Hat jemand hier schon mal die Sage emulation in MAME getestet?
Es startet, vermisst natürlich EPROMS & Floppy-Images ...
Hat jemand hier schon mal die Sage emulation in MAME getestet?
Es startet, vermisst natürlich EPROMS & Floppy-Images ...
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:
Es gibt Arbeit an der Stride-front.....
http://bitsavers.informatik.uni-stuttgart.de/bits/Sage_and_Stride/
Irgendeine Idee, warum UCSD nicht funktioniert unter SIMH? Hat sich das jemand mal angeschaut?
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.
Es wäre eventuell besser gewesen, zur Emulation der 68K CPU Musashi zu verwenden.
Ja, den Musahi benutzt fast jeder. Wundere mich, warum sie es selbst geschrieben haben ...
DANKE!
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:
ZitatAlles anzeigenTODO:
- floppy loading
- TMS9914 IEEE-488 controller
- board 2 (4x 2651 USART)
- Winchester controller
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.
Gibt es die ROMs für die Sage IV und die Strides irgendwo zum Download?
Sage II und IV haben die gleiche ROMs, Die Stride ROMS sind irgenwo im Forum vorhanden..
...such such such...hier -->
Ganz nebenbei, die ganze I/O läuft doch im SAGE über TRAPs, also könnte man doch die I/O einfach umstellen im Monitor-EPROM, oder?
Alles anzeigenIrgendeine 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 )
Der Witz ist, dass die Befehle bislang nicht gebraucht wurden, sonst wären sie hinzugefügt worden. die STOP_IMPL sind eigentlich Catch-Alls.
Das echte Problem liegt eigentlich eher im Timing des FDCs, den ich von Howard Harte mehr oder weniger übernommen habe (yes, simh Sage is my code...). Da gibt es einige wirklich harte Timing-Bedingungen, die nicht funktionieren, wenn die CPU nicht wirklich mit 8MHz getaktet ist, sondern wie bei SIMH eher freilaufend, d.h. so schnell wie möglich, läuft. Da hilft dooferweise auch kein Musashi.
>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
Man lernt natürlich dazu; der PCS-Cadmus-Meta-Emulator benutzt den. Aber für den Sage ist meine Scratch-Implementation eigentlich gut genug, selbst wenn ihr einige Instrs fehlen - sie sind nicht notwendig (!).
Grüße
Holger
Ganz nebenbei, die ganze I/O läuft doch im SAGE über TRAPs, also könnte man doch die I/O einfach umstellen im Monitor-EPROM, oder?
Nebbich. Soooo einfach ist das nun auch wieder nicht.
Grüße
Holger
Ganz nebenbei, die ganze I/O läuft doch im SAGE über TRAPs, also könnte man doch die I/O einfach umstellen im Monitor-EPROM, oder?
Nebbich. Soooo einfach ist das nun auch wieder nicht.
Grüße
Holger
Wer greift den direkt auf die HW zu? UCSD? CP/M?
Alles anzeigenGanz nebenbei, die ganze I/O läuft doch im SAGE über TRAPs, also könnte man doch die I/O einfach umstellen im Monitor-EPROM, oder?
Nebbich. Soooo einfach ist das nun auch wieder nicht.
Grüße
Holger
Wer greift den direkt auf die HW zu? UCSD? CP/M?
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.
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.
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
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.
Alles anzeigenAlles anzeigenIrgendeine 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 )
Der Witz ist, dass die Befehle bislang nicht gebraucht wurden, sonst wären sie hinzugefügt worden. die STOP_IMPL sind eigentlich Catch-Alls.
Das echte Problem liegt eigentlich eher im Timing des FDCs, den ich von Howard Harte mehr oder weniger übernommen habe (yes, simh Sage is my code...). Da gibt es einige wirklich harte Timing-Bedingungen, die nicht funktionieren, wenn die CPU nicht wirklich mit 8MHz getaktet ist, sondern wie bei SIMH eher freilaufend, d.h. so schnell wie möglich, läuft. Da hilft dooferweise auch kein Musashi.
>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
Man lernt natürlich dazu; der PCS-Cadmus-Meta-Emulator benutzt den. Aber für den Sage ist meine Scratch-Implementation eigentlich gut genug, selbst wenn ihr einige Instrs fehlen - sie sind nicht notwendig (!).
Grüße
Holger
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.
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.