CP/M auf ATmega88

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?

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:
> 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

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.

1

Initing mmc...

2

fat16 part found

3

fat16 scanning

4

free entrys in ptable ?

5

read fat bootblock.

6

fat16 bootblock check

7

Bytes per Sector 0200

8

Sectors per Cluster 20

9

Reserved Sectors__: 0001

10

Sectors per FAT__: 00D7

11

Ammount of FAT copies: 02

12

Max. entrys in Rootdir.: 0200

13

Begin of Volume at: 0000003F

14

Begin of FAT at___: 00000040

15

Begin of DIR at___: 000001EE

16

17

CP/M partition at: 1757875, size: 9728KB.

18

CP/M partition at: 1777406, size: 9728KB.

19

CP/M partition at: 1796937, size: 73344KB.

20

Partinit done.

21

Ok, CPU is live!

22

23

ipl

24

62k cp/m vers 2.2

25

26

A>

Grüße
Frank

Hallo,
hat sich schon jemand mit dem kleineren Teil der Platine befasst??
Ja das VGA Terminal...
Gruß
Hans- Werner

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

Halloe.

Wieder ein kleines Stück voran gekommen.

1

CP/M partition at: 1757875, size: 9728KB.

2

CP/M partition at: 1777406, size: 9728KB.

3

CP/M partition at: 1796937, size: 73344KB.

4

FAT16 File-Image at: 005, size: 256258Bytes.

5

Partinit done.

6

Ok, CPU is live!

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

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

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.

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.

Auf der gleichen Seite habe ich auch was zu zxcc von John Elliott 
gesehen:
http://hc-ddr.hucki.net/wiki/doku.php/cpm:windows

Das benutze ich schon eine Weile, um unter Linux das BIOS mit M80 zu 
assemblieren. Dieses, weil ich die Macrofähigkeiten des M80 für die 
Disk-Parameter-Tabellen nutze.

Zitat von der zxcc Homepage:
http://www.seasip.demon.co.uk/Unix/Zxcc/index.html

1

ZXCC is a two-purpose CP/M 2/3 emulator allowing:

2

 * Hi-Tech C for CP/M to be used as a cross-compiler under Unix.

3

 * The CP/M build tools (MAC, RMAC, GENCOM, LINK) to be used under DOS or Unix.

Vielleicht mag das ja mal jemand unter Windows testen.

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

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

Frank Zoll schrieb:

> - Diese Dateien müssen derzeit genau 256KB gross sein.

Nicht mehr lange:

1

A>^C

2

drvtbl (F233): F28F F652 F6A0 0000 0000 0000 0000 0000 ...

3

drvtbl (F233): F28F 0000 0000 0000 0000 0000 0000 0000 ...

4

Heap init: Start: F652,bytes free: 2478 

5

Heap get: 016, 

6

Heap get: 015, 

7

Heap get: 016, 

8

Heap get: 031, 

9

Heap get: 016, 

10

Heap get: 015, 

11

Heap get: 048, 

12

Heap get: 064, 

13

Heap get: 016, 

14

Heap get: 015, 

15

Heap get: 128, 

16

Heap get: 256, 

17

drvtbl (F233): F28F F652 F6A0 F72F 0000 0000 0000 0000 ...

18

A>stat b:

19

20

Bytes Remaining On B: 95k

21

22

A>stat c:

23

24

Bytes Remaining On C: 980k

25

26

A>stat d:

27

28

Bytes Remaining On D: 7692k

29

30

A>stat dsk:

31

32

    A: Drive Characteristics

33

 1944: 128 Byte Record Capacity

34

  243: Kilobyte Drive  Capacity

35

   64: 32  Byte Directory Entries

36

   64: Checked  Directory Entries

37

  128: Records/ Extent

38

    8: Records/ Block

39

   26: Sectors/ Track

40

    2: Reserved Tracks

41

42

    B: Drive Characteristics

43

 1944: 128 Byte Record Capacity

44

  243: Kilobyte Drive  Capacity

45

   64: 32  Byte Directory Entries

46

   64: Checked  Directory Entries

47

  128: Records/ Extent

48

    8: Records/ Block

49

   26: Sectors/ Track

50

    2: Reserved Tracks

51

52

    C: Drive Characteristics

53

 8128: 128 Byte Record Capacity

