C16 FPGA projekt

Jäger und Sammler

Monday, October 12th 2009, 4:24pm

Ich glaube du verwechselst mich?! Ich weiß nix von Core-Compilieren aber DoReCo war schon nicht schlecht! Ich sage nur: Notebook und Cola!

Aber unser letztes Treffen war CC08, oder?

Maus:
Das mit der 1351 Maus war eigentlich nur ein Gag aber wenn es das mal gibt, würd ich es auch nutzen!

SD-Karte:
Eine kpl. 1541 Emulation wäre toll aber ob so eine 1541U noch zusätzlich da rein passt?! SD2IEC Funktionalität wäre auf jeden Fall besser als nichts! IEC-Bus ist nice-to-have aber ich müsste dann doch noch zusätzlich ein SD2IEC einbauen und nur ein Card-Reader ist eine deutlich sauberere Lösung. Hast du eine Ahnung, ob an sowas bereits gearbeitet wird?

S-Video-Out:
Das ist für mich das KO-Kriterium. Ohne S-Video-Out kann ich nix machen, da ich im Brotbook nur per S-Video das TFT betreiben kann. Wenn es denn mal ein S-Video-Out gibt, wäre dass dann eine Einzellösung für einen bestimmten Core oder wäre dass dann gleich für A500, C64, VC-20 und C16/116/+4 nutzbar?

Sind das zur Zeit alle Cores oder gibt es auch schon den CPC Core für den Minimig? Vielleicht noch andere Sachen wie ZX81 oder Spectrum oder sowas? Hier trau ich mich von ST nicht zu sprechen.

Hoffentlich wird das was mit dem FPGA16!

Go to the top of the page

boing4000

Trainee

Posts: 159

22

Monday, October 12th 2009, 8:15pm

Yep, da habe ich Dich doch glatt verwechselt

Jedenfalls kennen wir uns trotzdem in Sachen Notebook.

Zur SD Karte usw. kann ich nur sagen: Es muss programmiert werden. Der ARM oder PIC braucht dazu eine angepasste Firmware.
Mit ganz ganz viel Bastelei kann man auch die bestehende Firmware so "verwenden", dass es ohne Umprogrammierung funktionieren könnte. Vom Prinzip her geht alles, nur wer codet das alles? Für meine Zwecke reicht der IEC Bus am Minimig aus. Dort kann man jedes IEC Gerät vom C64 usw. anschliessen und nutzen. Alle anderen Umbauten müssten eine andere Lösung wie z.B. SD2IEC einsetzen.

S-Video war für den Amiga nie geplant und Dennis van Weeren hat auch "nur" den RGB Part behandelt und per Scandoubler VGA tauglich gemacht. Das Minimig ITX Board besitzt einen S-Video out, die aktuelle Firmware unterstützt den verwendeten Wandler-IC. Das kann man wohl auch im C64/VC20 etc. einbauen.

Von anderen Portationen wie CPC, (S)NES und einen ZX-Spectrum Core habe ich schon mal gelesen. Der Jenige möchte die Core' aber nicht rausrücken. Angeblich wurde auch nicht viel dran gemacht, ausser die Pinnung und das Clockmodul angepasst. Doch finde ich nirgends eine Webseite mit den Sourcen von diesen Systemen.
Ein Atari-ST Port (aus Suska) sollte auf dem Minimig ebenfalls funktionieren. Der real vorhandene 68000er ist dann wieder ein Vorteil und der FPGA schluckt den ST-Core mit Leichtigkeit

Doch interessiert mich sowas auch nicht sonderlich.

Zum F16/FPGA16:
Dank der Infos zum TED werde ich mich bei Gelegenheit an das erste Videotiming machen. Irgendwie "träume" ich von einer C16 Re-implemenatation, egal ob nun von mir oder von jemand anderem, Hauptsache es geht

So schwer kanns das auch nicht sein, denn der C64 ist bei weitem komplexer und der VIC20 kommt ca. an den C16 heran.
Sobald eine erste Videoausgabe funktioniert, werden Bilder folgen!

(Wieso schaffe ich es nicht einen Beitrag zu verfassen, ohne ihn noch editieren zu müssen

)

___________________

This post has been edited 1 times, last edit by "boing4000" (Oct 12th 2009, 8:38pm)

Go to the top of the page

boing4000

Trainee

Posts: 159

23

Tuesday, October 13th 2009, 2:20pm

Quoted from "Nichtsnutz"

Da diese Frequenz aus den 17.73 nicht so leicht hervorgeht,denke ich mal dass da 7.09MHz benutzt werden.(4.433 * 4/5 = 3.54 * 2 = 7.09).Das ergibt zwar eine etwas laengere Zeile (64.2us), wird wohl noch toleriert werden !? Zusammen mit den Informationen auf den Seiten 11/12 koennte man schon erste "Bildversuche" machen...

