It appears full screen update of a 220x176 buffer @ 50 FPS is possible afterall.
Keep in mind this is not doing anything else but the graphics. But nevertheless, it really is refreshing from a 220x176 screenbuffer at 50 frames per second. Oscilloscope timebase is 5ms/div and there are 4 divs (every frame flips low / high)
That’s exactly what it is. Thats how the old EGA monitor cable worked, and where I got the idea from.
Maybe. I will need to test.
EDIT: the trick to optimizing on a device like this, is to keep the loop so simple, that everything fits in the registers. That is why accessing screenbuffer, palette buffer etc with indexes is not actually maybe the fastest way: registers need to be stored, and then recalled when you fetch data from different locations.
If you look at the assembly code generated per mask, its not half bad actually! Its about 15 cycles per pixel.
Mind you, I was able to crunch out about 10% speed increase from all modes while I was it
I’ve come across enhanced graphics adaptor before, I’d just forgotten that it lined up so well with RGB. I guess I remember the second half better because all the colours followed a pattern except for the darker yellow which they somehow modified to brown.
I checked and they actually mapped the 1 bits to 0xAA for the darker colours, which is probably why the multiplication idea came to mind.
(Your adding this wouldn’t be related to Operation Wolf, would it? I remember a similar-looking game being mentioned here a while back.)
That is pretty small.
I was confused by the lslsnegs combo, but I’m guessing that’s an optimised version of the multiplication.
(It’s equivalent to multiplying by -2, so I’m guessing R_MASK is equivalent to -2.)
I’m guessing t is signed by the fact asrs was generated instead of lsrs (I assume that’s what it would be called).
(Either that or it’s just a compiler anomaly.)
I think I’ll add brushing up on ARM ASM to my todo list.
Looking up EGA games, there’s quite a few decent ones.
Yes, looks like using bitshift (and unsigned variables?) instead of multiplication could save one instruction per mask.
I did not spot “t >>= 1” in the assembler as that is done for each mask too.
The result is saved to scptr (scanline buffer?) here already. I could be faster to save results of the rgb components to a register and only store the final rgb value to the scanline buffer.
That is weird. I think I once verified the FPS counter by moving a bitmap one pixel at a time horizontally and measured with a clock the time it takes to go over the screen.
I am pretty sure of this. I used the EXT0 pin high/low every second frame. Then measured length of pulse on several timebases. Same result in the Mode 14 trial and Pixonia using the default 110x88x16 color mode
Would the visual test do the job: Move a 10x10 bitmap one pixel right each frame, do that 100 times, measure the time, check if it matches to the FPS counter.
Of course, it might be difficult to see if some frames are skipped for some reason.
Or even harder to see if some frames are drawn twice to LCD without an application knowing it
But that is how we could start anyway. There could as well be just some stupid calculation error by me. One thing I could improve is to round the fps value correctly to the integer, but that is a minor thing.