CE kann eigentlich immer an Masse liegen, wenn kein anderer Chip am gleichen Bus ist. Das ist ja hier der Fall. (CE = Chip Enabled)

_________________
mfg Jornbyte

Es handelt sich bei dem Tipp nicht um eine Rechtsverbindliche Auskunft und
wer Tippfehler findet, kann sie behalten.

CE liegt wieder an Masse, und ich habe mal alle Delays entfernt.
Und es geht (so halbe) !!!
Ab und zu liefert er zwar falche Werte, aber ansonsten geht es.
Kann es sein, dass nach der Aktivierung, der Modus nur für eine begrenzte Zeit aktiv bleibt ?
Sobald ich nach dem ID Mode Befehl ein paar ms warte, liefert er wieder die EPROM Werte. Aber selbst im Datenblatt steht: 10ms Pause nach dem Befehl ?!?

Zu früh gefreut.
Es war zufällig derselbe Wert, wie eigentlich erscheinen sollte.
Ich habe nochmals alles Überprüft:
Ich stelle die Adresse ein, sende ein Byte.
Und das ganze 3x.
Die Adresse stimmt, denn ich habe vor dem Bytesenden ein Byte gelesen, und dies stimmt mit dem Inhalt des EPROMs an der Stelle überein.
Der Sendealgorithmus passt auch, denn ein 28Fxxx geht. Allerdings werden hier die Bytes an Adresse 0 gesendet.

Mir ist dabei aufgefallen, dass unmittelbar nach dem Senden, das gelesene Byte weder dem Inhalt des Bytes, noch dem gesendeten entspricht. Man muss etwa 2ms warten, bis man ein richtiges Byte lesen kann.
Warum ?
Möglichkeit a): Das EPROM verarbeitet das eben gesendete Byte.
Möglichkeit b): Was könnte es sonst noch sein ???

den b austein schon in einem kommerziellen romburner getestet? vileicht isser futsch

sorry die antwort bezog sich auf seite 1 von 2,kannste streichen,wird net defekt sein

>Mir ist dabei aufgefallen, dass unmittelbar nach dem Senden,
> das gelesene Byte weder dem Inhalt des Bytes, noch dem gesendeten entspricht. Man muss >etwa 2ms warten, bis man ein richtiges Byte lesen kann.


Warum Du unmittelbar nach den Kommandos keine gültigen Daten bekommst steht im Datenblatt. Unmittelbar nach der "Software Product Identification Entry" Kommandosequenz musst Du 10ms warten. Schau mal die Flowchart.

>Der Sendealgorithmus passt auch, denn ein 28Fxxx geht.
>Allerdings werden hier die Bytes an Adresse 0 gesendet.

Das deutet daraufhin, daß Du ein Problem mit dem Adressgenerator hast.
Zähler! Pfui!
Wie lange braucht Dein Programm denn, um von 0 auf 5555 oder auf 2aaaa zu zählen ?
Warum benutzest Du nicht 8-Bit-Register ? Dann dauert das höchstens 2 Clocks.
Der 29C.. erwartet ja gar nicht, daß Daten und Adressen bis in alle Ewigkeit stabil sind, da er interne Latches dafür hat (Datenstrobe= -CE * -WR, Adressstrobe= -CE * WR ).

Und weil diese Latches vorhanden sind, mag es außerdem sein, daß just im Moment der Pegeländerung auf der Steuerleitung am Ende Deines 5m langes Kabel per Übersprechen etwas ganz anderes produziert wird, als was Du in den LPT-Port geschrieben hast.
Laut Datenblatt ist ein 50ns Glitch reichlich ausreichend.

Als erstes würde ich das lange (Rund?)Kabel durch ein möglichst kurzes Flachkabel ersetzen, damit diese vorsätzliche Fehlerquelle entfällt.

perl >Mir ist dabei aufgefallen, dass unmittelbar nach dem Senden,
> das gelesene Byte weder dem Inhalt des Bytes, noch dem gesendeten entspricht. Man muss >etwa 2ms warten, bis man ein richtiges Byte lesen kann.


Warum Du unmittelbar nach den Kommandos keine gültigen Daten bekommst steht im Datenblatt. Unmittelbar nach der "Software Product Identification Entry" Kommandosequenz musst Du 10ms warten. Schau mal die Flowchart.

aber dann liefert er den Inhalt des EPROMs !

>Der Sendealgorithmus passt auch, denn ein 28Fxxx geht.
>Allerdings werden hier die Bytes an Adresse 0 gesendet.

Das deutet daraufhin, daß Du ein Problem mit dem Adressgenerator hast.
Zähler! Pfui!
Wie lange braucht Dein Programm denn, um von 0 auf 5555 oder auf 2aaaa zu zählen ?
Warum benutzest Du nicht 8-Bit-Register ?

das ding hat 17 Adressanschlüsse !!!
nehme ich 2 Register, brauche ich ein drittes wegen einer Adressleitung !

Dann dauert das höchstens 2 Clocks.
Der 29C.. erwartet ja gar nicht, daß Daten und Adressen bis in alle Ewigkeit stabil sind, da er interne Latches dafür hat (Datenstrobe= -CE * -WR, Adressstrobe= -CE * WR ).


Und weil diese Latches vorhanden sind, mag es außerdem sein, daß just im Moment der Pegeländerung auf der Steuerleitung am Ende Deines 5m langes Kabel per Übersprechen etwas ganz anderes produziert wird, als was Du in den LPT-Port geschrieben hast.
Laut Datenblatt ist ein 50ns Glitch reichlich ausreichend.

