Einfach programmierbares Modul für ROM-Port?

[czietz]

Hallo,

so eine Platine behalte ich, zwei sind reserviert, ich habe also aktuell noch 7 Platinen abzugeben. Ich dachte an folgende zwei Möglichkeiten. (Alle Preise verstehen sich inkl. Verpackung und Versand innerhalb Deutschlands.)

1. Nur die Platine = 5 €
Wer auf die Programmierbarkeit des Moduls verzichten kann, weil er z.B. einen EPROM-Programmer besitzt, kann sich so z.B. sein eigenes Testkit bauen. Benötigte Teile:

- 2 Flash-ICs (z.B. AM29F010, SST39SF010 [erhältlich z.B. bei Conrad]) in DIP-32. Manche EPROMs mit passenden Pinout sind auch möglich, sprecht mich ggf. an. ... und natürlich eine Möglichkeit, diese vor dem Einbau zu programmieren.
- 1 SMD-Kondensator 0805 100 nF
- 1 Drahtbrücke, weil der ATmega dann nicht bestückt ist.

Evtl. ist es bei dieser Lösung sogar möglich, den nicht benötigten Teil der Platine abzusägen, um sie mechanisch für einen MegaST passend zu machen. Die Kompatibilität zum MegaST kann ich mangels Testmöglichkeit aber nicht versprechen.

2. Platine + programmierter ATmega8515 = 15 €
Damit könnt Ihr das programmierbare ROM-Port-Modul aufbauen, das ich auch einsetze. Die Software wird über eine serielle Schnittstelle ins Modul geladen und kann selbstverständlich auch wieder  geändert/ersetzt werden. Benötigte Teile:

- 2 Flash-ICs (z.B. AM29F010, SST39SF010 [erhältlich z.B. bei Conrad]) in DIP-32.
- 2 SMD-Kondensatoren 0805 100 nF
- 4 SMD-Widerstände 0805 10 kΩ (Pullups/-downs, exakter Wert unkritisch)
- 2 SMD-Dioden z.B. 1N4448 (genauer Typ unkritisch)
- 2 3-polige Stiftleisten für die serielle Schnittstelle und die Stromversorgung beim Programmieren

- ... und natürlich eine serielle Schnittstelle mit 5V-TTL-Pegel, z.B. ein USB-zu-seriell-Kabel. Wenn dieses auch 5 V Spannungsversorgung liefert, kann es gleichzeitig auch die Versorgung beim Programmieren der Flash-ICs übernehmen.

Schaltplan und Anleitung, wie die Programmierung abläuft, lege ich bei. Falls gewünscht, kann ich ein Python-Skript bereitstellen, das die Flash-Bausteine aus einer Intel-HEX-Datei programmiert.

Bei Interesse schreibt mir bitte eine E-Mail: czietz(at)gmx(punkt)net, dann können wir den Rest klären. Bitte habt Verständnis, dass ich mich um die Option 2 erst nach den Osterfeiertagen kümmern kann. Die ATmegas müssen ja auch bestellt und programmiert werden.

[tin]

Ein dickes "Danke" an czietz für die Mühe und den hilfreichen Support! Die Karte macht das Testen der ROMs auf echter Hardware um einiges leichter, genau wie erhofft.

[ditto]

Dem kann ich mich nur anschließen! Vielen Dank auch von mir.

[czietz]

Es ist übrigens noch eine Platine verfügbar ‒ oder vielmehr wieder verfügbar geworden. Falls also jemand ein Programmiergerät hat und noch ein ROM-Port-Modul bauen will...

Wahlweise kann ich auch noch einen ATmega8515 dazu organisieren und programmieren, dann sind die Flash-ICs auf dem Modul bekanntlich stand-alone programmierbar. Preise siehe weiter oben; bei Interesse bitte PM.

Übrigens soll das Modul laut Auskunft von neogain http://forum.atari-home.de/index.php?topic=11799.msg206214#msg206214 auch mechanisch in einen MegaST passen.

[czietz]

Bekanntermaßen (siehe z.B. Profibuch) müssen Programme für ein ROM-Cartridge speziell erstellt werden. Es ist nicht einfach möglich, ein PRG- oder TOS-File irgendwie ins Cartridge zu brennen und dann von dort auszuführen, da fast alle Programme davon ausgehen, dass sie im RAM laufen, also z.B. reloziert werden wollen und einen beschreibbare Daten-Bereich erwarten.

