EmuTOS do not run with a PAK68/2 Speeder ...

Hardware, coding, music, graphic and various applications

Moderators: Mug UK, [ProToS], lp, moondog/.tSCc., Moderator Team

User avatar
frank.lukas
Hardware Guru
Hardware Guru
Posts: 1649
Joined: Tue Jan 29, 2008 5:33 pm
Location: Germany

EmuTOS do not run with a PAK68/2 Speeder ...

Postby frank.lukas » Mon Nov 21, 2016 11:12 am

I split EmuTOS 0.97 256kB Version in for 64kB Eproms and put it on a PAK68/2 MC68020 Speeder Card for the Atari ST and it do not boot ...

Image
fancy Atari Musik anDA Dance "Agare Hinu Harukana" 1998 ATARI http://www.youtube.com/watch?v=JX10fxb5eYE

BlankVector
Captain Atari
Captain Atari
Posts: 461
Joined: Wed Oct 24, 2007 7:52 pm
Location: France
Contact:

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby BlankVector » Mon Nov 21, 2016 12:42 pm

I assume that you didn't mess the EmuTOS ROM when splitting/flashing. Of course, it would be the #1 cause of trouble.
Does the same procedure work fine with any Atari TOS ROMs?

Regarding to EmuTOS, I can just say that Hatari + 68020 + EmuTOS just works fine. I don't know how much the PAK68/2 hardware is different from that setup.
Subscribe to my Vretrocomputing channel on YouTube and Facebook.

User avatar
frank.lukas
Hardware Guru
Hardware Guru
Posts: 1649
Joined: Tue Jan 29, 2008 5:33 pm
Location: Germany

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby frank.lukas » Mon Nov 21, 2016 12:49 pm

To Split I use ROMMIX from the Pinatubo package ...

Code: Select all

# Kommandodatei fr ROMMIX:
# erstellen von 4 Eprom-Files fr 27C512
# 1 EmuTOS-IMG wird auf 4 Eproms aufgeteilt
# von Udo Overath @ KR
# (das geht auch direkt mit Pinatubo --- ms)

# Puffergr”že setzen
bufsize 256k
# Directory setzen
chdir e:\pinatu24\rommix\

load emutos.img 0 256k all -> 0 all
save ee.u11 64k <- 0 ee
save oe.u10 64k <- 0 oe
save eo.u9 64k <- 0 eo
save oo.u8 64k <- 0 oo



I did that also with TOS 2.06 and it works fine with the PAK68/2 ...
fancy Atari Musik anDA Dance "Agare Hinu Harukana" 1998 ATARI http://www.youtube.com/watch?v=JX10fxb5eYE

User avatar
1st1
Atari Super Hero
Atari Super Hero
Posts: 802
Joined: Mon May 07, 2012 11:48 am

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby 1st1 » Mon Nov 21, 2016 2:51 pm

On an original ST the first bytes of the TOS rom, containing under others the reset vector is blended/mapped to adress 0 of the adress room of an 68000. So after a reset the 68000 finds the reset vecor out of the TOS ROM there the jump adress for TOS start into ROM.

The PAK 68/2 brings it's own TOS-ROMs. But the PAK does not support mapping/blending of the first bytes of these ROMs to adress 0. Instead, some original TOS roms with the correct reset vector must be installed on the ST mainboard. There the mapping/blending works and the 68020 on the PAK can see the reset vector. For example the combination TOS 1.04 on mainboard and TOS 2.06 on the PAK works fine. If you don't have TOS 1.04 ROM on the ST, the PAK does not start.

Now the question is: Needs EMUTos 256kB ROM the same reset vector value as TOS 2.06 (and 1.04) or a different one?
Power without the Price. It's not a bug. It's a feature. _/|\_ATARI

1040STFM in PC-Tower (PAK68/2, OvrScn, 4 MB, 1GB SCSI, CD-ROM...) * 2x Falcon 030 32GB/14MB+ScrnBlstrIII * 2x TT030 73GB/20MB+Nova * 520/1040STFM * 520/1040STE * 260/520ST/+ * some Mega ST * 2x Mega STE 500MB/4MB+M.CoCo * Stacy * STBook * SLM605 * SLM804 * SLM605 * SMM804 * SH 204/205 * Megafile 30/44/60 * SF314 * SF354 * 5x Pofo * PC3

anodyne
Atari maniac
Atari maniac
Posts: 75
Joined: Mon Aug 27, 2007 11:15 pm
Location: Canada
Contact:

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby anodyne » Mon Nov 21, 2016 4:13 pm

