Wie testet ihr selbst programmierte Änderungen am Kernal?

Freak · 14. Dezember 2016

Hallo,

ich habe demnächst vor, selbst Änderungen am Kernal-ROM vorzunehmen und überlege jetzt, wie ich diese nach dem Assemblieren möglichst unkompliziert testen kann.

Am einfachsten wäre ja ein Modul im Kernal-Sockel (eine Art Eprom-Emulator) oder am Expansion-Port, welches ich seriell (RS232, USB oder Netzwerk) vom Programmier-PC beschreiben kann. Aber ich glaube fast, sowas gibt es (noch) nicht.

Deswegen mal meine Frage an die Kernal-Programmierer:

Wie testet ihr euren geänderten Kernal in der Realität?

Ein Einspielen in einen C64-Emulator (z.B. VICE) würde insofern nicht helfen, da ich am C64 externe Hardware angeschlossen habe, die ich zum Testen ebenfalls brauche und die in der Emulation natürlich nicht vorhanden ist.

Ich freue mich auf konstruktive Antworten!

Gruß,
Thomas

tulan · 14. Dezember 2016

Also C64 Kernal habe ich noch nicht selber umprogrammiert, aber lange Zeit an einer embedded Z80 Hardware gearbeitet.
Am PC mit Crosscompiler entwickelt und dann per EPROM Simulator (PEPS III) auf der Zielplattform getestet.
Sollte für C64 Kernal mit passenden Adapter wohl auch funktionieren.

PS: PEPS III gibt es aber fast nicht mehr zu kaufen

tulan · 14. Dezember 2016

http://www.conitec.net/german/pricing.php
ganz unten!

markusC64 · 14. Dezember 2016

Wenn ich es machen würde (ist mir bisher erspart geblieben), so würde ich die geänderte Datei am PC erstellen, per ftp zur 1541 U2(+) des C64 schicken und dort die Kernal-Replacementfunktion der Ultimate nutzen.

Hexworx · 14. Dezember 2016

Einfach ins RAM unter'n KERNAL packen und umschalten reicht nicht erst mal?

TheRyk · 14. Dezember 2016

Wenn du ein EasyFlash3 hast:
M für EasyProg K für KERNAL to Flash, einen Slot (1-8) auswählen
Dann kannst du das geflashte KERNAL ROM von EasyFlash aus mounten
http://www.c64-wiki.de/index.php/EF3#Men.C3.BCfunktionen

Claus · 14. Dezember 2016

USB-Stick zwischen PC und 1541U swappen wäre mein persönlicher Favorit.

Freak · 14. Dezember 2016

Ein EasyFlash3 habe ich leider nicht.

Und ehrlich gesagt, wäre mir eine RAM-basierte Lösung irgendwie lieber. Ich hatte auch mal einen EProm-Emulator (für den Parallelport (von Elektor)), der ist aber irgendwo verschollen und nicht mehr auffindbar.

Ich werde also _erstmal_ über FTP was an die Ultimate schicken. So auf USB-Stick umstöpseln habe ich auch keine Lust. Das sollte schon eine feste Installation sein...

Danke für eure Kommentare!

Gruß,
Thomas

KiWi · 15. Dezember 2016

Code

!to "softkernal.prg",cbm
*=$0801
!by $0c,$08,$0a,$00,$9e,$32,$30,$36,$34,$00,$00,$00,$00
; SYS 2064 / $0810
*=$0810
sei
lda #<Kernal
sta $fa
lda #>Kernal
sta $fb
lda #$00
sta $fc
sta $fe
lda #$a0
sta $fd
lda #$e0
sta $ff
ldx #$20
copyloop:
ldy #$00
copy:
lda ($fa),y
sta ($fe),y ; copy kernal
lda ($fc),y
sta ($fc),y ; copy basic
iny
bne copy
inc $fb
inc $fd
inc $ff
dex
bne copyloop
lda #$35
sta $01
sta $fdd6 ; Patch NMI Restore
cli
jmp ($a000)
*=$0900
Kernal:
!bin "meinkernal.bin"

Alles anzeigen

So mache ich das beim Servant64. Darfst hal nix höher als $A000 in den Speicher laden, aber zum Testen von Hardware funktioniert das Einwandfrei.

mc71 · 15. Dezember 2016

Eprom brennen, in Sockel stecken, testen. Rinse and repeat. Die gesammelten 'verschossenen' Eproms alle paar Tage mal am Stück löschen. Alternativ bei kleinen Änderungen: Kernal ins RAM laden, mit Monitor-Programm patchjen bis Ergebnis OK, abspeichern und brennen. Dabei beachten, daß die originale SAVE-Routne das letzte Byte ($FFFF) nicht speichern kann.

Klar ist ein Eprom-Simulator eleganter; ich bin mir aber nichtmal sicher, ob CBM selbst sowas (in der Profiversion) schweineteures rumstehen hatte... die absolute Sensation war ja dann das Entwicklertool von Berkeley Softworks (GEOS), das die Programmdaten via DMA in den Testrechner geschoben hat. Mit bis zu 1 MB pro Sekunde.

