Nun, wie soll ich da anfangen...also, im ABBUC Magazin 93 schrieb Walter über den aktuellen Stand der PD Bibliothek und brachte auch die Idee auf, eine Datenbank auf dem Atari XL/XE selbst dafür als beste Lösung zu haben.
Irgendwie blieb ich an der Sache hängen und nach einigen Tagen schrieb ich Walter meine Ideen dazu. Als Nutzer der PD-Bibliothek hatte ich da irgendwie Interesse dran gefunden...

Eins kam zum anderen und schliesslich fing ich mit Rücksprache von Walter und nach Klärung diverser Grundbedingungen der Datenbank an, ein Programm in Turbobasic zu schreiben.
(Wir hatten uns, da das ganze ja für jeden offen zugänglich und auch erweiterbar sein sollte, für Turbobasic entschieden).
Nach mehreren Zwischenständen ist das Programm nun tatsächlich nutzbar und somit haben Walter und Ich beschlossen, damit mal "an die Öffentlichkeit" zu gehen.

Dieser Thread soll mehrere Funktionen haben:
1.Über den jeweils aktuellen Stand berichten.
2.Abbucianer zum testen des Programmes finden. Diese sollen dann Bugs und Verbesserungsideen hier posten, worüber ich dankbar wäre.
3.Leute zum mitmachen finden. Wie man, wenn man das Programm durchtestet, sieht, ist es nun doch schon ein wenig aufwändiger geworden. Trotzdem gibt es immer noch Dinge zu realisieren. Das das Programm nutzbar ist, heisst nicht, das es schon fertig ist.
4.Wichtig: Leute zu finden, die den Datenbestand einpflegen wollen. Interessenten sollten sich da mal an Walter (GoodbyteXL) wenden.

Hier habe ich das ATR mit Daten zum probieren auf meine Domain gestellt, einfach draufklicken und runterladen: http://www.gringo-comics.de/atari/abbuc-pd-dos25.atr

Was das Programm kann:



Wie auf dem Screenshot zu sehen, gibt es mittlerweile 10 Menüpunkte. Man kann unter anderem:
-Programme nach Titel oder Kategorie suchen, siehe Screenshot:


-Unterschiedliche Datenbankdateien auswählen
-PD-Disks suchen
-Eine Auswahl anlegen und speichern und später auch wieder laden



-Eine Bestellung ausdrucken
-Neue Daten eingeben
-Neue Datenbankdateien erstellen

-Es sind alle Kategorien der PD-Bibliothek integriert.
-Es gibt eine Datensatzansicht mit Infotext, falls vorhanden.




Die Daten:

Diese sind aufgegliedert. Es gibt Datenbankdateien, die lediglich die Hauptdaten der Programme enthalten. In jeder Datenbankdatei kann eine Menge von Daten enthalten sein, die lediglich begrenzt ist vom Medium, auf dem sie gespeichert ist. Dateiformat ist als Endung .DAT, entspricht aber einem reinen Textfile und kann in einem Editor bearbeitet werden.
Dann gibt es noch Programmbeschreibungsdateien. Diese enthalten immer einen Text zum jeweiligen Programm. Diese können eifach in einem Editor erstellt werden, z.B. habe ich dafür den Atarischreiber genutzt.
Durch diese Aufteilung von Haupt- und Nebeninfos konnte eine Menge Platz gespart werden.


Auf dem ATR sind schon ein paar Daten drauf, Standardmässig ist bei Start die Datei DATEN.DAT geladen. Diese sind mehr oder weniger sinnvoll, ich habe da Kategorien so vergeben, um z.B. Seitenwechsel simulieren zu können.

Momentane Verbesserungsideen:
(Wobei die mir wichtigsten Punkte mit einem * gekennzeichnet sind)

- Die Option, z.B. eine RAM-Disk oder einen zweiten (oder mehr) Drives zu nutzen.*

- Importfilter, um bereits bestehende Daten und Texte importieren zu können.-->Hier bräuchte ich die Info, welche Daten in welchen Formaten existieren. Bei komlizierteren Datenstrukturen und bei Portierungen zwischen PC- zu Atarifiles brauche ich da auch sicherlich Unterstützung von in diesem Gebiet erfahrenen Leuten.

