Posts by Stephan Scheuer

Also der Bug ist bekannt. Ich frage beim Laden immer das Statusbyte ab., um Ladefehler aufzudecken.

Naja, ich dacht, du beschäftigst dich eher mit der Hardware. Also mit TTL-ICs, CPUs, Widerständen, Kondensatoren usw. Deshalb meine annahme.

Ich hatte früher immer das siebente Bit gesucht. Leider wusste ich nicht, dass man bei Bit 0 anfängt zu zählen. Das waren noch Zeiten.

Ich hätte den Sachverhalt gleich so schreiben sollen, wie es ist.

Datebytes = 251 + letzten Sektor = $00,$FF. Die Ladeadresse $00,$30. usw. und pp.

Naja, irgendwas ist ja immer.

Ist das nun ein Bug, oder einfach eine Marotte des Laufwerkscode?

Das stand aber auch alles im dokumentierten Quellcode, den ich mit hochgeladen hatte.

Das man in einem Sektor keine $256 Datenbytes ablegen kann, und die auch noch auslesen möchte, ist doch klar. Warscheinlich hatte ich den Eindruck hinterlassen, als wenn es so wäre.

Einstein sagte mal, wenn man immer das Gleich macht, aber jedesmal ein anderes Ergebniss erwartet, ist man irre.

Ist ja so wie bei einer CSI-Sendung. Da werden verpixelte und grobkörnige Bilder in Handumdrehen super-scharf.

Oh ja, Kinzi hat die Erleuchtung. Du hast warscheinlich nicht bei $0 zu zählen angefangen, sondern ab $1, also Byte 0 wäre dann Byte 1.

In Hexadezimal beginnt anders, als in Dezimal, dass Zählen bei $0

Du, das ist doch OK, wenn man zugibt, dass man falsch lag. Es ist noch kein Meister vom Himmel gefallen. Das kann nicht jeder, wie z.B. meine Frau.

Die hatte sich letztes mit ihrer Nachbarin unterhalten/gestritten. Zum Schluss hatte sie die ganze Nachbarschafft unterhalten/zugebrüllt. Das war peinlich.

Ach ja, ich habe das Internet nach diesem Fehler durchsucht. Aber überhaupt nüscht gefunden. Seltsam, aber so steht es geschrieben.

PS: Die Diskusion eben, erinnerte mich ein wenig an den Mondlandungverschwörer, der hier vor Jahren mal seine Ansichten gepostet/verbreitet hatte.

Das Echo, auf dass er traf, war grandios. Jedoch nicht für ihn. Ich hatte nicht die Muße, an dem Tag meinen Senf dazu abzusondern.

Davon rede ich doch die ganze Zeit, von dem belegten Sektor, ohne Verbindung, und welche Unstände zum Tragen kommen müssen, damit das Ereignis eintritt.

Ich glaube, ich muss mal an einem Rhetorik-Seminar, an der Volkshochschule Teilnehmen.

Deshalb habe ich auch im SCPU-Filemaker eine kleine Routine eingebaut, die ermittelt, wann es dazu kommt. Dann wird nach dem Speichern ein Validate ausgeführt.

Der Bug ist nicht schlimm, sondern nur lästig. Deshalb hatte ich ja auch die Frage gestellt, weil ich zuerst dachte, dass in meinem Code ein Bug enthalten ist.

Das hat sich aber immer mehr, als unwahrscheinlich herausgestellt. Jetzt, wo bei dir auch zwei Blöcke abhanden gekommen sind, war alles klar. Das ist ein Bug im Floppy-ROM

Mit der Action Replay Fastsave-Routine passiert das übrigens nicht.

Und was ergeben 1+1+2+2+2+2+652?

Das sind 662 Blocks. Wo sind die 2 Blocks geblieben?

Du kannst ja mal das Image, mittels Dirmaster->BAM ansehen.

Das hatte ich mir schon gedacht. Ich hatte alle Bytes zusammengerechnet. Also $00,$FF,$00,$30.

Ich dachte, das wäre klar. Das man 256 Datenbytes nicht in einem Sektor speichen kann, und das aufgrund der zweii Bytes $00,$FF oder auch 4 Bytes $00 $FF $00 $30, ist mir bekannt.

