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?
:
Gesperrt durch Moderator
Welches EEPROM? Der Z80 hat keines an Bord. Und was hat DOS mit Z80 zu tun? Der Z80 ist ein MikroPROZESSOR. Die AVRs sind MikroCONTROLLER.
Das Eeprom das ich anschließe!?!? "Der Z80 ist ein MikroPROZESSOR. Die AVRs sind MikroCONTROLLER."# Ach ne...deshlab frage ich ja?!?
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
Einen Vorteil hast du aber. Es lässt sich recht einfach ein Simulator für dein vorhandenes System zusammenbauen.
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.
:
Bearbeitet durch User
Turbopascal unter CP/M brauchte aber BIOS-Funktionen. Prog nach 0x0100 laden sollte noch gehen aber IO wird wohl nur mit einigem Aufwand gehen.
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: > Aber wenn man den Z80 mit heutiger Technologie nochmal bauen würde, > so dass er mit 24MHz oder so laufen würde, Gibts doch, von Zilog.
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
:
Bearbeitet durch User
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
so hätte ich mir einen Beispielcode vorgestellt..mit SIO Chip
1 | Program Test; |
2 | const BA = $3F8; |
3 | |
4 | Begin |
5 | Port [BA+4] := 1; //LED an DTR einschalten |
6 | delay(1000); |
7 | Port[BA+4]:=0; //LED an DTR ausschalten |
8 | delay(1000); |
9 | end; |
:
Bearbeitet durch User
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 ;-)
vielleicht habe ich da gerade was passendes gefunden :-) Making 8-bit Arcade Games in C (English Edition) https://www.amazon.de/Making-8-bit-Arcade-Games-English-ebook/dp/B072583N1Y/ref=sr_1_2?ie=UTF8&qid=1545214112&sr=8-2&keywords=z80 Wobei es mir ja eher um grundlegenderes wie LED Blinken geht..gar nicht um die Ansteuerung eines Bildschirms etc
:
Bearbeitet durch User
ich werde die Tage mal in der Bibliothek der FH schauen, was es da zum Z80 so gibt
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.
"RAM Verwaltung" ist halt ein sehr schwammiger Begriff, den jeder anders versteht.
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.
:
Gelöscht durch Moderator
Moin, - ich werfe einmal den Z80-MBC2 in den Ring. Ein Z80 CPU, 128K RAM, einen ATMega32A zur Steuerung. Massenspeicher ist 2 x 24LC1025. https://hackaday.io/project/19000-a-4-4ics-z80-homemade-computer-on-breadboard https://github.com/SuperFabius/Z80-MBC Die Z80 CPU laeuft mit 4 MHz, CP/M geht (schnell ist was anderes), Laufwerk A und B haben ja jeweils 128kB. Turbo-Pascal 3 unter CP/M funktioniert. Ist halt Stand der Technik 1984. Viele Gruesse Th.
Toni schrieb: > Also kann ich den in C oder Pascal programmieren und das.bin File > einfach aufs EEprom packen, Ja, mit SDCC [1] [1] http://sdcc.sourceforge.net/
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.
Wenn du unbedingt Turbo Pascal auf einem AVR laufen lassen möchtest, dann nimmst du dieses System [1] [1] https://www.mikrocontroller.net/articles/AVR_CP/M
Es geht um Z80 nicht AVR... Für AVR gibte s genug Pascal derivate..die gängigsten da wohl wären Mikroe PAscal und elab
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
:
Gelöscht durch Moderator
@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;
Thomas M. schrieb: > .einfach sowas schreiben um über das angeschlossene SIO IC eine LEX zu > schalten? Eine LEX?
"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: > der 8080 ist Z80 kompatibel und umgekehrt Nein. Z80 kann 8080-Code ausführen, 8080 aber kann keinen Z80-Code ausführen.
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?
oder diesem PAscal https://github.com/daar/z80-pascal oder diesem http://forum.lazarus.freepascal.org/index.php?topic=12219.0
achne..zdev ist ein assmbler..aber ach vom Freepsacal gibt es eine Z80 Version die noch nicht perfekt ist
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
kann Herr holm einfach mal die Fresse halten und sich raushalten..das mit der Kmpatibilität wurde bereits geklärt Du Blitzmerker
:
Gelöscht durch User
@georg (Gast) danke..denn ich habe nicht verstanden weshalb immer wieder gesagt wird..weshalb es mit PAscal nicht ginge
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.
1 | ... |
2 | |
3 | ;------------------------------------------------------------------------ |
4 | |
5 | read dec c |
6 | call expr ; Eingabe Offset |
7 | ld hl, msg0 |
8 | call str |
9 | call crlf |
10 | red0 call ci |
11 | cp ":" |
12 | jr nz,red0 ; warten auf ":" |
13 | xor a |
14 | ld d,a |
15 | call ibyte ; Recordlaenge |
16 | jr z,red3 ; Recordlaenge = 0 |
17 | ld e,a |
18 | call ibyte ; Recordadresse |
19 | ld h,a |
20 | call ibyte |
21 | ld l,a |
22 | call ibyte ; Datentyp |
23 | ld c,e |
24 | push hl |
25 | ld hl,0ff00h |
26 | add hl,sp |
27 | red1 call ibyte ; Information lesen |
28 | ld (hl),a |
29 | inc hl |
30 | dec e |
31 | jr nz,red1 |
32 | call ibyte ; Checksumme |
33 | jp nz,error ; Checksumme falsch |
34 | pop de ; Berechnung Ladeadresse |
35 | ex (sp),hl |
36 | ex de,hl |
37 | add hl,de |
38 | ld b,0 |
39 | add hl,bc |
40 | ex de,hl |
41 | ex (sp),hl ; Laden des gelesenen Records |
42 | red2 dec hl |
43 | dec de |
44 | lddr |
45 | jr red0 |
46 | red3 ld hl,ploc+1 ; Laden der Startadresse |
47 | call ibyte |
48 | ld (hl),a |
49 | inc hl |
50 | call ibyte |
51 | ld (hl),a |
52 | ... |
Gruß, Holm
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
Holm T. (holm) Merkst Du Clown nicht das ich Dich nicht nach Deiner Meinung Frage..
:
Gelöscht durch User
"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 |
22 | - BDS-C.DOC (Etikett) und |
23 | - BDS-C0.DOC (diese Datei). |
..aber das ist ein C-Compiler.. Gruß, Holm
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.
Pirat schrieb: > Weihnachten steht vor der TÜR !!! Und was haben irgendwelche Sektenrituale inhaltlich mit diesem Thread zu tun? Nichts.
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:
1 | ; |
2 | ; ********************** |
3 | ; * PASCAL STAND ALONE * |
4 | ; * OPERATING SYSTEM * |
5 | ; ********************** |
6 | ; |
7 | ; COPYRIGHT RK ELEKTRONIK 1985 |
8 | ; |
9 | ; NOTE : NO FILES ARE USED |
10 | ; NO CP/M SYSTEM |
11 | ; |
12 | .Z80 |
13 | ; |
14 | ; INSTALL IF USED IN PROGRAM : |
15 | ; |
16 | EXTERNAL CONIN,CONOUT,RDRIN |
17 | EXTERNAL PUNOUT,LSTOUT |
18 | EXTERNAL GETIOB,SETIOB,NMISRV |
19 | EXTERNAL CONST,INIT |
20 | ; |
21 | EXTERNAL TOPMEM ;SPACE FOR PASCAL |
22 | ; |
23 | ; FOR EXTERNAL USE: |
24 | ENTRY PRETI,PERETI,PRETN |
25 | ; |
26 | ASEG |
27 | ORG 4000H |
28 | .PHASE 0 |
29 | ; |
30 | JP START |
31 | DEFB 0 |
32 | DEFB 0 |
33 | RST BDSIM |
34 | DEFW TOPMEM |
35 | ; |
Georg Georg
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
Holm T. schrieb: > wieder auftauchen und Statements abgeben ohne gelesen zu haben > ist auch nicht in Ordnung. Stimmt
> 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.
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.
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. ;-)
:
Bearbeitet durch User
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?"
Stefanus F. schrieb: > Ist hier der Senioren-Stammtisch? Gegenfrage: hättest Du was dagegen? Laß uns doch in der Sonne auf der Bank sitzen.. Gruß, Holm
Angehängte Dateien:
-
DSCF0804.JPG
84 KB
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
Angehängte Dateien:
-
DSC08234__1280_x_1024_.jpg
200 KB -
001.png
280 KB -
Bildschirmfoto63.png
56 KB -
DSC08239__1280_x_1024_.jpg
210 KB
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
...sieht aus als wären da immer noch der U880 und der 8255 von mir drauf :-) Gruß, Holm
Angehängte Dateien:
-
DSC08183__1280_x_1024_.jpg
100 KB -
DSC08184__1280_x_1024_.jpg
120 KB
Holm T. schrieb: > No uveren, tovarishch Tiffe! Tol'ko sovetskiye tekhnologii - eto khoroshiye tekhnologii!
> 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
:
Bearbeitet durch User
Beitrag #5668645 wurde von einem Moderator gelöscht.
Beitrag #5669919 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.
Thread beobachten
Seitenaufteilung abschalten