Posts by darkvision

Quote from GoDot

Nein, leider nicht. Das liegt daran, dass ich nicht weiß, ob es da ein Standardformat gibt (idealerweise was mit 1000 Bytes Textbildschirm und 1000 Bytes Farben oder auch ein entsprechendes Basic-Listing mit Print-Anweisungen (für das es bereits einen Lader in GoDot gäbe)). A

Naja... jetzt wo ich weiß wie ich VICE dazu bringe reale 320x200 Pixel im C64 auf 320x200 Pixel am PC-Monitor darzustellen (unskaliert) kann ich das Programm unter VICE starten, den Screenshot auf 320x200 zurechtschneiden und als GIF abspeichern. Das erleichtert zumindest die Suche nach der linken oberen Ecke wenn Vorder- und Hintergrund schwarz sind und man auch sonst nicht erkennen kann wo die 8x8 Pixel/Farbkachel im Bild beginnen. Ein Pixel zu weit rechts/oben/unten/links und die Farben passen nicht mehr zum Bild.

320x200 PNGs von RetroGallery sind aber immer noch die einfachste Variante... Einige Bilder nehmen aber halt auch den Rahmen mit auf.

Gibt ja bald ein paar freie Tage... mal sehn...

Quote from GoDot

Ach ja, denkt auch an solche Bildquellen:

Ja... geht auch... wobei ich das PETSCII-Bild nur als PNG herunterladen konnte und dann doch über GIMP/GIF gearbeitet hab. Manche Bilder lassen sich auch als PRG downloaden, da weis ich aber nicht ob das immer geht und ob GoDot damit klar kommt.

Bei den PNGs muss ich manchmal den Rand wegschneiden und dann die erste Position für die Farbkachel finden. Wenn aber kein Rand da ist (320x200Pixel PNG) dann geht das auch sehr gut ....

Um mal wieder etwas OnTopic zu werden...

Ich hab mir ja die meisten HiRes-Color-Bilder für den C64 in der RetroGallery angeschaut und die (meiner Meinung nach) besten Bilder inkl. Credits konvertiert.

Falls jemand noch ein Bild hat das auf das D81 soll.. oder eine andere Quelle für HiRes-Bilder hat (Farbe 320x200, nicht MultiColor 160x200).. einfach melden. Wenn GoDot die letzten Fehler beseitigt brauch ich was zum testen..

Ich glaub auf das aktuelle D81 passen noch ca.10 Bilder. ..

Ich hab die neue Version v0.06 hochgeladen.

Quote from GoDot

Funktioniert "b-a" (Block-Allocate) auf einer 1581 nicht? (Hab es allerdings nur in VICE ausprobiert, da ich keine 81 mehr besitze).

Wird hier etwas off-topic, wie können das auch im GoDot-Bereich weiterdiskutieren...

Aber der B-A Befehl funktioniert, zumindest auf einer HD-Partition. Man muss aber die 1581-Partition mit angeben. Also:

Mit JiffyDOS und TR=5 und SE=5 wird hier genau ein Block reserviert...

P.S. Die "0" oben ist die 1581-Partition, die man auf 1581-Disketten erzeugen kann... eher seltenes Format.

Hab ein paar Zeilen eingefügt bzw. entfernt. Das Laufwerk wird jetzt nicht mehr gewechselt und damit bleibt die aktive Partition auch unverändert. Die Ziel-Partition wird auch nur noch dann "aktualisiert" wenn die zuvor "aktiv" war...

Hab dabei auch den Kopierpuffer von 4096 auf 8192 Bytes vergrößert, d.h. es finden nur noch halb so viele Diskzugriffe statt. Sollte das kopieren minimal beschleunigen.

Ich teste das jetzt noch etwas und dann stelle ich das Update online...

Quote from Larry

Ich hatte gestern noch ein paar Kopierläufe gestartet und dabei festgestellt, dass hin und wieder am Ende das aktive SCSI Gerät nicht auf die Quelle (HD) zurückgesetzt wird.

Ich muss mir das nochmal anschauen, Probleme gibt es hier aber keine.

Aber am Ende wird aktuell das Ziel-Laufwerk aktiviert, da es ggf. das aktive Laufwerk war und dann muss die BAM im Speicher der HD aktualisiert werden (I0:-Befehl). Das müsste man dann etwas eingrenzen...

