Forum: Mikrocontroller und Digitale Elektronik CP/M auf ATmega88


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Leider habe ich von Z80 keine Ahnung..

Wenn du den 8080 kannst, ist das kein Problem. Der Z80 hat ein paar 
Befehle mehr und einen zweiten Registersatz, auf den mit einem der 
Spezialbefehle umgeschaltet werden kann.

Echte 8080-Programme laufen auf ddem Z80 ohne Änderung.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe den Thread hier von Anfang an mitverfolgt, hatte aber 
eigentlich nicht vor, mich zu beteiligen. Leider habe ich gestern in den 
von kbuchegg geposteten Source geschaut...

Gestern Abend habe ich von einem alten Speicherriegel ein DRAM (4Mx4, 
3,3V, SOJ) runtergeholt, und auf einen Lochrasteradapter fürs Steckbrett 
gelötet. Leider habe ich keinen Mega88 mehr gefunden. Deshalb bin ich 
gerade dabei, den Source auf Mega8 anzupassen.

Als Assembler benutze ich den avra unter Linux. Die aktuelle Release hat 
ein paar Macken, die in der Git-Version behoben sind.


Karl heinz Buchegger schrieb:

> Ich hab da jetzt mal eine OP-Code Tabelle mit reingenommen, aus der
> hervorgeht, welcher Befehl welche Flags beeinflusst. Im Moment bin ich
> dran, die vorhandenen Funktionseinheiten durchzugehen und zu
> kontrollieren, ob die Flagbehandlung mit dieser Tabelle übereinstimmt.

Danke dafür. Das hat mir den Einstieg deutlich erleichtert.

> Das Parity-Flag wird leider tatsächlich ziemlich stiefmütterlich
> behandelt. So wie das gemacht ist, geht das gar nicht. Es reicht einfach
> nicht aus, die Parity nur bei einer direkten Parity-Abfrage auszuwerten.
> Da muss auf jeden Fall noch nachgebessert werden.

Entweder verstehe ich da noch etwas nicht, oder die Sache wird so, wie 
Sprite_tm sich das vorgestellt hat, nicht funktionieren.
do_fetch_af:
  mov opl,z_flags
  mov oph,z_a
  rcall do_op_calcparity
  andi opl,~(1<<ZFL_P)
  sbrs temp2,0
   ori opl,(1<<ZFL_P)
  ret

Der Code wird bei "PUSH AF" verwendet. Hier wird das Parityflag 
berechnet und im Statusregister im kombinierten P/V-Flag gespeichert. 
Anschließend wird das Register auf dem Stack gespeichert.

Wenn die letzte OP vor dem PUSH eine arithmetische war, ist das V-Flag 
nach dem POP verloren (durch P-Flag vom zuletzt gespeicherten parityb 
überschrieben).

Wenn ich richtig liege, fallen mir 3 Lösungsmöglichkeiten ein.

1. Den Parity-Status (parityb) beim PUSH in einem der ungenutzten
   Statusregisterbits (Bit 3 oder 5) speichern.

2. Bei jedem Befehl merken, ob Parity gültig ist, und den Merker in
   do_fetch_af auswerten.

3. Parity bei den entsprechenden Befehlen immer sofort berechnen und das
   P/V-Flag setzen.

Persönlich tendiere ich zu 3. Im 8080-Befehlssatz sind das ja nicht so
viele Befehle, wenn auch häufig vorkommende.

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Ich habe den Thread hier von Anfang an mitverfolgt, hatte aber
> eigentlich nicht vor, mich zu beteiligen. Leider habe ich gestern in den
> von kbuchegg geposteten Source geschaut...
>
> Gestern Abend habe ich von einem alten Speicherriegel ein DRAM (4Mx4,
> 3,3V, SOJ) runtergeholt, und auf einen Lochrasteradapter fürs Steckbrett
> gelötet. Leider habe ich keinen Mega88 mehr gefunden. Deshalb bin ich
> gerade dabei, den Source auf Mega8 anzupassen.
>
> Als Assembler benutze ich den avra unter Linux. Die aktuelle Release hat
> ein paar Macken, die in der Git-Version behoben sind.

Hallo und herzlich willkommen im Mini AVR + CP/M Retro Thread ;-)

Peter

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Danke für die Begrüßung. Ich habe übers Wochenende Besuch und bin 
deshalb
noch nicht weiter gekommen. Nur ganz kurz:

Der AVRA funtioniert leider nicht richtig. Letzte Nacht habe ich dann
in meiner Verzweiflung den Atmel Windows Assembler unter Wine 
ausprobiert. Funktioniert. Prost.
Aber mein Mega8 geht noch nicht. :-(

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

um eine Struktur in die nun beginnenden Soft- und Hardwareänderungen zu 
bringen hier mein Vorschlag zur Projektseite:
http://www.mikrocontroller.net/articles/AVR_CP/M

Gruß Joe

von Martin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Auf dem Schaltplan (http://www.mikrocontroller.net/articles/AVR_CP/M) 
ist kaum etwas zu erkennen?

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Joe: Prima! Bei mir laufen gerade die Urlaubsvorbereitungen.. ;-)
Daher z.Z wenig Zeit.. bin aber schon mal sehr gespannt auf die Platinen
und wie sich die Firmware bis dahin weiterentwickelt hat..

Peter

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
@Martin
@alle

Alle aktuellen Dateien liegen hier auf dem SVN Server 
http://www.mikrocontroller.net/svn/list

Joe

von Karl H. (kbuchegg) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:


> 3. Parity bei den entsprechenden Befehlen immer sofort berechnen und das
>    P/V-Flag setzen.
>
> Persönlich tendiere ich zu 3. Im 8080-Befehlssatz sind das ja nicht so
> viele Befehle, wenn auch häufig vorkommende.

Das ist auch meine Präferenz.
Bei den 'OK' markierten Sequenzen ist das schon so.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
>> 3. Parity bei den entsprechenden Befehlen immer sofort berechnen und das
>>    P/V-Flag setzen.

> Bei den 'OK' markierten Sequenzen ist das schon so.

Hmm, ich meine, daß man hier:
do_op_inc:
  andi  z_flags, (1<<ZFL_C)       ; bis auf Carry alles auf 0
  ldi   temp, 1
  add   opl, temp
  in    temp, sreg
  mov   parityb, opl
  bst   temp, AVR_Z               ; Zero
  bld   z_flags, ZFL_Z
  sbrc  opl, 7                    ; Sign
  ori   z_flags, (1<<ZFL_S)       
  bst   temp, AVR_H               ; Half Sign
  bld   z_flags, ZFL_H
  bst   temp, AVR_C               ; Overflow
  bld   z_flags, ZFL_P
  ret
das Zwischenspeichern des Operanden in parityb sparen kann, und
bei den Befehlen AND/OR/XOR/DAA das Parityflag direkt berechnen muß.

Oder ich habe eben doch noch etwas übersehen...

von Karl H. (kbuchegg) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:

> das Zwischenspeichern des Operanden in parityb sparen kann, und
> bei den Befehlen AND/OR/XOR/DAA das Parityflag direkt berechnen muß.

Mag sein.
Ich hab mich noch nicht damit beschäftigt, wo man im Code noch einsparen 
bzw. verändern könnte/müsste.
Ich wollte nicht zu viele Veränderungen auf einmal machen. Erst mal eine 
Bestandsaufnahme bzw. den Code in eine etwas besser lesbare Form 
giessen.
Wenn im ersten Durchgang diese Dinge hier alle verschwunden sind

  andi z_flags,0b11101100

und durch besser lesbare Konstrukte in expliziter Bitnamenschreibweise 
ersetzt sind,
wenn für alle bisherigen Ausführungseinheiten dabeisteht, von welchem 
Opcode sie benutzt werden und die Flags (bis auf das Parity Flag) 
überprüft sind,
dann wäre mein nächster Schritt, die Behandlung des Parity Flags in die 
relevanten OpCodes einzubauen
gefolgt von:
  * wo gibt es offensichtliche Verbesserungsmöglichkeiten
  * restliche OpCodes implementieren

Aber das Auseinanderpfriemeln des jetzigen Codes ist mühsam.

PS: Ich kann leider von hier nicht auf das SVN-Repositor zugreifen (Ich 
schätze mal, dass da eine Firewall was dagegen hat. Das dürfte ich aber 
beim Admin nicht durchbringen).

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb :
> Mag sein.
> Ich hab mich noch nicht damit beschäftigt, wo man im Code noch einsparen
> bzw. verändern könnte/müsste.
> Ich wollte nicht zu viele Veränderungen auf einmal machen. Erst mal eine
> Bestandsaufnahme bzw. den Code in eine etwas besser lesbare Form
> giessen.

Ja das verstehe ich. Mir ging es auch nicht um einsparen im Sinne von 
Optimieren, sondern darum, daß der Code meiner Meinung nach fehlerhaft 
ist.
Ich wollte eigentlich da einsteigen, wo Du es vorgeschlagen hast und bin 
dann über die fehlerhafte P/V-Flag-Behandlung gestolpert. Es macht imho 
keinen Sinn, überall "; OK" dran zu schreiben, wenn man nachher nochmal 
alles umwerfen muß.

> PS: Ich kann leider von hier nicht auf das SVN-Repositor zugreifen (Ich
> schätze mal, dass da eine Firewall was dagegen hat. Das dürfte ich aber
> beim Admin nicht durchbringen).

Lesend gehts bei mir schon mal.

Inzwischen läuft mein Steckbrett-CP/M-AVR-Rechner. Mit ATmega8, 
12.288MHz und 3.3V. Falls jemand Interesse an meinen Anpassungen an 
Mega8 hat, würde die etwas polieren, und hier (oder im SVN) hochladen.

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Leo C.: Aber Sicher besteht daran Interesse!
Und ein Bild des Aufbaus wäre auch schön ;-)

Gruß Peter

von Karl H. (kbuchegg) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:

> Ich wollte eigentlich da einsteigen, wo Du es vorgeschlagen hast und bin
> dann über die fehlerhafte P/V-Flag-Behandlung gestolpert. Es macht imho
> keinen Sinn, überall "; OK" dran zu schreiben, wenn man nachher nochmal
> alles umwerfen muß.

OK.
Ich dachte du willst das vereinfachen.

Hmm. die P/V Behandlung sollte meiner Meinung nach bei den paar 
Anweisungen schon stimmen. Auch darauf achten, dass dieses Flag eine 
Doppelbedeutung hat.

von Joerg W. (joergwolfram)


Bewertung
0 lesenswert
nicht lesenswert
Soweit ich weiss, hat der 8080 nur ein P Flag und kein P/V. Das kam erst 
beim Z80. Damit sollten sich sogar beide Prozessoren auseinanderhalten 
lassen:
test:       sub    A               ;setzt A auf 0 (kein Overflow)
            jp     pe,code_8080    ;wenn A=0 dann ist Parity even
code_z80:   ....


code_8080:  ....

Jörg

von Leo C. (rapid)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> @Leo C.: Aber Sicher besteht daran Interesse!

Eigentlich machts ja keinen Sinn, den Mega8 zu nehmen. Bei 3,3V müßte 
man die L-Version nehmen, und die geht offiziell nur bis 8 MHz.

Andererseits passt das ja ganz gut zu diesem sinnlosen Projekt. :)

> Und ein Bild des Aufbaus wäre auch schön ;-)

Wieso? ;) Bei 2 ICs und einer SD-Karte gibts doch gar nichts zu sehen.
Ich habe keine brauchbare Kamera. Aber gestern Morgen war mein Besuch 
(mit Kamera) noch da, und da habe ich vorsorglich ein paar Bilder 
gemacht. Allerdings war das RAM da noch nicht verdrahtet.

von Leo C. (rapid)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:

> Hmm. die P/V Behandlung sollte meiner Meinung nach bei den paar
> Anweisungen schon stimmen.

Da habe ich eben bedenken.

> Auch darauf achten, dass dieses Flag eine
> Doppelbedeutung hat.

Im jetzigen Programm werden V-Flag und P-Flag getrennt gespeichert.
V im Statusregister und P in "parityb".
Bei PUSH AF wird P ins Statusregister kopiert und auf den Stack 
gespeichert.
Nach einem anschließenden POP AF ist ein evtl. vorher berechnetes V-Flag 
hinüber.

Bei reinen 8080-Programmen dürfte das keine Rolle spielen, da sie ja 
kein
V-Flag kennen. Aber dann kann man sich die V-Flag-Ermittlung auch 
sparen.
Und bei (zukünftigen) Z80-Programmen wirds dann fehlerhaft.

Voller Z80-Befehlsatz wäre schon interessant, da z.B. Turbo Pascal nur 
auf Z80 läuft.

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So sieht sie aus, die erste bestückte Platine.

Joe

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sieht doch super aus!

Peter

von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mal ne Frage, ohne euch ärgern zu wollen:
Warum habt ihr dem schönen Platinchen keinen VGA-Ausgang und PS2 Eingang 
gegönnt? Ein zweiter Atemga8 hätte diese Funktion gut erfüllt. Dann wäre 
es ein richtig schöner Stand-Alone Computer.

Gruß,
Markus

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
> Mal ne Frage, ohne euch ärgern zu wollen:

Die Antwort findest Du ausführlichst, wenn Du den Thread hier liest.
Der zweite Teil wird schwierig...

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Juchhu,
DDT kann jetzt Programme tracen.

Der DAA-Befehl hatte gefehlt, und im RST-Befehl war ein kleiner Fehler.

von Leo C. (rapid)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe im BIOS mal die Warmboot-Funktion ergänzt (CCP + BDOS neu 
laden).

Wer einen funktionierenden Warmboot haben möchte, kann das angehängte
BIOS installieren.

von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>>Warum habt ihr dem schönen Platinchen keinen VGA-Ausgang und PS2 Eingang
>>gegönnt? Ein zweiter Atemga8 hätte diese Funktion gut erfüllt. Dann wäre
>>es ein richtig schöner Stand-Alone Computer.

>Die Antwort findest Du ausführlichst, wenn Du den Thread hier liest.
>Der zweite Teil wird schwierig...

Man könnte ja auch ein zweit-Platinchen basteln. Auf der Seite sind da 
ja die RX-TX Anschlüsse zugänglich. Da könnte man ja ein Terminal 
anschließen:

http://www.serasidis.gr/circuits/TV_terminal/Small_TV_terminal.htm
http://tinyvga.com/avr-sdram-vga

von Martin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
In dem Assemblerfile "" sind einige Adressen festgelegt:

ccp:  equ  $3400+bias  ;base of cpm ccp
bdos:  equ  ccp+$806  ;base of bdos

Wo liegt den nun CP/M?

von Martin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
In dem Assemblerfile "bios.asm" sind einige Adressen festgelegt:

ccp:  equ  $3400+bias  ;base of cpm ccp
bdos:  equ  ccp+$806  ;base of bdos

Wo liegt den nun CP/M?

von spess53 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi

BDOS gehört zum CP/M (+BIOS und CCP).

MfG Spess

von Martin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antwort: ich habe jetzt eine Seite gefunden 
(http://www.dcast.vbox.co.uk/cpm.html) die näher auf die Adressen 
eingeht .

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Leo C.: Prima! Super, das jetzt auch der Warmstart geht.. kannst du 
bitte auch das assemblierte Bios.bin hier einstellen.. Welchen Z80 
Assembler hast du genommen (Link)?

Danke+Gruss aus Teneriffa,
Peter

von Leo C. (rapid)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> @Leo C.: Prima! Super, das jetzt auch der Warmstart geht.. kannst du
> bitte auch das assemblierte Bios.bin hier einstellen..

Das brauchst Du aber nicht auf Teneriffa? Hoffe ich doch für Dich.

> Welchen Z80 Assembler hast du genommen (Link)?

http://www.nongnu.org/z80asm/

Ich habe den genommen, der in meiner Linux Distri drin ist. Sprite_tm 
nimmt wohl den gleichen. Jedenfalls lief sein Makefile damit fehlerfrei 
durch.
Das Teil ist aber in der Tat etwas eigenartig.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:

> Zu einem anderen Aufbau sehe ich das aber letztlich genauso.. was
> ein 'fauler' Kompromiss ist und viel Rechenpower kostet muß durch
> etwas besseres ersetzt werden.. Da kann man beim Ram auch z.B über SRAM
> nachdenken.. dann braucht man keinen Refresh mehr..

Mit dem Refresh habe ich mich letze Woche ausgibig beschäftigt. Der 
kostet
so gut wie nichts. Ich habe auch mal "hidden refresh" realisiert. Das 
lohnt
einfach nicht. Und für die Zeiten, in denen mal keine RAM-Zugriffe
sind (zB. Disk-I/O), bräuchte man den normalen Refresh doch noch.

Viel sinnvoller wäre es, die verwurstete Port-Zuordnung zu verbessern.

Wie's richtig gut geht, findet man (mal wieder) auf der auch hier 
allseits
bekannten Seite von Chan.

von TheMason (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Leo

>Viel sinnvoller wäre es, die verwurstete Port-Zuordnung zu verbessern.


Dazu mal eine Frage.
Ist es nicht letztenendes egal wie die Port-Zuordnung zwischen AVR und 
DRAM ist ?
Es sind zwar die Adress-Leitungen vertauscht, aber im Prinzip macht es 
ja nichts aus, solang beim Schreiben und beim Lesen die gleiche 
Zuordnung verwendet wird. Oder hat das Auswirkungen auf den Refresh 
(sprich das sequentiell eine Row nach der anderen Refresht werden muß, 
und sobald Rows übersprungen werden gehen daten verloren oder ist das 
unabhängig davon das sie zu einem anderen Zeitpunkt (aber dann dennoch 
im selben zeitlichen Raster) refresht werden.
Also nach meinem Verständnis müsste es eig. egal sein wie die Zuordnung 
der Adress-Leitungen ist. Hauptsache sie ist beim Schreiben/Lesen 
gleich, und alle Rows werden im festen Raster (aber unterschiedliche 
Reihenfolge) refresht.
Ich gestehe aber das ich mir den DRAM-ASM Code noch nicht angeguckt 
habe. Hatte nur im Schaltplan gesehen das es etwas "Kraut und Rüben" 
war.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
TheMason schrieb:

> Dazu mal eine Frage.
> Ist es nicht letztenendes egal wie die Port-Zuordnung zwischen AVR und
> DRAM ist ?

Im Prinzip schon. Das beweist ja auch die Originalschaltung.

Wenn aber zB. die 8 niederwertigen Adressleitungen auf einem Port liegen
würden, könnte man sie zusammen mit einem out-Befehl ausgeben.
Ansonsten muß man die Addresbits durch Bitschiebereien oder 
Einzelbit-tests
und -Sets auf die verstreuten Addressleitungen verteilen.

Beim ATmega88 kann man allerdings bei keinenm einzigen der 3 Ports alle
Bits zusammenhängend verwenden. Auf Port B liegt der Quartz, auf Port D
die serielle Schnittstelle, und Port C hat überhaupt nur 6 Bit (wenn man 
nicht auf Reset verzichten will, sonst halt 7).

Bei den Adressen kann man hier also gar nicht so viel verbessern.

Die Datenbits sind bei der Schaltung aber auch unglücklich verteilt.
Wenn man WE mit einer der Datenleitungen tauscht, liegen die 4 
Datenleitungen
auf dem unteren Nibble eines Bytes.

Dann kann man die zwei Hälften eines Bytes zB. so einlesen

  in  temp,PINC        ; 1. Nibble einlesen (untere Hälfte von PC)
  andi temp,0x0f       ; obere Hälfte wegmaskieren
  swap temp

        ;Adressen umschalten ...

  in  temp2,PINC       ; 2. Nibble einlesen
  andi temp2,0x0f
  or  temp,temp2       ; Beide Hälften zusammen

Zusammen 6 Befehle, 6 Takte.
Im Originalprgramm gibt es ein Unterprogramm, das zwei mal aufgerufen
wird:
;...
  rcall dram_getnibble  
  swap temp

        ;Adressen umschalten ...

  rcall dram_getnibble  

        ; ...
;...

dram_getnibble:
  andi temp,0xf0
  sbic pinc,ram_d0
   ori temp,0x1
  sbic pinc,ram_d1
   ori temp,0x2
  sbic pinc,ram_d2
   ori temp,0x4
  sbic pinc,ram_d3
   ori temp,0x8
  ret


Auch wenn man den Unterprogrammaufruf wegläßt (man könnte ja den Code 
direkt einfügen), sind das schon 1 + 2x9 = 19 Takte.

Die Adressen-Ausgabe und -Umschaltung kann man aber auch noch deutlich
optimieren. Auch ohne Harwareänderung.

Durch die Änderungen habe ich eine Geschwindigkeitsverbesserung bei 
CP/M-Programmen von fast 50% erreicht.

Den Code dazu will ich nachher noch posten. Jetzt ist erst mal Mittag.

von TheMason (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Leo

Guten Hunger.

Na ja. Die Adress-Pin-Belegung ist wirklich nicht die glücklichste. Wär 
dann vllt was für eine Folge-Version :-)

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Leo C. nein, brauch ich hier nicht.. aber wenn ich zurueck bin.. :-)
Da faellt mir ein, das ich auch gerne das 2te asm Programm als BIN Datei
haette (war glaube ich cpm.asm -> cpm.bin), dann man ueber die cpmtools 
auch ersteinmal ohne z80 Assembler eine neues diskimage erstellen..

Das mit den 50% hoert sich ja schon mal super an!

Gruss Peter

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
TheMason schrieb:
> Na ja. Die Adress-Pin-Belegung ist wirklich nicht die glücklichste. Wär
> dann vllt was für eine Folge-Version :-)

Ja, nachdem ich mir das jetzt nochmal angeschaut habe, glaube ich auch,
daß eine neue Sortierung einiges bringen würde. An einen Punkt hatte ich
heute Mittag nicht gedacht: Die Originalroutinen sind auch deshalb 
langsam,
weil Sprite_tm viele NOPs im eingefügt hat. Alleine das weglassen der
überflüssigen NOPs dürfte den Zugriff schon deutlich beschleunigen.

von Leo C. (rapid)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> @Leo C. nein, brauch ich hier nicht.. aber wenn ich zurueck bin.. :-)
> Da faellt mir ein, das ich auch gerne das 2te asm Programm als BIN Datei
> haette (war glaube ich cpm.asm -> cpm.bin), dann man ueber die cpmtools
> auch ersteinmal ohne z80 Assembler eine neues diskimage erstellen..