-Die Kategorieauswahl flexibler gestalten. Auf und abwärts blättern soll dann möglich sein.* Dies ist auf jeden Fall der nächste Optimierungspunkt. Da verbirgt sich momentan auch noch eine Menge unnützer Programmcode, den ich in einer tiefen Nacht durch dumpfes Hin- und Herkopieren erstellt habe ....

Momentane Bugs:

- Es ist möglich, im Datenbankauswahlmenü durch <Enter> eine nicht vorhandene Datei auszuwählen, auch kann ein nicht vorhandener Name eingegeben werden. Dies führt nicht zum Programmabbruch, es wird halt nix gefunden.

Hinweise:
Das Programm ist noch offen, d.h. es kann jederzeit durch drücken der BREAK-Taste abgebrochen werden. Bitte beachtet dies, wenn ihr zur Fehlersuche in einem Untermenü abbrecht. Bei erneutem Run könnten, wenn kein Reset gemacht wurde, seltsame Dinge aufgrund eines noch offenen Kanals geschehen.
Das Programm selbst hat kaum REM Zeilen als Kommentar. Wer sich beteiligen und Code erstellen will, dem schicke ich gerne eine Auflistung der einzelnen Unterprogramme mit Zeilennummern und eine Variablenliste.

So, nun hoffe ich, das der ein oder andere mal reinschaut und sich vielleicht auch wie ich berufen fühlt, die PD-Bibliothek zu unterstützen.

Gruss, Holger (Rockford)