Da müsste dann eine Abfrage rein was das aktuelle SCSI-Gerät ist und wenn Target=Aktiv dann welche Partition aktiv ist. Dann muss das Laufwerk nicht gewechselt werden und die BAM nicht aktualisiert werden.

Und falls doch dann wieder auf das andere Laufwerk zurückschalten.

Auch wenn ich BBS nicht mehr nutze... ist es doch interessant zu sehen das man ganze BASIC-Programme in andere Systeme einpflanzen kann.

Wenn alles funktioniert gibt es mind. 2-3 User die das Programm nutzen... hat sich die Arbeit doch gelohnt

Quote from Juergen Johannes

Eben nochmal probiert. 64er Modus, Cbmscsicopy64 Basic (HD ID(4) eingestellt) verlassen. Cbmhdscsi64 Basic ohne Zeile 1210 (ohne Reset CMD HD) gestartet, im Programm wird gleich die vorher eingestellte ID(4) angezeigt.

Nur zum Verständnis: Es geht um die Geräteadresse der CMD-HD, nicht um das aktive SCSI-Gerät. Also z.B. SWAP-8/9 gedrückt oder GEOS hat die HD auf die GEOS-Laufwerksadresse angepasst.

Ich hab nochmal darüber nachgedacht: Bei cbmSCSIcopy kann ich darauf testen, bei cbmHDscsi muss die Adresse #30 = Konfigurationsmodus erlaubt sein -> Falls die Disk nicht initialisiert ist hängt sich die CMD-HD sonst auf. In dem Fall muss man den Konfigurationsmodus einschalten.

Ich hab jetzt aber noch zwei Änderungen eingefügt... ggf. löst es das Problem.

Grundsätzlich empfohlen: RESET (Ausnahme nicht initialisierte Disk) und ser.Kabel

So, jetzt aber genug getestet!!!

Quote from Juergen Johannes

Oder soll ich vorher noch etwas testen, ohne serielles Kabel?

Nö... ich denke das reicht jetzt mit der ganzen Testerei... ich denke die meisten haben eh ein ser. Kabel

Quote from Juergen Johannes

Du hast recht, habe wohl vergessen bei der HD Reset zu drücken.

Da fällt mir ein: Kam da keine Warnung? cmdHDscsi müsste da folgendes anzeigen:

Also wenn die SWAP-8/9 Taste gedrückt ist oder wenn GEOS die Adresse geändert hat.

Quote from C=Mac

Keine Ahnung, was macht das "Programm", was macht der Controller?

Wie viel Einfluss haben die verschiedene Arten (Assembler, Basic)?

Kann ich nicht unterscheiden, für mich sind solche Sachen ein Buch mit zehn Sigel.

Ist ja kein Problem... wenn man die Siegel nicht öffnen kann

Wie man an den Zeiten von Larry zwischen der kompilierten Version (16:03) und der BASIC-Version(19:48) sieht, ist es nicht der Controller der bremst, es sind die Befehle die über den Bus an das Laufwerk geschickt werden müssen. Und das geht in reinem Assembler viel schneller. Evtl. ist es noch der SCSI-Puffer, da nutze ich nur 4Kb... evtl. nutzt der SCSImanager 8Kb... das reduziert die Zugriffe auf die Hälfte. Müsste ich nochmal ins Handbuch schauen...

Quote from Juergen Johannes

Ok, wenn mit "Beiden Kabeln verbunden" alles funktioniert, auch ohne "@P0", könnte man Zeile 1210 ja weglassen?

Oder habe ich da was falsch verstanden?

In Deiner "Exklusiv"-Version sind die Befehle draußen...

Quote from C=Mac

SCSI-Manager (Nur C128) braucht ohne SCPU und Parallel-Kabel ca. 10 Minuten.

Das ist aber auch ein reines Assembler-Programm... cbmSCSIcopy ist auch mit Compiler immer noch ein BASIC-Programm. Ich halte die Zeiten für "ausreichend"... im Vergleich zum kopieren von 16Mb über den seriellen Bus.

Quote from Juergen Johannes

Du hast recht, habe wohl vergessen bei der HD Reset zu drücken. Jetzt funktioniert es.

Ufff.... dann baue ich den gleichen Check ein wie bei cbmSCSIcopy... das meldet am Anfang ja solche Fehler und wartet auf einen RESET an der CMD-HD.

Also geht es doch ohne serielles Kabel

