Ok, der PCF8574 geht auch bei 3.3V und ist bei Reichelt als DIL und Smd
verfügbar. PCF8574 und PCA9555 gehen auch bei 3.3V und haben 5V
tolerante Eingänge. Der Pegelwandler kann also entfallen.
Bei der Erweiterung dachte ich in Richtung Anwendung Arduino. Ein
embedded System (ich hab das CP/M gerade geadelt) lebt ja von externer
Hardware. Mit 8 oder 16 Bit I/O könnte der potentielle Nutzer schon eine
Menge anschließen. Ideal wäre die Ansteuerung wie ich schon mal
vorgeschlagen habe über die ungenutzten Biosfunktionen Reader.
Ersetzt man den mega328p durch die smd Version, bekommt man noch zwei
zusätzliche Pins in Form von 2 AD-Wandlern spendiert (ADC6 und ADC7).
Mein derzeitiger Entwurf sieht gerade so aus (pdf). Er hat die Maße
100mm x 70mm und passt damit genau in ein Fischer Alu-Gehäuse (AKG 7124
ME). Das System beinhaltet neben der USB ein VT100 Terminal mit VGA und
Tastaturanschluss den zwei ADC + I2C, sowie 8 Bit I/O.
Eine ähnliche Variante hatte ich schon mal vorgestellt. Sie ist hier
nicht sosehr auf Interesse gestoßen. Macht jedoch nichts, die neue baue
ich mir selber auf. Ich glaube im Gegensatz zum embedded Linux
(raspberry pi u.ä.) kann ein potentieller Interessent (Schüler,
Studenten, wie auch immer) damit ein komplettes System komplett selber
aufbauen, sein CP/M (Kernel) selbst konfigurieren und zusammenstellen.
Das System ist wirklich einfach und überschaubar.
Joe
Peter Sieg schrieb:> Joe G. schrieb:>> USB über FT232RL, die Variante über den MCP2200 würde noch einen>> externen Quarz benötigen.>> DRAM ist ein HM51W17805 (16M EDO RAM 2-Mword x 8 Bit)>> Als Arduino Pro Mini würde auch ein DFRobot Pro Mini V1.2 5V 16MHz>> Arduino Compatible gehen (9,9 €) allerdings müßte bei allen Varianten>> (auch China) ein 3.3V Regler eingesetzt werden.>> Platine derzeit 4 Lagen, es geht sehr eng zu! bei einer Abnahmemenge von>> 10 liegt der Preis ca. um 11€.>> Joe>> Hmm.. ich werde (für mich) das Gefühl nicht los, das wir dann mit dem> 'USB Stick' Konzept besser dran sind.. was meinen die anderen..>> Peter
Hallo zusammen,
ich werde, für mich persönlich, mit meinem "USB Stick" weiter arbeiten.
@Joe: Aber meinen ausdrücklichen Respekt, wie Du immer die Layouts hier
zauberst... :-)
Und vielen Dank für den Anstoss zur ZSDOS Portierung! Klasse!
Viele Grüße
Markus
Leo C. schrieb:> Joe G. schrieb:>>> Um die Vorteile des ZSDOS nun auch wirklich nutzen zu können, braucht es>> nun der Uhr.>> Um die Zeit bis zur funktionierenden RTC zu überbrücken, bastel ich> gerade an der Interrupt-Uhr.>>> Die Uhr (DS1307)>> ist über einen Pegelwandler am I2C Bus angeschlossen.>> 2. Stromversorgung und Pegelwandler wegen eines unpassenden> Uhrenbausteins?> Wie wärs mit PCF8583 oder DS1337 + 2 Dioden?>>> Weiterhin ist am>> Bus ein PCF8574 (8 Bit I/O). Somit hätte man neben der Uhr noch die>> Möglichkeit einen vollständigen 8 Bit Port zu benutzen (LCD, Tastatur,>> Led, wie auch immer). Außerdem können ja weitere I2C Geräte>> angeschlossen werden.>> Was könnte man denn noch anschließen wollen?> Drucker vielleicht? Dann bräuchte man 2. PCF8574 oder zB. PCA9555.> 2. Serielle? Gibs I2C-UARTS? 2. Software-UART stelle ich mir schwierig> vor.
Hallo zusammen,
bezüglich des Uhrenbausteins tendiere ich zum PCF8583 wie von Leo
vorgeschlagen, hat auch noch 240 Byte RAM als "Dreingabe" kann man
bestimmt einmal gebrauchen... ;-)
Oder gibt es Etwas das uns veranlassen sollte explizit einen DS1337 zu
nutzen?
Die I2C Bus-Erweiterung per PCF8574 o.ä. finde ich auch super!
In Zusammenhang mit meinem "AVR/CPM-Stick" denke ich gerade an eine
"Sandwich"-Platine als Aufsatz auf den AVR-Sockel des AVR/CPM-Sticks.
Somit hätte ich dann beliebig viel Platz für Erweiterungen...
Just my 2 cents
Viele Grüße
Markus
> bezüglich des Uhrenbausteins tendiere ich zum PCF8583 wie von Leo> vorgeschlagen, hat auch noch 240 Byte RAM als "Dreingabe" kann man> bestimmt einmal gebrauchen... ;-)
Das RAM könnte man zum bisher ungenutzten EEPROM legen. ;-)
> Oder gibt es Etwas das uns veranlassen sollte explizit einen DS1337 zu> nutzen?
Der PCF8583 ist schon etwas älter und wohl auch einige Designschwächen.
Ein besserer Nachfolger ist der PCF8563, der aber schwieriger zu
bekommen ist. Ob der DS1337 irgend einen Vorteil hat, kann ich jetzt
auch nicht sagen.
Leo C. schrieb:> Ein besserer Nachfolger ist der PCF8563, der aber schwieriger zu> bekommen ist
Mir ist es egal, der PDF8563 ist u.a. bei Farnell zu haben, also kein
Problem.
Joe G. schrieb:> Mir ist es egal, der PDF8563 ist u.a. bei Farnell zu haben, also kein> Problem.
Mir ist's auch egal. Die Softwarunterschiede sind gering. Man kann
sicher mit einem Treiber beide ansprechen. Leider sind sie nicht ganz
pinkompatibel. Aber wenn man an Pin 3 (A0/INT) und 7 (INT/CLKOUT) je
einen Pullup vorsieht, müßten beide Chips damit klarkommen. Dann kann
jeder seinen Wunschchip einstecken.
Ich habe vor, bei Reichelt einen PCF8583 zu bestellen. Für mein anderes
Projekt möchte ich einen DS2417 (1-wire) nehmen. Ginge hier auch. ;-)
Hallo Joe,
deine Anweisungen:
# Hallo Hannes,
# SD Card:
# Deine SD Card mit Fat16 formatieren und dann die Imagefiles
# CPMDSK_A.IMG, CPMDSK_B.IMG und CPMDSK_C.IMG aus
# http://www.mikrocontroller.net/articles/AVR_CP/M
# auf die Karte kopieren.
hat geklappt konnte ich mit meinem AVR auch lesen
# AVR Binärfile:
# Aktuelle Version von hier laden
# http://cloudbase.homelinux.net/viewvc/avr-cpm/avrc...
# übersetzen und auf den AVR bringen.
AVR Trunk herunter geladen und versucht zu übersetzen...
(Windows XP AVR Studio 4) Fehler zu wenig Speicher für das Programm im
Speicher des ATMega 168 ... also das ganze für einen 328er... nach
einigen Kämpfen auch geschafft. (aktuell AVR Studio 5)
# Bei Fragen fragen.
Wie gesagt habe ich den AVR CP/M Stick
Welche Einstellungen müssen in den Files gemacht werden? Angabe des RAM
(2 X 4256er! Wie setzt ihr die config bits? Bei mir zuckt nichts....
# Joe
Gruß
Hannes
@Hannes
so sollte es gehen.
Als ASM Options im AVR Studio:
-DF_CPU=20000000 -DBAUD=115200 -Datmega328P -DDRAM_8BIT
Takt und Baudrate natürlich an das eigene System anpassen.
In der config Datei sollte folgedes stehen:
#define K 1024
#define M 1024*K
#define RAMSIZE 256*K*4 /* 1 chip 256Kx4 */
;#define RAMSIZE 4*M*4 * 2 /* 2 chips 4Mx4 */
#define EM_Z80 1 /* Emulate Z80 if true */
#ifndef FAT16_SUPPORT
#define FAT16_SUPPORT 1 /* Include Support for FAT16 Partitions */
#endif /* which may contain CP/M image files. */
#define RAMDISKCNT 1 /* Number of RAM disks */
#define RAMDISKNR 'I'-'A' /* Drive "letter" for first RAM disk */
#define PARTID 0x52 /* Partition table id */
/* http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
*/
#define IPLADDR 0x2000 /* Bootloader load address */
#define DRAM_WAITSTATES 1 /* Number of additional clock cycles for dram
read access */
#define REFR_RATE 64000 /* dram refresh rate in cycles/s. */
/* Most drams need 1/15.6µs. */
#define RXBUFSIZE 128 /* USART recieve buffer size. Must be power of
2 */
#define TXBUFSIZE 128 /* USART transmit buffer size. Must be power
of 2 */
#if EM_Z80
#define CPUSTR "Z80"
#else
#define CPUSTR "8080"
#endif
.equ BOOTWAIT = 1
.equ MEMTEST = 1
.equ MEMFILL = 1
.equ MMC_DEBUG = 0 /* Increase for more debugging */
.equ FAT16_DEBUG = 0
.equ FAT16_RWDEBUG = 0
.equ FAT16_DBG_FAT = 0
.equ DISK_DEBUG = 0 /* Increase for more debugging */
.equ HOSTRW_DEBUG = 0
.equ HEAP_DEBUG = 0
.equ PORT_DEBUG = 0
.equ INS_DEBUG = 0
.equ STACK_DBG = 0
.equ PRINT_PC = 0
#define MMC_SPI2X 1 /* 0 = SPI CLK/4, 1 = SPI CLK/2 */
Nach dem Reset sollte dann im Terminalprogram (Baudrate und COM-Port
natürlich korrekt einstellen) sofort die Bootmeldung kommen. Auch wenn
die SD Card nicht richtig gelesen wird kommt auf jeden Fall eine
Meldung. Wenn nicht, zunächst mal prüfen ob der AVR auch über die
USB-Schnittstelle richtig sendet und ob überhaut was am PC ankommt.
Joe
Joe G. schrieb:> Als ASM Options im AVR Studio:>> -DF_CPU=20000000 -DBAUD=115200 -Datmega328P -DDRAM_8BIT
************
Nimmst Du schon länger 115200? Ohne Probleme? Vielleicht sollte ich das
auch mal umstellen. Ich glaube, über 57600 habe ich nie richtig
getestet.
Hannes schrieb:> # AVR Binärfile:> # Aktuelle Version von hier laden> # http://cloudbase.homelinux.net/viewvc/avr-cpm/avrc...> # übersetzen und auf den AVR bringen.>> AVR Trunk herunter geladen und versucht zu übersetzen...
Bitte nicht irgendwas aus Trunk, sondern:
http://cloudbase.homelinux.net/viewvc/avr-cpm/avrcpm/tags/3.0/
Bitte auf den Link klicken, oder, wenn sich Kopieren nicht vermeiden
läßt, darauf achten, daß der gesamte Link kopiert wird. Hier ist der
vollständige Link:
Leo C. schrieb:> Nimmst Du schon länger 115200? Ohne Probleme?
Ja, schon seit der ersten Version. 57600 machen bei mir Probleme mit dem
TP Editor. Der verschluckt bei schneller :-) Programmierung oder beim
Editieren sonst schon mal ein Zeichen. 115200 hat noch nie Probleme
bereitet.
Im trunk gibts jetzt eine Uhr.
Im Anhang ist der passende ZSDOS-Treiber, den ich noch nicht eingecheckt
habe.
Nach einem Reset wird die Uhr z.Zt. mit Tag und Monat 0 initialisiert.
Dies dürfte zu verschmerzen sein, da sie ja ohnehin gestellt werden muß.
Das ganze ist vorläufig. U.a. deshalb, weil ich die BCD/binär- und
zurück-Wandlung noch vom Z80- in den AVR-Teil verlegen will. Außerdem
behandelt sie 2100 noch irtümlicherweise als Schaltjahr.
@ Leo C.
SUPER Leo!
D>ldtim
ZSDOS Time Stamp Loader, Ver 1.1
Copyright (C) 1988 by H.F.Bower / C.W.Cotrill
hallo welt ...loaded at D8D8H
Clock is : AVRCPM Clock 0.1
D>td
- 00, 2000 00:02:45
D>td 4/28/12 10:12:28
Press any key to set time
Apr 28, 2012 10:12:28
D>td
Apr 28, 2012 10:12:31
D>
Die Datei svnrev.inc fehlt noch im trunc.
bios.asm und ipl.asm würde ich langsam entsorgen, führt nur zu
Verwirrungen.
Wollen wir wirklich cpm6X.sys einführen? Ich fand die Trennung von CCP
und BDOS recht transparent.
Joe G. schrieb:> Die Datei svnrev.inc fehlt noch im trunc.
Hier gibts das Tool, das die Datei erzeugt.
http://www.compuphase.com/svnrev.htm
Ich weiß noch nicht, ob ich das Ganze so lassen soll.
> bios.asm und ipl.asm würde ich langsam entsorgen, führt nur zu> Verwirrungen.
Ja.
> Wollen wir wirklich cpm6X.sys einführen?
Nein. Das war/ist nur ein Ergebnis meiner Experimente mit movcpm. Da
steckt auch noch viel Arbeit drin, weil die Distri, die Sprite_tm als
Grundlage genommen hat, kein movcpm enthält, und die Seriennummern
angeglichen werden mußten.
> Ich fand die Trennung von CCP und BDOS recht transparent.
Ja, in diese Richtung sollte es gehen. Ich würde "unser" CP/M gerne
durch ein wirklich vollständiges ersetzen. ZSDOS dann als Alternative in
einem weiteren Zweig.
Außerdem sollte irgendwann noch ein Buildscript kommen, das eine Release
als Zip-Paket für Endanwender erzeugt. Das Paket sollte dann ein
fertiges CP/M-Image enthalten, und keine Abhängigkeiten von SVN.
Leo C. schrieb:> Außerdem sollte irgendwann noch ein Buildscript kommen, das eine Release> als Zip-Paket für Endanwender erzeugt.
Hier ein kleines Script welches eine bootfähige cpm.bin Datei aus BIOS,
CCP, BDOS und IPL erzeugt. Es kann vollständig in AltairSIMH gestartet
werden und schreibt das File auch gleich wieder zurück. dd entfällt
damit. Die Version ist derzeit nur für ZSDOS könnte aber sicher leicht
für die Altair cp/m Version angepaßt werden.
Joe
Hallo Joe,
irgendwie klappt bei mir nichts,hab mal meine fuses mit angehängt
Kannst du mir sonst mal ein Hexfile machen (20Mhz Quarz 38400Baud)?
Gruß
Hannes
@Hannes
sieht eigentlich ok aus. Hier das HEX File
@alle
Ich glaube in unsrer Berechnung der Speichergröße ist noch eine Altlast
sprite_tm eingebaut. Derzeit wird der CCP Start im BIOS über
msize equ 62 ;size of available RAM in k
bias equ (msize-20) * 1024
ccp equ 3400h+bias ;base of cpm ccp
bdos equ ccp+806h ;base of bdos
bios equ ccp+1600h ;base of bios
berechnet. Der Summand -20 bei der Biasberechnung steht auch so im CP/M
Operating System Manual worauf sich sprite_tm ja bezieht. Doch
tatsächlich ist unser System nicht 20K sondern 22K groß. Das kann
schnell nachgerechnet werden.
3400h Sysgen + 800h CCP + E00h BDOS + D00h Bios = 22k
User CCP fängt auch bei DC00h an. Hätten wir ein 62k System, so würde es
bei D400h (62K – 9K) beginnen müssen. Im Bios müsste also msize auf 64
und im bias (msize-22) * 1024 geändert werden. Mit dieser Korrektur
könnte dann auch eine gemeinsame Speicherconfig für BIOS, CCP, und BDOS
verwendet werden.
Lag ich völlig daneben oder ist es nur noch keinem aufgefallen?
Joe
Hallo Joe,
Danke für die schnelle Hilfe... leider auch ohne Erfolg....mit dem
Mega168 läuft alles....mit dem Mega328P geht nichts.....
muss da noch Hardware angepasst werden?? Speicher hab ich
2 mal NEC D424256C-80...
Was kann ich noch tun??
Gruß
Hannes
Hannes schrieb:> Was kann ich noch tun??
Versuche mal statt des externen Quarzes von 20 MHz erst den internen
Takt von 8 MHz zu nehmen. Der Mega328P läuft in unserer Anwendung etwas
außerhalb seiner Spezifikation (3.3V mit 20 MHz). Wenn er mit 8 MHz
läuft, hast du den Fehler. Ich habe hier auch einen liegen, welcher nur
bis 16 MHz geht.
Joe
laut Datenblatt:
• Speed Grade:
– 0 - 4MHz@1.8 - 5.5V, 0 - 10MHz@2.7 - 5.5.V, 0 - 20MHz @ 4.5 - 5.5V
Ich hab mal das BIOS etwas nach der obigen Variante geändert. Die
Speichergröße wird in dieser Variante nur noch in der MEMCFG.LIB
angegeben. Damit kann nun eine beliebige (in den Grenzen des CP/M)
Speicherkonfiguration übersetzt werden. Anbei ein Bsp. mit 53K Speicher.
CPM on an AVR, v3.1 r180
Testing RAM: fill...wait...reread...
Initing mmc...
A:FAT16 File-Image at: 8450, size: 018KB.
B:FAT16 File-Image at: 8959, size: 256KB.
C:FAT16 File-Image at: 8703, size: 256KB.
Partinit done.
Ok, Z80-CPU is live!
ipl
53k cp/m vers 2.2
A>dir
A: CPMSTAT COM
A>cpmstat
- Logged - ---- Records ---- - Tracks - --- Capacity --- --- TPA
---
Drive User Block Track Drive Sys. Drive Directory Drive Bytes
K
A: 0 8 26 1944 2 77 64/ 64 243K 46854
45.76
- Operating System -
Version BDOS BIOS
CP/M 2.2 B806 C600
A>
Joe G. schrieb:> Ich glaube in unsrer Berechnung der Speichergröße ist noch eine Altlast> sprite_tm eingebaut. Derzeit wird der CCP Start im BIOS über>> msize equ 62 ;size of available RAM in k> bias equ (msize-20) * 1024> ccp equ 3400h+bias ;base of cpm ccp> bdos equ ccp+806h ;base of bdos> bios equ ccp+1600h ;base of bios
Sprite_tm ist daran eher unschuldig, glaube ich. Das war ein
Mißverständnis meinerseits. Ich hatte msize vom altairz80 Emulator
übernommen. Dort steht msize aber für die tatsächliche RAM-Größe und
nicht für die "CP/M-Größe", für die ich es dann genommen habe.
> berechnet. Der Summand -20 bei der Biasberechnung steht auch so im CP/M> Operating System Manual worauf sich sprite_tm ja bezieht. Doch> tatsächlich ist unser System nicht 20K sondern 22K groß. Das kann> schnell nachgerechnet werden.
Das CP/M Handbuch definiert ein 20K System, bei dem der CCP auf 3400H
liegt. Unser System ist demgegenüber um b=A800H verschoben, und damit
per Definition ein 62K System.
http://www.cpm.z80.de/manuals/archive/cpm22htm/ch6.htm#Section_6.2> 3400h Sysgen + 800h CCP + E00h BDOS + D00h Bios = 22k> User CCP fängt auch bei DC00h an. Hätten wir ein 62k System, so würde es> bei D400h (62K – 9K) beginnen müssen. Im Bios müsste also msize auf 64> und im bias (msize-22) * 1024 geändert werden. Mit dieser Korrektur> könnte dann auch eine gemeinsame Speicherconfig für BIOS, CCP, und BDOS> verwendet werden.
Die 22 ist im CP/M-Handbuch nicht definiert. Hätten wir ein 64K System,
würde unser BIOS auf F400H beginnen (CCP bei E400H).
> Lag ich völlig daneben oder ist es nur noch keinem aufgefallen?
Mir ists am letzten Freitag aufgefallen. Da hatte ich in den von Dir
verwendeten ZRDOS-Sourcecode geschaut und msize (wieder-) entdeckt.
Joe G. schrieb:> Ich hab mal das BIOS etwas nach der obigen Variante geändert. Die> Speichergröße wird in dieser Variante nur noch in der MEMCFG.LIB> angegeben. Damit kann nun eine beliebige (in den Grenzen des CP/M)> Speicherkonfiguration übersetzt werden. Anbei ein Bsp. mit 53K Speicher.
1
bias equ (msize-22) * 1024
2
ccp equ 3400h+bias ;base of cpm ccp
3
bdos equ ccp+806h ;base of bdos
4
bios equ ccp+1600h ;base of bios
Nix dagegen. Da wir von allen Systemteilen den Sourcecode haben, und
damit auch alles auf beliebige Adressen linken können, brauchen wir
diese Offset-Berechnung sowiso nicht mehr.
Leo C. schrieb:> Da hatte ich in den von Dir> verwendeten ZRDOS-Sourcecode geschaut und msize (wieder-) entdeckt.
Dann mache ich wieder eine -20 und damit ein 62k System daraus und
ändere es im ZRDOS-Code.
Oh sehe gerade Doppelpost - welche Variante nehmen wir?
Joe G. schrieb:> Dann mache ich wieder eine -20 und damit ein 62k System daraus und> ändere es im ZRDOS-Code.
Der Original-ZRDOS-Code braucht das eigentlich garnicht. (REL-File,
Adresse wird erst beim Linken festgelegt.) Quelle hier:
http://www.gaby.de/ftp/pub/cpm/znode51/specials/zsdossrc/zsdos.htm> Oh sehe gerade Doppelpost - welche Variante nehmen wir?
Im letzten Posting habe ich mir wohl mehrfach selber widersprochen.
Was wir nicht (mehr) brauchen, ist das "20K CP/M System" als Referenz.
Die Länge von CCP und BDOS könnte man auch anders bestimmen (Linker).
Das ist aber unnötig aufwendig, weil die seit CP/M 2.0 immer gleich
geblieben sind. Aus historischen Gründen bin ich dafür, ein CP/M-System,
dessen BIOS bei F200H beginnt, weiterhin als 62K-System zu bezeichnen.
Eine Definition für die RAM-Größe brauchen wir eigentlich nicht, da sich
an unseren 64K voraussichtlich nichts ändern wird. Deine Frage habe ich
jetzt immer noch nicht beantwortet. ;)
Vielleicht sollten wir die 3 Dateien MEMCFG.LIB, CFGACPM.LIB, AVRCPM.LIB
zu einer einzigen zusammen fassen? Oder AVRCPM.LIB doch getrennt lassen,
da sie keine harwareabhängingen Teile hat, und wirklich nur fürs BIOS
gebraucht wird?
Klingt sinnvoll.
Ein System mit BIOS ab F200H bezeichnen wir mit 62K und MEMCFG.LIB
CFGACPM.LIB fassen wir zu einer Datei zusammen. AVRCPM.LIB würde ich
auch extra stehen lassen, da sie ja nur fürs BIOS zuständig ist.
Joe G. schrieb:> Hannes schrieb:>> Was kann ich noch tun??>> Versuche mal statt des externen Quarzes von 20 MHz erst den internen> Takt von 8 MHz zu nehmen. Der Mega328P läuft in unserer Anwendung etwas> außerhalb seiner Spezifikation (3.3V mit 20 MHz). Wenn er mit 8 MHz> läuft, hast du den Fehler. Ich habe hier auch einen liegen, welcher nur> bis 16 MHz geht.> Joe>> laut Datenblatt:> • Speed Grade:> – 0 - 4MHz@1.8 - 5.5V, 0 - 10MHz@2.7 - 5.5.V, 0 - 20MHz @ 4.5 - 5.5V
Hallo zusammen,
beim durchsehen des Datenblatts zum ATmega328(P) ist mir ein
vermeintlicher Unterschied zwischen den 168er / 328er mit und ohne P im
Namen aufgefallen:
Ausschnitt aus dem Datenblatt:
http://www.alldatasheet.com/datasheet-pdf/pdf/444347/ATMEL/ATMEGA328.html
BRANCH INSTRUCTIONS
RJMP k Relative Jump PC ? PC + k + 1 None 2
IJMP Indirect Jump to (Z) PC ? Z None 2
JMP(1) k Direct Jump PC ? k None 3
RCALL k Relative Subroutine Call PC ? PC + k + 1 None 3
ICALL Indirect Call to (Z) PC ? Z None 3
CALL(1) k Direct Subroutine Call PC ? k None 4
Note: 1. These instructions are only available in ATmega168PA and
ATmega328P.
Heißt das, dass dem 168er / 328er ohne P im Namen (=ältere Versionen)
die absoluten Sprung-Befehle: JMP und CALL fehlen?
Falls ja, ist für mich nun klar, dass ich mir 328er mit P bestellen
werde um endlich in den Genuss des Z80 Emulators zu kommen!
Hintergrund meiner Frage:
Ich habe es schon mehrmals geschafft, das ich im Code vorhandene RCALL's
durch CALL's ersetzen musste, weil die Adressräume der relativen
Sprungbefehle nicht mehr ausgereicht haben!
Viele Grüße
Markus
Markus G. schrieb:> Heißt das, dass dem 168er / 328er ohne P im Namen (=ältere Versionen)> die absoluten Sprung-Befehle: JMP und CALL fehlen?
Nein, P steht für picoPower und damit für folgende technische Daten:
- True 1,8V supply Voltage
- Minimized leakage current
- Sleeping BOD
- ultra low power 32 kHz Crystal Oscillator
- Digital Input Disable Registers
- Power Reduction Register
- Clock Gating
- Flash Sampling
- Power Down Mode 0,1µA@1,8V
- Power Save Mode 0,6µA@1,8V
Die von dir zitierte Anmerkung 1 steht schon som im Datenblatt vom
ATmega168.
Hast du mal die 8 MHz Variante ausprobiert?
Joe
Markus G. schrieb:> Note: 1. These instructions are only available in ATmega168PA and> ATmega328P.
Das ist zur Abgrenzung zu den kleineren Prozessoren ATmega48 und -88.
Diese brauchen die langen Sprungbefehle nicht, da sie mit RCALL/RJMP den
gesamten Speicher erreichen können.
Hallo zusammmen!
Ich habe von Joerg die Hardware V4 als Eagle Datei bekommen.
Mir ist aufgefallen, das Pin 22 (CE) und Pin 24 (OE) des AS6C4008
jeweils /OE gemeinsam am ATMEGA 644P - Pin 3 anliegen ...
Bitte eine kleine Erklärung ob das ein Fehler ist oder gewollt.
Stefan
Hallo,
habe mir auch mal 2 Varianten aufgebaut und dafür auch ein anderes
Platinenlayout erstellt zum selber ätzen bzw. fräsen. Ich verwende nur
SMD Bauteile und DRAMs von alten SIMM bzw. PS2 Modulen. Das Layout kann
ich bei Interesse hier rein stellen.
Ich habe mitten im Thread davon gelesen, dass es wohl ZSDOS Images gibt.
Kann das jemand zur verfügung stellen?
Danke :)
VG
Franz
@Franz
Noch ein Aufbau, sehr schön! Welchen DRAM verwendest Du?
Anbei zwei ZSDOS Images.
CPMDSK_A.IMG ist ein bootfähiges Image mit einem Uhrentreiber von Leo C.
CPMDSK_D.IMG beinhaltet das komplette System im Altair HD Format. Hier
sind auch die Quellen für das System enthalten. Du kannst das System
selbst mit AVRCPM.SUP erzeugen (braucht bei 20 MHz ca. 30 Sekunden).
Source.zip enthät die Quellen für das BIOS, CCP und IPL
Gruß Joe
Nachtrag:
Ich hatte mich gewaltig mit der Zeit verschätzt. Um das System
vollständig auf unserem System zu übersetzten, d.h. Assembler, Linker,
DDT usw. benötigt man ca. 5 Min und 20 Sekunden. Unter Altair natürlich
nur wenige Sekunden.
Gruß Joe
Weil ich selber keine mehr hatte und man immer einige Platinen bei
pcbcart abnehmen muss um vernünftige Preise zu erhalten kann ich jetzt
hier anbieten:
Platinen und mehr zum Projekt: AVR CP/M USB Stick
Info's: http://avr.cwsurf.de/?AVR_CP%2FM
Ein komplettes CP/M System! Disk Images auf SD Karte. Nur 3 IC's DIL.
Diesmal: Blaue Platinen.
Preise:
Nur Platine: 8€
SD Slot: 4€ (ein paar habe ich noch, sonst muss ich erst aus USA
bestellen)
AVR progr.: 5€ (ATmega328P)
4bit x 256 Drams: 5€ (2 Stück) - nur solange Vorrat reicht.
Peter
Hallo Peter,
von der "blauen Ausgabe" hätte ich gerne ein Exemplar, inclusive der 3
ICs und des SD-Slots. Meine Adresse müsstest Du noch haben.
Gruß Siggi
@siggi & Hans-Werner: Adressen speicherere ich nicht.. (Datenschutz)
bitte sendet mir doch eine Mail über das Forum hier.. dann wird das
einfacher..
Ich bin vom 18-26.10 im Urlaub.. also nicht wundern, wenn es etwas
dauert..
---
Gerade nochmals SCDA6A0101 bei CSD bestellt.. Nun habe ich wieder genug
Slots für alle Platine.. habe trotzdem auch mal einen Ersatz-Slot
'drangefriemelt'.. geht auch..
Peter
Hier mal ein paar neue Diskimages und viele Fragen ;-)
CPMDSK_G.IMG = Fortran Compiler
CPMDSK_H.IMG = PL/I Compiler
Pl/I läuft komplett mit z.B FIB.PLI:
PLI FIB
LINK FIB
FIB
Fortran ist ein hello.for dabei, aber der Compiler beschwert sich..?
(Leider ist das editieren von Files unter CP/M auch nicht so einfach..
hat da
jemand ein gut funktionierendes VDE.COM / ZDE.COM?)
Ein paar Fortran Beispielprogramme, die sich hiermit compilieren lassen
wäre schön..
---
Frage 1:
Ich bin mit TP3 inzwischen bei CPMDSK_I.IMG angekommen. Images werden
aber nur bis _H gelesen. Muss ich um z.B 2 weitere einlesen zu lassen
die Konstanten MAXDISKS von 8 auf 10 erhöhen in dsk_fsys.asm:
; Fields in the parttabl
.equ MAXDISKS = 8 ;Max number of Disks (partitions)
???
Und muss woanders noch was geändert werden?
---
Frage 2:
Ich habe versucht ein neues 8MB Diskimage zu erstellen:
del CPMDSK_G.IM_
del CPMDSK_G.IMG
mkfs.cpm.exe -f myz80 -b cpm.bin -L test CPMDSK_G.IM_
rem FORTRAN
cpmcp -f myz80 CPMDSK_G.IM_ cpmdsk/FORTRAN/F80.COM 0:F80.COM
cpmcp -f myz80 CPMDSK_G.IM_ cpmdsk/FORTRAN/HELLO.FOR 0:HELLO.FOR
rem ...
rem make at least 8192k in size
dd if=CPMDSK_G.IM_ of=CPMDSK_G.IMG ibs=8388608 conv=sync
Es werden aber keine Files mit DIR anschließend angezeigt..?
(Ich vermute mein cpm.bin ist nicht passend dafür..?)
???
---
Peter
Peter Sieg schrieb:> Frage 1:> Ich bin mit TP3 inzwischen bei CPMDSK_I.IMG angekommen. Images werden> aber nur bis _H gelesen. Muss ich um z.B 2 weitere einlesen zu lassen> die Konstanten MAXDISKS von 8 auf 10 erhöhen in dsk_fsys.asm:>> ; Fields in the parttabl>> .equ MAXDISKS = 8 ;Max number of Disks (partitions)>> ???> Und muss woanders noch was geändert werden?
Images und Partitonen sind 2 verschiedene Dinge.
Peter Sieg schrieb:> (Ich vermute mein cpm.bin ist nicht passend dafür..?)
Peter, die Einstellungen für die Diskettenformate bzw. HD stehen in der
AVRCPM.LIB
Habe nun mit folgenden Änderungen:
; Fields in the parttabl
.equ MAXDISKS = 10 ;Max number of Disks (partitions); was 8
.equ PARTENTRY_SIZE = 11 ;Size of a Partitiontableentry; was 9
einen erfolgreichen Scan des LW: I:
CPM on an AVR, v2.3 r185
Testing RAM: fill...wait...reread...
Initing mmc...
A:FAT16 File-Image at: 514, size: 256KB.
B:FAT16 File-Image at: 530, size: 256KB.
C:FAT16 File-Image at: 546, size: 256KB.
D:FAT16 File-Image at: 562, size: 256KB.
E:FAT16 File-Image at: 578, size: 256KB.
F:FAT16 File-Image at: 594, size: 256KB.
G:FAT16 File-Image at: 610, size: 256KB.
H:FAT16 File-Image at: 626, size: 256KB.
I:FAT16 File-Image at: 002, size: 8192KB.
Partinit done.
Ok, Z80-CPU is live!
ipl
62k cp/m vers 2.2
A>
aber DIR I: zeigt NO FILES ??
---
Habe dann mal TP3 auf F gelegt und ALGOL auf J und B auf I kopiert:
A>dir f:
F: READ ME : TINST COM : TINST DTA : TINST MSG
F: TURBO COM : TURBO MSG : TURBO OVR : CMDLIN PAS
F: LISTER PAS : MC-MOD00 INC : MC-MOD01 INC : MC-MOD02 INC
F: MC-MOD03 INC : MC-MOD04 INC : MC-MOD05 INC : MC HLP
F: MC PAS : MCDEMO MCS : MC COM : MC-MOD03 COM
F: HELLO PAS
A>dir h:
H: FIB PLI : CHESS PLI : LIB COM : LINK COM
H: RMAC COM : PLI0 OVL : PLI1 OVL : PLI2 OVL
H: PLI COM : TEST PLI : PLILIB IRL : OPTIMIST PLI
H: OPTIMIST COM : PLIDIO ASM : MATSIZ LIB : MATSIZE LIB
A>dir i:
I: TTT2 COM : SARGON COM : OTHELLO COM : MMIND COM
I: ED COM : LOAD COM : STONE COM : PIP COM
I: STAT COM : SUBMIT COM : XSUB COM : LADDER COM
I: LADDER DAT : LADCONF COM : CURON COM : PACMAN COM
I: HITCH COM : HITCHHIK DAT : :
I: : : :
I: :
A>dir j:
J: : : :
J: :
A>
???
---
I: und J: werden auch mit dem freien Platz nicht korrekt angezeigt:
A>stat
A: R/W, Space: 40k
B: R/W, Space: 0k
C: R/W, Space: 129k
D: R/W, Space: 95k
E: R/W, Space: 48k
F: R/W, Space: 7928k
G: R/W, Space: 121k
H: R/W, Space: 13k
I: R/W, Space: 938k
J: R/W, Space: 952k
---
Ach Ja.. ALGOL macht bei LUNAR auch irgendwie Mist.. BCD Problem?
Peter
@Peter
Nachtrag: im BIOS.MAC mußt du natürlich auch das HD-Format eintragen,
oder du nimmst dieses CPM.BIN
@ Leo C.
Läuft Dein Server http://cloudbase.homelinux.net/... noch?
Peter Sieg schrieb:>> Peter, die Einstellungen für die Diskettenformate bzw. HD stehen in der>> AVRCPM.LIB>> ???>> Diese Datei habe/finde ich nicht??
Klar habe ich die/gefunden ;-)
Sorry.. gehört zum BIOS.
@Joe G: Kannst du deine *.MAC, AVRCPM.LIB und das damit erstellte
CPM.BIN mal als ZIP hier anhängen..?
BTW: Mikrocontroller Forum hat glaube ich inzwischen auch einen SVN
Server..
Peter
Peter Sieg schrieb:> @Joe G: Kannst du deine *.MAC, AVRCPM.LIB und das damit erstellte> CPM.BIN mal als ZIP hier anhängen..?
Die hast du nun sicherlich gefunden.
Übrigens, das 8MB HD-Format hat einen anderen Aufbau. Das mußt du in den
"diskdefs" berücksichtigen.
Hier die diskdefs für die CP/M Tools oder den Totalcommander.
# SIMH AltairZ80 Harddisk
diskdef simhd
seclen 128
tracks 2048
sectrk 32
blocksize 4096
maxdir 1024
skew 0
boottrk 6
os 2.2
end
Hi. Die diskdefs hatte ich schon angepasst..
Ich habe jetzt mal dein cpm.bin verwendet. Immer LW: I: bekomme ich
keine/vernünftige DIR Anzeige. Hatte dort erstmal das 8192k TP3 Image..
= NO FILES. Habe dieses dann als F: kopiert und unter I: eine Kopie von
A:
A>dir
A: ASM COM : DDT COM : DUMP COM : ED COM
A: T COM : TLOOP COM : LOAD COM : MBASIC COM
A: 23 BAS : BAGELS BAS : CHECKERS BAS : STARTREK BAS
A: TREKINST BAS : MASTRMND BAS : WEEKDAY BAS : PIP COM
A: STAT COM : SUBMIT COM : XSUB COM : ZORK1 COM
A: ZORK1 DAT : SURVEY COM
A>dir f:
F: READ ME : TINST COM : TINST DTA : TINST MSG
F: TURBO COM : TURBO MSG : TURBO OVR : CMDLIN PAS
F: LISTER PAS : MC-MOD00 INC : MC-MOD01 INC : MC-MOD02 INC
F: MC-MOD03 INC : MC-MOD04 INC : MC-MOD05 INC : MC HLP
F: MC PAS : MCDEMO MCS : MC COM : MC-MOD03 COM
F: HELLO PAS
A>dir i:
I: : :
A>dir j:
J: ASM COM : DDT COM : DUMP COM : ED COM
J: T COM : TLOOP COM : LOAD COM : MBASIC COM
J: 23 BAS : BAGELS BAS : CHECKERS BAS : STARTREK BAS
J: TREKINST BAS : MASTRMND BAS : WEEKDAY BAS : PIP COM
J: STAT COM : SUBMIT COM : XSUB COM : ZORK1 COM
J: ZORK1 DAT : SURVEY COM
A>
wieder bei I: keine Anzeige.. bei F: aber wird das 8192k TP3 Image
sauber gelistet.
Hmm..?? zumindest werden mal LW: A-J gescannt und angezeigt..
A>stat
A: R/W, Space: 41k
B: R/W, Space: 0k
C: R/W, Space: 131k
D: R/W, Space: 97k
E: R/W, Space: 49k
F: R/W, Space: 7928k
G: R/W, Space: 123k
H: R/W, Space: 13k
I: R/W, Space: 103k
J: R/W, Space: 41k
---
Habe noch Hitech-C und PARASOL in der Mache als neue Diskimages..
Peter
Bez. CPM.BIN:
Ich verwende Batch Dateien unter Windows - 1:
aliados m80.com =bios.mac
aliados l80.com bios.rel,bios.bin/n/e
aliados m80.com =ipl.mac
aliados l80.com ipl.rel,ipl.bin/n/e
und 2:
dd conv=sync bs=128 count=1 if=ipl.bin > cpm.bin
dd conv=sync bs=128 count=44 if=CPM.SYS >> cpm.bin
dd conv=sync bs=128 count=7 if=bios.bin >> cpm.bin
Kann ich das genau so auch mit den neueren Dateien in Source.zip machen?
Peter
Peter Sieg schrieb:> Kann ich das genau so auch mit den neueren Dateien in Source.zip machen?
Nein.
Da das System nun aus IPL CCP BDOS und BIOS zusammengesetzt ist, mußt du
die folgende Zusammensetzung wählen.
dd conv=sync bs=128 count=1 if=ipl.bin > cpm.bin
dd conv=sync bs=128 count=16 if=ZSCCP.BIN >> cpm.bin
dd conv=sync bs=128 count=28 if=ZSDOS.BIN >> cpm.bin
dd conv=sync bs=128 count=6 if=bios.bin >> cpm.bin
Joe
sorry, hab' gerade keine Zeit zum mittmischen.
Joe G. schrieb:> @ Leo C.> Läuft Dein Server http://cloudbase.homelinux.net/... noch?
Letzte Nacht ist mir aufgefallen, daß das Ding hängt. Nach einem
Neustart lief wieder alles. Und jetzt schon wieder nicht mehr. :-(
Peter Sieg schrieb:> make_bios.bat gibt aber jede Menge Fehler:
Ich benutze den Assembler, Linker usw. unter Altair SIMH. Da laufen die
Quellen fehlerfrei. Wenn du unter CP/M arbeitest, dann kannst du das dd
unter Windows gleich einsparen und alles zusammen unter CP/M binden
(AVRCPM.SUB)
Joe
Leo C. schrieb:> Für den Server brauche ich mal ne ruhige halbe Stunde. Heute aber leider> nicht mehr.
kein Problem...
Andere Baustelle: Ist den der PCF8583T für die Echzeituhr noch aktuell?
Ich würde gerne das Layout fertigstellen.
Yo. Rom wurde ja auch nicht an einem Tag erbaut..
Hmm.. das ZSDOS nicht unter aliados assemblierbar ist..?
Habe auch mal m80l80pc probiert. Da sind es 'nur' 97 Fehler:
C:\DATEN\Eagle\AVRCPM~1\KOPIEV~1>m80.com =zsdos.mac
V MACLIB ZSDOS.LIB ; Get
initialization code
e
V IF ZRL
V IF ZSDOS11
V IF ZS
Es fehlt anscheinend die ZSDOS.LIB und er kann das IF ... nicht ab..?
---
Nun, lasse es vorerst mal in diesen für mich unbefriedigenden Zustand:
Verwende das cpm.bin von Joe G. was ich selbst aber nicht erzeugen kann
mit den Windows Tools..
Ich kann mit den Änderungen am AVR Source nun bis LW: J arbeiten, wobei
I: nicht nutzbar ist..?
Werde es nochmal bis LW: L: erweitert und dann testen..
Falls das alles so nicht geht, werde ich wohl alles zurück bauen und
dann eben nur bis LW: H: gehen und ggf. eine 2te SD Karte für die
nächsten 8 LW: verwenden.
Peter
@Joe G.: Danke! Bringt aber keine Änderung: Scan nur bis J und DIR I: =
: : :
Da ist wohl noch ein wenig mehr im Argen.. zu tun..
Das 8192k Image mit Turbo Pascal 3 wurde aber ja auch vorher erkannt bei
Laufwerk F:
Peter
Ich habe jetzt erstmal alles zurück gebaut auf meine letzte Version,
wo ich das unter aliados assemblierte cpm.bin verwenden kann und auf
LW: A: - H:
Die Änderung auf mehr LW: - z.B bis L: müssen wir dann noch mal in Ruhe
in Angriff nehmen.. ich denke auch, das da einiges an ueberfluessiger
Code
in den Sourcen drin ist.. in fat16 z.B ist schon drin, das er A-Z
sucht..
Peter
@Joe G.: Evtl. kannst du ja das fertige AltairSIMH disk/hd-image hier
einhängen, womit sich cpm.bin komplett bilden läßt auf Basis ZSDOS..
Den AltairSIMH habe ich hier noch, aber nur ein cpm 2.2 diskimage auf a:
Peter
Kurze Anleitung dazu.
1. Altair.zip entpacken
2. AltairAll.bat starten
3. auf Laufwerk I: wechseln
4. mit "do avrcpm.sub" das Übersetzen und Linken starten
5. fettich Meister, im Verzeichnis von Altair steht die fertige CPM.BIN
schönen Abend
Joe
Was war eigentlich der Grund/Vorteil auf ZSDOS im CPM.BIN zu gehen..?
Weil es auch im Source vorliegt?
Mit der Erzeugung aus einer Emulation heraus kann ich leben ;-)
---
Meine Wünsche für Weihnachten ;-)
* mehr Diskimages mit lauffähigen, getesteten Applikationen
* Unterstützung von mehr Diskimages als bisher 8 (A-H).
* Evtl. einen Weg Dateien zw. laufendem CP/M und Hostsystem
auszutauschen (Kermit?)
Gruß Peter
@Leo C.
Ja, der hat RV2123-C2 ist auch nicht schlecht. Er hat schon den Quarz
integriert.
@Peter
ZSDOS hat bei voller Kompatibilität zu CP/M 2.2 einige wesentliche
Verbesserungen. Näheres hier:
http://susowa.homeftp.net/index.php/software-mainmenu/cpm-mainmenu-116/95-zsdos-zddos.html
@alle
Es gibt einen Entwurf mit RTC (PCF8583T) und einem 8-Bit Port (PCF
8574). Außerdem gibt es einen Erweiterungsport mit I2C und 2 x ADC. Die
Stromversorgung ist über den USB-Port realisiert, über den wahlweise das
VT100 Terminal angeschlossen werden kann oder der Propeller (VGA mit
VT100 Terminal) programmiert werden kann. Weiterhin gibt es einen PS2
Anschluss für die Tastatur. Die Platine passt in ein Fischer Alu-Gehäuse
(AKG 7124
ME)beziehen u.a. bei Reichelt.
Da bisher kein großes Interesse vorhanden war, habe ich den Aufbau noch
nicht in Angriff genommen. Doch jetzt scheint wieder Leben in das
Projekt zu kommen. Welche Wünsche gibt es denn noch?
Peter Sieg schrieb:> Was war eigentlich der Grund/Vorteil auf ZSDOS im CPM.BIN zu gehen..?
Wenn Du nach Lesen der "feature list" [1] von ZSDOS für Dich keine
Vorteile erkennen kannst, spricht natürlich nichts dagegen, bei
Original-CP/M zu bleiben.
> Weil es auch im Source vorliegt?
Source gibts auch für das Original.
> Meine Wünsche für Weihnachten ;-)>> * mehr Diskimages mit lauffähigen, getesteten Applikationen> * Unterstützung von mehr Diskimages als bisher 8 (A-H).
Wenn die Images (Laufwerke) nur ein paar hundert KByte groß wären, und
einzeln/unabhängig voneinander auswechselbar wären, würde ich das ja
vielleicht auch so sehen.
Aber: Auf ein Diskimage mit 8 Megabyte passen sehr viele
CP/M-Programme/-Pakete.
Kann es sein, daß Du die Images in etwa wie Archivdateien betrachtest,
statt wie (Festplatten-)Laufwerke?
Zugegebenermaßen wirds wg. der flachen Dir-Struktur unter CP/M leider
schnell unübersichtlich, und die User-Bereiche (0..31) werden auch
schlecht unterstützt. Ich meine aber, verschiedene Anwendungen auf einem
Laufwerk in getrennten User-Bereichen zu verwalten, ist immer noch
einfacher, als die Images auf der SD-Karte neu zu mischen.
Mit ZSDOS gibts übrigens bessere Unterstützung der User-Bereiche (z.B.
Pfad-Aliase für User-Nrs).
> * Evtl. einen Weg Dateien zw. laufendem CP/M und Hostsystem> auszutauschen (Kermit?)
CP/Net? ;)
Mit X/Y/Z-Modem-Protokoll müßte das eigentlich auch über die
Host-Schnittstelle gehen. Leider habe ich noch kein Programm gefunden,
das das unterstützt.
[1] Geheimtip: Doku
1
1.5 Differences Between CP/M 2.2, ZRDOS and ZSDOS.
2
3
Compatibility with existing applications was one of the primary goals of
4
ZSDOS. Most programs that run under CP/M 2.2 or ZRDOS 1.x should also run
5
under ZSDOS without any problems. The few programs that won't run under ZSDOS
6
depend on specific (unpublished) addresses in BDOS.
7
8
A quick summary of the features of ZSDOS compared to ZRDOS and CP/M 2.2 is
Peter Sieg schrieb:> Die Änderung auf mehr LW: - z.B bis L: müssen wir dann noch mal in Ruhe> in Angriff nehmen..
Die Nummer der RAM-Disk steht auch in config.inc:
1
#define RAMDISKNR 'I'-'A' /* Drive "letter" for first RAM disk */
Um die Anzahl der möglichen SD-Karten-Disks zu erhöhen muß man diese
Konstante vergrößern.
> ich denke auch, das da einiges an ueberfluessiger Code> in den Sourcen drin ist.. in fat16 z.B ist schon drin, das er A-Z> sucht..
Ich muß doch sehr bitten. ;-)
Die Anzahl der Laufwerke ist aber auch durch das im BIOS dazu
reservierten RAMs begrenzt. Da die Verwaltung dynamisch erfolgt, können
um so mehr Laufwerke verwaltet werden, je kleiner diese sind.
Hallo,
das VT Terminal mit dem Propeller interessiert mich auch. Nun muss das
einer nur noch in den Atmel bringen... Interessant wäre allerdings wenn
man die I/O Ports auch über in und out Befehle von der Z80 Seite zu
erreichen sind.
Gruß
Hans-Werner
Hans- w. Schütz schrieb:> Interessant wäre allerdings wenn> man die I/O Ports auch über in und out Befehle von der Z80 Seite zu> erreichen sind.
Klar, das ist sowieso die einfachste Möglichkeit, die Ports für den Z80
zugänglich zu machen.
Leo C. schrieb:> Die Nummer der RAM-Disk steht auch in config.inc:#define RAMDISKNR 'I'-'A'
/* Drive "letter" for first RAM disk */
Das hatte ich parallel auch schon gemacht, obwohl die Anz. Ramdisks bei
mir auf 0 steht. Es kam aber zu den oben beschriebenen Effekten:
I: DIR => : : : sonst nichts.
J: geht mit ZSDOS, mit CPM.BIN orig. 2.2 nicht.
Erweiterung auf K+L: Anzeige / Scan nur bis J:
Ich verwende eigentlich immer noch die 256k Images, weil:
1. Ich noch nicht versucht habe unter Windows, größere Images (8192k) zu
erzeugen.
2. Wirklich die Übersicht verloren geht und ich eigentlich thematisch
getrennte Sachen auch getrennt halten wollte.
Aber mit den Userbereichen ist klar eine Möglichkeit, die ich bisher
noch
nicht genutzt habe.
Wie kann ich denn unter Windows ein 8192k Leerimage anlegen?
Kann jemand dazu ggf. die passende diskdefs hier einhängen.
---
@Joe G: Achtung der bisher verwendete SD Card Slot ist (fast) nicht mehr
lieferbar! CSD hat noch ca. 50Stk. SCDA6A0101 - die passen! Danach heißt
es umstellen auf einen anderen Slot.
Wenn auf deine Platine der Propeller Chip für das Terminal mit drauf
ist,
habe ich (andere sehen das sicher anders..) kein Interesse daran..
Aus meiner Sicht sollte das AVR Only sein.. eher kann der Propeller
nebenbei noch Z80 spielen..
Peter
Joe G. schrieb:> Das läuft bei mir schon ein Jahr. Genau diese Schaltung ist auf dem> neuen Layout.> Beitrag "Re: CP/M auf ATmega88"
Mach doch mal bitte ein paar Foto's/Video über Youtube davon..
Wenn es wirklich gut läuft und eine bessere Anzeigequalität hat als
MicroVGA kann man ja mal über seinen Schatten springen..
und so ein Weihnachtsprojekt hätte ja auch was.. ;-)
Peter
Peter Sieg schrieb:> CSD hat noch ca. 50Stk. SCDA6A0101 - die passen!
Danke für den Hinweis.
Die Terminalhardware sehe ich ganz pragmatisch. Sicher könnte es auch
ein AVR sein, doch mit dem Propeller geht es schnell, einfach und gut.
Die Videoqualität ist deutlich besser als bei der MicroVGA und das
Terminal kann nach den eigenen Bedürfnissen programmiert werden. Ich
mache bei Gelegenheit mal einige Fotos.
Joe
Peter Sieg schrieb:> Wie kann ich denn unter Windows ein 8192k Leerimage anlegen?> Kann jemand dazu ggf. die passende diskdefs hier einhängen.Beitrag "Re: CP/M auf ATmega88"
Danach mit cpmtools bespielen. Format 'myz80' bzw. 'simhd'.
1
# MYZ80 hard drive (only works with libdsk, because it has a 256-byte header)
Peter Sieg schrieb:> Wie kann ich denn unter Windows ein 8192k Leerimage anlegen?
Unter Altair SIMH ein HD Laufwerk erzeugen und in CPMDSK_X.IMG
umbenennen.
Joe G. schrieb:> Unter Altair SIMH ein HD Laufwerk erzeugen und in CPMDSK_X.IMG> umbenennen.
Ahh..?? Und wie geht nun sowas..?
BTW: Ich habe hier im Thread ein myz80.img 'gefunden' was 8193k groß
ist..?
Peter
Ich habe jetzt mal versucht ein simhd.img unter Windows zu erstellen:
makeimage /dev/null simhd.img 8388480
mkfs.cpm.exe -f simhd -b cpm.bin -L test simhd.img
Das Problem (idiotisch!) simhd ist bei mir nicht in diskdefs drin und
editieren unter Windows kann ich es nicht, weil dann wieder CR+LF
eingefügt werden und das dann wieder unter windows mit dem cpmtools
nicht mehr lesbar ist(so ein 'scheiß' mit den cpmtools).
Kann mir bitte jemand eine vollständige diskdefs für die cpmtools + TC
mit avrcpm, myz80 und simhd hier einhängen..
Danke+Gruß, Peter
Es gibt aber auch für Windows Editoren, die Unix-Zeilenenden können.
Und dann gibt es noch sowas wie dos2unix und unix2dos usw.
Der "Scheiß" sind natürlich die von Dir verwendeten Windows-Tools, nicht
etwa die cpmtools.
Ein guter Editor unter Windows ist WinVi
http://www.winvi.de/de/Peter Sieg schrieb:> Ahh..?? Und wie geht nun sowas..?
1. neu.dsk im altairSIMH als HD anlegen
d tracks[0-7] 254
attach dsk zsdos.dsk
;attach hdsk i.dsk
attach hdsk neu.dsk
set cpu 64k
set cpu itrap
set cpu z80
set cpu altairrom
set cpu nonbanked
reset cpu
boot dsk
2. HD mit Programmen füllen
3. SIMH beenden
4. neu.dsk in CPMDSK_X.IMG umbenennen (X) ist der Laufwerksbuchstabe
deiner HD
5. auf SD-Card kopieren
6. freu
anbei noch ein "freu"Immage
Joe
Das mit neu.dsk werde ich mal probieren..
Ich möchte aber eigentlich lieber über die cpmtools gehen..
(warum eigentlich..? -> kann mal alles schön in Batch-Dateien legen..)
Ich habe also ein myz80.img und ein simhd.img mit makedisk angelegt:
(Ist auch alles schön mit E5 gefüllt gewesen)
makeimage /dev/null simhd.img 8388480
mkfs.cpm.exe -f simhd -b cpm.bin -L test simhd.img
+
makeimage /dev/null myz80.img 8388736
mkfs.cpm.exe -f myz80 -b cpm.bin -L test myz80.img
---
dann mit ein paar Programmen gefüllt:
rem Wordstar
cpmcp -f simhd simhd.img cpmdsk/ws30-vt100/INSTALL.COM 0:INSTALL.COM
cpmcp -f simhd simhd.img cpmdsk/ws30-vt100/MAILMRGE.OVR 0:MAILMRGE.OVR
...
rem Multiplan
cpmcp -f simhd simhd.img cpmdsk/MULTPLAN/INSTALL.COM 1:INSTALL.COM
cpmcp -f simhd simhd.img cpmdsk/MULTPLAN/INSTALL.DAT 1:INSTALL.DAT
---
mit cpmls bekomme ich die auch angezeigt.
Auf SD Karte als CPMDSK_E.IMG kopiert.
LW: E wird gefunden mit 8192k aber DIR E: NO FILES
???
Bei beiden identisch.
Als CPMDSK_A.IMG wird auch CP/M gebootet.. aber NO FILES??
Was mache ich falsch?
Peter
Peter Sieg schrieb:> makeimage /dev/null simhd.img 8388480> mkfs.cpm.exe -f simhd -b cpm.bin -L test simhd.img
Versuch' mal das simhd Image (geringfügig) zu vergrößern mit:
simhd Images werden nur erkannt, wenn sie die exakt richtige Größe von
8388608 Bytes haben (2048 Traks * 32 Sectors/Track * 128 Byte/Sector),
weil es sonst nicht viele Erkennungskriterien für dieses Format gibt.
Image-Files, deren Dateinamen dem Muster 'CPMDSK_[A-Z].IMG' entsprechen,
werden in alphabetisch aufsteigender Reihenfolge als Laufwerke A: B: ...
eingebunden. Wenn 'CPMDSK_E.IMG' die erste erkannte Datei ist (und keine
CP/M-Partitionen vorhanden sind), bekommt sie den Laufwerksbuchstaben
'A'.
Ich habe es gerade selber nochmal versucht. Dabei gehe ich davon aus,
dass bei dir in simhd das korrekte Format eingetraegn ist.
1. mkfs.cpm.exe -f simhd -b cpm.bin -L test simhd.img
2. dd if=simhd.img of=i.dsk ibs=8388608 conv=sync
3. stat i:dsk:
I: Drive Characteristics
65344: 128 Byte Record Capacity
8168: Kilobyte Drive Capacity
1024: 32 Byte Directory Entries
0: Checked Directory Entries
256: Records/ Extent
32: Records/ Block
32: Sectors/ Track
6: Reserved Tracks
Ahh.. ich habe aber Schritte 1+2 in umgekehrter Reihenfolge gemacht!
Ich teste das also noch mal in deiner Reihenfolge.
Trotzdem bin ich mit den user Bereichen nicht wirklich 'glücklich'.
Nach vielen Operationen wird man autom. auf A: und user 0 'zurück
geworfen':
A>i:
I>user 6
I>dir
I: CREF80 COM : F80 COM : HELLO FOR : L80 COM
I: LIB80 COM : M80 COM : OBSLIB REL : FORLIB REL
I: README TXT : HELLO REL : HELLO COM
I>hello
HELLO, WORLD
STOP ** at address 0131 **
A>
Peter
Auch Interessant!
Auf dem Altair Emulator wird man auf A: wie obern geschildert zurück
gebeamt.. auf dem avrcpm NICHT:
A>e:
E>user 6
E>dir
E: CREF80 COM : F80 COM : HELLO FOR : L80 COM
E: LIB80 COM : M80 COM : OBSLIB REL : FORLIB REL
E: README TXT : HELLO REL : HELLO COM
E>hello
HELLO, WORLD
STOP ** at address 0131 **
E>dir
E: CREF80 COM : F80 COM : HELLO FOR : L80 COM
E: LIB80 COM : M80 COM : OBSLIB REL : FORLIB REL
E: README TXT : HELLO REL : HELLO COM
E>
???
Peter
Hmm. In den Images ist das über Altair i.dsk mit do avrcpm.sub erzeugte
CPM.BIN enthalten..
BTW: Von so einer 8M Disk kann ich nicht als LW A: booten.. =reg.dump 76
76 76..
Daher verwende ich z.B eine 256k LW A: disk image und dann jetzt jeweils
8M images als B: und C: (TP3).
Peter
Hier noch ein ZIP mit MuMATH Package (bisher nur im Altair Emu getestet)
und eine deutsche PDF Anleitung dazu.
From:http://www.retroarchive.org/cpm/misc/misc.htm
This package was originally issued for the OSBORNE 1.
The MUSIMP.COM file contains my patch to make it useable
under generic cp/m. The original osborne version of this
executable is enclosed as MUSIMP.OBJ
The CLES?.* files are a tutorial in using the calculation
parts of MUMATH. The PLES?.* comprise a programming tutorial
for MUSIMP.
rwd
06/09/98
---
Schnellstart
Zum Kennenlernen von Musimp:
Starte Musimp am CP/M prompt: MUSIMP ALL
Setze „PAUSE“ für die nachfolgende Demo durch folgende Eingabe am “?“
Prompt: PAUSE:100;
(Altair Emulator: PAUSE:1000;)
Starte die Demo durch folgende Eingabe am “?“ Prompt: RDS(DEMO,ALL);
Beende Musimp
Peter
Liebe Mit-Retro-Freaks.
Ich hatte mal Lust diesen gesamten Thread etwas aufbereitet als PDF zur
Verfügung zu stellen. PDF (272 Seiten; von ursprünglich >470 Seiten)
habe ich im Wiki abgelegt und im Artikel eingebunden:
http://www.mikrocontroller.net/articles/AVR_CP/M
Ist schon sehr interessant, wie sich das alles so entwickelt hat und wer
maßgeblich daran beteiligt war bzw. ist!
Ich habe mir erlaubt auch ein Inhaltsvereichnis anzulegen mit Highlights
der
Entwicklung etc.
---
Ich selbst werden mich demnächst nach Datenaustausch acrcpm <-> PC über
Terminalsoftware (X/Y/Z-Modem o.ä) umschauen.. ich möchte gerne Dateien
zw. avrcpm und Kostsystem einfach austauschen können.
---
Mit max. 8x 8MB Diskimages und der Möglichkeit Programmpakete in User
Bereiche zu strukturieren, haben wir wohl ersteinmal genügend Platz..
;-)
---
Je länger ich drüber nachgedacht habe, wäre eine Stand-Alone Lösung mit
eigenen VGA+Tastatur Teil (auf Basis Propeller) doch 'nicht
uninteressant'.
Wer hätte den daran noch interesse..?
---
Was gäbe es sonst noch für 'sinnvolle' Erweiterungsmöglichkeiten?
---
Peter
Peter Sieg schrieb:> Je länger ich drüber nachgedacht habe, wäre eine Stand-Alone Lösung mit> eigenen VGA+Tastatur Teil (auf Basis Propeller) doch 'nicht> uninteressant'.
5 Platinen dazu sind gerade in Auftrag.
Peter Sieg schrieb:> Was gäbe es sonst noch für 'sinnvolle' Erweiterungsmöglichkeiten?
Mir fällt da schon noch einiges dazu ein.
Einen ATmega644 einsetzen. Der hätte eine zweite serielle Schnittstelle
z.B. für den Datenaustausch mit einem anderen System und noch genug Pins
für eine LPT Schnittstelle.
Einen AT90USB64/128 einsetzen. Dort könnte das Terminal über USB
angeschlossen werden und die serielle Schnittstelle ist ebenfalls frei.
Weiterhin gibt es genug Portpins. Die Programmierung über ISP kann auch
entfallen, da er über USB mit LUFA geflasht werden kann.
Mit der „Cpmlino“ Variante sieht es nicht so gut aus. Die derzeitige
Entwicklung geht ja zum ATmega32U4 und der ist wirklich Mist! Wenn man
sich mal die Portaufteilung ansieht, fragt man sich ernsthaft, was die
Entwickler dabei gedacht haben.
Joe
@Joe G. Der Schaltplan zeigt was..?
Die 5 Platinen sind die Version mit P8X32 Terminal?
Falls noch eine frei wäre..
---
I2C hab ich bisher auch noch überhaupt gar nichts gemacht.. hier gäbe es
auch
noch so einige Möglichkeiten.. Ich glaube der RTC läuft über I2C und
dafür habt ihr auch schon einen Treiber gemacht..?
---
Chip-8 Emulator unter CP/M wäre auch ein schönes Projekt.
---
Peter
Peter Sieg schrieb:> @Joe G. Der Schaltplan zeigt was..?
Der Schaltplan zeigt ein CP/M System mit VT100 Terminal, PS2 Tastatur,
RTC sowie einem 8-Bit Port. Ich hatte es schon hier beschrieben.
Beitrag "Re: CP/M auf ATmega88"
Da jedoch keiner so richtig Interesse gezeigt hat, hatte ich einfach für
mich 5 Testplatinen bestellt. Mit so einer plötzlichen Resonanz hatte
ich gar nicht gerechnet. Nun sind sie schon wieder alle.
1 x Joe G.
1 x Peter Z.
1 x Hans-Werner
1 x Peter S.
1 x Leo C.
Ohne den Anschein der Bestechlichkeit zu erwecken, würde ich Leo C.
gerne eine zukommen lassen :-). Somit hätten wir alle die gleiche
Hardware um die RTC die A/D-Wandler und den 8-Bit Port in Betrieb zu
nehmen. Bei Bedarf können wir ja dann wieder eine größere Serie
auflegen. Möglicherweise ergeben sich auch noch einige Änderungen.
Joe
@Joe G. Freut mich, das noch eine 'über' war .. ;-)
Auf dem Schaltplan sehe ich einen ATmega88/168 und Ein HM51W17805 =
SRam? und einen SD Slot.. sonst nichts Wesentliches.. bin ich blind?
Von P8X32 und ser.Eprom nichts zu sehen.. ich denke der Schaltplan passt
nicht zum verlinkten Board & Beschreibung..
Peter
Habe hier noch ein Problem mit einem avr cpm stick Aufbau.
Habe schon alles nachgelötet, C am SD Slot gwechselt.. immer das
gleiche:
Initing mmc...
A:FAT16 File-Image at: 002, size: 256KB.
Partinit done.
Ok, Z80-CPU is live!
Z V A =00 BC =A201 DE =0001 HL =DCD0 SP=BF3E PC=F2F0 76 76 76
A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00 CPU
halted!
CPM on an AVR, v2.3 r185
Testing RAM: fill...wait...reread...
Initing mmc...
A:FAT16 File-Image at: 514, size: 256KB.
B:FAT16 File-Image at: 530, size: 8192KB.
C:FAT16 File-Image at: 002, size: 8192KB.
D:FAT16 File-Image at: 1042, size: 8192KB.
Partinit done.
Ok, Z80-CPU is live!
Z V A =00 BC =A201 DE =0001 HL =DCD0 SP=BF40 PC=F2F0 76 76 76
A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00 CPU
halted!
Oben mit eine SD Karte mit nur A Image.
Unten andere SD Karte mit 4 Images.
???
Irgendeine Idee?
Peter
Du könntest ja mal .equ INS_DEBUG = 1 und .equ PRINT_PC = 1 setzen und
schauen wo der Prozessor hin springt und welchen Befehl er ausführt.
Es gibt ja prinzipiell zwei Fehlermöglichkeiten.
1. SD-Card wird nicht richtig gelesen
2. RAM verliert Speicherinhalte
Beides führt natürlich auf eine unsinnige Befehlsausführung.
Guten Abend,
ich würde für die neue Version noch einige Bauelemente bestellen. Wer
Interesse hat, hängt sich einfach mit ran.
ATmega328 TQFP32
P8X32A-Q44 (Propeller)
PCF8583T SO08
PCF8574T SO16W
AT24C256 DIL
20 MHz Quarz
5 MHz Quarz (Propeller)
32 KHz Quarz (RTC)
SD Slot SCDA6A0101
Joe
@Peter, ich weiß nicht, ob Du noch mit disk images experimentierst, oder
ob Du es mit oder ohne Erfolg aufgegeben hat. Ein paar Sachen sind mir
noch aufgefallen.
Peter Sieg schrieb:> Habe nun mit folgenden Änderungen:>> ; Fields in the parttabl>> .equ MAXDISKS = 10 ;Max number of Disks (partitions); was 8> .equ PARTENTRY_SIZE = 11 ;Size of a Partitiontableentry; was 9
Der 2. Wert sollte natürlich nicht geändert werden, da sich ja die Größe
eines einzelnen Tabelleneintrags ja nicht ändert. Vergrößern verbraucht
allerdings nur unnötig mehr RAM, während Verkleinern sicher tötlich ist.
Peter Sieg schrieb:>> Die Nummer der RAM-Disk steht auch in config.inc:>> #define RAMDISKNR 'I'-'A' /* Drive "letter" for first RAM disk */> Das hatte ich parallel auch schon gemacht, obwohl die Anz. Ramdisks bei> mir auf 0 steht.
RAMDISKNR-1 ist gleichzeitig auch das letzte erlaubte SD-Kartenlaufwerk.
Deshalb muß man diese Konstante auch dann richtig setzen, wenn man keine
RAM-Disks verwendet.
Man könnte die Anzahl der Disks vielleicht etwas übersichtlicher in
'config.inc' konfigurierbar machen. Da aber ggf. auch das BIOS angepasst
werden muß, weiß ich nicht, ob sich der Aufwand lohnt.
Peter Sieg schrieb:> Tja.. es sind immer die dummen Fehler..> So rum gehts:> mkfs.cpm.exe -f simhd -b cpm.bin -L test simhd.img> makeimage simhd.img simhd.img 8388608
Wenn man ein nagelneues Image erzeugt, müßte die Reihenfolge definitiv
egal sein. Sollte das bei Dir tatsächlich anders sein, würde ich Dich
bitten, nochmal je ein Image mit diesen Befehlen in beiden Reihenfolgen
zu erzeugen, jeweils eine Datei darauf zu kopieren, und mit das Ergebnis
zuzuschicken.
@Joe: Teile sind angekommen. Vielen Dank!
Hast du Bestückungsplan, Firmware für Propeller, 24C256 etc. ggf.
Aufbauhinweise; Bilder .. weitere Unterlagen dazu?
Ggf. reichelt Teileliste der restlichen Bauteile..
Gruß, Peter
Die Bestückung ergibt sich aus dem Schaltplan und dem Layout (siehe
Anhang 1). Einen Bestückungsplan habe ich nch nicht erstellt.
Die Firmware für den Propeller (siehe Anhang 2). Hier müssen noch die
Baudrate und Farben für das Terminal eingestellt werden
(propCOMM2_VGA.spin). Ich habe grün auf schwarz sowie 57600 Baud
eingestellt. Möglicherweise sind auch noch die Wartezeiten vom AVR CP/M
etwas zu vergrößern, damit die Initialisierung des VT100 Terminals
abgeschlossen ist, bevor das CP/M bootet.
Die Propellersoftware kann mit dem Propeller Spin-Tool übersetzt und
geladen werden.
http://www.parallax.com/tabid/832/Default.aspx#Software
Die Hardware ist so ausgelegt, dass es drei Kommunikationsmöglichkeiten
über die USB-Schnittstelle gibt.
1. Spinzugriff zum Propeller
2. Terminalzugriff zum AVR CP/M
3. CP/M - Propeller VT100
Die einzelnen Varianten werden über das Juperfeld gesetzt. Ich habe
leider noch kein schönes Bild dafür erstellt.
Danke Joe,
bei mir sind die Teile auch heute Morgen angekommen. Allerdings werde
ich mich frühestens nächste Woche damit beschäftigen können.
Nach Diktat verreist...
Hier ein Bild TOP Layer und Partlist.
Wer meine Teile+Platine haben möchte -> Mail. Ich komme auf absehbare
Zeit nicht dazu und habe ja noch die seriellen Varianten hier.
Peter
Hallo zusammen,
bzgl. dieses interessanten Projekts bin ich quasi ein Späteinsteiger :-)
Es ist auch das erst mal, dass ich hier etwas schreibe - hoffentlich
mache ich alles richtig.
Ich wollte mich Schritt für Schritt dem Thema nähern und habe daher erst
einmal die einfache "Lochraster-Variante" (Mega88, 1x RAM) aufgebaut
[[http://petersieg.kilu.de/avrcpm/avrcpm.html]].
Später wollte ich dann Platinen ätzen (oder bei einer Sammelbestellung
dranhängen), VGA-Adapter usw... realisieren.
Als Software (sowohl AVR-Code als auch Disk-Images) habe ich
verschiedene Entwicklungs-Stufen ausprobiert (unter WinAVR).
Zuletzt die Dateien von Peter Siegs "AVR_CPM_UDP2".
[[http://avr.cwsurf.de/?download=avrcpm_upd2.zip]]. Peter (DANKE!) hatte
mir schon mal das ein oder andere Disk-Image gegeben - aber so richtig
bin ich noch nicht weiter gekommen.
Es klappt noch nicht und ich weiß nicht, wo ich suchen muss? Ram?
Takt...?
Mein Aufbau:
- ATmega88-20
- RAM: sowohl KM44C256AP-8 als auch Siemens HYB514256A-70 (West Germany
:-))
- SD-Card: 1GB Platinum (Reichelt)
Beim Start kommt ohne Debug-Flags:
1
CPM on an AVR, v1.0
2
Initing mmc...
3
CP/M partition at: 062, size: 7657KB.
4
CP/M partition at: 15376, size: 7688KB.
5
CP/M partition at: 30752, size: 7688KB.
6
7
Ok, CPU is live!
Danach nix mehr - Stoppt. Als ob er nicht bootet...
MMC und RAM-Test geben folgende Ausgaben - nur was bedeutet das? Ist das
"gut" oder "schlecht" ?
1
CPM on an AVR, v1.0
2
Testing RAM: fill...wait...reread...
3
... (hier laufen dann Hex-Zahlen "00<xx@yyyy" mit yyyy bis FFFF durch)
4
Initing mmc...
5
MMC: <--0A, -->FF.
6
MMC: <--09, -->
7
...
8
MMC: <--FF, -->23.
9
MMC: <--FF, -->FF.
10
11
Ok, CPU is live!
Danach nichts mehr.
Und PC-Debug und INS-Debug:
... Endlose PC=xxxx hochzählend:
1
PC=2822PC=2822, opcode=00, decoded=0000.
2
PC=2823PC=2823, opcode=00, decoded=0000.
3
PC=2824PC=2824, opcode=00, decoded=0000.
4
PC=2825PC=2825, opcode=00, decoded=0000.
5
PC=2826PC=2826, opcode=00, decoded=0000.
6
PC=2827PC=2827, opcode=00, decoded=0000.
Hat jemand einen Tipp, wo das Problem liegen könnte?
Herzlichen Dank und Gruß
Marcel
Marcel Andre schrieb:> Testing RAM: fill...wait...reread...> ... (hier laufen dann Hex-Zahlen "00<xx@yyyy" mit yyyy bis FFFF durch)
Der Test schreibt verschiedene Werte (xx) ins RAM, aber es wird
offensichtlich von allen Adressen (yyyy) immer 00 zurück gelesen.
Bevor der RAM-Fehler nicht behoben ist, lohnt es sich nicht, über andere
Fehler überhaupt nachzudenken. Daß beide RAM-Bausteine kaputt sind, oder
mit 3,3V nicht funktionieren, glaube ich mal eher nicht.
--> Verdrahtung überprüfen.
Die Software-Revision von z80.asm habe ich im SVN gefunden. Die sollte
also funktionieren, wenn sie richtig konfiguriert ist. CPU und
Taktfrequenz scheinen richtig eingestellt zu sein, da sonst die Serielle
nicht laufen würde. Und sonst gibts der Version eigentlich nichts
einzustellen.
Danke Leo für die Rückmeldung !
Verdrahtung habe ich (mehrfach, auch mit Messgerät) überprüft. Da ist
alles nach dem Grundplan (den auf Sprite...) richtig
[http://spritesmods.com/?art=avrcpm&page=2].
Es gab da ja mal eine Änderung..., aber die ist da ja schon
berücksichtigt?
Bei mir ist PC1 - WE und PC4 - DO2/IO3
Marcel Andre schrieb:> Bei mir ist PC1 - WE und PC4 - DO2/IO3
Umdrehen!
siehe z80.asm:
1
;Port C
2
.equ ram_d0 = 0
3
.equ ram_d1 = 1
4
.equ ram_d2 = 2
5
.equ ram_d3 = 3
6
.equ ram_w = 4
7
.equ ram_cas= 5
Die Leitungen haben wir vertauscht, damit die 4 Datenleitungen zusammen
auf einem Nibble liegen. PC0..PC3 kann man natürlich beliebig
untereinander tauschen.
>> Die Leitungen haben wir vertauscht, damit die 4 Datenleitungen zusammen> auf einem Nibble liegen. PC0..PC3 kann man natürlich beliebig> untereinander tauschen.
Genau das war es: Gegenüber der original-Beschaltung (Image und
Eagle-Datei) mussten 3 Leitungen anders belegt werden.
Super herzlichen Dank!
Ich sage Peter noch Bescheid, ggf. die Doku zu ändern, damit andere
"Späteinsteiger" nicht in die gleiche Falle tappen.
Gruß
Marcel
hmm. Auf meiner Seite steht das schon genauso, wenn sich das mal
chronologisch durchliest.
Ach, sehe gerade, das ist die Ur-Altseite..
Besser diese hier:
http://petersieg.bplaced.net/
Dort steht:
Update
Hier der aktuelle Entwicklungstand der Software: avrcpm_upd.zip
* Warmstart (behoben im Bios; in den 2 diskimages enthalten)
* 8080 Opcodes fehlerbereinigt (MBASIC laeuft jetzt!)
* Unterstuetzung fuer ATmega8, 88, 168
* 2 Diskimages mit neuem Bios enthalten
Achtung: 2 Leitungen sind zu tauschen (Beschleunigung DRAM Zugriffe):
Pin 24 - PC1 - /WE
Pin 27 - PC4 - IO3
---
@Leo C: Zitat:
Marcel Andre schrieb:
> [[http://petersieg.kilu.de/avrcpm/avrcpm.html]].
Ehre wem Ehre gebührt. Und das ist in diesem Fall "Sprite_tm":
http://spritesmods.com/?art=avrcpm&page=2
=> Die Ehre von sprite_tm als Entwickler der Ursprungs-Version war hier
nie in Gefahr! Sowas hatte Marcel doch gar nicht geschrieben..
Und die "Ehre" für meine Seite(n) und deren Informationen beanspruche
ich schon noch für mich..
;-)
Peter
Eine Frage hätte ich noch, bevor ich mich an die "echte" Z80-Version
mache: Man findet "im Netz" ja jede Menge Software, die angeblich für
CP/M 2.2 und 8080-CPU gemacht wurde (z.B. TurboPascal 1.0).
Dennoch bricht so etwas immer mit falschem Opcode ab.
Ist das so richtig? Verlangt das doch die Z80-Emulation?
Joe G. schrieb:> TurboPascal läuft nur tatsächlich nur unter Intel 8086 oder Z80.
Das kann ja dann nur bedeuten, daß die Z80-Emulation noch nicht gut
genug ist. Da man prinzipiell immer eine 100%-Softwareemulation
hinkriegen (schließlich sind die Dinger allesamt Turing-vollständig),
kann es also allenfalls an der letztlich erzielbaren
Ausführungsgeschwindigkeit klemmen.
Deswegen ist es auch kein bissel spannend, CP/M oder TP auf einem AVR
zum Laufen zu kriegen, denn es steht von vornherein fest, daß es möglich
sein muß. Das einzig spannende ist, wie schnell das Ergebnis laufen
wird. Und das hängt nur davon ab, wie effizient die Emulation der CPU
auf dem Zielsystem ist.
Der Rest ist nicht mehr und nicht weniger als ein Benchmark für die Güte
der eigentlichen Problemlösung, sowohl in Hinsicht auf die Exaktheit als
auch die Effizienz der Emulation.
c-hater schrieb:> Joe G. schrieb:>> TurboPascal läuft nur tatsächlich nur unter Intel 8086 oder Z80.> Das kann ja dann nur bedeuten, daß die Z80-Emulation noch nicht gut> genug ist.
Diesen Kommentar verstehe ich nicht. Für alle Interessenten.
Die Z80 Emulation läuft vollständig, somit auch Turbo Pascal und andere
Programme die nur unter CP/M und Z80 Code laufen.
Peter Sieg schrieb:> => Die Ehre von sprite_tm als Entwickler der Ursprungs-Version war hier> nie in Gefahr! Sowas hatte Marcel doch gar nicht geschrieben..> Und die "Ehre" für meine Seite(n) und deren Informationen beanspruche> ich schon noch für mich..
Peter, ich will Deine Leistung für das Projekt garnicht
kleinreden/schreiben, aber Du verwendest den handgemalten Schaltplan von
sprite_tm ohne Quellenangabe. Überhaupt sehen imho die zahlreichen
Seiten für den uneingeweihten Betrachter so aus, als wäre das alles auf
Deinem Mist gewachsen. Erst wenn man auf die Idee kommt, den
unkommentierten Links zu folgen (auf der petersieg.kilu.de-Seite nicht
anklickbar), weiß man mehr.
Vorschlag: Analog zum hiesigen AVR CP/M-Artikel im ersten Absatz
ein/zwei Sätze zur Herkunft des Projekts einfügen.
Und eine Quellenangabe/Copyright zur Grafik 'avrcpm.png'.
Und wenn dann noch je ein halber Satz erklären würde, wo die 4 Links am
Anfang hinführen, wärs perfekt.
Gestern habe ich endlich mal Joes neue Platine (teil)bestückt und heute
in Betrieb genommen. Der Hauptteil läuft.
Terminal und USB-Schnittstelle habe ich erst mal weggelassen, und der
3,3V-Spannungsregler fehlt mir noch (inzwischen bestellt).
Vorläufig habe ich einen externen USB/Serial-Adapter dran, der auch 3,3V
liefert.
Beim Bestücken ist mir aufgefallen, daß die Pads für den Uhrenchip nicht
passen (zu eng, für das schmalere SO-Gehäuse). Das ist aber kein großes
Problem, da unterhalb des Chips Platz genug ist.
Leo C. schrieb:> Beim Bestücken ist mir aufgefallen, daß die Pads für den Uhrenchip nicht> passen
Oh Mist, da habe ich wohl geträumt! Ich bin leider bis auf die 3.3V und
den USB-Teil noch nicht so weit gekommen. In einigen Tage geht es aber
wieder weiter. Ich würde dann auch mal eine kleine Bauanleitung für die
Hard- und Software erstellen, da es für einen Neueisteiger schon recht
unübersichtlich wird.
@Leo.C. Was macht denn der lustige Draht der zum RTC geht?
Joe G. schrieb:> @Leo.C. Was macht denn der lustige Draht der zum RTC geht?
Der Draht geht, vom CS der SD-Karte kommend, scharf am RTC vorbei an das
abgeknickte Bein der LED. Ich habe die Betriebs-LED privisorisch zur
"Drive-Select"-Anzeige umgewidmet. Ohne diese Anzeige kann ich gar nicht
mehr leben.
Hier mal ein erster Vorschlag für das I2C-Interface
Der Parallel-I/O Chip hat nur je ein Input- und Output- und keinerlei
Steuerregister. Daher bietet es sich an, In und Out direkt auf
Z80-I/O-Befehle zu mappen. Im Moment sieht es so aus:
Da 8 Chips adressierbar sind, habe ich auch 8 Adressen reserviert. Mit
der A-Variante sind insgesamt 16 Ports adressierbar.
Der RTC und weitere, am externen Bus angeschlossene I2C-Chips (und wenn
man will, auch der PCF8574) können über das folgende Interface
angesprochen werden:
;05 in - Status of last Transfer: 0 = ok, else fail
5
;06 in/out - Number of bytes to transfer, including Slave address
6
;07,08 in/out - Read/Write address low/high
Das Z80-Programm füllt einen Puffer mit der Slave-Adresse, und im
Sendefall, mit den zu sendenden Daten. Die Pufferadresse und die Anzahl
zu übertragender Daten, werden über die oben angegebenen Ports an den
Treiber übergeben. Die Länge schließt immer die Slave-Adresse mit ein.
Anschließend wird der Transfer über die Ausgabe auf Port 5 gestartet.
Z.Zt. ist interne Puffer 17 Byte groß. Es können also maximal 16
Datenbytes (z.B. zu oder von einem EEPROM) übertragen werden.
Fehlerbehandlung und -Rückmeldung ist bisher nur rudimentär. Evtl. muß
dort noch nachgearbeitet werden.
Um das Interface und den RTC-Chip zu testen, habe ich ein quick&dirty
Programm mit Turbo-Pascal geschrieben. Eingecheckt ist noch nichts.
Deshalb der Anhang mit (hoffentlich) allen geänderten Dateien.
Deine Idee mit der I2C Interface finde ich gut so. IN/OUT über I/O. Ist
ja fast wie die alte PIO ;-)
Die Variante deines Virtual-I2C-Interface klingt auch schlüssig. So
lassen sich dann auch A/D-Wandler, LCD-Anzeigen etc. anschließen. Ich
werde wohl heute mal einen intensiven Löttag einlegen...
Joe G. schrieb:> werde wohl heute mal einen intensiven Löttag einlegen...
Ich hoffe, Du bist voran gekommen, und kannst den aktuellen
Softwarestand, den ich heute eingecheckt habe, testen.
Die Schnittstelle zur Uhr habe ich nochmal geändert. Deshalb muste der
ZSDOS-Treiber AVRCLOCK.MAC angepaßt werden.
Joe G. schrieb:> Dann ist das ja ein MUSS für das Pflichtenheft der nächsten Version ;-)
Beim Aufbau der Platine sind mir noch ein paar Punkte auf/eingefallen:
PCF8583:
- An Pin 1 (OSCI) muß ein Kondensator angeschossen sein. Das
Datenblatt empfiehlt einen Trimmer 5-25pF. Bei mir tuts
ein 15pF C (Abweichung in 3 Tagen ca. +2s). Ohne läuft die Uhr
nicht richtig an.
--> Pads für C und/oder Trimmer vorsehen.
- Lithiumzelle (hält Jahre) statt Gold-Cap (hält Tage)?
CR2032 ist spottbillig, aber leider etwas groß.
SD-Card:
- C11 scheint mir etwas klein dimensioniert. 4,7µF --> 47µF?
- Keine Pullups
Zu beiden Punkten siehe http://elm-chan.org/docs/mmc/mmc_e.html
(Abschnitt "Cosideration to Bus Floating and Hot Insertion")
FT232RL:
- R21 u. R22 (LED-Widerstände)
Sind 10K nicht etwas groß? (Bei mir noch nicht bestückt)
Vielen Dank für die Hinweise!
Leo C. schrieb:> An Pin 1 (OSCI) muß ein Kondensator angeschossen sein.
Ist aufgenommen, auch die Änderung der Bauform. Mal
sehen welche Lithiumzelle ich unter bekomme.
Leo C. schrieb:> - Keine Pullups
Ist auch aufgenommen.
Generell zu den R und C's:
Die 10K bzw. 10µ oder 4,7µ sind immer durch Copy und Paste an die Stelle
gekommen wie ein R oder ein C bestückt werden sollte. Dabei habe ich den
Bauteilwert nicht angepaßt. Also bei der Bestückung wirklich darauf
auchten welcher Wert sinnvoll ist. Ich ändere es aktuell gerade in den
Schaltungen.
Sever läuft.
Allerdings ging die Namensauflösung seit heute Morgen nicht mehr.
Sollte jetzt wieder gehen. Mein Browser weigert sich aber auch noch.
seltsam. Wenns bei Dir auch noch nicht tut, versuche mal
e179220223.adsl.alicedsl.de als Server.
Danke! Mit der "Ersatzadresse" get es.
Die neue AVR Software läßt sich erstmal fehlerfei übersetzen und CP/M
bootet auch korrekt.
Um den RTC anzusprechen ist sicherlich zunächst die TP-Quelle gedacht.
Wird AVRCLOCK.MAC dann noch benötigt? Ich nehme an, für den RTC hast du
A0 auf GND gelegt (Adr. A0)
Joe G. schrieb:> Die neue AVR Software läßt sich erstmal fehlerfei übersetzen und CP/M> bootet auch korrekt.
Im Moment ist es so, daß die Initialisierung hängen bleibt, wenn am
I2C-Bus keine Pullup-Widerstände sind, also z.B. auf "alter" Hardware.
Das möchte ich demnächst noch ändern.
> Um den RTC anzusprechen ist sicherlich zunächst die TP-Quelle gedacht.
Das TP-Programm war zum Testen der I2C-Schnittstelle und der Uhr
gedacht, und kann noch als Beispiel verwendet werden.
> Wird AVRCLOCK.MAC dann noch benötigt? Ich nehme an, für den RTC hast du> A0 auf GND gelegt (Adr. A0)
Ja, und ja.
In AVRCLOCK.MAC ist der Treiber für ZSDOS. Aus AVRCLOCK.REL wird mit
SETUPZST.COM das CLocktreiber-Ladeprogramm LDTIM.COM gebaut. Für den
schnellen test habe ich mal ein fertiges LDTIM.COM hier angehängt.
Man kann den Treiber auch ins BIOS einbauen. Dazu muß man ZSDOS
entsprechend konfigurieren. Kommt demnächst...
Joe G. schrieb:> Mal sehen welche Lithiumzelle ich unter bekomme.
Der Punkt war mehr als Frage und zur Diskussion gedacht. Vielleicht gibt
es ja noch Gründe für einen Kondensator, die ich übersehen habe. Wie
groß ist denn dein Goldcap?
Ich habe nur welche mit 0.1F hier. Bin zur Zt. am Messen. 2 volle Tage
scheint er nicht ganz zu schaffen. Laut Datenblatt sollte der Strom
unterhalb von gut 2V konstant sein. Das sieht bei mir anders aus.
@Leo C.
Für LDTIM.COM hätte ich ja auch mal das Handbuch lesen können ;-)
Programm läuft jedoch, auch das nun neue ACT.COM
Bei der Uhr habe ich noch Probleme, es kommt recht großer Unsin vom RTC.
Nun muß ich erst mal ein Oszi an die I2C Leitungen hängen.
Joe,
geht denn der I/O-Port?
Einfach zu testen mit ddtz.
"I80" zum Lesen. "O<val> 80" zum Schreiben.
Wenn das geht sehe ich keinen Grund, warum die Uhr nicht auch gehen
sollte.
hast Du einen C (ca. 18pF) von Pin 1 nach Vdd am RTC?
"Dummerweise" wird beim Schreiben der Uhr das 1Hz-Signal am
Interupt-Ausgang (Pin 7) abgeschaltet (In der Routine "rtc_set", durch
Setzen des "alarm enable" bits.
Nach Powerup kann man das Signal aber auf jeden Fall messen (Pullup
notwendig).
Joe G. schrieb:> Programm läuft jedoch, auch das nun neue ACT.COM
Das Programm ist nicht neu. :-)
Joe G. schrieb:> TIMER.COM darf auch ACT.COM heißen. (AVR CP/M Tool) ;-)
Oder AVRCPM Control Tool.
Leo C. schrieb:> Joe G. schrieb:>> TIMER.COM darf auch ACT.COM heißen. (AVR CP/M Tool) ;-)
hatte ich schon vergessen ;-)
Habe den Fehler nun eingegrenzt. Quarz schwingt, C zu Vdd auch nicht
vergessen, 1 Hz kommt, ABER die Option I2C beim Compiler nicht
eingestellt. Wenn ich nun jedoch I2C auf 1 setze, dann kommt das
Programm nichtmal bis zu einer Terminalausgabe. Die zwei PullUp
Widerstande sind jedoch am Bus.
Joe G. schrieb:> Beide Leitungen sind Low
Die Pullups sollten die aber hochziehen.
> In welchem File steckt eigentlich rtc_get?
leo@cb: grep rtc_get: *.asm
timer.asm:rtc_get:
Joe G. schrieb:> Leo C. schrieb:>> Die Pullups sollten die aber hochziehen.>> Der Controller zieht nach der Routine i2c_init die Leitungen auf Low.
Open Drain.
In der allgemeinen Init werden die Ports auf Ausgang und auf High
geschaltet (Sollte vielleicht geändert werden).
In i2c_init werden die aktiven Treiber abgeschaltet, und wenn keine
Pullups vorhanden sind, floaten die Leitungen nach Low.
Bei offenen Leitungen (Pullups fehlen oder falsch verdrahtet) sollte ca
70ms nach steigender Reset-Flanke ein ca 300µs langer High-Impuls
kommen.
Wenn die Leitungen ohne den Impuls dauerhaft auf Low liegen, zieht die
irgendwas runter. Das sollte aber nicht der Processor sein, wenn Du die
gleiche Software hast, wie ich.
@alle: Da ich noch 1-2 Anfragen hatte aber keine Platine mehr, habe ich
nochmals ein kleine Auflage an roten Platinen des AVR CP/M USB Sticks
bestellt.
Wer welche haben möchte (=> Mail!):
* Platine: 12€
* SD Slot: 3€
* ATmega328:4€ (programmiert)
Versand im Polsterumschlag: 2€
Das wird wohl die letzte Auflage werden, weil die SD Slots nur noch
schwer zu bekommen sind.
Peter
Die letzten Tage habe ich mich auch mal mit Bootloadern beschäftigt.
1. Im Artikel AVR CP/M ist ja schon einer beschrieben. Der geht aber
wohl nur mit Hardware-UART und ist für mich sowieso uninteressant, da
zum Laden propietäre Windows-Software gebraucht wird.
2. AVR Bootloader FastBoot von Peter Dannegger
Läuft quasi out-of-the-box. Egmont hat vor einiger Zeit schon was dazu
geschrieben.
Egmont schrieb:> fboot funktioniert bei mir nur bis Win XP.
Allerdings gibts mehrere Alternativen zu fboot, zum Teil mit
Verbesserungen. Das hier läuft bei mir, und läßt sich auch in gängige
Terminalprogramme einbinden:
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"
Im Wiki-Artikel sind aber auch noch andere genannt.
3. MMC/SD Bootloader für AT Mega von Stefan Seegel.
(http://www.mikrocontroller.net/articles/MMC/SD_Bootloader_f%C3%BCr_AT_Mega)
Das ist zur Zeit man Favorit. Man kopiert ein Image mit der neuen
Software auf eine SD-Karte, schiebt sie in den AVRCPM-Computer und
drückt Reset. Nach ca. 3 Sekunden meldet sich die neue Software.
Eine Version des Laders, die mit allen meinen SD-Karten (auch SDHC)
läuft, habe ich vor kurzem in das Forum gestellt:
Beitrag "Re: MMC/SD Bootloader füt ATMega16"
Der Bootloader lädt nur Dateien, die eine passende Kennung und gültige
CRC-Summe haben. Im Anhang ist deshalb mal ein Beispiel, wie man die
Kennung in Makefile und avrcpm.asm integrieren kann.
Wer zufällig ein AVRCPM mit ATmega328(P), 8-Bit-RAM, 115200 Baud hat,
kann auch die fertigen Dateien im Toplevel-Dir des Zips zum Testen
nehmen.
Das Hexfile flashen, Fuses einstellen auf: Boot section size 1024K
Words, Boot reset vector enabled (BOOTRST) (avrdude -U hfuse:w:0xd2:m).
Die Bin-Datei auf Karte kopieren und einstecken. Sollte klappen.
ps:
Peter Sieg schrieb:> Wer welche haben möchte (=> Mail!):> ...> * ATmega328:4€ (programmiert)
Für Kunden, die diesen Service nutzen, müßte der MMC-Bootloader doch
auch ideal sein.
@Leo C.
Der Bootloader scheint bei mir zu laufen. Wenn den AVR lösche wird nach
dem Reset offensichtlich die Datei avrcpm-3.1-test.bin in den Flash
geschrieben denn das CP/M läuft dann wieder. Allerdings bekommt man
keinen Hinweis, dass die Software nachgeladen wurde.
Die Quellen im Trunk-Verzeichnis lassen sich nur ohne die Option I2C=1
übersetzen. Ansonsten kommen Speicherzuordnungsfehler.
Wie muß aus der HEX eine BIN Datei gemacht werden? Die Datei scheint mir
mit FF aufgefüllt und am Ende steht noch ACPM + Prüfsumme?
Joe G. schrieb:> geschrieben denn das CP/M läuft dann wieder. Allerdings bekommt man> keinen Hinweis, dass die Software nachgeladen wurde.
Wie auch.
Der Bootloader kennt von der Hardware nur das allernötigste. LEDs haben
wir keine. Und die Software selbst weiß ja nicht, daß sie gerade erst
geladen wurde.
Normalerweise sollte man wissen, daß man eine Karte mit neuer Software
einsteckt. Bei mit flackert dann lustig die LED am Card-Select-Pin.
Beim Starten sollte man auch an der veränderten Versionsnummer sehen,
daß die Software neu ist. Es sei denn, man hat eine Testversion geladen.
> Die Quellen im Trunk-Verzeichnis lassen sich nur ohne die Option I2C=1> übersetzen. Ansonsten kommen Speicherzuordnungsfehler.
Ups, hatte ich nicht getestet. Mit den angehängten Dateien sollte es
wieder gehen.
> Wie muß aus der HEX eine BIN Datei gemacht werden?
make bin
(Oder im Makefile das bin-Target suchen, und die zwei Anweisungen dort
manuell ausführen, oder ins eingene Build-Dings übernehmen.)
> Die Datei scheint mir mit FF aufgefüllt und am Ende steht noch ACPM + Prüfsumme?
Ja. Und die Versionsnr. (Major,Minor). Normalerweise wird nur geladen,
wenn die auf der Karte gefundene Versionsnr. größer ist, als die
Installierte. Es sei denn, auf der Karte wurde eine Version 0.0
gefunden, die immer gelagen wird (Testversion). Alles im
Bootloader-Thread zu finden:
http://www.mikrocontroller.net/topic/goto_post/3085712
'crcgen' ist im Bootloader-Paket.
'objcopy' ist in den GNU-Binutils, und dürfte damit auf nahezu jedem
unixoiden System vorhanden sein (auch Cygwin und ähnliches). Es muß
nicht unbedingt 'avr-objcopy' sein. Aber das wird üblicherweise mit
avr-gcc mitgeliefert (WinAVR). Es gibt aber auch andere hex2bin Tools.
Auch welche die die Lücken mit 0xff füllen (Wahrscheinlich auch im
Bootloaderthread zu finden). Aber das ist ja schon reiner Luxus.
Besten Dank für die Erklärung.
Stimmt, die aktuelle Versionsnummer sollte es richten ;-)
Mit crcgen und objcopy geht es nun auch. Damit ist ein Softwareupdate
über MMC eine wirklich feine Sache.
Nur mal nebenbei. Ist eigentlich die veränderte serielle Routine
eingearbeitet? Das Flackern im TP Editor ist weg :-)
Joe G. schrieb:> Nur mal nebenbei. Ist eigentlich die veränderte serielle Routine> eingearbeitet? Das Flackern im TP Editor ist weg :-)
Ja. Damit wäre dieser Test wohl auch abgehakt. ;)
Wahrscheinlich habe ich aber auch einen kapitalen Fehler
"eingearbeitet". :-(
TP produziert mit einem einfachen kleinen Programm nur Mist. Vermutlich
ist bei den Z80 Opcodes ein Fehler in den Interpreter gerutscht. Die
gestern geposteten Dateien also bitte nicht für ein Produktionssystem
benutzen. ;-)
ps:
Hier das Programm (von hier
http://blogs.embarcadero.com/davidi/2008/11/06/38988 ):
1
program eightqueens;
2
{
3
Eight Queens problem - recursive edition
4
from Nicklaus Wirth's book:
5
Applications + Data Structures = Programs }{
6
Modified 11/06/2008 by David Intersimone "David I"
7
to work with Turbo Pascal version 1.0:
8
1 - added NumberOfIterations and loop to be able to benchmark
9
on modern circa 2008 PCs
10
2 - added MSDOS calls Int21h with AH=2Ch to get System Time
11
3 - commented out the call to 'print' the solutions to remove
12
screen output from the benchmark time
13
}
14
15
{ type
16
MSDOS_Parameters_Type = record
17
AX,BX,CX,DX,BP,SI,DI,DS,ES,Flags : Integer;
18
end;
19
}
20
21
const
22
{ NumberOfIterations = 12000;} {for benchmarking on modern PCs how many times to solve it}
In der aktuellen Version scheint "rcall" für die Funktion printhex nicht
mehr auszureichen. Mit "call" läuft es.
dsk_fsys.asm
printstring "DISK I/O: Invalid Function code: "
(r)call printhex
rjmp haltinv
Joe G. schrieb:> In der aktuellen Version scheint "rcall" für die Funktion printhex nicht> mehr auszureichen. Mit "call" läuft es.>> dsk_fsys.asm>> printstring "DISK I/O: Invalid Function code: "> (r)call printhex> rjmp haltinv
Das kommt davon, wenn man die Reihenfolge der Module verändert und
unkontrolliert Zwischenstände verteilt.
Bei mir heißt die Stelle:
printstring "DISK I/O: Invalid Function code: "
lcall printhex
rjmp haltinv
Seit gestern sogar schon im svn. lcall/ljmp sind Macros, die wenn
möglich r{call|jmp} einsetzen, und sonst eben ohne r.
Das Turbo-Pascal Problem liegt übrigens nicht am Z80-Interpreter,
sondern daran, daß man für rekursive Programme eine Option setzen, bzw.
abschlten muß: {$A- }
Der jetzige "Zwischenstand" aus dem svn geht :-) Sogar mit I2C=1 ohne
(!) Pullup. Bei der Vielzahl der jetzigen Möglichkeiten braucht es
dringend eine Dokumentation. Ich sehe ja bald selber nicht mehr durch
;-)
Joe G. schrieb:> Der jetzige "Zwischenstand" aus dem svn geht :-) Sogar mit I2C=1 ohne> (!) Pullup.
Das geht ja schon seit Ewigkeiten (17.2.) ;)
Damit könnte man den Treiber eigentlich fest reinnehmen, und den
I2C-Schalter aus der Config rauswerfen. Es sei denn, man will/muß auch
Flash sparen können, für kleinere Megas.
> Bei der Vielzahl der jetzigen Möglichkeiten braucht es dringend> eine Dokumentation. Ich sehe ja bald selber nicht mehr durch ;-)
Du bist nicht allein. ;-)
Die Schalter haben zwar alle mindestens eine Zeile Kommentar in
config.inc, aber die Zusammenhänge lassen sich damit nur mühsam
erschließen. Vielleicht sollte man die Schalter mal alle auflisten, nach
Katerogien sortiert. Mit etwas ausführlicheren Kommentaren, und
Beschreibung der Abhängigkeiten. Die Liste könnte man in config.inc oben
einfügen, in eine extra Datei, und/oder auf die Projektseite setzen.
Viele Schalter kann man auch im Makefile setzen. Wahrscheinlich sorgt
das für weitere Verwirrung. Es hat aber den Vorteil, daß man schnell mal
für einen Test mit anderen Optionen übersetzen kann, ohne die Sourcen zu
ändern. Makefile-Schalter kann man z.B. auch auf der Befehlszeile
setzen:
1
$ make DEVID_S="" MCU=atmega168
wenn man wissen will, ob das Programm ohne Bootloader in den ATmega168
passt. (Passt (noch) nicht, und EM_Z80 kann man im Makefile nicht
abschalten.) ;-) Oder:
1
$ make clean bin BAUD=9600
wenn man für Testzwecke mal schnell eine andere Baudrate braucht.
Vorschlag. Wir könnten doch zunächst alle Schalter auf eine „optimale“
Defaulteinstellung setzen, so wie es zum Teil schon realisiert ist. Wer
eine wirklich eigene Variante haben möchte, kommt sowieso nicht um eine
intensive Beschäftigung mit der Materie drum rum.
Defaultvorschlag:
DRAM-8BIT
F_CPU 20000000
BAUD 115200
I2C=1
EM_Z80=1
DBOOTLDRSIZE=2048
Joe G. schrieb:> Vorschlag. Wir könnten doch zunächst alle Schalter auf eine „optimale“> Defaulteinstellung setzen, so wie es zum Teil schon realisiert ist. Wer
Sowas ähnliches habe ich jetzt mal gemacht (Anhang). Als Default-MCU
habe ich jetzt mega328P eingestellt. Den will ja sowiso jeder haben,
weil nur damit Z80 geht. Die Kommentare sind aber noch ausbaufähig.
> eine wirklich eigene Variante haben möchte, kommt sowieso nicht um eine> intensive Beschäftigung mit der Materie drum rum.
Ja, wobei die bisherige Config aber auch schon zu (vermeidbaren)
Mißverständnissen geführt hat. (Z.B. [1])
> Defaultvorschlag:>> DRAM-8BIT> F_CPU 20000000> BAUD 115200> I2C=1> EM_Z80=1> DBOOTLDRSIZE=2048
Da die Bootladerunterstützung ja für den speziellen MMC/SD Bootloader
ist, andere Bootloader brauchen ja keine Unterstüzung, ist die Größe
auch fest. Deshalb habe ich sie mit anderen Parametern als (notfalls
änderbare) Konstanten weiter nach unten verbannt. Dafür gibt es jetzt
einen Schalter
> MMCBOOTLOADER
der defaultmäßig eingeschaltet ist, weil das ja auch nicht stört.
Bevor ich die geänderte Config einchecke, bitte ich alle Mitleser sich
daß mal anzuschauen, und ggf. Verbesserungsvorschläge zu machen. Mit den
vorhergehenden Änderungen (RTC, I2C, MMC Bootloader Support) soll das
Ganze demnächst Version 3.1 werden.
[1] Beitrag "Re: CP/M auf ATmega88"
Bei mir läuft die aktuelle Version auf beiden Hardwareversionen (mit
I2C/ohne I2C).
Die Voreinstellungen sind prima so, damit sollte der Einsteiger zunächst
sein System übersetzt bekommen.
CPM on an AVR, v3.1 r201 Test
Testing RAM: fill...wait...reread...
Initing mmc...
A:FAT16 File-Image at: 8479, size: 256KB.
B:FAT16 File-Image at: 8959, size: 256KB.
C:FAT16 File-Image at: 8703, size: 256KB.
D:FAT16 File-Image at: 9087, size: 8192KB.
Partinit done.
Ok, Z80-CPU is live!
A>
Eine Frage bleibt trotzdem.
Testversion=1 gesetzt und die Datei avrcpm-3.1.bin erzeugt. Es steht
auch die Version 0.0 in der BIN-Datei. Nach 3 Sekunden Reset wird diese
Version geladen (CPM on an AVR, v3.1 r201 Test) Bei einem kurzem Reset
wird die Version (CPM on an AVR, v3.1 r199) von der Datei
avrcpm-3.1-test.old geladen. Nach welchem Kriterium sucht der Bootloader
nach einer gültigen Datei? Welche Namenskonventionen gelten für diese
Datei?
Der Dateiname ist egal. Es wird nur nach dem Tag in der Datei geschaut:
ID, Version und CRC. Wenn mehrere. Versionen auf der Kartesind, sollte
die mit der höchsten Nummer geladen werden, falls sie das nicht schon
ist. Eine 0.0 Version sollte immer geladen werden, außer, wenn genau
diese schon im Speicher ist (CRC) . Wenn jetzt eine "normale" und eine
0.0 Version auf der Karte sind, könnte es sein, dass zwischen den beiden
getoggelt wird. Unschön, aber wie gehts besser? Der Anwender sollte ja
auch ungefähr wissen, was er will, und (nur) die passende Datei auf die
Karte kopieren.
Ok, toggeln muß ja auch nicht sein. Im Normalfall ist ja immer nur die
aktuelle Version auf der Karte.
Die VGA-Baugruppe ist nun komplett bestückt und in Betrieb genommen
(siehe Bilder). An der Software ist jedoch noch etwas zu tun. Anbei die
erste Version (0.1). Sie könnte auch ins SVN aufgenommen werden. Mit
einer Baudrate von 9600 laufen beide Systeme gut zusammen, bei einer
höheren Baudrate kommt es zu Fehlern, obwohl es im Terminalmodus geht.
Möglicherweise ein Pufferüberlauf. Die Tastatur geht derzeit nur mit dem
US Layout und außerdem gehen einige ESC Sequenzen noch nicht.
Hier ein ordentlicher Arbeiststand, mit dem man nun auch wirklich
arbeiten kann.
- deutsches Tastaturlayout
- deutscher Zeichensatz
P.S: Hat jemand die CP/M Version mit Tastatur und VGA schon aufgebaut?
Hallo Joe,
Danke für Deine VT100-Software.
Joe G. schrieb:> P.S: Hat jemand die CP/M Version mit Tastatur und VGA schon aufgebaut?
Meine Platine ist immer noch nicht komplett bestückt. Terminal und USB
hatte ich ja erst mal weggelassen. Nachdem ich vorhin die Drähte für den
externen USB-Seriell-Adapter weggelötet hatte, habe gemerkt, daß ich gar
keinen FTDI habe. Mir war völlig entgangen, daß der auch nicht in Deinem
Lieferservice mit drin war. Mal schauen, ob ich die Software auch ohne
FTDI-Chip in den Propeller bekomme.
Inzwischen habe ich den Bootloader nochmal getestet. Bei mir toggelt er
nicht zwischen 2 Programmversionen, aber 3 Punkte sind trotzdem unschön:
- Wenn außer der 0.0 Version noch eine andere auf der Karte ist, wird
bei jedem Reset die Software (0.0) neu geladen.
- Die Suche nach einer neuen Version dauert unötig lange, weil für jeden
Dir-Eintrag der ganze Dir-Sektor gelesen wird. D.h. jeder Sektor des
Root-Directories wird 16 mal gelesen. Bei einem Gerät, bei dem im
Normalbetrieb häufig Reset gedrückt wird, ist das schon ziemlich
lästig.
- Wenn ich die Karte im PC neu beschreibe, und dann in den AVRCPM-
Computer stecke, wird der erste Reset vom Bootloader ignoriert.
(Wahrscheinich Init-Fehler). Erst beim 2. Reset wird die Software
geladen.
Da die AVRCPM-Software unabhängig vom MMC/SD-Bootloader ist, und zu
dieser keine weiteren "Beschwerden" mehr kamen, habe ich den letzten
Stand heute ins SVN eingecheckt. Wenn weiterhin keine Änderungs- oder
Verbesserungsvorschläge kommen, werde ich daraus demnächst eine Version
3.1 machen.
Den Fehler des ersten Reset habe ich wohl als toggeln interpretiert.
Den Propeller kannst du auch seriell programmieren. Es ist neben Rx und
Tx nur noch ein Reset über DTR notwendig.
Bei der VT100 Software ist noch ein Bug bei R-Alt+Sonderzeichen,
außerdem müssen noch die Umlaute Ö,Ü,Ä im Zeichengenerator erstellt
werden. Demnächst kommt eine neue Version.
Joe G. schrieb:> Den Propeller kannst du auch seriell programmieren. Es ist neben Rx und> Tx nur noch ein Reset über DTR notwendig.
Das hatte ich befürchtet, daß DTR nicht optional ist. Heute Mittag habe
ich mir einige FT232 besorgt und gleich einen eingelötet. Der CP/M-Teil
läuft damit. Heute Abend kommt dann endlich der Propeller dran. Damit
habe ich bisher noch gar nichts gemacht.
Die Software gibt es jetzt hier als Version 3.1:
http://cloudbase.homelinux.net/viewvc/avr-cpm/avrcpm/tags/3.1/
Neuigkeiten seit 3.0:
- Unterstützung der neuesten Platine von Joe G.
- I2C
- Parallel Port I/O: PCF8574 (PCF8574A)
- RTC PCF8583
- ZSDOS clock driver
- Verbesserter Software-UART
- MMC/SD Bootloader support
- Konfiguration aufgeräumt
- Die üblichen kleinen Bug fixes und Verbesserungen
Also, außer I2C vielleicht, nur Kleinigkeiten. Hauptgrund für die
Version ist, daß ich den aktuellen Stand einfrieren möchte, weil ich
schon wieder eine Menge Änderungen angefangen habe. Schwerpunkt dabei:
Geschwindigkeitssteigerung, je nach Benchmark z.Zt. 10% - 20%, bei
gleichzeitiger Einsparung von Flash. Ziel: Programm soll ohne Funktions-
und Leistungseinbuße in den ATmega168 passen.
Jetzt wäre eigentlich ein guter Zeitpunkt um (Software-) Wünsche zu
äußern. Gerne auch ausgefallene oder anspruchsvolle Ideen. (außer
statisches RAM natürlich) ;-) Schließlich ist rund die Hälfe des
Flash-ROMs noch frei. Da ich nicht der Osterhase bin, kann ich die
Umsetzung natürlich nicht garantieren. Schon garnicht zum Fest.
Hier der aktuelle Stand für den Propeller. Wer noch keine Erfahrung
damit hat, der startet einfach das Hauptprogramm (propCOMM2_VGA.spin)
über F10 (läuft dann im RAM) oder F11 (wird in den EEPROM geladen).
Leo C. schrieb:> Jetzt wäre eigentlich ein guter Zeitpunkt um (Software-) Wünsche zu> äußern. Gerne auch ausgefallene oder anspruchsvolle Ideen. (außer> statisches RAM natürlich) ;-)
Osterwunsch :) Nutzung der beiden AD-Wandler (ADC6 und ADC7) Sie könnten
z.B. als 8 Bit Wandler laufen und über einen IN Befehl von einer festen
Adresse geladen werden.
Über den statischen RAM habe ich tatsächlich schon nachgedacht, doch
keine Sorge, nur bei unveränderter Pinbelegung. Mittels eines Latch und
RAS/CAS könnte man weiterhin wie gehabt adressieren, jedoch die
Refershzyklen einsparen. Damit sollte auch die Z80 Emulation schneller
laufen.
Joe G. schrieb:> Osterwunsch :)
2014 :)
> Nutzung der beiden AD-Wandler (ADC6 und ADC7) Sie könnten> z.B. als 8 Bit Wandler laufen und über einen IN Befehl von einer festen> Adresse geladen werden.
Sollten da nicht ein paar Parameter einstellbar sein? Vref, Betriebsart,
Sample rate?
> Über den statischen RAM habe ich tatsächlich schon nachgedacht, doch> keine Sorge, nur bei unveränderter Pinbelegung. Mittels eines Latch und> RAS/CAS könnte man weiterhin wie gehabt adressieren, jedoch die> Refershzyklen einsparen. Damit sollte auch die Z80 Emulation schneller> laufen.
Der Refresh dauert incl. IntAck max. 24 Takte und kommt bei 20Mhz alle
624 Takte. --> 3,85%
Leo C. schrieb:> Sollten da nicht ein paar Parameter einstellbar sein? Vref, Betriebsart,> Sample rate?
Gerne. Gerne auch 10 Bit. Nun wird jedoch wieder ein Protokoll nötig.
Mein Propeller will nicht abheben. :-(
Ich verwende die Linux Software bst (Brad's Spin Tool). Gestern Abend
habe ich aber auch mal die Windows Software (Spin Tool Software v1.3.2)
versucht. Die schenken sich nichts.
Für mich siehts so aus, daß der Propeller einfach nichts senden will.
Heute Morgen habe ich probeweise das EEPROM ausgelötet (Sockel hätte
wohl doch Vorteile gehabt) und den BOE-Pin auf VDD geklemmt. Ändert
alles nichts.
- FT232 funktioniert mit dem CP/M-Teil einwandfrei.
- Die Leiterbahnen vom Jumperfeld zum Propeller habe ich
durchgeklingelt. Verbindungen da, wo sie sein sollen. Keine
Kurzschlüsse.
- Resetpuls ca. (25µs) kommt am Propeller an. Die steigende Flanke sieht
merkwürdig aus, aber der Propeller scheint den Reset zu fressen.
- ca. 80ms später kommen Daten am RX-Pin des Propellers an.
- Am TX-Pin tut sich nichts. Wenn ich den Jumper ziehe, baumelt er um
0 Volt herum. Ein 100K Widerstand reicht, um ihn hoch zu ziehen, und
bei gestecktem Jumper zieht der FT232 ihn hoch.
- ca. 320ms nach Reset ist Aktivität auf dem I2C-Bus zum EEPROM. Also
hat der Propeller die Daten vom Host nicht erkannt, und versucht nun
sein Programm aus dem EEPROM zu laden.
Keine Ahnung, was ich noch versuchen könnte, außer Propeller tauschen.
:-(
Thread beobachten
Seitenaufteilung abschalten