Ein RAM/EPROM-Simulator simuliert, wie der Name schon andeutet, einen
RAM oder EPROM in der Schaltung.
Solche Simulatoren machen sich zu Nutze, dass EPROMs typischerweise
gesteckt (nicht eingelötet) werden, da man sie zum Löschen und
Programmieren zumeist ausbauen musste.
(In-System-Programmierung war damals, um 1995, noch nicht ĂĽblich.)
Man spart sich damit bei der Programmentwicklung den umständlichen
Steck- und Löschzyklus für den EPROM für jedes Programm-Update.
Mit dem Aufkommen von Flash-Speichern ist das Problem heutzutage
weitestgehend verschwunden.
Trotzdem ist RAM beim Schreiben immer noch schneller als Flash.
Weiterhin sind die unterschiedlichen EPROM-Typen trotz unterschiedlicher
Speichergröße weitestgehend pinkompatibel, was die Konstruktion
von Programmiergeräten als auch Simulatoren erleichtert.
SchlieĂźlich wurden statische RAM-Schaltkreise pinkompatibel
zu EPROMs hergestellt.
Diese haben nur einen zusätzlichen Anschluss zum Beschreiben
(WE).
Daher ist ein RAM-Simulator eine einfach realisierbare Bonus-Funktionalität
eines EPROM-Simulators.
Dynamische RAMs können damit nicht emuliert werden.
Anschluss (zum BefĂĽllen) am Parallelport, SPP genĂĽgt
Emuliert EPROM und sRAM, von 2 KByte (bspw. 2716) bis 512 KByte
Synchron-serielle Schnittstellen-Kommunikation via Schieberegister
Batterie-Pufferung des RAM-Inhalts, kann auch ohne PC betrieben werden
Typauswahl mittels DIP-Schalterbatterie
RAM auslesbar via Parallelport
Gesonderter RESET-Ein-/Ausgang
(rote IC-Klemme; hält den Prozessor oder Controller inaktiv
solange der PC mit der RAM-Befüllung beschäftigt ist)
Untergesetzte Stecksockel fĂĽr 24-, 28- und 32-beinige IC-Emulation
5-V-Speisung vom Stecksockel mit Verpolschutzdiode
Vollständig in CMOS-Technologie
Und er hat folgende Besonderheiten bzw. Kuriositäten:
RAM-Adressenauswahl mit Zähler, nicht voreinstellbar,
dadurch nur sequenzielles Adressieren, Füllen bzw. Auslesen möglich.
Voreinstellbare höhere Adressen oder getrennt steuerbare
Zählerleitungen „höherer“ Zähler erlauben einen schnellen Zugriff
auf weiter von 0 entfernte Adressbereiche.
Ein paar statische Pegel werden mit einem etwas kuriosen 74HC173
festgelegt, Wirkungsweise noch unklar.
Womöglich als Notnagel für das o.g. Problem.
Nein! Zur Emulation eines speziellen RAMs oder EPROMs mit Bänken!
Ist aber nun wirklich undokumentiert. Ich weiĂź ja nicht einmal, welcher Typ da emuliert werden soll.
Die serielle Anbindung ohne ECP oder EPP macht den Emulator
unnötig langsam, insbesondere bei Verwendung von USB2LPT
oder anderer Software-Virtualisierungsschichten.
Gleiches Problem beim GALEP der gleichen Firma
Umschaltung der Sendedatenleitung (D4 .. D7)
bei nicht untereinander verbundener Masse an den Pins 18 .. 21.
Zum Betrieb von bis zu vier kaskadierten und einzeln auswählbaren Simulatoren
ĂĽber den 14-poligen Pfostenstecker.
BestĂĽckungsvariante mit 32-KByte-RAM und Auswahl mittels SteckbrĂĽcke
(Jumper).
So etwas macht man eigentlich mit einer Löt- oder Kratzbrücke,
da der RAM ja auch eingelötet ist
Gattergrab, ohne GAL, ohne Mikrocontroller.
Ermöglicht immerhin die Disassemblierung.
Parallelport-Kabel mit 2 Ă— Steckern erforderlich. Nur 8 Datenleitungen und 1 BUSY-Leitung benutzt.
Wie beim GALEP (GALLEP III, GALEP IV), Conitec eben. Alle Lesedaten wursteln sich ĂĽber ein einzelne Leitung. Nix mit Nibble-Mode.
Schreibzugriffe (W) sind damit sehr schnell realisierbar, gemessen wurden 30 kByte/s.
Den ganzen 512-KByte-RAM fĂĽllen dauert 17 Sekunden.
Bei Lesezugriffen (R) ist die Geschwindigkeit mau, gemessen wurden 1 kByte/s.
Den ganzen 512-KByte-RAM auslesen dauert ĂĽber 8 Minuten.
Gesamtaufbau
Eine Alternative wäre der Betrieb an einem USB2LPT (nur High-Speed sinnvoll)
mit Gender-Changer und spezialisierter Firmware.
Die Schreib- und Lesegeschwindigkeit erreicht damit ĂĽber 100 kByte/s,
viel mehr als mit einem konventionellen Parallelport möglich ist.
Da USB Full-Speed fĂĽr den Datentransport ausreichend erscheint,
kann man auch eine eigenständige Mikrocontroller-Anbindung mit einem
USB-Controller entwickeln, etwa mit
AT90USB162.
Die Zugriffsmöglichkeiten zusammengefasst
(Zeiten: Parameter z = 1, Celeron 2,8 GHz):
Läuft unter Linux, Win32 und Win64, aber auch noch unter Windows 98
Eingebauter Portzugriffs-Treiber fĂĽr problemlosen Portzugriff unter Win32
Benutzt externen Portzugriffs-Treiber „inpout32.dll“ oder „inpoutx64.dll“ für Portzugriff unter Win64
Läuft mit USB-Paralleldrucker-Konverter und damit via USB auch auf schnittstellen-verarmten Laptops und Notebooks
130421: Der vermeintliche Linux-Fehler wurde endlich gefunden und gelöst!
Gesonderte UnterstĂĽtzung von USB2LPT: Zeit sparende Zusammenfassung von 8 IN-Transfers, macht immerhin Beschleunigungsfaktor 8
Fortschrittsanzeige und sinnhaltige Fehlermeldungen
Konsolen-Programm (wie bisher) mit gemeinsamem Quelltext; korrekte UnterstĂĽtzung von Kursor- und Sondertasten
Bitweise und parallel-byteweise geschwindigkeitsoptimiertes Laden des PEPS bzw. der PEPSe
(Gleiche Daten werden niemals wiederholt ins Schieberegister geschrieben.)
Schnelles Laden von HEX- und SHX-Dateien mit lĂĽckenhaften oder absteigenden Adressen
(Eine Routine ist eingebaut, die trotzdem alle zusammenhängenden Daten auffindet.)
Mehrere Dateien ladbar, einzelbyteweise per Kommandozeile ĂĽberschreibbar mit Option -i
Volle UnterstĂĽtzung fĂĽr bis zu 4 verkettet geschaltete PEPSe (aber mangels Hardware ungetestet), auch 3 PEPSe fĂĽr einen 24-Bit-Bus sind kein Problem
Stichproben-Verifizierung des Speicherinhalts als Standard (schnell und hinreichend sicher)
deutsch und englisch — auch unter Linux
Volle Unicode-UnterstĂĽtzung fĂĽr Funktion mit bspw. chinesischen Dateinamen
natives 32- und 64-Bit-Programm (AMD64 versteht sich)
Winzige Exe-Größe (ca. 30 kByte) ohne eingebaute oder extra notwendige Laufzeitbibliothek, läuft prompt von jedem USB-Stick oder jeder Diskette
Was noch fehlt:
Ausgiebiger Test (Ich selbst brauche das PEPS ja gar nicht!)
Natives Firmware-Schnipsel fĂĽr USB2LPT (nur fĂĽr High-Speed sinnvoll)
fĂĽr Beschleunigungsfaktor 1000 (ja, viel schneller als ein Parallelport!)
