Ich bin die Tage auf ein nettes Tool von Josh Bensadon gestoßen, den „CP/M Disk Explorer“. Mit diesem können unter Windows CP/M Images gelesen oder geschrieben/erzeugt werden. Weiterhin enthält er ein Tool, um gleich den DPB Block zu erzeugen oder auch eigene Formate zu kreieren. Für unsere Formate, AVRCPM und SIMHD habe ich mal in die Diskdefinitionen eingetragen, um die Images zu bearbeiten. Das Tool verzeiht jedoch keine Fehler. So muss das AVRCPM-Format exakt 256.256 Byte lang sein, ansonsten gibt’s „mecker“. In der ZIP-Datei gibt es als Laufwerk G gleich die aktuellen BIOS und CP/M Quellen.
Über Weihnachten ist mir aufgefallen, dass der Busy Test in der I2C_GPIO_out Routine NACH Ausgabe des Zeichens erfolgt. Das funktioniert auch, d.h. die Routine wartet sauber, bis der Drucker das Zeichen ausgegeben hat. Wenn der Druckvorgang allerdings schon ohne Papier oder Off-Line startet, wird das erste Datenbyte ins Nirvana ausgegeben und danach gewartet. Es wäre also besser die Testschleife
1 | GPIO_busy: |
2 | in a,(I2C_GPIO_DATB) |
3 | bit 0,a ; test bit 0 |
4 | jp nz,GPIO_busy ; wait while B[0] = 1 |
an den Anfang unmittelbar vor dem laden des Zeichens von (C) nach (A) zu verschieben. Ist nur eine Kleinigkeit. Der CPM-Disk-Explorer klingt ganz interessant - werde ich mal ausprobieren. Bislang habe ich mit dem cpmtools auf der Kommandozeile gearbeitet, funktioniert gut, man muss aber halt immer die Syntax im Kopf haben oder Skripte schreiben. Was ich aber noch mehr vermisse, sind Tools um die CP/M typischen Archive wie .LBR oder komprimierte Dateien (SQU, ARC, ZOO, ...) direkt unter Windows zu öffnen. Wenn ich so durch diverse CP/M Sammlungen gehe, wimmelt es da ja von solchen Dateien. Dazu kenne ich nur MS-DOS Tools, von denen es leider meistens keinen Quellcode gibt. Gibt es da eigentlich etwas, das wie ein Datei-Explorer unter Windows arbeitet? Ich wünschte mir da so einen Allesfresser, habe ihn aber nicht zu Weihnachten bekommen... Ich hatte schon mal angefangen, mir einen LBR-Leser und erste DeARCer und UnSQUeezer zu schreiben, das ist aber recht mühsam, wegen der vielen Kompressionsformate und Optionen. Die klassischen ZIP Dateien kann man ja gut mit diversen Tools inspizieren, aber für die älteren gibt es wohl keine "modernen" Tools mehr?
Martin H. schrieb: > Es wäre also besser die Testschleife... Das scheint mir eine sinvolle Änderung :-) > Gibt es da eigentlich etwas, das wie ein Datei-Explorer unter Windows > arbeitet? Ja, der TotalCommander mit einer entsprechenden Erweiterung [1]. Diese Erweiterung bindet quasi die CP/M Tools in den TC ein. Über Skripte [2] könnten nun die unterschiedlichen Packer für CP/M integriert werden. [1] https://hc-ddr.hucki.net/wiki/doku.php/cpm/disketten_xp2 [2] http://totalcmd.net/plugring/ScriptWFX.html
In den letzten Tagen habe ich noch eine RTC mit dem PCF 8563T implementiert, da ich kein fertiges breakout board mit dem 8583 bekommen habe. Der 8563 ist ähnlich aber nicht gleich wie der 8583. Der chip zählt Jahre von 0...99. Ich habe mich für 1970 als Basis entschieden und addiere bzw. subtrahiere dann 1970 um auf die aktuelle Jahreszahl zu kommen. Damit kann ich also 1970 bis 2069 abdecken, was für meine Lebenserwartung ausreichend ist. Ein RAM hat der chip nicht, wird auch nicht gebraucht. Ich habe das im Augenblick noch mit #if I2C_PCF8563 wie bei den anderen I2C Devices in meinem code stehen, werde aber noch die bisherige Variante für den 8583 ebenso klammern. Ich denke I2C_SUPPORT sollte nicht unbedingt automatisch die RTC einbinden - das ist ja auch nur eine Option, zumindest bei den älteren AVR-CPM-Stick boards. rtc_get funktioniert (z.B. beim booten), wo rtc_set verwendet wird, habe ich noch nicht herausgefunden... Martin
Ich denke es wird Zeit, mal eine Teildokumentation zu den I2C Komponenten nachzuliefern. Schließlich soll es ja keine Zweimannshow bleiben ;-) Im Anhang also die derzeit vom AVR-CP/M unterstützen I2C Komponenten mit ihrer Beschaltung. Deine RTC würde ich noch mit aufnehmen.
Ah sehr schön übersichtlich - gut auch, dass Du konsequent die sogenannten "7-bit" I2C Adressen angegeben hast - im Quellcode habe ich da auch immer so angepasst (beim PCF8583 stehen noch die "8-bit" Adressen drin, die sollten gelegentlich noch in (ADDR<<1) geändert werden, damit alles einheitlich ist). Der 8563 ist fast gleich wie der 8583, hat aber eine unveränderliche I2C Adresse von 0x51.
Angehängte Dateien:
-
Board_V1.0.jpg
380 KB
Hat jemand Interesse als Beta-Tester mitzuwirken? Geplant ist ein Bausatz für ein AVR-CP/M System mit heute verfügbaren Bauelementen. Dazu wurde der bisherige DRAM durch eine Schaltung mit einem SRAM ersetzt und getestet [1]. Die Software bleibt kompatibel. Um die Nachbausicherheit zu erhöhen und möglichst auch Anfängern den Aufbau zu erleichtern, wurde weitgehend auf SMD-Bauelemente verzichtet. Der Aufbau und die Inbetriebnahme soll dabei Schritt für Schritt, anhand einer Baumappe erfolgen. Dazu wurde die USB-Schnittstelle als Debug-Schnittstelle implementiert. Die folgenden Funktionen sind realisiert: 1 x RS232 (CP/M) 1 x LPT-Port (CP/M) 1 x PS2 Keyboard (VT100-Terminal) 1 x VGA (VT100 Terminal) 1 x RTC 1 x 8-Bit GPIO (3.3V) 1 x I2C-Bus (3.3V und 5V) 1 x SD-Card 1 x USB-Port Der USB-Port kann über DIP-Switch zur Inbetriebnahme wahlweise auf das AVR-CP/M oder das VT100-Terminal geschaltet werden. Im Normalmoduls ist dann das CP/M mit dem VT100 verbunden. Weiterhin kann zu Testzwecken der RS232-Port auf die USB-Schnittstelle umgelenkt werden. Gesucht sind zwei Beta-Tester (Aufbauerfahrung sollte vorhanden sein), die schrittweise nach Baumappe, das System aufbauen und ihren Aufbau bzw. Fehler dokumentieren. Weiterhin soll dabei gleichzeitig der Reichelt Warenkorb aktualisiert werden. Die gleiche Vorgehensweise gilt für die Softwareimplementierung. Ziel der ganzen Aktion ist ein freier robuster Bausatz für das AVR CP/M, ganz ohne kommerzielle Interessen. Beide Beta-Tester würden von mir je eine Leiterplatte (ohne Bauelemente) zur Verfügung gestellt bekommen. Interessenten melden sich bitte einfach per PN. [1] Beitrag "Re: CP/M auf ATmega88"
:
Bearbeitet durch User
Joachim W. schrieb: > Kannst du bitte den Schaltplan posten? Bitteschön. Die Schaltungen sind alle einzeln und zum Teil auch innerhalb des CP/M, aber noch nicht in diesem Layout getestet. > Alles auf einer Seite? Ja, alle Bauelemente befinden sich auf der Bestückungsseite.
Joe G. schrieb: > Joachim W. schrieb: >> Kannst du bitte den Schaltplan posten? > > Bitteschön. Die Schaltungen sind alle einzeln und zum Teil auch > innerhalb des CP/M, aber noch nicht in diesem Layout getestet. > >> Alles auf einer Seite? > Ja, alle Bauelemente befinden sich auf der Bestückungsseite. Vielen Dank :)
Mal so als Frage... wäre für eine Neuentwicklung mit SRAM vielleicht ein Atmega8515 sinnvoll (wegen XMEM)? Vor längerer Zeit habe ich für den einen i8080-Emulator umgesetzt. Der braucht 3 KB Flash, braucht selbst keinen RAM und besteht die Testsuite. Im Gegensatz zum AVR CP/M (der als Vorlage diente), habe ich das aber für avr-as geschrieben, weil mir C mehr Spaß macht als Assembler. Den Code habe ich mal angehängt. Weil avr-as keine halben Pointer mag, generiert das Perlscript aus i8080.o eine i8080_tables.S, die man zum Projekt dazulinken muss. Der i8080 wird mit emu_start() aufgerufen und ruft folgende Funktionen auf:
1 | // wenn EMULATE_IO aktiviert:
|
2 | uint8_t emu_io_read(uint8_t port); |
3 | void emu_io_write(uint8_t port, uint8_t data); |
4 | |
5 | // wenn BDOS aktiviert (für CONOUT und PRINTSTR):
|
6 | void uart_putc_raw(uint8_t); |
7 | |
8 | // wenn TRACE aktiviert:
|
9 | int printf_P(const char *fmt, ...); |
Mit MEMBASE lässt sich die Basisadresse des i8080-Adressraums im AVR-Adressraum in 256 Byte-Schritten einstellen. Die CPU startet bei 0x0000 oder bei aktiviertem BDOS bei 0x0100. Der i8080 lebt im und hat vollen Zugriff auf den AVR-Adressraum, inklusive der SFRs und CPU-Register. Auf einem Atmega8515 ließe sich also maximal ein 63 KB CP/M bauen (mein Testsystem hat aber nur 32 KB), dafür kann man den Emulator auch direkt im internen RAM laufen lassen. Die Performance habe ich nicht gemessen, aber wenn ich mich beim Taktezählen nicht vertan habe, braucht ein NOP nur 32 Takte. Viel Optimierpotential sehe ich da nicht.
S. R. schrieb: > Mal so als Frage... wäre für eine Neuentwicklung mit SRAM vielleicht ein > Atmega8515 sinnvoll (wegen XMEM)? Es ist ja keine Neuentwicklung, sondern ich habe einfach die Baugruppen und Software, welche so nach und nach entstanden sind, auf eine Leiterplatte gebracht. Der Wechsel von DRAM auf SRAM ist nur meinem persönlichen Spieltrieb geschuldet ;-) interessanter ist die Frage nach der Sinnhaftigkeit eines solchen Projektes. Stein des Anstoßes waren Studenten des 7. Semesters, welche wahllos 5V Systeme mit 3.3V Systemen zusammenschalten, keinen Bus debuggen können, weder SMD noch THT ordentlich löten können, nur rudimentär programmieren können, keine systematische Fehlersuche durchführen können… Die Aufzählung kann noch beliebig erweitert werden. Zukünftig sollen interessierte Studenten des ersten Semesters einen Bausatz in die Hand gedrückt bekommen und ihn unter fachkundiger Begleitung in Betrieb nehmen. Mal sehen, was sich dann daraus entwickelt.
Wirklich schön, wie sich das alles so weiter entwickelt hat! Insbesondere die I2c Unterstützung. Kann auch sein, das hier alles inkl VT100 Terminal genau die richtige Lösung ist für den skizzierten Einsatzzweck. Aber ich bin kein Freund von dem VT100 mit auf der Platine. Dazu kann man besser jedes Terminal Programm und USB-TTL Schnittstelle nehmen - ist aber nur meine Meinung. Ich mag halt keine Propeller Chip da drauf, nur fürs Terminal ;-) Peter
Holla, das ist ja schon ein richtiger Großrechner mit allem Drum und Dran! Wenn man das noch mit einer kleinen Tastatur (gibt es so etwas wie die Cherry Kassentastaturen G84-4100 auch mit PS/2?) und einem kleinen TFT Display kombiniert, könnte man einen schicken kleinen CP/M Laptop bauen. Onkel Osborne lässt grüßen. Zum VT100 Emulator habe ich noch eine Idee/Frage: Beim Programmieren kommt sehr schnell der Wunsch nach Grafik auf. CP/M bietet da per Definition nichts (GSX ist etwas hoch gegriffen und schluckt Speicher), aber man kann einfache, aber durchaus ansprechende Vektorgrafik leicht mit jeder Programmiersprache realisieren, wenn das Terminal passende Escapesequenzen unterstützt. Wenn ich z.B. Teraterm als Soft-Terminal verwende, versteht dies auch Tektronix Befehle und macht sogar ein extra Grafikfenster auf. Dann kann ich von meinem AVR-Stick Text und Grafik sogar "gleichzeitig" ausgeben. Ich mag Tektronix, aber wenn es moderner sein soll, wären auch Regis (DEC) oder HPGL (Plotterbefehle in ASCII) mögliche Alternativprotokolle. Deshalb die Frage: kann der Propeller-Code erweitert werden, sodass er auch einen Grafikbildschirm (als Alternative zum Textmodus) anzeigen könnte? Oder reicht da der Speicher nicht für z.B. 640x400 monochrome Pixel (=32 KB). Eventuell wäre da eine separate, optional andockbare Terminalplatine sinnvoll.
:
Bearbeitet durch User
hi, frage ... warum wurde der ram nicht via spi interface integriert, wäre auch nicht langsamer als parallel und mit addr latch und so? mt
Hallo Joe, ich finde die Idee richtig gut... und ich wäre auch wieder dabei. Gruß Hans-Werner
Apollo M. schrieb: > hi, frage ... warum wurde der ram nicht via spi interface integriert, > wäre auch nicht langsamer als parallel und mit addr latch und so? Schau mal hier: Beitrag "Re: CP/M auf ATmega88" Martin H. schrieb: > Zum VT100 Emulator habe ich noch eine Idee/Frage: Ich schreib morgen mal was dazu...
Apollo M. schrieb: > hi, frage ... warum wurde der ram nicht via spi interface integriert, > wäre auch nicht langsamer als parallel und mit addr latch und so? Kannst du das einmal vorrechnen, wie viel Zeit nach der einen bzw. nach der anderen Anbindung gebraucht wird.
Martin H. schrieb: > Zum VT100 Emulator habe ich noch eine Idee/Frage: Die RAM-Größe des Propellers beträgt nur 32KB. Für eine Pixelgrafik also zu wenig. Ich denke, eine TEK4010 Emulation wird nicht möglich sein. Um dennoch mit unterschiedlichen Zeichensätzen und Grafikelementen zu arbeiten, können verschiedene Character Sets [1] umgeschaltet werden. Für eine Weiterentwicklung würde ich den Propeller verlassen und ein anderes Konzept favorisieren (RaspberryPI / Bare Metal [2]). Zumal HDMI und USB bzw. Bluetooth-Tastaturen heute üblicher als VGA und PS2 sind. Das ist jedoch eine andere Baustelle ;-) [1] Beitrag "Re: VT100-Terminal (VGA+PS2)" [2] https://ultibo.org/
Angehängte Dateien:
-
Step_1_k.jpg
270 KB
Die ersten Platinensätze sind eingetroffen. Ich baue nun ein Startmuster auf, um jeden einzelnen Inbetriebnahmeschritt zu dokumentieren bzw. Fehler auszumerzen. Im nächsten Schritt dürfen dann die Betatester ran ;-)
moin, spiele gerade RunCPM auf einem TeenSy3.6 rum. echt beeindruckend. beim 180MHz CPU-takt geht da schon einiges los. gab es hier nicht mal einen benchmark um das ganze mal etws einordnen zu können? als terminal habe ich hier tera-term als vt100. laufwerke sind auf einer sd-card.
Horst S. schrieb: > gab es hier nicht mal einen benchmark um das ganze mal etws einordnen zu > können? Ja, wie ein Z80 mit etwa 3.2 MHz.
Wir haben immer ein eigenes Testtool (ACT) laufen lassen. Dieses findest du hier: https://www.mikrocontroller.net/svnbrowser/avr-cp-m/avrcpm/trunk/cpm/utils/
Angehängte Dateien:
-
Ready_1.jpg
470 KB -
Ready_2.jpg
230 KB
Der erste Schritt ist getan. Das System läuft und das Layout bzw. die Leiterplatte sind (fast) fehlerfrei. An zwei Stellen ist der Bestückungsaufdruck um 180 Grad gedreht. Die Aufbaudokumentation wird an diesem WE auch fertig werden, so dass Interessenten loslegen können. Da der LP-Hersteller überliefert hat, kann ich in Summe noch 5 Platinen zum Testen abgeben. Hans-Werner und Marcel sind schon berücksichtigt;-) Die Dokumente zum Aufbau und die komplette Software wird vollständig in Github [1] abgelegt. [1] https://github.com/Feinmechaniker/AVRCPM
Leo C. schrieb: > Horst S. schrieb: >> wo gibt es den test? > > Beitrag "Re: CP/M auf ATmega88" danke, aber wie bekomme ich das image auseinander?
Horst S. schrieb: > danke, aber wie bekomme ich das image auseinander? Mit den CP/M tools? Die Images sind (wie meistens) im simhd Format. Aber warum überhaupt? Warum nicht einfach auf eine SD-Karte kopieren?
Ich habe gerade mal beide Benchmarks auf dem neuen System
(abgeschalteter Refreshzyklus) laufen lassen. Mit dem Hi-Tech C liegt
der Test recht stabil bei 27 bis 28 Sekunden.
DHRYSTONE 1.1 BENCHMARK SUMMARY
SORTED BY PERFORMANCE
MANUF MODEL PROC CLOCK NOREG REG OS,COMPILER,NOTES
----- ----- ---- ----- ----- --- -----------------
Commodore 64 6510 1.00 19 34 C64 ROM ,C Power 2.9
trim,
Apple IIe 65C02 1.02 37 37 DOS 3.3,Aztec CII
v1.05i ,
Home Brew Z80 4.00 53 53 CPM-80 ,Hisoft C++ ,
Commodore 128 8502 2.00 43 68 C128 ROM ,C Power 128
trim,
Home Brew Z80 2.50 91 91 CPM-80 2.2,Aztec CII
1.05g,
Cromemco Z2 Z80 4.00 127 127 Cromix 11.26,ccc ,
NCR Decision M 8088 4.77 166 166 MS-DOS 2.11,Lattice
2.14
*Aeternum AVRCPM Z80emul ~3. 172 185 CPM-80 2.2,HI-TECH C
V3.09
Home Brew 8086 8.00 197 203 iRMX-86 V6,Intel C-86
2.0
NCR PC4 8088 0.00 212 212 MS-DOS 2.11,Lattice
2.14
:
Bearbeitet durch User
Leo C. schrieb: > Warum nicht einfach auf eine SD-Karte kopieren? RunCPM verwendet nur noch das FAT-Filesystem, es gibt kein Image mehr.
TeenSy 3.6 H>drynr Dhrystone(1.1) time for 5000 passes = 0 This machine benchmarks at 0 dhrystones/second RunCPM Version 3.7 (CP/M 2.2 60K)
Joe G. schrieb: > RunCPM verwendet nur noch das FAT-Filesystem, es gibt kein Image mehr. Ach ja, darum gings ja. Aber wie man auf dem PC Dateien aus einem Image heraus oder hineinkopiert, wurde hier ja schon öfters beschrieben. Horst S. schrieb: > Dhrystone(1.1) time for 5000 passes = 0 Du mußt die Funktion time() für das RunCPM-System anpassen, oder das Dhrystone-Programm so kompilieren, daß Du mit einer Stoppuhr messen kannst. Die Anzahl Loops muß evtl. auf 50000 oder 500000 hochgesetzt werden. Die Anleitung dazu ist im Sourcecode "dry.c" enthalten. Im Anhang Benchmark und Hi Tech C Compiler ohne Image.
Angehängte Dateien:
-
capture.bmp
6,1 MB
Martin H. schrieb: > @ David R. > Did you use an SD card (not SD-HC)? > The boot messages look like the card is not recognized. > Try with a plain old SD card (2 GB or so). @ Martin H. im using a samsung 4G card and toshiba 2GB FAT formatted under windows
David R. schrieb: > im using a samsung 4G card and toshiba 2GB FAT formatted under windows Any 4G SD card is SD-HC (there are very few exceptions). Your screenshot is surprisingly bad. Please do not capture more than needed (no white areas), and upload screenshots as PNG. See the rules listed above the response field. Also, you seem to have other problems as well: See the line about the C: drive, it is not shown correctly. Try to test your board without CP/M. I think something else is fishy.
Anbei ein XMODEM für das System mit I2C-UART über RDR: und PUN: Ich habe die Config-Datei gleich angepaßt. Damit geht das Kopieren von Datein zwischen CP/M und PC auch ohne Kermit recht fix.
Angehängte Dateien:
-
AVR-CPM-Stick-MultiTel-D.jpg
230 KB
Hallo zusammen, nur als Appetizer - was man so mit einem CP/M-AVR System (in diesem Fall der gute, alte CP/M-Stick) so machen kann. Das MultiTel-D zeigt 80x24 Zeichen und hat eine serielle Schnittstelle sodass man es als Terminal benutzen kann. Der CP/M-AVR Stick pass in den Raum für den integrierbaren Drucker - dann hätte ich einen kompakten, portablen CP/M Rechner ;-) Habe nur noch nicht herausgefunden, auf welche Escape-Sequenzen es reagiert (CTRL-L löscht schon mal den Bildschirm). Martin PS: wenn die aktuelle Platine die serielle Schnittstelle für das Terminal auf zusätzlich herausführen würde (einfache Steckerleiste mit oder ohne MAX232 reicht), könnte man eventuell auch für die Puristen eine Alternative ohne Propeller-Chip und PS/2 mit der gleichen Platine aufbauen.
Schöner Aufbau Martin :-) Die Bestückung des Propellers ist für das CP/M nicht zwingend notwendig (siehe Übersicht). Es können 1. per USB alle seriellen Schnittstellen (AVR, Propeller, RS232) angesprochen werden 2. direkt RS232 (9 polig D-SUB) benutzt werden 3. RS232 auf USB umgelenkt werden Man kann also auch CON: auf CRT: legen und CRT: auf USB ;-) Anbei noch zwei Tools um das VT100-Terminal im CP/M besser zu bedienen. CSET.COM schaltet zwischen den beiden Character Sets um. Der erste Parameter ist für G0 und der zweite Parameter für G1. Möglich sind US, UK, DE, DE, DEC und SUP. CSET US DE lädt also das US Set nach G0 und DE nach G1. Mit PSCS.COM kann sich dann der verfügbare Zeichenvorrad angezeigt werden. Den Quelltext gibt’s hier [1]. [1] https://github.com/Feinmechaniker/AVRCPM
Angehängte Dateien:
-
Ready_3.jpg
160 KB -
Ready_4.jpg
150 KB
Zu jedem Projekt gehört auch ein ordenliches Gehäuse :-)
Rene K. schrieb: > Wäre da noch eine Platine übrig? ? Ja, sende mir mal eine PN mit deiner E-Mail. Alle anderen Platinen habe ich heute, da nun alles ins Gehäuse paßt, in die Post gegeben. Sie sollten also nächste Woche eintreffen.
Joe G. schrieb: > Rene K. schrieb: > Wäre da noch eine Platine übrig? ? > > Ja, sende mir mal eine PN mit deiner E-Mail. > Alle anderen Platinen habe ich heute, da nun alles ins Gehäuse paßt, in > die Post gegeben. Sie sollten also nächste Woche eintreffen. Danke, habe dir eine PN geschickt ?
Ich bin gerade am Bestellen der BOM. Bei dir im GIT gibt es jetzt zwei verschiedene Versionen der Part-List. Ich gehe davon aus das die 1.0 aktuell ist und nicht 1.2? Platine ist ja 1.0. Der Reichelt Warenkorb ist auf die 1.0 ausgelegt? So mal fix drüber geschaut... Ist da der Propeller schon dabei oder muss ich den Extern organisieren?
Die Schaltung hat sich von der Version 1.0 auf die Version 1.2 nicht geändert. Die Änderungen betreffen ausschließlich Das Layout und den Bestückungsaufdruck (siehe Errata). Es ist also günstig die BOM und die Partlist der Version 1.2 zu nutzen bis auf C21 (100n), der ist in der Version 1.0 noch ein SMD 100n Baugröße 0805. Speziell C17 und C18 (18p) sollten in 0603 für die V1.0 bestückt werden. Es ist sonst eine arge Fummelei. Der Reichelt Warenkorb ist nicht vollständig (!) Ich habe zwar versucht alles zu erfassen, aber eine Kontrolle ist besser. Ob man die IC’s sockelt, muß zudem jeder selbst entscheiden. Ich hatte s im meinem Muster getan, um bei Fehlern eingreifen zu können. Prinzipiell halte ich es beim 8-Bit GPIO (PCF8574), RS232 Treiber (MAX3222) und dem 16-Bit GPIO (MCP23017) für sinnvoll. Weiterhin muss beim PCF8574 (8-Bit GPIO) darauf geachtet werden, welche Version man mag. Der PCF8574 hat die Adresse 0x20 und der PCF8574A die Adresse 0x38. Das muss bei den Einstellungen im Softwareteil des AVR „config.inc“ beachtet werden. Default ist der PCF8574. Der Propeller ist nicht mit im Reicheltkorb, den gibt es dort nicht. Weiterhin fehlt dort die Fassung für die SD-Card (Würth 693063010911). Ich freue mich über jede Ergänzung und Berichtigung.
Super, danke... Da setze ich mich heute Abend mal dran und Ergänze / Berichtige die Liste. An die SD-Card Fassung komme ich durch Vitamin B zu WE. Und kann hier welche zum Selbstkostenpreis anbieten.
Platine kam heute wohlbehalten bei mir an. Mensch hätte ich gewusst das du quasi "Um die Ecke" kommst, hätte man sich ja auch mal treffen können :-D P.s.: Ich habe nun den gesamten Thread nicht verfolgt (alle 100 Seiten). Aber ist es nicht möglich die VT100 Terminal Abfrage nicht auch auf ein Atmel der AtmegaX8 Reihe auszulagern? Die 4KB Ram dürften doch, rein theoretisch, für ein 80x24 Terminal völlig ausreichend sein. Gut, das VGA Timing müsste dann etwas "neben der Spezifikation" laufen. Aber dürfte machbar sein. Was sprach da für den Propeller?
:
Bearbeitet durch User
Rene K. schrieb: > Mensch hätte ich gewusst das > du quasi "Um die Ecke" kommst, hätte man sich ja auch mal treffen können Das können wir ja immer noch :-) > Was sprach da für den Propeller? Es gibt sogar eine Variante mit einem AVR als Terminal [1]. Es geht jedoch arg eng mit dem Timing um und viel Luft ist für eine farbige Darstellung auch nicht. Der Propeller hat deutlich mehr Geschwindigkeit und außerdem läuft noch ein AY-3-8910/YM2149 mit. [1] Beitrag "Re: CP/M auf ATmega88"
Angehängte Dateien:
-
Bild1.png
100 KB
Joe G. schrieb: > Das können wir ja immer noch :-) Sehr gerne :-) Mir fällt gerade die nächste Frage ins Auge: Sie dazu Bild 1. Der AtmegaXX8-PU oder auch P-PU läuft unter 3V3 doch garnicht auf 20Mhz sondern laut DB bloß 0-10Mhz unter 2.7-5.5V und 0-20Mhz unter 4.5-5.5V. Gibt es vom AtmegaXX8 auch ein Derivat welcher mit 20Mhz unter 3V3 spezifiziert ist?
Rene K. schrieb: > Gibt es vom AtmegaXX8 auch ein Derivat welcher mit 20Mhz unter 3V3 > spezifiziert ist? Nein, gibt es nicht. Bisher laufen aber alle von mir (und auch anderen)eingesetzten IC's ohne Probleme. Damit sie ordentlich anschwingen, ist das Fuse Bit auf "Full Swing Crystal" gestellt.
:
Bearbeitet durch User
Hallo, gestern endlich angefangen zu bauen, ich habe schon einige Fehler gefunden und auch einige Verbesserungsvorschläge. Ich bin jetzt 3 Wochen auf Reha... da finde sicherlich Zeit alles nieder zuschreiben (geht zu Joe per Mail). Mein Problem ist im Moment der SC16IS740, wo bekommt man das Teil günstig her? (ich würde auch mehrere nehmen). Zu dem Quarz sag ich mal nichts... Gruß Hans-Werner
Hans-Werner Schütz schrieb: > Mein Problem ist im Moment der SC16IS740, wo bekommt man das Teil > günstig her? (ich würde auch mehrere nehmen). Hier z.B: https://de.aliexpress.com/item/Freies-verschiffen-10-teile-los-in-lager-SC16IS740IPW-SC16IS740-16IS740-neue/32951175613.html?spm=a2g0x.search0104.3.7.12109c48i1H8VO&transAbTest=ae803_5&ws_ab_test=searchweb0_0%2Csearchweb201602_9_10065_10068_10547_319_317_10548_10696_10084_453_10083_454_10618_10304_10307_10820_10821_537_10302_536_10902_10843_10059_10884_10887_321_322_10103%2Csearchweb201603_35%2CppcSwitch_0&algo_pvid=9351d2e4-3607-4f97-b208-b53773bf6e39&algo_expid=9351d2e4-3607-4f97-b208-b53773bf6e39-1
Rene K. schrieb: > Super, danke... Da setze ich mich heute Abend mal dran und Ergänze / > Berichtige die Liste. > > An die SD-Card Fassung komme ich durch Vitamin B zu WE. Und kann hier > welche zum Selbstkostenpreis anbieten. Hallo René, hast Du schon die Liste ergänzen können? Sprich: welche Teile sind im Reichelt Warenkorb nicht enthalten? An der SD-Card Fassung hätte ich Interesse, sofern Du noch eine abtreten möchtest. Beste Grüße, Mathias P.S.: wieder einmal ein tolles Projekt von Joe G. mit einer sehr sauberen Doku! Ich habe bereits den AX81b und den CP/M-Stick aufgebaut - funktioniert beides klasse. Herzlichen Dank dafür!
Hallo, habe meine Platine soweit aufgebaut. VT100 geht, i2cscan findet die I2C Bauteile. Was mir beim Bestücken aufgefallen ist: Thermal-Pads lassen sich schlecht löten. Habe zwar kein Problem 0603 zu löten, aber es ist ja Platz für z.B. 0805. Den Quarz für den SI16... könnte man besser löten, wenn die Pads größer wären (hallo Hans-Werner), oder gleich HC-49. Ein Problem habe ich noch mit der RTC: im Reichelt Warenkorb steht das Ding als PCF 8583T DIP8, aber T ist SMD. Also habe das Chip erstmal auf einen 8er Dip-Sockel geprokelt. Solange das Board extern versorgt wird, ist die Abweichung nur minimal. Läuft die RTC auf der CR2032, ist die Abweichung einige Minuten in Plus. Schon ein CPM Hardware-Reset bringt die RTC einige Sekunden ins Plus. Kann man den RTC-Treiber permanent laden? Gruss Peter
Vielen Dank für deine Hinweise! Die Beschaltung um den SI16.. stelle ich auf „freundliche“ Bauelemente um. PCF8583T ist natürlich nicht korrekt, auch wenn Reichelt DIP8 dazu schreibt. Hier muss der PCF8583P in den Warenkorb. Das Problem mit der Uhr kann ich bei mir nicht nachvollziehen. Die Uhr läuft bei mir seit einem Monat korrekt (egal ob bei externer Versorgung oder der CR2032) auch ein CP/M-Reset ändert die Uhrzeit nicht. Mal sehen, was die anderen dazu sagen...
Hans-Werner vielen Dank für deine Anmerkungen und Korrekturen! Eine neue Doku liegt nun unter Github. Die Schalterstellungen sollten jetzt auch der Schaltung entsprechen und der VT100 Teil ist auch ergänzt.
Hallo Joe, jetzt fehlt nur noch ein Gehäuse... hast du das schon in der Produktion? :-) Das kann nicht jeder produzieren, und würde mich interessieren. Gruß Hans-Werner
Das Gehäuse ist schon als Muster fertig. Beitrag "Re: CP/M auf ATmega88" Ich hoffe bei erner entsprechenden Menge auf einen akzeptablen Preis.
Hallo Joe, mal ne Frage zum Trimmer C12 am PCF8583P. Ein Ende geht an Pin 1 und das andere an 3,3V. Sollte das nicht an D1,D2 bzw. Pin8 gehen? Wenn die 3,3V nicht da sind, hängt er ja in der Luft. Könnte ja mein Problem sein. Gruss Peter
Habe jetzt mal den C12 an Pin8 gehängt, jetzt läuft die RTC mit richtiger Uhrzeit im Batterie Betrieb. Die Änderung ist einfach durchzuführen: C12 von 3,3V trennen und mit Pin8 verbinden. @Joe Es wundert mich, daß Du da kein Problem hast. ps: melde mich für ein Gehäuse an. Gruss Peter
:
Bearbeitet durch User
Peter Z. schrieb: > Die Änderung ist einfach durchzuführen: > C12 von 3,3V trennen und mit Pin8 verbinden. Das ist ja ein dicker Hund ;-) Natürlich muss C12 an Pin8. Offensichtlich läuft meine Uhr auch ohne C12 genau. Die Gehäusewünsche sammle ich mal...
Hallo, Hiobsbotschaften... das mit den UARTS SC16IS740 hat nicht geklappt, der Lieferant kann nicht liefern aliexpress hat das Geld erstattet..?? Hab es dann bei E... versucht..und bis jetzt nichts erhalten. Hat da einer noch eine Quelle wo die Dinger auch bezahlbar sind? @Joe soll da noch etwas mit dem Gehäuse kommen? Gruß Hans-Werner
Da das Projekt in Richtung Bausatz läuft, beschaffe ich die Bauelemente in der Losgröße 10. Bei Mouser ist das IC für 2.47€ + Steuer verfügbar. Ich würde einfach für dich (vielleicht noch weitere Interessenten) mitbestellen. Auch das Gehäuse ist noch aktuell. Hier warte ich noch auf die Rückkopplung der Betatester bzw. final auf das endgültige Angebot in der Losgröße 10.
Hallo liebe (AVR)CP/M Freunde. Ich werde mir die nächsten Wochen mal wieder ein AVR CP/M Stick aufbauen. Da mein Stand inzwischen 'etwas' veraltet ist, würde ich nach erfolgreichem Aufbau dann den Stand von Martin flashen wollen: https://www.mikrocontroller.net/attachment/379658/AVRCPM-SER-PAR.zip (Danke für die tolle Beschreibung und fertiges HEX!) Frage zum I2C Uart. Wäre so etwas verwendbar (ohne SW Anpassungen): https://www.ebay.de/itm/SC16IS750-CJMCU-750-Single-UART-w-I2C-Bus-SPI-Interface-For-Industrial-Control/163595853069?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m1438.l2649 -- Ich habe mir dann noch mal den Stand des Artikels angeschaut. Der ist - hmm.. leider inzwischen völlig veraltet - und eher verwirrend! Gibt es da Bestrebungen, die älteren Optionen (z.B. Partitionen) auch unter "Historische/Alte Optionen" zu stellen und den aktuellen Stand evtl. auch nach oben, neu einzufügen? Ist finde es etwas 'blöd' wenn man sich erst durch alle historischen Versionen liest, evtl. schon anfängt.. und erst danach feststellt, das ein Atmega88 oder 168 eben nicht mehr ausreicht für die aktuelle Version, sondern ein Atmega328p der 'richtige' Chip ist. Gleiches gilt für FAT16/SD-Karte und Disk-Images.. Peter
Hallo Peter, den derzeit aktuellen Stand (incl. I2C und IO-Byte von Martin), findest du hier [1]. Dort sind dann auch die Quellen für den AVR das CP/M sowie schon übersetzte HEX-Files. > Frage zum I2C Uart. Wäre so etwas verwendbar (ohne SW Anpassungen): Der von dir verlinke EBAY-Artikel ist zum Softwarestand kompatibel. Mit dem Artikel hast du Recht. Hier würde etwas Überarbeitung guttun. Ich versuche es mal… [1] https://github.com/Feinmechaniker/AVRCPM
Hallo Joe. Ich habe mir mal erlaubt den Artikel etwas aufzubereiten. Evtl. bietet sich nun die Aufnahme der jetzt aktuellen Hardwareversion mit VT100 und I2C inkl. Gehäuse an? Und ggf. die Software Rubrik müsste sicher auch aktualisiert werden ;-) Peter
Peter S. schrieb: > ... > Frage zum I2C Uart. Wäre so etwas verwendbar (ohne SW Anpassungen): > Ebay-Artikel Nr. 163595853069 > ... Hallo Peter, genau so ein Board habe ich mit meinem CP/M-Stick verwendet (Platine kam damals von Dir). Wenn Du vom gleichen Anbieter noch 162722531579 mit bestellst, kannst Du auch den parallelen Centronics-Port anbauen. Braucht dann noch zwei 3.3->5V level converter für I2C und einen 5V Stromversorgung. PS: Ich habe mir dann noch eine 5V Powerbank dazu gebaut. Die kommerziellen Powerbanks schalten leider ab, wenn nicht genügend Strom gezogen wird. Deshalb habe ich mir eine selbst gebaut mit USB-LiPo-Ladeplatine (z.B. 162764857644), einer Pollin 3.6V LiPo Telefonzelle und 3.6V auf 5V Converter. Dann hat man ein portables CP/M System, das man schnell an jedes Terminal anschließen kann. Das teuerste war das 2.5 Zoll Aluminium Festplattengehäuse für die Powerbank. Martin
Hallo Joe, endlich den Uart bekommen.... wie sieht es mit Gehäuse aus? Gruß Hans- Werner
Hallo Joe. Ich habe nun viele Stunden Fehlersuche hinter mir, weil nach einiger Zeit das System sich mit Dump 76 76 weghängte. Habe mit dram_waitstate und dram_refresh Angaben in config.inc gespielt - bis ich heute auf die Idee kam, mir mal dram-refresh.asm anzuschauen:
1 | ; ------------------- DRAM Refresh Interrupt -------------------- |
2 | |
3 | .cseg |
4 | |
5 | INTERRUPT OC2Aaddr |
6 | reti ; only for SRAM |
7 | |
8 | sbis P_RAS,ram_ras ;2 |
9 | ... |
Das oberste reti gehört wohl erst einmal auskommentiert im Repo :-( Und zukünftig eher als define in config.inc und entsprechend dann darüber aktiviert, wenn SRAM definiert wurde. ;-) Peter
:
Bearbeitet durch User
Oh, sorry! Da ich unter Github nur die Daten für die DRAM Version bearbeitet hatte, ist mir das nicht aufgefallen bzw. ich hatte es nach dem damaligen erfolgreichen Hardwaretest ganz vergessen in der config.inc zu implementieren. :-( Hans- w. S. schrieb: > wie sieht es mit Gehäuse aus? Der letzte Betatester hatte mir erst letzte Woche alle Wünsche/Probleme/Änderungen zukommen lassen, so dass ich nun erst dazu komme auch diese Änderungen einfließen zu lassen. Letztlich kommt es dann noch auf die Stückzahl an. Ein Einzelmuster ist derzeit wirklich sehr teuer.
Hallo Joe, ich nehme ein Bausatz mit Gehäuse und ein Gehäuse für den Prototyp. Gruß Hans-Werner
moin, ich suche für den alten c't Prommer-80 die software. gab es die auch als quelle?
Da kann ich weiterhelfen, es gab Pascal und Assembler Versionen, kann aber erst heute abend danach schauen.
moin, dann hatte ich wohl die pascal-version. beim umstieg von cp/m auf den ersten pc hatte ich alles auf disk's im ibm-format abgespeichert und eingelagert. leider haben einige davon die lagerdauer nicht überstanden. ich hatte damals mit einem freund einen universal formatierer für cp/m gebaut. der konnte das disk-format für einzelne drives beliebig anpassen. so haben wir damals das formatchaos etwas in den grief bekommen.
In der c't 03/1985 ab Seite 76 ist das Pscal-Programm abgedruckt. Sollte also kein Datenträger auftauchen, kann man das notfalls noch abtippen.
moin, Danke an alle. @günter leider sind die sourcen der tp routinen beschädigt. da hängen unvollständige textteile drinn. ich habe hier noch die sourcen in asm vom "Z80 BASIC Ver 4.7c" von MS. leider sind auch da fehler drinn, diese habe ich begradigt. zudem sind einige befehle wie Cload und Csave nicht realisiert. hat da noch jemand was vollständiges?
:
Bearbeitet durch User
moin,
öhmmm..... watte im kopf.
habe mal statt z80asm die m80/l80 kombi genommen.
m80 =test/L/N
alle ok, prn-file bestens.
l80 test,test/N/E
es wird eine test.com erstellt. läuft aber nicht.
also ddtz test.com
DDTZ v2.7M by CB Falconer. CPU=Z80
Next PC Save
0380 0100 3
-d
0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0130 00 00 00 00 00 CD 29 0B FE 29 C4 9D 04 C3 40 0B ......)..)....@.
0140 3E 01 32 2F 3D C3 59 2B AF 32 2F 3D C3 59 2B AF >.2/=.Y+.2/=.Y+.
0150 32 2D 3D C3 59 2B CD 55 0B C2 47 2B 0C 0D CA 47 2-=.Y+.U..G+...G
0160 2B F5 CD 0E 0C C4 24 0C C2 3A 2B 7E F6 40 77 F1 +.....$..:+~.@w.
0170 FE 2C C0 CD 55 0B C2 C1 04 C3 2C 2B 3E 01 32 2D .,..U.....,+>.2-
0180 3D C9 3E FF 32 2E 3D C3 59 2B AF 32 2E 3D C3 40 =.>.2.=.Y+.2.=.@
0190 0B 3E 01 32 2E 3D C3 59 2B AF C3 7D 2B 3E FF C3 .>.2.=.Y+..}+>..
01A0 7D 2B 3A 8D 40 2F 6F 3A EC 3C B7 CA 59 2B 7D 32 }+:.@/o:.<..Y+}2
01B0 8D 40 32 2A 3D C3 59 2B 3E 01 32 EA 3C C3 59 2B .@2*=.Y+>.2.<.Y+
-
das schaut nicht nach dem aus was im prn steht......
0000 boot equ 0000h ; system reboot
0005 bdos equ 0005h ; bdos entry
point
005C fcb1 equ 005ch ; first file name
005C sfcb equ fcb1 ; source fcb
006C fcb2 equ 006ch ; second file
name
0080 dbuff equ 0080h ; default buffer
0100 tpa equ 0100h ; beginning of
tpa
;
0009 printf equ 9 ; print buffer
func#
000F openf equ 15 ; open file func#
0010 closef equ 16 ; close file
func#
0013 deletef equ 19 ; delete file
func#
0014 readf equ 20 ; sequential read
func#
0015 writef equ 21 ; sequential
write
0016 makef equ 22 ; make file func#
;
org tpa ; beginning of tpa
0100' 31 0239' lxi sp,stack ; set local stack
0103' 0E 10 mvi c,16 ; half an fcb
0105' 11 006C lxi d,fcb2 ; source of move
0108' 21 01D9' lxi h,dfcb ; destination fcb
010B' 1A mfcb: ldax d ; source fcb
010C' 13 inx d ; ready next
010D' 77 mov m,a ; dest fcb
010E' 23 inx h ; ready next
010F' 0D dcr c ; count 16...0
0110' C2 010B' jnz mfcb ; loop 16 times
;
;
was mache ich da falsch???????????????
ok, gefunden........ das /P:0100 ist wohl nicht default und muss vor dem laden des files pasieren. L80 /P:0100,DEMO,DEMO/N/E
ne, doch nich.... irgendwie habe ich beim linken immer noch einen offset von 0100h drinn. in der com-datei liegt der code erst ab 0200h.
Hallo Horst, entweder Du assemblierst absolut:
1 | ASEG |
2 | ORG 100H |
oder Codesegment-relativ (CSEG bzw. default) und läßt ORG dann weg, und sagst dem Linker mit /P:, wohin geladen werden soll.
DANKE!!!!!!!!!!!!!!!!!!!!!! man oh man.... peinlicher fehler. ich habe den fehler im linker gesucht. im m80 prn sah das doch alles ok aus.
:
Bearbeitet durch User
Weil ich in letzter Zeit viel mit meinem AVR-CP/M Stick gearbeitet habe (GSX-80 Grafik mit Fortran und CBASIC), habe ich mir zwei Windows Befehlszeilen-Skripte geschrieben, um ein Backup von den 8 MB Festplattendateien zu erzeugen. Dieses Backup erfolgt dateiweise, d.h. ich habe dann alle Einzeldateien in einem Verzeichnisbaum unter Windows liegen. Ein Skript kopiert mit Hilfe der CPMTOOLS alle Dateien in User-Unterverzeichnisse und das andere Skript kopiert alles wieder zurück in Image Dateien. Damit kann ich jetzt bequem Einzeldateien unter Windows ansehen, austauschen oder ändern und später wieder alles zurückspielen ohne jedesmal manuell CPMTOOLS Befehle eingeben zu müssen. Nur die SD-Karte muss ich natürlich noch umstecken. Für das Zurückkopieren werden komplett neue Image Dateien angelegt, wofür noch ein leeres Image als Vorlage benötigt wird. Ausserdem CPMCP aus den CPMTOOLS und natürlich die passende DISKDEFS Datei mit einer Definition für "avr8M". Ist vielleicht auch für andere Nutzer interessant. Martin
Hallo zusammen, ich habe über die Tage mal einen Emulator auf Breadboard aufgebaut und bin sowohl von der simplen Konstruktion als auch von der Performance mit einem atmega328p begeistert. Gar nicht so einfach, sich durch die 10-jährige Historie zu wühlen - trotz der Bemühungen Eurerseits, die Sache immer wieder zusammen zu fassen. Ich habe vor über 30 Jahren auch so meine Erfahrungen mit CP/M machen dürfen, erst mit einem Apple II + Z80-Karte, dann auf Epson QX-10 und PX-4. Letzterer ist mir vor einigen Wochen beim Aufräumen im Keller mal wieder in die Hände gefallen und hat meine Neugierde wieder geweckt. Das Ding läuft noch! Basic im Rom und Turbo-Pascal auf Mini-Kasette - ewige Ladezeiten, aber es geht. Dann fand ich ein tolles Stück Software für den ESP32 (www.fabgl.com - siehe Examples). Es emuliert einen Altair8800 recht performant mit VGA und Tastatur über PS/2. CP/M läuft super. Ich mag diesen minimalistischen Ansatz. Das hat mich dann auch hierher geführt. Toll finde ich die Versionen des AVRCPM-Projektes ohne Propeller etc., weil mir bei letzterem schon der Einsatz von Rechenpower zuviel ist. Da könnte man auch den ESP32 vorziehen. Also erst einmal ein großes Kompliment an die Community - tolle Arbeit! Leider ist es in diesem Threat inzwischen recht ruhig geworden, doch hoffe ich dennoch auf ein wenig Unterstützung, da ich noch ein wenig mit der Umgebung hadere. Als Umgebung verwende ich das aktuelle Microchip Studio 7.0.2542. Wenn ich damit die Sourcen (Version aus https://www.mikrocontroller.net/svnbrowser/avr-cp-m/avrcpm/tags/3.5/) in der Voreinstellung der Config.inc übersetze, findet der Linker zwei Symbole nicht: adc_read8 und avr_read_vcc (beide aus virt_ports.asm - Zeile 183 und 187). Schalte ich den ADC-Support in der Config.inc aus, läuft alles und CP/M startet. Eine Suche nach diesen Symbolen in allen *.inc und *.asm bringt keinen Treffer. Auch wenn ich den ADC sicher nicht so schnell brauchen werde, wüsste ich gerne, woran das liegt. Kennt einer die Antwort auf die Fragen a) wo sind die beiden Symbole definiert und b) warum sind sie in meiner Umgebung nicht definiert und c) bzw. ist der Code für den ADC möglicherweise veraltet und nicht mehr compilierbar? Im Fall c) sollte man evtl. die Default-Einstellungen der Config.inc mal überarbeiten, oder? Gruß Guido
Hallo Guido, der erste Prototyp vom ADC-Code war nicht so doll. Es hatte aber auch niemand Interesse daran. Deshalb hatte ich den Code nie ins SVN eingecheckt. Guido D. schrieb: > a) wo sind die beiden Symbole definiert in adc.asm. Die Datei ist hier im Anhang: Beitrag "Re: CP/M auf ATmega88" Sie muß in avrcpm.asm included und im Makefile zu ASRC0 zugefügt werden. Hier gibts auch eine ältere Version des Gesamtprogramms: Beitrag "Re: CP/M auf ATmega88" > und > b) warum sind sie in meiner Umgebung nicht definiert weil adc.asm fehlt. > und > c) bzw. ist der Code für den ADC möglicherweise veraltet und nicht mehr > compilierbar? Ich vermute mal, das er noch funktioniert. > Im Fall c) sollte man evtl. die Default-Einstellungen der Config.inc mal > überarbeiten, oder? Ja, das hatte ich wohl beim Entfernen von adc.asm vergessen.
Hallo Guido, die letzte Version mit Unterstützung von RTC, GPIO, UART, LPT usw. findest du hier [1] in der Version von AVR-Studio 7. [1] https://github.com/Feinmechaniker/AVRCPM
Guido D. schrieb: > Das hat mich dann auch hierher geführt. Toll finde ich die Versionen des > AVRCPM-Projektes ohne Propeller etc., weil mir bei letzterem schon der > Einsatz von Rechenpower zuviel ist. Der Propeller dient nur als VGA-Terminal. Da gibt es auch ein separates Projekt dazu: Beitrag "VT100-Terminal (VGA+PS2)" > Da könnte man auch den ESP32 > vorziehen. Den gab es vor zehn Jahren noch nicht...
ähmm..also meine Frage wurde hier sicher schon tausendfach gestellt..daher reicht mir eine kurze Zusammenfassung als Antwort aus, wollte den Threat nicht kapern.. Wenn hier einige nach Z80 Projekten Fragen, wird immer die Sinnfrage gestellt...und warum man sich heute noch damit beschäftigen sollte etc. Wieso ist ein AVR CP/M Projekt offenbar etwas völlig anderes:-) Wenn ich das hier so sehe, würde ich doch besser gleich einen Z80 verwenden Wie gesagt..hatte mir jetzt die restlichen 10 Seiten nicht alle durchgelesen...
Die kurze Antwort lautet: Weil es möglich ist, mit 2 IC’s (AVR+DRAM) und einer SD-Card ein komplettes CP/M System zu realisieren.
Joe G. schrieb: > Die kurze Antwort lautet: > Weil es möglich ist, mit 2 IC’s (AVR+DRAM) und einer SD-Card ein > komplettes CP/M System zu realisieren. Ähem... und das ist ein ausreichender Grund? Ich sehe das ganz anders: 1. Es ist für einen Programmierer lehrreich, einen Z80 in Assembler programmieren zu lernen, weil der Z80 einen recht guten und überschaubaren Befehlssatz hat und man es deshalb leicht hat, die für Assembler nötige "Denke" zu erlernen. 2. Es ist für den Hardwerker lehrreich, mit einem Z80 ein funktionables System zu konstruieren, weil man damit Digitalelektronik recht gut lernen und üben kann. 3. Es ist für den Systemarchitekten lehrreich, CP/M zu begreifen, weil man damit lernen kann, wie man ein durchaus leistungsfähiges DOS mit nur wenigen kByte an Gesamtumfang konstruieren kann. 4. Natürlich könnte man auch einen ZX-Spectrum emuliert bauen, Frank hat das ja vorgemacht, aber das läuft dann zu fast 100% auf das Spielen mit den damaligen Spielprogrammen hinaus - und nicht auf die genannten lehrreichen Ziele. Kann man machen, ist aber eine völlig andere Kiste. So. In beiden Fällen (AVR oder echter Z80) ist das damit erzeugte System für die heutige Praxis deutlich zu klein. Mit Wordstar (oder beim Spectrum mit TLW) schreibt man heutzutage keine Briefe an die Omi mehr. Punkt. Was bleibt, ist zum einen der damit erzielbare Lerneffekt. Den sehe ich allerdings bei einem interpretierten System wie per AVR oder ESP32 nicht gegeben, weil man dort ja doch wieder mehr mit dem interpretierenen System als mit dem eigentlichen Z80 bzw. CP/M zu tun hat. Was zum anderen bleibt, ist die Möglichkeit, einen kleinen Rechner zu haben, der binnen 2 Sekunden bootet, wo man ein paar digitale und analoge Ein- und Ausgänge haben kann, für die man sich per Turbopascal mal eben irgendwelche kleinen Testprogramme schreiben kann und wo man damit irgend etwas auf dem Basteltisch tun kann, einschließlich Langzeit-Logging auf Disk - und das alles, ohne den PC benutzen zu müssen. Ich würde das ganze Thema anders sehen, wenn man die Idee des CP/M weiter entwickeln würde, das Ganze dann tatsächlich auf einen passenden 32 bittigen µC portieren würde und damit ein kleines, aber benutzbares System abseits von Windows, Linux, QNX und Ähnlichem schaffen würde. So etwas wäre eine bessere Bastel-Idee. W.S.
W.S. schrieb: > 4. Natürlich könnte man auch einen ZX-Spectrum emuliert bauen, Frank hat > das ja vorgemacht, aber das läuft dann zu fast 100% auf das Spielen mit > den damaligen Spielprogrammen hinaus - und nicht auf die genannten > lehrreichen Ziele. Kann man machen, ist aber eine völlig andere Kiste. gegen Spiele-Emulation ist auch nichts einzuwenden, weil eine Soft-Emu nicht dasselbe ist. Was jetzt die 'lehrreichen Ziele' anbelangt, kann man genauso argumentieren - nicht notwendig, da mittels PC-Software-emu sowieso alles möglich ist?! Und damit sind die lehrreichen Ziele genauso obsolet, Hardware-Nachbau sinnlos so gesehen. Wollte mal auf diese Projekt aufmerksam machen: http://spritesmods.com/?art=avrcpm Interessantes Projekt, leider schweigen sie sich darüber aus wie der Einbau in das Gameboy-Gehäuse aussieht - hier spart man an Fotos, etc. ... oder eben doch nur ein Fake. Das ist leider das Defizit dieser ganzen Projekte - die Macher gehen von sich aus.
:
Bearbeitet durch User
Robert K. schrieb: > Was jetzt die 'lehrreichen Ziele' anbelangt, kann man genauso > argumentieren - nicht notwendig, da mittels PC-Software-emu sowieso > alles möglich ist?! > Und damit sind die lehrreichen Ziele genauso obsolet OK, wer sich als Verbraucher sieht, der benötigt keine Kenntnisse von Hardwaredesign und Programmierung und Betriebssystemen und Dateisystemen. Der muß bloß wissen, wie er/sie über das Display des Mobiltelefones wischen muß, um dann auf das gewünschte Icon zu tippen. W.S.
W.S. schrieb: > OK, wer sich als Verbraucher sieht, der benötigt keine Kenntnisse von > Hardwaredesign und Programmierung und Betriebssystemen und > Dateisystemen. Der muß bloß wissen, wie er/sie über das Display des > Mobiltelefones wischen muß, um dann auf das gewünschte Icon zu tippen. > > W.S. darum geht es doch gar nicht! Wenn ich schon ein Projekt ins Netz stelle, dann sollte das für jeden Interessierten nachbaubar sein. Dieses Ziel ist schon mal verfehlt. Für Programmierung, Hardwaredesign, Betriebssysteme, etc. kann man auch Bücher kaufen und lesen bzw. im Selbstkurs lernen oder an der Uni das entsprechende Fach studieren. Ein Projekt muß aber einen anderen Anspruch haben - und der ist aufgrund der Arroganz definitiv nicht erfüllt!
Robert K. schrieb: > Wollte mal auf diese Projekt aufmerksam machen: > http://spritesmods.com/?art=avrcpm Mußt du nicht, es reicht: Beitrag "CP/M auf ATmega88" zu lesen ;-)
Joe G. schrieb: > Mußt du nicht, es reicht: > Beitrag "CP/M auf ATmega88" > zu lesen ;-) ah okay, Du leidest offenbar an Alzheimer - bitte nicht falsche Zitate unterschieben :-) Originalzitat ist von Peter Sieg: Peter Sieg schrieb: > Hi. > > Wollte mal auf diese Projekt aufmerksam machen: > http://spritesmods.com/?art=avrcpm Ich habe das Zitat von Peter dann ebenfalls nochmal verwendet, aber irgendwas ist mit der 'Kommentierfunktion' hier schiefgelaufen (sehe ich gerade) ... leider kann man das nicht mehr ändern, wenn anschließend jemand anders postet - Fehler bzw. Websiteproblem, bei anderen Foren geht sowas.
:
Bearbeitet durch User
Robert K. schrieb: > darum geht es doch gar nicht! Oh doch. Es geht um das Können und das Selbstverständnis. Da ist ein großer Unteschied zwischen dem Elektroniker, der etwas machen will oder soll und deshalb Fachkenntnisse braucht - und dem Verbraucher, der lediglich auf ergonomische benutzbarkeit achtet, egal ob da drinnen nun ein Mikrocontroller oder ein grünes Marsmännchen werkelt. > Wenn ich schon ein Projekt ins Netz stelle, dann sollte das für jeden > Interessierten nachbaubar sein. Dieses Ziel ist schon mal verfehlt. Das kommt sowohl auf die Güte der hoffentlich vorhandenen Dokumentation als auch auf die Ausführung des Projektes an. Wäre im Einzelfall zu prüfen - mal abgesehen davon, daß nicht jeder elektronik-affin ist. Hier lese ich viel zu häufig sowas: "ich will was ganz dolles bauen aber ich verstehe von Elektronik garnichts..." > Für Programmierung, Hardwaredesign, Betriebssysteme, etc. kann man auch > Bücher kaufen Ja, in diesem Falle den Lampe-Jorke-Wengel, aber bloß kaufen nützt nichts, man muß es auch selbst praktizieren, damit man es tatsächlich lernt. W.S.
W.S. schrieb: > Natürlich könnte man auch einen ZX-Spectrum emuliert bauen, Frank hat > das ja vorgemacht, aber das läuft dann zu fast 100% auf das Spielen mit > den damaligen Spielprogrammen hinaus - und nicht auf die genannten > lehrreichen Ziele. Es gibt Z80-Cross-Assembler, mit denen man TAP-files für den Spectrum erzeugen kann. Hier auch ein Online-Z80-Assemler: https://clrhome.org/asm/ Dieser kann ebenso direkt ZX Spectrum TAP-Files erzeugen, welche man mit STECCY direkt per
1 | LOAD "" CODE |
2 | RANDOMIZE USR address |
ausführen kann. Es muss ja nicht immer ein Spiel sein. Ich habe früher mit dem ZX Spectrum Assembler gelernt und kann nur bestätigen, dass Z80-Code ideal ist, um Assembler zu lernen. Ich habe in den letzten Wochen auch mal z88dk als Cross-C-Compiler-Umgebung ausprobiert - läuft mit sccz80 (original z88dk's compiler) oder auch sdcc. Hier kann man ebenso direkt ZX-Spectrum-TAP files erzeugen, die auf dem STECCY reibungslos laufen.
:
Bearbeitet durch Moderator
Zuerst mal mein Wunsch: Dieses Jahr 2021 möge uns allen ein gutes und gesundes Jahr werden! Frank M. schrieb: > Es gibt Z80-Cross-Assembler, mit denen man TAP-files für den Spectrum > erzeugen kann. Ja, weiß ich. Aber man muß es tun wollen - und da sehe ich bei Nachbauern doch weitaus eher das Verlangen, alte Spiele laufen zu lassen. Ich kann Assembler, du auch, einige andere hier auch (noch) - aber ich lese gerade hier in diesem Forum immer wieder geradezu militante Beiträge, die jegliche Assembler-Kenntnisse als komplett obsolet abtun. W.S.
W.S. schrieb: > Zuerst mal mein Wunsch: > Dieses Jahr 2021 möge uns allen ein gutes und gesundes Jahr werden! dem Neujahrswunsch schließe ich mich an :-) W.S. schrieb: > Ja, weiß ich. Aber man muß es tun wollen - und da sehe ich bei > Nachbauern doch weitaus eher das Verlangen, alte Spiele laufen zu > lassen. In der Beziehung ist Deine Haltung leider falsch - daran ist nichts verkehrt sich der reinen Anwendung zu erfreuen oder eben nur für Spiele zu nutzen? Die Original-Retro-Computer sind zu teuer und Software-Emu auf einen PC ist nur ein schwacher Ersatz. Warum also nicht - genau dasselbe hast Du in etlichen anderen Bereichen doch auch?
W.S. schrieb: > Ich kann Assembler, du auch, einige andere hier auch (noch) - aber ich > lese gerade hier in diesem Forum immer wieder geradezu militante > Beiträge, die jegliche Assembler-Kenntnisse als komplett obsolet abtun. Tja, das ist leider so und Du darfst davon ausgehen, daß Beiträge dieser Art noch zunehmen werden.
W.S. schrieb: > Oh doch. Es geht um das Können und das Selbstverständnis. Da ist ein > großer Unteschied zwischen dem Elektroniker, der etwas machen will oder > soll und deshalb Fachkenntnisse braucht - und dem Verbraucher, der > lediglich auf ergonomische benutzbarkeit achtet, egal ob da drinnen nun > ein Mikrocontroller oder ein grünes Marsmännchen werkelt. learning by doing - vielleicht animiert es ja den ein oder anderen Anwender oder Verbraucher sich näher damit zu beschäftigen. Nur von vornherein den Anspruch zu erheben, daß sich nur die technische Elite damit beschäftigen darf, ist der falsche Weg. >> Wenn ich schon ein Projekt ins Netz stelle, dann sollte das für jeden >> Interessierten nachbaubar sein. Dieses Ziel ist schon mal verfehlt. > > Das kommt sowohl auf die Güte der hoffentlich vorhandenen Dokumentation > als auch auf die Ausführung des Projektes an. Wäre im Einzelfall zu > prüfen - mal abgesehen davon, daß nicht jeder elektronik-affin ist. Richtig, und die Anwender- bzw. Verbraucherseite wird von den Machern der Projekte völlig vergessen. Somit sind viele gute Projekte leider völlig obsolet. > Hier > lese ich viel zu häufig sowas: "ich will was ganz dolles bauen aber ich > verstehe von Elektronik garnichts..." ist doch okay - aber dann muß man dem Verbraucher auch sagen können: hier, Link xy kannst Du fertig kaufen oder Link yz kannst Du basteln, wenn Du löten kannst. Und beides kann man eben nicht sagen, weil die Links nicht existieren bzw. die ganze Doku saumäßig schlecht ist. Sowas ist dann leider sehr schade und Dialog mit dem Projektbetreiber hat leider auch wenig Sinn, weil der u.a. Deine Einstellung hat und auf einem anderen Level schwebt. >> Für Programmierung, Hardwaredesign, Betriebssysteme, etc. kann man auch >> Bücher kaufen > > Ja, in diesem Falle den Lampe-Jorke-Wengel, aber bloß kaufen nützt > nichts, man muß es auch selbst praktizieren, damit man es tatsächlich > lernt. Reparierst Du Dein Auto selbst, wenn es z.B. einen Getriebeschaden hat? Baust Du Dein Haus eigenhändig? Muß man das könnnen? ... in einer arbeitsteiligen Gesellschaft nicht mehr! Du kannst Dir auch Wissen aneignen ohne es zu praktizieren - ist manchmal auch sinnvoller, oder findest Du jeden Job/Tätigkeit toll? So manchen Job bzw. Tätigkeit möchte ich nicht unbedingt machen.
:
Bearbeitet durch User
Ich möchte nicht unhöflich sein, dennoch darum bitten Eure Diskussion anderweitig fortzuführen. Etwa 1900 Beiträge lang, war die Diskussion auf „CP/M auf AVR“ ausgerichtet. Ich würde mich freuen, wenn das zukünftig auch so bleibt. Danke!
Robert K. schrieb: > In der Beziehung ist Deine Haltung leider falsch Hä? Hab ich etwa Franks Projekt geschmäht? Nein, natürlich nicht. Aber ein ZX-Spectrum-Emulator per Cortex-M ist rein sachlich etwas ganz anderes als ein CP/M auf ATmega88. Der Spectrum reizt zum Nachbauen eben WEGEN der Spiele, der ATmega nicht. Unterscheide mal die unterschiedlichen Kisten. Robert K. schrieb: > Die Original-Retro-Computer sind zu teuer und Software-Emu auf einen PC > ist nur ein schwacher Ersatz. Rede nur weiter, dann reizt mich das so, daß ich mal versuche, so einen Universal-Retro-Z80-Computer tatsächlich zu konzipieren - mit einem richtigen Z80. Sowas wäre durchaus mal ein reizvolles Projekt. Beides einzeln hab ich schon, kenne ich schon, hab ich schon selber entwickelt und eines davon war vor Urzeiten auch mal in ner Gazette abgedruckt. Robert K. schrieb: > Nur von vornherein den Anspruch zu erheben, daß sich nur die technische > Elite damit beschäftigen darf, ist der falsche Weg. Wir alle haben mal angefangen, barfuß das Laufen zu lernen. Gilt auch hier und bedarf der eigenen Bemühungen, es zu verstehen. Wenn man es dann kann, dann darf man sich auch "technische Elite" nennen - wenn man derart eitel ist. Aber hier ging es vorrangig um die Frage, wozu - also zu welchem letztendlichen Zwecke - die hier besprochene Emulation eines Z80 und CP/M auf einem Atmel-IC gedacht ist. Und die Antwort war: weil es geht und nur 2 Schaltkreise braucht. Das ist mir ein bissel arg dünn. Dinge zu tun, nur weil es möglich ist, läßt mich an die Atombombe denken. Ich halte das für eine falsche, weil zu unbedachte Sinneshaltung. W.S.
Joe G. schrieb: > Ich möchte nicht unhöflich sein, dennoch darum bitten Eure Diskussion > anderweitig fortzuführen. Etwa 1900 Beiträge lang, war die Diskussion > auf „CP/M auf AVR“ ausgerichtet. Ich würde mich freuen, wenn das > zukünftig auch so bleibt. > Danke! kommt von den anderen denn noch was Neues? Kann ich nicht erkennen. Richtig, CP/M auf AVR ... auch für CP/M gibt es Spiele. Fakt ist auch, daß das Projekt wohl als Einbau in den Gameboy gedacht war, wenn man den Link von Peter weiter verfolgt wo das gleich auf der Eingangseite abgebildet wird ... nur da hört es dann auch schon auf - insofern bleiben leider Fragen offen.
W.S. schrieb: > Hä? > Hab ich etwa Franks Projekt geschmäht? Nein, natürlich nicht. Aber ein > ZX-Spectrum-Emulator per Cortex-M ist rein sachlich etwas ganz anderes > als ein CP/M auf ATmega88. Der Spectrum reizt zum Nachbauen eben WEGEN > der Spiele, der ATmega nicht. Unterscheide mal die unterschiedlichen > Kisten. Es geht ja nicht allein um Spiele - das ist nur eine Anwendung; bei CP/M weniger als bei Spectrum, aber auch das geht. Fakt ist leider, daß ein Spectrum Nachbau etwas aufwendiger wird als CP/M auf Atmega mit ein paar Bauteilen - das geht wesentlich schneller. Wer jetzt Spielefreak ist und mehr braucht, kann ja anfangen selbst welche nach zu programmieren auf CP/M ... und damit lernt er dann auch was Unnötiges. > Rede nur weiter, dann reizt mich das so, daß ich mal versuche, so einen > Universal-Retro-Z80-Computer tatsächlich zu konzipieren - mit einem > richtigen Z80. gibt es doch schon alles, nur meistens viel zu teuer. > Sowas wäre durchaus mal ein reizvolles Projekt. Beides > einzeln hab ich schon, kenne ich schon, hab ich schon selber entwickelt > und eines davon war vor Urzeiten auch mal in ner Gazette abgedruckt. Hast Du noch den Schaltplan? > Wir alle haben mal angefangen, barfuß das Laufen zu lernen. Gilt auch > hier und bedarf der eigenen Bemühungen, es zu verstehen. Wenn man es > dann kann, dann darf man sich auch "technische Elite" nennen - wenn man > derart eitel ist. take it easy - das Hauptproblem ist, daß bei vielen das Interesse auch abgewürgt wird wegen Kommerz, wegen zuviel Aufwand, usw. > Aber hier ging es vorrangig um die Frage, wozu - also zu welchem > letztendlichen Zwecke - die hier besprochene Emulation eines Z80 und > CP/M auf einem Atmel-IC gedacht ist. Und die Antwort war: weil es geht > und nur 2 Schaltkreise braucht. Das ist mir ein bissel arg dünn. und genau das ist die richtige Antwort - sehr wenig Aufwand, geht sogar auf Lochraster, kein Platinen ätzen & sonstiger Kommerz notwendig. > Dinge > zu tun, nur weil es möglich ist, läßt mich an die Atombombe denken. Ich > halte das für eine falsche, weil zu unbedachte Sinneshaltung. das hast Du nun wirklich überall - z.B. 80% aller Sportarten sind unsinnig und passiver Sport sogar schädlich wegen Bewegungsmangel ... es wird aber gemacht aus Spaß & Amüsement.
https://www.youtube.com/watch?v=F2SvMctec9M So ein richtiges Z80 Projekt hat wenigstens Potential :-)
Nach dieser doch eher weltanschaulichen Diskussion, noch einmal was recht bodenständiges: In allen Schaltungsentwürfen zu AVRCPM ist immer ein ISCP-Anschluss vorhanden. Gleichzeitig ist der Reset über 100nF gegen Masse gepuffert. Bei meinen Billig-China-Adaptern vom Typ USBASP hat das zur Folge, dass der Reset noch nicht wieder zurückgesetzt wurde, da fängt AVRDude schon an zu programmieren, was natürlich fehl schlägt. Die Dokumentation von AVR sagt nur aus, dass der Kondensator Sinn macht, wenn es bzgl. Störungen recht rauh zugeht, aber bei DEBUGwire nicht Verwendung finden darf. Ich deutete das als Hinweis auf besagtes Problem mit meinen USBASPs und habe ihn probehalber entfernt - und schon spielt AVRDude mit. Um beidem gerecht zu werden, habe ich den Kondensator nun gejumpert. Ohne eine neue weltanschauliche Diskussion lostreten zu wollen bzgl. Direktkauf in China und ob Firma R*, die hier gerne referenziert wird, keine Apotheke ist und ob die Finanzierung deutscher Zwischenhändler wirklich eine Sache von Hobbyisten sein sollte, meine Frage an die Gemeinde: Welche ISP-Programmer verwenden denn die Väter des Projektes - oder arbeitet Ihr nur noch mit Bootloadern? Und nun doch noch ein paar Sätze zu vorgenannter Diskussion: Es gefällt, was den Beteiligten Spaß macht. Die Sinnfrage stellt sich vlt. in der Kirche, beim Umweltschutz oder bei kommerziellen Projekten. Wer keinen Sinn in einem Vorschlag sieht, braucht ihn doch nicht anzunehmen. Deshalb muss man den anderen den Spaß doch nicht vermiesen, oder? Gruß Guido
Guido D. schrieb: > Bei meinen Billig-China-Adaptern vom Typ USBASP hat das zur Folge, dass > der Reset noch nicht wieder zurückgesetzt wurde, da fängt AVRDude schon > an zu programmieren, was natürlich fehl schlägt. Das hat als Aussage keinen rechten Sinn: die ISP-Programmierung erfolgt während eines aktiven Resets. Einzige Erklärung wäre, dass der Treiber in deinem Billigadapter zu schwachbrüstig ist und den C nicht rechtzeitig genug entladen hat, bevor die Programmierung startet. Aber eigentlich wird die Initialisierungssequenz einige Male wiederholt. Insofern würde ich ein anderes Problem vermuten.
Robert K. schrieb: > Hast Du noch den Schaltplan? Ja, irgendwo tief in der Bastelkiste schmort auch noch die ganze Zeitschrift. Aber das war alles mit BE der 80er Jahre gemacht: TTL, 2K RAM usw. Ein heutiger Ansatz sähe ganz anders aus. W.S.
W.S. schrieb: > Ja, irgendwo tief in der Bastelkiste schmort auch noch die ganze > Zeitschrift. Aber das war alles mit BE der 80er Jahre gemacht: TTL, 2K > RAM usw. Ein heutiger Ansatz sähe ganz anders aus. > > W.S. Nicht schlecht ... ist schon klar, heute sind die Möglichkeiten besser. Das Projekt, das Peter gefunden hat, ist ja nicht schlecht - nur leider geht vieles unter und das ist wirklich schade gerade wegen des minimalen Bauteil-Aufwands. Na ja, es gibt noch andere Projekte mit AVR - die sind etwas aufwändiger und dafür dann besser durchdacht.
Hallo, ich habe mir jetzt in den Sommerferien den Aeternum vorgenommen (Platine V1.0, Doku V1.2 aus dem Repo). Ein paar Kleinigkeiten neben den bekannten Errata sind mir noch aufgefallen (R7 wird nirgends beschrieben, die Fixes von V1.3 sind noch nicht in den Layouts, einige Bilder für den Bestückungsplatz fehlen). Aber bisher sieht es gut aus (VT100 fehlt noch). Hat sich jemand schon die Mühe gemacht, ein Gehäuse per 3D-Druck zu entwerfen? Besten Gruß Marcel
Super, wenn das Projekt noch Freunde findet :-) R7 kann unbestückt bleiben und war nur zur Lastanpassung vorgesehen. Ich hatte die Version 1.3 selber nicht mehr aufgebaut, bin jedoch an Aufbauberichten interessiert um sie einzupflegen. Ein Gehäuse hatte ich nur in Alu entworfen und realisiert. Da die CAD-Daten vorliegen, kann es sicherlich auch in 3D-Druck überführt werden. Gruß Jörg
Hallo Jörg, na klar - ich bin in den letzten Monaten (Jahren?) allerdings wie Hans-Werner etwas mehr beim NKC-Projekt (NDR Klein Computer) unterwegs gewesen - da gibts immer wieder neue Platinen - zuletzt auch 8080 und 6502-CPU :-) Gehäuse - muss mir mal die DXF-Dateien ansehen :-) Da scheint aber die Datei für "vorne" zu fehlen. Würden die Frontblenden auch auf ein Standardgehäuse passen? Gruß Marcel
Die Seitenteile scheinen auch zu fehlen, ansonsten klappt ein Neuexport aus dem FTD in STEP und dann Konvertierung zu STL :-)
Ich habe mal die Daten für die Front- und Rückplatte angehangen. Die Seitenteile sind aus Alu-Strangprofil wo die Boden- und Deckplatte eingeschoben werden. Tatsächlich hatte ich die Gehäusemaße genau nach der Leiterplattengröße ausgelegt, ein Standardgehäuse wird wohl nicht passen :-(
Hi, so, läuft alles prima! Jetzt fehlt nur noch der VT100 Teil. Ein paar Fragen (ist alles schon wieder so lange her...) - kriegt man auf der RS233 auch mehr als 9k6 hin? FÜr die Stamp hatte Leo doch mal den STAT-Befehl um "schnelle" Varianten erweitert? - Doku zu ZSDOS habe ich gefunden - aber gibts auch noch was spezielles für den Aeternum? So als Nachschlagewerk wie bei der Z180 Stamp? Gruß Marcel
z.B. auch - wie programmiert man die "Soundausgabe"? Oder Hinweise zu dem Thema BDOS-Aufruf in Sample bei Turbo Pascal usw.?
dl1ekm schrieb: > - kriegt man auf der RS233 auch mehr als 9k6 hin? Ja, bekommt man. Im Anhang mal einige Tools von Martin, Leo C. und mir um die RS232, RTC und VT100 zu bedienen. Ein Turbo Pascal Demo für die BDOS Aufrufe muß ich mal suchen, ist schon wieder etwas her, dass ich sowas programmiert habe. Die Soundausgabe auf dem Propeller ist noch nicht implementiert. Ich habe zwar ein Spin-Code, der den AY3891X / YM2149F Chip emuliert und auf das Audiointerface ausgibt, doch dazu müßte noch ein Befehlssatz im VT100 Protokoll implementiert werden.
:
Bearbeitet durch User
Hier der Spin-Code für ein Sounddemo sowie ein ganz kurzes Demo für BDOS und BIOS Aufrufe.
So - auch VT100 geht! Tolles Projekt! Gerade in der Anbindung von "echter" Hardware sehe ich deutliche Vorteile gegenüber anderen Emulationen z.B. auf dem ESP32 - auch wenn die HW langsam in die Jahre gekommen ist :-) Mir scheint es, dass das Projekt so bei 90% steht? Die Implementierung des Soundchips auf dem Propeller finde ich toll - "müsste man mal fertig machen" :-). Auch denke ich, dass eine erweitere Doku ähnlich dem STAMP-Projekt das Potential der Lösung deutlich stärker zeigen würde. Aber vielleicht kriegen wir das ja als Community noch gewuppt. Zum Thema RS232 Speed: Ich schau mir die samples mal an. Meine Idee war nur, daran direkt mein VT420 Terminal anzuschließen, und da wären 115200 besser als 9600 :-) Bei dem CPM für die Z180-Stamp hatte Leo dazu ich glaube den STAT Befehl verwendet und einige langsame Baudraten dann auf der AVR-Seite mit Highspeed versorgt. Mein kleiner Beitrag: Im Rahmen des Aufbaus sind mir in der Anleitung noch folgende Unklarheiten in der Doku aufgefallen: - Die Jumper für MODE 2 (6er) sind spiegelverkehrt dargestellt - sowohl in der Anleitung als auch im Anhang. Alle anderen Darstellungen sind dagegen korrekt. - Propeller: Es wäre gut, wenn man ERST die Bauteile für die Reset-Logik aufbaut und DANN erst den Propeller / Speaker. Denn so konnte ich den SMD BC817 kaum noch einlöten. - Ein Hinweis zu R7 (optional) wäre gut - Seite 15: Fehler bei den Widerständen. R16+R17 sind 150 Ohm, nicht R18 und R17 - Ein Tipp zur Ausrichtung des I2C Pegelwandler-IC wäre schön, da nichts auf der Platine erkennbar ist - Die Bestückung von C20 ist nicht in der Anleitung - Die Bestückung von C21 fehlt - JP1 wird nicht erwähnt Besten Dank für das Projekt! Marcel
Vielen Dank für die zahlreichen Anmerkungen! Ich werde sie nach meinen Urlaub einpflegen. Da die Änderung der Baudrate bei CP/M 2.2 nicht so elegant wie bei CP/M 3.0 gelöst ist, außerdem die Kommunikation eigentlich über I2C to seriell läuft, gibt es ja das kleine Tool, welches ich beigefügt habe. Wie schnell der I2C/Seriell Chip ist, und ob er 115K kann, mußt du mal dem Datenblatt entnehmen. Ja, eine erweiterte Doku ist schon wünschenswert – vielleicht findet sich ja noch ein Mitstreiter.
Angehängte Dateien:
-
P1090988.jpg
180 KB
hat schon mal jemand versucht, das AVR CP/M mit einem solchen MicroSD Cardreader zu betreiben? Dieser ist ja mit Pegelwandlern ausgestattet, so dass die ganze Schaltung mit 5V gespeist werden kann. Hierzu habe ich eine vorhandene Micro SDHC Karte mit FAT16 formatiert und die Imagedateien darauf kopiert. Dann habe ich diese MicroSD Karte zunächst in einen MMC/MicroSD Adapter gesteckt und mit dem vorhandenen CP/M Stick (Hardware Variante 3) gebootet, was problemlos funktioniert hat. Wenn ich nun aber den Cardreader statt des MMC Slots am SPI des ATmega328P bei Vcc=5V betreibe, lande ich nach dem RAM Test in einer Endlosschleife mit Bootversuchen von der SDHC Karte. Hat jemand eine Idee woran das liegen könnte?
Beitrag #7023546 wurde vom Autor gelöscht.
Angehängte Dateien:
-
IMG_3022.jpg
78 KB
Hallo Thomas, klar - und das funkt ganz hervorragend. Auf dem Foto ist eine 5V-Schaltung aufgebaut. Mit Uhr und GPIO. Ich weiß nicht, welche RAMs Du verwendest, aber meine KM44C256CP-7 kommen gut mit den 5 Volt klar. Vieleicht zieht aber irgend etwas zu viel Strom? Gruß Guido
Angehängte Dateien:
-
P1100007.jpg
250 KB
Vermutlich hast Du recht. Ich hatte zur Bestückung des ursprünglichen CP/M Sticks Siemens RAMs bestellt, die bei 3,3V nicht funktionierten. Um sie trotzdem zu nutzen, habe ich ein ganz minimalistisches Redesign zum Betrieb an 5V erstellt mit den beschriebenen Bootproblemen an dem "Arduino" MicroSD Adapter. Um das Problem zu lösen habe ich die MicroSD Karte u. a. über einfache Spannungsteiler zur 5V zu 3,3V Pegelanpassung der SPI Signale angeschlossen. Das hat perfekt funktioniert, so dass ich auf die Schnelle einen eigenen Adapter gebaut habe, der sogar noch etwas kleiner als das Kaufteil ist. - Thomas
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.