Joe G. schrieb:> Deshalb brauche ich eine Platine, solche Lötarbeiten werden mit> zunehmenden Alter unmöglich.
Da sind wir Kurzsichtigen wohl im Vorteil. Im Nahbereich gehts bei mir
immer noch ganz gut.
> Von mir aus reicht die RAM-Disk in der 8-Bit> Variante.
Ich habe sie jetzt trotzdem mal in die alte 4-Bit Variante eingebaut.
Ist im SVN zu finden, und braucht das neue BIOS, wie oben geschrieben.
Ich hoffe, das damit ein paar mehr Leute testen können. Ich brauche
etwas Feedback in Sachen Benutzbarkeit. Außerdem sind wahrscheinlich
noch Fehler drin, die ich alleine nicht finde.
> @alle> Gibt es denn außer bein Leo C. Peter und mir noch weitere lauffähige> Systeme? Wenn nicht, können wir irgendwie helfen?
Das würde mich auch mal interessieren. Insbesondere interessiert mich,
warum jemand das Ding hier aufbaut, und was er/sie damit tun möchte.
Grundsätzlich wurde das zwar am Anfang des Threads ausgiebig diskutiert,
aber was die Leute antreibt, die jetzt tatsächlich bauen, kann ich mir
gar nicht so richtig vorstellen. ;)
Leo C. schrieb:> Ich habe sie jetzt trotzdem mal in die alte 4-Bit Variante eingebaut.> Ist im SVN zu finden, und braucht das neue BIOS, wie oben geschrieben.
Habe jetzt mal eine Platine damit ausgestattet..
1
I>a:stat
2
3
A: R/W, Space: 42k
4
B: R/W, Space: 163k
5
C: R/W, Space: 129k
6
I: R/W, Space: 55k
läuft ersteinmal soweit gut..
aber das sieht komisch aus:
1
I>a:pip ed.com=c:ed.com
2
3
I>dir
4
5
I: ED COM
6
I>ed
7
8
Bdos Err On M: Select
9
I>
Nur mal zu den Gründen, die mich antreiben:
* CP/M ist DAS Ur-Betriebssystem.
* Das mit den heutigen Mikrocontrollern verbandelt ist ansich schon
interessant
* Man ist automatisch gleichzeitig 'Retro' und modern ;-)
* Man hat eine 'arbeitsfähige' retro-Umgebung mit 2 Chips+SD Karte
* MBasic, C Compiler, Wordstar, dbase-II, etc. etc.
* Aber evtl. kann man Retro+Modern noch weiter verheiraten:
->z.B ADC über AVR nach CP/M verfügbar machen, Frequenzzähler, I2C
Bausteine
Peter
Peter Sieg schrieb:> I>a:pip ed.com=c:ed.com> Bdos Err On M: Select> I>
Danke dafür.
Ich hatte heute schon mal was ähnliches, konnte es aber nicht
reproduzieren. Bei mir war nur der Select auf J, also (genau) eins
größer als ein existierendes Laufwerk. Jetzt kann ich davon ausgehen,
daß der Buchstabe Zufall war, der eigentliche Fehler aber nicht.
Gerade nochmal propiert: Fehler versteckt sich. :-(
> Nur mal zu den Gründen, die mich antreiben:> * CP/M ist DAS Ur-Betriebssystem.
Ich bin sozusagen damit groß geworden. ;-)
Vor allem aber ist mein erster Selbstbaucomputer damit groß geworden.
> * Das mit den heutigen Mikrocontrollern verbandelt ist ansich schon> interessant> * Man ist automatisch gleichzeitig 'Retro' und modern ;-)
Genau. Besonders beim Programmieren empfinde ich das so.
> * Man hat eine 'arbeitsfähige' retro-Umgebung mit 2 Chips+SD Karte> * MBasic, C Compiler, Wordstar, dbase-II, etc. etc.
Es sind jetzt schon 3 Chips. ;) Und beim "arbeitsfähig" bin ich immer
noch ein wenig skeptisch, wg. (fehlender) Geschwindigkeit. Aber
prinzipiell ja.
> * Aber evtl. kann man Retro+Modern noch weiter verheiraten:> ->z.B ADC über AVR nach CP/M verfügbar machen, Frequenzzähler, I2C> Bausteine
Dafür fehlt mir jetzt der Sinn. Geräte mit ADC, Frequenzzähler, etc,
programmiert man besser mit was anderem, als ausgerechnet CP/M. Außerdem
sollte man dann endgültig einen größeren AVR nehmen...
So, es ist soweit...
Die Schaltung und das Layout der neuen Platine - sagen wir Version 2.0
;-)
- das Board ist etwas breiter, so das die VGA direkt angeschlossen
werden kann.
- auf den freien Pins der VGA liegen zusätzlich die 25 MHz, und SDA/SCL
zur Erweiterung für I2C
Bitte Änderungen, Vorschläge, Kritik...
Joe
@Joe. Den Quarzosi 3,3V von reichelt gibt es nur in SMD.. die DIL's sind
alle für 5V..? Soll dann die VGA+PS/2 Mimik nicht mit auf die Platine..?
(wobei das auch ok wäre.. und später macht man das zur MicroVGA
kompatibel von den Anschlüssen her gesehen).
Ich frage mich nur, wie viele sich für weitere Platinen interessieren..?
Bisher hat sich noch kein weiterer 'Nachbauer' geoutet.. ;-)
Peter
@Peter
Den Quarzoszillator als SMD hatte ich verworfen. Damit ist der schnelle
Austausch nicht mehr möglich. Die Variante im DIL Gehäuse kann sehr gut
auf eine IC Fassung gesteckt werden. Mögliche Quarzoszillatoren bei
Rei****t z.B. unter Artikel-Nr.: OSZI 25,000000. Meine Testvarianten
laufen auch sauber mit 3.3V. Damit kann also nun die ganze Schaltung
wahlweise mit 5V oder 3.3V betrieben werden, wobei die MMC natürlich nur
mit 3.3V betrieben wird. Versehentliches "falschjumpern" nicht mehr
möglich. Die Test-VGA hat die gleiche Anschlussbelegung wie die
MicroVGA, kommt also von hinten an die Platine. Die Schaltung folgt
heute noch, bin noch nicht dazu gekommen. Wir könnten auch eine Platine
machen, die an der VGA Seite getrennt werden kann.
Peter Sieg schrieb:> Ich frage mich nur, wie viele sich für weitere Platinen interessieren..?
5 Stück werden es schon mal, schätze mit der VGA kommen noch einige
Interessenten dazu.
@alle
Wer hat Interesse an einer Platine? Bitte kurze Mail an mich.
nun erst mal zum Betonieren unterwegs...
Joe
VGA/Terminal Schaltung
Hier die Schaltung zur Diskussion. Sie geht auf eine Idee von Sebastian
B. hier im Forum zurück (siehe
Beitrag "AVR VGA Terminal")
Ich habe sie auf den ATTmega88 portiert und um eine Farbdarstellung
erweitert. Wobei das Wort Farbe nicht wörtlich zu nehmen ist. Es wird
für einen Text immer nur EINE Farbe angezeigt. Der AVR hat nur exakt 8
Takte um das Zeichen in das Schieberegister zu bringen und da ist keine
Zeit mehr für die Farbdarstellung jedes einzelnen Zeichens.
Joe
Hallo Leute,
ich bin noch eine Woche im Urlaub, dann will ich bauen!!
Die Microvga hängt z.Z. am MC CPM Computer wo sie gut funktioniert!
Welche Hardware Version sollte ich bauen und welche Software passt dann
dazu?? Ich habe vor das System mit der Microvga auszurüsten und kein USB
zu seriell chip einsetzen. Also bietet die fertige Platine Vorteile?
oder ist es besser gleich auf Lochraster zu bauen?
Vorschläge sind willkommen
gruß
Hans- Werner
Hallo und Willkommen Hans- Werner.
1. Hardware
An Hardware gibt es zur Zeit die fast urspüngliche Version von
sprite_tm, für
die Joe G. eine kleine Platinenauflage gemacht hat (vergriffen). Aktuell
sind da nur 2 Leitungen vertauscht um Dramzugriff per Nibble zu
ermöglichen.
Das kann man natürlich auch auf Lochraster aufbauen.. Schaltplan etc.
hier weiter oben, im Artikel oder auf meiner Projektseite..
Z.Z diskutieren bzw. planen wir eine Version 2 der Hardware.
Erweiterungen:
2 x Dramchips mit 4MBit. Dadurch 8-bit Ramzugriff und viel Platz für
Ramdisk.
MicroVGA direkt anschließbar bzw. sogar ein Selbstbauersatz dazu.
2. Software
Z.Z ist Dank an Leo C. es fast schon schwieriger die jeweils aktuellste
Version zu flashen ;-) Es gibt auf seiner Seite im trunk Zweig die
aktuellste Version für die aktuelle 4-bit Dramversion. 8080 CPU
Emulation
scheint fehlerfrei zu sein, bis zu 4 Partitionen (Typ=52=CP/M) werden
als
LW a: - d: gemappt. Zusätzlich 64kb Ramdisk als i:
Im Zweig Softuart gibt es die Software für die neue 8-bit Dramversion,
deren Platine gerade hier diskutiert wird..(2 x Dram Chips).
@Joe G. Das sieht doch prima aus mit dem VGATerm.. wie ich sehe ist da
auch PS/2 schon dabei.. Sind schon ein paar ESC Codes dekodiert..(CLS?)?
Lt. Entwickler ist das eng.. Nun Vorteil ist zumindest schon mal, das
man ein deutsches Tast.Layout einbauen kann.. Und evtl. schaffen wir es
ja doch noch durch z.B Übertaktung (30-40MHz) zumindest CLS und
CursorPos zu
implementieren.. ich würde vorschlagen, diese VGA+PS/2 Lösung mit so auf
die Platinen zu nehmen, das sie wie die MicroVGA-Anschlüsse direkt zu
funktioniert, wer aber doch MicroVGA möchte (oder nur das..?) dies
direkt dort durchtrennen kann..
Peter
Peter Sieg schrieb:> Und evtl. schaffen wir es> ja doch noch durch z.B Übertaktung (30-40MHz) zumindest CLS und> CursorPos zu> implementieren..
Die VGA kann leider nicht beliebig übertaktet werden, da der Pixeltakt
fest steht (25 MHz) und starr mit dem AVR Takt verbunden sein muß.
Deshalb auch der eigene Quarzoszillator auf der VGA. Ideal wären
natürlich 50 MHz ;-). Da hätte man dann 8 zusätzliche Takte für den AVR.
An der Software muß natürlich gearbeitet werden, die Hardware stellt ja
nur die Experimentierbasis.
Joe
Moin moin,
bin gerade über das Projekt gestolpert.
Ich habe mal mit einem ISP8A600 angefangen.
Dann folgten 8080, Z80 und über QRL dann zwangsweise 6502er.
Wobei der Z80 meine lieblings CPU war.
Irgendwo müsste bei mir auch noch eigene CP/M Software sein.
Werde mal suchen. Hatte mal nen eigenen Compiler geschreiben.
Pascal ähnlich, UPN. Compiler erzeugte ASM-Code. Das ganze war für
Steuerungen gedacht.
Ich würde mich gern an das Projekt mit drann hängen.
Leider sind hier keine DRAMs mehr vorhanden.
Wobei wird nocht unterstützung benötigt.
EAGLE, AVRSTUDIO (GCC,ASM) und ein bischen was an Erfahrung sind
vorhanden.
Horst schrieb:> Ich würde mich gern an das Projekt mit drann hängen.> Leider sind hier keine DRAMs mehr vorhanden.> Wobei wird nocht unterstützung benötigt.
Willkommen im Team!
DRAM's sind genug da. Derzeit sehe zwei offene Baustellen.
- dem AVR Z80 Code beibringen
- die VGA programmieren (VGA, PS2, Terminal)
@Horst: Auch von meiner Seite ein herzliches Willkommen!
Welche SOJ Dram's kommen jetzt höchstwahrscheinlich zum Einsatz?
4M x 4 SOJ haben 26 Pin?
oder doch die 1M x 4 SOJ mit 24 Pin (Auf der Platine zähle ich 24-Pin's)
Habe ihr dann mal ein paar Bezeichnungen passender Dram's..?
Dann kann ich schon mal meine Bastelkiste durchsuchen..
Peter
Moin mion,
OK, ich schau mal in die AVR-Soft rein.
Ich habe hier moch nen MYAVR Smart-Controler liegen.
Hat den schon jemand erweitert?
Ich werde wohl eher beim PC als Terminal bleiben.
VT50/100 müsste ich auch noch mit Pascal oder C-Sourcen irgandwo
rumliegen haben.
Wenn du noch DRAMS für mich hättest wäre das klasse joe.
Sonst würde ich eine Platine für 8x4164 machen, die sind noch zu
bekommen.
Das ganze mit SRAM zumachen ist sicher nett, aber die Hardwareanpassung
wird dann lagsam etwas umfangreich.
Ich könnte z.B. ein Layout für meinen Hardwarebestand machen,
MYAVR-Smart, 8x4164 plus schon festgelegter Hardwäre von euch. Hat da
jemand Intresse drann?
Das Übertakten der AVR's muss aus meiner sicht nicht unbedingt sein.
Wenn ich wirklich Tempo haben will wäre eine andere CPU angesagt (ARM ab
400 MHz).
Netter wäre ein BUS-System um die weitere Hardware auch per AVR zu
realisieren. Z.B. Ein AVR der Parallelport macht, einen für USB(per
Software), acht bis zehnmal Servoansteuerung u.s.w. ES gibt doch schon
so einiges was man da gut anflanschen könnte. Liesse sich auch alles gut
ins TINY-Basic ins BIOS einbauen.
Peter Sieg schrieb:> Welche SOJ Dram's kommen jetzt höchstwahrscheinlich zum Einsatz?> 4M x 4 SOJ haben 26 Pin?
4Mx4 SOJ kommen zum Einsatz. Die haben 24 Pins und werden von 1 bis 26,
unter Auslassung der 7 und der 20, durchnummeriert. Ein typischer
Vetreter ist z.B. HY5117404C
Joe
Horst schrieb:> Wenn du noch DRAMS für mich hättest wäre das klasse joe.
Ram's kannst du bekommen, sie sind noch oft auf den alten
Speicherriegeln zu finden.
>Netter wäre ein BUS-System um die weitere Hardware auch per AVR zu>realisieren. Z.B. Ein AVR der Parallelport macht, einen für USB(per>Software), acht bis zehnmal Servoansteuerung u.s.w. ES gibt doch schon>so einiges was man da gut anflanschen könnte. Liesse sich auch alles gut>ins TINY-Basic ins BIOS einbauen.
Hier kannst du dich auch austoben, Pin14/Pin15 der VGA-Schnittstelle
sind mit I2C belegt (die einzigen freien Pins). Hier kann noch viel
angeschlossen werden.
Joe
Horst schrieb:> Moin mion,> OK, ich schau mal in die AVR-Soft rein.
Hallo Horst,
genau wie Joe würde auch vorschlagen, daß Du Dir dann den 8080
Interpreter vornimmst. Bevor man ihn auf Z80 aufbohrt, müßte man mal
schauen, ob sich an der Performance noch was machen läßt. Ich fürchte
aber, das man das Teil nur schneller bekommt, wenn man wesentlich mehr
Flash investiert. Und das ist bei Mega8 und Mega88 nicht mehr vorhanden.
> Ich werde wohl eher beim PC als Terminal bleiben.> VT50/100 müsste ich auch noch mit Pascal oder C-Sourcen irgandwo> rumliegen haben.
Bei der Gelegenheit könntest Du auch mal einen Wordstar auf VT100/ansi
anpassen, oder einen angepaßten irgendwo auftreiben. Ich bin immer noch
nicht dazu gekommen, und kopiere zur Zeit fleißig Dateien zwischen Host
und Emulator bzw avrcpm hin und her.
> Sonst würde ich eine Platine für 8x4164 machen, die sind noch zu> bekommen.
Bloß nicht! Viel zu iel Aufwand. Evtl. müßte auch die Software gändert
werden. Und dann nicht mal eine RAM-Disk.
> Das ganze mit SRAM zumachen ist sicher nett, aber die Hardwareanpassung> wird dann lagsam etwas umfangreich.> Ich könnte z.B. ein Layout für meinen Hardwarebestand machen,> MYAVR-Smart, 8x4164 plus schon festgelegter Hardwäre von euch. Hat da> jemand Intresse drann?
Hoffentlich nicht. ;-)
> Netter wäre ein BUS-System um die weitere Hardware auch per AVR zu> realisieren. Z.B. Ein AVR der Parallelport macht, einen für USB(per> Software), acht bis zehnmal Servoansteuerung u.s.w. ES gibt doch schon> so einiges was man da gut anflanschen könnte. Liesse sich auch alles gut> ins TINY-Basic ins BIOS einbauen.
Kleine Erweiterungen sich sicher ok, aber ein Bus-System würde meiner
Meinung nach den Rahmen sprengen. --> anderes System.
A>stat dsk:
A: Drive Characteristics
1944: 128 Byte Record Capacity
243: Kilobyte Drive Capacity
64: 32 Byte Directory Entries
64: Checked Directory Entries
128: Records/ Extent
8: Records/ Block
26: Sectors/ Track
2: Reserved Tracks
I: Drive Characteristics
8128: 128 Byte Record Capacity
1016: Kilobyte Drive Capacity
192: 32 Byte Directory Entries
0: Checked Directory Entries
128: Records/ Extent
16: Records/ Block
32: Sectors/ Track
2: Reserved Tracks
J: Drive Characteristics
8192: 128 Byte Record Capacity
1024: Kilobyte Drive Capacity
192: 32 Byte Directory Entries
0: Checked Directory Entries
128: Records/ Extent
16: Records/ Block
32: Sectors/ Track
0: Reserved Tracks
K: Drive Characteristics
8192: 128 Byte Record Capacity
1024: Kilobyte Drive Capacity
192: 32 Byte Directory Entries
0: Checked Directory Entries
128: Records/ Extent
16: Records/ Block
32: Sectors/ Track
0: Reserved Tracks
L: Drive Characteristics
7680: 128 Byte Record Capacity
960: Kilobyte Drive Capacity
192: 32 Byte Directory Entries
0: Checked Directory Entries
128: Records/ Extent
16: Records/ Block
32: Sectors/ Track
0: Reserved Tracks
So sieht das jetzt bei mir mit 2 4Mx4 Chips aus.
Für jedes Megabyte ein Laufwerk.
Vom ersten Laufwerk gehen 2 Systemspuren ab (8K), für CCP+BDOS, die von
dort beim Warmstart neu geladen werden.
Vom letzten Laufwerk gehen 64Kbyte ab. Schließlich bracht der Rechner ja
auch etwas Arbeitsspeicher. ;-)
Im AVR-Teil sind 32 Sektoren pro Spur und maximal 1 MByte pro Laufwerk
fest vorgegeben. Die obersten 64K werden immer als Arbeitspeicher
verwendet.
Der Rest ist über die CP/M Parametertabellen frei einstellbar.
Dafür verwendet man am Besten die Macros, die ich hier mal angehängt
habe.
Ich war so frei, die DR-Macros für unsere Zwecke etwas anzupassen.
Das ganze kommt auch noch ins SVN, wenn ich etwas aufgeräumt und ein
paar Build-Scripte erstellt habe.
Noch nicht ganz perfekt aber in diese Richtung wird es gehen...
- VGA kann abgetrennt und separat verwendet werden
- Stromversorgung über Steckernetzteil an VGA
- Bereitstellung von 5V und 3.3V
Joe
@Joe: Rx und Tx liegen sich 1:1 gegenüber.. müßten die nicht gekreuzt
sein?
Und wenn es geht würde ich die Verbindungen, die benötigt werden, wenn
man beide zusammen betreiben will auch gleich durchverbinden.. dann muß
man keine Jumper einlöten und verbinden..
Peter
moin moin,
war ein langer Tag heute....... mit Familie unterwegs. :-)
Wo ist oder wer hat die aktuelle Software des AVR?
Meine Kisten hatten früher ECB-BUS.
Der uVGA-Bus ist auch OK.
Gibt's schon eine Backplan und ein Gehäuse dafür?
Würde schon lustig ausschauen, so alles auf halben EURO-Kartenformat.
AVR-CPU-Board mit SD-FD und RAM-FD
zweites SD-FD mit RAM-FD
uVGA.
Paralelle IO's.
Serielle IO's.
USB-Master.
Netzwerk.
RFM12-Board für Haussteuerung und ähnliches.
BT, wofür auch immer.
u.s.w
Und wenn dann mal einer Lust hat noch ein ARM-CPU-Board.
Kann was richtig grosses werden :-)
was würde ein bauteilesatz der aktuellen version kosten, wenn man avr
cp/m platine + vgs/ ps2 modul + aller notwendigen bauteile aus einer
quelle kaufen würde?
Horst schrieb:> Wo ist oder wer hat die aktuelle Software des AVR?http://cloudbase.homelinux.net/viewvc/avr-cpm/
Und hier unter 2. steht noch was dazu:
Beitrag "Re: CP/M auf ATmega88"> Meine Kisten hatten früher ECB-BUS.> Der uVGA-Bus ist auch OK.> Gibt's schon eine Backplan und ein Gehäuse dafür?
Ja, siehe Bild. ;-) [0]
> Würde schon lustig ausschauen, so alles auf halben EURO-Kartenformat.>> AVR-CPU-Board mit SD-FD und RAM-FD> zweites SD-FD mit RAM-FD> uVGA.> Paralelle IO's.> Serielle IO's.> USB-Master.> Netzwerk.> RFM12-Board für Haussteuerung und ähnliches.> BT, wofür auch immer.> u.s.w
Wozu das alles auf einem simulierten 8080 mit C/PM?
> Und wenn dann mal einer Lust hat noch ein ARM-CPU-Board.
Für CP/M dann doch eher ein eZ80.
> Kann was richtig grosses werden :-)
Aber mit der Basis, an der wir basteln macht das imho keinen Sinn.
[1] Das ist ein "Schrottteil" von Pollin für einen Euro.
http://www.pollin.de/shop/dt/MTcwOTcyOTk-/Computer_und_Zubehoer/Hardware/Laufwerke_Cardreader/Card_Reader_UCR_61S.html
Die neue Platine hat eigendlich drei Neuerungen:
1. 8-bit Dram -> damit ca. Faktor 2 im Dram-Zugriff = ca. doppelt so
schnell
2. VGA-Terminal (ala MicroVGA) direkt mit auf der Platine (trennbar)
3. I2C Schnittstelle
Einzig 3. eröffnet erweiterte Möglichkeiten.. Hier würde mich
Interessieren,
was für Möglichkeiten man hier sieht..(Ideen)?
Ansonsten fehlt mir noch eine elegante Möglichkeit mal eine Datei zw.
CP/M Welt und Host-Welt auszutauschen..
Gäbe XModem (muß noche 8080 Version finden). Ohne MicroVGA sollte das
direkt klappen.. aber mit wird die serielle Schnittstelle verwendet..
MicroVGA hat zwar einen 'Pass Through' Modus.. aber ob das klappt..?
Was gäbe es sonst noch für Möglichkeiten../Ideen..?
Peter
Peter Sieg schrieb:> Rx und Tx liegen sich 1:1 gegenüber.. müßten die nicht gekreuzt> sein?> Und wenn es geht würde ich die Verbindungen, die benötigt werden, wenn> man beide zusammen betreiben will auch gleich durchverbinden.. dann muß> man keine Jumper einlöten und verbinden..
Ich glaube es ist schon korrekt so, trotzdem bitte nochmal Schaltung und
Layout überprüfen. Die Belegung ist recht "tricky" deshalb hier mal eine
Übersicht dazu. Das sollte im späteren Betrieb auch Einstellung
erleichtern.
Wie ja schon weiter oben beschrieben, können neben der Kommunikation des
CP/M mit der VGA auch die Varianten CP/M an PC Terminal oder VGA an PC
Terminal eingestellt werden. Gerade die letzte Variante schein mir zum
Test und zur Inbetriebnahme der VGA recht nützlich. Außerdem versehe ich
die AVR im Normalfall mit einem Bootloader, so das über die USB der
jeweilige Controller programmiert werden kann.
Die Verbindungen CP/M VGA sind schon auf der Platine, sie liegen auf der
Unterseite.
> Ansonsten fehlt mir noch eine elegante Möglichkeit mal eine Datei zw.> CP/M Welt und Host-Welt auszutauschen..
Dir gefällt wohl die Variante Vinculum usb nicht? Das CP/M kennt ja
derzeit noch keine COM xx. Also im AVR die SPI für Vinculum usb
programmieren und im BIOS als COM xx anmelden.
@Ronny Minow
Ein Bausatz im Sinne von BAUSATZ ist eigentlich nicht geplant. Es wird
die Platinen und wieder einige Bauelemente (MMC Fassung, SMD IC's, AVR,
Quarze..) geben.
Joe G. schrieb:> Dir gefällt wohl die Variante Vinculum usb nicht?
Doch. Nur kann ich mir die genaue Funktion noch nicht so richtig
vorstellen..
Es wird ein USB Stick mit FAT unterstützt. Per seriellen Befehlen wird
das ganze gesteuert.. Also stelle ich mir das so vor, das im AVR+Bios
eine 2te serielle Schnittstelle implementiert werden müßte. Dazu dann
ein passendes Steuerprogramm auf CP/M Ebene das letzlich auch eine Datei
vom USB Stick lesen und auf CP/M Diskette schreiben kann (und
umgekehrt..).. Als Alternative könnte auch ein Xmodem diese 2te serielle
IF nutzen um z.B mit einem PC Daten auszutauschen.. Richtig..?
Peter
Joe G. schrieb:> Noch nicht ganz perfekt aber in diese Richtung wird es gehen...
Da hätte ich noch ein paar Verbesserungsvorschläge:
1.) Statt des 74HC165 sollte man eher ein 74HC166 nehmen bei dem das
Laden mit dem Takt synchronisiert ist.
2.) Mir leuchtet nicht ganz ein, wozu die 74HC244 Treiber nötig sind.
Laut Philips/NXP Datenblatt könnte ein 74HC-Standardausgang problemlos
4mA treiben, das würde sogar für alle drei Farben gleichzeitig reichen:
Moin moin,
Ich hab mal einen Blick in die Software getan. Schön, aber nicht auf
Tempo optimert. Da kann man noch reichlich arbeit reinstecken.
1.) Für die Z80 Codes EXX und EX AF,AF' muss noch ein zweiter
Registersatz her. Ich würde den ins normale SRAM des AVR legen. Diese
Befehle sind nicht so häufig verwendet worden. Die relativen
Sprungbefehle sollten kein Problem sein.
2.) Die IN und OUT würde ich wahlweise auf einen der seriellen Busse
umlegen.
So hat man die möglichkeit damit eigene Hardware zu steuern. Z.B. könnte
man über I²C oder so PIO's und SIO's anhängen. Ein Mega8 tut per
software so als ob er eine PIO oder SIO wäre.
Besteht die möglichkeit die uVGA so auch zu steuern?
3.) Für die Interrupt Codes (HALT, u.s.w) bräuchte man noch eine freie
Portleitung. Ich würde die SD-Floppy auf eine eigene Platine legen (
zwei Drives) und an den ser. BUS hängen. So wäre wieder reichlich
Hardware frei.
Das alles würde auch das BIOS vereinfachen.
Detlev T. schrieb:> Statt des 74HC165 sollte man eher ein 74HC166 nehmen
Gute Idee, schon geändert.
>Mir leuchtet nicht ganz ein, wozu die 74HC244 Treiber nötig sind.
Das waren Relikte aus der s/w Darstellung - auch geändert.
Peter Sieg schrieb:> Also stelle ich mir das so vor, das im AVR+Bios> eine 2te serielle Schnittstelle implementiert werden müßte. Dazu dann> ein passendes Steuerprogramm auf CP/M Ebene das letzlich auch eine Datei> vom USB Stick lesen und auf CP/M Diskette schreiben kann (und> umgekehrt..).. Als Alternative könnte auch ein Xmodem diese 2te serielle> IF nutzen um z.B mit einem PC Daten auszutauschen.. Richtig..?
Ja Peter, genauso dachte ich.
Hans- w. Schütz schrieb:> mich würde interessieren wann die neuen Platinen zu erwerben sind
Wenn jeder Interessent wirklich draufgesehen hat würde ich die
Bestellung auslösen. Bisher gab es ja noch Änderungen.
Der kalkulierte Preis (Losgröße 10) liegt bei 18,50 pro Stück.
Joe
Hallo Joe,
ich bin zwar nicht direkt ein Interessent für Platinen, aber die
VGA-Geschichte interessiert mich.
Mir ist da eine Unstimmigkeit aufgefallen. Du beziehst dich auf das
AVR-VGA-Projekt, dass 50 Zeilen a 80 Spalten hat. Das macht einen
SRAM-Bedarf von 4000 Bytes. Eingeplant hast du ein ATMEGA88 mit 1024
Bytes.
Es gibt mit dem 328p eine Version mit 2kiB, damit würde man noch 25
Zeilen schaffen, aber niemals 50. Das dürfte der Grund gewesen sein,
warum das Original-Projekt den Mega644 (4kiB) nutzt.
Außerdem könnte man mit einem "großen" ATMEGA alle 8 Bit des
Schieberegister nutzen und mit einem zweiten Port, einem 4-fach 2 zu
eins Multiplexer (statt AND) und dem DAC wie bei Jörg Wolframs Chipbasic
für Vorder- und Hintergrundfarbe je eine aus 16 auswählen ohne mehr ICs
zu brauchen.
Gruß, DetlevT
@Joe: Ich denke wir sollten jetzt auch nicht zu schnell die Platinen
ordern..
Ein paar Tage mehr zum drüber nachdenken, sollte nicht schaden.. Ich
persönlich finde, das jetzt ohne den VGA-Terminal Part, unser avr cpm
eigendlich nur von 4 auf 8-bit Ram gewachsen ist (mit dann größerer
Ramdisk).. ich bin noch nicht gänzlich überzeugt, ob wir nicht mit einem
größeren AVR (ATmega32/644/1284) mehr gewinnen, mit dem ATmegaX8 sind
wir mit den Pin's am Ende..
Peter
@Peter
Ich habe kein Problem noch einige Tage damit zu warten. Einen größeren
AVR würde ich auch nicht nehmen. Der Reiz besteht ja gerade darin mit
einem sehr einfachen System zu arbeiten. Wenn der Programmspeicher nicht
reicht gibt es ja noch den ATmega168. Benötigt man noch weitere Pins, so
lässt sich das System bequem über I2C erweitern.
@alle
Hier die letzte Schaltungs- und Layoutversion. Ich würde nun erst mal
Änderungen, Kritik, Wünsche oder Zustimmungen (Ablehnungen) sammeln, ehe
ich sie noch mal anfasse.
Joe
Horst schrieb:> Ich hab mal einen Blick in die Software getan. Schön, aber nicht auf> Tempo optimert. Da kann man noch reichlich arbeit reinstecken.
Wunderbar, dann kanns ja losgehen.
> 1.) Für die Z80 Codes EXX und EX AF,AF' muss noch ein zweiter> Registersatz her. Ich würde den ins normale SRAM des AVR legen.
Klar, und die restlichen, fehlenden natürlich auch. In der 8-Bit
Variante sind eh schon einige Register ausgelagert.
> Diese> Befehle sind nicht so häufig verwendet worden. Die relativen> Sprungbefehle sollten kein Problem sein.>> 2.) Die IN und OUT würde ich wahlweise auf einen der seriellen Busse> umlegen.> So hat man die möglichkeit damit eigene Hardware zu steuern. Z.B. könnte> man über I²C oder so PIO's und SIO's anhängen. Ein Mega8 tut per> software so als ob er eine PIO oder SIO wäre.> Besteht die möglichkeit die uVGA so auch zu steuern?>> 3.) Für die Interrupt Codes (HALT, u.s.w) bräuchte man noch eine freie> Portleitung. Ich würde die SD-Floppy auf eine eigene Platine legen (> zwei Drives) und an den ser. BUS hängen. So wäre wieder reichlich> Hardware frei.>> Das alles würde auch das BIOS vereinfachen.
Wir freuen uns auf Deine Verbesserungen und Erweiterungen.
@joe g: ok, welche teile kannst du liefern? ich habe noch ein paar edo-
ram riegel hier liegen. ich müsttste schauen, was das für ram's sind...
kannst du, wennn du die platinen in die fertigung gibts, eine material
liste erstellen, damit ich evtl. fehlende teile bestellen kann?
wie trennt ihr eigendlich die vga platine von der avr cpm platine? ich
denke, eine pinleiste, um die signale per jumper verbinden/ trennen zu
können, sollte ausreichen...
Detlev T. schrieb:> Mir ist da eine Unstimmigkeit aufgefallen. Du beziehst dich auf das> AVR-VGA-Projekt, dass 50 Zeilen a 80 Spalten hat. Das macht einen> SRAM-Bedarf von 4000 Bytes. Eingeplant hast du ein ATMEGA88 mit 1024> Bytes.
Der ATmega88 steht in der Schaltung nur stellvertretend (EAGLE
Footprint) für den ATmega328. Zum Einsatz kommen soll tatsächlich der
328. Das gibt dann genau die von dir genannten 25 Zeilen zu 80 Spalten.
Ja, es könnten mehr Ports, ein DAC, ein Multiplexer... aber auch ein
CPLD oder ein FPGA verwendet werden. Ich habe aus zwei Gründen darauf
verzichtet.
1. Das AVR CP/M ist bewusst mit sehr einfacher Hardware aufgebaut,
sozusagen ein minimalistisches System. So soll es auch bleiben. Mich
schmerzt eigentlich schon das dritte IC. Es ist keine Konkurrenz für
ARM's, eZ80, ... Ein Schüler mit Bastelerfahrung und einer kleinen
Kramkiste soll es aufbauen können und ein vollwertiges Betriebsystem mit
allen dazugehörigen Tools nutzen können.
2. Die VGA soll die gleichen Bedingungen erfüllen. Bunte Buchstaben
(außer grün auf Schwarz ;-) ) machen da eigentlich keinen Sinn.
3. Mit der microVGA gibt es schon etwas für diejenigen die mehr wollen.
Joe
Horst schrieb:> hat mal einer für den MYZ80 Emu ein Disk-Images mit DDTZ drinn für mich?> Bräuchte ich mal fürs testen.
Auf die Schnelle hatte ich nicht rausgefunden, wie man beim MYZ80 in und
aus den Diskimages kopiert. Bin dann beim simh hängen geblieben.
Z80-Simulator im DOS-Emulator muß ja auch nicht sein. :-)
Im Anhang ein nackter DDTZ.COM. War im simh Disk-Image schon drin.
Dort geht rein und raus mit den mitgelieferten Programmen R.COM und
W.COM.
Ronny Minow schrieb:> kannst du, wennn du die platinen in die fertigung gibts, eine material> liste erstellen, damit ich evtl. fehlende teile bestellen kann?
Ja, kann ich, kann aber EAGLE auch mit dem oben reingestellten Files.
> wie trennt ihr eigentlich die vga platine von der avr cpm platine?
Mit der Säge ;-)
Die genaue Bestellliste gebe ich bekannt, wenn wir das KGV gefunden
haben.
Joe
Von meiner Seite ok. Einzig ich habe keine 4M x 4 Dram Chips.. habt ihr
davon genug (1M x 4 habe ich jede Menge.. aber die dürften ja nicht
passen)?
Peter
Joe G. schrieb:> Ein Schüler mit Bastelerfahrung und einer kleinen> Kramkiste soll es aufbauen können und ein vollwertiges Betriebsystem mit> allen dazugehörigen Tools nutzen können.>> 2. Die VGA soll die gleichen Bedingungen erfüllen. Bunte Buchstaben> (außer grün auf Schwarz ;-) ) machen da eigentlich keinen Sinn.
Ich schaue vor allem auf den VGA-Teil (wird dich nicht überraschen) und
kann da deine Argumente nicht ganz nachvollziehen.
Kaum einer wird alle Teile in seiner "Kramkiste" finden. Den relativ
neuen ATMEGA328p auch sicher seltener als den häufig genutzten
ATMEGA644. Letzterer ist auch bei den üblichen Verdächtigen (Pollin,
Reichelt,...) im Angebot, der 328p nicht.
Wenn man schon eine Leiterplatte hat, macht ein 74HC157 einzulöten auch
nicht mehr Mühe als ein 74HC08. Der Preis ist auch fast gleich.
PS: Ich hatte mir jetzt gerade noch einmal den Schaltplan vom AVR-VGA
angesehen. Da ist mir aufgefallen, dass dort ein 74*AC*08 als AND-Gatter
vorgesehen war. Das erklärt, warum die Treiber noch nachgeschaltet
werden mussten. Die AC können praktisch keinen Strom liefern.
Detlev T. schrieb:> Kaum einer wird alle Teile in seiner "Kramkiste" finden. Den relativ> neuen ATMEGA328p auch sicher seltener als den häufig genutzten> ATMEGA644. Letzterer ist auch bei den üblichen Verdächtigen (Pollin,> Reichelt,...) im Angebot, der 328p nicht.
Den ATMEGA328P-PU gibt es zum Beispiel bei CSD.
Gruß,
Frank
ERRATUM
Detlev T. schrieb:> 2.) Mir leuchtet nicht ganz ein, wozu die 74HC244 Treiber nötig sind.> Laut Philips/NXP Datenblatt könnte ein 74HC-Standardausgang problemlos> 4mA treiben, das würde sogar für alle drei Farben gleichzeitig reichen:
Da habe ich mich doch glatt um eine Größenordnung vertan. In
Wirklichkeit sind es nicht 2.75mA, sondern 27.5mA. Das schafft man mit
einem HC-Ausgang natürlich nicht mehr.
Ich hänge hier mal die partlist aus eagle dran..
Hier ein Auszug ohne C, R, Jumper etc.:
1
PartValuePackageLibrary
2
B1DBDB101GDBrectifier
3
CON1SCDA5A0201SCDA5A0201SCDA5A0201
4
IC1ATmega88-20PDIL28-3atmel
5
IC274S08DSO1474xx-eu
6
IC3FT232RLSSOP28ftdichip
7
IC4ATmega88-20PDIL28-3atmel
8
IC774AC08DSO1474xx-eu
9
IC8LF50CDTDPACKv-reg
10
IC9LF33CDTDPACKv-reg
11
IC1074HC166DSO1674xx-eu
12
J1DCJ0202DCJ0202con-jack
13
LED1GrünLED3MMled
14
LED2GelbLED3MMled
15
LED3GrünLED3MMled
16
QG125MHzDIL14Scrystal
17
QG225MHzDIL14Scrystal
18
U$1DRAM_4M_4SOJ26-24AMESYS
19
U$2DRAM_4M_4SOJ26-24AMESYS
20
X1PN61729-SPN61729-Scon-berg
21
X2PS2SSV-BC06con-yamaichi
22
X3VGAHDF15Hcon-subd
Dazu ggf. noch ein paar Hinweise..
FT232RL und entsprechende Bauteile + USB Buchse braucht man nur, wenn
man diese PC Verbindung auch nutzen möchte..
Ich gehe davon aus, das der SD Slot auch mit der Platine geliefert
werden kann (wie beim letzten mal..)
Der AVR CP/M läuft bei mir stabil mit 30MHz. In ein paar Tagen bekomme
ich 40MHz Quarzoszillatoren und weiß dann, ob es auch damit geht.. d.h,
wer seinen AVR CP/M höher takten möchte, sollte anstatt 1x25MHz dann
einen höher getakteten Quarzoszi bestellen..
Peter
D.h z.Z liegt man bei 4-bit und Übertaktung bei ca. 1,3MHz 8080 Speed.
Das erreicht man ebendso mit 8-bit Dram Ansteuerung ohne Übertaktung.
Mit 8-bit + Übertaktung sind ca. 2MHz 8080 Speed drin..
Und noch weitere Optimierungen des Codes kommen on Top.
Peter
Detlev T. schrieb:> Wenn man schon eine Leiterplatte hat, macht ein 74HC157 einzulöten auch> nicht mehr Mühe als ein 74HC08.
Wozu dann der Multiplexer? Um während der Schwarzschulter die
Hintergrundfarbe einzustellen?
Joe G. schrieb:> Wozu dann der Multiplexer? Um während der Schwarzschulter die> Hintergrundfarbe einzustellen?
Der Multiplexer wird vom Ausgang des Schieberegisters angesteuert. Er
schaltet dann immer die einen oder die anderen 4 Bit durch, die auf
einem (zweiten) Port ausgegeben werden. 4 Bit= Rot Grün Blau und
Intensität. Damit könnte man dann Vorder- und Hintergrundfarbe frei
aus einer Palette von 16 Farben wählen. Auch ein anders farbiger Rahmen
wäre möglich, wenn man die ISR etwas erweitert.
Detlev T. schrieb:> Der Multiplexer wird vom Ausgang des Schieberegisters angesteuert.
OK, verstanden. Es gibt nur leider keine 2x4 Bit die frei sind, d.h.
doch einen größeren Controller zu nutzen. Aber genau das sollte ja nicht
sein.
Ich sehe einfach folgendes Problem. Zunächst wird sehr sehr ausführlich
über die Hardware diskutiert (ist auch gut so). Die Hardware ist jedoch
nur die halbe Miete. Es gehört natürlich noch eine entsprechende
Software dazu. Die Softwarediskussion bzw. die Mitarbeit ist meist
umgekehrt proportional zur Hardwarediskussion (ist nicht gut so).
Mein Vorschlag. Wenn die Software auf der SimpleVGA ordentlich und
stabil läuft, es einige nachgebaut und getestet haben, dann gibt es eine
nette 80x50 Farbvariante.
Joe
Detlev T. schrieb:> PS: Ich hatte mir jetzt gerade noch einmal den Schaltplan vom AVR-VGA> angesehen. Da ist mir aufgefallen, dass dort ein 74*AC*08 als AND-Gatter> vorgesehen war. Das erklärt, warum die Treiber noch nachgeschaltet> werden mussten. Die AC können praktisch keinen Strom liefern.
Mein Datenblatt sagt mir, dass gerade der AC-Type 24mA treibt.
Joe G. schrieb:> Es gehört natürlich noch eine entsprechende> Software dazu. Die Softwarediskussion bzw. die Mitarbeit ist meist> umgekehrt proportional zur Hardwarediskussion
Ist klar. Ich mache ja nur Vorschläge, die Entscheidung triffst du.
An dem Quelltext würde sich allerdings nicht viel ändern. Du musst ja
jetzt schon die drei Bits für die Farbe an einem Port ausgeben, das wäre
dann halt stattdessen ein ganzes Byte. Die Ausgabe-Routine würde sich
gar nicht ändern, allenfalls die Bezeichnung der Pins, die vermutlich
ein einziges mal irgendwo definiert werden. Dafür könnte man dann den
Standard 8x16 Font einer VGA-Karte nutzen, während du jetzt irgendwo
einen 6x16 Font auftreiben musst, weil du nur 6 Bits ins Schieberegister
schreiben kannst.
PS: Ich habe schon ein kleines C-Programm geschrieben, dass einen
VGA-Font erst einmal komplett einliest und die Daten dann als C-Datei
wieder ausgibt. Das auf Assembler-Ausgabe umzustricken ist kein großer
Akt. Sage Bescheid, wenn du Interesse daran hast.
@alle
Wir gehen nun langsam in die Bestellphase. Ich bitte alle Interessenten
wie beim letzen mal um eine kurze Mail an "feinmechaniker", damit ich
sie in den Verteiler aufnehmen kann. Weiterhin bitte die Anzahl der
Platinen und der möglicherweise noch benötigten Bauelemente mitteilen.
Wer meine Kontaktdaten schon hat, natürlich auch direkt ;-)
Schon erfasst sind:
Peter S. x Platinen
Peter Z. 1 Platine
Hans-Werner S. 2 Platinen, aber noch ohne Kontaktmail
Ronny Minow x Platinen
Noch mal einige Worte zur Hardware.
AVR CP/M:
Die neue Variante wird eine 8 Bit RAM Variante sein. Die alte 4 Bit
Variante läuft stabil. Die neue 8 Bit Variante ist in dieser Form der
erste Neuaufbau. Eine Versuchsschaltung auf LR läuft aber schon bei Leo
C.
Auch ist das neue Layout noch nicht getestet. Es könnten (was ich nicht
hoffe) noch Fehler drin sein. Alle Nachbauinteressenten sollten sich
also darüber im Klaren sein so was wie "Betatester" zu sein.
AVR VGA:
Diese Schaltung ist eine reine Experimentiervariante für eigene
Versuche. Die Grundidee basiert auf einer Schaltung von Sebastian B.
hier im Forum (siehe Beitrag "AVR VGA Terminal"). Mein LR Aufbau erzeugt
derzeit die H- und V-Synchronimpulse und die Datenpixel. Hier besteht
also noch jede Menge Handlungsbedarf.
microVGA:
Die Anschlüsse an der AVR CP/M Platine liegen Pinkompatibel zur
Beschaltung der microVGA. Hier gibt es mindestens zwei funktionierende
Systeme (Peter's und mein eigenes). Die microVGA bedient allerdings nur
ein englisches Tastaturlayout sowie eine maximale Baudraute von 38400.
Joe
Hat denn schon jemand das VGA Term in gange gebracht??
Hab ja die VGAterm hat aber Ihren preis...die Alternative wäre schon
interessant. Na schaun wir mal..
Gruß
Hans- Werner
Wohl kaum. Lt Joe existiert der Code für ATmega16.. müßte also erst an
328 angepasst werden.. Evtl. wäre es auch angebracht, für das VGATerm
einen extra Thread auszumachen.. könnte mehr Leute interressieren, die
mit CP/M wenig anfangen können/wollen.. auch um ggf. noch mehr für
Platinen zu
interessieren..
Peter
Moin moin,
Die ersten Aenderungen für den Z80-Emu sind fertig.
Neuer opcode-Interpreter
EX AF,AF'
EXX
Relative Jumps
Da ich noch keine Hardware habe bräuchte ich mal jemanden der die
Software
testen kann. Wer hat Lust und für welchen AVR soll ich es compilieren?
Horst S. schrieb:> Da ich noch keine Hardware habe bräuchte ich mal jemanden der die> Software> testen kann.
Sende mir doch einfach die Quelle zu und ich stelle sie über SVN bereit.
Joe
Horst S. schrieb:> Neuer opcode-Interpreter> EX AF,AF'> EXX> Relative Jumps
Das alles sagt mir nicht soo viel ;-)
Ist der z80 jetzt damit komplett drin..?
Generell kann ich schon testen.. aber bei dem kleinsten Problem.. geht
das dann wie ein Ping-Pong Spiel los.. ist halt sicher nicht ideal ohne
eigene Hardware.. Hast du das für die 4-bit Dram oder die 8-bit
Dramversion gemacht?
Außer Leo C. dürfte z.Z wohl eher niemand die 8-bit Hardware haben.. ;-)
---
Nun, ich habe die 4-bit Version (3x) hier. 30MHz. 38400 Baud.
Ich habe Sargon.com (Schachprogramm) auf einer 'Diskette'. Das Programm
steigt mit illegel Opcode aus, da es vermutlich z80 Code enthält..
---
Alternativ kann ich auch 1 x 4-bit Hardware verkaufen (-> Mail).
Peter
Gibt es irgendwo eine Tabelle mit den Steuercodes für die Sondertasten?
Es wäre dann möglich, VGATerm speziell für das System umzuschreiben.
Würde dann diese Spezial-Version liefern, falls dies gewünscht wird.
Moin moin,
@joe
>Sende mir doch einfach die Quelle zu und ich stelle sie über SVN bereit.
danke, aber so völlig ungetestet möchte ich das nicht in die weite welt
verteilen. wenn es zur zeit nur einen mit 8bit HW gibt wäre es wohl ganz
gut wenn ich meine änderungen auch in die 4bit SW einbaue. ich bin nach
schlechten erfahrungen bei anderen projekten kein freund von svn mehr.
kannst du die SW irgend wo für einen normalen download bereitstellen?
@Peter Sieg
danke fürs angebot, sende mir das mal als PM zu.
ich hätte schon gern die 8Bit hardware wann sind die platinen den so
weit?
ich lasse meine sonst immer beim platinenbelichter machen. ist die DRAM
verfügbarkeit/beschaffung eigentlich schon geklärt?
ich denke ich habe hier die SW als 8bit version.
leider ist in der SW selber keine doku und/oder change history drinn.
Horst S. schrieb:> danke, aber so völlig ungetestet möchte ich das nicht in die weite welt> verteilen.
Wenn die Software nicht verfügbar ist, kann sie nicht getestet werden...
> ich denke ich habe hier die SW als 8bit version.
Mir scheint, das nicht nur wir hier im Dunkeln tappen...
Hast Du keine Hardware, auf der Du testen kannst?
Wenn Du Deine Software (noch) nicht nicht ins Forum stellen willst, dann
schick sie mir doch bitte per Email. Ich kann Dir dann sagen, welche
Version Du hast, und auf welcher Hardware sie laufen würde. Außerdem
kann ich dann auch gene mal was testen.
Hallo Horst,
prinzipiell läuft Dein Interpreter. So siehts im Moment aus:
1
CPM on an AVR, v1.0
2
3
Testing RAM: fill...wait...reread...
4
5
Initing mmc...
6
CP/M partition at: 001, size: 7811KB.
7
CP/M partition at: 15624, size: 7812KB.
8
CP/M partition at: 31248, size: 7812KB.
9
Partinit done.
10
Ok, CPU is live!
11
12
ipl
13
62k cp/m vers 2.2
Danach sollte der CP/M Prompt "A>" kommen....
Der Bootloader (ipl) wird ausgeführt, der Anfang vom BIOS.
Im Bios hängt das Programm zuerst in der Console-Inputschleife (wo es
garnicht hinkommen sollte), und danach endlos in der Bootschleife, weil
der avr-teil beim Sektor lesen immer einen Fehler zurückmeldet.
Ich habe den Verdacht, das bei call/return etwas schief läuft.
Horst S. schrieb:> wenn es zur zeit nur einen mit 8bit HW gibt wäre es wohl ganz> gut wenn ich meine änderungen auch in die 4bit SW einbaue.
Im Moment scheine ich der einzige zu sein, der die 8-Bit Variante
aufgebaut hat. Es reicht aber, wenn Du Deine Software einmal schreibst.
Vorläufig kann ich sie dann in die verschiedenen Versionen integrieren.
Auf längere Sicht möchte ich aber nur noch eine Version haben,
allerdings modularisiert. Vielleicht sollte ich das jetzt endlich mal
machen.
> ich bin nach> schlechten erfahrungen bei anderen projekten kein freund von svn mehr.
Ohne Versionsverwaltung wirds aber echt schwierig mit mehreren Leuten an
einem Projekt. Oder richtet sich Deine Aversion speziell gegen
Subversion, und eine andere Versionsverwaltung wäre ok?
> ich denke ich habe hier die SW als 8bit version.> leider ist in der SW selber keine doku und/oder change history drinn.
Die change history ist im svn.
Die Doku ist hier im Thread. ;-)
Ansonsten: "Use the source luke!" ;-)
Im Source sind ganz oben die Ports definiert. Dort kannst Du sehen, das
für das RAM nur 4 Datenbits definiert sind.
Die aktuellen Quellen sind hier:
http://cloudbase.homelinux.net/viewvc/avr-cpm/trunk/
Das ist die "stabile" Version für die aktuelle (4-Bit-RAM) Hardware.
http://cloudbase.homelinux.net/viewvc/avr-cpm/branches/softuart/
Hier ist z.Zt. die Version für 8-Bit RAM.
Sorry für svn.
Leo C. schrieb:> Die Doku ist hier im Thread. ;-)
Es muss ja nicht jeder programmieren oder Hardware entwerfen. Vielleicht
findet sich hier einer der sich mal an eine ordentliche Doku macht.
Gibt es noch Interessenten für die neue LP? Alle von mir schon Erfassten
sollten im Mailverteiler sein, aber möglicherweise habe ich noch
jemanden vergessen. Einfach bei mir melden.
Hallo Leute,
wenn mein System endlich läuft werde ich es dokumentieren und alles auf
meiner Webseite veröffentlichen....
Wer seine Softwareversionen dann mit veröffentlichen will...
kein Problem.
Webseite schuetz.thtec (dot)org
Gruß
Hans- Werner
@Horst
> Der Bootloader (ipl) wird ausgeführt, der Anfang vom BIOS.> Im Bios hängt das Programm zuerst in der Console-Inputschleife (wo es> garnicht hinkommen sollte), und danach endlos in der Bootschleife, weil> der avr-teil beim Sektor lesen immer einen Fehler zurückmeldet.
Ich habe nochmal etwas genauer hingeschaut: Der Fehler ist ein völlig
anderer.
> Ich habe den Verdacht, das bei call/return etwas schief läuft.
Jetzt habe ich einen anderen Verdacht, aber ich muß noch suchen.
moin moin,
danke Leo. da scheint sich noch ein fehler in der todo_table
eingeschlichen zu haben. ich werde die noch mal überprüfen. kannst du
über die debugfunktion noch irgend was an infos sehen?
ich müsste sonst jeden möglichen opcode von hand testen. :-(
Horst S. schrieb:> danke Leo. da scheint sich noch ein fehler in der todo_table> eingeschlichen zu haben. ich werde die noch mal überprüfen. kannst du> über die debugfunktion noch irgend was an infos sehen?> ich müsste sonst jeden möglichen opcode von hand testen. :-(
Einen Fehler habe ich inzwischen gefunden. In meinem BIOS ist aber auch
ein Fehler.
Die Details schicke ich Dir per E-Mail, sonst wird das hier zuviel.
Horst S. schrieb:> aua, das klingt nach einer etwas grösseren baustelle.....
Ich glaube eher an ein, zwei, klitzekleine. Aber bis man die gefunden
hat,...
Hallo Joe,
Joe G. schrieb:> 1. Das AVR CP/M ist bewusst mit sehr einfacher Hardware aufgebaut,> sozusagen ein minimalistisches System. So soll es auch bleiben. Mich> schmerzt eigentlich schon das dritte IC.
Nur Interesse halber: Gibt es (außer der Möglichkeit der Farbänderung
per Software) einen Grund für den 74AC08? Könnte man, wenn man mit weiß
auf schwarz zufrieden wäre, da als Impedanzwandler nicht einen einfachen
Emitterfolger nutzen.(z.B. mit BF199: max. 100mA / 400MHz
Transitfrequenz) Statt eines ICs wäre das dann nur ein Transistor und
ein paar Widerstände.
Gruß, DetlevT
Detlev T. schrieb:> Gibt es (außer der Möglichkeit der Farbänderung per Software) einen Grund für
den 74AC08?
Nein gibt es nicht, ist nur für Nostalgiker wie mich die gerne grün auf
schwarz oder amber auf schwarz möchten, so wie es früher war...
Ansonsten ist natürlich auch ein schneller Transistor ausreichend.
Joe
Detlev T. schrieb:> Mich>> schmerzt eigentlich schon das dritte IC.
Das hatte ich glatt überlesen. Das ditte IC bezog sich auf die reine AVR
CP/M Schaltung, also ohne VGA. Hier kam gegenüber der Urvariante noch
der 74VHC08 als Pegelwander der MMC dazu. Das wurde notwendig um den AVR
und RAM sicher mit 5V laufen zu lassen.
Joe
hallo joe g,
kannst du dram's, bzw. sram's, für das board (je nach varainte) liefern?
falls nicht, ich habe hier noch ein paar edo ram riegel liegen. ob man
die bausteine verwenden kann, muss ich mal prüfen... ich habe eine gute
anzahl dieser riegel liegen. aber, welche bauteine man hiervon verwerten
kann, muss ich erst testen...
amsonten: kannst du evtl. sogar alle benötigten bauteile liefern? in
form eines bauatzes versteht sich. falls nicht, nehme ich die passenden
dram's/ sram's und die beiden platinen (avr cp/m platine + vga platine).
Moin moin,
gibt es eigentlich schon eine Version mit SRAM?
Den 628512 und 74HC374 gibt es günstig und als DIL.
Wenn schon Bastelkisteprojekt dann am besten auch ohne SMD.
@Horst S.
Damit solltest du besser nicht rechnen. Die DRAMs werden hier ja auch
als RAM-Disk benutzt, da fehlt beim SRAM der Platz. Außerdem würde sich
da vielleicht auch eher ein ATMEGA8515 oder 162 anbieten, der ein
SRAM-Interface in Hardware mitbringt. Ganz weit oben wurde das kurz
einmal andiskutiert, dann aber halt ein anderer Weg gegangen.
@VGA
Das ist der Teil, der mich eigentlich interessiert. Ich habe einmal eine
Impedanzwandlerschaltung mit einem Transistor simuliert. (R5-R7 ist der
VGA-Monitor)
Sieht alles ziemlich gut aus. Die Flankensteilheit wird maßgeblich vom
Eingangssignal bestimmt. Der Transistor allein schafft etwa 3ns
(10%<->90%).Nur die Abrundung am Ende der steigenden Flanke ist ein
Artefakt des Verstärkers allein. Der Eingangsstrom bei "ON" liegt bei
etwa 5mA, 6mA Spitze beim Schalten. Also etwas, was ein 74HC166 ohne
Hilfe noch so schafft.
Packt es als Memo zu den Akten. Vielleicht kommt die Frage bei einer
späteren Version wieder auf, wenn man den Aufbau weiter vereinfachen
will. Das hier soll keine Kritik an der aktuellen Hardware sein.
Die "ASC"-Datei ist die Simulation. Falls noch jemand damit spielen
will.
moin moin
mal eine frage an die asm-profis hier.
.dw label erzeugt 2byte mit der adr des label. so weit ok.
.dd low(label) erzeugt leider auch 2byte und eine warnung.
beides möchte ich aber nicht, sonder nur das lowbyte der adr.
ich arbeite mit avr-studio.
schon mal danke.
Hi
>.dd low(label) erzeugt leider auch 2byte und eine warnung.>beides möchte ich aber nicht, sonder nur das lowbyte der adr.
Der Flashspeicher der AVR ist Word-Organisiert. Daran lässt sich nichts
ändern.
MfG Spess
Kurze Info bez. Übertakten: 40MHz bei 3,3V geht nicht mehr. 30MHz läuft
stabil. Bei 5V kann das natürlich trotzdem noch mit 40MHz klappen (muß
aber nicht).
Peter
Moin moin,
Die 8080 Version ist so weit fertig.
Der Code passt noch locker in einen ATMega8.
Es ist noch Platz für zusätliche Wünsche.
Der Z80 hat über 700 Befehle, das passt leider nicht
mehr in die 8K. Hier für ist dann ein ATMega168 nötig.
Im wessentlichen habe ich den Opcode-Interpreter etwas auf Tempo
gebracht und für den Z80 vorbereitet.
Wer weiter mit arbeiten möchte kann sich direkt bei mir melden.
Danke noch mal an Leo fürs Testen da ich selbst noch keine
Schaltung habe.
Wie schaut es mit der Hardware aus?
Neue Ideen, neue Wünsche?
instr do_fetch_DIR16, do_nop, do_store_BC ;01 nn nn ;LD BC,nn
10
instr do_fetch_DIR8, do_op_CPFA, do_nop ;FE nn ;CP n
Nur mal zwei Befehle als Beispiel. Die Tabellen wären übersichtlicher,
und bei Änderungen an der Tabellenstruktur müßte man nur das Makro
ändern.
> Im wessentlichen habe ich den Opcode-Interpreter etwas auf Tempo> gebracht und für den Z80 vorbereitet.
So sieht es jetzt aus:
1
Zeit "Speed" HW Interpreter
2
[s] [KHz]
3
--------------------------------------
4
3.364 857 4 alt
5
3.173 1088 4 neu (Horst S.)
6
1.924 1499 8 alt
7
1.753 1645 8 neu (Horst S.)
Hardware mit 4bit/8bit-RAM, jeweils bei 20MHz.
>> Wer weiter mit arbeiten möchte kann sich direkt bei mir melden.>> Danke noch mal an Leo fürs Testen da ich selbst noch keine> Schaltung habe.
Wie man an der Tabelle sieht, läuft es jetzt auch mit der neuen
Hardware.
Ich habe nochmal eine Kleinigkeit am Interpreter ändern müssen, weil die
fetch- und store-routinen (dank der RAM-Makros in der 8-Bit Version)
nicht mehr zusammen in eine Page passen.
Ich habe angefangen, das Programm in mehrere Dateien zu zerlegen.
Die Struktur, wie das Ganze werden soll, kann man sicher schon erkennen.
Es gibt jetzt einen neuen Schalter, mit dem man die 8-Bit oder 4-Bit
auswählen kann. Weitere Schalter, zb. für die Größe des RAMs, sind
geplant. Die RAM-Disk ist z.Zt. gerade abgeschaltet. Wer
(Verbesserungs-) Vorschläge hat, bitte (hier) melden. Ich suche z.B.
noch nach einer Möglichkeit, die DRAM-Makros zu verunübeln.
Die neueste Version habe ich hier angehängt. Demnächst kommt sie auch
ins SVN. Z.Zt. in branches/modules. Später, wenn alle damit glücklich
sind, nach trunk.
Gute Nacht
Horst S. schrieb:> Wie schaut es mit der Hardware aus?
Die LP kommen am 27.08. Die restliche HW bestelle ich spätestens morgen,
es fehlen noch Zuarbeiten.
Moin Moin,
Frühstückspause!
und schnell die Tabelle gebaut. Gut das ich die in Excel verwalte.
Baust du das noch mit ein Leo? Danke.
Ich kümmere mich weiter um den Z80.
Danke.
@Leo C + Horst S: SUPER!! Herzlichen Dank! Mit euch kommt das Projekt
softwaretechnisch wirklich in 'ungeahnte Dimensionen' ;-)
(..and boldly go were no one has gone before..)
Prima!
(Habe gerade mal die 4-bit Version durch den Assembler gejagt;
heute nachmittag kann ich es erst den AVR flashen.. dann mehr..)
Peter
Peter Sieg schrieb:> Ups.. das war es noch nicht ganz für die 4-bit Version:> [code]> Booten:>> Initing mmc...> CP/M partition at: 401625, size: 8032KB.> CP/M partition at: 417690, size: 8032KB.> CP/M partition at: 433755, size: 8032KB.> Partinit done.> Ok, CPU is live!>> A =80 BC =0000 DE =0000 HL =0000 SP =08B0 PC =2000 31 00> 10> A =80 BC =0000 DE =0000 HL =0000 SP =1000 PC =2003 CD 35> 20
Also hat schon mal was funktioniert. Was war das denn?
> --- dann das hier geändert --->> #define K 1024> #define M 1204*K>> #define RAMSIZE 256*K*4 /* 1 chip 256Kx4 */> ;#define RAMSIZE 4*M*4 * 2 /* 2 chips 4Mx4 */
Das ist bisher nur so 'ne Idee. Wird noch nirgens ausgewertet.
Das ist auch ein Grund, warum die RAM-Disk abgeschaltet ist.
>> #define RAMDISKCNT 0 /* Number of RAM disks *>> --- und das hier geändert --->> .equ INS_DEBUG = 0
Das hatte ich vor dem Veröffenltlichen vergessen.
Wenns aber mit dem Schalter lief, muß es ohne den auch laufen.
Es wäre schön gewesen, wenn Du etwas genauer aufgeschrieben hättest, was
Du genau übersetzt hast.
> --- Fehler beim assemblieren ---
..
> C:\cpmtools\avr2\dram-4bit.asm(88): error: Relative branch out of reach
...
Die Fehler bekomme ich jetzt auch, wenn ich für Mega328P assembliere.
Mal sehen, ob ich die mit ein bischen Code-verschieben weg bekomme.
Leo C. schrieb:> Es wäre schön gewesen, wenn Du etwas genauer aufgeschrieben hättest, was> Du genau übersetzt hast.
ok. Sorry.
Zuerst für ATmega88 übersetzt. kein Fehler dabei.
Dann aber die debug Meldungen..
Und da ich immer einen 168 / 88 im Wechsel nutze, dann debug
ausgeschaltet
und für 168 übersetzt.. dabei die 9 Fehlermeldungen..
1
CPMonanAVR,v1.0
2
3
TestingRAM:fill...wait...reread...
4
5
Initingmmc...
6
CP/Mpartitionat:401625,size:8032KB.
7
CP/Mpartitionat:417690,size:8032KB.
8
CP/Mpartitionat:433755,size:8032KB.
9
Partinitdone.
10
Ok,CPUislive!
11
ipl
12
13
62kcp/mvers2.2
14
15
A>dir
16
17
18
A:ASMCOM:DDTCOM:DUMPCOM:EDCOM
19
A:TCOM:TLOOPCOM:LOADCOM:MBASICCOM
20
A:23BAS:BAGELSBAS:CHECKERSBAS:STARTREKBAS
21
A:TREKINSTBAS:MASTRMNDBAS:WEEKDAYBAS:PIPCOM
22
A:STATCOM:SUBMITCOM:XSUBCOM:ZORK1COM
23
A:ZORK1DAT
24
A>tb
25
26
27
28
Timerrunning.Elapsed:007.004s.
29
A>
Also ich korrigiere mich.. für 88 läuft das!! Nur im 168/328 Zweig
gibt es die angesprochenen Probleme..
Und von 7,589s auf 7,004s runter ;-) (30MHz)
Mea culpa.
Peter
Peter Sieg schrieb:> ok. Sorry.
Ich habe halt etwas länger suchen müssen. Alle "sinnvollen"
Kombinationen liefen bei mir. Mega328 mit 4-Bit ist bei mir nicht
sinnvoll, weil ich gerade keine Hardware dafür habe. ;-) Ob's durch den
Assembler läuft, teste ich aber trotzdem gelegentlich.
So wie im Anhang, müßte es jetzt gehen. Mit dieser Lösung bin ich aber
keinesfalls glücklich. Wer das ganze Paket mal in Form bringen will,
soll sich keinen Zwang antun...
Auf längere Sicht wird man bei den größeren Prozessoren nicht mehr ohne
absolute Sprünge auskommen. Die können ja nicht "hinten rum" springen,
wie der 8 oder 48.
> Und von 7,589s auf 7,004s runter ;-) (30MHz)
More to come... stay tuned.
Edit: sorry für die zip.zip Datei. Kann man so ein Versehen nicht wieder
löschen?
Horst S. schrieb:> und schnell die Tabelle gebaut. Gut das ich die in Excel verwalte.> Baust du das noch mit ein Leo? Danke.
Ist drin.
Im SVN und in dem Paket, das ich gerade gepostet habe.
Könnte Dein Excel-Exporter auch die Leerräume genau so formatieren, wie
ich es jetzt gemacht habe? Die Tab-Breite ist dabei auf 8 Eingestellt.
@Horst S.: Hänge es mal hier rein und sage was ich machen muß.. dann
kümmere ich mich morgen drum..
@Leo C.: 168 Zweig assembliert ohne Fehler und läuft auch. Prima!
Peter
Horst S. schrieb:> ich suche noch jemanden der die todo_tabs für die Z80-oopcodes füllt.> ist eine fleissarbeit, würde aber helfen.> hat jemand lust?
Gut, daß Du das selber hier reinstellst, ich wollte Deine E-Mail schon
umleiten. ;-)
Peter Sieg schrieb:> @Horst S.: Hänge es mal hier rein und sage was ich machen muß.. dann> kümmere ich mich morgen drum..
Das ist eine gute Frage. Mir ist das auch nicht klar. Das dürfte nämlich
sehr stark vom Interpreter abhängen, der ja auch noch nicht da ist.
Die wenigen Befehle, die in der jetztigen Tabelle fehlen, wird Horst
nicht meinen.
Für 0xDD und 0xFD braucht man imho gar keine Tabellen. Das sind
Umschaltprefixe für Befehle mit H, L, HL, (HL) als Operanden.
0xED ist nur schwach besetzt. Da wird man vielleicht eine irgendwie
komprimierte Tabelle machen.
CB ist sehr regelmäßig. Da kann man wahrscheinlich auch was machen, um
nicht eine 3 oder 4 mal 256 Byte Tabelle anlegen zu müssen.
Andererseits, wenn man mit größerem Prozessor mindestens 8KByte
zusätzlichen Tabellenplatz hat...
> @Leo C.: 168 Zweig assembliert ohne Fehler und läuft auch. Prima!
Danke fürs Testen.
Ist eigentlich recht einfach.
do_fetch_xxx ; woher kommen die daten LD ??,A = do_fetch_A
do_store_xxx ; wo sollen sie hin LD A,?? = do_store_A
im zweifelsfall einfach do_???? eintragen.
do_op_xxx ; hier steck die eigentliche finktion
im zweifelsfall bei do_op_xxxx einfach do_op_inv eintragen.
Danke Peter,
Schaut schon ganz gut aus.
Ich werde zum Wochenende mal eine Rohversion für den Z80 fertig machen
und an Leo senden.
Soll ich mal eine Beschreibung machen wie der Opcode-Interpreter nun
arbeitet?
Gruus Horst
Horst S. schrieb:> Soll ich mal eine Beschreibung machen wie der Opcode-Interpreter nun> arbeitet?
Aber immer und gerne!
Den Aufruf von Leo C. zur Dokuerstellung habe ich auch nicht vergessen..
nur
macht das erst Sinn, wenn das Projekt sich noch etwas mehr 'gesetzt'
hat.. z.Z ist noch viel zu viel im Umbruch (zum Besseren = Gut so!)..
Peter
-t3 heißt, dasß die Opcode-Tabelle von 4 auf 3 Byte je Eintrag reduziert
wurde. Spart 256 Byte Tabellenplatz, kostet aber 88 Byte zusätzlichen
Code für eine Sprungtabelle. Witzigerweise genau gleiche Laufzeit, wie
die 4-Byte Variante. Eine Optimierung ist mir dann aber noch
eingefallen. War eigentlich für die -t3-jmp Variante gedacht, dort aber
nicht anwendbar.;)
-t3-jmp: Statt push/return in der Interpreterschleife wird zwischen den
Phasen 'load', 'do_op' und 'store' direkt gesprungen. Kostet Platz, der
aber noch vorhanden ist.
Meinungen würden mich interessieren.
Peter Sieg schrieb:> Den Aufruf von Leo C. zur Dokuerstellung habe ich auch nicht vergessen..
Der (konstruktive) Vorschlag war von Jörg.
(Nach einer ironischen Bemerkung von mir zum Thema.)
Peter Sieg schrieb:> Hier noch der Rest, den ich soweit gefüllt habe..
@Peter, @Horst:
> do_op_ADC> do_op_SBC
Nach der bisherigen Nomenklatur müßten diese wohl do_op_ADCHL und
do_op_SBCHL heißen.
Aber in den DD/FD-Tabellen gibts ja auch noch IX und IY als
Zielregister.
Vorschlag:
op_ADDHL --> op_ADD16
op_ADC --> op_ADC16
op_SBC --> op_SBC16
Allgemeiner Vorschlag:
In den (Excel-) Tabellen grundsätzlich
1
do_fetch_xxx --> fetch_xxx
2
do_op_xxx --> op_xxx
3
do_store_xxx --> store_xxx
Das "do_" wird (nur) bei Bedarf über die Makros wieder zugefügt.
Moin moin,
Leo. schrieb:
< Meinungen würden mich interessieren.
Guter Trick das vom Stack in Register zu verlegen.
Damit bin ich bei meiner Frage die ich dir eigentlich zusammen mit der
Z80-Rohversion zusenden wollte.
Wie ist den nun die Registeraufteilung für den Z80?
Eigentlich wollte ich die neu festlegen und dort einiges aufräumen.
Die bestehende Áufteilung ist für den 8080 ja ok.
Kann man eigentlich noch Code in den DRAM-Routinen sparen?
Hier wird doch auch reichlich Zeit verbraten.
Gruss Horst
Horst S. schrieb:> Wie ist den nun die Registeraufteilung für den Z80?> Eigentlich wollte ich die neu festlegen und dort einiges aufräumen.
Sicher möglich. Als endgültig festgemauert sehe ich da noch nichts.
Die 2 Register, die ich für die serielle Schnittstelle reserviert habe,
kann man wahrscheinlich freischaufeln. Allerdings muß der RX-Code
unbedingt noch überarbeitet und getestet werden.
> Kann man eigentlich noch Code in den DRAM-Routinen sparen?> Hier wird doch auch reichlich Zeit verbraten.
Möchtest Du Code oder Zeit einsparen?
Ich weiß nicht, ob Du Dir die 8-Bit Version schon angeschaut hast, aber
dort habe ich massig Code gegen Zeit eingetauscht (Macros statt
Unterprogramme).
An unkritischen Stellen kann man sicher wieder Unterprogrammaufrufe
einbauen, und so etwas Flash einsparen, wenns eng wird.
Ansonsten ist die DRAM-Ecke ausgereizt. Imho. Jedenfalls mit den beiden
Hardwarevarianten, die wir jetzt haben.
Ach ja, in den DRAM-Routinen ist zur Zeit über die config-Datei ein (1)
"wait state" eingestellt. Bei schnellen RAMS kan man den weglassen. Das
sieht dann so aus:
Wegen der Makros spart das 46 Byte Flash. Geschwindigkeit brings aber
gar nicht so viel. Bei der Interpretervariante, die ich gerade teste,
hebt es aber den Speed-Faktor wieder über die magische 2 Mhz Marke. ;-)
Moin moin,
Leo C. schreib:
>Möchtest Du Code oder Zeit einsparen?
Zeit, das ist schliesslich Sinn und Zweg der Übung. Wie bekomme ich eine
möglichst schnelle Simulation der Ziel-CPU hin. Ob die RAM-Floppy 1 oder
2 Sekunden braucht ist mir da völlig egal.
Wenn wir dabei bleiben ATMega8 = 8080 und ATMega168 = Z80 hast du noch
reichlich Flash zum spielen. :-)
Wobei ich ja immer noch mit einem SRAM liebäugle.(Joe, wie wäre es?)
Wieviel Codes braust du eigentlich für einen normalen DRAM read/write?
Dann könnte man mal abschätzen ob das noch Tempo bringt.
Gruss Horst
Leo C. schrieb:> -t3-jmp: Statt push/return in der Interpreterschleife wird zwischen den> Phasen 'load', 'do_op' und 'store' direkt gesprungen. Kostet Platz, der> aber noch vorhanden ist.>> Meinungen würden mich interessieren.
My 2 cents:
Dank Joe G. sind ja die 4-bit HW Version 1 mit 168 AVR's ausgeliefert..
Wir haben also max. 16kb zur Verfügung.. das sieht bei z.Z ca. 6,5kb
also
noch nach 'reichlich' Luft aus.. (auch für den z80 Interpreter)..
Und ansonsten dient der 328 als 'letzte' Reserve..
Aber genauso wichtig wie speed ist die Übersichtlichkeit und
Verständlichkeit des Code!
Daraus folgt:
Speed vor kleinerem Code, solange Code übersichtlich und verständlich
bleibt.
Peter
Horst S. schrieb:> Wobei ich ja immer noch mit einem SRAM liebäugle.(Joe, wie wäre es?)
Zum 100000ten mal: Die Kombination SRAM und ATmega8 (48..328) macht
überhaupt keinen Sinn und ist ein völlig anderes Projekt. Lass Dich
nicht davon abhalten und mach einen neuen Thread auf.
Deine restlichen Fragen sind Durch einen einfach Blick in den Sourcecode
zu beantworten.
Down to 6,212s ;-)
BTW: Meldet sich immer noch mit Version 1.0..? Sollte man da nicht mal
den Zähler etwas höherstellen.. so 1.x und wenn z80 drin ist 2.x..
Was mögliche, künftige HW Redesigns angeht.. wurde schon mehrfach
angesprochen.. Jörg Wolfram hatte Überlegungen dazu.. aber mangels
Interesse (von möglichen Usern) diese nicht weiter verfolgt..
Ich schlage vor, insbesondere, da ja gerade die 8-bit Version erst
noch gebaut wird (von der 'Masse') ersteinmal hier an der vorhandenen
Basis weiter zu arbeiten.. dann mal sehen, was die Zukunft zu bringt..
Wichtiger als der Ram ist für mich ggf. I2C Hardware und deren
Einbindung
ins CP/M..
Peter
Ich habe mal wieder was neues ausprobiert. D.h., eigentlich habe ich nur
schon dagewesenes neu zusammengewürfelt.
| End Code Data Used | | [s] | [KHz]
-----------------+----------+------+------+-------+-----+-------+-------
letzte schnellste 0x001d00 5240 1434 6674 7424 1.366 2111
neu 0x001f00 6492 666 7158 7936 1.206 2391
Die Tabellen sind jetzt in Form von r/jmp/call/s von Data nach Code
gerutscht. Leider belegen sie so aber nochmal deutlich mehr Platz.
Peter Sieg schrieb:> Und ansonsten dient der 328 als 'letzte' Reserve..
Hier wollte ich jetzt hinschreiben, daß das hier das ideale Projekt für
den ATmega8 ist, weil der deutlich billiger ist, als seine Nachfolger.
Das scheint sich aber gerade zu ändern. Der 8 ist im Moment weder bei
CSD noch bei Reichelt lieferbar. Und CSD hat einen neuen Preis, der
deutlich über dem 88 liegt.
> Aber genauso wichtig wie speed ist die Übersichtlichkeit und> Verständlichkeit des Code!
An der Übersichtlichkeit hat sich imho bisher nichts geändert, da das
Interpreterprinzip ja immer noch das gleiche ist. Und wenns
unverständlich ist, liegst vielleicht nur an der Doku. ;-)
> BTW: Meldet sich immer noch mit Version 1.0..? Sollte man da nicht mal> den Zähler etwas höherstellen.. so 1.x und wenn z80 drin ist 2.x..
Bei mir gibts keine Versionen, nur Revisionen der einzelnen Dateien. ;)
Ich will schon seit längerem eine Funktion einbauen, die beim booten die
Revisionen der wichtigsten Teile anzeigt.
Vielleicht möchte ja jemand den "Releasemanager" spielen, und
ausgesuchte Revisionen als Version x.x.x taggen.
Leo C. schrieb:> Timer running. Elapsed: 003.988s.> A>
Ja, aber das ist 8-bit Dram ;-)
Warte mal bis ich auch meine 8-bit Version aufgebaut habe und den
direkt mitbestellten 40MHz Quarzosi draufgesteckt habe ;-) ;-)
Peter
Hallo,
das avrcpm ist inzwischen ja wirklich schnell genug, um Ladder zu
spielen. Vor ca. 25 Jahren war ich danach regelrecht süchtig. :-)
Die Configuration über LADCONF.COM funktioniert bei meinem Terminal
(minicom, VT-100/ANSI) nicht richtig. Deshalb habe ichs manuell
angepaßt, und in der Initialisierung auch den störenden Cursor
abgeschaltet. Mit dem "Programm" CURON.COM kann man den Cursor nach dem
Spielen wieder einschalten. Ich habe mal alles zusammen gepackt und
hier angehängt.
Ansonsten habe ich aus der 4-bit DRAM-Leseroutine nochmal 4 Taktzyklen
rausgequetscht. Aus der Schreibroutine leider nur einen. Das geht, weil
durch die Zusammenlegung mit der 8-Bit-Variante jetzt auch hier das
_255-Register vorhanden ist. Leider habe ich nicht ausprobiert, wie viel
das gebracht hat.
Dafür habe ich aber mal wieder eine Tabelle von der 8-bit Version:
[code]
--PUSH/POP-- --CALL/RET-- -----DEC----- Flash
[s] [MHz] [s] [MHz] [s] [MHz] [byte]
------------------------------------------------------------------
z80int 1.924 1.499 1.971 1.792 6.291 1.467 2426
8080int 1.732 1.665 1.831 1.861 5.911 1.561 2734
-t3 1.712 1.684 1.811 1.882 5.842 1.580 2564
-t3-jmp 1.367 2.109 1.466 2.325 4.707 1.961 2762
-jmp 1.206 2.391 1.281 2.660 3.988 2.314 3272
[code]
Unter DEC ist die Schleife von Peter. Ich habe dafür auch mal die
Taktzyklen gezählt, damit man die auch mal in ein Z80-Äquivalent
umrechnen kann. Unter MHz steht also jeweils die Frequenz, mit der ein
echter Z80 laufen müßte, um das gleiche Ergebnis wie mein 20MHz AVR zu
erzielen.
Unter Flash steht nur der Speicherverbrauch des Interpreters. Das
restliche Programm ist bei allen Zeilen gleich.
Leo C. schrieb:> Unter DEC ist die Schleife von Peter. Ich habe dafür auch mal die> Taktzyklen gezählt, damit man die auch mal in ein Z80-Äquivalent> umrechnen kann.
Jup. Wie viele Zyklen hast du denn gezählt?
Na, Ladder werde ich doch dann mal probieren.. ;-) Danke!
Gruß Peter
Peter Sieg schrieb:> C:\cpmtools\avr3\dram-4bit.inc(88): error: Relative branch out of reach
Hallo Peter,
Du könntest mal dieses hier versuchen:
http://cloudbase.homelinux.net/viewvc/avr-cpm/branches/modules/avrcpm/
Dort habe ich u.a. mal wieder alles so hingeschoben, daß alle Funktionen
mit relativen Sprüngen und Calls erreichbar sind. Bei mir kann ich
fehlerfrei übersetzen. Allerdings habe ich die 4-bit Version nicht
getestet.
Gestern Abend habe ich mal einen Wordstar 3.0 an das VT-100 Terminal
angepaßt. Da ich gerade ein CP/M Diskimage parat hatte, habe ich es mal
mit angehängt. In der Zip-Datei sind nur die Dateien. WS.COM ist der
angepasste Wordstar, und WSU.COM das Original.
Moin moin,
mal ein kleiner Zwischenbericht von der Fleißarbeit.
Alle Opcodes des Z80 aufgelöst, es sind etwas über 700.
Splitten der Tabellen fertig.
Paging der IX,IY Opcodes fertig.
CB Opcodes gehen alle.
ED Opcodes am debuggen.
Der Z80 hat parallel zu den 8080 Opcodes noch einige weitere.
Diese werden mittels Prefix , also voran gestelltem Opcode, eingeleitet.
Der Prefix CB leitet z.B. BIT Opcodes ein.
Der Prefix ED leitet z.B. IN/OUT und Block-Opcodes ein.
Diese können wie die 8080 Opcodes über Tabellen abgearbeitet werden.
Der Prefix DD leitet alle IX Opcodes ein.
Der Prefix FD leitet alle IY Opcodes ein.
In diesen Fällen werden die Opcodes die das HL Register verwenden so
umgebogen das nun das jeweilige I-Register verwendet wird.
In diesen Fällen ist es einfacher die Routinen für FETCH und STORE zu
ändern, den nur sie sind davon betroffen.
Alle zusammen passen in eine 256 Byte Page. Das Highbyte dieser Page
wird in main schon getrennt behandelt. Ich muss die geänderten Routinen
also nur auf getrennten Pages ablegen und kann dann bei den 8080 Opcodes
die gewünschte FETCH/STORE Page verwenden.
Ein Nachteil dieses Verfahrens ist das in diesen vier Fällen main
doppelt durchlaufen wird.
Der Vorteil ist das die Standart-Opcodes ohne zusätzlichen Zeitverlust
abgearbeitet werden.
Gruß Horst
Moin,
habe mal angefangen nach der Artikelbeschreibung ein diskimage
zu erstellen. Benutzt habe ich cpmtools für Windows. Die avrcpm
habe ich mit Notepad erstellt.
mkfs.cpm kommt mit einer Fehlermeldung:
unknown format avrcpm.
Was mache ich falsch?
Gruß
Peter
Peter Zabel schrieb:> zu erstellen. Benutzt habe ich cpmtools für Windows. Die avrcpm> habe ich mit Notepad erstellt.
Welche avrcpm meinst Du denn?
Die cpmtools sollten irgendwo eine Datei mit Diskdefinitionen haben.
Bei mir heißt diese Datei "diskdefs". Diese Datei muß man um einen
"avrcpm"-Eintrag erweitern:
1
diskdef avrcpm
2
seclen 128
3
tracks 77
4
sectrk 26
5
blocksize 1024
6
maxdir 64
7
skew 1
8
boottrk 2
9
os p2dos
10
end
> mkfs.cpm kommt mit einer Fehlermeldung:> unknown format avrcpm.> Was mache ich falsch?
Entweder findet Dein mkfs.cpm die Datei "diskdefs" nicht, oder in der
Datei fehlt der Eintrag "avrcpm". Wie die Datei unter Windows
normalerweise heißt, und wo sie dort liegen muß, kann ich Dir nicht
sagen.
Unter Windows heißt sie auch diskdefs und sollte im gleichen Verzeichnis
wie mkfs.cpm.exe liegen.
Wenn dd unter Windows später Probleme macht, dd mit Adminrechten
ausführen.
Joe
Die diskdefs liegt im gleichen Verzeichnis wie mkfs.cpm.exe
und ist um den Eintrag avrcpm erweitert. Trotzdem gibt
es die Fehlermeldung "unknown format avrcpm". Was kann es noch
sein?
Peter
OK, damit geht es, danke. In Deiner diskdefs sind nur 2 Formate.
Ich werde die originale mal abmagern, um mal zu sehen, woran
es liegt.
Ich habe noch eine Frage zu dd. Als output file steht dort
< sd card identifier >. Ist das das Linux device, wie eine
LiveCD die SD card finden würde, z.B. /dev/sde ?
Peter
PS: CSD hat Betriebsferien bis zum 04.09.
Mit dd --list kannst du dir alle deine Speichermedien anzeigen lassen.
Dann kopierst du einfach den entsprechenden Eintrag raus. Bei mir sieht
es z.B. so aus: of=\\?\Device\Harddisk5\Partition0
Bei Linux ist es einfacher, da ist es so wie du es schon beschrieben
hast.
Joe
Peter Zabel schrieb:> Die diskdefs liegt im gleichen Verzeichnis wie mkfs.cpm.exe> und ist um den Eintrag avrcpm erweitert. Trotzdem gibt> es die Fehlermeldung "unknown format avrcpm". Was kann es noch> sein?>> Peter
Jup.. da habe ich auch etwas gesucht ;-) Die Antwort ist so simpel wie
das Program doof ist.. Notepad fügt ein CR ans Ende der Zeile.. das
können
aber die cpmtools unter Windows gar nicht ab ;-)
Also:
1. Die cpmtools MÜSSEN unter X:\cpmtools liegen
2. Die diskdefs muß mit Unix Konvention als Zeilenende (nur LF) sein
Dann geht es.. garantiert..
Peter
Moin,
habe jetzt das diskimage auf die SD gebracht. Das dd aus den
UNIX-Tools für Windows kennt kein --list. Das dd 0.6beta3
von John Newbegin kennt zwar ein --list, bringt aber beim
Schreiben auf die SD immer eine Fehlermeldung:
Error reading file: 87 Falscher Parameter
19+1 records in
19+1 records out
unter Ubuntu war dann alles kein Problem
Peter
Ich kann nur wiederholen; Es wird mal Zeit für eine ordentliche
Dokumentation. Macht Mühe, aber erleichtert ungemein den Nachbau und
verhindert sinnloses doppelt, dreifach,..., probieren. Mein Vorschlag:
Einer nimmt sich dem Thema an, "Wie bringe ich ein CP/M System auf die
SD-Card - eine Anleitung Step by Step". Da unter Windows alles recht
bes**eiden geht, gleich eine Anleitung für Linux (Live CD).
Joe
Ich habe den Artikel mal mit entsprechenden Informationen angereichert..
In die grundsätzliche Bedienung eines Partitionierungstools muß man sich
aber selber und unabhängig einarbeiten!!
Ich hänge hier auch mal ein BDS-C Sourcearchive an, in dem Spiele und
unter
anderem auch Pacman enthalten ist.. ich habe z.Z wenig Zeit.. evtl. hat
ja mal jemand Zeit und Lust, das auch nach VT100 und unser System
umzusetzen..
sollten nur 3-4 Routinen sein (ClrSCR, PosXY,..)..
Peter
Peter Sieg schrieb:> sollten nur 3-4 Routinen sein (ClrSCR, PosXY,..)..
Ich habe mal reingeschaut, weil ich auch dachte, daß das ganz schnell
gemacht wäre. Leider gings nicht ganz so schnell, weil das Programm
direkt auf den UART-Port zugreift. Das wurde bisher von unserem System
noch nicht unterstützt. Wahrscheinlich hätte man den Pacman auch an die
BIOS Console-I/O anpassen können, aber ich habe es jetzt mal anders
herum gemacht.
Die Cursor-Steuerung habe ich mal auf die Tasten 2,4,6,8 (Ziffernblock)
gelegt.
Damit der Pacman aus dem Anhang läuft, muß man den ATmega updaten:
http://cloudbase.homelinux.net/viewvc/avr-cpm/branches/modules/avrcpm/avr/
Peter Zabel schrieb:> welchen Assembler ist sinnvoll, um die AVR asm Dateien> unter Windows zu übersetzen?
avrasm2.exe aus dem AVR Studio.
Gibts denn noch andere?
Ronny Minow schrieb:> ist evtl. noch ein bausatz zu haben? wenn ja, was kostet er?
Falls kein Bausatz mehr 'übrig' sein sollte.. die 4-bit Version kann man
sicher auch einfach auf Lochraster aufbauen.. ansonsten kann ich dir
4-bit
als fertig aufgebaute Platine (3,3V Versorgung - ohne FT232) anbieten.
Bei Interesse E-Mail: peter (dot) sieg2 (at) gmx (dot) de
Peter
Peter Sieg schrieb:> Ronny Minow schrieb:>> ist evtl. noch ein bausatz zu haben? wenn ja, was kostet er?>> Falls kein Bausatz mehr 'übrig' sein sollte.. die 4-bit Version kann man> sicher auch einfach auf Lochraster aufbauen.. ansonsten kann ich dir> 4-bit> als fertig aufgebaute Platine (3,3V Versorgung - ohne FT232) anbieten.> Bei Interesse E-Mail: peter (dot) sieg2 (at) gmx (dot) de>> Peter
wo finde ich den aktuellen schaltplan? ich habe hier 2 atmega32 frei.
der source dürfte wohl leicht anpassbar sein. hat das evtl. schon jemand
gemacht?
Im Artikel:
http://www.mikrocontroller.net/articles/AVR_CP/M
findest du Schaltplan+Eagle Dateien für die 4-bit Version.
hier auch als Skizze:
http://avr.cwsurf.de/
Die 8-bit Version findest du sicher etwas weiter oben in diesem Thread..
den du ruhig auch mal durchlesen solltest.. ;-)
Peter
Moin,
habe gerade beide Platinen aufgebaut. Danke an Joe für seine
Arbeit mit der Platine, den Bauteilen und dem Versand.
Allerdings habe ich noch nicht rausfinden können, wie
die Versorgung ohne USB-Power, sprich Versorgung von der
VGA-Platine geht. 5V für den Controller, 3,3V für die SD.
Gruss
Peter
Ich hatte drei Tage DSL Ausfall :-((
Zu euren Fragen:
@Peter1
Die RAM’s lassen sich wunderbar mit einer Heißluftpistole ablöten.
@Peter2
Variante 1 – Stromversorgung über VGA
1. Auf der VGA Platine natürlich den Gleichrichter und die beiden Regler
(5V und 3.3V) bestücken.
2. Am Power Switch Pin1, Pin2 und Pin3 verbinden.
3. Am JP13 (VGA-Seite) sollten nun an Pin1 GND, an Pin2 5V, und an Pin3
3.3V anliegen.
4. Auf der AVR-CP/M Platine JP7, Pin2 und Pin3 verbinden (3.3V von VGA)
Nun läuft der Controller auf der AVR CP/M und VGA Platine mit 5V und die
SD mit 3.3V
Variante 2a – Stromversorgung über USB (5V für AVR 3.3V für SD)
1. Auf der AVR-CP/M Platine JP1 Pin2 und Pin3 verbinden (5V über USB)
2. Auf der VGA Platine JP11 Pin2 und Pin3 verbinden (3.3V über
externen Regler auf VGA)
3. Auf der ACR-CP/M Platine JP7 Pin2 und Pin3 verbinden (3.3V auf SD).
Variante 2b – Stromversorgung über USB (3.3V für CP/M AVR und SD)
1. Auf der AVR-CP/M Platine JP1 Pin1 und Pin2 verbinden (3.3V über
FT232)
@Hans W.
Anbei die Schaltungsunterlagen als PDF und als EAGLE.
Die Software liegt bei Leo C. auf SVN. Ich selber habe die 8 Bit Version
noch nicht für den ATMEGA 168 übersetzt, könnten Peter oder Leo sicher
tun. Der VGA Software wende ich mich nach der Bestückung zu.
Kritik, Fehler in Schaltung und/oder Layout nehme ich natürlich auch
entgegen.
Joe
Moin moin,
Das ist noch ein fehler im Layout.
Der Pin14 des FT232RL muus nicht mit 10K an GND sondern an VCC.
In der Defaultversion ist das die PWREN# Funktion.
Ansonsten ist es an den DRAM arg eng zu löten. Die Durchkontaktiereungen
sind da etwas im weg. Sonst sind Platinen schon klasse für den Preis.
h3aau schrieb:> Das ist noch ein fehler im Layout.> Der Pin14 des FT232RL muus nicht mit 10K an GND sondern an VCC.
In der Tat! Ich ändere es in Schaltung und Layout. Für die jetzige
Funktion sollte es aber keine Auswirkungen haben, da die
Powerumschaltung per FET nicht genutzt wird.
Moin,
ich habe jetzt eine Verbindung zum Terminal, allerdings
bekomme ich folgende Meldung:
CPM on an AVR, v1.0
0F<00@FFFFM: fill...wait...reread...00<01@0100
Initing mmc...
CP/M partition at: 061, size: 993537KB.
Partinit done.
Ok, CPU is live!
H C A =00 BC =0000 DE =0000 HL =0000 SP =0000 PC =2000 30 01
12 Invali
d opcode!
DRAM Problem?
Gruss
Peter
Der nächste Schritt wäre ipl.bin ab Adresse 2000 zu starten. Dazu sollte
der Code vorher korrekt von der MMC geladen sein (mal MMC Debug zur
Kontrolle einschalten). Der Opcode 30 01 12 sieht nicht wie der Start
von ipl.bin aus.
Joe
moin Joe,
die cpm.bin ist aus dem Artikel.
Ich werde mal MMC Debug einschalten.
Zum Speichertest: Habe mal die Terminalausgabe mit
Hterm in hex mitgeschnitten. Bit0 ist 0, wenn es 1 sein
soll und 0 wenn es 1 sein soll. Die DRAMs sind
GM71C17400AJ6. Bei 20MHz gleiches Problem. Kann
es ein Timingproblem sein?
Gruss
Peter
Peter Zabel schrieb:> so sieht die Ausgabe von MMC-Debug aus:
MMC ist hier wahrscheinlich uninteressant.
> A =00 BC =0000 DE =0000 HL =0000 SP =0000 PC =2000 30 01> 12 Invalid opcode!
Nach laden des ipl sollte ab 2000 die Bytefolge 31 00 10 stehen (alles
Hex).
Bei Dir steht 30 01 und evtl. 12. Und 30 ist für den 8080 ein ungültiger
Opcode. Das passt gut zu Deinen Speichertestergebnissen. Wie Deine
Hardware es allerdings fertig bringt, ein Bit zwischen Lesen und
Schreiben zu invertieren, ist mir ein Rätsel. ;-)
Moin,
habe die Ausgabe vom Speichertest weiter untersucht.
Es ist nicht nur D0 betroffen, sondern auch D1, D2, D3.
Abhängig von der Adresse. Hat jemand ein funktionierendes
168er hex-file, 20 oder 25MHz zum testen für mich?
Meine fuses sind lf=0xE0, hf=0xDC.
Gruss
Peter
Halloe.
Ich schlage mich leider immer noch mit der Partinionierung meiner
SD-Card und dem aufbringen der Images rum. Die Idee, das ganze auf
eigene Partinionen zu packen klingt zwar recht nett, macht aber einen
riesenumstand für alle Windows-User.
Ich habe letzte nach extra einen "alten" PC platt gemacht um Linux drauf
zu spielen. Nun kämpfe ich mit der Hardwareerkennung von Linux. Seitdem
ich die SD-Card unter Linux neu partinioniert habe, wird sie beim
einstecken nicht mehr gefunden. Ich komme praktisch nicht mehr drauf.
Defekt ist die Karte wohl noch nicht, da Windows die eine FAT16
Partition die ich gelassen habe noch erkennt und nutzen kann.
Im moment überlege ich gerade, ob man das ganze nicht evtl. auf Dateien
in einem "sticknormalen" FAT16 umstellen könnte. Ich denke darüber nach,
die mit dem CPM-Tools angelegten images einfach mit einem bestimmten
Namen in das Root-Verzeichniss einer FAT16-Partition zu packen. Sowas
wie "diska.img", "diskb.img" .. usw. Und statt die Sektoren in den
Partitionen direkt anzusprechen, könnte man dann auf den Dateien
"rumrödeln".
Sollte ich die nächten Wochen mal Zeit dazu haben, werde ich mal
versuchen die bekannten FAT16-Treiber mit in den Source des CP/M
Projekts einzubinden. Leider ist meine Freizeit jedoch sehr beschränkt,
so das das bei mir ewig dauern könnte.
Freundliche Grüße
Frank
Peter Zabel schrieb:> habe die Ausgabe vom Speichertest weiter untersucht.> Es ist nicht nur D0 betroffen, sondern auch D1, D2, D3.> Abhängig von der Adresse.
Für mich sieht das nach einem Hardwarefehler aus.
Bitte Verdrahtung nochmal überprüfen.
Durchgang, Kurzschluß, A8-A10?
Hat Dein RAM evtl. doch eine A11?
Stromversorgung, Blockkondensatoren, ...
Kannst Du das RAM (testweise) mit 5V betreiben (evtl. SD-Karte ziehen)?
> Hat jemand ein funktionierendes> 168er hex-file, 20 oder 25MHz zum testen für mich?> Meine fuses sind lf=0xE0, hf=0xDC.
Andererseits:
Welche Hardware-/Softwarekombination hast Du überhaupt?
Software scheint ja die neueste aus dem "modules" Zweig zu sein. Die ist
mit der 4-Bit Hardware nicht besonders gut getestet.
Frank Zoll schrieb:> Halloe.>> Ich schlage mich leider immer noch mit der Partinionierung meiner> SD-Card und dem aufbringen der Images rum. Die Idee, das ganze auf> eigene Partinionen zu packen klingt zwar recht nett, macht aber einen> riesenumstand für alle Windows-User.
Für alle anderen aber nicht. :)
> Ich habe letzte nach extra einen "alten" PC platt gemacht um Linux drauf> zu spielen.
Einige hier kommen mit einer Linux Live-CD ganz gut zurecht.
> Nun kämpfe ich mit der Hardwareerkennung von Linux. Seitdem> ich die SD-Card unter Linux neu partinioniert habe, wird sie beim> einstecken nicht mehr gefunden. Ich komme praktisch nicht mehr drauf.
Gibt es irgendwelche Logeinträge?
(z.B. in '/var/log/syslog' oder '/var/log/kern.log')
> Defekt ist die Karte wohl noch nicht, da Windows die eine FAT16> Partition die ich gelassen habe noch erkennt und nutzen kann.>> Im moment überlege ich gerade, ob man das ganze nicht evtl. auf Dateien> in einem "sticknormalen" FAT16 umstellen könnte. Ich denke darüber nach,> die mit dem CPM-Tools angelegten images einfach mit einem bestimmten> Namen in das Root-Verzeichniss einer FAT16-Partition zu packen. Sowas> wie "diska.img", "diskb.img" .. usw. Und statt die Sektoren in den> Partitionen direkt anzusprechen, könnte man dann auf den Dateien> "rumrödeln".
Ja, das steht auch auf meiner todo-Liste. Aber ganz tief unten.
In´s 8K ROM paßt zwar kein FAT-Treiber mehr, aber das macht ja nichts.
> Sollte ich die nächten Wochen mal Zeit dazu haben, werde ich mal> versuchen die bekannten FAT16-Treiber mit in den Source des CP/M> Projekts einzubinden. Leider ist meine Freizeit jedoch sehr beschränkt,> so das das bei mir ewig dauern könnte.
Dann wünsche ich Dir (und uns) mal eine große Portion Freizeit. :)
Man kann auch immer noch auf Partitionierung verzichten, und ein
CP/M-Image direkt an den Anfang einer Speicherkarte schreiben. Wie das
unter Windows geht, wissen die Experten hier.
Moin,
Hardware ist die neue 8-Bit Platine.
Das DRAM hat A0 - A10.
Ich habe keine Verbindung zwischen A8,A9,A10 und
D0 - D4. Der 168er läuft mit 5V, die SD mit 3,3V.
Die Software habe ich am 31.08. runtergeladen.
Mein List-File sagt:
Including file 'C:\Programme\Atmel\AVR
Tools\AvrAssembler2\Appnotes\m168def.inc'
Including file 'D:\AVR_CPM-AVR\avr\config.inc'
Including file 'D:\AVR_CPM-AVR\avr\macros.inc'
Including file 'D:\AVR_CPM-AVR\avr\dram-8bit.inc'
Including file 'D:\AVR_CPM-AVR\avr\init.asm'
Including file 'D:\AVR_CPM-AVR\avr\mmc.asm'
Including file 'D:\AVR_CPM-AVR\avr\sw-uart.asm'
Including file 'D:\AVR_CPM-AVR\avr\dram-8bit.asm'
Including file 'D:\AVR_CPM-AVR\avr\remainders.asm'
Including file 'D:\AVR_CPM-AVR\avr\8080int-jmp.asm'
Gruss
Peter
Peter Zabel schrieb:> Moin,>> Hardware ist die neue 8-Bit Platine.> Das DRAM hat A0 - A10.> Ich habe keine Verbindung zwischen A8,A9,A10 und> D0 - D4. Der 168er läuft mit 5V, die SD mit 3,3V.
Ich habe den letzten, von Joe als pdf geposteten Schaltplan mit meinem
Aufbau verglichen. Ich habe keinen Unterschied gefunden. Das Layout
sollte mit diesem Plan ja übereinstimmen.
> Die Software habe ich am 31.08. runtergeladen.
Danach gibt es bisher nur Änderungen bei der mmc-Fehlerbehandlung. Die
Software läuft bei mit mit Mega8 und Mega328.
Läuft die Platine denn sonst schon bei jemandem? Joe?
Leo C. schrieb:>> Nun kämpfe ich mit der Hardwareerkennung von Linux. Seitdem>>> ich die SD-Card unter Linux neu partinioniert habe, wird sie beim>>> einstecken nicht mehr gefunden. Ich komme praktisch nicht mehr drauf.>>>> Gibt es irgendwelche Logeinträge?>> (z.B. in '/var/log/syslog' oder '/var/log/kern.log')
Ja, zu meinem leidwesen gibt es da welche die nicht gut klingen.
Wenn ich die SD- Card einlege wird sie noch erkannt. Er listet die größe
der Karte korrekt als 1GB Karte.
Danach zeigt der mir noch an, das es darauf 4 Partitionen gibt. (sdc:
sdc1 sdc2 sdc3 sdc4). Bis hier hin scheint er noch zu kommen.
sd 2:0:0:1 [sdc] 1958912 512-byte logical blocks: (1.00 GB/956 MiB)
sd 2:0:0:1 [sdc] Assuming drive cache: write through
sd 2:0:0:1 [sdc] Assuming drive cache: write through
sdc: sdc1 sdc2 sdc3 sdc4
Kurz darauf (ca. 2 Secunden abstand) kommt die Meldung:
usb 1-3: reset high speed USB device using ehci_hcd and address 2.
Gefolgt von:
sd 2:0:0:1 [sdc] Device not ready
sd 2:0:0:1 [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 2:0:0:1 [sdc] Sense Key : Not Ready [current]
sd 2:0:0:1 [sdc] Add. Sende: Medium not present
end_request: I/O error, dev sdc, sector 1958784
Buffer I/O error on device sdc, logical block 244848
sd 2:0:0:1 [sdc] Device not ready
sd 2:0:0:1 [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 2:0:0:1 [sdc] Sense Key : Not Ready [current]
sd 2:0:0:1 [sdc] Add. Sende: Medium not present
end_request: I/O error, dev sdc, sector 1958784
Buffer I/O error on device sdc, logical block 244848
sdc: detected capacity change from 1002962944 to 0
Danach bricht er den Versuch ab die Karte weiter an zu sprechen.
Habt ihr eine Idee, wie man die SD- Card unter Linux ( Suse 11.2 ) auf
einem alten AMD64 Shuttle PC wieder ans rennen bringen könnte ?
Unter WindowsXP läuft die Karte problemlos. Nur Linux zickt da rum.
Grüße
Frank
Könnt ihr mal einen Blick darauf werfen ?
Meine SD-Card konnte ich mitlerweile Partitionieren und mit den Images
befüllen. Leider klappt das Booten aber noch nicht.
Für mich sieht es so aus als ob die Karte die ersten Kommandos nocht
verarbeitet. Erst wenn versucht wird den ersten Sektor zu laden,
scheint die Karte nicht zu antworten.
Was meint ihr ?
Frank Zoll schrieb:> CT: 04 InitRes: 00 SPI_DISABLE
Karte ließ sich fehlerfrei initialisieren. Eine "SDC V2" Karte wurde
erkannt.
> mmcRdSect SPI_CLK_FAST> mmcCMD: 11 00000000 .. 01 CMDRes: 00 SPI_DISABLE RdSectRes: 01
-- -------- -- --
1 2 3 4
1, 2: Befehl "Read Single Block", Sector 0 wird an Karte gesendet.
3: Befehl wurde von der Karte aktzeptiert.
4: Karte hat innerhalb des Timeouts kein gültiges
'Data Token' (0xFE) gesendet.
Leider sieht man hier nicht, ob die Karte garnichts mehr gesendet hat,
oder ein Fehlertoken.
Du könntest mal MMC_DEBUG auf 3 setzen. Villeicht kommt man dann
dahinter.
Peter Zabel schrieb:
Funktioniert der RAM-Test bei Dir inzwischen fehlerfrei?
Wenn nicht, kannst Du den Rest hier vergessen.
> CP/M partition at: 061, size: 993537KB.> Partinit done.> mmcCMD: 11 00007A00 .. 01 CMDRes: 00> Ok, CPU is live!> ipl> DISK I/O: Invalid Function code: 01>> Demnach müsste IPL schon etwas geladen haben.
Das kann man so nicht sagen. Der ipl wird ohne Fehler von der Karte
geladen. Ob er danach korrekt im RAM steht, wissen wir nicht.
> Nur, was bedeutet diese Fehlermeldung?
Gültige Codes wären diese hier:
1
.equ READ_FUNC = 7
2
.equ WRITE_FUNC = 6
3
.equ BOOT_FUNC = 5
4
.equ HOME_FUNC = 4
Entweder läuft Dein IPL ins Nirwana (RAM-Fehler), oder IPL und BIOS
passen nicht zu Deiner AVR Programmversion. Letzteres müßte nicht
unbedingt an Dir liegen, da ich im SVN einiges an Chaos habe. Ich muß
mal dringend aufräumen.
Moin Leo,
ich habe auf LR ein 2.tes System aufgebaut. Das hat keine
Fehlermeldungen beim RAM-Test. Hast Du passende Dateien
für mich? Wäre doch schön die CP/M 2.2 Meldung auf dem
Terminal zu sehen.
Gruss
Peter
Hm komisch. Ich habe die Debugmeldungen mal umgestellt.
Es sieht so aus, als ob von der Karte immer nur High- Pegel zurück
gemeldet werden. In der Debug ausgabe steht bei allen Commandos FF. Ich
werde wohl mal schauen müssen, ob ich da noch irgendwo eine von diesen
viesen ungewollten Lötbrücken habe.
Peter Zabel schrieb:> ich habe auf LR ein 2.tes System aufgebaut. Das hat keine> Fehlermeldungen beim RAM-Test.
Gut.
> Hast Du passende Dateien> für mich? Wäre doch schön die CP/M 2.2 Meldung auf dem> Terminal zu sehen.
Im Anhang ist mal ein komplettes System mit ipl, ccp, bdos und bios.
Das kannst Du mit dd auf den Anfang der CP/M-Partition kopieren.
Moin Leo,
ok, das war es. Vielen Dank für die passende cpmsys.bin.
Passte wohl vorher nicht so zusammen. Werde mal anfangen,
Software draufzupacken.
Gruss
Peter
hallo ihr,
ich habe die lochraster version weitgehend aufgebaut. meine ram chips,
von meinen edo ram's, scheinen aber ungeeignet zu sein. laut den mir
vorliegenden schaltplänen kommen die signale an anderen pins herein.
ausserdem gehen die leiterbahnen über einen kleinen chip auf der platine
(signal koverter...?).
ob ein direkter anschluss möglich ist, oder ich diesen winzigen smd chip
(16 kontakte) brauche, weis ich nicht. daher einfach die frage:
wo bekomme ich passende ram chips her? idealer weise über reicheld und
im dip gehäuse. ausser, man kann diese auf lochraster gut löten, ohne
tiefergehende smd lötkenntnisse zu besitzen.
---
[edit] pinzahl korrigiert
Hallo,
hat einer schon die neue Platine in Gange? irgendwie finde ich nicht die
richtige Software. Das mit dem SVN ist der letzte Schrott, Dateien
lassen sich da nicht wirklich herunterladen.....
Gruß
Hans- Werner
Ronny Minow schrieb:> ich habe die lochraster version weitgehend aufgebaut. meine ram chips,> von meinen edo ram's, scheinen aber ungeeignet zu sein. laut den mir> vorliegenden schaltplänen kommen die signale an anderen pins herein.
Ich habs noch nicht getestet, aber prinzipiell müßten EDO's eigentlich
auch gehen.
Wie heißen Deine Chips denn genau?
> ausserdem gehen die leiterbahnen über einen kleinen chip auf der platine> (signal koverter...?).
Das sind wahrscheinlich Serienwiderstände.
> ob ein direkter anschluss möglich ist, oder ich diesen winzigen smd chip> (16 kontakte) brauche, weis ich nicht. daher einfach die frage:
Kann man weglassen.
> wo bekomme ich passende ram chips her? idealer weise über reicheld und> im dip gehäuse. ausser, man kann diese auf lochraster gut löten, ohne> tiefergehende smd lötkenntnisse zu besitzen.
Raketenwissenschaft ist's keine. Etwas Übung ist allerdings von Vorteil.
Dann kann mit die SOJ- und TSOP-Gehäuse ganz gut auf Lochraster löten,
wenn man die Pads vorher mit einem Messer in zwei Hälften teilt.
Hier hatte ich schon mal ein Bild gepostet:
Beitrag "Re: CP/M auf ATmega88"
Halloe.
Also ich bin einen kleinen Schritt weiter gekommen. Ich habe einfach
eine andere SD-Card genommen. Nun hänge ich am nächsten Schritt fest.
Dies sind die letzten Zeilen der Debug-Ausgabe:
1
mmcCMD: 11 35A56600 .. 01 CMDRes: 00
2
Ok, CPU is live!
3
4
ZHPNC A =DE BC =0000 DE =0000 HL =0000 SP =FFEF PC =2E32 CB CB CB Invali
5
d opcode!
Wenn ich das richtig interpretiere, hat das lesen des ersten Sektors der
Partition noch geklappt. Aber scheinbar stehen im RAM immer noch die
Code's CBCBCB vom RamTest. Scheinbar sind die Daten aus dem Sektor dort
nicht angekommen. Oder ?
Grüße
Frank
p.s. Wer meint das seine SD-Card auch nicht tut, der möge mal auf den
Hersteller schauen. Die Karten von "PLATINUM" machen wohl ziemliche
Probleme. Nun habe ich eine 1GB SD-Card von Verbatim am laufen. Die 1GB
Card von Platinum will mit dieser Hardwareversion nicht ans laufen
kommen.
Frank Zoll schrieb:> Halloe.>> Also ich bin einen kleinen Schritt weiter gekommen. Ich habe einfach> eine andere SD-Card genommen. Nun hänge ich am nächsten Schritt fest.>> Dies sind die letzten Zeilen der Debug-Ausgabe:>
1
> mmcCMD: 11 35A56600 .. 01 CMDRes: 00
2
> Ok, CPU is live!
3
>
4
> ZHPNC A =DE BC =0000 DE =0000 HL =0000 SP =FFEF PC =2E32 CB CB
5
> CB Invalid opcode!
> Wenn ich das richtig interpretiere, hat das lesen des ersten Sektors der> Partition noch geklappt. Aber scheinbar stehen im RAM immer noch die> Code's CBCBCB vom RamTest. Scheinbar sind die Daten aus dem Sektor dort> nicht angekommen. Oder ?
Der IPL wird auf 2000 bis 207F geladen. CB auf 2E32 ist also völlig in
Ordnung. ;-)
Warum der Prozessor dort hin springt kann wieder 2 Gründe haben:
1. RAM fehlerhaft. (unwahrschinlich, wenn RAM-Test ok)
2. IPL und/oder Rest auf den "Systemspuren" schrottig.
Vorschlag: System von obigem Artikel testen:
Beitrag "Re: CP/M auf ATmega88"
---
Gerade wollte ich auf "Absenden" drücken und sehe Deinen neuen Artikel:
Frank Zoll schrieb:> ZHPNC A =DE BC =0000 DE =0000 HL =0000 SP =FFEF PC =2000 30 0D> 1A Invalid opcode!
Das sieht dann aber doch nach einem Hardwarefehler aus.
Statt "30 0D 1A" sollte da "31 00 10" stehen.
Frank Zoll schrieb:> mmcCMD: 11 35A56600 .. 01 CMDRes: 00
********
Diese Zahl erscheint mir reichlich groß. Kannst Du mal die vollständigen
Bootmeldungen posten (Mit oder ohne MMC_DEBUG)?
Deine Partitionstabelle würde mich auch interessieren. Unter Linux wäre
das:
Juhu, freu es tut zum ersten mal :-)
Als letzten Fehler war eine der Adressleitungen nicht richtig
angeschlossen. Nun läufts mit der neuen Platine auch einwandfrei.
Als Prozessor habe ich den Atmega168 genommen. Sourcen stammen aus dem
SVN. Habe es nun erfolgreich mit dem AVR Studio Compiliert und
installiert bekommen. Habe mir einfach ein kleines neues Projekt
angelegt, die Sourcen reingeworfen und die Config auf 8bit und 168er
Atmega angepasst.
Als Betriebssystem auf der SD-Card hab ich die oben als letztes gelinkte
Version genommen.
1
CPM on an AVR, v1.0
2
Testing RAM: fill...wait...reread...
3
Initing mmc...
4
CP/M partition at: 1757875, size: 9765KB.
5
CP/M partition at: 1777406, size: 9765KB.
6
CP/M partition at: 1796937, size: 73464KB.
7
Partinit done.
8
Ok, CPU is live!
9
10
ipl
11
62k cp/m vers 2.2
12
13
A>dir
14
A: ASM COM : DDT COM : DUMP COM : ED COM
15
A: T COM : TLOOP COM : LOAD COM : MBASIC COM
16
A: 23 BAS : BAGELS BAS : CHECKERS BAS : STARTREK BAS
17
A: TREKINST BAS : MASTRMND BAS : WEEKDAY BAS : PIP COM
Frank Zoll schrieb:> Juhu, freu es tut zum ersten mal :-)
Herzlichen Glückwunsch und Willkommen im Club.
> angeschlossen. Nun läufts mit der neuen Platine auch einwandfrei.
Das ist ja mal 'ne Aussage.
> CP/M partition at: 1757875, size: 9765KB.
*******
Das sieht auch viel besser aus als 900032000 (= 0x35A56600).
> Vielen Dank für eure Hilfe.
Wir freuen uns jetzt auf den FAT16-Treiber. :-)
Hat jemand 4 Ramchips ***ausgelötet*** über?
Wollte mich die nächsten Tage mal an einen 8-bit Lochrasteraufbau
wagen..
(Ich weiß, das 2 auch reichen.. aber bei smd + LR besser Reserve;
Und meine Platine habe ich an einen weiteren, neuen Mitstreiter
abgetreten)
Peter
Leo C. schrieb:> Wir freuen uns jetzt auf den FAT16-Treiber. :-)
Hihi,
ich auch. Ich habe mir gestern Nacht schonmal ein wenig den Kopf darüber
zerbrochen. Soweit ich das einschätze wird es möglich sein. Ich habe
eine neue FAT16.asm Datei angelegt und schonmal angefangen die ersten
FAT16 Implementierungen vorzubereiten.
Zum aktuellen Stand:
- Eine FAT16 Partition wird bereits erkannt.
- Der BootSektor der FAT16 Partition wird bereits erfolgreich gelesen.
Nächste Schritte:
- Finden und Auswerten des Root-Verzeichnisses.
- Zuordnung gefundener Images auf die bestehenden Laufwerke A: bis D:.
- Finderoutine für das Auffinden beliebieger Sektoren über die
FAT-Einträge in den Image-Dateien
- Read/Write des gefundenen Sektors über die bestehenden MMC-Routinen
anbinden.
Ich werde mit einem sehr stark eingeschränkten FAT16 Treiber die Sache
wohl ans laufen bringen.
Folgende Eckdaten denke ich lassen sich erreichen:
- Es wird eine FAT16 Partition vorausgesetzt.
- In der FAT16 Partition wird es ein Paar Dateien geben, die die
einzelnen CP/M Partitionen darstellen werden.
- Die Image- Dateien müssen im ROOT- Verzeichniss der FAT16 Partition
angelegt werden.
- Die Image- Dateien werden sich nicht auf dem AVR-CP/M anlegen lassen.
So spare ich mir die Implementierung von "create_file"- Funktionen. (Da
sehr Umständlich)
- Die Namen für die Image- Dateien werden wir im Code fest hinterlegen.
- Die Größe der Image-Dateien kann nicht dynamisch geändert werden. Die
Images müssen praktisch von anfang an die volle Größe einer CP/M -
Partition abbilden.
- Die Performance wird gegenüber den direkten CP/M Partionen stark
leiden. Bei jedem Sektorzugriff muss dieser erst umständlich in der
jeweiligen Image-Datei gesucht werden. ( Juhu Retro like nix schnelle
:-) )
- Schreiben und Lesen einzelner Sektoren der Image-Dateien wird
funktionieren.
- Ich verwende den Pufferspeicherblock, der schon für das
Lesen/Schreiben der CP/M Partitionen verwendet wird einfach wieder. Ich
brauche ein paar zusätzliche Bytes, für die wichtigsten Variablen ausm
FAT16 System. Ich werde mit den derzeit noch verbliebenen knapp 100
Bytes SRAM eines 168AVR's wohl hinkommen. ( Ein paar Bytes werde ich
noch überlassen :-) )
- Ich mache die FAT16 Implementierung speziel für dieses Projekt neu, um
so viel Speicher und Resourcen wie nur irgend geht einzusparen.
- Ich versuche das ganze "unauffällig" in den bestehenden Code
einzufügen. Am Ende wäre das Ziel das man gleichzeitig mit FAT16 und
CP/M Partitionen arbeiten kann.
Grüße
Frank
Hallo,
heute bin ich endlich dazu gekommen die Software in den 168er zu
flashen.
Hardware ist das neue Board. Leider hängt es schon beim reread des Ram:
CPM on an AVR, v1.0
01<38@0139M: fill...wait...reread...F0<00@0000
nach einem Reset:
CPM on an AVR, v1.0
Fô<83@0083M: fill...wait...reread...F0<00@0000
hat jemand eine Idee??
die vorderen Zeichen wechseln ständig???
Ram Fehler?
Gruß
Hans- Werner
Hallo hschuetz,
leider kenne ich mich mit diesem Projekt nicht gut aus und weiß daher
nicht, ob hier Interrupts verwendet werden.
Falls ja, stellt sich die Frage, ob die von dir genutzte Firmware an den
168 angepasst wurde. Der reserviert nämlich doppelt so viel Speicher für
jeden Vektor in der Tabelle. Trotz großer Ähnlichkeit wird eine
atmega88-Version daher nicht ohne Änderung auf einem 168 laufen.
Gruß, DetlevT
Leo C. schrieb:> Ich habs noch nicht getestet, aber prinzipiell müßten EDO's eigentlich> auch gehen.> Wie heißen Deine Chips denn genau?
Ich habe in mein Archiv noch einmal nachgeschaut und Edo Ram Riegel mit
folgenden Chips gefunden:
* MSC 9618 C USA - MT 4C4001JDJ - 6
* OKI - M5I4400C-60SJ - 53825229A9Z
* Samsung - 447Y - KM44C100CJ - 7
* IBM - 014400J1F - 60 50H6697 - IBM 9370 - 625110500 Q
* MSC 9638 C USA - MT 4C4007JDJ - 6
Ich habe einfach mal alle Ziffern auf den Chips abgetippt, da ich nicht
weis, welche Ziffern entscheident sind...
Detlev T. schrieb:> leider kenne ich mich mit diesem Projekt nicht gut aus und weiß daher> nicht, ob hier Interrupts verwendet werden.
Aber wenn Du nur 4 Artikel weiter nach oben geschaut hättest, hättest Du
sehen können, daß gerade jemand mit Mega168 Erfolg gemeldet hat.
> Falls ja, stellt sich die Frage, ob die von dir genutzte Firmware an den> 168 angepasst wurde. Der reserviert nämlich doppelt so viel Speicher für> jeden Vektor in der Tabelle. Trotz großer Ähnlichkeit wird eine> atmega88-Version daher nicht ohne Änderung auf einem 168 laufen.
Joe G. hat von Anfang an einen 168, und ich bastle mit einem Mega8 und
einem Mega328 rum.