cbmhardware · 15. Dezember 2016

Vielleicht reicht für den ersten Test ein "Kernal Loader" : http://csdb.dk/release/?id=94352 ?

Wenn das dann funktioniert, würde ich auch auf Eprom brennen.

GI-Joe · 15. Dezember 2016

Hey, Freak ist ein Hardwaremensch, der idealerweise eine crossdev-script-taugtliche Lösung zum Kernal entwickeln/debuggen sucht, ggf. mit entspr. Hardware.
Hab ich Recht, Thomas ??

cbmhardware · 15. Dezember 2016

Es gäbe eine Lösung mit einem etwas schwieriger beschaffbaren Bauteil: IDT 7005 bei 8Kx8. Das ist ein Dualported SRAM, es sind also alle Leitungen doppelt vorhanden.
Eine Seite auf eine umschaltbare Kernal-Platine Original/SRAM und an die andere ein Interface zum Beschreiben. Wenn der C64 zum Beschreiben reicht: Leitungen vom Userport mit 74ls574 multiplexen, anschließen und Software dafür schreiben.

Edit: von der PLCC-Version habe ich noch wenige neue in Stange da. Könnte einen abgeben.

tulan · 15. Dezember 2016

@Freak Ich habe noch einen PEPS III für Parallelport rumliegen, könnte ich dir via Postweg zukommen lassen, aber nur geborgt.

Freak · 15. Dezember 2016

Zitat von tulan

@Freak Ich habe noch einen PEPS III für Parallelport rumliegen, könnte ich dir via Postweg zukommen lassen, aber nur geborgt.

@tulan: Vielen Dank, aber ich habe keinen Parallelport mehr. Sonst hätte ich meinen Emulator aus der Elektor wohl nicht entsorgt...

Die Lösung von @KiWi wäre erstmal eine Alternative. Da könnte man vom PC über XLink das File rüberschicken und so testen. Werde ich mal drüber nachdenken...

Zitat von cbmhardware

Es gäbe eine Lösung mit einem etwas schwieriger beschaffbaren Bauteil: IDT 7005 bei 8Kx8. Das ist ein Dualported SRAM, es sind also alle Leitungen doppelt vorhanden.
Eine Seite auf eine umschaltbare Kernal-Platine Original/SRAM und an die andere ein Interface zum Beschreiben. Wenn der C64 zum Beschreiben reicht: Leitungen vom Userport mit 74ls574 multiplexen, anschließen und Software dafür schreiben.

Edit: von der PLCC-Version habe ich noch wenige neue in Stange da. Könnte einen abgeben.

@cbmhardware: Ja, da fange ich ja schon das Sabbern an! Ich hatte mir das Datenblatt schon vor ein paar Tagen angeschaut und bin nur über den horrenden Preis gestolpert und über diesen Pin (dieses Flag), das gesetzt wird, wenn von beiden Seiten auf die gleiche Adresse zugegriffen wird. Ich habe das dann nicht weiter verfolgt. Aber so etwas wäre eine nahezu ideale Lösung: Das Dual-Port-RAM, einen Atmel und einen USB-Port. Dann (für mich einfacherweise, da von mir in Assembler nachprogrammiert) das XLink-Protokoll implementieren und mit "Xlink load kernal.rom" das Kernal übertragen... Wenn doch die PLCC-Version nicht so groß wäre...

Zitat von cbmhardware

Edit: von der PLCC-Version habe ich noch wenige neue in Stange da. Könnte einen abgeben.

Vielen Dank! Da komme ich vielleicht nochmal drauf zurück!

Ich habe von meinem alten Elektor-Emulator den Schaltplan hier gefunden:

http://www.worldofspectrum.org…r/eprom-emulator/fig3.jpg
Jetzt stelle ich mir immer noch den Atmel mit USB vor, plus drei HCT541 als Adress- und Datentreiber, sowie zwei HCT590 als Adresszähler. Und ein 8K- (oder 32k-) RAM.
Wenn man dann die kleinstmögliche Bauform nimmt, dann sollte das auf eine DIP24-Fläche passen... Man könnte im Atmel 3-4 Kernals permanent speichern und dann noch über USB weitere zum Testen übertragen...

Oh mann, zu viele Projekte und viel zu wenig Zeit...

Zitat von GI-Joe

Hey, Freak ist ein Hardwaremensch, der idealerweise eine crossdev-script-taugtliche Lösung zum Kernal entwickeln/debuggen sucht, ggf. mit entspr. Hardware.
Hab ich Recht, Thomas ??

Oh ja, da hast Du sowas von Recht. Freak ist ein Hardwaremensch!

Gruß,
Thomas

cbmhardware · 26. Dezember 2016

