Forum: Mikrocontroller und Digitale Elektronik 6502 Prozessor wer kennt den noch?


von Lattice User (Gast)


Lesenswert?

MCUA schrieb:
> Was heisst super geheim? Nur Xilinx kennt den, sonst keiner. Und wenn
> man's knacken will, muss man den Chip auseinander nehmen, was extrem
> teuer ist.

Kennen auch die grossen Tool Hersteller (Synopsis, Cadence). Auch muss 
man nicht den Chip auseinandernehemen, sondern die Designsoftware 
reicht. Mit reinem Netzlisten vs Bitstream Vergleich dürfte man schon 
sehr weit kommen.

Ab Serie 7 hat Xilinx AES auch in allen Familien Mitgliedern, d.h auch 
die kleineren Artix-7, es sei den das Advanced Datasheet lügt.

Aber ich denke das ist endgültig Offtopic hier. Zur Fortsetzung dieser 
Diskussion sollte wir einen Thread im FPGA Forum aufmachen.

von Christoph db1uq K. (christoph_kessler)


Angehängte Dateien:

Lesenswert?

Die Handbücher hab ich auch noch, sogar zwei zu PL65 - das hatte ich 
allerdings nie. Das Forth-ROM hatte ich zwar, aber meine Programme in 
Assembler (und Basic) geschrieben. Durch Herwig Feichtinger von der 
Funkschau / mc wurde der AIM ziemlich bekannt, auch unter Funkamateuren.

Von ihm gab es einen AIM65-Emulator auf dem Apple ÜÄ
Siemens hatte eine Lizenzversion das AIM65 als PC100. Dazu auch ein 
Handbuch.

von Osche R. (Gast)


Lesenswert?

für meinen AIM-65 suche ich noch zwei Kunststoffteile: die rote 
Abdeckung für das Display, und diesen Winkel, der die Klopapierrolle 
hält...

von Konrad S. (maybee)


Lesenswert?

PET 2001
CBM 8032 + CBM 8050
Osborne 1
TRS-80
... Alles längst verschenkt, verkauft oder sonstwie weg.

Geblieben ist ein Stück Sehnsucht nach den Atari STs; ich mochte einfach 
die Architektur der 68000er. Und geblieben ist eine HP 2100A mit 
Zubehör.
 http://oscar.taurus.com/~jeff/2100/sven/hp2.jpg
 http://oscar.taurus.com/~jeff/2100/hardware.html
Die habe ich erwischt, als sie gerade verschrottet werden sollte. Wird 
noch dauern bis ich mich mehr damit befassen kann. Aber das macht 
nichts. Ich bin mir sicher, dass der handeingetippte Bootloader nach 
20-30 Jahren brav seinen ersten Lochstreifen einlesen wird. Evtl. solle 
ich mal alle existierenden Lochsteifen auf dem PC einlesen. Mögen Mäuse 
eigentlich Lochsteifen-Papier?

Wilhelm Ferkes schrieb:
> Für meinen persönlichen Bedarf reichen die 640kB aber von heute ab
> nochmal 20 Jahre. ;-)

Würde mir ja auch reichen.
Mein Firefox belegt im Moment gerade 1101 MB virtuellen und 449 MB 
residenden Speicher. Und es hat schon was, hier -klickediklick- im Forum 
zu stöbern, dem einen oder anderen Link zu folgen, nebenher eben noch 
mal eine Windows-VM mit AVR-Studio anwerfen und was der Dinge so mehr 
sind. Meine Erfahrung sagt mir, dass auch mein aktueller, gut 
ausgestatteter PC in wenigen Jahren zu eng sein wird für wer weiß was 
für ein Betriebssystem und die dann darauf laufenden Anwendungen.

Gute alte Computer-Zeit? Hm, so-la-la. Aber die Erinnerung, die gute 
Erinnerung daran werde ich sicher behalten und von dem damit erworbenen 
Wissen profitieren.

Hach, schnief! ;-)

von Nichts ist zu Alt (Gast)


Lesenswert?

Heute wissen wahrscheinlich gerade noch ein Bruchteil der µC 
Programmierer wie die Prozessoren wirklich arbeiten, wenn mas nicht 
stimmt gleich ins Internet dammit und immer den größten und schnellsten 
Prozessor nehmen und noch am besten Übertakten damit die damit gebaute 
Uhr auch schnell genug läuft.


Wer kennt den den R6500 Entwicklungs Chip noch?

von Nichts ist zu Alt (Gast)


Lesenswert?

> Für meinen persönlichen Bedarf reichen die 640kB aber von heute ab
> nochmal 20 Jahre. ;-)

Für nen Toaster wird das noch in 50 Jahren noch reichen.;-)

von Abdul K. (ehydra) Benutzerseite


Lesenswert?

Konrad S. schrieb:
> PET 2001
> CBM 8032 + CBM 8050
> Osborne 1
> TRS-80
> ... Alles längst verschenkt, verkauft oder sonstwie weg.

Ein Vermögen.


>
> Geblieben ist ein Stück Sehnsucht nach den Atari STs; ich mochte einfach
> die Architektur der 68000er. Und geblieben ist eine HP 2100A mit
> Zubehör.
>  http://oscar.taurus.com/~jeff/2100/sven/hp2.jpg
>  http://oscar.taurus.com/~jeff/2100/hardware.html
> Die habe ich erwischt, als sie gerade verschrottet werden sollte. Wird
> noch dauern bis ich mich mehr damit befassen kann. Aber das macht
> nichts. Ich bin mir sicher, dass der handeingetippte Bootloader nach
> 20-30 Jahren brav seinen ersten Lochstreifen einlesen wird. Evtl. solle
> ich mal alle existierenden Lochsteifen auf dem PC einlesen. Mögen Mäuse
> eigentlich Lochsteifen-Papier?
>

Wie jedes Papier. Hauptsächlich weil es so schön raschelt und für den 
Nestbau. Ich kann dir aber sagen, was sie absolut nicht mögen: 
Bauschaum.

von Abdul K. (ehydra) Benutzerseite


Lesenswert?

Nichts ist zu Alt schrieb:
> Heute wissen wahrscheinlich gerade noch ein Bruchteil der µC
> Programmierer wie die Prozessoren wirklich arbeiten, wenn mas nicht
> stimmt gleich ins Internet dammit und immer den größten und schnellsten
> Prozessor nehmen und noch am besten Übertakten damit die damit gebaute
> Uhr auch schnell genug läuft.
>

Naja. Die Strategie is zumindest wesentlich besser als zu klein gespart 
und dann endlos aufgebohrt. Beispiele gibt es genug. Eines steht neben 
deinem Tisch.


>
> Wer kennt den den R6500 Entwicklungs Chip noch?


Ich vage.

von Konrad S. (maybee)


Lesenswert?

Nichts ist zu Alt schrieb:
> Für nen Toaster wird das noch in 50 Jahren noch reichen.;-)

"Du, Opa, warum kann dein Toaster nicht sprechen? Ist der krank?", ich 
kann es heute schon hören!

von Nichts ist zu Alt (Gast)


Lesenswert?

Ne der liegt im Schrank.

Ich habe den Mal Geschenkt bekommen aber gemacht habe ich damit noch 
nichts habe leider keine Unterlagen dazu. Aber mir wurde gesagt dass es 
ein IC ist das mann zu testen von Software verwendet wurde und es soll 
einen 6502 kern besitzen und noch etwas Peripherie.

Da wurde der R6500 schoneinmal besprochen:
Beitrag "R6500/1EC von Rockwell"

von Konrad S. (maybee)


Lesenswert?

Abdul K. schrieb:
> Ein Vermögen.

Ja, nun. Der eine fährt sonstwohin in Urlaub, der andere blättert 3000 
DM für PET hin. Hauptsache, jeder hat seinen Spass dabei.

von Rolf S. (Firma: privat) (ras)


Angehängte Dateien:

Lesenswert?

