Forum: Mikrocontroller und Digitale Elektronik CP/M auf ATmega88


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jens (Gast)


Lesenswert?

Leo C. schrieb:
> Bei mir
> hieß die nämlich mal myz80-img.zip.
Ich hatte sie umbenannt. Der Originalname war mir zu kryptisch ;-)

von Jens (Gast)


Angehängte Dateien:

Lesenswert?

Nächste Baustelle ;-)

Ich möchte eine Bootdiskette erstellen.

Variante 1: Klonen der Bootdisk mit SYSGEN

Aus nicht nachvollziehbarer Quelle hab ich ein SYSGEN (siehe Anhang):
1
C>a:load sysgen
2
3
FIRST ADDRESS 0100
4
LAST  ADDRESS 04FF
5
BYTES READ    0400
6
RECORDS WRITTEN 08
7
8
9
C>dir
10
C: CLS      HEX : SDIR     HEX : SYSGEN   HEX : SYSGEN   COM
11
C>a:pip a:=sysgen.com
12
C>a:
13
A>sysgen
14
SYSGEN VER 2.0
15
SOURCE DRIVE NAME (OR RETURN TO SKIP)a
16
SOURCE ON A, THEN TYPE RETURN
17
FUNCTION COMPLETE
18
DESTINATION DRIVE NAME (OR RETURN TO REBOOT)c
19
DESTINATION ON C, THEN TYPE RETURN
20
FUNCTION COMPLETE
21
DESTINATION DRIVE NAME (OR RETURN TO REBOOT)
22
23
A>dir c:
24
NO FILE
25
A>
Komisch. Alle Dateien sind 'weg' und booten läßt sich von dem Image auch 
nicht. Nur cpmls sieht die Dateien noch:
1
$ cpmls -f simhd /Volumes/CPM-DISK/CPMDSK_C.IMG 
2
0:
3
cls.hex
4
sdir.hex
5
sysgen.com
6
sysgen.hex
Kann das überhaupt so gehen? Möglicherweise verwende ich SYSGEN falsch, 
oder ich habe eine ungeeignete Version, oder SYSGEN kommt mit den großen 
Images nicht klar.




Variante 2: Bauen der Bootdisk auf dem Hostsystem
Hostsystem ist bei mir ein MacOS X (10.9.5).
Erster Schritt: Ich brauche (einen/den?) z80asm
Hier habe ich einen gefunden: 
http://wwwhomes.uni-bielefeld.de/achim/z80-asm.html

Der läßt sich aber nicht Kompilieren.
1. Versuch:
1
In file included from asm.c:12:
2
./z80-cpu.h:31:61: error: redefinition of 'wait'
3
enum cpu_control_pin { rd, wr, iorq, mreq, m1, inter, halt, wait, reset, rfsh,
4
                                                            ^
5
/usr/include/sys/wait.h:248:7: note: previous definition is here
6
pid_t   wait(int *) __DARWIN_ALIAS_C(wait);
7
        ^
8
1 error generated.
Aus irgendeinem Grund liegt 'wait' im selben Namensraum.
Ich hab das erste wait zu waitpin umbennant und scheitere jetzt am

2. Versuch:
1
ar rcs asm.a z80-cpu.o asm.o hash.o compile.o regs.o instr.o interrupt.o \
2
                 expression.o mini-display.o keyboard.o file.o
3
gcc -lc -o z80-asm z80-asm.o dummy.o asm.a hardware/hard.a
4
Undefined symbols for architecture x86_64:
5
  "_A", referenced from:
6
      _reg_adr in asm.a(regs.o)
7
  "_B", referenced from:
8
      _reg_adr in asm.a(regs.o)
9
  "_C", referenced from:
10
      _reg_adr in asm.a(regs.o)
11
  "_D", referenced from:
12
      _reg_adr in asm.a(regs.o)
13
  "_E", referenced from:
14
      _reg_adr in asm.a(regs.o)
15
  "_H", referenced from:
16
      _reg_adr in asm.a(regs.o)
17
  "_I", referenced from:
18
      _reg_adr in asm.a(regs.o)
19
  "_IXh", referenced from:
20
      _reg_adr in asm.a(regs.o)
21
  "_IXl", referenced from:
22
      _reg_adr in asm.a(regs.o)
23
  "_IYh", referenced from:
24
      _reg_adr in asm.a(regs.o)
25
  "_IYl", referenced from:
26
      _reg_adr in asm.a(regs.o)
27
  "_L", referenced from:
28
      _reg_adr in asm.a(regs.o)
29
     (maybe you meant: _LISTING)
30
  "_R", referenced from:
31
      _reg_adr in asm.a(regs.o)
32
ld: symbol(s) not found for architecture x86_64
Da bin ich einigermaßen ratlos.

Vielleicht hat ja jemand noch Tipps, um Variante 1 und Variante 2 zum 
Laufen zu bekommen.

Danke,
Jens

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Ein CP/M-System direkt unter CP/M bauen hatte ich hier [1] mal 
beschrieben.
Wenn du die SUB Datei unter CP/M benutzt, mußt du den Befehl w cpm.bin b 
streichen, da er nur für den Simulator definiert ist.

[1]: Beitrag "Re: CP/M auf ATmega88"

: Bearbeitet durch User
von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

Jens schrieb:
> Ich möchte eine Bootdiskette erstellen.

Mein Vorschlag: Nachschauen, wie das Makefile im Zweig 
'avrcpm/trunk/cpm/' vom SVN-Server Deines Vertrauens die Teile 
zusammenstoppelt.

> Variante 1: Klonen der Bootdisk mit SYSGEN
> Aus nicht nachvollziehbarer Quelle hab ich ein SYSGEN (siehe Anhang):

Möglicherweise wird dieses Sysgen die falschen Sektoren, oder zu wenige 
kopieren.

> A>dir c:
> NO FILE
> A>
> Komisch. Alle Dateien sind 'weg' und booten läßt sich von dem Image auch

> Kann das überhaupt so gehen?

Theoretisch schon.
> oder ich habe eine ungeeignete Version,

Sehr wahrscheinlich. Im Anhang ist das Original-SYSGEN von DR. Statt die 
Die Disk-Geometrie vom BIOS zu holen, liest (und schreibt) es die 
Sektoren 1 bis 26 von Track 0 und 1.
Die großen Formate haben aber 32 oder noch mehr Sektoren pro Spur.

> oder SYSGEN kommt mit den großen Images nicht klar.

Von dem Sektorproblem abgesehen, eher nicht.
Das simh-Format hat 6 Spuren a 32 Sektoren für das System reserviert.
Das Directory kann dann eigentlich nicht überschrieben werden.

Wurden denn beide Images vor und nach SYSGEN als simh erkannt? 
(Überprüfen mit 'A>stat dsk:')
Hier ist 'A' simh und 'G' myz80:
1
A>stat dsk:
2
3
    A: Drive Characteristics
4
65344: 128 Byte Record Capacity
5
 8168: Kilobyte Drive  Capacity
6
 1024: 32  Byte Directory Entries
7
 1024: Checked  Directory Entries
8
  256: Records/ Extent
9
   32: Records/ Block
10
   32: Sectors/ Track
11
    6: Reserved Tracks
12
13
    G: Drive Characteristics
14
65536: 128 Byte Record Capacity
15
 8192: Kilobyte Drive  Capacity
16
 1024: 32  Byte Directory Entries
17
 1024: Checked  Directory Entries
18
  256: Records/ Extent
19
   32: Records/ Block
20
  128: Sectors/ Track
21
    0: Reserved Tracks


> Variante 2: Bauen der Bootdisk auf dem Hostsystem
> Hostsystem ist bei mir ein MacOS X (10.9.5).
> Erster Schritt: Ich brauche (einen/den?) z80asm

Die BIOS-Quellen sind für den Microsoft M80 geschrieben. Die gängigen 
Crossassembler sind oft nicht ganz kompatibel. Deshalb nehme ich m80.com 
oder neuerdings slr180.com in einem CP/M-Emulator. Leider weiß ich 
nicht, ob es einen passenden Emulator für MacOS gibt.

von Jens (Gast)


Lesenswert?

Joe G. schrieb:
> Ein CP/M-System direkt unter CP/M bauen hatte ich hier [1] mal
> beschrieben.
Der Thread ist ja inzwischen schon etwas unüberichtlich geworden. Das 
war mir entgangen.

> Wenn du die SUB Datei unter CP/M benutzt, mußt du den Befehl w cpm.bin b
> streichen, da er nur für den Simulator definiert ist.
Wie ruft man denn die SUB-Datei unter CP/M überhaupt auf?
Was braucht man alles dazu? Nur SUBMIT.COM oder auch XSUB.COM?
So tut sich jedenfalls nicht viel:
1
G>a:submit avrcpm.sub
2
3
G>

Wenn ich das Makefile/Buildscript/avrcpm.sub per Hand durchspiele 
scheitere ich an diesem Punkt:
1
G>F:M80 =ZSDOS/M
2
3
...
4
5
U                                         IF  ROM
6
U                                           IF  ZS
7
P                                       ORG     ZSDOS+0DF9H
8
U                                         IF  ZS
9
U                                         IF  ROM
10
11
1197 Fatal error(s),108 Warning(s)
12
13
G>
Hab ich den falschen Assembler?


Leo C. schrieb:
> Mein Vorschlag: Nachschauen, wie das Makefile im Zweig
> 'avrcpm/trunk/cpm/' vom SVN-Server Deines Vertrauens die Teile
> zusammenstoppelt.
Dort hab ich schon geschaut. Das entspricht ja im wesentlichen der 
avrcpm.sub. Allerdings fehlen im Repository (URL: 
svn://mikrocontroller.net/avr-cp-m/avrcpm/trunk/cpm) m.E. ein paar 
wichtige Quellen, z.B. ZSDOS.MAC oder BDOS.MAC. Außerdem ist mir nicht 
klar, wo die CPMxx.SYS herkommen, bzw. wie diese erstellt werden.


> Wurden denn beide Images vor und nach SYSGEN als simh erkannt?
Vorher ja, hinterher sieht es so aus :-/
1
A>stat dsk:
2
3
    A: Drive Characteristics
4
65344: 128 Byte Record Capacity
5
 8168: Kilobyte Drive  Capacity
6
 1024: 32  Byte Directory Entries
7
 1024: Checked  Directory Entries
8
  256: Records/ Extent
9
   32: Records/ Block
10
   32: Sectors/ Track
11
    6: Reserved Tracks
12
13
    C: Drive Characteristics
14
 1944: 128 Byte Record Capacity
15
  243: Kilobyte Drive  Capacity
16
   64: 32  Byte Directory Entries
17
   64: Checked  Directory Entries
18
  128: Records/ Extent
19
    8: Records/ Block
20
   26: Sectors/ Track
21
    2: Reserved Tracks
Offenbar verändert SYSGEN die Laufwerkscharakteristik.
Den Ansatz mit SYSGEN werde ich später weiterverfolgen. Selber bauen ist 
viel spannender.


> CP/M-Emulator ... für MacOS
Wird es sicher geben. Aber ich hab ja Zugriff auf das CP/M-System via 
Terminalprogramm. Da brauch ich keinen Emulator :-)

Gute N8,
Jens

von Leo C. (rapid)


Lesenswert?

> Was braucht man alles dazu? Nur SUBMIT.COM oder auch XSUB.COM?
> So tut sich jedenfalls nicht viel:
G>a:submit avrcpm.sub

Möglicherweise handelt es sich um das Problem, das hier
Beitrag "Re: CP/M auf ATmega88"
und hier
Beitrag "Re: CP/M auf ATmega88"
angesprochen wird.

> 1197 Fatal error(s),108 Warning(s)

So viele Fehler bekomme ich von M80 immer, wenn die Zeilenenden nicht 
stimmen. Der besteht auf CR/LF.
Die SLR-Assembler schlucken auch Unix-Zeilenenden.

Jens schrieb:
> Allerdings fehlen im Repository (URL:
> svn://mikrocontroller.net/avr-cp-m/avrcpm/trunk/cpm) m.E. ein paar
> wichtige Quellen, z.B. ZSDOS.MAC oder BDOS.MAC.

Vom BDOS hatten wir nie Sourcecode, findet man aber, wie ZSDOS im Netz.

> Außerdem ist mir nicht klar, wo die CPMxx.SYS herkommen, bzw. wie
> diese erstellt werden.

Die 62K-Version hatte Sprite_tm in der Urfassung des Projekts schon 
mitgeliefert.
http://spritesmods.com/?art=avrcpm&page=4

Die anderen hatte ich mal mir irgendeinem MOVCPM gebastelt. Das hatte 
eine andere Seriennummer als Sprite_tms CP/M. Ich meine, die 
Seriennummern angepaßt zu haben, weiß aber nicht mehr, wie weit ich 
damit gekommen bin, und ob wirklich alles funktioniert, weil ich dann 
auf ZSDOS umgestiegen bin.

> Offenbar verändert SYSGEN die Laufwerkscharakteristik.

SYSGEN kopiert höchstwahrscheinlich ab Track 0, Sektor 1, weil auf 
Floppies die Sektornumerierung bei 1 beginnt. Da unsere Sektor-zählung 
bei 0 beginnt, wird der erste Sektor nicht mitkopiert. Dieser enthält 
beim simh-Format nicht nur den IPL, sondern auch eine Formatkennung. 
Wenn diese nach dem Kopieren fehlt, wird das (ursprünliche) 
AVRCPM-Standardformat angenommen.

Wenn Du das SYSGEN mal anpassen willst, kannst Du Dich an unserem IPL 
orientieren, oder die Diskgeometrie aus dem BIOS auslesen, und dann 
konsequenter weise auch die BIOS-Funktion für Sector-Translate 
verwenden.

von Jens (Gast)


Lesenswert?

Leo C. schrieb:
> G>a:submit avrcpm.sub
>
> Möglicherweise handelt es sich um das Problem, das hier
Bestimmt. Aber erstmal muss es manuel funktionieren. Dann schau mir das 
nochmal an.
Und ich dachte immer so komisches Verhalten gibt es erst seit MS-DOS ;-)


>> 1197 Fatal error(s),108 Warning(s)
> So viele Fehler bekomme ich von M80 immer, wenn die Zeilenenden nicht
> stimmen. Der besteht auf CR/LF.
Die Zeilenenden waren bzw. sind es nicht. Viel einfacher: Es fehlt die 
ZSDOS.LIB

Ich habe hier (http://www.znode.de/specials/zsdossrc/) eine gefunden, 
jetzt kommt diese Ausschrift:
1
G>f:m80 =zsdos/m
2
P                                       COMMON  /_BIOS_/
3
4
1 Fatal error(s)
5
G>
Vielleicht könnt Ihr Eure ZSDOS.LIB nochmal zeigen, bzw. im Repository 
einchecken.

> Die SLR-Assembler schlucken auch Unix-Zeilenenden.
Denn kann ich mir ja trotzdem mal anschauen.


>> Außerdem ist mir nicht klar, wo die CPMxx.SYS herkommen, bzw. wie
>> diese erstellt werden.
> Die 62K-Version hatte Sprite_tm in der Urfassung des Projekts schon
> mitgeliefert.
> http://spritesmods.com/?art=avrcpm&page=4
Ok.

> Die anderen hatte ich mal mir irgendeinem MOVCPM gebastelt. Das hatte
> eine andere Seriennummer als Sprite_tms CP/M. Ich meine, die
> Seriennummern angepaßt zu haben, weiß aber nicht mehr, wie weit ich
> damit gekommen bin, und ob wirklich alles funktioniert, weil ich dann
> auf ZSDOS umgestiegen bin.
ZSDOS ist offenbar eh das bessere BDOS.

> Wenn Du das SYSGEN mal anpassen willst, kannst Du Dich an unserem IPL
Später. Aber es wäre ein originalerer Weg, um eine Systemkopie 
anzufertigen.

Viele Grüße,
Jens

von Leo C. (rapid)


Lesenswert?

> G>f:m80 =zsdos/m
> P                                       COMMON  /_BIOS_/

Könnte das hier sein:
1
--- /home/leo/CPM/src/ZSDOS/1/ZSDOS.LIB  1998-12-24 10:19:34.000000000 +0100
2
+++ /home/leo/src/avr/CPM_auf_ATmega88/joe/zsdos-20120425/ZSDOS.LIB  2012-04-25 12:17:10.000000000 +0200
3
@@ -173,7 +173,5 @@
4
 ; the ZRL equate to TRUE.  With the ZRL equate set to FALSE, a standalone
5
 ; .REL file will be produced with no external requirements.
6
 
7
-ZRL  EQU  TRUE    ; Set True .ZRL file with COMMON for NZCOM,
8
+ZRL  EQU  FALSE    ; Set True .ZRL file with COMMON for NZCOM,
9
         ;     False to produce straight .REL file
10
-

von Jens (Gast)


Lesenswert?

Super:
1
G>f:m80 =zsdos/m
2
3
No Fatal error(s)
4
5
G>
Ich habe jetzt eine CPM.BIN!
Vielen Dank bis hierhin. Ohne Internet würde ich wahrscheinlich jetzt 
noch Doku lesen.


Joe G. schrieb:
> Wenn du die SUB Datei unter CP/M benutzt, mußt du den Befehl w cpm.bin b
> streichen, da er nur für den Simulator definiert ist.

Jetzt bleibt nur noch eine Frage:
Wie bekomm ich die CPM.BIN (mit Bordmitteln) an die richtige Stelle der 
'Boot-Diskette'?

Hier wird ja nach 'w' gleich aufgeräumt:
1
SAVE 26 cpm.bin
2
ERA IPL.COM   
3
ERA CCP.COM 
4
ERA ZSDOS.COM       
5
ERA BIOS.COM
6
w cpm.bin b
7
ERA CPM.BIN

Viele Grüße,
Jens

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Jens schrieb:
> Wie bekomm ich die CPM.BIN (mit Bordmitteln) an die richtige Stelle der
> 'Boot-Diskette'?

Ich habe als "Boardmittel" die CP/M Tools verwendet.
mkfs.cpm.exe -f avrcpm -b cpm.bin -L test diskimage
Ich vermute jedoch, dass du mit "Boardmittel" direkt in CP/M die CPM.BIN 
Datei in den Bootsektor schreiben möchtest, oder?

von Leo C. (rapid)


Lesenswert?

Jens schrieb:
> Vielen Dank bis hierhin. Ohne Internet würde ich wahrscheinlich jetzt
> noch Doku lesen.
...
> Jetzt bleibt nur noch eine Frage:
> Wie bekomm ich die CPM.BIN (mit Bordmitteln) an die richtige Stelle der
> 'Boot-Diskette'?

CPM/M 2.2 ALTERATION GUIDE

Diese Doku gibts im Internet. ;-)

von Jens (Gast)


Lesenswert?

Hah! Es bootet!
Vielen Dank, Jungs!

Joe G. schrieb:
> Ich habe als "Boardmittel" die CP/M Tools verwendet.
> mkfs.cpm.exe -f avrcpm -b cpm.bin -L test diskimage
Stimmt. So stehts ja auch im Makefile von Leo.
Bei mkfs.cpm kann man ja auch mehrmals -b <file> angeben. Kann man sich 
da den Zusammenbau mit DDT bzw. dd evtl. sparen?

> Ich vermute jedoch, dass du mit "Boardmittel" direkt in CP/M die CPM.BIN
> Datei in den Bootsektor schreiben möchtest, oder?
Ja. Das meinte ich eigentlich. Muß ja damals auch ohne Host-PC gegangen 
sein.


Um das Bauen zu vereinfachen, hab ich jetzt SuperSUB probiert:
http://archives.scovetta.com/pub/walnut-creek/SIMTEL/SIGM/VOLS000/VOL085/SUPERSUB.ASM
Aber so richtig gesprächig sind dir Tools von damals alle nicht:
1
G>dir
2
G: AVRCPM   LIB : CPM      BIN : BIOS     MAC : CCP      MAC
3
G: CFGACPM  LIB : SUPERSUB ASM : IPL      MAC : MEMCFG   LIB
4
G: ZSDOS    MAC : ZSDOS    COM : IPL      COM : CCP      COM
5
G: AVRCPM   SUB : BIOS     COM : XSUB     COM : ZSDOS    LIB
6
G: M80      COM : L80      COM : DDT      COM : SUPERSUB COM
7
G: $$$      SUB
8
G>supersub avrcpm.sub
9
SuperSUB V1.1
10
11
G>

Viele Grüße,
Jens

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

Jens schrieb:
> Hah! Es bootet!
Glückwunsch!

Jens schrieb:
> Aber so richtig gesprächig sind dir Tools von damals alle nicht:

Versuche es mal mit DO.COM

von Jens (Gast)


Lesenswert?

Joe G. schrieb:
> Versuche es mal mit DO.COM
Das meldet sich ja mit der gleichen Versionsnummer wie SUPERSUB.COM.
Immerhin kommt es bis zum DDT:
1
G>L80 BIOS,BIOS/N/E
2
3
Link-80  3.44  09-Dec-81  Copyright (c) 1981 Microsoft
4
5
Data    0100    0608    < 1288>
6
7
43314 Bytes Free
8
[0000   0608        6]
9
10
(xsub active)
11
G>ERA BIOS.REL
12
G>; PUT PIECES TOGETHER
13
G>DDT
14
15
(xsub active)
16
G>F100 5C00 0
17
F100?
18
19
G>

Viele Grüße,
Jens

von Jens (Gast)


Lesenswert?

Sehr merkwürdig. Ich hab jetzt den DDT nochmal auf das Laufwerk 
draufkopiert und nun geht es. Danke!

Mal sehen, was ich als nächstes ausprobiere.

Jens

von Marcel A. (dl1ekm)


Lesenswert?

Habe diese Frage auch schon beim AX81-Projekt gestellt:
Da sich diese Arduino (Uno) Boards (mit ATmega328 und 16 MHz) immer 
größerer Beliebtheit erfreuen - könnte das nicht eine alternative Basis 
zum "CPM Stick" sein?
Es müsste ja "nur" der RAM-Kram auf ein Zusatz-Shield. USB usw. ist ja 
schon alles drauf. Die SD-Card entweder mit auf das Zusatzshield oder 
ein SD-Card-Shield.

Würde ich glatt mal probieren - 2 Fragen:
- reichen die 16 MHz auf dem Board aus?
- wahrscheinlich müsste man den Arduino-Bootloader überschreiben, oder?

Was meint ihr?

Gruß
Marcel

von Jens (Gast)


Lesenswert?

Marcel A. schrieb:
> Würde ich glatt mal probieren - 2 Fragen:
> - reichen die 16 MHz auf dem Board aus?
Ja. Ich habe bei der ATmega128-Variante auch 'nur' 16 MHz verwendet.

> - wahrscheinlich müsste man den Arduino-Bootloader überschreiben, oder?
Nicht zwingend. Ich weiß aber nicht, wie knapp es im 328 zugeht.

Die Pins müssten ja gerade so reichen (UART, I2C, SD-Karte und DRAM).

Jens

von Marcel A. (dl1ekm)


Lesenswert?

Hallo Jens,

habe mir das gerade noch mal genauer angesehen.
PINs sind alles da - ABER:
RX/TX ist hart verdrahtet auf die RX/TX-Pins des ATMega (PD0/PD1). Diese 
werden aber im CPM-Stick für die RAM-Adressleitungen verwendet. Im Stick 
gibt es stattdessen einen Soft-UART auf den Pins PB0/PB1.
Würde bedeuten, man müsste HW-mäßig auf der Arduino-Uno-Platine 
rumbrutzeln - oder?

Zum Thema Bootloader: Habe ich das da richtig verstanden - wenn ich ein 
mit AVR GCC erstelltes oder eben dieses "CPM-HEX" mit avrdude und "-c 
arduino" flashe, dann ist das so wie mit der IDE und das HEX kommt 
hinter den Bootloader (falls es passt...)?

Danke und Gruß
Marcel

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Marcel A. schrieb:
> Da sich diese Arduino (Uno) Boards (mit ATmega328 und 16 MHz) immer
> größerer Beliebtheit erfreuen - könnte das nicht eine alternative Basis
> zum "CPM Stick" sein?

Beitrag "Re: CP/M auf ATmega88"

von Jens (Gast)


Lesenswert?

Joe G. schrieb:
> Beitrag "Re: CP/M auf ATmega88"
Das passt aber nicht auf meine Uno's.
Mimimi
:-)

