CP/M auf ATmega88

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.

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.

1

do_fetch_af:

2

  mov opl,z_flags

3

  mov oph,z_a

4

  rcall do_op_calcparity

5

  andi opl,~(1<<ZFL_P)

6

  sbrs temp2,0

7

   ori opl,(1<<ZFL_P)

8

  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.

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

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

@Martin
@alle

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

Joe

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.

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:

1

do_op_inc:

2

  andi  z_flags, (1<<ZFL_C)       ; bis auf Carry alles auf 0

3

  ldi   temp, 1

4

  add   opl, temp

5

  in    temp, sreg

6

  mov   parityb, opl

7

  bst   temp, AVR_Z               ; Zero

8

  bld   z_flags, ZFL_Z

9

  sbrc  opl, 7                    ; Sign

10

  ori   z_flags, (1<<ZFL_S)       

11

  bst   temp, AVR_H               ; Half Sign

12

  bld   z_flags, ZFL_H

13

  bst   temp, AVR_C               ; Overflow

14

  bld   z_flags, ZFL_P

15

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

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

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.

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.

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:

1

test:       sub    A               ;setzt A auf 0 (kein Overflow)

2

            jp     pe,code_8080    ;wenn A=0 dann ist Parity even

3

code_z80:   ....

4

5

6

code_8080:  ....

Jörg

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.

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.

So sieht sie aus, die erste bestückte Platine.

Joe

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

Juchhu,
DDT kann jetzt Programme tracen.

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

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.

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.

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.

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

1

  in  temp,PINC        ; 1. Nibble einlesen (untere Hälfte von PC)

2

  andi temp,0x0f       ; obere Hälfte wegmaskieren

3

  swap temp

4

5

        ;Adressen umschalten ...

6

7

  in  temp2,PINC       ; 2. Nibble einlesen

8

  andi temp2,0x0f

9

  or  temp,temp2       ; Beide Hälften zusammen

Zusammen 6 Befehle, 6 Takte.
Im Originalprgramm gibt es ein Unterprogramm, das zwei mal aufgerufen
wird:

1

;...

2

  rcall dram_getnibble  

3

  swap temp

4

5

        ;Adressen umschalten ...

6

7

  rcall dram_getnibble  

8

9

        ; ...

10

;...

11

12

dram_getnibble:

13

  andi temp,0xf0

14

  sbic pinc,ram_d0

15

   ori temp,0x1

16

  sbic pinc,ram_d1

17

   ori temp,0x2

18

  sbic pinc,ram_d2

19

   ori temp,0x4

20

  sbic pinc,ram_d3

21

   ori temp,0x8

22

  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.

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.

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.

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.

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.

Hier mal ein kleiner Test.

Im Debugger habe ich folgende kleine Schleife laufen lassen:

1

MVI A,01        ;

2

OUT 40     ;Start Timer         Takte

3

LXI H,0000      ;               10

4

DCX H           ;               6  -\

5

MOV A,H         ;               4   |

6

ORA L           ;               4   |

7

PUSH PSW        ;               10  | 44 * 65536  =  2883584

8

POP PSW         ;               10  |

9

JNZ 0107        ;               10 -/

10

MVI A,02        ;               7

11

OUT 40     ;Stop Timer          11

12

NOP             ;               gesamt Anzahl Takte: 2883612

Und das hier kam raus:

1

--------------------------------------------------------------------

2

AVR Atmega mit |                12,288 Mhz              |   20 MHz  

3

---------------+------------+----------------+----------+-----------

4

               | Laufzeit        Laufzeit        Z80         Z80

5

               |  Gesamt        pro Z80 Takt    Speed       Speed

6

---------------+-----------------------------------------------------

7

Orig. DRAM R/W | 17,187 s        5,960 µs      168 KHz     273 KHz

8

Neue  DRAM R/W |  9,806 s        3,401 µs      294 KHz     478 KHz

9

---------------+-----------------------------------------------------

10

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

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

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?

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

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

... hatte ich schon geändert. Muß noch was anderes faul sein.

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

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.

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

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

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.

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.

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

Leo C. schrieb:

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

einen MT4C4256-80

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

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.

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]

1

                 ; - Setup Ports

2

...

3

000045 e300        ldi temp,PC_OUTPUT_MASK

4

000046 b907        out DDRC,temp

5

6

...

7

8

                 dram_write:

9

0002f6 94f8        cli

10

...

11

0002f7 b117        in temp2,DDRC               ;DRAM data ports as outputs

12

0002f8 601f        ori temp2,RAM_DQ_MASK

13

0002f9 b917        out DDRC,temp2

14

...

15

000340 9a44        sbi PORTC,ram_w

16

...

17

000342 b107        in temp,DDRC

18

000343 7f00        andi temp,~RAM_DQ_MASK

19

000344 b907        out DDRC,temp

20

000345 b108        in temp,PORTC

21

000346 7f00        andi temp,~RAM_DQ_MASK

22

000347 b908        out PORTC,temp

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

Was die Leute alles so nachbauen.... :-)

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

@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

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.

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

Peter

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:

1

100 REM Timertest

2

110 TCTRPORT = &H40

3

120 REM Start timer 

4

130 OUT TCTRPORT,1

5

140 REM Do something

6

150 FOR I=0 TO 200

7

160 IF I MOD 10 = 0 THEN PRINT ".";

8

170 NEXT

9

180 REM Stop timer, print result

10

190 OUT TCTRPORT,15

11

200 PRINT

12

210 PRINT "Done."

13

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.

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

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

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.

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.

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

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

DEC HL setzt soviel ich weiss keine Flags. Also müsste man wie im ersten 
Testbeispiel ein

1

MOV A,H 

2

ORA L

nach das DEC HL setzen.

Jörg

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.

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.

@  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

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.

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:

1

   ------------------------------------------------------------------------

2

   |         Port D        |         Port B        |         Port C       |

3

   +-----------------------+-----------------------+----------------------+

4

   | 7 | 6 | 5 | 4 | 3 | 2 | 5 | 4 | 3 | 2 | 1 | 0 | 5 | 4 | 3 | 2 | 1 | 0|

5

   |            CS         |SCK DO  DI             |                      |

6

bb |A7  A6  A5      A8  OE |RAS A0  A1  A2  A3  A4 |CAS  W  D3  D2  D1  D0|

7

   +-----------------------+-----------------------+----------------------+

8

   |                    CS |SCK DO  DI             |        D3  D2  D1  D0|

9

exp|A7  A6                 |A9  A8  WE  OE  CAS RAS|A5  A4  A3  A2  A1  A0|

10

   ------------------------------------------------------------------------

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

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

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.

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

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

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

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

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.

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.

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.

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

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.

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:

1

dram_read:

2

  cli

3

  DRAM_SETADDR adrh, ~0,(1<<ram_ras), ~(1<<ram_a8), (1<<ram_oe)

4

  cbi P_RAS,ram_ras

5

  DRAM_SETADDR adrl, ~(1<<ram_ras),0, ~((1<<ram_oe)), (1<<ram_a8)

6

  cbi P_CAS,ram_cas

7

  cbi P_A8,ram_a8    ; 2 Takte

8

  nop                ; 1 Takt

9

  in  temp,P_DQ-2    ; PIN

10

  sbi P_CAS,ram_cas

11

12

  cbi P_CAS,ram_cas

13

  andi temp,0x0f     ; 1 Takt

14

  swap temp          ; 1 Takt

15

  nop                ; 1 Takt

16

  in  temp2,P_DQ-2   ; PIN

17

  andi temp2,0x0f

18

  or  temp,temp2

19

20

  sbi P_OE,ram_oe

21

  sbi P_CAS,ram_cas

22

  sbi P_RAS,ram_ras

23

  sei

24

  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.

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.

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

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

1

start:

2

  ldi temp,low(RAMEND)  ; top of memory

3

  out SPL,temp    ; init stack pointer

4

  ldi temp,high(RAMEND)  ; top of memory

5

  out SPH,temp    ; init stack pointer

6

7

  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.

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.

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

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.

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

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

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.

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

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? ;-)

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?

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

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.

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

1

CPM on an AVR, v1.0

2

Initing mmc...

3

Testing RAM: fill...wait...reread...

4

5

Ok, CPU is live!

6

ipl

7

8

62k cp/m vers 2.2

9

10

A>dir

11

A: ASM      COM : DDT      COM : DUMP     COM : ED       COM

12

A: T        COM : TLOOP    COM : LOAD     COM : MBASIC   COM

13

A: 23       BAS : BAGELS   BAS : CHECKERS BAS : STARTREK BAS

14

A: TREKINST BAS : MASTRMND BAS : WEEKDAY  BAS : PIP      COM

15

A: STAT     COM : SUBMIT   COM : XSUB     COM : ZORK1    COM

16

A: ZORK1    DAT

17

A>t b

18

19

Timer running. Elapsed: 007.573s.

20

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

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.

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.

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

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.

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.

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.

Ich hab es gerade mal ausprobiert. WS 3.0 läuft siehe Bild.

Zum Testen habe ich eine etwas chaotische Partitionierung erzeugt:

1

leo@cb:~$ /sbin/fdisk -luc /dev/sdb

2

3

Disk /dev/sdb: 1009 MB, 1009254400 bytes

4

32 heads, 61 sectors/track, 1009 cylinders, total 1971200 sectors

5

Units = sectors of 1 * 512 = 512 bytes

6

Sector size (logical/physical): 512 bytes / 512 bytes

7

I/O size (minimum/optimal): 512 bytes / 512 bytes

8

Disk identifier: 0x0001fc66

9

10

   Device Boot      Start         End      Blocks   Id  System

11

/dev/sdb1            8192     1890303      941056    6  FAT16

12

/dev/sdb2         1890304     1906687        8192   52  CP/M

13

/dev/sdb3            2048        8191        3072   52  CP/M

14

15

Partition table entries are not in disk order

16

leo@cb:~$

Die erste CP/M-Partition (A:) liegt also ganz hinten auf der SD-Karte.

Und das kommt raus:

1

A>CPM on an AVR, v1.0

2

Testing RAM: fill...wait...reread...

3

Initing mmc...

4

CP/M partition at: 1890304, size: 8192KB.

5

CP/M partition at: 2048, size: 3072KB.

6

7

Ok, CPU is live!

8

ipl

9

10

62k cp/m vers 2.2

11

12

A>stat a:dsk:

13

14

    A: Drive Characteristics

15

 1944: 128 Byte Record Capacity

16

  243: Kilobyte Drive  Capacity

17

   64: 32  Byte Directory Entries

18

   64: Checked  Directory Entries

19

  128: Records/ Extent

20

    8: Records/ Block

21

   26: Sectors/ Track

22

    2: Reserved Tracks

23

24

A>stat b:dsk:

25

26

    B: Drive Characteristics

27

 1944: 128 Byte Record Capacity

28

  243: Kilobyte Drive  Capacity

29

   64: 32  Byte Directory Entries

30

   64: Checked  Directory Entries

31

  128: Records/ Extent

32

    8: Records/ Block

33

   26: Sectors/ Track

34

    2: Reserved Tracks

35

36

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.

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.

Soo.. klappt!

1

CPM on an AVR, v1.0

2

Testing RAM: fill...wait...reread...

3

Initing mmc...

4

CP/M partition at: 401625, size: 8032KB.

5

CP/M partition at: 417690, size: 8032KB.

6

CP/M partition at: 433755, size: 8032KB.

7

8

Ok, CPU is live!

9

ipl

10

11

62k cp/m vers 2.2

12

13

A>dir

14

15

16

A: ASM      COM : DDT      COM : DUMP     COM : ED       COM

17

A: T        COM : TLOOP    COM : LOAD     COM : MBASIC   COM

18

A: 23       BAS : BAGELS   BAS : CHECKERS BAS : STARTREK BAS

19

A: TREKINST BAS : MASTRMND BAS : WEEKDAY  BAS : PIP      COM

20

A: STAT     COM : SUBMIT   COM : XSUB     COM : ZORK1    COM

21

A: ZORK1    DAT

22

A>b:

23

24

25

B>dir

26

27

28

B: TTT2     COM : OTHELLO  COM : MMIND    COM : ED       COM

29

B: LOAD     COM : STONE    COM : PIP      COM : STAT     COM

30

B: SUBMIT   COM : XSUB     COM

31

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

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!

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

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.

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