Kann man sich bei CF-Karten auf LBA verlassen?

[Christian E. (cerker)]

Hallo,

ich bin jetzt mal wieder an dem alten HD6309-Selbstbau-System von meinem 
Vater am arbeiten. Wir wollen dem Gerät nun eine Festplatte verpassen. 
Auch wenn ein SASI-Busadapter mit auf dem Floppycontroller ist, an dem 
SCSI-Platten eigentlich laufen sollten noch, möchten wir das Gerät mit 
IDE und einer CF-Card ausstatten.

Nachdem meine erste Version ala TTL-Grab das Timing versaut hat und 
falsche Werte in falschen Registern landeten (IOWR ging zu spät auf 
High, da hatte die CPU schon Adressen und Daten vom Bus genommen), hab 
ich jetzt eine CPLD-Karte entworfen die ich die Tage aufbauen und testen 
werde .. die hält das gespecte Timing auf beiden Seiten mit 1,5-3facher 
Sicherheit ein.

Hierzu benötige ich natürlich auch eine passende Treibersoftware. Das 
Betriebssystem ist FLEX9, eigentlich ein reines Diskettenbetriebssystem, 
das aber prinzipiell nicht auf ein Medienformat festgeschrieben ist, 
bzw. es außer beim Formatieren garnicht kennt (es wird beim Formatieren 
der Diskette eine sog. "Free-Chain" angelegt, dies ist eine einfach 
verkettete Liste in der sämtliche verfügbaren Sektoren eingetragen sind, 
beim Schreiben von Dateien werden die Sektoren dann aus dieser Liste 
entnommen .. damit ist die Einhaltung der Geometrie implizit gegeben). 
Sektor und Spur sind jeweils ein Byte, damit sind 256 Spuren mal 256 
Sektoren möglich. Jeder Sektor hat 256 Byte. Es werden 4 Laufwerke 
unterstützt.

Dies muss ich nun auf die deutliche größere CF-Card abbilden die dazu 
noch über 512 Byte Sektoren verfügt. Dazu möchte ich auf der CF-Card 
eine Reihe von erweiterten Partitionen <= 16MB (256 Sektoren*256 
Spuren*256 Byte) anlegen und diese mittels Treiber-Software wählbar auf 
die 4 Laufwerke "mounten".

Wenn ich LBA benutzen kann, wird das mappen sehr einfach. Ich würde dann 
einfach die Anforderung von FLEX (Spur und Sektor) zu einer 16bit Zahl 
zusammenfassen, das LSB als Auswahl des oberen oder unteren 
256Byte-Blocks benutzen und die oberen 15bit auf den Startsektor der 
Partition addieren um den gewünschten LBA Sektor zu erhalten. Mit CHS 
wird das ein relativ mühsames Mapping und ich muss dem Treiber immer die 
Geometrie bekannt machen.. bei LBA muss ich nur die höchste Sektornummer 
irgendwo ablegen als Sicherheit.

CF-Karten sind erstmals in der ATA-4 genormt (ja ich weiss die CFA hat 
früher was, aber die wollen Geld ..) und schon in ATA-3 ist LBA Pflicht 
für alle Devices.

So, jetzt endlich zur konkreten Frage: Hat jemand Erfahrungen mit realen 
Karten, ob man sich auf das Vorhandensein von LBA verlassen kann .. oft 
werden Normen ja großzügig ausgelegt und solang es in PC und Digicam 
trotzdem immer geht interessiert es niemanden, selbst wenn mal eine 
Karte Probleme macht wird das als gegeben hingenommen meist.

Gruß,
Christian

[Rufus Τ. F. (rufus)]

Christian Erker schrieb:
> Das Betriebssystem ist FLEX9

Schön, mal wieder von jemandem zu hören, der das verwendet. Lang ist's 
her ... da hab ich mir mal einen Rechner selbstgebaut, auf dem auch Flex 
lief. Mit einer kombinierte RAM- und ROM-Disk und zwei 
Diskettenlaufwerken, dank der ROM-Disk war das System sogar recht flott, 
da das OS, Dienstprogramme und der damals von mir verwendete 
Pascalcompiler darin untergebracht waren.


