atari-home.de - Foren
Software => Alternative Betriebssysteme => Thema gestartet von: sportingt am So 19.11.2023, 17:51:10
-
Hallo,
habe eine Frage, ob jemand Erfahrungen mit EmuTOS 1.2 in Zusammenhang mit der VOFA ET4000 hat?
VOFA ET4000 CPU-Version ist eingebaut, Autoordner mit Emulator.prg, Xmenu.prg und STA_VDi.PRG vorhanden.
Wenn ich ein Rainbow 192k TOS drin habe bootet der Rechner erfolgreich in den alternativen Videomode der VOFA.
Setzte ich jedoch EmuTOS-ROMs ein geht es nicht mehr.
Ich sehe immer nur die Startmeldung von EmuTOS, dann einen Weißen Reset-Bildschirm, dann wieder die EmuTOS Startmeldung.
Ich habe irgendwo gelesen, dass EmuTOS schon ET4000 Treiber installiert hat und direkt in den alternativen Modus booten soll? Habe dazu jedoch nichts genaues gefunden, und weiß auch nicht, ob dies direkt von den ROMs geht.
Vielleicht weiß einer von euch mehr dazu?
Grüße Thorsten
-
Was siehst Du denn am Ausgang der VGA-Grafikkarte? Denn ja, wenn EmuTOS eine Nova (EDIT: oder Vofa) samt unterstützter Grafikkarte erkennt, erfolgt die komplette Ausgabe des Bootvorgangs bereits auf der externen Grafikkarte.
(Achso: Ich gehe davon aus, dass Du von der 256k-Version von EmuTOS sprichst?)
-
VOFA und keine Nova ...
-
Auf dem Ausgang der Karte sehe ich nichts!
Sieht für mich aus als ob gar kein Signal kommt.
Auf dem Atari Output wie gesagt ein ständiger reboot Vorgang.
Weißer Bildschirm, dann eine Zeile EmuTos 1.2.1 usw.
Die ROMs sind 192k, da der 520ST die 256k ROMs ja nicht adressieren kann.
-
Die 192k-ROMs haben keinen eingebauten Vofa/Nova-Support. Permanent rebooten sollten sie dennoch nicht; vielleicht ist das was anderes (am ST oder den ROMs) kaputt?
-
Geht es mit dem Atari TOS im Mainboard und dem EmuTOS als Programm auf Diskette?
-
Wenn ich Emulator.prg usw im Autoordner deaktiviere läuft der ST mit EmuTos ohne Probleme.
Also denke ich, dass das Gerät und die ROMs ok sein sollten.
Wie kann man denn in Zusammenhang mit dem 192k ROMs dann Treiber für die ET nachstarten, ohne die PRGs für die VOFA zu verwenden , da diese ja scheinbar nicht für EmuTOS geeignet sind?
Mit den Rainbow TOS läuft es ja mit den originalen VOFA Treibern.
-
EmuTOS zusammen mit den Nova Treiber geht normalerweise ohne Probleme. Was für einen Festplattentreiber benutzt du denn? EmuTOS hat einen eingebauten Platten Treiber und braucht sonst keinen.
Im Download Bereich vom EmuTOS gibt es auch eine Programm Version für Diskette oder Platte ...
-
Ich kann aus eigener Erfahrung bestätigen, dass EMULATOR.PRG (und der Rest des Nova/Vofa-VDI) unter EmuTOS ohne Probleme laufen.
-
Gut zu hören!
Vielleicht ist mein System momentan etwas überladen um einfach auf EmuTOS zu wechseln.
Habe den HDDriver noch aktiv und starte momentan dann weiter ins MagiC.
Soweit ich es jetzt verstanden habe. HDDriver deaktivieren, Emulator.Prg usw wieder im Autoordner und dann mal checken ob es läuft?
-
HDDriver stört normalerweise nicht.
Ich würde mal einen neuen AUTO Ordner machen nur mit den drei Nova Treibern drin plus die beiden BIB Files und alle ACCs deaktivieren. Einfach den alten AUTO Ordner in AUT umbenennen ...
-
- Atari Mega ST mit ETOS 1.21 192k Version
- VOFA ET4000 Mega ST Bus Adapter
- Nova VOFA Treiber über Diskette geladen
-
Hallo Frank,
bei mir identisches Szenario auf 520ST...
Neuer Auto Ordner nur Files drin wie auf deinem Screenshot.
Probiert auf C: und A:....
VGA Screen schwarz (kein Signal)
Nach Start des Emulator.PRG aus Auto-Ordner (C: oder A:)
Screenmeldung EmuTOS Version 1.2.1, (Ladegeräusche A:)
restart weißer Screen, Screenmeldung EmuTOS 1.2.1.(Ladegeräusche A:)
usw...
Bei mir läuft es so scheinbar nicht.
Ergänzend wäre anzumerken, dass ich ein gepachtes EmuTOS einsetze, Ich habe ein Startdelay von 2s reingepached, da ich ja von einer physikalischen Platte boote.
(Ultrasatan)
Wenn ich mein TOS 1.04 de reinstecke, gehen beide Konstellationen (A: und C:) sofort.
Weiß momentan nicht, ob sich da noch viel Arbeit reinstecken will, wüßte auch nicht was man da noch weiter probieren könnte?
-
Hänge mal deine EmuTOS Version hier an damit ich damit probieren kann, mal schauen ...
-
Hallo Frank,
anbei mal die Dateien zum verwendeten TOS
Grüße Thorsten
-
Ich kann das schnell ausprobieren weil ich zwei Stück AT29C010A verwende ...
Habe das 192k Image in zwei Dateien Hi/Lo gesplittet und läuft bei mir ohne Probleme. Ich nutze zum Aufteilen das ROMMIX Paket aus dem PINATUBO Paket.
Vielleicht ein Fehler beim Aufteilen in die sechs Bestandteile bei dir?
-
Das Hi0 Rom hat einen Fehler bei mir, die anderen stimmen ...
Ich habe dein ETOS192DE.IMG mit ROMMIX aufgeteilt bei mir.
-
Hi Frank,
mit was für nem Mac-App schaust du dir das an?
Kann das sein, dass das der Zeitdelay-Patch ist? Mit was vergleichst du es denn?
Deine neu gesplitteten ROMs mit meinen hochgeladenen Dateien?
Ich hatte ROMSPLI2.PRG von P. Putnik verwendet. (unter Hatari) Bisher hatte das immer gut funktioniert.
Mit ROMMIX habe ich bisher keine Erfahrung, da ich mich an die Konfiguration der .mix Datei nicht so angetraut hatte.
Grüße Thorsten
-
... mit was für nem Mac-App schaust du dir das an?
Hex Editor 1.2 von RootRise
Kann das sein, dass das der Zeitdelay-Patch ist? Mit was vergleichst du es denn?
Deine neu gesplitteten ROMs mit meinen hochgeladenen Dateien?
Ich hatte ROMSPLI2.PRG von P. Putnik verwendet. (unter Hatari) Bisher hatte das immer gut funktioniert.
Habe deine 192k Image Datei aus Anwort #14 benutzt.
Mit ROMMIX habe ich bisher keine Erfahrung, da ich mich an die Konfiguration der .mix Datei nicht so angetraut hatte.
ROMMIX funktioniert sehr einfach unter TOS 2.06. Einfach die MIX Datei auf das TTP ziehen und loslassen ...
# Kommandodatei fr ROMMIX:
# erstellen von 6 Eprom-Files fr 27256
# 1 TOS-IMG wird auf 6 Eproms aufgeteilt
# (C) 1992 M. Schwingen
# Puffergre setzen
bufsize 64k
# Directory setzen
chdir c:\rommix
load etos192.img 0 64k all -> 0 all
save romh0.u4 32k <- 0 high
save roml0.u7 32k <- 0 low
load etos192.img 64k 64k all -> 0 all
save romh1.u3 32k <- 0 high
save roml1.u6 32k <- 0 low
load etos192.img 128k 64k all -> 0 all
save romh2.u2 32k <- 0 high
save roml2.u5 32k <- 0 low
-
nochmal überprüft mit diff im Terminal, diff meckert bei HI0 ...
-
nochmal überprüft mit diff im Terminal, diff meckert bei HI0 ...
Ja, weil @sportingt doch das Bootdelay konfiguriert hat, wie er selbst anmerkt!
-
... dann ist sein 192k Image in Antwort #14 nicht sein gepatchtes.
-
Hallo,
hatte glaube ich das falsche Image hochgeladen.
Habe es jetzt mit ROMMIX gesplittet.
Bei mir taucht auch eine 03 auf wie bei der alten HI0-ROM Datei.
Ich glaube ich hatte den Delay auch auf 3s nicht wie oben beschrieben 2s gepachtet.
Wahrscheinlich ist es 03 für 3s.
Kannst ja vielleicht noch mal probieren.
-
Kann ja mal dein gepatchtes 192k Image für meinen Mega ST in zwei Teile aufteilen und nochmal damit probieren morgen ...
Wüsste jetzt aber nicht wo der Unterschied zwischen Mega ST und 520ST sein soll. Einen Blitter hat mein Mega ST nicht mehr. Die VOFA Versionen sind absolut gleich weil ich beim Layout den gleichen Eagle Schaltplan benutzt habe. Der Unterschied zwischen Mega ST und 520ST ist nur das Platinenlayout und die unterschiedlichen Pullup Widerstände aber das liegt am Layout der Platinen und man kann die VOFA mit HCT245 oder F245 betreiben ...
-
Bei mir geht es ohne Probleme mit dem Image aus Beitrag #22
Hatte einen Reset beim Laden von STA_VDI wegen den Netzteil einem alten 250W AT Netzteil wahrscheinlich wegen zu langem Kabel und zu geringer Last, mit dem original Mega ST Netzteil gab es keine Probleme. Mehrmals probiert. Vielleicht bei dir ein Problem mit deinem Netzteil so das die Spannung nicht stabil ist. Die 260/520 Netzteile sind mehr als 30 Jahre alt und haben noch Transformatoren mit Spannungsregler. Kannst ja mal die 5 Volt Spannung messen wenn alles dran hängt ...
Ansonsten hat die VOFA eine 1N4148 Diode D2 welche nicht bestückt wird. Eventuell einen Jumper JP2 ...
1-2 = BG
2-3 = BGACK
... wahlweise verbunden mit dem Pin5 vom GAL IC5.
-
Hallo Frank,
mein Atari Netzteil hatte schon lange den Geist aufgegeben.
Nutze seitdem ein modernes Netzteil von Cisco.
Habe mal gemessen. Das Netzteil liefert 4,95V. An der VOFA liegen 4,85V an.
Auch wenn es nichts ausmachen sollte habe ich es mit der Tos 1.04 und EmuTOS getestet.
In beiden Fällen ist die Spannung gleich. Da es ja alles mit TOS 1.04 läuft und nur das EmuTOS nicht funktioniert vermute ich, dass es irgendwie mit dem TOS zusammenhängt. Ich werde bei Zeiten mal ein TOS mit Delay von 2s und 1s brennen. 0s hatte ich schon, da bootet meine Ultrasatan nur mit externer Spannungsversorgung. Geht in meiner Konstellation dann nicht.
Brauche ein paar Tage bis ich dazu komme. Gebe dann noch Feedback.
-
Teste doch mal mit der original 1.21 Version. Wenn die SD Karte nicht bootet reicht doch ein Reset, oder nicht?
-
Vielleicht kannst Du, @Lukas Frank ja das VDI, also die Versionen von EMULATOR und Co., mit denen Du erfolgreich testest, zur Verfügung stellen.
-
Habe eine Grafikkarte die mit dem T8 Treiber läuft ...
-
Ich habe gerade getestet: VOFA in einem 1040STf, mit einer T8-Grafikkarte, EmuTOS 1.2.1 192k aus dem Post #22 und dem VDI aus Post #28: Läuft!
-
Ja bei mir mit dem Mega ST läuft es ja auch.
Vermute auch mal es spielt keine Rolle welche T Version was den DAC angeht ...
... die VOFA eine 1N4148 Diode D2 welche nicht bestückt wird. Eventuell einen Jumper JP2 ...
1-2 = BG
2-3 = BGACK
... wahlweise verbunden mit dem Pin5 vom GAL IC5.
@sportingt ... wie ist das bei dir mit D2 und dem Jumper?
-
Hallo,
da bin ich jetzt raus? D2 ist bei mir leer.
Das mit dem Jumper hab ich nicht verstanden.
Wo soll der Jumper hin und was soll das dann bringen?
-
D2 wird nicht bestückt, das ist richtig.
Wenn du keinen JP2 hast auf deiner Platine und auch keinen anderen Jumper ist alles gut.
-
Hallo,
zwischendurch ein kleines Update. Ich habe mir mehrere Hi0 ROMs gemacht.
ohne Delay
1s
2s
3s war es bisher.
In keinem Fall geht es.
Treiber aus #28
probiert, geht auch nicht.
Werde es noch weiter testen. Update folgt....
P.S.
Interessanterweise bringt das Programm VOFATEST.TOS
mit dem ATARI TOS 1.04de keinen Fehler, während es unter EmuTOS für FEAT-Register einen Error bringt.
In der Treiberwelt stecke ich jetzt auch nicht so drin. Weiß jemand was ein FEAT-Register ist und worauf der Unterschied zurückzuführen sein könnte?
Vielleicht ist die ET4000 auch nicht 100% io?
-
Schau mal in das TSENG ET4000 PDF ...
Feature Control Register
This is a read/write register.
R/W : Port address = 3CA input; 3BA/3DA output
Bit Description
0 Feat (01
1 Feat (11
2 Reserved
3 Reserved
4 Reserved
5 Reserved.
6 Reserved
7 Enable NMI generation
NOTE: The "KEY" must be set in order to read bit 7. See Input Status Register
Zero for definition of "KEY".
Bits 0,1 are Feat(OI and Feat(ll bits from the Feature Connector.
Bit 7, when set to 1, enables a non-maskable interrupt (NMII. This bit can only
be set when in 6845 compatibility mode (CRTC 34 bit 7 = 11.
Normally, the XROML output pin is defined as external translation ROM enable. When
bit 7 of the Feature Control Register is set to 1, the XROML output will be defined
as the NMI output pin (See Section 2.2.61. This bit can only be set if the 6845 emulation
mode is active.
-
@sportingt ... lass mal YAART eine ganze Zeit laufen.
https://www.chzsoft.de/site/hardware/diverse-kleinigkeiten-fur-den-atari-st/#ram-test-software-yaart
-
Habe YAART über 50 Durchläufe machen lassen. Error 0
-
Lass mal schauen was an dem Nova Treiber nicht läuft unter EmuTOS bei dir ...
Starte mal nur das Emulator Programm manuell oder nur das im AUTO Ordner alleine. An Fehlermeldung kann da kommen "zu alte Nova Version" oder es gibt zwei Bomben über den System Monitor, also wenn es geht mit zwei Monitoren arbeiten. Ich meine ich hatte es auch schon mal das unbedingt ein Monitor oder Dummy Adapter auf ST-Hoch am System Monitoranschluss stecken musste.
-
Hallo Frank,
anbei ein Screenshot, wenn ich das Programm direkt manuell starte.
Die Emulator.PRG starten, dann wird die Meldung aus Screenshot angezeigt, danach wird wieder ins Desktop gewechselt.
Das geht so schnell, dass ich den Screenshot nur aus einem Slomo-Video rausbekommen habe.
Wenn ich aus dem Auto-Ordner starte, wird gar keine Meldung angezeigt. (Auch mit Solo nicht erkennbar) Wie ganz am Anfang beschrieben. Sobald der Emulator.prg geladen wird, kommt es zu einem Blackscreen und einem Reboot(Reset) in Endlosschleife.
-
... meine ich hatte es auch schon mal das unbedingt ein Monitor oder Dummy Adapter auf ST-Hoch am System Monitoranschluss stecken musste.
Habe den Fehler ...
Bei mir kommt es auch zu einem Reset beim Laufen vom Emulator Programm aber nur wenn unter EmuTOS die Systemauflösung ST-Gering ist !!!!!!!!!!!
Das Problem gibt es ja unter einem Atari TOS nicht. @czietz kann vielleicht was dazu sagen weil am Nova Treiber scheint es ja nicht zu liegen!?!
@sporniket ... du brauchst einen System Monitor oder Dummy Stecker mit Konfiguration auf ST-Hoch. Als Test stecke mal eineen dicken Draht in die System Moniorbuchse zwischen den Pins 13 (GND) und Pin 4 (Mono detect) ...
-
Guten Abend Frank,
jetzt haben wir die Ursache und Lösung!
Ja ich hatte immer einen ST-Gering Monitor dran.
Ich habe jetzt einfach einen ATARI/VGA Adapter reingesteckt. und den auf hohe Auflösung geschaltet.
Es ging sofort.
Echt doof. Normal arbeite ich fast immer mit ST-hoch. Hatte aus Platzgründen, nur einen Monitor am Tisch,
Um zwei Eingänge zu nutzen, einmal Video in, um den Bootvorgang zu sehen, und an der VOFA den VGA Eingang.
Wäre nie auf die Idee gekommen, dass EmuTOS mit geringer Auflösung nicht den Treiber korrekt starten.
Habe das in der EmuTOS doku nicht gelesen oder überlesen. Kleine Ursache, große Wirkung.
Danke Frank für die Übergangslösung!
Vielleicht gibt es dazu ja auch noch eine Erklärung, warum das EmuTOS dazu eine hohe Auflösung braucht, das ATARI TOS jedoch mit beiden Auflösungen die Emulator.PRG korrekt ausführt.
und Grüße an alle Beteiligten.
Thorsten
-
Danke Euch beiden fürs Eingrenzen des Fehlers. Ich gucke mir an, was EmuTOS hier macht. (Aufgrund meiner Todo-Liste wirds aber ein bisschen dauern. )
-
Ich habe bereits eine ziemlich fundierte Idee, woran es liegt und eine potenzielle Lösung. Allerdings kann ich heute Abend nicht testen. @Lukas Frank oder @sportingt : Möchte einer von Euch eine vermutlich gefixte EmuTOS-192k-Version testen? (Sonst mache ich das, aber halt eventuell erst in einigen Tagen.)
-
Ja hänge die mal hier an oder einen Link ...
-
Ja hänge die mal hier an oder einen Link ...
Danke. Siehe Anhang.
-
Heute nicht mehr, habe ganz schlimme Männergrippe oder Corana. Bin ja fünfmal geimpft und auch gegen Grippe, es geht mir dreckisch ....
-
@czietz ... funktioniert.
Sehr schön, wo war denn das Problem?
-
Danke für den Test. Ich werde den Fix voraussichtlich in den nächsten Tagen in die offiziellen EmuTOS-Sourcen einbauen.
Was war der Fehler? Zusammengefasst: Das EMULATOR.PRG von Nova-VDI schaltet TOS (per Setscreen XBIOS-Call) immer in den Monochrom-Modus. Falls ein Farbmonitor angeschlossen ist, schaltet es per direktem Hardwarezugriff kurz darauf Shifter und Glue zurück in den Farbmodus. Ich denke, das passiert, damit die TOS-internen Variablen auf 640x400x2 gestellt werden.
Nun gibt es - sowohl in Atari TOS als auch in EmuTOS - eine Erkennung in jedem Vertical-Blank-Interrupt, ob die Einstellung des Shifters zum angeschlossenen Monitor passt, um sonst durch den Reset zu gehen. (Das schützt Festfrequenz-Röhrenmonitore.) EmuTOS erkennt schon bevor das Nova-VDI den Shifter wieder zurückstellt, dass etwas nicht stimmt und löst eben den Reset aus.
Nun ist diese Erkennung kurzzeitig blockiert, so wie es in Atari TOS auch implementiert ist.
-
Sollte Idek dann die Atari ST und Mega STE Nova Treiber anpassen? Beim Atari Falcon und beim Atari TT gibt es das Problem ja nicht vermute ich? Und macht das dann Probleme unter einem Atari TOS?
Bei mir steht es unter 256 Farben auf Mittel siehe das Bild unter Atari TOS ...
-
Es gibt ein kleines Restrisiko eines Resets auch unter Atari TOS, nachdem der VBL von TOS wieder entsperrt wurde und bevor EMULATOR.PRG den Shifter wieder auf Farbmodus zurücksetzt. Insofern wäre es vermutlich sicherer, wenn das Nova-VDI den VBL sperren würde, bis der Shifter zurückgesetzt ist.
Aber da der EMULATOR.PRG unter Atari TOS in der Praxis nicht abstürzt, sollte er es unter EmuTOS auch nicht tun. Entsprechend werde ich den gefundenen und von Dir bestätigten Fix wie versprochen einbauen.
-
Oh, ich habe die Rückmeldung vergessen.
In EmuTOS-Snapshot 20231214-174428-bb217bd4 (https://sourceforge.net/projects/emutos/files/snapshots/) und allen neueren Snapshots ist der Fix enthalten.
Danke, @sportingt und @Lukas Frank fürs Melden und Testen!