von Marcel A. (dl1ekm)


Lesenswert?

Ja, für mich würde sich die Frage stellen, ob man mit dem USB-Seriell 
irgendwie klar kommt ...

von Leo C. (rapid)


Lesenswert?

Marcel A. schrieb:
> Es müsste ja "nur" der RAM-Kram auf ein Zusatz-Shield. USB usw. ist ja
> schon alles drauf. Die SD-Card entweder mit auf das Zusatzshield oder
> ein SD-Card-Shield.

z.B. so was:
Ebay-Artikel Nr. 121505102595

Da könnte man die RAMs gleich drauffrickeln. Und die Uhr könnte man auch 
mitverwenden.

>> - wahrscheinlich müsste man den Arduino-Bootloader überschreiben, oder?

Wenn man den USB-Converter nur für den Download verwenden möchte, nicht. 
Wenn man den USB-Converter aber auf die Pins des AVRCPM-Serial-IF 
umlegt, kann man den Arduino Bootloader wahrscheinlich nicht mehr 
verwenden. Mit Peter Danneggers Fastboot, oder mit dem SD-Bootloader 
gehts aber.
Beitrag "Re: CP/M auf ATmega88"

Jens schrieb:
> Nicht zwingend. Ich weiß aber nicht, wie knapp es im 328 zugeht.

Platz satt.

Marcel A. schrieb:
> RX/TX ist hart verdrahtet auf die RX/TX-Pins des ATMega (PD0/PD1). Diese
> werden aber im CPM-Stick für die RAM-Adressleitungen verwendet. Im Stick

Datenbus. D.h., sie sind hochohmig, wenn nicht auf das RAM zugegriffen 
wird, bzw, können auch noch für was anderes verwendet werden.

> gibt es stattdessen einen Soft-UART auf den Pins PB0/PB1.
> Würde bedeuten, man müsste HW-mäßig auf der Arduino-Uno-Platine
> rumbrutzeln - oder?

Ja.
Oder 4-Bit RAM.

> Zum Thema Bootloader: Habe ich das da richtig verstanden - wenn ich ein
> mit AVR GCC erstelltes oder eben dieses "CPM-HEX" mit avrdude und "-c
> arduino" flashe, dann ist das so wie mit der IDE und das HEX kommt
> hinter den Bootloader (falls es passt...)?

Der Bootloader liegt am Flash-Ende. Das "HEX" kommt also davor.

Marcel A. schrieb:
> Ja, für mich würde sich die Frage stellen, ob man mit dem USB-Seriell
> irgendwie klar kommt ...

Wenn die Pins nicht umgelegt werden sollen, gehts noch mit 4-Bit RAM.
(Wenn 4-Bit RAM dann mal wieder geht...)

von Jens (Gast)


Lesenswert?

Für so ein Arduino-Ding würde ich aber Speicher nehmen, der aktuell 
verfügbar ist. Serielle RAMs hab ich aber noch keine gesehen. (Im 
Gegensatz zu seriellen 'ROMs' [=EEPROM]).

Grüße,
Jens

von Konrad S. (maybee)


Lesenswert?

Jens schrieb:
> Serielle RAMs hab ich aber noch keine gesehen.

23LCV1024
Bei Mouser für 2-3€/Stück als PDIP-8/SOIC-8/TSSOP-8 lieferbar.

von Jens (Gast)


Lesenswert?

Konrad S. schrieb:
> 23LCV1024
Danke, sieht auf den ersten Blick ganz nett aus. Aber als 
Hauptspeicherersatz taugt es leider nicht, da der Speicher intern in 
pages (zu 32 Bytes) segmentiert wird.

Parallele Speicher (SRAM) brauchen zu viele Pins für einen Arduino-Uno.
Alternativ könnte man den Ardino MEGA 2560 nehmen (15€ bei ebay). Den 
finde ich aber nicht mehr so gängig, wie den Uno.

Oder SRAM (128k x 8) + 74164 (2x) für die Adresse.
Um 64k RAM anzusteuern braucht man
 8 Pin Daten
 2 Pin Steuerleitung (/OE & /WE)
 2 Pin Adresse (seriell über 74164)
------
12 Pins, wobei man die Adresspins mit der SD-Karte teilen kann.

Allerdings dürfte die Zugriffszeit durch die serielle Ansteuerung noch 
langsamer sein, als bei 4-Bit DRAM (inkl. Refresh).

Viele Grüße,
Jens

von Konrad S. (maybee)


Lesenswert?

Jens schrieb:
> da der Speicher intern in
> pages (zu 32 Bytes) segmentiert wird.

Der 23LCV1024 hat auch einen "sequential mode", da kannst du beliebig 
lesen/schreiben.

> Allerdings dürfte die Zugriffszeit durch die serielle Ansteuerung noch
> langsamer sein, als bei 4-Bit DRAM (inkl. Refresh).

Klar, das ist der Preis für die geringere Anzahl an Pins.

Es gäbe auch noch serielles FRAM, z.B. FM25V02 (32kB, 6€) oder FM25V05 
(64kB, 12€). Hätte auch seinen Reiz.

von Leo C. (rapid)


Lesenswert?

Jens schrieb:
> Konrad S. schrieb:
>> 23LCV1024
> Danke, sieht auf den ersten Blick ganz nett aus. Aber als
> Hauptspeicherersatz taugt es leider nicht, da der Speicher intern in
> pages (zu 32 Bytes) segmentiert wird.

Spielt keine Rolle (Datenblatt):
1
- Byte, Page and Sequential mode for Reads and Writes

> Parallele Speicher (SRAM) brauchen zu viele Pins für einen Arduino-Uno.

Beim Arduino Uno sind alle I/O-Pins auf Steckerleisten geführt und damit 
hat er genau so viele Pins wie die 28-Pin ATmegas, die wir normalerweise 
für das Projekt nehmen.

> Alternativ könnte man den Ardino MEGA 2560 nehmen (15€ bei ebay). Den
> finde ich aber nicht mehr so gängig, wie den Uno.

Wäre (auch) eine Möglichkeit.

> Oder SRAM (128k x 8) + 74164 (2x) für die Adresse.
> Um 64k RAM anzusteuern braucht man
> 12 Pins, wobei man die Adresspins mit der SD-Karte teilen kann.
> Allerdings dürfte die Zugriffszeit durch die serielle Ansteuerung noch
> langsamer sein, als bei 4-Bit DRAM (inkl. Refresh).

Wesentlich schneller, bei gleichem Hardware-Aufwand, dürfte diese 
Variante sein:
Beitrag "Re: CP/M auf ATmega88"

Das SPI-RAM wäre natürlich auch erheblich schneller.

Zusammenfassung bis hier:
Für AVR-CP/M mit Arduino Uno sind folgende Varianten denkbar:
- Onboard USB-Schnittstelle nicht benutzen
- Onboard USB-Schnittstelle umverdrahten
- 4-Bit DRAM
- 8-Bit Static-RAM mit Adress-Latches
- SPI-RAM

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Leo C. schrieb:
> Zusammenfassung bis hier:
> - SPI-RAM

Wenn Minimal dann einen SPI-RAM z.B. 23K512 oder 23K1024. Eine kleine 
Beschreibung zur Ansteuerung findet man hier:
http://www.parallax.com/sites/default/files/downloads/AN012-SRAM-v1.0.pdf

von Jens (Gast)


Lesenswert?

Der SRAM mit den Adress-Latches ist eine sehr gute Idee.

Leo C. schrieb:
> Zusammenfassung bis hier:
> Für AVR-CP/M mit Arduino Uno sind folgende Varianten denkbar:
> - Onboard USB-Schnittstelle nicht benutzen
> - Onboard USB-Schnittstelle umverdrahten
> - 4-Bit DRAM
> - 8-Bit Static-RAM mit Adress-Latches
> - SPI-RAM

Meiner bescheidenen Meinung nach sind nur zwei Dinge sinnvoll:
- Onboard USB nutzen
und
- 8-Bit SRAM oder SPI-RAM
und zusammen mit RTC und SD-Card auf ein Uno-kompatibles Shield.

Wenn es eine Entscheidung gibt, würde ich mich auch für Schaltplan, 
Layout und Prototypfertigung zur Verfügung stellen.

Jens

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Um AVR CP/M auf eine breitere Basis zu stellen, verfolge ich die Idee 
mit den Arduinos ja schon länger. Bisher ist eine „gute“ Lösung immer an 
den folgenden Problemen gescheitert.
 - 5V Versorgung der Arduino UNO Versionen
 - Rx/Tx Pins liegen falsch
Auch SRAM mit Latch bietet dabei keinen Ausweg. Auch hier müsste Rx/Tx 
umverdrahtet werden. Für die 3.3V Lösung müsste entweder ein 
Levelshifter für die SD-Card eingesetzt werden, oder das Arduino Board 
auf 3.3V umgestellt werden. Irgendwie alles unbefriedigend.
Eine Alternative war ein Arduino „kompatibler“ Entwurf [1]. Dazu gibt es 
von der Schaltung bis zum fertigen Layout alle Unterlagen.

Für ein „echtes“ Arduino Shield sehe ich nur die folgende Alternative:
 - Arduino UNO auf 3.3V umstellen
 - SPI-RAM (hat auch 3.3V !!) um die Original Rx/Tx Pins zu nutzen

Irgendwie alles unbefriedigend :-(

Besser sieht es mit der Arduino Pro Version aus. Die gibt es für 3.3V 
UND 20 MHz OHNE USB. Auf dieses Shield könnte der RAM (SRAM oder SPI) 
die SD-Card, die RTC und der V24-USB Wandler. Das Shield würde also bis 
auf den Prozessor das komplette CP/M System zur Verfügung stellen. Doch 
auch das macht eigentlich wenig Sinn. Dann kann man ja auch gleich auf 
[1] zurückgreifen.

[1] Beitrag "Re: CP/M auf ATmega88"

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Ich habe in der Mittagspause die Varianten nochmals überdacht.
Was haltet ihr von der folgenden Kombination:
-  Arduino UNO OHNE Änderungen (5V und Rx/Tx auf den üblichen Pins)
als COM 2 für CP/M
-  CP/M Shield mit 5V und 3.3V (Spannungsregler auf dem Shield)
-  Levelshifter nur für für SD-Card und SPI-RAM ( z.B. TXB0108)
-  RTC und I2C Porterweiterung auf 5V
-  USB oder V24 für Terminal
-  wenn noch Platz ist Propeller mit VT100 auf Shield
Um das System schnell wieder zum Laufen zu bringen, müsste nur die RAM 
Lib gegen eine neue SPI-RAM Lib ausgetauscht werden. Aber dazu könnte 
Leo C. ja vielleicht einen Kommentar zu abgeben.

von Marcel A. (dl1ekm)


Lesenswert?

Klingt gut - aber letztlich gehen schon die Vorteile des UNO in den 
Hintergrund - es wird letztlich ja doch "nur" die CPU wiederverwendet. 
Man müsste dann 2 USB-Kabel anschließen...
Aber was meint ihr?

Mir kommt gerade noch eine andere (wahrscheinlich dumme) Frage: Die 
RAM-Chips für die 4-bit und 8-bit Adressierung (HW Varianten 1 + 2 
(Stick)) sind doch die gleichen, oder?

von Leo C. (rapid)


Lesenswert?

> Mir kommt gerade noch eine andere (wahrscheinlich dumme) Frage: Die
> RAM-Chips für die 4-bit und 8-bit Adressierung (HW Varianten 1 + 2
> (Stick)) sind doch die gleichen, oder?

Edit, da Frage falsch gelesen:
Ja.

: Bearbeitet durch User
von Jens (Gast)


Lesenswert?

Joe G. schrieb:
> Was haltet ihr von der folgenden Kombination:
> -  Arduino UNO OHNE Änderungen (5V und Rx/Tx auf den üblichen Pins)
> als COM 2 für CP/M
> -  CP/M Shield mit 5V und 3.3V (Spannungsregler auf dem Shield)
> -  Levelshifter nur für für SD-Card und SPI-RAM ( z.B. TXB0108)
> -  RTC und I2C Porterweiterung auf 5V
> -  USB oder V24 für Terminal
> -  wenn noch Platz ist Propeller mit VT100 auf Shield
Für mich klingt das sehr vernünftig.

Mit Propeller drauf, wird der Platz wahrscheinlich zu knapp. Oder man 
macht den Propeller gleich auf eine zweite Platine, so das man den noch 
obenauf stapeln kann. Der braucht ja nur RX und TX.
Die RX-Signale (von Tastatur und UART) muß man irgendwie verodern.
Also irgendwie so:
1
 
2
=Propeller-Shield=
3
 |||||||  ||||||
4
===CP/M-Shield====
5
 |||||||  ||||||
6
===Arduino-Uno====
VGA und PS/2 gibt es auf dem Propeller-Shield. RAM und RTC auf dem 
CP/M-Shield und UART und CPU auf dem Arduino.

> Um das System schnell wieder zum Laufen zu bringen, müsste nur die RAM
> Lib gegen eine neue SPI-RAM Lib ausgetauscht werden.
Sollte machbar sein. Die Umstellung auf SIMM-Module war auch nicht 
wirklich schwer.

Viele Grüße,
Jens

von Konrad S. (maybee)


Lesenswert?

Joe G. schrieb:
> SPI-RAM (hat auch 3.3V !!)

23LCV1024 geht mit 2.5V bis 5.5V.

von Leo C. (rapid)


Lesenswert?

Da jetzt "alle" SPI-RAM wollen, versuchen wir mal herauszufinden, ob die
Geschwindigkeit davon im aktzeptablen Bereich liegen kann.

Zum Vergleich 8-Bit DRAM
Memory Read braucht 11 Takte.
Die Z80-Interpreter Hauptschleife braucht mindestens 25 Takte 
(NOP-Befehl). Davon die 11 Takte für den Opcode-Fetch. Bei 20MHz 
AVR-Takt würde das einem Z80 mit 3,2MHz entsprechen. Gemessen[1] hatte 
ich mal 3,1Mhz. Die Differenz dürfte an den 1ms Timer- und den 
Refresh-Interrupts liegen.

SPI-RAM ohne Cache
Die Berechnungen erfolgen unter optimalen Bedingungen: Macro, also ohne 
Call/Ret Overhead und alle benötigten Daten in Registern. Es kann also 
nur schlechter werden.

  'CS Low' + 'Out CMD+Address' + 'In Data' + 'CS High'
=     2    +    3 x (16 +1)    + (16 + 1)  +    2
= 55 + 1x17
= 72

Der NOP-Befehl würde 72+14 = 86 Takte brauchen, entsprechend
ca. 0,93 MHz Z80.

16-Bit Zugriffe könnten optimiert werden:
(55 + 2x17)/2 = 44,5 Takte pro Byte.
Bei angenommenen 20% 16-Bit Zugriffen (wer macht mal ein Profiling?) 
hätten wir ca 66 Takte pro RAM-Zugriff.

SPI-RAM mit Cache
Als hier der Vorschlag SPI-RAM kam, war meine erste Idee, daß das mit 
Cache vielleicht sogar schneller laufen könnte, als DRAM. Schließlich 
haben wir noch fast 600 Byte RAM frei. Das würde für einen 512-Byte 
großen Cache ausreichen. Wenn wir auf den FAT-Buffer verzichten, hätten 
wir sogar 1024 Byte für den Cache.

Welchen Cache brauchen wir?
Der einfachste Cache[2], mit einem einzigen Block in passender Größe, 
wie z.B. in [3], ist beim Z80 wg. der geringen Lokalität von Code und 
Daten wenig sinnvoll. Meiner Meinung nach ist er völlig ungeeignet, da 
jeder Z80-Befehl mit Datenzugriff mindestens 2 Cache-Misses erzeugen 
würde, wenn Code und Daten nicht im gleichen Block liegen. Letzteres ist 
aber sehr wahrscheinlich. Sogar dann noch, wenn der Block 1024 Byte groß 
wäre.

Das andere Extrem wäre ein mehrfach-assoziativer Cache mit möglichst 
vielen kleinen Blöcken. Diese Variante scheidet offensichlich aus, weil 
die Suche im Tag-RAM nach dem richtigen Block viel zu lange dauert. Und 
der Verwaltungsaufwand für eine Verdrängungsstrategie käme noch dazu.

Bleibt "Direct Mapped" (einfach assoziativ) mit optimaler Blockgröße und 
-Anzahl.

Damit der Cache einen Vorteil bringt, sollte der Zugriff bei einem Hit 
schätzungsweise in der Größenordnung 20 Takte oder darunter liegen. Bei 
einem Miss wird auf jeden Fall ein Vielfaches benötigt. Bei meinen 
ersten Versuchen mit 32 Blöcken a 16 Byte (oder umgekehrt) brauchte ich 
aber schon mehr als 15 Takte, um herauszufinden, ob der benötigte Block 
im Cache ist. Die Berechnung des Offsets braucht dann nochmal mindestens 
das Gleiche.

Aber vielleicht funktioniert das Ganze ja mit 4 Blöcken a 256 Byte. 
Diese Variante würde sich extrem optimieren lassen. Das Low-Byte der 
Addresse könnte z.B. direkt als Offset dienen. Die Valid- und 
Dirty-Flags könnten (falls überhaubt benötigt) evtl. in Registern 
gehalten werden.

Leider habe ich nicht die Zeit, um das alles auszuprobieren. Stattdessen 
würde ich mich lieber um mein Z180-Projekt kümmern, das ja auch so schon 
nur sehr schleppend voran kommt.

[1] Beitrag "Re: CP/M auf ATmega88"
[2] http://de.wikipedia.org/wiki/Cache
[3] 
http://www.parallax.com/sites/default/files/downloads/AN012-SRAM-v1.0.pdf

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Leo C. schrieb:
> Da jetzt "alle" SPI-RAM wollen, versuchen wir mal herauszufinden, ob die
> Geschwindigkeit davon im aktzeptablen Bereich liegen kann.

Das war doch schon eine sehr gute Abschätzung, danke!
SPI-RAM war ja auch nur ein Zugeständnis an einen unveränderten Arduino 
UNO. Bei der Latch-RAM Variante müsste halt der ARDUIONO umverdrahtet 
werden. Letztlich ist es sinnvoller die Ressourcen in den Z180 zu 
stecken. AVR CP/M läuft ja :-)

von Jens (Gast)


Lesenswert?

Danke für die Abschätzung. SPI-RAM ist also zu langsam.

Dann die Variante mit den Adress-Latches.
Lohnt es sich dort ein drittes Latch (für die 'Bankadresse') einzubauen?
Kennt sich jemand aus, wie das Bankswitching realisiert sein muß, damit 
CP/M 3.0 damit was anfagen kann? Dürfen die Bänke 64k groß werden, oder 
müssen die kleiner sein (16k)?

Joe G. schrieb:
> Bei der Latch-RAM Variante müsste halt der ARDUIONO umverdrahtet
> werden.
Alternativ mußte man 4 Datenleitungen über Port C und die anderen über 
Port D abhandeln. Geht natürlich wieder auf die Performance.

Hier nochmal der Link zum Schaltplan:
http://arduino.cc/de/uploads/Main/Arduino_Uno_Rev3-schematic.pdf

Umverdrahten würde ich vermeiden wollen.

Grüße,
Jens

von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

Jens schrieb:
> Danke für die Abschätzung. SPI-RAM ist also zu langsam.

Das habe ich nicht gesagt. ;-)
Dazu müßte zu langsam erst mal definiert werden. Wie schnell es mit 
optimaler Cache-Strategie werden kann, ist auch noch offen. Es ist aber 
abzusehen, daß es auch damit deutlich langsamer bleiben wird, als 8-Bit 
DRAM.

> Dann die Variante mit den Adress-Latches.
> Lohnt es sich dort ein drittes Latch (für die 'Bankadresse') einzubauen?

Das Latch ist bereits im µC vorhanden, da die Adressleitungen A16-A18 
"ungemultiplexed" auf die µC-Ports gehen.

> Kennt sich jemand aus, wie das Bankswitching realisiert sein muß, damit
> CP/M 3.0 damit was anfagen kann? Dürfen die Bänke 64k groß werden, oder
> müssen die kleiner sein (16k)?

Siehe Bild (Quelle [1]). Die Größe des Common-Bereichs ist nicht 
festgelegt. Typische Werte liegen zwischen 4K und 32K. Wie man dieses 
Modell in Hardware (bzw. im Emulator) realisiert, ist nochmal ein 
anderes Thema.

> Joe G. schrieb:
>> Bei der Latch-RAM Variante müsste halt der ARDUIONO umverdrahtet
>> werden.
> Alternativ mußte man 4 Datenleitungen über Port C und die anderen über
> Port D abhandeln. Geht natürlich wieder auf die Performance.

2 Leitungen verlegen würde reichen:
1
Arduino UNO:
2
     ---------------------------------------------------------------------------------
3
     |                          Pin Nummer ATmega (28 pol.)                          |
4
     +-------------------------------------------------------------------------------+
5
     |13 |12 |11 | 6 | 5 | 4 | 3 | 2 |19 |18 |17 |16 |15 |14 |28 |27 |26 |25 |24 |23 |
6
     ---------------------------------------------------------------------------------
7
     |         Port D                |         Port B        |         Port C        |
8
     +-------------------------------+-----------------------+-----------------------+
9
     | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 5 | 4 | 3 | 2 | 1 | 0 | 5 | 4 | 3 | 2 | 1 | 0 |
10
     |                        TX  RX |SCK DO  DI  CS         |SCL SDA                |
11
     +-------------------------------+-----------------------+-----------------------+
12
DRAM |D3  D2  D1  D0  D3  D2         |                D1  D0 |                       |
13
     |A7  A6  A5  A4  A3  A2         |A10 A9  A8      A1  A0 |        WE  OE  CAS RAS|
14
     +-------------------------------+-----------------------+-----------------------+
15
SRAM |AD7 AD6 AD5 AD4 AD3 AD2        |A18 A17 A16     AD1 AD0|        WE  OE  ASH ASL|
16
     +-------------------------------+-----------------------+-----------------------+
17
18
ASH: Address Strobe High
19
ASL: Address Strobe Low
Da die Ansteuerung der beiden Latches im Prinzip weniger anspruchsvoll 
ist, als die Steuerung des DRAMs, ließe sich evtl. noch was optimieren.



[1] 
http://bitsavers.informatik.uni-stuttgart.de/pdf/digitalResearch/cpm_plus/CPM_Plus_System_Guide_Jan83.pdf

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

Leo C. schrieb:
> 2 Leitungen verlegen würde reichen:
Der Performanceverlust um aus Port D und Port B wieder ein 8-Bit Wert zu 
basteln, dürfte deutlich geringer sein als den RAM über SPI anzusteuern.

DRAM sollte sicherlich
     +-------------------------------+
DRAM |D7  D5  D5  D4  D3  D2         |
     |A7  A6  A5  A4  A3  A2         |
     +-------------------------------+
heißen.

Als VT100 habe ich gerade eine erweiterte Version für das Z180 Projekt 
in Betrieb genommen. Darauf gibt es noch einen Signalquellenumschalter. 
Somit kann vom Terminal die Eigangsquelle ausgewählt werden. Dieses 
Design ließe sich sicherlich auf ein passendes Shield bringen.

von Marcel A. (dl1ekm)


Lesenswert?

Wenn ich das richtig verstanden habe würde dann die Leitungen PD0/1 und 
PB0/1 vertauscht werden - rein in Software. Ist das denn von der 
Performance her realistisch?

Ansonsten denke ich auch, dass die UNOs dann als Plattform keinen Sinn 
machen, wenn außer der CPM nicht weiter verwendet werden kann.

Meine ursprüngliche Idee war eigentlich nur ein "RAM-Shield" mit 2 x 
RAM-IC und SD-Card zu ergänzen und fertig :-)

von Marcel A. (dl1ekm)


Lesenswert?

Noch mal eine Frage zu den Anfängen: Wozu ist eigentlich die RST-Leitung 
auf dem USB-Seriell-Adapter auf dem CPM-Stick (HW-V2) da? Diese wird da 
mit dem Reset des ATmega verbunden...? Kann man dann aus dem Terminal 
den Stick resetten - wie?
Peter Sieg hatte einmal angemerkt, dass diese NICHT mit dem AVR-Reset 
verbunden werden sollte - ist sie aber.

