atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: Lukas Frank am Fr 19.10.2018, 18:47:52
-
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?
-
Den Fehler hatte ich auch. Versuche mal einen anderen Build. Bei mir hat es geholfen.
-
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 ...
-
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.
-
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" ...
(https://forum.atari-home.de/index.php?action=dlattach;topic=14728.0;attach=22960;image)
-
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?"
-
Alles im Thread vor deinem -> etos_ide.zip.pdf
-
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.
-
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 ...
-
@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:
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...
-
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.
-
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.
-
Danke, werde das probieren ...
-
@czietz, dein richtiger Name ist nicht zufällig Skynet? >:D :D
-
Hab das teilen jetzt auch mit rommix.ttp hin bekommen ...
-------
# 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 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?
-
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.
-
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.
-
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 !?!
-
Frank, hier im Archive (http://atari.8bitchip.info/TOSIDEP2.ZIP) 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. ;)
-
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 ...
-
Das funktioniert und bootet bis zum Desktop allerdings wird das IDE Interface nicht angesprochen !?!
Von IDE keine Spur
Hm, kann es sein daß das IDE interface aus irgendeinem Grunde nicht erkannt wird? Debug-Ausgaben einzubauen da jetzt noch in den 44 Byte unterzubringen dürfte etwas schwierig werden ;)
-
Ich probiere noch etwas anderes mit den beiden 27C1001 Eproms. Danach nehme ich mal ein auf dem Atari TT mit gcc 7.3.0 erzeugtes EmuTOS US, mal schauen ...
Vielleicht kann das mal jemand mit mehr Ahnung unter Hatari mit einem IDE Image nachvollziehen?
-
Ich probiere noch etwas anderes mit den beiden 27C1001 Eproms. Danach nehme ich mal ein auf dem Atari TT mit gcc 7.3.0 erzeugtes EmuTOS US, mal schauen ...
Vielleicht kann das mal jemand mit mehr Ahnung unter Hatari mit einem IDE Image nachvollziehen?
Schau lieber vorher nach was der für code erzeugt. Sieht so aus als ob der den gleichen bug wie mein cross-compiler hat. Zum testen:
void test(int c, char *p)
{
*p++ = 'A' + c;
*p++ = ':';
*p = '\0';
}
Übersetzen mit
m68k-atari-mint-gcc -O2 -S -o -
Wenn da als Ausgabe sowas rauskommt
_test:
move.l 8(%sp),%a0
move.b 7(%sp),%d0
add.b #65,%d0
move.b %d0,(%a0)
move.w #14848,1(%a0) <-- move.w auf ungerade Addresse
rts
ist der genauso buggy wie der cross-compiler den ich zuerst verwendet hab (ist lokal schon gefixt, aber noch nicht neu hochgeladen)