LBA müsste in CF-Karten ab einer bestimmten Größe eigentlich immer 
vorhanden sein (wenn sie im TrueIDE-Modus betrieben werden), wenn Du 
also nicht gerade welche unter 512 MB verwendest, sollte das eigentlich 
funktionieren. Das ist allerdings nur eine Vermutung.

Besonders schnell wird die Angelegenheit allerdings nicht werden, nicht 
nur, weil Du der 256-Byte-Sektoren wegen die Hälfte der Kapazität nicht 
nutzt, sondern wegen der Eigenheiten des Flex-Dateisystems mit der 
Sektorverkettung.

Die Gesamtkapazität der CF-Karte dürfte annähernd völlig irrelevant 
sein, da es mehr als ein paar MB Software für dieses Betriebssystem kaum 
geben dürfte.

Wie sehen Eure Pläne für das IDE-Interface aus?

[Christian E. (cerker)]

Rufus Τ. Firefly schrieb:
> Christian Erker schrieb:
>> Das Betriebssystem ist FLEX9
>
> Schön, mal wieder von jemandem zu hören, der das verwendet. Lang ist's
> her ... da hab ich mir mal einen Rechner selbstgebaut, auf dem auch Flex
> lief. Mit einer kombinierte RAM- und ROM-Disk und zwei
> Diskettenlaufwerken, dank der ROM-Disk war das System sogar recht flott,
> da das OS, Dienstprogramme und der damals von mir verwendete
> Pascalcompiler darin untergebracht waren.

2 Diskettenlaufwerke haben wir auch, leider nur in Single Density da die 
CPU bei 1MHz kein Double-Density schafft. Der 6309 könnte zwar 
prinzipiell 3MHz, aber da käme wegen des synchronen Businterfaces der 
6800 Reihe die einige Peripherie nicht mit (z.B. der EF9367 
Grafikcontroller).

Das ganze System ist übrigens mehr oder weniger ein auf 6x09 adaptierter 
EC65 (Elektor Computer, eigentlich 6502).

Hier ein paar Bilder:

https://lh5.googleusercontent.com/-fXSYDgzZdYs/TorgIIQqjQI/AAAAAAAAA0s/zDykaTMQ5bU/s576/IMG_5470.JPG

https://lh6.googleusercontent.com/-MhNnb0se5nU/Ton-VZpLa6I/AAAAAAAAAzY/D0A6t8evRyM/s640/IMG_5412.JPG


> Besonders schnell wird die Angelegenheit allerdings nicht werden, nicht
> nur, weil Du der 256-Byte-Sektoren wegen die Hälfte der Kapazität nicht
> nutzt, sondern wegen der Eigenheiten des Flex-Dateisystems mit der
> Sektorverkettung.

Ich hatte in Erwägung gezogen, immer 2 Sektoren in einen 512 Byte Sektor 
zu mappen. Das geht beim Lesen noch ohne Aufwand, beim Schreiben wird es 
etwas lästig da ich den Sektor komplett lesen muss, den jeweiligen Teil 
überschreiben und komplett zurückschreiben.

Wobei sich natürlich ein wenig die Frage nach dem Sinn stellt, ich 
könnte natürlich auch einfach 256 Worte mit MSB = 0x00 schreiben. Die 
halbierte Kapazität sollte nicht weiter stören.


> Die Gesamtkapazität der CF-Karte dürfte annähernd völlig irrelevant
> sein, da es mehr als ein paar MB Software für dieses Betriebssystem kaum
> geben dürfte.