Siehe Anhang.
Ich hoffe, es ist das richtige. Das bios ist da schon mit drin.

von bix (Gast)


Bewertung
0 lesenswert
nicht lesenswert
TheMason schrieb:
> Na ja. Die Adress-Pin-Belegung ist wirklich nicht die glücklichste. Wär
> dann vllt was für eine Folge-Version :-)

Die ungünstige Belegung vom RAM zu den Ports wurde hier schon 
diskutiert, siehe diverse Posts vom 12.06.2010 und folgende.

Aus diesem Grund wurde auch das Layout geändert und Platz für ein paar 
Jumper geschaffen, um zwischen alter und neuer Belegung umzuschalten.

Die ungünstigen Leitungen zum AVR sind gegenüber dem ersten Layout von 
Joe auf die Lötseite verlegt, so dass man auch bei bestücktem Board 
nachträglich noch Leiterbahnen auftrennen und Patchen kann.

Gruß, bix

von Leo C. (rapid)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Im Anhang ist mein aktueller Softwarestand. Es sind eine Menge 
Änderungen und Erweiterungen. Sicher wäre es besser gewesen, die 
Änderungen schrittweise zu posten, aber das schaffe ich wohl nicht.

Erst mal das wichtigste:
Im CPU-Emulator habe ich alle Flags so eingestellt, daß
sie sich (möglichst) wie auf einem 8080 verhalten. Der Emulator kann 
bisher nur 8080, und Software, die anhand der Flags glaubt, einen Z80 
unter sich zu haben, fällt mit großer Wahrscheilichkeit aufs Kreuz, wenn 
wie Z80-Befehle dann nicht da sind. Und diese Software gibts für CPM.
(siehe auch 
Beitrag "Re: CP/M auf ATmega88")

Der 8080 Befehlssatz ist jetzt komplett und weitere Fehler habe ich 
keine mehr gefunden. (Was aber nichts heißen muß.)

Jetzt kommen meine Spielereien:

* Schnellere DRAM-Routinen
  Geht jetzt nur, wenn man am Prozessor 2 Leitungen vertauscht.
  Sonst muß man die alten Routinen verwenden.
  Es könnte sein, daß das Timing für sehr langsame (alte) RAMs zu scharf
  eingestellt ist. Das muß nochmal überprüft und evtl. geändert werden.

* Interrupt und Empfangspuffer für USART Input.
  Mich hats einfach genervt, das immer Zeichen verloren gehen, wenn man
  mit der Maus in die CP/M-Console pasted.

* Timer-Interrupt mit 1ms Auflösung. War in erster Linie für
  Performance-Messungen gedacht, kann aber auch als Echtzeituhr 
verwendet
  werden. 32 Bit Sekundenzäler ala UNIX time_t. Nachdem ich das fertig
  hatte, habe ich beim simh Altair 8800 Simulator
  (http://www.schorn.ch/cpm/intro.php, tolles Teil übrigens)
  noch eine andere Idee gesehen, die ich dann auch noch eingebaut habe:
  Man kann vom CP/M aus einen Timer triggern, der ggf. die abgelaufene
  Zeit auf die Console schreibt.

Folgende DEFINEs kann man dem Assembler auf der Befehlszeile mitgeben
(Make-/Projektfile):

DRAM_DQ_ORDER :  0 = Original Pinbelegung. 1 = WE und DQ1 vertauscht.
  D.h. auf PC0..PC4 sind die DRAM-Datenbits.
  In meinem DRAM-Datenblatt heißen die Datenleitungen DQ und sind
  von 0 bis 3 durchnumiert.
  Achtung: Bei Sprite_tm (und im Datenblatt seines DRAMs) laufen
  die Nummern von 1 bis 4.
  Bei der alten Pinbelegung (DRAM_DQ_ORDER = 0) werden die alten
  Routinen verwendet, sonst die neuen. Wer es anders haben möchte,
  kann ja mal nach "CLASSIC_DRAM" suchen. Neue Software mit alter
  Pinbelegung geht aber nicht. Das habe ich zwischendurch mal
  rausgeworfen, als ich bei den vielen #if/#else den Durchblick
  verloren hatte.

Target-CPU : atmega8, atmega168 oder atmega88. Default ist atmega88
  Ich habe nur atmega8 getestet, weil ich die anderen erst
  bestellen müßte (Oder ein anders Gerät fleddern :).

F_CPU : Taktfrequenz. Default ist 20MHz

BAUD :  Default ist 38400

Im Programm gibts noch weitere Macros:

REFR_RATE : DRAM Refresh-Rate. Eingestellt sind die üblichen 15.6µs,
  entspr 64KHz. Um den Interrupt-Overhead etwas zu reduzieren, wird
  der Timer auf die halbe Rate programmiert, und dann immer 2 Reihen
  auf einmal aufgefrischt.

EM_Z80 : Auf 1 setzen, wenn man einen 8080 mit Z80-Flags testen will.
  (Oder wenn man alle Z80-Befehle eingebaut hat :)

Kritik in Form von Patches willkommen.

von Leo C. (rapid)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Update: Der Timer wird jetzt in einem vernünftigen Format ausgegeben.
  Die Uhr (Uptime) ist der Einfachheit halber im gleichen Format.

Außerdem hänge ich noch ein kleines Progrämmchen an, mit dem man den
Timer bedienen kann.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Hier mal ein kleiner Test.

Im Debugger habe ich folgende kleine Schleife laufen lassen:
MVI A,01        ;
OUT 40     ;Start Timer         Takte
LXI H,0000      ;               10
DCX H           ;               6  -\
MOV A,H         ;               4   |
ORA L           ;               4   |
PUSH PSW        ;               10  | 44 * 65536  =  2883584
POP PSW         ;               10  |
JNZ 0107        ;               10 -/
MVI A,02        ;               7
OUT 40     ;Stop Timer          11
NOP             ;               gesamt Anzahl Takte: 2883612

Und das hier kam raus:
--------------------------------------------------------------------
AVR Atmega mit |                12,288 Mhz              |   20 MHz  
---------------+------------+----------------+----------+-----------
               | Laufzeit        Laufzeit        Z80         Z80
               |  Gesamt        pro Z80 Takt    Speed       Speed
---------------+-----------------------------------------------------
Orig. DRAM R/W | 17,187 s        5,960 µs      168 KHz     273 KHz
Neue  DRAM R/W |  9,806 s        3,401 µs      294 KHz     478 KHz
---------------+-----------------------------------------------------
simh AltairZ80 |  0,022 s        7,629 ns      131 MHz

Zum Vergleich habe ich noch die Zahlen von einem Simulator auf meinem
PC dazugetan. (08/15 PC mit 2,5MHz Athlon 4850e)

Mein AVR läuft nur mit 12,288 MHz. Deshalb habe ich die Zahlen noch für
20MHz hochgerechnet. Die Zahlen erscheinen mir durchaus plausibel, wenn
ich an die Geschwindigkeit von meinem 4MHz CP/M-Rechner zurückdenke.

Ganz oben hat Jörg Wolfram geschrieben, daß er mit einem AVR ca. 2MHz
Z80-Geschwindigkeit erreicht hat. Na, dann gibts hier ja noch einiges
an *Spiel*raum...

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
@alle
Die Platine scheint fehlerfrei zu sein. CP/M bootet auch mit 24 Mhz 
externen Takt über den USB Treiber. Bei alten SD Karten schlägt bei der 
MMC Initialisierung das Timeout zu (Karte läßt sich für eine Antwort zu 
lange Zeit).
Die neue Software (mit alter Hardware) von Leo C. läuft bei mir noch 
nicht. die ipl Meldung kommt nicht. Mal suchen...

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Die neue Software (mit alter Hardware) von Leo C. läuft bei mir noch
> nicht. die ipl Meldung kommt nicht. Mal suchen...

Welche hast Du denn versucht? Und mit welchem Prozessor?
Ich frage deshalb, weil wir es mal vom Mega168 hatten, und ich bei der
Auswahl desselben einen dämlichen Fehler eingebaut habe.

Hast Du den Ramtest eingeschaltet?

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Deine Version vom 01.07, der Option DRAM_DQ_ORDER = 0, und dem Mega168.
Der Ramtest war eingeschaltet und läuft auch fehlerfrei durch.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Deine Version vom 01.07, der Option DRAM_DQ_ORDER = 0, und dem Mega168.

#elif defined atmega168
  .include "m8def.inc"

Bitte .include korrigieren. :-(

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
... hatte ich schon geändert. Muß noch was anderes faul sein.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Versuchst Du das auch mit 24 MHz? Kannst Du evtl. langsamer testen?
Und welchen RAM-Chip hast Du (Genaue Typbezeichnung mit Speed-Code)?

von nix_könner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
hab ich es überlesen?
Gibt es Alternative(n) zu dem verbauten DRAM Chip?
Welchen SRAM müsste ich z.B. nehmen? Und wie anschließen (mit einem 
Multiplexer, oder Latchs?), damit die Software nicht geändert werden 
muss?

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
nix_könner schrieb:
> Gibt es Alternative(n) zu dem verbauten DRAM Chip?

Ja, größere, und evtl. (aber eher nicht) kleinere DRAMs.

Auf die Schnelle habe ich 1MBit bis 16MBit gefunden.
Und natürlich gibts die in verschiedenen Geschwindigkeiten.
Und dann auch noch 3,3V und 5V VCC. Wobei die 5V-Typen hier auch mit
3.3V laufen. Aber die Spannung dürfte auch wieder Einfluß auf die
Zugriffszeiten haben.

> Welchen SRAM müsste ich z.B. nehmen? Und wie anschließen (mit einem
> Multiplexer, oder Latchs?), damit die Software nicht geändert werden
> muss?

SRAM macht bei diesem Projekt überhaupt keinen Sinn. Der Witz ist hier
ja gerade, daß man mit 2 Billigchips auskommt.

von nix_könner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke Leo. Dann muss ich mal suchen.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
PS/2 SIMs sind eine gute Quelle.
Ich habe meinen Chip (1MBit x 4)von einem 32MB Modul runtergelötet. Da 
sind jetzt noch 15 Stück drauf. Weitere Riegel liegen hier auch noch 
rum.

@all
Ich habe also welche übrig. Wer sonst keine findet...

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
@Leo C.
Ich habe heute nochmal beide RAM Varianten getestet. Gestern war der 
Ramtest leider doch aus.

Testumgebung: einmal 8 Mhz Takt / einmal 24 Mhz Takt
Ergebnis Taktunabhängig

RAM-Test alte Variante:
23 < 00
23 < 01
22 < 02
23 < 03
26 < 04
27 < 05
26 < 06
Es sieht also so aus, ob Bit 5 und Bit 1 immer 1 sind.

RAM-Test neue Variante:
00 < 00
00 < 01
00 < 02
00 < 03
als ob er überhaut nicht angesprochen wird. Ich werde mal WE an den Oszi 
klemmen.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> @Leo C.
> Ich habe heute nochmal beide RAM Varianten getestet. Gestern war der
> Ramtest leider doch aus.

Aha, so macht es mehr Sinn.

> Testumgebung: einmal 8 Mhz Takt / einmal 24 Mhz Takt

Bei 24Mhz ist der Refresh bei langsamen RAMs an einer Stelle an der 
Grenze. Die Schreib/Leseroutinen von Sprite_tm haben Luft ohne Ende. Die 
gehen wahrscheinlich auch bei 100MHz noch. Und meine Routinen nimmst Du 
ja nicht.

> Ergebnis Taktunabhängig
>
> RAM-Test alte Variante:
> 23 < 00
> 23 < 01
> 22 < 02
> 23 < 03
> 26 < 04
> 27 < 05
> 26 < 06
> Es sieht also so aus, ob Bit 5 und Bit 1 immer 1 sind.

Das ist das Bit, das ich mit WE getauscht habe. Ich hab mir das jetzt
nochmal genau angeschaut (Assembler Listing). Testen kann ich leider 
nicht. Ich meine, daß bei "DRAM_DQ_ORDER = 0" alle Bits an der richtigen 
Stelle für die Originalschaltung sind.

> RAM-Test neue Variante:
> 00 < 00
> 00 < 01
> 00 < 02
> 00 < 03
> als ob er überhaut nicht angesprochen wird. Ich werde mal WE an den Oszi
> klemmen.

Daß, das gehen sollte, stand ja nie zur Diskussion.



> Deine Version vom 01.07, der Option DRAM_DQ_ORDER = 0, und dem Mega168.
und
>  .include "m8def.inc"
> ... hatte ich schon geändert.

Das gibt beim Übersetzen noch einen Fehler:
| avr-m8_z80.asm(1230): error: Old harware can not work with new software!

Die Zeile 1230 und drumherum müßtest Du also auch geändert haben, sonst 
hättest Du nicht fehlerlos übersetzen können. Man kann diese 
"Sicherheitsabfrage" einfach rauswerfen. Darüber wird (bei DRAM_DQ_ORDER 
= 0) der richtige (dh. der Originaltreiber von Sprite_tm) genommen. Das 
meine Routinen mit der Originalpinbelegung nicht gehen, hatte ich ja 
schon geschrieben.

Sonst fällt mir dazu nichts mehr ein. Wenn die Hardware mit dem 
Originalprogamm funktioniert, dann müßte sie mit meinem Programm und den 
oben beschriebenen Anpassungen auch laufen.

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Das 4:0 hat es gebracht. Die Variante "DRAM_DQ_ORDER = 0" geht nun. War 
mein Fehler, 0 und 1 vertauscht. Die neue Variante "DRAM_DQ_ORDER = 1" 
natürlich mit den beiden getauschten Leitungen bringt immer noch
> 00 < 00
> 00 < 01
> 00 < 02
> 00 < 03
bei RAMORG 1. Bei RAMORG 0 kommt nicht mal mehr eine Ausschrift, hängt 
sich irgendwo ganz auf.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:

> bei RAMORG 1. Bei RAMORG 0 kommt nicht mal mehr eine Ausschrift, hängt
> sich irgendwo ganz auf.

RAMORG=0 ist sozusagen ungetestet. Das hätte ich wohl rauswerfen sollen.
RAMORG=1 sollte aber wirklich funktionieren.

Allerdings kommen hier so langsam die Zugriffzeiten, die genaue 
Chiporganisation usw. ins Spiel....

> Und welchen RAM-Chip hast Du (Genaue Typbezeichnung mit Speed-Code)?

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:

>> Und welchen RAM-Chip hast Du (Genaue Typbezeichnung mit Speed-Code)?

einen MT4C4256-80

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
> einen MT4C4256-80

Da dürfte es eigentlich keine Timing-Probleme geben.
Kannst Du Die Schaltung probeweise mit 5V betreiben?
Dann ohne SD-Karte um zu sehen, ob sie dann über den RAM-Test kommt.

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Kannst Du Die Schaltung probeweise mit 5V betreiben?
> Dann ohne SD-Karte um zu sehen, ob sie dann über den RAM-Test kommt.

Auch mit 5V ohne Erfolg.
Ich habe nun mal die Signale am RAM und am AVR gemessen. Wenn das 
Programm in den Ramtest läuft liegt /WE ständig auf Low und I/O1 bis 
I/O4 liefert keine Daten bzw. es kommen keine vom AVR. /RAS und /CAS 
liegen aber normal an.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Wenn das Programm in den Ramtest läuft liegt /WE ständig auf Low
> und I/O1 bis I/O4 liefert keine Daten bzw. es kommen keine vom AVR.

Du hast anscheinend ein andere Programm als ich. ;)

Du könntest mal schauen, ob die entsprechenden Portbits als Ausgänge 
programiert werden, und zb. an der WE-Leitung auch High-Pegel ausgegeben 
werden. Bei mir ist das der Fall.

[avr-m8_z80.lst]
                 ; - Setup Ports
...
000045 e300        ldi temp,PC_OUTPUT_MASK
000046 b907        out DDRC,temp

...

                 dram_write:
0002f6 94f8        cli
...
0002f7 b117        in temp2,DDRC               ;DRAM data ports as outputs
0002f8 601f        ori temp2,RAM_DQ_MASK
0002f9 b917        out DDRC,temp2
...
000340 9a44        sbi PORTC,ram_w
...
000342 b107        in temp,DDRC
000343 7f00        andi temp,~RAM_DQ_MASK
000344 b907        out DDRC,temp
000345 b108        in temp,PORTC
000346 7f00        andi temp,~RAM_DQ_MASK
000347 b908        out PORTC,temp

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Im Anhang der derzeit aktuelle Softwarestand:

Die Änderungen umfassen die Änderungen von Leo C. (siehe oben), die 
Änderungen für ein korrektes Timing des MT4C4256-80 und die Änderungen 
zur korrekten Initialisierung der SD-Card. Damit sollten nun auch alte 
langsame Karten zuverlässig laufen.

Bei Hardwareänderungen bitte beachten:
/WE (PC1 – Pin 24) wird mit IO3 (PC4 – Pin 27) getauscht. Auf der 
Leiterplatte auch an den rechteckigen Durchkontaktierungen erkennbar.
Welche RAM-Version benutzt wird kann als Compileroption angegeben 
werden.

Kritik erwünscht

von volkerp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
FÜr den PMD-85, ein tchech. Homecomputer der 80er Jahre, gibt es einen 
Emulator auf AVR-Basis (http://pmd85.topindex.sk/)

Dieser emuliert ebenfalls einen 8080-Prozessor. Vielleicht wäre dieses 
Projekt auch einen Blick wert?

VolkerP

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Was die Leute alles so nachbauen.... :-)

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Neuigkeiten

Ich habe "meine" Sourcen in ein SVN gestellt auf daß man hier zugreifen 
kann:
http://cloudbase.homelinux.net/viewvc/avr-cpm/trunk/

Meine Änderungen kann man dort nachlesen. Wer Fehler findet, der ...
muß sie nicht behalten, sondern darf sie gerne hier mitteilen und am 
Besten gleich korrigieren. Ich werde die nächsten Tage nicht dazu 
kommen.

Ich habe eine radikal geänderte Portbelegung getestet. Das Konzept dazu 
habe ich (mal wieder) bei Chan abgekupfert:
http://elm-chan.org/works/vp/report.html

Der Geschwindigkeitsgewinn ist nicht überwältigend, aber doch 
beachtlich. Und als Belohnung gibt es 3 freie Ports.

Hier mal die Ergebnisse mit meiner weiter oben geposteten, nicht 
repräsentativen Testschleife:

AVR Atmega mit 20 MHz:
-----------------------------------------------------------------------
                            | Laufzeit        Laufzeit         Z80
                            |  Gesamt        pro Z80 Takt     Speed
----------------------------+------------+----------------+------------
Letzter Stand:              |  5,921 s         2,05 µs       478 KHz
aktuell: (trunk 28)         |  3,239 s         1,12 µs       890 KHz
geänderte Portbelegung:     |  2,974 s         1,03 µs       969 KHz
(experimental 25)              |

Inzwischen habe ich einen 20MHz Quarz an meinem Mega8 
(undervoltaged/overclocked :). Mit 24.5 MHz macht er allerdings die 
Grätsche.

Den 1MHZ 8080/Z80 wird man mit dem jetzigen Konzept von Sprite_tm 
wahrscheinlich noch erreichen können. Für die 2 MHz wird man wohl den 
schönen Interpreter wegwerfen/total umkrempeln müssen.

Auf jeden Fall gibts noch viel zu tun. Für den Fall, daß jemand 
Langeweile hat, hänge ich einfach mal meinen uneditierten Merkzettel mit 
ein paar Ideen an. Die Liste ist sicher nicht vollständig.

Wünsche schönes Wochenende


avr_cpm Wunschliste
-------------------

• USART IO per Interrupt
    (DONE für Input)

• DRAM
  ∘ Adress- und Daten-Ports neu sortieren für schnelleren Zugriff
  ∘ Adress- und Datenleitungen multiplexen: --> 4 freie Ports
    (ist ohne Performanceverlust möglich)
  ∘ memRead/WriteWord?
  ∘ Memory block transfer?

• DEBUG/trace steuerbar durch Z80-Programm?
  (Über IN/OUT-Interface)

• Andere (größere) Disk-Formate
  dpb muß für avr zugänglich sein?

• Register umorganisieren
  ∘ für effizienteren code
  ∘ R1 als 0-Register? (wie gcc-avr)

• Source aufteilen
  ∘ console I/O (USART)
  ∘ mmc
  ∘ dram
  ∘ z80 emu (?)

• Z80 Befehle

• bios sector blocking/deblocking (avr)

• Mehrere CP/M-Laufwerke auf einer SD ?
  ∘ CP/M-Images in FAT-Dateisystem
  ∘ Diskimages hintereinander kopieren

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo. Bin wieder da ;-)
Habe mir gerade den aktuellen Stand von avr_cpm.asm (Joe G.) gezogen und
versucht ersteinmal für die original HW zu assemblieren mit:
#ifndef DRAM_DQ_ORDER      /* If this is set to 1, the portbits  */
  #define DRAM_DQ_ORDER 0    /* for DRAM IO3 and WE are swapped.    */
