Hans- w. Schütz schrieb:> 01<38@0139M: fill...wait...reread...F0<00@0000> nach einem Reset:> CPM on an AVR, v1.0> Fô<83@0083M: fill...wait...reread...F0<00@0000
An der Ausgabeformatierung muß ich wohl noch etwas feilen.
Verdrahtungsfehler oder defektes RAM im oberen Nibble?
Ach nein, das untere Nibble hat ja auch Fehler.
Wird dieses "o mit Dach" während des Ramtests ausgegeben, oder kommt das
durch den Reset zustande?
Ansonsten:
Prozessor?
Taktfrequenz?
RAM-Typ?
Über eine Antwort auf meine Frage in diesem Artikel würde ich mich auch
noch freuen:
Beitrag "Re: CP/M auf ATmega88"
Frank Zoll schrieb:> Leo C. schrieb:>> Wir freuen uns jetzt auf den FAT16-Treiber. :-)>> Hihi,>> ich auch. Ich habe mir gestern Nacht schonmal ein wenig den Kopf darüber
Hey, super.
> - Die Performance wird gegenüber den direkten CP/M Partionen stark> leiden. Bei jedem Sektorzugriff muss dieser erst umständlich in der> jeweiligen Image-Datei gesucht werden. ( Juhu Retro like nix schnelle> :-) )
Ich glaube, so schlimm wirds garnicht. Die SD-Zugriffe sind im Vergleich
zum Interpreter und zu den RAM-Zugriffen nämlich sauschnell. Die
RAM-Disk ist auch eher langsamer als die SD-Disk(s).
> FAT16 System. Ich werde mit den derzeit noch verbliebenen knapp 100> Bytes SRAM eines 168AVR's wohl hinkommen. ( Ein paar Bytes werde ich> noch überlassen :-) )
Und wenns doch nicht reicht, kann man die UART RX/TX-Buffer noch
verkleinern. Gut wäre natürlich, wenn man einen 2. Sektorpuffer hätte.
Das würde mit dem ATmega328 gehen.
Leo C. schrieb:> Wenn ich's recht überblicke, sind die ersten 3 "Fast Page Mode" RAM's,> also keine EDO's. Zum IBM habe ich auf die Schnelle kein Datenblatt> gefunden.>> Meiner Meinung nach müßten die alle funktionieren. Es sind aber alles> 1Mx4 Steine, und die haben leider eine andere Pinbelegung als die 4Mx4.> Damit passen Sie leider nicht auf die neue Leiterplatte von Joe. Aber Du> wolltest ja lochrastern...
Letzteres ist soweit richtig. Aber, wie Du schon bemerkt hast, die
Pinbelegung passt nicht zu den ICs, wie sie in der 4, bzw. 8, Bit
Version genutzt werden. ausserdem gehen die Leiterbahnen über einen
kleineren IC. Ob dieser was mit der Ansteuerung zu tun hat, kann ich Dir
leider nicht sagen...
Und, ich wollte eigendlich nicht zuviel in SMD arbeiten. Mir fehlt darin
die Praxis (kann man aber ändern), sowie evtl. benötigtes spezielleres
Werkzeug (Lötstation gehobener Art). Letzteres wollte ich mir nicht
kaufen, da ich doch zu selten etwas löte.
---
Kann mir jemand ein Ram IC empfehlen, den man nicht umbedingt mit
spezielleren Werkzeug beikommen muss? Ich gebe ungern 100€ & mehr aus,
nur um 1x einen SMD IC mit x beinchen zu Löten, bzw. ein Pizza Ofen zum
SMD Reflow Ofen umbauen zu müssen.
---
Habt Ihr evtl. einmal versucht, dieses Projekt mit einem anderem µC zu
entwickeln?
Hallo zusammen,
Ein Dank erstmal an Joe für diesen Bausatz.
Habe meine Platine erst jetzt aufbauen können und ein Problem,
Ich bekomme folgende Meldung
CPM on an AVR, v1.0
Testing RAM: fill...wait...reread...
Initing mmc...
mmcInit
mmcCMD: 00 00000000 .. 95 CMDRes: 01
mmcCMD: 08 000001AA .. 87 CMDRes: 05
mmcCMD: 37 00000000 .. 01 CMDRes: 01 mmcCMD: 29 00000000 .. 01 CMDRes:
01
mmcCMD: 37 00000000 .. 01 CMDRes: 01 mmcCMD: 29 00000000 .. 01 CMDRes:
00
mmcCMD: 10 00000200 .. 01 CMDRes: 00
CT: 02 InitRes: 00
mmcCMD: 11 00000000 .. 01 CMDRes: 00 No bootable CP/M disk found! Please
change MMC/SD-Card.
Folgendes habe ich schon unternommen:
-Alle Verbindungen zum RAM (GM71C17403CJ6) durchgemessen.
-Mehrere Versuche die SD-Karte bootfähig zu machen.
letzte Versuch mit dd if=cpm.bin of=\\.\g:
Bin mir auch nicht so sicher ob das so richtig ist ???
Eine genaue Beschreibung könnte mir schon helfen.
desweiteren habe ich im Softwarearchiv für die AVR-VGA Karte keine
passende Software gefunden.
Bin Dankbar für alle Tipps.
Gruß Egmont
Egmont schrieb:> Hallo zusammen,> Ein Dank erstmal an Joe für diesen Bausatz.> Habe meine Platine erst jetzt aufbauen können und ein Problem,> Ich bekomme folgende Meldung> mmcCMD: 11 00000000 .. 01 CMDRes: 00 No bootable CP/M disk found! Please> change MMC/SD-Card.
Also das Ram- wird es wohl nicht sein, denke ich. Ich hatte den gleichen
Fehler bei mir. Im Grunde genommen lag es wohl an der SD-Card. Es gibt
einige Cards bei dehnen ist das Timing besonders kritisch. Die Karte die
bei mir nicht wollte war eine 1GB-Platinum Card von Reichelt. Mit einer
anderen Card (1GB Verbatim) tat's dann auf anhieb. Es lohnt sich also
bei diesem Fehler einfach mal eine andere Karte zu testen. Das Problem,
das gewisse Karten nicht richtig laufen, haben hier im Forum auch schon
andere gehabt. Bin über die Suche auf den Tip gekommen, mal ne andere
Card zu testen. ( siehe auch
http://www.mikrocontroller.net/articles/MMC-_und_SD-Karten ).
Grüße
Frank
Ronny Minow schrieb:> Leo C. schrieb:>> Damit passen Sie leider nicht auf die neue Leiterplatte von Joe. Aber Du>> wolltest ja lochrastern...>> Letzteres ist soweit richtig. Aber, wie Du schon bemerkt hast, die> Pinbelegung passt nicht zu den ICs, wie sie in der 4, bzw. 8, Bit> Version genutzt werden.
Ich habe zwar begriffen, daß Du die RAM's nicht löten möchtest, aber
diese Bemerkung verstehe ich nicht. Die Pinbelegung bei den 1Mx4 Chips
ist anders als bei den 256Kx4 und 4Mx4 Chips. Aber die Bezeichnungen und
die Funktionen der Anschlüsse sind bei allen (bis auf die Anzahl der
Adressleitungen) gleich. Auf Lochraster spielt es doch keine Rolle, ob
man z.B. RAS auf Pin 4 oder Pin 5 löten muß.
> ausserdem gehen die Leiterbahnen über einen> kleineren IC. Ob dieser was mit der Ansteuerung zu tun hat, kann ich Dir> leider nicht sagen...
Dazu hatte ich schon geschrieben, daß es sich hier um Widerstände
handelt, die man auch weglassen kann.
> Und, ich wollte eigendlich nicht zuviel in SMD arbeiten. Mir fehlt darin> die Praxis (kann man aber ändern), sowie evtl. benötigtes spezielleres> Werkzeug (Lötstation gehobener Art). Letzteres wollte ich mir nicht> kaufen, da ich doch zu selten etwas löte.
Gehobene Art ist nicht nötig. Bei mir tuts seit ca. 30 Jahren ein Weller
Magnastat.
Ronny Minow schrieb:> Leo C. schrieb:>> Wenn ich's recht überblicke, sind die ersten 3 "Fast Page Mode" RAM's,>> also keine EDO's. Zum IBM habe ich auf die Schnelle kein Datenblatt>> gefunden.>>>> Meiner Meinung nach müßten die alle funktionieren. Es sind aber alles>> 1Mx4 Steine, und die haben leider eine andere Pinbelegung als die 4Mx4.>> Damit passen Sie leider nicht auf die neue Leiterplatte von Joe. Aber Du>> wolltest ja lochrastern...>> Letzteres ist soweit richtig. Aber, wie Du schon bemerkt hast, die> Pinbelegung passt nicht zu den ICs, wie sie in der 4, bzw. 8, Bit> Version genutzt werden. ausserdem gehen die Leiterbahnen über einen> kleineren IC. Ob dieser was mit der Ansteuerung zu tun hat, kann ich Dir> leider nicht sagen...>> Und, ich wollte eigendlich nicht zuviel in SMD arbeiten. Mir fehlt darin> die Praxis (kann man aber ändern), sowie evtl. benötigtes spezielleres> Werkzeug (Lötstation gehobener Art). Letzteres wollte ich mir nicht> kaufen, da ich doch zu selten etwas löte.>> --->> Kann mir jemand ein Ram IC empfehlen, den man nicht umbedingt mit> spezielleren Werkzeug beikommen muss? Ich gebe ungern 100€ & mehr aus,> nur um 1x einen SMD IC mit x beinchen zu Löten, bzw. ein Pizza Ofen zum> SMD Reflow Ofen umbauen zu müssen.>> ---
Halloe.
Also meine Card habe ich mit zwei RAM's folgenden Typs bestückt.
SIEMENS HYB5117400BJ-50 (4M x 4-Bit Dynamic RAM)
Und mal ganz erlich, mit diesen RAM's hatte ich beim Auflöten den
meisten Ärger. Alle anderen Chips ließen sich dank der Lötstopmaske
recht leicht festlöten. Ich habe es nach der Anleitung von Thomas
Pfeifer http://thomaspfeifer.net/smd_loeten_tsop.htm gemacht. Das ganze
klinkt zwar sehr Brutal, funktionierte bei mir jedoch auf anhieb. Zur
vorsicht habe ich nach dem Löten alle Pins nur einmal mit der Lupe
untersucht, ob evtl. noch Lötbrücken über waren.
Bei den Ram- Chips hingegen funktioniert diese simple Lösung leider
nicht. Habe hier zu erst versucht einfach alle Pins nacheinander
anzulöten, gerad so wie mans bei den DIL- Chips halt auch machen würde.
Habe micht totgeärgert weil ich immer wieder Pins hatte, die ein kleines
Stück über dem PCB "schwebten" und sich absolut nicht festbrutzeln
lassen wollten. Am Ende wär ich so verärgert, das ich einfach alles
nochmal ab gemacht habe. Dann habe ich alle Pad's mit ganz wenig Lötzin
versehen und das RAM-IC vorsichtig oben drauf gelegt. Danach habe ich
einfach meinen Heizluftföhn ausm Baumarkt genommen und das IC damit
nochmal richtig heiss gemacht. Der Effekt war super. Das IC ist durch
das Flussmittel und das Lötzinn richtig gut auf den PAD's verweilt und
ist sogar noch von selbst in die richtige Endposition gewandern. Am Ende
war dann von beiden IC's nur noch ein einziges Pad über das nicht
verbunden war. Das hab ich dann noch von "Hand" angelötet. Am meisten
Angst hatte ich das der Baumarktföhn evtl. mit IC und Board kurzen
prozess macht. ( Der wird ziemlich Heiss ). Habe das Föhnen daher ganz
ganz Vorsichtig gemacht...
Hab wohl glück gehabt den nun läufts.
Und zu der Frage mit dem kleinen IC, das unter dem SD-Card sockelt
sitzt. Das ist der Pegelwandler für die SD-CARD. Der wird gebraucht,
wenn man den AVR mit 5 Volt betreiben möchte. Den die SD-Cards vertragen
nur 3 Volt. Die Ram- Chips laufen nicht darüber, die Leitungen gehen
daran vorbei.
Grüße
Frank
Leo C. schrieb:> Hans- w. Schütz schrieb:>>> 01<38@0139M: fill...wait...reread...F0<00@0000>> nach einem Reset:>>> CPM on an AVR, v1.0>> Fô<83@0083M: fill...wait...reread...F0<00@0000>
nach dem Reset laufen die Zeichen am Anfang einfach durch, Ausgabe ist
willkürlich!
> An der Ausgabeformatierung muß ich wohl noch etwas feilen.
Was soll denn da kommen?
> Verdrahtungsfehler oder defektes RAM im oberen Nibble?> Ach nein, das untere Nibble hat ja auch Fehler.> Wird dieses "o mit Dach" während des Ramtests ausgegeben, oder kommt das> durch den Reset zustande?>> Ansonsten:> Prozessor?
ATMega 168
> Taktfrequenz?
20 MHz
> RAM-Typ?
Nanya NT511740b5J-60
wenn man eine Weile wartet will er von der SD booten, was aber bisher
nicht richtig funktioniert? Wie andere auch das Problem mit den
Speicherkarten, hab jetzt 6 verschiedene durch.. eine bootet anscheinend
richtig, allerdings sind keine Dateien vorhanden??!!
Bisher etwas unbefriedigend...na mal sehen.
Gruß
Hans- Werner
Leo C. schrieb:> Frank Zoll schrieb:>> - Die Performance wird gegenüber den direkten CP/M Partionen stark>> leiden. Bei jedem Sektorzugriff muss dieser erst umständlich in der>> jeweiligen Image-Datei gesucht werden. ( Juhu Retro like nix schnelle>> :-) )>> Ich glaube, so schlimm wirds garnicht. Die SD-Zugriffe sind im Vergleich> zum Interpreter und zu den RAM-Zugriffen nämlich sauschnell. Die> RAM-Disk ist auch eher langsamer als die SD-Disk(s).
Das Blöde ma FAT Dateisystem ist, das ich mich bei jedem Sectorzugriff
erst die verlinkte Liste der Cluster in der FAT- Tabelle entlanghangeln
muss, um raus zu bekommen in welchem Sektor der gesuchte Dateisektor
wirklich steht. Je weiter hinten in der Datei dieser Sektor steht, desto
langsamer wird die Routine arbeiten. Ich nutzte praktisch kaum Puffer,
so das ich da jedes mal vom anfang der Datei an alles lesen muss.
>> FAT16 System. Ich werde mit den derzeit noch verbliebenen knapp 100>> Bytes SRAM eines 168AVR's wohl hinkommen. ( Ein paar Bytes werde ich>> noch überlassen :-) )>> Und wenns doch nicht reicht, kann man die UART RX/TX-Buffer noch> verkleinern. Gut wäre natürlich, wenn man einen 2. Sektorpuffer hätte.> Das würde mit dem ATmega328 gehen.
Ich müsste schon einen ziemlich großen Block speicher reservieren, um
mir eine Tabelle aller Cluster aufzubauen aus denen die jeweilige
Image-Datei besteht. Da komme ich mit ein paar mehr Bytes einfach nicht
aus. Evtl. könnte man ja später mal drüber nachdenken diese Liste ein
einem Teil des DRAM's zu lagern. Im moment wäre ich aber auch schon
froh, wenns überhaupt läuft.
Einen 2. Sektorpuffer brauche ich erstmal nicht denke ich.
Ach ja, zu eurem Leidwesen habe ich hier mal eben riesen Parts des
Quellcodes umgeschaufelt und neu zusammen gestrickt. Ich habe die Datei
"remainders.asm" ziemlich leer gemacht. Da ist kaum was über geblieben.
Bei mir siehts nun so aus:
virt_ports.asm Hier sind die virtuellen Ports und die hilfsroutinen für
den UART- Zugriff über Ports.
dsk_fsys.asm Hier liegen die Grundroutinen des virtuellen Dateisystems
dsk_cpm.asm Hier liegen die Routinen für den Zugriff auf CP/M
Partitionen
dsk_fat.asm Hier liegen die Routinen für den Zugriff aus FAT16
Partitionen
dsk_ram.asm Hier liegen die Routinen für den Zugriff auf Ramdisk
Partitionen
dsk_mgr.asm Hier liegen die Routinen für die
Partitionstabellenverwaltung
Um das ganze nett aussehen zu lassen habe ich die Tabelle hostparttbl um
ein Byte erweitert. Jeder Eintrag dort wird nun angeführt von einem
Byte, das den Typ der jeweiligen Partition wiederspiegelt.
(0=None,1=CP/M,2=Fat,3=RAM). Im moment baue ich gerade alle Routinen so
um, das sie dieses Byte erkennen können und dann jeweils die für die
Partition richtigen lese/schreib routinen aufrufen.
Im moment läuft nix mehr, aber ich hoffe ich bekomme das noch wieder ans
laufen :-)
Grüße
Frank
Frank Zoll schrieb:> Egmont schrieb:>> Hallo zusammen,>> Ein Dank erstmal an Joe für diesen Bausatz.>> Habe meine Platine erst jetzt aufbauen können und ein Problem,>> Ich bekomme folgende Meldung>> mmcCMD: 11 00000000 .. 01 CMDRes: 00 No bootable CP/M disk found! Please>> change MMC/SD-Card.
Egmont, es kann gut sein daß Frank Recht hat. Es kann aber auch sein,
daß überhaupt keine CP/M-Partition auf Deiner Karte ist.
Kannst Du nochmal einen Versuch mit "MMC_DEBUG = 3" machen?
Vorzugsweise mit der neuesten Programmversion von meinem SVN-Server:
http://cloudbase.homelinux.net/viewvc/avr-cpm/branches/modules/
Da sind geringfügig erweiterte Debugmeldungen drin. Es geht aber auch
mit Deiner jetzigen Version.
> Also das Ram- wird es wohl nicht sein, denke ich. Ich hatte den gleichen> Fehler bei mir. Im Grunde genommen lag es wohl an der SD-Card. Es gibt> einige Cards bei dehnen ist das Timing besonders kritisch. Die Karte die> bei mir nicht wollte war eine 1GB-Platinum Card von Reichelt. Mit einer> anderen Card (1GB Verbatim) tat's dann auf anhieb. Es lohnt sich also> bei diesem Fehler einfach mal eine andere Karte zu testen. Das Problem,> das gewisse Karten nicht richtig laufen, haben hier im Forum auch schon> andere gehabt. Bin über die Suche auf den Tip gekommen, mal ne andere> Card zu testen. ( siehe auch> http://www.mikrocontroller.net/articles/MMC-_und_SD-Karten ).
Frank, Deine Platinum-Karte verhielt sich wirklich merkwürdig. Das
sollte man weiter untersuchen.
hschuetz schrieb:> Leo C. schrieb:>> Hans- w. Schütz schrieb:>>>>> 01<38@0139M: fill...wait...reread...F0<00@0000>>> nach einem Reset:>>>>> CPM on an AVR, v1.0>>> Fô<83@0083M: fill...wait...reread...F0<00@0000>>> nach dem Reset laufen die Zeichen am Anfang einfach durch, Ausgabe ist> willkürlich!>> An der Ausgabeformatierung muß ich wohl noch etwas feilen.> Was soll denn da kommen?
Das gleiche, aber nicht so viel übereinander. :)
>> Prozessor?> ATMega 168>> Taktfrequenz?> 20 MHz>> RAM-Typ?> Nanya NT511740b5J-60
Vom Timing her dürfte es keine Probleme geben. Du bist aber der Erste,
der hier mit EDO-RAM's aufschlägt. Ich bin (noch) der Meinung, daß die
auch funktionieren müßten. Aber ich werde mir das Datenblatt jetzt mal
genauer anschauen.
> wenn man eine Weile wartet will er von der SD booten, was aber bisher> nicht richtig funktioniert? Wie andere auch das Problem mit den> Speicherkarten, hab jetzt 6 verschiedene durch.. eine bootet anscheinend> richtig, allerdings sind keine Dateien vorhanden??!!
Bevor die RAM-Fehler nicht weg sind, brauchst Du mit SD-Karten gar nicht
anfangen.
> Bisher etwas unbefriedigend...na mal sehen.
Shit happens...
Frank Zoll schrieb:> Ach ja, zu eurem Leidwesen habe ich hier mal eben riesen Parts des> Quellcodes umgeschaufelt und neu zusammen gestrickt. Ich habe die Datei> "remainders.asm" ziemlich leer gemacht. Da ist kaum was über geblieben.
So war das mit mit der Datei auch gedacht. Da war alles drin, für das
ich noch keinen neuen Platz gefunden hatte.
>> Bei mir siehts nun so aus:>> virt_ports.asm Hier sind die virtuellen Ports und die hilfsroutinen für> den UART- Zugriff über Ports.> dsk_fsys.asm Hier liegen die Grundroutinen des virtuellen Dateisystems> dsk_cpm.asm Hier liegen die Routinen für den Zugriff auf CP/M> Partitionen> dsk_fat.asm Hier liegen die Routinen für den Zugriff aus FAT16> Partitionen> dsk_ram.asm Hier liegen die Routinen für den Zugriff auf Ramdisk> Partitionen> dsk_mgr.asm Hier liegen die Routinen für die> Partitionstabellenverwaltung
Sieht gut aus.
Man könnte sich überlegen den Assembler auf GNU avr-as umzustellen,
damit man aus den Dateien getrennte Übersetzungseinheiten machen kann.
> Um das ganze nett aussehen zu lassen habe ich die Tabelle hostparttbl um> ein Byte erweitert. Jeder Eintrag dort wird nun angeführt von einem> Byte, das den Typ der jeweiligen Partition wiederspiegelt.> (0=None,1=CP/M,2=Fat,3=RAM). Im moment baue ich gerade alle Routinen so> um, das sie dieses Byte erkennen können und dann jeweils die für die> Partition richtigen lese/schreib routinen aufrufen.> Im moment läuft nix mehr, aber ich hoffe ich bekomme das noch wieder ans> laufen :-)
Ich werde den jetzigen Stand mal einfrieren und eine Version draus
machen.
Hat jemand einen Vorschlag für eine Versionsnummer? :)
Deine Änderungen werden dann die nächste Version.
Frank Zoll schrieb:> Es gibt> einige Cards bei dehnen ist das Timing besonders kritisch. Die Karte die> bei mir nicht wollte war eine 1GB-Platinum Card von Reichelt.
Würde es Dir sehr viel Mühe bereiten, die Platinum-Karte nochmal mit
Softwarerevision 91 zu testen?
Die kannst Du z.B. über folgenden Link bekommen:
http://cloudbase.homelinux.net/viewvc/avr-cpm/branches/modules/avrcpm/avr/?view=tar&pathrev=91> http://www.mikrocontroller.net/articles/MMC-_und_SD-Karten ).
Zitat: "Die MMC-Implementierung für AVR von Elm Chan z. B. funktioniert
mit SanDisk problemlos hat aber mit Platinum Karten ein Problem."
Die aktuellen MMC-Routinen sind im wesentlichen die von Chan, nur in
Assembler. Die älteren von Sprite_tm sind bis Rev. 91 noch drin und
teilweise anders.
@all: Mit Platinum Karten (auch CF - Amiga) habe ich keine guten
Erfahrungen gemacht.. kaufe ich seitdem nicht mehr..
@Leo C. Vorschlag für Versionsnummer.. eigendlich hätte es schon einige
geben müssen.. ;-) Ich nehme immer völlig unortodox das Datum in der
Form:
YYYYMMDD - so weiß man immer gleich was die neueste Version ist und wann
diese zeitlich anzusiedeln ist ;-)
Peter
Hallo,
nun rennt's..... wer lesen kann ist klar im Vorteil....
Hatte bei assemblieren den 4bit Ram teil mit drin...und somit die
Fehler..
allerdings habe ich den SPI Clock auf /4 es laufen jetzt 2 Platinium
1Gb, eine SD 16Mb von Thoshiba und eine MMC 256Mb vom Medion.....
nun muss ich mal sehen wie ich Programme auf die Kartenimages bekomme...
CPM on an AVR, v1.0
Testing RAM: fill...wait...reread...
Initing mmc...
CP/M partition at: 060, size: 6930KB.
CP/M partition at: 13920, size: 8700KB.
CP/M partition at: 31320, size: 7830KB.
CP/M partition at: 46980, size: 7830KB.
Partinit done.
Ok, CPU is live!
ipl
62k cp/m vers 2.2
A>dir
A: ASM COM : DDT COM : DUMP COM : ED COM
A: T COM : LOAD COM : MBASIC COM : PIP COM
A: STAT COM : SUBMIT COM : XSUB COM : ZORK1 COM
A: ZORK1 DAT
A>
Gruß
Hans- Werner
Leo C. schrieb:> Frank Zoll schrieb:>> Es gibt>> einige Cards bei dehnen ist das Timing besonders kritisch. Die Karte die>> bei mir nicht wollte war eine 1GB-Platinum Card von Reichelt.>> Würde es Dir sehr viel Mühe bereiten, die Platinum-Karte nochmal mit> Softwarerevision 91 zu testen?
Ich habe mir heut morgen mal schnell die neuere Version gezogen und es
ausprobiert. Habs aber auf Anhieb nicht gleich ans laufen bekommen und
musste recht schnell aufgeben. Er hat einmal ganz kurz die Platinum Disk
erkannt, sich dann aber irgendwie aufgehängt. Nach dem Aufhängen kahm
keine Verbidung mehr zum Terminal zustande. Erst nachdem ich wieder
meine eigene Entwicklung aufgespielt habe, hat sich der Rechner wieder
gemeldet.
Wie ich sehe scheint es nicht unbedingt nur an der Marke "Platinum" zu
liegen. Zwei 1GB- Karten scheinen bei Hans Werner ja zu laufen. Ich
denke einfach mal, das meine SD-Card bereits eine macke hat. Wer ganz
oben mitgelesen hat, wird ja schon sehen das die Karte auch unter
SUSE-11.2 nicht ans laufen zu bringen war. Immer wenn ein HighSpeed
zugriff statt fand, brach die Verbindugn zur Karte ab. Ich hab die Karte
mitlerweile mal versucht mit meinen HIVE ans laufen zu bekommen. Auf dem
HIVE ziegt sich da ein ähnlicher Fehler. Die Karte wird nur ab und zu
mal erkannt.
Ich denke einfach mal das die Karte bereits einen kleinen Schaden weg
hat. Aber seltsam ist's schon das sie unter Window noch ansprechbar ist.
Freundliche Grüße
Frank
Hallo,
ich habe alles mit den SD Karten mit einem Debian System gemacht,
anscheinend ist aber das AVR Programm entscheidend.
Die 1Gb Karten sind auch ein bisschen ziggig... wenn man die Karten
unter Spannung zieht!!! das hat teilweise die komplette Zerstörung der
Daten zur Folge!!
Gruß
Hans- Werner
Egmont schrieb:> CT: 02 InitRes: 00 SPI_DISABLE
Die Karte wurde ohne Fehler initialisiert.
> mmcRdSect SPI_CLK_FAST> mmcCMD: 11 00000000 <FF <FF <FF >51 .. 01>01 <FF <00 CMDRes: 00 <FF <FF> <FE <00 <08 <FF SPI_DISABLE RdSectRes: 00
Sektor 0 der Karte (Partitionstabelle) wurde ohne Fehler gelesen.
> No bootable CP/M disk found!
Auf der Karte ist keine CP/M-Partition (Type 52), und am Anfang der
Karte ist kein CP/M-Diskimage.
> Ist es möglich deine(oder von Joe) CP/M-System-Datei zur verfügung zu> stellen, sodass ich die mit DD.exe auf meine SD-Karte übertrage kann> (Laufwerk A:).
Ich habe mal ein Diskimage hier angehängt. Das kannst Du mit dd auf eine
SD-Karte kopieren. Entweder direkt an den Anfang einer Karte (der alte
Inhalt der Karte geht dabei komplett verloren), oder in eine primäre
Partition. Die Partition muß Typ 52 haben. Wie das unter Windows geht,
weiß ich nicht.
Hallo Hans-Werner,
herzlichen Glückwunsch zu Deinem neuen funktionierenden CP/M-System.
hschuetz schrieb:> Die 1Gb Karten sind auch ein bisschen ziggig... wenn man die Karten> unter Spannung zieht!!! das hat teilweise die komplette Zerstörung der> Daten zur Folge!!
Das ist mir noch nie passiert. Ich ziehe die Karten an manchen Tagen 20
mal oder noch öfter. Hauptsächlich teste ich mit einer 2G Intenso. Die
Karte fällt jetzt zum 2. Mal auseinander. Ich hatte sie schon mal mit
Sekundenkleber zusammengeklebt und mit 2-Komponentenkleber in Form
gebracht (Schreibschutzschieber war abgefallen). Ich habe aber auch noch
2 verschiedene 1G Karten und eine 2G Mikro-SD-Karte im Test.
Halloe.
Mal ein kurzer Status der FAT16 implementierung. Ich kämpfe mich gerade
durch die Strukturen von Bootblock, FAT und Direktory. Habe schon die
korrekten Positionen von Bootblock, FAT, und Root- Direktory auf meiner
Testpartition gefunden. Morgen schaue ich dann mal, das ich das Root-
Verzeichniss nach den Image-Dateien durchsuche.
Hans- w. Schütz schrieb:> hat sich schon jemand mit dem kleineren Teil der Platine befasst??> Ja das VGA Terminal...
Um erlich zu sein, bisher nicht. Mir fehlen dummerweise noch die 3 470
Ohm 1206er SMD Widerstände vor der VGA- Buchse. So konnte ich den Teil
der Platine leider noch nicht fertig stellen. Naja und nur für die 3
Widerstände ne Bestellung aufgeben, das wiederstrebte mir. Hab gerad nix
anderes, das ich noch mitbestellen könnte.
Grüße
Frank
Moin Frank,
wenn Du mir Deine Adresse mailst, pack ich die in 'nen
Briefumschlag.
Softwaretechnisch kann ich eh nicht unterstützen, komme
mehr von der Hardware und da auch nicht unbedingt von
den Mikrocontrollern.
Gruss
Peter
Nun läßt sich der Dateianfang bereits erfolgreich lokalisieren. Als
nächstes muss ich noch eine Methode bauen, die sich Cluster für Cluster
zu einem beliebigen "Zielsektor" vorarbeiten kann. Dann kann ich das
Laden und Speichern der Sektoren so anpassen, das Sektoren aus dem Image
gelesen und geschreiben werden können. Vorher muss ich nur noch klären,
wieso da oben 256258 Bytes steht und nicht 256256. Denn die Datei ist
genau 256256 Bytes groß, irgenwie haben sie da 2 zusatzbytes
eingeschlichen :-) Die Zahl 005 gibt die Nummer des ersten Clusters der
Datei an. Diese Zahl speichere ich nun zusammen mit dem Partitionstyp in
der internen Partitionstabelle. Damit lassen sich später sowohl der
Dateianfang als auch der erste Cluster in der FAT schnell wiederfinden.
Grüße
Frank
@all: Mann! Schön, das sich hier so viel tut!! Wer hätte das mal
gedacht.. das sich aus dem 'Proof of concept' mal ein (fast)
vollwärtiges CP/M System
entwickelt...
Ich bin zur Zeit mit CC 2010 (Verein zum Erhalt klassischer Computer)
Messe/Treffen-Vorbereitungen etwas arg ausgelastet und komme daher zur
Zeit zu fast nicht anderem mehr.. aber der nächste 'Winter' kommt
bestimmt.. ;-)
Weiter so!
Peter
@alle: Ich bin beeindruckt was hier so alles passiert, wenn man eine
Woche nicht im Lande ist... Wichtig für noch alle weiteren potentiellen
Nachbauer und natürlich auch für die aktuelle Dokumentation, wäre die
Information ob Layout und Schaltung fehlerfrei sind (PWREN# habe ich
schon). Da einige „neue“ Systeme schon arbeiten, gehe ich mal davon aus
oder irre ich?
Gruß Joe
Joe G. schrieb:> @alle: Ich bin beeindruckt was hier so alles passiert, wenn man eine> Woche nicht im Lande ist... Wichtig für noch alle weiteren potentiellen> Nachbauer und natürlich auch für die aktuelle Dokumentation, wäre die> Information ob Layout und Schaltung fehlerfrei sind (PWREN# habe ich> schon). Da einige „neue“ Systeme schon arbeiten, gehe ich mal davon aus> oder irre ich?> Gruß Joe
Hallo Joe,
beim Layout von der VGA-Karte kann ich nur sagen das die drei
Widerstände 470 ohm an der Sub-D Buche sehr Dicht anliegen,
Meine Buchse ist komplett mit Kunststoff umgeben (habe da was
weggefräst) und somit gab es da keine Probleme.
Wo ist den für die Mini-VGA die Software abgelegt ??
Gruß Egmont
Egmont schrieb:> die drei> Widerstände 470 ohm an der Sub-D Buche sehr Dicht anliegen
Vielen Dank für den Hinweis!
Für die VGA gibt es noch keinen Code außer das Original, siehe hier:
Beitrag "AVR VGA Terminal"
@Joe,Feinmechaniker
pin 8 sollte doch an Masse liegen?? oder? Bei beiden AVR's liegen die
Anschlüsse in der Luft! Allerdings auch im Schaltplan!! Der Quarz hängt
auch in der Luft.
Gruß Hans- Werner
Hans- w. Schütz schrieb:> pin 8 sollte doch an Masse liegen??> Der Quarz hängt auch in der Luft.
DANKE!
Ja, sicher... dumme Sache mit Pin 8!
Beim Quarz ist es so gewollt. Die Jumperkonfiguration bot aus
Platzmangel keine andere Mögtlichkeit. Wird ein Quarz verwendet, so muß
eine kleine Brücke zwischen Quarz und Pin 9 gelegt werden.
Also für alle:
- Pin 8 (beide AVR) auf Masse legen.
- Quarzbestückung bei IC1 - Pin 9 des AVR mit dem Quarz verbinden (siehe
Schaltung)
Joe
Hallo,
hat denn einer schon etwas mit der VGA hinbekommen?
Irgendwie bin ich zu "dusselig" die Original Sourcen zu compilieren,
immer massenhaft Fehlermeldungen?!!
Gruß
Hans- Werner
Frank Zoll schrieb:> Halloe.>> Wieder ein kleines Stück voran gekommen.CP/M partition at: 1757875, size:
9728KB.
> CP/M partition at: 1777406, size: 9728KB.> CP/M partition at: 1796937, size: 73344KB.> FAT16 File-Image at: 005, size: 256258Bytes.> Partinit done.> Ok, CPU is live!
@Frank,
was macht deine Software mit FAT16...
@ALLE
habe immer noch nicht das Problem gelöst das ich auf meine SD-Karte ein
Bootprojekt finde.
Leo C. schrieb:> Auf der Karte ist keine CP/M-Partition (Type 52), und am Anfang der> Karte ist kein CP/M-Diskimage.
Habe mit ein Hexeditor mal auf meine SD-Karte geschaut und die Daten von
diskimage dort gefunden, dirkt am Anfang der Karte (vermute mal das das
so richtig ist). Nur was ist mit Type 52 gemeint ????
habe mit "DD if=diskimage of=\\.\f:" die Datei auf SD kopiert, benötige
ich noch Parameter die eine Partion vom Type 52 anlegt ??
Gruß Egmont
Egmont schrieb:> Habe mit ein Hexeditor mal auf meine SD-Karte geschaut und die Daten von> diskimage dort gefunden, dirkt am Anfang der Karte (vermute mal das das> so richtig ist). Nur was ist mit Type 52 gemeint ????
Hier ist die Partitionstabelle erklärt:
http://de.wikipedia.org/wiki/Partitionstabelle
Die Partitionstabelle liegt zusammen mit dem Bootloader im ersten Sektor
einer Festplatte, bzw. Speicherkarte (MBR).
Man kann (jedenfalls beim avrcpm-Computer) die Partitionstabelle, bzw.
den MBR aber auch weglassen. Dann beginnen die Nutzdaten im ersten
Sektor. Und natürlich hat man dann auch nur ein CP/M-Diskimage, und der
Rest der Karte ist nicht nutzbar.
> habe mit "DD if=diskimage of=\\.\f:" die Datei auf SD kopiert, benötige> ich noch Parameter die eine Partion vom Type 52 anlegt ??
Ich kenne mich mit dem Windows-DD nicht genug aus, um sagen zu können,
ob "\\.\f:" in einer Partition liegt, oder am Anfang der Karte.
Leo C. schrieb:>> habe mit "DD if=diskimage of=\\.\f:" die Datei auf SD kopiert, benötige>> ich noch Parameter die eine Partion vom Type 52 anlegt ??>> Ich kenne mich mit dem Windows-DD nicht genug aus, um sagen zu können,> ob "\\.\f:" in einer Partition liegt, oder am Anfang der Karte.
Damit liegt das Image am Anfang der Karte.. daher ist es keine Partition
und damit ist Part.Typ 52 auch irrelevant..
Ist denn der Artikel an dieser Stelle noch zu unverständlich..?:
[quote]
Das so erzeugete diskimage wird ROH (ohne Filesystem) mit:
dd if=diskimage of=<sd card identifier> bs=512
auf eine SD Karte geschrieben. Achtung! Alle anderen Dateien gehen dabei
verloren!
Die aktuelle Version unterstützt ebenfalls bis zu 4 primäre CP/M = Typ
52 Partitionen. Diese lassen sich mit einer Linux Live-CD und dem Tool
'cfdisk' anlegen. Da z.Z die virtuellen Disketten nur ca. 250kb 'groß'
sind, reicht es entsprechend große Partitionen azulegen (Ich habe
trotzdem 8MB große angelegt.. für später). Wichtig dabei ist es den Typ
auf 52 = CP/M zu setzen.. und schreiben/speichern nicht vergessen. Die
einzelnen Partitionen werden dann ohne zu formattieren wieder mittels
'dd if=diskimage of=[sd card partition] bs=512' gefüllt. Wird also die
SD Karte unter Linux z.B als sdh angezeigt, so ist die erste Partition
dann sdh1, die zweite sdh2 etc. of= ist dann also /dev/sdh1 /2 /3..
Ich habe übrigens die erste Partition als FAT eingerichtet und
entsprechend formattiert. So kann man den großen Bereich weiter unter
Windows nutzen. Und dann nur 3 CP/M Partitionen am Ende des
Speicherbereiches angelegt..
[/quote]
Peter
Leo C. schrieb:> Vor kurzem bin ich zufällig über ein CP/M-Plugin für den "Total> Commander" gestolpert:> http://hc-ddr.hucki.net/wiki/doku.php/cpm:disketten_xp2>> Vielleicht ist das ja für den einen oder anderen Windowsbenutzer> interessant.
Das habe ich vor Monaten schon mal getestet. Der Treiber greift direkt
auf den Floppycontroller zu, also leider für uns in dieser Form
ungeeignet :-(
Gerade gingen endlich die FT232 bei mir ein. Ich habe euch kleine
Briefchen gesendet....
Joe
Soo.. bin gerade dabei mich mit einem LR Aufbau einer 8-bit Variante zu
beschäftigen.. Dazu ein paar Fragen:
1. Ich kann den 2ten Dram Chip Huckepack 1:1 auf den Ersten Chip löten -
außer D0 - D3 (die 4 Datenbits)! Stimmt das so, oder sind noch
irgendwelche anderen Pin's, die getrennt zu verbinden sind..?
2. Ich könnte doch auch 256k x 4 Drams nehmen.. für die 8-bit
Variante..?
Klar ist es dann nicht 4MB, sondern nur 256k.. ;-) Vorteil für mich
wäre, DIL Fassung!
Die Verdrahtung würde ich dann nach config.inc - 8-bit Teil vornehmen:
1
#if DRAM_8BIT /* Implies software uart */
2
3
;Port D
4
.equ RAM_D0 = 0
5
.equ RAM_D1 = 1
6
.equ RAM_D2 = 2
7
.equ RAM_D3 = 3
8
.equ RAM_D4 = 4
9
.equ RAM_D5 = 5
10
.equ RAM_D6 = 6
11
.equ RAM_D7 = 7
12
.equ RAM_A0 = 0
13
.equ RAM_A1 = 1
14
.equ RAM_A2 = 2
15
.equ RAM_A3 = 3
16
.equ RAM_A4 = 4
17
.equ RAM_A5 = 5
18
.equ RAM_A6 = 6
19
.equ RAM_A7 = 7
20
21
;Port B
22
.equ RXD = 0
23
.equ TXD = 1
24
.equ MMC_CS = 2
25
.equ MMC_MOSI = 3
26
.equ MMC_MISO = 4
27
.equ MMC_SCK = 5
28
.equ RAM_A8 = 3
29
.equ RAM_A9 = 4
30
.equ RAM_A10 = 5
31
32
;Port C
33
.equ RAM_RAS = 0
34
.equ RAM_CAS = 1
35
.equ RAM_OE = 2
36
.equ RAM_W = 3
Pinouts von 256kx4 und 4Mx4 hänge ich hier mal an..
BTW: Ich will nur eine 3.3V Versorgung für das ganze System machen.
Und serielle Anbindung über TTL.
Passt das so.. oder habe ich irgendwas vergessen..?
Peter
Egmont schrieb:> Frank Zoll schrieb:>> Halloe.>> CP/M partition at: 1777406, size: 9728KB.>> FAT16 File-Image at: 005, size: 256258Bytes.>> @Frank,> was macht deine Software mit FAT16...
Och das ist eigentlich ganz einfach zu erklären. Ich hab mich einfach zu
dolle über Linux geärgert, weil ich immer wieder Probleme mit der
Hardwareerkennung hatte. Daher suchte ich nach einer "einfacheren"
möglichkeit um unter Windows die "Partitionen" für das CP/M Projekt
anzulegen.
Meine Aktuelle Lösung sieht so aus:
- Ich suche die 1. FAT16 Partition die ich auf der SD-Card finden kann.
- Ich schaue im ROOT- Verzeichniss dieser Partition nach Dateien die
diesem Schema entsprechen "CPMDSK_!.IMG" ( != Ein beliebieger Buchstabe
A-Z )
- Diese Dateien müssen derzeit genau 256KB gross sein. Daher habe ich
ein kleines Programm geschrieben das an die hier im Forum zu findenen
Images einfach Nullen dranhängt, bis 256KB erreicht sind.
- Jede gefundene Datei wird als virtuelle Partition in das CP/M System
eingebunden.
- Für das CP/M sieht der Zugriff über die Ports nacher genauso aus, wie
bei den "echten" CP/M Partitionen.
- Ach ja. Da echte CP/M Partitionen einen schnelleren Zugriff erlauben,
werden diese bevorzugt an den Anfang der Liste der "virtuellen"
Laufwerke gesetzt. Eine Mischung auf CP/M und FAT16 Partitionen ist
somit dann auch möglich.
Mit diesen Lösung spart man sich das Partitionieren der SD- Card unter
Linux und den ständigen wechsel zwischen Windows und Linux zum kopieren
der CP/M Images. Die per CPMTOOLS angelegten Diskettenimages kann man
nach dem "aufpusten" auf 256KB praktisch direkt verwenden.
Ich bin in den letzten Tagen nicht zum Coden gekommen. Aktuell muss ich
"nur noch" die Funktion schreiben, die aus einer CP/M- Sektorangabe
einen Sektor aus der Diskimage- Datei ermittelt. Schreiben und Lesen der
Sektoren werde ich danach wieder über die bereits bestehenden MMC-
Zugriffsrotuinen abwickeln. Ich denke das ich da noch 3-4 Abende rein
stecken muss, bis es endlich richtig läuft. Sobald ich es am laufen habe
werde ich hier mal ein Archiv mit meiner Version posten.
Mit dem zur Verfügung stehenden Speicher werden wir auskommen. Aktuell
liegt der Speicherverbrauch bei meinem Atmega168 Version bei:
Flash 9196 von 16384 genutzt.
SRAM 930 von 1024 genutzt.
EEPROM noch leer.
Grüße
Frank
Es ist aber noch einiges zu tun.
> Zugriffsrotuinen abwickeln. Ich denke das ich da noch 3-4 Abende rein> stecken muss, bis es endlich richtig läuft. Sobald ich es am laufen habe> werde ich hier mal ein Archiv mit meiner Version posten.
Hast Du meine Mail bekommen?
> liegt der Speicherverbrauch bei meinem Atmega168 Version bei:> Flash 9196 von 16384 genutzt.> SRAM 930 von 1024 genutzt.> EEPROM noch leer.
Da wäre noch Platz für einen Monitor. :-)
Peter Sieg schrieb:> Soo.. bin gerade dabei mich mit einem LR Aufbau einer 8-bit Variante zu> beschäftigen.. Dazu ein paar Fragen:>> 1. Ich kann den 2ten Dram Chip Huckepack 1:1 auf den Ersten Chip löten -> außer D0 - D3 (die 4 Datenbits)! Stimmt das so, oder sind noch> irgendwelche anderen Pin's, die getrennt zu verbinden sind..?
Welche sollten das den sein?
Huckepack mit SOJ-Gehäusen geht gut, wenn man beim oberen Chip die Pins
gerade nach unten biegt.
Dazu hatte ich schon mal ein Bild gepostet:
Beitrag "Re: CP/M auf ATmega88"> 2. Ich könnte doch auch 256k x 4 Drams nehmen.. für die 8-bit> Variante..?
Du kannst tun und lassen was Du willst.
> Klar ist es dann nicht 4MB, sondern nur 256k.. ;-) Vorteil für mich> wäre, DIL Fassung!> Die Verdrahtung würde ich dann nach config.inc - 8-bit Teil vornehmen:> [code]> #if DRAM_8BIT /* Implies software uart */
Oder einfach nach dem Schaltplan von Joe.
Joe G. schrieb:> Leo C. schrieb:>> Vor kurzem bin ich zufällig über ein CP/M-Plugin für den "Total>> Commander" gestolpert:>> http://hc-ddr.hucki.net/wiki/doku.php/cpm:disketten_xp2>>>> Vielleicht ist das ja für den einen oder anderen Windowsbenutzer>> interessant.>> Das habe ich vor Monaten schon mal getestet. Der Treiber greift direkt> auf den Floppycontroller zu, also leider für uns in dieser Form> ungeeignet :-(
Nicht daß es wichtig wäre, aber ich verstehe die Webseite so, daß man
auch direkt auf Floppies zugreifen kann. Aber genauso auch auf
Diskimages.
Das ganze ist ja nur eine graphische Oberfläche zu libdsk und cpmtools,
also zu dem, was wir auf der Kommandozeile eh schon haben.
Zitat: "Mein Plugin arbeitet mit CP/M-Disketten und Diskettenimages,
die von libdsk unterstützt werden, also Teledisk, CopyQM, MyZ80, DSK,
CFI, RAW, …"
Leo C. schrieb:> Du kannst tun und lassen was Du willst.
Danke Leo.. du bist wirklich sehr nett ;-) (Und hast einen besonderen
Humor) Sicher ist dir klar, das ich damit fragen wollte, das es da auch
mit der Firmware klappt.. macht ja keinen Sinn sowas aufzubauen, wenn es
dann nachher mit der Software nicht geht.. ;-)
Und vom Schaltplan.. da wäre es einfacher ohne Bus.. so muß man in Eagle
jede Verbindung anklicken und sehen, was mit was verbunden ist bzw. den
Signalnamen prüfen.. da ist so eine einfache Verbindungsliste für mich
und einen LR Aufbau einfacher..
Und wie ich sehe hast du dich schon an den disk Parametern dran
gesetzt..
Supi!! Dann gibts ja bald Images/Partitionen >243kb ;-)
Peter
Peter Sieg schrieb:> da wäre es einfacher ohne Bus.. so muß man in Eagle> jede Verbindung anklicken und sehen, was mit was verbunden ist bzw. den> Signalnamen prüfen
nö, ich habe jede Busleitung beschriftet. z.B.
D0_A0 | RAM Pin 9
D0_A0 | AVR Pin 2 usw.
Peter Sieg schrieb:> Leo C. schrieb:>> Du kannst tun und lassen was Du willst.>> Danke Leo.. du bist wirklich sehr nett ;-) (Und hast einen besonderen> Humor)
Man tut, was man kann.
> Sicher ist dir klar, das ich damit fragen wollte, das es da auch> mit der Firmware klappt.. macht ja keinen Sinn sowas aufzubauen, wenn es> dann nachher mit der Software nicht geht.. ;-)
Ich habe mich wirklich sehr gewundert, daß diese Frage ausgerechnet von
Dir kommt. Ich könnte mir vorstellen, daß Du die Antwort sogar in Deinen
eigenen Artikeln hier finden könntest.
> Und vom Schaltplan.. da wäre es einfacher ohne Bus.. so muß man in Eagle> jede Verbindung anklicken und sehen, was mit was verbunden ist bzw. den> Signalnamen prüfen.. da ist so eine einfache Verbindungsliste für mich> und einen LR Aufbau einfacher..
Zu dem Teil ist ja gerade eine Antwort von Joe reigekommen.
> Und wie ich sehe hast du dich schon an den disk Parametern dran> gesetzt..> Supi!! Dann gibts ja bald Images/Partitionen >243kb ;-)
Die grundsätzlichen Funktionen sind schon mal vorhanden. Aber ich habe
noch ein kleines Henne-Ei-Problem. Ich brauche Daten aus dem Bios, um
das Bios zu laden...
Übrigens wird man einige bekannte Diskimageformate, zB. MyZ80, (nahezu)
direkt verwenden können: Header abschneiden, neuen Header dranpappen,
fertig.
@Leo C./Joe: Ich bin mir bei der Verdrahtung ja auch zu 99,9% sicher..
ebendso bei der Antwort zu der Frage, ob nur D0-D3 NICHT verbunden
werden.. alle anderen Pin's ja.. bin ich zu 99,89763% sicher.. wäre nur
schön gewesen
einfach mal zu hören: Ja, genau.. oder Jup, so isses.. ;-)
;-)
Peter
Argh.. kann nicht editieren.. sorry..
@Joe: Ja jetzt sehe ich die Beschriftung.. prima.. werde ich dann groß
ausdrucken und für den LR Aufbau nutzen.. Danke!
Peter
Hallo an Alle....
Peter Sieg schrieb:> Die aktuelle Version unterstützt ebenfalls bis zu 4 primäre CP/M = Typ> 52 Partitionen. Diese lassen sich mit einer Linux Live-CD und dem Tool> 'cfdisk' anlegen. .....
Habe mir eine Koppix besorgt und habe es jetzt am laufen
######################################
CPM on an AVR, v32.10
Testing RAM: fill...wait...reread...
Initing mmc...
CP/M partition at: 1895040, size: 8064KB.
CP/M partition at: 1911168, size: 8064KB.
CP/M partition at: 1927296, size: 8064KB.
Partinit done.
Ok, CPU is live!
ipl
62k cp/m vers 2.2
A>
######################################
habe jetzt noch eine Partition die 960MB belegt, noch drauf.. so wie
Peter das geschrieben hat.
Aber Linux ist nicht so mein Ding und wäre Happy wenn das mit FAT16
klappt.
Gruß Egmont
So,
hat leider etwas länger gedauert als gedacht aber hier mal ein kurzes
Update. Ich hab soeben das erste mal lesend auf ein Diskimage auf meiner
FAT16 Partition zugreifen können. Das anzeigen des Directorys und der
Programmstart funktionieren. Das schreiben hab ich vorsichtshalber
erstmal abgestellt, bis ich sicher bin, das die Schreibopüerationen auch
immer schön in die Datei gehen und nicht daneben. :-)
Ich habe Leo eben mal eine kleine Vorabversion zum testen geschickt.
Sobald die letzten Macken beseitigt sind und der neue Code auch schön
aufgeräumt ist, gibts hier ein kleines Release.
1
CP/M partition at: 1757875, size: 9765KB.
2
CP/M partition at: 1777406, size: 9765KB.
3
CP/M partition at: 1796937, size: 73464KB.
4
FAT16 File-Image at: 005, size: 250KB.
5
Partinit done.
6
Ok, CPU is live!
7
8
ipl
9
62k cp/m vers 2.2
10
11
A>d:
12
D>dir
13
D: ASM COM : DDT COM : DUMP COM : ED COM
14
D: T COM : TLOOP COM : LOAD COM : MBASIC COM
15
D: 23 BAS : BAGELS BAS : CHECKERS BAS : STARTREK BAS
16
D: TREKINST BAS : MASTRMND BAS : WEEKDAY BAS : PIP COM
Frank Zoll schrieb:> So,> hat leider etwas länger gedauert als gedacht aber hier mal ein kurzes> Update. Ich hab soeben das erste mal lesend auf ein Diskimage auf meiner> FAT16 Partition zugreifen können. Das anzeigen des Directorys und der> Programmstart funktionieren. Das schreiben hab ich vorsichtshalber> erstmal abgestellt, bis ich sicher bin, das die Schreibopüerationen auch> immer schön in die Datei gehen und nicht daneben. :-)>> Ich habe Leo eben mal eine kleine Vorabversion zum testen geschickt.> Sobald die letzten Macken beseitigt sind und der neue Code auch schön> aufgeräumt ist, gibts hier ein kleines Release.
Zum Ausprobieren ist jetzt alles auf:
http://cloudbase.homelinux.net/viewvc/avr-cpm/trunk/avrcpm/avr/
Oder inzwischen auch besser mit SVN-Client (z.B. Tortoise SVN) auf:
http://cloudbase.homelinux.net/svn/avr-cpm/trunk/avrcpm/avr/
Die Reste aus "remainders.asm" haben jetzt auch ihre eigenen Dateien
bekommen. Außerdem habe ich für Jump und Call Makros gebaut, die je nach
Prozessor und Sprungweite den passenden rjmp/jmp, bzw. rcall/call Befehl
verwenden.
Bei mir assemblieren alle Prozessor-/RAM-Kombinationen mit und ohne
FAT16-Unterstützung (Mega8 und 88 nur ohne FAT16).
Das ist alles nur zum Testen und noch nicht unbedingt stabil. Z.B. passt
das BIOS aus trunk nicht mehr dazu. Bitte das BIOS aus dem stabilen
Zweig nehmen.
Zur Zeit muß die FAT16-Partition den Typ 0E haben. Da wir nur
LBA-Adressierung verwenden, wäre das eigentlich auch richtig. Gängig ist
aber auch Typ 6, der nicht erkannt wird. Sicher könnte man das umstellen
oder Typ 6 zusätzlich einbauen. Es stellt sich nur die Frage, was
sinnvoll ist.
"Meine" Partitionstypenreferenz
(http://www.win.tue.nl/~aeb/partitions/partition_types-1.html) meint
dazu:
1
06 DOS 3.31+ 16-bit FAT (over 32M)
2
Partitions, or at least the FAT16 filesystems created on them, are at
3
most 2 GB for DOS and Windows 95/98 (at most 65536 clusters, each at most
4
32 KB). Windows NT can create up to 4 GB FAT16 filesystems (using 64 KB
5
clusters), but these cause problems for DOS and Windows 95/98. Note that
6
VFAT is 16-bit FAT with long filenames; FAT32 is a different filesystem.
7
8
0e WIN95: DOS 16-bit FAT, LBA-mapped
9
0f WIN95: Extended partition, LBA-mapped
10
Windows 95 uses 0e and 0f as the extended-INT13 equivalents of 06 and
11
05. For the problems this causes, see Possible data loss with LBA and
12
INT13 extensions. (Especially when going back and forth between MSDOS and
13
Windows 95, strange things may happen with a type 0e or 0f partition.)
14
Windows NT does not recognize the four W95 types 0b, 0c, 0e, 0f ( Win95
15
Partition Types Not Recognized by Windows NT). DRDOS 7.03 does not support
16
this type (but DRDOS 7.04 does).
Das Linux/Gnome Partitionierprogramm "gparted" ist übrigens besonders
schlau ;-( Es hat einen Dialog, in dem man "Markierungen/Flags"
einstellen kann. Schaltet man das LBA-Flag ein, wird der Partitionstyp
von 6 auf E umgestellt.
Hallo zusammen,
wollte mal was über den Bootloader schreiben den ich benutze:
Bootloader von Peter Dannegger
http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger
- Boot_168.hex in ATMega168 laden
- Fusebit auf "BOOTRST" und 512k stellen
- FBoot.exe ins Verzeichniss kopieren wo auch die avrcpm.hex ist.
- FBoot ausführen mit folgenden Parameter
oder Flash.bat
fboot /C2 /B9600 /Pavrcpm.hex
^ ^ ^
| | |
| | +- Hex-File
| +-------- Baudrate
+------------ Comport (1-4)
fboot funktioniert bei mir nur bis Win XP.
Erlaubter Comport von 1 bis 4
Der Bootloader hat eine automatische Baudratenerkennung und man kann
auch höhere Werte eingeben zb 38400
Tipp:
Mit dem FT232RL-Tool (MProg 3.5 Release) eine feste "USB Serial Number"
vergeben, somit bekommt man immer den gleichen ComPort zugewiesen auch
wenn sich der USB-Port ändert.
In der Systemsteuerung / Geräte-Manager den ComPort ändern auf z.B. 2
Gruß Egmont
Joe G. schrieb:> Für welche Taktfrequenz ist der Bootloader übersetzt?
Du fragt bestimmt wegen Baudrate... da ist das so das er sich das selbst
errechnet. Es ist also kein Problem wenn man seine Taktfrequenz ändert.
Bekommt von FBoot.exe Daten geschickt wo dann die Baudlänge ermittelt
wird.
Habe ich schon selber ausprobiert. 12MHz vom FT232 eingestellt
CP-M-Source neu übersetzt mit der Taktfrequenz und mit dem Bootloader
geladen.
In der FastLoad.H steht zwar bei mir 8Mhz drinn wird aber nur dafür
verwendet um ein BootDelay zu errechnen.
.equ XTAL = 8000000 ; 8MHz, not critical
.equ BootDelay = XTAL / 3 ; 0.33s
wichtig sind die Einstellungen in Bootload.asm
.equ STX_PORT = PORTB
.equ STX = PB1
.equ SRX_PORT = PORTB
.equ SRX = PB0
Was man noch beachten sollte:
-SD-Karte entfernen
-FBoot.exe starten
-CP/M Reset
Source vom Bootlade siehe Anhang
Ich hoffe ich habe deine Frage richtig verstanden bzw. beantwortet.
Egmont
@Alle
für Linux gibt es auch Software dafür...
Joe G. schrieb:> CT: 02 InitRes: 00 SPI_DISABLE> mmcRdSect SPI_CLK_FAST> mmcCMD: 11 00000000 <FF <FF <FF >51 .. 01>01 <FF <00 CMDRes: 00 <FF <FF> <FE <31 <33 <FF SPI_DISABLE RdSectRes: 00
Hier ist das Lesekommando ok. Nach dem erfolgreichen Senden des Befehls
(CMDRes = 0), wird auf das Data-Token (0xFE) gewartet. Danach kommen die
eigentlichen Daten, die man hier nicht sieht.
> Assuming CP/M image at: 000, size: 8192KB.> Partinit done.> mmcRdSect SPI_CLK_FAST> mmcCMD: 11 00000000 <FF <FF <FF >51 .. 01>01 <FF <00 CMDRes: 00 <FF <FÆ
Hier ist der gleiche Lesebefehl (gleicher Sektor). Aber ein Abbruch,
bevor das Data Token kommt. Da man die Karte wohl ausschließen kann,
kann ich mir nur noch vorstellen, daß ein Interrupt Harakiri macht, oder
der Watchdog zuschlägt. Oder Stromversorgung, Stör/Erd-strahlen...
So siehts bei mir aus:
Leo C. schrieb:> Da man die Karte wohl ausschließen kann,> kann ich mir nur noch vorstellen, daß ein Interrupt Harakiri macht, oder> der Watchdog zuschlägt. Oder Stromversorgung, Stör/Erd-strahlen...
Der Watchdog ist abgeschaltet. Der Mega8 zeigt den gleichen Fehler. Für
heute tippe ich mal auf Erdstrahlen. Morgen werde ich mal ein schnelles
Oszi an die Stromversorgung in Nähe der Karte hängen.
Nachtrag:
Ich habe gerade alles nochmal für die alte 4 Bit Variante übersetzt und
- gleicher Fehler. Ein Hardwarefehler ist damit wohl auzuschließen.
CPM on an AVR, v2.0
Testing RAM: fill...wait...reread...
Initing mmc...
Assuming
NEUSTART
CPM on an AVR, v2.0
Testing RAM: fill...wait...reread...
Initing mmc...
Assuming
Joe G. schrieb:> Ich habe gerade alles nochmal für die alte 4 Bit Variante übersetzt und> - gleicher Fehler. Ein Hardwarefehler ist damit wohl auzuschließen.
Mit oder ohne Bootloader?
Ansonsten könnte die Software bei Dir noch anders übersetzt werden, als
bei mir.
Frank Zoll schrieb:> Ich hab soeben das erste mal lesend auf ein Diskimage auf meiner> FAT16 Partition zugreifen können. Das anzeigen des Directorys und der> Programmstart funktionieren.
Wie muss den die FAT16 Partition aussehen
Type (06) , Größe(960MB), IMG-Dateiname (cpm_d.img), IMG-Dateigröße.
Bei mir erscheint nur "fat16 scanning" aber keine Laufwerk.
Der Werte in der Klammer sind die Einstellung so wie sie bei mir sind.
Die SD-Karte hat vier Partitionen:
1. FAT16 06 960MB
2. CP/M 52 8MB aktiv
3. CP/M 52 8MB
4. CP/M 52 8MB
Gruß Egmont
Egmont schrieb:> Wie muss den die FAT16 Partition aussehen> Type (06) , Größe(960MB), IMG-Dateiname (cpm_d.img), IMG-Dateigröße.>> Bei mir erscheint nur "fat16 scanning" aber keine Laufwerk.> Der Werte in der Klammer sind die Einstellung so wie sie bei mir sind.>> Die SD-Karte hat vier Partitionen:> 1. FAT16 06 960MB
Der Typ der Partition sollte 0E sein (FAT16 / LBA-Modus). Ich weiss
nicht genau, ob es auch mit 06er Partitionen funktionieren würde. Das
habe ich noch nicht ausprobiert. Das Diskimage an sich war fast richtig.
Es müsste 'CPMDSK_D.IMG' heissen. Wobei die Suche nach den Images immer
bei A beginnt und mit Z aufhört. Die CP/M Partitionen werden immer
zuerst an den Anfang der internen Partitionstabelle gepackt. Und
Diskimages landen immer dahinter. Die Imagedatei an sich sollte
mindestens 256256 Bytes groß sein. Ist sie das noch nicht, so muss man
sie erstmal mit Nullen auffüllen. Macht man das nicht, würde ein
schreibversuch hinter das Ende der Datei das Dateisystem evtl.
beschädigen, wobei ich versuche diesen Fehler zu erkennen und abzufangen
! Ich habe es nur noch nicht getestet. Daher sind die Schreibroutinen
derzeit in der SVN Version auch noch auskommentiert. Die Routinen können
eine zu kleine Datei nicht vergrößern. Im moment sind Leo und ich dabei
die Routinen zu testen und noch Fehler beim schreibzugriff zu
beseitigen. Hoffe es wird nicht mehr lange dauern, bis wir aquch das im
Griff haben.
Freundliche Grüße
Frank
Ah, da fällt mir gerad noch was ein.
Das Booten von einer FAT16 Partition dürfte noch nicht funktionieren.
Das ganz liegt an der Art wie das Startup in der Datei init.asm codiert
wurde.
1
; Read first sector of first CP/M partition (ipl)
2
lds xl,hostparttbl+1
3
lds xh,hostparttbl+2
4
lds yl,hostparttbl+3
5
lds yh,hostparttbl+4
6
rcall mmcReadSect
Dieses Codestück muss noch angepasst werden, da bei einem Diskimage in
der hoastpartbl an der Position 1-4 nicht der 1. Sektor der Datei
abgelegt ist, sondern die Nummer des 1. Clusters der Datei. Hier greift
der bestehende Lesezugriff an die Falsche stelle der SD- Card. Ich werde
die Stelle bei gelegenheit mal anpassen, damit man auch ganz ohne CP/M
Partitionen ein System booten kann.
Grüße
Frank
Frank Zoll schrieb:> Es müsste 'CPMDSK_D.IMG' heissen. Wobei die Suche nach den Images immer> bei A beginnt und mit Z aufhört.
A - P würde genügen, da CP/M maximal 16 Laufwerke verwalten kann.
Darüber hinaus vermute ich, daß gerade hier noch
Optimierungsmöglichkeiten bestehen. Der Warmboot mit (nur) einem
FAT16-Image dauert deutlich länger, als nur mit Partitionen. Mit
eingeschalteten Debug-Messages sieht man eine deutliche Pause, nachdem
alle FAT-Daten gelesen worden sind. Beim Lesen und Schreiben von
CP/M-Dateien ist aber subjektiv kein Unterschied zum nackten
Part-Treiber. Das FAT16-Dateisystem an sich ist also ausreichend
schnell.
> Die Imagedatei an sich sollte> mindestens 256256 Bytes groß sein. Ist sie das noch nicht, so muss man> sie erstmal mit Nullen auffüllen. Macht man das nicht, würde ein> schreibversuch hinter das Ende der Datei das Dateisystem evtl.> beschädigen, wobei ich versuche diesen Fehler zu erkennen und abzufangen> ! Ich habe es nur noch nicht getestet.
Aber ich jetzt. :-)
Der FAT16-Treiber weigert sich beharrlich, über das Dateiende hinaus zu
lesen und zu schreiben.
> Daher sind die Schreibroutinen> derzeit in der SVN Version auch noch auskommentiert.
Jetzt nicht mehr. :-)
> Die Routinen können> eine zu kleine Datei nicht vergrößern. Im moment sind Leo und ich dabei> die Routinen zu testen und noch Fehler beim schreibzugriff zu> beseitigen. Hoffe es wird nicht mehr lange dauern, bis wir aquch das im> Griff haben.
Hier gibts die FAT16 Testversion:
http://cloudbase.homelinux.net/viewvc/avr-cpm/tags/2.0-fat16/
oder
http://cloudbase.homelinux.net/svn/avr-cpm/tags/2.0-fat16/
Es fehlt noch etwas Feinschliff und die Tests waren bisher noch nicht
sehr umfangreich. Mmn sollte es aber mindesten so gut funktionieren, als
der bisherige Code.
@Frank,
tolles Stück Arbeit.
Halloe.
Das Scannen nach den Image- Dateien ist wirklich nicht gerade schön. Bis
alle 26 Buchstaben durchprobiert wurden müssten bei 512 Directory-
Einträgen und 16 Einträgen pro Sektor insgesammt 832 Sektorlesezugriffe
erfolgen. Pro Buchstabe der gesucht werden soll werden alle 32
Direktory- Sektoren je einmal gelesen. Daher dauert es auch so lange.
Dafür bekommt man halt die Laufwerke immer in die richtige Reihenfolge
in der Partitionstabelle, egal in welcher Reihenfolge sie gerade auf der
SD- Card im Verzeichniss liegen. Hier würde ich vorschlagen, das wir
immer mit A anfangen und die Anzahl der Buchstaben auf die aktuelle
Größe der Partitionstabelle begrenzen. Mehr als diese Menge an Images
können eh nicht verwaltet werden. Man ist dann halt dann gezwungen mit A
anzufangen und die Images vorlaufend zu benennen, aber das sollte doch
nichts ausmachen oder ?
@Leo
Danke für die Hilfe bei den Tests.
Grüße
Frank
Frank Zoll schrieb:> Man ist dann halt dann gezwungen mit A> anzufangen und die Images vorlaufend zu benennen, aber das sollte doch> nichts ausmachen oder ?
Sicher nicht (imho). Der größte Teil der Dateinamen ist ja sowieso
hartcodiert.
Noch etwas anderes:
Wie wichtig ist denn noch, daß das Programm noch auf Atmega8 und
Atmega88 läuft?
Im Moment paßt nur noch die 4-Bit Version in den Speicher. Natürlich
ohne FAT16. Die 8-Bit Version würde man noch mit etwas
Geschwindigkeitseinbuße hinkriegen.
Frank Zoll schrieb:> Das Booten von einer FAT16 Partition dürfte noch nicht funktionieren.
@alle, die auf ihren SD-Karten nur FAT-Paritionen haben (wollen):
Das hat Frank inzwischen geändert. Man kann jetzt auch von einer
Image-Datei im FAT16-Filesystem booten. Außerdem werden jetzt zwei
FAT16-Partitionstypen erkannt. 0E und 06.
Das Update gibts hier:
http://cloudbase.homelinux.net/viewvc/avr-cpm/tags/2.0-fat16-1
Leo C. schrieb:> @alle, die auf ihren SD-Karten nur FAT-Paritionen haben (wollen):
Und jetzt auch an:
@alle, die mehr als ein File-Image auf ihrer FAT-Parition haben wollen:
Leider hatte sich ein kleiner Fehler eingeschlichen, der verhinderte,
daß mehr als eine Datei auf der FAT16-Partition erkannt wurde.
Neues Update:
http://cloudbase.homelinux.net/viewvc/avr-cpm/tags/2.0-fat16-2/
ist hier nicht noch ein Zahlendreher drin
-------[ Config.inc ]----------------------
#define K 1024
#define M 1204*K <-- Zahlendreher
#define RAMSIZE 4*M*4 * 2 /* 2 chips 4Mx4 */
-------------------------------------------
Gruß Egmont
Egmont schrieb:> ist hier nicht noch ein Zahlendreher drin
Oh, doch.
> -------[ Config.inc ]----------------------> #define K 1024> #define M 1204*K <-- Zahlendreher>> #define RAMSIZE 4*M*4 * 2 /* 2 chips 4Mx4 */> -------------------------------------------
Das steht da schon ziemlich lange drin, und ist wohl nur deshalb nicht
aufgefallen, weil es (bisher) nirgens benutzt wird.
Danke für den Hinweis.
Halloe.
Da der FAT16- Treiber nun bereits recht gut läuft, hätte ich evtl. ein
wenig Zeit über bei der Programmierung des VGA- Teils der Platine mit zu
helfen. Gibt es hier schon etwas, auf das man aufbauen könnte ? Bzw. ist
schon jemand dabei etwas vorzubereinten und braucht ggf. noch Hilfe ?
Grüße
Frank
p.s. Ich habe das TotalCommander Plugin das Leo gefunden hat mal kurz
angetestet. Wenn man die diskdefs passend erweitert, kann man damit auch
problemlos auf die Imagedateien zugreifen, die zu unserem netten kleinen
Projekt hier gehören. Es muss also nicht unbedingt mit einem Laufwerk
gearbeitet werden. Wer so wie ich GUI- Verwöhnt ist, dem kann ich nur
den Tipp geben sich mal das Tutorial auf der Homepage anzuschauen. Damit
klapts auf anhieb :-)
Guten Abend,
nach dem Erwerb des 4-Bit-Systems von Peter Sieg und dem Studium dieses
Forum-Threads war ich so begeistert, dass ich ihm auch die Platine der
8-Bit-Version abgekauft habe.
Jetzt bin ich beim Zusammenstellen der Bauteile gemäß Schaltplan und
Stückliste. Dabei habe ich gleich die Frage, wie man an den 13-poligen
SD-Karten-Sockel kommt? Die Standard-Lieferanten wie Reichelt, Segor
oder Conrad haben den nicht!
Außerdem verstehe ich die Stromversorgungsschaltung auf Seite 2 des
Schaltplans nicht. Wozu ist der Gleichrichter und der 5V
Spannungswandler notwendig, wenn man doch schon mit einem 5V
Steckernetzteil arbeitet? Auch die Funktion des 25MHz-Quarzoszillators
und des separaten 20 MHz-Quarzes sind mir nicht ganz klar. Welcher Quarz
macht was?
Gruß Siggi
aus dem SVN-Archiv
141_avr-cpm-trunk.tar.gz
fehlt eine Datei "heap.asm"
siehe aufruf in Datei
-----------[ avrcpm.asm ]----------
...
.include "heap.asm"
...
-----------------------------------
würde gerne diese Version auch mal testen
Gruß Egmont
Siggi M. schrieb:> wie man an den 13-poligen> SD-Karten-Sockel kommt?
Der wurde bei CSD bestellt... ca. 3 Euro
Bei mehr als 5 IMG-Dateien bekomme ich folgende Fehlermeldung
Version 136 vom SVN-Server.
Auf D: kann ich noch zugreifen, bei E: --> Kill
---------------------------------------------------------
CPM on an AVR, v2.0
Testing RAM: fill...wait...reread...
Initing mmc...
A:FAT16 File-Image at: 002, size: 250KB.
B:FAT16 File-Image at: 018, size: 250KB.
C:FAT16 File-Image at: 034, size: 250KB.
D:FAT16 File-Image at: 050, size: 250KB.
E:FAT16 File-Image at: 066, size: 250KB.
Partinit done.
Ok, CPU is live!
ipl
62k cp/m vers 2.2
A>d:
D>dir
D: TTT2 COM : OTHELLO COM : MMIND COM : ED COM
D: LOAD COM : STONE COM : PIP COM : STAT COM
D: SUBMIT COM : XSUB COM
D>e:
Bdos Err On E: Select
---------------------------------------------------------
Leo C. schrieb:> A - P würde genügen, da CP/M maximal 16 Laufwerke verwalten kann.
Gruß Egmont
Egmont schrieb:> aus dem SVN-Archiv> 141_avr-cpm-trunk.tar.gz> fehlt eine Datei "heap.asm"
Ups, stimmt(e).
Die Datei ist jetzt drin.
> würde gerne diese Version auch mal testen
Ist im Moment aber etwas gewagt. Du brauchst dann auf jeden Fall auch
das BIOS (bios.mac) aus dem cpm-Verzeichnis.
Kommentare und Patches dazu sind natürlich willkommen.
Egmont schrieb:> Bei mehr als 5 IMG-Dateien bekomme ich folgende Fehlermeldung> Version 136 vom SVN-Server.> Bdos Err On E: Select
Die Anzahl Laufwerke ist an zwei Stellen begrenzt:
1.) dsk_fsys.asm:
.equ MAXDISKS = 6 ;Max number of Disks (partitions)
2.) Z.Zt. noch im BIOS auf 4 Laufwerke.
Wenn Du MAXDISKS noch höher setzen willst, mußt Du den RAM-Verbrauch im
Auge behalten. Ggf. kann man die UART-Buffer halbieren.
Im Anhang ist ein BIOS, das bis 8 Laufwerke gehen sollte. In dem
Zip-Archiv sind auch die Quellen und die fertigen Binärdateien
'bios.bin', 'cpm.bin' und ein komplettes 'diskimage'.
Leider habe ich es z.Zt. nicht besser.
Halloe.
Ich habe mir in der letzten Nacht mal den VGA- Teil der aktuellen
Platine angeschaut und das oben verlinkte Beispiel für das
VGA-Betriebssystem genau unter die Lupe genommen.
Mitlerweile habe ich den Code der Vorlage aufgeräumt und so angepasst,
das er sich auch für den 328er Übersetzen lässt. Nun ist das SRAM
erstmal zu 197% gefüllt, wegen des zu großen Framebuffers. Als nächstes
werde ich den Puffer so weit verkleinern, das er gerade noch so eben in
das SRAM passt.
Findet sich hier evtl. jemand der lust hat einen spezeillen, neuen,
Zeichensatz zu basteln ? Wir brauchen einen Zeichensatz von 6 Pixel
breite verpackt in jeweils 1 Byte pro Zeile. Die höhe weiss ich noch
nicht genau, weil ich die endgültige Größe des Framebuffers noch nicht
ausprobiert habe. Bei den oben angedachten 25 Zeilen wäre die Höhe für
den Zeichensatz 16 Pixel(Zeilen). Ich plane jedoch möglichst viele
Zeilen aufs Display zu quetschen, da würden dann ggf. noch ein paar
Zeilen im zeichensatz wieder wegfallen.
Die 80 Zeichen pro Zeile scheinen machbar zu sein, unschön ist nur das
zwischen jedem Zeichen 2 spalten dunkel bleiben, die wir nicht werden
ansteuern können. Damit läßt sich dann wohl leider mit dem neuen
Zeichensatz keine durchgehende horizontale Line erreichen. Umgehen läßt
sich dieses Problem nicht so einfach, da der Port an dem das
Schieberegister hängt nur 6 der eigentlich im Original vorgesehenen 8
Bits liefern kann. Die Routine, die die Zeihen ausgiebt, hat leider
keine reserven mehr um da noch Befehle hinzunehmen zu können, die die
fehlenden 2 Bits irgendwie ersetzen könnten. Vieleicht hat hier ja
jemand noch eine super Idee ?
Kennt sich hier evtl. jemand mit den CP/M Terminals aus und kann mir da
Helfen, heraus zu bekommen was so ein Terminal alles können muss außer
bloß ein par Zeichen anzuzeigen ? Da scheint im Originalcode noch eine
große Lücke zu klaffen, die wir noch füllen müssen.
Grüße
Frank
Siggi M. schrieb:> Wozu ist der Gleichrichter und der 5V> Spannungswandler notwendig, wenn man doch schon mit einem 5V> Steckernetzteil arbeitet? Auch die Funktion des 25MHz-Quarzoszillators> und des separaten 20 MHz-Quarzes sind mir nicht ganz klar. Welcher Quarz> macht was?
- SD-Karten-Sockel Type SCDA5A0201, Best.Nr.: 020115
- Bei einem 5V Steckernetzteil entfällt natürlich der Gleichrichter und
der 5V Regler
- der 25MHz Quarzoszillator auf der VGA-Platine muß genau diesen Wert
haben, da davon der Pixeltakt abgeleitet wird.
- Das AVR-CP/M System benötigt auch einen Takt. Dieser kann durch den
Oszillator (25MHZ) oder einen externen Quarz (hier als Bsp. 20MHZ)
erzeugt werden. Da das Gesamtsystem noch sehr experimentell ist, die
vielen Varianten. Eine Möglichkeit ist also 1 x 25MHZ auf der AVR-CP/M
Platine. Damit ist auch gleich der VGA Takt erzeugt. Eine weitere
Möglichkeit 25MHz auf der VGA-Seite (siehe oben) und z.B. 30 MHz
AVR-CP/M.
Noch Fragen?
Joe
Frank Zoll schrieb:> Kennt sich hier evtl. jemand mit den CP/M Terminals aus und kann mir da> Helfen, heraus zu bekommen was so ein Terminal alles können muss außer> bloß ein par Zeichen anzuzeigen ? Da scheint im Originalcode noch eine> große Lücke zu klaffen, die wir noch füllen müssen.
Unbedingt:
- Clear screen
- Cursor positionieren (x,y)
- ein Attribut (eins aus:highlight, dim, inverse, underline, blink
(igit))
Gut:
- Clear to end of line
- Delete line (nachfolgende zeilen rutschen hoch)
- Insert Line (Zeilen unterhalb der Curserposition eine Zeile nach
unten)
- mehr Attribute
ANSI oder VT100 war zu CP/Ms Hochzeiten nicht verbreitet. Ist
wahrscheinlich auch etwas aufwendig zu implementieren.
Arbeitspferd war das Lear Siegler ADM-3A und viele Kompatible. Praktisch
jedes CP/M-Programm mit Terminalsteuerung unterstützt das.
http://www.tentacle.franken.de/adm3a/
Das scheint aber wirklich nur die unbedingt notwendigen Funktionen zu
haben.
Das nächst bessere, und auch sehr weit verbreitet, war dann Televideo
920 oder so.
Mein MC-Terminal, daß seit einigen Wochen wieder hier rumliegt und auf
Inbetriebnahme wartet, ist auch Televideo-kompatiebel.
Und weils so schön ist, in alten Erinnerungen zu schwelgen, im Anhang
ein Bild von meiner ersten Terminal-Karte (Elektor, 64 Zeichen x 16
Zeilen, max 1200 Baud und 120ms für den clear screen)
Frank Zoll schrieb:> Die 80 Zeichen pro Zeile scheinen machbar zu sein, unschön ist nur das> zwischen jedem Zeichen 2 spalten dunkel bleiben, die wir nicht werden> ansteuern können.
War leider mit dem ATmega328 nicht anders lösbar.
> Die Routine, die die Zeihen ausgiebt, hat leider> keine reserven mehr um da noch Befehle hinzunehmen zu können, die die> fehlenden 2 Bits irgendwie ersetzen könnten. Vieleicht hat hier ja> jemand noch eine super Idee ?
Vorschlag zur Ausgabe einer durchgehenden Linie.
PB4 und PB5 an das Schieberegister und vor der Zeilenausgabe die beiden
Bits gesetzt. Zwischen Backporch und Frontporch ist ja noch etwas Platz
für den Code.
Joe
Leo C. schrieb:
Vergessen:
> Unbedingt:> - Clear screen
- Cursor links (back space)
> - Cursor positionieren (x,y)> - ein Attribut (eins aus:highlight, dim, inverse, underline, blink)> Gut:> - Clear to end of line> - Delete line (nachfolgende zeilen rutschen hoch)> - Insert Line (Zeilen unterhalb der Curserposition eine Zeile nach> unten)
- Erase to end of screen
- Insert Character
- Delete Character
- Cursor right, up, down
> - mehr Attribute
Joe G. schrieb:> mmcCMD: 11 00017A00 .. 01 CMDRes: 00> A:FAT16 File-Image at: 002, size: 081KB.> Partinit done.> mmcCMD: 11 00017C00 .. 01 CMDRes: 00>> CPM on an AVR, v2.0> Testing RAM: fill...wait...reread...> Initing mmc...
Immerhin werden eine ganze Anzahl Sektoren fehlerfrei gelesen. Es liegt
wohl eher nicht an der Karte oder am mmc-Treiber.
Kannst Du mal das komplette Verzeichnis, in dem Du die Software
übersetzt hast, zusammen packen und an mich schicken?
Leo C. schrieb:> Kannst Du mal das komplette Verzeichnis, in dem Du die Software> übersetzt hast, zusammen packen und an mich schicken?
Ist unterwegs...
Joe G. schrieb:> Leo C. schrieb:>> Kannst Du mal das komplette Verzeichnis, in dem Du die Software>> übersetzt hast, zusammen packen und an mich schicken?>> Ist unterwegs...
Ich habs schon gesehen. Bis auf CPU, CPU-Frequenz und die Debugschalter
in 'config.asm' ist alles identisch zu meinem Stand hier, bzw zum
2.0-fat16-2 im SVN.
BIOS hatten wir ja schon ausgeschlossen.
Mir fällt nichts mehr ein.
Joe G. schrieb:> Leo C. schrieb:>> Mir fällt nichts mehr ein.>> Dann bleibt ja nur noch die Hardware. Ich mach mich mal auf die Suche.
Inzwischen habe ich auch mal mit Deinen Schaltern übersetzt. Hex-Files
sind auch identisch. (In Deiner 'AvrBuild.bat' ist ein komischer
Schalter für den Assembler gestzt. Ich wollte ausschließen, daß der
einen Unterschied macht.)
Vielleicht hat der Prozessor vom Übertakten einen Dachschaden?
Hm,
mitlerweile habe ich den VGA-Code ans laufen bekommen. Zufriedenheit
sieht aber anders aus. Ich bekomme auf meinem alten Monitor einen klaren
Sync bei 640*400 @74Hz. Aber von meinem Beispieltext im Framebuffer ist
nichts zu sehen. :-(
Grüße
Frank
@alle
Einen Schaltungs- / Layoutfehler habe ich gefunden.
der Pegelwandler IC2 (Pin 14) sollte mit seiner Spannungsversorgung an
3.3V liegen und nicht an 5V! Bitte im Layout ändern.
Leo C. schrieb:> Vielleicht hat der Prozessor vom Übertakten einen Dachschaden?
Nein, leider auch nicht.
Frank Zoll schrieb:> Aber von meinem Beispieltext im Framebuffer ist nichts zu sehen. :-(
Hast du eines von den 74AC08 Gattern (IC7) auch auf High gesetzt?
Ansonsten schiebt das Schieberegister nichts auf die VGA-Buchse.
Joe G. schrieb:> Frank Zoll schrieb:>> Aber von meinem Beispieltext im Framebuffer ist nichts zu sehen. :-(>> Hast du eines von den 74AC08 Gattern (IC7) auch auf High gesetzt?> Ansonsten schiebt das Schieberegister nichts auf die VGA-Buchse.
Halloe.
Ich denke, das müsste gerad schön bunt aussehen. Hier das Setup für die
Fordergrundfarbe.
Das Setup wird im moment unmittelbar vor der Ausgabeschleife aufgebaut.
Alles was nicht unbedingt für das Terminal gerbaucht wurde hab ich
mitlerweile raus geworfen. Im moment versuche ich gerade statt des Fonts
ein einfaches 10101010 Streifenmuster zu erzeugen. Auch das tut leider
nicht. Ich werd mir wohl mal die Hardeware unter der Lupe anschauen
müssen, evtl. hab ich da noch nen Bug drinn :-)
1
// farbe einstellen
2
// Pin 5-7 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:
Halloe.
Habe die letzten blödden Fehler endlich gefunden. Hier mal zwei Bilder
des aktuellen Standes :-)
Die VGA-Ausgabe läuft. Es ist gerade so eben Platz für 80 Zeichen pro
Zeile und insgesammt 22 Zeilen.
SRAM ist zu 96,4% gefüllt. Bissel was brauche ich noch für den Stack.
Nun brauchen wir einen Zeichensatz wie oben beschrieben. (6 Pixel Breit,
18 Pixel Hoch) Je ein Byte pro Zeile. Als nächstes muss ich die
Terminalverbindung reaktivieren und mich um einen Software UART für die
Tastatur kümmern, die ich abschalten musste weil der 328er nur 1 UART
zur Verfügung hat.
Grüße
Frank
p.s. Mit Attributen (Blinken,Invers, Durchgestrichen etc.) pro Zeichen,
das wird nix mehr, das RAM ist voll....
Halloe.
Ich habs geschaft, 24 Zeilen ins Ram rein zu quetschen. Damit wären wir
gerad noch konform mit den oben genannten Standard- Terminals. Ich habe
nur noch keine Idee was wir mit den Attribiuten machen. Da die Terminals
eigentlich alle mit 7 bit / Zeichen arbeiten, hätten wir noch 1 bit
über. Dies Bit könnten wir zum Beispiel nutzen um sowas wie einen
Inversen- Modus zu unterstützen. Bei 24 zeilen ist das Ram fast voll und
ich habe noch nicht die Routinen für die Tastatur fertig, daher möcht
ich mal nicht versprechen das ich evtl. wieder Zeilen rausstreichen muss
um das ganze Lauffähig zu halten.
Grüße
Frank
Ich habe mal meinen aktuellen Softwarestand hochgeladen (trunk).
Achtung: Diese Version bitte nicht mit Disk Images testen, die wichtige
Daten enthalten. Es könnte sein, daß unter bestimmten Bedingungen ein
falscher Sektor geschrieben wird.
Ich habe die maximale FAT16-Image-Dateigröße und die maximale
CP/M-Partitionsgröße auf 32MB begrenzt. Dh., CP/M-Dateisysteme können
maximal 32MB groß werden. Sieht hier jemand ein Problem?
Das Programm kann jetzt verschiedene Diskformate erkennen und einbinden.
Im Moment sind das die Images vom MyZ80 Emulator und von YAZE-(AG). In
der YAZE-AG Distrib sind verschiedene Diskimages (*.ydsk-Dateien), die
fast alle unterschiedliche Größen haben.
http://www.mathematik.uni-ulm.de/users/ag/yaze/
Diese Formate können auch mit den cpmtools verarbeitet werden.
Optimal sind aber weder MyZ80 noch das YAZE-Format. Beide haben einen
Header, der nicht der physikalischen Sektorgröße der Speicherkarten
entspricht (MyZ80 256 Byte und YAZE 128 Byte). Das kostet Performance,
weil die CP/M Datenblöcke dann immer mitten im Sektor beginnen und
enden, und der Teil davor, bzw. danach auch immer gelesen, bzw,
geschrieben werden muß.
Für unser System würde ich ein Format mit einem 1 Sektor (512 Byte)
großen Header bevorzugen. Das ließe sich mit der jetzt vorhandenen
Software verwenden.
Da aber Header unbeliebt zu sein scheinen ;), könnte man auch noch was
mit fest vorgegebenen Formatgrößen realisieren. Die Software dazu ist im
Prinzip auch vorhanden. Frank hat mir dazu schon den Vorschlag
geschickt, das Format über den Dateinamen zu bestimmen. Das geht auch,
allerdings nur mit FAT16 und natürlich nicht mit direkten Partitionen.
Eine andere (oder zusätzliche) Möglichkeit wäre, einige
Laufwerksbuchstaben (z.B. M-P) für feste Formate zu reservieren. Dazu
müßte man sich aber auf ein bis maximal 2 Formate einigen.
Je größer die Disk ist, und vor allem, je mehr Directory-Einträge sie
hat, um so langsamer wird der Zugriff. Große Disks mit kleinen
Directories machen aber keinen Sinn.
In der angehängten Zip-Datei ist ein leeres MyZ80 Image. Die Datei wird
beim Auspacken 8MB groß.
In den nächsten Tagen möchte ich das ganze nochmal überarbeiten (und das
Chaos etwas aufräumen). Inzwischen ist mir noch eine deutliche
Verbesserung zu der Schnittstelle zum 8080 BIOS-Teil eingefallen.
Eine andere Baustelle ist noch das Verhalten bei Diskwechsel mit und
ohne Warmstart. Verschiedene Softwarestände verhalten sich inzwischen
unterschiedlich, und mir ist noch nicht ganz klar wie es richtig geht.
Im Moment muß nach Ziehen und Stecken der Karte ein Warmstart erfolgen,
damit CP/M wieder auf die Karte zugreifen kann.
Wenn man allerdings die Karte immer automatisch neu initialisiert, wenn
sie gewechselt wurde, besteht die Gefahr, das Daten auf die falsche
Karte geschrieben werden.
Bitte probiert das mal aus und macht Vorschläge.
Frank Zoll schrieb:> Ich habs geschaft, 24 Zeilen ins Ram rein zu quetschen.
Super Frank!
Gab es noch was an der Hardware oder lag es an der Software?
Joe
Halloe
Die Hardware sowohl von der CP/M Emulatorseite als auch auf der VGA-
Seite läuft gänzlich ohne Lötpatches stabil. Die VGA- Seite habe ich mit
25Mhz wie gefordert übertacktet. Die CP/M Seite läuft auf 20 Mhz, hier
habe ich keinen Übertacktungsversuch gemacht. Auf VGA- Seite habe ich
nur einen blöden Softwarefehler gehabt. Mitlerweile läuft auch schon die
einfache Textausgabe über UART von der CP/M Seite aus. Das Keyboard habe
ich noch nicht am laufen und der Font ist auch noch nicht fertig. Die
Anzeige sieht wegen des falschen Fonts noch ziemlich kaputt aus, aber
man kann die Zeichen mit gut will schon erkennen.
Grüße
Frank
Ich habe mal hier meine aktuelle "Spielversion" angehangen. Das Hex-File
ist für den 328er mit 25Mhz Quarz compiliert. Die UART- Geschwindigkeit
ist 9600 Baud 8N1. Hier muss man auf der CP/M Seite von 36800 Baud noch
eben runtergelen, sonst klappt die Anzeige nicht. :-)
Hallo,
wo bekomme ich zum übersetzen von ipl.asm und bios.asm die Datei
z80asm.exe her. Googeln brachte bei mir kein Erfolg.
Ein Link oder eine Datei währe nicht schlecht (für Windows).
Was ist mit bios.mac, für was wird die benötigt....anderer
Compiler/System ?
Gruß Egmont
* ipl.asm (läd das CP/M von der 'Diskette' vom track 0 sector 2 bis track 1 sector 26)
4
* bios.asm
5
* cpm.sys
6
7
Obige 8080/Z80 Assemblerdateien lassen sich unter Linux hiermit: http://www.nongnu.org/z80asm/ und unter Windows hiermit (end Statement auskommentieren): http://www.tni.nl/products/tniasm.html übersetzen. Unix-Tools für Windows, u.a. DD findet ihr hier: http://sourceforge.net/projects/unxutils/files/unxutils/current/UnxUtils.zip/download
Egmont schrieb:> Hallo,> wo bekomme ich zum übersetzen von ipl.asm und bios.asm die Datei> z80asm.exe her. Googeln brachte bei mir kein Erfolg.> Ein Link oder eine Datei währe nicht schlecht (für Windows).> Was ist mit bios.mac, für was wird die benötigt....anderer> Compiler/System ?
bios.asm ist zu alt. Aktuell ist bios.mac. Dazu gehören auch die beiden
.lib Dateien.
bios.mac und ipl.mac können mit M80 (MACRO-80) von Microsoft auf Deinem
CP/M-System übersetzt werden. :)
Wahrscheinlich gibts kompatible Crossassembler, die unter Windows
laufen, aber ich habe noch keinen gefunden.
Es gibt auch CP/M-Emulatoren, die einen Befehl abarbeiten, der auf der
Befehlszeile übergeben wird. "zxcc" ist so ein Ding, und funktioniert
bei mir unter Linux wunderbar. Laut der Homepage sollte es aber auch
unter DOS (Windows) laufen:
http://www.seasip.demon.co.uk/Unix/Zxcc/
Wenn zxcc richtig installiert ist, kann man das BIOS so assemblieren und
linken:
1
$ zxcc m80 -=bios.mac
2
$ zxcc l80 -bios.rel,bios.bin/N/E
Das Makefile erledigt diese Schritte automatisch.
Für Windows habe ich noch eine eine Alternative gefunden: "m80l80pc.zip"
Mit Google leicht zu finden.
Wenn Die Dateien aus dem Paket im Pfad zu finden sind, können M80 und
L80 direkt auf der Befehlszeile gestartet werden. Das ganze ist
offensichtlich mit dem CP/M-Emulator "22nice" gebaut, der ebenfalls
leicht zu finden ist, und vielleicht auch sonst einen Versuch wert wäre.
Im m80l80pc.zip Paket ist auch das M80/L80 Handbuch als Textdatei. Sonst
habe ich immer nur gescannte Handbücher als PDF gefunden.
Meine Bitte an die Windowsbenutzer wäre, daß mal jemand die 2 Varianten
ausprobiert. Wenn m80l80pc die bessere Alternative ist, würde ich das
mit ins Makefile aufnehmen. Das aktuelle Makefile mit zxcc sollte auch
unter Windows ohne Änderung laufen.
@Leo C.
Danke für die Info! Ich hab die V91 mal reaktiviert. Das nun auftretende
Fehlerbild ist fast der Supergau. Hier ein Logauszug:
CPM on an AVR, v1.0
Testing RAM: fill...wait...reread...
Initing mmc...MMC: <--0A, -->FF
MMC: <--09, -->FF
MMC: <--08, -->FF
MMC: <--07, -->FF
…
MMC: <--FF, -->AA
MMC: <--FF, -->40
MMC: <--FF, -->E3
MMC: <--FF, -->FF
CP/M partition at: 8097, size: 4144KB.
CP/M partition at: 16385, size: 7808KB.
Partinit done.MMC: <--FF, -->FF
MMC: <--51, -->FF
MMC: <--00, -->FF
MMC: <--3F, -->FF
…
MMC: <--FF, -->E3
MMC: <--FF, -->1F
MMC: <--FF, -->3E
MMC: <--FF, -->FF
Ok, CPU is live!
ipl
DISK I/O: Invalid Function code: 01
Der letzte Fehler ist klar - ist das aktuelle BIOS auf der Karte. Aber
hier wird die Karte richtig und vollständig gelesen. Fragen über
Fragen...
Joe
Nachtrag:
Ich habe auch nochmal das alte BIOS übersetzt und auf die Karte
geschrieben.
CPM on an AVR, v1.0
Testing RAM: fill...wait...reread...
Initing mmc...
CP/M partition at: 000, size: 8192KB.
Partinit done.
Ok, CPU is live!
ipl
62k cp/m vers 2.2
A>dir
A: ASM COM : DDT COM : DUMP COM : ED COM
A: LOAD COM : PIP COM : STAT COM : SUBMIT COM
A: T COM : TIMER COM : ZORK1 COM : ZORK1 DAT
A: ZAP80 COM : MBASIC COM : ELIZA BAS
Das ist der Ergebnis der "neuen Hardware" mit der alten Software.
Joe G. schrieb:> CP/M partition at: 8097, size: 4144KB.> CP/M partition at: 16385, size: 7808KB.> Partinit done.MMC: <--FF, -->FF> MMC: <--51, -->FF> MMC: <--00, -->FF> MMC: <--3F, -->FF> …> MMC: <--FF, -->E3> MMC: <--FF, -->1F> MMC: <--FF, -->3E> MMC: <--FF, -->FF>> Ok, CPU is live!> ipl> DISK I/O: Invalid Function code: 01>> Der letzte Fehler ist klar - ist das aktuelle BIOS auf der Karte.
Wie meinst Du das? Der Code sieht eher nach einem zu alten Bios aus.
Das ursprüngliche BIOS hatte hier die Codes 01 und 02. Ich habe es
geändert auf Codes >= 40. Der "Code" könnte aber auch dadurch zustande
kommen, daß das BIOS nicht vollständig geladen wird.
> Aber> hier wird die Karte richtig und vollständig gelesen.
Bist Du sicher?
Bei all den Versuchen, die ich vorher gesehen hatte, war das auf mmc
Treiberebene aber auch der Fall.
Mir ist jetzt aber noch was anderes eingefallen:
Wieviele Sektoren werden beim Booten denn gelesen?
Anders gefragt: Wieviele Sektoren liest Dein ipl und wie wird/wurde Dein
cpm.bin gebaut. Ursprünglich wurden vom ipl 2 Sektoren zu wenig geladen,
und vom Makefile 1 Sektor zu wenig vom bios.bin kopiert. Mit dem
damaligen BIOS war das egal, weil es klein genug war.
Logauszug Rev. 78
1
* cpm/Makefile:
2
- cpm.bin: Copy (all) 7 sectors from bios.bin.
Logauszug Rev. 63
1
* cpm/ipl.asm
2
- Increased number of sectors to load from 49 to 51 (= all reserved sectors).
Deinen neuen Artikel habe ich gesehen. Obige Fragen bleiben.
> Fragen über Fragen...
Leo C. schrieb:> * cpm/Makefile:> - cpm.bin: Copy (all) 7 sectors from bios.bin.
Mein (Windows) Makefile hat nur 6 Sektoren gelesen, dumme Sache. Ich muß
mal alle Makefiles überprüfen.
Joe G. schrieb:> Leo C. schrieb:>> * cpm/Makefile:>> - cpm.bin: Copy (all) 7 sectors from bios.bin.>> Mein (Windows) Makefile hat nur 6 Sektoren gelesen, dumme Sache. Ich muß> mal alle Makefiles überprüfen.
ipl nicht vergessen. Ich meine, daß die 6 Sektoren gerade noch reichen.
Jedenfalls hats gereicht, als ich die Änderung gemacht habe, und beim
neuesten BIOS reichts auch. Aber die 5 Sektoren, die der alte ipl
kopiert, reichen nicht.
Hallo Peter.
Genau so siehts bei mir derzeit auch aus. Da der Font noch nicht
angepasst ist, fehlen an den Zeichen rechts immer 2 Pixel. Und da die
Höhe des Fonts nur 8 und nicht 16,667 Pixel ist, liest er am Ende über
den Pufferspeicher hinaus. Als nächstes muss ich erstmal einen
vernünftigen Font basteln und die Ausgaberoutine daran anpassen. Danach
kann ich daran gehen, die fehlennden Funktionen des VT100 Terminals
nachzubauen.
Grüße
Frank
Moin Frank,
fehlt nicht eher links was oder hängt das mit dem
Schieberegister zusammen? Wenn Du mir kurz erklären,
wie es aufgebaut ist, kann ich Dich beim Font
unterstützen. Ist ja eher ne Fleissarbeit.
Verstehe ich es richtig, dass in der font.c jede
Spalte ein 8x8 Zeichen ist? 1.Spalte 0x00 bis 0xff.
Sind dies schon die ASCII Adressen? Bei 16x6 werden
die Zeichen rel. schmal, obwohl, es geht ja min.
1 linie als Zwischenraum weg.
Gruss
Peter
Hallo Peter.
Ich habe schon einen einfachen Font angefangen. Im moment fehlen mir
"nur" noch die Kleinbuchstaben. Und ich muss das File nacher noch
passend aufbereiten. Ich spiele gerad mit einem ganz einfachen
Fonteditor rum.
Der Font wie er in der Font.c abgelegt ist, ist praktisch Zeilenweise
abgelegt. Pro Zeile eines Zeichens wird immer genau 1 Byte verwendet.
Jedoch sind nicht etwa alle Zeichen einfach nacheinander Zeile für Zeile
abgelegt.
Die Tabelle ist so angelegt, das jeweils eine Spalte von oben nach unten
gesehen ein Zeichen bildet. Von Links nach Rechts sind die Zeichen von
ASCII- Code 0 bis 255 aufsteigend abgebildet.
Das erleichtert der Bildaufbauroutine den Zugriff ganz enorm.
Mit der Aussage, es fehlt eher links was könnte stimmen. Wenn man die
Bits eher so Zählt 76543210, dann würde er links 2 Bits wegwerfen. Auf
jeden Fall werden nur die 6 niederwertigsten Bits auf den Port
ausgegeben. Und das Abschneiden an der Linken Seite würde auch zu deinem
Foto besser passen.
Grüße
Frank
Hallo Frank,
ich habe mal ein paar Buchstaben der 8x8 aufgemalt. Bei
"B" und "D" sieht man den senkrechten Strich noch auf dem
Monitor, weil sie eine Serife haben. Es fehlen also links
2 Bit. Die Ziffern rechts sind die cursor Positionen in
der font.c im AVR-Studio.
Gruss
Peter
Neues Format.
Ich habe mir heute nochmal die Formate des genialen simh Altair 8800
Emulators angeschaut. Das Diskettenformat kann man vergessen. Das
Harddiskformat ist aber ganz simpel und ich habe es schon eingebaut.
Kleiner Wermutstropfen: Das Format hat zwar 6 Systemspuren a 32 Sektoren
reserviert, aber wenn man dort ein System zum booten einspielt, kann es
nicht mehr erkannt werden. Das werde ich aber irgendwann mal ändern.
Zu dem Emulator gibt es eine ganze Menge Diskimages mit guter Software.
Allerdings sind das alles Diskettenimages. Aber man kann sie ja im
Emulator einfach auf "Harddisk" umkopieren. Hier kann man alles
runterladen:
http://www.schorn.ch/cpm/intro.php
Hier ist eine Formatbeschreibung für die cpmtools:
Halloe.
Es ist schon späht, aber ein kleines Update möchte ich euch noch zum
anschauen überlassen. Im Anhang findet ihr eine erste Version der
Routinen mit einem 6*16 Font. Bitte nicht zu genau drauf schauen, ich
habe den Font mal eben schnell komplett neu gezeichnet. Und ich bin bei
weitem kein Mahlkünstler :-)
Leider habe ich keinen wirklich guten kostenlosen Editor für Windows
gefunden. Man sieht beim Malen nicht, wie es nacher im gesammten
wirklich aussieht. Ich werde den Font nochmal ein bissel überarbeiten,
aber man kann nun wenigstens schonmal was erkennen. :-) Etwa in der Art
wird es nacher ausschauen.
Da ich noch ein "einfaches" Attribut umsetzen könnte frage ich einfach
mal. Invertiert oder lieber Unterstrichen, was hättet ihr lieber ?
Grüße
Frank
p.s. die 25. Zeile mit dem Müll darin werde ich in der nächsten Version
ausblenden, so das sie nicht mehr stört.
Ich habe das SVN-Repository etwas umstrukturiert. Alte Links aus dem
Forum werden wohl nicht mehr funktionieren, sorry. Vom Top-Level aus
dürfte es aber kein Problem sein, alles wieder zu finden.
In avrcpm/trunk gibt es ein neues "tools" Verzeichnis, in dem jetzt
Franks Progamm zum Vergößern von Images zu finden ist. Da das Programm
jetzt mit E5 Hex statt mit Nullen füllt, kann man es auch zum Erzeugen
neuer Images verwenden. Unter Linus geht das z.B. so:
Unter Windows müßte es so ähnlich auch gehen. Falls es dort kein 'expr'
oder ähnliches gibt, muß man die Größe selbst ausrechnen.
Das Resultat kann man in eine CP/M- oder unter passendem Namen, in eine
FAT16- Partition kopieren, und man hat ein frisch formatiertes CP/M
Dateisystem.
Außerdem gibt es noch ein Verzeichnis 'avrvga', das für die
Terminalsoftware von Frank vorgesehen ist. (Änderungen vorbehalten)
Hallo Frank,
welchen Font-Editor hast Du benutzt? Ich habe mal einige
Zeichen von Hand geändert (Bleistift und Papier). Aber bei
6 Pixel Breite hat man natürlich keine große Auswahl.
Typografisch ist was anderes.
Gruss
Peter
Halloe.
Heute habe ich mich erstmal ein wenig um die Terminalemulation
gekümmert. Am Bildschirmende wird nun nicht mehr einfach der ganze
Bildschirm gelöscht. Statt dessen Scrollt der ganze Bildbereich nun eine
Zeile aufwärts. Hier habe ich leider noch ein sehr eckliges Flackern
beim Scrollen, das ich noch nicht weg bekommen habe.
Auch um die Tastaturanbindung habe ich mich schon ein wenig kümmern
können. Bisher habe ich die Interruptroutine auch noch nicht ans laufen
bekommen. Im moment plagt mich noch die befürchtung, das der
Tastaturinterrput evtl. den gesammten Bildaufbau durcheinander bringen
könnte bei jedem Bit, das die Tastatur an den Controller schickt. Leider
habe ich hier weder ein Osziloskop noch einen Logiganalyzer, so das ich
im moment ein wenig im dunkeln stochere was das Problem angeht.
Grüße
Frank
Frank Zoll schrieb:> Auch um die Tastaturanbindung habe ich mich schon ein wenig kümmern> können. Bisher habe ich die Interruptroutine auch noch nicht ans laufen> bekommen. Im moment plagt mich noch die befürchtung, das der> Tastaturinterrput evtl. den gesammten Bildaufbau durcheinander bringen> könnte bei jedem Bit, das die Tastatur an den Controller schickt. Leider> habe ich hier weder ein Osziloskop noch einen Logiganalyzer, so das ich> im moment ein wenig im dunkeln stochere was das Problem angeht.
Du willst für die Tastatur einen interruptgesteuerten Software-UART
benutzen? Ich weiß nicht wie es bei dir jetzt aussieht, aber in meinem
Code war während einer Videozeile kein einziger Takt übrig. Deshalb habe
ich die Arbeit einem Hardware-UART überlassen und nur in der
horizontalen Austastlücke ggf. ein empfangenes Byte zwischengespeichert.
Wenn du auf jedes Bit reagieren musst, wird das nicht reichen.
Sebastian
Hallo Sebastian.
Ja, ich muss die Arbeit notgedrungener Massen selber machen. Der 168er
AVR Controller hat leider nur einen UART. Und der ist bereits für die
Verbindung zwischen dem VGA- Teil und dem CP/M Emulator belegt. Im
moment gehe ich davon aus, das ggf. jedes einzelne Bit das von der
Tastatur kommt alles durcheinander bringen könnte, wenn der Interupt
wärend der Pixelausgabe zuschlägt. In der vorliegenden Hardware ist der
Clockausgang der Tastatur mit dem INT1- Eingang des Controllers
verbunden. Im moment versuche ich gerade diesen Interrupt überhaupt
erstmal ans laufen zu bekommen. Soweit meine Rechergen ergeben, sendet
eine Standarttastatur mit einer Taktrate von 20 bis 30 Khz. Bei der
derzeitigen Auflösung mit 400 aktiven Zeilen bei 74HZ, hätten wir
rechnerisch 29,6 KHz abtastfrequenz, wenn wir es schaffen wären des
horizontales Blanks jeweils einen Tatsaturtakt abzuarbeiten. Das könnte
gerade so eben hinkommen würde ich sagen. Ich weiss nur noch nicht, wie
ich den Intterupt so lange heraus zögern kann, bis eine Grafikzeile
vollständig abgearbeitet wurde. Gänzlich verschlucken darf ich dabei ja
auch keinen einziegen Takt, sonst komme ich bei der Verarbeitung der
Datenbits durcheinander. Bin mal gespannt, ob ich das ganze irgendie in
den Griff bekomme.
Grüße
Frank
Die Verzögerung des INT1 passiert ganz von alleine:
Die Videozeile wird in einer ISR ausgegeben. Tritt während diese ISR
läuft der ext. Interrupt auf, wird nur das entsprechende INT1
Interrupt-Flag gesetzt. Die INT1 ISR wird erst ausgeführt wenn die Video
ISR zurückkehrt.
Da Zeilen- und Tastaturtakt aber nicht synchron sind, wird früher oder
später einen Takt verloren gehen.
(Verschachtelte Interrupts gehen auch, hab ich noch nie benutzt:
http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html )
Nur mal so der Neugierde habler......
640x400 Pixel heisst doch 640 / 8 = 80 Zeichen.
400 / 8 = 50 Zeilen.
Ein Zeichen besteht also aus einer 8x8 matrix.
Bei dieser werden nur die Bits xx543210 horizomtal verwendet.
Bit 76xxxxxx sind die Zwischenräume der Zeichen.
In der vertikalen werden nur die Zeilen 0,1,2,3,4,5, und 6 verwendet.
Zeile 7 ist der Abstand zwischen den Zeilen.
Also besteht ein Zeichen eigentlich aus einer 6x7 Matrix.
z.B. xx543210xx543210
1111 1111 = 0x3C,0x3C
1 1 1 11 = 0x41,0x13
1 1 1 11 = 0x41,0x13
111111 11111 = 0x3F,0x3E
1 1 1 11 = 0x41,0x13
1 1 1 11 = 0x41,0x13
1 1 1111 = 0x41,0x3C
= 0x00,0x00
Bei 25Mhz Taktung gehen nur die 640x350, 640x400 und 640x480 Modis.
80x43 80x50 80x60
Wollt ihr die uVGA auf 80x25 umstellen?
h3aau schrieb:> Bei 25Mhz Taktung gehen nur die 640x350, 640x400 und 640x480 Modis.> 80x43 80x50 80x60> Wollt ihr die uVGA auf 80x25 umstellen?
Geplant war 640x400 also 80x50 und dann jede zweite Zeile frei, also 80
Zeichen zu 25 Zeilen. Mehr geht eh nicht in den RAM.
Halloe.
Wir haben auf 80*24 Zeichen umgestellt mit einem neuen Font von 6(Breit)
* (16) Hoch Pixeln größe. Wobei nach jedem 6 Pixel breiten Zeichen 2
schwarze Pixel gesendet werden. 25 Zeilen passen nicht in den Speicher,
weil dies mit den benötigten Variablen für den UART und den Keyboard-
Puffer sowie die globalen Statusvariablen und den Stack kollidieren
würde. Die Auflösung bleibt aber 640*400 wobei die letzten 8 Zeilen
einfach nur schwarz ausgebeben werden.
Grüße
Frank
p.s. Für den Tastaturanschluss siehts ganz düster aus. Der Interrupt
haut wenn er prio bekommen würde 2 mal pro Bidlschirmzeile rein und
würde das ganze Bild durcheinander bringen. Und da die Clockerzeugung
von der Tastatur vorgegeben wird, können wir darauf keinen Einfluss
nehmen.
Halloe.
Ja das mit den unterlängen geht Problemlos. Ich habe es bei meinem Font
auch so gemacht. Die "Nulllinie" liegt dort auf der 12. Zeile. So sehen
die Buchstaben nacher im Display recht gut aus. Nur so Buchstaben wie W
und M die eigentlich besonders breit sind sehen bei 6 Punkten breite
nicht berauschend aus. Aber Lesbar ists auf jeden Fall geworden würd ich
sagen.
Ach ja, nochwas. Da CP/M Terminals nur 7bit ASCII- Codes verwendet
haben, habe ich das 8. Bit dafür genutzt Inverse Zeichen möglich zu
machen. Dazu habe ich alle Zeichen von 0-127 in den Bereich 128-255
kopiert und die Bits negiert. So kann ich spähter zumindest das Attribut
"invers" mit unterstützen. Wahlweise hätte man auch "unterstrichen"
nehmen können. Blinken z.B. würde nicht gehen, da wären der Ausgabe der
Pixel kein einzieger Tackt mehr für Sonderfunktionen über ist.
Grüße
Frank
Hallo
fzoll schrieb:> Für den Tastaturanschluss siehts ganz düster aus. Der Interrupt> haut wenn er prio bekommen würde 2 mal pro Bidlschirmzeile rein und> würde das ganze Bild durcheinander bringen. Und da die Clockerzeugung> von der Tastatur vorgegeben wird, können wir darauf keinen Einfluss> nehmen.
es gibt eine möglichkeit der Tastatur zu sagen das der Atmel nicht
bereit ist Daten aufzunehmen und die werden dann in der Tastatur
zwischengespeichert.
siehe Link.
http://www.marjorie.de/ps2/ps2_protocol.htm
Kommunikation: Allgemeine Beschreibung
PS/2 Mäuse und Tastaturen benutzen ein bidirektionales, synchrones
serielles Protokoll. Im Ruhezustand sind beide Busleitungen High. Nur in
diesem Zustand darf die Tastatur/Maus mit der Datenübertragung beginnen.
Der Host hat die absolute Kontrolle über den Bus und darf die
Kommunikation jederzeit unterbrechen, indem er die Clockleitung auf Low
zieht.
oder...
http://www.beyondlogic.org/keyboard/keybrd.htm
Keyboard to Host
...
The keyboard is free to send data to the host when both the KBD Data and
KBD Clock lines are high (Idle). The KBD Clock line can be used as a
Clear to Send line. If the host takes the KBD Clock line low, the
keyboard will buffer any data until the KBD Clock is released, ie goes
high. Should the Host take the KBD Data line low, then the keyboard will
prepare to accept a command from the host.
Gruß Egmont
fzoll schrieb:> Für den Tastaturanschluss siehts ganz düster aus. Der Interrupt> haut wenn er prio bekommen würde 2 mal pro Bidlschirmzeile rein und> würde das ganze Bild durcheinander bringen. Und da die Clockerzeugung> von der Tastatur vorgegeben wird, können wir darauf keinen Einfluss> nehmen.
Einfach mal eine Idee.
A.)
Tasttatur auf der VGA Platine kommt an die Hardware UART und die
Verbindung zum CP/M System erfolgt über eine Soft-UART analog der schon
realisierten.
B.)
Auf dem CP/M System sind ja noch zwei Leitungen frei. Über diese beiden
Leitungen wird die Tastatur angeschlossen. Da Sie beide am
Verbindungssteckverbinder anliegen, sollte das ohne großen
Hardwareänderungsaufwand zu realisieren sein.
Joe
Hallo Egmont und Joe.
Leider ist die Idee von Egmont nicht brauchbar. Das Problem ist, das die
tastatur zu langsam wäre die gesammten 11 Byte eines Zeichens wärend des
Vertical- Syncs zu senden. Und man kann die Übertragung nicht
mittendrinn anhalten. Sobald der Host (VGA-Contrloller) sagen würde, das
er nicht mehr zum Empfang bereit ist, wird nach Standard die Übertragung
komplett abgebrochen. Eine Pause ist im Protokoll nicht vorgesehen.
Leider.
Joe's Ideen an den UARTS und der Platine etwas zu verändern würden wohl
am meisten bringen.
Meine Idee ziehlt aber eher gerad in eine etwas andere Richtung. Ich
wollte die schöne Platine nicht "kaputt" machen. Statt dessen denke ich
gerade darüber nach mir einen ganz kleinen AVR- Controller auszusuchen
und ihn einfach als "Adapter" zwischen den VGA- Controller und die
Tastatur zu hängen. Dieser hätte dann genügend Zeit um alle Zeichen, die
die Tastatur sendet, zwischen zu Puffern. Und die beiden bestehenden
Datenleitungen aus dem PS/2 Port der Platine würde ich dann nutzen um
vom Adaptercontroller die Bits stück für stück abzuholen. Wobei ich dann
den Tackt wärend der horizintalen Sync- Zeiten auf seiten des VGA-
Controllers generieren würde.
Wenn wir es schaffen, da einen 4Pinner zu finden und zu Programmieren,
dann könnte man das Teil super einfach mit ein wenig Schrumpfschlach in
ein kleines Adapterkabel einbauchen und wird müssten die schöne Platine
nicht patchen.
Für eine Neuauflage würde ich das ganze dann gleich etwas anders
desigenen. Ich würde für den VGA- Teil einen Propeller Chip nehmen, der
hätte genügend Power um VGA/TV, sammt Tastatur und Maus zu händeln.
(DIP40 Gehäuse). Da wären dann auch die VT100- Attribute möglich. auch
in hochen Auflösung....
Grüße
Frank
PS2 komplett innerhalb des Zeilen-Sync zu machen geht nicht.
Vorschlag:
Da eine Zeile aber c.a. 25us dauert kann man 1/2 Bit pro Zeile
bearbeiten.
Dieses kann innerhalb des Zeilen-Sync erfolgen.
Also innerhalb des Zeilen-Sync eine halbe Clock-Phase für PS2 erzeugen,
und so jede zweite Zeile ein Bit lesen oder senden.
Der PS2 Byte-Transfer könnte auch Bild-Syncron starten, das wäre immer
noch schnell genug.
Hallo
h3aau schrieb:> Also innerhalb des Zeilen-Sync eine halbe Clock-Phase für PS2 erzeugen,
Zitat von http://www.marjorie.de/ps2/ps2_protocol.htm :
--------
Das Clock-Signal wird immer von der Tastatur/Maus erzeugt, aber der Host
hat die Kontrolle über die Kommunikation.
...
Die Clockfrequenz muß im Bereich von 10-16,7 kHz liegen. Das heißt, das
Clock-Signal muß für 30-50 µs High und für 30-50 µs Low sein.
--------
Wenn eine Zeile 25 µs dauert kann man dann nicht nach jedem Ende Clock
und Data auswerten? Bei 11 bit sollte man das synchron hinbekommen.
fzoll schrieb:> Das Problem ist, das die> tastatur zu langsam wäre die gesammten 11 Byte eines Zeichens wärend des> Vertical- Syncs zu senden.
Wieviel Zeit hat man in der Bild-Synchronisation.
oder...
gibt es die Möglichkeit ein Bildaufbau auszulassen ??
Gruß Egmont
Halloe.
Leider kann der HOST den PS/2 Clocktackt nicht beeinflussen. Das Clock-
Signal wird von der Tastatur generiert. Die Geschwindigkeit schwankt
hier je nach Tastatur zwischen ca. 10kHz und 30kHz. Man könnte nun
natürlich eine Suche starten und schauen ob man eine Tastatur finden
kann, dessen Clock-Signal zu unserem VGA- Signal "compatibel" ist.
Man kann auch kaum voraus sagen, wann die Tastatur ein Bit
senden/empfangen möchte. Im Grunde genommen startet der Tastaturclock in
dem moment in dem man eine Taste drückt. Kurze verzögerungen innerhalb
des Controllers mal ausser acht gelassen.
Diesen Start kann man unterbinden und hinauszögern, indem man dies per
Busy-Signal meldet. Wenn der Start aber erstmal erfolgt ist, würde das
melden des Busy- Signals aber nur den abbruch der aktuellen Übertragung
bewirken. Einigen Tastaturen soll das setzen des Busy- Signals sogar
egal sein, sie senden dann einfach weiter. Die Folge wäre ein
Datenverlust.
Ich habe mal versucht, meiner Tastatur ein Clock-Signal durch den Host
generiert aufzuzwingen. Am Ende kam dabei aber nur Datenschrott zu
stande, weil die Tastatur immer wieder ihre Übertragung abgerochen und
neu gestartet hat und ich somit immer wieder die ersten Bits der 1.
gedrückten Taste zu sehen bekahm.
Grüße
Frank
Halloe.
Ich spiele gerad mit dem Gedanken, das PS/2 Keyboardproblem durch den
Einsatz eines weiteren Controllers zu erschlagen. Anbei ein kleines
Schema von dem was ich mir vorstelle. Ich denke darüber nach, einen
kleinen 8Pinner AVR Controller in die Leitung zwischen der PS/2 Buchse
auf der Platine und der Tastatur zu einzubringen. Ich würde die
Clockleitungen beider Seiten auf Interrupt- Eingänge des AVR-
Controllers legen und die 2 Datenleitungen auf die übrigen Pins
verteilen.
Nun könnte man den AVR- Controller so Programmieren, das er auf der
einen Seite Datenbytes der Tastatur mit der geschwindigkeit, wie sie
durch die Tastatur festgelegt wird empfangen kann. Diese Bytes könnte
der Controller dann in seinem SRAM zwischenspeichern, bis sie durch den
VGA- Controller auf unserer Platine abgeholt werden. Hierzu würde ich
den VGA- Controller ebenfalls einen Tackt ausgeben lassen. Das
Tacksignal könnten wir dann relativ problemlos in der HSYNC- Phase
erzeugen lassen. Wir könnten auf geraden Ausgabezeilen einen Tackimpuls
erzeugen und auf ungeraden Zeilen die Daten entgegen nehmen. So könnten
wir dann am Ende die Datenbytes stück für stück vom "Puffercontroller"
abholen. Ein weiterer Vorteil wäre, das der Puffercontroller je nach
größe bis zu 512 Zeichen Puffer bereit stellen könnte. Im moment denke
ich an einen ATtiny45 für knapp 1,82€, welcher uns einen 256 Byte Puffer
schenken würde und leicht zu beschaffen ist.
Was ich daran nett finde ist, das wir dafür an der Platine keine
Änderungen vornehmen müssten. Und auch der Geldliche Aufwand wäre ja
minimal. (1 Stecker, 1 Buchse, der ATtiny Controller, ein Kerko und ein
Widerstand). Das ganze sollte sich recht einfach "fliegend" aufbauen
lassen.
Was haltet ihr von der Idee, wäre das eine nette Lösung für das
Keyboard- Problem ?
Freundliche Grüße
Frank
Hallo Frank
Egmont schrieb:> gibt es die Möglichkeit ein Bildaufbau auszulassen ??
Hier noch mal eine genaue Erklärung was ich damit meinte...
bei einer Vertical Frequency von ca. 70Hz kann man da nicht ein
komplette Bildaufbau auslassen. Mit auslassen meine ich keine Daten
ausgeben nur Hsync und Vsync.
Ein Bildaufbau dauert 12 ms (Active video time)soviel Zeit hat man die
Tastatur auszulesen.
- der Tastatur durch setzen von Clock auf High signalisieren das man
bereit ist Daten aufzunehmen.
- Daten einlesen (Tastatur kann 16 Byte im eigenem Buffer aufnehmen)
- Clock auf Low setzen.
- Bilddaten 69 mal ausgeben... und so weiter.
Ein Bildaufbau aussetzen (dunkel) sollte man eigendlich nicht merken.
Was meinst du, ist das machbar ?!?
Gruß Egmont
Hallo Egmont.
Einen Bildaufbau bei Bedarf aus zu lassen wäre wohl Problemlos möglich.
So lange die SYNC- Signale trozdem erzeugt werden, sollte der Monitor
nicht aus dem Tackt kommen. Damit hätte man eine Menge freier
Prozessorzeit über, um Daten von der Tastatur einzulesen. Das ganze wird
wohl ein bissel Tricky, ich könnte mir aber vorstellen das das machbar
wäre.
Freundliche Grüße
Frank
@fzoll
eine Tastaturlösung mit eigenem Kontroller hab ich fertig hier liegen..
nur der Reiz wäre schon Tastatur und VGA auf einem Chip...
Allerding sollte es nicht funktionieren...
gruß
Hans- Werner
Wäre folgendes für den VGA-Kontroller möglich:
Tastatur über seriellen Port anschließen. Die Verbindung zum
CPM-Prozessor mit zwei freien Portpins herstellen und eigenes, I2C
ähnliches ( synchrones Protokoll ) implementieren.
Noch ein Vorschlag (habt ihr aber sicher auch schon dran gedacht..)
Wenn der VGA-AVR das nicht mehr sauber packt.. dann den CP/M AVR nehmen
und
die 2 KBD Leitungen halt umlegen..
Peter
Frank Zoll schrieb:> Was haltet ihr von der Idee?
Wie im richtigen Leben gibt es für jede Lösung Pro und Contra. Ein ganz
wichtiges Argument: „Die schöne Platine nicht kaputt zu machen“ Da geht
eigentlich nichts drüber!
Doch nun weg von den emotionalen und hin zu den sachlichen Argumenten.
Soll die VGA Karte als eigenständiges „Terminalmodul“ fungieren, so ist
eine einfache universelle Schnittstelle immer von Vorteil. Das ist mit
der derzeitigen V24 gegeben. Würde die Tastatur über die beiden I2C
Leitungen der AVR CP/M Platine abgefragt, so wäre das ein Systembruch im
Sinne eines eigenständigen Terminals. Die Lösung von Frank einen
Attiny45 zu nehmen hat auch ihren Charme. Damit könnten sogar solche
Kunstwerke wie die Logitech diNovo Mini™ adaptiert werden.
Joe
Halloe.
Ich habe Egmont's Idee einmal zum Testen umgesetzt. VGA und Tastatur
lassen sich nun zusammen mit dem Terminal betreiben. Und das ganz ohne
Änderungen an der Platine oder zusätzliche Hardware.
Um das ganze recht einfach zu halten, habe ich es so umgesetzt, das
jedes 32. Bild ausgelassen wird, um die Tastatur zum Zug kommen zu
lassen. Auf meinem 17Zoll-Monitor ist das Auslassen eines Bildes
deutlich als Flackern erkennbar. Ob ich damit Stundenlang arbeiten
möchte, lasse ich einfach mal dahin gestellt.
Mal schauen, ob man es noch ein wenig weiter Verbessern kann. Anbei mal
die aktuelle Version für euch zum Rumspielen.
Freundliche Grüße
Frank
p.s. Ich habe längst noch nicht alle VT100 - Kommandos umgesetzt, mir
war erstmal wichtiger VGA und Tastatur ans laufen zu bekommen.
Halloe.
Da die Idee mit dem Auslassen eines ganzen Bildes recht gut Funktioniert
hat, habe ich mal versucht das ganze so Umzustricken, das es komplett
während der VSYNC- Zeit läuft. Dies hat mit meiner Tastatur leide rnicht
funktioniert. Es kahm kein einziges Byte mehr rüber. Danach habe ich mal
versucht, die Zeit der letzten 16 Zeilen, die eh nicht ausgegeben
werden, mit dazu zu nehmen. Nun konnte ich zwar ein paar Zeichen
empfangen, hatte aber immer wieder Übertragungsfehler. Mal schauen, was
sich da noch machen läßt.
Habt ihr vieleicht noch Ideen ?
Ach ja, einen seltsamen Fehler habe ich auch noch beobachten können. Mit
dem "BDOS" zusammen Funktioniert es eigentlich supi. Aber wenn man
Programme läd, gehts nicht mehr richtig. Konkrett die RETURN- Taste
schein nicht mehr abgefragt zu werden. Bei ZORK und MBASIC kann man zwar
munter etwas eintippen, aber wenn man RETURN drückt passiert nichts. Ich
vermute mal, das es noch fehler in der VT100 Emulation sind, die wir
noch beseitigen müssen.
Grüße
Frank
Hallo Frank
Frank Zoll schrieb:> Habt ihr vieleicht noch Ideen ?
Wenn in den letzten 16 Zeilen nichts mehr ausgegeben wird, sollte man da
schon KB-Clock auf High setzen, wenn jetzt die Tastatur antwortet, also
Daten hat, ein Bildaufbau komplett auslassen. Wenn in der Zeit nichts
kommt, Bildaufbau normal ausgeben. Das heist das Bild "flackert" nur
wenn man eine Taste drückt.
16 Zeilen * 25µs = 400µs -->
Clock muss für min 50µs High sein bevor Tastatur sendet. Also schafft es
die Tastatur in der Zeit von 350µs zu signalisieren das sie Daten hat.
Das bedeutet auch das man 70 mal in der Sekunde versucht die Tastatur
abzufragen ( ob was im KB-Buffer ist) ....
ist besser als....
2 mal in der Sekunde abzufragen und ein Bildaufbau auslassen (und dann
hat der User noch nicht mal eine Taste gedrückt.... dumm gelaufen).
Egmont
Hallo Frank,
Frank Zoll schrieb:
> Habt ihr vieleicht noch Ideen ?
Alles in der VSYNC-Zeit zu schaffen, wäre schon ideal. Wäre es nicht
denkbar, vom Modus 640x400@70Hz auf 640x480@60Hz zu gehen? Horizontal
bleibt alles gleich, es kommen nur 80 schwarze Pixelzeilen dazu. Grob
überschlagen hätte man dann pro Bildaufbau etwa 4.3ms Zeit für
Keyboardroutinen, während es bei 640x400 nur ca. 2ms sind.
Ich kann mir vostellen, dass die derzeit 2ms zu wenig sind, um eine
Tastaturantwort entgegenzunehmen. Teilweise sind die Make/Breakcodes
auch 2 oder 3 bytes lang, welche man von der Tastatur ohne Unterbrechung
entgegennehmen muß.
Viele Grüße, Thomas
Hallo Thomas.
Ich habe deinen Vorschlag ausprobiert. In der aktuellenb SVN- Version
ist die Auflösung nun 640*480 Pixel bei 60Hz(62Hz zeigt meine Monitor
an).
Die Keyboardroutinen laufen nun vollständig wärend der Zeit in der keine
aktive Videoausgabe erfolgt. Von 480 Zeilen werden nur 384 Zeilen
ausgegeben. Den rest der Zeit hat nun die Keyboardroutine um Zeichen zu
empfangen. Damit konnten wir das auslassen ganzer Bilder nun erfolgreich
"wegoptimieren".
Das Bild bleibt nun recht stabiel. Flakern tut's im moment nur beim
scrollen, da werde ich als nächstes mal drauf schauen.
Grüße
Frank
Hallo,
habe folgendes Problem mit meiner AVR-VGA.
Signal ist vorhanden wenn ich mit dem Oscilloscope nachmesse.
wenn ich den Monitorstecker drauf stecke wird das Signal über die 470
Ohm Widerstände auf 0,7 Volt gezogen aber Monitor zeigt kein Bild an.
Habe ein TFT und Röhrenmonitor ausprobiert beides das gleiche.
TFT schreibt das ein Eingangspegel vorhanden ist (Hsync unf Vsync).
>>>>> Sollte soweit doch Richtig sein ...oder mache ich da ein Denkfehler !
Laut Google erwartet Pin RGB 0,7 Vss und eine Impedanz von 75 Ohm.
Kommunikation von Tastatur zu CP-M funktioniert.
CP-M zu VGA kann ich jetzt noch nicht sagen aber aus PortC kommen Daten.
Habt ihr ein Tipp für mich woran das liegen könnte.
Gruss Egmont
Egmont schrieb:> Habt ihr ein Tipp für mich woran das liegen könnte.
Hast auch mal am Ausgang des Schieberegisters gemessen ob überhaupt
Pixeldaten kommen?
Joe
Hallo,
TFT läuft jetzt nachdem ich umgestellt habe auf neue Software (640x480)
Was mir noch aufgefallen ist, der TFT sagt mir unter Info das er eine
Auflösung von 848x480@62Hz gefunden hat... und die Zeichen sehen nicht
besonders schön aus.
Röhre sagt immer noch nichts !
Meine Vermutung ist, das die Röhre diese Auflösung nicht kann.
Was sagt eure Info vom Monitor ?
Gruss Egmont
Egmont schrieb:> Was sagt eure Info vom Monitor ?
640x480@60Hz
Deine Anzeige von 848x480@62Hz sieht nach einem unsauberen Syncronimpuls
aus.
Egmont schrieb:> und die Zeichen sehen nicht besonders schön aus.
Das passiert, wenn die Pixelauflösung des LCD nicht mit der der VGa
übereinstimmt.
Hallo Egmont.
Beide Versionen 640*400 und 640*480 habe ich auf einem alten
Röhrenmonitor getestet. Der iiyama Visionmaster Pro410 hatte keine
Probleme mit der Anzeige, obwohl der Pixeltakt nicht genau genug ist.
(62 statt 60 bzw. 74 statt 70 Hz).
Ich habe die neue Version mal auf einem "neueren" TFT Monitor
ausprobiert, um zu schauen ob evtl. neuere Monitore mit der krummen
Auflösung schwierigkeiten haben. Mein Samsung SyncMasterT220HD
(BreitbildMonitor) hat keine Probleme, die Auflösung 640*480 @ 62HZ
wieder zu geben. Der Font mit 6(8)* 16 Pixeln sieht sogar recht nett
aus, weil der Monitor das Bild netterweise in der Breite für mich
gestreckt hat.
Wie siehts den sonst so bei den anderen aus ? Habt ihr evtl. auch
Monitore, die es Stört das der Pixeltakt nicht genau genug ist für
640*480@60Hz ?
Grüße
Frank
"VGA industry standard" 640x480 pixel mode
General characteristics
Clock frequency 25.175 MHz
Line frequency 31469 Hz
Field frequency 59.94 Hz
One line
8 pixels front porch
96 pixels horizontal sync
40 pixels back porch
8 pixels left border
640 pixels video
8 pixels right border
---
800 pixels total per line
One field
2 lines front porch
2 lines vertical sync
25 lines back porch
8 lines top border
480 lines video
8 lines bottom border
---
525 lines total per field
Hallo
mit folgenden Werte habe ich ein besseres Bild bekommen
und die Info sagt 640x480@60Hz:
----[ global.h ]--------------------------------------------
#define H_FRONT 8 //2 // front porch
#define H_SYNC 10 //12 // sync pulse -- NEGATIVE polarity
#define H_BACK 6 // back porch
#define H_ACTIVE 80 // active video
#define H_TOTAL (H_SYNC+H_BACK+H_ACTIVE+H_FRONT)
#define H_CHARS H_ACTIVE
// unit: LINES
#define V_FRONT 5 //11 // front porch
#define V_SYNC 2 // sync pulse -- POSITIVE polarity
#define V_BACK 31 // back porch
#define V_ACTIVE 480 // active video
#define V_TOTAL (V_SYNC+V_BACK+V_ACTIVE+V_FRONT)
#define V_CHARS 24
-----------------------------------------------------------
Dazu habe ich festgestellt,
wenn man wie ich beide Atmel mit 25Mhz betreibt,
ein besseres Bild bekommt wenn man nur ein Quarz benutzt
(Jumper JP10 auf 1-2).
Gruss Egmont
Egmont schrieb:> Dazu habe ich festgestellt,> wenn man wie ich beide Atmel mit 25Mhz betreibt,> ein besseres Bild bekommt wenn man nur ein Quarz benutzt> (Jumper JP10 auf 1-2).
Dieser Effekt ist dem Entwicklungsboard geschuldet. Die AVR's sind nicht
besonders "EMV freundlich" In einem Industrieprodukt würde meine
Stromversorgungsvariante der beiden AVR's durchfallen. Ich hatte bewußt
auf die Drosseln verzichtet. So schlägt der Takt recht stark auf die
Stromversorgung durch. Bei nur einer Taktversorgung wenigstens nur mit
der einen Frequenz. Asche auf mein Haupt! Das nächste Board bekommt ein
EMV gerechteres Design.
Halloe.
Ich habe mal wieder ein kleines Update der Software für den
VGA/Keyboard- Teil des aktuellen Boards auf den SVN- Server hochgeladen.
Mit dem aktuellen Update sind nun die ersten VT100/VT52 Funktionen
implementiert. Die Tasten RETURN und BACKSPACE tun nun was sie sollten.
Damit läßt sich nun auch endliche eine Partie "ZORK1" auf dem Board
spielen. Der Cursor wird nun auch endlich korrekt angezeigt. Die
Tastaturroutinen laufen nun, ohne das ganze Bilder ausgelassen werden
müssen. Durch auslassen der Darstellung der letzten 96 Bildzeilen
konnten die Tastaurabfragen ans laufen gebracht werden. Das ganze ist
etwas "schwammig" und sicher nicht für Actionspiele geeignet, aber
immerhin tut's jetzt einigermaßen.
Grüße
Frank
Hallo Frank,
das mit dem svn Server ist sehr umständlich besser wäre den jeweiligen
stand zu posten...
leider konnte ich die Quellen auch nicht ohne Fehler übersetzen.??
Build started 2.11.2010 at 17:52:56
avr-gcc -mmcu=atmega328p -Wall -gdwarf-2 -std=gnu99
-DF_CPU=25000000UL -Os -funsigned-char -funsigned-bitfields
-fpack-struct -fshort-enums -MD -MP -MT dmm_vga.o -MF dep/dmm_vga.o.d
-c ../dmm_vga.c
../dmm_vga.c: In function '__vector_7':
../dmm_vga.c:45: error: 'PB3' undeclared (first use in this function)
../dmm_vga.c:45: error: (Each undeclared identifier is reported only
once
../dmm_vga.c:45: error: for each function it appears in.)
../dmm_vga.c: In function '__vector_12':
../dmm_vga.c:150: error: 'PB2' undeclared (first use in this function)
../dmm_vga.c: In function 'main':
../dmm_vga.c:215: error: 'PD5' undeclared (first use in this function)
../dmm_vga.c:215: error: 'PD6' undeclared (first use in this function)
../dmm_vga.c:215: error: 'PD7' undeclared (first use in this function)
../dmm_vga.c:222: error: 'PB0' undeclared (first use in this function)
../dmm_vga.c:222: error: 'PB2' undeclared (first use in this function)
../dmm_vga.c:225: error: 'PB1' undeclared (first use in this function)
../dmm_vga.c:226: error: 'PB3' undeclared (first use in this function)
make: *** [dmm_vga.o] Error 1
Build failed with 11 errors and 0 warnings...
Gruß
Hans-Werner
Hallo Hans Werner.
Sorry, im moment komme ich hier zu fast gar nichts mehr. Daher hier erst
verspähtet meine Antwort.
Ich nutzte unter WindowsXP den SVN- Client Tortoise. Mit dem kann man
eigentlich Problemlos auf den SVN- Server zugreifen und Updates ziehen
geht dort ganz einfach über einen "rechtsclick" auf das Verzeichniss und
die Auswahl des Punktes "SVN Update".
Ich kann die Zwischenstände auch hier im Thread Posten, habe es aber
bisher vermieden, um den Server nicht unnötig mit Alpha & Betha-
Versionen vollzumüllen. Mein Vorschlag wäre, erstmal noch bei dem SVN-
Server zu bleiben und erst die fertige Version des VGA- Terminals hier
für alle nochmal zu posten. Ich habe auch keine Probleme euch gezipte
Dateien auf Anfrage per E-Mail zukommen zu lassen. Was meint ihr ?
Was aber das Problem mit dem Compilieren angeht, so habe ich es gerad
nochmal ausprobiert. Die aktuelle SVN- Version läßt sich ohne Fehler
übersetzen. Ich denke das Problem das Du da hast, ist evtl. das gleiche
das ich auch beim ersten Compilieren der "Urversion" hatte. Ich hatte
eine etwas ältere Version von AVR-GCC installiert. Diese Version kannte
aber den 328er AVR noch nicht und hatte daher nicht die passenden
Includes mit den Daten der Anschlußpins. Nach einem Update auf die
Version "WinAVR-20100110" hat es dann bei mir aber Funktioniert. Schau
am besten einmal nach, welche Version dort Installiert ist.
Zum "aktuellen" Stand kann ich sagen, das ich als nächtes vor habe die
VT100 Emulation weiter aus zu bauen. Im moment habe ich hier lokal
bereits eine Version mit fertiger aber noch ungetesteter VT52 Emulation.
Meine Planung sieht vor, die Emulation zwischen VT52 und VT100/102 per
F12- Taste umschaltbar zu machen. Im moment komme ich nur nich zum
Programmieren.
Die VT52 Emulation ließ sich viel leichter Umsetzen als die VT100/102
Emulation, weil die Steuersequenzen deutlich kürzer und viel einfacher
aufgebaut sind. Bei VT52 kann immer nur ein Commando mit fester
Parameteranzahl nach dem ESCAPE kommen. Bei VT100/102 kann man praktisch
beliebieg viele "Variablen" nach dem ESCPAPE senden und dann ganz am
Ende sagen, welcher Befehl mit diesen Parametern auszuführen ist.
Außerdem werden die Variablen bei VT52 praktisch "binär" als einzelnes
ASCII- Zeichen gesendet, von dem man dann nur noch eine Constante
abziehen muss um auf den richtigen Wert zu kommen. Bei VT100/102 kommen
die Variablen als String und müssen erst noch interpretiert werden. Das
ganze wird mich wohl noch eine ganze Zeit lang beschäftigen, bis es
einigermaßen zufreidenstellend läuft.
Freundliche Grüße
Frank
In den letzten Tagen habe ich die Terminal- Emulation stark erweitert.
Die aktuelle Version findet sich wie immer auf dem oben verlinkten SVN-
Server. ( http://cloudbase.homelinux.net/svn/avr-cpm )
Unter anderem neu sind:
- Eine ADM-3A Emulation steht nun auch zur Auswahl.
- Umschaltung der Emualtionen VT52/VT100/ADM3-A per F11
- Umschaltung der Schriftfarbe per F12
- Fast alle ESCAPE- Codes des ADM-3A Terminals wurden implementiert. (
Ausnahmen: Auflösungswechsel, Testmodus und Baudratenänderung )
- Unterstüzt die Font- Umschaltung auf einen 2. Font.
( Derzeit wird hier nur zwischen 2 sehr ähnlichen Fonts umgeschaltet)
Was fehlt noch ?
- Jemand der Lust hat alle ESCAPE- Sequencen des ADM-3A Terminals
auszuprobieren und ggf. Fehler zu melden. Schön wäre ein MBASIC-
Programm, mit dem man alle Codes ausprobieren kann, damit der Fehler
leichter nachzustellen ist.
- Den beiden Fonts fehlen noch die Grafikzeichen, derzeit werden
Graphiczeichen als Leerräume dargestellt. Mag hier wer die fehlenden
Zeichen hinzu fügen ?
- Die VT52 und die VT100 ESCAPE- Sequencen werden noch nicht vollständig
beherscht.
Freundliche Grüße
Frank
Hallo Peter,
ich hab deine Version mal getestet... leider scheinen die Zeitprobleme
sich auszuweiten... bei der Bildschirmausgabe (dir) fehlen teilweise
Zeichen und bei der Tastatureingabe hakt es nach wie vor... Die
Terminalemulation hab ich nicht getestet...
Gruß
Hans- Werner
Halloe.
Ich glaube ich konnte das Problem der verlorenen Zeichen vom CP/M Kern
an das Terminal weiter einkreisen. Mir ist das ganze bisher im Test noch
nicht aufgefallen. Das könnte evtl. daran liegen, das ich den CP/M Teil
nur mit 20Mhz laufen lasse. Solltest Du den CP/M Kern übertacktet haben,
so wäre der ja etwas schneller als meine Version, so das das unten
Beschriebene Problem dann mit einer größeren Warscheinlichkeit auftreten
könnte. Ich versuchs auf jeden Fall mal nachzustellen.
Hier meine Vermutung:
Es könnte daran liegen, das während der V-SYNC Phase keine Zeichen von
der Seriellen Schnittstelle zum CP/M System abgeholt werden. Die V-SYNC-
Phase ist jedoch ein klein wenig länger, als die Dauer der Übertragung
eines einzelnen Zeichens. Das könnte dazu führen, das einzelne Zeichen
verloren gehen, wenn sie genau in der VSYNC- Phase gesendet wurden. Ich
hoffe ich habe mich da nicht verechnet :-).
Ich werde heut Abend mal versuchen ob es evtl. besser wird, wenn auch
während des VSYNC's auf eingehende Zeichen reagiert wird.
Was die nicht erkannten Tastendrücke angeht, so kann man da wohl nicht
mehr viel ausrichten. Da ich nur während des VSYNC's mit der Tastatur
interagieren kann, konnt es stark auf den Typ der Tastatur und die
Tippgeschwindigkeit an. Während der Ausgabe der sichtbaren Bildteile
muss ich die Tastatur ständig dazu zwingen ihre Kommunikation
einzustellen und ggf. sogar abzubrechen. Ich denke mal das das ganze
einige der Tastaturen am Markt nicht all zu gern mitmachen. Meine eigene
Tastatur gehört auch dazu. Sobald ich mal ein wenig schneller Tippe
gehen auch mir Tastendrücke verloren.
Eine mögliche Lösung hierfür sieht ein kleines ATINY- Puffer IC in der
Tastaturleitung vor, das die Zeichen zwischenspeichert und dann von der
VGA- Seite her per Pollingverfahren ausgelesen wird. Derzeit habe ich
nur leider keinen ATINY hier rum liegen, so das ich das im moment nicht
Ausprobieren könnte. Und das bestellen eines einzelnen ATINY's lohnt
sich nicht. Sobald ich da etwas fertiges habe, werde ich das als option
mit in den VGA- Kern übernehmen. Dann kann jeder nacher beim Compilieren
per DEFINE's entscheiden, ob er mit oder ohne zusätzliches PufferIC
arbeiten möchte.
Was mir noch aufgefallen ist, ist das auch das ADM-3A Terminal spezielle
Steuerzeichen für Befehle wie Unterstrichen, Unsichbar und Blinkend
kennt. Diese kann ich leider mangels Resourcen auf dem AVR-VGA Kern
nicht unterstützen, sie werden daher derzeit auch nocht nicht einmal
erkannt. Hier baue ich noch eine Erkennungsroutine ein, die die
Sequencen erkennt und dann aber einfach ignoriert. Damit sollten die
Steuerzeichen nicht mehr mit auf dem Bildschirm ausgegeben werden.
Vielen Dank fürs Testen,
Frank
Hallo Frank,
mein CPM Kern läuft mit 20MHz Quarz... also ist mein System mit deinem
vergleichbar. Wie wäre es denn wenn man die Übertragungrate reduziert?
Wenn du einen Tiny als Buffer nimmst... warum nicht auch für die
Serielle?
Gruß
Hans- Werner
Hallo Peter,
anscheinend ist ganz plötzlich alle weg... deine Schaltung sieht wild
aus, aber funktioniert...oder. Was macht denn die Software?
Gruß
Hans-Werner
Hi Hans-Werner und Joe.
Das war der aller erste LR Aufbau, der zum aller ersten Post in diesem
Thread führte. Damals noch mit 3.3V Netzteil und Handykabel zur
seriellen Verbindung.. ;-) Als ich den Adapter sah, mußte ich den
einfach bestellen (3-4€) und wußte, das der hier wie die Faust aufs Auge
passt..
Ist immer noch ein 4-bit Aufbau.. ich mag diese SMD Drams nicht :-(
Die 8080 Emulation und CP/M laufen sehr gut!
Wie Joe aber schon sagte habe ich von der Erweiterung auf Z80 Emulation
nichts mehr gehört und das serielle Terminal ist wohl auch nur
rudimentär
fertig gestellt..
Die letzten Entwicklungen gingen mir zu schnell um noch mitzukommen und
Richtung NUR Linux wollte ich auch nicht.. daher nutze ich immer noch
das
'alte' Diskformat und den tniasm..
Evtl. baue ich die 8-bit Dramversion mal in DIL auf LR auf.. aber mit
Platine wäre das schon einfacher..
Wie genau der letzte Stand ist und wo der nun liegt..??
---
Wenn man das mal wieder beleben wollte, würde ich (just my 2 cents!)
eine neue Platine machen wollen: 8-bit aber DIL - kein SMD!
Ohne Terminal, dafür aber obigen Adapter vorsehen, der gleich die 3,3V
Versorgung und die PC Kommunikation über USB erledigt. Also quasi
1x ATmega328, 2xDIL Dram, Quarz+2xC, USB Adapter. Thats it.
-
Die darauf laufende Software auf den aktuellen Stand bringen und
dokumentieren. Hier insbesondere das/die neuen Diskformate
berücksichtigen.
-
Die Z80 Emulation voran bringen!
Peter
Peter Sieg schrieb:> Wenn man das mal wieder beleben wollte, würde ich (just my 2 cents!)> eine neue Platine machen wollen: 8-bit aber DIL - kein SMD!
Das sollte sich machen lassen... wenn es wieder auf Interesse stößt.
> Die darauf laufende Software auf den aktuellen Stand bringen und> dokumentieren. Hier insbesondere das/die neuen Diskformate> berücksichtigen.
Hier sehen ich den größten Aufholbedarf. Das Projekt wird erst von
Interessenten nachgenutzt, wenn die Doku auch eine Nachnutzung erlaubt.
> Die Z80 Emulation voran bringen!
JA
Ich habe mal im Forum64, Forum des Vereins zum Erhalt klassischer
Computer und Robotron Forum Werbung gemacht:
---
Hi. Mehr Info's hier:
Beitrag "CP/M auf ATmega88"http://avr.cwsurf.de/?AVR_CP%2FM
Das Projekt ist etwas 'eingeschlafen', aber wir möchten es gerne etwas
wiederbeleben.
Es soll - bei genügend Interesse - eine neue Platine geben nur in DIL!
(kein SMD). Das wird dann ein ATmega328 und 2 x 4-bit Dram werden.
Dazu noch ein SD Slot und den USB-TTL Wandler und fertig.
Was zur Zeit alles läuft: 8080 Emulation inkl. Mircosoft Basic, BDS
C-Compiler, Spiele etc. inkl. vollem CP/M System mit bis zu 4
Diskettenimages..
Was noch fehlt: Z80 Emulation
Falls ihr an einer Platine interesse habt und bei der Doku oder
Programmentwicklung weiterarbeiten möchtet, postet es bitte im obigen
Thread und hier.
Das Ding macht wirklich Spaß!
Peter
---
Mal sehen, ob wir mind. 10 Interessenten zusammenbekommen.
Bei eine einfachen DIL Variante mit AVR, 2xDram für 8-bit
und dem oben genannten USB-TTL Wandler bin ich schon mit 2-3 Platinen
dabei.
Peter
Hallo,
ich wäre an zwei Boards interessiert - neben der CP/M-3 und qz80
Implementierung auf dem Propeller, wäre das meine zweite Software
CP/M-Maschine :-)
Grüsse,
Andreas
wunixbln-NO-SPAM-@googlemail.com (-NO-SPAM- löschen)
Andreas H. schrieb:> ich wäre an zwei Boards interessiert
Andreas, du bist aufgenommen.
@Peter
an welche D-RAM's hast du gedacht? Wieviele bekommen wir zusammen?
Joe
@Joe: 256k x 4bit
Part number V53C104P-70
Description HIGH Performance, LOW Power 256K X 4 BIT FAST PAGE MODE
CMOS Dynamic RAM; DIL-20
Davon habe ich ca. 34 Stück hier liegen.
Dann habe ich noch GM71C4256, HM514256, TC514256 hier ca. 20 Stück.
Auch DIL-20 und sollten alle dasselbe Pinout haben..
Peter
Peter Sieg schrieb:> @Joe: 256k x 4bit
OK, ich mache mich mal ans Layout. Peter, ich nehme an, du hast schon
getestet ob die RAM's auch mit 3.3V gehen. Laut Datenblatt haben sie
wieder nur 5V aber 64K ging ja auch mit 3.3V
Joe
MarioS aus dem Forum64 möchte auch 3 Platinen nehmen.
Leider gehen die V53C104P nicht! Entweder doch anderes Pinout oder 3,3V
reichen nicht. Die anderen habe ich getestet und gehen.. daher habe ich
nur
ca. 16 Ram Chips.. das sollte aber auch welche sein, die im Amiga 500,
C64-II etc. verwendet wurden..
EDIT: Pinout ist gleich.. also vertragen die die 3V nicht.. :-(
Peter
for(;;) aus dem Forum64 möchte auch eine Platine.
Er wird sich sicher hier auch noch (wie hoffentlich MarioS aus dem F64)
noch
mit seiner E-Mail Adresse melden.
@Joe: Damit sollten wir mind. schon 10 Stück zusammen haben, oder?
Macht du bitte wieder die Platinen und die Sammelbestellungen?
Gruß, Peter
Peter Sieg schrieb:> Macht du bitte wieder die Platinen und die Sammelbestellungen?
Mache ich. Bis jetzt habe ich nur dich und Andreas H. auf meiner Liste.
Holger (ambrosius) mir bitte mal die Mail zukommen lassen.
Joe
Ich hätte auch gerne eine Platine!
Wäre toll, wenn ein MAX232 mit drauf wäre, dann könnte ich es direkt an
mein Lear Siegler ADM-3A Terminal anschliessen.
Nils Eilers schrieb:> Wäre toll, wenn ein MAX232 mit drauf wäre
Peter häte gerne einen Anschluß für diese Platine:
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=200393339984
Du hättest gerne einen MAX232
Ich würde lieber einen FT232 mit Stecker nehmen um sozusagen ein
CP/M-USB Stecker zu bekommen.
Vorschlag:
Die Platine bekommt an der einen Stirnseite eine Buchsenleiste für
Peters Modul. Steckbar ist dann das besagte Modul, ein MAX232 Modul oder
ein FT232 Modul, oder, oder. Was meint ihr dazu?
Gruß, Joe
@Joe: Gute Idee mit der Kontaktleiste. Max232 halte ich für veraltet.
FT232 als zu bestückende Alternative ok. MicroVGA AnschlußLeiste wäre
auch
ok aber kein Muß..
Immer daran denken,so einfach wie möglich - nur nicht einfacher.. ;-)
Und der Adapter ist für den Preis nicht zu schlagen..
Peter
Hi Leute,
eins vornweg ich finde das Projekt herrlich bekloppt und werde erstmal
ein Lochrasteraufbau fädeln. Da kommt der Tipp mit dem Modul von Peter
wie gerufen, der FT ist ja nicht so gut Lochraster geeignet (ist ja
nicht jeder Elm Chan :-) Da tut sich aber gleich eine Frage auf: Die
erhältlichen Module scheinen alle mit CP2102 bestückt zu sein. Weiß
jemand, wie gut die mit Linux laufen? Für eine professionell gefertigte
Platine könnte ich mir noch eine "alles in SMD, so eng wie es
handzubestücken geht, wenn irgendmöglich in USB-Flashstick-Format
gequetscht"-Version vorstellen ;-)
frank
Ich finde die Idee mit der Stiftleiste auch gut, würde aber auf der
Platine dann noch den FT232 mit drauf nehmen - der braucht nicht viel
Platz und wenn jemand was anderes will, kann er das über die Stiftleiste
anschliessen ohne Leiterbahnen zu durchtrennen etc.
Frank P. schrieb:> Da tut sich aber gleich eine Frage auf: Die> erhältlichen Module scheinen alle mit CP2102 bestückt zu sein. Weiß> jemand, wie gut die mit Linux laufen?
Ist kein Problem, Treiber ist seit langem im Kernel.
Es geht ja nicht darum prinzipiell eine Platine für das Projekt auf die
Beine zu stellen, das haben wir ja schon in zwei Varianten getan, siehe
hier:
http://www.mikrocontroller.net/articles/AVR_CP/M
Die Idee ist vielmehr mit einem ganz, ganz einfachen Aufbau Mitstreiter
zu finden, die auch an der Software noch etwas tun. Stichwort Z80.
Einfach soll auch heißen DIL auf Fassung um auch mal ein IC zu tauschen
oder zu testen.
Joe
Genau. Im Prinzip sehe ich die 4-bit Platine aus dem Artikel
erweitert/umgebaut auf 8-bit (andere Portbelegungen) und der
Pinheaderbereich
links über dem SD Slot dann kompatibel zu dem CP2102 USB-TTL Adapter
ausgeprägt als die hier jetzt angestrebte neue Platine. FT232+USB Buchse
ist ja parallel noch drauf..
Der Vorteil der 8-bit Version ist halt die fast verdoppelte
Geschwindigkeit
der Emulation.. womit insbesondere Arcade-like Spiele (Ladder/Pacman)
besser
spielbar werden..
Und ja, schön wäre die Erweiterung auf Z80 Emulation, die dann die Tür
öffnen
würde für z.B Turbo Pascal, Sargon Schach, etc..
BTW: In dem Artikel ist die letzte 8-bit Version mit SMD Rams und
VGA-Terminal Teil übrigens nicht dokumentiert..?
Peter
getestet schrieb:> Ist kein Problem, Treiber ist seit langem im Kernel.
Danke fürs testen ;-)
Joe G. schrieb:> Es geht ja nicht darum prinzipiell eine Platine für das Projekt auf die> Beine zu stellen, das haben wir ja schon in zwei Varianten getan, …
Ich denke die Ansprache gilt meiner "so-klein-wie-möglich-Idee". Ich
weiß, was Ihr schon alles auf die Beine gestellt habt. Dafür genießt Ihr
meinen vollen Respekt. War ja auch nur so eine Idee, falls mal jemandem
langweilig wird ;-)
> Die Idee ist vielmehr mit einem ganz, ganz einfachen Aufbau Mitstreiter> zu finden, die auch an der Software noch etwas tun. Stichwort Z80.> Einfach soll auch heißen DIL auf Fassung um auch mal ein IC zu tauschen> oder zu testen.
Kann ich nachvollziehen, und ich will Euch da auch nicht reinreden, Gott
bewahre. Zumal ich Euch bei der Software wahrscheinlich nicht viel
helfen kann. Ich finde für mich eine professionell gefertigte
Platine für alles in DIL etwas übertrieben. Nichtsdestotrotz, wenn es
neue Mitstreiter bringt und Ihr noch eine Mindeststückzahl braucht,
würde ich auch eine LP nehmen. Es sollte dann aber schon eine 8-Bit
Version sein. An Z80 wäre ich natürlich auch sehr interessiert.
frank
@alle: was ist denn eigendlich `der letzte Stand` der Software?
Im SVN:
http://cloudbase.homelinux.net/svn/avr-cpm/
steht Revision 161.
Unter avrcpm - branches gibt es 2\ und fat16-test\
fat16-test war das lesen von Diskimages von fat16 formattierten SD
Karten..
..wie ist da der Status.. wer hats getestet..?
Und 2\ = Version 2? Was war doch gleich noch mal der Unterschied zu der
ersten Version..?
Und dann gibts noch trunk\ ..?
Nun ich habe hier die Version 1, die für 4-bit und 8-bit assembliert
werden
kann.. und bis zu 4 CP/M Partitionen unterstützt.. damit werde ich
ersteinmal
die neuen 8-bit Platinen versorgen, solange mich niemand eines anderen
überzeugt.. ;-)
Peter
Peter Sieg schrieb:> @alle: was ist denn eigendlich `der letzte Stand` der Software?
Die 2.0 Version lief auf meiner 8-Bit Hardware. Problem dort war, die SD
Karten konnten nur noch unter Linux mit den CP/M Partitionen erzeugt
werden.
Für Win.. User nicht so schön.
Die fat16 Version konnte ich zwar übersetzten jedoch nicht von der SD
Karte booten. Es war für mich nicht so richtig transparent, wie und in
welchem Format das CP/M System auf die Karte kam. Für weitere
Entwicklungen fürde ich diesen Zweig lieber weiterverfolgen.
Joe
Habe mir die fat16-test Version mal gezogen und für 4-bit; m168; 30MHz;
fat16 Nutzung assembliert. Dann disk images als CPMDSK_A.IMG ..
CPMDSK_D.IMG auf eine FAT16 formatierte SD Karte kopiert und es läuft!
8-bit kann ich mangels Hardware nicht testen. ATmega88 scheint Fehler
beim
assemblieren zu geben (Funktionen werden genutzt, die erst ab 168 da
sind).
Als disk images habe ich die originalen verwendet (urspüngliches Format
von ca. 243kb).
Sieht doch schon mal gut aus! Das komplette fat16 Verzeichnis inkl. AVR
Studio 4 Projektdatei und erzeugtem Hex hänge ich hier mal an.
Peter
In froher Erwartung auf die neue AVR-cpm Leiterplatte habe ich mir das
CPM-Image auch schon eingehender angeschaut, konnte aber nirgends die
Quellen für das CPM.SYS finden. Wer hat das CPM.SYS generiert und kann
dazu auch die Quellen abgeben ?!
Danke und Grüsse,
Andreas
Peter Sieg schrieb:> Sieht doch schon mal gut aus!
Bestens Peter, werde ich heute oder morgen mal auf 8-Bit testen. Im
nächsten Schritt sollten wir die Doku "Nachbausicher" machen. Auch im
Hinblick auf solche Fragen wie von Andreas.
@Andreas
Das cpm.sys ist die Originaldatei, zu finden hier:
http://www.mikrocontroller.net/articles/AVR_CP/M
Den Quelltext dazu kenne ich auch nicht. Um das Bios zu übersetzen und
die cpm.bin Datei zu erzeugen hatten wir auch für Win Makefiles
erstelllt. Ich suche mal alles zusammen und bemühe mich eine kleine
Kurzanleitung dazu zu verfassen.
Joe
Im Anhang mein bios Verzeichnis.
(Den Quelltext von cpm.sys habe ich aber auch nicht)
Darin ist bios.asm+ipl.asm
tniasm.exe zum assemblieren
make_bios.bat zum übersetzen von ipl+bios
make_cpm.bat zum bilden von cpm.bin (nutzt dd.exe, was auch enthalten
ist)
Das Resultat cpm.bin wird dann zum bilden von diskimages mit den
cpmtools
verwendet:
mkfs.cpm.exe -f avrcpm -b cpm.bin -L test CPMDSK_A.IMG
und füllen mit:
cpmcp -f avrcpm CPMDSK_A.IMG cpmdsk/MBASIC.COM 0:MBASIC.COM
Peter
Wegen BDOS+CCP bin ich fündig geworden. Die Quellen, für Z80 angepasst,
konnte ich bei Peter Schorn (http://www.schorn.ch/cpm/intro.php) finden.
Gruss,Andreas
@Andreas: Wäre super, wenn du die benötigten Teile zusammen puzzeln
würdest, um cpm.sys zu bilden. Idealerweise auch mit einem schon
verwendeten Z80 Assembler (tniasm; z80asm).
Peter