frank.lukas wrote:I split EmuTOS 0.97 256kB Version in for 64kB Eproms and put it on a PAK68/2 MC68020 Speeder Card for the Atari ST and it do not boot ...


Did you try running emutos.prg from the desktop instead of from ROM? That would help narrow down where the problem is.

anodyne
Atari maniac
Atari maniac
Posts: 75
Joined: Mon Aug 27, 2007 11:15 pm
Location: Canada
Contact:

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby anodyne » Mon Nov 21, 2016 4:21 pm

1st1 wrote:Now the question is: Needs EMUTos 256kB ROM the same reset vector value as TOS 2.06 (and 1.04) or a different one?

The EmuTOS 256kB ROM has the same format as TOS, i.e. the second long is the address to jump to on a reset. Or am I answering the wrong question?

BlankVector
Captain Atari
Captain Atari
Posts: 461
Joined: Wed Oct 24, 2007 7:52 pm
Location: France
Contact:

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby BlankVector » Mon Nov 21, 2016 4:51 pm

1st1 wrote:For example the combination TOS 1.04 on mainboard and TOS 2.06 on the PAK works fine.

I wonder how this can work, because TOS 1.04 is a 192KB ROM mapped at $FC0000, while TOS 2.06 is a 256KB ROM mapped at $E00000.

EmuTOS itself does not use that mapping of bytes 0 to 7 to the beginning of the ROM. However, you are right, that mapping is mandatory for the 68000 to start at the right address. I wonder how this is supposed to work on PAK68/2...
Subscribe to my Vretrocomputing channel on YouTube and Facebook.

User avatar
1st1
Atari Super Hero
Atari Super Hero
Posts: 802
Joined: Mon May 07, 2012 11:48 am

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby 1st1 » Mon Nov 21, 2016 5:55 pm

anodyne wrote:
1st1 wrote:Now the question is: Needs EMUTos 256kB ROM the same reset vector value as TOS 2.06 (and 1.04) or a different one?

The EmuTOS 256kB ROM has the same format as TOS, i.e. the second long is the address to jump to on a reset. Or am I answering the wrong question?


Yes, that's the wrong answer. The question is if the adress in the reset vector is the same or a different one.
Power without the Price. It's not a bug. It's a feature. _/|\_ATARI

1040STFM in PC-Tower (PAK68/2, OvrScn, 4 MB, 1GB SCSI, CD-ROM...) * 2x Falcon 030 32GB/14MB+ScrnBlstrIII * 2x TT030 73GB/20MB+Nova * 520/1040STFM * 520/1040STE * 260/520ST/+ * some Mega ST * 2x Mega STE 500MB/4MB+M.CoCo * Stacy * STBook * SLM605 * SLM804 * SLM605 * SMM804 * SH 204/205 * Megafile 30/44/60 * SF314 * SF354 * 5x Pofo * PC3

User avatar
1st1
Atari Super Hero
Atari Super Hero
Posts: 802
Joined: Mon May 07, 2012 11:48 am

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby 1st1 » Mon Nov 21, 2016 6:00 pm

BlankVector wrote:
1st1 wrote:For example the combination TOS 1.04 on mainboard and TOS 2.06 on the PAK works fine.

I wonder how this can work, because TOS 1.04 is a 192KB ROM mapped at $FC0000, while TOS 2.06 is a 256KB ROM mapped at $E00000.

EmuTOS itself does not use that mapping of bytes 0 to 7 to the beginning of the ROM. However, you are right, that mapping is mandatory for the 68000 to start at the right address. I wonder how this is supposed to work on PAK68/2...


That is what I explained. The PAK does not make mapping. But it blends out the original TOS at it's original adress range (those 192 kb) on the mainboard, so only the PAK TOS is visible to the 68020. But the mainboard chipset does a mapping/blend/mirror of the first bytes of the mainboard TOS to adress 0.

Also the 68020 and any newer Motroloa 68K CPU, even Apollo, need that mapping to read the reset vector.

So the 68020 starts with reset vector readed from mainboard TOS. And it does not take care if mainboard TOS is 192 or 256 kBytes, it's only the reset vector out of the mainboard TOS which needs to be visible to the CPU.

I hope that you now understand the problem: The mainboard TOS must have the correct reset vector adress to jump the processor into TOS ROM start adress. If it's wrong, the CPU will execute silly instructions from the wrong adress... So the details needed to know is if then reset vector of TOS 1.04, 206, EMU-TOS 192 kB, EMU TOS 256 KB all have the same reset vector in these first bytes.
Power without the Price. It's not a bug. It's a feature. _/|\_ATARI