54

 1016: Kilobyte Drive  Capacity

55

  192: 32  Byte Directory Entries

56

  192: Checked  Directory Entries

57

  128: Records/ Extent

58

   16: Records/ Block

59

   32: Sectors/ Track

60

    2: Reserved Tracks

61

62

    D: Drive Characteristics

63

65472: 128 Byte Record Capacity

64

 8184: Kilobyte Drive  Capacity

65

  512: 32  Byte Directory Entries

66

  512: Checked  Directory Entries

67

  256: Records/ Extent

68

   32: Records/ Block

69

   32: Sectors/ Track

70

    2: Reserved Tracks

71

72

A>

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, …"

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.

So sieht sie aus, die Version 2.0
Joe

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

17

D: STAT     COM : SUBMIT   COM : XSUB     COM : ZORK1    COM

18

D: ZORK1    DAT

19

D>mbasic

20

39417 Bytes free

21

BASIC Rev. 4.51

22

[CP/M Version]

23

Copyright 1977 (C) by Microsoft

24

Ok

Grüße
Frank

moin,
auch ich konnte die org VGA-Software nicht
übersetzen.
mfg
Peter

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.

Egmont schrieb:
> wollte mal was über den Bootloader schreiben den ich benutze

Für welche Taktfrequenz ist der Bootloader übersetzt?

Nun brauche ich mal eine kleine Debughilfe. Hier die Debugmeldungen der 
MMC:

CPM on an AVR, v2.0
Testing RAM: fill...wait...reread...
Initing mmc...
mmcInit
mmcCMD: 00 00000000 .. 95 CMDRes: 01
mmcCMD: 08 000001AA .. 87 CMDRes: 01
mmcCMD: 37 00000000 .. 01 CMDRes: 01
mmcCMD: 29 40000000 .. 01 CMDRes: 01
mmcCMD: 37 00000000 .. 01 CMDRes: 01
mmcCMD: 29 40000000 .. 01 CMDRes: 00
mmcCMD: 3A 00000000 .. 01 CMDRes: 00
 CT: 04 InitRes: 00
mmcCMD: 11 00000000 .. 01 CMDRes: 00
CP/M partition at: 2048, size: 3024KB.
CP/M partition at: 8097, size: 4144KB.
CP/M partition at: 16385, size: 7808KB.
Partinit done.
mmcCMD: 11 00100000 .. 01 CMDRes: 00

Neustart des Systems

Was bedeutet das letzte CMD11 Kommando mit der Antwort 00 und warum gibt 
es dann enen Neustart?

@Egmont
Danke, ja das hat die Frage beantwortet.

Joe G. schrieb:

> Initing mmc...
> mmcInit
> mmcCMD: 00 00000000 .. 95 CMDRes: 01
> mmcCMD: 08 000001AA .. 87 CMDRes: 01
> mmcCMD: 37 00000000 .. 01 CMDRes: 01
> mmcCMD: 29 40000000 .. 01 CMDRes: 01
> mmcCMD: 37 00000000 .. 01 CMDRes: 01
> mmcCMD: 29 40000000 .. 01 CMDRes: 00
> mmcCMD: 3A 00000000 .. 01 CMDRes: 00
>  CT: 04 InitRes: 00

Initialisierung ok.
Kartentyp: SD, Version 2

> mmcCMD: 11 00000000 .. 01 CMDRes: 00

11 Hex --> 17 Dez --> Read Block Command
Leseadresse 00000000

CMD Result 00 == alles ok.

> CP/M partition at: 2048, size: 3024KB.
> CP/M partition at: 8097, size: 4144KB.
> CP/M partition at: 16385, size: 7808KB.
> Partinit done.
> mmcCMD: 11 00100000 .. 01 CMDRes: 00

Hier das Gleiche.
Leseadresse 00100000 == Sektor 0x800 == 2048 Dez. == 1. Sektor der 1. 
Part.

> Neustart des Systems
>
> Was bedeutet das letzte CMD11 Kommando mit der Antwort 00 und warum gibt
> es dann enen Neustart?

Die Frage läßt sich so nicht beantworten. Wenn wirklich die Karte, bzw. 
der Treiber verantwortlich sein sollte, sieht man vielleicht mit 
"MMC_DEBUG = 3" mehr.

