Fällt mir noch ein:

Wenn wir den DOS2.5 Standard nun setzen, mache ich mir mal um die Textdateien Gedanken. Dann ist es mit einer Datei pro Text schlecht bestellt, 64 Dateien sind gleich aufgebraucht. Man könnte dann aber über eine grosse Datei verfahren, in der als Trenner zwischen den einzelnen Texten der spezifische Kenner, z.B. Programmnummer wie in der Datenbank steht.
Das kann man dann finden und ausgeben. Damit ist die 64 Dateiengrenze umschifft, wird halt langsamer beim Aufbau der Programmbeschreibung, je weiter die Programmbeschreibung hinten ist.



Da es aber ein Unterprozess ist, könnte man damit wohl leben.

Gruss, Holger

Rockford hat geschrieben:Kategorieschlüssel: Habe ich schon definiert. Muss ich Dir noch schicken, findest du aber auch am Ende des Programmes in den DATA Zeilen.

Ja, hatte ich aber als Versuchsdaten betrachtet ...

Wie schon angesprochen, bin ich schon länger daran, die Daten insgesamt zu bereinigen. Geschätzt sind vielleicht jetzt knapp über 50% der PDs durchgearbeitet.

Dabei werden die Angaben in der PD-Liste mit dem tatsächlichen Inhalt, dem Format, etc. der Disks verglichen. Danach wird der Text korrigiert und die ODS-Tabelle upgedatet.
Die Programme den Kategorien/Unterkategorien zugeordnet und der entsprechende Eintrag gemacht. Regelmäßig müssen auch die Disks korrigiert werden, weil Fehler drin sind. Insgesamt ist das nichts was sich mal eben so machen lässt. Spätestens bei Programmfehlern, die ich mit BASIC nicht korrigieren kann, ist mein Potential erschöpft. Ich hoffe dann ca. 99,9% Fehlerfreiheit zu erreichen, wenn die Datenbank auf dem XL/XE läuft.
Die verbleibenden Fehler sind/werden erfasst und ich werde gezielt um Hilfen bitten.

@Walter: P.S: Hast Du meine Mail erhalten?

Jo, bin aber heute nicht mehr in der Lage, das zu beantworten.

Gruss, Holger[/quote]

Rockford hat geschrieben:Fällt mir noch ein: Wenn wir den DOS2.5 Standard nun setzen...

Naja, auch auf die Gefahr hin Haue zu kriegen ...

SpartaDOS bietet da mehr und man müsste mal die Diskversion eruieren, was da so geht.
Als Bootdisk in SDCS 2.3 oder 3.2 kann man dem User alles mitliefern ...
Und von da auf eine Festplatte etc. ist es kein Akt ...

Persönlich werde ich da SDX 4.42 und eine CompactFlash-Karte am IDE-Controller nehmen.

GoodByteXL hat geschrieben:Naja, auch auf die Gefahr hin Haue zu kriegen ...

SpartaDOS bietet da mehr und man müsste mal die Diskversion eruieren, was da so geht.
Als Bootdisk in SDCS 2.3 oder 3.2 kann man dem User alles mitliefern ...

Haue gibts nich...is ne Idee & sollte man mal verfolgen.

Bräuchte in diesem Falle ein Diskimage oder SDCS2.3 oder 3.2.
Hab weder noch. Müsste dann ja den Zugriff mit den vielen Dateien auch prüfen.
Gibts bei den SpartaDOS Versionen Probleme mit anderen Diskstationen, z.B. 810er oder XF551?

Rockford hat geschrieben:Haue gibts nich...is ne Idee & sollte man mal verfolgen.

Bräuchte in diesem Falle ein Diskimage oder SDCS2.3 oder 3.2.
Hab weder noch. Müsste dann ja den Zugriff mit den vielen Dateien auch prüfen.
Gibts bei den SpartaDOS Versionen Probleme mit anderen Diskstationen, z.B. 810er oder XF551?

