Z80 emulator ( z80 core )

[sharpals]

Hallo, es hat mit seiner geschichte zu tun. Er war in maschinencode geschrieben !!!

Das interface ist zu dem alten noch kompatibel. Für eine komplete neuentwicklung , wäre die objektvariante eleganter.

Da der code ja frei verfügbar ist, wäre es auch schön wenn sich jemand anderes dieser sache annimmt und es mit seinen namen versieht.

Gruß michael

[sharpals]

Hi!

Noch interesse?

Hab mein FL-DOS im Internet gefunden - lol

Siehe : hier

Grüsse Frank :coder:[/quote]


Hallo, danke :-) Er läuft auf meinem Emu :-). Das Bild , das du auf der seite siehst, wurde dammit erstellt.

Gruß michael

[Reinhard Kern]

Zitat:

Zitat von sharpals

Hallo, ich poste hier mein Z80 Kern. Für alle, die immer wissen wollten, was ein Z80 so macht, oder auch für eigene EMU projekte.

Er ist Bestandteil mein MZ80x emulator.

Hallo,
kann man damit M80/L80 laufen lassen?

Hintergrund: ich habe noch manche alte Z80-Assembler-Files, die noch gelegentlich gebraucht werden (sogar für neue Hardware mit eZ80), aber M80 mag auf meinem neusten Entwicklungrechner (GHZ, W2000) nicht mehr in der Dos-Box laufen (um genau zu sein: nicht unter CP/M-Emulation in der DOS-Box). Manches habe ich schon auf DOS-basierten Z80-Assembler umgestellt, aber der kann nicht alles, z.B. keine .PHASE-Anweisung. M80 war der beste Z80-Assembler, der je existiert hat.

Gruss Reinhard

[Mavarik]

Zitat:

Zitat von Reinhard Kern

M80 war der beste Z80-Assembler, der je existiert hat.

Ja ja der gute "Masm"... Damit habe ich auch alles Programmiert. Inkl. unseres mForth 800 Compilers...

Kann ich mit Deinem Emulator die alten CP/M Diskette auf einem PC lesen?

Grüsse Frank :coder:

[Reinhard Kern]

Zitat:

Zitat von Mavarik

Zitat:

Zitat von Reinhard Kern

M80 war der beste Z80-Assembler, der je existiert hat.

Ja ja der gute "Masm"... Damit habe ich auch alles Programmiert. Inkl. unseres mForth 800 Compilers...

Kann ich mit Deinem Emulator die alten CP/M Diskette auf einem PC lesen?

Grüsse Frank :coder:

Ja, wenn du das Format kennst, man muss eine Definition wie folgt erstellen:

Delphi-Quellcode:

NOTE    THIS IS THE DATABASE FOR VERSION 1.30 OF 22DISK BY SYDEX.
NOTE
NOTE            MARCH 20, 1989
NOTE
NOTE                    SYDEX
NOTE                    153 NORTH MURPHY AVE.
NOTE                    SUNNYVALE, CA  94086
NOTE                    [phone]


BEGIN RK30  RK Solitaire 3.5 inch 64 Dir Ent.
DENSITY MFM,LOW
CYLINDERS 80
SIDES 2
SECTORS 10,512
SIDE1 0 1,5,9,3,7,2,6,10,4,8
SIDE2 1 1,5,9,3,7,2,6,10,4,8
ORDER SIDES
LABEL RK30
BSH 4  BLM 15  EXM 0  DSM 384  DRM 63  AL0 080H  AL1 0  OFS 6
END

BEGIN RK50  RK Solitaire 5.25 inch 64 Dir Ent.
DENSITY MFM,LOW
CYLINDERS 40
SIDES 2
SECTORS 10,512
SIDE1 0 1,5,9,3,7,2,6,10,4,8
SIDE2 1 1,5,9,3,7,2,6,10,4,8
ORDER CYLINDERS
LABEL RK50
BSH 4  BLM 15  EXM 1  DSM 191  DRM 63  AL0 080H  AL1 0  OFS 3
END


BEGIN SUP3  Superbrain QD - DSDD 48 tpi 5.25"
DENSITY MFM,LOW
COMPLEMENT
CYLINDERS 35
SIDES 2
SECTORS 10,512
SIDE1 0 1,3,5,7,9,2,4,6,8,10
SIDE2 1 1,3,5,7,9,2,4,6,8,10
ORDER CYLINDERS
BSH 4  BLM 15  EXM 1  DSM 169  DRM 63  AL0 080H  AL1 0  OFS 2
END

