Beiträge von Markaine

Ich will morgen auch kommen, ist noch nicht ganz sicher da ich am Freitag anderweitig noch einen Termin habe und ich nicht genau weiß wie lange der dauert.

You will find several packs here: CSDB

Es gibt eine Version für die REU (ist in Ultimate 1541/64 oder im Turbo Chamleon integriert), belegt dann keinen Speicher, alles andere macht tatsächlich nur bei sehr kleineren Projekten Sinn. Du kannst übrigens auch direkt auf die Disk assemblieren (ich weiß den Shortcut nicht auswendig).

Das Gameduino gefällt mir als Grafiklösung überhaupt nicht, daher wird das CX16 wohl eher nichts für mich.

Aus dem Facebook Thread (vom 8bitguy):

What sound chip will you be using?
At this point the leading contender is the General Instruments AY-8-8910. This chip is not just a sound chip but also provides 16 general-purpose I/O lines as well. We will have at least two of these chips in the system, giving a total of 6 voices and 32 I/O lines. While it is not quite a flexible as the SID chip, it is super simple to program. There will also be a stereo DAC which is part of the video chip, so digitized sounds can also be used in place of or along side the AY-8-8910.

What Video chip will you be using?
We have, for the time being, settled on a modified version of the Gameduino 1. Here are some of the specifications:

• 50x37 character text mode. Can have a virtual text screen of 64x64, which you can smoothly scroll through. There is possibly an 80-column mode in the works.
• 256 characters or tiles, which are 8x8 pixels, which can have 4 colors each.
• 256 sprites which can be 4, 16, or 256 colors. They are 16x16 in size
• While there is no bit-mapped graphics mode, there are enough sprites to fill most of the screen allowing for the creation of a pseudo-graphics mode in a variety of configurations and compromises, which is very much in the spirit of an 8-bit computer.

Why BASIC? Why Commodore BASIC?Well, I just want it to have some sort of BASIC in ROM, as well as an assembler/monitor. There’s no reason you couldn’t program it in C or any other language, though. Since we cannot license the ROMs from Commodore I want it to be possible for the end user to load BASIC 2.0 into flash or into RAM to use. However, it may end up having some other form of BASIC as default.

What about other languages?
There’s no reason you couldn’t program in C++ or whatever on this computer if somebody wants to port over a compiler. Alternatively, you can use a cross-compiler.

Why PS/2 Keyboard and not USB?
USB is tremendously more difficult to implement than PS/2. A good analogy is like the difference between implementing RS-232 or Ethernet. PS/2 keyboards are still manufactured, easy to find, and inexpensive. And, since the kernel is going to handle keyboard input, there’s no reason we can’t upgrade to USB later when we have the resources for that and it shouldn’t break compatibility.

Why VGA instead of Composite or HDMI?
I would love for it to have composite as a secondary option. But it can’t be the only option. I’d prefer something that could handle more than 40 columns clearly. VGA is fairly easy to implement as compared to HDMI. And worst case, there are low-cost chips that can convert VGA to HDMI. And if you have to convert to HDMI, far better to convert from VGA than from composite.

Why don’t you shoot for a 100% compatibility with the C64?
There are already plenty of products and emulators that do this. And while it would be nice, it would make this project considerably more complicated, expensive, and most likely would never get finished.

What sort of expansions would be possible?
We plan to have compatibility with Arduino shields. So, this will make a lot of hardware physically compatible and easy to snap on. However, the entire bus will also be available for anyone who wants to add custom hardware like SID chips, or whatever.

Why the 65816 processor?
I really wanted a 6502 computer. I wanted something that could be very close to a Commodore computer. However, the 6502 is limited to 64K of address space. To increase this usually requires banking memory in and out, which is a pain. So to make it possible to use more RAM, the 65816 is a perfect choice since it can access 16 MB of address space natively. However, when it boots up it will be in 6502 mode and be limited to 64K. It will be up to the programmer to make use of the extra RAM if they want.

What sort of joysticks will you use?
At the moment, the plan is to go with NES style game controllers. There are numerous reasons for this:

• The controllers, or at least clones are still manufactured.
• They offer more buttons, allowing more complex games.
• They require fewer I/O lines to operate them.
• Joysticks have sort of fallen out of favor and most people these days prefer controllers.

