1 Byte Adressdecoder gesucht


1 Byte Adressdecoder gesucht

von Schuster » Di 3. Jun 2008, 22:33
Hallo Experten,

mit welchem GAL kann genau 1 Byte aus den 16Bit des Atari dekodiert werden und wie würde das JEDEC File aussehen,
bzw. gibt es andere Bausteine die dafür besser geeignet wären?

Vielen Dank für eure Hilfe
Frank

von tuxie » Di 3. Jun 2008, 23:00
Hi,

es kommt darauf an was du machen möchtest. Mit nem Gal ist ein Adressdecoder schon recht einfach zu bauen. Ein 20V8 sollte da ausreichen.

Man kann auch jetzt nicht sagen, wie das Listing aussehen soll, weil man ja nicht was auf welche Adresse wie Reagiert werden soll.

TSchau Ingo

von mega-hz » Mi 4. Jun 2008, 00:01
ein Byte aus den 16Bit??
Meinst du nen ST oder war es ein Tipp-Fehler?

Mit nur einem GAL kann es gehen, kann aber auch sein, daß du 2 brauchst.
Erzähl mal, welche Adresse soll es sein und was soll decodiert werden?
Zugriff auf die Adresse? Dafür gibt es diese netten "Vergleicher" !
74688 z.B., haben 2x 8 Eingänge die miteinander verglichen werden, an den einen kann man nen 8fach DIP Schalter z.B. ranhängen und der andere kommt an die Adressleitungen...
Dieser Baustein wurde sehr oft auf alten ISA-Karten eingesetzt...
Da im Atari 8Bit aber ein 16Bit breiter Adressbus existiert, müsstest Du davon 2 Bausteine nehmen, im ST sogar 3 (24Bit Adressbus -A0)

Gruß,
Wolfram.

von Sleepy » Mi 4. Jun 2008, 06:37
So ein Adressvergleicher wärer je nach Anwendung die einfacherer Lösung; Du hättest das Schreiben des Programmes gespart und könntest (wenn DIP-Schalter eingesetzt werden) das "Vergleichsbyte" jederzeit ändern.

Sleepy

von tuxie » Mi 4. Jun 2008, 12:22
Man könnte es auch mit mehreren Und Gattern machen. Macht aber viel mehr Arbeit und man ha auch eine große verzöckerung die dann eventuell schon ne rolle spielen könnte. Wenn man einen Gal Prommer hat ist wohl ein Gal die beste Variante.

TSchau Ingo

Re: 1 Byte Adressdecoder gesucht

von Bernd » Mi 4. Jun 2008, 13:01
Schuster hat geschrieben:Hallo Experten,

mit welchem GAL kann genau 1 Byte aus den 16Bit des Atari dekodiert werden und wie würde das JEDEC File aussehen,
bzw. gibt es andere Bausteine die dafür besser geeignet wären?

Vielen Dank für eure Hilfe
Frank


Hallo Frank,

so wie ich dich verstehe möchtest du aus dem 64k eine einzelnes Byte selektieren. Dazu braucht man ein GAL mit 16 Eingängen für die Adressleitungen und einem 1 Ausgang für das gesetzte Byte.
Da reicht ein 16V8 nicht mehr aus - mindestens ein 20V8 oder 22V10 ist dazu erforderlich.

Die Logik ist recht einfach. Z.B das Byte Dez. 54783 , Hex D5FF soll das Ziel darstellen. Alle Pins des GALs müssen zugeordnet sein.
Erstmal ins Binäre umsetzten. (Tipp - der Windows Rechner kann unter wissenschaftlicher Darstellung sehr nützlich dabei sein)

- Linke Bit 15 = A15 - Rechte Bit 0 = A0
1101010111111111

Ausgang = A0 & A1 & A2 & A3 & A4 & A5 & A6 & A7 & A8 & /A9 & A10 & /A11 & A12 & /A13 & A14 & A15

Alle "0" Eingänge müssen mit dem "/" negiert werden.