einen hab ich noch, einen hab ich noch. Nachdem ich ihn vom Staub der 
letzten 20 Jahre befreit, die Sicherung gewechselt habe (war mechanisch 
defekt), Mut zur Lücke, eingeschaltet, und siehe da er funktioniert 
noch.
Hatte mit nem Junior Computer angefangen mich mit Asembler zu 
beschäftigen. Aber der Beruf.... An den AIM bin ich mehr oder weniger 
zufällig gekommen. Firmenauflösung.

Gruß Rolf

von Rolf S. (Firma: privat) (ras)


Angehängte Dateien:

Lesenswert?

da sollte eigentlich nochn Bild dranhängen!!!
Is irgendwie durchgegangen.

von Nichts ist zu Alt (Gast)


Lesenswert?

Rolf Scheer schrieb:
> einen hab ich noch, einen hab ich noch. Nachdem ich ihn vom Staub der
> letzten 20 Jahre befreit, die Sicherung gewechselt habe (war mechanisch
> defekt), Mut zur Lücke, eingeschaltet, und siehe da er funktioniert
> noch.
> Hatte mit nem Junior Computer angefangen mich mit Asembler zu
> beschäftigen. Aber der Beruf.... An den AIM bin ich mehr oder weniger
> zufällig gekommen. Firmenauflösung.
>
> Gruß Rolf

Du glücklicher;-)

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Lesenswert?

Mein 6502 Exemplar embedded in ATARI 130XE ;-)

http://www.nisch-aufzuege.at/atari_130xe_fotos/atari_130_xe.jpg
http://www.nisch-aufzuege.at/atari_130xe_fotos/deckel_auf.jpg
http://www.nisch-aufzuege.at/atari_130xe_fotos/inside.jpg
http://www.nisch-aufzuege.at/atari_130xe_fotos/inside2.jpg
http://www.nisch-aufzuege.at/atari_130xe_fotos/ram_erweiterung.jpg
http://www.nisch-aufzuege.at/atari_130xe_fotos/rs232.jpg
http://www.nisch-aufzuege.at/atari_130xe_fotos/von_hinten.jpg

Neben RS232 und Speichererweiterung 320K (1MB war auch schon mal darin)
Besonderheit 3*R6520 PIO macht zusätzlich 32bit PP z.B. zum Brennen von 
Eprom
Sockel für umschaltbares Zusatz BS-ROM

Für die Qualität der Fotos entschuldige ich mich vielleicht bekomme ich 
noch bessere hin.

Namaste

von Nichts ist zu Alt (Gast)


Lesenswert?

Gibts da auch ein Bildchen im Betrib?

Hoffe ohne Rauchwolke.;-)

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Lesenswert?

Mache ich gern er läuft noch inklusive XF551 320K 1/4"Floppy

Wenn jemand das Feeling auf seinem PC haben möchte es gibt einen 
Topemulator und die Software des Orignals läuft darauf hervorragend
kann ich alles hochladen  ich habe damals in BAsic ein Textprogramm für 
den 80zeicheneditor geschrieben auch das läuft auf dem Emulator 
hoffentlch find ich es zwischen den alten Disketten oder images.

Was leider einem Plattenabsturz zum Opfer viel war ein Floppysimulator 
ein  selbst in PDSBASIC geschriebenen auf einem 486SX . Er stellte mir 8 
virtuelle Floppylaufwerke bereit welche simuliert wurden und zusammen 
mit orignal XF551 Laufwerken am seriellen BUS des ATARI liefen und 
Images auf der Festplatte anlegten.
Schade.

Namaste

von GeraldB (Gast)


Lesenswert?

om pf schrieb:
> Designvorgabe beim IIGS war, dass Apple II-Software von 1977 drauf
> laufen sollte. Und zwar ohne Emulation. Daher musste die Kiste erstmal
> als einfacher 1MHz/64k 6502 hochlaufen, um dann mit fiesen Tricks die
> besseren Features freizuschalten.

om pf schrieb:
> Exakt deswegen habe ich ihn als gescheitert bezeichnet. Man wollte
> unbedingt eine Kiste, die mit 1MHz Apple ][-kompatibel hochläuft. Und
> alles andere musste da dann irgendwie drangepfriemelt werden.

Du kennst dich aber nicht gut mit dem IIGS aus. Er verhielt sich wie ein 
beschleunigter enhanced IIe (2,8MHz/128k 65C02 u. 80-Zeichen-Karte) und 
lief sofort nach dem Einschalten auf der eingestellten (schnellen) 
Geschwindigkeit. Wie du jedoch richtig schreibst, mußte bei bestimmten 
Zugriffen wegen dem timing runtergetaktet werden. Alle 
weiterverwendbaren alten Erweiterungskarten waren halt nur für die 
ursprünglichen 1MHz ausgelegt.

Was meinst du mit "fiesen Tricks um die besseren Features 
freizuschalten" ?
Die CPU startet im 8bit-Modus und wird wenn ein 16bit-BS z.B. GS/OS 
startet in den 16bit-Modus umgeschaltet. Aktuelle Intel-/AMD-CPUs 
starten ja auch immer noch im 16bit-Modus und werden beim Starten vom BS 
in den 32bit- bzw. 64bit-Modus umgeschaltet.


Und noch eine Anmerkung, weil weiter oben die Z80-Karte erwähnt wurde. 
Es gab für den AppleII auch eine Erweiterungskarte mit dem Namen "PC 
Transporter". Die hatte als CPU den NEC V20 und einen Sockel für einen 
optionalen 8087. Somit konnte man auch MS-DOS und sogar Windows 3.0 im 
Real mode laufen lassen.

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

Mein AIM65 wurde ziemlich bald um das "Elekterminal" und einen portablen 
Schwarzweiß-TV ergänzt. Später kam noch eine selbstgebaute 32 kByte 
DRAM-Speichererweiterung und eine Eprom-Umschaltplatine für wählbare 
Programmiersprache (Assembler, Basic oder Forth) dazu.
Als Drucker hatte ich auch noch einen LO15 Baudot-code Fernschreiber.

Das KIM Microchess Schachprogramm habe ich damals auf den AIM übertragen 
und mithilfe von zwei Kassettenrecordern (einer für den Quelltext, einer 
für den erzeugten Objectcode) assembliert. Die Steuerung für die beiden 
Kassettenrecorder war schon hardwaremäßig auf dem AIM vorgesehen.

von (prx) A. K. (prx)


Lesenswert?

Christoph Kessler (db1uq) schrieb:

> Eprom-Umschaltplatine für wählbare
> Programmiersprache (Assembler, Basic oder Forth) dazu.

Basic und PL/65 hatte ich ins RAM geladen (DRAM-Karte), weil zu selten 
gebraucht. Auf Adresse im RAM umgepatcht. Die ROMs brauchte ich für 
Assembler und Forth.

> und mithilfe von zwei Kassettenrecordern (einer für den Quelltext, einer
> für den erzeugten Objectcode) assembliert.

Das Ding kriegte irgendwann einen selbstgebauten Floppy-Controller 
verpasst. Mit 8-Zoll Laufwerk dran (das Ding hatte einen 230V-Motor).

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Lesenswert?

Nichts ist zu Alt schrieb:
> Gibts da auch ein Bildchen im Betrib?
>
> Hoffe ohne Rauchwolke.;-)


noch mal 2 bessere bilder vom inneren

http://www.nisch-aufzuege.at/atari_130xe_fotos/platine_links.png

http://www.nisch-aufzuege.at/atari_130xe_fotos/platine_rechts.png



und noch ein 8830 auf einem s3004-centronix interface
http://www.nisch-aufzuege.at/atari_130xe_fotos/s3004_parallelport.png
davon gibt es auch nich eine serielle variante


fotos vom heutigen fuktionstest
http://www.nisch-aufzuege.at/atari_130xe_fotos/in_betrieb.zip

von Yalu X. (yalu) (Moderator)


Lesenswert?