Hallo,
also zum testen des A8 Programms wäre ich gerne bereit ! Allerdings sollte die Liste der Abbuc-PD`s (und die Infos / Daten dazu) nur von Walter, von dir und zuvor festgelegten Leuten angelegt werden und nicht jeder nach belieben daran rumpfrimeln können...

Nunja, für jene Abbucianer, die kein Internet und/oder keinen PC haben ist das A8 Programm in TB XL sicherlich von Vorteil. Allerdings würde ich dennoch zwei- oder mehrgleisig fahren und auch zusätzlich ein PC / Mac Programm oder wenigstens die Daten in einem PC / Mac lesbaren Format anbieten. Als erstes fiel mir da Excel und Konsorten ein, aber das ist ja eine Tabellenkalkulation, könnte man aber auch als Datenbank missbrauchen. Soweit ich mich erinnere gab es auf dem A8 mal ein Datenaustauschformat namens *.DIF, bin mir aber nicht mehr sicher, ob dies allein von Tabellenkalkulationen (Visicalc, Syncalc) oder auch Datenbanken genutzt wurde - und inwieweit es das heute noch auf dem PC (oder anderen Rechnern) gibt...

Naja,wie auch immer, gut wäre es, wenn die Daten der Abbuc-PD Bib. sowohl auf dem A8 als auch auf dem PC / Mac ohne größere Umstände (und ohne einen A8 Emu oder einen Konverter nutzen zu müssen) nutzbar wären... nur so ein paar Gedanken... -Andreas Koch.

Hallo Andreas,

Die Liste der ABBUC-PDs obliegt natürlich Walter, er hat ja in der letzten Zeit schon einiges gemacht.
Wer also Datenbestände einpflegen will, muss sich logischerweise an bestimmte Vorgaben halten, was unter anderem auch die Benummerung der einzelnen Programme und der Infotexte dazu betrifft.

DIF: Gibt es nach wie vor, habe gerade mal in OpenOffice nachgesehen, wird unterstützt. Wär natürlich ne gute Sache, CSV wäre da auch eine Möglichkeit. Walter hat diesen Gedanken auch schon gehabt, weswegen ich das Thema Importfilter auch schon bei den Verbesserungsideen aufgenommen habe.

Wenn Du das Programm mal testen willst (Was mich freuen würde), kannst Du Dir oben im Thread das ATR einfach mal runterladen. Da ist alles drauf. Vorher solltest du noch Turbobasic laden. Das eigentliche Programm heisst dann PDREADER.TUR.

Gruss, Holger

Ach So:
Dadurch, das das Programm in TB XL ist und somit leicht auch abzuändern, kann es sehr leicht für eine Datenbank der eigenen Programme genutzt werden, wenn man das nicht schon hat. Für mich war das auch ein Grund, das ganze anzugehen.

Hi zusammen!

Die Übernahme der Daten ginge am einfachsten aus CSV, da ich die PDs in dem Format für die Webseite aufbereitet hatte und neue einfach dazu füge.

Knackpunkt ist das Trennen von Disks und Programm. Bei 750 PDs mit durchschnittlich 4-5 Programmen keine schnelle Arbeit ...

Hallo Walter,

ich müsste mal sehen, wie die CSV Datei aussieht. Kannst Du mir da mal was schicken? So ein paar Einträge reichen da erstmal.

Vielleicht kann man die Daten ja in einer Tabellenkalkulation aufbereiten und da z.B. die Programmnummer, die es bis jetzt nicht gibt, aber zukünftig für sinnvolles suchen nötig ist, hinzufügen.

Die Beschreibungstexte wären noch wichtiger zum übernehmen als die Grunddaten. Die Grunddaten sind doch recht fix einzugeben.

Gruss, Holger

Hi,

für CSV Dateien gibt es einen Internet-Standard (RFC4180), dort steht drin beschrieben wie ein CSV aufgebaut sein sollte.

http://www.rfc-editor.org/rfc/rfc4180.txt

Ciao

Carsten

Data Interchange Format (DIF) ist in Wikipedia beschrieben -> http://en.wikipedia.org/wiki/Data_Interchange_Format

@cas:

Danke für die Infos.
Wenn ich die CSV-Daten von Walter habe, geht's da weiter.

Letztenendes muss ich das vom Aufbau her in eine vom PDREADER lesbare Fassung bekommen, dann werde ich es mal mit Dir2Atr in ein ATR packen und schauen, ob's dann auch verwertbar ist.

Wenn's einfacher wird, schreibe ich auch das Datenhandling im PDREADER um, pro Datensatz gibt's ja nur 5 Felder.

Gruss, Holger

Moijn zusammen!

DIF als Format wäre mir auch lieber gewesen. Ich hatte anfangs (so vor 10 Jahren ...) damit und VisiCalc und SynCalc experimentiert.

Außerdem hatte ich damals Verbindung mit Dan Bricklin aufgenommen, der VisiCalc entwickelt hatte. Wegen mir nicht verständlicher "Probleme" konnte ich keine PD-Freigabe der ATARI-Version erreichen, obwohl ich ihm wie gefordert einen Emulator für PC und die ATR-Version meines Originals geschickt hatte.

Damit war die PD-Datenbank auf ATARI wieder in weite Ferne gerückt. Doch jetzt hat sich Holger der Sache angenommen und schreibt eine in TurboBASIC XL. Finde ich super!

Ich hoffe ja, das sich noch mehr TBS-Programmierer einklinken.

Holger, die CSV-Datei kommt per E-Mail.

CharlieChaplin hat geschrieben:Hallo,
also zum testen des A8 Programms wäre ich gerne bereit ! Allerdings sollte die Liste der Abbuc-PD`s (und die Infos / Daten dazu) nur von Walter, von dir und zuvor festgelegten Leuten angelegt werden und nicht jeder nach belieben daran rumpfrimeln können...

Nunja, für jene Abbucianer, die kein Internet und/oder keinen PC haben ist das A8 Programm in TB XL sicherlich von Vorteil. Allerdings würde ich dennoch zwei- oder mehrgleisig fahren und auch zusätzlich ein PC / Mac Programm oder wenigstens die Daten in einem PC / Mac lesbaren Format anbieten. Als erstes fiel mir da Excel und Konsorten ein, aber das ist ja eine Tabellenkalkulation, könnte man aber auch als Datenbank missbrauchen. Soweit ich mich erinnere gab es auf dem A8 mal ein Datenaustauschformat namens *.DIF, bin mir aber nicht mehr sicher, ob dies allein von Tabellenkalkulationen (Visicalc, Syncalc) oder auch Datenbanken genutzt wurde - und inwieweit es das heute noch auf dem PC (oder anderen Rechnern) gibt...

Naja,wie auch immer, gut wäre es, wenn die Daten der Abbuc-PD Bib. sowohl auf dem A8 als auch auf dem PC / Mac ohne größere Umstände (und ohne einen A8 Emu oder einen Konverter nutzen zu müssen) nutzbar wären... nur so ein paar Gedanken... -Andreas Koch.

Hey Andreas!

