Die Produktion des Z80 wird eingestellt, Zilog wird ab 14. Juni keine Bestellungen mehr entgegennehmen: https://www.mouser.com/PCN/Littelfuse_PCN_Z84C40.pdf
Das sind immerhin beeindruckende 48 Jahre Produktionszeitraum. (dann kann ich meinen Zaks jetzt wohl wegschmeissen).
Philipp Klaus K. schrieb: > Die Produktion des Z80 wird eingestellt, Nicht schlimm, ich hab noch 2. Falls mir jemals noch die Notwendigkeit begegnet, die einsetzen zu müssen. Aber es ist schön, dass CP/M mit allen Hilfsprogrammen inzwischen im Source vorliegt.
Markus F. (mfro) >Das sind immerhin beeindruckende 48 Jahre Produktionszeitraum. Wikipedia schreibt zum Erfolg des Z80: "Der Z80 überflügelte rasch den 8080 und wurde der bisher am weitesten verbreitete 8-Bit-Hauptprozessor (central processing unit, CPU). Wenn man die absolute Größe des Marktes einbezieht, dann ist er der seither erfolgreichste Hauptprozessor überhaupt. " https://de.wikipedia.org/wiki/Zilog_Z80
Philipp Klaus K. schrieb: > Die Produktion des Z80 wird eingestellt Damals(tm) gab es mehrere Second-Source-Hersteller ... ich nehme mal an, daß die sich alle vom Acker gemacht haben.
Markus F. schrieb: > (dann kann ich meinen Zaks jetzt wohl wegschmeissen). Solltest du den nicht langsam auswendig können? Außerdem kann man so einiges darin schon generell anwenden bzw. übertragen.
Hallo Bezüglich der nun mal gegebenen Hintergründe und die lange Geschichte, die ja auch (nur) von Entwicklern und Nutzern geschrieben wurde, ist die Mitteilung von Zilog aber enttäuschend emotionslos und kühl. Etwas Gefühl und Nostalgie vielleicht auch ein Erwähnen der Entwickler und wo alles der Z80 eingesetzt wurde und wird, hätte in diesen Fall nicht geschadet. Zurückhaltung und Professionalität kann man auch übertreiben... Edwin
Die Abkündigung bezieht sich doch nur auf den Z84C40? Das ist ein SIO, aber keine CPU.
Ist doch keine Pressemitteilung, sondern eine product change notice. Die läuft immer nach dem gleichen Schema ab.
Christoph M. schrieb: > Martin H. (horo) >>0x76 > > Oh, der ist gut :-) Kann ja immer noch ein Interrupt reinkommen...
Fooji schrieb: > Die Abkündigung bezieht sich doch nur auf den Z84C40? Das ist ein > SIO, > aber keine CPU. Ja, hier ist die Notice für die CPU: https://www.mouser.com/PCN/Littelfuse_PCN_Z84C00.pdf
Veit D. schrieb: > Hallo, > > in die Runde gefragt, was ist mit dem Zilog eZ80? Ist der inkompatibel? Zumindest bezüglich des instruction timing.
Christian M. schrieb: > Wie soll man dann die 40 Jahre alten Aufzüge reparieren? Die werden auf 6502 umgerüstet.
Jörg W. schrieb: > Ist doch keine Pressemitteilung, sondern eine product change > notice. Die > läuft immer nach dem gleichen Schema ab. Und ist offenbar eingescannt. Immerhin nicht gefaxt!
Niklas G. schrieb: > Jörg W. schrieb: >> Ist doch keine Pressemitteilung, sondern eine product change >> notice. Die >> läuft immer nach dem gleichen Schema ab. > > Und ist offenbar eingescannt. Immerhin nicht gefaxt! Die alte Kundschaft wurde per Telex informiert.
Puh, da werden ja meine Stangen an Z80-Komponenten vielleicht mal wertvoll? Ob ich das aber noch erleben darf?
Hallo Hinz! H. H. schrieb: > Die alte Kundschaft wurde per Telex informiert. Telex :) Und in welchen Atomraketen ist der Z80 verbaut?
Wer sich an den alten Mnemonics im Assemblercode erfreuen will, kann ja auf den Rabbit umsteigen. Dessen letzte Reinkarnation schafft 150 MHz Takt, und braucht davon auch nicht unbedingt mehrere Takte bei Simpeloperationen. Es ist also eher so wie mit einem alten Atom Netbook. Ist es entgueltig hinueber, kann man es endlich durch etwas besseres ersetzen.
Motopick schrieb: > Wer sich an den alten Mnemonics im Assemblercode erfreuen will, > kann ja auf den Rabbit umsteigen. Die Rabbits sind aber auch schon alle abgekündigt oder NRND.
Philipp Klaus K. schrieb: > Die Rabbits sind aber auch schon alle abgekündigt oder NRND. Na das sind ja wirklich schlechte Nachrichten.
Motopick schrieb: > Philipp Klaus K. schrieb: > >> Die Rabbits sind aber auch schon alle abgekündigt oder NRND. > > Na das sind ja wirklich schlechte Nachrichten. Besser die Rabbits werden abgekündigt als man selbst.
Vielleicht hilft: https://github.com/gdevic/A-Z80 : A-Z80 "A conceptual implementation of the Z80 CPU"
H. H. schrieb: > Motopick schrieb: >> Philipp Klaus K. schrieb: >> >>> Die Rabbits sind aber auch schon alle abgekündigt oder NRND. >> >> Na das sind ja wirklich schlechte Nachrichten. > > Besser die Rabbits werden abgekündigt als man selbst. Da ist zweifellos was dran. Mir waren aber gerade welche zugelaufen. :) Und ich war schon dabei, mich an den putzigen Kerlchen zu erfreuen.
Motopick schrieb: >> Besser die Rabbits werden abgekündigt als man selbst. > > Da ist zweifellos was dran. > > Mir waren aber gerade welche zugelaufen. :) > Und ich war schon dabei, mich an den putzigen Kerlchen zu erfreuen. Andere erfreuen sich an Bunnys.
H. H. schrieb: > Motopick schrieb: >>> Besser die Rabbits werden abgekündigt als man selbst. >> >> Da ist zweifellos was dran. >> >> Mir waren aber gerade welche zugelaufen. :) >> Und ich war schon dabei, mich an den putzigen Kerlchen zu erfreuen. > > Andere erfreuen sich an Bunnys. Auch da ist zweifellos was dran. Das wartet gerade in seiner Wahlheimat. Leider ist die Differenz der Postleitzahlen recht gross, und (b/g)eflogen wird die Strecke nicht mehr. :( (Muesste das nicht "Bunnies" heissen?)
Motopick schrieb: > (Muesste das nicht "Bunnies" heissen?) Auf Englisch schon, aber ich hab ja Deutsch geschrieben.
H. H. schrieb: > Motopick schrieb: >> (Muesste das nicht "Bunnies" heissen?) > > Auf Englisch schon, aber ich hab ja Deutsch geschrieben. Ach daher.
Uwe B. schrieb: > Vielleicht hilft: > https://github.com/gdevic/A-Z80 : A-Z80 "A conceptual implementation of > the Z80 CPU" T80 ist etablierter im FPGA-Bereich: https://opencores.org/projects/t80
> Wikipedia schreibt zum Erfolg des Z80: > > "Der Z80 überflügelte rasch den 8080 und wurde der bisher am weitesten > verbreitete 8-Bit-Hauptprozessor (central processing unit, CPU). ... > https://de.wikipedia.org/wiki/Zilog_Z80 Da würde ich leise Zweifel anmelden wollen. Aus irgendwelchen Altgeräten und alten Maschinensteuerungen hab ich eigentlich zu >80% alte 8051-Derivate gerettet. Damit kann ich euch totwerfen... Wie sind eure Erfahrungen?
Bernie B. schrieb: > Da würde ich leise Zweifel anmelden wollen. Aus irgendwelchen Altgeräten > und alten Maschinensteuerungen hab ich eigentlich zu >80% alte > 8051-Derivate gerettet. Damit kann ich euch totwerfen... CPU != MCU.
Helmut -. schrieb: > Puh, da werden ja meine Stangen an Z80-Komponenten vielleicht mal > wertvoll? Auch mein Gedanke. Es war ein schönes Teil. "Leider" passt der Europlatinen-Inhalt meines Z80-EPC heute in einen kleinen AVR. Inklusive vervielfachter Leistung. Dabei hat der Z80/U880 damals selbst für große Industrierechner gereicht. Vermutlich weil auch dessen Programmierung viel effizienter als heutzutage war. Begrenzte Ressourcen haben doch etwas Gutes an sich.
Die Nachricht ist halb so wild und die Überschrift stimmt in der Form auch nicht ganz. Denn: Etliche uP mit dem Z80 Befehlssatz bleiben lieferbar und sind nicht abgekündigt. Z.B. der Z8018010FSG oder der EZ80F91AZA50EK https://www.mouser.de/c/semiconductors/embedded-processors-controllers/microprocessors-mpu/?q=PCN%20Littlefuse&core=Z80 https://www.mouser.de/c/semiconductors/embedded-processors-controllers/microcontrollers-mcu/8-bit-microcontrollers-mcu/?q=PCN%20Littlefuse&core=eZ80 Und bis alle eingelagerten und gut abgehangenen Original Z80 im 40-Pin Gehäuse am Gebrauchtmarkt verschwinden, da gehen weiter 48 Jahre ins Land. Mindestens.
Gerhard H. schrieb: > Vermutlich weil auch dessen Programmierung viel effizienter als > heutzutage war. War sie überhaupt nicht, man hat sich nur mit viel weniger begnügt als heute. "Industrierechner" ist halt ein sehr dehnbarer Begriff.
Gerhard H. schrieb: > Vermutlich weil auch > dessen Programmierung viel effizienter als heutzutage war. Für ineffiziente Programme braucht man ein Übermass an Ressourcen. Hat man das nicht, wie damals, bleibt nur Effizienz als Option. Oder scheitern. :) Tatsächlich aber bezieht sich Effizienz nicht nur auf die verfügbaren Ressourcen Speicher und Rechenleistung, sondern auch auf die Ressource Programmieraufwand. Technische Ressourcen werden billiger, Programmierzeit nicht. Also kann es in ökonomischem Sinn effizienter sein, die investierte Zeit zu optimieren, nicht die Technik. Beispiel RasPi&Co: Für überschaubare Stückzahlen kann ein Gerät dieser Art trotz hoffnungslos überdimensionierter Technik ökonomisch effizienter sein als ein exakt passender µC.
:
Bearbeitet durch User
Bernie B. schrieb: > Da würde ich leise Zweifel anmelden wollen. Aus irgendwelchen Altgeräten > und alten Maschinensteuerungen hab ich eigentlich zu >80% alte > 8051-Derivate gerettet. Damit kann ich euch totwerfen... > > Wie sind eure Erfahrungen? Ja. Wenn mal ein Z80 auf einer Platine sass, war er ueblicherweise flankiert von einem 2716/2732 EPROM und einem 6116 RAM sowie einiger typischer Z80 Peripherie wie Z80 PIOs und Z80 CTC. Das ganze brauchte dann schon eine ganze Euro-Karte. Besonders oft habe ich bei den 8051ern den 8051FA gefunden. Ansonsten auch alles was besser, breiter und schneller war. Z.B. Intel 80188. Im Telekomsektor auch tonnenweise 68302 und 68360. Eine relative Ausnahme war ein intelligenter Druckerumschalter und Puffer. Dort hatte man einem Z80 glatte 256 kByte spendiert...
Jörg W. schrieb: > War sie überhaupt nicht, man hat sich nur mit viel weniger begnügt als > heute. Das sehe ich anders. Und man hat sich nicht nur mit weniger begnügt sondern vor allem mit dem Wesentlichen. Für alles und jedes brauchts eben kein hochauflösendes Display, KI und Sprachbedienung... (prx) A. K. schrieb: > Tatsächlich aber bezieht sich Effizienz nicht nur auf die verfügbaren > Ressourcen Speicher und Rechenleistung, sondern auch auf die Ressource > Programmieraufwand. Das ist in umfassenderer Betrachtung definitiv ein Argument, ich bezog es aber nur auf ersteres. Nicht daß noch der Eindruck entsteht ich würde in der Fortentwicklung generell einen Rückschritt sehen :)
Motopick schrieb: > Eine relative Ausnahme war ein intelligenter Druckerumschalter > und Puffer. Dort hatte man einem Z80 glatte 256 kByte spendiert... Und ich hatte mal eine DCF77 Uhr mit Z80, auf der ich genau 1 Stück 2114 fand. Das sind ein 1024x4 SRAM. :)
:
Bearbeitet durch User
(prx) A. K. schrieb: > Beispiel RasPi&Co: Für überschaubare Stückzahlen kann ein Gerät dieser > Art trotz hoffnungslos überdimensionierter Technik ökonomisch > effizienter sein als ein exakt passender µC. Im gleichen Masze wie hoffnungslos überdimensioniert wird, sinkt die Zuverlaessigkeit und Verfuegbarkeit des Systems hoffnungslos. Das kann man als > Fortentwicklung ansehen, muss es aber nicht.
(prx) A. K. schrieb: > Und ich hatte mal eine DCF77 Uhr mit Z80, auf der ich genau 1 Stück 2114 > fand. Das sind ein 1024x4 SRAM. :) Es gab in der S.B.Z. auch eine auf dem Z80 basierende "Tuerklingel". Die kam ganz ohnr RAM aus. :) Mit dem Bau derartiger "Klingeln", haben sich damals die FS-Ings. ein Zubrot verdient.
Motopick schrieb: > Es gab in der S.B.Z. auch eine auf dem Z80 basierende "Tuerklingel". > Die kam ganz ohnr RAM aus. :) Z80-EMUF auch.
Motopick schrieb: > Im gleichen Masze wie hoffnungslos überdimensioniert wird, sinkt die > Zuverlaessigkeit und Verfuegbarkeit des Systems hoffnungslos. Stimmt. Allerdings gilt das auch für den Menschen bei anfangs einfachen und zunehmend komplexen Tätigkeiten. Hoffnungslos überdimensioniert, nur bedingt zuverlässig und zeitweilig nicht verfügbar. Ganz klar ein hoffnungsloser Fall. :)
:
Bearbeitet durch User
(prx) A. K. schrieb: > Das sind ein 1024x4 SRAM. :) Für den Datenspeicher kann das ja auch genügen. Für den Programmspeicher wird man wohl eher nicht mit 4 Bit Breite auskommen. ;-)
(prx) A. K. schrieb: > Motopick schrieb: >> Im gleichen Masze wie hoffnungslos überdimensioniert wird, sinkt die >> Zuverlaessigkeit und Verfuegbarkeit des Systems hoffnungslos. > > Stimmt. Allerdings gilt das auch für den Menschen bei anfangs einfachen > und zunehmend komplexen Tätigkeiten. Hoffnungslos überdimensioniert, nur > bedingt zuverlässig und zeitweilig nicht verfügbar. Ganz klar ein > hoffnungsloser Fall. :) In diesem Fall ist es gut, wenn man nicht tarifgebunden taetig sein muss. H. H. schrieb: > Z80-EMUF auch. Ist das so ein Teil vom "Mikrocontrollerladen"?
Jörg W. schrieb: > Für den Programmspeicher wird man wohl eher nicht mit 4 Bit Breite > auskommen. ;-) Ein EPROM war auch noch drin. :)
Motopick schrieb: > Im gleichen Masze wie hoffnungslos überdimensioniert wird, sinkt die > Zuverlaessigkeit und Verfuegbarkeit des Systems hoffnungslos. Ha! Du hast ja doch eine Tastatur mit Umlauten! Schaem dich! LG, Sebastian
Motopick schrieb: >> Z80-EMUF auch. > > Ist das so ein Teil vom "Mikrocontrollerladen"? Zeitschrift MC vom Franzis Verlag, wie üblich in Kooperation mit irgendeiner kleinen Elektronikbude.
Sebastian W. schrieb: > Motopick schrieb: >> Im gleichen Masze wie hoffnungslos überdimensioniert wird, sinkt die >> Zuverlaessigkeit und Verfuegbarkeit des Systems hoffnungslos. > > Ha! Du hast ja doch eine Tastatur mit Umlauten! Schaem dich! > > LG, Sebastian Pff. Das ist durch Kopy und Pasta dahingeraten. :) Rat mal von wo das her ist...
H. H. schrieb: > Motopick schrieb: >>> Z80-EMUF auch. >> >> Ist das so ein Teil vom "Mikrocontrollerladen"? > > Zeitschrift MC vom Franzis Verlag, wie üblich in Kooperation mit > irgendeiner kleinen Elektronikbude. Die "Elektronikbude" war dann wohl besagter "Mikrocontrollerladen". Leicht erkennbar am "gelben" Katalog.
H. H. schrieb: > Motopick schrieb: >>> Z80-EMUF auch. >> >> Ist das so ein Teil vom "Mikrocontrollerladen"? > > Zeitschrift MC vom Franzis Verlag, wie üblich in Kooperation mit > irgendeiner kleinen Elektronikbude. Oder wars doch Elrad? (Dann natürlich nicht als EMUF.) Verdammt lang her...
Der Z80 EMUF Artikel in der mc war von Wolfgang Kanis (Ing. Büro W. Kanis GmbH). https://www.kanis.de/home/products/divers/z80.htm Der Artikel aus der mc 4/1983 findet sich im Netz bei Retro Computing. Das Teil war mit Z80A, RAM, EPROM und 2x Z80A PIO ausgestattet.
:
Bearbeitet durch User
H. H. schrieb: > Motopick schrieb: >> Es gab in der S.B.Z. auch eine auf dem Z80 basierende "Tuerklingel". >> Die kam ganz ohnr RAM aus. :) > > Z80-EMUF auch. NEIN. Da irrt der Herr H.H. Der Z80-EMUF hat ein "6116" Ram drauf. Seite 112 ff. https://hschuetz.selfhost.eu/mc-zeitschriften/1983/mc-1983-04.pdf Der Z80 kommt ohne Ram aus, wenn man * das Ram nicht bestückt * ein geeignetes Programm schreibt, welches ohne Ram arbeitet Bekannt ist hierzu die bereits erwähnte Melodieklingel https://hc-ddr.hucki.net/wiki/doku.php/elektronik/melodieklingel
>Der Z80 kommt ohne Ram aus, wenn man
Der kommt sogar ohne ROM aus. Wenn man die Datenleitungen mit Pulldowns
alle gegen Null zieht, arbeitet die CPU nur NOPs ab und man kann die
Adressleitungen als Zähler nutzen :-)
Klaus F. schrieb: > Da irrt der Herr H.H. > Der Z80-EMUF hat ein "6116" Ram drauf. Es gab damals auch ein minimalistisches Platinchen mit nur Z80, EPROM und PIO (oder wars 8255?). War dann wohl nicht aus der MC.
Christoph M. schrieb: >>Der Z80 kommt ohne Ram aus, wenn man > > Der kommt sogar ohne ROM aus. Wenn man die Datenleitungen mit Pulldowns > alle gegen Null zieht, arbeitet die CPU nur NOPs ab und man kann die > Adressleitungen als Zähler nutzen :-) Vergiß den Refresh nicht!
Stefan K. schrieb: > Der Artikel aus der mc 4/1983 findet sich im Netz bei Retro Computing. > Das Teil war mit Z80A, RAM, EPROM und 2x Z80A PIO ausgestattet. Das war deshalb auch schon eine Luxusversion mit überbordenden Ressourcen, aber hässlicherweise ohne Timer. Der m.W. erste Zwerg dieser Gattung nutzte einen 6504. http://retro.hansotten.nl/6502-sbc/emuf-and-mc/
:
Bearbeitet durch User
(prx) A. K. schrieb: > 1 Stück 2114 16 Stück waren im PET2001 Als CPU fand ich die Sharp LH5801 toll, PI 0/1 Takt wie 6502 und sonst wie z80 also ein Zwitter zwischen beiden Welten wo man sich gleich daheim fühlte.
Christoph M. schrieb: > Oh, der ist gut :-) Allerdings hält die CPU dabei keineswegs an, sondern unterlässt es lediglich, den PC hochzuzählen. Es wird also in vollem Tempo immer ebendieser Befehl ausgeführt, tritt somit mit Macht auf der Stelle. Symbolisch für Zilog?
:
Bearbeitet durch User
Motopick schrieb: > Das ganze brauchte dann schon eine ganze Euro-Karte. Schon mal den ZX81 aufgeschraubt? Z80, ULA, ROM, RAM, fertig. Der Z80 hats bis in Star Trek Universum geschafft: https://memory-alpha.fandom.com/de/wiki/11001001
Matthias S. schrieb: > Schon mal den ZX81 aufgeschraubt? Z80, ULA, ROM, RAM, fertig Vom Vorgänger ZX80 die genial/bizarre Arbeitsweise analysiert. Die basiert nämlich u.A. auf der beschriebenen Arbeitsweise des 0x76 Befehls.
Matthias S. schrieb: > Der Z80 hats bis in Star Trek Universum geschafft: https://spectrum.ieee.org/the-truth-about-benders-brain
(prx) A. K. schrieb: > Vom Vorgänger ZX80 die genial/bizarre Arbeitsweise analysiert. Wenn das interessiert: http://blog.tynemouthsoftware.co.uk/2019/10/how-the-zx80-works.html
Kann man nicht langsam mal ICs zuhause herstellen und damit solche Probleme umgehen? Hologramme belichten ging schon in den 80ern, mit Tennisbällen, Gehwegplatten, Mikrofilm und HeNe-Röhren. Von Privat-Transistoren habe ich schonmal gelesen.
Wollvieh W. schrieb: > Kann man nicht langsam mal ICs zuhause herstellen und damit solche > Probleme umgehen? Welche Probleme? Deinen Realitätsverlust?
Weiß nicht, wo jetzt das Problem ist. Es gibt Emulatoren. Wobei ich mal frech behaupte, dass man Z80 in 20 Jahren noch kaufen kann. Für Hardware: Man kann den Z80 in VHDL nachbauen. Es gibt entsprchende Projekte: https://github.com/gdevic/A-Z80 Das packt man in ein CPLD/kleines FPGA, ein paar Porttreiber dazu und einen Spannungsregler, das sollte sich auf einer Fläche unterbringen lassen, die so groß ist wie der Original Z80. Zum gleichen Stromverbrauch. Vermutlich bekommt man sogar eine funktionsfähige Z80-Emulation auf einem µC unter, der sich (eventuell mittels Adapterboard) in einen Z80-Sockel steckenlässt. Auch hier wird man ziemlich sicher nicht von 0 staten müssen.
ArnoNym schrieb: > Weiß nicht, wo jetzt das Problem ist. Es gibt Emulatoren. Wobei ich mal > frech behaupte, dass man Z80 in 20 Jahren noch kaufen kann. > > Für Hardware: Man kann den Z80 in VHDL nachbauen. Es gibt entsprchende > Projekte: Kann man, wenn's Spaß macht. Aber für produktive Anwendungen macht das kein Mensch mehr. Da wird nur noch alte Hardware am Leben gehalten, oft mit Restbeständen aus Lagern oder Recyclingbauteilen. Und auch damit ist irgendwann man Schluss. Dann wird die Anlage/Fahrstuhl/Whatever entweder entkernt und mit einer neuen Steuerung versehen oder vollständig stillgelegt. Das ist vollkommen normal. Alles hat seine Zeit. In spätestens 3 Milliarden Jahren ist auch hier auf dieser blauen Kugel Feierabend (Sonnenlebenszyklus, Roter Riese etc.), realistisch schon 2-3 Milliarden Jahre vorher.
> Das packt man in ein CPLD/kleines FPGA, ein paar Porttreiber dazu und > einen Spannungsregler, das sollte sich auf einer Fläche unterbringen > lassen, die so groß ist wie der Original Z80. > Zum gleichen Stromverbrauch. Naja, stimmt so nicht ganz, ein CPLD reicht nicht, die "Porttreiber" sind richtige Z80-PIO's und da der Z80 auf 5V lief brauchts noch einiges an Levelshifter. Aber ja, man kann wie auch hier im Forum schon vor über einem Jahrzehnt demonstriert wurde Z80-Homecomputer auf einem LowCost-FPGA nachbauen: Retrocomputing auf FPGA
Falk B. schrieb: > Restbeständen aus Lagern oder Recyclingbauteilen Ich sehe jetzt schon die Preise für gebrauchte Z80 in der Bucht in die Höhe schnellen ;)
900ss schrieb: > Ich sehe jetzt schon die Preise für gebrauchte Z80 in der Bucht in die > Höhe schnellen ;) Die Fahrstuhlhersteller kaufen dann massenweise Einzelexemplare bei eBay? :)
900ss schrieb: > Falk B. schrieb: >> Restbeständen aus Lagern oder Recyclingbauteilen > > Ich sehe jetzt schon die Preise für gebrauchte Z80 in der Bucht in die > Höhe schnellen ;) Neue vom Distri kosten ja auch schon 10€.
Wo bleiben die Chinesen, wenn man sie mal braucht? :) Jeder Kleinkram wird nachgebaut, aber keine Z80?
:
Bearbeitet durch User
(prx) A. K. schrieb: > Wo bleiben die Chinesen, wenn man sie mal braucht? Jeder Kleinkram > wird > nachgebaut, aber keine Z80? Die sind doch nicht blöd.
900ss schrieb: > Ich sehe jetzt schon die Preise für gebrauchte Z80 in der Bucht in die > Höhe schnellen ;) Danke für die Anregung. Dann werd ich mal in den Keller gehen und anfangen zusammenzusuchen. Falk B. schrieb: > Alles hat seine Zeit. In spätestens 3 Milliarden Jahren ist auch hier > auf dieser blauen Kugel Feierabend (Sonnenlebenszyklus, Roter Riese > etc.), realistisch schon 2-3 Milliarden Jahre vorher. Das hast Du ins rechte Licht gerückt :)
Harald K. schrieb: > Damals(tm) gab es mehrere Second-Source-Hersteller ... ich nehme mal an, > daß die sich alle vom Acker gemacht haben. ... und bei der letzten Produktionsstrasse für die Uralt-Fabrikation wird allmählich der Kaugummi spröde, der sie noch zusammen hält. :)
(prx) A. K. schrieb: > Die Fahrstuhlhersteller kaufen dann massenweise Einzelexemplare bei > eBay? :) Massenweise glaube ich kaum aber irgendeine wichtige Maschine (z.B. zum Geldschein drucken :) ), wo der Z80 dann ausfällt und ein einzelner helfen könnte ;)
Die werden wohl eher jetzt vor Ultimo die Lager aufstocken, damit sie die zu erwartenden Ausfälle im Rahmen der vereinbarten Wartung eine Weile abdecken können. Manche werden dann wohl auch ihre Kundschaft mit der frohen Botschaft überraschen, dass nach der Zeit der bereits vereinbarten Wartung Schluss ist, und sich der Kunde danach ins neue Jahrtausend begeben möge. Angereichert mit einem Angebot dafür.
:
Bearbeitet durch User
Eigentlich hätte das gesamte Z80-Ökosystem von Zilog auch in einen einzelnen schnuckligen Mikrocontroller gepackt werden können. Dann wäre viel Software nicht dem Verfall preisgegeben und ich hätte fürs Hobby nie auf was anderes umsteigen müssen.
Gerhard H. schrieb: > Eigentlich hätte das gesamte Z80-Ökosystem von Zilog auch in einen > einzelnen schnuckligen Mikrocontroller gepackt werden können. Der eigentlich von Toshiba stammende Z84C15 ist ziemlich dicht dran. Aber was nützt dir das, wenn der auch eingestellt wird?
(prx) A. K. schrieb: > 900ss schrieb: >> Ich sehe jetzt schon die Preise für gebrauchte Z80 in der Bucht in die >> Höhe schnellen ;) > > Die Fahrstuhlhersteller kaufen dann massenweise Einzelexemplare bei > eBay? :) Waren in den Fahrstühlen damals nicht ohnehin eher 8085 verbaut?
Percy N. schrieb: > Waren in den Fahrstühlen damals nicht ohnehin eher 8085 verbaut? Keine Ahnung. Und der Fahrstuhlexperte des Forums ist schon länger nicht mehr in Erscheinung getreten. Werden die 8085 noch hergestellt?
:
Bearbeitet durch User
(prx) A. K. schrieb: > Werden die 8085 noch hergestellt? https://www.amazon.com/Microchip-IM1821VM85A-analogue-8085-USSR/dp/B00P7CPWUY
Gerhard H. schrieb: > Vermutlich weil auch dessen Programmierung viel effizienter als > heutzutage war. Begrenzte Ressourcen haben doch etwas Gutes an sich. Jo, oder weil die Programme einfach nur primitiv waren, aber dann könnte man ja nicht so stolz auf seine großen Taten sein?
Re D. schrieb: > oder weil die Programme einfach nur primitiv waren Du beleidigst gerade eine ganze Programmierer-Generation. Folgt das aus einem generellen Programmier-Unverständnis?
Re D. schrieb: >> Vermutlich weil auch dessen Programmierung viel effizienter als >> heutzutage war. Begrenzte Ressourcen haben doch etwas Gutes an sich. > > Jo, oder weil die Programme einfach nur primitiv waren, aber dann könnte > man ja nicht so stolz auf seine großen Taten sein? War das Programm des Apollo Guidance Computers primitiv? War es trivial, unter welchen Umständen und welchen verfügbaren Mitteln es entstanden ist?
Sharp hat wohl auch Z80 hergestellt: https://www.x86-guide.net/en/cpu/Sharp-Z80-4MHz-PDIP-cpu-no6746.html Ob sie das immer noch tun?
Christoph M. schrieb: > Sharp hat wohl auch Z80 hergestellt: Ja, haben sie. Unter dem Namen LH0080(A).
Motopick schrieb: > Der Z80 in meinem C128D ist nahezu unbenutzt. Mancher fährt mit dem Porsche 600 m zum Bäcker, um ein paar Brötchen zu kaufen. > Das sagt doch alles. Ja. Ganz schlechte Planung; ein C 16 hätte vermutlich gereicht.
Angehängte Dateien:
-
911m.JPG
260 KB
Percy N. schrieb: >> Der Z80 in meinem C128D ist nahezu unbenutzt. > Mancher fährt mit dem Porsche 600 m zum Bäcker, um ein paar Brötchen zu > kaufen. Oder 911m ;-)
Dieter W. schrieb: > Christoph M. schrieb: >> Sharp hat wohl auch Z80 hergestellt: > > Ja, haben sie. Unter dem Namen LH0080(A). ... und den SC7852 (speziell für den PC1600 entwickelte 100-Pin-CMOS-Variante mit erweiterter I/O-Hardware).
Für viele ist ja der MC6502 einer der beliebtesten, aber mich zieht es auch eher zum Z80, einfach, weil mein erster Computer, der CPC 6128 war:-) Technisch war aber, glaube ich, der 6502 sogar besser, kann das sein? Ich habe hier jedenfalls neben dem CPC auch noch 2 Z80 CPUs für zukünftige Basteleien liegen:-) Schade, das es keine lauffähige Linuxdistribution für den Z80 gibt
H. H. schrieb: > Christian M. schrieb: >> Wie soll man dann die 40 Jahre alten Aufzüge reparieren? > > Die werden auf 6502 umgerüstet. Nein, die laufen dann mit dem Z80-Emulator auf dem Raspi-0
Paule M. schrieb: > Technisch war aber, glaube ich, der 6502 sogar besser, kann das sein? Es gibt Fragen dieser Gattung, die sind zeitlos. Etwa Swifts dickes und dünnes Ende des Eis. Aber 6502 vs Z80 heute?
:
Bearbeitet durch User
> Technisch war aber, glaube ich, der 6502 sogar besser, kann das sein?
Was bedeutet technisch?
Der 6502 hatte viel weniger Register und viel weniger Befehle und
deshalb ist der Assembler deutlich einfacher zu lernen. Mich hat es
immer gewundert, dass er es geschwindigkeitesmässig aufnehmen sollte.
Christoph M. schrieb: > Der 6502 hatte viel weniger Register und viel weniger Befehle und > deshalb ist der Assembler deutlich einfacher zu lernen. Vielleicht einfacher zu lernen aber viel weniger Register und viel weniger Befehle erschweren später die Programmierung.
Paule M. schrieb: > Schade, das es keine lauffähige Linuxdistribution für den Z80 gibt Ich erinnere mich dunkel an ein Mehrbenutzerbetriebssystem für den TRS-80 Model II namens OASYS oder so ähnlich, vermutlich für serielle Terminals, das muß Mitte der 80er-Jahre gewesen sein. Hat jemand genauere Erinnerungen daran?
Angehängte Dateien:
Hier mal der Vergleich der Architekturen von Z80 und 6502.
Paule M. schrieb: > > Schade, das es keine lauffähige Linuxdistribution für den Z80 gibt Linux nicht, aber Fuzix: https://www.fuzix.org/ Ich habe mal einen Z80-MBC2 aufgebaut (https://hackaday.io/project/159973-z80-mbc2-a-4-ics-homebrew-z80-computer, eine Z80, einen ATMega32 als I/O-Knecht und 128kB RAM, Massenspeicher mit einer SD-Card). Es gibt natuerlich keine richtige Speicherverwaltung, Netzwerk gibt es nicht, vi ist der Editor der Wahl. Wenn das Ding einmal stirbt, muss man natuerlich einen fsck machen. Eine Stunde spaeter kann man sicher einloggen. Aber Lustig.
Christoph M. schrieb: > Hier mal der Vergleich der Architekturen von Z80 und 6502. https://retrocomputing.stackexchange.com/questions/6656/how-was-microcode-implemented-in-retro-processors
Gerhard H. schrieb: > Vielleicht einfacher zu lernen aber viel weniger Register und viel > weniger Befehle erschweren später die Programmierung. Der 6502 Prozessor war mehr in Richtung Controlleranwendungen optimiert. Dass er statt dessen als Universalprozessor in PET, Apple, C16/64... bekannt wurde, ist eigentlich ein Treppenwitz der Geschichte. Aber er war billig, umgänglich auf der Ebene der Hardware, und das zählte. Wenn die Programme gross wurden, Hochsprachen via Compiler verwendeten, wurde es umständlich. Das ging mit 8080 und Z80 deutlich besser.
:
Bearbeitet durch User
Thomas W. schrieb: > eine Z80, einen ATMega32 als I/O-Knecht Erinnert mich an meinen Scherz mit einem ROM-losen(*) RCA 1802 System, in dem sich ganz unauffällig ein 8-Pin ATtiny versteckte. Der war für Prozessortakt, Baudrate und zyklische Interrupts zuständig. *: Das Programm wird per serieller Schnittstelle reingeladen. Der 1802 hat gewisse Besonderheiten, und ein AY-3-1015 wird per Pins konfiguriert, nicht per Register.
:
Bearbeitet durch User
Thomas W. schrieb: > Ich habe mal einen Z80-MBC2 aufgebaut > (https://hackaday.io/project/159973-z80-mbc2-a-4-ics-homebrew-z80-computer, > eine Z80, einen ATMega32 als I/O-Knecht und 128kB RAM, Massenspeicher > mit einer SD-Card). Auch wenn meine Frage jetzt etwas OT ist hier in dem Thread. Gibt es hier bei die Möglichkeit einen XT-Bus (AT-Bus 8 Bit) für Erweiterungen anzubinden. Bei der Variante mit dem ATmega32? Gruß und schönes Wochenende noch. bastler2022
Vor ein paar Jahren gab es hier ja mal das Projekt AVRCPM: https://hc-ddr.hucki.net/wiki/doku.php/cpm/avrcpm Leider sehe ich dort nur den 8080 source code. Weiß jemand, wo man den Z80 Source-Code findet und welche Lizenz es ist?
Christoph M. schrieb: > Vor ein paar Jahren gab es hier ja mal das Projekt AVRCPM: > > https://hc-ddr.hucki.net/wiki/doku.php/cpm/avrcpm > > Leider sehe ich dort nur den 8080 source code. Weiß jemand, wo man den > Z80 Source-Code findet und welche Lizenz es ist? https://github.com/MockbaTheBorg/RunCPM Es laeuft auf Arduino/Teensy/ESP32/STM32, emuliert natuerlich eine Z80.
Paule M. schrieb: > Schade, das es keine lauffähige Linuxdistribution für den Z80 gibt Früher gab es aber schon Diskussionen über Unix. Für den Atari (ST) gab es auch schon was in dieser Richtung https://subsole.org/st_mint
Re D. schrieb: > Gerhard H. schrieb: >> Vermutlich weil auch dessen Programmierung viel effizienter als >> heutzutage war. Begrenzte Ressourcen haben doch etwas Gutes an sich. > > Jo, oder weil die Programme einfach nur primitiv waren, Da die den Algorithmen in diesen Programmen immer noch dieselbe Mathematik zugrunde liegt, sind diese heute nicht "fortschrittlicher" als damals. Und bei manchen Algo's (Komprimierung, Krypto) war schon "damals" das Optimum erreicht und mathematisch nachgewiesen. Wenn heute alte Bibliotheken neu implementiert und gepushed werden, dann weil irgendwer gerne eine Hintertür für sich eingeschleust hätte: https://www.heise.de/hintergrund/Die-xz-Hintertuer-das-verborgene-Oster-Drama-der-IT-9673038.html
Rbx schrieb: > Früher gab es aber schon Diskussionen über Unix. Für den Atari (ST) gab > es auch schon was in dieser Richtung > https://subsole.org/st_mint Es gab zumindest eine sh-inspirierte shell mit I/O redirection für CP/M auf Z80. Den Namen habe ich vergessen. Erinnert sich wer?
Klar P. schrieb: > Wenn heute alte Bibliotheken neu implementiert und gepushed werden, > dann weil irgendwer gerne eine Hintertür für sich eingeschleust hätte: Oder weil der alte Code durch Jahrzehnte an Änderungen mittlerweile so vergammelt ist, dass man da mal neu ran muss. > Und bei manchen Algo's (Komprimierung, Krypto) war schon "damals" das > Optimum erreicht und mathematisch nachgewiesen. Könntest du das bitte näher ausführen? Also dass anno Z80 die optimale Komprimierung und Verschlüsselung bereits erreicht war. Was macht die Welt seither in diesen Sektoren eigentlich? Gäbe ja nichts mehr zu tun.
:
Bearbeitet durch User
>> Vielleicht einfacher zu lernen aber viel weniger Register und viel >> weniger Befehle erschweren später die Programmierung. > > Der 6502 Prozessor war mehr in Richtung Controlleranwendungen optimiert. > Dass er statt dessen als Universalprozessor in PET, Apple, C16/64... > bekannt wurde, ist eigentlich ein Treppenwitz der Geschichte. Kein Treppenwitz sondern logische Konsequenz nach dem Aufkauf des 6502 CPU Herstellers MOS-Technology durch den (Home-) Computer-Hersteller Commodore International. Bil Herd erklärt in einem seiner Videos, wie die 6502 Familie an die Requirements des C64 angepasst wurde, insbesonders wohl die zeropage?! Bil weisst öfters darauf hin, das sich Commodore zu einer bestimmten Zeit mehr als Chip-, denn als Computerhersteller verstand, weil sie eben einen Chip-Hersteller geschluckt haben. Und den haben sie heschluckt weil der Tramiel seine schlechte Erfahrung mit dem Taschenrechner-IC Hersteller Texas Instrument machte. https://www.youtube.com/watch?v=QNLbi6ZanUE https://de.wikipedia.org/wiki/MOS_Technologies https://de.wikipedia.org/wiki/Commodore_International#Geschichte
Angehängte Dateien:
-
XTBUS.png
91 KB
Hobby B. schrieb: > Thomas W. schrieb: >> Ich habe mal einen Z80-MBC2 aufgebaut >> (https://hackaday.io/project/159973-z80-mbc2-a-4-ics-homebrew-z80-computer, >> eine Z80, einen ATMega32 als I/O-Knecht und 128kB RAM, Massenspeicher >> mit einer SD-Card). > > Auch wenn meine Frage jetzt etwas OT ist hier in dem Thread. > Gibt es hier bei die Möglichkeit einen XT-Bus (AT-Bus 8 Bit) für > Erweiterungen anzubinden. Bei der Variante mit dem ATmega32? > > Gruß und schönes Wochenende noch. > bastler2022 Kein ATmega32, aber ein Renesas SH7709A SBC, implementiert einen XT-kompatiblen PC/104 Bus mit einem FPGA. Es ist eine Frage welchen individuellen Aufwand man treiben will.
Klar P. schrieb: > Bil Herd erklärt in einem seiner Videos, wie die 6502 Familie an die > Requirements des C64 angepasst wurde, insbesonders wohl die zeropage?! Der C64 hat einen 6510 drin, und der wurde tatsächlich speziell dafür gebaut. Aber die Änderungen gegenüber 6502 sind überschaubar und betreffen nicht die ISA. https://en.wikipedia.org/wiki/MOS_Technology_6510 Die Zeropage ist ein Konzept, das von 6800 übernommen wurde, und obendrein älter als jeder Mikroprozessor ist.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Klar P. schrieb: >> Wenn heute alte Bibliotheken neu implementiert und gepushed werden, >> dann weil irgendwer gerne eine Hintertür für sich eingeschleust hätte: > > Oder weil der alte Code durch Jahrzehnte an Änderungen mittlerweile so > vergammelt ist, dass man da mal neu ran muss. > >> Und bei manchen Algo's (Komprimierung, Krypto) war schon "damals" das >> Optimum erreicht und mathematisch nachgewiesen. > > Könntest du das bitte näher ausführen? Also dass anno Z80 die optimale > Komprimierung und Verschlüsselung bereits erreicht war. Huffman-Kodierung, 1952 "Der bei der Huffman-Kodierung gewonnene Baum liefert garantiert eine optimale und präfixfreie Kodierung. D. h., es existiert kein symbolbezogenes Kodierverfahren, das einen kürzeren Code generieren könnte, wenn die Auftrittswahrscheinlichkeiten der Symbole bekannt sind. " https://de.wikipedia.org/wiki/Huffman-Kodierung#Optimalit%C3%A4t Data encryption standard, 1973 Die Sicherheit eines crypto-algos basiert allerdinmgs auch auf der Schlüssellänge. Während die sich verlängerte, hat sich am Grundalgo nichts getan, weiterhin fröhliches Bit-Geschubse über XOR in mehreren Runden um die Ungleichverteilung der Symbolwahrscheinlichkeiten im plaintext zu beseitigen. > Was macht die Welt seither in diesen Sektoren eigentlich? Gäbe ja nichts > mehr zu tun. Gibt es auch nicht, außer die immer selben Algos auf immer neue Architekturen zu implementieren und die dabei en passant passierten Programmierfehler zu fixen. Oder einfach nur eine lib draufzulinken und zu hoffen, das es passt. https://www.heise.de/news/Der-GAU-fuer-Verschluesselung-im-Web-Horror-Bug-in-OpenSSL-2165517.html
Klar P. schrieb: >>> Vielleicht einfacher zu lernen aber viel weniger Register und viel >>> weniger Befehle erschweren später die Programmierung. >> >> Der 6502 Prozessor war mehr in Richtung Controlleranwendungen optimiert. >> Dass er statt dessen als Universalprozessor in PET, Apple, C16/64... >> bekannt wurde, ist eigentlich ein Treppenwitz der Geschichte. > > Kein Treppenwitz sondern logische Konsequenz nach dem Aufkauf des 6502 > CPU Herstellers MOS-Technology durch den (Home-) Computer-Hersteller > Commodore International. Der Intel 8080 war ein aufgebohrter 8008, der Z80 ein aufgebohrter 8080. Damit hat man praktisch die Einschraenkungen unter denen der 8008 litt, auch beim Z80. Compiler sind geduldige Gesellen. Denen macht das staendige Umladen von Registern und Daten nichts aus. Aber die Geschwindigkeit leidet. Der 6502 zieht seine Kraft aus seiner Vielzahl an Adressierungsarten in Verbindung mit dem recht schnellen und einfachen Zugriff auf die "nullte" Speicherseite. Damit verglichen ist der Z80 etwas komplexer aufgebaut, ohne jedoch grosse Vorteile aus dieser gesteigerten Komplexitaet zu ziehen. Programmiert man einen Z80 in Assembler, fuehlt man sich eher wie auf einem primitiven 8008. Auch wenn es dem Rabbit aktuell an den Kragen geht, sind genau seine Erweiterungen des Z80, die genau diese Schwaechen adressieren, ein guter Beleg dafuer.
Beitrag #7649651 wurde vom Autor gelöscht.
Beitrag #7649666 wurde vom Autor gelöscht.
>> Huffman-Kodierung, 1952 > > Und weshalb verwendet man die nicht durchweg? Weil Komprimierung wieder als uncool gilt? Komprimierte Disketten/Festplatten (drivespace) waren in den Neunzigern häufiger anzutreffen, insbesonders in Studentenkreisen die möglichst viele (raubkopierte) Software auf den teuren Disks/Festplatten halten wollte. In Zeiten kostenloser Cloud-Storages verschwendet man wieder Speicher als gäbe es keine Endlichkeit. > Theorien sind eine feine > Sache, aber per Theorie kriegt man auch problemlos RSA beliebiger Länge > geknackt, und das ganz ohne Quantencomputer. :) Naja, wer die Theorie nicht ehrt, ist in der Praxis nichts wert. o.ä ;-) > >> Data encryption standard, 1973 > > DES wurde bereits zu Zeiten der Z80 mathematisch als Optimum bewiesen? > M.W. hat man sich Jahrzehnte an den mysteriösen S-Boxes gerieben. Was dem einen das Optimum, das dem anderen sein Leid ;-) Also "Optimum" als "umgangssprachlicher" Begriff ist schon eine Hure, in die jeder das steckt, was er gerade möchte. Als mathematischer begriff dagegen sauber definiert als (globales) Extrema. Und für komprimierung und Crypto hat der alte shannon mit der definition von entropy das Optimum berechenbar gemacht. https://www.iacr.org/museum/shannon/shannon45.pdf https://people.math.harvard.edu/~ctm/home/text/others/shannon/entropy/entropy.pdf
Klar P. schrieb: > Weil Komprimierung wieder als uncool gilt? Bloss weil Dinge aus der Wahrnehmung verschwinden, verschwinden sie nicht aus der Realität. Enterprise-Speichersysteme verwenden routinemässig transparente Komprimierung. In den Cloud-Speichern deshalb vermutlich auch. Sieht der Kunde bloss nicht, und auch der Admin nur als Konfiguration und Statistik. Und wer es gerne eine Nummer kleiner hat, der mag auf seinem PC ZFS verwenden. Auch Windows NTFS kann es, wissen nur viele nicht. Muss allerdings nicht immer viel bringen. Wer die Cloud mit massenhaft Fotos oder Filmen vollstopft, der hat nicht viel davon, weil sowieso schon komprimiert und damit im Storage nicht weiter komprimierbar. Ebensowenig wer vorsorglich verschlüsselt speichert, ohne vorher zu komprimieren.
:
Bearbeitet durch User
Zino schrieb: >> Schade, das es keine lauffähige Linuxdistribution für den Z80 gibt > > Ich erinnere mich dunkel an ein Mehrbenutzerbetriebssystem für den > TRS-80 Model II namens OASYS oder so ähnlich, vermutlich für serielle > Terminals, das muß Mitte der 80er-Jahre gewesen sein. Hat jemand > genauere Erinnerungen daran? Wir hatten Mitte der 80er Jahre noch einen OASIS Rechner in der Firma (von WDC?), ausgerüstet sogar mit einer 5MByte 8" Festplatte, die das Stockwerk erschütterte, wenn man den Rechner anschaltete. OASIS war aber etwa so multitaskingfähig wie CP/M und hatte die nahezu gleichartige Philosophie. Das war nicht so dolle.
Beitrag #7649692 wurde vom Autor gelöscht.
900ss schrieb: > Ich sehe jetzt schon die Preise für gebrauchte Z80 in der Bucht in die > Höhe schnellen ;) Hier gibt es die letzten zwei Exemplare!!!!! Beitrag "[V] BDE-Terminal-Steuerungen mit Z80 zum Ausschlachten" ;-)
Klar P. schrieb: > Und für komprimierung > und Crypto hat der alte shannon mit der definition von entropy das > Optimum berechenbar gemacht. Wenn man den "Content" der allermeisten Onlinedaten so anschaut, kann man 1GB getrost auf "PIEEEEEP" komprimieren. Keinerlei Informationsverlust! Ich nenne es die B-Codierung!
von Thomas W. (dbstw) >Christoph M. schrieb: >> Vor ein paar Jahren gab es hier ja mal das Projekt AVRCPM: >> >> https://hc-ddr.hucki.net/wiki/doku.php/cpm/avrcpm >> >> Leider sehe ich dort nur den 8080 source code. Weiß jemand, wo man den >> Z80 Source-Code findet und welche Lizenz es ist? >https://github.com/MockbaTheBorg/RunCPM >Es laeuft auf Arduino/Teensy/ESP32/STM32, emuliert natuerlich eine Z80. Danke für den Link. Der Begriff Arduino ist etwas allgemein. Die Palette der unterstützen Prozessoren geht ja mittlerweile von 8 bis 32 Bit. Das genannte Projekt läuft leider nicht auf den kleinen Arduinos wie Nano- oder Uno. Es gibt auch ein Z80 Library https://github.com/CompactCow/ArduZ80 und einige andere: https://github.com/jkingsman/Z80Mega https://github.com/MockbaTheBorg/RunCPM Was fehlt ist eine lauffähige Version auf einem Atmega328.
Christoph M. schrieb: > Was fehlt ist eine lauffähige Version auf einem Atmega328 Vielleicht geht dieses Projekt als Basis. Im Text steht dort, dass es mal auf Z80 erweitert wurde, was ich aber nicht geprüft habe. https://www.mikrocontroller.net/articles/AVR_CP/M Nachtrag: Es scheint, dass die Sourcen nie den Weg vom Forums-SVN in Github gefunden haben. Das ist bitter. :( Ah.... hier gibt es noch ein Projekt, was einen AVR als Basis hat. Wurde auch mal hier im Forum vorgestellt. Finde den Link jetzt nicht. Aber hier einer zur Seite des Autors: https://jcwolfram.de/projekte/avr/ax81/main.php
:
Bearbeitet durch User
Klar P. schrieb: > (prx) A. K. schrieb: >> […] >> Könntest du das bitte näher ausführen? Also dass anno Z80 die optimale >> Komprimierung und Verschlüsselung bereits erreicht war. > > Huffman-Kodierung, 1952 > "Der bei der Huffman-Kodierung gewonnene Baum liefert garantiert eine > optimale und präfixfreie Kodierung. D. h., es existiert kein > symbolbezogenes Kodierverfahren, das einen kürzeren Code generieren > könnte, wenn die Auftrittswahrscheinlichkeiten der Symbole bekannt sind. > " Die Huffman-Kodierung ist unter Berücksichtigung der folgenden Anforderungen optimal: - Es soll ein fest vorgegebenes Quellalphabet verwendet werden. - Die Auftrittswahrscheinlichkeit ist für jedes Quellsymbol vorab bekannt. - Jedes Quellsymbol soll eindeutig in ein Codesymbol umgesetzt werden. Rückt man von diesen Anforderungen ab¹, sind erheblich bessere Verfahren möglich. Deswegen ging die Forschung nach guten Komprimierungsverfahren auch nach 1952 weiter und ist auch heute noch nicht abgeschlossen. ──────────────── ¹) Insbesondere bei der Komprimierung von Dateien gibt es keinen Grund, daran festzuhalten.
Christoph M. schrieb: > Das genannte Projekt läuft leider nicht auf den kleinen Arduinos wie > Nano- oder Uno. dann sollte man es auf ATmega1284 lauffähig bekommen, mehr Speicher!
Joachim B. schrieb: > Christoph M. schrieb: >> Das genannte Projekt läuft leider nicht auf den kleinen Arduinos wie >> Nano- oder Uno. > > dann sollte man es auf ATmega1284 lauffähig bekommen, mehr Speicher! Der RunCPM laeuft sehr gut auf einem Arduino DUE (und man hat eine 64K TPA). Die kleinen Arduinos (2k RAM) sind ein wenig zu klein (obwohl der DMA-Buffer fuer Disk-IO nur 128Byte klein ist).
Yalu X. schrieb: > Die Huffman-Kodierung ist unter Berücksichtigung der folgenden > Anforderungen optimal: > > - Es soll ein fest vorgegebenes Quellalphabet verwendet werden. > > - Die Auftrittswahrscheinlichkeit ist für jedes Quellsymbol vorab > bekannt. > > - Jedes Quellsymbol soll eindeutig in ein Codesymbol umgesetzt werden. Das wage ich zu bezweifeln. Du willst nur krampfhaft die Aussage zur Huffmann-Kodierung mies machen. Den in der Realität, wird die NIE so verwendet! - Das Quellalphabet ist NICHT vorgegeben, es wird aus den Daten ermittelt! - Dito die Auftrittswahrscheinlichkeit!
Interessant finde ich, dass die Z80 in der Zeitschrift BYTE kaum beachtet wurde im Gegensatz zum 6800 und 6502 (Apple ][ war in den USA sehr erfolgreich). Ich habe einen kleinen Artikel aus BYTE, July 1978 gefunden, wie man ein Multi-CPU-System mit zwei Z80-CPUs mit einem Arbiter baut (die Z80 wurde im Jahr 1976 auf den Markt gebracht). In A nutshell: Der obere Speicherbereich (ab 0x8000) kann von zwei CPUs geschrieben werden, die Synchronisierung ist ueber die /WAIT-Leitung bei der Z80-CPU. Damit wird sichergestellt, dass der Machine-Cycle auch abgeschlossen ist wenn die andere CPU wieder Zugriff auf den geteilten Speicher hat. Diese alten Heftchen sind auf Archive.org verfuegbar. Bei Interesse findet man es hier: https://archive.org/details/byte-magazine-1978-07-rescan
An Introduction to Data Compression https://www.cs.cmu.edu/~guyb/real-world/compress/gutmann.html "It would appear that Huffman or Shannon-Fano coding is the perfect means of compressing data. However, this is not the case. As mentioned above, these coding methods are optimal when and only when the symbol probabilities are integral powers of 1/2, which is usually not the case."
:
Bearbeitet durch User
Joachim B. (jar)
>dann sollte man es auf ATmega1284 lauffähig bekommen, mehr Speicher!
Ich weiß, dass es mit mehr geht. Die Kunst ist, mit wenig auszukommen.
Falk B. schrieb: > Du willst nur krampfhaft die Aussage zur Huffmann-Kodierung mies > machen. Den in der Realität, wird die NIE so verwendet! Nein, ich möchte nur die Behauptung von "Klar P." widerlegen, dass es seit 1952 keine Fortschritte bei den Komprimierungsverfahren mehr gegeben habe. > - Das Quellalphabet ist NICHT vorgegeben, es wird aus den Daten > ermittelt! > - Dito die Auftrittswahrscheinlichkeit! Ja, man kann das Quellalphabet und die Auftrittswahrscheinlichkeiten variabel halten. Da davon aber die Kodierung abhängt, muss diese Information dem Dekodierer bekannt gemacht werden, was zusätzliche Daten erfordert, weswegen das Verfahren nicht mehr optimal sein kann.
Christoph M. schrieb: > Joachim B. (jar) >>dann sollte man es auf ATmega1284 lauffähig bekommen, mehr Speicher! > > Ich weiß, dass es mit mehr geht. Die Kunst ist, mit wenig auszukommen. Es gab mal ein Projekt bei einem Arduino Uno eine SD-Karte als Paging-Device angeflanscht wurde. Manche Sachen muss man nicht tun.
Yalu X. schrieb: > Falk B. schrieb: >> Du willst nur krampfhaft die Aussage zur Huffmann-Kodierung mies >> machen. Den in der Realität, wird die NIE so verwendet! > > Nein, ich möchte nur die Behauptung von "Klar P." widerlegen, dass es > seit 1952 keine Fortschritte bei den Komprimierungsverfahren mehr > gegeben habe. Das kann man auch anders. >> - Das Quellalphabet ist NICHT vorgegeben, es wird aus den Daten >> ermittelt! >> - Dito die Auftrittswahrscheinlichkeit! > > Ja, man kann das Quellalphabet und die Auftrittswahrscheinlichkeiten > variabel halten. Das MUSS man in der Praxis auch! Bestenfalls beim Morsecode sind die konstant. > Da davon aber die Kodierung abhängt, muss diese > Information dem Dekodierer bekannt gemacht werden, was zusätzliche Daten > erfordert, Oh Gott! Damit bricht das Verfahren natürlich total zusammen! > weswegen das Verfahren nicht mehr optimal sein kann. Jaja, die Akademiker und ihr Elfenbeinturm . . .
Falk B. schrieb: > Jaja, die Akademiker und ihr Elfenbeinturm . . . Grundlage dieses Diskussionszweigs war von Anfang an der Elfenbeiturm. Wenn es dir da zu unbequem ist und du raus willst, kommen einige Aspekte hinzu, die bestimmte Verfahren verleiden können. So könnte es schwierig sein, bei Datenströmen den optimalen Hoffman-Code zu ermitteln.
:
Bearbeitet durch User
Falk B. schrieb: > Dito die Auftrittswahrscheinlichkeit! Wie beim Morse-Code.. Mir schwebt bei dieser Diskussion sowas hier im Hinterkopf herum https://de.wikipedia.org/wiki/Aho-Corasick-Algorithmus Den kriegt man allerdings per Haarspalterei nicht in die Birne ;)
Falk B. schrieb: >> Da davon aber die Kodierung abhängt, muss diese >> Information dem Dekodierer bekannt gemacht werden, was zusätzliche Daten >> erfordert, > > Oh Gott! Damit bricht das Verfahren natürlich total zusammen! Das nicht. >> weswegen das Verfahren nicht mehr optimal sein kann. > > Jaja, die Akademiker und ihr Elfenbeinturm . . . Für dich mag es akademisch erscheinen, ob ein Komprimierungsverfahren eine Datei auf 50% oder auf 10% reduziert, für andere ist das durchaus ein erheblicher Unterschied. Hier sieht man sehr schön, dass sich bzgl. der Datenkompression seit der Huffman-Kodierung einiges getan hat: https://de.wikipedia.org/wiki/Datenkompression#Zeittafel_der_Kompressions-Algorithmen Heute wird die Huffman-Kodierung kaum noch in Reinform, sondern nur noch als kleiner Bestandteil in komplexeren Verfahren eingesetzt.
Motopick schrieb: > Der 6502 zieht seine Kraft aus seiner Vielzahl an Adressierungsarten Der 6502 war ein abgespeckter 6800. Grund fürs Abspecken: Deutlich niedrigerer Preis. Unterschiede: Nur ein Akku (A) statt deren zwei (A & B), zwei 8-Bit-Indexregister (X und Y) statt eines 16-Bit-Indexregisters, nur ein 8-Bit-Stackpointer statt eines 16-Bit-Stackpointers. Der wesentliche Unterschied zwischen 8080/Z80 und 6502/68xx war die Nutzung des Taktes. Die 80er brauchten mehrere Taktzyklen für einen Speicherzugriff, die 65/68er brauchten nur einen Taktzyklus für einen Speicherzugriff. Daher rührte die nominell viel höhere Taktfrequenz der 80er-Systeme her; typische Z80-Homecomputer wurden mit 4 MHz getaktet, typische 65/68xx-Homecomputer wurden mit nur 1 MHz getaktet. Die Nutzer der 80er-Systeme waren daher oft der Ansicht, die prinzzipbedingt viel schnelleren Systeme zu haben ... Ideal für Diskussionen auf dem Schulhof, auf dem das jeweils "andere Lager" entsprechend gedisst wurde.
Harald K. schrieb: > Der 6502 war ein abgespeckter 6800. Wobei beim Abspecken aber nebenbei Flexibilität gewonnen wurde. Der 6800 litt an zu wenig Index/Adressregistern, und zu umständlichem Umgang damit. Sowas wie strcpy/memcpy ist beim 6800 bös aufwendig, nicht aber beim 6502. Da kam die (zp),y Adressierung ziemlich gut. Während (zp,x) m.E. für die Katz war, (zp),x wäre besser gewesen.
:
Bearbeitet durch User
> Nein, ich möchte nur die Behauptung von "Klar P." widerlegen, dass es > seit 1952 keine Fortschritte bei den Komprimierungsverfahren mehr > gegeben habe. "Meine" Aussage ist eher die, das im Gegensatz, zu der Behauptung von Beitrag "Re: Das Ende des Z80" damals in Rechentechnik implementierte Algorithmen keinesfalls "primitiver" war als die heutige, weil die Mathematik aus der diese Algo's abgeleiteten waren immer noch dieselbe ist. Und wenn bereits damals optimale Algorithmen implementiert wurden, ist es im Folgenden unmöglich was "optimaleres" aus der Mathematik zu konstruieren. Ja, es gibt neuere "Komprimierungsverfahren" die basieren aber nicht rein auf der Mathematik, sondern auch auf der Akzeptanz von minderer Qualität und Ausnutzung der nicht-perfekten Sensorik des Menschen. Aber so richtig neu ist das auch nicht, bereits die Richtlinie G.711 der ITU (1988 angenommen) enthält eine Audio-Komprimierung die die Eigenheiten des menschlichen Gehörs bei der verlustbehafteten Komprimierung ausnutzt https://de.wikipedia.org/wiki/A-law. Abgesehen davon, das diese Verfahren nicht von "Programmierern" sondern von Physikern und Nachrichtentechnikern(Elektrotechniker) entwickelt wurden, eben Personen, die Mathematik können. Beispielsweise Karlheinz Brandenburg, der Vater des MP3, der Elektrotechnik und Mathematik studierte.
Harald K. schrieb: > Der wesentliche Unterschied zwischen 8080/Z80 und 6502/68xx war die > Nutzung des Taktes. Die 80er brauchten mehrere Taktzyklen für einen > Speicherzugriff, die 65/68er brauchten nur einen Taktzyklus für einen > Speicherzugriff. > > Daher rührte die nominell viel höhere Taktfrequenz der 80er-Systeme her; > typische Z80-Homecomputer wurden mit 4 MHz getaktet, typische > 65/68xx-Homecomputer wurden mit nur 1 MHz getaktet. Und wer damals diese Prozessoren nicht zum Daddeln benutzte, sondern für etwas Nützliches, der freute sich insbesondere beim z80 über die diversen Interrupt-Möglichkeiten. Wer freilich nur grüne Männchen jagen wollte, der dürfte mehr Wert auf raschen Speicherzugriff gelegt haben, wohl wahr.
Der Speicherzugriff war bei 4 MHz Z80 mit 3-4 Takten etwas schneller als bei 1 MHz 6502.
:
Bearbeitet durch User
Bestellungen sind noch bis 14.06.24 bei Mouser möglich. Außerdem hat Zilog noch den Nachfolger .eZ80 im Programm
Angehängte Dateien:
-
z380.jpg
71 KB
Thomas schrieb: > den Nachfolger .eZ80 im Programm Der hat mit dem Z80 nicht mehr viel zu tun. Legitimer Nachfolger war der Z380.
wiki: The eZ80 (like the Z380) is binary compatible with the Z80 and Z180, but almost three times as fast as the original Z80 chip at the same clock frequency.
Thomas schrieb: > The eZ80 (like the Z380) is binary compatible with the Z80 and Z180 Nun ja, das ist noch das Gemeinsame. Ansonsten ist der eZ80 ja schon eher ein Mikrocontroller als ein Prozessor. Deutlich abgespeckt zum Z380. Kam auch erst später. Besonderes Leckerli des Z380 waren übrigens die 4 umschaltbaren Register-Sätze. Luxus pur :)
Gerhard H. schrieb: > Ansonsten ist der eZ80 ja schon eher ein Mikrocontroller als ein > Prozessor. Deutlich abgespeckt zum Z380. Interessanter ist hier wohl die Frage, ob er auch ggü dem z80 abgespeckt wurde; dazu die Verfügbarkeit spezieller Peripheriebausteine.
Percy N. schrieb: > Interessanter ist hier wohl die Frage, ob er auch ggü dem z80 abgespeckt > wurde; Wie gesagt, die haben nicht mehr viel gemeinsam. Insofern erübrigt sich die Frage eigentlich.
Beitrag #7650339 wurde von einem Moderator gelöscht.
Beitrag #7650406 wurde von einem Moderator gelöscht.
Gerhard H. schrieb: > Percy N. schrieb: >> Interessanter ist hier wohl die Frage, ob er auch ggü dem z80 abgespeckt >> wurde; > > Wie gesagt, die haben nicht mehr viel gemeinsam. > Insofern erübrigt sich die Frage eigentlich. Eigentlich sollte sich die Frage sehr leicht beantworten lassen durch die Aufzählung der Deiner Darstellung nach sehr kurzen Liste der Gemeinsamkeiten, allerdings nicht durch Gemeinplätze. Ob sich meine Frage erübrigt oder nicht ist wiederum eine Frage, deren Beantwortung Du getrost mir selbst überlassen kannst.
Klar P. schrieb: > damals in Rechentechnik implementierte Algorithmen keinesfalls > "primitiver" war als die heutige, weil die Mathematik aus der diese > Algo's abgeleiteten waren immer noch dieselbe ist. Der Unterschied ist, das man sich damals sehr genau überlegte wie man Werte als Int darstellen konnte, in welche Register man sie legte ohne ständig hin und herkopieren zu müssen und man nutzte nach Möglichkeit einfache binäre Rechenschritte in handoptimierten ASM Programmen. Heute tut man oft im Kern die gleichen Dinge, aber mit float und double und der math.h. Dank fetter Speicherausstattung, hohem Takt und netten Features wie DMA, DSP funktionen und Multicore, merkt man garnicht wie die MCU rackern muss. 'Damals' habe ich in Tagen einen handoptimierten Audiosampler auf dem 8051 programmiert. Super. Held der Arbeit, auf Tuchfühlung mit den Registern. In der gleichen Teit kann man heute einen ESP32 mit Display und Menueführung ins Wlan hängen, mit Handy und Alexa steuern und per Bluetooth auf der Anlage abspielen. Die Coder damals konnten besser mit sehr begrenzen Ressourcen umgehen. Die Coder heute stemmen dafür in sehr viel kürzerer zeit erheblich größere Aufgaben. Müssig darüber zu streiten wer 'besser' ist. Danmals musste ich die HW auf Bitebene kennen. Heute muss ich dafür erheblich mehr Tools und Libs kennen. Die Abstraktionsebene hat sich geändert. Vom ölverschmierten Maulschlüssel hin zum Diagnosegerät.
Harald K. schrieb: > Motopick schrieb: >> Der 6502 zieht seine Kraft aus seiner Vielzahl an Adressierungsarten > > Der 6502 war ein abgespeckter 6800. Grund fürs Abspecken: Deutlich > niedrigerer Preis. > Unterschiede: Nur ein Akku (A) statt deren zwei (A & B), zwei > 8-Bit-Indexregister (X und Y) statt eines 16-Bit-Indexregisters, nur ein > 8-Bit-Stackpointer statt eines 16-Bit-Stackpointers. > > Der wesentliche Unterschied zwischen 8080/Z80 und 6502/68xx war die > Nutzung des Taktes. Die 80er brauchten mehrere Taktzyklen für einen > Speicherzugriff, die 65/68er brauchten nur einen Taktzyklus für einen > Speicherzugriff. > > Daher rührte die nominell viel höhere Taktfrequenz der 80er-Systeme her; > typische Z80-Homecomputer wurden mit 4 MHz getaktet, typische > 65/68xx-Homecomputer wurden mit nur 1 MHz getaktet. > > Die Nutzer der 80er-Systeme waren daher oft der Ansicht, die > prinzzipbedingt viel schnelleren Systeme zu haben ... > > Ideal für Diskussionen auf dem Schulhof, auf dem das jeweils "andere > Lager" entsprechend gedisst wurde. Wie ueblich hast du die wesentlichen Punkte nicht erkannt. Ausser seiner recht vermurksten "indizierten" Adressierung, kann der Z80 nur einfach indirekt ueber BC, DE oder HL zugreifen. Er kennt auch keinen absolut nachindizierten Zugriff. Das muss man immer mit muehseliger (Adress-)Rechnerei ausgleichen. Und das ist das technische Niveau des 8008. Das der Z80 ueber wenige Registerpaare mehr verfuegt, verbessert es nicht grundsaetzlich. Die Unterschiede zum 6800 sind in dem Zusammenhang auch irrelevant. Und ich kenne auch einige 68er, die den Takt durch Vier teilen. 6805 und 6808 lassen gruessen.
Michael schrieb: > Danmals musste ich die HW auf Bitebene kennen Auch heute gibt es Leute die z.B. Dinge wie die Spectre-Sicherheitslücke finden. Auch dafür muss man nah an die Hardware, die in dem Fall auch noch extrem komplex ist. Michael schrieb: > Die Coder damals konnten besser mit sehr begrenzen Ressourcen umgehen Es gibt immer noch sehr simple 8bitter und 4bitter im Einsatz, in billigen Massenprodukten. Die muss auch wer programmieren. Es hat sich halt lediglich der Markt verschoben.
Niklas G. schrieb: > 4bitter im Einsatz Hast du dafür Beispiele? Der letzte, an den ich mich erinnern kann, war MARC4. Der scheint die Übernahme von Atmel nach Microchip nicht überlebt zu haben. Auch haben heutige 8-bit-MCUs nicht mehr so viel mit dem Z80 gemein, von der Breite des Busses mal abgesehen.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Hast du dafür Beispiele? Die werden kryptische chinesische Namen haben und keine öffentlich findbaren Datenblätter 😉
Niklas G. schrieb: > Jörg W. schrieb: >> Hast du dafür Beispiele? > > Die werden kryptische chinesische Namen haben und keine öffentlich > findbaren Datenblätter 😉 Gut, also war das bloß erstmal 'ne Behauptung, die noch zu beweisen wäre. Ich sehe die Entwicklung da eher in eine andere Richtung gehen: auch in China ist Zeit Geld, sowohl hinsichtlich der Arbeitszeit der Programmierer als auch der "Time to market". Man baut daher lieber leistungsfähige MCUs zu Preisen, die selbst kleinen 8-Bittern zu schaffen machen, sie Padauk. Diese ganz tollen handgefeilten Softwareteile haben nämlich allesamt einen großen Nachteil: es steckt unwahrscheinlich viel Zeit drin, sie zu erzeugen und zu pflegen. Bevor jemand mich dessen bezichtigt, ich würde die guten alten Programmierkünste nicht ausreichend würdigen: ich habe sowas selbst verbrochen, eine handgezählte Schleife für die Floppy-Routine meines CP/M-Computers, weil der Zugriff über DMA irgendwie immer das letzte Byte verlor. Da der Schleifenzähler in ein Register passen musste, wurde die Schleife per Assembler-Makro vervierfacht für Sektorgrößen bis 1 KiB. Sowas möchte ich heute nicht mehr machen müssen, ganz ehrlich.
:
Bearbeitet durch Moderator
> Auch heute gibt es Leute die z.B. Dinge wie die Spectre-Sicherheitslücke > finden. Auch dafür muss man nah an die Hardware, die in dem Fall auch > noch extrem komplex ist. Viele Sicherheitslücken stellen sich bei näherer Betrachtung als (hardware-unabhängige) Programmierfehler heraus. Da wird bspw. Schlüsselraum unzulässigerweise verkleinert indem bei der Generierung von Zufallszahlen geschlampt wird. Oder die Zugriffschutzüberwachung wird ausserkraft gesetzt indem Wertüberprüfungen weg"optimiert" werden und dadurch ein "Buffer overflow" implementiert wird. "Heartbleed" sei hier als Anschauungs-beispiel genannt. https://www.heise.de/hintergrund/So-funktioniert-der-Heartbleed-Exploit-2168010.html > Die Coder damals konnten besser mit sehr begrenzen Ressourcen umgehen. > Die Coder heute stemmen dafür in sehr viel kürzerer zeit erheblich > größere Aufgaben. Wobei die Aufgaben meist darin bestehen, die korrekte Funktion des Codes nachzuweisen und die dabei gefundenen (selbstgemachten) Programmierfehler zu entfernen. So ganz nach dem Bonmot "wer viel arbeit, macht viele fehler - wer wenig arbeitet, macht wenig fehler"
Jörg W. schrieb: > Gut, also war das bloß erstmal 'ne Behauptung, die noch zu beweisen > wäre. Google liefert z.B. den EMS6500, den es wohl noch gibt. Dann wird es noch mehr geben, die halt nur nirgends öffentlich angeboten werden. Klar P. schrieb: > Viele Sicherheitslücken stellen sich bei näherer Betrachtung als > (hardware-unabhängige) Programmierfehler heraus. Auch, aber es gibt auch Hardware-Bugs. Je komplexer die Hardware, desto mehr Möglichkeiten für Fehler. Klar P. schrieb: > und die dabei gefundenen (selbstgemachten) programmierfehler zu > entfernen Oft besteht ein signifikanter (!) Anteil der Arbeit darin, die Fehler in externen Komponenten/Bibliotheken zu finden und zu beheben. Geht bei OpenSource natürlich deutlich besser.
Niklas G. schrieb: > Es gibt immer noch sehr simple 8bitter und 4bitter im Einsatz, in > billigen Massenprodukten. Die muss auch wer programmieren. 4bitter sind schon ewig tot. Selbst die 8bitter die überlebt haben, haben eine menge Optimierungen die es C-Kompilern einfach machen und erheblich mehr Speicher als damals. Auch die sterben weg, weil es keinen Sinn macht die uralt Designs auf moderne Prozesse zu übertragen auf denen es bereits spuckenbillige 32bit MCUs gibt. Einen heutigen 8051 kannst Du nicht mit dem Original vergleichen. Mehr von allem, besser in allem. Und warum sollte man mit 120nm einen Wafer verschwenden, auf den im 40nm oder 7nm Prozess so unendlich viel mehr und bessere Chips zu erheblich niedrigeren Kosten passen? Man sieht es an den AVRs. Für das wenige was die können, sind die unglaublich teuer. Die werden nur noch verkauft weil es noch so viele Alte gibt die nicht wechseln wollen. Reine Psychologie. Fertigungstechnisch sind die bereits in der Resterampe. Auf die letzte mininische in der ASM noch eine Rolle spielt, kann man nicht auf den Markt schließen. Es gibt auch noch Hufschmiede. Trotzdem bezweifelt keiner das PKWs das Pferd als Transportmittel längst abgelöst haben.
Michael schrieb: > Man sieht es an den AVRs. > Für das wenige was die können, sind die unglaublich teuer. > Die werden nur noch verkauft weil es noch so viele Alte gibt die nicht > wechseln wollen. > Reine Psychologie. > Fertigungstechnisch sind die bereits in der Resterampe. Woher weißt du denn, in welchen Technologien die aktuellen gefertigt werden? Die Anzahl der in der letzten Zeit neu heraus gebrachten AVRs passt irgendwie nicht so ganz zu deiner Aussage. "Alte, die nicht wechseln wollen" finanzieren keine Produktentwicklung. Sowas rechnet sich nur, wenn mindestens einige Millionen Stück verkauft werden können (Milliarden sind natürlich besser), und die verkauft man nicht an ein paar Bastler.
Michael schrieb: > Fertigungstechnisch sind die bereits in der Resterampe. Wenn sie da insgesamt 5 Jahrzehnte verweilen, wie die Z80, sollte das kein Problem sein. :) Die Originalfertigung des NE555 verstarb unbeabsichtigt in Flammen, nicht weil sie eingestellt wurde.
:
Bearbeitet durch User
Niklas G. schrieb: > Jörg W. schrieb: >> Hast du dafür Beispiele? > > Die werden kryptische chinesische Namen haben und keine öffentlich > findbaren Datenblätter 😉 https://www.emmicroelectronic.com/product/multi-io/em6607
Michael schrieb: > Man sieht es an den AVRs. > Für das wenige was die können, sind die unglaublich teuer. Vergleichsweise teuer werden ältere Generationen. Das gilt sowohl für AVR wie eZ80 wie wohl für alle anderen. Und das wird plausibel mit der Wirtschaftlichkeit ihrer Fertigung bei sinkendem Absatz. Nicht unbedingt billiger als leistungsfähigere 32Bitter bleibt die aktuelle 8Bit Generation. Warum sollte sie aber, wenn sie ihren Job, viele Aufgaben nach wie vor einfacher zu lösen gut macht? Jörg W. schrieb: > Die Anzahl der in der letzten Zeit neu heraus gebrachten AVRs passt > irgendwie nicht so ganz zu deiner Aussage
(prx) A. K. schrieb: > Die Originalfertigung des NE555 verstarb unbeabsichtigt in Flammen, > nicht weil sie eingestellt wurde. Der wurde ursprünglich in Orem gefertigt, außer die ersten Muster. Die Fab22 wurde ganz ohne Brand in den 1980ern abgebaut, um Platz für die Fertigung mit größeren Wafern zu schaffen. Abgebrannt ist die Fab in Caen (F), das war Anfang des Jahrtausends.
Motopick schrieb: > Ausser seiner recht vermurksten "indizierten" Adressierung, > kann der Z80 nur einfach indirekt ueber BC, DE oder HL > zugreifen. Er kennt auch keinen absolut nachindizierten Zugriff. > Das muss man immer mit muehseliger (Adress-)Rechnerei ausgleichen Vermurkst? Auf dem Z80 konnte man für meinen Geschmack sehr bequem in Asm programmieren. Wenn Du was vermurkstes sehn willst nimm die ersten PICs. Die blanke Abschreckung. Mein persönlicher Favorit war der bequeme Kopier-Befehl LDIR. Sowas würde ich mir selbst heute noch für AVR wünschen.
H. H. schrieb: > https://www.emmicroelectronic.com/product/multi-io/em6607 Maskenprogrammiert – wie viele Millionen muss man denn davon verbauen, damit sich das rentiert (auch noch angesichts der dort benannten Bugs des Emulators)? Also nicht die Masken selbst, so viel kosten die nicht, aber die Entwicklungskosten für die Software … wahrscheinlich bleiben die Bugs dann in der Software auch genauso drin wie schon im Emulator. ;-)
Gerhard H. schrieb: > Wenn Du was vermurkstes sehn willst nimm die ersten PICs. Du meinst nicht zufällig die späteren PICs? Die anfängliche Implementierung als PIC1650 ist im Rahmen der Aufgabe nicht so übel. Da gab es noch kein Banking. Nur ungewohnt, weil quer zur üblichen Namensgebung. https://picaxe.com/docs/gi_cat_1977.pdf Meine Spitzenreiter: RCA 1802 und NS SC/MP. ISAs ohne Befehle für Unterprogrammaufrufe sind echt ätzend. Beim SC/MP kommen noch fehlende lange Sprungbefehle hinzu - ergibt etliche Sprungketten von einem Ende des Programms zum anderen. Der 1802 war wohl der erste 8bitter, der gewissermassen von vorneherein für Hochsprache konzipiert wurde. Nämlich für FORTH, das liess sich damit leidlich implementieren. Den Rest erledigte man dann lieber damit.
:
Bearbeitet durch User
2000 hat sich Fairchild auch mal mit µCs beschäftigt und den ACE1202 rausgebracht. Der ACE1202 war im DIP-8, hatte 6 IOs, internen 1MHz Takt und internes Reset. Das interne Reset war die Schwachstelle, es mußte ab 0V erfolgen und die VCC mußte schneller als 10ms/1V ansteigen. Ansonsten blieb er tot. Der Befehlssatz war deutlich komfortabler als bei den einfachen PICs. Ich hab noch irgendwo 2 Samples liegen. https://media.digikey.com/pdf/Data%20Sheets/Fairchild%20PDFs/ACE1202.pdf
:
Bearbeitet durch User
(prx) A. K. schrieb: > Du meinst nicht zufällig die späteren PICs Ich meine PICs wie 12F629. Grausam. Und mein persönlicher Fluchtgrund hin zu AVR. Immerhin, ein Exemplar hat in meinem smarten Home überlebt und steuert seit 20 (?) Jahren zuverlässig Licht und Lüfter im Bad :)
Hallo, Jörg W. schrieb: > Maskenprogrammiert – wie viele Millionen muss man denn davon verbauen, > damit sich das rentiert (auch noch angesichts der dort benannten Bugs > des Emulators)? Was hast du erwartet? Genau das ist ja die Domäne der "4-Bitter": Einsatz in Produkten, die keine große Rechenleistung erfordern und in >10e6-Auflagen produziert werden. Soweit ich weiß wurden (werden) zum Beispiel als Nachfolger der Magnetstreifen-Varianten in jeglicher Art von Karten (EC, Kredit, Krankenkasse, u.s.w.) 4-Bitter eingesetzt. Und genau da kommen dann die notwendigen Stückzahlen zusammen. rhf
Roland F. schrieb: > Soweit ich weiß wurden (werden) zum Beispiel als Nachfolger der > Magnetstreifen-Varianten in jeglicher Art von Karten (EC, Kredit, > Krankenkasse, u.s.w.) 4-Bitter eingesetzt. Das müsste Richie mal in seinem Lab analysieren. ;-) Ich bezweifle das, das sind meines Wissens irgendwelche secure MCUs, wie sie beispielsweise Infineon baut.
Michael schrieb: > 4bitter sind schon ewig tot. Aber gut zum Lernen. Das wäre dann so wie das Lowlevel-IT-Latein. Es ist schon noch eine Herausforderung, den Weg von der einfachen Wertetabelle zum hochintegrierten Gitterwürfel zu erkennen. Das ist eigentlich auch eine Sache, die Mut macht, komplexere Tabellen-/Matrixberechnungen in Asm aufzubauen. Man ist dann nicht mehr so weit weg von Digitalfiltern. Auf der anderen Seite nutzen viele Rechenfreaks lieber pyCuda und haben damit ihren Spaß. Und dann kommt noch das RISC-Design, wo der Code dann von der Verarbeitung schwierig wird - beim Intel kann man z.B. bestimmten Hexcodes persönliche Namen geben, die Intels eignen sich dafür sehr gut - und genau das funktioniert bei ARM eher schlecht. Vom Lernumfang bleibt der Hintergrund in etwa gleich - bei weniger differenzierbaren Code-Abschnitten bei RISC. Da ist man dann auch viel besser dran, wenn man schon mit C oder mit Java durch ist und Bibliotheken bzw. Bib+IDE nutzen kann.
Gerhard H. schrieb: > Motopick schrieb: >> Ausser seiner recht vermurksten "indizierten" Adressierung, >> kann der Z80 nur einfach indirekt ueber BC, DE oder HL >> zugreifen. Er kennt auch keinen absolut nachindizierten Zugriff. >> Das muss man immer mit muehseliger (Adress-)Rechnerei ausgleichen > > Vermurkst? > Auf dem Z80 konnte man für meinen Geschmack sehr bequem in Asm > programmieren. Wenn Du was vermurkstes sehn willst nimm die ersten PICs. > Die blanke Abschreckung. > Mein persönlicher Favorit war der bequeme Kopier-Befehl LDIR. Sowas > würde ich mir selbst heute noch für AVR wünschen. Vermurkst ist schon richtig. Eine Indexoperation die nur ein literales (8 bit(!))Offset kennt, und weiter nichts ist wohl Murks. Die "Indexregister" verdienen ihren Namen nicht. Es brauchte eine extra Programmiersprache, PLS/SYS, die sie etwas umfaenglicher benutzt hat. Der LDIR Befehl und seine nahen Anverwandten moegen ja bequem sein, genauso langsam sind sie aber auch. Und man muss auch noch selbst darauf achten, ob es ein LDIR oder ein LDDR sein muss. Auf dem 6502 haben sie zumindest mir nie wirklich gefehlt. Der alte PIC hat fuer seine paar Register das FSR, um bei "Bedarf" indirekt auf diese Register zuzugreifen. C-Compiler legen Autovariable per Funktion in fest zugeordneten Registern an. Daraus entsteht also kein wesentlicher Bedarf fuer mehr Aufwand. Und fuer Assembleruebungen reicht die FSR Konstruktion allemal, und ist fuer die Gesamtarchitektur auch "PIC-gerecht".
Jörg W. schrieb: > H. H. schrieb: > >> https://www.emmicroelectronic.com/product/multi-io/em6607 > > Maskenprogrammiert – wie viele Millionen muss man denn davon verbauen, > damit sich das rentiert (auch noch angesichts der dort benannten Bugs > des Emulators)? > > Also nicht die Masken selbst, so viel kosten die nicht, aber die > Entwicklungskosten für die Software … wahrscheinlich bleiben die Bugs > dann in der Software auch genauso drin wie schon im Emulator. ;-) Komplexe Sofware passt da eh nicht rein. Es wird sich aber nur lohnen, wenn man die wirklich geringe Leistungsaufnahme braucht. Die gehören ja nicht ohne Grund zu Swatch.
Rbx schrieb: > Michael schrieb: >> 4bitter sind schon ewig tot. > > Aber gut zum Lernen. Da reicht ja ein Emulator.
Motopick schrieb: > Die "Indexregister" verdienen ihren Namen nicht. Ach was. Indizieren können sie. Geringere Sprungweiten sind eben kein Wunder für einen 8Bitter. Der AVR beherrscht auch nicht mehr. Natürlich geht alles noch funktionsreicher, flexibler, aber auch unübersichlicher und komplexer: Wenn ich mir den Asm-Code eines 32Bitters anschaue kann ich nur sagen: nein danke. Das wäre ein Fluchtgrund zurück zu AVR :) > Der LDIR Befehl und seine nahen Anverwandten moegen ja bequem sein, > genauso langsam sind sie aber auch. Alles eine Frage der Relationen. Man vergleicht nur allzuschnell mit heutigen Maßstäben. Außerdem war der Z80 ein CISC, der AVR ein RISC ... > Und man muss auch noch selbst > darauf achten, ob es ein LDIR oder ein LDDR sein muss Das hab ich gerade noch geschafft.
Gerhard H. schrieb: > Wenn Du was vermurkstes sehn willst nimm die ersten PICs. Die waren nie als richtige µC gedacht, wie der Name schon andeutet. Ein Mofa ist ja auch kein vermurkstes Auto.
H. H. schrieb: > Die waren nie als richtige µC gedacht, wie der Name schon andeutet. > Ein Mofa ist ja auch kein vermurkstes Auto. Was für eine geschickte Interpretation!
H. H. schrieb: > Es wird sich aber nur lohnen, wenn man die wirklich geringe > Leistungsaufnahme braucht. > Die gehören ja nicht ohne Grund zu Swatch. Guter Punkt, ja. Da sind sie wirklich gut, die brauchen aktiv das, was andere im Sleep brauchen. ;-)
Beitrag #7650694 wurde von einem Moderator gelöscht.
Moin, Motopick schrieb: > Der LDIR Befehl und seine nahen Anverwandten moegen ja bequem sein, > genauso langsam sind sie aber auch. Auf einen ZX81 hat's ungefaehr gereicht, um innerhalb von einem (Halb)bild den Bildschirmspeicher komplett neu zu fuellen. Oder z.b. nach oben zu scrollen. Das sah dann schonmal garnicht schlecht aus :-) > Und man muss auch noch selbst > darauf achten, ob es ein LDIR oder ein LDDR sein muss. Oh mein Gott, wie schroeckelig... Ich fand's gut, denn damit hat man schnell gelernt, was die Unterschiede zwischen beiden sind, und was passiert, wenn man das nicht beruecksichtigt. > Auf dem 6502 haben sie zumindest mir nie wirklich gefehlt. Da kannste mal sehen... Mir schon. Ich konnt's erst garnicht glauben, als ich vom Z80 Assembler (ZX81) dann mal in Richtung 6502 Assembler (Atari400) unterwegs war: Was fuer ein Gewurstel, nur um erstmal ein paar Pointer klar zu machen, die irgendwo hinzeigen sollen. Jeder Furz, der mit Z80 Assembler 1..2 Instruktionen war, war aufm 6502 schon eine halbe DIN-A5 Karoseite Programm. War damals ja kurz nachm Krieg, da hatte ich keinen Assembler, sondern alles unter BASIC laufen lassen und "zu Fuss" assembliert. (Daher ist mir 118 beim Z80 auch viel gelaeufiger als 0x76.) Gruss WK
Beitrag #7650702 wurde von einem Moderator gelöscht.
Jörg W. schrieb: > Also nicht die Masken selbst, so viel kosten die nicht, aber die > Entwicklungskosten für die Software Gerade mal nachgelesen, weil es mich auch interessiert hat: Der EM66007 läuft schon ab 1,2 V und braucht im aktiven Modus nur 1,8 µA (typ. bei bei 32768 Hz). Er scheint also speziell für Geräte mit einer einzelnen 1,5V-Zelle gemacht zu sein (lt. Datenblatt u.a. für Uhren und Fahrradcomputer). Speziell für die Softwareentwicklungsphase gibt es als kompatiblen Ersatz den EM6503, der bis zu 100-mal programmiert werden kann, wodurch der von den Softwareentwicklern produzierte Elektroschrott immerhin auf 1% reduziert werden kann :) Der EM6503 läuft aber erst ab 2,0 V und braucht fünfmal so viel Strom (typ. 9,0 µA) und ist deswegen nicht für die angepeilten Serienprodukte geeignet.
Motopick schrieb: > Vermurkst ist schon richtig. Eine Indexoperation die nur ein literales > (8 bit(!))Offset kennt, und weiter nichts ist wohl Murks. Keineswegs. Es gibt verschiedene Szenarien, in denen mal die eine und mal die andere Variante sinnvoller ist. (1) Adressiert man Arrays statisch mit berechnetem Index, dann ist man auf einem 8-Bitter mit einer Adresse der Form const16+reg8 oft schon bedient. Siehe 6502 und diverse 68xx. Diese Variante fehlte in der Z80. Analog dazu implementierte die segmentierte Z8000 const32+reg16. Also grad andersrum. Sowas kommt in Fortran öfter vor, und natürlich in Assembler. (2) Adressiert man hingegen lokale Daten in Stackframes, und Structs über Pointer, wie es bei Hochsprachen vom C/Pascal-Stil extrem häufig ist, ist bei 8-Bittern die Form reg16+const8 sehr wichtig und const8 ist dabei meist ausreichend (*). Genau das bieten Z80 und 6800, nicht aber 6502. Die 8-Bit PICs haben damit ziemliche Nöte, erst die revidierte Vision der PIC18 Architektur kommt damit zurecht. Analog dazu implementierte die 68000 reg32+const16. In der Z8000 gab es diese Variante nur bei load&store, was die Effizienz von C/Pascal deutlich reduzierte. *: Assembler-Programmier mag es frusten, für verschieden grosse Offsets verschiedenen Code verwenden zu müssen. Einem Compiler ist das herzlich egal. Wenns nicht reicht, baut er Ersatzcode, und wenn das selten vorkommt, stört es nicht.
:
Bearbeitet durch User
Dergute W. schrieb: > Ich konnt's erst garnicht glauben, als ich vom Z80 Assembler (ZX81) dann > mal in Richtung 6502 Assembler (Atari400) unterwegs war: Was fuer ein > Gewurstel, nur um erstmal ein paar Pointer klar zu machen, die irgendwo > hinzeigen sollen. Ach was. Das ist in 6502 Assembler ein Vierzeiler. (Plus Tabelle :) Dem Indexregister sei dank. > > Gruss > WK Ditto
Dergute W. schrieb: > Ich konnt's erst garnicht glauben, als ich vom Z80 Assembler (ZX81) dann > mal in Richtung 6502 Assembler (Atari400) unterwegs war Man klagt über das, was man verliert, ohne zu würdigen, was man gewinnt. :)
:
Bearbeitet durch User
Dergute W. schrieb: > Ich konnt's erst garnicht glauben, als ich vom Z80 Assembler (ZX81) dann > mal in Richtung 6502 Assembler (Atari400) unterwegs war: Was fuer ein > Gewurstel, nur um erstmal ein paar Pointer klar zu machen, die irgendwo > hinzeigen sollen. Vermutlich hast du einfach nur die 128 Pointerquasiregister übersehen, die es beim 6502 gibt.
Moin, Yalu X. schrieb: > Vermutlich hast du einfach nur die 128 Pointerquasiregister übersehen, > die es beim 6502 gibt. Natuerlich habe ich die nicht uebersehen. Aber immer ein schlechtes Gefuehl dabei gehabt, weil ich nicht wusste, ob da das ATARI-Basic gerade seine Finger im Spiel hat oder ob wirklich nix schlimmes passiert, wenn ich da munter rumfuhrwerke... Und trotzdem: Das sind 4 Instruktionen, um 2 Byte auf Page 0 zu initialisieren und dann noch Y auf was definiertes setzen als 5. Instruktion vs.: LD HL, 12345 Ich sag' ja auch nicht, dass es unmoeglich ist, sondern gebe nur meine Empfindungen von vor ca. 40 Jahren wieder... Gruss WK
Um es mal so auszudrücken - es kommt darauf an, in welchen Zaubertrank man fällt. Ich bin 1980 (passenderweise) mit Z80 gestartet, dadurch entstand wohl eine gewisse Algo-Denkweise - schlecht war das Teil aber nicht, man konnte schon einiges damit anfangen. Ich wollte jedoch immer schon 'was Unix-artiges haben und bin daher bald zu OS9/68k gekommen (und CP/M 3 für die Brot- und Butter-Anwendungen), privat SAM68k - mein Studentenbudget konnte ich damit aufbessern, dass ich für einen deutschen Hersteller OS9 auf seine Industrierechner-Platform portiert habe. Treiber und Bootloader wurden damals(tm) noch in Assembler geschrieben, das hat Spaß gemacht, schöne Assembler-Syntax. Spätere Intel-Versuche ließen mich dagegen einfach nur "bäh" sagen. Mittlerweile nähere ich mich auch den 8-Bittern (fast) nur über C an (bis auf das eine PIC-ASM-Projekt DL4YHF-Frequency-Counter, das ich ein wenig aufgebohrt habe).
Martin H. schrieb: > dass ich für einen deutschen Hersteller OS9 auf seine > Industrierechner-Platform portiert Das war nicht zufällig in Kempen am Niederrhein?
Jörg W. schrieb: > Das war nicht zufällig in Kempen am Niederrhein? Nein, OWL - Detmold, die Firma ist allerdings mit einem schönen 8-Bitter großgeworden, der sogar lautmalerisch Namensbestandteil war. :)
Martin H. schrieb: > Mittlerweile nähere ich mich auch den 8-Bittern (fast) nur über C an Eben. Ich möchte nicht sagen, dass es völlig uninteressant ist, ob der Assembler eines Controllers gut ist (gut lesbar, praktisch und leistungsfähig) aber wann braucht man heute noch Assembler? Das sind tatsächlich Ausnahmen. Mit 8 Bittern hatte ich beruflich seit 30 Jahren fast nichts mehr an Hut. Ich nutze dort selten SPARC V8 Assembler. Lesen schon eher wenn etwas nicht lief (was macht der Schlumpf da?). Z80 Assembler hab ich jahrelang programmiert. Danach nie wieder. AVR nutze ich gerne privat, aber Assembler hab ich darauf zuletzt 2006 genutzt. Auf einem Cortex-M hab ich Assembler mal etwas genutzt, weil es keinen Port für das RTOS gab, was ich aber gerne nutzen wollte. Also mir ist es heute völlig "Latte" ob der Assembler was taugt oder ob es ein LDIR gibt oder nicht. Selbst die Tinys werden heute viel in C programmiert, den inzwischen sehr guten Compilern sei Dank. Der Z80 Assembler hat mir auch viel Spaß gemacht... damals. Und SPARC V8 auch. Alles hat seine Zeit. Und wenn jetzt der Z80 eingestellt wird... schulterzuck.... war damals ein "tolles Teil". Was es heute gibt, finde ich besser :) Hier zu Hause mal etwas an einem Z80 rumspielen kann auch reizvoll sein. Aber davon lebt keiner :) Er bleibt in guter Erinnerung.
900ss schrieb: > Der Z80 Assembler hat mir auch viel Spaß gemacht. Der Spaß hat sich bei mir auf den AVR übertragen. Mindestens so assemblerfreundlich wie einst der Z80. Ob das nun heute als Ausnahme gilt oder nicht ist mir dabei herzlich egal.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.