Ok, Image kommt. Aber ein Manual dazu habe ich nicht digital.
Funzt im Prinzip wie MSDOS.
Und deswegen gibt's auch keine Probleme mit Laufwerken, egal welche, auch Fremdlaufwerke laufen problemlos.

Moin

Bräuchte in diesem Falle ein Diskimage oder SDCS2.3 oder 3.2.

Wie verträgt sich das eigentlich mit Turbo Basic? MyDOS geht ja soweit ich weiß problemlos.

Gruß,

Michael

Das gilt es herauszufinden, da TBS und SDCS Speicher unterm OS benutzen.

Alternativ bleibe dann noch ACTION! oder BASIC XL.

Alternativ bleibe dann noch ACTION! oder BASIC XL.

Auch eine Alternative wäre evtl. Kyan Pascal. Das ist gut geeigneit, um mit "Daten-Records" umzugehen.

Das alles wäre für Holger aber vielleicht nicht ganz so schön, er hat ja schon einige Zeilen in den PD-Reader gesteckt...

Also auch noch mal MyDOS + TBXL als Option in Betracht ziehen oder gibt's da was zu bedenken?

Jau,
oder man nimmt Bewe-DOS, damit hat man dann auch Sparta-Format und TB XL funkt. wie es soll. Denn bewe-DOS benutzt kein RAM unter dem OS. Zudem ist Bewe-DOS Freeware und der lästige XF-Bug von Sparta 3.2 ist dort nicht vorhanden... Last not least haben es recht viele Abbucianer in ihrer Sammlung (Bewedos war mal Sondermagazin und/oder Jahresgabe)...

Glaube mich zu erinnern, dass BeweDOS so max. 1424 (?) Dateien auf der Disk zuläßt. Müßte dazu aber nochmal das Handbuch studieren, denn es kann sein, dass diese Zahl total falsch oder vielleicht auch formatabhängig ist... BeweDOS supportet 4 Laufwerke und Ramdisks bis zu 1MB, hat einen Formatter für 90, 130, 180 und 360k - es kann aber auch alle Sparta Formate bis 16MB lesen und beschreiben (man kann es auch auf große Sparta Disks oder Partitionen drauf kopieren und bootfähig machen)...

Gruß, Andreas Koch.

CharlieChaplin hat geschrieben:...oder man nimmt Bewe-DOS, damit hat man dann auch

Welche Version ist da eigentlich aktuell?

cas hat ja ein Manual für die 1.3er ins Web gestellt:

http://atariwiki.strotmann.de/xwiki/bin/view/APG/BeweDOS

Zur Anzahl der Dateien steht dort:

BW-DOS directories may contain up to 1424 files or directories, but it is recommended to keep this number less than 100, because the access to long directories is slow. Besides of this, while working with SpartaDOS, only SpartaDOS X (version 4.x) is able to use BW-DOS directories in full - other versions will work only with the first 126 files (the rest will be invisible).

Charlie: Volltreffer !

mp-one hat geschrieben:

Alternativ bleibe dann noch ACTION! oder BASIC XL.

Auch eine Alternative wäre evtl. Kyan Pascal. Das ist gut geeigneit, um mit "Daten-Records" umzugehen.

Das alles wäre für Holger aber vielleicht nicht ganz so schön, er hat ja schon einige Zeilen in den PD-Reader gesteckt...

Stimmt. Steckt schon was drin. Bei anderen Sprachen als TBS oder Atatri Basic wäre ich erst mal aussen vor, da ich da kein Wissen besitze und es mir erstmal auch nicht aneignen will.
Dennoch: Sollte sich jemand finden, der Die PDReader Software in einer anderen Programmiersprache umsetzen will und auch kann, dann kann er sich da gerne einbringen.
Der bis jetzt von mir geschriebene Code ist für mich auch sonst nutzbar, da einigermassen modular.

So, dies sind noch mal die XIO-Commands für BeWe-Dos:

Code: Alles auswählen

