The screen list which determines which render method to use for a certain line is only trip points, and the address of the function to set for the following lines. That's three bytes per trip point and we had maybe 10 trip points per screen. Not much. If RAM was really tight, one could simply not re...
While I certainly appreciate the effort, it's mainly the existing games and the emulator which did it for me in 2011. Also, putting a decent game into only 60K ROM and 4K RAM requires a lot of thought and that's a whole lot of the gratification programming for the Uzebox offers. It's missing if the ...
Unfortunately, I cannot reproduce the MMC speed problems. Now some cards work at both speeds without further measures, while some don't work at all. Should I be sad? Happy? :roll: (But all working cards are unhappy with ACMD41 and need CMD1 instead, still.) (I used this tutorial, by the way: http://...
Janka: I tried out the MMC patched version, however for some reason it behaves really odd (at least in the emulator). It works, but really slow, at the moment I have no idea why (this happens even when I use the hex you provided). I wanted to add the patch to the master repo so it existed as an opt...
My wild guess is those ._ files are the resource streams. FAT does not support multiple streams per file but MacOS wants to store some metadata along which each file so it creates that crap. I also found it in archives made on Macs.
Simply ignoring dotfiles should help. How do we do that in 3 byte?