openfpga-arduboy

openfpga-arduboy copied to clipboard

Games in the Arduboy library only use a few OLED commands, and use them in predictable ways. The 0x22 command used by the Gamebuino ports just needs to advance the buffer address to the next 'page' to resolve those glitches.

And the 0xB0-0xB7 page commands are only necessary for a couple of games, like ZooEscape:

https://raw.githubusercontent.com/eried/ArduboyCollection/master/Action%2FZooEscape%2FZooEscape.hex

While this kind of works, I would really like to stick with the command structure already in place. I also don't think this implementation matches the datasheet's, so there's likely to be more issues.

Fair enough - a complete by-the-datasheet OLED implementation is an admirable goal, and may be very useful for some other future project(s). But as I said, if the goal is playing Arduboy games then none of it will ever be utilised.

Also, while the current ssd1306-to-vga.v "kind of works" - some of it feels like unnecessary double-handling and obfuscation of the actual buffer writes with all of the x_cnt / y_cnt stuff.

Games in the Arduboy library only use a few OLED commands, and use them in predictable ways. The 0x22 command used by the Gamebuino ports just needs to advance the buffer address to the next 'page' to resolve those glitches.

And the 0xB0-0xB7 page commands are only necessary for a couple of games, like ZooEscape:

https://raw.githubusercontent.com/eried/ArduboyCollection/master/Action%2FZooEscape%2FZooEscape.hex

Can you provide the lss file for this hex, I hate Arduino IDE for it's lack of easy configurability but at the same time they unify multiple platforms under the same flag, I'll look into the issues.

I seen that the ssd1306-to-vga.v is not the issue, the SPI master is at fault, is taking more than 8 bit to become available to send again, some games does not check the ready/transmission complete flag, instead use a NOP delay to send at specified time to avoid losing 1-2-3 cycles each byte checking the flag and to the branch, some games seems that they send the data faster than the SPI need between begin and end of transmission when change from transmit data to transmit commands or viceversa or the core is 1-2 cycles faster than the original core in the same case :))) The SPI master is at fault because the Curse shift issue is visible with an original display as well, and Course does not use the 0x21/0x22 commands at beginning of the frame, they assume the counts are always at 0x00/0x00 at beginning of the frame. Anyway I'll change the ssd1306 driver to be able to receive paralel data and the SPI master be replaced with a paralel interface but the finish send be available after 8 bit transmission to avoid messing with games that do check the send complete flag.