Overall, I'm quite pleased with this RetroChallenge, after the mess of the last one anyway, which never really got restarted when I went on holiday.
I achieved most of what I planned - emulator, new game (actually two) and an Arduino version.
The 8021 was about 3/4 completed, but I never really went anywhere with it. It's more challenging to write for a TMS1100, and it's supposed to be a challenge.
It went a bit sideways in the middle, when the ROMs turned up. People have been thinking about home-brew Microvision games and emulators for years, but nobody dumped the ROMs even though it was known to be possible, and then two came along at once.
Thanks especially go to : Sean Riddle, Kevin Horton and Dan Boris.
Wednesday, 29 January 2014
Final Code Release
![]() |
Must be a boring film.... |
I've updated everything and rebuilt everything. The emulator has changed slightly, not bug fixes but changes to work with the Microvision / Arduino in the source, mainly to do with types (I forgot Arduino ints are 16 bits, longs 32 etc.). The main problem was that the rotary control only worked about 2/3 off the screen (due to wrap-around in the integer).
One mistake was that I put the rotary control checking stuff in the SDL hardware driver, so that came out and went where it belonged in the shared code.
Microvision.ino is a new upload. This is the Arduino file and is the extra bit you need besides the original source. Arduino doesn't really like complex project structures (not that this is complex) so you have to copy the header files from the source in and include the two shared files as a direct address link (e.g. the full path). It doesn't seem to work otherwise.
The last upload is a big one, 66Mb in size, it is the complete project tree off my machine, which contains everything.
I really must learn to use github and so on for the next project.
Sunday, 26 January 2014
Saturday, 25 January 2014
Hardware Version, progress report #4
![]() |
10k Pot added to the breadboard |
I found a 10k Pot in my box, from memory it was one of a batch I bought to repair a Microvision unit where the rotary controller was broken, and wired it into the remaining analogue port, and it plays fine.
Sound and Graphics work okay. There are a few minor graphic problems which relate to the incomplete emulation of the LCD.
Tomorrow I'll try the full LCD latency emulation and see how it works, it might well still be quick enough.
I will pinch our camera and make a video of some sort of the game being played, so you can see it is for real :)
One thing I forgot is that gcc-avr and gcc-x86 have different ideas about how big ints, longs and so on are - this was causing an overflow on the potentiometer calculations on the AVR, but it now all seems fixed and running nicely.
Hardware Version, progress report #3
After a lot of cursing regarding the Keypad library - the people who wrote it, it didn't seem to occur to them to have a simple 'is a key down' test, which is pretty helpful if you are programming games, I've got the keypad working. I might just chuck the keypad library and access the controls directly, rather like the LCD4884 library it is a bit limited.
I've also added the sound, which worked very well. The thing now beeps at me if I leave it alone though, Microvision carts do this to warn against battery usage.
So in BlockBuster you can now set the parameters and start the game up, of course you can't play it because I have done the pot (yet).
I always found Block Buster really difficult anyway, even on a real Microvision.
I've also added the sound, which worked very well. The thing now beeps at me if I leave it alone though, Microvision carts do this to warn against battery usage.
So in BlockBuster you can now set the parameters and start the game up, of course you can't play it because I have done the pot (yet).
I always found Block Buster really difficult anyway, even on a real Microvision.
Hardware Version, progress report #2
![]() |
Dracula has risen from the grave |
If I'm going to test it with Block Buster I'm going to have to add the potentiometer to the circuit, I think I have a few in the spares box somewhere.
It took longer than I though, because when I actually came to look at the LCD4884 library it is pretty useless except for drawing text (actually it doesn't do anything else at all !), so I had to grab the driver data sheet and poke the controller directly. This ended up being beneficial as the "dirty screen code" ended up being optimised for the way the controller worked, not the way the library worked.
Strange fact of the day : My watch was an hour fast for most of yesterday and I didn't notice......
Friday, 24 January 2014
Hardware Version, progress report #1
![]() |
Arduino board |
So if I actually dump that status to the LCD, then I should be getting (hopefully) the start up screen on the display.
The Arduino thing is a bit annoying. The 'IDE' is nice and easy if you just want a few simple bits, but try anything complicated and it just falls apart. The only way I can figure out to cross compile without abandoning it altogether is to #include the C files with a full path name (presumably because it copies source somewhere else - gawd knows). If you put the C files in the directory it compiles them, but bizarrely doesn't link them in. The Arduino is a great bit of hardware, and so is avr-gcc and avrdude, but the Arduino toolkit outside that is messy.
(One of the things I hate about the Mac is that there isn't a bl**dy key with a hash on it on the standard keyboard. So typing in #include or whatever means you have to press ALT 3. It's really annoying. The big keyboard has one but isn't wireless......)
The implementation is going to be pretty basic. I hacked the emulator so it dumped an include file line creating the ROM image in Arduino ROM if you precede the file name with an 'at'. That then is included into the source code which is compiled and uploaded.
Subscribe to:
Posts (Atom)