Hi.
Wollte mal auf diese Projekt aufmerksam machen:
http://spritesmods.com/?art=avrcpm
Dort wurde ein ATmega88, ein 256kx4 DRam-chip und eine SD Karte zusammen
geschaltet, um über einen 8080 Emulator letzlich CP/M 2.2 von der SD
Karte zu booten!
Ich dachte erst.. das kann doch nicht sein.. und hielt das für einen
Aprilscherz.. aber er funktioniert wirklich! Siehe:
http://avr.cwsurf (dot) de/?AVR_CP%2FM
Es wäre wunderbar, wenn sich hierfür noch mehr Leute begeistern könnten
und
1. Schauen, welche 8080 CP/M Programme jetzt auch schon laufen.. also
ggf.
erweiterte diskimage's erstellen und testen.. BTW: MBASIC steigt mit
einem
fehlenden Opcode aus.. ZORK läuft! Prima wären ein paar Spiele z.B
Sargon
Schach etc...
2. Versuchen den AVR Assemblersource zu erweitern (mehr opcodes/Z80).
Peter
Ich hatte selbst schon mal mit einem Z80-Emulator und externem DRAM an
einem Mega644 angefangen. Mit allen möglichen "Tricks" kommt man so auf
maximal 2MHz beim emulierten Z80, mit zusätzlicher Videoausgabe-Routine
und PS2-Tastatur wurde das Ganze eigentlich unbrauchbar.
Für eine bessere Emulation würde ich auf jeden Fall einen größeren µC
nehmen und für schnelleren Speicherzugriff diesen mit 8 Bits
anschließen.
Ansonsten finde ich die Idee nicht schlecht.
Jörg
Peter Sieg schrieb:> Dort wurde ein ATmega88, ein 256kx4 DRam-chip und eine SD Karte zusammen> geschaltet, um über einen 8080 Emulator letzlich CP/M 2.2 von der SD> Karte zu booten!
Hallo Peter,
du meinst doch sicher 2 Chips mit 4bit-RAM - einen Z80 auf einer
4bit-Architektur zu emulieren wäre schon Tierquälerei, obwohl natürlich
im Prinzip alles geht, auch eine Turingmaschine als Z80.
Ich habe zwar tatsächlich noch Quasi-CP/M-Systeme im Einsatz (der
Prozessor glaubt zumindest an CP/M), aber trotzdem die Frage, was soll's
- es gibt genügend Z80 und CP/M Systeme auf dem PC, und schliesslich
gibts ja den Z80 auch noch.
Gruss Reinhard
Reinhard Kern schrieb:> Peter Sieg schrieb:>> Dort wurde ein ATmega88, ein 256kx4 DRam-chip und eine SD Karte zusammen>> geschaltet, um über einen 8080 Emulator letzlich CP/M 2.2 von der SD>> Karte zu booten!>> Hallo Peter,>> du meinst doch sicher 2 Chips mit 4bit-RAM - einen Z80 auf einer> 4bit-Architektur zu emulieren
Perverserweise hat er tatsächlich nur einen RAM Chip benutzt. Was soll
ein Z80 auch mit 256kB anfangen :-)
(Kann den Link nicht direkt posten, Das (dot) gegen einen . austauschen.
Ja der Link sieht ansonsten wirklich so seltsam aus
http://avr.cwsurf (dot) de/?AVR_CP%2FM
Alle Speicherzugriffe ins REM werden über Nibbles abgehandelt
Wie die Befehlsdekodierung und Ausführung gemacht wurde: Finde ich
clever gelöst
Jup. Nur 1 DRam a 256kx4. Ein Byte wird als 2xNibble geschrieben und
wieder gelesen..
Selbst ich als Assembler Noob finde den Quelltext gut lesbar und
strukturiert..
Warum? Weil es geht! Und weil es Spaß macht zu zeigen, das es geht..
Und weil ein ATmega88 ca. 3€ kostet, eine solches DRam gibts in der
Schrottkiste (sind z.B beim Amiga 500 verwendet worden..) also alles
für ca. 6-8€..
Ich persönlich finde die aktuelle Geschwindigkeit gar nicht soo
schlecht!
Läuft aktuell mit 20MHz. Für SwinSID sind die 88er aktuell sogar mit 32
und 40MHz übertaktet.. also noch eine Option.. ohne Hardware und (fast)
Softwareanpassungen..
Für mich wäre die erste Priorität die Kompatibilität zu erhöhen, indem
mehr
Opcodes unterstützt werden.. Wäre doch was, wenn MBASIC und Sargon Chess
darauf laufen würden (Sargon habe ich noch nicht getestet)..
BTW: Mit der seriellen Anbindung bin ich prima zufrieden.. ich möchte
gar
keine TV/BAS und PS/2 Anschluß.. (trotzdem ist AVR Chipbasic ein prima
Projekt!!)
Nur CP/M ist hat schon was.. Turbo Pascal, Wordstar, dBase II.. ;-)
Peter
Ja, man könnte dann endlich die ATMegas als echte Computer verwenden.
Nur schade, dass CP/M mindestens 16 Kilobyte RAM erfordert, sonst könnte
man das ja komplett auf dem Mikrocontroller laufen lassen.
Man könnte sich da vielleicht sogar noch eine Art Bussystem,
beispielsweise auf Basis des I^2C überlegen, über den man dann
Peripheriegeräte anschließen kann. Die könnte man dann dem
Betriebssystem als Block oder Zeichengeräte darbieten.
Hallo
ist akademisch interessant, aber: CP/M war vor 25 Jahren. ( Habe selbst
unter CP/M meine Diplomarbeit geschrieben und Programme für mein Diplom
geschrieben. ) UNIX und VMS gab es damals auch schon. CP/M jetzt auf
einem AVR zu emulieren und als Betriebssystem zu verwenden ist "schräg".
Ein Linux auf einem AVR ist da wohl eher angesagt.
karadur schrieb:> Ein Linux auf einem AVR ist da wohl eher angesagt.
Der Linux-Kernel braucht so mindestens 4-8 Megabytes an Speicher. Ich
glaube, das wird aber dann auch zu langsam.
>> Ein Linux auf einem AVR ist da wohl eher angesagt.>Der Linux-Kernel braucht so mindestens 4-8 Megabytes an Speicher. Ich>glaube, das wird aber dann auch zu langsam.
... und eine MMU, FPU von Vorteil, 32 Bit Arch. (16 wüde gehen), und
und und
Ja, solche klein-Unixe gibts einige. Hätte man jedoch CP/M, so hätte man
erstmal eine Plattform auf der man aufbauen kann.
Natürlich könnte man sich auch überlegen, auf dem Atmel selbst ein
Dateisystem im Flash aufzubauen, aus dem man dann nativ Code ausführen
könnte. Aber das ist eventuell mehr Arbeit als solch ein Emulator und
weniger flexibel.
Karl heinz Buchegger schrieb:> Perverserweise hat er tatsächlich nur einen RAM Chip benutzt. Was soll> ein Z80 auch mit 256kB anfangen :-)
viel: program overlays habe ich ausgiebig benutzt und die kann man auch
mit page switching einblenden statt nachzuladen, geht viel schneller.
Und wenn man 4bit-Nibbles laden kann, dann kann man auch Daten aus einem
MB-grossen RAM laden.
Eine Steuerungssoftware von mir hatte 30 Overlays und hätte daher auf 30
RAM-Pages a 32 kB laufen können.
Unterschätzt den Z80 nicht, da konnte man auch schon richtige Computer
damit bauen.
Gruss Reinhard
Hallo
es gab auch CP/M 3.0. Damit konnte man dank MMU mit einem Z80 sehr viel
mehr Speicher verwalten. Ganz zu schweigen von CP/M86 und CP/M68k.
Und: die eZ80 sind auch nicht ohne.
PS: Auf meinem 8MHz Z80 CP/M war Turbopascal deutlich schneller als auf
einem IBM XT.
Und: etwas was ich sehr vermisse. Dank Epromfloppy war der Rechner
schneller gestartet als das die Bildröhre warm war.
Also nen Linux auf nem AVR emulieren dürfte denke ich scheitern.
Aber das CP/M mit emulierter Z80 ... Schon echt ne geniale Sache.
@reinhard
>Unterschätzt den Z80 nicht, da konnte man auch schon richtige Computer>damit bauen.
Das ist wohl auch der Grund warum es so viele Computer auf Z80-Basis gab
:-)
Mal im Ernst. Immerhin hat die ganze Computerei ja mit dem 4004
angefangen (wenn man man den Zuse, IBM, Leibnitz und Babbage außen vor
lässt :-)
Und nen Z80 auf nem AVR emulieren, und "nebenbei" noch das DRAM handlen
...
Respekt.
Wenn ich damals mal was mit CP/M gemacht hätte würd ich dieses Projekt
auf jedenfall nachbauen. Retro mit neuen mitteln find ich immer witzig.
Genauso wie den SwinSID. Schon echt klasse so Projekte. Weiter so :-)
Rene Böllhoff schrieb:> Also nen Linux auf nem AVR emulieren dürfte denke ich scheitern.
Nicht wirklich, wäre nur zu langsam. Wer eine Z80 simulieren kann, der
kann auch eine PDP-11 simulieren. Wird allerdings nicht brandschnell
sein.
> Mal im Ernst. Immerhin hat die ganze Computerei ja mit dem 4004> angefangen (wenn man man den Zuse, IBM, Leibnitz und Babbage außen vor> lässt :-)
Autos gibt's auch erst seit dem VM-Käfer, wenn man mal die zig anderen
älteren Hersteller aussen vor lässt ;-).
Mit dem 4004 haben die Mikrocomputer angefangen. Nicht die Computer.
Naja, bis zum 8080 galten solche Mikroprozessoren aber eher als was für
Steuerungen, ähnlich wie heute die Mikrocontroller.
Naja, aber im Emulator könnte man richtig viel machen. Man könnte zum
Beispiel virtuelle Hardwareeinheiten machen, welche dann rechenintensive
Operationen übernehmen. Damit könnte man sicherlich bis fast zur nativen
Geschwindigkeit der AVRs kommen.
>Autos gibt's auch erst seit dem VM-Käfer, wenn man mal die zig anderen>älteren Hersteller aussen vor lässt ;-).
Hast schon recht :-)
Aber ich denke mit dem 6502 und dem Z80 wurde die Computerei auch für
Hobbybastler möglich bzw die Verbreitung hat damit erst Einzug gehalten.
Trotzdem schon echt erstaunlich wie sich das alles entwickelt hat ...
Vor allem in den letzten 30 Jahren.
Christian Berger schrieb:> Naja, bis zum 8080 galten solche Mikroprozessoren aber eher als was für> Steuerungen, ähnlich wie heute die Mikrocontroller.
D'accord, solange du das "Mikro" nicht vergisst, wie Rene das tat.
Rene Böllhoff schrieb:> Trotzdem schon echt erstaunlich wie sich das alles entwickelt hat ...> Vor allem in den letzten 30 Jahren.
Davor war's im Entwicklungstempo auch nicht übel. Noch 1969 wurden
(manche) Computer aus Myriaden von Einzeltransistoren aufgebaut, z.B.
der für viele Jahre schnellste Computer CDC7600. Die (fast)
vollintegrierte 8080 kam mit ihren 6000 Transistoren auf dem Chip grad
mal 5 Jahre später raus (und war natürlich viele Grössenordnungen
langsamer).
>Davor war's im Entwicklungstempo auch nicht übel.
Schon richtig. Aber so richtig Einzug hat der Mikroprozessor ja erst
gefunden nachdem die Bauform nicht mehr in Turnhallen-Einheiten gemessen
wurde :-)
Aber die Miniaturisierung hat ja auch nichts mit den Konzepten von
damals zu tun. Die Prinzipien gelten ja sogar heute noch. Selbst wenn
sich in der Integration und der Ausführungs-Geschwindigkeit extrem viel
getan hat.
Rene Böllhoff schrieb:> Schon richtig. Aber so richtig Einzug hat der Mikroprozessor ja erst> gefunden nachdem die Bauform nicht mehr in Turnhallen-Einheiten gemessen> wurde :-)
Sachte - es gab ab Mitte der 50er einen Röhren(!)rechner, der grad mal 2
klassische Bauernschränke gross war und nur um die 2 Tonnen wog (*), I/O
extra. Das Ding war ziemlich verbreitet (>2000 Stück). So ne Art
Minicomputer der Röhrenära.
*: Ein Schrank für den Computer selbst, einer für die Stromversorgung.
Bei einem vor 10 Jahren gängigen Disk-System der besseren Kategorie war
die Basiseinheit einen solchen Schrank gross und wog grob eine Tonne. In
dieser Hinsicht hat sich also wenig geändert, nur die Stromversorgung
kriegt man dank Schaltnetzteiltechnik heute kleiner hin ;-).
>In dieser Hinsicht hat sich also wenig geändert ;-).
Wenn mans genau nimmt ist das ja auch ein Rückschritt gegenüber damals.
Die Groß/Superrechner von heute geben sich mit einem Schrank ja nicht
zufrieden, die wollen ja nach wie vor in Turnhalleneinheiten gerechnet
werden :-))
Das sich die Rechenleistung versechsfacht hat lassen wir mal unter den
Tisch fallen :))
Ups ... meinte : ver-zehn-hoch-sechs-oder-was-weiß-ich-sich-was-facht
:))
Aber dennoch sehr Interessant wie sich das alles entwickelt hab. Les im
Moment viel über die "alte" Technik. Vor allem würd mich mal
interessieren wie Zuse es geschafft hat mit Mechanik Fließkommazahlen zu
Rechnen. Bin ja gerad mal froh das ich das Floating-Point-Prinzip
verstehe :-))
Rene Böllhoff schrieb:> Wenn mans genau nimmt ist das ja auch ein Rückschritt gegenüber damals.> Die Groß/Superrechner von heute geben sich mit einem Schrank ja nicht> zufrieden, die wollen ja nach wie vor in Turnhalleneinheiten gerechnet> werden :-))
Es fing mit Saalgrösse an, und heute baut mal riesige Betonhallen um
diese Rechner drum herum. Aber zwischendrin gab es mal eine Zeit, in der
die schnellste verfügbare Rechentechnik in ein Kinderzimmer reinpasste.
Solange man das nämlich mit schnellen Einzelrechnern statt zigtausend
Nodes machte spielte die Verbindungslänge eine zunehmend dominante
Rolle, daher mussten die Dinger schrumpfen (Cray 1 und folgende).
> Aber dennoch sehr Interessant wie sich das alles entwickelt hab. Les im> Moment viel über die "alte" Technik.
Kennst du das Thornton-Buch (PDF) über die CDC6600? Ungemein
detailliert, bis auf Gatter/Transistorebene runter.
Peter Sieg schrieb:> Es wäre wunderbar, wenn sich hierfür noch mehr Leute begeistern könnten
Ihr habt doch ein Rad ab! Sorry, aber das musste ich einfach loswerden.
Ein EZ80F91AZA mit 50 MHz kostet bei Digikey etwa 10 Euro, bei RS etwa 7
Euro, hat 256k Flash eingebaut, hat Ethernet und noch einiges mehr an
Peripherie (2 UART, i2c, SPI, RTC, 32 GPIOs, ...) und ist zu 100%
software-kompatibel zum alten Z80. Du kannst sogar CP/M 3.0
Bankswitching machen, das Teil hat selber die entsprechende Logik dafür.
Du brauchst nur noch RAM anzuschließen. Ein 512k SRAM kostet bei RS 5
Euro. Also auch nicht die Welt. /CS macht der Controller selber, Daten-
und Adressbus und /RD und /WR werdet ihr auch wohl richtig anschließen
können.
Was soll das also? Modernes Flagellantentum?
PS:
http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProductDetails&familyId=130&productId=EZ80F91AZA
fchk
Frank K. schrieb:> Ihr habt doch ein Rad ab!
Eindeutig ja. Und?
> Ein EZ80F91AZA mit 50 MHz kostet bei Digikey etwa 10 Euro, bei RS etwa 7> Euro, hat 256k Flash eingebaut, hat Ethernet und noch einiges mehr
Meinst du wirklich, es ginge hier darum, auf möglichst effiziente Weise
Z80-Programme laufen zu lassen?
> Was soll das also? Modernes Flagellantentum?
Noch nie jemanden an einem 50 Jahre alten Motorrad basteln gesehen? Das
macht der bestimmt nicht um von A nach B zu kommen.
>> Es wäre wunderbar, wenn sich hierfür noch mehr Leute begeistern könnten>Ihr habt doch ein Rad ab! Sorry, aber das musste ich einfach loswerden.>Ein EZ80F91AZA mit 50 MHz kostet bei Digikey etwa 10 Euro, bei RS etwa 7>....
Du bist zu eingefahren: Du gehst von falschen Anforderungen aus. Du
gehst davon aus, dass jedes Problem haufenweise Rechenpower, Speicher
und viel Peripherie benötigt. Wer sagt, denn, dass es so sein muss?
Wenn das System nicht schnell sein muss, kommst du preislich mit den von
Dir aufgezählten Bauteilen nicht hin. Außerdem muss Du für Deine
Bauteile eine Platine fertigen lassen. Das geht mit dem Atmega88 auch
ohne. In Ingenieursstunden gerechnet, wäre Deine Lösung mit Sicherheit
überteuert.
Hallo
nu übertreibt es nicht! Es gibt Dinge die man einfach aus Interesse oder
Spass macht. Die Idee mit einem AVR einen 8080 zu emulieren ist ja toll.
Stefan schrieb:> Wenn das System nicht schnell sein muss, kommst du preislich mit den von> Dir aufgezählten Bauteilen nicht hin. Außerdem muss Du für Deine> Bauteile eine Platine fertigen lassen. Das geht mit dem Atmega88 auch> ohne. In Ingenieursstunden gerechnet, wäre Deine Lösung mit Sicherheit> überteuert.
Eben nicht. Der wesentliche Aufwand, nämlich die CPU-Emulation entfällt.
Heißt also: Ich muss nur das CP/M BIOS anpassen, aber das müsst Ihr
auch. Das BDOS ist ja überall gleich und wird ja als Objektfile
dazugelinkt. Und selbst ein 3.0'er BIOS hat nur verhältnismäßig wenige
Funktionen. Hab ich anno 87 schon mal gemacht, als ich noch jung und
hybsch war.
Und zum Bauteileaufwand: Gut, der Chip ist ein 144'er LQFP. Also
Adapterplatine, damits aufn Lochraster paßt. Das ist auch die einzige
Hürde. RAM im DIL-Gehäuse, 3.3V Vcc, kann man direkt anklemmen, ist kein
Hexenwerk. Ein Quarz oder Oszillator (braucht Ihr auch), Spannungsregler
(braucht Ihr auch), RS232-Pegelwandler (braucht Ihr auch), und eine
Handvoll R's und C's zum abblocken und als Lastkapazität für den Quarz
und als Pullups.
Mehr braucht der EZ80F91 nicht, um hochzukommen.
RTC gewünscht? OK, noch ein 32 kHz Uhrenquarz plus 2 C's und 1 R dazu.
SD-Karte? OK, ab an den SPI-Port. Kennt Ihr ja, ist hier auch nicht
anders.
Wenn man kein Ethernet braucht, dann wars das. Wirklich! Ich habe
Eval-Board, Prozessormodule und ZDI(Zilog 2-Draht JTAG
Variante)-Debugger und die ganze Doku und Software da, ich weiss, wovon
ich rede.
fchk
@Frank
>Ihr habt doch ein Rad ab!
Fällt dir aber früh auf ...
>Ein EZ80F91AZA mit 50 MHz kostet bei Digikey etwa 10 Euro, ...
Natürlich gibts Chips/Boards die mehr können weniger kosten, aber es
besteht doch gerade der Reiz darin mit den heutigen Standardchips solche
Sachen zu machen wie z.b. eine Z80, einen SID, eine 6502 zu emulieren,
oder eben ein BAS-Signal für nen Fernseher zu erzeugen.
Ich bin ja auch total Plemplem wenn ich mit einem FPGA Audio mache
obwohl jeder DSP für die Hälfte an Euros das doppelte an MIPS/MFLOPS
hat.
Trotzdem macht es Spaß, man lernt was dabei und man freut sich nachher.
(Selbst wenns im Falle des Audio-FPGAs die Freude hauptsächlich bei mit
selbst liegt, aber das ist es mir wert)
Ich glaube man nennt sowas : Meet the Challenge ... Oder anders gesagt :
Wenns Spaß macht ...
@A.K.
>Kennst du das Thornton-Buch (PDF) über die CDC6600?
Ne leider nicht. Hast du vllt nen Link dazu ?
Hatte mir mal die Schaltpläne von dem Apollo-11 Rechner angeguckt. Und
bin doch echt erstaunt wie nahe das Dingen einem heutigen
Mikrocontroller kommt.
Frank K. schrieb:> Ihr habt doch ein Rad ab!
Ich freue mich über diese losen Räder. Ehrlich! Schade dass du sie nicht
hast.
Frank K. schrieb:> ich weiss, wovon ich rede.
Mag sein, aber leider weisst nicht du nicht, wovon hier geredet wird.
Nicht von einer aktuellen Technik, sonderm dem Schwelgen in
Vergangenheit und deren Technik. Fertig kaufen kann man alles. Dann wäre
jedes Hobby, wo selbst gebaut wird dummes Zeug. Alles kann man billiger
und fertig kaufen. #gähn#
Das Z80-Zeugs was du erwähnst liegt hier auch rum. Weiss also was du
meinst. Ist aber nicht das, wovon hier gesprochen wird.
900ss D. schrieb:> ... Fertig kaufen kann man alles. Dann wäre> jedes Hobby, wo selbst gebaut wird dummes Zeug. Alles kann man billiger> und fertig kaufen. #gähn#
Ist aber Trend. Ich habe noch für Segelflugzeuge Spanten zugesägt und
mit Seide bespannt, die Enkel meines Nachbarn haben gestern auch ein
Segelflugzeug bekommen, auspacken, Flügel reinstecken, fliegt (nicht so
gut wie meine, muss ich feststellen). Die Kinder erwarten das auch so,
deswegen gibt es keine Bausätze mehr. Der PC muss eben auch zum
Geburtstag betriebsfertig dastehen.
Gruss Reinhard
Frank K. schrieb:> Eben nicht. Der wesentliche Aufwand, nämlich die CPU-Emulation entfällt.
Die CPU-Emulation ist reine Software, das muss somit nur einmal gemacht
werden.
Natürlich stimme ich Dir aber zu, dass wir eine Schraube locker haben.
Für uns ist Elektrotechnik ein wichtiger Teil in unserem Leben, und
willkommener Ausgleich zum langweiligen Beruf.
karadur schrieb:> Habe selbst> unter CP/M meine Diplomarbeit
Was ich vergass, hab ich übrigens auch ;-)
Es war allerdings ein geklontes CP/M und hiess ZDOS und lief auf einem
Z-80-System auf ECB-Bus Basis von Fa. Janich & Klass. Die Firma gibt es
sogar noch, wie ich gerade festgestellt habe. Und das System hatte zwei
8"-Lauferke. :-)
@Peter Sieg
Sorry, aber es geht hier nicht um das Einfachste oder Schnellste.
Es geht um die Herausforderung. Sicher es wäre einfacher auf dem PC
einen fertigen Z80 Emulator anzuwerfen und gut. Aber was hat man davon?
Es ist für mich halt interessanter eine Rechnerarchitektur auf einer
anderen abzubilden. In diesem Falle lernt man nämlich über beide etwas.
Genauso ist es vermutlich bei den Cracks, die heutzutage noch Demos für
den C64 machen (teilweise mit Effekten die man vor 15 Jahren nicht
einmal einem PC zugetraut hätte) Wenn man dort sagen würde: "wieso nehmt
ihr nicht einen PC mit 3d Karte, der ist doch viel schneller"
Dann würde man vermutlich aus dem Saal geworfen werden.
P.S.
Zur Zeit code ich an einer 6502 Emu (mit RAM, ROM, Dezimalmodus und
illegalen Opcodes) und kämpfe mit teilweise wiedersprüchlichen Dokus.
Christian Berger schrieb:> Natürlich stimme ich Dir aber zu, dass wir eine Schraube locker haben.
Full ACK
Der eine oder andere hat vielleicht im Platinenforum den Thread über die
'verrückteste Platine' gesehen. Ein Eintrag hat einen Link
http://users.monash.edu.au/~ralphk/burroughs.html
Ich hab mich spontan entschlossen, dass mein nächster ATMega-Rechner ein
Frontpanel braucht :-)
Frank K. schrieb:> Ihr habt doch ein Rad ab!
Auch wenn ich das alles nicht so eng sehe, kann ich Franks Worte doch
ein Bisschen verstehen. Warum?
Grundsätzlich bin auch ich ein Freund von solchen "Radabprojekten" (im
Folgenden RAPs genannt). Der entscheidende Unterschied zwischen einer
industriellen Produktentwicklung und einem RAP liegt in meinen Augen im
Folgenden:
Industriell
Bei einer industriellen Produktentwicklung wird versucht, sehr viele
verschiedene Kriterien wie
- Entwicklungsaufwand
- Materialkosten
- Fertigungskosten
- benötigte Fertigungseinrichtungen
- Baugröße
- Energieverbrauch
- seltener auch "Restro"-Aspekt (Beschränkung auf Materialien und/oder
Aussehen und/oder Fertigungsverfahren aus der Vergangenheit)
- ...
sinnvoll zu gewichten und das Produkt so zu optimieren, dass die
Kriterien in Summe möglichst gut erfüllt sind und somit mit dem Produkt
ein möglichst hoher Gewinn erzielt wird.
RAP
Bei einem RAP wird typischerweise eine radikal andere Gewichtung dieser
Kriterien vorgenommen und versucht, ein "Produkt" zu entwickeln, das
nach dieser Gewichtung optimal ist. Im häufig auftretenden Extremfall
wird nur ein einzelnes dieser Kriterien mit einem Gewicht >1 versehen,
während alle anderen mit 0 gewichtet sind, also völlig unberücksichtigt
bleiben.
Gerade dieser selbstdefinierte Bewertungsmaßstab frei von den Vorgaben
irgendwelcher Marketingabteilungen und anderen externen Zwängen macht
den Reiz von RAPs aus.
Eine Gewinnerzielungsabsicht besteht bei einem RAP üblicherweise nicht.
Stattdessen steht der Coolness-Faktor im Vordergund, der meist darin
besteht, sagen zu können: "Meine Entwicklung stellt hinsichtlich des
Kriteriums x alles, was es zu kaufen gibt, in den Schatten.
Beispiele:
Bei dem CP/M auf dem ATmega fehlt nach meinem Geschmack ein wenig dieser
Optimierungsgedanke, da der Einsatz des ATmega im Vergleich zu einem
Z80-kompatiblen Mikrocontroller bzgl. der o.g. Kriterien kaum Vorteile
bringt. Vielleicht habe ich aber auch nur ein wichtiges Kriterium
vergessen ;-)
Ok, es gibt noch einen weiteren Aspekt, weswegen man ein Hobbyprojekt
beginnt, nämlich der Lerneffekt bzw. Erkenntnisgewinn. Nur hätte ich
Hemmungen, dafür so viel Zeit in ein Projekt zu stecken, wo ich
vielleicht ähnlich viel in einem anderen Projekt lernen könnte, das
weniger zeitaufwendig ist und/oder ein nützlicheres Ergebnis liefert.
Aber die persönlichen Zielsetzungen sind eben verschieden. Deswegen läge
mir nichts ferner, als jemandem dieses Projekt auszureden. Auf jeden
Fall wünsche ich allen, die sich damit beschäftigen, viel Erfolg!
Hat jemand diesen CP/M Rechner mit einem stärkeren Atmega (z.B. Atmega
32) gebaut? Falls ja, stellt jener mal den Schaltplan Online? Und, falls
dieser das auch noch auf Lochraster aufgebaut hat, hätte ich gerne
einmal ein Foto :)
Ronny Minow schrieb:> Hat jemand diesen CP/M Rechner mit einem stärkeren Atmega (z.B. Atmega> 32) gebaut?
Der ist ... ähm .... auch nicht grossartig anders.
Und .... hmmm ... wie soll ich sagen .... ein Mega32 bringt dir bei
diesem Projekt gar nichts.
Der Hauptunterschied zwischen dem Mega88 und dem Mega32 besteht darin,
dass der Mega32 mehr Flash hat. Nun ist dieses Projekt aber auf Flash
gar nicht angewiesen. Flash ist mehr als genug brachliegend.
Karl heinz Buchegger schrieb:> Ronny Minow schrieb:>> Hat jemand diesen CP/M Rechner mit einem stärkeren Atmega (z.B. Atmega>> 32) gebaut?>> Der ist ... ähm .... auch nicht grossartig anders.>> Und .... hmmm ... wie soll ich sagen .... ein Mega32 bringt dir bei> diesem Projekt gar nichts.> Der Hauptunterschied zwischen dem Mega88 und dem Mega32 besteht darin,> dass der Mega32 mehr Flash hat. Nun ist dieses Projekt aber auf Flash> gar nicht angewiesen. Flash ist mehr als genug brachliegend.
Zum Flash: Kann man den freien Flash für ein Dateisystem nutzen? Ich
denke, der virtuelle CP/M / der Nutzer wird sich freuen wenn er ein paar
Programme auf dem Flash ablegen kann.
Und, afaik hat der Atmega32 etwas mehr Ram, als der Atmega88. Oder, bin
ich da falsch informiert...?
Ronny Minow schrieb:> Und, afaik hat der Atmega32 etwas mehr Ram, als der Atmega88. Oder, bin> ich da falsch informiert...?
Und was hast du davon? Für den simulierten Speicher ist das zu wenig und
für den Simulator zu viel. Erst beim Mega162 und externem SRAM an Stelle
des DRAM wird das interessant.
Yalu X. schrieb:> Gerade dieser selbstdefinierte Bewertungsmaßstab frei von den Vorgaben> irgendwelcher Marketingabteilungen und anderen externen Zwängen macht> den Reiz von RAPs aus.
Warum soll ich mein Hobby so rational betrachten?
Fast alle Hobbies sind rational betrachtet ziemlicher Blödsinn. Kosten
nur Geld, kommt kaum was Sinnvolles bei rum.
Ich betreibe mein Hobby #nur# weil es Spass macht.
Ich kann nicht alles nur rational betrachten und jeder hat sicher
irgendwo seinen Schwerpunkt bei Freizeitbeschäftigung, wo die Frage nach
dem rationalen Sinn berechtigt ist.
A. K. schrieb:> Bei der Cray-1 ging das> nicht mehr. Dort sind die Kabel nach passender Verzögerungszeit> dimensioniert. Dementsprechend sieht es drin aus:
Uff, echt beeindruckende Fotos.
A. K. schrieb:> Ronny Minow schrieb:>>> Und, afaik hat der Atmega32 etwas mehr Ram, als der Atmega88. Oder, bin>> ich da falsch informiert...?>> Und was hast du davon? Für den simulierten Speicher ist das zu wenig und> für den Simulator zu viel. Erst beim Mega162 und externem SRAM an Stelle> des DRAM wird das interessant.
Den simulierten Speicher müsste man von 1KB auf 2KB, oder etwas
dazwischen erweitern können... Was dem "zuviel Ram für den Simulator"
selbst angeht, sag ich nur dazu das man mit dem Emulator nicht ganz so
schnell an die grenzen stößt. Evtl. kann man im freien Ram noch ein
Keyboard Treiber, oder auch ein VGA/ FBAS Treiber rein quetschen...
Aber, das müsste mal jemand testen der etwas mehr Erfahrung im Umgang
mit den Atmega µC's hat...
Ronny Minow schrieb:> Den simulierten Speicher müsste man von 1KB auf 2KB, oder etwas> dazwischen erweitern können...
Der ist sowieso schon 128KB gross (256Kx4). Das SRAM im Controller wird
offenbar nur für den Stack des Simulators und als SD-Card Puffer (512B)
verwendet, da sind also noch >>400B Luft.
A. K. schrieb:> Ronny Minow schrieb:>>> Den simulierten Speicher müsste man von 1KB auf 2KB, oder etwas>> dazwischen erweitern können...>> Der ist sowieso schon 128KB gross (256Kx4). Das SRAM im Controller wird> offenbar nur für den Stack des Simulators und als SD-Card Puffer (512B)> verwendet, da sind also noch >>400B Luft.
Hmmm... Bei den verbleibenden ca. 400b kann man wohl nur ein Keyboard
Treiber (für PS2) und einen einfachen FBAS + Zeichengenerator einsetzen.
Wobei es da aber sicherlich sehr eng mit dem freien Ram wird...
Ronny Minow schrieb:> Hmmm... Bei den verbleibenden ca. 400b kann man wohl nur ein Keyboard> Treiber (für PS2) und einen einfachen FBAS + Zeichengenerator einsetzen.> Wobei es da aber sicherlich sehr eng mit dem freien Ram wird...
Jetzt muss ich mal nachfragen.
Hast du schon einmal ein Programm für einen MegaXX (egal welcher)
geschrieben.
Mir scheint dir ist überhaupt nicht klar, dass Flash und SRAM 2 Paar
Schuhe sind.
Programme stehen im Flash
Daten stehen im SRAM
Ein Keyboarddriver ist ganz klar ein Programm, kommt also ins Flash
(sofern er nicht von der virtuellen Z80 abgearbeitet wird, aber so
dämlich wird ja dann doch wohl keiner sein)
Und ja, es gibt eine Ausnahme: Daten die sich nicht ändern, also als
Konstante anzusehen sind, kann man auch im Flash parken.
Karl heinz Buchegger schrieb:> Ronny Minow schrieb:>>> Hmmm... Bei den verbleibenden ca. 400b kann man wohl nur ein Keyboard>> Treiber (für PS2) und einen einfachen FBAS + Zeichengenerator einsetzen.>> Wobei es da aber sicherlich sehr eng mit dem freien Ram wird...>> Jetzt muss ich mal nachfragen.> Hast du schon einmal ein Programm für einen MegaXX (egal welcher)> geschrieben.
Für einem MegaXX noch nicht, da liegt Dein Verdacht richtig.
> Mir scheint dir ist überhaupt nicht klar, dass Flash und SRAM 2 Paar> Schuhe sind.
Ich muss sicherlich noch vieles lernen. Aber, der Unterschied ist mir
schon bekannt.
> Programme stehen im Flash> Daten stehen im SRAM>> Ein Keyboarddriver ist ganz klar ein Programm, kommt also ins Flash> (sofern er nicht von der virtuellen Z80 abgearbeitet wird, aber so> dämlich wird ja dann doch wohl keiner sein)
Mir ging es darum, das der Treiber ja irgendwo her seine Daten bekommen
muss, die dieser zu verarbeiten hat. Ein Zeichenpuffer für, sagen wir 20
Zeichen + evtl. benötigte "Meta" Codes (Alt, Shift usw.) finde ich sehr
Hilfreich. Das ganze nimmt schon ein paar Bytes vom freiem Ram weg. Die
Codetable kann man ja im Flash ablegen, da sie ja nur einmalig erzeugt
wird.
Die visuelle Ausgabe, per FBAS, VGA or whatever, braucht dagegen schon
einige Bytes an Ram... Der Treiber muss sich ja zur Laufzeit die
auszugebenen Daten aus dem Ram holen....
Ok, vieleicht ist meine Denkweise aber auch im Grundsatz falsch. Falls
ja, korrigiert mich :)
Ronny Minow schrieb:> Mir ging es darum, das der Treiber ja irgendwo her seine Daten bekommen> muss, die dieser zu verarbeiten hat. Ein Zeichenpuffer für, sagen wir 20> Zeichen + evtl. benötigte "Meta" Codes (Alt, Shift usw.) finde ich sehr> Hilfreich.
OK.
20 Bytes benötigt - 400 Bytes SRAM frei
20 Bytes benötigt - 400 Bytes SRAM frei
was sagt uns das?
> Die visuelle Ausgabe, per FBAS, VGA or whatever, braucht dagegen schon> einige Bytes an Ram... Der Treiber muss sich ja zur Laufzeit die> auszugebenen Daten aus dem Ram holen....
Ähm.
Der Mega ist auch so schon mit der Z80 Emulation ausgelastet. Willst du
dem wirklich noch die Generierung eines Videosignals aufhalsen?
Kalle Schrob:
> Ähm.> Der Mega ist auch so schon mit der Z80 Emulation ausgelastet. Willst du> dem wirklich noch die Generierung eines Videosignals aufhalsen?
Nunja, er hat's noch nicht gemacht und kann es noch nicht beurteilen.
Sei also nicht so streng... ;-)
Na schön, das hier doch einiges an Interesse ist.. ;-)
(Auch - oder gerade weil wir ein Rad abhaben)
Oder wie schon im deutschen Liedgut steht, wer nicht verrückt ist, der
ist
nicht normal..
---
Nun jeder ist ja relativ frei, das Projekt zu erweitern.. ist ja GPL3..
Für mich persönlich, ist die serielle+VT100 Anbindung völlig ok..
PS/2+BAS
sind mir nicht so wichtig.. wenn es aber doch jemand macht. prima!
Wichtiger wäre zuerst einmal ein Ausbau der unterstützen Opcodes..
Wenn da mal auch mehr/Z80 Programme laufen etc.. mache ich auch gerne
ein
Platinen-Layout mit Eagle ;-) Oder ganz abgefahren in SMD mit Micro-SD
in
Streichholzschachtelgröße. ;-)
Peter
Peter Sieg schrieb:> Na schön, das hier doch einiges an Interesse ist.. ;-)> (Auch - oder gerade weil wir ein Rad abhaben)> Oder wie schon im deutschen Liedgut steht, wer nicht verrückt ist, der> ist> nicht normal..
Ganz Deiner Meinung :)
>> --->> Nun jeder ist ja relativ frei, das Projekt zu erweitern.. ist ja GPL3..> Für mich persönlich, ist die serielle+VT100 Anbindung völlig ok..> PS/2+BAS> sind mir nicht so wichtig.. wenn es aber doch jemand macht. prima!
Daran kann ich ja mal etwas basteln....
>> Wichtiger wäre zuerst einmal ein Ausbau der unterstützen Opcodes..
Man sollte erstmal testen, welche CP/M Software bereits läuft. Fehlen
Funktionen bzw. OpCodes, kann man diese sicher immer noch nachrüsten...
>> Wenn da mal auch mehr/Z80 Programme laufen etc.. mache ich auch gerne> ein> Platinen-Layout mit Eagle ;-) Oder ganz abgefahren in SMD mit Micro-SD> in> Streichholzschachtelgröße. ;-)>> Peter
Ich würde eher ein Board nehmen, was man "auf dem Küchentisch" aufbauen
kann. Ähnlich den Hive - Retrostyle Computer Projekt (
http://hive-project.de/ ) ...
---
Ich baue das Board gerade, mit LochMaster 3.0, vituel auf. Wer Shots
oder auch die Dateien aus LochMaster haben mag, einfach melden :) Ach
ja, ich benutze einen Atmega32 für den virtuellen Aufbau....
Hmm, eventuell wäre es auch sinnvoll eine PDP-11 zu emulieren. Die
Betriebssysteme darauf wurden im Quellcode ausgeliefert, und es gab viel
Software dafür.
Ich wollte knur kurz den Thread wieder nach oben bringen. Nebenbei finde
ich das ein wirklich schönes Projekt, was ich bei nächster Gelegenheit
testen und erweitern möchte. Wenn man einen zweiten AVR für Tastatur und
Video-Output nimmt, dann hat man ein schönes System.
Gruß,
SIGINT
@SIGNINT: Prima! Inzwischen kann ich das diskimage unter win32 ändern..
Habe auch ein othello gefunden, das läuft. Und ein mbasic für 8080.
Läuft zwar, aber Sprungziele werden beim load zu 00000??
Wird der z80.asm unter AVR Studio assembliert?
Wollte mal versuchen, von 20 auf 32MHz umzustellen.. dazu muß ich sicher
die
Geschwindigkeit der RS232 Schnittstelle umstellen..?
Peter
Peter Sieg schrieb:> @SIGNINT: Prima! Inzwischen kann ich das diskimage unter win32 ändern..> Habe auch ein othello gefunden, das läuft. Und ein mbasic für 8080.> Läuft zwar, aber Sprungziele werden beim load zu 00000??
Wenn du diese Emulation benutzt:
Es sind noch nicht alle Opcodes des Z80 unterstützt.
Speziell die CB und ED Schiene ist noch gar nicht vorhanden.
Und ob bei den implementierten Opcodes die Status Flags überall richtig
nachgezogen werden, hab ich nicht näher untersucht.
Jup. Bin leider auch kein 8080/Z80 Kenner.. da müßte ich mich erst
einarbeiten.. nun, zumindest kann ich den Quelltext mit AVR Studio 4
assemblieren (dabei auch gleich die Baudrate kalkulieren lassen..) und
das Ergebnis läuft..
Werde das mal mit ATmega88PA und 32MHz anstatt 20MHz probieren.. dabei
sollte auch der DRam Refresh weiter runter können.. mal schauen, wie
viel 'Geschwindigkeit' das bringt..
Dann wäre da auch noch die Frage, warum das Nibble an D0-D3 nicht auch
ein
Nibble an einem Port ist..
Nun Ja.. zu allem 'Überfluß' hier auch noch ein Platinenlayout ;-)
Peter
Ich habe mir den Code mal angesehen und denke, dass die DRAM-Anbindung
zwar recht minimalistisch, dafür aber auch arg langsam ist. Grob
geschätzt komme ich z.B. auf über 160 Takte bei der dram_read Routine.
Wenn man einen 40-poligen Controller (z.B. Meag16) und zwei DRAMs nimmt,
D0-D7 an Port A, A0-A7 an Port C und die Steuersignale an Port D, sollte
das wesentlich schneller gehen. Letztendlich müssen nur die
entsprechenden Routinen ausgetauscht werden. Ein Beispiel wäre:
1
dram_read: cli ;1 disable interrupt
2
ldi ZL,0x7F ;1 RAS
3
ldi ZH,0x1F ;1 RAS + CAS + OE
4
out PORTC,adrh ;1
5
out PORTD,ZL ;1 RAS active
6
out PORTC,adrl ;1
7
out PORTD,ZH ;1 RAS + CAS + OE active
8
ldi ZL,0x9F ;1 RAS inactive
9
out PORTD,ZL ;1 CAS + OE (hidden refresh)
10
in temp,PINA ;1 get data
11
out PORTD,ZH ;1 RAS + CAS + OE
12
ldi ZH,0xFF ;1
13
out PORTD,ZL ;1 only RAS
14
out PORTD,ZH ;1 inhibit
15
sei ;1 enable interrupt
16
ret ;4 end
Bringt Beschleunigung um etwa Faktor 7 beim Lesen aus dem Speicher.
Jörg
Hi Jörg.
Das wäre super!
Da meine Kenntnisse in AVR Assembler eigendlich nicht vorhanden sind ;-)
bleibe ich vorerst einmal beim aktuellen Aufbau. Hier möchte ich noch
mal
die Takterhöhung auf 32MHz und die Reduzierung des DRam-Refreshs
probieren.
Und der Warmstart muß auch überarbeitet werden (hängt einfach).
Inzwischen kann ich diskimage unter win32 mit den cpmtools ändern und
mit BDS-C übersetzte Programme laufen auch unter avr-cpm ;-)
Zu einem anderen Aufbau sehe ich das aber letztlich genauso.. was
ein 'fauler' Kompromiss ist und viel Rechenpower kostet muß durch
etwas besseres ersetzt werden.. Da kann man beim Ram auch z.B über SRAM
nachdenken.. dann braucht man keinen Refresh mehr..
Wäre super, wenn hier genügend zusammen kommen, um daraus einen kleinen,
schnuckeligen und brauchbaren CP/M Rechner zu basteln..
Peter
@ Peter Sieg: Ich habe mir Dein Projekt auf Deiner Homepage angesehen.
Als erstes: Das ist ein sehr interissantes Projekt. Nicht zuletzt
deshalb, weil mir CP/M eigendlich unbekannt ist. Das soll mich aber
nicht daran Hindern, Dein Projekt aufzubauen und mit zu Entwickeln.
Was mir für den Aufbau fehlt, ist ein Z80 Assembler. Wenn ich das Paket
zum erstellen der Image Disk richtig verstehe, brauche ich diesem um die
Software entsprechend übersetzen zu können. Wo bekomme ich diesem
Assembler her...?
@Joerg Wolfram: Du hattest einmal einen einfachen Basic Computer mit
einem Atmega8/88 aufgebaut. Könnte man die Umgebung für den TV Out/
FBAS, sowie den PS2 Controller an den CP/M Rechner anbringen? Falls
notwendig, über einen 2. Atmega8...
Sowas gibt es auch mit dem Propeller:
http://forums.parallax.com/forums/default.aspx?f=25&m=332138
TV, VGA, PS/2, SD-Karte, ... mit CPM2.2 oder MPM
Der Minimal-Aufbau ist für unter 30 Euro zu machen, wenn man alle
Teile kaufen muss.
Das einfachste Board, wäre ein abgespecktes Dracbalde (nur RAM, PS/2 und
VGA/TV, SD, keine weiteren IOs usw.)
kruemeltee schrieb:> Sowas gibt es auch mit dem Propeller:>> http://forums.parallax.com/forums/default.aspx?f=25&m=332138>> TV, VGA, PS/2, SD-Karte, ... mit CPM2.2 oder MPM>> Der Minimal-Aufbau ist für unter 30 Euro zu machen, wenn man *alle*> Teile kaufen muss.>> Das einfachste Board, wäre ein abgespecktes Dracbalde (nur RAM, PS/2 und> VGA/TV, SD, keine weiteren IOs usw.)
Auch, wenn der Propeller µC schon klasse ist, so denke ich sollten wir
den Atmega µC verwenden.
Ich selbst habe ein Hive -Retrosytle Computer, der 3 Propeller µC's
verwendet. Der Hive ist ein Klasse Computer. Man kann sicher auch CP/M
drauf laufen lassen, was auch in Entwicklung ist. Hier geht es aber um
CP/M für den Atmega, nicht für den Propeller µC.
---
@Peter Sieg: Welche Software hast Du schon auf dem Projekt zum leben
erwecken können?
Joerg Wolfram schrieb:> Wenn man einen 40-poligen Controller (z.B. Meag16) und zwei DRAMs nimmt
Vielleicht könnte man einen AVR 8515 oder 8535 nehmen, die haben ein
SRAM-Interface.
bix schrieb:> Vielleicht könnte man einen AVR 8515 oder 8535 nehmen, die haben ein> SRAM-Interface.
Soweit ich das überblicke: 8515 ja, 8535 nein.
Ist der 8515 eigentlich der einzige mit SRAM-Interface? In der
Vergleichstabelle von Atmel ist selbiges leider nicht aufgeführt.
frank
@Ronny Minor: Habe ein paar Spiele, die laufen: Mastermind, TicTacToe,
Othello, Stone.. kommt ggf. noch Packman mit VT52 Steuerung dazu.. evtl.
noch 4-gewinnt..
Peter
frank schrieb:> Ist der 8515 eigentlich der einzige mit SRAM-Interface? In der> Vergleichstabelle von Atmel ist selbiges leider nicht aufgeführt.> frank
Der ATmega162 hat "Up to 64K Bytes Optional External Memory Space"
Gruß
Roland
Peter Sieg schrieb:> @Ronny Minor: Habe ein paar Spiele, die laufen: Mastermind, TicTacToe,> Othello, Stone.. kommt ggf. noch Packman mit VT52 Steuerung dazu.. evtl.> noch 4-gewinnt..>> Peter
Einige Spiele sind schon einmal ein Anfang. Wie sieht es mit typischer
CP/M Software aus? Läuft z.B. DBase (gab es das für CP/M überhaupt...?)
?
---
Wer hat diesem Computer schon aufgebaut? Ach ja, gibt es schon Ideen für
ein Video Ausgang? Oder anders: könnte man an Herrn Wolframs Basic
Computer mit Atmega8/88 den DRAM drann hängen und somit eine Symbiose
aus beiden Computern machen?
... Auch, wenn der Propeller µC schon klasse ist, so denke ich sollten
wir den Atmega µC verwenden. ...
Warum nicht gleich eine Zuse 3 (fröhlich klappern die Postrelais)? Warum
überhaupt so etwas einfaches wie DRAM? 64 KByte als Magnetkernspeicher
- das nenne ich eine Aufgabe?
CPM-Gerümpelrechner schrieb:> Warum nicht gleich eine Zuse 3 (fröhlich klappern die Postrelais)? Warum> überhaupt so etwas einfaches wie DRAM? 64 KByte als Magnetkernspeicher> - das nenne ich eine Aufgabe?
Hast Du eine Z3 gebaut? Wenn ja, zeig mal her :)
@Ronny Minow: dbase gibt es für CP/M..
Generell gilt vorerst: NUR 8080 CPU - d.h Programme, die unter CP/M-80
laufen haben gute Changen..
Aber: Die Emulation hat SICHER noch Fehler! Z.B MBASIC4.5 für CPM-80
läuft ersteinmal.. Interaktiv, also z.B print 2+4 (=6) geht.. aber
Programmlauf geht nicht, weil alle Variablen zu 00000 evaluieren.. keine
Ahnung warum!
Im AltairSIMH Emulator mit Z80 CPU ist alles ok..
Die vielen anderen Basic Versionen habe ich noch nicht getestet..
Es gibt generell sehr viel alte Software für CP/M-80..
http://www.z80.eu/http://www.retroarchive.org/cpm/
Deswegen wäre/ist meine Prämisse:
1. Noch weitere Basic Interpreter testen
2. Noch eine paar weitere Spiele compilieren mit BDS-C
3. Warmstart implementieren (hängt da aktuell einfach)
4. Das ganze mal mit 32MHz laufen lassen (88PA)
5. 8080 Code prüfen und ggf. Fehler beseitigen
---
6. Evtl. andere Hardware mit 8-bit SRam etc. etc
7. Z80 Opcodes implementieren
Generell denke ich reicht es mir, wenn ich 1-5 erreicht habe..
bin aber allen Neuentwicklungen/Verbesserungen offen gegenüber..
kann man/das Projekt ja nur von profitieren..
---
Bezüglich des benutzten z80asm.. keine Ahnung, welcher das ist.
Da sollte man den Entwickler: Sprite_TM fragen.. ich würde den gerne
auch unter win32 haben.. bisher ändere ich das vorhandenen diskimage
mit cpmrm und cpmcp..
Peter
@Peter Sieg: Danke für die Links. Ich habe mich da mal umgesehen. Wenn
ich dazu komme, werde ich mal "Tiny C", "Pascal" und einen Assembler auf
dem Computer laufen lassen. Aber, ersteinmal muss ich den zusammen
löten. Die Bauteile hierfür dürften in einigen Tagen bei mir sein.
Ach ja, thx für das Pin Layout des SRam's, das Du auf Deiner Homepage
veröffendlicht hast.
Roland F. schrieb:> Der ATmega162 hat "Up to 64K Bytes Optional External Memory Space"
Das Interface wäre sogar richtig schnell. Jedoch gibts Probleme mit dem
untersten Kilobyte.
Christian Berger schrieb:> Das Interface wäre sogar richtig schnell. Jedoch gibts Probleme mit dem> untersten Kilobyte.
Stets 1K draufaddieren und das oberste KB nicht verwenden.
Christian Berger schrieb:> Dann hat man allerdings Probleme mit dem obersten Kilobyte. :)
Wer definiert, dass es dies geben muss? Unten weglassen geht bei
8080/Z80 nicht, oben schon.
Ich weiß, das ist verrückt ;-)
Ich denke ernsthaft darüber nach 10 Platinen anfertigen zu lassen ;-)
Aus dem forum64 gibts zumindest schon einmal noch 2 Interessenten außer
mir..
da ich auch mind. 2 für mich nehme wären es schon 4.. wenn wir noch ein
paar
finden könnte das wirklich klappen.. unter 10 macht es keinen Sinn..
ich rechne mit ca. 9-10€/Platine. SD Slot kostet 3€. Versand ca. 1,50€
(Post). Natürlich kann man das auch auf LR aufbauen.. aber mir fertiger
Platine wird es doch ein wenig einfacher (ist durchkontaktiert mit
Lötstopp).
Ach ja, Platine siehe weiter oben.. RS232 Wandler will ich nicht drauf
haben.
Und 3,3V Netzteile gibts bei Pollin..
Peter
@Peter: Lohnt es sich für so eine kleine Schaltung eine Platine fertigen
zu lassen?!? Ich fände es besser erst ein vollständiges System, mit
IO-Hardware (TV-Out, Keyboard, Sound?!, etc.) zu entwickeln und dann die
Platinen fertigen zu lassen. Ich glaube, die meisten würden gerne einen
kompletten CP/M Rechner haben, den man ohne externe Hardware betreiben
kann.
Ich hab schon ein paar Ideen, was man mit dem System machen könnte:
Portieren eines AVR-Assemblers auf CP/M-80
CP/M-80 Software zum flashen von AVRs
Grafik-LCD am System anbinden
mehrer Diskettenimages auf SD-Karte
einfache Soundausgabe per PWM (DMA,IRQ?!)
Mir ist klar, daß dies noch viel Arbeit ist, aber ich Glaube es könnte
sich lohnen.
Ich hab schonmal angefangen auf dem PC einen kleinen Z80-Emulator zu
basteln, um mich in CP/M ein zu arbeiten. Leider funktioniert das aber
noch nicht so, wie ich es möchte.
Gruß,
SIGINT
@SIGINT: Nun, eine 10ner Auflage der aktuellen Hardware steht einer
späteren Auflage eines erweiterten Systems ja nicht im Wege..
(Ich bin nun mal Minimalist ;-) )
Schau doch mal, ob Jörg Wolfram auch noch Interesse hat an einer
Erweiterung
zum vollwertigen CP/M Rechner mitzuarbeiten.. Evtl. finden sich hier
weitere
Mitstreiter.. kann man die Entwicklung ggf. aufteilen..
Wäre wirklich super, wenn das klappt!
Als Emulator schau mal bitte nach AltairSIMH. Läuft bei mir prima..
Hänge ich hier mal an.. einfach entpacken und Altairall.bat starten.
Laufwerk A: ist CP/M 2.2
Laufwerk B: ist MBasic
Laufwerk C: ist BDS-C compiler
Mit R/W lassen sich Dateien vom Hostsystem nach CP/M transferieren.
Peter
Es ist wahrscheinlich sinnvoller, eines der in der Codesammlung
vorhandenen AVR-Terminals zu benutzen. Die haben eigentlich alle eine
höhere Auflösung als das ChipBasic und die serielle Ansteuerung ist auch
schon fertig.
Ich halte das Ganze für ein recht interessantes Projekt, allerdings geht
für mich der praktische Nutzen gegen Null.
Wobei ich heutzutage auch kein Projekt mehr anfangen würde, welches nur
TV als Ausgabemedium hat. Schon beim ChipBasic mit seiner doch recht
groben Auflöung sind bei neueren TVs durch die ganze Samplinggeschichte
die Pixel unterschiedlich breit und auch teilweise unterschiedlich hoch
wahrscheinlich werden die Bilddaten 4:2:2 gespeichert).
Eine probeweise Darstellung von 80 Zeichen (480 Pixel bei 10MHz
Pixeltakt) ist auf einem guten Analoggerät noch lesbar, aber schon auf
einem 100Hz Fernseher einfach eine Zumutung (zumindest meinem Eindruck
nach).
Jörg
Hallo,
nettes Projekt, Danke Peter!
Ich habe mal Peters Idee aufgegriffen, seine Schaltung leicht erweitert
und ein Layout dazu erstellt. Vielleicht findest es ja Gefallen.
1. Die Jumper TTL, Reset und 3.3 V behalten vollständig ihre Pinbelegung
und Funktion
2. Die Kommunikation (RS232) ist auf eine USB-Schnittstelle gelegt.
3. Die Stromversorgung (5V und 3.3V) erfolgt über die USB-Schnittstelle
4. Steckverbinder zur ISP-Programmierung des AVR hinzugefügt.
5. Mit dem Jumper POWER Switch kann wahlweise zwischen 5V und 3.3V
umgesteckt werden (Vorsicht CF-Card ziehen!)
6. Mit dem Jumper CLOCK Switch kann der AVR Takt über den USB Controller
bezogen werden. Hier sind 6, 12, 24 oder 48 MHz möglich.
Weitere Ideen oder Vorschläge nehme ich gerne auf.
Joe
Hallo Joe.
Deine Ideen finde ich prima! Für mich ist wichtig, das die Jumper Header
(TTL Seriell) so bleiben, damit meine Kabel direkt passen..
Aber der FT232RL ist ja optional..und eine gute Idee.
Stromversorgung über USB Buchse ist auch eine gute Idee.. aber woher
kommen die 3,3V.. oder habe ich da einen Regler übersehen..?
ATmega88+Dram+SD Card sollte über 3,3V versorgt werden.. ich vermute
FT232RL benötigt 5V (und bekommt die ja auch direkt über die USB Buchse)
und kann 3,3V TTL Pegel an Rx+Tx ab.. ich hoffe der AVR kann allerdings
auch +5V ab, obwohl er mit 3,3V versorgt wird..?
Programmierung auf der Platine ist ebenfalls eine gute Idee (wenn ich
auch immer 6-Pol Header verwende ;-) )
Wozu ist D2 1N4148 da?
Wir funktioniert die optionale Taktgenerierung über den FT232RL?
Wie gesagt, wenn das Ganze auch ohne FT232RL Bstückung läuft und man die
3,3V aus dem USB Anschluß erzeugen kann, können wir gerne deine Platine
bestellen, da sie nur 10mm breiter ist..
Im Forum64 gibt zumindest auch schon mal Interesse an 3 Platinen.. hier
gab es auch Interesse an 1-2 Platinen und ich nehme 2.. langsam kommen
wir
auf die benötigten 10 ;-)
Peter
Hallo
ich finde die Idee akademisch sehr amüsant. Nur wer hier wirklich CP/M
machen will ( es ist in den 80ern wirklich super gewesen ) sollte sich
auch mal den ez80 anschauen. Man spart sich die Emulation, ist ein
Nachfolger des Z80 und sehr viel schneller. CP/M war mein erstes
richtiges Betriebssystem auf dem ich Megabytes an Sourcecode unter
Turbopascal erstellt habe, aber es gibt heute bessere Systeme. Es gibt
sicherlich noch viele Geräte die im Hintergrund mit CP/M laufen, aber es
gibt eigentlich ausser nostalgischen Gründen für mich kein Argument
jetzt noch CP/M zu implementieren.
Hallo Peter,
der FT232RL hat einen eigenen 3.3V Regler integriert. Er benötigt also
selbst 5V aus der USB Schnittstelle oder muß über ein eigenes Netzteil
versorgt werden.
Der Rx und Tx Pegel wird, je nach Versorung des FT232 entsprechend auf
5V oder 3.3V angepaßt. Die Brücke für die 5V hatte ich dafür vorgesehen
um für mögliche 5V Programmieradapter kompatibel zu sein.
Für die Programmierung kann ich auch ein 6-Pol Header einsetzen, ist
sogar etwas kleiner :-) Auch kam mir noch die Idee zu einem kleinen
Resettaster.
Die Diode ist nur zum Schutz, siehe AVR042: AVR Hardware Design
Considerations. Sie kann auch entfallen.
Der FT232 ist nur dann optional, wenn die 3.3V extern zugeführt werden.
Die Takterzeugung läuft über die Programmierung des FT232. Dazu gibt es
von FTDI ein kleines Tool über welches das interne EEPROM geschieben
wird.
Prima wenn es 10 Platinen werden....
Joe
@Joe: Ich verwende den AVR ISP Stick. Siehe hier:
http://www.mikrocontroller.net/articles/AVR-ISP-Stick
Wäre super, wenn du diesen 6-pol Programmierheader einbauen könntest.
Resettaster parallel zu dem 2-pol Header ist prima, solange wir dadurch
dir Platine nicht vergrößern.
Also noch mal für mich zum verstehen:
- Man kann 3,3V extern einspeisen und direkt TTL seriell am 3-pol Header
kummunizieren.. FT232RL bleibt dann unbestückt. Takt aus Quarz.
- Zum Flashen kann +5V über USB Buchse eingespeist werden (Ohne SD
Karte!)
- Bei bestücktem FT232RL kann versorgt dieser die anderen Teile mit
+3,3V und stellt natürlich auch direkt die Kommunikation über USB her
(virtueller Com-Port). Alternativ kann man ihm auch noch beibringen den
Takt für den AVR zu generieren, spart sich also den Quarz und die beiden
C's dazu..
So richtig verstanden..?
Dann bitte noch mal an alle, die Platine von Joe und Schaltplan
vergleichen..
denn wir fertigen ja keinen Prototypen mehr an.. und Fehler rächen sich
hier dann sofort an allen Platinen..
Peter
@Peter:
6-polige Programmierbuchse eingesetzt
Resettaster eingefügt
Ja, Du hast es richtig verstanden mit den 3.3V und dem TTL Header.
@Uhu:
Mir fällt keine so richtig einfache Schaltung ein die 5V auf der 3.3V
Leitung zu erkennen. Möglich ist die Differenz zwischen 5V und 3.3V zu
nutzen (1.7V) Eine rote LED sollte dann leuchten. Die Funktion wäre aber
invers, sie leuchtet wenn 3.3V anliegen und nicht wenn 5V anliegen.
Prinzipiell:
Der AVR verträgt laut Datenblatt 1.8 - 5.5V also kein Problem.
Die SD-Cad nur 3.3V also beim Flashen ziehen!
Der DRAM 3.3V oder 5V Volt ja nach Type, ein 5V Type wird also außerhalb
seiner Spezifikation betrieben.
Anbei das geänderte Layout bzw. die Schaltung nochmal zur Durchsicht.
Joe
@Peter Sieg & Joe G.: Falls möglich, verwendet bitte 512x8 SRam's. Diese
lassen sich bei reichelt bestellen... Bei 256x8 SRam's sieht es da
schwieriger aus. Und, diese kann wohl nur noch auf alten Mainboards
finden... Ich jedenfalls habe weder bei CSD noch bei reichelt passende
SRam's gefunden...
Oder, kennt jemand eine andere Quelle, die an Privat liefert...?
karadur schrieb:> auch mal den ez80 anschauen. Man spart sich die Emulation, ist ein> Nachfolger des Z80 und sehr viel schneller.
Hallo,
ganz so einfach ist es nach meiner Erfahrung leider nicht, z.B.
funktionieren die I/O-Befehle i.A. nicht mehr, weil der eZ80 Ports mit
16 Bit Adressen anspricht, und für die Adressierung der Ports von 0..255
gibt es neue Opcodes und ausserdem kollidieren sie mit der internen
Peripherie, im Bereich "HAL" muss man also modifizieren. Da ich in der
Hochsprache ohnehin keine direkten I/Os verwendet habe, müssen bei mir
nur die Zugriffe in Assembler geändert werden. Einfacher als neu
schreiben ist es aber schon.
Interessant wäre es, bei einem Paging-System das Paging auf die
eingebauten eZ80-Funktionen umzustellen und den Rest mit wenigen
Änderungen zu übernehmen. Dann stehen immerhin maximal 256 Pages a 64k
zur Verfügung. Allerdings ist auch da u.U. ein Trick nötig: CP/M u.ä.
Systeme setzen Speichermodelle voraus mit Programm und Daten innerhalb
64k (wie sollten sie das auch besser wissen), der eZ80 kann aber nur
ganze Seiten einblenden, um also Rom und Ram oder verschiedene
RAM-Bereiche innerhalb 64k abzubilden, braucht man noch etwas externe
Hardware.
Gruss Reinhard
Joe G. schrieb:> Mir fällt keine so richtig einfache Schaltung ein die 5V auf der 3.3V> Leitung zu erkennen.
Was spricht gegen eine ZF3,3, einen Widerstand und eine rote LED?
@Ronny Minow: Es geht hier ersteinmal darum, die Schaltung grundsätzlich
NICHT zu ändern. Und ein 256x4 Dram gegen ein 256x8 Sram zu tauschen
wäre
eine solche Änderung.. sowas muß warten bis die anderen Ideen hier ggf.
eine
geänderte Schaltung hervorbringen. Ein 256x4 Dram kann ich ggf.
mitliefern.
Peter
Peter Sieg schrieb:> @Ronny Minow: Es geht hier ersteinmal darum, die Schaltung grundsätzlich> NICHT zu ändern. Und ein 256x4 Dram gegen ein 256x8 Sram zu tauschen> wäre> eine solche Änderung.. sowas muß warten bis die anderen Ideen hier ggf.> eine> geänderte Schaltung hervorbringen. Ein 256x4 Dram kann ich ggf.> mitliefern.>> Peter
Oki, kannst Du auch einen vorprogrammierten Atmega88 beilegen? Falls
nicht, auch nicht schlimm. Die fehlenden Bauteile werde ich mir dann
noch kaufen. Eine Quelle für den DRam Chip habe ich aber nicht
gefunden...Melde Dich, wenn Du die Platinen hast und die Sachen zum
Versand vorbereitest.
@Ronny Minow: So funktioniert das garantiert nicht :-)
WENN wir uns hier auf eine Platinenversion geeinigt haben (sieht so
aus..) und ich mich entscheide, das es losgeht (bald), erst DANN kann
mir jeder Interessent seine Addresse per Mail senden und bekommt dafür
von mir meine BV. ERST wenn alle bezahlt haben (VORKASSE), DANN bestelle
ich die Platinen, denn ich muß auch Vorkasse leisten...
Also eins nach dem anderen..
Peter
> Und: etwas was ich sehr vermisse. Dank Epromfloppy war der Rechner> schneller gestartet als das die Bildröhre warm war.
Schön. das zu hören. Wenn es die aus der c't für den ECB-Bus war, dann
war sie von mir. Studienarbeit 1982/83 oder so. Habe noch ein Exemplar
hier liegen mit 2764, also damals um die 1000 DM.
>@Ronny Minow: Es geht hier ersteinmal darum, die Schaltung grundsätzlich>NICHT zu ändern. Und ein 256x4 Dram gegen ein 256x8 Sram zu tauschen>wäre
Ich begreife es nicht, denn die D-RAM Ansteuerung ist wesentlich
komplizierter. Ein Atmel hat doch wohl keine Refresh-Generierung wie ein
Z-80 System. Dies hat ja auch 8-Bit Refresh, was die 256x4 wohl nicht
haben. Sie haben nur 7-Bit Refresh.
S-RAM sind doch heute in jeder Größe verfügbar, nicht wie früher.
@Michael_ : Ganz einfach: Mache einen LR Aufbau mit SRAM und ändere die
AVR Firmware so ab, das alles mind. so gut/aber schneller funktioniert
wie jetzt und stelle uns dein geändertes Projekt inkl. Schaltplan und
Firmware-Source hier zur Verfügung. - Dann reden wir weiter - ok!
Peter
karadur schrieb:> @ Andy H.>> war die Schaltung aus der c't. Läuft immer noch. Zusammen mit der 1MByte> Ramfloppy.
Super, freut mich wirklich zu hören, die RAM-Floppy war von meinem Assi!
@alle:
Also: Joe G. hier aus dem Forum wird die Platinenbestellung übernehmen.
Wir haben uns diesbezüglich schon abgestimmt.
Redaktionsschluß für Änderungen an der Platinen ist Sonntag, der 6.6
18Uhr MEZ. Verbindliche Bestellungen für
Platinen (und ggf. SD Slots) sind bis zum Sonntag, den 13.6 18Uhr MEZ
möglich. Danach erfolgt die Bestellung.
Generell gilt für DIESE Platinenbestellung, das ursprüngliche
Hardwaredesign (ATmega88, 256kx4 Dram, SD Card) bleibt
unverändert! An Kosten ist mit etwa 10€/Platine zu rechnen (2-lagig,
durchkontaktiert, Lötstoplack). SD Slot etwa 3€/Stück.
Wenn mehrere DRam's benötigt werden.. könnte ich diese Joe zusenden, der
sie
dann mit der Bestellung verteilen kann..(Kosten 1€/Stück - Verrechnung
mit meiner Platinenbestellung bei Joe)..?
Weitere Details zur Abwicklung von Joe G. (feinmechaniker)...
Peter
Wie ich Peter schon im Forum64 geschrieben habe, bin ich an einer
Platine und den SD-Slot interessiert. Die restlichen Teile (AVR und
dRAM) habe ich selbst.
Jörg
Also interesse an einer Platine hätte ich ebenfalls. Bräuchte dann den
SD-Karten Slot, sowie das DRAM. Den Rest werd ich mir so
zusammenbestellen können denke ich.
Warum übergebt Ihr die Platine nicht einfach einem kleinen Online-Shop.
Der soll dann 10€ drauf schlagen, dafür ist es aber mit der ganzen
Bestellerei einfacher.
@Markus: Mit dd.exe für win32 ;-)
Wenn du dir von hier:
http://avr.cwsurf (dot) de/ -> AVR CP/M
die cpmtools.zip ziehst, hast du nicht nur dd.exe, sondern auch die
cpmtools um das diskimage unter Windows zu verändern (genauer: Programme
löschen, hinzufügen, listen).
Peter
@alle:
Wie Peter schon in beiden Foren geschrieben hat, nehme ich die
Bestellungen für die AVR CP/M Platinen entgegen. Dazu bitte Eure
benötigte Stückzahl, Eure Mailadresse sowie die Versandadresse über
„Feinmechaniker“ an mich senden. Weiterhin würde ich die notwendigen
SD-Card Sockel mitbestellen. Wer DRAM’s benötigt ebenfalls kurze Info an
mich. Es sind noch welche in geringer Stückzahl zu haben. Hier gilt –
Verteilung nach Bestelleingang. Jede Bestellung erhält von mir eine
kurze Bestätigung über den Eingang. (Wer schon bestellt hat, bitte nicht
noch mal wiederholen.) Wenn die Bestätigung nicht sofort erfolgt, etwas
Geduld, ich vergesse schon niemanden. Um die angekündigten Preise zu
halten müssen mindestens 10 Platinen zusammenkommen. In diesem Fall
liegt der Preis einer Platine (zweiseitig, durchkontaktiert,
Lötstoplack) bei ca. 10 € netto. Ein SD-Card Sockel kostet 2.95€ und
ein DRAM 1€. Dazu kommen noch 1,65€ für die Warensendung bzw. die Kosten
für die Versandtasche. Eine genaue Kalkulation gibt es nach dem
Bestelleingangsende, da erst dann der Leiterplattenpreis genau
kalkuliert werden kann. Bis Sonntag 18 Uhr nehme ich noch
Fehlerkorrekturen, Änderungsvorschläge, Verbesserungen der Schaltung
auf. Wie Peter schon geschrieben hat gilt jedoch das Hardwaregrunddesign
(ATmega88, 256kx4 DRAM, SD Card). Ziel ist zunächst die
Softwareentwicklung. Wer gleich mit einem SRAM arbeiten möchte, kann ihn
ja über eine Lochrasterplatine auf die DRAM Fassung stecken. Adress-,
Daten- und Steuerpins liegen an, der Rest ist NUR Softwareanpassung :-).
Bestellungen nehme ich bis Sonntag den 13.6 entgegen. Am 14.6 löse ich
die Bestellungen dann aus. Die Lieferzeit für die Platinen beträgt im
Normalfall 8 AT, also bitte nicht schon früher drängeln.
Joe
Das Funktioniert nicht wirklich zufrieden stellend mit einer Z-Diode und
einer LED. Die Exemplarstreuungen sind so groß, dass bei 3.3V die LED
schon leicht leuchtet, wobei meine Z-Diodenbox nur Werte von 2.7, 3.3,
3.9, beinhaltete. Wenn die Aussage nicht sicher ist, dann kann die
Anzeige auch wegelassen werden. Oder einen besseren Vorschlag…
Joe
Habe mir gerade mal den Schaltplan angesehen, dabei fiel mir folgendes
auf:
Es gibt nur einen Abblockkondensator (im Schaltplan am AVR, auf der
Platine neben dem RAM).
Ich würde für MCU und RAM jeweils einen eigenen Kondensator vorsehen und
die Bauteile so platzieren, dass sie nicht direkt vor oder hinter dem
Sockel sitzen, sondern seitlich versetzt. Das erleichtert den Ausbau der
ICs, wenn man einen Schraubendreher als Hebel ansetzen will.
Ggf. sollte man noch einen Elko für die SD-Karte einplanen.
Der Pin AREF sollte offen bleiben. Im Schaltplan ist er auf 3,3V gelegt,
auf der Platine gibt es ein nicht geroutetes Signal. Ich nehme an, das
ist AREF. Ich würde es im Schaltplan korrigieren.
Noch ein Tipp zu Eagle:
Mit dem Befehl Label kann man die Leitungen im Schaltplan beschriften.
So erkennt man besser, welche Signale aus dem BUS herausgeführt werden.
Ich habe testweise mal alle Labels gesetzt (s. Screenshot).
Im Screenshot ist der Label Befehl (Schaltfläche) unten links gesetzt.
Es ist die grüne Linie mit "ABC" darüber.
In der Vorschau sehe ich den angehängten Screenshot nicht. Ich hoffe, es
klappt trotzdem.
Eine Frage:
Kann man statt dem Mega88 auch einen Mega8 einsetzen? Sie unterscheiden
sich ja etwas, z.B. hinsichtlich der Speicheraufteilung.
Gruß, Bix.
Ist ein tolles Projekt.
Nein.. denn bix hat die aller erste Version der Schaltung verwendet..
Sorry, bix. Aktuell verfolgen wir die Schaltung von Joe G. (etwas weiter
oben) mit einer USB Buchse und FT232RL Optional..
Wäre super, wenn du da auch noch mal einen Blick drauf werfen könntest..
Peter
Peter Sieg schrieb:> Nein.. denn bix hat die aller erste Version der Schaltung verwendet..
Hmmm ... erwischt.
Sehr schönes Layout von Joe, da gibt es nichts zu meckern.
Nur zwei Anmerkungen:
Man könnte beim SD-Slot die Verbindung benachbarter Pads über eine
Leitung außen herum realisieren. Dann ist die thermische Kopplung
geringer und es lässt sich etwas einfacher löten. Ist aber auch kein
Drama, wenn man es so lässt.
Das Via der TXD-Leitung könnte man bei der Gelegenheit auch etwas weiter
weg schieben, um das Risiko eines ungewollten Kurzschlusses zu
minimieren. Platz ist ja genug da.
Die Änderungen sieht man auf den angehängten Screenshots (1=vorher /
2=nachher).
Das Via liegt im zweiten Screenshot in der Massefläche. Ich habe es
extra so dargestellt, damit man besser sieht, wie das Via verschoben
wurde. Ein "Ratsnest" bereinigt es dann wieder.
Man könnte noch, wenn man will, auf dem Toplayer einige Beschriftungen
anbringen, z.B. Markierung von Pin 1 der Stiftleisten und ICs, sowie "+"
bei Elko und LED, zu sehen auf Bild 3.
Man könnte noch einen optionalen Elko am SD-Slot vorsehen.
@bix:
Danke für die Hinweise! Ich nehme sie gerne auf.
Zum Einsatz eines Mega8. Ich denke er ist nur bis 16 MHz spezifiziert.
Ob er mit 20 MHz oder gar mit 24 MHz (Takt aus FT232) geht müßte
getestet werden.
Hi
>Sehr schönes Layout von Joe, da gibt es nichts zu meckern.
Ich würde da noch einigen Handlungsbedarf sehen. Abgesehen vom Layout,
fehlen solche elementaren Dinge, wie Abblockkondensatoren.
MfG Spess
spess53 schrieb:> fehlen solche elementaren Dinge, wie Abblockkondensatoren.
Hallo Spess, beziehst Du Dich auf den aktuellen Schaltplan von Joe?
Gruß, bix
Hi
>Hallo Spess, beziehst Du Dich auf den aktuellen Schaltplan von Joe?
Eigentlich auf das Layout, von dem du geschwärmt hast. Aber in dem
Schaltbild
vermisse ich auch einen Kondensator von AVCC nach AGND. Außerdem ist
z.b. ein 10µ-Elko am Reset-Pin tödlich für ISP.
Um es mal vorsichtig auszudrücken: Hardware ist nicht eure Stärke.
MfG Spess
@Spess
Komm, lasse uns nicht dumm sterben. Wo sind vorsichtig ausgedrückt die
"Eier" in der Schaltung? Wo siehst Du noch einigen Handlungsbedarf?
Genau deshalb soll ja hier diskutiert werden.
Joe
Mit dem Elko am Reset-Pin hat Spess natürlich recht. Der gehört dort
nicht hin. In der Schaltung von Peter, die ich im Kopf hatte, war er
dort nicht vorhanden.
Was den von mir erwähnten fehlenden Elko am SD-Kartenslot angeht, da
gibt es unterschiedliche Varianten.
Manche setzen keinen Kondensator ein, manche einen Abblockkondensator
von 100n. Elm-Chan setzt dort einen 4u7 Elko hin, um Spannungseinbrüche
abzufangen, falls eine SD-Karte im Betrieb eingesetzt wird.
Interessante Links hierzu:
http://www.mikrocontroller.net/articles/MMC-_und_SD-Kartenhttp://elm-chan.org/docs/mmc/mmc_e.html
... im Abschnitt: Cosideration to Bus Floating and Hot Insertion
http://www.dharmanitech.com/2009/01/sd-card-interfacing-with-atmega8-fat32.html
Sicherheitshalber sollte ein 220u Elko am Eingang der
Versorgungsspannung und ein 4u7 Elko direkt am SD-Slot vorgesehen
werden. Vielleicht läuft es ohne - schön. Falls nicht, kann man die
Elkos nachträglich noch bestücken.
AVcc soll gemäß Datenblatt zum Mega88A direkt mit Vcc verbundenwerden,
wenn der ADC nicht benutzt wird. Wenn der ADC benutzt wird, soll AVcc
über einen Tiefpass mit Vcc verbunden werden. Da wir den ADC nicht
verwenden, benötigen wir keinen Tiefpass.
Es ist sicherlich kein allzu hoher Aufwand, einen zusätzlichen
Abblockkondensator für AVcc vorzusehen.
Hi
>Komm, lasse uns nicht dumm sterben.
Was verstehst du an der Aussage, das Kondensatoren fehlen oder falsch
sind, nicht?
Ich beziehe mich mal auf das Layout von 18:36:
Mindesten 50% der Leiterzüge sind, zum Teil wesentlich, länger als
nötig:
- 90°-Winkel sollte man vermeiden.
- Unnötige 'Schlenker' z.B. rechte Seite oben.
- Unnötige Umwege z.B. Pin23 ATMega - Pin1 Speicher
_ ...
Außerdem sieht mir der Isolationsabstand etwas klein aus.
MfG Spess
Mir persönlich gefällt die folgende Variante zum Anschluß der SD-Card
ganz gut.
http://www.dharmanitech.com/2009/01/sd-card-interf...
Damit wird die Schaltung komplett mit 5V betrieben und nur die SD mit
3.3V. Es kann also nicht zur versehentlichen Zerstörung der SD kommen
und der Dram wird innerhalb seines Spannungsbereiches betrieben. Die
notwendigen Z-Dioden und Widerstände würde ich als SMD in die Nähe der
SD bringen und diese könnten dann optional bestückt werden.
Somit hätten wir die zwei möglichen Bestückungsvarianten auf der
Platine:
1. alles wie gehabt, extern (USB) 5V oder extern 3.3V (siehe alte
Schaltung)
2. nur noch extern 5V
Reinhard Kern schrieb:> CP/M u.ä.> Systeme setzen Speichermodelle voraus mit Programm und Daten innerhalb> 64k (wie sollten sie das auch besser wissen), der eZ80 kann aber nur> ganze Seiten einblenden, um also Rom und Ram oder verschiedene> RAM-Bereiche innerhalb 64k abzubilden, braucht man noch etwas externe> Hardware.
Insbesondere CP/M 3 verlangt einen Common-Breich, der in allen Pages
ansprechbar sein soll. Das dürfte ausgesprochen haarig werden und hat
mich bis auf weiteres von dieser Idee abgebracht. Wäre aber sehr nett
gewesen sonst, schade ...
Zu den fehlenden Z80-Opcode-Routinen:
CP/M ist ein auf dem 8080 lauffähiges OS. Der Befehlssatz des Z80 ist
ein Superset des 8080-Befehlssatzes.
Was spricht eigentlich dafür, den FT232RL nur optional vorzusehen?
Wenn man ihn unbedingt vorsieht, kann man sich den ISP-Stecker sparen,
wenn man dem Controller einen Bootlader spendiert.
Das hätte den Vorteil, daß jemand, der keinen ISP verfügbar hat, sich
nur von irgend jemandem ein mal den Bootlader flashen lassen muß und das
Teil dann selbst über den USB programmieren kann.
Das mit dem eZ80 ist eine Schnapsidee, das funktioniert im Leben nicht
mit CP/M.
Uhu Uhuhu schrieb:> Was spricht eigentlich dafür, den FT232RL nur optional vorzusehen?
Aufgrund seiner Bauform lötet er sich nicht so einfach, daher optional.
Wer ISP nicht benötigt, weil er mit Bootloader arbeitet, kann die
Stiftleiste ja weglassen.
Joe G. schrieb:> Mir persönlich gefällt die folgende Variante zum Anschluß der SD-Card> ganz gut.
Wenn Du diese Schaltung meinst:
http://3.bp.blogspot.com/_zqABT3suzXE/S_EwMNYzDhI/AAAAAAAAAW4/MHHY0U-xAhM/s1600/SD_M32_RTC.JPG
(Ver_2.4)
Dort fehlen die Spannungsteiler an den Portpins des ATMega, oder
zumindest Strombegrenzungswiderstände zwischen dem Anschluss des
ISP-Steckers und den Z-Dioden.
Ein 3,3V / 5V Mixbetrieb ist sicherlich für das RAM sowie den Betrieb
des ATMega bei hohen Frequenzen von Vorteil, insbesondere, wenn man noch
übertakten will.
Der optionale FT232 oder alternativ ein Low Drop 3,3V Spannungsregler
wäre damit verpflichtend und der Aufwand steigt.
Ohne 3,3V-Regler geht's zur Not auch (s. Schaltung von Ulrich Radig),
aber nicht ohne Spannungsteiler:
http://www.ulrichradig.de/home/index.php/avr/mmc-sd
heini schrieb:> Insbesondere CP/M 3 verlangt einen Common-Breich, der in allen Pages> ansprechbar sein soll. Das dürfte ausgesprochen haarig werden und hat> mich bis auf weiteres von dieser Idee abgebracht. Wäre aber sehr nett> gewesen sonst, schade ...
Hallo,
das kostet maximal 1 IC, aktuell bei mir ein 74xx139, wenns komplexer
wird ein GAL. Ich habe Flash von 0..7FFF auf den CP/M-Pages und RAM von
8000..FFFF, und das gemeinsam für 2 benachbarte Pages. Mir ist es aber
auch erst nach der ersten Version aufgefallen, dass die eingebauten
ChipSelects dafür nicht flexibel genug sind, daher ein Redesign.
Mit 3 Jumpern kann ich aber auch auf 24bit "flat" umschalten.
Gruss Reinhard
Die Geschwindigkeit des System ist ziemlich lausig. Allein um ein Byte
zu lesen oder zu schreiben werden ca. 220 Takte benötigt - vom
Zeitaufwand zur Befehlsabarbeitung einmal ganz zu schweigen.
Fazit: gute Idee (2 Chip Design & so.) aber Nachbau der
Orginalausführung: Nö.
heini schrieb:> Insbesondere CP/M 3 verlangt einen Common-Breich, der in allen Pages> ansprechbar sein soll. Das dürfte ausgesprochen haarig werden
Warum? Das ist nicht mehr als eine einfache Umsetzung der effektiven
Adresse in die DRAM-Adresse, im Programm. Nicht viel Aufwand.
@Joe: Finde ich gut noch ein paar Ideen zur Platine zu diskutieren..
aber KISS (Keep It Simple & Stupid). Diese Platine soll nahe am Original
mit kleinen Verbesserungen bleiben.. und das Original läuft auch bei mir
auf Lochraster, einem (1) Abblockkondensator und 3,3V und gut ist..
Das Ganze soll ja eigendlich lediglich das leidige von Hand verdrahten
auf Lochraster ersparen..
@Martin: Danke, aber das wußten wir schon.. wenn du Ideen hast wie man
an der orig. Hardware+Firmware noch etwas besser machen kann.. nur zu..
ansonsten gab/gibt es hier auch eine 'Fraktion' die über ein Redesign
ggf. mit 8-bit Sram nachdenken.. auch hier sind sicher weite
Betätigungsfelder für Mitwirkende..
Just my 2 cents
Peter
>Mindesten 50% der Leiterzüge sind, zum Teil wesentlich, länger als>nötig:>>- 90°-Winkel sollte man vermeiden.>- Unnötige 'Schlenker' z.B. rechte Seite oben.>- Unnötige Umwege z.B. Pin23 ATMega - Pin1 Speicher>_ ...
Autorouter halt...
Habe mir gerade mal die Timing-Diagramme im Datenblatt zum DRAM
angesehen. Jeder Zugriff auf das RAM (Lesen, Schreiben, Refresh) wird
durch setzen der RAS\ Leitung begleitet.
Man kann also die übrigen Leitungen des RAM als IO-Port nutzen, solange
RAS\ auf High-Pegel liegt.
Es ist lediglich zu beachten, dass die Adressleitungen vom uC
angesteuert werden müssen, bevor RAS\ auf Low gezogen wird.
Da außer RX und TX keine Ein- und Ausgabe möglich besteht, schlage ich
eine zweireihige Stiftleiste als optionalen Erweiterungsport vor. Er
müsste Spannungsversorgung sowie alle Leitungen zum RAM, insbesondere
RAS\, enthalten.
Man könnte dann weiter ausbauen, z.B. eine RTC, serielle EEPROMS, LEDs,
Taster oder LCD ergänzen.
Die Platine müsste etwa 1/2 cm verlängert werden, wenn man die
Stiftleiste am oberen Ende parallel zum RAM platziert. Die Bestückung
wäre natürlich optional.
A. K. schrieb:>> Insbesondere CP/M 3 verlangt einen Common-Breich, der in allen Pages>> ansprechbar sein soll. Das dürfte ausgesprochen haarig werden>> Warum? Das ist nicht mehr als eine einfache Umsetzung der effektiven> Adresse in die DRAM-Adresse, im Programm. Nicht viel Aufwand.
Vielleicht sehe ich ja den wald vor Bäumen nicht, aber nach meiner
Vorstellung muss für den zugriff auf den Common-Bereich in den ADL-Mode
gewechselt werden.
Ohne mich jetzt näher damit befasst zu haben, gehe ich davon aus, dass
das zu Problemen bei der Systemgenese führen wird, zumal GENCPM
schwerlich in der Lage sein wird, 24-bit-Adressen in .SPR_Dateien zu
verarbeiten.
Eine hardware-basierte Lösung über einen externen Adressdecoder, was
funktionieren sollte, fände ich schauderhaft, aber das ist vermutlich
ein weltanschauliches Problem<g>
Soweit ich erkennen kann hat CP/M 3 eine Form von Bank-Switching
verwendet. Eine Page blieb unverändert, der Rest wurde umgeschaltet.
Solch ein Verfahren lässt sich mühelos in einen CPU-Emulator einbauen,
da ist keine separate Hardware notwendig. Kostet ein paar Takte beim
Speicherzugriff.
Das kann im einfachsten Fall so aussehen:
used_bank = (address>=0xF000) ? 0 : active_bank;
jeweils vor dem Speicherzugriff. Alternativ über Tabelle.
Jungs, jetzt bleibt doch mal auf dem Teppich. CP/M ist tot und wir
haben es hier mit einem reinen Nostalgieprojekt zum Spielen und
schwelgen in netten Erinnerungen zu tun.
Dazu braucht man keinen 50 MHz-Prozessor und mehr als 64 kB waren damals
auch erst mal nicht vorgesehen.
Also: Bringen wir das CM/M 2.2 - Image zum Laufen und freuen uns daran,
daß das Systemchen läuft.
Was mir fehlen wird, ist eher das rat-tatat des zwei Einheiten hohen
3 1/2" Diskettenlaufwerkes beim Warmstart...
Uhu Uhuhu schrieb:> Jungs, jetzt bleibt doch mal auf dem Teppich. CP/M ist tot und wir> haben es hier mit einem reinen Nostalgieprojekt zum Spielen und> schwelgen in netten Erinnerungen zu tun.>> Dazu braucht man keinen 50 MHz-Prozessor und mehr als 64 kB waren damals> auch erst mal nicht vorgesehen.>> Also: Bringen wir das CM/M 2.2 - Image zum Laufen und freuen uns daran,> daß das Systemchen läuft.>> Was mir fehlen wird, ist eher das rat-tatat des zwei Einheiten hohen> 3 1/2" Diskettenlaufwerkes beim Warmstart...
Du kannst Uns ja ein Diskettenlaufwerks Kontroller bauen :) Das währe
soetwas wie das Sahnehäubchen auf dem Kuchen ;)
Uhu Uhuhu schrieb:> Jungs, jetzt bleibt doch mal auf dem Teppich. CP/M ist tot und wir> haben es hier mit einem reinen Nostalgieprojekt zum Spielen und> schwelgen in netten Erinnerungen zu tun.
Also für mich ist das kein Grund. Der Grund warum ich das interessant
finde ist, dass man hier die Chance hat mit 2 DIP-Chips einen kompletten
Rechner aufbauen kann. Und das mit relativ wenig Aufwand.
Die Alternative für mich wäre ein Flash-Dateisystem aus dem ich AVR-Code
direkt ausführen könnte.
Christian Berger schrieb:> Die Alternative für mich wäre ein Flash-Dateisystem aus dem ich AVR-Code> direkt ausführen könnte.
Dann solltest du das machen. Einen Uraltprozessor auf einem modernen µC
zu simulieren, um ein steinzeitliches OS - zu dem es keine Quellen gibt
- darauf laufen zu lassen, ist ohne nostalgischen Hintergrund schlicht
sinnlos.
CP/M ist wie gesagt mausetot und man kann mit dem Projekt eigentlich
nichts sinnvolles anfangen.
Nimm einen großen ATMega, häng einen fetten SRAM-Chip und einen
SD-Card-Sockel dran, pack FreeRTOS drauf, dann hast du was, was auch
nicht mehr Teile hat, als dieses Nostalgieschätzchen hier und zusätzlich
- im Gegensatz zu einem alten CP/M-Image - vollständig in Quellen
verfügbar und einigermaßen Stand der Technik ist.
Uhu Uhuhu schrieb:> um ein steinzeitliches OS - zu dem es keine Quellen gibt
Das ist inzwischen nicht mehr korrekt. Der Quellcode wurde inzwischen
veröffentlicht.
Christian Berger schrieb:> Das ist inzwischen nicht mehr korrekt. Der Quellcode wurde inzwischen> veröffentlicht.
Ah, das wußte ich nicht. Ist ja nett... Wo denn?
Nachtrag zu meinem voherigen Beitrag:
"Große" Festplatten hatten in den 80er Jahren - als CP/M aktuell war -
gerade mal 40 MB. Eine heutige SD-Karte kann CP/M überhaupt nicht
verwalten, ohne daß der größte Teil brach liegt.
Ich finde, daß wir bei dem vorgesehenen Muster mit CPM2.2 und den beiden
Chips beliben sollten.
Falls jemand was anderes bauen will, so sollte er ein neues Projekt
aufziehen und nicht seine Fähigkeiten im Zerreden dieses Projektes
einsetzen.
Für mich ist die ursprüngliche Richtung maßgebend.
Alle anderen Sachen wie
- CPM 3.0
- RTOS mit eigener HW
- SRAM Interface mit riesigen Erweiterungen
sollten in einen anderen Projekt erörtert werden. Mir gefällt das
Projekt hier gerade, weil es so einfach ist.
Habe gerade etwas entdeckt.
In den Kommentaren zum Original-Projekt auf der Seite
http://spritesmods.com/?art=avrcpm&page=4
wird auf ein Testprogramm für den 8080 hingewiesen: (instruction set
test program EX8080.COM) Ist sicherlich hilfreich, wenn man fehlende
Opcodes ergänzen möchte.
Hier der Link:
http://www.schorn.ch/cpm/intro.php
Auf der Seite gibt es auch unterschiedliche Programmiersprachen, unter
anderem Turbo Pascal.
Letztendlich finde ich das Ganze doch so interessant, dass ich ein
"Parallelprojekt" zumindest anfangen werde. Basis wird der aktuelle
ChipBasic2 Computer ohne Modifikationen sein. Dazu ein 64K RAM Modul am
Parallelport, welches zwar schon seit über einem Jahr bei mir existiert
aber erst jetzt durch die ladbaren Treiber wirklich benutzbar wird.
In Punkto Videoauflösung ist es mir gelungen, Treiber für 24 Zeilen a 50
Zeichen und 24 Zeilen a 60 zeichen zu entwickeln. Der Zeichensatz
umfasst 128 zeichen, sowohl normal als auch invers.
In der ersten Stufe (soweit Interesse daran ist), könnte ich ein
einfaches Terminalprogramm integrieren (das RAM-Modul wird dazu nicht
gebraucht). Dazu würde ich mich an z.B VT52 oder VT100 orientieren und
implementieren, was halt möglich ist. Die Frage ist natürlich, ob man
mit 60 zeichen/Zeile einigermassen arbeiten kann.
Die nächste Stufe wäre dann, meinen (weitestgehend vorhandenen) Z80
Emulator an das System anzupassen. Eigentlich wollte ich damit mal einen
ZX81 mit 2K RAM auf dem AVR simulieren, hab aber irgendwann
aufgegeben...
Jörg
Ich finde das Projekt einerseits interessant als CP/M Emulation,
andererseits als kleine Platform für weitere Mini-Computer. Es ist im
Prinzip ja alles dafür da. 128KByte RAM, externer Speicher (in Form
einer SD-Karte) und einer einfachen Schnittstelle nach außen hin.
Weiterhin, alles schön einfach zu löten und per USB eben die Möglichkeit
alles schön versorgen zu können. Als Experimentier-Platform schön
geeignet, und die IOs lassen sich ja auch noch einfach abgreifen.
Kurzum :
- Schönes CP/M Emulation-Nostalige-Projekt
- Einfache Platform zum Aufbau und Experimentieren eines Mini-Computers
Daher will ich auch son Dingen :-)
@Jörg: Prima! Mit deiner Erfahrung und Vorkenntnissen bin ich gespannt!
Und der Herbst kommt ja auch nach dem Sommer ;-) Da kann wieder mehr
gebastelt werden..
Ansonsten freue ich mich aber ersteinmal auf Platine Version 1 zum etwas
stabileren Aufbau des Originals mit Komm. und Stromversorgung über USB..
Peter
Joerg Wolfram schrieb:> Letztendlich finde ich das Ganze doch so interessant, dass ich ein> "Parallelprojekt" zumindest anfangen werde.
Dann eröffne aber bitte auch einen Extra Thread dafür.
@alle
Die Überarbeitung der Schaltung und dem Layout der Version 1.0 sind nun
abgeschlossen. Wie zu sehen, sind nicht alle Änderungen berücksichtigt.
Speziell die Variante mit dem zusätzlichen Busstecker hätte größere
Änderungen bedeutet.
Zur Bestellung der Platinen:
Alle die bei mir Platinen sowie Bauelemente bestellt haben müßten nun
eine Mail in Ihrem Postfach haben. Wer keine Mail bekommen hat, der hat
noch nicht bestellt oder ich habe ihn übersehen, dann bitte wie schon
oben beschrieben nochmal wiederholen. Auf gleichem Wege bekommt ihr das
EEPROM File für den FT232 und eine kleine Hardwaredoku.
Joe
>Es ist im>Prinzip ja alles dafür da. 128KByte RAM, externer Speicher (in Form
Mich wundert schon eine Weile, wie man mit dem 4256 CP/M machen will.
Das sind nicht 128KByte, sondern 128K B i t! Also 16 KByte( x8 ).
Mit 8 Adress und 4 Datenleitungen ist da nicht mehr drin.
http://www.datasheetcatalog.org/datasheet/hynix/HY534256ALJ.pdf
Ich lasse mich auch eines besseren belehren.
ich weiß ncht Michael, aber ein 256 KBit x 4 DRAM könnten gut 1024 KBit
sein, heißt durch 8: 128 KB (steht im DB: 262144 x 4 Bit), und die
Leitungen sind Zeile und Spalte, sollte so stimmen.
Für ein Byte sind immer zwei Lese-/Schreibzugriffe nötig.
Ich hoffe, ich habe kein Blödsinn erzählt, steht ja tw. auch hier im
Thread.
Hi,
Michael_ schrieb:>>Es ist im>>Prinzip ja alles dafür da. 128KByte RAM, externer Speicher (in Form> Mich wundert schon eine Weile, wie man mit dem 4256 CP/M machen will.> Das sind nicht 128KByte, sondern 128K B i t! Also 16 KByte( x8 ).> Mit 8 Adress und 4 Datenleitungen ist da nicht mehr drin.> http://www.datasheetcatalog.org/datasheet/hynix/HY534256ALJ.pdf> Ich lasse mich auch eines besseren belehren.
Wie schon vom Vorschreiber angedeutet:
Hier liegst du ziemlich daneben...
Und irgendwie kann ich deiner Rechnung auch nicht ganz folgen:
Normal ist ja folgendes:
Mit 8 Adressleitungen kannst du 2^8, also 256 Adressen selektieren.
Jede dieser Adressen enhält aber eine "Busbreite" an Bits. In diesem
Fall also vier. Im Ergebnis also 256 Adressen * 4 Bit = 1024 Bit
1024 Bit : 8 = 128Byte! (Also weder das Ergebnis deiner REchnung, noch
irgendeine sonst sinnvolle Angabe)
Also passt irgendetwas nicht...
Die Lösung: Bei diesem Baustein sind die Adressleitungen multiplext.
Ausserdem sind es neun, nicht acht! (A0-A8) Die Adresse besteht aus zwei
je 9 Bit breiten Adresstelegrammen. Somit besteht die Möglichkeit 2^9 *
2^9 = 2^18 Adressen zu Selektieren. (512*512 = 262144)
Jede dieser Adressen enthält eine "Busbreite" an Speicherzellen, also in
diesem Fall vier Bit. Somit hat der Baustein 2^18 * 4 = 1048576 Bit, was
dann 128 KB ergibt.
(Rechnung: 1048576 : 8 = 131072 Byte. Ein KB sind 1024 Byte, folglich
ergibt sich daraus 131072 : 1024 = 128, also 128KB)
Gruß
Carsten
Eine weitere Alternative für die DRAMs wäre, einen optionaler SOJ auf
DIL Adapter mit vorzusehen. Dann könnte man auch alte PS/2 Module
ausschlachten.
Jörg
Joe G. schrieb:> Die Überarbeitung der Schaltung und dem Layout der Version 1.0 sind nun> abgeschlossen. Wie zu sehen, sind nicht alle Änderungen berücksichtigt.
Spess schrieb:
> Außerdem sieht mir der Isolationsabstand etwas klein aus.
Der von Spess festgestellte zu geringe Isolationsabstand bedarf noch der
Korrektur. Also in den Polygon-Eigenschaften den Wert "Isolate" auf
mindestens 1 mm einstellen beziehungsweise den Wert, den der
Leiterplattenfertiger vorgibt.
(Siehe Screenshot, hier habe ich 40 mil bzw. 0.04 Inch eingestellt, was
etwa 1 mm entspricht.)
Die Beschriftung sollte als Vektorfont mit einer Größe von 50 mil und
Ratio von mindestens 20 % ausgeführt sein, sonst sind die Linien zu dünn
und die Beschriftung wird komplett weggeätzt.
Da die Größeneinheit auf Inch eingestellt ist, wären das folgende
Befehle.
change font vector
change size 0.05
change ratio 20
Den Unterschied sieht man auf dem Screenshot "Font". Oben links sieht
man das Wort "Reset" nach der Änderung, unten vor der Änderung.
Der DRC meckert dann auch nicht mehr daran herum.
Viele Grüße, bix
Hi
>Der von Spess festgestellte zu geringe Isolationsabstand bedarf noch der>Korrektur. Also in den Polygon-Eigenschaften den Wert "Isolate" auf>mindestens 1 mm einstellen beziehungsweise den Wert, den der>Leiterplattenfertiger vorgibt.
Man muss allerdings auch nicht übertreiben. Mehr als 25mil brauchst du
nicht. Und das sollte auch jeder Hersteller können.
MfG Spess
Mein erster Computer mit CP/M 2.2 war voll Eigenbau und hatte 4 Karten
im Einschubgehäuse.
Auf der ersten Karte waren nur der Z80 mit Quarz und die PIO zum
Anschluss der selbst gebauten Voll-Tastatur.
Die zweite Karte hatte 32 DRAM Chips mit je 16Kx1, eine Refreshlogik in
TTL, 4 NiCd AA Zellen als Notstromversorgung und einen NE555 mit 10uH
Drossel als Stepupwandler. Weil mir hier zwei Gatter fehlten, aber kein
Platz vorhanden war, hab ich mit etwas Diodenlogik nachgeholfen.
Die dritte Karte enthielt eine CTC und ein diskret aufgebautes
Kassettenrekorder Interface.
Die vierte war die Grafikkarte mit 2kByte RAM für 24 Zeilen mal 64
Zeichen, viel TTL und einem Kanal 3 Modulator. Noch jetzt erinnere ich
mich, wie ich in der Badewanne lag und auf Kästchenpapier die 256
Zeichen aufgemalt und daneben die Hexcodes geschrieben habe.
Das BIOS war auch selbst geschrieben, nach einer kaum lesbaren
Interfacebeschreibung auf braunem Thermokopiepapier aus irgendeiner
Zeitschrift.
Der Computer war ein Spitzenteil womit ich anfangs in Pascal und später
in C programmiert habe. Die 64kByte DRAM teilten sich Betriebssystem,
Arbeitsspeicher und RAM-Disk. Der C-Compiler bestand aus zwei COMs die
man nacheinander vom Kassettenrekorder in die RAM-Disk laden musste um
so den Quelltext zu kompilieren.
Übrigens wurden davon bestimmt 10 Stück nachgebaut und ich habe
zumindest den Aufwand daran verdient. Vom Spaß nicht zu reden.
Die Leiterplatten-Layouts wurden mit Tusche per Hand auf karierten
Karton gemalt und dann im Kontaktverfahren auf Film übertragen.
Und ja, wir haben schon mit Messer und Gabel gegessen.
>(Rechnung: 1048576 : 8 = 131072 Byte. Ein KB sind 1024 Byte, folglich>ergibt sich daraus 131072 : 1024 = 128, also 128KB)
Richtig!
>Die Leiterplatten-Layouts wurden mit Tusche per Hand auf karierten>Karton gemalt und dann im Kontaktverfahren auf Film übertragen.
Ja, das waren noch Zeiten. Kenne ich auch noch. Bis zur 256KByte
RAM-Floppy habe ich es auch noch geschafft.
Aber das war dann mausetot als die Übermacht von AMIGA und IBM-PC kam!
Ich denke auch mit Recht!
Hmm.. mit Recht..?
Nun, ich denke.. was die graphisch und spielerischen Aspekte und
vorallen Dingen die audiovisuellen, erstklassischen Demos angeht..
Amiga=klares JA.
(Inzw. ja auch auf der PC Plattform ein beliebtes Genre)
Aber ansonsten.. ist doch inzw. das 'Netz' der Computer.. soll heißen
ohne
E-Mail, Web, Streaming etc. wäre doch der Frontend=PC 'nur' ein
graphisch, verspielter CP/M Rechner ;-)
Die 'Killerapplikationen'=Textverabeitung, Tabellenkalkulation,
Datenbank gab es 'damals' auch schon (Wordstar, Multiplan, dbase).
Und mit einem ASCII basierten Mini-Linux kann man auch ohne
schnick-schnack Mails lesen und schreiben und Webseiten lesen etc.
Also Inhaltlich/Funktional sind die Urgestalten der CP/M Ära gar nicht
soo
weit weg.. und manchmal sicher noch einfacher zu verstehen und zu
kontrollieren.. nur Kiddies kann man damit schwer hinter dem Ofen
vorlocken ;-) Dazu muß es ja heute klickibund und animiert sein.. -
Inhalt: Nebensache - ;-)
Sorry,
Peter
Uhu Uhuhu schrieb:>> Mit 8MB Flash dürfte sich mit CPM wohl einiges anfangen lassen.>> Eher nicht.
Wieso nicht? Als Massenspeicher. Durchaus typisch für CP/M waren zwei
Floppy-Disk-Laufwerke mit 160KB.
moin moin,
vorsicht, 8MB war doch die maximale Größe je LW die CP/M verwalten
konnte.
WordStar konnte nur Dateien bis 512KB verarbeiten.
Meine RAM-Disk hatte zuletzt 2BM mit 64Stück U61000.
MfG
Pieter
A. K. schrieb:> Wieso nicht?
Weil dann erst ein extra Flash-Filesystem-Treiber für das interne Flash
her müßte. D.h., mit dem Image, das auf dem Brettchen laufen soll, wird
das nix.
Man müßte erst ein maßgeschneidertes CP/M zusammenfrickeln.
Verstehe ich nicht. Ein normales CP/M benötigte einen Floppy-Treiber im
BIOS. Dieses CP/M bräuchte einen Flash-Treiber ohne Filesystem, im BIOS
oder (vorzusgweise) im Emulator. Das Filesytem bringt CP/M selber mit -
muss ja kein FAT sein.
OK, mit dem Filesystem hast du recht.
Die SD-Karte kann man sich trotzdem nicht sparen, wenn man die Daten mit
den CP/M-Tools ins System bringen will.
Aber ich denke, weitere Debatten hier über derlei Verbesserungen
erübrigen sich trotzdem. Hier geht es darum, für das von Peter Sieg
vorgeschlagene System ein Platinchen zu basteln.
Wem das nicht reicht, für den gilt das im Zusammenhang mit dem eZ80
Gesagte: Beitrag "Re: CP/M auf ATmega88"
Für mich ist das hier wirklich ein reines Retro-Projekt. Ich habe nicht
vor, mit CP/M ernsthaft zu arbeiten.
Hallo Martin,
sofern überhaupt Interesse daran besteht, würde ich das im
ChipBasic2 Thread diskutieren.
Hier geht es mehr oder weniger darum, das Teil 1:1 nachzubauen.
Jörg
Joe G. schrieb:> @alle:> Wie Peter schon in beiden Foren geschrieben hat, nehme ich die> Bestellungen für die AVR CP/M Platinen entgegen. Dazu bitte Eure> benötigte Stückzahl, Eure Mailadresse sowie die Versandadresse über> „Feinmechaniker“ an mich senden. Weiterhin würde ich die notwendigen> SD-Card Sockel mitbestellen.
Kurz von Torschluss nochmal nachgefragt...
Wurden die letzten Änderungen in das Layout übernommen
(Isolationsabstand, Beschriftung?). Da ich nichts mehr gehört habe, habe
ich die Änderungen mal eingezeichnet (in die Version vom 6.6.2010), ein
paar schiefe Leitungen gerade gezogen und die Beschriftung für Top und
Bottom-Layer hinzugefügt.
Der DRC läuft nun sauber durch.
Beim Durchsehen der Software fiel mir auf, dass man einige Signale
günstiger verbinden kann, um den Zugriff auf das RAM zu beschleunigen.
Man muss dann nicht so viele Bits per Software einzeln zusammen setzen.
Um jedoch am Original-Layout nichts zu ändern, habe ich noch zwei 3*2
Stiftleisten hinzugefügt, die nirgends angeschlossen sind. Es ist aber
möglich, später durch Auftrenenn von vier Leitungen und Anschluss an die
Stiftleisten zwischen original Layout (Hardware Version 1) und
optimiertem Layout umzuschalten (Hardware Version 2), falls man das
will.
Wie gesagt, es ist optional und freiwillig. Ändert man nichts, läuft
alles wie bisher, so hat man keinen Nachteil.
Die optionalen Änderungen sind im beiliegenden Text "AVRCPM_HW_Rev2"
beschrieben sowie ein kurzes Beispiel, wie die Zugriffsroutinen auf das
RAM sich vereinfachen (dram_getnibble und dram_sendnibble).
Noch eine Frage:
Wie lange dauert die Freischaltung zum Forum normalerweise? Ich kriege
einfach keine Bestätigungsmail und kann mich nicht anmelden, möchte aber
auch bestellen.
Ronny Minow schrieb:> normalerweise bekommst du eine infomail, das du registriert bist.> versuche dich einfach mal einzuloggen...
Die Infomail habe ich nicht bekommen. Wenn ich trotzdem versuche mich
anzumelden, wird angezeigt "Login fehlgeschlagen".
Uhu Uhuhu schrieb:> Welches Forum?
Das beste Forum der Welt meine ich natürlich. Eben genau dieses hier ;-)
@bix
keine Torschlusspanik, ist doch noch ein Tag Zeit. Die letzten
Änderungen (Beschriftung, Isolationsabstand) sind schon eingearbeitet.
Weiterhin noch ein 100n C zwischen /DTR und Reset. Somit könnte der AVR
mit einem Bootloader und Reset über /DTR versehen werden und die
Programmierung über ISP entfällt. Damit sollte die Gefahr, die SD-Karte
versehentlich mit 5V zu versorgen, genommen sein. Die Idee mit dem
kleinen Steckfeld ist gut, ich habe sie übernommen.
@alle
Wer nur als Gast hier im Forum ist, und dennoch bei mir bestellen möchte
bitte das über diese Mail tun: info (at) amesys (dot) de
Joe
Joe G. schrieb:> Die Idee mit dem> kleinen Steckfeld ist gut, ich habe sie übernommen.
Hallo Joe,
danke für die schnelle Antwort.
Damit das mit den Stiftleisten später funktioniert (auf Hardware Version
2 Jumpern), habe ich die im Text mit (*) gekennzeichneten Pins des
ATMega so auf die Lötseite der Platine verlegt, dass man die Leitungen
später einfach durchtrennen kann (erkennbar an den quardatischen
"Vias").
Ist erst die IC-Fassung aufgelötet, kommt man auf der Bauteileseite ja
später nicht mehr an die Leitungen heran.
Es sind beim AVR die Pins 5, 19, 24 und 27.
Pin 19 musste ich vom AVR zum RAM verlegen, damit der Pin zum AVR
einzeln durchtrennt werden kann, ohne die restliche Leitung zu
unterbrechen (s. Bild avrcpm_brd.png).
Hier noch mal eine andere 'Floppy' = diskimage für AVR CP/M, mit
Spielen:
* Mastermind (mmind)(BDS-C Source vorhanden)
* Tic-Tac-Toe (ttt2)(BDS-C Source vorhanden)
* othello (22k Fortran Source vorhanden)
* othello (12k BDS-C Source vorhanden)
* stone (BDS-C Source vorhanden)
Solche images werden ja laut orig. Anweisung direkt mit:
dd if=<image> of=<device> bs=512
übertragen. VORSICHT! Absolut sicher sein, das <device> auch die
richtige
SD Karte ist!! Besser vorher alle anderen Wechseldatenträger abziehen!
(Ein evtl. vorhandenenes Dateisystem wird gnadenlos überschrieben und
man hat ein ideales Objekt für forensische Analysen und Neuformattierung
;-) )
Die cpmtools im Original gibts übrigens hier:
http://www.moria.de/~michael/cpmtools/
Peter
Soo ähnlich sollte die voll bestückte Platine dann aussehen ;-)
Leider kennt Eagle3D die USB Buchse (noch) nicht und auch einige C's
sehen
etwas komisch aus.. na ja.. ;-)
Peter
bix schrieb:> Ich freu mich schon darauf, den FT232 zu löten ;-)
Das ist gar nicht so schlimm. Besorg dir ein SMD-Flußmittel, wie z.B.
Chipquick SMD-4300-TF. Damit gehts fast vonselbst.
Für alte Knacker ist eine Stirnlupe ganz hilfreich, ein Binokular ist
ganz super.
Hier noch eine Rückmeldung vom Entwickler:
---
Hiya,
Damn, I never expected such a thread to grow out of something this silly
:) Even with pre-made PCB's, wow.
I use something which calls itself 'Z80 assembler version 1.8', which is
in the Debian-repositories as 'z80asm'. I thing you can use just about
any
sane Z80 assembler, though.
Jeroen
---
Peter
Ich hab mal angefangen das z80.asm auseinanderzunehmen um zu sehen, wo
es noch hapert.
Der entscheidende Teil kommt ab Zeile 1766, dort sind die ganzen
Ausführungs-'einheiten' zusammengefasst, die die eigentliche Arbeit
machen.
Ich hab da jetzt mal eine OP-Code Tabelle mit reingenommen, aus der
hervorgeht, welcher Befehl welche Flags beeinflusst. Im Moment bin ich
dran, die vorhandenen Funktionseinheiten durchzugehen und zu
kontrollieren, ob die Flagbehandlung mit dieser Tabelle übereinstimmt.
Das Parity-Flag wird leider tatsächlich ziemlich stiefmütterlich
behandelt. So wie das gemacht ist, geht das gar nicht. Es reicht einfach
nicht aus, die Parity nur bei einer direkten Parity-Abfrage auszuwerten.
Da muss auf jeden Fall noch nachgebessert werden.
Wenn sich wer an der Arbeit beteiligen will ....
Bei jeder Funktionseinheit steht dabei, von welchen Opcodes sie benutzt
wird. Eine abschliessende Kommentarzeile
1
; OK
weist darauf hin, dass diese Funktion schon überprüft ist. Im Gegensatz
zu
1
; Not yet checked
Wenn sich wer die Mühe macht, und die noch fehlenden OpCodes zu
implementieren, bitte auf die Flags achten. Die Flagbehandlung kann bei
ähnlichen Befehlen unterschiedlich sein! Das sieht man in der
OpCode-Übersichtstabelle:
1
RLC A
2
RLCA
haben zwar auf den ersten Blick dieselbe Funktion, die Behandlung des
Parity-Flags ist aber anders.
Im Zuge der Kontrolle tausche ich auch die magischen Bitkonstanten für
die Flags gegen besser lesbare 1<<irgendwas Konstrukte aus.
@Karl Heinz Buchegger: Super!! Leider habe ich von Z80 keine Ahnung..
Was ich aber schon geändert hatte, war die dynamische Berechnung der
Bautrate anhand der Quarzfrequenz:
Der so geänderte Code assembliert und läuft (selbst getestet).
Ich empfehle allen Platinenbauer den Quarz zu sockeln.. dann man man
später
einfacher auf einen 32MHz Quarz wechseln..
Den Lochrasteraufbau werde ich so original belassen (20MHz).. da kann
ich
dann aber sehr gerne auch verbesserte Firmware testen..
Bei den Platinen werde ich das dann zuerst mit 20MHz aufbauen, danach
mal mit 32MHz probieren, wie viel das bringt.. und danach die weiter
oben beschriebene Pin-Änderung und read_nibble/write_nibble probieren..
Muß mal sehen, ob es da irgendein fertiges Benchmark-Programm gibt..
Peter
Peter Sieg schrieb:> Was ich aber schon geändert hatte, war die dynamische Berechnung der> Bautrate anhand der Quarzfrequenz:
Machs bitte gleich richtig und rechne das High Register auch aus.
An solchen Stellen bitte auch immer gleich die magischen Konstanten
austauschen, damit man auch ohne Datenblatt zumindest eine Vorstellung
davon bekommt, was da ein/aus geschaltet wird.
Peter Sieg schrieb:> Leider habe ich von Z80 keine Ahnung..
Wenn du den 8080 kannst, ist das kein Problem. Der Z80 hat ein paar
Befehle mehr und einen zweiten Registersatz, auf den mit einem der
Spezialbefehle umgeschaltet werden kann.
Echte 8080-Programme laufen auf ddem Z80 ohne Änderung.
Ich habe den Thread hier von Anfang an mitverfolgt, hatte aber
eigentlich nicht vor, mich zu beteiligen. Leider habe ich gestern in den
von kbuchegg geposteten Source geschaut...
Gestern Abend habe ich von einem alten Speicherriegel ein DRAM (4Mx4,
3,3V, SOJ) runtergeholt, und auf einen Lochrasteradapter fürs Steckbrett
gelötet. Leider habe ich keinen Mega88 mehr gefunden. Deshalb bin ich
gerade dabei, den Source auf Mega8 anzupassen.
Als Assembler benutze ich den avra unter Linux. Die aktuelle Release hat
ein paar Macken, die in der Git-Version behoben sind.
Karl heinz Buchegger schrieb:> Ich hab da jetzt mal eine OP-Code Tabelle mit reingenommen, aus der> hervorgeht, welcher Befehl welche Flags beeinflusst. Im Moment bin ich> dran, die vorhandenen Funktionseinheiten durchzugehen und zu> kontrollieren, ob die Flagbehandlung mit dieser Tabelle übereinstimmt.
Danke dafür. Das hat mir den Einstieg deutlich erleichtert.
> Das Parity-Flag wird leider tatsächlich ziemlich stiefmütterlich> behandelt. So wie das gemacht ist, geht das gar nicht. Es reicht einfach> nicht aus, die Parity nur bei einer direkten Parity-Abfrage auszuwerten.> Da muss auf jeden Fall noch nachgebessert werden.
Entweder verstehe ich da noch etwas nicht, oder die Sache wird so, wie
Sprite_tm sich das vorgestellt hat, nicht funktionieren.
1
do_fetch_af:
2
mov opl,z_flags
3
mov oph,z_a
4
rcall do_op_calcparity
5
andi opl,~(1<<ZFL_P)
6
sbrs temp2,0
7
ori opl,(1<<ZFL_P)
8
ret
Der Code wird bei "PUSH AF" verwendet. Hier wird das Parityflag
berechnet und im Statusregister im kombinierten P/V-Flag gespeichert.
Anschließend wird das Register auf dem Stack gespeichert.
Wenn die letzte OP vor dem PUSH eine arithmetische war, ist das V-Flag
nach dem POP verloren (durch P-Flag vom zuletzt gespeicherten parityb
überschrieben).
Wenn ich richtig liege, fallen mir 3 Lösungsmöglichkeiten ein.
1. Den Parity-Status (parityb) beim PUSH in einem der ungenutzten
Statusregisterbits (Bit 3 oder 5) speichern.
2. Bei jedem Befehl merken, ob Parity gültig ist, und den Merker in
do_fetch_af auswerten.
3. Parity bei den entsprechenden Befehlen immer sofort berechnen und das
P/V-Flag setzen.
Persönlich tendiere ich zu 3. Im 8080-Befehlssatz sind das ja nicht so
viele Befehle, wenn auch häufig vorkommende.
Leo C. schrieb:> Ich habe den Thread hier von Anfang an mitverfolgt, hatte aber> eigentlich nicht vor, mich zu beteiligen. Leider habe ich gestern in den> von kbuchegg geposteten Source geschaut...>> Gestern Abend habe ich von einem alten Speicherriegel ein DRAM (4Mx4,> 3,3V, SOJ) runtergeholt, und auf einen Lochrasteradapter fürs Steckbrett> gelötet. Leider habe ich keinen Mega88 mehr gefunden. Deshalb bin ich> gerade dabei, den Source auf Mega8 anzupassen.>> Als Assembler benutze ich den avra unter Linux. Die aktuelle Release hat> ein paar Macken, die in der Git-Version behoben sind.
Hallo und herzlich willkommen im Mini AVR + CP/M Retro Thread ;-)
Peter
Danke für die Begrüßung. Ich habe übers Wochenende Besuch und bin
deshalb
noch nicht weiter gekommen. Nur ganz kurz:
Der AVRA funtioniert leider nicht richtig. Letzte Nacht habe ich dann
in meiner Verzweiflung den Atmel Windows Assembler unter Wine
ausprobiert. Funktioniert. Prost.
Aber mein Mega8 geht noch nicht. :-(
@Joe: Prima! Bei mir laufen gerade die Urlaubsvorbereitungen.. ;-)
Daher z.Z wenig Zeit.. bin aber schon mal sehr gespannt auf die Platinen
und wie sich die Firmware bis dahin weiterentwickelt hat..
Peter
Leo C. schrieb:> 3. Parity bei den entsprechenden Befehlen immer sofort berechnen und das> P/V-Flag setzen.>> Persönlich tendiere ich zu 3. Im 8080-Befehlssatz sind das ja nicht so> viele Befehle, wenn auch häufig vorkommende.
Das ist auch meine Präferenz.
Bei den 'OK' markierten Sequenzen ist das schon so.
Karl heinz Buchegger schrieb:>> 3. Parity bei den entsprechenden Befehlen immer sofort berechnen und das>> P/V-Flag setzen.> Bei den 'OK' markierten Sequenzen ist das schon so.
Hmm, ich meine, daß man hier:
1
do_op_inc:
2
andi z_flags, (1<<ZFL_C) ; bis auf Carry alles auf 0
3
ldi temp, 1
4
add opl, temp
5
in temp, sreg
6
mov parityb, opl
7
bst temp, AVR_Z ; Zero
8
bld z_flags, ZFL_Z
9
sbrc opl, 7 ; Sign
10
ori z_flags, (1<<ZFL_S)
11
bst temp, AVR_H ; Half Sign
12
bld z_flags, ZFL_H
13
bst temp, AVR_C ; Overflow
14
bld z_flags, ZFL_P
15
ret
das Zwischenspeichern des Operanden in parityb sparen kann, und
bei den Befehlen AND/OR/XOR/DAA das Parityflag direkt berechnen muß.
Oder ich habe eben doch noch etwas übersehen...
Leo C. schrieb:> das Zwischenspeichern des Operanden in parityb sparen kann, und> bei den Befehlen AND/OR/XOR/DAA das Parityflag direkt berechnen muß.
Mag sein.
Ich hab mich noch nicht damit beschäftigt, wo man im Code noch einsparen
bzw. verändern könnte/müsste.
Ich wollte nicht zu viele Veränderungen auf einmal machen. Erst mal eine
Bestandsaufnahme bzw. den Code in eine etwas besser lesbare Form
giessen.
Wenn im ersten Durchgang diese Dinge hier alle verschwunden sind
andi z_flags,0b11101100
und durch besser lesbare Konstrukte in expliziter Bitnamenschreibweise
ersetzt sind,
wenn für alle bisherigen Ausführungseinheiten dabeisteht, von welchem
Opcode sie benutzt werden und die Flags (bis auf das Parity Flag)
überprüft sind,
dann wäre mein nächster Schritt, die Behandlung des Parity Flags in die
relevanten OpCodes einzubauen
gefolgt von:
* wo gibt es offensichtliche Verbesserungsmöglichkeiten
* restliche OpCodes implementieren
Aber das Auseinanderpfriemeln des jetzigen Codes ist mühsam.
PS: Ich kann leider von hier nicht auf das SVN-Repositor zugreifen (Ich
schätze mal, dass da eine Firewall was dagegen hat. Das dürfte ich aber
beim Admin nicht durchbringen).
Karl heinz Buchegger schrieb :
> Mag sein.> Ich hab mich noch nicht damit beschäftigt, wo man im Code noch einsparen> bzw. verändern könnte/müsste.> Ich wollte nicht zu viele Veränderungen auf einmal machen. Erst mal eine> Bestandsaufnahme bzw. den Code in eine etwas besser lesbare Form> giessen.
Ja das verstehe ich. Mir ging es auch nicht um einsparen im Sinne von
Optimieren, sondern darum, daß der Code meiner Meinung nach fehlerhaft
ist.
Ich wollte eigentlich da einsteigen, wo Du es vorgeschlagen hast und bin
dann über die fehlerhafte P/V-Flag-Behandlung gestolpert. Es macht imho
keinen Sinn, überall "; OK" dran zu schreiben, wenn man nachher nochmal
alles umwerfen muß.
> PS: Ich kann leider von hier nicht auf das SVN-Repositor zugreifen (Ich> schätze mal, dass da eine Firewall was dagegen hat. Das dürfte ich aber> beim Admin nicht durchbringen).
Lesend gehts bei mir schon mal.
Inzwischen läuft mein Steckbrett-CP/M-AVR-Rechner. Mit ATmega8,
12.288MHz und 3.3V. Falls jemand Interesse an meinen Anpassungen an
Mega8 hat, würde die etwas polieren, und hier (oder im SVN) hochladen.
Leo C. schrieb:> Ich wollte eigentlich da einsteigen, wo Du es vorgeschlagen hast und bin> dann über die fehlerhafte P/V-Flag-Behandlung gestolpert. Es macht imho> keinen Sinn, überall "; OK" dran zu schreiben, wenn man nachher nochmal> alles umwerfen muß.
OK.
Ich dachte du willst das vereinfachen.
Hmm. die P/V Behandlung sollte meiner Meinung nach bei den paar
Anweisungen schon stimmen. Auch darauf achten, dass dieses Flag eine
Doppelbedeutung hat.
Soweit ich weiss, hat der 8080 nur ein P Flag und kein P/V. Das kam erst
beim Z80. Damit sollten sich sogar beide Prozessoren auseinanderhalten
lassen:
Peter Sieg schrieb:
> @Leo C.: Aber Sicher besteht daran Interesse!
Eigentlich machts ja keinen Sinn, den Mega8 zu nehmen. Bei 3,3V müßte
man die L-Version nehmen, und die geht offiziell nur bis 8 MHz.
Andererseits passt das ja ganz gut zu diesem sinnlosen Projekt. :)
> Und ein Bild des Aufbaus wäre auch schön ;-)
Wieso? ;) Bei 2 ICs und einer SD-Karte gibts doch gar nichts zu sehen.
Ich habe keine brauchbare Kamera. Aber gestern Morgen war mein Besuch
(mit Kamera) noch da, und da habe ich vorsorglich ein paar Bilder
gemacht. Allerdings war das RAM da noch nicht verdrahtet.
Karl heinz Buchegger schrieb:
> Hmm. die P/V Behandlung sollte meiner Meinung nach bei den paar> Anweisungen schon stimmen.
Da habe ich eben bedenken.
> Auch darauf achten, dass dieses Flag eine> Doppelbedeutung hat.
Im jetzigen Programm werden V-Flag und P-Flag getrennt gespeichert.
V im Statusregister und P in "parityb".
Bei PUSH AF wird P ins Statusregister kopiert und auf den Stack
gespeichert.
Nach einem anschließenden POP AF ist ein evtl. vorher berechnetes V-Flag
hinüber.
Bei reinen 8080-Programmen dürfte das keine Rolle spielen, da sie ja
kein
V-Flag kennen. Aber dann kann man sich die V-Flag-Ermittlung auch
sparen.
Und bei (zukünftigen) Z80-Programmen wirds dann fehlerhaft.
Voller Z80-Befehlsatz wäre schon interessant, da z.B. Turbo Pascal nur
auf Z80 läuft.
Mal ne Frage, ohne euch ärgern zu wollen:
Warum habt ihr dem schönen Platinchen keinen VGA-Ausgang und PS2 Eingang
gegönnt? Ein zweiter Atemga8 hätte diese Funktion gut erfüllt. Dann wäre
es ein richtig schöner Stand-Alone Computer.
Gruß,
Markus
Markus schrieb:
> Mal ne Frage, ohne euch ärgern zu wollen:
Die Antwort findest Du ausführlichst, wenn Du den Thread hier liest.
Der zweite Teil wird schwierig...
Ich habe im BIOS mal die Warmboot-Funktion ergänzt (CCP + BDOS neu
laden).
Wer einen funktionierenden Warmboot haben möchte, kann das angehängte
BIOS installieren.
>>Warum habt ihr dem schönen Platinchen keinen VGA-Ausgang und PS2 Eingang>>gegönnt? Ein zweiter Atemga8 hätte diese Funktion gut erfüllt. Dann wäre>>es ein richtig schöner Stand-Alone Computer.>Die Antwort findest Du ausführlichst, wenn Du den Thread hier liest.>Der zweite Teil wird schwierig...
Man könnte ja auch ein zweit-Platinchen basteln. Auf der Seite sind da
ja die RX-TX Anschlüsse zugänglich. Da könnte man ja ein Terminal
anschließen:
http://www.serasidis.gr/circuits/TV_terminal/Small_TV_terminal.htmhttp://tinyvga.com/avr-sdram-vga
In dem Assemblerfile "bios.asm" sind einige Adressen festgelegt:
ccp: equ $3400+bias ;base of cpm ccp
bdos: equ ccp+$806 ;base of bdos
Wo liegt den nun CP/M?
@Leo C.: Prima! Super, das jetzt auch der Warmstart geht.. kannst du
bitte auch das assemblierte Bios.bin hier einstellen.. Welchen Z80
Assembler hast du genommen (Link)?
Danke+Gruss aus Teneriffa,
Peter
Peter Sieg schrieb:
> @Leo C.: Prima! Super, das jetzt auch der Warmstart geht.. kannst du> bitte auch das assemblierte Bios.bin hier einstellen..
Das brauchst Du aber nicht auf Teneriffa? Hoffe ich doch für Dich.
> Welchen Z80 Assembler hast du genommen (Link)?http://www.nongnu.org/z80asm/
Ich habe den genommen, der in meiner Linux Distri drin ist. Sprite_tm
nimmt wohl den gleichen. Jedenfalls lief sein Makefile damit fehlerfrei
durch.
Das Teil ist aber in der Tat etwas eigenartig.
Peter Sieg schrieb:> Zu einem anderen Aufbau sehe ich das aber letztlich genauso.. was> ein 'fauler' Kompromiss ist und viel Rechenpower kostet muß durch> etwas besseres ersetzt werden.. Da kann man beim Ram auch z.B über SRAM> nachdenken.. dann braucht man keinen Refresh mehr..
Mit dem Refresh habe ich mich letze Woche ausgibig beschäftigt. Der
kostet
so gut wie nichts. Ich habe auch mal "hidden refresh" realisiert. Das
lohnt
einfach nicht. Und für die Zeiten, in denen mal keine RAM-Zugriffe
sind (zB. Disk-I/O), bräuchte man den normalen Refresh doch noch.
Viel sinnvoller wäre es, die verwurstete Port-Zuordnung zu verbessern.
Wie's richtig gut geht, findet man (mal wieder) auf der auch hier
allseits
bekannten Seite von Chan.
@Leo
>Viel sinnvoller wäre es, die verwurstete Port-Zuordnung zu verbessern.
Dazu mal eine Frage.
Ist es nicht letztenendes egal wie die Port-Zuordnung zwischen AVR und
DRAM ist ?
Es sind zwar die Adress-Leitungen vertauscht, aber im Prinzip macht es
ja nichts aus, solang beim Schreiben und beim Lesen die gleiche
Zuordnung verwendet wird. Oder hat das Auswirkungen auf den Refresh
(sprich das sequentiell eine Row nach der anderen Refresht werden muß,
und sobald Rows übersprungen werden gehen daten verloren oder ist das
unabhängig davon das sie zu einem anderen Zeitpunkt (aber dann dennoch
im selben zeitlichen Raster) refresht werden.
Also nach meinem Verständnis müsste es eig. egal sein wie die Zuordnung
der Adress-Leitungen ist. Hauptsache sie ist beim Schreiben/Lesen
gleich, und alle Rows werden im festen Raster (aber unterschiedliche
Reihenfolge) refresht.
Ich gestehe aber das ich mir den DRAM-ASM Code noch nicht angeguckt
habe. Hatte nur im Schaltplan gesehen das es etwas "Kraut und Rüben"
war.
TheMason schrieb:> Dazu mal eine Frage.> Ist es nicht letztenendes egal wie die Port-Zuordnung zwischen AVR und> DRAM ist ?
Im Prinzip schon. Das beweist ja auch die Originalschaltung.
Wenn aber zB. die 8 niederwertigen Adressleitungen auf einem Port liegen
würden, könnte man sie zusammen mit einem out-Befehl ausgeben.
Ansonsten muß man die Addresbits durch Bitschiebereien oder
Einzelbit-tests
und -Sets auf die verstreuten Addressleitungen verteilen.
Beim ATmega88 kann man allerdings bei keinenm einzigen der 3 Ports alle
Bits zusammenhängend verwenden. Auf Port B liegt der Quartz, auf Port D
die serielle Schnittstelle, und Port C hat überhaupt nur 6 Bit (wenn man
nicht auf Reset verzichten will, sonst halt 7).
Bei den Adressen kann man hier also gar nicht so viel verbessern.
Die Datenbits sind bei der Schaltung aber auch unglücklich verteilt.
Wenn man WE mit einer der Datenleitungen tauscht, liegen die 4
Datenleitungen
auf dem unteren Nibble eines Bytes.
Dann kann man die zwei Hälften eines Bytes zB. so einlesen
1
in temp,PINC ; 1. Nibble einlesen (untere Hälfte von PC)
2
andi temp,0x0f ; obere Hälfte wegmaskieren
3
swap temp
4
5
;Adressen umschalten ...
6
7
in temp2,PINC ; 2. Nibble einlesen
8
andi temp2,0x0f
9
or temp,temp2 ; Beide Hälften zusammen
Zusammen 6 Befehle, 6 Takte.
Im Originalprgramm gibt es ein Unterprogramm, das zwei mal aufgerufen
wird:
1
;...
2
rcall dram_getnibble
3
swap temp
4
5
;Adressen umschalten ...
6
7
rcall dram_getnibble
8
9
; ...
10
;...
11
12
dram_getnibble:
13
andi temp,0xf0
14
sbic pinc,ram_d0
15
ori temp,0x1
16
sbic pinc,ram_d1
17
ori temp,0x2
18
sbic pinc,ram_d2
19
ori temp,0x4
20
sbic pinc,ram_d3
21
ori temp,0x8
22
ret
Auch wenn man den Unterprogrammaufruf wegläßt (man könnte ja den Code
direkt einfügen), sind das schon 1 + 2x9 = 19 Takte.
Die Adressen-Ausgabe und -Umschaltung kann man aber auch noch deutlich
optimieren. Auch ohne Harwareänderung.
Durch die Änderungen habe ich eine Geschwindigkeitsverbesserung bei
CP/M-Programmen von fast 50% erreicht.
Den Code dazu will ich nachher noch posten. Jetzt ist erst mal Mittag.
@Leo C. nein, brauch ich hier nicht.. aber wenn ich zurueck bin.. :-)
Da faellt mir ein, das ich auch gerne das 2te asm Programm als BIN Datei
haette (war glaube ich cpm.asm -> cpm.bin), dann man ueber die cpmtools
auch ersteinmal ohne z80 Assembler eine neues diskimage erstellen..
Das mit den 50% hoert sich ja schon mal super an!
Gruss Peter
TheMason schrieb:> Na ja. Die Adress-Pin-Belegung ist wirklich nicht die glücklichste. Wär> dann vllt was für eine Folge-Version :-)
Ja, nachdem ich mir das jetzt nochmal angeschaut habe, glaube ich auch,
daß eine neue Sortierung einiges bringen würde. An einen Punkt hatte ich
heute Mittag nicht gedacht: Die Originalroutinen sind auch deshalb
langsam,
weil Sprite_tm viele NOPs im eingefügt hat. Alleine das weglassen der
überflüssigen NOPs dürfte den Zugriff schon deutlich beschleunigen.
Peter Sieg schrieb:> @Leo C. nein, brauch ich hier nicht.. aber wenn ich zurueck bin.. :-)> Da faellt mir ein, das ich auch gerne das 2te asm Programm als BIN Datei> haette (war glaube ich cpm.asm -> cpm.bin), dann man ueber die cpmtools> auch ersteinmal ohne z80 Assembler eine neues diskimage erstellen..
Siehe Anhang.
Ich hoffe, es ist das richtige. Das bios ist da schon mit drin.
TheMason schrieb:> Na ja. Die Adress-Pin-Belegung ist wirklich nicht die glücklichste. Wär> dann vllt was für eine Folge-Version :-)
Die ungünstige Belegung vom RAM zu den Ports wurde hier schon
diskutiert, siehe diverse Posts vom 12.06.2010 und folgende.
Aus diesem Grund wurde auch das Layout geändert und Platz für ein paar
Jumper geschaffen, um zwischen alter und neuer Belegung umzuschalten.
Die ungünstigen Leitungen zum AVR sind gegenüber dem ersten Layout von
Joe auf die Lötseite verlegt, so dass man auch bei bestücktem Board
nachträglich noch Leiterbahnen auftrennen und Patchen kann.
Gruß, bix
Im Anhang ist mein aktueller Softwarestand. Es sind eine Menge
Änderungen und Erweiterungen. Sicher wäre es besser gewesen, die
Änderungen schrittweise zu posten, aber das schaffe ich wohl nicht.
Erst mal das wichtigste:
Im CPU-Emulator habe ich alle Flags so eingestellt, daß
sie sich (möglichst) wie auf einem 8080 verhalten. Der Emulator kann
bisher nur 8080, und Software, die anhand der Flags glaubt, einen Z80
unter sich zu haben, fällt mit großer Wahrscheilichkeit aufs Kreuz, wenn
wie Z80-Befehle dann nicht da sind. Und diese Software gibts für CPM.
(siehe auch
Beitrag "Re: CP/M auf ATmega88")
Der 8080 Befehlssatz ist jetzt komplett und weitere Fehler habe ich
keine mehr gefunden. (Was aber nichts heißen muß.)
Jetzt kommen meine Spielereien:
* Schnellere DRAM-Routinen
Geht jetzt nur, wenn man am Prozessor 2 Leitungen vertauscht.
Sonst muß man die alten Routinen verwenden.
Es könnte sein, daß das Timing für sehr langsame (alte) RAMs zu scharf
eingestellt ist. Das muß nochmal überprüft und evtl. geändert werden.
* Interrupt und Empfangspuffer für USART Input.
Mich hats einfach genervt, das immer Zeichen verloren gehen, wenn man
mit der Maus in die CP/M-Console pasted.
* Timer-Interrupt mit 1ms Auflösung. War in erster Linie für
Performance-Messungen gedacht, kann aber auch als Echtzeituhr
verwendet
werden. 32 Bit Sekundenzäler ala UNIX time_t. Nachdem ich das fertig
hatte, habe ich beim simh Altair 8800 Simulator
(http://www.schorn.ch/cpm/intro.php, tolles Teil übrigens)
noch eine andere Idee gesehen, die ich dann auch noch eingebaut habe:
Man kann vom CP/M aus einen Timer triggern, der ggf. die abgelaufene
Zeit auf die Console schreibt.
Folgende DEFINEs kann man dem Assembler auf der Befehlszeile mitgeben
(Make-/Projektfile):
DRAM_DQ_ORDER : 0 = Original Pinbelegung. 1 = WE und DQ1 vertauscht.
D.h. auf PC0..PC4 sind die DRAM-Datenbits.
In meinem DRAM-Datenblatt heißen die Datenleitungen DQ und sind
von 0 bis 3 durchnumiert.
Achtung: Bei Sprite_tm (und im Datenblatt seines DRAMs) laufen
die Nummern von 1 bis 4.
Bei der alten Pinbelegung (DRAM_DQ_ORDER = 0) werden die alten
Routinen verwendet, sonst die neuen. Wer es anders haben möchte,
kann ja mal nach "CLASSIC_DRAM" suchen. Neue Software mit alter
Pinbelegung geht aber nicht. Das habe ich zwischendurch mal
rausgeworfen, als ich bei den vielen #if/#else den Durchblick
verloren hatte.
Target-CPU : atmega8, atmega168 oder atmega88. Default ist atmega88
Ich habe nur atmega8 getestet, weil ich die anderen erst
bestellen müßte (Oder ein anders Gerät fleddern :).
F_CPU : Taktfrequenz. Default ist 20MHz
BAUD : Default ist 38400
Im Programm gibts noch weitere Macros:
REFR_RATE : DRAM Refresh-Rate. Eingestellt sind die üblichen 15.6µs,
entspr 64KHz. Um den Interrupt-Overhead etwas zu reduzieren, wird
der Timer auf die halbe Rate programmiert, und dann immer 2 Reihen
auf einmal aufgefrischt.
EM_Z80 : Auf 1 setzen, wenn man einen 8080 mit Z80-Flags testen will.
(Oder wenn man alle Z80-Befehle eingebaut hat :)
Kritik in Form von Patches willkommen.
Update: Der Timer wird jetzt in einem vernünftigen Format ausgegeben.
Die Uhr (Uptime) ist der Einfachheit halber im gleichen Format.
Außerdem hänge ich noch ein kleines Progrämmchen an, mit dem man den
Timer bedienen kann.
Zum Vergleich habe ich noch die Zahlen von einem Simulator auf meinem
PC dazugetan. (08/15 PC mit 2,5MHz Athlon 4850e)
Mein AVR läuft nur mit 12,288 MHz. Deshalb habe ich die Zahlen noch für
20MHz hochgerechnet. Die Zahlen erscheinen mir durchaus plausibel, wenn
ich an die Geschwindigkeit von meinem 4MHz CP/M-Rechner zurückdenke.
Ganz oben hat Jörg Wolfram geschrieben, daß er mit einem AVR ca. 2MHz
Z80-Geschwindigkeit erreicht hat. Na, dann gibts hier ja noch einiges
an *Spiel*raum...
@alle
Die Platine scheint fehlerfrei zu sein. CP/M bootet auch mit 24 Mhz
externen Takt über den USB Treiber. Bei alten SD Karten schlägt bei der
MMC Initialisierung das Timeout zu (Karte läßt sich für eine Antwort zu
lange Zeit).
Die neue Software (mit alter Hardware) von Leo C. läuft bei mir noch
nicht. die ipl Meldung kommt nicht. Mal suchen...
Joe G. schrieb:> Die neue Software (mit alter Hardware) von Leo C. läuft bei mir noch> nicht. die ipl Meldung kommt nicht. Mal suchen...
Welche hast Du denn versucht? Und mit welchem Prozessor?
Ich frage deshalb, weil wir es mal vom Mega168 hatten, und ich bei der
Auswahl desselben einen dämlichen Fehler eingebaut habe.
Hast Du den Ramtest eingeschaltet?
Joe G. schrieb:> Deine Version vom 01.07, der Option DRAM_DQ_ORDER = 0, und dem Mega168.
#elif defined atmega168
.include "m8def.inc"
Bitte .include korrigieren. :-(
hab ich es überlesen?
Gibt es Alternative(n) zu dem verbauten DRAM Chip?
Welchen SRAM müsste ich z.B. nehmen? Und wie anschließen (mit einem
Multiplexer, oder Latchs?), damit die Software nicht geändert werden
muss?
nix_könner schrieb:> Gibt es Alternative(n) zu dem verbauten DRAM Chip?
Ja, größere, und evtl. (aber eher nicht) kleinere DRAMs.
Auf die Schnelle habe ich 1MBit bis 16MBit gefunden.
Und natürlich gibts die in verschiedenen Geschwindigkeiten.
Und dann auch noch 3,3V und 5V VCC. Wobei die 5V-Typen hier auch mit
3.3V laufen. Aber die Spannung dürfte auch wieder Einfluß auf die
Zugriffszeiten haben.
> Welchen SRAM müsste ich z.B. nehmen? Und wie anschließen (mit einem> Multiplexer, oder Latchs?), damit die Software nicht geändert werden> muss?
SRAM macht bei diesem Projekt überhaupt keinen Sinn. Der Witz ist hier
ja gerade, daß man mit 2 Billigchips auskommt.
PS/2 SIMs sind eine gute Quelle.
Ich habe meinen Chip (1MBit x 4)von einem 32MB Modul runtergelötet. Da
sind jetzt noch 15 Stück drauf. Weitere Riegel liegen hier auch noch
rum.
@all
Ich habe also welche übrig. Wer sonst keine findet...
@Leo C.
Ich habe heute nochmal beide RAM Varianten getestet. Gestern war der
Ramtest leider doch aus.
Testumgebung: einmal 8 Mhz Takt / einmal 24 Mhz Takt
Ergebnis Taktunabhängig
RAM-Test alte Variante:
23 < 00
23 < 01
22 < 02
23 < 03
26 < 04
27 < 05
26 < 06
Es sieht also so aus, ob Bit 5 und Bit 1 immer 1 sind.
RAM-Test neue Variante:
00 < 00
00 < 01
00 < 02
00 < 03
als ob er überhaut nicht angesprochen wird. Ich werde mal WE an den Oszi
klemmen.
Joe G. schrieb:> @Leo C.> Ich habe heute nochmal beide RAM Varianten getestet. Gestern war der> Ramtest leider doch aus.
Aha, so macht es mehr Sinn.
> Testumgebung: einmal 8 Mhz Takt / einmal 24 Mhz Takt
Bei 24Mhz ist der Refresh bei langsamen RAMs an einer Stelle an der
Grenze. Die Schreib/Leseroutinen von Sprite_tm haben Luft ohne Ende. Die
gehen wahrscheinlich auch bei 100MHz noch. Und meine Routinen nimmst Du
ja nicht.
> Ergebnis Taktunabhängig>> RAM-Test alte Variante:> 23 < 00> 23 < 01> 22 < 02> 23 < 03> 26 < 04> 27 < 05> 26 < 06> Es sieht also so aus, ob Bit 5 und Bit 1 immer 1 sind.
Das ist das Bit, das ich mit WE getauscht habe. Ich hab mir das jetzt
nochmal genau angeschaut (Assembler Listing). Testen kann ich leider
nicht. Ich meine, daß bei "DRAM_DQ_ORDER = 0" alle Bits an der richtigen
Stelle für die Originalschaltung sind.
> RAM-Test neue Variante:> 00 < 00> 00 < 01> 00 < 02> 00 < 03> als ob er überhaut nicht angesprochen wird. Ich werde mal WE an den Oszi> klemmen.
Daß, das gehen sollte, stand ja nie zur Diskussion.
> Deine Version vom 01.07, der Option DRAM_DQ_ORDER = 0, und dem Mega168.
und
> .include "m8def.inc"> ... hatte ich schon geändert.
Das gibt beim Übersetzen noch einen Fehler:
| avr-m8_z80.asm(1230): error: Old harware can not work with new software!
Die Zeile 1230 und drumherum müßtest Du also auch geändert haben, sonst
hättest Du nicht fehlerlos übersetzen können. Man kann diese
"Sicherheitsabfrage" einfach rauswerfen. Darüber wird (bei DRAM_DQ_ORDER
= 0) der richtige (dh. der Originaltreiber von Sprite_tm) genommen. Das
meine Routinen mit der Originalpinbelegung nicht gehen, hatte ich ja
schon geschrieben.
Sonst fällt mir dazu nichts mehr ein. Wenn die Hardware mit dem
Originalprogamm funktioniert, dann müßte sie mit meinem Programm und den
oben beschriebenen Anpassungen auch laufen.
Das 4:0 hat es gebracht. Die Variante "DRAM_DQ_ORDER = 0" geht nun. War
mein Fehler, 0 und 1 vertauscht. Die neue Variante "DRAM_DQ_ORDER = 1"
natürlich mit den beiden getauschten Leitungen bringt immer noch
> 00 < 00> 00 < 01> 00 < 02> 00 < 03
bei RAMORG 1. Bei RAMORG 0 kommt nicht mal mehr eine Ausschrift, hängt
sich irgendwo ganz auf.
Joe G. schrieb:> bei RAMORG 1. Bei RAMORG 0 kommt nicht mal mehr eine Ausschrift, hängt> sich irgendwo ganz auf.
RAMORG=0 ist sozusagen ungetestet. Das hätte ich wohl rauswerfen sollen.
RAMORG=1 sollte aber wirklich funktionieren.
Allerdings kommen hier so langsam die Zugriffzeiten, die genaue
Chiporganisation usw. ins Spiel....
> Und welchen RAM-Chip hast Du (Genaue Typbezeichnung mit Speed-Code)?
> einen MT4C4256-80
Da dürfte es eigentlich keine Timing-Probleme geben.
Kannst Du Die Schaltung probeweise mit 5V betreiben?
Dann ohne SD-Karte um zu sehen, ob sie dann über den RAM-Test kommt.
Leo C. schrieb:> Kannst Du Die Schaltung probeweise mit 5V betreiben?> Dann ohne SD-Karte um zu sehen, ob sie dann über den RAM-Test kommt.
Auch mit 5V ohne Erfolg.
Ich habe nun mal die Signale am RAM und am AVR gemessen. Wenn das
Programm in den Ramtest läuft liegt /WE ständig auf Low und I/O1 bis
I/O4 liefert keine Daten bzw. es kommen keine vom AVR. /RAS und /CAS
liegen aber normal an.
Joe G. schrieb:> Wenn das Programm in den Ramtest läuft liegt /WE ständig auf Low> und I/O1 bis I/O4 liefert keine Daten bzw. es kommen keine vom AVR.
Du hast anscheinend ein andere Programm als ich. ;)
Du könntest mal schauen, ob die entsprechenden Portbits als Ausgänge
programiert werden, und zb. an der WE-Leitung auch High-Pegel ausgegeben
werden. Bei mir ist das der Fall.
[avr-m8_z80.lst]
1
; - Setup Ports
2
...
3
000045 e300 ldi temp,PC_OUTPUT_MASK
4
000046 b907 out DDRC,temp
5
6
...
7
8
dram_write:
9
0002f6 94f8 cli
10
...
11
0002f7 b117 in temp2,DDRC ;DRAM data ports as outputs
Im Anhang der derzeit aktuelle Softwarestand:
Die Änderungen umfassen die Änderungen von Leo C. (siehe oben), die
Änderungen für ein korrektes Timing des MT4C4256-80 und die Änderungen
zur korrekten Initialisierung der SD-Card. Damit sollten nun auch alte
langsame Karten zuverlässig laufen.
Bei Hardwareänderungen bitte beachten:
/WE (PC1 – Pin 24) wird mit IO3 (PC4 – Pin 27) getauscht. Auf der
Leiterplatte auch an den rechteckigen Durchkontaktierungen erkennbar.
Welche RAM-Version benutzt wird kann als Compileroption angegeben
werden.
Kritik erwünscht
FÜr den PMD-85, ein tchech. Homecomputer der 80er Jahre, gibt es einen
Emulator auf AVR-Basis (http://pmd85.topindex.sk/)
Dieser emuliert ebenfalls einen 8080-Prozessor. Vielleicht wäre dieses
Projekt auch einen Blick wert?
VolkerP
Neuigkeiten
Ich habe "meine" Sourcen in ein SVN gestellt auf daß man hier zugreifen
kann:
http://cloudbase.homelinux.net/viewvc/avr-cpm/trunk/
Meine Änderungen kann man dort nachlesen. Wer Fehler findet, der ...
muß sie nicht behalten, sondern darf sie gerne hier mitteilen und am
Besten gleich korrigieren. Ich werde die nächsten Tage nicht dazu
kommen.
Ich habe eine radikal geänderte Portbelegung getestet. Das Konzept dazu
habe ich (mal wieder) bei Chan abgekupfert:
http://elm-chan.org/works/vp/report.html
Der Geschwindigkeitsgewinn ist nicht überwältigend, aber doch
beachtlich. Und als Belohnung gibt es 3 freie Ports.
Hier mal die Ergebnisse mit meiner weiter oben geposteten, nicht
repräsentativen Testschleife:
AVR Atmega mit 20 MHz:
-----------------------------------------------------------------------
| Laufzeit Laufzeit Z80
| Gesamt pro Z80 Takt Speed
----------------------------+------------+----------------+------------
Letzter Stand: | 5,921 s 2,05 µs 478 KHz
aktuell: (trunk 28) | 3,239 s 1,12 µs 890 KHz
geänderte Portbelegung: | 2,974 s 1,03 µs 969 KHz
(experimental 25) |
Inzwischen habe ich einen 20MHz Quarz an meinem Mega8
(undervoltaged/overclocked :). Mit 24.5 MHz macht er allerdings die
Grätsche.
Den 1MHZ 8080/Z80 wird man mit dem jetzigen Konzept von Sprite_tm
wahrscheinlich noch erreichen können. Für die 2 MHz wird man wohl den
schönen Interpreter wegwerfen/total umkrempeln müssen.
Auf jeden Fall gibts noch viel zu tun. Für den Fall, daß jemand
Langeweile hat, hänge ich einfach mal meinen uneditierten Merkzettel mit
ein paar Ideen an. Die Liste ist sicher nicht vollständig.
Wünsche schönes Wochenende
avr_cpm Wunschliste
-------------------
• USART IO per Interrupt
(DONE für Input)
• DRAM
∘ Adress- und Daten-Ports neu sortieren für schnelleren Zugriff
∘ Adress- und Datenleitungen multiplexen: --> 4 freie Ports
(ist ohne Performanceverlust möglich)
∘ memRead/WriteWord?
∘ Memory block transfer?
• DEBUG/trace steuerbar durch Z80-Programm?
(Über IN/OUT-Interface)
• Andere (größere) Disk-Formate
dpb muß für avr zugänglich sein?
• Register umorganisieren
∘ für effizienteren code
∘ R1 als 0-Register? (wie gcc-avr)
• Source aufteilen
∘ console I/O (USART)
∘ mmc
∘ dram
∘ z80 emu (?)
• Z80 Befehle
• bios sector blocking/deblocking (avr)
• Mehrere CP/M-Laufwerke auf einer SD ?
∘ CP/M-Images in FAT-Dateisystem
∘ Diskimages hintereinander kopieren
Hallo. Bin wieder da ;-)
Habe mir gerade den aktuellen Stand von avr_cpm.asm (Joe G.) gezogen und
versucht ersteinmal für die original HW zu assemblieren mit:
#ifndef DRAM_DQ_ORDER /* If this is set to 1, the portbits */
#define DRAM_DQ_ORDER 0 /* for DRAM IO3 and WE are swapped. */
#endif
dabei bekomme ich:
C:\E\AVR\avr-cpm\avrcpm\avr\z80.asm(1253): error: Old harware can not
work with new software!
???
Ich finde die Optionen zur DRAM Selektion SEHR unübersichtlich!
Das versteht doch kein Mensch mehr.. da müssen andere Namen+mehr
Erläuterungen in den ASM Quellcode..
Nun, was muß ich wie setzen, um ersteinmal für die original HW zu
assemblieren??
Danach wollte ich dann mal probieren PC1 + PC4 zu tauschen.
Das sollte dann wohl mit #define DRAM_DQ_ORDER 1 gehen?
Peter
ok. Habe mit DRAM_DQ_ORDER 1 assembliert und PC1 und PC4 getauscht.
Damit läufts und MBASIC arbeitet jetzt!! Hurra!
Super Arbeit! Vielen Dank dafür ;-)
Trotzdem wäre es schön, wenn die original HW über die entsprechende
Option
weiterhin nutzbar wäre mir der neuen SW...
Jetzt müssen nur noch die Platinen kommen.. dann gehts weiter...
Peter
@Peter
Wilkommen im Backofen!
Die alte HW Variante läuft auch mit der von Dir gezogenen
Softwareversion. Gib einfach unter Assembler Optionen -DDRAM_DQ_ORDER=0
ein.
Damit wird CLASSIC_DRAM = 1 gesetzt. Ja, ist unglücklich, einmal 0 und
einmal 1. Die Software geht nun auch ohne Pintausch.
Zusätzlich mußt Du noch die Fehlermeldung deaktivieren!
; ------------------ DRAM routines -------------
; TODO:
#if DRAM_DQ_ORDER == 1
#define CLASSIC_DRAM 0
#else
#define CLASSIC_DRAM 1 /* Change manualy, if you want new hw w/ old
sw */
#endif
Die Abfrage hier kannst du streichen
; #if DRAM_DQ_ORDER == 0
; #if CLASSIC_DRAM == 1
; #error "Old harware can not work with new software!"
; #endif
; #endif
Die Hardware ist auf dem Wege zu Dir.
Gruß
Joe
Danke Joe.
Die von dir genannte Abfrage, welche den Fehler produziert MUSS dann
aber
raus, da ich ja zuerst mit DRAM_DQ_ORDER = 0 nicht erfolgreich
assembliert hatte.. ;-)
Peter
Peter Sieg schrieb:> Die von dir genannte Abfrage, welche den Fehler produziert MUSS dann> aber> raus, da ich ja zuerst mit DRAM_DQ_ORDER = 0 nicht erfolgreich> assembliert hatte.. ;-)
Vergiß den Kram einfach. Zieh Dir lieber mal das hier, und sag
Deine Meinung dazu:
http://cloudbase.homelinux.net/viewvc/avr-cpm/trunk/avrcpm/avr/
[edit]
Ich sehe gerade, daß beim aktuellen Stand bei den #defines oben die
Pintauschmöglichkeit über "DRAM_DQ_ORDER" noch drin ist, die
Schreib/Lese-Routinen das aber nicht mehr unterstützen.
Falls ein überwältigendes Interesse daran besteht, die äußerst
unpraktische Originalpinbelegung am Laufen zu halten, werde ich das
vielleicht wieder einbauen. Bisher besteht allerdings gar kein
Interesse.
Peter Sieg schrieb:> Hallo. Bin wieder da ;-)
Ich jetzt auch. :)
> Ich finde die Optionen zur DRAM Selektion SEHR unübersichtlich!> Das versteht doch kein Mensch mehr.. da müssen andere Namen+mehr> Erläuterungen in den ASM Quellcode..
Das Ganze war nur zum Testen gedacht. Insbesondere die alten Routinen
hatte ich zuerst nur dringelassen, damit man mit den neuen vergleichen
kann.
Dann wurde mir der Aufwand zu groß, die neuen Routinen für alte
Pinbelegungen einzubauen und hatte dann schnell diese Schalter eingebaut
und nicht mal richtig getestet.
@Leo C. Solange es ja nur 2 Leitungen/Pins sind, die zu tauschen sind..
sehe ich da auch kein wirkliches Problem.. habe die jetzt auf meiner LR
Version umgelötet.. wenn ich die Platinen bekomme.. mach ich das da dann
genauso.. ist ja ein prima Geschwindigkeitszuwachs für die kleine
Änderung.
Hast du für deine Speedmessungen eigendlich ein fertiges Programm
genutzt?
Falls ja, könnte man das ja als Referenz nehmen..?
Anschauen werde ich mir das alles in den nächsten Tagen.. bin aber kein
Experte.. daher kann ich da selbst 'nur' lernen.. ;-)
Aber MBASIC.COM läuft jetzt! Das ist doch schon mal was! Gleich mal ein
paar Basic Programme raussuchen ;-)
Dann wollte ich mal schauen, ob mal ohne großen Aufwand die das
Dickimage
vergrößern kann.. z.B mehr Sektoren etc. etc... 250kb sind schnell
voll..
und selbst auf einer winzigen 16MB SD Karte ist so viel Platz ;-)
Auf jeden Fall freut es mich riesig, das aus diesem 'sinnlosen'
Proof-of-Concept ein richtiges, kleinen Bastelprojekt geworden ist!!
Und die Verbesserungen können sich sehen lassen:
* CP/M Warmstart
* 8080 Opcodes korrigiert
* Dram Access beschleunigt
Peter
Huch, ist hier ein Posting von mir gelöscht worden, oder habe ich das am
Montag tatsächlich nicht abgeschickt? Fällt mir jetzt erst auf, weil ich
jetzt auch ein Bild von dem "Gerät" schicken wollte, daß ich am Montag
angekündigt hatte. Ich habe es gestern aufgebaut, und es läuft.
Also auf ein Neues.
Peter Sieg schrieb:> @Leo C. Solange es ja nur 2 Leitungen/Pins sind, die zu tauschen sind..> sehe ich da auch kein wirkliches Problem.. habe die jetzt auf meiner LR> Version umgelötet.. wenn ich die Platinen bekomme.. mach ich das da dann> genauso.. ist ja ein prima Geschwindigkeitszuwachs für die kleine> Änderung.>> Hast du für deine Speedmessungen eigendlich ein fertiges Programm> genutzt?> Falls ja, könnte man das ja als Referenz nehmen..?
Das "Testprogramm" ist hier:
Beitrag "Re: CP/M auf ATmega88"> Aber MBASIC.COM läuft jetzt! Das ist doch schon mal was! Gleich mal ein> paar Basic Programme raussuchen ;-)
MBASIC ist leider immer noch A-langsam. Ich habe praktisch nur ELIZA
ausprobiert, und die ist nicht benutzbar.
In BASIC kannst Du Zeiten z.B. so messen:
1
100 REM Timertest
2
110 TCTRPORT = &H40
3
120 REM Start timer
4
130 OUT TCTRPORT,1
5
140 REM Do something
6
150 FOR I=0 TO 200
7
160 IF I MOD 10 = 0 THEN PRINT ".";
8
170 NEXT
9
180 REM Stop timer, print result
10
190 OUT TCTRPORT,15
11
200 PRINT
12
210 PRINT "Done."
13
220 END
> Dann wollte ich mal schauen, ob mal ohne großen Aufwand die das> Dickimage> vergrößern kann.. z.B mehr Sektoren etc. etc... 250kb sind schnell> voll..> und selbst auf einer winzigen 16MB SD Karte ist so viel Platz ;-)
Dazu habe ich am Montag auch einiges geschrieben. Jetzt nur kurz
Stichworte: Bios, Tabellen DPH, DPB, ...
Inzwischen bin ich sozusagen dran. Aber erst kommt das Sector
Blocking/Deblocking an die Reihe.
Zu den Bildern:
Das Gehäuse ist dieses hier:
http://www.pollin.de/shop/dt/MTcwOTcyOTk-/Computer_und_Zubehoer/Hardware/Laufwerke_Cardreader/Card_Reader_UCR_61S.html
Als (SD-)Kartenleser war das Gerät am PC absolut unbrauchbar. Aber 1€
für Gehäuse + SD-Slot ...
Edit:
Beim 2. Bild habe ich leider daneben gehauen. Da wollte ich eigentlich
auch eine verkleinerte Version schicken. Tut mir leid.
Peter Sieg schrieb:> Erste aufgebaut und läuft ;-)
Sieht doch gut aus!
Übrigens, Abblock C's sind dafür da, dass man sie als fehlend im Layout
ktitisiert und später nicht bestückt ;-)
Joe G. schrieb:> Übrigens, Abblock C's sind dafür da, dass man sie als fehlend im Layout> ktitisiert und später nicht bestückt ;-)
Genau! ;-) ;-)
Peter
Meine Platine ist auch da (schon vor 1-2 Wochen, hatte aber erst letztes
WE Zeit sie zu bestücken). Lauffähig ist diese, allerdings zickt der
FT232 noch rum. Habe den Treiber für den VCP installiert, bekomme aber
mit Putty dennoch kein Zeichen rein/rausgeschaufelt. Muß da mal
ausprobieren. CP/M hab ich demnach noch nicht getestet. Werde mir aber
die Sourcen von SVN runterladen und mal durchstöbern. Vllt auch CP/M zum
laufen bringen. Aber muß mich da erst einlesen.
Dickes Lob an Joe für die Sammelbestellung und Peter für die Initiative
dieses Projektes. Weiter so Jungs. Klasse :-)
Leo C. schrieb:> Im Debugger habe ich folgende kleine Schleife laufen lassen:> MVI A,01 ;> OUT 40 ;Start Timer Takte> LXI H,0000 ; 10> DCX H ; 6 -\> MOV A,H ; 4 |> ORA L ; 4 |> PUSH PSW ; 10 | 44 * 65536 = 2883584> POP PSW ; 10 |> JNZ 0107 ; 10 -/> MVI A,02 ; 7> OUT 40 ;Stop Timer 11> NOP ; gesamt Anzahl Takte: 2883612
Hi Leo C.
wäre es nicht super, diese 'Benchmark' Routine in dein timer (t.com)
Programm mit aufzunehmen..? -> t b würde dann den Timer starten,
die Schleife ausführen und direkt danach die verstrichene Zeit
ausgeben..
So hätten wir ein ungefähres Mass für Optimierungen..
Habe die 2te Platine noch ohne HW-Änderungen am laufen mit D* = 0.
=> geht also noch mit den alten Sprite_tm DRAM Routinen..
BTW: Welches fuses hast du für den Atmega8 gesetzt?
Möchte da auch mal einen mir 20mhz + 3,3v 'quälen' ;-)
Peter
Hmm. Ein normaler ATmega8 läuft bei mir nicht mit 3.3V und 20MHz.
lfuse=0xff; hfuse=0xd9
ATmega8L hab ich grad nicht da..
Egal.. 168 läuft erwartungsgemäß (fuses gleich wie 88).
Peter
Ich habe auch mal eine kleine Frage.
Ich habe dn ATMega168 drauf. Der läuft mit 3.3V bei 20MHz. Ich habe das
Problem das sobald ich irgend eine Test-Software draufspiele die
beispielsweise nur einen Prompt ausgibt (habe das uParse-Projekt in der
Codesammlung mal darauf gespielt), sich der Controller ständig resettet.
Gibt es beim Mega168 gegenüber dem Mega16/32/644 einen Unterschied beim
UART der zum Reset führen kann ? Register und Interruptvektoren hab ich
schon angepasst. Reset-Leitung ist auf High, und die WDTON ist nicht
gesetzt (AVR-Studio, also "richtig" herum). Ich kann mir da irgendwie
keinen Reim drauf machen warum der Controller sich permanent resettet.
Selbst wenn ich alle Interrupts disabled lasse, und nur einen Prompt
ausgebe mit anschließender while (1); resettet der sich andauernd.
Was kann/könnte das sein ?! Liegt es vllt daran das ich dem Mega168 mit
20MHz bei 3.3V zuviel zumute ?!
Fuses kann ich leider Momentan nicht posten da ich die Platine gerad
nicht Griffbereit habe. Aber es ist keine Bootsection aktiv, CLKDIV8 ist
nicht gesetzt, WDTON wie schon erwähnt auch nicht, Brownout detection
ebenfalls nicht.
Hi.
Ich haben einen 168 hier mit avrcpm am laufen. 3,3V und 20MHz.
lfuse=0xf7
hfuse=0xdf
efuse unverändert zum Auslieferzustand
Hoffe das hilft..
Peter
Rene Böllhoff schrieb:> Liegt es vllt daran das ich dem Mega168 mit> 20MHz bei 3.3V zuviel zumute ?!
Hier laufen alle Mega168 mit 3.3V und 24 MHz. Aber versuche doch mal auf
5V zu jumpern bzw. die 8 MHz intern zu nutzen. Bei 5V natürlich SD-Card
ziehen!
Rene Böllhoff schrieb:> sobald ich irgend eine Test-Software draufspiele die> beispielsweise nur einen Prompt ausgibt (habe das uParse-Projekt in der> Codesammlung mal darauf gespielt), sich der Controller ständig resettet.
Was mir spontan noch dazu einfällt.
Auf der Platine ist /DTR (FT232RL) über 100n mit dem Reset des AVR
verbunden.
@Peter
Erstmal danke für die Fuse-Werte. Werd es mal prüfen
@Joe
>die 8 MHz intern zu nutzen
Dann kann ich aber keine saubere Baudrate erzeugen, und das wär schon
wichtig.
>Bei 5V natürlich SD-Card ziehen!
Soweit bin ich noch nicht :-)
>Auf der Platine ist /DTR (FT232RL) über 100n mit dem Reset verbunden
Welche Version des Layouts ist es denn ? Ich hab irgendwie nur die
Version vom 06.06.10 gefunden und danach bestückt. Bin mir aber nicht
sicher ob das die aktuelle Version ist.
Bei mir im Schaltplan ist DTR mit nichts verbunden. Aber ich mess es mal
nach wenn ich die Platine wieder zur Hand habe.
Ich wüsste nicht was ich da großartig hätte falsch machen können. Bei
allen AVRs bisher nie ein Problem gewesen. Aber vllt sind die 20MHz ja
auch wirklich was viel, wobei ich mir das nur schwer vorstellen kann
wenn viele der Platinen mit 24MHz laufen. Merkwürdig, merkwürdig.
Rene Böllhoff schrieb:> Welche Version des Layouts ist es denn ? Ich hab irgendwie nur die> Version vom 06.06.10 gefunden und danach bestückt. Bin mir aber nicht> sicher ob das die aktuelle Version ist.
Die aktuelle Version ist vom 12.06.10 siehe auch hier:
http://www.mikrocontroller.net/articles/AVR_CP/M
Nur so als weiterer Hinweis.. hatte bei ebay 2xATmega88PA gekauft.. aus
Hongkong.. sind auch da.. aber vermutlich umgelabelte 8er.. ID is nicht
mit
88er identisch (avrdude meckert).. die laufen auch nicht mit 20MHz..
Peter
Hmm.. versuche micg gerade mal in z80 asm und möchte den timer.asm um
eine delay-benchroutine erweitern.. Programm läuft auch, aber egal, ob
in hl eine 0, 20 oder 50 geladen wird.. das Ergebnis ist immer 2,138/9
Sekunden??
Ist bestimmt wieder so absolut blöder Fehler ;-)
Hallo Peter,
> wäre es nicht super, diese 'Benchmark' Routine in dein timer (t.com)> Programm mit aufzunehmen..? -> t b würde dann den Timer starten,> die Schleife ausführen und direkt danach die verstrichene Zeit> ausgeben..> So hätten wir ein ungefähres Mass für Optimierungen..
direkt in das Timersteuerprogramm würde ich es nicht einbauen Aber auch
sonst wollte ich es nicht allzu komfortabel machen, damit niemand auf
die Idee kommt, das wäre ein richtiger Benchmark. Ich habe die Schleife
aber jetzt mal mit einem return zum CCP abgespeichert und hier
angehängt.
Peter Sieg schrieb:> dec hl> jp nz,l1 ; 256 x
Jörg hat ja schon geschrieben, daß hier Z_Flag nicht gesetzt wird.
Davon abgesehen wird die Schleife natürlich 65536 mal wiederholt.
Da die innere Schleife ja auch schon gute 3 Sekunden braucht, kommst Du
insgesammt auf gute 196 Kilosekunden, also über 54 Stunden. Ich glaube
nicht, daß Du so lange warten willst.
@ Leo C.
Das stimmt nicht ganz, denn die äussere Schleife wird NIE wiederholt.
Das liegt einfach daran, dass das Zero-Flag von der nächstinneren
Schleife noch gesetzt ist und der DEC HL Befehl keine Flags ändert.
Jörg
Joerg Wolfram schrieb:> Das stimmt nicht ganz, denn die äussere Schleife wird NIE wiederholt.
Das stimmt natürlich.
Ich hätte wohl schreiben sollen, daß die Schleife 65536 mal wiederholt
werden würde, wenn "dec hl" das Z-Flag beeinflussen würde.
Peter Sieg schrieb:> Ja, es mußte ja sowas 'dummes' sein ;-)> Danke!>> Habe jetzt register c statt hl genommen.. und 10x reicht auch ;-)> l1: ld b,0> l2: ld a,0> l3: dec a> jp nz,l3 ; 256 x> dec b> jp nz,l2 ; 256 x> dec c> jp nz,l1 ; 10 x
Statt möglichst schnell zu zählen (und das möglichst oft, damit's nicht
so schnell vorbei ist :), wäre es vielleicht besser, in die Schleife
einige "interessante" Befehle zu legen. Z.B. "PUSH", "POP", "CALL",
"RET", "LD (nnnn),HL", "EX (SP),HL". Also z.B. Befehle, die das
RAM-Interface etwas mehr fordern. Oder einen Mix aus Befehlen, der
möglichst praxisnah ist...
Peter, da Du doch was für MBASIC übrig hast: Mein Basic-Beispiel weiter
oben, könnte man auch noch ausbauen.
> Damit bekommt man mit:> AVR MHz D Zeit> 88 20 0 035,999s> 88 20 1 021,385s
Bei mir z.Zt:
8 20 ? 012.180s bb
8 20 - 010.811s exp
mit folgenden Pinbelegungen:
ok. Na klar kömmte/sollte man ggf. verschiedenen Befehle etc. in der
Schleife unterbringen.. aber was ist ein realer Mix? Und es ist ja kein
wirklicher Benchmark, sondern nur ein Anhaltspunkt um andere
Portbelegungen/Dramroutinen etc. zu 'messen'..
Und die MBASIC Version fand ich deshlab nicht ideal, weil man MBASIC
benötigt..
Hier noch mal die D0 (Original Sprita-tm Portbelegung + Routinen)
und die D1 Version (Port C - Pin 1 + 4 umbelegt + neue Routinen)
(in z80.asm zu wählen durch: DRAM_DQ_ORDER == 0/1)
>-----------------------------------------------------------------------
---
> | Port D | Port B | Port C |> +-----------------------+-----------------------+----------------------+> | 7 | 6 | 5 | 4 | 3 | 2 | 5 | 4 | 3 | 2 | 1 | 0 | 5 | 4 | 3 | 2 | 1 | 0|>D0| CS |SCK DO DI | |> |A7 A6 A5 A8 OE |RAS A0 A1 A2 A3 A4 |CAS D1 D3 D2 W D0|> +-----------------------+-----------------------+----------------------+> | 7 | 6 | 5 | 4 | 3 | 2 | 5 | 4 | 3 | 2 | 1 | 0 | 5 | 4 | 3 | 2 | 1 | 0|>D1| CS |SCK DO DI | |>bb|A7 A6 A5 A8 OE |RAS A0 A1 A2 A3 A4 |CAS W D3 D2 D1 D0|>----------------------------------------------------------------------- ---
D.h, du hast allein durch eine andere Portbelegung und geänderte
Routinen,
eine Verbesserung von 021,385s (D1) zu 10,811s (exp( geschafft?!
> Damit bekommt man mit:> AVR MHz D Zeit> 88 20 0 035,999s> 88 20 1 021,385s>Bei mir z.Zt:> 8 20 ? 012.180s bb> 8 20 - 010.811s exp
mit folgenden Pinbelegungen:
Hmm.. sehe gerade, das D1 und dein bb identisch sind, von den
Portbelegungen... hast du dann noch andere Routinen verwenden??
Denn du hast ja damit 12,180s erreicht (wohin ich nur 021,385s
erreiche)??
Und das das am ATmega8 liegen soll kann ich nicht wirklich glauben..
Hast du übrigens einen 8L verwendet?
>----------------------------------------------------------------------- ---> | Port D | Port B | Port C |> +-----------------------+-----------------------+----------------------+> | 7 | 6 | 5 | 4 | 3 | 2 | 5 | 4 | 3 | 2 | 1 | 0 | 5 | 4 | 3 | 2 | 1 | 0|>D2| CS |SCK DO DI | D3 D2 D1 D0|>ex|A7 A6 |A9 A8 WE OE CAS RAS|A5 A4 A3 A2 A1 A0|>----------------------------------------------------------------------- ---
Der Gewinn D1 -> D2 ist allerdings nicht 'soo' groß..
Peter
Peter Sieg schrieb:>> Damit bekommt man mit:>> AVR MHz D Zeit>> 88 20 0 035,999s>> 88 20 1 021,385s>>Bei mir z.Zt:>> 8 20 ? 012.180s bb>> 8 20 - 010.811s exp
Bei mir:
AVR MHz D Zeit
168 24 1 017,62s
muß mal den Code von Leo C. für die variante D1 (bb) testen.
Peter Sieg schrieb:> ok. Na klar kömmte/sollte man ggf. verschiedenen Befehle etc. in der> Schleife unterbringen.. aber was ist ein realer Mix?
Darum habe ich mich bisher ja auch gedrückt. ;)
> Und es ist ja kein> wirklicher Benchmark, sondern nur ein Anhaltspunkt um andere> Portbelegungen/Dramroutinen etc. zu 'messen'..
Ja, aber Deine Schleife testet nicht mal das halbe DRAM-Interface.
Geschweige, einen nennenswerten Teil des Interpreters.
> Und die MBASIC Version fand ich deshlab nicht ideal, weil man MBASIC> benötigt..
Aber das ist ja vorhanden. Und es ist eine reale Anwendung.
> mit folgenden Pinbelegungen:> Hmm.. sehe gerade, das D1 und dein bb identisch sind, von den> Portbelegungen... hast du dann noch andere Routinen verwenden??> Denn du hast ja damit 12,180s erreicht (wohin ich nur 021,385s> erreiche)??Beitrag "Re: CP/M auf ATmega88"> Hast du übrigens einen 8L verwendet?
Eben nicht. Ich hatte ja auch schon mehrfach geschrieben, daß mein Mega8
mit zu niedriger Spannung und zu hoher Frequenz läuft.
> Der Gewinn D1 -> D2 ist allerdings nicht 'soo' groß..Beitrag "Re: CP/M auf ATmega88"
Ich hatte mir allerdings auch etwas mehr erhofft.
Zur Zeit bin ich gerade wieder an etwas dran, von dem ich mir nochmal
einen Schub erhoffe. Details gibts aber erst, wenns wirklich
funktioniert.
Übrigens habe ich inzwischen den Sektor (De-)Blocking-Algorithmus, der
unnötiges, mehrfaches Lesen und Schreiben der SD-Karte vermeidet, drin.
Performance-mässig bringts leider auch noch nicht so viel, außer
vielleicht bei Anwendungen, die viel und wahlfrei auf Disk schreiben.
Aber Schreiben habe ich noch nicht wirklich getestet...
>> Und die MBASIC Version fand ich deshlab nicht ideal, weil man MBASIC>> benötigt..> Aber das ist ja vorhanden. Und es ist eine reale Anwendung.
Da das MBASIC im Archiv von Sprite_tm kaputt ist, habe ich hier mal eine
funktionierende Version drangehängt. Außerdem habe ich gleich noch ELIZA
dazugetan.
@Leo C.
Ich habe gerade die Versionen 28 und 29 getestet. Beide mit dem gleichen
(Fehler)ergebnis.
Version 19 bringt noch als ersten Opcode von Adresse 2000:
opcode 31 decoded 0192 also korrekt.
Version 28 und 29 bringen:
opcode 31 decoded FFFF und dann startet das System neu.
Hast du was am Befehlsinterpreter geändert? Muß wieder ein neuer
Schalter gesetzt werden?
Könntest du das cpm.bin nicht gleich wieder erstellen? Unter Windows
habe ich keinen Z80 Asssembler gefunden der die Quellen übersetzt.
Joe G. schrieb:> muß mal den Code von Leo C. für die variante D1 (bb) testen.
Ja, denn irgendwoher muß der Unterschied:
>> 88 20 1 021,385s>>Bei mir z.Zt:>> 8 20 ? 012.180s bb
ja herkommen.. denn die Portbelegung ist zw. D1 und bb identisch..
>Bei mir:>AVR MHz D Zeit>168 24 1 017,62s
ja, +20% höherer Takt sollte die Reduzierung von ca. 21 auf 17s
erklären.
Ich habe für timer.asm den tniasm.exe verwendet..(google). Der gibt
aber bei ipl.asm+bios.asm noch eine Fehlermeldung bei Zeile 71/211?
aus..
hatte noch keine Zeit da weiter rein zu schauen.. ist evtl. nur ne
Kleinigkeit.. einen anderen Assembler für win32 habe ich auch noch nicht
gefunden..
---
@Leo: Wenn die Optimierungen am Interpreter angekommen sind (nicht die
schon vorgenommenen Fehlerbereinigungen), kann man ja gerne andere /
weitere Befehle in die Benchschleife mit aufnehmen..
Z.Z habe ich eine D0 und eine D1 Variante hier am laufen.. Und die
LR-Version
kann ich ggf. ja einfach komplett umbauen.. wenn es sich lohnt..
Ich suche noch 32MHz und 40MHz Quarze (wo gibt es die..?), dann kann ich
mal
schauen ob die Realität der Hochrechnung entspricht (womit wir dann bei
>1MHz bis an die ~2MHz Z80 sind..)
BTW: Mbasic hatte ich schon lange mal ein andere Version gezogen..
Muß jetzt mal die alten Basic Juwelen durchtesten.. Nim/23 und Bagels
laufen einwandfrei.. stellen ich dann alle hier rein..
Peter
Joe G. schrieb:> @Leo C.> Ich habe gerade die Versionen 28 und 29 getestet. Beide mit dem gleichen> (Fehler)ergebnis.> Version 19 bringt noch als ersten Opcode von Adresse 2000:> opcode 31 decoded 0192 also korrekt.> Version 28 und 29 bringen:> opcode 31 decoded FFFF und dann startet das System neu.
Alle eingecheckten Revisionen sind bei mir mindestens einmal gelaufen.
Einziger Unterschied zu Deiner Hardware dürfte der Prozessor sein.
Mega88, Mega168 kann ich nicht testen.
Alles in trunk sollte auf Deiner Hardware funktionieren.
(Ab Rev. 32 braucht man allerdings das zugehörige Bios.)
> Hast du was am Befehlsinterpreter geändert?
Einige kleine, lokale Optimierungen. Das Konzept ist immer noch das
gleiche.
Hast Du einen Mega88 zum Testen?
> Muß wieder ein neuer Schalter gesetzt werden?
Nein.
> Könntest du das cpm.bin nicht gleich wieder erstellen?
Im SVN möchte ich eigentlich keine Binaries haben.
> Unter Windows> habe ich keinen Z80 Asssembler gefunden der die Quellen übersetzt.
Die Assemblerquellen gibt es hier:
http://savannah.nongnu.org/projects/z80asm/
Vielleicht ist ja jemand so freundlich, und übersetzt das Ding für
Windows.
Peter Sieg schrieb:> Ich habe für timer.asm den tniasm.exe verwendet..(google). Der gibt> aber bei ipl.asm+bios.asm noch eine Fehlermeldung bei Zeile 71/211?> aus..
Danke für den Tip! Wenn Du jeweils den "end" Befehl streichst übersetzt
der Compiler.
Leo C. schrieb:> Einige kleine, lokale Optimierungen. Das Konzept ist immer noch das> gleiche.> Hast Du einen Mega88 zum Testen?
Ich suche mal nach einem Mega88 zum testen. Übrigens ist mir
aufgefallen, wenn der Schalter zum RAM-Test gesetzt ist läuft das System
nicht stabil. Zork, MBASIC oder der SYS Befehl bringen oft (nicht immer)
Op-Codefehler. Ohne RAM Test läuft alles Fehlerfrei. Sieht nach einem
Timing Problem aus.
Peter Sieg schrieb:> Habe mich gerade daran erinnert, das auf alten Netzwerkkarten ja 25MHz> Quarze sind ;-)
Dann sind meine Netzwerkkarten noch nicht alt genug? Die beiden 20MHz
Quarze habe ich von dort.
Alte Grafikkarten sind eine gute Quelle für Oszillatoren. Auf meiner
guten alten ET4000 sind 25.17, 28.322, 36, 44.9 und 62MHz. Ich weiß nur
nicht, ob die Teile auch bei 3.3V laufen.
8 Stück 256x4MBit DRAMs sind übrigens auch drauf. Davon 4 sogar
gesockelt.
Feinmechaniker schrieb:> Übrigens ist mir> aufgefallen, wenn der Schalter zum RAM-Test gesetzt ist läuft das System> nicht stabil. Zork, MBASIC oder der SYS Befehl bringen oft (nicht immer)> Op-Codefehler. Ohne RAM Test läuft alles Fehlerfrei. Sieht nach einem> Timing Problem aus.
Das ist aber seltsam. Von dem RAM-Test sollte eigentlich keine
Erinnerung
übrig bleiben. Falls etwas nicht richtig initialisiert wird, sollte es
eher umgekehrt sein. Ich habe den RAM-Test immer eingeschaltet.
Hast Du den MEMFILL_CB-Schalter an? Ich finde den sehr nützlich, da ein
ins Nirvana laufendes Programm sofort gestopt wird.
bezüglich der Quarze.
CSD hat 36+40MHz aber 3.Oberton..? Geht das, oder eher nicht?
Ansonsten gibts wohl nur Quarzoszillatoren.. und ob die ab 3,3V
arbeiten..? Für SMD gibts aber welche ab 3,3V..
Peter
Jetzt habe ich doch noch meinem GPS-Logger den ATmega328P geklaut.
Läuft mit meinen neuesten Programmversionen auf Steckbrett und
Lochraster mit 2 verschiedenen Verdrahtungen.
Inzwischen habe ich eine weitere Verdrahtung ausprobiert und dafür auch
andere RAMs genommen (GM71C4256A-80, statt der schnelleren 3.3V Typen).
Mit ATmega8 gings problemlos, aber mit dem ATmega328P bekam ich die
gleichen Probleme, wie Joe G. sie beschrieben hatte.
@Joe G.:
Geholfen hat ein weiterer Wartezyklus beim Lesen, in der SVN/trunk
Version also so:
Nach den Datenblättern sollten 2 Takte (immerhin noch 83ns bei 24MHz)
dicke reichen, aber bei 3.3V statt 5V dürfen wir ja froh sein, daß die
RAMS überhaupt laufen.
Leo C. schrieb:> Geholfen hat ein weiterer Wartezyklus beim Lesen, in der SVN/trunk
Leider behebt es bei mir nicht den Fehler im Befehlsinterpreter, siehe
Joe G. schrieb:> Version 19 bringt noch als ersten Opcode von Adresse 2000:> opcode 31 decoded 0192 also korrekt.> Version 28 und 29 bringen:> opcode 31 decoded FFFF und dann startet das System neu.
In Version 28 hast du auch die beiden neunen Funktionen dram_read_w,
dram_write_w auch nicht eingebaut. In V29 habe ich die NOP's mal
eingefügt, ohne Erfolg.
@Leo C.
Ich habe den Fehler nochmal eingegrenzt. Es scheint wirklich ein Timing
Problem mit dem RAM zu sein. V28 und V29 laufen bei 8MHz auf dem mega168
und mega8. Bei 20MHz bzw. 24 MHz tritt das Problem auf.
Erstaunlicherweise läuft mein mega8 hier mit 3.3V und 24 MHz.
Joe G. schrieb:>> Version 19 bringt noch als ersten Opcode von Adresse 2000:>> opcode 31 decoded 0192 also korrekt.>> Version 28 und 29 bringen:>> opcode 31 decoded FFFF und dann startet das System neu.
Da ich die passende Hardware noch auf meinem Steckbrett habe, habe ich
die Version 19 grade ausprobiert. Läuft bei mir mit ATmega328P. Für
diesen Fehler habe ich auch keine Erklärung. Der Wert 0192 ist ja nur
ein Tabelleneintrag (Index 31) in inst_table. Es sieht so aus als ob der
Interpreter bei Dir ins Leere (unprogramierte Flash) greift. Ab der
Revision 28 muß die Tabelle auf einer durch 256 teilbaren Adresse
liegen. Das müßte aber durch das .org (PC+255) & 0xff00 davor
gewährleistet sein. Du könntest mal im Listing nachschauen, wo die
Tabelle bei Dir zu liegen kommt.
Mindestens ein Fehler ist aber drin. Beim Start sollte das Register "_0"
genullt werden. Z.B.:
1
start:
2
ldi temp,low(RAMEND) ; top of memory
3
out SPL,temp ; init stack pointer
4
ldi temp,high(RAMEND) ; top of memory
5
out SPH,temp ; init stack pointer
6
7
clr _0
>> In Version 28 hast du auch die beiden neunen Funktionen dram_read_w,> dram_write_w auch nicht eingebaut.
Die Funktionen waren immer als "experimental" gekennzeichnet und
abgeschaltet. Der Aufwand lohnt einfach nicht. Problem ist, daß ein
16-bit Wort auf der Grenze zwischen 2 Reihenadressen liegen kann.
>In V29 habe ich die NOP's mal> eingefügt, ohne Erfolg.
Ein weiterer Timing-Engpaß könnte noch in der Refresh-Routine liegen.
Dort sind 2 auskommentierte nops drin. Wenn ich mich richtig erinnere,
ist der 2. an der kritischeren Stelle.
Joe G. schrieb:> @Leo C.> Ich habe den Fehler nochmal eingegrenzt. Es scheint wirklich ein Timing> Problem mit dem RAM zu sein. V28 und V29 laufen bei 8MHz auf dem mega168> und mega8. Bei 20MHz bzw. 24 MHz tritt das Problem auf.> Erstaunlicherweise läuft mein mega8 hier mit 3.3V und 24 MHz.
Das es mit dem Meaga8 besser geht, ist mir am Wochenende ja auch
aufgefallen. Dir Porttreiber sind offensichtlich unterschiedlich (Ich
habe gerade in die Datenblätter geschaut, und mein Verdacht hat sich
bestätigt).
Man müßte mal ein Scope dranhängen, um zu sehen, was da vor sich geht.
Dein FFFF vs. 0192 Fehler ist damit aber nur schwer zu erklären. Der
Opcode wird ja in beiden Fällen aus dem RAM richtig gelesen.
Du kannst das RAM-Timing natürlich weiter dehnen. Zuerst 1 oder 2
weitere nops vor den in-Befehlen. Dann vor/nach den anderen
Signalflanken nops einbauen. Zum Schluß landet man vielleicht wieder bei
den vielen nops, die Sprite_tm schon drin hatte. ;-)
Oder beim Mega8 bleiben. Bisher kenne ich noch keinen Grund, der dagegen
sprechen würde.
Joe G. schrieb:>> clr _0> Das war der Fehler! V29 läuft, vielen Dank für den Hinweis.> Timer B zeigt nun 9.441 s mit einem mega8 und 24 Mhz
Bei mir hats komischerweise keinen Unterschied gemacht.
Ab Revision 51 ist der Fehler behoben. Allerdings sehe ich keinen Grund,
gleich die HEAD Revision (53) zu nehmen.
@Leo C. + Joe G. Super!
@Joe G. planst du einen Update der über #define D* = 1 erreichberen
Routinen,
um den Geschwindigkeitsvorteil nutzen zu können, der weiter oben
aufgefallen war (sobald du weißt in welchen Routinen, was geändert
wurde..)?
Hatte heute meinen ersten Arbeitstag nach dem Urlaub :-( :-(
Peter
@Leo C.
Revision 51 läuft.
@alle
um sich unter Windows ein Bios zu erzeugen sollte man ein DD "für
Windows" benutzen welches den Befehl conv=sync kennt. Hier in Link zu
UNIX-Tools unter Windows, da ist auch das entsprechende DD dabei.
http://sourceforge.net/projects/unxutils/files/unxutils/current/UnxUtils.zip/downloadPeter Sieg schrieb:> @Joe G. planst du einen Update der über #define D* = 1 erreichberen> Routinen
Ich habe sie genau so verwendet wie Leo C. sie bereitgestellt hat, bis
auf das zusätzliche Einfügen von "clr _0" in der V29. Aber ab V51 ist
der Befehl schon mit drin. Ab V51 mußt du jedoch das neue Bios nutzen.
@Joe G.: In wieweit wirst du die V51 in deine Version übernehmen..?
Und das neue Bios von Leo C. hatte ich schon (hatte er weiter oben als
cpm.bin zur Verfügung gestellt..).. oder gibts da schon ein neueres..?
Gruß Peter
Peter Sieg schrieb:> Und das neue Bios von Leo C. hatte ich schon (hatte er weiter oben als> cpm.bin zur Verfügung gestellt..).. oder gibts da schon ein neueres..?
ja, gibt es, siehe hier:
* cpm/bios.asm:
- New disk I/O interface.
- 16 bit wide track numbers
- sectran competed. Unused translation table removed.
* cpm/ipl.asm:
- New disk I/O interface.
Peter Sieg schrieb:> @Joe G.: In wieweit wirst du die V51 in deine Version übernehmen..?
Wenn es keine Probleme damit gibt, vollständig. Es wäre aber schön, wenn
sie noch von anderen getestet wird.
Man(n) .. ;-)
Mit der Geschwindigkeit kann ich z.Z nicht mithalten.. :-)
Könntet ihr dann bitte ipl.asm, bios.asm und avrcpm.asm hier einhängen..
dann sichere ich erstmal den aktuellen Stand als V1, assembliere dann
alles
und kann dann auch testen..
BTW: Was sind die Änderungen/Vorteile insbesondere von 16 bit wide track
numbers..?
Peter
Peter Sieg schrieb:> Man(n) .. ;-)> Mit der Geschwindigkeit kann ich z.Z nicht mithalten.. :-)> Könntet ihr dann bitte ipl.asm, bios.asm und avrcpm.asm hier einhängen..
Warum klickst Du denn nicht einfach hier drauf?
http://cloudbase.homelinux.net/viewvc/avr-cpm/trunk/> dann sichere ich erstmal den aktuellen Stand als V1, assembliere dann> alles> und kann dann auch testen..>> BTW: Was sind die Änderungen/Vorteile insbesondere von 16 bit wide track> numbers..?
Warst Du das nicht, der größere Disk-Formate wollte? ;-)
Da ich an dem Thema sowieso grade wieder dran bin...
Peter Sieg schrieb:> BTW: Was sind die Änderungen/Vorteile insbesondere von 16 bit wide track> numbers..?
Mit 8-Bit Nummern kommnt man maximal bis 8MByte.
(128 Byte per Sector) x (256 Sectors per Track) x (256 Tracks)
Bei SD-Karten im GB-Bereich ist das etwas wenig.
Jetzt mal ein paar Fragen zu größeren Diskformaten:
Hat sich daraüber schon jemand Gedanken gemacht?
Hat vielleicht jemand schon ein Konzept?
Oder kennt jemand einen hier brauchbaren Standard / eine fertige Lösung?
Vorschläge?
Meine eigenen Gedanken:
Fernziel vielleicht Disk-Images auf FAT Dateisystem lesen/schreiben.
(Dafür wird man wahrscheinlich einen Mega168 oder größer brauchen, da ja
auch noch die Z80 Opcodes ins Flash müssen).
Zwischenschritt:
Die Partitionstabelle von der SD-Karte lesen.
Erste (oder einzigste) Partition als CP/M partition nutzen.
Im Bootsektor der Partition die CP/M-Diskparameter ablegen.
Die Tabelle passt mit dem IPL in die ersten 128 Byte.
Was meint Ihr?
Leo C. schrieb:> Warum klickst Du denn nicht einfach hier drauf?> http://cloudbase.homelinux.net/viewvc/avr-cpm/trunk/>> Warst Du das nicht, der größere Disk-Formate wollte? ;-)
Na dann schaue ich mal in den 'Kofferraum' (trunk) ;-)
Werde dann mal versuchen für D1 eine V53 komplett zu übersetzen..
Ja, ich wars ;-) Aber den Verhältnissen entsprechend des Konzeptes..
eine
EINFACHE Implementierung!! Nichts zu kompliziertes.. Hey, wir reden hier
über CP/M.. wer sollte selbst bei 8MB großen 'Disketten' ohne
Unterverzeichnisse noch die Übersicht behalten.. Aktuell sind die
diskimages sowas um die 250kb.. da passt sogar schon der BDS-C Compiler
drauf.. also 512kb - 1MB sollte reichen.. besser wären dann mehrere
Disketten(-images) auf einer SD Karte.. (A:, B:, C: ...)
Just my 2 cents.
Peter
Peter Sieg schrieb:> EINFACHE Implementierung!! Nichts zu kompliziertes..
Ja eben.
> Hey, wir reden hier> über CP/M.. wer sollte selbst bei 8MB großen 'Disketten' ohne> Unterverzeichnisse noch die Übersicht behalten.. Aktuell sind die
Der Punkt ist, daß kleine Images auch nicht einfacher zu implementieren
sind, als große. Und warum dann so unendlich viel Platz
verschwenden(?/!)
> diskimages sowas um die 250kb.. da passt sogar schon der BDS-C Compiler> drauf.. also 512kb - 1MB sollte reichen..
Wenn ich das mit der Partitionstabelle so wie oben angedeutet mache,
kannst Du ja eine 512K Partition für CP/M anlegen. Und den Rest
anderweitig nutzen.
> besser wären dann mehrere> Disketten(-images) auf einer SD Karte.. (A:, B:, C: ...)
Dann eben 2 Partitionen, oder 3... Bei 4 wird aber Schluß sein, weil
erweiterte Partitionen will ich mir nicht antun.
Soo.. hat ein bißchen gedauert.. mußte erstnoch obiges dd
herunterladen.. und mit dem 'alten' dd unter admin Rechten dann das
diskimage schreiben (Vista)..
1
CPM on an AVR, v1.0
2
Initing mmc...
3
Testing RAM: fill...wait...reread...
4
5
Ok, CPU is live!
6
ipl
7
8
62k cp/m vers 2.2
9
10
A>dir
11
A: ASM COM : DDT COM : DUMP COM : ED COM
12
A: T COM : TLOOP COM : LOAD COM : MBASIC COM
13
A: 23 BAS : BAGELS BAS : CHECKERS BAS : STARTREK BAS
14
A: TREKINST BAS : MASTRMND BAS : WEEKDAY BAS : PIP COM
15
A: STAT COM : SUBMIT COM : XSUB COM : ZORK1 COM
16
A: ZORK1 DAT
17
A>t b
18
19
Timer running. Elapsed: 007.573s.
20
A>
Na.. 7.573s allerdings bei 30MHz ;-)
Target war ATmega88.
Na, wenn das keine super Arbeit ist Leo C. ;-)
Klasse!!
Und VIELEN Dank!
Gruß Peter
Peter Sieg schrieb:> Na.. 7.573s allerdings bei 30MHz ;-)
Mir wird schwindelig.
Wenn ich mich nicht verrechnet habe, hast Du bereits bei ca. 13,5MHz den
sicheren Bereich verlassen.
Wo sind meine Herztropfen.
Leo C. schrieb:> Wenn ich mich nicht verrechnet habe, hast Du bereits bei ca. 13,5MHz den> sicheren Bereich verlassen.
Haha.. Dann sind wir schon drei (der dritte ist jemand aus dem F64, der
einen ATmega88 als SID Ersatz mit 40MHz laufen läßt) ;-)
@Joe G: Mein Vorschlag wäre es, die aktuelle Version um MK SVN als V1 zu
belassen (inkl. ipl+bios.asm) und die R53 von Loe C. als aktuelle
Version ins MK SVN zu spiegeln.. sodaß wir im MK SVN immer etwas größere
Abstände zw. Versionen bekommen..
Peter
Leo C. schrieb:> Wenn ich mich nicht verrechnet habe, hast Du bereits bei ca. 13,5MHz den> sicheren Bereich verlassen.
Das ist ein Fehler im Datenblatt, die lineare Funktion knickt nicht bei
4.5V ab, Peter hat nur veregssen 12V an den AVR anzulegen. Nicht
auszudenken mit welcher Frequenz er bei 220V läuft! Ich vermute mal mit
50Hz ;-)
Peter Sieg schrieb:> Mein Vorschlag wäre es, die aktuelle Version um MK SVN als V1 zu> belassen (inkl. ipl+bios.asm)
Ich würde die Version V29 von Leo C. incl. ipl+bios als V1 eindampfen.
Mit der derzeitigen Hardware dürfte es damit für weitere
Nachbauinteressenten keine Probleme geben. R52 nehme ich als aktuelle
Testversion auf.
Peter Sieg schrieb:> und mit dem 'alten' dd unter admin Rechten dann das> diskimage schreiben
Eignet sich das "neue" DD nicht zum Diskimage schreiben? Ich habe dazu
bisher auch nur das "alte" verwendet.
@Joe G. Prima. Ich habe hier jetzt wie schon geschrieben, die R53 von
Leo C im Einsatz.. die unterstützt aber wohl nicht mehr das urspüngliche
HW Layout (sind ja nur die 2 Pins geändert..). Ich habe mir erlaubt
diese Version auch mal wieder dem Entwickler Sprite_tm zukommen zu
lassen.. Er freut sich sicher über solche Updates von Zeit zu Zeit..
Bei 220V erwarte ich auch 50Hz.. nachdem sich der Rauch verzogen hat..
;-)
Aber ich plane auch noch einen Test mit 40MHz.. da aber wohl mit einem
Quarzoszi, da es wohl keine Grundton Quarze für diese Frequenz mehr
gibt..
Da werde ich dann meinen LR Aufbau umbauen müssen.. ;-)
Joe G. schrieb:> Eignet sich das "neue" DD nicht zum Diskimage schreiben? Ich habe dazu> bisher auch nur das "alte" verwendet.
Anscheinend nicht.. ich habe es damit nicht hinbekommen.. evtl. findet
mal jemand eines, das beides kann..
Peter
@alle
Der aktuelle Bearbeitungsstand liegt nun wieder auf dem SVN-Repositor.
Unter V 1.0 findet ihr den letzten Stand der noch mit der alten Hardware
läuft. Bei den folgenden Versionen (Verzeichnis /Work) müssen die zwei
Pins, wie weiter oben schon beschrieben, getauscht werden.
Zwölfliter schrieb:> Laufen denn auch schon große Programme wie Wordstar?
Derzeit laufen alle für den 8080 codierten Programme, egal ob groß oder
klein. Keine Ahnung ob es Wordstar für den 8080 gab, ich kenne es nur
für Z80.
@Leo C. Bezüglich mehrere Disketten (A: , B:, ...) wäre mein erster
Ansatz gewesen, alle diskimages mit fester Größe ('disksize') direkt mit
z.b dd hintereinander zu hängen und dies dann so auch per dd auf die SD
Karte zu bringen.. Im AVR wäre dann ein 'Offset' zu halten, der beim
Start=0 ist und
beim Wechseln von A: nach z.B B: dann entsprechend auf 1 wechselt..
(C=2,..)
Beim Zugriff auf die SD Karte ist dieser Offset dann entsprechend zu
berücksichtigen (Offset * disksize = Block 0 der aktuellen 'Diskette')..
Peter
Peter Sieg schrieb:> @Leo C. Bezüglich mehrere Disketten (A: , B:, ...) wäre mein erster> Ansatz gewesen, alle diskimages mit fester Größe ('disksize') direkt mit> z.b dd hintereinander zu hängen und dies dann so auch per dd auf die SD> Karte zu bringen..
zu spät ;-)
Ich habe den code, um CPM-Laufwerke (A: .. D:) von Partitionen zu lesen,
fast fertig. Z.Zt. kämpfe ich allerdings mit der SD-Karte/dem
MMC-Treiber,
weil die Karte, die ich zum Testen nehmen wollte, Schwierigkeiten macht.
Werde jetzt erst mal meine alte Karte umpartitionieren.
Vorteil der Partitionen ist vor allem, daß man den nicht für
CPM-genutzten Platz für andere Zwecke verwenden kann. Ich habe z.B. auf
jeder Karte ein MP3-Verzeichnis fürs Auto.
Unter Linux ist es kein Problem, Partitionen mit beliebigen IDs
anzulegen. Für CP/M ist 0x52 reserviert, und die möchte ich dann auch
nehmen.
Ich weiß nicht, ob es für Windows auch gängige Partitionierungstools
gibt, die das können. Aber notfalls gehts ja mit dd. Ist dann auch nicht
umständlicher als ohne Partitionen.
Joe G. schrieb:> Keine Ahnung ob es Wordstar für den 8080 gab, ich kenne es nur> für Z80.
Seltsam, Wordstar ist ja imho das CP/M-Programm schlechthin. Ich bin
eigentlich davon überzeugt. daß alle CP/M-80 Versionen von Wordstar auch
auf 8080 laufen. Es sei denn, jemand hat in der Printer patch area
Z80-Code verwendet (Oder so ähnlich).
Ich bin noch nicht dazu gekommen, einen Wordstar an meine
Terminalemulation anzupassen. Der Worstar-Installer, den ich auprobiert
habe, hatte kein VT10x und kein ANSI im Angebot. Gelaufen ist er aber.
Die erste CP/M-Partition (A:) liegt also ganz hinten auf der SD-Karte.
Und das kommt raus:
1
A>CPM on an AVR, v1.0
2
Testing RAM: fill...wait...reread...
3
Initing mmc...
4
CP/M partition at: 1890304, size: 8192KB.
5
CP/M partition at: 2048, size: 3072KB.
6
7
Ok, CPU is live!
8
ipl
9
10
62k cp/m vers 2.2
11
12
A>stat a:dsk:
13
14
A: Drive Characteristics
15
1944: 128 Byte Record Capacity
16
243: Kilobyte Drive Capacity
17
64: 32 Byte Directory Entries
18
64: Checked Directory Entries
19
128: Records/ Extent
20
8: Records/ Block
21
26: Sectors/ Track
22
2: Reserved Tracks
23
24
A>stat b:dsk:
25
26
B: Drive Characteristics
27
1944: 128 Byte Record Capacity
28
243: Kilobyte Drive Capacity
29
64: 32 Byte Directory Entries
30
64: Checked Directory Entries
31
128: Records/ Extent
32
8: Records/ Block
33
26: Sectors/ Track
34
2: Reserved Tracks
35
36
A>
Das Disk-Format is noch das alte mit nur 243 Kilobyte. Die zugehörigen
Tabellen sind jetzt noch fest im BIOS und werden demnächst dynamisiert.
Wie immer auf:
http://cloudbase.homelinux.net/viewvc/avr-cpm/trunk/avrcpm/
Neues BIOS ist auch notwendig, damits klappt.
@Leo C.: Frage: diskimages werden nach wie vor mit z.B dd aufgespielt?
Also z.B dd if=diskimage of=/dev/sdb2 bs=512 ...(unter Linux)..?
Super! Man(n).. selbst ein Vollzeit-Entwickler könnte da nicht schneller
dran arbeiten.. ;-) Da komme ich ja mit dem wechseln der Versionen nicht
nach..
Peter
Peter Sieg schrieb:> @Leo C.: Frage: diskimages werden nach wie vor mit z.B dd aufgespielt?> Also z.B dd if=diskimage of=/dev/sdb2 bs=512 ...(unter Linux)..?
Genau.
Übrigens,
für linux gibt es sfdisk, mit dem man Partitionstabellenänderungen
scripten kann, zB. im Makefile. Mit "sfdisk -c /dev/sdb 2 52" kann man
z.B. die Partitions-ID von Partition 2 auf 52 einstellen.
A: 23 BAS : BAGELS BAS : CHECKERS BAS : STARTREK BAS
19
A: TREKINST BAS : MASTRMND BAS : WEEKDAY BAS : PIP COM
20
A: STAT COM : SUBMIT COM : XSUB COM : ZORK1 COM
21
A: ZORK1 DAT
22
A>b:
23
24
25
B>dir
26
27
28
B: TTT2 COM : OTHELLO COM : MMIND COM : ED COM
29
B: LOAD COM : STONE COM : PIP COM : STAT COM
30
B: SUBMIT COM : XSUB COM
31
B>
...allerdings Partitionierung, Typ=52 setzen nur mit Linux Live-CD und
cfdisk o.ä. Tools.. Auch bespielen per dd ging nur unter Linux, da das
Windows dd die Typ=52 Partitionen nicht kennt/anzeigt..
=> Wer kennt ein s/cfdisk unter Windows..?
Ansonsten wiedermal Super!
Gruß Peter
Peter Sieg schrieb:> ...allerdings Partitionierung, Typ=52 setzen nur mit Linux Live-CD und> cfdisk o.ä. Tools.. Auch bespielen per dd ging nur unter Linux, da das> Windows dd die Typ=52 Partitionen nicht kennt/anzeigt..
Etwas bequemer als PC mit Life-CD booten ist dann vielleicht dd und
Binär/Hex-Editor.
dd if=/dev/sdb of=mbr-b.bin bs=512 count=1
mbr-b.bin editieren.
Der Aufbau der Partitionstabelle ist im Wikipedia-Artikel gut
dargestellt:
http://de.wikipedia.org/wiki/Partitionstabelle
Der Partitionstyp steht also für die erste Partition auf 1C2. Für die
nächsten 3 Partitionen entsprechend auf 1D2, 1E2, 1F2.
Dieses Byte auf 52 ändern und die Datei zurückschreiben:
dd of=/dev/sdb if=mbr-b.bin bs=512 count=1
Fertig.
> => Wer kennt ein s/cfdisk unter Windows..?
Ich hab auch mal kurz geschaut, ob es z.B. (g)parted für Windows gibt
und bin gleich fündig geworden. Hurra... Linux-Live-CD!
Leo C. schrieb:> Etwas bequemer als PC mit Life-CD booten ist dann vielleicht dd und> Binär/Hex-Editor.
Hmm.. der Argumentation kann ich nicht folgen..?
Die Partitionierung muß bis ich was anderes weiß unter Linux (Live-CD
etc.) erfolgen.. Und dann den MBR extrahieren, den Typ mit HEX-Editor
ändern nur
damit ich unter Windows mit dd die dann erkannten Partition beschreiben
kann, um danach den Typ wieder ändern zu müssen (auch wenn man eine
MBR-Kopie verwendet..) scheint mir nicht wirklich einfacher zu sein..
:-(
Evtl. wäre es doch hierfür besser den Typ nicht auf 52 sondern FAT16 zu
stellen..? Wenn die dann alle unter dd+Windows erkannt werden, dann
müßte man nur einmalig die Partitionierung unter Linux vornehmen.. aber
erstmal abwarten.. evtl. finden wir doch noch ein natives Windows Tool..
BTW: Es funktioniert nach wie vor auch nur eine primäre Partition FAT
mit dem dd diskimage wie zuvor genutzt.. dann natürlich auch nur ein LW
A:
Peter
Peter Sieg schrieb:> BTW: Es funktioniert nach wie vor auch nur eine primäre Partition FAT> mit dem dd diskimage wie zuvor genutzt.. dann natürlich auch nur ein LW> A:
Diese Variante läuft bei mir mangels Linux auch gerade. Das kann aber
nicht die Lösung sein. Ich untersuche gerade Diskpart.EXE für Windows.
Peter Sieg schrieb:> Leo C. schrieb:>> Etwas bequemer als PC mit Life-CD booten ist dann vielleicht dd und>> Binär/Hex-Editor.>> Hmm.. der Argumentation kann ich nicht folgen..?> Die Partitionierung muß bis ich was anderes weiß unter Linux (Live-CD> etc.) erfolgen.. Und dann den MBR extrahieren, den Typ mit HEX-Editor> ändern nur> damit ich unter Windows mit dd die dann erkannten Partition beschreiben> kann, um danach den Typ wieder ändern zu müssen (auch wenn man eine> MBR-Kopie verwendet..) scheint mir nicht wirklich einfacher zu sein..> :-(
Wer hat denn soooo argumentiert?
Partitionieren kann man doch noch immer unter Windows, oder?
Warum also nicht mit dem Windows Partitionierer die Karte nach Wunsch
aufteilen, und den CP/M-Partitionen vorläufig einen Typ geben, den
Windows kann.
Dann das Windows fdisk oder Festplattenverwaltungswerkzeug, oder wie
auch immer das Teil unter NT, XP,... heißt, verlassen und anschließend
dd und Hex-Editor?
> Evtl. wäre es doch hierfür besser den Typ nicht auf 52 sondern FAT16 zu> stellen..? Wenn die dann alle unter dd+Windows erkannt werden, dann> müßte man nur einmalig die Partitionierung unter Linux vornehmen..
Mein Ironiedetektor scheint gerade nicht zu funktionieren.
Und dd kennt weder Partitionstypen (Partition IDs) noch Dateisysteme.
> BTW: Es funktioniert nach wie vor auch nur eine primäre Partition FAT> mit dem dd diskimage wie zuvor genutzt.. dann natürlich auch nur ein LW> A:
Das hat aber mit einer primären FAT überhaupt nichts zu tun. In diesem
Fall ist nach dem dd auf der Karte kein MBR mehr, keine
Partitionstabelle, und keine Partitionen, schon gar keine mit FAT...
Und was vorher auf der Karte war, spielt überhaupt keine Rolle mehr.
Wenn ich in dem neuen Programm keine Partitionstabelle finde, dann mache
ich der Einfachheit halber das gleiche wie vorher. Das heißt, wenn am
Anfang der SD-Karte "zufällig" ein CP/M-Dateisystem steht, gehts
weiter...
ps: Meinen Rechner habe ich diese Woche noch nicht neu gestartet. Und
nur, um eine Speicherkarte zu formatieren, werde ich das ganz bestimmt
nicht tun.
leo@cb:~$ uptime
17:09:00 up 10 days, 5:17, 15 users, load average: 0.26, 0.18, 0.06
@Leo C.
Meine SD Karte ist unter Linux etwa so partitioniert:
/dev/sdh1 200MB FAT16
/dev/sdh2 8MB CP/M
/dev/sdh3 8MB CP/M
/dev/sdh4 8MB CP/M
(app. 30MB unnused)
Diese Karte unter dem windows dd zeigt NUR die FAT16 Partition an!
Wenn ich da ein dd if=diskimage of=\\...die einzige angezeigte Part...
bs=512 mache, läuft avrcpm damit als A:
Wie gesagt, die Typ=52 = CP/M Partitionen werden erst gar nicht von dem
Tool unter Windows angezeigt.. ignoriert als wenn es sie gar nicht
gäbe..
Daher vermute ich, das wenn man vom Type CP/M hin zu FAT16 auch die
anderen Partitionen eben wieder zugreifbar macht.. und dann auch wieder
unter Windows mit dd beschreiben kann..
diskpart unter Windows gibt mir:
1
Datentr ### Status Größe Frei Dyn GPT
2
-------- ---------- ------- ------- --- ---
3
0 Online 149 GB 0 B
4
1 Online 244 MB 23 MB
5
2 Kein Mediu 0 B 0 B
6
3 Kein Mediu 0 B 0 B
7
4 Kein Mediu 0 B 0 B
8
5 Kein Mediu 0 B 0 B
9
6 Kein Mediu 0 B 0 B
10
7 Kein Mediu 0 B 0 B
11
8 Kein Mediu 0 B 0 B
12
13
DISKPART> select disk 1
14
15
Datenträger 1 ist jetzt der gewählte Datenträger.
16
17
DISKPART> list part
18
19
Partition ### Typ Größe Offset
20
------------- ---------------- ------- -------
21
Partition 1 Primär 196 MB 32 KB
22
Partition 0 Primär 8033 KB 196 MB
23
Partition 0 Primär 8033 KB 204 MB
24
Partition 0 Primär 8033 KB 212 MB
Ich persönlich habe kein wirkliches Problem mit einer Linux Live-CD..
Finde aber es aber schade, das wir nun ohne Linux - allein mit Windows
Mitteln - nicht mehr auskommen.. wobei wir ja noch 'das Tool' evtl. noch
finden.. (diskpart ist ein Krampf..)
Gruß Peter
Leo C. schrieb:> Partitionieren kann man doch noch immer unter Windows, oder?> Warum also nicht mit dem Windows Partitionierer die Karte nach Wunsch> aufteilen, und den CP/M-Partitionen vorläufig einen Typ geben, den> Windows kann.>> Dann das Windows fdisk oder Festplattenverwaltungswerkzeug, oder wie> auch immer das Teil unter NT, XP,... heißt, verlassen und anschließend> dd und Hex-Editor?
Das könnte so gehen.. aber das ist nicht einfacher als gleich eine
Live-CD zu nehmen.. (just my 2 cents)..
Peter
Peter Sieg schrieb:> Diese Karte unter dem windows dd zeigt NUR die FAT16 Partition an!
Das dd, das ich kenne, kann überhaupt keine Partitionen anzeigen.
Das Windows dd scheint etwas völlig anderes zu sein.
> Wenn ich da ein dd if=diskimage of=\\...die einzige angezeigte Part...> bs=512 mache, läuft avrcpm damit als A:
Wie greift man denn mit dd auf Geräte, bzw Partitionen, zu? Die
interessanteste Information hast Du weggelassen.
> Wie gesagt, die Typ=52 = CP/M Partitionen werden erst gar nicht von dem> Tool unter Windows angezeigt.. ignoriert als wenn es sie gar nicht> gäbe..> Daher vermute ich, das wenn man vom Type CP/M hin zu FAT16 auch die> anderen Partitionen eben wieder zugreifbar macht.. und dann auch wieder> unter Windows mit dd beschreiben kann..
Da kämen wir aber garantiert in Teufels Küche. Zum einen wird sich dann
Windows über jede (avr-)CP/M-Partition hermachen, und vielleicht
versuchen, sie zu reparieren. Zum anderen wird unser avr von jder
FAT16-Partition booten wollen, die ihm unter die Kontakte kommt. Ich
bestehe nicht auf die 52, aber IDs, die Windows kennt, kann man halt
nicht nehmen.
1
> Partition ### Typ Größe Offset
2
> ------------- ---------------- ------- -------
3
> Partition 1 Primär 196 MB 32 KB
4
> Partition 0 Primär 8033 KB 196 MB
5
> Partition 0 Primär 8033 KB 204 MB
6
> Partition 0 Primär 8033 KB 212 MB
Also Windows sieht die Partitionen ja. Dann sollte es auch ein Wergzeug
geben, mit dem man darauf zugreifen kann. dd?
Peter Sieg schrieb:> Diese Karte unter dem windows dd zeigt NUR die FAT16 Partition an!> Wenn ich da ein dd if=diskimage of=\\...die einzige angezeigte Part...> bs=512 mache, läuft avrcpm damit als A:
Ach ja, hatte ich ganz vergessen:
Es geht ja hier garnicht um Partitionen. Es geht darum, den ersten
Sektor von der Platte zu lesen und zu schreiben. Und das kann das dd,
das Du benutzt ja offensichlich. Schließlich hast Du bisher damit deine
CP/M-Images auf die Karten gebracht. Und wenn dd ab dem ersten
Platten-/Kartensektor schreiben kann, wird es wohl auch den 1. Sektor
lesen können.
Peter Sieg schrieb:> Das könnte so gehen.. aber das ist nicht einfacher als gleich eine> Live-CD zu nehmen.. (just my 2 cents)..
Für mich schon.
Bevor ich den Rechner (hier sogar 2x) wegen irgendwas neu starten muß,
installiere ich doch lieber gleich ein anderes Betriebssystem. (scnr)
Achso, daß habe ich vor 16 Jahren ja gemacht.
@Leo C.: Na, nu lass mal gut sein :-) Windows User, die keine Linux
Live-CD nehmen wollen, haben ja durch den sehr guten Fall-Back
Mechanismus immerhin das was alle vorher hatten.. nämlich LW A: =
gerechte Strafe würden jetzt Linux Nutzer sagen - alle anderen haben
halt bis zu 4 Laufwerke.. ;-)
=> kann ICH mit leben..
Trotzdem suche ich weiter, das unter Windows noch hinzubekommen.. ok?
;-)
(Cygwin hat cfdisk.. vergesst es!! Bloß die Finger weg davon.. erkennt
LW/Part. ebenfalls nicht.. und trägt sich noch nichtmal sauber ein zum
deinstallieren..)
Bin übrigens am WE nicht/wenig online..
Peter
Leo C. schrieb:> Wie greift man denn mit dd auf Geräte, bzw Partitionen, zu? Die> interessanteste Information hast Du weggelassen.
1
C:\cpmtools>dd2 --list
2
rawwrite dd for windows version 0.5.
3
Written by John Newbigin <jn@it.swin.edu.au>
4
This program is covered by the GPL. See copying.txt for details
5
Win32 Available Volume Information
6
...
7
NT Block Device Objects
8
\\?\Device\CdRom0
9
size is 2147483647 bytes
10
\\?\Device\Harddisk0\Partition0
11
link to \\?\Device\Harddisk0\DR0
12
Fixed hard disk media. Block size = 512
13
size is 160040803840 bytes
14
\\?\Device\Harddisk0\Partition1
15
link to \\?\Device\HarddiskVolume1
16
\\?\Device\Harddisk0\Partition2
17
link to \\?\Device\HarddiskVolume2
18
Fixed hard disk media. Block size = 512
19
size is 9663676416 bytes
20
\\?\Device\Harddisk1\Partition0
21
link to \\?\Device\Harddisk1\DR1
22
Removable media other than floppy. Block size = 512
23
size is 255852544 bytes
24
\\?\Device\Harddisk1\Partition1
25
link to \\?\Device\HarddiskVolume3
26
Removable media other than floppy. Block size = 512
27
size is 205599744 bytes
28
\\?\Device\Harddisk2\Partition0
29
link to \\?\Device\Harddisk2\DR2
30
\\?\Device\Harddisk2\Partition1
31
...
Wie man sieht, wird die gesamte SD Karte als
\\?\Device\Harddisk1\Partition0 erkannt und die FAT16 Partition als
\\?\Device\Harddisk1\Partition1.
Die anderen 3 Partition = Essig.
Und einfach auf ...Part.2 zu schreiben geht nicht:
Peter Sieg schrieb:> \\?\Device\Harddisk1\Partition0> link to \\?\Device\Harddisk1\DR1> Removable media other than floppy. Block size = 512> size is 255852544 bytes> Wie man sieht, wird die gesamte SD Karte als> \\?\Device\Harddisk1\Partition0 erkannt und die FAT16 Partition als
Also müßtest Du den MBR so lesen können?
dd if=\\?\Device\Harddisk1\Partition0 of=mbr-b.bin bs=512 count=1
Wenn ja, anschließend die ID's ändern und den MBR zurückschreiben.
> \\?\Device\Harddisk1\Partition1.> Die anderen 3 Partition = Essig.
Das ist natürlich ausgesprochen schade, daß die dort nicht erscheinen.
Dann müßte man vor und nach jedem Beschreiben einer CP/M-Partition den
MBR ändern. Das wäre mir dann auch zu umständlich.
Zu dem Thema habe ich das hier vorhin gefunden:
http://www.chrysocome.net/dd-backdoor
Das macht aber auch keinen Spaß.
> Und einfach auf ...Part.2 zu schreiben geht nicht:
Unter Linux kann man mit den cpmtool direkt auf die Karte zugreifen:
1
leo@cb:~$ cpmls -d -f avrcpm /dev/sdf3
2
ASM COM : DDT COM : DUMP COM : ED COM
3
INSTALL COM : LOAD COM : PIP COM : STAT COM
4
SUBMIT COM : T BIN : XSUB COM : MAILMRGE OVR
5
MERGPRIN OVR : WIMSGS OVR : WS COM : WSMSGS OVR
6
WSOVLY1 OVR : WSU COM
Da lohnt es sich ja fast, Linux in einer virtuellen Maschine zu
installieren, wenn man ansonsten mit Windows weiterarbeiten möchte.
Um mal etwas von der Diskussion der Partitionieung unter Windows
abzulenken.. ;-)
Aus meiner Sicht könnten nächste Schritte sein:
* Diskettenimage von 243kb vergrößern Richtung 1-xMB.
(Den riesigen Platz kann man ohne Unterverzeichnisse CP/M-like über
andere
USER x etwas übersichtlicher gestalten.. und die cpmtools erlauben die
Befüllung unterschiedlicher Userbereiche)
Da hat man dann auch mit nur einer 'Diskette' was davon ;-)
* Eine Möglichkeit auch ohne cpmtools einzelne Dateien zwischen der CP/M
und
der Host Welt auszutauschen. Das N8VEM Projekt verwendet dazu
klassisch
ein XModem (XM.COM) Programm.. das wäre sicher auch für uns eine gute
Wahl.
Andere Ideen..?
* Dann kämen ggf. die Z80 Opcodes dran...
* Und wie wäre es mit einem passenden, seriellen Terminal mit
BAS/VGA/LCD als
Bildschirm und PS/2 Tastatur ala PropTerm.. aber auch auf AVR Basis..?
Peter
Leo C. schrieb:> Also müßtest Du den MBR so lesen können?> dd if=\\?\Device\Harddisk1\Partition0 of=mbr-b.bin bs=512 count=1>> Wenn ja, anschließend die ID's ändern und den MBR zurückschreiben.
Ja kann ich.. ändert aber leider nichts daran, das dd die Partitionen
dann immer noch nicht bearbeiten kann.. der muß da wohl noch mehr als
nur die ID prüfen.. :-(
Peter
Peter Sieg schrieb:> Um mal etwas von der Diskussion der Partitionieung unter Windows> abzulenken.. ;-)
Oh, heute komme ich gar nicht mehr zum Essen.
> Aus meiner Sicht könnten nächste Schritte sein:> * Diskettenimage von 243kb vergrößern Richtung 1-xMB.
Klar, das muß kommen. Mit einem festen Format wärs auch schnell
gemacht.
> (Den riesigen Platz kann man ohne Unterverzeichnisse CP/M-like über> andere> USER x etwas übersichtlicher gestalten.. und die cpmtools erlauben die> Befüllung unterschiedlicher Userbereiche)
Leider werden die Userbereiche von CP/M 2.2 sehr schlecht unterstützt.
Mit CP/M 3 oder einer der 2.2 Alternativen wäre man da besser dran.
> * Eine Möglichkeit auch ohne cpmtools einzelne Dateien zwischen der CP/M> und> der Host Welt auszutauschen. Das N8VEM Projekt verwendet dazu> klassisch> ein XModem (XM.COM) Programm.. das wäre sicher auch für uns eine gute> Wahl.
Sollte kein Problem sein. Einfach mal ausprobieren.
> Andere Ideen..?
CP/NET? ;-)
> * Dann kämen ggf. die Z80 Opcodes dran...
Irgendwann sollte man das mal angehen, bevor das Flash mit anderen
Sachen voll ist. ;) Der Interpreter wird dadurch aber auf jeden Fall
langsamer werden. Ein Grund, warum ich das bisher nicht angegangen bin.
Wenn da nicht das ein oder andere wichtige Programm wäre, das Z80
vorraussetzt (mir fällt gerade nur Turbopascal ein), würde ich es sogar
ganz bleiben lassen.
> * Und wie wäre es mit einem passenden, seriellen Terminal mit> BAS/VGA/LCD als> Bildschirm und PS/2 Tastatur ala PropTerm.. aber auch auf AVR Basis..?
Anderes Projekt. :-)
Ansonsten will ich noch eine RAM-Disk einbauen. Beim Originalaufbau hat
man dafür zwar nur 64KByte, aber man könnte schonmal CCP+BDOS dort
deponieren und beim Warmstart von dort laden. Außerdem habe ich bei
meinem Aufbau jetzt 2 4x4MBit Chips drin. Das gibt dann eine RAM-Disk
mit knapp 4 MByte. :)
@Dagobert: Für 44,90€ ein gekapseltes Modul, was man dann noch mit
weiteren Bauteile in Richtung > 60€ zusammenbauen muß..?? Nein Danke.
Ansonsten schöne Arbeit.
@Leo C.
>Klar, das muß kommen. Mit einem festen Format wärs auch schnell>gemacht.
Warum nicht.. ist doch jetzt auch ein festes Format.. man muß doch nicht
immer alles variabel halten.. besser wäre es da wenn das ein Format
wäre,
das man auch dem AltairZ80 Emulator beibringen könnte.. dann kann man
Images
im Emulator laufen lassen und per R/W auch Dateien zw. CP/M und
Hostsystem transferieren..
Peter
Es gab Anfragen ob noch Leiterplatten verfügbar wären. Leider nein.
Bei genug Interessenten könnte natürlich eine neue Serie mit den
entsprechenden Änderungen aufgelegt werden. Mir fällt da spontan ein:
- geänderte Pinbelegung am RAM (RAM Disk)
- Video-VGA siehe weiter oben.
- weitere Vorschläge ???
Joe G. schrieb:> Es gab Anfragen ob noch Leiterplatten verfügbar wären. Leider nein.> Bei genug Interessenten könnte natürlich eine neue Serie mit den> entsprechenden Änderungen aufgelegt werden.
@Joe G. Ja, die beiden Pin's am Ram sollte mindestens aufgrund der
heutigen Erfahrungen getauscht werden.. ;-) Größerer Ram../ Ramdisk..
warten, was Leo C. hier zaubert.. beim Thema Terminal wirds etwas
schwieriger..
Was ich bisher so gefunden hatte:
Beitrag "AVR ASCII Video Terminal - 40 x 25 - BAS Signal"http://www.serasidis.gr/circuits/AVR_VGA/avr_vga.htmBeitrag "Einfacher Low Cost LCD Controller für 320x240 LCD im Textmodus"http://www.shaels.net/index.php/propterm
Obigen 3 fehlt noch die PS/2 Tastatur inkl. senden zum AVR.. Code dafür
ist
sicher verfügbar.. also entweder noch mit einbauen oder separat im
weiteren AVR aufbauen.. ideal würde ich auch die Realisierung mit
ATmega88/168 ansehen.. gleicher Baustein.. kann locker mir 20MHz - sogar
30MHz.. ein Programmer..
Propterm ist von dem was es kann sicher ideal.. aber ganz andere HW
Welt..
---
Wenn daran überhaupt genügend Interesse besteht (an einem passenden
Selbstbau-Terminal..) würde ich einen separaten Thread dazu
vorschlagen..
Und ein solches Terminal sollte ersteinmal entwickelt und auf
Steckbrett/LR aufgebaut werden, um dann zu entscheiden, ob es eine
separate Platine/abtrennbare Platine oder eine gemeinsame mit AVR CP/M
werden soll.. ich werde ersteinmal das uVGA testen.. da es auch 3,3V zur
Verfügung stellt.. fast schon ideal.. und für ca. 30€ kaum zu schlagen..
In jedem Fall wäre ich bei einer Neuauflage mit 1 Platine dabei ;-)
Dann sollte man auch mal prüfen, inwieweit aus den Ideen von Jörg
Wolfram (eigene Hardware mit BAS+PS/2 und SRAM-8bit) inzwischen etwas
geworden ist..
Peter
Das Problem bei fast allen Tastatur-Routinen ist es, dass meist nur
Normal und Shift-Ebene unterstützt wird, Alt-Ebene oder gar Sondertasten
kann man lange suchen. Von Caps-Lock-Steuerung rede ich gar nicht erst.
;)
Eine vollständige Tastatursteuerung, wie in VGATerm enthalten, hat es in
sich.
Auch die Ansteuerung des µVGA-Moduls ist sehr Tückenreich. Z.B. gibt es
oft Timing-Probleme, wodurch man viele Warteschleifen einbauen muss. Das
wurde mit VGATerm ebenso, dank eines 32 kB Empfangspuffers, eliminiert.
Aber wenn man die Unwegsamkeiten erst einmal überwunden hat, hat man
eine wirklich nutzbare VGA-Ansteuerung. Bei den oben genannten Systemem
fallen viele CP/M-Programme weg, weil diese einen 80x25-Zeichen
Bildschirm erfordern.
Dagobert schrieb:> Bei den oben genannten Systemem> fallen viele CP/M-Programme weg, weil diese einen 80x25-Zeichen> Bildschirm erfordern.
Ja.. alerdings basiert die BAS Lösung auf ATmega8 mit 16MHz.. Mit 88/168
und 25-30MHz sollte sich da ggf. noch was dran machen lassen..
Propterm hat schon alles was es braucht..
Allerdings zeigenja auch gerade VGAterm + uVGA das es grundsätzlich geht
;-)
Cool wäre aber aus meiner Sicht auch eine LCD Lösung..
Peter
Ich habe einige Jahre nach einer aufbaubaren Lösung gesucht. Immer war
ein CPLD oder FPGA notwendig. Ein normaler AVR schaffte evtl. gerade mal
die 80x25 Zeichen in SW und dann komplett ohne umfangreichere
Steuermöglichkeiten.
Bin mal gespannt, ob hier evtl. etwas entsteht, was auch von 'Max
Mustermann' ohne großes Programmierequipment oder Profi-SMD-Austattung
aufgebaut werden kann ;)
Peter Sieg schrieb:> Warum nicht.. ist doch jetzt auch ein festes Format.. man muß doch nicht> immer alles variabel halten..
Dann denk dir ein schönes Format aus (Größe u. Anzahl Dir-Einträge),
schnapp Dir das Alteration Guide oder eine andere Beschreibung und
erstelle die beiden Tabelleneinträge. Dann einfach in bios.asm
eintragen. den dpb braucht man dann nur einmal. Ich hatte nur 4 Plätze
für maximal 4 verschiedene Diskformate vorgesehen. Gestern Abend dachte
ich noch, damit wäre schon alles fertig.
Leider hatte ich nicht dran gedacht, daß bei Diskgrößen über 256KB die
Blockgrößte mindestens 2048 sein muß. Und die ist z.Zt. noch als
Konstante im avr-Teil.
also muß man noch in z80.asm unter
;*****************************************************
;* CP/M to host disk constants *
;*****************************************************
ändern auf
1
.equ blksize = 2048 ;CP/M allocation size
(oder gößer)
Bei der Gelegenheit kann man auch die Anzahl Sektoren pro Track auf
einen etwas größeren und "runderen" Wert setzen. Das muß aber nicht
sein. Mit 26 SPT kommt man auch bis 218MB Diskgröße. zB:
1
.equ CPMSPT = 32 ; oder 64 oder ...
Fertig. Ergebnis ggf. hier reinstellen oder mir zuschicken.
Natürlich darf sich auch jede(r) andere hier angesprochen fühlen.
Ach ja, ein passender Formateintrag für die cpmtools wäre dann auch
nicht schlecht, damit man damit einfach vom alten Format aufs neue
umkopieren kann.
> besser wäre es da wenn das ein Format wäre,> das man auch dem AltairZ80 Emulator beibringen könnte.. dann kann man> Images> im Emulator laufen lassen und per R/W auch Dateien zw. CP/M und> Hostsystem transferieren..
Falls Du den simh Altair 8800 Simulator meinst (den kenne ich, es gibt
aber wahrscheinlich noch andere):
Der hat variable Formate! Das Disk Image ist sicher irgendwo
dokumentiert (auf jedenfall im source, natürlich) aber ich bin bis jetzt
noch nicht über die Doku gestolpert. Vor dem eigenlichen CP/M-Diskimage
ist auf jeden Fall noch ein nicht gerade kleiner Header.
Joe G. schrieb:> Es gab Anfragen ob noch Leiterplatten verfügbar wären. Leider nein.> Bei genug Interessenten könnte natürlich eine neue Serie mit den> entsprechenden Änderungen aufgelegt werden. Mir fällt da spontan ein:> - geänderte Pinbelegung am RAM (RAM Disk)> - Video-VGA siehe weiter oben.> - weitere Vorschläge ???
Wie wärs mit 2 RAM-Chips (8 Bit breiter Datenbus)? Die Chips sind ja
massenweise kostenlos vorhanden und der Schaltungsmehraufwand ist imho
minimal. Also immer noch ein Lowcost Projekt.
Damit sich das lohnt, braucht man am Prozessor einen 8 Bit breiten Port.
Den bekommt man, wenn man die Serielle Schnittstelle verlegt. So sieht
dann das Ergebnis aus:
"HW A" ist die jetzt aktuelle Verdrahtung und "HW C" die 8-Bit Variante.
Es ist also fast nochmal eine Geschwindigkeitsverdopplung drin.
Zu den Details hatte ich am Montag schon mal einen Artikel geschrieben,
der aber hier nicht (mehr?) vorhanden ist. Vielleicht drücke ich ja
öfters auf Vorschau statt Absenden, oder...
Die Software dazu gibts in meinem SVN im softuart Zweig.
Leo C. schrieb:> Wie wärs mit 2 RAM-Chips (8 Bit breiter Datenbus)? Die Chips sind ja> massenweise kostenlos vorhanden und der Schaltungsmehraufwand ist imho> minimal. Also immer noch ein Lowcost Projekt.
Die Idee finde ich super! Welche Baudrate ist dann mit Soft-Uart noch
sinnvoll? Alternativ wäre natürlich auch ein AVR mit mehr Pin's :-)
Leider bin ich dieses WE in Familienfeier unterwegs.. ich werde mir aber
nächste Woche mal das CP/M Alteration Guide besorgen und mal versuchen,
das diskimage Format zu vergrößern.. soll aber niemanden davon abhalten
das auch zu machen.. bei mir kann das schon etwas dauern.. ;-) ;-)
Peter
Peter Sieg schrieb:> Die Idee finde ich super! Welche Baudrate ist dann mit Soft-Uart noch> sinnvoll? Alternativ wäre natürlich auch ein AVR mit mehr Pin's :-)
Senden geht mit 115k problemlos.
Empfangen habe ich bis 56700 getestet. Das ging, als die gröbsten Fehler
draußen waren. Es könnte auch noch mehr dring sein. Der Code ist aber
noch etwas chaotisch und müßte dringend aufgeräumt werden. Dann könnte
man auch noch eine etwas bessere Fehlererkennung/behandlung einbauen.
"Leider" gibts bei der üblichen Verbindung mit PC ja so gut wie keine
Übertragungsfehler.
Gilt alles für 20Mhz Prozessortakt.
> Leider bin ich dieses WE in Familienfeier unterwegs.. ich werde mir aber> nächste Woche mal das CP/M Alteration Guide besorgen und mal versuchen,> das diskimage Format zu vergrößern.. soll aber niemanden davon abhalten> das auch zu machen.. bei mir kann das schon etwas dauern.. ;-) ;-)
Ich werde mich bis auf Weiteres auch nicht dransetzen, da ich ja gar
kein größeres Format brauche. ;-)
Den Satz hatte ich doch glatt übersehen:
Peter Sieg schrieb:> Alternativ wäre natürlich auch ein AVR mit mehr Pin's :-)
Ja klar, und statisches RAM und...
... und vielleicht doch ein ez80 :-)
Übrigens habe ich Moment rein zufällig genau die 2 Pins für die
I2C-Schittstelle frei... :-)
Leo C. schrieb:> Wie wärs mit 2 RAM-Chips (8 Bit breiter Datenbus)? Die Chips sind ja> massenweise kostenlos vorhanden und der Schaltungsmehraufwand ist imho> minimal. Also immer noch ein Lowcost Projekt.
Gute Idee Port D doppelt zu belegen, auch PC4 und PC5 frei zu lassen.
Was möchtest du dort angeschlossen haben, ein RTC, eine PIO, ...
Ich erstelle mal einen neunen Schaltplan zu der Soft-Uart Variante.
Nachtrag:
Da das Erstellen mehrerer diskimages unter Windows nun etwas kompliziert
wird, siehe weiter oben, bietet sich ein nettes Tool wie "Parted Magic"
an. Läuft als Live-CD oder USB-Stick oder unter VM.
Joe G. schrieb:> Was möchtest du dort angeschlossen haben, ein RTC, eine PIO, ...
Wg. I2C drängt sich eine RTC ja förmlich auf. Aber irgend was sträubt
sich in mir. Gibt es I2C-(Flash-)ROMs im ca. einstellingen Megabit
Bereich? So als ROM-Disk oder SSD?
Ursprünglich dachte ich an Inputs, z.B. Taster für Z80 Reset, bzw.
Interrupt.
Damit könnte man z.B. ein hängendes Programm in den Debugger
zurückholen.
Frontpanel?
CS-Leitungen für SPI-Erweiterungen wäre auch denkbar.
Am Besten ein großes Lochrasterfeld vorsehen. Und/Oder Pfosten für
Huckepackerweiterungen.
Als DRAM habe ich 1Mx4 im SOJ26-20 Package vorgesehen. Das sollte noch
gut zu löten sein und außerdem gut verfügbar. Bei I2C bin ich mir noch
unsicher, Portererweiterung ist auch denkbar.
Das ist ja mal wieder ein Mist. (sorry, mußte raus)
Ich habe gerade meine Bestände durchgesehen, und festgestellt, daß ich
fast nur 4Mx4 habe. Ich dachte mir, macht ja nix, man kann ja einfach
die 2 Adressleitungen zusätzlich verbinden. In dem einen Datenblatt, daß
ich von 1Mx4 hier habe, habe ich aber gerade gesehen, daß die
anscheinend eine völlig andere Pinbelegung haben.
Joe G. schrieb:> @Leo C. alle anderen natürlich auch.>> Bitte mal durchsehen ob der RAM / MMC mit der Soft-Uart Variante> übereinstimmt.
Ich habe bis jetzt nur mal kurz drauf geschaut. Und es stimmt leider.
Deine Verdrahtung paßt zu dem 1Mx4 Datenblatt, und die 4Mx4 Datenblätter
sind alle anders. Beides vorsehen, für wahlweise Bestückung, wird wohl
viel zu aufwendig sein. Mir ist es egal, weil ich keine Platine brauche.
In meiner PC-Restekiste habe ich 7 verschiedene 72-polige RAM-Modul
Sorten.
Davon nur eines mit 1Mx4 bestückt.
Joe G. schrieb:> @Leo C. alle anderen natürlich auch.>> Bitte mal durchsehen ob der RAM / MMC mit der Soft-Uart Variante> übereinstimmt.
An die Datenleitungen von IC5 (oder IC4) sollten D4_A4 bis D7_A7
angeschlossen werden.
1Mx4 Chips haben auch eine A9. Nächster Pin wäre PB4 (MISO).
Und falls es 4Mx4 Chips werden sollten, käme noch eine A10 dazu (-->
PB5).
Der Rest scheint ok zu sein. RAS bis WE, A8 bis A9/10 und D0_A0 bis
D7_A7 kann man sowieso frei untereinander tauschen, wenn dadurch z.B.
das Layout einfacher wird.
Pullups am SD-Slot?
Chan empfiehlt sie sehr (aber einen Pulldown an CLK), hat sie aber bei
seinem neuesten GPS-Logger auch weggelassen.
Ich mache immer eine LED an CS mit R nach VCC. Macht sich hier besonders
gut als Drive-Select-Lampe.
@all: An Rams kann man aber auch die 256x4 2-mal nehmen.. 2ter Chip in
jetziger Platine huckepack, nur D0-D3 an D4-D7.. damit sollte die
vorhandene
Platine auch auf 8-bit Dram erweiterbar sein (4 Leitungen zum
Huckepackram legen + Uart umverdrahten..)
(PS: Ich finde die SOJ SCH*** zum löten ;-) - aber habe ich auch schon
hinbekommen..)
Peter
Leo C. schrieb:> An die Datenleitungen von IC5 (oder IC4) sollten D4_A4 bis D7_A7> angeschlossen werden.
Hab ich beim abspeichern gemerkt, ist schon geändert.
Leo C. schrieb:> Pullups am SD-Slot?> Chan empfiehlt sie sehr (aber einen Pulldown an CLK), hat sie aber bei> seinem neuesten GPS-Logger auch weggelassen.
Pullups sind ja normalerweise im AVR schon vorhanden, Pulldown an CLK?
steilere Flanken? Mein Oszi zeigt kein Unterschied.
Leo C. schrieb:> Ich mache immer eine LED an CS mit R nach VCC. Macht sich hier besonders> gut als Drive-Select-Lampe.
Nette Idee.
RAM Frage:
1M x4 oder 4M x4, mir ist es egal. Peter möchte nicht löten ;-) Ich
nehme meine ursprügliche Idee mal wieder auf. Für den RAM gibt es eine
28 polige IC Fassung und da steckt jeder drauf was er hat. Als
"Default-RAM-Stecker-Layout" gib es drei kleine RAM-Adapterplatinen, 1M
x4, 4M x4, 256 x 4.
Joe G. schrieb:> Pullups sind ja normalerweise im AVR schon vorhanden, Pulldown an CLK?> steilere Flanken? Mein Oszi zeigt kein Unterschied.
Am CLK ist Low-Pegel der Normal/Ruhezustand. Bei den anderen Pins ist es
High.
Zur Zeit werden die internen Pullups komplett abgeschaltet, damit man
ganze Bytes auf die Ports schreiben kann, ohne daß Pullups in Portbits,
die als Input programmiert sind, ständig ein- und ausgeschaltet werden.
Für die jetzige Schaltung kann man das aber ändern, wenn man PC4 und PC5
nicht als Inputs benutzt, oder das Pullupflattern egal ist.
Bleibt noch der Resetzustand...
> RAM Frage:> 1M x4 oder 4M x4, mir ist es egal. Peter möchte nicht löten ;-) Ich> nehme meine ursprügliche Idee mal wieder auf. Für den RAM gibt es eine> 28 polige IC Fassung und da steckt jeder drauf was er hat. Als> "Default-RAM-Stecker-Layout" gib es drei kleine RAM-Adapterplatinen, 1M> x4, 4M x4, 256 x 4.
Mir ists auch egal. Und Peter hat ja nur geschrieben, daß er nicht
gerne lötet.
Ich habe bei mir das 2. SOJ-RAM übrigens auch Huckepack auf das erste
gelötet. Wobei es jetzt eigentlich kein SO J mehr ist. ;-)
Schönes Wochenende
Leo
(Nach Diktat verreist)
Hier nun die SOJ26-24 Variante, also CP/M mit 4 MB. D0-D7 nun korrekt,
Pullup und Pulldown an MMC, LED an CS noch nicht (kommt noch) und I2C
wartet noch auf Ideen.
@Joe G. Können gerne SOJ nehmen.. kriege ich hin.. ist aber für sonst
nur DIL Verbauer eine kleine Herausforderung ;-) Deshalb: Einfach auf
eine Version einigen..und fertig. Keep it simple..
(Ich habe eine ganze Schachtel voll alter Ramriegel.. muß selbst erstmal
schauen, was ich da noch so finde..)
Eine Idee hätte ich allerdings noch:
Quarz+2xC ersetzen durch Quarzoszillator.. es ist so gut wie unmöglich
ab >25MHz noch Grundtonquarze zu bekommen (für 30MHz ist mir das
allerdings noch gelungen..).. Aber Quarzoszi's für 32/36/40MHz ist kein
Problem..
--- zum softuart und 8-bit dram access ---
; - Soft UART TX (OC1A/OCR1A).
; - Soft UART RX (ICP1/ICR1).
Das sin die beiden Uart Pins?
Ansonsten sehe ich nur D0-D3 definiert..? Ich hatte D4-D7 erwarten..?
Normalerweise dachte ich 2tes Dram Huckepack aufzulöten - alle Pins -
bis
auf D0-D3 und diese 4 Pins ergeben dann das 2te Nibble..
Peter
Peter Sieg schrieb:> Quarz+2xC ersetzen durch Quarzoszillator..
Ja, ist sicher besser. Schon in Hinblick auf mögliche Erweiterungen in
Richtung VGA (25.179 MHz) ;-)
Peter Sieg schrieb:> Ansonsten sehe ich nur D0-D3 definiert..?
Schau mal im letzen Schaltplan, den Tag davor hatte ich geträumt. Die
Soft UART Pins sind so wie in Leo C. Quelle.
C4 oder C5 könnte man auch als /CS für ein weiteres SPI-Gerät nutzen.
Ich habe hier noch ein Vinculum Vdrive rumliegen. Damit hat Leo C. sein
SSD im mehrstelligen GB-Bereich oder was ein USB Stick so hergibt. FAT
ist auch schon dabei, außerdem könnte man CP/M Programme über USB-Stick
austauschen.
Joe
@ Peter Sieg
ich habe damit angefangen und es funktioniert auch recht gut, allerdings
mehr als die Testprogramme hier im Thread habe ich nicht laufen lassen.
Aus Mangel an Interesse sowohl bei mir als auch im ChipBasic Thread habe
ich das Ganze aber erstmal wieder auf Eis gelegt. Beim nächsten Release
wird der 8080-Emulator mit dabei sein, mehr aber wahrscheinlich nicht.
Jörg
Hallo. Hier noch ein weiteres diskimage (um die Partitionen zu füllen
;-).
Es enthält den BDS C-Compiler und ein paar C-Sourcen von Spielen.
Übersetzung mit cc <datei.c> und dann clink <datei>.
Belegt nur ca. 100kb auf dem 243kb Image.
ED als Zeileneditor ist ebenfalls enthalten. Leider läuft der
Fullscreen-Editor VDE nicht..? Falls jemand noch einen kleinen,
einfachen Fullschreeneditor für CP/M-80 hat..
---
MicroVGA läuft auch am avr cp/m. 115200 baud schafft es aber nicht ohne
HW Handschake.. läuft jetzt mit 38400 baud.. stelle noch zwei Bilder
ein..
Der 3,3V Ausgang des MicroVGA ist hier wirklich sehr praktisch!
Peter
Peter Sieg schrieb:> MicroVGA läuft auch am avr cp/m.
Hat deine einstabiles Bild? Bei mir sehen die Buchstaben arg zerfranst
aus. Hast du mal die Pegel der seriellen Schnittstelle gemessen, 5V oder
3.3V ? Auf der Leiterplatte ist ja nicht so richtig zu erkennen wo die
3.3V Leitung bleibt und die 5V Leitung ist äußerst dünn ausgeführt.
Ich würde das neue Layout so ausführen, dass die MicroVGA Platine direkt
aufgeschraubt und verbunen werden kann. Für die 5V gibt es dann eine
übliche Klinkenbuchse.
Joe
Joe G. schrieb:> Hat deine einstabiles Bild? Bei mir sehen die Buchstaben arg zerfranst> aus.
Das Bild ist stabil. Aber die Buchstaben sehen hier auf dem 22" TFT auch
nicht schön aus :-( Habe sowas aber schon bei einigen Sachen gesehen, wo
800x600/640x480/80x25 Text (also geringe Auflösungen) versucht wird auf
solche großen Bildschirme 'hochzurechnen'..
Die Anschlüsse so zu legen, das MicroVGA direkt passt ist eine gute
Idee!
Ist wie gesagt eine doch noch recht preiswerte Möglichkeit einen
Stand-Alone CP/M Rechner zu basteln.. Ca. 30€ sind aus meiner Sicht ok.
Muß noch mal sehen, das auch Programme mit VT100/Ansi Sequenzen auch gut
laufen..
Eine Alternative könnte PropTerm sein.. Habe dafür aber noch kein
Fertigmodul/Bausatz/Platinenlayout/etc. gefunden..
Was ich z.Z suche ist ein einfacher Fullscreen Ascii/Text-Editor..
Wäre auch schön, wenn der einer oder andere auch mal ein diskimage
zusammen stellen würde mit z.B anderen Programmiersprachen oder
Anwendungen etc.
Peter
Schaltug / Layout
Da der Wunsch nach Taktfrequenzen über 20 Mhz besteht und Quarze in
diesem Bereich dünn werden, ist ja der Einsatz eines Quarzoszillators
geplant. Nun laufen dieses (DIL Variante) wiederum nur mit 5V und nicht
mit 3.3V. Was haltet ihr von dieser Variante:
- AVR und RAM laufen auf 5V (kann damit höher übertaktet werden)
- MMC wird über 74CHC08 auf 3.3V betrieben.
- als Spannungsregler kommt wieder der interne Regler des FTDI zum
Einsatz
- alle weiteren Busgeräte I2C, SPI laufen auf 5V oder SPI auf 3.3V
Das Konzept erfordert zusätzlich genau einen 74VHC08.
Joe
Hmm.. SMD Oszi gibt z.B bei reichelt zw. 25-50MHz (XO32 40,00000). Die
laufen mit 3,3V...
Ich würde ungern das Layout/die nötigen Bauteile weiter 'aufblähen' ;-)
BTW: Warum Man(n) auch unbedingt 2 x Dram's a 4-bit nehmen muß und nicht
1 x Sram (628128-70) muß Man(n) auch nicht wirklich verstehen.. ;-)
(Nein, kein ez80 etc. ;-)
BTW: Hat jemand eine Lösung, wie ich cmd.exe unter XP so laufen lassen
kann, das ich mit dem AltairSimh Emulator Programme testen kann, die
VT52/VT100/Ansi Escape-Sequenzen nutzen..? Kann gerne auch ein anderer
Shell-Ersatz etc. sein.. evtl. könnte ja telnetd + telnet hier gehen..
ist aber ein wenig oversized an Aufwand - oder?
Peter
Peter Sieg schrieb:> Warum Man(n) auch unbedingt 2 x Dram's a 4-bit nehmen muß und nicht> 1 x Sram (628128-70) muß Man(n) auch nicht wirklich verstehen.. ;-)
Wegen der fehlenden Pins - A0 bis A16.
Alles mit 5V laufen zu lassen hatte noch einen Grund. Meine
VGA-Testschaltung läuft auch mit 25 MHz, das Schieberegister und die
Leitungstreiber sowie die Tastaturschnittstelle mit 5V. Diese IC's habe
ich nicht als VHC-Type gefunden. Diese Schaltung würde ich gleich mit
anstückeln. So kann sie für weitere Experimente benutz werden oder bei
Bedarf durch die MicroVGA überbaut werden. Der beansprüchte Platz und
die Pinbelegung ist gleich.
Joe
Zum Terminal:
Mein TKTerm (Download auf www.DieProjektseite.de) beherscht die
Ansi-Sequenzen, welche auch µVGA kann. In Kürze gibt es eine weitere
Version des Programms wo dann auch die Baudratenauswahl funktioniert.
Wer die neue Version haben möchte, kann mich anschreiben (über die
Projektseite). Dem sende ich dann die aktuelle Version zu.
@Dagobert: ???! Ich suche ein Programm das solche ESC Sequenzen in einem
Win32 CMD(Command) Fenster interpretiert. Für serielle IF's gibts
viele..
@Joe: VGA-Testschaltung..? Es könnte Sinn machen, hier ein VGA Terminal
und PS/2 Tastatur-IF mit aufzunehmen.. allerdings eine fertige
Schaltung+SW dazu (80x25 Zeichen mit ESC IP) habe ich - außer PropTerm -
noch nicht gefunden..
Peter
Hier die Bilder von AVR CP/M + MicroVGA.
---
@Joe: Was die HW angeht, bin ich fast für alles offen, wenn es dem CP/M
Gedanken folgt, so einfach wie möglich - nur nicht einfacher!
Mit dem bisher erreichten kann man schon sehr zufrieden sein!
2 x Drams mit mehr Bytes bringt:
a. Faktor 2 in der Geschwindigkeit
b. Mögliche Erweiterungen in Richtung Ramdisk etc.
=> Ergo. Sollte in einer nächste Version mit aufgenommen werden.
Quarzoszillator ermöglicht übertakten bis 36/40/?? MHz, was wiederum
mehr Geschwindigkeit bringt und nicht viel kostet und die HW auch nicht
komplizierter macht.
=> Ergo. Reinnehmen.
I2C eröffnet ebenfalls noch ungeahnte Möglichkeiten und kostet=nichts.
=> Ergo. Reinnehmen.
Das mit dem Vinculum USB Drive dürfte auch sehr interessant sein..
Eine einfache Möglichkeit Dateien zw. CP/M und Host-Welt auszutauschen
wäre schon schön..
Alles andere, wenn es denn das System sinnvoll erweitert bzw. ergänzt..
warum nicht.. ein Selbstbauterminal (VGA-Out+PS/2 Tast.-In) sollte
allerdings ersteinmal als LR/Steckbrettaufbau funktionieren..
Just my 2 cents.
Peter
Hier der Vorschlag mit folgenden Änderungen:
- 4MB RAM
- LED an CS MMC
- 3.3V an MMC, nicht mehr versehentlich auf 5V steckbar
- 3.3V wahlweise über FTDI oder MicroVGA
- AVR und RAM kann wahlweise mit 3.3V oder 5V betrieben werden (hat
keinen Einfluß auf Spannung der MMC)
- Takt über FTDI oder Quarzoszillator
- mögliche Steckvarianten der V24 sind:
USB - CP/M
CP/M - VGA
USB - VGA
noch offen:
- Vinculum USB Drive
- I2C
Es geht nur eines von beiden, da bei einem weiteren SPI Device ein
zusätzliches CS benötig wird. Wir sollten uns auf eine Variante
festlegen oder es als Lochraster auslegen.
Peter Sieg schrieb:> sollte> allerdings ersteinmal als LR/Steckbrettaufbau funktionieren..
Da funktioniert es Lochrastermäßig ;-) H-Sync und V-Sync kommen exakt,
Pixeltakt und Zeichen auch. Aber durch Steckbrettaufbau mit viiiiel
Jitter. Schaltugsvorschlag dazu folgt noch.
Joe
Joe G. schrieb:> noch offen:> - Vinculum USB Drive> - I2C> Es geht nur eines von beiden, da bei einem weiteren SPI Device ein> zusätzliches CS benötig wird.
Hmm. VDRIVE2/VDIP1+2 können auch per UART gesteuert werden..
Bräuchte eine 2te serielle Schnittstelle (9600 8N1) und ein
entsprechendes Terminalprogramm unter CP/M, was über diese Schnittstelle
mit dem V* Device spricht und mit den vorhandenen Kommandos Dateien zw.
CP/M und V* Device liest und schreibt..
Peter
Peter Sieg schrieb:> VDRIVE2/VDIP1+2 können auch per UART gesteuert werden..> Bräuchte eine 2te serielle Schnittstelle (9600 8N1) und ein> entsprechendes Terminalprogramm unter CP/M
Das wird aber arg langsam...
Mir scheint SPI die bessere Lösung zumal man ja dem BIOS beibrigen kann,
dass genau dieses SPI Gerät die COM1 oder COM2, ... ist. Dann sollte
auch ein Terminal gehen.
Peter Sieg schrieb:> BTW: Warum Man(n) auch unbedingt 2 x Dram's a 4-bit nehmen muß und nicht> 1 x Sram (628128-70) muß Man(n) auch nicht wirklich verstehen.. ;-)
Für mich ist das Ganze ein Bastelkistenprojekt. D.h. es wird nur aus
Teilen zusammengebaut, die in der Bastel-/Reste-/Ramschkiste vorhanden
sind. D-Rams sind da reichlich drin. Große statische Rams eher nicht.
(ATmegas habe ich allerdings auch nicht im Überfluß, und meinem
GPS-Logger habe ich schon den 328P geklaut. ;)
Peter Sieg schrieb:> Hier die Bilder von AVR CP/M + MicroVGA.
Am Besten gefallen mir die geschraubten Nagelschellen. ;-)
Joe G. schrieb:> noch offen:> - Vinculum USB Drive
Kommt für mich nicht in Frage. (siehe oben)
> - I2C> Es geht nur eines von beiden, da bei einem weiteren SPI Device ein> zusätzliches CS benötig wird. Wir sollten uns auf eine Variante> festlegen oder es als Lochraster auslegen.
Ich fände ein paar Inputs ganz brauchbar. ZB. vom SD-Kartensockel
Card-Detect und evtl Write-Protect. Ferner Z80 Interupt/Reset. Wenn die
2 Pins nicht reichen: Schieberegister.
Im Anhang mal ein Bild vom Huckepack-Ram. (ex SOJ:)
In meinem SVN Repo gibts ein paar Updates. Im trunk ("alte" Hardware)
eigentlich nur ein paar Bugfixes. Bei einer partitionierten SD-Karte
wird jetzt sichergestellt, daß nicht außerhalb der CP/M-Partitionen
gelesen, und vor allem geschrieben wird. Wer also seine
CP/M-Partition(en) kleiner als das darin befindliche CP/M-Dateisystem
definiert hat, und noch andere, wichtige Daten auf der Karte hat, sollte
unbedingt updaten.
Im softuart-Zweig (8-Bit DRAM) das Gleiche. Plus RAM-Disk (Laufwerk I:).
Die RAM-Disk ist im Moment nur 64KB groß, damit sie auch bei den
kleinsten RAM-Chips noch funktioniert. Davon gehen dann noch 8KB für 2
Systemspuren ab.
Beim Kaltstart wird das CP/M von A: auf die RAM-Disk kopiert und beim
Warmstart von dort neu geladen. Sinn des ganzen sollte sein, daß man
nach dem booten die SD-Karte ziehen kann, und ohne sie weiterarbeiten
kann.
Leider macht uns CP/M hier einen Strich durch die Rechnung: Beim
Warmstart wird grundsätzlich auf A: zugegriffen, auch wenn der Benutzer
auf ein anderes Laufwerk umgeschaltet hat.
Abhilfe:
1. BDOS patchen. Andere (z.B. simh) machen das auch so.
2. Die RAM-Disk als Laufwerk A: verdrahten.
3. Alternatives CP/M (BDOS) verwenden? (Bekannte, gute Alternativen
setzen Z80 voraus)
Anderes, damit im Zusammenhang stehendes Problem:
Wenn man die SD-Karte zieht und wieder einsteckt, wird beim nächsten
Zugriff das System komplett neu gestartet. Das ist erst mal leicht zu
korrigieren, in dem z.B. bei einem Warmstart (^C) die Karte neu
initialisiert wird. Allerdings muß man dann auch die Partitionierung neu
einlesen. Wenn bei jedem Warmstart die Liste der gefundenen Partitionen
erscheint, nervt das aber...
Für Vorschläge, wie man das System an dieser Ecke rund macht, bin ich
dankbar. Hat überhaupt schon jemand die 8-Bit-Ram Variante nachgebaut,
und kann damit die RAM-Disk mal testen? Ich weiß noch nicht, ob ich die
in die 4-Bit-Ram Variante überhaupt noch einbauen soll.
Beide neuen Versionen laufen nur mit neuem BIOS, und das neue BIOS nur
mit neuem IPL. Beides ist auch im SVN. Ich habe aber auch mal ein
fertigs System hier angehängt.
Leo C. schrieb:> Hat überhaupt schon jemand die 8-Bit-Ram Variante nachgebaut,> und kann damit die RAM-Disk mal testen? Ich weiß noch nicht, ob ich die> in die 4-Bit-Ram Variante überhaupt noch einbauen soll.
Hi Leo C.
Ich bin noch nicht dazu gekommen, die 8-bit Variante nachzubauen. Ich
plane dazu meine LR Version umzubauen. Könntest du bitte nochmal
aufzeigen, wie genau ich was verdrahten muß? Ich gehe im Moment davon
aus:
1. 2ten Dram Chip 1:1 mit dem ersten verbinden (Huckepack) - bis auf
D0-D3!
2. Dram 1ter Chip verbinden:
D0 - 2 - PD0
D1 - 3 - PD1
D2 - 4 - PD2
D3 - 5 - PD3
3. Dram 2ter Chip verbinden:
D0 - 6 - PD4
D1 - 11 - PD5
D2 - 12 - PD6
D3 - 13 - PD7
4. Uart RX liegt dann an AVR Pin 14 = ICP1/ICR1
5. Uart Tx liegt dann an AVR Pin 15 = OC1A/OCR1A
Ups.. ich sehe gerade, das ist eine komplette Umverdrahtung!! Da kann
ich wahrscheinlich schneller einen kompletten Neuaufbau auf LR machen..
;-) Meine Platinen werde ich jedenfalls nicht so vergewaltigen.. Ich
glaube da brauchen wir die nächste Platinenversion doch eher als ich
gedacht hatte.. ;-)
> LW A: in Ramdisk umkopieren..
Das würde ich so nicht machen.. Evtl. hat man z.B seinen C Compiler auf
C: und möchte eher diesen in der Ramdisk haben (wozu allerdings 64kb zu
wenig wäre..).. eher sowas wie eine autoexec.bat ausführen, wo man dann
selbst definieren kann, was evtl. wohin kopiert werden soll..
>Wenn man die SD-Karte zieht und wieder einsteckt, wird beim nächsten>Zugriff das System komplett neu gestartet. Das ist erst mal leicht zu>korrigieren, in dem z.B. bei einem Warmstart (^C) die Karte neu>initialisiert wird. Allerdings muß man dann auch die Partitionierung neu>einlesen. Wenn bei jedem Warmstart die Liste der gefundenen Partitionen>erscheint, nervt das aber...
Ach.. macht doch nichts.. oder wenn gefundene Part. den vorher
gefundenen entsprechen.. Meldungen unterdrücken.. ;-)
>Ich weiß noch nicht, ob ich die>in die 4-Bit-Ram Variante überhaupt noch einbauen soll.
Da dann nur 64k zur Verfügung wären.. eher nein.. oder kann man das für
temp. Dateien eines C Compilers nutzen..?
Peter
Leo C. schrieb:> Ich fände ein paar Inputs ganz brauchbar. ZB. vom SD-Kartensockel> Card-Detect und evtl Write-Protect. Ferner Z80 Interupt/Reset. Wenn die> 2 Pins nicht reichen: Schieberegister.
- PCF8574 an I2C? Damit gibt es nochmal 8 Bit.
> Im Anhang mal ein Bild vom Huckepack-Ram. (ex SOJ:)
Deshalb brauche ich eine Platine, solche Lötarbeiten werden mit
zunehmenden Alter unmöglich.
> Abhilfe:> 3. Alternatives CP/M (BDOS) verwenden? (Bekannte, gute Alternativen> setzen Z80 voraus)
Ich denke diese Variante ist die flexibleste Lösung.
> Hat überhaupt schon jemand die 8-Bit-Ram Variante nachgebaut,> und kann damit die RAM-Disk mal testen? Ich weiß noch nicht, ob ich die> in die 4-Bit-Ram Variante überhaupt noch einbauen soll.
Ich noch nicht, werde ich auch ohne neue Platine nicht
(Altersaugenpulver ;-)). Von mir aus reicht die RAM-Disk in der 8-Bit
Variante.
@alle
Gibt es denn außer bein Leo C. Peter und mir noch weitere lauffähige
Systeme? Wenn nicht, können wir irgendwie helfen?
Peter Sieg schrieb:> Könntest du bitte nochmal> aufzeigen, wie genau ich was verdrahten muß? Ich gehe im Moment davon> aus:
Du kannst Den neuen Schaltplan von Joe nehmen.
> Ups.. ich sehe gerade, das ist eine komplette Umverdrahtung!!
Überraschung ;-)
> Da kann> ich wahrscheinlich schneller einen kompletten Neuaufbau auf LR machen..> ;-) Meine Platinen werde ich jedenfalls nicht so vergewaltigen.. Ich> glaube da brauchen wir die nächste Platinenversion doch eher als ich> gedacht hatte.. ;-)
Ich hatte mich eh schon gewundert, als Du mal vom Platinenumverdrahten
geschrieben hattest.
>> Wenn bei jedem Warmstart die Liste der gefundenen Partitionen>> erscheint, nervt das aber...> Ach.. macht doch nichts..
Doch, die Warmstarts werden ja auch bei (fast) jeder Beendigung eines
Programms ausgeführt. Bei Batchdateien nach jeder Zeile.
> oder wenn gefundene Part. den vorher> gefundenen entsprechen.. Meldungen unterdrücken.. ;-)
Oder umgekehrt: Nur ausgeben, wenn Partitionen geändert. ;)
So werde ichs machen. Kartenwechsel ohne Kaltstart muß einfach möglich
sein, da die "usability" sonst in den Keller sinkt.
>>Ich weiß noch nicht, ob ich die>>in die 4-Bit-Ram Variante überhaupt noch einbauen soll.> Da dann nur 64k zur Verfügung wären.. eher nein.. oder kann man das für> temp. Dateien eines C Compilers nutzen..?
Kommt wahrscheinlich auf die Größe Deiner C-Programme an. :)
Ansonsten ist das natürlich der Hauptzweck einer RAM-Disk.
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.
Hans- w. Schütz schrieb:> 01<38@0139M: fill...wait...reread...F0<00@0000> nach einem Reset:> CPM on an AVR, v1.0> Fô<83@0083M: fill...wait...reread...F0<00@0000
An der Ausgabeformatierung muß ich wohl noch etwas feilen.
Verdrahtungsfehler oder defektes RAM im oberen Nibble?
Ach nein, das untere Nibble hat ja auch Fehler.
Wird dieses "o mit Dach" während des Ramtests ausgegeben, oder kommt das
durch den Reset zustande?
Ansonsten:
Prozessor?
Taktfrequenz?
RAM-Typ?
Über eine Antwort auf meine Frage in diesem Artikel würde ich mich auch
noch freuen:
Beitrag "Re: CP/M auf ATmega88"
Frank Zoll schrieb:> Leo C. schrieb:>> Wir freuen uns jetzt auf den FAT16-Treiber. :-)>> Hihi,>> ich auch. Ich habe mir gestern Nacht schonmal ein wenig den Kopf darüber
Hey, super.
> - Die Performance wird gegenüber den direkten CP/M Partionen stark> leiden. Bei jedem Sektorzugriff muss dieser erst umständlich in der> jeweiligen Image-Datei gesucht werden. ( Juhu Retro like nix schnelle> :-) )
Ich glaube, so schlimm wirds garnicht. Die SD-Zugriffe sind im Vergleich
zum Interpreter und zu den RAM-Zugriffen nämlich sauschnell. Die
RAM-Disk ist auch eher langsamer als die SD-Disk(s).
> FAT16 System. Ich werde mit den derzeit noch verbliebenen knapp 100> Bytes SRAM eines 168AVR's wohl hinkommen. ( Ein paar Bytes werde ich> noch überlassen :-) )
Und wenns doch nicht reicht, kann man die UART RX/TX-Buffer noch
verkleinern. Gut wäre natürlich, wenn man einen 2. Sektorpuffer hätte.
Das würde mit dem ATmega328 gehen.
Leo C. schrieb:> Wenn ich's recht überblicke, sind die ersten 3 "Fast Page Mode" RAM's,> also keine EDO's. Zum IBM habe ich auf die Schnelle kein Datenblatt> gefunden.>> Meiner Meinung nach müßten die alle funktionieren. Es sind aber alles> 1Mx4 Steine, und die haben leider eine andere Pinbelegung als die 4Mx4.> Damit passen Sie leider nicht auf die neue Leiterplatte von Joe. Aber Du> wolltest ja lochrastern...
Letzteres ist soweit richtig. Aber, wie Du schon bemerkt hast, die
Pinbelegung passt nicht zu den ICs, wie sie in der 4, bzw. 8, Bit
Version genutzt werden. ausserdem gehen die Leiterbahnen über einen
kleineren IC. Ob dieser was mit der Ansteuerung zu tun hat, kann ich Dir
leider nicht sagen...
Und, ich wollte eigendlich nicht zuviel in SMD arbeiten. Mir fehlt darin
die Praxis (kann man aber ändern), sowie evtl. benötigtes spezielleres
Werkzeug (Lötstation gehobener Art). Letzteres wollte ich mir nicht
kaufen, da ich doch zu selten etwas löte.
---
Kann mir jemand ein Ram IC empfehlen, den man nicht umbedingt mit
spezielleren Werkzeug beikommen muss? Ich gebe ungern 100€ & mehr aus,
nur um 1x einen SMD IC mit x beinchen zu Löten, bzw. ein Pizza Ofen zum
SMD Reflow Ofen umbauen zu müssen.
---
Habt Ihr evtl. einmal versucht, dieses Projekt mit einem anderem µC zu
entwickeln?
Hallo zusammen,
Ein Dank erstmal an Joe für diesen Bausatz.
Habe meine Platine erst jetzt aufbauen können und ein Problem,
Ich bekomme folgende Meldung
CPM on an AVR, v1.0
Testing RAM: fill...wait...reread...
Initing mmc...
mmcInit
mmcCMD: 00 00000000 .. 95 CMDRes: 01
mmcCMD: 08 000001AA .. 87 CMDRes: 05
mmcCMD: 37 00000000 .. 01 CMDRes: 01 mmcCMD: 29 00000000 .. 01 CMDRes:
01
mmcCMD: 37 00000000 .. 01 CMDRes: 01 mmcCMD: 29 00000000 .. 01 CMDRes:
00
mmcCMD: 10 00000200 .. 01 CMDRes: 00
CT: 02 InitRes: 00
mmcCMD: 11 00000000 .. 01 CMDRes: 00 No bootable CP/M disk found! Please
change MMC/SD-Card.
Folgendes habe ich schon unternommen:
-Alle Verbindungen zum RAM (GM71C17403CJ6) durchgemessen.
-Mehrere Versuche die SD-Karte bootfähig zu machen.
letzte Versuch mit dd if=cpm.bin of=\\.\g:
Bin mir auch nicht so sicher ob das so richtig ist ???
Eine genaue Beschreibung könnte mir schon helfen.
desweiteren habe ich im Softwarearchiv für die AVR-VGA Karte keine
passende Software gefunden.
Bin Dankbar für alle Tipps.
Gruß Egmont
Egmont schrieb:> Hallo zusammen,> Ein Dank erstmal an Joe für diesen Bausatz.> Habe meine Platine erst jetzt aufbauen können und ein Problem,> Ich bekomme folgende Meldung> mmcCMD: 11 00000000 .. 01 CMDRes: 00 No bootable CP/M disk found! Please> change MMC/SD-Card.
Also das Ram- wird es wohl nicht sein, denke ich. Ich hatte den gleichen
Fehler bei mir. Im Grunde genommen lag es wohl an der SD-Card. Es gibt
einige Cards bei dehnen ist das Timing besonders kritisch. Die Karte die
bei mir nicht wollte war eine 1GB-Platinum Card von Reichelt. Mit einer
anderen Card (1GB Verbatim) tat's dann auf anhieb. Es lohnt sich also
bei diesem Fehler einfach mal eine andere Karte zu testen. Das Problem,
das gewisse Karten nicht richtig laufen, haben hier im Forum auch schon
andere gehabt. Bin über die Suche auf den Tip gekommen, mal ne andere
Card zu testen. ( siehe auch
http://www.mikrocontroller.net/articles/MMC-_und_SD-Karten ).
Grüße
Frank
Ronny Minow schrieb:> Leo C. schrieb:>> Damit passen Sie leider nicht auf die neue Leiterplatte von Joe. Aber Du>> wolltest ja lochrastern...>> Letzteres ist soweit richtig. Aber, wie Du schon bemerkt hast, die> Pinbelegung passt nicht zu den ICs, wie sie in der 4, bzw. 8, Bit> Version genutzt werden.
Ich habe zwar begriffen, daß Du die RAM's nicht löten möchtest, aber
diese Bemerkung verstehe ich nicht. Die Pinbelegung bei den 1Mx4 Chips
ist anders als bei den 256Kx4 und 4Mx4 Chips. Aber die Bezeichnungen und
die Funktionen der Anschlüsse sind bei allen (bis auf die Anzahl der
Adressleitungen) gleich. Auf Lochraster spielt es doch keine Rolle, ob
man z.B. RAS auf Pin 4 oder Pin 5 löten muß.
> ausserdem gehen die Leiterbahnen über einen> kleineren IC. Ob dieser was mit der Ansteuerung zu tun hat, kann ich Dir> leider nicht sagen...
Dazu hatte ich schon geschrieben, daß es sich hier um Widerstände
handelt, die man auch weglassen kann.
> Und, ich wollte eigendlich nicht zuviel in SMD arbeiten. Mir fehlt darin> die Praxis (kann man aber ändern), sowie evtl. benötigtes spezielleres> Werkzeug (Lötstation gehobener Art). Letzteres wollte ich mir nicht> kaufen, da ich doch zu selten etwas löte.
Gehobene Art ist nicht nötig. Bei mir tuts seit ca. 30 Jahren ein Weller
Magnastat.
Ronny Minow schrieb:> Leo C. schrieb:>> Wenn ich's recht überblicke, sind die ersten 3 "Fast Page Mode" RAM's,>> also keine EDO's. Zum IBM habe ich auf die Schnelle kein Datenblatt>> gefunden.>>>> Meiner Meinung nach müßten die alle funktionieren. Es sind aber alles>> 1Mx4 Steine, und die haben leider eine andere Pinbelegung als die 4Mx4.>> Damit passen Sie leider nicht auf die neue Leiterplatte von Joe. Aber Du>> wolltest ja lochrastern...>> Letzteres ist soweit richtig. Aber, wie Du schon bemerkt hast, die> Pinbelegung passt nicht zu den ICs, wie sie in der 4, bzw. 8, Bit> Version genutzt werden. ausserdem gehen die Leiterbahnen über einen> kleineren IC. Ob dieser was mit der Ansteuerung zu tun hat, kann ich Dir> leider nicht sagen...>> Und, ich wollte eigendlich nicht zuviel in SMD arbeiten. Mir fehlt darin> die Praxis (kann man aber ändern), sowie evtl. benötigtes spezielleres> Werkzeug (Lötstation gehobener Art). Letzteres wollte ich mir nicht> kaufen, da ich doch zu selten etwas löte.>> --->> Kann mir jemand ein Ram IC empfehlen, den man nicht umbedingt mit> spezielleren Werkzeug beikommen muss? Ich gebe ungern 100€ & mehr aus,> nur um 1x einen SMD IC mit x beinchen zu Löten, bzw. ein Pizza Ofen zum> SMD Reflow Ofen umbauen zu müssen.>> ---
Halloe.
Also meine Card habe ich mit zwei RAM's folgenden Typs bestückt.
SIEMENS HYB5117400BJ-50 (4M x 4-Bit Dynamic RAM)
Und mal ganz erlich, mit diesen RAM's hatte ich beim Auflöten den
meisten Ärger. Alle anderen Chips ließen sich dank der Lötstopmaske
recht leicht festlöten. Ich habe es nach der Anleitung von Thomas
Pfeifer http://thomaspfeifer.net/smd_loeten_tsop.htm gemacht. Das ganze
klinkt zwar sehr Brutal, funktionierte bei mir jedoch auf anhieb. Zur
vorsicht habe ich nach dem Löten alle Pins nur einmal mit der Lupe
untersucht, ob evtl. noch Lötbrücken über waren.
Bei den Ram- Chips hingegen funktioniert diese simple Lösung leider
nicht. Habe hier zu erst versucht einfach alle Pins nacheinander
anzulöten, gerad so wie mans bei den DIL- Chips halt auch machen würde.
Habe micht totgeärgert weil ich immer wieder Pins hatte, die ein kleines
Stück über dem PCB "schwebten" und sich absolut nicht festbrutzeln
lassen wollten. Am Ende wär ich so verärgert, das ich einfach alles
nochmal ab gemacht habe. Dann habe ich alle Pad's mit ganz wenig Lötzin
versehen und das RAM-IC vorsichtig oben drauf gelegt. Danach habe ich
einfach meinen Heizluftföhn ausm Baumarkt genommen und das IC damit
nochmal richtig heiss gemacht. Der Effekt war super. Das IC ist durch
das Flussmittel und das Lötzinn richtig gut auf den PAD's verweilt und
ist sogar noch von selbst in die richtige Endposition gewandern. Am Ende
war dann von beiden IC's nur noch ein einziges Pad über das nicht
verbunden war. Das hab ich dann noch von "Hand" angelötet. Am meisten
Angst hatte ich das der Baumarktföhn evtl. mit IC und Board kurzen
prozess macht. ( Der wird ziemlich Heiss ). Habe das Föhnen daher ganz
ganz Vorsichtig gemacht...
Hab wohl glück gehabt den nun läufts.
Und zu der Frage mit dem kleinen IC, das unter dem SD-Card sockelt
sitzt. Das ist der Pegelwandler für die SD-CARD. Der wird gebraucht,
wenn man den AVR mit 5 Volt betreiben möchte. Den die SD-Cards vertragen
nur 3 Volt. Die Ram- Chips laufen nicht darüber, die Leitungen gehen
daran vorbei.
Grüße
Frank
Leo C. schrieb:> Hans- w. Schütz schrieb:>>> 01<38@0139M: fill...wait...reread...F0<00@0000>> nach einem Reset:>>> CPM on an AVR, v1.0>> Fô<83@0083M: fill...wait...reread...F0<00@0000>
nach dem Reset laufen die Zeichen am Anfang einfach durch, Ausgabe ist
willkürlich!
> An der Ausgabeformatierung muß ich wohl noch etwas feilen.
Was soll denn da kommen?
> Verdrahtungsfehler oder defektes RAM im oberen Nibble?> Ach nein, das untere Nibble hat ja auch Fehler.> Wird dieses "o mit Dach" während des Ramtests ausgegeben, oder kommt das> durch den Reset zustande?>> Ansonsten:> Prozessor?
ATMega 168
> Taktfrequenz?
20 MHz
> RAM-Typ?
Nanya NT511740b5J-60
wenn man eine Weile wartet will er von der SD booten, was aber bisher
nicht richtig funktioniert? Wie andere auch das Problem mit den
Speicherkarten, hab jetzt 6 verschiedene durch.. eine bootet anscheinend
richtig, allerdings sind keine Dateien vorhanden??!!
Bisher etwas unbefriedigend...na mal sehen.
Gruß
Hans- Werner
Leo C. schrieb:> Frank Zoll schrieb:>> - Die Performance wird gegenüber den direkten CP/M Partionen stark>> leiden. Bei jedem Sektorzugriff muss dieser erst umständlich in der>> jeweiligen Image-Datei gesucht werden. ( Juhu Retro like nix schnelle>> :-) )>> Ich glaube, so schlimm wirds garnicht. Die SD-Zugriffe sind im Vergleich> zum Interpreter und zu den RAM-Zugriffen nämlich sauschnell. Die> RAM-Disk ist auch eher langsamer als die SD-Disk(s).
Das Blöde ma FAT Dateisystem ist, das ich mich bei jedem Sectorzugriff
erst die verlinkte Liste der Cluster in der FAT- Tabelle entlanghangeln
muss, um raus zu bekommen in welchem Sektor der gesuchte Dateisektor
wirklich steht. Je weiter hinten in der Datei dieser Sektor steht, desto
langsamer wird die Routine arbeiten. Ich nutzte praktisch kaum Puffer,
so das ich da jedes mal vom anfang der Datei an alles lesen muss.
>> FAT16 System. Ich werde mit den derzeit noch verbliebenen knapp 100>> Bytes SRAM eines 168AVR's wohl hinkommen. ( Ein paar Bytes werde ich>> noch überlassen :-) )>> Und wenns doch nicht reicht, kann man die UART RX/TX-Buffer noch> verkleinern. Gut wäre natürlich, wenn man einen 2. Sektorpuffer hätte.> Das würde mit dem ATmega328 gehen.
Ich müsste schon einen ziemlich großen Block speicher reservieren, um
mir eine Tabelle aller Cluster aufzubauen aus denen die jeweilige
Image-Datei besteht. Da komme ich mit ein paar mehr Bytes einfach nicht
aus. Evtl. könnte man ja später mal drüber nachdenken diese Liste ein
einem Teil des DRAM's zu lagern. Im moment wäre ich aber auch schon
froh, wenns überhaupt läuft.
Einen 2. Sektorpuffer brauche ich erstmal nicht denke ich.
Ach ja, zu eurem Leidwesen habe ich hier mal eben riesen Parts des
Quellcodes umgeschaufelt und neu zusammen gestrickt. Ich habe die Datei
"remainders.asm" ziemlich leer gemacht. Da ist kaum was über geblieben.
Bei mir siehts nun so aus:
virt_ports.asm Hier sind die virtuellen Ports und die hilfsroutinen für
den UART- Zugriff über Ports.
dsk_fsys.asm Hier liegen die Grundroutinen des virtuellen Dateisystems
dsk_cpm.asm Hier liegen die Routinen für den Zugriff auf CP/M
Partitionen
dsk_fat.asm Hier liegen die Routinen für den Zugriff aus FAT16
Partitionen
dsk_ram.asm Hier liegen die Routinen für den Zugriff auf Ramdisk
Partitionen
dsk_mgr.asm Hier liegen die Routinen für die
Partitionstabellenverwaltung
Um das ganze nett aussehen zu lassen habe ich die Tabelle hostparttbl um
ein Byte erweitert. Jeder Eintrag dort wird nun angeführt von einem
Byte, das den Typ der jeweiligen Partition wiederspiegelt.
(0=None,1=CP/M,2=Fat,3=RAM). Im moment baue ich gerade alle Routinen so
um, das sie dieses Byte erkennen können und dann jeweils die für die
Partition richtigen lese/schreib routinen aufrufen.
Im moment läuft nix mehr, aber ich hoffe ich bekomme das noch wieder ans
laufen :-)
Grüße
Frank
Frank Zoll schrieb:> Egmont schrieb:>> Hallo zusammen,>> Ein Dank erstmal an Joe für diesen Bausatz.>> Habe meine Platine erst jetzt aufbauen können und ein Problem,>> Ich bekomme folgende Meldung>> mmcCMD: 11 00000000 .. 01 CMDRes: 00 No bootable CP/M disk found! Please>> change MMC/SD-Card.
Egmont, es kann gut sein daß Frank Recht hat. Es kann aber auch sein,
daß überhaupt keine CP/M-Partition auf Deiner Karte ist.
Kannst Du nochmal einen Versuch mit "MMC_DEBUG = 3" machen?
Vorzugsweise mit der neuesten Programmversion von meinem SVN-Server:
http://cloudbase.homelinux.net/viewvc/avr-cpm/branches/modules/
Da sind geringfügig erweiterte Debugmeldungen drin. Es geht aber auch
mit Deiner jetzigen Version.
> Also das Ram- wird es wohl nicht sein, denke ich. Ich hatte den gleichen> Fehler bei mir. Im Grunde genommen lag es wohl an der SD-Card. Es gibt> einige Cards bei dehnen ist das Timing besonders kritisch. Die Karte die> bei mir nicht wollte war eine 1GB-Platinum Card von Reichelt. Mit einer> anderen Card (1GB Verbatim) tat's dann auf anhieb. Es lohnt sich also> bei diesem Fehler einfach mal eine andere Karte zu testen. Das Problem,> das gewisse Karten nicht richtig laufen, haben hier im Forum auch schon> andere gehabt. Bin über die Suche auf den Tip gekommen, mal ne andere> Card zu testen. ( siehe auch> http://www.mikrocontroller.net/articles/MMC-_und_SD-Karten ).
Frank, Deine Platinum-Karte verhielt sich wirklich merkwürdig. Das
sollte man weiter untersuchen.
hschuetz schrieb:> Leo C. schrieb:>> Hans- w. Schütz schrieb:>>>>> 01<38@0139M: fill...wait...reread...F0<00@0000>>> nach einem Reset:>>>>> CPM on an AVR, v1.0>>> Fô<83@0083M: fill...wait...reread...F0<00@0000>>> nach dem Reset laufen die Zeichen am Anfang einfach durch, Ausgabe ist> willkürlich!>> An der Ausgabeformatierung muß ich wohl noch etwas feilen.> Was soll denn da kommen?
Das gleiche, aber nicht so viel übereinander. :)
>> Prozessor?> ATMega 168>> Taktfrequenz?> 20 MHz>> RAM-Typ?> Nanya NT511740b5J-60
Vom Timing her dürfte es keine Probleme geben. Du bist aber der Erste,
der hier mit EDO-RAM's aufschlägt. Ich bin (noch) der Meinung, daß die
auch funktionieren müßten. Aber ich werde mir das Datenblatt jetzt mal
genauer anschauen.
> wenn man eine Weile wartet will er von der SD booten, was aber bisher> nicht richtig funktioniert? Wie andere auch das Problem mit den> Speicherkarten, hab jetzt 6 verschiedene durch.. eine bootet anscheinend> richtig, allerdings sind keine Dateien vorhanden??!!
Bevor die RAM-Fehler nicht weg sind, brauchst Du mit SD-Karten gar nicht
anfangen.
> Bisher etwas unbefriedigend...na mal sehen.
Shit happens...
Frank Zoll schrieb:> Ach ja, zu eurem Leidwesen habe ich hier mal eben riesen Parts des> Quellcodes umgeschaufelt und neu zusammen gestrickt. Ich habe die Datei> "remainders.asm" ziemlich leer gemacht. Da ist kaum was über geblieben.
So war das mit mit der Datei auch gedacht. Da war alles drin, für das
ich noch keinen neuen Platz gefunden hatte.
>> Bei mir siehts nun so aus:>> virt_ports.asm Hier sind die virtuellen Ports und die hilfsroutinen für> den UART- Zugriff über Ports.> dsk_fsys.asm Hier liegen die Grundroutinen des virtuellen Dateisystems> dsk_cpm.asm Hier liegen die Routinen für den Zugriff auf CP/M> Partitionen> dsk_fat.asm Hier liegen die Routinen für den Zugriff aus FAT16> Partitionen> dsk_ram.asm Hier liegen die Routinen für den Zugriff auf Ramdisk> Partitionen> dsk_mgr.asm Hier liegen die Routinen für die> Partitionstabellenverwaltung
Sieht gut aus.
Man könnte sich überlegen den Assembler auf GNU avr-as umzustellen,
damit man aus den Dateien getrennte Übersetzungseinheiten machen kann.
> Um das ganze nett aussehen zu lassen habe ich die Tabelle hostparttbl um> ein Byte erweitert. Jeder Eintrag dort wird nun angeführt von einem> Byte, das den Typ der jeweiligen Partition wiederspiegelt.> (0=None,1=CP/M,2=Fat,3=RAM). Im moment baue ich gerade alle Routinen so> um, das sie dieses Byte erkennen können und dann jeweils die für die> Partition richtigen lese/schreib routinen aufrufen.> Im moment läuft nix mehr, aber ich hoffe ich bekomme das noch wieder ans> laufen :-)
Ich werde den jetzigen Stand mal einfrieren und eine Version draus
machen.
Hat jemand einen Vorschlag für eine Versionsnummer? :)
Deine Änderungen werden dann die nächste Version.
Frank Zoll schrieb:> Es gibt> einige Cards bei dehnen ist das Timing besonders kritisch. Die Karte die> bei mir nicht wollte war eine 1GB-Platinum Card von Reichelt.
Würde es Dir sehr viel Mühe bereiten, die Platinum-Karte nochmal mit
Softwarerevision 91 zu testen?
Die kannst Du z.B. über folgenden Link bekommen:
http://cloudbase.homelinux.net/viewvc/avr-cpm/branches/modules/avrcpm/avr/?view=tar&pathrev=91> http://www.mikrocontroller.net/articles/MMC-_und_SD-Karten ).
Zitat: "Die MMC-Implementierung für AVR von Elm Chan z. B. funktioniert
mit SanDisk problemlos hat aber mit Platinum Karten ein Problem."
Die aktuellen MMC-Routinen sind im wesentlichen die von Chan, nur in
Assembler. Die älteren von Sprite_tm sind bis Rev. 91 noch drin und
teilweise anders.
@all: Mit Platinum Karten (auch CF - Amiga) habe ich keine guten
Erfahrungen gemacht.. kaufe ich seitdem nicht mehr..
@Leo C. Vorschlag für Versionsnummer.. eigendlich hätte es schon einige
geben müssen.. ;-) Ich nehme immer völlig unortodox das Datum in der
Form:
YYYYMMDD - so weiß man immer gleich was die neueste Version ist und wann
diese zeitlich anzusiedeln ist ;-)
Peter
Hallo,
nun rennt's..... wer lesen kann ist klar im Vorteil....
Hatte bei assemblieren den 4bit Ram teil mit drin...und somit die
Fehler..
allerdings habe ich den SPI Clock auf /4 es laufen jetzt 2 Platinium
1Gb, eine SD 16Mb von Thoshiba und eine MMC 256Mb vom Medion.....
nun muss ich mal sehen wie ich Programme auf die Kartenimages bekomme...
CPM on an AVR, v1.0
Testing RAM: fill...wait...reread...
Initing mmc...
CP/M partition at: 060, size: 6930KB.
CP/M partition at: 13920, size: 8700KB.
CP/M partition at: 31320, size: 7830KB.
CP/M partition at: 46980, size: 7830KB.
Partinit done.
Ok, CPU is live!
ipl
62k cp/m vers 2.2
A>dir
A: ASM COM : DDT COM : DUMP COM : ED COM
A: T COM : LOAD COM : MBASIC COM : PIP COM
A: STAT COM : SUBMIT COM : XSUB COM : ZORK1 COM
A: ZORK1 DAT
A>
Gruß
Hans- Werner
Leo C. schrieb:> Frank Zoll schrieb:>> Es gibt>> einige Cards bei dehnen ist das Timing besonders kritisch. Die Karte die>> bei mir nicht wollte war eine 1GB-Platinum Card von Reichelt.>> Würde es Dir sehr viel Mühe bereiten, die Platinum-Karte nochmal mit> Softwarerevision 91 zu testen?
Ich habe mir heut morgen mal schnell die neuere Version gezogen und es
ausprobiert. Habs aber auf Anhieb nicht gleich ans laufen bekommen und
musste recht schnell aufgeben. Er hat einmal ganz kurz die Platinum Disk
erkannt, sich dann aber irgendwie aufgehängt. Nach dem Aufhängen kahm
keine Verbidung mehr zum Terminal zustande. Erst nachdem ich wieder
meine eigene Entwicklung aufgespielt habe, hat sich der Rechner wieder
gemeldet.
Wie ich sehe scheint es nicht unbedingt nur an der Marke "Platinum" zu
liegen. Zwei 1GB- Karten scheinen bei Hans Werner ja zu laufen. Ich
denke einfach mal, das meine SD-Card bereits eine macke hat. Wer ganz
oben mitgelesen hat, wird ja schon sehen das die Karte auch unter
SUSE-11.2 nicht ans laufen zu bringen war. Immer wenn ein HighSpeed
zugriff statt fand, brach die Verbindugn zur Karte ab. Ich hab die Karte
mitlerweile mal versucht mit meinen HIVE ans laufen zu bekommen. Auf dem
HIVE ziegt sich da ein ähnlicher Fehler. Die Karte wird nur ab und zu
mal erkannt.
Ich denke einfach mal das die Karte bereits einen kleinen Schaden weg
hat. Aber seltsam ist's schon das sie unter Window noch ansprechbar ist.
Freundliche Grüße
Frank
Hallo,
ich habe alles mit den SD Karten mit einem Debian System gemacht,
anscheinend ist aber das AVR Programm entscheidend.
Die 1Gb Karten sind auch ein bisschen ziggig... wenn man die Karten
unter Spannung zieht!!! das hat teilweise die komplette Zerstörung der
Daten zur Folge!!
Gruß
Hans- Werner
Egmont schrieb:> CT: 02 InitRes: 00 SPI_DISABLE
Die Karte wurde ohne Fehler initialisiert.
> mmcRdSect SPI_CLK_FAST> mmcCMD: 11 00000000 <FF <FF <FF >51 .. 01>01 <FF <00 CMDRes: 00 <FF <FF> <FE <00 <08 <FF SPI_DISABLE RdSectRes: 00
Sektor 0 der Karte (Partitionstabelle) wurde ohne Fehler gelesen.
> No bootable CP/M disk found!
Auf der Karte ist keine CP/M-Partition (Type 52), und am Anfang der
Karte ist kein CP/M-Diskimage.
> Ist es möglich deine(oder von Joe) CP/M-System-Datei zur verfügung zu> stellen, sodass ich die mit DD.exe auf meine SD-Karte übertrage kann> (Laufwerk A:).
Ich habe mal ein Diskimage hier angehängt. Das kannst Du mit dd auf eine
SD-Karte kopieren. Entweder direkt an den Anfang einer Karte (der alte
Inhalt der Karte geht dabei komplett verloren), oder in eine primäre
Partition. Die Partition muß Typ 52 haben. Wie das unter Windows geht,
weiß ich nicht.
Hallo Hans-Werner,
herzlichen Glückwunsch zu Deinem neuen funktionierenden CP/M-System.
hschuetz schrieb:> Die 1Gb Karten sind auch ein bisschen ziggig... wenn man die Karten> unter Spannung zieht!!! das hat teilweise die komplette Zerstörung der> Daten zur Folge!!
Das ist mir noch nie passiert. Ich ziehe die Karten an manchen Tagen 20
mal oder noch öfter. Hauptsächlich teste ich mit einer 2G Intenso. Die
Karte fällt jetzt zum 2. Mal auseinander. Ich hatte sie schon mal mit
Sekundenkleber zusammengeklebt und mit 2-Komponentenkleber in Form
gebracht (Schreibschutzschieber war abgefallen). Ich habe aber auch noch
2 verschiedene 1G Karten und eine 2G Mikro-SD-Karte im Test.
Halloe.
Mal ein kurzer Status der FAT16 implementierung. Ich kämpfe mich gerade
durch die Strukturen von Bootblock, FAT und Direktory. Habe schon die
korrekten Positionen von Bootblock, FAT, und Root- Direktory auf meiner
Testpartition gefunden. Morgen schaue ich dann mal, das ich das Root-
Verzeichniss nach den Image-Dateien durchsuche.
Hans- w. Schütz schrieb:> hat sich schon jemand mit dem kleineren Teil der Platine befasst??> Ja das VGA Terminal...
Um erlich zu sein, bisher nicht. Mir fehlen dummerweise noch die 3 470
Ohm 1206er SMD Widerstände vor der VGA- Buchse. So konnte ich den Teil
der Platine leider noch nicht fertig stellen. Naja und nur für die 3
Widerstände ne Bestellung aufgeben, das wiederstrebte mir. Hab gerad nix
anderes, das ich noch mitbestellen könnte.
Grüße
Frank
Moin Frank,
wenn Du mir Deine Adresse mailst, pack ich die in 'nen
Briefumschlag.
Softwaretechnisch kann ich eh nicht unterstützen, komme
mehr von der Hardware und da auch nicht unbedingt von
den Mikrocontrollern.
Gruss
Peter
Nun läßt sich der Dateianfang bereits erfolgreich lokalisieren. Als
nächstes muss ich noch eine Methode bauen, die sich Cluster für Cluster
zu einem beliebigen "Zielsektor" vorarbeiten kann. Dann kann ich das
Laden und Speichern der Sektoren so anpassen, das Sektoren aus dem Image
gelesen und geschreiben werden können. Vorher muss ich nur noch klären,
wieso da oben 256258 Bytes steht und nicht 256256. Denn die Datei ist
genau 256256 Bytes groß, irgenwie haben sie da 2 zusatzbytes
eingeschlichen :-) Die Zahl 005 gibt die Nummer des ersten Clusters der
Datei an. Diese Zahl speichere ich nun zusammen mit dem Partitionstyp in
der internen Partitionstabelle. Damit lassen sich später sowohl der
Dateianfang als auch der erste Cluster in der FAT schnell wiederfinden.
Grüße
Frank
@all: Mann! Schön, das sich hier so viel tut!! Wer hätte das mal
gedacht.. das sich aus dem 'Proof of concept' mal ein (fast)
vollwärtiges CP/M System
entwickelt...
Ich bin zur Zeit mit CC 2010 (Verein zum Erhalt klassischer Computer)
Messe/Treffen-Vorbereitungen etwas arg ausgelastet und komme daher zur
Zeit zu fast nicht anderem mehr.. aber der nächste 'Winter' kommt
bestimmt.. ;-)
Weiter so!
Peter
@alle: Ich bin beeindruckt was hier so alles passiert, wenn man eine
Woche nicht im Lande ist... Wichtig für noch alle weiteren potentiellen
Nachbauer und natürlich auch für die aktuelle Dokumentation, wäre die
Information ob Layout und Schaltung fehlerfrei sind (PWREN# habe ich
schon). Da einige „neue“ Systeme schon arbeiten, gehe ich mal davon aus
oder irre ich?
Gruß Joe
Joe G. schrieb:> @alle: Ich bin beeindruckt was hier so alles passiert, wenn man eine> Woche nicht im Lande ist... Wichtig für noch alle weiteren potentiellen> Nachbauer und natürlich auch für die aktuelle Dokumentation, wäre die> Information ob Layout und Schaltung fehlerfrei sind (PWREN# habe ich> schon). Da einige „neue“ Systeme schon arbeiten, gehe ich mal davon aus> oder irre ich?> Gruß Joe
Hallo Joe,
beim Layout von der VGA-Karte kann ich nur sagen das die drei
Widerstände 470 ohm an der Sub-D Buche sehr Dicht anliegen,
Meine Buchse ist komplett mit Kunststoff umgeben (habe da was
weggefräst) und somit gab es da keine Probleme.
Wo ist den für die Mini-VGA die Software abgelegt ??
Gruß Egmont
Egmont schrieb:> die drei> Widerstände 470 ohm an der Sub-D Buche sehr Dicht anliegen
Vielen Dank für den Hinweis!
Für die VGA gibt es noch keinen Code außer das Original, siehe hier:
Beitrag "AVR VGA Terminal"
@Joe,Feinmechaniker
pin 8 sollte doch an Masse liegen?? oder? Bei beiden AVR's liegen die
Anschlüsse in der Luft! Allerdings auch im Schaltplan!! Der Quarz hängt
auch in der Luft.
Gruß Hans- Werner
Hans- w. Schütz schrieb:> pin 8 sollte doch an Masse liegen??> Der Quarz hängt auch in der Luft.
DANKE!
Ja, sicher... dumme Sache mit Pin 8!
Beim Quarz ist es so gewollt. Die Jumperkonfiguration bot aus
Platzmangel keine andere Mögtlichkeit. Wird ein Quarz verwendet, so muß
eine kleine Brücke zwischen Quarz und Pin 9 gelegt werden.
Also für alle:
- Pin 8 (beide AVR) auf Masse legen.
- Quarzbestückung bei IC1 - Pin 9 des AVR mit dem Quarz verbinden (siehe
Schaltung)
Joe
Hallo,
hat denn einer schon etwas mit der VGA hinbekommen?
Irgendwie bin ich zu "dusselig" die Original Sourcen zu compilieren,
immer massenhaft Fehlermeldungen?!!
Gruß
Hans- Werner
Frank Zoll schrieb:> Halloe.>> Wieder ein kleines Stück voran gekommen.CP/M partition at: 1757875, size:
9728KB.
> CP/M partition at: 1777406, size: 9728KB.> CP/M partition at: 1796937, size: 73344KB.> FAT16 File-Image at: 005, size: 256258Bytes.> Partinit done.> Ok, CPU is live!
@Frank,
was macht deine Software mit FAT16...
@ALLE
habe immer noch nicht das Problem gelöst das ich auf meine SD-Karte ein
Bootprojekt finde.
Leo C. schrieb:> Auf der Karte ist keine CP/M-Partition (Type 52), und am Anfang der> Karte ist kein CP/M-Diskimage.
Habe mit ein Hexeditor mal auf meine SD-Karte geschaut und die Daten von
diskimage dort gefunden, dirkt am Anfang der Karte (vermute mal das das
so richtig ist). Nur was ist mit Type 52 gemeint ????
habe mit "DD if=diskimage of=\\.\f:" die Datei auf SD kopiert, benötige
ich noch Parameter die eine Partion vom Type 52 anlegt ??
Gruß Egmont
Egmont schrieb:> Habe mit ein Hexeditor mal auf meine SD-Karte geschaut und die Daten von> diskimage dort gefunden, dirkt am Anfang der Karte (vermute mal das das> so richtig ist). Nur was ist mit Type 52 gemeint ????
Hier ist die Partitionstabelle erklärt:
http://de.wikipedia.org/wiki/Partitionstabelle
Die Partitionstabelle liegt zusammen mit dem Bootloader im ersten Sektor
einer Festplatte, bzw. Speicherkarte (MBR).
Man kann (jedenfalls beim avrcpm-Computer) die Partitionstabelle, bzw.
den MBR aber auch weglassen. Dann beginnen die Nutzdaten im ersten
Sektor. Und natürlich hat man dann auch nur ein CP/M-Diskimage, und der
Rest der Karte ist nicht nutzbar.
> habe mit "DD if=diskimage of=\\.\f:" die Datei auf SD kopiert, benötige> ich noch Parameter die eine Partion vom Type 52 anlegt ??
Ich kenne mich mit dem Windows-DD nicht genug aus, um sagen zu können,
ob "\\.\f:" in einer Partition liegt, oder am Anfang der Karte.
Leo C. schrieb:>> habe mit "DD if=diskimage of=\\.\f:" die Datei auf SD kopiert, benötige>> ich noch Parameter die eine Partion vom Type 52 anlegt ??>> Ich kenne mich mit dem Windows-DD nicht genug aus, um sagen zu können,> ob "\\.\f:" in einer Partition liegt, oder am Anfang der Karte.
Damit liegt das Image am Anfang der Karte.. daher ist es keine Partition
und damit ist Part.Typ 52 auch irrelevant..
Ist denn der Artikel an dieser Stelle noch zu unverständlich..?:
[quote]
Das so erzeugete diskimage wird ROH (ohne Filesystem) mit:
dd if=diskimage of=<sd card identifier> bs=512
auf eine SD Karte geschrieben. Achtung! Alle anderen Dateien gehen dabei
verloren!
Die aktuelle Version unterstützt ebenfalls bis zu 4 primäre CP/M = Typ
52 Partitionen. Diese lassen sich mit einer Linux Live-CD und dem Tool
'cfdisk' anlegen. Da z.Z die virtuellen Disketten nur ca. 250kb 'groß'
sind, reicht es entsprechend große Partitionen azulegen (Ich habe
trotzdem 8MB große angelegt.. für später). Wichtig dabei ist es den Typ
auf 52 = CP/M zu setzen.. und schreiben/speichern nicht vergessen. Die
einzelnen Partitionen werden dann ohne zu formattieren wieder mittels
'dd if=diskimage of=[sd card partition] bs=512' gefüllt. Wird also die
SD Karte unter Linux z.B als sdh angezeigt, so ist die erste Partition
dann sdh1, die zweite sdh2 etc. of= ist dann also /dev/sdh1 /2 /3..
Ich habe übrigens die erste Partition als FAT eingerichtet und
entsprechend formattiert. So kann man den großen Bereich weiter unter
Windows nutzen. Und dann nur 3 CP/M Partitionen am Ende des
Speicherbereiches angelegt..
[/quote]
Peter
Leo C. schrieb:> Vor kurzem bin ich zufällig über ein CP/M-Plugin für den "Total> Commander" gestolpert:> http://hc-ddr.hucki.net/wiki/doku.php/cpm:disketten_xp2>> Vielleicht ist das ja für den einen oder anderen Windowsbenutzer> interessant.
Das habe ich vor Monaten schon mal getestet. Der Treiber greift direkt
auf den Floppycontroller zu, also leider für uns in dieser Form
ungeeignet :-(
Gerade gingen endlich die FT232 bei mir ein. Ich habe euch kleine
Briefchen gesendet....
Joe
Soo.. bin gerade dabei mich mit einem LR Aufbau einer 8-bit Variante zu
beschäftigen.. Dazu ein paar Fragen:
1. Ich kann den 2ten Dram Chip Huckepack 1:1 auf den Ersten Chip löten -
außer D0 - D3 (die 4 Datenbits)! Stimmt das so, oder sind noch
irgendwelche anderen Pin's, die getrennt zu verbinden sind..?
2. Ich könnte doch auch 256k x 4 Drams nehmen.. für die 8-bit
Variante..?
Klar ist es dann nicht 4MB, sondern nur 256k.. ;-) Vorteil für mich
wäre, DIL Fassung!
Die Verdrahtung würde ich dann nach config.inc - 8-bit Teil vornehmen:
1
#if DRAM_8BIT /* Implies software uart */
2
3
;Port D
4
.equ RAM_D0 = 0
5
.equ RAM_D1 = 1
6
.equ RAM_D2 = 2
7
.equ RAM_D3 = 3
8
.equ RAM_D4 = 4
9
.equ RAM_D5 = 5
10
.equ RAM_D6 = 6
11
.equ RAM_D7 = 7
12
.equ RAM_A0 = 0
13
.equ RAM_A1 = 1
14
.equ RAM_A2 = 2
15
.equ RAM_A3 = 3
16
.equ RAM_A4 = 4
17
.equ RAM_A5 = 5
18
.equ RAM_A6 = 6
19
.equ RAM_A7 = 7
20
21
;Port B
22
.equ RXD = 0
23
.equ TXD = 1
24
.equ MMC_CS = 2
25
.equ MMC_MOSI = 3
26
.equ MMC_MISO = 4
27
.equ MMC_SCK = 5
28
.equ RAM_A8 = 3
29
.equ RAM_A9 = 4
30
.equ RAM_A10 = 5
31
32
;Port C
33
.equ RAM_RAS = 0
34
.equ RAM_CAS = 1
35
.equ RAM_OE = 2
36
.equ RAM_W = 3
Pinouts von 256kx4 und 4Mx4 hänge ich hier mal an..
BTW: Ich will nur eine 3.3V Versorgung für das ganze System machen.
Und serielle Anbindung über TTL.
Passt das so.. oder habe ich irgendwas vergessen..?
Peter
Egmont schrieb:> Frank Zoll schrieb:>> Halloe.>> CP/M partition at: 1777406, size: 9728KB.>> FAT16 File-Image at: 005, size: 256258Bytes.>> @Frank,> was macht deine Software mit FAT16...
Och das ist eigentlich ganz einfach zu erklären. Ich hab mich einfach zu
dolle über Linux geärgert, weil ich immer wieder Probleme mit der
Hardwareerkennung hatte. Daher suchte ich nach einer "einfacheren"
möglichkeit um unter Windows die "Partitionen" für das CP/M Projekt
anzulegen.
Meine Aktuelle Lösung sieht so aus:
- Ich suche die 1. FAT16 Partition die ich auf der SD-Card finden kann.
- Ich schaue im ROOT- Verzeichniss dieser Partition nach Dateien die
diesem Schema entsprechen "CPMDSK_!.IMG" ( != Ein beliebieger Buchstabe
A-Z )
- Diese Dateien müssen derzeit genau 256KB gross sein. Daher habe ich
ein kleines Programm geschrieben das an die hier im Forum zu findenen
Images einfach Nullen dranhängt, bis 256KB erreicht sind.
- Jede gefundene Datei wird als virtuelle Partition in das CP/M System
eingebunden.
- Für das CP/M sieht der Zugriff über die Ports nacher genauso aus, wie
bei den "echten" CP/M Partitionen.
- Ach ja. Da echte CP/M Partitionen einen schnelleren Zugriff erlauben,
werden diese bevorzugt an den Anfang der Liste der "virtuellen"
Laufwerke gesetzt. Eine Mischung auf CP/M und FAT16 Partitionen ist
somit dann auch möglich.
Mit diesen Lösung spart man sich das Partitionieren der SD- Card unter
Linux und den ständigen wechsel zwischen Windows und Linux zum kopieren
der CP/M Images. Die per CPMTOOLS angelegten Diskettenimages kann man
nach dem "aufpusten" auf 256KB praktisch direkt verwenden.
Ich bin in den letzten Tagen nicht zum Coden gekommen. Aktuell muss ich
"nur noch" die Funktion schreiben, die aus einer CP/M- Sektorangabe
einen Sektor aus der Diskimage- Datei ermittelt. Schreiben und Lesen der
Sektoren werde ich danach wieder über die bereits bestehenden MMC-
Zugriffsrotuinen abwickeln. Ich denke das ich da noch 3-4 Abende rein
stecken muss, bis es endlich richtig läuft. Sobald ich es am laufen habe
werde ich hier mal ein Archiv mit meiner Version posten.
Mit dem zur Verfügung stehenden Speicher werden wir auskommen. Aktuell
liegt der Speicherverbrauch bei meinem Atmega168 Version bei:
Flash 9196 von 16384 genutzt.
SRAM 930 von 1024 genutzt.
EEPROM noch leer.
Grüße
Frank
Es ist aber noch einiges zu tun.
> Zugriffsrotuinen abwickeln. Ich denke das ich da noch 3-4 Abende rein> stecken muss, bis es endlich richtig läuft. Sobald ich es am laufen habe> werde ich hier mal ein Archiv mit meiner Version posten.
Hast Du meine Mail bekommen?
> liegt der Speicherverbrauch bei meinem Atmega168 Version bei:> Flash 9196 von 16384 genutzt.> SRAM 930 von 1024 genutzt.> EEPROM noch leer.
Da wäre noch Platz für einen Monitor. :-)
Peter Sieg schrieb:> Soo.. bin gerade dabei mich mit einem LR Aufbau einer 8-bit Variante zu> beschäftigen.. Dazu ein paar Fragen:>> 1. Ich kann den 2ten Dram Chip Huckepack 1:1 auf den Ersten Chip löten -> außer D0 - D3 (die 4 Datenbits)! Stimmt das so, oder sind noch> irgendwelche anderen Pin's, die getrennt zu verbinden sind..?
Welche sollten das den sein?
Huckepack mit SOJ-Gehäusen geht gut, wenn man beim oberen Chip die Pins
gerade nach unten biegt.
Dazu hatte ich schon mal ein Bild gepostet:
Beitrag "Re: CP/M auf ATmega88"> 2. Ich könnte doch auch 256k x 4 Drams nehmen.. für die 8-bit> Variante..?
Du kannst tun und lassen was Du willst.
> Klar ist es dann nicht 4MB, sondern nur 256k.. ;-) Vorteil für mich> wäre, DIL Fassung!> Die Verdrahtung würde ich dann nach config.inc - 8-bit Teil vornehmen:> [code]> #if DRAM_8BIT /* Implies software uart */
Oder einfach nach dem Schaltplan von Joe.
Joe G. schrieb:> Leo C. schrieb:>> Vor kurzem bin ich zufällig über ein CP/M-Plugin für den "Total>> Commander" gestolpert:>> http://hc-ddr.hucki.net/wiki/doku.php/cpm:disketten_xp2>>>> Vielleicht ist das ja für den einen oder anderen Windowsbenutzer>> interessant.>> Das habe ich vor Monaten schon mal getestet. Der Treiber greift direkt> auf den Floppycontroller zu, also leider für uns in dieser Form> ungeeignet :-(
Nicht daß es wichtig wäre, aber ich verstehe die Webseite so, daß man
auch direkt auf Floppies zugreifen kann. Aber genauso auch auf
Diskimages.
Das ganze ist ja nur eine graphische Oberfläche zu libdsk und cpmtools,
also zu dem, was wir auf der Kommandozeile eh schon haben.
Zitat: "Mein Plugin arbeitet mit CP/M-Disketten und Diskettenimages,
die von libdsk unterstützt werden, also Teledisk, CopyQM, MyZ80, DSK,
CFI, RAW, …"
Leo C. schrieb:> Du kannst tun und lassen was Du willst.
Danke Leo.. du bist wirklich sehr nett ;-) (Und hast einen besonderen
Humor) Sicher ist dir klar, das ich damit fragen wollte, das es da auch
mit der Firmware klappt.. macht ja keinen Sinn sowas aufzubauen, wenn es
dann nachher mit der Software nicht geht.. ;-)
Und vom Schaltplan.. da wäre es einfacher ohne Bus.. so muß man in Eagle
jede Verbindung anklicken und sehen, was mit was verbunden ist bzw. den
Signalnamen prüfen.. da ist so eine einfache Verbindungsliste für mich
und einen LR Aufbau einfacher..
Und wie ich sehe hast du dich schon an den disk Parametern dran
gesetzt..
Supi!! Dann gibts ja bald Images/Partitionen >243kb ;-)
Peter
Peter Sieg schrieb:> da wäre es einfacher ohne Bus.. so muß man in Eagle> jede Verbindung anklicken und sehen, was mit was verbunden ist bzw. den> Signalnamen prüfen
nö, ich habe jede Busleitung beschriftet. z.B.
D0_A0 | RAM Pin 9
D0_A0 | AVR Pin 2 usw.
Peter Sieg schrieb:> Leo C. schrieb:>> Du kannst tun und lassen was Du willst.>> Danke Leo.. du bist wirklich sehr nett ;-) (Und hast einen besonderen> Humor)
Man tut, was man kann.
> Sicher ist dir klar, das ich damit fragen wollte, das es da auch> mit der Firmware klappt.. macht ja keinen Sinn sowas aufzubauen, wenn es> dann nachher mit der Software nicht geht.. ;-)
Ich habe mich wirklich sehr gewundert, daß diese Frage ausgerechnet von
Dir kommt. Ich könnte mir vorstellen, daß Du die Antwort sogar in Deinen
eigenen Artikeln hier finden könntest.
> Und vom Schaltplan.. da wäre es einfacher ohne Bus.. so muß man in Eagle> jede Verbindung anklicken und sehen, was mit was verbunden ist bzw. den> Signalnamen prüfen.. da ist so eine einfache Verbindungsliste für mich> und einen LR Aufbau einfacher..
Zu dem Teil ist ja gerade eine Antwort von Joe reigekommen.
> Und wie ich sehe hast du dich schon an den disk Parametern dran> gesetzt..> Supi!! Dann gibts ja bald Images/Partitionen >243kb ;-)
Die grundsätzlichen Funktionen sind schon mal vorhanden. Aber ich habe
noch ein kleines Henne-Ei-Problem. Ich brauche Daten aus dem Bios, um
das Bios zu laden...
Übrigens wird man einige bekannte Diskimageformate, zB. MyZ80, (nahezu)
direkt verwenden können: Header abschneiden, neuen Header dranpappen,
fertig.
@Leo C./Joe: Ich bin mir bei der Verdrahtung ja auch zu 99,9% sicher..
ebendso bei der Antwort zu der Frage, ob nur D0-D3 NICHT verbunden
werden.. alle anderen Pin's ja.. bin ich zu 99,89763% sicher.. wäre nur
schön gewesen
einfach mal zu hören: Ja, genau.. oder Jup, so isses.. ;-)
;-)
Peter
Argh.. kann nicht editieren.. sorry..
@Joe: Ja jetzt sehe ich die Beschriftung.. prima.. werde ich dann groß
ausdrucken und für den LR Aufbau nutzen.. Danke!
Peter
Hallo an Alle....
Peter Sieg schrieb:> Die aktuelle Version unterstützt ebenfalls bis zu 4 primäre CP/M = Typ> 52 Partitionen. Diese lassen sich mit einer Linux Live-CD und dem Tool> 'cfdisk' anlegen. .....
Habe mir eine Koppix besorgt und habe es jetzt am laufen
######################################
CPM on an AVR, v32.10
Testing RAM: fill...wait...reread...
Initing mmc...
CP/M partition at: 1895040, size: 8064KB.
CP/M partition at: 1911168, size: 8064KB.
CP/M partition at: 1927296, size: 8064KB.
Partinit done.
Ok, CPU is live!
ipl
62k cp/m vers 2.2
A>
######################################
habe jetzt noch eine Partition die 960MB belegt, noch drauf.. so wie
Peter das geschrieben hat.
Aber Linux ist nicht so mein Ding und wäre Happy wenn das mit FAT16
klappt.
Gruß Egmont
So,
hat leider etwas länger gedauert als gedacht aber hier mal ein kurzes
Update. Ich hab soeben das erste mal lesend auf ein Diskimage auf meiner
FAT16 Partition zugreifen können. Das anzeigen des Directorys und der
Programmstart funktionieren. Das schreiben hab ich vorsichtshalber
erstmal abgestellt, bis ich sicher bin, das die Schreibopüerationen auch
immer schön in die Datei gehen und nicht daneben. :-)
Ich habe Leo eben mal eine kleine Vorabversion zum testen geschickt.
Sobald die letzten Macken beseitigt sind und der neue Code auch schön
aufgeräumt ist, gibts hier ein kleines Release.
1
CP/M partition at: 1757875, size: 9765KB.
2
CP/M partition at: 1777406, size: 9765KB.
3
CP/M partition at: 1796937, size: 73464KB.
4
FAT16 File-Image at: 005, size: 250KB.
5
Partinit done.
6
Ok, CPU is live!
7
8
ipl
9
62k cp/m vers 2.2
10
11
A>d:
12
D>dir
13
D: ASM COM : DDT COM : DUMP COM : ED COM
14
D: T COM : TLOOP COM : LOAD COM : MBASIC COM
15
D: 23 BAS : BAGELS BAS : CHECKERS BAS : STARTREK BAS
16
D: TREKINST BAS : MASTRMND BAS : WEEKDAY BAS : PIP COM
Frank Zoll schrieb:> So,> hat leider etwas länger gedauert als gedacht aber hier mal ein kurzes> Update. Ich hab soeben das erste mal lesend auf ein Diskimage auf meiner> FAT16 Partition zugreifen können. Das anzeigen des Directorys und der> Programmstart funktionieren. Das schreiben hab ich vorsichtshalber> erstmal abgestellt, bis ich sicher bin, das die Schreibopüerationen auch> immer schön in die Datei gehen und nicht daneben. :-)>> Ich habe Leo eben mal eine kleine Vorabversion zum testen geschickt.> Sobald die letzten Macken beseitigt sind und der neue Code auch schön> aufgeräumt ist, gibts hier ein kleines Release.
Zum Ausprobieren ist jetzt alles auf:
http://cloudbase.homelinux.net/viewvc/avr-cpm/trunk/avrcpm/avr/
Oder inzwischen auch besser mit SVN-Client (z.B. Tortoise SVN) auf:
http://cloudbase.homelinux.net/svn/avr-cpm/trunk/avrcpm/avr/
Die Reste aus "remainders.asm" haben jetzt auch ihre eigenen Dateien
bekommen. Außerdem habe ich für Jump und Call Makros gebaut, die je nach
Prozessor und Sprungweite den passenden rjmp/jmp, bzw. rcall/call Befehl
verwenden.
Bei mir assemblieren alle Prozessor-/RAM-Kombinationen mit und ohne
FAT16-Unterstützung (Mega8 und 88 nur ohne FAT16).
Das ist alles nur zum Testen und noch nicht unbedingt stabil. Z.B. passt
das BIOS aus trunk nicht mehr dazu. Bitte das BIOS aus dem stabilen
Zweig nehmen.
Zur Zeit muß die FAT16-Partition den Typ 0E haben. Da wir nur
LBA-Adressierung verwenden, wäre das eigentlich auch richtig. Gängig ist
aber auch Typ 6, der nicht erkannt wird. Sicher könnte man das umstellen
oder Typ 6 zusätzlich einbauen. Es stellt sich nur die Frage, was
sinnvoll ist.
"Meine" Partitionstypenreferenz
(http://www.win.tue.nl/~aeb/partitions/partition_types-1.html) meint
dazu:
1
06 DOS 3.31+ 16-bit FAT (over 32M)
2
Partitions, or at least the FAT16 filesystems created on them, are at
3
most 2 GB for DOS and Windows 95/98 (at most 65536 clusters, each at most
4
32 KB). Windows NT can create up to 4 GB FAT16 filesystems (using 64 KB
5
clusters), but these cause problems for DOS and Windows 95/98. Note that
6
VFAT is 16-bit FAT with long filenames; FAT32 is a different filesystem.
7
8
0e WIN95: DOS 16-bit FAT, LBA-mapped
9
0f WIN95: Extended partition, LBA-mapped
10
Windows 95 uses 0e and 0f as the extended-INT13 equivalents of 06 and
11
05. For the problems this causes, see Possible data loss with LBA and
12
INT13 extensions. (Especially when going back and forth between MSDOS and
13
Windows 95, strange things may happen with a type 0e or 0f partition.)
14
Windows NT does not recognize the four W95 types 0b, 0c, 0e, 0f ( Win95
15
Partition Types Not Recognized by Windows NT). DRDOS 7.03 does not support
16
this type (but DRDOS 7.04 does).
Das Linux/Gnome Partitionierprogramm "gparted" ist übrigens besonders
schlau ;-( Es hat einen Dialog, in dem man "Markierungen/Flags"
einstellen kann. Schaltet man das LBA-Flag ein, wird der Partitionstyp
von 6 auf E umgestellt.
Hallo zusammen,
wollte mal was über den Bootloader schreiben den ich benutze:
Bootloader von Peter Dannegger
http://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger
- Boot_168.hex in ATMega168 laden
- Fusebit auf "BOOTRST" und 512k stellen
- FBoot.exe ins Verzeichniss kopieren wo auch die avrcpm.hex ist.
- FBoot ausführen mit folgenden Parameter
oder Flash.bat
fboot /C2 /B9600 /Pavrcpm.hex
^ ^ ^
| | |
| | +- Hex-File
| +-------- Baudrate
+------------ Comport (1-4)
fboot funktioniert bei mir nur bis Win XP.
Erlaubter Comport von 1 bis 4
Der Bootloader hat eine automatische Baudratenerkennung und man kann
auch höhere Werte eingeben zb 38400
Tipp:
Mit dem FT232RL-Tool (MProg 3.5 Release) eine feste "USB Serial Number"
vergeben, somit bekommt man immer den gleichen ComPort zugewiesen auch
wenn sich der USB-Port ändert.
In der Systemsteuerung / Geräte-Manager den ComPort ändern auf z.B. 2
Gruß Egmont
Joe G. schrieb:> Für welche Taktfrequenz ist der Bootloader übersetzt?
Du fragt bestimmt wegen Baudrate... da ist das so das er sich das selbst
errechnet. Es ist also kein Problem wenn man seine Taktfrequenz ändert.
Bekommt von FBoot.exe Daten geschickt wo dann die Baudlänge ermittelt
wird.
Habe ich schon selber ausprobiert. 12MHz vom FT232 eingestellt
CP-M-Source neu übersetzt mit der Taktfrequenz und mit dem Bootloader
geladen.
In der FastLoad.H steht zwar bei mir 8Mhz drinn wird aber nur dafür
verwendet um ein BootDelay zu errechnen.
.equ XTAL = 8000000 ; 8MHz, not critical
.equ BootDelay = XTAL / 3 ; 0.33s
wichtig sind die Einstellungen in Bootload.asm
.equ STX_PORT = PORTB
.equ STX = PB1
.equ SRX_PORT = PORTB
.equ SRX = PB0
Was man noch beachten sollte:
-SD-Karte entfernen
-FBoot.exe starten
-CP/M Reset
Source vom Bootlade siehe Anhang
Ich hoffe ich habe deine Frage richtig verstanden bzw. beantwortet.
Egmont
@Alle
für Linux gibt es auch Software dafür...
Joe G. schrieb:> CT: 02 InitRes: 00 SPI_DISABLE> mmcRdSect SPI_CLK_FAST> mmcCMD: 11 00000000 <FF <FF <FF >51 .. 01>01 <FF <00 CMDRes: 00 <FF <FF> <FE <31 <33 <FF SPI_DISABLE RdSectRes: 00
Hier ist das Lesekommando ok. Nach dem erfolgreichen Senden des Befehls
(CMDRes = 0), wird auf das Data-Token (0xFE) gewartet. Danach kommen die
eigentlichen Daten, die man hier nicht sieht.
> Assuming CP/M image at: 000, size: 8192KB.> Partinit done.> mmcRdSect SPI_CLK_FAST> mmcCMD: 11 00000000 <FF <FF <FF >51 .. 01>01 <FF <00 CMDRes: 00 <FF <FÆ
Hier ist der gleiche Lesebefehl (gleicher Sektor). Aber ein Abbruch,
bevor das Data Token kommt. Da man die Karte wohl ausschließen kann,
kann ich mir nur noch vorstellen, daß ein Interrupt Harakiri macht, oder
der Watchdog zuschlägt. Oder Stromversorgung, Stör/Erd-strahlen...
So siehts bei mir aus:
Leo C. schrieb:> Da man die Karte wohl ausschließen kann,> kann ich mir nur noch vorstellen, daß ein Interrupt Harakiri macht, oder> der Watchdog zuschlägt. Oder Stromversorgung, Stör/Erd-strahlen...
Der Watchdog ist abgeschaltet. Der Mega8 zeigt den gleichen Fehler. Für
heute tippe ich mal auf Erdstrahlen. Morgen werde ich mal ein schnelles
Oszi an die Stromversorgung in Nähe der Karte hängen.
Nachtrag:
Ich habe gerade alles nochmal für die alte 4 Bit Variante übersetzt und
- gleicher Fehler. Ein Hardwarefehler ist damit wohl auzuschließen.
CPM on an AVR, v2.0
Testing RAM: fill...wait...reread...
Initing mmc...
Assuming
NEUSTART
CPM on an AVR, v2.0
Testing RAM: fill...wait...reread...
Initing mmc...
Assuming
Joe G. schrieb:> Ich habe gerade alles nochmal für die alte 4 Bit Variante übersetzt und> - gleicher Fehler. Ein Hardwarefehler ist damit wohl auzuschließen.
Mit oder ohne Bootloader?
Ansonsten könnte die Software bei Dir noch anders übersetzt werden, als
bei mir.
Frank Zoll schrieb:> Ich hab soeben das erste mal lesend auf ein Diskimage auf meiner> FAT16 Partition zugreifen können. Das anzeigen des Directorys und der> Programmstart funktionieren.
Wie muss den die FAT16 Partition aussehen
Type (06) , Größe(960MB), IMG-Dateiname (cpm_d.img), IMG-Dateigröße.
Bei mir erscheint nur "fat16 scanning" aber keine Laufwerk.
Der Werte in der Klammer sind die Einstellung so wie sie bei mir sind.
Die SD-Karte hat vier Partitionen:
1. FAT16 06 960MB
2. CP/M 52 8MB aktiv
3. CP/M 52 8MB
4. CP/M 52 8MB
Gruß Egmont
Egmont schrieb:> Wie muss den die FAT16 Partition aussehen> Type (06) , Größe(960MB), IMG-Dateiname (cpm_d.img), IMG-Dateigröße.>> Bei mir erscheint nur "fat16 scanning" aber keine Laufwerk.> Der Werte in der Klammer sind die Einstellung so wie sie bei mir sind.>> Die SD-Karte hat vier Partitionen:> 1. FAT16 06 960MB
Der Typ der Partition sollte 0E sein (FAT16 / LBA-Modus). Ich weiss
nicht genau, ob es auch mit 06er Partitionen funktionieren würde. Das
habe ich noch nicht ausprobiert. Das Diskimage an sich war fast richtig.
Es müsste 'CPMDSK_D.IMG' heissen. Wobei die Suche nach den Images immer
bei A beginnt und mit Z aufhört. Die CP/M Partitionen werden immer
zuerst an den Anfang der internen Partitionstabelle gepackt. Und
Diskimages landen immer dahinter. Die Imagedatei an sich sollte
mindestens 256256 Bytes groß sein. Ist sie das noch nicht, so muss man
sie erstmal mit Nullen auffüllen. Macht man das nicht, würde ein
schreibversuch hinter das Ende der Datei das Dateisystem evtl.
beschädigen, wobei ich versuche diesen Fehler zu erkennen und abzufangen
! Ich habe es nur noch nicht getestet. Daher sind die Schreibroutinen
derzeit in der SVN Version auch noch auskommentiert. Die Routinen können
eine zu kleine Datei nicht vergrößern. Im moment sind Leo und ich dabei
die Routinen zu testen und noch Fehler beim schreibzugriff zu
beseitigen. Hoffe es wird nicht mehr lange dauern, bis wir aquch das im
Griff haben.
Freundliche Grüße
Frank
Ah, da fällt mir gerad noch was ein.
Das Booten von einer FAT16 Partition dürfte noch nicht funktionieren.
Das ganz liegt an der Art wie das Startup in der Datei init.asm codiert
wurde.
1
; Read first sector of first CP/M partition (ipl)
2
lds xl,hostparttbl+1
3
lds xh,hostparttbl+2
4
lds yl,hostparttbl+3
5
lds yh,hostparttbl+4
6
rcall mmcReadSect
Dieses Codestück muss noch angepasst werden, da bei einem Diskimage in
der hoastpartbl an der Position 1-4 nicht der 1. Sektor der Datei
abgelegt ist, sondern die Nummer des 1. Clusters der Datei. Hier greift
der bestehende Lesezugriff an die Falsche stelle der SD- Card. Ich werde
die Stelle bei gelegenheit mal anpassen, damit man auch ganz ohne CP/M
Partitionen ein System booten kann.
Grüße
Frank
Frank Zoll schrieb:> Es müsste 'CPMDSK_D.IMG' heissen. Wobei die Suche nach den Images immer> bei A beginnt und mit Z aufhört.
A - P würde genügen, da CP/M maximal 16 Laufwerke verwalten kann.
Darüber hinaus vermute ich, daß gerade hier noch
Optimierungsmöglichkeiten bestehen. Der Warmboot mit (nur) einem
FAT16-Image dauert deutlich länger, als nur mit Partitionen. Mit
eingeschalteten Debug-Messages sieht man eine deutliche Pause, nachdem
alle FAT-Daten gelesen worden sind. Beim Lesen und Schreiben von
CP/M-Dateien ist aber subjektiv kein Unterschied zum nackten
Part-Treiber. Das FAT16-Dateisystem an sich ist also ausreichend
schnell.
> Die Imagedatei an sich sollte> mindestens 256256 Bytes groß sein. Ist sie das noch nicht, so muss man> sie erstmal mit Nullen auffüllen. Macht man das nicht, würde ein> schreibversuch hinter das Ende der Datei das Dateisystem evtl.> beschädigen, wobei ich versuche diesen Fehler zu erkennen und abzufangen> ! Ich habe es nur noch nicht getestet.
Aber ich jetzt. :-)
Der FAT16-Treiber weigert sich beharrlich, über das Dateiende hinaus zu
lesen und zu schreiben.
> Daher sind die Schreibroutinen> derzeit in der SVN Version auch noch auskommentiert.
Jetzt nicht mehr. :-)
> Die Routinen können> eine zu kleine Datei nicht vergrößern. Im moment sind Leo und ich dabei> die Routinen zu testen und noch Fehler beim schreibzugriff zu> beseitigen. Hoffe es wird nicht mehr lange dauern, bis wir aquch das im> Griff haben.
Hier gibts die FAT16 Testversion:
http://cloudbase.homelinux.net/viewvc/avr-cpm/tags/2.0-fat16/
oder
http://cloudbase.homelinux.net/svn/avr-cpm/tags/2.0-fat16/
Es fehlt noch etwas Feinschliff und die Tests waren bisher noch nicht
sehr umfangreich. Mmn sollte es aber mindesten so gut funktionieren, als
der bisherige Code.
@Frank,
tolles Stück Arbeit.
Halloe.
Das Scannen nach den Image- Dateien ist wirklich nicht gerade schön. Bis
alle 26 Buchstaben durchprobiert wurden müssten bei 512 Directory-
Einträgen und 16 Einträgen pro Sektor insgesammt 832 Sektorlesezugriffe
erfolgen. Pro Buchstabe der gesucht werden soll werden alle 32
Direktory- Sektoren je einmal gelesen. Daher dauert es auch so lange.
Dafür bekommt man halt die Laufwerke immer in die richtige Reihenfolge
in der Partitionstabelle, egal in welcher Reihenfolge sie gerade auf der
SD- Card im Verzeichniss liegen. Hier würde ich vorschlagen, das wir
immer mit A anfangen und die Anzahl der Buchstaben auf die aktuelle
Größe der Partitionstabelle begrenzen. Mehr als diese Menge an Images
können eh nicht verwaltet werden. Man ist dann halt dann gezwungen mit A
anzufangen und die Images vorlaufend zu benennen, aber das sollte doch
nichts ausmachen oder ?
@Leo
Danke für die Hilfe bei den Tests.
Grüße
Frank
Frank Zoll schrieb:> Man ist dann halt dann gezwungen mit A> anzufangen und die Images vorlaufend zu benennen, aber das sollte doch> nichts ausmachen oder ?
Sicher nicht (imho). Der größte Teil der Dateinamen ist ja sowieso
hartcodiert.
Noch etwas anderes:
Wie wichtig ist denn noch, daß das Programm noch auf Atmega8 und
Atmega88 läuft?
Im Moment paßt nur noch die 4-Bit Version in den Speicher. Natürlich
ohne FAT16. Die 8-Bit Version würde man noch mit etwas
Geschwindigkeitseinbuße hinkriegen.
Frank Zoll schrieb:> Das Booten von einer FAT16 Partition dürfte noch nicht funktionieren.
@alle, die auf ihren SD-Karten nur FAT-Paritionen haben (wollen):
Das hat Frank inzwischen geändert. Man kann jetzt auch von einer
Image-Datei im FAT16-Filesystem booten. Außerdem werden jetzt zwei
FAT16-Partitionstypen erkannt. 0E und 06.
Das Update gibts hier:
http://cloudbase.homelinux.net/viewvc/avr-cpm/tags/2.0-fat16-1
Leo C. schrieb:> @alle, die auf ihren SD-Karten nur FAT-Paritionen haben (wollen):
Und jetzt auch an:
@alle, die mehr als ein File-Image auf ihrer FAT-Parition haben wollen:
Leider hatte sich ein kleiner Fehler eingeschlichen, der verhinderte,
daß mehr als eine Datei auf der FAT16-Partition erkannt wurde.
Neues Update:
http://cloudbase.homelinux.net/viewvc/avr-cpm/tags/2.0-fat16-2/
ist hier nicht noch ein Zahlendreher drin
-------[ Config.inc ]----------------------
#define K 1024
#define M 1204*K <-- Zahlendreher
#define RAMSIZE 4*M*4 * 2 /* 2 chips 4Mx4 */
-------------------------------------------
Gruß Egmont
Egmont schrieb:> ist hier nicht noch ein Zahlendreher drin
Oh, doch.
> -------[ Config.inc ]----------------------> #define K 1024> #define M 1204*K <-- Zahlendreher>> #define RAMSIZE 4*M*4 * 2 /* 2 chips 4Mx4 */> -------------------------------------------
Das steht da schon ziemlich lange drin, und ist wohl nur deshalb nicht
aufgefallen, weil es (bisher) nirgens benutzt wird.
Danke für den Hinweis.
Halloe.
Da der FAT16- Treiber nun bereits recht gut läuft, hätte ich evtl. ein
wenig Zeit über bei der Programmierung des VGA- Teils der Platine mit zu
helfen. Gibt es hier schon etwas, auf das man aufbauen könnte ? Bzw. ist
schon jemand dabei etwas vorzubereinten und braucht ggf. noch Hilfe ?
Grüße
Frank
p.s. Ich habe das TotalCommander Plugin das Leo gefunden hat mal kurz
angetestet. Wenn man die diskdefs passend erweitert, kann man damit auch
problemlos auf die Imagedateien zugreifen, die zu unserem netten kleinen
Projekt hier gehören. Es muss also nicht unbedingt mit einem Laufwerk
gearbeitet werden. Wer so wie ich GUI- Verwöhnt ist, dem kann ich nur
den Tipp geben sich mal das Tutorial auf der Homepage anzuschauen. Damit
klapts auf anhieb :-)
Guten Abend,
nach dem Erwerb des 4-Bit-Systems von Peter Sieg und dem Studium dieses
Forum-Threads war ich so begeistert, dass ich ihm auch die Platine der
8-Bit-Version abgekauft habe.
Jetzt bin ich beim Zusammenstellen der Bauteile gemäß Schaltplan und
Stückliste. Dabei habe ich gleich die Frage, wie man an den 13-poligen
SD-Karten-Sockel kommt? Die Standard-Lieferanten wie Reichelt, Segor
oder Conrad haben den nicht!
Außerdem verstehe ich die Stromversorgungsschaltung auf Seite 2 des
Schaltplans nicht. Wozu ist der Gleichrichter und der 5V
Spannungswandler notwendig, wenn man doch schon mit einem 5V
Steckernetzteil arbeitet? Auch die Funktion des 25MHz-Quarzoszillators
und des separaten 20 MHz-Quarzes sind mir nicht ganz klar. Welcher Quarz
macht was?
Gruß Siggi
aus dem SVN-Archiv
141_avr-cpm-trunk.tar.gz
fehlt eine Datei "heap.asm"
siehe aufruf in Datei
-----------[ avrcpm.asm ]----------
...
.include "heap.asm"
...
-----------------------------------
würde gerne diese Version auch mal testen
Gruß Egmont
Siggi M. schrieb:> wie man an den 13-poligen> SD-Karten-Sockel kommt?
Der wurde bei CSD bestellt... ca. 3 Euro
Bei mehr als 5 IMG-Dateien bekomme ich folgende Fehlermeldung
Version 136 vom SVN-Server.
Auf D: kann ich noch zugreifen, bei E: --> Kill
---------------------------------------------------------
CPM on an AVR, v2.0
Testing RAM: fill...wait...reread...
Initing mmc...
A:FAT16 File-Image at: 002, size: 250KB.
B:FAT16 File-Image at: 018, size: 250KB.
C:FAT16 File-Image at: 034, size: 250KB.
D:FAT16 File-Image at: 050, size: 250KB.
E:FAT16 File-Image at: 066, size: 250KB.
Partinit done.
Ok, CPU is live!
ipl
62k cp/m vers 2.2
A>d:
D>dir
D: TTT2 COM : OTHELLO COM : MMIND COM : ED COM
D: LOAD COM : STONE COM : PIP COM : STAT COM
D: SUBMIT COM : XSUB COM
D>e:
Bdos Err On E: Select
---------------------------------------------------------
Leo C. schrieb:> A - P würde genügen, da CP/M maximal 16 Laufwerke verwalten kann.
Gruß Egmont
Egmont schrieb:> aus dem SVN-Archiv> 141_avr-cpm-trunk.tar.gz> fehlt eine Datei "heap.asm"
Ups, stimmt(e).
Die Datei ist jetzt drin.
> würde gerne diese Version auch mal testen
Ist im Moment aber etwas gewagt. Du brauchst dann auf jeden Fall auch
das BIOS (bios.mac) aus dem cpm-Verzeichnis.
Kommentare und Patches dazu sind natürlich willkommen.
Egmont schrieb:> Bei mehr als 5 IMG-Dateien bekomme ich folgende Fehlermeldung> Version 136 vom SVN-Server.> Bdos Err On E: Select
Die Anzahl Laufwerke ist an zwei Stellen begrenzt:
1.) dsk_fsys.asm:
.equ MAXDISKS = 6 ;Max number of Disks (partitions)
2.) Z.Zt. noch im BIOS auf 4 Laufwerke.
Wenn Du MAXDISKS noch höher setzen willst, mußt Du den RAM-Verbrauch im
Auge behalten. Ggf. kann man die UART-Buffer halbieren.
Im Anhang ist ein BIOS, das bis 8 Laufwerke gehen sollte. In dem
Zip-Archiv sind auch die Quellen und die fertigen Binärdateien
'bios.bin', 'cpm.bin' und ein komplettes 'diskimage'.
Leider habe ich es z.Zt. nicht besser.
Halloe.
Ich habe mir in der letzten Nacht mal den VGA- Teil der aktuellen
Platine angeschaut und das oben verlinkte Beispiel für das
VGA-Betriebssystem genau unter die Lupe genommen.
Mitlerweile habe ich den Code der Vorlage aufgeräumt und so angepasst,
das er sich auch für den 328er Übersetzen lässt. Nun ist das SRAM
erstmal zu 197% gefüllt, wegen des zu großen Framebuffers. Als nächstes
werde ich den Puffer so weit verkleinern, das er gerade noch so eben in
das SRAM passt.
Findet sich hier evtl. jemand der lust hat einen spezeillen, neuen,
Zeichensatz zu basteln ? Wir brauchen einen Zeichensatz von 6 Pixel
breite verpackt in jeweils 1 Byte pro Zeile. Die höhe weiss ich noch
nicht genau, weil ich die endgültige Größe des Framebuffers noch nicht
ausprobiert habe. Bei den oben angedachten 25 Zeilen wäre die Höhe für
den Zeichensatz 16 Pixel(Zeilen). Ich plane jedoch möglichst viele
Zeilen aufs Display zu quetschen, da würden dann ggf. noch ein paar
Zeilen im zeichensatz wieder wegfallen.
Die 80 Zeichen pro Zeile scheinen machbar zu sein, unschön ist nur das
zwischen jedem Zeichen 2 spalten dunkel bleiben, die wir nicht werden
ansteuern können. Damit läßt sich dann wohl leider mit dem neuen
Zeichensatz keine durchgehende horizontale Line erreichen. Umgehen läßt
sich dieses Problem nicht so einfach, da der Port an dem das
Schieberegister hängt nur 6 der eigentlich im Original vorgesehenen 8
Bits liefern kann. Die Routine, die die Zeihen ausgiebt, hat leider
keine reserven mehr um da noch Befehle hinzunehmen zu können, die die
fehlenden 2 Bits irgendwie ersetzen könnten. Vieleicht hat hier ja
jemand noch eine super Idee ?
Kennt sich hier evtl. jemand mit den CP/M Terminals aus und kann mir da
Helfen, heraus zu bekommen was so ein Terminal alles können muss außer
bloß ein par Zeichen anzuzeigen ? Da scheint im Originalcode noch eine
große Lücke zu klaffen, die wir noch füllen müssen.
Grüße
Frank
Siggi M. schrieb:> Wozu ist der Gleichrichter und der 5V> Spannungswandler notwendig, wenn man doch schon mit einem 5V> Steckernetzteil arbeitet? Auch die Funktion des 25MHz-Quarzoszillators> und des separaten 20 MHz-Quarzes sind mir nicht ganz klar. Welcher Quarz> macht was?
- SD-Karten-Sockel Type SCDA5A0201, Best.Nr.: 020115
- Bei einem 5V Steckernetzteil entfällt natürlich der Gleichrichter und
der 5V Regler
- der 25MHz Quarzoszillator auf der VGA-Platine muß genau diesen Wert
haben, da davon der Pixeltakt abgeleitet wird.
- Das AVR-CP/M System benötigt auch einen Takt. Dieser kann durch den
Oszillator (25MHZ) oder einen externen Quarz (hier als Bsp. 20MHZ)
erzeugt werden. Da das Gesamtsystem noch sehr experimentell ist, die
vielen Varianten. Eine Möglichkeit ist also 1 x 25MHZ auf der AVR-CP/M
Platine. Damit ist auch gleich der VGA Takt erzeugt. Eine weitere
Möglichkeit 25MHz auf der VGA-Seite (siehe oben) und z.B. 30 MHz
AVR-CP/M.
Noch Fragen?
Joe
Frank Zoll schrieb:> Kennt sich hier evtl. jemand mit den CP/M Terminals aus und kann mir da> Helfen, heraus zu bekommen was so ein Terminal alles können muss außer> bloß ein par Zeichen anzuzeigen ? Da scheint im Originalcode noch eine> große Lücke zu klaffen, die wir noch füllen müssen.
Unbedingt:
- Clear screen
- Cursor positionieren (x,y)
- ein Attribut (eins aus:highlight, dim, inverse, underline, blink
(igit))
Gut:
- Clear to end of line
- Delete line (nachfolgende zeilen rutschen hoch)
- Insert Line (Zeilen unterhalb der Curserposition eine Zeile nach
unten)
- mehr Attribute
ANSI oder VT100 war zu CP/Ms Hochzeiten nicht verbreitet. Ist
wahrscheinlich auch etwas aufwendig zu implementieren.
Arbeitspferd war das Lear Siegler ADM-3A und viele Kompatible. Praktisch
jedes CP/M-Programm mit Terminalsteuerung unterstützt das.
http://www.tentacle.franken.de/adm3a/
Das scheint aber wirklich nur die unbedingt notwendigen Funktionen zu
haben.
Das nächst bessere, und auch sehr weit verbreitet, war dann Televideo
920 oder so.
Mein MC-Terminal, daß seit einigen Wochen wieder hier rumliegt und auf
Inbetriebnahme wartet, ist auch Televideo-kompatiebel.
Und weils so schön ist, in alten Erinnerungen zu schwelgen, im Anhang
ein Bild von meiner ersten Terminal-Karte (Elektor, 64 Zeichen x 16
Zeilen, max 1200 Baud und 120ms für den clear screen)
Frank Zoll schrieb:> Die 80 Zeichen pro Zeile scheinen machbar zu sein, unschön ist nur das> zwischen jedem Zeichen 2 spalten dunkel bleiben, die wir nicht werden> ansteuern können.
War leider mit dem ATmega328 nicht anders lösbar.
> Die Routine, die die Zeihen ausgiebt, hat leider> keine reserven mehr um da noch Befehle hinzunehmen zu können, die die> fehlenden 2 Bits irgendwie ersetzen könnten. Vieleicht hat hier ja> jemand noch eine super Idee ?
Vorschlag zur Ausgabe einer durchgehenden Linie.
PB4 und PB5 an das Schieberegister und vor der Zeilenausgabe die beiden
Bits gesetzt. Zwischen Backporch und Frontporch ist ja noch etwas Platz
für den Code.
Joe
Leo C. schrieb:
Vergessen:
> Unbedingt:> - Clear screen
- Cursor links (back space)
> - Cursor positionieren (x,y)> - ein Attribut (eins aus:highlight, dim, inverse, underline, blink)> Gut:> - Clear to end of line> - Delete line (nachfolgende zeilen rutschen hoch)> - Insert Line (Zeilen unterhalb der Curserposition eine Zeile nach> unten)
- Erase to end of screen
- Insert Character
- Delete Character
- Cursor right, up, down
> - mehr Attribute
Joe G. schrieb:> mmcCMD: 11 00017A00 .. 01 CMDRes: 00> A:FAT16 File-Image at: 002, size: 081KB.> Partinit done.> mmcCMD: 11 00017C00 .. 01 CMDRes: 00>> CPM on an AVR, v2.0> Testing RAM: fill...wait...reread...> Initing mmc...
Immerhin werden eine ganze Anzahl Sektoren fehlerfrei gelesen. Es liegt
wohl eher nicht an der Karte oder am mmc-Treiber.
Kannst Du mal das komplette Verzeichnis, in dem Du die Software
übersetzt hast, zusammen packen und an mich schicken?
Leo C. schrieb:> Kannst Du mal das komplette Verzeichnis, in dem Du die Software> übersetzt hast, zusammen packen und an mich schicken?
Ist unterwegs...
Joe G. schrieb:> Leo C. schrieb:>> Kannst Du mal das komplette Verzeichnis, in dem Du die Software>> übersetzt hast, zusammen packen und an mich schicken?>> Ist unterwegs...
Ich habs schon gesehen. Bis auf CPU, CPU-Frequenz und die Debugschalter
in 'config.asm' ist alles identisch zu meinem Stand hier, bzw zum
2.0-fat16-2 im SVN.
BIOS hatten wir ja schon ausgeschlossen.
Mir fällt nichts mehr ein.
Joe G. schrieb:> Leo C. schrieb:>> Mir fällt nichts mehr ein.>> Dann bleibt ja nur noch die Hardware. Ich mach mich mal auf die Suche.
Inzwischen habe ich auch mal mit Deinen Schaltern übersetzt. Hex-Files
sind auch identisch. (In Deiner 'AvrBuild.bat' ist ein komischer
Schalter für den Assembler gestzt. Ich wollte ausschließen, daß der
einen Unterschied macht.)
Vielleicht hat der Prozessor vom Übertakten einen Dachschaden?
Hm,
mitlerweile habe ich den VGA-Code ans laufen bekommen. Zufriedenheit
sieht aber anders aus. Ich bekomme auf meinem alten Monitor einen klaren
Sync bei 640*400 @74Hz. Aber von meinem Beispieltext im Framebuffer ist
nichts zu sehen. :-(
Grüße
Frank
@alle
Einen Schaltungs- / Layoutfehler habe ich gefunden.
der Pegelwandler IC2 (Pin 14) sollte mit seiner Spannungsversorgung an
3.3V liegen und nicht an 5V! Bitte im Layout ändern.
Leo C. schrieb:> Vielleicht hat der Prozessor vom Übertakten einen Dachschaden?
Nein, leider auch nicht.
Frank Zoll schrieb:> Aber von meinem Beispieltext im Framebuffer ist nichts zu sehen. :-(
Hast du eines von den 74AC08 Gattern (IC7) auch auf High gesetzt?
Ansonsten schiebt das Schieberegister nichts auf die VGA-Buchse.
Joe G. schrieb:> Frank Zoll schrieb:>> Aber von meinem Beispieltext im Framebuffer ist nichts zu sehen. :-(>> Hast du eines von den 74AC08 Gattern (IC7) auch auf High gesetzt?> Ansonsten schiebt das Schieberegister nichts auf die VGA-Buchse.
Halloe.
Ich denke, das müsste gerad schön bunt aussehen. Hier das Setup für die
Fordergrundfarbe.
Das Setup wird im moment unmittelbar vor der Ausgabeschleife aufgebaut.
Alles was nicht unbedingt für das Terminal gerbaucht wurde hab ich
mitlerweile raus geworfen. Im moment versuche ich gerade statt des Fonts
ein einfaches 10101010 Streifenmuster zu erzeugen. Auch das tut leider
nicht. Ich werd mir wohl mal die Hardeware unter der Lupe anschauen
müssen, evtl. hab ich da noch nen Bug drinn :-)
1
// farbe einstellen
2
// Pin 5-7 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:
Halloe.
Habe die letzten blödden Fehler endlich gefunden. Hier mal zwei Bilder
des aktuellen Standes :-)
Die VGA-Ausgabe läuft. Es ist gerade so eben Platz für 80 Zeichen pro
Zeile und insgesammt 22 Zeilen.
SRAM ist zu 96,4% gefüllt. Bissel was brauche ich noch für den Stack.
Nun brauchen wir einen Zeichensatz wie oben beschrieben. (6 Pixel Breit,
18 Pixel Hoch) Je ein Byte pro Zeile. Als nächstes muss ich die
Terminalverbindung reaktivieren und mich um einen Software UART für die
Tastatur kümmern, die ich abschalten musste weil der 328er nur 1 UART
zur Verfügung hat.
Grüße
Frank
p.s. Mit Attributen (Blinken,Invers, Durchgestrichen etc.) pro Zeichen,
das wird nix mehr, das RAM ist voll....
Halloe.
Ich habs geschaft, 24 Zeilen ins Ram rein zu quetschen. Damit wären wir
gerad noch konform mit den oben genannten Standard- Terminals. Ich habe
nur noch keine Idee was wir mit den Attribiuten machen. Da die Terminals
eigentlich alle mit 7 bit / Zeichen arbeiten, hätten wir noch 1 bit
über. Dies Bit könnten wir zum Beispiel nutzen um sowas wie einen
Inversen- Modus zu unterstützen. Bei 24 zeilen ist das Ram fast voll und
ich habe noch nicht die Routinen für die Tastatur fertig, daher möcht
ich mal nicht versprechen das ich evtl. wieder Zeilen rausstreichen muss
um das ganze Lauffähig zu halten.
Grüße
Frank
Ich habe mal meinen aktuellen Softwarestand hochgeladen (trunk).
Achtung: Diese Version bitte nicht mit Disk Images testen, die wichtige
Daten enthalten. Es könnte sein, daß unter bestimmten Bedingungen ein
falscher Sektor geschrieben wird.
Ich habe die maximale FAT16-Image-Dateigröße und die maximale
CP/M-Partitionsgröße auf 32MB begrenzt. Dh., CP/M-Dateisysteme können
maximal 32MB groß werden. Sieht hier jemand ein Problem?
Das Programm kann jetzt verschiedene Diskformate erkennen und einbinden.
Im Moment sind das die Images vom MyZ80 Emulator und von YAZE-(AG). In
der YAZE-AG Distrib sind verschiedene Diskimages (*.ydsk-Dateien), die
fast alle unterschiedliche Größen haben.
http://www.mathematik.uni-ulm.de/users/ag/yaze/
Diese Formate können auch mit den cpmtools verarbeitet werden.
Optimal sind aber weder MyZ80 noch das YAZE-Format. Beide haben einen
Header, der nicht der physikalischen Sektorgröße der Speicherkarten
entspricht (MyZ80 256 Byte und YAZE 128 Byte). Das kostet Performance,
weil die CP/M Datenblöcke dann immer mitten im Sektor beginnen und
enden, und der Teil davor, bzw. danach auch immer gelesen, bzw,
geschrieben werden muß.
Für unser System würde ich ein Format mit einem 1 Sektor (512 Byte)
großen Header bevorzugen. Das ließe sich mit der jetzt vorhandenen
Software verwenden.
Da aber Header unbeliebt zu sein scheinen ;), könnte man auch noch was
mit fest vorgegebenen Formatgrößen realisieren. Die Software dazu ist im
Prinzip auch vorhanden. Frank hat mir dazu schon den Vorschlag
geschickt, das Format über den Dateinamen zu bestimmen. Das geht auch,
allerdings nur mit FAT16 und natürlich nicht mit direkten Partitionen.
Eine andere (oder zusätzliche) Möglichkeit wäre, einige
Laufwerksbuchstaben (z.B. M-P) für feste Formate zu reservieren. Dazu
müßte man sich aber auf ein bis maximal 2 Formate einigen.
Je größer die Disk ist, und vor allem, je mehr Directory-Einträge sie
hat, um so langsamer wird der Zugriff. Große Disks mit kleinen
Directories machen aber keinen Sinn.
In der angehängten Zip-Datei ist ein leeres MyZ80 Image. Die Datei wird
beim Auspacken 8MB groß.
In den nächsten Tagen möchte ich das ganze nochmal überarbeiten (und das
Chaos etwas aufräumen). Inzwischen ist mir noch eine deutliche
Verbesserung zu der Schnittstelle zum 8080 BIOS-Teil eingefallen.
Eine andere Baustelle ist noch das Verhalten bei Diskwechsel mit und
ohne Warmstart. Verschiedene Softwarestände verhalten sich inzwischen
unterschiedlich, und mir ist noch nicht ganz klar wie es richtig geht.
Im Moment muß nach Ziehen und Stecken der Karte ein Warmstart erfolgen,
damit CP/M wieder auf die Karte zugreifen kann.
Wenn man allerdings die Karte immer automatisch neu initialisiert, wenn
sie gewechselt wurde, besteht die Gefahr, das Daten auf die falsche
Karte geschrieben werden.
Bitte probiert das mal aus und macht Vorschläge.
Frank Zoll schrieb:> Ich habs geschaft, 24 Zeilen ins Ram rein zu quetschen.
Super Frank!
Gab es noch was an der Hardware oder lag es an der Software?
Joe
Halloe
Die Hardware sowohl von der CP/M Emulatorseite als auch auf der VGA-
Seite läuft gänzlich ohne Lötpatches stabil. Die VGA- Seite habe ich mit
25Mhz wie gefordert übertacktet. Die CP/M Seite läuft auf 20 Mhz, hier
habe ich keinen Übertacktungsversuch gemacht. Auf VGA- Seite habe ich
nur einen blöden Softwarefehler gehabt. Mitlerweile läuft auch schon die
einfache Textausgabe über UART von der CP/M Seite aus. Das Keyboard habe
ich noch nicht am laufen und der Font ist auch noch nicht fertig. Die
Anzeige sieht wegen des falschen Fonts noch ziemlich kaputt aus, aber
man kann die Zeichen mit gut will schon erkennen.
Grüße
Frank
Ich habe mal hier meine aktuelle "Spielversion" angehangen. Das Hex-File
ist für den 328er mit 25Mhz Quarz compiliert. Die UART- Geschwindigkeit
ist 9600 Baud 8N1. Hier muss man auf der CP/M Seite von 36800 Baud noch
eben runtergelen, sonst klappt die Anzeige nicht. :-)
Hallo,
wo bekomme ich zum übersetzen von ipl.asm und bios.asm die Datei
z80asm.exe her. Googeln brachte bei mir kein Erfolg.
Ein Link oder eine Datei währe nicht schlecht (für Windows).
Was ist mit bios.mac, für was wird die benötigt....anderer
Compiler/System ?
Gruß Egmont
* ipl.asm (läd das CP/M von der 'Diskette' vom track 0 sector 2 bis track 1 sector 26)
4
* bios.asm
5
* cpm.sys
6
7
Obige 8080/Z80 Assemblerdateien lassen sich unter Linux hiermit: http://www.nongnu.org/z80asm/ und unter Windows hiermit (end Statement auskommentieren): http://www.tni.nl/products/tniasm.html übersetzen. Unix-Tools für Windows, u.a. DD findet ihr hier: http://sourceforge.net/projects/unxutils/files/unxutils/current/UnxUtils.zip/download
Egmont schrieb:> Hallo,> wo bekomme ich zum übersetzen von ipl.asm und bios.asm die Datei> z80asm.exe her. Googeln brachte bei mir kein Erfolg.> Ein Link oder eine Datei währe nicht schlecht (für Windows).> Was ist mit bios.mac, für was wird die benötigt....anderer> Compiler/System ?
bios.asm ist zu alt. Aktuell ist bios.mac. Dazu gehören auch die beiden
.lib Dateien.
bios.mac und ipl.mac können mit M80 (MACRO-80) von Microsoft auf Deinem
CP/M-System übersetzt werden. :)
Wahrscheinlich gibts kompatible Crossassembler, die unter Windows
laufen, aber ich habe noch keinen gefunden.
Es gibt auch CP/M-Emulatoren, die einen Befehl abarbeiten, der auf der
Befehlszeile übergeben wird. "zxcc" ist so ein Ding, und funktioniert
bei mir unter Linux wunderbar. Laut der Homepage sollte es aber auch
unter DOS (Windows) laufen:
http://www.seasip.demon.co.uk/Unix/Zxcc/
Wenn zxcc richtig installiert ist, kann man das BIOS so assemblieren und
linken:
1
$ zxcc m80 -=bios.mac
2
$ zxcc l80 -bios.rel,bios.bin/N/E
Das Makefile erledigt diese Schritte automatisch.
Für Windows habe ich noch eine eine Alternative gefunden: "m80l80pc.zip"
Mit Google leicht zu finden.
Wenn Die Dateien aus dem Paket im Pfad zu finden sind, können M80 und
L80 direkt auf der Befehlszeile gestartet werden. Das ganze ist
offensichtlich mit dem CP/M-Emulator "22nice" gebaut, der ebenfalls
leicht zu finden ist, und vielleicht auch sonst einen Versuch wert wäre.
Im m80l80pc.zip Paket ist auch das M80/L80 Handbuch als Textdatei. Sonst
habe ich immer nur gescannte Handbücher als PDF gefunden.
Meine Bitte an die Windowsbenutzer wäre, daß mal jemand die 2 Varianten
ausprobiert. Wenn m80l80pc die bessere Alternative ist, würde ich das
mit ins Makefile aufnehmen. Das aktuelle Makefile mit zxcc sollte auch
unter Windows ohne Änderung laufen.
@Leo C.
Danke für die Info! Ich hab die V91 mal reaktiviert. Das nun auftretende
Fehlerbild ist fast der Supergau. Hier ein Logauszug:
CPM on an AVR, v1.0
Testing RAM: fill...wait...reread...
Initing mmc...MMC: <--0A, -->FF
MMC: <--09, -->FF
MMC: <--08, -->FF
MMC: <--07, -->FF
…
MMC: <--FF, -->AA
MMC: <--FF, -->40
MMC: <--FF, -->E3
MMC: <--FF, -->FF
CP/M partition at: 8097, size: 4144KB.
CP/M partition at: 16385, size: 7808KB.
Partinit done.MMC: <--FF, -->FF
MMC: <--51, -->FF
MMC: <--00, -->FF
MMC: <--3F, -->FF
…
MMC: <--FF, -->E3
MMC: <--FF, -->1F
MMC: <--FF, -->3E
MMC: <--FF, -->FF
Ok, CPU is live!
ipl
DISK I/O: Invalid Function code: 01
Der letzte Fehler ist klar - ist das aktuelle BIOS auf der Karte. Aber
hier wird die Karte richtig und vollständig gelesen. Fragen über
Fragen...
Joe
Nachtrag:
Ich habe auch nochmal das alte BIOS übersetzt und auf die Karte
geschrieben.
CPM on an AVR, v1.0
Testing RAM: fill...wait...reread...
Initing mmc...
CP/M partition at: 000, size: 8192KB.
Partinit done.
Ok, CPU is live!
ipl
62k cp/m vers 2.2
A>dir
A: ASM COM : DDT COM : DUMP COM : ED COM
A: LOAD COM : PIP COM : STAT COM : SUBMIT COM
A: T COM : TIMER COM : ZORK1 COM : ZORK1 DAT
A: ZAP80 COM : MBASIC COM : ELIZA BAS
Das ist der Ergebnis der "neuen Hardware" mit der alten Software.
Joe G. schrieb:> CP/M partition at: 8097, size: 4144KB.> CP/M partition at: 16385, size: 7808KB.> Partinit done.MMC: <--FF, -->FF> MMC: <--51, -->FF> MMC: <--00, -->FF> MMC: <--3F, -->FF> …> MMC: <--FF, -->E3> MMC: <--FF, -->1F> MMC: <--FF, -->3E> MMC: <--FF, -->FF>> Ok, CPU is live!> ipl> DISK I/O: Invalid Function code: 01>> Der letzte Fehler ist klar - ist das aktuelle BIOS auf der Karte.
Wie meinst Du das? Der Code sieht eher nach einem zu alten Bios aus.
Das ursprüngliche BIOS hatte hier die Codes 01 und 02. Ich habe es
geändert auf Codes >= 40. Der "Code" könnte aber auch dadurch zustande
kommen, daß das BIOS nicht vollständig geladen wird.
> Aber> hier wird die Karte richtig und vollständig gelesen.
Bist Du sicher?
Bei all den Versuchen, die ich vorher gesehen hatte, war das auf mmc
Treiberebene aber auch der Fall.
Mir ist jetzt aber noch was anderes eingefallen:
Wieviele Sektoren werden beim Booten denn gelesen?
Anders gefragt: Wieviele Sektoren liest Dein ipl und wie wird/wurde Dein
cpm.bin gebaut. Ursprünglich wurden vom ipl 2 Sektoren zu wenig geladen,
und vom Makefile 1 Sektor zu wenig vom bios.bin kopiert. Mit dem
damaligen BIOS war das egal, weil es klein genug war.
Logauszug Rev. 78
1
* cpm/Makefile:
2
- cpm.bin: Copy (all) 7 sectors from bios.bin.
Logauszug Rev. 63
1
* cpm/ipl.asm
2
- Increased number of sectors to load from 49 to 51 (= all reserved sectors).
Deinen neuen Artikel habe ich gesehen. Obige Fragen bleiben.
> Fragen über Fragen...
Leo C. schrieb:> * cpm/Makefile:> - cpm.bin: Copy (all) 7 sectors from bios.bin.
Mein (Windows) Makefile hat nur 6 Sektoren gelesen, dumme Sache. Ich muß
mal alle Makefiles überprüfen.
Joe G. schrieb:> Leo C. schrieb:>> * cpm/Makefile:>> - cpm.bin: Copy (all) 7 sectors from bios.bin.>> Mein (Windows) Makefile hat nur 6 Sektoren gelesen, dumme Sache. Ich muß> mal alle Makefiles überprüfen.
ipl nicht vergessen. Ich meine, daß die 6 Sektoren gerade noch reichen.
Jedenfalls hats gereicht, als ich die Änderung gemacht habe, und beim
neuesten BIOS reichts auch. Aber die 5 Sektoren, die der alte ipl
kopiert, reichen nicht.
Hallo Peter.
Genau so siehts bei mir derzeit auch aus. Da der Font noch nicht
angepasst ist, fehlen an den Zeichen rechts immer 2 Pixel. Und da die
Höhe des Fonts nur 8 und nicht 16,667 Pixel ist, liest er am Ende über
den Pufferspeicher hinaus. Als nächstes muss ich erstmal einen
vernünftigen Font basteln und die Ausgaberoutine daran anpassen. Danach
kann ich daran gehen, die fehlennden Funktionen des VT100 Terminals
nachzubauen.
Grüße
Frank
Moin Frank,
fehlt nicht eher links was oder hängt das mit dem
Schieberegister zusammen? Wenn Du mir kurz erklären,
wie es aufgebaut ist, kann ich Dich beim Font
unterstützen. Ist ja eher ne Fleissarbeit.
Verstehe ich es richtig, dass in der font.c jede
Spalte ein 8x8 Zeichen ist? 1.Spalte 0x00 bis 0xff.
Sind dies schon die ASCII Adressen? Bei 16x6 werden
die Zeichen rel. schmal, obwohl, es geht ja min.
1 linie als Zwischenraum weg.
Gruss
Peter
Hallo Peter.
Ich habe schon einen einfachen Font angefangen. Im moment fehlen mir
"nur" noch die Kleinbuchstaben. Und ich muss das File nacher noch
passend aufbereiten. Ich spiele gerad mit einem ganz einfachen
Fonteditor rum.
Der Font wie er in der Font.c abgelegt ist, ist praktisch Zeilenweise
abgelegt. Pro Zeile eines Zeichens wird immer genau 1 Byte verwendet.
Jedoch sind nicht etwa alle Zeichen einfach nacheinander Zeile für Zeile
abgelegt.
Die Tabelle ist so angelegt, das jeweils eine Spalte von oben nach unten
gesehen ein Zeichen bildet. Von Links nach Rechts sind die Zeichen von
ASCII- Code 0 bis 255 aufsteigend abgebildet.
Das erleichtert der Bildaufbauroutine den Zugriff ganz enorm.
Mit der Aussage, es fehlt eher links was könnte stimmen. Wenn man die
Bits eher so Zählt 76543210, dann würde er links 2 Bits wegwerfen. Auf
jeden Fall werden nur die 6 niederwertigsten Bits auf den Port
ausgegeben. Und das Abschneiden an der Linken Seite würde auch zu deinem
Foto besser passen.
Grüße
Frank
Hallo Frank,
ich habe mal ein paar Buchstaben der 8x8 aufgemalt. Bei
"B" und "D" sieht man den senkrechten Strich noch auf dem
Monitor, weil sie eine Serife haben. Es fehlen also links
2 Bit. Die Ziffern rechts sind die cursor Positionen in
der font.c im AVR-Studio.
Gruss
Peter
Neues Format.
Ich habe mir heute nochmal die Formate des genialen simh Altair 8800
Emulators angeschaut. Das Diskettenformat kann man vergessen. Das
Harddiskformat ist aber ganz simpel und ich habe es schon eingebaut.
Kleiner Wermutstropfen: Das Format hat zwar 6 Systemspuren a 32 Sektoren
reserviert, aber wenn man dort ein System zum booten einspielt, kann es
nicht mehr erkannt werden. Das werde ich aber irgendwann mal ändern.
Zu dem Emulator gibt es eine ganze Menge Diskimages mit guter Software.
Allerdings sind das alles Diskettenimages. Aber man kann sie ja im
Emulator einfach auf "Harddisk" umkopieren. Hier kann man alles
runterladen:
http://www.schorn.ch/cpm/intro.php
Hier ist eine Formatbeschreibung für die cpmtools:
Halloe.
Es ist schon späht, aber ein kleines Update möchte ich euch noch zum
anschauen überlassen. Im Anhang findet ihr eine erste Version der
Routinen mit einem 6*16 Font. Bitte nicht zu genau drauf schauen, ich
habe den Font mal eben schnell komplett neu gezeichnet. Und ich bin bei
weitem kein Mahlkünstler :-)
Leider habe ich keinen wirklich guten kostenlosen Editor für Windows
gefunden. Man sieht beim Malen nicht, wie es nacher im gesammten
wirklich aussieht. Ich werde den Font nochmal ein bissel überarbeiten,
aber man kann nun wenigstens schonmal was erkennen. :-) Etwa in der Art
wird es nacher ausschauen.
Da ich noch ein "einfaches" Attribut umsetzen könnte frage ich einfach
mal. Invertiert oder lieber Unterstrichen, was hättet ihr lieber ?
Grüße
Frank
p.s. die 25. Zeile mit dem Müll darin werde ich in der nächsten Version
ausblenden, so das sie nicht mehr stört.
Ich habe das SVN-Repository etwas umstrukturiert. Alte Links aus dem
Forum werden wohl nicht mehr funktionieren, sorry. Vom Top-Level aus
dürfte es aber kein Problem sein, alles wieder zu finden.
In avrcpm/trunk gibt es ein neues "tools" Verzeichnis, in dem jetzt
Franks Progamm zum Vergößern von Images zu finden ist. Da das Programm
jetzt mit E5 Hex statt mit Nullen füllt, kann man es auch zum Erzeugen
neuer Images verwenden. Unter Linus geht das z.B. so:
Unter Windows müßte es so ähnlich auch gehen. Falls es dort kein 'expr'
oder ähnliches gibt, muß man die Größe selbst ausrechnen.
Das Resultat kann man in eine CP/M- oder unter passendem Namen, in eine
FAT16- Partition kopieren, und man hat ein frisch formatiertes CP/M
Dateisystem.
Außerdem gibt es noch ein Verzeichnis 'avrvga', das für die
Terminalsoftware von Frank vorgesehen ist. (Änderungen vorbehalten)
Hallo Frank,
welchen Font-Editor hast Du benutzt? Ich habe mal einige
Zeichen von Hand geändert (Bleistift und Papier). Aber bei
6 Pixel Breite hat man natürlich keine große Auswahl.
Typografisch ist was anderes.
Gruss
Peter
Halloe.
Heute habe ich mich erstmal ein wenig um die Terminalemulation
gekümmert. Am Bildschirmende wird nun nicht mehr einfach der ganze
Bildschirm gelöscht. Statt dessen Scrollt der ganze Bildbereich nun eine
Zeile aufwärts. Hier habe ich leider noch ein sehr eckliges Flackern
beim Scrollen, das ich noch nicht weg bekommen habe.
Auch um die Tastaturanbindung habe ich mich schon ein wenig kümmern
können. Bisher habe ich die Interruptroutine auch noch nicht ans laufen
bekommen. Im moment plagt mich noch die befürchtung, das der
Tastaturinterrput evtl. den gesammten Bildaufbau durcheinander bringen
könnte bei jedem Bit, das die Tastatur an den Controller schickt. Leider
habe ich hier weder ein Osziloskop noch einen Logiganalyzer, so das ich
im moment ein wenig im dunkeln stochere was das Problem angeht.
Grüße
Frank
Frank Zoll schrieb:> Auch um die Tastaturanbindung habe ich mich schon ein wenig kümmern> können. Bisher habe ich die Interruptroutine auch noch nicht ans laufen> bekommen. Im moment plagt mich noch die befürchtung, das der> Tastaturinterrput evtl. den gesammten Bildaufbau durcheinander bringen> könnte bei jedem Bit, das die Tastatur an den Controller schickt. Leider> habe ich hier weder ein Osziloskop noch einen Logiganalyzer, so das ich> im moment ein wenig im dunkeln stochere was das Problem angeht.
Du willst für die Tastatur einen interruptgesteuerten Software-UART
benutzen? Ich weiß nicht wie es bei dir jetzt aussieht, aber in meinem
Code war während einer Videozeile kein einziger Takt übrig. Deshalb habe
ich die Arbeit einem Hardware-UART überlassen und nur in der
horizontalen Austastlücke ggf. ein empfangenes Byte zwischengespeichert.
Wenn du auf jedes Bit reagieren musst, wird das nicht reichen.
Sebastian
Hallo Sebastian.
Ja, ich muss die Arbeit notgedrungener Massen selber machen. Der 168er
AVR Controller hat leider nur einen UART. Und der ist bereits für die
Verbindung zwischen dem VGA- Teil und dem CP/M Emulator belegt. Im
moment gehe ich davon aus, das ggf. jedes einzelne Bit das von der
Tastatur kommt alles durcheinander bringen könnte, wenn der Interupt
wärend der Pixelausgabe zuschlägt. In der vorliegenden Hardware ist der
Clockausgang der Tastatur mit dem INT1- Eingang des Controllers
verbunden. Im moment versuche ich gerade diesen Interrupt überhaupt
erstmal ans laufen zu bekommen. Soweit meine Rechergen ergeben, sendet
eine Standarttastatur mit einer Taktrate von 20 bis 30 Khz. Bei der
derzeitigen Auflösung mit 400 aktiven Zeilen bei 74HZ, hätten wir
rechnerisch 29,6 KHz abtastfrequenz, wenn wir es schaffen wären des
horizontales Blanks jeweils einen Tatsaturtakt abzuarbeiten. Das könnte
gerade so eben hinkommen würde ich sagen. Ich weiss nur noch nicht, wie
ich den Intterupt so lange heraus zögern kann, bis eine Grafikzeile
vollständig abgearbeitet wurde. Gänzlich verschlucken darf ich dabei ja
auch keinen einziegen Takt, sonst komme ich bei der Verarbeitung der
Datenbits durcheinander. Bin mal gespannt, ob ich das ganze irgendie in
den Griff bekomme.
Grüße
Frank
Die Verzögerung des INT1 passiert ganz von alleine:
Die Videozeile wird in einer ISR ausgegeben. Tritt während diese ISR
läuft der ext. Interrupt auf, wird nur das entsprechende INT1
Interrupt-Flag gesetzt. Die INT1 ISR wird erst ausgeführt wenn die Video
ISR zurückkehrt.
Da Zeilen- und Tastaturtakt aber nicht synchron sind, wird früher oder
später einen Takt verloren gehen.
(Verschachtelte Interrupts gehen auch, hab ich noch nie benutzt:
http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html )
Nur mal so der Neugierde habler......
640x400 Pixel heisst doch 640 / 8 = 80 Zeichen.
400 / 8 = 50 Zeilen.
Ein Zeichen besteht also aus einer 8x8 matrix.
Bei dieser werden nur die Bits xx543210 horizomtal verwendet.
Bit 76xxxxxx sind die Zwischenräume der Zeichen.
In der vertikalen werden nur die Zeilen 0,1,2,3,4,5, und 6 verwendet.
Zeile 7 ist der Abstand zwischen den Zeilen.
Also besteht ein Zeichen eigentlich aus einer 6x7 Matrix.
z.B. xx543210xx543210
1111 1111 = 0x3C,0x3C
1 1 1 11 = 0x41,0x13
1 1 1 11 = 0x41,0x13
111111 11111 = 0x3F,0x3E
1 1 1 11 = 0x41,0x13
1 1 1 11 = 0x41,0x13
1 1 1111 = 0x41,0x3C
= 0x00,0x00
Bei 25Mhz Taktung gehen nur die 640x350, 640x400 und 640x480 Modis.
80x43 80x50 80x60
Wollt ihr die uVGA auf 80x25 umstellen?
h3aau schrieb:> Bei 25Mhz Taktung gehen nur die 640x350, 640x400 und 640x480 Modis.> 80x43 80x50 80x60> Wollt ihr die uVGA auf 80x25 umstellen?
Geplant war 640x400 also 80x50 und dann jede zweite Zeile frei, also 80
Zeichen zu 25 Zeilen. Mehr geht eh nicht in den RAM.
Halloe.
Wir haben auf 80*24 Zeichen umgestellt mit einem neuen Font von 6(Breit)
* (16) Hoch Pixeln größe. Wobei nach jedem 6 Pixel breiten Zeichen 2
schwarze Pixel gesendet werden. 25 Zeilen passen nicht in den Speicher,
weil dies mit den benötigten Variablen für den UART und den Keyboard-
Puffer sowie die globalen Statusvariablen und den Stack kollidieren
würde. Die Auflösung bleibt aber 640*400 wobei die letzten 8 Zeilen
einfach nur schwarz ausgebeben werden.
Grüße
Frank
p.s. Für den Tastaturanschluss siehts ganz düster aus. Der Interrupt
haut wenn er prio bekommen würde 2 mal pro Bidlschirmzeile rein und
würde das ganze Bild durcheinander bringen. Und da die Clockerzeugung
von der Tastatur vorgegeben wird, können wir darauf keinen Einfluss
nehmen.
Halloe.
Ja das mit den unterlängen geht Problemlos. Ich habe es bei meinem Font
auch so gemacht. Die "Nulllinie" liegt dort auf der 12. Zeile. So sehen
die Buchstaben nacher im Display recht gut aus. Nur so Buchstaben wie W
und M die eigentlich besonders breit sind sehen bei 6 Punkten breite
nicht berauschend aus. Aber Lesbar ists auf jeden Fall geworden würd ich
sagen.
Ach ja, nochwas. Da CP/M Terminals nur 7bit ASCII- Codes verwendet
haben, habe ich das 8. Bit dafür genutzt Inverse Zeichen möglich zu
machen. Dazu habe ich alle Zeichen von 0-127 in den Bereich 128-255
kopiert und die Bits negiert. So kann ich spähter zumindest das Attribut
"invers" mit unterstützen. Wahlweise hätte man auch "unterstrichen"
nehmen können. Blinken z.B. würde nicht gehen, da wären der Ausgabe der
Pixel kein einzieger Tackt mehr für Sonderfunktionen über ist.
Grüße
Frank
Hallo
fzoll schrieb:> Für den Tastaturanschluss siehts ganz düster aus. Der Interrupt> haut wenn er prio bekommen würde 2 mal pro Bidlschirmzeile rein und> würde das ganze Bild durcheinander bringen. Und da die Clockerzeugung> von der Tastatur vorgegeben wird, können wir darauf keinen Einfluss> nehmen.
es gibt eine möglichkeit der Tastatur zu sagen das der Atmel nicht
bereit ist Daten aufzunehmen und die werden dann in der Tastatur
zwischengespeichert.
siehe Link.
http://www.marjorie.de/ps2/ps2_protocol.htm
Kommunikation: Allgemeine Beschreibung
PS/2 Mäuse und Tastaturen benutzen ein bidirektionales, synchrones
serielles Protokoll. Im Ruhezustand sind beide Busleitungen High. Nur in
diesem Zustand darf die Tastatur/Maus mit der Datenübertragung beginnen.
Der Host hat die absolute Kontrolle über den Bus und darf die
Kommunikation jederzeit unterbrechen, indem er die Clockleitung auf Low
zieht.
oder...
http://www.beyondlogic.org/keyboard/keybrd.htm
Keyboard to Host
...
The keyboard is free to send data to the host when both the KBD Data and
KBD Clock lines are high (Idle). The KBD Clock line can be used as a
Clear to Send line. If the host takes the KBD Clock line low, the
keyboard will buffer any data until the KBD Clock is released, ie goes
high. Should the Host take the KBD Data line low, then the keyboard will
prepare to accept a command from the host.
Gruß Egmont
fzoll schrieb:> Für den Tastaturanschluss siehts ganz düster aus. Der Interrupt> haut wenn er prio bekommen würde 2 mal pro Bidlschirmzeile rein und> würde das ganze Bild durcheinander bringen. Und da die Clockerzeugung> von der Tastatur vorgegeben wird, können wir darauf keinen Einfluss> nehmen.
Einfach mal eine Idee.
A.)
Tasttatur auf der VGA Platine kommt an die Hardware UART und die
Verbindung zum CP/M System erfolgt über eine Soft-UART analog der schon
realisierten.
B.)
Auf dem CP/M System sind ja noch zwei Leitungen frei. Über diese beiden
Leitungen wird die Tastatur angeschlossen. Da Sie beide am
Verbindungssteckverbinder anliegen, sollte das ohne großen
Hardwareänderungsaufwand zu realisieren sein.
Joe
Hallo Egmont und Joe.
Leider ist die Idee von Egmont nicht brauchbar. Das Problem ist, das die
tastatur zu langsam wäre die gesammten 11 Byte eines Zeichens wärend des
Vertical- Syncs zu senden. Und man kann die Übertragung nicht
mittendrinn anhalten. Sobald der Host (VGA-Contrloller) sagen würde, das
er nicht mehr zum Empfang bereit ist, wird nach Standard die Übertragung
komplett abgebrochen. Eine Pause ist im Protokoll nicht vorgesehen.
Leider.
Joe's Ideen an den UARTS und der Platine etwas zu verändern würden wohl
am meisten bringen.
Meine Idee ziehlt aber eher gerad in eine etwas andere Richtung. Ich
wollte die schöne Platine nicht "kaputt" machen. Statt dessen denke ich
gerade darüber nach mir einen ganz kleinen AVR- Controller auszusuchen
und ihn einfach als "Adapter" zwischen den VGA- Controller und die
Tastatur zu hängen. Dieser hätte dann genügend Zeit um alle Zeichen, die
die Tastatur sendet, zwischen zu Puffern. Und die beiden bestehenden
Datenleitungen aus dem PS/2 Port der Platine würde ich dann nutzen um
vom Adaptercontroller die Bits stück für stück abzuholen. Wobei ich dann
den Tackt wärend der horizintalen Sync- Zeiten auf seiten des VGA-
Controllers generieren würde.
Wenn wir es schaffen, da einen 4Pinner zu finden und zu Programmieren,
dann könnte man das Teil super einfach mit ein wenig Schrumpfschlach in
ein kleines Adapterkabel einbauchen und wird müssten die schöne Platine
nicht patchen.
Für eine Neuauflage würde ich das ganze dann gleich etwas anders
desigenen. Ich würde für den VGA- Teil einen Propeller Chip nehmen, der
hätte genügend Power um VGA/TV, sammt Tastatur und Maus zu händeln.
(DIP40 Gehäuse). Da wären dann auch die VT100- Attribute möglich. auch
in hochen Auflösung....
Grüße
Frank
PS2 komplett innerhalb des Zeilen-Sync zu machen geht nicht.
Vorschlag:
Da eine Zeile aber c.a. 25us dauert kann man 1/2 Bit pro Zeile
bearbeiten.
Dieses kann innerhalb des Zeilen-Sync erfolgen.
Also innerhalb des Zeilen-Sync eine halbe Clock-Phase für PS2 erzeugen,
und so jede zweite Zeile ein Bit lesen oder senden.
Der PS2 Byte-Transfer könnte auch Bild-Syncron starten, das wäre immer
noch schnell genug.
Hallo
h3aau schrieb:> Also innerhalb des Zeilen-Sync eine halbe Clock-Phase für PS2 erzeugen,
Zitat von http://www.marjorie.de/ps2/ps2_protocol.htm :
--------
Das Clock-Signal wird immer von der Tastatur/Maus erzeugt, aber der Host
hat die Kontrolle über die Kommunikation.
...
Die Clockfrequenz muß im Bereich von 10-16,7 kHz liegen. Das heißt, das
Clock-Signal muß für 30-50 µs High und für 30-50 µs Low sein.
--------
Wenn eine Zeile 25 µs dauert kann man dann nicht nach jedem Ende Clock
und Data auswerten? Bei 11 bit sollte man das synchron hinbekommen.
fzoll schrieb:> Das Problem ist, das die> tastatur zu langsam wäre die gesammten 11 Byte eines Zeichens wärend des> Vertical- Syncs zu senden.
Wieviel Zeit hat man in der Bild-Synchronisation.
oder...
gibt es die Möglichkeit ein Bildaufbau auszulassen ??
Gruß Egmont
Halloe.
Leider kann der HOST den PS/2 Clocktackt nicht beeinflussen. Das Clock-
Signal wird von der Tastatur generiert. Die Geschwindigkeit schwankt
hier je nach Tastatur zwischen ca. 10kHz und 30kHz. Man könnte nun
natürlich eine Suche starten und schauen ob man eine Tastatur finden
kann, dessen Clock-Signal zu unserem VGA- Signal "compatibel" ist.
Man kann auch kaum voraus sagen, wann die Tastatur ein Bit
senden/empfangen möchte. Im Grunde genommen startet der Tastaturclock in
dem moment in dem man eine Taste drückt. Kurze verzögerungen innerhalb
des Controllers mal ausser acht gelassen.
Diesen Start kann man unterbinden und hinauszögern, indem man dies per
Busy-Signal meldet. Wenn der Start aber erstmal erfolgt ist, würde das
melden des Busy- Signals aber nur den abbruch der aktuellen Übertragung
bewirken. Einigen Tastaturen soll das setzen des Busy- Signals sogar
egal sein, sie senden dann einfach weiter. Die Folge wäre ein
Datenverlust.
Ich habe mal versucht, meiner Tastatur ein Clock-Signal durch den Host
generiert aufzuzwingen. Am Ende kam dabei aber nur Datenschrott zu
stande, weil die Tastatur immer wieder ihre Übertragung abgerochen und
neu gestartet hat und ich somit immer wieder die ersten Bits der 1.
gedrückten Taste zu sehen bekahm.
Grüße
Frank
Halloe.
Ich spiele gerad mit dem Gedanken, das PS/2 Keyboardproblem durch den
Einsatz eines weiteren Controllers zu erschlagen. Anbei ein kleines
Schema von dem was ich mir vorstelle. Ich denke darüber nach, einen
kleinen 8Pinner AVR Controller in die Leitung zwischen der PS/2 Buchse
auf der Platine und der Tastatur zu einzubringen. Ich würde die
Clockleitungen beider Seiten auf Interrupt- Eingänge des AVR-
Controllers legen und die 2 Datenleitungen auf die übrigen Pins
verteilen.
Nun könnte man den AVR- Controller so Programmieren, das er auf der
einen Seite Datenbytes der Tastatur mit der geschwindigkeit, wie sie
durch die Tastatur festgelegt wird empfangen kann. Diese Bytes könnte
der Controller dann in seinem SRAM zwischenspeichern, bis sie durch den
VGA- Controller auf unserer Platine abgeholt werden. Hierzu würde ich
den VGA- Controller ebenfalls einen Tackt ausgeben lassen. Das
Tacksignal könnten wir dann relativ problemlos in der HSYNC- Phase
erzeugen lassen. Wir könnten auf geraden Ausgabezeilen einen Tackimpuls
erzeugen und auf ungeraden Zeilen die Daten entgegen nehmen. So könnten
wir dann am Ende die Datenbytes stück für stück vom "Puffercontroller"
abholen. Ein weiterer Vorteil wäre, das der Puffercontroller je nach
größe bis zu 512 Zeichen Puffer bereit stellen könnte. Im moment denke
ich an einen ATtiny45 für knapp 1,82€, welcher uns einen 256 Byte Puffer
schenken würde und leicht zu beschaffen ist.
Was ich daran nett finde ist, das wir dafür an der Platine keine
Änderungen vornehmen müssten. Und auch der Geldliche Aufwand wäre ja
minimal. (1 Stecker, 1 Buchse, der ATtiny Controller, ein Kerko und ein
Widerstand). Das ganze sollte sich recht einfach "fliegend" aufbauen
lassen.
Was haltet ihr von der Idee, wäre das eine nette Lösung für das
Keyboard- Problem ?
Freundliche Grüße
Frank
Hallo Frank
Egmont schrieb:> gibt es die Möglichkeit ein Bildaufbau auszulassen ??
Hier noch mal eine genaue Erklärung was ich damit meinte...
bei einer Vertical Frequency von ca. 70Hz kann man da nicht ein
komplette Bildaufbau auslassen. Mit auslassen meine ich keine Daten
ausgeben nur Hsync und Vsync.
Ein Bildaufbau dauert 12 ms (Active video time)soviel Zeit hat man die
Tastatur auszulesen.
- der Tastatur durch setzen von Clock auf High signalisieren das man
bereit ist Daten aufzunehmen.
- Daten einlesen (Tastatur kann 16 Byte im eigenem Buffer aufnehmen)
- Clock auf Low setzen.
- Bilddaten 69 mal ausgeben... und so weiter.
Ein Bildaufbau aussetzen (dunkel) sollte man eigendlich nicht merken.
Was meinst du, ist das machbar ?!?
Gruß Egmont
Hallo Egmont.
Einen Bildaufbau bei Bedarf aus zu lassen wäre wohl Problemlos möglich.
So lange die SYNC- Signale trozdem erzeugt werden, sollte der Monitor
nicht aus dem Tackt kommen. Damit hätte man eine Menge freier
Prozessorzeit über, um Daten von der Tastatur einzulesen. Das ganze wird
wohl ein bissel Tricky, ich könnte mir aber vorstellen das das machbar
wäre.
Freundliche Grüße
Frank
@fzoll
eine Tastaturlösung mit eigenem Kontroller hab ich fertig hier liegen..
nur der Reiz wäre schon Tastatur und VGA auf einem Chip...
Allerding sollte es nicht funktionieren...
gruß
Hans- Werner
Wäre folgendes für den VGA-Kontroller möglich:
Tastatur über seriellen Port anschließen. Die Verbindung zum
CPM-Prozessor mit zwei freien Portpins herstellen und eigenes, I2C
ähnliches ( synchrones Protokoll ) implementieren.
Noch ein Vorschlag (habt ihr aber sicher auch schon dran gedacht..)
Wenn der VGA-AVR das nicht mehr sauber packt.. dann den CP/M AVR nehmen
und
die 2 KBD Leitungen halt umlegen..
Peter
Frank Zoll schrieb:> Was haltet ihr von der Idee?
Wie im richtigen Leben gibt es für jede Lösung Pro und Contra. Ein ganz
wichtiges Argument: „Die schöne Platine nicht kaputt zu machen“ Da geht
eigentlich nichts drüber!
Doch nun weg von den emotionalen und hin zu den sachlichen Argumenten.
Soll die VGA Karte als eigenständiges „Terminalmodul“ fungieren, so ist
eine einfache universelle Schnittstelle immer von Vorteil. Das ist mit
der derzeitigen V24 gegeben. Würde die Tastatur über die beiden I2C
Leitungen der AVR CP/M Platine abgefragt, so wäre das ein Systembruch im
Sinne eines eigenständigen Terminals. Die Lösung von Frank einen
Attiny45 zu nehmen hat auch ihren Charme. Damit könnten sogar solche
Kunstwerke wie die Logitech diNovo Mini™ adaptiert werden.
Joe
Halloe.
Ich habe Egmont's Idee einmal zum Testen umgesetzt. VGA und Tastatur
lassen sich nun zusammen mit dem Terminal betreiben. Und das ganz ohne
Änderungen an der Platine oder zusätzliche Hardware.
Um das ganze recht einfach zu halten, habe ich es so umgesetzt, das
jedes 32. Bild ausgelassen wird, um die Tastatur zum Zug kommen zu
lassen. Auf meinem 17Zoll-Monitor ist das Auslassen eines Bildes
deutlich als Flackern erkennbar. Ob ich damit Stundenlang arbeiten
möchte, lasse ich einfach mal dahin gestellt.
Mal schauen, ob man es noch ein wenig weiter Verbessern kann. Anbei mal
die aktuelle Version für euch zum Rumspielen.
Freundliche Grüße
Frank
p.s. Ich habe längst noch nicht alle VT100 - Kommandos umgesetzt, mir
war erstmal wichtiger VGA und Tastatur ans laufen zu bekommen.
Halloe.
Da die Idee mit dem Auslassen eines ganzen Bildes recht gut Funktioniert
hat, habe ich mal versucht das ganze so Umzustricken, das es komplett
während der VSYNC- Zeit läuft. Dies hat mit meiner Tastatur leide rnicht
funktioniert. Es kahm kein einziges Byte mehr rüber. Danach habe ich mal
versucht, die Zeit der letzten 16 Zeilen, die eh nicht ausgegeben
werden, mit dazu zu nehmen. Nun konnte ich zwar ein paar Zeichen
empfangen, hatte aber immer wieder Übertragungsfehler. Mal schauen, was
sich da noch machen läßt.
Habt ihr vieleicht noch Ideen ?
Ach ja, einen seltsamen Fehler habe ich auch noch beobachten können. Mit
dem "BDOS" zusammen Funktioniert es eigentlich supi. Aber wenn man
Programme läd, gehts nicht mehr richtig. Konkrett die RETURN- Taste
schein nicht mehr abgefragt zu werden. Bei ZORK und MBASIC kann man zwar
munter etwas eintippen, aber wenn man RETURN drückt passiert nichts. Ich
vermute mal, das es noch fehler in der VT100 Emulation sind, die wir
noch beseitigen müssen.
Grüße
Frank
Hallo Frank
Frank Zoll schrieb:> Habt ihr vieleicht noch Ideen ?
Wenn in den letzten 16 Zeilen nichts mehr ausgegeben wird, sollte man da
schon KB-Clock auf High setzen, wenn jetzt die Tastatur antwortet, also
Daten hat, ein Bildaufbau komplett auslassen. Wenn in der Zeit nichts
kommt, Bildaufbau normal ausgeben. Das heist das Bild "flackert" nur
wenn man eine Taste drückt.
16 Zeilen * 25µs = 400µs -->
Clock muss für min 50µs High sein bevor Tastatur sendet. Also schafft es
die Tastatur in der Zeit von 350µs zu signalisieren das sie Daten hat.
Das bedeutet auch das man 70 mal in der Sekunde versucht die Tastatur
abzufragen ( ob was im KB-Buffer ist) ....
ist besser als....
2 mal in der Sekunde abzufragen und ein Bildaufbau auslassen (und dann
hat der User noch nicht mal eine Taste gedrückt.... dumm gelaufen).
Egmont
Hallo Frank,
Frank Zoll schrieb:
> Habt ihr vieleicht noch Ideen ?
Alles in der VSYNC-Zeit zu schaffen, wäre schon ideal. Wäre es nicht
denkbar, vom Modus 640x400@70Hz auf 640x480@60Hz zu gehen? Horizontal
bleibt alles gleich, es kommen nur 80 schwarze Pixelzeilen dazu. Grob
überschlagen hätte man dann pro Bildaufbau etwa 4.3ms Zeit für
Keyboardroutinen, während es bei 640x400 nur ca. 2ms sind.
Ich kann mir vostellen, dass die derzeit 2ms zu wenig sind, um eine
Tastaturantwort entgegenzunehmen. Teilweise sind die Make/Breakcodes
auch 2 oder 3 bytes lang, welche man von der Tastatur ohne Unterbrechung
entgegennehmen muß.
Viele Grüße, Thomas
Hallo Thomas.
Ich habe deinen Vorschlag ausprobiert. In der aktuellenb SVN- Version
ist die Auflösung nun 640*480 Pixel bei 60Hz(62Hz zeigt meine Monitor
an).
Die Keyboardroutinen laufen nun vollständig wärend der Zeit in der keine
aktive Videoausgabe erfolgt. Von 480 Zeilen werden nur 384 Zeilen
ausgegeben. Den rest der Zeit hat nun die Keyboardroutine um Zeichen zu
empfangen. Damit konnten wir das auslassen ganzer Bilder nun erfolgreich
"wegoptimieren".
Das Bild bleibt nun recht stabiel. Flakern tut's im moment nur beim
scrollen, da werde ich als nächstes mal drauf schauen.
Grüße
Frank
Hallo,
habe folgendes Problem mit meiner AVR-VGA.
Signal ist vorhanden wenn ich mit dem Oscilloscope nachmesse.
wenn ich den Monitorstecker drauf stecke wird das Signal über die 470
Ohm Widerstände auf 0,7 Volt gezogen aber Monitor zeigt kein Bild an.
Habe ein TFT und Röhrenmonitor ausprobiert beides das gleiche.
TFT schreibt das ein Eingangspegel vorhanden ist (Hsync unf Vsync).
>>>>> Sollte soweit doch Richtig sein ...oder mache ich da ein Denkfehler !
Laut Google erwartet Pin RGB 0,7 Vss und eine Impedanz von 75 Ohm.
Kommunikation von Tastatur zu CP-M funktioniert.
CP-M zu VGA kann ich jetzt noch nicht sagen aber aus PortC kommen Daten.
Habt ihr ein Tipp für mich woran das liegen könnte.
Gruss Egmont
Egmont schrieb:> Habt ihr ein Tipp für mich woran das liegen könnte.
Hast auch mal am Ausgang des Schieberegisters gemessen ob überhaupt
Pixeldaten kommen?
Joe
Hallo,
TFT läuft jetzt nachdem ich umgestellt habe auf neue Software (640x480)
Was mir noch aufgefallen ist, der TFT sagt mir unter Info das er eine
Auflösung von 848x480@62Hz gefunden hat... und die Zeichen sehen nicht
besonders schön aus.
Röhre sagt immer noch nichts !
Meine Vermutung ist, das die Röhre diese Auflösung nicht kann.
Was sagt eure Info vom Monitor ?
Gruss Egmont
Egmont schrieb:> Was sagt eure Info vom Monitor ?
640x480@60Hz
Deine Anzeige von 848x480@62Hz sieht nach einem unsauberen Syncronimpuls
aus.
Egmont schrieb:> und die Zeichen sehen nicht besonders schön aus.
Das passiert, wenn die Pixelauflösung des LCD nicht mit der der VGa
übereinstimmt.
Hallo Egmont.
Beide Versionen 640*400 und 640*480 habe ich auf einem alten
Röhrenmonitor getestet. Der iiyama Visionmaster Pro410 hatte keine
Probleme mit der Anzeige, obwohl der Pixeltakt nicht genau genug ist.
(62 statt 60 bzw. 74 statt 70 Hz).
Ich habe die neue Version mal auf einem "neueren" TFT Monitor
ausprobiert, um zu schauen ob evtl. neuere Monitore mit der krummen
Auflösung schwierigkeiten haben. Mein Samsung SyncMasterT220HD
(BreitbildMonitor) hat keine Probleme, die Auflösung 640*480 @ 62HZ
wieder zu geben. Der Font mit 6(8)* 16 Pixeln sieht sogar recht nett
aus, weil der Monitor das Bild netterweise in der Breite für mich
gestreckt hat.
Wie siehts den sonst so bei den anderen aus ? Habt ihr evtl. auch
Monitore, die es Stört das der Pixeltakt nicht genau genug ist für
640*480@60Hz ?
Grüße
Frank
"VGA industry standard" 640x480 pixel mode
General characteristics
Clock frequency 25.175 MHz
Line frequency 31469 Hz
Field frequency 59.94 Hz
One line
8 pixels front porch
96 pixels horizontal sync
40 pixels back porch
8 pixels left border
640 pixels video
8 pixels right border
---
800 pixels total per line
One field
2 lines front porch
2 lines vertical sync
25 lines back porch
8 lines top border
480 lines video
8 lines bottom border
---
525 lines total per field
Hallo
mit folgenden Werte habe ich ein besseres Bild bekommen
und die Info sagt 640x480@60Hz:
----[ global.h ]--------------------------------------------
#define H_FRONT 8 //2 // front porch
#define H_SYNC 10 //12 // sync pulse -- NEGATIVE polarity
#define H_BACK 6 // back porch
#define H_ACTIVE 80 // active video
#define H_TOTAL (H_SYNC+H_BACK+H_ACTIVE+H_FRONT)
#define H_CHARS H_ACTIVE
// unit: LINES
#define V_FRONT 5 //11 // front porch
#define V_SYNC 2 // sync pulse -- POSITIVE polarity
#define V_BACK 31 // back porch
#define V_ACTIVE 480 // active video
#define V_TOTAL (V_SYNC+V_BACK+V_ACTIVE+V_FRONT)
#define V_CHARS 24
-----------------------------------------------------------
Dazu habe ich festgestellt,
wenn man wie ich beide Atmel mit 25Mhz betreibt,
ein besseres Bild bekommt wenn man nur ein Quarz benutzt
(Jumper JP10 auf 1-2).
Gruss Egmont
Egmont schrieb:> Dazu habe ich festgestellt,> wenn man wie ich beide Atmel mit 25Mhz betreibt,> ein besseres Bild bekommt wenn man nur ein Quarz benutzt> (Jumper JP10 auf 1-2).
Dieser Effekt ist dem Entwicklungsboard geschuldet. Die AVR's sind nicht
besonders "EMV freundlich" In einem Industrieprodukt würde meine
Stromversorgungsvariante der beiden AVR's durchfallen. Ich hatte bewußt
auf die Drosseln verzichtet. So schlägt der Takt recht stark auf die
Stromversorgung durch. Bei nur einer Taktversorgung wenigstens nur mit
der einen Frequenz. Asche auf mein Haupt! Das nächste Board bekommt ein
EMV gerechteres Design.
Halloe.
Ich habe mal wieder ein kleines Update der Software für den
VGA/Keyboard- Teil des aktuellen Boards auf den SVN- Server hochgeladen.
Mit dem aktuellen Update sind nun die ersten VT100/VT52 Funktionen
implementiert. Die Tasten RETURN und BACKSPACE tun nun was sie sollten.
Damit läßt sich nun auch endliche eine Partie "ZORK1" auf dem Board
spielen. Der Cursor wird nun auch endlich korrekt angezeigt. Die
Tastaturroutinen laufen nun, ohne das ganze Bilder ausgelassen werden
müssen. Durch auslassen der Darstellung der letzten 96 Bildzeilen
konnten die Tastaurabfragen ans laufen gebracht werden. Das ganze ist
etwas "schwammig" und sicher nicht für Actionspiele geeignet, aber
immerhin tut's jetzt einigermaßen.
Grüße
Frank
Hallo Frank,
das mit dem svn Server ist sehr umständlich besser wäre den jeweiligen
stand zu posten...
leider konnte ich die Quellen auch nicht ohne Fehler übersetzen.??
Build started 2.11.2010 at 17:52:56
avr-gcc -mmcu=atmega328p -Wall -gdwarf-2 -std=gnu99
-DF_CPU=25000000UL -Os -funsigned-char -funsigned-bitfields
-fpack-struct -fshort-enums -MD -MP -MT dmm_vga.o -MF dep/dmm_vga.o.d
-c ../dmm_vga.c
../dmm_vga.c: In function '__vector_7':
../dmm_vga.c:45: error: 'PB3' undeclared (first use in this function)
../dmm_vga.c:45: error: (Each undeclared identifier is reported only
once
../dmm_vga.c:45: error: for each function it appears in.)
../dmm_vga.c: In function '__vector_12':
../dmm_vga.c:150: error: 'PB2' undeclared (first use in this function)
../dmm_vga.c: In function 'main':
../dmm_vga.c:215: error: 'PD5' undeclared (first use in this function)
../dmm_vga.c:215: error: 'PD6' undeclared (first use in this function)
../dmm_vga.c:215: error: 'PD7' undeclared (first use in this function)
../dmm_vga.c:222: error: 'PB0' undeclared (first use in this function)
../dmm_vga.c:222: error: 'PB2' undeclared (first use in this function)
../dmm_vga.c:225: error: 'PB1' undeclared (first use in this function)
../dmm_vga.c:226: error: 'PB3' undeclared (first use in this function)
make: *** [dmm_vga.o] Error 1
Build failed with 11 errors and 0 warnings...
Gruß
Hans-Werner
Hallo Hans Werner.
Sorry, im moment komme ich hier zu fast gar nichts mehr. Daher hier erst
verspähtet meine Antwort.
Ich nutzte unter WindowsXP den SVN- Client Tortoise. Mit dem kann man
eigentlich Problemlos auf den SVN- Server zugreifen und Updates ziehen
geht dort ganz einfach über einen "rechtsclick" auf das Verzeichniss und
die Auswahl des Punktes "SVN Update".
Ich kann die Zwischenstände auch hier im Thread Posten, habe es aber
bisher vermieden, um den Server nicht unnötig mit Alpha & Betha-
Versionen vollzumüllen. Mein Vorschlag wäre, erstmal noch bei dem SVN-
Server zu bleiben und erst die fertige Version des VGA- Terminals hier
für alle nochmal zu posten. Ich habe auch keine Probleme euch gezipte
Dateien auf Anfrage per E-Mail zukommen zu lassen. Was meint ihr ?
Was aber das Problem mit dem Compilieren angeht, so habe ich es gerad
nochmal ausprobiert. Die aktuelle SVN- Version läßt sich ohne Fehler
übersetzen. Ich denke das Problem das Du da hast, ist evtl. das gleiche
das ich auch beim ersten Compilieren der "Urversion" hatte. Ich hatte
eine etwas ältere Version von AVR-GCC installiert. Diese Version kannte
aber den 328er AVR noch nicht und hatte daher nicht die passenden
Includes mit den Daten der Anschlußpins. Nach einem Update auf die
Version "WinAVR-20100110" hat es dann bei mir aber Funktioniert. Schau
am besten einmal nach, welche Version dort Installiert ist.
Zum "aktuellen" Stand kann ich sagen, das ich als nächtes vor habe die
VT100 Emulation weiter aus zu bauen. Im moment habe ich hier lokal
bereits eine Version mit fertiger aber noch ungetesteter VT52 Emulation.
Meine Planung sieht vor, die Emulation zwischen VT52 und VT100/102 per
F12- Taste umschaltbar zu machen. Im moment komme ich nur nich zum
Programmieren.
Die VT52 Emulation ließ sich viel leichter Umsetzen als die VT100/102
Emulation, weil die Steuersequenzen deutlich kürzer und viel einfacher
aufgebaut sind. Bei VT52 kann immer nur ein Commando mit fester
Parameteranzahl nach dem ESCAPE kommen. Bei VT100/102 kann man praktisch
beliebieg viele "Variablen" nach dem ESCPAPE senden und dann ganz am
Ende sagen, welcher Befehl mit diesen Parametern auszuführen ist.
Außerdem werden die Variablen bei VT52 praktisch "binär" als einzelnes
ASCII- Zeichen gesendet, von dem man dann nur noch eine Constante
abziehen muss um auf den richtigen Wert zu kommen. Bei VT100/102 kommen
die Variablen als String und müssen erst noch interpretiert werden. Das
ganze wird mich wohl noch eine ganze Zeit lang beschäftigen, bis es
einigermaßen zufreidenstellend läuft.
Freundliche Grüße
Frank
In den letzten Tagen habe ich die Terminal- Emulation stark erweitert.
Die aktuelle Version findet sich wie immer auf dem oben verlinkten SVN-
Server. ( http://cloudbase.homelinux.net/svn/avr-cpm )
Unter anderem neu sind:
- Eine ADM-3A Emulation steht nun auch zur Auswahl.
- Umschaltung der Emualtionen VT52/VT100/ADM3-A per F11
- Umschaltung der Schriftfarbe per F12
- Fast alle ESCAPE- Codes des ADM-3A Terminals wurden implementiert. (
Ausnahmen: Auflösungswechsel, Testmodus und Baudratenänderung )
- Unterstüzt die Font- Umschaltung auf einen 2. Font.
( Derzeit wird hier nur zwischen 2 sehr ähnlichen Fonts umgeschaltet)
Was fehlt noch ?
- Jemand der Lust hat alle ESCAPE- Sequencen des ADM-3A Terminals
auszuprobieren und ggf. Fehler zu melden. Schön wäre ein MBASIC-
Programm, mit dem man alle Codes ausprobieren kann, damit der Fehler
leichter nachzustellen ist.
- Den beiden Fonts fehlen noch die Grafikzeichen, derzeit werden
Graphiczeichen als Leerräume dargestellt. Mag hier wer die fehlenden
Zeichen hinzu fügen ?
- Die VT52 und die VT100 ESCAPE- Sequencen werden noch nicht vollständig
beherscht.
Freundliche Grüße
Frank
Hallo Peter,
ich hab deine Version mal getestet... leider scheinen die Zeitprobleme
sich auszuweiten... bei der Bildschirmausgabe (dir) fehlen teilweise
Zeichen und bei der Tastatureingabe hakt es nach wie vor... Die
Terminalemulation hab ich nicht getestet...
Gruß
Hans- Werner
Halloe.
Ich glaube ich konnte das Problem der verlorenen Zeichen vom CP/M Kern
an das Terminal weiter einkreisen. Mir ist das ganze bisher im Test noch
nicht aufgefallen. Das könnte evtl. daran liegen, das ich den CP/M Teil
nur mit 20Mhz laufen lasse. Solltest Du den CP/M Kern übertacktet haben,
so wäre der ja etwas schneller als meine Version, so das das unten
Beschriebene Problem dann mit einer größeren Warscheinlichkeit auftreten
könnte. Ich versuchs auf jeden Fall mal nachzustellen.
Hier meine Vermutung:
Es könnte daran liegen, das während der V-SYNC Phase keine Zeichen von
der Seriellen Schnittstelle zum CP/M System abgeholt werden. Die V-SYNC-
Phase ist jedoch ein klein wenig länger, als die Dauer der Übertragung
eines einzelnen Zeichens. Das könnte dazu führen, das einzelne Zeichen
verloren gehen, wenn sie genau in der VSYNC- Phase gesendet wurden. Ich
hoffe ich habe mich da nicht verechnet :-).
Ich werde heut Abend mal versuchen ob es evtl. besser wird, wenn auch
während des VSYNC's auf eingehende Zeichen reagiert wird.
Was die nicht erkannten Tastendrücke angeht, so kann man da wohl nicht
mehr viel ausrichten. Da ich nur während des VSYNC's mit der Tastatur
interagieren kann, konnt es stark auf den Typ der Tastatur und die
Tippgeschwindigkeit an. Während der Ausgabe der sichtbaren Bildteile
muss ich die Tastatur ständig dazu zwingen ihre Kommunikation
einzustellen und ggf. sogar abzubrechen. Ich denke mal das das ganze
einige der Tastaturen am Markt nicht all zu gern mitmachen. Meine eigene
Tastatur gehört auch dazu. Sobald ich mal ein wenig schneller Tippe
gehen auch mir Tastendrücke verloren.
Eine mögliche Lösung hierfür sieht ein kleines ATINY- Puffer IC in der
Tastaturleitung vor, das die Zeichen zwischenspeichert und dann von der
VGA- Seite her per Pollingverfahren ausgelesen wird. Derzeit habe ich
nur leider keinen ATINY hier rum liegen, so das ich das im moment nicht
Ausprobieren könnte. Und das bestellen eines einzelnen ATINY's lohnt
sich nicht. Sobald ich da etwas fertiges habe, werde ich das als option
mit in den VGA- Kern übernehmen. Dann kann jeder nacher beim Compilieren
per DEFINE's entscheiden, ob er mit oder ohne zusätzliches PufferIC
arbeiten möchte.
Was mir noch aufgefallen ist, ist das auch das ADM-3A Terminal spezielle
Steuerzeichen für Befehle wie Unterstrichen, Unsichbar und Blinkend
kennt. Diese kann ich leider mangels Resourcen auf dem AVR-VGA Kern
nicht unterstützen, sie werden daher derzeit auch nocht nicht einmal
erkannt. Hier baue ich noch eine Erkennungsroutine ein, die die
Sequencen erkennt und dann aber einfach ignoriert. Damit sollten die
Steuerzeichen nicht mehr mit auf dem Bildschirm ausgegeben werden.
Vielen Dank fürs Testen,
Frank
Hallo Frank,
mein CPM Kern läuft mit 20MHz Quarz... also ist mein System mit deinem
vergleichbar. Wie wäre es denn wenn man die Übertragungrate reduziert?
Wenn du einen Tiny als Buffer nimmst... warum nicht auch für die
Serielle?
Gruß
Hans- Werner
Hallo Peter,
anscheinend ist ganz plötzlich alle weg... deine Schaltung sieht wild
aus, aber funktioniert...oder. Was macht denn die Software?
Gruß
Hans-Werner
Hi Hans-Werner und Joe.
Das war der aller erste LR Aufbau, der zum aller ersten Post in diesem
Thread führte. Damals noch mit 3.3V Netzteil und Handykabel zur
seriellen Verbindung.. ;-) Als ich den Adapter sah, mußte ich den
einfach bestellen (3-4€) und wußte, das der hier wie die Faust aufs Auge
passt..
Ist immer noch ein 4-bit Aufbau.. ich mag diese SMD Drams nicht :-(
Die 8080 Emulation und CP/M laufen sehr gut!
Wie Joe aber schon sagte habe ich von der Erweiterung auf Z80 Emulation
nichts mehr gehört und das serielle Terminal ist wohl auch nur
rudimentär
fertig gestellt..
Die letzten Entwicklungen gingen mir zu schnell um noch mitzukommen und
Richtung NUR Linux wollte ich auch nicht.. daher nutze ich immer noch
das
'alte' Diskformat und den tniasm..
Evtl. baue ich die 8-bit Dramversion mal in DIL auf LR auf.. aber mit
Platine wäre das schon einfacher..
Wie genau der letzte Stand ist und wo der nun liegt..??
---
Wenn man das mal wieder beleben wollte, würde ich (just my 2 cents!)
eine neue Platine machen wollen: 8-bit aber DIL - kein SMD!
Ohne Terminal, dafür aber obigen Adapter vorsehen, der gleich die 3,3V
Versorgung und die PC Kommunikation über USB erledigt. Also quasi
1x ATmega328, 2xDIL Dram, Quarz+2xC, USB Adapter. Thats it.
-
Die darauf laufende Software auf den aktuellen Stand bringen und
dokumentieren. Hier insbesondere das/die neuen Diskformate
berücksichtigen.
-
Die Z80 Emulation voran bringen!
Peter
Peter Sieg schrieb:> Wenn man das mal wieder beleben wollte, würde ich (just my 2 cents!)> eine neue Platine machen wollen: 8-bit aber DIL - kein SMD!
Das sollte sich machen lassen... wenn es wieder auf Interesse stößt.
> Die darauf laufende Software auf den aktuellen Stand bringen und> dokumentieren. Hier insbesondere das/die neuen Diskformate> berücksichtigen.
Hier sehen ich den größten Aufholbedarf. Das Projekt wird erst von
Interessenten nachgenutzt, wenn die Doku auch eine Nachnutzung erlaubt.
> Die Z80 Emulation voran bringen!
JA
Ich habe mal im Forum64, Forum des Vereins zum Erhalt klassischer
Computer und Robotron Forum Werbung gemacht:
---
Hi. Mehr Info's hier:
Beitrag "CP/M auf ATmega88"http://avr.cwsurf.de/?AVR_CP%2FM
Das Projekt ist etwas 'eingeschlafen', aber wir möchten es gerne etwas
wiederbeleben.
Es soll - bei genügend Interesse - eine neue Platine geben nur in DIL!
(kein SMD). Das wird dann ein ATmega328 und 2 x 4-bit Dram werden.
Dazu noch ein SD Slot und den USB-TTL Wandler und fertig.
Was zur Zeit alles läuft: 8080 Emulation inkl. Mircosoft Basic, BDS
C-Compiler, Spiele etc. inkl. vollem CP/M System mit bis zu 4
Diskettenimages..
Was noch fehlt: Z80 Emulation
Falls ihr an einer Platine interesse habt und bei der Doku oder
Programmentwicklung weiterarbeiten möchtet, postet es bitte im obigen
Thread und hier.
Das Ding macht wirklich Spaß!
Peter
---
Mal sehen, ob wir mind. 10 Interessenten zusammenbekommen.
Bei eine einfachen DIL Variante mit AVR, 2xDram für 8-bit
und dem oben genannten USB-TTL Wandler bin ich schon mit 2-3 Platinen
dabei.
Peter
Hallo,
ich wäre an zwei Boards interessiert - neben der CP/M-3 und qz80
Implementierung auf dem Propeller, wäre das meine zweite Software
CP/M-Maschine :-)
Grüsse,
Andreas
wunixbln-NO-SPAM-@googlemail.com (-NO-SPAM- löschen)
Andreas H. schrieb:> ich wäre an zwei Boards interessiert
Andreas, du bist aufgenommen.
@Peter
an welche D-RAM's hast du gedacht? Wieviele bekommen wir zusammen?
Joe
@Joe: 256k x 4bit
Part number V53C104P-70
Description HIGH Performance, LOW Power 256K X 4 BIT FAST PAGE MODE
CMOS Dynamic RAM; DIL-20
Davon habe ich ca. 34 Stück hier liegen.
Dann habe ich noch GM71C4256, HM514256, TC514256 hier ca. 20 Stück.
Auch DIL-20 und sollten alle dasselbe Pinout haben..
Peter
Peter Sieg schrieb:> @Joe: 256k x 4bit
OK, ich mache mich mal ans Layout. Peter, ich nehme an, du hast schon
getestet ob die RAM's auch mit 3.3V gehen. Laut Datenblatt haben sie
wieder nur 5V aber 64K ging ja auch mit 3.3V
Joe
MarioS aus dem Forum64 möchte auch 3 Platinen nehmen.
Leider gehen die V53C104P nicht! Entweder doch anderes Pinout oder 3,3V
reichen nicht. Die anderen habe ich getestet und gehen.. daher habe ich
nur
ca. 16 Ram Chips.. das sollte aber auch welche sein, die im Amiga 500,
C64-II etc. verwendet wurden..
EDIT: Pinout ist gleich.. also vertragen die die 3V nicht.. :-(
Peter
for(;;) aus dem Forum64 möchte auch eine Platine.
Er wird sich sicher hier auch noch (wie hoffentlich MarioS aus dem F64)
noch
mit seiner E-Mail Adresse melden.
@Joe: Damit sollten wir mind. schon 10 Stück zusammen haben, oder?
Macht du bitte wieder die Platinen und die Sammelbestellungen?
Gruß, Peter
Peter Sieg schrieb:> Macht du bitte wieder die Platinen und die Sammelbestellungen?
Mache ich. Bis jetzt habe ich nur dich und Andreas H. auf meiner Liste.
Holger (ambrosius) mir bitte mal die Mail zukommen lassen.
Joe
Ich hätte auch gerne eine Platine!
Wäre toll, wenn ein MAX232 mit drauf wäre, dann könnte ich es direkt an
mein Lear Siegler ADM-3A Terminal anschliessen.
Nils Eilers schrieb:> Wäre toll, wenn ein MAX232 mit drauf wäre
Peter häte gerne einen Anschluß für diese Platine:
http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=200393339984
Du hättest gerne einen MAX232
Ich würde lieber einen FT232 mit Stecker nehmen um sozusagen ein
CP/M-USB Stecker zu bekommen.
Vorschlag:
Die Platine bekommt an der einen Stirnseite eine Buchsenleiste für
Peters Modul. Steckbar ist dann das besagte Modul, ein MAX232 Modul oder
ein FT232 Modul, oder, oder. Was meint ihr dazu?
Gruß, Joe
@Joe: Gute Idee mit der Kontaktleiste. Max232 halte ich für veraltet.
FT232 als zu bestückende Alternative ok. MicroVGA AnschlußLeiste wäre
auch
ok aber kein Muß..
Immer daran denken,so einfach wie möglich - nur nicht einfacher.. ;-)
Und der Adapter ist für den Preis nicht zu schlagen..
Peter
Hi Leute,
eins vornweg ich finde das Projekt herrlich bekloppt und werde erstmal
ein Lochrasteraufbau fädeln. Da kommt der Tipp mit dem Modul von Peter
wie gerufen, der FT ist ja nicht so gut Lochraster geeignet (ist ja
nicht jeder Elm Chan :-) Da tut sich aber gleich eine Frage auf: Die
erhältlichen Module scheinen alle mit CP2102 bestückt zu sein. Weiß
jemand, wie gut die mit Linux laufen? Für eine professionell gefertigte
Platine könnte ich mir noch eine "alles in SMD, so eng wie es
handzubestücken geht, wenn irgendmöglich in USB-Flashstick-Format
gequetscht"-Version vorstellen ;-)
frank
Ich finde die Idee mit der Stiftleiste auch gut, würde aber auf der
Platine dann noch den FT232 mit drauf nehmen - der braucht nicht viel
Platz und wenn jemand was anderes will, kann er das über die Stiftleiste
anschliessen ohne Leiterbahnen zu durchtrennen etc.
Frank P. schrieb:> Da tut sich aber gleich eine Frage auf: Die> erhältlichen Module scheinen alle mit CP2102 bestückt zu sein. Weiß> jemand, wie gut die mit Linux laufen?
Ist kein Problem, Treiber ist seit langem im Kernel.
Es geht ja nicht darum prinzipiell eine Platine für das Projekt auf die
Beine zu stellen, das haben wir ja schon in zwei Varianten getan, siehe
hier:
http://www.mikrocontroller.net/articles/AVR_CP/M
Die Idee ist vielmehr mit einem ganz, ganz einfachen Aufbau Mitstreiter
zu finden, die auch an der Software noch etwas tun. Stichwort Z80.
Einfach soll auch heißen DIL auf Fassung um auch mal ein IC zu tauschen
oder zu testen.
Joe
Genau. Im Prinzip sehe ich die 4-bit Platine aus dem Artikel
erweitert/umgebaut auf 8-bit (andere Portbelegungen) und der
Pinheaderbereich
links über dem SD Slot dann kompatibel zu dem CP2102 USB-TTL Adapter
ausgeprägt als die hier jetzt angestrebte neue Platine. FT232+USB Buchse
ist ja parallel noch drauf..
Der Vorteil der 8-bit Version ist halt die fast verdoppelte
Geschwindigkeit
der Emulation.. womit insbesondere Arcade-like Spiele (Ladder/Pacman)
besser
spielbar werden..
Und ja, schön wäre die Erweiterung auf Z80 Emulation, die dann die Tür
öffnen
würde für z.B Turbo Pascal, Sargon Schach, etc..
BTW: In dem Artikel ist die letzte 8-bit Version mit SMD Rams und
VGA-Terminal Teil übrigens nicht dokumentiert..?
Peter
getestet schrieb:> Ist kein Problem, Treiber ist seit langem im Kernel.
Danke fürs testen ;-)
Joe G. schrieb:> Es geht ja nicht darum prinzipiell eine Platine für das Projekt auf die> Beine zu stellen, das haben wir ja schon in zwei Varianten getan, …
Ich denke die Ansprache gilt meiner "so-klein-wie-möglich-Idee". Ich
weiß, was Ihr schon alles auf die Beine gestellt habt. Dafür genießt Ihr
meinen vollen Respekt. War ja auch nur so eine Idee, falls mal jemandem
langweilig wird ;-)
> Die Idee ist vielmehr mit einem ganz, ganz einfachen Aufbau Mitstreiter> zu finden, die auch an der Software noch etwas tun. Stichwort Z80.> Einfach soll auch heißen DIL auf Fassung um auch mal ein IC zu tauschen> oder zu testen.
Kann ich nachvollziehen, und ich will Euch da auch nicht reinreden, Gott
bewahre. Zumal ich Euch bei der Software wahrscheinlich nicht viel
helfen kann. Ich finde für mich eine professionell gefertigte
Platine für alles in DIL etwas übertrieben. Nichtsdestotrotz, wenn es
neue Mitstreiter bringt und Ihr noch eine Mindeststückzahl braucht,
würde ich auch eine LP nehmen. Es sollte dann aber schon eine 8-Bit
Version sein. An Z80 wäre ich natürlich auch sehr interessiert.
frank
@alle: was ist denn eigendlich `der letzte Stand` der Software?
Im SVN:
http://cloudbase.homelinux.net/svn/avr-cpm/
steht Revision 161.
Unter avrcpm - branches gibt es 2\ und fat16-test\
fat16-test war das lesen von Diskimages von fat16 formattierten SD
Karten..
..wie ist da der Status.. wer hats getestet..?
Und 2\ = Version 2? Was war doch gleich noch mal der Unterschied zu der
ersten Version..?
Und dann gibts noch trunk\ ..?
Nun ich habe hier die Version 1, die für 4-bit und 8-bit assembliert
werden
kann.. und bis zu 4 CP/M Partitionen unterstützt.. damit werde ich
ersteinmal
die neuen 8-bit Platinen versorgen, solange mich niemand eines anderen
überzeugt.. ;-)
Peter
Peter Sieg schrieb:> @alle: was ist denn eigendlich `der letzte Stand` der Software?
Die 2.0 Version lief auf meiner 8-Bit Hardware. Problem dort war, die SD
Karten konnten nur noch unter Linux mit den CP/M Partitionen erzeugt
werden.
Für Win.. User nicht so schön.
Die fat16 Version konnte ich zwar übersetzten jedoch nicht von der SD
Karte booten. Es war für mich nicht so richtig transparent, wie und in
welchem Format das CP/M System auf die Karte kam. Für weitere
Entwicklungen fürde ich diesen Zweig lieber weiterverfolgen.
Joe
Habe mir die fat16-test Version mal gezogen und für 4-bit; m168; 30MHz;
fat16 Nutzung assembliert. Dann disk images als CPMDSK_A.IMG ..
CPMDSK_D.IMG auf eine FAT16 formatierte SD Karte kopiert und es läuft!
8-bit kann ich mangels Hardware nicht testen. ATmega88 scheint Fehler
beim
assemblieren zu geben (Funktionen werden genutzt, die erst ab 168 da
sind).
Als disk images habe ich die originalen verwendet (urspüngliches Format
von ca. 243kb).
Sieht doch schon mal gut aus! Das komplette fat16 Verzeichnis inkl. AVR
Studio 4 Projektdatei und erzeugtem Hex hänge ich hier mal an.
Peter
In froher Erwartung auf die neue AVR-cpm Leiterplatte habe ich mir das
CPM-Image auch schon eingehender angeschaut, konnte aber nirgends die
Quellen für das CPM.SYS finden. Wer hat das CPM.SYS generiert und kann
dazu auch die Quellen abgeben ?!
Danke und Grüsse,
Andreas
Peter Sieg schrieb:> Sieht doch schon mal gut aus!
Bestens Peter, werde ich heute oder morgen mal auf 8-Bit testen. Im
nächsten Schritt sollten wir die Doku "Nachbausicher" machen. Auch im
Hinblick auf solche Fragen wie von Andreas.
@Andreas
Das cpm.sys ist die Originaldatei, zu finden hier:
http://www.mikrocontroller.net/articles/AVR_CP/M
Den Quelltext dazu kenne ich auch nicht. Um das Bios zu übersetzen und
die cpm.bin Datei zu erzeugen hatten wir auch für Win Makefiles
erstelllt. Ich suche mal alles zusammen und bemühe mich eine kleine
Kurzanleitung dazu zu verfassen.
Joe
Im Anhang mein bios Verzeichnis.
(Den Quelltext von cpm.sys habe ich aber auch nicht)
Darin ist bios.asm+ipl.asm
tniasm.exe zum assemblieren
make_bios.bat zum übersetzen von ipl+bios
make_cpm.bat zum bilden von cpm.bin (nutzt dd.exe, was auch enthalten
ist)
Das Resultat cpm.bin wird dann zum bilden von diskimages mit den
cpmtools
verwendet:
mkfs.cpm.exe -f avrcpm -b cpm.bin -L test CPMDSK_A.IMG
und füllen mit:
cpmcp -f avrcpm CPMDSK_A.IMG cpmdsk/MBASIC.COM 0:MBASIC.COM
Peter
Wegen BDOS+CCP bin ich fündig geworden. Die Quellen, für Z80 angepasst,
konnte ich bei Peter Schorn (http://www.schorn.ch/cpm/intro.php) finden.
Gruss,Andreas
@Andreas: Wäre super, wenn du die benötigten Teile zusammen puzzeln
würdest, um cpm.sys zu bilden. Idealerweise auch mit einem schon
verwendeten Z80 Assembler (tniasm; z80asm).
Peter
Hallo Peter,
kannst Du mir bei Gelegenheit das SURVEY.COM (im Archiv) auf dem AVRcpm
ausführen ?! und den Output schicken. Die wichtigen Adressen stehen zwar
im BIOS.ASM, aber sicher ist sicher.
Danke, Andreas
Ich denke, wenn die fat16 Version auch für 8-bit ok ist, sollten wir
diese
als Basis für die weitere Entwicklung nehmen.
Evtl. mal ein Diff gegen V2/trunc fahren..
Meines Wissens hatte Leo C. das Diskettenformat vergrößert und evtl. ist
der Z80 Emulationscode in dieser Versionen schon weiter
fortgeschritten??
@Leo C: Liest du noch mit..?
Peter
Nachtrag.
Die 4-Bit Variante läuft auch bei mir mit Fat16. Allerdings reagieren
einige MMC's giftig. Die MC-Routine ist nicht wirkllich für alle Karten
sicher.
Joe
Ja Peter, ich lese noch mit.
Inzwischen habe ich auch wieder etwas Zeit für das Projekt, aber wohl
nicht mehr so viel wie letzten Sommer.
Am Samstag habe ich endlich mal meinen letzten Softwarestand in das
SVN-Repository eingecheckt. Die Software funktioniert bei mir, ist aber
nicht besonders gut getestet. Wegen der Features (FAT16, Disk Formate)
bitte nach meinen letzten Beiträgen hier im Forum suchen. Danach hier
fragen.
Die aktuelle Software ist für gewöhnlich hier zu finden:
http://cloudbase.homelinux.net/viewvc/avr-cpm/avrcpm/trunk/
Oder besser, mit einem SVN-Client:
http://cloudbase.homelinux.net/svn/avr-cpm
Als Client für Windows ist tortoisesvn zu empfehlen:
http://tortoisesvn.tigris.org/
Übrigens Peter, bei SVN steht trunk für Stamm, nicht etwa für Kofferraum
oder Rüssel. :)
In trunk ist üblicherweise die Hauptentwicklungslinie.
Wegen Z80 Unterstützung könnte ja mal jemand bei "Horst S. (h3aau)"
nachfragen. (Beitrag "Re: CP/M auf ATmega88")
Joe, wenn Du mit den SD-Karten-Problemen nicht weiterkommst, kann ich
versuchen, zu helfen.
@Joe: hast du mal probiert mit dem Debugschalter:
FAT16_DEBUG = 1
mehr Informationen zu bekommen?
Zur SD Card Initialisierung gibts ja einige Projekte zum
vergleichen/kopieren: Z.B www.sd2iec.de und sicher auch hier im Forum..
Beitrag "MMC/SD-Karte mit FAT16 an AVR"Beitrag "MMC SD library FAT16 FAT32 read write"
---
@Leo C: Prima! D.h. der trunk enthält jetzt die neueste Version?
Das Problem, was ich whrscheinlich damit habe ist, das es sich weit von
Win$ entfernt hat..? D.h mein ipl+bios etc. und Diskformate muß ich
anpassen/ändern, oder kann ich die orig. Formate+Bios beibehalten
(vorerst)?
Ist den da neuerer Z80 code von Horst S. (h3aau) schon drin, oder noch
nicht?
Peter
Leo C. schrieb:> Joe, wenn Du mit den SD-Karten-Problemen nicht weiterkommst, kann ich> versuchen, zu helfen.
Super Angebot Leo.
Das MMC Problem bei der 4-Bit Variante kann über dden SPI Takt behoben
werden, der der 8-Bit Variante bin ich derzeit ratlos. Der Ramtest läuft
durch, MMC wird erkannt und gelesen, der Sprung auf Adr. 2000H erfolgt
UND dort steht nur "Mist", meißt 00 00 00. Na und dann wars das. Ich
habe noch nicht rausbekommen ob der Ram seinen Inhalt vergißt, oder von
der MMC falsch gelesen wird. Ich denke aber zweiteres, da einige Karten
mit der Meldung "kein System" antworten.
Ich habe mir trunk gerade mal gezogen. Konnte ich für m168, 30MHz, 4-bit
Dram und fat16 ohne Fehler übersetzen.
Frage: Kann ich das mit den 'alten' Bios+ipl Diskimages (243kb) nutzen?
Um die Assemblierung der bios.mac +ipl.mac möchte ich mich dann erst
später kümmern...
Peter
Bios assemblieren:
zxcc habe ich für Dos/Win$ nicht gefunden.
m80l80.zip habe ich probiert:
*BIOS,TTY:=BIOS wirft 38 fatale Fehler aus.
Das ist so für mich natürlich keine akzepable 'Lösung'..
Ich brauche etwas, womit ich die unter Win$ assemblieren kann..
@Leo C: Kannst du die *.mac nicht wieder per awk? script in asm zurück
wandeln?
Peter
Im Anhang ist jetzt mal ein aktuelles System.
Zum Rest schreibe ich später nochmal mehr. Jetzt mal auf die Schnelle...
Peter Sieg schrieb:> Bios assemblieren:> zxcc habe ich für Dos/Win$ nicht gefunden.Beitrag "Re: CP/M auf ATmega88"Beitrag "Re: CP/M auf ATmega88"
Darüber, und auch sonst, sollte es kein Problem sein,
http://www.seasip.demon.co.uk/Unix/Zxcc/
zu finden.
Das Archiv der 0.4 Version enthält auch Windows Binaries.
http://www.seasip.demon.co.uk/Unix/Zxcc/zxcc-0.4.0.tar.gz> m80l80.zip habe ich probiert:> *BIOS,TTY:=BIOS wirft 38 fatale Fehler aus.
Ich meine mich zu erinnern, daß ich das mal kurz ausprobiert hatte, in
dem ich alle benötigten Dateien in ein Verzeichnis kopiert hatte. Um das
alles richtig unter Windows zu installieren, fehlt mir die Zeit,
vernünftiges Gerät und die Motivation. Hier wird es doch den ein oder
anderen Windowsprogrammierer geben, der das mal richtig installieren und
das Makefile ggf. anpassen kann. Mein Provisorium hat sicher
funktioniert, sonst hätte ich diese Möglichkeit hier garnicht erwähnt.
> Das ist so für mich natürlich keine akzepable 'Lösung'..
Das ist natürlich schlimm für Dich.
> Ich brauche etwas, womit ich die unter Win$ assemblieren kann..> @Leo C: Kannst du die *.mac nicht wieder per awk? script in asm zurück> wandeln?
nein.
Ja nun habe ich auch gelesen, das in der 4.0 Version Dos/Win Programme
enthalten sind. In der 5er aber nicht. Habe ich getestet (alles in 1
Verzeichnis), bekommen auch hier mit: zxcc m80 -=bios.mac 38 fatale
Fehler??
---
Hier:
http://hc-ddr.hucki.net/wiki/doku.php/cpm:windows
habe ich auch den cpm player getestet.
Dort bekomme ich mit cpm m80.com =bios.mac 41 fatale Fehler?
bios.rel wird aber erzeugt.
G:\temp>cpm l80.com bios.rel,bios.bin/N/E
Link-80 3.44 09-Dec-81 Copyright (c) 1981 Microsoft
Data 0100 0328 < 552>
53266 Bytes Free
[0000 0328 3]
G:\temp>
---
@Leo C. Ja ich weiß.. mal sehen.. aber wenn alle Stricke reißen bleibe
ich eben bei dem Code den ich aktuell habe.. das war auch ein Grund,
damals ersteinmal nicht mehr weiter 'mitzumachen' - ist halt (für mich!)
blöd, wenn das nach Linux Only abwandert und ich/Windows außen vor
bleiben.
Nun, evtl. findet ja jemand noch woran es liegt bzw. eine
funktionierende Lösung..
Kann ich denn den AVR Code aus trunk mit dem 'alten' Bios verwendet,
oder ist zwingend auch das aktuelle Bios tz verwenden?
Peter
Peter Sieg schrieb:> Kann ich denn den AVR Code aus trunk mit dem 'alten' Bios verwendet,> oder ist zwingend auch das aktuelle Bios tz verwenden?
Nein geht nicht.
Joe
Jup. Geht nicht.. habe ich gerade probiert..
Leider noch eine schlechte Nachricht. FAT16 scheint noch Probleme
zumindest beim schreiben zu haben.. BDSC (C-Compiler) meldet bei der
trunk Version:
BDos Err on C..
Und die fat16-test meldet bei clink mmind - No main defined - aborted.
Wenn ich mit Partitionen arbeite geht fat16-test einwandfrei.. trunk
muss
ich noch testen..
:-(
Peter
arg. Muss mich mal anmelden, damit ich editieren kann..
---
fat16-test und trunk lassen sich nicht mehr für atmega88 übersetzen
- auch ohne fat16support!
Das kann der atmega88 nicht ab:
call uartputc
Peter
Hallo Peter und Leo,
ich habe hier mal das ALIADOS im Cygwin übersetzt. Es ist eine
einigermassen lauffähige CPM-Emulation - eigentlich für Linux - die aber
auch unter Windows spielt (hier bei mir unter Win7)
Nach dem Start landet man auf Drive A: und das aktuelle Verzeichnis ist
dann auch im CPM auf A: zu sehen. Wenn dort M80 und L80 liegen, kann man
sogar mit:
aliados M80.COM =blafasel.asm ..
aus der DOS-Shell assemblieren.
Hier habe ich das gefunden: http://www.arrakis.es/~ninsesabe/aliados/
Im Ziparchiv liegt das aliados.exe und die notwendigen Cygwin-DLLs.
Bitte die DDLs im gleichen Verzeichnis wie das .exe legen.
Wer es braucht, kann es ja mal checken, evtl. hilft das den
Win$-Freunden bei der BIOS Assemblierung.
Gruss,
Andreas
@andreas: Danke. Arbeitet aber genauso wie oben cpmplayer etc. m80
meldet wieder 38 fatal errors..
Ich denke die haben ein Problem mit der Quelldatei..?
Peter
Ich habe gerade mal bios.mac in die AltairSIMH cpm2.2 disk geladen und
dort m80 =bios.mac aufgrufen.. auch 38 fatal errors..??
Kann es sein, das ich nicht das richtige m80.com + l80.com habe..??
Bitte mal die richtigen Versionen hier anhängen.. dann solltes das ggf.
mit
einige hier weiter oben aufgeführten Tools gehen.. denn die Meldung 38
fatal errors hatte ich schon mehrere Male mit unterschiedlichen Tools..
Peter
@Peter: ich kommte mit M80 und L80 das bios.mac aus dem SVN/trunk prima
assemblieren und linken (habe das aliados unter macosx verwendet):
lunatix:cpm hein$ aliados m80.com =bios.mac
No Fatal error(s)
lunatix:cpm hein$ aliados l80.com bios,bios/n/e
Link-80 3.44 09-Dec-81 Copyright (c) 1981 Microsoft
Data 0100 0518 < 1048>
52514 Bytes Free
[0000 0518 5]
hier meine eingesetzten Tools.
Andreas
Peter Sieg schrieb:> Ich habe gerade mal bios.mac in die AltairSIMH cpm2.2 disk geladen und> dort m80 =bios.mac aufgrufen.. auch 38 fatal errors..??
Kann es sein, daß Dein M80 die Includedateien 'avrcpm.lib' und
'cfgacpm.lib' nicht findet?
Ja, so ist/war es ;-)
aliados geht!! Habe inzwischen das cpm.bin komplett neu erstellen
können.
Nun auch neue diskimages erzeugt und unter Knoppix auf cp/m Partitionen
mit
dd geschrieben..
=> Bin jetzt auf neuestem trunk level ;-)
Trotzdem gibt es leider unter fat16 ein Schreibproblem!
@Andreas: kannst du bitte mal versuchen auch die cpmtools unter deiner
cygwin Umgebung zu compilieren? Dann haben wir die cygwin dll's
gemeinsam um
brauchen nicht ggf. 2 Versionen. Dazu haben die cpmtools unter Windows
noch
2 Unschönheiten:
1. diskdefs wird FEST unter x.\cpmtools gesucht.
2. diskdefs muss nach Unix Konvention nur mit LF als Zeilenende versehen
sein
(kein CR+LF wie unter Dos/Win üblich)
http://www.moria.de/~michael/cpmtools/
bei zxcc und cpm (cpmplayer) scheinen die lib's/includes von m80/l80
nicht
gefunden zu werden.. schaue ich mir noch mal an.. ob man das nicht noch
hinbekommt..
Fazit: Man kann alles unter Windows assemblieren!
Peter
Hmm.. m80l80pc geht nun auch.. vielleicht hatte ich wirklich nur die
includes nicht im Verzeichnis..
Ich hänge das m80l80pc.zip inkl. aller benötigten Dateien hier an.
zxcc+cpmplayer schaue ich mir jetzt auch noch mal an..
Peter
Ich hänge jetzt hier mal an: avrcpm_fat16.zip = neueste trunk Quellen
inkl. AVR Studio 4 Projekt und avrcpm_aliados.zip = alles zum bilden von
Bios+Ipl,CPM.BIN und Disk Images mit cpmtools.
Das sind außer der Hardware alles was es unter Windows braucht..
Auf 4-bit läuft es prima mit Partitionen.
fat16 lesend ok; schreibend Problem.
8-bit habe ich (noch) nicht. Bei Leo C. sollte es aber laufen (Part.?)
und bei Joe gibts Probleme (fat16?)..
Z80 Stand?
Peter
Joe G. schrieb:> Es sieht in etwa immer so aus:>> CPM on an AVR, v2.0> Initing mmc...
...
> mmcCMD: 11 003F4200 .. 01 CMDRes: 00> Ok, CPU is live!
Das sieht geigentlich alles ganz gut und plausibel aus.
> PC=2000> A =20 BC =0000 DE =0000 HL =>> IPL müßte jedoch mit 31 00 10 beginnen
Das der mmc-Treiber ohne Fehlermeldung falsche Daten liefert, will ich
noch nicht so ganz glauben. Deshalb würde ich den Fehler erst mal an
anderer Stelle vermuten.
Hast Du inzwischen mal mit aktueller Software (trunk) getestet?
@Peter, Leo C.
die 4-Bitv Variante aus trunc funktioniert (eingeschränkt). Die 8-Bit
Variante hat immer noch die gleichen Probleme. Ich vermute tatsächlich
MMC Probleme weil: (nun einige Logauszüge)
4 Bit Version
Test 1, MMC_1 128MB, MMCSPI2X =1 (CLK/2)
CPM on an AVR, v2.1
Testing RAM: fill...wait...reread...
Initing mmc...
A:FAT16 File-Image at: 8598, size: 208KB.
B:FAT16 File-Image at: 8510, size: 175KB.
C:FAT16 File-Image at: 8450, size: 118KB.
Partinit done.
Ok, CPU is live!
ipl
S A =A8 BC =280C DE =0080 HL =E180 SP =2000 PC =202F 28 A8
02 Invalid opcode!
bootet also komplet durch, führt IPL aus und dann gibt es Fehler
Test 2, MMC_1 128MB, MMCSPI2X =0 (CLK/4)
CPM on an AVR, v2.1
Testing RAM: fill...wait...reread...
Initing mmc...
A:FAT16 File-Image at: 8598, size: 208KB.
B:FAT16 File-Image at: 8510, size: 175KB.
C:FAT16 File-Image at: 8450, size: 118KB.
Partinit done.
Ok, CPU is live!
ipl
62k cp/m vers 2.2
A>
FEHLERFREI
Test 3, MMC_2 1GB, MMCSPI2X =0 (CLK/4), identisches Immage
CPM on an AVR, v2.1
Testing RAM: fill...wait...reread...
Initing mmc...
A:CP/M partition at: 8097, size: 4144KB.
B:CP/M partition at: 16385, size: 7808KB.
Partinit done.
Ok, CPU is live!
ipl
DISK I/O: Invalid Function code: 01
8 Bit Version
Test 4, MMC_1 128MB, MMCSPI2X =0 (CLK/4), gleiche Image, ohne MMC Debug
CPM on an AVR, v2.1
Testing RAM: fill...wait...reread...
Initing mmc...
A:FAT16 File-Image at: 8598, size:
NEUSTART
CPM on an AVR, v2.1
Testing RAM: fill...wait...reread...
Initing mmc...
Test 5, MMC_1 128MB, MMCSPI2X =0 (CLK/4), gleiche Image, mit MMC Debug
CPM on an AVR, v2.0
Testing RAM: fill...wait...reread...
Initing mmc...
mmcInit
mmcCMD: 00 00000000 .. 95 CMDRes: 01
mmcCMD: 08 000001AA .. 87 CMDRes: 05
...
A:FAT16 File-Image at: 002, size: 081KB.
Partinit done.
mmcCMD: 11 00017C00 .. 01 CMDRes: 00
NEUSTART
CPM on an AVR, v2.0
Testing RAM: fill...wait...reread...
Initing mmc...
d.h. wenn das MMC Debug eingeschaltet ist, wird die Karte etwas besser
gelesen jedoch auch nicht fehlerfrei. Übrigens sind die 4-Bit und die
8-Bit Varianten auf unterschiedlicher Hardware aufgebaut.
Joe
@Peter,
bitte vergrößere Deine FAT16-Imagedateien mal auf (mindestens) 256
KByte.
Unser Treiber kann das leider nicht selbst.
Vergrößern geht z.B. durch anhängen von Bytes mit dd, oder mit makeimage
von Frank Zoll, das im SVN in trunk/tools/makeimage zu finden ist. Wenn
man bei makeimage die Größe wegläßt, wird die Datei "zufällig" auf 256
KB vergrößert.
Neue, frisch formatierte Images kann man auch folgendermaßen erzeugen,
damit sie von Anfang an die richtige Größe haben:
1
$ makeimage /dev/null CPMDSK_x.IMG
mkfs.cpm kann man sich dann sparen.
Unter Windows muß man /dev/null evtl. durch etwas anderes ersetzen.
Hmm. Was mir aufgefallen ist. Test 4 = V2.1, ab Test5 V2.0?
Alle Test sind mit fat16 Fileimages gemacht.
Kannst du bitte auch mal 8-bit testen, ohne fat16 Images auf die SD
Karte zu tun, sondern anstatt dessen mal Partitionen zu verwenden?
Ich verwende ürigens auch 2 128Mb SD Karten: Noname + Kingston.
@Leo C: bei dir läuft aber die trunk in 8-bit?
Es sind doch mind. 10 Platinen mit der 8-bit 4MB + VGA Teil in Betrieb..
welche Version wird denn dort eingesetzt..?
Peter
@Leo C: Du meinst/vermutest, das beim schreiben über die aktuelle Größe
hinausgegangen wird und dann gibts Probleme.. weshalb diese Mindestgröße
sein muß?
makeimage - liegt nur als c Source vor. Ich habe keinen Compiler
installiert z.Z :-(
Und wenn sich jemand findet (@Andreas?) der das unter Windows / Cygwin
kompiliert, dann bitte auch evtl. Unix Spezifika (/dev/null) entsprechen
für uns Win$ User händelbar machen..
Peter
Peter Sieg schrieb:> @Leo C: bei dir läuft aber die trunk in 8-bit?
Logo. 4Bit ist (glaube ich) noch auf meinem Steckbrett, und habe ich
schon lange nicht mehr getestet.
> Es sind doch mind. 10 Platinen mit der 8-bit 4MB + VGA Teil in Betrieb..> welche Version wird denn dort eingesetzt..?
Keine Ahnung. Ich habe hier meinen eigenen Lochrasteraufbau.
Hier gibts ein Bild:
Beitrag "Re: CP/M auf ATmega88"
Peter Sieg schrieb:> @Leo C: Du meinst/vermutest, das beim schreiben über die aktuelle Größe> hinausgegangen wird und dann gibts Probleme.. weshalb diese Mindestgröße> sein muß?
Nein, ich weiß, daß der Treiber auf das Dateiende testet, und nicht
darüber hinaus schreibt. Stattdessen meldet er einen Fehler zurück. Der
Treiber könnte an der Stelle auch die Datei vergrößern (sofern Platz auf
dem Datenträger), aber der Aufwand dafür ist nach Franks und meiner
Meinung nach unverhältnismäßig groß.
> makeimage - liegt nur als c Source vor. Ich habe keinen Compiler> installiert z.Z :-(
Das Programm ist in anspruchlosestem ANSI-C geschrieben, und kann mit
jedem Compiler auf wahrscheinlich jeder Plattform übersetzt werden.
> Und wenn sich jemand findet (@Andreas?) der das unter Windows / Cygwin> kompiliert, dann bitte auch evtl. Unix Spezifika (/dev/null) entsprechen> für uns Win$ User händelbar machen..
Andreas wird das sicher machen können. Cygwin braucht man dafür nicht,
und das Programm hat keine Unix Spezifika.
@Leo C. das Schreibproblem ist gelöst! Danke!
Ich habe die _C.IMG Datei mit dd (in avrcpm_aliados.zip) so auf 256k
gebracht:
dd if=CPMDSK_C.IMG of=CPMDSK_D.IMG ibs=256k conv=sync
Dann auf SD Karte..
d:
D>cc mmind.c
BD Software C Compiler v1.60 (part I)
35K elbowroom
BD Software C Compiler v1.60 (part II)
32K to spare
D>clink mmind
BD Software C Linker v1.60
Last code address: 1B4D
Externals start at 1B4E, occupy 0000 bytes, last byte at 1B4E
Top of memory: E405
Stack space: C8B8
Writing output...
42K link space remaining
D>mmind
Random seed generation.. wait.. hit a key.
Guess my 4-digit number...(****); 0000 to abort.
Guess 1:0000
You gave up..
Press return to exit.
D>
Funktioniert also!
Ich habe das mal in meinem 'make_disk.bat' eingebaut.. bitte entzippen
und
die alte Version damit ersetzen..
Peter
Leo C. schrieb:> Nein, ich weiß, daß der Treiber auf das Dateiende testet, und nicht> darüber hinaus schreibt. Stattdessen meldet er einen Fehler zurück. Der> Treiber könnte an der Stelle auch die Datei vergrößern (sofern Platz auf> dem Datenträger), aber der Aufwand dafür ist nach Franks und meiner> Meinung nach unverhältnismäßig groß.
ok. Denke ich auch. Wenn man es weiß, ist es leichter die diskimage
mind.
so groß zu machen, wie diskdefs es definiert. Aktuell wären das ca. 243k
gewesen.. richtig?
(Bei Gelegenheit muß ich dann mal schauen, was du da schon an
Unterstützung von größeren Diskimagesgezauberst hast.. und wie ich das
nutzen kann..)
Aber ersteinmal die 8-bit Version haben und am laufen haben..
Dann Z80..
Peter
hier das makeimage.exe, lauffähig mit den Cygwin.DLLs die Ihr schon
habt. /dev/null geht wie unter Linux auch, da die Argumente ja in der
Cygwin-Runtime ausgewertet werden.
Andreas
Hat jemand schon einen fertigen Schaltplan für die 8bit AVR-Maschine ?
Ich würde mir das dann schonmal auf dem Breadboard zusammenstecken
wollen und könnte noch vor dem Release der Leiterplatte mit den Tests zu
den CCP+BDOS.ASM Quellen beginnen.
Andreas
Peter Sieg schrieb:> so groß zu machen, wie diskdefs es definiert. Aktuell wären das ca. 243k> gewesen.. richtig?
Fast. Die System-Tracks müssen ja auch noch reinpassen.
>> (Bei Gelegenheit muß ich dann mal schauen, was du da schon an> Unterstützung von größeren Diskimagesgezauberst hast.. und wie ich das> nutzen kann..)
Folgende sollten gehen:
simhd, simh altair 8800 hard disk format
MyZ80
YAZE
Siehe auch hier:
Beitrag "Re: CP/M auf ATmega88"Beitrag "Re: CP/M auf ATmega88"> Dann Z80..
Dazu habe ich vor 2 Tagen etwas geschrieben.
@Andreas: ich wollte mir das auch schon mal auf LR aufbauen. bin aber
zeitlich nicht dazu gekommen.. Basis wäre die 4-bit Skizze.
Aber Achtung! Völlig geänderte Pinzuordnungen bei 8-bit!
D0..D3 des 2ten Drams ist dann D4..D7.
Uart ändert sich ebenfalls (HW-Uart -> SW-Uart).
1
Hi. Ich möchte eine 8-bit Version auf LR aufbauen.
2
Wie genau muß ich was verdrahten? Ich gehe im Moment davon
3
aus:
4
5
1. 2ten Dram Chip 1:1 mit dem ersten verbinden (Huckepack) - bis auf D0-D3!
6
2. Dann nach Port Declarations aus config.inc gehen:
Andreas H. schrieb:> Hat jemand schon einen fertigen Schaltplan für die 8bit AVR-Maschine
Hier die 8-Bit Variante mit 4 MB x 4 RAM's.
@Peter
Ja, deine Portzuweisungen sind korrekt. Bei den Chips 4256 existieren
dann A9 und A10 halt nicht, ansonsten alles so wie auf der Schaltung.
Wenn alles mit 3.3V versorgt wird kann IC2 entfallen, dann aber
unbedingt die MMC ziehen wenn über ISP und 5V programmiert wird.
Zwei Baustellen, Softwaretest und Hardwareüberarbeitung waren zu viel.
Deshalb noch etws Geduld mit der neuen LP.
Joe
@Joe: Ich denke wir haben für uns schon ganz schön was geschafft.. Ich
bin jetzt endlich mal wieder auf dem aktuelle SW-Stand.. und fat16 sieht
gut aus.. bleibt noch das mmc/8-bit Problem.. wenn wir mehr Hardware
draußen haben.. gibts auch wieder etwas mehr Mitstreiter..
Also immer mit der Ruhe.. Gut Ding will Weile haben..
Peter
Hallo Leute,
meine Hardware läuft noch mit einer sehr alten 8bit Version. Interessant
wäre die Z80 Implemention und die Ausnutzung der MMC/SD Karte, am besten
alles mit dem Windows PC ladbar. Leider bin ich nicht der
Softwarespezialist...CPM 2.2 behersche ich gerade ein bischen...mit
echtem Z80. Aber ich lese hier weiter mit... mal sehen was noch wird.
Gruß
Hans-Werner
Hans- w. Schütz schrieb:> meine Hardware läuft noch mit einer sehr alten 8bit Version. Interessant> wäre die Z80 Implemention und die Ausnutzung der MMC/SD Karte, am besten> alles mit dem Windows PC ladbar.
Wenn Du mit "Ausnutzung der MMC/SD Karte" größere CP/M-Diskimages
meinst, kannst Du auf die Schnelle mal folgendes ausprobieren:
- Software (avr und BIOS) auf neuesten Stand bringen
http://cloudbase.homelinux.net/viewvc/avr-cpm/avrcpm/trunk/
- Bootbare SD-Karte herstellen. Entweder mit System in CP/M-Partition
oder als CPMDSK_A.IMG auf einer FAT16-Partition
- Das MyZ80-Image aus dem folgenden Beitrag runterladen und als
CPMDSK_B.IMG auf die FAT16-Partition kopieren:
Beitrag "Re: CP/M auf ATmega88"
Das Ergebnis sollte ein 8 MB großes Laufwerk B: uter CP/M sein.
Wenn Deine cpmtools mit libdsk compiliert sind, kann das Image auch auf
dem PC mit Dateien gefüllt werden.
> cpmcp -f myz80 ...
Hallo,
hier der Entwurf der 8-Bit Minimalvariante.
Optionen:
- FTDI durch Peters Platine ersetzen
- ISP Buchse einsparen (Programmierung über Bootloader)
Bitte Vorschläge, Änderungswünsche, Kritik....
Joe
Ich würde den FTDI nicht ersetzen, sondern zusätzlich eine Stiftleiste
vorsehen, damit man wahlweise den FTDI oder Peters Adapterplatine oder
meinen MAX232 verwenden kann.
Ich kenne jetzt die Belegung der Stiftleiste nicht, aber wenn dort TxD,
RxD, GND und 3V3 drauf wären, wäre ich schon sehr zufrieden.
Auf die ISP-Buchse würde ich nicht verzichten. Das habe ich bei einem
anderen Projekt (notgedrungen) und vermisse die Möglichkeit, direkt über
ISP programmieren zu können, doch sehr.
Hier die die Version mit USB-Type A Stecker und Adapter zur
"Peterplatine"
Peter, bitte mal schauen, ob die Anschlußbelegung korrekt ist. Gerade
bei TXD und RXD bin ich mir nicht sicher weil ich nicht weiß wo diese
Pins am IC liegen.
Joe
Hallo Peter,
gibt es das Modul auch in Deutschland zu kaufen? Oder nur in Hongkong..
habe da sehr schlechte Erinnerungen....
Anmerkung zur Schaltung... Wo bleiben diejenigen welche noch eine
serielle Schnittstelle haben... mir fehlt da ein Spannungsregler 3,3V...
Gruß
Hans-Werner
Ob es das Modul noch - zu diesem Preis - woanders gibt könnte google
klären.
Ich habe da mit der Bestellung sehr gute Erfahrungen gemacht!
Ansonsten bleibst ja noch FT232RL + USB Buchse. Der FT232 stellt
ebenfalls
3,3V zur Verfügung. Und wenn das immer noch nicht reicht.. 3,3V
Netzteile gibt es bei Pollin + ungebautes Handydatenkabel = TTL<->USB
Schnittstelle.
Peter
@Joe: Wenn du dann bei Eagle und dem layouten bist.. kannst du bitte die
4-bit Platine auch noch mal anpassen.. Da war ja Pin 24 - /WE und Pin 27
- IO3 getauscht worden.. ich bekomme das irgendwie in eagle nicht hin..
dann hat man, falls man noch mal die 4-bit Version fertigen will gleich
die richtige Platine..
Danke, Peter
Dankeschön! ;-)
Für die kommende Easy-8-bit Platine bitte hinter dem CP2102 Adapter vor
der Versorgung der IC's+SD etc. in der +3.3V Leitung einen Jumper
vorsehen für
einen Ein-/Ausschalter.. so kann man schon einstecken und die USB
Schnittstelle wird erreichbar.. Terminalprogramm kann gestartet werden
und
dann erst kann man dem Gerät seinen Strom geben und kann so die
Bootmeldungen
auch im Terminalprogramm verfolgen.. ohne diese Schaltmöglichkeit sieht
man nach <Return> nur noch den A> Prompt..
Peter
Ich kann die 3.3V trennen, jedoch kann der Bootvorgang wie von Andreas
beschrieben über den RESET Taster am AVR ausgelöst werden, was RESET auf
der CP2102 Platine macht kann ich nicht sagen, da ich die Schaltung
nicht kenne. Möglicherweise sollte hier der Jumper rein.
Joe
@Andreas+Joe: Ihr habt Recht. An den Resetschalter hatte ich gar nicht
mehr gedacht (fehlt auf meinem LR Aufbau). Das reicht..
Habe auch mal das myz80 8MB Image probiert. Klappt wunderbar.. 8MB große
Disketten.. wie bekommen wir die nur gefüllt.. ;-)
Muß mir jatzt mal die diskdefs Einträge für myz80 heraussuchen..
Wer hat denn ggf. noch andere Anwendungen, die jetzt schon mit
emulierter 8080 CPU laufen..? Gibts da schon Turbo Pascal für?
Ich habe mal ein Wordstar Diskimage mit dem aktuellem Bios angehangen.
Hier noch ein eagle3D Bild der 4-bit V1 Platine..
Peter
Inzwischen habe ich auf meinem Netbook unter Windows den CP/M Emulator
aliados[1] installiert. Funtioniert ganz gut, und scheint etwas
einfacher zu sein als zxcc.
Mit dem aktuellen Makefile im cpm-Zweig[3] kann jetzt auch unter Windows
ein Disk-Image mit IPL+CPM+BIOS etc. erstellt werden. Dazu müssen make,
cpmtools[4], aliados und das ein oder andere Kommandozeilenprogramm im
PATH gefunden werden. Wer nicht gleich ein komplettes Cygwin oder mingw
installieren möchte, kann es ja mal mit den UnixUtils[5] versuchen. Sehr
einfach zu installieren. und funtioniert bei mir wunderbar.
Das Ganze ist sicher noch Verbesserungsfähig. Ich würde mich freuen,
wenn das mal jemand ausprobieren würde.
Außerdem habe habe ich mal die Diskimages (*.ydsk Dateien), die bei dem
CP/M-Emulator YAZE-AG[6] "mitgeliefert" werden, getestet. Es können alle
gelesen werden.
Leider sind nur wenige davon für uns interessant, da entweder zu
speziell oder nur für Z80. Am interessantesten dürften der Hi-Tech C
Compiler und vielleicht die Unixlike Tools sein.
Damit die Image-Dateien von unserem System gelesen werden können, habe
ich sie CPMDSK_A.IMG .. CPM_M.IMG umbenannt und jeweils eine Hand voll
auf eine FAT16 Partition auf der Speicherkarte kopiert. Damit die mit
den "höheren" Buchstaben auch gelesen werden können, war leider ein
kleiner Bugfix notwendig. Im avr-Zweig des SVN-Archives gibt es also
auch ein Update.
[1] http://www.arrakis.es/~ninsesabe/aliados/
[3] http://cloudbase.homelinux.net/viewvc/avr-cpm/avrcpm/trunk/cpm/
[4] http://www.cpm8680.com/cpmtools/
[5] http://unxutils.sourceforge.net/
[6] http://www.mathematik.uni-ulm.de/users/ag/yaze/
Peter Sieg schrieb:> Prima! Da ich kein SVN inst. habe.. welche Datei(en) muß ich mir> herunterladen..?
Um alles herunter zu laden, begebe man sich z.B. hier her:
http://cloudbase.homelinux.net/viewvc/avr-cpm/avrcpm/trunk/
Dann klicke man rechts oben auf "Download Tarball".
Wenn man nur einen Teil (z.B. den CP/M-Teil) haben will, steige man in
das entsprechende Directory hinab, und klicke eben da auf "Download
Tarball".
Wenn man nur eine einzelne Datei herunter laden will, klicke man auf den
Namen der Datei oder auf die Revisionsnr. Anschließend findet man rechts
oben "Download File" (Imho umständlich und nicht empfehlenswert).
Wenn man aber öfters mal nur die geänderte(n) Datei(en) laden will,
installiert man (unter Windows) am Besten TortoiseSVN
(http://tortoisesvn.tigris.org/).
Das ist einfach eine Erweiterung des Windows Filemanagers um die
SVN-Client-Funktionen (Siehe Anhang).
Peter Sieg schrieb:> Muß mir jatzt mal die diskdefs Einträge für myz80 heraussuchen..
In meiner diskdefs ist folgender Eintrag
1
# MYZ80 hard drive (only works with libdsk, because it has a 256-byte header)
2
diskdef myz80
3
seclen 1024
4
tracks 64
5
sectrk 128
6
blocksize 4096
7
maxdir 1024
8
skew 1
9
boottrk 0
10
os 3
11
end
Der war wahrscheinlich in der Original-Datei, bin mir aber nicht sicher.
> Wer hat denn ggf. noch andere Anwendungen, die jetzt schon mit> emulierter 8080 CPU laufen..?
Ich hatte ja schonmal die die Diskimages vom simh Altair 8800 Emulator
emphohlen:
Beitrag "Re: CP/M auf ATmega88"
Für die Spielkinder unter uns habe ich mal das Basic- und das
Games-Image auf HD-Format umkopiert und als Zip hier angehängt. Viel
Spaß damit.
Von simhd kann jetzt auch gebootet werden. Um ein solches Bootimage zu
erkennen, muß im 1. Sektor (ipl) eine Marke vorhanden sein. Das
cpm/Makefile kann diese Marke erzeugen. Z.B. so:
1
$ make clean
2
$ make diskimage IMGFORMAT=simhd
Oder das Makefile entsprechend anpassen.
Ein fertiges Image habe ich hier mal angehängt.
Na.. ein bißchen ruhig geworden hier..?
@Joe: Stand 8-bit Simple Platinen?
Ich hatte hh3au (oder so ähnlich) mal per Mail kontaktiert, ob er die
Z80 Emulation nicht noch abschließen könnte.. ohne jede Antwort.. :-(
Gruß Peter
Peter Sieg schrieb:> @Joe: Stand 8-bit Simple Platinen?
Ich mußte erst noch ein anderes Projekt abschließen. Der Schaltplan
steht ja, das Layout auch in den Grundzügen, es muß nur noch "schön"
gemacht werden.
Gruß Joe
Ah. Hallo Horst. Schön wieder von Dir zu hören.
Ich zumindest nicht aktuell.. Gut Ding will Weile haben.
Freue mich das du noch mit im Boot bist!
Gesundheit geht vor! Alles Gute derweil!
Falls du aber irgendwann schon einen lauffähigen Zwischenstand
hättest, würde wir den gerne schon mal im Code mit aufnehmen.
Gruß Peter
Ich hab mal eine Frage ...
Ich weiß nicht ob die in dem Thread hier schon gestellt worden ist oder
nicht, aber ich würd gerne wissen ob es vom Timing her möglich ist die
Ansteuerung des DRAMs in C zu machen.
Ich stelle mir das so vor das ich 3 Routinen habe. Eine liest ein Byte,
eine zweite schreibt ein Byte und eine dritte macht den Refresh.
Damit der Refreh immer regelmäßig kommt wird die Refresh-Routine in
einen Timer-Interrupt gepackt der schneller ist als die notwendige
Refresh-Zeit. Die Lese und Schreib-Routine kann den Interrupt sperren
damit die Ansteuerung nicht verfusselt wird, daher wird der Refresh auch
öfter ausgeführt als notwendig, so die Idee.
Ich selbst habe das CP/M noch nicht ausprobiert da mich in erster Linie
die Hardware (DRAM, SD-Karte und der FTDI) als kompakte Platform für
Bastelzwecke interessiert.
Wäre mein "Vorhaben" so realisierbar, oder ist das Timing des DRAMs zu
kritisch, alsdass es in C umsetzbar wäre zw ist ?
ein Hallo an alle!
Ich habe seinerzeit auch mit dem legendären Z80 (bzw. U880) gearbitet
und mir so manchen SBC damit gebaut. Das letzte war der Mugler-PC mit
CPM 2.2, danach habe ich den Z80 und CPM aus den Augen verloren. Hatte
neben Arbeit und Familie nicht mehr genug Zeit für ein solch
Zeitintensives Hobby und nach einem Arbeitstag am PC auch keine rechte
Lust mehr.
Mit großem Interesse habe ich diesen Tread gelesen. Leider scheint er
aber einzuschlafen.
Ich hätte Interesse an 2 Platinen der "großen" Version mit 168'er, zwei
4Mx4 dRAM und Header für Micro VGA sowie Peter's USB<->Seriell Wandler.
Gibt es hierzu schon ein EAGLE - Project?
Wie weit ist der Arbeitsstand bei der Z80 - Emulation, kann mann diesen
irgendwo einsehen? Ich könnte mir vorstellen, dass ich mich an dieser
Stelle einklinke. Da die 8080 Codes ja offensichtlich funktionieren,
sollte die Einbindung der zusätzlichen Z80 spezifischen OP-Codes ja
reine Fleißarbeit sein - oder sehe ich das falsch?
Gruss Edgar
Rene B. schrieb:> Wäre mein "Vorhaben" so realisierbar, oder ist das Timing des DRAMs zu> kritisch, alsdass es in C umsetzbar wäre zw ist ?
Hallo Rene,
kritisch ist da nix, nur deutlich langsamer.
Zum Anfangen könntest Du mal die angehängten Dateien versuchen.
Compiliert fehlerfrei, ist aber nicht getestet.
Für den Refresh kann man auch die ASM-Datei verwenden. Die Routine
verändert keine Register. Man kann sie notfalls auch in ein C
Inline-Statement setzen.
Leo
@leo
Danke schön. Die Geschwiondigkeit ist erstmal nicht so wichtig.
Hauptsache ich weiß das es da nichts superkritisches vom Timing her
gibt.
Das die DRAMs ja eig. "dumm" und recht einfach gehalten sind denke ich
auch das es nicht so kritisch ist, aber wollte nochmal andere Meinungen
dazu hören. Testen werd ich es dann mal. Mit dem ASM in C hatte ich auch
schon überlegt, wollte aber erstmal alles in C machen.
Vielen Dank noch.
Die #define packt man sinnvollerweise in die Headerdatei.
Außerdem hatte ich vergessen zu erwähnen, daß die C-Routinen nur mit der
8-Bit Version funktionieren, und nur 64 kByte adressieren können. Beides
kann man natürlich ändern und ich überlasse es dem geneigten Leser gerne
zur Übung. ;)
Joe G. schrieb:> Ja, gibt es. Ich habe es mal hier aktualisiert.> http://www.mikrocontroller.net/articles/AVR_CP/M
Hallo Joe G.,
das sieht ja echt gut aus - Respekt!
Wird es eine Sammelbestellung für diese 2.(grosse) Variante geben?
Wenn ja, dann melde ich schon einmal 2 Platinen für mich an. Mit welchem
Preis pro Platine müsste man rechnen?
Gruss Edgar
Hallo Joe,
wird bei dieser Variante die Platine vom USB mit Strom versorgt?
dann hätte ich Interesse an 2 Platinen...vorausgesetzt es wird mal etwas
mit der Implementierung des Z80 Codes und mit dem Datenaustausch unter
Windows.
Gruß
Hans-Werner
@Hans-Werner
Diese Variante kann über USB mit 5V versorgt werden oder mit 3.3V über
den Steckverbinder für Peters Adapter. Die interne 3.3V Versorgung wird
bei der Bestückung mit dem FT232 wieder über den internen Regler
realisiert. Ansosnten entspricht die Schaltung fast der ursprünglichen
Version bis auf die Datenbreite von 8-Bit.
Der Datenaustausch unter Windows sollte mit der FAT-Version kein Problem
sein. Die MMC-Karten können damit nur über Windows beschrieben werden.
Linux ist nicht notwendig.
Joe
@Joe: auch ich würde gern 2 Platinen haben wollen
@Peter: handelt es sich hier um die AVRCPM-Platine, für die seinerzeit
ein Aufruf (auch im robotronforum) gestartet wurde ?! Ich habe in Sachen
Hardware ja schon seit einigerzeit nichts mehr gelesen.
Gruss,
Andreas
Hallo,
ich bin zufällig über dieses Projekt gestolpert. Meine Hochachtung! Ich
habe früher auch mal mit CPM gespielt. Ich habe mit dem CPM nichts vor
finde aber die Platine für etwas anderes interressant. Um eventuell das
noch zu unterstützen würde ich auch eventuell Platinen nehmen. Gibt es
da einen aktuellen Schaltplan und Eagle-Files bzw. SD-Kartenslotbauform?
Was kostet die Platine?
MfG
Achim
GPS'ler schrieb:> Gibt es> da einen aktuellen Schaltplan und Eagle-Files bzw. SD-Kartenslotbauform?> Was kostet die Platine?
Einen Schaltplan bzw. die Eagle-Files gibt es etwas weiter oben unter
avr_cpm.zip
Die Platine kostet ca. 10€-12€. Das kommt noch auf die Gesamtmenge an.
Hallo @Joe,
vielen Dank für Deine Info. Für mich wäre wünschenswert, dass man die
3,3V von extern einspeisen könnte. Jumper/Pfosten an R2 würde ohne
grossen Aufawand gehen. Für mich ist die interne 3,3V Versorgung etwas
wenig (50mA). Ist das nicht auch für eure Anwendung grenzwertig
(SD_Karte,IC5,IC6,IC1). Habe das aber nicht explizit geprüft. Besser
wäre natürlich ein eigener LowDropRegler von den 5V als Zusatz.
Nur zum Hintergrund:
Aber das hat mit dem eigentlichen Projekt nichts zu tun.Ich würde IC5
und IC6 nicht bestücken und da einen GPS Empfänger dranhängen bzw. die
ADC Eingänge und könnte dann einfach einen Logger daraus machen.
MfG
Achim
Ps.: Sorry für das abschweifen vom eigentlichen Threadthema
Hallo, ich bin von dem Projekt begeistert. Seit einem halben Jahr
verfolge ich die Beiträge. Nun habe ich Blut geleckt und will mit einem
Freund die Platine aufbauen. Ich bestelle vier Platinen.
Gruß Peter
GPS'ler schrieb:> Für mich wäre wünschenswert, dass man die> 3,3V von extern einspeisen könnte.
Wenn der FT232 nicht bestückt wird, können die 3.3V auch über JP3 Pin 1
eingespeist werden. Das ist für alle Anwendungen, die einen anderen USB
Adapter verwenden wollen. Wird der FT232 selbst bestückt und man möchte
die 3.3V über JP3 Pin 1 einspeisen muß die Verbindung zum Regler des
FT232 aufgetrennt werden. Das habe ich nun mit JP1 realisiert. Erfolgt
die Stromversorgung über USB, kann statt JP1 eine Brücke eingelötet
werden. Dank Leo C. haben wir ja immernoch die beiden I2C Leitungen des
AVR frei. Auch wenn es noch keine Anwendung dazu gibt, habe ich sie nun
auf JP5 gelegt. Paltz war ja noch auf der Leiterplatte.
Joe
Hallo
das ist ne feine Sache, So kann man das auch für andere Zwecke nutzen.
Kann ich noch den Hintergrund erfahren, warum RX/TX vom Atmega nicht für
die USB Komminikation benutzt wird? Wird das da Software mäßig gemacht?
In meinem Fall ist das gut, da kann man dann ein GPS-Modul dranhängen.
MfG
Achim
Port D des AVR liegt vollständig am 8-Bit Datenbus des RAM. Damit müssen
die Daten nicht umständlich zusammengestückelt werden wie in der
Urversion. Kein Vorteil ohne Nachteil. Die V24 Schnittstelle läuft nun
über andere Pins und wird per Software nachbgebildet (siehe Quelltext
von Leo C.).
Hallo
in der Ecke bei R2 oder C10 würde noch gut eine LowDrop 3,3V
Spannungsregler als als Bestückungsoption für externe 5V bzw. USB 5V
passen......
MfG
Achim
Ps: Ich bin mit 3 Platinen dabei...
Hallo @Joe,
vorneweg, ich habe noch nie eine Leiterplatte mit Eagle entworfen und
dadurch keinerlei Erfahrung in dieser Richtung!
....aber kann es sein, dass die SD-Karte Spiegelverkehrt ist und würde
nur passen, wenn das auf der Unterseite wäre. Ich habe mehrere
SD-Kartenhalter und wollte testen ob diese in etwa passen. Aber leider
nein. Dabei ist mir aufgefallen,dass die SCDA... falsch angeschlossen
sein müßte.Im Manual von denen steht "Viewed from the mounting face
side". Ich habe dein Layout ausgedruckt und ne SD Karte draufgelegt. CS
ist der erste bzw. 2. Pin nach der Abschrägung....
Eventuell liege ich voll daneben.....deshalb prüfen....
MfG
Achim
Ps: Eventuell kannst du die Pads nach recht verlängern (Falls das bei
euererKarte nicht stört) , dann würde es auch für meine passen...
Anbei die LIB
Ein 3.3V Regler mit T092 Gehäuse ist nun integriert. Muß ja nicht
bestückt werden.
Die SD-Card ist korrekt. Schau mal hier:
http://www.mikrocontroller.net/articles/AVR_CP/M
Die Karte wird immer so gesteckt, dass die Kontakte oben liegen, d.h.
die Schräge ist auf der linken Seite.
Joe
Hallo
@Joe danke für die Aufklärung. Da wird die Karte mit den Kontakten nach
oben reingesteckt. Kannte ich bisher nicht. Also Sorry...
Ich brauche das nicht, aber ist die Taktleitung vom FT... über den
Jumper zum Atmega nicht relative lang...
>Ein 3.3V Regler mit T092 Gehäuse ist nun integriert. Muß ja nicht>bestückt werden.
..super an welchen hast du da gedacht (Verfügbarkeit CSD hat da nur
TO-220)
Wann geht da die Bestellung los?
MfG
Achim
Hallo,
die Version 3.0 macht wirklich einen hervorragenden Eindruck. Ich nehme
auch 2 Stück von den Platinen.
Wie macht ihr das mit der Verrechnung?
siggi
Bei einer derzeitigen Abnahmemenge von 20 Stück würde eine Platine 9,80
€ + Porto kosten.
Ich warte noch die kommende Woche auf Interessenten bzw. die
Kontaktdaten. Am Freitag würde ich dann eine Mail an alle Interessenten
in meiner Kontaktliste senden. Übers Wochenende sind dann noch
Korrekturen möglich und am 25.07. würde ich dann die Bestellung
auslösen.
Joe
Hallo
@Joe von Reichelt gibts den LE 33 CZ der müßte doch auch gehen oder?
Hast du da auch die entsprechenden C's vorgesehen?
MfG
Achim
Ps: Ist E-Mail an dich nur mit Anmeldung möglich?
GPS'ler schrieb:> @Joe von Reichelt gibts den LE 33 CZ der müßte doch auch gehen oder?
JA
> Hast du da auch die entsprechenden C's vorgesehen?
JA
> Ps: Ist E-Mail an dich nur mit Anmeldung möglich?
JA
Dieses Projekt ist EINFACH - NUR - GEIL!
Ich hätte damals(tm) meinen rechten Arm für eine CP/M Maschine gegeben.
Hab gelötet und gefrickelt wie ein Wilder, aber am Ende wurde es dann
doch ein ZX80 :-)
Ich würde auch eine Platine (USB Stick) abnehmen.
Ich reihe mich auch mal in die Riege der Leute ein die dieses Projekt
Klasse finden :-)
Die neue Version hat echt was. Kann mit der alten Version ja noch bis
zum Sankt-Nimmerleins-Tag spielen (ohne die ursprüngliche CP/M-Version
wirklich zu nutzen :-))))
Was ich bei der neuen Version echt witzig finde ist das I2C
herausgeführt ist. Freut mich.
Echt gelungen.
Als erstes ein Danke für das Design und die Organisation der Platine.
Ich nehme natürlich auch eine, auch wenn es für mich eine
Herausforderung sein wird, den FT232 auf die Platine zu löten.
Andreas Jakob schrieb:> Grad gefunden.> DRAM´s für 99 cent, leider nur SMD.
Ist ja echt witzig, was ihr so findet. Allerdings lassen sich diese SOJ
Teile noch schlechter löten als der FT232 (siehe Variante 2). Die 4C4256
RAM's sind oft noch als Amiga Ramerweiterung in der Bucht aufzutreiben.
@ alle Interessenten der Version 3.0
Alle die sich bei mir per Mail wegen einer leiterplatte der Version 3.0
gemeldet haben, haben eine Mail mit ihrer Menge, dem Preis und weiteren
Informationen erhalten. Wer KEINE Mail erhalten hat, der ist bei mir
nicht erfaßt, Sorry. Entweder habe ich es dann verträumt oder ihr habt
euch noch nicht gemeldet. Bitte dann schnellstens nachholen.
Joe
@Joe: Prima, das du das wieder organisiert- Danke!
Evtl. wäre es sinnvoll (wenn du dir das 'aufbürden' willst), die SD
Slots von CSD gleich mitzubestellen. Ab 25 Stück kosten die <2€ /
Stück..?
Ansonsten müßte die wohl jeder selbst bestellen. Dann kostet einer 3€ +
Versand. Zeit wäre ja noch..
Kannst du bitte die aktuellen Eagle Dateien hier einhängen?
Ich bin noch an einer 'Quelle' von einigen DRams 4x256 DIP dran aud dem
F64.
Leider liest er zur Zeit keine Nachrichten..
Gruß Peter
Joe G. schrieb:> In der Tat, 2,06 € incl. Versand bei einer Abnahmemenge von 25 Stück.> Ich lass mich breitschlagen. Wer möchte? Ab 25 bestelle ich.
Ich nehme dann zu meinen 2 Platinen auch gerne die 2 SD-Adapter.
Gruß und Dank,
Frank
Hi Leute,
Das Projekt ist einsame Spitze! Faszinierend, was man mit einem AVR
alles anstellen kann.
Ich wollt Euch bei dieser Gelegenheit ein ähnliches Projekt vorstellen,
welches ich gerade umgesetzt habe.
Beitrag "Intel 8080 CP/M Emulator für Mikrocontroller (ARM7, ARM9, CortexM3, AVR32)"
In diesem Fall laufen sogar zwei Betriebssysteme auf dem
Mikrocontroller. Nut/OS (kleines Mikrocontroller Echtzeit
Betriebssystem) und CP/M.
Nut/OS dient dabei lediglich als "Wirtsplattform" um z.B. Zugriffe auf
die SD Karte zu ermöglichen.
Das ganze läuft auf allen von Nut/OS unterstützten Platformen mit mind.
80 KByte RAM (ARM7, ARM9, Cortex M3, AVR32, ...)
Viele Grüße,
Ole
PS: Anbei ein screenshot des laufenden CP/M Systems mit WordStar
Startscreen.
(Ausgaben über serielle Schnittstelle im minicom dargestellt.)
Die derzeitige Interessentenliste ist an alle per Mail raus. Bitte
nochmals überprüfen und gegebenenfalls korrigieren. Wünsche nehme ich
noch bis Sonntag entgegen, dann ist Wunschende für die Version 3.0. Am
Montag bestelle ich.
Joe
Hallo CPM/AVR Experten,
ich habe mich da jetzt mal warmgelesen und Geschmack gefunden. Ich habe
nun mit SVN das Projekt runtergeladen und zuerst mal versucht den AVR
Assemblerteil zu übersetzen.
Das Runteladen ist kein Problem (klar!) aber das Übersetzen schon.
zB:
AVRASM: AVR macro assembler 2.1.42 (build 1796 Sep 15 2009 10:48:36)
Copyright (C) 1995-2009 ATMEL Corporation
D:\www\Atmel\UsbStick\SVN_Source\avr-cpm\avrcpm\trunk\avr\8080int.asm(55
): error: printnewline: Unknown instruction or macro
D:\www\Atmel\UsbStick\SVN_Source\avr-cpm\avrcpm\trunk\avr\8080int.asm(56
): error: printstring: Unknown instruction or macro
D:\www\Atmel\UsbStick\SVN_Source\avr-cpm\avrcpm\trunk\avr\8080int.asm(56
): error: syntax error, unexpected STRING
Assembly failed, 3 errors, 0 warnings
Bevor man da jetzt anfängt zu suchen die Frage:
-Gibt es einen AVR-Studio-Projektfile?
Das Ganze soll unter Windows XP erstellt werden. Einige haben das ja
auch unter Windows gemacht und man muß ja das Rad nicht neu erfinden....
Um diesen Thread nicht mit solchen Problemen zu "belasten" sollte man
eventuell einen eigenen Thread "Software CP/M Klinik" aufmachen.
Es geht nicht darum, dass jemand Fehler sucht, sondern da scheint doch
was "generelles" bei Windows zu fehlen (Includes..etc)
Hi. Arbeite auch unter Windows und hänge mal mein ganzes AVR CPM
Verzeichnis hier ein. Kann ggf. nicht unbedingt der letzte SVN Stand
sein und aktuell habe ich nur 4-bit Hardware.
Peter
Hmm, also ich persönlich würde da ja persönlich einen PS/2 Anschluss und
einen Monitoranschluss dran bauen, oder das ganze in ein möglichst
kleines Gehäuse zu packen. So als Art Uhrencomputer.
Hallo @Peter
vielen Dank für das Projekt. Das ist zunächst mal auch nicht
übersetzbar, da viele spezielle absolute Path Angaben im BAT file sind.
Was mich aber zunächst sehr wundert ist zum Beispiel, dass in dem
"8080int.asm" kein "#include "macros.inc" drin ist. Sowohl bei dir, als
auch im runtergeladenen Projekt und das dann bei euch übersetzbar sein
soll.
...aber ich muß da zuerst mal wieder ASM Grundlagen lernen. Ich habe vor
ca. 30 Jahren das letzte mal Assembler (8008/8080/8086) gemacht.
Ich werde versuchen da ein gültiges AvrStudioProjekt zu basteln, so wie
wenn man was vom Radig etc,,, runteläd und problemlos übersetzen kann.
Ich habe eine gehende Windows XP AVR Studio 4 Installation ,it der ich
bisher problemlos Projekte übersetzen konnte. Ausserdem eine
WINAVR-20100110 Standardinstallation
Müssen wir aber hier wirklich nicht vertiefen. Ich versuche mich da
durchzukämpfen.
Vielen Dank
Achim
Ps. Problem ist noch die Beschaffung der DRAMS für die V 3 (für mich)
Frischling schrieb:> Was mich aber zunächst sehr wundert ist zum Beispiel, dass in dem> "8080int.asm" kein "#include "macros.inc" drin ist. Sowohl bei dir, als> auch im runtergeladenen Projekt und das dann bei euch übersetzbar sein> soll.
Hallo,
nur die Datei "avrcpm.asm" sollte durch den Assembler geschickt werden.
Alles andere wird included.
Leider habe ich keine Zeit, auf Details einzugehen. Ab Dienstag wirds
wieder besser.
Hallo Leo,
vielen Dank.Soweit war ich noch nicht vorgedrungen.....Ich hab halt mal
alle genommen.
>>>Assembly complete, 0 errors. 0 warnings
Super! Hat mir für den Einstieg sehr geholfen! Dachte ich mirs doch,
dass es "einfach" gehen muß. Sorry für die "verfrühte" Nachfrage.
Vielen Dank
Achim
Für alle, die sich schon mal im Vorfeld mit der Software befassen
wollen. Unter dem Punkt Downloads
http://www.mikrocontroller.net/articles/AVR_CP/M
habe ich drei CP/M Images reingestellt die unter Windows nur auf eine
SD-Card kopiert werden müssen. Um selbst ein Image zu erstellen, sollten
wir eine kleine Anleitung mit den notwendigen Tools verfassen, was
meinst du Peter?
Hallo
@Peter ALLES klar, jetzt wo du es sagst.....she ich das auch. Mein
Urproblem war, dass ich "avrcpm.asm" als "Entry File" gestzt habe. Wie
oben schon geschrieben ich habe zu früh gefragt! Man sollte eben erst
den Verstand einschalten, denken und dann fragen.......
Nochmals vielen Dank @Leo und @Peter für eure Hilfe. Jetzt scheine ich
in der Spur zu sein. Man wird halt älter....
Sorry
Achim
Aufbauhinweise V3
Die Leiterplatten sollten bald bei euch eintreffen. Deshalb für alle,
die neu dabei sind und natürlich auch für alle anderen, einige
Aufbauhinweise.
1. Wenn die 5V aus der USB-Schnittstelle bezogen werden dann muss JP1
gesteckt sein. Dabei wird der interne 3.3V Regler des FT232 genutzt.
2. Wenn die 5V über JP3 zugeführt werden, JP1 offen lassen.
3. Wird der AVR über einen externen Quarz getaktet, Pin2 und Pin3 bei
JP2 brücken.
4. Erhält der AVR seinen Takt über den FT232, dann Pin1 und Pin2 bei JP2
brücken. Der FT232 muss jedoch vorher über ein Tool, welches von der
FTDI Webseite bezogen werden kann, programmiert werden. CBUS0 muss dann
auf Taktausgabe geschaltet werden.
5. ACHTUNG! Wer den AVR über die ISP Schnittstelle mit externen 5V
programmiert MUSS vorher die SD-Card ziehen, sonst liegen die 5V an der
SD-Card! Das übersteht sie nicht.
Viel Spaß beim Aufbau!
Joe
So hier Bilder meiner ersten Platine.
Läuft alles!
Was ich festgestellt habe:
Das größte Problem sitzt meistens vor dem Rechner ;-) Hatte TTL-USB
Adapter falsch herum angeschlossen. ;-)
Die FAT16 Routinen sind wählerisch was die Karten angehen. 3 gehen
nicht; 2 gehen (1GB Platinen; Noname). Hier gibt es einige
Parallelprojekte (sd2iec) wo man ggf. schauen kann, ob man Code hierzu
übernehmen kann..
Ach ja.. Speed = 2,623 bei 8-bit und 30MHz (5,293 bei 30MHz und 4-bit).
Peter
@Achim: Kann dir 2 getestete Rams zusenden für 5€ unversichert. Wenn
Interesse = Mail senden.
@alle: Leider hat sich mein vermutlicher Ramlieferant aus dem Forum64
seit Wochen/Monaten nicht mehr gemeldet.. von daher sind meine Rams auch
begrenzt. Ich kann max. noch 2x2 Rams abgeben.
Peter
Peter Sieg schrieb:> Läuft alles!
Prima!
Nett auch eine Wahl der Quarzfrequenz. Natürlich muß die Version CP/M
V3.0 mit 30 MHz laufen!
@alle
Ich bin auch noch an einer Quelle für RAM's. Ansosnten muß ein Adapter
von SOJ auf DIP her.
Meine extra Rams sind alle vergeben.
Hier gibts noch 4 Stück zum Preis von 1,50€/Stück - Bestell-Nr.:
100155--:
info@Hefner-Electronic.de
Sehr geehrter Herr Sieg,
wir haben noch 4x Siemens HYB 514256A-70 DIP 20
Mit freundlichen Grüßen
Hefner-Electronic
Gunther Hefner
---
Der 30MHz SMD-Quarz ist von Pollin: Bestell-Nr.: 230079
Wie gesagt, 30MHz ist bereits grenzwertig. Ab 32Mhz lief es nicht mehr.
Wer das Letzte rausholen will.. ansonsten sollten 25MHz (alte Lan-Karte)
sicherer sein..
Peter
1. Gibt es eigentlich schon weitere Aufbauerfolge?
2. Habe noch 2 x 4C256-8 abzugeben, wer hat Interesse?
3. Es gibt neue Platineninteressenten, wer möchte noch und sollte etwas
geändert werden?
Gruß Joe
@Joe: 1 Änderungswunsch: Die RST Leitung des CP2102 Adapters NICHT mit
RESET des AVR verbinden. Sonst wird bei einem Reset des AVR's auch der
Adapter resettet und das macht wenig Sinn.
Peter
Mein mega168 ist jetzt auch eingetroffen, da wollte ich mich jetzt an
den Aufbau machen. Ich möchte das allerdings nicht als USB-Stick bauen,
sondern mit einem MAX232 Pegelwandler und externer 5V-Versorgung an ein
Lear Siegler ADM-3A-Terminal hängen.
Dazu habe ich mir gerade einen Wolf gesucht, wo ich wie welche Jumper
setzen muss - und schließlich wurde mir klar, dass die Eagle Dateien des
Postings vom 8.8. nicht mit der ausgelieferten Platine übereinstimmen.
Unter anderem fehlt der 3V-Spannungsregler.
Kann ich bitte die Eagle-Dateien bekommen, die der Platine entsprechen?
Ich bin verwirrt, die Zip-Datei vom 08.08. enthält den Stand vom
25.07.2011. Das ist der aktuelle Stand mit 3.3V Regler
Welche Jumper sind unklar?
Gruße Joe
Sorry, mein Fehler. Ich hatte offenbar noch eine veraltete Fassung auf
der Festplatte (was mir nicht bewußt war) und habe die beiden
vertauscht. Es ist alles in Ordnung.
Was mir gestern unklar war, habe ich mit dem Durchgangsprüfer geklärt
und die Platine soweit aufgebaut. Ich habe dabei einen anderen
3,3V-Spannungsregler verwendet, den ich noch zur Hand hatte: MCP1702.
Die verbauten 100nF-Kerkos sehen nicht ganz so schön aus, weil ich nur
welche mit Rastermaß 7,5mm zur Hand hatte. Ich habe einen 25 MHz
Grundton-Quarz verwendet mit 18pF-Kondensatoren daran. Gestern habe ich
noch die Fuses auf den Quarzbetrieb umgestellt - zu mehr war leider
keine Zeit mehr.
Bis jetzt sieht alles gut aus :-)
Jup. ZIP sollte noch aktuell sein. Kann nur sein, das im thrunk von Leo
etwas neuere Versionen sind! Am besten schaust du da mal.. letzte
Änderung
war glaube ich, das CP/M / Bios auch von einer 8MB Diskimage geladen
werden konnte..
Peter
Ich habe die AVR-Firmware aus dem trunk assembliert und bekomme jetzt
die Ausgabe:
CPM on an AVR, v2.1
Testing RAM: fill...wait...reread...
Initing mmc...
No bootable CP/M disk found! Please change MMC/SD-Card.
Initing mmc...
No bootable CP/M disk found! Please change MMC/SD-Card.
Wenn ich das richtig verstanden habe, kann diese Version von einer
FAT-16-formatierten SD-Karte aus einer Image-Datei booten? Ich habe aber
nicht verstanden, wie man das bewerkstelligt bzw. fertige Dateien dazu.
Gibt es eine Anleitung dazu? Aus dem Abschnitt dazu aus
http://avr.cwsurf.de/?AVR_CP%2FM bin ich nicht recht schlau geworden.
Oder kann hier jemand eine bootfähige Image-Datei hochladen, die ich
dann nur noch in das Hauptverzeichnis legen muss?
Sehr schön!
Und mit ADM3 Terminal ist dann auch stilecht ;-)
Im avrcpm_aliados.zip sind eigentlich schon disk images anthalten und
alle nötigen Batchdateien um sie zu bilden..
Peter
Interessant sind eure Bestückungsvarianten. Merkwürdigerweise schreibt
die Literatur immer etwas von Abblock C’s möglichst dicht am IC, ja
einen Elko an der SD Card, Pull Up und Pull Downs, …
Ich kann ja bei der nächsten Variante all diesen „überflüssigen“ Kram
weg lassen :-)
Übrigens hier
http://www.mikrocontroller.net/articles/AVR_CP/M
gibt es auch ein Diskimage.
Joe
Danke, die Disk-Images werde ich noch ausprobieren. Erst mal muss ich
aber noch die Pegelwandlung von RS-232 auf 3.3V in den Griff bekommen:
ich habe nicht bedacht, dass ein MAX232 5V-Pegel ausgibt, die für den
bei 3.3V betriebenen AVR zu hoch sind.
Was anderes: ich habe gesehen, wird ein BREAK auf der seriellen
Schnittstelle derzeit noch nicht behandelt. Das ADM-3A hat eine extra
Break-Taste und Terminalprogramme bieten üblicherweise die Funktion, ein
Break zu senden. Das würde die Möglichkeit eröffnen, bei Empfang eines
Breaks einen Kalt- oder Warmstart auszuführen, oder einen Debugger
aufzurufen.
Nils Eilers schrieb:> Pegelwandlung von RS-232 auf 3.3V
Ein 74HVCT08 (siehe Schaltung der AVR CP/M Variante 2) sollte das tun.
Dort hatte ich die Pegelwandlung für die SD Karte so vorgenommen.
Das mit dem Break habe ich nicht verstanden. Wer erzeugt es, wer nutzt
es, was macht es?
Gruß Joe
Die Pegelwandlung probiere ich mal auf dem Steckbrett. Evtl. reicht
schon Spannungsteiler aus zwei Widerständen, ansonsten hätte ich noch
74HC4050 hier.
Break wird leider nur im englischen Text der Wikipedia etwas näher
erklärt:
http://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter#Break_condition
Kurz gesagt ist ein Break ein gesendetes Startbit, dem keine Daten
folgen (0x00) und das auch für die Zeit halten wird, wo eigentlich das
logisch inverse Stop-Bit folgen müsste. Also wie das Senden eines 0x00
mit fehlendem Stop-Bit, was einen framing error ergibt.
Erzeugt wird das durch den Sender, in diesem Fall also ein
angeschlossenes Terminal(programm).
Was es bewirkt, ist nicht allgemeingültig definiert - es hängt ganz vom
Anwendungsfall bzw. der tatsächlichen Hardware ab. Allgemein benutzt man
es dazu, die Aufmerksamkeit des Empfängers zu erregen. Übliche
Anwendungen sind Wechsel der Baudrate oder Reset.
Beim AVRCPM wäre es nützlich, um aus jedem Programm aussteigen zu können
ohne Reset drücken zu müssen - insbesondere deswegen, weil der Speicher
erhalten bleibt.
Ich habe zwar schon Z80 und 6502-Assembler programmiert, aber noch nie
AVR. Die Implementierung sollte aber nicht sonderlich schwierig sein. Im
Grunde nur framing error erkennen (was sowieso der Fall sein sollte),
und wenn die empfangen Daten 0x00 sind, dann haben wir ein Break. Und
dann z.B. ein Reset oder Warmstart auslösen - fertig.
Der ATmega-U(S)ART kann diesen Zustand erkennen (Framing Error +
empfangenes Zeichen = 0).
Unser Software-UART (sw-uart.asm) könnte um diese Funktion erweitert
werden.
Freiwillige vor.
Wenn ich meine Hardware fertig habe, würde ich das gerne probieren. Ich
kann aber nur die soft-uart-Version testen, da ich keine 4-bit-Hardware
mit hw-uart besitze.
So ich habe nun auch eine Platine fertig bestückt.
Auf dem ersten Bild von der bestückten Platine von
Joe (Beitrag "Re: CP/M auf ATmega88")
ist eine USB-A Buchse zu erkennen. Ich habe nun ohne
das groß zu überprüfen auch eine USB-A Buchse eingelötet und
erst nachdem ich sofort einen 'Overcurrent' Fehler am USB
erhalten habe gemerkt daß das Layout für einen USB-A Stecker ist.
Hat mich dann etwas Zeit gekostet die Buchse wieder auszulöten und
auf der Unterseite einzulöten, aber jetzt gehts.
Foto gibts dann Morgen.
Gruß,
Günter
Oh, tut mir leid!
Ich hätte das bei den Aufbauhinweisen mit erwähnen sollen. Irgendwann
früher, weiter oben hatte ich das mal getätigt, jedoch später nicht noch
mal explizit erwähnt.
So, hier die versprochenen Fotos.
Wie gesagt habe ich eine USB Buchse auf der Rückseite,
die Kratzer am USB Anschluß kommen vom Entlöten.
Aktuell rennt hier ein ATMega168 bei 20MHz.
Gruß,
Günter
Ein Dankeschön an alle Beteiligten für das tolle Projekt auch von mir.
Ich bin heute dazu gekommen, die Platine zu bestücken. Funktioniert
alles bestens!
Viele Grüße, Thomas
Unter: http://www.mikrocontroller.net/articles/AVR_CP/M
stehen nun die aktuellen Layout Daten, eine Hexdatei zum Soforttest,
CP/M Immage zum Testen, sowie der Link zur aktuellen Software (Dank an
Leo C.)
Offene Baustellen im Projekt:
1. Z80 Emulation
2. Breakfunktion (Wunsch von Nils)
3. SD-Card Funktion verbessern (es gibt einige Karten, die nicht korrekt
funktionieren)
Überraschenderweise waren die knapp 30 Platinen sofort weg. Es gibt
schon wieder Anfragen nach neuen Leiterplatten. Ich würde ab sofort
wieder Interessenten sammeln. Natürlich sind jederzeit Wünsche,
Änderungen, Erweiterungen willkommen (Peter Resettrennung ist
vorgemerkt)
Joe
Hallo,
Ich würde gerne dem Thema Z80 Emulation ein bisschen Leben einhauchen.
Horst hat, wenn ich es richtig mitbekommen habe, das Thema an den Edgar
weitergegeben.
@Edgar, falls Du hier noch Hilfe benötigst würde ich mich gerne
anbieten.
Gruß,
Günter
So, Hardware ist jetzt erst mal fertig und in ein preiswertes Gehäuse
eingebaut (Reichelt SD 10 SW).
Die Pegelwandlung am MAX232 von 5V nach 3V funktioniert prima mit einem
simplen Spannungsteiler aus einem 1,8K und 3,3K Widerstand. Die
Stromversorgung erfolgt über ein 5V-Steckernetzteil und 1N5818
Schottky-Diode als Verpolschutz. Neben der Reset-Taste gibt's noch eine
LED für den SD-Kartenzugriff. Den Vorwiderstand habe ich auf 55 Ohm
verkleinert, damit sie gut hell leuchtet. Prima wäre noch, die Power-LED
und die Zugriffs-LED in einer Dual-LED zu kombinieren, aber da ich nur
eine Dual-LED mit gemeinsamer Kathode hatte, hätte das einen Transistor
als Inverter erfordert - vielleicht flicke ich den ja mal noch ein ;-)
An den I2C-Bus habe ich noch eine batteriegepufferte Echtzeituhr PCF8583
gehangen - mal sehen, ob und wann die Software das unterstützen kann.
Das wäre eine weitere Baustelle: den I2C-Bus dem emulierten 8080 als
I/O-Ports zur Verfügung stellen: vielleicht so, dass man in eine
I/O-Zelle die Adresse des I2C-Busses schreibt und dann über eine andere
den tatsächlichen Zugriff vornimmt.
Hallo,
bin hier zufällig rein geraten.
Falls benötigt, habe in meiner Chip-Kiste 8+1 Dram gefunden.
Vielleicht sinds ja die Richtigen:
TMS 44C256-80N und 1 M514256B-70R, jeweils 20-polig.
Gruß
W.Schwede
@Winfried: Die TMS 44C256-80N sollten die richtigen sein.
Wenn du sie entbehren kannst -> Mail an peter.sieg1 (at) gmx.de
(oder evtl. auch an Joe, dann können sie mit einer nächsten
Platinenbestellung verteilt werden)
Peter
Thema Echtzeituhr:
Von CP/M 2.2 wohl nicht unterstützt, könnte man sich vielleicht trotzdem
an die BDOS Funktionen 104 und 105 halten.
BDOS Funktion 104 - Datum und Uhrzeit stellen
Aufruf mit C=68h, DE=Adresse des Zeitstempels.
Der Zeitstempel hat folgendes Format:
DW Tag ;Tag 1 ist 1.Januar 1978
DB Stunde ;gepacktes BCD
DB Minute ;gepacktes BCD
BDOS Funktion 105 - Datum und Uhrzeit holen
Aufruf mit C=69h, DE=Adresse des Zeitstempels. Rückgabe A=Sekunden
(gepacktes BCD).
Der Zeitstempel hat folgendes Format:
DW Tag ;Tag 1 ist 1.Januar 1978
DB Stunde ;Gepacktes BCD
DB Minute ;Gepacktes BCD
Hallo Leute,
wer die Augen aufmacht kann klarer sehen...
meine Platine rennt nun auch mit 20 Mhz...
Interessant wäre jetzt die Z80 Implementierung und IO Ports über I2C
Gruß
Hans-Werner
RAM'S
dank Winfried S. gibt es nochmal 9 x DRAMS für das Projekt. Wer
Interesse hat melde sich bitte bei mir. Stückpreis 0,55€ + Porto (0,70€
Warensendung)
Gruß Joe
Es gibt bei genügend Interessenten (noch mindestens 2) nochmals die
Möglichkeit Platinen von der letzten Version zu bestellen.
Wer hat noch Interesse?
Gruß Joe
@alle:
Ich habe mich nun durchgerungen nochmals Platinen in China zu bestellen.
Um den Preis von 10€/Platine halten zu können, mußte ich allerdings
einige mehr abnehmen, sodaß wir wahrscheinlich auch noch Weihnachten
genug davon haben ;-) Reset zwischen USB TTL Wandler + AVR habe ich
entfernt.
Als Abwechslung habe ich die Platinen mit weißem Lötstoplack und
schwarzer Beschriftung gewählt. Das sollte ganz nett (nerd) mit den
schwarzen IC's und dem roten TTL-USB Wandler aussehen ;-)
Sollten so in 14 Tagen da sein. SD Slots würde ich dann auch besorgen,
sodaß 1 Platine mit Slot dann 12,50€ und Versand dann 2,50€ wären.
Wer welche möchte, schicke mir eine Mail mit Anzahl und Lieferadresse
und derjenige bekommt dann meine Bankverbindung zur Vorkasse.
Peter
@alle:
Wie ihr lesen könnt, kümmert sich Peter gerade um die Neubestellung der
nächsten Serie. Die Daten von Bobby und Wahe habe ich schon
weitergeleitet.
Dank Bobby gibt es nochmal 16 DRAM's für das Projekt. Bei Interesse
gleich eine Info an Peter, der tütet sie dann mit ein.
Joe
Platinen sind heute angekommen.. und erste läuft schon ;-)
Bestellte Platinen+Slots gehen morgen zur Post..
Wer übrigens Lust hat.. am 1+2 Okt. findet die Classic Computing in
37603 Holzminden statt (Infos: www.classic-computing.de). Ich werde mit
dem Stick
auch dort sein..
Peter
Hier scheint es auch noch Rams zu geben:
http://www.demotronic.net/
1,50€/Stück ist ok.
---
Ansonsten. Ist ein wenig ruhig geworden..?
Was macht die Z80 Implementierfraktion..?
Aber auch ohne Programmierkenntnisse, kann man z.B weitere Programme aus
CP/M Archiven ausprobieren und in einem neuen Diskimage zusammen
stellen..
Peter
Einen Z80 Emulator könnte ich demnächst zur Verfügung stellen.
Allerdings braucht der mindestens ca. 17K Flash, so dass nur der Mega328
in Frage käme. Dafür ist er aber recht flott. Für "Leos Schleife"
braucht er im FAST Mode (ZX81 Emulator bei 20MHz AVR-Takt und 12 Takten
für einen Speicherzugriff) ca. 0,8 Sekunden, was etwa 3,6 MHz Z80 Takt
entsprechen würde. Eine auf Speed optimierte Variante (braucht ca. 24K)
kommt sogar auf 0,7s was dann etwa 4,1MHz Z80-Takt wären (falls ich mich
da jetzt nicht verrechnet habe).
Jörg
Joerg, schön wär's mal, wenn ein EMU für AVRs wie den mega162 kommen
würde, an den man extern ganz "normale" RAMs über das Memory-Interface
dranbekommt.
So würde z.B. ein 62256/62512 mit 32k/64k RAM gehen. Auch Banking mit
grösseren Chips wäre drin. So dann (glaube ich) in CPM bis 512kb RAM.
@Jörg: Hört sich gut an! Bei den bisherigen Arbeiten zur Z80 Erweiterung
hatte ich den Eindruck, das das aber erheblich kleiner geht mit dem
Tabellenansatz.. so in Richtung +5-8kb.. arbeitet da z.Z eigentlich noch
jemand hier daran..?
Ein 328 hatte ich mal versuchsweise geflasht.. der schien aber mit den
3,3V an Spannungsversorgung nicht zurecht zu kommen..?
BTW: Es sind noch Platinen+SD Slots zu haben! -> Mail.
Peter
Peter Sieg schrieb:> Ein 328 hatte ich mal versuchsweise geflasht.. der schien aber mit den> 3,3V an Spannungsversorgung nicht zurecht zu kommen..?
Peter, ich versuche es heute auch mal mit einem 328 und 3.3V. Ich
berichte...
Über 5K belegen bei mir schon allein die Sprungtabellen:
Ohne Prefix: 512 Bytes
CB Prefix : 512 Bytes
ED Prefix: 512 Bytes
DD Prefix: 1024 Bytes
DD CB Prefix: 1024 Bytes
FD Prefix: 1024 Bytes
FD CB Prefix: 1024 Bytes
Was viel gegenüber meiner "alten Version" an Geschwindigkeit gebracht
hat, ist zum einen die vollständige Ausdekodierung aller Befehle und die
Nutzung des AVR Statusregisters. Außerdem habe ich es aufgegeben das
originale Befehlstiming möglichst genau nachzubilden. Bei vielen
Befehlen ist das Verhalten von AVR und Z80 gleich, da reicht nach der
Operation ein
IN reg_f,SREG
aus, für logische und Schiebeopertionen nutze ich Tabellen. Manchmal muß
man das C Flag über die Operation mittels des T-Flags "retten". Und das
N-Flag habe ich nach GPIOR0.0 verlegt. Bei bedingten Sprüngen etc.
nutze ich dann die Positionen der AVR Flags. Bei den meisten Programmen
sollte das auch keine Probleme bereiten.
Am AVR-CP/M Projekt selbst werde ich mich nicht direkt beteiligen, dafür
habe ich zu viele andere "Baustellen". Aber das "AX81"-Projekt wird
hoffentlich nächste Woche online gehen und damit auch der Sourcecode vom
Z80 Emulator.
Gruß Jörg
Hallo!
Ich hab hier noch ein Problem.
Hab das Projekt entsprechend kompiliert und auf den AVR gebracht, Images
kopiert und das Ganze startet erstmal auch, aber dann
"A: FAT16 File-Image at:255 size"
und Neustart in der Schleife.
Wo kann das Problem liegen?
Andre
Läuft der RAM Test korrekt durch?
Ansonsten sieht mir das ganz nach Kartenunverträglichkeit aus. Einige
SD-Karten laufen nicht richtig.
Nun gibt es mehrere Möglichkeiten.
1. SPI Takt runter setzen.
in der config.inc
#define MMC_SPI2X 1 auf (CLK/2)
#define MMC_SPI2X 0 setzen (CLK/4)
2. debuggen
In der config.inc
.equ MMC_DEBUG = 1
Damit wird über die Schnittstelle der MMC Inhalt ausgegeben. Du erkennst
also ob die Daten von der Karte richtig gelesen werden.
Beim Schalter
.equ MMC_DEBUG = 2 oder größer (siehe mmc.asm) wird der SPI Takt auf
clk/128 gesetzt. Dann sollte es wirklich gehen.
Einige Karten laufen leider nicht. Hier hilft nur Kartentausch oder die
MMC Routine noch mal anfassen.
Geht leider immer noch nicht.
Mit Debug sehe ich, das die Laufwerke erkannt und gelistet werden, dann
"Partinit done.; flags: 30"
Dann kommt noch ein Lesevorgang und wieder Neustart
Hab jetzt 3 Karten verschiedener Hesteller durch, (16/128/256MB),
fertiges Hex-File, selbstcompiliertes HEX, fertige Boot-Images als auch
neucompilierte. Keine Besserung. Hardware ist auch ok, Rams habe ich mal
mit zwei anderen gewechselt. Hmmm ..
@Andre
Die 256K großen Images findest du hier:
http://www.mikrocontroller.net/articles/AVR_CP/M
Welche Hardware verwendest du?
Wird deine MMc richtig initialisiert?
Schau mal bitte nach dem ersten Teil deiner Initialisierung.
CPM on an AVR, v2.1
Testing RAM: fill...wait...reread...
Initing mmc...
mmcInit SPI_CLK_SLOW <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
mmcCMD: 00 00000000 <FF <FF <FF >40 .. 95>95 <FF <01 CMDRes: 01
mmcCMD: 08 000001AA <FF <FF <FF >48 .. 87>87 <FF <05 CMDRes: 05
Es sieht so aus, ob etwas von der Karte gelesen wird, aber falsche
Daten. Nun kann das Image fehlerhaft sein oder die gelesenen
Kartendaten.
Wenn du INS_DEBUG = 1 setzt, kannst du die Codes und Befehle mitlesen
die ausgeführt werden. PRINT_PC = 1 zeigt dir zusätzlich den
Programcounter (hilfreich bei Sprüngen) an. In der derzeitigen
8080int-jmp.asm Lib stehen noch zwei Relativsprünge, entweder durch
"Call" ersetzen oder die neue Lib (siehe Anhang) benutzen.
Der prinzipielle Bootvorgang sollte so aussehen:
ipl.asm wird ausgeführt (läd das CP/M in den Speicher)
Die ersten bBefehle sind:
org $2000
ld sp,$1000
ld hl,"ipl"
call prmsg
Das bedeutet, PC steht auf 2000 und führt den ersten Befehl LD SP, $2000
aus. (31 00 20). Dann kommt der Befehl LD HL, "IPL" usw. Der Debugmodus
sollte also folgendes anzeigen.
Partinit done.
Ok, CPU is live!
PC=2000
C A =00 BC =0000 DE =0000 HL =0000 SP =E737 PC =2000 31 00 20
PC=2003
C A =00 BC =0000 DE =0000 HL =0000 SP =2000 PC =2003 21 37 20
PC=2006
C A =00 BC =0000 DE =0000 HL =2037 SP =2000 PC =2006 CD 2E 20
PC=202E
C A =00 BC =0000 DE =0000 HL =2037 SP =1FFE PC =202E 7E B7 C8
Viel Erfolg!
Joe
do9brx schrieb:> Von 256k war in den letzten Wochen nicht die Rede. Oder hab ich was> überlesen?
Die Images dürfen nicht kleiner sein als 256k soweit ich das
verstanden habe. Daher fülle ich die bei der Erzeugung mit Nullen auf.
Inzwischen werden aber dank Leo C. auch weitere Formate unterstützt.
(z.B 8MB Images).
Nur wenn man eine solches 8MB Image auch als Bootimage verwenden möchte,
muss man die aller neueste Firmware flashen!
Peter
Wie ist den die Geschwindigkeit des Emulators ? laueft Turbo Pascal
drauf ?
Denke drüber nach das ganze auch mal aufzubauen, scheint echt lustig zu
sein.
Ciao Matze
do9brx schrieb:> <\n>PC=2000 <\r>> <\n> A =00 BC =0000 DE =0000 HL =0000 SP =0000 PC =2000 31> 00 20 <\r>> <\n>PC=2003 <\r>> <\n> A =00 BC =0000 DE =0000 <\0><\r>
Der erste Befehl wird richtig gelesen, jedoch nicht korrekt ausgeführt.
Der Stackpointer sollte auf $2000 stehen die Ausgaberoutine bricht
jedoch mittendrin vor der Ausgabe von HL ab. Es gibt eigentlich keinen
Grund für so einen Abbruch. Die Ausgabe ist absolut linear programmiert
(utils.asm). Kann eigentlich nur ein Interruptaufruf dazwischen kommen.
Hast du die aktuellen Quellen (siehe hier)?
http://cloudbase.homelinux.net/viewvc/avr-cpm/avrcpm/trunk/
Ich bin etwas ratlos, hat jemand noch eine Idee?
Ich hatte bisher 2 Ramdefekte, die sich ähnlich äußerten.. FAT16 Images
erkannt. IPL bis ok.. dann Register Dump und HALT (Kein Reset!).
Man darf nicht vergessen, das wir das Ganze (zumindest die Rams)
außerhalb der Spezifikation betreiben.. da könnte das eine oder andere
Bauteil gerade an der Grenze sein..
Elko an der SD Karte bestückt? Spannung nicht unter 3,3V?
Peter
Leider habe ich ausser Deinen keine anderen Rams :-( Hab mein Lager
komplett durchwühlt aber leider nichts zum Ersatz gefunden.
Die Quellen waren die aktuellen, Elko ist bestückt, Spannung ok.
Werd mir das am Wochenende nochmal genauer ansehen, bis dahin muss ich
ein paar andere 8-Bit Baustellen abschließen.
Gruß, Andre
Habe heute mal versucht meinen 4-bit Prototypen (1x 4256 Ram), kein
Stützkondensator etc. an einem Atari ST als Terminal anzuschließen.
Dazwischen ein Max3232 3,3V TTL auf RS232 Wandler.
Der Prototyp hatte zuletzt über CP2102 TTL USB Adapter immer einwandfrei
am PC über USB funktioniert.
Baudrate auf 9600 8N1 geändert um den ST nicht zu überfordern ;-)
---
Auf einmal hatte ich ähnliche Phenomene wie du!? Reset nach Anzeige
Part. bzw. FAT16 Files und/oder illegal opcode etc. Manchmal auch erst
nach DIR Anzeige etc. = Instabiles Verhalten
???
Habe daraufhin einen 10uF Stützkondensator eingebaut. Spannung gemessen
3,7V von einem starken Steckernetzteil.
Keine wirkliche Verbesserung.
Ram getauscht - keine Besserung.
Ram getauscht auf einen Siemens HYB514256B-70 - damit scheint es nun
stabil zu gehen..??
---
Ich kann da wirklich keine intelligenten Schlüsse raus ziehen ausser:
Der CP2102 schein den AVR CPM nicht zu beeinflussen/beinträchtigen.?
Der MAX3232 Wandler aber irgendwie schon..?
Wohlgemerkt alle Rams die nun Probleme machten liefen mit CP2102 ohne
jedes Problem!
Peter
Peter Sieg schrieb:> Habe heute mal versucht meinen 4-bit Prototypen (1x 4256 Ram), kein> Stützkondensator etc. an einem Atari ST als Terminal anzuschließen.> [...] Habe daraufhin einen 10uF Stützkondensator eingebaut.> Ich kann da wirklich keine intelligenten Schlüsse raus ziehen ausser:> Der CP2102 schein den AVR CPM nicht zu beeinflussen/beinträchtigen.?> Der MAX3232 Wandler aber irgendwie schon..?
Der MAX3232 verwendet eine Ladungspumpe, um die für die RS-232
erforderlichen Spannungen zu erzeugen. Das kann auf der
Versorgungsspannung stören, wenn nicht (die richtigen)
Stützkondensatoren eingebaut sind.
Die Größe der Stützkondensatoren richtet sich nach der Frequenz der
Störungen: je kleiner die Frequenz, desto kleiner muss der Kondensator
sein, damit er schnell genug nachliefern kann. Wenn der 10µF Dein
einziger Entstörkondensator ist, solltest Du es auf jeden Fall noch mit
einem 100nF zusätzlich probieren.
Oft werden auch ganze Reihen verwendet, wie z.B. 100nF, 1µF, 100µF.
100nf sind auch schon drin gewesen.. der ist bei mir immer Standard ;-)
Was auf dem Wandler drauf ist, kann ich nicht entziffern (Fertigmodul)
sieht aber sehr klein aus, so wie 0,1 - 1uf - 5 Stück davon.
Peter
Na, damit sich auch mal wieder was zum Thema AVR CPM tut, hier ein
Diskimage mit Microsoft Multiplan V 1.2.
Entzippen und nach CPMDSK_E.DSK umbenennen. (Anstatt E auch ein anderes
virtuelles Laufwerk je nach Geschmack).
Vorher 1x Install.com ausführen und bei mir auf VT52 = Nr. 23
einstellen.
Peter
Für die, die nicht selber zusammen bauen möchten/können, habe ich auch
noch ein paar wenige, fertig aufgebaute und getestete AVR CP/M USB
Sticks inkl. passender SD Karte abzugeben. Bei Interesse -> Mail.
Peter
Hier ALGOL Compiler (P-Code) und Interpreter.
ALGOLM name.ALG -> Übersetzt nach name.AIN
RUNALG name.AIN führt aus.
2 Beispiele dabei.
Hanoi läuft einwandfrei.
Lunar läuft? Kommt nach Eingabe der Zahl nicht zurück..? unter Altairz80
ok.
---
Ich glaube, wir habe evtl. noch einen, kleinen Fehler in der 8080
Emulation..
Mal Multiplan starten in in r1c1 12, in r2c1 24 und in r3c1 =r1c1+r2c1
eingeben (Summe aus 12+24). Dann r1c1 auf 17 ändern.. ;-)
---
Hier mal wie ich solche Diskimages zusammen stelle.
Altairz80 herunterladen und CPU = 8080 einstellen!. cpm2 laden.
Diskimage z.B von retroarchive herunterladen und testen.
Wenn sie laufen, die Dateien mit w aus dem Image auf Filesystem
schreiben.
Mit cpmcp dann in ein leeres avrcpm Image kopieren.
Image auf SD Karte kopieren und ausprobieren.
---
Arbeitet eigentlich jemand noch/wieder an der Z80 Unterstützung, jetzt
da ein Z80 Emulator im Source (AX81) verfügbar ist..?
Peter
Peter Sieg schrieb:> Für die, die nicht selber zusammen bauen möchten/können, habe ich auch> noch ein paar wenige, fertig aufgebaute und getestete AVR CP/M USB> Sticks inkl. passender SD Karte abzugeben. Bei Interesse -> Mail.>> Peter
gibt es auch noch die variante mit dem vga anschluss (vers. 2...?). was
kostet ein stick?
Ronny Minow schrieb:> gibt es auch noch die variante mit dem vga anschluss
Nein, alle Bausätze sind raus. Von Stick müßte es noch genug geben,
einfach Peter fragen.
Ich bin gerade an einer neunen VGA-Variante als VT100 Terminal. Ist aber
noch ein Brettaufbau.
Joe G. schrieb:> Ronny Minow schrieb:>> gibt es auch noch die variante mit dem vga anschluss>> Nein, alle Bausätze sind raus. Von Stick müßte es noch genug geben,> einfach Peter fragen.> Ich bin gerade an einer neunen VGA-Variante als VT100 Terminal. Ist aber> noch ein Brettaufbau.
wenn es da auch bausätze geben wird, nehme ich gerne eins
Joe G. schrieb:> Ich bin gerade an einer neunen VGA-Variante als VT100 Terminal.
Hier nun die ersten Ergebnisse. Das VT100 Terminal läuft vollständig
ohne PC mit der AVR CP/M Platine. Für VGA und PS-2 werden genau zwei
IC's verwendet (1 x P8X32A und 1 x AT24C512 als Speicher). Läuft alles
auf 3.3V, somit sind auch keine Pegelwandler notwendig.
pollmull schrieb:> Oder hier mit gleichem Chip Terminal gleich noch mit CP/M drin:
Ganz nett, vielelicht baue ich mal das Dracblade in der V5 auf. Die Z80
Emulation ist darin vollständig enthalten.
Joe G. schrieb:> Ganz nett, vielelicht baue ich mal das Dracblade in der V5 auf. Die Z80> Emulation ist darin vollständig enthalten.>
Oder einen Hive (hive-project.de), da läuft grad wieder eine
Sammelbestellung der Boards. Wenn du dich beeilst, kannst du sicher noch
teilnehmen.
Da nun bald Weihnachten wird, gebe ich einige, restliche Platinen des
AVR CP/M USB Sticks unter SK ab für 6,50€/Stück. Habe noch 7 Stück da.
Es gibt NUR die Platinen!
Bei Interesse per Mail melden bei: peter (dot) sieg1 (at) gmx.de
Versand per Post für 2€ in D egal wie viele Platinen.
Peter
Hier etwas für die Feiertage.
Die Version 4.0 mit VGA auf einer Platine.
Änderungen gegenüber der alten Version:
- VGA mit VT100 Terminal auf einem Propellerchip
- SRAM
- ATMEGA 644
- zwei serielle Schnittstellen
- 8 Bit –E/A
- Stromversorgung über USB
USB1 ist für die Inbetriebnahme und Experimente gedacht. Über diese
Schnittstelle kann der Propeller geladen werden und die CP/M Ausgaben
über ein Terminal mitgelesen werden. Werden die Steckbrücken (JP1 und
JP2) richtig gesteckt, dann ist das CP/M-System direkt mit dem VT100
Terminal verbunden.
USB2 ist für alle Anwendungen frei. Denkbar ist z.B. ein Bootloader für
den AVR. Damit muss bei der Softwareentwicklung der AVR nicht jedes Mal
über die ISP-Schnittstelle geflasht werden.
Der DRAM wurde durch einen handelsüblichen SRAM ersetzt. Damit sind
jedoch zwei zusätzliche Latch notwendig geworden.
Durch den Wechsel auf den ATMEGA 644 ist nicht nur noch eine weitere
serielle Schnittstelle dazu gekommen, sondern auch noch ein komplett
freier 8-Bit Port. Belegt habe ich PA0 bis PA7, damit können die Pins
auch als 8-fach ADC verwendet werden.
Die Software muß natürlich noch angepasst werden. VGA und VT100 Terminal
läuft schon.
Schöne Weihnachten!
Joe
Ich weiß nicht, wurden am Beginn des Projektes nicht alle, die mit SRAM
kamen, mit den Worten: "Das ist dann ganz was anderes, mach eine eigenes
Projekt auf!", fortgeschickt? Ich meine der Reiz war ein CP/M auf zwei
Chips. Das haben wir mit 2xRAM für 8-bit schon aufgeweicht. Noch ein
Chip sind dann doch etwas über einer großzügig ausgelegten Definition
von 2 Chips, meiner Meinung. Außerdem frage ich mich ob eine
zusätzliche, inkompatible HW-Version Softwareentwickler anlocken kann.
Da müssten dann langsam HW-Abstraktionsschichten eingezogen werden ;-)
Das bindet doch nur Resourcen, die sowieso nicht da zu sein scheinen.
Ich hätte lieber Z80 als HW-V4.
Nur meine bescheidene Meinung.
frank
Hallo Frank,
endlich mal eine Meinung der ich mich anschliessen kann...
Nur leider bin ich nicht der richtige für Software, aber Hardware haben
wir genug. Ein CPM im Propeller mit VGA etc. gibt es schon und passt
nicht zum AVR. Ich finde die Kombination die du da gebaut hast, als
Variante sehr gut. Aber leider lassen die Softwarefreaks hier auf sich
warten...Z80 ist defenitiv überfällig.
Gruß
Hans-Werner
@Frank&Hans-Werner
Sicher sind eure Argumente nicht ganz vom Tisch zu fegen. Für jedes
Projekt gibt es Vor- und Nachteile. Der Propeller sollte auch kein CP/M
emulieren sondern nur als Tastatur und VGA Ausgabe fungieren. Das kann
er gut - das macht er gut.
Meine Motivation war die Folgende.
- nicht mehr so einfach beschaffbare DRAM’s verhindern einen breiten
Nutzerkreis
- keine weiteren freien Pins am AVR um sich die Welt nach außen zu
öffnen
- keine serielle Schnittstelle wenn ein Terminal angeschlossen ist
Nun könnte man auch einen größeren AVR nehmen ohne gleich auf SRAM
zuwechseln. Aber auch das hätte eine angepasste Softwareversion zu
Folge. Da die RAM-Ansteuerung schon ausgelagert ist, kann sie auch für
den statischen RAM angepasst werden.
Es war einfach ein Hardwarevorschlag von mir. Diesem Vorschlag braucht
keiner zu folgen. Mir hat das Arbeiten daran Freude bereitet – einzig
das zählt!
Schöne Weihnachten!
Joe
Joe G. schrieb:> Es war einfach ein Hardwarevorschlag von mir. Diesem Vorschlag braucht> keiner zu folgen.
Das ist schon klar und wir wollen auch nur gepflegt Vor- und Nachteile
diskutieren.
> Mir hat das Arbeiten daran Freude bereitet – einzig> das zählt!
Das sei Dir auch gegönnt.
Dir auch schöne Weihnachten!
frank
Frank P. schrieb:> Das ist schon klar und wir wollen auch nur gepflegt Vor- und Nachteile> diskutieren.
Wie wir sehen ist die Resonanz auch sehr gering. CP/M ist halt nicht
AdroidGalaxis500. Da mein ursprünglicher Hardwarevorschlag auf eine
vereinfachte Bauteilbeschaffung ausgerichtet war, werde ich diese
Variante vorerst zurückstellen. Der ATMEGA 644 bekommt nun wieder seine
beiden üblichen DRAM’s. Die Idee der zwei seriellen Schnittstellen, eine
für den Bootloader, werde ich beibehalten. So passiert es nicht mehr,
dass die 5V ISP noch im AVR-Board stecken und die SD-Card nicht gezogen
ist.
Joe
Joe G. schrieb:> Die Idee der zwei seriellen Schnittstellen, eine> für den Bootloader, werde ich beibehalten.
fboot von Peter Dannegger kann auf jedem Pin lauschen, ob UART oder
nicht. Genauso geht auch 1-Wire-Betrieb.
So braucht man keinen Controller mit 2 UARTs (war der mit 2en nicht erst
der 644P?) und für Layout wärs auch sehr einfach, da man nun direkt bei
zwei leeren Pins eine Serielle Schnittstelle machen kann, ohne ewig
durch die Gegend zu routen.
Nils S. schrieb:> fboot von Peter Dannegger kann auf jedem Pin lauschen, ob UART oder> nicht. Genauso geht auch 1-Wire-Betrieb.
Das wären in der aktuellen Variante PC4 zund PC5. Damit würde I2C
wegfallen. Soll nur CP/M darauf laufen - kein Problem. Aber mal einen
Schritt weiter gedacht. Über eine zweite serielle Schnittstelle könnte
man mit Kermit o.ä. auf das CP/M zugreifen. Am 8-Bit Port kann ein LCD
oder, oder angeschlossen werden.
@Joe: Ich sehe es (leider) auch so wie einige Vorredner.. Hardware haben
wir z.Z genug.. ich habe immer noch 5? Platinen des USB Sticks hier..
Rams auch..
Auch gefällt mir! die Kombination aus AVR+Propeller nicht.. der Prop.
kann dann schon alles alleine machen und Z80, CP/M gibts dafür auch
schon.. (sogar in Streichholzschachtelgröße)
Was das Projekt wirklich voran bringen könnte wäre Z80 Emulation und
dann die darauf aufbauenden Diskimages mit Turbo Pascal etc. etc.
Die 8080 Emu scheint aber auch noch mind. einen Bug zu haben.. siehe
Fehler im Multiplan..
Was auch schön wäre, eine altairz80 Emu, der direkt die Diskimages für
dieses Projekt verarbeiten kann..
Und weitere Diskimages die jetzt schon unter 8080 laufen..
Was ist ansonsten ggf. noch 'niedlich' finden würde wäre ein Stick in
SMD Bauweise mit Micro-SD Karte.. und Drams's die sich leicht beschaffen
lassen in SMD.. ist aber nur so ein 'Hirngespinnst'..
Z80 Emu. in ASM gibt ja nun Dank Jörg Wolfram im AX81 Projekt.. Basis
wäre also ja vorhanden..
Vielleicht sollten wir eine Bounty Prämie ausloben für eine
funktionierende Z80 Emu für dieses Projekt..?
Euch allen die besten Wünsche für 2012!
Peter
Peter Sieg schrieb:> Z80 Emu. in ASM gibt ja nun Dank Jörg Wolfram im AX81 Projekt.. Basis> wäre also ja vorhanden..
In der Quelle 8080int-jmp.asm ist ja auch schon alles vorbereitet. Es
müssen (nur) noch die Z80 spezifischen Codes nachgetragen werden. Ich
habe mal in der To_Tabelle die Befehle mit (Z80) markiert. Dabei viel
mir auch auf, dass der OpCode D9 falsch interpretiert wurde. Laut 8080
sollte das RET sein, ausgeführt wurde NOP und im Z80 ist es EXX. Ich
habe es korrigiert (siehe Anhang).
Joe
Peter Sieg schrieb:> Hast du mal probiert, ob der ominöse Multiplanfehler nun weg ist..?
Nein noch nicht.
@alle
Schraubt schon jemand an der Z80 Umsetzung? Wenn ja, bitte kurz melden
damit wir nicht doppelt schrauben ;-)
Joe
Der Fehler im Multiplan ist immer noch..
Einfach mal in Zelle r2c2 23 und in r3c2 4 und in r4c2 r2c2+r3c2
eintragen.
Ergibt ersteinmal richtig 27. Dann r3c2 von 4 auf 9 ändern .. :-(
Peter
Peter Sieg schrieb:> Der Fehler im Multiplan ist immer noch..
Bist dur dir sicher, dass Multiplan unter dem 8080 läuft? Möglicherweise
ist die unterschiedliche Parity-Flag Behandlung die Ursache. Setze doch
mal EM_Z80 auf 1, dann werden die Z80 Flags ausgeführt. Ich habe erst
mal alle Z80 JR nn Befehle eingebaut. Im nächsten Jahr mehr...
Allen einen schönen Jahreswechsel mit viel Elan für neue und alte
Projekte!
Gruß Joe
Joe G. schrieb:> In der Quelle 8080int-jmp.asm ist ja auch schon alles vorbereitet. Es> müssen (nur) noch die Z80 spezifischen Codes nachgetragen werden.
Dieses "nur" kann aber recht aufwendig werden, insbesondere bei den
Indexregister-Befehlen (DD/FD-Prefixe). Ich wünsche Dir und uns viel
Erfolg. Kennst Du diese Seite hier?
http://z80.info/decoding.htm
Da könnten ein paar nützliche Hinweise drin sein.
> habe mal in der To_Tabelle die Befehle mit (Z80) markiert. Dabei viel> mir auch auf, dass der OpCode D9 falsch interpretiert wurde. Laut 8080> sollte das RET sein, ausgeführt wurde NOP und im Z80 ist es EXX. Ich> habe es korrigiert (siehe Anhang).
Dir Korrektur ist richtig (Danke), aber die Beschreibung nicht ganz. D9
ist bei 8080 ein undefinierter Opcode (RET ist C9). Meines Wissens hat
der 8080 im Gegensatz zu den meisten anderen Prozessoren auch keine
nennenswerten undokomentierten Befehle an solchen Stellen. Der Fehler
dürfte sich daher in keinem Programm bemerkbar machen.
Joe G. schrieb:> Bist dur dir sicher, dass Multiplan unter dem 8080 läuft?
Ganz sicher. Damit habe ich Mitte der 80er die Telefonabrechnung für
unser Stockwerk im Studentenwohnheim gemacht (10 Apartments und ein
Telefon mit Einheitenzähler auf dem Flur).
Nächstes Jahr werde ich mir den Fehler mal anschauen.
> Möglicherweise> ist die unterschiedliche Parity-Flag Behandlung die Ursache. Setze doch> mal EM_Z80 auf 1, dann werden die Z80 Flags ausgeführt.
Ich kann mir nicht vorstellen, daß es ein Programm gibt, daß mit dem
8080-Befehlssatz auskommt, die Flags aber wie beim Z80 interpretiert.
Peter Sieg schrieb:> Was das Projekt wirklich voran bringen könnte wäre Z80 Emulation und> dann die darauf aufbauenden Diskimages mit Turbo Pascal etc. etc.
Turbo Pascal wäre sicher nett, aber wichtiger finde ich, das das
bestehende Minimalsystem zu verbessern, so das es richtig rund läuft.
Dazu stehen auf meiner ToDo-Liste noch:
- Notwendige und nützliche Tools auf PC als Paket zusammenstellen
("Entwicklungsumgebung") und insbesondere dokumentieren. Möglichst
einheitlich für Linux und Windows.
- SD-Kartentreiber verbessern.
- Break erkennen.
Mit dem ersten Punkt hatte ich vor einigen Monaten schon mal
angefangen...
> Was auch schön wäre, eine altairz80 Emu, der direkt die Diskimages für> dieses Projekt verarbeiten kann..
Zu altairz80 habe ich da
Beitrag "Re: CP/M auf ATmega88"
schon was geschrieben.
Leo C. schrieb:> Kennst Du diese Seite hier?
Die und die anderen Links auf der Seite sind eine Goldgrube!
Leo C. schrieb:> bei 8080 ein undefinierter Opcode
Stimmt, ich hatte diese Quelle genutzt und das "Sternchen" vor RET
übersehen.
http://www.pastraiser.com/cpu/i8080/i8080_opcodes.htmlLeo C. schrieb:> Dieses "nur" kann aber recht aufwendig werden, insbesondere bei den> Indexregister-Befehlen
Vielleicht hilft ja noch einer ;-)
Hallo Retro-Freak Kollegen, :-)
wünsche allen hier gut ins neue Jahr 2012 gekommen zu sein!
Dies ist mein erster Beitrag in diesem Thread (habe bisher nur
mitgelesen).
Von Peter habe ich vor ein paar Tagen zwei Platinen erstanden, sind
gestern auch angekommen, Danke Peter!
Nun muss ich noch die nötigen Bauteile besorgen und das Ganze
aufbauen...
...und dann gehts erst richtig los! :-)
Ich würde Euch gerne bei diesem spannenden Projekt unterstützen!
Was ich beitragen kann:
Aus dem Bereich Software(-Entwicklung):
- Etwas angestaubte Kenntnisse in 8080/8085 Assembler von früher...
- Kenntnisse auch in anderen Assembler Dialekten (6502/68000er) wer weiß
wofür es mal gut ist... :-)
- Kenntnisse in C / C++
- Allgemeine Kenntnisse im Bereich Softwareentwicklung (z.B. diverse
IDE's, etc.)
Aus dem Bereich Hardware:
- Allgemeine Elektronik-Kenntnisse (bin ausgebildeter
Kommunikationselektroniker)
- Kenntnisse im Bereich Mikroprozessor-/Mikrocontroller-Technik
- Messtechnik im eigenen Elektronik-Labor: 2 x Oszilloskop (analog u.
digital), 34 Kanal-Logikanalyser, STK500 Entwicklungsboard, etc.
Ich möchte zu meinem Einstieg auch gleich einen Vorschlag machen:
Mir ist beim Lesen aller (ja es sind über 1000!) Beiträge aufgefallen,
dass es viele wertvolle Hinweise / Links in diesem Threat gibt, welche
aber nur teilweise in der Projektseite:
http://www.mikrocontroller.net/articles/AVR_CP/M aufgeführt sind!
Zum Beispiel aktuell dieser: http://z80.info/decoding.htm
Ich würde als erstes die Links alle heraussuchen und auf der
Projektseite im Breich "Siehe auch" einfügen.
Des weiteren würde ich vorschlagen, auf der Projektseite auch einen
Punkt "ToDo" einzuführen um dort anstehende Themen wie z.B.: Erweiterung
um Z80 Emulation aufzuführen evtl. mit Hinweis wer an welchem Punkt
bereits arbeitet!
Was haltet Ihr davon?
Viele Grüße
Markus
@Markus
Willkommen bei den Retroinfizierten!
Wie du schon mitbekommen hast, lebt so ein Projekt vom Enthusiasmus der
Beteiligten. Somit ist jede Mitarbeit willkommen. Sei es bei der
Dokumentation der Hardware oder der Software. Dein Vorschlag, die
Projektseite zu aktualisieren ist gut. Eine Linksammlung fehlte
tatsächlich noch darauf. Auch eine ToDo-Sammlung ist eine gutes
demokratisches Mittel „wirkliche“ Bedürfnisse zu erfassen sowie den
aktuellen Stand zu dokumentieren.
Darf ich dir gleich einen konkreten Vorschlag unterbreiten? Da eine
Aufbaudokumentation noch fehlt, ist es aus meiner Sicht ganz nützlich so
was in Angriff zu nehmen. Wenn du bei deinem Aufbau die Aufbauschritte
und auch die dabei auftretenden Hürden dokumentierst hätten wir gleich
einen Anfang. Also einfach kurz alles notieren was bei der Hard- und
Software schief gehen kann.
Gruß Joe
Hallo Joe,
hallo Peter,
Danke für die herzliche Begrüßung!
Die Schlacht hat bereits gegonnen :-), seht hier:
http://www.mikrocontroller.net/articles/AVR_CP/M#Siehe_auch
Als nächstes werde ich dort noch jede Menge weitere Links einfügen,
welche ich aus diesem Threat extrahiert habe!
Dann folgt der Todo Abschnitt, da dürft Ihr Euch dann verausgaben... ;-)
Und wenn ich, voraussichtlich nächste Woche, alle Bauteile zusammen
habe, baue ich einen CP/M Stick auf und notiere mir dabei was mir dabei
auffällt (wie von Joe vorgeschlagen)!
Viele Grüße
Markus
Hallo zusammen,
so, ich habe meine Drohung, die Linksammlung zu vervollständigen und
eine ToDo-Liste einzufügen, nun war gemacht! :-)
Das Ergebnis seht Ihr hier:
http://www.mikrocontroller.net/articles/AVR_CP/M#ToDo_Liste
Sollte etwas fehlen, nicht gefallen, etc. bitte einfach (selbst)
editieren!
Viele Grüße
Markus
Markus G. schrieb:> Die Schlacht hat bereits gegonnen :-), seht hier:
Dank Markus und dem Verweis auf das Total Commander Plugin für CP/M habe
ich das AVR CP/M Format in die diskdefs des TC eingetragen. Nun kann man
mit dem TC unter Windows wunderbar unsere Images bearbeiten!
Peter Sieg schrieb:> Braucht der nicht trotzdem die cpmtools im Hintergrund..?> Schön wäre 1 Installer/ZIP zum entpacken, wo alles gleich fertig drin> ist..
Man benötigt nur das cpmwfx Plugin für TC und die diskdefs (siehe oben).
Dann wird das Immage gemappt und kann bearbeitet werden. Das geht sogar
schneller und einfacher als bei ZIP. Ein Installer wird somit
überflüssig da sich das Immage wie ein Unterverzeichnis in Win verhält.
Probier es mal, du wirst begeistert sein.
Arg?!"§§$$%
1. Also TC (Shareware) installiert.
2. cpm wfx plugin von hier geladen als zip:
http://hc-ddr.hucki.net/wiki/doku.php/cpm:disketten_xp2
3. TC gestartet und Zip aus 2 geöffnet. Findet plugin und frag ob es
inst. werden soll. Ja.
4. diskdefs in TC install Pfad\plugins\wfx\cpmimg kopiert und vorhandene
überschrieben.
5. TC neu gestartet. Doppelklick auf CPMDSK_A.IMG --.. kann nicht
geöffnet werden..
Super tolle Anleitung und super tolles selbsterklärendes Tool!
Außerdem sind im cpmimg Verzeichnis doch wieder cpmls, cpmcp, cpmrm.exe
etc. drin..
Peter
EDIT:
6. Anleitung unter 2 weiter lesen... !!
7. CPM Image datei mit F5 Kopieren an cpmwfx 'senden'..
8. Datei im rechten Fenster dann markieren mit der Maus und im Menu
unter Dateien-Eigenschaften unten im Format-Eingabefenster 'avrcpm'
eingeben..
Hurra!
ok, wer es braucht.. Ich denke man könnte avrcpm noch als Default Format
einstellen..? Spart zumindest Schritt 8.
Ich bleibe dann doch lieber bei den CMD Tools.. denn für ein erzeugen
eines CP/M Diskimage braucht man das trotzdem..
Peter
Hallo zusammen,
ich habe eine Anmerkung zum Thema SD-Kartenleser (SCDA...) -
Platinenlayout des CP/M-Stick:
GPS'ler schrieb:> Hallo @Joe,>> vorneweg, ich habe noch nie eine Leiterplatte mit Eagle entworfen und> dadurch keinerlei Erfahrung in dieser Richtung!>> ....aber kann es sein, dass die SD-Karte Spiegelverkehrt ist und würde> nur passen, wenn das auf der Unterseite wäre. Ich habe mehrere> SD-Kartenhalter und wollte testen ob diese in etwa passen. Aber leider> nein. Dabei ist mir aufgefallen,dass die SCDA... falsch angeschlossen> sein müßte.Im Manual von denen steht "Viewed from the mounting face> side". Ich habe dein Layout ausgedruckt und ne SD Karte draufgelegt. CS> ist der erste bzw. 2. Pin nach der Abschrägung....>> Eventuell liege ich voll daneben.....deshalb prüfen....>> MfG> Achim>> Ps: Eventuell kannst du die Pads nach recht verlängern (Falls das bei> euererKarte nicht stört) , dann würde es auch für meine passen...> Anbei die LIB
Ich habe heute das oben von GPS'ler (Achim) angesprochene Problem mit
dem vermeintlich spiegelverkehrten Layout des SD-Kartenhalters selbst
nachvollzogen:
Ich habe mir für den Aufbau des CP/M-Sticks über ebay folgende
SD-Kartenhalter gekauft:
http://www.ebay.de/itm/15x-ALPS-SCDA-SD-MEMORY-CARD-READER-BUCHSE-/290644435363?pt=Kartenleseger%C3%A4te&hash=item43abc221a3
Dabei habe ich folgendes festgestellt:
1. Der Pinabstand passt nicht genau zum Layout.
2. Dieser Kartenhalter ist NICHT für "Reverse mount" sondern für
"Standard mount" gedacht (s. Anhang scda.pdf).
3. Er ist also für unser Projekt NICHT geeignet!!!
4. Für einen korrekten Aufbau ist zwingend der SD-Kartenhalter vom Typ:
ALPS (Hersteller) SCDA5A0201 erforderlich!
Ob es baugleiche SD-Kartenhalter von anderen Herstellern gibt ist mir
nicht bekannt!
Und nun die Master-Frage: Hat jemand von Euch noch einen, besser wären
zwei, SD-Kartenhalter des richtigen Typs zum Verkauf für mich?
Gruß
Markus
Markus G. schrieb:> Für einen korrekten Aufbau ist zwingend der SD-Kartenhalter vom Typ:> ALPS (Hersteller) SCDA5A0201 erforderlich!
Ich habe sie immer hier bezogen:
http://www.csd-electronics.de/
Best.Nr.: 020115
Stückpreis: 2,95€
Peter Sieg schrieb:> Ich denke man könnte avrcpm noch als Default Format> einstellen..? Spart zumindest Schritt 8.
getan (siehe Anhang)
Peter Sieg schrieb:> Ich bleibe dann doch lieber bei den CMD Tools.. denn für ein erzeugen> eines CP/M Diskimage braucht man das trotzdem..
Du brauchst doch nur einmal ein leeres Image erstellen. Dann kopierst du
mit TC alle Dinge die du benötigst in das Imageverzeichnis. Das
komplette Image wird automatisch angepasst.
@Markus: Bezugsquelle SD Slot wurde ja schon genannt. Der SCDA6A..
sollte auch passen (ALPS). Ansonsten ging es 2009 darum einen günstigen
SD Slot mit GUTER Qualität UND Eagle LBR zu finden.. das war das
Ergebnis..
Peter
Da ich mich mit CP/M bis her nur sehr oberflächlich befasst habe,
kann man eigentlich auch mit 64 Zeichen/Zeiile "sinnvolle" Dinge damit
anstellen oder müssen es unbedingt 80 Zeichen sein?
Gruß Jörg
Hallo zusammen,
so nun ist es soweit:
Auch ich besitze nun einen funktionierenden AVR CP/M-Stick! Juhu
Da ich zwischenzeitlich auch einige Tests mit diversen DRAM-Bausteinen
und ein paar SD-Karten durchgeführt habe, habe ich dies nun auch auf der
Projektseite im Abschnitt Hardware im Anschluss an die Hardwarevariante
3 dokumentiert:
http://www.mikrocontroller.net/wikisoftware/index.php?title=AVR_CP/M§ion=2#Hardware
An dieser Stelle auch gleich die Bitte, diesen Abschnitt, um die von
Euch erfolgreich eingesetzten DRAM's und SD-Karten, zu erweitern!
Viele Grüße
Markus
Joe G. schrieb:> Markus G. schrieb:>> Auch ich besitze nun einen funktionierenden AVR CP/M-Stick!>> Herzlichen Glückwunsch!
Hallo Joe,
Danke für den Glückwunsch! :-)
Bis zur endgültigen Funktion hatte ich aber auch ein paar spannende
Begegnungen der Dritten Art, welche ich hier kurz aufzeigen möchte damit
andere Retro-Fans nicht in die gleichen Fallen tappen:
1. Ich hatte mich anfangs von der 4bit DRAM Architektur (256k x 4Bit)
irritieren lassen und in der Datei: config.inc
1
#define DRAM_8BIT 0
eingetragen, was zu Zeichensalat auf dem Terminal führte!
Korrekt ist:
1
#define DRAM_8BIT 1 /* 1 = 8bit wide DRAM */
2. Ich habe es geschafft mir genau zwei defekte DRAM's aus meinem Fundus
auszusuchen und den AVR CP/M-Stick damit zu bestücken! (Murphys Gesetz
Teil 1) :-(
Das wäre an sich noch gar kein so großes Problem gewesen, wenn nicht
auch noch die vorhandene Speichertest-Routine aktiviert durch:
1
.equ MEMTEST = 1
in der Datei: config.inc im Fehlerfall einfach weiterlaufen würde!!!
(Murphys Gesetz Teil 2) :-(
Dies kann dann z.B. so aussehen:
CPM on an AVR, v2.1
Testing RAM: fill...wait...reread...
FE<FF@FFFE
Initing mmc...
A:FAT16 File-Image at: 026, size: 256KB.
B:FAT16 File-Image at: 010, size: 256KB.
C:FAT16 File-Image at: 018, size: 256KB.
Partinit done.
Ok, CPU is live!
ipl
62k cp/m vers 2.2
PC=202B
Z P A =80 BC =0034 DE =0080 HL =F580 SP =2000 PC =202B C3 00
F2
Wie weit die Einschaltmeldungen noch ausgegeben werden, ist unter
anderem auch davon abhängig ob und welche Debug Ausgaben aktiviert sind!
Ergo: Defekte DRAM's führen zu blöden, bösen und ggf. schwer zu
findenden Fehlern!!!
Aber nun zum angenehmen Teil, der Lösung:
Nachdem ich mich dann irgendwann dazu entschieden hatte ein neues Paar
DRAM's einzusetzen sah es gleich viel besser aus!
Und um das Ganze nicht vielleicht noch einmal erleben zu müssen habe ich
mich anschließend entschlossen die Speichertest-Routine etwas zu
modifizieren.
Die von mir überarbeitete Testroutine hält beim ersten Speicher-Fehler
das System an und fordert zum Tausch des/der DRAM-Chips auf!
Diese Routine kann über die Anweisung:
1
.equ MEMTEST = 2
(oder höher) in der Datei: config.inc aktiviert werden!
Das Ganze sieht dann im Fehlerfall z.B. so aus:
CPM on an AVR, v2.1
Testing RAM: fill...wait...reread...
RAM test failure:
00<01@0100
System halted, replace RAM chip(s)!
Die geänderte Assembler Quellcode-Datei habe ich diesem Beitrag
angehangen.
Um die geänderte Speichertest-Routine zu verwenden sind also nur zwei
kleine Schritte nötig:
1. Austausch der vorhandenen Datei init.asm im Projektverzeichnis durch
die im Anhang befindliche Datei init.asm.
2. Aktivieren der neuen Routine durch die Anweisung:
1
.equ MEMTEST = 2
(oder höher) in der Datei: config.inc
Auch die alte Speichertest-Routine kann weiterhin verwendet werden,
hierzu ist wie bisher die Anweisung:
1
.equ MEMTEST = 1
in der Datei: config.inc zu setzen!
Viele Grüße
Markus
Markus G. schrieb:> Die geänderte Assembler Quellcode-Datei habe ich diesem Beitrag> angehangen.
Danke.
Verbesserungen und Korrekturen (insbesondere) mit Patch sind sehr sehr
gern gesehen.
Wenn niemand was dagegen hat, werde ich die Änderung übernehmen.
Peter Sieg schrieb:> Wer sollte was dagegen haben.. ;-)>> Gruß Peter
Ich bestimmt nicht!
Und dann war der Fehler und das Debugging wenigstens lohnenswert... :-)
Viele Grüße
Markus
Markus G. schrieb:> Die geänderte Assembler Quellcode-Datei habe ich diesem Beitrag> angehangen.
Super,läuft!
Wenn du Lust hast auch am Z80 Code zu arbeiten....
Die "JR Dinge" habe ich schon eingepflegt, sind aber noch nicht
vollständig getestet. CB, ED und FD sind noch offen (viel Fleißarbeit).
Gruß Joe
Joe G. schrieb:> Markus G. schrieb:>> Die geänderte Assembler Quellcode-Datei habe ich diesem Beitrag>> angehangen.>> Super,läuft!>> Wenn du Lust hast auch am Z80 Code zu arbeiten....>> Die "JR Dinge" habe ich schon eingepflegt, sind aber noch nicht> vollständig getestet. CB, ED und FD sind noch offen (viel Fleißarbeit).>> Gruß Joe
Hallo Joe,
Danke, freut mich! :-)
Ja, ich habe Lust auch bei der Z80 Emulation zu unterstützen.
Ich habe mir schon mal das z80int.asm Modul angesehen, kann es aber noch
nicht komplett überblicken.
Mir sind dabei vermeintlich ein paar Z80 spezifische Dinge aufgefallen
welche ich hier kurz aufzeigen möchte:
1. Wir müssen folgende Opcodes noch implementieren / testen:
Dahinter verbergen sich 456(!) einzelne Opcodes, soviel zum Thema
Fleißarbeit... :-)
2. Unter den Z80 spezifischen Opcodes gibt es auch einige welche 4 Bytes
lang sind.
Diese befinden sich alle in den Bereichen der DD, ED und FD Opcodes!
Wie wirkt sich dies auf die Opcode-Decoder-Routinen aus? Grübl
Ich habe die von mir angefertigte Tabelle (im xls und ods Format) diesem
Beitrag angehangen.
Diese Webseite diente mir als Quelle:
http://nemesis.lonestar.org/computers/tandy/software/apps/m4/qd/opcodes.txt
Viele Grüße
Markus
Markus G. schrieb:> Ja, ich habe Lust auch bei der Z80 Emulation zu unterstützen.
Der aktuelle Interpreter ist 8080int-jmp.asm
Für die 4 Byte Opcodes habe ich auch noch keinen Plan. Vielleicht fällt
Leo C. was dazu ein ;-).
Gut ist auch immer ein Blick auf das Projekt von Jörg Wolfram
http://www.jcwolfram.de/projekte/avr/ax81/main.php
Dort hat er schon einen Z80 Interpreter für AVR implementiert. Er kann
nicht 1:1 übernommen werden aber der Blick auf einzelne Befehle ist
äußerst hilfreich (Danke Jörg!).
Wenn du mir deine PM senden köntest, dann würde ich dir meinen
Arbeitsstand von 8080int-jmp.asm zukommen lassen.
Gruß Joe
Joe G. schrieb:> Markus G. schrieb:>> Ja, ich habe Lust auch bei der Z80 Emulation zu unterstützen.>> Der aktuelle Interpreter ist 8080int-jmp.asm> Für die 4 Byte Opcodes habe ich auch noch keinen Plan. Vielleicht fällt> Leo C. was dazu ein ;-).>> Gut ist auch immer ein Blick auf das Projekt von Jörg Wolfram> http://www.jcwolfram.de/projekte/avr/ax81/main.php> Dort hat er schon einen Z80 Interpreter für AVR implementiert. Er kann> nicht 1:1 übernommen werden aber der Blick auf einzelne Befehle ist> äußerst hilfreich (Danke Jörg!).>> Wenn du mir deine PM senden köntest, dann würde ich dir meinen> Arbeitsstand von 8080int-jmp.asm zukommen lassen.>> Gruß Joe
Hallo Joe,
okay, dann übernehme ich gerne Deinen Arbeitsstand.
Du hast soeben eine PM von mir bekommen mit meiner privaten
Emailadresse! :-)
Das Projekt von Jörg ist mir auch bekannt, war auch gerade wieder auf
der Seite und habe mir die Sourcen der V0.26 gezogen und kurz einen
Blick in den Z80-Emu geworfen!
Was mir dort auf den ersten Blick gut gefallen hat ist die Unterteilung
der "Opcode Familien" in einzelne Module (Include Dateien).
Ich finde dies macht das Ganze zumindest etwas übersichtlicher...
Viele Grüße
Markus
Hallo zusammen,
ich habe meine, im Beitrag #2541628 veröffentlichte,
Speichertest-Routine nun noch einmal verfeinert:
Durch den Eintrag:
1
.equ MEMTEST = 3
(oder höher) in der Datei: config.inc
ist es nun möglich im Falle eines Speicherfehlers auf einem AVR
CP/M-Stick V3.0 den/die defekten DRAM-Chips (IC5 / IC6) anzeigen zu
lassen!
Die geänderte Assembler Quellcode-Datei habe ich diesem Beitrag
angehangen.
Um die geänderte Speichertest-Routine zu verwenden sind also nur zwei
kleine Schritte nötig:
1. Austausch der vorhandenen Datei init.asm im Projektverzeichnis durch
die im Anhang befindliche Datei init.asm.
2. Aktivieren der neuen Routine durch die Anweisung:
.equ MEMTEST = 3
(oder höher) in der Datei: config.inc
Auch die alten Speichertest-Routinen können weiterhin verwendet werden,
hierzu ist wie bisher die Anweisung:
.equ MEMTEST = 1 oder 2
in der Datei: config.inc zu setzen!
Siehe auch folgenden Auszug aus der Datei init.asm:
Peter Sieg schrieb:> Gerade festgestellt das:> SIEMENS HYB514256B-70> wovon ich noch 9 Stk. habe NICHT laufen!>> Kennt jemand noch eine Quelle von 4256 Drams?>> Peter
Hallo Peter,
ich kenne leider auch keine verlässliche Quelle für weitere passende
DRAM's außer ab und zu ebay. :-(
Nachtrag: Gerade gefunden, könnte evtl. noch eine Quelle sein:
http://www.arcadecomponents.com/memory.html
Versand ist auch nach Deutschland möglich!
Aber was mich in diesem Zusammenhang noch interessieren würde:
Mit welcher uC Taktfrequenz hast Du die SIEMENS HYB514256B-70 DRAM's
getestet?
Ich hatte ursprünglich drei IC's davon (über ebay gekauft - also ohne
Gewähr auf Funktion).
Bei meinen Tests mit 20 MHz uC Takt, stellten sich dann 2 von 3 IC's als
reproduzierbar defekt heraus...
Einer davon läuft aber einwandfrei bei 20 MHz Takt, höhere Frequenzen
habe ich mangels Quarze bisher nicht getestet!
Gruß
Markus
Peter Sieg schrieb:> Hmm Ja.. sind mit 30MHz getaktet.. ;-)> Das ist dann natürlich grenzwertig und das auch noch bei nur 3,3V..>> Gruß Peter
Hallo Peter,
ja 30 MHz ist schon verdammt viel.
Ich habe soeben auch noch einmal Tests mit meinen zwei vermeintlich
defekten SIEMENS HYB514256B-70 IC's durchgeführt:
Einmal mit 2 bzw. 3 Waitstates, wie von Leo vorgeschlagen, bei 20 MHz uC
Takt und dann noch mit 1 bzw. 2 Waitstates bei 8 MHz uC internen Takt.
Aber es hilft alles nichts, diese beiden IC's sind definitiv defekt!
Vielleicht solltest Du Deinen DRAM's auch mal nur 8 MHz uC internen Takt
gönnen, dann sollte aber wirklich nichts fehlen, ausser sie sind
wirklich defekt!
Viele Grüße
Markus
@alle: Wie ist denn der Stand bei der Implementierung der Z80
Unterstützung?
@Leo C.: Konntest du schon mal in das wirre Verhalten von Multiplan
schnuppern. Irgendwo muss da doch noch in der 8080 Implementierung ein
Wurm drin sein..?
Ach Ja.. Platinen sind nun alle.. wenn noch wer hier Bedarf hat.. müßte
ich dann nachbestellen und das müssen immer mind. 10 Stück sein..
Peter
Peter Sieg schrieb:> @Leo C.: Konntest du schon mal in das wirre Verhalten von Multiplan> schnuppern. Irgendwo muss da doch noch in der 8080 Implementierung ein> Wurm drin sein..?
Jetzt habe ich es mal mit der Version 1.06 von hier
http://www.schorn.ch/cpm/intro.php
ausprobiert. Da taucht der Fehler auch auf. Da der Fehler im simh mit
8080-Emulation nicht vorkommt, muß es wohl an unserer CPU-Emulation
liegen.
Ich tippe auf den DAA-Befehl, da Multiplan wahrscheinlich mit BCD-Zahlen
rechnet. Vielleicht hat ja zufällig jemand CBASIC von Digital Research
parat, das auch in obiger Quelle zu finden ist, und das auch mit BCD
rechnet, und kann meine Vermutung bestätigen.
@Leo C.: Habe leider nur MS Basic hier..
Evtl. zeigt ja schon ein Vergleich zw. was 8080-DAA machen soll und das
was in unserer Implementierung passiert etwas auffälliges..
BTW: Das erinnert mich an einen Zeitungsartikel in dem es hieß:
... der letzte Fehler in CP/M wurde auch erst nach 7 Jahren gefunden..
;-)
Haha.. derjenige war ganz sicher Gott oder er hat keine Ahnung von
Software..
Peter
Peter Sieg schrieb:> @alle: Wie ist denn der Stand bei der Implementierung der Z80> Unterstützung?> @Leo C.: Konntest du schon mal in das wirre Verhalten von Multiplan> schnuppern. Irgendwo muss da doch noch in der 8080 Implementierung ein> Wurm drin sein..?>> Ach Ja.. Platinen sind nun alle.. wenn noch wer hier Bedarf hat.. müßte> ich dann nachbestellen und das müssen immer mind. 10 Stück sein..>> Peter
Hallo zusammen,
ich habe zwischenzeitlich von Joe seinen aktuellen Arbeitsstand der
Datei: 8080int-jmp.asm für den Z80 Emulator bekommen, Danke Joe!
Bin aber leider noch nicht wirklich dazu gekommen mich dort etwas
einzuarbeiten. :-(
Viele Grüße
Markus
Leo C. schrieb:> Peter Sieg schrieb:>> @Leo C.: Konntest du schon mal in das wirre Verhalten von Multiplan>> schnuppern. Irgendwo muss da doch noch in der 8080 Implementierung ein>> Wurm drin sein..?>> Jetzt habe ich es mal mit der Version 1.06 von hier> http://www.schorn.ch/cpm/intro.php> ausprobiert. Da taucht der Fehler auch auf. Da der Fehler im simh mit> 8080-Emulation nicht vorkommt, muß es wohl an unserer CPU-Emulation> liegen.>> Ich tippe auf den DAA-Befehl, da Multiplan wahrscheinlich mit BCD-Zahlen> rechnet. Vielleicht hat ja zufällig jemand CBASIC von Digital Research> parat, das auch in obiger Quelle zu finden ist, und das auch mit BCD> rechnet, und kann meine Vermutung bestätigen.
Hallo zusammen,
ich nehme mich des "Multiplan Fehlers" an!
@Leo C.: Danke für die Quelle zum CBASIC und den Hinweis auf den DAA
Befehl, mal sehen was ich herausbekomme.
Diese Bausstelle bringt dann auch gleich mein Verständnis über den
Prozessablauf des 8080 Befehlsinterpreters voran.
Dies hilft mir anschließend für die Arbeit am Z80 Interpreter...
Alles ein Frage der richtigen Kombination(en)... ;-)
Viele Grüße
Markus
Markus G. schrieb:> ich nehme mich des "Multiplan Fehlers" an!
Bin inzwischen einen Schritt weiter:
Bei den Arithmetikbefehlen wird das H-Flag (half carry) nicht gesetzt.
Ich habe auch mal einen Patch angefangen (Anhang), aber z.Zt. habe ich
nicht mal einen Assembler auf meinem Rechner installiert.
Bis ich testen kann, dauert also etwas.
@Leo C / Markus: Prima!
Ich kann etwas mehr zu Rams sagen:
SIEMENS HYB514256B-70 gehen bei mir definitiv nicht bei 3,3V, 20MHz und
3 Waitstates. Mehr als 8 Stück getestet - alle liegen nicht.
Aber:
V53C104P laufen nun bei 3,3V, 20MHz und 3 Waitstates!
Diese liefen damals unter 30/25MHz, 3,3V und 1 Waitstates NICHT.
Peter
Meine Entwicklungsumgebung geht wieder.
Der DAA-Code ist total buggy. 2 Fehler habe ich gefunden und dem
nächsten bin ich auf der Spur. (Wer hat nur so einen Mist programmiert?
;)
Peter Sieg schrieb:> @Leo C / Markus: Prima!>> Ich kann etwas mehr zu Rams sagen:> SIEMENS HYB514256B-70 gehen bei mir definitiv nicht bei 3,3V, 20MHz und> 3 Waitstates. Mehr als 8 Stück getestet - alle liegen nicht.>> Aber:> V53C104P laufen nun bei 3,3V, 20MHz und 3 Waitstates!> Diese liefen damals unter 30/25MHz, 3,3V und 1 Waitstates NICHT.>> Peter
Hallo Peter,
Deine RAM's verwirren mich... :-)
Drei Fragen dazu:
1. Was machen denn die SIEMENS HYB514256B-70 bei 8 MHz internem uC Takt?
2. Bleibt jeder RAM-Chip für sich gesehen bei jedem RAM-Test an der
selben Adresse stehen?
Zum Beispiel:
1. Chip immer an der Adresse 0100 (HEX):
2. Chip immer an der Adresse 0080 (HEX):
3. Chip immer an der Adresse 02CE (HEX):
etc...
Siehe auch meinen Beitrag #2545923.
3. Welche Zugriffszeit haben Deine V53C104P RAM's?
Viele Grüße
Markus
Leo C. schrieb:> Markus G. schrieb:>> ich nehme mich des "Multiplan Fehlers" an!>> Bin inzwischen einen Schritt weiter:> Bei den Arithmetikbefehlen wird das H-Flag (half carry) nicht gesetzt.>> Ich habe auch mal einen Patch angefangen (Anhang), aber z.Zt. habe ich> nicht mal einen Assembler auf meinem Rechner installiert.> Bis ich testen kann, dauert also etwas.
Hallo Leo,
ich sehe Du bist voll in Deinem Element... ;-)
Ich habe mir Deine neue 8080int-jmp.asm geladen, assembliert und damit
Multiplan 1.06 geteset:
Ich kann Dir sagen, noch ist der Bug da! :-)
Er tritt z.B. bei Additionen mit einem Ergebnis größer gleich 30 auf, 29
+ 1 = 130 und 29 + 2 = 131 :-)
Es gibt auch nette Subtraktionen: 1 - 8 = -1, 100 - 1 = 109 und 100 - 8
= 102 :-)
Falls es wieder eine neue Version zum Testen gibt, nur her damit... :-)
Viele Grüße
Markus
Markus G. schrieb:> Ich kann Dir sagen, noch ist der Bug da! :-)
Ja, der DAA-Code ist (bzw. war) ein einziger großer Bug. :)
Hast Du auch das hier gelesen?
Beitrag "Re: CP/M auf ATmega88"> Falls es wieder eine neue Version zum Testen gibt, nur her damit... :-)
Ich mache DAA gerade komplett neu. Im Moment gibts besonders lustige
Ergebnisse (Anhang). Aber vielleicht wirds heute noch fertig.
So, für Multiplan reichts jetzt.
Ob die Emulation allerdings ganz korrekt ist, weiß ich nicht.
Außerdem fehlt noch der Fall, wenn das N-Flag gesetzt ist. Das sollte
aber für alle korrekten 8080-Programme ausreichen.
Im Anhang ist noch ein Multiplan Testprogramm.
Leider habe ich keine Quellen gefunden, die den DAA Befehl vollständig
beschreiben. Für 8080 findet man noch weniger, als für den Z80.
Auf der Suche habe ich aber noch folgende interessante Dokumente
gefunden:
http://anyplatform.net/cpus.html
(weiter unten 8080/Z80 Series)
Weitere habe ich schon wieder verloren...
Hallo Draco,
danke für den Hinweis. Zaks ist schon eine der besten Referenzen für Z80
überhaupt, aber leider fehlt auch bei ihm der Zustand des Half-Carry
nach dem DAA-Befehl. Inzwischen habe ich aber noch ein gutes Dokument
(wieder-) gefunden:
"The Undocumented Z80 Documented"
http://www.myquest.nl/z80undocumented/
(auch auf http://www.z80.info) zu finden)
Leo C. schrieb:> So, für Multiplan reichts jetzt.> Ob die Emulation allerdings ganz korrekt ist, weiß ich nicht.> Außerdem fehlt noch der Fall, wenn das N-Flag gesetzt ist. Das sollte> aber für alle korrekten 8080-Programme ausreichen.>> Im Anhang ist noch ein Multiplan Testprogramm.>> Leider habe ich keine Quellen gefunden, die den DAA Befehl vollständig> beschreiben. Für 8080 findet man noch weniger, als für den Z80.> Auf der Suche habe ich aber noch folgende interessante Dokumente> gefunden:>> http://anyplatform.net/cpus.html> (weiter unten 8080/Z80 Series)>> Weitere habe ich schon wieder verloren...
Hallo Leo,
super! Danke!
Ich habe noch ein interesantes "Original-Dokument" gefunden.
Über den folgenden Link kann man sich das "Intel 8080 Microcomputer
System's Users Manual" ansehen:
http://www.scribd.com/doc/19954501/Intel-8080-Manual-1
Auf der Seite 29 von 40 ist der DAA Befehl beschrieben, die betroffenen
Flags (Fußnote 10) sind auf der Seite 33 von 40 beschrieben:
"If the value of the least significant 4-bits of the accumulator is
greater than 9 or if the auxiliary carry bit is set, 6 is added to the
accumulator. If the value of the most significant 4-bits of the
accumulator is now greater than 9 or if the carry bit is set, 6 is added
to the most significant 4-bits of the accumulator."
Viele Grüße
Markus
Hallo zusammen,
der DAA des 8080 ist einfach, da er nur Additionen korrigiert. Der Wert
des H-Flags nach der DAA-Operation ergibt sich aus der Oder-Verknüpfung
des vorherigen Wertes von H und aus der Bedingung Lower Nibble > 9. Also
H=H or (Akku and 0x0f)>9.
Seien a,b Element aus [0..9], s=a+b. Wenn s>9, dann hat ein Überlauf von
der Einerstelle auf die Zehnerstelle stattgefunden, also muss H gesetzt
werden. Jetzt ist es aber so, dass wir nicht 10, sondern 16 als Basis
für eine Stelle haben (Aufspaltung des Bytes in 2 Nibbles), daher wird
für s aus [16..18] das H-Flag automatisch gesetzt. Für s aus [10..15]
gibt es keinen Überlauf im 16er-System, aber im 10er-System, daher muss
das H-Flag über die Bedingung lower nibble>9 gesetzt werden.
Die gleiche Überlegung trifft auch auf das C-Flag und das Higher Nibble
zu, aber man muss hier schon den Überlauf aus der Einerstelle mit
einbeziehen. Das ergibt dann C=C or (Akku>0x99).
Und der Korrekturwert ergibt sich aus den Werten der beiden Flags nach
den beiden oben genannten Oder-Verknüpfungen:
Wenn H=1, dann wird 0x06 zum Akku addiert.
Wenn C=1, dann wird 0x60 zum Akku addiert.
Und wenn beide Flags gesetzt sind, dann ist der Korrekturwert 0x66.
Entsprechende Überlegungen muss man bei der Korrektur für Subtraktionen
beim Z80 machen.
Hallo,
Aus: Z80 Instruction Handbook (Your complete reference to the powerful
Z80 instruction set) - SCELBI Publications
DECIMAL ADJUST THE ACCUMULATOR
DAA 047oct 27hex
The decimal adjust accumulator instruction is a one byte instruction
that adjusts the contents of the accumulator to two binary coded-decimal
digits, one digit in the four least significant bits and one digit in
the four most significant bits. This instruction is used following the
addition or subtraction of two pair of BCD digits to adjust the result
to the proper BCD code. It may also be used following an increment,
decrement, or negate directive. Following an addition operation, this
instruction operates in the following manner.
The least significant half of the accumulator is checked for a BCD value
of zero to nine, and the H flag is checked for a zero condition. If both
of these conditions exist, this half is left as is.
However, if this half is greater than nine, or the H flag is one, the
accumulator will be incremented by six, thereby adjusting the least
significant half to the proper BCD code. The most significant half is
then checked for a BCD value of zero through nine and the C flag is
checked for a zero condition. If both conditions are true, the process
is complete. Otherwise, if either condition is not met, the most
significant half of the accumulator is incremented by six, with the
carry flag being set to a one if an overflow from the most significant
half occurs.
In the case of subtraction, the H and C flags are used to determine if
the value six must be subtracted from each half of the byte (which
occurs if the associated flag is set to a logic one state when the DAA
directive is encountered). The Z, S, and P/V flags are affected by these
operations (P/V reflects parity status). The N flag is not altered
Viele Grüße
Gerrit
Vielen Dank für die weiteren Hinweise zum DAA-Befehl.
Wie die Flags gesetzt werden müssen, ist auch in den 8080 Datenbüchern,
die ich auch auf meiner Festplatte gefunden habe, beschrieben.
Im Anhang ist mein aktueller Stand für den Interpreter.
DAA ist nur für den 8080 drin. Ich habe nochmal die Behandlung der Flags
bei allen relevanten
Befehlen anhand der angehängten Tabelle überprüft, und einige kleine
Fehler korrigiert.
Insbesondere INC und DEC sind dadurch leider größer und langsamer
geworden.
Zum Ausgleich habe ich die Opcode-Tabellen nochmal etwas komprimiert.
Dies brachte
Platzeinsparungen und Geschwindigkeitssteigerungen um unteren
Promillebereich. Insbesondere der
der NOP-Befehl konnte deutlich beschleunigt werden. :-)
Die anderen Interpretervarianten habe ich teilweise nachgezogen. Es
stellt sich aber die Frage, ob diese überhaupt noch von Interesse sind
(evtl. wg. ROM-Größe). Wenn ja, würde ich aber als nächstes Die Dateien
umstrukturieren, so daß die Action-Routinen (fetch/op/store)
nur einmal vorhenden sind.
Als Übung, oder für Leute mit Zeit/Langeweile, hätte ich jetzt folgende
Vorschläge:
1. Testen, testen, testen...
2. Überprüfung, ob die Flags überall richtig behandelt werden.
(kann natürlich mit 1. verbunden werden (DDT))
3. INC/DEC sehen so aus, als könnten sie verbessert werden.
Da die Befehle häufig vorkommen, würde sich das lohnen. Auch Peters
Bench-Schleife ist jetzt langsamer geworden.
Mit welchen SD-Karten gibt es denn noch Probleme?
Vielleicht kann man im Treiber ja noch was verbessern.
Im Anhang ist ein Photo von allen Karten, die bei mir laufen. Auf der
Micro-SD ist kein Hersteller zu finden. Vielleicht möchte ja jemand die
Projektseite damit ergänzen. Die Hardware ist bei mir auf Lochraster
gestrickt (8-Bit RAM).
Karten, die nicht funktionieren, habe ich bei mir keine.
Leo C. schrieb:> Mit welchen SD-Karten gibt es denn noch Probleme?> Vielleicht kann man im Treiber ja noch was verbessern.>> Im Anhang ist ein Photo von allen Karten, die bei mir laufen. Auf der> Micro-SD ist kein Hersteller zu finden. Vielleicht möchte ja jemand die> Projektseite damit ergänzen. Die Hardware ist bei mir auf Lochraster> gestrickt (8-Bit RAM).>> Karten, die nicht funktionieren, habe ich bei mir keine.
Hallo Leo,
ich habe die noch fehlenden SD-Karten (mit Hersteller) von Dir auf der
Projektseite ergänzt.
Welchen Systemtakt hat Dein Lochraster-Aufbau?
Ich frage weil ich auf der Projektseite den Systemtakt (bei mir 20 MHz)
mit angegeben habe.
Ggf. würde ich dann noch einen eigenen Abschnitt für Deine Karten
einfügen.
Viele Grüße
Markus
Falls es noch interessiert und ich habe nicht alles hier gelesen!
"Der Z80 ist beim DAA Befehl inkompatibel zum 8080." Leider ist das
alles ne lange Zeit her. Es kann daher sein, ich erzähle nicht alles
ganz richtig. Alles was ich definitiv weiß:
1. Es gab einen Unterschied im Standard-Befehlssatz von 8080, 8085, Z80
, der auch dokumentiert war.
2. Das wurde ausgenutzt um den Prozessor automatisch zu erkennen.
3. Dieser Unterschied war dort dokumentiert als unwesentlich, weil er in
normalen Programmen nicht vorkommt.
Vielleicht hilft das euch ja.
Ehemaliger Z80-Bastler -
Abdul
Zum DAA Befehl beim Z80 scheint es auch im Netz widersprüchliche
Dokumentationen zu geben, insbesondere was das Flag-Handling anbetrifft.
Gestern musste ich auch feststellen, dass meine Implemntierung beim AX81
nicht zu 100% korrekt ist. Aufgefallen ist es mir aber erst beim
Spectrum-ROM als da in den Zahlen plötzlich vereinzelt Sonderzeichen
aufgetreten sind. Beim ZX81 schein der Fehler dagegen nicht zu stören.
Gruß Jörg
Markus G. schrieb:> Welchen Systemtakt hat Dein Lochraster-Aufbau?> Ich frage weil ich auf der Projektseite den Systemtakt (bei mir 20 MHz)> mit angegeben habe.
Auch 20 MHz.
Hier gibts Bilder:
Beitrag "Re: CP/M auf ATmega88"
Leo C. schrieb:> Markus G. schrieb:>> Welchen Systemtakt hat Dein Lochraster-Aufbau?>> Ich frage weil ich auf der Projektseite den Systemtakt (bei mir 20 MHz)>> mit angegeben habe.>> Auch 20 MHz.>> Hier gibts Bilder:> Beitrag "Re: CP/M auf ATmega88"
Hallo Leo,
Danke für die Info!
Gruß
Markus
Leo C. schrieb:> Joerg Wolfram schrieb:>> Zum DAA Befehl beim Z80 scheint es auch im Netz widersprüchliche>> Dokumentationen zu geben, insbesondere was das Flag-Handling anbetrifft.>> Vielleicht hilft Dir das hier:> http://anyplatform.net/media/guides/cpus/8080%20&%20Z80%20Processor%20Data.txt>> In der Doku fehlt häufig der Zustand des H-Flags nach dem DAA-Befehl.>> @Abdul: "Ehemalig" muß ja nicht für immer sein...
Hallo Leo,
Danke für den Link, ich habe ihn gleich in unsere Projektseite mit
aufgenommen!
@Abdul: "Ehemalig" geht ja gleich gar nicht... ;-)
Gruß
Markus
Ich habe mir mal ein paar Gedanken zum Z80 Interpreter gemacht, und
angefangen, die Tabellenmakros entsprechend zu erweitern.
Folgendermaßen könnte es klappen:
Für jeden Prefix wird eine neue Tabelle angelegt. Für DD und FD könnte
man eine gemeinsame Tabelle verwenden, und beim Einstieg ein Flag
entsprechend setzen.
Wir brauchen dann 4 zusätzliche Tabellen: ED, DD/FD, CB, und CBDD/FD.
Da jede Tabelle 512 Byte belegt, und für die meisten Befehle nochmal
Zwischensprungtabellen dazu kommen, könnte es für den ATmega168 knapp
werden.
Für jeden Prefix gibts eine neue OP-Aktion:
1
do_op_prefixED:
2
mem_read_ds zl,z_pc ;zl = memReadByte(z_pc)
3
adiw z_pcl,1 ;++z_pc
4
ldi zh,high(EDjmp) ;
5
ijmp
6
7
8
do_op_prefixDD:
9
;TODO: Flag für DD setzen
10
11
mem_read_ds zl,z_pc ;zl = memReadByte(z_pc)
12
adiw z_pcl,1 ;++z_pc
13
ldi zh,high(DDFDjmp) ;
14
ijmp
15
16
do_op_prefixFD:
17
;TODO: Flag für FD setzen
18
19
mem_read_ds zl,z_pc ;zl = memReadByte(z_pc)
20
adiw z_pcl,1 ;++z_pc
21
ldi zh,high(DDFDjmp) ;
22
ijmp
Die Tabellen bekommen einen Namen über ein Makro zugeordnet. Zuerst die
schon bestehende Tabelle:
Fetch/Op/Store-Aktionen müssen definiert sein, bevor sie in den Tabellen
referenziert werden können. Damit die Sprünge möglichst kurz werden,
sollten sie
unmittelbar vor der Tabelle, in der sie das erste mal angesprochen
werden,
platziert werden.
Im Anhang ist ein ausbaufähiges Gerüst nach diesem Schema. Ich kann die
Datei ohne Fehler assemblieren, und einen Befehl aus der ED-Tabelle habe
ich erfolgreich getestet.
Leo C. schrieb:> Für DD und FD könnte> man eine gemeinsame Tabelle verwenden
Wenn mich meine Erinnerung nicht trügt, sind beim Z80 das DD und das FD
nur Präfixe, die dafür sorgen, dass der nachfolgende Befehl auf das IX-
bzw. IY-Register wirk, statt auf das HL-Register. Daraus folgen einige
undokumentierte Befehle, da alles, was mit HL geht auch mit IX und IY
geht, nur ein bisschen langsamer und ein Byte mehr an Code.
Hallo Konrad,
so ist es.
Wenn man allerdings bei jedem Befehl mit H, L oder HL prüft, ob vorher
ein DD- oder FD-Prefix war, dürfte das doch zu viel Geschwindigkeit
kosten. Aber man kann es natürlich ausprobieren, vor allem, wenn der
Platz nicht reicht.
Besonders hilfreich finde ich übrigens "The Undocumented Z80
Documented":
http://www.myquest.nl/z80undocumented/
Nicht nur wegen der undokumentierten Befehle.
Brauchen wir wirklich für die DD/FD-Behandlung eigene, vollständige
Sprungtabellen? Ich denke, dass geht besser, wenn man erweiterte
fetch_XX und store_XX-Routinen benutzt. Also zusätzlich zu fetch_HL auch
noch fetch_HLIXIY, welches ein Flag beachtet, dass durch die Präfix
DD/FD gesetzt wird und nach jeder Ausführung wieder zurückgesetzt wird.
Wenn wir z.B. INC HL betrachten, dann ist das fetch_HL, op_INC16 und
store_HL für den i8080. Für Z80 wird daraus folgendes: fetch_HLIXIY,
op_INC16, store_HLIXIY. Bei LD H,(HL) müssen wird daraus dann daraus
fetch_MHLIXIY, op_nop, store_H machen. INC L wäre dann fetch_LXLYL,
op_INC, store_LXLYL für das undokumentierte Feature auf die einzelnen
Bytes der Indexregister zugreifen zu können.
Die Bitbefehle sind leider etwas komplizierter, da hier durch Vorsetzen
von DD aus SET 7,A ein SET 7,(IX+d),A wird, also auf jeden Fall der
Speicher über IX+d angesprochen wird.
Durch die Einführung von fetch_HLIXIY dauert die Verarbeitung von
Befehlen mit HL länger als die mit BC oder DE. Auch muss man bei der
Behandlung des Displacement-Bytes bei fetch_MHLIXIY und store_MHLIXIY
aufpassen, dass sie einzeln aber auch paarweise vorkommen können [Siehe
INC (IX+d); LD (IX+d),A und LD A,(IX+d)].
Markus G. schrieb:>> Ich habe die von mir angefertigte Tabelle (im xls und ods Format) diesem> Beitrag angehangen.>> Diese Webseite diente mir als Quelle:> http://nemesis.lonestar.org/computers/tandy/software/apps/m4/qd/opcodes.txt>>> Viele Grüße>> Markus
Hallo zusammen,
ich habe in den von mir im Beitrag #2542248 erstellten Tabellen drei
versehentlich doppelt vorhandene Z80 Codes (CB01, DD22 und ED6B)
gefunden und korrigiert.
Im Anhang die neuen Tabellen.
Viele Grüße
Markus
Hallo zusammen,
zum Thema Sprungtabellen und zusätzlicher Speicherbedarf:
Wie wäre es, wenn wir, um keine Geschwindigkeitsverluste zu haben und
nicht von vorne herein zu viel Speicher zu verbrauchen, erst einmal nur
alle "offiziellen" Befehlskombinationen implementieren würden?
Wenn wir anschließend wissen wie es mit dem Speicherbedarf (bezogen auf
ATMega 168) aussieht, könnten wir dann ggf. die Befehls-Tabellen
komplett (inkl. illegaler Opcodes) implementieren oder uns mit der
Variante von Bernd B. (mainhattan) weiter beschäftigen?!
Just my 2 cents... :-)
Viele Grüße
Markus
Bernd B. schrieb:> Brauchen wir wirklich für die DD/FD-Behandlung eigene, vollständige> Sprungtabellen?
Dazu habe meine Meinung schon eins höher in der Antwort an Konrad
geschrieben.
Markus G. schrieb:> Wie wäre es, wenn wir, um keine Geschwindigkeitsverluste zu haben und> nicht von vorne herein zu viel Speicher zu verbrauchen, erst einmal nur> alle "offiziellen" Befehlskombinationen implementieren würden?
Natürlich sollte man (solltest Du :)) die dokumentierten Befehle zuerst
implementieren. Ich glaube aber, daß die undokumentierten wenig
zusätzlichen Platz belegen. Der Platz für die Sprungtabelle wird sowiso
benötigt, und der Rest wird meistens aus bereits vorhanden Teilen
zusammen gebaut.
Allgemein:
Ich habe einen (rudimentär getesteten) Vorschlag geliefert, wie man die
bestehende Tabelle für die Z80-Mehrbyteopcodes erweitern kann, weil es
dazu eine Anfrage gab
(Beitrag "Re: CP/M auf ATmega88").
Im Anhang ist noch mal Update.
Die ED-Tabelle ist jetzt fast vollständig. Die ED-Befehle sind aber noch
nicht alle voll funktionsfähig (Bitte die "TODO:"-Stellen suchen).
Die anderen Tabellen (DDFD, CB und DDFDCB) sind bisher nur Platzhalter.
Ich glaube, daß der Code dazu in 16K unterzubringen ist. Im Moment sind
noch über 3,5 KByte frei.
moin moin,
nach langer zeit mal wieder zeit......
1.) alle HL befehle auf eine 256byte page bringen.
2.) auf je eine page die IX und IY befehle. stratadrresse im lowbyte
identisch zu den HL befehlen.
3.) DD/FD schaltet nur das adress highbyte um. nach abarbeitung wieder
auf HL high adresse.
4.) danach normale befehlsabarbeitung.
macht 512byte für die befehle bei gutem tempo.
Hallo Horst,
ich habe mir erlaubt, Deine Tabelle etwas umzuformatieren. Kannst Du sie
in dieser Form noch gebrauchen?
Wenn ja, die ED-Tabelle habe ich ergänzt. Es fehlen noch die
Block-Befehle.
RAM-Test in init.asm
Markus G. hat Recht. Es macht keinen Sinn, das System bei einem
RAM-Fehler weiter laufen zu lassen.
Aber
Markus G. schrieb:> Durch den Eintrag:> .equ MEMTEST = 3>> (oder höher) in der Datei: config.inc>> ist es nun möglich im Falle eines Speicherfehlers auf einem AVR> CP/M-Stick V3.0 den/die defekten DRAM-Chips (IC5 / IC6) anzeigen zu> lassen!
Dieses halte ich aber doch für etwas zu spezialisiert. Nicht jeder hat
einen CP/M-Stick V3.0.
Was haltet Ihr denn von folgender Lösung (Anhang)?
1
CPM on an AVR, v2.1
2
Testing RAM: fill...wait...reread...
3
04<00@0000
4
05<01@0001
5
06<02@0002
6
07<03@0003
7
0C<08@0008
8
0D<09@0009
9
0E<0A@000A
10
0F<0B@000B
11
14<10@0010
12
15<11@0011
13
16<12@0012
14
17<13@0013
15
1C<18@0018
16
1D<19@0019
17
1E<1A@001A
18
1F<1B@001B System halted!
Die ersten 16 Fehler (knapper Bildschirm voll) werden ausgegeben und
dann gestoppt. An den Mustern kann man u.U. erkennen, welche(s) Bit(s)
defekt ist/sind.
Das Ausgabeformat könnte man noch verbessern. Man könnte auch
zusätzliche Spalten ausgeben, mit 1-Bits, die 0 sein sollen und 0-Bits,
die 1 sein sollen. Aber das halte ich auch wieder für übertrieben.
Markus G. schrieb:> Hallo zusammen,>> ich habe meine, im Beitrag #2541628 veröffentlichte,> Speichertest-Routine nun noch einmal verfeinert:>> Durch den Eintrag:>>
1
> .equ MEMTEST = 3
2
>
>> (oder höher) in der Datei: config.inc>> ist es nun möglich im Falle eines Speicherfehlers auf einem AVR> CP/M-Stick V3.0 den/die defekten DRAM-Chips (IC5 / IC6) anzeigen zu> lassen!>> Die geänderte Assembler Quellcode-Datei habe ich diesem Beitrag> angehangen.>> Um die geänderte Speichertest-Routine zu verwenden sind also nur zwei> kleine Schritte nötig:>> 1. Austausch der vorhandenen Datei init.asm im Projektverzeichnis durch> die im Anhang befindliche Datei init.asm.>> 2. Aktivieren der neuen Routine durch die Anweisung:>> .equ MEMTEST = 3>> (oder höher) in der Datei: config.inc>> Auch die alten Speichertest-Routinen können weiterhin verwendet werden,> hierzu ist wie bisher die Anweisung:>> .equ MEMTEST = 1 oder 2>> in der Datei: config.inc zu setzen!>> Siehe auch folgenden Auszug aus der Datei init.asm:>>
>> Viele Grüße>> Markus>>> PS: @Leo: Du darfst auch die neue Version gerne (wieder) ins SVN> einchecken!
Hallo zusammen,
ja, ich verstehe Leo's Eiwand, dass meine Ramtest Variante 3 nur für den
CPM-Stick V3.0 zu gebrauchen ist, das ist absolut richtig!
Genau aus diesem Grund habe ich auch die von mir zuvor implementierte
Variante 2 (MEMTEST = 2) im Code belassen.
Diese ist allgemein gültig, da sie den / die defekten Ram-Chips nicht
durch eine IC-Nummer / Position bestimmt und somit für jede
Aufbauvariante (Lochraster, ältere Platinenversion, etc.) verwendet
werden kann.
Die Ergänzung der Ausgabe um die Bitmuster haltet ich auch für sinnvoll
- Lötspritzer lassen grüßen... ;-)
Mein Vorschlag wäre also die Variante 2 um die Ausgabe der Bitmuster zu
ergänzen.
Viele Grüße
Markus
Peter Sieg schrieb:> Wichtig wäre eine einfache Meldung Ram1 Und/Oder Ram2 defekt und gut ist
Ist Ram1 jetzt der obere oder der untere Chip?
Markus G. schrieb:>> ; Info about MEMTEST:>> ; 0 = no memtest at all>> ; 1 = memtest shows defects but carrys on>> ; 2 = memtest shows defect and stops on first failure>> ; 3 = memtest shows defect, stops on first failure and>> ; shows which RAM chip has to be replaced>> ; on an AVR CP/M-Stick V3.0
Variante 1 hat sich offensichtlich nicht bewährt, da RAM-Fehler zu
leicht übersehen werden können.
Wenn wir Variante 3 in den allgemeinen Code aufnehmen, werden wir über
kurz oder lang auch Schalterstellungen für die anderen Hardwarevarianten
aufnehmen müssen.
Und mein Hauptpunkt: Ich befürchte ganz einfach, daß diejenigen, die
nicht in Lage sind, die Bitmuster zu interpretieren, auch die größten
Schwierigkeiten haben werden, das Programm selbst mit der richtigen
Schalterstellung zu übersetzen.
Im Anhang ist mein aktuelles Verhandlungsangebot :-)
Die Ausgabe könnte dann ungefähr so aussehen:
1
CPM on an AVR, v2.1
2
Testing RAM: fill...wait...reread...
3
Addr xx yy
4
0000 00 04 -------- -----X--
5
0001 01 05 -------- -----X--
6
0002 02 06 -------- -----X--
7
0003 03 07 -------- -----X--
8
0008 08 04 ----X--- -----X--
9
0009 09 05 ----X--- -----X--
10
000A 0A 06 ----X--- -----X--
11
000B 0B 07 ----X--- -----X--
12
000C 0C 04 ----X--- --------
13
000D 0D 05 ----X--- --------
14
000E 0E 06 ----X--- --------
15
000F 0F 07 ----X--- --------
16
0010 10 14 -------- -----X--
17
0011 11 15 -------- -----X--
18
0012 12 16 -------- -----X--
19
0013 13 17 -------- -----X-- System halted!
Verbesserungen am Format, eine ordentliche Überschriftenzeile, und die
Erklärung, was das ganze überhaupt soll, überlasse ich gerne dem Leser.
:-)
Im Anhang ist ein Vorschlag für BREAK-Erkennung und Verarbeitung.
Z. Zt. wird BREAK nur bei einem Character timeout erkannt. Ein BREAK,
daß nur wenig länger als ein normales Zeichen dauert. funktioniert noch
nicht.
BREAK setzt ein Flag in einem Interpreter-Register, in das auch die
Flags für Interrupts (und vielleicht Trace, Einzelschritt...) kommen
sollen.
Z. Zt. setzt BREAK den PC auf null. --> Warmstart.
Denkbar wären auch Kaltstart, Interrupt/NMI, Sprung in Debugger...
Vielleicht brauchen wir für so was noch ein schönes API.
Ich würde mich freuen, wenn viele Leute das mal mit vielen verschiedenen
Terminals/-Emulatoren testen würden. Bei mir funktionierts mit minicom
und Windows Hyperterminal, wobei ich für letzteres Google bemühen mußte,
um die Break-Taste zu finden (ctrl-break, bzw. Strg-Untbr).
Möglicherweise gibt es Terminals, die nur ein kurzes BREAK-Signal
senden. Mit denen funktionierts dann (noch) nicht, und das wären dann
gute Testkanditaten für die Vervollständigung des Codes.
Nils Eilers schrieb:> Was anderes: ich habe gesehen, wird ein BREAK auf der seriellen> Schnittstelle derzeit noch nicht behandelt. Das ADM-3A hat eine extra> Break-Taste und Terminalprogramme bieten üblicherweise die Funktion, ein> Break zu senden. Das würde die Möglichkeit eröffnen, bei Empfang eines> Breaks einen Kalt- oder Warmstart auszuführen, oder einen Debugger> aufzurufen.
Update
ddtz macht intensiv Gebrauch von Z80-Befehlen und kommt jetzt schon
ziemlich weit. Er läuft aber noch nicht wirklich, weil noch eine Menge
Befehle fehlen.
Z. Bsp. CB, und DD/FDCB komplett und in der ED-Tabelle fehlen bis auf
LDDR noch alle Blocktransfer- und Suchbefehle. Ausserdem sind die
implementierten Befehle kaum getestet.
Trace kann jetzt zur Laufzeit durch Schreiben auf einen Port ein- und
ausgschaltet werden. Praktisch zum Testen der neuen Befehle:
1
-l100,11a
2
0100 MVI A,01
3
0102 OUT 4F
4
0104 LXI B,77FF
5
0107 PUSH B
6
0108 POP PSW
7
0109 LXI B,1234
8
010C LXI D,5678
9
010F LXI H,9ABC
10
0112 ??= 08
11
0113 ??= D9
12
0114 ??= 08
13
0115 ??= D9
14
0116 MVI A,00
15
0118 OUT 4F
16
011A NOP
17
011B
18
-g100,11a
19
20
N A =01 BC =0000 DE =0000 HL =0000 SP=0100 PC=0104 01 FF 77
Da z. Zt. einiges in Bewegung ist, habe ich den alten Stand (8080 only,
korrigierter DAA, alter RAM-Test, kein BREAK) als Version 2.2
eingefroren:
http://cloudbase.homelinux.net/viewvc/avr-cpm/avrcpm/tags/2.2/
Die aktuelle Version ist wie üblich im trunk-Zweig.
Peter Sieg schrieb:> Gibts für ddtz eigentlich ein Manual?
Im angehängten Zip ist sogar eins auf Deutsch drin.
(Ich weiß grad nicht mehr wo ich das her hab, deshalb kann ich keinen
Link posten.)
Sorry, das war kein Manual, sondern "nur" eine Art Referenz. Im Netz
findet man aber viele Versionen von ddtz mit englischen und deutschen
Beschreibungen.
Man müßte doch auch ein Handbuch im Netz finden.
(Ich habe hier noch eine Kopie der gedruckten Fassung)
Aber Du wirst es sicher auch so noch finden. Sooo viele Punkte hat das
Hauptmenü ja auch nicht.
Im Z80-Interpreter dürften aber noch ein paar Fehler versteckt sein.
Der Turbo-Editor spinnt, und MC.PAS kann zwar als COM übersetzt werden,
aber mit dem Demosheet verrechnet es sich, wenn man andere/größere
Zahlen eingibt.
Letzte Nacht habe ich mal den Exerciser laufen lassen.
Heute Morgen sah das dann so aus:
Diese Fehler sind inzwischen korrigiert. Der Abbruch mit "Invalid
opcode! " kam beim DAA-Befehl, weil dort immer noch der Teil mit
gesetztem N-Flag fehlt. Den Abbruch habe ich jetzt aber raus gemacht,
damit ich sehen kann, wie weit das Testprogramm die nächste Nacht kommt.
Außerdem habe ich heute die noch fehlenden Block-I/O Befehle eingebaut.
Update im SVN.
Klasse Leo!
TP 3.0 läuft bei mir nun auch. Der Editor bockt zwar noch etwas doch mit
dem Exerciser sollten sich alle Fehler ausmerzen lassen. Es dauert....
Meiner rechnet immer noch hier:
<adc,sbc> hl,<bc,de,hl,sp>....( 71,680) cycles
Hallo Joe,
danke fürs testen.
Versuch's mal mit der Version im Anhang. Damit scheint jetzt alles zu
laufen.
Der Turbopascal-Editor läuft damit, und das Microcalc Demo auch.
Der Exerciser sah bei mir zu letzt so aus:
1
C>ex1
2
Z80 instruction exerciser
3
Undefined status bits NOT taken into account
4
<inc,dec> a...................( 3,072) cycles OK
5
<inc,dec> b...................( 3,072) cycles OK
6
<inc,dec> bc..................( 1,536) cycles OK
7
<inc,dec> c...................( 3,072) cycles OK
8
<inc,dec> d...................( 3,072) cycles OK
9
<inc,dec> de..................( 1,536) cycles OK
10
<inc,dec> e...................( 3,072) cycles OK
11
<inc,dec> h...................( 3,072) cycles OK
12
<inc,dec> hl..................( 1,536) cycles OK
13
<inc,dec> ix..................( 1,536) cycles OK
14
<inc,dec> iy..................( 1,536) cycles OK
15
<inc,dec> l...................( 3,072) cycles OK
16
<inc,dec> (hl)................( 3,072) cycles OK
17
<inc,dec> sp..................( 1,536) cycles OK
18
<inc,dec> (<ix,iy>+1).........( 6,144) cycles OK
19
<inc,dec> (<ix,iy>-1).........( 6,144) cycles OK
20
<inc,dec> ixh.................( 3,072) cycles OK
21
<inc,dec> ixl.................( 3,072) cycles OK
22
<inc,dec> iyh.................( 3,072) cycles OK
23
<inc,dec> iyl.................( 3,072) cycles OK
24
ld <bc,de>,(nnnn).............( 32) cycles OK
25
ld hl,(nnnn)..................( 16) cycles OK
26
ld sp,(nnnn)..................( 16) cycles OK
27
ld <ix,iy>,(nnnn).............( 32) cycles OK
28
ld (nnnn),<bc,de>.............( 64) cycles OK
29
ld (nnnn),hl..................( 16) cycles OK
30
ld (nnnn),sp..................( 16) cycles OK
31
ld (nnnn),<ix,iy>.............( 64) cycles OK
32
ld <bc,de,hl,sp>,nnnn.........( 64) cycles OK
33
ld <ix,iy>,nnnn...............( 32) cycles OK
34
ld a,<(bc),(de)>..............( 44) cycles OK
35
ld <b,c,d,e,h,l,(hl),a>,nn....( 64) cycles OK
36
ld (<ix,iy>+1),nn.............( 32) cycles OK
37
ld (<ix,iy>-1),nn.............( 32) cycles OK
38
ld <b,c,d,e>,(<ix,iy>+1)......( 512) cycles OK
39
ld <b,c,d,e>,(<ix,iy>-1)......( 512) cycles OK
40
ld <h,l>,(<ix,iy>+1)..........( 256) cycles OK
41
ld <h,l>,(<ix,iy>-1)..........( 256) cycles OK
42
ld a,(<ix,iy>+1)..............( 128) cycles OK
43
ld a,(<ix,iy>-1)..............( 128) cycles OK
44
ld <ixh,ixl,iyh,iyl>,nn.......( 32) cycles OK
45
ld <bcdehla>,<bcdehla>........( 3,456) cycles OK
46
ld <bcdexya>,<bcdexya>........( 6,912) cycles OK
47
ld a,(nnnn) / ld (nnnn),a.....( 44) cycles OK
48
ldd<r> (1)....................( 44) cycles OK
49
ldd<r> (2)....................( 44) cycles OK
50
ldi<r> (1)....................( 44) cycles OK
51
ldi<r> (2)....................( 44) cycles OK
52
neg...........................( 16,384) cycles OK
53
<rrd,rld>.....................( 7,168) cycles OK
54
<rlca,rrca,rla,rra>...........( 6,144) cycles OK
55
shf/rot (<ix,iy>+1)...........( 416) cycles OK
56
shf/rot (<ix,iy>-1)...........( 416) cycles OK
57
shf/rot <b,c,d,e,h,l,(hl),a>..( 6,784) cycles OK
58
<set,res> n,<bcdehl(hl)a>.....( 6,912) cycles OK
59
<set,res> n,(<ix,iy>+1).......( 448) cycles OK
60
<set,res> n,(<ix,iy>-1).......( 448) cycles OK
61
ld (<ix,iy>+1),<b,c,d,e>......( 1,024) cycles OK
62
ld (<ix,iy>-1),<b,c,d,e>......( 1,024) cycles OK
63
ld (<ix,iy>+1),<h,l>..........( 256) cycles OK
64
ld (<ix,iy>-1),<h,l>..........( 256) cycles OK
65
ld (<ix,iy>+1),a..............( 64) cycles OK
66
ld (<ix,iy>-1),a..............( 64) cycles OK
67
ld (<bc,de>),a................( 96) cycles OK
68
All tests successful.
Ich habe die Source neu übersetzt und dabei alle Tests die schon positiv
durchgelaufen sind, sowie DAA (bekannter Fehler) und die Block-I/O
Befehle auskommentiert.
Prima, der Editor läuft nun auch!
Wenn du Lust hast dieses Stück zu übernehmen...
instr do_fetch_DIR8, op_DJNZ, do_store_nop ;10 nn ;DJNZ nn
(Z80 OK)
;----------------------------------------------------------------
;|Mnemonic |SZHPNC|Description |Notes |
;|----------+------+---------------------+----------------------|
;|DJNZ e |------|Dec., Jump Non-Zero |B=B-1 till B=0 |
;
;The b register is decremented, and if not zero, the signed value e is
added to pc.
;The jump is measured from the start of the instruction opcode.
;e = Relative addressing (PC=PC+2+offset)
do_op_DJNZ: ; decremt B, jump B=0
lds temp, z_b ; B in temp
dec temp ; temp decrementieren
breq do_op_DJNZ_Z ; bei B=0
sts z_b, temp ; temp in B
subi opl, 0x80 ; z_pc + e im Zweierkomplement
subi z_pcl, 0x80
sbc z_pch, _0
add z_pcl, opl
adc z_pch, _0
do_op_DJNZ_Z:
ret
Joe G. schrieb:> Wenn du Lust hast dieses Stück zu übernehmen...
Nur wenn Du den Fehler behältst. ;-)
Die trickreiche Displacement-Berechnung braucht einen Takt (und ein
Register) weniger. Super!
Die Abkürzung ("Gehe nicht über store_...") bringt aber mehr.
Es gibt noch merkwürdige Fehler. Wenn TP über Q verlassen wird z.B. das
hier:
Logged drive: A
Work file:
Main file:
Edit Compile Run Save
eXecute Dir Quit compiler Options
Text: 0 bytes (8118-8118)
Free: 24301 bytes (8119-E006)
>
S NC A =09 BC =0606 DE =DF28 HL =DC00 SP=E3A9 PC=DC01 76 DF C3
Z N A'=AF BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00 CPU
halted!
oder wenn das compillierte Programm als COM ausgeführt wird:
A>dir
A: TEST PAS : TINST COM : TINST DTA : TINST MSG
A: TURBO COM : TURBO MSG : TURBO OVR : TEST BAK
A: TEST COM
A>test
Das ist ein AVR CP/M Test
A: TEST PASA: T COM A: TINST MSGA: /0123456 789A: TINST
DTAA: TURBO COMA: TURBO COMA: TEST BAKA: TEST BAK
I/O error 00, PC=3A50
Program aborted
A>
Das gilt übrigens auch für Zork1. Beim beenden stürzt es ab.
Damit der TP Editor über VT100 etwas bedienbarer wird, habe ich einige
"übliche" Steuerkommandos eingefügt, wer Lust hat kann ja noch
erweitern.
Da der Z80-Interpreter nun komplett ist, und gut läuft, habe ich mir
erlaubt, die Versionsnummer auf 3.0 zu erhöhen. Diese Version ist auch
wieder dauerhaft im tags-Verzeichnis abgelegt:
http://cloudbase.homelinux.net/viewvc/avr-cpm/avrcpm/tags/3.0/
- Z80 ist jetzt der Defaultprozessor. Das Programm belegt damit z.Zt.
aber mehr als 16 KB Flash. --> Atmega328 erforderlich.
- Für 8080 kann übersetzt werden, wenn "EM_Z80" in config.inc auf 0
gesetzt wird.
- Trace kann jetzt (auch) zur Laufzeit ein- und ausgeschaltet werden.
Einschalten: 1 auf Port 0x4F ausgeben.
Ausschalten: 0 auf Port 0x4F ausgeben.
(ddtz: "O 1 4f")
- Um Trace von der CP/M-Befehlszeile aus zu schalten, wurde das
Timer-Steuerprogramm (im Verzeichnis cpm/utils) erweitert.
(Der Name TIMER.COM passt nicht mehr, Vorschläge?)
- BREAK: Ein laufendes Programm kann jederzeit durch senden von BREAK
abgebrochen werden. Zur Zeit wird dann ein Warmstart ausgeführt,
was natürlich nicht hilft, wenn BDOS und/oder BIOS durch ein
amoklaufendes Programm überschrieben wurden.
Bitte gründlich testen. Kommentare, Änderungs- und
Verbesserungsvorschläge wie immer...
Schönes Wochenende
Hi.
Habe gerade Ramblade (ZiCOG - der Welt kleinste CP/M Computer ;-) ) vor
mir liegen: PCB is 1.9"x1.2" (48x30.5mm) SMT (surface mount)
http://forums.parallax.com/showthread.php?116893-RamBlade-Prop-SRAM-microSD-addon-to-run-ZiCog-CPM-PropDos-Catalina-etc
Und dachte mir so, das wäre doch mal eine Herausforderung @Joe?
Atmega328p in SMD
MicroSD Card Slot
2x4256 Drams in SMD (sind leider sehr groß - Alternative SRam?)
Bisschen Hühnerfutter
Nur Anschluß eines CP2102 Dongles = +3.3V und TTL ser. IO
Platine von beiden Seiten bestückt (sonst wird das nichts)
Peter
Peter Sieg schrieb:> Und dachte mir so, das wäre doch mal eine Herausforderung @Joe?
Das Projekt liegt schon in der Schublade. Als RAM habe ich 16 Stück
HM51W17805J-6 rumliegen (16M EDO DRAM 3.3V). Es würde nur ein IC
benötigt werden da er als 2M x 8 organisiert ist. Mit dem Refresh bin
ich mir nicht ganz sicher, sollte jedoch gehen (vielleicht schaut Leo
auch mal aufs Datenblatt).
Es könnte dann eine CP/M 3.0 Jubiläumsversion geben ;-)
Eine Frage zur RAMDISK.
Wenn ich #define RAMDISKCNT auf 1 setze wird eine Ramdisk angelegt. I:
z.B.
Da ja RAMSIZE nicht ausgewertet wird und in der aktuellen Stickversion
nur 2x256Kx4 verbaut sind, wo liegt dann der Ram und wie groß ist er?
STAT zeigt mir 1M für I: an, was ja nicht sein kann. In diesem Zustand
werden auch alle Programme fehlerhaft beendet. Zum Glück gibt es ja nun
Break ;-)
Ohje Ramdisk,
die habe ich außer Betrieb genommen, als ich die Erweiterung für mehrere
Diskformate eingebaut hatte. Mit etwas Glück, könnte sie laufen, wenn
man die Parameter in config.inc (RAMSIZE) anpasst. Bin aber nicht
optimistisch.
Der Hauptgrund, warum ich mich nicht mehr dafür interessiert habe ist,
daß die RAM-Zugriffe langsamer sind, als die Zugriffe auf die SD-Card.
Zum EDO-Ram: Refresh ist sicher kein Problem, und auch sonst müßte es
genauso funktionieren, wie die normalen D-Rams. EDO ist ja nur eine
weitere "Betriebsart".
EDO-Ram: Ich setzte mal einen Testweise auf die Stickversion.
Ramdisk: Ist nur schade wenn man 2MB verschenkt.
Mal eine ganz andere Frage in den Raum geworfen.
Ob man die Jugend begeistern kann, wenn man ein "CP/M - Shield" für
Arduino ins Leben ruft. Das könnte in beliebigen Ausbaustufen entstehen.
Arduino Nano – Shield mit RAM und SD-Card - kleinstes CP/M System der
Welt ;-)
Arduino Uno – CP/MLino Shield mit VGA und Tastatur
...
Joe
@Joe: Die Idee das als Arduino Nano Addon zu machen gefällt mir!
Läuft allerdings mit 5V = Levelshifter zur SD Karte erforderlich.
Aber das lässt sich ja mit 3k3 und 1k8 (6 Stück) SMD Widerständen
machen.
Leider sind die Arduino nicht wirklich 'billig'.. hatte gerade was um
die 30 US$ gesehen.. aber naja.. auf dem addon wären dann nur Ram und
(Micro-) SD Karte inkl. Levelshiftern..
Peter
Joe G. schrieb:> Ob man die Jugend begeistern kann, wenn man ein "CP/M - Shield" für
...
> Arduino Uno – CP/MLino Shield mit VGA und Tastatur
Arduino kenne ich ja noch. Aber "Shield" ... mußte ich erst mal
nachschlagen.
Ja. Shield muß sein. Und Lino muß umbedingt in den Namen. Aber ob das
für CP/M. daß ja zu seinen Lebzeiten schon nicht wirklich cool war, bei
der "Jugend" reicht? Also wenn es nicht mindestens Gezwitscher blubbern
kann [1], und einen "Gefällt mir" Knopf hat, sicher nicht.
[1] http://bubblino.com/
@Leo C: Haha.. Wink mit dem Zaunpfahl..
Nein ich sehe es folgendermaßen:
Wenn wir ein 'Shield' für diese Platform anbieten haben wir:
- autom. eine fertige Platine für AVR, Quarz, Vin, ggf. USB?
- Ein 'Shield' mit Micro-SD, ggf. Levelshiftern und DRam.
Vorteile:
- AVR Teil kann man fertig kaufen, ist getestet, läßt sich woanders für
verwenden.
- Nur Zusatzplatine muss selbst gebaut werden.
- Evtl. läßt sich Zusatzplatine auch für anderes verwenden!
Nachteile:
- evtl. höherer Preis für beides zusammen anstatt auf einer Platine?
Und an China kommt man solange man sehr günstige Preise haben will nicht
umher (sorry, aber ist so! alles andere ist leider realitätsfern..).
Just my 2 cents
Peter
Die Bastlergemeinde ist sowieso nicht wirklich zu durchschauen. Der
Raspberry-Pi hat einen waren Hype ausgelöst. Mehr als 10.000 verkaufte
Boards innerhalb von Stunden. Ja und was kann man damit tun? Auch nicht
mehr als mit dem CP/M Teil. Na gut Doom spielen aber Ladder und Chess
sind auch ganz nett. An Programmiersprachen gibt es unter CP/M alles als
das Herz begehrt – sogar ohne dot.net Geraffel.
Ich überlege mir mal eine Shield Variante und stelle sie dann zur
Diskussion. Über I2C darf dann auch bubblino angeschlossen werden ;-)
Joe G. schrieb:> Eine Frage zur RAMDISK.
Im aktuellen SVN war nur Code für 4-bit Hardware.
Im Anhang ist jetzt mal eine 8-Bit 192 KB Ramdisk. Getestet habe ich nur
mit 4 MBit Chips, aber es sollte auch mit kleineren funktionieren. Da
die Ramdisk-Größe über Tabellen im BIOS statisch festgelegt ist, muß
dieses eben auch angepaßt werden. Deshalb ist im Anhang auch gleich ein
Diskimage.
Hier mal der Versuch (ausbaufähig), die Speicherorganisation
darzustellen:
Wenn der Z80-Arbeitsspeicher addressiert wird, sind die Adressleitungen
A8-A10 immer High, egal ob entsprechend große RAMs vorhanden oder nicht.
Der Arbeitsspeicher liegt also immer am oberen Ende des physikalischen
RAMs.
Die RAM-Disks füllen den Speicher von unten. Maximal sind 4 Disks a 1
MByte möglich. Zur Zeit wird nicht geprüft, ob eine Ramdisk-Adresse
(Disk/Track/Sector) überhaupt in den vorhandenen Speicher hinein paßt.
Es ist also möglich, durch Schreiben in die RAM-Disk, den
Arbeitsspeicher zu überschreiben.
Eine 192K Disk wird im BIOS (BIOS.MAC) folgendermaßen definiert:
1
; Name spt bls dks dir cks off
2
dpb rd192, 32, 1024, 192, 32, 0, 0
dpb: Macro, daß aus den folgenden Daten den "disk parameter block"
generiert.
spt: sectors per track. Die Zahl muß zum AVR Ramdisk-Treiber passen.
bls: block size (KByte).
dks: disk size. Anzahl Blöcke der Größe bls.
dir: Anzahl Directory Einträge
cks: check size. Anzahl zu prüfender Directory Einträge.
Bei Wechselmedien = cks, sonst 0.
off: offset. Anzahl reservierter Tracks. Wenn off bei der ersten
Ramdisk > 0 ist, wird beim Kaltstart das System hier her kopiert,
und beim Warmstart von hier, statt von SD-Karte geladen. Bringt im
Moment fast nix, da Original BDOS beim Warmstart ohne Disk A:
hängen bleibt.
(s.a. Beitrag "Re: CP/M auf ATmega88")
Die Ramdisk wird beim Starten nicht gelöscht (formatiert), so daß am
Anfang meistens Müll drin steht, den man auch durch "ERA *.*" in allen
Userbereichen nicht weg bekommt. Deshalb gibt es das Programm WIPE.COM
auf dem angehängten Diskimage.
TODO:
- RAMDISK-Zugriff auf für Ramdisk tatsächlich vorhandenes RAM
einschränken. ("#define RAMSIZE" in config.inc)
- Ramdisk(s) abhängig von RAMSIZE dynamisch beim Start einrichten.
Analog zu SD-Karten-Images. BIOS-Anpassung dann nicht mehr notwendig.
- Bei Power-On-Reset die Ramdisk initialisieren.
Sonstige Resets übersteht der Ramdiskinhalt in der Regel, auch wenn
dabei der Refresh für längere Zeit ausfällt.
- Ramdisk-Treiber für 4-bit-RAM aktualisieren.
- MMU: "Ge-paged-tes" RAM für CP/M3
Freiwillige vor.
Die Ramdisk haben wir damals initialisiert, indem wir den ersten
versteckten DIR-Eintrag getestet haben. War es unser Eintrag, war die
Initialisierung fertig. Waren fremde Bytes drin, so wurde unser Eintrag
geschrieben, der Rest vom DIR gelöscht und in den Speicherbereich, auf
den der DIR-Eintrag zeigt, das CCP kopiert.
Leo C. schrieb:> Im Anhang ist jetzt mal eine 8-Bit 192 KB Ramdisk.
Danke Leo! Deine Version geht nun auch mit 256 x 8. Das gibt genau eine
Ramdisk von 192 KB. Unter Verwendung von Wipe läßt sie sich auch sauber
löschen und dann beschreiben. Die Variante zunächst das BIOS zu ändern
und dan ein neues CP/M zu bauen ist akzeptabel. Dabei viel mir auf, das
in unsrer Version SUBMIT nicht richtig ausgeführt wird. M80 und L80
werden einfach nicht gestartet. Auf AltairSIMH läuft es jedoch
problemlos
Joe
bin grade auf euer interessantes Projekt gestoßen.
Bei der Suche nach den RAM's hatte ich bisher kein Glück, die alten
PCs/Amigas habe ich längst verschrottet, und so alte DRAMs noch zu
kaufen ist nicht so einfach...
Hat jemand von euch noch zwei DRAM-Chips übrig?
Vielleicht hat jemand auch noch eine oder zwei Platinen zu verkaufen?
Gruß Jens
Hallo Jens,
RAM's solltest du hier bekommen:
http://www.demotronic.net/
Vielleicht hat Peter auch noch welche übrig?
Eine Platine (Varinate 3 - Stick) hätte ich noch mit zugehörigem SD
Slot.
Ansonsten noch etwas warten, ich bin gerade an der neuen Hardwareversion
mit einem Arduino Pro Mini als CPU-Board.
Joe
Jens schrieb:> bin grade auf euer interessantes Projekt gestoßen.> Bei der Suche nach den RAM's hatte ich bisher kein Glück, die alten> PCs/Amigas habe ich längst verschrottet, und so alte DRAMs noch zu> kaufen ist nicht so einfach...> Hat jemand von euch noch zwei DRAM-Chips übrig?> Vielleicht hat jemand auch noch eine oder zwei Platinen zu verkaufen?>> Gruß Jens
Hallo Jens,
ich selbst kann Dir leider nichts anbieten, aber ebay ist Dein Freund
z.B:
http://www.ebay.de/itm/DRAM-ICs-72-x-256Kbyte-gesockelt-Board-18MB-Classic-/251037082536?pt=Bauteile&hash=item3a72f9e3a8
Ich meine nicht die dort angebotene Platine (zu teuer / zu viele
Bausteine für Deinen Zweck) sondern das was der Verkäufer weiter unten
noch schreibt:
Voraussichtlich nächste Woche biete ich noch viel mehr Schaltkreise aus
meiner Hobbyzeit der
70er bis 90er- Jahre an. Die Aufbereitung zur Einstellung ist jedoch
sehr aufwändig/zeitintensiv,
weshalb ich gegenwärtig eher überlege, das Folgende in Pakete
zusammenzustellen.
Hier ein vorläufiger Überblick (Typenvielfalt und Daten werden noch
erweitert):
...
4 HY 534256 S-10 Hynix CMOS
4 HY 53C256 -LS80 Hynix CMOS
36 HY 53C256 LS-80 ? RAM- Board
...
Der oben genannten Chips wären z.B. passende DRAM's für das hier
beschriebene Projekt.
Entscheidend ist, das die DRAM's 4bit x 256kbit organisiert sind, nicht
zu verwechseln mit 1bit x 256kbit wie z.B. HYB 41256-10 Siemens DRAM!
Ich würde den Verkäufer einfach mal anschreiben...
Viele Grüße
Markus
Der verkauft auch HAL16V8.
Wenn ich mich recht erinnere, dann haben HAL eine vom Hersteller
festgelegte ROM-Maske. Im Gegensatz zu PAL (mit Zener-Fuse) und GAL (mit
EEPROM) ist da nix mit wiederverwenden.
Joe G. schrieb:> Dabei viel mir auf, das> in unsrer Version SUBMIT nicht richtig ausgeführt wird. M80 und L80> werden einfach nicht gestartet. Auf AltairSIMH läuft es jedoch> problemlos
Das habe jetzt endlich mal getestet und ist hier leider genauso.
Aber früher ging das mal...
Vorläufig kann man DO.COM (bzw. SuperSUB), z.B. aus obigem
Emulator-Paket nehmen, das sowieso besser ist.
Noch was anderes.
Da wir ja inzwischen auch Z80 können, wäre es auch interessant, einen
der verbesserten BDOS-Clones zu installieren. Diese wiederum würden von
einem Uhrenbaustein profitieren.
Da ich demnächst sowieso einige Bauteile bestellen will, möchte ich
einen RTC mitbestellen. Welcher Chip ist denn hier so gängig/beliebt?
Beim Reichelt käme wohl nur der DS1307 in Frage.
Der DS1307 ist sehr weit verbreitet und sicherlich nicht die
schlechteste Wahl.
Ich hatte mir die Tage auch schon mal Gedanken darüber gemacht wie I2C
zu benutzen ist. Es könnten ja dann dort ein 8 Bit I/O Port oder A/D
oder oder angeschlossen werden. Die BIOS Funktionen 05 - Stanzer und 06
- Lesereingabe werden doch eigentlich nie mehr benötig. Diese Funktionen
könnten doch eigentlich genutzt werden um auf den I2C zu schreiben bzw.
vom I2C zu lesen. Wir müßten uns nur noch ein ordentliches Protokoll
einfallen lassen.
An andere BDOS-Clones habe ich auch schon gedacht CP/M 3.0 ...
Joe G. schrieb:> Der DS1307 ist sehr weit verbreitet und sicherlich nicht die> schlechteste Wahl.
Na, dann kommen mal >= 2 [1] auf die Liste.
> oder oder angeschlossen werden. Die BIOS Funktionen 05 - Stanzer und 06> - Lesereingabe werden doch eigentlich nie mehr benötig. Diese Funktionen> könnten doch eigentlich genutzt werden um auf den I2C zu schreiben bzw.
Ich habe noch einen Stapel Lochkarten. Aber leider keine Stanze. ;-)
Imho greifen alle gängigen CP/M Kommunikationsprogramme direkt auf die
Ports der seriellen Schittstelle zu, weil die CP/M-Kanäle kaum zu
gebrauchen sind.
Man könnte z.B. im AVR-Teil (damals) gängige UARTs emulieren.
> An andere BDOS-Clones habe ich auch schon gedacht CP/M 3.0 ...
CP/M 3 ging vorher auch schon, da es mit 8080 auskommt. Macht meiner
Meinung nach ohne Banking wenig Sinn. Die Alternativen leisten dann
mehr, bei weniger RAM-Verbrauch.
[1] Da ich z.Zt. dabei bin, meine gute alte HD64180 Karte [2]
wiederzubeleben, soll die natülich nicht zurück stehen müssen.
Allerdings wäre dafür ein RTC mit SPI besser.
[2] Beitrag "Re: z80 system"
Hallo Peter,
ist der V53C104P10L auf dem CP/M-Stick einsetzbar? Wenn ja hätte ich
Interesse an zwei oder vier Stück davon, kannst du mir vielleicht per PM
an jenskauf(at)gmx.net schreiben?
Gruß Jens
Sieht schick aus!
USB Anbindung wie? FT232RL?
Welcher Ramchip (1 oder 2?)? Bezugsquelle?
Gibts passende Arduino Pro Mini über ebay oder wo?
Ansonsten wäre ich mit 2 Stück dabei (je nach Preis auch 3-5).
Peter
USB über FT232RL, die Variante über den MCP2200 würde noch einen
externen Quarz benötigen.
DRAM ist ein HM51W17805 (16M EDO RAM 2-Mword x 8 Bit)
Als Arduino Pro Mini würde auch ein DFRobot Pro Mini V1.2 5V 16MHz
Arduino Compatible gehen (9,9 €) allerdings müßte bei allen Varianten
(auch China) ein 3.3V Regler eingesetzt werden.
Platine derzeit 4 Lagen, es geht sehr eng zu! bei einer Abnahmemenge von
10 liegt der Preis ca. um 11€.
Joe
Hallo Leute,
man ist der Tread riesig. Folgendes Problem: Ich habe einen AVR Stick
(der aus diesem Forum) geschenkt bekommen. Da ist allerdings eine alte
Version an Software drauf. Nun lese ich hier etwas von FAT 16 und Z80
Unterstützung. Wie bekomme ich das alles auf den Stick? Dem Atmel ein
binärfile reinschiessen bekomme ich hin, wie gehts dann mit der SD
Karte? Gibt es da eine Anleitung oder kann mir einer erklären wo ich die
Files wie draufspielen muss?
Gruß
Hannes
Um die AVR-Firmware neu übersetzen (Taktfrequenz 20 statt 24 MHz) habe
ich versucht, die Batchdatei AVRBuild.bat im Ordner der Sourcen
auszuführen, ich erhalte folgende Meldungen:
---
AVRASM: AVR macro assembler 2.1.42 (build 1796 Sep 15 2009 10:48:36)
Copyright (C) 1995-2009 ATMEL Corporation
D:\Jens Privat\Z80\Software\AVR\avr\init.asm(44): error: ldiw: Unknown
instructi on or macro
D:\Jens Privat\Z80\Software\AVR\avr\init.asm(44): error: syntax error,
unexpected ',', expecting ':'
Assembly failed, 2 errors, 0 warnings
---
Wie sind die Sourcen zu compilieren, was ist ggf. vorher zu
installieren?
Gruß Jens
Es sieht aus aus ob bei dir die Datei macros.inc nicht geladen wird.
In der avrcpm.asm müßte folgendes stehen:
.include "config.inc"
.include "svnrev.inc"
.include "macros.inc"
Den richtigen Prozessor hast du gesetzt? -Datmega328P
Jens Kaufmann schrieb:> Um die AVR-Firmware neu übersetzen (Taktfrequenz 20 statt 24 MHz) habe> ich versucht, die Batchdatei AVRBuild.bat im Ordner der Sourcen> auszuführen, ich erhalte folgende Meldungen:
In den Sourcen gibt es keine Batchdatei.
Es gibt allerdings ein Makefile, das auch unter Windows funktioniert,
wenn GNU Make installiert ist.
Wo es die Sourcen gibt, hat Joe im Artikel direkt über Deinem gepostet.
Leo C. schrieb:> In den Sourcen gibt es keine Batchdatei.
Ich nehme an, dass ist die Batchdatei die ich mit den Quellen auf die
SD-Card gespielt hatte. Entweder wie Leo C. schon sagte das Makefile
verwenden oder im AVR-Studio das Projekt avrcpm.aps öffnen und unter
Project | Assembler Options die zeile
-DF_CPU=20000000 -DBAUD=57600 -Datmega328P -DDRAM_8BIT
eingeben.
@ Leo C.
Mich würde mal interessieren, ob der DS1307 auch mit 3.3V I2C läuft,
spezifiziert ist er ja nur für 5V. Auch für weitere IC's (IO, AD, DA
...) ist es interessant. Ansonsten müßte ein PCA9306 oder ähnliches
verwendet werden.
Mit der UART Emulation für I2C könnte ich mich auch anfreunden. Dann
kann der I2C Bus mit Kermit oder ähnlicher Software angesprochen werden.
Joe G. schrieb:> Ich nehme an, dass ist die Batchdatei die ich mit den Quellen auf> die SD-Card gespielt hatte.
Dann schaue ich mir die mal an.
> Mich würde mal interessieren, ob der DS1307 auch mit 3.3V I2C läuft,> spezifiziert ist er ja nur für 5V.
Ups, das hatte ich auch übersehen. Das Datenblatt meint:
"When a 3-volt battery is connected to the device and VCC is below 1.25
x VBAT, reads and writes are inhibited."
Mit einer 2,5Volt Batterie würde es wahrscheinlich funktionieren...
> Auch für weitere IC's (IO, AD, DA ...) ist es interessant. Ansonsten> müßte ein PCA9306 oder ähnliches verwendet werden.
Ähnliches wäre z.B.: AN79055 "Bi-directional level shifter for I²C-bus
and other systems." (2 FETs und 2 zusätzliche Pullups.)
https://www.google.com/search?q=%22AN97055%22
Beim Reichelt habe ich noch den PCF8583 gefunden. Größerer
Stromverbrauch, kein Batterie-Management, aber billiger und *"operating
supply voltage: 2.5 V to 6 V"*
Für mein anderes Projekt (HD64180) gehen die aber beide nicht, da ich
dort kein I2C habe.
Joe G. schrieb:> USB über FT232RL, die Variante über den MCP2200 würde noch einen> externen Quarz benötigen.> DRAM ist ein HM51W17805 (16M EDO RAM 2-Mword x 8 Bit)> Als Arduino Pro Mini würde auch ein DFRobot Pro Mini V1.2 5V 16MHz> Arduino Compatible gehen (9,9 €) allerdings müßte bei allen Varianten> (auch China) ein 3.3V Regler eingesetzt werden.> Platine derzeit 4 Lagen, es geht sehr eng zu! bei einer Abnahmemenge von> 10 liegt der Preis ca. um 11€.> Joe
Hmm.. ich werde (für mich) das Gefühl nicht los, das wir dann mit dem
'USB Stick' Konzept besser dran sind.. was meinen die anderen..
Peter
@Joe: Die/Deine Arbeit an sich ist klasse!!
Nur wenn halt alles so mal zusammen rechne.. entschwinden z.Z alle
Vorteile..
Eine separate Platine - evtl. direkt für CP2102 Dongle Anschluß.. geht
evtl. etwas größer mir Bestückung von beiden Seiten.. und viel
günstiger..
Atmega328P+DRAM+Micro-SD+Hühnerfutter
Peter
Peter Sieg schrieb:> Hmm.. ich werde (für mich) das Gefühl nicht los, das wir dann mit dem> 'USB Stick' Konzept besser dran sind.. was meinen die anderen..
Definiere "wir".
Peter Sieg schrieb:> Nur wenn halt alles so mal zusammen rechne.. entschwinden z.Z alle> Vorteile..
Also weiter oben hast Du noch ganz anders argumentiert.
Könnte ja sein, daß das Ding in der "Arduino-Szene" richtig einschlägt.
(Zumindest hier merkt aber leider bisher nichts davon.)
Joe G. schrieb:> ZSDOS Portieren ist ja auch eine nette Aufgabe.
Genau. Super.
Nils S. schrieb:> ... und eine MMU, FPU von Vorteil, 32 Bit Arch. (16 wüde gehen), und> und und
Ohne MMU ist ein Kernel zwar auch realisierbar aber der Kern lebt und
stirbt mit der MMU den das ist es was Ihn so stabil macht. Die Hardware
MMU ist es was ein Linux System so gut laufen lässt.
Waschmaschinenprozessoren ohne MMU sind zwar auch möglich nur das geht
eben von Zeit zu Zeit schief wenn da irgend ein Programm meint es muss
ins RAM posten. Abgesehen davon das ein ARM9 oder ARM11 sehr wenig
kostet und eben diese MMU schon hat. Warum implementierst Du das CP/M
System nicht auf dem ARM9/11? Der ist schon von vorne herein 32bit breit
und mit dem 3S2440 von Samsung der in einem FriendlyARM eingebaut ist
sehr sehr kostengünstig (die Hardware kostet ca. USD60 - 80,- inkl 3,5"
Schirm) uf den kann man bereits ein Keyboard und Netzwerk anstecken.
MfG
weakbit
Joe G. schrieb:> Gibt es eigentlich einen vernünftigen Grund warum wir beim CP/M mit dem> 62K Speichermodell arbeiten?
Ja, wurde von sprite_tm so "geliefert", ... und Trägheit.
Um das zu änderen braucht man eine möglichst vollständige
CPM-Distribution. Bei uns fehlt movcpm.com mit der zugehörigen
Seriennummer.
Oder man generiert alles neu aus den im Netz vorhandenen Sourcen.
Vor ein paar Wochen hatte ich mal mit movcpm angefangen, bin aber wieder
davon abgekommen. Im Anhang ist das Ergebnis. Das movcpm finde ich z.Zt.
nicht, meine Notizen auch nicht. Im Makefile und in CFGACPM.LIB die
gewünschte Spreichergröße setzen.
64k-System macht aber mit unseren großen Diskimages wenig Sinn, da diese
für alv und csv viel Platz beanspruchen. (Man kann das beobachten, in
dem man in avr/config.inc HEAP_DEBUG auf 1 setzt.)
SUBMIT
hatte ich mir gestern Abend nochmal angeschaut.
Joe, falls der Submit-Job "nur" dann nicht ausgeführt wird, wenn er
nicht auf Laufwerk A gestartet wird, handelt es sich (leider) um das
dokumentierte Verhalten von CP/M 2.x. [1]:
1
"If the SUBMIT function is performed on any disk other than
2
drive A, the commands are not processed until the disk is inserted
3
into drive A and the system reboots."
It's not a bug, ...
Beim simh Altair 8800 Emulator funktioniert Submit auch auf anderen
Laufwerken, weil dort dafür (und einige andere Kleinigkeiten) im BIOS
Patches vorhanden sind, die bei jedem Warmstart an CCP und BDOS
appliziert werden.
Man kann sich das Patchen aber sparen, wenn man Submit durch eine der
zahlreich vorhandenen Alternativen (DO, SUPERSUB, JOB, ...) ersetzt.
[1] http://www.cpm.z80.de/manuals/archive/cpm22htm/ch1.htm#Section_1.6.7
Leo C. schrieb:> Man kann sich das Patchen aber sparen, wenn man Submit durch eine der> zahlreich vorhandenen Alternativen (DO, SUPERSUB, JOB, ...) ersetzt.
Leider bricht DO oder SUPERSUB auch mit einem Fehler ab, M80 und L80
einzeln benutzt geht jedoch (Die Datein sind auch auf der HD).
D>do makecpm
SuperSUB V1.1
Memory full error on line number: 2501
Anbei noch alle Datein um sich ein komplettes ZSDOS zu basteln. Das
Diskimage ist wie immer im Altairformat.
Joe
Leo C. schrieb:> Joe, versuch's mal hiermit.
Danke! Es geht damit. Doch warum? Liegt der Unterschied wirklich nur
darin, dass dein File genau 256 Byte lang ist?
> Ok, es war ^Z
Es hätte mich auch gewundert, wenn Du nicht drauf gekommen wärst. Ich
war aber gerade dabei, eine längere Antwort zu tippen. Vielleicht
interessierts ja noch jemanden.
Die 256 Byte sind eher Zufall. Ich habe mit ddt den Sektor nach dem Text
mit 01AH (== ^Z == CP/M End Of File) aufgefüllt. Die Datei habe ich
danach mit SAVE 1 <dateiname> gespeichert.
SuperSub scheint beim Einlesen das physikalische Dateiende nicht zu
beachten, und versucht dann den gesamten Arbeitsspeicher als Text zu
interpretieren, bzw. bis ein EOF-Zeichen erkannt wird.
CP/M 3 (und ZSDOS glaube ich auch) können den Füllgrad des letzten
Sektors speichern (und damit die exakte Dateilänge), aber wahrscheinlich
macht kein CP/M-Programm davon Gebrauch. CP/M Texteditoren speichern
natürlich immer (mindestens) ein 01Ah am Textende.
Vielleicht hat Dein PC-Texteditor ja eine Möglichkeit, Steuerzeichen
direkt einzugeben. Ansonsten: echo, dd, copy, cat, ...
Leo C. schrieb:> Vielleicht hat Dein PC-Texteditor ja eine Möglichkeit
Ich nehme nun WinVi...
@alle
Um die Vorteile des ZSDOS nun auch wirklich nutzen zu können, braucht es
nun der Uhr. Vielleicht können wir uns auf eine gemeinsame
Hardwarevariante verständigen. Anbei mein Vorschlag. Die Uhr (DS1307)
ist über einen Pegelwandler am I2C Bus angeschlossen. Weiterhin ist am
Bus ein PCF8574 (8 Bit I/O). Somit hätte man neben der Uhr noch die
Möglichkeit einen vollständigen 8 Bit Port zu benutzen (LCD, Tastatur,
Led, wie auch immer). Außerdem können ja weitere I2C Geräte
angeschlossen werden.
Kommentare, Vorschläge?
Joe
Joe G. schrieb:> Um die Vorteile des ZSDOS nun auch wirklich nutzen zu können, braucht es> nun der Uhr.
Um die Zeit bis zur funktionierenden RTC zu überbrücken, bastel ich
gerade an der Interrupt-Uhr.
> Die Uhr (DS1307)> ist über einen Pegelwandler am I2C Bus angeschlossen.
2. Stromversorgung und Pegelwandler wegen eines unpassenden
Uhrenbausteins?
Wie wärs mit PCF8583 oder DS1337 + 2 Dioden?
> Weiterhin ist am> Bus ein PCF8574 (8 Bit I/O). Somit hätte man neben der Uhr noch die> Möglichkeit einen vollständigen 8 Bit Port zu benutzen (LCD, Tastatur,> Led, wie auch immer). Außerdem können ja weitere I2C Geräte> angeschlossen werden.
Was könnte man denn noch anschließen wollen?
Drucker vielleicht? Dann bräuchte man 2. PCF8574 oder zB. PCA9555.
2. Serielle? Gibs I2C-UARTS? 2. Software-UART stelle ich mir schwierig
vor.
Ok, der PCF8574 geht auch bei 3.3V und ist bei Reichelt als DIL und Smd
verfügbar. PCF8574 und PCA9555 gehen auch bei 3.3V und haben 5V
tolerante Eingänge. Der Pegelwandler kann also entfallen.
Bei der Erweiterung dachte ich in Richtung Anwendung Arduino. Ein
embedded System (ich hab das CP/M gerade geadelt) lebt ja von externer
Hardware. Mit 8 oder 16 Bit I/O könnte der potentielle Nutzer schon eine
Menge anschließen. Ideal wäre die Ansteuerung wie ich schon mal
vorgeschlagen habe über die ungenutzten Biosfunktionen Reader.
Ersetzt man den mega328p durch die smd Version, bekommt man noch zwei
zusätzliche Pins in Form von 2 AD-Wandlern spendiert (ADC6 und ADC7).
Mein derzeitiger Entwurf sieht gerade so aus (pdf). Er hat die Maße
100mm x 70mm und passt damit genau in ein Fischer Alu-Gehäuse (AKG 7124
ME). Das System beinhaltet neben der USB ein VT100 Terminal mit VGA und
Tastaturanschluss den zwei ADC + I2C, sowie 8 Bit I/O.
Eine ähnliche Variante hatte ich schon mal vorgestellt. Sie ist hier
nicht sosehr auf Interesse gestoßen. Macht jedoch nichts, die neue baue
ich mir selber auf. Ich glaube im Gegensatz zum embedded Linux
(raspberry pi u.ä.) kann ein potentieller Interessent (Schüler,
Studenten, wie auch immer) damit ein komplettes System komplett selber
aufbauen, sein CP/M (Kernel) selbst konfigurieren und zusammenstellen.
Das System ist wirklich einfach und überschaubar.
Joe
Peter Sieg schrieb:> Joe G. schrieb:>> USB über FT232RL, die Variante über den MCP2200 würde noch einen>> externen Quarz benötigen.>> DRAM ist ein HM51W17805 (16M EDO RAM 2-Mword x 8 Bit)>> Als Arduino Pro Mini würde auch ein DFRobot Pro Mini V1.2 5V 16MHz>> Arduino Compatible gehen (9,9 €) allerdings müßte bei allen Varianten>> (auch China) ein 3.3V Regler eingesetzt werden.>> Platine derzeit 4 Lagen, es geht sehr eng zu! bei einer Abnahmemenge von>> 10 liegt der Preis ca. um 11€.>> Joe>> Hmm.. ich werde (für mich) das Gefühl nicht los, das wir dann mit dem> 'USB Stick' Konzept besser dran sind.. was meinen die anderen..>> Peter
Hallo zusammen,
ich werde, für mich persönlich, mit meinem "USB Stick" weiter arbeiten.
@Joe: Aber meinen ausdrücklichen Respekt, wie Du immer die Layouts hier
zauberst... :-)
Und vielen Dank für den Anstoss zur ZSDOS Portierung! Klasse!
Viele Grüße
Markus
Leo C. schrieb:> Joe G. schrieb:>>> Um die Vorteile des ZSDOS nun auch wirklich nutzen zu können, braucht es>> nun der Uhr.>> Um die Zeit bis zur funktionierenden RTC zu überbrücken, bastel ich> gerade an der Interrupt-Uhr.>>> Die Uhr (DS1307)>> ist über einen Pegelwandler am I2C Bus angeschlossen.>> 2. Stromversorgung und Pegelwandler wegen eines unpassenden> Uhrenbausteins?> Wie wärs mit PCF8583 oder DS1337 + 2 Dioden?>>> Weiterhin ist am>> Bus ein PCF8574 (8 Bit I/O). Somit hätte man neben der Uhr noch die>> Möglichkeit einen vollständigen 8 Bit Port zu benutzen (LCD, Tastatur,>> Led, wie auch immer). Außerdem können ja weitere I2C Geräte>> angeschlossen werden.>> Was könnte man denn noch anschließen wollen?> Drucker vielleicht? Dann bräuchte man 2. PCF8574 oder zB. PCA9555.> 2. Serielle? Gibs I2C-UARTS? 2. Software-UART stelle ich mir schwierig> vor.
Hallo zusammen,
bezüglich des Uhrenbausteins tendiere ich zum PCF8583 wie von Leo
vorgeschlagen, hat auch noch 240 Byte RAM als "Dreingabe" kann man
bestimmt einmal gebrauchen... ;-)
Oder gibt es Etwas das uns veranlassen sollte explizit einen DS1337 zu
nutzen?
Die I2C Bus-Erweiterung per PCF8574 o.ä. finde ich auch super!
In Zusammenhang mit meinem "AVR/CPM-Stick" denke ich gerade an eine
"Sandwich"-Platine als Aufsatz auf den AVR-Sockel des AVR/CPM-Sticks.
Somit hätte ich dann beliebig viel Platz für Erweiterungen...
Just my 2 cents
Viele Grüße
Markus
> bezüglich des Uhrenbausteins tendiere ich zum PCF8583 wie von Leo> vorgeschlagen, hat auch noch 240 Byte RAM als "Dreingabe" kann man> bestimmt einmal gebrauchen... ;-)
Das RAM könnte man zum bisher ungenutzten EEPROM legen. ;-)
> Oder gibt es Etwas das uns veranlassen sollte explizit einen DS1337 zu> nutzen?
Der PCF8583 ist schon etwas älter und wohl auch einige Designschwächen.
Ein besserer Nachfolger ist der PCF8563, der aber schwieriger zu
bekommen ist. Ob der DS1337 irgend einen Vorteil hat, kann ich jetzt
auch nicht sagen.
Leo C. schrieb:> Ein besserer Nachfolger ist der PCF8563, der aber schwieriger zu> bekommen ist
Mir ist es egal, der PDF8563 ist u.a. bei Farnell zu haben, also kein
Problem.
Joe G. schrieb:> Mir ist es egal, der PDF8563 ist u.a. bei Farnell zu haben, also kein> Problem.
Mir ist's auch egal. Die Softwarunterschiede sind gering. Man kann
sicher mit einem Treiber beide ansprechen. Leider sind sie nicht ganz
pinkompatibel. Aber wenn man an Pin 3 (A0/INT) und 7 (INT/CLKOUT) je
einen Pullup vorsieht, müßten beide Chips damit klarkommen. Dann kann
jeder seinen Wunschchip einstecken.
Ich habe vor, bei Reichelt einen PCF8583 zu bestellen. Für mein anderes
Projekt möchte ich einen DS2417 (1-wire) nehmen. Ginge hier auch. ;-)
Hallo Joe,
deine Anweisungen:
# Hallo Hannes,
# SD Card:
# Deine SD Card mit Fat16 formatieren und dann die Imagefiles
# CPMDSK_A.IMG, CPMDSK_B.IMG und CPMDSK_C.IMG aus
# http://www.mikrocontroller.net/articles/AVR_CP/M
# auf die Karte kopieren.
hat geklappt konnte ich mit meinem AVR auch lesen
# AVR Binärfile:
# Aktuelle Version von hier laden
# http://cloudbase.homelinux.net/viewvc/avr-cpm/avrc...
# übersetzen und auf den AVR bringen.
AVR Trunk herunter geladen und versucht zu übersetzen...
(Windows XP AVR Studio 4) Fehler zu wenig Speicher für das Programm im
Speicher des ATMega 168 ... also das ganze für einen 328er... nach
einigen Kämpfen auch geschafft. (aktuell AVR Studio 5)
# Bei Fragen fragen.
Wie gesagt habe ich den AVR CP/M Stick
Welche Einstellungen müssen in den Files gemacht werden? Angabe des RAM
(2 X 4256er! Wie setzt ihr die config bits? Bei mir zuckt nichts....
# Joe
Gruß
Hannes
@Hannes
so sollte es gehen.
Als ASM Options im AVR Studio:
-DF_CPU=20000000 -DBAUD=115200 -Datmega328P -DDRAM_8BIT
Takt und Baudrate natürlich an das eigene System anpassen.
In der config Datei sollte folgedes stehen:
#define K 1024
#define M 1024*K
#define RAMSIZE 256*K*4 /* 1 chip 256Kx4 */
;#define RAMSIZE 4*M*4 * 2 /* 2 chips 4Mx4 */
#define EM_Z80 1 /* Emulate Z80 if true */
#ifndef FAT16_SUPPORT
#define FAT16_SUPPORT 1 /* Include Support for FAT16 Partitions */
#endif /* which may contain CP/M image files. */
#define RAMDISKCNT 1 /* Number of RAM disks */
#define RAMDISKNR 'I'-'A' /* Drive "letter" for first RAM disk */
#define PARTID 0x52 /* Partition table id */
/* http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
*/
#define IPLADDR 0x2000 /* Bootloader load address */
#define DRAM_WAITSTATES 1 /* Number of additional clock cycles for dram
read access */
#define REFR_RATE 64000 /* dram refresh rate in cycles/s. */
/* Most drams need 1/15.6µs. */
#define RXBUFSIZE 128 /* USART recieve buffer size. Must be power of
2 */
#define TXBUFSIZE 128 /* USART transmit buffer size. Must be power
of 2 */
#if EM_Z80
#define CPUSTR "Z80"
#else
#define CPUSTR "8080"
#endif
.equ BOOTWAIT = 1
.equ MEMTEST = 1
.equ MEMFILL = 1
.equ MMC_DEBUG = 0 /* Increase for more debugging */
.equ FAT16_DEBUG = 0
.equ FAT16_RWDEBUG = 0
.equ FAT16_DBG_FAT = 0
.equ DISK_DEBUG = 0 /* Increase for more debugging */
.equ HOSTRW_DEBUG = 0
.equ HEAP_DEBUG = 0
.equ PORT_DEBUG = 0
.equ INS_DEBUG = 0
.equ STACK_DBG = 0
.equ PRINT_PC = 0
#define MMC_SPI2X 1 /* 0 = SPI CLK/4, 1 = SPI CLK/2 */
Nach dem Reset sollte dann im Terminalprogram (Baudrate und COM-Port
natürlich korrekt einstellen) sofort die Bootmeldung kommen. Auch wenn
die SD Card nicht richtig gelesen wird kommt auf jeden Fall eine
Meldung. Wenn nicht, zunächst mal prüfen ob der AVR auch über die
USB-Schnittstelle richtig sendet und ob überhaut was am PC ankommt.
Joe
Joe G. schrieb:> Als ASM Options im AVR Studio:>> -DF_CPU=20000000 -DBAUD=115200 -Datmega328P -DDRAM_8BIT
************
Nimmst Du schon länger 115200? Ohne Probleme? Vielleicht sollte ich das
auch mal umstellen. Ich glaube, über 57600 habe ich nie richtig
getestet.
Hannes schrieb:> # AVR Binärfile:> # Aktuelle Version von hier laden> # http://cloudbase.homelinux.net/viewvc/avr-cpm/avrc...> # übersetzen und auf den AVR bringen.>> AVR Trunk herunter geladen und versucht zu übersetzen...
Bitte nicht irgendwas aus Trunk, sondern:
http://cloudbase.homelinux.net/viewvc/avr-cpm/avrcpm/tags/3.0/
Bitte auf den Link klicken, oder, wenn sich Kopieren nicht vermeiden
läßt, darauf achten, daß der gesamte Link kopiert wird. Hier ist der
vollständige Link:
Leo C. schrieb:> Nimmst Du schon länger 115200? Ohne Probleme?
Ja, schon seit der ersten Version. 57600 machen bei mir Probleme mit dem
TP Editor. Der verschluckt bei schneller :-) Programmierung oder beim
Editieren sonst schon mal ein Zeichen. 115200 hat noch nie Probleme
bereitet.
Im trunk gibts jetzt eine Uhr.
Im Anhang ist der passende ZSDOS-Treiber, den ich noch nicht eingecheckt
habe.
Nach einem Reset wird die Uhr z.Zt. mit Tag und Monat 0 initialisiert.
Dies dürfte zu verschmerzen sein, da sie ja ohnehin gestellt werden muß.
Das ganze ist vorläufig. U.a. deshalb, weil ich die BCD/binär- und
zurück-Wandlung noch vom Z80- in den AVR-Teil verlegen will. Außerdem
behandelt sie 2100 noch irtümlicherweise als Schaltjahr.
@ Leo C.
SUPER Leo!
D>ldtim
ZSDOS Time Stamp Loader, Ver 1.1
Copyright (C) 1988 by H.F.Bower / C.W.Cotrill
hallo welt ...loaded at D8D8H
Clock is : AVRCPM Clock 0.1
D>td
- 00, 2000 00:02:45
D>td 4/28/12 10:12:28
Press any key to set time
Apr 28, 2012 10:12:28
D>td
Apr 28, 2012 10:12:31
D>
Die Datei svnrev.inc fehlt noch im trunc.
bios.asm und ipl.asm würde ich langsam entsorgen, führt nur zu
Verwirrungen.
Wollen wir wirklich cpm6X.sys einführen? Ich fand die Trennung von CCP
und BDOS recht transparent.
Joe G. schrieb:> Die Datei svnrev.inc fehlt noch im trunc.
Hier gibts das Tool, das die Datei erzeugt.
http://www.compuphase.com/svnrev.htm
Ich weiß noch nicht, ob ich das Ganze so lassen soll.
> bios.asm und ipl.asm würde ich langsam entsorgen, führt nur zu> Verwirrungen.
Ja.
> Wollen wir wirklich cpm6X.sys einführen?
Nein. Das war/ist nur ein Ergebnis meiner Experimente mit movcpm. Da
steckt auch noch viel Arbeit drin, weil die Distri, die Sprite_tm als
Grundlage genommen hat, kein movcpm enthält, und die Seriennummern
angeglichen werden mußten.
> Ich fand die Trennung von CCP und BDOS recht transparent.
Ja, in diese Richtung sollte es gehen. Ich würde "unser" CP/M gerne
durch ein wirklich vollständiges ersetzen. ZSDOS dann als Alternative in
einem weiteren Zweig.
Außerdem sollte irgendwann noch ein Buildscript kommen, das eine Release
als Zip-Paket für Endanwender erzeugt. Das Paket sollte dann ein
fertiges CP/M-Image enthalten, und keine Abhängigkeiten von SVN.
Leo C. schrieb:> Außerdem sollte irgendwann noch ein Buildscript kommen, das eine Release> als Zip-Paket für Endanwender erzeugt.
Hier ein kleines Script welches eine bootfähige cpm.bin Datei aus BIOS,
CCP, BDOS und IPL erzeugt. Es kann vollständig in AltairSIMH gestartet
werden und schreibt das File auch gleich wieder zurück. dd entfällt
damit. Die Version ist derzeit nur für ZSDOS könnte aber sicher leicht
für die Altair cp/m Version angepaßt werden.
Joe
Hallo Joe,
irgendwie klappt bei mir nichts,hab mal meine fuses mit angehängt
Kannst du mir sonst mal ein Hexfile machen (20Mhz Quarz 38400Baud)?
Gruß
Hannes
@Hannes
sieht eigentlich ok aus. Hier das HEX File
@alle
Ich glaube in unsrer Berechnung der Speichergröße ist noch eine Altlast
sprite_tm eingebaut. Derzeit wird der CCP Start im BIOS über
msize equ 62 ;size of available RAM in k
bias equ (msize-20) * 1024
ccp equ 3400h+bias ;base of cpm ccp
bdos equ ccp+806h ;base of bdos
bios equ ccp+1600h ;base of bios
berechnet. Der Summand -20 bei der Biasberechnung steht auch so im CP/M
Operating System Manual worauf sich sprite_tm ja bezieht. Doch
tatsächlich ist unser System nicht 20K sondern 22K groß. Das kann
schnell nachgerechnet werden.
3400h Sysgen + 800h CCP + E00h BDOS + D00h Bios = 22k
User CCP fängt auch bei DC00h an. Hätten wir ein 62k System, so würde es
bei D400h (62K – 9K) beginnen müssen. Im Bios müsste also msize auf 64
und im bias (msize-22) * 1024 geändert werden. Mit dieser Korrektur
könnte dann auch eine gemeinsame Speicherconfig für BIOS, CCP, und BDOS
verwendet werden.
Lag ich völlig daneben oder ist es nur noch keinem aufgefallen?
Joe
Hallo Joe,
Danke für die schnelle Hilfe... leider auch ohne Erfolg....mit dem
Mega168 läuft alles....mit dem Mega328P geht nichts.....
muss da noch Hardware angepasst werden?? Speicher hab ich
2 mal NEC D424256C-80...
Was kann ich noch tun??
Gruß
Hannes
Hannes schrieb:> Was kann ich noch tun??
Versuche mal statt des externen Quarzes von 20 MHz erst den internen
Takt von 8 MHz zu nehmen. Der Mega328P läuft in unserer Anwendung etwas
außerhalb seiner Spezifikation (3.3V mit 20 MHz). Wenn er mit 8 MHz
läuft, hast du den Fehler. Ich habe hier auch einen liegen, welcher nur
bis 16 MHz geht.
Joe
laut Datenblatt:
• Speed Grade:
– 0 - 4MHz@1.8 - 5.5V, 0 - 10MHz@2.7 - 5.5.V, 0 - 20MHz @ 4.5 - 5.5V
Ich hab mal das BIOS etwas nach der obigen Variante geändert. Die
Speichergröße wird in dieser Variante nur noch in der MEMCFG.LIB
angegeben. Damit kann nun eine beliebige (in den Grenzen des CP/M)
Speicherkonfiguration übersetzt werden. Anbei ein Bsp. mit 53K Speicher.
CPM on an AVR, v3.1 r180
Testing RAM: fill...wait...reread...
Initing mmc...
A:FAT16 File-Image at: 8450, size: 018KB.
B:FAT16 File-Image at: 8959, size: 256KB.
C:FAT16 File-Image at: 8703, size: 256KB.
Partinit done.
Ok, Z80-CPU is live!
ipl
53k cp/m vers 2.2
A>dir
A: CPMSTAT COM
A>cpmstat
- Logged - ---- Records ---- - Tracks - --- Capacity --- --- TPA
---
Drive User Block Track Drive Sys. Drive Directory Drive Bytes
K
A: 0 8 26 1944 2 77 64/ 64 243K 46854
45.76
- Operating System -
Version BDOS BIOS
CP/M 2.2 B806 C600
A>
Joe G. schrieb:> Ich glaube in unsrer Berechnung der Speichergröße ist noch eine Altlast> sprite_tm eingebaut. Derzeit wird der CCP Start im BIOS über>> msize equ 62 ;size of available RAM in k> bias equ (msize-20) * 1024> ccp equ 3400h+bias ;base of cpm ccp> bdos equ ccp+806h ;base of bdos> bios equ ccp+1600h ;base of bios
Sprite_tm ist daran eher unschuldig, glaube ich. Das war ein
Mißverständnis meinerseits. Ich hatte msize vom altairz80 Emulator
übernommen. Dort steht msize aber für die tatsächliche RAM-Größe und
nicht für die "CP/M-Größe", für die ich es dann genommen habe.
> berechnet. Der Summand -20 bei der Biasberechnung steht auch so im CP/M> Operating System Manual worauf sich sprite_tm ja bezieht. Doch> tatsächlich ist unser System nicht 20K sondern 22K groß. Das kann> schnell nachgerechnet werden.
Das CP/M Handbuch definiert ein 20K System, bei dem der CCP auf 3400H
liegt. Unser System ist demgegenüber um b=A800H verschoben, und damit
per Definition ein 62K System.
http://www.cpm.z80.de/manuals/archive/cpm22htm/ch6.htm#Section_6.2> 3400h Sysgen + 800h CCP + E00h BDOS + D00h Bios = 22k> User CCP fängt auch bei DC00h an. Hätten wir ein 62k System, so würde es> bei D400h (62K – 9K) beginnen müssen. Im Bios müsste also msize auf 64> und im bias (msize-22) * 1024 geändert werden. Mit dieser Korrektur> könnte dann auch eine gemeinsame Speicherconfig für BIOS, CCP, und BDOS> verwendet werden.
Die 22 ist im CP/M-Handbuch nicht definiert. Hätten wir ein 64K System,
würde unser BIOS auf F400H beginnen (CCP bei E400H).
> Lag ich völlig daneben oder ist es nur noch keinem aufgefallen?
Mir ists am letzten Freitag aufgefallen. Da hatte ich in den von Dir
verwendeten ZRDOS-Sourcecode geschaut und msize (wieder-) entdeckt.
Joe G. schrieb:> Ich hab mal das BIOS etwas nach der obigen Variante geändert. Die> Speichergröße wird in dieser Variante nur noch in der MEMCFG.LIB> angegeben. Damit kann nun eine beliebige (in den Grenzen des CP/M)> Speicherkonfiguration übersetzt werden. Anbei ein Bsp. mit 53K Speicher.
1
bias equ (msize-22) * 1024
2
ccp equ 3400h+bias ;base of cpm ccp
3
bdos equ ccp+806h ;base of bdos
4
bios equ ccp+1600h ;base of bios
Nix dagegen. Da wir von allen Systemteilen den Sourcecode haben, und
damit auch alles auf beliebige Adressen linken können, brauchen wir
diese Offset-Berechnung sowiso nicht mehr.
Leo C. schrieb:> Da hatte ich in den von Dir> verwendeten ZRDOS-Sourcecode geschaut und msize (wieder-) entdeckt.
Dann mache ich wieder eine -20 und damit ein 62k System daraus und
ändere es im ZRDOS-Code.
Oh sehe gerade Doppelpost - welche Variante nehmen wir?
Joe G. schrieb:> Dann mache ich wieder eine -20 und damit ein 62k System daraus und> ändere es im ZRDOS-Code.
Der Original-ZRDOS-Code braucht das eigentlich garnicht. (REL-File,
Adresse wird erst beim Linken festgelegt.) Quelle hier:
http://www.gaby.de/ftp/pub/cpm/znode51/specials/zsdossrc/zsdos.htm> Oh sehe gerade Doppelpost - welche Variante nehmen wir?
Im letzten Posting habe ich mir wohl mehrfach selber widersprochen.
Was wir nicht (mehr) brauchen, ist das "20K CP/M System" als Referenz.
Die Länge von CCP und BDOS könnte man auch anders bestimmen (Linker).
Das ist aber unnötig aufwendig, weil die seit CP/M 2.0 immer gleich
geblieben sind. Aus historischen Gründen bin ich dafür, ein CP/M-System,
dessen BIOS bei F200H beginnt, weiterhin als 62K-System zu bezeichnen.
Eine Definition für die RAM-Größe brauchen wir eigentlich nicht, da sich
an unseren 64K voraussichtlich nichts ändern wird. Deine Frage habe ich
jetzt immer noch nicht beantwortet. ;)
Vielleicht sollten wir die 3 Dateien MEMCFG.LIB, CFGACPM.LIB, AVRCPM.LIB
zu einer einzigen zusammen fassen? Oder AVRCPM.LIB doch getrennt lassen,
da sie keine harwareabhängingen Teile hat, und wirklich nur fürs BIOS
gebraucht wird?
Klingt sinnvoll.
Ein System mit BIOS ab F200H bezeichnen wir mit 62K und MEMCFG.LIB
CFGACPM.LIB fassen wir zu einer Datei zusammen. AVRCPM.LIB würde ich
auch extra stehen lassen, da sie ja nur fürs BIOS zuständig ist.
Joe G. schrieb:> Hannes schrieb:>> Was kann ich noch tun??>> Versuche mal statt des externen Quarzes von 20 MHz erst den internen> Takt von 8 MHz zu nehmen. Der Mega328P läuft in unserer Anwendung etwas> außerhalb seiner Spezifikation (3.3V mit 20 MHz). Wenn er mit 8 MHz> läuft, hast du den Fehler. Ich habe hier auch einen liegen, welcher nur> bis 16 MHz geht.> Joe>> laut Datenblatt:> • Speed Grade:> – 0 - 4MHz@1.8 - 5.5V, 0 - 10MHz@2.7 - 5.5.V, 0 - 20MHz @ 4.5 - 5.5V
Hallo zusammen,
beim durchsehen des Datenblatts zum ATmega328(P) ist mir ein
vermeintlicher Unterschied zwischen den 168er / 328er mit und ohne P im
Namen aufgefallen:
Ausschnitt aus dem Datenblatt:
http://www.alldatasheet.com/datasheet-pdf/pdf/444347/ATMEL/ATMEGA328.html
BRANCH INSTRUCTIONS
RJMP k Relative Jump PC ? PC + k + 1 None 2
IJMP Indirect Jump to (Z) PC ? Z None 2
JMP(1) k Direct Jump PC ? k None 3
RCALL k Relative Subroutine Call PC ? PC + k + 1 None 3
ICALL Indirect Call to (Z) PC ? Z None 3
CALL(1) k Direct Subroutine Call PC ? k None 4
Note: 1. These instructions are only available in ATmega168PA and
ATmega328P.
Heißt das, dass dem 168er / 328er ohne P im Namen (=ältere Versionen)
die absoluten Sprung-Befehle: JMP und CALL fehlen?
Falls ja, ist für mich nun klar, dass ich mir 328er mit P bestellen
werde um endlich in den Genuss des Z80 Emulators zu kommen!
Hintergrund meiner Frage:
Ich habe es schon mehrmals geschafft, das ich im Code vorhandene RCALL's
durch CALL's ersetzen musste, weil die Adressräume der relativen
Sprungbefehle nicht mehr ausgereicht haben!
Viele Grüße
Markus
Markus G. schrieb:> Heißt das, dass dem 168er / 328er ohne P im Namen (=ältere Versionen)> die absoluten Sprung-Befehle: JMP und CALL fehlen?
Nein, P steht für picoPower und damit für folgende technische Daten:
- True 1,8V supply Voltage
- Minimized leakage current
- Sleeping BOD
- ultra low power 32 kHz Crystal Oscillator
- Digital Input Disable Registers
- Power Reduction Register
- Clock Gating
- Flash Sampling
- Power Down Mode 0,1µA@1,8V
- Power Save Mode 0,6µA@1,8V
Die von dir zitierte Anmerkung 1 steht schon som im Datenblatt vom
ATmega168.
Hast du mal die 8 MHz Variante ausprobiert?
Joe
Markus G. schrieb:> Note: 1. These instructions are only available in ATmega168PA and> ATmega328P.
Das ist zur Abgrenzung zu den kleineren Prozessoren ATmega48 und -88.
Diese brauchen die langen Sprungbefehle nicht, da sie mit RCALL/RJMP den
gesamten Speicher erreichen können.
Hallo zusammmen!
Ich habe von Joerg die Hardware V4 als Eagle Datei bekommen.
Mir ist aufgefallen, das Pin 22 (CE) und Pin 24 (OE) des AS6C4008
jeweils /OE gemeinsam am ATMEGA 644P - Pin 3 anliegen ...
Bitte eine kleine Erklärung ob das ein Fehler ist oder gewollt.
Stefan
Hallo,
habe mir auch mal 2 Varianten aufgebaut und dafür auch ein anderes
Platinenlayout erstellt zum selber ätzen bzw. fräsen. Ich verwende nur
SMD Bauteile und DRAMs von alten SIMM bzw. PS2 Modulen. Das Layout kann
ich bei Interesse hier rein stellen.
Ich habe mitten im Thread davon gelesen, dass es wohl ZSDOS Images gibt.
Kann das jemand zur verfügung stellen?
Danke :)
VG
Franz
@Franz
Noch ein Aufbau, sehr schön! Welchen DRAM verwendest Du?
Anbei zwei ZSDOS Images.
CPMDSK_A.IMG ist ein bootfähiges Image mit einem Uhrentreiber von Leo C.
CPMDSK_D.IMG beinhaltet das komplette System im Altair HD Format. Hier
sind auch die Quellen für das System enthalten. Du kannst das System
selbst mit AVRCPM.SUP erzeugen (braucht bei 20 MHz ca. 30 Sekunden).
Source.zip enthät die Quellen für das BIOS, CCP und IPL
Gruß Joe
Nachtrag:
Ich hatte mich gewaltig mit der Zeit verschätzt. Um das System
vollständig auf unserem System zu übersetzten, d.h. Assembler, Linker,
DDT usw. benötigt man ca. 5 Min und 20 Sekunden. Unter Altair natürlich
nur wenige Sekunden.
Gruß Joe
Weil ich selber keine mehr hatte und man immer einige Platinen bei
pcbcart abnehmen muss um vernünftige Preise zu erhalten kann ich jetzt
hier anbieten:
Platinen und mehr zum Projekt: AVR CP/M USB Stick
Info's: http://avr.cwsurf.de/?AVR_CP%2FM
Ein komplettes CP/M System! Disk Images auf SD Karte. Nur 3 IC's DIL.
Diesmal: Blaue Platinen.
Preise:
Nur Platine: 8€
SD Slot: 4€ (ein paar habe ich noch, sonst muss ich erst aus USA
bestellen)
AVR progr.: 5€ (ATmega328P)
4bit x 256 Drams: 5€ (2 Stück) - nur solange Vorrat reicht.
Peter
Hallo Peter,
von der "blauen Ausgabe" hätte ich gerne ein Exemplar, inclusive der 3
ICs und des SD-Slots. Meine Adresse müsstest Du noch haben.
Gruß Siggi
@siggi & Hans-Werner: Adressen speicherere ich nicht.. (Datenschutz)
bitte sendet mir doch eine Mail über das Forum hier.. dann wird das
einfacher..
Ich bin vom 18-26.10 im Urlaub.. also nicht wundern, wenn es etwas
dauert..
---
Gerade nochmals SCDA6A0101 bei CSD bestellt.. Nun habe ich wieder genug
Slots für alle Platine.. habe trotzdem auch mal einen Ersatz-Slot
'drangefriemelt'.. geht auch..
Peter
Hier mal ein paar neue Diskimages und viele Fragen ;-)
CPMDSK_G.IMG = Fortran Compiler
CPMDSK_H.IMG = PL/I Compiler
Pl/I läuft komplett mit z.B FIB.PLI:
PLI FIB
LINK FIB
FIB
Fortran ist ein hello.for dabei, aber der Compiler beschwert sich..?
(Leider ist das editieren von Files unter CP/M auch nicht so einfach..
hat da
jemand ein gut funktionierendes VDE.COM / ZDE.COM?)
Ein paar Fortran Beispielprogramme, die sich hiermit compilieren lassen
wäre schön..
---
Frage 1:
Ich bin mit TP3 inzwischen bei CPMDSK_I.IMG angekommen. Images werden
aber nur bis _H gelesen. Muss ich um z.B 2 weitere einlesen zu lassen
die Konstanten MAXDISKS von 8 auf 10 erhöhen in dsk_fsys.asm:
; Fields in the parttabl
.equ MAXDISKS = 8 ;Max number of Disks (partitions)
???
Und muss woanders noch was geändert werden?
---
Frage 2:
Ich habe versucht ein neues 8MB Diskimage zu erstellen:
del CPMDSK_G.IM_
del CPMDSK_G.IMG
mkfs.cpm.exe -f myz80 -b cpm.bin -L test CPMDSK_G.IM_
rem FORTRAN
cpmcp -f myz80 CPMDSK_G.IM_ cpmdsk/FORTRAN/F80.COM 0:F80.COM
cpmcp -f myz80 CPMDSK_G.IM_ cpmdsk/FORTRAN/HELLO.FOR 0:HELLO.FOR
rem ...
rem make at least 8192k in size
dd if=CPMDSK_G.IM_ of=CPMDSK_G.IMG ibs=8388608 conv=sync
Es werden aber keine Files mit DIR anschließend angezeigt..?
(Ich vermute mein cpm.bin ist nicht passend dafür..?)
???
---
Peter
Peter Sieg schrieb:> Frage 1:> Ich bin mit TP3 inzwischen bei CPMDSK_I.IMG angekommen. Images werden> aber nur bis _H gelesen. Muss ich um z.B 2 weitere einlesen zu lassen> die Konstanten MAXDISKS von 8 auf 10 erhöhen in dsk_fsys.asm:>> ; Fields in the parttabl>> .equ MAXDISKS = 8 ;Max number of Disks (partitions)>> ???> Und muss woanders noch was geändert werden?
Images und Partitonen sind 2 verschiedene Dinge.
Peter Sieg schrieb:> (Ich vermute mein cpm.bin ist nicht passend dafür..?)
Peter, die Einstellungen für die Diskettenformate bzw. HD stehen in der
AVRCPM.LIB
Habe nun mit folgenden Änderungen:
; Fields in the parttabl
.equ MAXDISKS = 10 ;Max number of Disks (partitions); was 8
.equ PARTENTRY_SIZE = 11 ;Size of a Partitiontableentry; was 9
einen erfolgreichen Scan des LW: I:
CPM on an AVR, v2.3 r185
Testing RAM: fill...wait...reread...
Initing mmc...
A:FAT16 File-Image at: 514, size: 256KB.
B:FAT16 File-Image at: 530, size: 256KB.
C:FAT16 File-Image at: 546, size: 256KB.
D:FAT16 File-Image at: 562, size: 256KB.
E:FAT16 File-Image at: 578, size: 256KB.
F:FAT16 File-Image at: 594, size: 256KB.
G:FAT16 File-Image at: 610, size: 256KB.
H:FAT16 File-Image at: 626, size: 256KB.
I:FAT16 File-Image at: 002, size: 8192KB.
Partinit done.
Ok, Z80-CPU is live!
ipl
62k cp/m vers 2.2
A>
aber DIR I: zeigt NO FILES ??
---
Habe dann mal TP3 auf F gelegt und ALGOL auf J und B auf I kopiert:
A>dir f:
F: READ ME : TINST COM : TINST DTA : TINST MSG
F: TURBO COM : TURBO MSG : TURBO OVR : CMDLIN PAS
F: LISTER PAS : MC-MOD00 INC : MC-MOD01 INC : MC-MOD02 INC
F: MC-MOD03 INC : MC-MOD04 INC : MC-MOD05 INC : MC HLP
F: MC PAS : MCDEMO MCS : MC COM : MC-MOD03 COM
F: HELLO PAS
A>dir h:
H: FIB PLI : CHESS PLI : LIB COM : LINK COM
H: RMAC COM : PLI0 OVL : PLI1 OVL : PLI2 OVL
H: PLI COM : TEST PLI : PLILIB IRL : OPTIMIST PLI
H: OPTIMIST COM : PLIDIO ASM : MATSIZ LIB : MATSIZE LIB
A>dir i:
I: TTT2 COM : SARGON COM : OTHELLO COM : MMIND COM
I: ED COM : LOAD COM : STONE COM : PIP COM
I: STAT COM : SUBMIT COM : XSUB COM : LADDER COM
I: LADDER DAT : LADCONF COM : CURON COM : PACMAN COM
I: HITCH COM : HITCHHIK DAT : :
I: : : :
I: :
A>dir j:
J: : : :
J: :
A>
???
---
I: und J: werden auch mit dem freien Platz nicht korrekt angezeigt:
A>stat
A: R/W, Space: 40k
B: R/W, Space: 0k
C: R/W, Space: 129k
D: R/W, Space: 95k
E: R/W, Space: 48k
F: R/W, Space: 7928k
G: R/W, Space: 121k
H: R/W, Space: 13k
I: R/W, Space: 938k
J: R/W, Space: 952k
---
Ach Ja.. ALGOL macht bei LUNAR auch irgendwie Mist.. BCD Problem?
Peter
@Peter
Nachtrag: im BIOS.MAC mußt du natürlich auch das HD-Format eintragen,
oder du nimmst dieses CPM.BIN
@ Leo C.
Läuft Dein Server http://cloudbase.homelinux.net/... noch?
Peter Sieg schrieb:>> Peter, die Einstellungen für die Diskettenformate bzw. HD stehen in der>> AVRCPM.LIB>> ???>> Diese Datei habe/finde ich nicht??
Klar habe ich die/gefunden ;-)
Sorry.. gehört zum BIOS.
@Joe G: Kannst du deine *.MAC, AVRCPM.LIB und das damit erstellte
CPM.BIN mal als ZIP hier anhängen..?
BTW: Mikrocontroller Forum hat glaube ich inzwischen auch einen SVN
Server..
Peter
Peter Sieg schrieb:> @Joe G: Kannst du deine *.MAC, AVRCPM.LIB und das damit erstellte> CPM.BIN mal als ZIP hier anhängen..?
Die hast du nun sicherlich gefunden.
Übrigens, das 8MB HD-Format hat einen anderen Aufbau. Das mußt du in den
"diskdefs" berücksichtigen.
Hier die diskdefs für die CP/M Tools oder den Totalcommander.
# SIMH AltairZ80 Harddisk
diskdef simhd
seclen 128
tracks 2048
sectrk 32
blocksize 4096
maxdir 1024
skew 0
boottrk 6
os 2.2
end
Hi. Die diskdefs hatte ich schon angepasst..
Ich habe jetzt mal dein cpm.bin verwendet. Immer LW: I: bekomme ich
keine/vernünftige DIR Anzeige. Hatte dort erstmal das 8192k TP3 Image..
= NO FILES. Habe dieses dann als F: kopiert und unter I: eine Kopie von
A:
A>dir
A: ASM COM : DDT COM : DUMP COM : ED COM
A: T COM : TLOOP COM : LOAD COM : MBASIC COM
A: 23 BAS : BAGELS BAS : CHECKERS BAS : STARTREK BAS
A: TREKINST BAS : MASTRMND BAS : WEEKDAY BAS : PIP COM
A: STAT COM : SUBMIT COM : XSUB COM : ZORK1 COM
A: ZORK1 DAT : SURVEY COM
A>dir f:
F: READ ME : TINST COM : TINST DTA : TINST MSG
F: TURBO COM : TURBO MSG : TURBO OVR : CMDLIN PAS
F: LISTER PAS : MC-MOD00 INC : MC-MOD01 INC : MC-MOD02 INC
F: MC-MOD03 INC : MC-MOD04 INC : MC-MOD05 INC : MC HLP
F: MC PAS : MCDEMO MCS : MC COM : MC-MOD03 COM
F: HELLO PAS
A>dir i:
I: : :
A>dir j:
J: ASM COM : DDT COM : DUMP COM : ED COM
J: T COM : TLOOP COM : LOAD COM : MBASIC COM
J: 23 BAS : BAGELS BAS : CHECKERS BAS : STARTREK BAS
J: TREKINST BAS : MASTRMND BAS : WEEKDAY BAS : PIP COM
J: STAT COM : SUBMIT COM : XSUB COM : ZORK1 COM
J: ZORK1 DAT : SURVEY COM
A>
wieder bei I: keine Anzeige.. bei F: aber wird das 8192k TP3 Image
sauber gelistet.
Hmm..?? zumindest werden mal LW: A-J gescannt und angezeigt..
A>stat
A: R/W, Space: 41k
B: R/W, Space: 0k
C: R/W, Space: 131k
D: R/W, Space: 97k
E: R/W, Space: 49k
F: R/W, Space: 7928k
G: R/W, Space: 123k
H: R/W, Space: 13k
I: R/W, Space: 103k
J: R/W, Space: 41k
---
Habe noch Hitech-C und PARASOL in der Mache als neue Diskimages..
Peter
Bez. CPM.BIN:
Ich verwende Batch Dateien unter Windows - 1:
aliados m80.com =bios.mac
aliados l80.com bios.rel,bios.bin/n/e
aliados m80.com =ipl.mac
aliados l80.com ipl.rel,ipl.bin/n/e
und 2:
dd conv=sync bs=128 count=1 if=ipl.bin > cpm.bin
dd conv=sync bs=128 count=44 if=CPM.SYS >> cpm.bin
dd conv=sync bs=128 count=7 if=bios.bin >> cpm.bin
Kann ich das genau so auch mit den neueren Dateien in Source.zip machen?
Peter
Peter Sieg schrieb:> Kann ich das genau so auch mit den neueren Dateien in Source.zip machen?
Nein.
Da das System nun aus IPL CCP BDOS und BIOS zusammengesetzt ist, mußt du
die folgende Zusammensetzung wählen.
dd conv=sync bs=128 count=1 if=ipl.bin > cpm.bin
dd conv=sync bs=128 count=16 if=ZSCCP.BIN >> cpm.bin
dd conv=sync bs=128 count=28 if=ZSDOS.BIN >> cpm.bin
dd conv=sync bs=128 count=6 if=bios.bin >> cpm.bin
Joe
sorry, hab' gerade keine Zeit zum mittmischen.
Joe G. schrieb:> @ Leo C.> Läuft Dein Server http://cloudbase.homelinux.net/... noch?
Letzte Nacht ist mir aufgefallen, daß das Ding hängt. Nach einem
Neustart lief wieder alles. Und jetzt schon wieder nicht mehr. :-(
Peter Sieg schrieb:> make_bios.bat gibt aber jede Menge Fehler:
Ich benutze den Assembler, Linker usw. unter Altair SIMH. Da laufen die
Quellen fehlerfrei. Wenn du unter CP/M arbeitest, dann kannst du das dd
unter Windows gleich einsparen und alles zusammen unter CP/M binden
(AVRCPM.SUB)
Joe
Leo C. schrieb:> Für den Server brauche ich mal ne ruhige halbe Stunde. Heute aber leider> nicht mehr.
kein Problem...
Andere Baustelle: Ist den der PCF8583T für die Echzeituhr noch aktuell?
Ich würde gerne das Layout fertigstellen.
Yo. Rom wurde ja auch nicht an einem Tag erbaut..
Hmm.. das ZSDOS nicht unter aliados assemblierbar ist..?
Habe auch mal m80l80pc probiert. Da sind es 'nur' 97 Fehler:
C:\DATEN\Eagle\AVRCPM~1\KOPIEV~1>m80.com =zsdos.mac
V MACLIB ZSDOS.LIB ; Get
initialization code
e
V IF ZRL
V IF ZSDOS11
V IF ZS
Es fehlt anscheinend die ZSDOS.LIB und er kann das IF ... nicht ab..?
---
Nun, lasse es vorerst mal in diesen für mich unbefriedigenden Zustand:
Verwende das cpm.bin von Joe G. was ich selbst aber nicht erzeugen kann
mit den Windows Tools..
Ich kann mit den Änderungen am AVR Source nun bis LW: J arbeiten, wobei
I: nicht nutzbar ist..?
Werde es nochmal bis LW: L: erweitert und dann testen..
Falls das alles so nicht geht, werde ich wohl alles zurück bauen und
dann eben nur bis LW: H: gehen und ggf. eine 2te SD Karte für die
nächsten 8 LW: verwenden.
Peter
@Joe G.: Danke! Bringt aber keine Änderung: Scan nur bis J und DIR I: =
: : :
Da ist wohl noch ein wenig mehr im Argen.. zu tun..
Das 8192k Image mit Turbo Pascal 3 wurde aber ja auch vorher erkannt bei
Laufwerk F:
Peter
Ich habe jetzt erstmal alles zurück gebaut auf meine letzte Version,
wo ich das unter aliados assemblierte cpm.bin verwenden kann und auf
LW: A: - H:
Die Änderung auf mehr LW: - z.B bis L: müssen wir dann noch mal in Ruhe
in Angriff nehmen.. ich denke auch, das da einiges an ueberfluessiger
Code
in den Sourcen drin ist.. in fat16 z.B ist schon drin, das er A-Z
sucht..
Peter
@Joe G.: Evtl. kannst du ja das fertige AltairSIMH disk/hd-image hier
einhängen, womit sich cpm.bin komplett bilden läßt auf Basis ZSDOS..
Den AltairSIMH habe ich hier noch, aber nur ein cpm 2.2 diskimage auf a:
Peter
Kurze Anleitung dazu.
1. Altair.zip entpacken
2. AltairAll.bat starten
3. auf Laufwerk I: wechseln
4. mit "do avrcpm.sub" das Übersetzen und Linken starten
5. fettich Meister, im Verzeichnis von Altair steht die fertige CPM.BIN
schönen Abend
Joe
Was war eigentlich der Grund/Vorteil auf ZSDOS im CPM.BIN zu gehen..?
Weil es auch im Source vorliegt?
Mit der Erzeugung aus einer Emulation heraus kann ich leben ;-)
---
Meine Wünsche für Weihnachten ;-)
* mehr Diskimages mit lauffähigen, getesteten Applikationen
* Unterstützung von mehr Diskimages als bisher 8 (A-H).
* Evtl. einen Weg Dateien zw. laufendem CP/M und Hostsystem
auszutauschen (Kermit?)
Gruß Peter
@Leo C.
Ja, der hat RV2123-C2 ist auch nicht schlecht. Er hat schon den Quarz
integriert.
@Peter
ZSDOS hat bei voller Kompatibilität zu CP/M 2.2 einige wesentliche
Verbesserungen. Näheres hier:
http://susowa.homeftp.net/index.php/software-mainmenu/cpm-mainmenu-116/95-zsdos-zddos.html
@alle
Es gibt einen Entwurf mit RTC (PCF8583T) und einem 8-Bit Port (PCF
8574). Außerdem gibt es einen Erweiterungsport mit I2C und 2 x ADC. Die
Stromversorgung ist über den USB-Port realisiert, über den wahlweise das
VT100 Terminal angeschlossen werden kann oder der Propeller (VGA mit
VT100 Terminal) programmiert werden kann. Weiterhin gibt es einen PS2
Anschluss für die Tastatur. Die Platine passt in ein Fischer Alu-Gehäuse
(AKG 7124
ME)beziehen u.a. bei Reichelt.
Da bisher kein großes Interesse vorhanden war, habe ich den Aufbau noch
nicht in Angriff genommen. Doch jetzt scheint wieder Leben in das
Projekt zu kommen. Welche Wünsche gibt es denn noch?
Peter Sieg schrieb:> Was war eigentlich der Grund/Vorteil auf ZSDOS im CPM.BIN zu gehen..?
Wenn Du nach Lesen der "feature list" [1] von ZSDOS für Dich keine
Vorteile erkennen kannst, spricht natürlich nichts dagegen, bei
Original-CP/M zu bleiben.
> Weil es auch im Source vorliegt?
Source gibts auch für das Original.
> Meine Wünsche für Weihnachten ;-)>> * mehr Diskimages mit lauffähigen, getesteten Applikationen> * Unterstützung von mehr Diskimages als bisher 8 (A-H).
Wenn die Images (Laufwerke) nur ein paar hundert KByte groß wären, und
einzeln/unabhängig voneinander auswechselbar wären, würde ich das ja
vielleicht auch so sehen.
Aber: Auf ein Diskimage mit 8 Megabyte passen sehr viele
CP/M-Programme/-Pakete.
Kann es sein, daß Du die Images in etwa wie Archivdateien betrachtest,
statt wie (Festplatten-)Laufwerke?
Zugegebenermaßen wirds wg. der flachen Dir-Struktur unter CP/M leider
schnell unübersichtlich, und die User-Bereiche (0..31) werden auch
schlecht unterstützt. Ich meine aber, verschiedene Anwendungen auf einem
Laufwerk in getrennten User-Bereichen zu verwalten, ist immer noch
einfacher, als die Images auf der SD-Karte neu zu mischen.
Mit ZSDOS gibts übrigens bessere Unterstützung der User-Bereiche (z.B.
Pfad-Aliase für User-Nrs).
> * Evtl. einen Weg Dateien zw. laufendem CP/M und Hostsystem> auszutauschen (Kermit?)
CP/Net? ;)
Mit X/Y/Z-Modem-Protokoll müßte das eigentlich auch über die
Host-Schnittstelle gehen. Leider habe ich noch kein Programm gefunden,
das das unterstützt.
[1] Geheimtip: Doku
1
1.5 Differences Between CP/M 2.2, ZRDOS and ZSDOS.
2
3
Compatibility with existing applications was one of the primary goals of
4
ZSDOS. Most programs that run under CP/M 2.2 or ZRDOS 1.x should also run
5
under ZSDOS without any problems. The few programs that won't run under ZSDOS
6
depend on specific (unpublished) addresses in BDOS.
7
8
A quick summary of the features of ZSDOS compared to ZRDOS and CP/M 2.2 is
Peter Sieg schrieb:> Die Änderung auf mehr LW: - z.B bis L: müssen wir dann noch mal in Ruhe> in Angriff nehmen..
Die Nummer der RAM-Disk steht auch in config.inc:
1
#define RAMDISKNR 'I'-'A' /* Drive "letter" for first RAM disk */
Um die Anzahl der möglichen SD-Karten-Disks zu erhöhen muß man diese
Konstante vergrößern.
> ich denke auch, das da einiges an ueberfluessiger Code> in den Sourcen drin ist.. in fat16 z.B ist schon drin, das er A-Z> sucht..
Ich muß doch sehr bitten. ;-)
Die Anzahl der Laufwerke ist aber auch durch das im BIOS dazu
reservierten RAMs begrenzt. Da die Verwaltung dynamisch erfolgt, können
um so mehr Laufwerke verwaltet werden, je kleiner diese sind.
Hallo,
das VT Terminal mit dem Propeller interessiert mich auch. Nun muss das
einer nur noch in den Atmel bringen... Interessant wäre allerdings wenn
man die I/O Ports auch über in und out Befehle von der Z80 Seite zu
erreichen sind.
Gruß
Hans-Werner
Hans- w. Schütz schrieb:> Interessant wäre allerdings wenn> man die I/O Ports auch über in und out Befehle von der Z80 Seite zu> erreichen sind.
Klar, das ist sowieso die einfachste Möglichkeit, die Ports für den Z80
zugänglich zu machen.
Leo C. schrieb:> Die Nummer der RAM-Disk steht auch in config.inc:#define RAMDISKNR 'I'-'A'
/* Drive "letter" for first RAM disk */
Das hatte ich parallel auch schon gemacht, obwohl die Anz. Ramdisks bei
mir auf 0 steht. Es kam aber zu den oben beschriebenen Effekten:
I: DIR => : : : sonst nichts.
J: geht mit ZSDOS, mit CPM.BIN orig. 2.2 nicht.
Erweiterung auf K+L: Anzeige / Scan nur bis J:
Ich verwende eigentlich immer noch die 256k Images, weil:
1. Ich noch nicht versucht habe unter Windows, größere Images (8192k) zu
erzeugen.
2. Wirklich die Übersicht verloren geht und ich eigentlich thematisch
getrennte Sachen auch getrennt halten wollte.
Aber mit den Userbereichen ist klar eine Möglichkeit, die ich bisher
noch
nicht genutzt habe.
Wie kann ich denn unter Windows ein 8192k Leerimage anlegen?
Kann jemand dazu ggf. die passende diskdefs hier einhängen.
---
@Joe G: Achtung der bisher verwendete SD Card Slot ist (fast) nicht mehr
lieferbar! CSD hat noch ca. 50Stk. SCDA6A0101 - die passen! Danach heißt
es umstellen auf einen anderen Slot.
Wenn auf deine Platine der Propeller Chip für das Terminal mit drauf
ist,
habe ich (andere sehen das sicher anders..) kein Interesse daran..
Aus meiner Sicht sollte das AVR Only sein.. eher kann der Propeller
nebenbei noch Z80 spielen..
Peter
Joe G. schrieb:> Das läuft bei mir schon ein Jahr. Genau diese Schaltung ist auf dem> neuen Layout.> Beitrag "Re: CP/M auf ATmega88"
Mach doch mal bitte ein paar Foto's/Video über Youtube davon..
Wenn es wirklich gut läuft und eine bessere Anzeigequalität hat als
MicroVGA kann man ja mal über seinen Schatten springen..
und so ein Weihnachtsprojekt hätte ja auch was.. ;-)
Peter
Peter Sieg schrieb:> CSD hat noch ca. 50Stk. SCDA6A0101 - die passen!
Danke für den Hinweis.
Die Terminalhardware sehe ich ganz pragmatisch. Sicher könnte es auch
ein AVR sein, doch mit dem Propeller geht es schnell, einfach und gut.
Die Videoqualität ist deutlich besser als bei der MicroVGA und das
Terminal kann nach den eigenen Bedürfnissen programmiert werden. Ich
mache bei Gelegenheit mal einige Fotos.
Joe
Peter Sieg schrieb:> Wie kann ich denn unter Windows ein 8192k Leerimage anlegen?> Kann jemand dazu ggf. die passende diskdefs hier einhängen.Beitrag "Re: CP/M auf ATmega88"
Danach mit cpmtools bespielen. Format 'myz80' bzw. 'simhd'.
1
# MYZ80 hard drive (only works with libdsk, because it has a 256-byte header)
Peter Sieg schrieb:> Wie kann ich denn unter Windows ein 8192k Leerimage anlegen?
Unter Altair SIMH ein HD Laufwerk erzeugen und in CPMDSK_X.IMG
umbenennen.
Joe G. schrieb:> Unter Altair SIMH ein HD Laufwerk erzeugen und in CPMDSK_X.IMG> umbenennen.
Ahh..?? Und wie geht nun sowas..?
BTW: Ich habe hier im Thread ein myz80.img 'gefunden' was 8193k groß
ist..?
Peter
Ich habe jetzt mal versucht ein simhd.img unter Windows zu erstellen:
makeimage /dev/null simhd.img 8388480
mkfs.cpm.exe -f simhd -b cpm.bin -L test simhd.img
Das Problem (idiotisch!) simhd ist bei mir nicht in diskdefs drin und
editieren unter Windows kann ich es nicht, weil dann wieder CR+LF
eingefügt werden und das dann wieder unter windows mit dem cpmtools
nicht mehr lesbar ist(so ein 'scheiß' mit den cpmtools).
Kann mir bitte jemand eine vollständige diskdefs für die cpmtools + TC
mit avrcpm, myz80 und simhd hier einhängen..
Danke+Gruß, Peter
Es gibt aber auch für Windows Editoren, die Unix-Zeilenenden können.
Und dann gibt es noch sowas wie dos2unix und unix2dos usw.
Der "Scheiß" sind natürlich die von Dir verwendeten Windows-Tools, nicht
etwa die cpmtools.
Ein guter Editor unter Windows ist WinVi
http://www.winvi.de/de/Peter Sieg schrieb:> Ahh..?? Und wie geht nun sowas..?
1. neu.dsk im altairSIMH als HD anlegen
d tracks[0-7] 254
attach dsk zsdos.dsk
;attach hdsk i.dsk
attach hdsk neu.dsk
set cpu 64k
set cpu itrap
set cpu z80
set cpu altairrom
set cpu nonbanked
reset cpu
boot dsk
2. HD mit Programmen füllen
3. SIMH beenden
4. neu.dsk in CPMDSK_X.IMG umbenennen (X) ist der Laufwerksbuchstabe
deiner HD
5. auf SD-Card kopieren
6. freu
anbei noch ein "freu"Immage
Joe
Das mit neu.dsk werde ich mal probieren..
Ich möchte aber eigentlich lieber über die cpmtools gehen..
(warum eigentlich..? -> kann mal alles schön in Batch-Dateien legen..)
Ich habe also ein myz80.img und ein simhd.img mit makedisk angelegt:
(Ist auch alles schön mit E5 gefüllt gewesen)
makeimage /dev/null simhd.img 8388480
mkfs.cpm.exe -f simhd -b cpm.bin -L test simhd.img
+
makeimage /dev/null myz80.img 8388736
mkfs.cpm.exe -f myz80 -b cpm.bin -L test myz80.img
---
dann mit ein paar Programmen gefüllt:
rem Wordstar
cpmcp -f simhd simhd.img cpmdsk/ws30-vt100/INSTALL.COM 0:INSTALL.COM
cpmcp -f simhd simhd.img cpmdsk/ws30-vt100/MAILMRGE.OVR 0:MAILMRGE.OVR
...
rem Multiplan
cpmcp -f simhd simhd.img cpmdsk/MULTPLAN/INSTALL.COM 1:INSTALL.COM
cpmcp -f simhd simhd.img cpmdsk/MULTPLAN/INSTALL.DAT 1:INSTALL.DAT
---
mit cpmls bekomme ich die auch angezeigt.
Auf SD Karte als CPMDSK_E.IMG kopiert.
LW: E wird gefunden mit 8192k aber DIR E: NO FILES
???
Bei beiden identisch.
Als CPMDSK_A.IMG wird auch CP/M gebootet.. aber NO FILES??
Was mache ich falsch?
Peter
Peter Sieg schrieb:> makeimage /dev/null simhd.img 8388480> mkfs.cpm.exe -f simhd -b cpm.bin -L test simhd.img
Versuch' mal das simhd Image (geringfügig) zu vergrößern mit:
simhd Images werden nur erkannt, wenn sie die exakt richtige Größe von
8388608 Bytes haben (2048 Traks * 32 Sectors/Track * 128 Byte/Sector),
weil es sonst nicht viele Erkennungskriterien für dieses Format gibt.
Image-Files, deren Dateinamen dem Muster 'CPMDSK_[A-Z].IMG' entsprechen,
werden in alphabetisch aufsteigender Reihenfolge als Laufwerke A: B: ...
eingebunden. Wenn 'CPMDSK_E.IMG' die erste erkannte Datei ist (und keine
CP/M-Partitionen vorhanden sind), bekommt sie den Laufwerksbuchstaben
'A'.
Ich habe es gerade selber nochmal versucht. Dabei gehe ich davon aus,
dass bei dir in simhd das korrekte Format eingetraegn ist.
1. mkfs.cpm.exe -f simhd -b cpm.bin -L test simhd.img
2. dd if=simhd.img of=i.dsk ibs=8388608 conv=sync
3. stat i:dsk:
I: Drive Characteristics
65344: 128 Byte Record Capacity
8168: Kilobyte Drive Capacity
1024: 32 Byte Directory Entries
0: Checked Directory Entries
256: Records/ Extent
32: Records/ Block
32: Sectors/ Track
6: Reserved Tracks
Ahh.. ich habe aber Schritte 1+2 in umgekehrter Reihenfolge gemacht!
Ich teste das also noch mal in deiner Reihenfolge.
Trotzdem bin ich mit den user Bereichen nicht wirklich 'glücklich'.
Nach vielen Operationen wird man autom. auf A: und user 0 'zurück
geworfen':
A>i:
I>user 6
I>dir
I: CREF80 COM : F80 COM : HELLO FOR : L80 COM
I: LIB80 COM : M80 COM : OBSLIB REL : FORLIB REL
I: README TXT : HELLO REL : HELLO COM
I>hello
HELLO, WORLD
STOP ** at address 0131 **
A>
Peter
Auch Interessant!
Auf dem Altair Emulator wird man auf A: wie obern geschildert zurück
gebeamt.. auf dem avrcpm NICHT:
A>e:
E>user 6
E>dir
E: CREF80 COM : F80 COM : HELLO FOR : L80 COM
E: LIB80 COM : M80 COM : OBSLIB REL : FORLIB REL
E: README TXT : HELLO REL : HELLO COM
E>hello
HELLO, WORLD
STOP ** at address 0131 **
E>dir
E: CREF80 COM : F80 COM : HELLO FOR : L80 COM
E: LIB80 COM : M80 COM : OBSLIB REL : FORLIB REL
E: README TXT : HELLO REL : HELLO COM
E>
???
Peter
Hmm. In den Images ist das über Altair i.dsk mit do avrcpm.sub erzeugte
CPM.BIN enthalten..
BTW: Von so einer 8M Disk kann ich nicht als LW A: booten.. =reg.dump 76
76 76..
Daher verwende ich z.B eine 256k LW A: disk image und dann jetzt jeweils
8M images als B: und C: (TP3).
Peter
Hier noch ein ZIP mit MuMATH Package (bisher nur im Altair Emu getestet)
und eine deutsche PDF Anleitung dazu.
From:http://www.retroarchive.org/cpm/misc/misc.htm
This package was originally issued for the OSBORNE 1.
The MUSIMP.COM file contains my patch to make it useable
under generic cp/m. The original osborne version of this
executable is enclosed as MUSIMP.OBJ
The CLES?.* files are a tutorial in using the calculation
parts of MUMATH. The PLES?.* comprise a programming tutorial
for MUSIMP.
rwd
06/09/98
---
Schnellstart
Zum Kennenlernen von Musimp:
Starte Musimp am CP/M prompt: MUSIMP ALL
Setze „PAUSE“ für die nachfolgende Demo durch folgende Eingabe am “?“
Prompt: PAUSE:100;
(Altair Emulator: PAUSE:1000;)
Starte die Demo durch folgende Eingabe am “?“ Prompt: RDS(DEMO,ALL);
Beende Musimp
Peter
Liebe Mit-Retro-Freaks.
Ich hatte mal Lust diesen gesamten Thread etwas aufbereitet als PDF zur
Verfügung zu stellen. PDF (272 Seiten; von ursprünglich >470 Seiten)
habe ich im Wiki abgelegt und im Artikel eingebunden:
http://www.mikrocontroller.net/articles/AVR_CP/M
Ist schon sehr interessant, wie sich das alles so entwickelt hat und wer
maßgeblich daran beteiligt war bzw. ist!
Ich habe mir erlaubt auch ein Inhaltsvereichnis anzulegen mit Highlights
der
Entwicklung etc.
---
Ich selbst werden mich demnächst nach Datenaustausch acrcpm <-> PC über
Terminalsoftware (X/Y/Z-Modem o.ä) umschauen.. ich möchte gerne Dateien
zw. avrcpm und Kostsystem einfach austauschen können.
---
Mit max. 8x 8MB Diskimages und der Möglichkeit Programmpakete in User
Bereiche zu strukturieren, haben wir wohl ersteinmal genügend Platz..
;-)
---
Je länger ich drüber nachgedacht habe, wäre eine Stand-Alone Lösung mit
eigenen VGA+Tastatur Teil (auf Basis Propeller) doch 'nicht
uninteressant'.
Wer hätte den daran noch interesse..?
---
Was gäbe es sonst noch für 'sinnvolle' Erweiterungsmöglichkeiten?
---
Peter
Peter Sieg schrieb:> Je länger ich drüber nachgedacht habe, wäre eine Stand-Alone Lösung mit> eigenen VGA+Tastatur Teil (auf Basis Propeller) doch 'nicht> uninteressant'.
5 Platinen dazu sind gerade in Auftrag.
Peter Sieg schrieb:> Was gäbe es sonst noch für 'sinnvolle' Erweiterungsmöglichkeiten?
Mir fällt da schon noch einiges dazu ein.
Einen ATmega644 einsetzen. Der hätte eine zweite serielle Schnittstelle
z.B. für den Datenaustausch mit einem anderen System und noch genug Pins
für eine LPT Schnittstelle.
Einen AT90USB64/128 einsetzen. Dort könnte das Terminal über USB
angeschlossen werden und die serielle Schnittstelle ist ebenfalls frei.
Weiterhin gibt es genug Portpins. Die Programmierung über ISP kann auch
entfallen, da er über USB mit LUFA geflasht werden kann.
Mit der „Cpmlino“ Variante sieht es nicht so gut aus. Die derzeitige
Entwicklung geht ja zum ATmega32U4 und der ist wirklich Mist! Wenn man
sich mal die Portaufteilung ansieht, fragt man sich ernsthaft, was die
Entwickler dabei gedacht haben.
Joe
@Joe G. Der Schaltplan zeigt was..?
Die 5 Platinen sind die Version mit P8X32 Terminal?
Falls noch eine frei wäre..
---
I2C hab ich bisher auch noch überhaupt gar nichts gemacht.. hier gäbe es
auch
noch so einige Möglichkeiten.. Ich glaube der RTC läuft über I2C und
dafür habt ihr auch schon einen Treiber gemacht..?
---
Chip-8 Emulator unter CP/M wäre auch ein schönes Projekt.
---
Peter
Peter Sieg schrieb:> @Joe G. Der Schaltplan zeigt was..?
Der Schaltplan zeigt ein CP/M System mit VT100 Terminal, PS2 Tastatur,
RTC sowie einem 8-Bit Port. Ich hatte es schon hier beschrieben.
Beitrag "Re: CP/M auf ATmega88"
Da jedoch keiner so richtig Interesse gezeigt hat, hatte ich einfach für
mich 5 Testplatinen bestellt. Mit so einer plötzlichen Resonanz hatte
ich gar nicht gerechnet. Nun sind sie schon wieder alle.
1 x Joe G.
1 x Peter Z.
1 x Hans-Werner
1 x Peter S.
1 x Leo C.
Ohne den Anschein der Bestechlichkeit zu erwecken, würde ich Leo C.
gerne eine zukommen lassen :-). Somit hätten wir alle die gleiche
Hardware um die RTC die A/D-Wandler und den 8-Bit Port in Betrieb zu
nehmen. Bei Bedarf können wir ja dann wieder eine größere Serie
auflegen. Möglicherweise ergeben sich auch noch einige Änderungen.
Joe
@Joe G. Freut mich, das noch eine 'über' war .. ;-)
Auf dem Schaltplan sehe ich einen ATmega88/168 und Ein HM51W17805 =
SRam? und einen SD Slot.. sonst nichts Wesentliches.. bin ich blind?
Von P8X32 und ser.Eprom nichts zu sehen.. ich denke der Schaltplan passt
nicht zum verlinkten Board & Beschreibung..
Peter
Habe hier noch ein Problem mit einem avr cpm stick Aufbau.
Habe schon alles nachgelötet, C am SD Slot gwechselt.. immer das
gleiche:
Initing mmc...
A:FAT16 File-Image at: 002, size: 256KB.
Partinit done.
Ok, Z80-CPU is live!
Z V A =00 BC =A201 DE =0001 HL =DCD0 SP=BF3E PC=F2F0 76 76 76
A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00 CPU
halted!
CPM on an AVR, v2.3 r185
Testing RAM: fill...wait...reread...
Initing mmc...
A:FAT16 File-Image at: 514, size: 256KB.
B:FAT16 File-Image at: 530, size: 8192KB.
C:FAT16 File-Image at: 002, size: 8192KB.
D:FAT16 File-Image at: 1042, size: 8192KB.
Partinit done.
Ok, Z80-CPU is live!
Z V A =00 BC =A201 DE =0001 HL =DCD0 SP=BF40 PC=F2F0 76 76 76
A'=00 BC'=0000 DE'=0000 HL'=0000 IX=0000 IY=0000 I=00 CPU
halted!
Oben mit eine SD Karte mit nur A Image.
Unten andere SD Karte mit 4 Images.
???
Irgendeine Idee?
Peter
Du könntest ja mal .equ INS_DEBUG = 1 und .equ PRINT_PC = 1 setzen und
schauen wo der Prozessor hin springt und welchen Befehl er ausführt.
Es gibt ja prinzipiell zwei Fehlermöglichkeiten.
1. SD-Card wird nicht richtig gelesen
2. RAM verliert Speicherinhalte
Beides führt natürlich auf eine unsinnige Befehlsausführung.
Guten Abend,
ich würde für die neue Version noch einige Bauelemente bestellen. Wer
Interesse hat, hängt sich einfach mit ran.
ATmega328 TQFP32
P8X32A-Q44 (Propeller)
PCF8583T SO08
PCF8574T SO16W
AT24C256 DIL
20 MHz Quarz
5 MHz Quarz (Propeller)
32 KHz Quarz (RTC)
SD Slot SCDA6A0101
Joe
@Peter, ich weiß nicht, ob Du noch mit disk images experimentierst, oder
ob Du es mit oder ohne Erfolg aufgegeben hat. Ein paar Sachen sind mir
noch aufgefallen.
Peter Sieg schrieb:> Habe nun mit folgenden Änderungen:>> ; Fields in the parttabl>> .equ MAXDISKS = 10 ;Max number of Disks (partitions); was 8> .equ PARTENTRY_SIZE = 11 ;Size of a Partitiontableentry; was 9
Der 2. Wert sollte natürlich nicht geändert werden, da sich ja die Größe
eines einzelnen Tabelleneintrags ja nicht ändert. Vergrößern verbraucht
allerdings nur unnötig mehr RAM, während Verkleinern sicher tötlich ist.
Peter Sieg schrieb:>> Die Nummer der RAM-Disk steht auch in config.inc:>> #define RAMDISKNR 'I'-'A' /* Drive "letter" for first RAM disk */> Das hatte ich parallel auch schon gemacht, obwohl die Anz. Ramdisks bei> mir auf 0 steht.
RAMDISKNR-1 ist gleichzeitig auch das letzte erlaubte SD-Kartenlaufwerk.
Deshalb muß man diese Konstante auch dann richtig setzen, wenn man keine
RAM-Disks verwendet.
Man könnte die Anzahl der Disks vielleicht etwas übersichtlicher in
'config.inc' konfigurierbar machen. Da aber ggf. auch das BIOS angepasst
werden muß, weiß ich nicht, ob sich der Aufwand lohnt.
Peter Sieg schrieb:> Tja.. es sind immer die dummen Fehler..> So rum gehts:> mkfs.cpm.exe -f simhd -b cpm.bin -L test simhd.img> makeimage simhd.img simhd.img 8388608
Wenn man ein nagelneues Image erzeugt, müßte die Reihenfolge definitiv
egal sein. Sollte das bei Dir tatsächlich anders sein, würde ich Dich
bitten, nochmal je ein Image mit diesen Befehlen in beiden Reihenfolgen
zu erzeugen, jeweils eine Datei darauf zu kopieren, und mit das Ergebnis
zuzuschicken.
@Joe: Teile sind angekommen. Vielen Dank!
Hast du Bestückungsplan, Firmware für Propeller, 24C256 etc. ggf.
Aufbauhinweise; Bilder .. weitere Unterlagen dazu?
Ggf. reichelt Teileliste der restlichen Bauteile..
Gruß, Peter
Die Bestückung ergibt sich aus dem Schaltplan und dem Layout (siehe
Anhang 1). Einen Bestückungsplan habe ich nch nicht erstellt.
Die Firmware für den Propeller (siehe Anhang 2). Hier müssen noch die
Baudrate und Farben für das Terminal eingestellt werden
(propCOMM2_VGA.spin). Ich habe grün auf schwarz sowie 57600 Baud
eingestellt. Möglicherweise sind auch noch die Wartezeiten vom AVR CP/M
etwas zu vergrößern, damit die Initialisierung des VT100 Terminals
abgeschlossen ist, bevor das CP/M bootet.
Die Propellersoftware kann mit dem Propeller Spin-Tool übersetzt und
geladen werden.
http://www.parallax.com/tabid/832/Default.aspx#Software
Die Hardware ist so ausgelegt, dass es drei Kommunikationsmöglichkeiten
über die USB-Schnittstelle gibt.
1. Spinzugriff zum Propeller
2. Terminalzugriff zum AVR CP/M
3. CP/M - Propeller VT100
Die einzelnen Varianten werden über das Juperfeld gesetzt. Ich habe
leider noch kein schönes Bild dafür erstellt.
Danke Joe,
bei mir sind die Teile auch heute Morgen angekommen. Allerdings werde
ich mich frühestens nächste Woche damit beschäftigen können.
Nach Diktat verreist...
Hier ein Bild TOP Layer und Partlist.
Wer meine Teile+Platine haben möchte -> Mail. Ich komme auf absehbare
Zeit nicht dazu und habe ja noch die seriellen Varianten hier.
Peter
Hallo zusammen,
bzgl. dieses interessanten Projekts bin ich quasi ein Späteinsteiger :-)
Es ist auch das erst mal, dass ich hier etwas schreibe - hoffentlich
mache ich alles richtig.
Ich wollte mich Schritt für Schritt dem Thema nähern und habe daher erst
einmal die einfache "Lochraster-Variante" (Mega88, 1x RAM) aufgebaut
[[http://petersieg.kilu.de/avrcpm/avrcpm.html]].
Später wollte ich dann Platinen ätzen (oder bei einer Sammelbestellung
dranhängen), VGA-Adapter usw... realisieren.
Als Software (sowohl AVR-Code als auch Disk-Images) habe ich
verschiedene Entwicklungs-Stufen ausprobiert (unter WinAVR).
Zuletzt die Dateien von Peter Siegs "AVR_CPM_UDP2".
[[http://avr.cwsurf.de/?download=avrcpm_upd2.zip]]. Peter (DANKE!) hatte
mir schon mal das ein oder andere Disk-Image gegeben - aber so richtig
bin ich noch nicht weiter gekommen.
Es klappt noch nicht und ich weiß nicht, wo ich suchen muss? Ram?
Takt...?
Mein Aufbau:
- ATmega88-20
- RAM: sowohl KM44C256AP-8 als auch Siemens HYB514256A-70 (West Germany
:-))
- SD-Card: 1GB Platinum (Reichelt)
Beim Start kommt ohne Debug-Flags:
1
CPM on an AVR, v1.0
2
Initing mmc...
3
CP/M partition at: 062, size: 7657KB.
4
CP/M partition at: 15376, size: 7688KB.
5
CP/M partition at: 30752, size: 7688KB.
6
7
Ok, CPU is live!
Danach nix mehr - Stoppt. Als ob er nicht bootet...
MMC und RAM-Test geben folgende Ausgaben - nur was bedeutet das? Ist das
"gut" oder "schlecht" ?
1
CPM on an AVR, v1.0
2
Testing RAM: fill...wait...reread...
3
... (hier laufen dann Hex-Zahlen "00<xx@yyyy" mit yyyy bis FFFF durch)
4
Initing mmc...
5
MMC: <--0A, -->FF.
6
MMC: <--09, -->
7
...
8
MMC: <--FF, -->23.
9
MMC: <--FF, -->FF.
10
11
Ok, CPU is live!
Danach nichts mehr.
Und PC-Debug und INS-Debug:
... Endlose PC=xxxx hochzählend:
1
PC=2822PC=2822, opcode=00, decoded=0000.
2
PC=2823PC=2823, opcode=00, decoded=0000.
3
PC=2824PC=2824, opcode=00, decoded=0000.
4
PC=2825PC=2825, opcode=00, decoded=0000.
5
PC=2826PC=2826, opcode=00, decoded=0000.
6
PC=2827PC=2827, opcode=00, decoded=0000.
Hat jemand einen Tipp, wo das Problem liegen könnte?
Herzlichen Dank und Gruß
Marcel
Marcel Andre schrieb:> Testing RAM: fill...wait...reread...> ... (hier laufen dann Hex-Zahlen "00<xx@yyyy" mit yyyy bis FFFF durch)
Der Test schreibt verschiedene Werte (xx) ins RAM, aber es wird
offensichtlich von allen Adressen (yyyy) immer 00 zurück gelesen.
Bevor der RAM-Fehler nicht behoben ist, lohnt es sich nicht, über andere
Fehler überhaupt nachzudenken. Daß beide RAM-Bausteine kaputt sind, oder
mit 3,3V nicht funktionieren, glaube ich mal eher nicht.
--> Verdrahtung überprüfen.
Die Software-Revision von z80.asm habe ich im SVN gefunden. Die sollte
also funktionieren, wenn sie richtig konfiguriert ist. CPU und
Taktfrequenz scheinen richtig eingestellt zu sein, da sonst die Serielle
nicht laufen würde. Und sonst gibts der Version eigentlich nichts
einzustellen.
Danke Leo für die Rückmeldung !
Verdrahtung habe ich (mehrfach, auch mit Messgerät) überprüft. Da ist
alles nach dem Grundplan (den auf Sprite...) richtig
[http://spritesmods.com/?art=avrcpm&page=2].
Es gab da ja mal eine Änderung..., aber die ist da ja schon
berücksichtigt?
Bei mir ist PC1 - WE und PC4 - DO2/IO3
Marcel Andre schrieb:> Bei mir ist PC1 - WE und PC4 - DO2/IO3
Umdrehen!
siehe z80.asm:
1
;Port C
2
.equ ram_d0 = 0
3
.equ ram_d1 = 1
4
.equ ram_d2 = 2
5
.equ ram_d3 = 3
6
.equ ram_w = 4
7
.equ ram_cas= 5
Die Leitungen haben wir vertauscht, damit die 4 Datenleitungen zusammen
auf einem Nibble liegen. PC0..PC3 kann man natürlich beliebig
untereinander tauschen.
>> Die Leitungen haben wir vertauscht, damit die 4 Datenleitungen zusammen> auf einem Nibble liegen. PC0..PC3 kann man natürlich beliebig> untereinander tauschen.
Genau das war es: Gegenüber der original-Beschaltung (Image und
Eagle-Datei) mussten 3 Leitungen anders belegt werden.
Super herzlichen Dank!
Ich sage Peter noch Bescheid, ggf. die Doku zu ändern, damit andere
"Späteinsteiger" nicht in die gleiche Falle tappen.
Gruß
Marcel
hmm. Auf meiner Seite steht das schon genauso, wenn sich das mal
chronologisch durchliest.
Ach, sehe gerade, das ist die Ur-Altseite..
Besser diese hier:
http://petersieg.bplaced.net/
Dort steht:
Update
Hier der aktuelle Entwicklungstand der Software: avrcpm_upd.zip
* Warmstart (behoben im Bios; in den 2 diskimages enthalten)
* 8080 Opcodes fehlerbereinigt (MBASIC laeuft jetzt!)
* Unterstuetzung fuer ATmega8, 88, 168
* 2 Diskimages mit neuem Bios enthalten
Achtung: 2 Leitungen sind zu tauschen (Beschleunigung DRAM Zugriffe):
Pin 24 - PC1 - /WE
Pin 27 - PC4 - IO3
---
@Leo C: Zitat:
Marcel Andre schrieb:
> [[http://petersieg.kilu.de/avrcpm/avrcpm.html]].
Ehre wem Ehre gebührt. Und das ist in diesem Fall "Sprite_tm":
http://spritesmods.com/?art=avrcpm&page=2
=> Die Ehre von sprite_tm als Entwickler der Ursprungs-Version war hier
nie in Gefahr! Sowas hatte Marcel doch gar nicht geschrieben..
Und die "Ehre" für meine Seite(n) und deren Informationen beanspruche
ich schon noch für mich..
;-)
Peter
Eine Frage hätte ich noch, bevor ich mich an die "echte" Z80-Version
mache: Man findet "im Netz" ja jede Menge Software, die angeblich für
CP/M 2.2 und 8080-CPU gemacht wurde (z.B. TurboPascal 1.0).
Dennoch bricht so etwas immer mit falschem Opcode ab.
Ist das so richtig? Verlangt das doch die Z80-Emulation?
Joe G. schrieb:> TurboPascal läuft nur tatsächlich nur unter Intel 8086 oder Z80.
Das kann ja dann nur bedeuten, daß die Z80-Emulation noch nicht gut
genug ist. Da man prinzipiell immer eine 100%-Softwareemulation
hinkriegen (schließlich sind die Dinger allesamt Turing-vollständig),
kann es also allenfalls an der letztlich erzielbaren
Ausführungsgeschwindigkeit klemmen.
Deswegen ist es auch kein bissel spannend, CP/M oder TP auf einem AVR
zum Laufen zu kriegen, denn es steht von vornherein fest, daß es möglich
sein muß. Das einzig spannende ist, wie schnell das Ergebnis laufen
wird. Und das hängt nur davon ab, wie effizient die Emulation der CPU
auf dem Zielsystem ist.
Der Rest ist nicht mehr und nicht weniger als ein Benchmark für die Güte
der eigentlichen Problemlösung, sowohl in Hinsicht auf die Exaktheit als
auch die Effizienz der Emulation.
c-hater schrieb:> Joe G. schrieb:>> TurboPascal läuft nur tatsächlich nur unter Intel 8086 oder Z80.> Das kann ja dann nur bedeuten, daß die Z80-Emulation noch nicht gut> genug ist.
Diesen Kommentar verstehe ich nicht. Für alle Interessenten.
Die Z80 Emulation läuft vollständig, somit auch Turbo Pascal und andere
Programme die nur unter CP/M und Z80 Code laufen.
Peter Sieg schrieb:> => Die Ehre von sprite_tm als Entwickler der Ursprungs-Version war hier> nie in Gefahr! Sowas hatte Marcel doch gar nicht geschrieben..> Und die "Ehre" für meine Seite(n) und deren Informationen beanspruche> ich schon noch für mich..
Peter, ich will Deine Leistung für das Projekt garnicht
kleinreden/schreiben, aber Du verwendest den handgemalten Schaltplan von
sprite_tm ohne Quellenangabe. Überhaupt sehen imho die zahlreichen
Seiten für den uneingeweihten Betrachter so aus, als wäre das alles auf
Deinem Mist gewachsen. Erst wenn man auf die Idee kommt, den
unkommentierten Links zu folgen (auf der petersieg.kilu.de-Seite nicht
anklickbar), weiß man mehr.
Vorschlag: Analog zum hiesigen AVR CP/M-Artikel im ersten Absatz
ein/zwei Sätze zur Herkunft des Projekts einfügen.
Und eine Quellenangabe/Copyright zur Grafik 'avrcpm.png'.
Und wenn dann noch je ein halber Satz erklären würde, wo die 4 Links am
Anfang hinführen, wärs perfekt.
Gestern habe ich endlich mal Joes neue Platine (teil)bestückt und heute
in Betrieb genommen. Der Hauptteil läuft.
Terminal und USB-Schnittstelle habe ich erst mal weggelassen, und der
3,3V-Spannungsregler fehlt mir noch (inzwischen bestellt).
Vorläufig habe ich einen externen USB/Serial-Adapter dran, der auch 3,3V
liefert.
Beim Bestücken ist mir aufgefallen, daß die Pads für den Uhrenchip nicht
passen (zu eng, für das schmalere SO-Gehäuse). Das ist aber kein großes
Problem, da unterhalb des Chips Platz genug ist.
Leo C. schrieb:> Beim Bestücken ist mir aufgefallen, daß die Pads für den Uhrenchip nicht> passen
Oh Mist, da habe ich wohl geträumt! Ich bin leider bis auf die 3.3V und
den USB-Teil noch nicht so weit gekommen. In einigen Tage geht es aber
wieder weiter. Ich würde dann auch mal eine kleine Bauanleitung für die
Hard- und Software erstellen, da es für einen Neueisteiger schon recht
unübersichtlich wird.
@Leo.C. Was macht denn der lustige Draht der zum RTC geht?
Joe G. schrieb:> @Leo.C. Was macht denn der lustige Draht der zum RTC geht?
Der Draht geht, vom CS der SD-Karte kommend, scharf am RTC vorbei an das
abgeknickte Bein der LED. Ich habe die Betriebs-LED privisorisch zur
"Drive-Select"-Anzeige umgewidmet. Ohne diese Anzeige kann ich gar nicht
mehr leben.
Hier mal ein erster Vorschlag für das I2C-Interface
Der Parallel-I/O Chip hat nur je ein Input- und Output- und keinerlei
Steuerregister. Daher bietet es sich an, In und Out direkt auf
Z80-I/O-Befehle zu mappen. Im Moment sieht es so aus:
Da 8 Chips adressierbar sind, habe ich auch 8 Adressen reserviert. Mit
der A-Variante sind insgesamt 16 Ports adressierbar.
Der RTC und weitere, am externen Bus angeschlossene I2C-Chips (und wenn
man will, auch der PCF8574) können über das folgende Interface
angesprochen werden:
;05 in - Status of last Transfer: 0 = ok, else fail
5
;06 in/out - Number of bytes to transfer, including Slave address
6
;07,08 in/out - Read/Write address low/high
Das Z80-Programm füllt einen Puffer mit der Slave-Adresse, und im
Sendefall, mit den zu sendenden Daten. Die Pufferadresse und die Anzahl
zu übertragender Daten, werden über die oben angegebenen Ports an den
Treiber übergeben. Die Länge schließt immer die Slave-Adresse mit ein.
Anschließend wird der Transfer über die Ausgabe auf Port 5 gestartet.
Z.Zt. ist interne Puffer 17 Byte groß. Es können also maximal 16
Datenbytes (z.B. zu oder von einem EEPROM) übertragen werden.
Fehlerbehandlung und -Rückmeldung ist bisher nur rudimentär. Evtl. muß
dort noch nachgearbeitet werden.
Um das Interface und den RTC-Chip zu testen, habe ich ein quick&dirty
Programm mit Turbo-Pascal geschrieben. Eingecheckt ist noch nichts.
Deshalb der Anhang mit (hoffentlich) allen geänderten Dateien.
Deine Idee mit der I2C Interface finde ich gut so. IN/OUT über I/O. Ist
ja fast wie die alte PIO ;-)
Die Variante deines Virtual-I2C-Interface klingt auch schlüssig. So
lassen sich dann auch A/D-Wandler, LCD-Anzeigen etc. anschließen. Ich
werde wohl heute mal einen intensiven Löttag einlegen...
Joe G. schrieb:> werde wohl heute mal einen intensiven Löttag einlegen...
Ich hoffe, Du bist voran gekommen, und kannst den aktuellen
Softwarestand, den ich heute eingecheckt habe, testen.
Die Schnittstelle zur Uhr habe ich nochmal geändert. Deshalb muste der
ZSDOS-Treiber AVRCLOCK.MAC angepaßt werden.
Joe G. schrieb:> Dann ist das ja ein MUSS für das Pflichtenheft der nächsten Version ;-)
Beim Aufbau der Platine sind mir noch ein paar Punkte auf/eingefallen:
PCF8583:
- An Pin 1 (OSCI) muß ein Kondensator angeschossen sein. Das
Datenblatt empfiehlt einen Trimmer 5-25pF. Bei mir tuts
ein 15pF C (Abweichung in 3 Tagen ca. +2s). Ohne läuft die Uhr
nicht richtig an.
--> Pads für C und/oder Trimmer vorsehen.
- Lithiumzelle (hält Jahre) statt Gold-Cap (hält Tage)?
CR2032 ist spottbillig, aber leider etwas groß.
SD-Card:
- C11 scheint mir etwas klein dimensioniert. 4,7µF --> 47µF?
- Keine Pullups
Zu beiden Punkten siehe http://elm-chan.org/docs/mmc/mmc_e.html
(Abschnitt "Cosideration to Bus Floating and Hot Insertion")
FT232RL:
- R21 u. R22 (LED-Widerstände)
Sind 10K nicht etwas groß? (Bei mir noch nicht bestückt)
Vielen Dank für die Hinweise!
Leo C. schrieb:> An Pin 1 (OSCI) muß ein Kondensator angeschossen sein.
Ist aufgenommen, auch die Änderung der Bauform. Mal
sehen welche Lithiumzelle ich unter bekomme.
Leo C. schrieb:> - Keine Pullups
Ist auch aufgenommen.
Generell zu den R und C's:
Die 10K bzw. 10µ oder 4,7µ sind immer durch Copy und Paste an die Stelle
gekommen wie ein R oder ein C bestückt werden sollte. Dabei habe ich den
Bauteilwert nicht angepaßt. Also bei der Bestückung wirklich darauf
auchten welcher Wert sinnvoll ist. Ich ändere es aktuell gerade in den
Schaltungen.
Sever läuft.
Allerdings ging die Namensauflösung seit heute Morgen nicht mehr.
Sollte jetzt wieder gehen. Mein Browser weigert sich aber auch noch.
seltsam. Wenns bei Dir auch noch nicht tut, versuche mal
e179220223.adsl.alicedsl.de als Server.
Danke! Mit der "Ersatzadresse" get es.
Die neue AVR Software läßt sich erstmal fehlerfei übersetzen und CP/M
bootet auch korrekt.
Um den RTC anzusprechen ist sicherlich zunächst die TP-Quelle gedacht.
Wird AVRCLOCK.MAC dann noch benötigt? Ich nehme an, für den RTC hast du
A0 auf GND gelegt (Adr. A0)
Joe G. schrieb:> Die neue AVR Software läßt sich erstmal fehlerfei übersetzen und CP/M> bootet auch korrekt.
Im Moment ist es so, daß die Initialisierung hängen bleibt, wenn am
I2C-Bus keine Pullup-Widerstände sind, also z.B. auf "alter" Hardware.
Das möchte ich demnächst noch ändern.
> Um den RTC anzusprechen ist sicherlich zunächst die TP-Quelle gedacht.
Das TP-Programm war zum Testen der I2C-Schnittstelle und der Uhr
gedacht, und kann noch als Beispiel verwendet werden.
> Wird AVRCLOCK.MAC dann noch benötigt? Ich nehme an, für den RTC hast du> A0 auf GND gelegt (Adr. A0)
Ja, und ja.
In AVRCLOCK.MAC ist der Treiber für ZSDOS. Aus AVRCLOCK.REL wird mit
SETUPZST.COM das CLocktreiber-Ladeprogramm LDTIM.COM gebaut. Für den
schnellen test habe ich mal ein fertiges LDTIM.COM hier angehängt.
Man kann den Treiber auch ins BIOS einbauen. Dazu muß man ZSDOS
entsprechend konfigurieren. Kommt demnächst...
Joe G. schrieb:> Mal sehen welche Lithiumzelle ich unter bekomme.
Der Punkt war mehr als Frage und zur Diskussion gedacht. Vielleicht gibt
es ja noch Gründe für einen Kondensator, die ich übersehen habe. Wie
groß ist denn dein Goldcap?
Ich habe nur welche mit 0.1F hier. Bin zur Zt. am Messen. 2 volle Tage
scheint er nicht ganz zu schaffen. Laut Datenblatt sollte der Strom
unterhalb von gut 2V konstant sein. Das sieht bei mir anders aus.
@Leo C.
Für LDTIM.COM hätte ich ja auch mal das Handbuch lesen können ;-)
Programm läuft jedoch, auch das nun neue ACT.COM
Bei der Uhr habe ich noch Probleme, es kommt recht großer Unsin vom RTC.
Nun muß ich erst mal ein Oszi an die I2C Leitungen hängen.
Joe,
geht denn der I/O-Port?
Einfach zu testen mit ddtz.
"I80" zum Lesen. "O<val> 80" zum Schreiben.
Wenn das geht sehe ich keinen Grund, warum die Uhr nicht auch gehen
sollte.
hast Du einen C (ca. 18pF) von Pin 1 nach Vdd am RTC?
"Dummerweise" wird beim Schreiben der Uhr das 1Hz-Signal am
Interupt-Ausgang (Pin 7) abgeschaltet (In der Routine "rtc_set", durch
Setzen des "alarm enable" bits.
Nach Powerup kann man das Signal aber auf jeden Fall messen (Pullup
notwendig).
Joe G. schrieb:> Programm läuft jedoch, auch das nun neue ACT.COM
Das Programm ist nicht neu. :-)
Joe G. schrieb:> TIMER.COM darf auch ACT.COM heißen. (AVR CP/M Tool) ;-)
Oder AVRCPM Control Tool.
Leo C. schrieb:> Joe G. schrieb:>> TIMER.COM darf auch ACT.COM heißen. (AVR CP/M Tool) ;-)
hatte ich schon vergessen ;-)
Habe den Fehler nun eingegrenzt. Quarz schwingt, C zu Vdd auch nicht
vergessen, 1 Hz kommt, ABER die Option I2C beim Compiler nicht
eingestellt. Wenn ich nun jedoch I2C auf 1 setze, dann kommt das
Programm nichtmal bis zu einer Terminalausgabe. Die zwei PullUp
Widerstande sind jedoch am Bus.
Joe G. schrieb:> Beide Leitungen sind Low
Die Pullups sollten die aber hochziehen.
> In welchem File steckt eigentlich rtc_get?
leo@cb: grep rtc_get: *.asm
timer.asm:rtc_get:
Joe G. schrieb:> Leo C. schrieb:>> Die Pullups sollten die aber hochziehen.>> Der Controller zieht nach der Routine i2c_init die Leitungen auf Low.
Open Drain.
In der allgemeinen Init werden die Ports auf Ausgang und auf High
geschaltet (Sollte vielleicht geändert werden).
In i2c_init werden die aktiven Treiber abgeschaltet, und wenn keine
Pullups vorhanden sind, floaten die Leitungen nach Low.
Bei offenen Leitungen (Pullups fehlen oder falsch verdrahtet) sollte ca
70ms nach steigender Reset-Flanke ein ca 300µs langer High-Impuls
kommen.
Wenn die Leitungen ohne den Impuls dauerhaft auf Low liegen, zieht die
irgendwas runter. Das sollte aber nicht der Processor sein, wenn Du die
gleiche Software hast, wie ich.
@alle: Da ich noch 1-2 Anfragen hatte aber keine Platine mehr, habe ich
nochmals ein kleine Auflage an roten Platinen des AVR CP/M USB Sticks
bestellt.
Wer welche haben möchte (=> Mail!):
* Platine: 12€
* SD Slot: 3€
* ATmega328:4€ (programmiert)
Versand im Polsterumschlag: 2€
Das wird wohl die letzte Auflage werden, weil die SD Slots nur noch
schwer zu bekommen sind.
Peter
Die letzten Tage habe ich mich auch mal mit Bootloadern beschäftigt.
1. Im Artikel AVR CP/M ist ja schon einer beschrieben. Der geht aber
wohl nur mit Hardware-UART und ist für mich sowieso uninteressant, da
zum Laden propietäre Windows-Software gebraucht wird.
2. AVR Bootloader FastBoot von Peter Dannegger
Läuft quasi out-of-the-box. Egmont hat vor einiger Zeit schon was dazu
geschrieben.
Egmont schrieb:> fboot funktioniert bei mir nur bis Win XP.
Allerdings gibts mehrere Alternativen zu fboot, zum Teil mit
Verbesserungen. Das hier läuft bei mir, und läßt sich auch in gängige
Terminalprogramme einbinden:
Beitrag "Re: UART Bootloader ATtiny13 - ATmega644"
Im Wiki-Artikel sind aber auch noch andere genannt.
3. MMC/SD Bootloader für AT Mega von Stefan Seegel.
(http://www.mikrocontroller.net/articles/MMC/SD_Bootloader_f%C3%BCr_AT_Mega)
Das ist zur Zeit man Favorit. Man kopiert ein Image mit der neuen
Software auf eine SD-Karte, schiebt sie in den AVRCPM-Computer und
drückt Reset. Nach ca. 3 Sekunden meldet sich die neue Software.
Eine Version des Laders, die mit allen meinen SD-Karten (auch SDHC)
läuft, habe ich vor kurzem in das Forum gestellt:
Beitrag "Re: MMC/SD Bootloader füt ATMega16"
Der Bootloader lädt nur Dateien, die eine passende Kennung und gültige
CRC-Summe haben. Im Anhang ist deshalb mal ein Beispiel, wie man die
Kennung in Makefile und avrcpm.asm integrieren kann.
Wer zufällig ein AVRCPM mit ATmega328(P), 8-Bit-RAM, 115200 Baud hat,
kann auch die fertigen Dateien im Toplevel-Dir des Zips zum Testen
nehmen.
Das Hexfile flashen, Fuses einstellen auf: Boot section size 1024K
Words, Boot reset vector enabled (BOOTRST) (avrdude -U hfuse:w:0xd2:m).
Die Bin-Datei auf Karte kopieren und einstecken. Sollte klappen.
ps:
Peter Sieg schrieb:> Wer welche haben möchte (=> Mail!):> ...> * ATmega328:4€ (programmiert)
Für Kunden, die diesen Service nutzen, müßte der MMC-Bootloader doch
auch ideal sein.
@Leo C.
Der Bootloader scheint bei mir zu laufen. Wenn den AVR lösche wird nach
dem Reset offensichtlich die Datei avrcpm-3.1-test.bin in den Flash
geschrieben denn das CP/M läuft dann wieder. Allerdings bekommt man
keinen Hinweis, dass die Software nachgeladen wurde.
Die Quellen im Trunk-Verzeichnis lassen sich nur ohne die Option I2C=1
übersetzen. Ansonsten kommen Speicherzuordnungsfehler.
Wie muß aus der HEX eine BIN Datei gemacht werden? Die Datei scheint mir
mit FF aufgefüllt und am Ende steht noch ACPM + Prüfsumme?
Joe G. schrieb:> geschrieben denn das CP/M läuft dann wieder. Allerdings bekommt man> keinen Hinweis, dass die Software nachgeladen wurde.
Wie auch.
Der Bootloader kennt von der Hardware nur das allernötigste. LEDs haben
wir keine. Und die Software selbst weiß ja nicht, daß sie gerade erst
geladen wurde.
Normalerweise sollte man wissen, daß man eine Karte mit neuer Software
einsteckt. Bei mit flackert dann lustig die LED am Card-Select-Pin.
Beim Starten sollte man auch an der veränderten Versionsnummer sehen,
daß die Software neu ist. Es sei denn, man hat eine Testversion geladen.
> Die Quellen im Trunk-Verzeichnis lassen sich nur ohne die Option I2C=1> übersetzen. Ansonsten kommen Speicherzuordnungsfehler.
Ups, hatte ich nicht getestet. Mit den angehängten Dateien sollte es
wieder gehen.
> Wie muß aus der HEX eine BIN Datei gemacht werden?
make bin
(Oder im Makefile das bin-Target suchen, und die zwei Anweisungen dort
manuell ausführen, oder ins eingene Build-Dings übernehmen.)
> Die Datei scheint mir mit FF aufgefüllt und am Ende steht noch ACPM + Prüfsumme?
Ja. Und die Versionsnr. (Major,Minor). Normalerweise wird nur geladen,
wenn die auf der Karte gefundene Versionsnr. größer ist, als die
Installierte. Es sei denn, auf der Karte wurde eine Version 0.0
gefunden, die immer gelagen wird (Testversion). Alles im
Bootloader-Thread zu finden:
http://www.mikrocontroller.net/topic/goto_post/3085712
'crcgen' ist im Bootloader-Paket.
'objcopy' ist in den GNU-Binutils, und dürfte damit auf nahezu jedem
unixoiden System vorhanden sein (auch Cygwin und ähnliches). Es muß
nicht unbedingt 'avr-objcopy' sein. Aber das wird üblicherweise mit
avr-gcc mitgeliefert (WinAVR). Es gibt aber auch andere hex2bin Tools.
Auch welche die die Lücken mit 0xff füllen (Wahrscheinlich auch im
Bootloaderthread zu finden). Aber das ist ja schon reiner Luxus.
Besten Dank für die Erklärung.
Stimmt, die aktuelle Versionsnummer sollte es richten ;-)
Mit crcgen und objcopy geht es nun auch. Damit ist ein Softwareupdate
über MMC eine wirklich feine Sache.
Nur mal nebenbei. Ist eigentlich die veränderte serielle Routine
eingearbeitet? Das Flackern im TP Editor ist weg :-)
Joe G. schrieb:> Nur mal nebenbei. Ist eigentlich die veränderte serielle Routine> eingearbeitet? Das Flackern im TP Editor ist weg :-)
Ja. Damit wäre dieser Test wohl auch abgehakt. ;)
Wahrscheinlich habe ich aber auch einen kapitalen Fehler
"eingearbeitet". :-(
TP produziert mit einem einfachen kleinen Programm nur Mist. Vermutlich
ist bei den Z80 Opcodes ein Fehler in den Interpreter gerutscht. Die
gestern geposteten Dateien also bitte nicht für ein Produktionssystem
benutzen. ;-)
ps:
Hier das Programm (von hier
http://blogs.embarcadero.com/davidi/2008/11/06/38988 ):
1
program eightqueens;
2
{
3
Eight Queens problem - recursive edition
4
from Nicklaus Wirth's book:
5
Applications + Data Structures = Programs }{
6
Modified 11/06/2008 by David Intersimone "David I"
7
to work with Turbo Pascal version 1.0:
8
1 - added NumberOfIterations and loop to be able to benchmark
9
on modern circa 2008 PCs
10
2 - added MSDOS calls Int21h with AH=2Ch to get System Time
11
3 - commented out the call to 'print' the solutions to remove
12
screen output from the benchmark time
13
}
14
15
{ type
16
MSDOS_Parameters_Type = record
17
AX,BX,CX,DX,BP,SI,DI,DS,ES,Flags : Integer;
18
end;
19
}
20
21
const
22
{ NumberOfIterations = 12000;} {for benchmarking on modern PCs how many times to solve it}
In der aktuellen Version scheint "rcall" für die Funktion printhex nicht
mehr auszureichen. Mit "call" läuft es.
dsk_fsys.asm
printstring "DISK I/O: Invalid Function code: "
(r)call printhex
rjmp haltinv
Joe G. schrieb:> In der aktuellen Version scheint "rcall" für die Funktion printhex nicht> mehr auszureichen. Mit "call" läuft es.>> dsk_fsys.asm>> printstring "DISK I/O: Invalid Function code: "> (r)call printhex> rjmp haltinv
Das kommt davon, wenn man die Reihenfolge der Module verändert und
unkontrolliert Zwischenstände verteilt.
Bei mir heißt die Stelle:
printstring "DISK I/O: Invalid Function code: "
lcall printhex
rjmp haltinv
Seit gestern sogar schon im svn. lcall/ljmp sind Macros, die wenn
möglich r{call|jmp} einsetzen, und sonst eben ohne r.
Das Turbo-Pascal Problem liegt übrigens nicht am Z80-Interpreter,
sondern daran, daß man für rekursive Programme eine Option setzen, bzw.
abschlten muß: {$A- }
Der jetzige "Zwischenstand" aus dem svn geht :-) Sogar mit I2C=1 ohne
(!) Pullup. Bei der Vielzahl der jetzigen Möglichkeiten braucht es
dringend eine Dokumentation. Ich sehe ja bald selber nicht mehr durch
;-)
Joe G. schrieb:> Der jetzige "Zwischenstand" aus dem svn geht :-) Sogar mit I2C=1 ohne> (!) Pullup.
Das geht ja schon seit Ewigkeiten (17.2.) ;)
Damit könnte man den Treiber eigentlich fest reinnehmen, und den
I2C-Schalter aus der Config rauswerfen. Es sei denn, man will/muß auch
Flash sparen können, für kleinere Megas.
> Bei der Vielzahl der jetzigen Möglichkeiten braucht es dringend> eine Dokumentation. Ich sehe ja bald selber nicht mehr durch ;-)
Du bist nicht allein. ;-)
Die Schalter haben zwar alle mindestens eine Zeile Kommentar in
config.inc, aber die Zusammenhänge lassen sich damit nur mühsam
erschließen. Vielleicht sollte man die Schalter mal alle auflisten, nach
Katerogien sortiert. Mit etwas ausführlicheren Kommentaren, und
Beschreibung der Abhängigkeiten. Die Liste könnte man in config.inc oben
einfügen, in eine extra Datei, und/oder auf die Projektseite setzen.
Viele Schalter kann man auch im Makefile setzen. Wahrscheinlich sorgt
das für weitere Verwirrung. Es hat aber den Vorteil, daß man schnell mal
für einen Test mit anderen Optionen übersetzen kann, ohne die Sourcen zu
ändern. Makefile-Schalter kann man z.B. auch auf der Befehlszeile
setzen:
1
$ make DEVID_S="" MCU=atmega168
wenn man wissen will, ob das Programm ohne Bootloader in den ATmega168
passt. (Passt (noch) nicht, und EM_Z80 kann man im Makefile nicht
abschalten.) ;-) Oder:
1
$ make clean bin BAUD=9600
wenn man für Testzwecke mal schnell eine andere Baudrate braucht.
Vorschlag. Wir könnten doch zunächst alle Schalter auf eine „optimale“
Defaulteinstellung setzen, so wie es zum Teil schon realisiert ist. Wer
eine wirklich eigene Variante haben möchte, kommt sowieso nicht um eine
intensive Beschäftigung mit der Materie drum rum.
Defaultvorschlag:
DRAM-8BIT
F_CPU 20000000
BAUD 115200
I2C=1
EM_Z80=1
DBOOTLDRSIZE=2048
Joe G. schrieb:> Vorschlag. Wir könnten doch zunächst alle Schalter auf eine „optimale“> Defaulteinstellung setzen, so wie es zum Teil schon realisiert ist. Wer
Sowas ähnliches habe ich jetzt mal gemacht (Anhang). Als Default-MCU
habe ich jetzt mega328P eingestellt. Den will ja sowiso jeder haben,
weil nur damit Z80 geht. Die Kommentare sind aber noch ausbaufähig.
> eine wirklich eigene Variante haben möchte, kommt sowieso nicht um eine> intensive Beschäftigung mit der Materie drum rum.
Ja, wobei die bisherige Config aber auch schon zu (vermeidbaren)
Mißverständnissen geführt hat. (Z.B. [1])
> Defaultvorschlag:>> DRAM-8BIT> F_CPU 20000000> BAUD 115200> I2C=1> EM_Z80=1> DBOOTLDRSIZE=2048
Da die Bootladerunterstützung ja für den speziellen MMC/SD Bootloader
ist, andere Bootloader brauchen ja keine Unterstüzung, ist die Größe
auch fest. Deshalb habe ich sie mit anderen Parametern als (notfalls
änderbare) Konstanten weiter nach unten verbannt. Dafür gibt es jetzt
einen Schalter
> MMCBOOTLOADER
der defaultmäßig eingeschaltet ist, weil das ja auch nicht stört.
Bevor ich die geänderte Config einchecke, bitte ich alle Mitleser sich
daß mal anzuschauen, und ggf. Verbesserungsvorschläge zu machen. Mit den
vorhergehenden Änderungen (RTC, I2C, MMC Bootloader Support) soll das
Ganze demnächst Version 3.1 werden.
[1] Beitrag "Re: CP/M auf ATmega88"
Bei mir läuft die aktuelle Version auf beiden Hardwareversionen (mit
I2C/ohne I2C).
Die Voreinstellungen sind prima so, damit sollte der Einsteiger zunächst
sein System übersetzt bekommen.
CPM on an AVR, v3.1 r201 Test
Testing RAM: fill...wait...reread...
Initing mmc...
A:FAT16 File-Image at: 8479, size: 256KB.
B:FAT16 File-Image at: 8959, size: 256KB.
C:FAT16 File-Image at: 8703, size: 256KB.
D:FAT16 File-Image at: 9087, size: 8192KB.
Partinit done.
Ok, Z80-CPU is live!
A>
Eine Frage bleibt trotzdem.
Testversion=1 gesetzt und die Datei avrcpm-3.1.bin erzeugt. Es steht
auch die Version 0.0 in der BIN-Datei. Nach 3 Sekunden Reset wird diese
Version geladen (CPM on an AVR, v3.1 r201 Test) Bei einem kurzem Reset
wird die Version (CPM on an AVR, v3.1 r199) von der Datei
avrcpm-3.1-test.old geladen. Nach welchem Kriterium sucht der Bootloader
nach einer gültigen Datei? Welche Namenskonventionen gelten für diese
Datei?
Der Dateiname ist egal. Es wird nur nach dem Tag in der Datei geschaut:
ID, Version und CRC. Wenn mehrere. Versionen auf der Kartesind, sollte
die mit der höchsten Nummer geladen werden, falls sie das nicht schon
ist. Eine 0.0 Version sollte immer geladen werden, außer, wenn genau
diese schon im Speicher ist (CRC) . Wenn jetzt eine "normale" und eine
0.0 Version auf der Karte sind, könnte es sein, dass zwischen den beiden
getoggelt wird. Unschön, aber wie gehts besser? Der Anwender sollte ja
auch ungefähr wissen, was er will, und (nur) die passende Datei auf die
Karte kopieren.
Ok, toggeln muß ja auch nicht sein. Im Normalfall ist ja immer nur die
aktuelle Version auf der Karte.
Die VGA-Baugruppe ist nun komplett bestückt und in Betrieb genommen
(siehe Bilder). An der Software ist jedoch noch etwas zu tun. Anbei die
erste Version (0.1). Sie könnte auch ins SVN aufgenommen werden. Mit
einer Baudrate von 9600 laufen beide Systeme gut zusammen, bei einer
höheren Baudrate kommt es zu Fehlern, obwohl es im Terminalmodus geht.
Möglicherweise ein Pufferüberlauf. Die Tastatur geht derzeit nur mit dem
US Layout und außerdem gehen einige ESC Sequenzen noch nicht.
Hier ein ordentlicher Arbeiststand, mit dem man nun auch wirklich
arbeiten kann.
- deutsches Tastaturlayout
- deutscher Zeichensatz
P.S: Hat jemand die CP/M Version mit Tastatur und VGA schon aufgebaut?
Hallo Joe,
Danke für Deine VT100-Software.
Joe G. schrieb:> P.S: Hat jemand die CP/M Version mit Tastatur und VGA schon aufgebaut?
Meine Platine ist immer noch nicht komplett bestückt. Terminal und USB
hatte ich ja erst mal weggelassen. Nachdem ich vorhin die Drähte für den
externen USB-Seriell-Adapter weggelötet hatte, habe gemerkt, daß ich gar
keinen FTDI habe. Mir war völlig entgangen, daß der auch nicht in Deinem
Lieferservice mit drin war. Mal schauen, ob ich die Software auch ohne
FTDI-Chip in den Propeller bekomme.
Inzwischen habe ich den Bootloader nochmal getestet. Bei mir toggelt er
nicht zwischen 2 Programmversionen, aber 3 Punkte sind trotzdem unschön:
- Wenn außer der 0.0 Version noch eine andere auf der Karte ist, wird
bei jedem Reset die Software (0.0) neu geladen.
- Die Suche nach einer neuen Version dauert unötig lange, weil für jeden
Dir-Eintrag der ganze Dir-Sektor gelesen wird. D.h. jeder Sektor des
Root-Directories wird 16 mal gelesen. Bei einem Gerät, bei dem im
Normalbetrieb häufig Reset gedrückt wird, ist das schon ziemlich
lästig.
- Wenn ich die Karte im PC neu beschreibe, und dann in den AVRCPM-
Computer stecke, wird der erste Reset vom Bootloader ignoriert.
(Wahrscheinich Init-Fehler). Erst beim 2. Reset wird die Software
geladen.
Da die AVRCPM-Software unabhängig vom MMC/SD-Bootloader ist, und zu
dieser keine weiteren "Beschwerden" mehr kamen, habe ich den letzten
Stand heute ins SVN eingecheckt. Wenn weiterhin keine Änderungs- oder
Verbesserungsvorschläge kommen, werde ich daraus demnächst eine Version
3.1 machen.
Den Fehler des ersten Reset habe ich wohl als toggeln interpretiert.
Den Propeller kannst du auch seriell programmieren. Es ist neben Rx und
Tx nur noch ein Reset über DTR notwendig.
Bei der VT100 Software ist noch ein Bug bei R-Alt+Sonderzeichen,
außerdem müssen noch die Umlaute Ö,Ü,Ä im Zeichengenerator erstellt
werden. Demnächst kommt eine neue Version.
Joe G. schrieb:> Den Propeller kannst du auch seriell programmieren. Es ist neben Rx und> Tx nur noch ein Reset über DTR notwendig.
Das hatte ich befürchtet, daß DTR nicht optional ist. Heute Mittag habe
ich mir einige FT232 besorgt und gleich einen eingelötet. Der CP/M-Teil
läuft damit. Heute Abend kommt dann endlich der Propeller dran. Damit
habe ich bisher noch gar nichts gemacht.
Die Software gibt es jetzt hier als Version 3.1:
http://cloudbase.homelinux.net/viewvc/avr-cpm/avrcpm/tags/3.1/
Neuigkeiten seit 3.0:
- Unterstützung der neuesten Platine von Joe G.
- I2C
- Parallel Port I/O: PCF8574 (PCF8574A)
- RTC PCF8583
- ZSDOS clock driver
- Verbesserter Software-UART
- MMC/SD Bootloader support
- Konfiguration aufgeräumt
- Die üblichen kleinen Bug fixes und Verbesserungen
Also, außer I2C vielleicht, nur Kleinigkeiten. Hauptgrund für die
Version ist, daß ich den aktuellen Stand einfrieren möchte, weil ich
schon wieder eine Menge Änderungen angefangen habe. Schwerpunkt dabei:
Geschwindigkeitssteigerung, je nach Benchmark z.Zt. 10% - 20%, bei
gleichzeitiger Einsparung von Flash. Ziel: Programm soll ohne Funktions-
und Leistungseinbuße in den ATmega168 passen.
Jetzt wäre eigentlich ein guter Zeitpunkt um (Software-) Wünsche zu
äußern. Gerne auch ausgefallene oder anspruchsvolle Ideen. (außer
statisches RAM natürlich) ;-) Schließlich ist rund die Hälfe des
Flash-ROMs noch frei. Da ich nicht der Osterhase bin, kann ich die
Umsetzung natürlich nicht garantieren. Schon garnicht zum Fest.
Hier der aktuelle Stand für den Propeller. Wer noch keine Erfahrung
damit hat, der startet einfach das Hauptprogramm (propCOMM2_VGA.spin)
über F10 (läuft dann im RAM) oder F11 (wird in den EEPROM geladen).
Leo C. schrieb:> Jetzt wäre eigentlich ein guter Zeitpunkt um (Software-) Wünsche zu> äußern. Gerne auch ausgefallene oder anspruchsvolle Ideen. (außer> statisches RAM natürlich) ;-)
Osterwunsch :) Nutzung der beiden AD-Wandler (ADC6 und ADC7) Sie könnten
z.B. als 8 Bit Wandler laufen und über einen IN Befehl von einer festen
Adresse geladen werden.
Über den statischen RAM habe ich tatsächlich schon nachgedacht, doch
keine Sorge, nur bei unveränderter Pinbelegung. Mittels eines Latch und
RAS/CAS könnte man weiterhin wie gehabt adressieren, jedoch die
Refershzyklen einsparen. Damit sollte auch die Z80 Emulation schneller
laufen.
Joe G. schrieb:> Osterwunsch :)
2014 :)
> Nutzung der beiden AD-Wandler (ADC6 und ADC7) Sie könnten> z.B. als 8 Bit Wandler laufen und über einen IN Befehl von einer festen> Adresse geladen werden.
Sollten da nicht ein paar Parameter einstellbar sein? Vref, Betriebsart,
Sample rate?
> Über den statischen RAM habe ich tatsächlich schon nachgedacht, doch> keine Sorge, nur bei unveränderter Pinbelegung. Mittels eines Latch und> RAS/CAS könnte man weiterhin wie gehabt adressieren, jedoch die> Refershzyklen einsparen. Damit sollte auch die Z80 Emulation schneller> laufen.
Der Refresh dauert incl. IntAck max. 24 Takte und kommt bei 20Mhz alle
624 Takte. --> 3,85%
Leo C. schrieb:> Sollten da nicht ein paar Parameter einstellbar sein? Vref, Betriebsart,> Sample rate?
Gerne. Gerne auch 10 Bit. Nun wird jedoch wieder ein Protokoll nötig.
Mein Propeller will nicht abheben. :-(
Ich verwende die Linux Software bst (Brad's Spin Tool). Gestern Abend
habe ich aber auch mal die Windows Software (Spin Tool Software v1.3.2)
versucht. Die schenken sich nichts.
Für mich siehts so aus, daß der Propeller einfach nichts senden will.
Heute Morgen habe ich probeweise das EEPROM ausgelötet (Sockel hätte
wohl doch Vorteile gehabt) und den BOE-Pin auf VDD geklemmt. Ändert
alles nichts.
- FT232 funktioniert mit dem CP/M-Teil einwandfrei.
- Die Leiterbahnen vom Jumperfeld zum Propeller habe ich
durchgeklingelt. Verbindungen da, wo sie sein sollen. Keine
Kurzschlüsse.
- Resetpuls ca. (25µs) kommt am Propeller an. Die steigende Flanke sieht
merkwürdig aus, aber der Propeller scheint den Reset zu fressen.
- ca. 80ms später kommen Daten am RX-Pin des Propellers an.
- Am TX-Pin tut sich nichts. Wenn ich den Jumper ziehe, baumelt er um
0 Volt herum. Ein 100K Widerstand reicht, um ihn hoch zu ziehen, und
bei gestecktem Jumper zieht der FT232 ihn hoch.
- ca. 320ms nach Reset ist Aktivität auf dem I2C-Bus zum EEPROM. Also
hat der Propeller die Daten vom Host nicht erkannt, und versucht nun
sein Programm aus dem EEPROM zu laden.
Keine Ahnung, was ich noch versuchen könnte, außer Propeller tauschen.
:-(
Hier die richtige Skizze. In der ursprünglichen Skizze waren RX_Prop und
Tx_Prop vertauscht. Ursache ist ein Layoutfehler. Da alle Pins jedoch
auf das Steckfeld gehen (zum Glück) kann der Fehler durch die nun
richtigen Brücken korregiert werden.
Super! Da hast sich gerade unsere Post gekreuzt ;-)
Das EEPROM (Fassung ist gut) sollte wieder drauf. Ansosnten ist die
Software nach dem Reset gelöscht.
EEPROM ist wieder drauf. Jetzt mit Sockel. Funktioniert auch. Leider
geht die Tastatur (noch) nicht. Das kann jetzt alles mögliche sein. Die
habe ich vor ein paar Tagen zum Reinigen zerlegt und vielleicht falsch
zusammen gebaut.
Das Terminal verschluckt aber Zeichen. Beim Hochfahren des AVRs wird nur
die Hälfte der Meldungen angezeigt. Bei mir kommt da wg. 6 "Laufwerken"
ziemlich viel Text.
Wenn die Tastatur korrekt angeschlossen ist, sollten die 3 LEDs beim
Reset kurz aufblinken (Tastaturreset), tun sie das nicht, geht die
Initialisierung schon schief.
Das "verschlucken" von Zeichen liegt an der Kommunikation. Der Puffer
ist derzeit 256 Byte groß, reicht jedoch bei 115200 Baud offensichtlich
für deine Datenmenge noch nicht aus. Mal sehen was sich da machen läßt.
Die Tastatur geht jetzt auch. R16 und R17 waren vertauscht. Evtl. ein
Problem mit dem Bestückungsplan.
Ein paar Tasten gehen aber noch nicht so richtig.
"Backspace" macht seltsame Sachen
"+" auf dem Ziffernblock geht nicht.
"'" (Symbol über '#'): Dort scheint "`" (0x60) statt "'" (0x27) zu
kommen.
"{[]}" Eckige und geschweifte Klammern fehlen.
Joe G. schrieb:> Das "verschlucken" von Zeichen liegt an der Kommunikation.
Mit der noch nicht funktionierenden Tastatur hatte ich den interessanten
Effekt, daß die Bootmeldungen alle richtig kamen, wenn ich den
USB-Stecker (Stromversorgung) eingesteckt hatte. Beim Drücken der
Reset-Taste kamen nur die verstümmelten Meldungen. Mit der
funktionierenden Tastatur kommen jetzt nur noch verstümmelte Meldungen.
Der AVR-TXD-Leitung würde ein Pullup ganz gut tun. Wenn die Leitung am
Jumperfeld offen ist, reicht es, wenn ich mit der Hand nur in die Nähe
komme, damit der AVR verrückt spielt.
Nachtrag: Man kann natürlich auch den internen Pullup enablen. Werde ich
gleich mal machen.
Leo C. schrieb:> Evtl. ein Problem mit dem Bestückungsplan.
Danke, ich schau mal nach.
Leo C. schrieb:> Ein paar Tasten gehen aber noch nicht so richtig.
Müßte nun alles bis auf Ö, Ä und Ü gehen.
Joe G. schrieb:> Die gehen nun auch und jetzt ist Ostern!
Klammern gehen, Umlauts gehen, sogar die hier:²³
Die Backspacetaste spinnt aber noch und die Control-Codes gehen nicht.
Eilt aber alles nicht.
Leo C. schrieb:> "+" auf dem Ziffernblock geht nicht.
Die Taste ist kaputt.
Aber am CP/M-Computer brauche ich sie nicht unbedingt.
Moin Leo,
bin auch dabei die neue Platine aufzubauen. Prop-Terminal geht,
Tastatur geht auch. AVR lässt sich flashen, nur kommt nichts auf
der seriellen Schnittstelle. Übersetzt habe ich das avrcpm.asm
mit Studio4 mit folgenden Änderungen im Makefile:
#MCU = atmega88
MCU = atmega328
F_CPU = 20000000
DRAM_8BIT = 1
#BAUD = 57600
BAUD = 115200
I2C = 1
EM_Z80 = 1
FAT16_SUPPORT = 1
MMCBOOTLOADER = 0
Die Übersetzung lief ohne Fehler und Warnungen.
Fuses: kein div8, ext crystal osz
Hast Du ein Hexfile für mich, damit ich ein HW-Problem ausschliessen
kann?
Vielen Dank
Gruss
Peter
Peter Zabel schrieb:> MCU = atmega328
Das sollte atmega328*p* heißen. Ist aber egal, da 'config.inc' dann
trotzdem atmega328p genommen wird, was eigentlich ein Fehler ist aber
auch egal ist, da für die Software kein Unterschied, ob MCU mit oder
ohne 'P', falls es letzteren überhaupt gibt.
1
leo@cb:~/src/avr/CPM_auf_ATmega88/3.1/3.1/avr$ make clean all
avrcpm.asm(33): Including file 'C:/Programme/Atmel/AVR Tools/AvrAssembler2/Appnotes\m328Pdef.inc'
9
avrcpm.asm(35): Including file 'config.inc'
10
...
Allerdings geht bei mir 'make flash' damit nicht, da avrdude keinen
'atmega328' kennt.
Ansonsten läuft das Programm bei mir mit diesen Einstellungen.
ps: In trunk gibts eine neue Version, die gründlich getestet werden
müßte.
http://cloudbase.homelinux.net/viewvc/avr-cpm/avrcpm/trunk/avr/
Hallo Leo,
Dein hex-file lief zuerst auch nicht. PB0 und PB1 geprüft, sind mit
dem Steckerfeld verbunden. Reset nicht auf Masse. Dann habe ich gesehen,
dass ich Brownout aus alter Gewohnheit auf 4,3V gesetzt habe...
Mein hex-file läuft auch. Habe ich richtig gesehen, dass die I2C
Basisadressen auf 0x40 (RTC) und 0x80 (Par) liegen?
Jetzt muss ich erstmal überlegen, wie das mit der SD Erstellung war.
Ist schon länger her.
Gruss
Peter
Glückwunsch Peter.
Peter Zabel schrieb:> Habe ich richtig gesehen, dass die I2C> Basisadressen auf 0x40 (RTC) und 0x80 (Par) liegen?
Fast.
virt_ports.asm:
1
;------------------------ Wall Clock and Timers --------------------------
2
;40 in/out - Timer/Clock control.
3
;41-46
4
;
5
;47-4D clock - BCD format: ss, mm, hh, DD, MM, YYl, YYh
#define TIMERPORT 0x40 /* Base z80 port address for clock access */
4
#define TIMER_CTL TIMERPORT
5
#define TIMER_MSECS TIMERPORT+1
6
#define TIMER_SECS TIMER_MSECS+2
7
#define CLOCKPORT TIMERPORT+7 /* Real time clock BCD (ss,mm,hh,DD,MM,YYYY) */
8
9
#define starttimercmd 1
10
#define quitTimerCmd 2
11
#define printTimerCmd 15
12
#define uptimeCmd 16
Auf 40-46 liegt der Interrupt-Timer, den es schon fast von Anfang an
gibt.
Dieser kann z.B. mit dem Programm 'ACT' aus dem cpm/utils Verzeichnis
abgefragt und gesteuert werden.
Die RTC liegt auf 46-4D. Eigentlich auch eine Interrupt-Uhr. Nur das
Stellen beim Booten erfolgt über den RTC-Chip, sofern vorhanden. Für
diese Uhr gibt es einen ZSDOS-Treiber ('LDTIM.COM') und ein
ZSDOS-Programm zum steuern und abfragen ('TD.COM') [1].
Und dann gibt es noch [2]:
virt_ports.asm:
Im Anhang ist ein bootbares simhd-Image mit dem man die neue Hardware
testen kann. Im wesentlichen ist ZSDOS drauf (aber nicht ganz
vollständig), und ein paar Test- und Benchmarkprogramme.
Hallo Leo,
wenn ich Dein image mit dd auf die sd schreibe, dann mault dd, dass
nicht
genügend Speicher vorhanden ist und kopiert 1 Block weniger.
Die 8 MB habe ich vorher mit cfdisk erzeugt, Type 52. Bootflag gesetzt.
Die SD bootet zwar, zeigt aber no Files. Mit cpmls sehe ich sie aber im
image.
Muss ich die Partition grösser machen?
Gruss
Peter
Einfach das zip auspacken, und die Datei auf eine Karte mit Fat-16
Dateisystem kopieren. Hätte ich vielleicht dazu schreiben sollen.
Wenn von dem Image gebootet werden soll, sollten keine CP/M-Partitionen
vorhanden sein.
Hallo Leo,
ich sehe schon, es hat sich viel getan. Super Arbeit!
Mit RTCDemo konnte ich Datum und Uhrzeit stellen und auslesen.
Allerdings läuft die RTC ca. 17% zu schnell, sowohl eingeschaltet als
auch ausgeschaltet. Ich werde morgen mal den Quarz tauschen, obwohl
ich nicht daran glauben kann.
Vielen Dank für Deine Hilfe und Frohe Ostern.
Gruss
Peter
Peter Zabel schrieb:> Allerdings läuft die RTC ca. 17% zu schnell, sowohl eingeschaltet als
Hast Du einen Kondensator oder Trimmer an Pin 1 der RTC? Der wurde im
Layout vergessen. Siehe hier (ff):
Beitrag "Re: CP/M auf ATmega88"
Guten Morgen und Frohe Ostern.
Im Anhang ist was Neues zum Testen. Allerdings nur interessant, wenn man
einen Mega im 32 poligen Gehäuse (SMD) hat. Insbesondere die neue
Hardware von Joe G.
Joe G. schrieb:> Das VT100 kann nun auch CRTL-Codes, damit ist WS oder der Turbo Editor
Danke.
Das Meiste scheint zu funktionieren. Folgende Punkte sind mir
aufgefallen:
- 'Return' scheint ein "Auto-Linefeed" zu machen.
- 'Backspace' liefert "0xC8 0x08" statt 'DEL' (0x7F).
- Wenn auf der letzten Position einer Zeile (80) etwas ausgegeben wird,
geht der Curser automatisch in die nächtse Zeile. Wordstar mag das
nicht.
- 'Delete Line' und/oder 'Insert Line' funktioniert nicht richtig.
- Die Cursor-Tasten liefern keine VT-100-Codes, aber das ist nicht
unbedingt von Nachteil.
> zu bedienen. Den Quellcode gibt es vorerst hier...> https://code.google.com/p/avr-cpm-system/
Was heißt vorerst, und wieso so weit weg?
Danke für die Hinweise.
Leider zeigen sich bei der Umsetzung der Codes Unterschiede zwischen
VT100 und den gewohnten MSDOS Funktionen. Wir sollten einen guten
Kompromiss finden.
Beispiel:
Backspace VT100 = Cursor links, Zeichen bleibt stehen
Backspace MSDOS = Cursor links, Zeichen löschen, nachfolgende Zeichen
nach links schieben
DEL MSDOS = Zeichen an Cursorposition löschen, nachfolgende Zeichen nach
links schieben (Vorwärtslöschung)
Hier mein Vorschlag:
BS mit VT100 Funktion 0x08
DEL mit VT100 Funktion 0x7F
Joe G. schrieb:> Schaut mal ob WS nun mit VT100 bei euch läuft. Der Turbo Editor geht nun> bei mir. Es fehlen nur noch die Farbattribute.
Bei mir werden wieder (oder immer noch) Zeichen verschluckt. Ich hätte
schwören können, daß das mit V05 weg war. Jetzt habe ich die noch mal
geladen, war aber leider nicht besser. In meiner Verzweiflung bin ich
jetzt mal auf 9600 Baud gegangen (Habe ich an meinem anderen System auch
gerade). Die Startup-Meldungen sind jetzt heil.
Kann es sein, daß die unterste Zeile beim Scrollen nicht mit hoch
geschoben wird?
Im Anhang ist ein Disk-Image mit ganz frisch konfiguriertem Wordstar
3.3. Das Higlight-Attribut ist auf "Inverse-Video" voreingestellt.
Ich habe jeweils 40 Zeilen eingestellt, und sonst nur noch:
WS.COM - Nur Terminal VT100 aus Menü ausgewählt.
WSE.COM - Zusätzlich die Escape-Sequenzen für "Delete Line" und "Insert
Line" konfiguriert.
Wenn man eine Datei öffnet, erscheint auf dem Bildschirm nur noch Salat.
Entweder ist Wordstar oder das Terminal abgestürtzt. Da es mit meiner
vorherigen WS-Version nicht so schlimm ist, kann es eigentlich nur an
dem Inverse-Attribut oder an den 40 Zeilen liegen. WS mit 40 Zeilen
läuft aber in der PC-Terminalemulation.
Danke für die Rückmeldung. Ich schaue mir am Freitag mal den Datenstrom
zwischen WS und VT100 an. Möglicherweise gibt es noch Codes die nicht
unterstützt sind. Das scrollen der letzten Zeile ist auch noch ein Bug.
Joe G. schrieb:> Leider zeigen sich bei der Umsetzung der Codes Unterschiede zwischen> VT100 und den gewohnten MSDOS Funktionen. Wir sollten einen guten
Man muß den ASCII-Code[1] DEL/0x7F und die Taste[2] Delete/Del/Entf
auseinander halten. Außerdem ist die Ecke ist aus historischen Gründen
etwas verkorkst. Schließlich wurde ASCII[0] für Fernschreiber mit
Druckwerk und Lochstreifenleser/stanze erfunden.
CP/M 2.2 unterstützt die Teletype auch noch: ASCII DEL, bzw Rubout
(0x7F) gibt das letzte Zeichen einfach noch mal aus und löscht es im
Input-Buffer[3]. ZSDOS hat aufgeräumt: "The delete key has been fixed so
that Rubout acts like Backspace instead of echoing the deleted
character."[4]
> Hier mein Vorschlag:> BS mit VT100 Funktion 0x08> DEL mit VT100 Funktion 0x7F
Wordstar macht es so:
BS (0x08, ^H) - Curser nach links bewegen.
DEL (0x7F) - Zeichen links vom Curser löschen.
^G - Zeichen an Curserposition löschen, also das, was man
am PC üblicherweise mit der Del-Taste machen will.
In der ANSI-Emulation unter Linux sendet die DEL-Taste eine 4 Zeichen
lange Escape-Sequenz (^[[3~), so wie alle Tasten des Curserblocks.
Deshalb habe ich weiter oben geschrieben, das man an der Stelle das
ANSI-Verhalten vielleicht garnicht haben möchte. Unter Turbopascal kann
mans imho verwenden. Mit Wordstar aber eher nicht. Sogar DEL/BS patchen
ist schon etwas aufwendig.
[0] https://en.wikipedia.org/wiki/ASCII "Since the delete code often
produced a backspace effect, this also forced terminal manufacturers
to make any Delete key produce something other than the Delete
character." [5]
[1] https://en.wikipedia.org/wiki/Delete_character
[2] https://en.wikipedia.org/wiki/Delete_key
[3] http://www.cpm.z80.de/manuals/cpm22-m.pdf Seite 5-16
[4] http://www.gaby.de/ftp/pub/cpm/znode51/specials/zsdossrc/zsdos3.zip
Seite 19, auch als PDF [6]
[5] https://en.wikipedia.org/wiki/ASCII#cite_note-bsp_del_mismatch-45
[6] http://www.gaby.de/ftp/pub/cpm/znode51/specials/zsdossrc/zsdos.pdf
Glückwunsch.
Wenn jetzt noch die "<" vom linken zum rechten Rand wandern...
Leider habe ich gerade Hardwareprobleme. Daher komme ich vorerst nicht
zum Testen.
Leo C. schrieb:> Wenn jetzt noch die "<" vom linken zum rechten Rand wandern...
Stimmt, sieht nicht schön aus ;-) Ist behoben.
Da der Propeller noch viele Pins frei hat, könnte ein Pin ein Piezo
Beeper bekommen. Damit würde auch ein BEL ausgegeben werden. Weiterhin
ist mit einem weiteren freien Pin ein AVR Reset möglich. Damit könnte
über eine Taste (z. B. F12) ein AVR Reset ausgeführt werden. Die Taste
F1 ist derzeit mit einem Terminal Reset belegt (ganz nützlich wenn das
Terminal derzeit noch Fehlfunktionen zeigt). Hier könnten wir uns auch
eine zugeordnete Taste überlegen (F11 ??). Übrigens, Alt Break steht
noch auf meiner Liste.
Gestern Abend habe ich mal die Sonntag-Nachmittag-Version getestet.
Für Ladder reichts jetzt :-)
Ein kosmetisches Plus wäre die Möglichkeit, den Curser abzuschalten.
Auf dem Bild sieht man ihn an ca. 4 Stellen gleichzeitig. Das Original
VT-100 kann das zwar nicht, aber spätestens ab VT-220 gehts[1]:
1
4.6.7 Text Cursor Enable Mode (DECTCEM)
2
Text cursor enable mode determines if the text cursor is visible.
3
You set and reset this mode as follows.
4
5
Mode Sequence Action
6
Set 9/11 3/15 3/2 3/5 6/8 Makes the cursor visible.
7
CSI ? 2 5 h
8
9
Reset 9/11 3/15 3/2 3/5 6/12 Makes the cursor not visible.
10
CSI ? 2 5 l
Joe G. schrieb:> Da der Propeller noch viele Pins frei hat, könnte ein Pin ein Piezo> Beeper bekommen. Damit würde auch ein BEL ausgegeben werden. Weiterhin
Gut.
> ist mit einem weiteren freien Pin ein AVR Reset möglich. Damit könnte> über eine Taste (z. B. F12) ein AVR Reset ausgeführt werden. Die Taste> F1 ist derzeit mit einem Terminal Reset belegt (ganz nützlich wenn das> Terminal derzeit noch Fehlfunktionen zeigt). Hier könnten wir uns auch> eine zugeordnete Taste überlegen (F11 ??).
Ich hatte schon mal den umgekehrten Weg angedacht: Propeller-Reset durch
AVR auslösen, um über CP/M ein neues Propeller-Programm zu laden. Da am
AVR aber gar keine Pins mehr frei sind, könnte man vielleicht beide
Resets gleichzeitig auslösen...
Reichen die freien Pins auch noch für einen seriellen oder parallelen
Druckerport? Die Frage/der Vorschlag ist höchstens halb Ernst gemeint,
da diese Erweiterung einfacher über I2C realisierbar wäre.
> Übrigens, Alt Break steht noch auf meiner Liste.
Gut. Inspiriert vom Linux Magic SysRq [2] möchte ich die
Break-Funktion bei Gelegenheit auch noch etwas ausbauen.
Nachtrag:
Die nostalgische Farbe ist ja verschwunden. Naja, "richtige" VT-100 sind
auch schwarz/weiß, und demnächst wird man die Farbe wahrscheinlich
selbst einstellen können.
[1] http://vt100.net/docs/vt220-rm/chapter4.html#S4.6.7
[2] http://en.wikipedia.org/wiki/Magic_SysRq_key
Leo C. schrieb:> Ein kosmetisches Plus wäre die Möglichkeit, den Curser abzuschalten.
Ein später Hinweis, aber noch nicht zu spät ;-) Bisher wird der Cursor
immer in den jeweiligen Routinen gesetzt.
Leo C. schrieb:> Da am> AVR aber gar keine Pins mehr frei sind, könnte man vielleicht beide> Resets gleichzeitig auslösen...
Dazu Kompromissvorschlag. Für einen Sotwaretest sind beide unabhängigen
Restfunktionen ganz nützlich. Ich lege jedes Reset auf einen getrennten
Pin am Propeller und per Software kann man sich die jeweilige
Konfiguration wählen. Etwa so:
Variante Reset AVR Reset Propeller Taste
1 x F11
2 x F12
3 x x F12
Leo C. schrieb:> Reichen die freien Pins auch noch für einen seriellen oder parallelen> Druckerport?
Die Pins würden reichen. Tatsächlich habe ich auch schon darüber
nachgedacht. Mir viel jedoch bisher keine sinnvolle Lösung zur Kopplung
VT100 – CP/M – COM oder PRT ein.
Leo C. schrieb:> Gut. Inspiriert vom Linux Magic SysRq [2] möchte ich die> Break-Funktion bei Gelegenheit auch noch etwas ausbauen.
Wirklich nett!
Leo C. schrieb:> Nachtrag:> Die nostalgische Farbe ist ja verschwunden. Naja, "richtige" VT-100 sind> auch schwarz/weiß, und demnächst wird man die Farbe wahrscheinlich> selbst einstellen können.
genau
Joe G. schrieb:> Dazu Kompromissvorschlag. Für einen Sotwaretest sind beide unabhängigen> Restfunktionen ganz nützlich. Ich lege jedes Reset auf einen getrennten> Pin am Propeller und per Software kann man sich die jeweilige> Konfiguration wählen. Etwa so:> Variante Reset AVR Reset Propeller Taste> 1 x F11> 2 x F12> 3 x x F12
Ich weiß nicht, ob sich der ganze Aufwand überhaupt lohnt. Die Idee, den
Propeller durch den AVR zu resetten, kam mir, weil das Umstecken der
Jumperkabel so umständlich war. Inzwischen geht das aber, und bei
Gelegenheit werde ich einen Schalter dran bauen.
Ich dachte, man kann sich das Umstecken sparen, wenn man den Propeller
vom CP/M aus programmiert. Da der AVR dann aber keine Verbindung zu
einem PC hat, und das programmieren aus dem Reset heraus starten müßte,
macht die Sache wohl nur mit einem Bootloader Sinn, der das
Propellerprogramm von der SD-Karte lädt. Alles in allem ziemlich viel
Aufwand.
>> Reichen die freien Pins auch noch für einen seriellen oder parallelen>> Druckerport?>> Die Pins würden reichen. Tatsächlich habe ich auch schon darüber> nachgedacht. Mir viel jedoch bisher keine sinnvolle Lösung zur Kopplung> VT100 – CP/M – COM oder PRT ein.
Auf Terminalseite so:
Printer 9/11 3/5 6/9 Turns on printer controller mode.
4
Controller CSI 5 i
5
6
9/11 3/4 6/9 Turns off printer controller mode.
7
CSI 4 i
8
9
The terminal sends received characters to the printer without displaying them on the screen.
10
All characters and character sequences except NUL, XON, XOFF, CSI 5 i, and CSI 4 i are sent
11
to the printer. The terminal does not insert or delete spaces, provide line delimiters, or
12
select the correct printer character set. Printer controller mode has a higher priority than
13
auto print mode. You can select printer controller mode during auto print mode.
14
15
In printer controller mode, keyboard activity continues to be directed to the host.
Auf CP/M-Seite kann man dann z.B. ein extra Druckprogamm schreiben. Da
auf CP/M ja immer nur ein Programm laufen kann, gibts keine Konflikte
mit der Console. Eigentlich würde man aber gerne einen Treiber im BIOS
haben wollen, der die Druckerausgabe in den Consolendatenstrom einfügt.
Damit das ohne Verklemmungen in jeder Situation einwandfrei
funktioniert, dürfte der Aufwand erheblich sein.
Wahrscheinlich ist es viel einfacher, eine parallele oder serielle
Druckerschnittstelle an I2C zu klemmen. Die Serielle könnte zudem für
andere Zwecke genutzt werden.
Es gibt für das VT100 neue Funktionen.
- Cursor unsichbar schalten wie VT220 (für Spieler)
- inverse Zeichendarstellung
- setzen der Vordergrund- und Hintergrundfarbe
- Pfeiltastenfunktion
Alle derzeit realisierten Funktionen sind im VT100.pdf beschrieben.
Code und PDF hier:
http://www.mikrocontroller.net/svnbrowser/avr-cp-m/
Der Bildschirm ist wieder grün. ;-)
Invers funktioniert. Den Rest habe ich noch nicht getestet.
Ist Dir der Fehler im Wordstar Hauptmenü schon aufgefallen?
Bei der Überschrift des Directories fehlt der erste Buchstabe:
Schaltet man mit 'F' das Dir aus und wieder an, ist Der Buchstabe da.
Wechselt man das Laufwerk mit 'L' fehlt der Buchstabe wieder.
Der Fehler ist ab Revision 66 zu sehen. Mit r65 gehts noch.
Joe, hast Du eigentlich mein Posting vom 31.3. (Ostern) gesehen?
Leo C. schrieb:> Bei der Überschrift des Directories fehlt der erste Buchstabe:
Danke!
Es scheint ein Timing Problem zu sein. Direkt vor der Ausgabe von
"Directory" wird die Sequenz ESC[11;01H ausgeführt. Wenn sie fertig ist,
der Cursor an der richtigen Stelle steht, ist das "D" schon aus dem
Puffer. :-( Mal sehen ob ich die Geschwindigkeit noch etwas erhöhen
kann. Spin ist recht langsam in der Ausführung.
Leo C. schrieb:> Joe, hast Du eigentlich mein Posting vom 31.3. (Ostern) gesehen?
Ja, habe ich gesehen und leider noch nicht getestet (ADC). Ist jedoch
als nächstes auf dem Plan. In diesem Zusammenhang gleich eine Frage an
alle.
Nach Rücksprache mit der Redaktion der Zeitschrift FUNKAMATEUR würden
sie uns Platz für einen Beitrag zum CP/M System einräumen (2 Seiten).
Dazu sind natürlich externe Anwendungen wünschenswert und der ADC zählt
ganz sicher dazu. Weiterhin würde ich ein LCD Display mal über I2C
ankoppeln bzw. den Franklin Light Sensor aus einem anderen Beitrag hier
im Forum. Welche Ideen hättet ihr noch?
Für den Beitrag im FA würde ich die Schaltung und das Layout auch
nochmals anpassen. Auch hier sind Korrekturen und Wünsche willkommen.
Die folgenden Wünsche stehen schon auf meiner Liste.
- Stützbatterie statt Goldcap
- korrektes Layout für RTC
- LED an SD Card
- Pull Up an SD Card
- Piezo für Bell Signal vom Propeller
- AVR Reset vom Propeller
Um die vielen DRAM Varianten zu integrieren, könnte auf der Leiterplatte
einfach eine DIL Fassung für einen (Norm)RAM vorgesehen werden. Auf
einer kleinen Zusatzplatine kann dann jeder seinen vorhandenen RAM
auflöten und in die DIL Fassung stecken.
Joe G. schrieb:> Es scheint ein Timing Problem zu sein.
Scheint mir eher nicht so. Bei 9600 ist das Problem auch noch. Bei 80MHz
hat der Spin-Interpreter dann immerhin 80000 Takte pro Zeichen. Ich
wollte gerade noch langsamer testen, aber bei 4800 Baud funktioniert
unsere Soft-UART (RX) nicht mehr. :(
> Ja, habe ich gesehen und leider noch nicht getestet (ADC). Ist jedoch> als nächstes auf dem Plan.
Das Ganze war ein Schnellschuß zum Probieren und als
Diskussionsgrundlage. Erweiterung auf 10 Bit wäre kein Problem. Die
Temperatur- und VCC-Messung würde ich wieder raus werfen.
> Nach Rücksprache mit der Redaktion der Zeitschrift FUNKAMATEUR würden> sie uns Platz für einen Beitrag zum CP/M System einräumen (2 Seiten).> Dazu sind natürlich externe Anwendungen wünschenswert und der ADC zählt> ganz sicher dazu. Weiterhin würde ich ein LCD Display mal über I2C> ankoppeln bzw. den Franklin Light Sensor aus einem anderen Beitrag hier> im Forum. Welche Ideen hättet ihr noch?
Nützliche Aufgaben für das Gerät fallen mir eigentlich nicht ein. ;-)
> - Stützbatterie statt Goldcap> - korrektes Layout für RTC
+ C, bzw. Trimmer an OSCI
> Um die vielen DRAM Varianten zu integrieren, könnte auf der Leiterplatte> einfach eine DIL Fassung für einen (Norm)RAM vorgesehen werden. Auf> einer kleinen Zusatzplatine kann dann jeder seinen vorhandenen RAM> auflöten und in die DIL Fassung stecken.
Oh je. Was wäre denn ein (bzw. das) Norm-RAM?
> aber bei 4800 Baud funktioniert unsere Soft-UART (RX) nicht mehr. :(
Geht jetzt ab 2400 Baud.
Noch langsamer ist zusätzliche Arbeit, die ich mir jetzt spare.
Der Fehler mit Wordstar ist auch mit 2400 noch da. Wordstar schreibt
erst das Directory, dann die Überschrift-Zeile "directory of disk A:",
und dann wird die Zeile darüber gelöscht. Dabei, oder danach, wird das
'd' gelöscht.
Ich bin schon auf der Suche und habe die Sequenz abgespeichert. Erst
wird alles korrekt geschrieben und dann der Cursor an die Stelle von "d"
gesetzt und gelöscht, ich bleibe dran...
Anbei die überarbeitete Schaltung. Folgende Änderungen sind
eingeflossen:
- Stützbatterie CR2032 für RTC
- korrektes Layout für RTC
- LED an SD Card
- Pull Up an SD Card
- Piezo für Bell Signal vom Propeller
- AVR Reset vom Propeller
- Trimmer für RTC
- Layout für SD-Slot von Attend (erhältlich bei Pollin)
Gibt es nöch Änderungen oder Wünsche?
ADC 0x17 bis 0x21
Nun habe ich endlich auch mal die beiden ADC Wandler mit der Testversion
überprüft.
0x17 und 0x18 gehen gut,
0x20 und 0x21 auch,
0x19 (Temperatursensor) habe ich nicht begriffen. Was hast du dort
angeschlossen, einen PT100?
Noch ein Vorschlag zur Erweiterung des Z-System Timers. Könnte man nicht
gleich mit LDTIM die Zeit aus der RTC übernehmen? Das Stellen mit TD
würde dann entfallen.
Nachtrag:
Die Definition von cr und lf ist jetzt in BIOS.MAC. Mit dieser
Konfiguration kann jedoch IPL.MAC nicht übersetzt werden, da die
Definition dort fehlt.
Sorry für so spät, z.Zt. komme ich zu fast nichts.
Joe G. schrieb:> Anbei die überarbeitete Schaltung. Folgende Änderungen sind> eingeflossen:>> - Stützbatterie CR2032 für RTC
Siehe 1. Bild. D2 kann eine Silizium-Diode sein. Wenn der Platz knapp
ist, kann man für D1/D2 eine Doppeldiode (BAV170) nehmen. [1]
> - korrektes Layout für RTC> - Trimmer für RTC
Weiter oben hatte ich mal vorgeschlagen, an Pin 3 und Pin 7 Pullups
vorzusehen, damit man wahlweise auch den PCF8563 einsetzen kann. Da wir
aber weder mit INT noch mit CLKOUT etwas anfangen können (außer evtl.
für Testzwecke), sind die Pullups nicht notwendig. Den 8563 könnte man
auch so einlöten, wenn er denn im gleichen Gehäuse wäre. :-( (SOT96-1
vs. SOT176-1)
[1] http://www.nxp.com/documents/user_manual/UM10301.pdf
Joe G. schrieb:> ADC 0x17 bis 0x21>> Nun habe ich endlich auch mal die beiden ADC Wandler mit der Testversion> überprüft.> 0x17 und 0x18 gehen gut,
Es gibt dort weniger Parameter zum Einstellen, als ich ursprünglich
dachte. Als Referenz kommt ja eigentlich nur Vcc in Frage.
Man könnte die Abfrage auch auf 10 Bit erweitern.
> 0x20 und 0x21 auch,
Bringt aber nix, da wegen Streuungen der internen Referenz ein Abgleich
notwendig ist. Dann kann man auch gleich die Vcc genau ausmessn.
> 0x19 (Temperatursensor) habe ich nicht begriffen. Was hast du dort> angeschlossen, einen PT100?
Dort ist ein interner Sensor angeschlossen. Siehe entsprechendes Kapitel
im Datenblatt (Anhang).
Bringt aber auch nix. Der Sensor hat starke Exemplarstreuungen und muß
abgeglichen werden (Parameter im EEPROM?). Wer den ganzen Aufwand nicht
scheut, kann auch gleich statt eines CP/M-Programms den AVR
programmieren.
> Noch ein Vorschlag zur Erweiterung des Z-System Timers. Könnte man nicht> gleich mit LDTIM die Zeit aus der RTC übernehmen? Das Stellen mit TD> würde dann entfallen.
Bei mir funktioniert es so:
- Beim Einschalten wird die Zeit aus der RTC als Systemzeit übernommen.
- Wenn die RTC vorher schon mal gestellt wurde, und die Standby-
Stromversorgung durchgehalten hat, stimmt die Uhrzeit jetzt.
- Während des Betriebs wird die Systemuhr über einen Timer-Interrupt
aktualisiert.
- Durch LDTIM wird die Uhr für ZSDOS (zB. für Timestamps) zugänlich
gemacht. Sie kann anschließend über TD abgefragt oder neu gestellt
werden.
- Wenn die Systemuhr durch TD gestellt wird, wird die neue Zeit auch in
die RTC kopiert.
Meiner Meinung nach also genau so, wie Du es gerne hättest. Falls es bei
Dir anders ist, brauche ich eine genaue Beschreibung.
LDTIM lädt den Treiber z.Zt. unter den CCP. Dadurch funktioniert der
Warmstart nicht mehr wie vorgesehen, und es gibt Probleme beim Wechseln
der SD-Karte. Den Uhrentreiber will ich bei Gelegenheit ins BIOS
verfrachten, aber das Warmstart-Problem bleibt, wenn z.B. andere
residente Programme geladen werden.
Joe G. schrieb:> Ab der Version 3.1 scheint in der CFGACPM.LIB> cr equ 13> lf equ 10> verloren gegangen zu sein.
Das sind ja keine für AVR-CP/M systemrelevanten Konstanten.
Joe G. schrieb:> Die Definition von cr und lf ist jetzt in BIOS.MAC. Mit dieser> Konfiguration kann jedoch IPL.MAC nicht übersetzt werden, da die> Definition dort fehlt.
Dann werde ich die auch in IPL.MAC definieren. Danke für den Hinweis.
Ich bin nun auch mal wieder dazu gekommen am System zu arbeiten.
- Die RTC geht im CP/M korrekt, war mein Fehler, ich hatte nicht die
korrekte BIOS Version auf meiner Card
- BEL, 07h, ^G ist implementiert (siehe Schaltungserweiterung)
- CP/M Reset ist implementiert (Taste F12) (siehe Schaltungsänderung)
Wer sich noch an den Aufbau wagen möchte, ich habe noch einige Platinen
hier liegen.
Das VT100 Terminal hat nun einen Arbeitsstand erreicht, der es gestattet
die Version 1.0 zu vergeben. Es sind nun alle ESC Farbsequenzen für
Vorder- und Hintergrundfarbe implementiert sowie die gestern erwähnten
Funktionen BEL und CP/M Reset. Weiterhin gibt es noch eine „hot key“
Taste (Alt+i) die von der normalen auf die inverse Textfunktion schaltet
und wieder zurück.
Wünsche und Fehler nehme ich gerne entgegen.
Hallo Gemeinde!
Erstmal vielen Dank, für die viele Arbeit, die bereits in das Projekt
gesteckt wurde!
Ich würde den CP/M-Emulator gerne nachbauen, um auch mal in den Genuß
eines Klassikers zu kommen.
Ich habe mir den kompletten Thread durchgelesen (was schon alleine
mehrere Abende gedauert hat...)
und versuch mal zu rekapitulieren:
* Z80-Emulation läuft mit ca. 2 MHz bei 20 MHz AVR-Frequenz
* CP/M und ZSDOS
* Zugriff auf SD-Karte mit FAT16 Filesystem
* Terminal mit Propeller (80x25?) und PS/2-Tastatur oder wahlweise per
USB
zusätzlich gibt es einen I2C-Anschluß, an dem bisher eine
Real-Time-Clock hängt.
Ist das soweit richtig?
Dann zu meinen Vorstellungen:
Als DRAM's habe ich hier noch folgende Chips gefunden:
HYB514256-AJ-70 256k x 4Bit
KM44C1000AJ-7 1M x 4Bit
HYB511000AJ-70 1M x 4Bit
Wenn ich den HYB514256 verwende ist die Speicheraufteilung die folgende:
62k RAM
2k System
192k RAM-Disk
Da die HYB514256 lt. Thread nicht bei allen funktioniert haben bleibt
als Alternative noch die 1M x 4Bit Chips. Wird in diesem Fall eine
größere RAM-Disk angelegt oder 'verfällt' der RAM, weil die
Adressleitungen fehlen?
@Joe:
Wäre es möglich den letzten Stand der Schaltung zu veröffentlichen?
Ich würde mir die Platine gern etwas umgestalten, da ich sie gleich auf
einer alten PS/2-Tastatur montieren möchte.
Außerdem würde ich gleich noch ein (Text-)Display und ein kleines
Soundmodul integrieren bzw. passende Anschlußmöglichkeiten dafür
vorsehen.
Sehe ich das richtig, daß der Pegelwandler zur SD-Karte weggefallen ist
und jetzt alles auf 3,3V läuft?
Wo bezieht man denn den Propeller-Chip am günstigsten?
Schön wäre ja die Lösung mit dem AVR gewesen (wie die Variante 2), aber
da ließ sich offenbar die nötige Auflösung von 80x24 und die
PS/2-Ansteuerung nicht vernünftig realisieren.
Programmiert wird der Propeller via serieller Schnittstelle? Ist da
schon ein Bootloader drin? Der Programmspeicher scheint extern zu sein,
oder wofür ist der I2C-EEPROM (AT24C512) da?
Das sollten erstmal genug Fragen sein ;-)
Viele Grüße
Jens
Jens schrieb:> Hallo Gemeinde!
Willkommen im Club.
(Auch wenn die Gemeinde sich etwas verlaufen zu haben scheint :)
> und versuch mal zu rekapitulieren:>> * Z80-Emulation läuft mit ca. 2 MHz bei 20 MHz AVR-Frequenz
Es sind inzwischen eher 3 MHz. Vielleicht sogar etwas mehr. [1]
> * CP/M und ZSDOS> * Zugriff auf SD-Karte mit FAT16 Filesystem> * Terminal mit Propeller (80x25?) und PS/2-Tastatur oder wahlweise per> USB> zusätzlich gibt es einen I2C-Anschluß, an dem bisher eine> Real-Time-Clock hängt.
+ 8-Bit Parallelport über PCF8574> Ist das soweit richtig?
Wenn wir über die letzte Leiterplatte von Joe G. reden, ja.
> Dann zu meinen Vorstellungen:> Als DRAM's habe ich hier noch folgende Chips gefunden:> HYB514256-AJ-70 256k x 4Bit> KM44C1000AJ-7 1M x 4Bit> HYB511000AJ-70 1M x 4Bit>> Wenn ich den HYB514256 verwende ist die Speicheraufteilung die folgende:> 62k RAM> 2k System> 192k RAM-Disk
256K x 4-Bit: Da bleiben nur 64K für die RAM-Disk.
> Da die HYB514256 lt. Thread nicht bei allen funktioniert haben bleibt> als Alternative noch die 1M x 4Bit Chips. Wird in diesem Fall eine> größere RAM-Disk angelegt oder 'verfällt' der RAM, weil die> Adressleitungen fehlen?
Wir haben 11 Adressleitungen. Das reicht bis 4 MByte.
Allerdings ist die RAM-Disk ziemlich uninterressant, da sie nicht
schneller als die SD-Karte ist. Ich weiß noch nicht mal, ob sie in der
aktuellen Software überhaupt noch funktioniert.
> Sehe ich das richtig, daß der Pegelwandler zur SD-Karte weggefallen ist> und jetzt alles auf 3,3V läuft?
Pegelwandler waren noch nie nötig, da ja alles mit 3,3V läuft.
> Programmiert wird der Propeller via serieller Schnittstelle? Ist da> schon ein Bootloader drin? Der Programmspeicher scheint extern zu sein,> oder wofür ist der I2C-EEPROM (AT24C512) da?
So ist es.
[1] :
Vor einigen Monaten hatte ich mal mit ein paar Benchmarks angefangen
(Dhrystone und ähnliches). Leider bin ich nicht fertig geworden und habe
keine fertigen Ergebnisse. Eine Tabelle mit den Ausführungszeiten
einzelner Befehle, habe ich aber noch gefunden:
>> * Z80-Emulation läuft mit ca. 2 MHz bei 20 MHz AVR-Frequenz> Es sind inzwischen eher 3 MHz. Vielleicht sogar etwas mehr. [1]
Gut. Ich denke das ist mir ausreichend schnell am Original Z80.
[Hardwarestand]
> Wenn wir über die letzte Leiterplatte von Joe G. reden, ja.
Ja, siehe Post vom 4.5.2013
(Beitrag "Re: CP/M auf ATmega88")
>> Dann zu meinen Vorstellungen:>> Als DRAM's habe ich hier noch folgende Chips gefunden:>> HYB514256-AJ-70 256k x 4Bit>> KM44C1000AJ-7 1M x 4Bit>> HYB511000AJ-70 1M x 4Bit>> 256K x 4-Bit: Da bleiben nur 64K für die RAM-Disk.
Ist denn die 4-Bit-Variante genauso schnell, wie die 8-Bit-Variante (mit
2 Chips)? (Ich hab mehrere Chips zur Verfügung, leider nix mit 8-Bit
Datenbreite.)
> Wir haben 11 Adressleitungen. Das reicht bis 4 MByte.> Allerdings ist die RAM-Disk ziemlich uninterressant, da sie nicht> schneller als die SD-Karte ist. Ich weiß noch nicht mal, ob sie in der> aktuellen Software überhaupt noch funktioniert.
Ok. Also mehr als 256kByte ist vorerst nicht sinnvoll.
>> Sehe ich das richtig, daß der Pegelwandler zur SD-Karte weggefallen ist>> und jetzt alles auf 3,3V läuft?> Pegelwandler waren noch nie nötig, da ja alles mit 3,3V läuft.
In der Version 2 (im Wiki), ist ein 74HCT08 zur SD-Karte verzeichnet.
Wenn nur mit 3,3V gearbeitet wurde, könnte das die Probleme mit dem
HYB514256 erklären.
Laut Datenblatt des HYB514256B/BJ ist er für 5V Vcc spezifiziert.
Apropos, hat jemand das Datenblatt zum HYB514256A/AJ?
>> Programmiert wird der Propeller via serieller Schnittstelle? Ist da>> schon ein Bootloader drin? Der Programmspeicher scheint extern zu sein,>> oder wofür ist der I2C-EEPROM (AT24C512) da?> So ist es.
Welche Größen darf der EEPROM haben? Gibt es eine Mindestgröße für die
Verwendung als VGA-Terminal? Wie kommen die Daten in den EEPROM? Gibt es
da einen Bootloader im Propeller? Ist der schon drin?
Viele Grüße
Jens
Jens schrieb:> Ist denn die 4-Bit-Variante genauso schnell, wie die 8-Bit-Variante (mit> 2 Chips)? (Ich hab mehrere Chips zur Verfügung, leider nix mit 8-Bit> Datenbreite.)
UPS, natürlich sollte man 2 Chips nehmen. 4 Bit ist schon deutlich
langsamer. Dann Stimmt Deine Rechnung also.
> Welche Größen darf der EEPROM haben? Gibt es eine Mindestgröße für die> Verwendung als VGA-Terminal?
Joe?
Ansonsten Datenblatt besorgen. Ich kann grad schlecht nachschauen, weil
ich unterwegs bin.
> Wie kommen die Daten in den EEPROM? Gibt es> da einen Bootloader im Propeller? Ist der schon drin?
Ja ist drin. (So war das "So ist es." gemeint.)
Jens schrieb:> Hallo Gemeinde!Leo C. schrieb:> Willkommen im Club.> (Auch wenn die Gemeinde sich etwas verlaufen zu haben scheint :)
Auch von mir ein Willkommen!
(Ein Gemeindemitglied war im Urlaub ;-)
Jens schrieb:> @Joe:> Wäre es möglich den letzten Stand der Schaltung zu veröffentlichen?
Ja, das werde ich demnächst tun. Wenn du mir deine Kontaktdaten
zusendest, kannst du schon jetzt den aktuellen Stand erhalten.
Jens schrieb:> Programmiert wird der Propeller via serieller Schnittstelle? Ist da> schon ein Bootloader drin? Der Programmspeicher scheint extern zu sein,> oder wofür ist der I2C-EEPROM (AT24C512) da?
Korrekt, der Propeller enthält den entsprechenden Bootloader und dieser
kann über einen seriellen Port angesprochen werden.
http://en.wikipedia.org/wiki/Parallax_Propeller#Boot_mechanism
Auf der Platine ist es über die USB-Schnittstelle realisiert. Über sie
kann der Propeller programmiert werden oder die VT100 Ausgabe an ein
externes Terminal erfolgen.
Jens schrieb:> Welche Größen darf der EEPROM haben?
mindestens 32KB
Ok. Zum Propeller bin ich jetzt im Wesentlichen aufgeklärt :-)
Noch ein paar Fragen zum Design:
Ich würde gerne nur einen Quarzoszillator verwenden. Der Propeller wird
momentan mit 5 MHz betrieben und besitzt eine interne PLL.
Diese PLL kann den Eingangstakt um den Faktor 1, 2, 4, 8 oder 16
vervielfachen.
Ich kann im Quellcode vom Terminal (Repository und VT100_V05.zip) keine
Stelle finden, an der CLKSET aufgerufen wird. Ist da evtl. nicht alles
dabei?
Wie läuft das beim Propeller, gibt es da eine Art "main", wo festgelegt
wird in welchem COG welcher Code läuft?
Im Datenblatt ist ein ominöses top objekt file erwähnt. Wo finde ich
das?
Der ATmega328 wird auch außerhalb der Spezifikation betrieben.
Laut Datenblatt (Rev. 8271E), Grafik 29-1 und Tabelle 29-11, verlässt
man oberhalb von 13,3 MHz den sicheren Betriebsbereich bei einer
Betriebsspannung von 3,3 V.
Für 20 MHz Taktfrequenz sollte man den ATmega328 mit mindestens 4,5 V
betreiben.
Meine Speicherchips sind alle noch auf 30-Pin SIMM-Modulen verbaut.
Diese SIMM-Module sind ebenfalls für 5V Betriebsspannung spezifiziert.
Von daher wäre es schon sinnvoll den Speicher und den Controller mit 5V
zu versorgen, oder?
Viele Grüße
Jens
P.S.: Was spricht eigentlich dagegen SIMM-Fassungen zu verwenden? Da
müßte ich die Chips nicht erst ablöten.
Jens schrieb:> Ich kann im Quellcode vom Terminal (Repository und VT100_V05.zip) keine> Stelle finden, an der CLKSET aufgerufen wird.
In der Datei VT100_VGA.spin
CON
'clock configuration
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000 '5 MHz Quarz AVR CP/M
Jens schrieb:> Wie läuft das beim Propeller, gibt es da eine Art "main", wo festgelegt> wird in welchem COG welcher Code läuft?
Das "main"-File ist die besagte Datei VT100_VGA.spin
Die 5 MHz des Propeller sollten zunächst nicht verändert werden, da sie
den Pixeltakt sowie alle Timingsignale zur Synchronisation
bereitstellen. Die zugehörigen Konstanten befinden sich in der Datei
VGA_HiRes_Text_010.spin
Jens schrieb:> Für 20 MHz Taktfrequenz sollte man den ATmega328 mit mindestens 4,5 V> betreiben.
Bisher gab es bei keinem Nachbau damit Probleme. Viele Varianten laufen
auch mit 25 MHz oder höher. Ich denke Peter hat es sogar bis 30 Mhz
getrieben.
Die letzte Variante benutzt einen HM51W17805 als DRAM. Dieser ist für
3.3V spezifiziert.
Jens schrieb:> P.S.: Was spricht eigentlich dagegen SIMM-Fassungen zu verwenden?
Nichts, nur der Platz.
Joe G. schrieb:>> Ich kann im Quellcode vom Terminal (Repository und VT100_V05.zip) keine>> Stelle finden, an der CLKSET aufgerufen wird.>> In der Datei VT100_VGA.spin
Mein grep kann mit UTF-16 nix anfangen. Deshalb hat meine Suche nach
clk nichts gebracht...
> CON> 'clock configuration> _clkmode = xtal1 + pll16x> _xinfreq = 5_000_000 '5 MHz Quarz AVR CP/M
Also 16 * 5 MHz = 80 MHz.
Auf 80 MHz kommt man auch mit 4 * 20 MHz.
> Die 5 MHz des Propeller sollten zunächst nicht verändert werden, da sie
Wie gesagt, ich denke der Propeller läuft mit 80 MHz.
> Bisher gab es bei keinem Nachbau damit Probleme. Viele Varianten laufen> auch mit 25 MHz oder höher. Ich denke Peter hat es sogar bis 30 Mhz> getrieben.
Das mag ja sein, und ich möchte auch niemandem zu Nahe treten, aber in
meinen Augen ist das Murks.
> Die letzte Variante benutzt einen HM51W17805 als DRAM. Dieser ist für> 3.3V spezifiziert.
Jepp. Den hab ich aber nicht. (Im Gegensatz zu den SIMM-Modulen.)
>> P.S.: Was spricht eigentlich dagegen SIMM-Fassungen zu verwenden?> Nichts, nur der Platz.
Richtig, so richtig niedlich sind die nicht.
Auch ist bei SIMM das /OE nicht rausgeführt. Daher müßte man Adress- und
Datenbus trennen, was mehr Pins am AVR benötigt.
Siehe auch diesen Beitrag:
Beitrag "Re: 2MB DRAM an AVR"
Schade eigentlich.
Viele Grüße
Jens
Jens schrieb:> Auf 80 MHz kommt man auch mit 4 * 20 MHz.
Es ist natürlich möglich EINEN 20 MHz Oszillator zu verwenden und den
AVR und den Propeller damit zu takten.
Jens schrieb:> Das mag ja sein, und ich möchte auch niemandem zu Nahe treten, aber in> meinen Augen ist das Murks.
Sicherlich ist wieder eine getrennte Spannungsversorgung denkbar. In der
Variante 2 haben wir das ja auch so realisiert. Allerdings sind dann
Pegelwandler zwischen AVR und SD-Card und AVR und Propeller notwendig.
Auch kann die RAM-Konfiguration beliebig geändert werden. Da alle
Quellen offen sind, hast du hier freie Hand.
Hallo,
ich habe ein paar DRAMs gefunden:
5x MB81C4256A-70P
7x V53C104AP-80
als 20-Pin DIP. Vielleicht sind die ja für dieses Projekt kompatibel und
jemand kann sie brauchen.
Joe G. schrieb:> Stückpreis 0,55€ + Porto (0,70€ Warensendung)
Wäre bei mir wohl ähnlich...
Gruß, TS
Hallo zusammen
nach der ersten einfachen 8080-Version auf Lochraster habe ich nun dank
Joes Hilfe auch auf "seiner Platine" den Z80-Teil mit FTDI ans laufen
bekommen. VGA/Tastatur/RTC/PIO folgen demnächst.
Freundlicherweise hat mir Joe auch direkt ein 240k "Boot-Image" und ein
weiteres 8MB CPM Image gegeben, welche ich zusammen auf eine mit FAT16
formatierte SD-Karte kompiert habe.
Alles wunderbar - bin begeistert (auch wenn die Löterei der Horror war).
Nun habe ich aber noch ein paar Anfänger/DAU-Fragen:
CPMTools unter Linux:
- Habe die avrcpm-Definition eingetragen - die boot-Diskette wird sauber
ausgelesen
- Aber die 8MB Datei geht zwar unter CPM, die Tools zeigen aber nichts
an, fehlt mir hier eine file-Definition? Wie kann die dieses Image
bearbeiten?
- das erste Image lautet CPMDSK_A. -> ist LW A. das zweite CPMDSK_D ->
wird als LW B eingebunden - warum nicht als D?
FAT16
- wie groß darf ich die FAT16-Partition machen: 2GB oder 4GB?
- Muss die erste "Diskette" immer 243K haben oder kann die auch schon
8MB sein?
- Ist 8MB eine feste Obergrenze? Oder ginge auch mehr (quasi eine
Festplatten-Simulation)?
Herzlichen Dank!
Gruß
Marcel
Marcel Andre schrieb:> Hallo zusammen>> nach der ersten einfachen 8080-Version auf Lochraster habe ich nun dank> Joes Hilfe auch auf "seiner Platine" den Z80-Teil mit FTDI ans laufen> bekommen. VGA/Tastatur/RTC/PIO folgen demnächst.>> Freundlicherweise hat mir Joe auch direkt ein 240k "Boot-Image" und ein> weiteres 8MB CPM Image gegeben, welche ich zusammen auf eine mit FAT16> formatierte SD-Karte kompiert habe.>> Alles wunderbar - bin begeistert (auch wenn die Löterei der Horror war).>> Nun habe ich aber noch ein paar Anfänger/DAU-Fragen:>> CPMTools unter Linux:> - Habe die avrcpm-Definition eingetragen - die boot-Diskette wird sauber> ausgelesen> - Aber die 8MB Datei geht zwar unter CPM, die Tools zeigen aber nichts> an, fehlt mir hier eine file-Definition? Wie kann die dieses Image> bearbeiten?
Mein Fehler! Wer lesen kann.... Habe simhd ergänzt - alles klar :-)
> - das erste Image lautet CPMDSK_A. -> ist LW A. das zweite CPMDSK_D ->> wird als LW B eingebunden - warum nicht als D?>> FAT16> - wie groß darf ich die FAT16-Partition machen: 2GB oder 4GB?> - Muss die erste "Diskette" immer 243K haben oder kann die auch schon> 8MB sein?> - Ist 8MB eine feste Obergrenze? Oder ginge auch mehr (quasi eine> Festplatten-Simulation)?
Auch hier: 8MB ist offenbar die 8-bit "Systemgrenze" für CP/M. Na,
reicht ja auch :-)
> Herzlichen Dank!>> Gruß> Marcel
Das Format des 8MB Images ist das HD Format von AltairSIMH. Das hat den
Vorteil, dass man unter AltairSIMH wunderbar auf dem PC arbeiten kann
und diese Datei dann gleichzeitig unter unserem CP/M System laufen
lassen kann.
Das System welches derzeit gebootet wird ist tatsächlich ZSDOS. Alle
Quelldateien dazu befinden sich auf der 8MB HD. Um sich ein eigenes
System zusammen zu bauen musst du nur die Datei AVRCPM.SUP ausführen. In
ihr sind auch alle benötigten Quelldateien für das ZSDOS System
aufgeführt.
Die wichtigen Fragen sind ja schon beantwortet. Bleibt noch...
Marcel Andre schrieb:> - das erste Image lautet CPMDSK_A. -> ist LW A. das zweite CPMDSK_D ->> wird als LW B eingebunden - warum nicht als D?
Kurze Antwort:
Weil es so geworden ist ;-)
Und wir außerdem spätestens mit 'CPMDSK_Q.IMG' ein Problem hätten.
Längere Antwort:
Als Dateinamen für die Images sind 'CPMDSK_A.IMG' bis 'CPMDSK_Z.IMG'
erlaubt.
CP/M unterstützt maximal 16 Laufwerke, die über einen Index 0..15
verwaltet werden. Davon haben wir (bis auf weiteres) die letzten 8
(8..15, bzw I..P) für fest im BIOS definierte Laufwerke, z.B. RAM-Disks,
reserviert. Die ersten 8 (0..7, bzw. A..H) werden in aufsteigender
Reihenfolge duch die automatisch erkannten Diskimages belegt.
[3][5]
Natürlich könnte man das auch anders machen, wenns denn eine(r) macht...
> FAT16> - wie groß darf ich die FAT16-Partition machen: 2GB oder 4GB?
4G sollten gehen, da 128 Sectors/Cluster unterstützt werden [6].
> - Muss die erste "Diskette" immer 243K haben oder kann die auch schon> 8MB sein?
Wenn ich mich richtig erinnere, kann von allen unterstützten Formaten,
außer MYZ80, gebootet werden. simhd geht definitiv. [1][2][3]
> - Ist 8MB eine feste Obergrenze? Oder ginge auch mehr
Es gibt Erweiterungen, die mehr könnten.
CP/M 3 kann 512MB.
> (quasi eine Festplatten-Simulation)?
Hüstel.
Zu CP/Ms besten Zeiten waren Festplatten eher deutlich kleiner als 8 MB.
Zum Zeitpunkt der angehängten Anzeige gab es allerdings auch schon
IBM-PCs (kompatible) mit 10 MB Festplatte zum halben Preis dieser
Platte.
> Herzlichen Dank!> Gruß> Marcel
Ein Abschnitt zu Disk-Images im AVR CP/M-Artikel wäre nicht
schlecht. Damit könntest Du Deinem Dank noch stärkeren Ausdruck
verleihen. ;-)
Dazu auch noch die Hinweise [7] und [8].
Und noch ein allgemeiner Hinweis:
Die AVR-CP/M-Software enthielt lange Zeit einen Fehler, durch den bei
Image-Formaten mit Headern ungleich der physikalischen Sektorgröße (yaze
und simhd), Daten in falslche Sektoren geschrieben wurden. Der Fehler
wurde in r209 bzw. Version 3.2 behoben. Deshalb bitte keine älteren
Versionen benutzen, wenn man mit diesen Image-Formaten "arbeiten"
möchte.
[1] Beitrag "Re: CP/M auf ATmega88"
[2] Beitrag "Re: CP/M auf ATmega88"
[3] Beitrag "Re: CP/M auf ATmega88"
[4] Beitrag "Re: CP/M auf ATmega88"
[5] drvtbl in BIOS.MAC
[6] dsk_fat16.asm:
1
; Function: Cluster to HostSector
2
...
3
; ! Only works with Clustersizes 2,4,8,16,32,64,128 !
So. Ich hab jetzt mal einen Schaltplan mit den folgenden Besonderheiten
erstellt:
- SIMM-Module statt Einzel-DRAM-Chips, deswegen
- ein ATmega128 (ausreichend IO, war außerdem gerade im E-Schritt)
- SIMM und ATmega auf 5V, restliche Peripherie mit Pegelwandler auf 3,3V
- UART-Multiplexer per DIP-Switch und "ODER"-Gatter, damit PC und
PS/2-Tastatur ohne umzuschalten verwendet werden können
- I2C mit 3,3V und 5V auf 4-polige Leiste herausgeführt
- restliche IO vom Propeller-Chip herausgeführt, damit kann z.B.
Sound-IO nachgerüstet werden
- neben dem VGA-Ausgang ist auch noch ein Video-Ausgang vorhanden
- Text-Display und LEDs als Erweiterungen am I2C, können sowohl vom AVR
als auch vom Propeller angesteuert werden
Die Idee hinter der Sache ist die: ich möchte gern meine SIMM-Rigel
nicht wegen der zwei DRAM-Chips auseinandernehmen, sondern direkt
verwenden.
Außerdem scheint der Propeller ein recht interessanter Chip zu sein.
Leider ist das Eval-Board völlig überteuert. Daher habe ich die für mich
interessante Peripherie vom Propeller-Eval-Board hier mit drauf gepackt.
An den restlichen IOs kann man Erweiterungen nach Bedarf vornehmen.
Die Anschlüsse sind PMOD kompatibel.
Wer nicht basteln möchte kann sich da auch hier bedienen:
http://www.digilentinc.com/Products/Catalog.cfm?NavPath=2,401&Cat=9http://www.maximintegrated.com/app-notes/index.mvp/id/5468
Die UART-Schnittstelle soll mehrere Funktionen erfüllen:
- Debugging AVR (PC <-> AVR)
- Debugging Propeller (PC <-> Propeller)
- Normalbetrieb, AVR sendet -> Propeller und PC empfangen
Propller (PS/2) oder PC senden -> AVR empfängt
So. Nun muß ich mal sehen, wie ich das Ganze auf eine (oder mehrere)
Platine(n) bringe.
Wer mag, kann mal drüber schauen, auch wenn es etwas voll geworden ist.
Aber so kann ich es noch ausdrucken und komme mit Eagle-Freeware aus.
Viele Grüße
Jens
Da hast du ja viel Arbeit investiert!
Was mir beim flüchtigen Betrachten auffällt.
Der AVR läuft mit 5V, der FT232 und der Propeller mit 3.3V. Nun
verbindest du Tx und Rx mit diesen unterschiedlichen Pegeln (AVR –
Prop.)
Liegen die ungenutzten Tx-Pins immer auf High damit das „Oder“
funktioniert?
Die gänzlich andere DRAM-Beschaltung bedingt eine neue RAM-Ansteuerung,
die Verwendung der AVR UART ersetzt die Soft UART. Wenn schon so viele
Änderungen, warum denn nicht gleich ein XMEGA mit ordentlicher
DRAM-Beschaltung?
Fazit:
Was ist der Gewinn der neuen Schaltung? Außer vielen Softwareänderungen
kann ich keine Vorteile erkennen. Doch das ist meine ganz persönliche
Meinung, ich möchte dich nicht in deinem Elan bremsen.
Nachtrag:
Wenn es dir um die zwei Versorgungsspannungen und den RAM geht, schlage
ich folgende Lösung vor. Alles läuft weiter auf 3.3V und der AVR wird
halt langsamer getaktet. An den jetzigen „DRAM-Bus“ kommt eine
„Hardwareemulation“ für einen 3.3V SRAM. Der Adress- /Datenmultiplexer
kann über RAS/CAS geschaltet werden. Damit ändert sich in der
Ansteuerung nichts bis auf das Abschalten des Refresh was jedoch sowieso
nicht viel Zeit kostet [1].
[1] Beitrag "Re: CP/M auf ATmega88"
Joe G. schrieb:> Der AVR läuft mit 5V, der FT232 und der Propeller mit 3.3V. Nun> verbindest du Tx und Rx mit diesen unterschiedlichen Pegeln (AVR –> Prop.)
Da ist noch der Pegelwandler dazwischen (TXB0108).
> Liegen die ungenutzten Tx-Pins immer auf High damit das „Oder“> funktioniert?
Meines Wissens nach ist der Ruhezustand auf den UART-Leitungen '1'.
Aber ausprobiert habe ich das mit der "Veroderung" noch nicht.
> Die gänzlich andere DRAM-Beschaltung bedingt eine neue RAM-Ansteuerung,> die Verwendung der AVR UART ersetzt die Soft UART. Wenn schon so viele> Änderungen, warum denn nicht gleich ein XMEGA mit ordentlicher> DRAM-Beschaltung?
Der Mega128 ist mir zugeflogen und die SIMM-Rigel liegen rum. Die
RAM-Ansteuerung kann ich mir leicht anpassen (hoffentlich).
Ich habe zwar den UART auf die UART-Pins gelegt, aber dort kann ich auch
erstmal Soft-UART drauf machen, muß also den Code nicht zwingend ändern.
Außerdem wäre XMEGA für mich eine neue Architektur, die für mich auf
Dauer keinen Erkenntnisgewinn bringt. Abgesehen von evtl. benötigten
neuen Programmiergeräten.
> Fazit:> Was ist der Gewinn der neuen Schaltung?
Für mich oder für die Community?
Für mich sieht es so aus:
- Propeller ist neu
- SIMM-DRAM-Ansteuerung ist neu
- UART-Veroderung ist neu (aber wenn es geht komfortabel)
- CPM kenn ich noch nicht und
ich habe meinen ersten selbstgebauten Computer :-)
Für die Community kann ich nicht sprechen. Es ist eben eine weitere
Variante. Wie bei den Linuxdistributionen ;-)
Grüße
Jens
Zum Nachtrag: Ich hab mit zwei Versorgungsspannungen kein Problem, ich
möchte nur gern alle Bauteile laut Spezifikation betreiben.
Hallo,
habe nun den Propeller in Betrieb genommen. Nachdem ich in die Falle mit
dem vertauschten RX/TX erkannt hatte und noch einige kalte Lötstellen
ausgemerzt hatte, ging es (siehe Bilder).
Aber nur so zu 90%...
Das Problem der abgeschnittenen Ränder habe ich durch manuelle
Einstellung hinbekommen - der AUTO-Modes hats nicht geschafft :-)
In WS/TP werden z.B. keine CRTL-Codes erkannt. Es geht auch kein
"Löschen nach links" - auch nicht im "DOS-Prompt" usw.
Anderes Problem: Keine Farben (alles grün) und auch kein
Bildschirm-Löschen usw.... (siehe 2. Bild)
Wo sollte ich suchen? Da ja "grundsätzlich" alles geht würde ich fast
ein HW-Problem ausschliessen?
Im CPM->USB-Modus geht alles zu 99% (Farben nicht 100%, wahrscheinlich
Problem von Hyperterminal/Minicom/Putty).
Danke euch!
Gruß
Marcel
Hallo Marcel,
die aktuelle Softwareversion gibt es hier (Version 1.0):
http://www.mikrocontroller.net/svnbrowser/avr-cp-m/
Alle Codes die derzeit implementiert sind und alle Farbvarianten sind im
beigefügten Dokument aufgeführt.
So - geht nun deutlich besser.
Ab und zu kommt die Tastatur-Emulation unter TP noch ins stottern (dann
geht alles mit Shift nicht mehr...) - ist aber nicht reproduzierbar.
Verstehen tue ich allerdings die ESC-Codes für die Farben noch nicht.
Grundsätzlich wirken sich die Codes offenbar auf den GANZEN Bildschirm
aus - nicht auf die folgenden Zeichen? Zumindest mein Testprogramm in TP
verhält sich so.
Gemäß VT100.pdf:
write(chr(27) + '[44m');
-> setzt den ganzen Bildschirm in Blau. Schrift auch in blau, vor grünem
Hintergrund.
Code 34m: -> setzt den ganzen Bildschirm schwarz, Text dann schwarz vor
blauem Hintergrund.
Scheint alles invers zu sein.
ESC 7m bewirkt aber keine Invers-Umschaltung. ALT-i hilft bei TP auch
nicht.
Die Steuer-Codes (Löschen usw.) verhalten sich unter TP und WS
unterschiedlich - aber wenn ich hier weiter oben lese ist das wohl
normal...
Gruß
Marcel
Marcel Andre schrieb:> Grundsätzlich wirken sich die Codes offenbar auf den GANZEN Bildschirm> aus - nicht auf die folgenden Zeichen? Zumindest mein Testprogramm in TP> verhält sich so.
Korrekt. Da der Bildwiederholspeicher des Propeller begrenzt ist, werden
die Farben nur für den gesamten Bildschirm gesetzt. ESC[44m setzt also
den Bildschirmhintergrund blau unabhängig von der Vordergrundfarbe.
ESC[32m würde dann den Text grün darstellen.
Der Bildwiederholspeicher ist gerade so groß, dass es möglich wäre jeder
Textzeile eine andere Vordergrund- und Hintergrundfarbe zuzuordnen. Aber
ob das Sinn macht?
Marcel Andre schrieb:> ESC 7m bewirkt aber keine Invers-Umschaltung.
Sollte es eigentlich tun, ALT i auch, ich überprüfe es mal.
F1 sollte alles wieder in den Grundzustand setzen, also invers aus, grün
auf schwarz.
Marcel Andre schrieb:> Die Steuer-Codes (Löschen usw.) verhalten sich unter TP und WS> unterschiedlich - aber wenn ich hier weiter oben lese ist das wohl> normal...
Grundsätzlich können ja bei der WS-Konfiguration einige Steuerzeichen
selbst definiert werden. Möglicherweise unterscheiden sie sich in der
Version gerade von TP.
Rein theoretische Frage: Wäre es eigentlich möglich, auf der vorhandenen
Hardware (CP/M Stick V 3.2) einen Intel 8086 oder 8088 zu emulieren und
da darauf dann PTS-DOS laufen zu lassen?
Okay, das klingt ja interessant. Mal gucken, ob ich mit meinen
bescheidenen Kenntnissen da was hinbekomme. (Hatte mal 2 Jahre
Assemblerprogrammierung für Intel 8051 in der Schule und C Kenntnisse
hab ich auch, die werden wohl weniger helfen). Jetzt muss ich sowieso
erstmal das AVR Tutorial durcharbeiten. Bin ziemlich am Anfang. Hab mir
übers lange Wochenende den Thread hier durchgelesen und gemerkt, dass
ich nicht viel verstehe...
So, habe nun die Uhr und den Parallel-Port erfolgreich "am Laufen".
Schon toll - das Konzept mit den virtuellen Ports für I2C und den
Parallel-Chip. Großes Lob an Leo für die Implementierung!
Habe erfolgreich in TP die Ports gelesen und geschrieben (Blinker :-))
Joe erwähnte, dass auf Port 17-22 (?) auch die ADCs des AVR liegen? In
der virt_ports.asm habe ich die aber nicht gefunden.
Einen Krampf bekomme ich immer noch bei den Terminal-Emulationen. Es
reicht ja schon, dass Propeller-Terminal und USB-Terminal (Putty) sich
anders verhalten bzgl. Bildschirm und KeyCodes. Auch klar, dass sich
Programme unterschiedlich verhalten bei den Steuertasten (wie TP und
WS), das kann man mit Muße konfigurieren. Aber dass sich auch ein
Programm selber unterschiedlich verhält... Siehe TP: Im Menü geht DEL
(nach links), im Editor nicht mehr (zumindest im Terminal)... Argggg :-)
Kann mir jemand ein gutes Terminalprogramm für Windows und/oder Linux
empfehlen? Putty und minicom habe ich probiert... Evtl. optimierte
Settings?
Schönen Abend noch!
Marcel
Tera Term mit der VT100 Einstellung sollte alles richtig machen.
Marcel Andre schrieb:> Joe erwähnte, dass auf Port 17-22 (?) auch die ADCs des AVR liegen? In> der virt_ports.asm habe ich die aber nicht gefunden.
;------------------------ ADC Interface
----------------------------------
;17-19 23,25 in - ADC Channels 6,7 and 8 (Temp-Sensor)
; ADC 6,7 only Devices in 32 pin Case (TQFP/MLF)
; 8 Bit only
; Fixed ADC clock (FCPU/128, 156KHz at 20MHz CPU)
; Vref = VCC
;20,21 in - ADC: Measure VCC
;
Joe G. schrieb:> Marcel Andre schrieb:>> Joe erwähnte, dass auf Port 17-22 (?) auch die ADCs des AVR liegen? In>> der virt_ports.asm habe ich die aber nicht gefunden.>> ;------------------------ ADC Interface> ----------------------------------> ;17-19 23,25 in - ADC Channels 6,7 and 8 (Temp-Sensor)> ; ADC 6,7 only Devices in 32 pin Case (TQFP/MLF)> ; 8 Bit only> ; Fixed ADC clock (FCPU/128, 156KHz at 20MHz CPU)> ; Vref = VCC> ;20,21 in - ADC: Measure VCC
In virt_ports.asm sind die Einträge seit SVN r214 drin. Nützt aber
nichts, da ich den eigentlichen ADC-Code noch nicht eingecheckt habe.
Ich hatte nur an Ostern eine "ADC-Testversion" hier als
Diskussionsgrundlage gepostet. Diskussion gabs keine, aber ich bin
inzwischen der Meinung, daß die Temperatur- und VCC-Messungen ziemlich
unsinnig sind und nur Verwirrung stiften, und deshalb entfernt werden
sollten. Im Anhang ist noch mal der fehlende Code.
Marcel Andre schrieb:> Siehe TP: Im Menü geht DEL> (nach links), im Editor nicht mehr (zumindest im Terminal)... Argggg :-)> Kann mir jemand ein gutes Terminalprogramm für Windows und/oder Linux> empfehlen? Putty und minicom habe ich probiert... Evtl. optimierte> Settings?
Meinst Du mit DEL die Taste mit dem Pfeil nach links oder die Taste, die
auf deutschen Tastaturen mit "Entf" beschriftet ist?
Wahrscheinlich sendet Deine DEL-Taste 0x08 (Backspace). "Löschen links"
geht aber in (mindestens) Turbopascal und Wordstar mit 0x7F (Delete).
minicom funktioniert bei mir mit der Einstellung "Backspace key sends:
DEL" (Terminal settings).
Eigentlich braucht man unter linux aber gar kein (extra)
Terminalprogramm. "$ cu -l /dev/ttyUSB0 -s 115200 --nostop" tuts auch.
(Allerdings grade nicht mit der Propeller-Platine. Wahrscheinlich, weil
DCD und/oder DSR nicht aktiv sind.)
Hier ist noch mehr zum Thema:
Beitrag "Re: CP/M auf ATmega88"
Leo C. schrieb:> Wahrscheinlich sendet Deine DEL-Taste 0x08 (Backspace). "Löschen links"> geht aber in (mindestens) Turbopascal und Wordstar mit 0x7F (Delete).
In den meisten Terminal-Emulationsprogrammen lässt sich das Verhalten
der Backspace-Taste einstellen - so auch in PuTTY. Das ging auch schon
in den damaligen DEC-Terminals der 80er Jahre... und sorgte damals schon
für jede Menge Verwirrung unter DEC/VMS, PDP11/RT bzw. Ultrix.
So, ich wollte mich mal wieder melden...
Hier mein aktueller Stand:
Die Idee mit der gemeinsamen Taktquelle (20 MHz für AVR und Propeller)
habe ich wieder verworfen, da der ATmega128 nur bis 16 MHz spezifiziert
ist.
Außerdem mußte ich AVR/CPU und Propeller/IO trennen, da es aussichtslos
schien, mit zwei Lagen den von mir gewünschten Formfaktor (Leiterplatte)
zu realisieren.
Dabei habe ich auch gleich die Schaltpläne getrennt (Anhang).
Danach wurden die Leiterplatten geroutet und gefertigt, Bauteile
bestellt und fleißig bestückt.
Viel geprüft und gemessen und dann hab ich die Schaltungen Stück für
Stück in Betrieb genommen.
Dabei wurden kleine Testprogramme (in C) für die einzelnen Funktionen
geschrieben oder genutzt:
Was bisher getestet wurde:
* ATmega128 (16 MHz Takt) --> funktioniert
* UART mit FTDI und 115200 kBit/s --> funktioniert
* SD-Karte (nachdem der richtige Pegelwandler verbaut wurde: TX_S_0108)
--> funktioniert
* SIMM-Riegel (256 kB, 1 MB, 4 MB) --> funktioniert
* die DIP-Umschalter am UART-Multiplexer (PC <-> AVR, PC <-> Propeller)
--> funktionieren
Damit muß man nicht umjumpern, sondern braucht nur die kleinen
Umschalter betätigen :-)
* Propeller --> funktioniert
Ich hab ein paar Spin-Beispiele ausprobiert und dann das aktuelle
VT100-VGA-Spin eingespielt.
Was noch ungetestet ist:
* RTC
* Video-Ausgabe (RCA-Buchse)
* I2C (mit 3.3V und 5V)
* ADC-Kanäle am AVR
Mängel, die mir bisher aufgefallen sind:
* Der Buzzer ist viel zu leise, eigentlich knackt er nur beim Ein- und
Ausschalten.
Damit der richtig geht, muß ich mit dem Propeller eine Frequenz
ausgeben.
* Auf der ATmega128-Leiterplatte hab ich zu wenig Platz um die
ISP-Buchse gelassen, unschön.
* Der Spannungsregler AP1117 schwingt gelegentlich (bei ca. 3,8 kHz), da
müssen größere Kondensatoren in die Nähe.
* Es fehlt ein Pullup an Propeller-TX, damit auch bei abgesteckter
Propellerplatine die TX-Veroderung geht.
* Das Propellerterminal kommt nicht wirklich mit 115200,8,N,1 aus. Dort
werden Zeichen verschluckt und Bits falsch interpretiert, wenn es zu
schnell geht.
Wenn man auf Senderseite zwei Stopbits einsetzt, geht es etwas besser,
aber immer noch nicht perfekt.
Außerdem fehlt noch die dritte Platine. Dort soll folgendes drauf:
* der 8-Bit Parallelport
* ein Display (nur welches? Text oder Grafik? LCD oder OLED?)
* Soundmodul
* ...?
Den aktuellen Schaltplan gibt es als Anhang, die Layouts werde ich bei
Gelegenheit auch noch veröffentlichen.
Jetzt sitze ich an der Speicheranbindung.
Vielleicht kann mir jemand (Leo?) sagen, was an der folgenden Ausgabe
falsch ist?
1
CPM on an AVR, v3.2 r216
2
Testing RAM: fill...wait...reread...
3
Addr xx yy
4
0083 83 83 -------- --------
5
00CC CC CC -------- --------
6
0225 27 27 -------- --------
7
0356 55 55 -------- --------
8
03D2 D1 D1 -------- --------
9
0407 03 03 -------- --------
10
0428 2C 2C -------- --------
11
04E9 ED ED -------- --------
12
0501 04 04 -------- --------
13
0576 73 73 -------- --------
14
0658 5E 5E -------- --------
15
0819 11 11 -------- --------
16
08F2 FA FA -------- --------
17
09E8 E1 E1 -------- --------
18
0A78 72 72 -------- --------
19
0B96 9D 9D -------- -------- System halted!
Und gleich noch eine Frage: An welcher Stelle werden die Adressleitungen
A8-A10 verwendet?
Bei dram_write und dram_read habe ich nichts gefunden. Dort wird immer
nur mit A0-A7 + A0-A7 gearbeitet (16 Bit = 64 kByte).
Ansonsten hier noch einmal Vielen Dank an die vielen Helfer, die die
Vorarbeit geleistet haben!
Es ist ein sehr spannendes Projekt :-)
Bis später
Jens
Nur ganz kurz, Morgen habe ich wahrscheinlich mehr Zeit, um auf Deine
Schaltung einzugehen:
Jens schrieb:> Und gleich noch eine Frage: An welcher Stelle werden die Adressleitungen> A8-A10 verwendet?
Bisher nur bei der RAM-Disk. Siehe dsk_ram.asm (8-bit).
Ansonsten werden A8-A10 bei allen DRAM-Zugriffen immer auf High
gehalten. Etwas mehr Info fidest Du vielleicht hier:
Beitrag "Re: CP/M auf ATmega88"
Hallo Jens,
spannend, dass du auch die Probleme mit der Propeller-VGA-Ausgabe hast.
Ich nutze die Platine von Joe. Anfangs ging es auch - aber seit ca. 2
Wochen habe ich immer an den genau gleichen Stellen Lücken in der
Darstellung oder falsche Interpretation von Zeichen usw.
Das scheint aber nicht immer ein Problem zu sein - bei Joe läuft es wohl
derzeit stabil. Bislang gibt es hier noch kein Indiz, woran das genau
liegt - da es ja beim einen geht - beim anderen nicht bzw. sich zeitlich
ändert...
Gruß
Marcel
Ich habe momentan etwas wenig Zeit, doch ich werde mich in einer ruhigen
Minute mal dem Problem mit der VGA-Ausgabe annehmen. Vermutlich ist es
einer der CTRL-Befehle der den Bildschirmspeicher zu weit überschreibt.
Da gleich darauf der V24 Puffer folgt, entstehen dabei die Probleme.
Jens schrieb:> Vielleicht kann mir jemand (Leo?) sagen, was an der folgenden Ausgabe> falsch ist?CPM on an AVR, v3.2 r216> Testing RAM: fill...wait...reread...> Addr xx yy> 0083 83 83 -------- --------
...
> 0B96 9D 9D -------- -------- System halted!
Falsch ist, daß Zellen ausgegeben werden, die angeblich gar keinen
Fehler haben. Unter xx steht, was in die Zelle geschrieben wurde, und
unter yy, was später gelesen wurde. Wenn die beiden Wert gleich sind,
dürfte also gar nichts ausgegeben werden. In der Testroutine kann ich
keinen Fehler entdecken. Bin ratlos.
Hier noch was zum Ramtest:
Beitrag "Re: CP/M auf ATmega88"
Leo C. schrieb:> Falsch ist, daß Zellen ausgegeben werden, die angeblich gar keinen> Fehler haben. Unter xx steht, was in die Zelle geschrieben wurde, und> unter yy, was später gelesen wurde. Wenn die beiden Wert gleich sind,> dürfte also gar nichts ausgegeben werden. In der Testroutine kann ich> keinen Fehler entdecken. Bin ratlos.
Ich glaube an meinem refresh ist was falsch. Ich bin in AVR-ASM nicht so
die Leuchte (C liegt mir mehr). Vielleich fällt Euch ja was auf:
[asm]
.cseg
INTERRUPT OC2Aaddr
push temp ; 2
LDS temp, RAM_CTRL_PORT ; 2
; gehe am refresh vorbei, wenn gerade ein Zugriff erfolgt
; ras = 0 -> Zugriff
; ras = 1 -> kein Zugriff -> refresh
sbrs temp, ram_ras ; 2
rjmp norefresh ; 2
; CAS RAS
cbr temp, (1<<ram_cas) ; 1 1 1
STS RAM_CTRL_PORT, temp ; 2 0 1
cbr temp, (1<<ram_ras) ; 1 0 1
STS RAM_CTRL_PORT, temp ; 2 0 0
sbr temp, (1<<ram_ras) ; 1 0 0
STS RAM_CTRL_PORT, temp ; 2 0 1
cbr temp, (1<<ram_ras) ; 1 0 1
STS RAM_CTRL_PORT, temp ; 2 0 0
sbr temp, (1<<ram_ras) ; 1 0 0
STS RAM_CTRL_PORT, temp ; 2 0 1
sbr temp, (1<<ram_cas) ; 1 0 1
STS RAM_CTRL_PORT, temp ; 2 1 1
norefresh: ;
pop temp ; 2
reti ; 4 --> 32 cycles
[/asm]
Dummerweise habe ich die Speichersteuerleitungen (RAS, CAS, WE) an Port
G gelegt, da kann ich die in und out-Befehle nicht verwenden.
Viele Grüße
Jens
Joe G. schrieb:> Vermutlich ist es> einer der CTRL-Befehle der den Bildschirmspeicher zu weit überschreibt.
Hmm. Bei 'normaler' ASCII-Ausgabe werden doch gar keine CTRL-Befehle
ausgeführt. Oder doch?
Grüße
Jens
Marcel Andre schrieb:> Anfangs ging es auch - aber seit ca. 2> Wochen habe ich immer an den genau gleichen Stellen Lücken in der> Darstellung oder falsche Interpretation von Zeichen usw.
Du kanns ja mal versuchen eine kleine Pause beim Versenden einzulegen
(softuart) oder zwei Stoppbits, statt nur Einem (harduart).
Letzteres hat das Problem bei mir etwas entspannt.
Marcel Andre schrieb:> sich zeitlich> ändert...
Ich denke die verschiedenen Quarze sind unterschiedlich frequenz-,
spannungs- und temperaturstabil. Wenn das Timing da etwas knapp ist,
kann das zu den beobachteten Effekten führen.
Viele Grüße
Jens
Jens schrieb:> Ich glaube an meinem refresh ist was falsch.
Ich bin mir sogar sicher, das da was falsch ist. Wenn ich den refresh
rausnehme, komme ich zum 'Initing mmc...'
Jetzt muß ich erstmal die SD-Karte bearbeiten.
Viele Grüße
Jens
Jens schrieb:> Ich glaube an meinem refresh ist was falsch. Ich bin in AVR-ASM nicht so> die Leuchte (C liegt mir mehr). Vielleich fällt Euch ja was auf:
Du hast auf jeden Fall vergessen, das Status-Register zu retten, da
cbr/sbr-Befehle die Flags verändern.
Den Rest schaue ich mir noch an.
1
> .cseg
2
>
3
> INTERRUPT OC2Aaddr
4
>
5
> push temp ; 2
6
in temp,sreg
7
push temp
8
> LDS temp, RAM_CTRL_PORT ; 2
9
10
...
11
12
> norefresh: ;
13
pop temp
14
out sreg,temp
15
> pop temp ; 2
16
> reti ; 4 --> 32 cycles
> Dummerweise habe ich die Speichersteuerleitungen (RAS, CAS, WE) an Port> G gelegt, da kann ich die in und out-Befehle nicht verwenden.
Das ist wirklich ungeschickt.
Leo C. schrieb:> Du hast auf jeden Fall vergessen, das Status-Register zu retten, da> cbr/sbr-Befehle die Flags verändern.
Super! Jetzt geht's auch mit refresh :-)
>> Dummerweise habe ich die Speichersteuerleitungen (RAS, CAS, WE) an Port>> G gelegt, da kann ich die in und out-Befehle nicht verwenden.> Das ist wirklich ungeschickt.
Naja. Nicht ganz so tragisch. Ich habe ein paar freie Portpins auf
Stiftleisten gelegt. Da kann ich zum Optimieren noch umfädeln. Aber
erstmal muß es überhaupt funktionieren.
Nächster Punkt ist die SD-Karte...
...aber nicht mehr heute!
Viele Grüße & Vielen Dank,
Jens
Der Rest sollte eigentlich funktionieren.
Aber was hälst Du denn von folgender Variante:
1
.cseg
2
3
INTERRUPT OC2Aaddr
4
5
push temp ;2
6
LDS temp, RAM_CTRL_PORT ;2
7
8
; gehe am refresh vorbei, wenn gerade ein Zugriff erfolgt
9
; ras = 0 -> Zugriff
10
; ras = 1 -> kein Zugriff -> refresh
11
12
sbrs temp, ram_ras ;2
13
rjmp norefresh ;-
14
; CAS RAS
15
; 1 1
16
STS RAM_CTRL_PORT,_CASREF ;2 0 1
17
STS RAM_CTRL_PORT,_CAS0 ;2 0 0
18
STS RAM_CTRL_PORT,_CASREF ;2 0 1
19
STS RAM_CTRL_PORT,_CAS0 ;2 0 0
20
STS RAM_CTRL_PORT,_255 ;2 1 1
21
22
norefresh: ;
23
pop temp ;2
24
reti ;4 --> 22 cycles
Dazu in 'config.inc' statt:
.def _OE = r4
folgendes:
.def _CASREF = r4 ;CAS before RAS refresh
und in 'init.asm' das Register entsprechend initialisieren.
Hier kann man sich push/pop von SREG wieder sparen, da die verwendeten
Befehle kein Flag ändern.
Evtl. müßten noch ein paar NOPs eingestreut werden.
Leo C. schrieb:> Aber was hälst Du denn von folgender Variante:
Ist vorgemerkt. Aber optimiert wird später (Hardware + Software)
:-)
Jetzt findet er das passende Image nicht:
mmcCMD: 11 00000000 .. 01 CMDRes: 00 No bootable CP/M disk found! Please change MMC/SD-Card.
Gerade eben wollte ich fragen, wo ich weiter zu suchen habe.
Hardwaremäßig funktioniert die SD-Karte, ich habe den Code von Roland
Riegel ausprobiert, der lief:
http://www.roland-riegel.de/sd-reader/index.html
Jetzt habe Testweise die SD-Karte nochmal neu bespielt. Mit dem Mac geht
das z.B. so:
Anschließend noch noch CPMDSK_A.IMG, CPMDSK_B.IMG und CPMDSK_C.IMG
draufkopiert.
Und auf einmal läuft es! Cool!
1
CPM on an AVR, v3.2 r216 Test
2
05 05 01 04
3
Testing RAM: fill...wait...reread...
4
Initing mmc...
5
6
A: FAT16 File-Image 'A' at: 003, size: 256KB.
7
B: FAT16 File-Image 'B' at: 057, size: 256KB.
8
C: FAT16 File-Image 'C' at: 073, size: 256KB.
9
Partinit done.
10
Ok, Z80-CPU is live!
11
12
62k cp/m vers 2.2
13
14
A>dir
15
A: ASM COM : DDT COM : DUMP COM : ED COM
16
A: T COM : TLOOP COM : LOAD COM : MBASIC COM
17
A: 23 BAS : BAGELS BAS : CHECKERS BAS : STARTREK BAS
18
A: TREKINST BAS : MASTRMND BAS : WEEKDAY BAS : PIP COM
19
A: STAT COM : SUBMIT COM : XSUB COM : ZORK1 COM
20
A: ZORK1 DAT : SURVEY COM
21
A>
Die vier Zahlen auf der zweiten Zeile sind von meinem
Speicher-Debugging.
Die Ausgaben vom Emulator zum Propeller laufen offenbar langasm genug,
so das auf dem VGA-Monitor alles 'ordentlich' zu sehen ist.
Dann doch noch eine Frage:
Herzlichen Glückwunsch Jens.
Jens schrieb:> Jetzt habe Testweise die SD-Karte nochmal neu bespielt. Mit dem Mac geht
...
> Und auf einmal läuft es! Cool!
Vielleicht bekommst Du ja noch raus, woran es lag.
Jens schrieb:> Die Ausgaben vom Emulator zum Propeller laufen offenbar langasm genug,> so das auf dem VGA-Monitor alles 'ordentlich' zu sehen ist.
Ja, leider ist das so. 9600 Baud würden für das 3 MHz Z80 CP/M föllig
ausreichen. Und wir bekommen jedes mal die Krise, wenn mit 115200 etwas
nicht richtig tut.
Jens schrieb:> Kann ich cseg irgendwie verkleinern? Der Flash-Vorgang dauert jedesmal> ewig (gefühlt).
Versuch mal:
$ make MMCBOOTLOADER=0 clean all
Wenn das hilft, und Du den Bootloader nicht brauchst, kannst Du den
Support dafür auch dauerhaft abschalten. Entweder im Makefile oder in
config.inc.
Leo C. schrieb:> Herzlichen Glückwunsch Jens.
Naja, der Glückwunsch gehört Euch, ich habe ja 'nur' nachgebaut...
>> Jetzt habe Testweise die SD-Karte nochmal neu bespielt. Mit dem Mac geht> Vielleicht bekommst Du ja noch raus, woran es lag.
Beim ersten Mal habe ich die Partitionierung mit dem
Festplattendienstprogramm gemacht. Ich glaube das Programm legt per
Default eine GUID (http://de.wikipedia.org/wiki/GUID_Partition_Table)
Partitionstabelle an. Das funktioniert natürlich nicht, wenn ein Master
Boot Record erwartet wird.
>> Die Ausgaben vom Emulator zum Propeller laufen offenbar langasm genug,>> so das auf dem VGA-Monitor alles 'ordentlich' zu sehen ist.> Ja, leider ist das so. 9600 Baud würden für das 3 MHz Z80 CP/M föllig> ausreichen. Und wir bekommen jedes mal die Krise, wenn mit 115200 etwas> nicht richtig tut.
Ich versuche alle meine Projekte mit 115200 bps laufen zu lassen. Das
ist für mich ein Quasistandard. Und ich denke auch, das der Propeller
die Rechenleistung hat, um das zu schaffen. Aber das gehört in die
Kategorie Optimierung Propeller.
Dort muss ich sowieso nochmal ran, damit der richtig beept.
>> Kann ich cseg irgendwie verkleinern?> Versuch mal:> $ make MMCBOOTLOADER=0 clean all
Ich hab es gleich in der config.inc deaktiviert. Jetzt dauert der
Programmiervorgang nur noch 12 Sekunden:
Jens schrieb:> Naja, der Glückwunsch gehört Euch, ich habe ja 'nur' nachgebaut...
Eben nicht 'nur'. Immerhin bist Du gerade dabei, die Menge der
unterstützten Controller zu vergrößern. Und eine zusätzliche
DRAM-Variante gibts wahrscheinlich auch. Und wenn Du die I2C-Verbindung
AVR-Propeller richtig durchziehen willst, dann bekommen wir auch noch
einen I2C-Multimaster-Treiber. :)
>> $ make MMCBOOTLOADER=0 clean all> Ich hab es gleich in der config.inc deaktiviert. Jetzt dauert der> Programmiervorgang nur noch 12 Sekunden:ATmega128 memory use summary
Mit was programmierst Du?
Bei mir für mega328p mit avrdude/dragon/isp sind es ca. 14s + nochmal
14s für den Verify. Der Unterschied ohne/mit Bootloader-Kennung ist mir
früher auch schon aufgefallen, und ich hatte überlegt, an der Stelle
etwas zu ändern. Allerdings ist der Unterschied mit avrdude 6 jetzt
verschwunden.
> A>t b>> Timer running. Elapsed: 005.021s.> A>tloop>> Timer running. Elapsed: 001.342s.> Gibt es noch einen erweiterten Benchmark?
A>act b
Timer running. Elapsed: 003.860s.
A>tloop
Timer running. Elapsed: 000.989s.
A>8q
Eight Queens. Running 2 iterations ...
Timer running. Elapsed: 007.669s.
A>
ACT.COM ist die neuere Version von T.COM. 8Q.PAS ist im Anhang.
Vor einigen Monaten hatte ich auch mal mit Dhrystone experimentiert. Die
Dateien und Ergebnisse muß ich mal suchen.
Hier sind schon mal ein paar Links dazu:
http://classes.soe.ucsc.edu/cmpe202/benchmarks/standard/dhrystone.chttp://wiretap.area.com/Gopher/Library/Techdoc/Bench/dhryst.txthttp://www.netlib.org/performance/html/dhrystone.data.col0.htmlhttp://www.ecrostech.com/Other/Resources/Dhrystone.htm
DHRYSTONE
Im Anhang sind 2 Diskimages mit C-Compilern, und jeweils dem Benchmark
Source und Binary. Für jeden Compiler habe ich jeweils eine Funktion
"time" geschrieben, die die Zeit in Sekunden liefert. Allerdings nicht
die aktuelle Uhrzeit, sondern nur die Zeit in Sekunden seit dem setzten
Reset.
Für den Test ist das ja egal.
Leider weiß ich noch nicht, warum die Laufzeit so stark schwankt. Mit
Hi-Tech C z.B zwischen 27 und 30 Sekunden, was 185 dhrystone/s bis 166
dhrystone/s entspricht. Eigentlich müßte immer das Gleiche (+- 1s)
herauskommen.
Die Ergebnisse (ca. Mittelwerte) habe ich in die Tabelle aus dem ersten
Link oben eingefügt. Sieht doch garnicht schlecht aus.
1
DHRYSTONE 1.1 BENCHMARK SUMMARY
2
SORTED BY PERFORMANCE
3
4
MANUF MODEL PROC CLOCK NOREG REG OS,COMPILER,NOTES
Leo C. schrieb:> unterstützten Controller zu vergrößern. Und eine zusätzliche> DRAM-Variante gibts wahrscheinlich auch.
Da müssen wir mal sehen, wie wir meine Änderungen ins Repository
bekommen.
> Und wenn Du die I2C-Verbindung> AVR-Propeller richtig durchziehen willst, dann bekommen wir auch noch> einen I2C-Multimaster-Treiber. :)
I2C müsste eigentlich schon gehen. Der Propeller bootet ja aus dem
EEPROM und der AVR hängt via Pegelwandler auch an den I2C-Leitungen...
> Mit was programmierst Du?
Hardware: Mit einem selbstgebauten AVR910:
http://www.klaus-leidinger.de/mp/Mikrocontroller/AVR-Prog/AVR-Programmer.html
Software: avrdude, ich weiß aber gerade nicht in welcher Version.
>> Timer running. Elapsed: 005.021s.> Timer running. Elapsed: 003.860s.
Ok, das passt. Der ATmega328 läuft ja auch mit 20 MHz, der ATmega128 mit
16 MHz.
> A>8q>> Eight Queens. Running 2 iterations ...> Timer running. Elapsed: 007.669s.
Hui. Ich musste mir erstmal 'ne Bedienungsanleitung für TP3 besorgen:
1
Running
2
Eight Queens. Running 2 iterations ...
3
Timer running. Elapsed: 010.383s.
Ein paar Prozentpunkte dürften sich noch rausholen lassen, wenn ich die
Steuerleitungen für den RAM ändere.
> Vor einigen Monaten hatte ich auch mal mit Dhrystone experimentiert. Die> Dateien und Ergebnisse muß ich mal suchen.> Hier sind schon mal ein paar Links dazu:
Ich dachte eher an die Übersicht, wie schnell welcher Opcode simuliert
wird. Naja, ist auch nicht wirklich wichtig.
Jetzt wird erstmal CP/M gelernt.
Grüße
Jens
Hi!
Ich habe die RTC mal ein bischen aufgepeppt.
Mit Turbo Pascal 3 kann man auch in der heutigen Zeit noch relativ gut
programmieren, hätte ich nicht gedacht. Auch der eingebaute Editor ist
ganz brauchbar (im Gegensatz zu ED...)
Im Anhang sind die ergänzten bzw. veränderten Programmteile.
Die Adresse der RTC musste ich auf 0x51 (read: 0xA3, write 0xA2)
umstellen, da auf 0x50 schon der EEPROM vom Propeller liegt.
Wer den Code per copy&paste direkt ins Zielsystem bringen will, kann
dafür sehr gut screen verwenden. Dazu muß man in screen die
folgenden Befehle eingeben:
1
<ctrl> a : readbuf <filename>
2
<ctrl> a : slowpaste 30
3
<ctrl> a ]
Durch slowpaste wird das Einfügen so verzögern, das der Emulator
hinterherkommt.
Viele Grüße
Jens
Hallo zusammen,
es ist ja hier etwas ruhig geworden :-)
Über die Tage wollte ich mich mal wieder etwas mehr mit dem System
auseinander setzen. Daher die Frage, ob sich evtl. schon
"Verbesserungen" am Zusammenspiel AVR/Propeller hinsichtlich der
VGA-Ausgabe ergeben haben.
Ansonsten schon mal frohes Fest und guten Rutsch!
Marcel
Marcel Andre schrieb:> Daher die Frage, ob sich evtl. schon> "Verbesserungen" am Zusammenspiel AVR/Propeller hinsichtlich der> VGA-Ausgabe ergeben haben.
Ähm, ja. Ich hatte mir den Propeller-Code mal vorgenommen. Allerdings
ist der noch nicht in einem vorzeigbaren Zustand.
Aber 38400 bps gingen dann ohne erkennbare Aussetzer. Hübsch wäre noch
ein FIFO zwischen VT100-Dekoder und Steuercode-Execution.
Momentan will ich mir noch ein kleines TFT als Ausgabeeinheit dranbauen.
Ich weß nur noch nicht, ob am Propeller, am ATmega oder ob auf einem
weiteren Controller.
Viele Grüße
Jens
Joe G. schrieb:> Konntest du einen Fehler eingrenzen?
Ich denke die vielen (zum Großteil unnötigen) if-Abfragen bremsen den
Spin-Interpreter aus. Ich hab das mal auf (m.E.) übersichtlichere
case-Konstrukte umgestellt.
Ich häng mal meine Version hier an.
Viele Grüße
Jens
Hallo Jens,
ich habe mir das gerade mal im Propeller-Tool angesehen auf die Schnelle
und 2 Fragen:
- in der VT100 sehe ich immer noch viele IFs... ?
- wofür ist der "TV-Ausgang" genau?
Ich brutzel das nachher mal rein und berichte :-)
Danke und Gruß
Marcel
Jens schrieb:> Ich häng mal meine Version hier an.
Danke, ich schaue mir morgen mal die Änderungen an.
Marcel A. schrieb:> - wofür ist der "TV-Ausgang" genau?
TV ist nicht notwendig und nicht bei uns implementiert. Ursprünglich war
es für Debugzwecke vorgesehen.
Marcel A. schrieb:> - in der VT100 sehe ich immer noch viele IFs... ?
Da mußt Du noch ein Stück runterscrollen.
An der PS/2-Verarbeitung habe ich nichts geändert (hoffentlich).
> - wofür ist der "TV-Ausgang" genau?
Dort habe ich mir debug-Ausgaben hingeschickt:
1
other:
2
debug.str(string("m1 not supported: "))
3
debug.hex(remote,2)
4
debug.out(13)
Welche Hardware verwendest Du? Ich habe mich ja beim
Propeller-Terminal-Teil mehr am Parallax-Evaluationboard orientiert.
Neben dem VGA-Ausgang gibt es dort noch eine Chinch-Buchse mit TV-Out.
Marcel A. schrieb:> Ich brutzel das nachher mal rein und berichte :-)
Ich habe auch an der Videoauflösung rumgespielt. Es kann also sein, das
Dein Ausgabegerät nicht synchronisiert, in diesem Fall stellst Du in der
VGA_HiRes_Text_010.spin die Auflösung am Besten zurück auf 640x480 (in
VGA_1024.spin muß dann noch rows angepasst werden.)
Viele Grüße,
Jens
Ich habe gerade gesehen, das mein Text etwas missverständlich klingen
könnte:
Jens schrieb:> Ich denke die vielen (zum Großteil unnötigen) if-Abfragen bremsen
Das 'unnötig' bezieht sich auf die Tatsache, das am häufigsten 'normale'
Zeichen reinkommen. Nur wenn eine ESC-Sequenz vorkommt bzw. aktiv ist,
muß diese interpretiert werden, nicht bei jedem Zeichen.
Viele Grüße
Jens
So, hier mal die ersten Ergebnisse.
Zunächst konnte ich das SPIN nicht compilieren. Das liegt wahrscheinlich
am QuellCode - Jens arbeitet in ASCII und Joe in UniCode...
Im Editor vom Propeller (bei mir unter Windoof):
1
{{ for keyboard-de start }}
2
3
cmp data,#de_ae wz 'replace ae
4
if_z mov data,#"ä"
5
cmp data,#de_oe wz 'replace oe
6
if_z mov data,#"ö"
7
cmp data,#de_ue wz 'replace ue
8
if_z mov data,#"ü"
Bei Joe:
1
{{ for keyboard-de start }}
2
3
cmp data,#de_ae wz 'replace ae
4
if_z mov data,#"ä"
5
cmp data,#de_oe wz 'replace oe
6
if_z mov data,#"ö"
7
cmp data,#de_ue wz 'replace ue
8
if_z mov data,#"ü"
Klar - in Zeile 361 der keyb-DE bleibt er dann hängen. Also einfach Joes
Datei genommen...
Danach nur Wirrwarr auf dem Bildschirm. Klar, Jens hatte auf 38400
stehen, Joe auf 115200. Ändern - gut. (wow, ich habe mich an
Propeller-Code gewagt haha...)
Und siehe da: Er scheint erst mal nichts mehr zu verschlucken!!!
Allerdings ist es immer noch nicht schön:
- Alles nur einfarbig - blauer Hintergrund, weiße Schrift
- Es kommt vor, dass der Cursor verschwindet (hängt wahrscheinlich mit
Steuerzeichen aus TP zusammen)
- Ab und zu werden dauerhaft "!" ausgegeben...
- Editor in TP funktioniert nicht - die Eingabe ist wohl letztlich ok,
aber die Darstellung kommt nicht hinterher - kein Scrolling, kein
Einfügen sichtbar usw. Der Bildschirm wird nicht richtig aufgebaut.
- Scrollen klappt auch in WS nicht
Ergebnis: Die VT100 von Joe hat bei mir funktional besser geklappt.
Vielleicht kann Joe die Timing-Optimierungen übernehmen, dann wäre es
wahrscheinlich so perfekt, wie es unter CP/M sein kann, wo hinsichtlich
Tastatur und Bildschirm jeder sein eigenen Standard definiert hat :-)
Danke an Jens!!!
Gruß
Marcel
Jens schrieb:> Marcel A. schrieb:>> - in der VT100 sehe ich immer noch viele IFs... ?> Da mußt Du noch ein Stück runterscrollen.> An der PS/2-Verarbeitung habe ich nichts geändert (hoffentlich).>>> - wofür ist der "TV-Ausgang" genau?> Dort habe ich mir debug-Ausgaben hingeschickt:>
1
>other:
2
>debug.str(string("m1 not supported: "))
3
>debug.hex(remote,2)
4
>debug.out(13)
5
>
>> Welche Hardware verwendest Du?
Die Platine von Joe G
>Ich habe mich ja beim> Propeller-Terminal-Teil mehr am Parallax-Evaluationboard orientiert.> Neben dem VGA-Ausgang gibt es dort noch eine Chinch-Buchse mit TV-Out.>>> Marcel A. schrieb:>> Ich brutzel das nachher mal rein und berichte :-)> Ich habe auch an der Videoauflösung rumgespielt. Es kann also sein, das> Dein Ausgabegerät nicht synchronisiert, in diesem Fall stellst Du in der> VGA_HiRes_Text_010.spin die Auflösung am Besten zurück auf 640x480 (in> VGA_1024.spin muß dann noch rows angepasst werden.)>
Das war kein Problem - aber mein TP-Programm, wo ich mit Farbe (gemäß
Joes Implementierung) rumgespielt habe, zeigt keine Farbe mehr.
Liegt wohl daran, dass Joe einiges anders gemacht hat.
Aber wie gesagt - die Timing-Probleme scheinen hier nicht aufzutreten.
>> Viele Grüße,> Jens
Marcel A. schrieb:> Das liegt wahrscheinlich> am QuellCode - Jens arbeitet in ASCII und Joe in UniCode...
Jepp. Mit UniCode kommt mein diff-Tool nicht klar. Da hab ich
konvertiert. Ich schau aber nochmal nach, ob es auch anders geht.
> Und siehe da: Er scheint erst mal nichts mehr zu verschlucken!
Bei 115200 im Propeller? Wenn das klappt, zieh ich meine Datenrate auch
wieder hoch :-)
> - Alles nur einfarbig - blauer Hintergrund, weiße Schrift
Dafür muß man im Propellercode noch ein bissel mehr ändern.
Bisher gibt es dort keinen Speicher für die Farbe.
Leider ist der Code schon recht unübersichtlich (und m.E. auch ungünstig
benannt), da machen Änderungen nicht so sehr viel Spaß.
> - Es kommt vor, dass der Cursor verschwindet (hängt wahrscheinlich mit> Steuerzeichen aus TP zusammen)
Da müßte man mal auf die debug-Ausgabe schauen. Alles was er nicht
kennt, sollte dort auftauchen.
> - Ab und zu werden dauerhaft "!" ausgegeben...
Das klingt nach einer verschluckten seriellen Schnittstelle.
> - Editor in TP funktioniert nicht - die Eingabe ist wohl letztlich ok,> aber die Darstellung kommt nicht hinterher - kein Scrolling, kein> Einfügen sichtbar usw. Der Bildschirm wird nicht richtig aufgebaut.
Bei mir ließ sich TP ganz gut bedienen. Kann aber auch an 38400 <->
115200 liegen.
> - Scrollen klappt auch in WS nicht
WS habe ich noch nicht verwendet. Der ist mir zu krude zum Bedienen.
Marcel A. schrieb:>> Welche Hardware verwendest Du?> Die Platine von Joe G
Da gibt es kein TV-Out. Schade um die ungenutzten Pins.
> Liegt wohl daran, dass Joe einiges anders gemacht hat.
Ich wollte den Code lesbarer formulieren. Außerdem hab ich versucht mich
an die Spec zu halten (Links im Code). Es kann gut sein, das nicht alles
100%ig identisch implementiert wurde.
Aber wir wollen ja auch im nächsten Jahr noch was zum Basteln haben :-;
Viele Grüße,
Jens
Ja prima.
ich arbeite übrigens immer noch mit der CPM Version 204... Hat jemand
mal ein neueres, laut Leo ist das ja uralt? Ich finde leider derzeit die
SVN-Quellen nicht... wo liegen die denn aktuell?
Dann könnte ich mal versuchen, die selber zu übersetzen (oh weh...) und
auf 57600 gehen... denn das 204er Image von Joe hat 115200.
Marcel, vielen Dank für's Testen!
Ich hab nochmal nachgeschaut: Mea cupla.
Irgendwas hab ich am Code kaputtoptimiert :-(
Z.B. wurden Parameter nicht richtig interpretiert.
Die Farbe (ESC[xx;xxm) müsste jetzt wieder gehen. Aber immer nur für den
kompletten Bildschirm.
2. Problem: Scrollen
Das Problem kann ich hier nachvollziehen, aber nicht so richtig
debuggen.
Wenn ich den Debug-Output aktiviere, schmiert der Propeller ab.
Weiß jemand, welche Sequenzen der Editor von TURBO.COM beim
Runterscrollen schickt?
Damit könnte ich gezielter suchen.
(Das Hochscrollen klappt übrigens...)
In Joe's Code wird ESC[L und ESC[M interpretiert. Das hab ich in keinem
Standard gefunden, aber in dieser Version wieder mit reingenommen.
Die Baudrate hab ich jetzt sowohl im AVR, als auch im Propeller auf
115200 gesetzt. Bis auf das Scrollproblem sehe ich keine Fehler.
Was noch sehr schön wäre, wenn jemand eine Idee für die Umsetzung von
bold auf dem Propeller-Terminal hat. Bisher sieht es in der
Linux-Konsole besser aus, als auf dem Terminal.
Außerdem hab ich noch mein ANSI-Testprogramm angehangen. Das darf gern
erweitert werden :-)
Momentan kann es mehr als unser VT100/ANSI-Emulator.
Ich wünsche allen einen
Guten Rutsch!
Jens
Ich wünsche allen ein gesundes neues jahr!
Jens schrieb:> In Joe's Code wird ESC[L und ESC[M interpretiert. Das hab ich in keinem> Standard gefunden, aber in dieser Version wieder mit reingenommen.
Eine Übersicht über die gebräuchlisten Codes findet man hier [1].
Alle derzeit implementierten Codes stehen in der Doku [2] zum VT100
Terminal.
Ein guter Test ist tatsächlich WS. Dort wird sehr intensiv Gebrauch von
den gängisten Sequenzen gemacht. WS sollte also in jedem Fall laufen.
Einen Bufferüberlauf kann man sehr gut mit einer gesendeten Testdatei
einer ganz bestimmten Länge testen. Das merkwürde ist. Beim ERSTEN
Senden gibt es keine Probleme mit jeder Baudrate. Eine beliebig lange
Datei wird fehlerfrei gesendet und schnell korrekt dargestellt. Erst
beim zweiten Versuch tritt der Fehler auf das Zeichen "verschluckt"
werden, übrigens dann bei jeder Baudrate. Deshalb auch mein Verdacht, an
einer Stelle wird der Bufferzeiger flasch überschrieben.
Gruß Joe
[1] http://www-user.tu-chemnitz.de/~heha/hs/terminal/terminal.htm
[2] http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/manual/
So,
hier wie versprochen die Ergebnisse der Tests der letzten VT100 von
Jens:
- FarbCode scheinen zumindest bei meinem Testprogramm ok (habe ansitest
noch nicht probiert)
- Inversdarstellung ok - z.B. bei WS
- TP: Sieht gut aus, auch Zeile einfügen, was aber (wie erwähnt) nicht
geht ist "runterscrollen", während raufscrollen geht (das war früher
auch nicht besser glaube ich)
- TP: Nach Beenden von TP kann ich keine großen Buchstaben mehr eingeben
(shift geht nicht) - daher auch kein Laufwerkswechsel möglich.
Propeller-Reset hilft (das war aber früher auch schon so glaube ich).
- WS: sieht gut aus - aber genau wie TP kein runterscrollen. Weitere
Tests aber nicht möglich, da WS/AVR/... beim Ankommen am unteren
Bildschirm abstürzt
Sonstiges:
- nach wie vor kommen irgendwann nur noch "!" und sonstiger Müll als
Phantomeingabe... da hilft auch kein Propeller-Reset (das war früher
nicht so)
- Auch in TP "stürzt" das ganze schon mal ab - keine Reaktion, keine
Anzeige... Nur Power off hilft (war früher auch nicht so).
Subjektive Zusammenfassung:
- Das "Verschluck-Problem", was bei mir immer am Anfang/Start auftrat,
ist offenbar weg - somit hier offenbar deutliche Verbesserung
- Die sonstigen "früheren" Probleme (Scrollen, Shift...) sind wohl noch
da.
- Einige Instabilitäten sind dazugekommen, meine ich (Abstürze, Dauer
"!")
Ich würde es gerne mal mit 57600 Bd ausprobieren. Aber leider habe ich
keinen aktuellen QuelleCode (ich arbeite mit V3.2 204).
Wo ist denn der Link geblieben oder hat jemand mal ein "aktuelles" Hex
mit 57600 und 115200 Baud?
Danke!
P.S.:"Früher" meint Joe's V1.0
Ich weiß, die Frage kommt ziemlich (zu?) spät: aber gibt es noch die
Möglichkeit, hier über ein Forenmitglied an eine fertige, unbestückte
Platine zu kommen? Oder sind alle Bestände schon abverkauft?
Gruß,
Andreas
Andreas Gruttmann schrieb:> Ich weiß, die Frage kommt ziemlich (zu?) spät: aber gibt es noch die> Möglichkeit, hier über ein Forenmitglied an eine fertige, unbestückte> Platine zu kommen?
Es gibt noch genau EINE unbestückte Platine (letzte Version VGA + CP/M).
Marcel A. schrieb:> Das "Verschluck-Problem", was bei mir immer am Anfang/Start auftrat,> ist offenbar weg
Ich habe gerade mal getestet. Das Problem liegt in der
FullDuplexSerial.spin, es kommt zu einem Pufferüberlauf. Mal sehen ob
ich den Fehler unproblematisch beheben kann.
Marcel A. schrieb:> Wo ist denn der Link geblieben oder hat jemand mal ein "aktuelles" Hex> mit 57600 und 115200 Baud?
Ich lade mal morgen die aktuelle Version hier [1] hoch.
Schönen Abend!
Joe
[1] http://www.mikrocontroller.net/svnbrowser/avr-cp-m/
> Ich lade mal morgen die aktuelle Version hier [1] hoch.
Prima. Aber da liegen ja nur die Propeller-Dateien. Wo liegen denn die
AVR Dateien?
>> Schönen Abend!> Joe>>> [1] http://www.mikrocontroller.net/svnbrowser/avr-cp-m/
Marcel A. schrieb:> Wo liegen denn die AVR Dateien?
Auf meinem Server. ;)
Leider hat DYN.COM vor ein paar Wochen meinen Hostnamen ohne Vorwarnung
gelöscht. Der Server deshalb unter dem alten Namen nicht mehr
erreichbar.
Die aktuelle Version habe ich mal hier angehängt. Änderungen gab es
zuletzt nur im I2C-Treiber. Später mehr.
Joe G. schrieb:> Wollen wir die aktuellen Daten mal im Mikrocontroller svn> zusammenführen?
Da wäre ich auch dafür. Ich würde mir sogar ein Login holen, damit ich
mal meinen Code als branch einchecken kann.
Viele Grüße,
Jens
@Jens
Ich habe nun mal deinen Code getestet. die Sequenz ESC[J (Bildschirm
löschen) ist fehlerhaft. Außerdem produziert dein Code den gleichen
Bufferüberlauf bei langen Datein.
Joe
Ich bin gerade dabei, mir das MakeFile für AVRCPM anzupassen. AVR Studio
6 hat eine ganz andere Verzeichnis-Struktur bei mir angelegt...
Vorab habe ich noch mal TP und WS mit der Terminal-Ausgabe getestet.
TP läuft soweit ich sehen kann problemlos.
WS scrollt auch hier nicht richtig... Wenn man in der letzten Zeile
ankommt, schreibt man da immer weiter (kein Scrolling), auch wenn der
Zeilenzähler hochzählt. Letztlich stimmt das Ergebnis, aber komisch
ausschauen tut es schon... Liegt das an meinem WS (Image von Joe)?
Gruß
Marcel
Joe G. schrieb:> Wollen wir die aktuellen Daten mal im Mikrocontroller svn> zusammenführen?
Das hatten wir ja vor fast einem Jahr schonmal angedacht. Damals wollte
ich allerdings das komplette Repository mit der ganzen History
transferieren. Dazu hätte man ein Dump des Repos auf dem hiesigen Server
einspielen müssen. Leider hat der Admin (Andreas Schwarz) nicht auf
meine Anfrage geantwortet.
Jens schrieb:> Da wäre ich auch dafür. Ich würde mir sogar ein Login holen, damit ich> mal meinen Code als branch einchecken kann.
Das hättest Du natürlich auch auf meinem Server tun können...
Was spricht denn dagegen, das Repo auf git zu konvertieren, und dann auf
GitHub oder einem ähnlichen Server zu installieren?
Ansonsten könnte ich den aktuellen Stand auf den mikrocontoller.net
SVN-Server kopieren. Die avrvga-Software von Frank Zoll natürlich auch.
Das alte Repo ist jetzt erstmal hier zugänglich:
http://cloudbase.mooo.com/viewvc/avr-cpm/
Leo C. schrieb:> Marcel A. schrieb:>> Wo liegen denn die AVR Dateien?>> Auf meinem Server. ;)> Leider hat DYN.COM vor ein paar Wochen meinen Hostnamen ohne Vorwarnung> gelöscht. Der Server deshalb unter dem alten Namen nicht mehr> erreichbar.>> Die aktuelle Version habe ich mal hier angehängt. Änderungen gab es> zuletzt nur im I2C-Treiber. Später mehr.
Meldet sich als
CPM on an AVR, v3.2 r216M
Ist das richtig? Im ZIP steht 221...
Das VT100 Terminalprogramm sollte nun mit 115200 fehlerfei
funktionieren. Es gab im Test (auch mit sehr langen Textdatein) keine
Fehler mehr. Die FullDuplexSeriel.spin. war noch fehlerhaft. Außerdem
habe ich noch die Initialisierung etwas geändert. Ich habe alle
Änderungen im SVN hochgeladen.
Marcel A. schrieb:> Meldet sich als> CPM on an AVR, v3.2 r216M
Ist wohl korrekt, steht so in der config.asm
Leo C. schrieb:> Ansonsten könnte ich den aktuellen Stand auf den mikrocontoller.net> SVN-Server kopieren. Die avrvga-Software von Frank Zoll natürlich auch.
Das wird wohl die beste Lösung sein.
Marcel A. schrieb:> CPM on an AVR, v3.2 r216M> Ist das richtig?
Nicht ganz.
> Im ZIP steht 221...
Die Datei snvrev.inc wurde seit r216 nicht mehr eingecheckt (Fehler
meinerseits). Die Datei sollte bei jedem Build neu erzeugt werden (Das
Programm dazu findet man hier: http://www.compuphase.com/svnrev.htm).
Allerdings macht das nur dann Sinn, wenn man mit einer aus dem SVN
ausgecheckten Arbeitskopie arbeitet.
Hier die letzten Änderungen, die aller in dem geposteten Zip-File sind:
1
r221 | leo | 2013-11-16 14:14:02 +0100 (Sa, 16. Nov 2013) | 1 Zeile
Joe G. schrieb:> Ich wünsche allen ein gesundes neues jahr!
Diesem Wunsch schließe ich mich gerne an, auch wenn er für mich gestern
zu spät kam. Mir gings nämlich gar nicht gut. Ich konnte mich kaum auf
dem Stuhl halten. An exzessivem Feiern kann es aber nicht gelegen
haben...
Seit heute wirkt der Wunsch aber. Danke Joe.
Jens schrieb:> Weiß jemand, welche Sequenzen der Editor von TURBO.COM beim> Runterscrollen schickt?> Damit könnte ich gezielter suchen.
Auch wenn die Frage inzwischen erledigt ist.
Mit TINST.COM kann man nachsehen, wie das Terminal configuriert ist.
Das hatte ich gestern gemacht, aber nicht mehr geschafft, das Ergebnis
abzuschicken.
1
Terminal type: ANSI
2
Send an initialization string to the terminal? (Y/N)? N
3
Send a reset string to the terminal (Y/N)? Y
4
Command: <ESC> [ 0 m (27 91 48 109)
5
CURSOR LEAD-IN command: <ESC> [ (27 91)
6
CURSOR POSITIONING COMMAND to send between line and column: ; (59)
7
CURSOR POSITIONING COMMAND to send after both line and column: H (72)
8
Column first (Y/N)? N
9
OFFSET to add to LINE: 1
10
OFFSET to add to COLUMN: 1
11
Binary address (Y/N)? N
12
Number of ASCII digits (2 or 3): 2
13
CLEAR SCREEN command: <ESC> [ 2 J (27 91 50 74)
14
Does CLEAR SCREEN also HOME cursor (Y/N)? N
15
HOME command: <ESC> [ H (27 91 72)
16
DELETE LINE command: <ESC> [ 1 M (27 91 49 77)
17
INSERT LINE command: <ESC> [ 1 L (27 91 49 76)
18
ERASE TO END OF LINE command: <ESC> [ K (27 91 75)
END HIGHLIGHTING command: <ESC> [ 0 m (27 91 48 109)
21
Number of rows (lines) on your screen: 24
22
Number of columns on your screen: 80
23
Delay after CURSOR ADDRESS (0-255 ms): 0
24
Delay after CLEAR, DELETE and INSERT (0-255 ms): 0
25
Delay after ERASE TO END OF LINE and HIGHLIGHT (0-255 ms): 0
26
Is this definition correct? (Y/N)? N
> Was noch sehr schön wäre, wenn jemand eine Idee für die Umsetzung von> bold auf dem Propeller-Terminal hat. Bisher sieht es in der> Linux-Konsole besser aus, als auf dem Terminal.
Dazu müßte man wohl einen 2. Font haben. Keine Ahnung, ob das möglich
ist.
Das Terminialprogramm hat doch 40 Zeilen. Außerdem kann ja WS auch auf
eine andere Zeilenzahl konfiguriert werden. Installationen gibt es hier:
Beitrag "Re: CP/M auf ATmega88"Beitrag "Re: CP/M auf ATmega88"Jens schrieb:> Was noch sehr schön wäre, wenn jemand eine Idee für die Umsetzung von> bold auf dem Propeller-Terminal hat. Bisher sieht es in der> Linux-Konsole besser aus, als auf dem Terminal.
Dazu müßte in der VGA_HiRes_Text_010.spin ein zweiter Zeichensatz
implementiert werden. Wie das geht kann hier: VGA_HiRes_Text.spin
entnommen werden, oder wie Leo C. zu sagen pflegt: Freiwillige vor.
Joe G. schrieb:> Das Terminialprogramm hat doch 40 Zeilen.
Richtig. Daran hab ich den Fehler ja auch erkannt :-)
> Außerdem kann ja WS auch auf> eine andere Zeilenzahl konfiguriert werden. Installationen gibt es hier:> Beitrag "Re: CP/M auf ATmega88"> Beitrag "Re: CP/M auf ATmega88">> Jens schrieb:>> Was noch sehr schön wäre, wenn jemand eine Idee für die Umsetzung von>> bold auf dem Propeller-Terminal hat. Bisher sieht es in der>> Linux-Konsole besser aus, als auf dem Terminal.>> Dazu müßte in der VGA_HiRes_Text_010.spin ein zweiter Zeichensatz> implementiert werden. Wie das geht kann hier: VGA_HiRes_Text.spin> entnommen werden, oder wie Leo C. zu sagen pflegt: Freiwillige vor.
Habe jetzt die neue VT100 SPIN drin - WS läuft, aber TP scrolled immer
noch nicht richtig. Timing scheint ok zu sein - weitere Tests morgen.
Besuch vor der Tür.
Guten Morgen zusammen,
so, hier die Ergebnisse meiner Tests.
Versionen:
AVRCPM "221"
VGA: Rev 85
Unter Windows/Teraterm (Terminal, 40 Zeilen):
- WS ok (da müsste ich mir evtl. die Tastatuscodes noch anpassen, das
ist ja an sich ein buchfüllendes Thema)
- TP ok (scrollen etc.). Der Code wird in der einen Version (DISK B)
leider invertiert dargestellt... In der Version DISK F ist das wie
bekannt besser mit Gelb auf Schwarz und weißen Menüs. Leide kann man ja
nicht auslesen, WELCHEN der 32 Screen-Emulationen hier verwendet wird...
Unter Propeller:
- keine Timingprobleme oder Müllzeichen festgestellt -> SUPER!
- WS ok (siehe oben, auch scrollen)
- TP "fast" ok: Auch hier die inverse Darstellung wie im Bild (DISK B)
und eine Darstellung ohne Attribute mit DISK F (da der Propeller ja wie
beschrieben wohl nur 2 Farben + Invers unterstützt). Ich habe noch keine
Option gefunden, dass der Editor den Text dann "flach" darstellt ohne
Attribute)
- ABER: Scrollen nach unten klappt nicht (beide Versionen) - man sieht
das auf dem Bild - die untere Zeile wird immer mit der aktuellen Zeile
gefüllt. aber der Bildschirm/Text rutscht nicht rauf. Gleiches
Verhalten, wenn man die Steuercodes für ScrollDown drückt. ScrollUp geht
dann wieder.
- Manchmal (nicht wirklich reproduzierbar) akzeptiert das System nach
dem Verlassen von TP oder WS die shift-Taste nicht mehr. Vermutlich
liegt das an irgendwelchen Steuercodes. Propeller-Reset hilft.
Ich bin mir nicht sicher, ob Scrollen früher mal geklappt hat. Glaube
aber nicht.
So, das wars erst mal von der Front :-)
Gruß
Marcel
Wer mag, kann nun auch die deutschen Umlaute ö,ä,ü und ß verwenden. Dazu
muß in der VGA_1024.spin der deutsche Zeichensatz geladen werden. Leider
ist in diesem Fall WS oder TP noch nicht richtig zu benutzen, da hier im
deutschen Zeichensatz noch die entsprechenden Standardzeichen
eingetragen werden müssen (macht etwas Arbeit).
@Marcel
Vielen Dank für den Test!
Zu Invers oder Bold hatte ich ja schon was gesagt, hier müßte der
Zeichensatz implementiert werden.
In der TINST.COM werden die Steuerkommandos für das Terminal und auch
die Tastatur festgelegt. So habe ich z.B. für das "Start highlighting"
den Code ESC[7m (invers) eingetragen, "Bold" gibt es ja noch nicht.
Weiterhin sind dort die Editorkommandos festgelegt. Wenn also eine ESC
Sequenz verwendet wird, die bei uns noch nicht implementiert ist, dann
geht die Ausführung schief. Beim schnellen Überfliegen habe ich z.B.
ESC[H und ESC[f (Cursor home) entdeckt. Diese Codes sind noch nicht
implementiert (muß ich noch nachtragen).
Joe G. schrieb:> Eine Übersicht über die gebräuchlisten Codes findet man hier [1].
Ok. Es gibt sicher hübschere Übersichten, aber lass uns die von heha
verwenden.
Marcel A. schrieb:> TP: Nach Beenden von TP kann ich keine großen Buchstaben mehr eingeben> (shift geht nicht) - daher auch kein Laufwerkswechsel möglich.
Das Problem kann ich nicht nachvollziehen.
> nach wie vor kommen irgendwann nur noch "!" und sonstiger Müll als> Phantomeingabe...
Dieses Problem kann ich auch nicht nachvollziehen.
Von wo kommen Deine Eingaben? Vielleicht gibt es Unregelmäßigkeiten beim
PS/2-Protokoll?
Joe G. schrieb:> @Jens> Ich habe nun mal deinen Code getestet. die Sequenz ESC[J (Bildschirm> löschen) ist fehlerhaft.
Inwiefern?
Es gibt einen Parameter für ESC[J:
1
ESC[J oder ESC[0J Löschen vom Kursor nach rechts und bis zum Bildende
2
ESC[1J Löschen vom Bildanfang und von links bis zum Kursor
3
ESC[2J Löschen des Bildschirms
Bei meinen Tests hat das hervorragend funktioniert.
> Außerdem produziert dein Code den gleichen> Bufferüberlauf bei langen Datein.
Kein Wunder, ich verwende ja auch die unveränderte
FullDuplexSerial.spin.
Joe G. schrieb:> Ich habe alle> Änderungen im SVN hochgeladen.
Dummerweise kann man wegen der komischen Dateikodierung von den
wichtigsten Dateien kein Diff machen :-(
Als Beispiel siehe hier:
http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/vga/VT100_VGA.spin?r1=86&r2=88Leo C. schrieb:> Mit TINST.COM kann man nachsehen, wie das Terminal configuriert ist.
Ah. TINST hatte ich noch nicht ausprobiert.
Wobei zum Scrollen ja nichts weiter drinsteht. Immerhin kann man die
Markierung auf invers konfigurieren, bis es einen bold-Font gibt.
Joe G. schrieb:> Das Terminialprogramm hat doch 40 Zeilen
Deins vielleicht. Ich hab mir noch ein paar weitere VGA-Modi (80x32 und
80x28) definiert, damit die Schrift nicht so gequetscht aussieht.
Joe G. schrieb:> Beim schnellen Überfliegen habe ich z.B.> ESC[H und ESC[f (Cursor home) entdeckt. Diese Codes sind noch nicht> implementiert (muß ich noch nachtragen).
In meinem Code sind sie drin. Auch das Nachtragen geht dort leichter...
Viele Grüße,
Jens
Jens schrieb:> Dummerweise kann man wegen der komischen Dateikodierung von den> wichtigsten Dateien kein Diff machen :-(> Als Beispiel siehe hier:> http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/vga/VT100_VGA.spin?r1=86&r2=88
An der Kodierung scheints nicht zu liegen. Imho verwendet man für sowas
aber sowieso nicht das viewvc-Provisorium, sondern einen anständigen
SVN-Clienten mit eingebautem oder externem Diff-Tool. Unter Windows z.B.
Tortoise SVN (s. Anhang für mitgeliefertes Diff). Auch Meld
(http://meldmerge.org/) hat keine Probleme mit utf-16.
> Marcel A. schrieb:>> TP: Nach Beenden von TP kann ich keine großen Buchstaben mehr eingeben>> (shift geht nicht) - daher auch kein Laufwerkswechsel möglich.> Das Problem kann ich nicht nachvollziehen.
Passiert(e) ab und zu beim Beenden von TP - ist aber nicht schlimm.
>>> nach wie vor kommen irgendwann nur noch "!" und sonstiger Müll als>> Phantomeingabe...> Dieses Problem kann ich auch nicht nachvollziehen.
Hat sich ja inzwischen erledigt.
So, habe gerade die Rev 91 der VT100.SPIN getestet.
Hatte mir erst mal eine IDE für den Propeller unter Linux installiert -
war es leid, immer zum anderen PC zu rennen.
Was soll ich sagen: Der Editor läuft unter TP! SUPER!
Folgendes habe ich noch:
- Ab und zu (manchmal reproduzierbar wenn ich den TP-Editor verlasse und
auf die DOS-Ebene gehe) geht shift nicht mehr. Wenn aber nur ich das
Problem habe - egal.
- Ab und zu stehen merkwürdige "@" im Quelltext/Display. Die
verschwinden aber beim scrollen und sind nicht im File enthalten - auch
eher geringes Problem
- Wer verrät mir, wie ich in TP/TPINST einstelle, dass der Quelltext
nicht invertiert dargestellt wird (siehe Bild in einem der letzten
Posts). Irgendwie muss das gehen, denn eine andere TP-Version macht das
nicht (die schreibt im Terminal aber auch gelben Text auf schwarz und
weiße Menüs), die erscheint im Propeller überall grün auf schwarz
@Jens: Aus dem Aufbau deiner Farb-Testroutine am Ende von ansitest.pas
vermute ich, dass die nur für Terminalbetrieb gedacht ist, da sie ja
alle Kombinationen "durchrattert" und das daher auf dem Probeller (der
kennt die Attribute ja nur für den ganzen Bildschirm) dann mit weißer
Schrift auf weißem Hintergrund endet? Propeller-Reset hilft :-) Habe mal
ein paar readln eingebaut.
@alle
Um mit einem "Bold" Zeichensatz zu arbeiten, müßte die
"Inversdarstellung" rausgenommen werden. Es gibt ja nur 8 Bit für jedes
Zeichen. Mit dem 8 Bit (derzeit für invers zuständig) könnte man nun auf
den zweiten Zeichensatz umschalten. Was meit ihr, lieber "invers" oder
lieber "bold"?
Wenn "bold" wie sollten wir den Zeichensatz pixeln? In der angehängten
Quelle habe ich dazu alles vorbereitet. Mit der Sequenz ESC[7m schaltet
man nun auf den zweiten Zeichensatz um. Da ich den ersten Zeichensatz
nur umkopiert habe, ist die Darstellung natürlich noch identisch. Hier
müßte nun die Arbeit beginnen. Es sind die drei Blöcke von $80 bis $F8
die bearbeitet werden müssen.
Marcel A. schrieb:> - Ab und zu (manchmal reproduzierbar wenn ich den TP-Editor verlasse und> auf die DOS-Ebene gehe) geht shift nicht mehr. Wenn aber nur ich das> Problem habe - egal.
Das schau im mir mal an.
Marcel A. schrieb:> Wer verrät mir, wie ich in TP/TPINST einstelle, dass der Quelltext> nicht invertiert dargestellt wird
Bei TINST.COM in der Terminalkonfiguration VT100 das "Start
highlighting" abschalten, also ESC[7m rausnehmen.
Joe G. schrieb:> Leo C. schrieb:>> Ansonsten könnte ich den aktuellen Stand auf den mikrocontoller.net>> SVN-Server kopieren. Die avrvga-Software von Frank Zoll natürlich auch.>> Das wird wohl die beste Lösung sein.
Da sich mein Vorschlag, das Repository auf Git umzustellen, leider nicht
durchgesetzt hat, ist die AVR-CP/M Software ab sofort auf
http://www.mikrocontroller.net/svnbrowser/avr-cp-m/
bzw. svn://mikrocontroller.net/avr-cp-m
zu finden.
Die Historie ist bis auf weiteres noch hier zu erreichen:
http://cloudbase.mooo.com/viewvc/avr-cpm (Browser)
bzw. http://cloudbase.mooo.com/svn/avr-cpm (SVN-Client)
VT100-Terminal
Die neue Version ist eingecheckt. Der Nutzer kann nun zwischen drei
Varianten auswählen.
1. Zeichensatz mit deutschen Umlauten
2. Zeichensatz mit inverser Darstellung
3. zwei Zeichensätze
Die Auswahl erfolgt in der VGA_1024.spin
OBJ
' vga : "vga_Hires_Text_German" 'with German letters ä,Ä,ö,Ö,ü,Ü,ß
' vga : "vga_Hires_Text_Invers" 'with inverse letters
vga : "vga_Hires_Text_Double" 'with second character font
Wer es in Betrieb testen möchte, kann mittels der Tastenkombination
"Alt+i" den aktuellen Zeichesatz umschalten.
Wir (Dank an Leo C. für die Hinweise) haben mal ein kleines RAM-Modul
für das CP/M-System entworfen. Es hat die folgenden technischen Daten:
- Softwarekompatibel zum bisherigen System,
- 3.3V oder 5V,
- 512K SRAM (verfügbar),
- in 64K Bänken linear adressierbar,
- steckbar DIL-18 polig
Was meint ihr? Würde damit das CP/M-System für potentielle Interessenten
lukrativer?
Gruß Joe
Marcel A. schrieb:> Hatte mir erst mal eine IDE für den Propeller unter Linux installiert -> war es leid, immer zum anderen PC zu rennen.
Hast Du da mal einen Link?
Ich würde den Propeller auch viel lieber unter Linux programmieren.
Marcel A. schrieb:> @Jens: Aus dem Aufbau deiner Farb-Testroutine am Ende von ansitest.pas> vermute ich, dass die nur für Terminalbetrieb gedacht ist, da sie ja> alle Kombinationen "durchrattert" und das daher auf dem Probeller (der> kennt die Attribute ja nur für den ganzen Bildschirm) dann mit weißer> Schrift auf weißem Hintergrund endet? Propeller-Reset hilft :-) Habe mal> ein paar readln eingebaut.
Ich habe sie zumindest im Terminal getestet. Vielleicht schaffen wir es
ja im Propeller noch einen Attribute/Farbspeicher pro Zeichen zu
implementieren. Schade, das sich der Propeller nicht so richtig gut
debuggen läßt.
Joe G. schrieb:> lieber "invers" oder> lieber "bold"?
Lieber bold. Aber noch lieber Beides :-)
Deutsche Umlaute halte ich dagegen für überflüssig. Damit fängt man sich
die Zeichensatzprobleme von MS-DOS ein.
Joe G. schrieb:> Was meint ihr? Würde damit das CP/M-System für potentielle Interessenten> lukrativer?
Ich finde nein. Welche Software läuft damit, die vorher nicht lief?
Bei meiner SIMM-Variante lassen sich Module von 256kB bis 4MB verwenden.
Aber selbst der 256kB-Riegel wird nicht vollständig genutzt.
Viele Grüße
Jens
Jens schrieb:> Hast Du da mal einen Link?> Ich würde den Propeller auch viel lieber unter Linux programmieren.
Such mal nach "Brad's Spin Tool", bzw. BST von Brad Campell.
Marcel A. schrieb:> Was ist denn der Vorteil/Unterschied zu dem RAM-Baustein, der bisher auf> deinem Board verbaut ist?
Manche Leute mögen DRAMs nicht. Oder haben Beschaffungsprobleme, oder
können/wollen die Teile nicht löten.
Jens schrieb:> Joe G. schrieb:>> Was meint ihr? Würde damit das CP/M-System für potentielle Interessenten>> lukrativer?> Ich finde nein. Welche Software läuft damit, die vorher nicht lief?>> Bei meiner SIMM-Variante lassen sich Module von 256kB bis 4MB verwenden.> Aber selbst der 256kB-Riegel wird nicht vollständig genutzt.
Mit der RAM-Disk kann man bis 4MB nutzen. Leider ist sie sehr langsam.
Deutlich schneller sollte es gehen, wenn man bei den obersten drei
Adressbits auf Multiplexing verzichtet. Mit etwas geändertem RAM-Treiber
bekommt man dann vielleicht auch mehrere RAM-Banks (z.B. für CP/M 3) mit
ausreichender Geschwindigkeit hin.
Leo C. schrieb:> Such mal nach "Brad's Spin Tool", bzw. BST von Brad Campell.
Danke, das sieht gut aus.
Leider scheint die Mac-Variante bei mir nicht zu laufen. Das wäre das
i-Tüpfelchen gewesen :-)
Dann probiere ich als nächstes die Linux-Version aus.
> Manche Leute mögen DRAMs nicht. Oder haben Beschaffungsprobleme, oder> können/wollen die Teile nicht löten.
Ok. Da hatte ich Euch falsch verstanden. Es soll also eine weitere
Speichervariante darstellen.
Prinzipiell ist die Idee gut, aktuell beschaffbare Bausteine zu
verwenden.
Mein Bedarf ist zwar gedeckt, aber ich bin ja auch nicht der Einzige ;-)
> Mit der RAM-Disk kann man bis 4MB nutzen.
Ja, aber wozu?
Die SD-Karte geht ja schon wesentlich schneller als dazumal die
Diskettenlaufwerke. RAM-Disk wurde ja zur Steigerung der
Zugriffsgeschwindigkeit genutzt. Bei den damaligen RAM-Preisen war aber
die Verbreitung eher gering. Daher gibt es auch nicht allzuviel
Software, die das sinnvoll nutzen kann.
Also eine SRAM-Variante ja, aber übermäßig viel davon (>256k), halte ich
nicht für sinnvoll.
Viele Grüße,
Jens
Die RAM-Variante soll eine kleine Hilfe sein.
Es können derzeit verfügbare IC's verwendet werden oder eigene DRAM's
auf einer entsprechenden Adapterkarte. Somit ist keine Layoutänderung
nötig.
Jens schrieb:> ielleicht schaffen wir es> ja im Propeller noch einen Attribute/Farbspeicher pro Zeichen zu> implementieren.
30 Zeilen mit 80 Zeichen würden wir mit dem verfügbaren Speicher gerade
noch hinbekommen. Dann ist aber das Ende der Fahnenstange erreicht.
Es gibt nun eine neue VT100 Variante.
- 80 Zeichen x 30 Zeilen
- Vordergrund- und Hintergrundfarbe für jedes Zeichen einzeln
einstellbar
- Invers ESC[7m
- Fett ein (helle Schrift) ESC[1m
- Fett aus (dunkle Schrift) ESC[22m
WS und TP müssen für diese Attribute natürlich angepaßt werden.
Selbstverständlich auch für Bildschirmauflösung 80x30.
http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/vga_color/
CP/M Duino
- Boardgröße Arduino Mega
- 512 MB SRAM (verfügbar)
- SD Card (verfügbarer Halter)
- RTC mit Stützbatterie
- 8 Bit Porterweiterung
- 2 ADC
- VT-100 Shield steckbar
Vielleicht interessiert sich der eine oder andere „Arduino Jünger“ ja
für eine solche Variante. Der Arduino bleibt dabei voll erhalten,
bekommt sogar noch 512 MB RAM und über das VT-100 Shield eine
VGA-Ausgabe und eine PS2 Tastatur.
Joe G. schrieb:> CP/M Duino>> - Boardgröße Arduino Mega
D.h. da steckt letztlich ein Arduina-Kompatibles Design hinter? Die IDE
würde einen normalen Arduina-"irgendwas" erkennen?
> - 512 MB SRAM (verfügbar)> - SD Card (verfügbarer Halter)> - RTC mit Stützbatterie> - 8 Bit Porterweiterung> - 2 ADC> - VT-100 Shield steckbar>> Vielleicht interessiert sich der eine oder andere „Arduino Jünger“ ja> für eine solche Variante. Der Arduino bleibt dabei voll erhalten,> bekommt sogar noch 512 MB RAM und über das VT-100 Shield eine> VGA-Ausgabe und eine PS2 Tastatur.
Das Design ist annähernd Kompatibel. Wenn der Arduino Bootloader
installiert
ist, sollte die IDE auch laufen. Sinnvoll ist jedoch der CP/M Bootloader
;-)
Hallo Joe.
Joe G. schrieb:> - 512 MB SRAM (verfügbar)> - SD Card (verfügbarer Halter)> - RTC mit Stützbatterie> - 8 Bit Porterweiterung
Ich dachte, Du wolltest ein "Shield" mit ungefähr den oben genannten
Komponenten bauen, damit Arduino-Besitzer auf CP/M "upgraden" können.
Wo siehst Du den Vorteil der Komplettlösung im Arduino-Format?
Joe G. schrieb:> Sinnvoll ist jedoch der CP/M Bootloader ;-)
Könnte mir vorstellen, daß man ein CP/M-Image für den Arduino-Bootloader
gernerieren kann.
Hallo Leo,
das war die ursprüngliche Idee. Dummerweise sind beim Arduino nicht alle
für unser CP/M-System benötigten Pins rausgeführt (siehe Anlage). Der
Arduino USB-Port liegt direkt auf AVR_TX /AVR_RX also für uns so auch
nicht zu gebrauchen. Der Propeller könnte in der Original Arduino
Konfiguration auch nicht programmiert werden. So entstand der nun
vorliegende Vorschlag.
1. Ein Arduino Board welches Arduino und CP/M kompatibel ist.
2. Ein VT-100 Shield
Die Idee mit dem CP/M–Image für den Arduino Bootloader ist natürlich
sehr gut. Dazu müsste allerdings auch der Arduino Bootloader auf die
Rx,Tx Pins beim CP/M angepasst werden.
Warum das ganze?
Ich sehe dabei zwei Aspekte. Der CP/M-Kenner kann sich ohne viel Aufwand
mit den Arduino beschäftigen und die Arduino-Jugend bekommt ohne viel
Aufwand ein komplettes Betriebssystem mit allen verfügbaren Programmen,
wie C, Pascal, Forth, Wordstar… sowie ein Arduino Board mit 512 KB SRam,
SD-Card, RTC, I2C usw. + VGA.
Neben der reinen AVR Lösung hat die Nutzung einer echten Z80 CPU auch
seinen Charme. Recherchiert man mal nach aktuellen Lösungen, so
kristallisieren sich unabhängig voneinander immer ähnliche Konzepte
heraus.
1. moderne Z80 CPU (z.B. Z8L180 oder Z8S180) 3.3V, 33 MHz
2. 128k – 512K SRAM
3. kein EPROM oder EEPROM
4. Bootvorgang über AVR
5. SD-Card statt Diskette
Beispiele dazu sind hier zu finden:
http://www.shaels.net/index.php/mini80http://forums.parallax.com/showthread.php/148944-Propeller-Z80-CPM-hybridhttp://hive-project.de/board/viewtopic.php?f=15&t=955
Den letzten Link habe ich für weitere Überlegungen aufgegriffen. Micha
hat dazu ein sehr gutes minimales Hardwarekonzept (sowie eine
Softwarebasis) auf AVR-Basis entwickelt. Dieses Konzept habe ich nun
aufgegriffen und etwas erweitert um ein Maximum an Softwaremodulen
unseres Systems weiter zu nutzen. Grob skizziert würde es etwa so
aussehen:
1. AVR übernimmt Buskontrolle
2. AVR initialisiert den RAM und die SD-Card (Kontrolle über V24 /
Terminal)
3. AVR läd BIOS von SD-Card und schreibt es in den RAM
4. AVR übergibt CRT Kanal an Z80 SIO
5. AVR initialisiert Soft I2C mit RTC
6. AVR übergibt Bus an Z80
7. Z80 bootet CP/M
8. AVR stellt IN(), OUT() Funktionen für Z80 zur Verfügung (virtuelle
SIO, PIO)
Mir gefällt die Idee persönlich so gut, dass ich sie für mich aufbauen
werde. Konzeptionell sind dazu folgende Schritte geplant.
1. minimaler Hardwareentwurf (siehe Anhang) als Entwicklungsbasis
2. Portierung der Software sowie Integration von Hardwareverbesserungen,
-erweiterungen
3. finale Version mit integriertem VT-100 Terminal auf bisheriger Basis
4. CP/M Duino mit echtem Z80 (Z180) ??
Es gibt sowohl im CP/M Forum als auch im HIVE Forum Interessenten. Auch
Micha als ursprünglicher Entwickler der Lösung ist weiter interessiert.
Es sollte doch möglich sein, die Interessenten aus drei Foren in einem
gemeinsamen Projekt zu bündeln.
Viel Text zu einer kurzen Frage.
Wer hat Interesse an diesem Projekt sowie zunächst an der Stufe 1 und
Stufe 2 ? Schaltung und Layout sind erstellt und könnten kurzfristig für
weitere Diskussion dienen.
Joe G. schrieb:> Neben der reinen AVR Lösung hat die Nutzung einer echten Z80 CPU auch> seinen Charme.
Ach. ;-)
> 4. Bootvorgang über AVR
Da gibts noch Alternativen. Letztes Jahr hatte ich mal was mit stm32
angfangen.
> 2. AVR initialisiert den RAM und die SD-Card (Kontrolle über V24 /> Terminal)> 3. AVR läd BIOS von SD-Card und schreibt es in den RAM> 4. AVR übergibt CRT Kanal an Z80 SIO
Die Umschalter würde ich einfach weglassen. Die Consolenschnittstelle
kann durch den I/O-Controller einfach durchgeschleift werden. Die beiden
Z180-UARTs stehen dann als weitere Schnittstellen zur Verfügung.
> 5. AVR initialisiert Soft I2C mit RTC
RTC ist im STM32 bereits eingebaut.
> Mir gefällt die Idee persönlich so gut, dass ich sie für mich aufbauen> werde. Konzeptionell sind dazu folgende Schritte geplant.> 1. minimaler Hardwareentwurf (siehe Anhang) als Entwicklungsbasis
Ist (noch) nicht minimal. ;)
> 4. CP/M Duino mit echtem Z80 (Z180) ??
Ach, dazu wollte ich ja auch noch was schreiben.
> Wer hat Interesse an diesem Projekt sowie zunächst an der Stufe 1 und> Stufe 2 ? Schaltung und Layout sind erstellt und könnten kurzfristig für> weitere Diskussion dienen.
Interessieren tuts mich schon. Aber nicht so, daß ich eine Platine haben
wollen würde.
Noch ein paar Worte zu meiner STM32–Variante.
- Den HD64180 hatte ich schon. Der läuft nur mit 5V.
- STM32 I/Os sind 5V-tolerant.
- STM32F1 mit vielen Pins sind billiger als AVR.
- Durch die vielen I/O-Pins kann alle denkbare Peripherie ohne weitere
ICs angeschlossen werden.
- Ein STM32VLDISCOVERY hatte ich schon. Damit konnte ich schnell
anfangen.
Leider hat das Discovery-Board doch zu wenige 5V-tolerante I/O-Ports.
Deshalb sind jetzt noch 2 Buffer-ICs verbaut. Wenn ich mal wieder dazu
komme, soll das Board (und die beiden HCT541) gegen einen (mindestens)
100 poligen STM32F101 getauscht werden.
Im angehängten Schaltplan sind P1-P3 die Buchsenleisten, auf die das
Discovery-Board gesteckt wird.
> Da gibts noch Alternativen. Letztes Jahr hatte ich mal was mit stm32> angfangen.
Leider habe ich davon keine Ahnung, aber kann ja noch werden ;-)
> Ist (noch) nicht minimal. ;)
Stimmt, anbei die Schaltung des derzeitigen Standes.
> Interessieren tuts mich schon. Aber nicht so, daß ich eine Platine haben> wollen würde.
Manchmal gibt es auch was umsonst ;-)
Prinzipiell habe ich nichts gegen eine STM32-Variante. Leider ist der
3.3V Z180 (Z8S180) nicht so richtig verfügbar. Der Z8L180 (5V) jedoch
überall.
> Die Umschalter würde ich einfach weglassen. Die Consolenschnittstelle> kann durch den I/O-Controller einfach durchgeschleift werden. Die beiden> Z180-UARTs stehen dann als weitere Schnittstellen zur Verfügung.
Das ist eigentlich auch nur für die Entwicklung gedacht. So kann der
Initialisierungsvorgang beim AVR besser überwacht werden. Natürlich
können auch einfach alle drei Schnittstellen nach außen geführt werden.
Finde ich spannend.
Noch spannender finde ich, dass ich diese Antwort 2x schreiben muss, die
erste ist verschütt gegangen.
Wofür ist den CRT gut? Das ist doch auch nur eine serielle
Schnittstelle, oder? Wo ist der Unterschied zum TTY Anschluss?
Habe zwar noch jede Mengen "Baustellen" hier aber... in was für einer
Größenordnung liegt denn das Projekt (Platine, Bauteile...)?
Gruß
Marcel
> Wofür ist den CRT gut? Das ist doch auch nur eine serielle> Schnittstelle, oder? Wo ist der Unterschied zum TTY-Anschluss?
An CRT wird das Terminal angeschlossen. Darüber erfolgen also die
Bildschirmausgabe und die Tastatureingabe. Mit TTY wird eine
vollständige serielle Schnittstelle, also Rx, Tx, RTS, CTS, DTR, DSR
bereitgestellt.
> Habe zwar noch jede Mengen "Baustellen" hier aber... in was für einer> Größenordnung liegt denn das Projekt (Platine, Bauteile...)?
Die Platine habe ich noch nicht kalkuliert, bei den Bauelementen schlägt
die Z180 CPU mit ca 10 $ zu. Den Rest kann man sich ja selbst
ausrechnen.
Es ist jedoch KEIN fertiges, erprobtes Konzept wie das bereits
existierende AVR CP/M !! Hier darf noch kräftig selbst Hand angelegt
werden.
Nachtrag: Anbei alle Schaltungen. Nun darf kräftig Kritik geäußert
werden bzw. Fehler und Unstimmgikeiten benannt werden.
Nur mal kurz, weil ich gerade nicht viel Zeit habe.
Joe G. schrieb:> Leider ist der> 3.3V Z180 (Z8S180) nicht so richtig verfügbar. Der Z8L180 (5V) jedoch> überall.
Hier scheints mehrere Verwechslungen zu geben, was bei den Datenblättern
von Zilog (Viele (Druck-)Fehler und fast immer "Preliminary") auch kein
Wunder ist. Die angehängten Graphen stammen aus [1]. Daraus, und aus der
Tabellenüberschrift zu den AC Characteristics in [1] und [2] schließe
ich, daß der Z8S180 auch mit 3.3 V, dann allerdings nur bis 20MHz läuft.
Beim freundlichen Chinesen habe ich den Z2S180 incl. Versand ab ca.
€2,20 gesehen, bei Abnahme von 10 Stück.
Wenn man den Z180 (und das RAM) mit 3.3V betreiben kann, ist es
schaltungstechnisch fast egal, ob man als "Hilfscontroller" einen AVR
oder STM32 nimmt. Gleiche Anzahl I/Os vorausgesetzt.
[1] http://www.zilog.com/docs/z180/um0050.pdf
[2] http://www.zilog.com/docs/z180/z8s180ps.pdf
> Daraus, und aus der> Tabellenüberschrift zu den AC Characteristics in [1] und [2] schließe> ich, daß der Z8S180 auch mit 3.3 V, dann allerdings nur bis 20MHz läuft.
Da ich gerade zwei frische Z8S180033VSC auf dem Labortisch habe, teste
ich gleich mal den Spannungsbereich aus.
Ich habe gerade 2 CPU's (Z8L180) getestet. Der M1 Zyklus bzw. der
Adresszähler laufen bei beiden Exemplaren sauber von 5 V bis runter zu
2.4 V.
Der Quarztakt lag auf 20 MHz.
Anbei ein vorläufiger Abschlussstand der AVR CP/M Version. Gegenüber der
letzten Version sind noch folgende Änderungen eingeflossen:
1. Adresslatch auf /BUSACK gelegt (Danke Leo C.)
2. SRAM auf 512K vergrößert
3. Takt direkt am Z180 erzeugt
4. System komplett auf 3.3V (Levelshifter für SD entfällt)
5. I2C komplett separat, also Umschalter CRT1/CRT2 getrennt
Ich würde diesen Arbeitsstand zunächst „einfrieren“ um weitere Ideen und
Vorschläge zu sammeln.
Aus meiner Sicht sehr überlegenswert der Vorschlag von Leo C. anstelle
eines AVR’s ein STM32 zu verwenden. Die Entwicklung könnte in Richtung
„CP/M Shield für STM Discovery“ gehen.
Wäre es nicht sinnvoller, einen neuen Thread dafür aufzumachen? "CP/M
auf ATmega88" passt inzwischen überhaupt nicht mehr.
Mich würde es freuen, weil die Thread-Ladezeit in meinem Firefox langsam
unerträglich wird.
Joe G. schrieb:> CP/M Shield für STM Discovery
Für welches Discovery? Ich hab inzwischen mehrere :-)
Außerdem ist man dann gleich wieder an dem Punkt, den Propeller
einzusparen, weil der STM genug Power für VGA hat:
http://www.youtube.com/watch?v=HkUUJ-rOUPg
Viele Grüße,
Jens
Nach einigen Überlegungen hat sich die AVR_Z80_Stamp Version
herauskristallisiert. Also ein Z180-Modul mit kompletten Z80 Bus. So
kann das Modul z.B. auf eine Leiterkarte mit ECB-BUS gesteckt werden.
Das Modul selbst ist jedoch auch schon (fast, nur 3.3V) ohne äußere
Beschaltung komplett lauffähig. Die Unterlagen dazu gibt es wie immer
hier:
http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/stamp/
Ich warte noch auf einige Bauelementemuster um das Layout zu überprüfen
und dann werde ich einen Satz Leiterplatten fertigen lassen. Bei allem
Enthusiasmus bitte jedoch immer bedenken. Es ist zunächst eine
Entwicklungsversion.
> und ich wuerde gern mit dem Asembler drauf rumspielen :)
Dabei sollte aber volle Z80 Kompatibilität nicht stören, oder?
In der config.inc gibt es einen Schalter 1), um die Z80 Emulation
abzuschalten. Dieser Schalter stammt aus der Anfangszeit des Projekts,
als der Interpreter für die Z80 Opcodes noch gar nicht vorhanden war,
und diente dazu, das Verhalten der Flags zwischen 8080- und Z80-Mode
umzuschalten.
Man könnte den 8080-Mode dazu verwenden, Flash einzusparen, damit das
Programm wieder in einen atmega88 paßt. Da an dieser Variante bisher
niemand Interesse gezeigt hat, ist sie wenig getestet, und die
undokumentierten 8080 Opcodes werden wahrscheinlich garantiert nicht
richtig interpretiert.
1) #define EM_Z80 1 /* Emulate Z80 if true, else 8080 */
> da ist nur die Rede von ATmega88 und weiter unten von 168,> was ist den nun die aktuelleste Version mit AVR ?
Die aktuelle Software braucht einen ATmega328P. Mit ein paar kleinen
Einschränkungen würde man sie noch in einen 168 bekommen, aber im
Normalfall sollte man sich daß nicht antun. Vom Preis und Verfügbarkeit
her dürfte sowieso fast kein Unterschied bestehen.
> Diese ?:> http://www.mikrocontroller.net/articles/Datei:ACPM_Prop.jpg
Auf dem Foto sieht man nicht, welcher Controller auf der Platine ist.
Bin mir aber ziemlich sicher, daß die niemand mit atmega168 bestückt
hat.
Drako schrieb:> ...
2 Fragen:
Ist da noch die Firmware drauf, die im ersten Bild (Screenshoot) zu
sehen ist (v2.3 r185)? Wenn nicht, welche dann?
Wird der USB-Dongle, der im 2 Bild zu sehen ist, mitgeliefert? Ist aus
dem Text nicht klar zu erkennen.
> 2 Fragen:
2 Tage - keine Antwort.
Dann kann man wohl davon ausgehen, das auf der halb bestückten Platine
noch die uralte Firmware mit unfertigem, buggy Z80-Interpreter drauf
ist. Neu flashen geht auch nicht so einfach, der der ISP-Stecker ja auch
fehlt. Aber da man wg. USB-Anschluß ja sowieso zum Lötkolben greifen
muß...
So, ich habe mal meinen ersten Lochraster-Aufbau von "anno dazumal"
ausgegraben (siehe Foto), den mit ATMega88 und 4bit RAM.
Ich habe dem dann einen 328p spendiert und wollte die aktuelle
"firmware" mit Z80-Unterstützung draufbringen.
Tja, mehrere Hürden - und letztlich kein Erfog:
- zunächst musste ich im MakeFile die Pfade zum avrasm und den
includesdes AVR Studios anpassen - kein Problem
- dann musste ich noch svnver.exe nachinstallieren (oder den Eintrag im
MakeFile auskommentieren) - auch kein Problem
- obwohl ich dann (so denke ich, siehe Anhang) die Flags richtig gesetzt
habe konnte er die init.asm nicht übsersetzten "Symbol SCL not found".
Ich denke das liegt daran, dass wegen der Abwahl von I2C die
equ-Einträge nicht geladen werden, in der init.asm aber trotzdem darauf
verwiesen wird. Ich habe also mal eben SCL durch 5 und SDA durch 4
ersetzt im code - ist ja eh egal
- beim Auslesen der "Release-Version" spuckt mir make immer noch
folgende Fehler aus:
- es wird keine eep-Datei erzeugt, im MakeFile steht aber für "make
program" sowohl hex als auch eep brennen. Daher kommt es zum Fehler
"avrcpm.eep not found". Ist das schlimm? Wird überhaupt was ins eeprom
geschrieben?
Wenn ich den 328er dann einsetze passiert - nichts. Keine Antwort auf
dem Terminal...
Mache ich hier noch was falsch oder "geht das gar nicht auf der HW"?
Danke und Gruß
Marcel
Marcel A. schrieb:> im MakeFile steht aber für "make> program" sowohl hex als auch eep brennen. Daher kommt es zum Fehler> "avrcpm.eep not found".
$ make flash
make program benutzt kein Mensch (dachte ich)
> Ist das schlimm?
Unschön, aber nicht schlimm.
> Mache ich hier noch was falsch oder "geht das gar nicht auf der HW"?
Weiß nicht, ob die aktuelle Software noch mit 4-bit läuft.
Kann ich mir erst heute Mittag anschauen. Alles so lange her...
Den letzten Beitrag habe ich wieder gelöscht, weil der darin enthaltene
Änderungsvorschlag Mist war. Da der Rest nicht ganz so falsch ist,
stelle ich ihn wieder rein
Marcel A. schrieb:> - obwohl ich dann (so denke ich, siehe Anhang) die Flags richtig gesetzt
Man kann stattdessen make übrigens auch so starten:
1
$ make DRAM_8BIT=0
oder auch
1
$ make flash DRAM_8BIT=0 AVRDUDE_PROGRAMMER=usbasp
> habe konnte er die init.asm nicht übsersetzten "Symbol SCL not found".> Ich denke das liegt daran, dass wegen der Abwahl von I2C die> equ-Einträge nicht geladen werden, in der init.asm aber trotzdem darauf> verwiesen wird.
Genau
> Ich habe also mal eben SCL durch 5 und SDA durch 4> ersetzt im code - ist ja eh egal
Das ist natürlich nicht egal, da die Ports ja für etwas anderes
verwendet werden.
8-bit RAM:
1
;Port C
2
.equ SDA = 4
3
.equ SCL = 5
4-bit RAM:
1
;Port C
2
.equ RAM_W = 4
3
.equ RAM_CAS = 5
Die RAM-Steuerleitungen als Input, macht sich dann nicht so gut.
Für die RXD-Leitung gilt ähnliches. Es kann natürlich sein, das noch
weitere Stellen angepaßt werden müssen. Wenns bei Dir so immer noch
nicht läuft, und müßte ich mir notfalls ein 4-Bit System aufbauen.
> process_begin: CreateProcess(NULL, awk -vID=VMAJOR "$1$2 ~ \"#define\"ID> {print $3}" config.inc, ...) failed.
Gibt es ein awk auf dem Rechner, und ist es im "$PATH"?
Ich habe gawk (aus WinAVR) drauf, und im makefile steht auch "AWK=gawk".
Ist auch im PATH.
Trotzdem ging es erst, als ich gawk.exe in awk.exe umbenannt hatte. Na
egal.
Jetzt kommen nur noch diese warnings:
1
avrcpm.asm(35): info: 'config.inc' included from here
2
config.inc(374): warning: Register r8 already defined by the .DEF directive
3
avrcpm.asm(35): info: 'config.inc' included from here
4
config.inc(375): warning: Register r9 already defined by the .DEF directive
5
avrcpm.asm(35): info: 'config.inc' included from here
6
config.inc(378): warning: Register r10 already defined by the .DEF directive
7
avrcpm.asm(35): info: 'config.inc' included from here
8
config.inc(379): warning: Register r11 already defined by the .DEF directive
9
avrcpm.asm(35): info: 'config.inc' included from here
10
config.inc(382): warning: Register r12 already defined by the .DEF directive
11
avrcpm.asm(35): info: 'config.inc' included from here
12
config.inc(383): warning: Register r13 already defined by the .DEF directive
13
avrcpm.asm(35): info: 'config.inc' included from here
Ich habe schon mit BAUD rumgespielt - ohne "sichtbaren" Erfolg.
Der Cursor in TeraTerm scheint bei einem Reset leicht zu flackern - mehr
nicht.
Wahrscheinlich geht es einfach nicht. Ist zwar schade, macht aber auch
keinen Sinn, da groß weiter zu testen, danke Leo.
Ich sollte mal langsam mit dem "großen" CPM-Rechner anfangen :-)
Gruß
Marcel
> Ich habe gawk (aus WinAVR) drauf, und im makefile steht auch "AWK=gawk".> Trotzdem ging es erst, als ich gawk.exe in awk.exe umbenannt hatte. Na> egal.
Im Makefile steht zwar:
AWK = gawk
allerdings:
conf-val = $(shell awk ...
statt:
conf-val = $(shell $(AWK) ...
Bei mir (Debian) gibt es einen Link von awk auf gawk über die
Alternativen-Verwaltung.
> Wahrscheinlich geht es einfach nicht.
Du bist jetzt wohl der Erste nach über 3 Jahren, der das merkt.
Aber ich weiß nicht so recht, ob ich mich damit abfinden will...
Mal sehen, ob ich etwas Zeit finde.
Hallo Forum!
Ich versuche gerade mit den cpmtools auf die 8 MB-Images zuzugreifen.
Aber irgendwie gelingt mir das nicht. cpmls zeigt einfach nichts an.
Ist denn die diskdef richtig, oder passt die nur für die 260 kB-Images?
(Mit den 260 kB-Images funktioniert cpmls.)
> "CPU halted!"-Fehler.
Das ist kein Fehler. Nur der Hinweis, daß die CPU auf einen HALT-Befehl
gelaufen ist. ;)
Von der Standard-Firmware wird normalerweise das gesamte RAM mit 0x76
(== HALT) gefüllt. Bei Programm- oder Hardware-Fehlern ist die
Wahrscheinlichkeit, daß die CPU auf so einen Halt springt, relativ groß.
Könnte sein, daß Du ein Hardwareproblem hast.
> Wie kann ich jetzt weiter vorgehen? Hat unsere Emulation noch Schwächen?
Die wird schon noch Schwächen haben, aber ganz bestimmt nicht solche.
Zexdoc habe ich z.B. auch zum Testen benutzt.
Kannst Du mal die kompletten Boot-Meldungen posten?
Leo C. schrieb:> Kannst Du mal die kompletten Boot-Meldungen posten?
Sieht eigentlich unverdächtig aus:
1
CPM on an AVR, v3.2 r216 Test
2
Testing RAM: fill...wait...reread...
3
Initing mmc...
4
5
A: FAT16 File-Image 'A' at: 003, size: 8192KB.
6
B: FAT16 File-Image 'B' at: 5262, size: 8192KB.
7
C: FAT16 File-Image 'C' at: 5257, size: 8192KB.
8
D: FAT16 File-Image 'D' at: 6298, size: 8192KB.
9
E: FAT16 File-Image 'E' at: 6811, size: 8192KB.
10
F: FAT16 File-Image 'F' at: 7323, size: 8192KB.
11
Partinit done.
12
Ok, Z80-CPU is live!
13
14
62k cp/m vers 2.2
15
16
A>
Die Images C und D hab ich gestern neu erstellt. Dort laufen die
Programme nicht. Images E und F sind die beiden Benchmark-Images
(Dhrystone), die funktionieren. Und Image A und B sind 'alt', die
funktionieren auch.
Du kannst ja evtl. mal einen Blick auf das angehängte Image werfen
(zextest.simhd). Zum Erstellen habe eigentlich nur empty.simhd genommen
und die Dateien mit cpmcp reinkopiert.
Dank & Gruß,
Jens
Jens schrieb:> Sieht eigentlich unverdächtig aus:> CPM on an AVR, v3.2 r216 Test
Ich wollte vor allem wissen, ob Du aktuelle Firmware hast.
> A: FAT16 File-Image 'A' at: 003, size: 8192KB.> ...
Leider sieht man hier nicht die exakte Größe.
1
$ ls -l *.IMG *.simhd
2
-rw-r--r-- 1 leo leo 8388608 Mai 2 2012 CPMDSK_A.IMG
3
-rw-r--r-- 1 leo leo 8388864 Nov 28 18:03 zextest.simhd
4
$
Dein 'zextest.simhd' ist um einen Sektor (512 byte) größer als 8192KB.
Deshalb wird es als my80- statt als simhd-Image erkannt. Diese Ecke ist
leider etwas unübersichtlich und schlecht dokumentiert.
Die cpmtools verlassen sich im Wesentlichen auch darauf, daß der
Anwender weiß was er tut.
> Zum Erstellen habe eigentlich nur empty.simhd genommen> und die Dateien mit cpmcp reinkopiert.
Wo gibts denn dieses 'empty.simhd'? Das scheint dann nämlich fehlerhaft
zu sein. Ich habe nur ein leeres myz80 Image gefunden[1].
Hier noch die Zusammenfassung von [2] und [3]:
Leo C. schrieb:> Wo gibts denn dieses 'empty.simhd'? Das scheint dann nämlich fehlerhaft> zu sein. Ich habe nur ein leeres myz80 Image gefunden[1].
Da habe ich wohl was durcheinandergehauen.
Ich habe gedacht, das die 8 MB-Images automatisch simhd-Images sind:
1
8388864 10 Okt 2010 empty.simhd
2
8314 1 Nov 2013 empty_8MByte_img.zip
Richtig muß es wohl dann so heißen:
1
8388864 10 Okt 2010 empty.myz80
2
8314 1 Nov 2013 empty_8MByte_img.zip
Hätte ich mal ins zip-Archiv geschaut, hätte ich das auch sehen können
(facepalm):
1
$ unzip -l empty_8MByte_img.zip
2
Archive: empty_8MByte_img.zip
3
Length Date Time Name
4
-------- ---- ---- ----
5
8388864 10-10-10 03:05 myz80.img
6
-------- -------
7
8388864 1 file
Vielen Dank Leo, ich glaube ich komme jetzt weiter.
Noch eine Frage: Wo gibt es makeimage? Mein Mac ist da etwas
minderbemittelt.
Viele Grüße,
Jens
Hallo Jens,
ich war grade den passenden Link für makeimage am Suchen. Aber schön,
daß es die Ingrid gibt. ;)
Jens schrieb:> $ unzip -l empty_8MByte_img.zip
Bleibt für mich noch die Frage, wo Du diese Zip-Datei her hast. Bei mir
hieß die nämlich mal myz80-img.zip.
Nächste Baustelle ;-)
Ich möchte eine Bootdiskette erstellen.
Variante 1: Klonen der Bootdisk mit SYSGEN
Aus nicht nachvollziehbarer Quelle hab ich ein SYSGEN (siehe Anhang):
1
C>a:load sysgen
2
3
FIRST ADDRESS 0100
4
LAST ADDRESS 04FF
5
BYTES READ 0400
6
RECORDS WRITTEN 08
7
8
9
C>dir
10
C: CLS HEX : SDIR HEX : SYSGEN HEX : SYSGEN COM
11
C>a:pip a:=sysgen.com
12
C>a:
13
A>sysgen
14
SYSGEN VER 2.0
15
SOURCE DRIVE NAME (OR RETURN TO SKIP)a
16
SOURCE ON A, THEN TYPE RETURN
17
FUNCTION COMPLETE
18
DESTINATION DRIVE NAME (OR RETURN TO REBOOT)c
19
DESTINATION ON C, THEN TYPE RETURN
20
FUNCTION COMPLETE
21
DESTINATION DRIVE NAME (OR RETURN TO REBOOT)
22
23
A>dir c:
24
NO FILE
25
A>
Komisch. Alle Dateien sind 'weg' und booten läßt sich von dem Image auch
nicht. Nur cpmls sieht die Dateien noch:
1
$ cpmls -f simhd /Volumes/CPM-DISK/CPMDSK_C.IMG
2
0:
3
cls.hex
4
sdir.hex
5
sysgen.com
6
sysgen.hex
Kann das überhaupt so gehen? Möglicherweise verwende ich SYSGEN falsch,
oder ich habe eine ungeeignete Version, oder SYSGEN kommt mit den großen
Images nicht klar.
Variante 2: Bauen der Bootdisk auf dem Hostsystem
Hostsystem ist bei mir ein MacOS X (10.9.5).
Erster Schritt: Ich brauche (einen/den?) z80asm
Hier habe ich einen gefunden:
http://wwwhomes.uni-bielefeld.de/achim/z80-asm.html
Der läßt sich aber nicht Kompilieren.
1. Versuch:
Ein CP/M-System direkt unter CP/M bauen hatte ich hier [1] mal
beschrieben.
Wenn du die SUB Datei unter CP/M benutzt, mußt du den Befehl w cpm.bin b
streichen, da er nur für den Simulator definiert ist.
[1]: Beitrag "Re: CP/M auf ATmega88"
Jens schrieb:> Ich möchte eine Bootdiskette erstellen.
Mein Vorschlag: Nachschauen, wie das Makefile im Zweig
'avrcpm/trunk/cpm/' vom SVN-Server Deines Vertrauens die Teile
zusammenstoppelt.
> Variante 1: Klonen der Bootdisk mit SYSGEN> Aus nicht nachvollziehbarer Quelle hab ich ein SYSGEN (siehe Anhang):
Möglicherweise wird dieses Sysgen die falschen Sektoren, oder zu wenige
kopieren.
> A>dir c:> NO FILE> A>> Komisch. Alle Dateien sind 'weg' und booten läßt sich von dem Image auch> Kann das überhaupt so gehen?
Theoretisch schon.
> oder ich habe eine ungeeignete Version,
Sehr wahrscheinlich. Im Anhang ist das Original-SYSGEN von DR. Statt die
Die Disk-Geometrie vom BIOS zu holen, liest (und schreibt) es die
Sektoren 1 bis 26 von Track 0 und 1.
Die großen Formate haben aber 32 oder noch mehr Sektoren pro Spur.
> oder SYSGEN kommt mit den großen Images nicht klar.
Von dem Sektorproblem abgesehen, eher nicht.
Das simh-Format hat 6 Spuren a 32 Sektoren für das System reserviert.
Das Directory kann dann eigentlich nicht überschrieben werden.
Wurden denn beide Images vor und nach SYSGEN als simh erkannt?
(Überprüfen mit 'A>stat dsk:')
Hier ist 'A' simh und 'G' myz80:
1
A>stat dsk:
2
3
A: Drive Characteristics
4
65344: 128 Byte Record Capacity
5
8168: Kilobyte Drive Capacity
6
1024: 32 Byte Directory Entries
7
1024: Checked Directory Entries
8
256: Records/ Extent
9
32: Records/ Block
10
32: Sectors/ Track
11
6: Reserved Tracks
12
13
G: Drive Characteristics
14
65536: 128 Byte Record Capacity
15
8192: Kilobyte Drive Capacity
16
1024: 32 Byte Directory Entries
17
1024: Checked Directory Entries
18
256: Records/ Extent
19
32: Records/ Block
20
128: Sectors/ Track
21
0: Reserved Tracks
> Variante 2: Bauen der Bootdisk auf dem Hostsystem> Hostsystem ist bei mir ein MacOS X (10.9.5).> Erster Schritt: Ich brauche (einen/den?) z80asm
Die BIOS-Quellen sind für den Microsoft M80 geschrieben. Die gängigen
Crossassembler sind oft nicht ganz kompatibel. Deshalb nehme ich m80.com
oder neuerdings slr180.com in einem CP/M-Emulator. Leider weiß ich
nicht, ob es einen passenden Emulator für MacOS gibt.
Joe G. schrieb:> Ein CP/M-System direkt unter CP/M bauen hatte ich hier [1] mal> beschrieben.
Der Thread ist ja inzwischen schon etwas unüberichtlich geworden. Das
war mir entgangen.
> Wenn du die SUB Datei unter CP/M benutzt, mußt du den Befehl w cpm.bin b> streichen, da er nur für den Simulator definiert ist.
Wie ruft man denn die SUB-Datei unter CP/M überhaupt auf?
Was braucht man alles dazu? Nur SUBMIT.COM oder auch XSUB.COM?
So tut sich jedenfalls nicht viel:
1
G>a:submit avrcpm.sub
2
3
G>
Wenn ich das Makefile/Buildscript/avrcpm.sub per Hand durchspiele
scheitere ich an diesem Punkt:
1
G>F:M80 =ZSDOS/M
2
3
...
4
5
U IF ROM
6
U IF ZS
7
P ORG ZSDOS+0DF9H
8
U IF ZS
9
U IF ROM
10
11
1197 Fatal error(s),108 Warning(s)
12
13
G>
Hab ich den falschen Assembler?
Leo C. schrieb:> Mein Vorschlag: Nachschauen, wie das Makefile im Zweig> 'avrcpm/trunk/cpm/' vom SVN-Server Deines Vertrauens die Teile> zusammenstoppelt.
Dort hab ich schon geschaut. Das entspricht ja im wesentlichen der
avrcpm.sub. Allerdings fehlen im Repository (URL:
svn://mikrocontroller.net/avr-cp-m/avrcpm/trunk/cpm) m.E. ein paar
wichtige Quellen, z.B. ZSDOS.MAC oder BDOS.MAC. Außerdem ist mir nicht
klar, wo die CPMxx.SYS herkommen, bzw. wie diese erstellt werden.
> Wurden denn beide Images vor und nach SYSGEN als simh erkannt?
Vorher ja, hinterher sieht es so aus :-/
1
A>stat dsk:
2
3
A: Drive Characteristics
4
65344: 128 Byte Record Capacity
5
8168: Kilobyte Drive Capacity
6
1024: 32 Byte Directory Entries
7
1024: Checked Directory Entries
8
256: Records/ Extent
9
32: Records/ Block
10
32: Sectors/ Track
11
6: Reserved Tracks
12
13
C: Drive Characteristics
14
1944: 128 Byte Record Capacity
15
243: Kilobyte Drive Capacity
16
64: 32 Byte Directory Entries
17
64: Checked Directory Entries
18
128: Records/ Extent
19
8: Records/ Block
20
26: Sectors/ Track
21
2: Reserved Tracks
Offenbar verändert SYSGEN die Laufwerkscharakteristik.
Den Ansatz mit SYSGEN werde ich später weiterverfolgen. Selber bauen ist
viel spannender.
> CP/M-Emulator ... für MacOS
Wird es sicher geben. Aber ich hab ja Zugriff auf das CP/M-System via
Terminalprogramm. Da brauch ich keinen Emulator :-)
Gute N8,
Jens
> Was braucht man alles dazu? Nur SUBMIT.COM oder auch XSUB.COM?> So tut sich jedenfalls nicht viel:
G>a:submit avrcpm.sub
Möglicherweise handelt es sich um das Problem, das hier
Beitrag "Re: CP/M auf ATmega88"
und hier
Beitrag "Re: CP/M auf ATmega88"
angesprochen wird.
> 1197 Fatal error(s),108 Warning(s)
So viele Fehler bekomme ich von M80 immer, wenn die Zeilenenden nicht
stimmen. Der besteht auf CR/LF.
Die SLR-Assembler schlucken auch Unix-Zeilenenden.
Jens schrieb:> Allerdings fehlen im Repository (URL:> svn://mikrocontroller.net/avr-cp-m/avrcpm/trunk/cpm) m.E. ein paar> wichtige Quellen, z.B. ZSDOS.MAC oder BDOS.MAC.
Vom BDOS hatten wir nie Sourcecode, findet man aber, wie ZSDOS im Netz.
> Außerdem ist mir nicht klar, wo die CPMxx.SYS herkommen, bzw. wie> diese erstellt werden.
Die 62K-Version hatte Sprite_tm in der Urfassung des Projekts schon
mitgeliefert.
http://spritesmods.com/?art=avrcpm&page=4
Die anderen hatte ich mal mir irgendeinem MOVCPM gebastelt. Das hatte
eine andere Seriennummer als Sprite_tms CP/M. Ich meine, die
Seriennummern angepaßt zu haben, weiß aber nicht mehr, wie weit ich
damit gekommen bin, und ob wirklich alles funktioniert, weil ich dann
auf ZSDOS umgestiegen bin.
> Offenbar verändert SYSGEN die Laufwerkscharakteristik.
SYSGEN kopiert höchstwahrscheinlich ab Track 0, Sektor 1, weil auf
Floppies die Sektornumerierung bei 1 beginnt. Da unsere Sektor-zählung
bei 0 beginnt, wird der erste Sektor nicht mitkopiert. Dieser enthält
beim simh-Format nicht nur den IPL, sondern auch eine Formatkennung.
Wenn diese nach dem Kopieren fehlt, wird das (ursprünliche)
AVRCPM-Standardformat angenommen.
Wenn Du das SYSGEN mal anpassen willst, kannst Du Dich an unserem IPL
orientieren, oder die Diskgeometrie aus dem BIOS auslesen, und dann
konsequenter weise auch die BIOS-Funktion für Sector-Translate
verwenden.
Leo C. schrieb:> G>a:submit avrcpm.sub>> Möglicherweise handelt es sich um das Problem, das hier
Bestimmt. Aber erstmal muss es manuel funktionieren. Dann schau mir das
nochmal an.
Und ich dachte immer so komisches Verhalten gibt es erst seit MS-DOS ;-)
>> 1197 Fatal error(s),108 Warning(s)> So viele Fehler bekomme ich von M80 immer, wenn die Zeilenenden nicht> stimmen. Der besteht auf CR/LF.
Die Zeilenenden waren bzw. sind es nicht. Viel einfacher: Es fehlt die
ZSDOS.LIB
Ich habe hier (http://www.znode.de/specials/zsdossrc/) eine gefunden,
jetzt kommt diese Ausschrift:
1
G>f:m80 =zsdos/m
2
P COMMON /_BIOS_/
3
4
1 Fatal error(s)
5
G>
Vielleicht könnt Ihr Eure ZSDOS.LIB nochmal zeigen, bzw. im Repository
einchecken.
> Die SLR-Assembler schlucken auch Unix-Zeilenenden.
Denn kann ich mir ja trotzdem mal anschauen.
>> Außerdem ist mir nicht klar, wo die CPMxx.SYS herkommen, bzw. wie>> diese erstellt werden.> Die 62K-Version hatte Sprite_tm in der Urfassung des Projekts schon> mitgeliefert.> http://spritesmods.com/?art=avrcpm&page=4
Ok.
> Die anderen hatte ich mal mir irgendeinem MOVCPM gebastelt. Das hatte> eine andere Seriennummer als Sprite_tms CP/M. Ich meine, die> Seriennummern angepaßt zu haben, weiß aber nicht mehr, wie weit ich> damit gekommen bin, und ob wirklich alles funktioniert, weil ich dann> auf ZSDOS umgestiegen bin.
ZSDOS ist offenbar eh das bessere BDOS.
> Wenn Du das SYSGEN mal anpassen willst, kannst Du Dich an unserem IPL
Später. Aber es wäre ein originalerer Weg, um eine Systemkopie
anzufertigen.
Viele Grüße,
Jens
Ich habe jetzt eine CPM.BIN!
Vielen Dank bis hierhin. Ohne Internet würde ich wahrscheinlich jetzt
noch Doku lesen.
Joe G. schrieb:> Wenn du die SUB Datei unter CP/M benutzt, mußt du den Befehl w cpm.bin b> streichen, da er nur für den Simulator definiert ist.
Jetzt bleibt nur noch eine Frage:
Wie bekomm ich die CPM.BIN (mit Bordmitteln) an die richtige Stelle der
'Boot-Diskette'?
Hier wird ja nach 'w' gleich aufgeräumt:
Jens schrieb:> Wie bekomm ich die CPM.BIN (mit Bordmitteln) an die richtige Stelle der> 'Boot-Diskette'?
Ich habe als "Boardmittel" die CP/M Tools verwendet.
mkfs.cpm.exe -f avrcpm -b cpm.bin -L test diskimage
Ich vermute jedoch, dass du mit "Boardmittel" direkt in CP/M die CPM.BIN
Datei in den Bootsektor schreiben möchtest, oder?
Jens schrieb:> Vielen Dank bis hierhin. Ohne Internet würde ich wahrscheinlich jetzt> noch Doku lesen.
...
> Jetzt bleibt nur noch eine Frage:> Wie bekomm ich die CPM.BIN (mit Bordmitteln) an die richtige Stelle der> 'Boot-Diskette'?
CPM/M 2.2 ALTERATION GUIDE
Diese Doku gibts im Internet. ;-)
Hah! Es bootet!
Vielen Dank, Jungs!
Joe G. schrieb:> Ich habe als "Boardmittel" die CP/M Tools verwendet.> mkfs.cpm.exe -f avrcpm -b cpm.bin -L test diskimage
Stimmt. So stehts ja auch im Makefile von Leo.
Bei mkfs.cpm kann man ja auch mehrmals -b <file> angeben. Kann man sich
da den Zusammenbau mit DDT bzw. dd evtl. sparen?
> Ich vermute jedoch, dass du mit "Boardmittel" direkt in CP/M die CPM.BIN> Datei in den Bootsektor schreiben möchtest, oder?
Ja. Das meinte ich eigentlich. Muß ja damals auch ohne Host-PC gegangen
sein.
Um das Bauen zu vereinfachen, hab ich jetzt SuperSUB probiert:
http://archives.scovetta.com/pub/walnut-creek/SIMTEL/SIGM/VOLS000/VOL085/SUPERSUB.ASM
Aber so richtig gesprächig sind dir Tools von damals alle nicht:
Habe diese Frage auch schon beim AX81-Projekt gestellt:
Da sich diese Arduino (Uno) Boards (mit ATmega328 und 16 MHz) immer
größerer Beliebtheit erfreuen - könnte das nicht eine alternative Basis
zum "CPM Stick" sein?
Es müsste ja "nur" der RAM-Kram auf ein Zusatz-Shield. USB usw. ist ja
schon alles drauf. Die SD-Card entweder mit auf das Zusatzshield oder
ein SD-Card-Shield.
Würde ich glatt mal probieren - 2 Fragen:
- reichen die 16 MHz auf dem Board aus?
- wahrscheinlich müsste man den Arduino-Bootloader überschreiben, oder?
Was meint ihr?
Gruß
Marcel
Marcel A. schrieb:> Würde ich glatt mal probieren - 2 Fragen:> - reichen die 16 MHz auf dem Board aus?
Ja. Ich habe bei der ATmega128-Variante auch 'nur' 16 MHz verwendet.
> - wahrscheinlich müsste man den Arduino-Bootloader überschreiben, oder?
Nicht zwingend. Ich weiß aber nicht, wie knapp es im 328 zugeht.
Die Pins müssten ja gerade so reichen (UART, I2C, SD-Karte und DRAM).
Jens
Hallo Jens,
habe mir das gerade noch mal genauer angesehen.
PINs sind alles da - ABER:
RX/TX ist hart verdrahtet auf die RX/TX-Pins des ATMega (PD0/PD1). Diese
werden aber im CPM-Stick für die RAM-Adressleitungen verwendet. Im Stick
gibt es stattdessen einen Soft-UART auf den Pins PB0/PB1.
Würde bedeuten, man müsste HW-mäßig auf der Arduino-Uno-Platine
rumbrutzeln - oder?
Zum Thema Bootloader: Habe ich das da richtig verstanden - wenn ich ein
mit AVR GCC erstelltes oder eben dieses "CPM-HEX" mit avrdude und "-c
arduino" flashe, dann ist das so wie mit der IDE und das HEX kommt
hinter den Bootloader (falls es passt...)?
Danke und Gruß
Marcel
Marcel A. schrieb:> Da sich diese Arduino (Uno) Boards (mit ATmega328 und 16 MHz) immer> größerer Beliebtheit erfreuen - könnte das nicht eine alternative Basis> zum "CPM Stick" sein?Beitrag "Re: CP/M auf ATmega88"
Marcel A. schrieb:> Es müsste ja "nur" der RAM-Kram auf ein Zusatz-Shield. USB usw. ist ja> schon alles drauf. Die SD-Card entweder mit auf das Zusatzshield oder> ein SD-Card-Shield.
z.B. so was:
http://www.ebay.de/itm/1Stk-XD-204-Data-logging-shield-fur-Arduino-UNO-SD-Card-/121505102595?pt=Wissenschaftliche_Ger%C3%A4te&hash=item1c4a44bb03
Da könnte man die RAMs gleich drauffrickeln. Und die Uhr könnte man auch
mitverwenden.
>> - wahrscheinlich müsste man den Arduino-Bootloader überschreiben, oder?
Wenn man den USB-Converter nur für den Download verwenden möchte, nicht.
Wenn man den USB-Converter aber auf die Pins des AVRCPM-Serial-IF
umlegt, kann man den Arduino Bootloader wahrscheinlich nicht mehr
verwenden. Mit Peter Danneggers Fastboot, oder mit dem SD-Bootloader
gehts aber.
Beitrag "Re: CP/M auf ATmega88"Jens schrieb:> Nicht zwingend. Ich weiß aber nicht, wie knapp es im 328 zugeht.
Platz satt.
Marcel A. schrieb:> RX/TX ist hart verdrahtet auf die RX/TX-Pins des ATMega (PD0/PD1). Diese> werden aber im CPM-Stick für die RAM-Adressleitungen verwendet. Im Stick
Datenbus. D.h., sie sind hochohmig, wenn nicht auf das RAM zugegriffen
wird, bzw, können auch noch für was anderes verwendet werden.
> gibt es stattdessen einen Soft-UART auf den Pins PB0/PB1.> Würde bedeuten, man müsste HW-mäßig auf der Arduino-Uno-Platine> rumbrutzeln - oder?
Ja.
Oder 4-Bit RAM.
> Zum Thema Bootloader: Habe ich das da richtig verstanden - wenn ich ein> mit AVR GCC erstelltes oder eben dieses "CPM-HEX" mit avrdude und "-c> arduino" flashe, dann ist das so wie mit der IDE und das HEX kommt> hinter den Bootloader (falls es passt...)?
Der Bootloader liegt am Flash-Ende. Das "HEX" kommt also davor.
Marcel A. schrieb:> Ja, für mich würde sich die Frage stellen, ob man mit dem USB-Seriell> irgendwie klar kommt ...
Wenn die Pins nicht umgelegt werden sollen, gehts noch mit 4-Bit RAM.
(Wenn 4-Bit RAM dann mal wieder geht...)
Für so ein Arduino-Ding würde ich aber Speicher nehmen, der aktuell
verfügbar ist. Serielle RAMs hab ich aber noch keine gesehen. (Im
Gegensatz zu seriellen 'ROMs' [=EEPROM]).
Grüße,
Jens
Konrad S. schrieb:> 23LCV1024
Danke, sieht auf den ersten Blick ganz nett aus. Aber als
Hauptspeicherersatz taugt es leider nicht, da der Speicher intern in
pages (zu 32 Bytes) segmentiert wird.
Parallele Speicher (SRAM) brauchen zu viele Pins für einen Arduino-Uno.
Alternativ könnte man den Ardino MEGA 2560 nehmen (15€ bei ebay). Den
finde ich aber nicht mehr so gängig, wie den Uno.
Oder SRAM (128k x 8) + 74164 (2x) für die Adresse.
Um 64k RAM anzusteuern braucht man
8 Pin Daten
2 Pin Steuerleitung (/OE & /WE)
2 Pin Adresse (seriell über 74164)
------
12 Pins, wobei man die Adresspins mit der SD-Karte teilen kann.
Allerdings dürfte die Zugriffszeit durch die serielle Ansteuerung noch
langsamer sein, als bei 4-Bit DRAM (inkl. Refresh).
Viele Grüße,
Jens
Jens schrieb:> da der Speicher intern in> pages (zu 32 Bytes) segmentiert wird.
Der 23LCV1024 hat auch einen "sequential mode", da kannst du beliebig
lesen/schreiben.
> Allerdings dürfte die Zugriffszeit durch die serielle Ansteuerung noch> langsamer sein, als bei 4-Bit DRAM (inkl. Refresh).
Klar, das ist der Preis für die geringere Anzahl an Pins.
Es gäbe auch noch serielles FRAM, z.B. FM25V02 (32kB, 6€) oder FM25V05
(64kB, 12€). Hätte auch seinen Reiz.
Jens schrieb:> Konrad S. schrieb:>> 23LCV1024> Danke, sieht auf den ersten Blick ganz nett aus. Aber als> Hauptspeicherersatz taugt es leider nicht, da der Speicher intern in> pages (zu 32 Bytes) segmentiert wird.
Spielt keine Rolle (Datenblatt):
1
- Byte, Page and Sequential mode for Reads and Writes
> Parallele Speicher (SRAM) brauchen zu viele Pins für einen Arduino-Uno.
Beim Arduino Uno sind alle I/O-Pins auf Steckerleisten geführt und damit
hat er genau so viele Pins wie die 28-Pin ATmegas, die wir normalerweise
für das Projekt nehmen.
> Alternativ könnte man den Ardino MEGA 2560 nehmen (15€ bei ebay). Den> finde ich aber nicht mehr so gängig, wie den Uno.
Wäre (auch) eine Möglichkeit.
> Oder SRAM (128k x 8) + 74164 (2x) für die Adresse.> Um 64k RAM anzusteuern braucht man> 12 Pins, wobei man die Adresspins mit der SD-Karte teilen kann.> Allerdings dürfte die Zugriffszeit durch die serielle Ansteuerung noch> langsamer sein, als bei 4-Bit DRAM (inkl. Refresh).
Wesentlich schneller, bei gleichem Hardware-Aufwand, dürfte diese
Variante sein:
Beitrag "Re: CP/M auf ATmega88"
Das SPI-RAM wäre natürlich auch erheblich schneller.
Zusammenfassung bis hier:
Für AVR-CP/M mit Arduino Uno sind folgende Varianten denkbar:
- Onboard USB-Schnittstelle nicht benutzen
- Onboard USB-Schnittstelle umverdrahten
- 4-Bit DRAM
- 8-Bit Static-RAM mit Adress-Latches
- SPI-RAM
Der SRAM mit den Adress-Latches ist eine sehr gute Idee.
Leo C. schrieb:> Zusammenfassung bis hier:> Für AVR-CP/M mit Arduino Uno sind folgende Varianten denkbar:> - Onboard USB-Schnittstelle nicht benutzen> - Onboard USB-Schnittstelle umverdrahten> - 4-Bit DRAM> - 8-Bit Static-RAM mit Adress-Latches> - SPI-RAM
Meiner bescheidenen Meinung nach sind nur zwei Dinge sinnvoll:
- Onboard USB nutzen
und
- 8-Bit SRAM oder SPI-RAM
und zusammen mit RTC und SD-Card auf ein Uno-kompatibles Shield.
Wenn es eine Entscheidung gibt, würde ich mich auch für Schaltplan,
Layout und Prototypfertigung zur Verfügung stellen.
Jens
Um AVR CP/M auf eine breitere Basis zu stellen, verfolge ich die Idee
mit den Arduinos ja schon länger. Bisher ist eine „gute“ Lösung immer an
den folgenden Problemen gescheitert.
- 5V Versorgung der Arduino UNO Versionen
- Rx/Tx Pins liegen falsch
Auch SRAM mit Latch bietet dabei keinen Ausweg. Auch hier müsste Rx/Tx
umverdrahtet werden. Für die 3.3V Lösung müsste entweder ein
Levelshifter für die SD-Card eingesetzt werden, oder das Arduino Board
auf 3.3V umgestellt werden. Irgendwie alles unbefriedigend.
Eine Alternative war ein Arduino „kompatibler“ Entwurf [1]. Dazu gibt es
von der Schaltung bis zum fertigen Layout alle Unterlagen.
Für ein „echtes“ Arduino Shield sehe ich nur die folgende Alternative:
- Arduino UNO auf 3.3V umstellen
- SPI-RAM (hat auch 3.3V !!) um die Original Rx/Tx Pins zu nutzen
Irgendwie alles unbefriedigend :-(
Besser sieht es mit der Arduino Pro Version aus. Die gibt es für 3.3V
UND 20 MHz OHNE USB. Auf dieses Shield könnte der RAM (SRAM oder SPI)
die SD-Card, die RTC und der V24-USB Wandler. Das Shield würde also bis
auf den Prozessor das komplette CP/M System zur Verfügung stellen. Doch
auch das macht eigentlich wenig Sinn. Dann kann man ja auch gleich auf
[1] zurückgreifen.
[1] Beitrag "Re: CP/M auf ATmega88"
Ich habe in der Mittagspause die Varianten nochmals überdacht.
Was haltet ihr von der folgenden Kombination:
- Arduino UNO OHNE Änderungen (5V und Rx/Tx auf den üblichen Pins)
als COM 2 für CP/M
- CP/M Shield mit 5V und 3.3V (Spannungsregler auf dem Shield)
- Levelshifter nur für für SD-Card und SPI-RAM ( z.B. TXB0108)
- RTC und I2C Porterweiterung auf 5V
- USB oder V24 für Terminal
- wenn noch Platz ist Propeller mit VT100 auf Shield
Um das System schnell wieder zum Laufen zu bringen, müsste nur die RAM
Lib gegen eine neue SPI-RAM Lib ausgetauscht werden. Aber dazu könnte
Leo C. ja vielleicht einen Kommentar zu abgeben.
Klingt gut - aber letztlich gehen schon die Vorteile des UNO in den
Hintergrund - es wird letztlich ja doch "nur" die CPU wiederverwendet.
Man müsste dann 2 USB-Kabel anschließen...
Aber was meint ihr?
Mir kommt gerade noch eine andere (wahrscheinlich dumme) Frage: Die
RAM-Chips für die 4-bit und 8-bit Adressierung (HW Varianten 1 + 2
(Stick)) sind doch die gleichen, oder?
> Mir kommt gerade noch eine andere (wahrscheinlich dumme) Frage: Die> RAM-Chips für die 4-bit und 8-bit Adressierung (HW Varianten 1 + 2> (Stick)) sind doch die gleichen, oder?
Edit, da Frage falsch gelesen:
Ja.
Joe G. schrieb:> Was haltet ihr von der folgenden Kombination:> - Arduino UNO OHNE Änderungen (5V und Rx/Tx auf den üblichen Pins)> als COM 2 für CP/M> - CP/M Shield mit 5V und 3.3V (Spannungsregler auf dem Shield)> - Levelshifter nur für für SD-Card und SPI-RAM ( z.B. TXB0108)> - RTC und I2C Porterweiterung auf 5V> - USB oder V24 für Terminal> - wenn noch Platz ist Propeller mit VT100 auf Shield
Für mich klingt das sehr vernünftig.
Mit Propeller drauf, wird der Platz wahrscheinlich zu knapp. Oder man
macht den Propeller gleich auf eine zweite Platine, so das man den noch
obenauf stapeln kann. Der braucht ja nur RX und TX.
Die RX-Signale (von Tastatur und UART) muß man irgendwie verodern.
Also irgendwie so:
1
2
=Propeller-Shield=
3
||||||| ||||||
4
===CP/M-Shield====
5
||||||| ||||||
6
===Arduino-Uno====
VGA und PS/2 gibt es auf dem Propeller-Shield. RAM und RTC auf dem
CP/M-Shield und UART und CPU auf dem Arduino.
> Um das System schnell wieder zum Laufen zu bringen, müsste nur die RAM> Lib gegen eine neue SPI-RAM Lib ausgetauscht werden.
Sollte machbar sein. Die Umstellung auf SIMM-Module war auch nicht
wirklich schwer.
Viele Grüße,
Jens
Da jetzt "alle" SPI-RAM wollen, versuchen wir mal herauszufinden, ob die
Geschwindigkeit davon im aktzeptablen Bereich liegen kann.
Zum Vergleich 8-Bit DRAM
Memory Read braucht 11 Takte.
Die Z80-Interpreter Hauptschleife braucht mindestens 25 Takte
(NOP-Befehl). Davon die 11 Takte für den Opcode-Fetch. Bei 20MHz
AVR-Takt würde das einem Z80 mit 3,2MHz entsprechen. Gemessen[1] hatte
ich mal 3,1Mhz. Die Differenz dürfte an den 1ms Timer- und den
Refresh-Interrupts liegen.
SPI-RAM ohne Cache
Die Berechnungen erfolgen unter optimalen Bedingungen: Macro, also ohne
Call/Ret Overhead und alle benötigten Daten in Registern. Es kann also
nur schlechter werden.
'CS Low' + 'Out CMD+Address' + 'In Data' + 'CS High'
= 2 + 3 x (16 +1) + (16 + 1) + 2
= 55 + 1x17
= 72
Der NOP-Befehl würde 72+14 = 86 Takte brauchen, entsprechend
ca. 0,93 MHz Z80.
16-Bit Zugriffe könnten optimiert werden:
(55 + 2x17)/2 = 44,5 Takte pro Byte.
Bei angenommenen 20% 16-Bit Zugriffen (wer macht mal ein Profiling?)
hätten wir ca 66 Takte pro RAM-Zugriff.
SPI-RAM mit Cache
Als hier der Vorschlag SPI-RAM kam, war meine erste Idee, daß das mit
Cache vielleicht sogar schneller laufen könnte, als DRAM. Schließlich
haben wir noch fast 600 Byte RAM frei. Das würde für einen 512-Byte
großen Cache ausreichen. Wenn wir auf den FAT-Buffer verzichten, hätten
wir sogar 1024 Byte für den Cache.
Welchen Cache brauchen wir?
Der einfachste Cache[2], mit einem einzigen Block in passender Größe,
wie z.B. in [3], ist beim Z80 wg. der geringen Lokalität von Code und
Daten wenig sinnvoll. Meiner Meinung nach ist er völlig ungeeignet, da
jeder Z80-Befehl mit Datenzugriff mindestens 2 Cache-Misses erzeugen
würde, wenn Code und Daten nicht im gleichen Block liegen. Letzteres ist
aber sehr wahrscheinlich. Sogar dann noch, wenn der Block 1024 Byte groß
wäre.
Das andere Extrem wäre ein mehrfach-assoziativer Cache mit möglichst
vielen kleinen Blöcken. Diese Variante scheidet offensichlich aus, weil
die Suche im Tag-RAM nach dem richtigen Block viel zu lange dauert. Und
der Verwaltungsaufwand für eine Verdrängungsstrategie käme noch dazu.
Bleibt "Direct Mapped" (einfach assoziativ) mit optimaler Blockgröße und
-Anzahl.
Damit der Cache einen Vorteil bringt, sollte der Zugriff bei einem Hit
schätzungsweise in der Größenordnung 20 Takte oder darunter liegen. Bei
einem Miss wird auf jeden Fall ein Vielfaches benötigt. Bei meinen
ersten Versuchen mit 32 Blöcken a 16 Byte (oder umgekehrt) brauchte ich
aber schon mehr als 15 Takte, um herauszufinden, ob der benötigte Block
im Cache ist. Die Berechnung des Offsets braucht dann nochmal mindestens
das Gleiche.
Aber vielleicht funktioniert das Ganze ja mit 4 Blöcken a 256 Byte.
Diese Variante würde sich extrem optimieren lassen. Das Low-Byte der
Addresse könnte z.B. direkt als Offset dienen. Die Valid- und
Dirty-Flags könnten (falls überhaubt benötigt) evtl. in Registern
gehalten werden.
Leider habe ich nicht die Zeit, um das alles auszuprobieren. Stattdessen
würde ich mich lieber um mein Z180-Projekt kümmern, das ja auch so schon
nur sehr schleppend voran kommt.
[1] Beitrag "Re: CP/M auf ATmega88"
[2] http://de.wikipedia.org/wiki/Cache
[3]
http://www.parallax.com/sites/default/files/downloads/AN012-SRAM-v1.0.pdf
Leo C. schrieb:> Da jetzt "alle" SPI-RAM wollen, versuchen wir mal herauszufinden, ob die> Geschwindigkeit davon im aktzeptablen Bereich liegen kann.
Das war doch schon eine sehr gute Abschätzung, danke!
SPI-RAM war ja auch nur ein Zugeständnis an einen unveränderten Arduino
UNO. Bei der Latch-RAM Variante müsste halt der ARDUIONO umverdrahtet
werden. Letztlich ist es sinnvoller die Ressourcen in den Z180 zu
stecken. AVR CP/M läuft ja :-)
Danke für die Abschätzung. SPI-RAM ist also zu langsam.
Dann die Variante mit den Adress-Latches.
Lohnt es sich dort ein drittes Latch (für die 'Bankadresse') einzubauen?
Kennt sich jemand aus, wie das Bankswitching realisiert sein muß, damit
CP/M 3.0 damit was anfagen kann? Dürfen die Bänke 64k groß werden, oder
müssen die kleiner sein (16k)?
Joe G. schrieb:> Bei der Latch-RAM Variante müsste halt der ARDUIONO umverdrahtet> werden.
Alternativ mußte man 4 Datenleitungen über Port C und die anderen über
Port D abhandeln. Geht natürlich wieder auf die Performance.
Hier nochmal der Link zum Schaltplan:
http://arduino.cc/de/uploads/Main/Arduino_Uno_Rev3-schematic.pdf
Umverdrahten würde ich vermeiden wollen.
Grüße,
Jens
Jens schrieb:> Danke für die Abschätzung. SPI-RAM ist also zu langsam.
Das habe ich nicht gesagt. ;-)
Dazu müßte zu langsam erst mal definiert werden. Wie schnell es mit
optimaler Cache-Strategie werden kann, ist auch noch offen. Es ist aber
abzusehen, daß es auch damit deutlich langsamer bleiben wird, als 8-Bit
DRAM.
> Dann die Variante mit den Adress-Latches.> Lohnt es sich dort ein drittes Latch (für die 'Bankadresse') einzubauen?
Das Latch ist bereits im µC vorhanden, da die Adressleitungen A16-A18
"ungemultiplexed" auf die µC-Ports gehen.
> Kennt sich jemand aus, wie das Bankswitching realisiert sein muß, damit> CP/M 3.0 damit was anfagen kann? Dürfen die Bänke 64k groß werden, oder> müssen die kleiner sein (16k)?
Siehe Bild (Quelle [1]). Die Größe des Common-Bereichs ist nicht
festgelegt. Typische Werte liegen zwischen 4K und 32K. Wie man dieses
Modell in Hardware (bzw. im Emulator) realisiert, ist nochmal ein
anderes Thema.
> Joe G. schrieb:>> Bei der Latch-RAM Variante müsste halt der ARDUIONO umverdrahtet>> werden.> Alternativ mußte man 4 Datenleitungen über Port C und die anderen über> Port D abhandeln. Geht natürlich wieder auf die Performance.
2 Leitungen verlegen würde reichen:
Leo C. schrieb:> 2 Leitungen verlegen würde reichen:
Der Performanceverlust um aus Port D und Port B wieder ein 8-Bit Wert zu
basteln, dürfte deutlich geringer sein als den RAM über SPI anzusteuern.
DRAM sollte sicherlich
+-------------------------------+
DRAM |D7 D5 D5 D4 D3 D2 |
|A7 A6 A5 A4 A3 A2 |
+-------------------------------+
heißen.
Als VT100 habe ich gerade eine erweiterte Version für das Z180 Projekt
in Betrieb genommen. Darauf gibt es noch einen Signalquellenumschalter.
Somit kann vom Terminal die Eigangsquelle ausgewählt werden. Dieses
Design ließe sich sicherlich auf ein passendes Shield bringen.
Wenn ich das richtig verstanden habe würde dann die Leitungen PD0/1 und
PB0/1 vertauscht werden - rein in Software. Ist das denn von der
Performance her realistisch?
Ansonsten denke ich auch, dass die UNOs dann als Plattform keinen Sinn
machen, wenn außer der CPM nicht weiter verwendet werden kann.
Meine ursprüngliche Idee war eigentlich nur ein "RAM-Shield" mit 2 x
RAM-IC und SD-Card zu ergänzen und fertig :-)
Noch mal eine Frage zu den Anfängen: Wozu ist eigentlich die RST-Leitung
auf dem USB-Seriell-Adapter auf dem CPM-Stick (HW-V2) da? Diese wird da
mit dem Reset des ATmega verbunden...? Kann man dann aus dem Terminal
den Stick resetten - wie?
Peter Sieg hatte einmal angemerkt, dass diese NICHT mit dem AVR-Reset
verbunden werden sollte - ist sie aber.
Da die 4Bit-RAM-Version ja nicht wirklich auf Z80 gebracht werden kann
und ich die HW V3 (Joes all-in-one) schon habe wollte ich mir den mal (8
Bit RAM) aufbauen. Aber die meisten CP2102-Adapter haben den RST nicht
herausgeführt. Stellt sich also die Frage, ob der überhaupt notwendig
ist.
Marcel A. schrieb:> Da die 4Bit-RAM-Version ja nicht wirklich auf Z80 gebracht werden kann
Wer behauptet denn so was?
Das Ding ist schon lange "auf Z80". Daß es angeblich nicht funktioniert,
wahrscheinlich gedebuged werden müßte, und dies zur Zeit niemand machen
will, ist eine andere Geschichte...
Leo C. schrieb:> Marcel A. schrieb:>> Da die 4Bit-RAM-Version ja nicht wirklich auf Z80 gebracht werden kann>> Wer behauptet denn so was?> Das Ding ist schon lange "auf Z80". Daß es angeblich nicht funktioniert,> wahrscheinlich gedebuged werden müßte, und dies zur Zeit niemand machen> will, ist eine andere Geschichte...
Ups - so habe ich das ja nicht gemeint. Ich habe da leider zu wenig Plan
von, um selber Hand anzulegen. Muss ja auch nicht sein - ist doch so
schon super.
> Ups - so habe ich das ja nicht gemeint.
Dann ist ja gut. :)
Du hast zwar 2 mal im Abstand von ein paar Wochen geschrieben, daß es
nicht wichtig sei, aber es scheint Dich ja doch zu beschäftigen...
Deshalb habe ich mal zurück geblättert.
Marcel A. schrieb:> So, ich habe mal meinen ersten Lochraster-Aufbau von "anno dazumal"> ausgegraben (siehe Foto), den mit ATMega88 und 4bit RAM.> Ich habe dem dann einen 328p spendiert und wollte die aktuelle> "firmware" mit Z80-Unterstützung draufbringen.
Das klingt so, als wäre das Ding "anno dazumal" schon mal gelaufen.
"Anno dazumal" gab es (mindestens) zwei 4-Bit Varianten, die leider
schön öfter für Verwirrung gesorgt haben. In der aktuellen Software ist
aber nur noch eine Pin-Belegung vorgesehen. Du könntest Deine
Verdrahtung mal mit der Definition in config.inc vergleichen.
Insbesondere diese Pins:
[avrasm]
;Port C
.equ RAM_D0 = 0
.equ RAM_D1 = 1
.equ RAM_D2 = 2
.equ RAM_D3 = 3
.equ RAM_W = 4
.equ RAM_CAS = 5
[avrasm]
Sicherheitshalber den Rest aber auch. Bei Unterschieden wäre es wohl am
Besten, wenn Du Deine Verdrahtung änderst.
Marcel A. schrieb:> Wozu ist eigentlich die RST-Leitung> auf dem USB-Seriell-Adapter auf dem CPM-Stick (HW-V2) da? Diese wird da> mit dem Reset des ATmega verbunden...? Kann man dann aus dem Terminal> den Stick resetten - wie?
Das Reset-Pin liegt einfach nur zur freien Verfügung auf der LP. In der
Bestückungsvariante FTDI wird es nicht benutzt. Man könnte es jedoch auf
RTS/CTS oder DTR/DSR legen und vom Terminal darüber Reset auslösen
(müßte jedoch noch programmiert werden)
Leo C. schrieb:> ;Port C> .equ RAM_D0 = 0> .equ RAM_D1 = 1> .equ RAM_D2 = 2> .equ RAM_D3 = 3> .equ RAM_W = 4> .equ RAM_CAS = 5>> Sicherheitshalber den Rest aber auch. Bei Unterschieden wäre es wohl am> Besten, wenn Du Deine Verdrahtung änderst.
Hallo Leo,
ich habe noch mal alles geprüft. Ich habe wohl die 4-Bit Version "neu",
also mit getauschten PC1/PC4. Verbindungen stimmen alle.
Derzeit läuft darauf eine Version für 8080 auf dem ATmega88. Ich kann
leider nicht sagen, welche Version, es meldet sich mit 1.0...
Ich vermute aber mal, dass ich eine Version drin habe mit nur einem
asm-file kompiliert und folgendem Inhalt:
1
#ifndef DRAM_DQ_ORDER /* If this is set to 1, the portbits */
2
#define DRAM_DQ_ORDER 1 /* for DRAM IO3 and WE are swapped. */
Teilweise sitzt das Problem (Z80 - 4Bit-Ram) auch vor der Tastatur...
Ich hatte zwar das neue HEX in den 328p geflashed - aber die Fuses nicht
angepasst - lief immer mit intern 8MHz.
Ich habe ihn nun genau wie den M88 auf "Ext-Full-Swing-Osz" (mit dem
Eclipse-Plugin) eingestellt - lfuse=77
Oder wäre "Ext Osz > 8MHz" besser?
Nun zeigt er wenigstens "Müll" im Terminal an und zwar im richtigen
Verhältnis/Startverhalten.... Der Müll ist aber immer das gleiche
Zeichen. Mit den seriellen Einstellungen habe ich schon gespielt -
bisher erfolglos. Aber ich denke, da könnte zumindest ein Teil meines
Problems liegen.
> Teilweise sitzt das Problem (Z80 - 4Bit-Ram) auch vor der Tastatur...
Das Problem sitzt fast immer vor der Tastatur. Man weiß nur oft nicht,
vor welcher... ;-)
> lfuse=77
Wenn das Hex ist, ist die "Divide clock by 8 internally; [CKDIV8=0]"
Fuse aktiviert.
Meine ATmega328P Fueses stehen auf:
avrdude: safemode: lfuse reads as D6
avrdude: safemode: hfuse reads as D2
avrdude: safemode: efuse reads as 7
ps:
Zum Rumspielen mit verschiedenen Einstellungen ist der "Engbedded Atmel
AVR® Fuse Calculator" gut zu gebrauchen:
http://www.engbedded.com/fusecalc/
So, das mit dem Takt war schon mal das Grundproblem - eigentlich ein
Klassiker... Grrrr (Hau mit dem Kopf auf die Tischkante....).
Nun, ich habe dann sicherheitshalber auch noch mal den aktuellen Stand
(V 154) übersetzt und geflashed. Es zeigt die gleiche Ausgabe wir der
manuell angepasste Stand auf dem 328er:
1
CPM on an AVR, v3.2 r0
2
Testing RAM: fill...wait...reread...
3
Addr xx yy
4
0000 00 FF -------- XXXXXXXX
5
0001 01 FF -------- XXXXXXX-
6
0002 02 FF -------- XXXXXX-X
7
0003 03 FF -------- XXXXXX--
8
0004 04 FF -------- XXXXX-XX
9
0005 05 FF -------- XXXXX-X-
10
0006 06 FF -------- XXXXX--X
11
0007 07 FF -------- XXXXX---
12
0008 08 FF -------- XXXX-XXX
13
0009 09 FF -------- XXXX-XX-
14
000A 0A FF -------- XXXX-X-X
15
000B 0B FF -------- XXXX-X--
16
000C 0C FF -------- XXXX--XX
17
000D 0D FF -------- XXXX--X-
18
000E 0E FF -------- XXXX---X
19
000F 0F FF -------- XXXX---- System halted!
Das dort r0 angezeigt wird liegt wohl auch daran, dass ich es als
Tar-Ball geladen habe und nicht richtig ausgeckekt habe. Muss mich mal
mit SVN befassen...
1
Warning: unable to find Subversion 1.7 'working copy' metadata.
Beim Lesen der Make-Meldungen ist mir aufgefallen, dass er die 8-Bit
Files für dram verwendet hat - musste da noch einen Schalter umlegen.
Jetzt verwendet er die 4bit-Files-aber gleiches Ergebnis.
ALso weitersuchen... :-)
Marcel A. schrieb:> CPM on an AVR, v3.2 r0> Testing RAM: fill...wait...reread...> Addr xx yy> 0000 00 FF -------- XXXXXXXX> 0001 01 FF -------- XXXXXXX-
Egal was ins RAM geschrieben wird, es wird immer 0xFF zurück gelesen.
Sieht nach einem Wrie-Only-Memory aus. ;) Könnte aber auch an der
Initialisierung liegen.
Früher (TM) sah die Portinitialisierung mal so aus:
1
; - Setup Ports
2
ldi temp,(1<<PUD) ;disable pullups
3
outm8 P_PUD,temp
4
ldi temp,0xFF
5
out PORTD,temp ;all pins high
6
out PORTB,temp
7
out PORTC,temp
8
out DDRD,temp ; all outputs
9
out DDRB,temp
10
out DDRC,temp
Du könntest in init.asm den Teil zwischen
"Setup Ports" und "outm8 TIMSK1,_0"
mal durch diese Zeilen ersetzen.
So, wir sind fast am Ziel :-)
Die oben genannte Änderung führ zur folgenden Ausgabe:
1
CPM on an AVR, v3.2 r0
2
Testing RAM: fill...wait...reread...
3
Initing mmc...
4
5
A: CP/M partition at: 062, size: 7657KB.
6
B: CP/M partition at: 15376, size: 7688KB.
7
C: CP/M partition at: 30752, size: 7688KB.
8
D: CP/M partition at: 46128, size: 7688KB.
9
Partinit done.
10
Ok, Z80-CPU is live!
Danach bleibt der Cursor aber stehen.
Kann das daran liegen, dass das CPM auf der SD noch für einen 8080 ist?
Wenn ich die SD-Card aus dem HW-4 Projekt (mit Propeller) reinstecke,
kommt:
1
CPM on an AVR, v3.2 r0
2
Testing RAM: fill...wait...reread...
3
Initing mmc...
4
5
A: FAT16 File-Image 'A' at: 003, size: 256KB.
6
B: FAT16 File-Image 'B' at: 007, size: 256KB.
7
C: FAT16 File-Image 'C' at: 011, size: 256KB.
8
D: FAT16 File-Image 'D' at: 023, size: 8192KB.
9
E: FAT16 File-Image 'E' at: 015, size: 250KB.
10
F: FAT16 File-Image 'F' at: 019, size: 256KB.
11
G: FAT16 File-Image 'G' at: 283, size: 8192KB.
12
Partinit done.
13
Ok, Z80-CPU is live!
14
15
62k cp/m vers 2.2
16
17
A>dir
Bei Eingabe von "dir" stürzt er aber ab.
Hängt das ggf. mit diesen Einstellungen im MakeFile zusammen
(FAT/CPM-Support)?
1
#FAT16_SUPPORT = 0
2
#CPMDSK_SUPPORT = 0
3
#MMCBOOTLOADER = 0
Das "Problem" in der Init.asm für 4-bit liegt für mein (rudimentäres)
Assembler-Verständnis darin, dass in der aktuellen Fassung:
1
; - Setup Ports
2
3
; ldi temp,(1<<PUD) ;disable pullups
4
; outm8 P_PUD,temp
5
out PORTD,_255 ;all pins high (enables pullup on input ports)
6
out PORTB,_255
7
out PORTC,_255
8
out DDRD,_255 ; PD all outputs
9
#if I2C_SUPPORT
10
ldi temp,~((1<<SCL)|(1<<SDA))
11
out DDRC,temp
12
#endif
13
#if DRAM_8BIT
14
ldi temp,~(1<<RXD)
15
out DDRB,temp
16
#endif
die "out DDRC" und "out DDRB" in den IF-Schachteln stecken und daher bei
4-Bit nicht angesprochen werden und damit die Ports nicht richtig
initialisiert werden.
Marcel A. schrieb:> Kann das daran liegen, dass das CPM auf der SD noch für einen 8080 ist?
Nein, daß könnte der Z80-Emulator (mindestens) genau so gut. Es liegt
eher daran, daß das BIOS nicht mehr zu der Schnittstelle im Emulator
paßt.
> Wenn ich die SD-Card aus dem HW-4 Projekt (mit Propeller) reinstecke,
Welcher Firmwarestand ist den auf dem Gerät drauf?
Könnte das gleiche Problem sein, ich glaubs aber eher nicht.
Wahrscheinlich ist noch was anderes faul.
Marcel A. schrieb:> die "out DDRC" und "out DDRB" in den IF-Schachteln stecken und daher bei> 4-Bit nicht angesprochen werden und damit die Ports nicht richtig> initialisiert werden.
Die IF-Schachteln habe ich erst kürzlich eingebaut, eben wegen dem 4-Bit
RAM. War offensichtlich ein Schuß in den Ofen.
Fast vergessen:
Ich wollte ein Image mitschicken, daß mit Deinem Softwarestand auf jeden
Fall laufen sollte. Leider habe ich gerade ein Problem.
So - es läuft FAST alles.
Das meine Karte aus der alten HW gar nicht geht ist klar - das war noch
das Partitions-Schema und nicht das FAT16-System.
Den Fehler mit dem Absturz nach dem Boot habe ich sowohl mit meinem CPM
Image als auch mit dem von Leo. Aber nicht immer. Meistens startet er
durch, ich kann auch einiges machen.
Es fällt aber auf, dass einige Zeichen "komisch" sind...
Ich konnte sogar Turbo Pascal starten
Der Aufruf von kompilierten COM-Dateien geht dafür aber wieder.
Manchmal klappt auch der Wechsel der Disketten - manchmal nicht.
Habe auch mal die Geschwindigkeit von 57600 auf 38400 geändert - keine
Änderung.
Hier mal ein Auszug, was sich so tut und was für Fehlermeldungen kommen.
Ich würde sagen: Im Grund geht es jetzt - aber irgendwo ist noch was
faul.
Was wäre eigentlich der Vorteil der 8bit-Variante? War das nur
Geschwindigkeit?
Leo, das mit den IFs war sicher kein Schuss in den Ofen. Das war schon
genau das Problem, wahrscheinlich müsste man die IFs nur anders
aufbauen.
Marcel A. schrieb:> Es fällt aber auf, dass einige Zeichen "komisch" sind...
Wirklich sehr mysteriös.
> Habe auch mal die Geschwindigkeit von 57600 auf 38400 geändert - keine> Änderung.>> Hier mal ein Auszug, was sich so tut und was für Fehlermeldungen kommen.> Ich würde sagen: Im Grund geht es jetzt - aber irgendwo ist noch was> faul.
Ich hätte da immer noch das Speichertiming im Verdacht.
> Was wäre eigentlich der Vorteil der 8bit-Variante? War das nur> Geschwindigkeit?
Meines Erachtens: ja
Grüße,
Jens
Vielleicht sollte ich mal den Speicher tauschen?
Hm... Es stellt sich die Frage, ob es wirklich den Aufwand lohnt, das
Thema 4Bit "gerade" zu biegen. Einziger Grund kann ja letztlich nur
sein, dass die DRAMs nicht mehr ganz so leicht zu beschaffen sind.
Ich denke, ich werde als nächsten mal den "Stick" bauen, dann habe ich
fast alles (alte) HW zusammen und kann dann hoffentlich mit dem Z180
Projekt anfangen.
Über Weihnachten werde ich mal mehr über den Z80 und CPM lesen.
(Rolf-Dieter Klein's Buch, Rodnay Zak, NCR Kleinkomputer.... Schon nett
:-))
> Vielleicht sollte ich mal den Speicher tauschen?
Eher nicht. Auch wenn es wirklich Timing-Probleme sind, heißt das nicht,
das es am RAM-Chip liegt. Ich vermute aber eher, daß die Initialisierung
immer noch nicht in Ordnung ist, bzw. daß Port-Register irgendwo
verändert werden, wo sie es nicht sollten. Es ist etwas mühsam, das
durch starren auf den Bildschirm herauszufinden. Vielleicht stecke ich
mir doch mal so ein System zusammen. Dieses Jahr aber nicht mehr.
Hallo,
ich möchte auch endlich mal den CP/M Computer nachbauen.
Hat noch jemand eine von diesen Platinen übrig?
http://www.mikrocontroller.net/articles/Datei:Avr_cpm2.jpg
Wenn nicht, würde ich gerne welche fertigen lassen. Hat sonst noch
jemand Interesse? Ich hätte auch noch ein paar Speicherchips KM44C4100
oder M5M44256
abzugeben.
Gruß
Cord
Hi,
ich habe gerade das CP/M-Stick-Layout (Peter Sieg) überarbeitet (ohne
FTDI, für gängige USB-Sticks, etwas kleiner und für "günstigere" SD Card
Reader.
Die Platinen sind bestellt, dauert aber eine Weile. Teile wie USB-Sticks
und Reader habe ich auch... Bei Bedarf einfach melden.
Gruß
Marcel
Marcel A. schrieb:> Hi,>> ich habe gerade das CP/M-Stick-Layout (Peter Sieg) überarbeitet (ohne> FTDI, für gängige USB-Sticks, etwas kleiner und für "günstigere" SD Card> Reader.>> Die Platinen sind bestellt, dauert aber eine Weile. Teile wie USB-Sticks> und Reader habe ich auch... Bei Bedarf einfach melden.>> Gruß> Marcel
@Marcel: Das PCB Layout/Schaltung stammt von Joe G., nicht von mir.
Kannst du bitte deine Überarbeitete Version als Eagle Dateien hier zur
Verfügung stellen? Welcher SD Slot ist jetzt verwendet?
Peter
Ich spiele ja schon seit einiger Zeit gerne mit dem AVRCP/M rum.
Dabei habe ich inzwischen schon öfter den Wunsch nach einer freien
RS232-Schnittstelle verspürt.
Man könnte diese dann prima für Dateiübertragungen zur 'richtigen' CP/M
Systemen benutzen.
Die vorhandene ist ja ausschließlich fürs Terminal.
Inwieweit wäre sowas realisierbar ?
Am einfachsten wäre das mit einem UART an I2C zu realisieren. Dafür gibt
fertige Chips, die aber teuer und schlecht erhältlich sind.
Vor einiger Zeit hatte ich mal angefangen, so einen I2C-UART mit einem
ATTiny2313 zu realisieren. Mangels eigenem Bedarf und übertriebener
Featuritis ist das Projekt irgendwann liegen geblieben.
> -itis
Entzündung?
Man kann auch einen Bitbanging UART auf freien Pins verwenden. Meistens
ist auch keine echte bidirektionale Verbindung nötig, also kommt man auf
dem Controller mit einem Pin aus, bei Bedarf als Eingang oder Ausgang.
Leo C. schrieb:> Am einfachsten wäre das mit einem UART an I2C zu realisieren. Dafür gibt> fertige Chips, die aber teuer und schlecht erhältlich sind.
Den SC16IS740 gibt es für 2,77€/Stück bei Mouser.
AVR-CP/M-Propeller-Terminal
Hier mal was zum Testen. Neue/aufgebesserte Software für das Terminal.
Liegt auch schon seit ein paar Tagen auf dem SVN-Server[1]. Ein paar
Fehler wurden beseitigt, ein paar weitere VT100-Funktionen hinzu gefügt,
und etwas schneller ist sie auch.
Ich habe vor, die Software noch weiter auszubauen und zu beschleunigen.
Außerdem soll sie an die stand-alone Version des Terminals[2] angepaßt
werden, zumal Joe mir eine Platine dafür geschenkt hat.
[1]
http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/VT100/source/work/
[2] Beitrag "VT100-Terminal (VGA+PS2)"
Peter Sieg schrieb:> Warum? Weil es geht! Und weil es Spaß macht zu zeigen, das es geht..> Und weil ein ATmega88 ca. 3€ kostet, eine solches DRam gibts in der> Schrottkiste (sind z.B beim Amiga 500 verwendet worden..) also alles> für ca. 6-8€..
Noch preiswerter, zum Nulltarif, aber hier wohl weniger von Reiz: CP/M
unter Windows mittels kostenfreiem, seit vielen Jahren bewährtem Emu, z.
B. via download von meiner site sharpmz.org. Dort gibts auch
verschiedene CP/M-Versionen, haufenweise Spiele, tonnenweise Software,
diskimages und und und... Der schnellste Weg, um CP/M zum Laufen zu
bringen. Anleitung bei Interesse im eigenen Thread oder via PN.
Propeller-Terminal für die AVR-CP/M-Platine
Die Entwicklung der Software geht im Thread "VT100-Terminal (VGA+PS2)"
hier
Beitrag "Re: VT100-Terminal (VGA+PS2)"
weiter, da die Hardwareunterschiede zwischen den beiden Terminals ja
gering sind.
Joe G. schrieb:>> Am einfachsten wäre das mit einem UART an I2C zu realisieren. Dafür gibt>> fertige Chips, die aber teuer und schlecht erhältlich sind.>> Den SC16IS740 gibt es für 2,77€/Stück bei Mouser.
Oder knapp 9€ für 5 Stück inclusive alles beim Ali.
Also gut, gestern sind sie angekommen, und mindestens einer funktioniert
sogar. Deshalb gibts im SVN jetzt minimalen Support für den Chip. Die
Register des UARTs sind zwischen 50H und 5FH in den I/O-Addressraum des
Z80 gemappt, können also mit IN- und Out-Befehlen angesprochen werden.
Einfache In- und Out-Routinen können dann z.B. so aussehen:
Für den I2C-UART gibts jetzt ein Kermit. Damit er läuft braucht man die
neueste Firmware. Beides als Binaries im Anhang. Die Kermit-Quellen sind
vorläufig auf meinem Server[1], und kommen demnächst ins hiesige SVN.
[1] http://cloudbase.mooo.com/cgit/Kermit-80/
Hallo,
ich habe mir kürzlich auch einen avrcpm-Rechner zusammengebaut mit
ATmega328P, 20 MHz, 8bit DRAM und einer 1 GB SD-Karte.
Als Firmware hatte ich erst die Version 3.2 r154, dann Version 3.5 r242.
Die Anbindung über RS232 zum PC läuft mit einem CP2102-Dongle und 115200
baud. Einen I2C-UART habe ich noch nicht angeschlossen.
Ich habe dann probiert, Kermit-80 4.11 (zusammengebastelt nach der
Anleitung ftp.kermit.columbia.edu/kermit/cpm80/cpkerm.pdf) zu verwenden:
Kermit läuft zwar unter CP/M im avrcpm und ich kann im Prinzip auch
Dateien zwischen PC und avrcpm hin- und herschicken (ich verwende
TeraTerm und dessen eingebautes Kermit-Protokoll auf der PC-Seite), aber
die Transferrate ist mit ca. 20 Bytes/s nicht brauchbar.
Ich habs so probiert: auf der CP/M-Seite kerm411.com gestartet und die
folgenden Befehle im Kermit abgesetzt:
set local-echo on
set port crt
receive
danach in TeraTerm mit File/Transfer/Kermit/Send... eine Datei
ausgewählt und übertragen. Diese ist dann im CP/M System auch
angekommen, aber mit nur ca. 20 Bytes/s.
Die umgekehrte Richtung geht auch:
im CP/M-Kermit diese Befehle absetzen:
set local-echo on
set port crt
send foo.bar
dann in TeraTerm File/Transfer/Kermit/Receive
foo.bar kommt dann auf dem PC an, aber auch nur mit der langsamen
Transferrate von ca. 20 Byte/s.
Mache ich da irgendwas grob falsch? Der Kermit-Transfer funktioniert ja
im Prinzip, aber ich verstehe nicht, warum die Transferrate so klein
ist...
Gruss,
Andreas
Hallo Andreas,
ich hatte das auch schon für die Z180 Stamp gebaut. Aber dort habe ich
für die "Console" und die Kermit-Schnittstelle zwei unterschiedliche
Ports genommen. Mich wundert, dass das überhaupt über die gleiche
geht...?
Gruß
Marcel
Andreas R. schrieb:> Ich habe dann probiert, Kermit-80 4.11 (zusammengebastelt nach der> Anleitung ftp.kermit.columbia.edu/kermit/cpm80/cpkerm.pdf) zu verwenden:
Du hast ein "Generic Kermit-80" gebaut?
> set local-echo on
Das dürfte für Dateiübertragung keine Rolle spielen. Im Zweifelsfall ist
es eher kontraproduktiv.
> set port crt
Das dürfte überflüssig sein, weil die IOBYTE-Funktionalität im
AVR-CP/M-BIOS nicht implementiert ist.
Versuch' mal noch ein:
set terminal quiet
Dann werden während der Dateiübertragung keine Zeichen auf die Console
ausgegeben.
> Mache ich da irgendwas grob falsch? Der Kermit-Transfer funktioniert ja> im Prinzip, aber ich verstehe nicht, warum die Transferrate so klein> ist...Marcel A. schrieb:> Mich wundert, dass das überhaupt über die gleiche> geht...?
me too.
Hallo,
danke für die Rückmeldungen.
Leo C. schrieb:> Andreas R. schrieb:>> Ich habe dann probiert, Kermit-80 4.11 (zusammengebastelt nach der>> Anleitung ftp.kermit.columbia.edu/kermit/cpm80/cpkerm.pdf) zu verwenden:>> Du hast ein "Generic Kermit-80" gebaut?>
Genau...
>> set local-echo on>> Das dürfte für Dateiübertragung keine Rolle spielen. Im Zweifelsfall ist> es eher kontraproduktiv.>
Stimmt, wie sich herausgestellt hat, macht dieser Befehl keinen
Unterschied...
>> set port crt>> Das dürfte überflüssig sein, weil die IOBYTE-Funktionalität im> AVR-CP/M-BIOS nicht implementiert ist.
Dieser Befehl ist aber offenbar (bei mir zumindest) nötig, sonst bekomme
ich gar keine Kermit-Verbindung hin...
> Versuch' mal noch ein:> set terminal quiet>> Dann werden während der Dateiübertragung keine Zeichen auf die Console> ausgegeben.
Das hat bei mir nichts gebracht, d.h. die Transferrate ist immer noch
bei ca. 20 Bytes/s :-(
>> Mache ich da irgendwas grob falsch? Der Kermit-Transfer funktioniert ja>> im Prinzip, aber ich verstehe nicht, warum die Transferrate so klein>> ist...>> Marcel A. schrieb:>> Mich wundert, dass das überhaupt über die gleiche>> geht...?>> me too.
Geht es vielleicht, weil ich TeraTerm unter Windows benutze? Ich habs
noch nicht unter Linux (mit z.B. minicom) probiert...
Danke und Gruss,
Andreas
Inzwischen habe ich mir auch ein "Kermit-80 v4.11 configured for Generic
CP/M-80 with VT100" gebaut und einiges ausprobiert. Im Grunde hätte aber
etwas Nachdenken und ein Blick in den Sourcecode gereicht, um darauf zu
kommen, daß das nicht funktionieren kann. ;-)
Das Kermit-Programm fragt während der Übertragung eines Pakets auch
immer die Consolenschnittstelle ab, damit der Benutzer die Übertragung
ggf. abbrechen kann (Funktion inchr in cpspk2.asm). Da Com.- und
Consolenschnittstelle aber die Gleiche ist, werden dadurch Zeichen, die
zu Datenpaketen gehören, als Consoleninput gelesen, und verworfen.
Wenn man die Consolenabfragen an den entsprechenden Stellen rauswerfen
würde, könnte es funktionieren...
Hallo,
Leo C. schrieb:> Inzwischen habe ich mir auch ein "Kermit-80 v4.11 configured for> Generic> CP/M-80 with VT100" gebaut und einiges ausprobiert. Im Grunde hätte aber> etwas Nachdenken und ein Blick in den Sourcecode gereicht, um darauf zu> kommen, daß das nicht funktionieren kann. ;-)>> Das Kermit-Programm fragt während der Übertragung eines Pakets auch> immer die Consolenschnittstelle ab, damit der Benutzer die Übertragung> ggf. abbrechen kann (Funktion inchr in cpspk2.asm). Da Com.- und> Consolenschnittstelle aber die Gleiche ist, werden dadurch Zeichen, die> zu Datenpaketen gehören, als Consoleninput gelesen, und verworfen.>> Wenn man die Consolenabfragen an den entsprechenden Stellen rauswerfen> würde, könnte es funktionieren...
Vielen Dank Leo, das war der entscheidende Hinweis!
Ich habe in cpspk2.asm, Zeile 936 den Befehl
call inpcon ; Try to get a character from the console
durch drei NOPs ersetzt - nun kriege ich vernünftige
Kermit-Datenübertragungsraten hin (ca. 700 Byte/s für PC->avrcpm und ca.
1.4 kByte/s für avrcpm->PC). Ich verwende TeraTerm unter Windows - ich
werde aber auch noch minicom unter Linux testen. Ausserdem muss ich noch
weitere Tests machen zur Zuverlässigkeit der Datenüebertragung.
Konkret habe ich aber nicht den Kermit-Sourcecode geändert und neu
kompiliert, sondern mein kerm411.com gepatcht: die Bytefolge "CD 1A 70"
bei Offset 2A19 wurde durch "00 00 00" ersetzt.
Ich glaube, nun haben wir einen bequemen Weg, Dateien von und zum avrcpm
zu übertragen, ohne jedesmal mit der SD-Karte hantieren zu müssen. Was
fehlt ist halt die Möglichkeit, die Datenübertragung zu unterbrechen -
man muss wohl den avrcpm mit dem Resettaster neu starten, falls das
nötig ist...
Grüsse und schönes Wochenende,
Andreas
Leo C. schrieb:> Für den I2C-UART gibts jetzt ein Kermit.
Prima, läuft...
A>kerm411
Kermit-80 v4.11 configured for AVR-CP/M with VT100
UART detected, crystal frequency: 11.0592 MHz.
Da hat das ganze mal jemand auf einem Arduino Nano umgesetzt:
https://acdc.foxylab.com/node/76
Das einzige zusätzliche Bauteil ist eine SD-Karte, die auch gleich als
RAM herhalten muß.
Hier noch das passende Video, für die, die kein Russisch können oder
Google-Translate nicht kennen:
https://youtu.be/LHFmt3qWAuY
Grüße,
Jens
Danke für die Info!
Eine sehr interessante Lösung, die SD-Card gleich als RAM zu nutzen.
Warum sind wir nicht darauf gekommen :-( Einzig die Umsetzung in GO
scheint mir recht langsam und die Beschränkung auf einen 8080. Aber mit
einer Micro-SD sollte nun ein CP/M in einem kleinen USB-Stick Gehäuse
möglich sein :-)
Joe G. schrieb:> Eine sehr interessante Lösung, die SD-Card gleich als RAM zu nutzen.
Stimmt.
> Warum sind wir nicht darauf gekommen :-( Einzig die Umsetzung in GO
Weil "uns" sogar SPI-RAM schon zu langsam war. Siehe
Beitrag "Re: CP/M auf ATmega88" ff.
Joe G. schrieb:> Einzig die Umsetzung in GO scheint mir recht langsam
Wenn ich den durch Google-Translate gedrehten Text richtig verstehe, ist
nur das PC-Programm zum Senden einer Hex-Datei an den Arduino, in Go
geschrieben. Von der Arduino-Software (Monitor und Emulator) habe ich
keine Quellen gefunden.
> und die Beschränkung auf einen 8080.
Reicht für mindestens 99% aller verfügbaren CP/M Programme. Aber soll ja
trozdem noch geändert werden.
Leo C. schrieb:> nur das PC-Programm zum Senden einer Hex-Datei an den Arduino, in Go> geschrieben.
Stimmt, habe ich dann auch gelesen. Mein Russisch ist echt eingerostet,
ich habe buchstabiert wie ein Anfänger :-(
Den Simulator hat er offensichtlich selbst programmiert ohne das die
Quellen derzeit verfügbar sind.
"я решил две задачи - создал эмулятор процессора Intel 8080."
Leo C. schrieb:>> Offenbar verändert SYSGEN die Laufwerkscharakteristik.>> SYSGEN kopiert höchstwahrscheinlich ab Track 0, Sektor 1, weil auf> Floppies die Sektornumerierung bei 1 beginnt. Da unsere Sektor-zählung> bei 0 beginnt, wird der erste Sektor nicht mitkopiert. Dieser enthält> beim simh-Format nicht nur den IPL, sondern auch eine Formatkennung.> Wenn diese nach dem Kopieren fehlt, wird das (ursprünliche)> AVRCPM-Standardformat angenommen.>> Wenn Du das SYSGEN mal anpassen willst, kannst Du Dich an unserem IPL> orientieren, oder die Diskgeometrie aus dem BIOS auslesen, und dann> konsequenter weise auch die BIOS-Funktion für Sector-Translate> verwenden.
Das habe ich jetzt gemacht. Ich habe syscop.c [1] für unsere Zwecke
modifiziert.
Als Compiler habe ich BDS-C verwendet:
1
C>CC AVRSYSCP
2
BD Software C Compiler v1.60 (part I)
3
24K elbowroom
4
BD Software C Compiler v1.60 (part II)
5
25K to spare
6
C>CLINK AVRSYSCP
7
BD Software C Linker v1.60
8
9
Last code address: 2BCE
10
Externals start at 2BCF, occupy 0006 bytes, last byte at 2BD4
11
Top of memory: DA05
12
Stack space: AE31
13
Writing output...
14
35K link space remaining
Anschließend kann man entweder die Systemspuren in eine Datei sichern:
1
C>AVRSYSCP A: SYSTRKS.BIN 52
oder -tada- eine Datei in die Systemspuren schreiben:
1
C>AVRSYSCP CPM.BIN A:
Wenn ich das richtig verstanden habe, muß bei 8MB-Images die
Formatkennung "<CPM_Disk>" am Ende des ersten Sektors (0x76...0x7f)
stehen, damit das modifizierte Image funktioniert.
Die Anpassung dafür könnte in IPL.MAC stattfinden.
Ein weiteres .org im Quelltext führt zu einem
Jens schrieb:> Ein weiteres .org im Quelltext führt zu einem> B>m80 =ipl8m/m> P org 176h
Das ".org" hast Du am Ende vor dem "end" eingefügt?
Wahrscheinlich mußt Du davor noch ein ".dephase" schreiben.
Leo C. schrieb:> Wahrscheinlich mußt Du davor noch ein ".dephase" schreiben.
Ja, das scheint zu klappen.
Ich habe auch noch einen anderen Weg gefunden.
Wenn man mit DDT die Teile zusammenlinkt, kann man noch die folgenden
Kommandos anhängen:
Hallo Ihr,
ich kann ein AVR CP/M Stick in der Rev.3 (USB Stick Form) bekommen,
inkl. USB TTL Wandler, welcher afaik als Terminal Zugang dient.
Ich komme aus der DOS Zeit, bzw. dem ehem. DDR BIC 5105/ 5110.
Ich habe mir schon einige CP/M Emulatoren geholt, um üben zu können. Ich
scheitere aber am erstellen der Disketten, bzw. am einbinden/ mounten
der Disketten. Ich habe JAZE 2.04.x und einen Z80 Emulator getestet. Bei
JAZE 2.4.x habe ich mir eine Diskette erstellt, bekomme aber die
herunter geladenen Programme nicht auf die virtuelle Diskette... Den Z80
Emulator 1.0.10.x bekomme ich nicht einmal gestartet. Was das angeht,
ist JAZE doch einfacher zu starten, da dieser vorkonfiguriert ist und
eine CP/M Version bei liegt.
Ich möchte mir gerne ein solchen Stick holen, um die frühere Zeit der
Computer kennen zu lernen. Ich habe und hatte ältere Computer, will aber
etwas näher an die Wurzeln heran. Bevor ich das aber mache, will ich das
zuerst einmal Virtuell sehen.
Wer kann mir einen Emulator empfehlen, wo ich CP/M für Z80, bzw. den
i8080 testen kann, bevor ich mir einen solchen Stick bauen lasse?
LG Ronny
Ronny M. schrieb:> Wer kann mir einen Emulator empfehlen, wo ich CP/M für Z80, bzw. den> i8080 testen kann
YAZE hast du ja schon genannt. Neben vielen anderen
Simulationsprogrammen gibt es noch AltairZ80 [1]. Dort lassen sich u.a.
verschiedene Betriebssysteme u.a. CP/M, simulieren.
[1] http://schorn.ch/index.html
Joe G. schrieb:> Ronny M. schrieb:>> Wer kann mir einen Emulator empfehlen, wo ich CP/M für Z80, bzw. den>> i8080 testen kann>> YAZE hast du ja schon genannt. Neben vielen anderen> Simulationsprogrammen gibt es noch AltairZ80 [1]. Dort lassen sich u.a.> verschiedene Betriebssysteme u.a. CP/M, simulieren.>> [1] http://schorn.ch/index.html
Ich bekomme leider keine Diskimages für Yaze erstellt, bzw. keine
Programme in eine *ydsk rein geschoben.. Weist Du, wie das geht?
Danke für dem Tipp zum Altair Emulator. Ich denke aber, dieser passt
nicht zum Rev. 3 Board. Da ist wohl YAZE passender. Nur, wie bekomme ich
eine Datei, ein Program auf die *.ydsk...?
Vielen Dank für die Hilfe :)
Ronny M. schrieb:> Danke für dem Tipp zum Altair Emulator. Ich denke aber, dieser passt> nicht zum Rev. 3 Board. Da ist wohl YAZE passender.
Mit YAZE habe ich noch nicht gearbeitet aber was hat die Rev. 3 was
anders sein sollte? Ist doch auch nur ein AVR mit RAM. Und CP/M ist
CP/M. Ich hatte damals alle meine Laufwerke unter dem AltairZ80
erstellt.
Hallo,
das hat sich inzwischen erledigt. YAZE habe ich wieder gelöscht. SIMH
Altair Z80 hat die Aufgabe der Emulation übernommen. Aber auch das hat
sich in einigen Tagen erledigt. Peter Sieg hat in der Bucht ein Set aus
CPM Stick + USB-Serial Adapter angeboten, welches ich mir gekauft habe.
Das ganze ist in wenigen Tagen bei mir. Die CPM Tools zum erstellen
eigener *.dsk "Disketten" habe ich mir auch schon geholt. Ein wenig
Software legt er mir auch noch bei. Und, ein wenig Software findet man
ja noch im Netz :)
Marcel A. schrieb:> Na denn. Auch ich habe hier noch einige Sticks (Platine) und jede Menge> 4-bit RAM und was man sonst so braucht vorrätig...> Schau mal auf meine HP...
Eine mit dem VGA Anteil hätte ich noch gerne. Das aber ein anderes mal,
bei mir steht bald ein Umzug an...
Hallo Ihr,
evtl. kann mir jemand bei der Lösung eines Problems helfen.
Ich habe ja den CPM Stick gekauft und eine CD mit Tools usw. bekommen.
Auf der CD sind auch ein paar Disk/HD Images. Ich kann den Stick sauber
booten und auf das Laufwerk B zugreifen. Laufwerk B ist ein
Festplattenimage mit 8MB größe.
Allerdings sehe ich nur den Inhalt der ersten 256kb... Mit B: komme ich
sauber auf die Festplatte, "stat" zeigt mir ein Freiraum von ca. 7.7MB
an. Auf der HDD sind aber mehr Programme...
Ich habe einige Programme aus der Batch Datei, die mir die DiskImages
erstellt, auskommentiert. In ADA usw. programmiere ich nicht...
Ich habe die Batch Dateien, womit ich mir meine Images erzeugt habe,
einmal angehangen.
Ich sehe weder mit der originales Batch Datei, noch mit meinen
Änderungen alle Dateien auf der HDD. Muss ich evtl. einen bestimmten
Bereich ansprechen? Ein B: scheint ja nicht zu reichen....
Ich komme nicht aus der CPM Zeit. Ich bin erst Ende der 80er Jahre, mit
DOS und dem Robotron BIC5105, bzw. BIC 5110 in die PC Welt
eingestiegen...
Hi.
Die einzelnen Applikationen sind in sog. Userbereiche kopiert - siehe
Batch Datei.
Umschalten mit z.B. user 1
(2, 3,...)
Das war eine Vorstufe der Unterverzeichnisse.
So hat man alles sauber getrennt und nicht Ada mit C oder Pascal
vermischt.
Peter
CP/M hat ebend keine Unterverzeichnisse.
Und auch keine Userkonten ala Unix etc.
ABER: Sog. User Bereiche. Das ist nichts weiter als das die Dateien
einem Userbereich zugeordnet werden und in der Anzeige NUR die Dateien
angezeigt werden, die zum aktuellen Userbereich gehören. Physikalisch
liegt alles im Rootverzeichnis.
Umschaltung mit user n.
Lies dir doch bitte mal ein CP/M Handbuch durch.
Googlen geht aber auch:
http://www.primrosebank.net/computers/cpm/cpm_cookbook_user.htm
Peter
Kannst Du, oder jemand anderes, mir ein passendes Buch empfehlen? Ich
habe, im 64er Forum - oder besser gesagt - deren Datengrab, ein wenig
Einsteigerliteratur gefunden. Aber, keines hiervon sprach das "user x"
Thema an..."
Vielen Dank :)
Eine Frage zum Schluss noch: Wie kann ich mbasic/ Basic 80 beenden und
zurück zu CPM kommen? ein ^c, ^x oder ^q brachte kein Erfolg. Ich muss
SIMH, bzw. den Stick resetten, um wieder zum BDOS zurück zu kommen...
Hatte M$ damals keine Exit- Routine eingebaut...? "quit", "bye" oder
"exit" bringt auch kein Erfolg.
Btw: das ist echt ein nettes kleines Spielzeug :)
I have the cpm stick 3.1 board with the atmega 328, 2x TC514256AP-70
drams but nothing showing on the serial port, nor is the sd card being
read.
question, does the atmega show anything through the serial terminal
before reading the sd card, so i can rule out the atmega is programmed
correctly with the correct fuse settings.
any help would be appreciated.
Horst S. schrieb:> hat schon mal einer darüber nachgedacht das ganze auf einen> STM32F103P6T8 zu bringen? wäre doch auch eine nette sache.
Der Z80-Emulator ist in feinstem AVR-Assembler geschrieben, das portiert
man nicht mal so eben.
Welche Vorteile versprichst Du Dir von STM32-Variante?
Man könnte halt auf das DRAM verzichten und hätte ggf. mehr Speed.
Beim STM32F103C8T6 bräuchte man aber wieder externes RAM, der hat intern
nur 20K. Sinnvoller wäre etwas mit 64K oder mehr. Oder noch besser 128K
RAM, da könnte man auch die Videoausgabe mit reinmachen. Also z.B. ein
STM32F405RG. Wobei sich dann trotzdem die Frage stellt, ob sich der
Aufwand lohnt. Denn es gibt ja schon die AVR-Variante, die recht gut
funktioniert. Und ich denke auch, dass das Interesse an solchen
Projekten eher nachlässt. Leider...
Jörg
Für ARMe gibt's schon fertige Z80-Emulationen. Die sind meist in C
geschrieben, weil dank der deutlich höheren Taktgeschwindigkeit die
Emulation nicht extrem performen muss. Als Ausgleich ist die Emulation
akkurater (d.h. das Zeitverhalten entspricht dem Original).
Habe mir einen AVR-CP/M Stick V3.1 zusammengebaut.
Tolles Projekt - schon erstaunlich, was in dem kleinen Ding mit grossem
Assembler-Quellcode-Herz steckt.
Wenn ich den Microsoft FORTRAN 3.44 Compiler ausprobiere, bekomme ich
einen Fehlerabbruch.
Der gleiche Compiler funktioniert auf dem Z80-CP/M Subsystem in meinem
HP-86, an der Software liegt es also nicht.
1
C>user 7
2
3
C>type hello.for
4
PROGRAM MAIN
5
print *, 'Hello World!'
6
END
7
8
C>f80 HELLO=HELLO
9
FORTRAN-80 Ver. 3.4 Copyright 1978, 79, 80 (C) By Microsofô
10
BYTES: 31663
11
Š1 PROGRAM MAIN
12
2 print *, 'Hello World!'
13
*****‰0000' LD BC¬$$L
14
*****‰0003' JP‰$INIT
15
?Line: 2 Statement Unrecognizable or Misspelleä:PRIN
16
3 END
17
*****‰0006' CALL‰$EX
18
19
Program Unit Length½0009 (9)
20
Bytes
21
Data Area Length½0001 (1) Bytes
22
23
Subroutines Referenced:
24
Š$INIT $EX
25
26
Variables:
27
Š
28
Labels:
29
Š$$L 0006'
30
Š1 Fatal Error(s) Detected
Merkwürdig sind die ersten und letzten Buchstaben der Fehlermeldungen.
Diese Zeichen haben jeweils bit 7 gesetzt.
Š = 0x8A = 1000.1010, bit 7 gelöscht: 0000.1010 = 0x10 = '\n'
½ = 0xBD = 1011.1101, bit 7 gelöscht: 0011.1101 = 0x3D = '='
ä = 0xE4 = 1110.0100, bit 7 gelöscht: 0110.0100 = 0x64 = 'd'
Auch wird PRINT nur verkürzt ausgegeben.
Hat jemand diesen FORTRAN Compiler auf dem AVR-CP/M laufen?
Kann es sein, dass hier noch Z80 opcodes fehlen?
Alle anderen Programme, incl. C Compiler etc. scheinen gut zu laufen,
nur der F80 nicht.
Hat jemand ein kleines Fortran Beispielprogramm mit PRINT oder WRITE,
das läuft?
Martin
> Habe mir einen AVR-CP/M Stick V3.1 zusammengebaut.
Welche Firmware-Version hast Du auf dem Stick?
> Kann es sein, dass hier noch Z80 opcodes fehlen?
Sicher nicht. Zumal der F80 ziemlich sicher ein reines 8080 Progamm ist.
Ich dachte zuerst an ein Timing-Problem mit der seriellen Schnittstelle.
Da aber nicht nur die Ausgabe vermurkst ist, sondern auch Fehler beim
compilieren sind, wird es wohl was anderen sein.
Ich schau mal rein.
... warte nochmal, bevor Du suchst ... der Compilerfehler ist
wahrscheinlich eher ein Problem meinerseits mit dem Uralt-Fortran. Ich
teste heute abend nochmal weiter.
Unabhängig davon: die gesetzten 7.bit im den Fehlermeldungen könnten
vielleicht verwendet worden sein um die Zeichenattribute für ein
Terminal zu steuern? Eventuell ist der Compiler für den TRS-80 und der
versteht so etwas z.B. für inverse Ausgabe oder ähnliches? Andere
Terminals maskieren dieses 8. Bit dann einfach weg. Ich habe
Windows/Teraterm mit 8 Datenbits + 1 Stop bit verwendet.
Martin
Martin schrieb:> ... warte nochmal, bevor Du suchst ... der Compilerfehler ist> wahrscheinlich eher ein Problem meinerseits mit dem Uralt-Fortran. Ich
Zu spät. ;)
> Wenn ich den Microsoft FORTRAN 3.44 Compiler ausprobiere, bekomme ich> einen Fehlerabbruch.
Das ist wahrscheinlich der neueste FORTRAN Compiler den es von Microsoft
für CP/M gibt. Den gleichen habe ich inzwischen auch ausprobiert.
> Der gleiche Compiler funktioniert auf dem Z80-CP/M Subsystem in meinem> HP-86, an der Software liegt es also nicht.
Das der Dein hello.for übersetzt hat, glaube ich jetzt nicht. MS FORTRAN
3.4 ist im wesentlichen ein FORTRAN-66 Compiler und hat definitiv keinen
PRINT-Befehl.
> Unabhängig davon: die gesetzten 7.bit im den Fehlermeldungen könnten> vielleicht verwendet worden sein um die Zeichenattribute für ein> Terminal zu steuern?
Bei mir kommen diese Bits nicht. Das scheint mir eher ein
Hardware-Problem oder ein Problem mit Deinr AVRCPM Firmware-Version
(welche?) zu sein.
> Ich habe> Windows/Teraterm mit 8 Datenbits + 1 Stop bit verwendet.
Das sollte passen.
1
CPM on an AVR, v3.5 r242
2
Testing RAM: fill...wait...reread...
3
Initing mmc...
4
5
A: CP/M partition at: 001, size: 7811KB.
6
B: FAT16 File-Image 'A' at: 3766, size: 8192KB.
7
C: FAT16 File-Image 'B' at: 859, size: 8192KB.
8
D: FAT16 File-Image 'C' at: 003, size: 8192KB.
9
E: FAT16 File-Image 'E' at: 375, size: 2048KB.
10
F: FAT16 File-Image 'F' at: 504, size: 1024KB.
11
G: FAT16 File-Image 'H' at: 586, size: 256KB.
12
H: FAT16 File-Image 'I' at: 603, size: 256KB.
13
Partinit done.
14
Ok, Z80-CPU is live!
15
16
62k cp/m vers 2.2
17
18
A>b:
19
B>f80 =hello
20
MAIN
21
22
?Line: 2 Statement Unrecognizable or Misspelled:PRIN
23
24
?1 Fatal Error(s) Detected
25
26
B>type hello2.for
27
PROGRAM MAIN
28
WRITE(1,200)
29
200 FORMAT(1X,'Hello World!')
30
END
31
32
B>f80 =hello2
33
MAIN
34
35
B>l80 hello2,hello2/n/e
36
37
Link-80 3.44 09-Dec-81 Copyright (c) 1981 Microsoft
Danke für die Mühe.
Ich hatte ein Disk Image CPMDSK_D.IMG verwendet. Dort lag unter USER 7
ein Programm HELLO.FOR. Damit bekam ich gleich die Fehlermeldungen und
die "merkwürdigen" Zeichen und glaubte dass da etwas größeres nicht
stimmt.
Wie Du schreibst, ist das Programm aber nicht für FORTRAN IV (oder 66?)
geeignet. Ich hatte dann gestern abend noch ein eigenes Testprogramm
geschrieben und das funktioniert. Entschuldigung für die Verwirrung.
Wenn ich allerdings einen Syntaxfehler in das Programm einbaue, kommen
wieder diese Zeichen mit gesetztem 7.Bit. Das müsste bei Dir auch der
Fall sein?
Vielleicht verwenden bestimmte Terminals das 7.Bit um invers oder fett
darzustellen (es gab auch eine Version dieses Fortrans für den TRS/80,
vielelicht versteht der das). Das ist aber kein wirkliches Problem.
Mein (jetzt erfolgreicher) Test:
1
CP/M on AVR, v3.2 r155
2
Testing RAM: fill...wait...verify...
3
Reading SD card...
4
5
A: FAT16 Image 'A' at: 002, size: 256 KB.
6
B: FAT16 Image 'B' at: 266, size: 256 KB.
7
C: FAT16 Image 'D' at: 274, size: 8192 KB.
8
D: FAT16 Image 'E' at: 010, size: 8192 KB.
9
Partinit done.
10
Ramdisk found.
11
Ok, Z80-CPU is alive!
12
13
ipl <<<<<<<<<<<<<< Was bedeutet das? Aus welcher .asm Quelle kommt das?
14
62k cp/m vers 2.2
15
16
A>C:
17
C>USER 7
18
19
C>TYPE HELLO.FOR
20
PROGRAM HELLO
21
INTEGER I, IUNIT
22
REAL X,Y
23
IUNIT=6
24
WRITE(5,100)
25
C 0 = current drive
26
C 3 = drive C:
27
CALL OPEN(IUNIT,11HHELLO TXT,3)
28
DO 50 I=1,100
29
X=FLOAT(I)/10.0
30
Y=SIN(X)
31
WRITE(IUNIT,200) X,Y
32
50 CONTINUE
33
34
100 FORMAT(15H Hello FORTRAN!)
35
200 FORMAT(1H ,F12.3,3H = ,F12.3)
36
END
37
38
39
C>F80 HELLO=HELLO
40
HELLO
41
42
C>L80 HELLO/N,HELLO/E
43
44
Link-80 3.44 09-Dec-81 Copyright (c) 1981 Microsoft
45
46
Data 0103 1E69 < 7526>
47
48
37999 Bytes Free
49
[0139 1E69 30]
50
51
C>HELLO
Schreibt "Hello FORTRAN" auf die LST device (Terminal)
Erstellt Datei 'HELLO.TXT' mit X,Y Werten.
> Ich hatte ein Disk Image CPMDSK_D.IMG verwendet. Dort lag unter USER 7> ein Programm HELLO.FOR.
Und F80.COM befindet sich ebenfalls auf diesem Image?
Wo finde ich das Image? Oder kannst Du es mir zukommen lassen?
> Wenn ich allerdings einen Syntaxfehler in das Programm einbaue, kommen> wieder diese Zeichen mit gesetztem 7.Bit. Das müsste bei Dir auch der> Fall sein?
Nein, die Zeichen kommen bei mir nicht.
> Vielleicht verwenden bestimmte Terminals das 7.Bit um invers oder fett> darzustellen (es gab auch eine Version dieses Fortrans für den TRS/80,> vielelicht versteht der das).
Das mag durchaus sein, aber mMn müßten die Bits dann anders verteilt
sein. Für mich sieht das eher nach Übertragungsfehler aus.
> Das ist aber kein wirkliches Problem.
Für mich schon, solange die Ursache nicht klar ist.
Deshalb hätte ich gerne das Disk Image.
> Mein (jetzt erfolgreicher) Test:CP/M on AVR, v3.2 r155
Zwar nicht uralt, aber auch nicht die neueste Version. Du könntest auf
v3.5 updaten.
> Ok, Z80-CPU is alive!>> ipl <<<<<<<<<<<<<< Was bedeutet das? Aus welcher .asm Quelle kommt das?> 62k cp/m vers 2.2
Das ist der "Initial Prgram Loader".
Der Bootloader im ersten Sektor der Disk, der das CP/M (CCP+BDOS+BIOS)
aus den reservierten Systemspuren ins RAM läd.
Sourcecode ist in cpm/IPL.MAC.
Hallo,
ich werde mal versuchen mir eine aktuellere Firmware zu assemblieren.
>Zwar nicht uralt, aber auch nicht die neueste Version. Du könntest auf v3.5
updaten.
Woher nehmen und nicht stehlen? Ich habe bislang nur ein 3.2 für die
standalone Version unter
https://www.mikrocontroller.net/svnbrowser/avr-cp-m/avrcpm/trunk/avr
gefunden. Ich habe die V3.1 Stick-Platine mit TTL-Serial ind 8-bit DRAM,
d.h. kein Propeller, VT100 etc. Wollte nur noch (wenn der Chinese
liefert) auf I2C-Seriell aufrüsten.
Danke für die Erläuterung des "ipl" - ich dachte das es Optionen
(I2C,...) kennzeichnet und konnte es in den Quellen nicht finden.
Die disk-image Dateien habe ich von
https://www.mikrocontroller.net/articles/AVR_CP/M dort unter "Downloads"
die datei CPMDSK_C.IMG geladen. Dort war unter "USER 7" der FORTRAN
Compiler mit L80 und dem "Beispiel" zu finden.
Den MS-F80 v3.44 Compiler hatte ich auch schon früher mal für andere
CP/M Rechner gefunden, vermutlich geistern die selben Dateien an vielen
Stellen herum. Z.B. auf http://www.retroarchive.org/
Da es auch eine TRS-80 Version des Compilers (zumindest der Handbücher)
gab, habe ich noch nach TRS-80 Infos gesucht.
Dazu habe ich noch dies gefunden:
1
The Model 4 uses the same character set as the Model 3 as long as the reverse video is turned off. If you wish to use reverse video, first send CHR$ code 16 to the display, then switch in the video memory. You can only access inverse video and POKE the data if you SET bit 7 of the data going to the display. Example: Send ASCII code to display with this assembler program:
2
3
LD A,41H
4
LD HL,F800H
5
LD (HL),A
6
7
The above puts the normal video “A” on the screen. If you want reverse video, use this:
8
9
LD A,41H ; A
10
SET 7,A
11
LD HL,F800H
12
LD (HL),A
13
14
You can also calculate the reverse video strings by adding 128 to each value to send to the screen.
15
***** N O T E *****
16
If you enable the reverse video, you *CANNOT* use the graphics characters. To disable the reverse video and enable the graphics, send a CHR$ code 17 to the screen.
Meine Spekulation ist, dass diese TRS-80 Spezialität verwendet wird um
Fehlermeldungen (nur diese) hervorzuheben. Um das zu prüfen, müsste man
aber den F80 disassemblieren, soweit wollte ich nun nicht gleich gehen.
Wenn aber diese Zeichen bei Dir (im Fehlerfall) nicht auftauchen, muss
es wohl etwas anderes in meiner Konfiguration sein. Merkwürdig wäre
dann aber das alle (?) anderen Programme (Turbo Pascal, Multiplan,
Wordstar, ED) mit ihren durchaus komplexen Ausgaben einwandfrei zu
funktioniern scheinen.
Martin
O.K. ich habe nun doch noch die aktuellen (hoffe ich) Quellen gefunden
und habe nun die Version 3.5 laufen.
Auch damit kommen bei Fehlermeldungen (nur dort) ebenfalls jeweils die
letzten Zeichen mit gesetztem Bit 7.
Daraufhin habe ich mir die Fehlermeldungen im F80.COM angesehen. Sie
haben immer auf dem letzten Buchstaben bit 7 als Ende-Kenner gesetzt.
Damit spart man ein (Null-)Byte pro String, setzt aber voraus, dass die
Ausgabeeinheit immer nur 7 bit ausgibt.
Im BIOS gibt es dazu die 5 Funktionen CONIN, CONOUT, LIST, READER und
PUNCH.
Im "CP/M 2.2 Alteration Guide" steht (S. 17/18, 1979-er Digital Research
Ausgabe), das für diese das high order (parity) bit == 0 sein soll,
auch bei der Eingabe. Das bedeutet dann aber auch, dass man generall in
CP/M keine 8-bit Binärdaten einlesen oder ausgeben kann.
Es ist mir nicht 100% klar ob diese Funktionen 7 bit erwarten oder ggf.
das 7.bit selbst löschen.
Nur die Funktionen CONIN und READER löschen bit 7 explizit im Beispiel
BIOS (S. 53)
In dem CP/M Assemblercode des HP Systems, das ich vor einiger Zeit mal
disasembliert hatte, findet ebenfalls eine explizite Maskierung auf die
unteren 7-bits beim TTY input statt.
Die CP/M Version von AVR-CPM macht anscheinend diese Filterung nicht,
sondern gibt die volle 8-bit Breitseite auf die Konsole.
Der Emulator "Z80Emu" gibt auch nur die 7-bit Texte aus.
So wie es jetzt ist, kann man dann aber auch höhere > 128 Zeichencodes
ausgeben, was ja auch ganz nett ist.
Ich bin nicht sicher ob CP/M grundsätzlich als 7-bit System für jede
Console - I/O zu verstehen ist.
Meine Spekulation zu TRS-80/Steuerzeichen war nicht richtig.
F80.COM:
Nach Ergänzung um einen MAX 2323 um ein Terminal anzuschließen, habe ich
mir nun noch ein SC16IS740 I2C-UART breakout-board besorgt.
Dazu würde mich interessieren, ob schon jemand das CP/M BIOS dafür
angepasst hat. Ich sehe die I2C Port Routinen auf der AVR Seite, aber
kein Gegenstück auf der CP/M Systemseite. Dort sind nur die originalen
leeren Funktionen mit "ret" für PUNCH bzw. "ret ^Z" für READER
implementiert.
Ich überlege, READER und PUNCH über den I2C-Serial-Wandler zu schicken.
Im BIOS würde dann das IOBYTE ausgewertet und ggf. input und output über
den I2C Bus geleitet.
Damit könnte man viele Programme direkt über CP/M auf diese zusätzliche
Schnittstelle lenken. Zum Beispiel als Drucker oder eben für Kermit etc.
Martin
Danke für die schnelle Antwort - gelesen hab ich's schon, die BIOS
Quellen hier auf diesem Server
(https://www.mikrocontroller.net/svnbrowser/avr-cp-m/avrcpm/trunk/cpm/)
scheinen aber aber noch die alten zu sein (BIOS.MAC und BIOS.ASM jeweils
mit den leeren returns)?
Oder habe ich da mal wieder was übersehen?
Ich möchte die I2C/UART nicht in jedem Programm direkt ansteuern,
sondern die dafür vorgesehenen Systemgeräte (RDR:, PUN:) nutzen.
Dann könnte ich z.B.
Joe G. schrieb:> Martin schrieb:>> Dazu würde mich interessieren, ob schon jemand das CP/M BIOS dafür>> angepasst hat.>> Ist schon implementiertb und getestet. Schau mal hier:
Im BIOS ist der UART leider noch nicht integriert.
Weil ich kein Z80 Assembler-Profi bin, habe ich mal in pseudo-code
aufgeschrieben, was im BIOS geändert/zugefügt werden müsste. Im Prinzip
dürfte es reichen, die "reader" und "punch" Routinen mit Leben zuu
füllen.
Mit den vorhandenen virtuellen Ports für I2C müsste das Ganze eigentlich
recht einfach gehen, wenn man erst mal ohne Fehlerabfragen, Timeouts
etc. arbeitet.
Da kein größerer Puffer verwendet wird, sondern byte-weise
ein-/ausgegeben wird, ist natürlich die Frage für welche Baud-Raten das
noch geht. Aber 2400 oder 4800 Baud wären auch schon o.k. z.B. für einen
Drucker.
Könnte das funktionieren?
Martin
in BIOS.ASM und/oder BIOS.MAC (welches wird denn eigentlich verwendet?)
Es geht einfacher. Um I2C brauchst Du Dich garnicht zu kümmern. In
diesem Artikel, auf den Joe schon verwiesen hatte, ist unten ein
Beispiel:
Beitrag "Re: CP/M auf ATmega88"
Was dann noch fehlt, ist die Input Status-Routine und die I/O-Byte
Geschichte.
ah Danke, den Kermit hatte ich zwar ge-sehen, die Assembler Routinen
aber über-sehen. Das sieht ja deutlich einfacher und schneller aus als
einen 1-byte buffer zu schicken.
Muss mal ausprobieren, ob ich ein neues BIOS bauen und dann auch auf die
SD Karte schreiben kann.
Das IOBYTE kann ich ja mit dem STAT Befehl schon ändern und mit STAT
DEV: die aktuelle Zuordnung ansehen - da muss ich nochmal im "Alteration
Guide" nachlesen, ob und wo was maskiert und getestet werden muss.
Es gibt da ja auch noch "User Defined" reader und printer devices die
man anschliessen kann. Aber ich denke RDR: und PUN: oder LST: und PUN:
wären schon ausreichend (solange man keinen zweiten I2C UART anhängen
möchte...).
Erst mal Danke für die Tips und Hinweise!
Um mich erst mal mit dem I2C UART anzufreunden und meine Verschaltung zu
überprüfen, habe ich zwei kleine Turbo-Pascal 3 Programme geschrieben,
die vielleicht auch für andere nützlich sein könnten:
MODE - erlaubt es UART Parameter (Baud-Rate, Bit-Anzahl, Parity,
Stop-Bit-Anzahl) einzustellen, ähnlich wie das MODE Programm unter DOS.
Ein Aufruf ohne Argumente zeigt die aktuellen Einstellungen an.
PRINT - erlaubt es eine Textdatei über den UART zu "drucken". z.B an
einen realen Drucker oder via Null-Modem an ein weiteres Terminal/PC zu
schicken. Vorher muss man einmal mit MODE die UART Parameter einstellen,
sie bleiben dann erhalten.
Martin
Hallo Martin,
ich freue mich, daß sich jemand mit den Sachen beschäftigt und finde
ziemlich gut, was Du da machst. Hast Du schon Erfahrungen mit der
Performance? Und wolltest Du das nicht in FORTRAN programmieren? ;-)
Bezüglich Performance habe ich nicht allzu viel probiert, da ich
meistens so mit 9600...19200 Baud arbeite und das geht sehr gut.
Ich "drucke" z.B. die Turbo Pascal Programme auf einen Laptop (mit
Nullmodem Kabel und Windows Teraterm) bei 19200 Baud und das geht
fehlerfrei. Einstellen lassen sich noch wesentlich höhere Datenraten.
Ich habe spaßeshalber auch einen modernen Thermodrucker
(POS/Kassendrucker) mit 19200 Baud angeschlossen und der druckt so
schnell dass es keine Verluste gibt.
Auf Handshaking habe ich deshalb bislang verzichtet, da der Laptop die
Daten schnell genug aufnimmt.
Ich vermute aber, dass man z.B. mit einem alten Nadeldrucker die
Baudrate auf 2400...4800 heruntersetzen oder besser Handshaking
einschalten muss.
Ich schwanke noch, ob ich die GPIO Leitungen lieber als allgemeine I/O
oder als Modem Leitungen fürs Handshaking verwenden soll.
Bei Verwendung als I/O könnte man Schalter oder digitale Joysticks
abfragen z.B. für Steuerungszwecke und Spiele. Ansonsten könnte man am
I2C Bus ja noch weitere I/O Bausteine anhängen, wenn gewünscht.
Das MODE Programm habe ich inzwischen so ergänzt, dass es auch der
Status der GPIO Pins (im Augenblick alle als input definiert) anzeigt.
Werde mal sehen, ob/wie ich das hier in das SVN ablegen kann.
Dann kommt die FORTRAN Version - oder doch lieber in ALGOL?.
Martin
Marcel schrieb:> Bitte dokumentier das mal irgendwo, so dass...
Guter Vorschlag!
@Martin
Einfach unformatiert in eine Textdatei tippen, ich übernehme es dann für
die Doku.
Martin Hepperle schrieb:> ob ich die GPIO Leitungen lieber als allgemeine I/O
Besser nicht. Tu Dir das nicht an.
> Ansonsten könnte man am> I2C Bus ja noch weitere I/O Bausteine anhängen, wenn gewünscht.
Eben. Lieber die 20¢ für einen PCF8574 investieren. Dafür gibts bereits
einen Treibern im Emulator. Es können 8 Stück davon (+ bei Bedarf
nochmal 8 PCF8574A) über einfache I/O-Befehle angesprochen werden.
...so, habe die letzten Abende mit I2C verbracht zunächst etwas
frustrierend, aber gestern abend hat's geklappt ;-)
Ich hatte ein kleines Platinchen mit dem MCP23017 zur Hand (keinen
PCF8574) und den wollte ich gerne anschließen.
Es hat aber 2 Abende gedauert, bis ich die vorhandenen I2C/Port
Anbindung verstanden habe - der AVR Assembler ist mir halt noch recht
fremd.
Zusätzlich war mir der Zusammenbau der Registerauswahl für den SC16IS740
unverständlich (mit swap, rshift), bis ich dann nochmal ins Datenblatt
geschaut habe und dort die merkwürdige Platzierung der Registeradresse
gefunden habe. Darüber hinaus hat mich auch die Mischung von 7-bit und
sogenannten 8-bit I2C Adressen verwirrt...
Jedenfalls habe ich jetzt den MCP23017 am laufen und kann damit sehr
flexibel bis 16 bit I/O ansteuern. Zum Beispiel für einen Centronics
Schnittstelle.
Für seine Register habe ich 22 Portadressen ab 0x90 verwendet.
Alles mit entsprechenden #defines etc. sodass man den Teil auf Wunsch
aktivieren kann.
Es ist noch die Frage, was standardmäßig aktiviert sein soll - im
Augenblick wird ja z.B. der SC16IS740 UART automatisch mit aktiviert,
wenn I2C Support aktiv ist. Besser wäre vielleicht neben generell I2C
Unterstützung eine Liste aller I2C Devices, sodass man über die
config.inc explizit definieren kann, welche man wirklich haben möchte.
Wenn immer alle eingebunden wären, geht irgendwann der Z80
Port-Adressraum aus.
Ich werde die MCP23017 Integration über's Wochenende nochmal etwas
weiter dokumentieren und könnte dann die modifizierten Quellen wieder
zur Integration zurückgeben. Es sind nur config.inc, i2c.asm und
virt_ports.asm betroffen und ein kleines Turbo-Pascal Testprogramm gibt
es noch dazu.
Martin
Hallo zusammen,
in dem beigefügten Archiv sind meine ASM Quellen mit MCP23017
Unterstützung.
Im "I2C-liesmich.txt" sind meine Erläuterungen dazu.
Ich kann auch ein .IMG beisteuern, auf dem dann die Pascal Dateien
enthalten sind.
Im Prinzip könnten die 3 modifizierten AVR Dateien direkt in das SVN
übernommen werden - meine Kommentarzeilen mit "-MH-" können entfernt
werden - ich erhebe kein Copyright auf irgendwas.
Zum Z80 BIOS habe ich etwas weitergelesen und sehe, dass wohl alles zum
Neubau auf dem von Leo C. verteilten disk image vorhanden ist.
Ich muss nur noch verstehen, welche Adressen/Größen ich anpassen muss,
weil das BIOS natürlich etwas größer wird wenn dort die serielle (RDR,
PUN) und die parallel Schnittstelle (LST) über I2C hinzukommen.
Martin
Hallo Martin,
Super.
Martin schrieb:> Im Prinzip könnten die 3 modifizierten AVR Dateien direkt in das SVN> übernommen werden -
Das Beste wäre, wenn Du die Erweiterungen und Verbesserungen selbst
einchecken würdest. Du brauchst dazu nur einen mikrocontroller.net
Account, den Du vielleicht ja schon hast.
> meine Kommentarzeilen mit "-MH-" können entfernt werden -
Diese Art von Markierungen sieht man häufig in alten Programmen. Aber
dafür hat man heute ja Versionsverwaltungen wie SVN.
> ich erhebe kein Copyright auf irgendwas.
Du könntest jeweils im Kopf eine Zeile mit Jahr und Autor einfügen.
> Ich kann auch ein .IMG beisteuern, auf dem dann die Pascal Dateien> enthalten sind.
Gerne.
Du kannst sie aber auch im SVN im Zweig cpm/utils unterbringen.
Leo,
ich wollte nicht so gerne in anderer Leute Code herumwursteln...kann das
aber gerne machen.
Dazu habe mir gerade einen microcontroller.net Account angelegt und auch
das extra SVN Passwort gefunden.
Mit Tortoise SVN ist es mir aber nicht gelungen, Verbindung mit dem
Repository aufzunehmen:
1
Command: Checkout from svn://mikrocontroller.net/avr-cp-m, revision HEAD, Fully recursive, Externals included
2
Error: Unable to connect to a repository at URL 'svn://mikrocontroller.net/avr-cp-m'
3
Error: Can't connect to host 'mikrocontroller.net': Es konnte keine Verbindung
4
Error: hergestellt werden, da der Zielcomputer die Verbindung verweigerte.
5
Completed!:
Brauche ich noch eine Freigabe meines Benutzernamens für das AVR-CPM
Repository?
Ich dachte, dass ich auch ohne Schreibzugriff browsen oder auschecken
könnte... Aber vielleicht brauche ich eine Freigabe per SVN auch zum
Lesen.
Martin
Martin H. schrieb:> Brauche ich noch eine Freigabe meines Benutzernamens für das AVR-CPM> Repository?
Ja, habe ich gerade eingerichtet und sollte nun gehen.
Joe,
Danke, aber irgendwie bin ich zu doof.
Mit dem Windows Tortoise SVN, mit dem ich sonst gelegentlich im internen
Firmen-Netzwerk arbeite, klappte es nicht. Nach außen ist da eine
Firewall, die vielleicht svn verbietet?
Also versuche ich mal als Alternative die Kommandozeile:
Ich versuche eine lokale Kopie auf meinem Rechner anzulegen:
1
svn checkout svn://mikrocontroller.net/avr-cp-m
2
svn: E170013: Unable to connect to a repository at URL 'svn://mikrocontroller.net/avr-cp-m'
3
svn: E730061: Can't connect to host 'mikrocontroller.net': Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte.
svn: E170013: Unable to connect to a repository at URL 'svn://mikrocontroller.net/avr-cp-m'
3
svn: E730061: Can't connect to host 'mikrocontroller.net': Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte.
Das gleiche bekomme ich auch mit anderen Befehlen wie "info" etc.
Hast Du noch eine Idee?
Martin
Die Quellen liegen hier: svn://mikrocontroller.net/avr-cp-m/avrcpm/trunk
Bei mir geht es, ich habe es gerade versucht. Versuche mal bitte über
diesen Link an das Archiv zu kommen:
https://www.mikrocontroller.net/svnbrowser/avr-cp-m/
Per WEB browser komme ich schon dahin und hatte mir das ganze ja auch
als TAR heruntergeladen um lokal zu arbeiten.
Das WEB Interface hat aber keine commit Funktion es ist nur ein viewer.
Mit "svn checkout" oder Turtoise-SVN klappt es nicht.
Ich habe nochmals etwas herumgeforscht, und tatsächlich verbietet unsere
Firmen-Firewall den port 3690 der für svn verwendet wird.
Wenn der mikrocontroller.net Server das WebDAV Protokoll unterstützen
würde, könnte ich darauf zugreifen, aber man kann nicht alles haben.
Martin
O.K. das mit dem SVN bekommen wir noch hin.
Nachdem ich den AVR-Teil soweit im Griff habe, möchte das CP/M System
mit Hilfe von AVRCPM.SUB nochmal zu bauen (und später erweitern).
Dazu habe ich versucht, das CP/M mit Hilfe der auf dem Disk-Image C:
vorhandenen Dateien und dem SUBMIT Skript AVRCPM.SUB neu zu bauen.
Das habe ich schließlich nach etwas Kampf mit SUBMIT und A: versus C:
hinbekommen und erhalte nun auch ein kombiniertes CPM.BIN.
(Kampf: wenn ich z.B. SUBMIT von Laufwerk C: ausführe bekomme ich eine
Fehlermeldung über ein fehlendes Laufwerk G: und ähnliche Effekte)
Am Ende von AVRCPM.SUB steht noch ein Aufruf eines ominösen Programms
"W". Das fehlt aber in der Distribution.
Ich vermute, dass es die CPM.BIN Datei roh auf den Datenträger schreiben
soll. Bevor ich nun lange herumsuche meine Frage:
Wie bekomme ich das CPM.BIN am einfachsten auf die Diskette A:?
(Also auf dem AVR-CP/M System, nicht über so modernen externen
Schnickschnack wie Windows oder Linux)
Danke,
Martin
Martin H. schrieb:> Am Ende von AVRCPM.SUB steht noch ein Aufruf eines ominösen Programms> "W". Das fehlt aber in der Distribution.
W.COM gehört zum simh und dient dort dazu, Dateien aus dem CP/M System
in das Host-Dateisystem zu schreiben. Auf einem richtigen CP/M-System
ist es also überflüssig.
> Ich vermute, dass es die CPM.BIN Datei roh auf den Datenträger schreiben> soll. Bevor ich nun lange herumsuche meine Frage:> Wie bekomme ich das CPM.BIN am einfachsten auf die Diskette A:?
Dafür waren MOVCPM und SYSGEN gedacht. Siehe "CP/M 2.2 Alterarion
Guide".
Jens hatte das ganze schon mal durchgezogen. Diskussion ungefähr ab [1]
und ab [2] gibts von ihm ein Programm, um CP/M aus die Systemspuren zu
kopieren.
[1] Beitrag "Re: CP/M auf ATmega88"
[2] Beitrag "Re: CP/M auf ATmega88"
... wieder ein Schrittchen weiter ...
Nachdem die Pascal Progrämmchen ja ganz nett aber eben hardware-abhängig
waren, wollte ich die Schnittstellen ja noch ins CP/M integrieren.
Die IOBYTE Funktionalität bin ich noch nicht angegangen, da ich mit der
aktuellen Konfiguration schon recht zufrieden bin.
Es sind nun die logischen Geräte LPT:, RDR: und PUN: verfügbar.
Man braucht dazu zwei I2C Sklaven:
I2C Adresse 0x48: SC16IS740 - UART (9600,N,8,1 default)
I2C Adresse 0x20: MCP23017 - 16-bit GPIO (Port A[0:7]: Daten, Port
B[0:3]: BUSY,ACK/,PAPER,STROBE/)
Die beiden I2C chips habe ich auf breakout boards mit in mein AVR-Stick
Gehäuse eingebaut und für die serielle Schnittstelle einen zweiten DB9
Stecker installiert.
Die Parallelschnittstelle ist mit VCC, GND auf einen 20-poligen
Bandkabelstecker geführt. Sie arbeitet allerdings mit 3,3V
Ein-Ausgabepegel, sodass je nach Einsatz Pegelwandler für klassische
Centronics-Drucker nötig wären.
"CON:" ist weiterhin die AVR-UART serielle
Ausgabe-/Eingabe-Schnittstelle
"RDR:" und "PUN:" sind auf die I2C UART serielle
Ausgabe-/Eingabe-Schnittstelle gelegt.
"LST:" ist auf die I2C GPIO parallele Ausgabe-Schnittstelle gelegt.
Ich kann nun den AVR-CP/M z.B. mit
1
PIP LST:=CON:
als Schreibmaschine benutzen (Ausgabe mit CTRL-Z beenden). Oder eine
Textdatei schnell mal mit
1
PIP PUN:=FILE.TXT
auf einen angeschlossenen Laptop oder seriellen Drucker ausgeben. Oder
mit
1
PIP FILE.TXT=RDR:
eine (mit CTRL-Z abgeschlossene) Textdatei einlesen.
Mit Turbo Pascal kann man nach einem Assign() auf 'Lst' (GPIO/parallel)
oder 'Aux' (I2C seriell) ausgeben.
Falls das jemand ausprobieren möchte:
- auf dem beigefügen Disketten-Image CPMDSK_A.IMG ist das modifizierte
BIOS. Beim Booten sollte sich CP/M mit Version "2.2x" melden.
- dazu gehört die entsprechende AVR Firmware, die die neuen virtuellen
Ports für die beiden I2C Geräte enthält.
Wenn das ganze noch etwas verfeinert ist, wird der Code wieder in die
Quellen zurückfließen.
Gestern Abend habe ich dann auch meine SD Karte vernichtet - zu viele
Schreib-Lesezyklen?
Martin
In einer der vielen AVR CP/M Versionen gab es auch die Variante mit I2C
und Echtzeituhr (PCF8583) und 8Bit-Schnittstelle (PCF8574). Somit konnte
u.a. ZSDOS zum Einsatz kommen. Um ein BIOS zu bauen hatte ich damals
auch eine kleine Konfiguration erstellt (ZSDOSCPM.SUB). Vielleicht nutzt
du gleich ZSDOS um deine Änderungen bezüglich I2C einzubauen. Für das
ZSDOS benötigst du (alles im Anhang):
IPL.MAC
CCP.MAC
ZSDOS.MAC(BDOS)
BIOS.MAC
AVRCPM.LIB
CFGACPM.LIB
Um es schnell zu testen, benutze ich immer den AltairZ80 Simulator. Der
„W“ Befehl schreibt die Datei vom CP/M System zurück auf den PC, kann
natürlich direkt auf CP/M entfallen.
Zu spät - ich habe schon das ZSDOS verwendet und auf Deiner AVRCPM.SUB
Datei aufgebaut. Darin steht dann auch:
1
; create BDOS.COM
2
$1:M80 =$1:ZSDOS/M
3
$1:L80 $1:ZSDOS,$1:ZSDOS/N/E
4
ERA $1:ZSDOS.REL
Ich habe nur die .SUB Datei auf A: kopiert und $1 Parameter eingebaut
damit die Quellen und Ergebnisse alle auf C: verbleiben können.
A: weil das SUBMIT nur über A: funktioniert (ich wollte nur mit Basis
CP/M Mittel arbeiten ohne DO, SUPERSUB etc.) .
Die 8-Bit-Schnittstelle (PCF8574) ist weiterhin enthalten, ich habe sie
nur auf I2C 0x27 gesetzt, weil das die Default Einstellung meiner Module
war (die gibt es z.B. auch als Interface für die 1602 LCD Anzeigen).
Die Z80 Ports dafür liegen weiterhin ab 0x80. Als Druckerschnittstelle
reichen die 8 Bit leider nicht aus, deshalb habe ich den 16-bit GPIO
verwendet.
Die RTC hatte ich im code nicht gesehen - ich glaube die war nur über
die low Level I2C ports ansprechbar, z.B. mit dem Pascal Programm im
SVN. Das ist natürlich auch weiterhin für alle möglichen I2C
Gerätschaften möglich.
Es ist also nichts verschwunden, nur zur vorhandenen Basis zugefügt
worden (solange noch virtuelle Ports frei sind, ist das wohl die
eleganteste Möglichkeit).
Martin H. schrieb:> Die 8-Bit-Schnittstelle (PCF8574) ist weiterhin enthalten, ich habe sie> nur auf I2C 0x27 gesetzt, weil das die Default Einstellung meiner Module> war (die gibt es z.B. auch als Interface für die 1602 LCD Anzeigen).
Das wollte ich schon länger mal schreiben. Hier liegt wohl ein
Missverständnis vor. Mit dem Treiber können insgesamt 8 ICs angesprochen
werden. 0x20 ist dann die Basisadresse, bzw. die Adresse des ersten
Chips. Ändert man die Adresse im Treiber auf 0x27, können die Chips auf
den Adressen 0x20-0x26 nicht mehr erreicht werden.
> Die Z80 Ports dafür liegen weiterhin ab 0x80.
Dein Modul liegt dann auf 0x87.
> Als Druckerschnittstelle> reichen die 8 Bit leider nicht aus, deshalb habe ich den 16-bit GPIO> verwendet.
Man könnte auch 2 PCF8574 verwenden, jedenfalls mit dem unveränderten
Treiber. Aber der MCP23017 hat natürlich weitere Vorteile. ZB. richtige
Push/Pull-Ausgänge. Und das er zusätzlich unterstützt wird, ist ja kein
Fehler.
> Die RTC hatte ich im code nicht gesehen - ich glaube die war nur über> die low Level I2C ports ansprechbar, z.B. mit dem Pascal Programm im> SVN. Das ist natürlich auch weiterhin für alle möglichen I2C> Gerätschaften möglich.
Für die RTC gibt es einen Treiber für ZSDOS (LDTIM)[1].
Den könnte man auch ins BIOS verlegen.
[1] Beitrag "Re: CP/M auf ATmega88"
Leo C. schrieb:> Das wollte ich schon länger mal schreiben. Hier liegt wohl ein> Missverständnis vor. Mit dem Treiber können insgesamt 8 ICs angesprochen> werden. 0x20 ist dann die Basisadresse, bzw. die Adresse des ersten> Chips. Ändert man die Adresse im Treiber auf 0x27, können die Chips auf> den Adressen 0x20-0x26 nicht mehr erreicht werden.
Ah ja - in der Tat ein Mistverständnis meinerseits. Das werde ich noch
überarbeiten. Ich wollte nur Überlappungen vermeiden. Es ist natürlich
die Frage, ob beide GPIOs (PCF8574 und MCP23017) unbedingt koexistieren
müssen oder ob man nicht (wenn überhaupt) nur einen GPIO einsetzt. Der
MCP23017 ist schön flexibel, frisst aber auch viele virtuelle
Portadressen. Aber solange noch genug verfügbar sind...
Joe G. schrieb:> Martin H. schrieb:>> Wie bekomme ich das CPM.BIN am einfachsten auf die Diskette A:?>> z.B. mit POWER.COM>> A0=load cpm.bin 4000 Last Address:59FFH 52 sectors> A0=write 0 1 4000 52> ...
Sehr gut - werde ich in Zukunft verwenden um mir den SD-Karten-Austausch
zu ersparen.
@Martin
Mit welchem Baudratenquartz arbeitest du beim SC16IS740? Ich würde es
gerne bei mir testen bevor ich den Code im SVN einchecke. Ein MCP23017
Modul muss ich mir erstmal besorgen.
Noch ein Vorschlag.
Da ja einige Hardwareboards mit Propeller, I2C (RTC und PCF8574) im
Umlauf sind, würde es mit deiner I2C Adresse 0x20 für den MCP23017 zu
Kollisionen kommen. Sie auf 0x27 zu legen ist auch nicht so günstig
(siehe Leo C.) da dann nur noch ein IC angesprochen werden kann. Um die
größtmögliche Kompatibilität zu erhalten, könntest du doch den MCP23017
auf 0x27 legen (siehe Tabelle). Dann sind zwar noch 7 statt 8 PCF8574 zu
verwenden, aber das kann verschmerzt werden denke ich.
P.S: In Deiner Kurzdoku „I2C liesmich.txt“ hast du die Zuordnung zu den
IC’s vertauscht.
Es sind nun diese drei I2C Geräte direkt implementiert:
- SC16IS740 UART at I2C address 0x20,
- MCP23017 16-bit GPIO at I2C address 0x48,
Danke für die Korrektur der I2C Adressen, habe ich in meinen Dokumenten
und im Schema.pdf geändert.
Dank POWER kann ich das CPM.BIN nun auch erfolgreich direkt vom System
auf die Karte schreiben.
Anbei nochmals eine aktualisierte Version meiner Dateien.
Die I2C Adresse für die PCF habe ich wieder auf die 0x20 zurückgesetzt,
die für den MCP erst mal ebenfalls auch 0x20 gelassen. Ich vermute, dass
nicht so viele Anwender beide Chips gleichzeitig verwenden möchten.
Die Baud-Raten Divisorberechnung habe ich versucht mit einem M80 Equate
zu berechnen, bin aber an den wahrscheinlich zu großen Zahlen
Divisor=(MHz/BaudRate/16) gescheitert. Deshalb ist der Divisor im
Quellcode BIOS.MAC als EQU hart verdrahtet, aber mit Formel kommentiert.
Steht so auch in MODE.PAS.
Mein SC16IS740 board hat einen 14.7456 MHz Quarz was dann z.B. für 9600
Baud einen Divisor von 96 ergibt.
Danke!
Ein Teil läuft schon mal...
ipl
64k cp/m vers 2.2x
B>scan
Scanning I2C bus for devices...
*** Device found at slave address 20h = 32d (8-bit: 40h = 64d)
*** Device found at slave address 27h = 39d (8-bit: 4Eh = 78d)
*** Device found at slave address 50h = 80d (8-bit: A0h = 160d)
Done.
Hier mußte ich meinen PCF8574 auf 0x27 legen, um keine Kollision zu
bekommen. 0x50 ist die RTC. Für die UART fehlt mir noch der
Baudratenquarz, erst mal in meiner Kiste suchen...
Nach dem Feedback habe ich nun in meinen System die folgende Zuordnung
realisiert:
- SC16IS740 UART at I2C address 0x48, mapped to Z80 ports 0x50-0x5F
(A0=VCC, A1=VCC), tested up to 115200 baud
- MCP23017 16-bit GPIO at I2C address 0x27, mapped to Z80 ports
0x60-0x75 (A0=VCC, A1=VCC, A2=VCC)
- PCF8574 8-bit GPIO(s) at I2C address(es) 0x20(-0x26), mapped to Z80
ports 0x80-0x86
In der nochmal beigefügten Paket sind diese so eingestellt.
Für mich ist das ein brauchbarer Kompromiss - man könnte dann noch 7
PCF8574 GPIOs anzuschließen.
Das AVR-UART ist wie im Original auf 115200, der I2C UART als default
auf 9600 in BIOS.MAC (setup_I2C_UART).
Die beiden Dokumente im Archiv sollten alles Wesentliche grob erläutern.
Den SC16IS740 UART kann man sicher auch mit anderen Quarzen betreiben,
dann müsste nur der Teiler neu ausgerechnet werden - Formeln aus dem
Datenblatt sind sicherheitshalber auch im Quellcode (BIOS.MAC und auch
in MODE.PAS).
Die Versionsnummer "2.2x" habe ich gewählt, damit ich sehe, ob meine
Änderungen wirklich ankommen. Es ist natürlich weiterhin ein CP/M 2.2
(bzw. ZSDOS).
@Martin
Ich bin gerade dabei deinen Code zu testen und zu übernehmen. Dabei sind
mir u.a. im CCP.MAC und ZDOS.MAC Laufwerkszuweisungen wie
maclib C:MEMCFG.LIB
aufgefallen. Hatte das einen Grund hier das Laufwerk C: anzugeben?
... die kannst Du entfernen.
Ich habe das neue System direkt auf dem AVR-CP/M-Stick erstellt und dort
liegt nur die AVRCPM.SUB Datei auf A: weil das CP/M SUBMIT nur von
Laufwerk A: aus funktioniert.
Aus Platzgründen liegen aber meine Quellen auf C: und ich musste für die
Makrodefinitionen deshalb einen Pfad angeben damit alles funktioniert.
Auch wenn die Verwendung des IOBYTE noch nicht implementiert ist, kannst
Du auch bei der Initialisierung des CP/M Systems den Default-Wert auf
148d (10.01.01.00b)setzen (wird augenblicklich auf Null gesetzt, d.h.
TTY: für alle 4 logischen Einheiten), dann gibt ein
1
STAT DEV:
schon mal die richtigen Zuordnungen aus.
In BIOS.MAC
Original:
Danke... hab mir schon sowas gedacht.
Ich habe mal alle Quellen um sich ein CP/M zu bauen in ein File gepackt
(cpm_source.zip). Außerdem gibt es Laufwerksimage auf dem direkt unter
CP/M das CP/M gebaut werden kann. Der Start erfolgt wie immer mit do
(Supersub) avrcpm.sub. Der Platz auf einer Diskette reicht gerade aus
dafür ;-)
Im BIOS hatte ich noch die Speierberechnung korregiert, es ist wieder
ein 62k CP/M (ist aber nur Kosmetik ;-)
Es wäre schön, wenn es noch jemand ausprobiert, die Erweiterungen von
Martin bzw. I2C sind wirklich sehr nützlich.
@Martin Die Änderungen bezüglich IOBYTE habe ich übernommen
Danke für die Sichtkontrolle und die Integrationsarbeit.
Ein aktualisiertes HEX file zum flashen ware im Repository auch gut
aufgehoben.
Mit 62K/64K hatte ich etwas gehadert und mich dann für die historisch
wohl falsche aber logischere 64K Bezeichnung entschieden. Ist aber
wirklich egal.
Martin H. schrieb:> Ein aktualisiertes HEX file zum flashen ware im Repository auch gut> aufgehoben.
Das ist der nächste Schritt.
Ich stelle gerade so etwas wie eine kleine Nachbauanleitung zusammen.
Hier werden als „Erststart“ auch die BIN bzw. Hex-Files bzw. die
Laufwerks-Images bereitgestellt. So kann der interessierte Nachnutzer
das System zunächst ohne die Hürden der Softwareerstellung in Betrieb
nehmen. Es hakt derzeit noch etwas bei der Lieferung aller meiner
benötigten I2C Komponenten. Einige sind beim Zoll hängen geblieben und
warten nun auf meine Auslöse :-)
Den Reformationstag habe ich genutzt, um das CON: Gerät zu reformieren.
Dort habe nun die IOBYTE Funktionalität implementiert.
Damit kann man jetzt systemweit zwischen dem AVR-UART und dem I2C-UART
umschalten. Alle Programme, die das BDOS verwenden, sollten damit
funktionieren. Ich habe es mit Turbo-Pascal, Multiplan Wordstar und Zork
getestet.
Wer ein Terminalprogramm wie Teraterm verwendet, muss die Zeilenenden
auf CR setzen, bei CR/LF überschreibt die Ausgabe sich selbst und man
sieht z.B. beim DIR nur eine Zeile.
Außerdem muss das lokale Echo ausgeschaltet sein, sonst sieht man alles
doppelt (bzw. nach ein paar Gläsern eben 4-fach).
Augenblicklich implementierte Zuordnungsmöglichkeiten für CON:
TTY: = AVR-UART
CRT: = I2C-UART
BAT: wie TTY:
UC1: wie TTY:
Weitere Möglichkeiten:
- die beiden weitere Optionen BAT: und UC1: könnte man noch für andere
Schnittstellen nutzen.
- die RDR:, PUN: und LST: Schnittstellen könnte man leicht auch noch
IOBYTE-tauglich machen, allerdings habe ich da im Augenblick keinen
direkten Bedarf.
Vielleicht bekomme ich ja mal einen Lochstreifenleser/stanzer, dann wird
es vielleicht interessanter ...
Je nach STAT Programm muss man unterschiedliche Zuweisungen angeben:
Das STAT auf meiner Festplatte C: ist ein anderes als das auf meiner
Diskette A:
Mit
1
STAT VAL:
bekomme ich auf A: TTY:, auf C: OCC: für den AVR-UART.
Anwendungsbeispiele:
... Anzeige der aktuellen Zuordnungen für die vier logischen Geräte
CON:, RDR:, PUN und LST:
1
A>STAT DEV:
2
CON: is TTY:
3
RDR: is PTR:
4
PUN: is PTP:
5
LST: is LPT:
... Anzeige der erlaubten Zuordnungen:
1
A>stat VAL:
2
3
Temp R/O Disk: d:=R/O
4
Set Indicator: d:filename.typ $R/O $R/W $SYS $D R
5
Disk Status : DSK: d:DSK:
6
User Status : USR:
7
Iobyte Assign:
8
CON: = TTY: CRT: BAT: UC1:
9
RDR: = TTY: PTR: UR1: UR2:
10
PUN: = TTY: PTP: UP1: UP2:
11
LST: = TTY: CRT: LPT: UL1:
... die Konsole auf die zweite serielle Schnittstelle (I2C-UART)
umlenken:
1
A>STAT CON:=CRT:
... ab hier erfolgen alle Ein- und -ausgaben vom I2C-UART, z.B. einem
zweiten Terminal.
1
A>STAT DEV:
2
CON: is CRT:
3
RDR: is PTR:
4
PUN: is PTP:
5
LST: is LPT:
... bis man dort ...
1
A>STAT CON:=TTY:
... eingibt.
Wie bisher kann man über "unlogische" (physikalische) Geräte auch Ein-
und Ausgaben auf der ursprünglichen AVR-UART-Konsole erzeugen:
1
A>PIP TTY:=readme.txt
... sendet den Datei-Inhalt IMMER auf den AVR-UART, unabhängig vom
IOBYTE.
1
A>PIP CRT:=readme.txt
... sendet den Datei-Inhalt IMMER auf den I2C-UART, unabhängig vom
IOBYTE.
Die Änderungen im BIOS sind gering und alles passt weiterhin noch in 52
Sektoren (obwohl ich rechnerisch immer auf 53 komme).
BIOS.MAC:
===============================================
1) zusätzliches equate für I2C Statusabfrage einfügen:
Joe G. schrieb:
[...]
> Ich stelle gerade so etwas wie eine kleine Nachbauanleitung zusammen.> Hier werden als „Erststart“ auch die BIN bzw. Hex-Files bzw. die> Laufwerks-Images bereitgestellt. So kann der interessierte Nachnutzer> das System zunächst ohne die Hürden der Softwareerstellung in Betrieb> nehmen.
Ich denke das ist sehr nützlich für den Einstieg.
> Es hakt derzeit noch etwas bei der Lieferung aller meiner> benötigten I2C Komponenten. Einige sind beim Zoll hängen geblieben und> warten nun auf meine Auslöse :-)
Ja, ja das sind auch meine besten Freunde dort - ich versuche meine
Bestellungen immer unter der magischen 22€ Grenze zu halten, das klappt
meistens. Ansonsten kostet mich der Abholspaß immer 2 Stunden und viel
Spaß beim Erklären - "Elektronikbauteile - was für eine Zollkategorie
ist das denn?" oder "was, ein alter Computer - ist das nicht
Elektronikschrott?".
Leider hatte ich keinen I2C UART mehr, sonst hätte ich mal einen
geschickt.
Martin H. schrieb:> Wäre toll, wenn Du das noch in Deine Testversion und dann ins> Repository einpflegen könntest.
Ich hoffe, ich komme morgen dazu. Auch der Zoll hat nun meine Baugruppen
durchgewunken ;-)
1) IOBYTE
Um die unendliche Geschichte vom IOBYTE abzuschließen, habe ich diese
noch für die LIST, PUNCH und READER Funktionen implementiert.
Damit kann man nun alle verfügbaren Geräten 'beliebig' zuordnen. Mit den
drei Schnittstellen AVR-UART, I2C-UART und I2C-GPIO bin ich in der
Praxis erst mal ausreichend versorgt.
Der Code des BIOS ist dadurch noch etwas angewachsen, passt aber gerade
noch in die ursprünglichen 7 Sektoren, sodass die Länge von 52 Sektoren
(à 128-Byte) für das System weiterhin ausreicht. Es sind nun aber nur
noch ein paar Bytes Luft am Ende.
Zur Übersicht hier nochmal die Größe der Komponenten, wie sie auf der
Boot-Diskette abgelegt sind:
1
IPL 1 record à 128 bytes = 0080h bytes - bootstrap loader
2
CCP 16 records à 128 bytes = 0800h bytes - command processor
3
ZSDOS 28 records à 128 bytes = 0E00h bytes - general CP/M DOS
4
BIOS 7 records à 128 bytes = 0380h bytes - hardware BIOS
5
52 records à 128 bytes
6
= 2*26 tracks*sectors
Augenblickliche Zuordnung der drei physikalischen I/O Geräte (AVR-UART,
I2C-UART, I2C-GPIO):
TTY: AVR-UART, input+output (Console)
CRT: I2C-UART, input+output (Console)
LPT: I2C-GPIO, output only (Printer)
UL1: I2C-UART, input only (PaperTape Reader)
UP1: I2C-UART, output only (PaperTape Punch)
BAT: AVR-UART, input+output (Console)
UC1: AVR-UART, input+output (Console)
Man könnte also theoretisch noch weitere UARTs für UL1:, UP2:, BAT: und
UC1: nachrüsten, wenn man das unbedingt braucht.
Das neue Code-Fragment in BIOS.MAC ist:
1
[...]
2
list:
3
ld a,(iobyte) ; get content of IOBYTE bits [7:8] to [0:1]
4
rlca ; rotate A left (11000000->10000001)
5
rlca ; rotate A left (10000001->00000011)
6
call JumpSel_01 ; select via bits [0:1]
7
dw AVR_UART_out ; 00=TTY:
8
dw I2C_UART_out ; 01=CRT:
9
dw I2C_GPIO_out ; 10=LPT:
10
dw AVR_UART_out ; 11=UL1:
11
12
listst:
13
ld a,(iobyte) ; get content of IOBYTE bits [7:8] to [0:1]
14
rlca ; rotate A left (11000000->10000001)
15
rlca ; rotate A left (10000001->00000011)
16
call JumpSel_01 ; select via bits [0:1]
17
dw AVR_UART_out_status ; 00=TTY:
18
dw I2C_UART_out_status ; 01=CRT:
19
dw I2C_GPIO_out_status ; 10=LPT:
20
dw AVR_UART_out_status ; 11=UL1:
21
22
punch:
23
ld a,(iobyte) ; get content of IOBYTE bits [5:4] to [1:2]
24
rrca ; rotate A right (00110000->00011000)
25
rrca ; rotate A right (00011000->00001100)
26
rrca ; rotate A right (00001100->00000110)
27
call JumpSel_12 ; select via bits [1:2]
28
dw AVR_UART_out ; 00=TTY:
29
dw I2C_UART_out ; 01=PTP:
30
dw I2C_GPIO_out ; 10=UP1:
31
dw AVR_UART_out ; 11=UP1:
32
33
reader:
34
ld a,(iobyte) ; get content of IOBYTE bits [5:4] to [1:2]
35
rrca ; rotate A right (00001100->00000110)
36
call JumpSel_12 ; select via bits [1:2]
37
dw AVR_UART_in ; 00=TTY:
38
dw I2C_UART_in ; 01=PTR:
39
dw AVR_UART_in ; 10=UR1:
40
dw AVR_UART_in ; 11=UR1:
41
42
; ----- specific handlers
43
[...]
2) Speicherzuordnung
Was mich immer etwas gestört hat, war die Inkonsistenz bezüglich der
Speichergröße (62K vs. 64K) sowie die teilweise Duplizierung von EQUates
in den Libraries GFCACPM.LIB und MEMCFG.LIB. Außerdem hatte ich das
'Gefühl', dass der teure 64KB Speicher nicht vollständig ausgenutzt
wird.
Dazu habe nun ich meine Version bereinigt und als relevante Größen muss
ich nun nur noch einmal die Speichergröße sowie die Längen von CCP, BDOS
und BIOS angeben.
Daraus werden dann die Ladeaddressen berechnet und einheitlich
bezeichnet (ccploc, bdosloc, biosloc).
Jede Änderung muss nun nur noch in MEMCFG.LIB angepasst werden. Diese
muss immer vor CFGACPM.LIB eingebunden werden.
Ich habe auch die teilweise verwendete Rundung auf ganze KBytes
entfernt.
Dazu musste ich allerdings ein paar alte EQUates z.B. im IPL und ZSDOS
ändern, da teilweise der gleiche Name für unterschiedliche Dinge
verwendet wurde.
MEMCFG.LIB:
maclib MEMCFG.LIB ; -MH- define msize and component lengths
4
maclib CFGACPM.LIB ; -MH- define load addresses etc.
5
6
.phase bdosloc ; -MH-
7
[...]
CCP.MAC:
1
[...]
2
maclib MEMCFG.LIB ; -MH- define msize and component lengths
3
maclib CFGACPM.LIB ; -MH- define load addresses etc.
4
5
.phase ccploc ; -MH-
6
[...]
7
serialize: ;check serialization
8
ld de,serial
9
ld hl,bdosloc ; -MH-
10
ld b,6 ;check six bytes
11
[...]
12
badserial:
13
ld hl,76f3h ;'di hlt' instructions. [di or (hlt shl 8)]
14
ld (ccploc),hl ; -MH-
15
ld hl,ccploc ; -MH-
16
[...]
17
end ccploc ; -MH-
Ich hatte einige Problem die wahre Größe des BIOS rechnerisch
festzustellen, da nach Ende des Codeteils noch nicht-initialisierte
Disketten- und Festplattenparameter folgen, deren Größe mit Hilfe von
Makros berechnet wird, die ich nicht komplett durchschaue. Diese
Bereiche werden z.B. von STAT C: oder von PIP B=C (copy) verwendet.
Von jeder Änderung der Speicherzuordnung sind alle vier Komponenten IPL,
CCP, BDOS und BIOS betroffen.
Nach einigen rechnerischen Fehlversuchen habe ich mich dann in Schritten
von 100h an die wahre Größe herangetastet. Dazu habe ich nach jeder
Änderung den Speicher mit DDT angesehen. Der Speichertest beschreibt ja
den Speicher mit 'v' sodass man gut sehen kann, wo was verändert wurde.
Letztendlich konnte ich die allokierte Größe des BIOS von 0D00h auf
0900h verringern. Diese Größe beinhaltet den BIOS code plus den Platz
für Disketten und Festplattenparameter.
Damit bleiben am Ende des Speichers noch ein paar Bytes frei und man hat
ca 1 KB mehr Arbeitsspeicher für Programme gewonnen.
Turbo-Pascal meldet dann (überschreibt den CCP) 26640 bytes (von
7B5-E406) frei.
Viele Programme wie Multiplan, Wordstar, Power etc. funktionieren damit.
Allerdings habe ich dann leider festgestellt, dass speziell der PIP beim
Kopieren anscheinend doch mehr im hohen Speicherbereich beansprucht und
einfach mit halbkopierten Dateien abbricht, wenn das BIOS nicht 0D00h
groß ist.
Eine Technische Dokumentation zum PIP und den benutzen Speicherbereichen
habe ich leider nicht gefunden.
Daher habe ich die Größe des BIOS wieder auf die ursprünglichen Werte
zurückgesetzt.
Damit bekomme ich wieder die 'alte' Speicherbelegung.
Meine kompletten Quellen sind im angehängten ZIP Archiv.
Martin H. schrieb:> Ich hatte einige Problem die wahre Größe des BIOS rechnerisch> festzustellen, da nach Ende des Codeteils noch nicht-initialisierte> Disketten- und Festplattenparameter folgen, deren Größe mit Hilfe von> Makros berechnet wird, die ich nicht komplett durchschaue.
Schau Dir dazu das Kapitel "10. DISK PARAMETER TABLE" im CP/M 2.2
Alteration Guide an. Die relevanten Parameter sind CSV und ALV. Im
AVR-CP/M Bios werden die dafür nötigen Buffer abhängig von der Anzahl
und Größe angemeldeter Laufwerke dynamisch am Ende des BIOS angelegt.
D.h., je mehr Laufwerke angemeldet sind, und je größer diese sind, um so
mehr Platz wird für die CSVs und ALVs benötigt.
> Diese> Bereiche werden z.B. von STAT C: oder von PIP B=C (copy) verwendet.
Nein, sie werden vom BDOS genutzt, abhängig von den aufgerufenen
Funktionen.
Martin H. schrieb:> Allerdings habe ich dann leider festgestellt, dass speziell der PIP beim> Kopieren anscheinend doch mehr im hohen Speicherbereich beansprucht und> einfach mit halbkopierten Dateien abbricht, wenn das BIOS nicht 0D00h> groß ist.
Eigentlich sollte bereits das Login eines Laufwerks mit einer
Fehlermeldung scheitern, wenn der Platz für die anzulegenden Buffer
nicht reicht.
Nachtrag:
Ich kann jetzt alle deine Quellen fehlerfrei übersetzen. Mein M80 möchte
einige TAB's nicht :-(
Meine I2C Testhardware ist auch kurz vor der Vollendung.
Mein Testaufbau ist noch doch etwas umfangreicher geworden als
ursprünglich geplant :-)
Neben den I2C Komponenten
- RTC mit PCF8583
- RS232 mit SC16IS750
- 16 Bit I/O mit MCP23017
habe ich noch eine DRAM kompatible SRAM Schaltung aufgebaut. Verbaut ist
ein 256kx8 SRAM, der sich mit seiner Ansteuerung (2 x Latch + Logik)
pinkompatibel zu den DRAM’s verhält. Zwei Gatter könnte man noch
einsparen, müsste aber im größeren Maß in den derzeitigen Quelltext
eingreifen. Jetzt kann einfach die neue Schaltung statt eines nicht mehr
verfügbaren DRAM’s eingesetzt werden. Nicht ganz – den Refresh habe ich
noch abgeschaltet :-) Somit lässt sich das CP/M – System nun komplett
mit aktuellen Bauelementen aufbauen. Für einen altersgerechten und
augenfreundlichen Aufbau habe ich versucht weitgehend auf SMD zu
verzichten.
@Martin
Ich habe nun mit meinem Experimentalaufbau alle deine Funktionen
getestet. Meine I2C Konfiguration sieht dabei wie folgt aus:
A>i2cscan
Scanning I2C bus for devices...
*** Device found at slave address 27h = 39d (8-bit: 4Eh = 78d)
*** Device found at slave address 48h = 72d (8-bit: 90h = 144d)
*** Device found at slave address 50h = 80d (8-bit: A0h = 160d)
Done.
Die Umleitung des Terminals auf die zweite serielle Schnittstelle
funktioniert.
Terminal 1 (115200 Baud)
A>stat dev:
CON: is OCC:
RDR: is CRT:
PUN: is CRT:
LST: is COM:
A>stat Val:
Temp R/O Disk: d:=R/O
Set Indicator: d:filename.typ $R/O $R/W $SYS $DIR
Disk Status : DSK: d:DSK:
User Status : USR:
Iobyte Assign:
CON: = OCC: ECC: BAT: AUX:
RDR: = COM: CRT: AUX: PRI:
PUN: = COM: CRT: AUX: PRO:
LST: = LPT: CRT: COM: AUX:
stat con:=ecc:
Terminal 2 (9600 Baud)
A>stat dev:
CON: is ECC:
RDR: is CRT:
PUN: is CRT:
LST: is COM:
stat con:=ecc:
Terminal 1 (115200 Baud)
Die Baudratenumschaltung und Datenübertragung auf der zweiten seriellen
Schnittstelle funktioniert bis 460800 Baud fehlerfrei. Der 16 Bit I/O
Port geht auch. Somit sollten alle deinen neuen Funktionen laufen.
Super!
@Leo C.
Ohne Refresh (meine Version mit DRAM) ist das System natürlich nun noch
schneller ;-)
mit Refresh ACT : 3.86s
ohne Refresh ACT : 3.799s
Klasse! Danke für Deine Mühe - das mit den Tabs ist merkwürdig - ich
habe auch immer den M80 verwendet.
Ich denke, damit ist das AVR/CPM noch ein bisschen näher an die damalige
Realität gerückt und auch flexibler nutzbar.
Den Kermit 4.11 von Leo C. der hier im Thread angeboten wurde, habe ich
auch verwendet - er erkennt den I2C-UART selbst und scheint darauf hart
verdrahtet zu sein. Man kann auch damit die Baud-Rate einstellen, wie
mit meinem MODE Programm. Ich bin nicht sicher, ob die Quellen
inzwischen im AVR-CPM-SVN liegen, damit das Programm längerfristig
erhalten bleibt.
Andererseits könnte man auch noch mit einem originalen Kermit 4.11
probieren, ob man mit SET PORT nun einfach auf die zweite serielle
Schnittstelle (I2C) schalten kann und dann die normalen Ausgaben
weiterhin auf CRT: erscheinen.
Dann bräuchte man die Spezialversion nicht mehr unbedingt, müsste aber
dann die Baud-Rate extern einstellen.
Ich verwende meistens das Original STAT Programm von DR - das bringt
dann andere Namen für die Lochstreifenleser etc., was aber nur
kosmetischer Natur ist.
Dann muss ich nur noch die Ein- und Ausgänge meines I2C-GPIO mit
Pegelwandlern auf 5V Niveau für eine Centronics Drucker-Schnittstelle
heben.
Irgendwo habe ich auch noch ein RTC Platinchen herumliegen - mal sehen
ob das noch in mein Gehäuse passt...
Martin H. schrieb:> Dann muss ich nur noch die Ein- und Ausgänge meines I2C-GPIO mit> Pegelwandlern auf 5V Niveau für eine Centronics Drucker-Schnittstelle> heben.
Der TXS0108E scheint mir daür genau der richtige Kandidat zu sein.
Ja, das würde passen (plus 3 Steuerleitungen für den Drucker).
Entweder so oder den gesamten Chip auf 5V heben und dann nur die zwei
I2C Leitungen von 3.3V auf 5V übersetzen. Ist vielleicht eleganter und
bräuchte nur 2 diskrete Konverter-Transistoren.
Ich habe sowieso einen 5V auf 3,3 Step-Down Regler nach der
Anschlussbuchse für die Spannungsversorgung.
Martin H. schrieb:> Ist vielleicht eleganter und> bräuchte nur 2 diskrete Konverter-Transistoren.
Ja, zwei BSS138 sind auch schnell integriert. Außerdem gibt es den MCP
23017 auch als DIL-Version, so dass man ihn bequem auf eine Fassung
stecken kann.(Eine defekte PIO war früher mein Lieblingsbauelement ;-)
Ich finde das IOBYTE als sehr schöne und elegante Sache die sehr gut zum
System passt sobald man mehr als eine serielle Schnittstelle angebaut
hat. Beim späteren MSDOS ist das nur noch ansatzweise vorhanden (MODE
LPT1:=CON2: sowie Umleitung mit '<','>'), durch die dann populär
werdende direkte Hardwareansteuerung völlig verloren gegangen.
Ich habe mir auch noch mal einen generischen Kermit 4.11
zusammengebastelt, d.h. ohne Kenntnis der I2C Schnittstelle. Den kann
man nun z.B. mit SET PORT CRT auf eine "beliebige" serielle
Schnittstelle umstellen, was eigentlich schöner ist als eine
Spezialversion zu haben. Allerdings muss man dann die Baud-Rate vorher
extern einstellen.
Irgendwie bekomme ich keine Dateiübertragung damit hin. Mit PIP
funktioniert es, d.h. die Schnittstellen sind verbunden und die Baudrate
stimmt. Hat Kermit noch ein Geheimnis, das ich nicht kenne? Meine
Einstellungen sind eigentlich auch ganz simpel:
SET PORT CRT
SET FILE-MODE BINARY
SET FLOW ON
SET AUTORECEIVE ON
RECEIVE
Aber es wird nicht mal der Dateiname übertragen. Zwei DOS Kermit
untereinander verstehen sich, nur Kermit-80 nicht.
Martin H. schrieb:> Den Kermit 4.11 von Leo C. der hier im Thread angeboten wurde, habe ich> auch verwendet - er erkennt den I2C-UART selbst und scheint darauf hart> verdrahtet zu sein. Man kann auch damit die Baud-Rate einstellen, wie> mit meinem MODE Programm.
Mich würde interessieren, ob es einen Performance-Unterschied zwischen
dem speziell angepaßten und dem Generic-Kermit gibt.
> Ich bin nicht sicher, ob die Quellen> inzwischen im AVR-CPM-SVN liegen, damit das Programm längerfristig> erhalten bleibt.
Leider sind die Quellen noch nicht im SVN. Zudem ist mein kleiner Server
seit kurzem down. Da es noch "etwas" dauern kann, bis ich ihn,
wahrscheinlich mit neuer Hardware, wieder hochfahren kann, hänge ich die
Quellen mal hier an.
Inzwischen haben ich meinen MCP23017 GPIO auf 5V umverdrahtet und zwei
Level-Converter in die I2C Leitungen eingefügt.
Dann noch ein Kabel mit D-SUB-25 Buchse in PC-Parallelport-Belegung
gelötet und dort ein normales PC-Centronics Druckerkabel angesteckt.
Als Drucker hatte ich nur einen HP ThinkJet zur Hand.
Ausdrucken mit
1
PIP LST:=file.txt
funktionierte einwandfrei; wenn das Papier ausging, stoppte der Druck
und nach Einlegen eines neuen Blatts ging es weiter.
Ebenso, wenn der Druckerpuffer voll war - dann ging des Ausdruck
häppchenweise nach jeder ausgegebenen Zeile weiter.
D.h. die Statusabfragen (BUSY, PAPER) und (unendlich langen)
Warteschleifen funtionieren wie geplant.
Auch CTRL+P zum Einschalten der Protokollierung geht, solange die
Programme über BDOS und nicht direkt über BIOS-Calls ausgeben (vielfach
leider üblich um Geschwindigkeit zu gewinnen).
Das einzige was mir noch auffiel war, dass nach Abschalten des Druckers
seine LEDs noch mit etwa halber Intensität weiterleuchteten.
Dabei scheint der Drucker über die Centronics-Schnittstelle noch Strom
zu ziehen - vielleicht eine Abart dieses speziellen Druckertyps.
Um das abzustellen, habe ich im BIOS noch zwei Zeilen ("; *** NEU ***")
eingefügt, um die Leitungen D0-D7 nach Ausgabe eines Zeichens definiert
auf 0V zu setzen.
Dann gehen die LEDs aus, wenn der Drucker abgeschaltet wird.
1
; ----- GPIO -----
2
3
I2C_GPIO_out:
4
IF MCP23017
5
ld a,c
6
out (I2C_GPIO_DATA),a ; data to A[0:7]
7
ld a,0
8
out (I2C_GPIO_DATB),a ; drop STROBE/ on B[3]
9
; stays low for 300 us, more than the required 0.5 us
10
ld a,8
11
out (I2C_GPIO_DATB),a ; rise STROBE/
12
GPIO_busy:
13
in a,(I2C_GPIO_DATB)
14
bit 0,a ; test bit 0
15
jp nz,GPIO_busy ; wait while B[0] = 1
16
; *** NEU ***
17
ld a,0
18
out (I2C_GPIO_DATA),a ; drop data lines to avoid backpowering printer when OFF
19
; *** NEU ***
20
ELSE
21
jp AVR_UART_OUT ; only one device
22
ENDIF
23
ret
Zu dem Problem mit dem generischen Kermit muss ich nochmal nachsehen...
Der generische Kermit funktioniert, allerdings hatte ich zunächst auch
Probleme.
Vermutlich war der UART in einem "undefinierten" Zustand infolge
vorheriger Experimente.
Wenn der I2C UART aber mit z.B. MODE initialisiert wird, sollte es
funktionieren.
Gegenüber dem angepassten Kermit ist die Geschwindigkeit auf etwa die
Hälfte reduziert.
Es muss sich ja beim generischen Kermit jedes Byte durch die
BDOS/BIOS/IOBYTE/AVR Schichten durchwühlen, das dauert...
Generic Kermit 4.11 using IOBYTE vs. special version accessing I2C UART:
Ich bin die Tage auf ein nettes Tool von Josh Bensadon gestoßen, den
„CP/M Disk Explorer“. Mit diesem können unter Windows CP/M Images
gelesen oder geschrieben/erzeugt werden. Weiterhin enthält er ein Tool,
um gleich den DPB Block zu erzeugen oder auch eigene Formate zu
kreieren. Für unsere Formate, AVRCPM und SIMHD habe ich mal in die
Diskdefinitionen eingetragen, um die Images zu bearbeiten. Das Tool
verzeiht jedoch keine Fehler. So muss das AVRCPM-Format exakt 256.256
Byte lang sein, ansonsten gibt’s „mecker“. In der ZIP-Datei gibt es als
Laufwerk G gleich die aktuellen BIOS und CP/M Quellen.
Über Weihnachten ist mir aufgefallen, dass der Busy Test in der
I2C_GPIO_out Routine NACH Ausgabe des Zeichens erfolgt. Das funktioniert
auch, d.h. die Routine wartet sauber, bis der Drucker das Zeichen
ausgegeben hat.
Wenn der Druckvorgang allerdings schon ohne Papier oder Off-Line
startet, wird das erste Datenbyte ins Nirvana ausgegeben und danach
gewartet.
Es wäre also besser die Testschleife
1
GPIO_busy:
2
in a,(I2C_GPIO_DATB)
3
bit 0,a ; test bit 0
4
jp nz,GPIO_busy ; wait while B[0] = 1
an den Anfang unmittelbar vor dem laden des Zeichens von (C) nach (A) zu
verschieben. Ist nur eine Kleinigkeit.
Der CPM-Disk-Explorer klingt ganz interessant - werde ich mal
ausprobieren.
Bislang habe ich mit dem cpmtools auf der Kommandozeile gearbeitet,
funktioniert gut, man muss aber halt immer die Syntax im Kopf haben oder
Skripte schreiben.
Was ich aber noch mehr vermisse, sind Tools um die CP/M typischen
Archive wie .LBR oder komprimierte Dateien (SQU, ARC, ZOO, ...) direkt
unter Windows zu öffnen. Wenn ich so durch diverse CP/M Sammlungen gehe,
wimmelt es da ja von solchen Dateien.
Dazu kenne ich nur MS-DOS Tools, von denen es leider meistens keinen
Quellcode gibt.
Gibt es da eigentlich etwas, das wie ein Datei-Explorer unter Windows
arbeitet?
Ich wünschte mir da so einen Allesfresser, habe ihn aber nicht zu
Weihnachten bekommen...
Ich hatte schon mal angefangen, mir einen LBR-Leser und erste DeARCer
und UnSQUeezer zu schreiben, das ist aber recht mühsam, wegen der vielen
Kompressionsformate und Optionen.
Die klassischen ZIP Dateien kann man ja gut mit diversen Tools
inspizieren, aber für die älteren gibt es wohl keine "modernen" Tools
mehr?
Martin H. schrieb:> Es wäre also besser die Testschleife...
Das scheint mir eine sinvolle Änderung :-)
> Gibt es da eigentlich etwas, das wie ein Datei-Explorer unter Windows> arbeitet?
Ja, der TotalCommander mit einer entsprechenden Erweiterung [1]. Diese
Erweiterung bindet quasi die CP/M Tools in den TC ein. Über Skripte [2]
könnten nun die unterschiedlichen Packer für CP/M integriert werden.
[1] https://hc-ddr.hucki.net/wiki/doku.php/cpm/disketten_xp2
[2] http://totalcmd.net/plugring/ScriptWFX.html
In den letzten Tagen habe ich noch eine RTC mit dem PCF 8563T
implementiert, da ich kein fertiges breakout board mit dem 8583 bekommen
habe.
Der 8563 ist ähnlich aber nicht gleich wie der 8583.
Der chip zählt Jahre von 0...99. Ich habe mich für 1970 als Basis
entschieden und addiere bzw. subtrahiere dann 1970 um auf die aktuelle
Jahreszahl zu kommen. Damit kann ich also 1970 bis 2069 abdecken, was
für meine Lebenserwartung ausreichend ist. Ein RAM hat der chip nicht,
wird auch nicht gebraucht.
Ich habe das im Augenblick noch mit #if I2C_PCF8563 wie bei den anderen
I2C Devices in meinem code stehen, werde aber noch die bisherige
Variante für den 8583 ebenso klammern. Ich denke I2C_SUPPORT sollte
nicht unbedingt automatisch die RTC einbinden - das ist ja auch nur eine
Option, zumindest bei den älteren AVR-CPM-Stick boards.
rtc_get funktioniert (z.B. beim booten), wo rtc_set verwendet wird, habe
ich noch nicht herausgefunden...
Martin
Ich denke es wird Zeit, mal eine Teildokumentation zu den I2C
Komponenten nachzuliefern. Schließlich soll es ja keine Zweimannshow
bleiben ;-) Im Anhang also die derzeit vom AVR-CP/M unterstützen I2C
Komponenten mit ihrer Beschaltung. Deine RTC würde ich noch mit
aufnehmen.
Ah sehr schön übersichtlich - gut auch, dass Du konsequent die
sogenannten "7-bit" I2C Adressen angegeben hast - im Quellcode habe ich
da auch immer so angepasst (beim PCF8583 stehen noch die "8-bit"
Adressen drin, die sollten gelegentlich noch in (ADDR<<1) geändert
werden, damit alles einheitlich ist).
Der 8563 ist fast gleich wie der 8583, hat aber eine unveränderliche I2C
Adresse von 0x51.
Hat jemand Interesse als Beta-Tester mitzuwirken?
Geplant ist ein Bausatz für ein AVR-CP/M System mit heute verfügbaren
Bauelementen. Dazu wurde der bisherige DRAM durch eine Schaltung mit
einem SRAM ersetzt und getestet [1]. Die Software bleibt kompatibel. Um
die Nachbausicherheit zu erhöhen und möglichst auch Anfängern den Aufbau
zu erleichtern, wurde weitgehend auf SMD-Bauelemente verzichtet. Der
Aufbau und die Inbetriebnahme soll dabei Schritt für Schritt, anhand
einer Baumappe erfolgen. Dazu wurde die USB-Schnittstelle als
Debug-Schnittstelle implementiert. Die folgenden Funktionen sind
realisiert:
1 x RS232 (CP/M)
1 x LPT-Port (CP/M)
1 x PS2 Keyboard (VT100-Terminal)
1 x VGA (VT100 Terminal)
1 x RTC
1 x 8-Bit GPIO (3.3V)
1 x I2C-Bus (3.3V und 5V)
1 x SD-Card
1 x USB-Port
Der USB-Port kann über DIP-Switch zur Inbetriebnahme wahlweise auf das
AVR-CP/M oder das VT100-Terminal geschaltet werden. Im Normalmoduls ist
dann das CP/M mit dem VT100 verbunden. Weiterhin kann zu Testzwecken der
RS232-Port auf die USB-Schnittstelle umgelenkt werden.
Gesucht sind zwei Beta-Tester (Aufbauerfahrung sollte vorhanden sein),
die schrittweise nach Baumappe, das System aufbauen und ihren Aufbau
bzw. Fehler dokumentieren. Weiterhin soll dabei gleichzeitig der
Reichelt Warenkorb aktualisiert werden. Die gleiche Vorgehensweise gilt
für die Softwareimplementierung. Ziel der ganzen Aktion ist ein freier
robuster Bausatz für das AVR CP/M, ganz ohne kommerzielle Interessen.
Beide Beta-Tester würden von mir je eine Leiterplatte (ohne Bauelemente)
zur Verfügung gestellt bekommen. Interessenten melden sich bitte einfach
per PN.
[1] Beitrag "Re: CP/M auf ATmega88"
Joachim W. schrieb:> Kannst du bitte den Schaltplan posten?
Bitteschön. Die Schaltungen sind alle einzeln und zum Teil auch
innerhalb des CP/M, aber noch nicht in diesem Layout getestet.
> Alles auf einer Seite?
Ja, alle Bauelemente befinden sich auf der Bestückungsseite.
Joe G. schrieb:> Joachim W. schrieb:>> Kannst du bitte den Schaltplan posten?>> Bitteschön. Die Schaltungen sind alle einzeln und zum Teil auch> innerhalb des CP/M, aber noch nicht in diesem Layout getestet.>>> Alles auf einer Seite?> Ja, alle Bauelemente befinden sich auf der Bestückungsseite.
Vielen Dank :)
Mal so als Frage... wäre für eine Neuentwicklung mit SRAM vielleicht ein
Atmega8515 sinnvoll (wegen XMEM)?
Vor längerer Zeit habe ich für den einen i8080-Emulator umgesetzt. Der
braucht 3 KB Flash, braucht selbst keinen RAM und besteht die Testsuite.
Im Gegensatz zum AVR CP/M (der als Vorlage diente), habe ich das aber
für avr-as geschrieben, weil mir C mehr Spaß macht als Assembler.
Den Code habe ich mal angehängt. Weil avr-as keine halben Pointer mag,
generiert das Perlscript aus i8080.o eine i8080_tables.S, die man zum
Projekt dazulinken muss.
Der i8080 wird mit emu_start() aufgerufen und ruft folgende Funktionen
auf:
1
// wenn EMULATE_IO aktiviert:
2
uint8_temu_io_read(uint8_tport);
3
voidemu_io_write(uint8_tport,uint8_tdata);
4
5
// wenn BDOS aktiviert (für CONOUT und PRINTSTR):
6
voiduart_putc_raw(uint8_t);
7
8
// wenn TRACE aktiviert:
9
intprintf_P(constchar*fmt,...);
Mit MEMBASE lässt sich die Basisadresse des i8080-Adressraums im
AVR-Adressraum in 256 Byte-Schritten einstellen. Die CPU startet bei
0x0000 oder bei aktiviertem BDOS bei 0x0100.
Der i8080 lebt im und hat vollen Zugriff auf den AVR-Adressraum,
inklusive der SFRs und CPU-Register. Auf einem Atmega8515 ließe sich
also maximal ein 63 KB CP/M bauen (mein Testsystem hat aber nur 32 KB),
dafür kann man den Emulator auch direkt im internen RAM laufen lassen.
Die Performance habe ich nicht gemessen, aber wenn ich mich beim
Taktezählen nicht vertan habe, braucht ein NOP nur 32 Takte. Viel
Optimierpotential sehe ich da nicht.
S. R. schrieb:> Mal so als Frage... wäre für eine Neuentwicklung mit SRAM vielleicht ein> Atmega8515 sinnvoll (wegen XMEM)?
Es ist ja keine Neuentwicklung, sondern ich habe einfach die Baugruppen
und Software, welche so nach und nach entstanden sind, auf eine
Leiterplatte gebracht. Der Wechsel von DRAM auf SRAM ist nur meinem
persönlichen Spieltrieb geschuldet ;-) interessanter ist die Frage nach
der Sinnhaftigkeit eines solchen Projektes.
Stein des Anstoßes waren Studenten des 7. Semesters, welche wahllos 5V
Systeme mit 3.3V Systemen zusammenschalten, keinen Bus debuggen können,
weder SMD noch THT ordentlich löten können, nur rudimentär programmieren
können, keine systematische Fehlersuche durchführen können… Die
Aufzählung kann noch beliebig erweitert werden.
Zukünftig sollen interessierte Studenten des ersten Semesters einen
Bausatz in die Hand gedrückt bekommen und ihn unter fachkundiger
Begleitung in Betrieb nehmen. Mal sehen, was sich dann daraus
entwickelt.
Wirklich schön, wie sich das alles so weiter entwickelt hat!
Insbesondere die I2c Unterstützung.
Kann auch sein, das hier alles inkl VT100 Terminal genau die richtige
Lösung ist für den skizzierten Einsatzzweck.
Aber ich bin kein Freund von dem VT100 mit auf der Platine. Dazu kann
man besser jedes Terminal Programm und USB-TTL Schnittstelle nehmen -
ist aber nur meine Meinung. Ich mag halt keine Propeller Chip da drauf,
nur fürs Terminal ;-)
Peter
Holla, das ist ja schon ein richtiger Großrechner mit allem Drum und
Dran!
Wenn man das noch mit einer kleinen Tastatur (gibt es so etwas wie die
Cherry Kassentastaturen G84-4100 auch mit PS/2?) und einem kleinen TFT
Display kombiniert, könnte man einen schicken kleinen CP/M Laptop bauen.
Onkel Osborne lässt grüßen.
Zum VT100 Emulator habe ich noch eine Idee/Frage: Beim Programmieren
kommt sehr schnell der Wunsch nach Grafik auf. CP/M bietet da per
Definition nichts (GSX ist etwas hoch gegriffen und schluckt Speicher),
aber man kann einfache, aber durchaus ansprechende Vektorgrafik leicht
mit jeder Programmiersprache realisieren, wenn das Terminal passende
Escapesequenzen unterstützt.
Wenn ich z.B. Teraterm als Soft-Terminal verwende, versteht dies auch
Tektronix Befehle und macht sogar ein extra Grafikfenster auf. Dann kann
ich von meinem AVR-Stick Text und Grafik sogar "gleichzeitig" ausgeben.
Ich mag Tektronix, aber wenn es moderner sein soll, wären auch Regis
(DEC) oder HPGL (Plotterbefehle in ASCII) mögliche Alternativprotokolle.
Deshalb die Frage: kann der Propeller-Code erweitert werden, sodass er
auch einen Grafikbildschirm (als Alternative zum Textmodus) anzeigen
könnte? Oder reicht da der Speicher nicht für z.B. 640x400 monochrome
Pixel (=32 KB).
Eventuell wäre da eine separate, optional andockbare Terminalplatine
sinnvoll.
Apollo M. schrieb:> hi, frage ... warum wurde der ram nicht via spi interface integriert,> wäre auch nicht langsamer als parallel und mit addr latch und so?
Schau mal hier:
Beitrag "Re: CP/M auf ATmega88"Martin H. schrieb:> Zum VT100 Emulator habe ich noch eine Idee/Frage:
Ich schreib morgen mal was dazu...
Apollo M. schrieb:> hi, frage ... warum wurde der ram nicht via spi interface integriert,> wäre auch nicht langsamer als parallel und mit addr latch und so?
Kannst du das einmal vorrechnen, wie viel Zeit nach der einen bzw. nach
der anderen Anbindung gebraucht wird.
Martin H. schrieb:> Zum VT100 Emulator habe ich noch eine Idee/Frage:
Die RAM-Größe des Propellers beträgt nur 32KB. Für eine Pixelgrafik also
zu wenig. Ich denke, eine TEK4010 Emulation wird nicht möglich sein. Um
dennoch mit unterschiedlichen Zeichensätzen und Grafikelementen zu
arbeiten, können verschiedene Character Sets [1] umgeschaltet werden.
Für eine Weiterentwicklung würde ich den Propeller verlassen und ein
anderes Konzept favorisieren (RaspberryPI / Bare Metal [2]). Zumal HDMI
und USB bzw. Bluetooth-Tastaturen heute üblicher als VGA und PS2 sind.
Das ist jedoch eine andere Baustelle ;-)
[1] Beitrag "Re: VT100-Terminal (VGA+PS2)"
[2] https://ultibo.org/
Die ersten Platinensätze sind eingetroffen. Ich baue nun ein Startmuster
auf, um jeden einzelnen Inbetriebnahmeschritt zu dokumentieren bzw.
Fehler auszumerzen. Im nächsten Schritt dürfen dann die Betatester ran
;-)
moin,
spiele gerade RunCPM auf einem TeenSy3.6 rum.
echt beeindruckend.
beim 180MHz CPU-takt geht da schon einiges los.
gab es hier nicht mal einen benchmark um das ganze mal etws einordnen zu
können?
als terminal habe ich hier tera-term als vt100.
laufwerke sind auf einer sd-card.
Der erste Schritt ist getan. Das System läuft und das Layout bzw. die
Leiterplatte sind (fast) fehlerfrei. An zwei Stellen ist der
Bestückungsaufdruck um 180 Grad gedreht. Die Aufbaudokumentation wird an
diesem WE auch fertig werden, so dass Interessenten loslegen können. Da
der LP-Hersteller überliefert hat, kann ich in Summe noch 5 Platinen zum
Testen abgeben. Hans-Werner und Marcel sind schon berücksichtigt;-) Die
Dokumente zum Aufbau und die komplette Software wird vollständig in
Github [1] abgelegt.
[1] https://github.com/Feinmechaniker/AVRCPM
Horst S. schrieb:> danke, aber wie bekomme ich das image auseinander?
Mit den CP/M tools? Die Images sind (wie meistens) im simhd Format.
Aber warum überhaupt? Warum nicht einfach auf eine SD-Karte kopieren?
Joe G. schrieb:> RunCPM verwendet nur noch das FAT-Filesystem, es gibt kein Image mehr.
Ach ja, darum gings ja.
Aber wie man auf dem PC Dateien aus einem Image heraus oder
hineinkopiert, wurde hier ja schon öfters beschrieben.
Horst S. schrieb:> Dhrystone(1.1) time for 5000 passes = 0
Du mußt die Funktion time() für das RunCPM-System anpassen, oder das
Dhrystone-Programm so kompilieren, daß Du mit einer Stoppuhr messen
kannst. Die Anzahl Loops muß evtl. auf 50000 oder 500000 hochgesetzt
werden. Die Anleitung dazu ist im Sourcecode "dry.c" enthalten. Im
Anhang Benchmark und Hi Tech C Compiler ohne Image.
Martin H. schrieb:> @ David R.> Did you use an SD card (not SD-HC)?> The boot messages look like the card is not recognized.> Try with a plain old SD card (2 GB or so).
@ Martin H.
im using a samsung 4G card and toshiba 2GB FAT formatted under windows
David R. schrieb:> im using a samsung 4G card and toshiba 2GB FAT formatted under windows
Any 4G SD card is SD-HC (there are very few exceptions).
Your screenshot is surprisingly bad. Please do not capture more than
needed (no white areas), and upload screenshots as PNG. See the rules
listed above the response field.
Also, you seem to have other problems as well:
See the line about the C: drive, it is not shown correctly.
Try to test your board without CP/M. I think something else is fishy.
Anbei ein XMODEM für das System mit I2C-UART über RDR: und PUN: Ich habe
die Config-Datei gleich angepaßt. Damit geht das Kopieren von Datein
zwischen CP/M und PC auch ohne Kermit recht fix.
Hallo zusammen,
nur als Appetizer - was man so mit einem CP/M-AVR System (in diesem Fall
der gute, alte CP/M-Stick) so machen kann.
Das MultiTel-D zeigt 80x24 Zeichen und hat eine serielle Schnittstelle
sodass man es als Terminal benutzen kann.
Der CP/M-AVR Stick pass in den Raum für den integrierbaren Drucker -
dann hätte ich einen kompakten, portablen CP/M Rechner ;-)
Habe nur noch nicht herausgefunden, auf welche Escape-Sequenzen es
reagiert (CTRL-L löscht schon mal den Bildschirm).
Martin
PS: wenn die aktuelle Platine die serielle Schnittstelle für das
Terminal auf zusätzlich herausführen würde (einfache Steckerleiste mit
oder ohne MAX232 reicht), könnte man eventuell auch für die Puristen
eine Alternative ohne Propeller-Chip und PS/2 mit der gleichen Platine
aufbauen.
Schöner Aufbau Martin :-)
Die Bestückung des Propellers ist für das CP/M nicht zwingend notwendig
(siehe Übersicht). Es können
1. per USB alle seriellen Schnittstellen (AVR, Propeller, RS232)
angesprochen werden
2. direkt RS232 (9 polig D-SUB) benutzt werden
3. RS232 auf USB umgelenkt werden
Man kann also auch CON: auf CRT: legen und CRT: auf USB ;-)
Anbei noch zwei Tools um das VT100-Terminal im CP/M besser zu bedienen.
CSET.COM schaltet zwischen den beiden Character Sets um. Der erste
Parameter ist für G0 und der zweite Parameter für G1. Möglich sind US,
UK, DE, DE, DEC und SUP.
CSET US DE
lädt also das US Set nach G0 und DE nach G1.
Mit PSCS.COM kann sich dann der verfügbare Zeichenvorrad angezeigt
werden.
Den Quelltext gibt’s hier [1].
[1] https://github.com/Feinmechaniker/AVRCPM
Rene K. schrieb:> Wäre da noch eine Platine übrig? ?
Ja, sende mir mal eine PN mit deiner E-Mail.
Alle anderen Platinen habe ich heute, da nun alles ins Gehäuse paßt, in
die Post gegeben. Sie sollten also nächste Woche eintreffen.
Joe G. schrieb:> Rene K. schrieb:> Wäre da noch eine Platine übrig? ?>> Ja, sende mir mal eine PN mit deiner E-Mail.> Alle anderen Platinen habe ich heute, da nun alles ins Gehäuse paßt, in> die Post gegeben. Sie sollten also nächste Woche eintreffen.
Danke, habe dir eine PN geschickt ?
Ich bin gerade am Bestellen der BOM. Bei dir im GIT gibt es jetzt zwei
verschiedene Versionen der Part-List. Ich gehe davon aus das die 1.0
aktuell ist und nicht 1.2? Platine ist ja 1.0.
Der Reichelt Warenkorb ist auf die 1.0 ausgelegt? So mal fix drüber
geschaut... Ist da der Propeller schon dabei oder muss ich den Extern
organisieren?
Die Schaltung hat sich von der Version 1.0 auf die Version 1.2 nicht
geändert. Die Änderungen betreffen ausschließlich Das Layout und den
Bestückungsaufdruck (siehe Errata).
Es ist also günstig die BOM und die Partlist der Version 1.2 zu nutzen
bis auf C21 (100n), der ist in der Version 1.0 noch ein SMD 100n
Baugröße 0805. Speziell C17 und C18 (18p) sollten in 0603 für die V1.0
bestückt werden. Es ist sonst eine arge Fummelei.
Der Reichelt Warenkorb ist nicht vollständig (!) Ich habe zwar versucht
alles zu erfassen, aber eine Kontrolle ist besser. Ob man die IC’s
sockelt, muß zudem jeder selbst entscheiden. Ich hatte s im meinem
Muster getan, um bei Fehlern eingreifen zu können. Prinzipiell halte ich
es beim 8-Bit GPIO (PCF8574), RS232 Treiber (MAX3222) und dem 16-Bit
GPIO (MCP23017) für sinnvoll.
Weiterhin muss beim PCF8574 (8-Bit GPIO) darauf geachtet werden, welche
Version man mag. Der PCF8574 hat die Adresse 0x20 und der PCF8574A die
Adresse 0x38. Das muss bei den Einstellungen im Softwareteil des AVR
„config.inc“ beachtet werden. Default ist der PCF8574.
Der Propeller ist nicht mit im Reicheltkorb, den gibt es dort nicht.
Weiterhin fehlt dort die Fassung für die SD-Card (Würth 693063010911).
Ich freue mich über jede Ergänzung und Berichtigung.
Super, danke... Da setze ich mich heute Abend mal dran und Ergänze /
Berichtige die Liste.
An die SD-Card Fassung komme ich durch Vitamin B zu WE. Und kann hier
welche zum Selbstkostenpreis anbieten.
Platine kam heute wohlbehalten bei mir an. Mensch hätte ich gewusst das
du quasi "Um die Ecke" kommst, hätte man sich ja auch mal treffen können
:-D
P.s.: Ich habe nun den gesamten Thread nicht verfolgt (alle 100 Seiten).
Aber ist es nicht möglich die VT100 Terminal Abfrage nicht auch auf ein
Atmel der AtmegaX8 Reihe auszulagern? Die 4KB Ram dürften doch, rein
theoretisch, für ein 80x24 Terminal völlig ausreichend sein. Gut, das
VGA Timing müsste dann etwas "neben der Spezifikation" laufen. Aber
dürfte machbar sein.
Was sprach da für den Propeller?
Rene K. schrieb:> Mensch hätte ich gewusst das> du quasi "Um die Ecke" kommst, hätte man sich ja auch mal treffen können
Das können wir ja immer noch :-)
> Was sprach da für den Propeller?
Es gibt sogar eine Variante mit einem AVR als Terminal [1]. Es geht
jedoch arg eng mit dem Timing um und viel Luft ist für eine farbige
Darstellung auch nicht. Der Propeller hat deutlich mehr Geschwindigkeit
und außerdem läuft noch ein AY-3-8910/YM2149 mit.
[1] Beitrag "Re: CP/M auf ATmega88"
Joe G. schrieb:> Das können wir ja immer noch :-)
Sehr gerne :-)
Mir fällt gerade die nächste Frage ins Auge:
Sie dazu Bild 1. Der AtmegaXX8-PU oder auch P-PU läuft unter 3V3 doch
garnicht auf 20Mhz sondern laut DB bloß 0-10Mhz unter 2.7-5.5V und
0-20Mhz unter 4.5-5.5V.
Gibt es vom AtmegaXX8 auch ein Derivat welcher mit 20Mhz unter 3V3
spezifiziert ist?
Rene K. schrieb:> Gibt es vom AtmegaXX8 auch ein Derivat welcher mit 20Mhz unter 3V3> spezifiziert ist?
Nein, gibt es nicht. Bisher laufen aber alle von mir (und auch
anderen)eingesetzten IC's ohne Probleme. Damit sie ordentlich
anschwingen, ist das Fuse Bit auf "Full Swing Crystal" gestellt.
Hallo,
gestern endlich angefangen zu bauen, ich habe schon einige Fehler
gefunden und auch einige Verbesserungsvorschläge. Ich bin jetzt 3 Wochen
auf Reha... da finde sicherlich Zeit alles nieder zuschreiben (geht zu
Joe per Mail).
Mein Problem ist im Moment der SC16IS740, wo bekommt man das Teil
günstig her? (ich würde auch mehrere nehmen). Zu dem Quarz sag ich mal
nichts...
Gruß
Hans-Werner
Rene K. schrieb:> Super, danke... Da setze ich mich heute Abend mal dran und Ergänze /> Berichtige die Liste.>> An die SD-Card Fassung komme ich durch Vitamin B zu WE. Und kann hier> welche zum Selbstkostenpreis anbieten.
Hallo René,
hast Du schon die Liste ergänzen können? Sprich: welche Teile sind im
Reichelt Warenkorb nicht enthalten?
An der SD-Card Fassung hätte ich Interesse, sofern Du noch eine abtreten
möchtest.
Beste Grüße,
Mathias
P.S.: wieder einmal ein tolles Projekt von Joe G. mit einer sehr
sauberen Doku! Ich habe bereits den AX81b und den CP/M-Stick aufgebaut -
funktioniert beides klasse. Herzlichen Dank dafür!
Hallo,
habe meine Platine soweit aufgebaut. VT100 geht, i2cscan findet
die I2C Bauteile. Was mir beim Bestücken aufgefallen ist:
Thermal-Pads lassen sich schlecht löten.
Habe zwar kein Problem 0603 zu löten, aber es ist ja Platz für
z.B. 0805.
Den Quarz für den SI16... könnte man besser löten, wenn die Pads
größer wären (hallo Hans-Werner), oder gleich HC-49.
Ein Problem habe ich noch mit der RTC: im Reichelt Warenkorb
steht das Ding als PCF 8583T DIP8, aber T ist SMD. Also habe
das Chip erstmal auf einen 8er Dip-Sockel geprokelt.
Solange das Board extern versorgt wird, ist die Abweichung nur
minimal. Läuft die RTC auf der CR2032, ist die Abweichung einige
Minuten in Plus. Schon ein CPM Hardware-Reset bringt die RTC
einige Sekunden ins Plus.
Kann man den RTC-Treiber permanent laden?
Gruss
Peter
Vielen Dank für deine Hinweise! Die Beschaltung um den SI16.. stelle ich
auf „freundliche“ Bauelemente um. PCF8583T ist natürlich nicht korrekt,
auch wenn Reichelt DIP8 dazu schreibt. Hier muss der PCF8583P in den
Warenkorb.
Das Problem mit der Uhr kann ich bei mir nicht nachvollziehen. Die Uhr
läuft bei mir seit einem Monat korrekt (egal ob bei externer Versorgung
oder der CR2032) auch ein CP/M-Reset ändert die Uhrzeit nicht. Mal
sehen, was die anderen dazu sagen...
Hans-Werner vielen Dank für deine Anmerkungen und Korrekturen! Eine neue
Doku liegt nun unter Github. Die Schalterstellungen sollten jetzt auch
der Schaltung entsprechen und der VT100 Teil ist auch ergänzt.
Hallo Joe,
jetzt fehlt nur noch ein Gehäuse... hast du das schon in der Produktion?
:-)
Das kann nicht jeder produzieren, und würde mich interessieren.
Gruß
Hans-Werner
Hallo Joe,
mal ne Frage zum Trimmer C12 am PCF8583P. Ein Ende geht an Pin 1 und
das andere an 3,3V. Sollte das nicht an D1,D2 bzw. Pin8 gehen?
Wenn die 3,3V nicht da sind, hängt er ja in der Luft. Könnte ja mein
Problem sein.
Gruss
Peter
Habe jetzt mal den C12 an Pin8 gehängt,
jetzt läuft die RTC mit richtiger Uhrzeit
im Batterie Betrieb.
Die Änderung ist einfach durchzuführen:
C12 von 3,3V trennen und mit Pin8 verbinden.
@Joe
Es wundert mich, daß Du da kein Problem hast.
ps: melde mich für ein Gehäuse an.
Gruss
Peter
Peter Z. schrieb:> Die Änderung ist einfach durchzuführen:> C12 von 3,3V trennen und mit Pin8 verbinden.
Das ist ja ein dicker Hund ;-) Natürlich muss C12 an Pin8.
Offensichtlich läuft meine Uhr auch ohne C12 genau. Die Gehäusewünsche
sammle ich mal...
Hallo,
Hiobsbotschaften... das mit den UARTS SC16IS740 hat nicht geklappt, der
Lieferant kann nicht liefern aliexpress hat das Geld erstattet..?? Hab
es dann bei E... versucht..und bis jetzt nichts erhalten. Hat da einer
noch eine Quelle wo die Dinger auch bezahlbar sind?
@Joe soll da noch etwas mit dem Gehäuse kommen?
Gruß
Hans-Werner
Da das Projekt in Richtung Bausatz läuft, beschaffe ich die Bauelemente
in der Losgröße 10. Bei Mouser ist das IC für 2.47€ + Steuer verfügbar.
Ich würde einfach für dich (vielleicht noch weitere Interessenten)
mitbestellen. Auch das Gehäuse ist noch aktuell. Hier warte ich noch auf
die Rückkopplung der Betatester bzw. final auf das endgültige Angebot in
der Losgröße 10.
Hallo liebe (AVR)CP/M Freunde.
Ich werde mir die nächsten Wochen mal wieder ein AVR CP/M Stick
aufbauen.
Da mein Stand inzwischen 'etwas' veraltet ist, würde ich nach
erfolgreichem Aufbau dann den Stand von Martin flashen wollen:
https://www.mikrocontroller.net/attachment/379658/AVRCPM-SER-PAR.zip
(Danke für die tolle Beschreibung und fertiges HEX!)
Frage zum I2C Uart. Wäre so etwas verwendbar (ohne SW Anpassungen):
https://www.ebay.de/itm/SC16IS750-CJMCU-750-Single-UART-w-I2C-Bus-SPI-Interface-For-Industrial-Control/163595853069?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m1438.l2649
--
Ich habe mir dann noch mal den Stand des Artikels angeschaut.
Der ist - hmm.. leider inzwischen völlig veraltet - und eher verwirrend!
Gibt es da Bestrebungen, die älteren Optionen (z.B. Partitionen) auch
unter "Historische/Alte Optionen" zu stellen und den aktuellen Stand
evtl. auch nach oben, neu einzufügen? Ist finde es etwas 'blöd' wenn man
sich erst durch alle historischen Versionen liest, evtl. schon anfängt..
und erst danach feststellt, das ein Atmega88 oder 168 eben nicht mehr
ausreicht für die aktuelle Version, sondern ein Atmega328p der
'richtige' Chip ist.
Gleiches gilt für FAT16/SD-Karte und Disk-Images..
Peter
Hallo Peter,
den derzeit aktuellen Stand (incl. I2C und IO-Byte von Martin), findest
du hier [1]. Dort sind dann auch die Quellen für den AVR das CP/M sowie
schon übersetzte HEX-Files.
> Frage zum I2C Uart. Wäre so etwas verwendbar (ohne SW Anpassungen):
Der von dir verlinke EBAY-Artikel ist zum Softwarestand kompatibel.
Mit dem Artikel hast du Recht. Hier würde etwas Überarbeitung guttun.
Ich versuche es mal…
[1] https://github.com/Feinmechaniker/AVRCPM
Hallo Joe.
Ich habe mir mal erlaubt den Artikel etwas aufzubereiten.
Evtl. bietet sich nun die Aufnahme der jetzt aktuellen Hardwareversion
mit VT100 und I2C inkl. Gehäuse an?
Und ggf. die Software Rubrik müsste sicher auch aktualisiert werden ;-)
Peter
Peter S. schrieb:> ...> Frage zum I2C Uart. Wäre so etwas verwendbar (ohne SW Anpassungen):> Ebay-Artikel Nr. 163595853069> ...
Hallo Peter,
genau so ein Board habe ich mit meinem CP/M-Stick verwendet (Platine kam
damals von Dir). Wenn Du vom gleichen Anbieter noch 162722531579 mit
bestellst, kannst Du auch den parallelen Centronics-Port anbauen.
Braucht dann noch zwei 3.3->5V level converter für I2C und einen 5V
Stromversorgung.
PS: Ich habe mir dann noch eine 5V Powerbank dazu gebaut. Die
kommerziellen Powerbanks schalten leider ab, wenn nicht genügend Strom
gezogen wird. Deshalb habe ich mir eine selbst gebaut mit
USB-LiPo-Ladeplatine (z.B. 162764857644), einer Pollin 3.6V LiPo
Telefonzelle und 3.6V auf 5V Converter. Dann hat man ein portables CP/M
System, das man schnell an jedes Terminal anschließen kann. Das teuerste
war das 2.5 Zoll Aluminium Festplattengehäuse für die Powerbank.
Martin
Hallo Joe.
Ich habe nun viele Stunden Fehlersuche hinter mir, weil nach einiger
Zeit das System sich mit Dump 76 76 weghängte. Habe mit dram_waitstate
und dram_refresh Angaben in config.inc gespielt - bis ich heute auf die
Idee kam, mir mal dram-refresh.asm anzuschauen:
1
; ------------------- DRAM Refresh Interrupt --------------------
2
3
.cseg
4
5
INTERRUPT OC2Aaddr
6
reti ; only for SRAM
7
8
sbis P_RAS,ram_ras ;2
9
...
Das oberste reti gehört wohl erst einmal auskommentiert im Repo :-(
Und zukünftig eher als define in config.inc und entsprechend dann
darüber aktiviert, wenn SRAM definiert wurde.
;-)
Peter
Oh, sorry!
Da ich unter Github nur die Daten für die DRAM Version bearbeitet hatte,
ist mir das nicht aufgefallen bzw. ich hatte es nach dem damaligen
erfolgreichen Hardwaretest ganz vergessen in der config.inc zu
implementieren. :-(
Hans- w. S. schrieb:> wie sieht es mit Gehäuse aus?
Der letzte Betatester hatte mir erst letzte Woche alle
Wünsche/Probleme/Änderungen zukommen lassen, so dass ich nun erst dazu
komme auch diese Änderungen einfließen zu lassen. Letztlich kommt es
dann noch auf die Stückzahl an. Ein Einzelmuster ist derzeit wirklich
sehr teuer.
moin,
dann hatte ich wohl die pascal-version.
beim umstieg von cp/m auf den ersten pc hatte ich alles auf disk's im
ibm-format abgespeichert und eingelagert. leider haben einige davon die
lagerdauer nicht überstanden.
ich hatte damals mit einem freund einen universal formatierer für cp/m
gebaut. der konnte das disk-format für einzelne drives beliebig
anpassen. so haben wir damals das formatchaos etwas in den grief
bekommen.
moin,
Danke an alle.
@günter leider sind die sourcen der tp routinen beschädigt.
da hängen unvollständige textteile drinn.
ich habe hier noch die sourcen in asm vom "Z80 BASIC Ver 4.7c" von MS.
leider sind auch da fehler drinn, diese habe ich begradigt. zudem sind
einige befehle wie Cload und Csave nicht realisiert.
hat da noch jemand was vollständiges?
Weil ich in letzter Zeit viel mit meinem AVR-CP/M Stick gearbeitet habe
(GSX-80 Grafik mit Fortran und CBASIC), habe ich mir zwei Windows
Befehlszeilen-Skripte geschrieben, um ein Backup von den 8 MB
Festplattendateien zu erzeugen.
Dieses Backup erfolgt dateiweise, d.h. ich habe dann alle Einzeldateien
in einem Verzeichnisbaum unter Windows liegen.
Ein Skript kopiert mit Hilfe der CPMTOOLS alle Dateien in
User-Unterverzeichnisse und das andere Skript kopiert alles wieder
zurück in Image Dateien.
Damit kann ich jetzt bequem Einzeldateien unter Windows ansehen,
austauschen oder ändern und später wieder alles zurückspielen ohne
jedesmal manuell CPMTOOLS Befehle eingeben zu müssen.
Nur die SD-Karte muss ich natürlich noch umstecken.
Für das Zurückkopieren werden komplett neue Image Dateien angelegt,
wofür noch ein leeres Image als Vorlage benötigt wird.
Ausserdem CPMCP aus den CPMTOOLS und natürlich die passende DISKDEFS
Datei mit einer Definition für "avr8M".
Ist vielleicht auch für andere Nutzer interessant.
Martin
Hallo zusammen,
ich habe über die Tage mal einen Emulator auf Breadboard aufgebaut und
bin sowohl von der simplen Konstruktion als auch von der Performance mit
einem atmega328p begeistert.
Gar nicht so einfach, sich durch die 10-jährige Historie zu wühlen -
trotz der Bemühungen Eurerseits, die Sache immer wieder zusammen zu
fassen.
Ich habe vor über 30 Jahren auch so meine Erfahrungen mit CP/M machen
dürfen, erst mit einem Apple II + Z80-Karte, dann auf Epson QX-10 und
PX-4.
Letzterer ist mir vor einigen Wochen beim Aufräumen im Keller mal wieder
in die Hände gefallen und hat meine Neugierde wieder geweckt.
Das Ding läuft noch! Basic im Rom und Turbo-Pascal auf Mini-Kasette -
ewige Ladezeiten, aber es geht.
Dann fand ich ein tolles Stück Software für den ESP32 (www.fabgl.com -
siehe Examples). Es emuliert einen Altair8800 recht performant mit VGA
und Tastatur über PS/2. CP/M läuft super. Ich mag diesen
minimalistischen Ansatz.
Das hat mich dann auch hierher geführt. Toll finde ich die Versionen des
AVRCPM-Projektes ohne Propeller etc., weil mir bei letzterem schon der
Einsatz von Rechenpower zuviel ist. Da könnte man auch den ESP32
vorziehen.
Also erst einmal ein großes Kompliment an die Community - tolle Arbeit!
Leider ist es in diesem Threat inzwischen recht ruhig geworden, doch
hoffe ich dennoch auf ein wenig Unterstützung, da ich noch ein wenig mit
der Umgebung hadere.
Als Umgebung verwende ich das aktuelle Microchip Studio 7.0.2542. Wenn
ich damit die Sourcen (Version aus
https://www.mikrocontroller.net/svnbrowser/avr-cp-m/avrcpm/tags/3.5/) in
der Voreinstellung der Config.inc übersetze, findet der Linker zwei
Symbole nicht: adc_read8 und avr_read_vcc (beide aus virt_ports.asm -
Zeile 183 und 187).
Schalte ich den ADC-Support in der Config.inc aus, läuft alles und CP/M
startet.
Eine Suche nach diesen Symbolen in allen *.inc und *.asm bringt keinen
Treffer.
Auch wenn ich den ADC sicher nicht so schnell brauchen werde, wüsste ich
gerne, woran das liegt. Kennt einer die Antwort auf die Fragen
a) wo sind die beiden Symbole definiert
und
b) warum sind sie in meiner Umgebung nicht definiert
und
c) bzw. ist der Code für den ADC möglicherweise veraltet und nicht mehr
compilierbar?
Im Fall c) sollte man evtl. die Default-Einstellungen der Config.inc mal
überarbeiten, oder?
Gruß
Guido
Hallo Guido,
der erste Prototyp vom ADC-Code war nicht so doll. Es hatte aber auch
niemand Interesse daran. Deshalb hatte ich den Code nie ins SVN
eingecheckt.
Guido D. schrieb:> a) wo sind die beiden Symbole definiert
in adc.asm. Die Datei ist hier im Anhang:
Beitrag "Re: CP/M auf ATmega88"
Sie muß in avrcpm.asm included und im Makefile zu ASRC0 zugefügt werden.
Hier gibts auch eine ältere Version des Gesamtprogramms:
Beitrag "Re: CP/M auf ATmega88"> und> b) warum sind sie in meiner Umgebung nicht definiert
weil adc.asm fehlt.
> und> c) bzw. ist der Code für den ADC möglicherweise veraltet und nicht mehr> compilierbar?
Ich vermute mal, das er noch funktioniert.
> Im Fall c) sollte man evtl. die Default-Einstellungen der Config.inc mal> überarbeiten, oder?
Ja, das hatte ich wohl beim Entfernen von adc.asm vergessen.
Hallo Guido,
die letzte Version mit Unterstützung von RTC, GPIO, UART, LPT usw.
findest du hier [1] in der Version von AVR-Studio 7.
[1] https://github.com/Feinmechaniker/AVRCPM
Guido D. schrieb:> Das hat mich dann auch hierher geführt. Toll finde ich die Versionen des> AVRCPM-Projektes ohne Propeller etc., weil mir bei letzterem schon der> Einsatz von Rechenpower zuviel ist.
Der Propeller dient nur als VGA-Terminal. Da gibt es auch ein separates
Projekt dazu:
Beitrag "VT100-Terminal (VGA+PS2)"> Da könnte man auch den ESP32> vorziehen.
Den gab es vor zehn Jahren noch nicht...
ähmm..also meine Frage wurde hier sicher schon tausendfach
gestellt..daher reicht mir eine kurze Zusammenfassung als Antwort aus,
wollte den Threat nicht kapern..
Wenn hier einige nach Z80 Projekten Fragen, wird immer die Sinnfrage
gestellt...und warum man sich heute noch damit beschäftigen sollte etc.
Wieso ist ein AVR CP/M Projekt offenbar etwas völlig anderes:-)
Wenn ich das hier so sehe, würde ich doch besser gleich einen Z80
verwenden
Wie gesagt..hatte mir jetzt die restlichen 10 Seiten nicht alle
durchgelesen...
Joe G. schrieb:> Die kurze Antwort lautet:> Weil es möglich ist, mit 2 IC’s (AVR+DRAM) und einer SD-Card ein> komplettes CP/M System zu realisieren.
Ähem... und das ist ein ausreichender Grund?
Ich sehe das ganz anders:
1. Es ist für einen Programmierer lehrreich, einen Z80 in Assembler
programmieren zu lernen, weil der Z80 einen recht guten und
überschaubaren Befehlssatz hat und man es deshalb leicht hat, die für
Assembler nötige "Denke" zu erlernen.
2. Es ist für den Hardwerker lehrreich, mit einem Z80 ein funktionables
System zu konstruieren, weil man damit Digitalelektronik recht gut
lernen und üben kann.
3. Es ist für den Systemarchitekten lehrreich, CP/M zu begreifen, weil
man damit lernen kann, wie man ein durchaus leistungsfähiges DOS mit nur
wenigen kByte an Gesamtumfang konstruieren kann.
4. Natürlich könnte man auch einen ZX-Spectrum emuliert bauen, Frank hat
das ja vorgemacht, aber das läuft dann zu fast 100% auf das Spielen mit
den damaligen Spielprogrammen hinaus - und nicht auf die genannten
lehrreichen Ziele. Kann man machen, ist aber eine völlig andere Kiste.
So.
In beiden Fällen (AVR oder echter Z80) ist das damit erzeugte System für
die heutige Praxis deutlich zu klein. Mit Wordstar (oder beim Spectrum
mit TLW) schreibt man heutzutage keine Briefe an die Omi mehr. Punkt.
Was bleibt, ist zum einen der damit erzielbare Lerneffekt. Den sehe ich
allerdings bei einem interpretierten System wie per AVR oder ESP32 nicht
gegeben, weil man dort ja doch wieder mehr mit dem interpretierenen
System als mit dem eigentlichen Z80 bzw. CP/M zu tun hat.
Was zum anderen bleibt, ist die Möglichkeit, einen kleinen Rechner zu
haben, der binnen 2 Sekunden bootet, wo man ein paar digitale und
analoge Ein- und Ausgänge haben kann, für die man sich per Turbopascal
mal eben irgendwelche kleinen Testprogramme schreiben kann und wo man
damit irgend etwas auf dem Basteltisch tun kann, einschließlich
Langzeit-Logging auf Disk - und das alles, ohne den PC benutzen zu
müssen.
Ich würde das ganze Thema anders sehen, wenn man die Idee des CP/M
weiter entwickeln würde, das Ganze dann tatsächlich auf einen passenden
32 bittigen µC portieren würde und damit ein kleines, aber benutzbares
System abseits von Windows, Linux, QNX und Ähnlichem schaffen würde.
So etwas wäre eine bessere Bastel-Idee.
W.S.
W.S. schrieb:> 4. Natürlich könnte man auch einen ZX-Spectrum emuliert bauen, Frank hat> das ja vorgemacht, aber das läuft dann zu fast 100% auf das Spielen mit> den damaligen Spielprogrammen hinaus - und nicht auf die genannten> lehrreichen Ziele. Kann man machen, ist aber eine völlig andere Kiste.
gegen Spiele-Emulation ist auch nichts einzuwenden, weil eine Soft-Emu
nicht dasselbe ist.
Was jetzt die 'lehrreichen Ziele' anbelangt, kann man genauso
argumentieren - nicht notwendig, da mittels PC-Software-emu sowieso
alles möglich ist?!
Und damit sind die lehrreichen Ziele genauso obsolet, Hardware-Nachbau
sinnlos so gesehen.
Wollte mal auf diese Projekt aufmerksam machen:
http://spritesmods.com/?art=avrcpm
Interessantes Projekt, leider schweigen sie sich darüber aus wie der
Einbau in das Gameboy-Gehäuse aussieht - hier spart man an Fotos, etc.
... oder eben doch nur ein Fake.
Das ist leider das Defizit dieser ganzen Projekte - die Macher gehen von
sich aus.
Robert K. schrieb:> Was jetzt die 'lehrreichen Ziele' anbelangt, kann man genauso> argumentieren - nicht notwendig, da mittels PC-Software-emu sowieso> alles möglich ist?!> Und damit sind die lehrreichen Ziele genauso obsolet
OK, wer sich als Verbraucher sieht, der benötigt keine Kenntnisse von
Hardwaredesign und Programmierung und Betriebssystemen und
Dateisystemen. Der muß bloß wissen, wie er/sie über das Display des
Mobiltelefones wischen muß, um dann auf das gewünschte Icon zu tippen.
W.S.
W.S. schrieb:> OK, wer sich als Verbraucher sieht, der benötigt keine Kenntnisse von> Hardwaredesign und Programmierung und Betriebssystemen und> Dateisystemen. Der muß bloß wissen, wie er/sie über das Display des> Mobiltelefones wischen muß, um dann auf das gewünschte Icon zu tippen.>> W.S.
darum geht es doch gar nicht!
Wenn ich schon ein Projekt ins Netz stelle, dann sollte das für jeden
Interessierten nachbaubar sein. Dieses Ziel ist schon mal verfehlt.
Für Programmierung, Hardwaredesign, Betriebssysteme, etc. kann man auch
Bücher kaufen und lesen bzw. im Selbstkurs lernen oder an der Uni das
entsprechende Fach studieren.
Ein Projekt muß aber einen anderen Anspruch haben - und der ist aufgrund
der Arroganz definitiv nicht erfüllt!
Joe G. schrieb:> Mußt du nicht, es reicht:> Beitrag "CP/M auf ATmega88"> zu lesen ;-)
ah okay, Du leidest offenbar an Alzheimer - bitte nicht falsche Zitate
unterschieben :-)
Originalzitat ist von Peter Sieg:
Peter Sieg schrieb:> Hi.>> Wollte mal auf diese Projekt aufmerksam machen:> http://spritesmods.com/?art=avrcpm
Ich habe das Zitat von Peter dann ebenfalls nochmal verwendet, aber
irgendwas ist mit der 'Kommentierfunktion' hier schiefgelaufen (sehe
ich gerade) ... leider kann man das nicht mehr ändern, wenn anschließend
jemand anders postet - Fehler bzw. Websiteproblem, bei anderen Foren
geht sowas.
Robert K. schrieb:> darum geht es doch gar nicht!
Oh doch. Es geht um das Können und das Selbstverständnis. Da ist ein
großer Unteschied zwischen dem Elektroniker, der etwas machen will oder
soll und deshalb Fachkenntnisse braucht - und dem Verbraucher, der
lediglich auf ergonomische benutzbarkeit achtet, egal ob da drinnen nun
ein Mikrocontroller oder ein grünes Marsmännchen werkelt.
> Wenn ich schon ein Projekt ins Netz stelle, dann sollte das für jeden> Interessierten nachbaubar sein. Dieses Ziel ist schon mal verfehlt.
Das kommt sowohl auf die Güte der hoffentlich vorhandenen Dokumentation
als auch auf die Ausführung des Projektes an. Wäre im Einzelfall zu
prüfen - mal abgesehen davon, daß nicht jeder elektronik-affin ist. Hier
lese ich viel zu häufig sowas: "ich will was ganz dolles bauen aber ich
verstehe von Elektronik garnichts..."
> Für Programmierung, Hardwaredesign, Betriebssysteme, etc. kann man auch> Bücher kaufen
Ja, in diesem Falle den Lampe-Jorke-Wengel, aber bloß kaufen nützt
nichts, man muß es auch selbst praktizieren, damit man es tatsächlich
lernt.
W.S.
W.S. schrieb:> Natürlich könnte man auch einen ZX-Spectrum emuliert bauen, Frank hat> das ja vorgemacht, aber das läuft dann zu fast 100% auf das Spielen mit> den damaligen Spielprogrammen hinaus - und nicht auf die genannten> lehrreichen Ziele.
Es gibt Z80-Cross-Assembler, mit denen man TAP-files für den Spectrum
erzeugen kann.
Hier auch ein Online-Z80-Assemler: https://clrhome.org/asm/
Dieser kann ebenso direkt ZX Spectrum TAP-Files erzeugen, welche man mit
STECCY direkt per
1
LOAD "" CODE
2
RANDOMIZE USR address
ausführen kann. Es muss ja nicht immer ein Spiel sein.
Ich habe früher mit dem ZX Spectrum Assembler gelernt und kann nur
bestätigen, dass Z80-Code ideal ist, um Assembler zu lernen.
Ich habe in den letzten Wochen auch mal z88dk als
Cross-C-Compiler-Umgebung ausprobiert - läuft mit sccz80 (original
z88dk's compiler) oder auch sdcc. Hier kann man ebenso direkt
ZX-Spectrum-TAP files erzeugen, die auf dem STECCY reibungslos
laufen.
Zuerst mal mein Wunsch:
Dieses Jahr 2021 möge uns allen ein gutes und gesundes Jahr werden!
Frank M. schrieb:> Es gibt Z80-Cross-Assembler, mit denen man TAP-files für den Spectrum> erzeugen kann.
Ja, weiß ich. Aber man muß es tun wollen - und da sehe ich bei
Nachbauern doch weitaus eher das Verlangen, alte Spiele laufen zu
lassen.
Ich kann Assembler, du auch, einige andere hier auch (noch) - aber ich
lese gerade hier in diesem Forum immer wieder geradezu militante
Beiträge, die jegliche Assembler-Kenntnisse als komplett obsolet abtun.
W.S.
W.S. schrieb:> Zuerst mal mein Wunsch:> Dieses Jahr 2021 möge uns allen ein gutes und gesundes Jahr werden!
dem Neujahrswunsch schließe ich mich an :-)
W.S. schrieb:> Ja, weiß ich. Aber man muß es tun wollen - und da sehe ich bei> Nachbauern doch weitaus eher das Verlangen, alte Spiele laufen zu> lassen.
In der Beziehung ist Deine Haltung leider falsch - daran ist nichts
verkehrt sich der reinen Anwendung zu erfreuen oder eben nur für Spiele
zu nutzen?
Die Original-Retro-Computer sind zu teuer und Software-Emu auf einen PC
ist nur ein schwacher Ersatz.
Warum also nicht - genau dasselbe hast Du in etlichen anderen Bereichen
doch auch?
W.S. schrieb:> Ich kann Assembler, du auch, einige andere hier auch (noch) - aber ich> lese gerade hier in diesem Forum immer wieder geradezu militante> Beiträge, die jegliche Assembler-Kenntnisse als komplett obsolet abtun.
Tja, das ist leider so und Du darfst davon ausgehen, daß Beiträge dieser
Art noch zunehmen werden.
W.S. schrieb:> Oh doch. Es geht um das Können und das Selbstverständnis. Da ist ein> großer Unteschied zwischen dem Elektroniker, der etwas machen will oder> soll und deshalb Fachkenntnisse braucht - und dem Verbraucher, der> lediglich auf ergonomische benutzbarkeit achtet, egal ob da drinnen nun> ein Mikrocontroller oder ein grünes Marsmännchen werkelt.
learning by doing - vielleicht animiert es ja den ein oder anderen
Anwender oder Verbraucher sich näher damit zu beschäftigen.
Nur von vornherein den Anspruch zu erheben, daß sich nur die technische
Elite damit beschäftigen darf, ist der falsche Weg.
>> Wenn ich schon ein Projekt ins Netz stelle, dann sollte das für jeden>> Interessierten nachbaubar sein. Dieses Ziel ist schon mal verfehlt.>> Das kommt sowohl auf die Güte der hoffentlich vorhandenen Dokumentation> als auch auf die Ausführung des Projektes an. Wäre im Einzelfall zu> prüfen - mal abgesehen davon, daß nicht jeder elektronik-affin ist.
Richtig, und die Anwender- bzw. Verbraucherseite wird von den Machern
der Projekte völlig vergessen.
Somit sind viele gute Projekte leider völlig obsolet.
> Hier> lese ich viel zu häufig sowas: "ich will was ganz dolles bauen aber ich> verstehe von Elektronik garnichts..."
ist doch okay - aber dann muß man dem Verbraucher auch sagen können:
hier, Link xy kannst Du fertig kaufen oder Link yz kannst Du basteln,
wenn Du löten kannst.
Und beides kann man eben nicht sagen, weil die Links nicht existieren
bzw. die ganze Doku saumäßig schlecht ist.
Sowas ist dann leider sehr schade und Dialog mit dem Projektbetreiber
hat leider auch wenig Sinn, weil der u.a. Deine Einstellung hat und auf
einem anderen Level schwebt.
>> Für Programmierung, Hardwaredesign, Betriebssysteme, etc. kann man auch>> Bücher kaufen>> Ja, in diesem Falle den Lampe-Jorke-Wengel, aber bloß kaufen nützt> nichts, man muß es auch selbst praktizieren, damit man es tatsächlich> lernt.
Reparierst Du Dein Auto selbst, wenn es z.B. einen Getriebeschaden hat?
Baust Du Dein Haus eigenhändig?
Muß man das könnnen? ... in einer arbeitsteiligen Gesellschaft nicht
mehr!
Du kannst Dir auch Wissen aneignen ohne es zu praktizieren - ist
manchmal auch sinnvoller, oder findest Du jeden Job/Tätigkeit toll?
So manchen Job bzw. Tätigkeit möchte ich nicht unbedingt machen.
Ich möchte nicht unhöflich sein, dennoch darum bitten Eure Diskussion
anderweitig fortzuführen. Etwa 1900 Beiträge lang, war die Diskussion
auf „CP/M auf AVR“ ausgerichtet. Ich würde mich freuen, wenn das
zukünftig auch so bleibt.
Danke!
Robert K. schrieb:> In der Beziehung ist Deine Haltung leider falsch
Hä?
Hab ich etwa Franks Projekt geschmäht? Nein, natürlich nicht. Aber ein
ZX-Spectrum-Emulator per Cortex-M ist rein sachlich etwas ganz anderes
als ein CP/M auf ATmega88. Der Spectrum reizt zum Nachbauen eben WEGEN
der Spiele, der ATmega nicht. Unterscheide mal die unterschiedlichen
Kisten.
Robert K. schrieb:> Die Original-Retro-Computer sind zu teuer und Software-Emu auf einen PC> ist nur ein schwacher Ersatz.
Rede nur weiter, dann reizt mich das so, daß ich mal versuche, so einen
Universal-Retro-Z80-Computer tatsächlich zu konzipieren - mit einem
richtigen Z80. Sowas wäre durchaus mal ein reizvolles Projekt. Beides
einzeln hab ich schon, kenne ich schon, hab ich schon selber entwickelt
und eines davon war vor Urzeiten auch mal in ner Gazette abgedruckt.
Robert K. schrieb:> Nur von vornherein den Anspruch zu erheben, daß sich nur die technische> Elite damit beschäftigen darf, ist der falsche Weg.
Wir alle haben mal angefangen, barfuß das Laufen zu lernen. Gilt auch
hier und bedarf der eigenen Bemühungen, es zu verstehen. Wenn man es
dann kann, dann darf man sich auch "technische Elite" nennen - wenn man
derart eitel ist.
Aber hier ging es vorrangig um die Frage, wozu - also zu welchem
letztendlichen Zwecke - die hier besprochene Emulation eines Z80 und
CP/M auf einem Atmel-IC gedacht ist. Und die Antwort war: weil es geht
und nur 2 Schaltkreise braucht. Das ist mir ein bissel arg dünn. Dinge
zu tun, nur weil es möglich ist, läßt mich an die Atombombe denken. Ich
halte das für eine falsche, weil zu unbedachte Sinneshaltung.
W.S.
Joe G. schrieb:> Ich möchte nicht unhöflich sein, dennoch darum bitten Eure Diskussion> anderweitig fortzuführen. Etwa 1900 Beiträge lang, war die Diskussion> auf „CP/M auf AVR“ ausgerichtet. Ich würde mich freuen, wenn das> zukünftig auch so bleibt.> Danke!
kommt von den anderen denn noch was Neues? Kann ich nicht erkennen.
Richtig, CP/M auf AVR ... auch für CP/M gibt es Spiele.
Fakt ist auch, daß das Projekt wohl als Einbau in den Gameboy gedacht
war, wenn man den Link von Peter weiter verfolgt wo das gleich auf der
Eingangseite abgebildet wird ... nur da hört es dann auch schon auf -
insofern bleiben leider Fragen offen.
W.S. schrieb:> Hä?> Hab ich etwa Franks Projekt geschmäht? Nein, natürlich nicht. Aber ein> ZX-Spectrum-Emulator per Cortex-M ist rein sachlich etwas ganz anderes> als ein CP/M auf ATmega88. Der Spectrum reizt zum Nachbauen eben WEGEN> der Spiele, der ATmega nicht. Unterscheide mal die unterschiedlichen> Kisten.
Es geht ja nicht allein um Spiele - das ist nur eine Anwendung; bei CP/M
weniger als bei Spectrum, aber auch das geht.
Fakt ist leider, daß ein Spectrum Nachbau etwas aufwendiger wird als
CP/M auf Atmega mit ein paar Bauteilen - das geht wesentlich schneller.
Wer jetzt Spielefreak ist und mehr braucht, kann ja anfangen selbst
welche nach zu programmieren auf CP/M ... und damit lernt er dann auch
was Unnötiges.
> Rede nur weiter, dann reizt mich das so, daß ich mal versuche, so einen> Universal-Retro-Z80-Computer tatsächlich zu konzipieren - mit einem> richtigen Z80.
gibt es doch schon alles, nur meistens viel zu teuer.
> Sowas wäre durchaus mal ein reizvolles Projekt. Beides> einzeln hab ich schon, kenne ich schon, hab ich schon selber entwickelt> und eines davon war vor Urzeiten auch mal in ner Gazette abgedruckt.
Hast Du noch den Schaltplan?
> Wir alle haben mal angefangen, barfuß das Laufen zu lernen. Gilt auch> hier und bedarf der eigenen Bemühungen, es zu verstehen. Wenn man es> dann kann, dann darf man sich auch "technische Elite" nennen - wenn man> derart eitel ist.
take it easy - das Hauptproblem ist, daß bei vielen das Interesse auch
abgewürgt wird wegen Kommerz, wegen zuviel Aufwand, usw.
> Aber hier ging es vorrangig um die Frage, wozu - also zu welchem> letztendlichen Zwecke - die hier besprochene Emulation eines Z80 und> CP/M auf einem Atmel-IC gedacht ist. Und die Antwort war: weil es geht> und nur 2 Schaltkreise braucht. Das ist mir ein bissel arg dünn.
und genau das ist die richtige Antwort - sehr wenig Aufwand, geht sogar
auf Lochraster, kein Platinen ätzen & sonstiger Kommerz notwendig.
> Dinge> zu tun, nur weil es möglich ist, läßt mich an die Atombombe denken. Ich> halte das für eine falsche, weil zu unbedachte Sinneshaltung.
das hast Du nun wirklich überall - z.B. 80% aller Sportarten sind
unsinnig und passiver Sport sogar schädlich wegen Bewegungsmangel ... es
wird aber gemacht aus Spaß & Amüsement.
Nach dieser doch eher weltanschaulichen Diskussion, noch einmal was
recht bodenständiges:
In allen Schaltungsentwürfen zu AVRCPM ist immer ein ISCP-Anschluss
vorhanden. Gleichzeitig ist der Reset über 100nF gegen Masse gepuffert.
Bei meinen Billig-China-Adaptern vom Typ USBASP hat das zur Folge, dass
der Reset noch nicht wieder zurückgesetzt wurde, da fängt AVRDude schon
an zu programmieren, was natürlich fehl schlägt.
Die Dokumentation von AVR sagt nur aus, dass der Kondensator Sinn macht,
wenn es bzgl. Störungen recht rauh zugeht, aber bei DEBUGwire nicht
Verwendung finden darf. Ich deutete das als Hinweis auf besagtes Problem
mit meinen USBASPs und habe ihn probehalber entfernt - und schon spielt
AVRDude mit.
Um beidem gerecht zu werden, habe ich den Kondensator nun gejumpert.
Ohne eine neue weltanschauliche Diskussion lostreten zu wollen bzgl.
Direktkauf in China und ob Firma R*, die hier gerne referenziert wird,
keine Apotheke ist und ob die Finanzierung deutscher Zwischenhändler
wirklich eine Sache von Hobbyisten sein sollte, meine Frage an die
Gemeinde:
Welche ISP-Programmer verwenden denn die Väter des Projektes - oder
arbeitet Ihr nur noch mit Bootloadern?
Und nun doch noch ein paar Sätze zu vorgenannter Diskussion:
Es gefällt, was den Beteiligten Spaß macht. Die Sinnfrage stellt sich
vlt. in der Kirche, beim Umweltschutz oder bei kommerziellen Projekten.
Wer keinen Sinn in einem Vorschlag sieht, braucht ihn doch nicht
anzunehmen. Deshalb muss man den anderen den Spaß doch nicht vermiesen,
oder?
Gruß
Guido
Guido D. schrieb:> Bei meinen Billig-China-Adaptern vom Typ USBASP hat das zur Folge, dass> der Reset noch nicht wieder zurückgesetzt wurde, da fängt AVRDude schon> an zu programmieren, was natürlich fehl schlägt.
Das hat als Aussage keinen rechten Sinn: die ISP-Programmierung erfolgt
während eines aktiven Resets.
Einzige Erklärung wäre, dass der Treiber in deinem Billigadapter zu
schwachbrüstig ist und den C nicht rechtzeitig genug entladen hat, bevor
die Programmierung startet. Aber eigentlich wird die
Initialisierungssequenz einige Male wiederholt. Insofern würde ich ein
anderes Problem vermuten.
Robert K. schrieb:> Hast Du noch den Schaltplan?
Ja, irgendwo tief in der Bastelkiste schmort auch noch die ganze
Zeitschrift. Aber das war alles mit BE der 80er Jahre gemacht: TTL, 2K
RAM usw. Ein heutiger Ansatz sähe ganz anders aus.
W.S.
W.S. schrieb:> Ja, irgendwo tief in der Bastelkiste schmort auch noch die ganze> Zeitschrift. Aber das war alles mit BE der 80er Jahre gemacht: TTL, 2K> RAM usw. Ein heutiger Ansatz sähe ganz anders aus.>> W.S.
Nicht schlecht ... ist schon klar, heute sind die Möglichkeiten besser.
Das Projekt, das Peter gefunden hat, ist ja nicht schlecht - nur leider
geht vieles unter und das ist wirklich schade gerade wegen des minimalen
Bauteil-Aufwands.
Na ja, es gibt noch andere Projekte mit AVR - die sind etwas aufwändiger
und dafür dann besser durchdacht.
Hallo,
ich habe mir jetzt in den Sommerferien den Aeternum vorgenommen (Platine
V1.0, Doku V1.2 aus dem Repo). Ein paar Kleinigkeiten neben den
bekannten Errata sind mir noch aufgefallen (R7 wird nirgends
beschrieben, die Fixes von V1.3 sind noch nicht in den Layouts, einige
Bilder für den Bestückungsplatz fehlen). Aber bisher sieht es gut aus
(VT100 fehlt noch).
Hat sich jemand schon die Mühe gemacht, ein Gehäuse per 3D-Druck zu
entwerfen?
Besten Gruß
Marcel
Super, wenn das Projekt noch Freunde findet :-)
R7 kann unbestückt bleiben und war nur zur Lastanpassung vorgesehen.
Ich hatte die Version 1.3 selber nicht mehr aufgebaut, bin jedoch an
Aufbauberichten interessiert um sie einzupflegen.
Ein Gehäuse hatte ich nur in Alu entworfen und realisiert. Da die
CAD-Daten vorliegen, kann es sicherlich auch in 3D-Druck überführt
werden.
Gruß Jörg
Hallo Jörg,
na klar - ich bin in den letzten Monaten (Jahren?) allerdings wie
Hans-Werner etwas mehr beim NKC-Projekt (NDR Klein Computer) unterwegs
gewesen - da gibts immer wieder neue Platinen - zuletzt auch 8080 und
6502-CPU :-)
Gehäuse - muss mir mal die DXF-Dateien ansehen :-)
Da scheint aber die Datei für "vorne" zu fehlen. Würden die Frontblenden
auch auf ein Standardgehäuse passen?
Gruß
Marcel
Ich habe mal die Daten für die Front- und Rückplatte angehangen. Die
Seitenteile sind aus Alu-Strangprofil wo die Boden- und Deckplatte
eingeschoben werden. Tatsächlich hatte ich die Gehäusemaße genau nach
der Leiterplattengröße ausgelegt, ein Standardgehäuse wird wohl nicht
passen :-(
Hi,
so, läuft alles prima! Jetzt fehlt nur noch der VT100 Teil.
Ein paar Fragen (ist alles schon wieder so lange her...)
- kriegt man auf der RS233 auch mehr als 9k6 hin? FÜr die Stamp hatte
Leo doch mal den STAT-Befehl um "schnelle" Varianten erweitert?
- Doku zu ZSDOS habe ich gefunden - aber gibts auch noch was spezielles
für den Aeternum? So als Nachschlagewerk wie bei der Z180 Stamp?
Gruß
Marcel
dl1ekm schrieb:> - kriegt man auf der RS233 auch mehr als 9k6 hin?
Ja, bekommt man. Im Anhang mal einige Tools von Martin, Leo C. und mir
um die RS232, RTC und VT100 zu bedienen. Ein Turbo Pascal Demo für die
BDOS Aufrufe muß ich mal suchen, ist schon wieder etwas her, dass ich
sowas programmiert habe. Die Soundausgabe auf dem Propeller ist noch
nicht implementiert. Ich habe zwar ein Spin-Code, der den AY3891X /
YM2149F Chip emuliert und auf das Audiointerface ausgibt, doch dazu
müßte noch ein Befehlssatz im VT100 Protokoll implementiert werden.
So - auch VT100 geht! Tolles Projekt!
Gerade in der Anbindung von "echter" Hardware sehe ich deutliche
Vorteile gegenüber anderen Emulationen z.B. auf dem ESP32 - auch wenn
die HW langsam in die Jahre gekommen ist :-)
Mir scheint es, dass das Projekt so bei 90% steht? Die Implementierung
des Soundchips auf dem Propeller finde ich toll - "müsste man mal fertig
machen" :-). Auch denke ich, dass eine erweitere Doku ähnlich dem
STAMP-Projekt das Potential der Lösung deutlich stärker zeigen würde.
Aber vielleicht kriegen wir das ja als Community noch gewuppt.
Zum Thema RS232 Speed: Ich schau mir die samples mal an. Meine Idee war
nur, daran direkt mein VT420 Terminal anzuschließen, und da wären 115200
besser als 9600 :-) Bei dem CPM für die Z180-Stamp hatte Leo dazu ich
glaube den STAT Befehl verwendet und einige langsame Baudraten dann auf
der AVR-Seite mit Highspeed versorgt.
Mein kleiner Beitrag: Im Rahmen des Aufbaus sind mir in der Anleitung
noch folgende Unklarheiten in der Doku aufgefallen:
- Die Jumper für MODE 2 (6er) sind spiegelverkehrt dargestellt - sowohl
in der Anleitung als auch im Anhang. Alle anderen Darstellungen sind
dagegen korrekt.
- Propeller: Es wäre gut, wenn man ERST die Bauteile für die Reset-Logik
aufbaut und DANN erst den Propeller / Speaker. Denn so konnte ich den
SMD BC817 kaum noch einlöten.
- Ein Hinweis zu R7 (optional) wäre gut
- Seite 15: Fehler bei den Widerständen. R16+R17 sind 150 Ohm, nicht R18
und R17
- Ein Tipp zur Ausrichtung des I2C Pegelwandler-IC wäre schön, da nichts
auf der Platine erkennbar ist
- Die Bestückung von C20 ist nicht in der Anleitung
- Die Bestückung von C21 fehlt
- JP1 wird nicht erwähnt
Besten Dank für das Projekt!
Marcel
Vielen Dank für die zahlreichen Anmerkungen! Ich werde sie nach meinen
Urlaub einpflegen.
Da die Änderung der Baudrate bei CP/M 2.2 nicht so elegant wie bei CP/M
3.0 gelöst ist, außerdem die Kommunikation eigentlich über I2C to
seriell läuft, gibt es ja das kleine Tool, welches ich beigefügt habe.
Wie schnell der I2C/Seriell Chip ist, und ob er 115K kann, mußt du mal
dem Datenblatt entnehmen.
Ja, eine erweiterte Doku ist schon wünschenswert – vielleicht findet
sich ja noch ein Mitstreiter.
hat schon mal jemand versucht, das AVR CP/M mit einem solchen MicroSD
Cardreader zu betreiben? Dieser ist ja mit Pegelwandlern ausgestattet,
so dass die ganze Schaltung mit 5V gespeist werden kann. Hierzu habe ich
eine vorhandene Micro SDHC Karte mit FAT16 formatiert und die
Imagedateien darauf kopiert. Dann habe ich diese MicroSD Karte zunächst
in einen MMC/MicroSD Adapter gesteckt und mit dem vorhandenen CP/M Stick
(Hardware Variante 3) gebootet, was problemlos funktioniert hat.
Wenn ich nun aber den Cardreader statt des MMC Slots am SPI des
ATmega328P bei Vcc=5V betreibe, lande ich nach dem RAM Test in einer
Endlosschleife mit Bootversuchen von der SDHC Karte. Hat jemand eine
Idee woran das liegen könnte?
Hallo Thomas,
klar - und das funkt ganz hervorragend.
Auf dem Foto ist eine 5V-Schaltung aufgebaut. Mit Uhr und GPIO.
Ich weiß nicht, welche RAMs Du verwendest, aber meine KM44C256CP-7
kommen gut mit den 5 Volt klar. Vieleicht zieht aber irgend etwas zu
viel Strom?
Gruß
Guido
Vermutlich hast Du recht. Ich hatte zur Bestückung des ursprünglichen
CP/M Sticks Siemens RAMs bestellt, die bei 3,3V nicht funktionierten. Um
sie trotzdem zu nutzen, habe ich ein ganz minimalistisches Redesign zum
Betrieb an 5V erstellt mit den beschriebenen Bootproblemen an dem
"Arduino" MicroSD Adapter. Um das Problem zu lösen habe ich die MicroSD
Karte u. a. über einfache Spannungsteiler zur 5V zu 3,3V Pegelanpassung
der SPI Signale angeschlossen. Das hat perfekt funktioniert, so dass ich
auf die Schnelle einen eigenen Adapter gebaut habe, der sogar noch etwas
kleiner als das Kaufteil ist.
- Thomas
Leo C. schrieb:> Nils E. schrieb:>> Gibt es die kompletten Sourcen noch irgendwo?> https://github.com/Feinmechaniker/AVRCPM> https://cloudbase.mooo.com/cgit/avrcpm/
Auf github ist ja nur die neueste Version v3.5 R241M als avrcpm.hex in
/avr
und auf der 2ten URL sind leider nur Sourcen (fuer die ich keine
Umgebung zum compilieren habe).
Leider habe ich mit der v3.5 R241M oefters folgende Fehlermeldung:
Z V A =00 BC =00FF DE =00FF HL =E3EF SP=E3A9 PC=5D8C 76 76 76
a'=00 bc'=0000 de'=0000 hl'=0000 IX=0000 IY=0000 I=00 CPU halted!
Ich hatte meinen AVR-CPM-STick HW v3.0 von v2.3r186 auf v3.5r241M
upgedated.
Im Internet fand ich noch eine v3.2r155 bei der der Fehler sehr selten
vorkommt: https://hc-ddr.hucki.net/wiki/doku.php/cpm/avrcpm
petersieg hatte am 07.12.2019 dazu eine Idee hier im Thread
Beitrag "Re: CP/M auf ATmega88"
Gibt es evtl. ein avrcpm.hex der v3.5r0 - denn die wurde mir in einem
anderen Forum als stabil gemeldet? Oder gibt es eine andere bevorzugte
Firmware fuer die HW v3.0?
Auf der Wiki-Seite zum AVR CPM fehlt meiner Ansicht nach auch der
Verweis auf die cpmtools diskdefs fuer das 8MB Laufwerk CPMDSK_D.IMG
# SIMH AltairZ80 Harddisk # AVR CP/M
diskdef avr8m
seclen 128
tracks 2048
sectrk 32
blocksize 4096
maxdir 1024
skew 0
boottrk 6
os 2.2
end
Aktuell kann man da nur die diskdefs fuer das 256K Floppy-Format (Drive
A:-C:) lesen:
# AVR CP/M
diskdef avrcpm
seclen 128
tracks 77
sectrk 26
blocksize 1024
maxdir 64
skew 1
boottrk 2
os p2dos
end
Auch diese Angabe war dankenwerterweise auf
https://hc-ddr.hucki.net/wiki/doku.php/cpm/avrcpm
Guido L. schrieb:> Auf github ist ja nur die neueste Version v3.5 R241M als avrcpm.hex
Diese Version ist für einen statischen RAM compiliert. Wenn du einen
dynamischen RAM (wie die ursprüngliche Version) verwendest, dann mußt du
den Refresh wieder einschalten und die Quellen noch compilieren.
In der Datei dram-refresh.asm mußt du das reti nur auskommentieren und
das Projekt neu übersetzen. Dann solle es für die DRAM-Bestückung stabil
laufen.
Ich habe mal eine HEX-Datei erzeugt, ohne sie jedoch zu testen.
; ------------------- DRAM Refresh Interrupt --------------------
.cseg
INTERRUPT OC2Aaddr
;reti ; only for SRAM
Joe G. schrieb:> Ich habe mal eine HEX-Datei erzeugt, ohne sie jedoch zu testen.
Vielen Dank fuers compilieren! :)
Leider ist es trotz dem DRAM-Refresh noch instabil (OK - nicht so viel
wie vorher).
Zum Test nehme ich gern dac ompilierte FRAROUND, das endet hier mit
einem Garbage Collection Error.
Die interpretierte Version endet mit einem CPU-Halt.
Wenn ich FRACTAL.BAS mit Tera Term langsam ueber die Zwischenablage in
MBASIC reinlaufen lasse, bekomme ich beim speichern einen anderen
CPU-Halt Error :(
Diese hatte ich mit der v3.2 r155 nicht.
Das DRAM kann nicht direkt mit SRAM im Sockel ersetzt werden?
Soweit ich gelesen habe, kommt SRAM bei Deiner anderen
Emulations-Platine zum Einsatz (128K SRAM wovon 64K genutzt werden).
Die SRAM Variante hatte ich mal entworfen, weil nicht mehr jeder Zugang
zu einem alten DRAM Riegel hatte. Der Speicher kann nicht 1:1 ersetzt
werden, da die die Ansteuerung RAS/CAS entfällt. Dazu sind bei der
SRAM-Variante noch zwei Octal-Latch (74HC574) integriert, die die
Zwischenspeicherung für RAS/CAS vornehmen.
Die Instabilitäten in deiner Variante kann ich nicht nachvollziehen. Ich
habe gerade dein Programm auf meiner DRAM-Variante laufen lassen – keine
Probleme. Mögliche Fehlerursachen könnten sein:
DRAM arbeitet nicht mehr korrekt (Speicherverlust)
ATMEGA328 ist bei den 3.3V mit dem 20 MHz Takt überfordert (liegt ja
außerhalb der Spezifikation)
mein heutiger Test:
@Joe, bitte daran denken, dass auf Mobilgeräten Proportionalschrift
verwendet und deshalb Dein Code als Fließtext ausgegeben wird, der dann
vom Leser nicht mehr richtig erkannt werden kann. Bitte immer die
entsprechenden Stellen in [ code ] und [ /code ] (ohne Leerzeichen)
einfassen.
Ich habe das oben für Dich gemacht.
Verstehen muss ich es ja nicht :)
Ich habe mir jetzt doch mal eine Mini-avrasm2-Compileumgebung
"gebastelt" und den Source selbst compiliert:
AVRASM: AVR macro assembler 2.2.8 (build 80 Jan 14 2020 18:27:50)
Copyright (C) 1995-2020 ATMEL Corporation
"ATmega328P" memory use summary [bytes]:
Segment Begin End Code Data Used Size Use%
---------------------------------------------------------------
[.cseg] 0x000000 0x007800 16528 1150 17678 32768 53.9%
[.dseg] 0x000100 0x00070d 0 1549 1549 2048 75.6%
[.eseg] 0x000000 0x000000 0 0 0 1024 0.0%
Assembly complete, 0 errors. 6 warnings
Allerdings habe ich mir die alten dram-refresh.asm angesehen.
Da war das reti vom SRAM nicht nur auskommentiert, sondern die Zeile
ganz weg.
So habe ich das reti inkl. dem SRAM-Kommentar geloescht.
Also habe ich eigentlich keine Aenderung erwartet, aber jetzt klappt es
mit den FRAROUND-Versionen und auch das speichern des FRACTAL.BAS in
MBASIC :)
Ich habe mal "ganz frech" meine Version v3.5 R241GL benannt.
Die haenge ich mal als Anhang dran inkl. dem Source und Compiler.
Das ganze war bei mir in C:\TEMP\avrasm2
und konfiguriert ist es dann in der
C:\TEMP\avrasm2\avrcpm35\AvrBuild.BAT
Das baut die .hex in C:\TEMP\avrasm2\ als avrcpm_v3_5_R241GL_ddr.hex
Joe G. schrieb:> Ich nutze die Version 3.00A mit den Einstellungen als VT100 Terminal.
Bei Turbo Pascal v3.01A waren es 2 Probleme hier.
1.)
stand das Terminal auf ANSI und in den 32-Terminal-Definitionen meiner
v3.01A Dateien gab es kein VT100
Dies konnte durch Uebernahme der TINST.DTA aus der v3.00A beheben.
Damit kannte TINST von v3.01A dann auch VT100
Die passende B._Floppy haenge ich ier an.
2.)
Meine mit MSYS2 compilierte cpmtools Version macht nur Murks :(
Ich habe aus anderer Quelle eine console-cygwin-2.24-Version fuer
Windowsm die arbeitet richtig
Damit kommen die Dateien und Verzeichniseintrage dann auch sauber an.
Joe G. schrieb:> Ich hatte hier [1] mal ein nettes Tool vorgestellt um schnell ein Immage> zu erzeugen oder zu schreiben.>> [1] Beitrag "Re: CP/M auf ATmega88"
Als Alternative gibt es auch den
CIFE - CP/M Image File Explorer
von Uwe Merker
https://github.com/ProgrammingHobby/CPM_Image-File_Explorer
ESPTerm fand ich Jahren auch nett, aber ich verlor immer die Verbindung
(Drehendes Icon WG WLAN?)
Ich mag mit einem ESP dann eher einen Telnet-Zugriff.
Dazu gibt es von "DHansel" die WiFi-Moden Firmware:
https://github.com/dhansel/WifiModem
Mit leichtem basteln geht die nicht nur auf einem ESP8266 sondern auch
auf einem ESP32.
Und vom ESP32 gibt es auch eine Platinenversion mit Ethernet.
Thread beobachten
Seitenaufteilung abschalten
