Posts by Freak

Last weekend I did some in-depth review of the control logic of the FCC64 cartridge. After a couple of hours staring at the CUPL-File I found a few lines of logic equations where I thought that those lines were not correct and could cause issues. So I updated four logic equations in total and flashed the cartridge with the updated jedec-file that wincupl has generated...

Success!

With the updated CPLD-Configuration the FCC64 cartridge is fully working with both romsets from 5 MHz up to 14 MHz! There is no more need for cranking up the clockspeed!

Yesterday I sent the new CPLD configuration files to wybren1971 , asking him to test it on his FCC64. He confirmed that with the new CPLD configuration files his FCC64 is also working properly at 5 MHz with brom 1.5 and crom 1.3. Thank you wybren1971 for testing!

Today I updated the CPLD configuration files in the github repository.

But how to get your CPLD flashed with the updated configuration?

In addition to flashing the CPLD with a JTAG-Adapter by you I propose two ways to get your CPLD updated. Due to the fact that I am currently reducing any contacts (personal as well as even by mail) I do not offer that you can send me your FCC64 for updating!

Option A) I will attend the DoReCo-Party in September (if the spreading of the virus will be stopped in time...). I will bring all the equipment to update the CPLD.

Option B) I started to write an updater for the CPLD as a program on the C64. This program will update the CPLD via the Userport. I will also design a very small pcb that I can send to you. The pcb will contain the 2 mm socket for the jtag-pinheader. You will only need to solder a userport-connector to this pcb. See this posting for details (in german language).

But even option B will take some time...

Cheers,

Thomas

Dein "testkernal.bin" sieht soweit ganz okay aus.

Dein schematisches Bild zeigt aber nur den Soll-Zustand (den es letztlich auch auf der Reprom-Homepage gibt) und nicht den Ist-Zustand. Der Ist-Zustand ist aber relevant und wird für eine Beurteilung benötigt. Deswegen die Frage nach einem Foto!

Was bedeutet "die 3 Linken sind nicht mit dem Charrom verbunden"? Du hast das Charrom noch eingebaut und die linke Stiftleiste im Reprom nicht bestückt? Ungewöhnlich, sollte aber funktionieren...

Dir ist hoffentlich auch bewusst, das Du beim Reprom noch Brücken entsprechend der C64-Version setzen musst. Auch deswegen wäre ein Foto hilfreich!

Du weißt, das Du nach dem Umschalten des Kernals manuell einen Reset auslösen musst?

Gruß

Thomas

Stelle Du doch dein Image hier mal rein, dann kann man sich das File angucken und eine Aussage zur Funktionsfähigkeit geben...

Was heißt "wenn beide Schalter auf 0 sind"? Bedeutet 0 bei Dir "Schalter offen" und demnach K0 und K1 NICHT mit GND verbunden?

Vielleicht wäre auch ein Foto Deines Aufbaus hilfreich...

Gruß

Thomas

Quote from katarakt

Bei dem teil von frank buss habe ich etwas bedenken, das teil hat fast niemand nachgebaut und ob der code tatsächlich fehlerfrei ist weiß man nicht, da es ja keinen bedarf und somit tester gab. Würde mich wundern, wenn der tatsächlich ohne bugs wäre

Ganz fehlerfrei ist sein Code nicht. Ich hatte "vor Jahren" mal den Teil der /NMI-Erzeugung vermessen und dabei Unterschiede zu seinem Code festgestellt. Nachzulesen ist das in diesem Posting (unterer Teil...).

Quote from Coco

Geht's da um sowas? Dann glaube ich, dass ein generischer Packer immer zweite Wahl ist, weil man mit Tokenisieren und binärer Kodierung der Zahlen nicht nur mehr Kompression erreicht, sondern man spart sich auch den ganzen Tabellenkram.

Dachte ich zuerst auch. Aber es sind im SVF-File auch große Teile, die sich zig-fach wiederholen. Die würde man mit Tokenisierung nicht wirklich wegkürzen können, sprich: Da würden sich dann halt nur die Token (plus zugehörige Daten) wiederholen...

Quote from ssdsa

Exomizer packt auch ziemlich gut. https://bitbucket.org/magli143/exomizer/wiki/Home

