Entschuldigung, darf ich neugierig fragen, was denn eine REL Datei ist und was sie so besonders macht, dass man sie nicht wie andere Dateien behandeln kann?
Der COPY-Befehl lässt ja nur Kopien zwischen den beiden Laufwerken einer Einheit zu, weshalb das aus meiner Sicht schon mal flach fällt.
Du könntest die Datei auf der Diskette zum Lesen öffnen und auf dem petSD zum Schreiben öffnen. Dabei die Inhalte Byte für Byte auslesen und übertragen (wird wohl ewig dauern)
Oder
über Zusatzhardware (Zoomfloppy und entsprechender Software) und den PC ein Diskimage erzeugen
Edit: Eine Relative Datei bietet wahlfreien Zugriff auf die einzelnen Datensätze, ohne dass man das ganze File auslesen und durchsuchen müsste. Ich denke dem Threadersteller geht es weniger um die Art der Datei, sondern darum, dass die Datei nicht als Ganzes in den Arbeitsspeicher (Eine ganze Diskette) des 8032 passt und somit durch ein spezielles Kopierprogramm in Häppchen kopiert werden sollte.
Moin Ajax,
hast du die Längen Beschreibungen der einzelnen Felder ?
Oder ist die Länge der Felder in der Dateien unbekannt ?
Ist nicht auf der Demo-Diskette zur 8250 ein Kopierprogramm, welches in BASIC geschrieben wurde?
Das könnte man doch umpfriemeln, dass es von Unit zu Unit kopiert?
Ob die Lesepointer stimmen? Keine Ahnung! 
100 data 17,21,24,19,30,18,35,17,0,0 (Hier anpassen, da für die 1541 geschrieben und deshalb nur 35 tracks kopiert werden)
110 tr=1:se=0:sd=9:dd=8 (sd=source-disk--> 8250 und dd=destination disk--> petsd)
120 print"copying from drive ";sd;" to drive ";dd
130 read mt,ms
140 if mt=0 then print"finished":end
150 for tr=tr to mt
160 for se=0 to ms-1
170 print"track ";tr;", sector ";se
180 open1,sd,5,"#":open2,dd,5,"#":rem Puffer öffnen
190 open3,sd,15:open4,dd,15:rem Kommandokanäle öffnen
200 print#3,"u1:5 0 "+str$(tr)+str$(se):rem Sektor lesen
210 print#4,"b-p:5 0":rem Lesepointer zurücksetzen
220 print#3,"b-p:5 0"
230 for i=0 to 255:get#1,a$
240 if a$=""then a$=chr$(0):rem GET liefert keine Nullbytes
250 print#2,a$;:next i
260 print#4,"u2:5 0 "+str$(tr)+str$(se):rem Sektor schreiben
270 close4:close2:close1:close3
280 next se:next tr
290 goto 130Oder ist die Länge der Felder in der Dateien unbekannt ?
Ist die Länge der Felder nicht fix? Mir deuchte, so wäre meine Erinnerung.
Das umfriemel Programm ist gar nicht noetig.
Bei der .REL Datei muss nur auf Unit 8 geoeffnet werden
und dann gleich wieder auf Unit 9 geschrieben werden.
Das ist kein Problem.
Wenn man um die Feldlaengen weiss, gehts recht schnell.
Aber ein guter Anstatz das in das Kopier Programm einzubauen
und auch Moeglichkeiten mit einzubauen haendisch die Feldlaengen
anhand der Inhalte zu ermitteln und dann dann zu kopieren.
Oder ist die Länge der Felder in der Dateien unbekannt ?
Ist die Länge der Felder nicht fix? Mir deuchte, so wäre meine Erinnerung.
Jupp. Die ist Fix. nur wenn viele Daten drin stehen und keine Zusammenhaenge
erkennbar sind, ist es hilfreich zu wissen, welches Feld wie lang ist.
Feld 1 = 10 Zeichen
Feld 2 = 3 Zeichen
Feld 3 = 7 Zeichen
usw. usw.
Du könntest die Datei auf der Diskette zum Lesen öffnen und auf dem petSD zum Schreiben öffnen. Dabei die Inhalte Byte für Byte auslesen und übertragen (wird wohl ewig dauern)
Schau mal einer an... Schon sind wir uns einig.
Bei der .REL Datei muss nur auf Unit 8 geoeffnet werden
und dann gleich wieder auf Unit 9 geschrieben werden.
Das ist kein Problem.
CodeAlles anzeigen180 open1,sd,5,"#":open2,dd,5,"#":rem Puffer öffnen 190 open3,sd,15:open4,dd,15:rem Kommandokanäle öffnen 200 print#3,"u1:5 0 "+str$(tr)+str$(se):rem Sektor lesen 210 print#4,"b-p:5 0":rem Lesepointer zurücksetzen 220 print#3,"b-p:5 0" 230 for i=0 to 255:get#1,a$ 240 if a$=""then a$=chr$(0):rem GET liefert keine Nullbytes 250 print#2,a$;:next i 260 print#4,"u2:5 0 "+str$(tr)+str$(se):rem Sektor schreiben 270 close4:close2:close1:close3 280 next se:next tr 290 goto 130
Hi Eloy,
ich seh jetzt erst das im Quellcode von Unit zu Unit kopiert wird.
Wenn das so funktioniert waere das Supi und eine Loesung fuer Ajax.
Beim Bitweise kopieren hatte ich vor "kurzem" festgestellt, dass ein
BitWeises kopieren einer .prg Datei den Effekt hatte, dass es hinterher
keine Kennzeichnung mehr mir .prg im Directory gab.
Mit #diddl unter anderem hatten wir diesbezueglich bereits einen
Fred aufgemacht wo wir etwas darueber diskutiert hatten.
'Feldlängen' sind für die REL Datei nicht von Belang.
Es gibt in einer REL Datei nur eine feste Recordlänge, die beim Anlegen der Datei definiert werden muß.
Um eine REL Datei auf ein anderes Gerät zu kopieren, braucht man demnach die Recordlänge.
Blockweises kopieren einer REL Datei kann nicht funktionieren, weil dann die Side-Sectors nicht mitkopiert werden.
Es koennen aber nur 80 Zichen max. gelesen werden pro Input pro String.
Oder nicht ?
Wenn der Datensatz also laenger als 80 ist, waere es doch Sinnvoll zu wissn wie lang welcher Satz ist.
Oder nicht ?
Aus der Erinnerung, daher ohne Garantie:
INPUT# kann bis 255 Zeichen lesen. Die maximale Recordlänge der Floppy ist 254, das entspricht der 'Nutzlast' pro Sektor.
Ich aus der Praxis. Bei mehr als 80 Zeichen pro String gibts Aerger. Bei .REL
Wenn dem so ist, muß man die Zeichen einzeln mit GET# abholen.
Nicht einzeln.
Lesen mit Input.
Ich schau nachher mal in meinen Quellcode wenn ich
endlich diesen Sche...... HP Drucker installiert bekommen habe.
Grrrrrr
Gerade extra nochmal das Handbuch (8032) zur Hand genommen: Richtig, da steht auch drin, daß INPUT# maximal 80 Zeichen verarbeiten kann.
INPUT# dürfte auch fehlschlagen, sobald irgendwelche Binärdaten enthalten sind - CHR$(0) und sowas.
GET# dauert ewig.
Eigentlich hilft da nur eine kleine Assemblerroutine, die eine definierte Anzahl von Zeichen abholt.
Hatten wir nicht genau die gleiche Diskussion schonmal vor ein paar Monaten. Wollte da nicht jemand was schreiben?
Oder war das im Nachbarforum?
Gerade extra nochmal das Handbuch (8032) zur Hand genommen: Richtig, da steht auch drin, daß INPUT# maximal 80 Zeichen verarbeiten kann.
Das ist die Größe des Input-Buffers.
INPUT# dürfte auch fehlschlagen, sobald irgendwelche Binärdaten enthalten sind - CHR$(0) und sowas.
GET# dauert ewig.
Eigentlich hilft da nur eine kleine Assemblerroutine, die eine definierte Anzahl von Zeichen abholt.
Moin #detlef,
bei normalen Datenbank Anwendungen sollten keine 0 Zeichen enthalten sein,
so daß ein lesen <-> schreiben von U8 zu U9 recht schnell gehen sollte.
Ich glaube aber mal so ganz theoretisch, dass ein 0 Zeichen innerhalb der festgelegten
Zeichenkette durchaus mit uebertragen wird. Der input# Befehl
arbeitet ja doch etwas anders als der get# Befehl.
CHR$(0) ist für die Floppy die Ende-Markierung einer Zeichenkette. Unbenutze Zeichen am Ende eines Records werden mit CHR$(0) aufgefüllt.
Bei INPUT# wird CHR$(0) nie mit übertragen.
CHR$(0) ist für die Floppy die Ende-Markierung einer Zeichenkette. Unbenutze Zeichen am Ende eines Records werden mit CHR$(0) aufgefüllt.
Bei INPUT# wird CHR$(0) nie mit übertragen.
Eben das ist das Problem. Du kannst aber auch in REL-Dateien binäre Daten ablegen die 0-Bytes enthalten.
Die kann man nämlich mit PRINT# schreiben und mit GET# lesen.
Aber da es bei Satzgrößen > 80 Zeichen sowieso nicht klappt, hat sich INPUT# sowieso erledigt.
Aber wie unterscheidest Du die dann von den Füllzeichen am Recordende?
Das klappt nur, wenn Du weißt, wieviele Zeichen tatsächlich genutzt werden.
Naja, ich hab kein Problem mit input#
und funktioniert Supi. 80 zeichen pro Feld sind auch ausreichend fuer mich.
Wenns mit get#.....gut.
Ich bleib bei input# ( geht schneller ) 
Interessant waere, was Ajax nun dazu sagt. 
Aber wie unterscheidest Du die dann von den Füllzeichen am Recordende?
Das klappt nur, wenn Du weißt, wieviele Zeichen tatsächlich genutzt werden.
Bei Binärdaten muss man sich sowieso selber um den Inhalt kümmern. Da gibt es keine halbgefüllten Records.
Man liest immer jeden Record komplett.
Bei Binärdaten muss man sich sowieso selber um den Inhalt kümmern. Da gibt es keine halbgefüllten Records.
Man liest immer jeden Record komplett.
Also gehen doch chr$(0) Zeichen in dem "besagten/betagten" String ?! 
Bei Binärdaten muss man sich sowieso selber um den Inhalt kümmern. Da gibt es keine halbgefüllten Records.
Man liest immer jeden Record komplett.
Also gehen doch chr$(0) Zeichen in dem "besagten/betagten" String ?!
In der Regel werden in den REL-Dateien keine Binärdaten gespeichert sein. Also sollten die sich mit INPUT# lesen lassen, wenn die Recordgröße nicht größer als 80 Zeichen ist.
Aber sicherheitshalber sollten man sich die Daten mal vorher anschauen.
Nachdem der doofe HP Drucker ( Tolle HP Dru....) endlich installiert ist,
setz ich mich nachher mkal ran und fuelle ein Datenbank Feld mit chr$(0) Zeichen
und schaue mal was input# in der Praxis damit so anstellt........
Ich habe gerade nochmal ins Floppy-Handbuch geschaut. Ist halt schon so lange her.
Ne, INPUT wird nicht gehen, wenn du die Struktur der Records nicht kennst. Denn jeder Record kann ja mehrere Felder enthalten, die durch CHR$(13) getrennt sind und die einzeln mit INPUT gelesen werden müssen. Mit einem INPUT pro Record bekommt du immer nur das erste Feld.
Die einzige zuverlässige Methode für das Kopieren von REL-Dateien, deren Record-Struktur man nicht kennt, ist das vollständige Lesen und Schreiben jedes Records mit GET# (oder einer Assembler-Routine).
Wenn das eine einmalige Aktion ist, dann mach's halt mit GET und lass das Programm ein paar Stunden rödeln. 
