Wie testet ihr selbst programmierte Änderungen am Kernal?

  • Wie testet ihr selbst programmierte Änderungen am Kernal?

    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
  • 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
  • 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.
    ---
    Meine Github-Projekte: github.com/markusC64/
    1541 Ultimate II Firmware Releases: github.com/markusC64/1541ultimate2/releases
    1541 Ultimate II Update instructions: github.com/markusC64/1541ultimate2/wiki
  • USB-Stick zwischen PC und 1541U swappen wäre mein persönlicher Favorit.
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────
  • 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
  • Quellcode

    1. !to "softkernal.prg",cbm
    2. *=$0801
    3. !by $0c,$08,$0a,$00,$9e,$32,$30,$36,$34,$00,$00,$00,$00
    4. ; SYS 2064 / $0810
    5. *=$0810
    6. sei
    7. lda #<Kernal
    8. sta $fa
    9. lda #>Kernal
    10. sta $fb
    11. lda #$00
    12. sta $fc
    13. sta $fe
    14. lda #$a0
    15. sta $fd
    16. lda #$e0
    17. sta $ff
    18. ldx #$20
    19. copyloop:
    20. ldy #$00
    21. copy:
    22. lda ($fa),y
    23. sta ($fe),y ; copy kernal
    24. lda ($fc),y
    25. sta ($fc),y ; copy basic
    26. iny
    27. bne copy
    28. inc $fb
    29. inc $fd
    30. inc $ff
    31. dex
    32. bne copyloop
    33. lda #$35
    34. sta $01
    35. sta $fdd6 ; Patch NMI Restore
    36. cli
    37. jmp ($a000)
    38. *=$0900
    39. Kernal:
    40. !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.
    10 SIN
    20 GOTO HELL

    www.SX-64.de
  • 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.
  • 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.
    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von cbmhardware ()

  • tulan schrieb:

    @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...


    cbmhardware schrieb:

    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...



    cbmhardware schrieb:

    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:


    worldofspectrum.org/z88forever/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...


    GI-Joe schrieb:

    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

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Freak ()

  • 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.


    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von cbmhardware ()

  • @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
  • Freak schrieb:

    Hier nochmal ein Bild vom Entwurf:
    yo, das sieht sehr gut aus und ist vor allem schön scriptfähig unter Linux via xlink :thumbsup:
    Ich fang hier schon gerade wieder an zu sabbern :P
    Sehr interessante Geschichte ! Was für einen RAM-IC hatst nun genommen ? den IDT 7005 oder einen normalen SRAM ?
  • 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.
    Bilder
    • flashkernal3.png

      67,92 kB, 1.200×510, 13 mal angesehen
    If we're evil or divine - we're the last in line. - Ronnie James Dio (1984) -
  • 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