Gibt es dafür auch eine ausführliche Dokumentation? Ich habe mit dem Exomizer heute Nachmittag mal das Packen einer 100 kByte SVF-Datei ausprobiert:

"exomizer raw infile.svf -P0 -o outfile.raw"

Danach lag im Verzeichnis ein nur 4 kByte langes File!

Sollte Exomizer die Datei wirklich um 96% eingedampft haben? Ich weiß es leider noch nicht, da ich jetzt erstmal nach einem ASM-Source zum Entpacken des Streams suchen muss. Wobei der doch mit generiert werden soll. Ist der etwa im Stream mit drin?

Naja, ROM wurde auch nicht an einem Tag erbaut...

Gruß

Thomas

Danke Unseen , da habe ich erstmal genügend Stoff, um mich in die Sache einzulesen.

Gruß

Thomas

PS: In der Tat wäre eine Konvertierung von SVF nach XSVF möglich. Es gibt aber in einem der dortigen Repositories auch "easp", einen "Easy SVF Player", inklusive Source, den ich mir demnächst mal ansehen werde...

Quote from Unseen

Gabs schonmal: CPLD (u.a.) am C64 programmieren mit PlayXSVF

Leider außer dem Schaltplan absolut nichts zum Download da, auf dem man aufbauen könnte. Ich habe auch maximal ein SVF-File und das Erstellen eines XSVF-Files ist nicht möglich...

Trotzdem Danke, kannte den Thread noch nicht.

Gruß

Thomas

Hallo,

für ein kleines Projekt suche ich einen geeigneten Packer/Cruncher. Dieser soll aber keine Programme packen, sondern ca. 2000 kByte an reinem ASCII-Text, aufgeteilt in vier Pakte zu je 50 kByte. Ich will in meinem Programm nacheinander auf diese vier Pakete zeilenweise zugreifen, d.h. im Idealfall liefert mir das Entpackprogramm zeilenweise den Originaltext eines Pakets zurück, solange bis das Ende des Pakets erreicht ist. Ein Bereitstellen einzelner Bytes ist aber auch natürlich möglich, dann füge ich diese zu den benötigten Zeilen zusammen.

Der ASCII-Text, der gepackt werden soll, sieht generell so aus:

Und so geht es dann weiter, bis zu einer Länge von ca. 50 kByte.

Da ich mich auf diesem Gebiet nicht sonderlich gut auskenne, meine Frage in die Runde: Gibt es einen dafür geeigneten Packer/Cruncher?

Schon mal vielen Dank für eure Kommentare.

Gruß

Thomas

Hallo,

um das Nachbauen der FCC64 ein wenig zu erleichtern und das Hin- und Herschicken von aufgelöteten ATF1504-CPLDs zwecks Programmierung zu vermeiden, hatte mich vor ein paar Tagen OliverW. auf die Idee gebracht, das CPLD mittels des C64 zu programmieren.

Das Ganze ist derzeit noch in der Konzeptphase (in meinem Kopf), aber es erscheint mir durchaus realisierbar. Alles was man zum Programmieren des CPLD bräuchte, bringt der C64 durch seinen Userport (oder Tapeport) bereits mit, so dass man nur eine kleine Adapterplatine zwischen Userport/Tapeport und dem 10-poligen Programmierstecker der FCC64 bräuchte. Da auf der Adapterplatine keine passiven oder aktiven Bauteile wären, sollte auch ein Adapter mittels einfachen Drähten funktionieren, wäre folglich aber nicht so stabil wie die Adapterplatine.

Ich habe mich daraufhin mal auf der Homepage von bigby umgesehen. Er hat selbst schon mal die ATF1504-CPLDs mittels OpenOCD gelöscht und beschrieben. Als Basis dienen SVF-Files, die durch das ATMISP-Tool von Atmel erzeugt werden können.

Demzufolge bräuchte ich für den C64 einen "SVF-Player", der die SVF-Files fürs "Löschen", "Prüfung Leer", "Programmieren" und "Überprüfung der Programmierung" nacheinander interpretiert und damit über den Userport/Tapeport per JTAG auf das ATF1504-CPLD der FCC64 zugreift.

Ich werde mich wohl mal mit den (lesbaren) SVF-Files beschäftigen müssen...