XIO 33,#iocb,0,0,"Dn:[path>]filename"  = the "ERASE" command
XIO 35,#iocb,0,0,"Dn:[path>]filename"  = the "PROTECT" command
XIO 36,#iocb,0,0,"Dn:[path>]filename"  = the "UNPROTECT" command
XIO 40,#iocb,4,0,"Dn:[path>]filename"  = load and run a program
XIO 40,#iocb,4,128,"Dn:[path>]filename"= the "LOAD" command
XIO 42,#iocb,0,0,"Dn:[path>]name"      = the "CREDIR" command
XIO 43,#iocb,0,0,"Dn:[path>]name"      = the "DELDIR" command
XIO 44,#iocb,0,0,"Dn:path"             = the "CWD" command.

Auch recht mächtig!

Afaik,
Version 1.3 ist die letzte bzw. aktuellste von Bewe-DOS...
-Andreas Koch.

mp-one hat geschrieben:Auch eine Alternative wäre evtl. Kyan Pascal. Das ist gut geeigneit, um mit "Daten-Records" umzugehen.

Nee, PASCAL ist auf DOS2-Derivate geeicht, was das Filesystem angeht. Da ist das SpartaDOS-FS, das in der Version von SDX 4.2x von BeweDOS nachprogrammiert wurde, besser geeignet, da es relative Zugriffe erlaubt.

Also auch noch mal MyDOS + TBXL als Option in Betracht ziehen oder gibt's da was zu bedenken?

Jo, MyDOS ist ein DOS2-Derivat mit all den Fehlern und Schwächen.

Als KGN ist DOS 2.5 & TurboBASIC XL auf einem 64KB-XL/XE und nackter 1050 die Basis.

Nimmt man diese Hardware als das Minimum an (800/48KB und nackte 810er mal außen vor gelassen, weil wenig verbreitet), kann man nur noch beim DOS oder der Programmiersprache tunen. TBS ist für ein OpenSourceProjekt natürlich die bessere Lösung, alternativ bliebe sonst noch das ATARI BASIC, will man jedem User Einblick gewähren.

Damit kann man nur noch am DOS schrauben. Und da ein sequentielles FileSystem beim Arbeiten mit einer DB nun mal deutlich langsamer ist als ein relatives, kam ich auf SpartaDOS.
Wäre aber wohl doch eher was für eine Prof-Version.
Für OpenSource wäre BeweDOS als Test gut geeignet.
Die Home-Version sollte mit DOS2.5 ausreichend bestückt sein.

Der Unterschied:
Unlike Atari DOS and compatibles, which use an absolute physical disk position (sector and offset into sector) for the NOTE and POINT functions, SpartaDOS X uses a relative position within the file. POS is the desired offset into the currently open file. For example, if POS was 612, the next GET from the file would get the 613th byte of the file. This value will refer to the same position in the file even if the file is physically moved to another disk. The file must be open for this operation.

Because of a limitation in Atari BASIC, BASIC XL, and BASIC XE, the first method shown, using the POINT command, will only work with positions up to and including 32767. If a value greater than 32767 is given a BASIC error will occur. To POINT to a greater location with these languages (and possibly others) it is necessary to use the second method. The POINT command is bypassed by poking the three byte file position directly into the IOCB registers and executing the XIO. Aux1 and aux2 must be the values used when the file was opened.

Other languages, such as ACTION! and Turbo BASIC XL, have no such limitation on the POINT command, allowing it to be used instead of the lengthy XIO method.

GoodByteXL hat geschrieben:
Damit kann man nur noch am DOS schrauben. Und da ein sequentielles FileSystem beim Arbeiten mit einer DB nun mal deutlich langsamer ist als ein relatives, kam ich auf SpartaDOS.
Wäre aber wohl doch eher was für eine Prof-Version.
Für OpenSource wäre BeweDOS als Test gut geeignet.
Die Home-Version sollte mit DOS2.5 ausreichend bestückt sein.

