192kB EmuTOS in 1MB Eproms ...

[Lukas Frank]

Habe mir Adapter Platinchen machen lassen um ein 192kB TOS in zwei 128kBx8 (1MB) Eproms zu nutzen.

Habe die 192kB EmuTOS Version von dort ->   https://forum.atari-home.de/index.php/topic,14685.0.html

Was kann das sein? Ein Hardware Fehler beim Adapter 28 auf 32 pin?

[Gaga]

Den Fehler hatte ich auch. Versuche mal einen anderen Build. Bei mir hat es geholfen.

[Lukas Frank]

Da ich IDE brauche bin ich ja darauf angewiesen aus den Quellen selbst zu compilieren. Es gibt noch nur die eine Quelle, oder?

Ich lösche am Sonntag mal die Eprom da ich keine mehr habe und brenne mal ein TOS 1.04 um zu schauen ob meine Adapter funktionieren ...

[czietz]

Kannst Du mal exakt das ROM posten, das Du gebrannt hast (oder einen Link auf konkret die Nachricht im Thread, wo ich es mir herunterladen kann)? Dann gucke ich mir das an.

[Lukas Frank]

Das ist die Version die @Thorsten Otto gemacht hat meine ich. Im Anhang ...

Ich wusste nicht wie ich die 192kB in zwei Dateien aufteilen sollte mit dem ROMMIX Paket. Deshalb habe ich das im Brenner Programm gemacht. Zuerst "1st of 2 bytes" und dann "2nd of 2 bytes" ...

[czietz]

Ich will mir die aber nicht irgendwo raussuchen müssen, mit dem Risiko, doch nicht die Datei zu überprüfen, die Du genommen hast. Daher: "Kannst Du mal exakt das ROM posten, das Du gebrannt hast?"

[Lukas Frank]

Alles im Thread vor deinem ->  etos_ide.zip.pdf

[czietz]

In dem genannten File an der genannten Adresse 00FE04BA steht kein Befehl, der eine Line-F-Exception auslösen würde. Vermutung: EPROM nicht mehr gut. Wenn aufgrund eines Fehler im EPROM die oberen vier Bits einer Instruktion als '1111' gelesen werden, gibt es eine Line-F-Exception.

[Lukas Frank]

Das sind 27C1001

Da war zuvor ein EmuTOS 9.91 in der 256kB Version oder so drauf und funktionierte.

Ich habe nur OTP Proms in 27C010, die wollte ich zum Probieren nicht nehmen da zu schade ...

[czietz]

@Thorsten Ottos 192k Image aus dem verlinkten Thread stürzt mir in Hatari an einer ganz anderen Stelle mit einem Address Error ab, weil der Code für sh_curdir(BYTE *ppath) (in gemshlib.c) fragwürdig von gcc compiliert wird:

Code: [Auswählen]

ROM:00FE00D8                 move.l  a2,-(sp)
ROM:00FE00DA                 movea.l 8(sp),a2
ROM:00FE00DE                 jsr     sub_FCD6DC   ; Dgetdrive
ROM:00FE00E4                 move.b  d0,d1
ROM:00FE00E6                 addi.b  #$41,d1
ROM:00FE00EA                 move.b  d1,(a2)
ROM:00FE00EC                 move.w  #$3A00,1(a2)   ; <=== GEFÄHRLICH
ROM:00FE00F2                 pea     2(a2)
ROM:00FE00F6                 addq.w  #1,d0
ROM:00FE00F8                 move.w  d0,-(sp)
ROM:00FE00FA                 jsr     sub_FCD7BC   ; Dgetpath
ROM:00FE0100                 addq.l  #6,sp
ROM:00FE0102                 tst.b   2(a2)
ROM:00FE0106                 bne.s   loc_FE010E
ROM:00FE0108                 move.w  #$5C00,2(a2)
ROM:00FE010E
ROM:00FE010E loc_FE010E:                             ; CODE XREF: ROM:00FE0106j
ROM:00FE010E                 movea.l (sp)+,a2
ROM:00FE0110                 rts

Es stürzt an der markierten Stelle ab, die auf einem 68000 nur funktionieren würde, wenn ppath (=A2) auf eine ungerade Adresse zeigen würde. Ich befürchte, der von Thorsten verwendete gcc mit den von ihm verwendeten Einstellungen erzeugt Code, der nicht für einen 68000 (sondern erst ab 68020?) gedacht ist...