Das erste Problem, welches gelöst werden müsste, liegt in der Dateigröße der SVF-Files. Die durchschnittliche Größe einer SVF-Datei für das ATF1504-CPLD liegt bei ca. 50 kByte. Bei vier zu verarbeitenden SVF-Files hat man also ca. 200 kByte ASCII-Text. Viel zu viel für den kleinen C64. Man könnte zwar extern diese Dateien "tokenisieren" und damit deutlich verkleinern, allerdings fände ich einen Daten-Packer wesentlich einfacher zu handhaben. Dieser würde dann die vier Dateien packen und sie würden dann in den SVF-Player integriert werden, so dass am Ende ein One-Filer entsteht. Der Entpacker müsste dann im Idealfall die SVF-Datei zeilenweise entpacken, mindestens jedoch byteweise (um nicht die 50 kByte pro SVF-File komplett im C64-Speicher auspacken zu müssen).

Dann wären auch gegebenenfalls CPLD-Updates ohne großen Mehraufwand für JTAG-Programmieradapter möglich und zwar generell nicht nur für die FCC64.

Interessante Projektidee, wie ich finde...

Gruß

Thomas

Quote from wybren1971

But with the new roms (CROM 1.3(e) and BROM 1.5) or the one translated by sailor, the FCC64 card works only at 14Mhz (at 5, 7 and 10 the screen freezes) and there is no ram disk available. I don't know why it freezes with other speeds than 14 MHz.

I may find some spare time during the following weekend to look into this issue. But it is hard to believe that the new ROMs do only work at 14 MHz, simply because CPUs with this speed were not widely available and surely haven't been used in the Final Chess Card in those days.

Due to the absence of the RAM-Disk in the new ROMs I also thought that the new ROMs are not to be used with the FCC for the C64 but maybe with the ISA-Hardware for PCs. But we do have a new CROM that is used for Commodore-Hardware only... Very strange...

I will keep you posted.

Cheers,

Thomas

Quote from Matthias

Mal ein aktuelles Bild vom Tuning Board (Beta Prototype):

- Optionaler Streifenfix

- Tuning 64 "HAT" Socket

- Userport + Tape Port Pins gedreht

- Video-Buchsen-Pins korrigiert

- Automatische Adressen für SID I und SID II + IO1/2 Jumper für SID III

- SID Digifix und Filter Jumper

- 2. Audio Channel auf Pin 5/7 der Video-Buchse per Jumper schaltbar

- TOD mit präzisen 50/60Hz

- Mehr Pins (CS: CIA1/2, VIC, SID)

- Bohrlöcher für ZIF Sockel jetzt 1.0mm

- Löcher für Schrauben an die richtige Position gesetzt (waren leicht versetzt)

- Und viele sonstige kleinen Optimierungen

Display More

Das "REV P2020.1" auf dem Bild der Platine solltest Du vielleicht auch noch anpassen...

Henning beschreibt es auf der für das Reprom64 erstellten Homepage doch sehr genau:

K0 und K1 sind für die Kernal-Umschaltung zuständig und haben interne Pull-Ups. D.h. mittels Schalter kann man K0 und K1 gegen GND schalten und somit insgesamt 4 Kernals umschalten.

Deine Vermutung ist also korrekt...

Gruß

Thomas

Quote from 1ST1

Wie schaut es aktuell mit der Veranstaltung eigentlich aufgrund der aktuellen Nachrichtenlage aus? Überall werden Veranstaltungen, auch kleinere, wegen der elendigen Fledermausbazille abgesagt. Auch in Paderborn gibts schon Fälle, und Spahn hat vor 3 Tagen eine Reisewarnung für NRW herausgegeben.

Dass es hier so ruhig ist, wundert mich ehrlich gesagt auch etwas. Ich verfolge die Nachrichtenlage und die Ausbreitung schon sehr intensiv und habe mich heute auch schon mit androSID neben anderen Dingen darüber telefonisch ausgetauscht. Aktuell sehe ich noch ein relativ niedriges Risiko einer Ansteckungsgefahr bei der Veranstaltung, allerdings bin ich mir für das übernächste Wochenende da nicht mehr so sicher...

Gruß

Thomas

Quote from wybren1971

Quote from Freak

that needed to be formated??? Not sure about that...).