Gut, heisst für mich, dass ich mich erstmal auf die Homeversion konzentriere (800XL+1050er ohne upgrades + DOS2.5).
Details zum Datensatzformat+zu den Texten können wir ja intern durchsprechen, Walter.
Wenn die erste offizielle Version steht, ist es ja damit nicht beendet. Da ich es als Open Source mache und dies auch beibehalten will, wird es Versionsnummern geben. Sprich: Die erste offizielle stabile Version wird dann 1.0 sein.

Auf jeden Fall bin ich für die bis jetzt von allen eingebrachten Punkte und Ideen dankbar. Für den Pdreader hat sich die neue Rubrik Programmierung hier im Forum schon richtig gelohnt.

Gruss, Holger

GoodByteXL hat geschrieben:

mp-one hat geschrieben:Auch eine Alternative wäre evtl. Kyan Pascal. Das ist gut geeigneit, um mit "Daten-Records" umzugehen.

Nee, PASCAL ist auf DOS2-Derivate geeicht, was das Filesystem angeht. Da ist das SpartaDOS-FS, das in der Version von SDX 4.2x von BeweDOS nachprogrammiert wurde, besser geeignet, da es relative Zugriffe erlaubt.

Hi Walter,

das bezog sich nicht auf das DOS sondern auf den in Pascal vorhandenen RECORD-Datentyp. Da kann man mehrere Variablen zu einem Typ zusammenfassen und dann gemeinsam verwalten. In Kyan Pascal etwa so:

Code: Alles auswählen

TYPE
  ABBUC_PDListe = RECORD
    PDNR : Integer;
    PDName : String[40];
    PDGenre : Integer;
  END;

Var MyPDListe : ABBUC_PDListe;


Im Programm kann man dann solche Strukturen, also z.B. den Datensatz einer ganzen PD-Disk, mit einem einzigen Befehl PUT(MyPDListe) auf Disk schreiben, von dort lesen usw. In Turbo Basic muss man dafür mehrere Print # oder Put # Befehle nehmen, hat also mehr zu tun. Daher hatte ich (Kyan-) Pascal als grundsätzlich recht gut geeignet angesehen.

In Pascal gibt es u.a. den SEEK-Befehl, mit dem man wahlfreien Zugriff in die Datei hat. Dieses entspricht sogar eher dem relativen Zugriff als der NOTE- und POINT-Methode von BASIC.

Gruß,

Michael



Gruß,

Michael

mp-one hat geschrieben:In Pascal gibt es u.a. den SEEK-Befehl, mit dem man wahlfreien Zugriff in die Datei hat. Dieses entspricht sogar eher dem relativen Zugriff als der NOTE- und POINT-Methode von BASIC.

Ja, das ist in PASCAL komfortabel zu machen, aber NOTE und POINT arbeiten in DOS2-Derivaten ausschließlich sequentiell und orientieren sich an den physikalischen Sektoren auf dem Datenträger, was schön simpel aber für große Datenmengen unbrauchbar ist.
Wie vorher schon beschrieben, muss dann bei jeder Operation jedesmal beim 1. Sektor des Files auf der Disk angefangen werden zu lesen, um den z.B. Datensatz 453 zu finden.
Jetzt stell dir das bei der PD-DB mit zig Programmen, also Datensätzen vor ...
Selbst bei einer ED-Disk ist das schon elend langsam.

Und da Kyan PASCAL, soweit ich weiß, nicht mit SDCS oder SDX arbeitet, ist es (leider) keine Alternative, obwohl mit PASCAL an sich schön zu programmieren ist.
Für große Datenmengen kann man von den Hochsprachen bequem eigentlich nur TBS oder ACTION benutzen unter einem DOS, das im Gegensatz zu DOS2 so klever arbeitet wie MSDOS.
Im SpartaDOS-Format springt man direkt in an die Stelle des Datensatzes innerhalb des DB-Files und liest oder schreibt. Und - ganz wichtig - wird das DB-File auf einen anderen Datenträger kopiert, muss man nichts ändern, egal wo er auf dem neuen Datenträger liegt.
Daher kann man mit einem DOS im SpartaDOS-Format sogar auf nackten 1050ern schneller in den Daten suchen als mit DOS2-Derivaten.

