SpritesMind.Net

By dynamically loading I mean that, when the sprite changes, its tiles are loaded from rom to ram the previous frame, the space of vram that occupies the sprite is always the same. The idea is to have large animations for the main character, which is the most repetitive one, so can lead to visual sa...

The 'SEGA' animation at the start generates multiple scaled copes of the logo on the CPU on start-up and animates between them. The original unscaled SEGA logo appears to be the only uncompressed graphics in the rom. For some reason I just thought of it, the sprites of the two main characters/heroe...

The most stupid optimization, but useful since can be done in lot of occasions: move.b 0xA10001, d0 and.b #0xF , d0 Optimized: moveq.l #0xF, d0 and.b 0xA10001, d0 If you are going for bit operations probably can be done. Also clears the register which perhaps is what you need.

Palettes are defined independently as 16 uncompressed colours, then referenced in palette sets which are just pointers to 4 palettes to load at once. Makes sense that way, palettes can be loaded anytime. You can compress them do, there are unused bits, but bit manipulation is not cheap at cpu level...

Wow! That’s a close encounter with nostalgia. Make sure to capitalize it and press the appropriate signals to recall attention to the appropriate public.

Congratulations! Good job.

You are right Eke, I thought that on cold start both z80 was stopped and without bus, so a fast position to check it, but it’s only stopped/reset. Just redid the experiment making sure the bus was acquired by the 68K and: Fusion: high byte Regen: high byte Gens KMOD: low byte MD1 Asian TMS: high byt...

I haven’t studied 16bit Sonic games in detail, but I’m pretty confident they use a several level metatile as main compression system. In that case I don’t think is possible to compress the metatiles themselves, but I don’t know about the (top) map. Be sure to understand what I'm talking about becaus...

I believe I do it with the Z80 stopped, but you could be right, let me check it again in a day or so.

Program tested: 0: move.w #0x00FF, 0xA00000 move.b 0xA00000, d0 jeq 0b Tested on (I could be using somewhat old versions of emulators): Gens KMOD: copies low byte Fusion: copies high byte Regen: copies low byte Real hardware TMS Asian: copies low byte Conclusion: it doesn’t matter since all those em...

I don’t know, my GUESS is: z80 bus is 8bit so you can't connect a word, it can’t be a buffer since there is no independent device working, therefor only d0-d7 are connected. The other option is d8-d15 are connected but that will be an unnecessary misconduct. move.b d0, 0xA00000 -> works for sure And...

No word access: Z80 memory space can only be accessed by the 68k in byte address mode, and that has to mean something.

No, you can write bytes from the 68k both at even and odd address. Documentation says (m68k.pdf): 68k byte Write Cycle: “STORE DATA ON D7–D0 IF LDS IS ASSERTED. STORE DATA ON D15–D8 IF UDS IS ASSERTED” So in theory the other byte is in unknown value. I could be that the byte is duplicated by the 68k...

For all I know, when the 68k reads something it stores the data into the data register as is in the data bus, in the next cycle, when it moves it to some other part (alu or general use registers, for example) on the exit of the data register it can swap bytes if needed. When it’s time to write…I hav...

Which register are you talking about, vdp register or cpu register?

From real hardware perspective I don’t know if VDP registers take into account UDS/LDS signals or not. What I know is that is not necessary at all, doing so only will waste chip gates. All memory access are 16 bit access, and then on a byte operation the 68K uses the upper or lower byte ONLY. Theref...