Forum: Mikrocontroller und Digitale Elektronik Das Ende des Z80


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Philipp Klaus K. (pkk)


Lesenswert?

Die Produktion des Z80 wird eingestellt, Zilog wird ab 14. Juni keine 
Bestellungen mehr entgegennehmen:

https://www.mouser.com/PCN/Littelfuse_PCN_Z84C40.pdf

von Christoph M. (mchris)


Lesenswert?

Oh nein, das ist mein Lieblingsprozessor.

0x3E 0x3A

von Markus F. (mfro)


Lesenswert?

Das sind immerhin beeindruckende 48 Jahre Produktionszeitraum.

(dann kann ich meinen Zaks jetzt wohl wegschmeissen).

von Michael B. (laberkopp)


Lesenswert?

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.

von Christoph M. (mchris)


Lesenswert?

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

von Martin H. (horo)


Lesenswert?

Philipp Klaus K. schrieb:
> Die Produktion des Z80 wird eingestellt

:(
1
0x76

von Harald K. (kirnbichler)


Lesenswert?

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.

von Christoph M. (mchris)


Lesenswert?

Martin H. (horo)
>0x76

Oh, der ist gut :-)

von Rbx (rcx)


Lesenswert?

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.

von Christian M. (likeme)


Lesenswert?

Wie soll man dann die 40 Jahre alten Aufzüge reparieren?

von Edwin (jemand3rd)


Lesenswert?

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

von Veit D. (devil-elec)


Lesenswert?

Hallo,

in die Runde gefragt, was ist mit dem Zilog eZ80? Ist der inkompatibel?

von Fooji (fooji)


Lesenswert?

Die Abkündigung bezieht sich doch nur auf den Z84C40? Das ist ein SIO, 
aber keine CPU.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ist doch keine Pressemitteilung, sondern eine product change notice. Die 
läuft immer nach dem gleichen Schema ab.

von Joachim B. (jar)


Lesenswert?

Christoph M. schrieb:
> Martin H. (horo)
>>0x76
>
> Oh, der ist gut :-)

ich dachte eher an 0x00

von Markus F. (mfro)


Lesenswert?

Christoph M. schrieb:
> Martin H. (horo)
>>0x76
>
> Oh, der ist gut :-)

Kann ja immer noch ein Interrupt reinkommen...

von Philipp Klaus K. (pkk)


Lesenswert?

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

von Philipp Klaus K. (pkk)


Lesenswert?

Veit D. schrieb:
> Hallo,
>
> in die Runde gefragt, was ist mit dem Zilog eZ80? Ist der inkompatibel?

Zumindest bezüglich des instruction timing.

von H. H. (Gast)


Lesenswert?

Christian M. schrieb:
> Wie soll man dann die 40 Jahre alten Aufzüge reparieren?

Die werden auf 6502 umgerüstet.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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!

von H. H. (Gast)


Lesenswert?

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.

von Helmut -. (dc3yc)


Lesenswert?

Puh, da werden ja meine Stangen an Z80-Komponenten vielleicht mal 
wertvoll? Ob ich das aber noch erleben darf?

von Peter M. (r2d3)


Lesenswert?

Hallo Hinz!

H. H. schrieb:
> Die alte Kundschaft wurde per Telex informiert.

Telex
:)

Und in welchen Atomraketen ist der Z80 verbaut?

von Motopick (motopick)


Lesenswert?

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.

von Philipp Klaus K. (pkk)


Lesenswert?

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.

von Motopick (motopick)


Lesenswert?

Philipp Klaus K. schrieb:

> Die Rabbits sind aber auch schon alle abgekündigt oder NRND.

Na das sind ja wirklich schlechte Nachrichten.

von H. H. (Gast)


Lesenswert?

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.

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Lesenswert?

Vielleicht hilft:
https://github.com/gdevic/A-Z80 :  A-Z80 "A conceptual implementation of 
the Z80 CPU"

von Motopick (motopick)


Lesenswert?

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.

von H. H. (Gast)


Lesenswert?

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.

von Motopick (motopick)


Lesenswert?

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?)

von H. H. (Gast)


Lesenswert?

Motopick schrieb:
> (Muesste das nicht "Bunnies" heissen?)

Auf Englisch schon, aber ich hab ja Deutsch geschrieben.

von Motopick (motopick)


Lesenswert?

H. H. schrieb:
> Motopick schrieb:
>> (Muesste das nicht "Bunnies" heissen?)
>
> Auf Englisch schon, aber ich hab ja Deutsch geschrieben.

Ach daher.

von Klar P. (Gast)


Lesenswert?

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