Moin Walter,

ah, ok, jetzt sehe ich, was Du meinst. Im Basic gibt es ja auch gar keinen Befehl, der wie SEEK sofort auf den x-ten Datensatz positionieren kann. Ich muss das bei Gelegenheit unter Kyan mal ausprobieren, was er macht, wenn man bei einer großen Datei per SEEK auf einen weit hinten liegenden Datensatz positioniert. Dann müsste es doch aber unter Sparta DOS auch einen zusätzlichen Befehl für das relative Positionieren geben, oder wird da NOTE und POINT "umfunktioniert"?

GoodByteXL hat geschrieben:]Ja, das ist in PASCAL komfortabel zu machen, aber NOTE und POINT arbeiten in DOS2-Derivaten ausschließlich sequentiell und orientieren sich an den physikalischen Sektoren auf dem Datenträger, was schön simpel aber für große Datenmengen unbrauchbar ist.

Also wenn ich mir mit NOTE eine Sektorposition in einer offenen Datei merke, kann ich doch danach per POINT wieder genau dahin springen, ohne erst die ganze Datei zu lesen, oder? D.h. NOTE und POINT arbeiten nicht sequentiell sondern ermöglichen den Direktzugriff. Dumm ist nur, dass sie eben mit absoluten Sektorpositionen arbeiten. Da kriegt man Probleme, wenn die Datei auf einer anderen Disk liegt, dann gelten ja die gemerkten absoluten Sektoren nicht mehr. Insofern hast Du aber recht, für eine gute Datenverwaltung ist dieser absolute Modus nicht gut geeignet. Was fehlt ist eben sowas wie SEEK und die Unterstützung durch das DOS dafür.

GoodByteXL hat geschrieben:Und da Kyan PASCAL, soweit ich weiß, nicht mit SDCS oder SDX arbeitet, ist es (leider) keine Alternative, obwohl mit PASCAL an sich schön zu programmieren ist.

Hmmm, ich hatte vor einiger Zeit hier im Forum mal gelesen, das jemand es unter SD 3.2 zum Laufen gebracht hat und es mit SDX 4.xx probieren wollte. Muss mal suchen...

Gruß und schönes WE,

Michael

Hi,

Rockford hat geschrieben:Gut, heisst für mich, dass ich mich erstmal auf die Homeversion konzentriere (800XL+1050er ohne upgrades + DOS2.5).

DOS 2.5 heißt dann ja auf jeden Fall, viele Datensätze in wenigen großen Dateien zu halten. Vielleicht wäre ein Test mit ein paar mehr Datensätzen mal aufschlussreich, wie schnell Suchen, Blättern etc. unter DOS 2.5 dann wirklich sind.

Die Entscheidung für das ein oder andere DOS wird, glaube ich, ziemlich wichtig und sollte gut überlegt werden. Davon hängt dann ja auch ab, wie z.B. auf Unterverzeichnisse zugegriffen wird. Die XIO-Befehle sind ja bei MyDOS leicht anders als bei BeWe- und SpartaDOS, d.h. das Programm ließe sich dann nicht einfach auf eine Disk mit einem anderen DOS kopieren. Es wäre Anpassungsarbeit erforderlich.

Aber wie gesagt, vielleicht erstmal die Homeversion testen und dann sieht man weiter.

Gruß,

Michael

mp-one hat geschrieben:Hi,

...
DOS 2.5 heißt dann ja auf jeden Fall, viele Datensätze in wenigen großen Dateien zu halten.

....

Stimmt, das betrifft ja vorallem die Texte. Die Datensätze werden ja auf jeden Fall in möglichst wenig Dateien sein.

Gruss, Holger