Da die 4Bit-RAM-Version ja nicht wirklich auf Z80 gebracht werden kann 
und ich die HW V3 (Joes all-in-one) schon habe wollte ich mir den mal (8 
Bit RAM) aufbauen. Aber die meisten CP2102-Adapter haben den RST nicht 
herausgeführt. Stellt sich also die Frage, ob der überhaupt notwendig 
ist.

von Leo C. (rapid)


Lesenswert?

Marcel A. schrieb:
> Da die 4Bit-RAM-Version ja nicht wirklich auf Z80 gebracht werden kann

Wer behauptet denn so was?
Das Ding ist schon lange "auf Z80". Daß es angeblich nicht funktioniert, 
wahrscheinlich gedebuged werden müßte, und dies zur Zeit niemand machen 
will, ist eine andere Geschichte...

von Marcel A. (dl1ekm)


Lesenswert?

Leo C. schrieb:
> Marcel A. schrieb:
>> Da die 4Bit-RAM-Version ja nicht wirklich auf Z80 gebracht werden kann
>
> Wer behauptet denn so was?
> Das Ding ist schon lange "auf Z80". Daß es angeblich nicht funktioniert,
> wahrscheinlich gedebuged werden müßte, und dies zur Zeit niemand machen
> will, ist eine andere Geschichte...

Ups - so habe ich das ja nicht gemeint. Ich habe da leider zu wenig Plan 
von, um selber Hand anzulegen. Muss ja auch nicht sein - ist doch so 
schon super.

von Leo C. (rapid)


Lesenswert?

> Ups - so habe ich das ja nicht gemeint.

Dann ist ja gut. :)
Du hast zwar 2 mal im Abstand von ein paar Wochen geschrieben, daß es 
nicht wichtig sei, aber es scheint Dich ja doch zu beschäftigen...
Deshalb habe ich mal zurück geblättert.

Marcel A. schrieb:
> So, ich habe mal meinen ersten Lochraster-Aufbau von "anno dazumal"
> ausgegraben (siehe Foto), den mit ATMega88 und 4bit RAM.
> Ich habe dem dann einen 328p spendiert und wollte die aktuelle
> "firmware" mit Z80-Unterstützung draufbringen.

Das klingt so, als wäre das Ding "anno dazumal" schon mal gelaufen. 
"Anno dazumal" gab es (mindestens) zwei 4-Bit Varianten, die leider 
schön öfter für Verwirrung gesorgt haben. In der aktuellen Software ist 
aber nur noch eine Pin-Belegung vorgesehen. Du könntest Deine 
Verdrahtung mal mit der Definition in config.inc vergleichen. 
Insbesondere diese Pins:
[avrasm]
;Port C
.equ RAM_D0  = 0
.equ RAM_D1  = 1
.equ RAM_D2  = 2
.equ RAM_D3  = 3
.equ RAM_W  = 4
.equ RAM_CAS  = 5
[avrasm]

Sicherheitshalber den Rest aber auch. Bei Unterschieden wäre es wohl am 
Besten, wenn Du Deine Verdrahtung änderst.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Marcel A. schrieb:
> Wozu ist eigentlich die RST-Leitung
> auf dem USB-Seriell-Adapter auf dem CPM-Stick (HW-V2) da? Diese wird da
> mit dem Reset des ATmega verbunden...? Kann man dann aus dem Terminal
> den Stick resetten - wie?

Das Reset-Pin liegt einfach nur zur freien Verfügung auf der LP. In der 
Bestückungsvariante FTDI wird es nicht benutzt. Man könnte es jedoch auf 
RTS/CTS oder DTR/DSR legen und vom Terminal darüber Reset auslösen 
(müßte jedoch noch programmiert werden)

von Marcel A. (dl1ekm)


Lesenswert?

Leo C. schrieb:


> ;Port C
> .equ RAM_D0  = 0
> .equ RAM_D1  = 1
> .equ RAM_D2  = 2
> .equ RAM_D3  = 3
> .equ RAM_W  = 4
> .equ RAM_CAS  = 5

>
> Sicherheitshalber den Rest aber auch. Bei Unterschieden wäre es wohl am
> Besten, wenn Du Deine Verdrahtung änderst.

Hallo Leo,

ich habe noch mal alles geprüft. Ich habe wohl die 4-Bit Version "neu", 
also mit getauschten PC1/PC4. Verbindungen stimmen alle.
Derzeit läuft darauf eine Version für 8080 auf dem ATmega88. Ich kann 
leider nicht sagen, welche Version, es meldet sich mit 1.0...
Ich vermute aber mal, dass ich eine Version drin habe mit nur einem 
asm-file kompiliert und folgendem Inhalt:
1
#ifndef DRAM_DQ_ORDER      /* If this is set to 1, the portbits  */
2
  #define DRAM_DQ_ORDER 1    /* for DRAM IO3 and WE are swapped.    */
3
...
4
;Port C
5
#if DRAM_DQ_ORDER == 1
6
.equ ram_d1 =  1
7
.equ ram_w  =  4
8
#else /* original */
9
.equ ram_d1 =  4
10
.equ ram_w  =  1
11
#endif
12
.equ ram_d0 =  0
13
.equ ram_d2 =  2
14
.equ ram_d3 =  3
15
.equ ram_cas=  5
16
17
.equ P_W   = PORTC
18
.equ P_CAS = PORTC
19
20
.equ RAM_DQ_MASK = (1<<ram_d3)|(1<<ram_d2)|(1<<ram_d1)|(1<<ram_d0)
21
.equ PC_OUTPUT_MASK = (1<<ram_cas)|(1<<ram_w)
22
#endif

Die HW müsste das hier sein (ohne FTDI):
[[Beitrag "Re: CP/M auf ATmega88"]]

Also das scheint es nicht zu sein.

: Bearbeitet durch User
von Marcel A. (dl1ekm)


Lesenswert?

Teilweise sitzt das Problem (Z80 - 4Bit-Ram) auch vor der Tastatur... 
Ich hatte zwar das neue HEX in den 328p geflashed - aber die Fuses nicht 
angepasst - lief immer mit intern 8MHz.

Ich habe ihn nun genau wie den M88 auf "Ext-Full-Swing-Osz" (mit dem 
Eclipse-Plugin) eingestellt - lfuse=77
Oder wäre "Ext Osz > 8MHz" besser?

Nun zeigt er wenigstens "Müll" im Terminal an und zwar im richtigen 
Verhältnis/Startverhalten.... Der Müll ist aber immer das gleiche 
Zeichen. Mit den seriellen Einstellungen habe ich schon gespielt - 
bisher erfolglos. Aber ich denke, da könnte zumindest ein Teil meines 
Problems liegen.

von Leo C. (rapid)


Lesenswert?

> Teilweise sitzt das Problem (Z80 - 4Bit-Ram) auch vor der Tastatur...

Das Problem sitzt fast immer vor der Tastatur. Man weiß nur oft nicht, 
vor welcher... ;-)

> lfuse=77

Wenn das Hex ist, ist die "Divide clock by 8 internally; [CKDIV8=0]" 
Fuse aktiviert.

Meine ATmega328P Fueses stehen auf:
avrdude: safemode: lfuse reads as D6
avrdude: safemode: hfuse reads as D2
avrdude: safemode: efuse reads as 7

ps:
Zum Rumspielen mit verschiedenen Einstellungen ist der "Engbedded Atmel 
AVR® Fuse Calculator" gut zu gebrauchen:
http://www.engbedded.com/fusecalc/

: Bearbeitet durch User
von Marcel A. (dl1ekm)


Lesenswert?

Ja, habe ich mir gerade auch schon überlegt. Probier ich gleich aus!

von Marcel A. (dl1ekm)


Lesenswert?

So, das mit dem Takt war schon mal das Grundproblem - eigentlich ein 
Klassiker... Grrrr (Hau mit dem Kopf auf die Tischkante....).

Nun, ich habe dann sicherheitshalber auch noch mal den aktuellen Stand 
(V 154) übersetzt und geflashed. Es zeigt die gleiche Ausgabe wir der 
manuell angepasste Stand auf dem 328er:
1
CPM on an AVR, v3.2 r0
2
Testing RAM: fill...wait...reread...
3
Addr xx yy
4
0000 00 FF -------- XXXXXXXX
5
0001 01 FF -------- XXXXXXX-
6
0002 02 FF -------- XXXXXX-X
7
0003 03 FF -------- XXXXXX--
8
0004 04 FF -------- XXXXX-XX
9
0005 05 FF -------- XXXXX-X-
10
0006 06 FF -------- XXXXX--X
11
0007 07 FF -------- XXXXX---
12
0008 08 FF -------- XXXX-XXX
13
0009 09 FF -------- XXXX-XX-
14
000A 0A FF -------- XXXX-X-X
15
000B 0B FF -------- XXXX-X--
16
000C 0C FF -------- XXXX--XX
17
000D 0D FF -------- XXXX--X-
18
000E 0E FF -------- XXXX---X
19
000F 0F FF -------- XXXX---- System halted!

Das dort r0 angezeigt wird liegt wohl auch daran, dass ich es als 
Tar-Ball geladen habe und nicht richtig ausgeckekt habe. Muss mich mal 
mit SVN befassen...
1
Warning: unable to find Subversion 1.7 'working copy' metadata.
2
This directory may not be under version control.

von Marcel A. (dl1ekm)


Lesenswert?

Beim Lesen der Make-Meldungen ist mir aufgefallen, dass er die 8-Bit 
Files für dram verwendet hat - musste da noch einen Schalter umlegen.
Jetzt verwendet er die 4bit-Files-aber gleiches Ergebnis.

ALso weitersuchen... :-)

von Leo C. (rapid)


Lesenswert?

Marcel A. schrieb:
> CPM on an AVR, v3.2 r0
> Testing RAM: fill...wait...reread...
> Addr xx yy
> 0000 00 FF -------- XXXXXXXX
> 0001 01 FF -------- XXXXXXX-

Egal was ins RAM geschrieben wird, es wird immer 0xFF zurück gelesen. 
Sieht nach einem Wrie-Only-Memory aus. ;) Könnte aber auch an der 
Initialisierung liegen.

Früher (TM) sah die Portinitialisierung mal so aus:
1
; - Setup Ports
2
  ldi   temp,(1<<PUD)    ;disable pullups
3
  outm8  P_PUD,temp
4
  ldi  temp,0xFF
5
  out   PORTD,temp    ;all pins high
6
  out   PORTB,temp
7
  out   PORTC,temp
8
  out   DDRD,temp    ; all outputs
9
  out  DDRB,temp
10
  out  DDRC,temp
Du könntest in init.asm den Teil zwischen
"Setup Ports" und "outm8 TIMSK1,_0"
mal durch diese Zeilen ersetzen.

von Marcel A. (dl1ekm)


Lesenswert?

So, wir sind fast am Ziel :-)

Die oben genannte Änderung führ zur folgenden Ausgabe:
1
CPM on an AVR, v3.2 r0
2
Testing RAM: fill...wait...reread...
3
Initing mmc...
4
5
A: CP/M partition at: 062, size: 7657KB.
6
B: CP/M partition at: 15376, size: 7688KB.
7
C: CP/M partition at: 30752, size: 7688KB.
8
D: CP/M partition at: 46128, size: 7688KB.
9
Partinit done.
10
Ok, Z80-CPU is live!

Danach bleibt der Cursor aber stehen.
Kann das daran liegen, dass das CPM auf der SD noch für einen 8080 ist?

Wenn ich die SD-Card aus dem HW-4 Projekt (mit Propeller) reinstecke, 
kommt:
1
CPM on an AVR, v3.2 r0
2
Testing RAM: fill...wait...reread...
3
Initing mmc...
4
5
A: FAT16 File-Image 'A' at: 003, size: 256KB.
6
B: FAT16 File-Image 'B' at: 007, size: 256KB.
7
C: FAT16 File-Image 'C' at: 011, size: 256KB.
8
D: FAT16 File-Image 'D' at: 023, size: 8192KB.
9
E: FAT16 File-Image 'E' at: 015, size: 250KB.
10
F: FAT16 File-Image 'F' at: 019, size: 256KB.
11
G: FAT16 File-Image 'G' at: 283, size: 8192KB.
12
Partinit done.
13
Ok, Z80-CPU is live!
14
15
62k cp/m vers 2.2
16
17
A>dir

Bei Eingabe von "dir" stürzt er aber ab.

Hängt das ggf. mit diesen Einstellungen im MakeFile zusammen 
(FAT/CPM-Support)?
1
#FAT16_SUPPORT = 0
2
#CPMDSK_SUPPORT = 0
3
#MMCBOOTLOADER = 0


Das "Problem" in der Init.asm für 4-bit liegt für mein (rudimentäres) 
Assembler-Verständnis darin, dass in der aktuellen Fassung:
1
; - Setup Ports
2
3
;  ldi   temp,(1<<PUD)    ;disable pullups
4
;  outm8  P_PUD,temp
5
  out   PORTD,_255    ;all pins high (enables pullup on input ports)
6
  out   PORTB,_255
7
  out   PORTC,_255
8
  out   DDRD,_255    ; PD all outputs
9
#if I2C_SUPPORT
10
  ldi  temp,~((1<<SCL)|(1<<SDA))
11
  out  DDRC,temp 
12
#endif
13
#if DRAM_8BIT
14
  ldi  temp,~(1<<RXD)
15
  out  DDRB,temp
16
#endif

die "out DDRC" und "out DDRB" in den IF-Schachteln stecken und daher bei 
4-Bit nicht angesprochen werden und damit die Ports nicht richtig 
initialisiert werden.

von Leo C. (rapid)


Lesenswert?

Marcel A. schrieb:
> Kann das daran liegen, dass das CPM auf der SD noch für einen 8080 ist?

Nein, daß könnte der Z80-Emulator (mindestens) genau so gut. Es liegt 
eher daran, daß das BIOS nicht mehr zu der Schnittstelle im Emulator 
paßt.

> Wenn ich die SD-Card aus dem HW-4 Projekt (mit Propeller) reinstecke,

Welcher Firmwarestand ist den auf dem Gerät drauf?
Könnte das gleiche Problem sein, ich glaubs aber eher nicht. 
Wahrscheinlich ist noch was anderes faul.

Marcel A. schrieb:
> die "out DDRC" und "out DDRB" in den IF-Schachteln stecken und daher bei
> 4-Bit nicht angesprochen werden und damit die Ports nicht richtig
> initialisiert werden.

Die IF-Schachteln habe ich erst kürzlich eingebaut, eben wegen dem 4-Bit 
RAM. War offensichtlich ein Schuß in den Ofen.


Fast vergessen:
Ich wollte ein Image mitschicken, daß mit Deinem Softwarestand auf jeden 
Fall laufen sollte. Leider habe ich gerade ein Problem.

: Bearbeitet durch User
von Marcel A. (dl1ekm)


Lesenswert?

So - es läuft FAST alles.

Das meine Karte aus der alten HW gar nicht geht ist klar - das war noch 
das Partitions-Schema und nicht das FAT16-System.

Den Fehler mit dem Absturz nach dem Boot habe ich sowohl mit meinem CPM 
Image als auch mit dem von Leo. Aber nicht immer. Meistens startet er 
durch, ich kann auch einiges machen.

Es fällt aber auf, dass einige Zeichen "komisch" sind...

Ich konnte sogar Turbo Pascal starten

Der Aufruf von kompilierten COM-Dateien geht dafür aber wieder.

Manchmal klappt auch der Wechsel der Disketten - manchmal nicht.
Habe auch mal die Geschwindigkeit von 57600 auf 38400 geändert - keine 
Änderung.

Hier mal ein Auszug, was sich so tut und was für Fehlermeldungen kommen. 
Ich würde sagen: Im Grund geht es jetzt - aber irgendwo ist noch was 
faul.

Was wäre eigentlich der Vorteil der 8bit-Variante? War das nur 
Geschwindigkeit?

Leo, das mit den IFs war sicher kein Schuss in den Ofen. Das war schon 
genau das Problem, wahrscheinlich müsste man die IFs nur anders 
aufbauen.

1
A: FAT16 File-Image 'A' at: 003, size: 256KB.
2
B: FAT16 File-Image 'B' at: 007, size: 256KB.
3
C: FAT16 File-Image 'C' at: 011, size: 256KB.
4
D: FAT16 File-Image 'D' at: 023, size: 8192KB.
5
E: FAT16 File-Image 'E' at: 015, size: 250KB.
6
F: FAT16 File-Image 'F' at: 019, size: 256KB.
7
G: FAT16 File-Image 'G' at: 283, size: 8192KB.
8
Partinit done.
9
Ok, Z80-CPU is live!
10
11
62k cp/m vers 2.2
12
13
A>c:
14
C>dir
15
62k cp/m vers 2.2
16
17
A>dir
18
A: CPMSTAT  COM : DDT      COM : DDTZ     COM : TD       CFG
19
A: COPY     CFG : LDTIM    COM : SIMHCLOK REL : AVRCLOCK REL
20
A: COPY     UPD : COPY     COM : CPU      COM : DO       COM
21
A: DUMP     COM : ED       COM : TD       COM : WIPE     COM
22
A: STAT     COM
23
A>
24
25
B>turbo
26
27
ZSDOS error on Á: No Drive
28
Call: 14
29
30
B>
31
--------------------------------- 
32
  CPM on an AVR, v3.2 r0
33
Testing RAM: fill...wait...reread...
34
Initing mmc...
35
36
A: FAT16 File-Image 'B' at: 007, size: 256KB.
37
B: FAT16 File-Image 'C' at: 011, size: 256KB.
38
C: FAT16 File-Image 'D' at: 023, size: 8192KB.
39
D: FAT16 File-Image 'E' at: 015, size: 250KB.
40
E: FAT16 File-Image 'F' at: 019, size: 256KB.
41
F: FAT16 File-Image 'G' at: 283, size: 8192KB.
42
Partinit done.
43
Ok, Z80-CPU is live!
44
45
62k cp/m vers 2.2
46
47
A>dir
48
A: TEST     BAK : TINST    COM : TINST    DTA : TINST    MSG
49
A: TURBO    COM : TURBO    MSG : TURBO    OVR : TEST     COM
50
A: TEST     PAS : BLOCK    PAS : BLOCK    BAK : BDOS     COM
51
A: BDOS     PAS : BDOS     BAK : RTCDEMO  PAS : RTCDEMO  COM
52
A: ANSITEST BAK : ANSITEST PAS
53
A>test
54
Das ist ein AVR CP/M Test in Turbo Pascal 3.0
55
Hello Word VT100 Test !
56
57
A>
58
59
Logged drive: A
60
61
Work file:
62
Main file:
63
64
Edit     Compile  Run   Save
65
66
eXecute  Dir      Quit  compiler Options
67
68
Text:     ð bytes (8118-8118)
69
Free: ððððð bytes (8119-E006)
70
71
>
72
Dir mask:
73
TEST     BAK : TINST    COM : TINST    DTA : TINST    MSG : TURBO    COM
74
TURBO    MSG : TURBO    OVR : TEST     COM : TEST     PAS : BLOCK    PAS
75
BLOCK    BAK : BDOS     COM : BDOS     PAS : BDOS     BAK : RTCDEMO  PAS
76
RTCDEMO  COM : ANSITEST BAK : ANSITEST PAS
77
78
Bytes Remaining On A: ðððk
79
>
80
81
--- Editor gestartet (test.pas):
82
83
^K^K^K^K^K 1    Col 69  Insert    Indent  A:TEST.PAS
84
     C  A =1D BC =611E DE =423F HL =1FB7 SP=E3FC PC=7CEB       76 61 6C
85
  H NC  a'=00 bc'=0000 de'=0000 hl'=0000 IX=7BF3 IY=446C I=00       CPU halted!
86
 
87
A>b:
88
B>dir
89
B: C        CCC : C        SUB : CC2      COM : CC       COM
90
B: CLIB     COM : CLINK    COM : DEFF2    CRL : DEFF     CRL
91
B: BDS      LIB : STDIO    H   : TTT2     C   : MMIND    C
92
B: OTHELLO  C   : STONE    C   : ED       COM : OTHELLO  CRL
93
B: STONE    $$$
94
B>ed
95
96
Bdos Err On P: Select

von Jens (Gast)


Lesenswert?

Marcel A. schrieb:
> Es fällt aber auf, dass einige Zeichen "komisch" sind...
Wirklich sehr mysteriös.

> Habe auch mal die Geschwindigkeit von 57600 auf 38400 geändert - keine
> Änderung.
>
> Hier mal ein Auszug, was sich so tut und was für Fehlermeldungen kommen.
> Ich würde sagen: Im Grund geht es jetzt - aber irgendwo ist noch was
> faul.
Ich hätte da immer noch das Speichertiming im Verdacht.

> Was wäre eigentlich der Vorteil der 8bit-Variante? War das nur
> Geschwindigkeit?
Meines Erachtens: ja

Grüße,
Jens

von Marcel A. (dl1ekm)


Lesenswert?

Vielleicht sollte ich mal den Speicher tauschen?

Hm... Es stellt sich die Frage, ob es wirklich den Aufwand lohnt, das 
Thema 4Bit "gerade" zu biegen. Einziger Grund kann ja letztlich nur 
sein, dass die DRAMs nicht mehr ganz so leicht zu beschaffen sind.

Ich denke, ich werde als nächsten mal den "Stick" bauen, dann habe ich 
fast alles (alte) HW zusammen und kann dann hoffentlich mit dem Z180 
Projekt anfangen.

Über Weihnachten werde ich mal mehr über den Z80 und CPM lesen.
(Rolf-Dieter Klein's Buch, Rodnay Zak, NCR Kleinkomputer.... Schon nett 
:-))

von Leo C. (rapid)


Lesenswert?

> Vielleicht sollte ich mal den Speicher tauschen?

Eher nicht. Auch wenn es wirklich Timing-Probleme sind, heißt das nicht, 
das es am RAM-Chip liegt. Ich vermute aber eher, daß die Initialisierung 
immer noch nicht in Ordnung ist, bzw. daß Port-Register irgendwo 
verändert werden, wo sie es nicht sollten. Es ist etwas mühsam, das 
durch starren auf den Bildschirm herauszufinden. Vielleicht stecke ich 
mir doch mal so ein System zusammen. Dieses Jahr aber nicht mehr.

von Cord J. (cord)


Lesenswert?

Hallo,
ich möchte auch endlich mal den CP/M Computer nachbauen.
Hat noch jemand eine von diesen Platinen übrig?

http://www.mikrocontroller.net/articles/Datei:Avr_cpm2.jpg

Wenn nicht, würde ich gerne welche fertigen lassen. Hat sonst noch 
jemand Interesse? Ich hätte auch noch ein paar Speicherchips KM44C4100 
oder M5M44256
abzugeben.

Gruß
  Cord

von Marcel A. (dl1ekm)


Angehängte Dateien:

Lesenswert?

Hi,

