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:
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"
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.
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
> 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.
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
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:
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?
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. ;-)
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:
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
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
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
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"
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:
http://www.ebay.de/itm/1Stk-XD-204-Data-logging-shield-fur-Arduino-UNO-SD-Card-/121505102595?pt=Wissenschaftliche_Ger%C3%A4te&hash=item1c4a44bb03
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...)
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
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
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.
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
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
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"
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.
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?
> 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.
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
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
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 :-)
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
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:
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.
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 :-)
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.
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...
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.
> 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.
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)
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. */
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.
> 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/
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.
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... :-)
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.
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.
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.
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.
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
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
:-))
> 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.
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
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 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
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 ?
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.
> -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.
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.
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)"
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.
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.
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:
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/
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
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
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.
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
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...
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
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.
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
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 :-)
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.
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.
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."
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
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.
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:
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
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
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 :)
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.
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 :)
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...
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...
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
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
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..."
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 :)
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.
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?
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
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).
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
> 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.
... 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
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
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.
> 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.
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
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:
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
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.
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.
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?)
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.
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!
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
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? ;-)
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
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.
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.
...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
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
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.
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
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.
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.
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
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/
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
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
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"
... 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
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.
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).
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"
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.
@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.
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,
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.
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...
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).
@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?
... 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:
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
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.
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 :-)
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:
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.
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 ;-)
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:
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.
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.
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.
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.
@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
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...
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.
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.
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 ;-)
Ich finde das IOBYTE als sehr schöne und elegante Sache die sehr gut zum
System passt sobald man mehr als eine serielle Schnittstelle angebaut
hat. Beim späteren MSDOS ist das nur noch ansatzweise vorhanden (MODE
LPT1:=CON2: sowie Umleitung mit '<','>'), durch die dann populär
werdende direkte Hardwareansteuerung völlig verloren gegangen.
Ich habe mir auch noch mal einen generischen Kermit 4.11
zusammengebastelt, d.h. ohne Kenntnis der I2C Schnittstelle. Den kann
man nun z.B. mit SET PORT CRT auf eine "beliebige" serielle
Schnittstelle umstellen, was eigentlich schöner ist als eine
Spezialversion zu haben. Allerdings muss man dann die Baud-Rate vorher
extern einstellen.
Irgendwie bekomme ich keine Dateiübertragung damit hin. Mit PIP
funktioniert es, d.h. die Schnittstellen sind verbunden und die Baudrate
stimmt. Hat Kermit noch ein Geheimnis, das ich nicht kenne? Meine
Einstellungen sind eigentlich auch ganz simpel:
SET PORT CRT
SET FILE-MODE BINARY
SET FLOW ON
SET AUTORECEIVE ON
RECEIVE
Aber es wird nicht mal der Dateiname übertragen. Zwei DOS Kermit
untereinander verstehen sich, nur Kermit-80 nicht.
Martin H. schrieb:> 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.
Mich würde interessieren, ob es einen Performance-Unterschied zwischen
dem speziell angepaßten und dem Generic-Kermit gibt.
> Ich bin nicht sicher, ob die Quellen> inzwischen im AVR-CPM-SVN liegen, damit das Programm längerfristig> erhalten bleibt.
Leider sind die Quellen noch nicht im SVN. Zudem ist mein kleiner Server
seit kurzem down. Da es noch "etwas" dauern kann, bis ich ihn,
wahrscheinlich mit neuer Hardware, wieder hochfahren kann, hänge ich die
Quellen mal hier an.
Inzwischen haben ich meinen MCP23017 GPIO auf 5V umverdrahtet und zwei
Level-Converter in die I2C Leitungen eingefügt.
Dann noch ein Kabel mit D-SUB-25 Buchse in PC-Parallelport-Belegung
gelötet und dort ein normales PC-Centronics Druckerkabel angesteckt.
Als Drucker hatte ich nur einen HP ThinkJet zur Hand.
Ausdrucken mit
1
PIP LST:=file.txt
funktionierte einwandfrei; wenn das Papier ausging, stoppte der Druck
und nach Einlegen eines neuen Blatts ging es weiter.
Ebenso, wenn der Druckerpuffer voll war - dann ging des Ausdruck
häppchenweise nach jeder ausgegebenen Zeile weiter.
D.h. die Statusabfragen (BUSY, PAPER) und (unendlich langen)
Warteschleifen funtionieren wie geplant.
Auch CTRL+P zum Einschalten der Protokollierung geht, solange die
Programme über BDOS und nicht direkt über BIOS-Calls ausgeben (vielfach
leider üblich um Geschwindigkeit zu gewinnen).
Das einzige was mir noch auffiel war, dass nach Abschalten des Druckers
seine LEDs noch mit etwa halber Intensität weiterleuchteten.
Dabei scheint der Drucker über die Centronics-Schnittstelle noch Strom
zu ziehen - vielleicht eine Abart dieses speziellen Druckertyps.
Um das abzustellen, habe ich im BIOS noch zwei Zeilen ("; *** NEU ***")
eingefügt, um die Leitungen D0-D7 nach Ausgabe eines Zeichens definiert
auf 0V zu setzen.
Dann gehen die LEDs aus, wenn der Drucker abgeschaltet wird.
1
; ----- GPIO -----
2
3
I2C_GPIO_out:
4
IF MCP23017
5
ld a,c
6
out (I2C_GPIO_DATA),a ; data to A[0:7]
7
ld a,0
8
out (I2C_GPIO_DATB),a ; drop STROBE/ on B[3]
9
; stays low for 300 us, more than the required 0.5 us
10
ld a,8
11
out (I2C_GPIO_DATB),a ; rise STROBE/
12
GPIO_busy:
13
in a,(I2C_GPIO_DATB)
14
bit 0,a ; test bit 0
15
jp nz,GPIO_busy ; wait while B[0] = 1
16
; *** NEU ***
17
ld a,0
18
out (I2C_GPIO_DATA),a ; drop data lines to avoid backpowering printer when OFF
19
; *** NEU ***
20
ELSE
21
jp AVR_UART_OUT ; only one device
22
ENDIF
23
ret
Zu dem Problem mit dem generischen Kermit muss ich nochmal nachsehen...
Der generische Kermit funktioniert, allerdings hatte ich zunächst auch
Probleme.
Vermutlich war der UART in einem "undefinierten" Zustand infolge
vorheriger Experimente.
Wenn der I2C UART aber mit z.B. MODE initialisiert wird, sollte es
funktionieren.
Gegenüber dem angepassten Kermit ist die Geschwindigkeit auf etwa die
Hälfte reduziert.
Es muss sich ja beim generischen Kermit jedes Byte durch die
BDOS/BIOS/IOBYTE/AVR Schichten durchwühlen, das dauert...
Generic Kermit 4.11 using IOBYTE vs. special version accessing I2C UART:
Thread beobachten
Seitenaufteilung abschalten