Hallo Walter!

GoodByteXL hat geschrieben:

allerdings: von 7 Boot-Versuchen ist bombjack 5 mal gestartet und 2 mal (ganz am Ende, dort wo der Bildschirmspeicher überschrieben wird) hängengeblieben.

Ggf. liegt das an dem komischen Format: 2305 Sekt in SD ...

Das sollte ziemlich egal sein, das File wird auch komplett bis zum letzten Sektor (2304, in Sektor 2305 steht dann das "PICONAME.TXT") geladen. Es muss also irgendwas beim Start von BombJack schiefgehen. Evtl. liegts an meiner Ram-Erweiterung, an irgendeinem kleinen Bug in BombJack, oder irgendwas mit meinem Rechner stimmt gerade nicht.

Hab's gerade eben 3x probiert: alle 3 mal hat es einwandfrei gestartet. Tja, werd' wohl bei Gelegenheit mal meinen Rechner etwas genauer unter die Lupe nehmen...

so long,

Hias

Hi Hias!

Da dein ATR bei mir den gleichen Effekt verursacht (Compy Shop 256K-Erw. im 800XL), das von mir zusammengestellte ATR aber nicht, muss es am ATR liegen, denke ich.

Hast du einen Trick, das File auf eine echte 360K-Disk zu kriegen?

Das einzige DOS bisher, das eine File mit über 1000 Sektoren fehlerfrei auf Diskette bekommt ist bisher SpartaDOS in allen 4 Versionen (1.x, 2.x, 3.x, 4.x).
Hatte es fast vergessen. Aber als ich mit dem Floppy-Controller vom Erhard damals große Files auf die 1,44MB-Disks schreiben wollte, gab's das Problem auch schon ...

Blöderweise gibt es beim Laden unter SpartaDOS aber Speicherkonflikte, die ich nicht lösen kann.

Bewe-DOS versuche ich als nächstes ...

Ich weiß, ist nur Spielerei, aber da ich sowieso mit der ersten Herbstseuche platt zuhause hänge, habe ich Zeit dafür

Versuch' mal mein ATR (siehe letzter Eintrag).

Hallo Walter!

GoodByteXL hat geschrieben:Da dein ATR bei mir den gleichen Effekt verursacht (Compy Shop 256K-Erw. im 800XL), das von mir zusammengestellte ATR aber nicht, muss es am ATR liegen, denke ich.

Sehr seltsam. Evtl. liegt es daran, daß Du MyPicoDos in Version 4.03 verwendet hast und ich in Version 4.04? Das XEX File ist auf jeden Fall identisch.

Wenn es nie funktionieren würde, könnte ich durch systematisches Testen wohl schnell den Fehler eingrenzen, aber da es nur ab und zu auftritt ist das irgendwie blöd...

Hast du einen Trick, das File auf eine echte 360K-Disk zu kriegen?

Einfachste Lösung ist wohl einen Sektorkopierer zu nehmen. Ein 360k Image hast Du ja schon :-)

so long,

Hias

Tja,

Einfachste Lösung ist wohl einen Sektorkopierer zu nehmen. Ein 360k Image hast Du ja schon

Genau da liegt der Haken. Die Formatierroutinen sind nicht "kompatibel" und dann gibt's Datensalat.

Im Image werden offensichtlich nicht 2 Diskettenseiten emuliert sondern nur die Anzahl an Sektoren. Nach 180K ist Schluss mit "fehlerfreiem Kopieren". Ich war selbst verblüfft darüber. Alle DOS2-kompatiblen DOS scheinen damit Probleme zu haben.

SpartaDOS & Bewe-DOS sind bisher die einzigen DOS, die Files, die länger als eine Diskseite sind, auf eine echte 360K-Disk kopieren.

Nun werde ich mal BiboDOS 'rauskramen und die XF weiter quälen ...

Ergänzung:

Bei BiboDOS 6.4RF das Gleiche - nach 180K auf eine Seite der in QD formatierten Disk in der XF551 ist Schluss.