Die 64.2us aus 7.09MHz sollten innerhalb der tolleranz liegen. Zudem kann man diese Frequenz ganz einfach aus dem Basistakt gewinnen: ((4.433 * 16) / 10) = 7.092MHz.
Ideen und Lösungen fallen mir leicht, aber die Umsetzung in HDL (Screibweise, Syntax, Kleinigkeiten etc.) nicht so sehr. Da verliert man schnell die Lust, wenn man eigentlich nicht zum programmieren kommt und sich nur mit der verzwickten Schreibweise rumärgert.
Naja, etwas mehr Übung tut dem sicher gut, aber natives 68000er assembly ist mir wirklich lieber.

___________________

Go to the top of the page

Nichtsnutz

Beginner

Posts: 40

Date of registration: Mar 4th 2009

Location: Niedersachsen

24

Tuesday, October 13th 2009, 4:04pm

Hallo boing4k,

nun bin ich kein Experte in VHDL,aber ich wuerde es folgendermassen angehen:Mit einer der DFS Einheiten im Spartan3 wuerde ich 8 * 4.433MHz erzeugen.Alle anderen Takte wuerde ich daraus ableiten,als sogenannte "clock enable" Signale.Diese sind nur einen Haupttakt lang.Man bekommt somit einen vollsynchronen Entwurf.Intern benoetigt man nicht unbedingt Takte mit 50% Tastverhaeltniss.
Mit VERILOG kenne ich mich leider nicht aus,ich habe mich nur mit VHDL beschaeftigt.Es folgt ein bischen *ungetestete* Praxis:

Source code

[font='Courier New, Courier, mono']
  signal vcke      : unsigned(2 downto 0);
  signal ven       : std_logic;
  signal h_counter : unsigned(8 downto 0);
  signal h_rst     : std_logic;

  ------------------------------------------------------------------
  -- 8 x 4.433MHz durch 5 Teilen um ein enable mit 7.09MHz zu
  -- bekommen.
  ------------------------------------------------------------------
  PROC_VIDEO_ENABLE:
  process (clk) begin
    if rising_edge(clk) then
      if (vcke = 4) then
        vcke <= "000";
      else
        vcke <= vcke + 1;
      end if;
    end if;
  end process;

  -- video clock enable --------------------------------------------
  ven <= '1' when (vcke = 4) else '0';
  ------------------------------------------------------------------
  ------------------------------------------------------------------
  -- Horizontaler Pixelzaehler.Zaehlt von 0..455 also 456 Takte.
  -- Wird mit "ven" weitergeschaltet laeuft also mit 7.09MHz.
  ------------------------------------------------------------------
  PROC_HCOUNTER:
  process (clk) begin
    if rising_edge(clk) then
      if (ven = '1') then
        if (h_rst = '1') then
          h_counter <= (others => '0');
        else
          h_counter <= h_counter + 1;
        end if;
      end if;
    end if;
  end process;

  h_rst <= '1' when (h_counter = 455) else '0';
  -------------------------------------------------------------------

[/font]

Aus dem horizontalen Zaehler leitet man dann die Austastimpulse aus u.s.w ... :blah!

Gruesse

Zuerst wurde ich geboren,dann geschah eine Weile gar nichts.

Go to the top of the page

boing4000

Trainee

Posts: 159

25

Tuesday, October 13th 2009, 4:37pm

Hi Nichtsnutz,

schönen Dank für das praktische Beispiel der Bilderzeugung! Das ist schon mal ein guter Anfang

Da muss ich mich erst mal reinfinden, denn VHDL ist für mich halt "das Unbekannte". Generell ist die Funktion schon logisch, nur könnte ich sowas nie selber generieren, weil mir diese Syntax echt fremd ist. Da fehlt mir wohl der nächste Schritt von "lesen und verstehen" bis zu "eigene Schaltungen generieren".

EDIT: Die Frage zum Code hat sich geklärt

Evtl. bastel ich mir die Schaltung in Verilog um, denn so einfach kann man z.B. das Toplevel Modul nicht von einem Accent in den anderen umwandeln. Oder gibt es Tools/Scripte zur Wandlung von VHDL<>Verilog? Die Mischung von beiden Accenten in einem Projekt ist anscheinend auch nicht möglich.

