Hallo Besucher, der Thread wurde 81k mal aufgerufen und enthält 386 Antworten

letzter Beitrag von stynx am

Selbstbau 68k Rechner

    Zitat von PeterSieg


    Aber, es gibt z.Z keine wirklich aktive Entwicklung - Schade eigentlich, bei den Möglichkeiten..


    Nun ja es kommt ja noch der Duinomite eMega mit Ethernet:
    http://www.olimex.com/dev/duinomite-emega.html


    oder in Zukunft der


    OLinuXino:
    http://www.olimex.com/dev/imx233-olinuxino-maxi.html


    Leider hab ich das Gehaeuse fuer den Duinomite Mega bis jetzt nur in UK gefunden:
    Hier nur mit dem Duinomite Mega fue ca. 58EUR in der Bucht 270962505009


    Die hatten auch mal das Gehaeuse allein....ist wohl Olimex selber als Verkaeufer.

    C128Egretz: Die Preise sind klasse. Vielleicht bestelle ich da dann irgendwann Revision 2 der Platine. :)


    Hab gestern nen blöden Nebeneffekt der indirekten Registeradressierung des VDPs erfahren. Man schreibt in den Registerport die Nummer des Registers, welches man lesen oder schreiben möchte. Danach werden die Daten über den Datenport ausgetauscht. Wenn nun während des ersten Befehls ein Interrupt auftritt und in der entsprechenden ISR der VDP ebenfalls indirekt angesprochen wird (verändern des Registerports), merkt das eigentliche Programm davon nichts und schreibt/liest falsche Register.


    Hach, ich muss mal aufhören, lustige Spielereien mit SID und VDP zu programmieren und mich wieder um den Basic Interpreter kümmern. cd, mkdir, rm, save fehlen noch und die Tastatur hat noch US Layout...
    :)

    [offtopic]Für ARMe:

    Normalerweise ist der ganze Basic-Speicher frei, aber ich pfuschte gerade an Puffern für das Display rum.
    [/offtopic]
    BTW Bogogil, ich finde Dein Projekt super!

    guidol Ich finde die Olimex Dinger preislich nicht so interessant für 32,60 € (ohne Porto) konnte ich meinen Raspberry Pi bei RS-Online bestellen mit folgenden Daten:

    • Broadcom BCM2835 SoC (PDF-Datenblatt), enthält:

      • CPU: ARM1176JZFS v6 32Bit Single Core mit mathematischem Koprozessor (VPU) und DSP, 700 MHz
      • GPU: Videocore IV, Dual Core, 128 KB L2-Cache, 250 MHz

        • unterstützt OpenGL ES 2.0
        • unterstützt OpenVG 1.1
        • belegt 32, 64 oder 128 MB des RAM (konfigurierbar)
    • 256 MB RAM, 400 MHz
    • SD Memory Card Slot (SDHC), kompatibel zu Class 4 und Class 6 Karten
    • HMDI 1.3a
    • Composite Video
    • 3,5mm Stereo-Audio
    • 26 Pin Port mit 5V, 3,3V, GND und 17 3,3V GPIO Pins (SPI, I2C, UART) mit 2 - 16 mA
    • Maße: 85,60mm x 53,98mm x 17mm
    • Gewicht: ca. 45g
    • Versorgungsspannung: 5V via MicroUSB-Anschluss
    • Platine: 6 Lagen
    • 2 x USB 2.0 über internem Hub
    • 1 x RJ45 10/100 MBit/s Ethernet, intern über den USB-Controller angebunden
    • 5 Status LEDs (Power, SD-Card Zugriff, LAN 10/100 MBit, LAN Full-Duplex, LAN Link / Zugriff)
    • Stromverbrauch: max. 3,5W (700mA)
    • Schaltplan (PDF)

    Dazu hab ich mir dann noch für knapp 20 € (inkl. Porto) ein Nokia Netzteil und 2x 8GB microSD Karten mit Adapter bestellt.


    Somit bin ich beim Preis vom iMX233-OLinuXino-Maxi der laut Liste 53,49€ kostet. Der DUINOMITE-eEGA ist mit 47,54€ auch nur unwesentlich günstiger hat aber einen CAN Bus, was Ihn für aufs Auto bezogene Bastelleien (Modellabhängig) interessant macht bzw. machen könnte.

    Um mal wieder on Topic zu werden: Mit dem Pattern Modus des VDP kann man schon recht einfach hantieren. Und es macht grad richtig Spaß, die Möglichkeiten zu entdecken. :) Hier hab ich denselben Modus verwendet, den ich auch für den Text-Screen verwende: 512x212. Ich hätte lieber den ersten Pattern Modus gewählt (256x212, dafür zwei unabhängige Ebenen).

    [Externes Medium: http://www.youtube.com/watch?v=-I2YuP5CpNI]

    Ich muss mir etwas anderes übelegen, wie ich zu Videos komme. Auf dem Monitor ist das Scrolling noch butterweich und ruckelfrei.


    Edith: Und wann schreibt Schlonkel mir ne exklusive Lost Caves Portierung? :D

    Ich weiß ich bin schon wieder zum Teil Offtopic aber ich wage trotzdem mal eine Frage:


    Bogogil was meinst Du ließe sich der V9990 wie auf dem MSX in Form eines Cartridges (GFX9000) auch am C64 betreiben?


    Ich könnte mir einen VIC Adapter vorstellen der das SVIDEO Signal direkt abgreift (oder notfalls ein Kabel vom Videoausgang zum Cartridge). Im Cartrige ist dann eine Art elektronischen Umschalter (ggf. mit Konverter) der das jeweils aktive Videosignal auf den sich am Cartridge befindlichen Ausgang führt.
    So hätte man die Möglichkeit die Videogenerierung des VICs zu deaktivieren wärend man den V9990 nutzt. Das das Bildschirm abschalten den C64 um einiges beschleunigt ist ja bekannt, da die CPU nicht ständig auf den VIC warten muß.
    Es gab ja auch einen 2 MHz der mit so einer Grafikkarte noch mahr Sinn machen würde.
    Mit 2 MHz müßte der 6502 ja dann auch etwa das MSX Z80 Nivau erreichen.
    Und für die GEOS Fetischisten müßte so eine Grafikkarte für den C64 doch der heilige Gral sein.
    Trotzdem stellt sich mir die Frage wäre der C64 schnell genug um den Grafik Chip mit Daten zu füttern, da ja die Auflösungen deutlich höher sind.
    Falls nicht könnte man evtl. eine Art simplen Coprozessor einsetzen (z.B. einen PIC oder Atmel) der auf Anweisung der C64 CPU die Grafikdaten von z.B. einer SD-Karte streamt.
    Darüber hinaus könnte dieser Coprozessor falls das überhaupt möglich ist ebenfalls den SID mit Musikdaten versorgen, so das sich die CPU auf die Spielelogik und das Abfragen der Joystikports so wie das Auslösen von Ereignissen (Sounds ausgeben, Anweisungen an die Grafikkarte geben, Dateien von der Leveldaten von der Floppy holen) beschränkt ist.

    Zitat von natas

    guidol Ich finde die Olimex Dinger preislich nicht so interessant für 32,60 € (ohne Porto) konnte ich meinen Raspberry Pi bei RS-Online bestellen


    Natuerlich ist ein Raspberry fuer den Preis spannender :) (hab meinen bestellt und jetzt ist er auch unterwegs).
    Allerdings ist der Raspberry noch nicht so gut verfuegbar und auch nicht so einfach als BASIC-Rechner nutzbar.
    Ich denke schon, dass beide ihre Existensberechtigung haben - je nach Einsatzzweck.
    Der Raspberry ist in den News mehr gepusht und wird jetzt auch in ganz anderen Stueckzahlen produziert, was den Preis
    drueckt.


    Ich finde, dass die Olimex Platinen gegenueber anderen "Entwicklerboards" sehr guenstig sind.


    Ich bin mal auf den Raspberry gespannt...und wann dann mein (in rot) bestelltes Gehaeuse aus UK kommt :)
    siehe: https://www.modmypi.com/shop/raspberry-pi-cases

    2008 hab ich einen Einplatinencomputer mit der gleichen CPU gebaut. ROM, 128k SRAM, DUART und zwei Slots für Erweiterungen. Dieser Computer geht 1 zu 1 zurück auf einen Lochraster Aufbau, der aber nicht mehr funktioniert. Dann hab ich lange nichts bzw nur sporadisch mal etwas gemacht. IDE und DRAM Schaltungen hab ich auf Lochraster aufgebaut und am obigen System getestet. Letzten Herbst war dann der VDP dran, für den ich eine kleine Platine entworfen hab. Mit dem Schaltplan für den aktuellen Rechner hier im Thread hab ich Ende Oktober letztes Jahr begonnen. Vieles war dabei reine Fleißarbeit: Fertige Elemente schlicht zeichnen und ganz oft Symbole und Footprints für gEDA erstellen.
    Genau da hab ich dann den ersten Bock abgeschossen: Beim Erstellen des Footprints für den WD177x hab ich aus Versehen zwei Pins dieselbe Nummer gegeben und es ist mir bis zum Schluss nicht aufgefallen. Die Folge war ein Kurzschluss zwischen D3 und RESET. War aber leicht zu fixen. Für die Ferritperlen hab ich Footprints von Widerständen benutzt. Eigentlich kein Problem, nur hab ich beim Platzieren nicht daran gedacht, dass die Ferritperlen dicker sind. Nun passen nicht alle aufs Board, weil es zu eng ist. Dann wollte ich die internen Widerstände des Atmega als Pullups für die PS/2 Ports benutzen. Mit reinen PS/2 Tastaturen klappt das wunderbar. USB-Tastaturen, die mit diesen passiven Adaptern kommen, verweigern ihren Dienst. Nach dem Einschalten checken die die Leitungen bevor es der Atmega geschafft hat, die Widerstände als Pullups zu konfigurieren. Die Folge ist, dass sie im USB Modus arbeiten wollen. Das Timing für den VDP stabil hinzubekommen, war auch etwas schwieriger. Entweder sind die Angaben im Datenblatt nicht klar genug oder ich bin nicht klar genug, wenn ich das lese. :D


    Ich hatte auch darüber nachgedacht, den VDP an den C64 zu flanschen. Ich würd dafür ein GAL/CPLD benutzen, um das Timing zu steuern. Evtl ist der 6510 auch langsam genug, dass man das Timing ausser Acht lassen kann. ;) Was die Geschwindigkeit angeht muss man halt viel innerhalb des VRAMs mit Hilfe des VDP machen. Dann sind es immer nur ein paar Register, die gesetzt werden müssen. Mit zusätzlicher Hardware ist der VDP in der Lage, Genlock zu spielen. Man kann nicht nur mehrere VDP zusammen arbeiten lassen, um die Anzahl der möglichen Ebenen zu erweitern, sondern auch andere Videoquellen verwenden. Elegant wär es, wenn ein C64 Spiel dann automatisch erkennen würde, ob der VDP vorhanden ist und diesen dann für einen schönen Hintergrund verwendet wird. Aber nunja, das muss alles jemand programmieren. Ich fürchte, so toll die Möglichkeiten sind, es endet wie die GFX9k der MSXler. :-(

    Das so eine Grafikerweiterung nur sehr bedingt erfolgreich sein wird ist klar. Dafür ist einfach schon der Preis zu hoch außer man bekommt die Chips fürn Euro. Aber das ein Deine Eigenentwicklung markttechnisch bessere Chancen hat sehe ich auch nicht. Evtl. kann man die Grafikerweiterung ja systemoffen gestalten. Die Prototypenkarte hat ja auch schon mit den 3 Anschlußboards mehre System unterstützt und zwar: PC-98, MSX, IBM-PC
    Jetzt hast Du noch eine weitere Variante beigesteuert.


    Was haltet Ihr von der Idee einen Streaming Prozessor dem Cartridge hinzuzufügen? Also einen PIC oder auch gerne einen Atmel)und eine SD-Card ggf. noch etwas ein lokales RAM. Diese soll dann auf Anweisung das VRAM füllt und evtl. sogar Videosequenzen streamten. Evtl. könnte man dann noch 2 PWM Ausgänge zu Audioausgängen machen, so das der Sid ausschließlich zur musikalischen Untermalung genutzt wird. Der Streaming Pozessor kann dann auf Anweisung Samples (zur C64 Zeit noch Digis genannt) ohne großen Aufwand abgespielt vermutlich sogar MODs.


    Ich denke diese Erweiterung mit dem 8BitBaby realisiert oder ähnlich designed wäre eine gute Idee weil gleich Commodore 64, VIC-20, C16/116/Plus4 und Apple ][ möglich wären.
    Oder als Huckpackplatine wie der mini Maximite und das ganze dann auf einer 8BitBaby ähnliche Adapterplatinen für z.B. Atari 8Bit oder Schneider CPC so einfach die unbenötigten Ports abesägt werden so das man mit einer einzigen Adapterplatine bis zu 4 Systeme unterstützen kann und immer die gleiche Hauptplatine oben einsteckt.


    Das alles macht nur dann Sinn wenn es wirklich noch größere Mengen new old Stock des V9990 gibt, so das man einen vernüftigen Preis aushandeln kann dafür dürfte aber nicht jeder selbst bei den Brokern anfragen sonst sehen die tatsächlich noch einen Markt für diese eigentlich wertlosen Chips. Der ja bei Ebay als Sammlerstück angeboten wird.


    Ich gehe jetzt mal von einer technischen Machbarkeit in einem vertretbaren finanziellen Rahmen aus stellt sich jetzt noch die Frage gibt es überhaupt interesse an so einer Grafikkarte? Es gab ja schließlich füher auch 80 Zeichenkarten zu horenden Preisen.

    Richtig, aber ich wollte und will mit meinem Projekt keinen Markt bedienen. Da man so oder so die Software neu schreiben muss, bin ich den Weg gegangen, komplett neu anzufangen. Wenn ich mir aber vorstelle, etwas für einen Markt zu entwickeln, dann sollte ich nicht nur darauf achten, dass die Entwicklung am Ende bezahlbar ist, sondern, dass es auch Support gibt bzw ich diesen leisten kann. Oder man müsste wirklich darauf hinweisen, dass es keinen Support über die erste Inbetriebnahme hinaus gibt... Aber evtl seh ich das auch zu schwarz und die C64 Community ist in dieser Hinsicht aktiver und es kommen die entsprechenden Anwendungen, die ein Käufer erwartet. :)


    Vielleicht machst du dazu mal einen eigenen Thread auf ala "Ideensammlung für eine C64 Grafikkarte". Dort könnten wir Ideen sammeln und wenn ich kann, werde ich meine Erfahrung in Hard- & Software mit dem VDP einfließen lassen. Übrigens kann man das VRAM so ähnlich wie das Amiga Chipram in den normalen CPU Speicherbereich einblenden. Meine Grafikkarte, welche ich letztes Jahr gebaut habe, hat dieses Feature on-board. Allerdings hab ich es nie wirklich genutzt. Auch bei diesem Zugriff bleibt die Gewalt beim VDP und die CPU muss warten; bei jedem einzelnen Zugriff. Dennoch könnte man - da man hier mit voller 16-Bit breite auf das VRAM zugreifen kann - mit einer entsprechenden CPU oder DMA weitere Geschwindigkeit gewinnen. Ein Vorteil des Einblendens in den normalen CPU Speicher wäre die Umgehung der indirekten Adressierung (zumindest, wenn man aufs VRAM zugreift), welche wie weiter oben beschrieben, zu Problemen mit Interrupts führt.


    Hab grad nochmal nachgelesen: Letzten Herbst hatte dieser eine Anbieter noch über 100Stk und ich hab bei den 4 Stück, die ich gekauft hab nicht 10, sondern 20% Preisnachlass bekommen. Aus wirtschaftlicher Sicht, wäre IMHO eine FPGA Lösung die beste...

    Die FPGA Lösung gibt es ja bereits vom Jens. Nur hier geht es ja ums Retro und ich finde das dieser V9990 wirklich Retro ist und so ziemlich das beste was es damals gab und dazu noch 8 Bit kompatibel.
    Gut der Streaming Prozessor wäre auch nicht gerad Retro, außer man beutzt dafür ebenfalls eine Retro CPU.

    Puh, mir dreht sich alles. Hab letzte Woche angefangen, einen tcp/ip Protokollstack zu portieren. So langsam leide ich an den Auswirkungen der Endianess Verwirrung. :rauch: Naja, zumindest rudimentär funktioniert mein Code. Sprich: Ich kann meinen Rechner anpingen. Allerdings bleibt mein Programm zwischendurch einfach hängen. Wo das Problem liegt, muss ich mal genauer untersuchen. Desweiteren versuch ich grad, einen minimalen Webserver zu implementieren. :) Nuja, schauen wir mal, ob mir das noch gelingt...


    Bogo

    Mal ein kleines Update: Ich hab seit gestern einen minimalen Webserver laufen. Er antwortet nur auf http GET Requests und liest die angeforderten html Seiten von CF-Karte.
    Der Code stürzt noch immer zufällig ab, aber das liegt wohl am DRAM Zugriff. Ich konnte den Fehler soweit eingrenzen, als dass es eine Hand voll Adressen gibt, die beim Lesen ab und an 0x00 bzw 0xff zurück liefern, anstatt des korrekten Inhaltes. Dachte zuerst an ein defektes SIMM Modul, aber ein baugleiches liefert exakt dieselben Symptome. Schon komisch, dass nur bestimmte Adressen davon betroffen sind. Ich vermute jetzt, dass mein Timing beim DRAM Zugriff noch nicht 100% korrekt ist und dass diese Adressen in einer gemeinsamen Zeile liegen, bei der sich das auswirkt. Mal schauen, wie ich das gefixt bekomme. :)


    Öhm, interessiert es euch überhaupt, wenn ich zwischendurch mal Projekt-Updates poste?


    Bogo