Chameleon - gesammelte Factpostings

EDIT by FXXS: folgende 44 Postings stammten ursprunglich aus dem Featurethread: Chameleon - Diskussion über Features

VHDL-Sources wird's nicht geben, dafür haben wir schon zu viel verschenkt. Da gibt es ne neue Firma "Arcaderetrogaming" aus Amiland, die wohl von einem Deutschen gegründet wurde. Der "Entwickler" hat schon in einem öffentlichen Forum zugegeben, dass er große Teile von Peter's FPGA64 in dem Teil drin hat. Peter hat an keiner Stelle seine Einverständnis dazu gegeben, dennoch hat der Inhaber von dem Laden die Unverfrohrenheit, mich nach Core-Lizenzen von Clone-A zu fragen, will aber bisher keinen Cent für das bezahlen, was er bereits geklaut hat. Soviel zu open-source cores...

Chameleon als Hardware-Entwicklungsplattform will ich eigentlich auch nicht, denn wir haben schon eine FPGA-Entwicklungsplattform: Den C-One. Der hat mehr FPGA-Power und mehr Interfaces. Das ist aber mit Peter noch nicht ausdiskutiert.

Wer eine neue Plattform haben will mit anderer CPU und mehr Grafik, der ist auf dem C-One besser aufgehoben. Vielleicht ringt sich ja mal einer durch, den 65816 für etwas zu benutzen? Ich hatte mal ein Bounty von 500,- EUR für einen 1MHz-VC20-Core mit 65816 ausgesetzt. VC20-Core ist open-source, da hätte man "nur" existierende Elemente aneinander pappen müssen. Warum hat das keiner gemacht? Ist doch alles offen und so einfach?

Das Freezer problem in der 1541u ist natürlich so ne Sache für sich - als ich damals das Retro Replay gemacht habe, gab es von den Cyberpunx (Count Zero) strenge Vorgaben: Preis 100,- DM oder weniger, Verdienste sollen in die Szene zurück fließen, vergünstigte Freezer für Beteiligte an der Software-Entwicklung, dann durfte ich die Hardware mit dem Rom der Cyberpunx verkaufen. Gab es so eine Vereinbarung mit Gideon?

Chameleon und C-One vom Werdegang her zu vergleichen ist nicht richtig, denn beim C-One gab's eine Haupt-Entwicklerin die mich (und damit ihre Kunden) betrogen hat. Bei Chameleon gibt es einen Verantwortlichen, der seit 15 Jahren im Geschäft ist und der im Vorfeld die richtigen Leute an die richtigen Elemente der Entwicklung setzt. Jeder Beteiligte ist bezahlt, außerdem ist die Zielgruppe eine Andere (wer hat gesagt, dass gerade Spieler sich das Teil nicht kaufen wollen?).
Das Konzept ist so grundverschieden wie's nur sein kann: Der C-One wollte die Idee des C64 in dieses Jahrtausend tragen: Der erste re-konfigurierbare Computer der Welt, der von Otto-Normalanwender auch auf Core-Ebene programmiert werden kann (merke: FPGA-Technik war zu dem Zeitpunkt oft nur den Chip-Entwicklern vorbehalten!). Chameleon hingegen will den C64 selbst in dieses Jahrtausend bringen, und zwar mit modernen Interfaces und Massenspeichern. Dabei soll die Plattform eben *nicht* verändert werden, weil nur so für die breite Masse ein Nutzen entsteht. Gemeinsam ist einzig, dass die Hardware-Basis FPGAs benutzt.

Jens

Ich möchte mal wieder auf Chameleon-Features eingehen:

Das Austauschen von Kernal-Rom (und auch Basic/Char) ist kein Thema, die können beim Starten auch von der Flashkarte geholt werden. Sie müssen ohnehin ins Ram von Chameleon kopiert werden, wo das memory-mapping vom C64 nachgebildet wird. Ob die Quelle jetzt der Computer selbst, oder die Flashkarte ist, das spielt keine Rolle.

