Hi Bernd,

mit 300ns für die /IORD- /IOWR-Signale wird es sehr knapp: Ein CPU-Takt hat genau 1/1,773447Mhz=563ns. Die verteilen sich beim Zugriff aufs CF so:

140 CPU-Address-Setup (laut Datenblatt des 2Mhz 6502)
25? MMU
25 I/O-Decoder (U2)
50 CF-Address-Setup (bei Pio-Mode 1), 70 = Pio-Mode 0
15 steigende Flanke des Taktes (=fallende Flanke der CF-RW-Signale)
290 minimale Breite des CF-RW-Signals
15 fallende Flanke des Taktes (=steigende Flanke der CF-RW-Signale)

Macht 560ns! Anmerkung: Fürs CF-Address-Setup zählt auch der Chip-Enable des CF mit, der aus den Addressleitungen an der MMU und dem dahinterliegenden I/O-Decoder generiert wird.

Vermutlich ist es daher besser, bei etwa 270-280ns zu bleiben, um Reserven bei leichten Taktverschiebungen zu haben. Fürs Schreiben eignet sich wohl Phi0 an der CPU und fürs Lesen Phi2 an der PIA am besten (diese beiden Signale kommen ja aus den LS-Gattern, die 20 LS-TTL-Lasten tragen können, ohne gleich zusammenzubrechen).

Gruß Dietrich

Hallo,

ich habe da noch einige Infos über die Signale am Freddi gefunden.

http://hardware.atari8.info/freddie/symulacja.gif
und
http://hardware.atari8.info/freddie.php

Bernd

Hallo Bernd!

Erstmal vielen Dank für Deine Messungen! Zur genauen Interpretation der Ergebnisse aber noch ein paar Anmerkungen:

Bei der Bestimmung der Signaldauer (zB PHI2=high) solltest Du nicht bei 0 zu Messen beginnen, sondern die Schaltschwellen der verwendeten ICs berücksichtigen. Bei TTL kompatiblen ICs (74LS, 74HCT etc) ist VIL max 0.8V, VIH min 2.0V. Dazwischen ist's undefiniert, es kann sein daß das IC bei 0.8V schon wechselt, oder auch erst bei 2.0V.

Ich habe nun anhand der Grafiken versucht das mit einzubeziehen. Hier die Dauer von Signal=high bei Berücksichtigung verschiedener Schaltschwellen:

Code: Alles auswählen

             0.8V   1.4V   2.0V
PHI0(CPU)     305    295    280
PHI2(LS08)    310    300    290

Von der Phasenlage her müsste man natürlich auch noch die Fälle berücksichtigen, wo zB lo->hi bei 0.8V und hi->lo bei 2.0V stattfindet, aber das können wir hier ignorieren. Die Signallänge liegt dementsprechend irgendwo zwischen min und max.

Die 280ns minimale Länge sind zwar etwas knapp, aber ansonsten denke ich, daß es mit PHI0 für's Schreiben und mit PHI2 (am Ausgang des LS08) für's Lesen klappen sollte!

so long,

Hias

Dietrich hat geschrieben:

Hias hat geschrieben:Bei den Compact-Flash Karten gibt es einen Modus, sodaß Daten-Transfers auch in 8bit möglich sind (über das Set Features Kommando, $EF, Feature $01). Ich hatte das mal ausprobiert, aber es hat nicht so richtig geklappt. Hattest Du in dieser Richtung schon Erfolg?

Jo, genau das klappt bei mir. Ich habe ein Basic-Pgm (mit etwas 6502-Code) geschrieben, das den Atari auf eingebaute CF-Karten untersucht, dann mit "Set Feature" in den 8bit-Modus geht und anschließend einen "Identify Device" ausführt. Auch beim Schreiben und Lesen von 512 Byte-Sektoren gabs im 8bit-Betrieb keine Probleme.

So, nun hat's bei mir auch geklappt. Nunja, eigentlich hatte es wohl vorher auch schon funktioniert, nur war ich zu blöd in meinem Turbo-Basic Testprogramm auch das richtige Gosub zu verwenden. Wenn man die CF Karte in den 16-Bit Modus versetzt, soll man sich nicht wundern wenn man keine 512 Bytes zurückbekommt...