Um die Nutzung von existierenden Programmen mit meinem ROM-Modul zu erleichtern, habe ich einen kleinen Wrapper geschrieben, den man zusammen mit dem gewünschten Programm (normale TOS/PRG-Datei) ins Flash-ROM schreibt, sodass man nun einfach Programme vom ROM-Modul starten kann. Sinnvoll kann das z.B. sein, um auf einem Atari ohne funktionierenden Laufwerke ein Testprogramm zu starten. Oder um einen Treiber für eine nicht-autobootfähige Festplatte nachzuladen, ohne eine Diskette nutzen zu müssen.

Z.Zt. nicht implementiert aber als Erweiterung denkbar wäre eine Option, das Programm schon beim Booten automatisch vom ROM-Modul starten zu lassen.

Noch hat mein Wrapper ein paar "Ecken und Kanten", aber falls Interesse besteht, kann ich ihn beizeiten hier veröffentlichen.

[Lukas Frank]

... falls Interesse besteht, kann ich ihn beizeiten hier veröffentlichen.

Das ist eine sehr Interessante Geschichte. Beschreibe doch mal etwas genauer wie das funktioniert und wo die Grenzen liegen und wie man dein Programm handhaben muss ...

[czietz]

Das betreffende Programm wird ins RAM kopiert. Anders lassen sich die Programme üblicherweise nicht zum Laufen bewegen. Dann muss ich etliche Dinge erledigen, die sonst GEMDOS beim Programmstart machen würde: relozieren, Base-Page ausfüllen etc. Danach läuft das Programm aber ganz normal und dürfte nicht merken, dass es aus dem ROM-Modul gestartet wurde.

Limitationen: Nachladen von weiteren Dateien ist nicht möglich, weil das ROM-Modul ja kein "echtes" Laufwerk ist, von dem Dateien gelesen werden können. Damit sind leider AES-Programme mit separaten RSC-File außen vor. Da mein ROM-Modul nur 64 kByte an (nutzbarem) Speicher bietet, ist das zugleich die Größenbeschränkung für Software. Zu guter letzt kann es natürlich sein, dass irgendein Programm den "Betrug" doch bemerkt und nicht läuft oder sich komisch verhält...

[mfro]

Ich nehme an, Du kennst das Pexec()-Beispielprogramm im Profibuch S. 258 + 259?

[czietz]

Ja, wobei Pexec hier gar nicht nötig ist. Beim Start vom Desktop legt GEMDOS auch für ein Programm vom Cartridge schon einen Prozess samt TPA (natürlich inkl. Base-Page) an.

[Lukas Frank]

Muss ich mir das so vorstellen das ich einige Programme vom Typ *.TOS z.B. zusammen mit deinem Starterprogramm verteilt auf zwei Eproms brenne. Und dann dein Programm durch doppelklicken von klein c:\ starte und das Programm welches ich nutzen möchte durch dein Programm nachgeladen wird per Dateiauswahl, oder ?

[czietz]

Im Prinzip ja. Derzeit wird allerdings nur ein Programm unterstützt, nicht mehrere. Das brennst Du mit meinem Code als "Vorspann" ins Flash, dann kannst Du's von Desktop aus von c:\ starten.

[1ST1]

Mich wundert diese Vorgehensweise. TOS unterstützt, wenn das ROM die richtige Datenstruktur beinhaltet, doch auch ein ROM-Laufwerk, welches unter dem Laufwerksbuchstaben "c:" (Kleines "c" im Gegensatz zum Festplattenlaufwerk "C:", großes "C") angesprochen im Cardridgeport angesprochen werden kann. Da ist der ganze Aufwand nicht nötig, und man kann da auch einen AUTO-Ordner anlegen.

[czietz]

Mich wundert diese Vorgehensweise. TOS unterstützt, wenn das ROM die richtige Datenstruktur beinhaltet, doch auch ein ROM-Laufwerk, welches unter dem Laufwerksbuchstaben "c:" (Kleines "c" im Gegensatz zum Festplattenlaufwerk "C:", großes "C") angesprochen im Cardridgeport angesprochen werden kann. Da ist der ganze Aufwand nicht nötig, und man kann da auch einen AUTO-Ordner anlegen.