Offenbar spielt RR-Net für Euch eine große Rolle. Wofür genau, wenn ich fragen darf? Was sind die Killer-Anwendungen? Ich kenne die Transfer-Programme, Contiki, vielleicht noch das Final Replay von Graham, den Loader von den Dreams (oder von wem war das?) in Sachen "the internet is my harddrive" (LOAD holt per HTTP das PRG) - was noch? Vielleicht kann ich ne vernünftige Kompensation für Gehäuse-nicht-zerdremlen-woller machen, wenn ich die killer-Anwendungen kenne.

Sound 'rausnehmen wäre blöd - es kostet kaum Geld, nur 8,1mm Breite an der Steckerfront und die FPGA-Routinen dafür sind nur wenige Zeilen lang. Das kann auch für ganz andere Dinge verwendet werden (z.B. SID-Erweiterungen) und sollte deswegen unbedingt drin bleiben.

Ich bin etwas überrascht, dass "entweder IEC oder PS/2 Tastatur" ein Problem darstellt (wo doch die C64-Tastatur den coolen Look des Systems ausmacht!), aber auch da werde ich versuchen, eine Lösung zu finden (Kabelpeitsche oder sowas).

Jens

Ähem... also selbst wenn ich den C16-Datasettenport nehmen würde, würde das nicht passen. Außerdem gibt es da draußen mehr .TAP files als man glauben mag, da würde ich es vorziehen, wenn wir ein kleines Bischen von den 32MB Ram für TAP-Space reservieren und die entsprechende Emu einbauen. Einfach ein TAP file im Browser anwählen, Computer wird gestartet und man kann mit LOAD das Tape laden. Ganz ohne Bandsalat

Wer jetzt auf Tape SAVEn will, kriegt Haue

Jens

Zitat von sauhund

was mich daran erinnert das jens wohl doch nochmal den logicanalyzer mit in den bunker nehmen muss.... aber ja

Hmmjaa, das messen wir lieber mal hier, auf die Bunker-Umgebung habe ich seit meinem letzten Besuch irgendwie keine Lust. Ich hab' sowohl NMOS- als auch HMOS-VICs hier, da können wir die Übergänge prima messen. Das eilt aber nicht und ist eigentlich ne super Beschäftigung für nen langen Winterabend, denn es sind 240 Übergänge mit halbwegs vernünftigen Werten zu füllen - mal zwei (S-Video) macht 480, mal zwei (unterschiedliche VICs) macht 960. Allein das Erstellen der Tabelle ist nicht so prall, dann kommt aber noch ne Auswertung, wie man das in RGB darstellt (Farbraumwandlung ist zwar kein Ding, aber will auch gemacht werden).

Wie gut, dass die Hardware re-konfigurierbar ist - so ne PAL-Emu kann man später immer noch verfeinern, ohne dass der Kunde was löten muß. Wichtig ist erstmal, dass wir die 64us-Delayline emulieren, damit die Farbübergänge von Zeile zu Zeile stimmen.

Unseen:
Son langes Tape hab' ich zwar noch nicht gesehen, aber wenn Du unbedingt pr0n gucken musst, wird wohl die einzige Möglichkeit sein, ein Stück von der REU zugunsten des TAP-Bereiches zu opfern (eigentlich sollte die REU 16MB werden). Ich hatte erstmal an 2MB gedacht, die hätten wir sicher noch frei. Speichern auf Tape ist genau dann kein Problem in der Emu, wenn jedes Byte einen gleich langen Impuls darstellt. Die Impulse sind aber unterschiedlich lang, deswegen kannst Du unter Umständen z.B. mit einer 10 Sekunden langen Aufzeichnung einen zuvor 12 Sekunden langen Bereich überschreiben und umgekehrt. Um das zu umgehen, müsste man mit konstantem Takt (ideal: Prozessortakt) bit-weise über den TAP-Puffer gehen, was aber bei 2MB gerademal für 17 Sekunden ausreichen würde. Eine Implementierung von SAVE könnte ich mir nur dann "einfach" vorstellen, wenn man alles löscht, was beim Drücken von "record&play" *nach* der aktuellen (virtuellen) Bandposition kommt. Oder anders: Man kann nach dem Speichern nicht mehr auf play drücken, da kommt dann nichts mehr.

