atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: Atariosimus am Do 30.08.2018, 23:27:36
-
Ich habe ein paar Verständnisfragen zu FTOS bzw. zum Hin- und Herschalten von mehreren
Betriebssystemen.
1) Ist die Platine von Lynxman auch für den Mega STE nutzbar und
notfalls rückbaubar?
https://forum.atari-home.de/index.php/topic,13680.msg219046.html#msg219046 (https://forum.atari-home.de/index.php/topic,13680.msg219046.html#msg219046)
2) Nach dem Prinzip von PP sind noch 3 Schalter nötig. Einer als Schreibschutz
und die anderen 2 um zwischen den TOS Versionen auf den Flash Speichern herum zu switchen?
Prinzip habe ich unten nochmal rangehängt allerdings ohne GAL sondern diskret ausgeführt.
Wo sind diese Schalter bei Lynxman später zu finden?
3) Wenn man die Flash Speicher in die Romsockel einsetzt, wie schafft man es den Rechner
zum Laufen zu bringen. Die Speicher sind ja erstmal leer. Ist da eine Startdiskette notwendig?
4) czietz hat ja eine sehr elegante Lösung dargestellt. Da wird der gesamte Prozessor in die neue
Platine eingesetzt und diese in den Prozessorsockel es wird per Software mittels
Supervisormodus zwischen den Versionen geswitched.
Auch hier die Frage wie man das Teil überhaupt startet.
Gibt es dazu einen Schaltplan und das Programm oder läuft das unter Patentschutz?
https://forum.atari-home.de/index.php/topic,13421.0.html (https://forum.atari-home.de/index.php/topic,13421.0.html)
5) Ist das Flashprogramm von PP für beide Lösungen uneingeschränkt einsetzbar?
Also die von Lynxman/PP und czietz.
Das Flashprogramm findet man auf dieser Seite:
http://atari.8bitchip.info/flashest.php (http://atari.8bitchip.info/flashest.php)
6) Es gibt im Netz eine Lösung ohne Flash mit normalen EPROMs auf die 4 Betriebssysteme
dauerhaft gebrannt werden und die mit zwei Schaltern bedient werden.
Das ist extrem simpel aufgebaut.
Hat diese Version schon mal jemand gebaut?
http://atari4ever.free.fr/hardware/tos.html (http://atari4ever.free.fr/hardware/tos.html)
Gemeint ist 4TOS_SWC.ZIP
-
Es gibt eine erweiterte Version dieser Schaltung, die mit einem GAL gemacht ist.
Das GAL übernimmt dabei die Funktion der Logik-Gatter die in dem Schaltplan eingezeichnet sind. Die Funktion ist folgende:
- DTACK erzeugen beim schreiben in den ROM-Bereich ab E00000, zum Flashen
- Enable-Signal erzeugen für beide ROM-Bereiche (FC0000 + E00000) damit man sowohl TOS 1.04 als auch 2.06 in den gleichen ROMs betreiben kann. Die Funktion ist die gleiche, ob man nun TTL oder GAL dafür nimmt.
In der erweiterten Version übernimmt ein kleiner ATtiny Microcontroller die Funktion der DIP-Schalter, so das die ganze Schaltung mit einem einzelnen Taster bedient werden kann und über eine Duo-LED (oder zwei einzelne) etwas anzeigen kann.
zu 3. :
Die Flash Chips müssen vorher schon mit einem Funktionierenden System beschrieben werden, sonst startet der Rechner garnicht.
zu 6:
Diese einfache Variante verzichtet auf die DTACK-Erzeugung, daher kann man nur ein TOS verwenden, das der Atari auch in dem Adressbereich anspricht. Mit dieser Schaltung wäre es z.b. nicht möglich in einen einfachen ST ein TOS 2.06 einzubauen, weil der ST ja nur im ROM-Bereich für 1.0x die passenden Signale erzeugt.
-
Ah, das bringt endlich mal Licht ins Dunkel. Danke SolderGirl.
Ideal wäre die Umschaltung per Auswahlmenü ähnlich wie bei Mid und Low Resolution.
Sobald man eine bestimmte Tos Version geklickt hat bootet der Rechner mit der gewählten
Version. Ob das allerdings so umsetzbar ist weiß ich nicht. czietz ist da ja nah dran.
zu 3) Ich hab leider nirgends eine Beschreibung gefunden wie die Flash Speicher
vorher beschrieben werden.
Ich hätte es mit einem Juniorprommer oder was ähnlichem versucht.
Zu 6) In einem Mega STE geht das ja zum Glück wenn ich den Urheber der Schaltung
richtig verstanden habe. Die Rombereiche werden durch 2 Schalter eingestellt.
Was ja auch PP so macht ein weiterer dient als Schreibschutz.
-
zu 3) Ich hab leider nirgends eine Beschreibung gefunden wie die Flash Speicher
vorher beschrieben werden.
Ich hätte es mit einem Juniorprommer oder was ähnlichem versucht.
Im Prinzip mit jedem Gerät, das die Chips schreiben kann. Man muss nur die Images passend machen, also aufgeteilt in High- und Low-Byte. Und wenn man mehrere auf einmal schreiben will, müssen die halt dementsprechend zusammengesetzt sein. Ich glaub es gibt Programme dafür.
Zu 6) In einem Mega STE geht das ja zum Glück wenn ich den Urheber der Schaltung
richtig verstanden habe. Die Rombereiche werden durch 2 Schalter eingestellt.
Was ja auch PP so macht ein weiterer dient als Schreibschutz.
Die Schalter sind nur dazu da, die Flash Chips in jeweils 4 Bänke auftuteilen. Dafür werden die Schalter einfach mit den obersten Adressbits des Flash verbunden. Damit der Rechner den Flash in beiden ROM-Bereichen "sieht", muss man zwei Dinge machen:
Sobald ein Zugriff auf den entsprechenden Bereich passiert, die Chips aktivieren damit sie Daten liefern, und die DTACK-Leitung auf 0/Masse ziehen, damit es keine Bomben gibt.
Und wenn man z.B. TOS 1.04 und TOS 2.06 umschaltbar haben will, dann müssen die Chips in beiden Adressbereichen eingeblendet werden.
Das heißt, DTACK und das aktivieren der Chips (CE-Signal) Muss sowohl bei Zugriffen auf FC0000 ... als auch bei E00000 passieren. Das ist halt am einfachsten mit einem GAL zu machen, aber natürlich auch mit ein paar TTL-Chips möglich.
PS:
So eine Umschaltung in Software zu machen geht vermutlich auf mehrere Arten.
Spontan kommt mir da der Gedanke ein Latch, also im Prinzip ein paar Flip-Flops zu benutzen, und das an einer ganz bestimmten Adresse in den Speicher einzublenden, die vom Atari sonst nicht genutzt wird. Dafür würde sich z.B. F0FFFF anbieten, das liegt innerhalb des Bereichs der vom c't-IDE Adapter zwar belegt, aber nicht genutzt wird. Sobald jetzt ein Schreibzugriff an genau diese Adresse passiert, gibt man das Signal einmal auf DTACK und gleichzeitig auf den Trigger des Latch, so das der ein paar Bit vom Datenbus speichert. Die Ausgänge des Latch verbindet man dann mit den Adresspins der Flash-Chips, an Stelle der Schalter. Man müsste dann natürlich noch den Rechner von Hand resetten, oder den Reset irgendwie automatisch machen. Das müsste aber theoretisch auch in Software gehen.
Der einzige Nachteil daran ist, das man viele TTL-Gatter oder GAL-Pins braucht, um genau eine einzelne Adresse zu bestimmen. Dafür muss man wirklich alle 24 Adressleitungen der CPU abfragen.
Wie Lynxman das auf seiner Platine gemacht hat kann ich aus den Bildern nicht sagen.
-
Die Schwierigkeit finde ich besteht eigentlich darin, zu erkennen wie das Zusammenspiel
der ganzen Anschlüsse funktioniert. Und dann noch die Adressbereiche.
Das die ROMs des Betriebssystems in Lo und Hi unterteilt ist muß man auch erst mal
verstehen.
Also ich schicke was rein und es soll was sinnvolles rauskommen. Mit KV
Tabellen kann man das zum Beispiel im Anschluß gut minimieren. Dazu muß man
aber erstmal wissen was in so einer Logiktabelle stehen soll. Abgesehen
davon ist das Timing auch ein Faktor der beachtet werden muß.
Ich finde es immer wieder faszinierend mit ein paar Datenleitungen so was hinzubekommen.
-
Man müsste dann natürlich noch den Rechner von Hand resetten, oder den Reset irgendwie automatisch machen. Das müsste aber theoretisch auch in Software gehen.
Der einzige Nachteil daran ist, das man viele TTL-Gatter oder GAL-Pins braucht, um genau eine einzelne Adresse zu bestimmen. Dafür muss man wirklich alle 24 Adressleitungen der CPU abfragen.
Zum Resetten würde es vielleicht reichen ein paar Bomben zu werfen 8).
Aber ich glaube ich hatte auch schon Programme die den Rechner neu booten liessen,
wenn man die anklickte.
So spontan würde ich mich für eine Schaltung eines Userports entscheiden. Da wurden ja einige
sogar mit Software veröffentlicht. Diese entsprechend angepasst und das wars dann.
-
Einige Anmerkungen:
Das Flash-TOS von Lynxman, das ich habe, verwendet nur einen einzigen Taster, den man länger drücken muss, um das TOS umzuschalten. Entsprechend habe ich es mit dem Reset-Taster verbunden und kann durch langes Drücken von Reset die TOS-Version wechseln. Kein weiterer Taster zu montieren, Gehäuse bleibt unmodifiziert.
Mein Flash-TOS im STE reagiert mittels CPLD tatsächlich auf bestimmte Adressen, um eine Umschaltung per Softwaremenü zu ermöglichen. Es würde im Mega-STE aber nicht funktionieren, da der Blitter auf das ROM zugreifen können muss, was im MSTE nicht geht, wenn die Platine im CPU-Sockel steckt.
Das Flash-Programm von PP funktioniert auch mit Lynxmans und meinen Flash-TOS-Lösungen. Allerdings ist das Programm (wie auch andere Software von PP) fehlerhaft und ungepflegt, weshalb ich meine eigene Flash-Software geschrieben habe. @Lynxman wollte sie gründlich testen, daher habe ich sie nicht veröffentlicht.
-
Das Flash-TOS von Lynxman, das ich habe, verwendet nur einen einzigen Taster, den man länger drücken muss, um das TOS umzuschalten. Entsprechend habe ich es mit dem Reset-Taster verbunden und kann durch langes Drücken von Reset die TOS-Version wechseln. Kein weiterer Taster zu montieren, Gehäuse bleibt unmodifiziert.
Das ist wirklich sehr geschickt. Gibt es dazu einen Schaltplan? Ich bräuchte einen 4 mal Umschalter.
Gussoin hat bei dem Monitor Adapter so was ähnliches. Da wir nur per Minitaster d8e Lautstärke
durch Drûcken verändert. So was in der Art müsste es sein.
Es würde im Mega-STE aber nicht funktionieren, da der Blitter auf das ROM zugreifen können muss, was im MSTE nicht geht, wenn die Platine im CPU-Sockel steckt.
Hat denn der STE nicht auch einen Blitter oder nimmst Du die Platine in dem Fall immer raus?
Versteh ich leider nicht ganz ???
Das Flash-Programm von PP funktioniert auch mit Lynxmans und meinen Flash-TOS-Lösungen. Allerdings ist das Programm (wie auch andere Software von PP) fehlerhaft und ungepflegt, weshalb ich meine eigene Flash-Software geschrieben habe. @Lynxman wollte sie gründlich testen, daher habe ich sie nicht veröffentlicht.
Upps, fehlerhaft? Wo macht sich denn das speziell bemerkbar oder ist der Fehler
für Normalanwender nicht relevant?
-
Das ist wirklich sehr geschickt. Gibt es dazu einen Schaltplan?
Mir gefällt die Lösung auch. Nach einem Schaltplan aber musst Du Lynxman fragen. Letztlich ist da irgendein kleiner (ATTiny?) Mikrocontroller drauf, der den Taster auswertet, die obersten Adresspins der Flash-ROMs umschaltet und sich die letzte Einstellung merkt.
Es würde im Mega-STE aber nicht funktionieren, da der Blitter auf das ROM zugreifen können muss, was im MSTE nicht geht, wenn die Platine im CPU-Sockel steckt.
Hat denn der STE nicht auch einen Blitter oder nimmst Du die Platine in dem Fall immer raus?
Versteh ich leider nicht ganz ???
Im STE ist das kein Problem, nur im MegaSTE wegen der zusätzlichen Hardware, die für Cache und 16 MHz zwischen CPU und Systembus ist.
Upps, fehlerhaft? Wo macht sich denn das speziell bemerkbar oder ist der Fehler
für Normalanwender nicht relevant?
Offensichtlichster Bug: Manche Flashbausteine lassen sich einfach nicht flashen. Siehe z.B. diesen Thread: https://forum.atari-home.de/index.php/topic,13494.msg218610.html#msg218610
Und diverse Buttons in der GUI sind ohne Funktion. OK, letzteres ist kein Bug, die Entwicklung wurde einfach nicht abgeschlossen.
-
Dann hoffe ich, das Lynxman Dein Programm bald testet um auf PPs
nicht mehr angewiesen sein zu müssen ;D
Für den MegaSTE wäre somit eine Kombination mit einem ATTiny sowie die
Umschaltung mit nicht flashbaren ROMs wohl das Beste. So sind
tiefere Eingriffe nicht nötig und man steckt einfach nur die Platine/n in die ROM Sockel.
Auf Software zum Umschalten muß man halt verzichten. Wäre aber mit der ATTiny
Lösung dann sowieso nicht sehr tragisch. Quasi nur eine Leitung am Resetknopf anbringen
um den Umschaltimpuls auszulösen. Das dürfte auch universell einsetzbar sein und
jederzeit rückbaubar. Flashroms sind dann nur für Entwickler wirklich sinnvoll.
-
In diesem Paket sind die Schaltpläne und Layouts enthalten, auch die Firmware für den ATtiny ist dabei:
http://atari.8bitchip.info/FlashableTOSx4.rar (http://atari.8bitchip.info/FlashableTOSx4.rar)
PS: Die Funktion ist hier so, man hat einen Taster, durch kurzes Drücken schaltet man von einer Bank zur nächsten. Lange drücken hebt den Schreibschutz auf, ist also nur zum Flashen wichtig.
Die Duo-LED zeigt normal die Bank an, also Rot, Gelb, Grün oder aus.
Wenn man die Bank gewechselt hat, muss man ca 2 Sekunden warten, dann blinkt die LED kurz und dann hat er die neue Bank gespeichert. Dann ein Reset und das andere TOS bootet.
Wenn man den Schreibschutz aufhebt, blinkt die LED rot und man kann ein neues TOS Flashen.
Allerdings funktioniert das bei mir nicht richtig, beim Schreiben kommt immer nur eine Fehlermeldung.
Leider bootet das TOS 1.04 bei mir nichtmehr, vermutlich wegen der CF-Karte. Dazu hab ich TOS 2.06 und EmuTOS, die funktionieren beide. Und in der vierten Bank ist ein System drin das ich nicht kenne, und das einen "offscreen-Treiber" laden will den es nicht findet.
Die Funktion wird man sicher nicht sehr oft brauchen, das ist klar. Ist ja auch bei modernen PCs so, da hat man ein Flash als BIOS, aber wie oft macht man schon ein BIOS-Update?
Aber EmuTOS wird ja noch weiter entwickelt, und ppera arbeitet an modifizierten/gefixten Versionen von TOS 1.04 / 2.06. Für sowas ist es dann doch ganz praktisch. Auch wenn man es nur alle Schaltjahre mal braucht, ist es doch ganz praktisch wenn man die Möglichkeit hat ein neues TOS zu flashen ohne den Rechner aufmachen zu müssen.
-
Vielen Dank SolderGirl :D
-
Ich möchte mir nach dieser Anleitung 4 Betriebssysteme einbauen
http://www.tehkella.net/retro/?p=257 (http://www.tehkella.net/retro/?p=257)
Meine Frage ist, ob man ein TOS 1.04 auch nehmen kann?
Mit TOS 1.0 geht es laut Autor jedenfalls nicht, da es an einer anderen Startadresse beginnt.
Ideale Kombination für mich wäre TOS 1.02/1.04/1.62/2.06 alle in 2 Roms gebrannt und
umschaltbar.
Zusatzfrage mit welchem TOS deckt man die meißten Spiele ab um Inkompatibilitaten
zu vermeiden?
-
Der Artikel bezieht sich doch auf einen STE und da läuft alles kleiner TOS 1.06 nicht.
-
Wirklich ein schönes Bild nur was soll mir das jetzt sagen?
-
Nichts, ich musste etwas ausprobieren ...
-
... mit welchem TOS deckt man die meißten Spiele ab um Inkompatibilitaten
zu vermeiden?
TOS 1.04 würde ich jetzt sagen.
-
Vezzelli schreibt in seiner Anleitung:
Why not TOS 1.0?
----------------
TOS 1.0 is 192K in size, and located at $FC00000, while TOS 1.6 and upper
are 256K in size and located at $E000000.
The size is not a problem, but the different location is a BIG problem.
The tos should be relocated, and currently I haven't found how to do it.
Ich möchte stattdessen TOS 1.04 nehmen. Habe ich da die selben Probleme?
Die Größe ist auch 192K mit der Startadresse $FC00000.
-
Ja
TOS 1.0 = 1.02 = 1.04 immer die gleiche Startadresse
-
Jetzt wäre die Frage wie man das trotzdem hinbekommt. Bei den Flash Versionen
scheint das ja alles zu gehen.
Wenn man das 1.04 einfach auf 256K ausdehnt bis zur
Startadresse $E000000...oder einen Sprungbefehl einbauen...keine Ahnung. :(
Ideal wäre TOS 1.02/1.04/1.62/2.06
Hier fehlt jetzt ein guter "Brennmeister"
-
Wozu ? Einfach flashen und gut, da FC eh über ROM2 decodiert wird. D.h. dem Decoder ist das egal der wird auf beide Adressbereiche angesprochen. D.h. eigentlich vollkommen egal welches TOS du da rein packst.
-
So dachte ich das eigentlich auch aber Vezzelli hatte damit Probleme.
Why not TOS 1.0?
----------------
TOS 1.0 is 192K in size, and located at $FC00000, while TOS 1.6 and upper
are 256K in size and located at $E000000.
The size is not a problem, but the different location is a BIG problem.
The tos should be relocated, and currently I haven't found how to do it.
ROMS
$E00000 Start of ROM OS (for version 1.4 and above)
$FC0000 Start of ROM OS (for versions below 1.4)
http://www.atari-forum.com/viewtopic.php?f=74&t=14341 (http://www.atari-forum.com/viewtopic.php?f=74&t=14341)
Da steht TOS versions usable with project: 1.00, 1.02, 1.04, 2.05 (not recommended) , 2.06 . Kaos TOS, Magic , + ?
Not good: 1.06 - it is STE only.
Bei PP gings zumindest, wenn man seine Hardware grob vergleicht.
Hab jetzt mal 2 EPROMS 120ns mit der
Herstellernummer: M27C4001-10F1 (wahrscheinlich NEC)
bestellt. Die entsprechen 27C040
-
Programming the Eproms
----------------------
You need some practice with your eprom programming software for this.
Select 4mbit eprom type, then load 'LO' part of first tos at address 00000.
Then load 'LO' part of the second tos at address 20000. Third TOS will go
at 40000, fourth at 60000. Then program the 4mbit 'LO' eprom.
Do the same (keep same TOS order!!) for the 'HI' part.
Ich versuche mal eine Probe mit deutschem TOS herzustellen nach obigem Rezept um diese
später zu brennen sobald die Bauteile da sind.
Eventuell kann man da schon Kardinalfehler korrigieren.
-
Ich habe jetzt die TOS Versionen in 2 Teile gesplittet also 1.02/1.04/1.62/2.06
Als Tool wurde ROMSPLI2.PRG von Pera Putnik verwendet. Sehr einfach zu bedienen.
http://atari.8bitchip.info/astopensw.php (http://atari.8bitchip.info/astopensw.php)
Putnik schreibt: ...when split some older TOS with len. of $30000 into 2 parts, we still get
2 files of $20000 (128KB) length, just end of files is unused, irrelevant.
EPROM programmers may expect full filelengths for chips, so like this is best.
Hoffe das das dann so läuft. Nächster Schritt ist die Hi und Lo Teile zusammen zu fügen,
so dass 2 große Files von jeweils 512KB für Hi und Lo entstehen.
Die Quad Dateien für Hi und Lo sind jetzt fertig siehe Anhang. Fehlen nur noch die EPROMs.
Da diese Kombination auf dem MegaSte nicht funktionierte habe ich sie wieder entfernt.
-
Mit Snapshot die Hexdatei geknippst.
Darauf sind die Einstellung erkennbar.
Das 2te Bild zeigt das Ende des ROMs an.
Das 3te Bild soll den freien Platz zwischen 2 ROMs veranschaulichen.
-
Die EPROMs sind da. Das Brennen dauert. Musste zuerst diese mit UV Licht löschen.
Jetzt liegt eine im Grill und nach einer halben Stunde sind gerade Mal ca.5% gebrannt.
-
Kennt jemand eine einfache Schaltung um mit einem einzigen Schalter 4 Schaltzustände zu
erreichen?
-
Dürfen es auch zwei sein?:
http://phoenix.inf.upol.cz/~opichals/libhyp/hypview.cgi?url=http://www.newtosworld.de/dmdocuments/CHIPS_X.HYP&index=843
-
ich dachte eher an etwas filigraneres ;D
Natürlich kann man es mit einem Tiny8 machen.
Mit einem 4066 und einem Hochzähler müsste so was umsetzbar sein.
D.h. man drückt nur auf einen Schalter einmal oder mehrmals.
Diesen könnte man mit dem Resetschalter verbinden.
Vorteil keine Bohrung im Gehäuse und keine extra Schalter.
-
Erster Chip ist nach ca. 6 Stunden gebrannt. ::)
Vergleichender Lesetest war positiv.
Jetzt noch den Zweiten und hoffen, dass die unterschiedlichen Längen vom
Dekoder auch richtig interpretiert werden. Hoffe auch die 120 ns sind nicht zu langsam.
Unter diesem Link sieht man sehr deutlich wie die Verdrahtung sein sollte.
https://www.exxoshost.co.uk/forum/viewtopic.php?t=962 (https://www.exxoshost.co.uk/forum/viewtopic.php?t=962)
Hier noch die Version als Huckepack:
https://temlib.org/AtariForumWiki/index.php/STE_TOS_Upgrade (https://temlib.org/AtariForumWiki/index.php/STE_TOS_Upgrade)
-
So was wie diesen Zähler.
Der Impuls kommt vom Resetschalter vom Atari hier CLK.
An Q0 ist A17 und an Q1 ist A18.
Mit einem 7474 FlipFlop müsste das gehen.
Eine Entprellschaltung ist beigefügt.
-
Erster Chip ist nach ca. 6 Stunden gebrannt. ::)
???
-
Erster Chip ist nach ca. 6 Stunden gebrannt. ::)
???
Vielleicht morst er die Bits einzeln mit einem Taster hinein? ;) Die Programmierzeit für ein 1-MBit-EPROM liegt typisch bei deutlich unter einer Minute.
-
Nee, nix morsen sondern Kaffee trinken gegangen :D
Keine Ahnung woran das liegt, hab den Standardalgorithmus genommen
mit 50ms.
Kenne das auch anders. Jetzt sind beide gebrannt ohne Fehler.
Gibt noch andere Algorihtmen vielleicht probier ich (fast/intelligent) die mal später aus.
http://www.armory.com/~rstevew/Public/Pgmrs/EPROM/How_EPROMs_Work.htm (http://www.armory.com/~rstevew/Public/Pgmrs/EPROM/How_EPROMs_Work.htm)
Mit 50ms ist es eindeutig zu lang. Mit dem Modus Intelligent 100/0 in mükro Sekunden dauert es jetzt nur noch etwa 5 Minuten.
-
Die EPROMS sind drin. Leider funktioniert nur Tos 2.06 :(
,während bei 1.62, 1.04 und 1.02 nichts passiert. Bildschirm bleibt dunkel und
Festplatte blinkt nicht. Zumindest sind die EPROMs schnell genug mit 120 ns.
Liegt es an der TOS Kombination wegen E0 und FC oder muss zusatzlich im Rechner selbst
noch was vorbereitet werden? Z.B HD abschalten, Jumper verstellen oder weniger RAM
einsetzen, anderer Treiber?
-
Vorher hast du es das TOS 1.62, 1.02 und TOS 1.04 im Mega STE funktionieren ?
Im Mega STE läuft ein TOS 2.05 und ein TOS 2.06 sowie EmuTOS ...
-
Das habe ich einfach probiert. TOS 1.04 schafft man ja auch mit Diskettenboot im MegaSTE
Die Images habe ich von hier
https://www.atariworld.org/tos-rom/ (https://www.atariworld.org/tos-rom/)
Wäre naturlich ein Ding wenn das nur mit den von Dir genannten Versionen geht.
-
Wäre naturlich ein Ding wenn das nur mit den von Dir genannten Versionen geht.
Ich Denke schon.
TOS 1.62 ist STE only und ein MSTE ist eine völlig andere Maschine.
Da hat mal jemand mit Tricks TOS 1.04 auf einem 1040STE gebootet habe ich mal irgendwo gelesen meine ich.
-
Das kann man mit dem Programm Credisk zusammen mit Tracc.prg, Mtosboot.sys und
dem 1.04 Image. Das geht sehr gut von Diskette. Aber in ROM Version müsste es sowas geben.
Hm, das wäre dann noch was für PP das aufs EPROM zu bringen von ihm ist ja dieses Programm ;D
Schade das ich keinen STe habe sonst könnte ich zumindest testen, ob das Quad Tos darauf läuft.
Ob man das mit Steem prüfen kann?
-
Wenn man TOS 1.04 von Diskette bootet wurde die Hardware ja schon vom eingebauten TOS initialisiert.
Oder sehe ich das falsch?
Auf jeden Fall wird alles vor 2.05 nicht ohne Modifikationen im Mega STE laufen.
Beim TOS 2.06 war das Revolutionäre des es alle 68K Atari Maschinen kennt.
Im STBook könnte eine Modifizierte 2.06 eingebaut sein, da bin ich mir aber nicht sicher.
-
Fakt ist das diese ganze Quad Geschichte für den STe zugeschnitten ist. Das habe ich so
gar nicht auf dem Schirm gehabt.
Dazu kenn ich mich in Betriebssystemen zuwenig aus um das zu bestätigen.
Ich verstehe das jedoch so, dass das Diskettentos sich im Ram einistet und
die Steuerung übernimmt.
Was da genau modifiziert werden muss ist die Frage. Ist ein Thema für Leute mit
Assemblerkennissen.
Es würde mich interessieren ob das Quad Tos wie ich es zusammengesetzt hab
in einem STe funktioniert.
-
Es würde mich interessieren ob das Quad Tos wie ich es zusammengesetzt hab
in einem STe funktioniert.
Ohne Tricks und Änderungen im TOS läuft im STE ein TOS 1.6, TOS 1.62 und ein TOS 2.06 sowie EmuTOS.
-
Also ich meinte damit ob die Dateien von Quad Tos wie ich sie im Thread Antwort #23 angehängt habe
so laufen. Die ungeklärte Frage ist für mich die Kombination von TOS 1.04 mit 2.06.
-
Gibt es ein Programm das die einzelnen Teile auf dem Atari merged?
Möchte für den Copybefehl nicht immer den PC benutzen.
Habe mir überlegt ein normales TOS 2.06, ein gepachtes 2.06, ein EmuTos und ein ??
einzusetzen. Für das 4te ?? bin ich noch unschlüssig. Das sollte alles ohne Tricks
in ein MegaSTe 2 x 512KB EPROM passen.
Bisher finde ich Quad Projekte aber nur für den STe.
-
Gibt es ein Programm das die einzelnen Teile auf dem Atari merged?
cat tos1.img tos2.img > merged.img
-
Danke aber wie heisst denn da das Programm dazu etwa cat.prg?
Ist das im Autoordneranzulegen?
Ich möchte alles nur auf dem Atari machen.
-
Das programm heisst einfach nur cat (wenns von mint kommt) oder cat.ttp aus dem Gemini-Paket.
-
Ohne Tricks und Änderungen im TOS läuft im STE ein TOS 1.6, TOS 1.62 und ein TOS 2.06 sowie EmuTOS.
Ist mir noch gar nicht aufgefallen, dass es so viele unterschiedliche Formen von EmuTOS's
gibt, ganz zu schweigen von Amiga, Aranym und Firebee Versionen.
EmuTOS mit 256k würde ich dann zum Brennen nehmen. Die anderen
sind ungeeignet für einen MegaSTe, weil zu gross oder Floppy.
Die Cardridge wäre auch eine Möglichkeit als externes Betriebssystem.
Die aktuellsten Atari Versionen sind vom 7.12.2018.
512k für TT und Falcon:
https://sourceforge.net/projects/emutos/files/snapshots/20181207-232749-80ef013/emutos-512k-20181207-232749-80ef013.zip/download (https://sourceforge.net/projects/emutos/files/snapshots/20181207-232749-80ef013/emutos-512k-20181207-232749-80ef013.zip/download)
256k für STe/MegaSTe:
https://sourceforge.net/projects/emutos/files/snapshots/20181207-232749-80ef013/emutos-256k-20181207-232749-80ef013.zip/download (https://sourceforge.net/projects/emutos/files/snapshots/20181207-232749-80ef013/emutos-256k-20181207-232749-80ef013.zip/download)
192k für ST/STF/MegaST:
https://sourceforge.net/projects/emutos/files/snapshots/20181207-232749-80ef013/emutos-192k-20181207-232749-80ef013.zip/download (https://sourceforge.net/projects/emutos/files/snapshots/20181207-232749-80ef013/emutos-192k-20181207-232749-80ef013.zip/download)
Floppy für alle:
https://sourceforge.net/projects/emutos/files/snapshots/20181207-232749-80ef013/emutos-floppy-20181207-232749-80ef013.zip/download (https://sourceforge.net/projects/emutos/files/snapshots/20181207-232749-80ef013/emutos-floppy-20181207-232749-80ef013.zip/download)
Cartridge für alle:
https://sourceforge.net/projects/emutos/files/snapshots/20181207-232749-80ef013/emutos-cartridge-20181207-232749-80ef013.zip/download (https://sourceforge.net/projects/emutos/files/snapshots/20181207-232749-80ef013/emutos-cartridge-20181207-232749-80ef013.zip/download)
Damit ergibt sich die Konstellation: EmuTOS, TOS 2.06, Gepatchtes TOS 2.06 V38 und TOS 2.05
EmuTOS 256k:
https://sourceforge.net/projects/emutos/files/snapshots/20181207-232749-80ef013/emutos-256k-20181207-232749-80ef013.zip/download (https://sourceforge.net/projects/emutos/files/snapshots/20181207-232749-80ef013/emutos-256k-20181207-232749-80ef013.zip/download)
TOS 2.06:
http://www.avtandil.narod.ru/tos/tos206de.zip (http://www.avtandil.narod.ru/tos/tos206de.zip)
TOS 2.06V38:
http://vezz.it/atari/auto/tp206v38.zip (http://vezz.it/atari/auto/tp206v38.zip)
TOS 2.05:
http://www.avtandil.narod.ru/tos/tos205de.zip (http://www.avtandil.narod.ru/tos/tos205de.zip)
Die vier Teile in Hi und Lo gesplittet mit dem Tool
http://atari.8bitchip.info/ROMSPLIT.ZIP (http://atari.8bitchip.info/ROMSPLIT.ZIP)
und die 8 Teile in 2 512k Hi und Lo folgendermaßen zusammensetzen:
-
Nur damit hier keine unvollständigen Infos stehen, verweise ich bezüglich der jeweils unterstützten Rechner auf die EmuTOS-Dokumentation:
https://github.com/emutos/emutos/blob/master/doc/readme-192k.txt
https://github.com/emutos/emutos/blob/master/doc/readme-256k.txt
https://github.com/emutos/emutos/blob/master/doc/readme-512k.txt
-
Zur Floppy und Cartridge Version gibts da auch noch Text links?
Ich vermisse ein EmuTOS mit Rainboweffekt. Das wäre noch ein nettes optisches Feature :D
-
Alle Dokumentation unter: https://github.com/emutos/emutos/tree/master/doc
Ohnehin sinnvoll, da mal zu lesen...
-
https://github.com/emutos/emutos/blob/master/doc/readme-cartridge.txt (https://github.com/emutos/emutos/blob/master/doc/readme-cartridge.txt)
https://github.com/emutos/emutos/blob/master/doc/readme-floppy.txt (https://github.com/emutos/emutos/blob/master/doc/readme-floppy.txt)
-
Das Floppy Image von EmuTos funktioniert so jedenfalls nicht >:D
-
Das Floppy Image von EmuTos funktioniert so jedenfalls nicht >:D
Was meinst Du mit "so"? Natürlich funktioniert es, getestet.
Du hast sicherlich gesehen, dass es ein einseitiges (single-sided) Image ist und dass Du es nicht einfach auf eine doppelseitige Floppy schreiben darfst. (Zitat Doku, Hervorhebung von mir: "These floppies are provided in the form of raw single-sided floppy images.")
-
Ja funktioniert einwandfrei. Ich nutze auch rawwrite unter windows.
-
Wie bringe ich denn das Image auf die Diskette?
Habe .st mit JayMsa extrahiert und die Datei Emutos.sys auf eine 360k Diskette kopiert.
-
Wie bringe ich denn das Image auf die Diskette?
Habe .st mit JayMsa extrahiert und die Datei Emutos.sys auf eine 360k Diskette kopiert.
Das funktioniert natürlich nicht, wie Du auch schon festgestellt hast. Wie sollte es auch?
Du musst mit einem Programm direkt die .st-Datei auf die Diskette schreiben. Frank hat Dir ja schon rawwrite unter Windows genannt, aber wenn Du schon JayMsa nutzt, dann lass dieses doch die .st-Datei schreiben.
-
Auf einem Atari funktioniert es mit JayMSA auch ...
ST Image einladen und eine Einseitige Diskette in Laufwerk A einlegen und dann unter Disk -> Extract
-
So, endlich hat es geklappt mit folgendem Tool
http://www.chrysocome.net/downloads/rawwritewin-0.7.zip (http://www.chrysocome.net/downloads/rawwritewin-0.7.zip)
Vorab eine HD Diskette mit 360k formatiert am Atari hatte ich allerdings schon
vorher gemacht.
Das muss man jedoch wissen mit dem Tool. :o
Gleich über Bordmittel wärs schöner gewesen.
Danke Frank habe das auch probiert wie beschrieben und ging auch sofort. :D
Vielen Dank :D
-
Wunderschön... diese detaillierten Grafiken und Icons. Da hatte doch wer Geschmacksverirrung. >:D
-
Tja, gute Designer sind eben rar. Hoffentlich ist der Programmcode hübscher ;D
-
Wunderschön... diese detaillierten Grafiken und Icons. Da hatte doch wer Geschmacksverirrung. >:D
Halten wir mal ein paar Dinge ganz eindeutig fest:
1. EmuTOS wird mit alternativen Iconsets ausgeliefert; wem die Standardicons nicht gefallen, kann diese jederzeit nachladen. RTFM.
2. Wem auch die alternativen Iconsets nicht gefallen, der kann ja seine eigenen Fähigkeiten als Pixelkünstler unter Beweis stellen und weitere Icons zu EmuTOS beitragen. Bei Open-Source-Software zählt nicht meckern sondern machen.
Tja, gute Designer sind eben rar. Hoffentlich ist der Programmcode hübscher ;D
3. Das betrachte ich (als jemand der einiges an Code beigetragen hat) als knapp an einer Unverschämtheit vorbei geschrammt!
-
3. Das betrachte ich (als jemand der einiges an Code beigetragen hat) als knapp an einer Unverschämtheit vorbei geschrammt!
Immer locker bleiben :D
-
Ohne Buchstützen würd ich ja nichts sagen.
-
Neues Quad TOS ist fertig gebrannt. Hat diesmal nur ca. 5 Minuten gedauert. Mit Modus Intelligent 100/0.
Inhalt: 2.05 (DE), Supertos (UK), EmuTOS256 (DE) und TOS 2.06 (DE).
Laut Petari soll auch sein umgestricktes TOS 1.04 für den MegaSTE möglich sein. das könnte
z.B. statt des Supertos' getauscht werden.
Die Platine teste ich noch. Sofern Conrad einen 7476 (JK Flipflop) in seiner Filiale
zum Mitnehmen hat bau ich das heute zusammen.
Die Schaltung soll entweder über das FlipFlop gehen um mittels Taster eine Umschaltung zu erzielen
oder mittels Jumper soll das jeweilige gewünschte TOS fest voreingestellt werden.
So hat man es dann selbst in der Hand wie man Umschalten möchte.
Eine erweiterte Option die denkbar wäre, wäre die Einstellung des FlipFlops über eine kleine Batterie zu speichern wenn der Rechner abgeschaltet wird.
Aber das muss erstmal getestet werden.
-
Die Platine teste ich noch. Sofern Conrad einen 7476 (JK Flipflop) in seiner Filiale
zum Mitnehmen hat bau ich das heute zusammen.
Die Schaltung soll entweder über das FlipFlop gehen um mittels Taster eine Umschaltung zu erzielen
oder mittels Jumper soll das jeweilige gewünschte TOS fest voreingestellt werden.
So hat man es dann selbst in der Hand wie man Umschalten möchte.
Eine erweiterte Option die denkbar wäre, wäre die Einstellung des FlipFlops über eine kleine Batterie zu speichern wenn der Rechner abgeschaltet wird.
Aber das muss erstmal getestet werden.
Vergiss nicht, den Taster zu entprellen, sonst hast Du mit dieser Schaltung wenig Spaß. Letztlich wäre es mit einem Mikrocontroller doch einfacher gewesen. Entprellen ist dort nur etwas zusätzlicher Code, speichern lässt sich die Wahl im integrierten EEPROM.
-
Danke für den Tipp.
Microcontroller : 1) Wer programmiert mir den Code?
2) Programmieradapter erforderlich
So ist es einfacher (für mich).
Entprellen ist ein Argument, da gibts auch was.
http://www.berel-amries.de/WVSS/Arbeitsvorlagen/Prellfreier_Schalter/Endprellen%20eines%20Umschalters.htm (http://www.berel-amries.de/WVSS/Arbeitsvorlagen/Prellfreier_Schalter/Endprellen%20eines%20Umschalters.htm)
Hier gehts noch einfacher mit RC Glied
https://www.mikrocontroller.net/articles/Entprellung (https://www.mikrocontroller.net/articles/Entprellung)
Pufferbatterie: Da könnte man die schon Vorhandene im Rechner mitnutzen.
VCC Abgriff wäre am Timerbaustein Pin 18. Das Flipflop darf dann nicht direkt mit 5V
verbunden werden.
Sollte zu viel Strom verbraucht werden noch eine Batterie parallel dranhängen.
-
QUAD TOS ist eingebaut.
Bei EmuTos wird nur in Laufwerk D Pixelmüll angezeigt. Alle anderen Betriebssysteme haben das nicht.
DMA Fehler sind deshalb auszuschließen. Der Brennvorgang zeigte auch keine Fehler.
Entweder habe ich noch was überlesen oder EmuTos ist vielleicht nicht richtig gesplittet worden.
Suche nach der Ursache.
Da Conrad wieder mal die entscheidenden Teile nicht hatte, geschieht die Auswahl wie zuvor
mittels Jumper. Letztes Bild ist von SuperTOS UK
Die QUAD TOS Dateien sind angehängt. Bei EmuTos handelt es sich um die aktuelle Version.
Habe jetzt nochmals EmuTOS als Floppyversion geladen, da ist auf dem D Laufwerk auch Pixelmüll.
Fehler ist wiederholbar.
QUAD TOS wieder entfernt, da vermutlich ein Bug in HDDriver in Verbindung mit EmuTOS zu
Pixelmüll führt.
-
Die gesplittete EmuTOS hänge ich hier auch noch dran.
-
Hast Du die EPROMs auch verifiziert d.h. zurückgelesen? Evtl. haben die Programmierpulse von 50 ms (Angabe von Dir oben) ja ein paar Bits "verglühen" lassen. Deine EPROMs hätten 50-µs-Pulse gebraucht, also Faktor 1000(!) kürzer
-
Ja alles zurückgelesen und mehrmals verifiziert. Da war kein Fehler. Die Eproms sind in Ordnung.
-
Besteht der EmuTOS Fehler auch mit der aktuellen 0.991 Version?
-
Ergänzend: Tritt der Fehler auch mit der .prg-Version von EmuTOS auf?
-
Wie wurde die D:-Partition angelegt (Parameter)?
-
Besteht der EmuTOS Fehler auch mit der aktuellen 0.991 Version?
Ja
-
Bei meinem Mega STE mit drei 300MB Partitionen auf einer SCSI/ACSI Platte ist von der 0.991 Bootdiskette gebootet alles in Ordnung.
-
@Atariosimus ... du nutzt doch mehr als 1GB an deinem original Atari MSTE Hostadapter, oder?
-
Nein intern nur ein GB wie auf dem Foto zu erkennen ist. Aufgeteilt in 4 Partitionen.
-
Alles mal rückgebaut und die Eproms eingesetzt, die schon immer drin waren. Genau das gleiche
Resultat. Ich kann mir da keinen Reim drauf machen.
-
Ergänzend: Tritt der Fehler auch mit der .prg-Version von EmuTOS auf?
Eindeutig ja und das bei den Eproms die schon immer drin waren also keine Quad TOS.
-
Wenn das jetzt original Atari TOS wäre, würde ich sagen, mach die Partitionen niemals 256 MB groß, immer ein bischen unter solchen Grenzen drunter bleiben, z.B. 254 MB und lieber ein bischen nicht partitionieren... Bei EmuTOS habe ich keine Erfahrungen, aber beim Atari TOS hab ich da schon öfters Probleme gehabt.
-
Bei Atari TOS funktioniert es ja sehr gut mit der Aufteilung. Sogar bei allen
3 TOS Varianten.
Vielleicht ist EmuTOS da restriktiver? Allerdings hätte ich dann erwartet, dass bei allen
Laufwerken was nicht stimmt.
Der Fehler sollte zum Prüfen leicht reproduzierbar sein.
Ich finde es jedenfalls seltsam, dass nur das D Laufwerk spinnt. Brennfehler schliesse
ich aus. Eingebaut ist der Adapter von AmigaKit. Vielleicht liegt es daran.
-
Ich kann das Problem nachvollziehen. Es ist m.M.n. ein Bug in HDDRUTIL (aus HDDRIVER) beim Anlegen der Partitionen, kein Bug in EmuTOS.
Ich muss jetzt auf der EmuTOS-Liste diskutieren, ob wir einen Workaround dafür bauen können. Ich bitte Dich aber, vorerst EmuTOS nicht mit dieser so partitionierten SD-Karte zu benutzen. Bei einem Schreibzugriff auf die falsch angezeigte Partition D: würde es zu Datenverlust kommen.
-
Na super, vielen Dank czietz. :D
Ich hatte mir schon ernsthaft Gedanken gemacht
die Hardware irgendwie geschrottet zu haben.
Bei TOS hatten die schon diesen Workaround drin.
ohne den HDDriver von Seimet zu kennen. :o
Betrifft das auch andere Festplattentreiber?
Wie hätte ich die SD-Karte partitionieren müssen um keinen Pixelmüll zu erhalten?
Ich hätte noch eine Bitte zur Dauer der Startsequenz.
Die ist mir viel zu schnell eingestellt als dass man sie als Neu User
komplett lesen und reagieren kann.
Musste mehrmals resetten um die Optionen nach lesen zu können.
Es wäre besser die Zeit beim ersten Start
zu erhöhen vielleicht 30 Sekunden. Diejenigen die das dann
verkürzen wollen können das mittels Button einstellen.
-
Bei meinem Mega STE mit drei 300MB Partitionen auf einer SCSI/ACSI Platte ist von der 0.991 Bootdiskette gebootet alles in Ordnung.
Wie sehen denn da die Parameter von HDDriver aus?
-
Bei TOS hatten die schon diesen Workaround drin.
ohne den HDDriver von Seimet zu kennen. :o
Nö, hatten sie nicht. Atari TOS kann mit Festplatten von sich aus ja gar nicht umgehen. Du nutzt ja unter TOS automatisch HDDRIVER, während EmuTOS seinen eigenen Plattentreiber mitbringt. Alle Details unter: https://sourceforge.net/p/emutos/mailman/message/36494360/
Kurzfassung: Bei TOS/Windows-kompatibel partitionierten Medien nutzt EmuTOS die Windows-Werte und die sind an einer Stelle falsch. Wenn Du diese SD-Karte in einen Windows-10-Rechner (der Zugriff auf alle vier Partitionen erlaubt) stecken würdest, hättest Du dasselbe Problem wie unter EmuTOS.
Wie hätte ich die SD-Karte partitionieren müssen um keinen Pixelmüll zu erhalten?
Ich denke, letztlich kann nur Uwe Seimet beantworten, warum das Problem genau bei Laufwerk D: auftritt.
Ich hätte noch eine Bitte zur Dauer der Startsequenz.
Die ist mir viel zu schnell eingestellt als dass man sie als Neu User
komplett lesen und reagieren kann.
Musste mehrmals resetten um die Optionen nach lesen zu können.
Es wäre besser die Zeit beim ersten Start
zu erhöhen vielleicht 30 Sekunden. Diejenigen die das dann
verkürzen wollen können das mittels Button einstellen.
Den meisten Usern ist die Startzeit von EmuTOS recht. Künstliche Verzögerungen werden keine Mehrheit finden. Auch ich will nicht jedes Mal (wie bei TOS 2 oder 3) eine Taste drücken müssen, damit der Rechner endlich bootet. Du kannst beim Booten Shift drücken und festhalten, damit der Startbildschirm nicht verschwindet. (Steht da auch.)
-
Du kannst beim Booten Shift drücken und festhalten, damit der Startbildschirm nicht verschwindet. (Steht da auch.)
...und genau das kann ich wegen der Schnelligkeit nicht lesen :o
Wenn Du diese SD-Karte in einen Windows-10-Rechner (der Zugriff auf alle vier Partitionen erlaubt) stecken würdest, hättest Du dasselbe Problem wie unter EmuTOS.
Ich nutze noch XP und sehe nur die erste Partition ::)
PP hat mal einen Weg erklärt wie man bei XP trotzdem alle sehen kann.
-
Drive D: is wrong, however: FAT size under TOS 4096 bytes * 16 sectors =
65536 bytes, under EmuTOS 512 bytes * 64 sectors = 32768 bytes. This
causes EmuTOS to look for the root directory where actually the second
FAT is.
Verstehe ich das richtig das die FAT Grösse von TOS doppelt so groß ist wie bei EmuTos
und deshalb sieht EmuTOS im Root Verzeichnis statt auf D nach?
Wie hätte ich denn partitionieren müssen um Pixelmüll zu verhindern und trotzdem
zwischen EmuTOS und TOS optimale Kompatibilität zu haben?
Da würde mich jetzt die Einstellung von Frank interessieren.
-
Ich habe keinerlei Probleme. Ich nutze eine 4GB SCSI Festplatte und HDDriver 10.12
(https://fglukas.lima-city.de/forum/hdd_1.jpg)
(https://fglukas.lima-city.de/forum/hdd_2.jpg)
-
Verstehe ich das richtig das die FAT Grösse von TOS doppelt so groß ist wie bei EmuTos
Die vermeintliche (also aus dem Bootsektor gelesene) FAT-Größe, ja.
und deshalb sieht EmuTOS im Root Verzeichnis statt auf D nach?
Nein, EmuTOS und Windows und andere sehen in der zweiten FAT nach, wenn sie eigentlich das Root-Verzeichnis öffnen wollen.
Wie hätte ich denn partitionieren müssen um Pixelmüll zu verhindern und trotzdem
zwischen EmuTOS und TOS optimale Kompatibilität zu haben?
Wie oben schon geschrieben: Im Regelfall macht es HDDRUTIL ja richtig, siehe Deine Laufwerk C:, E: und F:. Was dafür sorgt, dass D: falsch ist, muss vermutlich Uwe Seimet herausfinden. Nur er weiß, wie HDDRUTIL diese Werte berechnet.
-
Frank benutzt eine 4GB Festplatte, ich gehe davon aus, dass das bei einer SD-Karte auch keinen
Unterschied macht. Werde das jetzt nach seinen Angaben umstricken.
Allerdings nur 3 Partitionen auf Festplatte und die Letzte auf USB Stick.
Fällt mir noch ein Wunsch ein. Kann man ab einer bestimmten Größe das EmuTos nicht so
umstricken, dass statt Bytes GB oder MB angezeigt werden? Find das immer übel
wenn in einem Ordner so eine riesen Zahl in Bytes steht und man beim Umrechnen doch
etwas handlichere Werte hat.
Vielleicht noch eine Idee wie man dieses Thema statt Workaround auch abhandeln könnte.
Entweder prüft EmuTOS vorab ob die Partitionen kompatibel sind oder man legt noch ein
Zusatzprogramm bei dass nur angibt ob es installiert werden kann.
Letztlich wird der normale User bei Auftreten dieses Bugs immer zuerst EmuTOS verantwortlich
machen. Da ja seiner Ansicht nach es bei TOS keine Probleme gab.
Ob Seimet sich da überhaupt dransetzt ist die Frage. Er könnte ja auch argumentieren, daß er mit EmuTOS nichts am Hut hat und den Treiber für TOS ausgelegt hat und da funktioniert es ja.
-
Ob Seimet sich da überhaupt dransetzt ist die Frage. Er könnte ja auch argumentieren, daß er mit EmuTOS nichts am Hut hat und den Treiber für TOS ausgelegt hat und da funktioniert es ja.
Sei versichert, Uwe Seimet wird sich darum kümmern. Wir stehen schon in Kontakt.
Das obige Argument zöge übrigens nicht, denn die Partitionierung ist ja als "TOS & Windows"-kompatibel angegeben und unter Windows hättest Du exakt dasselbe Problem. Es ist kein EmuTOS-spezifischer Bug!. Ich habe mir vor ein paar Monaten, als ich meinen Windows-10-Rechner neu hatte, übrigens vermutlich dadurch eine Partition D: auf einem HDDRUTIL-partitionierten Medium zerschossen. Zum Glück gab es ein Backup. Ich habe es damals nicht weiter untersucht, aber nun bin ich sicher, dass es damals auch der Bug in HDDRUTIL war.
-
Ich habe das Problem übrigens nicht, wenn ich ein 1-GiB-großes Medium händisch wie im Anhang dargestellt partitioniere, statt den "Splitten"-Knopf zu drücken.
-
Ist das Problem nur da wenn man vier Partitionen anlegt? Ich hatte bei mir einfach Splitten in drei Teile angeklickt.
-
Das sind ja interessante Neuigkeiten. Dann bekommen wir sicher bald ein neues Update von Uwe.
Vielleicht ist Neubrennen überflüssig nach dem Update.
Mach das jetzt auch händisch.
In der Zwischenzeit noch ein paar Impressionen von dem QUAD TOS.
Ich musste da etwas improvisieren mit den Sockeln. Die kann man auch
tiefer legen. Der Prototyp funktioniert sehr gut. Alle Verbindungen zwieschen
den Leisten wurden nochmals verlötet um auch sicheren Kontakt zu gewährleisten.
Mit dem Entreprellen und der Auswahllogik lass ich mir noch etwas Zeit.
-
Anhand dieses asynchronen Frequenzzählers eine Klickschaltung aufgebaut um die 4 verschiedenen
Betriebssysteme anzusteuern. Die Hälfte der Schaltung genügt.
https://elektroniktutor.de/digitaltechnik/teiler.html (https://elektroniktutor.de/digitaltechnik/teiler.html)
Eingesetzt wurde ein 74LS74 RS FlipFlop (siehe Schaltbild). Testweise mit dem Clockeingang
an Masse gegangen. Und siehe da das TOS wechselte. Inwieweit das prellt kann ich so
noch nicht beurteilen, da mir erstmal wichtig war überhaupt einen Wechsel herbeizuführen.
Nebenbei ist mir beim Aufruf des EmuTOS noch ein witziges Feature aufgefallen.
Klickt man auf das linke Fuji Logo wird eine kurze Melodie abgespielt. Das rechte Fuji ist jedoch tonlos.
-
Bei EmuTOS ist mir noch was aufgefallen.
Nach dem Umschalten von TOS ergibt sich folgende Meldung beim Anspeichern des Desktops.
Das Dateisystem wurde auf die entsprechnde Größe abgeändert, so dass D jetzt keinen
Pixelmüll mehr hat.
-
Hier die HDDRUTIL
Kann man denn die einmal beschriebene SD Karte nicht einfach so für ein anderes
Betriebssystem weiterbenutzen?
Kann mir nur vorstellen das der eigene Treiber der in EmuTOS schon vorhanden ist
mit dem HDD Treiber irgendwie kollidiert.
Vielleicht geht das nur richtig wenn man diesen zuvor deinstalliert.
-
Sei versichert, Uwe Seimet wird sich darum kümmern. Wir stehen schon in Kontakt.
Ganz frisch: HDDRIVER 10.14: https://www.hddriver.net/de/news.html, in dem unterem anderem dies in HDDRUTIL korrigiert ist.
Das Update ist -- wie bei HDDRIVER üblich -- für Käufer einer Version 10.x kostenlos.
-
Vielen Dank, direkt gezogen ...
-
Donnerwetter, das ging ja schnell. Das heißt dann auch das EmuTOS so bleibt wie es ist
oder wird trotzdem noch ein Workaround für den Fall der Fälle angestrebt?
-
Donnerwetter, das ging ja schnell. Das heißt dann auch das EmuTOS so bleibt wie es ist
oder wird trotzdem noch ein Workaround für den Fall der Fälle angestrebt?
Für das kommende EmuTOS-Release ist es zu spät für größere Änderungen am Festplattentreiber. Danach sehen wir weiter.
-
Der Support hier im Forum und von Uwe ist einfach toll. Schade das ich nicht alles was hier entdeckt wird sofort ausprobieren kann >:D... ist einfach viel zu viel für mal eben.
-
Das Teil ist fertig. Anbei noch der handskizzierte Schaltplan.
Der Vorteil dieser Schaltung liegt darin mit nur einem Taster das ensprechende TOS
prellfrei zu wählen.
Die Jumper stehen auf dem Bild in neutral. Es wird nur mit dem Tastschalter
das TOS ausgewählt. Wer den Tastschalter nicht möchte kann jedoch
alternativ über die Jumper gehen. Diese müssen dann allerdings um 90 Grad
gedreht gesteckt werden um in Funktion zu treten.
Es wurden LS Bausteine verwendet mit HC geht das auch jedoch ist die Entprellung
über den Widerstand R2 möglicherweise beim 74HC14 etwas anzupassen,
da die Schwellwerte etwas abweichen können.
Die Funktionsweise ist denkbar einfach. Je nach Anzahl der Tastendrücke kommt man
um ein oder auch mehrere TOS's nach vorne. Z.B. bei 4 Klicks kehrt man wieder zum
Ausgangs TOS zurück. Der Tastschalter ist auf der Platine angebracht. Eine Verbindung
mit Reset ist trotzdem möglich.
Noch ungetestet:
Pufferbatterie: Da könnte man die schon Vorhandene im Rechner mitnutzen.
Austausch des 74LS74 durch 74HC74.
VCC Abgriff für das FlipFlop wäre am Timerbaustein Pin 18. Plus Pol des 74HC74
muss dabei komplett getrennt sein von der VCC Schiene.
Mit KitCad könnte man diese Platine schön aufbauen und sie vom Chinamann
herstellen lassen. Ob man nun SMD nimmt spielt eigentlich keine Rolle, da die
Platzverhältnisse durch die EPROMs vorgegeben sind.
Auf dem Bild ist links der 74LS14 unter dem Hi Eprom (blau) untergebracht.
-
Mir ist noch etwas bei EmuTOS aufgefallen.
Das Laufwerk einer extern angehängten Gigafile wird einfach nicht erkannt.
Stattdessen wird C auf D, D auf E, E auf F und F auf G verschoben.
Laufwerk C läßt sich nicht öffnen.
Alle anderen TOS machen das nicht.
-
Problem gelöst. Hab die Id verändert und neuen HDdriver aufgespielt.
-
Problem gelöst. Hab die Id verändert und neuen HDdriver aufgespielt.
Und was war der eigendliche Fehler?
-
HDDRIVER 10.12. jetzt ist die 10.14 drauf. Es werden dadurch sogar mehr Laufwerke
der externen Gigafile zur Verfügung gestellt. Das Booten ist so schnell, dass die externe Gigafile
manchmal gar nicht mitkommt und erneut Reset erforderlich ist.
-
74HC74:
Operating Voltage Range: 2.0 to 6.0 V
Low Input Current: 1.0 µA (0,001 mA)
maximaler Ruhestrom: 4 µA
Bei einer CR2032 3V Knopfzelle mit 210 mAh läuft so ein Baustein ca. 210000 h.
Was etwa 24 Jahre im Idealfall entspricht. Bei maximalem Ruhestrom etwa 6 Jahre.
Reichlich Reserve um den Baustein zum Halten der Information mit einer Pufferbatterie
lange zu versorgen.
Abgriff von Vcc im Rechner zwischen Pin 18 von U402 und der Kathode von Diode D401
auf Vcc vom 74HC74 gelegt mittels Draht.
Vcc von der Rechnerplatine muss von Vcc vom 74HC74 getrennt sein.
Andernfalls wird sonst der Rechner im abgeschalteten Zustand von der Batterie
mitversorgt was zu schneller Entladung der Knopfzelle führen würde.
-
Mit einem zusätzlichen Widerstand von 4,7k zwischen Masse und Ausgang vom Schmitt-Trigger
läuft das jetzt so wie gewünscht. Der Widerstand verhindert einen undefinierten Zustand oder
auch das "Flattern" am 74HC74. Derzeit liegen etwa 2,43V an bei abgeschaltetem Rechner.
-
Nach längeren Tests wurde der Widerstand wieder entfernt.
Die Speicherung des eingestellten TOS' nach Abschalten des Rechners funktioniert bisher nicht zuverlässig.
-
Ziel war es das aktuelle TOS auch zu speichern bei Netztrennung.
Mehrere Optionen testweise durchprobiert:
- eine Batterie dierekt an den 74HC74 angehängt
gleichzeitig Batterie vom Rechner wieder wieder abgelötet.
- Widerstand 4,7K von Clk auf Masse und Kondensator (100nF) zwischen Clk und Ausgang vom 74LS 14
- Diode zwischen Masse und Clk (Kathode)
- ohne diese Bauteile nur mit Batterie von Pin 18.
Keines dieser Optionen auch Kombinationen funktionierte.
Mein Eindruck ist, dass durch das Ein- und wieder Anschalten Impulse auf das FlipFlop kommen
und zu einer Verstellung führen. Weitere Möglichkeit wäre auch eine falsche Dimensionierung
der Bauteile. Merkwürdig ist nur, dass der Timmerbaustein offensichtlich gut mit der Netztrennung
zurechtkommt. Am Oszilloskop gemessen zwischen Clk und Masse gab es beim Ausschalten
einen kurzen Takt in die negative Richtung mit ca. 0,1 mV.
Die Schaltung bleibt jetzt erst einmal wie am Anfang. Das zuverlässige Wechseln zwischen den TOS'
funktioniert mittels Tastschalter sehr zuverlässig.
-
Mit einem kleinen PIC würde das doch gehen -> https://electrosome.com/push-button-switch-pic-microcontroller/
-
Ja, sicher das wäre die Lösung von czietz.
Es müsste aber auch so gehen, nur ich finde den Fehler nicht.
Es geht nur darum, dass das FlipFlop beim Ausschalten seine Informationen behält.
-
Es geht nur darum, dass das FlipFlop beim Ausschalten seine Informationen behält.
Das tun die aber nicht. Dazu muss ja die letzte Ansteuerung irgendwie erhalten bleiben !?!
-
Genau. Bleibt der Rechner dauernd an so ist das auch so. Beim Ausschalten sollte die Batterie
diese Funktion erhalten.
-
Dann musst du die Spannungsversorgung der +5V durch eine Diode von deiner Schaltung entkoppeln so in der Art wie bei einem Uhrenbaustein (z.B. Atari TT) und deine Ansteuerschaltung über eine Batterie versorgen. DAs verbraucht aber viel zu viel Strom und deine Batterie ist schnell entleert. Nimm einen PIC + Software ...
-
Das ist leider so nicht ganz richtig. Der Verbrauch liegt bei 1 bis 4 mücro Ampere. Das reicht für
mindestens 6 oder sogar 24 Jahre. Der 74hC74 braucht sehr wenig Strom ist ja ein CMOS.
Weiterhin hat der MegaSTE eine Schaltung die gerade die Batterie
entkoppelt. Die Transistoren Schalten solange durch wie Strom vom Netz anliegt
danach übernimmt die Batterie die Versorgung. Ich messe 2,4 Volt. Das FlipFlop läuft
nach Datenblatt sogar mit nur 2Volt.
-
2,4V minus 0,6V das wird zu wenig sein für einen High Pegel. Nimm doch eine 4,5V Batterie ...
-
Nein, es liegen nach der Schaltung im Atari, 2,4 V direkt am 74HC74 an.
Um das auszuschliessen habe ich sogar direkt eine CR2032 an den IC angeschlossen.
Danke trotzdem für Deine geschätze Hilfe. Ich versteh es einfach nicht.
Ist letzlich eine banale Pufferschaltung mit Batterie.
Vieleicht hätte ich den Schmitt- Trigger auch noch mit einbeziehen müssen,
was mir allerdings wenig schlüssig wäre.
-
Dann messe doch mal den High Pegel bei 2,4V Betriebsspannung unter der richtigen Last die auch in deiner kompletten Schaltung da ist ...
-
Pegel an den Ausgängen von 74HC74 zwischen 0 und 5,1V unter Netzbetrieb.
Es könnte auch so sein, dass zum Halten 2x3V CR2032 erforderlich sind.
Bisher bin ich davon ausgegangen, dass im "Schlafmodus" der IC nur
wissen muss wie die Ausgänge im Pegel liegen und deshalb mit 2,4V an
Versorgungsspannung auskommt.
Abzüglich Diode sind das dann gerade mal 5,1V, wenn ich noch eine Batterie
nehme die etwas verbraucht ist oder zusätzlich einen Widerstand einsetze.
Jetzt werf ich mal einen Blick ins Datenblatt vom 27C040 wie weit der Pegel
abgesenkt werden kann. Zwischen 0,8V (-0,5) Low und 2,0V High an den Eingängen reichen aus.
Der 74HC74 kann 6V als Versorgungsspannung vertragen. Das High ist mit minimal 4,2V angegeben.
Bei 4,5V sind es minimal 3,15V als High. Was mit Zwischenwerten ist ist leider nicht angegeben.
Hm, bei Batteriebetrieb lagen bei nur einer Batterie 2,4V an. Sowohl an Vcc wie auch am Ausgang Q.
Leider ist für diesen Wert nichts im Datenblatt angegeben. Vielleicht läuft der mit dieser
Eingangsspannung nicht. Nur 2V sind noch angegeben und da sind es dann mit 1,5V zu wenig.
-
High ist doch erst ab 2,6V, keine Ahnung ...
-
steht so im Datenblatt. Fahre gerade eine Testreihe mit 2 Batterien. Nach einer Stunde schalte ich
wieder an.
-
Das hat funktioniert jetzt nochmal eine Stunde.
-
Du musst wahrscheinlich die Bauteile am Eingang des Flipflops auch mit der Batterie puffern.
-
Hallo 1ST1, ja das wäre auch noch eine Möglichkeit den Schmitt-Trigger zu puffern.
Leider habe ich keinen HC Typ mehr in der Bastelkiste. Den Eingang habe ich
wieder mittels 4,7k auf Masse gelegt. Ist der Schmitt Triger stromlos so flattert
da nichts am FlipFlop. Im Grunde sollte sich da auch gar nichts tun.
Irgendwie leuchtet es mir aber nicht so ganz ein was da passiert. Der Zustand des
FlipFlops ist jetzt im Test. Habe jetzt 4mal hintereinander das eingestellte EmuTOS
wie erwartet bekommen. Probiere das aber weiter durch nicht das hier der Zufall
nur gewirkt hat. Alles mit 2xCR2032 in Reihe und gesichert durch eine Diode. Aus den Batterien
geht nur was raus und nur auf das FlipFlop. Von der Netzseite auch noch eine Diode damit die
Batterien bei ausgeschaltetem Netzteil nicht die Schaltung speist.
-
Du hast doch ein Oszi, oder? Also prüfe mal wie sich die Logikpegel an den Ein und Ausgängen ändern wenn du den Rechner Stromlos schaltest oder an schaltest.
-
Ja, so ein Einkanal China Oszi DSO150.
-
Hier der Q Ausgang bei Netzbetrieb. Die Spannung die am Oszo angezeigt wird ist höher als auf dem
Drehspulmessgerät. Warum das so ist, keine Ahnung. Jedenfalls sind die Kurven
interessant als Vergleich. Sehe da keinen Unterschied ohne Netzbetrieb. Was ja auch gut ist.
-
Bis jetzt liefen die Tests erfolgreich. Nach dem Einschalten (12 mal) war immer das zuvor eingestellte TOS da. Mal sehen wie es jetzt morgen ist und ob die Batterien sich unerwartet schnell enttleeren.
-
Der Pegel wechselt je nach TOS beim Ausgang Q zwischen - 0.16V und 6.0V
Wobei die -0.16V nur als Mittelwert zu sehen sind. Auf dem Oszi wird knapp -1V angezeigt.
Bemerkenswert ist das im Low Bereich eine Wellenform dargestellt wird, während bei High
nur eine gerade sichtbar ist.
Bei nur einer Batterie trat der Effekt auf von -0.16V auf 3.0V zu springen
was zu falschen Ergebnissen führte.
Mit 2 Batterien läuft die Speicherung zuverlässig.
-
Endlich fertig. Die Batterie wird einfach auf den Sockel aufgesteckt.
So ist jederzeit ein leichter Austausch möglich.
Die Spannung hat sich nach dem Einbau auch etwas geglättet, da die Kontakte jetzt besser sind.
Je nach TOS Einstellung schwankt der Wert am Ausgang Q zwischen 5,56 und nahezu 0,0V.
Einem Nachbau steht damit nichts mehr im Wege. Wenn man dazu noch eine saubere Platine
entwickelt sieht das auch ganz nett aus. Anbei noch die Beschaltung des FlipFlops 74HC74.
-
Schön das es jetzt wie gewünscht funktioniert. Bin gespannt wie lange die beiden Batterien halten?
-
Wenn die Theorie mit dem HC Typ stimmt sollte es sehr lange dauern.
Vorteil ist der einfache Aufbau und dass man auch ohne Batterie den Rechner noch starten
kann.
-
Die Batterieeinspeisung wurde noch etwas angepasst mit 2 Kondensatoren parallel zur Spannung.
-
Zwischenstatus:
Bisher läuft die Batterieeinspeisung wie gewünscht.
Es wird immer das eingestellte TOS beim Einschalten
angezeigt. Die Kondensatoren dienen dazu bei Wechsel der Batterien
den Zustand zu halten.
-
Mit Lichtgeschwindigkeit umschalten so könnte der Titel dieser Applikation auch heissen :D
Die Umschaltung erfolgt jetzt von Aussen mittels einer LDR.
Bei Conrad gibts da einen schönen Bausatz von Velleman.
https://www.vellemanprojects.eu/products/view/?id=350454 (https://www.vellemanprojects.eu/products/view/?id=350454)
Die Schaltung könnte man noch verkleinern oder statt mit Relais mit einem BUZ
oder ähnlichem aufbauen. Vielleicht hat der Chinese auch noch etwas in der Richtung
was den selben Zweck erfüllt und billiger ist. Conrad verlangt dafür ca. 12 Euronen.
Zusammenlöten muss man selbst. Zeitaufwand ca. 1 Stunde.
Die Empfindlichkeit der LDR ist so eingestellt, dass man nur den Finger ca. 3 Sekunden
auf die LDR hält um einen Pegelwechsel zu erhalten. Die LDR wird im Lüftungsschlitz
des Laufwerksschachtes mit Heißkleber befestigt. Bohren ist also nicht nötig.
Das Klicken des Relais signalisiert nebenbei die Umschaltung ist jedoch kein Muss.
Sollte wirklich einmal zu wenig Licht in einem Raum vorhanden sein so kann mit einem
Hände oder Taschenlampe nachgeholfen werden. Es ist dabei noch zu beachten
die Einstellung des Mäuseklaviers in on/off Mode zu halten. Andernfalls hätte
man den Nebeneffekt im Einschaltmoment des Rechners einen Impuls zuschalten.
Die LDR ist übrigens unten etwas links von der Mitte mit dem Mäander zu erkennen.
1) Sicher werden sich jetzt einige Fragen warum dieser Aufwand, ein Tastschalter reicht doch?
Ja, richtig nur den muss man so anbringen, dass man ihn auch mechanisch betätigen kann.
2) Warum nicht direkt am Reset Schalter hängen?
Ginge auch, jedoch hatte ich keine Lust den Rechner komplett zu zerlegen.
-
Interessante Lösung. Irgendwo habe ich mal gesehen, dass das jemand mit einem Reedkontakt gemacht hat, man muss halt einen Magneten an die Stelle des Gehäuses halten, wo man den Reedschalter versteckt hat. Ab er Magnet hat halt den Nachteil, dass da Disketten in der Nähe rumfliegen. Heutzutage werden so viele Magnete in der IT verwendet, man darf sein iPad mit magnetischer Apple-Hülle nicht auf nen Stapel Disketten legen, jetzt kommt Microsoft mit einem USB-C-Stecker, der magnetisch gehalten wird, ... Magic, und da waren die Daten weg.
-
Nun selbst hab ich es noch nicht geschaft meine Disketten mit Magnet zu löschen.
Die Festplatten haben auch sehr kräftige Magneten im Inneren.
Es kommt sicher auf die Dosis und die Lage an.
-
Es ist jetzt eingebaut und funktioniert so wie erwartet. Die Empfindlichkeit wurde
nochmal eingestellt, so dass der LDR auch bei Zmmerbeleuchtung anspricht.
Da der LDR so unauffällig angebracht ist wurde noch ein Pfeil aufgeklebt damit man weiss
wo man die Finger auflegen muss. Um in eine andere TOS Version zu kommen
muss man 3 mal hintereinander ca.4 sek den Finger draufhalten.
-
Statt des FlipFlops liese sich auch diese Idee einer Schaltung verwenden.
Batterien entfallen damit. Allerdings nur mit Programmiergerät machbar.
http://www.afug-info.de/Schaltungen-Eigenbau/5xUniversalschalter/ (http://www.afug-info.de/Schaltungen-Eigenbau/5xUniversalschalter/)
-
Statt des FlipFlops liese sich auch diese Idee einer Schaltung verwenden.
Was schrieb ich: ;)
Letztlich wäre es mit einem Mikrocontroller doch einfacher gewesen.
-
Nur mit dem Equipment und dem Schaltplan. Beides war nicht vorhanden.
Eine Fachkraft wäre unbezahlbar gewesen ;D
-
Nur mit dem Equipment und dem Schaltplan. Beides war nicht vorhanden.
Eine Fachkraft wäre unbezahlbar gewesen ;D
Hier wäre es jetzt interessant zu wissen wie lange deine Batterie mitspielt, da Berechnungen und Realität oft nicht übereinstimmen.
-
Die läuft immer noch ohne grosse Änderung der Spannung :D
-
Nur mit dem Equipment und dem Schaltplan. Beides war nicht vorhanden.
Eine Fachkraft wäre unbezahlbar gewesen ;D
Hier wäre es jetzt interessant zu wissen wie lange deine Batterie mitspielt, da Berechnungen und Realität oft nicht übereinstimmen.
Arthur Deine Frage war noch offen.
Seit Beginn meines Einbaus sind mehr als 8 Monate vergangen. Die 2 C2032 Batterien sind immer noch drin wie am Anfang. Das eingestellte TOS (insgesamt stehen ja 4 zur Verfügung)
Ist auf Anhieb da wenn man den Rechner ans Netz bringt.
Die Platine vom AmigaKit scheint allerdings etwas empfindlich auf Biegung zu sein.
Musste diese mehrmals aus und einbauen und den Anzug der Befestigungsschrauben vorsichtig steigern.