What do you need help with the most?At the moment we need help with kernel design. Even if the board were finished today, it would be a doorstop without having any software. So kernel development is the priority. We’re using modified C64s as test-mules.

Who is involved at the moment?
At the moment it is somewhat disorganized. And this may change over time as we figure out what aspects people want to do. But the main people on board right now are:

• David Murray - Ringleader and kernel design.
• Lorin Milsap - Lead Board Design
• Kevin Willams - prototyping/manufacturing
• Robin Harbron - Kernel and OS design
• Robin Raymond - Software design
• Bil Herd - Design Adviser

Will it be sold as a kit or pre-assembled?I’m sort of hoping to do both. Ironically, the kit would probably end up costing the same or more because of the DIP style packing. But I can see why a hobbyist would prefer that style of board. The pre-assembled unit would probably be a lot of surface mount.

Wenn Du nach dem assemblieren "s" drückst wird der Code ausgeführt.

Nach allem was ich hier jetzt so gelesen habe und auch aus vielen dutzenden anderen Projekten (Commander X16, Phoenix C256, Mega65...) die ich mir angeschaut habe sowie meine Erfahrung mit C64 & Co., sieht meine Traumretrokiste "Vision F64" nun wie folgt aus. Das Ganze realisiert in einem FPGA, ohne alte Chips, so bleibt das Projekt zukunftssicher. Der grundlegende Gedanke dahinter ist, es soll möglichst einfach sein tolle Ergebnisse zu erzielen, dabei aber bewusste Restriktionen vorhanden sein um die Kreativität zu fördern und das Look & Feel der 80er nahe zu kommen. So gibt es z. B. auch nicht dutzende Grafikmodi, sondern genau zwei. Auch wenn es wohl nie realisiert wird... Es ist deutlich mehr mehr als ein C64, es ist wohl fast ein Amiga, aber eben so gestrickt, dass die Einstiegshürde möglichst klein ist.

Grundlegendes

• Ganz wichtig ist eine sehr gute Dokumentation, auch wenn es lästig ist und Arbeit verursacht
• Für noch wichtiger halte ich eine integrierte Entwicklungsumgebung für Code, GFX und SFX. Kann ich Entwickler überzeugen, dann bekommt das System auch Software, ist Software (Spiele, Demos...) vorhanden kommen auch die User.
• Die Platine im Mini-ITX Formfaktor, so stehen von Anfang an Gehäuse zur Verfügung, sollte jemals eine ordentlich Stückzahl erreicht werden passt dies auch ein Tastaturgehäuse
• Es gibt definierte Hardwareregister z. B. für Sound und GFX, die direkt beschrieben werden können, "ich schreib nen Poke und die Bildschirmfarbe ändert sich"
• Auf Multitasking wird bewusst verzichtet, es verklompliziert vieles, sehr wohl kann "on-the-fly" zwischen mehreren Programmen hin- und her gewechselt werden, vom Assembler zum Musictool und ab ins Basic, dafür nutzt das System die integrierte Freezefunktion und ggf. einen geschützten Speicherbereich in dem die gefreezten Teile zwischengespeichert werden. So kann man simpel und einfach zwischen mehreren Programmen hin und her wechseln.

Software im Flash
Ganz wesentlich aus meiner Sicht: einschalten, loslegen.

• Integrierte HILFE Funktion (quasi ein integriertes WIKI: Basicbefehle, Assemblerbefehle, grundlegende Bedienung der mitgelieferten Software...)
• Kernal
• Basic (angelehnt an Basic 7.0 o.ä., OHNE Zeilennummern und ohne GOTO)
  
  
  • Für Basic, Kernal etc. gibt es eine Einsprungtabelle, so bleibt Software auch bei Updates der ROMs kompatibel
• ZIP kompatibler Cruncher/Decruncher (mit Hardwarebeschleunigung im FPGA)
• Editor
• Monitor
• Assembler
• Debugger
• Freezemenu (in dem Monitor und Debugger augerufen werden können, Spiel freezen um Zwischenstände zu speichern etc.)
• Zeichenprogramm mit Konvertier- und Importierfunktionen
• Charset, Sprite und Tile Editor
• Playfieldeditor
• SFX-Editor
• Musiceditor
  
  
  • weitere Devtools können ins Flash geschrieben werden, z. B. Hochsprachen