1040STFM in PC-Tower (PAK68/2, OvrScn, 4 MB, 1GB SCSI, CD-ROM...) * 2x Falcon 030 32GB/14MB+ScrnBlstrIII * 2x TT030 73GB/20MB+Nova * 520/1040STFM * 520/1040STE * 260/520ST/+ * some Mega ST * 2x Mega STE 500MB/4MB+M.CoCo * Stacy * STBook * SLM605 * SLM804 * SLM605 * SMM804 * SH 204/205 * Megafile 30/44/60 * SF314 * SF354 * 5x Pofo * PC3

rpineau
Atari Super Hero
Atari Super Hero
Posts: 511
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby rpineau » Mon Nov 21, 2016 6:14 pm

@frank.lukas,
As explained above, the 680x0 reads the 8 first byte at address $0 to fetch its PC and stack address.
If the Pack doesn't remap these, the 68020 will read them from the ST where the GLUE remap them to the onboard TOS. IF the TOS on the machine (not on the PAK) is a TOS 2.06 it will fetch the right PC value and then jump to $00E00030. If it's a TOS 1.04, it will just to $00FC0000.
As you used the 256K Emutos, it's mapped to $00E00000. If you use the 192K Emutos, it will be mapped to $00FC0000 and should work if your onboard TOS is 1.0x
Rodolphe
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 766
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby mfro » Mon Nov 21, 2016 6:39 pm

rpineau wrote:@frank.lukas,
As explained above, the 680x0 reads the 8 first byte at address $0 to fetch its PC and stack address.
If the Pack doesn't remap these, the 68020 will read them from the ST where the GLUE remap them to the onboard TOS. IF the TOS on the machine (not on the PAK) is a TOS 2.06 it will fetch the right PC value and then jump to $00E00030. If it's a TOS 1.04, it will just to $00FC0000.
As you used the 256K Emutos, it's mapped to $00E00000. If you use the 192K Emutos, it will be mapped to $00FC0000 and should work if your onboard TOS is 1.0x
Rodolphe


As TOS2.06 appears to work fine on the PAK without any modifications, we (some guys at the German forum) actually expect EmuTOS should work as well. We assume the access to FC0000 caused by the on-board roms are "tricked" to E40000 with the PAK which should be a mirror to E00000 (considering 64 kB chips).

There is another thing that caught our attention: very early in the startup code, EmuTOS tries to write to the PMMU TC register (TOS 2.06 doesn't seem to do anything similar). The 68020 does not have a PMMU, but on the PAK (as MiNT detects an 68030), it appears the card's GAL redirects all coprocessor access to the 68881 on the board regardless of coprocessor id.

Is it possible that this access causes EmuTOS to hang?

rpineau
Atari Super Hero
Atari Super Hero
Posts: 511
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby rpineau » Mon Nov 21, 2016 6:52 pm

I check the TOS address decoding in the Pak gal code and it does indeed decode for E00000.

The fpu cs doesn't check for the copro-id as it checks a[19..16] (copr. address in CPU space) but not for A[15..13] (which is the copr-id):
csfpu = fc0 * fc1 * /a[19] * /a[18] * a[17] * /a[16] * /JP4 ;
So that could indeed be an issue as it would get a FPU error if an attempt at writing to the PMMU result in a write to the FPU and trigger an exception.
Regards, Rodolphe
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

rpineau
Atari Super Hero
Atari Super Hero
Posts: 511
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby rpineau » Mon Nov 21, 2016 6:59 pm

I think the code that has that issue is there :

Code: Select all

not_68030:
        move.l  #mmu_done,0x10     // if a MOVEC causes an exception, we're done
        moveq   #0,d0
        MOVEC_D0_ITT0              // first we initialise the TTRs (ACRs on a 68ec040)
        MOVEC_D0_ITT1
        MOVEC_D0_DTT0
        MOVEC_D0_DTT1
        MOVEC_D0_TC                // disable translation on 68040-60 (will error out
                                   //  on a 68ec040)

Well .. a movec will not trigger an exception on a 68020 . but it doesn't have a PMMU so this is probably what breaks on the Pak020 (or any 68020 cards that doesn't decode the copro ID).
You can comment that code and recompile emutos and see if this helps.
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