Christoph Kessler (db1uq) schrieb:
> Das KIM Microchess Schachprogramm habe ich damals auf den AIM übertragen
> und mithilfe von zwei Kassettenrecordern (einer für den Quelltext, einer
> für den erzeugten Objectcode) assembliert.

Klasse :D

Das errinnert mich an die Zeiten, wo es bei Großcomputern noch üblich
war, zwei lange, sortierte Listen mittels dreier Magnetbandspeicher zu
einer einzigen zusammenzuführen.

War der von dir verwendete Assembler symbolisch? Dann kann es ja fast
nur ein Two-Pass-Assembler gewesen sein (um auch Vorwärtsreferenzen
aufzulösen), d.h. du musstest beide Kassettenrecorder zwischendurch
zurückspulen? :D :D

von (prx) A. K. (prx)


Lesenswert?

Yalu X. schrieb:

> Das errinnert mich an die Zeiten, wo es bei Großcomputern noch üblich
> war, zwei lange, sortierte Listen mittels dreier Magnetbandspeicher zu
> einer einzigen zusammenzuführen.

Interessanter wars, wenn man nur einen einzigen Kassettenrekorder zur 
Verfügung hatte.

> War der von dir verwendete Assembler symbolisch? Dann kann es ja fast
> nur ein Two-Pass-Assembler gewesen sein (um auch Vorwärtsreferenzen
> aufzulösen), d.h. du musstest beide Kassettenrecorder zwischendurch
> zurückspulen? :D :D

Oder Quelltext zweimal hintereinander draufschreiben. Output reicht 
einmal, der erste Pass produziert ja nur eine Symboltabelle.

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Lesenswert?


von Reinhardt (Gast)


Lesenswert?

Mal eine Frage an alle die sich einen eigenen Rechner mit 8086 (oder 
besser) gebaut haben: Wo habt ihr ein BIOS herbekommen ? Gab es sowas 
früher noch als Sourcecode ?

von Lattice User (Gast)


Lesenswert?

Reinhardt schrieb:
> Gab es sowas
> früher noch als Sourcecode ?

Im Technical Reference Manual des orginalem IBM AT war dessen BIOS in 
Source abgedruckt.

von Reinhardt (Gast)


Lesenswert?

Der Wahnsinn ... habe die Guides für XT und AT gefunden, da steht ja 
wirklich alles bis ins kleinste Detail auf über 600 Seiten. Selbst 
MS-DOS Source Code ist im Netz zu finden ... wie genial ist das bitte. 
Wenn man krank im Kopf ist könnte man das jetzt auf eine 68000er CPU 
portieren :P

von Anja Zoe C. (zoe)


Lesenswert?

Reinhardt schrieb:
> Der Wahnsinn ... habe die Guides für XT und AT gefunden, da steht ja
> wirklich alles bis ins kleinste Detail auf über 600 Seiten. Selbst
> MS-DOS Source Code ist im Netz zu finden ... wie genial ist das bitte.
> Wenn man krank im Kopf ist könnte man das jetzt auf eine 68000er CPU
> portieren :P

Das (in meinen Augen) suboptimale Prinzip der BIOS Einsprünge durch 
Interrupts hat Atari ja brav auf den ST kopiert. Das TOS war dem 
(MS-)DOS ja nun auch sehr ähnlich, mit allen Nachteilen.

Zoe

von (prx) A. K. (prx)


Lesenswert?

Anja zoe Christen schrieb:

> Das (in meinen Augen) suboptimale Prinzip der BIOS Einsprünge durch
> Interrupts hat Atari ja brav auf den ST kopiert.

Die Interrupts waren schon ok, aber nicht welche. IBM hatte von allen 
256 möglichen zielsicher genau jene genutzt, die Intel dafür explizit 
verboten hatte (reserved).

Besonders perfide hatte Rockwell das beim AIM65 gemacht. Die haben 
derart an ihre eigene Perfektion geglaubt, dass sie keine Sprungleiste 
einbauten, sondern die Programmierer der übrigen ROMs direkt die 
richtige Stelle mitten drin finden und aufrufen durften. Natürlich 
führte das alsbald zu ein paar üblen Hacks, weil last-minute-fixes diese 
Einsprungadressen nicht mehr verschieben durften.

von Lattice User (Gast)


Lesenswert?

A. K. schrieb:
> Besonders perfide hatte Rockwell das beim AIM65 gemacht. Die haben
> derart an ihre eigene Perfektion geglaubt, dass sie keine Sprungleiste
> einbauten, sondern die Programmierer der übrigen ROMs direkt die
> richtige Stelle mitten drin finden und aufrufen durften. Natürlich
> führte das alsbald zu ein paar üblen Hacks, weil last-minute-fixes diese
> Einsprungadressen nicht mehr verschieben durften.

Bleib fair. Seit der Zeit des AIM65 hat die Industrie viel gelernt.

Ausserdem auch beim IBM PC/XT ist es ziemlich schnell passiert dass die 
Einsprungaddressen ins BIOS in Stein gemeisselt waren, und das obwohl 
der korrekte Aufruf über einen Int Befehl ging.
Im AT BIOS finden sich viele Stellen wo an der XT kompatiblem 
Einsprungaddresse nichts als ein Sprungbefehl befindet. Ich würde mich 
nicht wundern wenn das für den Realmode heute noch gilt.

von Udo (Gast)


Lesenswert?

DEVPAC Assembler, ist ein Macro assembler.
Es gibt noch monitor6502.... aber glaube nicht als Download


ich suche ein mini computer mit 6502, willst oder hast du einen gebaut

von Andreas B. (bitverdreher)


Lesenswert?

Ob das jetzt 9 Jahre später noch jemanden interessiert?
Ein neuer Thread wäre sinnvoller gewesen, wenn Du nur einen 6502 Rechner 
suchst.

von Mi N. (msx)


Lesenswert?

Udo schrieb:
> ich suche ein mini computer mit 6502,

In welcher Form?
Ich habe hier noch einen alten Acorn Atom. Und als Derivat davon noch 
einen Einplatinenrechner ca. 50 x 100 mm² + 64-pol. VG-Leiste mit R6501, 
8 KB RAM und 32 KB EPROM. Im EPROM ist das modifizierte ATOM-Basic inkl. 
FP-Routinen, ein Monitorprogramm mit Disassembler/Simulator und auch ein 
Assembler. Als Floppy passte eine Commodore 1541 dazu.
Aber vielleicht ist das EPROM auch schon taub geworden.

Andreas B. schrieb:
> Ein neuer Thread wäre sinnvoller gewesen

Ack

von Lothar (Gast)


Lesenswert?

Udo schrieb:
> ich suche ein mini computer mit 6502

Wenn es Dir nur um 6502 ähnlichen Assembler geht, die STM8 uC sind vom 
6502 abgeleitet:

https://www.mikrocontroller.net/articles/STM8

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

Es gab auch noch einen 65C02-kompatiblen von Mitsubishi
https://en.wikipedia.org/wiki/Mitsubishi_740

Nur waren die Hexcodes der 65C02-Erweiterung in einem Bit irgendwie 
vertauscht. Ich habe damals den Code meines Wisi Orbit Satreceivers 
ausgelesen und mühsam dieses Bit umgedreht um den Code disassemblieren 
zu können. Immerhin habe ich damit den Quelltext halbwegs erhalten und 
den Startkanal in der Tabelle ändern können, sodass das ATV-Relais 
Hornisgrinde sofort beim Start eingestellt war.

von MCUA (Gast)


Lesenswert?

> Wenn es Dir nur um 6502 ähnlichen Assembler geht, die STM8 uC sind vom
> 6502 abgeleitet:
Bloss dass STM8 nicht die bescheuerten (war Anfang der 70er schon so) 
8-Bit-Index-Register hat und somit auch nicht ähnlich dem 6502 progr. 
werden kann.

von c-hater (Gast)


Lesenswert?

Lothar schrieb:

> Wenn es Dir nur um 6502 ähnlichen Assembler geht, die STM8 uC sind vom
> 6502 abgeleitet:

Nicht wirklich. Außer bei der Tatsache, dass es sich bei beiden um eine 
"Akku-Architektur" handelt, hat der STM8 fast nix mit dem 6502 zu 
schaffen.

Da gibt es andere (auch heute noch kaufbare) µC mit einer MCU, die dem 
6502 doch sehr viel ähnlicher ist...

Aber, warum sollte man das überhaupt wollen? Der 6502 war schon zu 
seiner Zeit kein Glanzstück, sondern nur vergleichweise billig und hat 
nur deshalb die hohe Verbreitung erreicht (in den meisten Fällen auch 
damals nichtmal im Original, sondern in abgewandelten Varianten).

Wer sich heute noch ernsthaft damit befasst, verschwendet Lebenszeit.

von (prx) A. K. (prx)


Lesenswert?

c-hater schrieb:
> Wer sich heute noch ernsthaft damit befasst, verschwendet Lebenszeit.

Wer keine Lebenszeit verschwenden kann ist wahrhaft arm dran.

von c-hater (Gast)


Lesenswert?

(prx) A. K. schrieb:

> Wer keine Lebenszeit verschwenden kann ist wahrhaft arm dran.

Diese Aussage hat durchaus eine gewisse Berechtigung, würde ich mal 
sagen.

Wenn ich mir anschaue, was ich in den letzten Jahren so als Hobbyprojekt 
umgesetzt habe, ist da etliches dabei, was ich auf Arbeit sicher nicht 
so gemacht hätte...

Aber es hat Spaß gemacht und somit ist es dann doch keine verschwendete 
Lebenszeit.

von Franko P. (sgssn)


Lesenswert?

Hallo
mein erster "Computer" war auch einer mit 6502, der Junior Computer von 
Elektor. Bei ebay gibts noch einen;
https://www.ebay.de/sch/i.html?_from=R40&_trksid=p2380057.m570.l1313&_nkw=elektor+junior+computer&_sacat=0

Meiner hat irgend wann den Geist aufgegeben. Die alten Chips hatten 
damals noch nicht die "Lebenszeit" wie heutiche.

Gruß
Gerhard

: Bearbeitet durch User
von c-hater (Gast)


Lesenswert?

Franko P. schrieb:

> Meiner hat irgend wann den Geist aufgegeben. Die alten Chips hatten
> damals noch nicht die "Lebenszeit" wie heutiche.

Das kann ich so nicht bestätigen. Ich besitze immer noch einen voll 
funktionsfähigen Atari800XL, gekauft 1986.

Ich würde mal davon ausgehen, dass nix, was du heute als Consumer kaufen 
kannst, 35 Jahre ohne Reparatur laufen wird...

von Franko P. (sgssn)


Lesenswert?

