Hallo, ich bräuchte für einen Selbstbau-Heimcomputer eine 16-bit-CPU die Zugriff auf externes EEPROM und SRAM bietet bzw. auf einen Backbuffer einer Grafikadapter-Platine etc. Schnell sollte sie auch noch sein denn sie soll einen 64kB @ 8Bit Backbuffer bearbeiten können bei akzeptabler Framerate. Dabei aber nicht zu schnell am Bus denn die EEPROMS sind scheinbar nicht so schnell wie SRAMs. Nach einiger Recherche liebäugelte ich mit einem XA-S3 von NXP, doch scheinbar sind die veraltet bzw. werden nicht mehr lange produziert. Die Renesas R8 und die ARM7 scheint es nur in winzigen SMD-Gehäusen zu geben was mir etwas missfällt, obwohl diese CPUs schneller wären als ein XA-S3. Hat jemand hier den Überblick welche CPU gerade aktuell wäre und gleichzeitig die gewünschten Kriterien erfüllt ? 1) 16 Bit 2) externer Buszugriff 3) schnell 4) lötbares Gehäuse 5) nicht veraltet bzw. Produktionsstop
Und warum muss das eine 16-Bit-CPU sein? ARMe mit 32 Bit gibt es auch mit Deinen Anforderungen "wie Sand am Meer", bis vielleicht auf das "lötbare Gehäuse", aber das liegt dann auch eher an Deinen Lötkünsten bzw. wäre durch Einsatz geeigneter Adapterplatinen umschiffbar. Oh, und warum EEPROMs an den Bus hängen? Welche Aufgabe sollen die erfüllen, die z.B. eine SD-Karte nicht erfüllen könnte?
:
Bearbeitet durch User
H-G S. schrieb: > Dabei aber nicht zu schnell am Bus denn die EEPROMS sind scheinbar > nicht so schnell wie SRAMs. Deshalb nimmt man ja auch serial Flash oder SD und kopiert sie nach dem Reset in den RAM. Warum die Beschränkung auf 16Bit? Nimm einfach irgendnen ARM-Cortex mit externem Bus, der kann wahlweise 8, 16 oder 32Bit breit zugreifen. Muß ja kein BGA sein, es gibt sie auch in lötbarem TQFP. Es gibt auch passende Adapterplatinen von TQFP auf 2,54mm Stiftraster.
Schnell ist relativ, du schreibst leider nichts zum benoetigten Datendurchsatz. Wenn dir 20 MHz CPU-Takt reichen, dann ist der WDC 65C816 vielleicht eine Alternative, der ist noch in Produktion und als PLCC-44 oder DIP-40 erhaeltlich, in Einzelstueckzahlen so um die 5 Eur IIRC. Die CPU hat einen 24 Bit Adressraum, 8 Bit externen Datenbus und es gibt von WDC einen wohl relativ brauchbaren C-Compiler (aber nur fuer Windows). Allerdings ist der als 6502-Nachfahre doch schon etwas angestaubt. Dafuer kann man fuer Performance-Optimierungen seine Assembler-Kenntnisse aus C64-Zeiten vervorkramen (oder einem anderen 6502-Rechner nach Wahl) :-).
Eric B. schrieb: > TI MSP430? NXP (Freescale) HCS12? Beide noch verfügbar als TTSOP... Von den MSPs gab/gibt es afaik keine Variante mit externem (Speicher)-Bus. Ansonsten fallen mir noch M16C von Renesas und div. C166/XE166 von Infineon ein. Letztere gibt es afair mit bis zu 100 MHz, falls QFP-100 u.ä. noch als lötbar gilt.
Der Freescale (jetzt NXP) 68SEC000 (der auch auf dem Minimig FPGA-Board drauf ist) ist auch noch in Produktion, ein "echter" 68000 mit bis zu 20 MHz (3.3/5V) in TQFP64 - dafuer gibt's dann auch deutlich mehr Compiler/OS/Tools usw. Der ist nicht fuer neue Designs empfohlen, aber wohl mit 10 Jahren Lieferversprechen.
Freunde alten Gelumps dürften sich noch am 80186 erfreuen, der im Embedded-Bereich wohl auch immer noch mit zahnlosen Kiefern am Gnadenbrot lutscht.
Peter D. schrieb: > Deshalb nimmt man ja auch serial Flash oder SD und kopiert sie nach dem > Reset in den RAM. Es soll Leute geben die möchten richtigen Arbeitsspeicher in ausreichender Menge so wie ihn die meisten Mikrokontroller in Form von direkt zugreifbaren RAM eben nicht bieten. So habe ich den TO verstanden .....
Mitlesa schrieb: > Es soll Leute geben die möchten richtigen Arbeitsspeicher in > ausreichender Menge so wie ihn die meisten Mikrokontroller > in Form von direkt zugreifbaren RAM eben nicht bieten. Bei den STM32F746 hast du 320 kByte Single Cycle Flash on chip . Und wenn dass nicht langt sind demnächst noch grössere F7 erhältlich. Und bei anderen Herstellern gibt es ähnliches. Auf dem F7 Disco Board gibt es dann nochmals 8 MByte SDRAM.
Mitlesa schrieb: > Es soll Leute geben die möchten richtigen Arbeitsspeicher in > ausreichender Menge Ja, und? Was würde langsames EEPROM am Bus daran ändern? Eben. Drauf verzichten, serielles EEPROM/Flash/SDkarte verwenden, in den richtigen schnellen Speicher kopieren, fertig.
Rufus Τ. F. schrieb: > Eben. Drauf verzichten, serielles EEPROM/Flash/SDkarte verwenden, in den > richtigen schnellen Speicher kopieren, fertig. Na klar, schnell mal ne 128MB SD Karte ins 16K SRAM vom AVR kopieren. Wie konnte das der TO übersehen .... dass das so einfach geht.
Welchen Teil von "richtiger Arbeitsspeicher in ausreichender Menge" hast Du nicht verstanden?
emm schrieb: > Wenn dir 20 MHz CPU-Takt reichen, dann ist der WDC 65C816 vielleicht > eine Alternative Hast wohl einen leichten Hang zum Sadismus. ;-)
EFM32GG990F1024 (Cortex-M4) hat 48MHz Takt, 256kByte RAM, 1024MByte Flash und ein externes Bus-Interface (8, 16 oder 32 bit breit). IDE, Compiler und Entwicklerwerkzeuge sind frei. Blackbird
Danke für die vielen Antworten :-) Ich dachte mir für das Projekt ungefähr folgendes: Eine XA-S3 (ROM-less) CPU hängt an einem 8kB @16 Bit EEPROM das einen Bootcode enthält der aus einem anderen (seriellen EEPROM ?) Speichermedium dann den Code und Daten in ein SRAM lädt welches in den Codebereich (bis 16MB) hineingemapped ist (Harvard-Architektur). Der XA-S3 dürfte noch mit einem 50ns (55 ?) EEPROM funktionieren, das SRAM sollte wohl auch etwa so schnell sein. Ausführungszeit pro Befehl wäre dann ab 100ns gewesen. Als Gehäuse gäbe es das PLCC das ich in einen Sockel setzen würde. Die "Grafikkarte" bestünde aus 2 Bild-Buffern zu je 64kB, einem AD 725 RGB/PAL Konverter und einem schnellen PIC der die Syncsignale für einen AV-Anschluss eines Fernsehers erzeugt. Die Backbuffer werden mit Latches etc. umgeschaltet sodass immer einer an den TV gesendet wird während der andere vom CPU-Bus beschrieben werden kann. Dazu erwägte ich noch eine schnelle Buffer-Löschung mit Hilfe eines schnellen Zählers, der PIC-gesteuert den Buffer einmal füllt mit einer vorher ausgewählten Farbe. Auflösung wäre 288x216 Pixel (durch 8 teilbar und bei gedoppelter Breite und Höhe füllt das wohl recht gut ein PAL-Bild aus). Farbraum wäre das in diesem Forum vorgestellte 256 Farben aus 8 Bit mit R2R-Netzwerk (3x3x2). @ARM CPU: Irgendwas sagt mir dass 32-Bit-Code nicht gesund ist, ich möchte nämlich gerne in Assembler selber programmieren - daher auch meine Wahl einer 16- Bit-CPU. 8 Bit waren einfach zu wenig mit 64kB Adressraum - soviel braucht ja schon der Bildbuffer. @Löten/SMD: Manche lassen sich ja noch recht gut löten, aber Lötfett-Schlamassel liegen mir irgendwie nicht so. Edit: Der "Zilog Z16Fxxx" sieht sehr erfolgversprechend aus, wohl nur 50ns pro Befehl - das klingt zu gut um wahr zu sein ;-) Ich werde mal in die Dokumentation tauchen ...
:
Bearbeitet durch User
H-G S. schrieb: > Hallo, > > ich bräuchte für einen Selbstbau-Heimcomputer eine > 16-bit-CPU die Zugriff auf externes EEPROM und SRAM > bietet bzw. auf einen Backbuffer einer Grafikadapter-Platine > etc. > Schnell sollte sie auch noch sein denn sie soll einen 64kB @ 8Bit > Backbuffer bearbeiten können bei akzeptabler Framerate. Mein Vorschlag: PIC24FJ256DA210 24Bit CPU mit eingebautem Grafik-Controller und 96KByte Ram im 100-Pin TQFP Gehäuse. Externer Bus gibt es noch gratis dazu. Kannst du als Sample bei Microchip beziehen.
:
Bearbeitet durch User
H-G S. schrieb: > Ich dachte mir für das Projekt ungefähr folgendes: Das sieht mir so aus, wie meine Projekte vor rund 30 Jahren, wo man für ein MB RAM noch ein halbes Königreich bezahlen mußte. Warum willst du denn nicht was Neueres nehmen? ich würde dir zu nem LPC4088 im 208er Gehäuse raten, dazu nen 32 bittigen SDRAM zu 4 oder 8 oder 16 MB und du hast genug von allem: Platz, Grafik, MHz. Lediglich die LP zu routen ist für nen Einsteiger ne Herausforderung. Aber da ich sowas seit Jahren im Regal liegen habe, könnte ich es posten - wenn von dir ausreichendes Interesse bekundet wird. W.S.
H-G S. schrieb: > @ARM CPU: > Irgendwas sagt mir dass 32-Bit-Code nicht gesund ist, ich möchte nämlich > gerne in Assembler selber programmieren - daher auch meine Wahl einer > 16-Bit-CPU. > 8 Bit waren einfach zu wenig mit 64kB Adressraum - soviel braucht ja > schon der Bildbuffer. 32-Bit-Code gibt's auch in schön: Guter alter 68k 1) oder Renesas RX. Der Siemens (irgendwas war noch mit ST) C166 Befehlssatz ist ebenfalls gut lesbar und den anderen genannten nicht unähnlich. Alle sind bei größeren Sachen deutlich besser lesbar als das 8-Bit/16-Bit-8051/XA-Zeug 1) auch in schnell für's FPGA http://www.apollo-core.com/index.htm > Der "Zilog Z16Fxxx" sieht sehr erfolgversprechend aus, > wohl nur 50ns pro Befehl - das klingt zu gut um wahr zu sein ;-) > Ich werde mal in die Dokumentation tauchen ... Dann lieber C166/XE166 (siehe oben).
@PIC24F: TQFP klingt nicht gut um es zu löten. @LPC4088: 208er Gehäuse klingt auch nicht so gut. @XE166: Scheinen Automotive- etc. Chips zu sein mit zuviel unnötigem Schnickschnack, LQFP-100. Haben die überhaupt einen externen Bus ? Überhaupt schrecken mich die All-in-one-Controller etwas ab, da ich keinen A/D-Wandler oder ähnliche Module brauche.
Abgesehen von einen Retrodesign, was soll das Ganze ? 16bit CPU, Eprom, PAL Ausgang ? Abgeshen, dass auch eine moderne 8Bit CPU soviel Dampf hat wie vor 30 Jahren eine 16bitter, steuert man doch heutzutage eher einen Grafik LCD an. Fuer eine 320x240 LCD wuerde ich fuer fluessigen Aufbau eher eine 32bit CPU empfehlen.
> 32-Bit-Code gibt's auch in schön: Guter alter 68k 1) oder Renesas RX. Ich wuerde auch empfehlen sich da bei Renesas umzusehen. Ich hab da schon die R32 und SH2 programmiert. Am R32 hatte ich auch externes Ram. Die SH2 hatten soviel internes Ram das es praktisch nicht moeglich ist das voll zu bekommen. Es gab da unmengen an Konfigurationsmoeglichkeiten bezueglich gewuenschter Busbreite und Waitstates. Fuer Grafiksachen hat Renesas auch Controller mit bergeweisen internen Ram, Dualport Ram und Interface zu Controllern. Da schiebt der DMA im Hintegrund den Displaybuffer raus und die CPU laeuft einfach mit 200-400Mhz weiter ohne gebremst zu werden. Und ein SH2A z.B hat 16 Registerbaenke die er in einem Befehl umschalten kann. Der hat eine Interruptroutine bereits wieder verlassen wenn so ein armseliger ARM noch Register auf den Stack push. Allerdings solche Controller in Assembler programmieren? Das ist doch wohl ein Witz. Nicht das es grundsaetzlich nicht ginge, aber wie soll man da den Ueberblick behalten bei den ueblichen Anwendungen die man auf solchen Controllern macht. Dann kommt noch hinzu das diese Controller superskalar sind. Sie fuehren also mehrere Assemblerbefehle gleichzeitig aus wenn der Compiler den Code richtig erzeugt. Sowas will man nicht von Hand machen. > Fuer eine 320x240 LCD wuerde ich fuer fluessigen Aufbau eher eine 32bit > CPU empfehlen. Kommt drauf an was man macht. Ich hatte genau so ein Display an einem R32 mit 50Mhz Takt. War fuer eine Messtechnikanwendung voll ausreichend. Natuerlich wenn man Videos kucken will reicht das nicht mehr! Und nicht nur auf die Megaherz schauen! Auch mal pruefen wieviel Waitstates der Controller einlegen muss. Oder wie gross der interne Cache ist. Da bekleckern sich die ST32 auch nicht unbedingt mit Ruhm. Olaf
Der MC68VZ328 Dragonball wird noch (aber nicht mehr lange) produziert, hat eine eingebaute Framebuffer Hardware und alles, was man sonst so von der M68k Familie gewohnt ist. Lief im Palm 5 und gibts auch auch unter uCLinux. http://www.nxp.com/pages/dragonball-vz-integrated-processor:MC68VZ328
:
Bearbeitet durch User
Das ist doch alles Unsinn. Neben der offensichltichen Anforderung, ein externes Bus-Interface zu besitzen ist die zweite Anforderung, daß es Programmierwerkzeuge (neudeutsch: eine Toolchain) geben muß. Das wäre mindestens ein Makro-Assembler, besser ein C-Compiler. Im Idealfall auch noch Pascal, BASIC, Fortran etc. Ob es dann ein 8-, 16- oder 32-Bitter wird, muß man sehen. Aber natürlich gibt es 8-Bitter mit mehr als 16-Bit Adreßraum. Und schnell sind die auch. Wenn man sich auf etwas Z80-kompatibles einschießt, hat man das Problem der Toolchain gleich mit gelöst. Ganz davon zu schweigen was man an existierendem Code bekommt. Und an Emulationswerkzeugen. 68000er sieht ähnlich gut aus. 80x86 ist dann eher für Masochisten ;)
H-G S. schrieb: > Hallo, > > ich bräuchte für einen Selbstbau-Heimcomputer eine > 16-bit-CPU die Zugriff auf externes EEPROM und SRAM > bietet bzw. auf einen Backbuffer einer Grafikadapter-Platine > etc. > Schnell sollte sie auch noch sein denn sie soll einen 64kB @ 8Bit > Backbuffer bearbeiten können bei akzeptabler Framerate. > Dabei aber nicht zu schnell am Bus denn die EEPROMS sind scheinbar > nicht so schnell wie SRAMs. > Hat jemand hier den Überblick welche CPU gerade aktuell wäre > und gleichzeitig die gewünschten Kriterien erfüllt ? > > 1) 16 Bit > 2) externer Buszugriff > 3) schnell > 4) lötbares Gehäuse > 5) nicht veraltet bzw. Produktionsstop FPGA mit 16 bit core deiner Wahl, handlötbares Gehäuse könnte aber schwierig werden.
> Der MC68VZ328 Dragonball wird noch (aber nicht mehr lange) produziert,
Oh..man. Hab auch schon verwendet. Genauer gesagt 68332. Aber hey die
Dinger sind steinalt und waren fruher auch mal nicht schlecht. Aber
sowas nimmt man doch nicht mehr fuer ein neues Projekt. Mal abgesehen
davon das die Rechenleistung vielleicht etwas zu bescheiden ist wenn es
ueber die 160x160 Pixel eines Palm hinausgeht.
Olaf
@Grafik-LCD: Das war auch mein erstes Konzept. Aber als ich mir die Displaygrößen (5 Zoll bei 640x480), Größe des Bildspeichers (300kB...), Ansteuer-Clockrate etc. ansah stellte sich das als total unbrauchbar heraus. Ich wollte schliesslich eine Art Heimcomputer zum Spass- Programmieren und nicht ein Laptop-ähnliches Ding mit Mini-LCD. HDMI fiel auch aus da man dafür extreme Clockraten braucht. Daher bleibt nur noch die gute alte PAL-4:3-Fernseher Lösung mit 256 Farben und 64kB-Bildspeicher. @Renesas: Ich würde gerne etwas nachhaltiges bauen und nicht einen Automotive/überladenen Spezial-Controller nehmen der in ein paar Jahren nicht mehr hergestellt wird. Die "Grafikkarte" soll auch eine Platine mit einem einfachen Anschluss an den Adress- und Datenbus mit ein paar Steuerleitungen werden. Daher ja auch die Forderung nach externem EEPROM und SRAM. 400 MHz klingt zwar verdammt gut und nach hunderten (tausenden ?) Sprites gleichzeitig am Bildschirm aber ich vermute man muss dann die Leiterbahnen auf der Platine extrem gut entwerfen und auch das EMV-Problem ist ja auch noch da. @Filme abspielen: Ich dachte eher an Anwendungen/Spiele im alten 8/16-Bit-Stil wobei die Farbpalette von 256 Farben das Ganze noch mehr vereinfacht. Wie soll ich denn grafischen Inhalt mit 16 Bit Farbtiefe erstellen ? @Softwaretools: Ich plane komplett ohne Hilfsmittel bzw. ohne Benutzung eines PC auszukommen. Das sollte eigentlich zu schaffen sein, das Projekt ist ja zum Austoben gedacht, da kann ich schon ein bisschen mehr Programmieren.
:
Bearbeitet durch User
H-G S. schrieb: > @Softwaretools: > Ich plane komplett ohne Hilfsmittel bzw. ohne Benutzung > eines PC auszukommen. Das schaffst du ja schon nicht bei der Suche nach der passenden CPU und beim lesen der Antworten.
Wo soll das PAL Signal denn hin? Ich wuesst nichts mehr wo man das einspeisen koennte. Also in einen neuen Monitor nicht mehr. Da hat man Glueck wenn, und wie lange, die noch VGA koennen. Was spricht denn gegen einen "mikromedia for PIC32" von Mikroelektronika : http://www.mikroe.com/mikromedia/pic32/ fuer 99 Dollar. "Large 320x240 TFT Color Display with Touch Screen and Stereo MP3 Codec chip.." "PIC32MX460F512L is an exceptional 32-bit MCU. 80MIPS power, hardware multiplier and divider, DMA controller .."
Ein schönes Thema für einen regnerischen Wintertag ;-) H-G S. schrieb: > 8 Bit waren einfach zu wenig mit 64kB Adressraum - soviel braucht ja > schon der Bildbuffer. Mit 8 Bit kannst Du gerade einmal 256 Byte adressieren und mit 16 Bit 65536. Erst mit 32 Bit Registerbreite fängt es an, Spaß zu machen, ohne sich mit irgendeiner Segmentierung plagen zu müssen. Eine 68k CPU paßt noch in eine DIL/PLCC-Fassung, ist aber heutzutage zu langsam. Wenn man ähnlich bequem in Assembler programmieren möchte, bieten sich H8S, H8SX oder auch RX-Controller an. Da sind die Grenzen zwischen 8 - 32 Bit schwimmend und Letztere sind von der Hardware sehr 'elegant'. Für Deinen Bedarf reicht vielleicht schon ein RX210. H-G S. schrieb: > @Löten/SMD: > Manche lassen sich ja noch recht gut löten, aber Lötfett-Schlamassel > liegen mir irgendwie nicht so. Nimm Flußmittel und Entlötlitze; damit klappt es. H-G S. schrieb: > Ich dachte eher an Anwendungen/Spiele im alten 8/16-Bit-Stil > wobei die Farbpalette von 256 Farben das Ganze noch mehr > vereinfacht. Ein paar Beispiele auch mit H8SX und RX: http://mino-elektronik.de/TFT-direct-drive/TFT-direct-drive.htm
> @Softwaretools: Ich plane komplett ohne Hilfsmittel bzw. ohne Benutzung eines PC auszukommen. Also das Codeflash per Hex Eingabe Switch programmieren nachdem der Code aus ASM und nachschlagen in Instruction Manual decodiert wurde? Unter diesen Bedingungen wuerd ich mich mit etwas Einfacherem, zB einer LED, die etwas blinkt zufrieden geben.
H-G S. schrieb: > @XE166: > Scheinen Automotive- etc. Chips zu sein mit zuviel unnötigem > Schnickschnack, LQFP-100. > Haben die überhaupt einen externen Bus ? Ja. Z.B. der XE164F, XE164FN, XE167F. Von ST könnte es auch noch welche geben. > Überhaupt schrecken mich die All-in-one-Controller etwas > ab, da ich keinen A/D-Wandler oder ähnliche Module brauche. Die müssen nicht zwingend verwendet werden... Olaf schrieb: > Mal abgesehen > davon das die Rechenleistung vielleicht etwas zu bescheiden ist wenn es > ueber die 160x160 Pixel eines Palm hinausgeht. Was damals überwiegend am "OS" von Palm bzw. dessen Routinen lag, als am 68k. Siehe nicht nur die div. Demos für den Atari ST. Etwas OT: SH-Cores, z.Z. den SH-2, gibt es mittlerweile als Open Source: http://0pf.org/j-core.html
H-G S. schrieb: > 1) 16 Bit > 2) externer Buszugriff > 3) schnell > 4) lötbares Gehäuse > 5) nicht veraltet bzw. Produktionsstop M16C/30. Ich halre das 100er Flatpack durchaus für lötbar mit Hobbymitteln. Ist softwaretechnisch quasi ein Motorola 68000er. Der Nachteil, schwache 2mA Ausgänge die nur Portweise in der Richtung schaltbar sind, ist für dich wohl egal.
H-G S. schrieb: > @Renesas: > Ich würde gerne etwas nachhaltiges bauen und nicht einen > Automotive/überladenen Spezial-Controller nehmen der > in ein paar Jahren nicht mehr hergestellt wird. Mal auf der Renesas Longevity Program-Seite nachgesehen? Bspw. sind etliche RX63N im PLP: Date of PLP Termination 1): März 2035. Bis dahin dürfte es eher die anderen verbauten Komponenten nicht mehr geben. 1) http://www.renesas.com/support/plp/ "A PLP product is managed under a special product life cycle for the duration that it participates in the program. Renesas Electronics strives to maintain supply of a PLP product for the duration that it participates in the program. Following the termination of a product's participation in the PLP, life cycle management for the product will be carried out as a regular product." > gleichzeitig am Bildschirm aber ich vermute man muss dann > die Leiterbahnen auf der Platine extrem gut entwerfen und > auch das EMV-Problem ist ja auch noch da. Das ist auch ein Vorteil der Renesas Controller. Da ist die Pinbelegung meist sehr gut und entsprechend gut routebar im Gegensatz zu bspw. STM32, PIC32MZ und anderen bei denen die Pinbelegung nicht nur wie völlig zufällig ausgewürfelt aussieht.
> M16C/30. Ich halre das 100er Flatpack durchaus für lötbar mit > Hobbymitteln. Mal abgesehen davon das man alles loeten kann wenn man sich ein bisschen anstrengt, wenn man nun garnicht will dann nimmt man einfach ein Entwicklungsboard mit DIP-Anschluss an den Seiten und tut so als wenn das ein dickes IC waere. Ansonsten finde ich die M16C natuerlich auch super. Wuerde ich zwar fuer ein neues Projekt auch nicht mehr verwenden, aber wenn man unbedingt will dann sind sie schon nett. Man muss sich mal klar machen das die vor 15Jahren schon an Peripherie eingebaut hatten was man heute so bei einem STM32F103 erwartet/kennt. Das war zu Zeiten als die Bastler bei uns dachten das ein Mega8 cool sei... Mir waere es ja auch egal, aber M16C kommen wegen ihrer langen Geschichte auch gut mit 5V klar. Ausserdem mag es ja sein das sie in Deutschland ausserhalb der Industrie nicht so bekannt sind, in Japan werden sie aber auch gerne von Bastlern genutzt. Deshalb haben sie eine gute gcc Unterstuetzung. (und die SH2 auch) Olaf
H-G S. schrieb: > Eine XA-S3 (ROM-less) CPU hängt an einem 8kB @16 Bit EEPROM das einen > Bootcode enthält der aus einem anderen (seriellen EEPROM ?) > Speichermedium dann den Code und Daten in ein SRAM lädt > welches in den Codebereich (bis 16MB) hineingemapped ist > (Harvard-Architektur). Nunja, das sind deine persönlichen Vorlieben. Ob das sinnvoll ist oder nicht, hängt aber natürlich vom konkreten Problem ab, was mit dem Computersystem gelöst werden soll. Dir schwebt wohl so eine Art PC für Arme vor, sowas wie die Homecomputer der 80er und frühen 90er Jahre des letzten Jahrhunderts. Tja, die gab es, sie waren zeitweilig recht erfolgreich, heute sind sie de facto ausgestorben. Mit gutem Grund: "Richtige" PCs haben ihnen von oben her das Wasser abgegraben, mit mehr Rechenpower, mehr Speicher und durch die massenhafte Produktion geringeren Kosten. Und von unten her drangen die Mikrocontroller leistungsmäßig in die früheren Anwendungsbereiche der Homecomputer vor. Dazwischen gibt es de facto heute keine Lücke mehr, in der ein proprietäres 16Bit-System überleben könnte. DESWEGEN gibt es praktisch auch keins mehr! Wenn du das nicht akzeptieren kannst, stimmt irgendwas bei dir im Kopf nicht, dann bist du einer der typischen Ewiggestrigen. > @ARM CPU: > Irgendwas sagt mir dass 32-Bit-Code nicht gesund ist, ich möchte nämlich > gerne in Assembler selber programmieren So what? ARM ist ein recht dankbares ASM-Target. Man muss eigentlich nur die (möglicherweise verschiedenen!) Asm-Sprachen der in Frage kommenden Targets lernen. Reine Fleissarbeit. Aber das ist Asm-Programmierung ja sowieso. Wenn du zu faul dazu bist, bist du auch kein Asm-Programmierer. Also: No mercy. > - daher auch meine Wahl einer > 16- > Bit-CPU. > 8 Bit waren einfach zu wenig mit 64kB Adressraum - soviel braucht ja > schon der Bildbuffer. OMG. Noch nie war die Verarbeitungsbreite der ALU einer CPU zwingend an die Addressbusbreite des RAMs gekoppelt. Wäre es so, dürften 8Bit-Cores ja nur 256 Bytes addressieren können... Tatsächlich gibt es aber einerseits 8Bit-Cores, die bis zu 24MByte RAM ohne Bank-Switching addressieren können, andererseits aber auch 32Bit-Rechenknechte, für die bei 16kByte RAM Schicht ist, mehr ginge nur mit Bankswitching (oder sinnvoller: der Wahl eines anderen Controllers derselben Familie). Zusammenfassend: Du bist unfähig oder unwillig, irgendetwas zu dem hinzuzulernen, was du vor 25..30 Jahren mal wußtest. Das geht nicht gut aus. Das ist schlimmer als geplante Obsoleszenz, das ist pränatale Obsoleszenz, soweit es die möglichen Produkte deines Wirkens betrifft. Bezogen auf dich selber ist es wohl einfach nur Altersstarrsinn... Tipp: Such dir ein Hobby in einem Bereich, was nicht so sehr vom technischen Fortschritt betroffen ist, wo man nicht dauernd was neues lernen muss.
MaWin schrieb: > M16C/30 Hm... hat der nicht 64 kByte Segmente? IMHO gibts zwar einen longjmp, aber beim Datenzugriff muss man das Segmentregister setzen. Und das willst du in Assembler programmieren? Na dann, viel Spaß. Bevor du dich auf ein 16-Bit Abstellgleis begibst, programmiere doch erst mal einen Corex-Mx in Assembler. Ich finde den Thumb2 Befehlssatz gar nicht schlecht, zudem die meisten Befehle in 16-Bit codiert sind. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439b/CHDDIGAC.html
H-G S. schrieb: > @LPC4088: > 208er Gehäuse klingt auch nicht so gut. Ja was? Du suchst doch wohl nicht nen IC mit nur 3 Beinen, der damit nen externen Bus, Farbgrafik und externes RAM bedient? H-G S. schrieb: > @Softwaretools: > Ich plane komplett ohne Hilfsmittel bzw. ohne Benutzung > eines PC auszukommen. > Das sollte eigentlich zu schaffen sein, das Projekt ist ja zum > Austoben gedacht, da kann ich schon ein bisschen mehr > Programmieren. Das ist zuviel für meine Seele. AnDenKopfGreif... W.S.
W.S. schrieb: > H-G S. schrieb: >> @Softwaretools: >> Ich plane komplett ohne Hilfsmittel bzw. ohne Benutzung >> eines PC auszukommen. >> Das sollte eigentlich zu schaffen sein, das Projekt ist ja zum >> Austoben gedacht, da kann ich schon ein bisschen mehr >> Programmieren. > > Das ist zuviel für meine Seele. AnDenKopfGreif... http://retrobsd.org/wiki/doku.php "Development system on-board. It is possible to have C compiler in the system, and to recompile the user application (or the whole operating system) when needed." Allerdings für PIC32... Auf der RetroBSD-Seite sind auch Module verlinkt, welche so ziemlich die Anforderungen erfüllen würden... DTX2-4105C http://dimitech.com/products.php PIC32MX795 mit dem Rest zum Betrieb im PLCC-68-Format ;)
klausr schrieb: >> M16C/30 > > Hm... hat der nicht 64 kByte Segmente? IMHO gibts zwar einen longjmp, Das ist doch kein Infineaon C166 / C167 JMP und JSR sind 20 bit (voller Adressbereich), relative Jumps 16 bit. Datenzugriffe sind 16 bit und erreichen damit bevorzugt RAM in den ersten 64k, oder 16 bit relative zu einem anderen Register wie dem Stackpointer.
Hallo, Ich suche eine 16 oder 32 Bit CPU/Controller mit externem Bus (Code+Daten). Das Teil sollte etwas flotter sein aber auch nicht zu flott damit ich nicht mit EMV/Layout Probleme bekomme (erstes größeres Projekt). Und es sollte unbedingt noch lötbar sein, ich dachte da an SOP (1,27mm Raster) oder Ähnliches. Hat jemand Vorschläge ? PS: weiss jemand ob es schnelleres Standard-EEPROM als 55ns gibt ?
H-G S. schrieb: > Ich suche eine 16 oder 32 Bit CPU/Controller mit externem Bus H-G S. schrieb: > Und es sollte unbedingt noch lötbar sein, ich dachte da an SOP (1,27mm > Raster) oder Ähnliches. Das wird nicht gehen. 32 Bit Daten, mindestens 40 bit Adressen und was sonst noch so dazu kommt geht nicht mehr in ein SOT-Package. TQFT o.ä. hat Rastermasse von 0,6 oder 0,5 mm, daran wirst du dich gewöhnen müssen. 80286 usw. sind nicht mehr zeitgemäss, und lötbar sind sie auch nicht direkt. Georg
H-G S. schrieb: > Das Teil sollte etwas flotter sein aber auch nicht zu flott Das sind natürlich super konkrete Angaben :-( Schonmal was von MIPS oder FLOPS gehört? Oder sag wenigstens, was Du damit machen willst.
Ich brauche die CPU für das "Mainboard" eines Selbstbau-Computers. Er soll eine selbstgebaute Grafikkarte mit 64kB Bildpuffer beschreiben, neben den ganzen I/O-Aufgaben. Ich dachte der Bus-Speed sollte gängigen/verfügbaren EEPROMs und SRAMs entgegenkommen. Ich sah dass schnelles SRAM irgendwie schwer oder nur als teueres Dualport-RAM zu bekommen ist. Deswegen würde ich den Bildpuffer als 55ns-SRAM bauen, da ich scheinbar nicht so einfach schnelleres SRAM in der nötigen Organisation beziehen kann. Es scheint wohl am günstigsten zu sein die 64kB als 2x32kB Bit zu organisieren damit ein schneller Zugriff über einen 16-Bit Datenbus erfolgen kann. Die Taktfrequenz der CPU sollte wohl nicht 50MHz übersteigen, wobei ich sah dass ein 20MHz Z16F auch schon sehr flott ist: 50nS je 1-CLK-Instruktionen. Das würde ungefähr genügen, aber der Z16F kann über den externen Bus scheinbar keinen Code ausführen ...
H-G S. schrieb: > Er soll eine selbstgebaute Grafikkarte mit 64kB Bildpuffer beschreiben Das kann man auch mit 'nem 8-Bit-Prozessor, wenn man den Bildpuffer in mehreren Häppchen in den Adressraum einblendet und mit einer "Bank-Select-Logik" umschaltet. Sicher, so etwas ist dann zwar vermutlich etwas langsamer, aber Retro wäre es auf jeden Fall. Ein Beispiel für so etwas wurde in den 80ern mal als Selbstbauprojekt für ein Graphikterminal in der c't veröffentlicht - das Ding nannte sich "Grip" und verwendete einen Z80 als steuernden Prozessor. Das ist das Handbuch davon, mit Schaltungsbeschreibung: https://www.yumpu.com/de/document/view/21236004/graffik-interface-prozessor-handbuch-conitec-prof80 Das Teil konnte auch eine Speichererweiterung bekommen, um Farbgraphik zu erzeugen.
> Ich sah dass schnelles SRAM irgendwie schwer oder nur als teueres > Dualport-RAM zu bekommen ist. Bei ebay gibts 32kx8 SRAM mit 10/15ns nachgeworfen. Bei Digikey kostet ein 512kx8 mit 10ns dreieurofuffzig oder so. Gibts auch mit 16bit Breite als 256kx16. Auch nicht teurer.
> Nein nicht 80187 sonder eher 80186.
Genau den meinte ich. War aber ein Scherz, so olle Kamellen sollte man
in neuen Designs nicht mehr verwenden.
Dem Threadstarter geht es offensichtlich nicht um ein neues Design, sondern um "Retro Computing". Wer heute noch parallele EEPROMS und SRAMs an einen Prozessorbus hängen will, und das alles bevorzugt im DIP oder sehr groben 0.05"-SMD-Raster, der ist eindeutig auf "Retro" aus. Insofern ist ein '186 durchaus passend.
Mich hatte der 80186 damal gereizt, weil man Programmteile relativ komfortabel auf dem PC austesten konnte, bevor man sie auf den "Mikrocontroller" portiert.
Ich bräuchte eine CPU die Code nachladen kann und schnell Daten in einen externen Bildpuffer schreiben kann.
H-G S. schrieb: > Ich bräuchte eine CPU die Code nachladen kann und schnell Daten in einen > externen Bildpuffer schreiben kann. Welche CPU kann das nicht?
Rufus Τ. F. schrieb: >> Ich bräuchte eine CPU die Code nachladen kann > > Welche CPU kann das nicht? Die CPU eines µC mit ausschliesslich Flash als Programmspeicher kann es schlecht bis überhaupt nicht.
:
Bearbeitet durch User
Also Retro, aber schnell und wenig Pins (THT) und 16-Bit-Speicherinterface ...? Mouser sagt: gibt es nicht. Geht auch nicht! 20MHz, 64 DIP, 20-Bit Adress - 8-Bit Dateninterface : Z8S180 Ansonsten: 32-Bit-CPU, 40-DIP, Externes EEProm, welches in RAM geladen wird, Videointerface, 8-Kerne: Propeller *Edit:* Speicher-IF muss dann ein Core übernehmen ... Gruß Jobst
:
Bearbeitet durch User
Jobst M. schrieb: > 20MHz, 64 DIP, 20-Bit Adress - 8-Bit Dateninterface : Z8S180 Im 48poligen DIP mit 20-Bit Adressen, 8-Bit Daten aber nur geringerem Takt gibt* es noch den 68008. *) antiquarisch, hergestellt wird der schon seit 20 Jahren nicht mehr. Einer der Gründe für den Flop des Sinclair QL dürfte die Entscheidung gewesen sein, darin den 68008 zu verbauen.
Rufus Τ. F. schrieb: > > > *) antiquarisch, hergestellt wird der schon seit 20 Jahren nicht mehr. > Einer der Gründe für den Flop des Sinclair QL dürfte die Entscheidung > gewesen sein, darin den 68008 zu verbauen. ...ich denke eher die "rasenden Schnürsenkel"... Gruß, Holm
Holm T. schrieb: > ...ich denke eher die "rasenden Schnürsenkel"... Die waren der andere Grund. Was fürn Scheiß!
Angehängte Dateien:
-
microd.JPG
36 KB
Ihr meint die? Och, im Vergleich zu Musikcasetten waren die doch sehr angenehm.
> *) antiquarisch, hergestellt wird der schon seit 20 Jahren nicht mehr.
Einer der Gründe für den Flop des Sinclair QL dürfte die Entscheidung
gewesen sein, darin den 68008 zu verbauen.
Der 68008 war schnarch langsam da er die langen 68K Opcodes durch den
8bit Datenbus quälen musste.
Ich habe im youtube-Video von Stefan Noack (Building an 8-Bit COmputer from Zero) gesehen dass er auch Probleme hatte eine CPU mit externem Bus zu finden für sein Projekt. Er hat schliesslich einen dicken EZ80 gewählt und ihn auf ein Adapterboard gefunzelt. Aber das wollte ich eigentlich vermeiden. So schlecht scheint der XA-S3 im Nachhinein betrachtet gar nicht zu sein, vielleicht reichen ja 100/200 ns Ausführungszeiten.
Es scheint man kriegt die XA-S3 und die 80C166 nur noch als Import oder teuer über ebay. Kennt jemand vielleicht einen ARM-Prozessor der soetwas wie einen externen Bus ansteuern kann und nicht zuviele Pins hat ? Mittlerweile habe ich mich damit abgefunden evtl. mit 0,5mm Pins herumzulöten :-)
Die Idee einen eigenen Computer zu bauen mit eigener Software hatte ich auch schon länger. Hin und wieder bastle eich auch Retro-artige Geräte. Deshalb finde ich dieses Video auch so passend zum Thread: https://www.youtube.com/watch?v=xO9ppicjlFg
Sowas: ich habe mir nochmal den Z16F angesehen und es besteht evtl. die Möglichkeit dass er doch Code aus dem externen Speicher und auch aus dem internen Speicher ausführen kann.
> Der 68008 war schnarch langsam da er die langen 68K Opcodes durch > den 8bit Datenbus quälen musste. Verglichen mit was? Ich hatte die MC68008 Karte in meinem ][+ und konnte so on the fly zwischen Z80, 6502 und 68008 umschalten. Ich fand den 68008 garnicht so schlecht. Allerdings hatte ich den um eigenes 32k Ram erweitert wo das DTACK schneller kam als vom Apple-Bus. Und wenn man bedenkt das man damals ja wirklich noch in Assembler programmiert hat, dann war der 68k ja wohl eine goettliche Freude im vergleich zu den beiden anderen. Olaf
H-G S. schrieb: > Kennt jemand vielleicht einen ARM-Prozessor der soetwas wie einen > externen Bus ansteuern kann und nicht zuviele Pins hat ? Was ist nicht zu viele? Ab 100 Pins findet man fast von jedem Hersteller etwas. Unter 100 Pins kenne ich keinen ARM mit 16-bit Businterface.
Ja, die vielen Pins sind schon seltsam ... es bräuchte ja eigentlich nur etwa 24 Adressleitungen und 16 Datenleitungen und ein paar Steuersignale. Das zeigt mal wieder dass diese Automotive-/Motortreiber-Controller irgendwie für mein Projekt nicht geeignet sind :-) Ich habe mich mal bei Zilog angemeldet und warte ab ob sie mich freischalten. Dann frage ich den Support ob und wie schnell ich externes Code- und Datenram ansteuern kann. Eventuell kann ich in das Flash des Z16F einen Bootloader brennen der dann von einem "Massenspeicher" Code und Daten in ein externes SRAM lädt und startet.
> Ja, die vielen Pins sind schon seltsam ... Bei Microcontrollern erwarten die Leute nunmal eine gewisse Menge an Funktionalitaet und damit Chipflaeche. Die gibt dann die Gehaeusegroesse vor. Ob das Gehaeuse dann noch 50 oder 100 IO-Leitungen hat spielt da keine grosse Rolle mehr. > Dann frage ich den Support ob und wie schnell ich externes Code- und > Datenram ansteuern kann. Prima, auf so Fragen warten sie jeden Tag. Anstatt zu warten waere es aber vielleicht einfacher im jeweiligen Datenblatt nachzuschauen. Olaf
Olaf schrieb: > Ich hatte die MC68008 Karte in meinem ][+ Das kitzelt die Neugierde des Archäologen in mir. Wie hiess dieses Produkt/Bausatz/Bauanleitung?
Nimm halt ein FPGA auf ner Adapterplatine verlötet, da kannst du deinen Wunschprozessor draufladen. Kostet 10€ und gut ist.
H-G S. schrieb: > Ja, die vielen Pins sind schon seltsam ... es bräuchte ja eigentlich nur > etwa 24 Adressleitungen und 16 Datenleitungen und ein paar > Steuersignale. Jetzt packst du zu deinen 40 Pins noch 12 Steuerleitungen, 10 Pins für die Versorgung, Reset, Takteingang. Dann bist du schon bei 64 Pins. Das nächste übliche lötbare Gehäuse hat 100 Pins. Jetzt musst du dich nur fragen, wie viele Anwendungen es wohl gibt, bei denen man ein Businterface + sehr wenige Pins braucht. Um es kurz zu machen: So was braucht heute eigentlich niemand mehr. Über das Businterface kommt gewöhnlich Ram/Rom dran. Und damit alleine kann man nicht viel anfangen. Torben K. schrieb: > Nimm halt ein FPGA auf ner Adapterplatine verlötet, da kannst du deinen > Wunschprozessor draufladen. Kostet 10€ und gut ist. Die Adapterplatine kostet 10€. Der FPGA je nach Wunschprozessor 20€-xxx€. Und jetzt zeig mir erstmal einen FPGA mit maximal 64 Pins, genug Zellen für einen ARM-Core und Gehäuse ohne Massepad/Balls. Das gibt es wahrscheinlich auch nicht.
H-G S. schrieb: > Ja, die vielen Pins sind schon seltsam ... es bräuchte ja eigentlich nur > etwa 24 Adressleitungen und 16 Datenleitungen und ein paar > Steuersignale. Ob ein 8085 8 Datenbit multiplext, oder ein Z8002 oder 8086 16 Datenbits, das spielt für die Anzahl Pins kaum eine Rolle. Weshalb die mit 40 Pins auskamen. Nur die Pins für Byteselektion kommen dazu. Beim Z8001 waren es mehr Adressleitungen und deshalb DIL-48.
> Die Adapterplatine kostet 10€. Der FPGA je nach Wunschprozessor > 20€-xxx€. Und jetzt zeig mir erstmal einen FPGA mit maximal 64 Pins, > genug Zellen für einen ARM-Core und Gehäuse ohne Massepad/Balls. Das > gibt es wahrscheinlich auch nicht. Die kleinsten Boards (FPGA & Oszillator) auf Adapterplatine kommen ab 10€ aus China (EP2C5, 4600 LEs). Für 20€ kommt schon ein EP4CE6 (6272 LEs) in selber Manier. Wieviel LEs braucht ein ARM Core? Wobei, ARM war keine Anforderung.
> Das kitzelt die Neugierde des Archäologen in mir. > Wie hiess dieses Produkt/Bausatz/Bauanleitung? http://www.appleii-box.de/H061E_MC68008pageEN.htm Heutzutage findet man alles im Internet. :-) Olaf
Torben K. schrieb: > Die kleinsten Boards (FPGA & Oszillator) auf Adapterplatine kommen ab > 10€ aus China (EP2C5, 4600 LEs). Für 20€ kommt schon ein EP4CE6 (6272 > LEs) in selber Manier. Wieviel LEs braucht ein ARM Core? Wobei, ARM war > keine Anforderung. ARM-Core braucht zwischen 2-3k Zellen. Und der Core ist sehr kompakt. Irgendwelche Spezialprozessoren brauchen vermutlich mehr. Aber fertige Boards aus China war nicht wirklich die Anforderung. Abgesehen, davon wie die Chinesen es schaffen Boards zu einem Preis anzubieten zu dem man das IC nicht einmal bekommt, bekommt man für ~10€ auch ein STM32F4-Discovery. Erfüllt bis auf das Format Eval-Board alle Anforderungen.
Na dann wurden dem TO ja genügend Möglichkeiten aufgezeigt und er kann seine 16bit CPU mit externem Bus auswählen :)
Also mit 0,5mm Pitch wächst die Anzahl der CPUs nochmal etwas an, aber wirkliche Knaller sind da auch nicht dabei. Denn alles in der Größe wird dann ehr ein Controller, welcher allerdings internen Flash besitzt, aus dem er arbeitet. Bei dem PIC32 mit EBI bin ich mir nicht sicher, ob er hieraus Code ausführen kann. Allerdings sind die neueren Modelle mit 200MHz auch durchaus in der Lage ein eigenes Videobild zu produzieren. Einfach einen DMA-Kanal Daten mit beliebiger Rate aus dem Parallel-IF ausgeben lassen. H-G S. schrieb: > Die "Grafikkarte" bestünde aus 2 Bild-Buffern zu je 64kB, einem AD 725 > RGB/PAL Konverter und einem schnellen PIC der die Syncsignale für > einen AV-Anschluss eines Fernsehers erzeugt. > Die Backbuffer werden mit Latches etc. umgeschaltet sodass immer > einer an den TV gesendet wird während der andere vom CPU-Bus beschrieben > werden kann. Ich stelle mir das gerade vor: Da kommen 30 Leitungen von der CPU und 30 Leitungen vom Grafikcontroller, welche zu 2x30 Leitungen der beiden RAMs umgeschaltet werden müssen ... Und weil es einfacher ist, auch noch in DIL. Und dann wird erwartet, dass das schnell Daten verarbeiten kann ... Mach Dir lieber nochmal Gedanken über ein ordentliches Grafikkartenkonzept. Denn das ist nicht Retro. Auf so blöde Ideen sind die damals nicht gekommen. Denn es ist auch völlig blödsinnig, für ein neues Bild jedes Mal einen kompletten Speicher füllen zu müssen. C64 bis Amiga sind auf jeden Fall ohne doppelten Speicher ausgekommen. Ich würde mir ein FiFo schnappen, durch den der Hauptprozessor dem Videoprozessor Kommandos und Daten mitteilt. z.B. - Lösche Bildschirm - Kopiere RAM 1 zu RAM 2 - Schalte Ausgabe auf RAM 1/2 - Schiebe Bild x,y Pixel - Hier kommen 100 Bytes Daten welche ab Position x ins RAM sollen - Zeichne eine Linie von x,y nach x,y - Schreibe "Text" an Position x,y Der Grafikprozessor führt dies dann während der Austastlücken im Shadow-RAM aus. Nun ist es auf einmal völlig egal, wie schnell Deine Main-CPU ist ... Gruß Jobst
Der Controller auf der Grafikkarte taktet nur das Sync-Signal und den Zähler-IC der von 0000h bis FFFFh etwa hochzählt und das /RD des aktiven Bildpuffers wird automatisch mit erzeugt irgendwie :-) Es braucht 2 umschaltbare Bildpuffer damit man in den einen zeichnen kann während der Controller+Zähler aus dem anderen Bildpuffer ausliest und an den PAL-Encoder schickt. Umgeschaltet wird das Ganze irgendwie durch Latches (mehrere :-)). Ich dachte auch am Anfang an Großes, wie zB. Linien zeichnen lassen oder leichtes 3D. Aber wenn man sich so die Leistung der Controller und deren Konnektivität ansieht ist das nicht möglich. Ich bin froh wenn ich ein paar Hardware-Umriss-maskierte Tiles/Sprites in den Bildpuffer schreiben kann bei hoffentlich mindestens 25 Bildern pro Sekunde. Ich habe mir die Technik des C64 angesehen und dessen Grafikchip (VIC-2 ?) war total genial für die Zeit. Der konnte Hardware-mäßig den Bildschirm um 8 Pixel scrollen sodass man nicht den ganzen Bildschirm jedes Frame neu füllen musste. Ich könnte soetwas mit viel Aufwand für Hardware-Scrolling implementieren indem ich die Adresszähler auf der Grafikkarte mit versetzten Startwerten vorlade aber die 64k SRAM reichen wohl nur für den horizontal überstehenden Rand links und rechts. Ich vermute eine anständige Grafikkarte mit Scrolling, Sprites, Farbpalette, Zeichenbefehle etc. geht nur mit Dualport-RAM, extrem schnellem ARM oder gleich mit dickem FPGA dazu :-). Das sprengt ein bisschen den Rahmen denn ich möchte es einfach halten und 16-Bit-(2D)-Grafik genügt mir eigentlich. @ARM auf FPGA: glaubt ihr wirklich es ist so einfach ? Wenn die ihre ARM-DIEs entwickeln steckt doch bestimmt viel mehr dahinter als einfach ein Raster von Gattern durchzubrennen.
H-G S. schrieb: > Es braucht 2 umschaltbare Bildpuffer damit man in den einen zeichnen > kann während der Controller+Zähler aus dem anderen Bildpuffer ausliest > und an den PAL-Encoder schickt. Oder einen einzigen Bildpuffer und Speicher, auf den durch passendes Timing sowohl Prozessor als auch Bildwiedergabe zugreifen können. Das war und ist der übliche Weg. Wenn die Bildverarbeitung unbedingt bildsynchron erfolgen soll, dann reicht eine umschaltbare Basisadresse für den Zähler. Da das wohl keine Massenware sein wird eignet sich für den Dual-Port Zugriff sogenanntes Video-RAM besonders gut. Das ist altes asynchrones DRAM, das nach einem Transferzyklus für die komplette Row auf einem zweiten unabhängigen seriellen Port Videodaten rausschiebt. Das wird zwar nicht mehr produziert, gibts aber als 64Kx4 noch bei Segor (41264-ZIP120), in ZIP-16, was sogar in Lötpunktraster passt. Siehe Beitrag "Grafik-LCD Controller mit AVR und VRAM"
:
Bearbeitet durch User
H-G S. schrieb: > Der konnte Hardware-mäßig den Bildschirm um 8 Pixel scrollen Jain. Dazu konnte er die gesamte Bildausgabe pixelweise früher oder später ausgeben. Bei einer Bildbewegung wurde dann pixelweise das Bild immer einen pixel später ausgegeben, bis 8 erreicht war und dann wurde der Speicherinhalt verschoben und die Verzögerung wieder auf 0 gesetzt:
1 | S9ABCEDF... |
2 | S9ABCEDF... |
3 | S9ABCEDF... |
4 | S9ABCEDF... |
5 | S9ABCEDF... |
6 | S9ABCEDF... |
7 | S9ABCEDF... |
8 | S9ABCEDF... |
9 | S123456789ABCEDF... |
10 | S123456789ABCEDF... |
11 | S123456789ABCEDF... |
12 | S123456789ABCEDF... |
13 | S123456789ABCEDF... |
14 | S123456789ABCEDF... |
15 | S123456789ABCEDF... |
16 | S123456789ABCEDF... |
17 | etc. ... |
S = Start der Bildausgabe SO wurde dann auch eine pixelweiche Bewegung möglich. Deshalb hat es bei einigen Spielen am Rand auch geflimmert. Im übrigen wurde die CPU des C64 mit 1MHz getaktet .... H-G S. schrieb: > Umgeschaltet wird das Ganze irgendwie durch Latches (mehrere :-)). Ja, das alleine ist eine Eurokarte ... H-G S. schrieb: > Linien zeichnen lassen Ja, würde mit einem Ausgabeprozessor gehen. > leichtes 3D Nein. > Ich bin froh wenn ich ein > paar Hardware-Umriss-maskierte Tiles/Sprites Kannst Du mit Deiner Lösung vergessen, da sie keine Objekte 'hinter' Deinen Sprites zulässt. Möchtest Du ein paar 8563 und 8566 Chips haben? Gut, damit kannst Du Deine 256 Farben vergessen, aber die sind Retro ... Die sind auch DIL :-D Gruß Jobst
H-G S. schrieb: > Ich könnte soetwas mit viel Aufwand für Hardware-Scrolling > implementieren indem ich die Adresszähler auf der Grafikkarte mit > versetzten Startwerten vorlade Sieh Dir mal den 6845 an.
Jobst M. schrieb: >> Ich bin froh wenn ich ein >> paar Hardware-Umriss-maskierte Tiles/Sprites > > Kannst Du mit Deiner Lösung vergessen, da sie keine Objekte 'hinter' > Deinen Sprites zulässt. Es ist so gedacht dass ein Pixel/Byte nur ins Bild-RAM geschrieben wird wenn es nicht die Spezialfarbe enthält die das Pixel als "durchsichtig" markiert. Das heisst dass das Pixel/Byte was an der Stelle bereits im Bild-RAM steht bleibt. Rufus Τ. F. schrieb: > Sieh Dir mal den 6845 an. Zuwenig Farben (eine) in der maximalen Auflösung :-) Jobst M. schrieb: > Möchtest Du ein paar 8563 und 8566 Chips haben? Gut, damit kannst Du > Deine 256 Farben vergessen, aber die sind Retro ... > Die sind auch DIL :-D Der hat nur 16 Farben ... Ich baue das Ding einfach mal und gucke was so möglich ist an Bildrate und Sprite/Tile-Anzahl. Das dauert aber noch ziemlich denn die Platine ätzen lassen und die Bauteile kosten einiges. Ausserdem will ich mir vorher meinen Stufe-2-Progger (mit 8051-Herz) bauen mit dem ich dann alles flashen kann. Am Stufe-1-Progger (mit DIL-Switches) bin ich schon dran, ich habe die geätzte Platine schon hier :-)
Wenn du dir wirklich einen Heimcomputer bauen willst dann würde ich doch mal bei den FPGA reinschauen. Das erspart dir kiloweise TTL zu verlöten, aber du bist nach wie vor noch auf der Hardwareebene mit Gattern etc. Du spielst dann halt mit der Hardwarebeschreibung statt Fädeldraht.
H-G S. schrieb: > Es ist so gedacht dass ein Pixel/Byte nur ins Bild-RAM geschrieben wird > wenn es nicht die Spezialfarbe enthält die das Pixel als "durchsichtig" > markiert. > Das heisst dass das Pixel/Byte was an der Stelle bereits im Bild-RAM > steht bleibt. D.h. a.) Deine Sprites bewegen sich Hinter dem Bild ...? b.) Ändert das an dem Problem nichts. Du brauchst eine Mimik, welche positionsabhängig entscheidet und umschaltet zwischen Hintergrund und Sprite. Schließlich sollen sich die Sprites vor dem Hintergrund bewegen können. H-G S. schrieb: > Der hat nur 16 Farben ... Aber die wären da ... Gruß Jobst
H-G S. schrieb: > @ARM auf FPGA: > glaubt ihr wirklich es ist so einfach ? > Wenn die ihre ARM-DIEs entwickeln steckt doch bestimmt viel mehr > dahinter als einfach ein Raster von Gattern durchzubrennen. Nein, so einfach ist das nicht. Wenn du damit noch nichts gemacht hast, kannst du dich auf ein paar Monate Einarbeitungszeit einstellen, bis du einen ARM-ähnliches Softcore ansatzweise verstehst und zum laufen bekommst. Jobst M. schrieb: > Also mit 0,5mm Pitch wächst die Anzahl der CPUs nochmal etwas an, aber > wirkliche Knaller sind da auch nicht dabei. > Denn alles in der Größe wird dann ehr ein Controller, welcher allerdings > internen Flash besitzt, aus dem er arbeitet. Ich weiß nicht was für dich jetzt ein Knaller ist, aber die meisten 32-bit µCs mit Businterface können auch externen Code ausführen. Bei den Cortex M7 wird es dank Cache auch richtig schnell. Nebenbei: Von Allwinner gibt es sogar einen Cortex A8 im TQFP Gehäuse. Wenn es dir um VGA-Grafik und du wirklich ein bisschen mehr machen willst, dann lohnt es sich einen Controller zu wählen, der dafür eine Hardware-Schnittstelle hat und an den man auch genug Ram anschließen kann. Das STM32F429-Discovery wäre zum Beispiel ein geeignetes Evalboard für diesen Zweck. Statt dem Display kann man auch einen Monitor über VGA anschließen.
H-G S. schrieb: > Zuwenig Farben (eine) in der maximalen Auflösung :-) Du hast nicht verstanden, was der 6845 macht. Der interessiert sich nicht für Farben, der erzeugt nur die Adressignale für den Bildschirmspeicher. Wie der organisiert ist (d.h. welche Bittiefe er verwendet), ist nicht vorgegeben. Klar, man braucht einiges an Schieberegistern, aber dann geht damit jede beliebige gewünschte Farbtiefe. Du willst ein PAL-Signal erzeugen, also eh' keine ernstzunehmende Auflösung. (Warum eigentlich? Damit die Bildqualität gegenüber einem mit RGB angesteuerten Monitor optimal schlecht ist?)
Rufus Τ. F. schrieb: > Du willst ein PAL-Signal erzeugen, also eh' keine ernstzunehmende > Auflösung. > (Warum eigentlich? Damit die Bildqualität gegenüber einem mit RGB > angesteuerten Monitor optimal schlecht ist?) Ich bin schon PC-geschädigt, da ich jahrelang spielsüchtig war und zu viel Zeit dafür hatte. Ich ertrage das Sitzen vor einem Monitor körperlich nicht mehr. Daher dachte ich ich mach was an der Glotze, die ist schön groß und ich muss nicht auf dem PC-Stuhl sitzen. Zweiter Grund ist das absurd miese Spielangebot auf dem PC und den Konsolen. Die versuchen mit aller Macht uns ihre Gewaltspiele unterzujubeln. Dazu kommen noch unterschwellige visuelle Effekte, regelrechte Verarsche und solche Sachen. Ganz zu schweigen von der allgemein miesen Qualität der Spiele, die sollen wohl nur Kinder und Jugendliche befriedigen. Einziger Ausweg: selber coden (aber nicht am PC) :-)
H-G S. schrieb: > Daher dachte ich ich mach was an der Glotze Röhrenkübel? Andere Glotzen haben VGA- oder HDMI-Eingänge. VGA ist mit etwas Bastelaufwand noch selbst in den Griff zu bekommen -- und das Timing dafür sollte sich sogar mit 'nem 6845 erzeugen lassen. Dann hast Du wenigstens so etwas ähnliches wie ein vernünftiges Bild, und keinen Matsch. Zu Spielen kann ich nichts sagen, dafür bin ich sehr gründlich gar keine Zielgruppe.
avr schrieb: > Ich weiß nicht was für dich jetzt ein Knaller ist, aber die meisten > 32-bit µCs mit Businterface können auch externen Code ausführen. Und nun nochmal zurück zu den CPUs (!=µC) über die ich diese Aussage getroffen habe (von denen jede ihren Code über einen externen Bus ausführen muss) .... Gruß Jobst
Jobst M. schrieb: > Und nun nochmal zurück zu den CPUs (!=µC) über die ich diese Aussage > getroffen habe (von denen jede ihren Code über einen externen Bus > ausführen muss) .... Meinetwegen. Aber ich denke wir sind uns hier alle einig, dass der TO keine CPU, sondern einen µC will. Alles andere verkompliziert die Sache nur.
avr schrieb: > Meinetwegen. Aber ich denke wir sind uns hier alle einig, dass der TO > keine CPU, sondern einen µC will. Alles andere verkompliziert die Sache > nur. Ich brauche keinen A/D-Wandler oder serielle Schnittstellen, aber ein paar Portpins für ein paar Extra-Aufgaben wären ganz gut. Es müsste der Grafikkarte zB. mit einem Signal mitgeteilt werden wann sie den anderen Bildpuffer aktivieren soll etc. Das ginge natürlich auch mit Memory-gemappten Registern irgendwie ...
:
Bearbeitet durch User
Ich bin auf den NXP Kinetis K10-72 (ARM Cortex-M4) gestossen. Der hat wohl ein externes Businterface namens FlexBus und steckt womöglich im LQFP-Gehäuse, vielleicht 64-Pin. Taktfrequenz scheint 72 MHz. Das User-Manual hat 1400 Seiten, das Inhaltsverzeichnis ist schon 50 Seiten lang :-)
:
Bearbeitet durch User
Wenn der ARM passt nehm ich den auf einem SMD-Adapter und einen LPC-ARM als Controller auf der Grafikkarte. Ich sehe zwar im Moment kaum die 1,5mm Lötaugen auf der Platine und kann mir 0,5mm Pitch nicht recht vorstellen aber mit Lupe und guter Beleuchtung gehts bestimmt :-) @16 bit: Ich dachte das sei gut wegen Adressraum, Datendurchsatz am Bus, Farbtiefe und Opcode-Codierung. Farbtiefe ist mittlerweile auf 8 Bit reduziert worden aber mit 16-bit-Bus kann man den Bildpuffer schnell füllen. Ich schaue mir auf jeden Fall mal den ARM an denn etwas mehr Power kann nicht schaden. Immerhin wäre es am günstigsten wenn die Framerate 50Hz erreichen würde. Es gibt sowieso ein Problem mit dem PAL-Converter und dem Syncsignal: ich habe keinen Röhrenfernseher mehr um es zu testen! Ich habe gelesen dass die neuen LCD-Glotzen tolerant bei Syncfehlern sein sollen, daher würde ich wohl nie wissen ob das Timing wirklich korrekt ist.
H-G S. schrieb: > Immerhin wäre es am günstigsten wenn die > Framerate 50Hz erreichen würde. > > Es gibt sowieso ein Problem mit dem PAL-Converter und dem Syncsignal: > ich habe keinen Röhrenfernseher mehr um es zu testen! Ich habe gelesen > dass die neuen LCD-Glotzen tolerant bei Syncfehlern sein sollen, daher > würde ich wohl nie wissen ob das Timing wirklich korrekt ist. Naja, eigentlich benötigst Du 25Hz mit Zeilensprung. 50 Halbbilder/s. Videorekorder (also die richtigen) sind da noch kritischer, als Fernseher ... Gruß Jobst
H-G S. schrieb: > ich habe keinen Röhrenfernseher mehr Dann lass' das mit dem PAL-Signal sein, und erzeuge ein RGB-Signal. Das kann (und sollte) dann auch gleich VGA-Timing haben, und Du kannst den Interlace-Kram seinlassen. PAL ist unscharfer verwaschener Matsch. Sowas will man nicht.
Rufus Τ. F. schrieb: > Dann lass' das mit dem PAL-Signal sein, und erzeuge ein RGB-Signal. Das > kann (und sollte) dann auch gleich VGA-Timing haben, und Du kannst den > Interlace-Kram seinlassen. > > PAL ist unscharfer verwaschener Matsch. Sowas will man nicht. Meinst du ein SCART-RGB Signal mit Sync separat ? Ich glaube mein LCD hat sogar noch eine Scart Buchse. Obwohl ja ein gelber Chinch-Video Eingang auf jeden Fall am LCD vorhanden sein dürfte - auch in Zukunft. Übrigens schauen die Youtube-Videos der Uzebox-Grafik gar nicht so verwaschen aus ... Es müssten übrigens 50Hz sein beim PAL wenn man von den Halbbildern ausgeht. Mir fällt gerade ein dass durch die ineinander verschachtelten Zeilen die Adressierung über Zähler komplizierter werden könnte. Man muss wohl die Zähler vor jeder Zeile Adressversetzt laden wenn die Bilddaten linear im Bildpuffer liegen.
:
Bearbeitet durch User
H-G S. schrieb: > durch die ineinander verschachtelten > Zeilen die Adressierung über Zähler komplizierter werden könnte. Man > muss wohl die Zähler vor jeder Zeile Adressversetzt laden wenn die > Bilddaten linear im Bildpuffer liegen. DAS ist nicht Dein Problem. Das kann man durch geschickte Vertauschung von zwei Adressbits zwischen Sender und GraKa lösen. Interessanter dürfte sein, dass die ungeraden Zeilen zeitlich in Bildmitte beginnen. Schickst Du sie mit dem selben Timing los, wie die geraden, dann hast Du anschließend 50p (meine: 50Hz progressive) mit halber Zeilenzahl ... Gruß Jobst
:
Bearbeitet durch User
H-G S. schrieb: > Meinst du ein SCART-RGB Signal mit Sync separat ? Wenn nichts besseres vorhanden ist (VGA, HDMI), dann auf jeden Fall das. > Obwohl ja ein gelber Chinch-Video Eingang auf jeden Fall am LCD > vorhanden sein dürfte - auch in Zukunft. Das ist nach dem UHF-Modulator die schlechteste aller Möglichkeiten, ein Bildsignal auf einen Monitor zu übertragen. Und es ist davon auszugehen, daß das auf Dauer aussterben wird, wie es auch Videorecorder und andere analoge Videoquellen schon getan haben. Bei RGB entfällt die grottige Farbcodierung, bei der die Farbauflösung nochmal weiter reduziert wird, was man insbesondere bei Rottönen sehen kann. Sieh Dir Deinen Fernseher genauer an - hat der wirklich keinen VGA- oder HDMI-Eingang? Wenn VGA vorhanden ist, brauchst Du Dir um den Interlace-Krampf keine Gedanken zu machen. Und auch HDMI ist für Dich nicht unerreichbar, es gibt Konverter, die aus einem VGA-Signal ein HDMI-Signal erzeugen. Bau Deine Retro-Bastelkiste wenigstens mit 'nem VGA-Eingang. Lass' PAL & Interlace links liegen. > Übrigens schauen die Youtube-Videos Das sind Videos. Bewegtbildmaterial. Stell' einfach mal nur eine Liniengraphik oder einen Textbildschirm dar, und Du siehst, wie unendlich schlecht PAL und die Fernsehauflösung sind. Es gibt gute Gründe, warum Computer seit Ende der 80er nicht mehr an Fernseher angeschlossen werden.
Rufus Τ. F. schrieb: > Und auch HDMI ist für Dich nicht unerreichbar, es > gibt Konverter, die aus einem VGA-Signal ein HDMI-Signal erzeugen. Die Konverter sind ja richtige externe Geräte mit Gehäuse. Schade dass mit HD ready/Full HD nichts geht ... aber 1 bw 2 MB Grafikpuffer sind einfach zu krass :-) Zum PAL-Zeilen-Problem baue ich mir den Grafikkarten-Prototypen flexibel mit Tastern und LEDs damit ich da feinabstimmen kann. Ausserdem plane ich ihn an den 8051er-Progger zu hängen, der hat 6x8 Ausgansports mit dem ich im Bildpuffer schreiben kann etc.
H-G S. schrieb: > Zum PAL-Zeilen-Problem baue ich mir den Grafikkarten-Prototypen flexibel Genau, erst wenn es in Serie geht, wird es fest. > damit ich da feinabstimmen kann Ich sehe es schon kommen: Der komplexeste analoge TV-Bildgenerator wird jetzt entwickelt wo analoge Bildübertragung schon fast tod ist ... Vielleicht solltest Du Dich auch einfach mal in die Materie einlesen. Sonst wirst Du das auch mit flexiblen Lösungen nicht zum laufen bekommen. Oder planst Du die Sync-Informationen mit im RAM abzulegen? Gruß Jobst
H-G S. schrieb: > Die Konverter sind ja richtige externe Geräte mit Gehäuse. Und? Dein Fernseher ist auch ein richtiges externes Gerät mit Gehäuse. Kann es sein, daß Du annähernd alles, was man Dir sagt, versuchst möglichst vollständig zu ignorieren, um die aufwendigste und schlechteste Lösung durchzuziehen?
LOL : auf meine Anfrage bei einem Chip-Distributor erhielt ich den Preisvorschlag von insgesamt 80 Euro mit Versand für 2 Stück XA-S3 Prozessoren. Rufus Τ. F. schrieb: > Kann es sein, daß Du annähernd alles, was man Dir sagt, versuchst > möglichst vollständig zu ignorieren, um die aufwendigste und > schlechteste Lösung durchzuziehen? Ich weiss auf jeden Fall dass der TV das Anzeigegerät sein muss. HD/ready-Auflösung und VGA gehen nicht wegen Speicherbedarf eines Bildes. Da bleibt irgendwie nur noch PAL. Torben K. schrieb: > Das wäre auch noch eine Idee: > https://de.wikipedia.org/wiki/Datei:NipkowDiskWithColourPicture.jpg Propeller-Display war damals ein Thema als ich noch am Röhrenmonitor hockte und die ersten LCD/TFT noch zu teuer waren zum Basteln. Sieht ausserdem gefährlich aus das Ding :-)
H-G S. schrieb: > VGA gehen nicht wegen Speicherbedarf eines Bildes Denk da noch mal genau drüber nach. VGA bedeutet nicht, daß Du zwingend 640x480 ausgeben musst - VGA bedeutet nur 32 kHz Zeilenfrequenz und 400 bzw. 480 Pixelzeilen und kein Interlace, sowie RGB. Welchen Pixeltakt (d.h. welche Horizontalauflösung) Du verwendest, bleibt Dir überlassen, und niemand hält Dich davon ab, die Vertikalauflösung zu halbieren, indem Du jede Bildzeile doppelt ausgibst. So macht es auch 'ne VGA-Karte, wenn sie einen der CGA-Graphikmodi ausgeben soll. Ansonsten: Du bist in der "Designphase". Mach' doch einfach den Graphikspeicher größer, warum willst Du den auf 64 kB begrenzen, wenn Du noch nicht mal weißt, mit was für einer CPU Du den ansteuern willst?
Ja ... 2x ARM CPU und dann auf 64k Bildspeicher begrenzen, weil es Retro sein soll- Dazu mit einer hirnrissigen Herangehensweise. Früher hat man versucht, mit möglichst wenig Aufwand viel zu erreichen. Du versuchst mit einer Materialschlacht möglichst wenig zu erreichen. Komische Vorstellungen, passt irgendwie alles nicht. Ich bin raus ... Gruß Jobst
Der ARM-Kinetis ist scheinbar sehr komplex und aufwendig zu handhaben. Da müsste ich mich wohl erstmal monatelang einlesen und mit einem Experimentierboard einlernen. Dafür ist er sehr günstig und verfügbar. Das Äquivalent von ST Micro (STM32F4 ?) hat scheinbar nur einen externen SD-Karten-Bus und einen externen DRAM-Bus, also nicht gerade geeignet für mein Projekt. Auch stellt sich die Frage wie flott die Code-Ausführung aus dem internen SRAM oder gar aus dem externen SRAM beim Kinetis ist - immerhin wird ja mit Cache gearbeitet. Ich müsste wohl ein paar Bücher besorgen über ARM Cortex M etc. Edit: der XMC4000 hat scheinbar auch einen externen Bus :-) Edit-Edit: aber nur ab 100-Pin
:
Bearbeitet durch User
Hol dir ne alte Betty und du hast alles drin - Framebuffer, externen RAM und ROM, LPC2220 von NXP (Arm7TDMI), Lautsprecher, Keyboard, Funk, IR usw. Der MC hat einen Bootloader und alles was der Siedler braucht.
H-G S. schrieb: > Das Äquivalent von ST Micro (STM32F4 ?) hat scheinbar nur einen externen > SD-Karten-Bus und einen externen DRAM-Bus, also nicht gerade geeignet > für mein Projekt. Was ist für dich ein DRAM-Bus? Manche STM32 haben ein FSMC, das kein DRAM unterstützt, dafür aber SRAM, LCDs, NAND/NOR-Flash. Mit dem FMC geht dann auch DRAM. Der STM32F4VG (auf dem Discovery-Board) hat einen externen Bus durch das FSMC mit 16bit. Allerdings hat er kaum Adressleitungen. Mehr gibt es in größeren Gehäuseformen mit mehr Pins.
Matthias S. schrieb: > Hol dir ne alte Betty und du hast alles drin - Framebuffer, externen RAM > und ROM, LPC2220 von NXP (Arm7TDMI), Lautsprecher, Keyboard, Funk, IR > usw. > Der MC hat einen Bootloader und alles was der Siedler braucht. Die Betty hat einen Framebuffer von 64kB ?
Update: Ich habe mich entschieden dem Cortex M4 eine Chance zu geben :-) Ich habe mir 3 Bücher besorgt und das vierte ist unterwegs. Im günstigsten Fall gibt es einen mit wenigen Pins aber dennoch sovielen Adress- und Datenpins für ein externes 64kx16 SRAM.
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.