32 KB (EP)ROM-Simulator mit RP2040 Pico-Board

[Mi N. (msx)]

Zum Spielen mit älteren Prozessoren braucht man in der Regel 
Programmspeicher bzw. Simulatoren für DIL-Gehäuse, die sich möglichst 
zügig umprogrammieren lassen. Frühere Ausführungen für ROM-Simulatoren 
wurden vielfach per LPT1 angesprochen, was mit heutigen PCs kaum noch 
möglich ist.

Der RP2040 kann zum einen seriell angelieferte Daten entgegennehmen und 
in seinem internen RAM speichern und ist zum anderen auf Grund seinen 
hohen Taktrate gut geeignet, diese schnell als Datenbytes auszugeben.

Die gezeigte Schaltung basiert auf dem RP2040 Pico-Board, das genug 
GPIO-Leitungen frei hat, um die an GPIO0 – GPIO14 angelegte Adresse 
einzulesen und an den Ausgängen GPIO15 – GPIO22 das zugehörige Byte 
auszugeben. Da ältere CPUs in der Regel mit 5 V Pegeln arbeiten, werden 
für die Adressleitungen 74LVC541-Puffer benötigt, um die 3,3 V Pegel für 
den RP2040 zu erhalten.
Ausgangsseitig gibt es einen Puffer 74HCT541, der zu den angelegten 3,3 
V Pegeln 5 V Pegel liefert. Zudem hat er idealerweise zwei 
Freigabeeingänge, die bestens zu den Signalen /CS und /OE passen.
Ein RP2040 kann maximal ein ROM mit 256 KB simulieren, weshalb hier für 
eine mögliche Erweiterung ein 34-pol. Pfostenstecker gewählt wurde, der 
auch das /Reset-Signal liefern kann.

Die Daten werden über eine PIO-simulierte RS232-Schnittstelle mit 500 kB 
empfangen. Dadurch können auch ältere Rechner (ggf. std. Baudrate 
einstellen) Dateien im Intel-Hex oder Motorola S-Format übertragen. Da 
es sich hierbei um ASCII-Dateien handelt, reicht die Ausgabe über ein 
'type' wie es im Beispiel 'bas.bat' gezeigt wird.

Nach Initialisierung des Programms wird die Routine 'rom_simulation()' 
ausgeführt, die permanent die Adressleitungen einliest und das 
zugehörige Datenbyte aus dem 'rom_puffer[]' an PIO1-SM0 übergibt, 
welches die schnelle Ausgabe erledigt. Bei 200 MHz Taktfrequenz des 
RP2040 beträgt die max. Zugriffszeit 120 ns. 70 ns werden bei 360 MHz 
erreicht.
Da jeder Zeichenempfang diese Routine per ISR unterbricht, wird mit 
jedem ser. Zeichen automatisch ein /Reset ausgelöst.

Damit je nach Speicherbelegung im Zielsystem und benötigter ROM-Größe 
2732 – 27128 die Daten an der richtigen Adresse im 'rom_puffer[]' 
liegen, kann die übertragene Adresse maskiert "=Sxxxx<CR>" (Maske = xxxx 
- 1) und mit einem Offset versehen werden: "=Oxxxx<CR>".

Der ROM-Simulator kann auch 'stand alone' arbeiten. Dazu wird beim 
Programmstart das zuletzt unter Index = 0 abgelegte Programm ins RAM 
geladen. Für das Abspeichern gibt es den Befehl "=R{index}<CR>", der 
optional das aktuelle Programm an bis zu acht unterschiedlichen Stellen 
sichern kann: Index 0 – 7. Fehlt eine Angabe des Index wird 0 gewählt.
Zurückgelesen werden diese Bereiche mit dem Befehl "=L{index}<CR>" - 
ebenfalls mit default = 0 wie beim Programmstart.

Das Programm ist ein Projekt für Segger Embedded Studio und die Bilder 
zeigen Schaltung, Aufbau und das Adapterkabel. Platinen bzw. die 
Fertigungsdateien dafür könnte ich bei Interesse bereitstellen.

[Mi N. (msx)]

