Posts by konsolero

Quote from Larry

Firmware 3.12a von vor 9 Stunden: Illegal Device Number Error bei Device#2 ?? Was soll das denn? Altes U64 1.4a Board.

Hatte das jemand von euch schonmal ?

Modem und damit BBS geht so nicht mehr

Hi Larry,

ich habe bei meinem Ultimate64 Elite (eins) auch die 3.12a damals im Mai / Juni draufgemacht, war dann aber länger nicht mehr im BBS.

Habe damit beim Connect zu C*Base BBS aber auch massive Probleme mit "verschluckten" Daten und kann mich nicht mehr per Swiftlink einwählen.

Habe daher wieder downgegradet (erfolgreich) auf die FW 3.11, musste aber auch den zugehörigen ESP32-Patch auch wieder draufmachen,

um WiFi zum Laufen zu bringen.

Damit gehen wieder die geliebten C*Base BBSes

Gruß Konsolero aka 01101 Zaindlmaier 10110

-[0/0]-

Hi,

nö, ich hatte den Kernal nicht mit der U2+ ersetzen lassen.

Ich dachte, die "harte" Kernal-Variante wäre sicherer. Hatte den Kernal im Realoaded MK2.

Habe jetzt allerdings überall die 3.10er drauf. Damit tut's jetzt.

Interessant, das mit dem "Byte patchen".

Ich hab nämlich nochmal n Compare der Kernals gemacht.

Dabei ist mir aufgefallen, dass bei $FF80 im laufenden U64 ne $08 steht und im ROM ne $09.

Komische Sache das

Hallöchen,

ich hätte da ne Frage zu dem neuen "Hyperspeed File System" Feature beim Software IEC.

Sollte das eigentlich auch mit der 1541U2+ funktionieren? Es ist ja genau so im Firmware Update mit enthalten.

Auf meinem U64e funktioniert es mit dem neuen U64-Kernal problemlos und 200 Blocks werden in einem Augenblick geladen.

Allerdings funktioniert der schnelle Zugriff nicht auf meiner 1541U2+. Da lädt er zwar, aber es dauert viiieeel zu lange.

Habe schon 2 unterschiedliche Kernal-Varianten des U64-Kernals getestet (eine Version vom Dezember'20, die andere vom Januar'21).

Allerdings leider ohne Erfolg.

Der Kernal benutzt ja das UCI (Ultimate Command Interface). Das hat ja die U2P auch genau so wie das U64e.

Hat das von Euch schon mal jemand ausprobiert?

Hallo,

ich hätte da ne Frage zu dem neuen "Hyperspeed File System" Feature beim Software IEC.

Sollte das eigentlich auch mit der 1541U2+ funktionieren? Es ist ja genau so im Firmware Update mit enthalten.

Auf meinem U64e funktioniert es mit dem neuen U64-Kernal problemlos und 200 Blocks werden in einem Augenblick geladen.

Allerdings funktioniert der schnelle Zugriff nicht auf meiner 1541U2+. Da lädt er zwar, aber es dauert viiieeel zu lange.

Habe schon 2 unterschiedliche Kernal-Varianten des U64-Kernals getestet (eine Version vom Dezember'20, die andere vom Januar'21).

Allerdings leider ohne Erfolg.

Der Kernal benutzt ja das UCI (Ultimate Command Interface). Das hat ja die U2P auch genau so wie das U64e.

Hat das von Euch schon mal jemand ausprobiert?

Hallo zusammen,

jetzt muss ich doch noch den alten Beitrag reaktivieren bzgl. der 9VAC Spannung

Ich habe kürzlich den neuen Userport-Adapter bei Gideon bestellt und auch bekommen, ausgeschrieben mit den 9VAC an PIN 10 u. 11.

Laut C64-Wiki wird die Wechselspannung auch genau an diesen beiden PINs gemessen (10, 11)

Die erste Vergleichsmessung habe ich beim Reloaded MK2 gemacht, wo mir mein Multimeter 11V angezeigt hat.

Am Adapter beim U64 hatte ich da etwas mehr als 12V.

Und beides hat mich etwas verwirrt.

Ich benutze zwar nur den 4-Player-Adapter, den die 9VAC PINs gar nicht interessieren, wollte aber schon wissen,

ob das mit den 9VAC passt.

Das könnte natürlich auch am Messgerät liegen.

Kann jemand bestätigen, dass die neue Userport-Adapter-Platine (die auch so ausgeschrieben ist) die 9VAC zuverlässig liefert?

Oh, thanks for the info.

That explains some odd behaviour, that occurs in a few situations.

Hallo,

mal eine Frage an die Experten, was die Speed Zones der 1541 beim Lesen / Schreiben angeht.

Die Bits 6 und 5 in $1c00 legen ja die Schreibgeschwindigkeit der Magnetisierungswechsel in der 1541 fest.

Gilt dies nur für den Schreibvorgang?

D.h., beim Lesen sind diese Bits in $1c00 irrelevant, da der Timer im Controller ja durch die 1er Bits / Magnetisierungswechsel getriggert wird?

Wenn man z.B. den Job $e0 abschickt (Motor an, Lesekopf positionieren und Job starten), werden diese Speed-Bits vom Betriebssystem automatisch korrekt gesetzt (bis Track 35).

Nach meinen Beobachtungen wird die Speed-Zone ab Track 36 in der 1541-II fälschlicherweise mit 2 (= 10) belegt, müsste eigentlich wie bei Track 35 bei 00 liegen.