Waren wir beide an diesem Punkt nicht schon einmal vor ein paar Jahren?
Für eine Datenbank auf dem A8 bin ich bereit, ein paar Tausend Programme in einem speziellen Format zu katalogisieren. Inzwischen ist klar, dass auch mit CSV nix zu reissen ist, weil es immer noch so viel Tipparbeit erfordert, dass man schneller und einfacher gleich alles neu tippen kann.

Für Emus und PCs, MACs, etc. etwas aufzuarbeiten habe ich (noch) immer absolut kein Interesse, weil dafür die PD-Liste so wie sie ist völlig ausreicht. Man muss sie nur halt lesen ...
Für die Sammler mit One-Click auf PC etc. tippe ich keinen einzigen Anschlag, da sie weder dem Club noch der Szene etwas nützen.

Aber falls jemand sich an der Aufarbeitung der Programmbeschreibungen etc. für die von Holger initiierte Datenbank auf dem XL/XE aktiv beteiligen möchte, immer gerne.

Hallo!

Wieder zurück aus dem sonnigen Berlin poste ich nun auch mal meinen aktuellen Stand zur CSV Sache:

Das Problem sind die unterschiedlichen Feldtypen (Sprich Variablen und Stringvariablen), die ich in der Datenbank am A8 bestimmt habe. Mit der CSV erhält man aben alles kommasepariert und damit geht beim einlesen von z.B. Text$ schon mal einiges schief. Die Lösung wäre dann als Komplettstring einlesen, auseinanderfieseln und ggfls. von Stringvariable in Zahlvariable umwandeln. Dann fehlen da aber noch bestimmte Datenbankfelder , die ich aufgrund Speicherersparnis auf dem A8 angelegt habe. Der Hauptstolperstein ist die Katalogisierung auf Programm- anstatt auf Diskbasis. Nur so lassen sich Suchroutinen vernünftig nutzen und sind auch zeitmässig flott. Zudem verringert sich der Speicherplatz für Daten auf Disketten hiermit nicht unbeträchtlich.

Also:
Neu eintippen zumindest der Kopfdaten scheint auch mir momentan der sinnvollste Weg zu sein.
Texte kann man auch rüberbringen, muss diese aber ggfls. auseinander nehmen.
Ich persönlich favorisiere, wenn ich Programme für den A8 suche, natürlich eine Lösung, die auch auf dem A8 läuft.
(Sonst hätte ich das Programm ja nicht erstellt...)

PC oder MAC usw. ist ja schön und gut, aber man hat dann schon wieder 2 Rechner am laufen. Und wie Walter schon geschrieben hat: Für diese User ist die momentane Lösung schon recht gut.

Gruss, Holger

Rockford hat geschrieben:... Also: Neu eintippen zumindest der Kopfdaten scheint auch mir momentan der sinnvollste Weg zu sein.
Texte kann man auch rüberbringen, muss diese aber ggfls. auseinander nehmen.

Habe nach einigen Testen keine andere sinnvolle Lösung als neu eintippen gefunden. Vor allem bei Samplern bleibt nach der manuellen "Zerpflückung" oft nicht viel mehr als die Bezeichnung des Programms stehen. Kein sehr sinnvoller Hinweis auf die Funktion, den Inhalt, etc., wenn aus dem Sampler herausgenommen und als einzelnes Programm betrachtet.
Deswegen bastele ich auch an einer mobilen XL-Lösung für's Wohnmobil ...

Rockford hat geschrieben:Ich persönlich favorisiere, wenn ich Programme für den A8 suche, natürlich eine Lösung, die auch auf dem A8 läuft.
(Sonst hätte ich das Programm ja nicht erstellt...)

So isses !!!

Rockford hat geschrieben:...damit geht beim einlesen von z.B. Text$ schon mal einiges schief.

Warum? Wird ein Textbegrenzungszeichen erwartet?
So was läßt sich doch recht schnell ergänzen.

Vielleicht verstehe ich auch das Problem nicht.
Wäre es nicht das Einfachste, ein/zwei Datensätze zu posten wie sie aussehen und wie sie aussehen sollten für den DB-Import.
(oder gar das csv anzuhängen)

Wenn alles nichts hilft, kann man vllt. ein "verteiltes Erfassen" organisieren