Wenn du etwas übers GAL-Programmierung lernen möchtest findest du hier die Möglichkeit:
http://www.inf.fu-berlin.de/lehre/SS03/ ... en/gal.pdf

Ich benutze den GDSWin Assembler ( http://www.sh-elektronik.de/ ) - ist leider keine Freeware. Er hat einen sehr guten Simulator um die Logik anschließend zu testen.

Bernd

von Schuster » Mi 4. Jun 2008, 22:41
Hallo Bernd,

genau das was du beschreibst möchte ich machen.
Dabei möchte ich D1FF dekodieren für ein PBI Device.
Sicherlich muss ich mir noch ein paar andere Signal zur Verfügung stellen.
Wenn ich den 20V8 benutze, wieviele Eingäng bzw. Ausgänge bleiben denn noch übrig wenn ich 16 schon für die Adressbits benuzt habe?

Danke an alle für eure Antworten, ich werde mir auch die Adressvergleicher anschauen, vieleicht sind die auch interessant.

Hat einer von euch schon mal ein PBI Device entwickelt welches 100% konform zum Atari-Design ist?

Danke
Frank

von Bernd » Mi 4. Jun 2008, 22:56
Hallo Frank,

ein 20V8 hat 24 Pins, 2 entfallen auf die Stromversorgung, 2 gehen für die Freigabelogik darauf. Bleiben 20 Pins übrig, daher die 20 im ersten Feld als Eingänge. 8 Pins können sowohl als Ein- oder Ausgang benutzt werden.
Schau dir mal das Datenblatt dazu an:
http://www.latticesemi.com/lit/docs/dat ... d9ri$0DJ$B

Viele Grüße,
Bernd

von Mathy » Mi 4. Jun 2008, 23:52
Hallo Frank

Schuster hat geschrieben:Hat einer von euch schon mal ein PBI Device entwickelt welches 100% konform zum Atari-Design ist?

Mir fallen da spontan Hias, Guus Assmann und Roland Scholz ein.

Tschüß

Mathy

von mega-hz » Do 5. Jun 2008, 11:47
@Schuster:

Wenn Du $D1FF dekodieren willst, gehts noch einfacher!
Du brauchst nur FF decodieren, denn $D1XX ist schon am 74LS138
im XL als dekodierter Ausgang da!:-)
Es ist Pin 14 wo D1xx rauskommt.
Das spart einiges im GAL und wenn Du nen Vergleicher 74688 nehmen möchtest, brauchst Du nur einen davon!

Mein verstorbener Freund und ich haben anfang der 90er eine PBI Schaltung gebaut, welche sich richtig als PBI Gerät angemeldet hat,
bestand aber aus einer ganzen Handvoll Logic ICs, da wir keine GALs hatten. Die Schaltung hatte aber nur ein 2K Eprom in den ausgeblendeten Mathe-Bereich nach $D8xx eingeblendet.

Hier ist ein interessanter Artikel über das PBI...

Gruß,
Wolfram.

von HiassofT » Do 5. Jun 2008, 14:41
Mathy hat geschrieben:
Schuster hat geschrieben:Hat einer von euch schon mal ein PBI Device entwickelt welches 100% konform zum Atari-Design ist?

Mir fallen da spontan Hias, Guus Assmann und Roland Scholz ein.

Ich hab leider noch kein PBI Gerät entwickelt (der Freezer hängt zwar am PBI, aber meldet sich nicht beim OS als PBI Gerät an, so wie zB die BlackBox oder das KMK/JZ Interface).

Anfang/Mitte der 90er hatte ich angefangen ein "richtiges" PBI IDE Interface zu entwickeln, hatte dann aber letztlich etliche Timing-Probleme und hab' wieder aufgegeben. Damals hatte ich die Logik aus standard TTL ICs aufgebaut, inzwischen ist mir auch klar wieso das nicht so gut gelaufen ist :-)

Hier mal ein paar Tips, damit Du nicht durch die gleichen Fehler stolperst wie ich damals bzw. bei der Freezer Entwicklung:

