SpritesMind.Net

Posted: **Fri Dec 28, 2007 7:39 am**

HardWareMan wrote: If I replace that command this:

           move.b      (a0)+,d1        *
           rol.l       #8,d1           *
           move.b      (a0)+,d1        *
           rol.l       #8,d1           *
           move.b      (a0)+,d1        *
           rol.l       #8,d1           *
           move.b      (a0)+,d1        *

All works perfectly. I'd made some tests and here is result:

Looks like a byte swap was missed... but good friggin' lord! Do a byte swap this way:

Code: Select all

        move.l (a0)+,d1
        ror.w   #8,d1
        swap   d1
        ror.w   #8,d1

EDIT: Hmm... thinking about it a moment, if the above address isn't aligned and you're simulating the alignment error of the 68000, my code above will cause a fault on odd aligned addreeses. If the address is aligned or you don't check alignment on move.l in the emulator, then it's fine.

Posted: **Fri Dec 28, 2007 8:33 am**

Chilly Willy wrote:Looks like a byte swap was missed... but good friggin' lord!

I'm not use byte swapping. This is long word reading by byte.

Chilly Willy wrote:EDIT: Hmm... thinking about it a moment, if the above address isn't aligned and you're simulating the alignment error of the 68000, my code above will cause a fault on odd aligned addreeses. If the address is aligned or you don't check alignment on move.l in the emulator, then it's fine.

Maybe. Pointers lays on odd or even addresses. But I'm reading the "MOTOROLA M68000 FAMILY Programmer’s Reference Manual" and not found any restriction to "MOVE" command. Only command must be aligned to even addresses.

Posted: **Fri Dec 28, 2007 12:07 pm**

HardWareMan wrote:Emulator: see below.
Windows: does not matter.
Here is the problem:
1: GENS's debugger wrong decodes ORI.W and some other opcodes.
2: I found a bug in emulation M68K in MOVE.L (A0)+,D1. First time it's work fine, after some calculations it's read garbage in D1, but A0 is still correct. MOVE.B (A0)+,D1 works perfectly.

oh...M68k engine...I never looked at it yet...
I'll try to find if someone corrected this starscream bug.
when you say "wrong decode", do you mean disasm output is wrong or it produces bug (like for move.l) ? (to know if it's a engine or print issue)

PPS. Can you do something with that terrible 16bit screen mode? That screen flashes is killing me... (Gens32 use 32bit screen mode)

ah ah! I know...but it's very hard to change it...
I tried some years ago to just disable color mode change but if you're in 32bit, color became corrupt
I didn't try anymore since I didn't want to lost time in a Gens issue

Posted: **Fri Dec 28, 2007 1:35 pm**

I have my screen always in 16bit mode... no need for more.

[quote=HardWareMan]Only command must be aligned to even addresses.[/quote]

AFAIK, all instructions must be on EVEN addresses, and all data bigger than BYTE must be on EVEN addresses. I get ADDRESS ERROR in my code if doing say MOVE.W ($FF0001), D0.

Posted: **Fri Dec 28, 2007 4:00 pm**

KanedaFr wrote:oh...M68k engine...I never looked at it yet...
I'll try to find if someone corrected this starscream bug.
when you say "wrong decode", do you mean disasm output is wrong or it produces bug (like for move.l) ? (to know if it's a engine or print issue)

Yes, just printing error. If press "Step" ("T" button) PC changes and next instruction shows correct.

TmEE co.(TM) wrote:AFAIK, all instructions must be on EVEN addresses, and all data bigger than BYTE must be on EVEN addresses. I get ADDRESS ERROR in my code if doing say MOVE.W ($FF0001), D0.

Oh... You right... "M68000 8-/16-/32-Bit Microprocessors User’s Manual" says:

An address error exception occurs when the processor attempts to access a word or long word operand or an instruction at an odd address. An address error is similar to an internally generated bus error. The bus cycle is aborted, and the processor ceases current processing and begins exception processing. The exception processing sequence is the same as that for a bus error, including the information to be stacked, except that the vector number refers to the address error vector. Likewise, if an address error occurs during the exception processing for a bus error, address error, or reset, the processor is halted.

Heh...

Posted: **Sat Dec 29, 2007 8:31 am**

movep allows for odd addresses, but it only reads/writes a byte at a time. An old DOS emulator for the ST did this to read a word from any address (avoids the odd address error):

Code: Select all

    movep.w 1(a0),d0
    move.b   (a0),d0

That loads a litte-endian word into d0. Rotate/shift on the 68000 are SLOW, so you wanted to avoid move.b/shift/move.b sequences.

Posted: **Sat Dec 29, 2007 12:54 pm**

HardWareMan wrote:
Chilly Willy wrote:Looks like a byte swap was missed... but good friggin' lord!

I'm not use byte swapping. This is long word reading by byte.
Chilly Willy wrote:EDIT: Hmm... thinking about it a moment, if the above address isn't aligned and you're simulating the alignment error of the 68000, my code above will cause a fault on odd aligned addreeses. If the address is aligned or you don't check alignment on move.l in the emulator, then it's fine.
Maybe. Pointers lays on odd or even addresses. But I'm reading the "MOTOROLA M68000 FAMILY Programmer’s Reference Manual" and not found any restriction to "MOVE" command. Only command must be aligned to even addresses.

No, he's right. Non-byte data accesses to odd addresses cause an Address Error exception (remember those things at the top of the cartridge?) on the 68000 and 68010. They just cause reduced performance on the 68020 and later. Which means that Gens is the only one doing the right thing here.

Your problem may be that you're looking in the "family" reference manual, when you need to look at something specifically for the 68000. (maybe even a special section in that very manual)

And I've been doing 68K assembler since 1985, so I should know. I even put an address error handler in the game that I was working on last year, and hit it more than a few times. (Apparently the MESS emulation gets this right too.)

Posted: **Sat Dec 29, 2007 1:37 pm**

It would be nice if all the 68K exceptions are emulated in Kmod, especially ADDRESS ERROR, since every once in a while I stumble upon it... and after several hundred lines of code it isn't always the easiest thing to find...

Posted: **Sat Dec 29, 2007 2:12 pm**

Did you try to spy vector 3 (0xC) call ?
I don't remember if Gens handle all the vectors or not...
personally, i use my Debug_Alert function...

I don't remember if Megadrive support all 68k vectors...

sorry for all these "I don't remember" but it"s been a while I looked at Gens core

Posted: **Sat Dec 29, 2007 4:27 pm**

no MD emu I have doesn't support Address Error... and MD seems to support all 68K exceptions.

Posted: **Sat Dec 29, 2007 6:22 pm**

TmEE co.(TM) wrote:no MD emu I have doesn't support Address Error... and MD seems to support all 68K exceptions.

Not MD support that exceptions, but 68000 it self in MD. When I repairing one MD, 68000, it did double bus error and halts. With fully complies with the specifications.

Posted: **Sat Dec 29, 2007 6:49 pm**

I expressed myself badly...

SpritesMind.Net

Bugs ?