Reboot C64 macht ein cold-boot so scheint es.
Nicht ganz: Der FPGA und die Software wird nicht neu aus dem EPROM geladen... Ansonsten stimmt es.
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von Jood am
Reboot C64 macht ein cold-boot so scheint es.
Nicht ganz: Der FPGA und die Software wird nicht neu aus dem EPROM geladen... Ansonsten stimmt es.
Nicht ganz: Der FPGA und die Software wird nicht neu aus dem EPROM geladen... Ansonsten stimmt es.
Heb bemerkt wenn man eine andere cartridge/kernel/floppy kernal ladt, dan Reboot dan werden dieser dinger activiert. Bei normaler Reset nicht.
Stimmt. Dazu kann die Ultimate allerdings die bereits geladene Software und den geladenen FPGA nehmen... Wobei das ROM-Image vom Modul dann tatsächlich vom Eprom geladen wird. Meine Aussage hat sich allein auf die Software der Ultimate bezogen (das ist jene, die die Menüs macht, sich um die Ansteuerung des FPGAs kümmert, das Ethernet bedient und anderes).
Ich habe ein G64 im 1541U-II Plus gemount, und mit Turbo Nibbler V4 mit half-tracks eine kopie zum echten 1541 gemacht, aber der ziel-diskette ist danach nicht in ordnung. Muss noch weiter testen mit nibbler.
Öh, eine 1541 kann keine Halftracks fehlerfrei schreiben. Der Schreib-/Lesekopf ist dafür zu dick und beschreibt jeweils den benachbarten Halftrack (auf beiden Seiten des Tracks) teilweise mit. Dort musst Du den Fehler suchen.
Hat jetzt aber nichts mit der Ultimate zu tun, also Fortsetzung bitte im passenden Thread, sofern notwendig.
Öh, eine 1541 kann keine Halftracks fehlerfrei schreiben. Der Schreib-/Lesekopf ist dafür zu dick und beschreibt jeweils den benachbarten Halftrack (auf beiden Seiten des Tracks) teilweise mit. Dort musst Du den Fehler suchen.
Hat jetzt aber nichts mit der Ultimate zu tun, also Fortsetzung bitte im passenden Thread, sofern notwendig.
Da verwundere ich mich ein bisschen, denn ich habe fruher mal ein GEOS 2.0 System diskette kopiert mit burstnibbler, und ich habe gelesen dass GEOS half-tracks gebracht fur die kopier-schutz. Die kopie lief ohne probleme.
Aber, angenommen dass wurde nicht klappen, welche drive typ sollte ich mal probieren fur diese test?
Habe ich auch gemacht - ohne Halftracks. Geos braucht keine Halftracks.
Ansonsten siehe Anleitung Burstnibbler: Man soll exakt die Stelle, wo der Kopierschutz ist, per Halftrack kopieren und den Rest ohne Halftracks. Wobei ich zugeben muss, mit Halftracks habe ich eher theoretische Erfahrungen. Klar ist jedoch: Mit einem 40 Spurkopf kann das nicht klappen, jeden Halftrack mit Daten zu füllen...
Gibts denn eine drive die dass konnte? Ich habe 1541-II, 1570, 1571, BlueChip als mogliche alternativen. Kennst du einer G64 die half-tracks ausnutzt? Ich mochte mal wissen was lauft und was nicht
@nhoijtink: Machst Du bitte, wie von Markus vorgeschlagen, dazu einen neuen Thread auf, das gehoert nicht in den Thread zur U2(+).
@nhoijtink: Machst Du bitte, wie von Markus vorgeschlagen, dazu einen neuen Thread auf, das gehoert nicht in den Thread zur U2(+).
Das lesen/schreiben/kopieren von/zu 1541 Ultimate zum 15xx drives um die compatibilitat zu testen hat nichts mit 1541 Ultimate zu tun?
Im Allgemeinen schon, aber Deine Frage geht ja eher in Richtung der Hardwarefähigkeiten von Commodore Laufwerken. Gepaart mit Nibblerbedienung (die waren nicht dafür gedacht, eine ganze Disk per Halftrack zu kopieren).
Ich habe ein G64 im 1541U-II Plus gemount, und mit Turbo Nibbler V4 mit half-tracks eine kopie zum echten 1541 gemacht, aber der ziel-diskette ist danach nicht in ordnung. Muss noch weiter testen mit nibbler.
Ich lass sein....
Ulticopy 8 funktioniert
![]()
Nach dem Kopieren ist zwar das Directory (Header) der Quelldisk zerstört, aber das ist kein Problem.
wie jetzt ??
meine Quelldisketten haben in der Regel auch einen Schreibschutz .
oder ist im Backup die Störung ??
Das Problem ist "nur" im Floppy-RAM der echten 1541. Ein Initialize bspw. bringt wieder alles in Ordnung. Oder Disk rausnehmen. Oder Reset...
Kurz: Offenbar wird ein wichtiger Buffer im RAM der Floppy überschrieben. Kein Grund zur Sorge.
Nachtrag: Ich denke, es ist der Buffer mit der BAM.
Frage: Wie funktioniert das mit dem Ultimate Dos ? Kann man das Teil wie ne Finale Cartridge verlassen und landet dann ins Basic und hat dort noch Floppy Kommandos zur Verfügung? Oder wie muss ich mir das
keiner in Benutzung?
wie jetzt ??
Hab's unglücklich formuliert.
Lese ich das Directory der Quelldisk mit F1 (JiffyDos) ein.
Wird nach dem Kopieren mit Ulticopy8 der Header verstümmelt angezeigt.
Erst wenn ich die Quelldisk aus dem LW nehme und wieder einsetzte, wird das Directory korrekt angezeigt.
Bin jetzt nicht sicher, aber JD hält das Dir, glaub ich, im Speicher und liest es ohne Diskwechsel nicht wieder von Disk ein.
Es handelt sich um einen optischen Makel äh ich meine natürlich Feature
Edit: markusC64 war schneller.
@markusC64
Danke für's erklären.
Es gibt noch viele Funktionen, welche ich noch nie benutzt habe bzw. gar nicht weiss für was sie sind.
Aber man lernt dazu
Gruss C=Mac.
Sorry, das Posting ist einigen wohl durchgegangen...
Nein, um das nutzen zu können, muss man schon selbst programmieren. Vorzugsweise Assembler. Aber in Basic geht das durch eine Kette von POKE-Anweisungen auch - natürlich auf Kosten der Performance.
Nachtrag: Ich habe bei mir noch eine Routine wiedergefunden, welche ein paar API-Aufrufe der Ultimate testweise aufruft. Ich füge die einfach mal diesem Posting hinzu.
Bin jetzt nicht sicher, aber JD hält das Dir, glaub ich, im Speicher und liest es ohne Diskwechsel nicht wieder von Disk ein.
Commodore DOS hat einen Buffer, in dem die BAM gehalten wird. Und jener Sektor beinhaltet auch den Disknamen.
Da die BAM aber im RAM dann auch falsch ist, darf man keiensfalls das Problem ignorieren, sondern muss durch eine der zuvor genannten Möglichkeiten Abhilfe schaffen (Initialize, DIsk rausnehmen, Reset).
Die v3.1_475+_v1 habe ich jetzt auch mal auf meine UII+ geflasht. Noch habe ich nichts weiter getestet außer USB-Devices. Ergebnis: Der USB-Stick, den Gideon mit der UII+ mitgesendet hat, funktioniert nach wie vor. Der USB-2.0-Stick, von dem ich geflasht habe, funktioniert nach dem Update nun nicht mehr (am PC aber schon). Zwei USB-Geräte (ein Stick und ein Adapter für MicroSD-Karten) werden im Gegensatz zu vorher jetzt einwandfrei von der UII+ erkannt.
Der mit dem Update ausgeknockte Stick wird bei Anschluss zwar kurz in der Liste mit korrekter Bezeichnung angezeigt. Statt "Ready" steht neben dem Namen aber "Unknown" und kurze Zeit später verschwindet der Stick wieder aus der Übersicht. Das USB-Handling scheint nicht so einfach zu sein. Zumindest hängt es offenbar nicht an der Hardware der UII+.
Ehrlich gesagt finde ich es schon sehr bedauerlich, dass das Easyflash nun seit Jahren nicht richtig unterstuetzt wird.
Geht mir genauso. Zumal es - wenn ich mich richtig erinnere - aus fachkundigem Mund hieß, das wäre nicht schwer zu implementieren. Vermutlich ist der Drang dazu deshalb nicht so hoch, weil das EasyFlash-Format ja läuft und "nur" Schreibzugriffe nicht funktionieren.
Geht mir genauso. Zumal es - wenn ich mich richtig erinnere - aus fachkundigem Mund hieß, das wäre nicht schwer zu implementieren. Vermutlich ist der Drang dazu deshalb nicht so hoch, weil das EasyFlash-Format ja läuft und "nur" Schreibzugriffe nicht funktionieren.
Ja, das finde ich auch sehr schade. Und das ist bei mir echt der Grund, warum ich die 1541U als Standalone nutze...
Weil ich brauche einfach mein EasyFlash3.