Ausserdem habe ich mal eine Software zum Zugriff unter DOS in Pascal (nicht Delphi, nicht Turbo) geschrieben, die wie folgt anfängt, dient aber nur zum KOMPLETTEN Lesen und Schreiben und v.a. Formatieren, also zum Archivieren von CP/M-Disketten meiner Machart. Sollte den Kunden und den Kundendienst unabhängig von einem realen CP/M-System machen.

Delphi-Quellcode:

 PROGRAM rkcpm; {read/write/format rk cp/m disks into/from dos file}

 CONST skewstr = '01050903070206100408';
       maxsector = 10;
       strategy = 1; { side 0 up, then side 1}
       deblock = 4;  { 4 cpm sect = 1 dos sect }
       offset = 3;
       direntries = 64;
       allocunit = 16; { cpm sect / block entry }
       systemtracks = 3; { only head 0 used ! }

       dir_offset = 3;

 {$I cnc\biosiod.pas}

 {$I doslib.pas}

 TYPE
      sector = array[0..127] of byte;
      sstring = string[76];
      genstring = string [255];
      st = (norm,sel1,sel2,sel3,skip);
      maddr = record case boolean of
              false : (ad : integer);
              true : (ofs,seg : word);
              end;
      hexcar = array[0..15] of char;
      dskparams = array [0..10] of byte;
{....}

Bei weiterem Interesse melden.

Gruss Reinhard

[sharpals]

Hallo, ich habe zwar einige CP/M´s unter dem Emu laufen, er benutzt aber *.DSK files. AUsserdem scheint die WD17xx emulation ein flagproblem zu haben.

DIe CP/M´s können ohne probleme lesen, aber beim schreiben ( MZ80B ) erscheint ein BDOS fehler.


Wenn ihr lust habt, gebe ich euch den quellcode des emus und ihr baut einen CP/M Bdos emulator, der dann direkt auf die Files zugreift.


Die Z80 ist auf jedemfall schnell genug, der kern solltebei 75 Mhz mit 3Mhz laufen.


Wir müssten also ein VTx oder TTY emulation schreiben, was wohl nicht das drama ist, da man den call 5 ja abfangen kann.

Wirklich aufwendig ist sind die filefunktionen.

Der vorteil ist, du hättest ein anpassbares system.

[Reinhard Kern]

Zitat:

Zitat von sharpals

Hallo, ich habe zwar einige CP/M´s unter dem Emu laufen, er benutzt aber *.DSK files. AUsserdem scheint die WD17xx emulation ein flagproblem zu haben.

DIe CP/M´s können ohne probleme lesen, aber beim schreiben ( MZ80B ) erscheint ein BDOS fehler.


Wenn ihr lust habt, gebe ich euch den quellcode des emus und ihr baut einen CP/M Bdos emulator, der dann direkt auf die Files zugreift.


Die Z80 ist auf jedemfall schnell genug, der kern solltebei 75 Mhz mit 3Mhz laufen.


Wir müssten also ein VTx oder TTY emulation schreiben, was wohl nicht das drama ist, da man den call 5 ja abfangen kann.

Wirklich aufwendig ist sind die filefunktionen.

Der vorteil ist, du hättest ein anpassbares system.

Hallo,

hab mir gerade meine alten MAC-Files mal wieder angesehen: 1300 Zeilen für Disk Access, geschrieben für EPRom/RAMFloppy und reale Disketten, ist also nicht so schlimm, und bei Zugriff auf ein anders (DOS-) Filesystem wird es entsprechend weniger.

Für mich lohnt sich kein grösserer Aufwand, weil ich ja über funktionierende Systeme verfüge, ich muss bloss im Zweifelsfall auf einen alten DOS-Rechner zurückgreifen. Die meisten Sachen lassen sich aber sogar unter W2000 noch übersetzen. Ausserdem habe ich das Diskettenproblem umgekehrt gelöst: für meine Werkzeugmaschinensteuerungen unter CP/M gab es ein CP/M-Programm, das DOS-Disketten formatieren, lesen und schreiben kann (in Z80-Pascal), der Datenaustausch ist also gewährleistet (das meiste lief sowieso über DNC).

