Logikproblem: Speicherbank umschalten
- Ersteller unilein
- Erstellt am
-
- Schlagworte
- adressierung speicherlogik vintage z80
Mit sowas wäre man auch flexibel. Das habe ich früher eingesetzt, heute nicht mehr. Neben dem Compiler benötigt man einen geeigneten Programmer.
Zum Beispiel GAL16V8
Zum Beispiel GAL16V8
TommyB
Team Bitschubse
Programmer brauchts noch nicht mal, ein älterer PC der noch einen Parallel Port hat reicht aus. Optimal ist natürlich anders, aber das ist sofort verfügbar. So habe ich auch gestartet und es hat funktioniert 
Hi,
Gruß
Dino
den Tiny sollte man dann aber wegen der Durchlaufzeit sicherheitshalber mit 20MHz takten. Das sind dann immer noch etliches mehr an Nanosekunden gegenüber nem 74139 oder NAND-Gattern. Ich tippe mal Faktor 10.
Gruß
Dino
Acht Takte wäre bei 8MHz eine Mikrosekunde (12 Takte entsprechend 1,5µs), mit 20MHz käme man auf 400ns (bzw 600ns).
Du hattest ja bereits mit Übertaktung experimentiert, als erstes sind da meiner Erinnerung nach komplexere Innereien ausgefallen...
Hi,
ausgerechnet habe ich es jetzt nicht wirklich.
Das summiert sich alles zu einer gemeinsamen Zugriffszeit.
Laut Datenblatt müssen nach Low auf /MREQ 2,5 Taktzyklen später die validen Daten auf dem Bus liegen. Das sind bei 4MHz (250ns) also 625ns. Die Zeit frißt du bereits mit dem Tiny auf. Da bleibt für die Reaktionszeit des RAMs nichts mehr übrig. Die Adresse liegt maximal 0,5 Taktzyklen (125ns) früher bereit. Das ist vom Timing mit ziemlich heißer Nadel gestrickt.
Gruß
Dino
ausgerechnet habe ich es jetzt nicht wirklich.
Das ist selbst bei nem alten Z80 schon recht viel. Bei möglichen 4MHz Systemtakt des alten Z80A hätte ich da schon arge Bauchschmerzen. Bei 2,5MHz mag das wohl noch irgendwie hinhauen. Schön sind die Durchlaufzeiten aber sicher nicht. Wenn man mal mit den gut 200ns Zugriffszeit der RAMs aus der Zeit rechnet.
Das summiert sich alles zu einer gemeinsamen Zugriffszeit. Laut Datenblatt müssen nach Low auf /MREQ 2,5 Taktzyklen später die validen Daten auf dem Bus liegen. Das sind bei 4MHz (250ns) also 625ns. Die Zeit frißt du bereits mit dem Tiny auf. Da bleibt für die Reaktionszeit des RAMs nichts mehr übrig.
Die Adresse liegt maximal 0,5 Taktzyklen (125ns) früher bereit. Das ist vom Timing mit ziemlich heißer Nadel gestrickt.Gruß
Dino
Die maximale (regelkonforme) Taktfrequenz der "schnellen" AVR liegt bei 20MHz, was 50ns Taktzeit entspricht. Für die geforderten 625ns hat man also höchstens(!) 12 Takte.
Wenn man das ohne Interrupt angehen will, braucht man 'ne Schleife, in der der der Zustand der Eingänge ausgewertet wird. Also
Start:
lade eingänge ( 1 Takt)
werte Eingänge aus (?? Takte)
setze Ausgänge (1 Takt)
springe nach Start (2 Takte)
blieben maximal 8 Takte für die Auswertung.
Analog zu meinem Tabellen-Vorschlag kann man natürlich auch hier verfahren:
Start:
lade Eingänge nach ZL (1 Takt)
hopse indirekt nach Z (2 Takte)
setze Ausgänge (1 Takt) <-- Durchlaufzeit
hopse nach Start (2 Takte)
Sieht auf den ersten Blick sogar besser aus mit 4Takten=200ns, allerdings weiß man ja nicht, wann sich die Eingänge ändern. Im worstcase halt direkt nachdem man die Eingänge geladen hat - dann reagiert man erst nach 9 Takten (450ns).
Das Programm kann logischerweise nichts anderes mehr machen, schneller als drei Assembler-Instruktionen (und eine für den Rücksprung) fällt mir nichts mehr ein...
Wenn man das ohne Interrupt angehen will, braucht man 'ne Schleife, in der der der Zustand der Eingänge ausgewertet wird. Also
Start:
lade eingänge ( 1 Takt)
werte Eingänge aus (?? Takte)
setze Ausgänge (1 Takt)
springe nach Start (2 Takte)
blieben maximal 8 Takte für die Auswertung.
Analog zu meinem Tabellen-Vorschlag kann man natürlich auch hier verfahren:
Start:
lade Eingänge nach ZL (1 Takt)
hopse indirekt nach Z (2 Takte)
setze Ausgänge (1 Takt) <-- Durchlaufzeit
hopse nach Start (2 Takte)
Sieht auf den ersten Blick sogar besser aus mit 4Takten=200ns, allerdings weiß man ja nicht, wann sich die Eingänge ändern. Im worstcase halt direkt nachdem man die Eingänge geladen hat - dann reagiert man erst nach 9 Takten (450ns).
Das Programm kann logischerweise nichts anderes mehr machen, schneller als drei Assembler-Instruktionen (und eine für den Rücksprung) fällt mir nichts mehr ein...
Hi LotadaC,
625ns minus der Zugriffszeit des SRAMs. Also minus 55-100ns die so ein normales SRAM vom Typ 6264, 62256 oder ähnliches typischerweise hat.
Das wird verdammt eng.
Gruß
Dino
625ns minus der Zugriffszeit des SRAMs. Also minus 55-100ns die so ein normales SRAM vom Typ 6264, 62256 oder ähnliches typischerweise hat.
Das wird verdammt eng.
Gruß
Dino
Jaja, hatte ich schon verstanden. Vielleicht reicht das dicke Ausrufungszeichen nicht. Wollte Deinen Kommentar nur unterstreichen - selbst mit nur drei Instruktionen wirds verdammt eng. Und noch mehr kann zumindest ich nicht rausoptimieren...
Vorteil wären hier die fehlenden Glitches.
Zu Deinem Vorschlag mit dem Decoder-IC hab ich nichts weiter gesagt - das mußt Du selbst mit Uni auseinanderklamüsern, wo da jetzt eventuell was nicht paßt.
Vorteil wären hier die fehlenden Glitches.
Zu Deinem Vorschlag mit dem Decoder-IC hab ich nichts weiter gesagt - das mußt Du selbst mit Uni auseinanderklamüsern, wo da jetzt eventuell was nicht paßt.
Hallo zusammen,
hier geht's ja rund!.
Also das Tiny-Ding habe ich inzwischen auch verworfen. Ich habe auch ausgerechnet gehabt, dass das sehr eng wird. Ich möchte den Z80B mit 6MHz betreiben. Evtl. auch nur mit 4 MHz. Ich werde jetzt mal schauen, wie es mit den NAND's aussieht. Das Decoder-Ding habe ich ja auch noch nicht verworfen (das wäre wohl die Lösung, die auf jeden Fall stabil wäre).
Wie Ihr wisst, brauche ich für meine Projekte ja immer etwas länger, aber ich bleibe dran.
Grüße,
Uni
hier geht's ja rund!
.Also das Tiny-Ding habe ich inzwischen auch verworfen. Ich habe auch ausgerechnet gehabt, dass das sehr eng wird. Ich möchte den Z80B mit 6MHz betreiben. Evtl. auch nur mit 4 MHz. Ich werde jetzt mal schauen, wie es mit den NAND's aussieht. Das Decoder-Ding habe ich ja auch noch nicht verworfen (das wäre wohl die Lösung, die auf jeden Fall stabil wäre).
Wie Ihr wisst, brauche ich für meine Projekte ja immer etwas länger, aber ich bleibe dran.
Grüße,
Uni
Einen GAL und passenden Programmer habe ich leider nicht. Das fällt also flach. Trotzdem dank für die Idee.
Ich habe in meiner Bastelkiste noch einen 74HC138 gefunden. Das ist ein 3-to-8-Line Decoder. Der ist schnell genug. Den habe ich mal samt Dioden und Pullups auf ein Brett gesteckt und siehe da. Das klappt gut.
Dino's Vorschlag für den HC139 funktioniert übrigens doch, man muss lediglich die Dioden richtig herum benutzen.... Keine Ahnung warum die Logik da so kleinlich ist
.Somit habe ich jetzt zwei funktionierende Versionen. HC139 oder HC138. Bei der HC139-Version werden lediglich zwei Dioden benötigt um die erforderliche Kodierung zu bekommen. Bei HC138 sind es 6 Stück. Da fällt die Wahl eigentlich leicht.
Gruß
Uni
Hi LotadaC,
und hi unilein,
also nen Z80 schafft max 2,5MHz und der Z80A max 4MHz. Das müßte dann ne andere Version sein. Es gibt glaube ich ne CMOS-Version (Z80H) die bis 8MHz schaffen soll. Ob die aber auch wirklich voll kompatibel ist weiß ich auch nicht.
GAL und Progger reichen alleine auch nicht. Man benötigt noch einen GAL-Assembler dafür der einem die Logikgleichungen in das JEDEC-File wandelt. Wird schon schwierig so einen Assembler zu finden. Heutzutage sind ja eher FPGAs und CPLDs in Verwendung. Hab letztens mal nach dem GALASM (oder hieß der PALASM) gesucht. War nicht so erfolgreich Gabs damals noch unter MS-DOS
Gruß
Dino
auf das Ausrufungszeichen hab ich garnicht so geachtet
und hi unilein,
also nen Z80 schafft max 2,5MHz und der Z80A max 4MHz. Das müßte dann ne andere Version sein. Es gibt glaube ich ne CMOS-Version (Z80H) die bis 8MHz schaffen soll. Ob die aber auch wirklich voll kompatibel ist weiß ich auch nicht.
GAL und Progger reichen alleine auch nicht. Man benötigt noch einen GAL-Assembler dafür der einem die Logikgleichungen in das JEDEC-File wandelt. Wird schon schwierig so einen Assembler zu finden. Heutzutage sind ja eher FPGAs und CPLDs in Verwendung. Hab letztens mal nach dem GALASM (oder hieß der PALASM) gesucht. War nicht so erfolgreich
Gabs damals noch unter MS-DOS Gruß
Dino
Ich habe eine Packung Z80B erstanden. Oder korrekterweise müsste man sagen Z8400BPS. Das sind weiterentwickelte Z80 und sie vertragen 6MHz. Bei den nicht dokumentierten OP-Codes wäre ich vorsichtig, ansonsten sind die aber voll kompatibel. Ich habe das auch schon ausprobiert, indem ich den Chip einfach mal in meinen alten Laser 210-Homecomputer gesteckt habe. Der hat nicht gemeckert
GAL und Progger reichen alleine auch nicht. Man benötigt noch einen GAL-Assembler dafür der einem die Logikgleichungen in das JEDEC-File wandelt. Wird schon schwierig so einen Assembler zu finden. Heutzutage sind ja eher FPGAs und CPLDs in Verwendung. Hab letztens mal nach dem GALASM (oder hieß der PALASM) gesucht. War nicht so erfolgreich
Gruß
Dino
Wie gesagt, ich besitze nichts dergleichen. Auf mit FPGA's und CPLD's kenne ich mich nicht aus. Meine Kenntnisse der Elektronik stammen aus der Zeit, als ich 12 bis 14 Jahre alt war. Da war es schon schwierig und teuer einen LM324 zu beschaffen. Erst seit knapp 2 Jahren beschäftige ich mich wieder mit meinem alten Hobby. Das erklärt, warum ich die Klapperlogik noch schätze
Gruß
Uni