Das Clockmodul (ich kenne es nur als DCM" mit 7.09MHz Erzeugung ist soweit kein Problem. Doch der TED braucht trotzdem die 17.733MHz, wenn ich es richtig deute? Ein zusätzlicher Scandoubler braucht dann 2*17.733MHz, diese 35.464MHz habe ich ja erzeugt.
Mit einem 2. DCM könnte man auch wieder neue saubere Takte (ohne Teiler) erzeugen, daher sollte das schon gehen.

Schade das es keinen Neuralscanner (aus Enterprise) gibt, wobei mir nur denken muss und schon wird es umgesetzt

Dann eben weiter tippern und etliche Übersetzversuche machen, bis die liebe Syntax auch haarklein stimmt.

___________________

This post has been edited 1 times, last edit by "boing4000" (Oct 13th 2009, 5:01pm)

Go to the top of the page

dirk

Intermediate

Posts: 334

Date of registration: May 29th 2006

Location: OWL

26

Tuesday, October 13th 2009, 8:51pm

Quoted from "boing4000"

Von anderen Portationen wie CPC, (S)NES und einen ZX-Spectrum Core habe ich schon mal gelesen. Der Jenige möchte die Core' aber nicht rausrücken. Angeblich wurde auch nicht viel dran gemacht, ausser die Pinnung und das Clockmodul angepasst. Doch finde ich nirgends eine Webseite mit den Sourcen von diesen Systemen.

Hier gibt es Infos u.a zum ZX Spectrum Core.
http://zxgate.sourceforge.net/
Sourcen ohne Roms. http://rapidshare.de/files/48515913/zxgate.zip.html
Die Sourcen sind leider bei zxgate nicht mehr herunterladbar. Aber ich habe, als sie noch verfügbar waren, das gesamte Paket gesichert.
Hieraus habe ich den Spectrum Core für den C-One und DE1 portiert und probiert. Auf dem DE1 Board funktioniert das Laden von Kassette über einen freien FPGA Eingang.

Go to the top of the page

boing4000

Trainee

Posts: 159

27

Tuesday, October 13th 2009, 10:05pm

Hi Dirk,

vielen Dank für den Link, den Source werde ich mir bald anschauen und (je nach Möglichkeit) auf dem Minimig portieren. Sowas scheint erst mal eine gute Übung zu sein

Einen Datasetten-pin muss der C16 auf jeden Fall auch bekommen! Einige Games habe ich nur im Original auf uralten kasetten. Die sollen natürlich auch auf dem F16 laufen. Ansonsten müsste man sich eine art Samplemaschine bauen um die Daten von Tape digital abzuspeichern.

___________________

Go to the top of the page

Schmitti

Professional

Posts: 897

Date of registration: May 8th 2006

Location: Deutschland

28

Friday, October 16th 2009, 7:06am

Hier eine Anmerkung zum VHDL-Code und sinngemäß natürlich auch für Verilog-Code gültig:
In Zeile 14 würde ich auf >= abfragen. Das ergibt ein fehlertolerantes Design, wenn der Zähler (warum auch immer) auf einen Wert größer als 4 fallen sollte. Die Routine fängt sich dann schneller wieder, als wenn ich warten muss, bis der Zähler über den Überlauf wieder bei 0 ankommt. Das kann oft hiilfreich sein.
Ansonsten sieht der VHDL-Code sauber aus.

Go to the top of the page

Wiesel

mit der Lizenz zum Löten

Posts: 1,039

Date of registration: Dec 9th 2004

Location: in der Wildnis

29

Friday, October 16th 2009, 10:13am

Meiner Meinung nach ist das der falsche Ansatz. Das liest sich so, als würdet Ihr nicht nur das Rad neu erfinden, sondern die Radmuttern.

Ich fang' mal vorne an: Der 264 ist als Nachfolger des C64 gedacht gewesen - billiger und besser sollte er sein. Die Vorgabe bei der Entwicklung war "weniger Customchips", weil die den Großteil der Kosten verursacht haben. Der 264 ist *komplett* aus dem Wissen des C64 entstanden, demnach muss man ein bischen was über den C64 wissen:

- der 6510 ist ein 6502 mit "angeflanschtem" 6-Bit IO-Port und tri-states für Daten und Adressen, sowie der R/W Leitung.
- Der VIC-II wurde in zwei Teams entwickelt: Eine Character- und eine Sprite-Engine, die erst in der letzten Phase der Entwicklung zusammengeführt wurden.
- der SID wurde von einem ganz anderen Team entwickelt (wobei einige Mitglieder auch am VIC-II gearbeitet haben, aber das tut nichts zur Sache)

Jetzt der 264:
Der 8501 Prozessor ist ein gepimpter 6502 mit mehr Ports und der unsauberen Pin-Spar-Maßnahme, dass kein Phi2 out generiert wird. Gepimpt deswegen, weil er auf ca. 2 MHz läuft und ansonsten die gleichen Zusatzmaßnahmen hat wie der 6510: Port (diesmal 8 Bits) und tristate für Adressen, Daten und R/W. NMI wurde auch gleich wegrationalisiert, weil der Custom-Chip (CIA) für die Generierung ohnehin nicht drin ist. Illegale Opcodes sind identisch mit denen des 6510 und werden ganz sicher auch in Demos und Spielen benutzt. Bei den "instable" opcodes müsste man vielleicht noch genauer untersuchen, was aufgrund der höheren Geschwindigkeit passiert - vielleicht sind die ja gar nicht mehr so instable :-)