Falls aber jemand Interesse hat, ein komplettes CP/M-BDOS inklusive Grafikausgabe kann ich zur Verfügung stellen. Das wird wohl kaum jemand noch kommerziell nutzen, ausserdem ist es wie unter CP/M üblich eben an spezielle Hardware angepasst: WD-Disk-Controller, Cherry serielles Keyboard oder eigenes, NEC-Grafik usw.

Gruss Reinhard

[sharpals]

Hallo, erstmal eine Frage: Wei kann ich das Update hochladen ?

Der kern ist etwas verbessert und hat eine 6502 zugesellt bekommen .

Und zurück zum thema, ich habe in meinen emu ein blanken Z80 mit Call 5 abfang gemacht.

Ich dachte immer, das, die cp/m programme immer via call 5 arbeiten. Demm ist leider nicht so (?).

Das idealste wäre einen cp/m ccp zu verwenden und das bdos nachzubilden.

Wie könnte mann das ganze lösen ?


Gruß Michael

[Reinhard Kern]

Zitat:

Zitat von sharpals

Hallo, erstmal eine Frage: Wei kann ich das Update hochladen ?

Der kern ist etwas verbessert und hat eine 6502 zugesellt bekommen .

Und zurück zum thema, ich habe in meinen emu ein blanken Z80 mit Call 5 abfang gemacht.

Ich dachte immer, das, die cp/m programme immer via call 5 arbeiten. Demm ist leider nicht so (?).

Das idealste wäre einen cp/m ccp zu verwenden und das bdos nachzubilden.

Wie könnte mann das ganze lösen ?


Gruß Michael

Hallo Michael,
das ist die BIOS Jmp Table aus meinem BDOS, daraus siehst du, was zu implementieren ist:

Delphi-Quellcode:

 ist es natürlich nicht, sondern Z80
;
;   BIOS JUMP TABLE
   JP   BOOT
WBOOTE:   JP   WBOOT
   JP   CONST
   JP   CONIN
   JP   CONOUT
   JP   LIST
   JP   PUNCH
   JP   READER
   JP   HOME
   JP   SELDSK
   JP   SETTRK
   JP   SETSEC
   JP   SETDMA
   JP   READ
   JP   WRITE
   JP   LISTST
   JP   SECTRAN
   JP   CONOST   ;CON OUTP STATUS
   JP   READST   ;READER STATUS
   JP   PUNST   ;PUN STATUS
   JP   0
;

Ist alles trivial bis auf die Disketten-Funktionen wie SETTRK: da muss man wohl Pseudofloppies nachbilden aus dem Current Dir unter Windows und auch für Boot-Images sorgen, weil der Zugriff von CP/M aufs BDOS eben nur auf der Ebene Disk/Track/Sector mit CP/M-Format erfolgt. Booten heisst also die ersten Sectoren der Disk einlesen und von dort starten, das muss man nachbilden. Und einen Dir-Inhalt von MSDOS muss man wohl in ein CP/M-Dir umwandeln, damit CP/M was damit anfangen kann.

Gruss Reinhard

[Reinhard Kern]

Zitat:

Zitat von Reinhard Kern

Hallo Michael,
das ist die BIOS Jmp Table aus meinem BDOS, daraus siehst du, was zu implementieren ist:

Delphi-Quellcode:

 ist es natürlich nicht, sondern Z80
;
;   BIOS JUMP TABLE
   JP   BOOT
WBOOTE:   JP   WBOOT
.........
;

Ist alles trivial bis auf die Disketten-Funktionen wie SETTRK: da muss man wohl Pseudofloppies nachbilden aus dem Current Dir unter Windows und auch für Boot-Images sorgen, weil der Zugriff von CP/M aufs BDOS eben nur auf der Ebene Disk/Track/Sector mit CP/M-Format erfolgt. Booten heisst also die ersten Sectoren der Disk einlesen und von dort starten, das muss man nachbilden. Und einen Dir-Inhalt von MSDOS muss man wohl in ein CP/M-Dir umwandeln, damit CP/M was damit anfangen kann.

Nachtrag zum vorherigen Posting: ich habe gerade mal einen Blick auf die BDOS-Funktionen von CP/M geworfen - es dürfte doch wesentlich einfacher sein, diese direkt zu implementieren, da man Funktionen wie Read File ziemlich direkt auf MSDOS umsetzen kann, ohne sich um die Struktur einer CP/M-Diskette zu kümmern. Dazu kommt noch, dass man dann keinen Originalcode benutzt und auch die theoretische Möglichkeit von Lizenzproblemen ausgeschlossen ist.

Gruss Reinhard