[Thorsten Otto]

Ich befürchte, der von Thorsten verwendete gcc mit den von ihm verwendeten Einstellungen erzeugt Code, der nicht für einen 68000 (sondern erst ab 68020?) gedacht ist...

Oha. Das ist natürlich ungut. Schau ich mir mal an.

[Thorsten Otto]

Argl. Fehler gefunden. Aus irgendeinem mir schleierhaftem Grunde wurde die Überprüfung auf ungerade Addressen abgeschaltet (vermutlich, weil es im linux-port auch so gemacht wird, warum auch immer).

Problem ist nur, wenn ich das rückgängig mache, erzeugt der neue GCC dann wieder mehr Code, der (mit IDE Support) nicht in 192k passt Was u.a. daran liegt, daß gcc dann an vielen Stellen zu pessimistisch ist was das alignment angeht (z.b. wird dann die Sector-Nummer beim Erzeugen eines 10-byte SCSI-Command-Blocks in build_rw_command mit 4 single-byte-stores erzeugt, obwohl sie an einer geraden Addresse liegt).

Es erklärt auch nicht die Line-F Exception aus deinem Beispiel.

Habe dir die US-Version nochmal angehängt wenn du es nochmal probieren willst (ich hoffe mal Deine Eproms sind löschbar Da sind jetzt noch 44 Bytes frei... Die deutsche Version passt wie gesagt jetzt nicht mehr.

[Lukas Frank]

Danke, werde das probieren ...

[Arthur]

@czietz, dein richtiger Name ist nicht zufällig Skynet?

[Lukas Frank]

Hab das teilen jetzt auch mit rommix.ttp hin bekommen ...


-------
# 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 192k
# Directory setzen
chdir c:\rommix\

load etoside.img 0 192k all -> 0 all
save u9.img 96k <- 0 even
save u10.img 96k <- 0 odd

-------
@czietz
@Thorsten Otto

Da ist doch genug Platz in den beiden 128kB Eproms. Geht das nicht ein TOS etwas größer als 192kB zu booten?

[Thorsten Otto]

Da ist doch genug Platz in den beiden 128kB Eproms. Geht das nicht ein TOS etwas größer als 192kB zu booten?

Hm, kA wie da die Address-Dekodierung funktioniert, die kompletten 256k belegen ja auch den Bereich der für I/O-Addressen benutzt wird. Allerdings starten die erst bei $FF8000 ca., wenn das funktionieren sollte, könnte man vlt. die ersten 32k von $FF0000-$FF8000 noch für ROM-Code nutzen. Vlt. kann Christian was dazu sagen? Auf jeden Fall müsste man die Scripts, die das finale emutos.img erzeugen, anpassen, weil die sonst nach 192k abschneiden.

[czietz]

Wenn man schon Hardwareumbauten vornimmt, um dem STF eine neue Adressdekodierung für ROMs zu verpassen, dann doch am besten gleich für die Adresslage von TOS 2.06, also ab 0xE00000 aufwärts. Es ist imho nicht sinnvoll, eine Speziallösung zu entwickeln, um noch einige wenige kB ab 0xFF0000 zu nutzen.

[Lukas Frank]

Habe dir die US-Version nochmal angehängt wenn du es nochmal probieren willst (ich hoffe mal Deine Eproms sind löschbar Da sind jetzt noch 44 Bytes frei... Die deutsche Version passt wie gesagt jetzt nicht mehr.

Das funktioniert und bootet bis zum Desktop allerdings wird das IDE Interface nicht angesprochen !?!

[Arthur]

Frank, hier im Archive sind die Patches von ppera die mit IDE und Twisted IDE funktionieren. Lt. den Infos im Archiv kann man es mit dem HxD-Editor für Windows selber patchen. Sind für 2.06, Kaos1.42, 1,06STe, 1.04ST enthalten. Ich denke die sollten auch mit normalen IDE-Treibern funktionieren wenn kein Twisted-IDE benutzt wird. Habe das aber nicht selbst ausprobiert. Wenn es aber unbedingt EmuTOS sein soll dann kannst du das hier einfach ignorieren.

[Lukas Frank]

czietz hat ein TOS 1.04 für mich mit den ppera Patches gepatcht. Das funktioniert bei mir nicht mit IDE, läuft wie ein normales TOS. Von IDE keine Spur ...