Bedarf für eine neue C64-Diagnose Platine?

Zitat von detlef

Das Verlängern der Warteschleife nach dem Portumschalten im Diagnose-EPROM hat nichts gebracht. Da ist ja - wie gesagt - auch schon eine Warteschleife drin gewesen.

Vielleicht kann mir mal jemand erklären, warum das BASIC-Programm mit REM-Zeile 25 vernüftige Werte liefert und ohne nicht.

Code

1. 10 POKE 56322,224 : REM Keyboard off
2. 20 POKE 56320,128 : REM Select port 2
3. 25 REM <- mit Zeile 25 funktioniert es, ohne nicht
4. 30 PRINT PEEK(54297), PEEK(54298)
5. 40 POKE 56320,64 : REM Select port 1
6. 50 PRINT PEEK(54297), PEEK(54298)
7. 60 POKE 56322,255 : REM Keyboard on

IIRC wird die Widerstandsmessung im SID über das (Ent-?)Laden eines Kondensators gemacht, die benötigte Zeit bis zum Erreichen einer bestimmten Schaltschwelle ist proportional zum Widerstand. Eine Änderung der Portkonfiguration verfälscht also auf jeden Fall die aktuell laufende Messung, erst die darauf folgende liefert wieder verlässliche Daten. Auch diese Folgemessung muss aber erst komplett abgewartet werden. Ich habe allerdings keine Ahnung, in welcher Größenordnung diese Zeitintervalle liegen.

Beim Thema Portkonfiguration wäre noch interessant, welcher Zustand nach dem Einschalten vorliegt: Port 1 aktiv? Port 1 aktiv? Beide parallel? Oder keiner von beiden?

Zitat von detlef

Aber als nächstes werde ich mal das Diagnose-EPROM patchen, so dass die Analogwerte angezeigt werden.

Zitat von GMP

Wie darf ich das verstehen? Man kann die Werte dann später auf dem Bildschirm sehen? Wenn ja, wäre das spitze.

Zitat von detlef

So hatte ich das vor. Die Anzeige als zweistelliger Hex-Wert sollte nicht so kompliziert sein. Am Ende des EPROM-Bereiches ist noch ausreichend Platz für solche "Erweiterungen".

bei gepatchten versionen, bitte irgendwo die prüfsumme des diag-roms automatisch errechnen und mit anzeigen lassen.

so haben wir es gemacht, sonst verliert man die übersicht und man kann sofort die verschiedenen versionen unterscheiden.
auch falls ein eprom-bit später (durchs alter oder unsachgemäßes handling) kippt.

gruß
helmut

Zitat von detlef

So hatte ich das vor. Die Anzeige als zweistelliger Hex-Wert sollte nicht so kompliziert sein. Am Ende des EPROM-Bereiches ist noch ausreichend Platz für solche "Erweiterungen".

Das wäre natürlich klasse. Du mußt dann aber das "C64 Diagnostic ROM-Rev. 586220++" entsprechend patchen, ist dir klar oder? Soll ja nicht mehr viel platz vorhanden sein.

Zitat von GMP

@detlef ??? Du hast da was vergessen.

Was denn?

Zitat von GMP

Laut Detlefs Info anscheinend doch. Hoffentlich meint er nicht den freien Platz am Ende des gesamten ROM-Files.

Ja, klar!

Aber ernsthaft: Da sind noch rund 700 Byte am Ende des 8KByte großen Bereichs des Diagnose-Programms frei. Da steht Müll drin, der aber laut meinem Unassembler nicht genutzt wird.
Zwischendrin gibt es auch einige kleinere, nicht mehr genutze Abschnitte - da ist schon fleiißg im Code rumgepatcht worden. War das Commodore? Um die zu nutzen müsste ich aber etwas mehr Zeit investieren.

Ich mache jetzt erst mal eine quick'n dirty Version, um das Problem mit dem Control Port Fehler zu lokalisieren. Bevor ich eine gepatchte Version veröffentliche, würde ich die erst mal zum Testen verteilen und dann hier im Forum zu Verfügung stellen.