ich habe gerade das CP/M-Stick-Layout (Peter Sieg) überarbeitet (ohne 
FTDI, für gängige USB-Sticks, etwas kleiner und für "günstigere" SD Card 
Reader.

Die Platinen sind bestellt, dauert aber eine Weile. Teile wie USB-Sticks 
und Reader habe ich auch... Bei Bedarf einfach melden.

Gruß
Marcel

von chris_ (Gast)


Lesenswert?

Nicht ganz so schlank wie CPM auf dem Atmega88, aber vielleicht trotzdem 
interessant: CPM auf dem Arduino Due.
http://sourceforge.net/projects/cpmduino/

von Peter S. (petersieg)


Lesenswert?

Marcel A. schrieb:
> Hi,
>
> ich habe gerade das CP/M-Stick-Layout (Peter Sieg) überarbeitet (ohne
> FTDI, für gängige USB-Sticks, etwas kleiner und für "günstigere" SD Card
> Reader.
>
> Die Platinen sind bestellt, dauert aber eine Weile. Teile wie USB-Sticks
> und Reader habe ich auch... Bei Bedarf einfach melden.
>
> Gruß
> Marcel

@Marcel: Das PCB Layout/Schaltung stammt von Joe G., nicht von mir.
Kannst du bitte deine Überarbeitete Version als Eagle Dateien hier zur 
Verfügung stellen? Welcher SD Slot ist jetzt verwendet?

Peter

von Marcel A. (dl1ekm)


Lesenswert?

Hallo Peter,

die egale-Datei ist auf meiner Homepage

http://www.retro-compi.de/index.php/cpm-z80-projekte/cpm-stick/cpmstick-hardware

unten zum Download verfügbar.

Es passen die Adapter z.B. von "Pollin" oder aus China. Ich habe auch 
gute Erfahrungen mit den Micro-SD-Slots von Pollin/China gemacht.

Gruß
Marcel

von petersieg (Gast)


Lesenswert?

Ahh. Super! Vielen Dank.

Peter

von Pruunz (Gast)


Lesenswert?

Gibt es irgendwo Layout Dateien der neuesten Version mit AVR Terminal ?

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Pruunz schrieb:
> Gibt es irgendwo Layout Dateien der neuesten Version mit AVR Terminal ?

Ja, bei mir. Sende mir einfach eine Mail.

von Christian D. (toast_r)


Lesenswert?

Ich spiele ja schon seit einiger Zeit gerne mit dem AVRCP/M rum.
Dabei habe ich inzwischen schon öfter den Wunsch nach einer freien 
RS232-Schnittstelle verspürt.
Man könnte diese dann prima für Dateiübertragungen zur 'richtigen' CP/M 
Systemen benutzen.
Die vorhandene ist ja ausschließlich fürs Terminal.

Inwieweit wäre sowas realisierbar ?

von Leo C. (rapid)


Lesenswert?

Am einfachsten wäre das mit einem UART an I2C zu realisieren. Dafür gibt 
fertige Chips, die aber teuer und schlecht erhältlich sind.
Vor einiger Zeit hatte ich mal angefangen, so einen I2C-UART mit einem 
ATTiny2313 zu realisieren. Mangels eigenem Bedarf und übertriebener 
Featuritis ist das Projekt irgendwann liegen geblieben.

von Nils S. (kruemeltee) Benutzerseite


Lesenswert?

> -itis

Entzündung?

Man kann auch einen Bitbanging UART auf freien Pins verwenden. Meistens 
ist auch keine echte bidirektionale Verbindung nötig, also kommt man auf 
dem Controller mit einem Pin aus, bei Bedarf als Eingang oder Ausgang.

von Leo C. (rapid)


Lesenswert?

Nils S. schrieb:
> Man kann auch einen Bitbanging UART auf freien Pins verwenden.

Klar

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Leo C. schrieb:
> Am einfachsten wäre das mit einem UART an I2C zu realisieren. Dafür gibt
> fertige Chips, die aber teuer und schlecht erhältlich sind.

Den SC16IS740 gibt es für 2,77€/Stück bei Mouser.

von Marcel A. (dl1ekm)


Lesenswert?


von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

AVR-CP/M-Propeller-Terminal

Hier mal was zum Testen. Neue/aufgebesserte Software für das Terminal. 
Liegt auch schon seit ein paar Tagen auf dem SVN-Server[1]. Ein paar 
Fehler wurden beseitigt, ein paar weitere VT100-Funktionen hinzu gefügt, 
und etwas schneller ist sie auch.

Ich habe vor, die Software noch weiter auszubauen und zu beschleunigen. 
Außerdem soll sie an die stand-alone Version des Terminals[2] angepaßt 
werden, zumal Joe mir eine Platine dafür geschenkt hat.



[1] 
http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/VT100/source/work/
[2] Beitrag "VT100-Terminal (VGA+PS2)"

von Xyz X. (Firma: xyz) (khmweb)


Lesenswert?

Peter Sieg schrieb:
> Warum? Weil es geht! Und weil es Spaß macht zu zeigen, das es geht..
> Und weil ein ATmega88 ca. 3€ kostet, eine solches DRam gibts in der
> Schrottkiste (sind z.B beim Amiga 500 verwendet worden..) also alles
> für ca. 6-8€..

Noch preiswerter, zum Nulltarif, aber hier wohl weniger von Reiz: CP/M 
unter Windows mittels kostenfreiem, seit vielen Jahren bewährtem Emu, z. 
B. via download von meiner site sharpmz.org. Dort gibts auch 
verschiedene CP/M-Versionen, haufenweise Spiele, tonnenweise Software, 
diskimages und und und... Der schnellste Weg, um CP/M zum Laufen zu 
bringen. Anleitung bei Interesse im eigenen Thread oder via PN.

: Bearbeitet durch User
von Leo C. (rapid)


Lesenswert?

Propeller-Terminal für die AVR-CP/M-Platine

Die Entwicklung der Software geht im Thread "VT100-Terminal (VGA+PS2)" 
hier

Beitrag "Re: VT100-Terminal (VGA+PS2)"

weiter, da die Hardwareunterschiede zwischen den beiden Terminals ja 
gering sind.

von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

Joe G. schrieb:
>> Am einfachsten wäre das mit einem UART an I2C zu realisieren. Dafür gibt
>> fertige Chips, die aber teuer und schlecht erhältlich sind.
>
> Den SC16IS740 gibt es für 2,77€/Stück bei Mouser.

Oder knapp 9€ für 5 Stück inclusive alles beim Ali.
Also gut, gestern sind sie angekommen, und mindestens einer funktioniert 
sogar. Deshalb gibts im SVN jetzt minimalen Support für den Chip. Die 
Register des UARTs sind zwischen 50H und 5FH in den I/O-Addressraum des 
Z80 gemappt, können also mit IN- und Out-Befehlen angesprochen werden. 
Einfache In- und Out-Routinen können dann z.B. so aussehen:
1
;----------------------------- ISC16IS740 UART -------------------------------
2
I2C_UART_PORT   equ     50H
3
4
I2C_UART_RHR    equ     I2C_UART_PORT+00H       ;R      Receive Holding
5
I2C_UART_THR    equ     I2C_UART_PORT+00H       ;W      Transmit Holding
6
I2C_UART_IER    equ     I2C_UART_PORT+01H       ;R/W    Interrupt Enable
7
I2C_UART_FCR    equ     I2C_UART_PORT+02H       ;W      FIFO Control
8
I2C_UART_IIR    equ     I2C_UART_PORT+02H       ;R      Interrupt Identification
9
I2C_UART_LCR    equ     I2C_UART_PORT+03H       ;R/W    Line Control
10
I2C_UART_MCR    equ     I2C_UART_PORT+04H       ;R/W    Modem Control
11
I2C_UART_LSR    equ     I2C_UART_PORT+05H       ;R      Line Status
12
I2C_UART_MSR    equ     I2C_UART_PORT+06H       ;R      Modem Status
13
I2C_UART_SPR    equ     I2C_UART_PORT+07H       ;R/W    Scratchpad
14
I2C_UART_TCR    equ     I2C_UART_PORT+06H       ;R/W    Transmission Control
15
I2C_UART_TLR    equ     I2C_UART_PORT+07H       ;R/W    Trigger Level
16
I2C_UART_TXLVL  equ     I2C_UART_PORT+08H       ;R      Transmit FIFO Level
17
I2C_UART_RXLVL  equ     I2C_UART_PORT+09H       ;R      Receive FIFO Level
18
I2C_UART_EFCR   equ     I2C_UART_PORT+0FH       ;R/W    Extra Features
19
I2C_UART_DLL    equ     I2C_UART_PORT+00H       ;R/W    divisor latch LSB
20
I2C_UART_DLH    equ     I2C_UART_PORT+01H       ;R/W    divisor latch MSB
21
I2C_UART_EFR    equ     I2C_UART_PORT+02H       ;R/W    Enhanced Feature
22
I2C_UART_XON1   equ     I2C_UART_PORT+04H       ;R/W    Xon1 word
23
I2C_UART_XON2   equ     I2C_UART_PORT+05H       ;R/W    Xon2 word
24
I2C_UART_XOFF1  equ     I2C_UART_PORT+06H       ;R/W    Xoff1 word
25
I2C_UART_XOFF2  equ     I2C_UART_PORT+07H       ;R/W    Xoff2 word
26
27
28
;-----------------------------------------------------------------------------
29
; Output character in C
30
; Return with character in  C and A
31
32
i2c_uart_out:
33
        IN   A,(I2C_UART_LSR)
34
        AND  20H
35
        JR   Z,i2c_uart_out     ; wait till ready
36
        LD   A,C
37
        OUT  (I2C_UART_THR),A
38
        RET
39
40
;-----------------------------------------------------------------------------
41
; Get character from I2C UART
42
; Return character in A
43
44
i2c_uart_in:
45
        IN   A,(I2C_UART_LSR)
46
        AND  01H
47
        JR   Z,i2c_uart_in     ; wait till ready
48
        IN  (I2C_UART_RHR),A
49
        RET

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Sehr schön!
Nun noch einen modernen DRAM (aktuell verfügbar) und das Z180 Projekt 
bekommt ernsthafte Konkurenz ;-)

von Leo C. (rapid)


Lesenswert?

Never, ever ;-)

Es sei denn, man tauscht auch noch den µC, z.B. gegen einen Cortex-M.

von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

Für den I2C-UART gibts jetzt ein Kermit. Damit er läuft braucht man die 
neueste Firmware. Beides als Binaries im Anhang. Die Kermit-Quellen sind 
vorläufig auf meinem Server[1], und kommen demnächst ins hiesige SVN.


[1] http://cloudbase.mooo.com/cgit/Kermit-80/

von Andreas R. (Gast)


Lesenswert?

Hallo,

ich habe mir kürzlich auch einen avrcpm-Rechner zusammengebaut mit 
ATmega328P, 20 MHz, 8bit DRAM und einer 1 GB SD-Karte.
Als Firmware hatte ich erst die Version 3.2 r154, dann Version 3.5 r242. 
Die Anbindung über RS232 zum PC läuft mit einem CP2102-Dongle und 115200 
baud. Einen I2C-UART habe ich noch nicht angeschlossen.
Ich habe dann probiert, Kermit-80 4.11 (zusammengebastelt nach der 
Anleitung ftp.kermit.columbia.edu/kermit/cpm80/cpkerm.pdf) zu verwenden:
Kermit läuft zwar unter CP/M im avrcpm und ich kann im Prinzip auch 
Dateien zwischen PC und avrcpm hin- und herschicken (ich verwende 
TeraTerm und dessen eingebautes Kermit-Protokoll auf der PC-Seite), aber 
die Transferrate ist mit ca. 20 Bytes/s nicht brauchbar.

Ich habs so probiert: auf der CP/M-Seite kerm411.com gestartet und die 
folgenden Befehle im Kermit abgesetzt:
set local-echo on
set port crt
receive
danach in TeraTerm mit File/Transfer/Kermit/Send... eine Datei 
ausgewählt und übertragen. Diese ist dann im CP/M System auch 
angekommen, aber mit nur ca. 20 Bytes/s.

Die umgekehrte Richtung geht auch:
im CP/M-Kermit diese Befehle absetzen:
set local-echo on
set port crt
send foo.bar
dann in TeraTerm File/Transfer/Kermit/Receive
foo.bar kommt dann auf dem PC an, aber auch nur mit der langsamen 
Transferrate von ca. 20 Byte/s.

Mache ich da irgendwas grob falsch? Der Kermit-Transfer funktioniert ja 
im Prinzip, aber ich verstehe nicht, warum die Transferrate so klein 
ist...

Gruss,

Andreas

von Marcel A. (dl1ekm)


Lesenswert?

Hallo Andreas,

ich hatte das auch schon für die Z180 Stamp gebaut. Aber dort habe ich 
für die "Console" und die Kermit-Schnittstelle zwei unterschiedliche 
Ports genommen. Mich wundert, dass das überhaupt über die gleiche 
geht...?

Gruß
Marcel

von Leo C. (rapid)


Lesenswert?

Andreas R. schrieb:
> Ich habe dann probiert, Kermit-80 4.11 (zusammengebastelt nach der
> Anleitung ftp.kermit.columbia.edu/kermit/cpm80/cpkerm.pdf) zu verwenden:

Du hast ein "Generic Kermit-80" gebaut?

> set local-echo on

Das dürfte für Dateiübertragung keine Rolle spielen. Im Zweifelsfall ist 
es eher kontraproduktiv.

> set port crt

Das dürfte überflüssig sein, weil die IOBYTE-Funktionalität im 
AVR-CP/M-BIOS nicht implementiert ist.

Versuch' mal noch ein:
set terminal quiet

Dann werden während der Dateiübertragung keine Zeichen auf die Console 
ausgegeben.

> Mache ich da irgendwas grob falsch? Der Kermit-Transfer funktioniert ja
> im Prinzip, aber ich verstehe nicht, warum die Transferrate so klein
> ist...

Marcel A. schrieb:
> Mich wundert, dass das überhaupt über die gleiche
> geht...?

me too.

von Andreas R. (Gast)


Lesenswert?

Hallo,

danke für die Rückmeldungen.

Leo C. schrieb:
> Andreas R. schrieb:
>> Ich habe dann probiert, Kermit-80 4.11 (zusammengebastelt nach der
>> Anleitung ftp.kermit.columbia.edu/kermit/cpm80/cpkerm.pdf) zu verwenden:
>
> Du hast ein "Generic Kermit-80" gebaut?
>

Genau...

>> set local-echo on
>
> Das dürfte für Dateiübertragung keine Rolle spielen. Im Zweifelsfall ist
> es eher kontraproduktiv.
>

Stimmt, wie sich herausgestellt hat, macht dieser Befehl keinen 
Unterschied...

>> set port crt
>
> Das dürfte überflüssig sein, weil die IOBYTE-Funktionalität im
> AVR-CP/M-BIOS nicht implementiert ist.

Dieser Befehl ist aber offenbar (bei mir zumindest) nötig, sonst bekomme 
ich gar keine Kermit-Verbindung hin...

> Versuch' mal noch ein:
> set terminal quiet
>
> Dann werden während der Dateiübertragung keine Zeichen auf die Console
> ausgegeben.

Das hat bei mir nichts gebracht, d.h. die Transferrate ist immer noch 
bei ca. 20 Bytes/s :-(

>> Mache ich da irgendwas grob falsch? Der Kermit-Transfer funktioniert ja
>> im Prinzip, aber ich verstehe nicht, warum die Transferrate so klein
>> ist...
>
> Marcel A. schrieb:
>> Mich wundert, dass das überhaupt über die gleiche
>> geht...?
>
> me too.

Geht es vielleicht, weil ich TeraTerm unter Windows benutze? Ich habs 
noch nicht unter Linux (mit z.B. minicom) probiert...

Danke und Gruss,

Andreas

von Leo C. (rapid)


Lesenswert?

Inzwischen habe ich mir auch ein "Kermit-80 v4.11 configured for Generic 
CP/M-80 with VT100" gebaut und einiges ausprobiert. Im Grunde hätte aber 
etwas Nachdenken und ein Blick in den Sourcecode gereicht, um darauf zu 
kommen, daß das nicht funktionieren kann. ;-)

Das Kermit-Programm fragt während der Übertragung eines Pakets auch 
immer die Consolenschnittstelle ab, damit der Benutzer die Übertragung 
ggf. abbrechen kann (Funktion inchr in cpspk2.asm). Da Com.- und 
Consolenschnittstelle aber die Gleiche ist, werden dadurch Zeichen, die 
zu Datenpaketen gehören, als Consoleninput gelesen, und verworfen.

Wenn man die Consolenabfragen an den entsprechenden Stellen rauswerfen 
würde, könnte es funktionieren...

von Andreas R. (Gast)


Lesenswert?

Hallo,

Leo C. schrieb:
> Inzwischen habe ich mir auch ein "Kermit-80 v4.11 configured for
> Generic
> CP/M-80 with VT100" gebaut und einiges ausprobiert. Im Grunde hätte aber
> etwas Nachdenken und ein Blick in den Sourcecode gereicht, um darauf zu
> kommen, daß das nicht funktionieren kann. ;-)
>
> Das Kermit-Programm fragt während der Übertragung eines Pakets auch
> immer die Consolenschnittstelle ab, damit der Benutzer die Übertragung
> ggf. abbrechen kann (Funktion inchr in cpspk2.asm). Da Com.- und
> Consolenschnittstelle aber die Gleiche ist, werden dadurch Zeichen, die
> zu Datenpaketen gehören, als Consoleninput gelesen, und verworfen.
>
> Wenn man die Consolenabfragen an den entsprechenden Stellen rauswerfen
> würde, könnte es funktionieren...

Vielen Dank Leo, das war der entscheidende Hinweis!

Ich habe in cpspk2.asm, Zeile 936 den Befehl
  call  inpcon    ; Try to get a character from the console
durch drei NOPs ersetzt - nun kriege ich vernünftige 
Kermit-Datenübertragungsraten hin (ca. 700 Byte/s für PC->avrcpm und ca. 
1.4 kByte/s für avrcpm->PC). Ich verwende TeraTerm unter Windows - ich 
werde aber auch noch minicom unter Linux testen. Ausserdem muss ich noch 
weitere Tests machen zur Zuverlässigkeit der Datenüebertragung.
Konkret habe ich aber nicht den Kermit-Sourcecode geändert und neu 
kompiliert, sondern mein kerm411.com gepatcht: die Bytefolge "CD 1A 70" 
bei Offset 2A19 wurde durch "00 00 00" ersetzt.

Ich glaube, nun haben wir einen bequemen Weg, Dateien von und zum avrcpm 
zu übertragen, ohne jedesmal mit der SD-Karte hantieren zu müssen. Was 
fehlt ist halt die Möglichkeit, die Datenübertragung zu unterbrechen - 
man muss wohl den avrcpm mit dem Resettaster neu starten, falls das 
nötig ist...

Grüsse und schönes Wochenende,

Andreas

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Leo C. schrieb:
> Für den I2C-UART gibts jetzt ein Kermit.

Prima, läuft...

A>kerm411
Kermit-80 v4.11 configured for AVR-CP/M with VT100
UART detected, crystal frequency: 11.0592 MHz.

von Jens (Gast)


Lesenswert?

Da hat das ganze mal jemand auf einem Arduino Nano umgesetzt:
https://acdc.foxylab.com/node/76

Das einzige zusätzliche Bauteil ist eine SD-Karte, die auch gleich als 
RAM herhalten muß.

Hier noch das passende Video, für die, die kein Russisch können oder 
Google-Translate nicht kennen:
https://youtu.be/LHFmt3qWAuY

Grüße,
Jens

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Danke für die Info!
Eine sehr interessante Lösung, die SD-Card gleich als RAM zu nutzen. 
Warum sind wir nicht darauf gekommen :-( Einzig die Umsetzung in GO 
scheint mir recht langsam und die Beschränkung auf einen 8080. Aber mit 
einer Micro-SD sollte nun ein CP/M in einem kleinen USB-Stick Gehäuse 
möglich sein :-)

von Leo C. (rapid)


Lesenswert?

Joe G. schrieb:
> Eine sehr interessante Lösung, die SD-Card gleich als RAM zu nutzen.

Stimmt.

> Warum sind wir nicht darauf gekommen :-( Einzig die Umsetzung in GO

Weil "uns" sogar SPI-RAM schon zu langsam war. Siehe 
Beitrag "Re: CP/M auf ATmega88" ff.

von Leo C. (rapid)


Lesenswert?

Joe G. schrieb:
> Einzig die Umsetzung in GO scheint mir recht langsam

Wenn ich den durch Google-Translate gedrehten Text richtig verstehe, ist 
nur das PC-Programm zum Senden einer Hex-Datei an den Arduino, in Go 
geschrieben. Von der Arduino-Software (Monitor und Emulator) habe ich 
keine Quellen gefunden.

> und die Beschränkung auf einen 8080.

Reicht für mindestens 99% aller verfügbaren CP/M Programme. Aber soll ja 
trozdem noch geändert werden.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Leo C. schrieb:
> nur das PC-Programm zum Senden einer Hex-Datei an den Arduino, in Go
> geschrieben.

Stimmt, habe ich dann auch gelesen. Mein Russisch ist echt eingerostet, 
ich habe buchstabiert wie ein Anfänger :-(
Den Simulator hat er offensichtlich selbst programmiert ohne das die 
Quellen derzeit verfügbar sind.
"я решил две задачи - создал эмулятор процессора Intel 8080."

: Bearbeitet durch User
von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Joe G. schrieb:
> Den Simulator hat er offensichtlich selbst programmiert ohne das die
> Quellen derzeit verfügbar sind.

Sind jetzt verfügbar [1], alles in C++ umgesetzt.

[1] https://github.com/Dreamy16101976/cpm4nano

von Jens (Gast)


Angehängte Dateien:

Lesenswert?

Leo C. schrieb:
>> Offenbar verändert SYSGEN die Laufwerkscharakteristik.
>
> SYSGEN kopiert höchstwahrscheinlich ab Track 0, Sektor 1, weil auf
> Floppies die Sektornumerierung bei 1 beginnt. Da unsere Sektor-zählung
> bei 0 beginnt, wird der erste Sektor nicht mitkopiert. Dieser enthält
> beim simh-Format nicht nur den IPL, sondern auch eine Formatkennung.
> Wenn diese nach dem Kopieren fehlt, wird das (ursprünliche)
> AVRCPM-Standardformat angenommen.
>
> Wenn Du das SYSGEN mal anpassen willst, kannst Du Dich an unserem IPL
> orientieren, oder die Diskgeometrie aus dem BIOS auslesen, und dann
> konsequenter weise auch die BIOS-Funktion für Sector-Translate
> verwenden.
Das habe ich jetzt gemacht. Ich habe syscop.c [1] für unsere Zwecke 
modifiziert.
Als Compiler habe ich BDS-C verwendet:
1
C>CC AVRSYSCP
2
BD Software C Compiler v1.60  (part I)
3
  24K elbowroom
4
BD Software C Compiler v1.60 (part II)
5
  25K to spare
6
C>CLINK AVRSYSCP
7
BD Software C Linker   v1.60
8
9
Last code address: 2BCE
10
Externals start at 2BCF, occupy 0006 bytes, last byte at 2BD4
11
Top of memory: DA05
12
Stack space: AE31
13
Writing output...
14
  35K link space remaining

Anschließend kann man entweder die Systemspuren in eine Datei sichern:
1
C>AVRSYSCP A: SYSTRKS.BIN 52

oder -tada- eine Datei in die Systemspuren schreiben:
1
C>AVRSYSCP CPM.BIN A:

Wenn ich das richtig verstanden habe, muß bei 8MB-Images die 
Formatkennung "<CPM_Disk>" am Ende des ersten Sektors (0x76...0x7f) 
stehen, damit das modifizierte Image funktioniert.

Die Anpassung dafür könnte in IPL.MAC stattfinden.
Ein weiteres .org im Quelltext führt zu einem
1
B>m80 =ipl8m/m
2
P                                       org     176h
3
4
1 Fatal error(s)
Weiß jemand, wie man das richtig macht?

Viele Grüße,
Jens


[1] 
http://www.classiccmp.org/cpmarchives/cpm/Software/WalnutCD/cpm/utils/dskutl/syscop.c

von Leo C. (rapid)


Lesenswert?

Jens schrieb:
> Ein weiteres .org im Quelltext führt zu einem
> B>m80 =ipl8m/m
> P                                       org     176h

Das ".org" hast Du am Ende vor dem "end" eingefügt?

Wahrscheinlich mußt Du davor noch ein ".dephase" schreiben.

von Jens (Gast)


Lesenswert?

Leo C. schrieb:
> Wahrscheinlich mußt Du davor noch ein ".dephase" schreiben.
Ja, das scheint zu klappen.

Ich habe auch noch einen anderen Weg gefunden.
Wenn man mit DDT die Teile zusammenlinkt, kann man noch die folgenden 
Kommandos anhängen:
1
S176
2
3C
3
43
4
50
5
4D
6
5F
7
44
8
69
9
73
10
6B
11
3E
12
.
13
D170

Danke,
Jens

von Ronny M. (hobby-coder)


Lesenswert?

Hallo Ihr,

ich kann ein AVR CP/M Stick in der Rev.3 (USB Stick Form) bekommen, 
inkl. USB TTL Wandler, welcher afaik als Terminal Zugang dient.

Ich komme aus der DOS Zeit, bzw. dem ehem. DDR BIC 5105/ 5110.

Ich habe mir schon einige CP/M Emulatoren geholt, um üben zu können. Ich 
scheitere aber am erstellen der Disketten, bzw. am einbinden/ mounten 
der Disketten. Ich habe JAZE 2.04.x und einen Z80 Emulator getestet. Bei 
JAZE 2.4.x habe ich mir eine Diskette erstellt, bekomme aber die 
herunter geladenen Programme nicht auf die virtuelle Diskette... Den Z80 
Emulator 1.0.10.x bekomme ich nicht einmal gestartet. Was das angeht, 
ist JAZE doch einfacher zu starten, da dieser vorkonfiguriert ist und 
eine CP/M Version bei liegt.

Ich möchte mir gerne ein solchen Stick holen, um die frühere Zeit der 
Computer kennen zu lernen. Ich habe und hatte ältere Computer, will aber 
etwas näher an die Wurzeln heran. Bevor ich das aber mache, will ich das 
zuerst einmal Virtuell sehen.

Wer kann mir einen Emulator empfehlen, wo ich CP/M für Z80, bzw. den 
i8080 testen kann, bevor ich mir einen solchen Stick bauen lasse?

LG Ronny

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Ronny M. schrieb:
> Wer kann mir einen Emulator empfehlen, wo ich CP/M für Z80, bzw. den
> i8080 testen kann

YAZE hast du ja schon genannt. Neben vielen anderen 
Simulationsprogrammen gibt es noch AltairZ80 [1]. Dort lassen sich u.a. 
verschiedene Betriebssysteme u.a. CP/M, simulieren.

[1] http://schorn.ch/index.html

von Ronny M. (hobby-coder)


Lesenswert?

Joe G. schrieb:
> Ronny M. schrieb:
>> Wer kann mir einen Emulator empfehlen, wo ich CP/M für Z80, bzw. den
>> i8080 testen kann
>
> YAZE hast du ja schon genannt. Neben vielen anderen
> Simulationsprogrammen gibt es noch AltairZ80 [1]. Dort lassen sich u.a.
> verschiedene Betriebssysteme u.a. CP/M, simulieren.
>
> [1] http://schorn.ch/index.html

Ich bekomme leider keine Diskimages für Yaze erstellt, bzw. keine 
Programme in eine *ydsk rein geschoben.. Weist Du, wie das geht?

Danke für dem Tipp zum Altair Emulator. Ich denke aber, dieser passt 
nicht zum Rev. 3 Board. Da ist wohl YAZE passender. Nur, wie bekomme ich 
eine Datei, ein Program auf die *.ydsk...?

Vielen Dank für die Hilfe :)

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Ronny M. schrieb:
> Danke für dem Tipp zum Altair Emulator. Ich denke aber, dieser passt
> nicht zum Rev. 3 Board. Da ist wohl YAZE passender.

Mit YAZE habe ich noch nicht gearbeitet aber was hat die Rev. 3 was 
anders sein sollte? Ist doch auch nur ein AVR mit RAM. Und CP/M ist 
CP/M. Ich hatte damals alle meine Laufwerke unter dem AltairZ80 
erstellt.

von Ronny M. (hobby-coder)


Lesenswert?

Hallo,

das hat sich inzwischen erledigt. YAZE habe ich wieder gelöscht. SIMH 
Altair Z80 hat die Aufgabe der Emulation übernommen. Aber auch das hat 
sich in einigen Tagen erledigt. Peter Sieg hat in der Bucht ein Set aus 
CPM Stick + USB-Serial Adapter angeboten, welches ich mir gekauft habe.

Das ganze ist in wenigen Tagen bei mir. Die CPM Tools zum erstellen 
eigener *.dsk "Disketten" habe ich mir auch schon geholt. Ein wenig 
Software legt er mir auch noch bei. Und, ein wenig Software findet man 
ja noch im Netz :)

