Hängt scheinbar mit dem Native-Lfw zusammen, denn mit einem 1581RAM-Lfw funktioniert es ohne Probleme.
Ich habe bisher noch keine Ahnung, an welcher Stelle sich das Programm dann stört bzw. aufhängt.
Pusti64
Es gibt 735 Antworten in diesem Thema, welches 110.873 mal aufgerufen wurde. Der letzte Beitrag (
Hängt scheinbar mit dem Native-Lfw zusammen, denn mit einem 1581RAM-Lfw funktioniert es ohne Probleme.
Ich habe bisher noch keine Ahnung, an welcher Stelle sich das Programm dann stört bzw. aufhängt.
Pusti64
Hängt scheinbar mit dem Native-Lfw zusammen, denn mit einem 1581RAM-Lfw funktioniert es ohne Probleme.
Ich habe bisher noch keine Ahnung, an welcher Stelle sich das Programm dann stört bzw. aufhängt.
Schau mal hier:
.C:7123 60 RTS
.C:7124 AD CC 70 LDA $70CC
.C:7127 F0 FA BEQ $7123
.C:7129 AD C6 88 LDA $88C6
.C:712c 29 04 AND #$04
.C:712e F0 0B BEQ $713B
.C:7130 20 0A 47 JSR $470A
.C:7133 AD CB 70 LDA $70CB
.C:7136 D0 EB BNE $7123
.C:7138 4C 71 5C JMP $5C71
.C:713b 4C 7C 46 JMP $467C
.C:713e 4C 27 3D JMP $3D27
.C:7141 A2 0A LDX #$0A
.C:7143 20 D7 61 JSR $61D7
Alles anzeigen
Das ist nach dem Umbenennen-Dialog. Da wird dann bei $7129 curType abgefragt.
bei NativeMode wird dann der Code ab $7130 ausgeführt. Die Routine bei $470a baut den Bildschirm neu auf, alle Fenster sind jetzt aktualisiert.
Nach dem Rücksprung aus dem Unterprogramm $470a steht bei $7133 aber $00-Code -> PANIC!
>C:7133 00 00 00 00 00 00 00 41 00 00 00 00 00 00 00 00 00 00 00 00 .......A............
>C:7147 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 42 00 00 .................B..
>C:715b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....................
>C:716f 00 00 00 00 00 00 00 43 00 00 00 00 00 00 00 00 00 00 00 00 .......C............
>C:7183 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 44 00 00 .................D..
>C:7197 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....................
>C:71ab 00 00 00 00 00 00 00 45 00 00 00 00 00 00 00 00 00 00 00 00 .......E............
>C:71bf 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 46 00 00 .................F..
>C:71d3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....................
>C:71e7 00 00 00 00 00 00 00 47 00 00 00 00 00 00 00 00 00 00 00 00 .......G............
Sieht so aus als wird beim Aufbauen der Fenster der Bereich mit den Dateinamen innerhalb des Fensters überschrieben. Nach der Rückkehr aus $470a ist das vorherige Programm dann "weg"...
Alles anzeigenHängt scheinbar mit dem Native-Lfw zusammen, denn mit einem 1581RAM-Lfw funktioniert es ohne Probleme.
Ich habe bisher noch keine Ahnung, an welcher Stelle sich das Programm dann stört bzw. aufhängt.
Schau mal hier:
Code Alles anzeigen.C:7123 60 RTS .C:7124 AD CC 70 LDA $70CC .C:7127 F0 FA BEQ $7123 .C:7129 AD C6 88 LDA $88C6 .C:712c 29 04 AND #$04 .C:712e F0 0B BEQ $713B .C:7130 20 0A 47 JSR $470A .C:7133 AD CB 70 LDA $70CB .C:7136 D0 EB BNE $7123 .C:7138 4C 71 5C JMP $5C71 .C:713b 4C 7C 46 JMP $467C .C:713e 4C 27 3D JMP $3D27 .C:7141 A2 0A LDX #$0A .C:7143 20 D7 61 JSR $61D7Das ist nach dem Umbenennen-Dialog. Da wird dann bei $7129 curType abgefragt.
bei NativeMode wird dann der Code ab $7130 ausgeführt. Die Routine bei $470a baut den Bildschirm neu auf, alle Fenster sind jetzt aktualisiert.
Nach dem Rücksprung aus dem Unterprogramm $470a steht bei $7133 aber $00-Code -> PANIC!
Code>C:7133 00 00 00 00 00 00 00 41 00 00 00 00 00 00 00 00 00 00 00 00 .......A............ >C:7147 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 42 00 00 .................B.. >C:715b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .................... >C:716f 00 00 00 00 00 00 00 43 00 00 00 00 00 00 00 00 00 00 00 00 .......C............ >C:7183 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 44 00 00 .................D.. >C:7197 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .................... >C:71ab 00 00 00 00 00 00 00 45 00 00 00 00 00 00 00 00 00 00 00 00 .......E............ >C:71bf 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 46 00 00 .................F.. >C:71d3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .................... >C:71e7 00 00 00 00 00 00 00 47 00 00 00 00 00 00 00 00 00 00 00 00 .......G............Sieht so aus als wird beim Aufbauen der Fenster der Bereich mit den Dateinamen innerhalb des Fensters überschrieben. Nach der Rückkehr aus $470a ist das vorherige Programm dann "weg"...
Habe mir das Problem vorhin mal näher angesehen. Dieses jsr ist einfach nur falsch, denn mit jmp funktioniert es an dieser Stelle ohne Probleme. Vermutlich habe ich mich bei dieser Änderung damals einfach nur verschieben![]()
Pusti64
habe ich mich bei dieser Änderung damals einfach nur verschieben
Kein Problem. Passiert.
Ich habe das auch nur durch Zufall entdeckt. Normalerweise nutze ich den Text-Modus nicht. Ich bin ja immer noch dabei, meine HD auf SD2IEC zu kopieren. Bei den 1541-Partitionen (überwiegend Sachen außerhalb Geos) sehen die Directories im Icon-Modus grauenvoll aus. Deshalb habe ich da mal auf Text-Modus umgeschaltet. Dann ist besser zu erkennen, das muß so sein oder Directory kaputt
.
Gruß
Werner
PS: ich nutze dafür das aktuelle geoConvert von darkvision. Das ist beim Schreiben eines D64 auf SD2IEC-Native sau schnell
.
Anbei die aktuelle Version V5.06.
Achtung diese benötigt MP128 ab V3.3 r6 !
- nach Rückkehr von einem Hilfsmittel (DeskAcc) wird der Dateizähler mit 0 angezeigt
- C= Shift X markiert bei Bedarf nur die erste Leiste im Lfw-Fenster
- Lässt man beim Kopieren bzw Verschieben die Maustaste länger gedrückt, erscheint keine weitere Dialogbox mehr. Eventuell vorhandene Dateien werden auf dem Ziellaufwerk ohne Abfrage überschrieben.
- Anzeige des aktuellen InputDriver
- Druckergrafik verändert
- wechselt man kurzfristig die Partition um eventuell eine andere Datei zu kopieren. Gelangt man hinterher per längerem Klick auf die untere Fensterleiste zur vorherigen Partition zurück und erspart sich somit den erneuten Aufruf der Part-Box.
- Es können jetzt bis zu 255 Dateien markiert, kopiert und verschoben werden.
Achtung DT kann nur mit maximal 255 Dateien arbeiten! Daher z.B. beim Dublizieren auf die Gesamtzahl der Dateien achten.
- Außerdem sind eine Reihe von RAM, SD2IEC und CMD-HD Lfw-Grafiken dazugekommen. Wer also zum Beispiel ein MO-Laufwerk in seiner CMD-HD werkeln lässt, bekommt das nun auch grafisch angezeigt.
Pusti64
Hallo Pusti64,
Danke für Deine neue Version.![]()
Ich habe unter GTKVice 3.3 gerade das neue MP3 128 (101219) installiert. Installation ohne Probleme (TD128 171019 aktiv).
Neuen TD128 141219 kopiert und alles neu gestartet. Leider werden jetzt die Laufwerk Icons A bis C defekt angezeigt (siehe Hardcopy).
Nach zurückinstallieren des TD 128 171019, werden die Icons wieder richtig angezeigt.
LW A -->1581
LW B -->1581
LW C --> FD4
LW D -->1541
Bei Anklicken der LW, wird allerdings alles richtig geöffnet, scheint also erstmal nur die Icon zu betreffen. Weiter habe ich noch nichts getestet.
Bleibe weiter am Ball.![]()
Bitte melde dich an, um diesen Anhang zu sehen.
Gruß Jojo
Neuen TD128 141219 kopiert und alles neu gestartet. Leider werden jetzt die Laufwerk Icons A bis C defekt angezeigt (siehe Hardcopy).
Bei mir ist das nur ein 1581-Laufwerk. Eine 1571 wird korrekt angezeigt. RAM81 auch OK.
Wenn ich RealDrvType auf $23 setze wird HD81-Icon angezeigt. Vermutlich ist der Zeiger auf das Icon einer echten 1581 nicht korrekt.
Pusti64 : Kann es sein das ab $7768 im i_MoveData Befehl falsche Werte stehen?
Da wird ein i_MoveData verwendet, wenn es kein SD2IEC ist:
Im Gegensatz dazu wenn es ein SD2IEC ist:
Wenn ich es richtig sehe liegen ab $778d die Daten für das 1581-Icon. Ändere ich den i_MoveData für das 1581-Icon wie folgt ab:
Dann kommt das 1581-Icon wie es soll.
P.S. Was man auf JoJos Screenshot auch sieht: Rechts unten scheint das Drucker-Icon verschoben, daher passen die Farben nicht mehr so ganz.
P.S. Was man auf JoJos Screenshot auch sieht: Rechts unten scheint das Drucker-Icon verschoben, daher passen die Farben nicht mehr so ganz.
Also das"verschobene" Drucker-Icon kann ich am echten C128DCR nicht nachvollziehen. Scheint an VICE zu liegen. Welche GTK3-Version genau wird da eingesetzt?
Dafür klappt jetzt der Wechsel von Drucker- und Eingabe-Treiber über kurzen/langen Klick auf das Symbol.
Mehr, wenn ich Zeit hatte, etwas zu probieren....
Gruß
Werner
PS:
Außerdem sind eine Reihe von RAM, SD2IEC und CMD-HD Lfw-Grafiken dazugekommen. Wer also zum Beispiel ein MO-Laufwerk in seiner CMD-HD werkeln lässt, bekommt das nun auch grafisch angezeigt.
Speziell bei HD sehe ich bei HD-Nat keinen Unterschied. Das HD81-Symbol ist geringfügig anders (die "81"). Aber woran sehe ich, dass in meiner HD ein MO-Laufwerk steckt?
Also das"verschobene" Drucker-Icon kann ich am echten C128DCR nicht nachvollziehen. Scheint an VICE zu liegen. Welche GTK3-Version genau wird da eingesetzt
Gar kein GTK3...
Bitte melde dich an, um diesen Anhang zu sehen.
Das Icon wurde verschoben um mehr Platz für die Anzeige des Maustreibers zu erhalten. Und es wurde auch verändert... das hat sicher nichts mit VICE zu tun ![]()
Gibts im VDC-Modus auch die 8x8 Pixel Farbkacheln? Falls ja, scheint so als ob die Lage des Druckericons nicht mehr auf die Farbkacheln abgestimmt ist.
Ist aber nur "Kosmetik"... vielleicht Farbe für Drucker+Text gleichsetzen? Und von vorne herein in schwarz statt in grau?
Gibts im VDC-Modus auch die 8x8 Pixel Farbkacheln?
TD 128 arbeitet mit einer Auflösung von 640x200 und Farbe 8x2 Pixel.
Ich kann den "Versatz" jetzt auch sehen, aber nur, wenn ich die Farb-Einstellungen geändert habe. Bei "Standard" tritt das nicht auf. Bei mir ist für die Laufwerksleiste immer die Standardfarbe aktiv.
Gruß
Werner
TD 128 arbeitet mit einer Auflösung von 640x200 und Farbe 8x2 Pixel.
Ich kann den "Versatz" jetzt auch sehen, aber nur, wenn ich die Farb-Einstellungen geändert habe. Bei "Standard" tritt das nicht auf. Bei mir ist für die Laufwerksleiste immer die Standardfarbe aktiv.
Was ist denn die Standardfarbe? Ich hab den TD128 gestartet nach dem booten von MP128... keine Änderungen an den Farben. Für mich sah das schon immer so hässlich grün aus. Das war doch beim TD64 nicht anders?
Wenn ich "Farben ändern" auswähle, auf "Standard" klicke und dann den Drucker anwähle sieht das so aus:
Bitte melde dich an, um diesen Anhang zu sehen.
Liegt an der Position des Farbrechtecks...
Gar kein GTK3...
Da meinte ich Juergen Johannes, der mit GTK3-Vice probiert hat....
Ich habe diese Version momentan nicht im Einsatz, weil zu viele Probleme und weil es keine 32bit nightly builds (pokefinder) mehr gibt. Aber in Kürze wird es wohl eine neue "offizielle Version" geben.....
Welche Farbe das genau ist, kann ich so aus dem Stegreif nicht sagen. An meinem C128DCR ist die Farbe dort ein dunkleres cyan (wie der Rest der Laufwerksleiste). Klicke mal weiter bis die Farbe dem entspricht. Dann ist der Versatz nicht zu sehen
.
Liegt an der Position des Farbrechtecks...
Ja. Und weil Pusti64 hier wohl auch auf Standard ist, ist ihm das wohl nicht augefallen
. Aber ist auch nicht ganz so wichtig, da nur Kosmetik.
Wichtiger sind zunächst die anderen neuen/geänderten Funktionen zu testen .....
Gruß
Werner
PS: und das Ganze könnte auch noch von den auf dem Boot-Laufwerk vorhandenen Dateien "Pad Color Pref" und "TopDesk.win" abhängen....
Ich habe jetzt den TD128 unter WinVice (Version von markusC64 vom August, siehe hier : Bitte melde dich an, um diesen Link zu sehen. ) probiert. Da ist der Versatz auch sofort zu sehen... Also ist VICE auf jeden Fall nicht ganz unbeteiligt ....
nochmal PS
:
Das Umbenennen von Dateien im Text-Modus funktioniert jetzt auch wieder ohne Absturz.
Ich habe jetzt den TD128 unter WinVice (Version von markusC64 vom August, siehe hier : Bitte melde dich an, um diesen Link zu sehen. ) probiert. Da ist der Versatz auch sofort zu sehen... Also ist VICE auf jeden Fall nicht ganz unbeteiligt ....
Schon seltsam... ab $15b8 steht der Einsprung zu DirectColor, der von verschiedenen Routinen verwendet wird. Da wird auch das Drucker-Icon eingefärbt.
BreakPoint gesetzt... und bei jedem Aufruf die Register r2L bis r4 geprüft, die enthalten ja die Koordinaten des Rechtecks. Ändere ich r2L/r2H vor dem setzen der Farbe für den Drucker um 2Pixel (von $a6/$bd nach $a4/$bb) nach oben, dann passt alles. Das Icon wird ja auch bei y=$a4 positioniert (die Tabelle dazu liegt bei $3887). Ändere ich das wieder auf $a6, dann ist auch alles wieder OK.
Die Position des Farbrechtecks wird bei $15ac gesetzt... wüsste jetzt nicht wie VICE hier Einfluss auf absolut gesetzte Werte haben soll ![]()
Die Position des Farbrechtecks wird bei $15ac gesetzt... wüsste jetzt nicht wie VICE hier Einfluss auf absolut gesetzte Werte haben soll
Und warum sehe ich den Versatz am echten C128DCR (im Gegensatz zu VICE) nicht sofort? Ich muss hier erst die Farben ändern um das Problem zu sehen.....
Und warum sehe ich den Versatz am echten C128DCR (im Gegensatz zu VICE) nicht sofort? Ich muss hier erst die Farben ändern um das Problem zu sehen.....
Hast Du andere Voreinstellungen für die Farben? Oder setzt der VDC am echten C128 die Farben evtl. anders als VICE im 2Pixel-Modus?
Fakt ist das hier das Icon in der DoIcons-Tabelle um 2Pixel nach oben versetzt wurde. Die Icon-Tabelle in der alten Version hat die Y-Position noch bei $a6. Die Position des Farbrechtecks wurde aber noch nicht angepasst, die setzt das Rechteck nach wie vor bei Y=$a6. Anpassen der Y-Position und alles passt wieder zusammen. Sofern das am echten 128er nicht wieder andere Probleme macht.
Ändere ich in der alten Version die Position in der DoIcons-Tabelle auf $a4, dann hab ich dort auch die "Farbfehler".
Der VDC-ColorMode steht in MegaPatch128 bei $04, die Kommentare in ColorBox verwirren mich aber etwas:
ldx vdcClrMode ;welcher VDC Farbmodus?
cpx #3
beq :3 ;8x4 Pixel
cpx #4
beq :4 ;8x2Pixel
::40 lsr ;geteilt durch 8 (8x8 Pixel)
::3 lsr ;geteilt durch 4 (8x4 Pixel)
::4 lsr ;geteilt durch 2 (8x2 Pixel)
sta r2L ;in r2L ist Y-Anfang
Hat es evtl. damit was zu tun? Verhalten sich VICE und der echte C128 hier anders?
P.S. Bei $04 wird der Y-Wert nur nur 2 geteilt... wären das nicht 4 Pixel in der Höhe? Evtl. setzt der 128er hier auch nur 4Pixel, VICE ist da genauer (fälschlicherweise?) und setzt die Farben auf 2Pixel genau. Daher fällt hier das nicht angepasst Farbrechteck auch auf...
Hast Du andere Voreinstellungen für die Farben? Oder setzt der VDC am echten C128 die Farben evtl. anders als VICE
1. eigentlich nicht
2. aber VICE scheint da im VDC irgendwie anders zu arbeiten. Am C128 z.B. ist das Druckersymbol eher schwarz als grau wie in VICE. Auch die Fensterumrandung (in den Farbeinstellungen) weicht ab. Am C128 sind alle 4 Fenster-Umrandungen schwarz (Standard) in VICE Fenster 1 und 2 grau, Fenster 3 und 4 schwarz.
Habe jetzt mal meine "Pad Color Pref" und "TopDesk.win" vom C128 auf die MP3-128-Bootdisk (FD1581) für VICE kopiert. Keine Änderung. In Vice sieht man den Versatz sofort, am C128 nur wenn ich die Farbeinstellungen verändere. Scheint also in VICE irgendwas mit der VDC-Steuerung nicht dem original C128 zu entsprechen....
Aber ich weiss, dass da im Bezug auf VDC in letzter Zeit in VICE was geändert wurde. Ob das was ändert, kann ich leider noch nicht sagen. 64bit VICE kommt mir vorerst nicht auf die Festplatte
, habe zumindest vorerst Win 10 32 bit am Laufen....
Gruß
Werner
Hm, vielleicht ein Grund, nochmal zu schauen, ob es VDC Korekturen im VICE gibt, die sich in 3.2 rückportieren lassen... Wenn ich mal datzu komme. Wobei es durchaus hilfreich wäre zu wissen, ob im GTKVICE 3.3 die Probleme auch da sind. Wenn ja, lohnt sich Rückportieren ja gar nicht.
Scheint also ein VICE/VDC-Problem zu sein, wobei das nur auf Grund einer fehlerhaften Y-Position des Farbrechtecks sichtbar wird. Bin mal gespannt was passiert wenn Pusti64 die Y-Posititon des Farbrechtecks and die Y-Position des Drucker-Icons anpasst.
Da $a4 durch 4 und 2 teilbar ist sollte das funktionieren. $a6 ist nur durch 2 teilbar, daher scheint der 128er das anders zu handeln als VICE. Evtl. runder der 128er auf und VICE rundet ab.