Jens

Im Kaufabsicht-Thread kam die Frage nach dem Sound-output, da will ich hier nochmal drauf eingehen:

Der Sound-out an Chameleon ist ein ganz einfacher Delta-Sigma-Wandler, der vom FPGA gesteuert wird. Er ist nach außen geführt als 3,5mm Stereo-Klinke, so wie bei PCs auch - daran kann man Aktivboxen anschließen, die zunächst die Floppy-Geräusche abspielen werden. In späteren Cores könnte man hier auch einen zweiten SID emulieren, aber grundsätzlich ist erstmal der SID im Computer die bessere Wahl.

Wer beide Sound-Ausgaben mischen will, der braucht einen externen Mixer. Mixer-Funktionen sind in Chameleon nicht geplant.

Jens

Richtig, das Ziel war nicht, die SCPU performancemäßig zu toppen, sondern im Rahmen der Möglichkeiten ein bischen mehr Speed 'rauszuholen. Da wir ohnehin eine externe 6510 CPU brauchen um interne Zustände außen verfügbar zu haben, können wir auch gleich den original-6510 abschalten und den Externen ein bischen schneller laufen lassen.

Erwartet keine Wunder bei der Geschwindigkeit - vielleicht 6 oder 8 MHz, aber definitiv _keine_ 20MHz. Die Speicherbandbreite limitiert uns, da wird ziemlich viel von für die Video-Ausgabe benötigt. Je geringer die VGA-Bildwiederholrate, desto mehr CPU-Speed, weil der ganze Speicher "shared" ist.

Vielleicht bekommen wir ja die Protovision-Jungs dazu, Metal Dust auf den Turbo-Mode von Chameleon zu portieren, dann ist die Killer-Anwendung für die SCPU nicht mehr exklusiv (oder braucht man die noch für was Anderes??). :bia:

Jens

Zitat von zealot

Kann man den Speed einstellen?

Ja, es gibt zwei Modes: Einmal einen C64-Mode-des-C128 kompatiblen 2MHz-Mode, der auch über das gleiche Bit wie auf dem 128er eingeschaltet wird (im VIC), und einen "fullspeed" mode, der sich wirklich wie ein "warp mode" anfühlt. Der 2MHz-Mode ist z.B. für die angepassten Versionen von Uridium oder Paradroid gut: Andrew Braybrook hatte damals Sonderversionen für den C64-Mode des C128 rausgebracht, die im oberen und unteren Rand auf 2MHz umschalten und so ein bischen mehr Speed 'rausholten (ich glaube das waren rund 30%). Zur Erinnerung: Wenn man immer auf 2MHz blieb, war kein vernünftiges Bild mehr zu sehen.

Zitat von zealot

Ich hatte noch nach MP3 gefragt. Das wirds wohl nicht geben oder "nur" über den Clockport mit dem existierenden MP3@C64?

Das MP3at64 wird auf Chameleon genau so schlecht passen wie auf dem MMCR auch: Eigentlich gar nicht. Und einen MP3 Decoder im FPGA werden wir sicher auch nicht machen. Die Anwendung "MP3 auf einem C64 abspielen" ist denkbar verspielt und wurde auch von den Kunden nur schlecht angenommen, denn in der Zeit ist der Computer für nichts Anderes zu gebrauchen. Auf heutigen Computern macht das Sinn, denn da kann man im Hintergrund abspielen und noch sinnvolle Dinge nebenbei machen, aber das werden wir auch auf Chameleon nicht hinbekommen. Wer beim Coden Musik hören will, der kann den TASS gern patchen, damit er SIDs abspielt, ist ohnehin viel stilechter

Jens

Zitat von skoe

Der Turbo-Modus beinhaltet die emulierte 1541, richtig?

