SpritesMind.Net

I poll for VBL bit in the VDP in main loop and I also set a flag in the frame interrupt. If main loop sees that the flag is set after all game logic it can assume slowdown has happened and act upon it, when flag isn't set the logic ended before frame did.

I just do 255/34 in my tools and it works for linear and the nonlinear ramp too.

Just for code I have couple old things that can be looked at : My first game on MD, very poor code : http://www.tmeeco.eu/SMD/GBMD11S.RAR Pong game that doesn't use RAM at all : http://www.tmeeco.eu/BitShit/PONG!RAM.ASM And for some less terrible stuff here's a disassembly of the TMSS ROM I made a w...

http://www.tmeeco.eu/SMD/68000.pdf
http://www.tmeeco.eu/SMD/68000REF.TXT
http://www.tmeeco.eu/SMD/68Ktiming.txt
http://www.tmeeco.eu/SMD/68Ktiming2.txt
http://www.tmeeco.eu/SMD/M68000PRM.pdf
http://www.tmeeco.eu/SMD/MC68000UM.pdf

These should get you going

Interrupts are auto-acknowledged on MD, there's no need to read the status port to get the next interrupt. Also on Z80 side, IRQ lasts entire line and if your handler finishes early it'll be called again due to it.

Only SMS/GG actually use the first index in a visible way, no other console does. So you're limited to using backdrop to make use of those first 4 indexes of each palette.

Your bank writes goes to high byte (D8....D15), you'll have to do MOVE.W #$bb00, ($A130xx) where bb is your bank number to get the number go to low byte (D0...D7) which the mapper responds to. Little-endian vs Big-Endian business.

I do wish the arenas get bigger and scroll around like Alien Syndrome. Single screen stages make things pretty underwhelming...
Music side of things has me interested though. Good luck ~

For small scale stuff it does make sense to 3D print things. Mechanically they can be good but you got to design things appropriately. If you need hundreds of cartridges then 3D printing is gonna be on the verge of not cheap plus it also takes a long time to make those carts. For thousands you can d...

There's no sharing of VRAM access patterns (MD and SMS access patterns are night and day, SMS mode using patterns identical to real SMS VDP), no compatible data formats (everything is completely different, GFX, tilemaps, sprite list) or the rendering process (identical to real SMS in SMS mode). Not ...

Writing is the part that isn't useful though, I got to pass stuff to Z80 side and almost never read back any responses. Workaround is using cart RAM, that's not subject to access issues from Z80. SMS compatibility is not a problem, NMI never happens in MD mode and YM IRQ never happens in SMS mode. Y...

* YM IRQ connected to Z80 * Bus management allowing to Z80 to make proper accesses to 68K side (so you can read and write RAM and VDP properly). * VDP turning unused sprite GFX fetches into CPU access slots * Line interrupts should start much earlier so that 68K hits the end of line rather than miss...

I have doubts it remains compatible enough with existing games and whatnot. Even 68010 breaks a lot of games.

I think first you should put effort into getting the content, arrange it up, create some mockups and then you'll have something concrete to show to someone who will be implementing things. It'll narrow down the scope and allows to focus on exactly how to make the content presentation a reality.

I like the 1 to 16 bits. You need whole 65536 posts to get to 16 hahahaha.