CPU

• 32/16 Bit CPU, z. B. 6800x
• Mit einer Geschwindigkeit die etwa der Taktfrequenz von 12 MHz entspricht
• 1 MB Arbeitsspeicher und kein MB mehr, auch nicht erweiterbar!
• 256 KB Adressbereich reserviert für Basic, Kernal, Monitor, (ROM), Register (außerhalb Arbeitsspeicher)
• 768 KB für externe Cartridges, z. B. Spiele auf Modul (außerhalb Arbeitsspeicher)
• 2 MB (erweiterbar bis 14 MB) die auschließlich als RAM-Disk genutzt werden können und dient z. B. als Zwischenspeicher für die Sourcecodes, undo/redo Speicher für die Grafik- und Soundprogramme etc., um die Entwicklung und den Umgang mit dem System möglichst angenehm zu halten, so müssen die Sourcen etc. nicht den Arbeitsspeicher belegen. Zudem gestaltet sich mit einer RAM-Disk das Nachladen von Programmteilen angenehmer, nachgeladene Inhalte können direkt in die RAM-Disk entpackt werden und von dort in den Arbeitsspeicher kopiert werden.

GFX

• Kein dedizierter Grafikspeicher, wie beim C64 teilt sich das System den Speicher
• Die GPU kann in einen der vier RAM Bereiche, max. 256 KB Speicher addressieren
• Die GPU bietet Hardwareunterstützung für Plot, Line, Fill...
• Eine einfache Form eines schnellen Blitters/DMA mit Funktion copy, erase, fill, and, or, eor
• Softscrolling links/rechts und oben/unten
• Hires- & 80 Zeichen-Mode:
  
  
  • 640 x 200 px
  • 4 Farben (von 32)
  • Hauptsächlich für Basic und Devtools (und sollte jemals jemand ein GEOS dafür machen wollen...)
• Lowres- & 40 Zeichen-Mode:
• Der Lowres-Mode kann entweder im Bitmap-Mode oder im Playfieldmode betrieben werden
  
  
  • 320 x 200 px
  • 32 Farben (1 Transparentfarbe für Playfieldmode), feste Farbpalette
  • Max. 3 Playfields übereinander (z. B. für Paralaxscrolling)
  • Das Playfield besteht aus 1x1, 2x2, 3x3 oder 4x4 großen Tiles (max. 32x32 px), es können max. 128 unterschiedliche Tiles definiert werden aus denen die Playfields generiert werden.
  • Das Playfield hat max. eine Größe von 65536 (256x256) Tiles, wobei die X- und Y-Größe, bis zur max. Anzahl Tiles, frei definiert werden kann. So müssen sich Coder nicht erst eine aufwendige Scrollroutine für Spiele ausdenken, das macht das System (wenn man denn will sonst kann man beispielsweise auch den Blitter direkt nutzen um lustige Sachen anzustellen).
• "Copper Bar"
  
  
  • Die sich ganz oder teilweise im Hintergrund oder Vordergrund befinden kann
  • Für Rastereffekte
• 40 Sprites
  
  
  • Größe wählbar 8x8, 16x16 oder 24x24 px
  • Max. 8 Farben (aus 32)
  • 8 definierbare Farbpaletten die dann für die Sprites ausgewählt werden können
  • Es können mehrere Sprites zu einem größeren Sprite "verbunden" werden, dass dann wie ein Sprite (von den Registern her) behandelt wird. Es hat keinen Einfluss auf die max. Zahl Sprites, nur das Handling zusammengesetzter Sprites wird vereinfacht.
• Eine Art Rasterzeileninterrupt um auf Bildschirmzeilenebene eingreifen zu können

SFX

• 6 Kanäle Stereo FM Synthie (angelehnt an welchen Chip auch immer, gerne auch SID)
• 2 (oder 4?) Digitale Audio Kanäle (DAC) max. 14 Bit

Konnektivität

