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
Announcement: there is an English version of this forum on 
