So, everything has been updated on the right apart from the old data sheets - everything is, I think current.
The main changes is that the Emulator now has a proper latency implementation. The picture on the right (Bowling again) shows the two pixels rather than one, and it doesn't flicker like the optimised one does.
The Space Invaders source has been packaged with a Binary and updated (it does run on MESS) and so has the system library, though I don't think that's been updated since the last time I used it.
Windows, OSX and source versions are available. Linux users should fine it compiles fine from the OSX sources. Windows users who want to compile it, well, good luck !
Space Invaders uses three keys, one from the left row, one from the middle, and one from the right. You move with left and middle, and fire with right.
To get off the static score screen press Left/Right (e.g. Left and Middle on the keyboard) at the same time.
It doesn't matter which row you use .... I've got 1k of code to fix the key routines if anyone really minds.
Thursday, 23 January 2014
Too smart for my own good.
This is the Microvision Bowling Cart which was dumped in the last day or two by Sean R. by the carve the top off and take a picture with an electronic microscope method.
Unfortunately it didn't work properly on the emulator. A couple of easy fixes - it has the 'reversed output' like Vegas Slots, and there were a couple of error bits that meant it went haywire.
But it kept flickering - switching 45 degrees all the time. I thought it was a timing bug or possibly a polarity reversal issue. MESS was fine (albeit the data was bit reversed) and MESS doesn't do the polarity reversal, not that it actually matters, you can't have too much DC in an emulator.
It was actually my try-to-be-too-smart optimised LCD code, which tried to second guess the programmer as to whether they were writing vertically or horizontally or both to the LCD controller. It got it right, but this cartridge, technically does both, sort of. The top left most pixel should be set as well as the one below it, but because it does multiple writes to these lines, it got confused, and switched between the two all the time. So sorry, that was really dumb and I hope I haven't wasted too much of Sean's time.
So my plan X is to write a proper LCD rendering routine and use that for the PC based emulator and the row one for the Arduino (I don't think it could do a pixel based one and keep up). This isn't hard, my optimised version treats a row as a single entity with a single entity whereas in reality each pixel has its own latency. This will mean the bomber game which draws everything as columns won't work on the Arduino.
Once I've done that I will update everything, rebuild the Windows version and so on.
Then maybe this weekend I can see if I can build the hardware version.
Unfortunately it didn't work properly on the emulator. A couple of easy fixes - it has the 'reversed output' like Vegas Slots, and there were a couple of error bits that meant it went haywire.
But it kept flickering - switching 45 degrees all the time. I thought it was a timing bug or possibly a polarity reversal issue. MESS was fine (albeit the data was bit reversed) and MESS doesn't do the polarity reversal, not that it actually matters, you can't have too much DC in an emulator.
It was actually my try-to-be-too-smart optimised LCD code, which tried to second guess the programmer as to whether they were writing vertically or horizontally or both to the LCD controller. It got it right, but this cartridge, technically does both, sort of. The top left most pixel should be set as well as the one below it, but because it does multiple writes to these lines, it got confused, and switched between the two all the time. So sorry, that was really dumb and I hope I haven't wasted too much of Sean's time.
So my plan X is to write a proper LCD rendering routine and use that for the PC based emulator and the row one for the Arduino (I don't think it could do a pixel based one and keep up). This isn't hard, my optimised version treats a row as a single entity with a single entity whereas in reality each pixel has its own latency. This will mean the bomber game which draws everything as columns won't work on the Arduino.
Once I've done that I will update everything, rebuild the Windows version and so on.
Then maybe this weekend I can see if I can build the hardware version.
Subscribe to:
Posts (Atom)