anodyne
Atari maniac
Atari maniac
Posts: 75
Joined: Mon Aug 27, 2007 11:15 pm
Location: Canada
Contact:

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby anodyne » Mon Nov 21, 2016 8:29 pm

rpineau wrote:I think the code that has that issue is there :

Code: Select all

not_68030:
        move.l  #mmu_done,0x10     // if a MOVEC causes an exception, we're done
        moveq   #0,d0
        MOVEC_D0_ITT0              // first we initialise the TTRs (ACRs on a 68ec040)
        MOVEC_D0_ITT1
        MOVEC_D0_DTT0
        MOVEC_D0_DTT1
        MOVEC_D0_TC                // disable translation on 68040-60 (will error out
                                   //  on a 68ec040)

Well .. a movec will not trigger an exception on a 68020 . but it doesn't have a PMMU so this is probably what breaks on the Pak020 (or any 68020 cards that doesn't decode the copro ID).
You can comment that code and recompile emutos and see if this helps.


According to the M68000 Family Programmer's Reference Manual, doing a MOVEC with an invalid control register field should cause an illegal instruction exception. MOVEC to ITT0/ITT1/DTT0/DTT1 have control register fields 004/005/006/007 which are illegal on the 68020. So it should trigger an exception, and therefore branch to mmu_done.

joska
Hardware Guru
Hardware Guru
Posts: 4186
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby joska » Mon Nov 21, 2016 9:08 pm

rpineau wrote:I check the TOS address decoding in the Pak gal code and it does indeed decode for E00000.


Yes, it has to do that to be able to run 2.06. However, it looks like it does not decode address 0, but in some absurd way relies on the motherboard ROMs. I have no idea how the PAK does that, and it just looks completely bonkers.

Anyway, I have a PAK/20 here that does not boot on either of my Megas (crashes very early in boot due to RAM errors), I hope to get that sorted soon and maybe find out how this odd thing works :)
Jo Even

VanillaMiNT - Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 766
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby mfro » Mon Nov 21, 2016 9:12 pm

anodyne wrote:... doing a MOVEC with an invalid control register field should cause an illegal instruction exception. MOVEC to ITT0/ITT1/DTT0/DTT1 have control register fields 004/005/006/007 which are illegal on the 68020. So it should trigger an exception, and therefore branch to mmu_done.


Hi Roger,

I assume this has never been tested on an 68020 or on a PAK?

What if the PAK's GAL forwards *all* coprocessor accesses to the MC68881?

I never tested this myself (although I was a proud owner of a PAK like twenty years ago) but could well assume that this case might trigger a coprocessor protocol violation exception (which isn't trapped) instead?

rpineau
Atari Super Hero
Atari Super Hero
Posts: 511
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby rpineau » Mon Nov 21, 2016 9:24 pm

We could at least test a version without the write to PMMU (I can recompile it if needed and post it here).
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

User avatar
DarkLord
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4256
Joined: Mon Aug 16, 2004 12:06 pm
Location: Prestonsburg, KY - USA
Contact:

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby DarkLord » Mon Nov 21, 2016 9:26 pm

Does the Pak 68/3 board work the same as the '020 /2 version? Should I try
the latest EmuTOS on my Pak 68/3 board just to see what happens?
Welcome To DarkForce! http://www.darkforce.org "The Fuji Lives.!"
Atari SW/HW based BBS - Telnet:darkforce-bbs.dyndns.org 520

anodyne
Atari maniac
Atari maniac
Posts: 75
Joined: Mon Aug 27, 2007 11:15 pm
Location: Canada
Contact:

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby anodyne » Mon Nov 21, 2016 10:55 pm

Answering Markus: I'm not aware that anyone has tested a 68020 or the PAK with EmuTOS.

Answering Rodolphe: If there's a problem due to coprocessor access, then the problem is caused by the PMOVEs before the MOVECs. If someone needs a customised version, let me know. I would like to get EmuTOS working with the PAK, if at all possible.

rpineau
Atari Super Hero
Atari Super Hero
Posts: 511
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby rpineau » Mon Nov 21, 2016 11:31 pm

Anodyne, I agree with you.
I would say that as a test we should comment this :

Code: Select all

#ifndef __mcoldfire__
        move.l  #not_68030,0x2c    // PMOVE is lineF on non-68030 systems
        PMOVE_TO_TTR0(zero)        // first we initialise the TTRs (ACRs on a 68ec030)
        PMOVE_TO_TTR1(zero)
        move.l  #mmu_done,0x2c     // since PMOVE_TO_TC doesn't exist on a 68ec030,
        PMOVE_TO_TC(zero)          //  we're done if we get a lineF exception ...
        bra.b   mmu_done
not_68030:
        move.l  #mmu_done,0x10     // if a MOVEC causes an exception, we're done
        moveq   #0,d0
        MOVEC_D0_ITT0              // first we initialise the TTRs (ACRs on a 68ec040)
        MOVEC_D0_ITT1
        MOVEC_D0_DTT0
        MOVEC_D0_DTT1
        MOVEC_D0_TC                // disable translation on 68040-60 (will error out
mmu_done:
#endif

and recompile.
Also one thing I do (for myself) is to change the Makefile CPUFLAGS to -m68020
It could be useful to have an option to do this (the same way we set the language with a default of -m68000).
If commenting the above works we might need a #ifndef PAK or something like this to auto comment the code.
Anyway . great job as usual on Emutos :)
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