Leider vollkommen falsch! Bitte lies doch das Profibuch oder die offizielle Atari-Dokumentation, bevor Du sowas schreibst. Der Desktop gaukelt Dir vor, dass als Laufwerk c: ein Dateisystem auf dem Cartridge wäre. Da ist aber kein Dateisystem sondern nur eine verkettete Liste aus Programmen mit ihren jeweiligen Einsprungpunkten. Weder sind Datendateien noch Ordner möglich. Und vor allem: Das ist eine Eigenart des Desktop, GEMDOS weiß davon nichts. Wenn ein Programm versucht, eine Datei c:\foobar.rsc zu laden, guckt GEMDOS auf der Festplatte.

[czietz]

Wenn es jemand ausprobieren möchte, angehängt ein Cartridge-Image, in das ich meinen Wrapper, MEMTEST.TOS und SYSINFO.PRG gepackt habe. Es ist im Format, das sich im Emulator (z.B. Steem oder Hatari) laden lässt.

Es würde mich interessieren, ob das mit den von Euch verwendeten TOS-Versionen usw. fehlerfrei läuft.

[Lukas Frank]

Ich besitze ein Atari Testmodul für den Romport und probiere das mal am Montag aus ...

Mit dem ROMMIX.TTP aus dem Pinatubo Paket sollte das in zwei Eprom Files zu splitten sein.

Code: [Auswählen]

# Kommandodatei fr ROMMIX:
# erstellen von 2 Eprom-Files fr 27256
# 1 IMG wird auf 2 Eproms aufgeteilt
# (C) 1992 M. Schwingen

# Puffergr”že setzen
bufsize 64k
# Directory setzen
chdir c:\pinatubo\rommix\

load cart.img 0 64k all -> 0 all
save rom_hi 32k <- 0 high
save rom_lo 32k <- 0 low



[KarlMüller]

Der Desktop gaukelt Dir vor, dass als Laufw......versucht, eine Datei c:\foobar.rsc zu laden, guckt GEMDOS auf der Festplatte.

Es ist richtig was Du schreibst!

Zu dem Problem gibt es auch Programme, welche im Prinzip aus dem ROM eine Diskette machen und durch den von Dir genannten Mechanismus einen Treiber ins System hängen. Wenn ich mich recht erinnere war in der c't mal sowas.

[Lukas Frank]

Kann denn jemand der die c´t Jahres DVDs hat mal nachschauen was es dort zum Thema Atari ST und Romport an Software eventuell gibt ?

[czietz]

Das wären dann wohl (Auszüge aus dem c't-Register):

EPROM-Bank für den Atari 520 ST
128 KByte für residente Software
Klaus Koerth
c't 1/86, S. 58

Solid-State-Disk für Atari ST
Schneller Nur-Lesespeicher am ROM-Port
Grogor von  Stangen, Peter Glasmacher
c't 9/86 S. 46

Doppelbank
c't-EPROM-Bank mit 256 KByte bestücken
Bernd Behr
c't 3/90, S. 290

EPROM-Prothese
32-Pin-EPROMs in 28-Pin-Projekten nutzen
Bernd Behr
c't 2/92, S. 160
(512 KByte ROM-Disk)

Dort gibt es einen Treiber, um den Speicherbereich des ROM-Ports als Laufwerk E: einzubinden; im Prinzip wie eine RAM-Disk, aber natürlich nur-lesend. Das macht aber sicherlich nur dann Spaß, wenn man mindestens die kompletten 128 kiByte des ROM-Ports nutzt (was mein Modul nicht kann) oder gar via Bank-Switching 256 kiByte oder 512 kiByte einbindet, wie in den letzten zwei Artikeln beschrieben, was mein Modul erst recht nicht kann.

[Lukas Frank]

Gerade mal in zwei 32kB Eproms gebrannt und läuft wunderbar ...



Wie hast das genau gemacht mit deinem Image ?

Kann man das mit anderen Programmen selber nachvollziehen ?

[czietz]

Um ein Programm so zu verpacken, kann ich Dir ein Python-Skript zukommen lassen, das meinen Wrapper darum packt. Hat aber alles noch Beta-Status. Zwei Programme, wie in dem Beispiel, werden vom Skript jedoch derzeit nicht unterstützt, das Image habe ich folglich mit dem Hexeditor zusammengesetzt.