von Marcel A. (dl1ekm)


Lesenswert?

Na denn. Auch ich habe hier noch einige Sticks (Platine) und jede Menge 
4-bit RAM und was man sonst so braucht vorrätig...
Schau mal auf meine HP...

von Ronny M. (hobby-coder)


Lesenswert?

Marcel A. schrieb:
> Na denn. Auch ich habe hier noch einige Sticks (Platine) und jede Menge
> 4-bit RAM und was man sonst so braucht vorrätig...
> Schau mal auf meine HP...

Eine mit dem VGA Anteil hätte ich noch gerne. Das aber ein anderes mal, 
bei mir steht bald ein Umzug an...

von Ronny M. (hobby-coder)


Angehängte Dateien:

Lesenswert?

Hallo Ihr,

evtl. kann mir jemand bei der Lösung eines Problems helfen.

Ich habe ja den CPM Stick gekauft und eine CD mit Tools usw. bekommen. 
Auf der CD sind auch ein paar Disk/HD Images. Ich kann den Stick sauber 
booten und auf das Laufwerk B zugreifen. Laufwerk B ist ein 
Festplattenimage mit 8MB größe.

Allerdings sehe ich nur den Inhalt der ersten 256kb... Mit B: komme ich 
sauber auf die Festplatte,  "stat" zeigt mir ein Freiraum von ca. 7.7MB 
an. Auf der HDD sind aber mehr Programme...

Ich habe einige Programme aus der Batch Datei, die mir die DiskImages 
erstellt, auskommentiert. In ADA usw. programmiere ich nicht...

Ich habe die Batch Dateien, womit ich mir meine Images erzeugt habe, 
einmal angehangen.

Ich sehe weder mit der originales Batch Datei, noch mit meinen 
Änderungen alle Dateien auf der HDD. Muss ich evtl. einen bestimmten 
Bereich ansprechen? Ein B: scheint ja nicht zu reichen....

Ich komme nicht aus der CPM Zeit. Ich bin erst Ende der 80er Jahre, mit 
DOS und dem Robotron BIC5105, bzw. BIC 5110 in die PC Welt 
eingestiegen...

von Peter S. (petersieg)


Lesenswert?

Hi.
Die einzelnen Applikationen sind in sog. Userbereiche kopiert - siehe 
Batch Datei.
Umschalten mit z.B. user 1
(2, 3,...)

Das war eine Vorstufe der Unterverzeichnisse.

So hat man alles sauber getrennt und nicht Ada mit C oder Pascal 
vermischt.

Peter

von Ronny M. (hobby-coder)


Lesenswert?

Afaik hat CPM weder Unterverzeichnisse, noch Userkonten... Oder, habe 
ich hier einen Denkfehler...?

von Peter S. (petersieg)


Lesenswert?

CP/M hat ebend keine Unterverzeichnisse.
Und auch keine Userkonten ala Unix etc.
ABER: Sog. User Bereiche. Das ist nichts weiter als das die Dateien 
einem Userbereich zugeordnet werden und in der Anzeige NUR die Dateien 
angezeigt werden, die zum aktuellen Userbereich gehören. Physikalisch 
liegt alles im Rootverzeichnis.
Umschaltung mit user n.

Lies dir doch bitte mal ein CP/M Handbuch durch.

Googlen geht aber auch:
http://www.primrosebank.net/computers/cpm/cpm_cookbook_user.htm


Peter

von Ronny M. (hobby-coder)


Lesenswert?

Kannst Du, oder jemand anderes, mir ein passendes Buch empfehlen? Ich 
habe, im 64er Forum - oder besser gesagt - deren Datengrab, ein wenig 
Einsteigerliteratur gefunden. Aber, keines hiervon sprach das "user x" 
Thema an..."

von Peter S. (petersieg)


Lesenswert?


: Bearbeitet durch User
von Ronny M. (hobby-coder)


Lesenswert?

Vielen Dank :)

Eine Frage zum Schluss noch: Wie kann ich mbasic/ Basic 80 beenden und 
zurück zu CPM kommen? ein ^c, ^x oder ^q brachte kein Erfolg. Ich muss 
SIMH, bzw. den Stick resetten, um wieder zum BDOS zurück zu kommen... 
Hatte M$ damals keine Exit- Routine eingebaut...? "quit", "bye" oder 
"exit" bringt auch kein Erfolg.

Btw: das ist echt ein nettes kleines Spielzeug :)

von Stefan (Gast)


Lesenswert?

system

von Ronny M. (hobby-coder)


Lesenswert?

Stefan schrieb:
> system

Danke :) Damit sind meine Fragen beantwortet. Wenn ich doch wieder 
welche habe, schreibe ich das hier rein :)

von David R. (retrogadgets)


Lesenswert?

I have the cpm stick 3.1 board with the atmega 328, 2x TC514256AP-70 
drams but nothing showing on the serial port, nor is the sd card being 
read.

question, does the atmega show anything through the serial terminal 
before reading the sd card, so i can rule out the atmega is programmed 
correctly with the correct fuse settings.

any help would be appreciated.

von David R. (retrogadgets)


Lesenswert?

...

von Horst S. (h3aau)


Lesenswert?

moin,
hat schon mal einer darüber nachgedacht das ganze auf einen 
STM32F103P6T8 zu bringen? wäre doch auch eine nette sache.

von Horst S. (h3aau)


Lesenswert?

meine natürlich den STM32F103C8T6............... sorry

von Tom (Gast)


Lesenswert?

David R. schrieb:
> question, does the atmega show anything through the serial terminal
> before reading the sd card,
You should see something like:
1
CPM on an AVR, v3.2 r0
2
Testing RAM: fill...wait...reread...
3
Initing mmc...

von Tom (Gast)


Lesenswert?

Horst S. schrieb:
> hat schon mal einer darüber nachgedacht das ganze auf einen
> STM32F103P6T8 zu bringen? wäre doch auch eine nette sache.
Der Z80-Emulator ist in feinstem AVR-Assembler geschrieben, das portiert 
man nicht mal so eben.
Welche Vorteile versprichst Du Dir von STM32-Variante?

von Joerg W. (joergwolfram)


Lesenswert?

Man könnte halt auf das DRAM verzichten und hätte ggf. mehr Speed.


Beim STM32F103C8T6 bräuchte man aber wieder externes RAM, der hat intern 
nur 20K. Sinnvoller wäre etwas mit 64K oder mehr. Oder noch besser 128K 
RAM, da könnte man auch die Videoausgabe mit reinmachen. Also z.B. ein 
STM32F405RG. Wobei sich dann trotzdem die Frage stellt, ob sich der 
Aufwand lohnt. Denn es gibt ja schon die AVR-Variante, die recht gut 
funktioniert. Und ich denke auch, dass das Interesse an solchen 
Projekten eher nachlässt. Leider...

Jörg

von Andreas J. (antibyte)


Lesenswert?


von S. R. (svenska)


Lesenswert?

Für ARMe gibt's schon fertige Z80-Emulationen. Die sind meist in C 
geschrieben, weil dank der deutlich höheren Taktgeschwindigkeit die 
Emulation nicht extrem performen muss. Als Ausgleich ist die Emulation 
akkurater (d.h. das Zeitverhalten entspricht dem Original).

von David R. (retrogadgets)


Lesenswert?

I see on the forum different fuse setting for the atmega 328, which 
should i use?

von David R. (retrogadgets)


Lesenswert?

avrdude -c usbasp -p m328p -e -U flash:w:avrcpm.hex
avrdude -c usbasp -p m328p -U lfuse:w:0xf7:m -U hfuse:w:0xdf:m

ive used the above is this correct

von Martin (Gast)


Lesenswert?

Habe mir einen AVR-CP/M Stick V3.1 zusammengebaut.
Tolles Projekt - schon erstaunlich, was in dem kleinen Ding mit grossem 
Assembler-Quellcode-Herz steckt.

Wenn ich den Microsoft FORTRAN 3.44 Compiler ausprobiere, bekomme ich 
einen Fehlerabbruch.

Der gleiche Compiler funktioniert auf dem Z80-CP/M Subsystem in meinem 
HP-86, an der Software liegt es also nicht.
1
C>user 7
2
3
C>type hello.for
4
      PROGRAM MAIN
5
      print *, 'Hello World!'
6
      END
7
8
C>f80 HELLO=HELLO
9
FORTRAN-80 Ver. 3.4 Copyright 1978, 79, 80 (C) By Microsofô
10
BYTES: 31663
11
Š1            PROGRAM MAIN
12
2             print *, 'Hello World!'
13
*****‰0000'     LD      BC¬$$L
14
*****‰0003'     JP‰$INIT
15
?Line: 2 Statement Unrecognizable or Misspelleä:PRIN
16
3             END
17
*****‰0006'     CALL‰$EX
18
19
Program Unit Length½0009 (9)
20
 Bytes
21
Data Area Length½0001 (1) Bytes
22
23
Subroutines Referenced:
24
Š$INIT                  $EX
25
26
Variables:
27
Š
28
Labels:
29
Š$$L    0006'
30
Š1 Fatal Error(s) Detected
Merkwürdig sind die ersten und letzten Buchstaben der Fehlermeldungen.
Diese Zeichen haben jeweils bit 7 gesetzt.

Š = 0x8A = 1000.1010, bit 7 gelöscht: 0000.1010 = 0x10 = '\n'
½ = 0xBD = 1011.1101, bit 7 gelöscht: 0011.1101 = 0x3D = '='
ä = 0xE4 = 1110.0100, bit 7 gelöscht: 0110.0100 = 0x64 = 'd'

Auch wird PRINT nur verkürzt ausgegeben.

Hat jemand diesen FORTRAN Compiler auf dem AVR-CP/M laufen?
Kann es sein, dass hier noch Z80 opcodes fehlen?

Alle anderen Programme, incl. C Compiler etc. scheinen gut zu laufen, 
nur der F80 nicht.

Hat jemand ein kleines Fortran Beispielprogramm mit PRINT oder WRITE, 
das läuft?

Martin

von Leo C. (rapid)


Lesenswert?

> Habe mir einen AVR-CP/M Stick V3.1 zusammengebaut.

Welche Firmware-Version hast Du auf dem Stick?

> Kann es sein, dass hier noch Z80 opcodes fehlen?

Sicher nicht. Zumal der F80 ziemlich sicher ein reines 8080 Progamm ist.
Ich dachte zuerst an ein Timing-Problem mit der seriellen Schnittstelle. 
Da aber nicht nur die Ausgabe vermurkst ist, sondern auch Fehler beim 
compilieren sind, wird es wohl was anderen sein.
Ich schau mal rein.

von Martin (Gast)


Lesenswert?

... warte nochmal, bevor Du suchst ... der Compilerfehler ist 
wahrscheinlich eher ein Problem meinerseits mit dem Uralt-Fortran. Ich 
teste heute abend nochmal weiter.

Unabhängig davon: die gesetzten 7.bit im den Fehlermeldungen könnten 
vielleicht verwendet worden sein um die Zeichenattribute für ein 
Terminal zu steuern? Eventuell ist der Compiler für den TRS-80 und der 
versteht so etwas z.B. für inverse Ausgabe oder ähnliches? Andere 
Terminals maskieren dieses 8. Bit dann einfach weg. Ich habe 
Windows/Teraterm mit 8 Datenbits + 1 Stop bit verwendet.

Martin

von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

Martin schrieb:
> ... warte nochmal, bevor Du suchst ... der Compilerfehler ist
> wahrscheinlich eher ein Problem meinerseits mit dem Uralt-Fortran. Ich

Zu spät. ;)

> Wenn ich den Microsoft FORTRAN 3.44 Compiler ausprobiere, bekomme ich
> einen Fehlerabbruch.

Das ist wahrscheinlich der neueste FORTRAN Compiler den es von Microsoft 
für CP/M gibt. Den gleichen habe ich inzwischen auch ausprobiert.

> Der gleiche Compiler funktioniert auf dem Z80-CP/M Subsystem in meinem
> HP-86, an der Software liegt es also nicht.

Das der Dein hello.for übersetzt hat, glaube ich jetzt nicht. MS FORTRAN 
3.4 ist im wesentlichen ein FORTRAN-66 Compiler und hat definitiv keinen 
PRINT-Befehl.

> Unabhängig davon: die gesetzten 7.bit im den Fehlermeldungen könnten
> vielleicht verwendet worden sein um die Zeichenattribute für ein
> Terminal zu steuern?

Bei mir kommen diese Bits nicht. Das scheint mir eher ein 
Hardware-Problem oder ein Problem mit Deinr AVRCPM Firmware-Version 
(welche?) zu sein.

> Ich habe
> Windows/Teraterm mit 8 Datenbits + 1 Stop bit verwendet.

Das sollte passen.

1
CPM on an AVR, v3.5 r242
2
Testing RAM: fill...wait...reread...
3
Initing mmc...
4
5
A: CP/M partition at: 001, size: 7811KB.
6
B: FAT16 File-Image 'A' at: 3766, size: 8192KB.
7
C: FAT16 File-Image 'B' at: 859, size: 8192KB.
8
D: FAT16 File-Image 'C' at: 003, size: 8192KB.
9
E: FAT16 File-Image 'E' at: 375, size: 2048KB.
10
F: FAT16 File-Image 'F' at: 504, size: 1024KB.
11
G: FAT16 File-Image 'H' at: 586, size: 256KB.
12
H: FAT16 File-Image 'I' at: 603, size: 256KB.
13
Partinit done.
14
Ok, Z80-CPU is live!
15
16
62k cp/m vers 2.2
17
18
A>b:
19
B>f80 =hello
20
MAIN
21
22
?Line: 2 Statement Unrecognizable or Misspelled:PRIN
23
24
?1 Fatal Error(s) Detected
25
26
B>type hello2.for
27
      PROGRAM MAIN
28
      WRITE(1,200)
29
200   FORMAT(1X,'Hello World!')
30
      END
31
32
B>f80 =hello2 
33
MAIN
34
35
B>l80 hello2,hello2/n/e
36
37
Link-80  3.44  09-Dec-81  Copyright (c) 1981 Microsoft
38
39
Data    0103    1A0B    < 6408>
40
41
39529 Bytes Free
42
[0117   1A0B       26]
43
44
B>hello2
45
46
Hello World!
47
48
B>


Nachtrag:
Falls Du tatsächlich eine modifizierte Compilerversion haben solltest:
Im Anhang ist ein Diskimage mit dem Compiler den ich zum Testen 
verwendet habe.
Handbuch gibts hier:
http://www.textfiles.com/bitsavers/pdf/microsoft/cpm/Microsoft_FORTRAN-80_Ver3.4_Users_Manual_Nov80.pdf

: Bearbeitet durch User
von Martin (Gast)


Lesenswert?

Danke für die Mühe.

Ich hatte ein Disk Image CPMDSK_D.IMG verwendet. Dort lag unter USER 7 
ein Programm HELLO.FOR. Damit bekam ich gleich die Fehlermeldungen und 
die "merkwürdigen" Zeichen und glaubte dass da etwas größeres nicht 
stimmt.
Wie Du schreibst, ist das Programm aber nicht für FORTRAN IV (oder 66?) 
geeignet. Ich hatte dann gestern abend noch ein eigenes Testprogramm 
geschrieben und das funktioniert. Entschuldigung für die Verwirrung.

Wenn ich allerdings einen Syntaxfehler in das Programm einbaue, kommen 
wieder diese Zeichen mit gesetztem 7.Bit. Das müsste bei Dir auch der 
Fall sein?
Vielleicht verwenden bestimmte Terminals das 7.Bit um invers oder fett 
darzustellen (es gab auch eine Version dieses Fortrans für den TRS/80, 
vielelicht versteht der das).  Das ist aber kein wirkliches Problem.

Mein (jetzt erfolgreicher) Test:
1
CP/M on AVR, v3.2 r155
2
Testing RAM: fill...wait...verify...
3
Reading SD card...
4
5
A: FAT16 Image 'A' at: 002, size: 256 KB.
6
B: FAT16 Image 'B' at: 266, size: 256 KB.
7
C: FAT16 Image 'D' at: 274, size: 8192 KB.
8
D: FAT16 Image 'E' at: 010, size: 8192 KB.
9
Partinit done.
10
Ramdisk found.
11
Ok, Z80-CPU is alive!
12
13
ipl <<<<<<<<<<<<<< Was bedeutet das? Aus welcher .asm Quelle kommt das?
14
62k cp/m vers 2.2
15
16
A>C:
17
C>USER 7
18
19
C>TYPE HELLO.FOR
20
      PROGRAM HELLO
21
      INTEGER I, IUNIT
22
      REAL X,Y
23
      IUNIT=6
24
      WRITE(5,100)
25
C     0 = current drive
26
C     3 = drive C:
27
      CALL OPEN(IUNIT,11HHELLO   TXT,3)
28
      DO 50 I=1,100
29
         X=FLOAT(I)/10.0
30
         Y=SIN(X)
31
         WRITE(IUNIT,200) X,Y
32
50    CONTINUE
33
34
100   FORMAT(15H Hello FORTRAN!)
35
200   FORMAT(1H ,F12.3,3H = ,F12.3)
36
      END
37
38
39
C>F80 HELLO=HELLO
40
HELLO
41
42
C>L80 HELLO/N,HELLO/E
43
44
Link-80  3.44  09-Dec-81  Copyright (c) 1981 Microsoft
45
46
Data    0103    1E69    < 7526>
47
48
37999 Bytes Free
49
[0139   1E69       30]
50
51
C>HELLO
Schreibt "Hello FORTRAN" auf die LST device (Terminal)
Erstellt Datei 'HELLO.TXT' mit X,Y Werten.

von Leo C. (rapid)


Lesenswert?

> Ich hatte ein Disk Image CPMDSK_D.IMG verwendet. Dort lag unter USER 7
> ein Programm HELLO.FOR.

Und F80.COM befindet sich ebenfalls auf diesem Image?
Wo finde ich das Image? Oder kannst Du es mir zukommen lassen?

> Wenn ich allerdings einen Syntaxfehler in das Programm einbaue, kommen
> wieder diese Zeichen mit gesetztem 7.Bit. Das müsste bei Dir auch der
> Fall sein?

Nein, die Zeichen kommen bei mir nicht.

> Vielleicht verwenden bestimmte Terminals das 7.Bit um invers oder fett
> darzustellen (es gab auch eine Version dieses Fortrans für den TRS/80,
> vielelicht versteht der das).

Das mag durchaus sein, aber mMn müßten die Bits dann anders verteilt 
sein. Für mich sieht das eher nach Übertragungsfehler aus.

> Das ist aber kein wirkliches Problem.

Für mich schon, solange die Ursache nicht klar ist.
Deshalb hätte ich gerne das Disk Image.

> Mein (jetzt erfolgreicher) Test:CP/M on AVR, v3.2 r155

Zwar nicht uralt, aber auch nicht die neueste Version. Du könntest auf 
v3.5 updaten.

> Ok, Z80-CPU is alive!
>
> ipl <<<<<<<<<<<<<< Was bedeutet das? Aus welcher .asm Quelle kommt das?
> 62k cp/m vers 2.2

Das ist der "Initial Prgram Loader".
Der Bootloader im ersten Sektor der Disk, der das CP/M (CCP+BDOS+BIOS) 
aus den reservierten Systemspuren ins RAM läd.
Sourcecode ist in cpm/IPL.MAC.

von Martin (Gast)


Lesenswert?

Hallo,

ich werde mal versuchen mir eine aktuellere Firmware zu assemblieren.

>Zwar nicht uralt, aber auch nicht die neueste Version. Du könntest auf v3.5 
updaten.
Woher nehmen und nicht stehlen? Ich habe bislang nur ein 3.2 für die 
standalone Version unter
https://www.mikrocontroller.net/svnbrowser/avr-cp-m/avrcpm/trunk/avr
gefunden. Ich habe die V3.1 Stick-Platine mit TTL-Serial ind 8-bit DRAM, 
d.h. kein Propeller, VT100 etc. Wollte nur noch (wenn der Chinese 
liefert) auf I2C-Seriell aufrüsten.

Danke für die Erläuterung des "ipl" - ich dachte das es Optionen 
(I2C,...) kennzeichnet und konnte es in den Quellen nicht finden.

Die disk-image Dateien habe ich von 
https://www.mikrocontroller.net/articles/AVR_CP/M dort unter "Downloads" 
die datei CPMDSK_C.IMG geladen. Dort war unter "USER 7" der FORTRAN 
Compiler mit L80 und dem "Beispiel" zu finden.

Den MS-F80 v3.44 Compiler hatte ich auch schon früher mal für andere 
CP/M Rechner gefunden, vermutlich geistern die selben Dateien an vielen 
Stellen herum. Z.B. auf http://www.retroarchive.org/
Da es auch eine TRS-80 Version des Compilers (zumindest der Handbücher) 
gab, habe ich noch nach TRS-80 Infos gesucht.

Dazu habe ich noch dies gefunden:
1
The Model 4 uses the same character set as the Model 3 as long as the reverse video is turned off. If you wish to use reverse video, first send CHR$ code 16 to the display, then switch in the video memory. You can only access inverse video and POKE the data if you SET bit 7 of the data going to the display. Example: Send ASCII code to display with this assembler program: 
2
3
    LD A,41H 
