MAME & Sage II

    MAME nicht, ab er simh.

    https://virtuallyfun.com/wordpress/category/simh/page/2/

    https://github.com/simh/simh
    Der kann aber nur CP/M booten, UCSD-Pascal und PDOS funktionieren

    nicht.

    DIsk Images und Eproms findet man z.B. hier:

    http://www.sageandstride.org/

    Es gibt Arbeit an der Stride-front.....

    http://bitsavers.informatik.uni-stuttgart.de/bits/Sage_and_Stride/

    Einmal editiert, zuletzt von ngc224 ()

    Zitat von e2k

    Irgendeine Idee, warum UCSD nicht funktioniert unter SIMH? Hat sich das jemand mal angeschaut?

    Das liegt dran, daß der Emulator für die 68k CPU einige Befehle noch nicht implementiert hat.

    (z.B. cmpm )


    linux-4232:/home/josef/emulators/simh-master # BIN/sage ucsd.sim


    Sage-II/IV 68k simulator V4.0-0 Current git commit id: 564ce2b3



    /home/josef/emulators/simh-master/ucsd.sim-4> set debug debug.log

    Debug output to "debug.log"

    Loading boot code from sage-ii.hex


    SAGE II Startup Test [1.2]


    RAM Size = 512K


    Booting from Floppy


    PC Breakpoint, PC: 00FE1AD6 (jmp (a0))

    sim> g


    UCSD p-System IV.1 Bootstrap


    Not yet implemented!, PC: 000006A8 (cmpm.b (a0)+,(a1)+)

    sim>


    localhost:/home/josef/emulators/simh-master/SAGE # fgrep -r 'STOP_IMPL' *

    i8251.c: return STOP_IMPL;

    i8251.c: return STOP_IMPL;

    i8255.c: return STOP_IMPL;

    i8259.c: return STOP_IMPL;

    m68k_cpu.c: return STOP_IMPL;

    m68k_cpu.c: rc = STOP_IMPL;

    m68k_cpu.c: rc = STOP_IMPL;

    m68k_cpu.c: rc = STOP_IMPL; break;

    m68k_cpu.c: rc = STOP_IMPL; break;

    m68k_cpu.c: rc = STOP_IMPL; break;

    m68k_cpu.c: rc = STOP_IMPL; break;

    m68k_cpu.c: rc = STOP_IMPL; break;

    m68k_cpu.c: rc = STOP_IMPL; break;

    m68k_cpu.c: rc = STOP_IMPL; break;

    m68k_cpu.c: case STOP_IMPL:

    m68k_cpu.h:#define STOP_IMPL 6 /* not yet implemented (should disappear) */

    sage_lp.c: return STOP_IMPL;

    sage_stddev.c: return STOP_IMPL;

    localhost:/home/josef/emulators/simh-master/SAGE #


    siehe SAGE/SAGE.PBOOT.TEXT


    ; Base of loop for each character

    $20 CMPM.B (A0)+,(A1)+ ;Compare the entries

    DBNE D1,$20


    Es wäre eventuell besser gewesen, zur Emulation der 68K CPU Musashi zu verwenden.

    https://github.com/kstenerud/Musashi

    https://github.com/simh/simh/tree/master/AltairZ80

    Hallo miteinander,


    die MAME-Emulation der Sage II ist noch nicht sehr weit gediehen, vor allem ist das Floppy-System noch nicht emuliert. Im Source-Code steht:



    Die ROMs müssen gezippt ins Unterverzeichnis "roms" abgelegt werden. Dieses wird während des Entpackens des Emulators automatisch erstellt. Ein anderer Speicherort kann aber in einer Konfigurationsdatei angegeben werden. Die beiliegende Datei ist für MAME geeignet.


    Zur emulierten 68K-CPU: MAME ist soweit ich mich erinnere auf eine eigene 68K-Emulation umgestiegen - dabei ging es um die genauere Emulation der Dauer von Befehlszyklen, und wann sie angehalten werden können. Das aber aus der Hüfte geschossen, so tief habe ich mich nie mit der 68K beschäftigt.


    Gruß

    Rober

    Den TMS9914 kan man sich sparen : der wird weder im ROM noch im BIOS unterstützt : evtl. Programme müssten den direkt ansteuern. Im Stride ist er dan auch nicht mehr vorhanden.

    Die Floppy-ansteurerung ist ebenfalls merkwürdig : obwohl ein 765 vorhanden ist, werden Floppyselect und Status bit über 2 unterschiedliche 8255's gehandelt, die dan auch noch ganz andere Teil der Kiste ansteurern. Softwaremassig nicht sonderlich einfach zu handhaben.


    Der MFM-kontroller ist handgestrickt und ziemlich unüblich realisiert : ein Track ist ein Sektor.

    Na ja, das Boot-Prom hat ja nur die Read-Routinen, damit der Urlader das System in den Speicher bekommt. Die Write-Routinen dazu finden sich dann natürlich im jeweiligen (CP/M und UCSD)-BIOS-Teil, und die gehen natürlich dann an das blanke Metall, unabhängig davon, ob der BDOS- bzw. P-Interpreter-Teil dann die Zugriffe über einen Trap abstrahiert. CP/M und UCSD müssen nicht selber an I/O-Ports rumwackeln, aber irgendwas muss immer die Drecksarbeit machen.

    Die SAGE -Boot prom hat sowohl Read wie Write Routinen.

    Der grosse Unterschied ist das die PROM-Sachen "polled" sind, die BIOS Routinen hingegen Interrupt-driven.

    Zitat von jdreesen

    Die SAGE -Boot prom hat sowohl Read wie Write Routinen.

    Der grosse Unterschied ist das die PROM-Sachen "polled" sind, die BIOS Routinen hingegen Interrupt-driven.

    Hast recht, hatte ich mit einem anderen System verwechselt.

    Allerdings: mit polled-IO konnte man eigentlich noch nie wirklich was Vernünftiges anfangen, ausser das "richtige" System booten. Siehe auch den Murks im IBM-BIOS oder die CBM-Serial-IO-Routinen. Von dem, was ich da disassembliert habe, ist der Sage-PROM-Code eher mit der heißen Nadel gestrickt - gibt es zwar halbwegs, aber ich würde mich besser nicht darauf verlassen, mehr als nur einen Bootloader in den Speicher zu bekommen.

    Einmal editiert, zuletzt von hl351ge ()

    Zitat von hl351ge

    Von dem, was ich da disassembliert habe, ist der Sage-PROM-Code ....

    Dir ist bekannt das von der Sage die originale, dokumentierte, source codes von PROM und BIOS vorhanden sind ? Leider nicht die von der Stride.


    Siehe : http://www.bitsavers.org/bits/…nd_Stride/SageSources.zip

    Einmal editiert, zuletzt von jdreesen () aus folgendem Grund: Link dazu...

    Zitat von jdreesen
    Zitat von hl351ge

    Von dem, was ich da disassembliert habe, ist der Sage-PROM-Code ....

    Dir ist bekannt das von der Sage die originale, dokumentierte, source codes von PROM und BIOS vorhanden sind ? Leider nicht die von der Stride.


    Siehe : http://www.bitsavers.org/bits/…nd_Stride/SageSources.zip

    Rate mal, wo die herkommen.
    Die habe ich aber erst aufgetrieben, nachdem ich das BIOS durch IDA gezogen habe.


    Im Source finden sich als Beispiel so schöne Dinge wie:

    ; Delays in floppy disk driver (may be changed for full speed PROM)

    DLY1 .EQU 174. ;1 Millisecond delay for FDCMD & FDSTAT

    ; (goes to 236. for full speed memory)

    DLY2 .EQU 10. ;24 Microsecond delay for FDCMP & FDSTAT &

    ; FDREAD. (goes to 16 for full speed memory)

    DLY3 .EQU 2 ;1 Second loop for FDREAD.

    ; (goes to 3 for full speed memory)

    DLY4 .EQU 2 ;950 Millisecond delay in FDRECAL.

    ; (goes to 3 for full speed memory)

    DLY5 .EQU 4 ;580 Millisecond delay in FDINIT.

    ; (goes to 5 for full speed memory (550 Milli)

    DLY6 .EQU 0FFFFH ;278 Millisecond delay in FDINIT.

    ; (stays same for full speed memory)

    DLY7 .EQU 40. ;96 Microsecond delay for start of recalibrate

    ; and seek. (goes to 64 for full speed memory)


    Sowas macht wirklich Spaß bei einem Emulator wie SIMH, der bestrebt ist, mit maximaler Geschwindigkeit zu laufen, und nicht zeitgenau die Takte abzuzählen. Wollte ich eigentlich einbauen - genau aus dem Grund -, aber das hat Mark abgelehnt. Da ist Interrupthandling deutlich pflegeleichter.

    Einmal editiert, zuletzt von hl351ge ()

    Lesen funktioniert mit der FDC Emulation eigentlich recht gut, nur das Schreiben macht Probleme.

    Aber wenn man in der Ramdisk arbeitet, kann man man unter UCSD p-System Programme compilieren

    und ausführen.

    Ja, im Prinzip funktioniert das. Du solltest die Bootdisk übrigens am Besten mit IMDU auspacken zu einer BIN-Datei. Howard Harte's simh_imd kann die RLL-komprimierten Sektoren nur lesen, weil sich beim Ändern vergrößern können und dann nicht mehr in ihren Bereich in der IMD-Datei passen würden. Aber es gibt da natürlich noch ein Timing-Problem beim Schreiben. Werde ich bei einem Zeitfenster wahrscheinlich nochmal anpacken.

    Zitat von hl351ge

    Ja, im Prinzip funktioniert das. Du solltest die Bootdisk übrigens am Besten mit IMDU auspacken zu einer BIN-Datei. Howard Harte's simh_imd kann die RLL-komprimierten Sektoren nur lesen, weil sich beim Ändern vergrößern können und dann nicht mehr in ihren Bereich in der IMD-Datei passen würden. Aber es gibt da natürlich noch ein Timing-Problem beim Schreiben. Werde ich bei einem Zeitfenster wahrscheinlich nochmal anpacken.

    Ist mir bekannt. Ich habe hier absichtlich ein komprimiertes imd verwendet.

    Beim Schreiben auf ein unkomprimiertes imd wird das Filesystem zerstört.

    Ich habe festgestellt, daß das Schreiben prinzipiell auch funktioniert.

    Nur beim Schreiben in das Directory wird der Schreibvorgang nach 51 oder 103 Byte

    abgebrochen. Warum das so ist, habe ich nicht herausgefunden.