www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik CP/M auf ATmega88


Autor: Peter Sieg (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: karadur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
karadur schrieb:
> Habe selbst
> unter CP/M meine Diplomarbeit geschrieben

Willkommen im Club. ;-)

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nils S. (kruemeltee) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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

Autor: karadur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

dann sucht mal nach XINU.( Zilog ) Läuft zwar nicht auf AVR, aber 8Bit.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: karadur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-).

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 :-))

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank K. (fchk)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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&...

fchk

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: karadur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :-)

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wobei Burroughs es sich noch leisten konnte, die Kabel einigermassen zu 
sortieren und mit passender Länge zu verlegen. Bei der Cray-1 ging das 
nicht mehr. Dort sind die Kabel nach passender Verzögerungszeit 
dimensioniert. Dementsprechend sieht es drin aus:
http://www.digibarn.com/collections/systems/crays/...

Beim Verkabeln:
http://www.digibarn.com/collections/systems/crays/...
http://www.digibarn.com/collections/systems/crays/...

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
—————————————————————————————————————————————————————————————————————
"Produkt"                      Gewichtung > 0     Gewichtung = 0
—————————————————————————————————————————————————————————————————————
Web-Server im SO-6-Gehäuse     Baugröße           Speicherkapazität
                               Materialkosten     Geschwindigkeit

Soft-USB                       Baugröße           Geschwindigkeit
                               Materialkosten     Entwicklungsaufwand

Oszi aus Schrottteilen         Materialkosten     Bandbreite
(alter Fernseher usw.)                            Messgenauigkeit
                                                  Entwicklungsaufwand

Relaisrechner                  Restro-Aspekt      Geschwindigkeit
                                                  Speicherkapazität
                                                  Entwicklungsaufwand
—————————————————————————————————————————————————————————————————————

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!

