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 
Da hatte ich wohl Glück.
Das VSP Lab hat bei einem verbastelten Brotkasten nach ca. 40 sec dann Fehler geschmissen.
Die restlichen CeVis sind stabil geblieben.
Tritt der Bug bevorzugt bei kalten VICs auf oder bei warmen?
