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

[frank.lukas]

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 ...

[BlankVector]

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.

[frank.lukas]

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 ...

[1st1]

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?

[anodyne]

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]

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]

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...

[1st1]

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.

[1st1]

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.

[rpineau]

@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

[mfro]

@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]

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

[rpineau]

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.

[anodyne]

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]

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

[mfro]

... 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]

We could at least test a version without the write to PMMU (I can recompile it if needed and post it here).

[DarkLord]

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?

[anodyne]

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]

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

[anodyne]

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]

... 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.

[DarkLord]

E-mail sent.

[DarkLord]

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.

[mfro]

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.