Wenn das stimmt, kann man bei Programmen, die schnarchlangsam nachladen und einen eigenen Loader benutzen einfach mal kurz den Turbo reinhauen. Bei einem "normalen" Turbo, der nur im C64 säße und einer externen 1541 ginge das nicht.

Auch das ist Einstellungssache. Der Fullspeed-Mode holt raus was drin ist, aber Fastloader werden nur dann funktionieren, wenn die Floppy um den gleichen Faktor beschleunigt wird. Dabei ist zu beachten, dass die Floppy immer 1,4% schneller laufen muss als der C64, damit das Timing der Fastloader nicht durcheinander gebracht wird. Hier müssen wir auf jeden Fall Finetuning betreiben; nur die Erfahrung wird zeigen, ob "echter Warpmode" mit gleichzeitig beschleunigter 1541 auch zuverlässig zusammen spielt, denn *eigentlich* sind die timing-technisch voneinander abgekoppelt, damit sie dem Originalsystem möglichst nahe kommen.

Jens

Zitat von Diddl

oder wird die interne CeVi CPU immer deaktiviert?

Ja, außerdem nutzt Chameleon einen Modus der PLA, der bislang nicht dokumentiert ist. Eigentlich steht es schon in den Gleichungen der PLA, die ich vor Urzeiten veröffentlicht habe, aber scheinbar ist das niemandem vor mir aufgefallen.

Der C64 wird im Extremfall zur speicherlosen Peripherie degradiert. Die 64K können theoretisch rausgenommen werden, nur das Farbram sollte noch drin bleiben. Außerdem hast Du natürlich Recht, dass uns draußen am Expansionsport reichlich Signale fehlen ($01, Video-Adressen, Farbram-Daten), aber die kann man nachbilden (zumindest wenn man weiss, in welchem Zyklus was gemacht wird).

Basic/Kernal Roms sind gar kein Thema, die werden beim Starten einfach vom C64 ins Ram von Chameleon kopiert. Das Character-Rom ist schon ein bischen tricky, wenn man die interne CPU nicht bemühen will - geht aber auch ohne zu große Verrenkungen, schließlich läuft der Character-Rom Zugriff des VIC kompett über den statischen Adressbus, der wiederum am Expansionsport anliegt (*dafür* ist der LS373 auf dem C64-Board da!).

Das einzige Stück Voodoo ist also, bei den PLA-Gleichungen genau hinzugucken, und sich bei zwei ganz bestimmten Bauteilen im C64-Schaltplan mal die Frage zu stellen "warum ausgerechnet diese Werte?". Das werden Peter und ich wahrscheinlich in ein paar Monaten dokumentieren, wenn Chameleon auf dem Markt ist und die ersten paar Einheiten verkauft sind.

Jens

Zitat von Ace

Wenn man wirklich kein Platz mehr hat, wie wäre es mit einer aufsteckbaren Zusatzplatine ? Vielleicht mittels Flachbandkabel ? Ist im PC Bereich ja auch manchmal so üblich....

RR-Net ist in diesem Fall schon eine Tochterplatine, für die im Gehäuse Platz reserviert werden musste. Und Flachbandkabel sind für schnelle digitale Signale nicht wirklich geeignet - Chameleon hat reichlich Features und die kann man am Mini-DIN9 auch nochmal gut erweitern. "kein Midi" ist nicht gerade ein Showstopper, speziell wenn man's ohne Löten nachrüsten kann.

AREA51HT:
Die Platine wird im Gehäuse gut gehalten, dafür sind die kleinen Laschen und die Bohrung in der Mitte da. Außerdem macht man sich kaum eine Vorstellung, wie stabil eine Platine sein kann. Beim MMC Replay ist die Platine noch viel kleiner und hält seit langer Zeit bei hunderten Usern den täglichen, mehrfachen Druck auf Reset oder Freeze aus. Dieser Druck wird nicht schwächer sein, als das Gezerre an einem VGA-Kabel. Außerdem wiegt der C64 keine 50kg, bevor irgendwas von dem Material auch nur im Entferntesten an "abbrechen" denkt, rutscht der C64 vom Tisch oder das Modul aus dem Slot.

