SpritesMind.Net

And you've tested it on all variations of the hardware? Just checkin'.

You need to have code in RAM only if you're DMAing from outside the ROM area (i.e from MD RAM to VRAM).

But that's not what the official documentation says:

Source address are $000000-$3FFFFF(ROM) and $FF0000--$FFFFFF(RAM) for memory to VRAM transfers. In the case of ROM to VRAM transfers, a ...

I'm converting dma_vram_copy from genesis.c into ASM and I think I found a bug in it, at least the version I have. (I got it from one of his examples, so maybe he's updated it since then...)

void dma_vram_copy(uint source,ushort dest,ushort len)
{
register volatile ushort *pw;
register uint *pl ...

For any more serious MD dev, you need a flashcart or something else to run your code on the real deal... there's a lot of stuff you can do in emulators and not on real HW. Try using BTST on VDP ;)

Well, sure, but I think the point still stands -- especially if the required delay might be slightly ...

but you should check the output if you want to be sure.

I don't like the idea of relying on examining the compiler output for a decision like that. That gratuitously ties your code down to that particular version of that particular compiler... if you switch to a compiler that produces different ...

I have to admit it took me a second to figure out what you meant. So basically you're saying the fetch/decode part of the CPU's fetch/decode/execute sequence for the move instruction should cover it, right? Got it. :)

Or actually... could NOPs actually take 8 cycles rather than 4, hence two NOPs ...

I found one doc that says you need 16 cycles. Two NOPs is eight cycles. I'm not sure whether or not the doc means you need 16 cycles before the next move instruction that accesses the register, or 16 cycles including the next move instruction. If it includes it, then it should work out to at least ...

Pascal's code can be improved by using segments to declare variables. It's easier to read and it won't give you a chance to make a mistake and screw up your variables by declaring them wrong.

(This code is for asmx. It's probably very similar or even identical in other assemblers, but not having ...

Hmm, that's even stricter than the system I devised.

OK, I can see my line of thinking is not popular and it's not the "ASM way", so I will probably abandon this line of thinking. But for the sake of argument, I'll defend it anyway.

NEVER put anything on the stack if you have a free register. The more you keep stuff in registers, the faster it will ...

you have to put them after every TH line modification.

So it's something specific to that particular register, then? Any other places where I might need to use NOP where it isn't obvious from the documentation?

I'd say, question is 'how long this delay must be'? Because different C compilers ...

Yes, but my question is when they're necessary... how do you know when you should put them? As I said, I haven't found any information on it in the documentation.

the registers you pass get trashed (read: clobbered) anyway

Eh? Not if you don't change 'em, or if you preserve 'em.

Keeping track of 8/16/32 bit things shouldn't be a problem... you have B/W/L to tell you what are you dealing with.

I was thinking more along the lines of remembering whether ...

I'm wondering when exactly you should use NOP. For instance, here's the read_joypad1 routine from genesis.c:

ushort read_joypad1()
{
register volatile uchar *pb;
ushort i, j;

pb = (uchar *) 0xa10003;

*pb = 0x40; /* check joypad */
asm("nop");
asm("nop");
i = *pb & 0x3f;

*pb = 0 ...

This is more of a general M68000 question than a Genesis question, but I figured I might as well post it here. :)

I decided to start coding a game entirely in ASM as a programming exercise of sorts. I've been well-acquainted with the general principles of ASM for probably over 10 years now, but I ...