Der TED ist ein heruntergeschnittener VIC-II. Die Sprite-Engine wurde entfernt und die 12-Bit Logik des VIC-II wurde auf 8-Bit reduziert, jedoch im Tempo verdoppelt. Damit wurde es möglich, das Farb-Ram ins normale Ram zu legen. Der 40x12-Bit Badline-Puffer des VIC-II wurde auf 40x16 Bit aufgeblasen, ansonsten wurde am Character-Timing gegenüber dem VIC-II nichts, aber auch gar nichts verändert. Borders öffnen, Rasterzeilen-IRQs, das ist alles identisch mit dem C64. Einige Democoder haben sogar Teile des VIC-II auf dem plus/4 reverse-engineert, weil die CPU da schneller ist - die Ergebnisse waren 100% auf den C64 übertragbar und sind hin und wieder auch in Emulatoren eingeflossen.
Die Ausgabe-Einheit des TED ist aufgrund der größeren Datenmange die pro Pixel zur Verfügung steht auch einfacher geworden. Da Du aber auf RGB abbilden willst, wird die Sache nochmal sehr viel angenehmer - Du nimmst ein Blockram dafür.

Jetzt das Timing: Nach der Vorgabe "weniger Customchips" wurde wohl auch der 8701 wegrationalisiert, aber ich vermute, dass der komplett in den TED gerutscht ist. Ich vermute daher weiter, dass das Timing für die CPU nicht "Basistakt durch 10 oder durch 20" ist, sondern "Basistakt durch 9 oder durch 18", so wie es beim C64 der Fall ist. Nur so kann das Speichertiming von einem nahezu unveränderten Character-Core des VIC-II erzeugt werden. Speicherzugriffe sind nicht wie beim C64 500ns lang (ca. 2MHz), sondern 250ns (ca. 4MHz). Man bedenke, dass der C64 in einer Zeit entwickelt wurde, als die Rams noch 350ns Zugriffszeit hatten. Es hat aber nicht lange gedauert, bis die ersten 200ns-Rams zu haben waren, darauf hat der 264 aufgebaut.

Mein Ansatz würde also lauten:

- 6510 core nehmen, Port erweitern, NMI streichen, Geschwindigkeit spielt bei heutigen FPGAs keine Rolle -> 8501 fertig.

- VIC-II core nehmen, Sprites herauskürzen, Badline-Puffer aufblasen, Anzahl Speicherzugriffe verdoppeln -> Video-Teil des TED fertig

- Der 6529 ist der simpelste aller Portbausteine, wer den nicht in ein paar Zeilen VHDL hinbekommt, ist nicht für dieses Projekt geeignet.

- der Rest des C16/C116/plus4 ist 74er TTL-Logik, also praktisch "Quelltext" für den FPGA

Bleibt das Random-Register des TED, sowie der Sound. Sound hat keine Filter, da kann man sich kenntnismäßig bei den Emulatoren umgucken. Ich würde vermuten, dass es ein Haufen Addierer ist, ähnlich wie beim SID. Das Random-Register ist eine Leiterschleife, die im Chip "ein paar mal umhergelegt" ist, damit die Abstrahlung des Chips als Random-Quelle genutzt werden kann. Das ist vermutlich nicht 100% random, sondern sogar sehr deterministisch wenn man's genau untersuchen würde, aber zur Überbrückung dieser genauen Untersuchungen würde ich es durch ein einfaches LFSR ersetzen, dann ist auch dieser Teil des TED gegessen.

Mit den ganzen Vorkenntnissen die man aus der C64-Welt hat, klingt das ziemlich einfach. Da jedoch nichts so schwer ist, wie sich in fremde Quelltexte einzulesen, wäre mein Ansatz (und damit mein Angebot) ein Anderes:

Ich baue einen Adapter, mit dem die Hardware von Indivision ECS an den TED eines laufenden C16 angeschlossen werden kann. Der FPGA (ein Altera EP1C3) könnte dann auf dem Bus "lauschen" und eine TED-Implementierung könnte ihr eigenes Bild generieren (ähnlich wie Chameleon auf dem C64). Zunächst in 15kHz, damit man nicht gleich nen SD-Ram Controller mit coden muss. Der Indivision ECS wäre dann ein Zombie, weil der CPLD natürlich umprogrammiert werden muss, aber es geht ja schließlich um Entwicklung, nicht um ein Endprodukt.

Selbst wenn Ihr dieses Angebot nicht annehmt, sollte der Weg auf jeden Fall über die Quelltexte von FPGA64 laufen, das spart *viele* Monate Arbeit.

Jens

Go to the top of the page

Nichtsnutz

Beginner

Posts: 40

Date of registration: Mar 4th 2009

Location: Niedersachsen

30

Friday, October 16th 2009, 1:09pm

Hallo Wiesel,

erstmal vielen Dank dass Du Dir die Zeit nimmst hier zu schreiben.
Ich kann was dieses Projekt angeht nur fuer mich schreiben.Ich kenne mich mit den internern des C64 sogut wie garnicht aus.Die FPGA64 Implementierung von Peter ist mir bekannt,ich hatte auch mal in die Quelltexte hineingeschaut und gestaunt! Das ist fuer mich noch viel zu hoch.Ebenso die Sachen die tobiflex auf dem COne macht.Ich mache es nur zum Spass,ein bischen Digitaltechnik,ein bischen hier im F64 Fachsimpeln.Eine Implementierung wie Du sie vorschlaegst kann ich nicht leisten,dass muss ich ehrlich sagen damit keine falschen Erwartungen hier entstehen.Was ich leisten kann in loser Folge waere z.B:
Messungen an dem TED mit einem LogicPort vorzunehmen.Das hatte ich schonmal angefangen.Ich hatte ein bischen an der CPU gemessen.Da der LP nicht genug Speicher hat ein Frame zu speichern sondern vielleicht gerade eine Zeile,wollte ich mir mit einem CPLD und LM1881 einen Zeilensync separator zum Triggern bauen,damit ich auf einzelne Zeilen Triggern kann.
Danach auf der Grundlage der vorhandenen Doku einzelne Funktionseinheiten des TED nachbilden: PAL Raster,erstmal nur stabiles Fernsehbild,danach einzelne Farbregister dazu,einfache Speicherzugriffe um Zeichen auf dem Bildschirm zu bekommen, u.s.w.
Also doch eher wie Du schreibst auch die Radmuttern erfinden! Ich will etwas lernen und man lernt am besten indem man selber macht und natuerlich dabei auch auf die Schnauze faellt.Und als Freizeitbastler muss ich auch die Zeit fuer all das haben...
Ich hoffe da auf wohlwollen Seitens der Experten hier.
Und noch ein bischen zum Thema:
Das Timing ist wohl das wichtigst um ueberhaupt anfangen zu koennen.Den 1/10 , 1/20 CPU-Takt habe ich mir aus den TED Datenblatt Angaben zusammengerechnet.Dort steht als PHI_OUT CPU Frequenz 886,7KHz was bei 17,7344MHz Haupttakt 1/20 ist.Ich hatte mir auch gedanken zu all den anderen Takten die man brauch gemacht:
Videotakt: 7.09MHz , das passt mit 17,7344 * (2/5) und den 456Takten pro Zeile.
CPU_FAST : 7.09 / 4 = 1.77MHz
CPU_SLOW : 7.09 / 8 = 886KHz
AUDIO : 7.09 / 64 = 110,8KHz
Einfacher linedoubler fuer 50Hz VGA : 2*7.09 = 14.18MHz.
Ich hoffe ich habe nichts vergessen.Ich wollte daher mit einem 17.73MHz Quarz erstmal * (8/5) = 28.36MHz erzeugen und fuer alles andere mit clock enables arbeiten.
Vielleicht hat es ja Commodore tatsaechlich so gemacht,da die Teiler die sich ergeben einfache Zweierpotenzen sind,die man ohne Tricks von einem Zaehler abgreifen kann 14.18 / (2,8,16,128 ) .
Nun, soviel von mir.Es haben ja noch ein paar andere Interesse bekundet...

Gruesse

Zuerst wurde ich geboren,dann geschah eine Weile gar nichts.

Go to the top of the page

boing4000

Trainee

Posts: 159

31

Friday, October 16th 2009, 2:25pm

Hi Jens,

auch von mir vielen Dank für die wirklich ausführliche Erklärung und Gegenüberstellung zum C64.
So genau kenne ich die 8Bit C= Welt nicht, um diese doch sehr starken Gemeinsamkeiten herausgesehen zu haben. Eine gewisse Ähnlichkiet der Systeme hatte ich schon vermutet, aber nicht in diesem Ausmass!

