Hallo, hat schonmal jemand diesen Rechner aufgebaut? Bisher komme ich nicht mal an die Platinen, es sei denn ich lasse sie selbst fertigen (vielleicht hat ja noch jemand welche?) Die gerber Daten sind ja verfügbar, notfalls muss man dann eben welche machen lassen. Es soll CPM drauf laufen und natürlich eine Floppy dran. Diese muss auch von einer Software-Erstellungs-Umgebung (welche auch immer) erreichbar sein. Also nicht nur vom CPM aus. Aus meinen DOS Zeiten konnte ich das über den Borland Turbo-Assembler machen über das DOS API (Int20h) oder über C eben mit fopen, fclose usw. Ich schwanke immer noch zwischen dem RC2014 und diesem hier aber beim RC2014 habe ich völlig den Überblick verloren. Diese ganzen Steckmodule müssen ja auch irgendwelche Treiber haben und mal eben ROMWBM umschreiben, soweit bin ich nicht, fange da bei Null an. Wüsste nicht mal wie da einen Assembler installieren sollte auf meinem Gamer PC. Aber das steht ja auch alles hier: https://github.com/wwarthen/RomWBW/tree/master/Source Kann jemand von seinen Erfahrungen berichten mit dem Zeta SBC V2 ?? gruss, Christian
Christian J. schrieb: > Bisher komme ich nicht mal an die Platinen Kein Wunder. Z80 und Floppy sind so gut wie tot. Der Z80 Kern lebt in Form von Mikrocontrollern noch weiter, aber nicht als nackte CPU.
Stefanus F. schrieb: > Kein Wunder. Z80 und Floppy sind so gut wie tot. Stefanus... das sind Retro-Projekte. Und die Chipse kriegt du nachgeworfen, habe selbst etliche davon. Ne 1.4M Floppy habe ich auch noch. Es geht nur um die Platinen des Zeta, da reagiert keiner mehr bei den e-mail Adressen, die auf der Support Seite stehen. Ich frage nur ob die Kiste schon mal jemand gebaut hat und wie seine Erfarungen damit sind. Das N8VEM Projekt ist mir ne Nummer zu gross.
Ok, für den Preis unschlagbar! https://www.ebay.com/itm/PCB-Zeta-SBC-V2-ParPortProp/383033326094?hash=item592e90ba0e:g:i8oAAOSwSRJcipaT
Ich hätte ja eher das hier genommen: https://hackaday.io/project/161496-cpm-50-mk-ii weniger retro, deutlich mehr Wumms. fchk
Frank K. schrieb: > weniger retro, deutlich mehr Wumms. Ach Frank... wenn ich eine Harley anwerfe, dann will ich ja auch das Hämmern der Kolben hören und den Qualm aus dem Auspuff sehen - auch wenn Klima-Greta das nicht passt). Sonst würde ich mir ja eine Kawasaki ZX-12 R Ninja kaufen mit 178 Mhz, ähm PS, die 300 km/h läuft. Und bei dem Board kann man den Bits zuschauen, wie sie tackern.
Ich habe das P112 Single Board Computer System [1] aufgebaut. Scheint mir ähnlich dem Zeta zu sein. [1] https://661.org/p112/
Hallo ! Ich habe mir das Zetasystem nachgebaut. Funzt Super. Meine ganzen alten Projekte kann ich jetzt wieder übersetzen. Gucke mal auf https://www.retrobrewcomputers.org da habe ich meine Platinen her. Ich baue mir gerade ein ECB-System auf.
Christian J. schrieb: > Es soll CPM drauf laufen und natürlich eine Floppy dran. > Diese muss auch von einer Software-Erstellungs-Umgebung > (welche auch immer) erreichbar sein. Also nicht nur vom CPM aus. Wenn CP/M auf die Floppy zugreifen kann, kannst du das auch. Direkte Zugriffe laufen über die BIOS-API, die BDOS-API arbeitet auf dem Dateisystem.
S. R. schrieb: > Direkte Zugriffe laufen über die BIOS-API, die BDOS-API arbeitet auf dem > Dateisystem. Also genau wie bei DOS, der INT 21h... ?
hbl@hbl.de schrieb: > Ich habe mir das Zetasystem nachgebaut. Funzt Super. Meine ganzen > alten Projekte kann ich jetzt wieder übersetzen. Gucke mal auf Habe mir die Platinen für 18 Euro aus Russland bestellt, mal gucken ob sie ankommen. Bausätze gibt es zwar auch aber das meiste habe ich eh hier zu Hause dank Holm Tiffe :-) In meiner "Virenzeit" war es so, dass man über das Bios nur auf LL Funktionen zugreifen konnte, über das DOS aber dann auch ein richtiges FS hatte, was über den INT21H mit seinen 1000 Funktionen aufgerufen wurde.
Christian J. schrieb: >> Direkte Zugriffe laufen über die BIOS-API, >> die BDOS-API arbeitet auf dem Dateisystem. > > Also genau wie bei DOS, der INT 21h... ? Rate mal, bei wem DOS diese Struktur kopiert hat. :-) Das CP/M-BIOS entspricht IO.SYS (systemabhängig), das CP/M-BDOS entspricht MSDOS.SYS (systemunabhängig). Die meisten CP/M-Funktionen haben direkte Äquivalente (z.B. FCBs funktionieren), obwohl DOS zusätzliche APIs für zusätzliche Funktionalität (z.B. Unterverzeichnisse) anbietet. Christian J. schrieb: > dass man über das Bios nur auf LL Funktionen zugreifen konnte, > über das DOS aber dann auch ein richtiges FS hatte, Logisch: DOS ist ja auch ein Betriebssystem, während das BIOS eigentlich nur Hardwaretreiber bereitstellt.
S. R. schrieb: > Rate mal, bei wem DOS diese Struktur kopiert hat. :-) > Das CP/M-BIOS entspricht IO.SYS (systemabhängig), das CP/M-BDOS https://www.i8086.de/dos-int-21h/dos-int-21h.html Geil,l fühle mich wieder wie mit 22 als ich meinen ersten 386er bekam und nichts anders zu tun hatte als .com und .exe Viren zu schreiben :-) Bis meine Kiste total infiziert war und nichts mehr lief. Den Int21h konnte man Tracen über die 8086 Singe Step und alles abklemmen, was sich da rein gehängt hatte. War damals stolz wie Oskar, dass der Quelltext im 40Hex Magazin veröffentlicht wurde, dem damaligen Hacker Szene Magazin. Natürlich hatten dann die Scanner Hersteller ihn auch gleich, obwohl er niemals frei war. Ok, 1994 war das wie ich grad sehe. https://malware.wikia.org/wiki/Shark Das waren noch Zeiten...
In den 90er Jahren hatte ich als gerade eben Erwachsener für die Telekom einen Floppy-Treiber geschrieben, bei dem man den Zugriff auf die Laufwerke temporär sperren konnte. Als Seiteneffekt war er fast 2x so schnell ("neuere" Laufwerke ermöglichten das). Meine Hauptaufgabe bestand darin, den Interrupts 21 auf einene TSR Routinen umzubiegen, die den Zugriff aufs Floppy Laufwerk abwickelten.
Christian J. schrieb: > Natürlich > hatten dann die Scanner Hersteller ihn auch gleich, obwohl er niemals > frei war Wäre ja absurd, wenn Antivirensysteme einen Virus nicht erkennen dürften wegen des Urheberrechts daran - aber bei Juristen ist natürlich alles möglich. Georg
hbl@hbl.de schrieb: > Hallo ! > > Ich habe mir das Zetasystem nachgebaut. Funzt Super. Meine ganzen > alten Projekte kann ich jetzt wieder übersetzen. Gucke mal auf > > https://www.retrobrewcomputers.org > > da habe ich meine Platinen her. Ich baue mir gerade ein ECB-System > auf. Hi, habe die Platinen bekommen. Dabei ist auch eine mit SD Kartenslot. Hast du eine Bezugsquelle für das Chipset? Es würde ein Vermögen an Versandkosten kosten das alles einzeln zu bestellen, da alle Chips ja sehr betagt sind. Und die z80 CPU soll angeblich 8 Mhz haben, damit die Floppy betreibbar ist. Habe das Laufwerk schon hier, 3.5z. Nur mit 8Mhz finde ich keine Z80 CPU, die enden bei 6Mhz. Diesen Müll hier hatte ich schonmal, die stiegen schon ab 3.5 Mhz bei mir aus auf dem Board, was ich damals gebaut habe. Irgendwelche Klone. https://www.ebay.de/itm/2PCS-Z84C0008PEC-DIP-40-Microprocessors-MPU-8MHz-Z80-CPU-XT/123209404028?hash=item1cafda4e7c:g:HgEAAOSwNYtb9j5b
moin,
>>z80 CPU soll angeblich 8 Mhz haben
in meinem System hat damals ein µPD765 die Floppy gesteuert, der z80
Takt war davon unabhängig.
Die Baugruppe liegt noch irgendwo.
Die z80-CMOS-CPU hatte ich mit 10MHz getaktet...und Ladder konnte nicht
mehr gespielt werden, einfach zu schnell.
Hat das Teil auch eine RAM-Disk?
Viel Spass.
Peter
Pieter schrieb: > Hat das Teil auch eine RAM-Disk? Nee, aber wohl Banking über 8x64kb. Und eine SD Floppy, die über einen Propeller angesteuert wird. Floppy geht direkt dran. Bin da auch erst am Anfang, wird wohl der Winter drüber vergehen. http://www.malinov.com/Home/sergeys-projects/zeta-sbc-v2
Nachtrag: Farnell hat noch 3 Stück: https://de.farnell.com/zilog/z84c0008peg/cpu-z80-8mhz-84c00-dip40/dp/1081890
Pieter schrieb: > Farnell hat noch 3 Stück: Da können nur Gewerbliche bestellen. Oder aus GB halt: https://www.ebay.de/sch/i.html?_from=R40&_trksid=m570.l1313&_nkw=Z84C0008PEG&_sacat=0
Christian J. schrieb: > Nur mit 8Mhz > finde ich keine Z80 CPU, die enden bei 6Mhz. Dann kauf dir bei Ali einen Z80 für 20 MHz. Die gibt's. Das Problem ist, daß es kaum zu 20 MHz passende PIO, CTC, SIO gibt. Sowas sollte man also bei so einem Retro-Projekt vermeiden. Abhilfe: FT245 für's "serielle", CPLD für alles andere. W.S.
W.S. schrieb: > Dann kauf dir bei Ali einen Z80 für 20 MHz. Ich kaufe das so, wie das für das Projekt richtig ist. Alles andere führt nur wieder dazu, dass nachher nichts mehr funktioniert. Das Ding haben schon hunderte aufgebaut, ist vom N8VEM Projekt abgeleitet worden. Die vielen 74er klicke ich mir wohl bei Reichelt zusammen, glaube da kriegt man die auch einzeln. Floppycontroller liegen so um die 15 Euro bei ebay.
Pieter schrieb: > Die z80-CMOS-CPU hatte ich mit 10MHz getaktet...und Ladder konnte nicht > mehr gespielt werden, einfach zu schnell. Moin, ich habe die Platinen und bei Reichelt auch die meisten Bauteile bestellt. Bevor ich das Teil zusammen zimmer frage ich mal bescheiden. Wenn ich da CPM aufspiele mit den Treibern für die Floppy.... wie könnte ich das System in C programmieren? Assember ist keine Option mehr, fange ich nach 25 Jahren ohne nicht mehr mit an. Gab oder gibt es für CPM C Compiler? SDCC wäre eine Option aber dafür braucht man kein CP/M und hat eben kein OS drunter liegen. Das System muss ja für irgendwas gut sein, es wird erstmal per VT100 visualisiert auf einem PC. Einen VGA Monitor Anschluss bekommte es später, wobei ich jemand finden muss, der mir einen Propeller Chip programmiert. Betrieben wird es mit RomWBW https://github.com/wwarthen/RomWBW was selbst vollständig in Assembler geschrieben ist. Die Images sind 512kb gross, wobei ich noch nicht weiss, wie die in einem 64kb Adressraum verarbeitet werden.
Da ich das unbestimmte Gefühl nicht loswerde, dass Du das Projekt noch nicht ausreichend genug studiert hast, gebe ich Dir mal diesen Link, der mich massgeblich inspirierte => http://www.malinov.com/Home/sergeys-projects/zeta-sbc-v2 Ingo
Ingolf O. schrieb: > Da ich das unbestimmte Gefühl nicht loswerde, dass Du das Projekt noch > nicht ausreichend genug studiert hast, gebe ich Dir mal diesen Link, der > mich massgeblich inspirierte => Es ging um die Frage: Ist auf dem Ding eine "hostet" C Entwicklung möglich? Ohne irgendwelchen Cross-Compiler Geschichten. Und wenn Cross-Compiler, dann Idealerweise per Hex Upload oder direkt auf dem Z80 selbst (wie eben UCSD Pascal auf dem Apple II) Und diese Seite kenne ich nahezu auswendig. Bisher habe ich "free-standing" mit SDCC gemacht für meinen Z80 Bau von 2015. Ohne OS dahinter aber eben leider auch ohne jede Peripherie wie Floppy usw. usw. Kein Int21 Interrups, kein BIOS was mir hilft....
Christian J. schrieb: > Es ging um die Frage: Ist auf dem Ding eine "hostet" C Entwicklung > möglich? Ohne irgendwelchen Cross-Compiler Geschichten. Für CP/M gab es Turbo Pascal. Authentisch wäre damit zu arbeiten. C war damals im Kleincomputer-Bereich noch nicht wirklich verbreitet. Du kannst den BDSC-Compiler ausprobieren: https://www.bdsoft.com/resources/bdsc.html
Christian J. schrieb: > SDCC wäre eine Option aber dafür > braucht man kein CP/M und hat eben kein OS drunter liegen. Das müsstest du dann sdcc beibringen. Zumindest bräuchtest du einen Ersatz für den standard crt.o (was die globale Variabelen initialisiert und dannn dein main() aufruft) und ein bisschen Code womit du die CP/M Funktionen aufrufen kannst. zB
1 | void printf(char *text) |
2 | {
|
3 | __asm__ ( |
4 | ...lade 'text' in HL... |
5 | |
6 | "printfloop: "
|
7 | " ld a,(hl) ; next character"
|
8 | " cp 0 ; 0 is end of string"
|
9 | " inc hl"
|
10 | " ret z "
|
11 | |
12 | " push hl"
|
13 | " ld c,2 ; BDOS call C_WRITE"
|
14 | " call 5 ; call BDOS"
|
15 | " pop hl"
|
16 | " jr printfloop"
|
17 | );
|
18 | }
|
EDIT: Als Alternative gibt's auch noch HiTech C für CP/M -- aber der generiert ziemlich sub-optimale Code.
:
Bearbeitet durch User
Eric B. schrieb: > Als Alternative gibt's auch noch HiTech C für CP/M -- aber der generiert > ziemlich sub-optimale Code. Route_66 H. schrieb: nachträglich eine zweite Datei anhängen geht nicht
:
Bearbeitet durch User
Eric B. schrieb: > Als Alternative gibt's auch noch HiTech C für CP/M -- aber der generiert > ziemlich sub-optimale Code. Nachträglich eine zweite Datei anhängen geht nicht!?
also ich hatte "damals"(tm) "Mix C" für CP/M auf meinem System mit CP/M3.0 auf HD64180. https://www.cpm8680.com/mix/index.htm
Hallo! Im read.me steht "provided free of charge for any use, private or commercial," deshalb hier das Archiv.
Danke für die Vorschläge Ich muss mich da erstmal durcharbeiten. In jedem Fall ziehe ich einen C Compiler vor, auch wenn ich damals Pascal gelernt habe 1983 als erste Sprache. C und das idealerweise ohne dass ein PC dran muss. Code sollte natürlich ok sein, C89 bzw K&R erfüllt sein. Und möglichst auch Dead Code Elemination, was nicht gebraucht wird im Aufruferbaum, wird nicht erzeugt. Der SDCC lässt zb ja alles stehen was man schreibt. Klingt aber schon alles echt gut! UCSD Pascal war damals der Standard bei uns, auch für Stundenplan Programme usw.
Eric B. schrieb: > Das müsstest du dann sdcc beibringen. Zumindest bräuchtest du einen > Ersatz für den standard crt.o (was die globale Variabelen initialisiert > und dannn dein main() aufruft) und ein bisschen Code womit du die CP/M > Funktionen aufrufen kannst. Ich habe vor 3 Jahren eine .crt.0 für mein System zusammen gestrickt. Es war möglich, leere Funktionen mit Zeigern auf feste Adressen abzulegen. Print und NCurses lagen im ROM fix und fertig. Musste man nur noch Zeiger drauf legen und konnte am PC das Programm schreiben, was dann per Hex Upload hoch ging mit 9600 baud. Idealerweise gibt es so eine .crt.o ja schon für CP/M.
Christian J. schrieb: > Gab oder gibt es für CPM C Compiler? Es gibt QC für CP/M. Der wirft ASM Code raus. Assembler, Librarian und Linker Locater für CP/M gibt es auch. Alles sogar im Quältext.
Hallo, für C Compiler und andere CP/M SW verweise ich mal wieder auf mein Lieblingsimage, bei dem ich für Multicomp und NKC immer wieder gern zugreife: https://obsolescence.wixsite.com/obsolescence/multicomp-fpga-cpm-demo-disk Gruß, Rene
Rene V. schrieb: > für C Compiler und andere CP/M SW verweise ich mal wieder auf mein > Lieblingsimage, bei dem ich für Multicomp und NKC immer wieder gern > zugreife: Mal gebookmarked, klingt sehr gut! Habe nur später an meinem Z80 eine Floppy dran aber das kriege ich schon irgendwie hin.
Kein Problem, da ist irgendwo auch der Link, das Archiv (und nicht das Image) downzuladen. Da kannst Du dann die einzelnen Programme rauskopieren und auf Disk unterbringen. Hab ich auch so gemacht. Alter DOS PC und Superdisk können hilfreich sein. Oder per Terminal seriell übertragen. Gruß, Rene
Ich frage nochmal, bevor ich da los löte: Ich habe Pltinen bekommen aus Russland, das Mainboard und noch eine mit einer Halterung für SD Karte. Und ein Testfeld ist da auch noch drauf mit Lötpads. Wofür ist diese "ParPortProp" Platine noch alles? Ich will auf jeden Fall die 3.5z Floppy dran schrauben, daher brauche ich wohl eher keine SD. Floppy war mir mehr "Retro", außerdem sägt die so schön. Es scheint da noch ein Board zu geben für VGA Grafik. Oder? Ich bleibe aber erstmal bei meiner klass Lösung, ein FTDI Adapter und das Ganze nach minicom oder Putty umleiten auf dem PC. Mit der Kommandozeile müsste genug zu machen sein.
Christian J. schrieb: > daher brauche ich wohl eher keine SD Tu dir selbst einen Gefallen und lass die SD-Karte aktiv. Als Festplattenersatz ist so etwas unschlagbar. Du kannst sie ja im fertigen Produkt verstecken, damit es Retro aussieht.
Georg G. schrieb: > Tu dir selbst einen Gefallen und lass die SD-Karte aktiv. Als > Festplattenersatz ist so etwas unschlagbar. Ja, ok.... nur wird sie kaum lesbar sein am PC denke ich. Eingebaut wird sie, muss mich aber sowieso noch stundenmlang da einlesen und einarbeiten, die Zeiten von DOS und Apple II sind lange vorbei bei mir.... Aber da ist ja noch mehr rauf als die SD Karte und wohl ein Propeller Chip als Interface. Kannste nicht mal ein wenig mehr über das System erzählen?
Christian J. schrieb: > Kannste nicht mal ein wenig mehr über das System erzählen? Zu generischem CP/M kann ich dir etwas erzählen. Aber dein spezielles System kenne ich nicht. :-(
Christian J. schrieb: > Es soll CPM drauf laufen und natürlich eine Floppy dran. Diese muss auch > von einer Software-Erstellungs-Umgebung (welche auch immer) erreichbar > sein. Also nicht nur vom CPM aus. Aus meinen DOS Zeiten konnte ich das > über den Borland Turbo-Assembler machen über das DOS API (Int20h) oder > über C eben mit fopen, fclose usw. Hi, ich habe jetzt nicht alles gelesen, aber es gab "damals" eine Forth(83)-Version, die auf Diskette kam (kostenlos von einem Forth-Fan) und alle wesentlichen CPM-Funktionen implementiert hatte. Wir hatten da - glaube ich - einen Rechner mit Karten von Janich&Klass. Und obwohl das Forth perfekt lief auf dem Rechner, hat die (natürlich extrem konservative) Geschäftsführung auf Turbo-Pascal als Entwicklungssoftware bestanden. Vielleicht wäre für dich so eine Forth-Umgebung ja eine Alternative zu irgeneinem "C"... Gruß Rainer
Ich habe mir gerade 2 Reh CPU-280 aufgebaut, FDC, 1MB RAM und Z280 on Board. Nettes Spielzeug, kann u.a. auch 1,6MB auf 3,5" HD Disketten. Gruß, Holm
Hallo, ich wollte nur mal fragen, wer auch den Zeta SBC aufgebaut hat? Da war noch eine zweite Platine dabei mit einer SD karte und einem "Propeller" CPU. Von der weiss ich noch nicht wie ich einen "Propeller" überhaupt programmieren soll? Habe die CPU Platine per Hand verlötet erstmal. Leider viele Fehlstellen unter dem Mikrospkop in der Firma zu sehen. Die Pads und Vias sind zu klein, zu dichte Masse an Pads, keine Thermal-Pads verwendet worden usw. Hätte die mal besser auf die Welle legen sollen. Falls einer es hat: Welchen Wert braucht dieser eine Quarz Osc der mit 8 Mhz bezeichnet ist auf der Platine? Auf allen Fotos sieht man nämlich 20 Mhz. Und wofür ist diese "Propeller" Platine? Den Datenspeicher macht doch die Floppy dachte ich.
Christian J. schrieb: > Und wofür ist diese "Propeller" Platine? Den Datenspeicher macht doch > die Floppy dachte ich. Das ist eine Erweiterung mit VGA, PS/2-Tastatur, SD-Karteninterface und Lautprecher. Das Projekt ist hier beschrieben: http://www.malinov.com/Home/sergeys-projects/parportprop
Ok, die Seite kenne ich ja und habe die mal ausgedruckt. Und wie kriege ich die Firmware in diesen "propeller"? Die Baustelle wollte ich eigentlich nicht aufmachen. Ok, die steht im EEPROM drin. Aber bisher keinen Erfolg bei der Suche nach der Firmware bzw dem zu brennenden Bits. Alle Seiten sind tote Links, die ich danach absuchte. Prommer habe ich ja..
Schau mal dort => https://www.retrobrewcomputers.org/doku.php?id=software:firmwareos:romwbw:start#romwbw
Ingolf O. schrieb: > Schau mal dort => > https://www.retrobrewcomputers.org/doku.php?id=software:firmwareos:romwbw:start#romwbw Wenn Du mir sagst wo das Binary Image des I2C EEPROMs ist..... Supports ParPortProp (video, kbd, SD Card) Irgendwie kann ich mir nicht vorstellen, dass das da beim Booten reingeladen wird, da das ganze System keinen i2C Bus hat. Der Propeller zieht sich das wie ein FPGA ja beim Booten rein.
Stefan ⛄ F. schrieb: > Christian J. schrieb: >> Bisher komme ich nicht mal an die Platinen > > Kein Wunder. Z80 und Floppy sind so gut wie tot. Der Z80 Kern lebt in > Form von Mikrocontrollern noch weiter, aber nicht als nackte CPU. Was bist Du den für ein Vogel? Doch nicht der nette Stefan Frings? ???
Christian J. schrieb: > Wenn Du mir sagst wo das Binary Image des I2C EEPROMs ist..... hier: www.malinov.com/Home/sergeys-projects/parportprop/parportproptest.zip?at tredirects=0&d=1
Ich habe das Teil schon in zweifacher Ausfertigung aufgebaut. Davon einmal sogar in einem alten Zenith Laptopgehäuse. Der Oszillator 8MHz ist unterschiedlich bestückt, da er von der verwendeten CPU und CTC abhängig. Daher die Differenzen. Ich habe das ganze als 10MHz System aufgebaut. In einem Mini-EGS Gehäuse: https://felge1966.jimdofree.com/zeta-sbc-v2/ Gruss Jörg
:
Bearbeitet durch User
Mein Link scheint nicht die aktuelle Version zu beinhalten. Ich denke die ist hier zu finden: https://www.retrobrewcomputers.org/doku.php?id=software:firmwareos:romwbw:start#romwbw Dort die Datei "RomWBW v2.9.1 Distribution Package" entpacken und im Verzeichnis "Prop" steht der Quellcode. Ein BIN-File ist jedoch nicht dabei. Ich habe deshalb mal den Code schnell compiliert.
Ich danke euch erstmal, lade das gleich zu Hause dann runter.... und spiele es in ein E2Prom ein mit dem China-Prommer. Notfalls auch Arduino, je nachdem was geht. Grad mal die Platine überprüft auf "kalte lötstellen". Die 3 Oszillatoren sind bei mir bestückt wie geschrieben. Ich habe nur eine 8Mhz Z80 CPU und drunter, also 4 und NMOS mit 2Mhz. 20 Mhz sind also falsch? Der Floppy Adapter muss ja auch eine fixe Frequenz haben.
Christian J. schrieb: > Ich danke euch erstmal, lade das gleich zu Hause dann runter.... und > spiele es in ein E2Prom ein mit dem China-Prommer. Notfalls auch > Arduino, je nachdem was geht. Wenn an dem Propeller eine serielle Schnittstelle zum PC dran ist, sollte man auch mit der Entwicklungssoftware von Parallax den EEPROM via Propeller beschreiben können.
Beitrag #6098563 wurde von einem Moderator gelöscht.
Sergey hat auf seiner Seite auch was zu den Freuenzen geschrieben. CTC und CPU sollten nach Möglichkeit mit über 6MHz betrieben werden, da der Zeta sonst nur 720K Floppys nutzen kann (Replacement notes) Das ROM File des Propellers ist in den ROM Verzeichnis enthalten: https://github.com/wwarthen/RomWBW/releases/download/v2.9.1/RomWBW-2.9.1-Package.zip Gruß Jörg
:
Bearbeitet durch User
Ich habe mir mal die Schalung genauer angesehen. Die serielle Schnittstelle ist schon integriert und auch so verschaltet, dass der Propeller und das EEPROM direkt über die serielle Schnittstelle beschrieben werden können. Möglich ist das direkt mit dem Propeller Tool von Parallax oder einer Alternative, wie z.B. „bst“. Nach einem „Reset“ sucht der Propeller Bootloader zunächst nach einer seriellen Verbindung. Ist diese vorhanden, kann ein Binärfile entweder in den RAM oder den EEPROM geschrieben werden. Günstig ist, mit der Software selbst ein Reset auslösen zu können und das ist bei deiner Platine über DSR und Brücke JP2 realisiert.
Ich baue erstmal die Hauptplatine auf und habe dazu einiges bestellen müssen, was noch länger dauert, da ich nicht bei jedem Lädchen einen neuen Account anlegen will. der FDC aus China wird hoffentlich funktionieren. Denke mal, dass ein Text CP/M damit möglich ist auf einem VT100 Terminal zb minicom. Mit der PartPropCrd wird dann auch wohl einfache CGA Frafik möglich sein schätze ich mal. Sergej hat auch grad das x-tausenste "Z80 Minimal System" mit Platine veröffentlicht.
Moin, inzwischen sind 99% der Bauteile drauf, einige fehlen noch aber kommen sicher irgendwann geliefert. Mal eine Frage zu dem Memory Mapping. Ich habe einen ganze normalen Z80 mal gebaut mit 16kb ROM und 48kb RAM. Fix und nicht veränderbar. Was soll das jetzt bei dem Zeta? Da ist ein 512kb Flash ROM drauf, was sich auf 4 je 16kb Bänke abbilden lässt? Also 32 einzelne Seiten? Weiterhin sind auch 512kb RAM verbaut, die sich wohl ebenfalls "mappen" lassen? Wie soll denn da ein Programm laufen, was im Code hin und her springt? Kann da im laufenden Betrieb einfach so geswitched werden? Gibt es da vielleicht eine Grafik, die das alles etwas mehr verdeutlicht und auch warum das so gemacht wurde? Ich habe ja nicht 32 verschiede CP/M Versionen drauf.... Gruss, Christian http://www.malinov.com/Home/sergeys-projects/zeta-sbc-v2 Memory Banks and Paging The 64 KiB Z80 memory address space is divided into four 16 KiB memory banks: Bank #0 (0000h - 3FFFh Bank #1 (4000h - 7FFFh) Bank #2 (8000h - 0BFFFh) Bank #3 (0C000h - 0FFFFh) The physical memory (512 KiB Flash ROM and 512 KiB SRAM) is divided into 16 KiB pages: Pages 0 - 31 are mapped to the Flash ROM: page #0 starts at ROM address 00000h, and page #31 ends at ROM address 7FFFFh. Pages 32 - 63 are mapped to the SRAM: page #32 starts at RAM address 00000h, and page #63 ends at RAM address 7FFFFh. Page select registers are used to map physical memory pages to the banks in Z80 address space: MPGSEL_0 (78h) - Page select register for bank #0 MPGSEL_1 (79h) - Page select register for bank #1 MPGSEL_2 (7Ah) - Page select register for bank #2 MPGSEL_3 (7Bh) - Page select register for bank #3
Christian J. schrieb: > Wie soll denn da ein Programm laufen, was im Code hin und her springt? > Kann da im laufenden Betrieb einfach so geswitched werden? Wenn das OS das unterstützt, durchaus. CP/M 3 z.B. unterstützt banked memory mit bis zu 16 RAM-Bänken. http://rvbelzen.tripod.com/cpm3-prg/cpm3prg1.htm
Christian J. schrieb: > Wie soll denn da ein Programm laufen, was im Code hin und her springt? Da CP/M 2.2 von sowas nie gehört hat, mappst du einfach vier verschiedene RAM-Pages in die vier Bänke und lässt das so. Damit werden alle Programme glücklich. > Kann da im laufenden Betrieb einfach so geswitched werden? Ja. "OUT (0x78), A" wechselt die ersten 16 KB des Adressraums aus. Du solltest natürlich in dem Moment keinen Code aus diesem Bereich ausführen. Damit kannst du z.B. in deinem BIOS eine Flash- und eine RAM-Disk implementieren. Immer, wenn das BIOS einen Sektor lesen/schreiben will, mappst du kurz die Bänke 0-2 um (Bank 3 enthält ja das BIOS), kopierst die Sektordaten umher, und mappst wieder zurück. Natürlich ohne Interrupts.
S. R. schrieb: > Da CP/M 2.2 von sowas nie gehört hat, mappst du einfach vier > verschiedene RAM-Pages in die vier Bänke und lässt das so. Damit werden > alle Programme glücklich. Ich glaube das werde ich auch tun. Ich will CPM ja nur benutzen, nicht umstricken. ROMBW runterladen und glücklich sein. Ist ja alles in ASsm geschrieben und ich will C machen. Gucken wie ich den SDCC da mit einbringen kann und ob überhaupt. Müsste doch möglich sein Hex Files up zu loaden mit X-Modem oder etwas ähnlichem. Wie ist die denn die engültige Konfiguration? Liegt CPM im RAM, weil es beim Booten geladen und geswitched wurde? Oder bleibt da etwas ROM unten oder oben im Speicher? 64 kb sind ja 4 x 16kb, also 4 Bänke.
Joerg F. schrieb: > Ich habe das Teil schon in zweifacher Ausfertigung aufgebaut. > Davon einmal sogar in einem alten Zenith Laptopgehäuse. Moin, habe alles fertig gelötet, nur der Floppy Chip ist noch unterwegs aus China. Welche ROMWBW Verfsion muss man denn flashen? Stelle grad fest, dass die TopWin Software für den TLS866 den Dienst verweigert, weil sie zu alt ist. Wer baut denn sowas ein? Die lief doch. Ok, Update habe ich jetzt aus China. SST Chip wird erkannt und programmmiert. Gibt da für den Zeta Images .bin in 44kb und eines .rom mit 512kb. Welches nun? Gruss, Christian
Ok, man muss wohl das 512kb Image brennen. Leider läuft nichts, die Platine zieht 5ma und die grüne LED brennt (die auch noch falsch herum war). Sonst alles kalt, nichts zieht Strom bei voller Bestückung.... und ohne Oszi wird das wohl kaum zu finden sein. Die TTL's haben alle Spannung an GND und Vcc, den Rest habe ich noch nicht überprüft, weil ich da die Pins erst heraus suchen muss. Grumpf.... war ja teuer genug das Ganze.
Christian ne bewährte Methode beim Z80 ist es, /Wait erst mal auf Masse zu verdrahten und dann /reset. Dann bleibt das Ding im ersten Befehlsholezyklus auf der Adresse 0 stehen. Da kann Du in Ruhe durchklingeln ob das erste Byte wie vorgesehen an der CPU ankommt. Gruß, Holm
holm schrieb: > Liegt ein Takt an? Genau das habe ich selbst mit einem Multimeter verneinen können! 4.99V auf Takt Pin. Möglicherweise ist der alte 8 Mhz Oscillator aus der Wühl-Kiste defekt. Alles andere war neu, der war ausgelötet. Also neue bestellen.....
Christian J. schrieb: > Genau das habe ich selbst mit einem Multimeter verneinen können! 4.99V > auf Takt Pin. Möglicherweise ist der alte 8 Mhz Oscillator aus der > Wühl-Kiste defekt. Alles andere war neu, der war ausgelötet. Also neue > bestellen..... Leg mal den unbenutzten Pin der Oszillatordose (Pin 1?) an VDD oder an Masse. Manche Oszillatoren haben dort einen OE-Eingang zum Einschalten. Wenn der Takt da ist, der Z80 aber trotzdem spinnt, dann schalte 330 Ohm von CPU_CLK nach VDD. Mit dem Oszi gemessen muss die High-Phase an die VDD rankommen. TTL-High mit 3 V reicht hier nicht.
Hab schon neue Oscis bestellt.... erstmal alles ausschliessen was auf defekte Bauteile hindeuten koennte. Dann weitersehen. Und vielleicht mal wieder ein altes Oszi kaufen, analog reicht ja fuer einfache Dinge.
Christian schrieb: > Und vielleicht mal > wieder ein altes Oszi kaufen, analog reicht ja fuer einfache Dinge. Prinzipiell ja, aber zum Debuggen von Digitaltechnik würde ich immer zu einem Speicheroszi greifen.
Die Kombination eines guten Analogoszis zur Bewertung der Signalintegrität (Flanken, Pegel, Überschwinger) mit einem preiswerten Protokollanalyzer (Saleae bzw Plagiat desselben) zur Bewertung der digitalen Aspekte tut es genauso.
Bernd schrieb: > Prinzipiell ja, aber zum Debuggen von Digitaltechnik würde ich immer > zu einem Speicheroszi greifen. Mache ich gerne, sobald ich aus der Unterhaltszahlung für meine Kinder raus bin :-) Neuer Quarz ist drin, gleiches Ergebnis. Von den 8 Z80 die ich hier habe + den DDR Nachbau zieht er 120ma bei einer CPU mit gelbem Aufdruck und 10ma bei allen anderen. Die CPU spielt aber in meinem ersten Aufbau und der ist handverdrahtet, Fädeldraht für Fädeldraht durch die Kämme. Mein Bastelrechner zieht rund 600ma - 1.5A, je nachdem ob da NMOS drin sind oder CMOS Steine. Die Sowjet Modelle des 8255 sind da sehr hungrig. FTDI Konverter für Sub-D9 habe ich noch nicht, der ist noch aus China unterwegs. Falls jemand Spass dran hat würde ich diesem mangels Equipment mal gern das Brett schicken und auch sämtliche CPU's dazu. Sauberer Aufbau, alles unter dem Mikroskop geprüft. Ich brauche Oszis 1 x in 2 Jahren, dafür lohnt es einfach nicht. Sealea Logic habe ich auch aber den nutze ich nur für I2C und SPI Protokolle. Die sind ja fest eingestellt. Vielleicht ist die Platine auch nicht so ganz ok, kam ja aus Russland bestellt. Wer weiss...
Also wenn sie von ebay / pcbsale-ru sind, ist die Platine schon mal i.O. Da waren meine auch her. Ich habe allerdings derzeit keine Zeit für Fremdprojekte, sonst würde ich ja sagen : Schicke her, aber die nächsten Monate wirds nichts. Hast du an der CPU mal mit Logiktester geprüft, was alles dort ankommt und eventuell mal alles unnötige wie den 82c55 sowie den FDC runter? Gruß Jörg
Joerg F. schrieb: > Hast du an der CPU mal mit Logiktester geprüft, was > alles dort ankommt und eventuell mal alles unnötige wie den 82c55 sowie > den FDC runter? Alles noch nicht, dass meine Ausrüstung sehr schmal geworden ist. Ich gucke mal ob ich mir einen Oszi leihe und warte auch erstmal auf das Adapterkabel. Ich kriege das schon hin, der Fädelaufbau lief auch zuerst nicht, weil da eine Masse in der Luft hing. Alles durchmessen, Chip für Chip runter usw. Da reicht ja eine schlechte Lötstelle irgendwo und das ganze System steht still. Jedenfalls leuchtete grad schonmal die rote HALT LED als ich beim Messen war. Also irgendwas tut sich..... Ich melde mich, wenn ich da weiter bin.
Kannst Du Dir nicht aus ein paar Gattern einen einfachen Logiktester basteln? Gruß, Holm
Ich schau mal nach nem Oszi.... ab 25 Euro gibt es die ja schon... https://www.ebay-kleinanzeigen.de/s-oszilloskop/k0
Ok, schon gekauft, wird morgen abgeholt :-) 50 Ocken + Fahrtkosten für 60km.... für nen 100er nicht schlecht.
Im einfachsten Fall als Logiktester so etwas: http://www.elektronik-labor.de/Lernpakete/Kalender13/Logik.html oder http://www.dieelektronikerseite.de/Circuits/Logiktester.htm Die Teile dürften in neiner normalen Bastelkiste doch zu finden sein.... und für ganz versnobbte https://mosfetkiller.de/?s=logiktester1 Gruß Jörg
:
Bearbeitet durch User
Christian J. schrieb: > Wie ist die denn die engültige Konfiguration? Liegt CPM im RAM, > weil es beim Booten geladen und geswitched wurde? CP/M komplett im RAM inklusive BIOS ist sinnvoll, denn nur so bekommst du einen 62 KB TPA hin. Ansonsten wärst du maximal bei 47 KB (weil das BIOS auch ein paar Variablen halten muss), was für bestimmte Programme nicht reicht.
S. R. schrieb: > (weil das BIOS auch ein paar Variablen halten muss) Wenn du auf Sektorgrößen ungleich 128 Bytes gehst, musst du einen kompletten Sektor im RAM halten, damit Deblocking funktioniert. Je nach Disk Größe langt auch die Allokation Tabelle gut zu. BIOS im EProm war nur zu Urzeiten sinnvoll, als noch mit 8" Disketten hantiert wurde.
Ha das Ding mit dem Ozszi überprüft, es spielt mit 2 CPUs (Z0840006PSC Typen, gelber Aufdruck), mit den anderen 6 springt er nicht an. Kann sein, dass 8 MHz zuviel für diese sind. Stromaufnahme ist 120mA ohne den Floppy Chip und 230 mit dem WD37C65... schon etwas seltsam, dass der soviel zieht. Habe zwei Stück NOS Ware von 1987, beide das gleiche Bild. Passt aber zu einem Video über den Rechner. Mehr, wenn mein FTDI Adapter da ist, habe kein Sub-D mehr hier und mit Kabel da drin rumstochern will ich nicht. Finde ich auch etwas seltsam, grad noch eine 8 Mhz CPU geordert aber der Rest muss ja auch dazu passen und 8 Mhz waren damals nicht so üblich. Die waren alle eher langsamer. Und mein Z80C30A CTC Baustein ist Grade A was seine Taktrate angeht, also 2.5Mhz. Also da auch noch die 8Mhz Variante bestellen.... es wird langsam teuer... 140 Taler schon.
Hallo, die 8Mhz Chips sind schon da. Stromaufnahme des Boards: 20mA! Mit Floppy Chip sind es 210mA Auf vielen Leitungen zappelt es, der Adressbus ist lebending aber auffällig ist, dass kein einziger IO Request beim Starten erzeugt wird. Auf keiner der blau markierten Leitungen tut sich was, auch weil das Enable G2B nie kommt. Auf RD ist viel los an der CPU, auf WR so gut wie nichts. Die CPU scheint zu arbeiten aber das Drumherum nicht. Das Signal fiel mir auf an einigen Datenleitungen des Flash ROM. Seltsam. Ok, es wird angesteuert und es kommt was raus. Nur was... hin und wieder leuchtet die HALT LED, irgendwann kommt sie. Und auch auf den Ausgängen des 16C550 bleibt es ruhig. Natürlich auch dann auf RX/TX am MAX232. Takt usw liegt an überall. Spannung auch. Sicherheitshalber nochmal fast alle Lötstellen angeschmolzen. Ich bin mit meinem Latein am Ende und dem was ich mit einem einfachen Oszi ergründen könnte. Und ich kenne das System nicht gut genug. Bei meinem Eigenbau (handverdrahtet) konnte ich schon beim Bau alles prüfen, jede Leitung. Das spielte dann auch. Hier weiss ich nicht mal, ob die Platine überhaupt in Ordnung ist. Jetzt müsste mir jemand helfen, der das Ding schonmal gebaut hat und ich schicke es ihm samt aller doppelten Chips (habe alle 2-fach bestellt) oder es wird eine weitere (teure) Leiche im Schrank :-( Frust :-((((
Der richtige Tipp zur Fehlersuche kam doch schon. Einfach eine Step-Logik aufbauen und dann Schritt für Schritt die ersten Befehle abarbeiten. Am Daten- und Adressbus kann man dann sehr gut sehen, ob der Befehl ausgeführt wird oder wo es klemmt.
Joe G. schrieb: > Der richtige Tipp zur Fehlersuche kam doch schon. Einfach eine > Step-Logik aufbauen und dann Schritt für Schritt die ersten Befehle > abarbeiten. Jörg... bitte! Ich debugge doch nicht das gebrannte CPM System, weil ich keine Ahnung habe was da drin passiert. Zudem auf dem Ding nicht nur 1 Takt drauf ist sondern 3. Ich habe kaum Ahnung wie eine Z80 ihre Daten holt, wo da welches Bit rumwuseln muss. Das wuselt ne Menge auf den Bussen, also läuft die CPU ja. Sonst würde sie stehen bleiben per HALT etc. Nur irgendwo ist der Wurm drin oder eine Leiterbahnunterbrechung. Allein schon das Page Mapping... wenn man das bloss abschalten könnte.
Christian J. schrieb: > Jörg... bitte! Ich debugge doch nicht das gebrannte CPM System, weil ich > keine Ahnung habe was da drin passiert. (...) Dann mach Dir doch eigene EPROMs. Erstmal eins mit lauter NOPs drin, dann sollte die CPU einfach als Binärzähler arbeiten. D.h. an jeder Adressleitung muss ein Rechtecksignal zu messen sein. Dann ein Programm rein was in Endlosschleife eine I/O-Adresse anspricht und schauen ob der zugehörige /CS reagiert. Und so weiter. Die MMU würde ich erstmal totlegen. RAM-Chips raus und A14 mit A14 und A15 mit A15 verbinden, A16 und A17 auf Masse.
soul e. schrieb: > Dann mach Dir doch eigene EPROMs. Erstmal eins mit lauter NOPs drin, > dann sollte die CPU einfach als Binärzähler arbeiten. D.h. an jeder > Adressleitung muss ein Rechtecksignal zu messen sein. Ja, das klingt vernünftig. Als ich damals mein Z80 Rechner gebaut habe, habe ich das auch so gemacht, nach jedem Schritt getestet und dann weiter gebaut. Problem ist nur hierbei, dass ROM und RAM durch einen Mechanismus gemapped werden, also die "MMU". Da kann nicht einfach floaten. Das Flash ist voll, da sind 512kb drin. CPM 2.3 hat keine 512 KB. Mannomann... 20 Jahre mit Mikrocontrollern versauen einen ganz schön. Da kann der Fehler nur außerhalb liegen. Und selbst mit RAM dran waren die noch einfach, zb der Cortex M3. EPROMs passen übrigens nicht rein, da ist ein Flash drin mit einem anderen Pinning als normale EPROMs. Davon habe ich dutzende, 16kb und 8kb. PS: Der Z80-Gott Leo hat sich gemeldet, glaube er hat auch die Stamp gebaut und programmiert.... das gibt Hoffnung :-)
Christian J. schrieb: [..] > Ich habe kaum Ahnung wie eine Z80 ihre Daten > holt, wo da welches Bit rumwuseln muss. Das wuselt ne Menge auf den > Bussen, also läuft die CPU ja. Sonst würde sie stehen bleiben per HALT > etc. Nur irgendwo ist der Wurm drin oder eine Leiterbahnunterbrechung. > Allein schon das Page Mapping... wenn man das bloss abschalten könnte. Halb so wild Christian. An der CPU gibts die Signale /MREQ, /RD, /WR und /IORQ. Nach Reset holt das Ding mit /MREQ und /RD auf der Adresse 0 die Daten aus dem ROM (/M1 Maschinenzyklus 1) ist dabei aktiv. Danach werden die Signale wieder inaktiv und die nächste Adresse wird auf dem BUS gelegt, wieder /MREQ und /RD usw.. /IORQ wird bei einem IO Request aktiv. Das ist schon die Hauptsache dessen was man wissen muß. Ein Low an /Wait zwingt die CPU zu warten ..bis der Speicher mal fertig ist und das /Wait wieder weg nimmt. Das läßt sich Klasse zum Debuggen verwenden, wenn man /Wait mit einem Chip Select eines RAMs, ROMS oder IO-Bausteins verbindet, bleibt die CPU beim ersten Zugriff darauf stehen und man kann dann statisch nachmessen ob beispielsweise die Daten korrekt anliegen. Ein /BUSRQ schaltet die ganze CPU hochohmig, Du kannst dann von extern z.B. mit einem Arduino o.Ä. untersuchen was passiert wenn Du extern steuerst. /RFSH wäre noch anzumerken, nach jedem Befehl wird da ein Refreshzyklus für dynamische RAMs eingeschoben, wirst Du wohl aber nicht da dran haben. Gruß, Holm
Ok Holm, danke für die Ausführungen. Ich muss jetzt erstmal nachdenken und vor allem den Frust abbauen. Ich glaube schon, dass die CPU arbeitet, da ist ja ununterbrochen Musik auf den Leitungen. Nur auf einigen nicht wo ich es vermuten würde. Erstmal Kaffee machen... ganz ruuuuhig Christian.... und wieder runterkommen....
Hi ! Baue dir doch einfach einen NOP-Sockel den Du anstelle des Flash reinsteckst. 8 Pulldowns fertig
Ok, glaube ich habe da was... auf A0... A4 liegen jeweils auftsteigend halbierte Frequenzen, d.h. er zählt einfach nur hoch und das dauernd. M1 ist da, MREQ ist da. Da sieht so aus als hole er sich nur Nullen aus dem Flash ROM raus. Würde er arbeiten würde da ja auf Ax wuseln, Sprünge usw. Ok.... weitermachen....
Edgar S. schrieb: > Baue dir doch einfach einen NOP-Sockel den Du anstelle des Flash > reinsteckst. Glaube das FLash ist auch so schon ein NOP Sockel.... :-( Zumindest im Eprommer ist aber alles da, ist voll.
Christian J. schrieb: > PS: Der Z80-Gott Leo hat sich gemeldet, glaube er hat auch die Stamp > gebaut und programmiert.... das gibt Hoffnung :-) Also das mit dem Z80-Gott nimmst Du bitte zurück. Und die Stamp-Hardware geht im Wesentlichen auf Joe G.s Kappe.
Was hindert dich denn dran, den Flash mal kurz umzuprogrammieren? Gruss Jörg
Joerg F. schrieb: > Was hindert dich denn dran, den Flash mal kurz umzuprogrammieren? Zur Zeit eigentlich nichts. Aber da ich weiss dass der Fetch-Zyklus funktioniert tut das nicht not. Da sind alle Signale da, die sein müssen. Die Platine ist zudem grad auf dem Postweg zu jemand, der Spass an sowas hat, erheblich mehr Ahnung als ich und bei dem ich mich erkenntlich zeigen werde. Der Thread wurde damals ganz schön lang.... aber er lief mit super Hilfe aus diesem Forum hier. Aber da war ich arbeitslos und hatte den ganzen Tag Zeit von morgens bis abends. 5 Jahre her... Beitrag "Retro Fieber: Z80 oder 68000 ?"
Hallo, zunächst einmal möchte ich mich bei Leo (rapid) ganz herzlich bedanken für die schnelle Unterstützung. Das Paket mit allem Zeug war abends um 16 Uhr in der Post und am nächsten Tag schon bei ihm. 1. 1k Resistor Array als Pull Down vergessen, der war so eng zwischen zwei Sockeln, dass ich den übersehen hatte. Klar, dass die CPU in HALT ging, wenn ich die Finger dran hielt. Die Adressleitungen waren ja floatend. Zudem statt 1k ein 10k Array eingelötet. 103 ist eben 10k und nicht 1k,m das wäre 102. 2. Sub-D als Buchse statt als Stecker eingelötet, dadurch spiegelverkehrte Belegung. 3. Floppy Disk Controller Chipse beide kaputt vom China-Mann. Das ahnte ich aber schon bei deren immenser Stromaufnahme. Und last but not least und da wäre ich nicht drauf gekommen: ROMWBW fragt das PartProp Board ab, ob es da ist. Ist es nicht da bleibt der Boot Vorgang stehen und der Z80 hängt sich endlos auf. Das ist sehr wahrscheinlich ein Bug. Leo hat das Image mit veränderter Konfig neu kompiliert war übrigens sehr einfach ist unter Windows cmd Shell (Build eingeben und abwarten...). Die Images lassen sich je nach Bestückung kompilieren indem man die Config Files ändert. Grosse Klasse, Leo! Hut ab und danke!
Was sinddas für FDC ICs die Du da hast? Ich habe noch 37C65 übrig, die auf der Reh CPU280 nicht laufen (das ist ein Firmwareproblem der Z280 Geschichte) ..die sind in PLCC44 und übrig... Gruß, Holm
..ok, hab selber nachgesehen, Du brauchst 37c65 in DIP40. Gruß, Holm
So, die Mühle spielt! Stromverbrauch 50mA mit FC drauf. Nettes Spielzeug, da fühlt man sich in die 80iger versetzt :-) Und ROMBW ist voll gepackt mit Features. Jetzt noch etwas einarbeiten in die Systeme, die da angeboten werden, vor allem in CPM und dann geht's ab! Xmodem Transfer klappt auch vom PC, denn Cross Entwicklung ist da doch komfortabler. Intel Hex kann man auch direkt per Copy & Paste übertragen. @Joerg: Du hast nicht zufällig eine Putty Konfiguration, die alle Tasten richtig belegt, so dass die Cursor auch keine ESC Sequenzen erzeugen usw.? Da ist ja ne Menge einstellbar....
holm schrieb: > ..ok, hab selber nachgesehen, Du brauchst 37c65 in DIP40. Das lässt sich mit einem Adapter lösen, wenn sich sonst nichts findet. Georg
georg schrieb: > Das lässt sich mit einem Adapter lösen, wenn sich sonst nichts findet. Alles schon fertig, den Chip gabs für 15 Euro, spielt auch... naja CP/M hatte ja gar keine Cursor Tasten... schon etwas heftig da Basic zu programmieren, wenn man jede Zeile neu schreiben muss. Beim C64 konnte man reingehen und mit Return drücken war die dann drin. Aber es klappt..... tolles Teilchen.
Christian J. schrieb: > Du hast nicht zufällig eine Putty Konfiguration, die alle Tasten > richtig belegt, so dass die Cursor auch keine ESC Sequenzen erzeugen > usw.? Putty simuliert ein ANSI/VT100-kompatibles Terminal (zumindest kannst du das einstellen). Du musst also deinen CP/M-Anwendungen auch beibringen, dass sie VT100-kompatible Escape-Sequenzen verstehen. Dann funktionieren auch die Cursortasten. Andere Terminaltypen sind eher selten. Chris schrieb: > naja CP/M hatte ja gar keine Cursor Tasten... Die Terminals hatten Cursortasten, lieferten aber unterschiedliche Sequenzen dafür. Das ADM-3A liefert z.B. CTRL+{H,J,K,L} statt ESC,[,{A,B,C,D}. CCP selbst kann mit Cursortasten nicht umgehen. Wichtig ist, dass Backspace ein CTRL+H und kein DEL sendet, sonder funktioniert das nicht. (Was Delete senden sollte, weiß ich aus dem Kopf nicht.)
Chris schrieb: > naja CP/M hatte ja gar keine Cursor Tasten Es gibt den "Wordmaster" Editor für CP/M, der sich in Minuten an jedes Terminal anpassen lässt. Für gängige Typen gibt es Vorlagen. Wordmaster ist für den 10-Finger-blind Schreiber optimiert. Alles geht mit maximal 2 Tasten gleichzeitig gedrückt. Damit schlägst du in der Geschwindigkeit jeden Mausschubser um Längen :-) Falls du auch Drucken im Hintergrund oder Rechtschreibprüfung brauchst, nimmst du Wordstar. Gleiche Bedienung.
S. R. schrieb: > Putty simuliert ein ANSI/VT100-kompatibles Terminal (zumindest kannst du > das einstellen). Du musst also deinen CP/M-Anwendungen auch beibringen, > dass sie VT100-kompatible Escape-Sequenzen verstehen. Dann funktionieren > auch die Cursortasten. Andere Terminaltypen sind eher selten. Das mit dem "beibringen" dürfte bei fertiger gebrannter Software schwierig werden. Die Leute die das Image erstellt haben, haben sich ja was dabei gedacht. Die haben die CP/M Befehle, die ja wie bei DOS auch nur Dateien sind ja in das gemappte EPROM gequetscht, so dass sie wie ROM Laufwerk wirken. Bei "meinem" Z80 System habe ich ja mit ncurses eine kompatible Schnittstelle, so dass eben auch die Cursor Tasten, BS und DEL funktionieren. Ohne DEL geht es leider nicht. Tüftel ich aber noch raus, da haben ja viele mit dem N8VEM schon Erfahrungen, der ist ja kompatibel. > CCP selbst kann mit Cursortasten nicht umgehen. Wichtig ist, dass > Backspace ein CTRL+H und kein DEL sendet, sonder funktioniert das nicht. > (Was Delete senden sollte, weiß ich aus dem Kopf nicht.) Kriegen wir schon raus, sobald ich vernünftig editieren kann werde ich mich mal dran wagen. Leider haben die Basic Versionen kein Interface zur Floppy, so dass Programm speichern nur über ein List in ein Logfile geht. Man kann die Optionen alle nur über den Reset Knopf verlassen. Implementiert sind Nascom Basic und T-Basic. Befehle sie CSAVE, CLOAD etc wurden alle entfernt. Was für mich noch interessant wäre, wäre ein crt.s File für den SDCC Compiler, was die Architektur abbildet. Das Hochladen von Intel Hex ist ja kein Thema, geht mit Copy und Paste und wird als Datei auch gleich abgelegt im RAM. Kann von dort aus auf die Floppy kopiert werden.
S. R. schrieb: > Damit kannst du z.B. in deinem BIOS eine Flash- und eine RAM-Disk > implementieren. Immer, wenn das BIOS einen Sektor lesen/schreiben will, > mappst du kurz die Bänke 0-2 um (Bank 3 enthält ja das BIOS), kopierst > die Sektordaten umher, und mappst wieder zurück. Natürlich ohne > Interrupts. Hallo S.R. wo kann ich mich informieren, wie das genau läuft? CPM hat ja was mit DOS zu tun. Beim DOS gab es das BIOS im Read-Only Speicher, was aus einem ROM geladen wurde. Int 13h war das. DOS hatte aber auch viele residente Teile (Int 21h) im RAM liegen, andere Befehle waren einfach Programme die geladen wurden von der Platte. Kann CPM auch Programme > 32kb ausführen? Es belegt ja selbst RAM, kann auch nicht eben mal verschwinden. Und Programme ausführen mit Mapping stelle ich mir heftig vor. Sprünge über die Grenzen dürften dann ja crashen. Das RAM ist jedenfalls als Disk ausgeführt, wohl durch die Community zugefügt worden.
Christian J. schrieb: > Was für mich noch interessant wäre, wäre ein crt.s File für den SDCC > Compiler, was die Architektur abbildet. Wie schon mal geschrieben, sollte man sich z88dk mal anschauen (ich auch). Das ist (u.A.) ein aktueller SDCC mit fertiger crt für CP/M und vor allem einer libc mit CP/M File-I/O, stdio usw. Die komplette libc ist in Assembler geschrieben, was beim Original-SDCC ja nicht der Fall ist. http://www.z88dk.org https://github.com/z88dk Und dann gäbe es noch native CP/M C-Compiler (HI-TECH C, Aztec C), die mit einem Emulator auf DOS/Windows oder Linux laufen. In Deinem ZETA2-RomWBW-Paket werden Emulator und C-Compiler schon mitgeliefert. Aber anders, als ich schon mal schrieb, ist da Aztec drin und nicht HI-TECH. https://github.com/wwarthen/RomWBW/tree/master/Tools
1 | leo@cb:~/Projekte/Christian/Zeta2/RomWBW/Tools/cpm/bin$ ls |
2 | ARCV.COM CRC.COM GENCPM.COM LIB80.COM M80.COM SIDSYM.COM TEX21A.COM UNCR.COM ZMAC.COM |
3 | AS.COM CREF80.COM HEX80.COM LIB.COM MAC.COM SLR180.COM TEX21B.COM UNZIP.COM ZML.COM |
4 | BASCOM.COM CZ.COM HEXCOM.COM LIBUTIL.COM MLOAD25.COM SLRMAC.COM TEX21.COM USQ.COM ZMLIB.COM |
5 | CC.COM DIRX.COM L80.COM LINK.COM NULU.COM SLRNK.COM UCRLZH.COM Z80ASM.COM |
6 | CNM.COM DISKINFO.COM LBREXT.COM LN.COM RMAC.COM SQZ.COM UNARC.COM Z80MR.COM |
7 | leo@cb:~/Projekte/Christian/Zeta2/RomWBW/Tools/cpm/bin$ zxcc CZ.COM |
8 | C Vers. 1.06D Z80 (C) 1982 1983 1984 by Manx Software Systems |
9 | No input! |
10 | |
11 | leo@cb:~/Projekte/Christian/Zeta2/RomWBW/Tools/cpm/bin$ zxcc CZ.COM --v |
Leo C. schrieb: > Das ist (u.A.) ein aktueller SDCC mit fertiger crt für CP/M und > vor allem einer libc mit CP/M File-I/O, stdio usw. Die komplette libc > ist in Assembler geschrieben, was beim Original-SDCC ja nicht der Fall > ist. Ok, wir müssen eh noch mal telefonieren, da ich ein Video darüber machen will und keine Fehler reinhauen möchte. Heisst das, dass ich aus C heraus - sofern ich einen gescheiten Editor finde - zb fopen und close nutzen kann, die ja das I/O Interface nutzen? SDCC ist ja für sich allein, er kennt seine Außenwelt nicht. Das wäre dann in der libc.o drin? ncurses wäre auch noch gut, da ich dann den VT100 Moni nutzen könnte. Ich bleibe erstmal unter Windows, bisher den SDCC immer unter Linux kompiliert und eingesetzt. Da war das mit minicom und Skripten sehr schön komfortabel.
Christian J. schrieb: > Kann CPM auch Programme > 32kb ausführen? Die maximale Programmgröße hängt vom RAM Ausbau ab. Bei den gängigen 64k RAM sind gute 56k immer möglich. Dein Programm darf den CCP komplett überschreiben, nur BDOS und BIOS sind tabu. An der Adresse 0x05 steht ein Sprung an den Anfang des BDOS. So findet ein Programm heraus, wieviel RAM es nutzen darf. Hast du die CP/M Literatur? Interface Guide, System Alteration Guide, Manual? Kannst du alles als pdf haben, brauch ich nur deine Mailadresse. Zum Thema Banking: Tu es dir nicht an, noch nicht, das gibt reichlich Frust. Falls du damit spielen möchtest, nimm dir CP/M-3. Da ist das von Haus aus vorgesehen und gut machbar.
:
Bearbeitet durch User
Georg G. schrieb: > Zum Thema Banking: Tu es dir nicht an, noch nicht, das gibt reichlich > Frust. Falls du damit spielen möchtest, nimm dir CP/M-3. Ich glaube für den Fall habe ich hier noch ein Cortex M3 Board mit 32 MB RAM rum liegen... habe unbestätigte Gerücht gehört es soll inzwischen der 32 Bit Bus erfunden worden sein, beginnend mit dem 68000er...
PS: Sorry, wenn ich hier etwas viel tippe.... aber das Ding ist halt spannend. Ich habe versucht aus "Retro Gründen" ein 27C040 EPROM mit großem Fenster zu benutzen. Sieht halt irgendwie besser aus und wenn man es im Raum belässt bleibt es auch erhalten ohne Aufkleber. Dazu Pin 1 auf Pin 31 am EPROM verlötet da sich der Flash SST29F040 von dem 27C040 unterscheidet, A18 liegt beim Flash auf 31, beim EPROM auf 1. 1 beim Flash ist NC, 31 ist #WE (nur für programmieren). Vpp ist normalerweise "dont care" wenn nicht programmiert wird. Klappte aber leider nicht, der Rechner lief gar nicht an. Klar dass das EPROM richtig programmiert wurde. Aber wie sieht es mit dem Timing aus? Die Kiste läuft auf 8Mhz, alle Z80 Teile sind dafür gekauft worden. Das EEPROM hat 120ns Zugriffszeit laut Datenblatt. Müsste doch reichen. 1/120E-9 = 8.333 Mhz
Christian J. schrieb: >> Du musst also deinen CP/M-Anwendungen auch beibringen, >> dass sie VT100-kompatible Escape-Sequenzen verstehen. >> Dann funktionieren auch die Cursortasten. > > Das mit dem "beibringen" dürfte bei fertiger > gebrannter Software schwierig werden. Es dürfte auch schwierig sein, einem Hund das Miauen beizubringen... Befasse dich mit der Software, die du benutzen möchtest, und du solltest irgendwo rauskriegen, wie man sie an verschiedene Terminaltypen anpasst. Außerdem solltest du dein Terminal (bzw. deinen Terminalemulator) kennen, sonst ist das alles hinfällig. Bei WordStar gibt man den Terminaltypen während der Installation an, und der Installer patcht dann die passenden Sequenzen in WordStar rein. Oder man patcht selbst, die Adressen findet man in der Dokumentation zu WordStar. Oder du findest irgendwo im Netz passend gepatchte Versionen, die gibt es auch... Multiplan kennt ANSI-Terminals ab Werk. > Die Leute die das Image erstellt haben, haben sich ja > was dabei gedacht. Sicherlich. Die haben bestimmt auch dazugeschrieben, mit welcher Software du arbeiten sollst. > Die haben die CP/M Befehle, die ja wie bei DOS auch nur Dateien > sind ja in das gemappte EPROM gequetscht, so dass sie wie > ROM Laufwerk wirken. Äh. Ich tue mal so, als hätte ich das nicht gelesen. > Bei "meinem" Z80 System habe ich ja mit ncurses eine kompatible > Schnittstelle, so dass eben auch die Cursor Tasten, BS und DEL > funktionieren. Ohne DEL geht es leider nicht. Tja, was gibt denn dein Terminal so an Bytesequenzen aus, wenn du Cursortasten, Backspace oder Delete drückst? Und was erwartet deine Gegenstelle? Christian J. schrieb: >> Damit kannst du z.B. in deinem BIOS eine Flash- und eine RAM-Disk >> implementieren. Immer, wenn das BIOS einen Sektor lesen/schreiben will, >> mappst du kurz die Bänke 0-2 um (Bank 3 enthält ja das BIOS), kopierst >> die Sektordaten umher, und mappst wieder zurück. Natürlich ohne >> Interrupts. > > wo kann ich mich informieren, wie das genau läuft? Indem du dir einfach mal verschiedene Mappings auf ein Blatt Papier malst und schaust, wie man das sinnvoll macht. Es ist dein Code, du entscheidest. Du musst dich nur an die API halten, und die ist im "CP/M Alteration Guide" beschrieben. > CPM hat ja was mit DOS zu tun. Nein, hat es nicht. > Beim DOS gab es das BIOS im Read-Only Speicher, was aus > einem ROM geladen wurde. Nein, das BIOS wird nicht aus einem ROM geladen, sondern von dort ausgeführt. > Int 13h war das. Nein, der int 13h ist nicht "das BIOS". Da gehört noch wesentlich mehr dazu. > DOS hatte aber auch viele residente Teile (Int 21h) > im RAM liegen, andere Befehle waren einfach > Programme die geladen wurden von der Platte. Ja. Und was bedeutet das jetzt? Nix. > Kann CPM auch Programme > 32kb ausführen? Wenn du genug RAM hast, ja. > Es belegt ja selbst RAM, kann auch nicht eben mal verschwinden. Hättest du dich mal darüber informiert, wie CP/M funktioniert - es gibt da Dokumentation zu, die ist sogar lesenswert - dann wüsstest du, dass du teilweise falsch liegst. > Und Programme ausführen mit Mapping stelle ich mir heftig vor. > Sprünge über die Grenzen dürften dann ja crashen. CP/M 2 weiß nichts von Bank Switching, daher ist sämtlicher Speicher oberhalb von 64 KB nur als RAM-Disk sinnvoll. CP/M 3 unterstützt Bank Switching. Befasse dich einfach mal damit, ich verweise auch hierzu auf die Dokumentation von Digital Research oder auch Youtube, wie das funktioniert. Das könnte dir helfen. > Das RAM ist jedenfalls als Disk ausgeführt, wohl durch > die Community zugefügt worden. ???
Hallo! Mein Name ist Bruno und ich habe auch ein Zeta V2 gemacht aber es funkzioniert nicht. Ich habe kein Propeller Board, nur basis Platinne. Ich habe 5V auf alles chips, aber kein ausgang am seriell Port. MAX202 ist nach dem cca 20 sekunden sehr heiß. Habe keine Frequencmessgerät und kein Oscyloskop. Suche nach lösung meine problemme :-(
Georg G. schrieb: > Christian J. schrieb: >> Kann CPM auch Programme > 32kb ausführen? > > Die maximale Programmgröße hängt vom RAM Ausbau ab. Bei den gängigen 64k > RAM sind gute 56k immer möglich. > Dein Programm darf den CCP komplett überschreiben, nur BDOS und BIOS > sind tabu. Das ist definitiv falsch, das BDOS kann auch überschrieben werden, nach exit des Programms erfolgt dann ein neu Laden von BDOS und CCP. CPU280 Boot Loader V1.2 RBC 4-Jun-2018 http://www.retrobrewcomputers.org based on Cold Loader Program V1.13 TR 950314 Press DEL to run SETUP. 1024k RAM ok CP/M-3 Loader V1.2 RBC 4-Jun-2018 based on CP/M-3 Loader V1.13 Booting system file from EPROM BNKBIOS3 SPR FE00 0200 BNKBIOS3 SPR AA00 4600 RESBDOS3 SPR F800 0600 BNKBDOS3 SPR 7C00 2E00 62K TPA CP/M-3 BIOS V1.2 RBC 8-Mar-2017 http://www.retrobrewcomputers.org based on CP/M-3 BIOS V1.13 TR 950314 E: MDrive 768k H:-K: DOM Module 128 MB E> Wie man sieht kann ein Bankbios bis in die Gegend von 62Kbyte TPA anbeiten, hier auf einem Z280. Gruß, Holm
Georg G. schrieb: > Christian J. schrieb: >> Kann CPM auch Programme > 32kb ausführen? > > Die maximale Programmgröße hängt vom RAM Ausbau ab. Bei den gängigen 64k > RAM sind gute 56k immer möglich. > Dein Programm darf den CCP komplett überschreiben, nur BDOS und BIOS > sind tabu. Das ist definitiv falsch, das BDOS kann auch überschrieben werden, nach exit des Programms erfolgt dann ein neu Laden von BDOS und CCP. CPU280 Boot Loader V1.2 RBC 4-Jun-2018 http://www.retrobrewcomputers.org based on Cold Loader Program V1.13 TR 950314 Press DEL to run SETUP. 1024k RAM ok CP/M-3 Loader V1.2 RBC 4-Jun-2018 based on CP/M-3 Loader V1.13 Booting system file from EPROM BNKBIOS3 SPR FE00 0200 BNKBIOS3 SPR AA00 4600 RESBDOS3 SPR F800 0600 BNKBDOS3 SPR 7C00 2E00 62K TPA CP/M-3 BIOS V1.2 RBC 8-Mar-2017 http://www.retrobrewcomputers.org based on CP/M-3 BIOS V1.13 TR 950314 E: MDrive 768k H:-K: DOM Module 128 MB E> Wie man sieht kann ein Bankbios bis in die Gegend von 62Kbyte TPA anbeiten, hier auf einem Z280. Gruß, Holm Christian J. schrieb: > Georg G. schrieb: >> Zum Thema Banking: Tu es dir nicht an, noch nicht, das gibt reichlich >> Frust. Falls du damit spielen möchtest, nimm dir CP/M-3. > > Ich glaube für den Fall habe ich hier noch ein Cortex M3 Board mit 32 MB > RAM rum liegen... habe unbestätigte Gerücht gehört es soll inzwischen > der 32 Bit Bus erfunden worden sein, beginnend mit dem 68000er... Du irrst, ein 68000 hatte einen 16 Bit Bus, ein 68008 8Bit, auch wenn sie beide 32Bit breite Register hatten. Ab 68020/80386 gibts 32 Bit breite Busse. Komm mit Deiner hohen Nase wieder runter, da oben ist es heiß, man holt sich sonst leicht einen Sonnenbrand auf der Nase. Gruß, Holm
holm schrieb: > BDOS kann auch überschrieben werden Du darfst alles überschreiben. Nur darfst du dich dann nicht über seltsame Effekte wundern. Wie bitte soll ein System Call funktionieren, wenn du das System gerade überschrieben hast?
holm schrieb: > CP/M-3 Loader V1.2 RBC 4-Jun-2018 > based on CP/M-3 Loader V1.13 > Booting system file from EPROM > > BNKBIOS3 SPR FE00 0200 Man braucht nicht CP/M3, um Bankswitching zu machen, das kann man sich auch selber einrichten. Ich habe mir ein Overlay-System erstellt, allerdings funktionierte das mit Nachladen der Overlays von Floppy etc., aber es geht genausogut mit Nachladen aus RAM-Bänken oder mit direktem Umschalten von Bänken mit den Overlays (was bei mir nicht ging wegen mehr als 100 Overlays). Angeber wie Christian muss man einfach nicht beachten. Georg
LEUTE! Könnt euch bitte mal außerhalb meines Thread beharken? Gerade Holm geht mir in steigendem Maße langsam auf den Zünder mit seiner Art sich mit JEDEM anzulegen aber auch jene, die darauf anspringen. Sucht euch bitte eine andere Spielwiese, ich komme schon klar! Christian
Du startest hier einen Thread über ein Z80-System, machst dich dann aber hämisch über Z80-User lustig: Christian J. schrieb: > habe unbestätigte Gerücht gehört es soll inzwischen > der 32 Bit Bus erfunden worden sein, beginnend mit dem 68000er... Also entweder massive Schizophrenie oder von vornherein ein Trollversuch. Dass man mit einem 32bit-Bus viel Speicher ansprechen kann, ist nicht neu und brüsten muss man sich mit solchen Kenntnissen auch nicht, das weiss und kann auch jeder andere hier, bloss hat das mit dem von dir selbst gestellten Thema nicht das geringste zu tun. mit trolligen Grüssen Georg
georg schrieb: > Also entweder massive Schizophrenie oder von vornherein ein > Trollversuch. Georg, bleib einfach aus meinen Threads raus. Du und einige andere hier seit einfach ein streitsüchtiges Volk und damit möchte ich nichts zu tun haben. Danke für Deine Beitrag und weiterhin ein schönes Leben.
Christian J. schrieb: > Georg, bleib einfach aus meinen Threads raus Manchmal lasse ich mich halt von Trollen wie dir trotzdem provozieren. Georg
Georg G. schrieb: >> BDOS kann auch überschrieben werden > > Du darfst alles überschreiben. Nur darfst du dich dann nicht über > seltsame Effekte wundern. Wie bitte soll ein System Call funktionieren, > wenn du das System gerade überschrieben hast? Wenn ich das BDOS nicht mehr brauche, dann kann ich es problemlos überschreiben und die Anwendung per "RST 0" beenden. Die BIOS-Calls bleiben erhalten, wo ist das Problem? Christian J. schrieb: > Sucht euch bitte eine andere Spielwiese, ich komme schon klar! Du behauptest, ein großer Virenprogrammierer zu DOS-Zeiten gewesen zu sein, kriegst aber die grundlegenden Fakten nicht auf die Reihe. Du hast gewisse Dinge nachweislich schonmal gemacht, scheiterst aber immer wieder daran. Beschäftigst dich schon länger mit Z80 und CP/M, versagst aber ständig in den Grundlagen. Stellst in unregelmäßigen Abständen die gleichen Fragen, die dir schonmal beantwortet (oder sogar erklärt) wurden. Wenn man dich über einen längeren Zeitraum betrachtet (auch mit dem anderen Account), dann hast du schon äußerst trollige Züge. Aktives Trollen verstärkt diesen Eindruck dann noch. Vielleicht gibt's ja noch andere Gründe, 'ne gutartige Demenz oder so...
S. R. schrieb: > Stellst in unregelmäßigen Abständen die > gleichen Fragen, die dir schonmal beantwortet (oder sogar erklärt) > wurden. Vielleicht habe ich einfach nicht so viel Zeit hier überhaupt mit zu kriegen, wer was schreibt und sogar User zu verfolgen? Mir nicht einmal darüber Gedanken mache? Bis auf einige wenige, die unentwegt in Auseinandersetzungen verwickelt sind? Liegt vielleicht auch daran, dass oft Wochen oder Monate vergehen, die ich ganz ohne dieses Forum lebe, was ich seit 20 Jahren (!) kenne und dort angemeldet bin unter einer einzigen Präsens. Ach ja, von 2010 bis 2015 war Pause meinerseits, kommt auch mal vor.
Christian J. schrieb: > Vielleicht habe ich einfach nicht so viel Zeit hier überhaupt mit zu > kriegen, wer was schreibt und sogar User zu verfolgen? Es gibt nur sehr wenige User, die sich mit CP/M und Z80 beschäftigen. Die fallen auf, wenn man zu der Gruppe gehört. Genauso, wie es zur Zeit nur genau einen aktiven User gibt, der sich in einem anderen Forum mit dem 8086 prügelt. Im Übrigen hast du den eigentlichen Kritikpunkt vollständig ignoriert, gratuliere. Ich verweise also einfach mal auf die Forensuche. Du könntest dort Fragen auf deine Antworten finden, auch zu CP/M, und mit ein bisschen Glück sogar von dir. Optimal wäre sogar, wenn du das machst, bevor du fragst.
S. R. schrieb: > Ich verweise also einfach mal auf die Forensuche. Du > könntest dort Fragen auf deine Antworten finden, auch zu CP/M, und mit > ein bisschen Glück sogar von dir. Optimal wäre sogar, wenn du das > machst, bevor du fragst. Dazu bin ich schon vor kurzer Zeit über gegangen und ja, es stimmt, wenn es um Z80, 8085 usw geht springen einige User hoch, was ja auch zu begrüßen ist. Ohne jene wäre es mir niemals gelungen vor 5 Jahren das Thema zu bearbeiten, wofür diesen User, namentlich Leo und A.K. mein großer Dank gebührt. Mal sehen wie weit es mich trägt, da ich noch andere Hobbies habe, die in Gesellschaft ausgeübt werden, während CP/M doch eher die Sorte ist, die allein und schweigend stattfindet. Daher auch die großen Pausen, solche Themen nur bei Regenwetter und im Winter.
Georg G. schrieb: > holm schrieb: >> BDOS kann auch überschrieben werden > > Du darfst alles überschreiben. Nur darfst du dich dann nicht über > seltsame Effekte wundern. Wie bitte soll ein System Call funktionieren, > wenn du das System gerade überschrieben hast? Georg..bitte..Du warst doch bis jetzt fachlich ganz gut auf Draht, warum denkst Du sollte man einen System Call eines überschriebenen Systems überhaupt nutzen wollen? Es ist klar wie Kloßbrühe das nach Überschreiben des BDOS dessen Funktionen nicht mehr nutzbar sind, aber das BIOS und dessen Funktionen arbeiten nach wie vor normal, daraus ergibt sich das der Programmexit dann ein Kalstart sein sollte. Gruß, Holm
Christian J. schrieb: > LEUTE! > > Könnt euch bitte mal außerhalb meines Thread beharken? Gerade Holm geht > mir in steigendem Maße langsam auf den Zünder mit seiner Art sich mit > JEDEM anzulegen aber auch jene, die darauf anspringen. > > Sucht euch bitte eine andere Spielwiese, ich komme schon klar! > > Christian Nun gut Christian. Es gibt User die glauben etwas zu wissen und es gibt User die aus Erfahrung wissen und ggf. die korrigieren, die glauben Z80 hätte was mit Klimawandel oder Gott zu tun. Ich habe Deine Hochnäsigkeit kritisiert, was wohl der eigentliche Grund für das "zuhnemend auf die Nerven" gehen ist. Ich sags mal so: Wer nicht will, der hat schon. Mach also hier weiter, ich werde mich raushalten. Erfahrungsgemäß findest Du mich 1 Jahr später dann wieder um mich was zu fragen, so lange kannst Du ja in Deinem eigenen Saft schmoren. Literatur gibts genug..Du mußt nur lesen. Gruß, Holm
S. R. schrieb: > Ich verweise also einfach mal auf die Forensuche. Du > könntest dort Fragen auf deine Antworten finden, auch zu CP/M, und mit > ein bisschen Glück sogar von dir. Optimal wäre sogar, wenn du das > machst, bevor du fragst. Tja... nur finde ich halt auf so manches Problem nicht mal im Netz Antworten :-( Die 1.44MB Floppy läuft soweit aber eben nicht richtig. 2 von 3 Disketten scheitern schon beim Verify des Formats an zu vielen defekten Sektoren. Ich habe früher noch nie eine kaputte Floppy gehabt und habe Jahre mit Disketten gearbeitet. Seltsam... jedenfalls liess sich eine Disk überreden mit 0 Fehlern den Verify zu überstehen. fdu und cleardir angewendet... leider lässt sich weder mit copy noch mit pip etwas Funktionierendes auf die Floppy kopieren. Es entsteht immer dieser Fehler, entweder beim Verify oder später bei der Ausführung. Keine Ahnung.... Spannung von 5.0 auf 5.2 angehoben, Interleave Faktor auf 5-6 gesetzt, Kabel sehr kurz gemacht auf 10cm == keine Verbesserung!
Christian J. schrieb: > Ich habe früher noch nie eine kaputte Floppy gehabt > und habe Jahre mit Disketten gearbeitet. Seltsam... Die Magnetschicht der Medien ist wahrscheinlich mittlerweile in eher mäßigem Zustand, die Laufwerke selbst könnten vermutlich etwas Säuberung gebrauchen... und ich gehe davon aus, dass du die Disketten selbstverständlich nicht in einem normalen PC ausprobiert hast?
Christian J. schrieb: > Tja... nur finde ich halt auf so manches Problem nicht mal im Netz > Antworten :-( Die 1.44MB Floppy läuft soweit aber eben nicht richtig. Läuft die Floppy mit 1,44 MB (HD) oder mit 720 kB (DD)? Wird der Density Select-Pin passend bedient (beim PC Pin 2), bzw ist das Laufwerk auf automatische Erkennung (über das Loch in der Diskette) eingestellt? Bei PC-Laufwerken ist meist letzteres der Fall. Sind die zur Datenrate passenden Disketten drin? DD auf HD scheiben oder umgekehrt klappt genauso gut wie am Tapedeck Metal-Cassetten mit der CrO2-Einstellung aufnehmen. Die Flussdichte passt nicht, es wird zuviel oder zuwenig magnetisiert, dadurch sind die Medien nach kurzer Zeit nicht mehr lesbar. HD drinhaben und HD eingestellt haben, dann aber mit 250 kbit/s drauf gehen klappt ebenfalls nicht. Die Datenrate muss zum Einstellung des Laufwerkes und damit indirekt zum Medium passen. > 2 von 3 Disketten scheitern schon beim Verify des Formats an zu vielen > defekten Sektoren. Ich habe früher noch nie eine kaputte Floppy gehabt > und habe Jahre mit Disketten gearbeitet. Seltsam... jedenfalls liess > sich eine Disk überreden mit 0 Fehlern den Verify zu überstehen. Das kann normal sein... Funktionieren diese Disketten am PC, lassen sie sich da formatieren? Meine Erfahrung als Sammler historischer Computer mit >400 5,25" und >100 3,5"-Disketten im Bestand: * Disketten bis 1995 funktionieren eigentlich immer. Sowohl Markenware als auch die "weissen" aus der C64 Szene. Bei 5,25" gibt es Ausreisser (BASF, einige 3M), wo sich die Magnetschicht ablöst und schmiert. Das sind bestimmte Serien, der Rest ist aber in Ordnung. * brauchbare Disketten zwischen 1995 und 1999: TDK, TDK, Memorex, 3M, ... NoName funktioniert meist nicht mehr. Einige Serien der Markenhersteller (Precision, ...) ebenfalls nicht. * ab 2000: vergiss es...
S. R. schrieb: > Die Magnetschicht der Medien ist wahrscheinlich mittlerweile in eher > mäßigem Zustand, die Laufwerke selbst könnten vermutlich etwas Säuberung > gebrauchen... und ich gehe davon aus, dass du die Disketten > selbstverständlich nicht in einem normalen PC ausprobiert hast? Die 1.44mb Floppy's sind ehrlich gesagt 25 Jahre alt. Das Laufwerk wohl nicht viel weniger, habe 2 Stück. Und ich habe schon ewig kein Mainboard mehr mit einer IDE Schnittstelle. Mit testen im PC wird da nichts, es sie denn ich besorge mir mal so ein USB Laufwerk. Eine lässt sich ja einwandfrei formatieren aber da ist wohl ein Wurm im System drin, da dieser Fehler ja auf ein Problem beim Kopieren hindeutet.
soul e. schrieb: > Läuft die Floppy mit 1,44 MB (HD) oder mit 720 kB (DD)? > Wird der Density Select-Pin passend bedient (beim PC Pin 2), bzw ist das > Laufwerk auf automatische Erkennung (über das Loch in der Diskette) > eingestellt? Bei PC-Laufwerken ist meist letzteres der Fall. Ich weiss nur noch soviel, dass DD und HD zwei paar Schuhe sind. Im 1.44 Laufwerk ließen sich beide verwenden. Ich habe bei dem Zeta Rechner aber einiges einzustellen, das beschränkt sich jedoch auf HD oder DD und auf den Interleave, den ich zwischen 2 und 6 varriert habe. Je höher, desto langsamer das Lesen. 2 packt der Rechner aber nicht, dafür ist er mit 8 Mhz zu langsam. Meine C64 Disketten sind meist noch lesbar und die sind jetzt 1985... also 35 Jahre alt. Die CD ROM von 1996 aber nicht mehr wo meine Uni Arbeiten drauf waren, sind alle Schrott. Ebenso die rund 200 DVD, die ich ab 2002 mit TV Sendungen bespielt habe, neulich alle entsorgt. Habe übrigens 2 Böder Disketten und BASF, die BASF waren völlig fratze, die Böder laufen noch. Sind von 1998. Habe mir bei ebay mal 2 DD mit 720kb besorggt, gucken ob die besser laufen. Und das Laufwerk kriegt man eine Isoprop Reinigung verpasst bei den Leseköpfen.
Christian J. schrieb: > Und ich habe schon ewig kein Mainboard > mehr mit einer IDE Schnittstelle. Eine typische "Christian"-Antwort. Diskettenlaufwerke haben keine IDE-Schnittstelle. Christian J. schrieb: > Ich weiss nur noch soviel, dass DD und HD zwei paar Schuhe sind. Und so viel Detailwissen...
Christian J. schrieb: > Die 1.44mb Floppy's sind ehrlich gesagt 25 Jahre alt. Das Laufwerk wohl > nicht viel weniger, habe 2 Stück. Das ist eher von Vorteil. Hochwertige Disketten wurden nur bis ca 1995 produziert, danach waren sie eher als kostenoptimierte Wegwerfartikel ausgelegt. Und alte Laufwerke, insbesondere alte Varianten der Teac FD-235, haben den Vorteil dass noch alle Funktionen über Jumper eingestellt werden können. Spätere Modelle sind mehr oder weniger fest auf "IBM PC" verdrahtet. > Eine lässt sich ja einwandfrei formatieren aber da ist wohl ein Wurm im > System drin, da dieser Fehler ja auf ein Problem beim Kopieren > hindeutet. Aber Du bist Dir absolut sicher, dass Dein CP/M-Rechner auch einen HD-Datenstrom mit 500 kbit/s liefert? Üblich war das damals nicht, die meisten CP/M-Kisten machen SD (125+125 kbit/s) oder DD (250 kbit/s). In diesem Fall kannst Du ein 1,44 MB-Laufwerk nur verwenden wenn Du es auf DD umstellst und passende Disketten verwendest. Ansonsten funktioniert es nur sporadisch.
soul e. schrieb: > Aber Du bist Dir absolut sicher, dass Dein CP/M-Rechner auch einen > HD-Datenstrom mit 500 kbit/s liefert? Üblich war das damals nicht, die > meisten CP/M-Kisten machen SD (125+125 kbit/s) oder DD (250 kbit/s). In > diesem Fall kannst Du ein 1,44 MB-Laufwerk nur verwenden wenn Du es auf > DD umstellst und passende Disketten verwendest. Ansonsten funktioniert > es nur sporadisch. Genau das scheint mir der Wurm zu sein. Mein Laufwerk hat keine Jumper mehr und für PC kommt es mit DD und HD klar. Ich warte immer noch auf die 720er die ich bestellt habe und ich werde auch mal versuchen ein sehr altes Laufwerk zu bekommen. Und dann werde ich von 8 Mhz auf 6 Mhz runtergehen. Der Rechner springt ganz sporadisch in einen HALT rein, unedfinierbar, mal nicht, mal schon. Und den Zirkus hatte ich schon 2015, der erst behoben wurde als ich auf 4 Mhz zurück ging. Ich habe nur intensv mit dem FDU Tool gespielt und da bricht der Verify ab, sobald ein Sektor nicht die richtigen Bufferdaten enthält. Und das kann bei ein und derselben Diskette unterschiedlich sein wo der erste Sektor Zicken macht. Erstmal ein USB externes FDD bestellt, damit ich meine noch recht großen Bestände von 1995 testen und auch sichern kann. Verify Programme dürfte es ja noch geben, Windows 7 hat so eines ja auch eingebaut unter "Eigenschaften".
soul e. schrieb: > Aber Du bist Dir absolut sicher, dass Dein CP/M-Rechner > auch einen HD-Datenstrom mit 500 kbit/s liefert? Er hat keinen Rechner aus den späten 70er Jahren, sondern eine modernen Retro-SBC-Entwicklung mit einem halbwegs modernen Floppy-Controller, entworfen in diesem Millenium. Da steckt ein FDC drin, den man in zigtausenden ISA-Karten findet, oder auf 386er/486er Boards. soul e. schrieb: > Spätere Modelle sind mehr oder weniger fest > auf "IBM PC" verdrahtet. Richtig, und genau deswegen entwickelt man Retro-Geräte (wie z.B. den Zeta V2) heutzutage um genau diese Annahmen herum. Echte DD-Laufwerke und DD-Medien sind inzwischen schwierig zu finden und führen in einem Retro-Kontext zu mehr Frustration als Spaß. Gilt natürlich nicht, wenn man mit Commodore oder Apple hantiert. Aber auch da geht es hauptsächlich darum, wie man normale PC-Laufwerke anknotet. Christian J. schrieb: > Genau das scheint mir der Wurm zu sein. Nö, das isses ganz sicher nich.
Christian J. schrieb: > Erstmal ein USB externes FDD bestellt, damit ich meine noch > recht großen Bestände von 1995 testen und auch sichern kann. Schlechte Entscheidung. USB-Laufwerke - taugen nicht besonders viel; - kommen nicht mit marginalen Medien klar; - können oft keine DD-Formate verarbeiten; - Formate jenseits von "IBM PC" sowieso nicht; - unterstützen keine lowlevel-Zugriffe, die man für Datenrettung braucht. Wenn du wirklich eine sinnvolle Entscheidung treffen willst, dann besorge dir einen Gotek, flashe den auf FlashFloppy um, klemme den an dein Board und teste ob das funktioniert. Du kannst den danach ja wieder wegschmeißen. Funktioniert das nicht, ist dein Board kaputt. Funktioniert das, sind deine Laufwerke oder Disketten kaputt. So einfach ist das.
Tja, da staunt der Laie und der Fachmann wundert sich.... das scheiss Ding geht! Mit 720kb Disketten... ratter,chrr..tack, tack, tack... lange nicht gehört das Geräusch. Ich kann sogar vom Laufwerk booten :-) Das ist ja besser als Weihnachten! Aber 1.44MB bleibt ein Wunschtraum. Jedenfalls gehe ich jetzt mal runter auf 6 Mhz, da der 8255 die 8 Mhz sowieso wohl nicht packt. Pure Vermutung: Da der Kopierfehler ein immer wieder zu repoduzierender "logischer Fehler" war könnte es auch sein, dass dieses Board nie wirklich mit 1.44 MB getestet worden ist. Und dass die Software das Laufwerk ggf. nicht richtig ansteuert mit einer 1.44MB Diskette. Aber nur pure Vermutung...
Christian J. schrieb: > Pure Vermutung: Da der Kopierfehler ein immer wieder zu repoduzierender > "logischer Fehler" war könnte es auch sein, dass dieses Board nie > wirklich mit 1.44 MB getestet worden ist. Und dass die Software das > Laufwerk ggf. nicht richtig ansteuert mit einer 1.44MB Diskette. 95% der PC-Laufwerke erkennen HD-Disketten an dem zweiten Indexloch an der Oberkante. Die anderen 5% bekommen es über Pin 2 mitgeteilt. Damit wird der Schreib/Leseverstärker an die Magnetschicht angepasst. Damit es funktioniert muss aber auch die Datenrate des Floppycontrollers passen. Und dem Controller sagt keiner was für eine Diskette einliegt. Das kann er nur ausprobieren. Ein PC versucht erst mit 500 kbit/s zu lesen, wenn das klappt ist es HD. Danach versucht er es mit 250 kbit/s, wenn da lesbare Daten rauskommen ist es DD. Ansonsten defekt oder nicht formatiert. Beim erstmaligen Beschreiben (formatieren) muss man dem Controller sagen mit welcher Frequenz er das Laufwerk beaufschlagen soll. Bei MS-DOS wäre das "format A: /F:720" für DD oder "format A: /F:1.44" für HD. Das 1.44 ist default, das kann man auch weglassen. Hier ist der Schaltplan von Deinem Zeta-SBC: https://docs.google.com/viewer?a=v&pid=sites&srcid=bWFsaW5vdi5jb218d3d3fGd4OjViN2NjZGMxY2I5ZjkwNzM Wie man sieht geht Pin 2 des Floppysteckers an Pin 36 des WD37C65C, und das ist der /RWC-Ausgang. Der Pin ist High für MFM 500K (HD) und Low für MFM 250K (DD). Also wie beim PC -- keine Rückmeldung des Diskettentyps vom Laufwerk an den Controller. D.h. Du musst beim Formatieren angeben mit welcher Datenrate geschrieben werden soll. Wenn Du eine 1,44 MB-Diskette mit 250 kbit/s formatierst, dann funktioniert das nur recht sporadisch. Bzgl 8255 hatte ich mir mal das hier notiert: Intel P8255A 4 MHz (250 ns) P8255A-5 5 MHz (200 ns) NEC D8255AC-2 5 MHz (200 ns) D8255AC-5 4 MHz (250 ns) D71055C 8 MHz (120 ns) D71055C-8 8 MHz (120 ns) D71055C-10 10 MHz (100 ns) Harris 82C55A-5 5 MHz (200 ns) 82C55A 8 MHz (120 ns)
soul e. schrieb: > D.h. Du musst beim Formatieren angeben mit welcher Datenrate geschrieben > werden soll. Wenn Du eine 1,44 MB-Diskette mit 250 kbit/s formatierst, > dann funktioniert das nur recht sporadisch. Hi, danke erstmal für die Infos wie das alles zusammen hängt. Die Datenrate kann man nicht einstellen. Das Tool fdu.com hat nur ein Setup über die Disk Größe und den Interleave. Mehr ist da nicht. Ich habe da alles durch. Aber vielleicht fällt mir noch was ein. PS: Das Formatieren ging ja auch alles und auch der Verify. Die Fehlermeldung auf die Du nicht eingingst trate ja erst beim copy.com auf und zwar beim Vergleichen. Und zwar immer. Die kopierten Dateien waren auch nicht startbar, da trat der gleiche Fehler auf: END OF CYLINDER. FDU Manual: https://github.com/wwarthen/RomWBW/blob/master/Doc/FDU.txt Mein 82C55A ist so WinChing aus China... muss ich mal gucken wie der tickt, ob der die 8 Mhz packt.
Christian J. schrieb: > PS: Das Formatieren ging ja auch alles und auch der Verify. Die > Fehlermeldung auf die Du nicht eingingst trate ja erst beim copy.com auf > und zwar beim Vergleichen. Und zwar immer. Die kopierten Dateien waren > auch nicht startbar, da trat der gleiche Fehler auf: END OF CYLINDER. Also das was ging war innerhalb FDU, und das was nicht ging war im CCP, also mit "A> "? > FDU Manual: > https://github.com/wwarthen/RomWBW/blob/master/Doc/FDU.txt In dem von Dir verlinkten Dokument steht "Note that FDU does not utilize your systems ROM or OS to access the floppy system. FDU interacts directly with hardware. Upon exit, you may need to reset your OS to get the floppy system back into a state that is expected." D.h. FDU spricht direkt mit der Hardware, und zwar so wie Du das beim Start vorgegeben hast. Wenn Du HD einstellst (wie auch immer), dann mit HD, und wenn Du DD einstellst mit DD. CP/M dagegen holt sich die Info über die Floppy-Geometrie aus einer Tabelle im BIOS. Da steht hardcoded drin was Dein Laufwerk für Eigenschaften hat. Wenn die Angabe in der DPT nicht zum real vorliegenden Format der Diskette passt, dann fehlen dem Dateisystem ein paar Sektoren oder liegen an der falschen Stelle. Im "CPM 2.0 System Alteration Guide" ist das irgendwo erklärt, und wie man die Tabelle an sein Laufwerk anzupassen hat. Zu Apple's Zeiten brauchte man für "große" Laufwerke zwei Einträge: einmal einen für 35 Tracks einseitig (das normale Apple-Format) und einmal einen für 80 Tracks doppelseitig. Wenn dann eine klassisch formatierte Diskette drinlag wurde die als Laufwerk A> angesprochen. Eine 80 Track-Diskette im selben Laufwerk war D>, weil dann eine andere Geometrietabelle galt. Eventuell hast Du ein ähnliches Problem. Dann liegen 720k und 1.44k auf verschiedenen Laufwerksbuchstaben. Oder es ist nur eine Tabelle vorhanden und das andere Format noch gar nicht angelegt. Da sich bei Dir neben der Geometrie auch die Datenrate unterscheidet muss das im BIOS auch entsprechend berücksichtigt sein. Vielleicht findest Du die Stelle im Quellcode, oder jemand anderes hat Zeit sich da mal durchzufräsen. Dann wäre zumindest klar welche Formate theoretisch funktionieren müssten und wie die angesprochen werden. BTW: wenn ich so über den Schaltplan schaue: der 8255A macht doch nur den Parallelport? Wenn der nicht läuft schmeiss ihn erstmal raus. Eigentlich hätte da auch ein Z80PIO reingehört, und statt dem 16550D mit seinem dekadenten FIFO eine Z80SIO, SCC oder DART ;-)
Hallo soul e: Du hast wohl recht und ich auch :-) Warum nicht gleich den "Chefentwickler" fragen... der dann auch das bestätigt, was ich vermutete und was Du sehr gut dargestellt hast: Hi Christian, Yes, I am pretty sure this is an issue in v2.9.1. I have not released the final version of 2.9.2 yet, but you can download the latest pre-release from GitHub at https://github.com/wwarthen/RomWBW/releases. I suggest you try this and see if it works. Thanks, Wayne On Mon, Mar 2, 2020 at 2:07 PM .... wrote: Dear Sir, I hope you can spend a minute for my problem: My Zeta V2 formats 1.44MB Floppys @ 8 Mhz. Formatting and Verify is ok. Trying to copy a file to the floppy I get the error in the picture: END OF CYLINDER. This error doesnt occur with 720kb floppys. Interleave tested fropm 2 to 6: Nothing changes. Any idea? Regards from Germany, Christian
soul e. schrieb: > Eigentlich hätte da auch ein Z80PIO reingehört, und statt dem 16550D mit > seinem dekadenten FIFO eine Z80SIO, SCC oder DART ;-) Ich frage mich auch warum sämtliche Z80 Designs nicht die Zilog Familie benutzen sondern Intel Chips. PIO, SIO, CTC das alles gibt es von Zilog aber keiner setzt es ein. Der 8255 war eigentlich aus der 8085 Reihe... Weisst Du eigentlich welches Basic open, print# und close Dateibefehle implementiert hat, so dass man was sinnvolles damit programmieren kann, was auf Diskette schreibt? Bei den mir bekannten Basic's sind die alle entfernt worden. Habe noch Basi.com und Basc.com gestern aufgespielt.
soul e. schrieb: > Bzgl 8255 Bei mir arbeitet ein OKI M82C55A-2 bei 10MHz ohne Probleme als IDE-Interface.
soul e. schrieb: > Oder es ist nur eine Tabelle > vorhanden und das andere Format noch gar nicht angelegt. Da sich bei Dir > neben der Geometrie auch die Datenrate unterscheidet muss das im BIOS > auch entsprechend berücksichtigt sein. @Georg.... Oh, auch wieder da? ;-) Mit schon erwähnt hat der Maintainer des Projektes Warthen geschrieben, dass dieses Problem bekannt sei und es deswegen auch Updates gebe. Im Pre Release 2.9.2 Beta wird von Floppy I/O gesprochen... werde mir das heute abend mal in den Brenner laden und flashen. Das Zeta Board kann sich angeblich auch selbst flashen aber soweit bin ich noch nicht. Interessant ist unter diesem Aspekt aber, dass es Youtube Videos gibt, wo das Formatieren und Bespielen einer 1.44Mb gezeigt und beschrieben wird. Obwohl es eigentlich gar nicht funktionieren dürfte. Dabei ist das Zeta Projekt schon seit 2011 bekannt und wurde 2015 beendet. Und erst 2020 fällt auf, dass die Floppy nicht spielt....
Bei meinen beiden Zetas (V2) mit 10MHz läuft die Floppy im 1,44MB Format problemlos. Eventuell passt ja was an deinen ICs nicht (hochgetaktete Fälschungen)? Gruß Jörg
:
Bearbeitet durch User
Joerg F. schrieb: > Eventuell passt ja was an deinen ICs nicht (hochgetaktete > Fälschungen)? Was soll ich dazu sagen? Das Thema hatte ich schon 2015 mal: Schön gelb bedruckte Z80 CPU's PSC006 aus der Bucht, wie neu. Schön zum angucken, denn es lief keine einzige bei 4 Mhz. Erst unter 2 Mhz taten sie es und der Verkäufer hat mich heute noch gesperrt, weil er nur Bahnhof verstand als ich die reklamierte. Ich solle Fotos schicken .... blablubb. Kann sein, der WDC ist auch so ein China Teilchen, für 15 Euronen .... Ja, kann sein... wer weiss das schon noch was noch echt ist und was geklont? Siehe NRF24L01+, da haben die Fakes die originale schon lange vom Markt verdrängt.
Und alles ward gut mit der Version 2.9.2 Beta ..... die jetzt auch noch ein Daddelspiel an Bord hat....
Leo? Bist Du noch da? Zum Thema Programmierung nachdem nun die "Bedienung" einigermaßen klappt. Eine Programmerstellung auf dem Minirechner scheidet aus. Die Editoren die ich dort ausprobiert habe sind einfach zu nervtötend gegenüber Notepad++ mit Syntax Färbung usw. Asm ist angedacht und wird wieder erlernt, da 25 Jahre nicht mehr benutzt. Dazu ist der Tasm wohl der richtige Crosscompiler. Nächste Frage ist der Test von Programmteilen... auf dem Minirechner oder lieber in einer CPM Umgebung auf dem PC? Floppy soll ja auch laufen. Der sdcc ist eigentlich mein Liebling aber für den habe ich keine Runtime Libs, was zb die Umleitung von fopen und fclose angeht, denn die Floppy und den VT100 Bildschirm will ich ja nutzen. Dazu muss CPM bedient werden, wie auch immer. Hochladen würden per Intel Hex gehen oder per Z-Modem. Mühsam aber machbar. Source Level Debugger wie beim ARM sind wohl Utopien denke ich mal....
Christian J. schrieb: > Source Level Debugger Irgendwo muss man den Fortschritt ja auch merken. Stichwort "SID" bze "ZSID". Ist etwas komfortabler als DDT.
Georg G. schrieb: > . Ist etwas komfortabler als DDT Ah ok... ich bin ja mal gespannt. Manual habe ich auch schon gefunden. Hoffe mal, dass toppt die uVIsion IDE noch :-) Schmerz beseite.... wie schreiben denn die Freaks den Code? zb für ROMWBW? Auf einem PC mit Emulator oder spielen die auch jeden Debuglauf in die Kiste rein, lassen laufen, testen erneut und wieder von vorne. Das lässt sich mit einem Shell Script ja leicht erledigen, dass man nicht so viel tippen muss.
Christian J. schrieb: > Der sdcc ist eigentlich mein Liebling aber für den habe ich keine > Runtime Libs Dafür gibt es z88dk. Auch zum Rest habe ich mich wiederholt geäußert. Und da ich zur Zeit unterwegs bin, und auf einem kaputten Händi tippen muss, bin ich auch schon wieder weg.
Georg G. schrieb: > Irgendwo muss man den Fortschritt ja auch merken. Stichwort "SID" bze > "ZSID". Ist etwas komfortabler als DDT. Ich empfehle ddt180 von meiner Homepage. Außerdem gibt es mindestens für hitech-C einen Source Level Debugger.
Leo C. schrieb: > Dafür gibt es z88dk. > Auch zum Rest habe ich mich wiederholt geäußert. Klappt schonmal .... sdcc eben :-) 18 0000 ; Function main flags 0x00000000 __stdc 19 0000 ; void main() 20 0000 ._main 21 0000 21 05 00 ld hl,5 ;const 22 0003 E5 push hl 23 0004 21 07 00 ld hl,7 ;const 24 0007 E5 push hl 25 0008 C5 push bc 26 0009 .i_2 27 0009 21 04 00 ld hl,4 ;const 28 000C CD 00 00 call l_gintspsp ; 29 000F 21 04 00 ld hl,4 ;const 30 0012 39 add hl,sp 31 0013 CD 00 00 call l_gint ; 32 0016 D1 pop de 33 0017 19 add hl,de 34 0018 C1 pop bc 35 0019 E5 push hl 36 001A 21 04 00 ld hl,4 ;const 37 001D 39 add hl,sp 38 001E 34 inc (hl) 39 001F 7E ld a,(hl) 40 0020 23 inc hl 41 0021 20 01 jr nz,ASMPC+3 42 0023 34 inc (hl) 43 0024 66 ld h,(hl) 44 0025 6F ld l,a 45 0026 D1 pop de 46 0027 E1 pop hl 47 0028 23 inc hl 48 0029 E5 push hl 49 002A D5 push de 50 002B 2B dec hl 51 002C C3 09 00 jp i_2 52 002F .i_3 53 002F C1 pop bc 54 0030 C1 pop bc 55 0031 C1 pop bc 56 0032 C9 ret
Mein Zeta SBC läuft prima mit einem Z80H von 1985 mit 10 Mhz (12 Mhz startet, ist aber nicht stabil). Habe ein Gotec mit FlashFloppy firmware als Diskettenlaufwerk dran, die Ramdisk muss ich noch initalisieren, macht noch Probleme mit CP/M 3, läuft ansonsten prima. Btw, ich habe noch 4 Platinen, wenn die jemand haben will, ich habe €20 für 5 bezahlt, für €4 + €4 Versand = €8 sende ich diese gerne weiter.
Armin D. schrieb: > Mein Zeta SBC läuft prima mit einem Z80H von 1985 mit 10 Mhz (12 Mhz > startet, ist aber nicht stabil). Ich habe jetzt auch auf CP/M testweise mein erste C Programm zur Berechnung vom Primzahlen laufen. Ist leider ununterbrechbar, weil Cntrl-C noch nicht erkannt wird und kbhit nicht richtig funktioniert. Und die Doku von z88dk so spartanisch ist, dass man es kaum nutzen kann. Ich versuche mir erstmal eine Testumgebung zu schaffen, ohne ständig die gleichen Befehle wieder und wieder eingeben zu müssen wenn ich Änderungen teste. era test.com xm r test.com xmodem -> Upload klick, klick, klick... Dafür schreibe ich mir derzeit erstmal ein Download.com und eine Batch Datei für den PC, die das etwas bequemer machen. Leider habe ich von Windows keine Ahnung, denn das Script unten was ich damals als "Fernbedienung" schrieb muss ich von Linux her nach Windows cmd Shell portieren. #!/bin/bash # =========================================================== # Programm zur Übertragung von Intel Hex Files an den Z80 # 7.2016 # =========================================================== echo "---------------------------------" echo "Datentransfer zum Z80" echo "---------------------------------" echo "Stelle tty/USB0 auf 38400 baud ein....." stty 38400 raw -ixon -ixoff -parenb -crtscts -F /dev/ttyUSB0 echo "Sende "load" Startsequenz...." echo -n -e "load\r" > /dev/ttyUSB0 sleep 1 echo "Uebertrage Daten...." cat build/z80ram.ihx > /dev/ttyUSB0 echo -n -e "\r" > /dev/ttyUSB0 #echo -n -e "run\r" > /dev/ttyUSB0
Moin, hat da vielleicht schonmal jemand mit dem z88dk Kit gearbeitet? Was mir irgendwie fehlt ist der Überbau für CP/M 2.x. Kleine C Programme funktionieren problemlos, die werden auch richtig gelinkt auf die passenden Zieladressen. Aber was mir fehlt sind Header oder Libraries, also eine API, die mir auch das HBIOS und das BDOS öffnet, denn da sind ja eine Menge Funktionen drin, die meinen Winzling steuern. An die Timer des CTC will ich ja auch ran und die liegen auf I/O Port Adressen. Sowas wie include "bdos.h" include "hbios.h" Ich habe es noch nicht ausprobiert aber ich vermute, dass auch File Objekte richtig übersetzt werden, damit ich aus heraus Dateioperationen machen kann. Das würde ja voraussetzen, dass das z88dk kit die Funktionen des BDOS nutzt. Derzeit schreibe ich mir ein Download Programm, damit das Testen endlich fixier geht ohne die Tipperei, um die Intel Hex Ausgabe direkt in ein COM File zu wandeln und es zu starten. Ein einfaches make File für den ZSDCC muss auch noch her, davon habe ich leider gar keine Ahnung. Ganz einfach, nur mehrere Dateien kompilieren und alle zusammen linken. dannn wäre meine Entwicklungsumgebung fertig und ich könnte dran gehen dem Kerlchen was Sinnvolles beizubringen. Freue mich schon drauf :-)
Christian J. schrieb: > Aber was mir fehlt sind Header oder Libraries, also eine API, > die mir auch das HBIOS und das BDOS öffnet, denn da sind > ja eine Menge Funktionen drin, die meinen Winzling steuern. Die CP/M-API ist so klein, dass du dir die Libs auch "mal eben so" schreiben kannst. Da gibt's tatsächlich nicht viel. Und die Systeme haben so wenig RAM, dass man auf Convenience verzichten muss, d.h. man schreibt sich kleine, angepasste Funktionen statt großer, generischer Funktionen.
Gefunden habe ich das hier, siehe Anhang. Basiert alles auf dem Laden von Registern samt Aufruf des Soft Ints mit RST. Viel ist das nicht.... Ich bastel mir erstmal ESC Funktionen, damit ich mit dem Cursor rumflitzen kann. Hoffe mal dass die Standard VT100 Codes auch passen. Nicht alle aber die wichtigsten. http://ascii-table.com/ansi-escape-sequences-vt-100.php
Hallo Leute ! Bei Tindie.com wird ein System gehandelt welches ich für besser als das Zeta halte. Das System heisst SC126 und gibt es als Bausatz und für sehr kleines Geld als unbestückte Platine. Hier mal einige Daten: Z80180 mit 18.432mhz Quarz 512K RAM 2 512K Flashes (über Jumper auswählbar) RTC 2*Seriell (TTL) 2*SPI für SD-Karte 1*I2C 8*LED RC2014 Bus. Ich betreibe das ganze mit RC2014 CF-Karten Interface und einer SD-Karte. An den RC2014 Bus habe ich eine VG für einen ECB Floppycontroller gefrickelt. Einfach mal ansehen......
hbl999 schrieb: > Bei Tindie.com wird ein System gehandelt welches ich für besser > als das Zeta halte. Habe auch was gefunden bei Aliexpress.... mit Debug Stecker. 10-fache Taktrate des Z80, mehr Speicher, mehr Peripherie, Source Level Debugging, 32 Bit Timer, 2 UARTS, SPI usw. und das alles für 1,79 Euro statt wie 150 Euro für das Z80 Board. Kommt also nur drauf an, wie man "besser" definiert.... sic!
Hallo, habe das Zeta Board in der Version 2 ausgebaut, starten tut das Board, aber danach passiert nichts mehr. Ich kann alle Tasten drücken, nichts. Hat kjemand von euch einen Tip? Danke Gruß Stefan
Stefan F. schrieb: > Ich kann alle Tasten drücken, nichts. > Hat kjemand von euch einen Tip? Naja, meines hat der Leo zum Laufen gebracht... hatte da auch Probleme. Zunächst mal müssen alle Schipse 8 Mhz vertragen können, wenn Du die 1.4MB Floppy auswählst. Und dann natürlich die Sache mit den Lötstellen denn die sind ja nunmal echt winzig. Dann sollte es klappen. Habe darauf einige Apps geschrieben mit zk88 Compiler, der bringt gleich COM Programme raus.
PS: Und Du musste das ROMWBW neu kompilieren ohne die Propeller Platine! Sonst startet der nicht. Da gibt es ein Konfig File wo man eine 0 reinschreiben muss... frag mich aber nicht mehr wie das heisst. Das Ding liegt seit über einem Jahr im Schrank, weil da irgendwie die Anwendung fehlt. Man hat 3 Laufwerke, eines im RAM, eine Floppy und eines im ROM. Damit kann man schon prima spielen. Habe da mal was zu gemacht: https://www.youtube.com/watch?v=PCjD2PE38fs
Hallo Christian, danke für die schnelle Antwort. Das RomWBW habe ich natürlich neu compiliert und das ParPortPro mit FALSE in der Config als nicht vorhanden eingestellt. Das System funktioniert auch ohne Floppy, meine Z80 läuft mit 6Mhz. Wenn da irgendwo eine nicht gute Lötstelle wäre, würde doch gar nicht das Board funktionieren. Gruß Stefan
Stefan F. schrieb: > Das System funktioniert auch ohne Floppy, meine Z80 läuft mit 6Mhz. > Wenn da irgendwo eine nicht gute Lötstelle wäre, würde doch gar nicht > das Board funktionieren. Naja, mit Floppy fand ich es irgendwie "mehr Retro", mit 720kb Disketten, sofern man sie noch kriegt geht das auch mit 6 Mhz. Außerdem, eine Fehlerbeschreibung ist das nicht, was Du da gemacht hast. Ich habe das alles unter einem Video Mikroskop verlötet. Die Widerstände müssen stimmen, also Stern Netzwerk. Lies dir auch mal durch, was hier oben steht. Ich hatte zb 2 defekte Floppy Controller Chips. Widerstand vergessen usw. Du musst natürlich einen VT100 komp. Monitor haben, also eine minicom Terminalanwendung. Die muss entsprechend auch eingestellt werden, also bidirektional. Die Baudrate liegt bei 38400 bei mir. Was ich noch vergessen habe ist, dass Du einen speziellen Adapter brauchst, den ich auch kaufen musste. Und ein verdrehtes Null Modem Kabel. Guck dir mal meine Videos dazu an, das zweite glaube ich: Teil 2: https://www.youtube.com/watch?v=HcE7Ad6KD4U teil3: https://www.youtube.com/watch?v=aTZBoD9yntM
Habe die Platine auch unter einer Lupe gelötet, jeden Widerstand vor dem EInbau mit einem Multimeter durchgemessen, das andere habe ich ja, ansonsten würde ich ja keine Meldung auf dem Bildschirm von meinem Notebook bekommen. Ich kann weder M für Monitor oder C für CP/M ..... auswählen, ab hier geht das System nicht mehr. Gruß Stefan
Hi, wenn alle Stricke reissen kann ich dir meinen Kram mal im Paket zusenden mit allem drum und dran. Das spielt aus der Dose heraus. Netzteil, alles dabei. Und Du kannst vergleichen. Falls Interesse bitte an PN melden. Oder meine email aus der Info Box des YT Kanals holen. Software dafür kannste mit z88dk schreiben als C-Code auf dem Rechner. Und dann per Z-Modem hochladen. Die eingebauten Basics erlauben leider nicht wirklich Programme zu speichern. Das habe ich dem Warthen auch geschrieben. Echte CP/M Tools zur Software Entwicklung auf dem Rechner selbst sind nach heutigen Massstäben dazu geeignet die Plätze in der Klapse zu füllen. Übrigens sollte beim taste drücken eine LED leuchten auf dem Adapter... Gruss, Christian
Stefan F. schrieb: > habe das Zeta Board in der Version 2 ausgebaut, starten tut das Board, > aber danach passiert nichts mehr. Ich kann alle Tasten drücken, nichts. > Hat kjemand von euch einen Tip? Teste mal dein Kabel. Also vom Zeta abziehen, Rx/Tx verbinden und schauen, ob du auf deinem Computer ein Echo bekommst. Das muss funktionieren, sonst sind entweder Kabel oder serielle Schnittstelle an deinem Terminal kaputt. Als nächstes prüfe die Lötstellen um den 16C550 und den DB9-Anschluss herum und löte notfalls einmal alles kurz nach. Da du die Ausgaben siehst, ist ein Großteil des Boards funktionsfähig. Schlimmstenfalls ist dein 16C550 kaputt, den könntest du testweise ersetzen (alle 16550, 16450 oder 8250 im DIP40 sollten passen). christian.julius@gmx.de schrieb: > Naja, meines hat der Leo zum Laufen gebracht... hatte da auch > Probleme. Zunächst mal müssen alle Schipse 8 Mhz vertragen können, > wenn Du die 1.4MB Floppy auswählst. Richtig, aber booten tut das Teil auch ohne Floppy-Controller. > Dann sollte es klappen. Habe darauf einige Apps geschrieben > mit zk88 Compiler, der bringt gleich COM Programme raus. Du meinst z88dk und das setzt natürlich voraus, dass die Platine überhaupt bootet. Mit sdcc geht es aber auch; ich habe bisher nur Assembler geschrieben. Christian J. schrieb: > PS: Und Du musste das ROMWBW neu kompilieren ohne die Propeller > Platine! > Sonst startet der nicht. Das ist schlicht falsch. Wenn ROMWBW für ParPortProp konfiguriert ist, aber keins angeschlossen ist, dann dauert es ungefähr eine Sekunde länger, bis das Menü erscheint. Christian J. schrieb: > Software dafür kannste mit z88dk schreiben als C-Code auf dem Rechner. > Und dann per Z-Modem hochladen. Kannst du mir bitte erklären, wie man das mit Z-Modem macht? Bei X-Modem weiß ich, wie das geht (XM.COM ist ja im Flash), aber wie hast du das mit Z-Modem geschafft? > Die eingebauten Basics erlauben leider > nicht wirklich Programme zu speichern. Das MBASIC.COM kann Programme speichern, einfach mit "SAVE TEST.BAS" und "LOAD TEST.BAS". Wichtig ist nur, dass man die Dateinamen in Großbuchstaben angibt (MBASIC erzeugt sonst ungültige Einträge, aber die kann man mit "KILL TEST.BAS" auch wieder löschen). > Übrigens sollte beim taste drücken eine LED leuchten auf dem Adapter... Welchem Adapter?
Ich markiere den Thread jetzt so dass keine Benachrichtungen mehr kommen. Angebot steht, ansonsten bin ich aus dem Thema auch heraus, da ich diesem ganzen "Vintage Zeugs" mit Z80 und Co. schon lange den Rücken gekehrt habe. Praktischer Nutzwert ist gleich Null, es sei denn jemand will allen Ernstes auf einer prähistorischen Umgebung Programme schreiben. Da war selbst "edlin" von DOS3.0 noch Luxus gegen.
Spielt noch prima, der Trümmer :-) @S.R. Ich meinte X-Modem aus minicom heraus. Zu lange her alles... die Soft im Flash kann man sich übrigens selbst zusammen stellen und rein kompilieren. Einfach die CMP Programme die rein sollen in ein Verzeichnis. Das wird dann gespiegelt ins Flash. @Stephan: Läuft er inzwischen? Ich habe Probs mit 1.4MB Floppys. Beim Verify nach Format spuckt er zu viele defekte Sektoren aus. Und eine 720kb Floppy war schwer zu bekommen aber mit der geht es prima. Sämtliche ca 100 Stück 1.4MB Floppy's von 1995-1998 die ich noch hatte waren übrigens platt. Nicht mal mehr mit USB Laufwerk am PC noch formatierbar. Ich werde mir noch ein .COM schreiben, was mir Intel Hex vom z88dk Compiler übersetzt in eine Datei. Das geht alles fixer als mit X-Modem.
Nabend, habe die Platine nochmal aufgebaut und gleicher Fehler. Die Einschaltmeldung kommt, aber dann ist wieder schluss. Kein Booten von CP/M, Monitor.... Habe es auch mal an einem alten Notebook angeschlossen, mit Windows 7 und Nullmodemkabel, der selbe Fehler. Ich denek der 16550 wird defekt sein. Habe mir mal einen neuen bestellt, mal ob ich dann mehr Glück habe. Vielen Dank an Alle die sich zu meinem Problem gemeldet hatten. Gruß Stefan
Christian J. schrieb: > Ich habe Probs mit 1.4MB Floppys. Beim Verify nach Format spuckt > er zu viele defekte Sektoren aus. Und eine 720kb Floppy war schwer > zu bekommen aber mit der geht es prima. Ich habe einen Zeta mit 4 MHz und benutze normale HD-Disketten in einem HD-Laufwerk, aber mit abgeklebtem HD-Loch als 720 KB. Funktioniert auch prima. Probleme mit DD- und HD-Unterschieden gibt es vor allem bei 5.25"-Laufwerken, die von uns keiner an den Zeta anschließt - und vielleicht bei DD-Laufwerken, die sowieso keiner hat. > Sämtliche ca 100 Stück 1.4MB Floppy's von 1995-1998 die ich > noch hatte waren übrigens platt. Klingt entweder nach schlechter Lagerung oder einem kaputten/verschmutzten Laufwerk. Der Zeta formatiert sowas problemlos (ob sie danach allerdings formatiert sind, hängt von Laufwerk und Medium ab). > Nicht mal mehr mit USB Laufwerk am PC noch formatierbar. USB-Laufwerke gehören nicht zu den zuverlässigsten Diskettenlaufwerken. Kann auch sein, dass dieses Laufwerk deine Disketten kaputtgemacht hat - so ging es mir. > Ich werde mir noch ein .COM schreiben, was mir Intel Hex vom z88dk > Compiler übersetzt in eine Datei. Das geht alles fixer als mit X-Modem. Das müsste PIP können (habe ich aber spontan nicht getestet):
1 | A>B:PIP TEST.COM=CON:[H] |
2 | (Hex-Datei reinkopieren, dann STRG+Z) |
Das H steht für eine Hex-Datei; I steht für eine Hex-Datei, aber 00h-Records werden ignoriert. Ansonsten kannst geht folgendes:
1 | A>B:PIP TEST.HEX=CON: |
2 | (Hex-Datei reinkopieren, dann STRG+Z) |
3 | A>LOAD TEST |
4 | A>SAVE 16 TEST.COM |
Setzt aber voraus, dass die Hex-Datei ab Adresse 0100h beginnt (für COM-Dateien ist das immer der Fall).
Stefan F. schrieb: > habe die Platine nochmal aufgebaut und gleicher Fehler Hast du die Löstellen nachgemessen? Die Signale angeschaut, ob sie am 16550 auch ankommen? Das Kabel am Notebook getestet (per Echo)? Irgendwas verändert?
S. R. schrieb: > Ich habe einen Zeta mit 4 MHz und benutze normale HD-Disketten in einem > HD-Laufwerk, aber mit abgeklebtem HD-Loch als 720 KB. Funktioniert auch > prima. Das kann funktionieren, da die Koerzitivfeldstärken bei 3,5" relativ nahe beieinanderliegen. DD 600 Oe, HD 720 Oe. Bei 5,25" sind es 300 Oe für SD/DD gegenüber 600 Oe für HD. (in A/m umrechnen müsst Ihr selber, bei Magnetbändern wurden diese historischen Einheiten bevorzugt)
Soul E. schrieb: > Das kann funktionieren, da die Koerzitivfeldstärken bei 3,5" relativ > nahe beieinanderliegen. DD 600 Oe, HD 720 Oe. Das funktioniert sogar sehr gut. Ich habe so gut wie keine DD-Disketten, brauche aber hin und wieder welche. > Bei 5,25" sind es 300 Oe für SD/DD gegenüber 600 Oe für HD. Richtig. Außerdem sind bei 5.25" die Spuren bei DD einerseits doppelt so breit wie bei HD, andererseits sind DD-Laufwerke recht verbreitet. Und dann geht es bei Retro-Spielereien auch nicht um ewige Datensicherheit. Mir reicht es fast immer, wenn die Diskette die Daten ein paar Stunden oder Tage hält.
S. R. schrieb: > Und dann geht es bei Retro-Spielereien auch nicht um ewige > Datensicherheit. Mir reicht es fast immer, wenn die Diskette die Daten > ein paar Stunden oder Tage hält. Und genau das ist der Punkt. "Retro Spielereien". Klar, man fühlt sich wie 1986 im Informatik Kurs (Apple 2e), fehlt nur noch der Bernstein Monitor. Aber nach einer Weile hat es sich dann aus ausgespielt. Mit VT100 und nucurses als Treiber kann man vllt ein paar Spielchen mit Grafik Kötzchen erstellen. Und mancher kriegt vielleicht einen Retro-Flash wenn er die Floppy sägen hört. Ich habe ein C-Programm geschrieben, was die sog. Doppelwürfel-Verschlüsselung durchführt, die die Geheimdienste damals und auch heute noch verwenden bei ihren Zahlensendern. Und ein 40x80 "Game of Life" mit ncurses. Das passt dann ja auch noch in die Zeit. Aber sonst... tja,.... dsas Nächste wäre dann ein 68000er, weil die IC's so schön gross sind? Wie isset jetzt, Stefan? Haben oder nicht? Kannste ja die Chips einzeln runternehmen und austesten. Meiner läuft, gestern noch mit gespielt.
Christian J. schrieb: > > Bisher habe ich "free-standing" mit SDCC gemacht für meinen Z80 Bau von > 2015. Ohne OS dahinter aber eben leider auch ohne jede Peripherie wie > Floppy usw. usw. Kein Int21 Interrups, kein BIOS was mir hilft.... Wenn es ein moderneres OS sein darf: FUZIX ist ein (teils POSIX-kompatibles) freies Unix für Z80, das mit SDCC kompiliert wird. https://github.com/EtchedPixels/FUZIX
Philipp Klaus K. schrieb: > freies Unix für Z80, das mit SDCC kompiliert wird. Ich warte lieber bei der GCC mal den Z80 unterstützt. Keine Ahnung wieso das nicht gemacht wurde. Der SDCC ist schnarch langsam, wenn man die Anzahl "Nodes" auf eine vernünftige Zahl einstellt, hat keine Dead Code Elemination und keine LTO. Das erzeugt halt Bläh-Code. Kein Mensch bindet heute noch eigene Libs ein, sondern meist Sourcen. Und da wird eben jede Routine übersetzt, ganz egal ob sie gebraucht wird. Und printf"Hello world! 10x im Quelltext wird auch 10x im Binfile angelegt, weil keine LTO. Will ihn aber auch nicht zu schlecht machen, da ich schon viel Code damit geschrieben habe, ein eigenes kleines Betriebssystem sogar mit Command Shell. Was mich so wundert ist, dass kein einziges Z80 System die hauseigenen Zilog Bausteine verwendet, die doch extra dafür geschaffen wurden. Der 8255 ist ja von Intel glaube ich, gibt es aber auch von Zilog. Z80 SIO, Z80 DMA usw.
Christian J. schrieb: > Philipp Klaus K. schrieb: >> freies Unix für Z80, das mit SDCC kompiliert wird. > > Ich warte lieber bei der GCC mal den Z80 unterstützt. Keine Ahnung wieso > das nicht gemacht wurde. > > Der SDCC ist schnarch langsam, wenn man die Anzahl "Nodes" auf eine > vernünftige Zahl einstellt, […] Der GCC verwendet einen graphfärbenden Registerallokator nach Chaitin (siehe Chaitin et al., "Register allocation via coloring", 1981 sowie Chaitin, "Register allocation & spilling via graph coloring", 1982). Der ist nicht langsam (wenn auch oft nicht schnell genug für Just-In-Time Compilation), und erlaubt es, guten Code für Architekturen mit vielen gleichartigen Registern zu erzeugen. Aber mit irregulären Architekturen mit wenigen Registern, wie Z80 oder STM8 kommt er nicht gut zurecht. Der SDCC verwendet einen anderen Registerallokator (siehe Krause, "Optimal Register Allocation in Polynomial Time", 2013), der auch mit irregulären Architekturen wie dem Z80 gut zurecht kommt, aber deutlich langsamer als Chaitin ist. Es gibt noch einen weiteren Ansatz (siehe Castañeda Lozano, "Constraint-Based Register Allocation and Instruction Scheduling", 2012), der mir für Z80 brauchbar erscheint, aber auch der ist deutlich langsamer als Chaitin. Es ist mein Registerallokator, der bei hohem Wert für "--max-allocs-per-node" SDCC langsam macht. Im Prinzip gibt es noch etwas Potential für Geschwindigkeitsverbesserungen. Insbesondere: * Eine verbesserte theoretische Schranke. Mein Algorithmus ist in XP, ich habe auch ein W[SAT]-Schwere-Resultat, aber zwischen W[SAT] und XP ist eine Lücke, die es ermöglichen könnte eine Faktor in der Laufzeit von |V|^(2tw(G)+1)r) auf |V|^sqrt(tw(G)r) zu drücken. Dabei ist r die Anzahl der Register (9 für SDCC mit Z80, tw(G) die Baumweite des Kontrollflussgraphen (bei C meist 3 oder 4), V die Menge der lokalen Variablen. * Eine parallelisierte Implementierung. Bisher verwendet SDCC nur einen Thread, aber der Registerallokator wäre eigentlich gut parallelisierbar. * Eine optimierte Implementierung des Registerallokators. Hier wurde zwar schon einiger Aufwand in die Wahl der Datenstrukturen, etc gesteckt, aber es könnte durchaus weiteres Potential geben (insbesondere weitere Optimierung der Datenstrukturen für Cache-freundliches Layout, weniger Speicherallokation und -deallokation). * Eine Wahl der Baumzerlegung, die einige Eigenheiten des Registerallokators besser berücksichtigt könnte den Speicherbedarf des Allokators reduzieren, und somit den Cache besser nutzen. Da gab es zwar bereits Fortschritte (siehe Krause, Larisch, Salfelder, "The tree-width of C", 2020), aber ich sehe noch weiteres Potential.
Philipp Klaus K. schrieb: > Der SDCC verwendet einen anderen Registerallokator (siehe Krause, > "Optimal Register Allocation in Polynomial Time", 2013), der auch mit > irregulären Architekturen wie dem Z80 gut zurecht kommt, Ach Du bist der SDCC Papst.... ich verstehe da leider nur Bahnhof von :-( Compiler sind recht komplizierte Stück Software wo viele ihren Doktor drauf gedrückt haben. >>* Eine verbesserte theoretische Schranke. Mein Algorithmus ist in XP, >>ich habe auch ein W[SAT]-Schwere-Resultat, aber zwischen W[SAT] und XP >>ist eine Lücke, die es ermöglichen könnte eine Faktor in der Laufzeit >>von |V|^(2tw(G)+1)r) auf |V|^sqrt(tw(G)r) zu drücken. Ok... alles klar.. nix verstehen... Ich werde mir mal die neue Beta die Tage drauf holen und den kompilieren auf meiner Linux Kiste. Lange nichts mehr mit gemacht und es war auch nicht so ganz einfach diese crt0 Datei zu erzeugen für meine eigene Z80 Kiste. Glaube ein A.K. war hier ziemlich gut drin.
Christian J. schrieb: > Was mich so wundert ist, dass kein einziges Z80 System die hauseigenen > Zilog Bausteine verwendet, die doch extra dafür geschaffen wurden. Was wäre denn der Vorteil der Zilog-Bausteine?
Christian J. schrieb: > Philipp Klaus K. schrieb: >> freies Unix für Z80, das mit SDCC kompiliert wird. > > Ich warte lieber bei der GCC mal den Z80 unterstützt. Keine Ahnung wieso > das nicht gemacht wurde. > >[…], hat keine Dead Code Elemination und keine > LTO. Das erzeugt halt Bläh-Code. Kein Mensch bindet heute noch eigene > Libs ein, sondern meist Sourcen. Und da wird eben jede Routine > übersetzt, ganz egal ob sie gebraucht wird. […] Dead-Code-Elimination ist ein sehr allgemeiner Begriff, der vieles umfasst, sowohl Optimierungen, die SDCC vornimmt, als auch manche, die SDCC nicht vornimmt. Dir geht es darum, dass nicht genutzte C Funktionen nicht in die Binärdatei gelinkt werden, selbst wenn diese C Funktionen einfach so zusammen mit genutzten in der gleichen Übersetzungseinheit stehen. Eine Art von Dead-Code-Elimination zur Linkzeit. Dies können die in SDCC enthaltenen, auf asxxxx basierenden Linker nicht. Der aussichtsreichste Weg, diese Optimierung zu ermöglichen, dürfte sein, in SDCC die Unterstützung der GNU binutils als Assembler und Linker zu verbessern. Man würde also mit SDCC kompilieren, und mit GNU binutils assemblieren und linken.
Nachdem wir das Originalthema jetzt sowieso verlassen haben... Philipp Klaus K. schrieb: > Dies können die in SDCC > enthaltenen, auf asxxxx basierenden Linker nicht. Die SDCC-Toolchain fühlt sich für mich immer seltsam antiquiert an, weil alles außer dem Compiler anders funktioniert als gewohnt. Das fängt schon damit an, dass es keine einzelne Objektdatei wie bei gcc oder cc65 gibt. Philipp Klaus K. schrieb: > Der aussichtsreichste Weg, diese Optimierung zu ermöglichen, dürfte > sein, in SDCC die Unterstützung der GNU binutils als Assembler und > Linker zu verbessern. Das wäre eine super Sache. Existiert da was? Als ich das letzte Mal geschaut hatte, gab es zumindest kein Z80-ELF. Was mich noch interessieren würde, wäre Codegenerierung für i80. Da sieht es mit C-Compilern ziemlich traurig aus (eigentlich gibt es nur ACK und ein paar CP/M-Dinge). Woran scheitert das?
Philipp Klaus K. schrieb: > Dies können die in SDCC > enthaltenen, auf asxxxx basierenden Linker nicht. Naaaa... sicherlich kann es nicht so schwer sein zu erkennen ob eine Routine verwendet wird oder nicht. Wie sieht es denn heute aus? Arduino, das meist verwendete Bastelsystem der Welt: Man bindet eine Lib ein und nimmt daraus was man braucht, vielleicht erbt sie auch noch was. Würde die Lib aber komplett ins Binary übernommen würde wohl kein Code mehr in den Chip passen. Ich weiss nicht wie ein Compiler funktioniert aber er erzeugt doch sicher ein Aufrufdiagramm intern. Die echten "Libs", also .lib nutzt doch heute niemand mehr, ich habe nicht eine einzige in meinem Leben erzeugen müssen und befasse mich seit 1988 mit uC's, seit 1996 mit C-Compilern. Ich habe mit Z80 eine Eingabemaske erstellt, mit ncurses von Frank M. Darin sind auch alle Vt100 Steuercodes für den Cursor und einiges mehr. Ich nutze aber nur wenig draus, trotzdem erzeugt mir SDCC Binary Code für alles was drin steht. Das ist für den winzigen Speicher solcher Systeme einfach zu viel. Wikipedia: "Seit Mitte der 1990er Jahre ist es Stand der Technik, dass Compiler und Linker unbenutzte Codeabschnitte erkennen und entfernen. Diese Optimierungstechnik bezeichnet man als dead code elimination. Seit Mitte der 2010er Jahre haben äquivalente Techniken in IDEs (Anzeige von unbenutzten Code schon beim Editieren) und in Debugger (Code, der im aktuellen Durchlauf nicht mehr erreicht werden kann, wird beispielsweise abgedunkelt) Einzug gehalten."
Christian J. schrieb: > Ich frage mich auch warum sämtliche Z80 Designs nicht die Zilog Familie > benutzen sondern Intel Chips. Weil Du zu wenige Z80-Designs kennst. > PIO, SIO, CTC das alles gibt es von Zilog > aber keiner setzt es ein. Oh doch, schau dir mal die Rechner aus dem Ostblock an: U855, U856 und U857 zu hauf. Nur der U858 (DMA) wurde seltener verbaut.
Hallo zusammen, wie gesagt, habe die Platine Zeta Version 2 nochmal aufgebaut und wieder der gleiche Fehler, ich kann nichts starten, weder Monitor, CP/M, BASIC. Habe das ParPortProp auch aufgebaut, Montitor angeschlossen und zeigt das die Hardware vom ParPortProp OK ist. Aber auch hier geht es nicht weiter, bleibt einfach stehen. Habe schon alle Lötstellen nachgelötet aber auch ohne Erfolg. Muss man in der Software noch was anderes einstellen? Danke für irgendein Tipp von euch. Gruß Stefan F.
Christian J. schrieb: > > Naaaa... sicherlich kann es nicht so schwer sein zu erkennen ob eine > Routine verwendet wird oder nicht. Wie sieht es denn heute aus? Arduino, > das meist verwendete Bastelsystem der Welt: Man bindet eine Lib ein und > nimmt daraus was man braucht, vielleicht erbt sie auch noch was. Würde > die Lib aber komplett ins Binary übernommen würde wohl kein Code mehr in > den Chip passen. Ich weiss nicht wie ein Compiler funktioniert aber er > erzeugt doch sicher ein Aufrufdiagramm intern. > > Die echten "Libs", also .lib nutzt doch heute niemand mehr, ich habe > nicht eine einzige in meinem Leben erzeugen müssen und befasse mich seit > 1988 mit uC's, seit 1996 mit C-Compilern. > SDCC wird, wie bei vielen FOSS-Projekten üblich, durch wenige Freiwillige entwickelt. Die machen eben das, was sie interessiert. GCC und LLVM haben dagegen viele Entwickler, darunter auch bezahlte Vollzeitkräfte. Zum asxxxx-Fork in SDCC: Es ist unter den SDCC-Entwicklern Konsens, dass die aktuelle Situation nicht optimal ist. Die Assembler und Linker in SDCC basieren auf einer sehr alten Version von asxxxx. asxxxx und der SDCC-Fork haben sich über lange Zeit auseinanderentwickelt (es gab eine Zeit, in der asxxxx eine GPL-inkompatible Lizenz hatte). Es wäre nun erheblicher Aufwand, den SDCC-Fork mit einem aktuellen asxxxx zusammenzuführen. Eine Alternative könnten Assembler und Linker aus GNU binutils sein (die aber bisher nicht für alle von SDCC unterstützten Architekturen verfügbar sind). Wenn jemand diese Dead-Code-Elimination mit dem asxxxx-Fork in SDCC implementieren will, und einen Patch schreibt, könnte man das natürlich übernehmen, und müsste nicht auf die große Lösung zu Assembler / Linker warten. Vermutlich wäre der Aufwand tatsächlich nicht so groß (man könnte eventuell auf der Dead-Code-Elimination, wie sie f+r .lib funktioniert, aufbauen). Dabei müsste natürlich berücksichtigt werden, dass der potentiell zu Eliminierende Code nur als soclher betrachtet werden darf, wenn er entsprechend markiert ist (was der Compiler machen würde). Man will ja nicht, dass der Linker etwas herausoptimiert, das aus C-Perspektive nicht benötigt wird, aber tatsächlich eine Bedeutung hat (z.B. Code, den das BIOS eines Systems an einer bestimmten Stelle erwartet). > > > Wikipedia: > "Seit Mitte der 1990er Jahre ist es Stand der Technik, dass Compiler und > Linker unbenutzte Codeabschnitte erkennen und entfernen. Diese > Optimierungstechnik bezeichnet man als dead code elimination. SDCC hat solche Optimierungen zur Compilezeit (für Teile von Funktionen), aber zur Linkzeit gibt es diese eben bisher nur, wenn .lib verwendet werden.
Stefan F. schrieb: > wie gesagt, habe die Platine Zeta Version 2 nochmal aufgebaut und wieder > der gleiche Fehler, ich kann nichts starten, weder Monitor, CP/M, BASIC. > Habe das ParPortProp auch aufgebaut, Montitor angeschlossen und zeigt > das die Hardware vom ParPortProp OK ist. Es tut mir leid aber hier wird dir niemand helfen können. Und die Platine nochmal aufzubauen ist ein teures Werk von vielen Stunden, da man sie ja nicht wieder entlöten kann und wegen der winzigen Pads alles genau kontrollieren muss. Solange du das TX Signal nicht verfolgst von seinem Ursprung (PC) bis zum Ziel (SIO) wirst du keinen Erfolg haben. Die Quarze müssen stimmen, die Baudrate ist 38400, 8N1, kein Flussprotokoll. Diese Daten müssen natürlich auch im Gerätemanager von Windows eingetragen werden. Es haben hunderte diese Platine aufgebaut und sie funktioniert einwandfrei. Ohne einen Oszillographen oder wenigstens Data Logger geht es natürlich nicht. Trotzdem hier mal mein Brand in das EEPROM ohne PartProp.
Philipp Klaus K. schrieb: > SDCC wird, wie bei vielen FOSS-Projekten üblich, durch wenige > Freiwillige entwickelt. Die machen eben das, was sie interessiert. GCC > und LLVM haben dagegen viele Entwickler, darunter auch bezahlte > Vollzeitkräfte. Philipp, kannst du mir in einfachen Worten erklären warum der GCC niemals Z80 Code konnte, obowohl das einer der am weitesten verbreiteten Neumann- CPU der Welt war? Und einen orthogonalen CISC Befehlssatz hat sie auch. Von dem meisten Zeugs da unten habe ich noch nie etwas gehört. Bekannt sind mir nur 68HC11,68000, AVR, Blackfin, DSP16, Intel, MicroBlaze als Softcore und die MSP's, sowie V850 aus meiner Zeit bei Renesas vor 20 Jahren. Motorola 68HC11 A29K Adapteva Epiphany Atmel AVR Blackfin C4x CRIS D30V DSP16xx FR-30 FR-V Intel i960 IP2000 M32R MCORE MicroBlaze MMIX MN10200, MN10300 NS32K ROMP Stormy16 Synopsis Designware ARC Texas Instruments MSP430, MSP432 V850 Xtensa
Christian J. schrieb: > Es tut mir leid aber hier wird dir niemand helfen können. Zumindest nicht ohne weitere Informationen. Ein "es geht nicht" hilft halt niemandem, der die Platine nicht sehen kann. > Und die Platine nochmal aufzubauen ist ein teures Werk von vielen > Stunden, da man sie ja nicht wieder entlöten kann und wegen der > winzigen Pads alles genau kontrollieren muss. Also ich habe jetzt insgesamt vier Platinen aufgebaut, mit leicht unterschiedlicher Bestückung und in ca. zwei Stunden pro Platine. (Alle Chips natürlich gesockelt. So kann man auch vor dem Bestücken die Spannungen testen.) Christian J. schrieb: > Philipp, kannst du mir in einfachen Worten erklären warum > der GCC niemals Z80 Code konnte, obowohl das einer der am > weitesten verbreiteten Neumann- CPU der Welt war? Weil nie jemand genug Geld und Zeit auf das Problem geworfen hat, um es zu lösen. Und weil die Architektur des Z80 weder zur Architektur des GCC passt, noch zur Programmiersprache C. > Und einen orthogonalen CISC Befehlssatz hat sie auch. Der Z80 ist das Gegenteil von orthogonal, nämlich CISC. Die meisten Befehle funktionieren nur mit A, aber im Gegensatz zu den anderen Registern kann A nicht sinnvoll gepaart werden (F ist kein normales Register). Adressierung auf dem Stack ist umständlich (wenn auch weniger grausam als bei i80), was sowohl bei lokalen Variablen als auch bei der ABI stört. Es gibt einen Grund, warum SDCC normalerweise keinen reentranten Code erzeugt, obwohl das in C so vorgeschrieben ist. Der GCC unterstützt effektiv nur Architekturen, die orthogonal genug sind und eine reguläre Registerstruktur anbieten können (z.B. AVR, Epiphany, ARM) - oder durch Verbreitung (x86) bzw. Geld (die ganzen DSPs) eingeklebt wurden. Die Details sind durchaus interessant, aber vermutlich interessiert dich das überhaupt nicht. Falls doch, hast du hier einen interessanten Vergleich aus aktueller Perspektive, wo jemand seinen Ansatz für 6502 und Z80 implementiert und vergleicht: http://cowlark.com/2018-02-27-6502-arithmetic/ http://cowlark.com/2018-03-18-z80-arithmetic/
S. R. schrieb: > Weil nie jemand genug Geld und Zeit auf das Problem geworfen hat, um es > zu lösen. Und weil die Architektur des Z80 weder zur Architektur des GCC > passt, noch zur Programmiersprache C Vermutlich ist das die Kernaussage. Der Z80 ist von gestern, ohne Frage. Ich sehr habe lange (viele Jahre als Entwickler) mit dem CCS für PIC gearbeitet. In dem Fall muss man einfach zufrieden sein mit dem was es gibt und der sdcc macht seine Arbeit schon sehr gut, wenn man gewisse Dinge berücksichtigt. Ich hätte mein Eigenbau Z80 Teil nie ans Laufen gekriegt, wenn es den nicht gäbe, da ich ca 1993 Asm an den Nagel gehängt habe für i386. Da floss mir Asm noch so aus dem Ärmel. Und grad schaue ich zu, wie mein Zeta2 Z80 Primzahlen berechnet... einfach schön die grünen Zeichen auf schwarzem Grund :-) Mit dem z80dk Kit ist das sowas von einfach!
S. R. schrieb: >> Und einen orthogonalen CISC Befehlssatz hat sie auch. > > Der Z80 ist das Gegenteil von orthogonal, nämlich CISC. Die meisten > Befehle funktionieren nur mit A, aber im Gegensatz zu den anderen > Registern kann A nicht sinnvoll gepaart werden (F ist kein normales > Register). Wobei die Nichtorthogonalität bei den 16-Bit-Befehlen noch ausgeprägter ist als bei 8 Bit. Da sind beim Z80 abgesehen von ix und iy keine zwei Register gleich: hl kann als 16-Bit-Akku für für Addition und Subtraktion verwendet werden, und relativ flexibel als Adressregister. Bei ix und iy geht das meiste davon auch, und zusätzlich noch indizierte Adressierung, aber Befehle, die ix oder iy verwenden sind länger und langsamer als solche, die hl verwenden. bc und de lassen sich auf hl, ix oder iy addieren, und sehr eingeschränkt als Adressregister verwenden (laden vom / ins 8_bit Register a, aber nicht andere 8-Bit-Register), aber sonst geht nicht so viel. de hat durch den Befehl ex de, hl eine Sonderrolle, da man damit effizient Daten zwischen hl und de übertragen kann. bc hat dagegen die Besonderheit, dass b mittels djnz besonders effizient als Schleifenzähler verwendet werden kann, während c sich zur Adressierung bei I/O eignet. Um effizienten Code für Z80 generieren zu können, muss der Registerallokator all diese Besonderheiten berücksichtigen können. Ein Registerallokator nach Chaitin, wie ihn GCC verwendet kann das nicht (dafür ist Chaitin aber recht schnell und eben eine gute Wahl für Architekturen, bei denen alle Register gleich sind, oder es zumindest von jeder Art von Register viele gibt).
> Und weil die Architektur des Z80 weder zur Architektur des GCC > passt, noch zur Programmiersprache C. > > […] > > Adressierung auf dem Stack ist umständlich (wenn auch weniger grausam > als bei i80), was sowohl bei lokalen Variablen als auch bei der ABI > stört. Es gibt einen Grund, warum SDCC normalerweise _keinen_ > reentranten Code erzeugt, obwohl das in C so vorgeschrieben ist. Ganz so schlimm ist der Z80 dann doch nicht. Der Stackzugriff ist ein bischen umständlich, aber immer noch besser als bei MCS-51 oder Padauk. SDCC erzeugt daher für Z80 per Default reentranten Code (anders als bei MCS-51 oder Padauk). Mit dem STM8 unterstützt SDCC übrigens auch eine Architektur die nichtorthogonal ist, aber sich dennoch gut für C eignet. Aber auch der STM8 ist noch nicht das Ende der nichtorthogonalen Fahnenstange. Man könnte durchaus nichtorthogonale Architekturen schaffen, für die SDCC nochmal deutlich kompakteren und schnelleren Code als für STM8 erzeugen könnte.
Hallo, so,eventuell habe ich den Fehler gefunden. Ich habe meinen USB nach RS232 Schnittstellenwandler in verdacht, das dieser mit den Pegel nicht zurecht kommt. Habe mal an den PINs vom MAX 232 PIN 9 und PIN 10 einen USB nach TTL Wandler angeschlossen und siehe da, es funktioniert auf einmal die Daten Kommunikation. Gruß Stefan
Stefan F. schrieb: > Ich habe meinen USB nach RS232 Schnittstellenwandler in verdacht, > das dieser mit den Pegel nicht zurecht kommt. Das ist eher unwahrscheinlich, es sei denn, du hast beim Einlöten den MAX202 kaputtgemacht. Du hast übrigens meine Frage noch immer nicht beantwortet, ob der "Echo-Test" mit dem Kabel (Wandler) funktioniert. :-)
Hallo, habe den Schaltplan mit den Layout der Platine verglichen, bei meiner Version stimmen nicht die Anschlüsse zur SUB-Stecker. Habe dann mal die Schaltung mit den MAX232 so aufgebaut wie im Schaltplan und angeschlossen an meiner Platine und siehe da es funktioniert. Gruß Stefan
Hat jemand noch ein paar von den FDCs (WD37C65, FDC37C65 oder GM82C765) für den ZETA V2 übrig und würde die gegen Porto und etwas Kleingeld abgeben? Wir haben in der Gruppe ein paar von denen gebaut, sind aber jetzt mehrmals mit der FDC-Beschaffung auf die Nase gefallen (defekt, gefälscht) und bräuchten so 3-4 Stück. Einen haben wir von einer ISA-Karte geerntet und damit getestet, aber hätten die anderen gerne bis Weihnachten auch funktional... Ich frage einfach mal hier im Thread, weil die Wahrscheinlichkeit höher ist, dass jemand mit den Chips das sieht. ;-)
S. R. schrieb: > für den ZETA V2 übrig und würde die gegen Porto und etwas Kleingeld > abgeben? Pfff.. ich hatte 3 Stück, alle waren defekt. Der eine wurde kochend heiss und verbrannte direkt, die anderen waren Fakes. Das dürfte fast unmöglich sein da noch dran zu kommen. Die Fakes laufengar nicht, direkt in die Tonne damit. Hier ist der Müll, den ich leider gekauft habe: https://www.ebay.de/itm/253826759926? das hier ist vllt NOS Ware aus Fernost. Goldstar baute mal Videorekorder. https://www.ebay.de/itm/392589617355?
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.