Ich möchte nach langer zeit mal wieder einen 6502 Programmieren, ist schon 30 Jahre her. Ich habe von den dingern leider keine Unterlagen mehr. Kennt jemand einen Basic oder Asemmbler Compiler für Windos/Dos oder Unterlagen? 6502.org war ich schon.
Guckst Du hier: http://media.ccc.de/browse/congress/2010/27c3-4159-en-reverse_engineering_mos_6502.html Da wird genau beschrieben wie der Funktioniert, auch besonders die Grundlagen und was sich die Entwickler dabei gedacht haben. Mit dem und einem Datenblatt mit Befehlsübersicht solltest Du damit zurecht kommen.
bastelhans schrieb: > Kennt jemand einen Basic oder Asemmbler Compiler für Windos/Dos oder > Unterlagen? Wenn du Glück hast, gibt es sogar einen ausgezeichneten Freeware C-Compiler: Ich schaute gerade mal in der Doku zum SDCC-Compiler, den ich für 8051 unter Vista nutze. Da ist tatsächlich was zum 6500 mit drin. Solch einen Assembler gibt es da auf jeden Fall. Ich weiß nur nicht genau, wie sich 6500 und 6502 unterscheiden. Suche mal unter dem Begriff "Sourceforge".
Danke schonmal für die Schnellen Antworten. Den R6500 habe ich auch noch rumliegen, Das ist ein 6502 mit eingepauten I/O Latch für vier 8bit Ports im 64 poligen Dualinlinegehäuse. Siehe Beitrag "r6500 von Rockwell"
Hallo, es gibt auch noch den TASM z.B. hier: http://www.ticalc.org/archives/files/fileinfo/15/1504.html Gruß Anja
bastelhans schrieb: > Ich habe von den dingern leider keine Unterlagen mehr. Hier gibts umso mehr: http://www.classiccmp.org/cini/systems.htm > Kennt jemand einen Basic oder Asemmbler Compiler für Windos/Dos oder > Unterlagen? Ein BASIC findet sich dort auch, ebenso ein PL/65-Compiler.
Wilhelm Ferkes schrieb: > Ich schaute gerade mal in der Doku zum SDCC-Compiler, den ich für 8051 > unter Vista nutze. Da ist tatsächlich was zum 6500 mit drin. Wirklich? In Doku und Source-Code finde ich nichts dazu, am nächsten käme noch der 68HC08.
Ich hab mal mit dem cc65 gearbeitet, funzt prima. Allerdings ist der C-Compiler nicht ganz Standardkonform (hatte aber kein Problem damit). http://www.cc65.org/ Wenn's spezifisch zum C64 sein soll, hier reinschnuppern: An Introduction to Programming C-64 Demos - http://www.antimon.org/code/Linus/ Viel Spass. :)
A. K. schrieb: > Wirklich? In Doku und Source-Code finde ich nichts dazu, am nächsten > > käme noch der 68HC08. Hast wohl recht. Zumindest fand ich dieses: APPENDIX N AS6500 ASSEMBLER N-1 Hat also zumindest den Assembler drinne.
Wilhelm Ferkes schrieb: > Hat also zumindest den Assembler drinne. Nu werde ich einen Compiler suchen um einen Assembler zu finden ;-). 6502-Assembler gibts viele, wie beispielsweise den AS, der anscheinend fast alles kann was sich im letzten Jahrtausend mal jemand an Mikroprozessoren und -controller einfallen lies: http://john.ccac.rwth-aachen.de:8000/as/
war das ding nicht im C64 drin? wieso programmierst du dann keinen C64? :)
Ben _ schrieb: > war das ding nicht im C64 drin? Im C64 war der 6510 verbaut. Der 6502 war in dessen Vorgänger, d.h im VC20 verbaut
> Im C64 war der 6510 verbaut. Der 6502 war in dessen Vorgänger, d.h im > VC20 verbaut ohhh, VC20, das war mein erster Rechner, ich war gerade in der Lehre zum Elektroniker und da kam grad der VC64 auf den Markt, war aber zu teuer... Michael :-)
> Im C64 war der 6510 verbaut. Der 6502 war in dessen Vorgänger, > d.h im VC20 verbaut Das ist ein Unterschied wie Ohrfeige und Backpfeife. Der 6510 hat lediglich einen zusaetzlichen 6-bit I/O Port. Ansonsten ist es die absolut identische CPU. Wer sich wirklich daran aufgeilt kann ja dann die 1541 Floppy programmieren. Die hat naemlich tatsaechlich einen 6502 drin, zusammen mit 2kB RAM. Es gibt einen DOS-Befehl, mit dem man Maschinencode direkt an die Floppy senden kann. Dann kann man mit der Floppy-LED morsen oder auf dem Schrittmotor Musik spielen. Ich wuerde aber auch den C64 empfehlen, da es viele gute Assembler und Monitorprogramme dafuer gibt und man direkt auf der Maschine coden kann. Mann muss nichts hochladen sondern startet einfach mit einem Tastendruck das Programm, mit einem weiteren Tastendruck kommt man zurueck in den Assembler. Und natuerlich hat der C64 die ganze interessante Peripherie, wie den VIC-II, den SID, Joystickports, Userport, Cartridge Port ... Hier gibts eine Anleitung fuer ein Hello World: http://www.youtube.com/watch?v=9hLGvLvTs1w Und wer keinen Platz hat kann das ganze natuerlich auch mit einem Emulator machen: http://www.viceteam.org/ Wenn man zwischendurch schnell was coden will: http://www.6502asm.com/ 6502 Assembler und Emulator in JavaScript.
Auch der Apple II hatte eine 6502 drin. Im Apple II+ kam dann noch eine Z80 hinzu. Damit konnte man dann CP/M fahren, um z.B. WordStar, dBase, Turbo Pascal 1.0 etc. zu benutzen.
Banane schrieb: > Im Apple II+ kam dann noch eine Z80 hinzu. Da bringst Du was durcheinander, kein Apple II (egal, ob Apple II, II+, IIe, IIc) hatte jemals eine Z80. Das gab es nur mit einer nachzurüstenden "CP/M-Karte" von Drittherstellern -- oder in Nachbauten.
@Rufus Deine Aussage trifft für Original Apple II zu. Bei den Clones gab es Mainboard mit 6502 und Z80. Für die Originalen brauchte man eine Microsoft Z80 Softcard (ohne RAM) oder eine Microsoft Premium Softcard mit eigenem RAM (64kB) und turboschnellen 6MHz Z80B Prozessor. Näturlich gab es die Z80 Karten auch als Clones. cu Georg PS: Ich spiele damit aus Nostalgie Gründen/Mid-Life-Crisis gerade damit rum.
Ich hatte meinen Apple II+ mit einer 68000 Karte mit 128MB Ram erweitert. Meine Enttäuschung war gross als ich dann einen 8088 PC kaufte. Das waren noch Zeiten! ;-)
Mittlerweile gibt es Nachbauten auf FPGA Basis. http://www1.cs.columbia.edu/~sedwards/apple2fpga/ oder http://www.applelogic.org/ cu Georg
68000 und 128 MB RAM - das passt nicht gut zusammen (vom Preis und den nur 24 Herausgeführten Addressleitungen). Wohl eher 128 kBytes.
Hast Recht! 128 kBytes Ram! Das kann man sich heute nicht mehr vorstellen! Waldo
> Mittlerweile gibt es Nachbauten auf FPGA Basis. Es gab schon seit langem diskret aufgebaute 6502, die mit > 50 MHz liefen. Hauptbeweggrund war die existierende Software, z.B. gute Schachprogramme. Auf einem FPGA sind weit höhere Taktfrequenzen machbar. Ja, mit dem 6502 haben wir damals viiiiiel Zeit verbracht. Die PET (Personal Electronic Transactor), CBM4000, CBM8000er Serie hatte auch welche drin. Beitrag "6502 / 6510 (C64) Emulator (momentan noch PC, später Controller) - Einige Fragen" Beitrag "Gute alte Zeiten :)"
Hermocrates schrieb: > Der 6510 hat > lediglich einen zusaetzlichen 6-bit I/O Port. Ansonsten ist es die > absolut identische CPU. Na ja, fast - der 6510 kann ausserdem seine Daten+Adressleitung (und R/W) auf Anforderung floaten, beim 6502 waren dafür externe Chips notwendig, zB 3*74244 im VC20. Ausserdem finde ich, dass man in diesem Thread auch mal http://www.visual6502.org verlinken sollte. =)
Aus so einem Nostalgiegefühl heraus hatte ich mal einen 6510-Echtzeitemulator für den AVR geschrieben und in dem KIM-1-Thread hochgeladen: Beitrag "Re: KIM-1 in AVR?" Vielleicht kann's ja in dem Zusammenhang hier mal jemand gebrauchen. Ist eigentlich eine lustige Sache da sich der AVR-IO verwenden lässt (bspw. USART) und man so eine Art 6510-µController hat. Mark
>68000 und 128 MB RAM - das passt nicht gut zusammen (vom Preis und den >nur 24 Herausgeführten Addressleitungen). Wohl eher 128 kBytes. Willst Du jetzt sagen, ein 68k kann nur 128kB adressieren? mit A0..23 sinds 16MB, nicht 128 kB.
MCUA schrieb: >>68000 und 128 MB RAM - das passt nicht gut zusammen (vom Preis und den >>nur 24 Herausgeführten Addressleitungen). Wohl eher 128 kBytes. > Willst Du jetzt sagen, ein 68k kann nur 128kB adressieren? > mit A0..23 sinds 16MB, nicht 128 kB. 16MB sind schon korrekt.... aber wie denkst du passt das mit 128MB zusammen?
Georg W. schrieb: > Deine Aussage trifft für Original Apple II zu. Bei den Clones gab es > Mainboard mit 6502 und Z80. Schrieb ich was anderes? > Das gab es nur mit einer nachzurüstenden "CP/M-Karte" von > Drittherstellern -- oder in Nachbauten.
Beim Mac IIfx sind übrigens sogar zwei 6502 als I/O-Koprozessoren vorhanden. Kann man per Software den Code reinladen, da RAM-Code Speicher.
@Rufus sorry. Irgendwie scheint mir die deutsche Grammatik Schwierigkeiten zu bereiten. Bzw. sollte man die Beiträge bis zum Ende lesen und nicht bei 90% aufhören und gleich lostippen :-( cu Georg
> 16MB sind schon korrekt.... aber wie denkst du passt das mit > 128MB zusammen? oder etwa 16 MWord, also 32 MByte? > Beim Mac IIfx sind übrigens sogar zwei 6502 als > I/O-Koprozessoren vorhanden. War das die Geschichte mit dem invertierten Takt? Phi1 und Phi2, so griffen die CPUs abwechselnd auf den Bus zu.
Ich hab noch einen Atari130XE auf 6502Basis +Floppy (unverkäuflich) nebst Schaltbild, ATARI inter(BS-Handbuch&Hardwareerklärung), "MeinAatariecomputer" (Programmierbeispiele) und diverse SW Assembler Monitor etc etc bei interesse kanst du alle benötigten Kopien und jede Menge Uunterstützung von mir bekommen Ich hatte bis zu 1MB Ram darin 6 Parrallelports und Schnittstellenwandler.... Floppysimulator in PDS-Basic auf 486er ist leider einem PC Absturz zum Opfer gefallen. Er ist für mich der ideale Bastelcomputer Namaste
Der 6502 wurde aber meist wohl in industriellen Schaltungen eingesetzt. Ich beobachtete sowas immer, wenn ich z.B. in einem Rechenzentrum mal eine Baugruppe zog. Modem, oder sonst ein Übertragungsgerät. Ich war ja immer nur mit Fernmeldetechnik beschäftigt. Der 6502 war wohl ähnlich häufig vertreten wie 8080 und Z80, oder 8048 und 8051. Ich hab hier noch eine alte Baugruppe mit 6802 liegen, die hatten wohl wieder Detailunterschiede, da passierte mal sowas wie mit der Ausgliederung von Zilog aus den Intel-Geschichten bei 8080/Z80. Mal sehen, vielleicht baue ich eines Tages noch einen auf Lochraster auf. Vom Speicherumfang gleichen sie ja den 8080 bzw. Z80, und 8051. Fertige Eval-Boards wird es leider kaum noch geben. Mit dem 8085 und 8048 machte ich das auch schon mal. Das ist ja keine Kunst, nur handwerkliche Fleißarbeit.
Angehängte Dateien:
-
cepac.jpg
33 KB
Habe hier noch einen Original CEPAC-65 aus der C`T. Das war ein sog. Einplatinencomuter. Der verwendete 6535 hatte 128 Byte SRAM, 2Ports und ein Timer. Ich habe damals die Programme auf dem C64 Assembliert, ins Eprom gebrannt und dann umgesteckt. War umständlich, aber hat Spass gemacht.
Ich hatte mal eine Idee fuer ein minimalistisches 6502 System. Ein 6510, ein Flash, ein SRAM und ein MAX232. Ins Flash kommt ein Bootloader/Monitor, der Programme ueber einen Bit-Bang UART ins SRAM oder ins Flash laedt. Das ganze sollte auf ein Steckbrett passen.
Mal eine Frage... Wozu macht man das heute noch? Ein einzelner AVR dürfte ein Vielfaches der Rechenleistung haben...
Ein möglicher Grund sich jetzt noch damit zu beschäftigen ist es wenn man eine alte Steuerung oder ähnliches hat, die den 6502 nutzt. Da macht es ggf. schon Sinn das alte Programm zu verstehen (ggf. reverse Engeniering) oder es ggf. zu ändern. Neu macht der 6502 eher wenig Sinn. Da sind neuere µC Leistungsfähiger und einfacher von der Hardware.
Ben _ schrieb: > Mal eine Frage... Wozu macht man das heute noch? > Ein einzelner AVR dürfte ein Vielfaches der Rechenleistung haben... Reine Nostalgie, wie auch Leute Freude an Röhrenradios und Nixie-Röhren und Oldtimer-Autos haben. Das hat nicht immer direkt logische und rationale Gründe. Ich habe hier auch noch einen 8085 auf Lochraster liegen, und baute den einfach auf, obwohl mir klar ist, daß es was besseres gibt. Er ist aber schon ein wenig frisiert, hat mit 32k RAM und ROM einen ziemlich guten Ausbau, wie er damals eher unrealistisch war. Manchmal macht es einfach Spaß.
> Mal eine Frage... Wozu macht man das heute noch? Auf dem AVR kann man keinen selbstmodifizierenden Code schreiben (Harvard-Architektur) Und wie jeder weiss sind Systeme, auf denen man keinen selbstmodifizierenden Code schreiben kann, nutzlos ;)
Okay, selbstmodifizierender Code geht nur wenn das Programm in SRAM liegt. Ließe sich bestimmt auch mit einigen µCs die externes RAM fürs Programm nutzen können bewerkstelligen. Ich hab immer noch einen 68000 herumliegen, aber für den bekommt man bestimmt kein lauffähiges System auf Lochraster hin. Zumindest nicht ganz so einfach. Ein 486er müßte auch auf Lochraster passen...
Ben _ schrieb: > Ich hab immer noch einen 68000 herumliegen, aber für den bekommt man > bestimmt kein lauffähiges System auf Lochraster hin. Doch, das geht. Kein Streifenraster, echtes Lochraster, zuerst Stromversorgungsleitungen mit dickerem Draht direkt auf dem Raster mit SMD-Kondensatoren dicht an den Stromversorgungspins der ICs, und den Rest fädeln. Mit der Technik kann man auch Bauteile im Pin-Grid-Array verarbeiten. Ein 486 dürfte aufgrund der recht heftigen fließenden Ströme schwierig werden.
Na gut, unmöglich ist nichts... Aber der braucht doch schon einiges an externer Beschaltung und sich nur für diesen einen Spaß dermaßen tief in die Architektur einarbeiten ist auch ein fragliches Vergnügen. Ähnlich beim 486er. So viel Strom will der nun wieder auch nicht. Was wird der haben, vielleicht 20W? Ich glaub die Dinger sind noch mit vollen 5V gelaufen, das wären gerade mal 4A.
Den 486er kriegst du schon dank PGA-Gehäuse rein mechanisch nicht auf Lochraster, den 68000 jedoch schon. Den kriegst du sogar auf Lötstreifenraster oder Steckbrett, weil zumindest damals in riesigem DIP64 Gehäuse. Das spätere PLCC68 ist immerhin noch lötpunktrastertauglich.
A. K. schrieb: > Den 486er kriegst du schon dank PGA-Gehäuse rein mechanisch nicht auf > Lochraster O doch, das geht, denn das PGA des 486 hat genauso wie das des 386 und sogar das der ersten Pentium-Modelle mit 60/66 MHz ein Pinraster von 0.1". Erst die Pentiums der zweiten Generation (ab 75 MHz) haben das "staggered PGA", bei der zwischen zwei Reihen im 0.1"-Abstand eine weitere um 0.05" versetzte angeordnet ist, und das ist nicht in 'ne Lochrasterkarte zu bekommen.
Hallo zusammen, beim Lesen dieses Threads juckt es in meinen Fingern und ich aergere mich das ich mein 6502 Zeug (Buecher, CDs, Zeitschriften (Peeker aus den 80ern) eine seit Jahrzehnten nicht mehr laufenden AppleII+ Clon) vor nicht allzulanger Zeit entsorgt habe. duck und weg MfG, Balze aka AVR Noob
bastelhans schrieb: > Kennt jemand einen Basic oder Asemmbler Compiler für Windos/Dos oder > Unterlagen? Schau mal hier: http://www.westerndesigncenter.com/wdc/index.cfm http://www.avocetsystems.com/company/techshee/asheets/6502.htm oder hier http://www.npsnet.com/danf/cbm/cross-development.html oder hier: http://www.megawin.com.tw/megawin_EN/D_DownloadShow.asp?ID=25
> DIP64 Gehäuse
Das ist aus heutiger Sicht das einzig Coole am 68000 und der einzige
Grund wieso meiner hier noch lebt...
Ben _ schrieb: > Ich hab immer noch einen 68000 herumliegen, aber für den bekommt man > bestimmt kein lauffähiges System auf Lochraster hin. Das war mein erstes Gebastel mit einem Mikroprozessor :) MC68000 mit 8MHz, 32kiB SRAM, 32kiB EPROM und serielle Schnittstelle für Softwareupload und Kommunikation. Das Ganze war relativ einfach gestrickt (ca. 12 ICs), trotzdem war es viel Arbeit, die vielen Busleitungen per Schaltdraht zu verlegen, und entsprechend wüst sah das Ergebnis aus. Eine weitere Hürde lag darin, dass ich weder ein EPROM-Programmier- noch ein Löschgerät zur Verfügung hatte. Aber das Board hat funktioniert und war damals mein mit Abstand schnellster Rechner.
Auf Lochraster wuerde ich den 68008 verwenden, denn der hat einen 8-bit Bus. Spart deutlich Bauteile und reduziert den Verdrahtungsaufwand. Wenn man keine langsame Peripherie hat, dann kann man DTACK auf GND legen, das reduziert die Komplexitaet des Buses nochmal deutlich.
Mitte der 90er Jahre war der 6502 in Herzschrittmachern eines deutschen Herstellers verbaut, mit nem 32kHz (Hertz!) Takt. Der 6502 war zwar damals schon alt, aber die Entwickler kannten jedes Bit mit Vornamen und haben deshalb dieses Teil genommen. Heute nehmen die nen Quadcore unter Windows ;-) just kidding Cheers Detlef
Detlef _a schrieb: > Mitte der 90er Jahre war der 6502 in Herzschrittmachern eines deutschen > Herstellers verbaut, mit nem 32kHz (Hertz!) Takt. 32kHz ... da gingen die Opas sicher ab wie Schmidts Katze :) > Heute nehmen die nen Quadcore unter Windows ;-) Ach, deswegen sehen die Leute manchmal etwas weggetreten aus: Das sind die Phasen, wenn der Herzschrittmacher gerade rebootet oder ein neuer Servicepack eingespielt wird ;-)
Die Politik dazu: 1. Windows saves lives! 2. Windows does something good for the Rentenkasse! >> 68000 auf Lochraster > Das war mein erstes Gebastel mit einem Mikroprozessor :) Hast Du das Board noch? Ich hatte mal was vergleichbares mit einem 8088, 32kB EPROM, 64kB SRAM, eine COM und zwei Ports für LEDs...
Ben _ schrieb: > Hast Du das Board noch? Explizit weggeschmissen hab ich es nicht, ich müsste es mal suchen. Interessant wäre ja, ob es heute noch läuft, oder ob inzwischen vielleicht sämtliche kalten Lötstellen von damals auseinandergefallen sind :)
Hallo, ich habe damals auf dem Apple II+ mit dem "Apple II Assembler-Kurs" von Sybex Assembler gelernt. Da war ein nettes Programm dabei mit dem man den einzelnen Befehlen bei der Ausführung zu schauen konnte, also z.B. die Auswirkung auf Speicher, Register, Flags, PC,... Das ganze war deutlich anschaulicher als ein klassische "Debugger". Kennt dieses Programm jemand und gibts es sowas z.B. für x86 ?? Gruss, Bernd
Bernd schrieb: > Kennt dieses Programm jemand und gibts es sowas z.B. für x86 ?? Wenn du gleichzeitig bitweise den vollständigen Registerstatus einer aktuellen 64-bit x86-CPU ansehen willst, dann brauchst du eine ganze Wand mit Monitoren.
Um die Register in Hex, einen kleinen Auszug aus dem Speicher (RAM) in Hex und ASCII und die Flags darzustellen braucht es sicher keinen Monitorwand. Gruss, Bernd
Der 6502 im Herzschrittmacher wird sicherlich ein 65C02 gewesen sein. Weil sonst der Träger Gefahr läuft, im heißen Sommer das Leben zu lassen. Der 6502 war ein NMOS Chip und die waren aus dynamischer Logik... Oder war der 6502 echtes statisches Design? Das mit den zwei Phasen hat man typischerweise bei Video oder DMA Controller gemacht. In der zweiten Phase war der Prozessor leise und der Bus konnte vom Kompagnion benutzt werden. 6502, 6802 und 6809 hatten das. Beim IIfx war es nicht so. Die beiden 6502 waren für die beiden I/O-Kanäle völlig getrennt.
Bernd schrieb: > Kennt dieses Programm jemand Avr Noob schrieb: > ... 6502 Zeug (Buecher, CDs, Zeitschriften (Peeker aus den > 80ern) eine seit Jahrzehnten nicht mehr laufenden AppleII+ Clon) vor > nicht allzulanger Zeit entsorgt habe Da war auch der Sybex Assembler Kurs bei. (blau/orange Plastikverpackung, hab's noch genau vor Augen :) MfG, balze aka AVR Noob
Bernd schrieb: > Um die Register in Hex, einen kleinen Auszug aus dem Speicher (RAM) in > Hex und ASCII und die Flags darzustellen braucht es sicher keinen > Monitorwand. Die allgemein zugänglichen Register: 1 Program Counter 16 allgemeine x86-Register 64 Bits in 3 Darstellungen (Dez, Hex, Char) 1 x86-Flag-Register, aufgeschlüsselte Bits 6 Segment-Register, aufgeschlüsselte Segment-Info 8 x87-Register in 3 Darstellungen (x87, MMX, 3DNow) 1 x87-Control-Register, aufgeschlüsselte Bits 16 AVX/SSE Register 256 Bits in 3 Darstellungen (single, double, integer) Der erste Schirm ist damit effektiv voll. Für die Befehle und mindestens zwei Speicherbereiche (Stack + Data) brauchts dann noch einen.
Banane schrieb: > Auch der Apple II hatte eine 6502 drin. Im Apple II+ kam dann noch eine > > Z80 hinzu. Damit konnte man dann CP/M fahren, um z.B. WordStar, dBase, > > Turbo Pascal 1.0 etc. zu benutzen. Gemeint ist wahrscheinlich ein Commodore C128. Der hat noch Z80 extra für CP/M-Modus. MfG
Dimi S. schrieb: > Gemeint ist wahrscheinlich ein Commodore C128. Nein, der ist nicht gemeint, auch wenn das von Dir gesagte auf ihn zutrifft. Für die verschiedenen Apple-II-Modelle gab es von Drittanbietern (also nicht Apple selbst) sogenannte "CP/M"-Karten, die diese Funktion dem Apple zur Verfügung stellten. In manchen Nachbauten des Apple II war diese Karte gleich fest integriert.
Sogar für den C64 gab es von Commodore ein Z80-Modul. Mit CP/M.
Hallo zusammen, @Bernd: Ich habe heute zufaellig etwas in meinem Keller gefunden. Den Sybex Assemblerkurs für den Apple II/IIe incl. 5 1/4 Zoll Diskette. Allerdings habe ich keine Möglichkeit mehr diese zu lesen (oder es zu versuchen, ist immerhin von 1984) MfG, Balze Avr Noob schrieb: > Bernd schrieb: >> Kennt dieses Programm jemand > > Avr Noob schrieb: >> ... 6502 Zeug (Buecher, CDs, Zeitschriften (Peeker aus den >> 80ern) eine seit Jahrzehnten nicht mehr laufenden AppleII+ Clon) vor >> nicht allzulanger Zeit entsorgt habe > > Da war auch der Sybex Assembler Kurs bei. (blau/orange > Plastikverpackung, hab's noch genau vor Augen :) > > MfG, > > balze aka AVR Noob
Hier ist ein interessanter Vortrag zum C64: http://www.youtube.com/watch?v=ZsRRCnque2E Die 6502 Assemblerpgrammierung wird hier gut erklaert.
Ihr redet immer in der Vergangenheit. Im Sitronix st2205/st2203 steckt ein 6502-Kern mit intern 32k Ram und sehr viel I/O (LCD-Interface, USB, Uarts, SPI...). Extern bis 44MB Speicherbereich. Steckt wohl in Millionen von Bilderrahmen drin. Von Mitsubishi gab auch mal eine CPU mit 6502 Befehlssatz mit 40MHZ (?) Wär doch mal heiss, einen Apple am Schlüsselanhänger zu simulieren...
Karl-Werner Riedel schrieb: > Ihr redet immer in der Vergangenheit. Im Sitronix st2205/st2203 steckt > ein 6502-Kern mit intern 32k Ram und sehr viel I/O (LCD-Interface, USB, > Uarts, SPI...). Extern bis 44MB Speicherbereich. > Steckt wohl in Millionen von Bilderrahmen drin. > > Wär doch mal heiss, einen Apple am Schlüsselanhänger zu simulieren... noch besser, Sitronix ST31xx oder ST36xx (von beiden habe die Dev kits hier) - 24MHz core, USB 2.0, LCM Interface (320x240x16bit), NAND Flash controller, 32k RAM, Audio codec usw. > Von Mitsubishi gab auch mal eine CPU mit 6502 Befehlssatz mit 40MHZ (?) ja Renesas 740 fam., allerdings schwer zu finden.
Was würdet ihr als effizienteste CPU sehen? AVR ist wohl ziemlich nahe dran mit nur ca. 4000 Gattern.
Abdul K. schrieb: > Was würdet ihr als effizienteste CPU sehen? Wie definierst du denn die Effizienz einer CPU?
> Was würdet ihr als effizienteste CPU sehen? AVR ist wohl ziemlich nahe > dran mit nur ca. 4000 Gattern Entsprechen 4000 Gatter in etwa 1000 SN7400? Oder mit anderen Worten: ist es möglich eine AVR CPU aus 1000 SN7400 zu bauen?
Abdul K. schrieb: > AVR ist wohl ziemlich nahe > dran mit nur ca. 4000 Gattern. 4000 Gatter, oder meinst du 4000 Transistoren? Die 6502, 8085, Z80, waren ja relativ ähnliche Bausteine, hatten wohl sowas um die 6000 Transistoren. Ich hab diese Zahl jetzt einfach mal so im Kopf, müßte aber konkret nachschauen. Markus schrieb: > Entsprechen 4000 Gatter in etwa 1000 SN7400? Oder mit anderen Worten: > ist es möglich eine AVR CPU aus 1000 SN7400 zu bauen? Ob es jetzt 1000 sind, oder ein paar mehr oder weniger, das Prinzip ist immer gleich. Aus Einzeltransistoren und Widerständen baut man Logik-Gatter, sicherlich nicht nur NAND-Gatter wie im 7400, daraus wiederum komplexere Digitalbausteine wie Zähler und Flipflops, usw.. Mit NAND oder NOR alleine, kann man auch jede beliebige Logik erstellen. Man braucht allerdings dann mehr Gatter, als wenn man den Funktionen entsprechend gleich die richtige Gatterart wählt.
Den Schaltplan des 6502 findest Du im Netz. Wenn Pollin dann mal wieder BS170 im Angebot hat, kann's losgehen...
om pf schrieb: > Den Schaltplan des 6502 findest Du im Netz. Es ist mal ganz interessant, zu sehen, wie die Technik auf Transistorebene spielt. Das reicht für meinen Bedarf. Den 8085 auf Lochraster aufzubauen, und in Assembler zu programmieren, reichte ebenfalls. Eine Europakarte voll Bausteine, nur um 2 parallele 8-bit-Ports einzulesen oder auszugeben, und einen Timerbaustein. > Wenn Pollin dann mal wieder > BS170 Ein Schelm, wer jetzt böses denkt. Aber ich hab ja gar keinen Tipp gegeben, wenn man genau liest. ;-) MaWin war trotzdem auf 180.
Effizienz ist einfach der kleinste Aufwand für maximalen Nutzen! Der AVR soll aus 4000 Gattern im Originaldesign bestehen. Wurde wohl an einer nordischen Uni ursprünglich als Konzeptstudie entworfen. Anscheinend hat Atmel das Konzept dann in ein Produkt umgesetzt. 4000 Gatter wären ca. 3x bis 4x mehr Transistoren. Eine SRAM-Zelle besteht aus 4 oder 6 Transis. Dynamische Design brauchen noch weniger. Schon erstaunlich, 6000 Transis für einen kompletten 6502 ?? Wenn man das mit heutzutage vergleicht.
Der 6502 hat 4000 Transistoren Quelle: Microprocessor Report 8008: 3.5K transistors 14 mm^2 6800: 4.1K transistors 16 mm^2 8080: 4.8K transistors 20 mm^2 1802: 5K transistors 27 mm^2 6502: 4K transistors 21 mm^2 Z80: 8.5K transistors 18 mm^2 8085: 6.5K transistors 20 mm^2 8086: 29K transistors 33 mm^2 8088: 29K transistors 33 mm^2 Z8001 17.5K transistors 39 mm^2 68000 68K transistors 44 mm^2 6809: 9K transistors 21 mm^2
Abdul K. schrieb: > Schon erstaunlich, 6000 Transis für einen kompletten 6502 ?? Offenbar sind es grad mal 3510 Transistoren. Immerhin hat er gegenüber der direkten Konkurrenz extrem wenig Registerbits.
In meinem DMM, ein PREMA 5000 (80er/90er Jahre) werkelt tatsächlich ein 65C02, welches damit über die Rechenleistung eines damaligen Heimcomputers verfügt.
Abdul K. schrieb: > Schon erstaunlich, 6000 Transis für einen kompletten 6502 ?? Wenn man > das mit heutzutage vergleicht. Nun ja, in den spartanischen Prozessoren war ja auch wirklich nicht viel drinne, nur ein paar Register und Zähler. Schau dir den 8085 an, der hat mal eben insgesamt 6 frei verwendbare Register, einen Akku, ein Flagregister, einen Program Counter, ein wenig Interruptlogik, das Steuerwerk, kein Pipelining, das wars schon. Zur Not konnte man ihn ohne Stack und damit ohne Unterprogramme sogar noch als Single-Chip betreiben, wenn die 6 Register reichten. Dann genügte nur das externe EPROM alleine. Mit RAM wurde er dann richtig leistungsfähig, weil da auch ein verhältnismäßig großer Hardwarestack drin liegen konnte. Integrierte Peripherie wie z.B. Timer oder UART gab es auch nicht. Die mußte man noch extern aufbauen, wie auf meiner vollen Lochrasterkarte. Die modernen ARM-Cores sind aber auch bekannt dafür, daß sie klein und schmal sind, und damit wenig Energie verbrauchen. Über die genauen Gatterzahlen dort, bin ich allerdings nicht im Bilde. Im Grunde kann man sich mit heutigen Mitteln auch leicht eine eigene CPU entwerfen, so wie man sie gerade braucht. In meinem Studium war das unter einem neuen Prof. in Mikroprozessortechnik mal vorgesehen, aber wir kamen nicht mehr dazu. Im ersten Jahr des Profs funktionierte der Vorlesungsplan noch nicht wie erhofft.
Das war ja der Trick beim 6502: Man hatte relativ viele Adressierungsarten dafür. Offensichtlich kann man Register gegen Adressierungsmodi tauschen für gleiche Performance. Ich erinnere mich aber nur sehr dunkel an 6502. Damals am PET direkt in Hex reingecodet und glücklich wenn die Kiste nach Aufruf aus dem BASIC heraus, auch wieder zurückkam ;-) Alles in der großen Pause in der Schulzeit im Kaufhof ;-))
> Offenbar sind es grad mal 3510 Transistoren. Na, dann zähl' noch einmal nach. http://www.shiresoft.com/downloads/docs/6502.pdf
@Hermocrates: Ganz nett, die Zahlen. Du hast den 4004 vergessen... ;-) Das war wohl einer der ersten überhaupt, oder sogar tatsächlich der erste. Im Offtopic war heute noch ein Thread zur Waage. Worauf hin ich meine 23 Jahre alte digitale Küchenwaage mal inspizierte. Da ist auch noch so ein olles Ding drauf, µPD7520C von NEC, PMOS-Technologie mit -8V Betriebsspannung, 4-bit-µC, kommt etwa so in Richtung 8048. Leider fand ich kein Datenblatt mehr. Abdul K. schrieb: > Ich erinnere mich aber nur sehr dunkel an 6502. Das Ding kennen hier sicher hauptsächlich Leute aus Heimcomputern. Mir begegnete er auch sehr oft in professionellen Einschüben in größeren Rechenzentren, er war wohl in Industrieelektronik sehr beliebt. > Offensichtlich kann man Register gegen > Adressierungsmodi tauschen für gleiche Performance. Er hatte auf jeden Fall eine interessante Architektur, wiederum um einiges anders als z.B. der 8085.
Luk4s K. schrieb: > In meinem DMM, ein PREMA 5000 (80er/90er Jahre) werkelt tatsächlich ein > 65C02, welches damit über die Rechenleistung eines damaligen > Heimcomputers verfügt. Sicherlich werkelt er noch in einer ganzen Menge moderner Anwendungen, wie auch der olle 8048, der sich immer noch z.B. in PC-Tastaturen befindet.
Ich finde den Schaltplan schon erstaunlich. Wie wenig da drin ist und wie teuer das Teil dann im VK war. Kein Wunder wenn die Chips damals so warm wurden. Überall NMOS. Komischerweise die Ausgänge dann wieder CMOS.
Abdul K. schrieb: > Komischerweise die Ausgänge dann wieder CMOS. Nixda. Unten wie oben N-FET, invertiert angesteuert.
Abdul K. schrieb: > Ich finde den Schaltplan schon erstaunlich. Wie wenig da drin ist und > wie teuer das Teil dann im VK war. Und wie günstig im Vergleich zur Konkurrenz.
Realistisch? 3510 Transistoren BS170, pro Transistor max. 2 Widerstände, einen Haufen Kondensatoren, eine Rolle Lötzinn und eine Lochrasterplatine 200 mm x 200 mm plus 6 Wochen Urlaub
Markus schrieb: > 3510 Transistoren BS170, pro Transistor max. 2 Widerstände, einen Haufen > Kondensatoren, eine Rolle Lötzinn und eine Lochrasterplatine 200 mm x > 200 mm plus 6 Wochen Urlaub Weniger wenn Widerstände statt der für NMOS typischen Stromquellen (depletion mode N-FET) als Pullups verwendet werden. Aber für die aktiven Highside-FETs der Pintreiber ist die Schwellspannung des BS170 bei 5V Versorgung etwas knapp.
> Weniger wenn Widerstände statt der für NMOS typischen Stromquellen > (depletion mode N-FET) als Pullups verwendet werden. Aber für die > aktiven Highside-FETs der Pintreiber ist die Schwellspannung des BS170 > bei 5V Versorgung etwas knapp. Kein Problem, habe noch ein "paar" BSS129.
Markus schrieb: > 3510 Transistoren BS170, Nix mit nur BS170. Die meisten FET sind wohl Depletion-Mode-FET, wenn auch eben NMOS. So realisiert man schaltbare oder feste Widerstände auf integrierten Chips. Aber ich kann die Bauteilsymbole auf dem Plan tatsächlich noch nicht ganz richtig deuten, es sind alte Symbole.
Wilhelm Ferkes schrieb: > Nix mit nur BS170. Die meisten FET sind wohl Depletion-Mode-FET, Nein. Dünner Kanal ist enhancement mode, dicker Kanal depletion mode. NMOS Standardschaltung ist enhancement mode Schalter unten und depletion mode Stromquelle als Pullup. Circa vergleichbar mit bipolarer RTL per NPN mit Pullup-Widerstand.
Angehängte Dateien:
-
6502_CMOS_NMOS.gif
4,8 KB
Ja, dann ist es doch NMOS. Oben schriebst du: Beitrag "Re: 6502 Prozessor wer kennt den noch?" Hä? Aber es gibt viele Stellen im Schaltplan, die ich nicht richtig verstehe. Bin aber auch kein Chip-Designer.
Passt doch. Rechts im Bild sind zwei NMOS-Inverter, enh-FET unten und dep-FET oben. Der Pintreiber links ist anders aufgebaut, mit über inverter angesteuertem enh-FET oben für schnelleren aktiven Pullup.
Abdul K. schrieb: > Kein Wunder wenn die Chips damals so warm wurden. Die wärmemäßige Entwicklung verlief genau anders herum: Der 6502 wurde, mit der Standardtaktfrequenz von 1MHz betrieben, so gut wie überhaupt nicht warm. Dafür hat er noch zu wenig Transistoren. Der MC68000 (HMOS) wurde immerhin schon lauwarm. Mit dem 80486 kamen dann die Kühlköper und teilweise auch kleine Lüfter. Heute besteht ein PC volumenmäßig fast nur noch aus Kühlköper und Lüfter. Betrachtet man allerdings die Watt/MIPS, schneiden die neuen Prozessoren dank CMOS und kleineren Strukturen schon besser ab.
Yalu X. schrieb: > Der > MC68000 (HMOS) wurde immerhin schon lauwarm. Die NMOS-Typen wurden unabhängig der Taktfrequenz warm. Mein NMOS-8085 auf der Lochrasterplatine wurde bei 2,4576MHz schon handwarm. Die NMOS-RAM und EPROM ebenfalls. Sicher völlig unabhängig der Taktfrequenz. Da ich aber noch Bauteilreserven habe, wechselte ich den mal gegen einen CMOS-Typen. Der bleibt schön kalt.
Ja Yalu. Die neueren Prozessoren sind alle begrenzt durch die abführbare Leistung. Da ist so langsam die Luft raus. Bin gespannt wie es weitergeht. Mehr als 8 Prozessoren parallel machen auch nicht viel Sinn, nach einem Paper aus ca. 1990. Ich meinte den Vergleich zwischen NMOS und CMOS Varianten, z.B. Z80 oder 6502. Aus obiger Liste würde ich übrigens 6809 bevorzugen. @A.K.: OK, nun macht das mit NMOS und CMOS Sinn. Warum wurden die NMOS Pull-Ups eigentlich gemacht? Nur damit man keinen P-FET einbauen muß/konnte? Das ist übrigens ein Thema auch heutzutage noch: Es gibt Chiphersteller die ziemlich symmetrische NPN und PNP auf einen Chip kriegen, andere dagegen haben da wohl Probleme. LTC ist z.B. eine Firma, die damit wenig Probleme hat. Ein ähnliches Thema ist BCD.
NMOS 6802 mit 3.58MHz quarz hat etwas über 50°C gehäusetemperatur.
Abdul K. schrieb: > weitergeht. Mehr als 8 Prozessoren parallel machen auch nicht viel Sinn, > nach einem Paper aus ca. 1990. Bei Servern dürfen es heute dank Virtualisierung auch mehr sein. Bei Clients hängt es von der Anwendung ab. Bei gut optimiertem Video-Encoding geht im Prinzip soviel du willst, bei Office sind schon 2 genug. Aber das wird die Verkäufer nicht daran hindern, den Leuten auch 16-Kerner anzudrehen. Die dann oft genug arbeiten wie ein Ruder 8er verkehrt herum: Einer arbeitet im Turbo-Overdrive und 15 schnarchen. Das zitierte Limit könnte sich auch auf Amdahl's Law beziehen. Aber das gilt nur für bestimmte Problemklassen. > OK, nun macht das mit NMOS und CMOS Sinn. Warum wurden die NMOS Pull-Ups > eigentlich gemacht? Nur damit man keinen P-FET einbauen muß/konnte? NMOS heisst so weil ausschliesslich N-FETs verwendet werden. P-FETs liessen sich zunächst nicht mit vergleichbarer Performance integrieren.
Abdul K. schrieb: > OK, nun macht das mit NMOS und CMOS Sinn. Warum wurden die NMOS Pull-Ups > eigentlich gemacht? Nur damit man keinen P-FET einbauen muß/konnte? Der NMOS-Prozeß in der Halbleiterherstellung war wesentlich einfacher und billiger als der CMOS-Prozeß.
Thomas R. schrieb: > NMOS 6802 mit 3.58MHz quarz hat etwas über 50°C gehäusetemperatur. Nicht nur, daß die mehr Energieaufnahmen haben: Auch der Beschleunigungsprozeß der Alterung ist höher.
Ja. Aber nun kenne ich das RCA(?) Patent für CMOS. Das ist vieeel älter als unsere 8-Bitter hier. Die 4000er ist CMOS und auch uralt. Hm. Mir schwand gerade was ganz Böses, was MaWin auf den Plan ruft: Patent?! Also wurden Atomkraftwerke aufgewendet, damit man das Patent nicht brauch.
Abdul K. schrieb: > Ja. Aber nun kenne ich das RCA(?) Patent für CMOS. Das ist vieeel älter > als unsere 8-Bitter hier. Die 4000er ist CMOS und auch uralt. Yep, CMOS gab es, die metal gate CD4000. Aber noch kein schnelles CMOS wie die silicon gate 74HC. Zudem: 8080: 4.8K transistors 20 mm^2 -- Intel NMOS 1802: 5K transistors 27 mm^2 -- RCA CMOS Fällt dir darin was auf? Soweit mir bekannt sind beide in 6µ Technik.
Abdul K. schrieb: > Die 4000er ist CMOS und auch uralt. Die CMOS-Strukturen in den 4000-ern waren so riesig groß, daß sie in einem Prozessor keinen Platz gefunden hätten. In einem einfachen Gatter hingegen schon. Darum führte man den NMOS-Prozeß eine Weile weiter, auch wenn es seit etwa 1970 die CMOS-Gatter gab. Die späteren CMOS-Prozessoren waren auch nicht in Metal-Gate-Technik, sondern in Silicon-Gate-Technik.
Korrektur: Der 1802 hatte offenbar schon silicon gate CMOS. Allerdings noch in eher gemächlich arbeitender Technik.
A. K. schrieb: > Abdul K. schrieb: > >> Ja. Aber nun kenne ich das RCA(?) Patent für CMOS. Das ist vieeel älter >> als unsere 8-Bitter hier. Die 4000er ist CMOS und auch uralt. > > Yep, CMOS gab es, die metal gate CD4000. Aber noch kein schnelles CMOS > wie die silicon gate 74HC. > Warum ist ein Metall Gate so viel langsamer? Sieht so aus, als wäre einfach nur die Oxidschicht dünner. > Zudem: > 8080: 4.8K transistors 20 mm^2 -- Intel NMOS > 1802: 5K transistors 27 mm^2 -- RCA CMOS > Fällt dir darin was auf? Soweit mir bekannt sind beide in 6µ Technik. Grad kommt der BWLer bei mir mal wieder durch ;-) : RCA ist tot, Intel reich. Meinst du das??
Abdul K. schrieb: > Warum ist ein Metall Gate so viel langsamer? Wenn ich mich richtig erinnere, dann konnte die Fertigungstechnik bei prinzipiell gleicher Prozesstechnik Siliziumstrukturen kleiner bauen als Metallstrukturen. > Grad kommt der BWLer bei mir mal wieder durch ;-) : > RCA ist tot, Intel reich. Meinst du das?? Nö. 5% mehr Transistoren als Intel, aber 30% mehr Platz. Trotz Si-Gate-CMOS und obwohl der 1802 fast nur aus gut optimierbaren RAM-Strukturen besteht (16x 16-Bit Register).
Muss auch schnell noch meinen Senf dazugeben: Bernd schrieb: > Hallo, > > ich habe damals auf dem Apple II+ mit dem "Apple II Assembler-Kurs" von > Sybex Assembler gelernt. Da war ein nettes Programm dabei mit dem man > den einzelnen Befehlen bei der Ausführung zu schauen konnte, also z.B. > die Auswirkung auf Speicher, Register, Flags, PC,... > Das ganze war deutlich anschaulicher als ein klassische "Debugger". > > Kennt dieses Programm jemand und gibts es sowas z.B. für x86 ?? > > Gruss, > Bernd Ja, der Assembler heißt Merlin oder auch BigMac (nein kein goldenes M) Das Buch habe ich sogar noch hier, zusammen mit Rodney Zacks "Programming the 6502" und Peter Heuer 6502 Microcomputer. --------------------- Es gab von Mitsubishi den M7702 der ist mit 6502 Kern, und heute gibt es den von Renasas unter e7700 mit Flash und Ram.... --------------------- Der Beste weg ist einen Apple // Emulator mit Merlin zu benutzen... ------------------------- Apple 2+ Nachbauten gab es einige (Space 81) war der wohl am häufigste verwendete Nachbau des Motherboard's und hatte nur eine 6502 CPU. Der ITT 2020 hatte eine 6502 und einen Z80, aber kein Applesoft im ROM, diese mußte man über eine EPROM Karte in Slot #0 Nachrüsten. Heute werkelt immer noch ein Apple //c mit Z80 Karte intern und 128 MB intern (AUGE) bei mir........ wird alle 2 Jahre mal Eingeschaltet. Roland
>Offensichtlich kann man Register gegen Adressierungsmodi tauschen >für gleiche Performance. Ja, wenn das angehängte RAM gleich schnell ist wie die CPU; wenn langsamer braucht man Register. Es gibt auch heute noch leistungsfähige Controller, mit extrem wenig Registern, weil RAM gleiche Geschwindigk hat wie CPU. Dass der 68k wirklich 68k Transitoren gehabt haben soll?
MCUA schrieb: > Dass der 68k wirklich 68k Transitoren gehabt haben soll? http://www.uni-giessen.de/faq/archiv/motorola.68k-chips-faq/msg00000.html
So zumindest das verbreitete Gerücht. Stehts in obigen Link begründet? Habe zwar viel auf 68K gemacht, aber dieser Prozessor ist nicht wirklich elegant. Damit wären wir mal wieder beim AVR. @A.K.: Die Ausbeute war mit NMOS entscheidend höher. Den Strom hat der Anwender bezahlt. Gängiges erfolgreiches Geschäftsmodell. Klingt ja fast wie heutiges China. Das meinte ich!
Abdul K. schrieb: > Habe zwar viel auf 68K gemacht, aber dieser Prozessor ist nicht wirklich > elegant. Kommt drauf an mit wem man ihn vergleicht. Zeitgenossen ähnlicher Klasse waren eigentlich nur 8086 und Z8000. Mit denen verglichen ist er doch ziemlich elegant. C-Compiler kommen damit auch weitaus besser zurecht. > Die Ausbeute war mit NMOS entscheidend höher. Den Strom hat der Anwender > bezahlt. Gängiges erfolgreiches Geschäftsmodell. Jo, so kann man es sagen. Allerdings war der 8080 auch viel schneller als der 1802. Zwar nicht der Taktfrequenz nach, aber wer mal ein 1802 Programm geschrieben hat, der kennt dessen extreme Umständlichkeit.
z.B. 6809. Wobei der Vergleich wegen dem möglichen Adressraum hinkt. Der wurde allerdings oftmals gar nicht <satt> genutzt. War nicht das Gerücht, der Z8000 kam aus der DDR?
> Den Strom hat der Anwender bezahlt.
Das eine Watt für einen 6502 hatte aber auch niemanden wirklich groß
interessiert. Ein kleines Steckernetzteil hat schon das Dreifache an
Heizverlusten.
Meine Küchenwaage mit dem alten PMOS-µC und 8V Betriebsspannung läuft
mit einem Satz von 6 Mignonzellen gut 3-4 Jahre. Danach werden die
Batterien aber auch schlecht, selbst wenn der µC die Energie nicht ganz
aufgezehrt hat. Das Gerät läuft bei mir täglich gut 3 Minuten.
Abdul K. schrieb: > z.B. 6809. Völlig andere Grössenklasse. Typische Speicherkapazität von 68000ern war 128KB bis einige MB. Für 6809 gab es zwar eine MMU, aber lineare 32-Bit Adressierung war unschlagbar angenehm. > War nicht das Gerücht, der Z8000 kam aus der DDR? Wurde dort nachgebaut (= geklaut).
A. K. schrieb: >> z.B. 6809. > > Völlig andere Grössenklasse. Der schönste aller 8-Bit-Prozessoren (wenn man mal von der leider viel zu spät vollständig dokumentierten Hitachi-Interpretation davon namens 6309 absieht). Ich habe einen handgeschnitzten Rechner mit dem.
Rufus Τ. Firefly schrieb: > Der schönste aller 8-Bit-Prozessoren Yep. Hatte mal etwas mit rumgespielt, bischen an sowas wie eine Art Doppelprozessorsystem aus dem AIM65 mit seinem 6502 und einem zusätzlichen 6809 gedacht. Wurde aber nichts draus, 68000 hatte doch weit mehr Reiz. Zumal da C Programmierung realistisch war. Ein kompletter(!) C Compiler auf 6809? Nö, lieber nicht. Aber wenn du da Wert drauf legst: Die 68'11/12 Mikrocontroller-Linie ist ziemlich dicht dran.
Wilhelm Ferkes schrieb: >> Den Strom hat der Anwender bezahlt. > > Das eine Watt für einen 6502 hatte aber auch niemanden wirklich groß > interessiert. Ein kleines Steckernetzteil hat schon das Dreifache an > Heizverlusten. > Ja. Aber die Stückzahlen!!! > Meine Küchenwaage mit dem alten PMOS-µC und 8V Betriebsspannung läuft > mit einem Satz von 6 Mignonzellen gut 3-4 Jahre. Danach werden die > Batterien aber auch schlecht, selbst wenn der µC die Energie nicht ganz > aufgezehrt hat. Das Gerät läuft bei mir täglich gut 3 Minuten. So leicht bist du? ;-) H4 soll doch so fettend sein. (Achtung: Ohne zu Denken wirds gleich gelöscht sein...)
@prx: Du hattest einen C-Compiler auf deinem selbstgebauten 68k System laufen? Was war das fuer eine Compiler? Mit float support? Hattest du ein OS? Dateisystem? Floppy/Festplatte?
A.K. Du zerstörst mein Post durch Kürzung! Ich schränkte bereits den Speicherbereich ein! Der 6809 ist einfach Geschichte. Wir hatten schonmal einen Thread. Nun noch Forth dazu. Dann brauchste das unsägliche C nicht!
A. K. schrieb: > Ein > kompletter(!) C Compiler auf 6809? Nö, lieber nicht. Es gab einen. Introl-C nannte sich das, war natürlich K&R-C, kein ANSI-C, denn das gab es damals noch nicht. http://www.swtpc.com/mholley/Introl/Introl_Brochure.pdf Das von Abdul angesprochene Bussharing der 65xx- und 68xx-Reihe habe ich mal mit einem Terminal umgesetzt, bei dem eine mit einem 6845 gesteuerte Videologik sich den Bus mit einem '09 teilte, beide konnten ohne sich ins Gehege zu kommen auf den Videospeicher zugreifen. War zwar ein kleines Multiplexergrab, funktionierte aber bei 18 MHz Pixeltakt und resultierenden 1.7 MHz Takt für den '09. Tjaja, lang ist's her. Der 6845 lebt übrigens immer noch, er ist (natürlich nur noch als IP-Core) in jeder PC-Graphikhardware enthalten, und dort für den "Textmodus" sowie die unterhalb von VGA angesiedelten Graphikmodi zuständig. MDA, CGA und auch die Herculeskarte waren alle um diesen Baustein herum konstruiert.
Hermocrates schrieb: > Du hattest einen C-Compiler auf deinem selbstgebauten 68k System laufen? Zusammen mit einem Freund. Meins war eine Fertigplatine plus eigenem Zusatzkram wie NVRAM, Floppy-Controller und später einer Dual-Port-Memory Rechnerkopplung mit einem PC-AT. Sein CPU-Board entstand als Selbstbau mit eigener MMU. > Was war das fuer eine Compiler? Mit float support? Der "Portable C Compiler". Mitsamt Fiesskomma-Support, klar. Die initiale 68000 Portierung war nicht von mir, aber das Drumrum wie Assembler, Linker, Betriebssystem war von uns, dazu kam später meine Erweiterung auf gewisse ANSI-C Verträglichkeit. > Hattest du ein OS? Dateisystem? Floppy/Festplatte? Yep. Eigenes Dateisystem mit ziemlich effizientem Floppy-Betrieb. Als dann der Trend zum PC offenbar wurde und Festplatten aufkamen, da gabs dann die erwähnte Rechnerkopplung und der PC diente als I/O-Controller für die Festplatte. Sowas selbst zu bauen war jenseits dessen, was wir uns zutrauten und fertige systemunabhängige Festplattencontroller waren langsamer als die für den PC, und ausserdem sauteuer.
Abdul K. schrieb: > Der 6809 ist einfach Geschichte. Wir hatten schonmal einen Thread. > Nun noch Forth dazu. Dann brauchste das unsägliche C nicht! Forth hatte ich schon auf dem AIM65. Und bei Forth ist es fast egal was drunter liegt, ob 6809 oder 6502.
@prx: Hoert sich verdammt interessant an. Hast du eine Website dazu?
Forth gab es auch für Z80, und zwar sogar in Form eines "Homecomputers". Das war der eher erfolglose Jupiter Ace, aber von dem existieren Nachbauanleitungen wie z.B. die hier http://home.micros.users.btopenworld.com/JupiterAce/JupiterAce.html
Hermocrates schrieb: > @prx: Hoert sich verdammt interessant an. Hast du eine Website dazu? Schlag mal nach wann der PC-AT aktuell war und wann das WWW erfunden wurde.
Ich hatte mal ne zeitlang vom AIM65 geträumt. War aber jenseits meiner Möglichkeiten.
Vom Himmel gefallen war er bei mir auch nicht, sondern das Ergebnis eines Ferienjobs.
Um 1980 hatte ich mir einen Acorn Atom zugelegt - ein Exot mit 6502. Der war günstig, ließ viel Löterei zu, hatte ein eigenartiges BASIC aber eine FP-Erweiterung, die 5 Byte verwendete (4 Byte für die Mantisse). Sein Nachfolger waren der BBC-Computer und der Archimedes, wofür die ersten ARM-CPUs aus gleichem Haus verwendet wurden. Acorn kannte damals keiner, ARM ist heute in aller Munde.
Archimedes. Ja, das waren die Plakate an Händlern immer in der Nähe von Unis, weil die Dinger nur akademische Kreise interessierten ;-) Da es für den AIM65 nicht reichte, wurde mein erster PC ein Z80 selbstgebaut. Letztendlich die bessere Richtung.
Der 6502 ist der am weitesten gereiste Prozessor. Ein paar verrichten heute noch klaglos ihren Dienst in mehr als 10^9 km Entfernung.
> Der 6502 ist der am weitesten gereiste Prozessor. Ein paar verrichten > heute noch klaglos ihren Dienst in mehr als 10^9 km Entfernung. Nicht der 1802? Hast du einen Link für mich?
Echt? Ich dachte das wäre Harris RISC 2000 Forth. Gibts als radiation-hardened. Mal was anderes zu CMOS: Kann mir einer erklären, warum der 74HC14 keine Triggerschwelle um die halbe Versorgungsspannung hat? Die liegt nämlich erheblich tiefer mehr in Richtung TTL-Level. Fein denkt man, das Ding sollte ursprünglich TTL-Logik kompatibel sein, aber nein: Es gibt auch einen extra 74HCT14 dafür. Bei dem ist der Level dann auch passend. Und noch kurioser: Der 74HC74 hat am Clock-Eingang auch einen Schmitt-Trigger: Und der ist genau auf halber Versorgungsspannung!!
> Echt? Ich dachte das wäre Harris RISC 2000 Forth. Gibts als > radiation-hardened. Am Ende dieses Artikels (http://www.bernd-leitenberger.de/computer-raumfahrt2.shtml) ist eine Liste der Prozessoren, die von Kirk & Co. eingesetzt wurden. Deine Waffel ist nicht dabei ;)
Lattice User schrieb: > Der 6502 ist der am weitesten gereiste Prozessor. Ein paar verrichten > heute noch klaglos ihren Dienst in mehr als 10^9 km Entfernung. Worin? Wenn du die Voyager-Sonden meinst: Da sind keine Mikroprozessor-ICs drin, das ist noch Handarbeit.
Markus schrieb: >> Der 6502 ist der am weitesten gereiste Prozessor. Ein paar verrichten >> heute noch klaglos ihren Dienst in mehr als 10^9 km Entfernung. > > Nicht der 1802? Hast du einen Link für mich? Ok, ich schränke meine Aussage etwas ein: Wenn man nach Voyager 1/2 und 6502 googlet findet man viele Hinweise darauf. Macht man das gleiche mit Voyager 1 und 1802 gibt es darauf viele hits. (Mehr sogar). Allerdings auch Hinweise auf eine Custom CPU. Kommt davon wenn man mir richtigem oder falschen Vorwissen Google befrägt. Nach 1802 habe ich erst nach deinem Einwand gesucht.
Google findet auch Spekulationen und Gerüchte. Sowas zu planen und zu bauen dauert viele Jahre und man verwendet bei derartigen Missionen Technik, die als verlässlich bekannt ist. Weder 1802 noch 6502 existierten zu dem Zeitpunkt, zu dem Voyager konzipiert wurde.
Die Voyager 1 - zurückgelegte Strecke 22.780.000.000 km - ist von der NASA selbst gebastelt worden.
>Kann mir einer erklären, warum der 74HC14 keine Triggerschwelle um die >halbe Versorgungsspannung hat? Stimmt nicht. Die liegt in der Mitte.
MCUA schrieb: > Stimmt nicht. Die liegt in der Mitte. Tatsächlich? 74HC14 von NXP bei 6V: rauf typ. 3,14V, runter typ. 1,89V. Mitte geht anders.
Markus. Das ist ja zum Lachen. Glaubst du auch ALDI baut deinen Kaffee an? Der 1802 und auch der Harris 2000 sind typische Space-Prozessoren. Da könnte ihr Links mit dem Gegenteil bringen, wie ihr wollt! Es schwirr(t)en einige Tausend Satelliten um die Erde!
MCUA schrieb: >>Kann mir einer erklären, warum der 74HC14 keine Triggerschwelle um die >>halbe Versorgungsspannung hat? > Stimmt nicht. Die liegt in der Mitte. Dachte ich auch bis gestern, dann habe ich meine LTspice Lib ändern müssen. Ärgerlich, wenn davor ein RC-Filter als Integrator für einen Korrelator sitzt! Es gibt immer Überraschungen!
Der Rechner der Voyager 1 - zurückgelegte Strecke 22.780.000.000 km - ist von der NASA selbst gebastelt worden.
>> Stimmt nicht. Die liegt in der Mitte. >Tatsächlich? 74HC14 von NXP bei 6V: rauf typ. 3,14V, runter typ. 1,89V. >Mitte geht anders. 74HC14 von TI : (bsp bei 4,5V : 1,35V/3,15V) : genau Mitte (auch bei anderen VCCs 2...6V genau Mitte)
> Markus. Das ist ja zum Lachen. Glaubst du auch ALDI baut deinen Kaffee > an? > Der 1802 und auch der Harris 2000 sind typische Space-Prozessoren. Da > könnte ihr Links mit dem Gegenteil bringen, wie ihr wollt! > Es schwirr(t)en einige Tausend Satelliten um die Erde! Was möchtest du mir mitteilen? Dass der 1802 in Satelliten eingesetzt wurde, habe ich oben bereits angedeutet. Wo liegt dein Problem?
MCUA schrieb: > 74HC14 von TI : (bsp bei 4,5V : 1,35V/3,15V) : Nope, das Datasheet von TI sagt für 4.5V: rauf typ 2,5V, runter typ 1,6V. Das sind rauf +0,25V, runter -0,65V relativ zu 2,25V. Auch nicht so ganz Mitte. Deine 1,55V/3,15V sind die min/max-Werte der oberen Schaltschwelle. Der analoge Bereich der unteren Schaltschwelle ist 0,9V/2,45V.
A. K. schrieb: > Google findet auch Spekulationen und Gerüchte. Such is life. > > Sowas zu planen und zu bauen dauert viele Jahre und man verwendet bei > derartigen Missionen Technik, die als verlässlich bekannt ist. Weder > 1802 noch 6502 existierten zu dem Zeitpunkt, zu dem Voyager konzipiert > wurde. 1802 -> 1974 6502 -> 1975 Launch -> 1977 Also wäre durchaus möglich gewesen ohne mit der heissen Nadel gestrickt zu sein. Und die NASA hat keineswegs immer nur auf verlässliche Technik gesetzt.
Lattice User schrieb: > Also wäre durchaus möglich gewesen ohne mit der heissen Nadel gestrickt > zu sein. 2 Jahre zwischen Verfügbarkeit vom Prozessor und Start der Sonde sind für so etwas eine mehr als weissglühende Nadel. > Und die NASA hat keineswegs immer nur auf verlässliche Technik > gesetzt. Hat sie nicht. Aber bei derart langfristigen Missionen zum damaligen Zeitpunkt schon. Die Billigschiene kam später.
> 74HC14 von TI : (bsp bei 4,5V : 1,35V/3,15V) : Obige Werte stimen! sind ausm TI-DS vom 74HC14 . Auch bei AHC14 sind es diese Werte (Vielleicht gibt es mehrere DSs mit anderen Werten?, jedenfalls stimmen die obigen )
Lattice User schrieb: > Also wäre durchaus möglich gewesen ohne mit der heissen Nadel gestrickt > zu sein. Und die NASA hat keineswegs immer nur auf verlässliche Technik > gesetzt. http://voyager.jpl.nasa.gov/faq.html
http://voyager.jpl.nasa.gov/faq.html "Voyager was built in-house at JPL; the computers were manufactured by General Electric to JPL specifications." Aha!
Angehängte Dateien:
-
hc14.gif
28 KB
MCUA schrieb: > Obige Werte stimen! sind ausm TI-DS vom 74HC14 . Auch bei AHC14 sind es > diese Werte (Vielleicht gibt es mehrere DSs mit anderen Werten?, > jedenfalls stimmen die obigen ) Anbei die von mir verwendete Version mit typ 2,5V / 1,6V.
A. K. schrieb: > Lattice User schrieb: > >> Also wäre durchaus möglich gewesen ohne mit der heissen Nadel gestrickt >> zu sein. > > 2 Jahre zwischen Verfügbarkeit vom Prozessor und Start der Sonde sind > für so etwas eine mehr als weissglühende Nadel. Die Konzeptphase wurde 1975 abgeschlossen. Etwas knapp für den 6502, aber nicht für den 1802. >> Und die NASA hat keineswegs immer nur auf verlässliche Technik >> gesetzt. > > Hat sie nicht. Aber bei derart langfristigen Missionen zum damaligen > Zeitpunkt schon. Die Billigschiene kam später. Auch schon vorher, bis 1967 wurde sogar richtiggehend geschlampt. Lies mal die Details zur Apollo 1 Katastrophe. Der Computer der Mondlandefähre musste sogar mehrfach bei der Landung neu gestartet werden (Apollo 11). (Spricht allerdings auch für sein Konzept dass das ohne Abruch der Mission überhaupt möglich war)
Angehängte Dateien:
-
hc14b.PNG
18 KB
A. K. schrieb: > Anbei die von mir verwendete Version mit typ 2,5V / 1,6V. PS: Diesmal mit Markierung.
Angehängte Dateien:
-
Bildschirmfoto.png
18 KB
Auf dem Bild sieht man das schön wie die Schwellen verlaufen. Das ist von ON-Semiconductors.
> 74HC14 von TI : (bsp bei 4,5V : 1,35V/3,15V) :
sind min/max Werte. Diese Werte stehen auch im DS auch unter
'recommended operating conditions'
Markus schrieb: >> Markus. Das ist ja zum Lachen. Glaubst du auch ALDI baut deinen Kaffee >> an? > Die Nasa baut nichts, die vergibt Aufträge und bastelt nebenher etwas. >> Der 1802 und auch der Harris 2000 sind typische Space-Prozessoren. Da >> könnte ihr Links mit dem Gegenteil bringen, wie ihr wollt! > >> Es schwirr(t)en einige Tausend Satelliten um die Erde! > > Was möchtest du mir mitteilen? Dass der 1802 in Satelliten eingesetzt > wurde, habe ich oben bereits angedeutet. Wo liegt dein Problem? Das es wesentlich mehr Varianten als bei Googles ersten Blick dokumentiert, gibt. Du hattest ja gesagt, der Harris wäre nicht dabei. Ich weiß es aber anders.
MCUA schrieb: > sind min/max Werte. Diese Werte stehen auch im DS auch unter > 'recommended operating conditions' Ich glaub wir reden aneinander vorbei. Die ursprüngliche Frage war: "Kann mir einer erklären, warum der 74HC14 keine Triggerschwelle um die halbe Versorgungsspannung hat?" Meine Interpretation war: Er wunderte sich darüber, dass die beiden Schaltschwellen dieses Schmitt-Triggers nicht leidlich symmetrisch um Vcc/2 herum liegen, sondern tiefer. Man kann diesen Text natürlich auch wortwörtlich so verstehen, dass er eine der beiden Schaltschwellen bei Vcc/2 erwartet, die andere darunter. Aber so verstanden gibt seine Frage nicht für mich allzu viel Sinn.
> Du hattest ja gesagt, der Harris wäre nicht dabei. Ich weiß es aber anders. Der Harris ist nicht in der Liste und nichts anderes habe ich geschrieben. > Die Nasa baut nichts, die vergibt Aufträge und bastelt nebenher etwas. Der Satz ist widersprüchlich: am Anfang schreibst du, dass die die NASA nichts baut, am Ende, dass sie nebenher bastelt. Ansonsten möchte ich dein Augenmerk auf diesen Beitrag (Beitrag "Re: 6502 Prozessor wer kennt den noch?") lenken.
(zu 74HC14) >Meine Interpretation war: Er wunderte sich darüber, dass die beiden >Schaltschwellen dieses Schmitt-Triggers nicht leidlich symmetrisch um >Vcc/2 herum liegen, sondern tiefer. Wenn man die min/max Werte nimmt (auch in recommended im DS) dann sind diese Werte symmetrisch um VCC/2.
Abdul K. schrieb: > Und noch kurioser: Der > 74HC74 hat am Clock-Eingang auch einen Schmitt-Trigger: Und der ist > genau auf halber Versorgungsspannung!! Wenn du einen besseren Schmitt-Trigger haben möchtest, mit selbst bestimmter Hysterese, mache ihn mit 2 Widerständen und einem nicht invertierenden CMOS-Gatter, oder eben mit 2 invertierenden Gattern, wenn die verfügbarer sind.
> Und noch kurioser: Der 74HC74 ... 74HC14 u. 74HC74 haben lt DS von TI genau die gleichen Schaltschwellen.
MCUA schrieb: > 74HC14 u. 74HC74 haben lt DS von TI genau die gleichen Schaltschwellen. Beim HC74 ergibt das auch Sinn. Denn da interessiert nur Vt+.
>> 74HC14 u. 74HC74 haben lt DS von TI genau die gleichen Schaltschwellen. >Beim HC74 ergibt das auch Sinn. Denn da interessiert nur Vt+. Nein, auch beim CLK interessiert VT- , denn ohne wirksame VT- keine wirksame VT+!
MCUA schrieb: > 74HC14 u. 74HC74 haben lt DS von TI genau die gleichen Schaltschwellen. TI ist nicht der einzige Hersteller; jeder kocht da seine eigene Suppe. Und wenn ein 74HC74 einen Schmitt-Trigger am Clock-Eingang hat ist das schön, ein anderer Hersteller läßt ihn auch gerne weg. Abdul K. schrieb: > Da es für den AIM65 nicht reichte, wurde mein erster PC ein Z80 > selbstgebaut. Letztendlich die bessere Richtung. Da war ja schon immer so: keine Ahnung von Elektronik aber einen Z80 gut finden :-)
Markus schrieb: >> Du hattest ja gesagt, der Harris wäre nicht dabei. Ich weiß es aber anders. > > Der Harris ist nicht in der Liste und nichts anderes habe ich > geschrieben. > Das wäre dann ok. Die List ist viel zu kurz. >> Die Nasa baut nichts, die vergibt Aufträge und bastelt nebenher etwas. > > Der Satz ist widersprüchlich: am Anfang schreibst du, dass die die NASA > nichts baut, am Ende, dass sie nebenher bastelt. > Das ist doch nervig! Die NASA ist in erster Linie eine Behörde. Der größte Teil des Geldes geht in die Förderung der amerikanischen Großindustrie. Ja genau die, die per Lobbyisten die Abgeordneten schmieren. Welch Zufall. Damit das schöner rüberkommt, macht man noch PR durch Bildchen von schönen Projekten. Die sind intern.
A. K. schrieb: > MCUA schrieb: > >> sind min/max Werte. Diese Werte stehen auch im DS auch unter >> 'recommended operating conditions' > > Ich glaub wir reden aneinander vorbei. Die ursprüngliche Frage war: > > "Kann mir einer erklären, warum der 74HC14 keine Triggerschwelle um die > halbe Versorgungsspannung hat?" > > Meine Interpretation war: Er wunderte sich darüber, dass die beiden > Schaltschwellen dieses Schmitt-Triggers nicht leidlich symmetrisch um > Vcc/2 herum liegen, sondern tiefer. > > Man kann diesen Text natürlich auch wortwörtlich so verstehen, dass er > eine der beiden Schaltschwellen bei Vcc/2 erwartet, die andere darunter. > Aber so verstanden gibt seine Frage nicht für mich allzu viel Sinn. Jede Frage kann man nur mit Vorwissen über den Fragesteller sinnvoll beantworten. Daher denke ich, A.K. weiß etwas über mich ... und hat es auch in meinem Sinne interpretiert. Das Problem ist zweigestaltig und ergibt sich aus der Tatsache, das CMOS die höchste Störtoleranz bei Schaltschwellen nahe VCC Halbe hat: 1. niedrigere Störtoleranz, da woanders. Asymmetrie für analog Signale die in manchen Anwendungen niederfrequent gleichspannungsfrei sind. Ein Beispiel hatte ich mit dem Korrelator genannt. 2. Jeder Hersteller kocht ein anderes Süppchen. Keine universelle SPICE-Lib möglich.
MCUA schrieb: >> Und noch kurioser: Der 74HC74 ... > 74HC14 u. 74HC74 haben lt DS von TI genau die gleichen Schaltschwellen. Bei NXP aber nicht!
Wilhelm Ferkes schrieb: > Abdul K. schrieb: > >> Und noch kurioser: Der >> 74HC74 hat am Clock-Eingang auch einen Schmitt-Trigger: Und der ist >> genau auf halber Versorgungsspannung!! > > Wenn du einen besseren Schmitt-Trigger haben möchtest, mit selbst > bestimmter Hysterese, mache ihn mit 2 Widerständen und einem nicht > invertierenden CMOS-Gatter, oder eben mit 2 invertierenden Gattern, wenn > die verfügbarer sind. Danke für deine Hilfestellung. Ist halt ärgerlich, wenn man richtiges Verhalten impliziert hat und erst später drüber stutzt. Was mache ich nun mit meiner Mondrakete?
> Das ist doch nervig! Das wollte ich mit meinem Beitrag, der "Satzkritik" und dem Link zum Ausdruck bringen. Ansonsten habe ich das Gefühl, dass vom Thema nicht viel übrig geblieben ist. Weiter oben im Thread steht, dass die Transistoren des Design NMOS "enhancement mode" und NMOS "depletion mode" sind. Dazu eine Frage: ist es denkbar die beiden Transistoren durch BS170 & BS250 zu ersetzen?
>Jede Frage kann man nur mit Vorwissen über den Fragesteller sinnvoll >beantworten. Oje. Die Frage war, warum sich die Schwellen angeblich nicht symm. um VCC/2 herum bewegen. Was gibts da zu interpretien? Und die angeg min/max-Werte bewegen sich symm. um VCC/2 . >1. niedrigere Störtoleranz, Du meinst wohl Hohe Störsicherheit >..woanders Hä?
Markus schrieb: > Weiter oben im Thread steht, dass die Transistoren des Design NMOS > "enhancement mode" und NMOS "depletion mode" sind. Dazu eine Frage: ist > es denkbar die beiden Transistoren durch BS170 & BS250 zu ersetzen? Nein. Der BS250 ist ein enhancement mode P-FET und als solcher nicht gut als Stromquelle zu gebrauchen.
Abdul K. schrieb: > Was mache ich > nun mit meiner Mondrakete? Abdul, sei nicht besorgt über Apollo-Projekte. Die machten damals noch Computer aus 3-Input-NOR-Gates in RTL-Technik, und ein bißchen Rechnerei mit Boolescher Algebra, das funzte auch, die Menschen kehrten lebendig wieder zurück.
Markus schrieb: > es denkbar die beiden Transistoren durch BS170 & BS250 zu ersetzen? Du kannst aber neben dem BS170 für die Rolle des dep-N-FET einen N-Kanal J-FET wie den BF245-A verwenden.
MCUA schrieb: > Und die angeg min/max-Werte bewegen sich symm. um VCC/2 . Dein min-Wert ist nicht der untere Schwellwert, sondern die untere Grenze des oberen Schwellwertes. Daher liegt der über Fertigungstoleranzen und Themperaturen variierende Bereich des oberen Schwellwerts um Vcc/2 herum. Das war aber nicht die Fragestellung.
> Nein. Der BS250 ist ein enhancement mode P-FET und als solcher nicht gut > als Stromquelle zu gebrauchen. Das ist richtig: was ich meinte, ob es möglich ist, das Design in eine NMOS/PMOS Struktur umzuwandeln. BS170 & BS250 sind immerhin recht preiswert zu bekommen.
Markus schrieb: > Das ist richtig: was ich meinte, ob es möglich ist, das Design in eine > NMOS/PMOS Struktur umzuwandeln. Klar. Nimm einfach das Schaltbild des CMOS-Kollegen 65C02.
MCUA schrieb: >>Jede Frage kann man nur mit Vorwissen über den Fragesteller sinnvoll >>beantworten. > Oje. Die Frage war, warum sich die Schwellen angeblich nicht symm. um > VCC/2 herum bewegen. Was gibts da zu interpretien? > Und die angeg min/max-Werte bewegen sich symm. um VCC/2 . > Verstehe ich nicht. Mich interessieren nur die typischen Werte (Zumindest in diesem Fall). >>1. niedrigere Störtoleranz, > Du meinst wohl Hohe Störsicherheit Ist dasselbe. >>..woanders > Hä? Woanders ist weg von der halben Versorgungsspannung.
> Klar. Nimm einfach das Schaltbild des CMOS-Kollegen 65C02.
Fein. Hast du einen Link?
Wilhelm Ferkes schrieb: > Abdul K. schrieb: > >> Was mache ich >> nun mit meiner Mondrakete? > > Abdul, sei nicht besorgt über Apollo-Projekte. Die machten damals noch > Computer aus 3-Input-NOR-Gates in RTL-Technik, und ein bißchen Rechnerei > mit Boolescher Algebra, das funzte auch, die Menschen kehrten lebendig > wieder zurück. Und für den Notfall hatte man die Filmchen schon im Studio gedreht. Ja ja. Ich meinte aber MEINE Mondrakete: Den Korrelator. Ich kenne den Apollo-Recher.
Markus schrieb: >> Klar. Nimm einfach das Schaltbild des CMOS-Kollegen 65C02. > > Fein. Hast du einen Link? Sag mal Markus: Bist du der das Schaltnetzteil fürs Bordnetz entwickelt? 6 Wochen werden nicht reichen! Völlig unrealistisch. Schau dir mal den Plan an. Das sind alleine 10.000 Lötpunkte. Vielleicht steht gar nicht alles notwendige drinnen. Mir erschließt sich die Funktion jedenfalls auf Anhieb nicht komplett. Realistischer wäre ein Ansatz aus 74HC und EPROM. Eine 'Euro-Platine, 6 Wochen, das würde ich vielleicht hinkriegen.
Jens Petersen schrieb: > Abdul K. schrieb: >> Da es für den AIM65 nicht reichte, wurde mein erster PC ein Z80 >> selbstgebaut. Letztendlich die bessere Richtung. > > Da war ja schon immer so: keine Ahnung von Elektronik aber einen Z80 gut > finden :-) Zustimm :-) 8080 und Nachfolger (u.A. Z80) haben eine Registerarchitektur ins Leben gerufen unter der wir heute noch leiden (x86).
Markus schrieb: > Fein. Hast du einen Link? Mach es einfach so wie jene, die dem 6502 ihr Innenleben entlockten. Bischen Schleifen, bischen Ätzen und dann ein Mikroskop nutzen. Und schon liegt das Schaltbild klar und deutlich vor Augen ;-).
> Mach es einfach so wie jene, die dem 6502 ihr Innenleben entlockten. > Bischen Schleifen, bischen Ätzen und dann ein Mikroskop nutzen. Und > schon liegt das Schaltbild klar und deutlich vor Augen ;-). ... und da wir Pfingsten haben und einen Tag mehr "frei", ist die Zeit auch kein Problem. Danke für deinen Ratschlag.
Abdul K. schrieb: > Markus schrieb: >>> Klar. Nimm einfach das Schaltbild des CMOS-Kollegen 65C02. >> >> Fein. Hast du einen Link? > > Sag mal Markus: Bist du der das Schaltnetzteil fürs Bordnetz entwickelt? > > 6 Wochen werden nicht reichen! Völlig unrealistisch. Schau dir mal den > Plan an. Das sind alleine 10.000 Lötpunkte. Vielleicht steht gar nicht > alles notwendige drinnen. Mir erschließt sich die Funktion jedenfalls > auf Anhieb nicht komplett. > > Realistischer wäre ein Ansatz aus 74HC und EPROM. Eine 'Euro-Platine, 6 > Wochen, das würde ich vielleicht hinkriegen. Guck da: Beitrag "Dynamisch visualisierbarer Schaltplan eines 65C02 Mikroprozessors"
Keine Angst Lattice! Mit so einem Schrott wie die 6502 aus heutiger Sicht ist, werde ich meine Zeit nicht mehr verbringen. Da ärgere ich euch lieber hier ;-)
>Dein min-Wert ist nicht der untere Schwellwert, Hab ich nicht behauptet >Mich interessieren nur die typischen Werte.. Die interessieren norm. gerade nicht. Es interssieren norm. die min..max- Werte, weil die in Wirklichkeit auftreten können (WorstCase) Und es ist beim HC14 nicht gesagt, dass die min..max-Werte von Vt-/+ sich bei Temp-Änder. genau linear zueinander verhalten. Es sind keineswegs Präz-U-Komparatoren! (9500XL- PLDs haben auch Schmitt-trg, da ist die Hyster. gerade mal 50mV!)
Lattice User schrieb: > Jens Petersen schrieb: >> Abdul K. schrieb: >>> Da es für den AIM65 nicht reichte, wurde mein erster PC ein Z80 >>> selbstgebaut. Letztendlich die bessere Richtung. >> >> Da war ja schon immer so: keine Ahnung von Elektronik aber einen Z80 gut >> finden :-) > > Zustimm :-) > > 8080 und Nachfolger (u.A. Z80) haben eine Registerarchitektur ins Leben > gerufen unter der wir heute noch leiden (x86). 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. Namaste
> Mir erschließt sich die Funktion jedenfalls auf Anhieb nicht komplett. Jetzt bin ich schon wieder um eine Illusion ärmer. > Guck da: > Beitrag "Dynamisch visualisierbarer Schaltplan eines 65C02 Mikroprozessors" Hübsches TTL-Grab ;)
> 8080 und Nachfolger (u.A. Z80) haben eine Registerarchitektur ins Leben > gerufen unter der wir heute noch leiden (x86). Für typische Embedd-Syst. wollte diese blöde x86-Architektur noch nie jemand haben.
Abdul K. schrieb: > Mit so einem Schrott wie die 6502 Auch wieder typisch für Z80 Nutzer; keine Toleranz :-)
MCUA schrieb: > Für typische Embedd-Syst. wollte diese blöde x86-Architektur noch nie > jemand haben. 188er fand man nicht selten als Controller auf Festplatten.
Ich weiß sehr wohl wann es darauf ankommt, max/min-Werte zu benutzen! Das ist hier nicht das Thema! Die Triggerschwellen korrelieren mit Versorgungsspannung und Temperatur in ganz eindeutiger Weise! Genaus die sich ergebende Hysterese mit der Versorgungsspannung. Die Eingangsschwelle wird durch das Verhältnis der beiden W-Werte der Eingangs-FETs bestimmt. L und W sind stark prozeßabhängig. Damit schwankt der Spannungsübergabepunkt oder wie man es nennen will. Es ist alles streng monoton. Zum Testen kann man ein ungepuffertes Gatter wie HCU04 vom Ausgang auf den Eingang kurzschließen. Die sich ergebende Spannung sollte bei VCC/2 zu liegen kommen.
Jens Petersen schrieb: > Abdul K. schrieb: >> Mit so einem Schrott wie die 6502 > > Auch wieder typisch für Z80 Nutzer; keine Toleranz :-) Auf was willst du hinaus? Mein Liebling ist die 6809 ! Der Z80 war einfach mit mehr Möglichkeiten ausgestattet, wenn man auch die undokumentierten Befehle mitbenutzte. Da gab es beim Z80 eine Unmenge.
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. > > Namaste Na ja, beim 6502 kann man ja von Registerschitektur nicht sprechen. Und die Systemarchitektur war im Grunde auch nicht ausbaufähig. Hauptproblem dabei der 8 bit Stackpointer, d.h. nicht wirklich C kompatibel. Eine 16bit Version des Prozessors ist ja auch am Markt gescheitert (IMO zu recht). Übrigens meinen Apple II besitze ich noch :-) Einschliesslich Z80 Karte, 1 MB Ramdisk (selbstgebaut) und eine 8086 Karte (auch selbst gebaut).
Lattice User schrieb: > Eine 16bit Version des Prozessors ist ja auch am Markt gescheitert (IMO > zu recht). Arg krudes Teil. 2 Jahre nach dem Original hätte das Teil wohl Chancen gehabt, trotz der stumpfsinnigen Architektur. Aber zu dem Zeitpunkt wo das Ding rauskam wars nur noch ein Witz.
Tja, der richtig Zeitpunkt. Das ist immer das Problem Nr.1 Ich habe mal Mr. CMOS himself gefragt wegen des HC14. Ist nur ein Ausschnitt und begann eigentlich mit dem HCU04. Er meinte das (Mein Text mit > ): >I must say that the OnSemi DS for HCU04 is crap. No typical values >there. So no compare possible with model. Data sheets are written to avoid claiming anything they could get sued for =-O > > >Can I ask Mr. CMOS another question? >Why is the trigger level of the 74HC14 not half VCC? It is considerable >lower! >I thought this could be TTL conversion compatibility but there is >another variant 74HCT14 extra for TTL. Strange. >Looking at the 74HC74 there is a schmitt-trigger input function in CLK >input. And now interesting: Here it is half VCC ! Schmitt thresholds are at the discretion of the circuit designer.
MCUA schrieb: > Für typische Embedd-Syst. wollte diese blöde x86-Architektur noch nie > jemand haben. Dafür gibt es aber mehr als genug Systeme, die einen 80188/186 einsetzen. Aber das wird wohl an den recht brauchbaren Entwicklungssystemen liegen, die es dafür schon in den 90ern gab (wie z.B. die DOS-C-Compiler von Borland).
Ebend! Das mit der gewohnten Entwicklungsumgebung und der Tatsache, das die meisten Entwickler/Supporter mit DOS vertraut waren, war immer ein Argument. Gerne auch der miserable 386EX. Das ist aber 10 Jahre her! Heute geht der Zug zu ARM, NET usw. Rufus, die Rente wartet ;-)
Borlands Turbo-Pascal 1.0 lief sogar auf meinem Apple unter CP/M mit Z80 und 64KByte RAM. Der erste Bildschirm orientierte Editor den ich hatte ....
Abdul K. schrieb: > Rufus, die Rente wartet ;-) Ach danke, aber ich fürchte, daß sie das bei mir noch eine ganze Weile lang tun wird.
MCUA schrieb: > Für typische Embedd-Syst. wollte diese blöde x86-Architektur noch nie > jemand haben. Waren (sind) nicht 80186er in den Signalanlagen der Bahn verbaut worden.
Abdul K. schrieb: >>Looking at the 74HC74 there is a schmitt-trigger input function in CLK >>input. And now interesting: Here it is half VCC ! Bei NXP finde ich beim HC74 die gleichen unsymmetrischen Vt+/Vt- Werte wie beim HC14. Und bei TI finde ich bei CLK keinen Schmitt-Trigger.
A. K. schrieb: >> Eine 16bit Version des Prozessors ist ja auch am Markt gescheitert (IMO >> zu recht). > > Arg krudes Teil. 2 Jahre nach dem Original hätte das Teil wohl Chancen > gehabt, trotz der stumpfsinnigen Architektur. Aber zu dem Zeitpunkt wo > das Ding rauskam wars nur noch ein Witz. Das wäre 1977 gewesen. Zu diesem Zeitpunkt wäre aber die Binärkompatibilität zum 6502 kein absolutes Muss gewesen. Als er kam war diese Kompatibilität seine einzige Hoffnung, d.h. für 16bit Versionen der erfolgreichen AppleII und C64. Wobei nur ein AppleIII das Licht der Welt erblickt hat, war aber viel zu spät, auch wegen der Inhouse Konkurrenz. Ob Commodore je eine 16bit Version des C64 erwogen hat ist mir nicht bekannt. Zum Vergleich: 8086 wurde 1978 vorgestellt, der 68000 1979.
Ähnlich bizarre Fortsätze wie W65C816 hat übrigens auch Zilog verbrochen. Wobei die eZ80 mit 24-Bit Adressierung und entsprechenden Registern noch die harmlose Version ist. Wirklich krass ist die Z380, eine 32-Bit Version der Z80.
beide kamen zu spät, mit dem 68000 und sogar mit dem "komischen" 8088 war mehr Speicher (ohne Banking) möglich
A. K. schrieb: > Abdul K. schrieb: > >>>Looking at the 74HC74 there is a schmitt-trigger input function in CLK >>>input. And now interesting: Here it is half VCC ! > > Bei NXP finde ich beim HC74 die gleichen unsymmetrischen Vt+/Vt- Werte > wie beim HC14. Und bei TI finde ich bei CLK keinen Schmitt-Trigger. Die Unterschiede sind eine Katastrophe. Aus analoger Sicht. Hier ist es symmetrisch bei NXP: http://www.nxp.com/documents/data_sheet/74HC_HCT74.pdf
Der große Speicherbereich der 68K hat ihr wenig gebracht, dagegen die 1-2 Jahre frühere Markteinführung dem 8086 den Durchbruch - wie wir ja fast jeder neben dem Schreibtisch stehen sehen. Wobei man aber sagen muß, daß der moderne PC nur noch beim Booten ein 86er ist.
Abdul K. schrieb: > Hier ist es symmetrisch bei NXP: > http://www.nxp.com/documents/data_sheet/74HC_HCT74.pdf Stimmt, da bin ich wohl ins falsche DS gerutscht. Allerdings stehen hier keine Triggerlevels drin, sondern nur die üblichen Eingangsparameter. Deren geringer Eingangsbereich von typ Vil=2.1V/Vih=2.4V bei Vcc=4,5V macht deutlich, dass die Hysterese hier viel kleiner sein muss als beim HC14, es sich folglich um eine anderes aufgebaute Schmitt-Trigger Stufe handelt.
Teilweise brauchten die EPROMs mehr Strom als der Prozessor selbst. Die 2716er EPROMs waren schon richtig vornem die kamen schon mit nur einer Betriebsspannung aus beim lesen entgegengesetzt zum 2708 der umständliche DREI verschiedene Spannungen braucht 5V 12V und -8V. Dann gab es noch so komische TMS2716 von Texas Instruments die auch noch die nervige Stromversorgung will.
Yep. Gutdünken oder Absicht? "Schmitt thresholds are at the discretion of the circuit designer."
Bei den DRAM war an jeder Ecke ein Versorgungsanschluß... Ach, da erinnere ich mich: 2x Angebot genutzt für CMOS 64Kx1 8 Bausteine macht: 128KByte für 340DM.
Abdul K. schrieb: > Der große Speicherbereich der 68K hat ihr wenig gebracht, dagegen die > 1-2 Jahre frühere Markteinführung dem 8086 den Durchbruch - wie wir ja > fast jeder neben dem Schreibtisch stehen sehen. Zum Zeitpunkt der PC-Entscheidung hatte IBM bereits ein 68000 System gebaut, für anderen Zweck. Der Grund für 8088 lag einerseits in den Kosten vom Gesamtsystem, im 8-Bit Bus, und auch die nutzbare 8080-Peripherie spielte eine Rolle. Bei 68000 war beispielsweise das Thema DMA schlecht besetzt (bzw. teuer, sofern überhaupt schon da). Andererseits wurden vielen damalige Entscheidungen von IBM auf einen Aspekt konzentriert: Es durfte keinesfalls der Eindruck entstehen, dass ein solches System über kurz oder lang das lukrative Mainframe-Geschäft verdirbt. Eine aus Sicht der Programmierers 32 Bits breite dem Mainframe ähnliche Architektur hätte aber genau dies nahe gelegt. Auf ähnliche Art hatte IBM auch eine andere Entwicklung versemmelt: IBM hatte in den 70ern eine bahnbrechende RISC-Entwicklung, die aus genau diesem Grund letztlich in einem I/O-Satellitenrechner vergammelte, statt das Mainframe-Geschäft zu vermiesen. Bloss keine schlafenden Hunde wecken. Das taten dann andere.
Abdul K. schrieb: > Yep. Gutdünken oder Absicht? Absicht. Eine Stufe wie beim HC14 hätte die Eingangsbedingungen zu weit von den HC74ern anderer Hersteller ohne Schmitt-Trigger entfernt. Ein nettes Gimick, dass manchmal nützlich ist, aber nicht im Weg stehen darf.
A.K. Du hast es geblickt! Übrigens sind wir wieder beim ollen Terminal angekommen: Windows ist nichts anderes! Achso, wollte noch nachtragen: Meine erste Maus kostete 250DM. Ha ha, war ich blöde.
Abdul K. schrieb: > Der große Speicherbereich der 68K hat ihr wenig gebracht Die 68000 und Folgeversionen waren über lange Zeit sehr erfolgreich, nur eben nicht ganz so erfolgreich wie x86.
Ja, netter Satz. Stammt direkt aus dem Shareholder Geschäftsbericht, oder? Wir haben es vermasselt, aber wir waren gut! So gut, das Apple aus lauter Not den PowerPC einkaufen mußte. Weil Motorola keine gescheite CPU jenseits der 040 zurechtbekam und beim 040 schon nicht genug geliefert wurde.
Abdul K. schrieb: > A.K. Du hast es geblickt! Übrigens sind wir wieder beim ollen Terminal > angekommen: Einerseits ja ... > Windows ist nichts anderes! ... aber andererseits nicht deshalb. Der Terminalbetrieb findet sich in Umgebungen wieder, bei denen die eigentliche Arbeit über Terminal-Services oder virtualisiert auf RZ-Rechnerfarmen abläuft, statt auf dem nun zum Grafikterminal degradierten PC. Oder/und in Form immer mehr browserbasierter Anwendungen - grad da kommt noch einiges auf uns zu. Mit Windows hat das allerdings wenig zu tun.
Für Microsoft, Apple und Computerlibhaber: Super Webseite zu kaputlachen: http://www.stupidedia.org/stupi/Portal:Computer
Was man früher Terminal/ etc. nannte haben wir heute alles wieder, nennt sich nur 'Cloud'. Bestes Beispiel sind Spiele, die in der Wolke gerendert und aufs Tablet gestreamt werden.
Und wie ist so die Sicht auf uns, wenn man 16 ist?
Abdul K. schrieb: > Ja, netter Satz. Stammt direkt aus dem Shareholder Geschäftsbericht, > oder? Wir haben es vermasselt, aber wir waren gut! Es lief ja auch wirklich eine Zeitlang gut, nur war eben irgendwann Schluss. Das ist oft so. War Nokia von Anfang an schlecht oder verdammt? Nein, aber irgendwann... Auch Intel kann es passieren, dass in den nächsten Jahren der halbe Client-Markt wegbricht und bei ARMs landet. Beide Architekturen waren eigentlich am Ende, die ersten 32-Bit x86er wie die 68030/40 Schiene, da der Aufwand für eine zu den RISC vergleichbaren Leistung durch die CISC-Architektur und Fehlentscheidungen unterwegs sehr hoch war. Intel hatte aber aufgrund des grossen Erfolgs der PCs genug Resourcen, um mit dem in der Entwicklung und Produktion sehr teuren Pentium-Pro den Knoten zu durchschlagen. Damit war der Kessel geflickt. Ohne diesen Erfolg wäre Intel längst Geschichte. Motorola hatte weniger Resourcen und eine zu diesem Zeitpunkt deutlich verbautere Architektur (was 1978 gut war, das war 1990 ein Problem). Vieles von dem was die 68020 hinzufügte erwies sich als übler Klotz am Bein, wenns um superskalere Implementierung geht. Mit Coldfire flog das meiste davon wieder raus - und darin lebt die 68000 bis heute weiter. > So gut, das Apple aus > lauter Not den PowerPC einkaufen mußte. Und weil es Intel so schlecht geht werden sie demnächst aus lauter Not teilweise auf ARM umsteigen. > Weil Motorola keine gescheite CPU jenseits der 040 zurechtbekam Möglich wärs gewesen, aber der Aufwand war für Motorola zu gross. Die Entscheidung für eine andere Linie war richtig. Beim Versuch, mit der VAX eine einstmals sehr erfolgreiche nun aber überholte Architektur mit immensem Entwicklungsaufwand noch über die Runden zu retten ist DEC fast vor die Hunde gegangen. Das haben sie dann später zwar nachgeholt, aber es war schon Jahre vorher sehr knapp geworden.
Herrlich off-topic. A.K. kann man stundenlang zuhören.
Ich habe mit dem Thema mal angefangen und möchte mich für eure
Bemühungen bedanken und mich entschuldigen das ich jetzt er wieder
Melde.
wie_warr_das_thema schrieb
> Alles ein wenig "Off-Topic" hier?!
Ist aber wurscht Hauptsache mann hat Spass hier. Das Thema geht mehr
oder weniger um die Alten Prozessoren anfang der Achtziger ende der
Sibziger und deren einsatzorte.
Interessant wäre auuch wass Ihr mit dem r6502 oder ähnlichen angestellt
habt?
bko schrieb: > mit dem 68000 und sogar mit > dem "komischen" 8088 war mehr Speicher (ohne Banking) > möglich 8086/88 hatten das Banking eingebaut, Segmentregister sind nichts als eine komfortable Version davon. Während der 68000 immerhin schon eine ausgewachsene 32bit Architektur hatte. Aber wie A.K. oben ausführte, IBM wollte keine Biligkonkurrenz zum Mainframe. Der 68000 war durchaus erfolgreich, neben Apple gabs ja noch Atari ST und Commodore Amiga. Sowie natürlich jede Menge Industrie-Systeme. (siehe VME Bus).
ich weiß ich weiß, ein 68000 (ein 68008 hätts auch getan) wäre damals ein Traum gewesen, ein lahmer 8088 mit nun endlich 256kByte Speicher wahr einfach billiger und hat meine Apple-2 Platine dann abgelöst...
Abdul K. schrieb: > Und wie ist so die Sicht auf uns, wenn man 16 ist? Amüsant, was die Entwickler jenseits des Atlantiks so vor >30 Jahren erschaffen haben. Allerdings hatte ich als 'Digital/AVR/MSP430 native' nie was mit der Entwicklung für solche 'Steinzeit'-MCUs/MPUs zu tun, und habe auch nicht vor Kuchenbleche voll mit EPROMS, SRAMs, Busdecodern, UARTs etc. anzutun ;) So weiß man erst zu schätzen, wie einfach das heute alles ist...
bko schrieb: > ich weiß ich weiß, ein 68000 (ein 68008 hätts auch getan) > wäre damals ein Traum gewesen, ein lahmer 8088 mit nun > endlich 256kByte Speicher wahr einfach billiger > und hat meine Apple-2 Platine dann abgelöst... Verräter! Ich habe den Umstieg auf x86 immerhin noch mit einem Atari ST um ein paar Jahre hinausgezögert.
purer Geldmangel (heute unvorstellbar wie teuer das Zeug mal war) Aber: die Apple2 Platine lebt noch, der 8088 Computer ist schon lange im Schrott gelandet ...
Die Geschichte zu den Segmentregistern muß nun auch noch kommen: Man wollte ursprünglich echte 20 Bits unterbringen, aber die MMU wurde zu groß! Also speckte man ab. Was dann Intel alles damit trieb, darf A.K. erzählen. Das Konzept wurde ja mehrmals neu betoniert.
Lattice User schrieb: > 8086/88 hatten das Banking eingebaut, Segmentregister sind nichts als > eine komfortable Version davon. Während der 68000 immerhin schon eine > ausgewachsene 32bit Architektur hatte. Aber wie A.K. oben ausführte, IBM > wollte keine Biligkonkurrenz zum Mainframe. > Vorsicht! Der 68K kannte nur 16-Bit Code-Segmente! Das fand ich echt nervig. Apple hat da drumrum eine Software-MMU gebaut, die solche Segmente automatisch nachlud. Elegante Lösung für ein Problem. Erst der 68010 war was gescheites. Dann hätte Apple auch leichter auf Multitasking gehen können. Da mußten sie dann wieder endlos tricksen, denn nun mußte es beim 68020 zum alten Konzept der 68000 kompatibel bleiben.
Abdul K. schrieb: > Vorsicht! Der 68K kannte nur 16-Bit Code-Segmente! Was darf ich mir denn darunter vorstellen? Segmente gabs ja seitens der CPU überhaupt keine, MMU gabs auch nicht und die Adressierung war linear 32-bittig. Wer eine MMU brauchte machte sie sich selber - und wenns bloss mein Design aus ein paar 74LS670 + 74S283 war, mit max je 8MB grossem Code-, Daten und Stacksegment.
Man konnte bei den Relativsprüngen nur vorzeichenbehaftete 16-Bit Offsets angeben. Will man Code-Segmente im Speicher verschieben, geht sowas nur mit Relativsprüngen im Code. Absolutsprünge müßte man neu berechnen! Das ist aber Binärcode, was im Speicher steht! Vielleicht bin ich zu sehr Apple-lastig. Das war eben meine 68K Assemblerplattform. Der Apple Memory-Manager hat diese Segmente nämlich für einen komfortabel verwaltet, automatisches Nachladen von Segmenten von der Diskette usw. Jedenfalls durften sie dort dann nur 32K groß werden. Bei A.K. war bestimmt alles viel besser ;-)
Abdul K. schrieb: > Vorsicht! Der 68K kannte nur 16-Bit Code-Segmente! Das fand ich echt > nervig. Apple hat da drumrum eine Software-MMU gebaut, die solche > Segmente automatisch nachlud. Elegante Lösung für ein Problem. > Erst der 68010 war was gescheites. Dann hätte Apple auch leichter auf > Multitasking gehen können. Da mußten sie dann wieder endlos tricksen, > denn nun mußte es beim 68020 zum alten Konzept der 68000 kompatibel > bleiben. Das ist nicht richtig, der 68000 hatte eine 32 bit lineare Addressierung, sowohl für Programmcode als auch für Daten. Relative Sprünge waren auf +/- 32 kByte begrenzt, sowie bei Datenaddressierung mit Baseregister und Offset war auch der Offset nur auf 16 Bit begrenzt. Das machte es schwierig Programme im Speicher beliebig zur Laufzeit rumzuschieben. Der 68010 (als auch der 68020) konnte dann mit einer externen MMU umgehen, der 68030 hatte sie dann eingebaut.
Abdul K. schrieb: > Man konnte bei den Relativsprüngen nur vorzeichenbehaftete 16-Bit > Offsets angeben. Will man Code-Segmente im Speicher verschieben, geht > sowas nur mit Relativsprüngen im Code. Nur wenn du aus "ging bloss" ein "so war es am einfachsten" machst. > Bei A.K. war bestimmt alles viel besser ;-) Besser als so ein Gefrickel jedenfalls schon. Bischen simples Dualport-Mem, ein paar Addierer und Komparatoren und fertig ist eine einfache segmentierte MMU, die für Code und Daten unabhängige Basisadressen und Limits vorgibt. Fast verzögerungsfrei, d.h. ohne Waitstate, und mit problemlos verfügbaren billigen Komponenten. Luxus war das nicht, kein Paging, aber Adressraumtrennung und OS-definiere Segmentbasisadressen waren damit möglich. Klar, mit 68010 funktioniert das besser, aber segmentiert mit je einem einzigen Segment für Code, Daten/Stack gibts ohnehin kein Paging oder partielles Swapping, also ist ein Wiederaufsetzen nach Bus-Error nicht zwingend.
Lattice User schrieb: > A. K. schrieb: >>> Eine 16bit Version des Prozessors ist ja auch am Markt gescheitert (IMO >>> zu recht). >> >> Arg krudes Teil. 2 Jahre nach dem Original hätte das Teil wohl Chancen >> gehabt, trotz der stumpfsinnigen Architektur. Aber zu dem Zeitpunkt wo >> das Ding rauskam wars nur noch ein Witz. > > Das wäre 1977 gewesen. Zu diesem Zeitpunkt wäre aber die > Binärkompatibilität zum 6502 kein absolutes Muss gewesen. Als er kam war > diese Kompatibilität seine einzige Hoffnung, d.h. für 16bit Versionen > der erfolgreichen AppleII und C64. Wobei nur ein AppleIII das Licht der > Welt erblickt hat, war aber viel zu spät, auch wegen der Inhouse > Konkurrenz. Ob Commodore je eine 16bit Version des C64 erwogen hat ist > mir nicht bekannt. > > Zum Vergleich: 8086 wurde 1978 vorgestellt, der 68000 1979. Der AppleIII hatte auch "nur" einen 6502, der aber mit 2MHz lief. Die 16bit Version war der AppleIIGS. Und das der gescheitert ist, kann man nicht sagen. Einen leider etwas unvollständigen Überblick finden man bei Wikipedia: http://de.wikipedia.org/wiki/Apple_IIgs Über die Zeit gab es drei Mainboad-Versionen (ROM 00, ROM 01 u. ROM3). Bei der Einstellung des Modells war eine komplett überarbeitete neue Version (ROM 04 - Codename "Mark Twain") kurz vor der Markteinführung. Die CPU wurde nur mit 2,8MHz getaktet. Es gab aber Beschleunigerkarten mit einer 7MHz CPU, die man später als es noch schnellere CPUs gab (14MHz) auch austauschen konnte.
Abdul K. schrieb: > Man konnte bei den Relativsprüngen nur vorzeichenbehaftete 16-Bit .... Ich habe lange zum posten bebraucht. Aber wie die schreibst war das eine Einschräunkung die sich Apple selbst auferlegt hatte. Beim Atari (das weiss ich sicher) als auch vermutlich beim Amiga gabe es diese Einschränkung nicht.
>Zum Zeitpunkt der PC-Entscheidung hatte IBM .. bewusst den schlechtesten, nicht den besten Prozessor ausgewählt. >Die Geschichte zu den Segmentregistern... gibt es nur weil Intel beim 4004 nicht an grössere Bereiche gedacht hatte (und schlecht von ner DEC abgeguggt hatte ; so extrem schlecht, dass nichtmal vernünftige Stack-adr. möglich war) > Für typische Embedd-Syst. wollte diese blöde x86-Architektur noch nie > jemand haben. Ein paar Ausnahmen gibt es. Aber mit 68k hat die Industrie (nicht PC-Indust.) gejubelt. Sehr viele Systeme sind damit gemacht worden (Stichwort Werkzeug u. CNC-Maschinen, VMEbus) Ja, beim Coldfire ist vieles vom 68k rausgeschmissen worden. Denke mal, dass das später wieder rein kommt(!) Denn RISC ist zwar neuer als CISC, aber es kommt auch immer mehr CISC wieder in RISC rein.
MCUA schrieb: >>Die Geschichte zu den Segmentregistern... > gibt es nur weil Intel beim 4004 nicht an grössere Bereiche gedacht > hatte Intel hat zwar viel auf dem Kerbholz, aber das ist mit Verlaub gesagt an den Haaren herbeigezogen.
MCUA schrieb: > Ja, beim Coldfire ist vieles vom 68k rausgeschmissen worden. > Denke mal, dass das später wieder rein kommt(!) Schon passiert. Die erste Generation war etwas zu radikal rasiert wurden. Aber was dann dazu kam war teils auch völlig neu. Das Hauptproblem der 68020-Erweiterung waren die extrem schlecht dekodierbaren und viel zu komplexen Adressierungsarten. Einzig die anno 68000/10 seltsamerweise fehlende Skalierung vom Index war sinnvoll, der gesamte Rest überflüssig bis schädlich.
A. K. schrieb: > Einzig die anno > 68000/10 seltsamerweise fehlende Skalierung vom Index war sinnvoll Adressregister indirekt mit 32bit Displacement ist doch auch sinnvoll. Ist doch das was Abdul beim 68000 so schmerzlich vermisst hat. Das ganze Memoryindirekt geraffel war aber dann doch zu Arg auf den Mainframe geschielt.
Lattice User schrieb: > Abdul K. schrieb: > Das ist nicht richtig, der 68000 hatte eine 32 bit lineare > Addressierung, sowohl für Programmcode als auch für Daten. > Relative Sprünge waren auf +/- 32 kByte begrenzt, sowie bei > Datenaddressierung mit Baseregister und Offset war auch der Offset nur > auf 16 Bit begrenzt. Das machte es schwierig Programme im Speicher > beliebig zur Laufzeit rumzuschieben. > Der 68010 (als auch der 68020) konnte dann mit einer externen MMU > umgehen, der 68030 hatte sie dann eingebaut. Ja, schrieb ich doch.
So lese und höhre ich euch zu, wie ihr schwelgt in tiefer Trauer. Die CPU´s heute werden kleiner und auch schlauer. Eines Tages wenn wir gehn werden 6502 vertikal als Grabstein stehn. Klaus
Klaus De lisson schrieb: > Die CPU´s heute werden kleiner und auch schlauer. Das mit dem schlauer wage ich zu bezweifeln. Die nehmen einen immer noch wörtlich und machen nie das was man wirklich will ;)
Lattice User schrieb: > Adressregister indirekt mit 32bit Displacement ist doch auch sinnvoll. > Ist doch das was Abdul beim 68000 so schmerzlich vermisst hat. Vermisst, weil keine MMU. Ein Compiler kommt ganz gut ohne aus. Das selbst wäre aber nicht das Problem gewesen - die Codierung war es. Das Problem liegt darin, dass zwar in der 68000 aus dem ersten Codewort die Gesamtlänge des Befehls ableitbar war, nicht aber in der 68020, da die Länge des Adressteils eines Operanden nicht mehr nur vom Codewort sondern vom Inhalt des Adressteils selbst abhing. Noch schlimmer war das bei zwei solchen Adressen im MOVE-Befehl. Denn dann konnte die Position des zweiten Adressfelds erst bestimmt werden, wenn die Länge des ersten Adressfelds ermittelt war. Und erst nach der Dekodierung des zweiten Adressfelds wusste man, wie lang der Befehl insgesamt überhaupt war. Und nun versuch bei sowas mal 2-3 Befehle pro Takt zu dekodieren. Prost Mahlzeit. IMHO hats schon bei 68040 spätestens aber mit 68060 die Empfehlung gegeben, diesen Kokolores nicht zu nutzen, weil schneller ohne. > Das ganze Memoryindirekt geraffel war aber dann doch zu Arg auf den > Mainframe geschielt. Und völlig für die Katz. Zeit spart es jedenfalls keine, nur bischen Register und Platz. Dafür ist aber ein vollständiger Retry von Befehlen mit Pagefault aufgrund der diversen möglichen Überlappungen von Operanden kaum durchführbar. Daher auch die in der gesamten übrigen Prozessorwelt unübliche und sehr zeitraubende Methode des Mikrocode-Interrupts. Der Ablauf solcher Befehle bringt ausserdem jene Pipeline zur Verzweiflung. In heutigen Implementierungen von Intel und AMD wäre das kein wesentliches Problem mehr. Aber damals war aufgrund von Pipeline-Effekten der Ersatzcode aus mehreren Befehlen deutlich schneller, weil man unbhängigen Code dazwischen einstreuen kann.
>Die CPU´s heute werden kleiner und auch schlauer.
Schlauer? Manche werden dümmer! Nur schneller werden sie alle.
Lattice User schrieb: > Das ganze Memoryindirekt geraffel war aber dann doch zu Arg auf den > Mainframe geschielt. Nicht auf Mainframe, die IBMs sind vergleichsweise simpel gestrickt. Das Vorbild war die DEC VAX, nachdem ja die 68000 unübersehbar von der DEC PDP-11 inspiriert war. Die VAX kriegte aber kurz drauf selbst genau das beschriebene Problem und brach DEC fast den Hals.
MCUA schrieb: > Schlauer? Manche werden dümmer! Nur schneller werden sie alle. Nö, manche werden langsamer. Grad in jüngster Zeit. Intels Schritt zum Atom beispielsweise, aber auch AMDs Brazos. Selbst AMDs Bulldozer wird als eher ein Tick langsamer pro Core vermutet.
A. K. schrieb: > Dafür ist aber ein vollständiger Retry von Befehlen > mit Pagefault aufgrund der diversen möglichen Überlappungen von > Operanden kaum durchführbar. Daher auch die in der gesamten übrigen > Prozessorwelt unübliche und sehr zeitraubende Methode des > Mikrocode-Interrupts. Bist du sicher dass nicht schon der 68010 Microcode Interrupts hatte? Bei einer 2 Address Architektur liegt das Nahe um Mehrdeutigkeiten beim Retry zu vermeiden, z.B. weil man im ersten und im zweitem Operanden das gleiche Register mit Postincrement benutzt. Da mir das 68010 Usermanual in meiner Sammlung fehlt kann ich das nicht überprüfen. Apropos Microcode Interrupts. Auf manchen Mainframes wurde bei Memoryindirekt nicht nur die Addresse nachgeladen sondern auch die Addressmodifier. (Z.B. Univac 110x) Damit kann man eine schöne Endlosschleife im Microcode erzeugen, und wenn dieser nicht Interruptable ist steht die Maschine. Und wenn der Frontpanel Reset Button auch vom Microcode abgefragt wurde, ouch. Hatte ich gerüchterweise damals von Telefunkenmainframes gehöhrt.
Es gab einige ominöse Bit-Felder beim Interrupt-Frame auf dem Stack. Die waren im Handbuch nicht weiter ausgeführt. Ich befürchte, du hast Recht.
Lattice User schrieb: > Bist du sicher dass nicht schon der 68010 Microcode Interrupts hatte? Hatte er. Wenn man den 68010 komplett neu designed hätte, dann wäre es evtl. auch ohne Mikrocode-Interrupt gegangen. Hatte man aber nicht. NatSemi hatte das bei der 32000 mit Retry gemacht. Hat die Befehle um eine Latte von Einschränkungen bereichert - und die Chips um ein paar nette Bugs. > Bei einer 2 Address Architektur liegt das Nahe um Mehrdeutigkeiten beim > Retry zu vermeiden, z.B. weil man im ersten und im zweitem Operanden das > gleiche Register mit Postincrement benutzt. Sowas kann man mit Schattenregistern abwickeln. > Apropos Microcode Interrupts. Auf manchen Mainframes wurde bei > Memoryindirekt nicht nur die Addresse nachgeladen sondern auch die > Addressmodifier. Nicht bloss die. Auch ein paar kleinere Kisten mit speicherindirekter Adressierung und Indirektionsbit in der Adresse. PDP-8 beispielsweise.
A. K. schrieb: > Nicht auf Mainframe, die IBMs sind vergleichsweise simpel gestrickt. Das > Vorbild war die DEC VAX, nachdem ja die 68000 unübersehbar von der DEC > PDP-11 inspiriert war. Die VAX kriegte aber kurz drauf selbst genau das > beschriebene Problem und brach DEC fast den Hals. Mit den IBMs kenne ich mich nicht aus, aber es gab noch andere, die hatten definitiv Memoryinderikte Addressierung, z.B. Univac 1106 (mein erster). Die VAX ist natürlich CISC schlechthin, man müsste dafür den Begriff VCISC einführen. Aber ich hatte bei ihrer Einführung nicht den Eindruck dass DEC Probleme hatte. Bis diese zum Klotz am Bein wurde hatte sie sich doch 15 Jahre gut verkauft.
Lattice User schrieb: > VCISC einführen. Aber ich hatte bei ihrer Einführung nicht den Eindruck > dass DEC Probleme hatte. Bis diese zum Klotz am Bein wurde hatte sie > sich doch 15 Jahre gut verkauft. Eben, das meinte ich doch. Wie bei der 68000 Familie, Anfangs kann man sich komplexe Befehle mit hochgradig sequentieller Dekodierung und Ausführung leisten. Spart Platz und der ist Geld wert. Irgendwann ist dann aber Schluss mit innerem Gänsemarsch und du willst einen Befehl pro Takt, oder noch mehr. Und dann wirds bös. Das ist eigentlich der Zeitpunkt, sich Neues auszudenken. Wenn man kann und darf. Auch Intel hat schon dreimal versucht, sich vom Fluch der 8080/x86-Histore zu befreien. Der erste Versuch (432) war ein schnarchlangsames Komplexitätsmonster der Extraklasse und scheiterte deshalb schon im Ansatz. Der zweite (860) war ein recht schräger RISC und interessierte nur ein paar Spezialisten. Der dritte (IA64) verhungert grad dank AMDs 64-Bit Intervention.
A. K. schrieb: > Eben, das meinte ich doch. Verstanden, aber so gesehen hat das DEC das Genick gebrochen. Gibt es schliesslich nicht mehr. > Wie bei der 68000 Familie, Anfangs kann man > sich komplexe Befehle mit hochgradig sequentieller Dekodierung und > Ausführung leisten. Spart Platz und der ist Geld wert. Irgendwann ist > dann aber Schluss mit innerem Gänsemarsch und du willst einen Befehl pro > Takt, oder noch mehr. Da hast du natürlich vollkommen recht. Intel hat für dieses Problem allerdings eine Lösung gefunden, Zerlegung des CISC Befehls in mehrere RISC Befehle die dann in die Pipeline geschoben werden. Allerdings ist der 80x86 relativ einfach im Vergleich zur VAX. Intel hatte allerdings mehr Zeit eine Lösung zu finden, denen stand keine erfolgreiche Konkurrenz im gleichen Markt mit RISC Prozessoren im Nacken.
Lattice User schrieb: > Verstanden, aber so gesehen hat das DEC das Genick gebrochen. Gibt es > schliesslich nicht mehr. Letzten Endes ja. Da ging zu viel Geld den Bach runter. Aber sie hatten es danach noch viele Jahre geschafft, mit Alpha. > Intel hat für dieses Problem allerdings eine Lösung gefunden, Zerlegung > des CISC Befehls in mehrere RISC Befehle die dann in die Pipeline > geschoben werden. Genau das meinte ich ja mit dem oben erwähnten Pentium Pro. Strukturelle Ähnlichkeit dazu lässt sich bis heute in den Intel Prozessoren finden, ausgenommen Atom und die Abirrung Pentium 4. Einzig war Intel damit allerdings nicht. AMD hatte um den Dreh herum den K5 und der Designzwerg Nexgen kam damit sogar als Erster raus. Intels Produkt war allerdings eine Klasse besser (und teurer).
A. K. schrieb: > Auch Intel hat schon dreimal versucht, sich vom Fluch der > 8080/x86-Histore zu befreien. Der erste Versuch (432) war ein > schnarchlangsames Komplexitätsmonster der Extraklasse und scheiterte > deshalb schon im Ansatz. Gab es den 432 überhaupt? Ich denke nicht dass Intel zu diesem Zeitpunkt den x86 bereits als Fluch betrachtet hat. Der 432 war einfach die nächste geplante Generation. Ich hatte ein Usermanual, war nicht viel dünner als das VAX Prozessorhandbuch. > Der zweite (860) war ein recht schräger RISC > und interessierte nur ein paar Spezialisten. Der dritte (IA64) > verhungert grad dank AMDs 64-Bit Intervention. Der IA64 ist dabei noch nicht mal Intels eigenes Gewächs sondern wurde von HP übernommen (und natürlich etwas weiterentwickelt). Mit der AMD64 aka Intel x64 habe ich mich ehrlich gesagt noch nicht auseinader gesetzt, das einzige was ich mir mal angesehen habe ist die Registerarchtektur und das sieht schön symmetrisch aus. Ist der AMD x64 jetzt CISC oder RISC?
Lattice User schrieb: > Gab es den 432 überhaupt? Gute Frage. Ich glaube den gab es wirklich. Aber nicht in Systemen, eher im Prototypenstadium. > Ich denke nicht dass Intel zu diesem Zeitpunkt den x86 bereits als Fluch > betrachtet hat. Nein. Der 432 war als eigentliche nächste Generation nach 8080 vorgesehen, mit 8086 als Interimslösung - und 286 als Rettungsboot. > Der IA64 ist dabei noch nicht mal Intels eigenes Gewächs sondern wurde > von HP übernommen (und natürlich etwas weiterentwickelt). Wer da nun genau was einbrachte weiss ich nicht, aber zur "Blüte" entwickelt wurde er letztlich von beiden zusammen. > Ist der AMD x64 jetzt CISC oder RISC? Wie x86, aber mit 64-Bit Registern und doppelter Anzahl, d.h. 16 statt 8. Plus ein paar Kleinigkeiten wie PC-relativer Datenadressierung.
He Leute, was geht den hier ab? hab hier noch 1x UM6502 uns 2x UM6522 rumliegen! bin ich jetz reich oder was? Was soll ich mit dem Zeugs anfangen? mfg Manfred
Manfred John schrieb: > Was soll ich mit dem Zeugs anfangen? Darfs eine ehrliche Antwort sein? Tonne auf, rein, Tonne zu.
A. K. schrieb: >> Ist der AMD x64 jetzt CISC oder RISC? > > Wie x86, aber mit 64-Bit Registern in doppelter Anzahl, d.h. 16 statt 8. Soweit ich das verstanden habe, sind diese Register nicht mehr an spezielle Funktionen gebunden, z.B. wie (e)cx als Zähler bei den "rep move" Befehlen in der x86 Variante. Aber genug von Intels Verirrungen :-) Zurück zu den 8 Bittern. Wie ist eure Meinung welches der erfolgreichste 8 Bitter ist (einschliesslich Embedded)? Meine Rangliste: Platz 1: 8051 (und Varianten) Platz 2: 8048 (und Varianten) Platz 3 und folgende, keine Meinung.
Lattice User schrieb: > Soweit ich das verstanden habe, sind diese Register nicht mehr an > spezielle Funktionen gebunden, z.B. wie (e)cx als Zähler bei den "rep > move" Befehlen in der x86 Variante. Daran hat sich nichts geändert. Das sind ja ohnehin Spezialbefehle, die allgemeinen Befehle sind schon seit jeher fast alle auf alle Register anwendbar. Shift-Count ist immer noch in CL. Es ist auch die gleiche Codierung. Mit optionalem Präfix-Byte für 3 obere Bits der Registernummern, und 1 Bit für 64-Bit Operationen. Gestrichen wurden eben dafür die INC/DEC Opcodes auf Register.
A. K. schrieb: > > allgemeinen Befehle sind schon seit jeher fast alle auf alle Register > anwendbar. Nicht wirklich, z.B. mul/div will einen Operanten immer in (e)ax und lieferte das Ergebniss immer in (e)ax und (e)dx ab. Beim 68000/PDP 11/VAX gab da keine Einschränkung, und ich wage zu behaupen auch bei keinen der RISCs.
Hey, das Posting zu ändern während ich antworte ist unfair :-) A. K. schrieb: > Es ist auch die gleiche Codierung. Mit optionalem Präfix-Byte für 3 > obere Bits der Registernummern, und 1 Bit für 64-Bit Operationen. > Gestrichen wurden eben dafür die INC/DEC Opcodes auf Register. Präfix byte mit 3 bit Registernummerergänzung stellt natürlich die Registersymmentrie her.
Lattice User schrieb: > Nicht wirklich, z.B. mul/div will einen Operanten immer in (e)ax und > lieferte das Ergebniss immer in (e)ax und (e)dx ab. Deshalb ja "fast". Aber Multiplikation mit einfach genauem Ergebnis gab es schon vorher ohne Kopplung an AX/DX. Anfangs nur mit Konstante, später dann auch r mit r/m. > und ich wage zu behaupen auch bei keinen der RISCs. IBMs Power hatte ursprünglich ein MQ-Register für diverse Operationen wie Multiplikation, Division und 64-Bit Shift/Mask-Ops. Ist keine gute Idee wenn man das Pipelinen will, weshalb das mit PowerPC einkassiert wurde.
Lattice User schrieb: > Präfix byte mit 3 bit Registernummerergänzung stellt natürlich die > Registersymmentrie her. Nein. Das sind die 3 Bits, die für die 3 maximal im Befehl codierbaren Register fällig werden, wenn man davon 16 statt 8 hat, also die jeweils obersten Bits. Weshalb 8/6/32-Bit Befehle mit ausschliessich den alten Registern keinen Präfix brauchen. Was vorher unsymmetrisch war ist es hinterher auch noch. Ach ja: Eine Symmetrie kam doch hinzu. Mit (ggf leerem) Präfix sind alle 16 Register in Byte-Operationen nutzbar.
A. K. schrieb: > Lattice User schrieb: > >> Präfix byte mit 3 bit Registernummerergänzung stellt natürlich die >> Registersymmentrie her. > > Nein. Das sind die 3 Bits, die für die 3 maximal im Befehl codierbaren > Register fällig werden, wenn man davon 16 statt 8 hat, also die jeweils > obersten Bits. Weshalb 8/6/32-Bit Befehle mit ausschliessich den alten > Registern keinen Präfix brauchen. Ok, danke. Wieder etwas schlauer ;-)
Lattice User schrieb: > Zurück zu den 8 Bittern. > Wie ist eure Meinung welches der erfolgreichste 8 Bitter ist > (einschliesslich Embedded)? > > Meine Rangliste: > Platz 1: 8051 (und Varianten) > Platz 2: 8048 (und Varianten) > Platz 3 und folgende, keine Meinung. Wenn man sich auf Controller bezieht, die 4-Bitter wegläßt, ebenso die Japaner, dann ja.
Abdul K. schrieb: > Lattice User schrieb: >> Zurück zu den 8 Bittern. >> Wie ist eure Meinung welches der erfolgreichste 8 Bitter ist >> (einschliesslich Embedded)? >> >> Meine Rangliste: >> Platz 1: 8051 (und Varianten) >> Platz 2: 8048 (und Varianten) >> Platz 3 und folgende, keine Meinung. > > Wenn man sich auf Controller bezieht, die 4-Bitter wegläßt, ebenso die > Japaner, dann ja. 4 bitter hatte ich nicht eingeschlossen. Bei den 8 bittern meine ich schon alle, also Controller, reguläre CPUs allerdings echte 8 bitter wie 8080, 6502, Z80 etc. 8088/68008 gehören nicht dazu. Dazu zählen auch IP Versionen in ASICs/FPGAs. Du bist also der Meinung bist einem Japaner (z.B. NEC µPD78xx) gehöhrt nach diesen Kriterien der Spitzenplatz?
Manfred John schrieb > hab hier noch 1x UM6502 > uns 2x UM6522 > rumliegen! > bin ich jetz reich oder was? > Was soll ich mit dem Zeugs anfangen? Z.B. ins Ebay stellen oder an ein Museum oder Etwas hübsches bauen wie z.B. Eine Dcf77 Uhr und vielleicht noch dafür den RIOT IC 6532 zulegen. p.s.: Elektor hatte da mal so Projekte. (Juniorcomputer,etc...)
Lattice User schrieb: > Bei den 8 bittern meine ich schon alle, also Controller, Guten Morgen, obwohl Ihr wohl noch schlaft. Wenn ich mich richtig erinnere, haben/hatten die 68HC08/68HC11 den größten Marktanteil. Die fehlen ganz in der Auflistung.
Gn Morgen auch, klar vorne liegt die 8051 Familie bei der Zahl der Hersteller, hier aus der Keil-Seite: http://www.keil.com/c51/chips.asp Praktisch jede Fab. hat so ein Teil im Angebot.
Ja, der i432 sollte als Nachfolger von 8080/8085 gelten (Intel hatte da schon die Haken v. 8080/8085 erkannt), aber der i432 hinkte dem Zeitplan hinterher. Und weil Motorola mit ihren CPUs mächtig Konkurenz gemacht hatte (oder auch weil der i432 nicht kompat. war?), hat Intel dann auch am 8086 gearbeitet. Später mal hat Intel (mit AD zusammen) beim Blackfin aber keinen Fehlgriff gemacht, und hat Teile der Register-Archit. vom 68k abgeguggt. > ... der erfolgreichste 8 Bitter .... ist schwer zu definieren, da man das Wort 'erfolgreich' schwer definieren kann. Handhabung? Preis? Stückzahl-ingesamt? Projekt-Anzahl? Entwickler-Ärgernisse? Laufzeit über Jahre gesehen? Sec.Sources?
Jens Petersen schrieb: > Wenn ich mich richtig erinnere, haben/hatten die 68HC08/68HC11 den > größten Marktanteil. Die fehlen ganz in der Auflistung. Das wundert mich jetzt etwas, daß diese Familie den größten Marktanteil gehabt haben soll. Denn, ein 68HC11 befindet sich bei mir nur in einem einzigen Gerät, dem EPROMMER. Vor Jahren schlachtete ich noch viele Altgeräte vom Schrott, und dort begegnete mir mindestens um den Faktor 10 öfter der 8051. Klar ist die Auswahl der Schlachtgeräte nicht ganz repräsentativ, aber man bekommt einen kleinen Eindruck. Der 8051 ist ganz nett, und es gibt sicher Gründe, warum er bis heute überlebte, und noch lange nicht ausstirbt. Etwas stören tut gelegentlich mal der kleine Hardwarestack, wenn man nicht sorgfältig programmiert. Das ist eben einer der Unterschiede zwischen µC und µP, da waren die µP überlegen. In Assembler ist z.B. meine DCF77-Uhr programmiert, hat nur etwa 3-4kByte Code. Aber der Stack hat schon eine Tiefe von 64 Byte, wobei er sich diese mit dem internen RAM der Größe 128 Byte teilt, und dort auch noch die Registerbänke mit drin liegen. Da muß man also etwas aufpassen und sorgfältig arbeiten. Zum Test installierte ich zusätzlich zur manuellen Berechnung und Simulation noch einen Stack-Check-Code, den ich dann später wieder entfernte. Mittlerweile wurde er ja auch an vielen Stellen verbessert, den Core gibt es mit 2 anstatt 12 Clockzyklen, und SiLabs hat Typen mit Taktfrequenzen um 100MHz. Damit eignen sie sich besonders gut für Hochsprachen. Flash wurde ins Innere verfrachtet, leistungsfähige On-Chip-Peripherie gibt es auch. Der 8048 hatte ja eigentlich nur ein kurzes Leben ab 1976, bis er 1980 vom 8051 abgelöst wurde. Immerhin war es aber der erste 8-bit-µC, und leben tut der heute auch noch. Große Dinge kann man dank 4k Speichergröße damit auch nicht bewegen, aber z.B. mal eine PC-Tastatur scannen und über Soft-UART mit dem PC kommunizieren. Etwa 1980 installierte ich bei Kunden die damals neue FTA (Familientelefonanlage), und das Ding war recht störungsanfällig. Dort war auch ein 8048 drin, aber als 8035 mit externem EPROM. Das war sicher auch gut so, denn der Service konnte so leicht die Software auswechseln. In der Anfangszeit mußten die Anlagen nach der Installation beim Kunden noch bis zu drei mal ausgewechselt werden, und Software-Bugs gab es auch reichlich. Der µC lief aber nach Inbetriebnahme ununterbrochen durch, bis die Anlage irgendwann mal aus Altersgründen ausgewechselt wird.
Kann man den 6510 der in den C64 verbaut war auch als normalen 6502 benuten? Sind die soweit compentibel?
Prozessorsammler schrieb: > Kann man den 6510 der in den C64 verbaut war auch als normalen 6502 > benuten? > Sind die soweit compentibel? Jein. Auf den Adressen 0 und 1 liegt der I/O Port und durch den sind die auch nicht Pinkompatibel. Die Befehe sind soweit gleich.
>> Wenn ich mich richtig erinnere, haben/hatten die 68HC08/68HC11 den >> größten Marktanteil. Die fehlen ganz in der Auflistung. >Das wundert mich jetzt etwas... Die 68HC05/08/68HC11 (auch ST6,7) waren/sind in der AutomobilBranche schwer vertreten.
MCUA schrieb: > Die 68HC05/08/68HC11 (auch ST6,7) waren/sind in der AutomobilBranche > schwer vertreten. Dort waren/sind auch die 8051 stark vertreten.
Den 68HC11 gab es wohl auch im PLCC68-Gehäuse, wie den 80C515. Ich kenne den 68HC11 im Detail nicht, befürchte aber, daß die Unterschiede nicht wirklich allzu groß sind.
Wilhelm Ferkes schrieb: > Vor Jahren schlachtete ich noch viele Altgeräte vom Schrott, und dort > begegnete mir mindestens um den Faktor 10 öfter der 8051. Klar ist die > Auswahl der Schlachtgeräte nicht ganz repräsentativ, aber man bekommt > einen kleinen Eindruck. > Den Eindruck hatte ich auch. Neben den Japanern eben. Neuerdings Chinesen und Korea. > Der 8051 ist ganz nett, und es gibt sicher Gründe, warum er bis heute > überlebte, und noch lange nicht ausstirbt. > Ebend. Cypress hat ihn gerade wieder in eine neue Linie eingebaut. > Etwas stören tut gelegentlich mal der kleine Hardwarestack, wenn man > nicht sorgfältig programmiert. Das ist eben einer der Unterschiede > zwischen µC und µP, da waren die µP überlegen. In Assembler ist z.B. > meine DCF77-Uhr programmiert, hat nur etwa 3-4kByte Code. Aber der Stack > hat schon eine Tiefe von 64 Byte, wobei er sich diese mit dem internen > RAM der Größe 128 Byte teilt, und dort auch noch die Registerbänke mit > drin liegen. Da muß man also etwas aufpassen und sorgfältig arbeiten. > Zum Test installierte ich zusätzlich zur manuellen Berechnung und > Simulation noch einen Stack-Check-Code, den ich dann später wieder > entfernte. > Du bist doch fit! Der Keil-Assembler legt dir allerdings die Objekte alle schön selbständig ab! Da muß man solange man nicht Pointer benutzt, keinerlei Arbeit reinstecken. Auch das Overlay funzt super. Gibt es Assembler, die das nicht können? > scannen und über Soft-UART mit dem PC kommunizieren. Etwa 1980 > installierte ich bei Kunden die damals neue FTA (Familientelefonanlage), > und das Ding war recht störungsanfällig. Dort war auch ein 8048 drin, > aber als 8035 mit externem EPROM. Das war sicher auch gut so, denn der > Service konnte so leicht die Software auswechseln. In der Anfangszeit > mußten die Anlagen nach der Installation beim Kunden noch bis zu drei > mal ausgewechselt werden, und Software-Bugs gab es auch reichlich. Der > µC lief aber nach Inbetriebnahme ununterbrochen durch, bis die Anlage > irgendwann mal aus Altersgründen ausgewechselt wird. Damals konnte man selbst so noch Gewinn machen :-)
>Den 68HC11 gab es wohl auch im PLCC68-Gehäuse, wie den 80C515. Ich kenne >den 68HC11 im Detail nicht, befürchte aber, daß die Unterschiede nicht >wirklich allzu groß sind. Hä? total anders.
Er meinte wohl, den HC11 gäbe es in verschiedenen Gehäusevarianten, eben auch in PLCC68 so wie den 515. Den 515 gibts aber NUR in diesem Gehäuse. Ich finde den 8051 recht gelungen: Bit-Befehle, genialer I/O. Er war nie für große Programme gedacht! Man muß auch immer den Compiler dazusehen. Und da ist man beim 8051 mit dem Keil eindeutig im Vorteil. Die Software ist ausgereift und hochoptimierend. Nacharbeit im erzeugten Code lohnt nicht.
Wilhelm Ferkes schrieb: > Den 68HC11 gab es wohl auch im PLCC68-Gehäuse, wie den 80C515. Ich kenne > den 68HC11 im Detail nicht, befürchte aber, daß die Unterschiede nicht > wirklich allzu groß sind. Das sehe ich aber anders. Zum Einen ist der HC11 um einiges schneller unterwegs, da er intern durch 4 teilt und nicht durch 12. Dann hat er nicht diese fiese Stack-Einschränkung, von Neumann, kann 16 Bit dividieren, hat Unterstützung für Zahlen mit Vorzeichen, usw. Ich habe übrigens früher immer gern die OTP-Variante (im Speziellen den 711E9 mit 12 k OTPROM und 512 Bytes RAM und 512 Bytes EEPROM) verwendet, weil der Bestückungs-Aufwand so schön gering war. Während der Entwicklung habe ich natürlich externes RAM angeschlossen. Aber dank des HC24 hat das fast keine PINs gekostet, nur der UART ging für den Monitor flöten. Auch nett war das eingebaute Boot-ROM. Man brauchte also nicht noch irgendein EPROM für den Monitor zu verbauen. Aber jetzt, wo es 8051 mit FLASH als Single-Clocker und eingebauter Debug-Peripherie gibt, verwende ich sie auch. Die Stack-Limitierung nervt zwar ganz gewaltig und ab und an will ich einfach mein N-Flag wieder haben, aber irgendwie geht es dann doch. :-)
Der Stack kann z.B. bei Keil extern auf 16-Bit umkonfiguriert werden. Alles was du dazu brauchst, macht der C-Compiler automatisch. Ist schon genial. Banking übrigens genauso. VonNeumann ist beim 8051 bei externem Speicher immer möglich! Kostet nur ein Gatter. DAS solltest du als Benutzer aber schon wissen, oder?! Wie gesagt, das ist kein Prozessor!
Der 8051 ist extrem beliebt bei ASIC Hersteller wenn es darum geht einen Microcontroller mit zu integrieren. Alles modernere wie Pic etc krankt an den Lizenskosten. Und auch bei weniger versteckten Teilen steht aussen auf dem Chip keineswegs immer 8051 drauf, z.B. die CY7C6801x USB Controller (FX2) von Cypress. Sehr verbreitet. Zum 8048: Der ist keinesweg schon 1980 verstorben, da darf man nicht übershen dass praktisch jeder PC mit 2 davon kommt, einen in der Tastatur und einen am anderen Ende des Tastaturkabels (ursprünglich in der 8041 Variante). Heute ist dieser natürlich im Chipsatz integriert aber nach wie vor existent. Abdul K. schrieb: > Wilhelm Ferkes schrieb: >> Vor Jahren schlachtete ich noch viele Altgeräte vom Schrott, und dort >> begegnete mir mindestens um den Faktor 10 öfter der 8051. Klar ist die >> Auswahl der Schlachtgeräte nicht ganz repräsentativ, aber man bekommt >> einen kleinen Eindruck. >> > > Den Eindruck hatte ich auch. Neben den Japanern eben. Neuerdings > Chinesen und Korea. Die Japaner kann ich schwer einschätzen, der µPD78xx war auf jedem Fall bei Nadeldruckern sehr verbreitet. (Da hatte ich mal einen reverse engineered, samt selbst geschriebenen Disassembler umd Assembler) Bei Chinesen und Koreanern ist erst mal zu klären ob das wirklich eine eigene Architektur ist. Abdul K. schrieb: >> Der 8051 ist ganz nett, und es gibt sicher Gründe, warum er bis heute >> überlebte, und noch lange nicht ausstirbt. >> > > Ebend. Cypress hat ihn gerade wieder in eine neue Linie eingebaut. Bist du sicher? Der FX3 (für USB 3) wird meines Wissens auf ARM basieren, die hausinterne Konkurrenz PSOC5 ist definitiv ARM. Wilhelm Ferkes schrieb: > Etwas stören tut gelegentlich mal der kleine Hardwarestack, wenn man > nicht sorgfältig programmiert. Das ist eben einer der Unterschiede > zwischen µC und µP, da waren die µP überlegen Um da wieder den Bogen zum 6502 zu schliessen, der ist da auch nicht viel besser. Von 0x00-0xFF mit 1 byte addressierbarer RAM, Stack fest auf 0x100-0x1FF. Stackpointer wurde so initialisert dass man in µC Anwendungen beide Bereiche überlappen lassen konnte, also genau wie beim 8081.
Abdul K. schrieb: > VonNeumann ist beim 8051 bei externem Speicher immer möglich! Kostet nur > ein Gatter. DAS solltest du als Benutzer aber schon wissen, oder?! Ich habe in meinen fertigen HC11 Systemen keinen externen Speicher, das ist ja gerade das Schöne! Externen Speicher habe ich nur beim Debuggen gebraucht.
Lattice User schrieb: > Anwendungen beide Bereiche überlappen lassen konnte, also genau wie beim > 8081. Soll heissen: genau wie beim 8051
A. K. schrieb: > NatSemi hatte das bei der 32000 mit Retry gemacht. Hat die Befehle um > eine Latte von Einschränkungen bereichert - und die Chips um ein paar > nette Bugs. > >> Bei einer 2 Address Architektur liegt das Nahe um Mehrdeutigkeiten beim >> Retry zu vermeiden, z.B. weil man im ersten und im zweitem Operanden das >> gleiche Register mit Postincrement benutzt. > > Sowas kann man mit Schattenregistern abwickeln. Wenn der erste Zugriff auf eine Peripherie Addresse geht ist Retry auch gefährlich. 2 oder noch mehr Addressbefehle sind aus heutiger Sicht keine gute Idee gewesen.
Moppel schrieb: > Abdul K. schrieb: >> VonNeumann ist beim 8051 bei externem Speicher immer möglich! Kostet nur >> ein Gatter. DAS solltest du als Benutzer aber schon wissen, oder?! > > Ich habe in meinen fertigen HC11 Systemen keinen externen Speicher, das > ist ja gerade das Schöne! Externen Speicher habe ich nur beim Debuggen > gebraucht. Worauf willst du denn hinaus? Klingt für mich nach Motorola-Fan und Intel-Hasser. Und die umgekehrte Variante kenne ich auch zu Genüge. Ich finde das lächerlich. Der 8051 ist extrem simpel intern aufgebaut. Harvard-Architektur macht die Sache schön einfach. Es gibt genug Alternativen, wenn man was anderes haben will. Der PSoC3 hat 8051, der PSoC5 ARM.
Abdul K. schrieb: > Der PSoC3 hat 8051, der PSoC5 ARM. Den PSoC3 hatte ich übersehen. Ich fürchte aber dass dieser zwischen PSoC(1) und PSoC5 nur ein Schattendasein führen. <Glaskugel> Der ARM wird in solchen Anwendungen auf lange Sicht den 8051 ablösen. </Glaskugel>
Lattice User schrieb: > Der ARM wird in solchen Anwendungen auf lange Sicht den 8051 ablösen. Dafür braucht man keine Glaskugel. Es ist neben dem MIPS Core die einzige 32-Bit Controller-Architektur, die man kaufen kann, ohne von einem Konkurrenten zu kaufen.
Glaube ich nicht für die nächsten 10 Jahre. Der ARM ist vielen zu umständlich. Mich stört z.B. das man nicht ein einfach vorhersagbare Laufzeitverhalten hat. Beim 8051 kann man die Zyklen einfach auszählen. Für mich ist aber der Compiler und der I/O interessanter. Leider gibts es nur noch C als Sprache. Man muß ja die Libs benutzen können. Das ist das Schlimmste. Persönlich hätte ich mir den AVR im PSoC gewünscht.
Abdul K. schrieb: > Glaube ich nicht für die nächsten 10 Jahre. Der ARM ist vielen zu > umständlich. Ist die Frage wie er es gemeint hat. ARM wird nicht direkt die 8-Bit Controller im Produktionsvolumen ablösen, aber ARM ist im 32-Bit Controller-Sektor das, was 8051 im 8-Bit Sektor ist. Sehr viele jener, die überhaupt in dem Sektor tätig sind, haben ihn bereits irgendwie im Angebot, oder werden es über kurz oder lang. Und die Dinger drücken nach unten. Der Sektor komplexerer 8-Bit Controller mit grossem Programm gerät ja schon unter Druck. Wer da nicht schon auf viel Erfahrung und Code sitzt, sondern es sich aussuchen kann, der wird immer mehr zu ARMs tendieren, statt sich mit Fiesmatentchen wie etlichen Adressräumen und zueinander inkompatiblen Pointern rumärgern zu müssen.
Wilhelm Ferkes schrieb: > Das wundert mich jetzt etwas, daß diese Familie den größten Marktanteil > gehabt haben soll. Denn, ein 68HC11 befindet sich bei mir nur in einem > einzigen Gerät, dem EPROMMER. In der ELEKTRONIK waren ab und zu 'Marktanalysen' abgedruckt, welche Prozessoren in welchen Segmenten stückzahlmäßig dominieren. Da lagen die 68HCxx immer deutlich vorne. Ich habe sie auch nie eingesetzt, aber das heißt doch nichts. Was im KFZ-Bereich abgeht, bekommt man in der Regel garnicht mit. Beispielsweise wurde der LIN-Bus von einigen Fahrzeugherstellern und Motorola als einzigem µP-Hersteller entwickelt (1999). Das zeigt wie dominierend Motorola/Freescale in dem Bereich ist. Ähnlich ist es mit Renesas (ex. Hitachi) SHx; die verwendet niemand privat. Aber im KFZ-Bereich sieht es ganz anders aus.
Abdul K. schrieb: > Glaube ich nicht für die nächsten 10 Jahre. Der ARM ist vielen zu > umständlich. Mich stört z.B. das man nicht ein einfach vorhersagbare > Laufzeitverhalten hat. Beim 8051 kann man die Zyklen einfach auszählen. Und diese Zyklen muss man auch viel zu oft zählen weil man das Ding am Rande der Leistungsfähigkeit benutzt. Been there, done that. > > Für mich ist aber der Compiler und der I/O interessanter. Leider gibts > es nur noch C als Sprache. Man muß ja die Libs benutzen können. Das ist > das Schlimmste. > Persönlich hätte ich mir den AVR im PSoC gewünscht. Den hätte man aber einem direkten Konkurrenten kaufen müssen. A. K. schrieb: > Abdul K. schrieb: > >> Glaube ich nicht für die nächsten 10 Jahre. Der ARM ist vielen zu >> umständlich. > > Ist die Frage wie er es gemeint hat. ARM wird nicht direkt die 8-Bit > Controller ablösen, aber ARM ist im 32-Bit Controller-Sektor das, was > 8051 im 8-Bit Sektor ist. Sehr viele jener, die überhaupt in dem Sektor > tätig sind, haben ihn bereits irgendwie im Angebot, oder werden es über > kurz oder lang. Genau.
A. K. schrieb: > Und die Dinger drücken nach unten. Der Sektor komplexerer 8-Bit > Controller mit grossem Programm gerät ja schon unter Druck. Wer da nicht > schon auf viel Erfahrung und Code sitzt, sondern es sich aussuchen kann, > der wird immer mehr zu ARMs tendieren, statt sich mit Fiesmatentchen wie > etlichen Adressräumen und zueinander inkompatiblen Pointern rumärgern zu > müssen. Das ist schon längst entschieden: Alles was jetzt an jungem Gemüse nachwächst, wird u.a. vor allem auf ARM gehen. Für die ist 8051 billiger Chinakram ohne Mehrwert für hochpreisige Länder. Ich gebe dem 8051 noch 10, vielleicht 20 Jahre. Wobei ich nicht genau weiß, wie das Lizenzmodell ist. Bei ARM muß man wohl für jedes verkaufte System zahlen.
Lattice User schrieb: > Abdul K. schrieb: >> Glaube ich nicht für die nächsten 10 Jahre. Der ARM ist vielen zu >> umständlich. Mich stört z.B. das man nicht ein einfach vorhersagbare >> Laufzeitverhalten hat. Beim 8051 kann man die Zyklen einfach auszählen. > > Und diese Zyklen muss man auch viel zu oft zählen weil man das Ding am > Rande der Leistungsfähigkeit benutzt. Been there, done that. > War für mich nie ein Problem. Dann hast du schlicht die falsche Plattform für dein Projekt gewählt. Mit einem 8051 baut man Waschmaschinen, keine CNC-Maschinen! (Klar kenne ich Projekte mit Banking u.a. beim 8051...) >> >> Für mich ist aber der Compiler und der I/O interessanter. Leider gibts >> es nur noch C als Sprache. Man muß ja die Libs benutzen können. Das ist >> das Schlimmste. > >> Persönlich hätte ich mir den AVR im PSoC gewünscht. > > Den hätte man aber einem direkten Konkurrenten kaufen müssen. > Das ist das Hauptproblem! Warum sollte jemand sonst so eine Krücke wie den M8C verwenden? Richtig, wurde bei der Übernahme einer Firma quasi kostenlos mitgeliefert...
Abdul K. schrieb: > Lattice User schrieb: >> Abdul K. schrieb: >>> Glaube ich nicht für die nächsten 10 Jahre. Der ARM ist vielen zu >>> umständlich. Mich stört z.B. das man nicht ein einfach vorhersagbare >>> Laufzeitverhalten hat. Beim 8051 kann man die Zyklen einfach auszählen. >> >> Und diese Zyklen muss man auch viel zu oft zählen weil man das Ding am >> Rande der Leistungsfähigkeit benutzt. Been there, done that. >> > > War für mich nie ein Problem. Dann hast du schlicht die falsche > Plattform für dein Projekt gewählt. > Mit einem 8051 baut man Waschmaschinen, keine CNC-Maschinen! Du willst doch unbedingt Zyklen zählen, nicht ich :) Oft hat du doch gar nicht die Wahl welcher Prozessor eingesetzt wird, und der 8051 ist in vielen ASICs als Controller integriert. (z.B. Fernseher, Monitor, ...). Und wenn dann in so einem System ein 32bit Prozessor gebraucht wird, z.B. weil der Fernseher plötzlich MPEG/H.264 Decoding braucht oder gar auf Linux basieren soll wird der 8051 trotzdem mitgeschleppt um z.B. die Videopipeline zu kontrollieren.
Abdul K. schrieb: > Er meinte wohl, den HC11 gäbe es in verschiedenen Gehäusevarianten, eben > auch in PLCC68 so wie den 515. Den 515 gibts aber NUR in diesem Gehäuse. Konkret meinte ich, sie sind in etwa in der selben Leistungsklasse. Der eine hat mehr Peripherie von diesem, der andere mehr von jenem. Wer sich einmal auf Motorola oder Intel eingeschossen hat, verläßt diesen Bereich nicht so gerne bald: Das bedeutet immer, wenigstens neue Tools anzuschaffen. Moppel schrieb: > Das sehe ich aber anders. Zum Einen ist der HC11 um einiges schneller > unterwegs, da er intern durch 4 teilt und nicht durch 12. Dann hat er > nicht diese fiese Stack-Einschränkung, von Neumann, kann 16 Bit > dividieren, hat Unterstützung für Zahlen mit Vorzeichen, usw. Ich für meinen Teil, fand die 8051-er für mich immer ganz OK. Wenn man alle Spezialitäten kennt, kann man sehr gut damit leben. Z.B. der 80C517, hat eine 32-bit-Hardware-MDU, und hängt im Rechnen größere Klassen glatt ab. Und was macht denn der 68HC11 in meinem EPROMMER? Er steuert ein paar I/O-Ports an, und kommuniziert über 9600 Baud mit dem PC. Könnte genau so gut ein 8051 sein. Der Hersteller hat als Vorliebe aber den 68HC11. Das ist auch ganz OK so. Lattice User schrieb: > Zum 8048: Der ist keinesweg schon 1980 verstorben, da darf man nicht > übershen dass praktisch jeder PC mit 2 davon kommt, einen in der > Tastatur Wie schon gesagt: Er ist teilweise in neuen Tastaturen. Wenn man die öffnet, ist da original ein Baustein mit der Bezeichnung 8048 drin, wenn auch der mal von NEC oder OKI ist. Abdul K. schrieb: > Der 8051 ist extrem simpel intern aufgebaut. Harvard-Architektur macht > die Sache schön einfach. Es gibt genug Alternativen, wenn man was > anderes haben will. Meine Opto-Net-Boards von Feger mit dem 80C517A sind mit Jumpern konfigurierbar, ob Harvard oder Von Neumann. Letzteres geht übrigens mit 2 UND-Gattern, an den Pins PSEN und WR/RD (muß ich mal genauer nachsehen). Die Boards haben auch Vollausbau im Speicher, je 64k RAM und ROM. Das reicht noch ein Weilchen. Die Von-Neumann-Konfiguration ist ja auch ganz praktisch, ich lade die Testprogramme einfach über ein Terminal vom PC aus. Zum Basteln reichen die Dinger auch noch völlig. Ich habe noch vor, die SDCC-Libraries mal an die MDU anzupassen. Dann gehen sie ab wie ein Zäpfchen. Obwohl man diese Bausteine neu nirgends mehr einsetzt. ;-) Jens Petersen schrieb: > Da lagen die > 68HCxx immer deutlich vorne. Das kaufe ich dir sogar unbesehen ab. Wieso sollte es auch nicht so sein? > Was im > KFZ-Bereich abgeht, bekommt man in der Regel garnicht mit. Wie ich schon oben bemerkte, schlachtete ich Schrott. Und da waren einige Motorsteuergeräte (Jetronic, Motronic) von Bosch dabei, hatten immer den 80C515 drinne. Einige Kommilitonen aus dem Studium waren vor 10 Jahren zur Exkursion bei Bosch, genau in dieser Abteilung. Sie kamen aus dem Staunen nicht mehr raus, und sagten, der Code sei vollständig in Assembler geschrieben.
Abdul K. schrieb: > Das ist schon längst entschieden: Alles was jetzt an jungem Gemüse > nachwächst, wird u.a. vor allem auf ARM gehen. Für die ist 8051 billiger > Chinakram ohne Mehrwert für hochpreisige Länder. Ich gebe dem 8051 noch > 10, vielleicht 20 Jahre. Aussterben wird er so schnell nicht, aber ob er in 10 Jahren noch den Spizenplatz einhält glaube ich eigentlich nicht. Im Augenblick drängen ARM Basierende Controller im Niedrigpreissegment auf den Markt. > > Wobei ich nicht genau weiß, wie das Lizenzmodell ist. Bei ARM muß man > wohl für jedes verkaufte System zahlen. Der 8051 als solcher ist lizensfrei, du kannst jederzeit einen eigenen machen. Ansonsten hängt es vom Hersteller des IP Cores ab. Zum ARM: http://www.arm.com/products/buying-guide/licensing/index.php "The manufacturing rights are perpetual" Ich lese das so, dass keine Stückzahllizens anfällt.
Lattice User schrieb: > Aussterben wird er so schnell nicht, aber ob er in 10 Jahren noch den > Spizenplatz einhält glaube ich eigentlich nicht. Im Augenblick drängen > ARM Basierende Controller im Niedrigpreissegment auf den Markt. Das Leben des 8051 wurde schon 1995 abgesungen. Aber es ist richtig, mit Aufkommen der LPC2000-Serien bei NXP versuchte man, über den Preis die 8-Bitter zu verdrängen. Ist ja auch nicht verkehrt, wenn man zum selben Preis einen 32-Bitter bekommt, der keinen höheren Energieverbrauch hat.
Einen eigenen ARM kannst du genauso machen. Oder kann man Op-Code mittlerweile patentieren? Der ARM bietet einfach das Optimum zwischen Die-Fläche und Leistung. @Wilhelm: Sieht so aus, als würden sie bei Bosch Zyklen zählen ;-) Das sie die Leute überhaupt reinliesen, wundert mich.
Wilhelm Ferkes schrieb: > Lattice User schrieb: > >> Zum 8048: Der ist keinesweg schon 1980 verstorben, da darf man nicht >> übershen dass praktisch jeder PC mit 2 davon kommt, einen in der >> Tastatur > > Wie schon gesagt: Er ist teilweise in neuen Tastaturen. Wenn man die > öffnet, ist da original ein Baustein mit der Bezeichnung 8048 drin, wenn > auch der mal von NEC oder OKI ist. Bei PS/2 Tastaturen war es noch nie ein anderer. Als ROM Typ konntest du die schon immer mit eigenem Aufdruck kaufen, diese Kosten spart man sich halt neuerdings. Mit USB Tastaturen werden hier die Karten neu gemischt, dafür ist der 8048 dann doch zu klein.
Abdul K. schrieb: > Einen eigenen ARM kannst du genauso machen. Oder kann man Op-Code > mittlerweile patentieren? > Was man bei uns patentieren kann oder nicht ist leider viel zu oft irrelevant. Und in den USA kannst du einen Mausclick patentieren. Intel hat ja die AMD x64 opcodes auch nicht einfach reimplementiert sondern sich mit einem Crosslizensabkommen von AMD die Erlaubnis geholt.
Abdul K. schrieb: > @Wilhelm: > Sieht so aus, als würden sie bei Bosch Zyklen zählen ;-) > Das sie die Leute überhaupt reinliesen, wundert mich. Mich wundert da nichts. Bei extremen Stückzahlen lohnt es sich eventuell tatsächlich, in Assembler zu programmieren. Da sind Entwicklungskosten vielleicht das kleinere Übel. Sicher holt man gegenüber einer Hochsprache noch etwas Performance heraus, wenn man das richtig macht. Das Assembler aber fehleranfälliger ist, alleine auf Grund der Quellcodegröße und Übersicht, ist mir schon klar. Als ich mit ARM begann, fand ich auf fernöstlichen Seiten ausgezeichnete Tutorials in ARM-Assembler. Und begegnete auch Dingen, daß Leute den ARM vollständig in Assembler programmieren. Übrigens würde ich heute gerne auch ARM wählen, habe es in der Industrie schon einmal getan, und 8051 abgelöst. Lattice User schrieb: > Mit USB Tastaturen werden hier die Karten neu gemischt, dafür ist der > 8048 dann doch zu klein. Das ist wohl wahr. Wenn man bedenkt, daß der 8048 über Soft-UART kommunizierte, weil er keinen UART hat, das war schon schräg.
Lattice User schrieb: > Was man bei uns patentieren kann oder nicht ist leider viel zu oft > irrelevant. Und in den USA kannst du einen Mausclick patentieren. Als NEC 8088/8086 in Form der V20/V30 nachbaute hatten sie im Manual viele Befehle und Register umbenannt. Alles was nicht sowieso jede CPU hatte hiess anders. Offenbar waren nicht die Opcodes das Problem.
A. K. schrieb: > Lattice User schrieb: > >> Was man bei uns patentieren kann oder nicht ist leider viel zu oft >> irrelevant. Und in den USA kannst du einen Mausclick patentieren. > > Als NEC 8088/8086 in Form der V20/V30 nachbaute hatten sie im Manual > viele Befehle und Register umbenannt. Alles was nicht sowieso jede CPU > hatte hiess anders. Offenbar waren nicht die Opcodes das Problem. NEC hatte eine 8086 Secondsource Lizenz. NEC ist nicht gerade klein. Ausserdem gab es das Gericht in einem kleinen Kaff in Texas noch nicht, wo du in so einem Fall erst mal verlierst. Wenn man einen ARM einfach neu entwickelt, muss man auf jedem Fall erhebliche Anwalts und Gerichtskosten mit einplannen. Und dabei ist irrelevant wer am Ende den Prozess gewinnt. Beim 8051 Core gibt es diese Probleme nicht mehr, auch weil Intel in diesem Markt nicht mehr interresiert ist.
Lattice User schrieb: > Beim 8051 Core gibt es diese Probleme nicht mehr, auch weil Intel in > diesem Markt nicht mehr interresiert ist. Auf der Intel-Homepage gibt es seit wenigstens 5 Jahren keinen Support mehr zum 8051. Wie es vorher war, weiß ich aber auch nicht.
>aber ARM ist im 32-Bit Controller-Sektor das, was 8051 im 8-Bit Sektor ist >Ich gebe dem 8051 noch 10, vielleicht 20 Jahre. Bei diskreten 8bit-uC-ICs stand der 8051 vielleicht vor 25 Jahren an oberster Stelle, aber heute nicht mehr. Aber ganz aussterben wird er wohl nie. >Wer sich einmal auf Motorola oder Intel eingeschossen hat, verläßt diesen >Bereich nicht so gerne bald Motorola oder Intel ? Das war einmal. >VonNeumann ist beim 8051 bei externem Speicher immer möglich! Toll. Jede us! >Beim 8051 kann man die Zyklen einfach auszählen. Toll. Jede us! >Vorsicht! Der 68K kannte nur 16-Bit Code-Segmente! Hä? >Oder kann man Op-Code mittlerweile patentieren? Das kann ich mir nicht vorstellen. Denn bei Patentanmeldung muss ja gesagt werden, was neu und besser ist UND wie das gemacht werden soll. Und mit Op-Code alleine ist die Realisierung noch nicht dargelegt. Zu ARM: Ein Wechsel von einem zum anderen ARM-Hersteler, kann uU genauso aufwändig (oder aufwändiger) sein , wie der Wechsel zum anderen Hersteller mit anderer CPU. Ausserdem: Der weltweite Marktführer von uCs hat bessere CPUs als ARM(CM..), und ARM überhaupt nicht im Programm und will die auch nicht.
> Ausserdem: Der weltweite Marktführer von uCs hat bessere CPUs als > ARM(CM..), und ARM überhaupt nicht im Programm und will die auch nicht. Was ist unter "besser" zu verstehen? Kannst du das etwas ausführen?
Zyklen zähle ich, wenn der 8051 hartes Timing erzeugen muß. Ich zähle keine, wenn du das auf Performance beziehst. Ist einfach sinnlos, wenn das gegenüber keinerlei Anstalten macht nachzudenken "Jede us!" Was soll das heißen? Jedenfalls nix deutsches.
MCUA schrieb: >>Vorsicht! Der 68K kannte nur 16-Bit Code-Segmente! > Hä? Oben schon geklärt. Er bezieht sich dabei auf ein etwas eigenwilliges Speichermodell, das von Apple verwendet wurde um sich eine Hardware-MMU zu ersparen.
> "Jede us!" > Was soll das heißen? Jedenfalls nix deutsches. Könnte - jede Mikrosekunde - bedeuten. Aber was soll's der Beitrag ist so oder so nur Wischi-Waschi.
Ja, das macht Sinn. MCUA hält wohl Rennschweine. @A.K.: Bist du dir sicher, das der 68K relative Sprünge mit 32-Bit Offset konnte? Soweit ich mich erinnere, fand ich solche Befehle nicht im Assembler. Äh, ich meine Op-Code, denn ich hatte keinen Assembler, folglich alles per Hand gecodet. Am Ende hatte ich dann den ADB-Bus Rainbow Software-Dongle geknackt ;-) Waren nur ca. 100 Befehle notwendig, dann dacht die Dongle-Software sie hätte reale Hardware dran.
Abdul K. schrieb: > @A.K.: Bist du dir sicher, das der 68K relative Sprünge mit 32-Bit > Offset konnte? Habe ich nie behauptet. Erst mit 68020 - diese Erweiterung war harmlos. Aber mit Segmenten hat das zunächst Nullkommagarnix zu tun. Erst wenn man auf diese Beschränkung der relativen Adressierung ein entsprechendes Speichermodell eines bestimmten Betriebssystem begründet. Aber das ist dann Sache des Betriebssystems. Mir ist kein 32- oder 64-Bit Prozessor mit fester Befehlslänge bekannt, der den gesamten Adressraum mit relativer Adressierung erfassen kann. Trotzdem wird aus dieser Beschränkung der Codierung keine Segmentierung.
Oh, dann hatten wir aneinander vorbeigeredet. Wie hat dann das BS Programmsegmente verschieben können? Das verstehe ich nicht. Habe ja oben erklärt, wie Apple das realisierte um Garbage Collection durchführen zu können. Der Memory Manager hat periodisch diese 'Segmente' im Speicher sortiert und eventuell auch gelöscht oder neue geladen.
Abdul K. schrieb: > @A.K.: Bist du dir sicher, das der 68K relative Sprünge mit 32-Bit > Offset konnte? Positionsunabhängiger Code geht natürlich auch jenseits von 64KB. Nur eben mit etwas mehr Aufwand. Auch x86-Code sieht etwas anders aus, wenn man dem GCC ein -fPIC zumutet.
Abdul K. schrieb: > Oh, dann hatten wir aneinander vorbeigeredet. Wie hat dann das BS > Programmsegmente verschieben können? So wie überall sonst auch: mit einer Hardware-MMU. Intern gab es keine, also hat man nicht selten extern eine hinzugestrickt. Skizziert hatte ich eine solche oben bereits.
Ah ja. Nun, Apple hatte das mit Handles gemacht.
>Mir ist kein 32- oder 64-Bit Prozessor mit fester Befehlslänge bekannt, >der den gesamten Adressraum mit relativer Adressierung erfassen kann. (also RISC, weil feste Befehlslänge) Das kann norm.weise auch nicht gehen, da in 32 Bit OPcode (so breit ist der Adr.raum von 32bittern ja meistens) nunmal nicht auch noch 32Bit Disp reinpassen können. Aber man kann das (32bit)disp (selbst wenn OPcode nur 16bit breit) auch in ner Mem-Table ablegen, dann geht es wieder. (Allerdings braucht diese (so genannte) 'RISC'-CPU in diesem Fall dafür nat. weitere Mem-zugriffe. (wie ein CISC auch) )
MCUA schrieb: > (also RISC, weil feste Befehlslänge) Ja, aber ich wollte den Begriff vermeiden, weil sich allerhand RISCs mit variabler Befehlslänge tummeln, die dieses Problem nicht haben. Von AVR bis hin zu Motorola/Freescales Frechheit, sogar den Coldfire so zu nennen. > Das kann norm.weise auch nicht gehen, Jep, du hast es gemerkt! ;-) Mit Präfix-Methoden wärs aber prinzipiell möglich, beispielweise indem man 16-Bit Disp und 16-Bit Konstante im Befehl per Präfix-Befehl zu vollen 32-Bit aufbläst. Sowas in der Art findet sich beim MaxQ2000.
> weil sich allerhand RISCs mit variabler Befehlslänge tummeln, bis hin zu > Motorola/Freescales Frechheit, sogar den Coldfire so zu nennen. (ehem) Motorola nennt das wohl VL-RISC, weil RISC scheinbar moderner klingt. Aber VL-RISC ist eigentlich CISC als RISC.
MCUA schrieb: > Aber VL-RISC ist eigentlich CISC als RISC. Natürlich. Es sei denn man sieht es aus dem Übergang vom CPU32-Core zur ersten echten Coldfire-Generation heraus, denn so betrachtet war diese tatsächlich reduziert, hat sich das R also verdient. ;-)
Hä hä. Aber ich steige wohl nun aus. Der Thread dauert immer einige Sekunden bis er aufgebaut ist. Leider erscheinen die neuesten Posts immer am Ende, nicht am Anfang wie bei emails.
MCUA schrieb: > Die 68HC05/08/68HC11 (auch ST6,7) waren/sind in der AutomobilBranche > schwer vertreten. Diese 68-Teile sind sogar hier im Forum noch nicht mal im Filter, der 8051 hingegen schon. Sind sie ausgestorben? Wenn ja, warum? War der 8051 doch noch eine Konkurrenz, vielleicht eine ernst zu nehmende? Vielleicht sogar eine sehr beliebte? Und sicher hat er einige verdrängt. Mir begegnete bisher auch niemand, der über sie klagte. Ich tue das bis heute auch nicht.
Abdul K. schrieb: > Aber ich steige wohl nun aus. Der Thread dauert immer einige Sekunden > bis er aufgebaut ist. Leider erscheinen die neuesten Posts immer am > Ende, nicht am Anfang wie bei emails. Musst nur die Seitenaufteilung einschalten.
Wilhelm Ferkes schrieb: > Diese 68-Teile sind sogar hier im Forum noch nicht mal im Filter. > Sind sie ausgestorben? Wenn ja, warum? Das Forum hier repräsentiert nicht die Welt, sondern nur einen kleinen nicht repräsentativen Ausschnitt davon.
A. K. schrieb: > Das Forum hier repräsentiert nicht die Welt, sondern einen kleinen nicht > repräsentativen Ausschnitt davon. Aber es repräsentiert die User. Wäre schon komisch, wenn hier nur 8051-er her finden, und 68HC11-er weniger. Mit den AVR und ATmega hier im Forum habe ich ja auch nichts zu tun. Ja wo sind denn dann die 68HC11-er stark vertreten? Im US-Ausland? Motorola steht ja von der ehemaligen Namensgebung her für Automotive-Konzern in den USA, etwa was Bosch in Deutschland ist. Ein bißchen anders zwar strukturiert, aber im Groben.
Wilhelm Ferkes schrieb: > Aber es repräsentiert die User. Es repräsentiert einen bestimmten Teil deutscher User, und nicht einmal den nach Stückzahl gewichtet. Du findest hier fast ausschliesslich Leute aus dem deutschsprachigen Raum, weshalb beispielsweise vorwiegend im japanischen Raum verwendete Controller schon mal wegfallen. Auch sind hier nach meinem Eindruck überwiegend Anwender mit eher kleinen Stückzahlen vertreten. Wenns nicht Bastler sind, dann die Kategorie Ing-Büro und unterer Mittelstand. Ein Markt für den sich Freescale nicht gross zu interessieren scheint.
Wilhelm Ferkes schrieb: > MCUA schrieb: > >> Die 68HC05/08/68HC11 (auch ST6,7) waren/sind in der AutomobilBranche >> schwer vertreten. > > Diese 68-Teile sind sogar hier im Forum noch nicht mal im Filter, der > 8051 hingegen schon. > > Sind sie ausgestorben? Wenn ja, warum? War der 8051 doch noch eine > Konkurrenz, vielleicht eine ernst zu nehmende? Vielleicht sogar eine > sehr beliebte? Und sicher hat er einige verdrängt. Mir begegnete bisher > auch niemand, der über sie klagte. Ich tue das bis heute auch nicht. bei mir werkeln noch 2 gelegentlich auf ner CControlBasic II ;-)
A. K. schrieb: > Abdul K. schrieb: > >> Aber ich steige wohl nun aus. Der Thread dauert immer einige Sekunden >> bis er aufgebaut ist. Leider erscheinen die neuesten Posts immer am >> Ende, nicht am Anfang wie bei emails. > > Musst nur die Seitenaufteilung einschalten. Aha. Dafür ist es gut. Was hälst du denn von NIOS?
Habs grad mal schnell überflogen. Klassische langweilige an MIPS orientierte RISC mit 32-Bit Codierung fast ohne besondere Eigenschaften (kennst du eine kennst du alle). Aber mit I/O-Befehlen für Cache-Bypass, was die hier irgendwo mal erwähnte Sache mit dem speziellen Code für volatile Variablen erklärt. Anderswo wird sowas über Adressbereiche implementiert. Diverse Konkurrenten neigen mittlerweile dazu, zur reinen 32-Bit Codierung auch eine 16-Bit Codierung anzubieten - oder auch nur diese - um Platz zu sparen. Hab das hier in aller Kürze nicht gesehen. Anderer Softcore?
Vielleicht etwas off-topic, aber für die die Transistoren nicht trauen, hier mal ein Schaltplan eines Relaisrechners mit etwa 1000 Relais. http://www.cs.ubc.ca/~hilpert/e/simon/index.html
GeraldB schrieb: > Der AppleIII hatte auch "nur" einen 6502, der aber mit 2MHz lief. Die > 16bit Version war der AppleIIGS. Und das der gescheitert ist, kann man > nicht sagen. Den IIGS kann man durchaus als gescheitert ansehen. Die direkten Wettbewerber waren der Atari ST (als Nachfolger von 800XL, 130XE) und der Commodore Amiga 1000 (als Nachfolger von C64, C128D). Beide waren bei gleichem Preis deutlich performanter und damit relativ gesehen günstiger als der Apple. 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. Atari und Commodore haben den harten Schnitt gewagt, auf Kompatibilität verzichtet, und waren damit erfolgreicher. Patrick
> Atari und Commodore haben den harten Schnitt gewagt, auf Kompatibilität > verzichtet, und waren damit erfolgreicher. Das ist ja auch der Grund warum Commodore und Atari heute so erfolgreich am Markt bestehen - während Apple kaum noch jemand kennt.
Apple ist ja auch den Umweg über iPod und Co gegangen. Ohne dieses Eierkram wäre der Apfel auch schon verschimmelt.
> Ohne dieses Eierkram wäre der Apfel auch schon verschimmelt.
Umweg? Was soll der Unfug? Apple geht als Unternehmen mit vielen Ideen -
auch viele Wege. Man schaue sich nur Appels erfolgreiche Geschichte im
Notebooksektor an oder die Macintosh-Serie. Du hast einfach keinen
blassen Schimmer.
Schicke (und teure) Computer haben sie schon immer gebaut. Nur die Gewinne sind erst wieder mit den "neuen Ideen" gekommen.
Wilhelm Ferkes schrieb: > Ja wo sind denn dann die 68HC11-er stark vertreten? Im Maschinenbau (Textil) sind die schon mal vertreten. Ich habe da einige Jahre lang Soft+Hardware fuer gemacht. Da wurden die in groesseren Stueckzahlen in Bedienpanels und FUs eingesetzt. Auch kenn ich die Teile von Geldscheinlesern eine grossen Schokoherstellers. Soviel ich noch weiss waren die im franzoesich sprechenden Raum beleibt.
Markus schrieb: >> Atari und Commodore haben den harten Schnitt gewagt, auf Kompatibilität >> verzichtet, und waren damit erfolgreicher. > > Das ist ja auch der Grund warum Commodore und Atari heute so erfolgreich > am Markt bestehen - während Apple kaum noch jemand kennt. Auch Apple hatte erst mit dem MacIntosh wieder Erfolg. Der war zu nix kompatibel, aber dafür von Leuten zu bedienen, die eigentlich keinen Bock auf Computertechnik haben. "Computer as an appliance", als Gerät. Einschalten und benutzen. Genau diese Zielgruppe bedienen auch die iGadgets. Aber es ging um den Apple IIGS. Der musste Rücksicht auf seine Vorgänger nehmen und war damit dem ST und Amiga gegenüber im Nachteil. Patrick
om pf schrieb: > Aber es ging um den Apple IIGS. Der musste Rücksicht auf seine Vorgänger > nehmen ... Nicht nur das, er kam schlichtweg ein paar Jahre zu spät, nämlich erst gegen Ende 1986.
DirkB schrieb: > Schicke (und teure) Computer haben sie schon immer gebaut. Nur die > Gewinne sind erst wieder mit den "neuen Ideen" gekommen. Hast du Apple-Aktien und bist versauert wegen damaligen Gewinneinbruch? So einer würde nämlich genauso argumentieren! Im Allgemeinen schert sich der Konsument nicht um den Ertrag des Herstellers, sondern möchte diesen sogar indirekt minimieren durch Kauf eines besonders guten Gerätes zu niedrigstem Preis. Soweit ich mitbekommen habe, könnte man auch sagen: Sie verkaufen Computer und Gadgets um ihre gedongelte Musik an den Mann zu bringen. Jedenfalls soll die Musiksparte ganz prächtige Gewinne abwerfen. So ganz allgemein. Soll jetzt kein Apple-Thread werden.
Abdul K. schrieb: > Im Allgemeinen schert sich der Konsument nicht um den Ertrag des > Herstellers, sondern möchte diesen sogar indirekt minimieren durch Kauf > eines besonders guten Gerätes zu niedrigstem Preis. Genau. Und das waren damals die PCs mit Windows. (So dachten die meisten Konsumenten) Hätte, wäre, wenn ... es Apple damals so gut gegangen wäre, hätte Steve Jobs ja nicht wieder einsteigen brauchen (mit seinen neuen Ideen). Der hat seinen Job schon gut gemacht.
Rufus Τ. Firefly schrieb: > om pf schrieb: >> Aber es ging um den Apple IIGS. Der musste Rücksicht auf seine Vorgänger >> nehmen ... > > Nicht nur das, er kam schlichtweg ein paar Jahre zu spät, nämlich erst > gegen Ende 1986. Der Amiga 1000 kam Mitte 1985, der Atari ST Ende 1985. Damit hatte der IIGS "nur" 1 Jahr Verspätung. Auch wenn es uns damals ewig lange vorkam... Patrick
Wilhelm Ferkes schrieb: > Schau dir den 8085 an, [...] > Integrierte Peripherie wie z.B. Timer oder UART gab es auch nicht. Der 8085 hatte im Gegensatz zum 8080 und Z80 immerhin einen integrierten UART (allerdings nur mit RxD und TxD, keine Steuerleitungen) und zwei spezielle Maschinenbefehle, um jeweils ein Byte zwischen dem Akku und dem Sende- bzw. Empfangspuffer hin- und herzuschieben. Der interne UART wurde beispielsweise im http://de.wikipedia.org/wiki/Mikrocomputer_für_Ausbildung verwendet, um die Tastatur-Monitor-Baugruppe anzubinden, die im Grunde ein serielles Terminal mit 5V-Pegel war.
Abdul K. schrieb: > Was hälst du denn von NIOS? NIOS (Altera), MicroBlaze (Xilinx), Mico32 (Lattice) sind eher aus der Not geboren einen FPGA optimierten lizenzfreien Softcore anbieten zu müssen. Konkurrenz zu ARM/Mips können und wollen diese nicht sein. A. K. schrieb: > Diverse Konkurrenten neigen mittlerweile dazu, zur reinen 32-Bit > Codierung auch eine 16-Bit Codierung anzubieten - oder auch nur diese - > um Platz zu sparen. ARM Thumb Befehlssatz. Mir ist nicht bekannt ob das auch jemand anders macht, für FPGAs ist ein 2. Befehlssatz eher Balast.
om pf schrieb: > Damit hatte der IIGS "nur" 1 Jahr Verspätung. Ja, aber mit der rasanten Taktfrequenz von nur 2.8 MHz war er auch "nur" ein Jahr nach ST/VC Amiga altes Brot. Der '816 hätte mit bis zu 16 MHz getaktet werden können, und wäre dann zumindest interessant gewesen, aber das ging aus firmenpolitischen Gründen nicht. Naja, daß His Steveness dem Laden dann den Rücken gekehrt hat, dürfte auch daran gelegen haben.
Rufus Τ. Firefly schrieb: > om pf schrieb: >> Damit hatte der IIGS "nur" 1 Jahr Verspätung. > Ja, aber mit der rasanten Taktfrequenz von nur 2.8 MHz war er auch "nur" > ein Jahr nach ST/VC Amiga altes Brot. 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. Die beiden anderen Firmen, die heute nicht mehr da sind, haben hingegen beim Generationswechsel einen sauberen Cut gemacht.
Hat man den Taktfrequenzwechsel damals nicht zur Laufzeit unterbringen können? Das kann doch auch damals nicht so schwer gewesen sein ? Das sollte doch sogar extern über Portbits und Vorteiler machbar sein?
R. Max schrieb: > Wilhelm Ferkes schrieb: > >> Schau dir den 8085 an, [...] >> Integrierte Peripherie wie z.B. Timer oder UART gab es auch nicht. > > Der 8085 hatte im Gegensatz zum 8080 und Z80 immerhin einen integrierten > UART (allerdings nur mit RxD und TxD, keine Steuerleitungen) und zwei > spezielle Maschinenbefehle, um jeweils ein Byte zwischen dem Akku und > dem Sende- bzw. Empfangspuffer hin- und herzuschieben. > > Der interne UART wurde beispielsweise im > http://de.wikipedia.org/wiki/Mikrocomputer_für_Ausbildung verwendet, um > die Tastatur-Monitor-Baugruppe anzubinden, die im Grunde ein serielles > Terminal mit 5V-Pegel war. Ja, ich hab den 8085 mal in Assembler programmiert, allerdings nur ein Lauflicht bzw. Bitmuster an 2 I/O-Ports des 8255. Der Baugruppe verpaßte ich auch noch einen Timer 8253, damit es wenigstens geringfügig komfortabel wird. Damit kann er sogar PWM, der 8253 war ein interessanter vielseitiger Timer. Auch habe ich hier noch das Buch zum 8085 von Günter Schmitt stehen: Mikrocomputertechnik/8085A. Dort habe ich mir in der Vor-Internet-Zeit einiges abgeschaut. Am Buchende ist ein mehrseitiges Terminalprogramm in Pascal abgedruckt. Wenn ich mal Lust und Zeit habe, wandele ich das in C oder Assembler um, da ich keinen Pascal-Compiler habe, aber das ist kein Problem. Der SDCC beherrscht außer 8051 wohl auch 8085 und Z80. Aber für die Baugruppe noch einen Monitor zu schreiben, wäre sicherlich interessant. Mit den Befehlen SID und SOD konnte man aus einem Byte ein bit maskieren, und seriell herein oder heraus schieben. Im Grunde war das ja nur die Setzung eines Pins. Alles andere mußte man schon zu Fuß machen, und wenn die Baugruppe keinen Timer hatte, mit den Timings der Befehlszyklen herumrechnen. Das war schon etwas schräg, da fast jeder 8085-Befehl eine andere Zyklenzahl hat. Aber ich habe hier auch noch UART-Bausteine liegen, ich glaube, 8250. Aber das Lochraster-Board hat leider keinen Platz mehr. Die Europakarte ist mit 8085, 8255, 8253, RAM und EPROM und Adreßdekoder brechend voll. Ansonsten habe ich hier noch ein paar Zentralsteuerplatinen liegen, die mal aus MFA-Computern stammten, welche verschrottet wurden. Es sind allerdings Einschübe im Europa-Format, die man so direkt gar nicht betreiben kann. Ich habe da auch keine Pläne, es sind einfach nur mal Museumsstücke zur Ansicht. Helmut Lenzen schrieb: > Im Maschinenbau (Textil) sind die schon mal vertreten. Ich habe da > einige Jahre lang Soft+Hardware fuer gemacht. Da wurden die in > groesseren Stueckzahlen in Bedienpanels und FUs eingesetzt. Auch kenn > ich die Teile von Geldscheinlesern eine grossen Schokoherstellers. > Soviel ich noch weiss waren die im franzoesich sprechenden Raum > beleibt. Das ist doch mal eine handfeste Aussage!
Winfried J. schrieb: > Hat man den Taktfrequenzwechsel damals nicht zur Laufzeit unterbringen > können? > Man konnte im Betrieb umschalten. Allerdings hing da einiges an Peripherie dran, was auf 1MHz angewiesen war. So wurde z.B. bei einem Zugriff auf die Slots runtergetaktet, und der Videogenerator griff auch mit der gewohnten Geschwindigkeit auf seinen Speicher zu. Der natürlich auch nicht linear organisiert war, sondern genauso verschachtelt wie beim Apple ][ (bei dem man das Chaos in Kauf genommen hatte, um ein paar Gatter zu sparen).
Lattice User schrieb: > ARM Thumb Befehlssatz. Mir ist nicht bekannt ob das auch jemand anders > macht, für FPGAs ist ein 2. Befehlssatz eher Balast. Ein zweiter ja. Muss ja kein zweiter sein, siehe Cortex M1. Ist platzsparende Codierung bei FPGAs überflüssig?
Lattice User schrieb: > Abdul K. schrieb: >> Was hälst du denn von NIOS? > > NIOS (Altera), MicroBlaze (Xilinx), Mico32 (Lattice) sind eher aus der > Not geboren einen FPGA optimierten lizenzfreien Softcore anbieten zu > müssen. Konkurrenz zu ARM/Mips können und wollen diese nicht sein. > Naja. Ich frage nur, weil ich oftmals größere Hardware-Logik UND nen Mikrocontroller benötige. Aber ich kriege einfach keine Übersicht über die ganzen FPGAs. Außerdem muß es auslesegeschützt sein und wenige Pins. Und auf ne Entwicklungsumgebung, die in GB zählt, habe ich auch keinen Bock. Bleibt da noch was übrig?
A. K. schrieb: > Lattice User schrieb: > >> ARM Thumb Befehlssatz. Mir ist nicht bekannt ob das auch jemand anders >> macht, für FPGAs ist ein 2. Befehlssatz eher Balast. > > Ein zweiter ja. Muss ja kein zweiter sein, siehe Cortex M1. > Ist platzsparende Codierung bei FPGAs überflüssig? Wie immer so pauschal kann man das natürlich nicht sagen. Wichtig bei einem Softcore ist der Logikfootprint. d.h. Bedarf an LUTs und FlipFlops. Speicher in der Form von Blockram ist in der Regel reichlich vorhanden. Ist wie vieles ein Kompromiss. PS. Einen Softcore habe ich mir noch nicht angetan.
Abdul K. schrieb: > > Naja. Ich frage nur, weil ich oftmals größere Hardware-Logik UND nen > Mikrocontroller benötige. Aber ich kriege einfach keine Übersicht über > die ganzen FPGAs. Außerdem muß es auslesegeschützt sein und wenige Pins. > Auslesegeschutz ist heute Standard. Bei FPGAs die von einem externen Flash geladen werden kann man es mit AES verschlüsseln. Ist 100 pin TQFP viel für dich? Oder gar 25-ball WLCSP (2.5 * 2.5 mm)? FPGAs in kleinen Gehäusen sind natürlich auch nicht sehr gross, für einen 8bit Softcore plus Logik reicht es aber. > Und auf ne Entwicklungsumgebung, die in GB zählt, habe ich auch keinen > Bock. Das ist natürlich ein KO Kriterium. (Lattice : >5GB installiert ohne Softcoreunterstützung).
Wilhelm Ferkes schrieb: > Mit den Befehlen SID und SOD konnte man aus einem Byte ein bit > maskieren, und seriell herein oder heraus schieben. Im Grunde war das ja > nur die Setzung eines Pins. Alles andere mußte man schon zu Fuß machen, [...] Ja, hast recht. Da hatte ich den 8085 mit seiner primitiven Hardware-Unterstützung für einen Soft-UART wohl mit dem 8051 in einen Topf geworfen, der einen richtigen UART hat.
R. Max schrieb: > Ja, hast recht. Da hatte ich den 8085 mit seiner primitiven > Hardware-Unterstützung für einen Soft-UART wohl mit dem 8051 in einen > Topf geworfen, der einen richtigen UART hat. Was ich am 8085 gut gelungen fand, ist der gigantische 16-bit-Hardware-Stack. Allerdings nur in einem guten Ausbau mit wenigstens 32k RAM. Anders als in den µC 8048 und 8051. Da konnte man schon mal Programmtechniken anwenden, die mehrbytige Datensätze auf dem Stack an Funktionen übergeben, ohne Variablen zu verbrauchen, oder mal eine rekursive Funktion bedenkenlos anwenden.
Wilhelm Ferkes schrieb: > Was ich am 8085 gut gelungen fand, ist der gigantische > 16-bit-Hardware-Stack. Allerdings nur in einem guten Ausbau mit > wenigstens 32k RAM. Anders als in den µC 8048 und 8051. Bischen andere Grössenklasse. Mikrocontroller wie 8048/51 hatten damals bestenfalls 256 Bytes RAM an Bord, da ergaben riesige Stacks wenig Sinn. Auch die maximal 256 Bytes des 6502 waren eher selten ein Problem.
A. K. schrieb: > Bischen andere Grössenklasse. Mikrocontroller wie 8048/51 hatten damals > bestenfalls 256 Bytes RAM an Bord, da ergaben riesige Stacks wenig Sinn. Ach, vom Preis und der Leistungsklasse tun sich 8085 und 8051 nicht allzu sehr viel. OK, sie hatten zwar jeweils einen Anwendungsbereich, und beim 8051 hätte ich mir gelegentlich 1k Stack gewünscht. Es geht aber auch so, und es ging immer gut.
Wilhelm Ferkes schrieb: > Ach, vom Preis und der Leistungsklasse tun sich 8085 und 8051 nicht > allzu sehr viel. OK, sie hatten zwar jeweils einen Anwendungsbereich, Mit der Grössenklasse meinte ich eher den Speicherausbau. 8051 war als begrenzter Mikrocontroller konzipiert, in erster Linie mit ausschliesslich internem ROM/RAM. Die 16-Bit Speicheradressierung wurde hauptsächlich für ROM-Zugriff genutzt, selten hatte man externes RAM. Es war ja nie vorgesehen gewesen, dass heute routinemässig viele KB RAM drin stecken, die man mangels geeigneter Adressierung nur ziemlich umständlich verwenden kann. Dass man 30 Jahre später noch damit programmiert, mit ROM-Kapazitäten von mitunter einigen hundert KB, das hatte Intel damals nicht im Traum vermutet. Hätte man wohl in lichten Momenten für regelrecht bescheuert gehalten. ;-) Ein 8080/85 hingegen war vor vorneherein für (damals) grosse Speicherkapazität konzipiert und dank eines einheitlichen Adressraums sprach da auch nichts gegen RAM.
A. K. schrieb: > Ein 8080/85 hingegen war vor vorneherein für (damals) grosse > Speicherkapazität konzipiert und dank eines einheitlichen Adressraums > sprach da auch nichts gegen RAM. Was hatte man denn damals an RAM, als der 8085 heraus kam? 1980 hatte man vielleicht 256 Byte oder 512? Ich habe jetzt noch eine RAM-Bank hier liegen, schöne violette Keramik mit 256x1 Bit aus dieser Zeit. Man brauchte 8 Bausteine für 256 Byte. Schon fast eine halbe Europa-Karte voll. Nur für die 256 mickrigen RAM-Bytes. Das RAM-Zeugs war damals teuer oder nicht machbar. Der 8048 wurde wegen Speichergrößen noch auf 1-Byte-Befehle optimiert, sowas kann man sich heute gar nicht mehr vorstellen. Meine spätere Lochrasterkarte mit 8085 konnte ich mit 32k RAM bestücken, aber nur, weil es diese Speicher 20 Jahre später tatsächlich gab. Ich kenne die beiden Dinger 8051 und 8085 sehr gut. Aber es ist schon erstaunlich, daß man früher erst mal nur hauptsächlich an viel Speicher dachte. Viel mehr konnte der 8085 ja auch gar nicht, mit den 6 Registern alleine konnte der gar nicht viel mehr reißen. Die Sachen mit den µC und integrierter Peripherie kamen ja erst später, und damit andere Handhabungstechniken.
Wilhelm Ferkes schrieb: > Was hatte man denn damals an RAM, als der 8085 heraus kam? 1980 hatte > man vielleicht 256 Byte oder 512? Schüttel man deine grauen Zellen neu durch, da kommt was durcheinander. Der AIM65 kam ca. 1977 raus und hatte 4KB SRAM, 8 Stück 1Kx4.
Heute optimiert man wieder. Aus Geschwindigkeitsgründen, damit der Flaschenhals CPU-RAM, möglichst breit wird.
A. K. schrieb: > Schüttel man deine grauen Zellen neu durch, da kommt was durcheinander. > Der AIM65 kam ca. 1977 raus und hatte 4KB SRAM, 8 Stück 1Kx4. Das stimmt, wenn man sowas zeitnah bekam. Von den 1Kx4 habe ich auch noch welche.
> Klassische langweilige an MIPS orientierte RISC mit 32-Bit Codierung fast > ohne besondere Eigenschaften Die werben damit, schön einfache Cores zu haben. Xilinx hat auch ARM Cores, haben auch ein IC, bei dem ARMCM3 drauf mit weitere FPGA-Teile. ...ist aber (meine ich) viel zu teuer. (ca4x teurer als das Äquivalent mit 2 ICs ) >Bei FPGAs die von einem externen Flash geladen werden kann man es mit AES >verschlüsseln. Aber nur bei grösseren FPGAs. Aber auch der unverschlüsselte Bitstream ist faktisch nicht zu knacken, weil Xilinx (und wahrsch. auch Altera) die konkrete Umsetzung geheim halten. >1980 hatte man vielleicht ... 1982: 8085A: ca 14 DM Z80CPU: ca 12 DM 6502: ca 17 DM 2716: ca 9 DM 2732: ca 18 DM 6116: ca 20 DM ..also schon eine ganze Menge EPROM/RAM. (der 8051 war da schon viel zu klein)
Wilhelm Ferkes schrieb: > Ich kenne die beiden Dinger 8051 und 8085 sehr gut. Aber es ist schon > erstaunlich, daß man früher erst mal nur hauptsächlich an viel Speicher > dachte. Viel mehr konnte der 8085 ja auch gar nicht, mit den 6 Registern > alleine konnte der gar nicht viel mehr reißen. Was hat denn die Anzahl Register damit zu tun? Die 8080 Architektur war zwar kein Geniestreich, aber doch universell nutzbar - und aus Software-Sicht(!) praktikabler als die Konkurrenz 6800. Mit 8085 (meist aber Z80) hat man um 1980 herum bereits ziemlich ernsthafte Business-Rechner auf CP/M-Basis gebaut, mit 64KB DRAM (16Kx1 Chips). 1981 gabs mit dem Osborne-1 den ersten CP/M Schleppable mit ebenfalls 64KB. > Die Sachen mit den µC und integrierter Peripherie kamen ja erst später, Für was hältst du den 8048, wenn nicht für einen Mikrocontroller mit integrierter Periphierie? Dessen Inspirationsquelle, der viele Jahre führende Mikrocontroller Fairchild F8 kam 1975 raus.
Die Zeit um 1975 bis 1980 bekam man manche Dinge in Bastelläden erst 3 Jahre nach Markteinführung. Entwickler in Firmen, mit Bezugsquellen und Info-Material, waren da viel besser dran.
A. K. schrieb: > Was hat denn die Anzahl Register damit zu tun? Mit Hilfe der 6 Register, was ja internes RAM war, konnte man im Extremfall den 8085 sogar als Single-Chip verwenden. Wenn man vom externen EPROM mal absah.
Wilhelm Ferkes schrieb: > Mit Hilfe der 6 Register, was ja internes RAM war, konnte man im > Extremfall den 8085 sogar als Single-Chip verwenden. Wenn man vom > externen EPROM mal absah. Sowas ähnlich Bizarres ist mir als DCF77-Uhr mal begegnet. War eine Z80 drin, mit einem(!) SRAM 1kx4. Aber das war ziemlich krank.
Wilhelm Ferkes schrieb: > Die Zeit um 1975 bis 1980 bekam man manche Dinge in Bastelläden erst 3 > Jahre nach Markteinführung. Entwickler in Firmen, mit Bezugsquellen und > Info-Material, waren da viel besser dran. Was man schlecht kriegte waren Mikrocontroller. Ausser im Schrott. Was mal in Elektor&Co aufkreuzte war jedoch im Versand auch zu kriegen, und das waren die universelleren Mikroprozessoren, wie auch SC/MP und statische ROM/RAM.
A. K. schrieb: > War eine Z80 > drin, mit einem(!) SRAM 1kx4. Aber das war ziemlich krank. Ooch, 512 Bytes sind für einen Assembler-Programmierer für eine kleine Maschine aber schon ganz schön viel Holz. Sogar heute manchmal noch. Um das SRAM wenigstens in ganzen Bytes zu lesen und zu schreiben, das ist ja bekannt, wie das geht, müssen wir gar nicht erst diskutieren. Meine DCF77-Uhr auf dem 8051 kommt mit dem internen RAM aus, welches sich bei 128 Bytes auch noch den Stack und die Register und das Flagsegment mit teilt. Man muß das nur höllisch genau berechnen. Das Board hat zwar auch 32k SRAM, wollte es aber so hin bekommen, daß es auch ohne geht. > Was man schlecht kriegte waren Mikrocontroller. Ausser im Schrott. Mir als unbedarftem Bastler wurden 8051 erst 1990 überhaupt bekannt. 1992 kaufte ich beim Schuricht 2 NMOS-8051, mit dem Hintergrund, dann endlich was über die Dinger zu lernen, wenn ich sie mal besitze, und einzusteigen. Und war stolz wie Oskar!!! 1978 las ich zwar schon mal, daß irgendwo ein 8085 das Licht der Welt erblickte, aber ich konnte damals mit dem Zeugs nicht wirklich was anfangen, war bis dahin Analogbastler auf einfachem Level. Eben Fernmelde-Azubi damals.
Wilhelm Ferkes schrieb: > A. K. schrieb: > >> War eine Z80 >> drin, mit einem(!) SRAM 1kx4. Aber das war ziemlich krank. > > Ooch, 512 Bytes sind für einen Assembler-Programmierer für eine kleine > Maschine aber schon ganz schön viel Holz. Sogar heute manchmal noch. Um > das SRAM wenigstens in ganzen Bytes zu lesen und zu schreiben, das ist > ja bekannt, wie das geht, müssen wir gar nicht erst diskutieren. > Doch, müssen wir!
MCUA schrieb: >>Bei FPGAs die von einem externen Flash geladen werden kann man es mit AES >>verschlüsseln. > Aber nur bei grösseren FPGAs. Hängt vom Hersteller ab, Bei Xilinx hast du recht. Die aktuelle Lattice FPGA Familien ECP3 und MachXO2 können entweder AES (ECP3 auch der kleinste!) oder haben Onchip Konfigurationsspeicher (MachXO2). > Aber auch der unverschlüsselte Bitstream > ist faktisch nicht zu knacken, weil Xilinx (und wahrsch. auch Altera) > die konkrete Umsetzung geheim halten. So super geheim ist das auch nicht, und schon gar nicht unmöglich. Aber darum geht es nicht, Kopierschutz ist viel wichtiger. Auch geht es darum Überprduktion zu verhindern (d.h. der Auftragsfertiger produziert ein paar mehr auf eigene Rechnung) @Abdul Schau dir mal den MachXO2 an, ausser in der kleinsten Version haben diese auch User Flash der sich direkt als Programmspeicher für einen Softcore verwenden lässt.
>> Aber auch der unverschlüsselte Bitstream >> ist faktisch nicht zu knacken, weil Xilinx (und wahrsch. auch Altera) >> die konkrete Umsetzung geheim halten. >So super geheim ist das auch nicht, und schon gar nicht unmöglich. 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. In Verbind. mit Dev-DNA ist das auch Kopierschutz.
Angehängte Dateien:
-
IMGP2397.JPG
230 KB -
IMGP2398.JPG
220 KB
Um mal wieder auf die Anfangsfrage zu kommen: Ich kenne ihn noch. Auf dem Boden habe ich den Commodore KIM 1, selbst eingebaut in ein hübsches Gehäuse. Samt Literatur und Rechnung (Oktober 1978). Das gute Stück funktioniert übrigens noch. Dazu noch etliche Portbausteine 8255 und andere Altlast-ICs an die heute keiner mehr denkt. (vermutlich ist bei uns vor Generationen mal ein Eichhorn mit eingekreuzt worden ;-) ) mfg Dietmar M.
Der AIM65 Rockwell war auch mal ein schönes Gerät mit Drucker, Alphanumerischer LED-Anzeige und einer Schreibmaschienentastertur. Dafür gabs auch mal Assembler und Bausic Compiler wenn nicht sogar mal einen C Compiler. Hatte ihn leider vor 15 Jahren Verkauft.
War das nicht Bill Gates der mal Ende der Achtziger gesagt hatte dass 640 Kb RAM die nächsten 20Jahre ausreicht?
Overflow schrieb: > War das nicht Bill Gates der mal Ende der Achtziger gesagt hatte dass > 640 Kb RAM die nächsten 20Jahre ausreicht? Hatte er auch gesagt, wofür es ausreichen soll? PC? Denn sonst klingt das, wie: Die Rente ist sicher (nur die Höhe nicht). Für meinen persönlichen Bedarf reichen die 640kB aber von heute ab nochmal 20 Jahre. ;-) @Nichts ist zu Alt: Etwa um 1976 las ich Funkschau, dort waren auch z.B. die 8080-Einplatinencomputer drin, bzw. Selbstbauprojekte (wovon ich aber noch nichts verstand). Mann, war das damals kompliziert: Leser wandten sich bei der Fehlersuche mit Leserbriefen an die Zeitschrift, suchten wochen- und monatelang Fehler, das war alles sehr langwierig ohne Internet.
Nichts ist zu Alt schrieb: > Dafür gabs auch mal Assembler und Bausic Compiler Basic Interpreter, Microsoft. > wenn nicht sogar mal einen C Compiler. Einen PL/65-Compiler in 2 ROMs. Weit unter C Niveau. Aber immerhin.
und Forth "DUP DUP SWAP" der AIM war 1979 mein erster richtiger Computer ( nach "Kosmos Logikus" und einem programmierbarem Taschenrechner HP25)
Wilhelm Ferkes schrieb: > noch nichts verstand). Mann, war das damals kompliziert: Leser wandten > sich bei der Fehlersuche mit Leserbriefen an die Zeitschrift, suchten > wochen- und monatelang Fehler, das war alles sehr langwierig ohne > Internet. Es hatte allerdings auch zur Folge, dass man genug Zeit zum Denken hatte. Heute landen viele Fragen nach wenigen Sekunden intensiven aber vergeblichen Nachdenkens bereits im Internet und es dürfen andere Leute weiterdenken.
A. K. schrieb: > Es hatte allerdings auch zur Folge, dass man genug Zeit zum Denken > hatte. Allerdings. Aus der Zeit habe ich auch noch eine Reihe Bücher hier stehen. Man mußte wirklich seinen Hintern in einen Buchladen oder eine Bibliothek schleppen. Heute suche ich mir Info aber auch im Internet, an Büchern ist in den letzten Jahren kaum noch was hinzu gekommen. > und es dürfen andere Leute > weiterdenken. Andere Leute zum Mitdenken hatte man schlicht nicht, weder Nachbarn, noch Bekannte, noch Kollegen, wenn man in einem anderen Beruf arbeitete, man ist als Bastler oft allein auf weiter Flur. Man mußte wirklich selbst denken. Ich selbst suchte vor 20 Jahren an einem ersten Elektor-Board mit Standard-8051 mal geschlagene 3 Wochen nach einem Fehler, wobei die serielle Schnittstelle am Terminal nur Hieroglyphen ausgab. Oszi hatte ich da noch nicht, und es dauerte eine Weile, bis ich wirklich den Quarz wechselte. Die hatten da tatsächlich eine Quarzschaltung drinne, die einen 3.-Oberwelle-Quarz verwendete, mit einer Festinduktivität zur Unterdrückung der Grundwelle. Und das schwang nicht ordentlich. Da ist man als Anfänger schnell ratlos.
Ich weiß nicht so recht, ob Einsamkeit den eigenen Horizont erhellt. Das denken ja viele. Denkt an die Eremiten und Gurus. Hm. Ich persönlich liebe den Kontrast zwischen meiner Hexenküche und dem Leben draußen. Zumal man nur einmal lebt und jede Zeitverschwendung das Ende näher rückt.
Abdul K. schrieb: > Ich weiß nicht so recht, ob Einsamkeit den eigenen Horizont erhellt. Manchmal schon. Beispielsweise kann man Datasheets selber lesen oder lesen lassen. Im Forum gibts öfter welche der zweiten Kategorie.
Lesen heißt nicht unbedingt verstehen - Weisheit eines Forumbenutzers mit Nachname K.
>War das nicht Bill Gates der mal Ende der Achtziger gesagt hatte dass >640 Kb RAM die nächsten 20Jahre ausreicht? Das war auch der, der seine Hardware nicht ans Laufen gebracht hat, und die er deshalb von Anderen beziehen musste.
Im Prinzip würden 640K sicherlich reichen. Ein ähnliches Statement ist übrigens von wohl Steve Jobs für den Mac überliefert. Er wollte nie mehr als 128K einbauen. Aber mit OOP, hunderten inkompatiblen DLLs, NET-Versionen, PHP Phyton, Ruby usw. (die alle letztendlich das Gleiche tun)...
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.
Angehängte Dateien:
-
AIM65_Handbuecher.jpg
800 KB
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.
Angehängte Dateien:
-
IMG_0437.JPG
86 KB
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
Angehängte Dateien:
-
IMG_0434.JPG
44 KB
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
Angehängte Dateien:
-
kim1_04.jpg
230 KB
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.
Thread beobachten
Seitenaufteilung abschalten
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.