Wenn man das VIC-II Videotiming tatsächlich annähernd übernehmen kann, werde ich dies auf jeden Fall ausprobieren. Leider liegt mir VHDL wirklich nicht, das gibt ne Menge Verwirrung. Ebenfalls fehlt mir momentan die pratische Übung um sowas umzusetzen. Verilog wäre mir daher wesentlich lieber, daher der Gedanke an die "Neuerschaffung", evtl. aus dem Abschauen vom FPGA64.

Mich wundert dann nur der Unterschied in der Größe des "Charbereich". Beim C64 sind die vertikalen Ränder viel breiter als beim C16, obwohl beide die gleiche Menge Zeichen/Zeile besitzen. Dies tritt zumindest beim echten PAL 170x Monitor auf!
Oder ist das nur auf die unterschiedlichen Videoausgabe (Badline Puffer) zurück zu führen?
Im Emulator (Linux vice) kann man beide Rechnerfenster übereinander legen und sieht wirklich keinen Unterschied in der Größe der Rahmen und des Charfensters. Daher scheint das Videoverhalten tatsächlich sehr ähnlich zu sein (zumindest emuliert).

Dein Angebot zum Indivision ECS klingt gut und ich hatte sowieso mit dem Gedanken gespielt mir einen solchen anzuschaffen.
Bleibt die frage wie Du diese Mitarbeit siehst. Der C16FPGA (oder F16) soll open source sein, damit jeder die Möglichkeit hat, den Core auf andere Plattformen zu übertragen. Wenn das für Dich OK ist, wird Dein Mitwirken willkommen sein.

Da mir momentan meine Gesundheit (Rücken/Bandscheibe) etwas zu schaffen macht, bin ich nicht 100% bei der Sache. Doch besteht weiterhin der Wunsch einen C16 Softcore einsetzen zu können, egal von wem er realisiert wird

___________________

Go to the top of the page

boing4000

Trainee

Posts: 159

32

Friday, October 16th 2009, 2:38pm

@Nichtsnutz

Grundlegend sehe ich es auch wie Du. Man möchte bei so einer Sache etwas lernen und natürlich seine Freude haben. Wenn auch nur die kleinsten Sachen funktionieren, freut man sich wie ein Kind. Deine Schritte zur Realisierung entspricht auch meiner Sichtweise, daher würde man wirklich Rad + Muttern + Nabe neu erfinden

. Nur ist es viel viel mehr Arbeit und man weiss nicht, ob überhaupt etwas "brauchbares" dabei herum kommt.
Die Implementation des TED war in meinem Empfinden leichter als eine passende CPU anzugleichen. Doch wie es laut Jens aussieht, ist die CPU mit einigen (gewussten) kleinen Änderungen schon vorhanden. Der TED braucht etwas mehr Anpassung, aber möglich ist es.

Persönlich stehe ich jetzt vor 2 Bergen:
1. VHDL und der FPGA64 - "leichte" Anpassung und schon wäre ein C16FPGA verfügbar
2. Neuerschaffung des TED usw. in Verilog - viel Arbeit und viel Zeitaufwand

Welche Lösung auch immer stattfindet, das Hauptziel ist wie gesagt: Ein frei portierbarer C16 im FPGA

___________________

Go to the top of the page

Wiesel

mit der Lizenz zum Löten

Posts: 1,039

Date of registration: Dec 9th 2004

Location: in der Wildnis

33

Saturday, October 17th 2009, 12:30pm

Traue keinem Timing, das Du nicht selbst gemessen hast... die Gerüchte über die Identität des Character-Generators sind nicht wirklich so, wie ich sie in meinem Posting von Donnerstag dargestellt habe. Eine Verwandschaft ist sicher noch erkennbar, aber die "einfach doppelte" Geschwindigkeit beim Speichertakt stimmt schlicht und einfach nicht.

Das Setup: Einfach Pins an die interessanten Leitungen angelötet um den Logic analyzer drauf zu stecken:
index.php?page=Attachment&attachmentID=23093

Trigger auf BA um eine Badline zu finden, ergibt gleich die erste Überraschung: Es sind zwei Badlines.
index.php?page=Attachment&attachmentID=23094

Einen Schritt zurück, hier sieht man, wie zwei Badlines von sechs normalen Zeilen gefolgt sind:
index.php?page=Attachment&attachmentID=23095

Der Beginn einer Badline ist wohl nochmal mit ein paar interleaved-Speicherzugriffen gespickt:
index.php?page=Attachment&attachmentID=23096