von Bernie B. (flitzmaus)


Lesenswert?

> 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?

von (prx) A. K. (prx)


Lesenswert?

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.

von 900ss (900ss)


Lesenswert?

Martin H. schrieb:
> 0x76

LOL, schön beschrieben :)

von Gerhard H. (hauptmann)


Lesenswert?

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.

: Bearbeitet durch User
von Klaus F. (klaus27f)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Motopick (motopick)


Lesenswert?

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...

von Gerhard H. (hauptmann)


Lesenswert?

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 :)

von (prx) A. K. (prx)


Lesenswert?

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
von Motopick (motopick)


Lesenswert?

(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.

von Motopick (motopick)


Lesenswert?

(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.

von H. H. (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

(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. ;-)

von Motopick (motopick)


Lesenswert?

(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"?

von (prx) A. K. (prx)


Lesenswert?

Jörg W. schrieb:
> Für den Programmspeicher wird man wohl eher nicht mit 4 Bit Breite
> auskommen. ;-)

Ein EPROM war auch noch drin. :)

von Sebastian W. (wangnick)


Lesenswert?

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

von H. H. (Gast)


Lesenswert?

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.

von Motopick (motopick)


Lesenswert?

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...

von Motopick (motopick)


Lesenswert?

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.

von H. H. (Gast)


Lesenswert?

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...

von Stefan K. (stk)


Lesenswert?

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
von Klaus F. (klaus27f)


Lesenswert?

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

von Christoph M. (mchris)


Lesenswert?

>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 :-)

von H. H. (Gast)


Lesenswert?

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.

von Zino (zinn)


Lesenswert?

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!

von (prx) A. K. (prx)


Lesenswert?

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
von Joachim B. (jar)


Lesenswert?

(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.

von (prx) A. K. (prx)


Lesenswert?

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
von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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.

von H. H. (Gast)


Lesenswert?

Matthias S. schrieb:
> Der Z80 hats bis in Star Trek Universum geschafft:

https://spectrum.ieee.org/the-truth-about-benders-brain

von (prx) A. K. (prx)


Lesenswert?

(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

von Wollvieh W. (wollvieh)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

Wollvieh W. schrieb:
> Kann man nicht langsam mal ICs zuhause herstellen und damit solche
> Probleme umgehen?

Welche Probleme? Deinen Realitätsverlust?

von ArnoNym (bergler)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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.

von Klar P. (Gast)


Lesenswert?

> 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

von 900ss (900ss)


Lesenswert?

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 ;)

von (prx) A. K. (prx)


Lesenswert?

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? :)

von H. H. (Gast)


Lesenswert?

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€.

von (prx) A. K. (prx)


Lesenswert?

Wo bleiben die Chinesen, wenn man sie mal braucht? :)
Jeder Kleinkram wird nachgebaut, aber keine Z80?

: Bearbeitet durch User
von H. H. (Gast)


Lesenswert?

(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.

von Gerhard H. (hauptmann)


Lesenswert?

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 :)

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

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. :)

von 900ss (900ss)


Lesenswert?

(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 ;)

von (prx) A. K. (prx)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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?

von Percy N. (vox_bovi)


Lesenswert?

(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?

von (prx) A. K. (prx)


Lesenswert?

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
von H. H. (Gast)


Lesenswert?


von Re D. (re_d228)


Lesenswert?

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?

von Gerhard H. (hauptmann)


Lesenswert?

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?

von Falk B. (falk)


Lesenswert?

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?

von Christoph M. (mchris)


Lesenswert?

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?

von Dieter W. (dds5)


Lesenswert?

Christoph M. schrieb:
> Sharp hat wohl auch  Z80 hergestellt:

Ja, haben sie. Unter dem Namen LH0080(A).

von Motopick (motopick)


Lesenswert?

Der Z80 in meinem C128D ist nahezu unbenutzt.
Das sagt doch alles.

von Percy N. (vox_bovi)


Lesenswert?

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.

von Falk B. (falk)


Angehängte Dateien:

Lesenswert?

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 ;-)

von Yalu X. (yalu) (Moderator)


Lesenswert?

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).

von Paule M. (martin_mu)


Lesenswert?

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

: Bearbeitet durch User
von Hardy F. (hflor)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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
von Christoph M. (mchris)


Lesenswert?

> 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.

von H. H. (Gast)


Lesenswert?

Äpfel sind süßer als Birnen.

von Gerhard H. (hauptmann)


Lesenswert?

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.

von Zino (zinn)


Lesenswert?

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?

von Christoph M. (mchris)


Angehängte Dateien:

Lesenswert?