anodyne
Atari maniac
Atari maniac
Posts: 75
Joined: Mon Aug 27, 2007 11:15 pm
Location: Canada
Contact:

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby anodyne » Mon Nov 21, 2016 11:54 pm

Hi Rodolphe,
Thanks for the EmuTOS comments! If the problem is with the PMOVEs, then I might just rearrange startup.S to avoid the problem. Since there isn't any Atari-manufactured system with a 68020, we might as well make EmuTOS compatible with some de facto standard hardware.

anodyne
Atari maniac
Atari maniac
Posts: 75
Joined: Mon Aug 27, 2007 11:15 pm
Location: Canada
Contact:

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby anodyne » Tue Nov 22, 2016 12:03 am

mfro wrote:
anodyne wrote:... doing a MOVEC with an invalid control register field should cause an illegal instruction exception. MOVEC to ITT0/ITT1/DTT0/DTT1 have control register fields 004/005/006/007 which are illegal on the 68020. So it should trigger an exception, and therefore branch to mmu_done.


Hi Roger,

I assume this has never been tested on an 68020 or on a PAK?

What if the PAK's GAL forwards *all* coprocessor accesses to the MC68881?

I never tested this myself (although I was a proud owner of a PAK like twenty years ago) but could well assume that this case might trigger a coprocessor protocol violation exception (which isn't trapped) instead?

Yes, good point, we don't trap that exception. That would be something else to try - would someone with a PAK who is willing to debug EmuTOS send me an email? We should be able to use EMUTOS.PRG, no need to burn EPROMs.

User avatar
DarkLord
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4256
Joined: Mon Aug 16, 2004 12:06 pm
Location: Prestonsburg, KY - USA
Contact:

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby DarkLord » Tue Nov 22, 2016 8:34 am

E-mail sent.
Welcome To DarkForce! http://www.darkforce.org "The Fuji Lives.!"
Atari SW/HW based BBS - Telnet:darkforce-bbs.dyndns.org 520

User avatar
DarkLord
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4256
Joined: Mon Aug 16, 2004 12:06 pm
Location: Prestonsburg, KY - USA
Contact:

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby DarkLord » Tue Nov 22, 2016 8:37 am

DarkLord wrote:E-mail sent.


Er...just noticed the "debugging" part. I can test it on my Pak equipped
STacy but actual code? Probably not... Just being honest here, don't
want to waste anyone's time.
Welcome To DarkForce! http://www.darkforce.org "The Fuji Lives.!"
Atari SW/HW based BBS - Telnet:darkforce-bbs.dyndns.org 520

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 766
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: EmuTOS do not run with a PAK68/2 Speeder ...

Postby mfro » Tue Nov 22, 2016 5:51 pm

Need to wait for confirmation, but I think the mistery is unravelled.

EmuTOS first checks for an 68030 by setting the transparent translation registers. Failure on that is catched with setting the exception vector for linef to the next test. This one tests for a 020 or ec030 with a pmove to the tc register (this is valid on the 68851). This is as well catched with targetting the linef vector a few instructions below.

Unfortunately, the PAK doesn't seem to correctly decode the coprocessor ID and forwards the instruction to the FPU that can't do anything with it - this ends up (besides strange behaviour, I had scrambled strings in my test program) in an illegal instruction exception (while a linef exception was expected).

As the illegal vector wasn't moved (it's still pointing to the cache test above), we end up with an infinite loop (at least until the exception stack overwrites something important).

If we want to support the PAK in EmuTOS, the illegal instruction vector must move with the linef vector in the sequence of tests.


Social Media

     

Return to “Professionals”

Who is online

Users browsing this forum: No registered users and 7 guests