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