4
    LD HL,F800H 
5
    LD (HL),A 
6
 
7
The above puts the normal video “A” on the screen. If you want reverse video, use this: 
8
9
    LD A,41H ; A 
10
    SET 7,A 
11
    LD HL,F800H 
12
    LD (HL),A 
13
 
14
You can also calculate the reverse video strings by adding 128 to each value to send to the screen. 
15
***** N O T E ***** 
16
If you enable the reverse video, you *CANNOT* use the graphics characters. To disable the reverse video and enable the graphics, send a CHR$ code 17 to the screen.

Meine Spekulation ist, dass diese TRS-80 Spezialität verwendet wird um 
Fehlermeldungen (nur diese) hervorzuheben. Um das zu prüfen, müsste man 
aber den F80 disassemblieren, soweit wollte ich nun nicht gleich gehen.

Wenn aber diese Zeichen bei Dir (im Fehlerfall) nicht auftauchen, muss 
es wohl etwas anderes in meiner Konfiguration sein.  Merkwürdig wäre 
dann aber das alle (?) anderen Programme (Turbo Pascal, Multiplan, 
Wordstar, ED) mit ihren durchaus komplexen Ausgaben einwandfrei zu 
funktioniern scheinen.

Martin

von Martin (Gast)


Lesenswert?

O.K. ich habe nun doch noch die aktuellen (hoffe ich) Quellen gefunden 
und habe nun die Version 3.5 laufen.

Auch damit kommen bei Fehlermeldungen (nur dort) ebenfalls jeweils die 
letzten Zeichen mit gesetztem Bit 7.

Daraufhin habe ich mir die Fehlermeldungen im F80.COM angesehen. Sie 
haben immer auf dem letzten Buchstaben bit 7 als Ende-Kenner gesetzt.
Damit spart man ein (Null-)Byte pro String, setzt aber voraus, dass die 
Ausgabeeinheit immer nur 7 bit ausgibt.
Im BIOS gibt es dazu die 5 Funktionen CONIN, CONOUT, LIST, READER und 
PUNCH.
Im "CP/M 2.2 Alteration Guide" steht (S. 17/18, 1979-er Digital Research 
Ausgabe), das für diese das high order (parity) bit == 0 sein soll,
auch bei der Eingabe. Das bedeutet dann aber auch, dass man generall in 
CP/M keine 8-bit Binärdaten einlesen oder ausgeben kann.

Es ist mir nicht 100% klar ob diese Funktionen 7 bit erwarten oder ggf. 
das 7.bit selbst löschen.

Nur die Funktionen CONIN und READER löschen bit 7 explizit im Beispiel 
BIOS (S. 53)

In dem CP/M Assemblercode des HP Systems, das ich vor einiger Zeit mal 
disasembliert hatte, findet ebenfalls eine explizite Maskierung auf die 
unteren 7-bits beim TTY input statt.

Die CP/M Version von AVR-CPM macht anscheinend diese Filterung nicht, 
sondern gibt die volle 8-bit Breitseite auf die Konsole.
Der Emulator "Z80Emu" gibt auch nur die 7-bit Texte aus.

So wie es jetzt ist, kann man dann aber auch höhere > 128 Zeichencodes 
ausgeben, was ja auch ganz nett ist.
Ich bin nicht sicher ob CP/M grundsätzlich als 7-bit System für jede 
Console - I/O zu verstehen ist.

Meine Spekulation zu TRS-80/Steuerzeichen war nicht richtig.

F80.COM:
1
...
2
 I  l  l  e  g  a  l     S  t  a  t  e  m  e  n  t     N  u  m  b  e  .
3
49 6C 6C 65 67 61 6C 20 53 74 61 74 65 6D 65 6E 74 20 4E 75 6D 62 65 F2
4
0xF2 & 0x7F => 0x72 = 'r'
5
6
0000477A 496C 6C65 6761 6C20 5374 6174 656D 656E Illegal Statemen
7
0000478A 7420 4E75 6D62 65F2 5374 6174 656D 656E t Numbe.Statemen
8
0000479A 7420 556E 7265 636F 676E 697A 6162 6C65 t Unrecognizable
9
000047AA 206F 7220 4D69 7373 7065 6C6C 65E4 496C  or Misspelle.Il
10
000047BA 6C65 6761 6C20 5374 6174 656D 656E 7420 legal Statement 
11
000047CA 436F 6D70 6C65 7469 6FEE 496C 6C65 6761 Completio.Illega
12
000047DA 6C20 444F 204E 6573 7469 6EE7 496C 6C65 l DO Nestin.Ille
13
000047EA 6761 6C20 4461 7461 2043 6F6E 7374 616E gal Data Constan
14
000047FA F44D 6973 7369 6E67 204E 616D E549 6C6C .Missing Nam.Ill
15
0000480A 6567 616C 2050 726F 6365 6475 7265 204E egal Procedure N
16
0000481A 616D E549 6E76 616C 6964 2044 4154 4120 am.Invalid DATA 
17
0000482A 436F 6E73 7461 6E74 206F 7220 5265 7065 Constant or Repe
18
0000483A 6174 2046 6163 746F F249 6E63 6F72 7265 at Facto.Incorre
19
0000484A 6374 204E 756D 6265 7220 6F66 2044 4154 ct Number of DAT
20
0000485A 4120 436F 6E73 7461 6E74 F349 6E63 6F72 A Constant.Incor
21
0000486A 7265 6374 2049 6E74 6567 6572 2043 6F6E rect Integer Con
22
0000487A 7374 616E F4                            stan.
23
...

Martin

von Martin (Gast)


Lesenswert?

Nach Ergänzung um einen MAX 2323 um ein Terminal anzuschließen, habe ich 
mir nun noch ein SC16IS740 I2C-UART breakout-board besorgt.

Dazu würde mich interessieren, ob schon jemand das CP/M BIOS dafür 
angepasst hat. Ich sehe die I2C Port Routinen auf der AVR Seite, aber 
kein Gegenstück auf der CP/M Systemseite. Dort sind nur die originalen 
leeren Funktionen mit "ret" für PUNCH bzw. "ret ^Z" für READER 
implementiert.

Ich überlege, READER und PUNCH über den I2C-Serial-Wandler zu schicken. 
Im BIOS würde dann das IOBYTE ausgewertet und ggf. input und output über 
den I2C Bus geleitet.

Damit könnte man viele Programme direkt über CP/M auf diese zusätzliche 
Schnittstelle lenken. Zum Beispiel als Drucker oder eben für Kermit etc.

Martin

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Martin schrieb:
> Dazu würde mich interessieren, ob schon jemand das CP/M BIOS dafür
> angepasst hat.

Ist schon implementiertb und getestet. Schau mal hier:

Beitrag "Re: CP/M auf ATmega88"

Beitrag "Re: CP/M auf ATmega88"

seriell mit Kermit
Beitrag "Re: CP/M auf ATmega88"

von Martin (Gast)


Lesenswert?

Danke für die schnelle Antwort - gelesen hab ich's schon, die BIOS 
Quellen hier auf diesem Server 
(https://www.mikrocontroller.net/svnbrowser/avr-cp-m/avrcpm/trunk/cpm/) 
scheinen aber aber noch die alten zu sein (BIOS.MAC und BIOS.ASM jeweils 
mit den leeren returns)?

Oder habe ich da mal wieder was übersehen?

Ich möchte die I2C/UART nicht in jedem Programm direkt ansteuern, 
sondern die dafür vorgesehenen Systemgeräte (RDR:, PUN:) nutzen.

Dann könnte ich z.B.
1
pip PUN:=readme.txt
eingeben um einen Datei zu drucken.

Martin

von Leo C. (rapid)


Lesenswert?

Joe G. schrieb:
> Martin schrieb:
>> Dazu würde mich interessieren, ob schon jemand das CP/M BIOS dafür
>> angepasst hat.
>
> Ist schon implementiertb und getestet. Schau mal hier:

Im BIOS ist der UART leider noch nicht integriert.

von Martin (Gast)


Lesenswert?

Weil ich kein Z80 Assembler-Profi bin, habe ich mal in pseudo-code 
aufgeschrieben, was im BIOS geändert/zugefügt werden müsste. Im Prinzip 
dürfte es reichen, die "reader" und "punch" Routinen mit Leben zuu 
füllen.

Mit den vorhandenen virtuellen Ports für I2C müsste das Ganze eigentlich 
recht einfach gehen, wenn man erst mal ohne Fehlerabfragen, Timeouts 
etc. arbeitet.
Da kein größerer Puffer verwendet wird, sondern byte-weise 
ein-/ausgegeben wird, ist natürlich die Frage für welche Baud-Raten das 
noch geht. Aber 2400 oder 4800 Baud wären auch schon o.k. z.B. für einen 
Drucker.
Könnte das funktionieren?

Martin


in BIOS.ASM und/oder BIOS.MAC (welches wird denn eigentlich verwendet?)
1
// --- VORHANDENER CODE FUER I/O ---
2
conin:
3
  in a,(0)
4
  cp 0ffh
5
  jp nz,conin
6
7
  in a,(1)
8
  ret
9
10
conout:
11
  ld a,c
12
  out (2),a
13
  ret
14
15
list:
16
  ret
17
18
listst:
19
  ld a,0
20
  ret
21
22
// --- NEU ---
23
  // ---------------------------------------------------------------
24
  // we need a static buffer for one byte
25
  db BUFFER [1]
26
  // ---------------------------------------------------------------
27
  
28
  // some constants
29
  I2CCMD    = 5;        // addr of I2C Command Port (1=read, 2=write)
30
  I2CMSGLEN = 1;        // Transferpuffergroesse
31
  I2CADRL   = 7;        // Transferpufferadresse low/high
32
  I2CADRH   = 8;
33
  
34
  I2C_CMD_Read  = 1;    // I2C Read Command
35
  I2C_CMD_Write = 2;    // I2C Write Command
36
  // ---------------------------------------------------------------
37
38
  // ---------------------------------------------------------------
39
punch:
40
  // send one byte in register C to UART via I2C
41
  Port[I2CADRH] := Hi(Addr(BUFFER));   // only needed once: move to init_uart_i2c
42
  Port[I2CADRL] := Lo(Addr(BUFFER));   // ...same...
43
  ... copy content of register C to BUFFER
44
  Port[I2CMSGLEN] := 1;                // send one byte
45
  Port[I2CCMD] := I2C_CMD_Write;       // go!
46
  ret
47
48
  // ---------------------------------------------------------------
49
reader:
50
  ; ld a,01Fh
51
  // read one byte into register A to UART via I2C
52
  Port[I2CADRH] := Hi(Addr(BUFFER));   // only needed once e,g, at cold/warmstart
53
  Port[I2CADRL] := Lo(Addr(BUFFER));   // only needed once e,g, at cold/warmstart
54
  ... copy content of register C to BUFFER
55
  Port[I2CMSGLEN] := 1;                // send one byte
56
  Port[I2CCMD] := I2C_CMD_Read;        // go!
57
  ret
58
59
  // ---------------------------------------------------------------
60
init_uart_i2c:
61
   // routine called during coldstart (and/or warmstart?)
62
  // set addr of buffer
63
  Port[I2CADRH] := Hi(Addr(BUFFER));   // only needed once e,g, at cold/warmstart
64
  Port[I2CADRL] := Lo(Addr(BUFFER));   // only needed once e,g, at cold/warmstart
65
  // set baud rate (e.g. 2400...4800...9600 baud)
66
  // ... store baud rate "somewhere" so that a CP/M program can
67
  // change this later
68
  // more initialization needed?

von Leo C. (rapid)


Lesenswert?

Es geht einfacher. Um I2C brauchst Du Dich garnicht zu kümmern. In 
diesem Artikel, auf den Joe schon verwiesen hatte, ist unten ein 
Beispiel:

Beitrag "Re: CP/M auf ATmega88"

Was dann noch fehlt, ist die Input Status-Routine und die I/O-Byte 
Geschichte.

von Martin (Gast)


Lesenswert?

ah Danke, den Kermit hatte ich zwar ge-sehen, die Assembler Routinen 
aber über-sehen. Das sieht ja deutlich einfacher und schneller aus als 
einen 1-byte buffer zu schicken.

Muss mal ausprobieren, ob ich ein neues BIOS bauen und dann auch auf die 
SD Karte schreiben kann.

Das IOBYTE kann ich ja mit dem STAT Befehl schon ändern und mit STAT 
DEV: die aktuelle Zuordnung ansehen - da muss ich nochmal im "Alteration 
Guide" nachlesen, ob und wo was maskiert und getestet werden muss.
Es gibt da ja auch noch "User Defined" reader und printer devices die 
man anschliessen kann. Aber ich denke RDR: und PUN: oder LST: und PUN: 
wären schon ausreichend (solange man keinen zweiten I2C UART anhängen 
möchte...).

Erst mal Danke für die Tips und Hinweise!

von Leo C. (rapid)


Lesenswert?

Im Alteration Guide wirst Du dazu wahrscheinlich nicht viel finden. Du 
könntest mal nach dem Zapple Monitor suchen, z.B. hier:

https://www.autometer.de/unix4fun/z80pack/ftp/altair/

von Martin (Gast)


Angehängte Dateien:

Lesenswert?

Um mich erst mal mit dem I2C UART anzufreunden und meine Verschaltung zu 
überprüfen, habe ich zwei kleine Turbo-Pascal 3 Programme geschrieben, 
die vielleicht auch für andere nützlich sein könnten:

MODE - erlaubt es UART Parameter (Baud-Rate, Bit-Anzahl, Parity, 
Stop-Bit-Anzahl) einzustellen, ähnlich wie das MODE Programm unter DOS. 
Ein Aufruf ohne Argumente zeigt die aktuellen Einstellungen an.

PRINT - erlaubt es eine Textdatei über den UART zu "drucken". z.B an 
einen realen Drucker oder via Null-Modem an ein weiteres Terminal/PC zu 
schicken. Vorher muss man einmal mit MODE die UART Parameter einstellen, 
sie bleiben dann erhalten.

Martin

von Leo C. (rapid)


Lesenswert?

Hallo Martin,
ich freue mich, daß sich jemand mit den Sachen beschäftigt und finde 
ziemlich gut, was Du da machst. Hast Du schon Erfahrungen mit der 
Performance? Und wolltest Du das nicht in FORTRAN programmieren? ;-)

von Martin Hepperle (Gast)


Lesenswert?

Bezüglich Performance habe ich nicht allzu viel probiert, da ich 
meistens so mit 9600...19200 Baud arbeite und das geht sehr gut.

Ich "drucke" z.B. die Turbo Pascal Programme auf einen Laptop (mit 
Nullmodem Kabel und Windows Teraterm) bei 19200 Baud und das geht 
fehlerfrei. Einstellen lassen sich noch wesentlich höhere Datenraten.
Ich habe spaßeshalber auch einen modernen Thermodrucker 
(POS/Kassendrucker) mit 19200 Baud angeschlossen und der druckt so 
schnell dass es keine Verluste gibt.

Auf Handshaking habe ich deshalb bislang verzichtet, da der Laptop die 
Daten schnell genug aufnimmt.
Ich vermute aber, dass man z.B. mit einem alten Nadeldrucker die 
Baudrate auf 2400...4800 heruntersetzen oder besser Handshaking 
einschalten muss.

Ich schwanke noch, ob ich die GPIO Leitungen lieber als allgemeine I/O 
oder als Modem Leitungen fürs Handshaking verwenden soll.
Bei Verwendung als I/O könnte man Schalter oder digitale Joysticks 
abfragen z.B. für Steuerungszwecke und Spiele. Ansonsten könnte man am 
I2C Bus ja noch weitere I/O Bausteine anhängen, wenn gewünscht.

Das MODE Programm habe ich inzwischen so ergänzt, dass es auch der 
Status der GPIO Pins (im Augenblick alle als input definiert) anzeigt.

Werde mal sehen, ob/wie ich das hier in das SVN ablegen kann.
Dann kommt die FORTRAN Version - oder doch lieber in ALGOL?.

Martin

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Als Hommage an Gary Kindall und sein CP/M muß man PL/M verwenden ;-)

P.S. Tolle Erweiterung von Dir!

von Marcel (Gast)


Lesenswert?

Finde ich auch!

Bitte dokumentier das mal irgendwo, so dass es die Nachwelt auch 
versteht :-)

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Marcel schrieb:
> Bitte dokumentier das mal irgendwo, so dass...
Guter Vorschlag!

@Martin
Einfach unformatiert in eine Textdatei tippen, ich übernehme es dann für 
die Doku.

von Leo C. (rapid)


Lesenswert?

Martin Hepperle schrieb:
> ob ich die GPIO Leitungen lieber als allgemeine I/O

Besser nicht. Tu Dir das nicht an.

> Ansonsten könnte man am
> I2C Bus ja noch weitere I/O Bausteine anhängen, wenn gewünscht.

Eben. Lieber die 20¢ für einen PCF8574 investieren. Dafür gibts bereits 
einen Treibern im Emulator. Es können 8 Stück davon (+ bei Bedarf 
nochmal 8 PCF8574A) über einfache I/O-Befehle angesprochen werden.

von Martin Hepperle (Gast)


Lesenswert?

...so, habe die letzten Abende mit I2C verbracht zunächst etwas 
frustrierend, aber gestern abend hat's geklappt ;-)
Ich hatte ein kleines Platinchen mit dem MCP23017 zur Hand (keinen 
PCF8574) und den wollte ich gerne anschließen.
Es hat aber 2 Abende gedauert, bis ich die vorhandenen I2C/Port 
Anbindung verstanden habe - der AVR Assembler ist mir halt noch recht 
fremd.
Zusätzlich war mir der Zusammenbau der Registerauswahl für den SC16IS740 
unverständlich (mit swap, rshift), bis ich dann nochmal ins Datenblatt 
geschaut habe und dort die merkwürdige Platzierung der Registeradresse 
gefunden habe. Darüber hinaus hat mich auch die Mischung von 7-bit und 
sogenannten 8-bit I2C Adressen verwirrt...

Jedenfalls habe ich jetzt den MCP23017 am laufen und kann damit sehr 
flexibel bis 16 bit I/O ansteuern. Zum Beispiel für einen Centronics 
Schnittstelle.
Für seine Register habe ich 22 Portadressen ab 0x90 verwendet.
Alles mit entsprechenden #defines etc. sodass man den Teil auf Wunsch 
aktivieren kann.

Es ist noch die Frage, was standardmäßig aktiviert sein soll - im 
Augenblick wird ja z.B. der SC16IS740 UART automatisch mit aktiviert, 
wenn I2C Support aktiv ist. Besser wäre vielleicht neben generell I2C 
Unterstützung eine Liste aller I2C Devices, sodass man über die 
config.inc explizit definieren kann, welche man wirklich haben möchte. 
Wenn immer alle eingebunden wären, geht irgendwann der Z80 
Port-Adressraum aus.

Ich werde die MCP23017 Integration über's Wochenende nochmal etwas 
weiter dokumentieren und könnte dann die modifizierten Quellen wieder 
zur Integration zurückgeben. Es sind nur config.inc, i2c.asm und 
virt_ports.asm betroffen und ein kleines Turbo-Pascal Testprogramm gibt 
es noch dazu.

Martin

von Marcel (Gast)


Lesenswert?

Wow...

von Martin (Gast)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

in dem beigefügten Archiv sind meine ASM Quellen mit MCP23017 
Unterstützung.
Im "I2C-liesmich.txt" sind meine Erläuterungen dazu.

Ich kann auch ein .IMG beisteuern, auf dem dann die Pascal Dateien 
enthalten sind.

Im Prinzip könnten die 3 modifizierten AVR Dateien direkt in das SVN 
übernommen werden - meine Kommentarzeilen mit "-MH-" können entfernt 
werden - ich erhebe kein Copyright auf irgendwas.

Zum Z80 BIOS habe ich etwas weitergelesen und sehe, dass wohl alles zum 
Neubau auf dem von Leo C. verteilten disk image vorhanden ist.
Ich muss nur noch verstehen, welche Adressen/Größen ich anpassen muss, 
weil das BIOS natürlich etwas größer wird wenn dort die serielle (RDR, 
PUN) und die parallel Schnittstelle (LST) über I2C hinzukommen.

Martin

von Leo C. (rapid)


Lesenswert?

Hallo Martin,

Super.

Martin schrieb:
> Im Prinzip könnten die 3 modifizierten AVR Dateien direkt in das SVN
> übernommen werden -

Das Beste wäre, wenn Du die Erweiterungen und Verbesserungen selbst 
einchecken würdest. Du brauchst dazu nur einen mikrocontroller.net 
Account, den Du vielleicht ja schon hast.

> meine Kommentarzeilen mit "-MH-" können entfernt werden -

Diese Art von Markierungen sieht man häufig in alten Programmen. Aber 
dafür hat man heute ja Versionsverwaltungen wie SVN.

> ich erhebe kein Copyright auf irgendwas.

Du könntest jeweils im Kopf eine Zeile mit Jahr und Autor einfügen.

> Ich kann auch ein .IMG beisteuern, auf dem dann die Pascal Dateien
> enthalten sind.

Gerne.
Du kannst sie aber auch im SVN im Zweig cpm/utils unterbringen.

von Martin H. (therealmartin)


Lesenswert?

Leo,

ich wollte nicht so gerne in anderer Leute Code herumwursteln...kann das 
aber gerne machen.

Dazu habe mir gerade einen microcontroller.net Account angelegt und auch 
das extra SVN Passwort gefunden.

Mit Tortoise SVN ist es mir aber nicht gelungen, Verbindung mit dem 
Repository aufzunehmen:
1
Command: Checkout from svn://mikrocontroller.net/avr-cp-m, revision HEAD, Fully recursive, Externals included  
2
Error: Unable to connect to a repository at URL 'svn://mikrocontroller.net/avr-cp-m'  
3
Error: Can't connect to host 'mikrocontroller.net': Es konnte keine Verbindung  
4
Error:  hergestellt werden, da der Zielcomputer die Verbindung verweigerte.  
5
Completed!:


Brauche ich noch eine Freigabe meines Benutzernamens für das AVR-CPM 
Repository?
Ich dachte, dass ich auch ohne Schreibzugriff browsen oder auschecken 
könnte... Aber vielleicht brauche ich eine Freigabe per SVN auch zum 
Lesen.


Martin

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Martin H. schrieb:
> Brauche ich noch eine Freigabe meines Benutzernamens für das AVR-CPM
> Repository?

Ja, habe ich gerade eingerichtet und sollte nun gehen.

von Martin H. (therealmartin)


Lesenswert?

Joe,

Danke, aber irgendwie bin ich zu doof.

Mit dem Windows Tortoise SVN, mit dem ich sonst gelegentlich im internen 
Firmen-Netzwerk arbeite, klappte es nicht. Nach außen ist da eine 
Firewall, die vielleicht svn verbietet?

Also versuche ich mal als Alternative die Kommandozeile:
Ich versuche eine lokale Kopie auf meinem Rechner anzulegen:
1
svn checkout svn://mikrocontroller.net/avr-cp-m
2
svn: E170013: Unable to connect to a repository at URL 'svn://mikrocontroller.net/avr-cp-m'
3
svn: E730061: Can't connect to host 'mikrocontroller.net': Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte.
oder auch mit Authentifizierungsdaten
1
svn checkout svn://mikrocontroller.net/avr-cp-m --username TheRealMartin --password ...
2
svn: E170013: Unable to connect to a repository at URL 'svn://mikrocontroller.net/avr-cp-m'
3
svn: E730061: Can't connect to host 'mikrocontroller.net': Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte.
Das gleiche bekomme ich auch mit anderen Befehlen wie "info" etc.

Hast Du noch eine Idee?

Martin

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Die Quellen liegen hier: svn://mikrocontroller.net/avr-cp-m/avrcpm/trunk

Bei mir geht es, ich habe es gerade versucht. Versuche mal bitte über 
diesen Link an das Archiv zu kommen:

https://www.mikrocontroller.net/svnbrowser/avr-cp-m/

von Martin H. (therealmartin)


Lesenswert?

Per WEB browser komme ich schon dahin und hatte mir das ganze ja auch 
als TAR heruntergeladen um lokal zu arbeiten.
Das WEB Interface hat aber keine commit Funktion es ist nur ein viewer.

Mit "svn checkout" oder Turtoise-SVN klappt es nicht.