Das wäre aber nur beim Schreiben von Daten relevant, korrekt?

Ah, danke.

Hab zwar die Doku vom MK2 durchgelesen, hab da aber nach nem Bildchen gesucht.

Die entscheidende Zeile hab ich überlesen

Hallöchen,

ich hätte da mal n paar Fragen zur PIN-Belegung der A/V-Buchse des MK2:

- ist die A/V-Buchse exakt so belegt wie beim Original? D.h., Stereo (SID1/SID2) kommt da ausschließlich über die Klinke ?

- PIN 3 der A/V-Buchse geht also auf Audio-out und PIN 5 geht auf Audio-in (Ext-in) ?

Beim U64e ist es ja so, dass PIN 3 u. 5 jeweils zu den entsprechenden SIDs gehn und Audio-in nicht mit der A/V-Buchse verbunden ist.

So waren zumindest meine Beobachtungen.

Also das Problem mit dem Delfin im Bermudadreieck in der deutschen Version hatte ich auch aufm original Easyflash.
Ob es an einem bereits defektem Savegame lag, kann ich nicht mit Sicherheit sagen.
Beim Crash hat das Spiel allerdings den gesamten Savegameslot zerflasht.

Ich Probiere das mal in Vice aus, ohne ein Savegame anzulegen, statt dessen mit Snapshots.
Dann sollte sich schnell herausstellen, obs am Savegame lag.

Aha, das erklärt alles.
Das wollt ich wissen.

Danke

Das ist mir schon klar.

Ich formuliers nochmal etwas anders:
Also wenn ich den Raster-IRQ aktiviert habe und in der Hauptschleife einen
JMP * verwende, dann habe ich einen Jitter von 0-2.
D.h., der VIC Cycle müsste sich direkt nach Auslösen des IRQ zwischen 7 und 9 befinden.
Aber: Der VIC Cycle ist hier dann zwischen 9 und 11 (laut VICE).
Das heißt für mich, das Auslösen des IRQ benötigt hier 9 Cycles, nicht 7.

Ist dem so oder zählt VICE die VIC Cycles etwas anders?

Ich mein den Cycle der aktuellen Rasterzeile des VIC II.
Die wird ja im VICE Monitor in der Übersicht (R) immer angezeigt.

Hi,
hab da mal ne Frage an die Experten:
Auf codebase64.org wird beim Aufbau eines stabilen Raster-IRQs beschrieben,
dass das reine Auslösen desselben 7 Cycles benötigt.
Also ich meine nur das Sichern des SP, PC und Sprung nach ($FFFE).

In VICE bin ich da allerdings immer bei Cycle 9.
(Das Ausführen der vor dem Eintreten des IRQs mitberücksichtigt)

Ist bei VICE die Zählweise etwas anders oder benötigt das Auslösen tatsächlich 9 Cycles?

Jupp, jetzt les ichs. Hast ja auch geschrieben "wenn die Firmware hinreichend neu ist"

Ich hab mir das C64-Jiffy.rom als EXOS-CRT gebaut.
In WinVICE funktioniert das.

Bei meiner Ultimate2+ bekomme ich beim Laden der CRT allerdings die Meldung: EXOS not implemented
(Firmware 3.1 (10C) )

Sehr interessant. Den CRT-Typ kannte ich noch nicht.
Muss ich mir auch gleich mal anschauen.

Mit einem CRT-Image eine KERNAL-Cartridge abzubilden wird - so wie ich das sehe - eine unmögliche Aufgabe.
Wenn man den Artikel von skoe liest (und halbwegs versteht):
http://skoe.de/kernal/kernal-cartridge.pdf
dann ist für einen KERNAL-Ersatz via Cartridge auf jeden Fall separate Hardware notwendig (welche im Easyflash3 und in der 1541Ultimate vorhanden ist).

Ganz am Ende von Punkt 1.2 ist das grobe Konzept für die Aufgaben der Cartridge beschrieben.
Diese muss nämlich permanent, je nach Speicherzugriff, permanent zwischen No-Cartridge-Mode und Ultimax-Mode hin und herschalten.
Je nach dem, ob die CPU von Adresse $E000-$FFFF aus dem KERNAL oder aus dem RAM lesen soll, ebenso, wenn vom RAM zwischen $1000-$FFFF gelesen werden soll.
Denn der KERNAL-Bereich kann nur im Ultimax-Modus überblendet werden, dann hat man aber keinen Zugriff mehr auf das RAM zwischen $1000 und $FFFF.

Abgekürzt heißt das: Über ein CRT-Image wird das wohl nicht gehen.

Wenn man jeweils den x64 von vice-2.4 und vice-3.0 (in meinem Fall WinVICE) mit -remotemonitor startet und sich per telnet aufschaltet (Port 6510),
dann stellt man die Unterschiede im Protokoll fest.
Während 2.4 immer auf <enter> wartet, reagiert die 3.0 bereits beim ersten Eintippen des Befehls.
Ob sich das auch durch das Betriebssystem unterscheidet weiß ich nicht.
Auf jeden Fall ist das Protokoll leider nicht kompatibel

Ja, stimmt. Steht bei der Erläuterung von VSP Lab 1.0.
Sehr interessant ist auch der Scroller-Text von "Safe VSP" von tlf
http://csdb.dk/release/?id=115690

und natürlich die gesamte Diskussion
http://csdb.dk/forums/?roomid=11&topicid=99103&firstpost=2

Jetzt hab ich erst mal was zu lesen