How did you do that? I loaded old BROM and CROM files (from Jani his side) but i never could access the RAM disk. Is it used at all? I did not notice any change in playing when setting the dip switch to 8 or 32 Kb.

The Manual suggest the static ram is for setting personal settings and saving games. But i did not see that option.

Finally I got some spare time to check this issue in detail:

* inserted a fresh 3V coin cell battery

* setting the dip switches of the FCC to: 8k, 5M, 1x

* brom: 1.0, crom: 0.9 (german version)

* I used an Ultimate 64 for testing, but this should not matter at all...

With this configuration the ram disk is fully working! (No need for formatting the disk. )

Maybe the following will clearify the usage a little bit:

Saving games

* Select "Datei / Sichere Spiel" ("File / Save Game" ??? )

* Select "ram disk"

* Optional: Press "Lese Dir" ("Read Dir" ??? ) to show the contents of the ram disk

* Enter your desired file name in the small (one line-) box on the lower left side of the window

* Press "Sichere" ("Save" ??? )

Now all moves up to the current state are being saved to the disk.

Reading games:

* Select "Datei / Lade Spiel" ("File / Load Game" ??? )

* Select "ram disk"

* Press "Lese Dir" ("Read Dir" ??? ) to show the contents of the ram disk

* Enter your desired file name in the small (one line-) box on the lower left side of the window or simply select your desired file name in the upper left box

* The desired file name should now be stated in the box on the lower left side of the window

* Press "Lade" ("Load" ??? ) or "Replay" ("Replay" ??? )

"Lade" will load the game and will set the game pointer prior to the first move. Hence the board will look as if no move has been made. Moves can be replayed with "Commodore / R" or "Commodore / A" or from the option menu.

"Replay" will load the game and will set the game pointer after the last move. Hence the board will look as if the game has already been played...

Cheers,

Thomas

If one is still looking for a proper power switch S1 for the widget board, this one would be a perfect fit without the need for drilling additional holes:

Either 200AWMSP1T1A1M7Q (long actuator, Mouser: 612-200AWMSP1T1A1M7Q, Digikey: EG5772-ND)

or 200AWMSP1T2A1M7Q (short actuator, Mouser: 612-200AWMSP1T2A1M7Q, Digikey: 200AWMSP1T2A1M7QE-ND)

And at least Mouser is having plenty of them in stock. I haven't tested these switches yet, but I am very sure they will fit. I will order a couple of them and report...

Cheers,

Thomas

Quote from wybren1971

I converted the CUPL design with ATMELISP to a FCC64.svf file and programmed the CPLD with openocd and a buspirate via JTAG. i can share the openocd config en de svf file if someone wants to go that route. (i use linux hence this solution)

IMHO it would be very good if you can publish your approach to translate the CUPL-File and to flash the CPLD on a linux system...

Quote from wybren1971

Does anyone else see the ram disk?

I did not try the "new" brom and crom, but with the old roms I got a fully functional ramdisk (that needed to be formated??? Not sure about that...).

You may check the supply voltage of the static ram. It should be approx. 3,0 V with the module completely disconnected from the c64.

Cheers,

Thomas

Quote from androSID

Ich sage nur Hut ab Thomas!

Danke! Größtes Problem ist ja dafür Zeit freizuschaufeln, wenn man nicht nur ein Projekt hat. Erst recht, wenn man schon vorher weiss, das man nach ein paar Stunden nur 1-2 neue Leiterzüge geroutet hat.

Aber viel mehr geht jetzt mit vier Layern auch nicht. Die Platine ist vom Routing her dicht! Vielleicht, wenn man das Routing völlig neu machen würde, oder aber auf sechs Layer geht...

Bin echt mal gespannt, ob das Teil später auch rennt...

Gruß

Thomas

Erst den Ring unter dem Gehäuse abziehen, dann die LED nach unten drücken...

Gruß

Thomas

Im Hotel Buddeus war noch mindestens ein Zimmer frei. Jetzt ist eins weniger frei... ...und ich habe eine Unterkunft.

Gruß

Thomas

PS: Wo ist der Steakhouse-Thread? (Oder die Pizza-Sammelbestellung?)

Die Final Chess Card nutzt diesen Pin.

Gruß

Thomas