Ich habe nochmals etwas herumgeforscht, und tatsächlich verbietet unsere 
Firmen-Firewall den port 3690 der für svn verwendet wird.

Wenn der mikrocontroller.net Server das WebDAV Protokoll unterstützen 
würde, könnte ich darauf zugreifen, aber man kann nicht alles haben.

Martin

: Bearbeitet durch User
von Martin H. (therealmartin)


Lesenswert?

O.K. das mit dem SVN bekommen wir noch hin.

Nachdem ich den AVR-Teil soweit im Griff habe, möchte das CP/M System 
mit Hilfe von AVRCPM.SUB nochmal zu bauen (und später erweitern).

Dazu habe ich versucht, das CP/M mit Hilfe der auf dem Disk-Image C: 
vorhandenen Dateien und dem SUBMIT Skript AVRCPM.SUB neu zu bauen.

Das habe ich schließlich nach etwas Kampf mit SUBMIT und A: versus C: 
hinbekommen und erhalte nun auch ein kombiniertes CPM.BIN.
(Kampf: wenn ich z.B. SUBMIT von Laufwerk C: ausführe bekomme ich eine 
Fehlermeldung über ein fehlendes Laufwerk G: und ähnliche Effekte)

Am Ende von AVRCPM.SUB steht noch ein Aufruf eines ominösen Programms 
"W". Das fehlt aber in der Distribution.

Ich vermute, dass es die CPM.BIN Datei roh auf den Datenträger schreiben 
soll. Bevor ich nun lange herumsuche meine Frage:
Wie bekomme ich das CPM.BIN am einfachsten auf die Diskette A:?
(Also auf dem AVR-CP/M System, nicht über so modernen externen 
Schnickschnack wie Windows oder Linux)

Danke,
Martin

: Bearbeitet durch User
von Leo C. (rapid)


Lesenswert?

Martin H. schrieb:
> Am Ende von AVRCPM.SUB steht noch ein Aufruf eines ominösen Programms
> "W". Das fehlt aber in der Distribution.

W.COM gehört zum simh und dient dort dazu, Dateien aus dem CP/M System 
in das Host-Dateisystem zu schreiben. Auf einem richtigen CP/M-System 
ist es also überflüssig.

> Ich vermute, dass es die CPM.BIN Datei roh auf den Datenträger schreiben
> soll. Bevor ich nun lange herumsuche meine Frage:
> Wie bekomme ich das CPM.BIN am einfachsten auf die Diskette A:?

Dafür waren MOVCPM und SYSGEN gedacht. Siehe "CP/M 2.2 Alterarion 
Guide".
Jens hatte das ganze schon mal durchgezogen. Diskussion ungefähr ab [1] 
und ab [2] gibts von ihm ein Programm, um CP/M aus die Systemspuren zu 
kopieren.


[1] Beitrag "Re: CP/M auf ATmega88"
[2] Beitrag "Re: CP/M auf ATmega88"

von Martin H. (therealmartin)


Lesenswert?

Danke,

werde mal mit avrsyscp von Jens experimentieren.

Martin

von Martin H. (therealmartin)


Angehängte Dateien:

Lesenswert?

... wieder ein Schrittchen weiter ...

Nachdem die Pascal Progrämmchen ja ganz nett aber eben hardware-abhängig 
waren, wollte ich die Schnittstellen ja noch ins CP/M integrieren.
Die IOBYTE Funktionalität bin ich noch nicht angegangen, da ich mit der 
aktuellen Konfiguration schon recht zufrieden bin.

Es sind nun die logischen Geräte LPT:, RDR: und PUN: verfügbar.
Man braucht dazu zwei I2C Sklaven:
I2C Adresse 0x48: SC16IS740 - UART (9600,N,8,1 default)
I2C Adresse 0x20: MCP23017  - 16-bit GPIO (Port A[0:7]: Daten, Port 
B[0:3]: BUSY,ACK/,PAPER,STROBE/)

Die beiden I2C chips habe ich auf breakout boards mit in mein AVR-Stick 
Gehäuse eingebaut und für die serielle Schnittstelle einen zweiten DB9 
Stecker installiert.
Die Parallelschnittstelle ist mit VCC, GND auf einen 20-poligen 
Bandkabelstecker geführt. Sie arbeitet allerdings mit 3,3V 
Ein-Ausgabepegel, sodass je nach Einsatz Pegelwandler für klassische 
Centronics-Drucker nötig wären.

"CON:" ist weiterhin die AVR-UART serielle 
Ausgabe-/Eingabe-Schnittstelle
"RDR:" und "PUN:" sind auf die I2C UART serielle 
Ausgabe-/Eingabe-Schnittstelle gelegt.
"LST:" ist auf die I2C GPIO parallele Ausgabe-Schnittstelle gelegt.

Ich kann nun den AVR-CP/M z.B. mit
1
PIP LST:=CON:
als Schreibmaschine benutzen (Ausgabe mit CTRL-Z beenden).  Oder eine 
Textdatei schnell mal mit
1
PIP PUN:=FILE.TXT
auf einen angeschlossenen Laptop oder seriellen Drucker ausgeben.  Oder 
mit
1
PIP FILE.TXT=RDR:
eine (mit CTRL-Z abgeschlossene) Textdatei einlesen.
Mit Turbo Pascal kann man nach einem Assign() auf 'Lst' (GPIO/parallel) 
oder 'Aux' (I2C seriell) ausgeben.

Falls das jemand ausprobieren möchte:

- auf dem beigefügen Disketten-Image CPMDSK_A.IMG ist das modifizierte 
BIOS. Beim Booten sollte sich CP/M mit Version "2.2x" melden.
- dazu gehört die entsprechende AVR Firmware, die die neuen virtuellen 
Ports für die beiden I2C Geräte enthält.

Wenn das ganze noch etwas verfeinert ist, wird der Code wieder in die 
Quellen zurückfließen.

Gestern Abend habe ich dann auch meine SD Karte vernichtet - zu viele 
Schreib-Lesezyklen?

Martin

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

In einer der vielen AVR CP/M Versionen gab es auch die Variante mit I2C 
und Echtzeituhr (PCF8583) und 8Bit-Schnittstelle (PCF8574). Somit konnte 
u.a. ZSDOS zum Einsatz kommen. Um ein BIOS zu bauen hatte ich damals 
auch eine kleine Konfiguration erstellt (ZSDOSCPM.SUB). Vielleicht nutzt 
du gleich ZSDOS um deine Änderungen bezüglich I2C einzubauen. Für das 
ZSDOS benötigst du (alles im Anhang):
IPL.MAC
CCP.MAC
ZSDOS.MAC(BDOS)
BIOS.MAC
AVRCPM.LIB
CFGACPM.LIB
Um es schnell zu testen, benutze ich immer den AltairZ80 Simulator. Der 
„W“ Befehl schreibt die Datei vom CP/M System zurück auf den PC, kann 
natürlich direkt auf CP/M entfallen.

von Martin H. (therealmartin)


Lesenswert?

Zu spät - ich habe schon das ZSDOS verwendet und auf Deiner AVRCPM.SUB 
Datei aufgebaut. Darin steht dann auch:
1
; create BDOS.COM
2
$1:M80 =$1:ZSDOS/M
3
$1:L80 $1:ZSDOS,$1:ZSDOS/N/E
4
ERA $1:ZSDOS.REL
Ich habe nur die .SUB Datei auf A: kopiert und $1 Parameter eingebaut 
damit die Quellen und Ergebnisse alle auf C: verbleiben können.
A: weil das SUBMIT nur über A: funktioniert (ich wollte nur mit Basis 
CP/M Mittel arbeiten ohne DO, SUPERSUB etc.) .

Die 8-Bit-Schnittstelle (PCF8574) ist weiterhin enthalten, ich habe sie 
nur auf I2C 0x27 gesetzt, weil das die Default Einstellung meiner Module 
war (die gibt es z.B. auch als Interface für die 1602 LCD Anzeigen).
Die Z80 Ports dafür liegen weiterhin ab 0x80.  Als Druckerschnittstelle 
reichen die 8 Bit leider nicht aus, deshalb habe ich den 16-bit GPIO 
verwendet.

Die RTC hatte ich im code nicht gesehen - ich glaube die war nur über 
die low Level I2C ports ansprechbar, z.B. mit dem Pascal Programm im 
SVN. Das ist natürlich auch weiterhin für alle möglichen I2C 
Gerätschaften möglich.

Es ist also nichts verschwunden, nur zur vorhandenen Basis zugefügt 
worden (solange noch virtuelle Ports frei sind, ist das wohl die 
eleganteste Möglichkeit).

von Leo C. (rapid)


Lesenswert?

Martin H. schrieb:
> Die 8-Bit-Schnittstelle (PCF8574) ist weiterhin enthalten, ich habe sie
> nur auf I2C 0x27 gesetzt, weil das die Default Einstellung meiner Module
> war (die gibt es z.B. auch als Interface für die 1602 LCD Anzeigen).

Das wollte ich schon länger mal schreiben. Hier liegt wohl ein 
Missverständnis vor. Mit dem Treiber können insgesamt 8 ICs angesprochen 
werden. 0x20 ist dann die Basisadresse, bzw. die Adresse des ersten 
Chips. Ändert man die Adresse im Treiber auf 0x27, können die Chips auf 
den Adressen 0x20-0x26 nicht mehr erreicht werden.

> Die Z80 Ports dafür liegen weiterhin ab 0x80.

Dein Modul liegt dann auf 0x87.

> Als Druckerschnittstelle
> reichen die 8 Bit leider nicht aus, deshalb habe ich den 16-bit GPIO
> verwendet.

Man könnte auch 2 PCF8574 verwenden, jedenfalls mit dem unveränderten 
Treiber. Aber der MCP23017 hat natürlich weitere Vorteile. ZB. richtige 
Push/Pull-Ausgänge. Und das er zusätzlich unterstützt wird, ist ja kein 
Fehler.

> Die RTC hatte ich im code nicht gesehen - ich glaube die war nur über
> die low Level I2C ports ansprechbar, z.B. mit dem Pascal Programm im
> SVN. Das ist natürlich auch weiterhin für alle möglichen I2C
> Gerätschaften möglich.

Für die RTC gibt es einen Treiber für ZSDOS (LDTIM)[1].
Den könnte man auch ins BIOS verlegen.

[1] Beitrag "Re: CP/M auf ATmega88"

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Martin H. schrieb:
> Wie bekomme ich das CPM.BIN am einfachsten auf die Diskette A:?

z.B. mit POWER.COM

A0=load cpm.bin 4000 Last Address:59FFH    52 sectors
A0=write 0 1 4000 52
G=----:-- T=0000 S=001 PS=000 Rec#    1 At:4000-407F
G=----:-- T=0000 S=002 PS=001 Rec#    2 At:4080-40FF
G=----:-- T=0000 S=003 PS=002 Rec#    3 At:4100-417F

....

G=----:-- T=0001 S=024 PS=023 Rec#   50 At:5880-58FF
G=----:-- T=0001 S=025 PS=024 Rec#   51 At:5900-597F
G=----:-- T=0001 S=026 PS=025 Rec#   52 At:5980-59FF

von Martin H. (therealmartin)


Lesenswert?

Leo C. schrieb:
> Das wollte ich schon länger mal schreiben. Hier liegt wohl ein
> Missverständnis vor. Mit dem Treiber können insgesamt 8 ICs angesprochen
> werden. 0x20 ist dann die Basisadresse, bzw. die Adresse des ersten
> Chips. Ändert man die Adresse im Treiber auf 0x27, können die Chips auf
> den Adressen 0x20-0x26 nicht mehr erreicht werden.

Ah ja - in der Tat ein Mistverständnis meinerseits. Das werde ich noch 
überarbeiten. Ich wollte nur Überlappungen vermeiden. Es ist natürlich 
die Frage, ob beide GPIOs (PCF8574 und MCP23017) unbedingt koexistieren 
müssen oder ob man nicht (wenn überhaupt) nur einen GPIO einsetzt. Der 
MCP23017 ist schön flexibel, frisst aber auch viele virtuelle 
Portadressen. Aber solange noch genug verfügbar sind...

Joe G. schrieb:
> Martin H. schrieb:
>> Wie bekomme ich das CPM.BIN am einfachsten auf die Diskette A:?
>
> z.B. mit POWER.COM
>
> A0=load cpm.bin 4000 Last Address:59FFH    52 sectors
> A0=write 0 1 4000 52
> ...

Sehr gut - werde ich in Zukunft verwenden um mir den SD-Karten-Austausch 
zu ersparen.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

@Martin

Mit welchem Baudratenquartz arbeitest du beim SC16IS740? Ich würde es 
gerne bei mir testen bevor ich den Code im SVN einchecke. Ein MCP23017 
Modul muss ich mir erstmal besorgen.

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

Noch ein Vorschlag.

Da ja einige Hardwareboards mit Propeller, I2C (RTC und PCF8574) im 
Umlauf sind, würde es mit deiner I2C Adresse 0x20 für den MCP23017 zu 
Kollisionen kommen. Sie auf 0x27 zu legen ist auch nicht so günstig 
(siehe Leo C.) da dann nur noch ein IC angesprochen werden kann. Um die 
größtmögliche Kompatibilität zu erhalten, könntest du doch den MCP23017 
auf 0x27 legen (siehe Tabelle). Dann sind zwar noch 7 statt 8 PCF8574 zu 
verwenden, aber das kann verschmerzt werden denke ich.

P.S: In Deiner Kurzdoku „I2C liesmich.txt“ hast du die Zuordnung zu den 
IC’s vertauscht.

Es sind nun diese drei I2C Geräte direkt implementiert:
    - SC16IS740 UART at I2C address 0x20,
    - MCP23017 16-bit GPIO at I2C address 0x48,

Beitrag #5590045 wurde vom Autor gelöscht.
von Martin H. (therealmartin)


Angehängte Dateien:

Lesenswert?

Danke für die Korrektur der I2C Adressen, habe ich in meinen Dokumenten 
und im Schema.pdf geändert.
Dank POWER kann ich das CPM.BIN nun auch erfolgreich direkt vom System 
auf die Karte schreiben.

Anbei nochmals eine aktualisierte Version meiner Dateien.
Die I2C Adresse für die PCF habe ich wieder auf die 0x20 zurückgesetzt, 
die für den MCP erst mal ebenfalls auch 0x20 gelassen. Ich vermute, dass 
nicht so viele Anwender beide Chips gleichzeitig verwenden möchten.

Die Baud-Raten Divisorberechnung habe ich versucht mit einem M80 Equate 
zu berechnen, bin aber an den wahrscheinlich zu großen Zahlen 
Divisor=(MHz/BaudRate/16) gescheitert. Deshalb ist der Divisor im 
Quellcode BIOS.MAC als EQU hart verdrahtet, aber mit Formel kommentiert. 
Steht so auch in MODE.PAS.
Mein SC16IS740 board hat einen 14.7456 MHz Quarz was dann z.B. für 9600 
Baud einen Divisor von 96 ergibt.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Danke!
Ein Teil läuft schon mal...

ipl
64k cp/m vers 2.2x

B>scan
Scanning I2C bus for devices...
*** Device found at slave address 20h = 32d (8-bit: 40h = 64d)
*** Device found at slave address 27h = 39d (8-bit: 4Eh = 78d)
*** Device found at slave address 50h = 80d (8-bit: A0h = 160d)
Done.

Hier mußte ich meinen PCF8574 auf 0x27 legen, um keine Kollision zu 
bekommen. 0x50 ist die RTC. Für die UART fehlt mir noch der 
Baudratenquarz, erst mal in meiner Kiste suchen...

: Bearbeitet durch User
von Martin H. (therealmartin)


Angehängte Dateien:

Lesenswert?

Nach dem Feedback habe ich nun in meinen System die folgende Zuordnung 
realisiert:
- SC16IS740 UART at I2C address 0x48, mapped to Z80 ports 0x50-0x5F 
(A0=VCC, A1=VCC), tested up to 115200 baud
- MCP23017 16-bit GPIO at I2C address 0x27, mapped to Z80 ports 
0x60-0x75 (A0=VCC, A1=VCC, A2=VCC)
- PCF8574 8-bit GPIO(s) at I2C address(es) 0x20(-0x26), mapped to Z80 
ports 0x80-0x86
In der nochmal beigefügten Paket sind diese so eingestellt.

Für mich ist das ein brauchbarer Kompromiss - man könnte dann noch 7 
PCF8574 GPIOs anzuschließen.

Das AVR-UART ist wie im Original auf 115200, der I2C UART als default 
auf 9600 in BIOS.MAC (setup_I2C_UART).

Die beiden Dokumente im Archiv sollten alles Wesentliche grob erläutern.
Den SC16IS740 UART kann man sicher auch mit anderen Quarzen betreiben, 
dann müsste nur der Teiler neu ausgerechnet werden - Formeln aus dem 
Datenblatt sind sicherheitshalber auch im  Quellcode (BIOS.MAC und auch 
in MODE.PAS).

Die Versionsnummer "2.2x" habe ich gewählt, damit ich sehe, ob meine 
Änderungen wirklich ankommen. Es ist natürlich weiterhin ein CP/M 2.2 
(bzw. ZSDOS).

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

@Martin
Ich bin gerade dabei deinen Code zu testen und zu übernehmen. Dabei sind 
mir u.a. im CCP.MAC und ZDOS.MAC Laufwerkszuweisungen wie

maclib  C:MEMCFG.LIB

aufgefallen. Hatte das einen Grund hier das Laufwerk C: anzugeben?

von The RealMartin (Gast)


Lesenswert?

... die kannst Du entfernen.

Ich habe das neue System direkt auf dem AVR-CP/M-Stick erstellt und dort 
liegt nur die AVRCPM.SUB Datei auf A: weil das CP/M SUBMIT nur von 
Laufwerk A: aus funktioniert.
Aus Platzgründen liegen aber meine Quellen auf C: und ich musste für die 
Makrodefinitionen deshalb einen Pfad angeben damit alles funktioniert.

Auch wenn die Verwendung des IOBYTE noch nicht implementiert ist, kannst 
Du auch bei der Initialisierung des CP/M Systems den Default-Wert auf 
148d (10.01.01.00b)setzen (wird augenblicklich auf Null gesetzt, d.h. 
TTY: für alle 4 logischen Einheiten), dann gibt ein
1
STAT DEV:
 schon mal die richtigen Zuordnungen aus.

In BIOS.MAC
Original:
1
  xor  a
2
  ld  (iobyte),a
3
  ld  (cdisk),a
4
  jp  gocpm
Neu:
1
  ld  a,148
2
  ld  (iobyte),a
3
  xor  a
4
  ld  (cdisk),a
5
  jp  gocpm

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

Danke... hab mir schon sowas gedacht.

Ich habe mal alle Quellen um sich ein CP/M zu bauen in ein File gepackt 
(cpm_source.zip). Außerdem gibt es Laufwerksimage auf dem direkt unter 
CP/M das CP/M gebaut werden kann. Der Start erfolgt wie immer mit do 
(Supersub) avrcpm.sub. Der Platz auf einer Diskette reicht gerade aus 
dafür ;-)

Im BIOS hatte ich noch die Speierberechnung korregiert, es ist wieder 
ein 62k CP/M (ist aber nur Kosmetik ;-)

Es wäre schön, wenn es noch jemand ausprobiert, die Erweiterungen von 
Martin bzw. I2C sind wirklich sehr nützlich.

@Martin Die Änderungen bezüglich IOBYTE habe ich übernommen

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hier noch die Quellen

von Martin H. (therealmartin)


Lesenswert?

Danke für die Sichtkontrolle und die Integrationsarbeit.
Ein aktualisiertes HEX file zum flashen ware im Repository auch gut 
aufgehoben.

Mit 62K/64K hatte ich etwas gehadert und mich dann für die historisch 
wohl falsche aber logischere 64K Bezeichnung entschieden. Ist aber 
wirklich egal.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Martin H. schrieb:
> Ein aktualisiertes HEX file zum flashen ware im Repository auch gut
> aufgehoben.

Das ist der nächste Schritt.

Ich stelle gerade so etwas wie eine kleine Nachbauanleitung zusammen. 
Hier werden als „Erststart“ auch die BIN bzw. Hex-Files bzw. die 
Laufwerks-Images bereitgestellt. So kann der interessierte Nachnutzer 
das System zunächst ohne die Hürden der Softwareerstellung in Betrieb 
nehmen. Es hakt derzeit noch etwas bei der Lieferung aller meiner 
benötigten I2C Komponenten. Einige sind beim Zoll hängen geblieben und 
warten nun auf meine Auslöse :-)

von Martin H. (therealmartin)


Lesenswert?

Den Reformationstag habe ich genutzt, um das CON: Gerät zu reformieren.
Dort habe nun die IOBYTE Funktionalität implementiert.

Damit kann man jetzt systemweit zwischen dem AVR-UART und dem I2C-UART 
umschalten. Alle Programme, die das BDOS verwenden, sollten damit 
funktionieren. Ich habe es mit Turbo-Pascal, Multiplan Wordstar und Zork 
getestet.

Wer ein Terminalprogramm wie Teraterm verwendet, muss die Zeilenenden 
auf CR setzen, bei CR/LF überschreibt die Ausgabe sich selbst und man 
sieht z.B. beim DIR nur eine Zeile.
Außerdem muss das lokale Echo ausgeschaltet sein, sonst sieht man alles 
doppelt (bzw. nach ein paar Gläsern eben 4-fach).

Augenblicklich implementierte Zuordnungsmöglichkeiten für CON:
TTY: = AVR-UART
CRT: = I2C-UART
BAT: wie TTY:
UC1: wie TTY:

Weitere Möglichkeiten:
- die beiden weitere Optionen BAT: und UC1: könnte man noch für andere 
Schnittstellen nutzen.
- die RDR:, PUN: und LST: Schnittstellen könnte man leicht auch noch 
IOBYTE-tauglich machen, allerdings habe ich da im Augenblick keinen 
direkten Bedarf.
Vielleicht bekomme ich ja mal einen Lochstreifenleser/stanzer, dann wird 
es vielleicht interessanter ...

Je nach STAT Programm muss man unterschiedliche Zuweisungen angeben:
Das STAT auf meiner Festplatte C: ist ein anderes als das auf meiner 
Diskette A:
Mit
1
STAT VAL:
bekomme ich auf A: TTY:, auf C: OCC: für den AVR-UART.

Anwendungsbeispiele:
... Anzeige der aktuellen Zuordnungen für die vier logischen Geräte 
CON:, RDR:, PUN und LST:
1
A>STAT DEV:
2
CON: is TTY:
3
RDR: is PTR:
4
PUN: is PTP:
5
LST: is LPT:

... Anzeige der erlaubten Zuordnungen:
1
A>stat VAL:
2
3
Temp R/O Disk: d:=R/O
4
Set Indicator: d:filename.typ $R/O $R/W $SYS $D  R
5
Disk Status  : DSK: d:DSK:
6
User Status  : USR:
7
Iobyte Assign:
8
CON: = TTY: CRT: BAT: UC1:
9
RDR: = TTY: PTR: UR1: UR2:
10
PUN: = TTY: PTP: UP1: UP2:
11
LST: = TTY: CRT: LPT: UL1:

... die Konsole auf die zweite serielle Schnittstelle (I2C-UART) 
umlenken:
1
A>STAT CON:=CRT:

... ab hier erfolgen alle Ein- und -ausgaben vom I2C-UART, z.B. einem 
zweiten Terminal.
1
A>STAT DEV:
2
CON: is CRT:
3
RDR: is PTR:
4
PUN: is PTP:
5
LST: is LPT:
... bis man dort ...
1
A>STAT CON:=TTY:
... eingibt.

Wie bisher kann man über "unlogische" (physikalische) Geräte auch Ein- 
und Ausgaben auf der ursprünglichen AVR-UART-Konsole erzeugen:
1
A>PIP TTY:=readme.txt
... sendet den Datei-Inhalt IMMER auf den AVR-UART, unabhängig vom 
IOBYTE.
1
A>PIP CRT:=readme.txt
... sendet den Datei-Inhalt IMMER auf den I2C-UART, unabhängig vom 
IOBYTE.


Die Änderungen im BIOS sind gering und alles passt weiterhin noch in 52 
Sektoren (obwohl ich rechnerisch immer auf 53 komme).