Nun,
das von Yellow Man erstellte Image läuft nur auf XF551 (und kompatiblen) Laufwerken. So ist das bei den meisten XF Tools, sie laufen nur auf der XF und erzeugen bei anderen Laufwerken einen Error 139 weil der Speeder (und die erwartete Geschwindigkeit) nicht stimmt...

So war es früher recht lange schwierig für andere 360k Laufwerke (z.B. Floppy 2000) brauchbare Quad-Density Tools zu finden, da die meisten halt nur für die XF waren. Inzwischen hat sich da zum Glück einiges geändert. Den MyDOS-Bug bei zweiseitigen Disks und langen Dateien (die mehr als eine Seite brauchen) habe ich schon mit Version 4.50 beobachtet und er existiert in allen neueren MyDOS Versionen immer noch - hatte früher schonmal mit ner 3,5" XF versucht sehr lange Dateien auf eine 720k Disk zu kopieren, leider ohne Erfolg.

Es ist mir allerdings neu, das Bibo-DOS und Turbo-DOS diesen Bug auch haben (vermutlich gehen die ähnlich wie DOS 2 und DOS 2.5 von einer max. Filelänge aus, die wohl <180k ist). Egal, ich benutze eh nur noch max. das 180k Format auf realen Floppies, größere Formate nur im Emu bzw. als ATR... -Andreas Koch.

@GoodByteXL: Das sollte für einen vernünftigen Sektorkopierer überhaupt kein Problem sein.

Die meisten DOS-Versionen, die bis zu 360K unterstützen, kucken allerdings beim Kopieren einer DD/QD-Disk in die ersten Bytes des Sektors 360, um festzustellen, ob es sich um eine DD- oder QD-Disk handelt. Da jedes DOS beim QD-Format sein eigenes Süppchen kocht, kann man mit den DOS-Diskkopieren sicher nur Images kopieren, die auch mit dem gleichen DOS erstellt wurden.

Kannst ja mal ausprobieren, $82 in das erste Byte von Sektor 360 zu schreiben (bei SpartaDOS wird ja wohl ein Disk-Editor dabei sein ).
Danach aber keine Files mehr auf die Disk schreiben!
Dann sollte es mit dem Kopierer von Turbo-DOS gehen (weil Turbo-DOS Bit 7 von Sektor 360 als QD-Kennzeichen benutzt).

CharlieChaplin hat geschrieben:Es ist mir allerdings neu, das Bibo-DOS und Turbo-DOS diesen Bug auch haben (vermutlich gehen die ähnlich wie DOS 2 und DOS 2.5 von einer max. Filelänge aus, die wohl <180k ist).

Nein, die Filelänge ist nicht auf 180KB begrenzt.

Gruß Dietrich (der noch nie ein File gesehen hat, das nicht auf eine DD-Disk passt)

@Dietrich: [off topic!]
Naja, bisher waren ja auch die Demo und Game Programmierer meistens so freundlich, ihre ultralangen Programme in zwei oder mehr Dateien zu unterteilen und dann auf zwei oder mehr Diskseiten zu schieben.