#endif

dabei bekomme ich:
C:\E\AVR\avr-cpm\avrcpm\avr\z80.asm(1253): error: Old harware can not 
work with new software!

???

Ich finde die Optionen zur DRAM Selektion SEHR unübersichtlich!
Das versteht doch kein Mensch mehr.. da müssen andere Namen+mehr 
Erläuterungen in den ASM Quellcode..

Nun, was muß ich wie setzen, um ersteinmal für die original HW zu 
assemblieren??

Danach wollte ich dann mal probieren PC1 + PC4 zu tauschen.
Das sollte dann wohl mit #define DRAM_DQ_ORDER 1 gehen?

Peter

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ok. Habe mit DRAM_DQ_ORDER 1 assembliert und PC1 und PC4 getauscht.
Damit läufts und MBASIC arbeitet jetzt!! Hurra!

Super Arbeit! Vielen Dank dafür ;-)

Trotzdem wäre es schön, wenn die original HW über die entsprechende 
Option
weiterhin nutzbar wäre mir der neuen SW...

Jetzt müssen nur noch die Platinen kommen.. dann gehts weiter...

Peter

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
@Peter

Wilkommen im Backofen!

Die alte HW Variante läuft auch mit der von Dir gezogenen 
Softwareversion. Gib einfach unter Assembler Optionen  -DDRAM_DQ_ORDER=0 
ein.
Damit wird CLASSIC_DRAM = 1 gesetzt. Ja, ist unglücklich, einmal 0 und 
einmal 1. Die Software geht nun auch ohne Pintausch.
Zusätzlich mußt Du noch die Fehlermeldung deaktivieren!

; ------------------ DRAM routines -------------
; TODO:

#if DRAM_DQ_ORDER == 1
 #define CLASSIC_DRAM 0
#else
 #define CLASSIC_DRAM 1    /* Change manualy, if you want new hw w/ old 
sw */
#endif


Die Abfrage hier kannst du streichen

; #if DRAM_DQ_ORDER == 0
;  #if CLASSIC_DRAM == 1
;    #error "Old harware can not work with new software!"
;  #endif
; #endif

Die Hardware ist auf dem Wege zu Dir.

Gruß
Joe

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke Joe.

Die von dir genannte Abfrage, welche den Fehler produziert MUSS dann 
aber
raus, da ich ja zuerst mit DRAM_DQ_ORDER = 0 nicht erfolgreich 
assembliert hatte.. ;-)

Peter

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Die von dir genannte Abfrage, welche den Fehler produziert MUSS dann
> aber
> raus, da ich ja zuerst mit DRAM_DQ_ORDER = 0 nicht erfolgreich
> assembliert hatte.. ;-)

Vergiß den Kram einfach. Zieh Dir lieber mal das hier, und sag
Deine Meinung dazu:

http://cloudbase.homelinux.net/viewvc/avr-cpm/trunk/avrcpm/avr/

[edit]
Ich sehe gerade, daß beim aktuellen Stand bei den #defines oben die 
Pintauschmöglichkeit über "DRAM_DQ_ORDER" noch drin ist, die 
Schreib/Lese-Routinen das aber nicht mehr unterstützen.
Falls ein überwältigendes Interesse daran besteht, die äußerst 
unpraktische Originalpinbelegung am Laufen zu halten, werde ich das 
vielleicht wieder einbauen. Bisher besteht allerdings gar kein 
Interesse.

Peter Sieg schrieb:
> Hallo. Bin wieder da ;-)

Ich jetzt auch. :)

> Ich finde die Optionen zur DRAM Selektion SEHR unübersichtlich!
> Das versteht doch kein Mensch mehr.. da müssen andere Namen+mehr
> Erläuterungen in den ASM Quellcode..

Das Ganze war nur zum Testen gedacht. Insbesondere die alten Routinen
hatte ich zuerst nur dringelassen, damit man mit den neuen vergleichen 
kann.
Dann wurde mir der Aufwand zu groß, die neuen Routinen für alte 
Pinbelegungen einzubauen und hatte dann schnell diese Schalter eingebaut
und nicht mal richtig getestet.

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Leo C. Solange es ja nur 2 Leitungen/Pins sind, die zu tauschen sind..
sehe ich da auch kein wirkliches Problem.. habe die jetzt auf meiner LR
Version umgelötet.. wenn ich die Platinen bekomme.. mach ich das da dann
genauso.. ist ja ein prima Geschwindigkeitszuwachs für die kleine 
Änderung.

Hast du für deine Speedmessungen eigendlich ein fertiges Programm 
genutzt?
Falls ja, könnte man das ja als Referenz nehmen..?

Anschauen werde ich mir das alles in den nächsten Tagen.. bin aber kein
Experte.. daher kann ich da selbst 'nur' lernen.. ;-)

Aber MBASIC.COM läuft jetzt! Das ist doch schon mal was! Gleich mal ein
paar Basic Programme raussuchen ;-)

Dann wollte ich mal schauen, ob mal ohne großen Aufwand die das 
Dickimage
vergrößern kann.. z.B mehr Sektoren etc. etc... 250kb sind schnell 
voll..
und selbst auf einer winzigen 16MB SD Karte ist so viel Platz ;-)

Auf jeden Fall freut es mich riesig, das aus diesem 'sinnlosen' 
Proof-of-Concept ein richtiges, kleinen Bastelprojekt geworden ist!!

Und die Verbesserungen können sich sehen lassen:
* CP/M Warmstart
* 8080 Opcodes korrigiert
* Dram Access beschleunigt

Peter

von Peter S. (petersieg)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So. Platinen sind angekommen. Nochmals vielen Dank an Joe G. dafür!
Erste aufgebaut und läuft ;-)

Peter

von Leo C. (rapid)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Huch, ist hier ein Posting von mir gelöscht worden, oder habe ich das am 
Montag tatsächlich nicht abgeschickt? Fällt mir jetzt erst auf, weil ich 
jetzt auch ein Bild von dem "Gerät" schicken wollte, daß ich am Montag 
angekündigt hatte. Ich habe es gestern aufgebaut, und es läuft.

Also auf ein Neues.

Peter Sieg schrieb:
> @Leo C. Solange es ja nur 2 Leitungen/Pins sind, die zu tauschen sind..
> sehe ich da auch kein wirkliches Problem.. habe die jetzt auf meiner LR
> Version umgelötet.. wenn ich die Platinen bekomme.. mach ich das da dann
> genauso.. ist ja ein prima Geschwindigkeitszuwachs für die kleine
> Änderung.
>
> Hast du für deine Speedmessungen eigendlich ein fertiges Programm
> genutzt?
> Falls ja, könnte man das ja als Referenz nehmen..?

Das "Testprogramm" ist hier:
Beitrag "Re: CP/M auf ATmega88"

> Aber MBASIC.COM läuft jetzt! Das ist doch schon mal was! Gleich mal ein
> paar Basic Programme raussuchen ;-)

MBASIC ist leider immer noch A-langsam. Ich habe praktisch nur ELIZA 
ausprobiert, und die ist nicht benutzbar.

In BASIC kannst Du Zeiten z.B. so messen:
100 REM Timertest
110 TCTRPORT = &H40
120 REM Start timer 
130 OUT TCTRPORT,1
140 REM Do something
150 FOR I=0 TO 200
160 IF I MOD 10 = 0 THEN PRINT ".";
170 NEXT
180 REM Stop timer, print result
190 OUT TCTRPORT,15
200 PRINT
210 PRINT "Done."
220 END


> Dann wollte ich mal schauen, ob mal ohne großen Aufwand die das
> Dickimage
> vergrößern kann.. z.B mehr Sektoren etc. etc... 250kb sind schnell
> voll..
> und selbst auf einer winzigen 16MB SD Karte ist so viel Platz ;-)

Dazu habe ich am Montag auch einiges geschrieben. Jetzt nur kurz 
Stichworte: Bios, Tabellen DPH, DPB, ...

Inzwischen bin ich sozusagen dran. Aber erst kommt das Sector 
Blocking/Deblocking an die Reihe.

Zu den Bildern:
Das Gehäuse ist dieses hier:
http://www.pollin.de/shop/dt/MTcwOTcyOTk-/Computer_und_Zubehoer/Hardware/Laufwerke_Cardreader/Card_Reader_UCR_61S.html

Als (SD-)Kartenleser war das Gerät am PC absolut unbrauchbar. Aber 1€ 
für Gehäuse + SD-Slot ...

Edit:
Beim 2. Bild habe ich leider daneben gehauen. Da wollte ich eigentlich 
auch eine verkleinerte Version schicken. Tut mir leid.

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Erste aufgebaut und läuft ;-)

Sieht doch gut aus!
Übrigens, Abblock C's sind dafür da, dass man sie als fehlend im Layout 
ktitisiert und später nicht bestückt ;-)

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Übrigens, Abblock C's sind dafür da, dass man sie als fehlend im Layout
> ktitisiert und später nicht bestückt ;-)

Genau! ;-) ;-)

Peter

von Rene B. (themason) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Meine Platine ist auch da (schon vor 1-2 Wochen, hatte aber erst letztes 
WE Zeit sie zu bestücken). Lauffähig ist diese, allerdings zickt der 
FT232 noch rum. Habe den Treiber für den VCP installiert, bekomme aber 
mit Putty dennoch kein Zeichen rein/rausgeschaufelt. Muß da mal 
ausprobieren. CP/M hab ich demnach noch nicht getestet. Werde mir aber 
die Sourcen von SVN runterladen und mal durchstöbern. Vllt auch CP/M zum 
laufen bringen. Aber muß mich da erst einlesen.

Dickes Lob an Joe für die Sammelbestellung und Peter für die Initiative 
dieses Projektes. Weiter so Jungs. Klasse :-)

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Im Debugger habe ich folgende kleine Schleife laufen lassen:
> MVI A,01        ;
> OUT 40     ;Start Timer         Takte
> LXI H,0000      ;               10
> DCX H           ;               6  -\
> MOV A,H         ;               4   |
> ORA L           ;               4   |
> PUSH PSW        ;               10  | 44 * 65536  =  2883584
> POP PSW         ;               10  |
> JNZ 0107        ;               10 -/
> MVI A,02        ;               7
> OUT 40     ;Stop Timer          11
> NOP             ;               gesamt Anzahl Takte: 2883612

Hi Leo C.
wäre es nicht super, diese 'Benchmark' Routine in dein timer (t.com) 
Programm mit aufzunehmen..? -> t b würde dann den Timer starten,
die Schleife ausführen und direkt danach die verstrichene Zeit 
ausgeben..
So hätten wir ein ungefähres Mass für Optimierungen..

Habe die 2te Platine noch ohne HW-Änderungen am laufen mit D* = 0.
=> geht also noch mit den alten Sprite_tm DRAM Routinen..

BTW: Welches fuses hast du für den Atmega8 gesetzt?
Möchte da auch mal einen mir 20mhz + 3,3v 'quälen' ;-)

Peter

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hmm. Ein normaler ATmega8 läuft bei mir nicht mit 3.3V und 20MHz.
lfuse=0xff; hfuse=0xd9

ATmega8L hab ich grad nicht da..
Egal.. 168 läuft erwartungsgemäß (fuses gleich wie 88).

Peter

von Rene B. (themason) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich habe auch mal eine kleine Frage.

Ich habe dn ATMega168 drauf. Der läuft mit 3.3V bei 20MHz. Ich habe das 
Problem das sobald ich irgend eine Test-Software draufspiele die 
beispielsweise nur einen Prompt ausgibt (habe das uParse-Projekt in der 
Codesammlung mal darauf gespielt), sich der Controller ständig resettet.
Gibt es beim Mega168 gegenüber dem Mega16/32/644 einen Unterschied beim 
UART der zum Reset führen kann ? Register und Interruptvektoren hab ich 
schon angepasst. Reset-Leitung ist auf High, und die WDTON ist nicht 
gesetzt (AVR-Studio, also "richtig" herum). Ich kann mir da irgendwie 
keinen Reim drauf machen warum der Controller sich permanent resettet. 
Selbst wenn ich alle Interrupts disabled lasse, und nur einen Prompt 
ausgebe mit anschließender while (1); resettet der sich andauernd.
Was kann/könnte das sein ?! Liegt es vllt daran das ich dem Mega168 mit 
20MHz bei 3.3V zuviel zumute ?!

Fuses kann ich leider Momentan nicht posten da ich die Platine gerad 
nicht Griffbereit habe. Aber es ist keine Bootsection aktiv, CLKDIV8 ist 
nicht gesetzt, WDTON wie schon erwähnt auch nicht, Brownout detection 
ebenfalls nicht.

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi.

Ich haben einen 168 hier mit avrcpm am laufen. 3,3V und 20MHz.
lfuse=0xf7
hfuse=0xdf
efuse unverändert zum Auslieferzustand

Hoffe das hilft..

Peter

von Feinmechaniker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rene Böllhoff schrieb:
> Liegt es vllt daran das ich dem Mega168 mit
> 20MHz bei 3.3V zuviel zumute ?!

Hier laufen alle Mega168 mit 3.3V und 24 MHz. Aber versuche doch mal auf 
5V zu jumpern bzw. die 8 MHz intern zu nutzen. Bei 5V natürlich SD-Card 
ziehen!

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Rene Böllhoff schrieb:
> sobald ich irgend eine Test-Software draufspiele die
> beispielsweise nur einen Prompt ausgibt (habe das uParse-Projekt in der
> Codesammlung mal darauf gespielt), sich der Controller ständig resettet.

Was mir spontan noch dazu einfällt.
Auf der Platine ist /DTR (FT232RL) über 100n mit dem Reset des AVR 
verbunden.

von Rene B. (themason) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
@Peter

Erstmal danke für die Fuse-Werte. Werd es mal prüfen

@Joe

>die 8 MHz intern zu nutzen

Dann kann ich aber keine saubere Baudrate erzeugen, und das wär schon 
wichtig.

>Bei 5V natürlich SD-Card ziehen!

Soweit bin ich noch nicht :-)

>Auf der Platine ist /DTR (FT232RL) über 100n mit dem Reset verbunden

Welche Version des Layouts ist es denn ? Ich hab irgendwie nur die 
Version vom 06.06.10 gefunden und danach bestückt. Bin mir aber nicht 
sicher ob das die aktuelle Version ist.
Bei mir im Schaltplan ist DTR mit nichts verbunden. Aber ich mess es mal 
nach wenn ich die Platine wieder zur Hand habe.

Ich wüsste nicht was ich da großartig hätte falsch machen können. Bei 
allen AVRs bisher nie ein Problem gewesen. Aber vllt sind die 20MHz ja 
auch wirklich was viel, wobei ich mir das nur schwer vorstellen kann 
wenn viele der Platinen mit 24MHz laufen. Merkwürdig, merkwürdig.

von Feinmechaniker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rene Böllhoff schrieb:
> Welche Version des Layouts ist es denn ? Ich hab irgendwie nur die
> Version vom 06.06.10 gefunden und danach bestückt. Bin mir aber nicht
> sicher ob das die aktuelle Version ist.

Die aktuelle Version ist vom 12.06.10 siehe auch hier:
http://www.mikrocontroller.net/articles/AVR_CP/M

von Rene B. (themason) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
@joe

Ah danke. Dachte schon ich hätte Lötpunkte auf den Augen.
Aber die DTR Leitung kanns nicht sein ... C14 ist bei mir nicht 
bestückt.

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nur so als weiterer Hinweis.. hatte bei ebay 2xATmega88PA gekauft.. aus 
Hongkong.. sind auch da.. aber vermutlich umgelabelte 8er.. ID is nicht 
mit
88er identisch (avrdude meckert).. die laufen auch nicht mit 20MHz..

Peter

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hmm.. versuche micg gerade mal in z80 asm und möchte den timer.asm um
eine delay-benchroutine erweitern.. Programm läuft auch, aber egal, ob 
in hl eine 0, 20 oder 50 geladen wird.. das Ergebnis ist immer 2,138/9 
Sekunden??
Ist bestimmt wieder so absolut blöder Fehler ;-)
bench:
        ld      a,startTimerCmd
  out  (TIMERCTL),a  ; start
; loop starts here
  ld      hl,0
l1:    
        ld      b,0
l2:  
        ld      a,0
l3:  dec   a
  jp      nz,l3    ; 256 x
        dec    b
  jp      nz,l2    ; 256 x
  dec    hl
  jp      nz,l1    ; 256 x
; loop ends here
        ld      a,printTimerCmd
  out  (TIMERCTL),a  ; print elapsed time
  ret        ; and done

Peter

von Joerg W. (joergwolfram)


Bewertung
0 lesenswert
nicht lesenswert
DEC HL setzt soviel ich weiss keine Flags. Also müsste man wie im ersten 
Testbeispiel ein
MOV A,H 
ORA L
nach das DEC HL setzen.

Jörg

von Leo C. (rapid)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

> wäre es nicht super, diese 'Benchmark' Routine in dein timer (t.com)
> Programm mit aufzunehmen..? -> t b würde dann den Timer starten,
> die Schleife ausführen und direkt danach die verstrichene Zeit
> ausgeben..
> So hätten wir ein ungefähres Mass für Optimierungen..

direkt in das Timersteuerprogramm würde ich es nicht einbauen Aber auch 
sonst wollte ich es nicht allzu komfortabel machen, damit niemand auf 
die Idee kommt, das wäre ein richtiger Benchmark. Ich habe die Schleife 
aber jetzt mal mit einem return zum CCP abgespeichert und hier 
angehängt.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:

>   dec    hl
>   jp      nz,l1    ; 256 x

Jörg hat ja schon geschrieben, daß hier Z_Flag nicht gesetzt wird.
Davon abgesehen wird die Schleife natürlich 65536 mal wiederholt.
Da die innere Schleife ja auch schon gute 3 Sekunden braucht, kommst Du 
insgesammt auf gute 196 Kilosekunden, also über 54 Stunden. Ich glaube 
nicht, daß Du so lange warten willst.

von Joerg W. (joergwolfram)


Bewertung
0 lesenswert
nicht lesenswert
@  Leo C.

Das stimmt nicht ganz, denn die äussere Schleife wird NIE wiederholt. 
Das liegt einfach daran, dass das Zero-Flag von der nächstinneren 
Schleife noch gesetzt ist und der DEC HL Befehl keine Flags ändert.

Jörg

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Joerg Wolfram schrieb:
> Das stimmt nicht ganz, denn die äussere Schleife wird NIE wiederholt.

Das stimmt natürlich.
Ich hätte wohl schreiben sollen, daß die Schleife 65536 mal wiederholt
werden würde, wenn "dec hl" das Z-Flag beeinflussen würde.

von Peter Sieg (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ja, es mußte ja sowas 'dummes' sein ;-)
Danke!

Habe jetzt register c statt hl genommen.. und 10x reicht auch ;-)
bench:
        ld      a,startTimerCmd
  out  (TIMERCTL),a  ; start
; loop starts here
  ld      c,10
l1:    ld      b,0
l2:    ld      a,0
l3:  dec   a
  jp      nz,l3    ; 256 x
        dec    b
  jp      nz,l2    ; 256 x
  dec    c
  jp      nz,l1    ; 10 x
; loop ends here
        ld      a,printTimerCmd
  out  (TIMERCTL),a  ; print elapsed time
  ret        ; and done

Damit bekommt man mit:
AVR   MHz   D  Zeit
88    20    0  035,999s
88    20    1  021,385s

Peter

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Ja, es mußte ja sowas 'dummes' sein ;-)
> Danke!
>
> Habe jetzt register c statt hl genommen.. und 10x reicht auch ;-)

