EPROM-Emulator?

Erinnere mich auch dunkel an sowas... Platinchen und irgendein Western-Stecker kam zum Schreiben dran? und ein Kabelchen, um während dem Programieren RESET zu drücken, sowas.

Hab gegoogelt und nix gefunden, und war nicht sicher ob und was und wo, aber Ecke Elektor/ELV kommt hin...

Thomas Prufer

Olaf Kaluza schrieb:

m

Gerade die /Bauh=F6he/ d=FCrfte das Hauptproblem werden... (Je nachdem, w= ie eng es im Zielsystem zugeht.)

s

Adressieren durchaus mehr, und Bankswitching gab es auch damals schon. Wer wei=DF, was in dem Teil drin ist und warum man damals so ein verh=E4ltnism=E4=DFig riesiges Teil genommen hat - aber da die fr=FCher a= uch mal relativ teuer waren, wird man es wohl nicht ganz ohne Grund gemacht haben= =2E

wurde.

Ich auch - und nein, das z=E4hlt nicht als Flash. :-)

Tilmann

Hallo, Ralph. 80c39 und 27512 passt irgendwie nicht zusammen. Der Prozessor kann am Stück 2KByte adressieren, für ein 64KByte-Eprom wäre also 32-faches Bankswitching nötig. Ich vermute daher, daß hier ein Eprom eingesetzt wurde, was gerade am Lager war und nur zum Teil beschrieben wurde. Kannst Du ungefähr abschätzen, wieviel vom Eprom wirklich gebraucht wird? Das könnte die zu verwendende Hardware eventuell reduzieren.

Eventuell kann man dann Dein Problem auf einen Mikrocontroller und einen Schnittstellenbaustein reduzieren, wie es hier auch schon vorgeschlagen wurde.

--

     Mit freundlichen Gruessen  Andreas Graebe
--. .-. .- . -... . .--.-. - ..-. .... -....- -... . .-. .-.. .. -. .-.-.- -.. .

Ich schalte da über die hohen Adressleitungen Bänke um. Natürlich merkt die CPU davon nix, außer, daß sie dann halt andere Daten sieht.

-ras

--

Ralph A. Schmid

http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/

Original ist was Kleineres drin, siehe vorheriges Posting :)

-ras

--

Ralph A. Schmid

http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/

Hallo Ralph,

das geht bestimmt auch ohne FPGA-VHDL-ARM-Dualported-RAM-Zeug ;-)

Ich habe sowas mal für'n 68k in meinem alten Modem gebastelt, EPROMs raus und SRAMS bzw. Flashes mit Huckepackplatine rein.

Der 80C39 hat doch bestimmt diese Pseudo-IOs und die legt er im Reset auf so'n flauen H-Pegel per interner PullUps, das ist die Chance. Du baust ein Flash ein, welches Du ISP-fähig machst: Den Controller in den Resetzustand versetzen (Patchdraht zum Resetpin nötig) und and die Daten/Adress/Steuerleitungen per Schieberegister zum Laden bzw. Programmieren bedienen. Auf das Rücklesen und Abfragen des Flashes verzichten wir hier einfach mal. Am Ende des Ladevorgangs dann die Ausgänge des Schieberegisters in den TriState bringen (z.B. beim HC590 ganz einfach per OE) und den Controller freilassen. Die 3 bis 4 Schieberegister könnte man als SMD auf das RAM/FLASH kleben und per Fädeldraht verdrahten oder als Zwischenplatine oder Huckepackplatine unter/aus das RAM/Flash. Bedient wird die Chose dann per 5 Leitungen:

Schiebeclock SCLK Schiebedaten SDAT Übernahmeclock RCLK Reset/Tristate RES Masse GND

Per Parallelport am PC ist man dann mit BitBanging einfach dabei, allerdings mühevoll und auch nicht so richtig schnell...

Schneller ist es eventuell per USB-IO-Adapter à la FTDI, aber das wissen andere hier besser...

