Ich glaube es gibt hier einen Spezialisten, der mit an dem Projekt arbeitet. Ich pappe das Verzeichnis mal an als zip. Es geht um das beispiel ANSIest.c wo ich eine Warnung erhalte. Die crt.s Dazei sieht soweit gut aus, sie bildet ja den Startup Code, habe vor 10 Jahren mal selbst eine geschrieben aber ist nicht mehr so präsent.
Kompiliert wird mit sdc <filename>, da sollte crt.s mit eingebunden werden.
Die beiden crt.s habe ich mit
sdasz80 -plosgff -o S190818-R011023_crt0.s und
sdasz80 -o S190818_crt0.s
kompiliert, in crt0.rel umbenannt und damit die im SDCC Verzeichnis überschrieben.
Glaube Philipp heisst der Programmierer aber auch ein gewisser Leo kennt sih damit aus? Kannst Du mal drüber schauen? Die Warnungen scheinen merkwürdig zu sein, denn der Code ist nach der ersten Durchsicht ok.
gruss,
Throsten
E:\Embedded\Z80_MBC2\Backup_SD\SDCC>sdc ANSItest.c
ANSItest.c:3: warning 283: function declarator with no prototype
No compiler errors.
Error: utility srec_cat.exe not found!
Nothing to load to the target.
E:\Embedded\Z80_MBC2\Backup_SD\SDCC>sdc Blink_MBC2.c
Blink_MBC2.c:127: warning 283: function declarator with no prototype
Blink_MBC2.c:134: warning 283: function declarator with no prototype
No compiler errors.
Error: utility srec_cat.exe not found!
Nothing to load to the target.
srec_cat.exe ist das Hex2Bin Tool von keil. Ist jetzt drin
E:\Embedded\Z80_MBC2\SDCC>sdc ANSItest.c
ANSItest.c:3: warning 283: function declarator with no prototype
No compiler errors.
All done! Output executable file (Intel-Hex): out.hex
Ok, Warnungen sind weg. Komisch.. früher ging auch while(1); jetzt musst es while(1){}; heissen.
Hier hinter scheinen sich die I/O Ports des MBC2 System zu verbergen. Leider bin ich etwas aus der Materie raus. Der MBC2 benutzt den Atmega als Interface für eine UART, ebenso für einen MC27... als I2C GPIO Port. Leider gibt es keine Doku wie man diese Peripherie ansteuert.
// Z80-MBC2 IOS I/O ports definitions
__sfr __at 0x00 Exec_port; // IOS Execute Opcode read/write port
__sfr __at 0x01 StorOpc_port; // IOS Store Opcode write only port
__sfr __at 0x01 SerRx_port; // IOS Serial Rx read only port
Dahinter steckten 4 Register des 8255 am I/O Bus des Z80, die mit speziellen Werten gefüttert werden mussten, d.h. Command Register und Datenregister. Für den MBC2 gibt es leider gar nichts was dahinter steckt. Glaube maximal 256 I/O Adressen sind da möglich. Die Adressierung lief über die unteren Adressleistungen A0-A7.
Hier hinter scheinen sich die I/O Ports des MBC2 System zu verbergen.
Leider bin ich etwas aus der Materie raus. Der MBC2 benutzt den Atmega
als Interface für eine UART, ebenso für einen MC27... als I2C GPIO Port.
Leider gibt es keine Doku wie man diese Peripherie ansteuert.
Du hast dieses "Bios". Wenn Du das aktuelle (auch letzte) "Bios" benutzt (S220718-R290823_IOS-Z80-MBC2.ino), findest Du ab line 892 die Definition der IO-Operationen, die vom ATMEGA ausgefuehrt werden. Ab line 974 findest Du den Zugriff auf den MCP27016:
1
Wire.beginTransmission(GPIOEXP_ADDR);
2
Wire.write(GPIOA_REG);// Select GPIOA
3
Wire.write(ioData);// Write value
4
Wire.endTransmission();
Der Hinweis auf das Datenblatt des MCP27016 darf natuerlich nicht fehlen. Ich kann mich (als Schueler) der Kampf mit dem Datenblatt des 6532 oder 6522 (heute sind das triviale Bausteine) gut erinnern.
Ich denke diese Tabelle gibt da mehr Aufschluss drüber. Zumindest genug um erstmal eine LED blinken zu lassen. Die scheinen das alles über diese 2 Ports laufen zu lassen und je nachdem welcher Wert reingeschrieben wird bedient der Atmel die passenden Routinen in seiner Firmware. Der hänggt ja auch nur an A0 vom Bus dran, mehr geht ja nicht. Ich frage mich wie der das RAM mit den Images bespielt, denn am Adressbus hängt er nicht dran, nur am Datenbus.
__sfr __at 0x00 EXEC_OPCODE; // IOS Execute Opcode read/write port
__sfr __at 0x01 STORE_OPCODE; // IOS Store Opcode write only port
__sfr __at 0x01 SER_RX; // IOS Serial Rx read only port
Danach will ich mcurses als Interface zum VT100 aufsetzen und mit dem SDCC eigene Programme schreiben.
Ich denke diese Tabelle gibt da mehr Aufschluss drüber. Zumindest genug
um erstmal eine LED blinken zu lassen. Die scheinen das alles über diese
2 Ports laufen zu lassen und je nachdem welcher Wert reingeschrieben
wird bedient der Atmel die passenden Routinen in seiner Firmware.
Im Endeffekt: Ja. Und wenn Du ein wenig bei CP/M 2.2 guckst, wirst Du sehen dass viele CP/M-BIOS-Funktionen direkt implementiert sind.
Der
hänggt ja auch nur an A0 vom Bus dran, mehr geht ja nicht. Ich frage
mich wie der das RAM mit den Images bespielt, denn am Adressbus hängt er
nicht dran, nur am Datenbus.
Das ist sehr pfiffig geloest: Da der ATMega die Clock und Reset kontrolliert, kann man die Z80 in einzelnen Clocks betreiben (klappt eigentlich nur bei der CMOS-CPU). Nach dem Reset werden die passenden OPCodes auf den Bus geschrieben, die CPU fuehrt das aus und kann in das reale RAM einschreiben. Wenn Du den Boot-Loader dann in den RAM geschrieben hast, kannst Du neu starten und das Betriebssystem Deiner Wahl starten.
Das findet alles bei den Routinen loadByteToRAM(byte value) und loadHL(word value) statt (line 2506ff in S220718-R290823_IOS.MBC2.ino):
1
voidloadByteToRAM(bytevalue)
2
// Load a given byte to RAM using a sequence of two Z80 instructions forced on the data bus.
3
// The RAM_CE2 signal is used to force the RAM in HiZ, so the Atmega can write the needed instruction/data
4
// on the data bus. Controlling the clock signal and knowing exactly how many clocks pulse are required it is possible control the
5
// whole loading process.
6
// In the following "T" are the T-cycles of the Z80 (See the Z80 datashet).
7
// The two instruction are "LD (HL), n" and "INC (HL)".
Zu Deinem Wunsch die blaue/weisse/pinke LED blinken zu lassen: Gucke bitte in "Examples with Basic.txt" auf der SD-Card: Du willst ein reines (ohne Betriebssystem) Z80-Programm ausfuehren. Es muesste dann reichen (Pseudo-Code):
Im Endeffekt: Ja. Und wenn Du ein wenig bei CP/M 2.2 guckst, wirst Du
sehen dass viele CP/M-BIOS-Funktionen direkt implementiert sind.
Ich hatte damals sowas gemacht. Ginge das auch für die BIOS Routinen, dass man die aus C zugänglich macht mit den entsprechenden Parametern wenn man ihre Adresse kennt? Ich brauche ja eine API zum BIOS.
PS: Bin ich froh, dass diese EPROM Brennerei ein Ende hat! Habe noch rund 100 hier.
// Absolute Adressen des gesamten RAMs (ohne Stack) und ROMs
// Diese Array sind Overlays und benötigen keinen Speicherplatz
Ich verstehe nicht Dein Goal nicht: Willst Du ein CP/M-Programm schreiben (dann hast Du natuerlich alle Moeglichkeiten, dazu musst Du aber das BIOS haben), dann kannst Du die BIOS-Calls wie folgt benutzen (aus: http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch5.htm)
1
As mentioned above, access to the FDOS functions is accomplished by passing a function number and information address through the primary point at location BOOT+0005H. In general, the function number is passed in register C with the information address in the double byte pair DE. Single byte values are returned in register A, with double byte values returned in HL, a zero value is returned when the function number is out of range. For reasons of compatibility, register A = L and register B = H upon return in all cases.
Aber gerade die Unabhaengigkeit von den festen Adressen war ja genau der grosse Fortschritt bei CP/M (und die Modularitaet der Teile des Betriebssystemes).
Alternativ wirklich ohne alles: Kleines Z80-Assembler, Start bei 0x0000 (Reset0) und gut ist. Beides ist Moeglich.
Ich verstehe nicht Dein Goal nicht: Willst Du ein CP/M-Programm
schreiben (dann hast Du natuerlich alle Moeglichkeiten, dazu musst Du
aber das BIOS haben), dann kannst Du die BIOS-Calls wie folgt benutzen
The principal entry point to the FDOS is at location BOOT+0005H (normally 0005H) where a jump to BASE is found. As mentioned above, access to the FDOS functions is accomplished by passing a function number and information address through the primary point at location BOOT+0005H
Danke, das reicht schon. Ich habe in den 90iger Asm Programme für den X86 geschrieben da musste man den INT21h beedienen für DOS und einen anderen fürs BIOS. Stand alles im PC Intern.
Ich brauche nur das VT100 Interface, den ganzen Low Level Disk Kram tue ich mir nicht an. Und ich muss mir ein C Konstrukt basteln, was die Funktionen anspringt, da ich auf Assembler verzichten will. Also eine C Funktion, die vielleicht etwas Inline Assembler hat die das managed.
Habe zwar eine C Lib mcurses, die VT100 bedienen kann aber die müsste mein Programm dann mitschleppen, dabei gibt es das ja alles schon im BDOS.
Alternativ geht natürlich auch mbasic von Grant Serle, das sich auch kompilieren lässt zu einem COM File.ö Zusammen mit dem autostart Mechanismus kann man so ein Programm starten und zb die GPIO Leiste bedienen, das ist alls schon drin mit dem OUT und IN Befehlen. Allerdings ist die Editor Funktion nicht komfortabel, das würde ich alles schon gern am PC machen und dann hochladen als Text oder als Kompilat. Copy & Paste klappen aber im Terminalfenster, d.h. mans spart sich das mühsame Eintippen.
Habe zwar eine C Lib mcurses, die VT100 bedienen kann aber die müsste
mein Programm dann mitschleppen, dabei gibt es das ja alles schon im
BDOS.
Noe. BDOS steht fuer Basic DISK Operating System, ja, es hat auch Character I/O, RAW I/O und buffered Read and Write (praktisch ein PrintString), aber curses bietet deutlich mehr. Insbesondere Cursor-Control ist Deine Aufgabe.
Es sind ja jetzt vierzig Jahre her, es kann sein, dass sich Deine Erinnerungen etwas vermischen? Kannst Du Dich noch an die ellenlangen Listen von Terminal-Codes wg. Cursor-Up, -Down oder Erase Line erinnern?
Oder das Elend mit den Floppy-Disk-Formaten? Jeder hatte seine eigene Wurst?
Es sind ja jetzt vierzig Jahre her, es kann sein, dass sich Deine
Erinnerungen etwas vermischen? Kannst Du Dich noch an die ellenlangen
Listen von Terminal-Codes wg. Cursor-Up, -Down oder Erase Line erinnern?
In der mcurses von Frank (UKW) ist man davon entbunden, die Routinen bauen die ESC Sequenzen einfach ein. Es geht ja nur um Textfelder, Cursor zurück, poitionierend usw.
sdasz80 -plosgff -o S190818-R011023_crt0.s und
sdasz80 -o S190818_crt0.s
kompiliert, in crt0.rel umbenannt und damit die im SDCC Verzeichnis
überschrieben.
Das übliche vorgehen ist, die crt0.rel von SDCC zu lassen, wie sie ist, die eigene "crt0.rel" (muss nicht notwendigerweise so heißen) beim Linkeraufruf als erste .rel anzugeben, und --no-std-crt0 zu verwenden, also z.B.:
