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.
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
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. :-(
@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
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:
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.
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
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...
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.
>>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.htmhttp://tinyvga.com/avr-sdram-vga
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?
@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
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.
@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.
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.
@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
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.
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
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.
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?
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. :-(
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?
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)?
> 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
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
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
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
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
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
@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
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
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.
@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
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 ;-)
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
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 :-)
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
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
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.
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
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!
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.
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
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
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 ;-)
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:
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:> 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.
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:
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.
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.
@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
@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/downloadPeter 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.
@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
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.
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
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.
@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
@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.
@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
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.
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.
@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
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.
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
@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:
1
Datentr ### Status Größe Frei Dyn GPT
2
-------- ---------- ------- ------- --- ---
3
0 Online 149 GB 0 B
4
1 Online 244 MB 23 MB
5
2 Kein Mediu 0 B 0 B
6
3 Kein Mediu 0 B 0 B
7
4 Kein Mediu 0 B 0 B
8
5 Kein Mediu 0 B 0 B
9
6 Kein Mediu 0 B 0 B
10
7 Kein Mediu 0 B 0 B
11
8 Kein Mediu 0 B 0 B
12
13
DISKPART> select disk 1
14
15
Datenträger 1 ist jetzt der gewählte Datenträger.
16
17
DISKPART> list part
18
19
Partition ### Typ Größe Offset
20
------------- ---------------- ------- -------
21
Partition 1 Primär 196 MB 32 KB
22
Partition 0 Primär 8033 KB 196 MB
23
Partition 0 Primär 8033 KB 204 MB
24
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
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
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.
1
> Partition ### Typ Größe Offset
2
> ------------- ---------------- ------- -------
3
> Partition 1 Primär 196 MB 32 KB
4
> Partition 0 Primär 8033 KB 196 MB
5
> Partition 0 Primär 8033 KB 204 MB
6
> 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?
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.
@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
Leo C. schrieb:> Wie greift man denn mit dd auf Geräte, bzw Partitionen, zu? Die> interessanteste Information hast Du weggelassen.
1
C:\cpmtools>dd2 --list
2
rawwrite dd for windows version 0.5.
3
Written by John Newbigin <jn@it.swin.edu.au>
4
This program is covered by the GPL. See copying.txt for details
5
Win32 Available Volume Information
6
...
7
NT Block Device Objects
8
\\?\Device\CdRom0
9
size is 2147483647 bytes
10
\\?\Device\Harddisk0\Partition0
11
link to \\?\Device\Harddisk0\DR0
12
Fixed hard disk media. Block size = 512
13
size is 160040803840 bytes
14
\\?\Device\Harddisk0\Partition1
15
link to \\?\Device\HarddiskVolume1
16
\\?\Device\Harddisk0\Partition2
17
link to \\?\Device\HarddiskVolume2
18
Fixed hard disk media. Block size = 512
19
size is 9663676416 bytes
20
\\?\Device\Harddisk1\Partition0
21
link to \\?\Device\Harddisk1\DR1
22
Removable media other than floppy. Block size = 512
23
size is 255852544 bytes
24
\\?\Device\Harddisk1\Partition1
25
link to \\?\Device\HarddiskVolume3
26
Removable media other than floppy. Block size = 512
27
size is 205599744 bytes
28
\\?\Device\Harddisk2\Partition0
29
link to \\?\Device\Harddisk2\DR2
30
\\?\Device\Harddisk2\Partition1
31
...
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:
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:
1
leo@cb:~$ cpmls -d -f avrcpm /dev/sdf3
2
ASM COM : DDT COM : DUMP COM : ED COM
3
INSTALL COM : LOAD COM : PIP COM : STAT COM
4
SUBMIT COM : T BIN : XSUB COM : MAILMRGE OVR
5
MERGPRIN OVR : WIMSGS OVR : WS COM : WSMSGS OVR
6
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.
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
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
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. :)
@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
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 ???
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.htmBeitrag "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
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.
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
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 ;)
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
1
.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:
1
.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.
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:
"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.
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
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. ;-)
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... :-)
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.
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.
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.
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.
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.
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.
@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
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.
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)
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.
@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
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
@ 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
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
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
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
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
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
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
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.
@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
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
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
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
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.
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:)
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.
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
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?
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.
Thread beobachten
Seitenaufteilung abschalten