Hi
der elektor junior computer stammte so von 1980. Was da den Geist 
aufgegeben hat, weiss ich nicht. Auf dem Board war ja nicht viel drauf. 
Vielleicht wars ja nur das Eeprom. Keine Ahnung, hat auf jeden fall 
keinen mux mehr gemacht.
:-(

von Percy N. (vox_bovi)


Lesenswert?

c-hater schrieb:
> Wenn ich mir anschaue, was ich in den letzten Jahren so als Hobbyprojekt
> umgesetzt habe, ist da etliches dabei, was ich auf Arbeit sicher nicht
> so gemacht hätte...
>
> Aber es hat Spaß gemacht und somit ist es dann doch keine verschwendete
> Lebenszeit.

Seltsam nur, dass kaum jemand seine Arbeitszeit als vertane Lebenszeit 
ansehen mag, auch wenn sie kaum mehr eingebracht hat als wirtschaftliche 
Vorteile.

von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


Lesenswert?

6502 war eine schöne CPU mit vielfältigen Adressierungsmöglichkeiten 
aber bescheuerter Registerauswahl...

Ich hab ihn gerne programmiert und würde heute noch bei jedem HEX-Code 
erkennen, ob es für 6502 ist.

Die 6502-SBCs aus der Zeit sind erstaunlich stabil:

http://www.wolfgangrobel.de/sbc/junior.htm
http://www.wolfgangrobel.de/sbc/junior2.htm
http://www.wolfgangrobel.de/sbc/aim65.htm
http://www.wolfgangrobel.de/sbc/aimusa.htm
http://www.wolfgangrobel.de/sbc/kim1.htm
http://www.wolfgangrobel.de/sbc/kim1a.htm

Die gehen heute alle noch - wie mein Apple IIc Clone...

von MCUA (Gast)


Lesenswert?

>Ich hab ihn gerne programmiert und würde heute noch bei jedem HEX-Code
>erkennen, ob es für 6502 ist.
Du würdest aber (schon ab den 70ern) ein 6800 oder gar ein 6809 viel 
lieber programmieren.
8-Bit-Index-Register ist so ziemlich das bescheuertste was einem bei 
einer CPU passieren kann. ...noch nichtmal simpler Index-Zugriff auf 512 
Bytes möglich.

von Andreas B. (bitverdreher)


Lesenswert?

MCUA schrieb:
> 8-Bit-Index-Register ist so ziemlich das bescheuertste was einem bei
> einer CPU passieren kann. ...noch nichtmal simpler Index-Zugriff auf 512
> Bytes möglich

Das hatte ich damals nie vermißt. Notfalls macht man das indirekt 
indiziert.

von Percy N. (vox_bovi)


Lesenswert?

Andreas B. schrieb:
> Das hatte ich damals nie vermißt. Notfalls macht man das indirekt
> indiziert.

Irgendwer scheint damals zumindest auf dem 8080, der immerhin das 
virtuelle M-Register hatte, die erweiterten (teilweise inoffiziellen) 
OPs des Z80 so sehr vermisst zu haben, dass der iA86 entsprechend 
ausgelegt wurde.

von (prx) A. K. (prx)


Lesenswert?

MCUA schrieb:
> Du würdest aber (schon ab den 70ern) ein 6800 oder gar ein 6809 viel
> lieber programmieren.

6809 ja, aber nicht 6800. Die hatte zwar ein 16-Bit Indexregister, aber 
nur eines, und das war eindeutig zu wenig.

Demgegenüber hatte die 6502 quasi 128 16-Bit Indexregister.

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?

MCUA schrieb:
> 8-Bit-Index-Register ist so ziemlich das bescheuertste was einem bei
> einer CPU passieren kann. ...noch nichtmal simpler Index-Zugriff auf 512
> Bytes möglich.

und trotzdem war es möglich, bei meinem ersten PET2001, bei meinem 
zweiten apple2 Nachbau.
War kein Problem mit HEX auf Käsekästchen und hatte mich damals an µC 
und ASM gebracht.

Es hat Spass gemacht und vertane Lebenszeit war es nicht, so war meine 
erste Aufgabe in der Prüftechnik eine Mittelwertroutine in ASM und das 
noch ohne Macroassembler.

von MCUA (Gast)


Lesenswert?

1 16-Bit Indexregister ist immer noch besser als irgent welche 
8-Bit-Indexregister (weil Pointerbreite einfach zu gering).
(was nicht heisst, dass 2 oder 3 nicht besser wäre als 1)
Auch wenn man RAM-Speicher mit für adress. benutzen kann, hatte der 6502 
keine 128 Indexregister.
(es gibt auch heute noch CPUs, die Memory, RAM-Speicher für adress. mit 
benutzen können; trotzdem haben die nicht unzählige Register)
Register ist nicht Memory.

von (prx) A. K. (prx)


Lesenswert?

MCUA schrieb:
> 8-Bit-Indexregister (weil Pointerbreite einfach zu gering).

Die 6502 war eigentlich nicht dafür gedacht, mit 64kB RAM pointerlastige 
C-Programme auszuführen (*). Sondern eher in Richtung Mikrocontroller. 
Da sind 2 8-Bit Indexregister besser als eines mit 16, weil die weitaus 
meisten Tabellen klein genug sind.

Wo das nicht ausreichte, verwendete man (zp),y und konnte ganz gut damit 
leben. Der Fehler war (zp,x) statt (zp),x. Das wurde so gut wie nie 
gebraucht.

> Auch wenn man RAM-Speicher mit für adress. benutzen kann, hatte der 6502
> keine 128 Indexregister.

Du übersiehst mein "quasi". Die Zeropage wurde dafür intensiv genutzt. 
Das war auch wahrlich nicht die erste Architektur, die Pointer im RAM 
liegen hatte. Typen von DEC und Data General fallen mir dazu ein. 
Register waren damals sehr teuer.

> Register ist nicht Memory.

Man kann sie als erste Stufe der Speicherhierarchie betrachten.

Wieviele Universalregister hatte TIs 990/9900? Aus Sicht des 
Assembler-Programmierers waren es 16, alle im RAM.

*: Das war zwar auch mit 8080 kein Spass, aber unterschiedliche Sprachen 
und Programmiertechniken legen unterschiedlich viel Wert auf Pointer in 
voller Breite. Zilog orientierte sich beim Nachfolger der Z80 an den 
Erfordernissen von Fortran, hatte aber Pech, weil die Leute lieber C 
verwendeten.

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?

(prx) A. K. schrieb:
> Zilog orientierte sich beim Nachfolger der Z80 an den
> Erfordernissen von Fortran, hatte aber Pech, weil die Leute lieber C
> verwendeten.

noch lieber war mir dann die LH5801/5803 im sharp PC1500

Einen pi0-Takt zur synchronen Übernahme (um eine VIA 65C22 anzusteuern) 
und statische 16-Bit Register wie im z80.
Man konnte praktisch alles anschliessen und machen!
Doof war nur das man den PC (program counter) nur indirekt auslesen 
konnte um mit Stackmanipulation verschiebbaren Code zu erzeugen mit 
relokatible SUBs mittels branch +- und rts.

: Bearbeitet durch User
von MCUA (Gast)


Lesenswert?

>Die 6502 war eigentlich nicht dafür gedacht, mit 64kB RAM pointerlastige
>C-Programme auszuführen
Das war ja schon der Fehler.
Auch in den 70ern war ein Mem-Bereich von 256 Byte schon viel zu klein.
Wenigstens einige kB hätte man dafür vorsehen sollen, also vielleicht 
Index-Reg mit wenigstens 12..14 Bit Breite.
Auch hat effiziente Programmierung nichts mit irgent einer (benutzten) 
Hochsprache, oder mit C, zu tun (denn die kann die Fehler in der CPU 
nicht ausbügeln, bestenfalls verschleiern).


> Register ist nicht Memory.
Register können rechnen (somit auch speichern) Memory nicht.

Damit aus RAM/FFs Register werden müssen deren Ein- u Ausgangs-Ports 
parallel zugänglich sein, auf ALU geführt werden, ALU-Ausgang muss auf 
RAM-Eingangs-Port geführt sein.

Davon ist der 6502 meilenweit entfernt.

von Andreas B. (bitverdreher)


Lesenswert?

MCUA schrieb:
> Auch in den 70ern war ein Mem-Bereich von 256 Byte schon viel zu klein.

Hmm, also ich weiß ja nicht, in welchen 70ern Du gelebt hast. Für mich 
waren das die Zeiten mit 8080, Z80 ect. Und am Ende der 70er kam dann 
erst der 68000 auf.

von MCUA (Gast)


Lesenswert?

1974 hat 1kB SRAM ca 105,00 $ gekostet, 1 Jahr später bereits nur die 
Hälfte.
Also kann man nicht behaupten, einige kB Speicherbereich wäre völlig 
übertrieben.
Und wenn es Anfangs 70er schon zu klein war, war es Ende 70er erst recht 
zu klein.

von (prx) A. K. (prx)


Lesenswert?

MCUA schrieb:
> Auch hat effiziente Programmierung nichts mit irgent einer (benutzten)
> Hochsprache, oder mit C, zu tun

Die hauptsächlich verwendeten Adressierungen haben zwar auch mit der zu 
lösenden Aufgabe zu tun, aber insgesamt auch sehr viel mit der 
verwendeten Sprache.

Einige typische Adressierungsarten sind
1
  (1) konstante Adresse
2
  (2) variable Adresse
3
  (3) konstante Adresse + variabler Index
4
  (4) variable Adresse + konstanter Index
5
  (5) variable Adresse + variabler Index

In jenen Anwendungsbereichen, die man bei der Entwicklung der 6502 im 
Auge hatte, dominieren bei Datenadressierung (1) und (3). Typische 
ROM-Bausteine hatten anfangs 4KB, RAMs 0,5kB. Mehr Index als 8 Bits war 
in dieser Dimension nur selten nötig. Man dachte damals nicht in die 
Ferne, sondern nur bis zum nächsten Laternenpfahl.

Die Sprache spielt eine Rolle, da die Häufigkeit dieser 
Adressierungsarten abhängig von der Sprache ist. So nutzt Fortran 
(1,2,3,5). (4) spielte im damaligen Fortran eine geringe Rolle. Sie ist 
jedoch in C Programmen extrem häufig (Ausnahme: Compiler mit statischer 
Adressierung lokaler Variablem, z.B. beim 8051).

Solange Adresse und Index gleich breit sind, besteht zwischen (3) und 
(4) kein Unterschied. Das betrifft beispielsweise PDP-11, 8086 small 
model, Z8000 non-segmented: 16 Bit Adresse und 16 Bit Index.

Ist die Adresse aber breiter als ein Index, sind (3) und (4) 
verschieden. Bei 6502 und Z8000 segmented mode entschied man sich für 
(1,2,3), bei 68000 für (1,2,4,5). Die Z8000 hatte (4,5) nur bei LD/ST, 
nicht als allgemeine Adressierung. Deshalb war die Umsetzung von 
typischem C Code aus dem Unix Umfeld für Z8000 weniger effizient als für 
68000.

von Andreas B. (bitverdreher)


Lesenswert?

MCUA schrieb:
> Also kann man nicht behaupten, einige kB Speicherbereich wäre völlig
> übertrieben.

OK, wenn Du den gesamten Speicher meinst (das hatte ich mißverstanden), 
aber wer will denn über den gesamten Speicher Indextabellen anlegen?

von (prx) A. K. (prx)


Lesenswert?

MCUA schrieb:
> Register können rechnen (somit auch speichern) Memory nicht.

Üblicherweise können sie nicht rechnen. Mit Ausnahme eines als 
Hardware-Zähler implementierten Program Counters sind Register lediglich 
Speicherstellen für irgendwelche Daten. Rechnen tut eine Recheneinheit, 
die z.B. Daten von irgendwo liest und nach irgendwo schreibt.

Bezogen auf die Sicht des Assembler-Programmierers kann eine 6502 ebenso 
gut mit Speicher rechnen wie mit dem Akku. Ob ADC #1 oder INC zp, in 
beiden Fällen wird eine Speicherstelle gelesen und wieder geschrieben. 
Nur ist es im einen Fall der Akku, im anderen Fall das RAM, und es 
dauert beim Speicher länger.

Falls dabei ein nicht für den Programmierer sichtbares Temporärregister 
eine Rolle spielen könne - geschenkt. Hier geht es um das, was der 
Programmierer von der Maschine sieht.

> Register können rechnen (somit auch speichern) Memory nicht.

Speichern kann auch der Speicher, selbst wenn das sprachlich auf 
Englisch nicht so ins Auge springt wie auf Deutsch. Vielleicht nennt IBM 
den ja deshalb Storage statt Memory. ;-)

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


Lesenswert?

MCUA schrieb:
> war es Ende 70er erst recht zu klein.

Langfristige Planung war damals nicht angesagt, man baute für den 
Moment, nicht für die Zukunft. Intels 8051 und Zilogs Z8 sind Beispiele 
für Architekturen, bei denen nie mehr als ein 8-Bit Adressraum für 
skalare Daten angedacht war. Beim 8051 kämpfen die Leute bis heute 
damit, dass diese Architektur viel viel länger lebt als vorgesehen, via 
Compiler und seltsamen Speicherplatzangaben in C.