Gehe davon aus, daß kurz vor Ende von PHI2 Adress- und Datenbus schon ungültig sind. Beim Freezer verwenden wir folgende Techniken um das zu umgehen:
- Im CPLD latchen wir alle Eingangs-Signale vom Atari (R/W, Adressbus) sobald PHI2 auf High geht. Danach darf sich sowieso nichts mehr ändern und die Logik braucht sich nicht weiters drum zu kümmern. Aktuelle CPLDs unterstützen solche Latches an den Eingängen von Haus aus und man muss sie nur noch aktivieren.
- Für Schreibzugriffe (ins Flash oder RAM) haben wir eine kleine Hilfsschaltung mit dem HCT123 gebastelt, das einen etwas kürzeren Impuls erzeugt (startet mit der steigenden Flanke von PHI2, endet ein Stückchen bevor PHI2 auf Low geht, alle Signale vom Atari sind während dieser Zeit gültig). Dieses Signal verwenden wir zur Erzeugung des /WE Signals.

Wenn Du einen CPLD nimmst (was ich grundsätzlich nur empfehlen kann, in einen etwas grösseren CPLD passt locker die gesamte Logik eines PBI Devices rein - nur die I/O Pins sind bei den kleineren CPLDs etwas knapp) ist es sehr ratsam die Flankensteilheit der Ausgänge zu reduzieren. Das kann man auch bei ziemlich allen CPLDs konfigurieren und ist absolut notwendig wenn Du die Schaltung auf einer einfachen Platine aufbaust und mit dem Atari verbinden willst. Die CPLDs sind für Taktfrequenzen bis 200MHz und mehr ausgelegt und müssen dementsprechend steilflankige Signale ausgeben können. Das führt dann aber dazu, daß es zu Reflektionen, Übersprechen und anderen unangenehmen Sachen kommt, falls das Platinenlayout dafür nicht ausgelegt ist (und das Layout vom Atari ist definitv nicht dafür ausgelegt :-). Also einfach Flanken etwas moderater einstellen und gut ists :-)

Durch die hohe Geschwindigkeit der CPLDs muss man auch bei asynchronen Sachen (wie zB dem asynchronen Reset) aufpassen: ein kurzer Spike von ein paar nS Länge ist für den CPLD schon ein gültiges Signal. Beim Freezer haben wir deshalb zwischen Reset-Ausgang am PBI und Eingang am CPLD ein kleines RC-Glied gehängt das als Tiefpass funktioniert und kurze Spikes ausfiltert.

Wenn Du diese paar Dinge beachtest, ist es aber wirklich ziemlich einfach einen aktuellen CPLD an den Atari zu hängen. Dann einfach noch ein paar Adress/Datenleitungen zu RAM, Flash (und den anderen Bauteilen Deines Geräts) und Du bist fertig. Die Logik kannst Du dann einfach am PC entwerfen und per JTAG Interface in den CPLD programmieren. Ist deutlich einfacher als stundenlang neue Logik-ICs rein- oder rauszulöten :-)

so long,

Hias

von Schuster » Do 5. Jun 2008, 16:49
HiassofT hat geschrieben:....
Wenn Du einen CPLD nimmst (was ich grundsätzlich nur empfehlen kann, in einen etwas grösseren CPLD passt locker die gesamte Logik eines PBI Devices rein - nur die I/O Pins sind bei den kleineren CPLDs etwas knapp) ist es sehr ratsam die Flankensteilheit der Ausgänge zu reduzieren. Das kann man auch bei ziemlich allen CPLDs konfigurieren und ist absolut notwendig wenn Du die Schaltung auf einer einfachen Platine aufbaust und mit dem Atari verbinden willst. Die CPLDs sind für Taktfrequenzen bis 200MHz und mehr ausgelegt und müssen dementsprechend steilflankige Signale ausgeben können. Das führt dann aber dazu, daß es zu Reflektionen, Übersprechen und anderen unangenehmen Sachen kommt, falls das Platinenlayout dafür nicht ausgelegt ist (und das Layout vom Atari ist definitv nicht dafür ausgelegt :-). Also einfach Flanken etwas moderater einstellen und gut ists :-)