Ich hab's damals mit 'nem Batteriegepufferten RAM gemacht... ach das waren noch Zeiten, als alle paar Tage 'ne neue Firmware rauskam und dann irgendwann sagenhafte 19200 Bit/s durch die Leitung sausten...

Gruß Ing.olf

Ingolf Pohl schrieb:

Und heute minnt man einfach einen Mega128, packt einen kleinen Bootloader rein und lässt ihn ein ROM auf seinen Portpins simulieren und den UART für "nach draußen". Sollte sogar mit internem Takt gehen wenn Temperatur nicht zu stark schwankt. Also nicht mal ein Quarz nötig.

1 chip, ein bissi Hühnerfutter, ein IC-Doppelsockel... Fertig.

Michael.

Sicherlich, man kann sie doch mit einem UV-Flash l=F6schen. :-) Gruss Harald PS: F=FCr den 8748 gabs fr=FCher (tm) mal ne ganz tolle DCF77-Schaltung. :-)

Das ist ein möglicher Ansatzpunkt, um Hardware beim Simulator sparen zu können. Ein weiterer wäre vielleicht der Takt. Du schreibst, daß die CPU mit

8..10 MHz betrieben wird. Aber bedeutet das tatsächlich auch, daß auf den EPROM mit 100..125ns Zykluszeit zugegriffen wird? Und wie ist die Ansteuerung genau gelöst? Nur /OE, nur /CS oder Kombination?

Zusamenfassend: Kannst du irgendwie ein Timingdiagramm der Ansteuerung ermitteln und posten? Es genügt eigentlich schon ein Diagramm der benutzten Steuerleitung(en). Natürlich sollte es den worst case abbilden, also die engste vorkommende Zugriffsfolge darstellen. Außerdem wäre auch ein Blockschaltbild des Bussystems hilfreich.

Erst mit diesen Informationen kann man wirklich fundiert über eine aufwandsminimierte Variante eines EPROM-Simulators für die konkrete Anwendung nachdenken.

Eine wirklich universelle Simulation ist nur mit relativ hohem Aufwand im Volumen eines 27512 unterzubringen, aber das schrieben andere ja auch schon. Das Hauptproblem ist die nötige Busabtrennung für bis zu 27 Signale. Die kostet erheblich Fläche, egal wie man es dreht und wendet.

Am Fri, 07 May 2010 22:29:50 +0200 schrieb Michael Buchholz:

Da wäre ich etwas skeptisch, ob man damit genügend Programmspeicher für den 80C39 emulieren kann. Immerhin war die Rede von einem 27C512. Und ob man die Zugriffszeiten hin bekommt? Selbst beim schnarchigen 80C39 würde ich mal gefühlte 300ns annehmen, in denen der AT-Mega Steuerleitungen testen, entscheiden, Adresse einlesen, Datum auf den Bus legen und wieder rechtzeitig wegnehmen muss, wenn die Steuerleitungen es anzeigen. Dazu ist der Daten/Adressbus des 80C39 auch noch gemultiplext... "Mach ma', Michael." Mich würde es auch interessieren, ob's wirklich so einfach geht.

Ein ganz anderer Ansatz wäre natürlich den 80C39 gegen einen anderen Controller auszutauschen, den man via Bootloader programmieren kann - nur wer will die Software darauf portieren bzw. einen Emulator dafür schreiben...

Gruß Ing.olf

Wenn ich mich recht erinnere, wird der Systemtakt mittels eines Teilers durch 15 (ja, wirklich) aus der Quarzfrequenz erzeugt.

--

     Mit freundlichen Gruessen  Andreas Graebe
--. .-. .- . -... . .--.-. - ..-. .... -....- -... . .-. .-.. .. -. .-.-.- -.. .

Wenn das stimmt und damit entsprechend langsam auf das EPROM zugegriffen wird, könnte der komplette Simulator mitsamt USB-Interface zum Programmieren aus einem ATMega1284P und zehn passiven Bauelementen bestehen. (1 Quarz, 2 Kondensatoren, 1 Elko, 2 Z-Dioden, 3 Widerstände,

1 USB-Buchse).