Jens

Zitat von spider-j

Mal ne blöde Frage: wozu ist MIDI OUT an nem C64 überhaupt gut? Also "IN" kann ich ja noch halbwegs verstehen - aber wer nutzt den C64 schon zur MIDI Steuerung?

Gute Frage - den C64 als Sequencer benutzen ist im Zeitalter von echt brauchbaren Programmen auf dem PC eigentlich sinnfrei. Ihn als Instrument zu benutzen ist aber sehr sinnvoll, weil nichts an den SID herankommt, was heutzutage so gebaut wird.

Chameleon ist aber nicht "exklusiv" für den C64, sondern hat auch nen Stand-alone Mode. In diesem Mode könnte man "alles" machen, eben auch eine Plattform, für die Midi-out sinnvoll ist. Und wenn man schon einen UART auf eine Clockport-Karte packt, kann man den Output auch gleich sinnvoll nutzen. Ich würde einen 16c550 nehmen, der einen etwas anderen Quarz bestückt ist, damit man die MIDI-Baudrate genau trifft. Anstelle von RS232-Pegelkonvertern kommen halt die Midi-üblichen Optokoppler zum Einsatz, damit wäre ein Design zu bezahlbaren Preisen gemacht. Blöd nur, dass man wieder mit Kabelpeitsche arbeiten muss, denn ein 5-pol DIN passt beim besten Willen nicht zwei mal an die Stelle, wo sonst der RJ45 vom RR-Net sitzt

Mal ne blöde Frage: Könnte eine Midi-Software auf dem C64 mit einem 16c550 umgehen? Die Meisten Midi-Interfaces haben damals den 6551 oder 6850 ACIA benutzt; sind die irgendwie register-kompatibel? Ich hab' weder Zeit noch Lust jetzt nen Bit-für-Bit Vergleich zu machen...

Jens

Zitat von skoe

Ist das da oben neben dem Audioanschluss ein IR-Sensor oder sowas?

Ja, und er ist auf die CDTV-Fernbedienung ausgelegt. Die ist für kleines Geld bei Vesalia zu haben und ist ein Zwischending zwischen Fernbedienung und game-Controller, deswegen finde ich sie ziemlich klasse. Leider hat Commodore eine kleine Besonderheit eingebaut: Die Fernbedienung nutzt eine Modulationsfrequenz von 40kHz, was die Wahl des IR-Empfängers stark einschränkt. Ich habe gerade erfahren, dass mein Wunschtyp nicht zu haben ist, und ich auf einen größeren Typen mit anderem Pinout ausweichen muß. Jetzt muß ich also die Platine nochmal verändern und wir werden damit leben müssen, dass der Empfänger rund 2mm aus dem Gehäuse herausragen wird. Vielleicht verbessert das ja die Empfindlichkeit

Lieferung der Musterplatinen ist im Plan, sollten kommende Woche hier eintrudeln. Ich habe gerade noch mit dem Platinenhersteller telefoniert.

Jens

Hmm.. dann muss ich mein Dilemma wohl ein bischen genauer beschreiben: Ich habe nicht genug Pins am Mini-DIN Stecker, der nach links Draußen führt. Der hat fünf Funktionen:

- PS2 Tastatur
- IEC Anschlus
- Alternative 1: Userport-Erweiterung (Parallelkabel-Emu)
- Alternative 2: PS2 Maus
- Power-Input für stand-alone Betrieb

Szenario 1:
Chameleon steckt am C64, da bekommt die Floppy-Emu natürlich einen Reset mit, denn das Signal ist vom Expansionsport her bekannt. Hier kann der PS2-Maus Anschluss mit einem kleinen Adapter mit dem Userport verbunden werden, so dass die fehlenden CIA-Leitungen für die SpeedDos/DolphinDos Emu vorhanden sind.

