As I remember it, the MS didn't support X-flipping the sprites in hardware. I also remember that you had to place a certain number of T-states between writes (more during screen time than in VBlank). I double-buffered all the sprite images, wrote the unflipped one in Vblank and software X-flipped (i.e. a 256 byte table) and downloaded during screen time. I remember that it took JUST the right number of cycles for both cases and I figured that the hardware guys had thought about it. I ALWAYS double-buffered my sprites on 8-bit systems. Tomb Raider Color Gameboy did it (and downloaded the entire screen image so if I had had the time, I could have done some biiiggg effects... but no developement time)
If I remember quickly, it went something like this (it is 18 years ago!). VBlank ------ LD A,(HL) ; OUT ($BC),A ; this was repeated 32 times, no loop. INC L ; LD E,(HL) ; LD A,(DE) ; repeated 32 times, no loop. OUT ($BC),A ; INC L ; I ALWAYS use 8*16 sprites since you can get twice as much moving, in fact I don't know why anyone would use 8*8 really.
The reason I only needed and INC L rather than an INC HL was that the sprites were 64 bytes each (4 bits per pixel x 128 pixels (8*16)) and were on 64 byte bounderies. I also built a sound developement tool on the PC. I couldn't find the part number of the MS sound generator but I chanced across the chip on an early Japanese PC and I got the number by taking the thing apart. The sound driver was best shown off on 'Asterix and the Great Rescue'. I also did the MD sound-driver for games like 'Asterix and The Power of the Gods'. That was 100% Z80 and I was proud of it! On another note, did anyone else notice that the MD RAM was at locations $ff0000-$ffffff? The top 8 address-lines were not connected so it was, basically, the last 64K of address space. That means you can use short-word addressing and if you sacrifice one address register (pointing at $ff8000), you can read & write relative to that. Good speedup!
I cannot comment much on the SMS, it had no FIFO on the VDP so things had to be nicely timed when you were out of VBL. As for MD... ...the relative addressing trick for MD RAM works nicely, and those top 8 address bits are free use flags too since their state makes no difference on how things go on HW side Also, no offence, but your MD Z80 music driver that got used in Asterix is a bit poor... but one will always be proud over what one does Here's an example of what my Z80 music driver can do : http://8bitcollective.com/music/TmEE/Guile+Theme/ enjoy :3 and one more : http://8bitcollective.com/music/TmEE/The+Coast/
Do you still have the sms sound development tool you created for PC Piglet? I'm sure people doing homebrew coding for sms now would be interested in it. Have you ever visited smspower? (http://www.smspower.org/) its a very good site for sms development, has a museum section etc. Perhaps you could share some of your sms development experiences on the forum there too.
Hehe. Cool I love reading about old dev stuff/stories/comments like this. Yeah, took me a bit to realize that move.w $8002, d0 wrapped into the upper address range because it's signed. So you could access the top 32k directly @ 4 cycles faster. Of course (a0,d0.w) is also faster too, but I tend to stay away from indexing like that on the 68000. Sequential access is always faster if you add the base+index first, then post increment. I'm pretty sure it's also faster to even just add directly to a0 and do (An) than it is to do (a0,d0.w) and add on d0 - for increments larger than 1/2/4. Heh, but I'd have to re-check the cycles times again to make sure.