> l1:    ld      b,0
> l2:    ld      a,0
> l3:    dec     a
>        jp      nz,l3    ; 256 x
>        dec     b
>        jp      nz,l2    ; 256 x
>        dec     c
>        jp      nz,l1    ; 10 x

Statt möglichst schnell zu zählen (und das möglichst oft, damit's nicht 
so schnell vorbei ist :), wäre es vielleicht besser, in die Schleife 
einige "interessante" Befehle zu legen. Z.B. "PUSH", "POP", "CALL", 
"RET", "LD (nnnn),HL", "EX (SP),HL". Also z.B. Befehle, die das 
RAM-Interface etwas mehr fordern. Oder einen Mix aus Befehlen, der 
möglichst praxisnah ist...

Peter, da Du doch was für MBASIC übrig hast: Mein Basic-Beispiel weiter 
oben, könnte man auch noch ausbauen.

> Damit bekommt man mit:
> AVR   MHz   D  Zeit
> 88    20    0  035,999s
> 88    20    1  021,385s
Bei mir z.Zt:
  8     20    ?  012.180s   bb
  8     20    -  010.811s   exp

mit folgenden Pinbelegungen:
   ------------------------------------------------------------------------
   |         Port D        |         Port B        |         Port C       |
   +-----------------------+-----------------------+----------------------+
   | 7 | 6 | 5 | 4 | 3 | 2 | 5 | 4 | 3 | 2 | 1 | 0 | 5 | 4 | 3 | 2 | 1 | 0|
   |            CS         |SCK DO  DI             |                      |
bb |A7  A6  A5      A8  OE |RAS A0  A1  A2  A3  A4 |CAS  W  D3  D2  D1  D0|
   +-----------------------+-----------------------+----------------------+
   |                    CS |SCK DO  DI             |        D3  D2  D1  D0|
exp|A7  A6                 |A9  A8  WE  OE  CAS RAS|A5  A4  A3  A2  A1  A0|
   ------------------------------------------------------------------------

"exp" findet man in meinem SVN im "experimental" Zweig.

von Peter S. (petersieg)


Bewertung
0 lesenswert
nicht lesenswert
ok. Na klar kömmte/sollte man ggf. verschiedenen Befehle etc. in der 
Schleife unterbringen.. aber was ist ein realer Mix? Und es ist ja kein 
wirklicher Benchmark, sondern nur ein Anhaltspunkt um andere 
Portbelegungen/Dramroutinen etc. zu 'messen'..
Und die MBASIC Version fand ich deshlab nicht ideal, weil man MBASIC 
benötigt..
Hier noch mal die D0 (Original Sprita-tm Portbelegung + Routinen)
und die D1 Version (Port C - Pin 1 + 4 umbelegt + neue Routinen)
(in z80.asm zu wählen durch: DRAM_DQ_ORDER == 0/1)
          >----------------------------------------------------------------------- 
---
>  |         Port D        |         Port B        |         Port C       |
>  +-----------------------+-----------------------+----------------------+
>  | 7 | 6 | 5 | 4 | 3 | 2 | 5 | 4 | 3 | 2 | 1 | 0 | 5 | 4 | 3 | 2 | 1 | 0|
>D0|            CS         |SCK DO  DI             |                      |
>  |A7  A6  A5      A8  OE |RAS A0  A1  A2  A3  A4 |CAS D1  D3  D2   W  D0|
>  +-----------------------+-----------------------+----------------------+
>  | 7 | 6 | 5 | 4 | 3 | 2 | 5 | 4 | 3 | 2 | 1 | 0 | 5 | 4 | 3 | 2 | 1 | 0|
>D1|            CS         |SCK DO  DI             |                      |
>bb|A7  A6  A5      A8  OE |RAS A0  A1  A2  A3  A4 |CAS  W  D3  D2  D1  D0|
>----------------------------------------------------------------------- ---

D.h, du hast allein durch eine andere Portbelegung und geänderte 
Routinen,
eine Verbesserung von 021,385s (D1) zu 10,811s (exp( geschafft?!
> Damit bekommt man mit:
> AVR   MHz   D  Zeit
> 88    20    0  035,999s
> 88    20    1  021,385s
>Bei mir z.Zt:
>  8     20    ?  012.180s   bb
>  8     20    -  010.811s   exp
mit folgenden Pinbelegungen:
Hmm.. sehe gerade, das D1 und dein bb identisch sind, von den 
Portbelegungen... hast du dann noch andere Routinen verwenden??
Denn du hast ja damit 12,180s erreicht (wohin ich nur 021,385s 
erreiche)??
Und das das am ATmega8 liegen soll kann ich nicht wirklich glauben..
Hast du übrigens einen 8L verwendet?
>----------------------------------------------------------------------- ---
>  |         Port D        |         Port B        |         Port C       |
>  +-----------------------+-----------------------+----------------------+
>  | 7 | 6 | 5 | 4 | 3 | 2 | 5 | 4 | 3 | 2 | 1 | 0 | 5 | 4 | 3 | 2 | 1 | 0|
>D2|                    CS |SCK DO  DI             |        D3  D2  D1  D0|
>ex|A7  A6                 |A9  A8  WE  OE  CAS RAS|A5  A4  A3  A2  A1  A0|
>----------------------------------------------------------------------- ---
Der Gewinn D1 -> D2 ist allerdings nicht 'soo' groß..

Peter

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
>> Damit bekommt man mit:
>> AVR   MHz   D  Zeit
>> 88    20    0  035,999s
>> 88    20    1  021,385s
>>Bei mir z.Zt:
>>  8     20    ?  012.180s   bb
>>  8     20    -  010.811s   exp


Bei mir:
AVR   MHz   D  Zeit
168   24    1  017,62s

muß mal den Code von Leo C. für die variante D1 (bb) testen.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> ok. Na klar kömmte/sollte man ggf. verschiedenen Befehle etc. in der
> Schleife unterbringen.. aber was ist ein realer Mix?

Darum habe ich mich bisher ja auch gedrückt. ;)

> Und es ist ja kein
> wirklicher Benchmark, sondern nur ein Anhaltspunkt um andere
> Portbelegungen/Dramroutinen etc. zu 'messen'..

Ja, aber Deine Schleife testet nicht mal das halbe DRAM-Interface. 
Geschweige, einen nennenswerten Teil des Interpreters.

> Und die MBASIC Version fand ich deshlab nicht ideal, weil man MBASIC
> benötigt..

Aber das ist ja vorhanden. Und es ist eine reale Anwendung.

> mit folgenden Pinbelegungen:
> Hmm.. sehe gerade, das D1 und dein bb identisch sind, von den
> Portbelegungen... hast du dann noch andere Routinen verwenden??
> Denn du hast ja damit 12,180s erreicht (wohin ich nur 021,385s
> erreiche)??

Beitrag "Re: CP/M auf ATmega88"


> Hast du übrigens einen 8L verwendet?

Eben nicht. Ich hatte ja auch schon mehrfach geschrieben, daß mein Mega8
mit zu niedriger Spannung und zu hoher Frequenz läuft.

> Der Gewinn D1 -> D2 ist allerdings nicht 'soo' groß..

Beitrag "Re: CP/M auf ATmega88"

Ich hatte mir allerdings auch etwas mehr erhofft.
Zur Zeit bin ich gerade wieder an etwas dran, von dem ich mir nochmal 
einen Schub erhoffe. Details gibts aber erst, wenns wirklich 
funktioniert.

Übrigens habe ich inzwischen den Sektor (De-)Blocking-Algorithmus, der 
unnötiges, mehrfaches Lesen und Schreiben der SD-Karte vermeidet, drin.
Performance-mässig bringts leider auch noch nicht so viel, außer 
vielleicht bei Anwendungen, die viel und wahlfrei auf Disk schreiben.
Aber Schreiben habe ich noch nicht wirklich getestet...

von Leo C. (rapid)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>> Und die MBASIC Version fand ich deshlab nicht ideal, weil man MBASIC
>> benötigt..

> Aber das ist ja vorhanden. Und es ist eine reale Anwendung.

Da das MBASIC im Archiv von Sprite_tm kaputt ist, habe ich hier mal eine 
funktionierende Version drangehängt. Außerdem habe ich gleich noch ELIZA 
dazugetan.

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
@Leo C.
Ich habe gerade die Versionen 28 und 29 getestet. Beide mit dem gleichen 
(Fehler)ergebnis.
Version 19 bringt noch als ersten Opcode von Adresse 2000:
opcode 31 decoded 0192 also korrekt.
Version 28 und 29 bringen:
opcode 31 decoded FFFF und dann startet das System neu.
Hast du was am Befehlsinterpreter geändert? Muß wieder ein neuer 
Schalter gesetzt werden?

Könntest du das cpm.bin nicht gleich wieder erstellen? Unter Windows 
habe ich keinen Z80 Asssembler gefunden der die Quellen übersetzt.

von Peter S. (petersieg)


Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> muß mal den Code von Leo C. für die variante D1 (bb) testen.

Ja, denn irgendwoher muß der Unterschied:
>> 88    20    1  021,385s
>>Bei mir z.Zt:
>>  8    20    ?  012.180s   bb
ja herkommen.. denn die Portbelegung ist zw. D1 und bb identisch..

>Bei mir:
>AVR   MHz   D  Zeit
>168   24    1  017,62s
ja, +20% höherer Takt sollte die Reduzierung von ca. 21 auf 17s 
erklären.

Ich habe für timer.asm den tniasm.exe verwendet..(google). Der gibt
aber bei ipl.asm+bios.asm noch eine Fehlermeldung bei Zeile 71/211? 
aus..
hatte noch keine Zeit da weiter rein zu schauen.. ist evtl. nur ne 
Kleinigkeit.. einen anderen Assembler für win32 habe ich auch noch nicht
gefunden..

---

@Leo: Wenn die Optimierungen am Interpreter angekommen sind (nicht die 
schon vorgenommenen Fehlerbereinigungen), kann man ja gerne andere / 
weitere Befehle in die Benchschleife mit aufnehmen..
Z.Z habe ich eine D0 und eine D1 Variante hier am laufen.. Und die 
LR-Version
kann ich ggf. ja einfach komplett umbauen.. wenn es sich lohnt..
Ich suche noch 32MHz und 40MHz Quarze (wo gibt es die..?), dann kann ich 
mal
schauen ob die Realität der Hochrechnung entspricht (womit wir dann bei 
>1MHz bis an die ~2MHz Z80 sind..)

BTW: Mbasic hatte ich schon lange mal ein andere Version gezogen..
Muß jetzt mal die alten Basic Juwelen durchtesten.. Nim/23 und Bagels
laufen einwandfrei.. stellen ich dann alle hier rein..

Peter

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> @Leo C.
> Ich habe gerade die Versionen 28 und 29 getestet. Beide mit dem gleichen
> (Fehler)ergebnis.
> Version 19 bringt noch als ersten Opcode von Adresse 2000:
> opcode 31 decoded 0192 also korrekt.
> Version 28 und 29 bringen:
> opcode 31 decoded FFFF und dann startet das System neu.

Alle eingecheckten Revisionen sind bei mir mindestens einmal gelaufen.
Einziger Unterschied zu Deiner Hardware dürfte der Prozessor sein.
Mega88, Mega168 kann ich nicht testen.
Alles in trunk sollte auf Deiner Hardware funktionieren.
(Ab Rev. 32 braucht man allerdings das zugehörige Bios.)

> Hast du was am Befehlsinterpreter geändert?

Einige kleine, lokale Optimierungen. Das Konzept ist immer noch das 
gleiche.
Hast Du einen Mega88 zum Testen?

> Muß wieder ein neuer Schalter gesetzt werden?

Nein.

> Könntest du das cpm.bin nicht gleich wieder erstellen?

Im SVN möchte ich eigentlich keine Binaries haben.

> Unter Windows
> habe ich keinen Z80 Asssembler gefunden der die Quellen übersetzt.

Die Assemblerquellen gibt es hier:
http://savannah.nongnu.org/projects/z80asm/

Vielleicht ist ja jemand so freundlich, und übersetzt das Ding für 
Windows.

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi.

Habe mich gerade daran erinnert, das auf alten Netzwerkkarten ja 25MHz 
Quarze sind ;-)
>Damit:
>AVR   MHz   D  Zeit
>88    25    1  016,871s

Peter

von Feinmechaniker (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Ich habe für timer.asm den tniasm.exe verwendet..(google). Der gibt
> aber bei ipl.asm+bios.asm noch eine Fehlermeldung bei Zeile 71/211?
> aus..

Danke für den Tip! Wenn Du jeweils den "end" Befehl streichst übersetzt 
der Compiler.

Leo C. schrieb:
> Einige kleine, lokale Optimierungen. Das Konzept ist immer noch das
> gleiche.
> Hast Du einen Mega88 zum Testen?

Ich suche mal nach einem Mega88 zum testen. Übrigens ist mir 
aufgefallen, wenn der Schalter zum RAM-Test gesetzt ist läuft das System 
nicht stabil. Zork, MBASIC oder der SYS Befehl bringen oft (nicht immer) 
Op-Codefehler. Ohne RAM Test läuft alles Fehlerfrei. Sieht nach einem 
Timing Problem aus.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Habe mich gerade daran erinnert, das auf alten Netzwerkkarten ja 25MHz
> Quarze sind ;-)

Dann sind meine Netzwerkkarten noch nicht alt genug? Die beiden 20MHz 
Quarze habe ich von dort.

Alte Grafikkarten sind eine gute Quelle für Oszillatoren. Auf meiner 
guten alten ET4000 sind 25.17, 28.322, 36, 44.9 und 62MHz. Ich weiß nur 
nicht, ob die Teile auch bei 3.3V laufen.

8 Stück 256x4MBit DRAMs sind übrigens auch drauf. Davon 4 sogar 
gesockelt.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Feinmechaniker schrieb:
> Übrigens ist mir
> aufgefallen, wenn der Schalter zum RAM-Test gesetzt ist läuft das System
> nicht stabil. Zork, MBASIC oder der SYS Befehl bringen oft (nicht immer)
> Op-Codefehler. Ohne RAM Test läuft alles Fehlerfrei. Sieht nach einem
> Timing Problem aus.

Das ist aber seltsam. Von dem RAM-Test sollte eigentlich keine 
Erinnerung
übrig bleiben. Falls etwas nicht richtig initialisiert wird, sollte es 
eher umgekehrt sein. Ich habe den RAM-Test immer eingeschaltet.

Hast Du den MEMFILL_CB-Schalter an? Ich finde den sehr nützlich, da ein 
ins Nirvana laufendes Programm sofort gestopt wird.

von Peter S. (petersieg)


Bewertung
0 lesenswert
nicht lesenswert
bezüglich der Quarze.
CSD hat 36+40MHz aber 3.Oberton..? Geht das, oder eher nicht?
Ansonsten gibts wohl nur Quarzoszillatoren.. und ob die ab 3,3V
arbeiten..? Für SMD gibts aber welche ab 3,3V..

Peter

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Jetzt habe ich doch noch meinem GPS-Logger den ATmega328P geklaut.
Läuft mit meinen neuesten Programmversionen auf Steckbrett und 
Lochraster mit 2 verschiedenen Verdrahtungen.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Inzwischen habe ich eine weitere Verdrahtung ausprobiert und dafür auch 
andere RAMs genommen (GM71C4256A-80, statt der schnelleren 3.3V Typen). 
Mit ATmega8 gings problemlos, aber mit dem ATmega328P bekam ich die 
gleichen Probleme, wie Joe G. sie beschrieben hatte.

@Joe G.:
Geholfen hat ein weiterer Wartezyklus beim Lesen, in der SVN/trunk 
Version also so:
dram_read:
  cli
  DRAM_SETADDR adrh, ~0,(1<<ram_ras), ~(1<<ram_a8), (1<<ram_oe)
  cbi P_RAS,ram_ras
  DRAM_SETADDR adrl, ~(1<<ram_ras),0, ~((1<<ram_oe)), (1<<ram_a8)
  cbi P_CAS,ram_cas
  cbi P_A8,ram_a8    ; 2 Takte
  nop                ; 1 Takt
  in  temp,P_DQ-2    ; PIN
  sbi P_CAS,ram_cas

  cbi P_CAS,ram_cas
  andi temp,0x0f     ; 1 Takt
  swap temp          ; 1 Takt
  nop                ; 1 Takt
  in  temp2,P_DQ-2   ; PIN
  andi temp2,0x0f
  or  temp,temp2

  sbi P_OE,ram_oe
  sbi P_CAS,ram_cas
  sbi P_RAS,ram_ras
  sei
  ret

Nach den Datenblättern sollten 2 Takte (immerhin noch 83ns bei 24MHz) 
dicke reichen, aber bei 3.3V statt 5V dürfen wir ja froh sein, daß die 
RAMS überhaupt laufen.

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Geholfen hat ein weiterer Wartezyklus beim Lesen, in der SVN/trunk

Leider behebt es bei mir nicht den Fehler im Befehlsinterpreter, siehe

Joe G. schrieb:
> Version 19 bringt noch als ersten Opcode von Adresse 2000:
> opcode 31 decoded 0192 also korrekt.
> Version 28 und 29 bringen:
> opcode 31 decoded FFFF und dann startet das System neu.

In Version 28 hast du auch die beiden neunen Funktionen dram_read_w, 
dram_write_w auch nicht eingebaut. In V29 habe ich die NOP's mal 
eingefügt, ohne Erfolg.

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
@Leo C.
Ich habe den Fehler nochmal eingegrenzt. Es scheint wirklich ein Timing 
Problem mit dem RAM zu sein. V28 und V29 laufen bei 8MHz auf dem mega168 
und mega8. Bei 20MHz bzw. 24 MHz tritt das Problem auf. 
Erstaunlicherweise läuft mein mega8 hier mit 3.3V und 24 MHz.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
>> Version 19 bringt noch als ersten Opcode von Adresse 2000:
>> opcode 31 decoded 0192 also korrekt.
>> Version 28 und 29 bringen:
>> opcode 31 decoded FFFF und dann startet das System neu.

Da ich die passende Hardware noch auf meinem Steckbrett habe, habe ich 
die Version 19 grade ausprobiert. Läuft bei mir mit ATmega328P. Für 
diesen Fehler habe ich auch keine Erklärung. Der Wert 0192 ist ja nur 
ein Tabelleneintrag (Index 31) in inst_table. Es sieht so aus als ob der 
Interpreter bei Dir ins Leere (unprogramierte Flash) greift. Ab der 
Revision 28 muß die Tabelle auf einer durch 256 teilbaren Adresse 
liegen. Das müßte aber durch das .org (PC+255) & 0xff00 davor 
gewährleistet sein. Du könntest mal im Listing nachschauen, wo die 
Tabelle bei Dir zu liegen kommt.

Mindestens ein Fehler ist aber drin. Beim Start sollte das Register "_0" 
genullt werden. Z.B.:
start:
  ldi temp,low(RAMEND)  ; top of memory
  out SPL,temp    ; init stack pointer
  ldi temp,high(RAMEND)  ; top of memory
  out SPH,temp    ; init stack pointer

  clr  _0

>
> In Version 28 hast du auch die beiden neunen Funktionen dram_read_w,
> dram_write_w auch nicht eingebaut.

Die Funktionen waren immer als "experimental" gekennzeichnet und 
abgeschaltet. Der Aufwand lohnt einfach nicht. Problem ist, daß ein 
16-bit Wort auf der Grenze zwischen 2 Reihenadressen liegen kann.

>In V29 habe ich die NOP's mal
> eingefügt, ohne Erfolg.

Ein weiterer Timing-Engpaß könnte noch in der Refresh-Routine liegen. 
Dort sind 2 auskommentierte nops drin. Wenn ich mich richtig erinnere, 
ist der 2. an der kritischeren Stelle.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> @Leo C.
> Ich habe den Fehler nochmal eingegrenzt. Es scheint wirklich ein Timing
> Problem mit dem RAM zu sein. V28 und V29 laufen bei 8MHz auf dem mega168
> und mega8. Bei 20MHz bzw. 24 MHz tritt das Problem auf.
> Erstaunlicherweise läuft mein mega8 hier mit 3.3V und 24 MHz.

Das es mit dem Meaga8 besser geht, ist mir am Wochenende ja auch 
aufgefallen. Dir Porttreiber sind offensichtlich unterschiedlich (Ich 
habe gerade in die Datenblätter geschaut, und mein Verdacht hat sich 
bestätigt).

Man müßte mal ein Scope dranhängen, um zu sehen, was da vor sich geht.

Dein FFFF vs. 0192 Fehler ist damit aber nur schwer zu erklären. Der 
Opcode wird ja in beiden Fällen aus dem RAM richtig gelesen.

Du kannst das RAM-Timing natürlich weiter dehnen. Zuerst 1 oder 2 
weitere nops vor den in-Befehlen. Dann vor/nach den anderen 
Signalflanken nops einbauen. Zum Schluß landet man vielleicht wieder bei 
den vielen nops, die Sprite_tm schon drin hatte. ;-)