Szenario 2:
Stand-alone Betrieb; Ein geregeltes 5V-Netzteil wird an den Power-Input angeschlossen. Jetzt ist der IEC-Anschluss evtl. komplett ungenutzt, weil C64 und Floppy komplett in Chameleon sind; weitere Verbindungen werden wenn, dann nur zu speziellen IEC-Geräten hergestellt (Drucker, non-1541-Floppy). Nur die externen sonder-IEC-Geräte bekommen keinen Reset. Finde ich halb so wild, denn es ist nicht sehr populär, für diese Geräte Code zu schreiben, der per Reset wieder aus dem Speicher gekegelt werden muss.

Szenario 3:
Wieder Stand-alone Betrieb; diesmal aber ohne Computer, also Chameleon ist "nur Floppy", die man an einen C16, VC20, vielleicht aber auch an C64 oder C128 anschließt. So wird Chameleon auch zum Diskettenlaufwerk oder zur Festplatte für diese anderen Commodore-Systeme. Hier hätte ich jetzt die Wahl entweder Reset anzuschließen, oder SRQ zu beschalten, damit Burst-Transfers möglich werden. Bisher habe ich mich für SRQ entschieden, da Chameleon Taster hat und man im Bedarfsfall da drauf drücken kann. Dieser Mode wäre meiner Meinung nach am meisten eingeschränkt. Es wäre aber meiner Meinung nach eine ähnlich große Einschränkung, wenn SRQ nicht beschaltet wäre. Die Option auf "beides" habe ich nicht, weil 10-polige Mini-DIN Stecker und Buchsen zwar existieren, aber in der Praxis und in den hier benötigten Stückzahlen nicht zu bekommen sind.

Am liebsten würde ich jetzt von der Mehrheit von Euch hören, dass die Entscheidung "SRQ statt Reset" die Richtige ist. Oder Ihr lyncht mich jetzt alle und schreit ganz laut, dass SRQ zwar nice-to-have wäre, aber eben weit hinter einem "korrekten" Reset zurücksteht. Die Entscheitung fällt mit der Kabelbaum-Definition, die ich gerade schreibe und die ich vor heute Abend nach Taiwan schicken werde.

Jens

viele Stunden Löt-Arbeit:
proto_topview.jpg
proto_bottomview.jpg
proto_sideview.jpg

...und jetzt geht die eigentliche Arbeit erst los: Alle Funktionsgruppen prüfen. Mechanisch passt alles so wie ich's mir gedacht habe. Selbst der leicht gekippte Batteriehalter passt noch ins Gehäuse.

Jens

Zitat von Ace

Einzig mit der gelben Gehäusefarbe kann ich mich nicht anfreunden.

Die liegt aber in der Natur der Sache. Chameleons sind nunmal knallgelb, wusstest Du das nicht :-)?

Im Ernst: Meine Absicht war es, das Teil so auffällig wie möglich zu gestalten. Signalfarbe ist da die beste Idee; das fällt garantiert auf, wenn man auf ner Party mit dem Teil und nem Flachbildschirm irgendwo sitzt. Mal ganz davon abgesehen, dass andere Gehäusefarben im Moment komplett ausverkauft sind - ich habe nur noch ein paar wenige blaue Gehäuse, die aber auch schnell weniger werden, danach gibt's nur noch die Gelben. Neue Gehäuse machen steht aus finanziellen Gründem momentan außer Frage - allein das Werkzeug auf die Maschine zu spannen kostet mehr, als ich im Moment bereit bin, in den Retro-Markt zu stecken. Das liegt aber nur daran, dass ich im Moment so viel Geld in Chameleon stecke, irgendwann nächstes Jahr gibts auch wieder neue Gehäuse. Chameleon bleibt trotzdem knallgelb!

Die Schweden fanden die Kombination mit der Farbe der Taster ganz hübsch, als ich das Teil im September 2008 auf der BIT in Stockholm vorgestellt habe. Die haben richtig gegröhlt als ich sie gefragt habe wie sie die Farbkombination finden. Wundert mich total, dass Du das nicht nachempfinden kannst

Jens

Zitat von Unseen

