
Moderators: Mug UK, moondog/.tSCc., [ProToS], lp, Moderator Team
Code: Select all
# Kommandodatei fr ROMMIX:
# erstellen von 4 Eprom-Files fr 27C512
# 1 EmuTOS-IMG wird auf 4 Eproms aufgeteilt
# von Udo Overath @ KR
# (das geht auch direkt mit Pinatubo --- ms)
# Puffergre 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
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 ...
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?
1st1 wrote:For example the combination TOS 1.04 on mainboard and TOS 2.06 on the PAK works fine.
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?
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...
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
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)
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.
rpineau wrote:I check the TOS address decoding in the Pak gal code and it does indeed decode for E00000.
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.
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
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?
DarkLord wrote:E-mail sent.
Users browsing this forum: No registered users and 3 guests