atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: czietz am So 19.02.2017, 21:52:33
-
Ich habe das schlechte Wetter heute genutzt, um ein Projekt zu layouten, das ich schon länger geplant hatte: einen TOS-Selector mit Flash-ROM für meinen STE. (Notiz an mich selbst: ich hasse layouten. ;))
Diese Platine soll mir bei EmuTOS-Entwicklung und -Testing helfen, ist daher speziell auf meine Bedürfnisse zugeschnitten und daher vielleicht für die Allgemeinheit nicht so interessant. Ich will trotzdem kurz davon berichten:
- Ein reiner TOS-Selector mit Platz für 4 Images. (Kein IDE, kein Fast-RAM usw.)
- In den CPU-Sockel steckbar -- jegliche zu lötenden Umbauten kommen an meinem STE nicht Frage.
- TOS kann via Software gewählt werden, das Gehäuse muss also nicht für einen Taster o.dgl. durchlöchert werden.
- Kann optional auch Cartridges (64k oder 128k) simulieren. (Damit ließe sich auch ein Boot-Menü programmieren.)
-
In den CPU-Sockel stecken klingt interessant, einerseits um zu sehen wie du das mechanisch gelöst hast, und außerdem musst du ja unterbinden, dass wenn eine ROM-Adresse angesprochen wird, dass die originalen TOS-ROMs still halten, oder baust du die einfach aus? Und dann natürlich noch die Frage, ob auch der Blitter an diese ROMs ran kommt...
-
In den CPU-Sockel stecken klingt interessant, einerseits um zu sehen wie du das mechanisch gelöst hast, und außerdem musst du ja unterbinden, dass wenn eine ROM-Adresse angesprochen wird, dass die originalen TOS-ROMs still halten, oder baust du die einfach aus? Und dann natürlich noch die Frage, ob auch der Blitter an diese ROMs ran kommt...
CPU-Sockel: Ich habe mir einen PLCC-"Plug" von der Firma cab Produkttechnik anfertigen lassen, also quasi etwas in Form eines PLCC-ICs, das dann auf die Adapter-Platine gelötet und in den Sockel auf dem STE gesteckt wird. Die CPU kommt dafür auf den Adapter. (Wenn ich einen günstigen 68000 in PLCC finde, kaufe ich ihn, dann hat der Adapter seine eigene CPU und ich muss nicht das Original aus dem STE verbauen.)
Originale TOS-ROMs: Müssen in der Tat raus -- aber die sind ja zum Glück gesockelt.
Blitter: Für den Blitter ist das Flash-ROM zugreifbar.
Aber ich habe ja erst heute die Platinen bestellt (und dabei 10 Euro versenkt, weil ich bei der ersten Bestellung Murks hochgeladen habe und man Bestellungen nicht stornieren kann :( ). Ob's wirklich geht, so wie ich mir das vorstelle, werde ich berichten, wenn das Teil zusammengebaut ist.
-
PLCC MC68000 in 8Mhz müsste ich noch haben ...
-
Wenn Lukas Frank keinen hat, ich habe hier ein paar 68HC001-8FN.
Die 001 unterscheiden sich zum 000 das sie auch im 8-Bit-Mode wie die 68008 laufen können.
Der Pin zum Umschalten ist beim 68000* nicht belegt und kann beim 001 unbeschalten bleiben, er läuft dann im 16-Bit-Mode.
Sind Original Motorola-Chips.
Im Tausch gegen 1 Platine gerne abzugeben. ;-)
*Den 68001 gibt es nur in PLCC, beim DIL-Gehäuse sind alle Pins des 68000 bekanntlich belegt.
CPU-Sockel: Ich habe mir einen PLCC-"Plug" von der Firma cab Produkttechnik anfertigen lassen, also quasi etwas in Form eines PLCC-ICs, das dann auf die Adapter-Platine gelötet und in den Sockel auf dem STE gesteckt wird. Die CPU kommt dafür auf den Adapter.
Wieviel kostet so ein Teil?
-
Wieviel kostet so ein Teil?
Ich müsste die Rechnung raussuchen, um 100%ig sicher zu sein, aber ich habe etwas von 20 € im Kopf. Jedenfalls günstiger als bei RS Components und günstiger als ein Zweit-STE zum Verbasteln.
-
Wie machst du das mit den ROM Signalen von der GLUE, woher kommen die ?
-
Ich kann mir vorstellen, dass er die Chipselect-Signale mit einem Adressdecoder einfach selber generiert.
-
Deshalb frage ich ...
Die STE GLUE hat ja ROM Signale von 0 bis 6 für größeres TOS. Im ST gehen bis 768kb ...
-
Wieviel kostet so ein Teil?
Ich müsste die Rechnung raussuchen, um 100%ig sicher zu sein, aber ich habe etwas von 20 € im Kopf. Jedenfalls günstiger als bei RS Components und günstiger als ein Zweit-STE zum Verbasteln.
20€ sind OK.
-
Ich kann mir vorstellen, dass er die Chipselect-Signale mit einem Adressdecoder einfach selber generiert.
Exakt. Der GLUE (bzw. GSTMCU im STE) generiert nur Select-Signale für Lesezugriffe auf die ROM-Bereiche. Um das Flash aber zu beschreiben, muss ich diese auch für Schreibzugriffe erzeugen. (Und der CPU DTACK zurückmelden.) Folglich ist ein eigener Adressdecoder an Bord, wie bei den Flash-ROM-Lösungen von Popsel/Ppera auch.
-
So, ich habe die Tatsache genutzt, dass ich endlich mal wieder etwas Freizeit hatte, um den Adapter aufzubauen und in Betrieb zu nehmen. Von einem kleinen Bug in der Logik des CPLD abgesehen, funktionierte alles auf Anhieb und ohne Hardwarepatches etc. Nicht schlecht, wenn man bedenkt, dass ich mir gerade erst ein bisschen Verilog beigebracht habe, auf diversen Zugfahrten, die ich in der letzten Zeit so machen musste.
Jetzt habe ich TOS 2.06, TOS 1.62, EmuTOS und das STE-Diagnose-Cartridge verfügbar und kann via Software umschalten. 8) Fotos des eingebauten Adapters (zum Test noch außerhalb des Gehäuses) und der Rückseite samt PLCC-Adapter siehe Anhang.
-
Schickes Rot. 8)
"Punktlandung" beim Entwickeln ist immer toll! :)
Passt das noch mit der Blechabschirmung?
-
Passt das noch mit der Blechabschirmung?
Ich habe die Abdeckung einmal lose aufgelegt: Ja, sie passt, gerade noch so -- wie geplant. Die einzige Stelle an der ich mich um ca. 1 mm vermessen habe, ist die Kunststoffstütze in der Gehäusemitte. Aber ich mache aus dem Bug ein Feature ;): Die Stütze bekommt eine kleine geschnitzte Kerbe, dann stützt sie auch das Adapterboard und verhindert, dass es sich z.B. beim Transport des STE aus dem CPU-Sockel hebelt.
-
Die einzige Stelle an der ich mich um ca. 1 mm vermessen habe, ist die Kunststoffstütze in der Gehäusemitte. Aber ich mache aus dem Bug ein Feature ;): Die Stütze bekommt eine kleine geschnitzte Kerbe, dann stützt sie auch das Adapterboard und verhindert, dass es sich z.B. beim Transport des STE aus dem CPU-Sockel hebelt.
:D
-
Tolle Sache! Aber wie schaltest du bei (teil)defektem STE auf das DIAG-Cardridge um?
-
Auch daran wurde gedacht: das CPLD aktiviert das Cartridge, wenn beim Einschalten/Reset ein auf ein Testpad geführter Eingang low ist. Ich überlege, den mit dem Eingangspin für die rechte Maustaste zu verbinden.
-
? Rechte Maustaste ?
Wie soll das gehen? Die hängt an der Tastatur.
-
? Rechte Maustaste ?
Wie soll das gehen? Die hängt an der Tastatur.
Ja, und? Das hindert mich doch trotzdem nicht daran, ein Kabel von dort zu verlegen. (Steckbar natürlich, damit die Tastatur weiterhin ausbauen kann.)
-
Gab es da nicht ein Problem wenn man beim einschalten des ST/TT/Falcon eine Maustaste drückt?
Ich meine da war was das der 6301 in der Tastatur dann in einem falschen Modus startet und die Tastatur dann nicht richtig funktioniert.
Zum ausprobieren bin ich jetzt leider zu weit von einem ST entfernt.
Ich hoffe das mich meine Erinnerung hier nicht fehlleitet...
-
Stimmt, mag er nicht. Dann halt einer der -- bei mir eh ungenutzen -- Joystick-Ports an der Seite. Muss ich halt eine Drahtbrücke stecken, wenn ich das Cartridge beim Starten geladen haben möchte.
-
Lege das Signal doch auf ein unbenutztes Signal am Druckerport (aufpassen dass dein Druckerkabel da nicht belegt ist) und bastle dir ein "Diagnosedongle" für den Druckerport...
-
Ich freu mich immer zu lesen wie 1st1 jemanden der sich mit der Materie sehr gut auskennt aufklären muss. Letzten Tage mehrfach passiert.
Czietz hast du das tos komplett selbst ausdekodiert oder hast du die Rom Leitungen verwendet ?
-
Meines Wissens liegt ein Joystickknopf oder Maustaste nicht als separates Signal am Tastaturport an. Und der Tastaturstecker innerhalb eines 1040 ist bis auf den Verpolungsschutz auch komplett belegt. Und spielen wir das Spielchen mal weiter, solch eine Platine wäre sicher auch für einen Mega-ST oder Mega-STE, evtl. sogart TT interessant. Da finde ich dann die Sache mit dem Diagnosestecker am Duckerport viel eleganter...
Und jetzt kommst du mit deiner Aufklärung.
-
Nun, der Vorschlag von 1ST1 wäre genauso umsetzbar -- bei mir ist es trotzdem der Joystick/Jagpad-Port geworden, für den ich keine Verwendung habe. Steckt dort nun beim Start eine Brücke zwischen zwei Pins, startet das Cartridge. Sollte ich die Platine mal für einen anderen Atari umdesignen, kann man den Testpunkt ja immer noch anders verdrahten.
Czietz hast du das tos komplett selbst ausdekodiert oder hast du die Rom Leitungen verwendet ?
Die Zugriffe auf 0xE00000 - 0xE3FFFF und 0xFA0000 - 0xFBFFFF dekodiere ich selbst aus. Wie weiter oben im Thread geschrieben, ist das für Schreibzugriffe sowieso nötig. Nur /ROM2 vom GLUE brauche ich, um den Zugriff auf 0x000000 - 0x000007 (beim Booten) abzufangen. Um den kompletten Adressbus anzuschließen, hätte ich nämlich ein CPLD mit mehr Pins benötigt.
-
Jetzt habe ich TOS 2.06, TOS 1.62, EmuTOS und das STE-Diagnose-Cartridge verfügbar und kann via Software umschalten. 8)
Wie hast Du denn das Umschalten per Software realisiert? (Für mich wäre das auch interessant, wenn ich irgendwann mein Flash-ROM zum Laufen bekommen sollte. Wo ich das Gehäuse verletzen soll, um den Umschalter unterzubringen, ist nämlich auch noch so ein ungelöstes Problem ...)
-
Ein beliebiger Schreibzugriff im Supervisormodus auf 0xE4xxxx schaltet auf den ersten Slot, auf 0xE5xxxx schaltet auf den zweiten Slot usw. Man kann sich kompliziertere Verfahren ausdenken, z.B. dass die Umschaltung erst scharf geschaltet werden muss, aber bislang hatte ich keine Probleme mit Software, die fälschlicherweise das TOS umgeschaltet hat.
Wichtig: Unmittelbar nach der Umschaltung ist ein (ebenfalls per SW ausgelöster) Reset nötig, weil man dem Rechner ja das TOS unter den Füßen weggezogen hat.
-
Wie hast Du denn das Umschalten per Software realisiert? (Für mich wäre das auch interessant, wenn ich irgendwann mein Flash-ROM zum Laufen bekommen sollte. Wo ich das Gehäuse verletzen soll, um den Umschalter unterzubringen, ist nämlich auch noch so ein ungelöstes Problem ...)
Im Forum64 verwenden sie ab und zu Reedkontakte, die sich mit Magneten schalten lassen und irgendwie merkt sich das die aktuelle Einstellung übers Ausschalten des Rechners hinaus. Vielleicht über ein Akkugepuffertes Flipflop. Vielleicht wäre das ja was?
-
Wie hast Du denn das Umschalten per Software realisiert? (Für mich wäre das auch interessant, wenn ich irgendwann mein Flash-ROM zum Laufen bekommen sollte. Wo ich das Gehäuse verletzen soll, um den Umschalter unterzubringen, ist nämlich auch noch so ein ungelöstes Problem ...)
Im Forum64 verwenden sie ab und zu Reedkontakte, die sich mit Magneten schalten lassen und irgendwie merkt sich das die aktuelle Einstellung übers Ausschalten des Rechners hinaus. Vielleicht über ein Akkugepuffertes Flipflop. Vielleicht wäre das ja was?
Ein 8 pol AVR/PIC merkt sich das ohne Akku. Zumindest wäre das meine Wahl.
-
Ein beliebiger Schreibzugriff im Supervisormodus auf 0xE4xxxx schaltet auf den ersten Slot, auf 0xE5xxxx schaltet auf den zweiten Slot usw.
Danke für die Erklärung! Auf so eine einfache Idee muss man erst mal kommen :)
Dann nehme ich an, beim Flashen beschreibst Du nur E0.0000 bis E3.999, also nur den jeweils ausgewählten Bereich und niemals das ganze EEPROM ...
Man kann sich kompliziertere Verfahren ausdenken
Mir würde gefallen, den Datenbus einzubeziehen und die Auswahl in einem EEPROM zu speichern, so dass man vor dem Auswählen die letzte Auswahl auslesen und anzeigen kann. Und vielleicht sogar dass man Namen dazu speichern kann, die dann auf den Umschaltbuttons angezeigt werden. Das wäre aber schon wieder ein Projekt für sich :o
Ein 8 pol AVR/PIC merkt sich das ohne Akku. Zumindest wäre das meine Wahl.
Das wäre auch mein Favorit - es sei denn, man könnte es sogar ins CPLD integrieren ...
-
Ein beliebiger Schreibzugriff im Supervisormodus auf 0xE4xxxx schaltet auf den ersten Slot, auf 0xE5xxxx schaltet auf den zweiten Slot usw.
Danke für die Erklärung! Auf so eine einfache Idee muss man erst mal kommen :)
Dann nehme ich an, beim Flashen beschreibst Du nur E0.0000 bis E3.999, also nur den jeweils ausgewählten Bereich und niemals das ganze EEPROM ...
Man kann sich kompliziertere Verfahren ausdenken
Mir würde gefallen, den Datenbus einzubeziehen und die Auswahl in einem EEPROM zu speichern, so dass man vor dem Auswählen die letzte Auswahl auslesen und anzeigen kann. Und vielleicht sogar dass man Namen dazu speichern kann, die dann auf den Umschaltbuttons angezeigt werden. Das wäre aber schon wieder ein Projekt für sich :o
Ein 8 pol AVR/PIC merkt sich das ohne Akku. Zumindest wäre das meine Wahl.
Das wäre auch mein Favorit - es sei denn, man könnte es sogar ins CPLD integrieren ...
sehe das so ähnlich wie Michael960. per software umschalten, das hätte schon was. Aber der Atmel von PPera'schen Lösung langt mir auch. Mein STe steht z. Zt. im Regal und wird nicht genutzt. Ich will den aber auch nicht, wie meine anderen ST's "verschandeln". Irgendwie wünsche ich mir einen Pak68/3 mit ordentlich fastram. Denke damit kann man den ST's wieder neues leben einhauchen. @tuxie, was macht das ethernetinterface? der moderne atari von heute möchte auch ins Netz ;)
-
Dann nehme ich an, beim Flashen beschreibst Du nur E0.0000 bis E3.999, also nur den jeweils ausgewählten Bereich und niemals das ganze EEPROM ...
Genau. Das hat den Vorteil, dass ich ppera's Flash-Programm für den ST weiterverwenden kann.
Mir würde gefallen, den Datenbus einzubeziehen und die Auswahl in einem EEPROM zu speichern, so dass man vor dem Auswählen die letzte Auswahl auslesen und anzeigen kann.
Zwei Bits des Datenbus sind bei mir angeschlossen -- und ja, das erlaubt mir in der Tat das Zurücklesen der aktuellen Auswahl. Dauerhaft speichern kann ich aber nicht. Das CPLD selbst bietet keinen internen EEPROM (von dem für die Konfigurationsbits abgesehen, den man aber nur mit dem Programmierkabel beschreiben kann). Evtl. bekäme man die State-Machine für ein SPI-EEPROM noch in den 72 Makrozellen unter, keine Ahnung. Einen Mikrocontroller nur als Speicherbaustein einzusetzen widerstrebte mir irgendwie, wäre aber vermutlich die einfachste Lösung.
-
Einen Mikrocontroller nur als Speicherbaustein einzusetzen widerstrebte mir irgendwie, wäre aber vermutlich die einfachste Lösung.
Da kann ich Dich gut verstehen. Aber es ist einfach und billig.
Aber es ist schon Irre da ja so ein kleiner AVR schon 1 Mips pro MHz hinbekommt, da braucht ein 68000 8MHz dafür! (Ja ich weis, Mips ist nicht alles...)
Und AVRs gehen je nach Typ bis 20MHz...
-
... CPU-Sockel: Ich habe mir einen PLCC-"Plug" von der Firma cab Produkttechnik anfertigen lassen, also quasi etwas in Form eines PLCC-ICs, das dann auf die Adapter-Platine gelötet und in den Sockel auf dem STE gesteckt wird...
Ich habe mir das gerade noch mal angeschaut, weil meinem Falcon (und vielleicht auch dem TT) ein flashbares TOS sicher auch gut zu Gesicht stünde. Muß wegen mir nicht unbedingt vom Falcon aus flashbar sein, eine Lösung per (z.B.) JTAG-Adapter tät's mir auch (ließe sich mit einem kleinen FPGA oder CPLD sicher realisieren).
Kann man den "PLCC-Stecker" (müsste ja in dem Fall ein 44-poliger sein) bei denen "einfach so" bestellen?
-
Kann man den "PLCC-Stecker" (müsste ja in dem Fall ein 44-poliger sein) bei denen "einfach so" bestellen?
Einfach freundlich nach einem Angebot fragen. Ich habe das Teil auch "einfach so" (also als Privatperson) dort bestellen können. Natürlich musste ich im Voraus zahlen, was ich in diesem Fall aber vollkommen OK finde.