Die Einbauweise des IR-Empfängers ist... öhm... "unkonventionell".

Aus der Not eine Tugend gemacht - es muss ein 40kHz-Empfänger sein, sonst kann man die coole CDTV-Fernbedienung nicht benutzen. Oder kennst Du irgendeine Fernbedienung mit Steuerkreuz, die wie ein Gamepad in der Hand liegt? Guckst Du hier.

Jens

Zitat von Cyberdyne

Sieht klasse aus! Kann man das Teil jetzt auch kpl. alleine betreiben? Sprich: Nur die gelbe Box, eine PS2-Tastatur, eine SD-Card und ein TFT-Moni und los gehts?

Ja, das geht. Der Kabelbaum hat neben den zwei PS2-Anschlüssen und dem IEC-Port auch ein USB-Kabel, das für ein iPod-Ladegerät gedacht ist (diese Netzteile mit USB-Stecker, die nichts weiter als 5V ausspucken). Damit wird das Teil versorgt und kann dann auch allein laufen - entweder als ganzer C64 mit Floppy, oder nur als Floppy für andere IEC-fähige Systeme. Das wäre ein C64 ohne Joystick-Ports, daher mein Drang, die CDTV-Fernbedienung kompatibel zu machen.

Zitat von Cyberdyne

Ist ein S-Video-Out möglich? Was ich will, kann man ahnen, oder?

Theoretisch könnten wir auch S-Video oder YUV ausgeben, aber so richtig will sich mir der Sinn darin nicht erschließen - ein VGA-Display ist weitaus billiger, selbst kleine TFTs werden schon unter 50,- EUR gehandelt. Warum will man sich dann eine Röhre hinstellen?
Ich zweifele außerdem an der Naturtreue dieses S-Video Signals, denn wir haben nur fünf Bit pro Kanone. Ob wir damit exakt die Pegel des VIC-II treffen müsste man im Detail messen. Womöglich müsste man da mit einem PWM-Verfahren das LSB pulsen, damit man Zwischenwerte erreicht. Extrem viel Aufwand für einen zweifelhaften Zeck...

Jens

Zitat von Ace

Boah, C64 Emulation gibts also inklusive ? Wie kompatibel wird dieser sein ? Denke mal , das wird so ne Lösung wie beim DTV ?

Der C64 wird ohnehin fast komplett in Chameleon abgebildet, weil uns sonst wichtige Signale bei der Video-Generierung fehlen würden. Die Frage nach "kompatibel" muss ich wohl mit "besser als der C128" beantworten. Software-Emulatoren haben wir schon überholt.

Jens

Zitat von Kratznagel

Sehe ich da auf dem dritten Bild eine Ethernet-Schnittstelle? Wird diese RR-Net-kompatibel sein?

Das "sideview" Bild zeigt Chameleon mit einem installierten RR-Net2, also mit der Version, die schon mit dem MMC Replay so hübsch passte. Die Form der Platine ist fast komplett vom MMC Replay übernommen. Die Ethernet-Schnittstelle ist nicht Bestandteil des Paketes, Chameleon wird ohne RR-Net geliefert.

Jens

Zitat von Ace

Verwendet hier jemand wirklich noch ne´n Drucker am C64 ?

Das würde ich auch gern wissen. Aber "for what it's worth": Wir haben so viel FPGA-Power, dass so ein reduzierter Rechner wie im MPS803 (oder ähnlichen) problemlos reinpassen würde. Ein bischen mehr Speicher und ein angepasstes Rom, dann könnte sich das Teil am IEC-Bus mit Geräteadresse 4 melden und die ausgedruckte Seite im Speicher ablegen. Die SD-Kartensoftware speichert das als TIF/GIF/PNG auf die SD-Karte und man könnte auf die Weise Dokumente "ausdrucken" und auf neue Medien übertragen, ohne dass Papier verschwendet werden muss, das man wieder einscannen müsste. Und Farbbänder für die alten Dinger gibts auch nur noch als selbst-Auffüller...

Wer opfert sich für so eine Software?

Jens