Bei der eingangs gezeigten Schaltung ist Q1 schlecht gezeichnet und 
falsch. Es muß ein NPN Typ sein wie z.B. BC817. Das Layout der 
Leiterplatte stimmt dennoch.
Um das Schaltbild nicht einfach zu wiederholen, wird ein Schaltbild 
gezeigt, welches Speicher mit bis zu 256 KB simulieren kann. Dabei wird 
kein original Pico-Board verwendet, sondern die Ausführung eines anderen 
Anbieters, welches alle GPIO-Leitungen frei verfügbar auf den 
Stiftleisten herausgeführt hat. Diese Boards kosten <= 2,50 Euro und 
sind auch mit 4 bzw. 16 MB Flash-Speicher mit der Zusatzbezeichnung 
'Ultimate' erhältlich. Nebenbei: Für Anwendungen mit dem ADC dürfte der 
dort verwendete LDO wegen geringeren Rauschens von Vorteil sein.

Das oben gezeigte Programm ist leicht angepasst worden. Der für die 
Baudrate verwendete PIO0-SM0 Teiler verwendet nun den ganzzahligen und 
fraktionalen Teil damit 'krumme' Baudraten wie zum Beispiel 460800 Baud 
genauer eingestellt werden können.

Dann gibt es eine neue Version, bei der nun Core1 des RP2040 allein den 
Ablauf der Simulationsroutine erledigt. Der Vorteil ist, daß Interrupts 
beim RX-Empfang die Routine nicht mehr unterbrechen und zwangsläufig ein 
/Reset ausgegeben werden muß. Soll statt RS232 die USB-Schnittstelle 
verwendet werden (Arduino-IDE), müssen Unterbrechungen durch ISRs auf 
jeden Fall vermieden werden, was nur mit Core1 ereichbar ist.
Unter http://mino-elektronik.de/Gemischtes/ROM-Simulator.html finden 
sich die neuen Versionen und auch die Fertigungsdaten für die Platine.

[Denny A. (denny_a)]

Wäre es mit dem gezeigten ROM-Simulator möglich, einen 2716 EPROM (2 
Kbit, 11 Adressleitungen, 8 Datenleitungen, 5V-Pegel) zu simulieren?
Gibt es dafür Besonderheiten bei der Adressmaske oder beim Offset, oder 
kann der 2716 direkt abgebildet werden?

[Mi N. (msx)]

Da beim 2716 Pin 21 (Vpp) wohl auf Vcc liegt, würde das einem 2732 
entsprechen, bei dem der Code in der oberen Hälfte des Speichers liegt 
(A11 = '1'). Dafür könnte man beim erzeugten .hex-Code die 
Speicheradresse mit einem Offset von 0x800 versehen. Alternativ 
verbindet man Pin 21 nicht, wodurch dann durch den 
'pull-down'-Widerstand A11 = '0' wird.

Da ich 2708/2716 garnicht mehr auf dem Schirm hatte, hatte ich 
MIN_ROM_SIZE auf 0x1000 gesetzt.
Die aktuellen Versionen sind jetzt für den 2716 (0x800) angepaßt!

[Vanye R. (vanye_rijan)]

Die interessante Frage ist noch ob so ein Simulator auch wirklich in 
jedem alten System funktioniert. Die Hardwaresimulation ist ja durchaus 
anspruchsvoll wie man an der hohen notwendigen Taktfrequenz sieht. Und 
damals hat ja auch nicht jeder immer perfekt nach Datenblatt die 
Hardware designt. Da koennte es schon auch ein paar Geraete geben wo das 
Timing zu knapp ist.

Vanye

[Mi N. (msx)]

Was willst Du Uns eigentlich sagen? Deine Angst vor aktuellen µCs gehört 
doch eher in die Schwurbelecke vom esoterischen Wochenblatt.

Zeig mit eine einzige Schaltung, bei der ein 450 ns EPROM nicht durch 
diesen Simulator ersetzt werden kann.

[Wastl (hartundweichware)]

Vanye R. schrieb:
> Die interessante Frage ist noch ob so ein Simulator auch wirklich in
> jedem alten System funktioniert.

Jawoll, einfach mal so ein schönes (für mich beeindruckendes)
Projekt schlechtreden. Was hast du davon?

[F. P. (fail)]

Mi N. schrieb:
> Zeig mit eine einzige Schaltung, bei der ein 450 ns EPROM nicht durch
> diesen Simulator ersetzt werden kann.

Wie lange braucht diese PROM-Simulation, bis das erste Byte ausgegeben 
werden kann? Vielleicht beginnt die CPU den PROM zu lesen, bevor diese 
Simulation bereit ist...

[Roland F. (rhf)]