Ein CPU-Speicherzugriff herausvergrößert zeigt, dass das Verhältnis wirklich 1/10 und 1/20 ist:
index.php?page=Attachment&attachmentID=23097

Nur der Vollständigkeit halber: Ein TED Speicherzugriff.
index.php?page=Attachment&attachmentID=23098

Go to the top of the page

Wiesel

mit der Lizenz zum Löten

Posts: 1,039

Date of registration: Dec 9th 2004

Location: in der Wildnis

34

Saturday, October 17th 2009, 12:32pm

und in einem VBlank legt die CPU richtig Kohlen auf:
index.php?page=Attachment&attachmentID=23099

Eine einzelne Zeile im Detail zeigt, dass der TED wohl auch außerhalb des Textfensters noch ein bischen Daten aus dem Speicher holt:
index.php?page=Attachment&attachmentID=23100

Eigentlich müsste man jetzt nochmal die Pixelclock messen, aber ich mach' jetzt Wochenende.

Jens

Go to the top of the page

Nichtsnutz

Beginner

Posts: 40

Date of registration: Mar 4th 2009

Location: Niedersachsen

35

Saturday, October 17th 2009, 1:40pm

Hallo Wiesel,

vielen Dank für die Timings.Du bist ein Profi.Deine Messungen bestätigen das was ich auch gemessen hatte.Ich habe allerdings keinen derart leistungsfähigen L.A.Ich habe auch ein Bild von zwei Badlines angehängt.Es steht auch im TED Manual so.Dort wird es back-to-back DMA genannt: Zitat:"If last DMA was row 8 of character,then DMA for row 1 of next character is initiated.".Zusammen mit den dazwischen ligenden 6 normalen Zeilen ist das wohl eine char-box.
Das mit dem 1/20 hatte ich auch so gemessen.Im Bild unten rechts sieht man "CLK1->Cycles A->B = 20".CLK1 ist der 17.73 Haupttakt.

Ich "verzweifele" gerade an etwas anderem was ich angefangen habe und da ich immer nur eine Baustelle auf dem Tisch haben mag,dauert es bei mir damit noch ein bischen mit dem C16.Habe ihn aber wieder hochgeholt und aufgeschraubt!

Ok,dann erstmal schönes Wochenende.
Vassilis

index.php?page=Attachment&attachmentID=23102 index.php?page=Attachment&attachmentID=23103

Zuerst wurde ich geboren,dann geschah eine Weile gar nichts.

Go to the top of the page

boing4000

Trainee

Posts: 159

36

Saturday, October 17th 2009, 2:58pm

Ebenfalls vielen Dank für die Mühe und Messungen Jens!

Das macht die ganze Sache zwar durchsichtiger, dafür aber auch komplexer. Evtl. muss man doch einen Teil des Rades und der Muttern neu erfinden. So wie ich es einschätze, wird das eine grosse Anpassungsarbeit an den FPGA64 Core. Für mich ist das momentan nicht machbar, mangels Übung/Durchblick in VHDL.

Die Neuerschaffung in Verilog wäre mir persönlich noch am angenehmsten, dann ist es eine saubere Sache. Bei Gelegenheit werde ich mir die Sache mal vornehmen um zumindest ein PAL Timing-Gerüst als Basis zu haben.

Das Sammeln von Informationen ist ebenfalls wichtig um ein Projekt zu realisieren!
Das Ziel ist genannt, daher bin ich weiterhin über jede Mitarbeit, Hilfe und Info dankbar

___________________

This post has been edited 2 times, last edit by "boing4000" (Oct 17th 2009, 3:21pm)

Go to the top of the page

boing4000

Trainee

Posts: 159

37

Saturday, October 17th 2009, 6:43pm

Quoted from "Wiesel"

Eine einzelne Zeile im Detail zeigt, dass der TED wohl auch außerhalb des Textfensters noch ein bischen Daten aus dem Speicher holt:

Das ist mir auch schon aufgefallen. Ebenso scheint es zum Ende jeder Scanline im oberen/unteren Rahmen auch zu einem anderen Timing oder CPU/TED Busverhalten zu kommen. Hier Splitbilder, damit man die Details besser erkennt.

Oberer Rahmen:
index.php?page=Attachment&attachmentID=23112 index.php?page=Attachment&attachmentID=23113

Unterer Rahmen:
index.php?page=Attachment&attachmentID=23114 index.php?page=Attachment&attachmentID=23115

Der Code (hier ab Adresse $1000) lautet:

	Source code
1 2 3 4	SEI LDA #$00 STA $FF19 JMP $1003