Entwicklungsziel der 6502 war ein günstiger Preis. 16-Bit Indexregister 
waren damals teuer, wenn auf dem Chip. 2 Bytes Speicher für den gleichen 
Zweck waren billig.

Intel hatte selbst bei der Segmentierung von 80286 nicht weiter als bis 
zum nächsten Laternenpfahl gedacht. Und sich deshalb später kräftigst in 
den Hintern gebissen, als Snooping von Segment-Deskriptoren nötig wurde, 
wo eine bessere Befehlsdefinition genauso einfach aber auf Dauer viel 
effektiver gewesen wäre.

: Bearbeitet durch User
von MCUA (Gast)


Lesenswert?

>Langfristige Planung war damals nicht angesagt, man baute für den
>Moment, nicht für die Zukunft.
Und 6800, 6809??
Der konnte es.

Auch damalige Mini-Computer konnten es.
Und wieviele und wie breite Register hatte eine IBM 360?


>Intels 8051...
ja der hat extreme Probleme mit allem was über 256 Byte hinaus geht 
(DPTR!!).
aber das war lediglich ein Steuerungscontroller, sozusagen keine 
richtige CPU.

>Intel hatte selbst bei der Segmentierung von 80286 ..
Hatten die 8-Bit-Indexregister?

von (prx) A. K. (prx)


Lesenswert?

MCUA schrieb:
>>Langfristige Planung war damals nicht angesagt, man baute für den
>>Moment, nicht für die Zukunft.
> Und 6800, 6809??
> Der konnte es.

Die 6809 kam zu spät. Motorola hatte zwar aus den Fehlern der 6800 
gelernt. Aber da war der Zug schon praktisch abgefahren.

> Auch damalige Mini-Computer konnten es.

Von Aufwand und Komplexität her sind wir eher bei der PDP-8 als bei der 
PDP-11. Und die PDP-8 hatte überhaupt keine Indexregister. Berechnete 
oder indirekte Adressierung fand über das RAM statt, inklusive 
auto-inkrement.

MCUA schrieb:
>>Intel hatte selbst bei der Segmentierung von 80286 ..
> Hatten die 8-Bit-Indexregister?

Ich hatte das als Beispiel für typische Zukunftsplanung dieser Ära 
genannt, nicht als pinkompatible Implementierung. Davon gabs noch mehr, 
beispielsweise den 26-Bit Program Counter von ARM. Sogar IBMs eigentlich 
auf grosse Implementierungsbreite und Zukunft geplante 360 fiel mit 
ihrem 24-Bit Program Counter später auf die Nase.

: Bearbeitet durch User
von Genau (Gast)


Lesenswert?

War damals eigentlich alles patentiert und reserviert ? Also auch die 
Registerbreite und deren Nutzung ?

von Heiner (Gast)


Lesenswert?

Winfried J. schrieb:

> Genau deshalb mag ich den 6502 und auch die AVR, alles klar und
> übersichtlich. Das ist schmeichelt einem einfach strukturierten alten
> Freak und wenn der Adressraum nicht reicht dann gibt es noch
> Memorymapping.

Wieder einer der den Anschluss an die Moderne verpasst hat und im 
letzten Jahrtausend stehengebliebenen ist. Traurig.

Allen anderen: ein fröhliches Plaste & Elaste :)

von (prx) A. K. (prx)


Lesenswert?

Registerbreiten sind wohl etwas schwer zu patentieren, andernfalls 
hätten wir zwischendrin vielleicht auch schon 11- und 17-Bit-Register 
gesehen.

Mehrere Hersteller machten sich immerhin die Mühe, abgekupferte 
Befehlssätze umzubenennen. Die Befehle der Z80 kennen wohl einige hier, 
aber wer kennt Intels Originalbezeichnungen? Die stark abweichende 
Mnemotechnik von NECs 8088/86-kompatiblen V20/V30 hingegen hat nie 
jemand freiwillig verwendet.

Ich interpretiere das so, dass man zwar gefahrlos die Befehle verwenden 
konnte, aber beim Copyright der Doku aufpassen musste.

: Bearbeitet durch User
von GeraldB (Gast)


Lesenswert?

c-hater schrieb:
> Aber, warum sollte man das überhaupt wollen? Der 6502 war schon zu
> seiner Zeit kein Glanzstück,

Aber sicher war er das. Immerhin war er ca. 4 mal so schnell wie eine 
Intel-CPU.

von c-hater (Gast)


Lesenswert?

GeraldB schrieb:

> Aber sicher war er das. Immerhin war er ca. 4 mal so schnell wie eine
> Intel-CPU.

4x so schnell wie welche Intel-CPU?

von (prx) A. K. (prx)


Lesenswert?


von Schlaumaier (Gast)


Lesenswert?

c-hater schrieb:
> Aber, warum sollte man das überhaupt wollen? Der 6502 war schon zu
> seiner Zeit kein Glanzstück,

Also ich war sehr zufrieden mit den Teil. Ich habe sogar im Keller noch 
1 Gerät was den eingebaut hat.  (1541 genannt) ein schöner grauer Kasten 
mit einen Turbo schnellen Zusatzkarte ;)

Würde mich echt interessieren ob das Teilchen noch läuft. ;)

Davon abgesehen. Die bester Doku. für den Chip gibt es in 
Spezialfachbüchern zu 1541 auf den Flohmarkt.

von Percy N. (vox_bovi)


Lesenswert?

(prx) A. K. schrieb:
> Mehrere Hersteller machten sich immerhin die Mühe, abgekupferte
> Befehlssätze umzubenennen. Die Befehle der Z80 kennen wohl einige hier,
> aber wer kennt Intels Originalbezeichnungen?

Halb so schlimm, intel hat lediglich mehr Namen für Befehle verwendet, 
wo Zilog mit syntaktischen Feinheiten auskam.
Zugegeben, MVI statt MOV zu schreiben erfordert Konzentration, aber 
darauf zu achten, wie es nach MOV denn nun weiter geht, auch.

Alles harmlos gemessen an dem, was dann mit dem i86 kam ...

von Percy N. (vox_bovi)


Lesenswert?

c-hater schrieb:
> 4x so schnell wie welche Intel-CPU?

Ein 4004 auf 500 kHz ...

von MCUA (Gast)


Lesenswert?

Diese Zero-Page ist definitv kein Registersatz. (s.o.)
Akku und diese Zero-Page-Teile sind nicht austauschbar.

Ein 16-Bit Ind-Register hätte mit Sicherheit keine zu grosse 
Kostensteigerung bewirkt.
Man hat hier zuviel und an falschen Stellen gespart.

> Man dachte damals nicht in die Ferne, sondern nur bis zum nächsten 
Laternenpfahl.
Beim nächsten Laternenpfahl standen! aber schon einige kB's (die wie 
genannt nicht sehr teuer waren), und die konnte man eben nicht 
vernunftig adressieren.

>Typische ROM-Bausteine hatten anfangs 4KB, RAMs 0,5kB
1975 hat von Intel ein 256-Bit-SRAM ca 1,75$ gekostet, eins mit 1024 
Bits ca 7,00$.
Und wo steht dass man nur je 8 Bauteine davon verwenden kann und nicht 
mehr als 56$ ausgeben kann?


Bei CPU-Architektur interessiert ein Compiler definitv überhaupt nicht.
Denn der muss sich nach der CPU richten (kann nur das umsetzen was die 
CPU auch kennt),
also ist es völlig unerheblich wie hier irgent ein Compiler es gemacht 
oder nicht gemacht hat.
(jede Sprachen-Syntax kann man (mit mehr oder weniger Aufwand) auf jede 
CPU-Architektur anwenden)

von (prx) A. K. (prx)


Lesenswert?

MCUA schrieb:
> Bei CPU-Architektur interessiert ein Compiler definitv überhaupt nicht.
> Denn der muss sich nach der CPU richten (kann nur das umsetzen was die
> CPU auch kennt),