Hallo,
F. P. schrieb:
> Wie lange braucht diese PROM-Simulation, bis das erste Byte ausgegeben
> werden kann?

Sicherlich weniger als ein 450ns-EPROM braucht um die Daten 
bereitzustellen.

rhf

[Vanye R. (vanye_rijan)]

> Zeig mit eine einzige Schaltung, bei der ein 450 ns EPROM nicht durch
> diesen Simulator ersetzt werden kann.

Stimmt, das kann ich nicht. ICh hab naemlich niemals eine Schaltung 
gesehen wo so lahme Eproms drin waren. Eigentlich waren das immer 200, 
150 oder 120er. Muss wohl an der Gnade der spaeten Geburt liegen. :)

Vanye

[F. P. (fail)]

Roland F. schrieb:
> Hallo,
> F. P. schrieb:
>> Wie lange braucht diese PROM-Simulation, bis das erste Byte ausgegeben
>> werden kann?
>
> Sicherlich weniger als ein 450ns-EPROM braucht um die Daten
> bereitzustellen.
>
> rhf

Hast Du Dir überhaupt den Code angeschaut? Der macht so einiges bevor er 
anfängt, die Daten bereitzustellen.

[Soul E. (soul_eye)]

F. P. schrieb:
> Wie lange braucht diese PROM-Simulation, bis das erste Byte ausgegeben
> werden kann? Vielleicht beginnt die CPU den PROM zu lesen, bevor diese
> Simulation bereit ist...

Du meinst bevor ich mit dem Compilieren fertig bin und auf Upload 
gedrückt habe? Die meisten Emulatoren bedienen praktischerweise einmal 
den Reset-Pin, wenn sie startklar sind. Und Überraschung --

Mi N. schrieb:
> (...), der
> auch das /Reset-Signal liefern kann.

dieser Emulator tut das auch. Da hat also jemand mitgedacht :-)

[F. P. (fail)]

Soul E. schrieb:
> F. P. schrieb:
>> Wie lange braucht diese PROM-Simulation, bis das erste Byte ausgegeben
>> werden kann? Vielleicht beginnt die CPU den PROM zu lesen, bevor diese
>> Simulation bereit ist...
>
> Du meinst bevor ich mit dem Compilieren fertig bin und auf Upload
> gedrückt habe? Die meisten Emulatoren bedienen praktischerweise einmal
> den Reset-Pin, wenn sie startklar sind. Und Überraschung --

Nein, ich meinte nach dem Einschalten, wenn der ROM-Simulator wie von Mi 
N. erwähnt "stand alone" betrieben wird. Da wird die CPU erstmal 
Schrott-Code ausführen, bis der ROM-Simulator die Reset-Leitung 
runterzieht. Das kann gefährlich sein. Eine kleine Änderung an der 
Schaltung sollte jedoch Reset beim Einschalten per Hardware aktivieren 
können, bis es vom RP2040 explizit deaktiviert wird.