Quote from Juergen Johannes

"?DEVICE NOT PRESENT ERROR in 48320".

Ich hab mir den Code nochmal angeschaut.

War die CMD-HD evtl. auf eine andere Adresse umgestellt? Am besten vorher mal RESET drücken...

An der Stelle wird nämlich die CMD-HD auf das neue SCSI-Gerät umgestellt und dabei auf die Standard-Adresse zurückgesetzt. Wenn das Gerät dann vorher eine andere Adresse hatte... wäre obiger Fehler nachvollziehbar.

Quote from Larry

Dann ein Blick auf die SCPU: Die LED ist aus, auch nachdem das Backup fertig ist ? Das wird doch eigentlich nicht in den 1MHz Modus geschaltet, oder ?

Nö... an den SCPU-Registern ändere ich nichts... das macht die SCPU doch von sich aus bei einem Zugriff auf den ser.Bus. Wie auch das TC64v2.

Quote from Larry

Vorher dauerte das Backup der Partition 16:03 Minuten

Mit TC64v2: Gerade getestet und 15:35 Minuten (Mit AustroSpeed 1E)

Quote from Larry

Erst die gute Nachricht: Es funktioniert ohne Probleme. 16 MB Partition wurde anstandslos kopiert.

Es sieht trotzdem so aus als ob es nicht immer funktioniert, darauf deuten zumindest die Tests von JoJo bei cbmHDscsi drauf hin.

Das serielle Kabel wird also trotzdem benötigt. Aber man muss das PP-Kabel nicht abschalten.

Quote from Juergen Johannes

Habe es doch noch geschafft. Kabel entfernt. HD wird als LW8, RL als LW9, interne 1571 als 11 erkannt.

Versuch ohne Zeile 1210 funktioniert bei mir, in beiden Modi, ohne Probleme. Sogar noch einen Tick schneller, als mit seriellen Kabel.

Versuch mit Zeile 1210, also original, Fehlermeldung "No CMD HD FOUND - EXITING NOW".

Wow! Vielen Dank.. dann kann ich den Befehl rauswerfen.. macht das kompilieren einfacher weil ich den Befehl nicht vorher löschen muss...

1000x Danke

Der 128er ist ja echt ne lahme Krücke

Das es mit PP-Kabel schneller geht ist klar. Die Frage ist aber ob man das PP-Kabel abschalten muss. Ich hab das anfangs von den CMD-Tools übernommen um auf der sicheren Seite zu sein. Aber wenn es nicht nötig ist.. Es muss halt auch ohne ser.Kabel funktionieren...

So, jetzt aber genug auf den großen Bruder draufgeknüppelt... mag den ja auch nicht, aber es freut mich wenn es darauf läuft. Ein bisschen Ehrgeiz hat man ja....

Interessant ist es dennoch das der 64er schneller ist...

Quote from Juergen Johannes

Habe V0.05, erst als 64er (128/64er Modus), dann 128/80er eingelesen und Zeile 1210 entfernt (1210 Return). Dann mit RUN gestartet. Mehere 1581 + 1541 Partitionen kopiert. Scheint in beiden Modi zu funktionieren.

Hast Du auch das ser.Kabel (bei ausgeschalteten Geräten) entfernt? Es geht ja darum ob das auch nur mit PP-Kabel funktioniert.

Quote from Juergen Johannes

Im 64er Modus scheint das kopieren noch einen Tick schneller zu sein, als im 128/80er Modus.

Seltsam... ich dachte der 128er im 80Z läuft mit 2MHz? Oder ist der große Bruder manchmal etwas "langsam"

Quote from Juergen Johannes

Würde das kompilieren gehen, wenn die Zeile 1210, als REM Zeile bestehen bleibt (falls doch noch Fehler auftauchen).

Das kompilieren ist nicht das Problem, sondern das ausführen. Da REM-Zeilen aber alles mögliche an Text beinhalten können: Ja, das geht. Aber im Kompilat kann man das REM nicht mehr entfernen (nicht so einfach...)

Quote from Larry

??? Mir hat der Befehl beim Kompilieren keine Probleme gemacht. Wurde als einzige Extension also solche erkannt und verwurstet.

Am 128er mit Blitz!128 hatte JoJo aber ?SyntaxError-Fehler, das Programm ließ sich zwar starten aber hat dann abgebrochen. Nach löschen der Zeile: Alles OK.