Autor: Ronny Minow (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ronny Minow (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ronny Minow (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ronny Minow (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ronny Minow (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Kluchscheißernder Nixwisser (kluchscheisser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ronny Minow (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sigint 112 (sigint)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Sieg (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
dram_read:      cli                     ;1 disable interrupt
                ldi     ZL,0x7F         ;1 RAS
                ldi     ZH,0x1F         ;1 RAS + CAS + OE
                out     PORTC,adrh      ;1
                out     PORTD,ZL        ;1 RAS active
                out     PORTC,adrl      ;1
                out     PORTD,ZH        ;1 RAS + CAS + OE active
                ldi     ZL,0x9F         ;1 RAS inactive
                out     PORTD,ZL        ;1 CAS + OE (hidden refresh)
                in      temp,PINA       ;1 get data
                out     PORTD,ZH        ;1 RAS + CAS + OE
                ldi     ZH,0xFF         ;1
                out     PORTD,ZL        ;1 only RAS
                out     PORTD,ZH        ;1 inhibit
                sei                     ;1 enable interrupt
                ret                     ;4 end          
Bringt Beschleunigung um etwa Faktor 7 beim Lesen aus dem Speicher.

Jörg

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ronny Minow (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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...

Autor: kruemeltee (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sowas gibt es auch mit dem Propeller:

http://forums.parallax.com/forums/default.aspx?f=2...

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

Autor: Ronny Minow (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kruemeltee schrieb:
> Sowas gibt es auch mit dem Propeller:
>
> http://forums.parallax.com/forums/default.aspx?f=2...
>
> 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?

Autor: bix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Roland F. (opale)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ronny Minow (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: CPM-Gerümpelrechner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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?

Autor: Ronny Minow (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Ronny Minow (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann hat man allerdings Probleme mit dem obersten Kilobyte. :)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da ist doch Platz für einen Regler drauf - dann könnte man auf 
vorhandene Wandwarzen zurückgreifen...

Autor: Ronny Minow (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@PeterSieg: ich bin #2 (Posting #18) im Board drüben...

Autor: Sigint 112 (sigint)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Peter Sieg (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: karadur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> aber woher kommen die 3,3V.

Im FTDI steckt ein 3,3V-Regler.

Mich würde die Platine auch interessieren.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
karadur schrieb:
> aber es gibt heute bessere Systeme

Aber klar doch. Nur sind die auch noch so übersichtlich, wie CPM?

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ronny Minow (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter Sieg: Du kannst zu meiner Platinenreservierung (+ SRam usw.) eine 
dazu legen. Dann sind es 8 Platinen.

Autor: O. Hagendorf (ohagendorf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und ich bin auch an einer interessiert.

Olaf

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde vorschlagen, noch eine rote LED draufzusetzen, die leuchtet, 
wenn das Teil auf 5V gejumpert ist - dann werden nicht so viele SDs 
gebraten.

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Ronny Minow (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...?

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Ronny Minow (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Andy H. (vinculum) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Michael_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>@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.

Autor: karadur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Andy H.

war die Schaltung aus der c't. Läuft immer noch. Zusammen mit der 1MByte 
Ramfloppy.

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Andy H. (vinculum) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Joerg F. (felge1966)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Frage: wie bekomme ich unter XP das disk image auf die SD-Card?

Autor: Zorg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Infos, Peter :)

Autor: Ronny Minow (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter Sieg: Wie sieht es mit den Versandkosten aus?

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ronny Minow: Denkst du nicht, das diese Frage besser von Joe 
beantwortet werden sollte.. ;-)

Peter

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist mit der 5V-LED? 
Beitrag "Re: CP/M auf ATmega88"

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: bix (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: bix (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Man hätte noch Platz für ein kleines Lochraster-Feld.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist der FTDI jetzt gestrichen? Hoffentlich nicht...

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: bix (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: bix (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> fehlen solche elementaren Dinge, wie Abblockkondensatoren.

Hallo Spess, beziehst Du Dich auf den aktuellen Schaltplan von Joe?

Gruß, bix

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: bix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-Karten
http://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-interf...

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.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Hinweise, werden aufgegriffen. Die fehlende Drossel in der 
USB-Leitung vermißt wohl keiner? Gibt es ohne sie in Problem (EMV)?
Joe

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: heini (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: bix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: bix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/...
(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

Autor: karadur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Uhu Uhuhu

zum Thema Schnapsidee: http://www.ez80sbc.com/

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ö.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Sieg (petersieg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: telenovela (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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...

Autor: bix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: heini (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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>

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Ronny Minow (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Notfalls als SD-Card mit Lautsprecher für's adäquate Rattern.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joerg Felgentreu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu schrieb:

> Ah, das wußte ich nicht. Ist ja nett... Wo denn?

http://www.cpm.z80.de/source.html

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist ja wirklich nett. Vielen Dank.

PL/M habe ich auch mal programmiert - ist aber nicht wirklich der 
Bringer...

Autor: bix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Uhu

keine Sorge, dafür habe ich schon einen eigenen...

Jörg

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Michael_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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/HY...
Ich lasse mich auch eines besseren belehren.

Autor: kruemeltee (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schaut euch mal 512k AS6C4008 + 74HC374 + 74HC138 an. Ist nicht teuer 
und gibt sogar banked her :)

Autor: nixKönner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/HY...
> 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

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: bix (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Höhlenmaler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>(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!

Autor: Peter Sieg (petersieg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja und mit beweglichen Lettern drucken konnte man schon im 15. 
Jahrhundert...

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Evaluation Kit "At XMega XPlain" wäre vielleicht das richtige für 
euch. Gibt's bei Reichelt für ca. 36€.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier gibt es die Beschreibung zu dem Board:
http://www.atmel.com/dyn/resources/prod_documents/...

Mit 8MB Flash dürfte sich mit CPM wohl einiges anfangen lassen.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan schrieb:
> Mit 8MB Flash dürfte sich mit CPM wohl einiges anfangen lassen.

Eher nicht.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... keine Sorge, dafür habe ich schon einen eigenen ...

Hallo Joerg,

wo kann ich deinen Thread finden?

Martin

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Joerg

OK.

Autor: bix (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: bix (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Huch
Das Schaltbild wollte ich als PNG anhängen. Hab mich verklickt, Anhänge 
zeigt die Vorschau leider nicht an - sorry.

Autor: Ronny Minow (hobby-coder)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@bix: normalerweise bekommst du eine infomail, das du registriert bist. 
versuche dich einfach mal einzuloggen...

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bix schrieb:
> Wie lange dauert die Freischaltung zum Forum normalerweise?

Welches Forum?

Autor: bix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: bix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).
; ATmega8 (HW-Rev.2)
; 
; 
;             +-------------v-------------+ 
;      Reset\ | 01 (RESET)         PC5 28 | CAS\
;      TXD    | 02 (RXD)           PC4 27 | RAS\ (*)
;      RXD    | 03 (TXD)           PC3 26 | D3
;      OE\    | 04 PD2             PC2 25 | D1
;  (*) WE\    | 05 PD3             PC1 24 | D2   (*)
;      SD_CS\ | 06 PD4             PC0 23 | D0
;      VCC    | 07 VCC             GND 22 | GND
;      GND    | 08 GND            AREF 21 | n.c.
;      Q20MHz | 09 (XTAL1)        AVCC 20 | VCC
;      Q20MHz | 10 (XTAL2)   (SCK) PB5 19 | A8 / SD_SCK (*)
;      A5     | 11 PD5      (MISO) PB4 18 | A0 / SD_MISO
;      A6     | 12 PD6      (MOSI) PB3 17 | A1 / SD_MOSI
;      A7     | 13 PD7             PB2 16 | A2
;      A4     | 14 PB0             PB1 15 | A3
;             +---------------------------+ 

E-Mail mache ich gleich fertig.

Danke und Grüße

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@bix / Joe: Prima!

Peter

Autor: Peter Sieg (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Sieg (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: bix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Sieg schrieb:
> Soo ähnlich sollte die voll bestückte Platine dann aussehen ;-)

Schööön.

Ich freu mich schon darauf, den FT232 zu löten ;-)

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist doch eine gute Möglichkeit sich in SMD löten zu versuchen. Ich 
kann aber (nur für alte Knacker) den FT232 schon bestücken.

Joe

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
; OK
weist darauf hin, dass diese Funktion schon überprüft ist. Im Gegensatz 
zu
; 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:
      RLC  A
      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.

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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:
.equ F_CPU = 20000000                           ; system clock in Hz
.equ BAUD  = 38400                              ; baud rate
 
; Berechnungen
.equ UBRR_VAL   = ((F_CPU+BAUD*8)/(BAUD*16)-1)  ; clever rounding

...

; - Init serial port
  ldi temp,$18
  sts ucsr0b,temp
  ldi temp,$6
  sts ucsr0c,temp
  ldi temp,0
  sts ubrr0h,temp
  ldi temp,UBRR_VAL
  sts ubrr0l,temp

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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
; - Init serial port
  ldi temp, (1<<TXEN0) | (1<<RXEN0)
  sts ucsr0b,temp
  ldi temp, (1<<UCSZ01) | (1<<UCSZ00)
  sts ucsr0c,temp
  ldi temp, HIGH(UBRR_VAL)
  sts ubrr0h,temp
  ldi temp, LOW(UBRR_VAL)
  sts ubrr0l,temp

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
do_fetch_af:
  mov opl,z_flags
  mov oph,z_a
  rcall do_op_calcparity
  andi opl,~(1<<ZFL_P)
  sbrs temp2,0
   ori opl,(1<<ZFL_P)
  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.

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :-(

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

um eine Struktur in die nun beginnenden Soft- und Hardwareänderungen zu 
bringen hier mein Vorschlag zur Projektseite:
http://www.mikrocontroller.net/articles/AVR_CP/M

Gruß Joe

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf dem Schaltplan (http://www.mikrocontroller.net/articles/AVR_CP/M) 
ist kaum etwas zu erkennen?

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Martin
@alle

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

Joe

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
do_op_inc:
  andi  z_flags, (1<<ZFL_C)       ; bis auf Carry alles auf 0
  ldi   temp, 1
  add   opl, temp
  in    temp, sreg
  mov   parityb, opl
  bst   temp, AVR_Z               ; Zero
  bld   z_flags, ZFL_Z
  sbrc  opl, 7                    ; Sign
  ori   z_flags, (1<<ZFL_S)       
  bst   temp, AVR_H               ; Half Sign
  bld   z_flags, ZFL_H
  bst   temp, AVR_C               ; Overflow
  bld   z_flags, ZFL_P
  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...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Leo C.: Aber Sicher besteht daran Interesse!
Und ein Bild des Aufbaus wäre auch schön ;-)

Gruß Peter

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
test:       sub    A               ;setzt A auf 0 (kein Overflow)
            jp     pe,code_8080    ;wenn A=0 dann ist Parity even
code_z80:   ....


code_8080:  ....

Jörg

Autor: Leo C. (rapid)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Leo C. (rapid)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So sieht sie aus, die erste bestückte Platine.

Joe

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieht doch super aus!

Peter

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Juchhu,
DDT kann jetzt Programme tracen.

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

Autor: Leo C. (rapid)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>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...
http://tinyvga.com/avr-sdram-vga

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In dem Assemblerfile "" 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?

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

BDOS gehört zum CP/M (+BIOS und CCP).

MfG Spess

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antwort: ich habe jetzt eine Seite gefunden 
(http://www.dcast.vbox.co.uk/cpm.html) die näher auf die Adressen 
eingeht .

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Leo C. (rapid)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

  in  temp,PINC        ; 1. Nibble einlesen (untere Hälfte von PC)
  andi temp,0x0f       ; obere Hälfte wegmaskieren
  swap temp

        ;Adressen umschalten ...

  in  temp2,PINC       ; 2. Nibble einlesen
  andi temp2,0x0f
  or  temp,temp2       ; Beide Hälften zusammen

Zusammen 6 Befehle, 6 Takte.
Im Originalprgramm gibt es ein Unterprogramm, das zwei mal aufgerufen
wird:
;...
  rcall dram_getnibble  
  swap temp

        ;Adressen umschalten ...

  rcall dram_getnibble  

        ; ...
;...

dram_getnibble:
  andi temp,0xf0
  sbic pinc,ram_d0
   ori temp,0x1
  sbic pinc,ram_d1
   ori temp,0x2
  sbic pinc,ram_d2
   ori temp,0x4
  sbic pinc,ram_d3
   ori temp,0x8
  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.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Leo

Guten Hunger.

Na ja. Die Adress-Pin-Belegung ist wirklich nicht die glücklichste. Wär 
dann vllt was für eine Folge-Version :-)

Autor: Peter Sieg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Leo C. (rapid)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: bix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Leo C. (rapid)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Leo C. (rapid)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal ein kleiner Test.

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

Und das hier kam raus:
--------------------------------------------------------------------
AVR Atmega mit |                12,288 Mhz              |   20 MHz  
---------------+------------+----------------+----------+-----------
               | Laufzeit        Laufzeit        Z80         Z80
               |  Gesamt        pro Z80 Takt    Speed       Speed
---------------+-----------------------------------------------------
Orig. DRAM R/W | 17,187 s        5,960 µs      168 KHz     273 KHz
Neue  DRAM R/W |  9,806 s        3,401 µs      294 KHz     478 KHz
---------------+-----------------------------------------------------
simh AltairZ80 |  0,022 s        7,629 ns      131 MHz

Zum Vergleich habe ich noch die Zahlen von einem Simulator auf meinem
PC dazugetan. (08/15 PC mit 2,5MHz Athlon 4850e)

Mein AVR läuft nur mit 12,288 MHz. Deshalb habe ich die Zahlen noch für
20MHz hochgerechnet. Die Zahlen erscheinen mir durchaus plausibel, wenn
ich an die Geschwindigkeit von meinem 4MHz CP/M-Rechner zurückdenke.

Ganz oben hat Jörg Wolfram geschrieben, daß er mit einem AVR ca. 2MHz
Z80-Geschwindigkeit erreicht hat. Na, dann gibts hier ja noch einiges
an *Spiel*raum...

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

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

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :-(

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... hatte ich schon geändert. Muß noch was anderes faul sein.

Autor: Leo C. (rapid)
Datum:

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

Autor: nix_könner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: nix_könner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Leo. Dann muss ich mal suchen.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)?

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Leo C. schrieb:

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

einen MT4C4256-80

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Leo C. (rapid)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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]
                 ; - Setup Ports
...
000045 e300        ldi temp,PC_OUTPUT_MASK
000046 b907        out DDRC,temp

...

                 dram_write:
0002f6 94f8        cli
...
0002f7 b117        in temp2,DDRC               ;DRAM data ports as outputs
0002f8 601f        ori temp2,RAM_DQ_MASK
0002f9 b917        out DDRC,temp2
...
000340 9a44        sbi PORTC,ram_w
...
000342 b107        in temp,DDRC
000343 7f00        andi temp,~RAM_DQ_MASK
000344 b907        out DDRC,temp
000345 b108        in temp,PORTC
000346 7f00        andi temp,~RAM_DQ_MASK
000347 b908        out PORTC,temp

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: volkerp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joe G. (feinmechaniker) Benutzerseite
Datum:

Bewertung
0