Oder beim Mega8 bleiben. Bisher kenne ich noch keinen Grund, der dagegen 
sprechen würde.

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> clr  _0

Das war der Fehler! V29 läuft, vielen Dank für den Hinweis.
Timer B zeigt nun 9.441 s mit einem mega8 und 24 Mhz

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
>> clr  _0
> Das war der Fehler! V29 läuft, vielen Dank für den Hinweis.
> Timer B zeigt nun 9.441 s mit einem mega8 und 24 Mhz

Bei mir hats komischerweise keinen Unterschied gemacht.

Ab Revision 51 ist der Fehler behoben. Allerdings sehe ich keinen Grund, 
gleich die HEAD Revision (53) zu nehmen.

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
ich teste mich mal nach oben ;-)
Bin zunächst gerade dabei mir ein neues BIOS zu erzeugen.

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Leo C. + Joe G. Super!
@Joe G. planst du einen Update der über #define D* = 1 erreichberen 
Routinen,
um den Geschwindigkeitsvorteil nutzen zu können, der weiter oben 
aufgefallen war (sobald du weißt in welchen Routinen, was geändert 
wurde..)?

Hatte heute meinen ersten Arbeitstag nach dem Urlaub :-( :-(

Peter

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
@Leo C.
Revision 51 läuft.

@alle
um sich unter Windows ein Bios zu erzeugen sollte man ein DD "für 
Windows" benutzen welches den Befehl conv=sync kennt. Hier in Link zu 
UNIX-Tools unter Windows, da ist auch das entsprechende DD dabei.

http://sourceforge.net/projects/unxutils/files/unxutils/current/UnxUtils.zip/download

Peter Sieg schrieb:
> @Joe G. planst du einen Update der über #define D* = 1 erreichberen
> Routinen

Ich habe sie genau so verwendet wie Leo C. sie bereitgestellt hat, bis 
auf das zusätzliche Einfügen von "clr  _0" in der V29. Aber ab V51 ist 
der Befehl schon mit drin. Ab V51 mußt du jedoch das neue Bios nutzen.

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Joe G.: In wieweit wirst du die V51 in deine Version übernehmen..?

Und das neue Bios von Leo C. hatte ich schon (hatte er weiter oben als 
cpm.bin zur Verfügung gestellt..).. oder gibts da schon ein neueres..?

Gruß Peter

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Und das neue Bios von Leo C. hatte ich schon (hatte er weiter oben als
> cpm.bin zur Verfügung gestellt..).. oder gibts da schon ein neueres..?

ja, gibt es, siehe hier:

* cpm/bios.asm:
  - New disk I/O interface.
  - 16 bit wide track numbers
  -  sectran competed. Unused translation table removed.
* cpm/ipl.asm:
  - New disk I/O interface.

Peter Sieg schrieb:
> @Joe G.: In wieweit wirst du die V51 in deine Version übernehmen..?

Wenn es keine Probleme damit gibt, vollständig. Es wäre aber schön, wenn 
sie noch von anderen getestet wird.

von Peter S. (petersieg)


Bewertung
0 lesenswert
nicht lesenswert
Man(n) .. ;-)
Mit der Geschwindigkeit kann ich z.Z nicht mithalten.. :-)
Könntet ihr dann bitte ipl.asm, bios.asm und avrcpm.asm hier einhängen..
dann sichere ich erstmal den aktuellen Stand als V1, assembliere dann 
alles
und kann dann auch testen..

BTW: Was sind die Änderungen/Vorteile insbesondere von 16 bit wide track 
numbers..?

Peter

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Man(n) .. ;-)
> Mit der Geschwindigkeit kann ich z.Z nicht mithalten.. :-)
> Könntet ihr dann bitte ipl.asm, bios.asm und avrcpm.asm hier einhängen..

Warum klickst Du denn nicht einfach hier drauf?
http://cloudbase.homelinux.net/viewvc/avr-cpm/trunk/

> dann sichere ich erstmal den aktuellen Stand als V1, assembliere dann
> alles
> und kann dann auch testen..
>
> BTW: Was sind die Änderungen/Vorteile insbesondere von 16 bit wide track
> numbers..?

Warst Du das nicht, der größere Disk-Formate wollte? ;-)

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Da ich an dem Thema sowieso grade wieder dran bin...

Peter Sieg schrieb:
> BTW: Was sind die Änderungen/Vorteile insbesondere von 16 bit wide track
> numbers..?

Mit 8-Bit Nummern kommnt man maximal bis 8MByte.
(128 Byte per Sector) x (256 Sectors per Track) x (256 Tracks)

Bei SD-Karten im GB-Bereich ist das etwas wenig.

Jetzt mal ein paar Fragen zu größeren Diskformaten:

Hat sich daraüber schon jemand Gedanken gemacht?
Hat vielleicht jemand schon ein Konzept?
Oder kennt jemand einen hier brauchbaren Standard / eine fertige Lösung?

Vorschläge?


Meine eigenen Gedanken:
Fernziel vielleicht Disk-Images auf FAT Dateisystem lesen/schreiben.
(Dafür wird man wahrscheinlich einen Mega168 oder größer brauchen, da ja 
auch noch die Z80 Opcodes ins Flash müssen).

Zwischenschritt:
Die Partitionstabelle von der SD-Karte lesen.
Erste (oder einzigste) Partition als CP/M partition nutzen.
Im Bootsektor der Partition die CP/M-Diskparameter ablegen.
Die Tabelle passt mit dem IPL in die ersten 128 Byte.

Was meint Ihr?

von Peter S. (petersieg)


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Warum klickst Du denn nicht einfach hier drauf?
> http://cloudbase.homelinux.net/viewvc/avr-cpm/trunk/
>
> Warst Du das nicht, der größere Disk-Formate wollte? ;-)

Na dann schaue ich mal in den 'Kofferraum' (trunk) ;-)
Werde dann mal versuchen für D1 eine V53 komplett zu übersetzen..

Ja, ich wars ;-) Aber den Verhältnissen entsprechend des Konzeptes.. 
eine
EINFACHE Implementierung!! Nichts zu kompliziertes.. Hey, wir reden hier 
über CP/M.. wer sollte selbst bei 8MB großen 'Disketten' ohne 
Unterverzeichnisse noch die Übersicht behalten.. Aktuell sind die 
diskimages sowas um die 250kb.. da passt sogar schon der BDS-C Compiler 
drauf.. also 512kb - 1MB sollte reichen.. besser wären dann mehrere 
Disketten(-images) auf einer SD Karte.. (A:, B:, C: ...)

Just my 2 cents.

Peter

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> EINFACHE Implementierung!! Nichts zu kompliziertes..

Ja eben.

> Hey, wir reden hier
> über CP/M.. wer sollte selbst bei 8MB großen 'Disketten' ohne
> Unterverzeichnisse noch die Übersicht behalten.. Aktuell sind die

Der Punkt ist, daß kleine Images auch nicht einfacher zu implementieren 
sind, als große. Und warum dann so unendlich viel Platz 
verschwenden(?/!)

> diskimages sowas um die 250kb.. da passt sogar schon der BDS-C Compiler
> drauf.. also 512kb - 1MB sollte reichen..

Wenn ich das mit der Partitionstabelle so wie oben angedeutet mache, 
kannst Du ja eine 512K Partition für CP/M anlegen. Und den Rest 
anderweitig nutzen.

> besser wären dann mehrere
> Disketten(-images) auf einer SD Karte.. (A:, B:, C: ...)

Dann eben 2 Partitionen, oder 3... Bei 4 wird aber Schluß sein, weil 
erweiterte Partitionen will ich mir nicht antun.

von Peter S. (petersieg)


Bewertung
0 lesenswert
nicht lesenswert
Soo.. hat ein bißchen gedauert.. mußte erstnoch obiges dd 
herunterladen.. und mit dem 'alten' dd unter admin Rechten dann das 
diskimage schreiben (Vista)..
CPM on an AVR, v1.0
Initing mmc...
Testing RAM: fill...wait...reread...

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 : TLOOP    COM : LOAD     COM : MBASIC   COM
A: 23       BAS : BAGELS   BAS : CHECKERS BAS : STARTREK BAS
A: TREKINST BAS : MASTRMND BAS : WEEKDAY  BAS : PIP      COM
A: STAT     COM : SUBMIT   COM : XSUB     COM : ZORK1    COM
A: ZORK1    DAT
A>t b

Timer running. Elapsed: 007.573s.
A>

Na.. 7.573s allerdings bei 30MHz ;-)
Target war ATmega88.

Na, wenn das keine super Arbeit ist Leo C. ;-)
Klasse!!

Und VIELEN Dank!

Gruß Peter

von Leo C. (rapid)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Na.. 7.573s allerdings bei 30MHz ;-)

Mir wird schwindelig.

Wenn ich mich nicht verrechnet habe, hast Du bereits bei ca. 13,5MHz den 
sicheren Bereich verlassen.

Wo sind meine Herztropfen.

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Wenn ich mich nicht verrechnet habe, hast Du bereits bei ca. 13,5MHz den
> sicheren Bereich verlassen.

Haha.. Dann sind wir schon drei (der dritte ist jemand aus dem F64, der 
einen ATmega88 als SID Ersatz mit 40MHz laufen läßt) ;-)

@Joe G: Mein Vorschlag wäre es, die aktuelle Version um MK SVN als V1 zu 
belassen (inkl. ipl+bios.asm) und die R53 von Loe C. als aktuelle 
Version ins MK SVN zu spiegeln.. sodaß wir im MK SVN immer etwas größere 
Abstände zw. Versionen bekommen..

Peter

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Wenn ich mich nicht verrechnet habe, hast Du bereits bei ca. 13,5MHz den
> sicheren Bereich verlassen.
Das ist ein Fehler im Datenblatt, die lineare Funktion knickt nicht bei 
4.5V ab, Peter hat nur veregssen 12V an den AVR anzulegen. Nicht 
auszudenken mit welcher Frequenz er bei 220V läuft! Ich vermute mal mit 
50Hz ;-)

Peter Sieg schrieb:
> Mein Vorschlag wäre es, die aktuelle Version um MK SVN als V1 zu
> belassen (inkl. ipl+bios.asm)

Ich würde die Version V29 von Leo C. incl. ipl+bios als V1 eindampfen. 
Mit der derzeitigen Hardware dürfte es damit für weitere 
Nachbauinteressenten keine Probleme geben. R52 nehme ich als aktuelle 
Testversion auf.

Peter Sieg schrieb:
> und mit dem 'alten' dd unter admin Rechten dann das
> diskimage schreiben
Eignet sich das "neue" DD nicht zum Diskimage schreiben? Ich habe dazu 
bisher auch nur das "alte" verwendet.

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Joe G. Prima. Ich habe hier jetzt wie schon geschrieben, die R53 von 
Leo C im Einsatz.. die unterstützt aber wohl nicht mehr das urspüngliche 
HW Layout (sind ja nur die 2 Pins geändert..). Ich habe mir erlaubt 
diese Version auch mal wieder dem Entwickler Sprite_tm zukommen zu 
lassen.. Er freut sich sicher über solche Updates von Zeit zu Zeit..

Bei 220V erwarte ich auch 50Hz.. nachdem sich der Rauch verzogen hat.. 
;-)

Aber ich plane auch noch einen Test mit 40MHz.. da aber wohl mit einem 
Quarzoszi, da es wohl keine Grundton Quarze für diese Frequenz mehr 
gibt..
Da werde ich dann meinen LR Aufbau umbauen müssen.. ;-)

Joe G. schrieb:
> Eignet sich das "neue" DD nicht zum Diskimage schreiben? Ich habe dazu
> bisher auch nur das "alte" verwendet.

Anscheinend nicht.. ich habe es damit nicht hinbekommen.. evtl. findet 
mal jemand eines, das beides kann..

Peter

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
@alle

Der aktuelle Bearbeitungsstand liegt nun wieder auf dem SVN-Repositor.
Unter V 1.0 findet ihr den letzten Stand der noch mit der alten Hardware 
läuft. Bei den folgenden Versionen (Verzeichnis /Work) müssen die zwei 
Pins, wie weiter oben schon beschrieben, getauscht werden.

von Zwölfliter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Laufen denn auch schon große Programme wie Wordstar?

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Zwölfliter schrieb:
> Laufen denn auch schon große Programme wie Wordstar?

Derzeit laufen alle für den 8080 codierten Programme, egal ob groß oder 
klein. Keine Ahnung ob es Wordstar für den 8080 gab, ich kenne es nur 
für Z80.

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Leo C. Bezüglich mehrere Disketten (A: , B:, ...) wäre mein erster 
Ansatz gewesen, alle diskimages mit fester Größe ('disksize') direkt mit 
z.b dd hintereinander zu hängen und dies dann so auch per dd auf die SD 
Karte zu bringen.. Im AVR wäre dann ein 'Offset' zu halten, der beim 
Start=0 ist und
beim Wechseln von A: nach z.B B: dann entsprechend auf 1 wechselt.. 
(C=2,..)
Beim Zugriff auf die SD Karte ist dieser Offset dann entsprechend zu 
berücksichtigen (Offset * disksize = Block 0 der aktuellen 'Diskette')..

Peter

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> @Leo C. Bezüglich mehrere Disketten (A: , B:, ...) wäre mein erster
> Ansatz gewesen, alle diskimages mit fester Größe ('disksize') direkt mit
> z.b dd hintereinander zu hängen und dies dann so auch per dd auf die SD
> Karte zu bringen..

zu spät ;-)

Ich habe den code, um CPM-Laufwerke (A: .. D:) von Partitionen zu lesen, 
fast fertig. Z.Zt. kämpfe ich allerdings mit der SD-Karte/dem 
MMC-Treiber,
weil die Karte, die ich zum Testen nehmen wollte, Schwierigkeiten macht.
Werde jetzt erst mal meine alte Karte umpartitionieren.

Vorteil der Partitionen ist vor allem, daß man den nicht für 
CPM-genutzten Platz für andere Zwecke verwenden kann. Ich habe z.B. auf 
jeder Karte ein MP3-Verzeichnis fürs Auto.

Unter Linux ist es kein Problem, Partitionen mit beliebigen IDs 
anzulegen. Für CP/M ist 0x52 reserviert, und die möchte ich dann auch 
nehmen.
Ich weiß nicht, ob es für Windows auch gängige Partitionierungstools 
gibt, die das können. Aber notfalls gehts ja mit dd. Ist dann auch nicht 
umständlicher als ohne Partitionen.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Keine Ahnung ob es Wordstar für den 8080 gab, ich kenne es nur
> für Z80.

Seltsam, Wordstar ist ja imho das CP/M-Programm schlechthin. Ich bin 
eigentlich davon überzeugt. daß alle CP/M-80 Versionen von Wordstar auch 
auf 8080 laufen. Es sei denn, jemand hat in der Printer patch area 
Z80-Code verwendet (Oder so ähnlich).

Ich bin noch nicht dazu gekommen, einen Wordstar an meine 
Terminalemulation anzupassen. Der Worstar-Installer, den ich auprobiert 
habe, hatte kein VT10x und kein ANSI im Angebot. Gelaufen ist er aber.

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab es gerade mal ausprobiert. WS 3.0 läuft siehe Bild.

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Leo C. + Joe G. -> das solltet ihr entscheiden:
Hi again,

Just looked through the source. Seems the two guys made some truly
non-trivial improvements in the code, so I want to mention them on the
site and in the copyright. Do you know if it's OK if I just put down 'Leo
C.' and 'Joe G.' as their names, or do they want another moniker in there?

Jeroen

On Wed, 28 Jul 2010, Peter Sieg wrote:

> Hi Jeroen.
>
> Please find attached the actual version of your avrcpm project.
> 8080 opcodes fixed, warm start fixed, speed up of app. 100%,
> target are: atmege8,88,168 and 328.
> The improvements are not from me, but rather Leo C. and Joe G. from
> the german mikrocontroler forum!
> (2 pins have to be exchanged:
> Pin 24 - PC1 - /WE
> Pin 27 - PC4 - IO3)
>
> Many thanks, Peter

Am besten mir/hier kurz bescheid geben.. dann gebe ichs weiter oder
auch gerne natürlich direkt an:
jeroen (at) spritesmods.com

Peter

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Zum Testen habe ich eine etwas chaotische Partitionierung erzeugt:
leo@cb:~$ /sbin/fdisk -luc /dev/sdb

Disk /dev/sdb: 1009 MB, 1009254400 bytes
32 heads, 61 sectors/track, 1009 cylinders, total 1971200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0001fc66

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            8192     1890303      941056    6  FAT16
/dev/sdb2         1890304     1906687        8192   52  CP/M
/dev/sdb3            2048        8191        3072   52  CP/M

Partition table entries are not in disk order
leo@cb:~$ 
Die erste CP/M-Partition (A:) liegt also ganz hinten auf der SD-Karte.

Und das kommt raus:
A>CPM on an AVR, v1.0
Testing RAM: fill...wait...reread...
Initing mmc...
CP/M partition at: 1890304, size: 8192KB.
CP/M partition at: 2048, size: 3072KB.

Ok, CPU is live!
ipl

62k cp/m vers 2.2

A>stat a:dsk:

    A: Drive Characteristics
 1944: 128 Byte Record Capacity
  243: Kilobyte Drive  Capacity
   64: 32  Byte Directory Entries
   64: Checked  Directory Entries
  128: Records/ Extent
    8: Records/ Block
   26: Sectors/ Track
    2: Reserved Tracks

A>stat b:dsk:

    B: Drive Characteristics
 1944: 128 Byte Record Capacity
  243: Kilobyte Drive  Capacity
   64: 32  Byte Directory Entries
   64: Checked  Directory Entries
  128: Records/ Extent
    8: Records/ Block
   26: Sectors/ Track
    2: Reserved Tracks

A>

Das Disk-Format is noch das alte mit nur 243 Kilobyte. Die zugehörigen 
Tabellen sind jetzt noch fest im BIOS und werden demnächst dynamisiert.

Wie immer auf:
http://cloudbase.homelinux.net/viewvc/avr-cpm/trunk/avrcpm/

Neues BIOS ist auch notwendig, damits klappt.

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Leo C.: Frage: diskimages werden nach wie vor mit z.B dd aufgespielt?
Also z.B dd if=diskimage of=/dev/sdb2 bs=512 ...(unter Linux)..?

Super! Man(n).. selbst ein Vollzeit-Entwickler könnte da nicht schneller
dran arbeiten.. ;-) Da komme ich ja mit dem wechseln der Versionen nicht
nach..

Peter

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> @Leo C.: Frage: diskimages werden nach wie vor mit z.B dd aufgespielt?
> Also z.B dd if=diskimage of=/dev/sdb2 bs=512 ...(unter Linux)..?

Genau.

Übrigens,
für linux gibt es sfdisk, mit dem man Partitionstabellenänderungen 
scripten kann, zB. im Makefile. Mit "sfdisk -c /dev/sdb 2 52" kann man 
z.B. die Partitions-ID von Partition 2 auf 52 einstellen.

von Peter S. (petersieg)


Bewertung
0 lesenswert
nicht lesenswert
Soo.. klappt!
CPM on an AVR, v1.0
Testing RAM: fill...wait...reread...
Initing mmc...
CP/M partition at: 401625, size: 8032KB.
CP/M partition at: 417690, size: 8032KB.
CP/M partition at: 433755, size: 8032KB.

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 : TLOOP    COM : LOAD     COM : MBASIC   COM
A: 23       BAS : BAGELS   BAS : CHECKERS BAS : STARTREK BAS
A: TREKINST BAS : MASTRMND BAS : WEEKDAY  BAS : PIP      COM
A: STAT     COM : SUBMIT   COM : XSUB     COM : ZORK1    COM
A: ZORK1    DAT
A>b:


B>dir


B: TTT2     COM : OTHELLO  COM : MMIND    COM : ED       COM
B: LOAD     COM : STONE    COM : PIP      COM : STAT     COM
B: SUBMIT   COM : XSUB     COM
B>

...allerdings Partitionierung, Typ=52 setzen nur mit Linux Live-CD und 
cfdisk o.ä. Tools.. Auch bespielen per dd ging nur unter Linux, da das 
Windows dd die Typ=52 Partitionen nicht kennt/anzeigt..
=> Wer kennt ein s/cfdisk unter Windows..?

Ansonsten wiedermal Super!

Gruß Peter

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> ...allerdings Partitionierung, Typ=52 setzen nur mit Linux Live-CD und
> cfdisk o.ä. Tools.. Auch bespielen per dd ging nur unter Linux, da das
> Windows dd die Typ=52 Partitionen nicht kennt/anzeigt..

Etwas bequemer als PC mit Life-CD booten ist dann vielleicht dd und 
Binär/Hex-Editor.

dd if=/dev/sdb of=mbr-b.bin bs=512 count=1

mbr-b.bin editieren.
Der Aufbau der Partitionstabelle ist im Wikipedia-Artikel gut 
dargestellt:
http://de.wikipedia.org/wiki/Partitionstabelle

