[hatari-devel] Big problems with bus error on Falcon

Thomas H. th.huth at gmx.de
Sat Jan 16 11:10:46 CET 2010


> Datum: Thu, 14 Jan 2010 23:28:52 +0100
> Von: Laurent Sallafranque <laurent.sallafranque at free.fr>

> It's too interesting, I take 5 minutes to answear ;)
> 
> > This is address 0xff800A.  According to docs it's unassigned.
> 
> That's why I'm asking myself that on the real computer, reading (or 
> writing to) an unasigned area does not generate a bus error as it does 
> on hatari. (it's just a guess, I have no clue).

Most unassigned adresses cause an bus error on real hardware, however certain memory regions do not and simply "ignore" the access. I think this depends on the address decoder of the corresponding hardware area.

> 
> > Another strange thing : the game conquest stops with a bus error at
> > address $ff8901.
> 
> 
> > Did it try to read or write a word from an odd address?
> 
> 
> I don't know, I'll have to look at the code.

In that case you would get an adress error instead of an bus error. But only with 68000 CPU since the 68030 can access odd addresses with word access, too.


Are you sure about the address? FF8901 seems to be mapped right in ioMemTabFalcon.c...
Could you maybe do a cpu_disasm trace run and paste the last dozend instructions before the crash here?

> Which docs do you use ?
> I use the compendium and the hardware.txt docs.

Docs are often wrong, especially the Falcon docs. I suggest to always think twice before blindly following a documentation text and test it with real hardware if possible... (maybe you could get/borrow a used Falcon somewhere, Laurent?)

> > Btw. I was looking at the current Falcon mappings:
> >
> > For example:
> >         { 0xff8006, SIZE_WORD, IoMem_ReadWithoutInterception, 
> > IoMem_WriteWithoutInterception }, /* Falcon configuration */
> >
> >
> > *Byte* at 0xff8006 is monitor type (programs cannot change), but
> > the next byte is Falcon processor control byte:
> > 	bit 0: 030 speed (set 16Mhz, unset 8Mhz)
> > 	bit 2: blitter speed (set 16Mhz, unset 8Mhz)
> > 	bit 5: STE bus emulation (0=on, 1=off)
> >
> > Shouldn't we emulate at least the first two bits?
> >   
> 
> Yes, probably. If it's not too hard to emulate ;)

Monitor bits already emulated, search for ff8006 in stMem.c.
However, you might want to add a real handler function for this register since it is currently possible that a Falcon program overwrites these monitor bits in this register, which might not be possible on real hardware.


> > Then:
> >         { 0xff800A, SIZE_WORD, IoMem_VoidRead, 
> > IoMem_VoidWrite },                               /* No bus error here */
> >         { 0xff800C, SIZE_WORD, IoMem_VoidRead, 
> > IoMem_VoidWrite },                               /* No bus error here */
> >         { 0xff8060, SIZE_LONG, IoMem_VoidRead, 
> > IoMem_VoidWrite },                               /* No bus error here */
> >
> > According to my documentation whole 0xff8008 - 0xff81ff range is
> unassigned.
> > Why these particular addresses are singled out, why all the (503)
> addresses
> > in this range aren't the same?
> >   
> Perhaps because Thomas added them one by one when he discovered and 
> corrected bus error for specifics programs (the same way I did it for 
> illusion). Thomas ?

I once wrote a little test program that steps through all IO memory addresses and tests which addresses cause a bus error and which do not. I then run this program on both, real hardware and the emulator and changed the ioMemTab according to the real hardware behaviour. So I am pretty sure that the IO bus error regions are already accurate in Hatari.

I can supply you with this test program next week (I am currently not at home), so you can compare yourself. (Just remind me again if I forget ;-) )

> > Then to video handling...
> > ...
> > So I guess display size can be wrong?
> >   
> 
> Yes, I think so too, but Videl Emulation is quite incomplete for now.
> I think I'll give it a try one of these days (but I don't feel as 
> comfortable with video than I was with crossbar).
> > According to my documentation, 0xff860e - 0xff86ff is unassigned,
> > is this a bug:
> >         { 0xff860e, SIZE_BYTE, IoMem_VoidRead, 
> > IoMem_VoidWrite },                               /* No bus error here */

All lines that are marked with "No bus error here" have been verified by myself with my test program. I don't think that you have to change anything here.

> >         { 0xff860f, SIZE_BYTE, FDC_FloppyMode_ReadByte, 
> > FDC_FloppyMode_WriteByte },             /* Floppy mode (?) register */
> >   
> Again, some patchs added one by one to let the falcon run ?

IIRC this is a real (ie. working) register on the Falcon which has something to do with the Ajax floppy disk controller. It's just _very_ hard to find documentation about this regiser. See bottom of fdc.c.

> Perhaps the good way would be to put all unasigned areas as 
> readvoid/writevoid ?

I think most of the unassigned regs that don't generate bus errors already use the ReadVoid and WriteVoid functions. I don't think that you've got to change much here, it should be pretty accurate already.

> > 0xff8700 - 0xff878e are SCSI registers with the areas 0xff8716 -
> 0xff877f - 
> > and 0xff8790 - 0xff879f being unassigned.  ioMemTabFalcon didn't have
> > anything on them.  Would be good to have comment on them.
> >   
> I don't know here.

A comment in the source code would be certainly good. Though the most docs only talk about TT SCSI registers... not sure whether they are the same on Falcon.

> > Microwire registers not implemented:
> >         { 0xff8922, SIZE_WORD, IoMem_VoidRead, 
> > IoMem_VoidWrite },                                     /* Microwire data
> */
> >         { 0xff8924, SIZE_WORD, IoMem_VoidRead, 
> > IoMem_VoidWrite },                                     /* Microwire mask
> */
> >   
> Microwire doesn't exist on Falcon. I've left the 2 registers here just 
> in case.
> Perhaps they should be removed. (except if as I suppose, all N/A areas 
> should be void read / write).

Someone should verify these registers on real Falcon, but I am sure that they do not generate a bus error there (or a lot of STE programs would simply crash on Falcon).

> > These were not in my document, what the crossbar thing does here?
> >         { 0xff893b, SIZE_BYTE, IoMem_ReadWithoutInterception, 
> > IoMem_WriteWithoutInterception }, /* No bus error here */
> >         { 0xff893c, SIZE_WORD, Crossbar_CodecStatus_ReadWord, 
> > Crossbar_CodecStatus_WriteWord }, /* CODEC status */
> >         { 0xff893e, SIZE_WORD, IoMem_ReadWithoutInterception, 
> > IoMem_WriteWithoutInterception }, /* No bus error here */
> > ?
> >   
> 0xff893b : N/A ? I don't know here (it's just here in case of a program 
> access to address 3a with a word.

No, that case would already be handled by the code in ioMem.c.
On real hardware when you've got a register of one byte size followed by an address that generates an bus error when accessed with "move.b", you also do not get a bus error when you access both addresses at a time with "move.w". So this case is already handled in ioMem.c (see the nBusErrorAccesses variable there).

I think this 0xff893b line is there because my bus error test program did not report an bus error at that address when it tried to access it in byte mode, so this address never generates a bus error on real hardware.

 
> > SCC DMA and port registers not implemented:
> >         { 0xff8c80, 8, IoMem_VoidRead, 
> > IoMem_WriteWithoutInterception },                        /* TODO: SCC */
> >   
> 
> I Don't know what is SCC.

IIRC that's the serial port of the Falcon.

 Thomas

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser



More information about the hatari-devel mailing list