Zweiter Versuch mit anderer Karte. Ich habe das Image mal direkt auf 00 
geschrieben und MMC_DEBUG=3 gesetzt.

CPM on an AVR, v2.0
Testing RAM: fill...wait...reread...
Initing mmc...
mmcInit SPI_CLK_SLOW <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
mmcCMD: 00 00000000 <FF <FF <FF >40 .. 95>95 <FF <01  CMDRes: 01
mmcCMD: 08 000001AA <FF <FF <FF >48 .. 87>87 <FF <05  CMDRes: 05
mmcCMD: 37 00000000 <FF <FF <FF >77 .. 01>01 <FF <01  CMDRes: 01 mmcCMD: 
29 00000000 <FF <FF <FF >69 .. 01>01 <FF <01  CMDRes: 01
mmcCMD: 37 00000000 <FF <FF <FF >77 .. 01>01 <FF <01  CMDRes: 01 mmcCMD: 
29 00000000 <FF <FF <FF >69 .. 01>01 <FF <00  CMDRes: 00
mmcCMD: 10 00000200 <FF <FF <FF >50 .. 01>01 <FF <00  CMDRes: 00 <FF
 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
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Æ

CPM on an AVR, v2.0
Testing RAM: fill...wait...reread...

Das sieht irgendwie nach dem gleichen Fehler aus. Ubrigens SPI CLK/2 
oder /4 ergibt keine Änderung.

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:

1

mmcCMD: 3A 00000000 <FF <FF <FF >7A .. 01>01 <FF <00  CMDRes: 00 <80 <FF <80 <00 <FF 

2

 CT: 04 InitRes: 00 SPI_DISABLE 

3

mmcRdSect SPI_CLK_FAST 

4

mmcCMD: 11 00000000 <FF <FF <FF >51 .. 01>01 <FF <00  CMDRes: 00 <FF <FF <FF <FE <31 <6C <FF SPI_DISABLE RdSectRes: 00 

5

Assuming CP/M image at: 000, size: 8192KB.

6

Partinit done.

7

mmcRdSect SPI_CLK_FAST 

8

mmcCMD: 11 00000000 <FF <FF <FF >51 .. 01>01 <FF <00  CMDRes: 00 <FF <FF <FE <31 <6C <FF SPI_DISABLE RdSectRes: 00 

9

Ok, CPU is live!

Das war jetzt mit V2.0. Aber mit trunk und jeweils einer SD V1.0 Karte, 
ists genauso.

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.

Alles ohne Bootloader.

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/

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 :-)

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

Ich komme immer noch nicht so recht weiter...
Auch mit der FAT-Version sieht es meim lesen der mmc merkwürdig aus. 
Anbei mal das Debug-File. Nach dem letzen CMD11 Befehl startet das 
System neu.


CPM on an AVR, v2.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
mmcCMD: 11 00007E00 .. 01 CMDRes: 00
mmcCMD: 11 00013C00 .. 01 CMDRes: 00
...
...
...
mmcCMD: 11 00017800 .. 01 CMDRes: 00
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...

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.

Leo C. schrieb:
> Mir fällt nichts mehr ein.

Dann bleibt ja nur noch die Hardware. Ich mach mich mal auf die Suche.

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:

3

DDRD  |= ( 1 << DDD5) | ( 1 << DDD6 )| ( 1 << DDD7 );

4

PORTD |= ( 1 << PD5 ) | ( 0 << PD6  )| ( 1 << PD7  );

Schade das ich das ganze nicht nachmessen kann, ich habe weder ein Oszi 
noch einen Logikanalyser zur Hand.

Grüße
Frank

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. :-)

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,

habe mal versucht, ein Foto von der Bilschirmausgabe
des VGA-Teils zu machen. Es ist ein 15" TFT.

Gruss
Peter

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:

1

# SIMH AltairZ80 Harddisk

2

diskdef simhd

3

  seclen 128

4

  tracks 2048

5

  sectrk 32

6

  blocksize 4096

7

  maxdir 1024

8

  skew 0

9

  boottrk 6

10

  os 2.2

11

end

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:

1

$ ./makeimage /dev/null myz80.img $(expr 128 \* 65536 + 256)

2

$ ./makeimage /dev/null simhd.img $(expr 128 \* 65536)

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 )

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.

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

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 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

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 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

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

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