Hallo,

@GoodByteXL: mit welchem Programm (Textverarbeitung, Tabellenkalkulation, Datenbank ...) verwaltest Du denn die PD-Liste und welche Struktur (Felder, Typen) hat diese, woran sich ein Import in die A8-DB orientieren könnte? Falls es reiner Text ist, könnte man auch eine Art Marker-Symbol vor jeden Programmnamen setzen, der dann von der A8-Anwendung zum Trennen der Namen genutzt werden kann.

[EDIT]: Habe gerade gesehen, dass die Liste (PDF) oft ja schon ein relativ markantes Format aufweist.

1. Zeile: DiskNr Name Optionen Anzahl Disks/Formate
2..n Zeile: Programm 1: Beschreibung 1 ... Programm n Beschreibung n

Wobei sehr hilfreich ist, dass die Programmnamen fast immer in fett geschrieben sind und mit einem Doppelpunkt enden. Hier gibt es einige Ansatzpunkte zum parsen.

[/EDIT]


@Rockford: Welche Felder und Typen hat denn Deine DB genau? Vielleicht kann man wenigstens eine Teilzuordnung durchführen, um sich etwas Arbeit zu sparen.

DB-Liste Feld x ---> A8-Liste Feld y
...
...

@eda, GoodByteXL:

Wäre es nicht das Einfachste, ein/zwei Datensätze zu posten wie sie aussehen und wie sie aussehen sollten für den DB-Import.

Genau, postet doch mal so einen Datensatz im CSV-Format.

Weiterhin muss ggf. auch die Umlautkonvertierung vom PC auf den ATARI beachtet werden, falls die PD-Liste momentan auf dem PC verwaltet wird. Vielleicht kann ich Euch durch die Erfahrungen, die ich über die Jahre beim PiXLator in diesem Bereich gesammelt habe, weiter helfen.

Gruß,

Michael

@eda70 und mp-one:

Prima, dass ihr euch die Sache mal anschauen wollt. Vielleicht fällt euch ein praktikabler Weg ein.

Hier also ein Beispieldatensatz, wie er in der PDREADER Datenbank aussieht (Dahinter als Kommentar der Feldname und Zweck):

Code: Alles auswählen



11101                 ;PDN - Programmnummer
Printmaster         ;A$ - Programmname
111                     ;N - Disknummer
27                       ;GNR - Genrenummer
1                         ;XL - Systemanforderungen
D11101               ;DAT$ - Beschreibungsdateiverweis



Kurze Erklärung:
PDN ist immer Die Disknummer und 2 Zeichen für die Programmnummer auf der Disk. Somit ergibt sich eine globale Zählnummer, die eindeutig ist. Format: Zahl

A$ ist der Programmname, kann also auch Sonderzeichen und Komma oder Punkt enthalten. Format: Text

N ist die Disknummer. Format: Zahl

GNR ist die Genrenummer. Alle Genres sind fest im PDREADER hinterlegt. Dies spart extrem Platz. Die Genres entsprechen den vor einiger Zeit vorgeschlagenen von Walter. Format: Zahl

XL Systemanforderungen, womit Speicher gemeint ist. Es gibt hier 1-3. Format: Zahl

DAT$ ist der Name der Beschreibungsdatei. Dies ist optional und kann auch entfallen, dann muss an dieser Stelle wenigstens ein Füllzeichen (Beliebig) stehen. Ein weiterer Vorteil ist, dass verschiedene Programme und Utilities identische Texte haben, so z.B. Fonts oder Bilder für den Printshop. Da wird auch Platz gespart.Format: Text

Hier nun zwei Datensätze aus der csv-Datei, die es zu portieren gilt:

"0001","Spiele 1","G",,"SD/1S","Egon: Streiche ein Haus an und hüte dich vor den Geistern! Crazy Gats: Finde durch die Drehtüren zum Wasserhahn! Blockade: Erreiche den unteren Spielfeldrand? Epsilon: Suche die Schlüssel in den unterirdischen Gewölben! Goldrush: Sprenge den Weg zu den Goldmünzen frei! Saucer Launch: Verteidige die Erde vom Steuerpult aus! 17 und 4: Ein Kartenspiel."
"0002","Spiele 2","G",,"ED/1S","Knight Battle: Schätzen Wind und Ladung ein, um die Burg zu treffen! Sternenfestung: Schütze das Sternensystem vor den Frogs! Taucher: Berge alle Schätze aus dem Unterwasserlabyrinth! Vier gewinnt: Ein Denkspiel. Juwel Eater: Bringe alle Juwelen zum Ausgang! Minigolf: Partie über 14 Löcher."