Vielleicht wäre ja ein FM16W08 praktischer, der wäre sofort startklar. 
Zum Beschreiben wird dann natürlich Reset aktiviert, so daß der Bus frei 
ist. Die Puffer könnten entfallen. Also ein FM16W08 statt der drei 
Puffer-Chips. (Hat aber nur 16 Kbit nicht 32 KByte. Für einen 2716 
reicht's. Dann eben ein FM18W08-SG für 32 KByte...)

[Mi N. (msx)]

F. P. schrieb:
> Nein, ich meinte nach dem Einschalten, wenn der ROM-Simulator wie von Mi
> N. erwähnt "stand alone" betrieben wird. Da wird die CPU erstmal
> Schrott-Code ausführen, bis der ROM-Simulator die Reset-Leitung
> runterzieht. Das kann gefährlich sein.

Oh, Lebensgefahr?
In den 70ern waren wohl 74LS14 mit RC-Glied eine typische 
Resetschaltung, die die CPU beim Einschalten aus der 'Gefahrenzone' 
hielt. Danach war ein TL7705 ein schönes IC, welches neben definiertem 
Resetimpuls - positiv für 8051 und negativ für den Rest der Welt - eine 
Unterspannungserkennung und einen /Reseteingang bereitstellte.
Mit diesen Schaltungen ist die CPU nach Anlegen der Versorgungsspannung 
für 0,1 - 0,3 s blockiert. Selbst so 'modernes Zeugs' wie TS809 liefert 
einen typischen Resetimpuls von 0,2 s.

Der RP2040 startet sehr schnell und ich habe aus den genannten Gründen 
keinen Anlass gesehen, das Einschaltverhalten des Simulators 
nachzumessen. Sollte dies jemals ein Problem sein, kann man beim Start 
des RP2040 als 1. Befehl einen /Reset ausgeben oder mit einem 
pullup-Widerstand an der Basis den BC817 aktivieren. Mehr möchte ich 
dazu nicht ausführen.

> Vielleicht wäre ja ein FM16W08 praktischer

Und an welchem Pin lade ich die .ihex oder .srec Datei in den Chip?

[F. P. (fail)]

Mi N. schrieb:
> F. P. schrieb:
>> Nein, ich meinte nach dem Einschalten, wenn der ROM-Simulator wie von Mi
>> N. erwähnt "stand alone" betrieben wird. Da wird die CPU erstmal
>> Schrott-Code ausführen, bis der ROM-Simulator die Reset-Leitung
>> runterzieht. Das kann gefährlich sein.
>
> Oh, Lebensgefahr?

Es könnte Peripherie so konfiguriert werden, daß Ausgang an Ausgang 
geht. Oder (selbst erlebt) die aktuelle Spur der Floppy wird formatiert 
(dazu reichte in den 70ern das Schreiben eines einzigen Bytes an die 
"falsche" Adresse), setzt aber voraus, daß der Floppy-Motor an ist.

> In den 70ern waren wohl 74LS14 mit RC-Glied eine typische
> Resetschaltung, die die CPU beim Einschalten aus der 'Gefahrenzone'
> hielt.

Ja, siehe Bild mit '241.

> Und an welchem Pin lade ich die .ihex oder .srec Datei in den Chip?

Reset aktivieren und per MCU den Bus (samt WE des FRAM/EEPROM) 
übernehmen.

[Mi N. (msx)]

F. P. schrieb:
> Reset aktivieren und per MCU den Bus (samt WE des FRAM/EEPROM)
> übernehmen.

Das bedeutet, Du benötigst zusätzlich ein FRAM, ohne etwas einsparen zu 
können. Eine Pegelanpassung 3,3 <-> 5 V muß weiterhin vorhanden sein.

Die Schaltung für 256 KB habe ich noch einmal korrigiert und 'schöner' 
gezeichnet und mit R23 den oben erwähnten pullup-Widerstand eingefügt, 
der die nun 2 x Reset-Ausgänge direkt beim Einschalten aktiv hält. Die 
Beschaltung für RES+ ist optional.

[F. P. (fail)]

Mi N. schrieb:
> Das bedeutet, Du benötigst zusätzlich ein FRAM, ohne etwas einsparen zu
> können. Eine Pegelanpassung 3,3 <-> 5 V muß weiterhin vorhanden sein.

Nein, muß nicht vorhanden sein, wenn man eine 5-V-MCU nimmt. Ich hatte 
absichtlich einen 5-V-FRAM genannt.

Aber natürlich ist es interessant, das (fast) ganz in Software zu 
machen.

[Mi N. (msx)]

F. P. schrieb:
> Nein, muß nicht vorhanden sein, wenn man eine 5-V-MCU nimmt. Ich hatte
> absichtlich einen 5-V-FRAM genannt.

Gerade habe ich einen R6501 auf dem Tisch. Bei anliegendem /Reset sind 
dessen Adressleitungen auf '0' oder '1' oder fungieren als Binärzähler.
Gleiches Problem ergibt sich bei /CS, /RD und /WR, welche zumeist von 
einem LS139 u.a. auch für RAM, EPROM und VIA/PIA erzeugt wurden.
Diese Leitungen willst Du jetzt mit einem anderen Controller 
'überschreiben', in der Hoffnung, daß die richtige Adresse im FRAM 
angesprochen wird?

Mache einen Schaltplan, wie Du die Sache angehen würdest und vielleicht 
auch eine Kostenaufstellung für 32 KB.
Dann können wir darüber reden.

[F. P. (fail)]

Mi N. schrieb:
> Gerade habe ich einen R6501 auf dem Tisch. Bei anliegendem /Reset sind
> dessen Adressleitungen auf '0' oder '1' oder fungieren als Binärzähler.

Autsch. Das ist natürlich tödlich für meine Variante. Ich komme aus der 
Z80-Ecke und da ist während des Resets der Bus frei.