Announcement: there is an English version of this forum on Hi. Wollte mal auf diese Projekt aufmerksam machen: http://spritesmods.com/?art=avrcpm Dort wurde ein ATmega88, ein 256kx4 DRam-chip und eine SD Karte zusammen geschaltet, um über einen 8080 Emulator letzlich CP/M 2.2 von der SD Karte zu booten! Ich dachte erst.. das kann doch nicht sein.. und hielt das für einen Aprilscherz.. aber er funktioniert wirklich! Siehe: http://avr.cwsurf (dot) de/?AVR_CP%2FM Es wäre wunderbar, wenn sich hierfür noch mehr Leute begeistern könnten und 1. Schauen, welche 8080 CP/M Programme jetzt auch schon laufen.. also ggf. erweiterte diskimage's erstellen und testen.. BTW: MBASIC steigt mit einem fehlenden Opcode aus.. ZORK läuft! Prima wären ein paar Spiele z.B Sargon Schach etc... 2. Versuchen den AVR Assemblersource zu erweitern (mehr opcodes/Z80). Peter
Ich hatte selbst schon mal mit einem Z80-Emulator und externem DRAM an einem Mega644 angefangen. Mit allen möglichen "Tricks" kommt man so auf maximal 2MHz beim emulierten Z80, mit zusätzlicher Videoausgabe-Routine und PS2-Tastatur wurde das Ganze eigentlich unbrauchbar. Für eine bessere Emulation würde ich auf jeden Fall einen größeren µC nehmen und für schnelleren Speicherzugriff diesen mit 8 Bits anschließen. Ansonsten finde ich die Idee nicht schlecht. Jörg
Peter Sieg schrieb: > Dort wurde ein ATmega88, ein 256kx4 DRam-chip und eine SD Karte zusammen > geschaltet, um über einen 8080 Emulator letzlich CP/M 2.2 von der SD > Karte zu booten! Hallo Peter, du meinst doch sicher 2 Chips mit 4bit-RAM - einen Z80 auf einer 4bit-Architektur zu emulieren wäre schon Tierquälerei, obwohl natürlich im Prinzip alles geht, auch eine Turingmaschine als Z80. Ich habe zwar tatsächlich noch Quasi-CP/M-Systeme im Einsatz (der Prozessor glaubt zumindest an CP/M), aber trotzdem die Frage, was soll's - es gibt genügend Z80 und CP/M Systeme auf dem PC, und schliesslich gibts ja den Z80 auch noch. Gruss Reinhard
Reinhard Kern schrieb: > Peter Sieg schrieb: >> Dort wurde ein ATmega88, ein 256kx4 DRam-chip und eine SD Karte zusammen >> geschaltet, um über einen 8080 Emulator letzlich CP/M 2.2 von der SD >> Karte zu booten! > > Hallo Peter, > > du meinst doch sicher 2 Chips mit 4bit-RAM - einen Z80 auf einer > 4bit-Architektur zu emulieren Perverserweise hat er tatsächlich nur einen RAM Chip benutzt. Was soll ein Z80 auch mit 256kB anfangen :-) (Kann den Link nicht direkt posten, Das (dot) gegen einen . austauschen. Ja der Link sieht ansonsten wirklich so seltsam aus http://avr.cwsurf (dot) de/?AVR_CP%2FM Alle Speicherzugriffe ins REM werden über Nibbles abgehandelt Wie die Befehlsdekodierung und Ausführung gemacht wurde: Finde ich clever gelöst
Jup. Nur 1 DRam a 256kx4. Ein Byte wird als 2xNibble geschrieben und wieder gelesen.. Selbst ich als Assembler Noob finde den Quelltext gut lesbar und strukturiert.. Warum? Weil es geht! Und weil es Spaß macht zu zeigen, das es geht.. Und weil ein ATmega88 ca. 3€ kostet, eine solches DRam gibts in der Schrottkiste (sind z.B beim Amiga 500 verwendet worden..) also alles für ca. 6-8€.. Ich persönlich finde die aktuelle Geschwindigkeit gar nicht soo schlecht! Läuft aktuell mit 20MHz. Für SwinSID sind die 88er aktuell sogar mit 32 und 40MHz übertaktet.. also noch eine Option.. ohne Hardware und (fast) Softwareanpassungen.. Für mich wäre die erste Priorität die Kompatibilität zu erhöhen, indem mehr Opcodes unterstützt werden.. Wäre doch was, wenn MBASIC und Sargon Chess darauf laufen würden (Sargon habe ich noch nicht getestet).. BTW: Mit der seriellen Anbindung bin ich prima zufrieden.. ich möchte gar keine TV/BAS und PS/2 Anschluß.. (trotzdem ist AVR Chipbasic ein prima Projekt!!) Nur CP/M ist hat schon was.. Turbo Pascal, Wordstar, dBase II.. ;-) Peter
Ja, man könnte dann endlich die ATMegas als echte Computer verwenden. Nur schade, dass CP/M mindestens 16 Kilobyte RAM erfordert, sonst könnte man das ja komplett auf dem Mikrocontroller laufen lassen. Man könnte sich da vielleicht sogar noch eine Art Bussystem, beispielsweise auf Basis des I^2C überlegen, über den man dann Peripheriegeräte anschließen kann. Die könnte man dann dem Betriebssystem als Block oder Zeichengeräte darbieten.
Hallo ist akademisch interessant, aber: CP/M war vor 25 Jahren. ( Habe selbst unter CP/M meine Diplomarbeit geschrieben und Programme für mein Diplom geschrieben. ) UNIX und VMS gab es damals auch schon. CP/M jetzt auf einem AVR zu emulieren und als Betriebssystem zu verwenden ist "schräg". Ein Linux auf einem AVR ist da wohl eher angesagt.
karadur schrieb: > Ein Linux auf einem AVR ist da wohl eher angesagt. Der Linux-Kernel braucht so mindestens 4-8 Megabytes an Speicher. Ich glaube, das wird aber dann auch zu langsam.
>> Ein Linux auf einem AVR ist da wohl eher angesagt. >Der Linux-Kernel braucht so mindestens 4-8 Megabytes an Speicher. Ich >glaube, das wird aber dann auch zu langsam. ... und eine MMU, FPU von Vorteil, 32 Bit Arch. (16 wüde gehen), und und und
Ja, solche klein-Unixe gibts einige. Hätte man jedoch CP/M, so hätte man erstmal eine Plattform auf der man aufbauen kann. Natürlich könnte man sich auch überlegen, auf dem Atmel selbst ein Dateisystem im Flash aufzubauen, aus dem man dann nativ Code ausführen könnte. Aber das ist eventuell mehr Arbeit als solch ein Emulator und weniger flexibel.
Karl heinz Buchegger schrieb: > Perverserweise hat er tatsächlich nur einen RAM Chip benutzt. Was soll > ein Z80 auch mit 256kB anfangen :-) viel: program overlays habe ich ausgiebig benutzt und die kann man auch mit page switching einblenden statt nachzuladen, geht viel schneller. Und wenn man 4bit-Nibbles laden kann, dann kann man auch Daten aus einem MB-grossen RAM laden. Eine Steuerungssoftware von mir hatte 30 Overlays und hätte daher auf 30 RAM-Pages a 32 kB laufen können. Unterschätzt den Z80 nicht, da konnte man auch schon richtige Computer damit bauen. Gruss Reinhard
Hallo es gab auch CP/M 3.0. Damit konnte man dank MMU mit einem Z80 sehr viel mehr Speicher verwalten. Ganz zu schweigen von CP/M86 und CP/M68k. Und: die eZ80 sind auch nicht ohne. PS: Auf meinem 8MHz Z80 CP/M war Turbopascal deutlich schneller als auf einem IBM XT. Und: etwas was ich sehr vermisse. Dank Epromfloppy war der Rechner schneller gestartet als das die Bildröhre warm war.
Also nen Linux auf nem AVR emulieren dürfte denke ich scheitern. Aber das CP/M mit emulierter Z80 ... Schon echt ne geniale Sache. @reinhard >Unterschätzt den Z80 nicht, da konnte man auch schon richtige Computer >damit bauen. Das ist wohl auch der Grund warum es so viele Computer auf Z80-Basis gab :-) Mal im Ernst. Immerhin hat die ganze Computerei ja mit dem 4004 angefangen (wenn man man den Zuse, IBM, Leibnitz und Babbage außen vor lässt :-) Und nen Z80 auf nem AVR emulieren, und "nebenbei" noch das DRAM handlen ... Respekt. Wenn ich damals mal was mit CP/M gemacht hätte würd ich dieses Projekt auf jedenfall nachbauen. Retro mit neuen mitteln find ich immer witzig. Genauso wie den SwinSID. Schon echt klasse so Projekte. Weiter so :-)
Rene Böllhoff schrieb: > Also nen Linux auf nem AVR emulieren dürfte denke ich scheitern. Nicht wirklich, wäre nur zu langsam. Wer eine Z80 simulieren kann, der kann auch eine PDP-11 simulieren. Wird allerdings nicht brandschnell sein. > Mal im Ernst. Immerhin hat die ganze Computerei ja mit dem 4004 > angefangen (wenn man man den Zuse, IBM, Leibnitz und Babbage außen vor > lässt :-) Autos gibt's auch erst seit dem VM-Käfer, wenn man mal die zig anderen älteren Hersteller aussen vor lässt ;-). Mit dem 4004 haben die Mikrocomputer angefangen. Nicht die Computer.
Naja, bis zum 8080 galten solche Mikroprozessoren aber eher als was für Steuerungen, ähnlich wie heute die Mikrocontroller. Naja, aber im Emulator könnte man richtig viel machen. Man könnte zum Beispiel virtuelle Hardwareeinheiten machen, welche dann rechenintensive Operationen übernehmen. Damit könnte man sicherlich bis fast zur nativen Geschwindigkeit der AVRs kommen.
>Autos gibt's auch erst seit dem VM-Käfer, wenn man mal die zig anderen >älteren Hersteller aussen vor lässt ;-). Hast schon recht :-) Aber ich denke mit dem 6502 und dem Z80 wurde die Computerei auch für Hobbybastler möglich bzw die Verbreitung hat damit erst Einzug gehalten. Trotzdem schon echt erstaunlich wie sich das alles entwickelt hat ... Vor allem in den letzten 30 Jahren.
Christian Berger schrieb: > Naja, bis zum 8080 galten solche Mikroprozessoren aber eher als was für > Steuerungen, ähnlich wie heute die Mikrocontroller. D'accord, solange du das "Mikro" nicht vergisst, wie Rene das tat.
Rene Böllhoff schrieb: > Trotzdem schon echt erstaunlich wie sich das alles entwickelt hat ... > Vor allem in den letzten 30 Jahren. Davor war's im Entwicklungstempo auch nicht übel. Noch 1969 wurden (manche) Computer aus Myriaden von Einzeltransistoren aufgebaut, z.B. der für viele Jahre schnellste Computer CDC7600. Die (fast) vollintegrierte 8080 kam mit ihren 6000 Transistoren auf dem Chip grad mal 5 Jahre später raus (und war natürlich viele Grössenordnungen langsamer).
>Davor war's im Entwicklungstempo auch nicht übel.
Schon richtig. Aber so richtig Einzug hat der Mikroprozessor ja erst
gefunden nachdem die Bauform nicht mehr in Turnhallen-Einheiten gemessen
wurde :-)
Aber die Miniaturisierung hat ja auch nichts mit den Konzepten von
damals zu tun. Die Prinzipien gelten ja sogar heute noch. Selbst wenn
sich in der Integration und der Ausführungs-Geschwindigkeit extrem viel
getan hat.
Rene Böllhoff schrieb: > Schon richtig. Aber so richtig Einzug hat der Mikroprozessor ja erst > gefunden nachdem die Bauform nicht mehr in Turnhallen-Einheiten gemessen > wurde :-) Sachte - es gab ab Mitte der 50er einen Röhren(!)rechner, der grad mal 2 klassische Bauernschränke gross war und nur um die 2 Tonnen wog (*), I/O extra. Das Ding war ziemlich verbreitet (>2000 Stück). So ne Art Minicomputer der Röhrenära. *: Ein Schrank für den Computer selbst, einer für die Stromversorgung. Bei einem vor 10 Jahren gängigen Disk-System der besseren Kategorie war die Basiseinheit einen solchen Schrank gross und wog grob eine Tonne. In dieser Hinsicht hat sich also wenig geändert, nur die Stromversorgung kriegt man dank Schaltnetzteiltechnik heute kleiner hin ;-).
>In dieser Hinsicht hat sich also wenig geändert ;-).
Wenn mans genau nimmt ist das ja auch ein Rückschritt gegenüber damals.
Die Groß/Superrechner von heute geben sich mit einem Schrank ja nicht
zufrieden, die wollen ja nach wie vor in Turnhalleneinheiten gerechnet
werden :-))
Das sich die Rechenleistung versechsfacht hat lassen wir mal unter den
Tisch fallen :))
Ups ... meinte : ver-zehn-hoch-sechs-oder-was-weiß-ich-sich-was-facht
:))
Aber dennoch sehr Interessant wie sich das alles entwickelt hab. Les im
Moment viel über die "alte" Technik. Vor allem würd mich mal
interessieren wie Zuse es geschafft hat mit Mechanik Fließkommazahlen zu
Rechnen. Bin ja gerad mal froh das ich das Floating-Point-Prinzip
verstehe :-))
Rene Böllhoff schrieb: > Wenn mans genau nimmt ist das ja auch ein Rückschritt gegenüber damals. > Die Groß/Superrechner von heute geben sich mit einem Schrank ja nicht > zufrieden, die wollen ja nach wie vor in Turnhalleneinheiten gerechnet > werden :-)) Es fing mit Saalgrösse an, und heute baut mal riesige Betonhallen um diese Rechner drum herum. Aber zwischendrin gab es mal eine Zeit, in der die schnellste verfügbare Rechentechnik in ein Kinderzimmer reinpasste. Solange man das nämlich mit schnellen Einzelrechnern statt zigtausend Nodes machte spielte die Verbindungslänge eine zunehmend dominante Rolle, daher mussten die Dinger schrumpfen (Cray 1 und folgende). > Aber dennoch sehr Interessant wie sich das alles entwickelt hab. Les im > Moment viel über die "alte" Technik. Kennst du das Thornton-Buch (PDF) über die CDC6600? Ungemein detailliert, bis auf Gatter/Transistorebene runter.
Peter Sieg schrieb: > Es wäre wunderbar, wenn sich hierfür noch mehr Leute begeistern könnten Ihr habt doch ein Rad ab! Sorry, aber das musste ich einfach loswerden. Ein EZ80F91AZA mit 50 MHz kostet bei Digikey etwa 10 Euro, bei RS etwa 7 Euro, hat 256k Flash eingebaut, hat Ethernet und noch einiges mehr an Peripherie (2 UART, i2c, SPI, RTC, 32 GPIOs, ...) und ist zu 100% software-kompatibel zum alten Z80. Du kannst sogar CP/M 3.0 Bankswitching machen, das Teil hat selber die entsprechende Logik dafür. Du brauchst nur noch RAM anzuschließen. Ein 512k SRAM kostet bei RS 5 Euro. Also auch nicht die Welt. /CS macht der Controller selber, Daten- und Adressbus und /RD und /WR werdet ihr auch wohl richtig anschließen können. Was soll das also? Modernes Flagellantentum? PS: http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProductDetails&familyId=130&productId=EZ80F91AZA fchk
Frank K. schrieb: > Ihr habt doch ein Rad ab! Eindeutig ja. Und? > Ein EZ80F91AZA mit 50 MHz kostet bei Digikey etwa 10 Euro, bei RS etwa 7 > Euro, hat 256k Flash eingebaut, hat Ethernet und noch einiges mehr Meinst du wirklich, es ginge hier darum, auf möglichst effiziente Weise Z80-Programme laufen zu lassen? > Was soll das also? Modernes Flagellantentum? Noch nie jemanden an einem 50 Jahre alten Motorrad basteln gesehen? Das macht der bestimmt nicht um von A nach B zu kommen.
>> Es wäre wunderbar, wenn sich hierfür noch mehr Leute begeistern könnten >Ihr habt doch ein Rad ab! Sorry, aber das musste ich einfach loswerden. >Ein EZ80F91AZA mit 50 MHz kostet bei Digikey etwa 10 Euro, bei RS etwa 7 >.... Du bist zu eingefahren: Du gehst von falschen Anforderungen aus. Du gehst davon aus, dass jedes Problem haufenweise Rechenpower, Speicher und viel Peripherie benötigt. Wer sagt, denn, dass es so sein muss? Wenn das System nicht schnell sein muss, kommst du preislich mit den von Dir aufgezählten Bauteilen nicht hin. Außerdem muss Du für Deine Bauteile eine Platine fertigen lassen. Das geht mit dem Atmega88 auch ohne. In Ingenieursstunden gerechnet, wäre Deine Lösung mit Sicherheit überteuert.
Hallo nu übertreibt es nicht! Es gibt Dinge die man einfach aus Interesse oder Spass macht. Die Idee mit einem AVR einen 8080 zu emulieren ist ja toll.
Stefan schrieb: > Wenn das System nicht schnell sein muss, kommst du preislich mit den von > Dir aufgezählten Bauteilen nicht hin. Außerdem muss Du für Deine > Bauteile eine Platine fertigen lassen. Das geht mit dem Atmega88 auch > ohne. In Ingenieursstunden gerechnet, wäre Deine Lösung mit Sicherheit > überteuert. Eben nicht. Der wesentliche Aufwand, nämlich die CPU-Emulation entfällt. Heißt also: Ich muss nur das CP/M BIOS anpassen, aber das müsst Ihr auch. Das BDOS ist ja überall gleich und wird ja als Objektfile dazugelinkt. Und selbst ein 3.0'er BIOS hat nur verhältnismäßig wenige Funktionen. Hab ich anno 87 schon mal gemacht, als ich noch jung und hybsch war. Und zum Bauteileaufwand: Gut, der Chip ist ein 144'er LQFP. Also Adapterplatine, damits aufn Lochraster paßt. Das ist auch die einzige Hürde. RAM im DIL-Gehäuse, 3.3V Vcc, kann man direkt anklemmen, ist kein Hexenwerk. Ein Quarz oder Oszillator (braucht Ihr auch), Spannungsregler (braucht Ihr auch), RS232-Pegelwandler (braucht Ihr auch), und eine Handvoll R's und C's zum abblocken und als Lastkapazität für den Quarz und als Pullups. Mehr braucht der EZ80F91 nicht, um hochzukommen. RTC gewünscht? OK, noch ein 32 kHz Uhrenquarz plus 2 C's und 1 R dazu. SD-Karte? OK, ab an den SPI-Port. Kennt Ihr ja, ist hier auch nicht anders. Wenn man kein Ethernet braucht, dann wars das. Wirklich! Ich habe Eval-Board, Prozessormodule und ZDI(Zilog 2-Draht JTAG Variante)-Debugger und die ganze Doku und Software da, ich weiss, wovon ich rede. fchk
@Frank >Ihr habt doch ein Rad ab! Fällt dir aber früh auf ... >Ein EZ80F91AZA mit 50 MHz kostet bei Digikey etwa 10 Euro, ... Natürlich gibts Chips/Boards die mehr können weniger kosten, aber es besteht doch gerade der Reiz darin mit den heutigen Standardchips solche Sachen zu machen wie z.b. eine Z80, einen SID, eine 6502 zu emulieren, oder eben ein BAS-Signal für nen Fernseher zu erzeugen. Ich bin ja auch total Plemplem wenn ich mit einem FPGA Audio mache obwohl jeder DSP für die Hälfte an Euros das doppelte an MIPS/MFLOPS hat. Trotzdem macht es Spaß, man lernt was dabei und man freut sich nachher. (Selbst wenns im Falle des Audio-FPGAs die Freude hauptsächlich bei mit selbst liegt, aber das ist es mir wert) Ich glaube man nennt sowas : Meet the Challenge ... Oder anders gesagt : Wenns Spaß macht ... @A.K. >Kennst du das Thornton-Buch (PDF) über die CDC6600? Ne leider nicht. Hast du vllt nen Link dazu ? Hatte mir mal die Schaltpläne von dem Apollo-11 Rechner angeguckt. Und bin doch echt erstaunt wie nahe das Dingen einem heutigen Mikrocontroller kommt.
Frank K. schrieb: > Ihr habt doch ein Rad ab! Ich freue mich über diese losen Räder. Ehrlich! Schade dass du sie nicht hast. Frank K. schrieb: > ich weiss, wovon ich rede. Mag sein, aber leider weisst nicht du nicht, wovon hier geredet wird. Nicht von einer aktuellen Technik, sonderm dem Schwelgen in Vergangenheit und deren Technik. Fertig kaufen kann man alles. Dann wäre jedes Hobby, wo selbst gebaut wird dummes Zeug. Alles kann man billiger und fertig kaufen. #gähn# Das Z80-Zeugs was du erwähnst liegt hier auch rum. Weiss also was du meinst. Ist aber nicht das, wovon hier gesprochen wird.
900ss D. schrieb: > ... Fertig kaufen kann man alles. Dann wäre > jedes Hobby, wo selbst gebaut wird dummes Zeug. Alles kann man billiger > und fertig kaufen. #gähn# Ist aber Trend. Ich habe noch für Segelflugzeuge Spanten zugesägt und mit Seide bespannt, die Enkel meines Nachbarn haben gestern auch ein Segelflugzeug bekommen, auspacken, Flügel reinstecken, fliegt (nicht so gut wie meine, muss ich feststellen). Die Kinder erwarten das auch so, deswegen gibt es keine Bausätze mehr. Der PC muss eben auch zum Geburtstag betriebsfertig dastehen. Gruss Reinhard
Frank K. schrieb: > Eben nicht. Der wesentliche Aufwand, nämlich die CPU-Emulation entfällt. Die CPU-Emulation ist reine Software, das muss somit nur einmal gemacht werden. Natürlich stimme ich Dir aber zu, dass wir eine Schraube locker haben. Für uns ist Elektrotechnik ein wichtiger Teil in unserem Leben, und willkommener Ausgleich zum langweiligen Beruf.
karadur schrieb: > Habe selbst > unter CP/M meine Diplomarbeit Was ich vergass, hab ich übrigens auch ;-) Es war allerdings ein geklontes CP/M und hiess ZDOS und lief auf einem Z-80-System auf ECB-Bus Basis von Fa. Janich & Klass. Die Firma gibt es sogar noch, wie ich gerade festgestellt habe. Und das System hatte zwei 8"-Lauferke. :-)
@Peter Sieg Sorry, aber es geht hier nicht um das Einfachste oder Schnellste. Es geht um die Herausforderung. Sicher es wäre einfacher auf dem PC einen fertigen Z80 Emulator anzuwerfen und gut. Aber was hat man davon? Es ist für mich halt interessanter eine Rechnerarchitektur auf einer anderen abzubilden. In diesem Falle lernt man nämlich über beide etwas. Genauso ist es vermutlich bei den Cracks, die heutzutage noch Demos für den C64 machen (teilweise mit Effekten die man vor 15 Jahren nicht einmal einem PC zugetraut hätte) Wenn man dort sagen würde: "wieso nehmt ihr nicht einen PC mit 3d Karte, der ist doch viel schneller" Dann würde man vermutlich aus dem Saal geworfen werden. P.S. Zur Zeit code ich an einer 6502 Emu (mit RAM, ROM, Dezimalmodus und illegalen Opcodes) und kämpfe mit teilweise wiedersprüchlichen Dokus.
Christian Berger schrieb: > Natürlich stimme ich Dir aber zu, dass wir eine Schraube locker haben. Full ACK Der eine oder andere hat vielleicht im Platinenforum den Thread über die 'verrückteste Platine' gesehen. Ein Eintrag hat einen Link http://users.monash.edu.au/~ralphk/burroughs.html Ich hab mich spontan entschlossen, dass mein nächster ATMega-Rechner ein Frontpanel braucht :-)
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/cray1/portrait/index.html Beim Verkabeln: http://www.digibarn.com/collections/systems/crays/cray-book/ccw7.jpg http://www.digibarn.com/collections/systems/crays/cray-book/ccw9.jpg
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:
1 | ————————————————————————————————————————————————————————————————————— |
2 | "Produkt" Gewichtung > 0 Gewichtung = 0 |
3 | ————————————————————————————————————————————————————————————————————— |
4 | Web-Server im SO-6-Gehäuse Baugröße Speicherkapazität |
5 | Materialkosten Geschwindigkeit |
6 | |
7 | Soft-USB Baugröße Geschwindigkeit |
8 | Materialkosten Entwicklungsaufwand |
9 | |
10 | Oszi aus Schrottteilen Materialkosten Bandbreite |
11 | (alter Fernseher usw.) Messgenauigkeit |
12 | Entwicklungsaufwand |
13 | |
14 | Relaisrechner Restro-Aspekt Geschwindigkeit |
15 | Speicherkapazität |
16 | Entwicklungsaufwand |
17 | ————————————————————————————————————————————————————————————————————— |
Bei dem CP/M auf dem ATmega fehlt nach meinem Geschmack ein wenig dieser Optimierungsgedanke, da der Einsatz des ATmega im Vergleich zu einem Z80-kompatiblen Mikrocontroller bzgl. der o.g. Kriterien kaum Vorteile bringt. Vielleicht habe ich aber auch nur ein wichtiges Kriterium vergessen ;-) Ok, es gibt noch einen weiteren Aspekt, weswegen man ein Hobbyprojekt beginnt, nämlich der Lerneffekt bzw. Erkenntnisgewinn. Nur hätte ich Hemmungen, dafür so viel Zeit in ein Projekt zu stecken, wo ich vielleicht ähnlich viel in einem anderen Projekt lernen könnte, das weniger zeitaufwendig ist und/oder ein nützlicheres Ergebnis liefert. Aber die persönlichen Zielsetzungen sind eben verschieden. Deswegen läge mir nichts ferner, als jemandem dieses Projekt auszureden. Auf jeden Fall wünsche ich allen, die sich damit beschäftigen, viel Erfolg!
Hat jemand diesen CP/M Rechner mit einem stärkeren Atmega (z.B. Atmega 32) gebaut? Falls ja, stellt jener mal den Schaltplan Online? Und, falls dieser das auch noch auf Lochraster aufgebaut hat, hätte ich gerne einmal ein Foto :)
Ronny Minow schrieb: > Hat jemand diesen CP/M Rechner mit einem stärkeren Atmega (z.B. Atmega > 32) gebaut? Der ist ... ähm .... auch nicht grossartig anders. Und .... hmmm ... wie soll ich sagen .... ein Mega32 bringt dir bei diesem Projekt gar nichts. Der Hauptunterschied zwischen dem Mega88 und dem Mega32 besteht darin, dass der Mega32 mehr Flash hat. Nun ist dieses Projekt aber auf Flash gar nicht angewiesen. Flash ist mehr als genug brachliegend.
Karl heinz Buchegger schrieb: > Ronny Minow schrieb: >> Hat jemand diesen CP/M Rechner mit einem stärkeren Atmega (z.B. Atmega >> 32) gebaut? > > Der ist ... ähm .... auch nicht grossartig anders. > > Und .... hmmm ... wie soll ich sagen .... ein Mega32 bringt dir bei > diesem Projekt gar nichts. > Der Hauptunterschied zwischen dem Mega88 und dem Mega32 besteht darin, > dass der Mega32 mehr Flash hat. Nun ist dieses Projekt aber auf Flash > gar nicht angewiesen. Flash ist mehr als genug brachliegend. Zum Flash: Kann man den freien Flash für ein Dateisystem nutzen? Ich denke, der virtuelle CP/M / der Nutzer wird sich freuen wenn er ein paar Programme auf dem Flash ablegen kann. Und, afaik hat der Atmega32 etwas mehr Ram, als der Atmega88. Oder, bin ich da falsch informiert...?
Ronny Minow schrieb: > Und, afaik hat der Atmega32 etwas mehr Ram, als der Atmega88. Oder, bin > ich da falsch informiert...? Und was hast du davon? Für den simulierten Speicher ist das zu wenig und für den Simulator zu viel. Erst beim Mega162 und externem SRAM an Stelle des DRAM wird das interessant.
Yalu X. schrieb: > Gerade dieser selbstdefinierte Bewertungsmaßstab frei von den Vorgaben > irgendwelcher Marketingabteilungen und anderen externen Zwängen macht > den Reiz von RAPs aus. Warum soll ich mein Hobby so rational betrachten? Fast alle Hobbies sind rational betrachtet ziemlicher Blödsinn. Kosten nur Geld, kommt kaum was Sinnvolles bei rum. Ich betreibe mein Hobby #nur# weil es Spass macht. Ich kann nicht alles nur rational betrachten und jeder hat sicher irgendwo seinen Schwerpunkt bei Freizeitbeschäftigung, wo die Frage nach dem rationalen Sinn berechtigt ist.
A. K. schrieb: > Bei der Cray-1 ging das > nicht mehr. Dort sind die Kabel nach passender Verzögerungszeit > dimensioniert. Dementsprechend sieht es drin aus: Uff, echt beeindruckende Fotos.
A. K. schrieb: > Ronny Minow schrieb: > >> Und, afaik hat der Atmega32 etwas mehr Ram, als der Atmega88. Oder, bin >> ich da falsch informiert...? > > Und was hast du davon? Für den simulierten Speicher ist das zu wenig und > für den Simulator zu viel. Erst beim Mega162 und externem SRAM an Stelle > des DRAM wird das interessant. Den simulierten Speicher müsste man von 1KB auf 2KB, oder etwas dazwischen erweitern können... Was dem "zuviel Ram für den Simulator" selbst angeht, sag ich nur dazu das man mit dem Emulator nicht ganz so schnell an die grenzen stößt. Evtl. kann man im freien Ram noch ein Keyboard Treiber, oder auch ein VGA/ FBAS Treiber rein quetschen... Aber, das müsste mal jemand testen der etwas mehr Erfahrung im Umgang mit den Atmega µC's hat...
Ronny Minow schrieb: > Den simulierten Speicher müsste man von 1KB auf 2KB, oder etwas > dazwischen erweitern können... Der ist sowieso schon 128KB gross (256Kx4). Das SRAM im Controller wird offenbar nur für den Stack des Simulators und als SD-Card Puffer (512B) verwendet, da sind also noch >>400B Luft.
A. K. schrieb: > Ronny Minow schrieb: > >> Den simulierten Speicher müsste man von 1KB auf 2KB, oder etwas >> dazwischen erweitern können... > > Der ist sowieso schon 128KB gross (256Kx4). Das SRAM im Controller wird > offenbar nur für den Stack des Simulators und als SD-Card Puffer (512B) > verwendet, da sind also noch >>400B Luft. Hmmm... Bei den verbleibenden ca. 400b kann man wohl nur ein Keyboard Treiber (für PS2) und einen einfachen FBAS + Zeichengenerator einsetzen. Wobei es da aber sicherlich sehr eng mit dem freien Ram wird...
Ronny Minow schrieb: > Hmmm... Bei den verbleibenden ca. 400b kann man wohl nur ein Keyboard > Treiber (für PS2) und einen einfachen FBAS + Zeichengenerator einsetzen. > Wobei es da aber sicherlich sehr eng mit dem freien Ram wird... Jetzt muss ich mal nachfragen. Hast du schon einmal ein Programm für einen MegaXX (egal welcher) geschrieben. Mir scheint dir ist überhaupt nicht klar, dass Flash und SRAM 2 Paar Schuhe sind. Programme stehen im Flash Daten stehen im SRAM Ein Keyboarddriver ist ganz klar ein Programm, kommt also ins Flash (sofern er nicht von der virtuellen Z80 abgearbeitet wird, aber so dämlich wird ja dann doch wohl keiner sein) Und ja, es gibt eine Ausnahme: Daten die sich nicht ändern, also als Konstante anzusehen sind, kann man auch im Flash parken.
Karl heinz Buchegger schrieb: > Ronny Minow schrieb: > >> Hmmm... Bei den verbleibenden ca. 400b kann man wohl nur ein Keyboard >> Treiber (für PS2) und einen einfachen FBAS + Zeichengenerator einsetzen. >> Wobei es da aber sicherlich sehr eng mit dem freien Ram wird... > > Jetzt muss ich mal nachfragen. > Hast du schon einmal ein Programm für einen MegaXX (egal welcher) > geschrieben. Für einem MegaXX noch nicht, da liegt Dein Verdacht richtig. > Mir scheint dir ist überhaupt nicht klar, dass Flash und SRAM 2 Paar > Schuhe sind. Ich muss sicherlich noch vieles lernen. Aber, der Unterschied ist mir schon bekannt. > Programme stehen im Flash > Daten stehen im SRAM > > Ein Keyboarddriver ist ganz klar ein Programm, kommt also ins Flash > (sofern er nicht von der virtuellen Z80 abgearbeitet wird, aber so > dämlich wird ja dann doch wohl keiner sein) Mir ging es darum, das der Treiber ja irgendwo her seine Daten bekommen muss, die dieser zu verarbeiten hat. Ein Zeichenpuffer für, sagen wir 20 Zeichen + evtl. benötigte "Meta" Codes (Alt, Shift usw.) finde ich sehr Hilfreich. Das ganze nimmt schon ein paar Bytes vom freiem Ram weg. Die Codetable kann man ja im Flash ablegen, da sie ja nur einmalig erzeugt wird. Die visuelle Ausgabe, per FBAS, VGA or whatever, braucht dagegen schon einige Bytes an Ram... Der Treiber muss sich ja zur Laufzeit die auszugebenen Daten aus dem Ram holen.... Ok, vieleicht ist meine Denkweise aber auch im Grundsatz falsch. Falls ja, korrigiert mich :)
Ronny Minow schrieb: > Mir ging es darum, das der Treiber ja irgendwo her seine Daten bekommen > muss, die dieser zu verarbeiten hat. Ein Zeichenpuffer für, sagen wir 20 > Zeichen + evtl. benötigte "Meta" Codes (Alt, Shift usw.) finde ich sehr > Hilfreich. OK. 20 Bytes benötigt - 400 Bytes SRAM frei 20 Bytes benötigt - 400 Bytes SRAM frei was sagt uns das? > Die visuelle Ausgabe, per FBAS, VGA or whatever, braucht dagegen schon > einige Bytes an Ram... Der Treiber muss sich ja zur Laufzeit die > auszugebenen Daten aus dem Ram holen.... Ähm. Der Mega ist auch so schon mit der Z80 Emulation ausgelastet. Willst du dem wirklich noch die Generierung eines Videosignals aufhalsen?
Kalle Schrob: > Ähm. > Der Mega ist auch so schon mit der Z80 Emulation ausgelastet. Willst du > dem wirklich noch die Generierung eines Videosignals aufhalsen? Nunja, er hat's noch nicht gemacht und kann es noch nicht beurteilen. Sei also nicht so streng... ;-)
Na schön, das hier doch einiges an Interesse ist.. ;-) (Auch - oder gerade weil wir ein Rad abhaben) Oder wie schon im deutschen Liedgut steht, wer nicht verrückt ist, der ist nicht normal.. --- Nun jeder ist ja relativ frei, das Projekt zu erweitern.. ist ja GPL3.. Für mich persönlich, ist die serielle+VT100 Anbindung völlig ok.. PS/2+BAS sind mir nicht so wichtig.. wenn es aber doch jemand macht. prima! Wichtiger wäre zuerst einmal ein Ausbau der unterstützen Opcodes.. Wenn da mal auch mehr/Z80 Programme laufen etc.. mache ich auch gerne ein Platinen-Layout mit Eagle ;-) Oder ganz abgefahren in SMD mit Micro-SD in Streichholzschachtelgröße. ;-) Peter
Peter Sieg schrieb: > Na schön, das hier doch einiges an Interesse ist.. ;-) > (Auch - oder gerade weil wir ein Rad abhaben) > Oder wie schon im deutschen Liedgut steht, wer nicht verrückt ist, der > ist > nicht normal.. Ganz Deiner Meinung :) > > --- > > Nun jeder ist ja relativ frei, das Projekt zu erweitern.. ist ja GPL3.. > Für mich persönlich, ist die serielle+VT100 Anbindung völlig ok.. > PS/2+BAS > sind mir nicht so wichtig.. wenn es aber doch jemand macht. prima! Daran kann ich ja mal etwas basteln.... > > Wichtiger wäre zuerst einmal ein Ausbau der unterstützen Opcodes.. Man sollte erstmal testen, welche CP/M Software bereits läuft. Fehlen Funktionen bzw. OpCodes, kann man diese sicher immer noch nachrüsten... > > Wenn da mal auch mehr/Z80 Programme laufen etc.. mache ich auch gerne > ein > Platinen-Layout mit Eagle ;-) Oder ganz abgefahren in SMD mit Micro-SD > in > Streichholzschachtelgröße. ;-) > > Peter Ich würde eher ein Board nehmen, was man "auf dem Küchentisch" aufbauen kann. Ähnlich den Hive - Retrostyle Computer Projekt ( http://hive-project.de/ ) ... --- Ich baue das Board gerade, mit LochMaster 3.0, vituel auf. Wer Shots oder auch die Dateien aus LochMaster haben mag, einfach melden :) Ach ja, ich benutze einen Atmega32 für den virtuellen Aufbau....
Hmm, eventuell wäre es auch sinnvoll eine PDP-11 zu emulieren. Die Betriebssysteme darauf wurden im Quellcode ausgeliefert, und es gab viel Software dafür.
Ich wollte knur kurz den Thread wieder nach oben bringen. Nebenbei finde ich das ein wirklich schönes Projekt, was ich bei nächster Gelegenheit testen und erweitern möchte. Wenn man einen zweiten AVR für Tastatur und Video-Output nimmt, dann hat man ein schönes System. Gruß, SIGINT
@SIGNINT: Prima! Inzwischen kann ich das diskimage unter win32 ändern.. Habe auch ein othello gefunden, das läuft. Und ein mbasic für 8080. Läuft zwar, aber Sprungziele werden beim load zu 00000?? Wird der z80.asm unter AVR Studio assembliert? Wollte mal versuchen, von 20 auf 32MHz umzustellen.. dazu muß ich sicher die Geschwindigkeit der RS232 Schnittstelle umstellen..? Peter
Peter Sieg schrieb: > @SIGNINT: Prima! Inzwischen kann ich das diskimage unter win32 ändern.. > Habe auch ein othello gefunden, das läuft. Und ein mbasic für 8080. > Läuft zwar, aber Sprungziele werden beim load zu 00000?? Wenn du diese Emulation benutzt: Es sind noch nicht alle Opcodes des Z80 unterstützt. Speziell die CB und ED Schiene ist noch gar nicht vorhanden. Und ob bei den implementierten Opcodes die Status Flags überall richtig nachgezogen werden, hab ich nicht näher untersucht.
Angehängte Dateien:
-
avrcpm_eagle.png
8,2 KB
Jup. Bin leider auch kein 8080/Z80 Kenner.. da müßte ich mich erst einarbeiten.. nun, zumindest kann ich den Quelltext mit AVR Studio 4 assemblieren (dabei auch gleich die Baudrate kalkulieren lassen..) und das Ergebnis läuft.. Werde das mal mit ATmega88PA und 32MHz anstatt 20MHz probieren.. dabei sollte auch der DRam Refresh weiter runter können.. mal schauen, wie viel 'Geschwindigkeit' das bringt.. Dann wäre da auch noch die Frage, warum das Nibble an D0-D3 nicht auch ein Nibble an einem Port ist.. Nun Ja.. zu allem 'Überfluß' hier auch noch ein Platinenlayout ;-) Peter
Ich habe mir den Code mal angesehen und denke, dass die DRAM-Anbindung zwar recht minimalistisch, dafür aber auch arg langsam ist. Grob geschätzt komme ich z.B. auf über 160 Takte bei der dram_read Routine. Wenn man einen 40-poligen Controller (z.B. Meag16) und zwei DRAMs nimmt, D0-D7 an Port A, A0-A7 an Port C und die Steuersignale an Port D, sollte das wesentlich schneller gehen. Letztendlich müssen nur die entsprechenden Routinen ausgetauscht werden. Ein Beispiel wäre:
1 | dram_read: cli ;1 disable interrupt |
2 | ldi ZL,0x7F ;1 RAS |
3 | ldi ZH,0x1F ;1 RAS + CAS + OE |
4 | out PORTC,adrh ;1 |
5 | out PORTD,ZL ;1 RAS active |
6 | out PORTC,adrl ;1 |
7 | out PORTD,ZH ;1 RAS + CAS + OE active |
8 | ldi ZL,0x9F ;1 RAS inactive |
9 | out PORTD,ZL ;1 CAS + OE (hidden refresh) |
10 | in temp,PINA ;1 get data |
11 | out PORTD,ZH ;1 RAS + CAS + OE |
12 | ldi ZH,0xFF ;1 |
13 | out PORTD,ZL ;1 only RAS |
14 | out PORTD,ZH ;1 inhibit |
15 | sei ;1 enable interrupt |
16 | ret ;4 end |
Bringt Beschleunigung um etwa Faktor 7 beim Lesen aus dem Speicher. Jörg
Hi Jörg. Das wäre super! Da meine Kenntnisse in AVR Assembler eigendlich nicht vorhanden sind ;-) bleibe ich vorerst einmal beim aktuellen Aufbau. Hier möchte ich noch mal die Takterhöhung auf 32MHz und die Reduzierung des DRam-Refreshs probieren. Und der Warmstart muß auch überarbeitet werden (hängt einfach). Inzwischen kann ich diskimage unter win32 mit den cpmtools ändern und mit BDS-C übersetzte Programme laufen auch unter avr-cpm ;-) Zu einem anderen Aufbau sehe ich das aber letztlich genauso.. was ein 'fauler' Kompromiss ist und viel Rechenpower kostet muß durch etwas besseres ersetzt werden.. Da kann man beim Ram auch z.B über SRAM nachdenken.. dann braucht man keinen Refresh mehr.. Wäre super, wenn hier genügend zusammen kommen, um daraus einen kleinen, schnuckeligen und brauchbaren CP/M Rechner zu basteln.. Peter
@ Peter Sieg: Ich habe mir Dein Projekt auf Deiner Homepage angesehen. Als erstes: Das ist ein sehr interissantes Projekt. Nicht zuletzt deshalb, weil mir CP/M eigendlich unbekannt ist. Das soll mich aber nicht daran Hindern, Dein Projekt aufzubauen und mit zu Entwickeln. Was mir für den Aufbau fehlt, ist ein Z80 Assembler. Wenn ich das Paket zum erstellen der Image Disk richtig verstehe, brauche ich diesem um die Software entsprechend übersetzen zu können. Wo bekomme ich diesem Assembler her...? @Joerg Wolfram: Du hattest einmal einen einfachen Basic Computer mit einem Atmega8/88 aufgebaut. Könnte man die Umgebung für den TV Out/ FBAS, sowie den PS2 Controller an den CP/M Rechner anbringen? Falls notwendig, über einen 2. Atmega8...
Sowas gibt es auch mit dem Propeller: http://forums.parallax.com/forums/default.aspx?f=25&m=332138 TV, VGA, PS/2, SD-Karte, ... mit CPM2.2 oder MPM Der Minimal-Aufbau ist für unter 30 Euro zu machen, wenn man alle Teile kaufen muss. Das einfachste Board, wäre ein abgespecktes Dracbalde (nur RAM, PS/2 und VGA/TV, SD, keine weiteren IOs usw.)
kruemeltee schrieb: > Sowas gibt es auch mit dem Propeller: > > http://forums.parallax.com/forums/default.aspx?f=25&m=332138 > > TV, VGA, PS/2, SD-Karte, ... mit CPM2.2 oder MPM > > Der Minimal-Aufbau ist für unter 30 Euro zu machen, wenn man *alle* > Teile kaufen muss. > > Das einfachste Board, wäre ein abgespecktes Dracbalde (nur RAM, PS/2 und > VGA/TV, SD, keine weiteren IOs usw.) Auch, wenn der Propeller µC schon klasse ist, so denke ich sollten wir den Atmega µC verwenden. Ich selbst habe ein Hive -Retrosytle Computer, der 3 Propeller µC's verwendet. Der Hive ist ein Klasse Computer. Man kann sicher auch CP/M drauf laufen lassen, was auch in Entwicklung ist. Hier geht es aber um CP/M für den Atmega, nicht für den Propeller µC. --- @Peter Sieg: Welche Software hast Du schon auf dem Projekt zum leben erwecken können?
Joerg Wolfram schrieb: > Wenn man einen 40-poligen Controller (z.B. Meag16) und zwei DRAMs nimmt Vielleicht könnte man einen AVR 8515 oder 8535 nehmen, die haben ein SRAM-Interface.
bix schrieb: > Vielleicht könnte man einen AVR 8515 oder 8535 nehmen, die haben ein > SRAM-Interface. Soweit ich das überblicke: 8515 ja, 8535 nein. Ist der 8515 eigentlich der einzige mit SRAM-Interface? In der Vergleichstabelle von Atmel ist selbiges leider nicht aufgeführt. frank
@Ronny Minor: Habe ein paar Spiele, die laufen: Mastermind, TicTacToe, Othello, Stone.. kommt ggf. noch Packman mit VT52 Steuerung dazu.. evtl. noch 4-gewinnt.. Peter
frank schrieb: > Ist der 8515 eigentlich der einzige mit SRAM-Interface? In der > Vergleichstabelle von Atmel ist selbiges leider nicht aufgeführt. > frank Der ATmega162 hat "Up to 64K Bytes Optional External Memory Space" Gruß Roland
Peter Sieg schrieb: > @Ronny Minor: Habe ein paar Spiele, die laufen: Mastermind, TicTacToe, > Othello, Stone.. kommt ggf. noch Packman mit VT52 Steuerung dazu.. evtl. > noch 4-gewinnt.. > > Peter Einige Spiele sind schon einmal ein Anfang. Wie sieht es mit typischer CP/M Software aus? Läuft z.B. DBase (gab es das für CP/M überhaupt...?) ? --- Wer hat diesem Computer schon aufgebaut? Ach ja, gibt es schon Ideen für ein Video Ausgang? Oder anders: könnte man an Herrn Wolframs Basic Computer mit Atmega8/88 den DRAM drann hängen und somit eine Symbiose aus beiden Computern machen?
... Auch, wenn der Propeller µC schon klasse ist, so denke ich sollten wir den Atmega µC verwenden. ... Warum nicht gleich eine Zuse 3 (fröhlich klappern die Postrelais)? Warum überhaupt so etwas einfaches wie DRAM? 64 KByte als Magnetkernspeicher - das nenne ich eine Aufgabe?
CPM-Gerümpelrechner schrieb: > Warum nicht gleich eine Zuse 3 (fröhlich klappern die Postrelais)? Warum > überhaupt so etwas einfaches wie DRAM? 64 KByte als Magnetkernspeicher > - das nenne ich eine Aufgabe? Hast Du eine Z3 gebaut? Wenn ja, zeig mal her :)
@Ronny Minow: dbase gibt es für CP/M.. Generell gilt vorerst: NUR 8080 CPU - d.h Programme, die unter CP/M-80 laufen haben gute Changen.. Aber: Die Emulation hat SICHER noch Fehler! Z.B MBASIC4.5 für CPM-80 läuft ersteinmal.. Interaktiv, also z.B print 2+4 (=6) geht.. aber Programmlauf geht nicht, weil alle Variablen zu 00000 evaluieren.. keine Ahnung warum! Im AltairSIMH Emulator mit Z80 CPU ist alles ok.. Die vielen anderen Basic Versionen habe ich noch nicht getestet.. Es gibt generell sehr viel alte Software für CP/M-80.. http://www.z80.eu/ http://www.retroarchive.org/cpm/ Deswegen wäre/ist meine Prämisse: 1. Noch weitere Basic Interpreter testen 2. Noch eine paar weitere Spiele compilieren mit BDS-C 3. Warmstart implementieren (hängt da aktuell einfach) 4. Das ganze mal mit 32MHz laufen lassen (88PA) 5. 8080 Code prüfen und ggf. Fehler beseitigen --- 6. Evtl. andere Hardware mit 8-bit SRam etc. etc 7. Z80 Opcodes implementieren Generell denke ich reicht es mir, wenn ich 1-5 erreicht habe.. bin aber allen Neuentwicklungen/Verbesserungen offen gegenüber.. kann man/das Projekt ja nur von profitieren.. --- Bezüglich des benutzten z80asm.. keine Ahnung, welcher das ist. Da sollte man den Entwickler: Sprite_TM fragen.. ich würde den gerne auch unter win32 haben.. bisher ändere ich das vorhandenen diskimage mit cpmrm und cpmcp.. Peter
@Peter Sieg: Danke für die Links. Ich habe mich da mal umgesehen. Wenn ich dazu komme, werde ich mal "Tiny C", "Pascal" und einen Assembler auf dem Computer laufen lassen. Aber, ersteinmal muss ich den zusammen löten. Die Bauteile hierfür dürften in einigen Tagen bei mir sein. Ach ja, thx für das Pin Layout des SRam's, das Du auf Deiner Homepage veröffendlicht hast.
Roland F. schrieb: > Der ATmega162 hat "Up to 64K Bytes Optional External Memory Space" Das Interface wäre sogar richtig schnell. Jedoch gibts Probleme mit dem untersten Kilobyte.
Christian Berger schrieb: > Das Interface wäre sogar richtig schnell. Jedoch gibts Probleme mit dem > untersten Kilobyte. Stets 1K draufaddieren und das oberste KB nicht verwenden.
Christian Berger schrieb: > Dann hat man allerdings Probleme mit dem obersten Kilobyte. :) Wer definiert, dass es dies geben muss? Unten weglassen geht bei 8080/Z80 nicht, oben schon.
Ich weiß, das ist verrückt ;-) Ich denke ernsthaft darüber nach 10 Platinen anfertigen zu lassen ;-) Aus dem forum64 gibts zumindest schon einmal noch 2 Interessenten außer mir.. da ich auch mind. 2 für mich nehme wären es schon 4.. wenn wir noch ein paar finden könnte das wirklich klappen.. unter 10 macht es keinen Sinn.. ich rechne mit ca. 9-10€/Platine. SD Slot kostet 3€. Versand ca. 1,50€ (Post). Natürlich kann man das auch auf LR aufbauen.. aber mir fertiger Platine wird es doch ein wenig einfacher (ist durchkontaktiert mit Lötstopp). Ach ja, Platine siehe weiter oben.. RS232 Wandler will ich nicht drauf haben. Und 3,3V Netzteile gibts bei Pollin.. Peter
Da ist doch Platz für einen Regler drauf - dann könnte man auf vorhandene Wandwarzen zurückgreifen...
@Peter: Lohnt es sich für so eine kleine Schaltung eine Platine fertigen zu lassen?!? Ich fände es besser erst ein vollständiges System, mit IO-Hardware (TV-Out, Keyboard, Sound?!, etc.) zu entwickeln und dann die Platinen fertigen zu lassen. Ich glaube, die meisten würden gerne einen kompletten CP/M Rechner haben, den man ohne externe Hardware betreiben kann. Ich hab schon ein paar Ideen, was man mit dem System machen könnte: Portieren eines AVR-Assemblers auf CP/M-80 CP/M-80 Software zum flashen von AVRs Grafik-LCD am System anbinden mehrer Diskettenimages auf SD-Karte einfache Soundausgabe per PWM (DMA,IRQ?!) Mir ist klar, daß dies noch viel Arbeit ist, aber ich Glaube es könnte sich lohnen. Ich hab schonmal angefangen auf dem PC einen kleinen Z80-Emulator zu basteln, um mich in CP/M ein zu arbeiten. Leider funktioniert das aber noch nicht so, wie ich es möchte. Gruß, SIGINT
@SIGINT: Nun, eine 10ner Auflage der aktuellen Hardware steht einer späteren Auflage eines erweiterten Systems ja nicht im Wege.. (Ich bin nun mal Minimalist ;-) ) Schau doch mal, ob Jörg Wolfram auch noch Interesse hat an einer Erweiterung zum vollwertigen CP/M Rechner mitzuarbeiten.. Evtl. finden sich hier weitere Mitstreiter.. kann man die Entwicklung ggf. aufteilen.. Wäre wirklich super, wenn das klappt! Als Emulator schau mal bitte nach AltairSIMH. Läuft bei mir prima.. Hänge ich hier mal an.. einfach entpacken und Altairall.bat starten. Laufwerk A: ist CP/M 2.2 Laufwerk B: ist MBasic Laufwerk C: ist BDS-C compiler Mit R/W lassen sich Dateien vom Hostsystem nach CP/M transferieren. Peter
Es ist wahrscheinlich sinnvoller, eines der in der Codesammlung vorhandenen AVR-Terminals zu benutzen. Die haben eigentlich alle eine höhere Auflösung als das ChipBasic und die serielle Ansteuerung ist auch schon fertig. Ich halte das Ganze für ein recht interessantes Projekt, allerdings geht für mich der praktische Nutzen gegen Null. Wobei ich heutzutage auch kein Projekt mehr anfangen würde, welches nur TV als Ausgabemedium hat. Schon beim ChipBasic mit seiner doch recht groben Auflöung sind bei neueren TVs durch die ganze Samplinggeschichte die Pixel unterschiedlich breit und auch teilweise unterschiedlich hoch wahrscheinlich werden die Bilddaten 4:2:2 gespeichert). Eine probeweise Darstellung von 80 Zeichen (480 Pixel bei 10MHz Pixeltakt) ist auf einem guten Analoggerät noch lesbar, aber schon auf einem 100Hz Fernseher einfach eine Zumutung (zumindest meinem Eindruck nach). Jörg
Angehängte Dateien:
-
AVR_CPM.png
12 KB
Hallo, nettes Projekt, Danke Peter! Ich habe mal Peters Idee aufgegriffen, seine Schaltung leicht erweitert und ein Layout dazu erstellt. Vielleicht findest es ja Gefallen. 1. Die Jumper TTL, Reset und 3.3 V behalten vollständig ihre Pinbelegung und Funktion 2. Die Kommunikation (RS232) ist auf eine USB-Schnittstelle gelegt. 3. Die Stromversorgung (5V und 3.3V) erfolgt über die USB-Schnittstelle 4. Steckverbinder zur ISP-Programmierung des AVR hinzugefügt. 5. Mit dem Jumper POWER Switch kann wahlweise zwischen 5V und 3.3V umgesteckt werden (Vorsicht CF-Card ziehen!) 6. Mit dem Jumper CLOCK Switch kann der AVR Takt über den USB Controller bezogen werden. Hier sind 6, 12, 24 oder 48 MHz möglich. Weitere Ideen oder Vorschläge nehme ich gerne auf. Joe
Hallo Joe. Deine Ideen finde ich prima! Für mich ist wichtig, das die Jumper Header (TTL Seriell) so bleiben, damit meine Kabel direkt passen.. Aber der FT232RL ist ja optional..und eine gute Idee. Stromversorgung über USB Buchse ist auch eine gute Idee.. aber woher kommen die 3,3V.. oder habe ich da einen Regler übersehen..? ATmega88+Dram+SD Card sollte über 3,3V versorgt werden.. ich vermute FT232RL benötigt 5V (und bekommt die ja auch direkt über die USB Buchse) und kann 3,3V TTL Pegel an Rx+Tx ab.. ich hoffe der AVR kann allerdings auch +5V ab, obwohl er mit 3,3V versorgt wird..? Programmierung auf der Platine ist ebenfalls eine gute Idee (wenn ich auch immer 6-Pol Header verwende ;-) ) Wozu ist D2 1N4148 da? Wir funktioniert die optionale Taktgenerierung über den FT232RL? Wie gesagt, wenn das Ganze auch ohne FT232RL Bstückung läuft und man die 3,3V aus dem USB Anschluß erzeugen kann, können wir gerne deine Platine bestellen, da sie nur 10mm breiter ist.. Im Forum64 gibt zumindest auch schon mal Interesse an 3 Platinen.. hier gab es auch Interesse an 1-2 Platinen und ich nehme 2.. langsam kommen wir auf die benötigten 10 ;-) Peter
Hallo ich finde die Idee akademisch sehr amüsant. Nur wer hier wirklich CP/M machen will ( es ist in den 80ern wirklich super gewesen ) sollte sich auch mal den ez80 anschauen. Man spart sich die Emulation, ist ein Nachfolger des Z80 und sehr viel schneller. CP/M war mein erstes richtiges Betriebssystem auf dem ich Megabytes an Sourcecode unter Turbopascal erstellt habe, aber es gibt heute bessere Systeme. Es gibt sicherlich noch viele Geräte die im Hintergrund mit CP/M laufen, aber es gibt eigentlich ausser nostalgischen Gründen für mich kein Argument jetzt noch CP/M zu implementieren.
Peter Sieg schrieb: > aber woher kommen die 3,3V. Im FTDI steckt ein 3,3V-Regler. Mich würde die Platine auch interessieren.
karadur schrieb: > aber es gibt heute bessere Systeme Aber klar doch. Nur sind die auch noch so übersichtlich, wie CPM?
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
@Peter Sieg: Du kannst zu meiner Platinenreservierung (+ SRam usw.) eine dazu legen. Dann sind es 8 Platinen.
@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
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.
Angehängte Dateien:
-
AVR_CPM.png
8 KB
@Peter: 6-polige Programmierbuchse eingesetzt Resettaster eingefügt Ja, Du hast es richtig verstanden mit den 3.3V und dem TTL Header. @Uhu: Mir fällt keine so richtig einfache Schaltung ein die 5V auf der 3.3V Leitung zu erkennen. Möglich ist die Differenz zwischen 5V und 3.3V zu nutzen (1.7V) Eine rote LED sollte dann leuchten. Die Funktion wäre aber invers, sie leuchtet wenn 3.3V anliegen und nicht wenn 5V anliegen. Prinzipiell: Der AVR verträgt laut Datenblatt 1.8 - 5.5V also kein Problem. Die SD-Cad nur 3.3V also beim Flashen ziehen! Der DRAM 3.3V oder 5V Volt ja nach Type, ein 5V Type wird also außerhalb seiner Spezifikation betrieben. Anbei das geänderte Layout bzw. die Schaltung nochmal zur Durchsicht. Joe
@Peter Sieg & Joe G.: Falls möglich, verwendet bitte 512x8 SRam's. Diese lassen sich bei reichelt bestellen... Bei 256x8 SRam's sieht es da schwieriger aus. Und, diese kann wohl nur noch auf alten Mainboards finden... Ich jedenfalls habe weder bei CSD noch bei reichelt passende SRam's gefunden... Oder, kennt jemand eine andere Quelle, die an Privat liefert...?
karadur schrieb: > auch mal den ez80 anschauen. Man spart sich die Emulation, ist ein > Nachfolger des Z80 und sehr viel schneller. Hallo, ganz so einfach ist es nach meiner Erfahrung leider nicht, z.B. funktionieren die I/O-Befehle i.A. nicht mehr, weil der eZ80 Ports mit 16 Bit Adressen anspricht, und für die Adressierung der Ports von 0..255 gibt es neue Opcodes und ausserdem kollidieren sie mit der internen Peripherie, im Bereich "HAL" muss man also modifizieren. Da ich in der Hochsprache ohnehin keine direkten I/Os verwendet habe, müssen bei mir nur die Zugriffe in Assembler geändert werden. Einfacher als neu schreiben ist es aber schon. Interessant wäre es, bei einem Paging-System das Paging auf die eingebauten eZ80-Funktionen umzustellen und den Rest mit wenigen Änderungen zu übernehmen. Dann stehen immerhin maximal 256 Pages a 64k zur Verfügung. Allerdings ist auch da u.U. ein Trick nötig: CP/M u.ä. Systeme setzen Speichermodelle voraus mit Programm und Daten innerhalb 64k (wie sollten sie das auch besser wissen), der eZ80 kann aber nur ganze Seiten einblenden, um also Rom und Ram oder verschiedene RAM-Bereiche innerhalb 64k abzubilden, braucht man noch etwas externe Hardware. Gruss Reinhard
Joe G. schrieb: > Mir fällt keine so richtig einfache Schaltung ein die 5V auf der 3.3V > Leitung zu erkennen. Was spricht gegen eine ZF3,3, einen Widerstand und eine rote LED?
@Ronny Minow: Es geht hier ersteinmal darum, die Schaltung grundsätzlich NICHT zu ändern. Und ein 256x4 Dram gegen ein 256x8 Sram zu tauschen wäre eine solche Änderung.. sowas muß warten bis die anderen Ideen hier ggf. eine geänderte Schaltung hervorbringen. Ein 256x4 Dram kann ich ggf. mitliefern. Peter
Peter Sieg schrieb: > @Ronny Minow: Es geht hier ersteinmal darum, die Schaltung grundsätzlich > NICHT zu ändern. Und ein 256x4 Dram gegen ein 256x8 Sram zu tauschen > wäre > eine solche Änderung.. sowas muß warten bis die anderen Ideen hier ggf. > eine > geänderte Schaltung hervorbringen. Ein 256x4 Dram kann ich ggf. > mitliefern. > > Peter Oki, kannst Du auch einen vorprogrammierten Atmega88 beilegen? Falls nicht, auch nicht schlimm. Die fehlenden Bauteile werde ich mir dann noch kaufen. Eine Quelle für den DRam Chip habe ich aber nicht gefunden...Melde Dich, wenn Du die Platinen hast und die Sachen zum Versand vorbereitest.
@Ronny Minow: So funktioniert das garantiert nicht :-) WENN wir uns hier auf eine Platinenversion geeinigt haben (sieht so aus..) und ich mich entscheide, das es losgeht (bald), erst DANN kann mir jeder Interessent seine Addresse per Mail senden und bekommt dafür von mir meine BV. ERST wenn alle bezahlt haben (VORKASSE), DANN bestelle ich die Platinen, denn ich muß auch Vorkasse leisten... Also eins nach dem anderen.. Peter
> Und: etwas was ich sehr vermisse. Dank Epromfloppy war der Rechner > schneller gestartet als das die Bildröhre warm war. Schön. das zu hören. Wenn es die aus der c't für den ECB-Bus war, dann war sie von mir. Studienarbeit 1982/83 oder so. Habe noch ein Exemplar hier liegen mit 2764, also damals um die 1000 DM.
>@Ronny Minow: Es geht hier ersteinmal darum, die Schaltung grundsätzlich >NICHT zu ändern. Und ein 256x4 Dram gegen ein 256x8 Sram zu tauschen >wäre Ich begreife es nicht, denn die D-RAM Ansteuerung ist wesentlich komplizierter. Ein Atmel hat doch wohl keine Refresh-Generierung wie ein Z-80 System. Dies hat ja auch 8-Bit Refresh, was die 256x4 wohl nicht haben. Sie haben nur 7-Bit Refresh. S-RAM sind doch heute in jeder Größe verfügbar, nicht wie früher.
@ Andy H. war die Schaltung aus der c't. Läuft immer noch. Zusammen mit der 1MByte Ramfloppy.
@Michael_ : Ganz einfach: Mache einen LR Aufbau mit SRAM und ändere die AVR Firmware so ab, das alles mind. so gut/aber schneller funktioniert wie jetzt und stelle uns dein geändertes Projekt inkl. Schaltplan und Firmware-Source hier zur Verfügung. - Dann reden wir weiter - ok! Peter
karadur schrieb: > @ Andy H. > > war die Schaltung aus der c't. Läuft immer noch. Zusammen mit der 1MByte > Ramfloppy. Super, freut mich wirklich zu hören, die RAM-Floppy war von meinem Assi!
@alle: Also: Joe G. hier aus dem Forum wird die Platinenbestellung übernehmen. Wir haben uns diesbezüglich schon abgestimmt. Redaktionsschluß für Änderungen an der Platinen ist Sonntag, der 6.6 18Uhr MEZ. Verbindliche Bestellungen für Platinen (und ggf. SD Slots) sind bis zum Sonntag, den 13.6 18Uhr MEZ möglich. Danach erfolgt die Bestellung. Generell gilt für DIESE Platinenbestellung, das ursprüngliche Hardwaredesign (ATmega88, 256kx4 Dram, SD Card) bleibt unverändert! An Kosten ist mit etwa 10€/Platine zu rechnen (2-lagig, durchkontaktiert, Lötstoplack). SD Slot etwa 3€/Stück. Wenn mehrere DRam's benötigt werden.. könnte ich diese Joe zusenden, der sie dann mit der Bestellung verteilen kann..(Kosten 1€/Stück - Verrechnung mit meiner Platinenbestellung bei Joe)..? Weitere Details zur Abwicklung von Joe G. (feinmechaniker)... Peter
Wie ich Peter schon im Forum64 geschrieben habe, bin ich an einer Platine und den SD-Slot interessiert. Die restlichen Teile (AVR und dRAM) habe ich selbst. Jörg
Also interesse an einer Platine hätte ich ebenfalls. Bräuchte dann den SD-Karten Slot, sowie das DRAM. Den Rest werd ich mir so zusammenbestellen können denke ich.
Warum übergebt Ihr die Platine nicht einfach einem kleinen Online-Shop. Der soll dann 10€ drauf schlagen, dafür ist es aber mit der ganzen Bestellerei einfacher.
@Markus: Mit dd.exe für win32 ;-) Wenn du dir von hier: http://avr.cwsurf (dot) de/ -> AVR CP/M die cpmtools.zip ziehst, hast du nicht nur dd.exe, sondern auch die cpmtools um das diskimage unter Windows zu verändern (genauer: Programme löschen, hinzufügen, listen). Peter
@Ronny Minow: Denkst du nicht, das diese Frage besser von Joe beantwortet werden sollte.. ;-) Peter
@alle: Wie Peter schon in beiden Foren geschrieben hat, nehme ich die Bestellungen für die AVR CP/M Platinen entgegen. Dazu bitte Eure benötigte Stückzahl, Eure Mailadresse sowie die Versandadresse über „Feinmechaniker“ an mich senden. Weiterhin würde ich die notwendigen SD-Card Sockel mitbestellen. Wer DRAM’s benötigt ebenfalls kurze Info an mich. Es sind noch welche in geringer Stückzahl zu haben. Hier gilt – Verteilung nach Bestelleingang. Jede Bestellung erhält von mir eine kurze Bestätigung über den Eingang. (Wer schon bestellt hat, bitte nicht noch mal wiederholen.) Wenn die Bestätigung nicht sofort erfolgt, etwas Geduld, ich vergesse schon niemanden. Um die angekündigten Preise zu halten müssen mindestens 10 Platinen zusammenkommen. In diesem Fall liegt der Preis einer Platine (zweiseitig, durchkontaktiert, Lötstoplack) bei ca. 10 € netto. Ein SD-Card Sockel kostet 2.95€ und ein DRAM 1€. Dazu kommen noch 1,65€ für die Warensendung bzw. die Kosten für die Versandtasche. Eine genaue Kalkulation gibt es nach dem Bestelleingangsende, da erst dann der Leiterplattenpreis genau kalkuliert werden kann. Bis Sonntag 18 Uhr nehme ich noch Fehlerkorrekturen, Änderungsvorschläge, Verbesserungen der Schaltung auf. Wie Peter schon geschrieben hat gilt jedoch das Hardwaregrunddesign (ATmega88, 256kx4 DRAM, SD Card). Ziel ist zunächst die Softwareentwicklung. Wer gleich mit einem SRAM arbeiten möchte, kann ihn ja über eine Lochrasterplatine auf die DRAM Fassung stecken. Adress-, Daten- und Steuerpins liegen an, der Rest ist NUR Softwareanpassung :-). Bestellungen nehme ich bis Sonntag den 13.6 entgegen. Am 14.6 löse ich die Bestellungen dann aus. Die Lieferzeit für die Platinen beträgt im Normalfall 8 AT, also bitte nicht schon früher drängeln. Joe
Das Funktioniert nicht wirklich zufrieden stellend mit einer Z-Diode und einer LED. Die Exemplarstreuungen sind so groß, dass bei 3.3V die LED schon leicht leuchtet, wobei meine Z-Diodenbox nur Werte von 2.7, 3.3, 3.9, beinhaltete. Wenn die Aussage nicht sicher ist, dann kann die Anzeige auch wegelassen werden. Oder einen besseren Vorschlag… Joe
Angehängte Dateien:
-
Schem_Eagle.PNG
44 KB
Habe mir gerade mal den Schaltplan angesehen, dabei fiel mir folgendes auf: Es gibt nur einen Abblockkondensator (im Schaltplan am AVR, auf der Platine neben dem RAM). Ich würde für MCU und RAM jeweils einen eigenen Kondensator vorsehen und die Bauteile so platzieren, dass sie nicht direkt vor oder hinter dem Sockel sitzen, sondern seitlich versetzt. Das erleichtert den Ausbau der ICs, wenn man einen Schraubendreher als Hebel ansetzen will. Ggf. sollte man noch einen Elko für die SD-Karte einplanen. Der Pin AREF sollte offen bleiben. Im Schaltplan ist er auf 3,3V gelegt, auf der Platine gibt es ein nicht geroutetes Signal. Ich nehme an, das ist AREF. Ich würde es im Schaltplan korrigieren. Noch ein Tipp zu Eagle: Mit dem Befehl Label kann man die Leitungen im Schaltplan beschriften. So erkennt man besser, welche Signale aus dem BUS herausgeführt werden. Ich habe testweise mal alle Labels gesetzt (s. Screenshot). Im Screenshot ist der Label Befehl (Schaltfläche) unten links gesetzt. Es ist die grüne Linie mit "ABC" darüber. In der Vorschau sehe ich den angehängten Screenshot nicht. Ich hoffe, es klappt trotzdem. Eine Frage: Kann man statt dem Mega88 auch einen Mega8 einsetzen? Sie unterscheiden sich ja etwas, z.B. hinsichtlich der Speicheraufteilung. Gruß, Bix. Ist ein tolles Projekt.
Nein.. denn bix hat die aller erste Version der Schaltung verwendet.. Sorry, bix. Aktuell verfolgen wir die Schaltung von Joe G. (etwas weiter oben) mit einer USB Buchse und FT232RL Optional.. Wäre super, wenn du da auch noch mal einen Blick drauf werfen könntest.. Peter
Angehängte Dateien:
-
AVR_CPM_BRD1.PNG
30 KB -
AVR_CPM_BRD2.PNG
29 KB -
AVR_CPM_BRD3.PNG
28 KB
Peter Sieg schrieb: > Nein.. denn bix hat die aller erste Version der Schaltung verwendet.. Hmmm ... erwischt. Sehr schönes Layout von Joe, da gibt es nichts zu meckern. Nur zwei Anmerkungen: Man könnte beim SD-Slot die Verbindung benachbarter Pads über eine Leitung außen herum realisieren. Dann ist die thermische Kopplung geringer und es lässt sich etwas einfacher löten. Ist aber auch kein Drama, wenn man es so lässt. Das Via der TXD-Leitung könnte man bei der Gelegenheit auch etwas weiter weg schieben, um das Risiko eines ungewollten Kurzschlusses zu minimieren. Platz ist ja genug da. Die Änderungen sieht man auf den angehängten Screenshots (1=vorher / 2=nachher). Das Via liegt im zweiten Screenshot in der Massefläche. Ich habe es extra so dargestellt, damit man besser sieht, wie das Via verschoben wurde. Ein "Ratsnest" bereinigt es dann wieder. Man könnte noch, wenn man will, auf dem Toplayer einige Beschriftungen anbringen, z.B. Markierung von Pin 1 der Stiftleisten und ICs, sowie "+" bei Elko und LED, zu sehen auf Bild 3. Man könnte noch einen optionalen Elko am SD-Slot vorsehen.
@bix: Danke für die Hinweise! Ich nehme sie gerne auf. Zum Einsatz eines Mega8. Ich denke er ist nur bis 16 MHz spezifiziert. Ob er mit 20 MHz oder gar mit 24 MHz (Takt aus FT232) geht müßte getestet werden.
Hi
>Sehr schönes Layout von Joe, da gibt es nichts zu meckern.
Ich würde da noch einigen Handlungsbedarf sehen. Abgesehen vom Layout,
fehlen solche elementaren Dinge, wie Abblockkondensatoren.
MfG Spess
Angehängte Dateien:
-
AVR_CPM_Schem_Joe.png
21 KB
spess53 schrieb: > fehlen solche elementaren Dinge, wie Abblockkondensatoren. Hallo Spess, beziehst Du Dich auf den aktuellen Schaltplan von Joe? Gruß, bix
Hi
>Hallo Spess, beziehst Du Dich auf den aktuellen Schaltplan von Joe?
Eigentlich auf das Layout, von dem du geschwärmt hast. Aber in dem
Schaltbild
vermisse ich auch einen Kondensator von AVCC nach AGND. Außerdem ist
z.b. ein 10µ-Elko am Reset-Pin tödlich für ISP.
Um es mal vorsichtig auszudrücken: Hardware ist nicht eure Stärke.
MfG Spess
@Spess Komm, lasse uns nicht dumm sterben. Wo sind vorsichtig ausgedrückt die "Eier" in der Schaltung? Wo siehst Du noch einigen Handlungsbedarf? Genau deshalb soll ja hier diskutiert werden. Joe
Mit dem Elko am Reset-Pin hat Spess natürlich recht. Der gehört dort nicht hin. In der Schaltung von Peter, die ich im Kopf hatte, war er dort nicht vorhanden. Was den von mir erwähnten fehlenden Elko am SD-Kartenslot angeht, da gibt es unterschiedliche Varianten. Manche setzen keinen Kondensator ein, manche einen Abblockkondensator von 100n. Elm-Chan setzt dort einen 4u7 Elko hin, um Spannungseinbrüche abzufangen, falls eine SD-Karte im Betrieb eingesetzt wird. Interessante Links hierzu: http://www.mikrocontroller.net/articles/MMC-_und_SD-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-interfacing-with-atmega8-fat32.html Sicherheitshalber sollte ein 220u Elko am Eingang der Versorgungsspannung und ein 4u7 Elko direkt am SD-Slot vorgesehen werden. Vielleicht läuft es ohne - schön. Falls nicht, kann man die Elkos nachträglich noch bestücken. AVcc soll gemäß Datenblatt zum Mega88A direkt mit Vcc verbundenwerden, wenn der ADC nicht benutzt wird. Wenn der ADC benutzt wird, soll AVcc über einen Tiefpass mit Vcc verbunden werden. Da wir den ADC nicht verwenden, benötigen wir keinen Tiefpass. Es ist sicherlich kein allzu hoher Aufwand, einen zusätzlichen Abblockkondensator für AVcc vorzusehen.
Hi
>Komm, lasse uns nicht dumm sterben.
Was verstehst du an der Aussage, das Kondensatoren fehlen oder falsch
sind, nicht?
Ich beziehe mich mal auf das Layout von 18:36:
Mindesten 50% der Leiterzüge sind, zum Teil wesentlich, länger als
nötig:
- 90°-Winkel sollte man vermeiden.
- Unnötige 'Schlenker' z.B. rechte Seite oben.
- Unnötige Umwege z.B. Pin23 ATMega - Pin1 Speicher
_ ...
Außerdem sieht mir der Isolationsabstand etwas klein aus.
MfG Spess
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
Mir persönlich gefällt die folgende Variante zum Anschluß der SD-Card ganz gut. http://www.dharmanitech.com/2009/01/sd-card-interf... Damit wird die Schaltung komplett mit 5V betrieben und nur die SD mit 3.3V. Es kann also nicht zur versehentlichen Zerstörung der SD kommen und der Dram wird innerhalb seines Spannungsbereiches betrieben. Die notwendigen Z-Dioden und Widerstände würde ich als SMD in die Nähe der SD bringen und diese könnten dann optional bestückt werden. Somit hätten wir die zwei möglichen Bestückungsvarianten auf der Platine: 1. alles wie gehabt, extern (USB) 5V oder extern 3.3V (siehe alte Schaltung) 2. nur noch extern 5V
Reinhard Kern schrieb: > CP/M u.ä. > Systeme setzen Speichermodelle voraus mit Programm und Daten innerhalb > 64k (wie sollten sie das auch besser wissen), der eZ80 kann aber nur > ganze Seiten einblenden, um also Rom und Ram oder verschiedene > RAM-Bereiche innerhalb 64k abzubilden, braucht man noch etwas externe > Hardware. Insbesondere CP/M 3 verlangt einen Common-Breich, der in allen Pages ansprechbar sein soll. Das dürfte ausgesprochen haarig werden und hat mich bis auf weiteres von dieser Idee abgebracht. Wäre aber sehr nett gewesen sonst, schade ...
Zu den fehlenden Z80-Opcode-Routinen: CP/M ist ein auf dem 8080 lauffähiges OS. Der Befehlssatz des Z80 ist ein Superset des 8080-Befehlssatzes. Was spricht eigentlich dafür, den FT232RL nur optional vorzusehen? Wenn man ihn unbedingt vorsieht, kann man sich den ISP-Stecker sparen, wenn man dem Controller einen Bootlader spendiert. Das hätte den Vorteil, daß jemand, der keinen ISP verfügbar hat, sich nur von irgend jemandem ein mal den Bootlader flashen lassen muß und das Teil dann selbst über den USB programmieren kann. Das mit dem eZ80 ist eine Schnapsidee, das funktioniert im Leben nicht mit CP/M.
Uhu Uhuhu schrieb: > Was spricht eigentlich dafür, den FT232RL nur optional vorzusehen? Aufgrund seiner Bauform lötet er sich nicht so einfach, daher optional. Wer ISP nicht benötigt, weil er mit Bootloader arbeitet, kann die Stiftleiste ja weglassen.
Joe G. schrieb: > Mir persönlich gefällt die folgende Variante zum Anschluß der SD-Card > ganz gut. Wenn Du diese Schaltung meinst: http://3.bp.blogspot.com/_zqABT3suzXE/S_EwMNYzDhI/AAAAAAAAAW4/MHHY0U-xAhM/s1600/SD_M32_RTC.JPG (Ver_2.4) Dort fehlen die Spannungsteiler an den Portpins des ATMega, oder zumindest Strombegrenzungswiderstände zwischen dem Anschluss des ISP-Steckers und den Z-Dioden. Ein 3,3V / 5V Mixbetrieb ist sicherlich für das RAM sowie den Betrieb des ATMega bei hohen Frequenzen von Vorteil, insbesondere, wenn man noch übertakten will. Der optionale FT232 oder alternativ ein Low Drop 3,3V Spannungsregler wäre damit verpflichtend und der Aufwand steigt. Ohne 3,3V-Regler geht's zur Not auch (s. Schaltung von Ulrich Radig), aber nicht ohne Spannungsteiler: http://www.ulrichradig.de/home/index.php/avr/mmc-sd
heini schrieb: > Insbesondere CP/M 3 verlangt einen Common-Breich, der in allen Pages > ansprechbar sein soll. Das dürfte ausgesprochen haarig werden und hat > mich bis auf weiteres von dieser Idee abgebracht. Wäre aber sehr nett > gewesen sonst, schade ... Hallo, das kostet maximal 1 IC, aktuell bei mir ein 74xx139, wenns komplexer wird ein GAL. Ich habe Flash von 0..7FFF auf den CP/M-Pages und RAM von 8000..FFFF, und das gemeinsam für 2 benachbarte Pages. Mir ist es aber auch erst nach der ersten Version aufgefallen, dass die eingebauten ChipSelects dafür nicht flexibel genug sind, daher ein Redesign. Mit 3 Jumpern kann ich aber auch auf 24bit "flat" umschalten. Gruss Reinhard
Die Geschwindigkeit des System ist ziemlich lausig. Allein um ein Byte zu lesen oder zu schreiben werden ca. 220 Takte benötigt - vom Zeitaufwand zur Befehlsabarbeitung einmal ganz zu schweigen. Fazit: gute Idee (2 Chip Design & so.) aber Nachbau der Orginalausführung: Nö.
heini schrieb: > Insbesondere CP/M 3 verlangt einen Common-Breich, der in allen Pages > ansprechbar sein soll. Das dürfte ausgesprochen haarig werden Warum? Das ist nicht mehr als eine einfache Umsetzung der effektiven Adresse in die DRAM-Adresse, im Programm. Nicht viel Aufwand.
@Joe: Finde ich gut noch ein paar Ideen zur Platine zu diskutieren.. aber KISS (Keep It Simple & Stupid). Diese Platine soll nahe am Original mit kleinen Verbesserungen bleiben.. und das Original läuft auch bei mir auf Lochraster, einem (1) Abblockkondensator und 3,3V und gut ist.. Das Ganze soll ja eigendlich lediglich das leidige von Hand verdrahten auf Lochraster ersparen.. @Martin: Danke, aber das wußten wir schon.. wenn du Ideen hast wie man an der orig. Hardware+Firmware noch etwas besser machen kann.. nur zu.. ansonsten gab/gibt es hier auch eine 'Fraktion' die über ein Redesign ggf. mit 8-bit Sram nachdenken.. auch hier sind sicher weite Betätigungsfelder für Mitwirkende.. Just my 2 cents Peter
>Mindesten 50% der Leiterzüge sind, zum Teil wesentlich, länger als >nötig: > >- 90°-Winkel sollte man vermeiden. >- Unnötige 'Schlenker' z.B. rechte Seite oben. >- Unnötige Umwege z.B. Pin23 ATMega - Pin1 Speicher >_ ... Autorouter halt...
Habe mir gerade mal die Timing-Diagramme im Datenblatt zum DRAM angesehen. Jeder Zugriff auf das RAM (Lesen, Schreiben, Refresh) wird durch setzen der RAS\ Leitung begleitet. Man kann also die übrigen Leitungen des RAM als IO-Port nutzen, solange RAS\ auf High-Pegel liegt. Es ist lediglich zu beachten, dass die Adressleitungen vom uC angesteuert werden müssen, bevor RAS\ auf Low gezogen wird. Da außer RX und TX keine Ein- und Ausgabe möglich besteht, schlage ich eine zweireihige Stiftleiste als optionalen Erweiterungsport vor. Er müsste Spannungsversorgung sowie alle Leitungen zum RAM, insbesondere RAS\, enthalten. Man könnte dann weiter ausbauen, z.B. eine RTC, serielle EEPROMS, LEDs, Taster oder LCD ergänzen. Die Platine müsste etwa 1/2 cm verlängert werden, wenn man die Stiftleiste am oberen Ende parallel zum RAM platziert. Die Bestückung wäre natürlich optional.
A. K. schrieb: >> Insbesondere CP/M 3 verlangt einen Common-Breich, der in allen Pages >> ansprechbar sein soll. Das dürfte ausgesprochen haarig werden > > Warum? Das ist nicht mehr als eine einfache Umsetzung der effektiven > Adresse in die DRAM-Adresse, im Programm. Nicht viel Aufwand. Vielleicht sehe ich ja den wald vor Bäumen nicht, aber nach meiner Vorstellung muss für den zugriff auf den Common-Bereich in den ADL-Mode gewechselt werden. Ohne mich jetzt näher damit befasst zu haben, gehe ich davon aus, dass das zu Problemen bei der Systemgenese führen wird, zumal GENCPM schwerlich in der Lage sein wird, 24-bit-Adressen in .SPR_Dateien zu verarbeiten. Eine hardware-basierte Lösung über einen externen Adressdecoder, was funktionieren sollte, fände ich schauderhaft, aber das ist vermutlich ein weltanschauliches Problem<g>
Soweit ich erkennen kann hat CP/M 3 eine Form von Bank-Switching verwendet. Eine Page blieb unverändert, der Rest wurde umgeschaltet. Solch ein Verfahren lässt sich mühelos in einen CPU-Emulator einbauen, da ist keine separate Hardware notwendig. Kostet ein paar Takte beim Speicherzugriff. Das kann im einfachsten Fall so aussehen: used_bank = (address>=0xF000) ? 0 : active_bank; jeweils vor dem Speicherzugriff. Alternativ über Tabelle.
Jungs, jetzt bleibt doch mal auf dem Teppich. CP/M ist tot und wir haben es hier mit einem reinen Nostalgieprojekt zum Spielen und schwelgen in netten Erinnerungen zu tun. Dazu braucht man keinen 50 MHz-Prozessor und mehr als 64 kB waren damals auch erst mal nicht vorgesehen. Also: Bringen wir das CM/M 2.2 - Image zum Laufen und freuen uns daran, daß das Systemchen läuft. Was mir fehlen wird, ist eher das rat-tatat des zwei Einheiten hohen 3 1/2" Diskettenlaufwerkes beim Warmstart...
Uhu Uhuhu schrieb: > Jungs, jetzt bleibt doch mal auf dem Teppich. CP/M ist tot und wir > haben es hier mit einem reinen Nostalgieprojekt zum Spielen und > schwelgen in netten Erinnerungen zu tun. > > Dazu braucht man keinen 50 MHz-Prozessor und mehr als 64 kB waren damals > auch erst mal nicht vorgesehen. > > Also: Bringen wir das CM/M 2.2 - Image zum Laufen und freuen uns daran, > daß das Systemchen läuft. > > Was mir fehlen wird, ist eher das rat-tatat des zwei Einheiten hohen > 3 1/2" Diskettenlaufwerkes beim Warmstart... Du kannst Uns ja ein Diskettenlaufwerks Kontroller bauen :) Das währe soetwas wie das Sahnehäubchen auf dem Kuchen ;)
Uhu Uhuhu schrieb: > Jungs, jetzt bleibt doch mal auf dem Teppich. CP/M ist tot und wir > haben es hier mit einem reinen Nostalgieprojekt zum Spielen und > schwelgen in netten Erinnerungen zu tun. Also für mich ist das kein Grund. Der Grund warum ich das interessant finde ist, dass man hier die Chance hat mit 2 DIP-Chips einen kompletten Rechner aufbauen kann. Und das mit relativ wenig Aufwand. Die Alternative für mich wäre ein Flash-Dateisystem aus dem ich AVR-Code direkt ausführen könnte.
Christian Berger schrieb: > Die Alternative für mich wäre ein Flash-Dateisystem aus dem ich AVR-Code > direkt ausführen könnte. Dann solltest du das machen. Einen Uraltprozessor auf einem modernen µC zu simulieren, um ein steinzeitliches OS - zu dem es keine Quellen gibt - darauf laufen zu lassen, ist ohne nostalgischen Hintergrund schlicht sinnlos. CP/M ist wie gesagt mausetot und man kann mit dem Projekt eigentlich nichts sinnvolles anfangen. Nimm einen großen ATMega, häng einen fetten SRAM-Chip und einen SD-Card-Sockel dran, pack FreeRTOS drauf, dann hast du was, was auch nicht mehr Teile hat, als dieses Nostalgieschätzchen hier und zusätzlich - im Gegensatz zu einem alten CP/M-Image - vollständig in Quellen verfügbar und einigermaßen Stand der Technik ist.
Uhu Uhuhu schrieb: > um ein steinzeitliches OS - zu dem es keine Quellen gibt Das ist inzwischen nicht mehr korrekt. Der Quellcode wurde inzwischen veröffentlicht.
Christian Berger schrieb: > Das ist inzwischen nicht mehr korrekt. Der Quellcode wurde inzwischen > veröffentlicht. Ah, das wußte ich nicht. Ist ja nett... Wo denn? Nachtrag zu meinem voherigen Beitrag: "Große" Festplatten hatten in den 80er Jahren - als CP/M aktuell war - gerade mal 40 MB. Eine heutige SD-Karte kann CP/M überhaupt nicht verwalten, ohne daß der größte Teil brach liegt.
Ich finde, daß wir bei dem vorgesehenen Muster mit CPM2.2 und den beiden Chips beliben sollten. Falls jemand was anderes bauen will, so sollte er ein neues Projekt aufziehen und nicht seine Fähigkeiten im Zerreden dieses Projektes einsetzen. Für mich ist die ursprüngliche Richtung maßgebend. Alle anderen Sachen wie - CPM 3.0 - RTOS mit eigener HW - SRAM Interface mit riesigen Erweiterungen sollten in einen anderen Projekt erörtert werden. Mir gefällt das Projekt hier gerade, weil es so einfach ist.
Uhu Uhuhu schrieb: > Ah, das wußte ich nicht. Ist ja nett... Wo denn? http://www.cpm.z80.de/source.html
Das ist ja wirklich nett. Vielen Dank. PL/M habe ich auch mal programmiert - ist aber nicht wirklich der Bringer...
Habe gerade etwas entdeckt. In den Kommentaren zum Original-Projekt auf der Seite http://spritesmods.com/?art=avrcpm&page=4 wird auf ein Testprogramm für den 8080 hingewiesen: (instruction set test program EX8080.COM) Ist sicherlich hilfreich, wenn man fehlende Opcodes ergänzen möchte. Hier der Link: http://www.schorn.ch/cpm/intro.php Auf der Seite gibt es auch unterschiedliche Programmiersprachen, unter anderem Turbo Pascal.
Letztendlich finde ich das Ganze doch so interessant, dass ich ein "Parallelprojekt" zumindest anfangen werde. Basis wird der aktuelle ChipBasic2 Computer ohne Modifikationen sein. Dazu ein 64K RAM Modul am Parallelport, welches zwar schon seit über einem Jahr bei mir existiert aber erst jetzt durch die ladbaren Treiber wirklich benutzbar wird. In Punkto Videoauflösung ist es mir gelungen, Treiber für 24 Zeilen a 50 Zeichen und 24 Zeilen a 60 zeichen zu entwickeln. Der Zeichensatz umfasst 128 zeichen, sowohl normal als auch invers. In der ersten Stufe (soweit Interesse daran ist), könnte ich ein einfaches Terminalprogramm integrieren (das RAM-Modul wird dazu nicht gebraucht). Dazu würde ich mich an z.B VT52 oder VT100 orientieren und implementieren, was halt möglich ist. Die Frage ist natürlich, ob man mit 60 zeichen/Zeile einigermassen arbeiten kann. Die nächste Stufe wäre dann, meinen (weitestgehend vorhandenen) Z80 Emulator an das System anzupassen. Eigentlich wollte ich damit mal einen ZX81 mit 2K RAM auf dem AVR simulieren, hab aber irgendwann aufgegeben... Jörg
Ich finde das Projekt einerseits interessant als CP/M Emulation, andererseits als kleine Platform für weitere Mini-Computer. Es ist im Prinzip ja alles dafür da. 128KByte RAM, externer Speicher (in Form einer SD-Karte) und einer einfachen Schnittstelle nach außen hin. Weiterhin, alles schön einfach zu löten und per USB eben die Möglichkeit alles schön versorgen zu können. Als Experimentier-Platform schön geeignet, und die IOs lassen sich ja auch noch einfach abgreifen. Kurzum : - Schönes CP/M Emulation-Nostalige-Projekt - Einfache Platform zum Aufbau und Experimentieren eines Mini-Computers Daher will ich auch son Dingen :-)
@Jörg: Prima! Mit deiner Erfahrung und Vorkenntnissen bin ich gespannt! Und der Herbst kommt ja auch nach dem Sommer ;-) Da kann wieder mehr gebastelt werden.. Ansonsten freue ich mich aber ersteinmal auf Platine Version 1 zum etwas stabileren Aufbau des Originals mit Komm. und Stromversorgung über USB.. Peter
Joerg Wolfram schrieb: > Letztendlich finde ich das Ganze doch so interessant, dass ich ein > "Parallelprojekt" zumindest anfangen werde. Dann eröffne aber bitte auch einen Extra Thread dafür.
@alle Die Überarbeitung der Schaltung und dem Layout der Version 1.0 sind nun abgeschlossen. Wie zu sehen, sind nicht alle Änderungen berücksichtigt. Speziell die Variante mit dem zusätzlichen Busstecker hätte größere Änderungen bedeutet. Zur Bestellung der Platinen: Alle die bei mir Platinen sowie Bauelemente bestellt haben müßten nun eine Mail in Ihrem Postfach haben. Wer keine Mail bekommen hat, der hat noch nicht bestellt oder ich habe ihn übersehen, dann bitte wie schon oben beschrieben nochmal wiederholen. Auf gleichem Wege bekommt ihr das EEPROM File für den FT232 und eine kleine Hardwaredoku. Joe
>Es ist im >Prinzip ja alles dafür da. 128KByte RAM, externer Speicher (in Form Mich wundert schon eine Weile, wie man mit dem 4256 CP/M machen will. Das sind nicht 128KByte, sondern 128K B i t! Also 16 KByte( x8 ). Mit 8 Adress und 4 Datenleitungen ist da nicht mehr drin. http://www.datasheetcatalog.org/datasheet/hynix/HY534256ALJ.pdf Ich lasse mich auch eines besseren belehren.
ich weiß ncht Michael, aber ein 256 KBit x 4 DRAM könnten gut 1024 KBit sein, heißt durch 8: 128 KB (steht im DB: 262144 x 4 Bit), und die Leitungen sind Zeile und Spalte, sollte so stimmen. Für ein Byte sind immer zwei Lese-/Schreibzugriffe nötig. Ich hoffe, ich habe kein Blödsinn erzählt, steht ja tw. auch hier im Thread.
Hi, Michael_ schrieb: >>Es ist im >>Prinzip ja alles dafür da. 128KByte RAM, externer Speicher (in Form > Mich wundert schon eine Weile, wie man mit dem 4256 CP/M machen will. > Das sind nicht 128KByte, sondern 128K B i t! Also 16 KByte( x8 ). > Mit 8 Adress und 4 Datenleitungen ist da nicht mehr drin. > http://www.datasheetcatalog.org/datasheet/hynix/HY534256ALJ.pdf > Ich lasse mich auch eines besseren belehren. Wie schon vom Vorschreiber angedeutet: Hier liegst du ziemlich daneben... Und irgendwie kann ich deiner Rechnung auch nicht ganz folgen: Normal ist ja folgendes: Mit 8 Adressleitungen kannst du 2^8, also 256 Adressen selektieren. Jede dieser Adressen enhält aber eine "Busbreite" an Bits. In diesem Fall also vier. Im Ergebnis also 256 Adressen * 4 Bit = 1024 Bit 1024 Bit : 8 = 128Byte! (Also weder das Ergebnis deiner REchnung, noch irgendeine sonst sinnvolle Angabe) Also passt irgendetwas nicht... Die Lösung: Bei diesem Baustein sind die Adressleitungen multiplext. Ausserdem sind es neun, nicht acht! (A0-A8) Die Adresse besteht aus zwei je 9 Bit breiten Adresstelegrammen. Somit besteht die Möglichkeit 2^9 * 2^9 = 2^18 Adressen zu Selektieren. (512*512 = 262144) Jede dieser Adressen enthält eine "Busbreite" an Speicherzellen, also in diesem Fall vier Bit. Somit hat der Baustein 2^18 * 4 = 1048576 Bit, was dann 128 KB ergibt. (Rechnung: 1048576 : 8 = 131072 Byte. Ein KB sind 1024 Byte, folglich ergibt sich daraus 131072 : 1024 = 128, also 128KB) Gruß Carsten
Eine weitere Alternative für die DRAMs wäre, einen optionaler SOJ auf DIL Adapter mit vorzusehen. Dann könnte man auch alte PS/2 Module ausschlachten. Jörg
Angehängte Dateien:
-
Polygon_Isolation.PNG
14 KB -
Font.PNG
9,5 KB
Joe G. schrieb: > Die Überarbeitung der Schaltung und dem Layout der Version 1.0 sind nun > abgeschlossen. Wie zu sehen, sind nicht alle Änderungen berücksichtigt. Spess schrieb: > Außerdem sieht mir der Isolationsabstand etwas klein aus. Der von Spess festgestellte zu geringe Isolationsabstand bedarf noch der Korrektur. Also in den Polygon-Eigenschaften den Wert "Isolate" auf mindestens 1 mm einstellen beziehungsweise den Wert, den der Leiterplattenfertiger vorgibt. (Siehe Screenshot, hier habe ich 40 mil bzw. 0.04 Inch eingestellt, was etwa 1 mm entspricht.) Die Beschriftung sollte als Vektorfont mit einer Größe von 50 mil und Ratio von mindestens 20 % ausgeführt sein, sonst sind die Linien zu dünn und die Beschriftung wird komplett weggeätzt. Da die Größeneinheit auf Inch eingestellt ist, wären das folgende Befehle. change font vector change size 0.05 change ratio 20 Den Unterschied sieht man auf dem Screenshot "Font". Oben links sieht man das Wort "Reset" nach der Änderung, unten vor der Änderung. Der DRC meckert dann auch nicht mehr daran herum. Viele Grüße, bix
Hi >Der von Spess festgestellte zu geringe Isolationsabstand bedarf noch der >Korrektur. Also in den Polygon-Eigenschaften den Wert "Isolate" auf >mindestens 1 mm einstellen beziehungsweise den Wert, den der >Leiterplattenfertiger vorgibt. Man muss allerdings auch nicht übertreiben. Mehr als 25mil brauchst du nicht. Und das sollte auch jeder Hersteller können. MfG Spess
Mein erster Computer mit CP/M 2.2 war voll Eigenbau und hatte 4 Karten im Einschubgehäuse. Auf der ersten Karte waren nur der Z80 mit Quarz und die PIO zum Anschluss der selbst gebauten Voll-Tastatur. Die zweite Karte hatte 32 DRAM Chips mit je 16Kx1, eine Refreshlogik in TTL, 4 NiCd AA Zellen als Notstromversorgung und einen NE555 mit 10uH Drossel als Stepupwandler. Weil mir hier zwei Gatter fehlten, aber kein Platz vorhanden war, hab ich mit etwas Diodenlogik nachgeholfen. Die dritte Karte enthielt eine CTC und ein diskret aufgebautes Kassettenrekorder Interface. Die vierte war die Grafikkarte mit 2kByte RAM für 24 Zeilen mal 64 Zeichen, viel TTL und einem Kanal 3 Modulator. Noch jetzt erinnere ich mich, wie ich in der Badewanne lag und auf Kästchenpapier die 256 Zeichen aufgemalt und daneben die Hexcodes geschrieben habe. Das BIOS war auch selbst geschrieben, nach einer kaum lesbaren Interfacebeschreibung auf braunem Thermokopiepapier aus irgendeiner Zeitschrift. Der Computer war ein Spitzenteil womit ich anfangs in Pascal und später in C programmiert habe. Die 64kByte DRAM teilten sich Betriebssystem, Arbeitsspeicher und RAM-Disk. Der C-Compiler bestand aus zwei COMs die man nacheinander vom Kassettenrekorder in die RAM-Disk laden musste um so den Quelltext zu kompilieren. Übrigens wurden davon bestimmt 10 Stück nachgebaut und ich habe zumindest den Aufwand daran verdient. Vom Spaß nicht zu reden. Die Leiterplatten-Layouts wurden mit Tusche per Hand auf karierten Karton gemalt und dann im Kontaktverfahren auf Film übertragen. Und ja, wir haben schon mit Messer und Gabel gegessen.
>(Rechnung: 1048576 : 8 = 131072 Byte. Ein KB sind 1024 Byte, folglich >ergibt sich daraus 131072 : 1024 = 128, also 128KB) Richtig! >Die Leiterplatten-Layouts wurden mit Tusche per Hand auf karierten >Karton gemalt und dann im Kontaktverfahren auf Film übertragen. Ja, das waren noch Zeiten. Kenne ich auch noch. Bis zur 256KByte RAM-Floppy habe ich es auch noch geschafft. Aber das war dann mausetot als die Übermacht von AMIGA und IBM-PC kam! Ich denke auch mit Recht!
Hmm.. mit Recht..? Nun, ich denke.. was die graphisch und spielerischen Aspekte und vorallen Dingen die audiovisuellen, erstklassischen Demos angeht.. Amiga=klares JA. (Inzw. ja auch auf der PC Plattform ein beliebtes Genre) Aber ansonsten.. ist doch inzw. das 'Netz' der Computer.. soll heißen ohne E-Mail, Web, Streaming etc. wäre doch der Frontend=PC 'nur' ein graphisch, verspielter CP/M Rechner ;-) Die 'Killerapplikationen'=Textverabeitung, Tabellenkalkulation, Datenbank gab es 'damals' auch schon (Wordstar, Multiplan, dbase). Und mit einem ASCII basierten Mini-Linux kann man auch ohne schnick-schnack Mails lesen und schreiben und Webseiten lesen etc. Also Inhaltlich/Funktional sind die Urgestalten der CP/M Ära gar nicht soo weit weg.. und manchmal sicher noch einfacher zu verstehen und zu kontrollieren.. nur Kiddies kann man damit schwer hinter dem Ofen vorlocken ;-) Dazu muß es ja heute klickibund und animiert sein.. - Inhalt: Nebensache - ;-) Sorry, Peter
Das Evaluation Kit "At XMega XPlain" wäre vielleicht das richtige für euch. Gibt's bei Reichelt für ca. 36€.
Hier gibt es die Beschreibung zu dem Board: http://www.atmel.com/dyn/resources/prod_documents/doc8203.pdf Mit 8MB Flash dürfte sich mit CPM wohl einiges anfangen lassen.
Uhu Uhuhu schrieb: >> Mit 8MB Flash dürfte sich mit CPM wohl einiges anfangen lassen. > > Eher nicht. Wieso nicht? Als Massenspeicher. Durchaus typisch für CP/M waren zwei Floppy-Disk-Laufwerke mit 160KB.
moin moin, vorsicht, 8MB war doch die maximale Größe je LW die CP/M verwalten konnte. WordStar konnte nur Dateien bis 512KB verarbeiten. Meine RAM-Disk hatte zuletzt 2BM mit 64Stück U61000. MfG Pieter
A. K. schrieb: > Wieso nicht? Weil dann erst ein extra Flash-Filesystem-Treiber für das interne Flash her müßte. D.h., mit dem Image, das auf dem Brettchen laufen soll, wird das nix. Man müßte erst ein maßgeschneidertes CP/M zusammenfrickeln.
Verstehe ich nicht. Ein normales CP/M benötigte einen Floppy-Treiber im BIOS. Dieses CP/M bräuchte einen Flash-Treiber ohne Filesystem, im BIOS oder (vorzusgweise) im Emulator. Das Filesytem bringt CP/M selber mit - muss ja kein FAT sein.
OK, mit dem Filesystem hast du recht. Die SD-Karte kann man sich trotzdem nicht sparen, wenn man die Daten mit den CP/M-Tools ins System bringen will. Aber ich denke, weitere Debatten hier über derlei Verbesserungen erübrigen sich trotzdem. Hier geht es darum, für das von Peter Sieg vorgeschlagene System ein Platinchen zu basteln. Wem das nicht reicht, für den gilt das im Zusammenhang mit dem eZ80 Gesagte: Beitrag "Re: CP/M auf ATmega88" Für mich ist das hier wirklich ein reines Retro-Projekt. Ich habe nicht vor, mit CP/M ernsthaft zu arbeiten.
... keine Sorge, dafür habe ich schon einen eigenen ... Hallo Joerg, wo kann ich deinen Thread finden? Martin
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
Angehängte Dateien:
-
avrcpm_brd.png
31 KB
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.
Angehängte Dateien:
-
avrcpm_schem.png
21 KB
Huch Das Schaltbild wollte ich als PNG anhängen. Hab mich verklickt, Anhänge zeigt die Vorschau leider nicht an - sorry.
@bix: normalerweise bekommst du eine infomail, das du registriert bist. versuche dich einfach mal einzuloggen...
Ronny Minow schrieb: > normalerweise bekommst du eine infomail, das du registriert bist. > versuche dich einfach mal einzuloggen... Die Infomail habe ich nicht bekommen. Wenn ich trotzdem versuche mich anzumelden, wird angezeigt "Login fehlgeschlagen". Uhu Uhuhu schrieb: > Welches Forum? Das beste Forum der Welt meine ich natürlich. Eben genau dieses hier ;-)
@bix keine Torschlusspanik, ist doch noch ein Tag Zeit. Die letzten Änderungen (Beschriftung, Isolationsabstand) sind schon eingearbeitet. Weiterhin noch ein 100n C zwischen /DTR und Reset. Somit könnte der AVR mit einem Bootloader und Reset über /DTR versehen werden und die Programmierung über ISP entfällt. Damit sollte die Gefahr, die SD-Karte versehentlich mit 5V zu versorgen, genommen sein. Die Idee mit dem kleinen Steckfeld ist gut, ich habe sie übernommen. @alle Wer nur als Gast hier im Forum ist, und dennoch bei mir bestellen möchte bitte das über diese Mail tun: info (at) amesys (dot) de Joe
Joe G. schrieb: > Die Idee mit dem > kleinen Steckfeld ist gut, ich habe sie übernommen. Hallo Joe, danke für die schnelle Antwort. Damit das mit den Stiftleisten später funktioniert (auf Hardware Version 2 Jumpern), habe ich die im Text mit (*) gekennzeichneten Pins des ATMega so auf die Lötseite der Platine verlegt, dass man die Leitungen später einfach durchtrennen kann (erkennbar an den quardatischen "Vias"). Ist erst die IC-Fassung aufgelötet, kommt man auf der Bauteileseite ja später nicht mehr an die Leitungen heran. Es sind beim AVR die Pins 5, 19, 24 und 27. Pin 19 musste ich vom AVR zum RAM verlegen, damit der Pin zum AVR einzeln durchtrennt werden kann, ohne die restliche Leitung zu unterbrechen (s. Bild avrcpm_brd.png).
1 | ; ATmega8 (HW-Rev.2) |
2 | ; |
3 | ; |
4 | ; +-------------v-------------+ |
5 | ; Reset\ | 01 (RESET) PC5 28 | CAS\ |
6 | ; TXD | 02 (RXD) PC4 27 | RAS\ (*) |
7 | ; RXD | 03 (TXD) PC3 26 | D3 |
8 | ; OE\ | 04 PD2 PC2 25 | D1 |
9 | ; (*) WE\ | 05 PD3 PC1 24 | D2 (*) |
10 | ; SD_CS\ | 06 PD4 PC0 23 | D0 |
11 | ; VCC | 07 VCC GND 22 | GND |
12 | ; GND | 08 GND AREF 21 | n.c. |
13 | ; Q20MHz | 09 (XTAL1) AVCC 20 | VCC |
14 | ; Q20MHz | 10 (XTAL2) (SCK) PB5 19 | A8 / SD_SCK (*) |
15 | ; A5 | 11 PD5 (MISO) PB4 18 | A0 / SD_MISO |
16 | ; A6 | 12 PD6 (MOSI) PB3 17 | A1 / SD_MOSI |
17 | ; A7 | 13 PD7 PB2 16 | A2 |
18 | ; A4 | 14 PB0 PB1 15 | A3 |
19 | ; +---------------------------+ |
E-Mail mache ich gleich fertig. Danke und Grüße
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
Angehängte Dateien:
-
avrcp_m.jpg
110 KB
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
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 ;-)
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.
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
Hier noch eine Rückmeldung vom Entwickler: --- Hiya, Damn, I never expected such a thread to grow out of something this silly :) Even with pre-made PCB's, wow. I use something which calls itself 'Z80 assembler version 1.8', which is in the Debian-repositories as 'z80asm'. I thing you can use just about any sane Z80 assembler, though. Jeroen --- Peter
Ich hab mal angefangen das z80.asm auseinanderzunehmen um zu sehen, wo es noch hapert. Der entscheidende Teil kommt ab Zeile 1766, dort sind die ganzen Ausführungs-'einheiten' zusammengefasst, die die eigentliche Arbeit machen. Ich hab da jetzt mal eine OP-Code Tabelle mit reingenommen, aus der hervorgeht, welcher Befehl welche Flags beeinflusst. Im Moment bin ich dran, die vorhandenen Funktionseinheiten durchzugehen und zu kontrollieren, ob die Flagbehandlung mit dieser Tabelle übereinstimmt. Das Parity-Flag wird leider tatsächlich ziemlich stiefmütterlich behandelt. So wie das gemacht ist, geht das gar nicht. Es reicht einfach nicht aus, die Parity nur bei einer direkten Parity-Abfrage auszuwerten. Da muss auf jeden Fall noch nachgebessert werden. Wenn sich wer an der Arbeit beteiligen will .... Bei jeder Funktionseinheit steht dabei, von welchen Opcodes sie benutzt wird. Eine abschliessende Kommentarzeile
1 | ; OK |
weist darauf hin, dass diese Funktion schon überprüft ist. Im Gegensatz zu
1 | ; Not yet checked |
Wenn sich wer die Mühe macht, und die noch fehlenden OpCodes zu implementieren, bitte auf die Flags achten. Die Flagbehandlung kann bei ähnlichen Befehlen unterschiedlich sein! Das sieht man in der OpCode-Übersichtstabelle:
1 | RLC A |
2 | RLCA |
haben zwar auf den ersten Blick dieselbe Funktion, die Behandlung des Parity-Flags ist aber anders. Im Zuge der Kontrolle tausche ich auch die magischen Bitkonstanten für die Flags gegen besser lesbare 1<<irgendwas Konstrukte aus.
@Karl Heinz Buchegger: Super!! Leider habe ich von Z80 keine Ahnung.. Was ich aber schon geändert hatte, war die dynamische Berechnung der Bautrate anhand der Quarzfrequenz:
1 | .equ F_CPU = 20000000 ; system clock in Hz |
2 | .equ BAUD = 38400 ; baud rate |
3 | |
4 | ; Berechnungen |
5 | .equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) ; clever rounding |
6 | |
7 | ... |
8 | |
9 | ; - Init serial port |
10 | ldi temp,$18 |
11 | sts ucsr0b,temp |
12 | ldi temp,$6 |
13 | sts ucsr0c,temp |
14 | ldi temp,0 |
15 | sts ubrr0h,temp |
16 | ldi temp,UBRR_VAL |
17 | 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
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.
1 | ; - Init serial port |
2 | ldi temp, (1<<TXEN0) | (1<<RXEN0) |
3 | sts ucsr0b,temp |
4 | ldi temp, (1<<UCSZ01) | (1<<UCSZ00) |
5 | sts ucsr0c,temp |
6 | ldi temp, HIGH(UBRR_VAL) |
7 | sts ubrr0h,temp |
8 | ldi temp, LOW(UBRR_VAL) |
9 | sts ubrr0l,temp |
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.