Hier die Reihenfolge:
Disknummer, Diskname, Kategorie, Systemanforderungen, Diskart, Text

Prinzipielle Probleme dieser Struktur sind:
-Aufteilung nach Disk und nicht nach Programm. Dies macht leider ein gezieltes Suchen recht aufwändig und auch langsam.
-Es sind immer unterschiedliche Genres auf einer Disk, somit ist eine feine Genresortierung kaum noch möglich. Bsp: Wer Adventures sucht, bekommt mit der neuen Aufteilung auch nur diese gezeigt. Unter der alten Aufteilung ist aufgrund der Sammeldisks nur eine Suche nach Spielen allgemein möglich.

Will man zumindest einen Teil portieren, muss man die Daten umstellen, z.B. in Excel oder Open Office. Dann müsste man für jedes Programm eine Zeile hinzufügen und fortlaufend per Mausclick und ziehen durchnummerieren.
Direkt verwendbare Felder:
Disknummer, eventuell Disktyp (Dieser wird im PDREADER noch kommen, aus Platzgründen ist aber eine Kennzahl wohl sinnvoller, ähnlich wie bei dem Feld XL).

Zumindest als Feld zu nutzen:
Diskname, wäre dann Programmname
Systemanforderungen, wäre mit Kennzahl 1-3 zu füllen.
Textart, wäre dann der Beschreibungsdateiverweis.

Dann müsste beim portieren das Kommatrennzeichen noch einem Zeilenumbruch weichen, das ist aber das kleinste Problem.

Man sieht: Es bleibt vom ursprünglichen nicht viel übrig.

Die Ziele der PDREADER Datensatzstruktur waren für mich: Kompakt, damit viele Datensätze auf eine Disk/ ein ATR passen, zudem sollen Suchvorgänge flott abgearbeitet werden. Somit ist diese kurze, etwas kryptische Struktur entstanden. Wenn man die Struktur weiss, kann diese aber sehr einfach auch mit einem Editor, z.B. Atari Schreiber bearbeiten oder auch erstellen.
Durch die Struktur kann man nun auch längere Texte pro Programm sinnvoll hinterlegen. Momentan habe ich mal 14x38 Zeichen vorgehalten, könnte aber durch Seitenumbruch auch länger sein, kein Problem. Da wäre halt ein Steuerzeichen nötig.

Hinweis:
Wichtig ist zu wisssen, dass wir viele Mitglieder haben, die die Errungenschaften wie SIO2PC, SIO2SD oder gar SIO2USB nicht nutzen, also von einem PDREADER auf Diskette profitieren würden. Viele sind ja auch nicht hier im Forum aktiv, vergesst das bitte nicht.


Gruss, Holger

Rockford hat geschrieben:...Datensätze aus der csv-Datei, die es zu portieren gilt:

"0001","Spiele 1","G",,"SD/1S","Egon: Streiche ein Haus an und hüte dich vor den Geistern! Crazy Gats: Finde durch die Drehtüren zum Wasserhahn! Blockade: Erreiche den unteren Spielfeldrand? Epsilon: Suche die Schlüssel in den unterirdischen Gewölben! Goldrush: Sprenge den Weg zu den Goldmünzen frei! Saucer Launch: Verteidige die Erde vom Steuerpult aus! 17 und 4: Ein Kartenspiel."

Für alle denen das nicht klar sein sollte: Die PD-Liste ist im Original TEXT !!! Steinalt, weil fast so alt wie der ABBUC. Den Text hatte ich in mühseliger Handarbeit auf das für die Webseite geforderte CSV-Format gebracht. So ergibt sich das, was Holger hier als zu übernehmende Daten zeigt.

... Hier die Reihenfolge:
Disknummer, Diskname, Kategorie, Systemanforderungen, Diskart, Text ...

Wobei im letzteren die Masse der Arbeit stecken wird, da die Beschreibungen z.T. neu geschrieben werden müssen.