Ich habe inzwischen herausgefunden, dass das Lesen und Testen der 4 Analogwerte 5 mal wiederholt wird. Wenn nur ein gelesener Wert ausserhalb des erlaubten Bereichs liegt, wird das als "BAD" gewertet. Das ist ganz schön pingelig. Es gibt auch einen Zähler, beim wievielten Versuch es fehltgeschlagen ist. Das sind alles Informationen, die nützlich wären, die aber nicht ausgegeben werden.

Zitat von detlef

Aber ernsthaft: Da sind noch rund 700 Byte am Ende des 8KByte großen Bereichs des Diagnose-Programms frei. Da steht Müll drin, der aber laut meinem Unassembler nicht genutzt wird.

Mist. In dem vermeintlich ungenutzen Bereich am Ende des ROMs stehen die Kernal- und BASIC-Versionen drin.
Das wird wohl indirekt adressiert (es gibt keinen direkten Verweis). Das Disassembler-Listing, das ich als Referenz benutzt habe, hat den Bereich einfach unterschlagen.

Das macht die Sache etwas komplizierter aber nicht unmöglich. Ich arbeite dran.

EDIT durch TRW: 3 Beiträge zusammengefasst. Bitte soweit möglich Mehrfachpostings vermeiden und lieber eigene Beiträge ergänzen! Danke!

Zitat von detlef

EDIT durch TRW: 3 Beiträge zusammengefasst. Bitte soweit möglich Mehrfachpostings vermeiden und lieber eigene Beiträge ergänzen! Danke!

Was soll denn das jetzt?
Ich bin erst mal raus hier.

Zitat von detlef

Was soll denn das jetzt?

Das könnte ich dich auch fragen. Wo ist dein Problem? Ich habe lediglich 3 Postings von dir in einem zusammengefasst und darauf hingewiesen, dass du bitte (wie jeder andere auch) soweit möglich dein zuletzt geschriebenen Beitrag editierst und die neuen Informationen dort hinzufügst und nicht ein neues Posting verfasst.

Keine Information ist verloren gegangen. Also kein Grund hier beleidigt zu sein!

Zitat von detlef

Ich bin erst mal raus hier.

Bitte nicht. Es ist doch kein Schaden entstanden und wir wollen ja nur ein gutes Stück Hardware gemeinsam noch besser machen.

Leider kann ich kein Assembler, habe jedoch ein altes und neues ROM und 2 Brotkästen zum Testen.

Zitat von Bobbel

Schau mal hier: CHECK64 - Neue EPROM-Zusammenstellung

Upps... Ich brauche das Etikett mit dem 1541 checker

Danke

So, jetzt gibt's was neues von meinem C64-DIAGNOSTIC-Projekt.

Ich hatte mich ja damit beschäft, weil mein CHECK64 einen Control Port Fehler meldetet. Ich habe daraufhin - wie angekündigt - die Diagnose-Routine so gepatcht, dass die gelesenen Analogwerte angezeigt werden. Damit konnte ich dann den Fehler sofort lokalisieren und beheben (ein Lötfehler auf der Platine).

Dabei habe ich mich eingehend mit der C64-DIAGNOSTIC befasst. Da ich bisher ziemlich wenig Ahnung von der C64-Hardware hatte, war das eine willkommene Gelegenheit, mich ein wenig einzuarbeiten. Ich habe inzwischen ein relozierbares Assembler-File erstellt und schon mal etwas optimiert um Platz für zukünftige Erweiterungen zu schaffen. Im Moment habe ich erst mal 450 Bytes freigeschaufelt (ohne irgendwelche Funktionen rauszuschmeissen). Da ist aber noch Potential für noch mal 600-1000 Bytes (der gsammte RAM-Test ist doppelt vorhanden).

Weil ich einiges geändert habe, möchte ich euch bitten, diese Version zu testen, ob sie noch korrekt und stabil funktioniert. Vor allem auf Geräten, die irgendwelche Fehler zeigen.
Ich hab nur im VICE und auf meinem intakten C64C getestet.

Wenn sich genügend Interessenten und Tester finden, dann können wir einen neuen Thread aufmachen und diskutieren, welche Erweiterungs- und Änderungswünsche es gibt.