Durch die hohe Geschwindigkeit der CPLDs muss man auch bei asynchronen Sachen (wie zB dem asynchronen Reset) aufpassen: ein kurzer Spike von ein paar nS Länge ist für den CPLD schon ein gültiges Signal. Beim Freezer haben wir deshalb zwischen Reset-Ausgang am PBI und Eingang am CPLD ein kleines RC-Glied gehängt das als Tiefpass funktioniert und kurze Spikes ausfiltert.

Wenn Du diese paar Dinge beachtest, ist es aber wirklich ziemlich einfach einen aktuellen CPLD an den Atari zu hängen. Dann einfach noch ein paar Adress/Datenleitungen zu RAM, Flash (und den anderen Bauteilen Deines Geräts) und Du bist fertig. Die Logik kannst Du dann einfach am PC entwerfen und per JTAG Interface in den CPLD programmieren. Ist deutlich einfacher als stundenlang neue Logik-ICs rein- oder rauszulöten :-)

so long,

Hias


Hi Hias,

danke für die Tips.
Welchen CPLD würdest du empfehlen um die gesamte Logik in einen hinein zu bekommen?
Ein JTAG Interface würde natürlich die Entwicklungszeit erheblich verkürzen.
Hast du das Design vom Freezer veröffentlicht? Ich frage nur, vielleicht kann man sich ein paar Dinge ja kopieren:-).

@mega-hz
Das mit Pin14 wäre zwar einfacher, aber da das Signal nicht am PBI liegt muss immer ein Kabel innen angelötet werden. Was ich nicht möchte. Es soll an jedem Atari Laufen können.

Danke
Frank

von Bernd » Do 5. Jun 2008, 17:27
Hallo Frank,

hier gibt es den Freezer Sourcecode von Hias.
http://www.horus.com/~hias/freezer/software/

Bernd

PS: Bitte bedenke dass die Rechte an den Programmteilen bei Hias liegt.

von HiassofT » Do 5. Jun 2008, 18:12
Schuster hat geschrieben:Welchen CPLD würdest du empfehlen um die gesamte Logik in einen hinein zu bekommen?

Schau' Dir mal den XC9572 von Xilinx an. Den gibt's im PLCC84 Gehäuse und hat dann (bis zu) 69 I/Os. Bei den kleineren Varianten (im PLCC44 Gehäuse) wird's mit 32-34 I/Os wohl etwas zu knapp (ausser Du lagerst Teile der Logik aus).

Lattice (die ispMach 4A5 Serie, im Freezer steckt ein M4A5-64/32) und Altera (MAX 3000A Serie) sind auch OK, aber da gibt's die CPLDs mit mehr als 32 I/Os nur mehr im ungemütlichen TQFP-100 Gehäuse.

Von den Features her tun sich alle 3 Hersteller nicht viel, auch die Entwicklungssoftware dafür ist in etwa gleich gut/schlecht. Schau' einfach mal bei den Herstellerseiten und bei den Elektronikhändlern nach welche ICs Du am besten bekommst.

Hast du das Design vom Freezer veröffentlicht? Ich frage nur, vielleicht kann man sich ein paar Dinge ja kopieren:-).

Ja, klar. Geh' einfach nach http://turbofreezer.horus.com/ (ist ein redirect nach http://www.horus.com/~hias/freezer/), dort findest Du untern "hardware" den Schaltplan. Aber vorsicht, im Schaltplan sind leider noch ein paar Bugs drin (siehe 00README.txt). Alle 74LSxx sind in Wirklichkeit 74HCTxx, die BAT-48 sollte eine BAT-85 sein und es fehlen noch einige 100nF Bypass Kondensatoren (bei jedem IC ist einer daneben, beim M4A5 sind 2 direkt bei den Versorgungsleitungen).

Dort im "hardware" Verzeichnis findest Du auch die komplette Logik (freezer-logic.zip) als VHDL Source, inkl. ispLever Projekt Files.

so long,

Hias