Will man zumindest einen Teil portieren, muss man die Daten umstellen, ...

Das Umstellen der Struktur in einer PC-basierten Datenbank macht IMHO genau so viel Tipparbeit wie die direkte Eingabe auf dem XL. Nur anschließend müsste man die Daten 'rüberziehen und noch einmal prüfen und ggf. korrigieren. Von daher wollte ich gleich den direkten Ansatz nehmen und den Rest sparen.

Hi Walter,

Für alle denen das nicht klar sein sollte: Die PD-Liste ist im Original TEXT !!! Steinalt, weil fast so alt wie der ABBUC. Den Text hatte ich in mühseliger Handarbeit auf das für die Webseite geforderte CSV-Format gebracht. So ergibt sich das, was Holger hier als zu übernehmende Daten zeigt.

jau, Text erleichtert es nicht gerade. Sind die Liste im Web und die PDF-Liste auf dem gleichen Stand was die Formatierung betrifft? Wie gesagt, in der PDF-Liste gibt es durchaus Strukturen, die man zum Auslesen verwenden könnte: Programmnamen sind fett und enden mit Doppelpunkt. Beschreibungen enden mit Punkt. Wenn das für das CSV-File genauso gilt, hätte man einen Ansatzpunkt.

Gruß,

Michael

mp-one hat geschrieben:jau, Text erleichtert es nicht gerade. Sind die Liste im Web und die PDF-Liste auf dem gleichen Stand was die Formatierung betrifft? ... Wenn das für das CSV-File genauso gilt, hätte man einen Ansatzpunkt.Michael

Moijn Michael, schau mal bitte die ganze PD-Liste durch, dann siehst du, warum ich lieber gleich auf dem XL tippen will.

Der Ursprung des PDF-Files ist eine normale Textdatei, die ich aber parallel auch in ODS habe. Daher ist der schnelle Export nach CSV kein Thema, oder jedes andere Format.

Es gibt viele Daten, die kann man direkt übernehmen, z.B. Disk # 0308,
oder mit minimaler manueller Anpassung übernehmen, z.B. Disk # 0730.
Es gibt viele Daten, die müssen von Hand geändert werden, z.B. alle Sampler-Disks wie Disk # 0001. Wobei eine bessere Beschreibung für die einzelne Spiele völlig fehlt, also geschrieben werden muss.
Es gibt eine Menge Daten, die müssen erst überprüft bzw. erstellt werden, weil es bisher nicht geschah. Die Disk # 0098 und vergleichbare gehören dazu.
Es ist leider keine einfache Sortier- und Konvertieraufgabe. Zusätzlich muss ergänzt, korrigiert, entfehlert und z.T. erst einmal geschrieben werden.

Aber es rollt ...

GoodByteXL hat geschrieben:
Aber es rollt ...

Heisst das, Du pflegst gerade schon Daten ein?

Gruss, Holger

Hallo Walter und Holger,

ich habe mal eine Stunde in eine "quick-and-dirty" Routine mit Pascal unter Delphi investiert. Das Auslesen der Disks 0001 und 0002 ("Sampler") klappt schon ganz gut. Ein Programmname wird immer am ":" erkannt, das Ende der Beschreibung dann an ".", "!" oder "?". Die DB ist momentan in Access gemacht und könnte dann leicht nach Excel und CSV konvertiert werden, um sie in den ATARI zu bekommen.

Sicherlich gibt es noch diverse Sonderfälle, sodass eine richtige Lösung dann deutlich mehr Arbeit erfordern wird. Prinzipiell ginge es aber wohl und ich vermute, man wird einen guten Teil automatisch konvertieren können. Dass man trotzdem noch einiges manuell nachpflegen muss, z.B. die Genres je Programm bei Disketten mit gemischtem Inhalt, ist natürlich klar.

Sagt mir bitte bescheid, wenn ich diesen Weg weiter verfolgen soll oder es für Dich/Euch doch besser ist, die Sachen per Hand zu tippen (falls Walter schon sehr viel gemacht hat...). Ist wie gesagt nur ein Angebot.

Ihr könnt mir ja so oder so testweise mal die komplette CSV-Datei schicken, ich sehe dann ja, wo es hakt und wie realistisch der Ansatz für die gesamte Liste ist.



Gruß,

Michael