CPU Architekturen orientieren sich daran, was von ihnen erwartet wird. 
Und dazu gehört u.A. seit langem eine effiziente Umsetzbarkeit der 
gängigen Programmiersprachen. Umgekehrt orientieren sich 
Programmiersprachen mitunter auch an dem, was die real existierende 
Hardware hergibt. Besonders C.

Das reimt sich nicht immer, denn weder 8051 noch die älteren 8-Bit PICs 
eignen sich sonderlich für C, aber man tat es trotzdem, die Hardware war 
da und es musste halt sein.

In den 70ern stellte man eine deutliche Diskrepanz zwischen dem fest, 
was Compiler brauchten, und dem, was die Maschinen lieferten. Dies 
führte zur IBM 801 und auch zur offenen RISC Diskussion der 80er.

Es gibt also einen klaren Zusammenhang zwischen Prozessor-Architektur 
und Compilern. Da verschiedene Sprachen verschiedene Anforderungen an 
Maschinen haben, spielt es eine Rolle, welche Sprachen man bei der 
Konzeption im Auge hat.

> also ist es völlig unerheblich wie hier irgent ein Compiler es gemacht
> oder nicht gemacht hat.

Bei der 6502 ist das so, denn die wurde weder für irgendwelche 
Hochsprachen konzipiert, noch wurden m.W. in grossem Umfang Compiler 
dafür eingesetzt.

> (jede Sprachen-Syntax kann man (mit mehr oder weniger Aufwand) auf jede
> CPU-Architektur anwenden)

Obzwar die Turing-Maschine grosse Bedeutung hat, und auch die Bedeutung 
der Sprache C nicht zu leugnen ist, bin ich noch nie einem C Compiler 
für sie begegnet. Auch wenn das zweifelsfrei möglich wäre. Das könnte 
auch daran liegen, dass es nicht nur theoretisch funktionieren muss, 
sondern das Ergebnis praktischen Sinn haben soll.

Soll heissen: Wenns gut läuft, dann zählt nicht so sehr, was man tun 
kann, sondern was man tun sollte. Unsinn zu machen, bloss weil man es 
kann, bleibt Unsinn.

: Bearbeitet durch User
von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


Angehängte Dateien:

Lesenswert?

Meine 6502 ist eh Schrott, da funktioniert nicht mal ROR...

;-)

von Josef G. (Gast)


Lesenswert?

Apropos Turing-Maschine: Hat die Interrupts?

von (prx) A. K. (prx)


Lesenswert?

Josef G. schrieb:
> Apropos Turing-Maschine: Hat die Interrupts?

Braucht sie nicht, geht ganz theoretisch auch ohne. Kann nur sein, dass 
sie dafür ein "Bisschen" mehr Tempo braucht und ihr dann ganz praktisch 
das Band wegfliegt.

: Bearbeitet durch User
von MCUA (Gast)


Lesenswert?

>CPU Architekturen orientieren sich daran, was von ihnen erwartet wird.
Gut zu programmieren, heisst eine effiziente CPU zu haben (gut und effi 
in ASM zu progr.), unabhängig von Compiler.
Der Compiler kommt später und muss womöglich für weniger effiz CPUs 
gemacht werden.

Wie auf Speicher zugegriffen wird (gut, umständlich, unnötig usw) ist 
direkt am ASM der CPU zu sehen, da muss man nicht erst irgent einen 
Compiler machen.
(Marketing-Gequatsche)
Dass der 8051 umständlich zu handhaben ist (jedenfalls wenn grösser 256 
Byte) ist am ASM zu sehen, da bracht man keinen Compiler(bauer) zu 
fragen.

>Es gibt also einen klaren Zusammenhang zwischen Prozessor-Architektur und 
Compilern.
Nö.

>Da verschiedene Sprachen verschiedene Anforderungen..
Egal wie man es nennt, ein guter, effizient. Speicherzugriff ist IMMER 
(selbstverständl. auch in ASM) nötig und sinnvoll,
also kann man das mit "Sprachen" ausklammern.


>Bei der 6502 ist das so, denn die wurde weder für irgendwelche Hochsprachen 
konzipiert,..
Die CPU hätte nur mit effizienten Adress.Möglichkeiten konzipiert sein 
müssen, dann wäre es gut gewesen.
Compiler hätten das dann auch nutzen können.

