SpritesMind.Net

there is no way to "fix CRAM dots, but with clever timing you can avoid them. Sonic 3 is a great example of this; while it doesnt DMA, it writes 3 colours per scanline, with a very precise timing to basically push the dots into overscan. This and some clever code (in case of DMA) and you can squeeze...

its not necessary at the least, but you save yourself a lot of unnecessary headache by clearing the RAM anyway.

bclr #FLAG_FRET_GREEN, (fret_flags) ; clear the green fret bit first btst #pad_button_a, d0 ; Check A button bne @NoA ; if button is off, skip setting the bit bset #FLAG_FRET_GREEN, (fret_flags) ; set the green fret bit @NoA: This is the easiest solution; of course there are ways to optimize cycle ...

I'd like something like that Nemesis. And I can test them out, when I hace money for a flash cart, as I have 3 machines mysel (2x model 1 MegaDrive, 1x model 1 Genesis; need to open up to see board revision)

A while back, as we spoke about MoVfuscator, an utility which compiles any C code to only use mov instruction, we thought if move in Motorola 68000 would also be in fact Turing complete. A lot came out of it, but no real way to fully exploit Motorola 68000 with working methods. After that, I took so...

I am not sure about SNASM68K, all I know about it is, that I cant even run that assembler in my Win7 64-bit machine. As far as I know the assembler is known for being... bad, at least on Sonic hacking scene. I may be biased, but I'd suggest to use ASM68K (Nemesis version, it fixes lots of issues and...

you can not DMA in multiple 128KB areas. In fact 0x20000 is another 128KB bank, therefore the DMA breaks and reads from 0 for bytes past 0x1FFFF, as far as I am aware. This can easily be fixed by making sure no DMA'd data is in 2 128KB areas in ROM.