• Möglichst HDMI
• 3,5 mm Klinke für Sound
• USB oder PS/2 für Maus und Tastatur
• 2x SD-Kartenslot
• 2 (oder 4?) Joystickports, welche auch immer, sie sollten aber ein Typus Joystick oder Joypad supporten der mehr als 3 unterschiedliche Knöpfe beherrscht (um etwas zeitgemäßere und abwechslungsreichere Spielsteuerungen zu ermöglichen)
• LAN und WLAN, Zugriff z. B. per FTP auf die Speicherkarten...
• Einen Expansionport und/oder GPIOs (für die Hardwarefreaks), z. B. auch für MP3 Decoder und ähnliche Spielereien

Dessen Idee stammt vom April 2018...

Zitat von sparhawk

Hmmm... Ich sehe da jetzt nichts was nach einem Retrocomputer aussieht. Gibts da vielleicht Screenshots irgendwo?

Siehe Wikipedia: RISC OS, läuft z.B. auch auf Archimedes A7000 (glaube bis 1997 produziert).

Nur eine Notiz am Rande, für den Raspberry gibt es schon ein RetroOS: RISC OS, stammt ursprünglich vom Acorn Archimedes.

Das wäre doch vielleicht eine schöne Alternative für die CPU: RTF65002, wäre auch eine Abtrennung von 68k Prozessoren die wieder so nach Amiga aussehen und hätte eine Verbindung in 8bit Welt.

Ich finde über grundlegende Hardwarespecs gibt es doch sehr ähnliche Ansichten. Das Gerät muss Spaß machen. Ich finde das Ganze steht und fällt auch mit den Entwicklertools und dem Schwierigkeitsgrad das System zu beherrschen. Je niedriger die Einstiegshürden sind und je besser die mitgelieferten Tools und Dokumentation, desto besser kann der Start gelingen. Ich kann keine Hardware entwickeln, sollte ein Projekt starten das mir zusagt wäre ich aber gerne bereit mich an der Programmierung der Tools (z. B. Editoren für Grafik, Sprites, Maps) und der Dokumentation zu beteiligen.

Ich würde das komplett vom C64 Thema trennen, dafür gibt es genug Lösungen: Turbo Chameleon, Ultimate 64 und Dinge die im Werden sind wie der Mega65 oder MK3. Es kostet viel zu viel Zeit um die Kompatibilität für einen C64 Modus herzustellen, das sieht man schon am Turbo Chameleon oder U64. Diese Zeit ist besser aufgewendet für eine integrierte Entwicklungsumgebung (sowas wie Studio 64 oder vergleichbar dem Pico8). Es macht auch keinen Sinn einen VIC II oder III zu schaffen, es soll einfacher zu programmieren sein, der VIC ist alles andere als eine Ideale Vorlage.

Die aktuellen Specs des Commander 16 (8-Bit Guy):

• Prozessor 65C816
• Grafik Gameduino (FPGA), VGA Ausgang
• Sound 2x AY-3-8190 (6 Stimmen)
• Maus & Tastutur PS2
• RS-232 Schnittstelle
• Joystick 2x SNES Ports
• Speicher 1 MB
  
  
  • es gibt auch schon eine Memory Map, in Kürze zusammengefasst: die unteren 64K sind mehr oder minder für Grafik und System, die restlichen Bänke frei zur Benutzung

Eine weitere neue Entwicklung: Neon816, interessant daran finde ich die Idee das der Schöpfer den Grafikausgang als DVI-D realisiert, dafür gibt es billige Adapter auf HDMI und man umgeht das Problem mit den HDMI Lizenzen. Auch hier wird Grafik und Sound über einen FPGA implementiert.

Zum Yamaha V9958 Chip, die Features gehen durchaus in die Richtung die hier schon besprochen wurde, der Chip ist nur noch recht teuer zu bekommen. Ahnliches in einen FPGA umzusetzen ist vielleicht sinnvoller und zukunftssicher wie @Retrofan (und andere) schon geschrieben haben. Retrofähige Prozessoren wird noch einiges hergestellt, bei Grafikchips sieht es dafür nicht so gut aus, da macht ein FPGA durchaus Sinn.

Wenn ich den ganzen Thread Revue passieren lasse, gibt es in Summe schon einige Details die sich annähern und es kristallisieren sich ein paar grundlegende Details heraus:

• Feste Farbpalette bis höchstens 32 Farben
• Eine Auflösung im Bereich 320x200 bis 640x200 (640x400?) px
• Softscrolling
• Sprites und davon ausreichend viele
• Ein Prozessor mit 16 Bit Fähigkeiten, der angenehmer zu handhaben ist wie ein 6502 oder 65816
• 1-4 MB RAM
• Es könnte komplett oder partiell als FPGA aufgebaut sein, z.B. echte alte CPU (von denen einige auch noch sehr gut verfügbar sind) und GPU im FPGA
• Ordentliche Soundfähigkeiten mit mind. 6 Voices
• Integriertes Basic und Monitor (und Assembler?)

Von der Hardware mal ganz abgesehen, ich finde der "VisionF64" sollte deutlich einfacher zu handhaben wie die alten 8-Bitter. Es ist ziemlich mühsam einem C64 etwas zu entlocken wie beispielsweise Sam's Journey. Wenn ich diese Herausforderung will gibt es genug Auswahl an bestehenden Retrosystemen. Eine Entwicklung die sich zu sehr am C64 anlehnt halte ich nicht für sinnvoll, die Hardware des C64 ist in vielen Bereichen zu mühsam. Integrierte Tools wie beim Pico-8 könnten ein gutes Vorbild sein und ebenso wichtig ist eine gute Dokumentation. Der potentielle Entwickler erhält von Anfang an alles in die Hand um loslegen zu können. Es setzt die Hürde herab sich erst mühsam vielleicht die Tools sogar selbst erstellen zu müssen. Dies könnte das Interesse wecken von Entwicklern, jung und alt, sich mit einem bewusst limitiert gestalteten System zu befassen, dafür darf aber die Lernkurve nicht so groß sein wie bei den alten 8-Bittern.

Ich hab eine neue Version des TapeDevil V3 fertiggestellt, mit Updates von vorhanden Programmen und einiges neu hinzugefügt. Ingesamt sind jetzt 185 Tools & Utilities enthalten, viel Spaß damit

Übrigens mit der neuen Firmware für das U64 (1.10/3.4) schaltet eine Duo-Color LED jetzt sauber zwischen Power und Drive um, es entsteht keine Mischfarbe mehr.

Meinem Gefühl nach ist die Kombination von 6800x Prozesser und einer etwas aufgebohrten C64 Grafik nicht stimmig. Ich denke eine interessante Kombination, die dem potentiellen Spieler, Coder und Grafiker gefällt zu zimmern ist gar nicht so einfach. Es soll mehr sein wie ein C64 aber kein Amiga werden. Ein stimmigies Konzept zu finden das da zwischendrin sitzt finde ich spannend.

Eine echte CPU, Grafik- und Musicchip limitiert das System auf das was die Chips können. Bei einem FPGA besteht immer die Gefahr das die Entwickler dem Gerät Dinge hinzufügen "weil es halt geht" (so lange der FPGA nur groß genug ist) und dann kommt am Ende ein Mega65 raus, der nicht mehr viel mit dem C65 zu tun hat (außer das er auch einen C65 Mode hat, den wohl kaum jemand nutzen wird).

Wenn das Ding auch außerhalb der C64 Welt erfolg versprechen soll, würde ich nicht zu nah am C64 bleiben, dafür gibt es C128, 64DTV, div. FPGA Lösungen (U64, Chameleon) und irgendwann den Mega65.

Wen interessiert in so einem frühen Stadium die Farbpalette? Darum kann man sich kümmern wenn die Hardwarespecs und grundlegende Ideen zum System stehen. Soll es eine reine FPGA Lösung werden? Ein Mix wie beim Foenix C256? Oder lieber etwas basierend auf Chips die es in vernünftigen Stückzahlen und Preisen noch gibt und FGPA nur wo es sein muss? Ich würde zu letzterem tendieren (siehe auch mein Posting auf Seite 1).

Gideon hat im Januar die Prototypenplatinen für den Userport Adapter und den internen Lautsprecher (für die Floppygeräusche) bestellt, ist also in Arbeit und sollte in den nächsten Monaten verfügbar sein.