Wenn ich denn mal den GCC für 6809 von William Astle 
(http://www.boxofdoom.net/2011/09/22/how-to-compile-gcc-for-the-6809-processor-gcc6809/) 
ans laufen bekomme (da hakt es noch an einigen Ecken) will ich es mir 
ev. antun mich an einem Contiki-Port zu versuchen .. aber bisher hab ich 
da so einige Probleme .. der Linker scheint keine Symbole für den Anfang 
und die Länge der Sections zu erzeugen, was ich aber im Startupcode 
benötigen würde .. ev. muss ich den Herrn Astle einfach mal anschreiben. 
Das dann eben als ein Betriebssystem das ev. auch mal die eingebaute 
Farbpixelgrafik nutzt. Aber erstmal FLEX auf IDE anpassen.. der Rest 
kommt später.

> Wie sehen Eure Pläne für das IDE-Interface aus?

Momentan ist die Idee ein XC95108 CPLD welches das komplette Interface 
enthält, inkl. Timinganpassung, 16bit Multiplexing .. hierzu habe ich 
mir eine Idee von jemand anders abgeschaut (leider find ich den Quelle 
nicht mehr): Ein Lesezugriff auf Register 0 bewirkt das die ganzen 16bit 
gelesen werden, das MSB auf den Bus gelegt und das LSB gelatcht. Das LSB 
wird dann im darauffolgenden Zugriff auf 0x01 gelesen (hierbei wird 
temporär das Error/Feature-Register überdeckt) .. beim Schreiben wird 
entsprechend beim Zugriff auf 0x00 erst das MSB gelatcht und dann beim 
Zugriff auf 0x01 zusammen mit dem LSB geschrieben. Dies hat den Vorteil 
das ein 16bit Zugriff einfach ein LDD oder STD ist, aber bedingt eben 
etwas Aufwand.

Die erste Version mit TTL-Logik war wie gesagt ein Reinfall, da ich /WR 
für IDE aus E und RW erzeugt habe .. allerdings war die 
Durchlaufverzögerung zu hoch, so dass /WR erst auf High ging als die CPU 
schon die Adressen und Daten vom Bus genommen hatte .. damit landete 
statt 0xEF in 0xE307 .. 0xED in 0xE305 oder so in 50% der Fälle. Das 
CPLD nutzt nun den Q-Takt als Referenz mit, so das /WR deutlich vor der 
fallenden Flanke von E, aber bei schon sicher gültigen Daten und 
Adressen auf High geht. Lesen war mit dem alten Interface problemlos, da 
/RD ja ebenfalls verzögert war und damit das Timing zum positiven 
verschoben hat (es war noch sicher Low an der Fallenden Flanke von E).

Das ist ein Problem der unterschiedlichen Businterface von 6800 und 
8086, der 8086 hält die Daten deutlich länger auf dem Bus nach der 
steigenden Flanke von /WR (je nach Takt 40-90ns).

Gruß,
Christian

[Rufus Τ. F. (rufus)]

Christian Erker schrieb:
> Momentan ist die Idee ein XC95108 CPLD welches das komplette Interface
> enthält ...

Das klingt ziemlich gut, damit dürfte sich 16-Bit-IDE tatsächlich recht 
flott umsetzen lassen.

Allerdings: Wenn Du sowieso ein CPLD verwenden möchtest, wäre dann nicht 
vielleicht die Verwendung von SD-Karten einfacher? Deren Interface ist 
nicht ansatzweise so verdrahtungsintensiv, es ist recht gut dokumentiert 
(zig Leute verwenden SD-Karten an irgendwelchen µCs) und es dürfte für 
einen mit nur 1 MHz getakteten '09 auch mehr als ausreichend schnell 
sein.

> GCC für 6809

Uiuiui. Ich hatte einen nativen K&R-C-Compiler namens "introl C", der 
kannte halt kein C89 (das war, als ich mich damit beschäftigte, auch 
noch nagelneu). Mit C konnte ich aber damals nicht sonderlich viel 
anfangen.

Hier übrigens gibt es einiges an Material zu Flex:
http://www.flexusergroup.com/flexusergroup/fug1.htm

> Das ganze System ist übrigens mehr oder weniger ein auf 6x09
> adaptierter EC65

Meines war weitestgehend auf Lochrasterplatinen gefädelt und nutzte 
einen 68B09E mit 2 MHz Takt und einem daran angeschlossenen ebenfalls 
mit 68B09E aufgebautem Text-Terminal (mit 68B45 als Timingcontroller), 
nachdem ich eine Zeitlang auch ein Graphikterminal genutzt hatte (in der 
c't 1984 vorgestelltes Selbstbauprojekt "Grip" mit Z80 und 6845, hatte 
eine Auflösung von 720x280 Pixeln).
Die Textdarstellung des Graphikterminals gefiel mir nicht sonderlich, 
also gabs dann den Selbstbau mit einer 9x12-Fontmatrix, mit 96 Zeichen 
pro Zeile und 25 Zeilen ... oder sogar 50 im (flacker!) Interlacemodus.

[Christian E. (cerker)]

Rufus Τ. Firefly schrieb:
> Allerdings: Wenn Du sowieso ein CPLD verwenden möchtest, wäre dann nicht
> vielleicht die Verwendung von SD-Karten einfacher? Deren Interface ist
> nicht ansatzweise so verdrahtungsintensiv, es ist recht gut dokumentiert
> (zig Leute verwenden SD-Karten an irgendwelchen µCs) und es dürfte für
> einen mit nur 1 MHz getakteten '09 auch mehr als ausreichend schnell
> sein.

Das klingt jetzt ein wenig "seltsam", aber ich möchte ungern 
"Grundlagen"-Technologien einführen die es damals so nicht gab, eine 
Realisierung mit heutigen Mitteln ist OK .. eine CF-Karte statt einer 
echten Festplatte z.B.

IDE gab es damals schon, zumindest in den Anfängen.

> Uiuiui. Ich hatte einen nativen K&R-C-Compiler namens "introl C", der
> kannte halt kein C89 (das war, als ich mich damit beschäftigte, auch
> noch nagelneu). Mit C konnte ich aber damals nicht sonderlich viel
> anfangen.#

Der GCC ist selbstverständlich ein Crosscompiler, den würde ich 
benötigen um ein angepasstes Contiki zu übersetzen. Introl und "McCosh" 
hab ich beide für direkt auf FLEX.

> Hier übrigens gibt es einiges an Material zu Flex:
> http://www.flexusergroup.com/flexusergroup/fug1.htm

Ich bin schon auf deren Mailingliste und hab diese auch schon genutzt .. 
auf deren FTP Server liegt so einiges an SW, ja.

>> Das ganze System ist übrigens mehr oder weniger ein auf 6x09
>> adaptierter EC65
>
> Meines war weitestgehend auf Lochrasterplatinen gefädelt und nutzte
> einen 68B09E mit 2 MHz Takt und einem daran angeschlossenen ebenfalls
> mit 68B09E aufgebautem Text-Terminal (mit 68B45 als Timingcontroller),
> nachdem ich eine Zeitlang auch ein Graphikterminal genutzt hatte (in der
> c't 1984 vorgestelltes Selbstbauprojekt "Grip" mit Z80 und 6845, hatte
> eine Auflösung von 720x280 Pixeln).
> Die Textdarstellung des Graphikterminals gefiel mir nicht sonderlich,
> also gabs dann den Selbstbau mit einer 9x12-Fontmatrix, mit 96 Zeichen
> pro Zeile und 25 Zeilen ... oder sogar 50 im (flacker!) Interlacemodus.

Spezifikationen zu diesem System:

HD63C09 CPU, 48KB RAM, 8KB ROM
Elektor-VDU Karte mit 6845 für Textgrafik 80x24, erweitert mit 
Attribut-RAM
Floppycontroller WD2797, SASI-Interface (nur paar Bustreiber)
Grafik "Kolorator" mit EF9367: 512x256 Pixel, 16 Farben
Soundchip YM2203C
Sprachaufzeichnung/Wiedergabe mit FX709 CODEC

Der Soundchip kann offenbar so einiges wenn man ihn korrekt 
programmiert:
http://www.youtube.com/watch?v=HqjQV1JUxjM (nur so als Beispiel) ..

Gruß,
Christian