BIOS.MAC:
===============================================
1) zusätzliches equate für I2C Statusabfrage einfügen:
1
IF SC16IS740
2
...        
3
        I2C_UART_RXRDY  equ     01h     ; data available?
4
ENDIF

===============================================
2) CON: I/O Funktionen ersetzen:
1
; ----- I/O handlers -----
2
const:
3
        ld      a,(IOBYTE)      ; get content of IOBYTE
4
        call    JumpSel_01      ; select via bits [0:1]
5
        dw      AVR_UART_status ; 00=TTY:
6
        dw      I2C_UART_status ; 01=CRT:
7
        dw      AVR_UART_status ; 10=BAT:
8
        dw      AVR_UART_status ; 11=UC1:
9
10
conin:
11
        ld      a,(IOBYTE)      ; get content of IOBYTE
12
        call    JumpSel_01      ; select via bits [0:1]
13
        dw      AVR_UART_in     ; 00=TTY:
14
        dw      I2C_UART_in     ; 01=CRT:
15
        dw      AVR_UART_in     ; 10=BAT:
16
        dw      AVR_UART_in     ; 11=UC1:
17
18
conout:
19
        ld      a,(IOBYTE)      ; get content of IOBYTE
20
        call    JumpSel_01      ; select via bits [0:1]
21
        dw      AVR_UART_out    ; 00=TTY:
22
        dw      I2C_UART_out    ; 01=CRT:
23
        dw      AVR_UART_out    ; 10=BAT:
24
        dw      AVR_UART_out    ; 11=UC1:
25
26
list:
27
... keine Änderungen, vielleicht später ...


===============================================
3) Den neuen I/O Verteiler einfügen

...
1
; ----- specific handlers
2
3
; general, IOBYTE indexed jump table selector
4
; call must be followed by 4 address words
5
JumpSel_01:     ; selector in bits [0:1]
6
        RLCA    ; multiply A by 2 for address increment
7
JumpSel_21:     ; offset is in bits [1:2] of A
8
        AND     00000110B       ; mask bits [1:2] of A
9
        EX      (SP),HL ; swap (SP)<->HL, HL = first address after CALL = table base
10
        LD      E,A     ; load Offset into DE
11
        LD      D,0
12
        ADD     HL,DE   ; add offset to table base
13
        LD      A,M     ; least significant byte
14
        INC     HL
15
        LD      H,M     ; most significant byte
16
        LD      L,A     ; HL = address of routine
17
        EX      (SP),HL ; swap (SP)<->HL, TOS now has the routine address
18
        RET     ; return to selected Routine via TOS address
...

===============================================
4) Die fehlende I2C_UART Status Funktion einfügen

...
1
; ----- I2C UART -----
2
3
I2C_UART_status:
4
        in      a,(I2C_UART_LSR)
5
        and     I2C_UART_RXRDY
6
        ret     z       ; no data available
7
        or      0ffh
8
        ret
...

Das war's.

@Joe: Wäre toll, wenn Du das noch in Deine Testversion und dann ins 
Repository einpflegen könntest.

von Martin H. (therealmartin)


Lesenswert?

Joe G. schrieb:
[...]
> Ich stelle gerade so etwas wie eine kleine Nachbauanleitung zusammen.
> Hier werden als „Erststart“ auch die BIN bzw. Hex-Files bzw. die
> Laufwerks-Images bereitgestellt. So kann der interessierte Nachnutzer
> das System zunächst ohne die Hürden der Softwareerstellung in Betrieb
> nehmen.
Ich denke das ist sehr nützlich für den Einstieg.

> Es hakt derzeit noch etwas bei der Lieferung aller meiner
> benötigten I2C Komponenten. Einige sind beim Zoll hängen geblieben und
> warten nun auf meine Auslöse :-)

Ja, ja das sind auch meine besten Freunde dort - ich versuche meine 
Bestellungen immer unter der magischen 22€ Grenze zu halten, das klappt 
meistens. Ansonsten kostet mich der Abholspaß immer 2 Stunden und viel 
Spaß beim Erklären - "Elektronikbauteile - was für eine Zollkategorie 
ist das denn?" oder "was, ein alter Computer - ist das nicht 
Elektronikschrott?".

Leider hatte ich keinen I2C UART mehr, sonst hätte ich mal einen 
geschickt.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Martin H. schrieb:
> Wäre toll, wenn Du das noch in Deine Testversion und dann ins
> Repository einpflegen könntest.

Ich hoffe, ich komme morgen dazu. Auch der Zoll hat nun meine Baugruppen 
durchgewunken ;-)

von Martin H. (therealmartin)


Angehängte Dateien:

Lesenswert?

1) IOBYTE
Um die unendliche Geschichte vom IOBYTE abzuschließen, habe ich diese 
noch für die LIST, PUNCH und READER Funktionen implementiert.
Damit kann man nun alle verfügbaren Geräten 'beliebig' zuordnen. Mit den 
drei Schnittstellen AVR-UART, I2C-UART und I2C-GPIO bin ich in der 
Praxis erst mal ausreichend versorgt.
Der Code des BIOS ist dadurch noch etwas angewachsen, passt aber gerade 
noch in die ursprünglichen 7 Sektoren, sodass die Länge von 52 Sektoren 
(à 128-Byte) für das System weiterhin ausreicht. Es sind nun aber nur 
noch ein paar Bytes Luft am Ende.

Zur Übersicht hier nochmal die Größe der Komponenten, wie sie auf der 
Boot-Diskette abgelegt sind:
1
IPL     1 record  à 128 bytes = 0080h bytes - bootstrap loader
2
CCP    16 records à 128 bytes = 0800h bytes - command processor
3
ZSDOS  28 records à 128 bytes = 0E00h bytes - general CP/M DOS
4
BIOS    7 records à 128 bytes = 0380h bytes - hardware BIOS
5
       52 records à 128 bytes
6
   = 2*26 tracks*sectors


Augenblickliche Zuordnung der drei physikalischen I/O Geräte (AVR-UART, 
I2C-UART, I2C-GPIO):
TTY:  AVR-UART, input+output (Console)
CRT:  I2C-UART, input+output (Console)
LPT:  I2C-GPIO, output only (Printer)
UL1:  I2C-UART, input only (PaperTape Reader)
UP1:  I2C-UART, output only (PaperTape Punch)
BAT:  AVR-UART, input+output (Console)
UC1:  AVR-UART, input+output (Console)

Man könnte also theoretisch noch weitere UARTs für UL1:, UP2:, BAT: und 
UC1: nachrüsten, wenn man das unbedingt braucht.


Das neue Code-Fragment in BIOS.MAC ist:
1
[...]
2
list:
3
  ld  a,(iobyte)  ; get content of IOBYTE bits [7:8] to [0:1]
4
  rlca  ; rotate A left (11000000->10000001)
5
  rlca  ; rotate A left (10000001->00000011)
6
  call  JumpSel_01  ; select via bits [0:1]
7
  dw  AVR_UART_out  ; 00=TTY:
8
  dw  I2C_UART_out  ; 01=CRT:
9
  dw  I2C_GPIO_out  ; 10=LPT:
10
  dw  AVR_UART_out  ; 11=UL1:
11
12
listst:
13
  ld  a,(iobyte)  ; get content of IOBYTE bits [7:8] to [0:1]
14
  rlca  ; rotate A left (11000000->10000001)
15
  rlca  ; rotate A left (10000001->00000011)
16
  call  JumpSel_01  ; select via bits [0:1]
17
  dw  AVR_UART_out_status  ; 00=TTY:
18
  dw  I2C_UART_out_status  ; 01=CRT:
19
  dw  I2C_GPIO_out_status  ; 10=LPT:
20
  dw  AVR_UART_out_status  ; 11=UL1:
21
22
punch:
23
  ld  a,(iobyte)  ; get content of IOBYTE bits [5:4] to [1:2]
24
  rrca  ; rotate A right (00110000->00011000)
25
  rrca  ; rotate A right (00011000->00001100)
26
  rrca  ; rotate A right (00001100->00000110)
27
  call  JumpSel_12  ; select via bits [1:2]
28
  dw  AVR_UART_out  ; 00=TTY:
29
  dw  I2C_UART_out  ; 01=PTP:
30
  dw  I2C_GPIO_out  ; 10=UP1:
31
  dw  AVR_UART_out  ; 11=UP1:
32
33
reader:
34
  ld  a,(iobyte)  ; get content of IOBYTE bits [5:4] to [1:2]
35
  rrca  ; rotate A right (00001100->00000110)
36
  call  JumpSel_12  ; select via bits [1:2]
37
  dw  AVR_UART_in  ; 00=TTY:
38
  dw  I2C_UART_in  ; 01=PTR:
39
  dw  AVR_UART_in  ; 10=UR1:
40
  dw  AVR_UART_in  ; 11=UR1:
41
42
; ----- specific handlers
43
[...]


2) Speicherzuordnung
Was mich immer etwas gestört hat, war die Inkonsistenz bezüglich der 
Speichergröße (62K vs. 64K) sowie die teilweise Duplizierung von EQUates 
in den Libraries GFCACPM.LIB und MEMCFG.LIB. Außerdem hatte ich das 
'Gefühl', dass der teure 64KB Speicher nicht vollständig ausgenutzt 
wird.
Dazu habe nun ich meine Version bereinigt und als relevante Größen muss 
ich nun nur noch einmal die Speichergröße sowie die Längen von CCP, BDOS 
und BIOS angeben.
Daraus werden dann die Ladeaddressen berechnet und einheitlich 
bezeichnet (ccploc, bdosloc, biosloc).
Jede Änderung muss nun nur noch in MEMCFG.LIB angepasst werden. Diese 
muss immer vor CFGACPM.LIB eingebunden werden.

Ich habe auch die teilweise verwendete Rundung auf ganze KBytes 
entfernt.

Dazu musste ich allerdings ein paar alte EQUates z.B. im IPL und ZSDOS 
ändern, da teilweise der gleiche Name für unterschiedliche Dinge 
verwendet wurde.

MEMCFG.LIB:
1
[...]
2
msize  equ  62    ; 64 KB = 62 KB + 2 KB buffer area above BIOS
3
; length of each component rounded up to next 100h
4
ccplen  equ  0800h    ; CCP at DC00h
5
bdoslen  equ  0E00h    ; BDOS at E400h
6
bioslen  equ  0600h    ; BIOS at F200h
7
nhdisks  equ  2    ; total number of hard disks (set to 0 if no hard disks desired)
8
[...]

CFGACPM.LIB:
Berechnung der Ladeadressen:
1
[...]
2
ccploc  equ  msize*1024-bioslen-bdoslen-ccplen  ; base of CCP
3
bdosloc   equ  ccploc+ccplen                      ; base of BDOS (serial number, code starts at bdosloc+6)
4
biosloc   equ  ccploc+ccplen+bdoslen              ; base of BIOS
5
[...]

IPL.MAC:
1
[...]
2
  maclib  MEMCFG.LIB  ; -MH- define msize and component lengths
3
  maclib  CFGACPM.LIB  ; -MH- define load addresses etc.
4
[...]
5
  ld  hl,ccploc  ; -MH-
6
  ld  de,128
7
  ld  c,1    ;sector 1
8
[...]
9
  jp  biosloc  ; -MH-
10
11
prmsg:
12
  ld  a,(hl)
13
[...]

nsects   equ  26*2 - 1  ;cold start sector count

BIOS.MAC:
1
[...]
2
  maclib  MEMCFG.LIB  ; -MH- define msize and component lengths
3
  maclib  CFGACPM.LIB  ; -MH- define load addresses etc.
4
5
bdos  equ  bdosloc+6  ; -MH- direct call to BDOS
6
[...]
7
  org  100h
8
  .phase  biosloc  ; -MH-
9
  .z80
10
11
nsects  equ  ($-ccploc)/128    ; -MH- warm start sector count
12
[...]
13
  ld  c,0    ;track
14
  ld  d,1    ;sektor (0 based, skip ipl)
15
  ld  hl,ccploc  ; -MH-
16
store1:
17
  push  bc
18
[...]
19
  ld  c,0    ;track
20
  ld  d,1    ;sektor (0 based)
21
  ld  hl,ccploc  ; -MH-
22
load1:
23
  push  bc
24
[...]
25
  ld  c,a
26
  jp  ccploc  ; -MH-
27
  
28
msgSel:  db  13,10,"Sel: ",0
29
[...]

ZSDOS.MAC:
1
[...]
2
  org  100h
3
  maclib  MEMCFG.LIB  ; -MH- define msize and component lengths
4
  maclib  CFGACPM.LIB  ; -MH- define load addresses etc.
5
  
6
  .phase  bdosloc  ; -MH-
7
[...]

CCP.MAC:
1
[...]
2
  maclib  MEMCFG.LIB  ; -MH- define msize and component lengths
3
  maclib  CFGACPM.LIB  ; -MH- define load addresses etc.
4
5
  .phase  ccploc  ; -MH-
6
[...]
7
serialize:      ;check serialization
8
  ld  de,serial
9
  ld  hl,bdosloc  ; -MH-
10
  ld  b,6    ;check six bytes
11
[...]
12
badserial:
13
  ld  hl,76f3h  ;'di hlt' instructions. [di or (hlt shl 8)]
14
  ld  (ccploc),hl  ; -MH-
15
  ld  hl,ccploc  ; -MH-
16
[...]
17
  end  ccploc  ; -MH-

Ich hatte einige Problem die wahre Größe des BIOS rechnerisch 
festzustellen, da nach Ende des Codeteils noch nicht-initialisierte 
Disketten- und Festplattenparameter folgen, deren Größe mit Hilfe von 
Makros berechnet wird, die ich nicht komplett durchschaue. Diese 
Bereiche werden z.B. von STAT C: oder von PIP B=C (copy) verwendet.
Von jeder Änderung der Speicherzuordnung sind alle vier Komponenten IPL, 
CCP, BDOS und BIOS betroffen.

Nach einigen rechnerischen Fehlversuchen habe ich mich dann in Schritten 
von 100h an die wahre Größe herangetastet. Dazu habe ich nach jeder 
Änderung den Speicher mit DDT angesehen. Der Speichertest beschreibt ja 
den Speicher mit 'v' sodass man gut sehen kann, wo was verändert wurde.
Letztendlich konnte ich die allokierte Größe des BIOS von 0D00h auf 
0900h verringern. Diese Größe beinhaltet den BIOS code plus den Platz 
für Disketten und Festplattenparameter.
Damit bleiben am Ende des Speichers noch ein paar Bytes frei und man hat 
ca 1 KB mehr Arbeitsspeicher für Programme gewonnen.
Turbo-Pascal meldet dann (überschreibt den CCP) 26640 bytes (von 
7B5-E406) frei.
Viele Programme wie Multiplan, Wordstar, Power etc. funktionieren damit.
Allerdings habe ich dann leider festgestellt, dass speziell der PIP beim 
Kopieren anscheinend doch mehr im hohen Speicherbereich beansprucht und 
einfach mit halbkopierten Dateien abbricht, wenn das BIOS nicht 0D00h 
groß ist.
Eine Technische Dokumentation zum PIP und den benutzen Speicherbereichen 
habe ich leider nicht gefunden.

Daher habe ich die Größe des BIOS wieder auf die ursprünglichen Werte 
zurückgesetzt.
Damit bekomme ich wieder die 'alte' Speicherbelegung.

Meine kompletten Quellen sind im angehängten ZIP Archiv.

: Bearbeitet durch User
von Leo C. (rapid)


Lesenswert?

Martin H. schrieb:
> Ich hatte einige Problem die wahre Größe des BIOS rechnerisch
> festzustellen, da nach Ende des Codeteils noch nicht-initialisierte
> Disketten- und Festplattenparameter folgen, deren Größe mit Hilfe von
> Makros berechnet wird, die ich nicht komplett durchschaue.

Schau Dir dazu das Kapitel "10. DISK PARAMETER TABLE" im CP/M 2.2 
Alteration Guide an. Die relevanten Parameter sind CSV und ALV. Im 
AVR-CP/M Bios werden die dafür nötigen Buffer abhängig von der Anzahl 
und Größe angemeldeter Laufwerke dynamisch am Ende des BIOS angelegt. 
D.h., je mehr Laufwerke angemeldet sind, und je größer diese sind, um so 
mehr Platz wird für die CSVs und ALVs benötigt.

> Diese
> Bereiche werden z.B. von STAT C: oder von PIP B=C (copy) verwendet.

Nein, sie werden vom BDOS genutzt, abhängig von den aufgerufenen 
Funktionen.

Martin H. schrieb:
> Allerdings habe ich dann leider festgestellt, dass speziell der PIP beim
> Kopieren anscheinend doch mehr im hohen Speicherbereich beansprucht und
> einfach mit halbkopierten Dateien abbricht, wenn das BIOS nicht 0D00h
> groß ist.

Eigentlich sollte bereits das Login eines Laufwerks mit einer 
Fehlermeldung scheitern, wenn der Platz für die anzulegenden Buffer 
nicht reicht.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Hallo Martin,

ich bekomme beim neuen System erstmal einen Fehler, muss mal suchen, 
woran das liegt.

CPM on an AVR, v3.5 r242
Testing RAM: fill...wait...reread...
Initing mmc...

A: FAT16 File-Image 'A' at: 8479, size: 256KB.
B: FAT16 File-Image 'B' at: 8959, size: 256KB.
C: FAT16 File-Image 'C' at: 8703, size: 256KB.
D: FAT16 File-Image 'D' at: 9087, size: 8192KB.
E: FAT16 File-Image 'E' at: 8831, size: 250KB.
F: FAT16 File-Image 'F' at: 13183, size: 256KB.
G: FAT16 File-Image 'G' at: 13311, size: 256KB.
Partinit done.

Ok, Z80-CPU is live!

ipl
 Z  N   A =80 BC =0034 DE =0080 HL =F580 SP=2000 PC=0286       76 76 76
        a'=00 bc'=0000 de'=0000 hl'=0000 IX=0000 IY=0000 I=00       CPU 
halted!

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Nachtrag:
Ich kann jetzt alle deine Quellen fehlerfrei übersetzen. Mein M80 möchte 
einige TAB's nicht :-(
Meine I2C Testhardware ist auch kurz vor der Vollendung.

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?

Mein Testaufbau ist noch doch etwas umfangreicher geworden als 
ursprünglich geplant :-)
Neben den I2C Komponenten
- RTC mit PCF8583
- RS232 mit SC16IS750
- 16 Bit I/O mit MCP23017
habe ich noch eine DRAM kompatible SRAM Schaltung aufgebaut. Verbaut ist 
ein 256kx8 SRAM, der sich mit seiner Ansteuerung (2 x Latch + Logik) 
pinkompatibel zu den DRAM’s verhält. Zwei Gatter könnte man noch 
einsparen, müsste aber im größeren Maß in den derzeitigen Quelltext 
eingreifen. Jetzt kann einfach die neue Schaltung statt eines nicht mehr 
verfügbaren DRAM’s eingesetzt werden. Nicht ganz – den Refresh habe ich 
noch abgeschaltet :-) Somit lässt sich das CP/M – System nun komplett 
mit aktuellen Bauelementen aufbauen. Für einen altersgerechten und 
augenfreundlichen Aufbau habe ich versucht weitgehend auf SMD zu 
verzichten.

von David R. (retrogadgets)


Angehängte Dateien:

Lesenswert?

Hello

I have the cpm stick 3.1 now running but upon reading the sd gives some 
garbage as well.  Thanks for your help.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Please turn on the debug option “.equ MMC_DEBUG  = 1” in “confic.inc” , 
and post  us the answer.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

@Martin
Ich habe nun mit meinem Experimentalaufbau alle deine Funktionen 
getestet. Meine I2C Konfiguration sieht dabei wie folgt aus:

A>i2cscan
Scanning I2C bus for devices...
*** Device found at slave address 27h = 39d (8-bit: 4Eh = 78d)
*** Device found at slave address 48h = 72d (8-bit: 90h = 144d)
*** Device found at slave address 50h = 80d (8-bit: A0h = 160d)
Done.

Die Umleitung des Terminals auf die zweite serielle Schnittstelle 
funktioniert.

Terminal 1 (115200 Baud)

A>stat dev:
CON: is OCC:
RDR: is CRT:
PUN: is CRT:
LST: is COM:

A>stat Val:
Temp R/O Disk: d:=R/O
Set Indicator: d:filename.typ $R/O $R/W $SYS $DIR
Disk Status  : DSK: d:DSK:
User Status  : USR:
Iobyte Assign:
CON: = OCC: ECC: BAT: AUX:
RDR: = COM: CRT: AUX: PRI:
PUN: = COM: CRT: AUX: PRO:
LST: = LPT: CRT: COM: AUX:

stat con:=ecc:
Terminal 2 (9600 Baud)

A>stat dev:
CON: is ECC:
RDR: is CRT:
PUN: is CRT:
LST: is COM:

stat con:=ecc:
Terminal 1 (115200 Baud)

Die Baudratenumschaltung und Datenübertragung auf der zweiten seriellen 
Schnittstelle funktioniert bis 460800 Baud fehlerfrei. Der 16 Bit I/O 
Port geht auch. Somit sollten alle deinen neuen Funktionen laufen. 
Super!

@Leo C.
Ohne Refresh (meine Version mit DRAM) ist das System natürlich nun noch 
schneller ;-)
mit Refresh ACT : 3.86s
ohne Refresh ACT : 3.799s

von Martin H. (therealmartin)


Lesenswert?

Klasse! Danke für Deine Mühe - das mit den Tabs ist merkwürdig - ich 
habe auch immer den M80 verwendet.

Ich denke, damit ist das AVR/CPM noch ein bisschen näher an die damalige 
Realität gerückt und auch flexibler nutzbar.

Den Kermit 4.11 von Leo C. der hier im Thread angeboten wurde, habe ich 
auch verwendet - er erkennt den I2C-UART selbst und scheint darauf hart 
verdrahtet zu sein. Man kann auch damit die Baud-Rate einstellen, wie 
mit meinem MODE Programm. Ich bin nicht sicher, ob die Quellen 
inzwischen im AVR-CPM-SVN liegen, damit das Programm längerfristig 
erhalten bleibt.
Andererseits könnte man auch noch mit einem originalen Kermit 4.11 
probieren, ob man mit SET PORT nun einfach auf die zweite serielle 
Schnittstelle (I2C) schalten kann und dann die normalen Ausgaben 
weiterhin auf CRT: erscheinen.
Dann bräuchte man die Spezialversion nicht mehr unbedingt, müsste aber 
dann die Baud-Rate extern einstellen.

Ich verwende meistens das Original STAT Programm von DR - das bringt 
dann andere Namen für die Lochstreifenleser etc., was aber nur 
kosmetischer Natur ist.

Dann muss ich nur noch die Ein- und Ausgänge meines I2C-GPIO mit 
Pegelwandlern auf 5V Niveau für eine Centronics Drucker-Schnittstelle 
heben.

Irgendwo habe ich auch noch ein RTC Platinchen herumliegen - mal sehen 
ob das noch in mein Gehäuse passt...

von Martin H. (therealmartin)


Lesenswert?

@ David R.
Did you use an SD card (not SD-HC)?
The boot messages look like the card is not recognized.
Try with a plain old SD card (2 GB or so).

: Bearbeitet durch User
von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Martin H. schrieb:
> Dann muss ich nur noch die Ein- und Ausgänge meines I2C-GPIO mit
> Pegelwandlern auf 5V Niveau für eine Centronics Drucker-Schnittstelle
> heben.

Der TXS0108E scheint mir daür genau der richtige Kandidat zu sein.

von Martin H. (therealmartin)


Lesenswert?

Ja, das würde passen (plus 3 Steuerleitungen für den Drucker).

Entweder so oder den gesamten Chip auf 5V heben und dann nur die zwei 
I2C Leitungen von 3.3V auf 5V übersetzen. Ist vielleicht eleganter und 
bräuchte nur 2 diskrete Konverter-Transistoren.

Ich habe sowieso einen 5V auf 3,3 Step-Down Regler nach der 
Anschlussbuchse für die Spannungsversorgung.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Martin H. schrieb:
> Ist vielleicht eleganter und
> bräuchte nur 2 diskrete Konverter-Transistoren.

Ja, zwei BSS138 sind auch schnell integriert. Außerdem gibt es den MCP 
23017 auch als DIL-Version, so dass man ihn bequem auf eine Fassung 
stecken kann.(Eine defekte PIO war früher mein Lieblingsbauelement ;-)

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Lesenswert?