Hier mal der Vergleich der Architekturen von Z80 und 6502.

von Thomas W. (dbstw)


Lesenswert?

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.

von Thomas W. (dbstw)


Lesenswert?


von (prx) A. K. (prx)


Lesenswert?

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
von (prx) A. K. (prx)


Lesenswert?

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
von Hobby B. (bastler2022)


Lesenswert?

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

von Christoph M. (mchris)


Lesenswert?

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?

von Thomas W. (dbstw)


Lesenswert?

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.

von Rbx (rcx)


Lesenswert?

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

von Klar P. (Gast)


Lesenswert?

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

von Zino (zinn)


Lesenswert?

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?

von (prx) A. K. (prx)


Lesenswert?

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
von Klar P. (Gast)


Lesenswert?

>> 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

von Motopick (motopick)


Angehängte Dateien:

Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Klar P. (Gast)


Lesenswert?

(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

von Motopick (motopick)


Lesenswert?

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.
von Klar P. (Gast)


Lesenswert?

>> 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

von (prx) A. K. (prx)


Lesenswert?

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
von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

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.
von Falk B. (falk)


Lesenswert?

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"

;-)

von Falk B. (falk)


Lesenswert?

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 Christoph M. (mchris)


Lesenswert?

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.

von 900ss (900ss)


Lesenswert?

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
von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Joachim B. (jar)


Lesenswert?

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!

von Thomas W. (dbstw)


Lesenswert?

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).

von Falk B. (falk)


Lesenswert?

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!

von Thomas W. (dbstw)


Angehängte Dateien:

Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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
von Christoph M. (mchris)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Thomas W. (dbstw)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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 . . .

von (prx) A. K. (prx)


Lesenswert?

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
von Rbx (rcx)


Lesenswert?

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 ;)

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Harald K. (kirnbichler)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Klar P. (Gast)


Lesenswert?

> 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.

von Percy N. (vox_bovi)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

Der Speicherzugriff war bei 4 MHz Z80 mit 3-4 Takten etwas schneller als 
bei 1 MHz 6502.

: Bearbeitet durch User
von Thomas (kosmos)


Lesenswert?

Bestellungen sind noch bis 14.06.24 bei Mouser möglich. Außerdem hat 
Zilog noch den Nachfolger .eZ80 im Programm

von Gerhard H. (hauptmann)


Angehängte Dateien:

Lesenswert?

Thomas schrieb:
> den Nachfolger .eZ80 im Programm

Der hat mit dem Z80 nicht mehr viel zu tun.
Legitimer Nachfolger war der Z380.

von Thomas (kosmos)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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 :)

: Bearbeitet durch User
von Percy N. (vox_bovi)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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.
von Percy N. (vox_bovi)


Lesenswert?

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.

von Michael (Firma: HW Entwicklung) (mkn)


Lesenswert?

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.

von Motopick (motopick)


Lesenswert?

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.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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
von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Jörg W. schrieb:
> Hast du dafür Beispiele?

Die werden kryptische chinesische Namen haben und keine öffentlich 
findbaren Datenblätter 😉

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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
von Klar P. (Gast)


Lesenswert?

> 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"

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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.

von Michael (Firma: HW Entwicklung) (mkn)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von H. H. (Gast)


Lesenswert?

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

von Gerhard H. (hauptmann)


Lesenswert?

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

von H. H. (Gast)


Lesenswert?

(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.

von Gerhard H. (hauptmann)


Lesenswert?

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.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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. ;-)

von (prx) A. K. (prx)


Lesenswert?

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
von Peter D. (peda)


Lesenswert?

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
von Gerhard H. (hauptmann)


Lesenswert?

(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 :)

von Roland F. (rhf)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Rbx (rcx)


Lesenswert?

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.

von Motopick (motopick)


Lesenswert?

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".

von H. H. (Gast)


Lesenswert?

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.

von H. H. (Gast)


Lesenswert?

Rbx schrieb:
> Michael schrieb:
>> 4bitter sind schon ewig tot.
>
> Aber gut zum Lernen.

Da reicht ja ein Emulator.

von Gerhard H. (hauptmann)


Lesenswert?

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.

von H. H. (Gast)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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!

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.
von Dergute W. (derguteweka)


Lesenswert?

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.
von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Motopick (motopick)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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
von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Dergute W. (derguteweka)


Lesenswert?

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

von Martin H. (horo)


Lesenswert?

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).

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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?

von Martin H. (horo)


Lesenswert?

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. :)

von 900ss (900ss)


Lesenswert?

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.

von Gerhard H. (hauptmann)


Lesenswert?

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.

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.