Der Partitionstyp steht also für die erste Partition auf  1C2. Für die 
nächsten 3 Partitionen entsprechend auf 1D2, 1E2, 1F2.
Dieses Byte auf 52 ändern und die Datei zurückschreiben:

dd of=/dev/sdb if=mbr-b.bin bs=512 count=1

Fertig.


> => Wer kennt ein s/cfdisk unter Windows..?

Ich hab auch mal kurz geschaut, ob es z.B. (g)parted für Windows gibt 
und bin gleich fündig geworden. Hurra... Linux-Live-CD!

von Peter S. (petersieg)


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Etwas bequemer als PC mit Life-CD booten ist dann vielleicht dd und
> Binär/Hex-Editor.

Hmm.. der Argumentation kann ich nicht folgen..?
Die Partitionierung muß bis ich was anderes weiß unter Linux (Live-CD 
etc.) erfolgen.. Und dann den MBR extrahieren, den Typ mit HEX-Editor 
ändern nur
damit ich unter Windows mit dd die dann erkannten Partition beschreiben 
kann, um danach den Typ wieder ändern zu müssen (auch wenn man eine 
MBR-Kopie verwendet..) scheint mir nicht wirklich einfacher zu sein.. 
:-(

Evtl. wäre es doch hierfür besser den Typ nicht auf 52 sondern FAT16 zu 
stellen..? Wenn die dann alle unter dd+Windows erkannt werden, dann 
müßte man nur einmalig die Partitionierung unter Linux vornehmen.. aber 
erstmal abwarten.. evtl. finden wir doch noch ein natives Windows Tool..

BTW: Es funktioniert nach wie vor auch nur eine primäre Partition FAT 
mit dem dd diskimage wie zuvor genutzt.. dann natürlich auch nur ein LW 
A:

Peter

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> BTW: Es funktioniert nach wie vor auch nur eine primäre Partition FAT
> mit dem dd diskimage wie zuvor genutzt.. dann natürlich auch nur ein LW
> A:

Diese Variante läuft bei mir mangels Linux auch gerade. Das kann aber 
nicht die Lösung sein. Ich untersuche gerade Diskpart.EXE für Windows.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Leo C. schrieb:
>> Etwas bequemer als PC mit Life-CD booten ist dann vielleicht dd und
>> Binär/Hex-Editor.
>
> Hmm.. der Argumentation kann ich nicht folgen..?
> Die Partitionierung muß bis ich was anderes weiß unter Linux (Live-CD
> etc.) erfolgen.. Und dann den MBR extrahieren, den Typ mit HEX-Editor
> ändern nur
> damit ich unter Windows mit dd die dann erkannten Partition beschreiben
> kann, um danach den Typ wieder ändern zu müssen (auch wenn man eine
> MBR-Kopie verwendet..) scheint mir nicht wirklich einfacher zu sein..
> :-(

Wer hat denn soooo argumentiert?

Partitionieren kann man doch noch immer unter Windows, oder?
Warum also nicht mit dem Windows Partitionierer die Karte nach Wunsch 
aufteilen, und den CP/M-Partitionen vorläufig einen Typ geben, den 
Windows kann.

Dann das Windows fdisk oder Festplattenverwaltungswerkzeug, oder wie 
auch immer das Teil unter NT, XP,... heißt, verlassen und anschließend 
dd und Hex-Editor?


> Evtl. wäre es doch hierfür besser den Typ nicht auf 52 sondern FAT16 zu
> stellen..? Wenn die dann alle unter dd+Windows erkannt werden, dann
> müßte man nur einmalig die Partitionierung unter Linux vornehmen..

Mein Ironiedetektor scheint gerade nicht zu funktionieren.
Und dd kennt weder Partitionstypen (Partition IDs) noch Dateisysteme.

> BTW: Es funktioniert nach wie vor auch nur eine primäre Partition FAT
> mit dem dd diskimage wie zuvor genutzt.. dann natürlich auch nur ein LW
> A:

Das hat aber mit einer primären FAT überhaupt nichts zu tun. In diesem 
Fall ist nach dem dd auf der Karte kein MBR mehr, keine 
Partitionstabelle, und keine Partitionen, schon gar keine mit FAT...
Und was vorher auf der Karte war, spielt überhaupt keine Rolle mehr.

Wenn ich in dem neuen Programm keine Partitionstabelle finde, dann mache 
ich der Einfachheit halber das gleiche wie vorher. Das heißt, wenn am 
Anfang der SD-Karte "zufällig" ein CP/M-Dateisystem steht, gehts 
weiter...


ps: Meinen Rechner habe ich diese Woche noch nicht neu gestartet. Und 
nur, um eine Speicherkarte zu formatieren, werde ich das ganz bestimmt 
nicht tun.
leo@cb:~$ uptime
 17:09:00 up 10 days,  5:17, 15 users,  load average: 0.26, 0.18, 0.06

von Peter S. (petersieg)


Bewertung
0 lesenswert
nicht lesenswert
@Leo C.
Meine SD Karte ist unter Linux etwa so partitioniert:
/dev/sdh1  200MB  FAT16
/dev/sdh2    8MB  CP/M
/dev/sdh3    8MB  CP/M
/dev/sdh4    8MB  CP/M
(app. 30MB unnused)

Diese Karte unter dem windows dd zeigt NUR die FAT16 Partition an!
Wenn ich da ein dd if=diskimage of=\\...die einzige angezeigte Part... 
bs=512 mache, läuft avrcpm damit als A:

Wie gesagt, die Typ=52 = CP/M Partitionen werden erst gar nicht von dem
Tool unter Windows angezeigt.. ignoriert als wenn es sie gar nicht 
gäbe..
Daher vermute ich, das wenn man vom Type CP/M hin zu FAT16 auch die 
anderen Partitionen eben wieder zugreifbar macht.. und dann auch wieder 
unter Windows mit dd beschreiben kann..

diskpart unter Windows gibt mir:
  Datentr ###  Status      Größe    Frei     Dyn  GPT
  --------  ----------  -------  -------  ---  ---
       0    Online       149 GB      0 B
       1    Online       244 MB    23 MB
       2    Kein Mediu      0 B      0 B
       3    Kein Mediu      0 B      0 B
       4    Kein Mediu      0 B      0 B
       5    Kein Mediu      0 B      0 B
       6    Kein Mediu      0 B      0 B
       7    Kein Mediu      0 B      0 B
       8    Kein Mediu      0 B      0 B

DISKPART> select disk 1

Datenträger 1 ist jetzt der gewählte Datenträger.

DISKPART> list part

  Partition ###   Typ              Größe    Offset
  -------------  ----------------  -------  -------
  Partition 1    Primär             196 MB    32 KB
  Partition 0    Primär            8033 KB   196 MB
  Partition 0    Primär            8033 KB   204 MB
  Partition 0    Primär            8033 KB   212 MB

Ich persönlich habe kein wirkliches Problem mit einer Linux Live-CD..
Finde aber es aber schade, das wir nun ohne Linux - allein mit Windows 
Mitteln - nicht mehr auskommen.. wobei wir ja noch 'das Tool' evtl. noch
finden.. (diskpart ist ein Krampf..)

Gruß Peter

von Peter S. (petersieg)


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Partitionieren kann man doch noch immer unter Windows, oder?
> Warum also nicht mit dem Windows Partitionierer die Karte nach Wunsch
> aufteilen, und den CP/M-Partitionen vorläufig einen Typ geben, den
> Windows kann.
>
> Dann das Windows fdisk oder Festplattenverwaltungswerkzeug, oder wie
> auch immer das Teil unter NT, XP,... heißt, verlassen und anschließend
> dd und Hex-Editor?

Das könnte so gehen.. aber das ist nicht einfacher als gleich eine 
Live-CD zu nehmen.. (just my 2 cents)..

Peter

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Diese Karte unter dem windows dd zeigt NUR die FAT16 Partition an!

Das dd, das ich kenne, kann überhaupt keine Partitionen anzeigen.
Das Windows dd scheint etwas völlig anderes zu sein.

> Wenn ich da ein dd if=diskimage of=\\...die einzige angezeigte Part...
> bs=512 mache, läuft avrcpm damit als A:

Wie greift man denn mit dd auf Geräte, bzw Partitionen, zu? Die 
interessanteste Information hast Du weggelassen.


> Wie gesagt, die Typ=52 = CP/M Partitionen werden erst gar nicht von dem
> Tool unter Windows angezeigt.. ignoriert als wenn es sie gar nicht
> gäbe..


> Daher vermute ich, das wenn man vom Type CP/M hin zu FAT16 auch die
> anderen Partitionen eben wieder zugreifbar macht.. und dann auch wieder
> unter Windows mit dd beschreiben kann..

Da kämen wir aber garantiert in Teufels Küche. Zum einen wird sich dann 
Windows über jede (avr-)CP/M-Partition hermachen, und vielleicht 
versuchen, sie zu reparieren. Zum anderen wird unser avr von jder 
FAT16-Partition booten wollen, die ihm unter die Kontakte kommt. Ich 
bestehe nicht auf die 52, aber IDs, die Windows kennt, kann man halt 
nicht nehmen.
>   Partition ###   Typ              Größe    Offset
>   -------------  ----------------  -------  -------
>   Partition 1    Primär             196 MB    32 KB
>   Partition 0    Primär            8033 KB   196 MB
>   Partition 0    Primär            8033 KB   204 MB
>   Partition 0    Primär            8033 KB   212 MB

Also Windows sieht die Partitionen ja. Dann sollte es auch ein Wergzeug 
geben, mit dem man darauf zugreifen kann. dd?

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Diese Karte unter dem windows dd zeigt NUR die FAT16 Partition an!
> Wenn ich da ein dd if=diskimage of=\\...die einzige angezeigte Part...
> bs=512 mache, läuft avrcpm damit als A:

Ach ja, hatte ich ganz vergessen:
Es geht ja hier garnicht um Partitionen. Es geht darum, den ersten 
Sektor von der Platte zu lesen und zu schreiben. Und das kann das dd, 
das Du benutzt ja offensichlich. Schließlich hast Du bisher damit deine 
CP/M-Images auf die Karten gebracht. Und wenn dd ab dem ersten 
Platten-/Kartensektor schreiben kann, wird es wohl auch den 1. Sektor 
lesen können.



Peter Sieg schrieb:
> Das könnte so gehen.. aber das ist nicht einfacher als gleich eine
> Live-CD zu nehmen.. (just my 2 cents)..

Für mich schon.
Bevor ich den Rechner (hier sogar 2x) wegen irgendwas neu starten muß, 
installiere ich doch lieber gleich ein anderes Betriebssystem. (scnr)
Achso, daß habe ich vor 16 Jahren ja gemacht.

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Leo C.: Na, nu lass mal gut sein :-) Windows User, die keine Linux 
Live-CD nehmen wollen, haben ja durch den sehr guten Fall-Back 
Mechanismus immerhin das was alle vorher hatten.. nämlich LW A: = 
gerechte Strafe würden jetzt Linux Nutzer sagen - alle anderen haben 
halt bis zu 4 Laufwerke.. ;-)
=> kann ICH mit leben..

Trotzdem suche ich weiter, das unter Windows noch hinzubekommen.. ok? 
;-)
(Cygwin hat cfdisk.. vergesst es!! Bloß die Finger weg davon.. erkennt 
LW/Part. ebenfalls nicht.. und trägt sich noch nichtmal sauber ein zum 
deinstallieren..)

Bin übrigens am WE nicht/wenig online..

Peter

von Peter S. (petersieg)


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Wie greift man denn mit dd auf Geräte, bzw Partitionen, zu? Die
> interessanteste Information hast Du weggelassen.
C:\cpmtools>dd2 --list
rawwrite dd for windows version 0.5.
Written by John Newbigin <jn@it.swin.edu.au>
This program is covered by the GPL.  See copying.txt for details
Win32 Available Volume Information
...
NT Block Device Objects
\\?\Device\CdRom0
  size is 2147483647 bytes
\\?\Device\Harddisk0\Partition0
  link to \\?\Device\Harddisk0\DR0
  Fixed hard disk media. Block size = 512
  size is 160040803840 bytes
\\?\Device\Harddisk0\Partition1
  link to \\?\Device\HarddiskVolume1
\\?\Device\Harddisk0\Partition2
  link to \\?\Device\HarddiskVolume2
  Fixed hard disk media. Block size = 512
  size is 9663676416 bytes
\\?\Device\Harddisk1\Partition0
  link to \\?\Device\Harddisk1\DR1
  Removable media other than floppy. Block size = 512
  size is 255852544 bytes
\\?\Device\Harddisk1\Partition1
  link to \\?\Device\HarddiskVolume3
  Removable media other than floppy. Block size = 512
  size is 205599744 bytes
\\?\Device\Harddisk2\Partition0
  link to \\?\Device\Harddisk2\DR2
\\?\Device\Harddisk2\Partition1
...

Wie man sieht, wird die gesamte SD Karte als 
\\?\Device\Harddisk1\Partition0 erkannt und die FAT16 Partition als 
\\?\Device\Harddisk1\Partition1.
Die anderen 3 Partition = Essig.

Und einfach auf ...Part.2 zu schreiben geht nicht:
C:\cpmtools>dir game*
 Datenträger in Laufwerk C: ist VISTA
 Volumeseriennummer: 849E-3C87

 Verzeichnis von C:\cpmtools

29.07.2010  13:31            71.168 gameimage
               1 Datei(en),         71.168 Bytes
               0 Verzeichnis(se), 98.861.772.800 Bytes frei

C:\cpmtools>dd2 if=gameimage of=\\?\Device\Harddisk1\Partition2 bs=512
rawwrite dd for windows version 0.5.
Written by John Newbigin <jn@it.swin.edu.au>
This program is covered by the GPL.  See copying.txt for details
Error native opening file: 0 Der Vorgang wurde erfolgreich beendet

Peter

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> \\?\Device\Harddisk1\Partition0
>   link to \\?\Device\Harddisk1\DR1
>   Removable media other than floppy. Block size = 512
>   size is 255852544 bytes

> Wie man sieht, wird die gesamte SD Karte als
> \\?\Device\Harddisk1\Partition0 erkannt und die FAT16 Partition als

Also müßtest Du den MBR so lesen können?
dd if=\\?\Device\Harddisk1\Partition0 of=mbr-b.bin bs=512 count=1

Wenn ja, anschließend die ID's ändern und den MBR zurückschreiben.

> \\?\Device\Harddisk1\Partition1.
> Die anderen 3 Partition = Essig.

Das ist natürlich ausgesprochen schade, daß die dort nicht erscheinen.
Dann müßte man vor und nach jedem Beschreiben einer CP/M-Partition den 
MBR ändern. Das wäre mir dann auch zu umständlich.

Zu dem Thema habe ich das hier vorhin gefunden:
http://www.chrysocome.net/dd-backdoor

Das macht aber auch keinen Spaß.

> Und einfach auf ...Part.2 zu schreiben geht nicht:

Unter Linux kann man mit den cpmtool direkt auf die Karte zugreifen:
leo@cb:~$ cpmls -d -f avrcpm /dev/sdf3
ASM      COM : DDT      COM : DUMP     COM : ED       COM
INSTALL  COM : LOAD     COM : PIP      COM : STAT     COM
SUBMIT   COM : T        BIN : XSUB     COM : MAILMRGE OVR
MERGPRIN OVR : WIMSGS   OVR : WS       COM : WSMSGS   OVR
WSOVLY1  OVR : WSU      COM

Da lohnt es sich ja fast, Linux in einer virtuellen Maschine zu 
installieren, wenn man ansonsten mit Windows weiterarbeiten möchte.

von Peter S. (petersieg)


Bewertung
0 lesenswert
nicht lesenswert
Um mal etwas von der Diskussion der Partitionieung unter Windows 
abzulenken.. ;-)

Aus meiner Sicht könnten nächste Schritte sein:
* Diskettenimage von 243kb vergrößern Richtung 1-xMB.
  (Den riesigen Platz kann man ohne Unterverzeichnisse CP/M-like über 
andere
  USER x etwas übersichtlicher gestalten.. und die cpmtools erlauben die
  Befüllung unterschiedlicher Userbereiche)
  Da hat man dann auch mit nur einer 'Diskette' was davon ;-)
* Eine Möglichkeit auch ohne cpmtools einzelne Dateien zwischen der CP/M 
und
  der Host Welt auszutauschen. Das N8VEM Projekt verwendet dazu 
klassisch
  ein XModem (XM.COM) Programm.. das wäre sicher auch für uns eine gute 
Wahl.
  Andere Ideen..?
* Dann kämen ggf. die Z80 Opcodes dran...
* Und wie wäre es mit einem passenden, seriellen Terminal mit 
BAS/VGA/LCD als
  Bildschirm und PS/2 Tastatur ala PropTerm.. aber auch auf AVR Basis..?

Peter

von Peter S. (petersieg)


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Also müßtest Du den MBR so lesen können?
> dd if=\\?\Device\Harddisk1\Partition0 of=mbr-b.bin bs=512 count=1
>
> Wenn ja, anschließend die ID's ändern und den MBR zurückschreiben.

Ja kann ich.. ändert aber leider nichts daran, das dd die Partitionen 
dann immer noch nicht bearbeiten kann.. der muß da wohl noch mehr als 
nur die ID prüfen.. :-(

Peter

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Um mal etwas von der Diskussion der Partitionieung unter Windows
> abzulenken.. ;-)

Oh, heute komme ich gar nicht mehr zum Essen.

> Aus meiner Sicht könnten nächste Schritte sein:
> * Diskettenimage von 243kb vergrößern Richtung 1-xMB.

Klar, das muß kommen. Mit einem festen Format wärs auch schnell 
gemacht.

>   (Den riesigen Platz kann man ohne Unterverzeichnisse CP/M-like über
> andere
>   USER x etwas übersichtlicher gestalten.. und die cpmtools erlauben die
>   Befüllung unterschiedlicher Userbereiche)

Leider werden die Userbereiche von CP/M 2.2 sehr schlecht unterstützt.
Mit CP/M 3 oder einer der 2.2 Alternativen wäre man da besser dran.

> * Eine Möglichkeit auch ohne cpmtools einzelne Dateien zwischen der CP/M
> und
>   der Host Welt auszutauschen. Das N8VEM Projekt verwendet dazu
> klassisch
>   ein XModem (XM.COM) Programm.. das wäre sicher auch für uns eine gute
> Wahl.

Sollte kein Problem sein. Einfach mal ausprobieren.

>   Andere Ideen..?

CP/NET? ;-)

> * Dann kämen ggf. die Z80 Opcodes dran...

Irgendwann sollte man das mal angehen, bevor das Flash mit anderen 
Sachen voll ist. ;) Der Interpreter wird dadurch aber auf jeden Fall 
langsamer werden. Ein Grund, warum ich das bisher nicht angegangen bin. 
Wenn da nicht das ein oder andere wichtige Programm wäre, das Z80 
vorraussetzt (mir fällt gerade nur Turbopascal ein), würde ich es sogar 
ganz bleiben lassen.

> * Und wie wäre es mit einem passenden, seriellen Terminal mit
> BAS/VGA/LCD als
>   Bildschirm und PS/2 Tastatur ala PropTerm.. aber auch auf AVR Basis..?

Anderes Projekt. :-)

Ansonsten will ich noch eine RAM-Disk einbauen. Beim Originalaufbau hat 
man dafür zwar nur 64KByte, aber man könnte schonmal CCP+BDOS dort 
deponieren und beim Warmstart von dort laden. Außerdem habe ich bei 
meinem Aufbau jetzt 2 4x4MBit Chips drin. Das gibt dann eine RAM-Disk 
mit knapp 4 MByte. :)

von Dagobert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Zum Thema Terminal:

Schaut euch mal VGATerm auf www.dieprojektseite.de an.

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Dagobert: Für 44,90€ ein gekapseltes Modul, was man dann noch mit 
weiteren Bauteile in Richtung > 60€ zusammenbauen muß..?? Nein Danke. 
Ansonsten schöne Arbeit.

@Leo C.
>Klar, das muß kommen. Mit einem festen Format wärs auch schnell
>gemacht.
Warum nicht.. ist doch jetzt auch ein festes Format.. man muß doch nicht
immer alles variabel halten.. besser wäre es da wenn das ein Format 
wäre,
das man auch dem AltairZ80 Emulator beibringen könnte.. dann kann man 
Images
im Emulator laufen lassen und per R/W auch Dateien zw. CP/M und 
Hostsystem transferieren..

Peter

von hschuetz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,
das Modul gibts für 28,49 Euro, hat alles on Board, auch eine 3,3V 
Stromversorgung (200mA)...
http://www.watterott.com/de/Schnittstellen/Video-VGA
Gruß
Hans- Werner

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
hschuetz schrieb:
> das Modul gibts für 28,49 Euro, hat alles on Board, auch eine 3,3V
> Stromversorgung (200mA)...
> http://www.watterott.com/de/Schnittstellen/Video-VGA

@hschuetz: Super, Danke! Genau was ich gesucht habe.. gleich mal eins 
bestellt.. ;-)