Der EPROM-Inhalt wäre in der unteren Hälfte des ATMega-Programmspeichers abgelegt, in der obere Hälfte läge der USB-Treiber, der Bootloader und folgendes "Betriebssystem" für den Normalbetrieb (also Lesebetrieb als virtuelles EPROM):

wait_oe_low: sbic CONTROL_PORT,OE_BIT ;2 1 rjmp wait_oe_low ; 2 in ZL,ADRESSL_PORT ;1 in ZH,ADRESSH_PORT ;1 lpm TMP,Z ;3 out DATA_PORT,TMP ;1 out DATA_DDR,ALLBITS ;1 wait_oe_high: sbis CONTROL_PORT,OE_BIT ;2 1 rjmp wait_oe_high ; 2 out DATA_DDR,NOBITS ;1 rjmp wait_oe_low ;2

Da der 1284 mit 20MHz laufen kann, läge die Zykluszeit im worst case bei

16*50ns, also 800ns. Ggf. kann man auch noch übertakten, 25MHz schaffen nach meiner Erfahrung etwa 70% der Exemplare, dann wäre man dann sogar bei 640ns Zykluszeit.

Für Firmware-Bootloader und USB-Treiber gibt es fertige Software (größtenteils in ekelhaftem C, aber immerhin). Die wären nur noch geringfügig zu ergänzen, im wesentlichen dadurch, daß der Interrupthandler des USB-Treibers als erstes noch den Datenport hochohmig macht, was in zwei Takten zu erledigen wäre. Dazu kommt allerdings noch die Interruptlatenz von (worst case) 8 Takten und eventuell 2 Takte zum Sichern des einen benötigten Registers (bei vollständiger Programmierung in Assembler müßte man sich um solchen Scheiß nicht kümmern, da würde man einfach ein Register für diesen Zweck "reservieren", d.h. in diesem Fall das 'NOBITS'-Register des "Betriebssystems" benutzen).

Im schlimmsten Fall gibt es also eine gegenüber dem Lesebetrieb um 7T (350ns) verspätete Deaktivierung des Datenports beim Eintritt in den Programmiermodus. Das sollten auch empfindliche Bustreiber konkurrierender Speicher (sofern überhaupt vorhanden) unbeschadet überstehen können.

Für mich wäre durchaus auch ein Ansatz, daß ein NOR-Flash da drinsitzt und nur eben zur Programmierung temporär von einem kleinen controller "übernommen" wird...

-ras

--

Ralph A. Schmid

http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/

Geht wenn man der CPU auf der Leiterplatte den Adreßbus tristate schalten kann, Datenbus ist ja meist kein Problem. Ging beim 6502 nicht, da hat man die Treiber nicht so ausgelegt um Chipgrösse zu minimieren. Bei anderen alten CPUs soll das aber wegen in-circuit Test der Leiterplatte möglich gewesen sein. Bei Controllern bei denen der Bus optional an Ports hängt sollte es auch möglich sein.

MfG JRD

Oder eben einfach auf dem Platinchen die Leitungen durch einen Treiberbaustein führen, der das kann.

-ras

--

Ralph A. Schmid

http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/

Mir fällt gerade ein, der Bus ist beim 80C39 ja gemuxed, da wird wohl irgendwo ein Latch für die Adressen sein, eventuell kann man das schon mal zusammen mit dem Reset tristaten, dann sind die unteren 8-Bit Adressen und Daten schon mal frei. Die restlichen Adressbits wurden beim 80C39 doch aus den Ports abgeleitet, die sind im Reset auch "Input", also per Pull-Up auf High, fehlt eigentlich nur noch das Read-Signal in Form des PSEN#, das muss wohl "übersteuert" werden, kann schon was werden, wenn man das originalsignal durch einen Widerstand zwingt und bei Bedarf dann mit einem tristatefähigen Treiber übersteuert... Ist alles nicht nach Lehrbuch, aber kann man machen...

Ing.olf