Jede Sprachen-Syntax passt auf jede CPU.
(und es gibt nicht nur eine, sondern hunderte Möglichkeiten, wie 
bsp.weise in ein Call (oder Methode oder wie auch immer man das nennen 
will) verzweigt wird.

von (prx) A. K. (prx)


Lesenswert?

MCUA schrieb:
> Jede Sprachen-Syntax passt auf jede CPU.

Du weisst, was "Syntax" in diesem Zusammenhang bedeutet?

von Genau (Gast)


Lesenswert?

Damals musste extrem an Speicherplatz gespart werden für die 
8-Bit-Systeme - siehe zB. die Modulgrößen der NES-Spiele oder davor beim 
Atari 2600. Das ging bestimmt nur mit Assembler-Sprache plus Tricks.

von chris_ (Gast)


Lesenswert?

A. K. (prx)
>CPU Architekturen orientieren sich daran, was von ihnen erwartet wird.
>Und dazu gehört u.A. seit langem eine effiziente Umsetzbarkeit der
>gängigen Programmiersprachen. Umgekehrt orientieren sich
>Programmiersprachen mitunter auch an dem, was die real existierende
>Hardware hergibt. Besonders C.

Wenn Ich's recht weiß, hat man beim Entwurf der AVR-Architektur stark 
auf die Bedürfnisse eines C-Compilers geachtet, was zu einer recht guten 
Performance für die Umsetzung von C in den Maschinencode des AVRs führt.

Vielleicht kannst Du das bestätigen?

von (prx) A. K. (prx)


Lesenswert?

chris_ schrieb:
> Vielleicht kannst Du das bestätigen?

"This paper describes the AVR architecture, and the changes that were 
undertaken in the architecture and instruction set during the compiler 
development phase in order to make the AVR family of microcontrollers 
very suitable targets for a C compiler."

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.63.1447

: Bearbeitet durch User
von chris_ (Gast)


Lesenswert?

>http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.63.1447
Super, danke.

Damit hat sich die Ansicht von

 MCUA (Gast)
13.10.2020 23:07
>Gut zu programmieren, heisst eine effiziente CPU zu haben (gut und effi
>in ASM zu progr.), unabhängig von Compiler.
>Der Compiler kommt später und muss womöglich für weniger effiz CPUs
>gemacht werden.

wohl erledigt.

von MCUA (Gast)


Lesenswert?

>Wenn Ich's recht weiß, hat man beim Entwurf der AVR-Architektur stark
>auf die Bedürfnisse eines C-Compilers geachtet,
Was bitte soll da speziell wegen C gemacht worden sein?
Die 3 16-Bit-Index Register (die zudem nichmal gleichartig 
funktionieren)?
Ein Speicher, der ein Stack beinhalten kann?
Dass man Werte an Ports ausgeben kann?
Auf das bisschen Zeug kommt man OHNE C-Compiler.
Man sieht es direkt an ner CPU.
Es ist Marketing-Gelabere.

>..very suitable targets for a C compiler."
Das ist Marketing-Gelabere.
Und immer wieder fallen Leute (wohl auch weil sie es einfach nicht 
kapieren) drauf rein.
(und ganz Naive schwatzen alles nach, was sie irgentwo gelesen haben)

von moep (Gast)


Lesenswert?

Also bei mouser gibts die CMOS Version (wieder):
https://www.mouser.de/ProductDetail/Western-Design-Center-WDC/W65C02S6TPG-14?qs=opBjA1TV903lvWo9AEKH5w%3D%3D

Die gängige Peripherie wie 65C22 wird auch angeboten

von nop (Gast)


Lesenswert?

MCUA schrieb:
>>..very suitable targets for a C compiler."
> Das ist Marketing-Gelabere.

Nein, das stimmt schon. Fehlende 16 Bit-Register und ein zu kleiner 
Stack sind enorme Einschränkungen.

- Der Stack wird sowohl zur Parameterübergabe als auch für lokale 
Variablen benutzt. Da werden 256 byte schnell knapp. Ein brauchbarer 
C-Compiler müsste einen eigenen Stack emulieren. Kostet.
- Man kann nur den Akku direkt auf den Stack pushen. Die Indexregister 
müssen vorher in den Akku geschoben werden. Kostet.
- Ohne 16-Bit Register müssen viele Operationen in zwei 8-Bit 
Operationen zerlegt werden. Selbst ein for (i=0;i<1024;i++). Kostet.

Man kann das alles auf dem 6502 implementieren, aber es wird niemals 
effizient.

$EA

von (prx) A. K. (prx)


Lesenswert?

nop schrieb:
> Man kann das alles auf dem 6502 implementieren, aber es wird niemals
> effizient.

C auf 6502 ist Krampf. Macht das ernsthaft jemand?

> - Der Stack wird sowohl zur Parameterübergabe als auch für lokale
> Variablen benutzt.

Das ist zwar in C üblich, aber nur, wenn es auch sinnvoll möglich ist. 
Beim 8051 und bei älteren 8-Bit PICs adressieren die Compiler Parameter 
und lokale Variablen vorzugsweise statisch, statt über Stack. Ggf mit 
Analyse der Aufrufe, um Mehrfachbelegung des RAMs zu ermöglichen. Muss 
eine Funktion unbedingt reentrant oder gar rekursiv sein, wird es 
deshalb kompliziert.

: Bearbeitet durch User
von nop (Gast)


Lesenswert?

(prx) A. K. schrieb:
> C auf 6502 ist Krampf. Macht das ernsthaft jemand?

cc65 hat das durchgezogen, mit erstaunlichen Ergebnissen. Natürlich 
fehlt Fliesskommaarithmetik, und man muss ein paar Regeln beachten, wenn 
man effizienten Code will:

https://cc65.github.io/doc/coding.html

$EA

von MCUA (Gast)


Lesenswert?

>>> ..very suitable targets for a C compiler."
>> Das ist Marketing-Gelabere.
> Nein, das stimmt schon. Fehlende 16 Bit-Register und ein zu kleiner
> Stack sind enorme Einschränkungen.
A ja ???  Nur bei C ???

von Joachim D. (Firma: JDCC) (scheppertreiber)


Lesenswert?

Ich hatte den Manx Aztek CG65 Crosscompiler, das hatte schon
funktioniert. Assembler ist beim 6502 aber fast einfacher
(vom Flußdiagramm direkt eintippen, sind ja nur eine handvoll
Befehle).

von nop (Gast)


Lesenswert?

MCUA schrieb:
> A ja ???  Nur bei C ???

Nein, das gilt natürlich für alle Hochsprachen, die Funktionsparameter 
oder lokale Variablen haben, oder rekursive Funktionen erlauben. Mit 
Pascal müsste man die gleichen Klimmzüge machen.

$EA

von (prx) A. K. (prx)


Lesenswert?

nop schrieb:
> cc65 hat das durchgezogen, mit erstaunlichen Ergebnissen.

Habs mir mal kurz angesehen. Wo immer C nicht ziemlich direkt auf die 
Maschine abbildbar ist, und das ist sehr oft der Fall, besteht der Code 
aus einer Serie von Calls von Laufzeitfunktionen. Die bilden eine Art 
Pseudomaschine. Dieses Prinzip kann man natürlich auf jede Maschine 
anwenden.

: Bearbeitet durch User
von MCUA (Gast)


Lesenswert?

>>>>> ..very suitable targets for a C compiler."
>>>> Das ist Marketing-Gelabere.
>>> Nein, das stimmt schon. Fehlende 16 Bit-Register und ein zu kleiner
>>> Stack sind enorme Einschränkungen.
>> A ja ???  Nur bei C ???
> Nein, das gilt natürlich für alle Hochsprachen, die Funktionsparameter
> oder lokale Variablen haben, oder rekursive Funktionen erlauben. Mit
> Pascal müsste man die gleichen Klimmzüge machen.
Das gilt mindestens! genauso auch für ASM.
Also ist es doch Marketing-Gelabere.

von Manfred (Gast)


Lesenswert?

moep schrieb:
> Die gängige Peripherie wie 65C22 wird auch angeboten

Müsste ich noch vorrätig haben. Und im Regal liegt noch ein Huntsville 
InCircuit-Emulator, das wird über 30 Jahre her sein, dass ich den 
benutzt habe. Ich habe tagelang Assembler geschrieben.

Es gibt eine heftige Falle: Die CMOS haben ein paar Befehle, die der 
NMOS nicht kennt. Der Emulator hat natürlich einen 65SC02 drin weil man 
den NMOS nicht anhalten kann.

Der geringere Stromverbrauch war ja ganz nett, das Störspektrum vom CMOS 
aber so, dass ich ihn im Prüfplatz für Rufempfänger nicht einsetzen 
konnte. Später habe ich dann zu einem "Trick" gegriffen, den CMOS-6502 
angehalten, Quarz aus und danach per Taste fortgesetzt. Da war die 
Personaldecke in der Werkstatt noch anständig und man hatte Zeit, sowas 
zu beforschen.

Wir konnten uns sogar eine eigene Leiterplatte gönnen, 6502 - 6522 - 
6532, SRAM, EEPROM und Pufferakku als Eurokarte. Keine Ahnung, wie viele 
Stunden ich das Handlayout geklebt habe, könnte dreistellig geworden 
sein.

(prx) A. K. schrieb:
> C auf 6502 ist Krampf. Macht das ernsthaft jemand?

Gab es damals schon C? Meine ersten 6502-Anwendungen habe ich per 
Makroassembler auf dem cbm3032 geschrieben, danach dann am 286er unter 
DOS.

von nop (Gast)


Lesenswert?

MCUA schrieb:
>>> A ja ???  Nur bei C ???
>> Nein, das gilt natürlich für alle Hochsprachen, die Funktionsparameter
>> oder lokale Variablen haben, oder rekursive Funktionen erlauben. Mit
>> Pascal müsste man die gleichen Klimmzüge machen.

> Das gilt mindestens! genauso auch für ASM.
> Also ist es doch Marketing-Gelabere.

Echt jetzt? Das wird mir zu blöd, ich bin raus.

$EA

von (prx) A. K. (prx)


Lesenswert?

Manfred schrieb:
> Gab es damals schon C?

Nicht für 6502, aber C ist ein paar Jahre älter.

Es gab auf dem AIM/65 allerdings einen minimalistischen Compiler in 8kB 
ROM für eine Sprache namens PL/65. Der hat den Code direkt aus der 
Syntax erzeugt, ohne Symboltabelle oder einer anderer Art von 
Gedächtnis:
http://retro.hansotten.nl/uploads/files/PL65MAN.txt

Den vollen Zyklus mit wenig RAM darf man sich so vorstellen:
- Quellcode von Band #1 laden (Kassettenrekorder)
- Quellcode im Editor ändern
- Quellcode auf Band #1 schreiben
- PL/65 Compiler starten
- Liest Quellcode von Band #1
- Schreibt Asm-Code auf Band #2
- Assembler starten (ROM)
- Liest Asm-Code in Pass 1 vom Band #2
- Liest Asm-Code in Pass 2 vom Band #2
- Schreibt Programm auf Band #1
- Programm von Band laden
- Ausführen
- Mist, zurück auf Anfang

Mit genug RAM konnte man das etwas abkürzen, aber Floppy-Disks gab es 
für den AIM/65 nicht.

: Bearbeitet durch User
von MCUA (Gast)


Lesenswert?

>Echt jetzt? Das wird mir zu blöd, ich bin raus.
Hast Schema nicht kapiert.

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.