Yes, for the first time in thirty years (possibly because no-one else has been daft enough to do it) there's a new game for the Microvision.
It's one of those left to right Bombing the city flat games, where you have to clear a landing strip.
There are two keys - anything in the middle row drops a bomb, and anything on the left continues the game (when a level is over, because you've crashed or landed, it displays your score).
Source code has been added to the link list on the right. The assembler has also been updated (minor tweaks), the system library (ditto), and the Windows and OSX versions of the emulator (which contain the binary files).
Windows still has this clearing-one-byte behaviour (on resetting the TMS1100 it writes zero into code Memory [0]) that goes away with the insertion of an effectively null code line. I read through the code, and put a fair few ASSERTS in - I wondered if a rogue value got into X or Y and that caused a memory write , C not being protected, but can't see any problem. It's possible it might be in SDL of course.
Sunday, 19 January 2014
Saturday, 18 January 2014
Bomber, part the third
Bomber is now working, pretty much. The game core bit is playable, it has sound effects (well, in as much as a Microvision can manage them), the only bits left to do are the start a new level bit, and the end of game score display bit.
It does require a new version of the emulator (to fix the issue with row/column based rendering on the LCD, or to be precise my shortcut implementation of it !) so I'll probably release the updated executables, source and so on later this week. The assembler has been tweaked a bit as well.
The screen grabs look much the same, so here's a picture of an Avro Lancaster. If you're interested in this plane, Leo McKinstry's book is an excellent history of its design, production and use (he wrote similar books about the Spitfire and Hurricane)
It does require a new version of the emulator (to fix the issue with row/column based rendering on the LCD, or to be precise my shortcut implementation of it !) so I'll probably release the updated executables, source and so on later this week. The assembler has been tweaked a bit as well.
The screen grabs look much the same, so here's a picture of an Avro Lancaster. If you're interested in this plane, Leo McKinstry's book is an excellent history of its design, production and use (he wrote similar books about the Spitfire and Hurricane)
Friday, 17 January 2014
Bomber, part the second
| Bomber running in the Emulator |
Minor improvements made, both to the 'skyline' and the bomber and bombs are both visible on the screen - the bomber in the top left and the bomb about 1/3 of the way down.
Coding for Microvision is a bit like a 2600 in some ways - the screen display is pretty much everything and the rest wraps round it.
This is going to be a fairly primitive game - aren't they all :) - just bombing with increasing speeds and displaying a score at the end of the game.
Then I'll think of a second game to do that will be the main game for the Challenge.
Thursday, 16 January 2014
Bomber , part the first.
First bit of working bomber code, showing the 'buildings' (okay single square pixels) that you have to flatten with your bomber and bomb (both single square pixels).
Not much for the Graphics Artists here.
Showed up one bug though. The LCD rendering/latency code is optimised for column data writes (e.g. writing a line horizontally) - this renders lines vertically (so it can keep the building heights as a table - see bank 1, the numbers correspond to the building heights), but of course that doesn't work properly.
I don't want to do it a la MESS where it tracks each pixel individually, so I'll have to have a row based renderer and a column based renderer and switch between the two depending on the data in the latch. Which will be basically the same thing, might blink at switch over.
It's not a cycles issue for a PC or a Mac, but I still hope to get an Arduino version working, and that might be short of CPU cycles. No big problem really :)
Fix for tomorrow I think.
Not much for the Graphics Artists here.
Showed up one bug though. The LCD rendering/latency code is optimised for column data writes (e.g. writing a line horizontally) - this renders lines vertically (so it can keep the building heights as a table - see bank 1, the numbers correspond to the building heights), but of course that doesn't work properly.
I don't want to do it a la MESS where it tracks each pixel individually, so I'll have to have a row based renderer and a column based renderer and switch between the two depending on the data in the latch. Which will be basically the same thing, might blink at switch over.
It's not a cycles issue for a PC or a Mac, but I still hope to get an Arduino version working, and that might be short of CPU cycles. No big problem really :)
Fix for tomorrow I think.
Minor Updates
Couple of fixes to the assembler - it didn't handle page overflows properly following the conversion to the LFSR program counter, and labels can now have underscores in them.
I have also uploaded the current version of the system routines on the links page as well.
Further to the weird Windows only bug, I'm going to code read the emulator source in case I've done something daft, wouldn't be the first time :)
I have also uploaded the current version of the system routines on the links page as well.
Further to the weird Windows only bug, I'm going to code read the emulator source in case I've done something daft, wouldn't be the first time :)
Okay, so I decided to do something a bit different
It won't ever be done on a real Microvision, though - probably.
Not because it's technically impossible, actually it's technically not that difficult, but because the Microvision main units are so fragile that it's a rather expensive experiment.
This is a Cheetah3D model.
(Note that I'm not quite sure how you do the insert round curve at the top yet ....)
Library routines move onward
The support library is coming along quite well, I'm quite pleased with it. It currently occupies only four pages of ROM memory, and wastes only about 6 bytes - this is because a TMS1100 divides memory into pages of 64 bytes and you can't cross to a different page without a jump, it's not like a Z80 where memory is contiguous.
The screenshot uses about 12 bytes to - clear the screen, play a beep, display a number and increment it (the latter is for keeping scores and so on) - you can actually see most of the code in the screen shot. It operates like a fast counter. I suspect on a real Microvision it would be extremely blurry in the least significant digit because the LCD isn't one of the greatest available.
Functionality at present is :
The screenshot uses about 12 bytes to - clear the screen, play a beep, display a number and increment it (the latter is for keeping scores and so on) - you can actually see most of the code in the screen shot. It operates like a fast counter. I suspect on a real Microvision it would be extremely blurry in the least significant digit because the LCD isn't one of the greatest available.
Functionality at present is :
- Microvision hardware initialisation
- Writing a row or column bit pattern to the LCD latches given a row or column number
- Performing a Display Update
- Performing Display Polarisation switching
- A sound system that runs in the background (sort of - it toggles the speaker on the update and does the timing on the polarisation) which allows beeps of about 0.5 seconds or so and half a dozen different beeps, all dependent on how frequently you update the screen :)
- 3 x 5 digit font for scores / settings and the code to select it.
- Render a four digit number to the screen at any vertical position, optionally updating font data
- Clear screen routine / Zero score routine
- 4 bit Random Number Generator - bit rubbish but useable.
- Add 1, 10 or 100 to the 4 digit number (for scoring, mostly)
There's no keyboard routines or other utility functions - not sure what to provide, rotate functions maybe ?
Subscribe to:
Posts (Atom)