Ich dachte du wüstest, dass ich das schon lange weiß.

Naja, nun sind alle unklarheiten geklärt.

PS: Das Action Replay speichert immer die Ladeadresse als Byte 2 und Byte 3 ab. Den SMON hatte ich vor c.a. 35 Jahren benutzt.

Dateiende ist Byte 0 im letzten zu lesenden Sektor. Danach kommt Byte 1, dass auskunft gibt. wieviele Bytes noch zu laden sind.

Wenn du nun ab z.B. von $3000 bis $307F eine Datei abspeicherts, ist auch die Ladeadresse, als Byte 2 und Byte 3 vorhanden.

Teste es doch mal mit dem Action Replay. Bitte vorher den Fastsaver mit off deaktivieren, weil diese eigene Routinen im Floppy-RAM nutzt.

Kann es sein, das wir aneinander vorbei reden? Ich speichere keine $256 Bytes, sondern 251 Bytes.

Die Saveroutine speichert $FB Bytes ab. Dazu kommen dann noch die File-End-Bytes $00,$FF und die Ladeadresse $00,$30.

Das macht zusammen $FF Bytes.

Im übrigen tritt der Fehler auch auf, wenn man mittels Action Replay Monitor eine File abspeichert.

Leere Disk in das Laufwerk einlegen.

Falstloader mit off deaktivieren.

Jetzt den kleinen Text im Monitor eintippen und Enter drücken.

s"10",8,3000,30fc

----------------------

0 " " 2a

1 "10" prg

662 blocks free.

OK, alles klar, ich habe versanden.

Wenn es ein Programmfehler ist, wo liegt der Fehler, und warum schreibt die Saveroutine dann $00,$FF ?

Du kannst in Zeile 40 die Zahl 255 -> $FF

duch $254 -> $FE ersetzen. Programm starten.

Nun mittels Action Replay Monitor die Adresse

$2000 aufrufen, und ansehen. Dann wirst du

feststellen, dass Byte $FF nicht eingelesen wurde.

10 sa=8192

20 open 2,8,2,"#"

30 open 15,8,15,"u1 2 0 18 0"

40 for i=0 to 255

50 get#2,a$:if a$="" then a$=chr$(0)

60 poke sa,asc(a$):sa=sa+1

70 next i

80 close 15:close 2

Aber egal, lasen wir das Thema. Vielleicht ist es doch ein Fehler im FloppyDos.

Du irrst dich. Wie willst du das letzte Byte auslesen? Und warum schreiben die Laufwerke $00,$FF

Im übrigen würden alle Laufwerke, die ich besitze, murks veranstallten. Das machen sie aber nicht.

Also, ein Sektor, auch der letzte Sektor, kann 256 Daten-Bytes aufnehmen.

Byte $00 und Byte $01, sind keine Datenbytes. Sie dienen dem Laufwerk, den letzten Sektor zu erkennen, und die Anzahl der noch zu lesen Bytes zu ermitteln. Aus diesem Grund gibt es auch

keinen Track $00. Wenn jetzt das letzte Byte im Sektor gelesen werden soll, muss $00 für letzter zu lesender Sektor, und $FF für ganzen Sektor einlesen, stehen. Wie gesagt, die ersten zwei Bytes

auf jedem Sektors sind, entweder der Link zum nächsten Sektor, oder das Ende der Datei ist erreicht. Möchte man die ersten zwei Bytes auch als Datenspeicher nutzen, muss man eine Custom-

Laderoutine coden. Diese wird auch 256-Byte Sektor-Trackloader genannt. abder das ist eine andere Geschichte.

Ich habe eben mit dem Testprogramm einen Sektor erstellt, und natürlich auch den anschlusslosen, in der BAM belegten Sektor. Byte $00 und Byte $01 -> $00,$FF -> Das sind keine Datenbytes.

Wenn die Floppy das letzte Byte in dem Sektor lesen möchtest, muss Byte $01 ein $FF sein, weil das letzte Byte sonst unerreichbar wäre.

Siehe Bild, denn ein Bild sagt mehr als 1000 Worte.

