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.
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.
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...
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! ;-)
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?
> 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.;-)
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.
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.
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!
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"
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.
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
da sollte eigentlich nochn Bild dranhängen!!! Is irgendwie durchgegangen.
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;-)
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
Gibts da auch ein Bildchen im Betrib? Hoffe ohne Rauchwolke.;-)
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
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.
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.
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).
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
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
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.
http://www.youtube.com/watch?v=I9-fIK7L5MM&feature=related http://www.youtube.com/watch?v=XFqjy-F0oQw&feature=related
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 ?
Reinhardt schrieb: > Gab es sowas > früher noch als Sourcecode ? Im Technical Reference Manual des orginalem IBM AT war dessen BIOS in Source abgedruckt.
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
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
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.
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.
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
Ob das jetzt 9 Jahre später noch jemanden interessiert? Ein neuer Thread wäre sinnvoller gewesen, wenn Du nur einen 6502 Rechner suchst.
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
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
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.
> 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.
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.
c-hater schrieb: > Wer sich heute noch ernsthaft damit befasst, verschwendet Lebenszeit. Wer keine Lebenszeit verschwenden kann ist wahrhaft arm dran.
(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.
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
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...
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. :-(
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.
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...
>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.
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.
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.
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
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.
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.
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
(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
>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.
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.
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.
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.
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?
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
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
>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?
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
War damals eigentlich alles patentiert und reserviert ? Also auch die Registerbreite und deren Nutzung ?
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 :)
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
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.
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?
Wer Sinn für bescheuerte Performance-Vergleiche hat: https://en.wikipedia.org/wiki/Instructions_per_second#Timeline_of_instructions_per_second
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.
(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 ...
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)
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
Meine 6502 ist eh Schrott, da funktioniert nicht mal ROR... ;-)
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
>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.
MCUA schrieb: > Jede Sprachen-Syntax passt auf jede CPU. Du weisst, was "Syntax" in diesem Zusammenhang bedeutet?
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.
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?
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
>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.
>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)
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
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
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
(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
>>> ..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 ???
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).
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
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
>>>>> ..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.
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.
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
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
>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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.