Aus vielen ultralangen Demos (mit zwei oder mehr Seiten bzw. mit zwei oder mehr Files) lässt sich aber oft problemlos ein langes single file erstellen, einfach mal die Copy Funktion mit append verwenden, z.B. bei Numen (mainpart) oder vielen anderen Demos. Ich habe dutzende solcher Demos zu single Files zusammengefügt, finden kann man diese z.B. auf meinem DOS Rechner oder halt auf Sven Gleich`s Demo-Homepage mit 1MB Mega-images (nicht alle diese Demos passen auf 180k Disks):

http://www-user.tu-chemnitz.de/%7Esgl/a ... _php3.html

Gerade beim zusammenfügen solcher ultralanger Dateien war mir oft eine 512k Erweiterung sehr hilfreich (hin- und wieder hat da selbst 256k XRAM nicht ausgereicht), insbesondere da die copy+append Funktion unter DOS 2 auf Disk recht lästig ist (nach dem anfügen erfolgt das anpassen der Sektor/Filelinks, das dauert)... -Andreas Koch

Cash hat geschrieben: Die Yellowman Version hat ein Boot Error.

GoodByteXL hat geschrieben:Hallo!

Das Image von Yellow_Man bleibt bei mir immer kurz vor Ende hängen ...

Hallo,

ich weiß nicht was Ihr mit dem Image macht.
Auf dem Emulator läuft es einwandfrei mit 320 Kb CompyShop.

Folgendes um das ATR auf eine echte Disk, nur XF!!!, zu bringen:
Das Image auf den USB-Stick oder die SD Karte, oder was auch immer kopieren.
Auf den Atari den Copy 2000 2.51Q (Q für Quard Densety) laden.
XF Floppy als Ziel und Image als Quelle. Disk-format: On.
Die Diskette wird 2-Seitig formatiert.

Das Quard Format ist NICHT My-Dos kompatibel.
My-Dos zeigt das Directory an, beim laden ist nach Sektor 707 (720) schluß, da die Rückseite nicht erkannt wird.

Das Spiel lädt bei mir von der FX auf einen Atari mit 320Kb nach Compy Shop. Kurz vor ende des ladens, wird der Bildschirm mit Daten überschrieben.

Gruß,
Yellow_Man

@Dietrich:

Gruß Dietrich (der noch nie ein File gesehen hat, das nicht auf eine DD-Disk passt)

Naja, BombJack hat als File über 1000 Sektoren in DD ...

Kann sein, dass in meinem Falle der Error vor der Maschine sitzt .

Aber:
Mit einem Sektorkopierer habe ich das MyDOS-Image mit BombJack auf eine 360K-Disk bekommen. Nur fliegt beim Kopieren die HighSpeed-Routine 'raus und das Booten von 360K-Disk in Normalspeed dauert - aber es funktioniert. Die HS-Routine von MyPicoDOS versuche ich mal nachzuarbeiten, falls das von TurboDOS aus funktioniert.

Hi Walter!

GoodByteXL hat geschrieben:Mit einem Sektorkopierer habe ich das MyDOS-Image mit BombJack auf eine 360K-Disk bekommen. Nur fliegt beim Kopieren die HighSpeed-Routine 'raus und das Booten von 360K-Disk in Normalspeed dauert - aber es funktioniert. Die HS-Routine von MyPicoDOS versuche ich mal nachzuarbeiten, falls das von TurboDOS aus funktioniert.

Das liegt an der MyPicoDos Version, die Du drauf hast (4.03). Support für XF551 etc gibt's erst ab Version 4.04, die 4.03er unterstützt nur Happy/Speedy.

so long,

Hias

OK, das hatte ich überlesen ...

Versuche gleich nochmal eine Kopie mit V4.04.

Was ich nicht verstehe:
Beim Kopieren von langen Files über 180K (nicht Images) bricht der Schreibvorgang auf der XF551 außer bei BeweDOS und SpartaDOS immer mit einem Fehler 139 ab.

In APE kann ich das zumindest mit MyDOS von einer virtuellen Disk auf die andere, mit echten geht's nicht ...

Nachtrag:
Mit V4.04 wir die HighSpeed der XF prima unterstützt. Das ATR dazu [gelöscht].

Zum Kopieren auf eine echte XF-Disk habe ich DiskCopy von TurboDOS verwendet, weil hier die XF korrekt unterstützt wird inklusive HighSpeed. Bei Copy 2000 Q und anderen QD-Sektorkopierern steigt meine XF beim Schreiben bei 180K aus ....

Nachtrag:
Mit FastCopy 2.01 geht's auch, aber nicht so schnell wie mit DiskCopy.

Nachtrag:
Damit die XF551 nicht bei den vielen Disks abraucht, hat sie eine Stromversorgung per Schaltnetzteil (PC).

Hallo,

das ganze noch mal von vorne......
Neue Version 3 von Bomb Jack ist erschienen.


a) press P to get pause
b) press M to switch music on/off
b) you don't need to press SPACE on the titlescreen.

Bernd

Bernd hat geschrieben:das ganze noch mal von vorne......
Neue Version 3 von Bomb Jack ist erschienen.

Und hier das ATR (wieder mit MyPicoDos, diesmal gleich als 360k QD Disk Image):
http://www.horus.com/~hias/tmp/bombjackv3.zip

so long,

Hias

HiassofT hat geschrieben:

Bernd hat geschrieben:das ganze noch mal von vorne......
Neue Version 3 von Bomb Jack ist erschienen.

Und hier das ATR (wieder mit MyPicoDos, diesmal gleich als 360k QD Disk Image):
http://www.horus.com/~hias/tmp/bombjackv3.zip

so long,

Hias

Iss ja ein geiler Service hier.

Cash hat geschrieben:Iss ja ein geiler Service hier. :P

Aber klar, gerne doch!

so long,

Hias

Übrigens, Sowohl das bekannte SIO2SD als auch das neue SDrive laden die Bomb Jack Fileversion problemlos direkt.

MOijn zusammen!

@Dietrich:

Nein, die Filelänge ist nicht auf 180KB begrenzt.

Das sollte ist wohl so, habe es trotzdem noch einmal probiert. In TurboDOS funktioniert das fehlerfrei, in Bewe-DOS und SpartaDOS auch, in MyDOS und BiboDOS nicht - weder von Disk auf Disk noch von APE auf Disk oder umgekehrt. Nach 720 Sektoren (APE zählt so schön mit) ist Ende und es wird mit Error 139 abgebrochen. Beim Kopieren von Disk auf Disk in MyDOS und BiboDOS wird ein Error 130 ausgegeben.

@Beetle: Mit virtuellen Laufwerken kann ich es außer mit APE auf dem SIO2PC nicht mangels Hardware nicht testen. Aber originale Hardware 'piept' viel schöner in meinen Ohren

Vermute einen Fehler in MyDOS / BiboDOS, was das Umkopieren von Files angeht, die mehr als eine Diskseite beanspruchen. VTOC?

Falls es in Zukunft noch mehr solcher langen Files geben wird, die man in die PD-Bibliothek aufnehmen kann, wäre ein Fix für MyDOS vorteilhaft.

Gruß
Walter

(der hofft, dass der Error nicht vor'm Moni sitzt ... )

GoodByteXL hat geschrieben: In TurboDOS funktioniert das fehlerfrei, in Bewe-DOS und SpartaDOS auch, in MyDOS und BiboDOS nicht

Speziell MYDOS versucht, Laufwerke mit den Percom-Kommandos zu konfigurieren. Wenn es nun eine die XF auf Double-Density konfiguriert (statt auf Quad), gibt es natürlich beim Versuch, auf Sektoren > 720 zuzugreifen, Error 139. Das hat mit dem Filesystem (VTOC usw.) nichts zu tun.

Das alles ist hier jetzt aber Mega-Offtopic !

Zur Abwechslung mal was zum Thema:
Es gibt nun eine gepackte BombJack-Version (siehe den BombJack-Thread auf Atari-Age), die "nur" 96KB lang ist. Damit hat sich das Thema 360KB erledigt.

Gruß Dietrich (der nur Images bis 180KB benutzt)

Oh Mist,
da war Dietrich schneller !! Genau genommen gibt es aufgrund meiner Anfrage sogar zwei gepackte Versionen bei atari-age, nämlich

a) von Fandal mit einer Länge von ca. 124k (entpacken der XEX-Version dauert ca. 10 sekunden mit dem emu) und

b) von TeBe mit einer Länge von 96k (entpacken der XEX-Version dauert ca. 20 sekunden mit dem emu)...

na auf jeden fall passt Bombjack jetzt locker auf eine 130k Disk drauf (benötigt natürlich weiterhin 320k RAM)...

-Andreas Koch.