Ich weiß. Da kommt zuerst das Byte $00, für den letzten Sektor. Danach die Anzahl der Bytes im letzten Sektor, Was bei dem Testprogramm $FF war.

Was ich wissen wollte, ist, warum wird noch ein leerer, nicht verketteter Sektor in der BAM belegt. Das Problem trat zuerst bei dem SuperCPU-Datei-Linker, mit der 1581 auf.

Ich am Bug-Suchen, die Laderoutine durch diverse andere, u.a. von der Code-Base ersetzt. Immer das gleiche Problem. Es wird ein Sektor, der nicht genutzt wird, belegt.

Danach JiffyDOS deaktiviert und CBM-DOS aktiviert. Das Problem bleibt. Nunja, ich habe es schließlich herausgefunden, und es tritt sehr selten auf.

Ich ermittle beim SCPU-Dateilinker, ob der letzte Sektor $00 $FF aufweist. Falls ja, wird nach dem Speichen ein Validate ausgeführt.

.....Auf einen Sektor passen aber nur 254......

Das sind auch 254 Bytes. Plus die zwei Anfangsbytes, $00 $FF, die das Laufwerk aufträgt. Wenn dem nicht so wäre, hätte das Laufwerk auch kein $00,$FF

vermerkt, sondern die Sektorverkettung zum nachten Sektor geleitet, also der in der BAM als belegt gekennzeichnete Sektor, gelle.

Das ist natürlich eine sehr gute Idee. Ich komme mal darauf zurück, wenn es soweit ist. Ich wollte mir auch schon Oropax in den Gehörgängen schieben, aber das lasse ich besser sein,

sonst hängt der Haussegen wieder sehr schräg, nach unten. Daran habe ich wirklich kein Interesse, das muss nicht sein.

Hier mal, für deine Arbeit, eine kleine Aufmerksamkeit von mir. Sechs NUFLI-Bilder, wie ich mir Windows an C64 vorstelle.

Ich denke mal, dass es vielleicht ein wenig zuviel des Guten ist, was man auf den Pics sehen kann.

Ich bin beeindruckt, und sitze schon geschlagene 3 Stunden vor dem Rechner. Meine Frau motzt auch schon: Nörgel, nörgel, mecker, määäähh. Richtig klasse gemacht, das Game.

Quote from kinzi

Das kann ich mir nicht vorstellen.

Ich kann mir sogar Vorstellen, was ich mir nicht vorstellen kann.

Teste das angehangene Programm doch bitte mal, und sage mir, was an der Routine falsch sein könnte. Weil die speichert 256-Bytes und belegt noch einen nutzlosen Sektor.

Die Routine habe ich leicht abgeändert, von der Code Base.

Ich hätte mal an die Community eine Frage:

Ist es bekannt, dass die 1541 oder auch 1581, beim Speichen von 256 Bytes, also wenn der letzte Sektor voll ist, einen weiteren Sektor in der BAM Belegt?

Die BAM kann nur mittesl Validate wieder berichtigt werden, weil der leere Sektor keine Verkettung des vorherigen Sektors besitzt.

Anbei, das Testprogramm und der Quellcode. Gestartet wird das Programm mit SYS4096 oder im WinVice-Monitor mit g1000.

Hier noch einige Pogramme, die komplett im SuperCPU-RAM laufen.

Der "SCPU Tab Maker" muss mit ,8,1 geladen werden, um eine kleine Routine, die von $02bf bis $02f2 den RAM belegt, zu starten.

Nach dem Start wird das Programm direkt in Bank $01, ab $1000 geladen.

Alle weiteren Programme können mit ,8 geladen werden.

Es sind auch viele Bugfixes und verbesserungen enthalten, wie z.B. beim Disk Wizard. Die meisten Sprünge nach $AB1E habe ich nach $FFD2 abgeändert (Inkompatible Basic-ROM Routine)

Gibt man mittels $AB1E einen Text aus, der in Bank $01 steht, fehlt der Routine das Bankbyte. Und so wird versucht, von Bank $00 den Text auszugeben, wass natürlich nicht funktioniert.

Wenn jemand die Programme gebrauchen kann, bitteschön.