Das angehängte EPROM-Image basierte auf der aktuellen Version CHECK64_v1.2_20170907. Ich habe nur C64-DIAGNOSTIC ausgetauscht (speicheroptimiert und experiemelle Anzeige der POT-Werte). Für Interessierte habe ich auch mal das Assembler-File dazugebackt. Das sieht aber noch etwas chaotisch aus.

Spontan fallen mir zwei Sachen ein die man Einbauen könnte wenn man sich weiterhin auf 8kb beschränken will ( Das ist ja ein CBM80 Rom und könnte auch genau so gut 16kb verwenden).

1. Umschreiben auf Kernal Replacement und den DEAD TEST vom 781220 in den Start hängen.

So könnte man zb defekte Kernal ROMs und Basics über die Checksumme diagnostizieren.

2. Optischer VIC Test um defekte VIC's mit Spritefehlern etc. zu Diagnostizieren. Der SID Test ist ja auch rein akustischer Natur, bis auf den Paddle Check kann via Hardware nichts diagnostiziert werden. Das gleiche gilt für den VIC.

Zitat von KiWi

1. Umschreiben auf Kernal Replacement und den DEAD TEST vom 781220 in den Start hängen.

Das ist doch schon mal ein interessanter Vorschlag. DEAD TEST + C64-DIAG zuammen in ein 16K Kernall-Replacement.
Geht das? Lässt sich die CHECK64-Platine so konfigurieren?

Zitat von GMP

Sollte möglich sein. Man startet im Ultimax-Mode für den Dead-Test und schaltet dann um für das C64-Diag.

Ok, dann werde ich mir mal bei Gelegenheit den DEAD TEST vornehmen.

Das Kernal replacement ist mit ein paar Zeilen erledigt:

*=$E000

jmp Start ; CBM80 durch Kernal-Start-Routine ersetzen

*=$FFFC
!word $E000 ; Kaltstart auf $E000 umbiegen
!word $E000

Achja, ich hatte die Quellcodes für's 64Studio dem Jani geschickt und auch auf sx-64.de veröffentlicht.

Würde es Dir etwas ausmachen wenn wir beim 64Studio als Assembler bleiben könnten / würden ? Für mich ist das so ne Supportsache, der Endurion hat viel Arbeit in das 64Studio gesteckt und ich fände es gut wenn mehr Forum64 User das auch Benutzen würden ...

Zitat von KiWi

Würde es Dir etwas ausmachen wenn wir beim 64Studio als Assembler bleiben könnten / würden ? Für mich ist das so ne Supportsache, der Endurion hat viel Arbeit in das 64Studio gesteckt und ich fände es gut wenn mehr Forum64 User das auch Benutzen würden ...

Auf 64Studio kann ich nicht wechseln, weil mein gesamtes Tooling auf meinen Assembler und den zugehörigen Unassembler ausgelegt ist. Das betrifft auch viele Sachen, die ich parallel für den PET mache. Da sind viele gängige C64-Tools nicht nutzbar.
Ich könnte den Assembler kompatibel zu 64Studio machen (die Schlüsselworte sind leicht anpassbar), aber unterstützt 64Studio sowas wie PROC/ENDPROC und lokale Labels?
Und kann ich, wie es für C64-Diag derzeit notwendig ist, einfach einen Adress-Offset für die Absolut-Adressen definieren? Ein Teil des C64-Diag-Codes wird ja ins RAM kopiert und dort ausgeführt (also an einer anderen Adresse ausgeführt).

Wir können diese Diskussion auch gerne in einen passenden Forenbereich verlagern.

EDIT: Ich habe gerade gefunden, dass der ACME die Befehle routine_start/routine_end und pseudopc kennt. Das entpricht in etwa meinem PROC/ENDPROC und OFFSET.
Weisst du, ob 64Studio den kompletten ACME Befehlsumfang unterstützt?

64Studio kann (glaube ich) auch ACME Befehle - wenn nicht: Sollten wir @Endurion mit ins Boot holen. Ist ja wichtig das jeder das Compilen/Assemblieren kann.

Mein 586220 Assembly läuft auf jeden Fall problemlos auf dem 64Studio.

Ich glaube allerdings ein Thread-Split ist hier jetzt angesagt da wir zu Off-Topic sind. Ansonsten gerne per PM weiter ..