Ich fand die Idee doch so interessant, dass ich mal ein bisschen mit Eagle entworfen habe. Ist nur das grobe Prinzip für einen C64-2 (16kb ROM), im System beschreibbar und mit Hilfe von $de00.

Der Speicherchip kann ein 32kB E²Prom oder Flash sein. A0-A5 liegen direkt an und es können auf $de00 64Byte-Pages geschrieben werden. Dies oberen Adressleitungen werden beim Flash-Mode vom Bus isoliert und können über §dec0 angelegt werden. Zusätzlich muss natürlich das originale Kernal selektiert werden, damit man sich das nicht vor der Nase wegflasht. A14 ist umschaltbar für zwei Bänke.
Der freie halbe 139 wird dann noch zum Schreiben auf $de00 verwendet. Ist alles noch nicht ausgereift, aber vielleicht erkennt man den Ansatz ? - Ich brüte noch daran ...

Können natürlich auch Denkfehler drin sein .. ?

Edit: Ein kleiner Fehler. Die Leitung vom Dip-Switch (2) muss mit einem Gatter vom 7400 verbunden werden, ansonsten wird /CE vom C64 auf festen Pegel gesetzt.

Edit2: eine etwas nachgebesserte Version. $de00 wurde vom anderen halben 139er erzeugt und die andere Hälfte übernimmt jetzt die Kernal-Wahl.

Freak · 26. Dezember 2016

@cbmhardware: Das ist aber nett!

Ich wollte ja zuerst die Softwareversion nehmen und im RAM testen. Allerdings will ich aber auch auf RAM unterm Kernal zugreifen und dann bräuchte ich schon einen eigenen Speicher.

Ich habe daraufhin die Schaltung meines alten Eprom-Emulators genommen und die ein wenig umgestrickt, so dass ein AT90USB162 (oder ATmega32U2) den Speicher beschreiben kann.
Dass kann z.B. gleich nach dem Einschalten passieren und dient dann als Kernal-Ersatz. Solange die CPU den Speicher beschreibt, kann die CPU auch die Reset-Leitung auf Null ziehen...

Über den USB-Anschluss (Mitte unten) und dem XLINK-Protokoll von Henning kann man dann einen neuen Kernal laden (c:\xlink load kernal.rom). Ich habe mir die Xlink-Firmware in AVR-Assembler nachprogrammiert und kann somit die notwendigen Änderungen für ein Beschreiben des Emulator-RAMs relativ schnell einpflegen.

Ich habe inzwischen "auf die Schnelle" eine Platine entworfen (Hau-Ruck-Verfahren, Hauptsache alle Verbindungen sind da. Schön ist was anderes...) und Mein China-PCB-Hersteller Elecrow hat sie auch schon gefertigt und losgeschickt. Das dauert jetzt noch zwei Wochen bis die Platinen hier sind. Ich mache inzwischen erstmal Urlaub und im neuen Jahr schau ich mal, was ich auf die Reihe bekomme.

Hier nochmal ein Bild vom Entwurf:

In der Mitte kann von unten entweder ein 24-poliger Adaptersockel für den Brotkasten oder ein 28-poliger Adaptersockel für die Assy 250469 eingelötet werden.

Gruß,
Thomas

GI-Joe · 26. Dezember 2016

Zitat von Freak

Hier nochmal ein Bild vom Entwurf:

yo, das sieht sehr gut aus und ist vor allem schön scriptfähig unter Linux via xlink
Ich fang hier schon gerade wieder an zu sabbern
Sehr interessante Geschichte ! Was für einen RAM-IC hatst nun genommen ? den IDT 7005 oder einen normalen SRAM ?

cbmhardware · 26. Dezember 2016

Freak: Sieht interessant aus, da bin ich auch mal gespannt. Mit dem AVR hast Du natürlich den Vorteil, dass der gleich alle Leitungen passend schalten kann, wenn Daten kommen.

Ist für mich ein bisschen Denksport und die Schaltung erst mal so hingeklatscht. Ich hatte jetzt erst mal so geplant, dass es möglichst ins System integriert wird, damit nicht allzu viele Leitungen geschaltet werden müssen. Dann muss man natürlich auch den C64 zum Beschreiben verwenden.

Im Anhang baumeln letzte Korrekturen.

Freak · 26. Dezember 2016

Standard-32k-SRAM 62256 ist drauf. Der weiter oben verlinkte Schaltplan des Elektor-Eprom-Emulator spiegelt recht gut die Schaltung wider. Ich habe nur die Steuersignale auf die AVR-CPU gelegt.

Geplant ist auch, dass man sich beim Einschalten eins von acht ROMs auswählen kann, welches die CPU dann ins RAM kopiert.

Ich bilde mir im Moment auch noch ein, dass man alles in etwa auf die Größe eines Adaptersockels verkleinern könnte. Dann ist die Platine aber auch sechslagig und dass wird alles zu teuer...

Gruß,
Thomas

Tags