nachdem ich das kabel auf etwa 1m gekürzt hatte, und 74hc4040 einsetzte, hatte ich massive Probleme, dass einzelne Adressen übersprungen wurden. Dies habe ich mit 100pF 1k gelöst.

Als erstes würde ich das lange (Rund?)Kabel durch ein möglichst kurzes Flachkabel ersetzen, damit diese vorsätzliche Fehlerquelle entfällt.

Wenn ich aber mal Zeit habe, baue ich eine neue Schaltung mit 3x 74HC574.
Die Clock Leitungen werden mit einem 2 zu 4 Dekoder steueren.

>aber dann liefert er den Inhalt des EPROMs !

Scheint daß der Chip ein angefangenes Kommando per Timeout beendet.


>>Laut Datenblatt ist ein 50ns Glitch reichlich ausreichend.

>nachdem ich das kabel auf etwa 1m gekürzt hatte, und 74hc4040 einsetzte, hatte ich massive Probleme, dass einzelne Adressen übersprungen wurden

Da siehst Du's, das sind offenbar die Reflektionen im Kabel. Die kann man bändigen, wenn man am Computerende in alle Signalleitungen rund 30..50 Ohm Widerstände einfügt.
Die Versorgungen an den Chips hast Du doch wohl hoffentlich abgeblockt?



>das ding hat 17 Adressanschlüsse !!!
nehme ich 2 Register, brauche ich ein drittes wegen einer Adressleitung !


Hat sogar 18 Adressleitungen, trotzdem brauchst Du wegen der internen Latches nur entweder zwei 8 Bit Register oder ein 8-Bit und ein 2-Bit (zB.74HC74):
D7....D0 vom LPT
IIIIIIII
++++++++---->A0..A7
IIIIIIII
I7....I0
Register
Q7....Q0
IIIIIIII
++++++++---->A8..A15
IIIIIIII
Register
Q1Q0---->A16,A17

Einen Decoder brauchst Du nicht, Du kannst die Clocks einfach zusammenbinden und
die alte RES-Leitung brauchst Du auch nicht mehr.

Außerdem, was soll der Geiz?






[ Diese Nachricht wurde geändert von: perl am 2002-09-09 18:24 ]

Weiterhin sehe ich folgenden Fehler:

Du schreibst:
>CE wird invertiert, und zusammen mit OE einem NAND Gatter zugeführt. Daraus wird WE erzeugt.

Später schreibst Du:
>CE liegt wieder an Masse, und ich habe mal alle Delays entfernt.


Das bedeutet, Du hast die Daten am LPT, der PROM hat ebenfalls OE aktiv und qualmt vor sich hin .
Man nennt das auch "Bus Contention".
Die Daten auf dem Bus sind die des stärkeren.
Dann schaltest Du praktisch gleichzeitig WE und OE um.
Noch bevor sich die Datenleitungen vom Kurzschluß beruhigt haben, latcht der PROM das, was er in diesem Moment sieht.
So darf das nicht sein!
Im DB steht, daß die Daten 50ns vor -WE stabil (und natürlich richtig) sein müssen und dann nicht mehr gehalten werden brauchen.

Nicht ganz:
Sobald OE auf 1 geht, bekommt WE denselben Pegel wie CE, ansonsten liegt WE auf 1.

Ich habe nun eine neue Schaltung überlegt. So einfache Sachen wie Spannungsversorgung und Kondensatoren fehlen noch.
Ist die Schaltung so OK ?

Uploaded Image: Flash4.gif

Sieht brauchbar aus.
Allerdings würde ich lieber A0..A7 ungepuffert zuführen, dann brauchst Du für die 256 Bytes eines Sektors die Register nicht mehr zu verändern.

Wie ich oben schrieb, ist eine Clock Leitung für die Register ausreichend. Falls Du tatsächlich mal alle Adressen puffern willst, brauchtst Du dann nur noch ein Register dazupappen, während Du bei Deiner parallelen Anordnung der Register mit den Steuerleitungen am Ende bist.

Achte drauf, daß der LPT im Standard (SPP) Mode läuft. In ECP oder EPP bekommst Du wahrscheinlich Kummer mit dem Protokoll und den FIFOs.

Viel Glück!

[ Diese Nachricht wurde geändert von: perl am 2002-09-09 23:52 ]

Du hast bei der Schaltung etwas übersehen:
Ist mir gestern aben auch nicht gleich eingefallen:
Die Adressleitungen werden nur beim Byte Load gelatched.
Beim Lesen der Daten müssen die Adressdaten die ganze Zeit anstehen. -> Weiteres 75HC574 und Adressdekoder für die Clock Leitung notwendig.

Ich betreibe den LPT Port laut BIOS im EPP/ECP Modus.
Dann sind die 4 Control Leitungen Open Kolllektor mit Pullups. Diese sind dann auch von außen auf Masse legbar. So in etwa wie I²C.
Dies kann ich beim EPROM aber nicht gebrauchen, und muss den Port softwaremäßig in den Standart Mode umschalten. Jetzt ist der Control Port TTL Ausgang, und die 8 Bit Leitungen sind in der Richtung umschaltbar, was im EPP Modus nicht geht.
Dies nur mal nebenbei.

Du brauchst trotzdem keinen Adressdecoder wenn Du die Register hintereinander hängst.
3 mal tick-tack an der gemeinsamen Clockleitung und alle Register sind geladen.