Dietrich hat geschrieben: Im 8bit-Betrieb kriege ich 4- bis 8mal soviele Images auf ein CF wie bei MyIDE :mrgreen:

Ich würd' eher sagen 2 bzw. 4 mal so viele, um genau zu sein :-)

Ein kleines Problem bei mehreren logischen (Atari) Sektoren pro physikalischem (harddrive/cf card) Sektor ist ja das Schreiben. Ohne 512 Byte Sektorpuffer wird das schwierig. Hast Du dafür schon eine elegante, kompatible Lösung gefunden?

Ich habe mich ein wenig durch die diversen Specs (ATA/ATAPI, CF, SCSI, Sandisk) gewühlt, in der Hoffnung daß es irgendeine Möglichkeit geben könnte evtl. einen Sektor-Cache in der HDD/CF-Card dafür zu missbrauchen (sowas wie die Read/Write Buffer SCSI Kommandos), habe aber leider nichts brauchbares gefunden. Die Sandisk Karten unterstützen auch leider nicht das Packet Kommando (ist auch nicht in der CF Spec enthalten), sieht also eher schlecht aus...

so long,

Hias

Hias hat geschrieben:Ich würd' eher sagen 2 bzw. 4 mal so viele (Partitionen), um genau zu sein

In SD/MD sind es 4-8mal so viele, in DD 2-4mal so viele. Grund ist, dass bei MyIDE ein Image immer am Beginn eines Cylinders beginnt, das kann zu einer recht großen Lücke führen, die im Extremfall fast so groß wie ein Image selbst ist. Da ich das CF im LBA-Modus anspreche (keine Lust mit CHS rumzurechnen) und für jedes Image den Startsektor speichere, gibt es bei mir keine Lücken.

Ohne 512 Byte Sektorpuffer wird das schwierig. Hast Du dafür schon eine elegante, kompatible Lösung gefunden?

Ursprünglich wollte ich das RAM unter $D600-$D7FF dafür benutzen (diese 512 Byte RAM kann man mit ein paar Gattern aktivieren). Aber ich bin davon abgekommen, um die Schaltung einfach zu halten - und natürlich, weil der Turbo-Freezer $D7xx benutzt, wie ich gesehen habe
Also mach ich's ganz einfach: Die meisten Images sind ohnehin Spiele, d.h. Nur-Lese-Partitionen. Und wenn man auf den Schreibzugriff verzichtet, braucht man auch keinen Puffer
Natürlich kann man auch Schreib-Images/Partitionen anlegen. Bei denen ist das Sektor-Mapping dann eben 1:1, was natürlich Platz kostet.

Hias hat geschrieben:...in der Hoffnung daß es irgendeine Möglichkeit geben könnte evtl. einen Sektor-Cache in der HDD/CF-Card dafür zu missbrauchen

Da hab ich auch schon nachgeguckt. Es gibt zwar Kommandos mit denen man den (einen) Sektor-Puffer des CF beschreiben und wieder auslesen kann. Dummerweise ist der Inhalt des Puffers nach einem Lese/Schreibkommando wieder hinüber. Schade eigentlich!

Dietrich hat geschrieben:In SD/MD sind es 4-8mal so viele, in DD 2-4mal so viele. Grund ist, dass bei MyIDE ein Image immer am Beginn eines Cylinders beginnt, das kann zu einer recht großen Lücke führen, die im Extremfall fast so groß wie ein Image selbst ist. Da ich das CF im LBA-Modus anspreche (keine Lust mit CHS rumzurechnen) und für jedes Image den Startsektor speichere, gibt es bei mir keine Lücken. :smile:

Ah, ja, das ist eine sehr gute Idee!

Ursprünglich wollte ich das RAM unter $D600-$D7FF dafür benutzen (diese 512 Byte RAM kann man mit ein paar Gattern aktivieren). Aber ich bin davon abgekommen, um die Schaltung einfach zu halten - und natürlich, weil der Turbo-Freezer $D7xx benutzt, wie ich gesehen habe :wink:

OK. Man könnte natürlich auch (mit einer kleinen Zusatz-Schaltung) eine der 8 RAM-Pages im Bereich D000-D7FF nach D6xx mappen. zB gesteuert durch ein paar Adressen in D1xx. Damit hätte man dann insgesamt 2k Puffer. Ist aber natürlich alles ein ziemlich großer Aufwand.

Also mach ich's ganz einfach: Die meisten Images sind ohnehin Spiele, d.h. Nur-Lese-Partitionen. Und wenn man auf den Schreibzugriff verzichtet, braucht man auch keinen Puffer :smile:
Natürlich kann man auch Schreib-Images/Partitionen anlegen. Bei denen ist das Sektor-Mapping dann eben 1:1, was natürlich Platz kostet.

OK, das ist meiner Meinung nach ein sehr guter Kompromiss!

Wann gibt's die erste Version zum Testen? :-)

so long,

Hias

@Dietrich: Da fällt mir gerade noch eine Frage ein :-)

Wie planst Du denn die Partitions-Verwaltung zu machen?

Die Variante, wie sie beim MyIDE gemacht wird (max. 8 fixe Partitionen, der Rest "image space") finde ich nicht so toll - IMHO etwas unflexibel. So, wie's bei der BlackBox ist (beliebig viele Partitionen möglich), finde ich persönlich es schon besser. Etwas störend ist bei der BlackBox aber, daß die Partitions-Tabellen recht beschränkt sind und man so bei größeren Platten recht häufig zwischen verschiedenen Partitions-Tabellen wechseln muß.

Sehr praktisch wäre es auch, wenn man ein paar Default-Konfigurationen (zB 10 oder 20) abspeichern könnte, sodaß man dann schnell Zugriff auf verschiedene, oft benötigte Setups hat.

so long,

Hias

@hias: Da das hier jetzt etwas Offtopic wird, habe ich einen neuen Thread aufgemacht:
http://www.abbuc.de/modules.php?name=Fo ... pic&t=2373

[quote="Dietrich"]Hey Bernd,

Mögliche Gegenmaßnahmen wären:

b) Den gewünschten Ausgang des I/O-Page-Decoders (U2, D5xx, D1xx oder D6xx) zur Aktivierung des CF sowie die Adressleitungen A0, A1 und A2 über von PHI2 gesteuerte Latches an das CF anschliessen. Die Latches sollen durchlässig sein, wenn PHI2 Low ist und bei PHI2 = High sperren. Damit wäre sichergestellt, dass sich am CF der Chip-Enable und die Adressleitungen nicht ändern solange PHI2 High ist, egal was die CPU macht.

(Soweit das Zitat)

Meiner Erfahrung nach ist das Einbauen von Addresslatches der einzige robuste Weg, um den parallelen Bus wirklich stabil zu kriegen.
Allerdings sollte man bei Schreibzugriffen den Write-Impuls kürzen (so dass er vor der fallenden Flanke von Phi2 weggeht, ca. 50 ns reichen da), weil bei manchen Ataris auch die Daten zerbröseln, bevor PHI2 (am PBI) fällt.
Letzterer Trick war schon im TURBO FREEZER III (1988) eingebaut.
Der neue FREEZER IV hat auch die Adresslatches.
Beide Massnahmen zusammen ergeben erst einen brauchbaren parallelen Bus.
Wundert sich noch wer, warum es damals kaum Hardware für den PBI gab ? Und wer's dennoch versucht hat, kriegte Berge von Retouren... nur weil die Ataris sich nicht an die Atari - eigenen Spezifikationen gehalten haben. Eine echte Schande, das. (Bin heute noch wütend...)

UnclieBernie hat geschrieben:Allerdings sollte man bei Schreibzugriffen den Write-Impuls kürzen

Deshalb werden wir fürs Schreiben auch PHI0 statt PHI2 benutzen (siehe irgendwo weiter oben im Thread). Den Write-Impuls kann man nicht kürzen, da CFs einen 290ns langen Write-Impuls verlangen (siehe oben). Den ganzen Write-Impuls um 50ns vorverlegen dürfte zuviel sein, da dann andere Timing-Bedinungen des Atari und des CF verletzt werden, siehe die Rechnung oben.