Developing for VZ – Part 4
I had seen a few people talking about a programming system created for vintage computers. The developer named it Turbo Rascal: Syntax Error (or TRSE for short). It’s free to download and use. Most of the coding is based on Pascal but there are some C-like programming methods in it.
I talked to the head developer about porting to the VZ200. He was busy with some other platforms and coding but said if I created some code he’d be happy to let me contribute to his Github for TRSE. I soon had my Github set up for it and he gave me permission to publish new code.
I wrote various routines in Assembly which are called from the Pascal-like TRSE. So the complex and fast-executing code is 100% pure Assembly, whereas the higher level things — variables, functions, records, coding can all be done using TRSE.
I wrote code for manipulating and drawing text in the VZ200 MODE(0) text mode then moved on to hires graphics support. I wrote procedures for drawing a dot on the screen in whichever colour you set the ‘Pen’ to. Then added support for drawing a line, a rectangle, a circle and a filled rectangle.
Next, I added support for sound effects and non-destructive sprites a’la MPAGD. Instead of drawing a sprite on existing pixel data, it would use XOR to draw and if you use XOR again it would return you back to the pixels previously there. I later added it as an option as I needed fast drawing without XOR (particularly when deleting a sprite).
I wrote the sprite code so you can first define a sprite as any pixels in size, then set the sprite data to an array containing the data and call a Draw routine to blit it to the screen.
You can actually change this on the fly! I wrote a clone of Centipede for the VZ200 called “Millipede”. It uses 4×4 pixel sprites for the player’s sprite, mushrooms and the millipede itself. When the spider or scorpion are drawn onscreen (or their explosions) it switches the sprite sizes to 12×4 pixels and switches back to 4×4 and the smaller sprite data array.
It works very well.
I did have an issue with sound due to the fact that the VZ uses the same memory location to set graphics/text mode, palette 0 or 1 and toggle 2 bits to make the speaker create a sound. Calling the built-in code in VZ200 ROM worked fine on one emulator but not on another nor on a real VZ300.
I recently re-coded it so it’d work and all is well.
I also purchased and downloaded Aseprite to design some graphics for my friend Shallan50k’s game “Luna”. It’s an amazing sprite editor for all sorts of computer platforms. I found some code for converting sprite data to a format which can be exported for Assembly programming. I soon based my code on that and wrote a plugin for Aseprite to export sprite data for the VZ200 which can be used in either Assembly (export in Hex or Decimal) or in a TRSE array — it exports with the sprite-data array line already formatted for you.
An example of the sprite data I exported to use for Millipede:
smallSprites: array of byte = (000,000,000,000,040, 128, 000, 000, 040, 162, 016, 000, 040, 170, 020, 016, 040, 170, 020, 020, 060, 192, 000, 000, 060, 243, 032, 000, 060, 255, 040, 032, 060, 255, 040, 040);
You can test your sprites in Aseprite and see how they animate by flipping through them. You can also set it to ‘Play’ the sprite frame-by-frame to see if it might look good on a real computer. I found it incredibly useful for Millipede as I changed the way my sprites worked and looked and had to redesign them. I had previously created them the hard way but this was much easier.