KAnn ich einen Z80 mit RAM und ROM und PIO genauso wie einen AVR nuzen?
Also kann ich den in C oder Pascal programmieren und das.bin File
einfach aufs EEprom packen, wie z.B. von Turbo Pascal erstellt wird,
oder geht das nur wenn Dos vorhanden ist?
Wenn Turbo Pascal einen Betriebssystemunabhängigen Code produzieren
kann, sollte das gehen. Oder der Z80 hat so ein OS wie CP/M an Board.
Der AVR hat ja im Normalfall auch kein Betriebssystem ala DOS als
Unterbau.
eben, deshalb dachte ich mir das es gehen sollte.
Aber die Frage ist halt ob der Produzierte code ein andere sin muss als
beim normalen <programmieren mit Dos.
Denn genutzt werden soll es ja wie gesagt wie ein µc..also Adressbuss
ansprechen um PIO Pins zu schalten etc..LED blinken etc.
In wieweit Turbo Pascal für Z80 das kann weiß ich nicht.
C sollte in der Lage sein, vom Linker her etc., Code zu produzieren der
direkt läuft. Einsprungpunkt vom Prozessor bei Reset muss dann
berücksichtigt werden.
also, wenn es C kann, sollte es dann nicht auch jedes Pascal/BAsic
könnnen?
Denn es geht ja eher um die Frage..wie ist das z.B. mit der RAM
verwaltung?
Wenn man z.B. nut 16KB ansteckt..alsow as die CPU direkt verwalten
kann..funktioniert das dann einfach so..oder ist die Aufgabe eines
Betriebssystems auch diesen Speicher verwalten.
Da Betriebssysteme sowohl in C als auch in Pascal geschrieben wurde,
sollte es ja grundsätzlich gehen
Toni schrieb:> Da Betriebssysteme sowohl in C als auch in Pascal geschrieben wurde,> sollte es ja grundsätzlich gehen
Es scheint sogar einen Crosscompiler für Pascal zu geben:
http://www.z80.info/z80sdt.htm
Aber egal welche Sprache verwendet wir, es muss dafür erstmal eine
Compiler/Linker geben der auch den Assembler/Binärcode für den uralten
Z80 erzeugen kann.
Zu Zeiten wo der noch recht neu war habe ich den eigentlich immer nur
mit Assembler gefüttert. Hochsprachen waren damals noch nicht so
wirklich verbreitet.
Toni schrieb:> KAnn ich einen Z80 mit RAM und ROM und PIO genauso wie einen AVR nuzen?
Man kann das. Ob du das kannst ... weiß ich nicht. Angesichts deiner
Fragen bezweifle ich das mal. Und es ist natürlich nicht ganz genau
so.
> Also kann ich den in C oder Pascal programmieren und das.bin File> einfach aufs EEprom packen, wie z.B. von Turbo Pascal erstellt wird,> oder geht das nur wenn Dos vorhanden ist?
Es gibt kein DOS für Z80. Ein verbreitetes Betriebssystem war CP/M. Aber
selbstverständlich geht es auch ohne ein Betriebssystem. Das absolute
Minimum an Software ist eine Art Loader, der das Programm über
irgendeine Schnittstelle (RS-232?) in den RAM bzw. Flash/EEPROM (so
vorhanden) lädt und startet. Der sollte dann praktischerweise im ROM
liegen. Klassisch nannte man so ein Programm "Monitor" und es hatte auch
Funktionen wie Speichertest, einen Editor für Speicherinhalte,
Registeranzeige und die Funktion, ein Programm im Speicher anzuspringen.
So ein Monitor braucht natürlich Ein/Ausgabemöglichkeiten. Eine RS-232
Schnittstelle reicht dafür ja schon.
Alternativ kannst du dein Programm auch extern auf einen (E)EPROM
brennen und den dann auf dein Prozessorboard stecken. Das ist dann aber
sehr viel mühsamer als ein AVR mit integrierten Flash und
ISP-Schnittstelle.
Außerdem brauchst du natürlich einen C- bzw. Pascal Compiler, der dir
Z80 Maschinencode erzeugt. C-Compiler für "nackte" Z80 Systeme (also
ohne BIOS oder sonstige Infrastruktur) gibt es. Zu Pascal kann ich
nichts sagen. Forth wäre vielleicht noch zu erwähnen. Und BASIC in
vielfältigen Varianten.
Kommt drauf an, welche Hochsprache man benutzt.
Ich finde in dem Moment wo man mit Assembler drangeht, hat der Z80 nur
Nachteile im Vergleich zu einem AVR. Allein die Geschwindigkeit, die der
AVR erreicht...
@ Toni
Naja. Ich sag mal ein klares: Jein!
Die Unterschiede zwischen einem Mikroprozessor wie dem Z80 und einem
Mikrocontroller wie dem AVR sind im Grunde nur eine Frage der
Konstruktion eines Gesamtsystems. Das ist auch schon erwähnt worden.
Während der Mikrocontroller AVR bereits Programm-Fest-Speicher und RAM
hat, hat der Z80 das von Hause aus nicht, aber man kann das extern
anschliessen. Während der AVR bereits Schnittstellen wie UART, SPI, TWI
etc. neben einigem anderen hat, hat der Z80 das von Hause aus nicht,
aber man kann das extern anschliessen.
OK. Man kann also beide, den AVR und den Z80 im Prinzip von der Hardware
her gleich machen, wenn man will. Für einen geschickten Bastler kein
allzu grosses Problem.
Das entscheidende bei Deiner Frage ist, der Unterschied in der Software.
In dieser Hinsicht sind AVR und Z80 im Lieferzustand gleich. Tun wir die
also mal eine die eine Schublade. Der Vergleich muss dann mit einem PC
in der anderen Schublade passieren.
Ein PC wird häufig mit einem "Betriebssystem" geliefert. AVR/Z80
hingegen nicht. (Ich betrachte hier mal BIOS und Betriebssysteme wie
Windows/Linux als eines. Organisatorisch ist da doch noch ein
Unterschied).
Das Betriebssystem übernimmt Aufgaben, die in jedem "guten" Programm
irgendwann einmal gebraucht werden. Also: Text-Ein- und Ausgabe, Fenster
aufmachen. Ereignisse von Treibern entgegennehmen und verteilen bzw.
umgekehrt, Speicherveraltung, Massenspeichersteuerung etcpp.
Wenn ich auf einem PC etwa ein Turbo-Pascal- oder ein C-Programm
schreibe und das compiliere, dann ist der Compiler so eingerichtet, dass
er von dem Vorhandensein dieses Betriebssystems schon ausgeht. D.h. er
wird keinen eigenen Code etwa für die Ein- und Ausgabe oder die
Massenspeicherverwaltung (etwa das Filesystem) mitbringen. (Das stimmt
so nicht ganz, denn er bringt etwa mit "printf" bestimmte besondere
Möglichkeiten zur Ausgabe mit, die aber letztendlich primitive
Einzelzeichen wie 'A' oder 'B' dann doch über das Betriebssystem
ausgibt).
Compiler für einen AVR oder einen nackten Z80 dürfen dagegen nicht davon
ausgehen, dass gewisse einfache Möglichkeiten schon vorhanden sind.
Sie werden mit mehr oder weniger umfgangreichen Bibliotheken von Code
geliefert, bzw. der Programmierer muss diese einfachen Möglichkeiten
selbst schreiben.
OK. Grundsätzlich kann man also mit Turbo Pascal für den PC kein
Programm für ein AVR- oder Z80-System erzeugen, weil das Turbo Pascal
eben ausführbaren Code mit DOS oder Windows oder Linux-Betriebssystem
erzeugt. Das hat der Z80 ja erstmal so nicht.
Für solche Gelegenheiten, bei denen man auf einem System wie dem PC ein
Programm für den AVR erzeugen will benötigt man einen sogenannten
"Cross-Compiler". Im Prinzip ist das AVR-Studio bzw. der dort verwendete
GCC ein Cross-Compiler. Es gibt auch GCC als "native" Compiler, der eben
Code für das System erzeugt, auf dem er läuft. Aber ein Cross-Compiler
erzeugt Code für fremde Systeme.
Von diesem Punkt an, muss man sich dann etwas tiefer mit Compilern
beschäftigen.
Z.B. spielt der sogenannte "Start-Up"-Code eine Rolle. Das ist der Code,
der nach dem Reset abläuft und dann das eigentliche Programm aufruft. In
C wäre das die main-Funktion. Wie das in Pascal heisst, habe ich
vergessen. :-)
Ein ähnlicher Punkt betrifft die Speicherverwaltung. Will man etwa
"malloc" verwenden, muss man sich den Code dafür selbst schreiben (wobei
das andere inzwischen für viele Mikrocontroller und Mikroprozessoren
getan haben).
Wenn Du das mal für den Z80 genauer anschauen willst, dann guck Dir mal
die Unterlagen von CP/M an. CP/M ist das Betriebssystem, dass aber durch
Basisroutinen für die Ein- und Ausgabe etc. ergänzt werden muss. Ich
weiss nicht mehr welches Handbuch genau dafür zuständig ist, aber mit
etwas Geduld findet man das auch heute noch im Netz. (Ansonsten müsste
ich mal in meinem Bücherstapel suchen).
Auf CP/M lief dann unter anderem auch Turbo Pascal. Ich habe das selbst
mal verwendet. Lang, lang ists her.
Im Prinzip muss so eine Anpassung aber nicht zwangsweise an ein
Betriebssystem stattfinden. Man könnte dem Compiler eben auch
Basisroutinen mitgeben, die kein Betriebssystem voraussetzen. Dann würde
man die Anwendung direkt mit dem Mikrocontroller oder dem Mikroprozessor
verheiraten.
Na, ich hoffe das hilft Dir erstmal etwas weiter.
Ben B. schrieb:> Kommt drauf an, welche Hochsprache man benutzt.>> Ich finde in dem Moment wo man mit Assembler drangeht, hat der Z80 nur> Nachteile im Vergleich zu einem AVR. Allein die Geschwindigkeit, die der> AVR erreicht...
Na gut. Ein bisschen Off-Topic, aber das reizt mich dann doch.
Der Vergleich passt nicht so ganz. Der Z80 hat einen wesentlich
umfangreicheren Befehlssatz als der AVR. Da geht um den CISC/RISC
Unterschied.
So gesehen, ist der AVR zwar schneller, aber er muss komplexere
Operationen die der Z80 in einem Befehle vereint, durch mehrere Befehle
nachbilden. (Das weisst Du im Prinzip vermutlich ohnehin).
OK. Ich vermute mal, dass die Geschwindigkeit des AVR rein auf das
Silizium bezogen dennoch in Summe höher ist also so ein 1, 2 oder 6MHz
Z80. Aber wenn man den Z80 mit heutiger Technologie nochmal bauen würde,
so dass er mit 24MHz oder so laufen würde, wäre er doch schneller als
der AVR, denke ich.
Ob man das jetzt ernsthaft diskutieren sollte, bezweifele ich. Aber ich
wollte dem guten alten Z80 (noch lieber dem 6502) die Treue halten. :-)
Theor schrieb:> Ob man das jetzt ernsthaft diskutieren sollte, bezweifele ich. Aber ich> wollte dem guten alten Z80 (noch lieber dem 6502) die Treue halten. :-)
Völlig offtopic, sry. Aber
So abwegig finde ich das nicht. Ich bin gerade dabei ein 6502 System auf
einem FPGA zu implementieren. Ist extrem klein (~500 Spartan-3e LUTs)
und kann mal schnell die üblichen Nervsachen erledigen (z.B.
Displayansteuerung etc) die sonst mit Verilog machbar, aber ätzend,
sind.
Dann bleibt im FPGA mehr Platz für die Sachen, die man in einem uC eher
nicht mehr machen kann.
MfG
AHz
Crosscompiler für den Z80 gibt es für viele Programmiersprachen und
Systeme.
Ob Windows, MS-DOS, CP/M, RIO und sogar auf Heimcomputern wie dem
ZX-Spectrum.
Toni schrieb:> Also kann ich den in C oder Pascal programmieren und das.bin File> einfach aufs EEprom packen
Natürlich, so hat man das damals schon gemacht.
Toni schrieb:> wie z.B. von Turbo Pascal erstellt wird
Das gerade nicht, Turbo Pascal erstellt Programme für Systeme mit
Betriebssystem, zuerst meiner Erinnerung nach für CP/M, dann für DOS und
später für Windows.
Für Z80 gab und gibt es immer noch eine grosse Menge an Assemblern und
Compilern in einer ganzen Reihe von Sprachen. Aber deine Frage ist
inkonsequent, ein AVR benutzt ja auch nicht DOS oder Windows.
Der einzige Unterschied zwischen Z80 und AVR ist kein logischer, sondern
nur ein physikalischer: der Z80 hat keine internen Speicher, weder Rom
noch Ram, daher müssen externe Chips angeschlossen werden. Die
Programmentwicklung läuft also prinzipiell gleich, nur dass man am Ende
ein externes Eprom oder Flash programmiert und nicht das interne. Ich
habe lange Zeit einen sehr guten Pascal-Crosscompiler benutzt (Prospero
Pascal), zusammen mit Assembler.
Der Vollständigkeit halber: man kann sich ein Z80-System mit CP/M
erstellen, da könnten auch Turbo Pascal für CP/M Programme laufen, aber
das ist ein ganz anderes Thema.
Georg
> Das gerade nicht, Turbo Pascal erstellt Programme für Systeme mit> Betriebssystem, zuerst meiner Erinnerung nach für CP/M, dann für DOS und> später für Windows.
Es gab in der C't mal einen Artikel der gezeigt hat wie man TP3.0 fuer
DOS dazu bringt ohne Betriebsystem zu laufen. Es ist sicherlich kein
grosses Problem etwas aehnliches fuer die CP/M Version zu machen. Also
wenn man es ganz feste will natuerlich....
Olaf
NAMENSWECHSEL DA ANDERER COMPUTER!!!
falls wieder ein beknackter Mod meint deshalb wild löschen zu müssen!!
"Es gibt kein DOS für Z80."
=?!?
Ich denke ein Z80 ist binärkompatibel zum 8088 oder 8086 und kann somit
sehr wohl DOS bedienen...oder hab ich da was falsch verstanden..er ist
NICHT Pinkompatibel, aber Binärkompatibel.
Ich selber hatte einen Schnedier CPC8126 mit BAsic/CP/M..und meine es
gibt im netzt auch welche auf denen MS Dos läuft..kann mich aber auch
irren.
Und auf diesem hatte ich in Basic bzw PAscal auch programmiert
aber die Antworten reichen mir soweit..#Scahde..ich wollte eben nur mal
etwas rumdaddeln mit meinem Kindheitsprozessor..und wollte das nicht in
ASM machen..sondern ein eine ausgereiftere Hochsprache wie PAscal doer C
gehen..und das wären dann eher sowas wie Freepascal oder eben gcc
gewesen..die Uralt Pascal Dialekte sind nicht vergleichbar...max Turbo
PAscal 7 hätte ich noch in betracht gezogen
Hier eine FPGA Lösung mit C Firmware, die im Z80 läuft + Peripherie:
https://github.com/abnoname/iceZ0mb1e
Da kannst du dir den C Firmware Teil anschauen. Die Peripherie ist nicht
PIO/SIO kompatibel, aber das Prinzip ist das gleiche -> Stichwort: sdcc
Also klare Antwort: ja! Ein Z80 mit PIO, SIO etc. ist das gleiche wie
beim AVR, nur verteilt auf viele Chips. Meine Lösung hier läuft auf
einem Chip (im FPGA) :-)
Thomas M. schrieb:> ein beknackter Mod meint
Schon deswegen gehoert das geloescht.
Nur ein Name pro Thread ist eine der Grundregeln hier, wenn Du Dich
nicht dran halten willst, werde nicht auch noch ausfaellig.
wendelsberg
ich wollte schon gerne beim echten Z80 bleiben ;-)
Und eben auch mit standard Pascal oder C, wenn man sowieso eine
spezielle Version mit völlig anderen Befehlen hat, bringt es einem aus
Nostalgiegründen natürlich nichts;-)
Man will sich ja etwas in die Zeit von damals zurückversetzt fühlen :-)
Dennis H. schrieb:> In wieweit Turbo Pascal für Z80 das kann weiß ich nicht.> C sollte in der Lage sein, vom Linker her etc., Code zu produzieren der> direkt läuft. Einsprungpunkt vom Prozessor bei Reset muss dann> berücksichtigt werden.
IMHO gab es für Turbopascal 3.xx Patches um Rom-fähigen Code zu
erzeugen.
Die Bildschirmtreiber etc. bring Turbopascal ja selbst mit, die werden
vom tinst Programm in die Laufzeitbibliothek gepatched.
Schwierig dürfte es werden die nötigen Infos dafür heute noch
aufzutreiben.
Gruß,
Holm
Toni schrieb:> also, wenn es C kann, sollte es dann nicht auch jedes Pascal/BAsic> könnnen?> Denn es geht ja eher um die Frage..wie ist das z.B. mit der RAM> verwaltung?> Wenn man z.B. nut 16KB ansteckt..alsow as die CPU direkt verwalten> kann..funktioniert das dann einfach so..oder ist die Aufgabe eines> Betriebssystems auch diesen Speicher verwalten.
Turbo bekommt beim Start vom OS mitgeteilt wie groß der TPA ist, darum
hat sich also das OS zu kümmern.
> Da Betriebssysteme sowohl in C als auch in Pascal geschrieben wurde,> sollte es ja grundsätzlich gehen
Das ist eher nicht der Fall. CP/M besteht aus Assembler und PLZ.
Gruß,
Holm
Ben B. schrieb:> Kommt drauf an, welche Hochsprache man benutzt.>> Ich finde in dem Moment wo man mit Assembler drangeht, hat der Z80 nur> Nachteile im Vergleich zu einem AVR. Allein die Geschwindigkeit, die der> AVR erreicht...
..ist im Vergleich zum Z80 genau was?
Es gibt den Z180 (Z80 kompatibel) mit bis zu 33 Mhz und Onboard MMU die
1Mbyte adressieren kann.
Gruß,
Holm
Thomas M. schrieb:> NAMENSWECHSEL DA ANDERER COMPUTER!!!> falls wieder ein beknackter Mod meint deshalb wild löschen zu müssen!!>> "Es gibt kein DOS für Z80."> =?!?> Ich denke ein Z80 ist binärkompatibel zum 8088 oder 8086 und kann somit> sehr wohl DOS bedienen...oder hab ich da was falsch verstanden..er ist> NICHT Pinkompatibel, aber Binärkompatibel.
"=?!?" ist falsch, "!!!!" ist richtig.
Ein Z80 ist abwärtskompatibel zum 8080 und 8085, die sind aber beide
nicht kompatibel zum 8088 oder 8086.
Gruß,
Holm
Thomas M. schrieb:> ich wollte schon gerne beim echten Z80 bleiben ;-)> Und eben auch mit standard Pascal oder C, wenn man sowieso eine> spezielle Version mit völlig anderen Befehlen hat, bringt es einem aus> Nostalgiegründen natürlich nichts;-)> Man will sich ja etwas in die Zeit von damals zurückversetzt fühlen :-)
Dafür gibts ausreichend Möglichkeiten das zu tun, u.A. hier in diesem
Thread
ist eine hübsche zu finden:
Beitrag "Z180-Stamp Modul"
Du hast sehr schräge Vorstellungen was doch da wie gehen müßte, mit
Deinem derzeitigen Wissensstand ist ein solches Projekt für Dich zu viel
Arbeit und setzt mehr Wissen voraus als Du hast.
Gruß,
Holm
" Da Betriebssysteme sowohl in C als auch in Pascal geschrieben wurde,
> sollte es ja grundsätzlich gehen
Das ist eher nicht der Fall. CP/M besteht aus Assembler und PLZ."
Dann mach dich mal Schlau ;-)
Apple OS wurde z.B. in Pascal geschrieben,..und ist nur eines..es gab
noch einige mehr :-)
"Die Programmierung in Pascal mit der strengen Typprüfung war ein
wesentlicher Grund für die hohe Stabilität des frühen Mac OS"
Quelle
https://de.wikipedia.org/wiki/Apple_Pascal
Toni schrieb:> KAnn ich einen Z80 mit RAM und ROM und PIO genauso wie einen AVR nuzen?> Also kann ich den in C oder Pascal programmieren und das.bin File> einfach aufs EEprom packen, wie z.B. von Turbo Pascal erstellt wird,> oder geht das nur wenn Dos vorhanden ist?
Ja. Für die modernen Typen gibts auch einen
USB-Hardware-Programmer/Debugger und eine IDE mit Compiler,...
https://www.zilog.com/index.php?option=com_product&task=dev_tool_detail&DevToolKit=eZ80F910300KITG
Diese modernen Typen laufen mit 50MHz, haben 512k Flash, 24 Bit
Register, können 16 MB RAM linear adressieren und sind immer noch voll
binärkompatibel zum Ur-Z80.
Es hat sich also auch hier was getan.
fchk
Toni schrieb:> KAnn ich einen Z80 mit RAM und ROM und PIO genauso wie einen AVR nuzen?
Uff. Theoretisch ja. Aber der Schaltungsaufwand ist gigantisch. 8 Bit
Datenbus und 16 Bit Adressbus möchten erstmal verdrahtet werden.
> Also kann ich den in C oder Pascal programmieren und das.bin File> einfach aufs EEprom packen, wie z.B. von Turbo Pascal erstellt wird,> oder geht das nur wenn Dos vorhanden ist?
Oha. Du brauchst etwas, das einen Z80 Maschinencode erzeugt. Ob Du ein
OS verwendest oder nicht ist erstmal egal. Der Compiler wird dir schon
sagen, ob und wenn ja auf welchem OS er laufen will. Ich könnte mir
vorstellen dass ein Schneider CPC mit CP/M und Turbo Pascal
funktionieren könnte.
Um das ganze bequem in dein Z80-System zu bekommen, brauchst Du
mindestens einen Bootloader im ROM den Du dir selbst schreiben musst.
Sonst musst Du jedes Mal das EPROM extern neu Flashen.
Als Ergebnis hast Du eine riesen Platine mit veralteter Technik die viel
Strom verbraucht und ein exotisches Entwicklungs-System benötigt.
Nach dem Abschluss deines Projektes, werden Microkontroller für dich
einen Gott-Status erreichen. Du wirst jeden Tag dafür Beten, dass es
Microkontroller noch lange geben wird und man nie wieder
Microprozessoren und deren Preferie extern aufbauen muss.
Mein Tipp. Lass es sein.
Aber ja, man kann es machen...
na der Schnedier CPC funktioniert natürlich mit CP/M Plus..das wurde
damals mitgeliefert ;-) Udn Apscal gibte s auch dafür..aber wie
gesagt..mir geht es um den Eisnatz auf Lochraster und Ansteuerung der
IOs eines SIO oder PIO.
Habe auch das BUch Programmieren in Maschinensprache mit Z80 hier..aber
ASM wollte ich ja nicht..da ich das damals auch nie genutz hatte in der
Kindheit.
Und logo jedes mal EEPROM flashen ist logo und kein Drama..und mir auch
nicht neu ;-)
Thomas P. schrieb:> " Da Betriebssysteme sowohl in C als auch in Pascal geschrieben wurde,>> sollte es ja grundsätzlich gehen>> Das ist eher nicht der Fall. CP/M besteht aus Assembler und PLZ.">>> Dann mach dich mal Schlau ;-)
Bin ich schon.
> Apple OS wurde z.B. in Pascal geschrieben,..und ist nur eines..es gab> noch einige mehr :-)
Was interessiert das hier? Ich rede auf Deine Anforderung von Z80 und
CP/M und nicht von "einige mehr".
>> "Die Programmierung in Pascal mit der strengen Typprüfung war ein> wesentlicher Grund für die hohe Stabilität des frühen Mac OS">> Quelle> https://de.wikipedia.org/wiki/Apple_Pascal
Na dann gehe mal Turbopascal für MacOS kaufen.
Du hast ein recht ungesundes Nichtwissen.
Gruß,
Holm
Thomas M. schrieb:> na der Schnedier CPC funktioniert natürlich mit CP/M Plus..das wurde> damals mitgeliefert ;-) Udn Apscal gibte s auch dafür..aber wie> gesagt..mir geht es um den Eisnatz auf Lochraster und Ansteuerung der> IOs eines SIO oder PIO.> Habe auch das BUch Programmieren in Maschinensprache mit Z80 hier..aber> ASM wollte ich ja nicht..da ich das damals auch nie genutz hatte in der> Kindheit.
Kannste das mal aus Deiner Programmiersprache nach deutsch oder englisch
übersetzen?
>> Und logo jedes mal EEPROM flashen ist logo und kein Drama..und mir auch> nicht neu ;-)
Wie flasht man einen EEPROM?
Komm vergiß es, Du hast mal wo was gehört, weißt Alles besser und das es
nicht geht liegt an den Leuten hier.
Viel Spaß noch bei der Idee.
Gruß,
Holm
Toni schrieb:> also, wenn es C kann, sollte es dann nicht auch jedes Pascal/BAsic> könnnen?
Du musst einen Compiler benutzen, der für den Mikrocontroller bzw.
Mikroprozessor gemacht wurde.
Bei AVR wäre das der avr-gcc oder fpc-avr (Free Pascal).
Beim Z80 wäre das zum Beispiel der sdcc oder pascal-80.
Da beide kein DOS Betriebssystem ausführen können, kannst du sie nicht
einfach die DOS Rechner programmieren. Und schon gar nicht kannst du
Compiler benutzen, die Maschinencode für DOS Rechner erzeugen, denn die
haben Prozessoren aus der Intel x86 Reihe.
Jede Prozessor-Serie muss mit anderem Maschinencode Programmiert werden.
Wenn alle CPU's gleich funktionieren würden, gäbe es keinen Fortschritt.
"RAM Verwaltung" ist Aufgabe deines Programms, eventuell zusammen mit
dem Betriebssystem (falls vorhanden). DU hast unter Kontrolle, wann dein
Programm wie viel RAM und wofür belegt. Automatische RAM Verwaltung gibt
es nur bei Scriptsprachen (z.B. Python, LUA, Perl) und
halb-interpretiertem Code (z.B. Java und C#).
Moin,
wenn ich mich richtig erinnere, dann kann man in TurboPascal auch
eingebettetes Assembler, Inline-Assembler genannt, nutzen. Damit müßte
es möglich sein, die BIOS-Routinen (also sozusagen den Bootloader)
selbst zu schreiben.
Für den Z80 gab es sehr wohl ein DOS, nämlich das MSX-DOS (Microsoft
Extended DOS), das angeblich zu 99% kompatibel war. (Der Haken waren die
übrigen 1%, aber das ist eine andere Geschichte...)
Und für dieses MSXDOS gab es auch einen TurboPascal-Compiler.
Die strenge Typprüfung und die extrem logische Syntax sowie die
erstklassige Dokumentation waren ein großer Vorteil von Pascal.
(Eigentlich müßte sich die starre Speicherverwaltung von Pascal für die
Harvardarchitektur sehr gut eignen, oder?)
Mit C hatte man aber auch damals schon mehr Freiheiten, auch die, mehr
Fehler zu machen...
> "RAM Verwaltung" ist Aufgabe deines Programms
Sorry, aber das stimmt so nicht. Der Turbo-Compiler hat sich darum
gekümmert. Heap und Stack wurden einmal von oben und einmal von unten
beschrieben - und durften keinesfalls zusammentreffen, was der Compiler
aber im Normalfall verhindert hat.
Was soll der dämliche Kommentar zum EEprom flashen?!? nenn es doch wie
Du willst..jedenfalls ist das beschreiben des EEproms kein
Problem..wollte ich lediglich damit sagen! Aber ich gehe davon aus, das
jeder andere verstanden hat was ich damit meinte..
jup,
Pascal kann inline Assembler :-)
Aber ich kann es nicht;-) Und wenn tatsächlich noch ein Bootloader etc
rein muss..wirds tatsächlich rum rumspielen etwas zu umfangreich
befürchte ich.
Thomas W. schrieb:> CP/M geht (schnell ist was anderes)
Es gab für CP/M keine Standard-Hardware wie den IBM PC, daher gibt es
nicht ein sondern viele CP/M, bzw. man muss selbst das CP/M an die
Hardware anpassen (hiess glaube ich BDOS).
Thomas W. schrieb:> Laufwerk A und B haben ja jeweils 128kB.
Das ist nur eine Frage der Anpassung, ich habe Disketten bis zu 2 MB
(3,5 Zoll HD) verwendet. Da man ja sowieso den Treiber für die Laufwerke
schreiben muss kann man praktisch jedes Format verwenden oder sich
selbst was ausdenken, das kann auch ganz exotisch sein.
Georg
georg schrieb:> Thomas W. schrieb:>> CP/M geht (schnell ist was anderes)>> Es gab für CP/M keine Standard-Hardware wie den IBM PC, daher gibt es> nicht ein sondern viele CP/M, bzw. man muss selbst das CP/M an die> Hardware anpassen (hiess glaube ich BDOS).
Du glaubst falsch. BDOS (und CCP) waren die hardwareunabhängigen Teile
von CP/M. Der systemabhängige Teil war das BIOS.
> Thomas W. schrieb:>> Laufwerk A und B haben ja jeweils 128kB.>> Das ist nur eine Frage der Anpassung
Das war eine Aussage zu eben diesem Z80-MBC2. Der emuliert die
Laufwerke, mutmaßlich mit den beiden 24LC1025 I²C EEPROMs. Die Kapazität
stimmt ja schon mal.
Thomas M. schrieb:> "Es gibt kein DOS für Z80."
Woher kommt eigentlich diese irrige Aussage?
DOS = Disk Operating System
CP/M ist im Original ein reinrassiges DOS
DOS ≠ MS-DOS/PC-DOS oder was auch immer!
Für Z-80 gab es übrigens nur Turbo-Pascal 3, alle neueren Versionen nur
für MS-DOS / kompatible und nachfolgende PC-Betriebssysteme.
Ich kann mich allerdings auch an ein Minimal-CP/M erinnern, das
TP3-CP/M-Programme aus dem EPROM lauffähig machte.
Wenn man die Möglichkeiten auf Microcontroller-Niveau reduziert (keine
Display-Steuerung oder gar Grafik, nur serielle Konsole und keine
Massenspeicher) bleibt das erforderliche BIOS recht übersichtlich.
Die Z80 hatten normalerweise 1-2 MHz, deutlich teurer 4 oder sogar 10
MHz. Es gab im Amateurfunk den TNC (terminal node controller) für
Packet-Radio mit Z80. Da sind sicher gebrauchte Europakarten zu finden.
Thomas M. schrieb:> Was soll der dämliche Kommentar zum EEprom flashen?!? nenn es doch wie> Du willst..jedenfalls ist das beschreiben des EEproms kein> Problem..wollte ich lediglich damit sagen! Aber ich gehe davon aus, das> jeder andere verstanden hat was ich damit meinte..
Den Schuh ziehe ich mir nicht an, der Dämlack bist Du. Große Klappe aber
innen hohl.
Gruß,
holm
@Toni,
Klar kann man mit dem Z80 Einplatinenrechner bauen.
Programmiert wird das Ganze dann "bare metal" mit
der IAR oder Keil - Toolchain.
Man kann das Z80 - System auf ner Lochrasterplatte
aufbauen, man kann sich aber auch ein fertiges System
schnappen und auf diesem aufbauen.
Du brauchst aber dann einen Eprommer!
Ich hab als Beispiel mal ne Karte auf den Scanner
gelegt, Z80, 2X PIO, 1X CTC, ROM und RAM.
Ein geiles Teil, absolut interessant, sie stammt
aus einer teilautomatischen OB - Notvermittlung
aus der Zeit des "kalten Krieges".
mfg
"Du brauchst aber dann einen Eprommer!"
Habe hier ein EEprom rumliegen, wie gesagt..das ist kein Problem..damit
habe ich auch schon rumprobiert..beschreiben etc.
Ich arbeite sonst ja auch eher mit Atmega oder STM32.
ber auch bei der Keil oder IAR Lösung benötige ich dann dennoch eine ART
Bootcode.und daran scheitert es ja..ich hatte gehofft, man könnte
einfach das bin/hex file so verwenden wie es aus gängigen 8080 Compilern
kommt
aber tatsächlich ist Deine eingestellte Platine nett...da sie eben
wirklich nur das nötigste besitzt..was man sowieso auch nur aufbauen
würde...ok..es befinden sich 2x PIO drauf, aber daran sollte es nicht
scheitern;-)
Thomas M. schrieb:> Aber auch bei der Keil oder IAR Lösung benötige ich dann dennoch eine ART> Bootcode.und daran scheitert es ja.
Nein, Du brauchst keinen "Bootcode". Wozu sollte der da sein?
Dein Compiler muss halt Code erzeugen, der die benötigten Vektoren
(Reset- & Interrupt) an den richtigen Adressen enthält, das packst Du so
in Dein (E- oder EE- oder was auch immer P-) ROM, und das wars schon.
Der C-Startup-Code, der für die Erzeugung von Binaries genutzt wird, die
ohne Betriebssystem verwendet werden sollen, kümmert sich um das
wesentliche, Initialisieren des Stacks, Initialisieren der Variablen und
Aufrufen von main(). Mehr ist nicht.
Und da unterscheidet sich die Angelegenheit überhaupt nicht zwischen der
Programmierung auf irgendeinem µC oder einem klassischen Mikroprozessor
- bei letzterem ist halt die Peripherie und Speicherorganisation nicht
vom Hersteller des Prozessors vorgegeben.
Thomas M. schrieb:> Ich denke ein Z80 ist binärkompatibel zum 8088 oder 8086 und kann somit> sehr wohl DOS bedienen...oder hab ich da was falsch verstanden..er ist> NICHT Pinkompatibel, aber Binärkompatibel.
Was Du Dir denkst, spielt keine Rolle. Danach wird sich kein Prozessor
richten. Eine gewisse Binärkompatibilität des Z80 besteht nur zu 8080
und 8085.
ok..also nochmal zusammengefasst gefragt..ob ich es richtig verstanden
habe..den dazu wurde vorher widersprüchliches geschrieben..
Wenn ich also z.B. einen C Complier nehme der Z80 code erzeugen
kann(kann der gc 8080 oder Z80?) oder eben ein PAscal das 8080 bzw Z80
kann, könnt ich also doch, genau so, wie iche s ursprünglich
dachte..einfach sowas schreiben um über das angeschlossene SIO IC eine
LEX zu schalten?
Da ich ja direkt die Register schreibe?
Program Test;
const BA = $3F8;
Begin
Port [BA+4] := 1; //LED an DTR einschalten
delay(1000);
Port[BA+4]:=0; //LED an DTR ausschalten
delay(1000);
end;
"Eine gewisse Binärkompatibilität des Z80 besteht nur zu 8080§
ist bereits geklärt..der 8080 ist Z80 kompatibel und umgekehrt
https://de.wikipedia.org/wiki/Zilog_Z80
Christoph db1uq K. schrieb:> Die Z80 hatten normalerweise 1-2 MHz, deutlich teurer 4 oder sogar 10> MHz.
So schlecht war die Z80 nicht...
Z80 hatte initial 2.5 MHz, der Z80A (vermutlich selektierte Z80 (?))
hatte 4 MHz für wenig mehr Geld, Z80B und Z80H mit 6MHz und 8MHz kamen
später auch noch, bei 10MHz war dann aber Schluss (alles NMOS IIRC).
Ein CMOS-Redesign erlaubte dann noch höhere Taktraten.
Thomas M. schrieb:> Wenn ich also z.B. einen C Complier nehme der Z80 code erzeugen> kann(kann der gc 8080 oder Z80?) oder eben ein PAscal das 8080 bzw Z80> kann, könnt ich also doch, genau so, wie iche s ursprünglich> dachte..einfach sowas schreiben um über das angeschlossene SIO IC eine> LEX zu schalten?
für C ja, siehe SDCC, für Pascal NEIN
Warum für PAscal nein?!
Es ist doch z.B von Freepascal eine Z80 Variante weitgehend
fertig..wieso geht die dann nicht?
Da die für Z80 und nicht für DOS ist..geht die doch sehr wohl, sonst
wäre die doch eben für DOS oder CP/M-richtig?
Thomas M. schrieb:> "Eine gewisse Binärkompatibilität des Z80 besteht nur zu 8080§> ist bereits geklärt..der 8080 ist Z80 kompatibel und umgekehrt>> https://de.wikipedia.org/wiki/Zilog_Z80
..falsch.
Der Z80 ist 8080 kompatibel, aber nicht umgekehrt.
Thomas M. schrieb:> achne..zdev ist ein assmbler..aber ach vom Freepsacal gibt es eine Z80> Version die noch nicht perfekt ist
Mach doch einfach los, Du kennst Dich ja aus .. [ ]
Gruß,
Holm
Joe G. schrieb:> für C ja, siehe SDCC, für Pascal NEIN
Natürlich auch Pascal, was glaubst du dass ich jahrelang gemacht habe
(Prospero Pascal). Und auch Basic, Forth, Modula2, sogar Prolog -für
kaum einen anderen Prozessor gibt es so viele Möglichkeiten. Es kann
allerdings sein dass man auf einen Link nur noch HTTP 404 bekommt.
Georg
Thomas M. schrieb:> benötige ich dann dennoch eine ART> Bootcode.und daran scheitert es ja..
Das ist eine Verblendung durch die Einschränkung auf heutige Sicht -
eigentlich war es viel einfacher. Compiler und Linker liefern eine
Binär- oder Hex-Datei, die lädst du in deinen Programmer und klickst auf
Programmieren - fertig, Eprom oder Flash in die Fassung stecken, läuft
(oder auch nicht, aber das ist wieder ein ganz anderes Problem).
Bootloader waren nicht üblich, und wenn hätten sie das Problem gehabt,
dass man ja beliebige Eproms, EEProms oder Flash-Bausteine am Z80
verwenden konnte, ein theoretischer Bootloader hätte all programmieren
können müssen, was praktisch unmöglich ist.
Tatsächlich habe ich mal so etwas Ähnliches geschrieben für
In-Circuit-Programmierung in der Fabrik, aber nur für ganz bestimmte
Flash-ICs von Intel.
Georg
Thomas M. schrieb:> kann Herr holm einfach mal die Fresse halten und sich raushalten..das> mit der Kmpatibilität wurde bereits geklärt Du Blitzmerker
Das hatte ich Dir als Erster oben geschrieben, begriffen hattest Du es
trotzdem nicht, sondern lamentierst wieder Zeug was nicht stimmt.
Fresse halten? Klar doch. Schnauze Du Spinner.
Ich hätte Dir helfen können weil ich das Zeug seit Jahrzehnten kenne.
Du hättest sogar Hardware bekommen können, aber jeder ist seines eigenen
Glückes Schmied.
Gruß,
Holm
georg schrieb:> Thomas M. schrieb:>> benötige ich dann dennoch eine ART>> Bootcode.und daran scheitert es ja..>> Das ist eine Verblendung durch die Einschränkung auf heutige Sicht -> eigentlich war es viel einfacher. Compiler und Linker liefern eine> Binär- oder Hex-Datei, die lädst du in deinen Programmer und klickst auf> Programmieren - fertig, Eprom oder Flash in die Fassung stecken, läuft> (oder auch nicht, aber das ist wieder ein ganz anderes Problem).> Bootloader waren nicht üblich, und wenn hätten sie das Problem gehabt,> dass man ja beliebige Eproms, EEProms oder Flash-Bausteine am Z80> verwenden konnte, ein theoretischer Bootloader hätte all programmieren> können müssen, was praktisch unmöglich ist.>> Tatsächlich habe ich mal so etwas Ähnliches geschrieben für> In-Circuit-Programmierung in der Fabrik, aber nur für ganz bestimmte> Flash-ICs von Intel.>> Georg
Man kann aber über eine Sio mit Intel hex Kram hochladen und starten,
den Finalen Prom erst brennen wenn es läuft.
Gibts hier fertig.
Thomas M. schrieb:> @georg (Gast)> danke..denn ich habe nicht verstanden weshalb immer wieder gesagt> wird..weshalb es mit PAscal nicht ginge
Weil Du vorher das in Assembler geschriebene Laufzeitsystem des Pascal
Compilers anpassen müßtest. Keine Hände, keine Kekse.
Gruß,
Holm
"Thomas", auch für Dich gelten die Forenregeln.
Nur ein Pseudonym pro Thread - also nicht mischen zwischen "Thomas M.
(Gast)" und "Thomas M. (thomasmopunkt)".
Und das mit den Umgangsformen darfst (nicht nur Du) auch noch etwas
optimieren.
georg schrieb:> Natürlich auch Pascal, was glaubst du dass ich jahrelang gemacht habe> (Prospero Pascal). Und auch Basic, Forth, Modula2, sogar Prolog -für> kaum einen anderen Prozessor gibt es so viele Möglichkeiten.
Ich denke, wir waren schon einen Schritt weiter. Es ging um einen
Compiler, der nicht CP/M oder ein anderes OS als Unterbau für den
Hex-Code benötigt. Beim SDCC ist das so, aber auch bei
- Prospero Pascal ?
- Modula2 ?
- Prolog ?
Welche Versionen sind das?
Joe G. schrieb:> georg schrieb:>> Natürlich auch Pascal, was glaubst du dass ich jahrelang gemacht habe>> (Prospero Pascal). Und auch Basic, Forth, Modula2, sogar Prolog -für>> kaum einen anderen Prozessor gibt es so viele Möglichkeiten.>> Ich denke, wir waren schon einen Schritt weiter. Es ging um einen> Compiler, der nicht CP/M oder ein anderes OS als Unterbau für den> Hex-Code benötigt. Beim SDCC ist das so, aber auch bei> - Prospero Pascal ?> - Modula2 ?> - Prolog ?> Welche Versionen sind das?
Ich schrieb oben schon das es Patches für Turbopascal gab um das
ROM-fähig zu machen, muß wohl vor Urzeiten mal in der MC gestanden
haben.
Auch der BDS-C Compiler (8080) bringt Code für naked Systeme mit:
1
Vorwort
2
Inhaltsverzeichnis
3
4
Teil 1: Bedienungsanleitung (File BDS-C1.DOC)
5
6
Teil 2: Library-Funktionen (File BDS-C2.DOC)
7
8
Teil 3: Nutzung des Long-Integer- und (File BDS-C3.DOC)
9
des Floating-point-Paketes
10
11
Teil 4: Erzeugung von ROM-Code (File BDS-C4.DOC)
12
13
Teil 5: Beispiel-Programme (File BDS-C5.DOC)
14
15
Anhang 1: Fehler-Ausschriften von (File BDS-C6.DOC)
16
Compiler und Linker
17
18
Anhang 2: Einschraenkungen von BDS-C (File BDS-C7.DOC)
19
gegenueber UNIX-C
20
21
Ausserdem gehoeren zu dem Nutzer-Handbuch die Files
Joe G. schrieb:> Ich denke, wir waren schon einen Schritt weiter. Es ging um einen> Compiler, der nicht CP/M oder ein anderes OS als Unterbau für den> Hex-Code benötigt
Nein, da bist du geistig einige Schritte zurückgeblieben. Natürlich geht
es um Stand-Alone-Systeme. Ich wüsste aber nicht warum ich dir jetzt
beweisen müsste dass z.B. meine Photometer-Systeme für die chemische
Industrie funktioniert haben (Z80, 7Segment-Anzeigen, Pascal im Eprom).
Offenbar kannten die deine Bedenken nicht, da kommst du ein paar
Jahrzehnte zu spät. Allerdings hätte ich mich wahrscheinlich auch damals
nicht von so dummen Einwürfen davon abhalten lassen einfach zu machen.
Georg
Das ist so erbärmlich.
gibt es eigentlcih noch einen Thread wo die Leute vernünftig miteinander
umgehen und der Moderator nicht eingreifen muß und später dann dafür
beschimpft wird?
Weihnachten steht vor der TÜR !!!
georg schrieb:> Joe G. schrieb:>> Ich denke, wir waren schon einen Schritt weiter. Es ging um einen>> Compiler, der nicht CP/M oder ein anderes OS als Unterbau für den>> Hex-Code benötigt>> Nein, da bist du geistig einige Schritte zurückgeblieben. Natürlich geht> es um Stand-Alone-Systeme. Ich wüsste aber nicht warum ich dir jetzt> beweisen müsste dass z.B. meine Photometer-Systeme für die chemische> Industrie funktioniert haben (Z80, 7Segment-Anzeigen, Pascal im Eprom).> Offenbar kannten die deine Bedenken nicht, da kommst du ein paar> Jahrzehnte zu spät. Allerdings hätte ich mich wahrscheinlich auch damals> nicht von so dummen Einwürfen davon abhalten lassen einfach zu machen.>> Georg
Machst Du heute noch Pascal? Ich habe das zu CP/M Zeiten und Anfang DOS
fast ausschließlich gemacht..aber indessen da so gut wie Alles
vergessen.
Ich schreibe nur noch C und Assembler...
Gruß,
Holm
georg schrieb:> Nein, da bist du geistig einige Schritte zurückgeblieben.> Ich wüsste aber nicht warum ich dir jetzt> beweisen müsste dass z.B. meine Photometer-Systeme für die chemische> Industrie funktioniert haben (Z80, 7Segment-Anzeigen, Pascal im Eprom).
Dann hilf mir! Als Zurückgebliebener möchte keine Beweise (verstehe ich
sowiso nicht ;-) sondern nur Hilfe. Ich würde gerne eine Prologversion
und eine Modula2 Version für Z80 ohne CP/M oder ein anderes OS nutzen.
Unter welchen Stichworten werde ich fündig?
Turbo Pascal ist ein anderes Produkt als Freepascal, was wiederum anders
ist als diverse andere Pascal Varianten.
Turbo Pascal erzeugt Programme für x86 Rechner mit DOS (kompatiblen)
Betriebssystem. Und dann gab es da noch diese eine Version für CP/M.
Beide Betriebssysteme sind nicht vorhanden -> ergo: Turbo Pascal ist
nicht geeignet.
Stefanus F. schrieb:> Turbo Pascal ist ein anderes Produkt als Freepascal, was wiederum anders> ist als diverse andere Pascal Varianten.>> Turbo Pascal erzeugt Programme für x86 Rechner mit DOS (kompatiblen)> Betriebssystem. Und dann gab es da noch diese eine Version für CP/M.>> Beide Betriebssysteme sind nicht vorhanden -> ergo: Turbo Pascal ist> nicht geeignet.
Na sag mal, bist Du hier neu im Thread?
Was glaubst Du warum ich hier mindestens das 3. Mal schreibe das es für
Turbopascal 3 Patches gab um romfähigen Code auf Naked Z80 Systemen
laufen zu lassen? Wie schriebst du neulich "holm blockiert sich selbst"?
Erkennst Du hier Deine eigene Leseschwäche samt Blockade?
Für CP/M gab es eine Version 1.00, 2.00 und 3.00, 3.01, 3.02. so viel zu
"diese eine Version".
Gruß,
Holm
Holm T. schrieb:> Na sag mal, bist Du hier neu im Thread?
Ich habe einige Beiträge übersprungen. Hier wird ja nur noch beleidigt
und beschimpft! Ich hätte mich besser ganz heraus gehalten.
Über Programmiersprachen kann man sich hier einfach nicht normal
unterhalten.
Bin schon wieder weg.
Für CP/M TP sind (disassemblierte) Sourcen verfügbar, die sich mit
übersetzen lassen:
http://www.memotech.franken.de/CPM80/
Da kann jeder Interessierte mal reinschauen, wie die Pascal-Runtime mit
CP/M, also mit BDOS und BIOS interagiert.
1
How to build Turbo Pascal from these sources
2
============================================
3
4
I use the tools from SLR Systems:
5
SLR180.COM (assembler)
6
"SLR180 Copyright (C) 1985-86 by SLR Systems Rel. 1.32"
7
SLR180 is the version extended for Hitachi HD64180 / Zilog Z180
8
opcodes. The Z80-only version, Z80ASM will also be fine.
9
10
SLRNK.COM (linker)
11
"SuperLinker Copyright (C) 1983-86 by SLR Systems Release 1.31"
12
13
These were written for CP/M-80. I use the CP/M emulator 22NICE from Sydex
14
to let them run under DOS (or in Windows DOS-box).
15
16
commands:
17
> slr180 tp-rtl,tp-me,tp-c
18
Assembles all three parts (runtime library, menu and editor,
19
compiler). Enter desired version number to build (for each part).
20
21
> slrnk tp-rtl,tp-me,tp-c,tp/n/e
22
Link the parts together; the resulting program is named TP.COM.
Ein emuliertes CP/M lässt sich einfach mit YAZE unter Win* und Linux
aufsetzen.
Holm T. schrieb:> Machst Du heute noch Pascal?
Ich könnte, ist alles noch da, auch das Knowhow - aber die Zeit vergeht,
der Chemiekonzern hat die Abteilung geschlossen, ein
Messmaschinenhersteller, für den ich Steueungen gebaut habe, ist schon
lange insolvent, usw. Im Moment liegt kein Bedarf vor.
Joe G. schrieb:> Ich würde gerne eine Prologversion> und eine Modula2 Version für Z80 ohne CP/M oder ein anderes OS nutzen.> Unter welchen Stichworten werde ich fündig?
Da werden Stichworte nicht reichen. Was möglich ist oder nicht und wie
findet man nur im Compiler-Handbuch, bei mir z.B. im Abschnitt "Non-CP/M
Object Program". Ganz hinten im Manual von 1983.
CP/M eliminieren ist übrigens recht einfach. Ein CP/M-Programm beginnt
an Adresse 100H, und alle BS-Aufrufe gehen über Adressen zwischen 0 und
FFH. Ich hatte mir dazu einen 255 Byte langen "CP/M-Emulator"
geschrieben, den man an 0 linkt, dann kann man das ganze CP/M
weglassen. Die meisten Aufrufe sind nur Returns, für Standalone braucht
man ja z.B. keine Floppies. Den Anfang davon:
Stefanus F. schrieb:> Holm T. schrieb:>> Na sag mal, bist Du hier neu im Thread?>> Ich habe einige Beiträge übersprungen. Hier wird ja nur noch beleidigt> und beschimpft! Ich hätte mich besser ganz heraus gehalten.>> Über Programmiersprachen kann man sich hier einfach nicht normal> unterhalten.>> Bin schon wieder weg.
Quatsch, ich habs doch normal versucht. Aber Du kannst sagen was Du
willst, wieder auftauchen und Statements abgeben ohne gelesen zu haben
ist auch nicht in Ordnung.
Gruß,
Holm
> Turbo Pascal erzeugt Programme für x86 Rechner mit DOS (kompatiblen)> Betriebssystem. Und dann gab es da noch diese eine Version für CP/M.
Wie erwähnt gab es auch eine Version für MSXDOS. Der Computer (Philips)
hat einen Z80B mit 6 MHz, samt einem BASIC-Interpreter im ROM.
S. R. schrieb:> svensson schrieb:>> Wie erwähnt gab es auch eine Version für MSXDOS.>> Und da MSXDOS auf einem Z80 läuft, hat es mit PC-DOS genau keine> Kompatiblität.
Es gab keine Version für MSXDOS, das war die normale CP/M Version,
MSXDOS ist auch kein "DOS" im landläufigen Sinne, sondern ein
modifiziertes CP/M.
Gruß,
Holm
Holm T. schrieb:> MSXDOS ist auch kein "DOS" im landläufigen Sinne, sondern ein> modifiziertes CP/M.
Wobei man das über MS-DOS eigentlich auch sagen könnte, zumindest die
ersten Versionen. ;-)
Wenn es auch C sein darf ...
Mit dem Suchterm "GCC Z80" findet man z.B.
https://sourceforge.net/projects/z80gcc/
Um die Basis-Routinen für I/O etc. wird man sich, - wie zuletzt von
Georg erwähnt -, vermutlich dennoch kümmern müssen und dafür gute
Assembler-Kenntnisse haben.
Theor schrieb:> Mit dem Suchterm "GCC Z80" findet man z.B.> https://sourceforge.net/projects/z80gcc/
Last Update: 2015. Und Dateien gibt's da auch keine. Das war ja mal ein
Griff ins Klo.
Es gibt zwei nennenswerte offene C-Compiler für den Z80, und zwar SDCC
und Z88DK. Weitere Compiler gibt es zwar, aber die sind in aller Regel
tot.
S. R. schrieb:> Weitere Compiler gibt es zwar, aber die sind in aller Regel> tot.
Ja und? Was hat sich in den letzten Jahrzehnten denn am Z80 geändert?
Wer unbedingt seine Daten in der Cloud speichern will wird ja kaum einen
Z80 benutzen. Der von mir verwendete Pascal-Compiler von 1983 erfüllt
seine Aufgabe perfekt, und im Gegensatz zu vielen "modernen" Programmen
ist er praktisch ohne Bugs. Man muss auch nicht jeden Monat Updates
einspielen.
MBasic, Assembler M80 und Linker L80 waren wohl die letzten fehlerfreien
Programme die Microsoft erstellt hat. Aber wie man sieht ist das kein
lohnendes Ziel.
So ganz nebenbei gibt es für den eZ80 von Zilog Assembler und C-Compiler
nach dem neuesten Stand, und die können auch Z80-Code erstellen, man
muss ja die erweiterten Befehle nicht benutzen.
Georg
georg schrieb:>> Weitere Compiler gibt es zwar,>> aber die sind in aller Regel tot.>> Ja und?
Ich konkretisiere: Die sind in aller Regel tot und/oder nicht frei.
Wenn du einen Z80 mit CP/M und dem Ökosystem aus den frühen 80ern genau
so benutzen willst, wie du es in den frühen 80ern schon getan hast, dann
ist das eine coole Sache - und heißt Retro-Computing. Find ich super.
Aber nicht alles, was einen Z80 enthält, ist Retro. Mein Board ist es
definitiv nicht (da ist ein AVR als Support-Prozessor mit drauf). Und
ich habe auch nicht unbedingt große Lust, mich mit allen Einschränkungen
damaliger Technik rumzuschlagen.
Man kann mit heutigen Mitteln (und heutigem Wissen) aus damaliger
Technik wesentlich mehr rausholen, als man damals für möglich gehalten
hätte. Beispiel: SymbOS (www.symbos.de). Find ich auch super.
Wenn der Compiler nicht in 56 KB RAM und 4 MHz gequetscht werden muss,
kann er wesentlich effizienteren Code produzieren und wesentlich
komplexere Quelltexte in annehmbarer Zeit verarbeiten. Das kann man
nutzen - aber nicht mit Turbo Pascal 3.0 unter CP/M.
S. R. schrieb:> georg schrieb:>>> Weitere Compiler gibt es zwar,>>> aber die sind in aller Regel tot.>>>> Ja und?>> Ich konkretisiere: Die sind in aller Regel tot und/oder nicht frei.>> Wenn du einen Z80 mit CP/M und dem Ökosystem aus den frühen 80ern genau> so benutzen willst, wie du es in den frühen 80ern schon getan hast, dann> ist das eine coole Sache - und heißt Retro-Computing. Find ich super.>> Aber nicht alles, was einen Z80 enthält, ist Retro. Mein Board ist es> definitiv nicht (da ist ein AVR als Support-Prozessor mit drauf).
Jaa.. der unsägliche Erpom-Emulator... weil man heute glaubt die
Hardware irgendwie an den Haaren aus dem Sumpf ziehen zu müssen. Eproms
brennen kann Keiner mehr, der Promer wird ja von Windows10 nicht mehr
unterstützt...oder so.
> Und> ich habe auch nicht unbedingt große Lust, mich mit allen Einschränkungen> damaliger Technik rumzuschlagen.
Die da wären?
Hier ging es um eine Embedded Anwendung ..oder genauer nur um den
Versuch einer Spielerei.
>> Man kann mit heutigen Mitteln (und heutigem Wissen) aus damaliger> Technik wesentlich mehr rausholen, als man damals für möglich gehalten> hätte. Beispiel: SymbOS (www.symbos.de). Find ich auch super.
Das ist doch eher sehr spezielle Hardware und die Besonderheit liegt
hier nicht im Z80.
>> Wenn der Compiler nicht in 56 KB RAM und 4 MHz gequetscht werden muss,> kann er wesentlich effizienteren Code produzieren und wesentlich> komplexere Quelltexte in annehmbarer Zeit verarbeiten. Das kann man> nutzen - aber nicht mit Turbo Pascal 3.0 unter CP/M.
Vorsicht! Tubopascal 3.0x war ein hocheffizienter Compiler, deshalb und
wegen seiner integrierten "IDE" war er auf dem 8-Bit Markt nahezu das
Nonplusultra. Gegen die Codequalität dürfte ein SDCC (ich nehme den
teilweise auch) heute noch heftig zu kämpfen haben, trotz des Vielfachen
zur Verfügung stehender Resourcen.
Du versuchst hier die Logik von "viel hilft viel" zu propagieren, aber
KISS ist auch nicht schlecht ..eher besser.
Wenn Du von modern redest dann würde ich nicht vom Z80 und besseren
Compilern schwadronieren, sondern gleich ein BluePill Board nehmen.
Gruß,
Holm
Holm T. schrieb:> Gegen die Codequalität dürfte ein SDCC (ich nehme den teilweise auch)> heute noch heftig zu kämpfen haben
Wie kommst Du auf diese Idee?
Du kannst ein Z80 System auf einen FPGA packen und Software
drumherumstricken um damit wie mit einem µController System zu arbeiten:
Retrocomputing auf FPGA
S. R. schrieb:> Es gibt zwei nennenswerte offene C-Compiler für den Z80, und zwar SDCC> und Z88DK. Weitere Compiler gibt es zwar, aber die sind in aller Regel> tot.
Für tote Controller nimmt man tote Compiler.
https://www.bdsoft.com/resources/bdsc.html
Rufus Τ. F. schrieb:> Holm T. schrieb:>> Gegen die Codequalität dürfte ein SDCC (ich nehme den teilweise auch)>> heute noch heftig zu kämpfen haben>> Wie kommst Du auf diese Idee?
Einfach Code-Dichte. Turbopascal erzeugte kompakten und sehr schnellen
Code,
SDCC braucht da simpel noch ein Bisschen Zeit.. wobei natürlich
kontraproduktiv ist, dass der Z80 schon ein Weile "out" ist.
Gruß,
Holm
soul e. schrieb:> S. R. schrieb:>>> Es gibt zwei nennenswerte offene C-Compiler für den Z80, und zwar SDCC>> und Z88DK. Weitere Compiler gibt es zwar, aber die sind in aller Regel>> tot.>> Für tote Controller nimmt man tote Compiler.> https://www.bdsoft.com/resources/bdsc.html
BDS-C hatte ich schon erwähnt.
Tot ist der Z80 aber eher nicht, ich kenne nur alte Beispiele (Nintendo
usw) aber es ist erstaunlich aus aus welchen recht modernen Geschichten
einen immer wieder die Struktur, aber auch der Befehlssatz eines Z80
angrinst.
Ich hatte erst letztens wieder das vergnügen, mir fällt aber jetzt nicht
ein was genau da war.
Gruß,
Holm
Holm T. schrieb:> ....aber es ist erstaunlich aus aus welchen recht modernen Geschichten> einen immer wieder die Struktur, aber auch der Befehlssatz eines Z80> angrinst.> Holm
als ich dem 6502 und z80 schon den Rücken gekehrt hatte zum 68K und mich
intensiver mit dem LH5803 (Sharp PC1500) beschäftigte da erkannte ich
beide wieder, z80 + 6502 und man konnte sogar 65xx Chips adaptieren dank
phi0/1 Takt(6502) aber auch mit 16bit Register rechnen wie im z80.
Joachim B. schrieb:> und mich intensiver mit dem LH5803 (Sharp PC1500) beschäftigte
Das im Zusammenhang mit "modernen Geschichten" zu erwähnen ist aber auch
... Lustig. Der PC1500 war vor über 35 Jahren aktuell (ich hab' für das
Ding mal eine handgeklöppelte Druckausgabefunktion geschrieben, weil
das, was das eingebaute Basic mit dem Parallelinterface machte,
unglaublich langsam war, und das war vor etwa 35 Jahren).
S. R. schrieb:> Wenn der Compiler nicht in 56 KB RAM und 4 MHz gequetscht werden muss,> kann er wesentlich effizienteren Code produzieren
Das ist sowieso ein grundlegender Irrtum. Der erzeugte Code soll auf Z80
laufen, nicht der Compiler! Der eZ80-Compiler läuft bei mir auf einem
Intel I5 unter Windows 10, ist dir das nicht modern genug? Und selbst
uralte Cross-Compiler, die seit Jahrzehnten nicht mehr upgedatet wurden,
laufen zumindest unter MSDOS und somit auch auf einem Windows 10 System.
Von 56k Ram ist da nirgends die Rede, nicht für die Entwicklung.
Und selbst meine Z80-Steuerungen hatten 256k Ram, nur so nebenbei
bemerkt.
Georg
Rufus Τ. F. schrieb:> Joachim B. schrieb:>> und mich intensiver mit dem LH5803 (Sharp PC1500) beschäftigte>> Das im Zusammenhang mit "modernen Geschichten" zu erwähnen ist aber auch> ... Lustig. Der PC1500 war vor über 35 Jahren aktuell (ich hab' für das> Ding mal eine handgeklöppelte Druckausgabefunktion geschrieben, weil> das, was das eingebaute Basic mit dem Parallelinterface machte,> unglaublich langsam war, und das war vor etwa 35 Jahren).
Ist aber auch egal Rufus, der Z80 ist ähnlich wie der 8051 irgendwie
nicht tot zu kriegen. Irgend ein NEC Einchipper sah von den Registern
her auch wie ein Z80 aus (inkl. Schattensatz), der Opcode war aber
anders.
Wikipedia:
1
Später wurde der Prozessor auch in Texas-Instruments-Taschenrechnern (selbst heute noch im TI-83 Plus, TI-84 Plus und TI-84 Plus Silver Edition), in SNKs Neo Geo als Sound-Co-Prozessor und Segas Spielkonsolen Master System und Game Gear verwendet; der Sega Mega Drive nutzte ihn als Coprozessor für die Audioausgabe. Nintendos Spielkonsolen Game Boy und Game Boy Color benutzten einen Z80-Klon (DMG-CPU), der von Sharp hergestellt wurde. Er hat einen leicht abgewandelten Befehlssatz.
2
3
Der Z80 wurde auch bei eingebetteten Systemen beliebt und ist dort heute noch weit verbreitet, beispielsweise arbeitet in Toshibas Mikrocontroller-Familien TLCS-90 und TLCS-870 ein Z80-Kern in vielfältigsten Kombinationen von Speicher- und Peripherieausstattungen. Auch in dem von 1986 bis 1989 in der DDR vom VEB AAC Cottbus hergestellten Hybridsynthesizer Tiracon 6V dient der Z80 zur digitalen Steuerung der analogen Klangerzeuger-Hardware. Verwendet wurden dabei jedoch weder die in der Sowjetunion hergestellten noch die DDR-Clones des Z80 (siehe Versionen).
BTW: Alle "in der Sowjetunion hergestellten" Z80 Clones enthalten einen
Chip "U880-5" oder "U880-6", die haben da also nur Zyklus II gemacht,
die Chips kamen aus der DDR. Egal, die sind fehlerfreier als das
Original.
Gruß,
Holm
Holm T. schrieb:>> Aber nicht alles, was einen Z80 enthält, ist Retro. Mein Board ist es>> definitiv nicht (da ist ein AVR als Support-Prozessor mit drauf).>> Jaa.. der unsägliche Erpom-Emulator... weil man heute glaubt die> Hardware irgendwie an den Haaren aus dem Sumpf ziehen zu müssen.
Erklär mal bitte, was du damit meinst?
> Eproms brennen kann Keiner mehr, der Promer wird ja> von Windows10 nicht mehr unterstützt...oder so.
Bei mir liegen weder Brenner noch EPROMs rum. Sicher, ein paar alte
BIOS-Bausteine (5V-Flash) habe ich noch und die kommen da auch noch
rein.
>> Und ich habe auch nicht unbedingt große Lust, mich mit allen>> Einschränkungen damaliger Technik rumzuschlagen.> Die da wären?
Begrenzt zuverlässige Hardware, aufwändiges Bootstrapping,
Speichermangel, primitive Hardware (geringe Auflösung, keine Grafik,
keine Farbe), etc.
Ich bin nicht mit CP/M groß geworden und die damalige Software war etwas
weniger ausführlich, was Fehler oder Hilfestellungen betrifft. Dafür gab
es Bedienungsanleitungen und Bücher - aber die muss man sich auch
erstmal besorgen, lesen und verstehen.
> Hier ging es um eine Embedded Anwendung ..oder genauer nur um den> Versuch einer Spielerei.
Eben. Da muss man nicht feste Retro-Regeln ansetzen. :-)
>> Man kann mit heutigen Mitteln (und heutigem Wissen) aus damaliger>> Technik wesentlich mehr rausholen, als man damals für möglich gehalten>> hätte. Beispiel: SymbOS (www.symbos.de). Find ich auch super.>> Das ist doch eher sehr spezielle Hardware und die Besonderheit liegt> hier nicht im Z80.
Darum ging es nicht. Es ging darum, dass dieses System auf dieser
Hardware in den 80ern schlicht unmöglich gewesen wäre. Nicht, weil die
Technik das nicht konnte (sie kann es nachweislich ja), sondern weil die
Menschen es nicht konnten.
>> Wenn der Compiler nicht in 56 KB RAM und 4 MHz gequetscht werden muss,>> kann er wesentlich effizienteren Code produzieren und wesentlich>> komplexere Quelltexte in annehmbarer Zeit verarbeiten. Das kann man>> nutzen - aber nicht mit Turbo Pascal 3.0 unter CP/M.>> Vorsicht! Tubopascal 3.0x war ein hocheffizienter Compiler, deshalb und> wegen seiner integrierten "IDE" war er auf dem 8-Bit Markt nahezu das> Nonplusultra.
Da sag ich nichts gegen.
Aber gegen eine moderne IDE (und sei es Vim + Plugins) auf einem
modernen PC kann TP3 nicht mehr anstinken. Ich bin zum Beispiel ein
großer Fan von Syntax-Highlighting und nutze auch gerne die Maus -
obwohl ich viel auf der Kommandozeile unterwegs bin.
> Gegen die Codequalität dürfte ein SDCC (ich nehme den teilweise auch)> heute noch heftig zu kämpfen haben, trotz des Vielfachen> zur Verfügung stehender Resourcen.
Das bezweifle ich mal äußerst stark.
> Du versuchst hier die Logik von "viel hilft viel" zu propagieren, aber> KISS ist auch nicht schlecht ..eher besser.
Nein, ich möchte nicht "viel hilft viel" propagieren.
Ich möchte darauf hinweisen, dass die Welt sich weitergedreht hat und
man nicht alles, was zwischenzeitlich entstanden ist, abwerten muss.
Einiges ist deutlich besser als alles, was es vorher gab. Nicht alles.
soul e. schrieb:>> Es gibt zwei nennenswerte offene C-Compiler für den Z80, und zwar SDCC>> und Z88DK. Weitere Compiler gibt es zwar, aber die sind in aller Regel>> tot.>> Für tote Controller nimmt man tote Compiler.> https://www.bdsoft.com/resources/bdsc.html
So tot ist der Z80 auch nicht.
georg schrieb:>> Wenn der Compiler nicht in 56 KB RAM und 4 MHz gequetscht werden muss,>> kann er wesentlich effizienteren Code produzieren>> Das ist sowieso ein grundlegender Irrtum. Der erzeugte Code soll auf Z80> laufen, nicht der Compiler!
Sag ich ja. ;-)
Aber wenn man BDS-C oder TP3 propagiert, dann laufen die nunmal unter
CP/M auf einem Z80 - mit allen Einschränkungen.
Sicher, man kann die auch in einen Z80-Emulator stecken, aber das ändert
nichts am Ergebnis.
> Der eZ80-Compiler läuft bei mir auf einem Intel I5 unter Windows 10,
Mit dem eZ80-Compiler habe ich mich ehrlich gesagt noch nie beschäftigt.
Keine Ahnung, was der kann oder wie fähig er ist.
> Und selbst meine Z80-Steuerungen hatten 256k Ram,> nur so nebenbei bemerkt.
Und damit zwingend eine Banking-Logik, also entweder CP/M 3 oder
handgestrickte Software, die damit umgehen konnte. ;-)
S. R. schrieb:> Und damit zwingend eine Banking-Logik, also entweder CP/M 3 oder> handgestrickte Software, die damit umgehen konnte. ;-)
Und was ist daran so lächerlich?
Georg
Stefanus F. schrieb:> Ist hier der Senioren-Stammtisch?
Es ist doch für uns alte Knacker von unschätzbarem Wert, wenn uns User
wie S.R. erklären, dass alles was wir damals programmiert haben garnicht
funktionieren kann. Wenn wir das nur damals schon gewusst hätten, wir
hätten doch niemals Z80-Systeme entwickelt und die Geschichte wäre
anders verlaufen.
Nur gut dass meine Kunden in der Autoindustrie nie draufgekommen sind,
dass die Steuerungen ihrer Messmaschinen garnicht funktionieren. Da habe
ich wohl nochmal Glück gehabt.
Georg
S. R. schrieb:> Holm T. schrieb:>>> Aber nicht alles, was einen Z80 enthält, ist Retro. Mein Board ist es>>> definitiv nicht (da ist ein AVR als Support-Prozessor mit drauf).>>>> Jaa.. der unsägliche Erpom-Emulator... weil man heute glaubt die>> Hardware irgendwie an den Haaren aus dem Sumpf ziehen zu müssen.>> Erklär mal bitte, was du damit meinst?
Na ein AVR der aus seinem Flash bootet, einen Urlader ins RAM des Z80
schreibt und den loslaufen läßt. Der AVR gerne noch mit einer Art
Debugger mit dem man den RAM des Z80 angucken und ändern kann.
Das meine ich.
>>> Eproms brennen kann Keiner mehr, der Promer wird ja>> von Windows10 nicht mehr unterstützt...oder so.>> Bei mir liegen weder Brenner noch EPROMs rum. Sicher, ein paar alte> BIOS-Bausteine (5V-Flash) habe ich noch und die kommen da auch noch> rein.>>>> Und ich habe auch nicht unbedingt große Lust, mich mit allen>>> Einschränkungen damaliger Technik rumzuschlagen.>> Die da wären?>> Begrenzt zuverlässige Hardware, aufwändiges Bootstrapping,> Speichermangel, primitive Hardware (geringe Auflösung, keine Grafik,> keine Farbe), etc.
Entschuldigung diese Argumente sind allesamt Unfug. Weder ein Z80 noch
ein AVR sind unzuverlässig oder haben Grafik. Es würde mich auch tüchtig
nerven wenn z.B jedes "Blinkersteuergerät" in einem Auto Grafik hätte.
>> Ich bin nicht mit CP/M groß geworden und die damalige Software war etwas> weniger ausführlich, was Fehler oder Hilfestellungen betrifft. Dafür gab> es Bedienungsanleitungen und Bücher - aber die muss man sich auch> erstmal besorgen, lesen und verstehen.
Naja. Microsoft mach heute noch Software die trotz Onlinehilfe und Web
einfach nicht zu verstehen ist...
>>> Hier ging es um eine Embedded Anwendung ..oder genauer nur um den>> Versuch einer Spielerei.>> Eben. Da muss man nicht feste Retro-Regeln ansetzen. :-)
Die muß man überhaupt nicht setzen, Regeln sind hier ausnahmsweise gar
nicht notwendig.
>>>> Man kann mit heutigen Mitteln (und heutigem Wissen) aus damaliger>>> Technik wesentlich mehr rausholen, als man damals für möglich gehalten>>> hätte. Beispiel: SymbOS (www.symbos.de). Find ich auch super.>>>> Das ist doch eher sehr spezielle Hardware und die Besonderheit liegt>> hier nicht im Z80.>> Darum ging es nicht. Es ging darum, dass dieses System auf dieser> Hardware in den 80ern schlicht unmöglich gewesen wäre. Nicht, weil die> Technik das nicht konnte (sie kann es nachweislich ja), sondern weil die> Menschen es nicht konnten.
Entschuldige bitte, Du verdrehst hier was. Das was Menschen in diesem
Zeitraum so entwickelt haben, Supersclare, massiv parallele Rechner z.B,
Unix Betriebssysteme oder von mir aus auch VMS, Grafikworkstations, VR
usw. beeindruckt mich deutlich mehr als dieses Computerspiel SymbOS. Das
nämlich ist zu Nichts gut, es ist eine Designstudie auf alter Hardware,
oft noch übertaktet und soll zeigen was auf so einer Kiste machbar ist,
nützlich ist es aber nicht.
>>>> Wenn der Compiler nicht in 56 KB RAM und 4 MHz gequetscht werden muss,>>> kann er wesentlich effizienteren Code produzieren und wesentlich>>> komplexere Quelltexte in annehmbarer Zeit verarbeiten. Das kann man>>> nutzen - aber nicht mit Turbo Pascal 3.0 unter CP/M.>>>> Vorsicht! Tubopascal 3.0x war ein hocheffizienter Compiler, deshalb und>> wegen seiner integrierten "IDE" war er auf dem 8-Bit Markt nahezu das>> Nonplusultra.>> Da sag ich nichts gegen.>> Aber gegen eine moderne IDE (und sei es Vim + Plugins) auf einem> modernen PC kann TP3 nicht mehr anstinken. Ich bin zum Beispiel ein> großer Fan von Syntax-Highlighting und nutze auch gerne die Maus -> obwohl ich viel auf der Kommandozeile unterwegs bin.
Meine IDE ist auch vi samt make, Leute könne nicht verstehen wieso was
Buntes, wenn es geht noch auf VisualC++ basierend nicht besser ist.
Kann ich einfach sagen: Ich brauche damit nur maximal ein viertel der
Zeit wie fürs Klicken im Bunten.
>>> Gegen die Codequalität dürfte ein SDCC (ich nehme den teilweise auch)>> heute noch heftig zu kämpfen haben, trotz des Vielfachen>> zur Verfügung stehender Resourcen.>> Das bezweifle ich mal äußerst stark.
Warum? Ich rede hier nicht vom SDCC als Solchem, sondern speziell von
dem von ihm generierten Z80 Code. Als der Z80 seine Hoch-Zeit hatte (hat
nicht geheiratet) gabs keinen SDCC und als der SDCC dann endlich raus
kam, redete kaum einer vom Z80. Warum denkst Du das genau in diese
Personality übermäßig viel Manpower geflossen ist?
BTW: C-Quellen eines brauchbaren Z8000 Compilers wären mir lieber...
>>> Du versuchst hier die Logik von "viel hilft viel" zu propagieren, aber>> KISS ist auch nicht schlecht ..eher besser.>> Nein, ich möchte nicht "viel hilft viel" propagieren.> Ich möchte darauf hinweisen, dass die Welt sich weitergedreht hat und> man nicht alles, was zwischenzeitlich entstanden ist, abwerten muss.
Das tue ich weiß Gott nicht. Aber auch Du solltest lernen das neu !=
besser ist.
> Einiges ist deutlich besser als alles, was es vorher gab. Nicht alles.
Es gibt aber auch Besseres das es früher gab verglichen mit dem was es
jetzt Neues gibt.
Hey, da laufen noch DEC-PDP11 in den Steuerungen von Atomkraftwerken.
Mach das mal über diese Zeit mit einem heute modernen PC, gib aber
vorher Bescheid damit ich wegziehen kann.
[..]
>>> Wenn der Compiler nicht in 56 KB RAM und 4 MHz gequetscht werden muss,>>> kann er wesentlich effizienteren Code produzieren>>>> Das ist sowieso ein grundlegender Irrtum. Der erzeugte Code soll auf Z80>> laufen, nicht der Compiler!>> Sag ich ja. ;-)
Ist Beides richtig. ein Bisschen Kopffreiheit schadet keinem Compiler,
deswegen ist ja Cross-Development nicht sooo neu.
[..]
>>> Der eZ80-Compiler läuft bei mir auf einem Intel I5 unter Windows 10,
...riesiges Hindernis. Ich mag kein OS das meine Daten woanders hin
schaufelt oder gar verschwinden läßt.
>> Mit dem eZ80-Compiler habe ich mich ehrlich gesagt noch nie beschäftigt.> Keine Ahnung, was der kann oder wie fähig er ist.>>> Und selbst meine Z80-Steuerungen hatten 256k Ram,>> nur so nebenbei bemerkt.>> Und damit zwingend eine Banking-Logik, also entweder CP/M 3 oder> handgestrickte Software, die damit umgehen konnte. ;-)
Naja..nichts dagegen zu sagen. Eine "Intel Management Engine" mit
genauso viel Sicherheitslöchern wie Features und möchtegern USB
Schnittstelle ist noch viel mieser als das.
Gruß, auch vom A20 Gate,
Holm
georg schrieb:> Es ist doch für uns alte Knacker von unschätzbarem Wert, wenn uns User> wie S.R. erklären, dass alles was wir damals programmiert haben garnicht> funktionieren kann.
Es ist vielmehr von unschätzbarem Wert, dass User wie S.R. noch heute
recht interessante CP/M Systeme [1] entwerfen, aufbauen und auch zu
laufen bringen :-)
Georg, manchmal ist es vor der Kritik hilfreich sich mit dem Hintergrund
des jeweiligen Users auseinander zu setzen.
[1] Beitrag "Re: eigenes Z80 Mainboard - geht das so?"
S. R. schrieb:> primitive Hardware (geringe Auflösung, keine Grafik
Das wusste ich damals natürlich auch nicht, so habe ich in meinem
jugendlichen Leichtsinn auf meinen Steuerungen doch tatsächlich Grafik
angezeigt, siehe Bildschirmfoto.
Durch einen Grafikprozessor war die Grafik deutlich schneller als die
damals übliche CGA- oder Herkulesgrafik auf PC.
Joe G. schrieb:> Georg, manchmal ist es vor der Kritik hilfreich sich mit dem Hintergrund> des jeweiligen Users auseinander zu setzen.
Was für Hintergrund? Er hat weder Ahnung vom Programmieren noch von
Hardware.
Georg
georg schrieb:> Und was ist daran so lächerlich?
Daran ist nichts lächerlich. Wieso fragst du?
georg schrieb:> Es ist doch für uns alte Knacker von unschätzbarem Wert, wenn uns User> wie S.R. erklären, dass alles was wir damals programmiert haben garnicht> funktionieren kann.
Wie kommst du denn auf den Gedanken?
Rauchst du heimlich? Und wenn ja, was?
Holm T. schrieb:>> Erklär mal bitte, was du damit meinst?>> Na ein AVR der aus seinem Flash bootet, einen Urlader ins RAM des Z80> schreibt und den loslaufen läßt. Der AVR gerne noch mit einer Art> Debugger mit dem man den RAM des Z80 angucken und ändern kann.
Achso, ja. Genau so habe ich das gemacht. :-)
Hat den Vorteil, dass man den Urlader genauso entwickeln kann wie die
restliche Software (in einer vertrauten Umgebung mit schnellen
Testzyklen).
>> Begrenzt zuverlässige Hardware, aufwändiges Bootstrapping,>> Speichermangel, primitive Hardware (geringe Auflösung, keine Grafik,>> keine Farbe), etc.>> Entschuldigung diese Argumente sind allesamt Unfug. Weder ein Z80 noch> ein AVR sind unzuverlässig oder haben Grafik. Es würde mich auch tüchtig> nerven wenn z.B jedes "Blinkersteuergerät" in einem Auto Grafik hätte.
Naja, die üblichen (mir bekannten zeitgenössischen) CP/M-Systeme nutzen
Disketten, keine Grafik und keine Farben. Das ist die Umgebung, in der
TP3 läuft. Auf so einem System macht mir die Entwicklung potentiell
weniger Spaß als auf meinem Linux.
Zumal ich Delphi seit der Schulzeit nicht mehr angefasst habe und
erstmal klassisches Pascal sowie TP3 im Speziellen lernen müsste, um
damit zu arbeiten.
> Das was Menschen in diesem Zeitraum so entwickelt haben, [...]> beeindruckt mich deutlich mehr als dieses Computerspiel SymbOS.
Vor gut 30 Jahren hätte es dich vermutlich mehr beeindruckt.
Schade, dass du es heute so leicht wegwischst.
> Das nämlich ist zu Nichts gut, es ist eine Designstudie auf> alter Hardware, oft noch übertaktet und soll zeigen was auf> so einer Kiste machbar ist, nützlich ist es aber nicht.
Nichts, was man auf so alter Hardware zum Spaß macht, ist nützlich.
Absolut garnichts. Das ist eine Eigenschaft vieler Hobbies.
> Warum? Ich rede hier nicht vom SDCC als Solchem, sondern speziell von> dem von ihm generierten Z80 Code.
Naja, Z80 ist eins der besser unterstützten Targets vom SDCC. Der
Register-Allokator ist nachweislich optimal (für lange Compilezeit) und
die Target-unabhängigen Optimierungen sind auch schön.
> Als der Z80 seine Hoch-Zeit hatte (hat> nicht geheiratet) gabs keinen SDCC und als der SDCC dann endlich raus> kam, redete kaum einer vom Z80. Warum denkst Du das genau in diese> Personality übermäßig viel Manpower geflossen ist?
Weil der Z80 eine eher einfache, recht fähige und extrem weit
verbreitete Architektur ist. Außerdem ist er - wie der 8051 - nicht
totzukriegen.
Laut SDCC-Webseite (jaja...) ist er definitiv mindestens auf dem
gleichen Niveau wie alle anderen C-Compiler für den Z80 auch, kann dafür
aber einen Teil von C11 usw.
> Aber auch Du solltest lernen das neu != besser ist.
Das weiß ich schon.
Aber aus "neu != besser" folgt nicht "alt == besser".
>> Einiges ist deutlich besser als alles, was es>> vorher gab. Nicht alles.> Es gibt aber auch Besseres das es früher gab verglichen> mit dem was es jetzt Neues gibt.
Logisch. Aber deswegen muss man das, was heute neu ist, trotzdem nicht
verteufeln.
Besser ist besser. Unabhängig von der Zeit.
> Naja..nichts dagegen zu sagen. Eine "Intel Management Engine" mit> genauso viel Sicherheitslöchern wie Features und möchtegern USB> Schnittstelle ist noch viel mieser als das.
An der Uni haben wir mit Epiphany und RISC-V gearbeitet.
Jetzt habe ich mit Qualcomm-Chipsätzen zu tun, dagegen ist die "Intel
Management Engine" ein Witz.
Gruß
georg schrieb:> Das wusste ich damals natürlich auch nicht, so habe ich in meinem> jugendlichen Leichtsinn auf meinen Steuerungen doch tatsächlich Grafik> angezeigt, siehe Bildschirmfoto.
Und natürlich kann TP3 damit umgehen.
Oh Mann, hier ist dein Preis für bösartiges, sinnentstellendes Zitieren.
Gratuliere.
Holm T. schrieb:>> Ist hier der Senioren-Stammtisch?> Gegenfrage: hättest Du was dagegen?
Nein keineswegs. Je älter ich werde, umso lustiger finde ich andere alte
Männer. Und da ich deutlich über 40 bin, bin ich jetzt auch endlich in
der Altersgruppe, wo man mitreden darf.
S. R. schrieb:
[..]
>> Holm T. schrieb:>>> Erklär mal bitte, was du damit meinst?>>>> Na ein AVR der aus seinem Flash bootet, einen Urlader ins RAM des Z80>> schreibt und den loslaufen läßt. Der AVR gerne noch mit einer Art>> Debugger mit dem man den RAM des Z80 angucken und ändern kann.>> Achso, ja. Genau so habe ich das gemacht. :-)> Hat den Vorteil, dass man den Urlader genauso entwickeln kann wie die> restliche Software (in einer vertrauten Umgebung mit schnellen> Testzyklen).
Auch georg wird darüber nur müde schmunzeln.
Das ist die Arbeitsweise eines AVR Freaks. Verstehe mich richtig. ich
baue auch einen Röhrenverstärker und setze da dann eine
Gleichrichterröhre ein.
Kommentare dazu sind dann in der Richtung "warum nimmst Du keine Dioden"
usw. ...weil die da nicht hin gehören.
Ein Z80 Rechner braucht keinen genauso leistungsfähigen Mikro als
"Consolen Rechner", das kann der selber. Wie hatte ich hscon oben
beschrieben, man nimmt entweder einen Monitor im Eprom der u.U auch
assemblieren/disassemblieren, sowie z.B. Intel Hex hochladen,
Einzelschritt usw. kann, oder aber nur einen Urlader den man dann nicht
ändert.
Du machst im Prinzip das Selbe, nur hast Du die Funktionalität in den
AVR ausgelagert. Es ist naheliegend, aber nicht clever.
>>>> Begrenzt zuverlässige Hardware, aufwändiges Bootstrapping,>>> Speichermangel, primitive Hardware (geringe Auflösung, keine Grafik,>>> keine Farbe), etc.>>>> Entschuldigung diese Argumente sind allesamt Unfug. Weder ein Z80 noch>> ein AVR sind unzuverlässig oder haben Grafik. Es würde mich auch tüchtig>> nerven wenn z.B jedes "Blinkersteuergerät" in einem Auto Grafik hätte.>> Naja, die üblichen (mir bekannten zeitgenössischen) CP/M-Systeme nutzen> Disketten, keine Grafik und keine Farben. Das ist die Umgebung, in der> TP3 läuft. Auf so einem System macht mir die Entwicklung potentiell> weniger Spaß als auf meinem Linux.
Neben mir steht ein CP/M2.2 System ohne Grafik, mit Festplatte.
Mein Rechner zu DDR Zeiten hatte 3 Floppies und eine 512x256
Monochromgrafik (WPU AS86/1). Farbe hatte der damalige nicht und der
jetzt hier auch nicht..weil mich nichts dahin zieht. Dafür hat der
jetzige ne Netzwerkschnittstelle und kann Daten über FTP und Telnet
austauschen.
Grafik braucht auf so einem Ding kein Schwein, das kann jeder PC besser,
aber mal irgend eine Hardware dranhängen und mit rigendwelchen Signalen
spielen, das kann die CP/M Kiste besser.
>> Zumal ich Delphi seit der Schulzeit nicht mehr angefasst habe und> erstmal klassisches Pascal sowie TP3 im Speziellen lernen müsste, um> damit zu arbeiten.
Hmpf. Ich mache schon lange kein Pascal mehr und C muß man nicht
umlernen.
>>> Das was Menschen in diesem Zeitraum so entwickelt haben, [...]>> beeindruckt mich deutlich mehr als dieses Computerspiel SymbOS.>> Vor gut 30 Jahren hätte es dich vermutlich mehr beeindruckt.> Schade, dass du es heute so leicht wegwischst.
Nein, 1990 gabs das Ding so nicht und mich haben da auch Rechner mit
größeren Bitbreiten interessiert, da habe ich auf SM1420 und K1840
herumgespielt, in den 90ern ging das dann mit HP Workstations, SGI und
Convex Rechnern weiter :-)
>>> Das nämlich ist zu Nichts gut, es ist eine Designstudie auf>> alter Hardware, oft noch übertaktet und soll zeigen was auf>> so einer Kiste machbar ist, nützlich ist es aber nicht.>> Nichts, was man auf so alter Hardware zum Spaß macht, ist nützlich.> Absolut garnichts. Das ist eine Eigenschaft vieler Hobbies.
Aber man kann oft das Angenehme mit dem Nützlichen Verbinden.
Die CP/M Mühlen mit denen ich zu tun habe (K1520 Systeme) haben
Bussysteme die es möglich machen Peripherie nach Bedarf nachzurüsten. Ob
nun ADU Karten oder Parallele Peripherie..liegt mehr oder weniger alles
herum.
Damit kann man schon was anfangen, natürlich entsteht da heute kein
Produkt mehr draus.
>>> Warum? Ich rede hier nicht vom SDCC als Solchem, sondern speziell von>> dem von ihm generierten Z80 Code.>> Naja, Z80 ist eins der besser unterstützten Targets vom SDCC. Der> Register-Allokator ist nachweislich optimal (für lange Compilezeit) und> die Target-unabhängigen Optimierungen sind auch schön.
Mag sein. Bei meinen letzten Experimenten in dieser Richtung hab ichs
dann lieber in Assembler neu geschrieben, war mir zu lang.
>> Weil der Z80 eine eher einfache, recht fähige und extrem weit> verbreitete Architektur ist. Außerdem ist er - wie der 8051 - nicht> totzukriegen.>
Das schireb ich obe nschon selber, aber: er hat nicht gerade eine für
Compiler ideale Registerstruktur.
> Laut SDCC-Webseite (jaja...) ist er definitiv mindestens auf dem> gleichen Niveau wie alle anderen C-Compiler für den Z80 auch, kann dafür> aber einen Teil von C11 usw.>>> Aber auch Du solltest lernen das neu != besser ist.>> Das weiß ich schon.> Aber aus "neu != besser" folgt nicht "alt == besser".
Nein, man sollte den Vergleich lieber gar nicht erst bringen, weil er in
beiden Richtungen nicht sinnvoll ist.
[..]
>> mit dem was es jetzt Neues gibt.>> Logisch. Aber deswegen muss man das, was heute neu ist, trotzdem nicht> verteufeln.
Tue ich das? Mein Geschmack ist anders als der des Mainstreams, aber
mit sicherheit nicht altmodisch.
>> Besser ist besser. Unabhängig von der Zeit.
Hab ich gerade gesagt.
>>> Naja..nichts dagegen zu sagen. Eine "Intel Management Engine" mit>> genauso viel Sicherheitslöchern wie Features und möchtegern USB>> Schnittstelle ist noch viel mieser als das.>> An der Uni haben wir mit Epiphany und RISC-V gearbeitet.> Jetzt habe ich mit Qualcomm-Chipsätzen zu tun, dagegen ist die "Intel> Management Engine" ein Witz.>> Gruß
Hab ich nicht, 1. Bin ich seit 98 nicht mehr an einer Uni und 2. fehlt
mir die Zeit. Wenn ich mal Zeit habe nehme ich endlich mal die hier
rumliegenden Bitslices in die Hand und baue mir meine CPU selber.
Gruß,
Holm
Toni schrieb:> KAnn ich einen Z80 mit RAM und ROM und PIO genauso wie einen AVR nuzen?
Nein, natürlich nicht. Du kannst das Z80-System zwar als µC
abstrahieren, musst aber auch dann mit dem leben, was dieser
abstrahierte µC halt besitzt.
Scheinbar schonmal keine SIO und kein EEPROM, also schonmal kein UART in
Hardware und keine persistenten Konfigurationsdaten. Vermutlich wird's
auch beim Thema "Timer" etwas eng. Und auch für sonstige Peripherie, die
man heutzutage so auf einem AVR8 finden kann...
> Also kann ich den in C oder Pascal programmieren und das.bin File> einfach aufs EEprom packen
Das ganz sicher nicht. Bestenfalls kannst du es in den "ROM" packen.
Aber natürlich nur dann, wenn dieser nicht wirklich ROM, sondern
programmierbar ist. Also Flash oder E(E)PROM.
> oder geht das nur wenn Dos vorhanden ist?
DOS hat damit exakt nullkommagarnix zu tun.
Stefanus F. schrieb:> Holm T. schrieb:>>> Ist hier der Senioren-Stammtisch?>> Gegenfrage: hättest Du was dagegen?>> Nein keineswegs. Je älter ich werde, umso lustiger finde ich andere alte> Männer. Und da ich deutlich über 40 bin, bin ich jetzt auch endlich in> der Altersgruppe, wo man mitreden darf.
:-)
Die Bank ist aber voll, da wirst Du Jungspund noch ne Weile stehen
müssen ...
Gruß,
Holm
Holm T. schrieb:> Auch georg wird darüber nur müde schmunzeln.
Ich habe verstanden, was georg von mir hält.
War ja deutlich genug.
> Ein Z80 Rechner braucht keinen genauso leistungsfähigen Mikro als> "Consolen Rechner", das kann der selber.
Das ist mir schon klar, allerdings weiß ich, wie man eine AVR-UART
benutzt (einen SIO-Chip besitze ich nichtmal). Einen KC85 hab ich zwar
mal in HC-BASIC programmiert, aber das ist keine Grundlage, um eine
komplett neue Cross-Toolchain aufzubauen und zu testen. Dazu kommt, dass
ich weder EPROMs noch Brenner da habe.
> Wie hatte ich hscon oben beschrieben, man nimmt entweder> einen Monitor im Eprom der u.U auch assemblieren/disassemblieren,
Ich hatte weder einen passenden Monitor vorrätig, noch EPROM oder
Brenner. Und selbst wenn ich mir eins der Programme aus dem Internet
gegriffen hätte, hätte ich es weder hinreichend verstanden noch "mal
eben so" anpassen können. Inzwischen sieht das anders aus.
> sowie z.B. Intel Hex hochladen, Einzelschritt usw. kann,> oder aber nur einen Urlader den man dann nicht ändert.
Den muss man aber erstmal haben und verstehen. Und irgendwie in den Chip
reinbekommen. Das ist alles Wissen, was man nicht aus dem Stand kriegt,
und zuviele Baustellen auf einmal garantieren in erster Linie nur, dass
das Projekt fehlschlägt.
> Du machst im Prinzip das Selbe, nur hast Du die Funktionalität in den> AVR ausgelagert. Es ist naheliegend, aber nicht clever.
Es baut auf den bereits vorhandenen Fähig- und Fertigkeiten auf und hat
mir eine Menge Stress erspart. Die nächste Runde - auf Basis TMPZ84C015
- kommt ohne AVR aus. Aber dafür muss ich eine Platine machen.
> Neben mir steht ein CP/M2.2 System ohne Grafik, mit Festplatte.
Neben mir im Schrank ein i486SX mit 40 MB Festplatte und DOS. Das ist
die Welt, in der ich groß geworden bin... und schon die war historisch.
> Grafik braucht auf so einem Ding kein Schwein, das kann jeder PC besser,> aber mal irgend eine Hardware dranhängen und mit rigendwelchen Signalen> spielen, das kann die CP/M Kiste besser.
Eben. Und weil mein PC so ca. 1 bis 2 Megapixel darstellen kann, kann
ich damit auch mehrere Texte gleichzeitig anschauen. Handbuch und
Quellcode zum Beispiel.
> Hmpf. Ich mache schon lange kein Pascal mehr und C muß man nicht> umlernen.
Für BDS-C, Aztec oder Small-C schon.
Die sprechen nicht gerade ANSI-C, und C99 schonmal garnicht.
> Nein, 1990 gabs das Ding so nicht und mich haben da auch Rechner mit> größeren Bitbreiten interessiert, da habe ich auf SM1420 und K1840> herumgespielt, in den 90ern ging das dann mit HP Workstations, SGI und> Convex Rechnern weiter :-)
Mit solchen Systemen bin ich nie in Berührung gekommen. Die gab es in
meiner Welt schlicht nicht - auch nicht in der Welt meiner Eltern oder
Großeltern.
>> Weil der Z80 eine eher einfache, recht fähige und extrem weit>> verbreitete Architektur ist. Außerdem ist er - wie der 8051 - nicht>> totzukriegen.>>> Das schireb ich obe nschon selber, aber: er hat nicht gerade eine für> Compiler ideale Registerstruktur.
Das stimmt allerdings, betrifft aber alle Compiler - nicht nur SDCC.
Und ich kann mir gut vorstellen, dass der damit noch eher klarkommt als
die Systeme, die auf dem Z80 selbst laufen müssen.
>> Logisch. Aber deswegen muss man das, was heute neu ist,>> trotzdem nicht verteufeln.>> Tue ich das? Mein Geschmack ist anders als der des Mainstreams, aber> mit sicherheit nicht altmodisch.
Naja, manchmal hat man schon das Gefühl.
Ich bin nicht erst seit gestern hier im Forum unterwegs. :-)
> Hab ich nicht, 1. Bin ich seit 98 nicht mehr an einer Uni und 2. fehlt> mir die Zeit. Wenn ich mal Zeit habe nehme ich endlich mal die hier> rumliegenden Bitslices in die Hand und baue mir meine CPU selber.
Habe ich auch noch vor - aber in VHDL und für FPGAs.
Apropros, kennst du
https://www.youtube.com/playlist?list=PLEeZWGE3PwbansoxKjjMKHQqS_2cm8i60
? Der baut einen RISC-V ohne FPGA nach.
Rufus Τ. F. schrieb:> Das im Zusammenhang mit "modernen Geschichten" zu erwähnen ist aber auch> ... Lustig.
im Gegensatz zu z80 oder 6502 passte das aber :)
Da war der LH5803 eben moderner, ich meinte ja nur den AHA Effekt als
man einiges im ASM Befehlssatz und an Register wiedererkannte.
Rufus Τ. F. schrieb:> (ich hab' für das> Ding mal eine handgeklöppelte Druckausgabefunktion geschrieben, weil> das, was das eingebaute Basic mit dem Parallelinterface machte,> unglaublich langsam war, und das war vor etwa 35 Jahren).
und ich ein ASAVE(statt CSAVE) und ALOAD(statt CLOAD) im EEPROM über
eine 65C22 zum apple2 auf Disk.
mich nervte die Cassettenspeicherung, auch handgeklöppelt auf
Karopapier, weil da noch ohne Assembler.
leider zwar nicht wirklich gut, da auch Themenfragen und Antworten
sinnloserweise gelöscht wurden. und Herr Holf nur teilweise entfernt
wurde trotz unpassender Bemerkungen..aber immerhin ein Anfang, das nicht
immer die Beiträge die als Reaktion auf blöde Kommentare erfolgt sind,
sondern auch die Beiträge entfernt wurden, die überhaupt erst die
Stimmung angeheizt habe..
geht doch..wenn dei Monds jetzt noch lernen das GASt GAst ist, völlig
wurscht welcher Name davor steht und das mehrer Namen nichts schlimmes
sind, solange kein vorgetäuschter Dialog stattfindet der womöglich
gezielt für Unruhe sorgt..sondern lediglich dadurch entsteht das man mit
einem anderen Browser, oder Laptop etc auf den Threat erneut
antwortet..dann hätten die Mods..wieder etwas mehr gelernt...aber wie
gesagt..dennoch ein Fortschritt...geht doch!
..meine "unpassenden" Bemerkungen wirst Du nicht los werden so lange Du
"unpassendes" Zeug behauptest und postest.
Du bist hier der absolute Obermacker der sogar glaubt die Mods darüber
aufklären zu müssen wie Nutzernamen zu handhaben
seien..unglaublich..blond.
Gruß,
Holm
Hmmm....
also mein Z80 Klunker ist voll in C programmiert, verhält sich wie ein
kleiner PC und arbeitet mit einem eigenen Basis System, ncurses VT100
Interface von Frank (UKW) und der Dump Editor. Nicht ganz trivial aber
sehr komfortabel mit geany zu programmieren, komplett unter Linux
erstellt alles.
Läuft bis heute noch......
Christian
> Ist hier der Senioren-Stammtisch?
Nö.
Die Jugend ist noch hier.
Toni / Thomas, gibts Dich noch?
Hast Du das Intresse an Assembler und C und den Z80
trotz des Hasen - und Igel - Kampfes hier
bereits verloren?
mfg
@Christian J.
Drein Projekt hatte ich damals mit Interesse verfolgt.
Und kann mich noch daran erinnern wie hier wieder die traurigen
gestalten sich aufgespielt hatten, als Du weiße Platinen gesucht hattest
für das Projekt, und als es dann plötzlich fertig war..waren sie
plötzlich still geworden;-)
nein alles gut.
Holm nervt nur etwas..
Das Thema ist für mich auch beantwortet...
Es funktioniert nicht so wie von mir gedacht.
Dann kann ich auch meinen Z80 Schneider CPC6128 progammieren in was auch
immer und die externen Ports nutzen.
Evtl sehe ich mal SDCC an, aber alles wo ich mich erst lange reinfuchsen
müsste fehlt mir die Zeit.
Hatte gerade nur noch mal nach dem Faden hier gesucht.
Ich verfolge ihn aber nicht mehr aktiv.
Danke den die hilfreich waren.
und HErr Holm..Dich frage ich hier nicht..auch wenn Du offenbar wissen
dazu hast, interessiert mich deine Meinung wundersamer weise
nicht...Also spar dir deine Luft bevor Du noch mit einem Herzkasper
umkippst
Thread beobachten
Seitenaufteilung abschalten