Da das ROM sich von einem normalen JiffyDOS Rom unterscheidet, dachte ich kann es vielleicht jemand brauchen.
Natuerlich unterscheidet sich das, es ist schliesslich ein anderes Produkt.
Fuer jede Art von Rechner/Floppy gibt es unterschiedliche ROMs/Kernals.
Quatsch ! Die SW ist die Gleiche. Lediglich am ROM sind 2 Adressleitungen vertauscht. wenn man diese beiden Leitungen über einen Adaptersockel beim Programmieren vertauscht, ist das aus Sicht der CPU exakt das gleiche ROM wie in der 1541
Selbst mit sehr starken Magneten hat meines Wissens kaum jemand geschafft, mal ein Bit umzukippen, was früher so rumgeisterte (Nicht auf TV/Lautsprecher legen usw.) sind überwiegend ewig weiter erzählte Ammenmärchen.
stärke des Magneten UND sein Abstand zum Datenträger ist entscheidend !
Nimm einen Neodym-Magneten von der Größe eines Cent-Stückes und wische 5x auf der Disk-Oberfläche entlang und Du wirst sehen, dass Du da nix mehr Gescheites von lesen kannst
In diesem Fall hilft ein sehr gutes Tool weiter : Speaking Hardformatter 
Außerdem werden z.B. mit dem Action-Replay-Disk-Backup die Spuren dann auch gleich neuformatiert, wenn man die Option anwählt.
Vorsicht ! Der AR-Formater macht kein Verify und liefert auch ein OK, wenn die Disk außer Track 18 komplett schrott ist.
Allerdings kann man den AR-Formater auch sehr schön zum drüberbügeln nehmen, denn .....
Nach meinen vorhergehenden Experimenten mit OpenCBM nahm ich dann mal so eine Disk und formatierte sie, inkl. Verify und Abschlussbericht. Lesefehler ohne Ende. Dies wiederholte ich nun und bemerkte, das sich die Lesefehler auf den Tracks von Mal zu Mal besserten, ja bis die Disk nach ungefähr 5-6 Formatierungen dann sogar fehlerfrei war.
..... genau das habe ich auch schon mehrfach festgestellt - und nach 10x AR-Format konnte man dann (oft) auch mit dem DOS-Format mit Verify eine fehlerfreie Disk formatieren. Ob und wie lange hier die Daten dann drauf bleiben, ist die große Frage ....
was hat mich das schon Lebenszeit gekostet (wenn man MOV AX,[$b000] liest, aber MOV AX,$b000 geschrieben hat)
der Klassiker ist immer noch ...
lda Konstante statt lda #Konstante
beides ist gültig aber eines davon ist immer völlig falsch im entspr. Kontext ...
Das hat mich auch schon extrem Lebenszeit gekostet und graue Haare beschert
Irgendwie ist dein Code ein wenig confuse mit den branches. Du schreibst zwei Mal in $D03F...
ja, ich habe ein +checkdtv - macro, was auch ein lda #1 sta $d03f macht - kann ich ja später weglassen ...
und der code soll nur ein schmaler testcode sein, darum keine Tabellen und mehr inx + stx $d020
mein Fehler war
lda #$04
lda $d03c
bringt nicht soviel, mit einem sta $d03c funz es nun - erwartungsgemäß
nach einer 1:1 Analyse des binarys hab ich es dann auch gemerkt ..... 
DANKEEEEEE 
so, habs ausprobiert, funzt nicht bei mir im Vice 
wieso geht das bei Dir und bei mir nicht ?
edit: meine Vice-Version ...
Es muss lauten LDA #$04 STA $D03C. Dann klappt es auch mit den 256 Farben für die Bildschirmhintergrundfarbe.
alles klar, vielen Dank.
Sollte vorher mal das ProgrammingGuide lesen ..... 
Also, auf dem WinVice x64dtv funktioniert dein Code.
eben NICHT ! denn der Screen sollte den gleichen Farbverlauf haben wie der Border !
DAS ist mein Problem was ich versuche zu lösen ....
vielleicht weiß peiselulli der alte DTV-Profi ja Rat - ich muß ihn mal anschreiben ....
Moin,
ich hab mal für mich einen DTV-Farbtest gecoded und ich bekomme die 256 Farben im Border hin , aber nicht auf dem Screen $d021, obwohl ich $d03f auf #$01 gesetzt hab, wie es Jerry im DTV-ProgrammingGuide beschrieben hat.
Danach soll es in $D021 auch gehen. Hat jemand einen heißen Tipp ?
anbei mal mein Codeschnipsel und das binary...
Moin ,
ich bin auch dabei, freue mich schon
wenn ich mit -a ein vorhandenes DirArt von einem D64 extrahiere, dann wird bei normalen Bindestrichen der Hexwert #2d ausgegeben, obwohl beim Erstellen mit reinem Text mit Bindestrichen der richtige Hexwert #2d erzeugt wird.
Funktioniert es besser, wenn Du in print_filename_with_escapes() diesen Passus
auf
erweiterst?
yo, so passt es perfekt - dankeeee 
Claus : kannste in der nächsten Version direkt so einbauen 
DirArt kannst Du übrigens auch automatisch extrahieren mit -a
ahhh, DAS ist doch mal ein gutes Featue !! Super, damit kann man arbeiten
Was mir aufgefallen ist:
wenn ich mit -a ein vorhandenes DirArt von einem D64 extrahiere, dann wird bei normalen Bindestrichen der Hexwert #2d ausgegeben, obwohl beim Erstellen mit reinem Text mit Bindestrichen der richtige Hexwert #2d erzeugt wird.
Warum der Einwand?
weil sowas .... -L -T DEL -N -f " on mar-12-2023 " .... kann ich im BuildScript als besser lesbare Variable abbilden/erzeugen als
sowas: -L -T DEL -N -f " on mar#2d12#2d2023 "
Beides würde das selbe Ergebnis bringen ...
War nur jammern auf hohem Niveau - cc1541 ist wirklich ein Top-Tool was einem soooo viel Arbeit abnimmt ....
Danke dafür !! 
cc1541
Was ist das?
mit cc1541 kannst Du in Scripten, Makefiles unter Linux bzw. in Batch-Dateien unter Windows vollautomatisch D64 -Images erstellen.
siehe auch HIER
Im Hex String sind nur Kleinbuchstaben erlaubt.
danke , das wars ! Auf sowas muss man erstmal kommen 
Außerdem musst du doppelte Anführungszeichen verwenden, also: "
nö, muss man nicht, jedenfalls in der Linux-Shell funzt 'xxxxxx' auc super und machmal sogar besser als "xxxxxx"
Moin,
ich habe mit mit cc1541 ein d64 erstellt und bereits erfolgreich 2 Dateien drauf kopiert.
Nun wollte ich auch gleich mein DirArt mit drauf machen. Also habe ich mir mit einem HEX-Editor die 16bytes jeder Zeile des Dirarts eines anderen D64 rauskopiert und wollte es mit cc1541 in mein neuen Disk-Image einfügen. leider gibt's da aber Fehler, dessen Grund ich nicht kenne. Weiß jemand einen Tipp ?
frag mal AuSPuFF² , der hat die schnellen xum1541 gerade neu aufgelegt
Und wenn eine Adressleitung nicht passt, dann kommt das Rom im Normalfall auch nicht mehr bis zum Test-Code....
kommt drauf an, welche Adressleitung defekt ist und wo der Code steht
Also ich finde das schon sehr sinnvoll.
ja, sinnvoll ist es schon ...
Wenn das ROM ganz defekt ist -> Dauerlauf. Das erkennt man.
Wenn das ROM subtil defekt ist -> Fehlerblinken.
ok, das ist ein Argument ! Den Dauerlauf gibts ja auch noch - hatte ich nicht auf dem Schirm
1541 mit rot blinkender Lampe...
Sind für die 154x/157x alle gleich, WIMRE.
wollte ich schon immer mal wissen:
die Selbsttests mit den Blinkcode werden doch in mit der Software im ROM gemacht, oder ?
Wie kann denn die Software, die aus dem ROM kommt, feststellen, dass Ihr eigenes ROM defekt ist ?
Weil wenn das ROM defekt ist, läuft doch auch die Selbsttest-Softwae nicht (oder nur buggy).
gibt's da nicht ein Henne/Ei-Problem ?
ARRRRRRR - ich werd ncohmal irre mit Dropbox .... 
so nu nochmal aufs Neue ...
Es gibt eine Aktualisierung der 3 Links, wo es das Manual, die UNIPROM64-EPROM-Kollektion und die EPROM-Generatoren zu saugen gibt.
Es gibt eine Aktualisierung der 3 Links, wo es das Manual, die UNIPROM64-EPROM-Kollektion und die EPROM-Generatoren zu saugen gibt.
Moin,
es gibt was neues und zwar 2 neue Modul-Generatoren:
make_64k_TC_Multifile-Multiload_EPROM-FILES_linux_x64
make_128k_TC_Multifile-Multiload_EPROM-FILES_linux_x64
TC steht hier für Tinycrunch !
Dieser Multifile-Multiload EPROM-Generator fuer das UNIPROM64-EPROM-Modul bestehent aus einer
Shell-Script-Datei (make_TC_Multifile-Multiload_EPROM.sh) und einer dazugehoehrigen Config-Datei
(multifilelist.conf).
Das Shell-Script erstellt zusammen mit der Config-Datei aus einem oder mehreren
PRG-Files ein 64kb bzw. 128kb grosses EPROM-File, welches auf einen 27C512-EPROM gebrannt werden
und dann mit der UNIPROM64-EPROM-Karte benutzt werden kann.
Beim Ausfuehren der Shell-Script-Datei unter Linux werden alle Files mittels
Tinycrunch inplace gepackt (-vi). Dadurch ist es auch möglich, z.b. Leveldaten über das
UNIPROM64-Modul nachzuladen und inplace zu entpacken ohne den restlichen Speicher anzutasten.
Über das Shell-Script wird vollautomatisch der dazugehörige Header-Quellcode assembliert, dann mit dem
entsprechenden Programmfiles zusammengefuegt und schliesslich die fertige BIN-Batei
in den Ordner "TC_Multifile-Multiload_64kb-EPROM-DATA" abgelegt.
Weiterhin wird fuer Testzwecke ein CRT-File erstellt, das man im Vice als Cartridge laden
kann um zu sehen, ob Alles zur Zufriedenheit erstellt wurde und auch laeuft.
Die gepackten Files sind Headerless, d..h. die Entpackroutine gibt es nur 1x im Modul - das spart Speicherplatz ....
Dieser Modulgenerator ist für gepatchte Nachlade-Programme !
Es kann alles kopiert/extrahiert werden zwischen $0200 und $FFFF - selbstverständlich auch unter den ROMs und unter den I/O-Bereichen.
Es werden nur folgende Zeropage/Stack-RAM-Adressen verwendet:
$02, $FA-$FF, $0100-$01C7
Der Rest steht im Modulcode oder wurde bereits vom Shellscript erledigt
Das erste Programm wird nach dem RESET automatisch gestartet. In dem Programm sollte die Load-Routine für die Nachladung der nächsten Files mit der
Nachlade-Routine des UNIPROM64-Moduls ersetzt werden, und zwar wie folgt:
viel Spaß mit den neuen Features des UNIPROM64-Moduls
ich hätte LazyJones getippt