Es scheint als würde die CPU kurz vor dem Scanline Ende auf "Framespeed" abgebremst zu werden. Die Dotabstände an den seitlichen Rahmen entsprechen den selben Abständen wie kurz vor dem oberen/unteren Rahmenende. Den selben Effekt kann man ausserdem im vice Emulator ("xplus4" unter Linux) nachstellen. Somit ist das Busverhalten im Emulator (Quellcode) auch ein Anhaltspunkt.

___________________

Go to the top of the page

Wiesel

mit der Lizenz zum Löten

Posts: 1,039

Date of registration: Dec 9th 2004

Location: in der Wildnis

38

Thursday, December 31st 2009, 5:44pm

Lustig, dieses Thema ist als "erledigt" markiert - da bin ich anderer Meinung :-)

Ich hatte versprochen, dass ich die Pixelclock noch messe, damit die Annahmen auch durch etwas Handfestes belegt werden. Das habe ich gerade gemacht: Den Bildschirm mit dem 4x4 Karomuster gefüllt und den Video-Ausgang gemessen. Die Frequenz die dabei 'rauskommt ist ca. 1,77MHz. Ein 4x4 Schachbrettmuster bedeutet, dass immer 2 Pixel schwarz und 2 Pixel weiß sind. Die Pixelclock ist demnach vier mal so hoch, also rund 7,08MHz.

Um das aus der Basisfrequenz von 17,7344MHz zu generieren, schaltet der TED intern auf der steigenden und der fallenden Flanke des Taktes. Um also im FPGA etwas nachzubilden, was mit clock-enables arbeitet, braucht man die doppelte Frequenz, also 35,4688MHz.

Damit dürfte das Basistiming in ein paar Zeilen Code gemacht sein, ein gutes Stück einfacher als beim C64, weil keine PLL notwendig ist. Ich hab' aber noch ne ganz andere Idee, für die ich gleich noch nen anderen Thread auf mache.

Jens

Go to the top of the page

controlport2

Супер Mодератор

Posts: 6,354

Date of registration: Nov 25th 2002

Location: DO

39

Thursday, December 31st 2009, 10:28pm

Quoted

Lustig, dieses Thema ist als "erledigt" markiert

Nicht mehr.

Hier sind viele Themen bereits als erledigt markiert, das kommt noch vom Boardupdate. Ich schau schon, dass ich das rausnehme wenn ichs sehe.

Bin kein richtiger Sammler - mehr so ein 'Haber'...SYS64738
FOSFOURMC: "Fantastic Operating System For Oldschool Users Running Modern Computers"

DoReCo-Homepage :!:

Go to the top of the page

Wiesel

mit der Lizenz zum Löten

Posts: 1,039

Date of registration: Dec 9th 2004

Location: in der Wildnis

40

Thursday, December 31st 2009, 11:16pm

Na dann versehen wir wenigstens weitere Teilbereiche als "erledigt", denn ich habe meine Messungen am TED-Ausgang fertiggestellt. Ziel der Messungen war es, den Farbraum des TED zu kennen, nachdem ich den ganzen Tag über PAL-Farbkodierung gelesen habe.

Der TED scheint in Sachen Farbe vom Prinzip her doch sehr viel vom VC20 und dem C64 geerbt zu haben. Der größte Unterschied ist wohl, dass im TED keine Farb-Zuordnungstabelle mehr vorhanden ist, sondern dass die Werte direkt aus den Grafikdaten in Richtung ausgang geschoben werden:

- die acht einstellbaren Luma-Werte werden in acht Werte "größer null" auf dem Luma-Ausgang übersetzt
- weitere Luma-Werte gibt es für Sync und schwarz, die beide unter den anderen acht Luma-Werten liegen
- einen White-burst gibt es seltsamerweise nicht - wie die Monitore damit klarkommen, ist mir ein Rätsel.

Positive Nachrichten gibt es für die Farbsättigung: Die Amplitude auf dem Chroma-Ausgang ist durch alle Farben hindurch identisch, damit ist die Farbe einzig durch die Phase des Chroma-Signals im Verhältnis zum colour-burst am Anfang der Zeile bestimmt. Bei "15 Farben und schwarz" drängt sich die Vermutung auf, dass ähnlich wie beim C64 in 22,5-Grad Schritten der Winkel abgewandert wird, wobei es dann einen Winkel geben muss, den der TED nicht erreichen kann. Ich muß mal schauen, ob mein Oscar einen Mode hat, in dem er den Winkel messen kann - genug Daten sollte er mit 200 Megasamples eigentlich haben :-)

Oder hat schonmal jemand den Farbraum des C16 durchgemessen?

Jens

Go to the top of the page

Forum-64

Quoted from "Nichtsnutz"

Source code

Quoted from "boing4000"

Quoted from "Wiesel"

Source code

Quoted