Peter

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Es gab Anfragen ob noch Leiterplatten verfügbar wären. Leider nein.
Bei genug Interessenten könnte natürlich eine neue Serie mit den 
entsprechenden Änderungen aufgelegt werden. Mir fällt da spontan ein:
- geänderte Pinbelegung am RAM (RAM Disk)
- Video-VGA siehe weiter oben.
- weitere Vorschläge ???

von Dagobert (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Es gab Anfragen ob noch Leiterplatten verfügbar wären. Leider nein.
> Bei genug Interessenten könnte natürlich eine neue Serie mit den
> entsprechenden Änderungen aufgelegt werden.

@Joe G. Ja, die beiden Pin's am Ram sollte mindestens aufgrund der 
heutigen Erfahrungen getauscht werden.. ;-) Größerer Ram../ Ramdisk.. 
warten, was Leo C. hier zaubert.. beim Thema Terminal wirds etwas 
schwieriger..
Was ich bisher so gefunden hatte:
Beitrag "AVR ASCII Video Terminal  - 40 x 25  - BAS Signal"
http://www.serasidis.gr/circuits/AVR_VGA/avr_vga.htm
Beitrag "Einfacher Low Cost LCD Controller für 320x240 LCD im Textmodus"
http://www.shaels.net/index.php/propterm

Obigen 3 fehlt noch die PS/2 Tastatur inkl. senden zum AVR.. Code dafür 
ist
sicher verfügbar.. also entweder noch mit einbauen oder separat im 
weiteren AVR aufbauen.. ideal würde ich auch die Realisierung mit 
ATmega88/168 ansehen.. gleicher Baustein.. kann locker mir 20MHz - sogar 
30MHz.. ein Programmer..
Propterm ist von dem was es kann sicher ideal.. aber ganz andere HW 
Welt..
---
Wenn daran überhaupt genügend Interesse besteht (an einem passenden 
Selbstbau-Terminal..) würde ich einen separaten Thread dazu 
vorschlagen..
Und ein solches Terminal sollte ersteinmal entwickelt und auf 
Steckbrett/LR aufgebaut werden, um dann zu entscheiden, ob es eine 
separate Platine/abtrennbare Platine oder eine gemeinsame mit AVR CP/M
werden soll.. ich werde ersteinmal das uVGA testen.. da es auch 3,3V zur 
Verfügung stellt.. fast schon ideal.. und für ca. 30€ kaum zu schlagen..

In jedem Fall wäre ich bei einer Neuauflage mit 1 Platine dabei ;-)

Dann sollte man auch mal prüfen, inwieweit aus den Ideen von Jörg 
Wolfram (eigene Hardware mit BAS+PS/2 und SRAM-8bit) inzwischen etwas 
geworden ist..

Peter

von Dagobert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das Problem bei fast allen Tastatur-Routinen ist es, dass meist nur 
Normal und Shift-Ebene unterstützt wird, Alt-Ebene oder gar Sondertasten 
kann man lange suchen. Von Caps-Lock-Steuerung rede ich gar nicht erst. 
;)

Eine vollständige Tastatursteuerung, wie in VGATerm enthalten, hat es in 
sich.

Auch die Ansteuerung des µVGA-Moduls ist sehr Tückenreich. Z.B. gibt es 
oft Timing-Probleme, wodurch man viele Warteschleifen einbauen muss. Das 
wurde mit VGATerm ebenso, dank eines 32 kB Empfangspuffers, eliminiert.

Aber wenn man die Unwegsamkeiten erst einmal überwunden hat, hat man 
eine wirklich nutzbare VGA-Ansteuerung. Bei den oben genannten Systemem 
fallen viele CP/M-Programme weg, weil diese einen 80x25-Zeichen 
Bildschirm erfordern.

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dagobert schrieb:
> Bei den oben genannten Systemem
> fallen viele CP/M-Programme weg, weil diese einen 80x25-Zeichen
> Bildschirm erfordern.

Ja.. alerdings basiert die BAS Lösung auf ATmega8 mit 16MHz.. Mit 88/168 
und 25-30MHz sollte sich da ggf. noch was dran machen lassen..
Propterm hat schon alles was es braucht..
Allerdings zeigenja auch gerade VGAterm + uVGA das es grundsätzlich geht 
;-)
Cool wäre aber aus meiner Sicht auch eine LCD Lösung..

Peter

von Dagobert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe einige Jahre nach einer aufbaubaren Lösung gesucht. Immer war 
ein CPLD oder FPGA notwendig. Ein normaler AVR schaffte evtl. gerade mal 
die 80x25 Zeichen in SW und dann komplett ohne umfangreichere 
Steuermöglichkeiten.

Bin mal gespannt, ob hier evtl. etwas entsteht, was auch von 'Max 
Mustermann' ohne großes Programmierequipment oder Profi-SMD-Austattung 
aufgebaut werden kann ;)

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Warum nicht.. ist doch jetzt auch ein festes Format.. man muß doch nicht
> immer alles variabel halten..

Dann denk dir ein schönes Format aus (Größe u. Anzahl Dir-Einträge), 
schnapp Dir das Alteration Guide oder eine andere Beschreibung und 
erstelle die beiden Tabelleneinträge. Dann einfach in bios.asm 
eintragen. den dpb braucht man dann nur einmal. Ich hatte nur 4 Plätze 
für maximal 4 verschiedene Diskformate vorgesehen. Gestern Abend dachte 
ich noch, damit wäre schon alles fertig.

Leider hatte ich nicht dran gedacht, daß bei Diskgrößen über 256KB die 
Blockgrößte mindestens 2048 sein muß. Und die ist z.Zt. noch als 
Konstante im avr-Teil.

also muß man noch in z80.asm unter
;*****************************************************
;*         CP/M to host disk constants               *
;*****************************************************

ändern auf
  .equ  blksize = 2048    ;CP/M allocation size

(oder gößer)

Bei der Gelegenheit kann man auch die Anzahl Sektoren pro Track auf 
einen etwas größeren und "runderen" Wert setzen. Das muß aber nicht 
sein. Mit 26 SPT kommt man auch bis 218MB Diskgröße. zB:
  .equ  CPMSPT = 32    ; oder 64 oder ...

Fertig. Ergebnis ggf. hier reinstellen oder mir zuschicken.
Natürlich darf sich auch jede(r) andere hier angesprochen fühlen.

Ach ja, ein passender Formateintrag für die cpmtools wäre dann auch 
nicht schlecht, damit man damit einfach vom alten Format aufs neue 
umkopieren kann.


> besser wäre es da wenn das ein Format wäre,
> das man auch dem AltairZ80 Emulator beibringen könnte.. dann kann man
> Images
> im Emulator laufen lassen und per R/W auch Dateien zw. CP/M und
> Hostsystem transferieren..

Falls Du den simh Altair 8800 Simulator meinst (den kenne ich, es gibt 
aber wahrscheinlich noch andere):

Der hat variable Formate! Das Disk Image ist sicher irgendwo 
dokumentiert (auf jedenfall im source, natürlich) aber ich bin bis jetzt 
noch nicht über die Doku gestolpert. Vor dem eigenlichen CP/M-Diskimage 
ist auf jeden Fall noch ein nicht gerade kleiner Header.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Es gab Anfragen ob noch Leiterplatten verfügbar wären. Leider nein.
> Bei genug Interessenten könnte natürlich eine neue Serie mit den
> entsprechenden Änderungen aufgelegt werden. Mir fällt da spontan ein:
> - geänderte Pinbelegung am RAM (RAM Disk)
> - Video-VGA siehe weiter oben.
> - weitere Vorschläge ???

Wie wärs mit 2 RAM-Chips (8 Bit breiter Datenbus)? Die Chips sind ja 
massenweise kostenlos vorhanden und der Schaltungsmehraufwand ist imho 
minimal. Also immer noch ein Lowcost Projekt.

Damit sich das lohnt, braucht man am Prozessor einen 8 Bit breiten Port. 
Den bekommt man, wenn man die Serielle Schnittstelle verlegt. So sieht 
dann das Ergebnis aus:
-------------------------------------------------------
           |  Peters  |        Leos        |
           | Schleife |      Schleife      |
-----------+----------+--------------------+-----------
AVR   MHz  | Zeit [s] | Zeit [s]   "Speed" | HW    SW    
-----------+----------+---------+----------+-----------
 8    20     12,180                           A     0
 8    20     12,453      3.488     827 KHz    A     1
 8    20     11.500      3.488     827 KHz    A     3
-------------------------------------------------------
 8    20      7.599      2.039    1380 KHz    C     2
 8    20      6.680      2.039    1380 KHz    C     3
-------------------------------------------------------
 8    20      6.418      1.958    1470 KHz    C     4


"HW A" ist die jetzt aktuelle Verdrahtung und "HW C" die 8-Bit Variante.

Es ist also fast nochmal eine Geschwindigkeitsverdopplung drin.

Zu den Details hatte ich am Montag schon mal einen Artikel geschrieben, 
der aber hier nicht (mehr?) vorhanden ist. Vielleicht drücke ich ja 
öfters auf Vorschau statt Absenden, oder...

Die Software dazu gibts in meinem SVN im softuart Zweig.

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Wie wärs mit 2 RAM-Chips (8 Bit breiter Datenbus)? Die Chips sind ja
> massenweise kostenlos vorhanden und der Schaltungsmehraufwand ist imho
> minimal. Also immer noch ein Lowcost Projekt.

Die Idee finde ich super! Welche Baudrate ist dann mit Soft-Uart noch 
sinnvoll? Alternativ wäre natürlich auch ein AVR mit mehr Pin's :-)

Leider bin ich dieses WE in Familienfeier unterwegs.. ich werde mir aber
nächste Woche mal das CP/M Alteration Guide besorgen und mal versuchen,
das diskimage Format zu vergrößern.. soll aber niemanden davon abhalten 
das auch zu machen.. bei mir kann das schon etwas dauern.. ;-) ;-)

Peter

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Die Idee finde ich super! Welche Baudrate ist dann mit Soft-Uart noch
> sinnvoll? Alternativ wäre natürlich auch ein AVR mit mehr Pin's :-)

Senden geht mit 115k problemlos.
Empfangen habe ich bis 56700 getestet. Das ging, als die gröbsten Fehler 
draußen waren. Es könnte auch noch mehr dring sein. Der Code ist aber 
noch etwas chaotisch und müßte dringend aufgeräumt werden. Dann könnte 
man auch noch eine etwas bessere Fehlererkennung/behandlung einbauen. 
"Leider" gibts bei der üblichen Verbindung mit PC ja so gut wie keine 
Übertragungsfehler.

Gilt alles für 20Mhz Prozessortakt.

> Leider bin ich dieses WE in Familienfeier unterwegs.. ich werde mir aber
> nächste Woche mal das CP/M Alteration Guide besorgen und mal versuchen,
> das diskimage Format zu vergrößern.. soll aber niemanden davon abhalten
> das auch zu machen.. bei mir kann das schon etwas dauern.. ;-) ;-)

Ich werde mich bis auf Weiteres auch nicht dransetzen, da ich ja gar 
kein größeres Format brauche. ;-)

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Den Satz hatte ich doch glatt übersehen:

Peter Sieg schrieb:
> Alternativ wäre natürlich auch ein AVR mit mehr Pin's :-)

Ja klar, und statisches RAM und...
... und vielleicht doch ein ez80 :-)

Übrigens habe ich Moment rein zufällig genau die 2 Pins für die 
I2C-Schittstelle frei... :-)

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Wie wärs mit 2 RAM-Chips (8 Bit breiter Datenbus)? Die Chips sind ja
> massenweise kostenlos vorhanden und der Schaltungsmehraufwand ist imho
> minimal. Also immer noch ein Lowcost Projekt.

Gute Idee Port D doppelt zu belegen, auch PC4 und PC5 frei zu lassen. 
Was möchtest du dort angeschlossen haben, ein RTC, eine PIO, ...
Ich erstelle mal einen neunen Schaltplan zu der Soft-Uart Variante.

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:

Da das Erstellen mehrerer diskimages unter Windows nun etwas kompliziert 
wird, siehe weiter oben, bietet sich ein nettes Tool wie "Parted Magic" 
an. Läuft  als Live-CD oder USB-Stick oder unter VM.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Was möchtest du dort angeschlossen haben, ein RTC, eine PIO, ...

Wg. I2C drängt sich eine RTC ja förmlich auf. Aber irgend was sträubt 
sich in mir. Gibt es I2C-(Flash-)ROMs im ca. einstellingen Megabit 
Bereich? So als ROM-Disk oder SSD?

Ursprünglich dachte ich an Inputs, z.B. Taster für Z80 Reset, bzw. 
Interrupt.
Damit könnte man z.B. ein hängendes Programm in den Debugger 
zurückholen.

Frontpanel?

CS-Leitungen für SPI-Erweiterungen wäre auch denkbar.


Am Besten ein großes Lochrasterfeld vorsehen. Und/Oder Pfosten für 
Huckepackerweiterungen.

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Als DRAM habe ich 1Mx4 im SOJ26-20 Package vorgesehen. Das sollte noch 
gut zu löten sein und außerdem gut verfügbar. Bei I2C bin ich mir noch 
unsicher, Portererweiterung ist auch denkbar.

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@Leo C. alle anderen natürlich auch.

Bitte mal durchsehen ob der RAM / MMC mit der Soft-Uart Variante 
übereinstimmt.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Das ist ja mal wieder ein Mist. (sorry, mußte raus)

Ich habe gerade meine Bestände durchgesehen, und festgestellt, daß ich 
fast nur 4Mx4 habe. Ich dachte mir, macht ja nix, man kann ja einfach 
die 2 Adressleitungen zusätzlich verbinden. In dem einen Datenblatt, daß 
ich von 1Mx4 hier habe, habe ich aber gerade gesehen, daß die 
anscheinend eine völlig andere Pinbelegung haben.


Joe G. schrieb:
> @Leo C. alle anderen natürlich auch.
>
> Bitte mal durchsehen ob der RAM / MMC mit der Soft-Uart Variante
> übereinstimmt.

Ich habe bis jetzt nur mal kurz drauf geschaut. Und es stimmt leider. 
Deine Verdrahtung paßt zu dem 1Mx4 Datenblatt, und die 4Mx4 Datenblätter 
sind alle anders. Beides vorsehen, für wahlweise Bestückung, wird wohl 
viel zu aufwendig sein. Mir ist es egal, weil ich keine Platine brauche.

In meiner PC-Restekiste habe ich 7 verschiedene 72-polige RAM-Modul 
Sorten.
Davon nur eines mit 1Mx4 bestückt.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> @Leo C. alle anderen natürlich auch.
>
> Bitte mal durchsehen ob der RAM / MMC mit der Soft-Uart Variante
> übereinstimmt.

An die Datenleitungen von IC5  (oder IC4) sollten D4_A4 bis D7_A7 
angeschlossen werden.

1Mx4 Chips haben auch eine A9. Nächster Pin wäre PB4 (MISO).
Und falls es 4Mx4 Chips werden sollten, käme noch eine A10 dazu (--> 
PB5).

Der Rest scheint ok zu sein. RAS bis WE, A8 bis A9/10 und D0_A0 bis 
D7_A7 kann man sowieso frei untereinander tauschen, wenn dadurch z.B. 
das Layout einfacher wird.

Pullups am SD-Slot?
Chan empfiehlt sie sehr (aber einen Pulldown an CLK), hat sie aber bei 
seinem neuesten GPS-Logger auch weggelassen.

Ich mache immer eine LED an CS mit R nach VCC. Macht sich hier besonders 
gut als Drive-Select-Lampe.

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@all: An Rams kann man aber auch die 256x4 2-mal nehmen.. 2ter Chip in 
jetziger Platine huckepack, nur D0-D3 an D4-D7.. damit sollte die 
vorhandene
Platine auch auf 8-bit Dram erweiterbar sein (4 Leitungen zum 
Huckepackram legen + Uart umverdrahten..)
(PS: Ich finde die SOJ SCH*** zum löten ;-) - aber habe ich auch schon 
hinbekommen..)

Peter

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> An die Datenleitungen von IC5  (oder IC4) sollten D4_A4 bis D7_A7
> angeschlossen werden.

Hab ich beim abspeichern gemerkt, ist schon geändert.

Leo C. schrieb:
> Pullups am SD-Slot?
> Chan empfiehlt sie sehr (aber einen Pulldown an CLK), hat sie aber bei
> seinem neuesten GPS-Logger auch weggelassen.

Pullups sind ja normalerweise im AVR schon vorhanden, Pulldown an CLK? 
steilere Flanken? Mein Oszi zeigt kein Unterschied.

Leo C. schrieb:
> Ich mache immer eine LED an CS mit R nach VCC. Macht sich hier besonders
> gut als Drive-Select-Lampe.

Nette Idee.

RAM Frage:
1M x4 oder 4M x4, mir ist es egal. Peter möchte nicht löten ;-) Ich 
nehme meine ursprügliche Idee mal wieder auf. Für den RAM gibt es eine 
28 polige IC Fassung und da steckt jeder drauf was er hat. Als 
"Default-RAM-Stecker-Layout" gib es drei kleine RAM-Adapterplatinen, 1M 
x4, 4M x4, 256 x 4.

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Pullups sind ja normalerweise im AVR schon vorhanden, Pulldown an CLK?
> steilere Flanken? Mein Oszi zeigt kein Unterschied.

Am CLK ist Low-Pegel der Normal/Ruhezustand. Bei den anderen Pins ist es 
High.

Zur Zeit werden die internen Pullups komplett abgeschaltet, damit man 
ganze Bytes auf die Ports schreiben kann, ohne daß Pullups in Portbits, 
die als Input programmiert sind, ständig ein- und ausgeschaltet werden.
Für die jetzige Schaltung kann man das aber ändern, wenn man PC4 und PC5 
nicht als Inputs benutzt, oder das Pullupflattern egal ist.

Bleibt noch der Resetzustand...


> RAM Frage:
> 1M x4 oder 4M x4, mir ist es egal. Peter möchte nicht löten ;-) Ich
> nehme meine ursprügliche Idee mal wieder auf. Für den RAM gibt es eine
> 28 polige IC Fassung und da steckt jeder drauf was er hat. Als
> "Default-RAM-Stecker-Layout" gib es drei kleine RAM-Adapterplatinen, 1M
> x4, 4M x4, 256 x 4.

Mir ists auch egal. Und Peter hat ja nur geschrieben, daß er nicht 
gerne lötet.

Ich habe bei mir das 2. SOJ-RAM übrigens auch Huckepack auf das erste 
gelötet. Wobei es jetzt eigentlich kein SO J mehr ist. ;-)

Schönes Wochenende
Leo
(Nach Diktat verreist)

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier nun die SOJ26-24 Variante, also CP/M mit 4 MB. D0-D7 nun korrekt, 
Pullup und Pulldown an MMC, LED an CS noch nicht (kommt noch) und I2C 
wartet noch auf Ideen.

von Peter Sieg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Joe G. Können gerne SOJ nehmen.. kriege ich hin.. ist aber für sonst 
nur DIL Verbauer eine kleine Herausforderung ;-) Deshalb: Einfach auf 
eine Version einigen..und fertig. Keep it simple..
(Ich habe eine ganze Schachtel voll alter Ramriegel.. muß selbst erstmal 
schauen, was ich da noch so finde..)

Eine Idee hätte ich allerdings noch:
Quarz+2xC ersetzen durch Quarzoszillator.. es ist so gut wie unmöglich 
ab >25MHz noch Grundtonquarze zu bekommen (für 30MHz ist mir das 
allerdings noch gelungen..).. Aber Quarzoszi's für 32/36/40MHz ist kein 
Problem..

--- zum softuart und 8-bit dram access ---
  ; - Soft UART TX (OC1A/OCR1A).
  ; - Soft UART RX (ICP1/ICR1).
Das sin die beiden Uart Pins?

Ansonsten sehe ich nur D0-D3 definiert..? Ich hatte D4-D7 erwarten..?
Normalerweise dachte ich 2tes Dram Huckepack aufzulöten - alle Pins - 
bis
auf D0-D3 und diese 4 Pins ergeben dann das 2te Nibble..

Peter

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Quarz+2xC ersetzen durch Quarzoszillator..

Ja, ist sicher besser. Schon in Hinblick auf mögliche Erweiterungen in 
Richtung VGA (25.179 MHz) ;-)

Peter Sieg schrieb:
> Ansonsten sehe ich nur D0-D3 definiert..?

Schau mal im letzen Schaltplan, den Tag davor hatte ich geträumt. Die 
Soft UART Pins sind so wie in Leo C. Quelle.

C4 oder C5 könnte man auch als /CS für ein weiteres SPI-Gerät nutzen. 
Ich habe hier noch ein Vinculum Vdrive rumliegen. Damit hat Leo C. sein 
SSD im mehrstelligen GB-Bereich oder was ein USB Stick so hergibt. FAT 
ist auch schon dabei, außerdem könnte man CP/M Programme über USB-Stick 
austauschen.
Joe

von Joerg W. (joergwolfram)


Bewertung
0 lesenswert
nicht lesenswert
@ Peter Sieg

ich habe damit angefangen und es funktioniert auch recht gut, allerdings 
mehr als die Testprogramme hier im Thread habe ich nicht laufen lassen. 
Aus Mangel an Interesse sowohl bei mir als auch im ChipBasic Thread habe 
ich das Ganze aber erstmal wieder auf Eis gelegt. Beim nächsten Release 
wird der 8080-Emulator mit dabei sein, mehr aber wahrscheinlich nicht.

Jörg

von Peter S. (petersieg)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo. Hier noch ein weiteres diskimage (um die Partitionen zu füllen 
;-).
Es enthält den BDS C-Compiler und ein paar C-Sourcen von Spielen.
Übersetzung mit cc <datei.c> und dann clink <datei>.
Belegt nur ca. 100kb auf dem 243kb Image.
ED als Zeileneditor ist ebenfalls enthalten. Leider läuft der 
Fullscreen-Editor VDE nicht..? Falls jemand noch einen kleinen, 
einfachen Fullschreeneditor für CP/M-80 hat..
---
MicroVGA läuft auch am avr cp/m. 115200 baud schafft es aber nicht ohne 
HW Handschake.. läuft jetzt mit 38400 baud.. stelle noch zwei Bilder 
ein..
Der 3,3V Ausgang des MicroVGA ist hier wirklich sehr praktisch!

Peter

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> MicroVGA läuft auch am avr cp/m.

Hat deine einstabiles Bild? Bei mir sehen die Buchstaben arg zerfranst 
aus. Hast du mal die Pegel der seriellen Schnittstelle gemessen, 5V oder 
3.3V ? Auf der Leiterplatte ist ja nicht so richtig zu erkennen wo die 
3.3V Leitung bleibt und die 5V Leitung ist äußerst dünn ausgeführt.

Ich würde das neue Layout so ausführen, dass die MicroVGA Platine direkt 
aufgeschraubt und verbunen werden kann. Für die 5V gibt es dann eine 
übliche Klinkenbuchse.

Joe

von Peter S. (petersieg)


Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> Hat deine einstabiles Bild? Bei mir sehen die Buchstaben arg zerfranst
> aus.

Das Bild ist stabil. Aber die Buchstaben sehen hier auf dem 22" TFT auch 
nicht schön aus :-( Habe sowas aber schon bei einigen Sachen gesehen, wo 
800x600/640x480/80x25 Text (also geringe Auflösungen) versucht wird auf 
solche großen Bildschirme 'hochzurechnen'..

Die Anschlüsse so zu legen, das MicroVGA direkt passt ist eine gute 
Idee!

Ist wie gesagt eine doch noch recht preiswerte Möglichkeit einen 
Stand-Alone CP/M Rechner zu basteln.. Ca. 30€ sind aus meiner Sicht ok. 
Muß noch mal sehen, das auch Programme mit VT100/Ansi Sequenzen auch gut 
laufen..

Eine Alternative könnte PropTerm sein.. Habe dafür aber noch kein 
Fertigmodul/Bausatz/Platinenlayout/etc. gefunden..

Was ich z.Z suche ist ein einfacher Fullscreen Ascii/Text-Editor..

Wäre auch schön, wenn der einer oder andere auch mal ein diskimage 
zusammen stellen würde mit z.B anderen Programmiersprachen oder 
Anwendungen etc.

Peter

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Schaltug / Layout

Da der Wunsch nach Taktfrequenzen über 20 Mhz besteht und Quarze in 
diesem Bereich dünn werden, ist ja der Einsatz eines Quarzoszillators 
geplant. Nun laufen dieses (DIL Variante) wiederum nur mit 5V und nicht 
mit 3.3V. Was haltet ihr von dieser Variante:

- AVR und RAM laufen auf 5V (kann damit höher übertaktet werden)
- MMC wird über 74CHC08 auf 3.3V betrieben.
- als Spannungsregler kommt wieder der interne Regler des FTDI zum 
Einsatz
- alle weiteren Busgeräte I2C, SPI laufen auf 5V oder SPI auf 3.3V

Das Konzept erfordert zusätzlich genau einen 74VHC08.

Joe

von Peter S. (petersieg)


Bewertung
0 lesenswert
nicht lesenswert
Hmm.. SMD Oszi gibt z.B bei reichelt zw. 25-50MHz (XO32 40,00000). Die 
laufen mit 3,3V...

Ich würde ungern das Layout/die nötigen Bauteile weiter 'aufblähen' ;-)

BTW: Warum Man(n) auch unbedingt 2 x Dram's a 4-bit nehmen muß und nicht 
1 x Sram (628128-70) muß Man(n) auch nicht wirklich verstehen.. ;-)
(Nein, kein ez80 etc. ;-)

BTW: Hat jemand eine Lösung, wie ich cmd.exe unter XP so laufen lassen 
kann, das ich mit dem AltairSimh Emulator Programme testen kann, die 
VT52/VT100/Ansi Escape-Sequenzen nutzen..? Kann gerne auch ein anderer 
Shell-Ersatz etc. sein.. evtl. könnte ja telnetd + telnet hier gehen.. 
ist aber ein wenig oversized an Aufwand - oder?

Peter

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Warum Man(n) auch unbedingt 2 x Dram's a 4-bit nehmen muß und nicht
> 1 x Sram (628128-70) muß Man(n) auch nicht wirklich verstehen.. ;-)

Wegen der fehlenden Pins - A0 bis A16.

Alles mit 5V laufen zu lassen hatte noch einen Grund. Meine 
VGA-Testschaltung läuft auch mit 25 MHz, das Schieberegister und die 
Leitungstreiber sowie die Tastaturschnittstelle mit 5V. Diese IC's habe 
ich nicht als VHC-Type gefunden. Diese Schaltung würde ich gleich mit 
anstückeln. So kann sie für weitere Experimente benutz werden oder bei 
Bedarf durch die MicroVGA überbaut werden. Der beansprüchte Platz und 
die Pinbelegung ist gleich.

Joe

von Dagobert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Zum Terminal:

Mein TKTerm (Download auf www.DieProjektseite.de) beherscht die 
Ansi-Sequenzen, welche auch µVGA kann. In Kürze gibt es eine weitere 
Version des Programms wo dann auch die Baudratenauswahl funktioniert. 
Wer die neue Version haben möchte, kann mich anschreiben (über die 
Projektseite). Dem sende ich dann die aktuelle Version zu.

von Peter S. (petersieg)


Bewertung
0 lesenswert
nicht lesenswert
@Dagobert: ???! Ich suche ein Programm das solche ESC Sequenzen in einem 
Win32 CMD(Command) Fenster interpretiert. Für serielle IF's gibts 
viele..

@Joe: VGA-Testschaltung..? Es könnte Sinn machen, hier ein VGA Terminal 
und PS/2 Tastatur-IF mit aufzunehmen.. allerdings eine fertige 
Schaltung+SW dazu (80x25 Zeichen mit ESC IP) habe ich - außer PropTerm - 
noch nicht gefunden..

Peter

von Peter S. (petersieg)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier die Bilder von AVR CP/M + MicroVGA.

---

@Joe: Was die HW angeht, bin ich fast für alles offen, wenn es dem CP/M 
Gedanken folgt, so einfach wie möglich - nur nicht einfacher!
Mit dem bisher erreichten kann man schon sehr zufrieden sein!
2 x Drams mit mehr Bytes bringt:
a. Faktor 2 in der Geschwindigkeit
b. Mögliche Erweiterungen in Richtung Ramdisk etc.
=> Ergo. Sollte in einer nächste Version mit aufgenommen werden.
Quarzoszillator ermöglicht übertakten bis 36/40/?? MHz, was wiederum
mehr Geschwindigkeit bringt und nicht viel kostet und die HW auch nicht
komplizierter macht.
=> Ergo. Reinnehmen.
I2C eröffnet ebenfalls noch ungeahnte Möglichkeiten und kostet=nichts.
=> Ergo. Reinnehmen.
Das mit dem Vinculum USB Drive dürfte auch sehr interessant sein..
Eine einfache Möglichkeit Dateien zw. CP/M und Host-Welt auszutauschen
wäre schon schön..

Alles andere, wenn es denn das System sinnvoll erweitert bzw. ergänzt..
warum nicht.. ein Selbstbauterminal (VGA-Out+PS/2 Tast.-In) sollte
allerdings ersteinmal als LR/Steckbrettaufbau funktionieren..

Just my 2 cents.

Peter

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier der Vorschlag mit folgenden Änderungen:

- 4MB RAM
- LED an CS MMC
- 3.3V an MMC, nicht mehr versehentlich auf 5V steckbar
- 3.3V wahlweise über FTDI oder MicroVGA
- AVR und RAM kann wahlweise mit 3.3V oder 5V betrieben werden (hat 
keinen Einfluß auf Spannung der MMC)
- Takt über FTDI oder Quarzoszillator
- mögliche Steckvarianten der V24 sind:
  USB - CP/M
  CP/M - VGA
  USB - VGA

noch offen:
- Vinculum USB Drive
- I2C
Es geht nur eines von beiden, da bei einem weiteren SPI Device ein 
zusätzliches CS benötig wird. Wir sollten uns auf eine Variante 
festlegen oder es als Lochraster auslegen.

Peter Sieg schrieb:
> sollte
> allerdings ersteinmal als LR/Steckbrettaufbau funktionieren..
Da funktioniert es Lochrastermäßig ;-) H-Sync und V-Sync kommen exakt, 
Pixeltakt und Zeichen auch. Aber durch Steckbrettaufbau mit viiiiel 
Jitter. Schaltugsvorschlag dazu folgt noch.
Joe

von Peter S. (petersieg)


Bewertung
0 lesenswert
nicht lesenswert
Joe G. schrieb:
> noch offen:
> - Vinculum USB Drive
> - I2C
> Es geht nur eines von beiden, da bei einem weiteren SPI Device ein
> zusätzliches CS benötig wird.

Hmm. VDRIVE2/VDIP1+2 können auch per UART gesteuert werden..
Bräuchte eine 2te serielle Schnittstelle (9600 8N1) und ein 
entsprechendes Terminalprogramm unter CP/M, was über diese Schnittstelle 
mit dem V* Device spricht und mit den vorhandenen Kommandos Dateien zw. 
CP/M und V* Device liest und schreibt..

Peter

von Joe G. (feinmechaniker) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
na dann will ich auch mal...
hier mein Aufbau...
Joe

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> VDRIVE2/VDIP1+2 können auch per UART gesteuert werden..
> Bräuchte eine 2te serielle Schnittstelle (9600 8N1) und ein
> entsprechendes Terminalprogramm unter CP/M

Das wird aber arg langsam...
Mir scheint SPI die bessere Lösung zumal man ja dem BIOS beibrigen kann, 
dass genau dieses SPI Gerät die COM1 oder COM2, ... ist. Dann sollte 
auch ein Terminal gehen.

von Leo C. (rapid)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> BTW: Warum Man(n) auch unbedingt 2 x Dram's a 4-bit nehmen muß und nicht
> 1 x Sram (628128-70) muß Man(n) auch nicht wirklich verstehen.. ;-)

Für mich ist das Ganze ein Bastelkistenprojekt. D.h. es wird nur aus 
Teilen zusammengebaut, die in der Bastel-/Reste-/Ramschkiste vorhanden 
sind. D-Rams sind da reichlich drin. Große statische Rams eher nicht.
(ATmegas habe ich allerdings auch nicht im Überfluß, und meinem 
GPS-Logger habe ich schon den 328P geklaut. ;)

Peter Sieg schrieb:
> Hier die Bilder von AVR CP/M + MicroVGA.

Am Besten gefallen mir die geschraubten Nagelschellen. ;-)

Joe G. schrieb:
> noch offen:
> - Vinculum USB Drive

Kommt für mich nicht in Frage. (siehe oben)

> - I2C
> Es geht nur eines von beiden, da bei einem weiteren SPI Device ein
> zusätzliches CS benötig wird. Wir sollten uns auf eine Variante
> festlegen oder es als Lochraster auslegen.

Ich fände ein paar Inputs ganz brauchbar. ZB. vom SD-Kartensockel 
Card-Detect und evtl Write-Protect. Ferner Z80 Interupt/Reset. Wenn die 
2 Pins nicht reichen: Schieberegister.


Im Anhang mal ein Bild vom Huckepack-Ram. (ex SOJ:)

von Leo C. (rapid)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
In meinem SVN Repo gibts ein paar Updates. Im trunk ("alte" Hardware) 
eigentlich nur ein paar Bugfixes. Bei einer partitionierten SD-Karte 
wird jetzt sichergestellt, daß nicht außerhalb der CP/M-Partitionen 
gelesen, und vor allem geschrieben wird. Wer also seine 
CP/M-Partition(en) kleiner als das darin befindliche CP/M-Dateisystem 
definiert hat, und noch andere, wichtige Daten auf der Karte hat, sollte 
unbedingt updaten.

Im softuart-Zweig (8-Bit DRAM) das Gleiche. Plus RAM-Disk (Laufwerk I:).
Die RAM-Disk ist im Moment nur 64KB groß, damit sie auch bei den 
kleinsten RAM-Chips noch funktioniert. Davon gehen dann noch 8KB für 2 
Systemspuren ab.
Beim Kaltstart wird das CP/M von A: auf die RAM-Disk kopiert und beim 
Warmstart von dort neu geladen. Sinn des ganzen sollte sein, daß man 
nach dem booten die SD-Karte ziehen kann, und ohne sie weiterarbeiten 
kann.

Leider macht uns CP/M hier einen Strich durch die Rechnung: Beim 
Warmstart wird grundsätzlich auf A: zugegriffen, auch wenn der Benutzer 
auf ein anderes Laufwerk umgeschaltet hat.

Abhilfe:
1. BDOS patchen. Andere (z.B. simh) machen das auch so.
2. Die RAM-Disk als Laufwerk A: verdrahten.
3. Alternatives CP/M (BDOS) verwenden? (Bekannte, gute Alternativen
   setzen Z80 voraus)

Anderes, damit im Zusammenhang stehendes Problem:
Wenn man die SD-Karte zieht und wieder einsteckt, wird beim nächsten 
Zugriff das System komplett neu gestartet. Das ist erst mal leicht zu 
korrigieren, in dem z.B. bei einem Warmstart (^C) die Karte neu 
initialisiert wird. Allerdings muß man dann auch die Partitionierung neu 
einlesen. Wenn bei jedem Warmstart die Liste der gefundenen Partitionen 
erscheint, nervt das aber...

Für Vorschläge, wie man das System an dieser Ecke rund macht, bin ich 
dankbar. Hat überhaupt schon jemand die 8-Bit-Ram Variante nachgebaut, 
und kann damit die RAM-Disk mal testen? Ich weiß noch nicht, ob ich die 
in die 4-Bit-Ram Variante überhaupt noch einbauen soll.

Beide neuen Versionen laufen nur mit neuem BIOS, und das neue BIOS nur 
mit neuem IPL. Beides ist auch im SVN. Ich habe aber auch mal ein 
fertigs System hier angehängt.

von Peter S. (petersieg)


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Hat überhaupt schon jemand die 8-Bit-Ram Variante nachgebaut,
> und kann damit die RAM-Disk mal testen? Ich weiß noch nicht, ob ich die
> in die 4-Bit-Ram Variante überhaupt noch einbauen soll.

Hi Leo C.
Ich bin noch nicht dazu gekommen, die 8-bit Variante nachzubauen. Ich 
plane dazu meine LR Version umzubauen. Könntest du bitte nochmal 
aufzeigen, wie genau ich was verdrahten muß? Ich gehe im Moment davon 
aus:
1. 2ten Dram Chip 1:1 mit dem ersten verbinden (Huckepack) - bis auf 
D0-D3!
2. Dram 1ter Chip verbinden:
D0 - 2 - PD0
D1 - 3 - PD1
D2 - 4 - PD2
D3 - 5 - PD3
3. Dram 2ter Chip verbinden:
D0 - 6 - PD4
D1 - 11 - PD5
D2 - 12 - PD6
D3 - 13 - PD7
4. Uart RX liegt dann an AVR Pin 14 = ICP1/ICR1
5. Uart Tx liegt dann an AVR Pin 15 = OC1A/OCR1A

Ups.. ich sehe gerade, das ist eine komplette Umverdrahtung!! Da kann 
ich wahrscheinlich schneller einen kompletten Neuaufbau auf LR machen.. 
;-) Meine Platinen werde ich jedenfalls nicht so vergewaltigen.. Ich 
glaube da brauchen wir die nächste Platinenversion doch eher als ich 
gedacht hatte.. ;-)

> LW A: in Ramdisk umkopieren..
Das würde ich so nicht machen.. Evtl. hat man z.B seinen C Compiler auf 
C: und möchte eher diesen in der Ramdisk haben (wozu allerdings 64kb zu 
wenig wäre..).. eher sowas wie eine autoexec.bat ausführen, wo man dann 
selbst definieren kann, was evtl. wohin kopiert werden soll..

>Wenn man die SD-Karte zieht und wieder einsteckt, wird beim nächsten
>Zugriff das System komplett neu gestartet. Das ist erst mal leicht zu
>korrigieren, in dem z.B. bei einem Warmstart (^C) die Karte neu
>initialisiert wird. Allerdings muß man dann auch die Partitionierung neu
>einlesen. Wenn bei jedem Warmstart die Liste der gefundenen Partitionen
>erscheint, nervt das aber...
Ach.. macht doch nichts.. oder wenn gefundene Part. den vorher 
gefundenen entsprechen.. Meldungen unterdrücken.. ;-)

>Ich weiß noch nicht, ob ich die
>in die 4-Bit-Ram Variante überhaupt noch einbauen soll.
Da dann nur 64k zur Verfügung wären.. eher nein.. oder kann man das für 
temp. Dateien eines C Compilers nutzen..?

Peter

von Joe G. (feinmechaniker) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:
> Ich fände ein paar Inputs ganz brauchbar. ZB. vom SD-Kartensockel
> Card-Detect und evtl Write-Protect. Ferner Z80 Interupt/Reset. Wenn die
> 2 Pins nicht reichen: Schieberegister.

- PCF8574 an I2C? Damit gibt es nochmal 8 Bit.

> Im Anhang mal ein Bild vom Huckepack-Ram. (ex SOJ:)

Deshalb brauche ich eine Platine, solche Lötarbeiten werden mit 
zunehmenden Alter unmöglich.

> Abhilfe:
> 3. Alternatives CP/M (BDOS) verwenden? (Bekannte, gute Alternativen
>    setzen Z80 voraus)

Ich denke diese Variante ist die flexibleste Lösung.

> Hat überhaupt schon jemand die 8-Bit-Ram Variante nachgebaut,
> und kann damit die RAM-Disk mal testen? Ich weiß noch nicht, ob ich die
> in die 4-Bit-Ram Variante überhaupt noch einbauen soll.

Ich noch nicht, werde ich auch ohne neue Platine nicht 
(Altersaugenpulver ;-)). Von mir aus reicht die RAM-Disk in der 8-Bit 
Variante.

@alle
Gibt es denn außer bein Leo C. Peter und mir noch weitere lauffähige 
Systeme? Wenn nicht, können wir irgendwie helfen?

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Könntest du bitte nochmal
> aufzeigen, wie genau ich was verdrahten muß? Ich gehe im Moment davon
> aus:

Du kannst Den neuen Schaltplan von Joe nehmen.

> Ups.. ich sehe gerade, das ist eine komplette Umverdrahtung!!

Überraschung ;-)

> Da kann
> ich wahrscheinlich schneller einen kompletten Neuaufbau auf LR machen..
> ;-) Meine Platinen werde ich jedenfalls nicht so vergewaltigen.. Ich
> glaube da brauchen wir die nächste Platinenversion doch eher als ich
> gedacht hatte.. ;-)

Ich hatte mich eh schon gewundert, als Du mal vom Platinenumverdrahten 
geschrieben hattest.

>> Wenn bei jedem Warmstart die Liste der gefundenen Partitionen
>> erscheint, nervt das aber...
> Ach.. macht doch nichts..

Doch, die Warmstarts werden ja auch bei (fast) jeder Beendigung eines 
Programms ausgeführt. Bei Batchdateien nach jeder Zeile.

> oder wenn gefundene Part. den vorher
> gefundenen entsprechen.. Meldungen unterdrücken.. ;-)

Oder umgekehrt: Nur ausgeben, wenn Partitionen geändert. ;)
So werde ichs machen. Kartenwechsel ohne Kaltstart muß einfach möglich 
sein, da die "usability" sonst in den Keller sinkt.

>>Ich weiß noch nicht, ob ich die
>>in die 4-Bit-Ram Variante überhaupt noch einbauen soll.
> Da dann nur 64k zur Verfügung wären.. eher nein.. oder kann man das für
> temp. Dateien eines C Compilers nutzen..?

Kommt wahrscheinlich auf die Größe Deiner C-Programme an. :)
Ansonsten ist das natürlich der Hauptzweck einer RAM-Disk.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.