-
Mit meinem Flash4C64cs können alle ChipSelect-Kombinationen frei eingestellt werden, daher hatte ich Kasi angeboten meine Lösung auszuprobieren. Mit einem Brennadapter kann das Flash4C64cs natürlich programmiert werden wie ein SST39SF010A DIP-Bauform.
Hier noch eine Übersicht der gebrannten ROMs:
Etwas sehr ähnliches hat Piers Finlayson diese Woche vorgestellt. Allerdings ohne die CS per DIP Switch. Stattdessen kann man per Jumper die ROM images auswählen. CS kann per reflashing geändert werden. Ist auch alles Open Source:
https://github.com/piersfinlayson/software-defined-retro-rom
-
Ich persönlich würde aber auch eine signifikante Geldsumme für einen Neuauflage eines 1084S bezahlen. Mit echter Bildröhre und schwammigem C64 Bild. 
Da braucht es doch keine Neuauflage eines 1084S. Da gibt es sicherlich noch genug davon.
Aber neue und passende Zeilentrafos fehlen halt.
Irgendwann sind aber auch die Bildröhren durch. Und Reparaturen werden immer schwieriger. Mal so ne kleine Neuauflage wäre schon fein. 
-
Schade, dass das Projekt gleich wieder so schlecht geredet wird. Ich finde es gut, dass es eine weitere Möglichkeit gibt, ein HDMI Signal aus dem C64 zu holen. Leider ist es mit einem S-Video zu HDMI Konverter nicht getan, weil das Videosignal des C64 so schlecht ist, dass es keine perfekte und günstige Lösung gibt. Das bedeutet: es bleibt einem nichts anderes übrig, als den VIC komplett nachzubilden, um ein exaktes digitales Bildsignal zu bekommen. Genauso funktioniert auch das Chamaeleon von iComp, aber da gibt es leider kein HDMI, sondern "nur" VGA.
Ich würde das nicht schlechtreden nennen. Ich finde es aber auch Quatsch jedes Projekt zu bejubeln. Ich selber mag gestochen scharfe C64 Ausgaben nicht. Damit sehen Demos und Games of richtig billig und schlecht aus. Das unperfekte Bild gehört meiner Meinung nach zum C64 dazu.
Und wie gesagt: technisch ist es ohne Frage eine Meisterleistung. Aber für MEINEN Bedarf und meine Vorstellung vom C64 Erlebnis absolut unnötig.
Ich persönlich würde aber auch eine signifikante Geldsumme für einen Neuauflage eines 1084S bezahlen. Mit echter Bildröhre und schwammigem C64 Bild.
-
Thanks for coming to my TED talk. ;P (Sorry, liege gerade krank herum und kann nicht viel anderes machen als Foren zu lesen und zu schreiben...)
Och, ich glaube einige der Leute hier machen nur genau das, ohne diagnostiziert krank zu sein!
Gute Besserung!
-
Zumindest in Jans Video sehen die Farben auch krass gesättigt aus. Ich hoffe das kann man irgendwann auch einstellen.
-
Technisch beeindruckend, ist aber ähnlich wie die GameBoy Cartridge zum Streamen doch etwas "enttäuschend", weil es quasi wieder Emulation ist. Ich denke ich bleibe da eher bei SVideo und einem preiswerten SVideo zu HDMI Wandler. Da gibt es ja ziemlich gute für um die 30€. Und solange meine CRTs noch leben spielen wir eh auf diesen. Aber für Videocapture reichen die Wandler.
-
Blöderweise fallen diese VIC-II-Emulatoren immer wieder bei neuen und nicht so neuen Demo-Effekten auf die Nase. 
Der VIC-II wird von dem ISEVIC nicht emuliert.
AndyDTV Ja, auch beim Ali kosten die Tang Nano 20K 30 - 35€.
Und wie kommen die dann ans Videosignal? Kommt das über die drei Clipleitungen?
-
root42
Alter Funker ?
Mein Meister - DK5LN - hatte mal mit ein paar leuten eine Relaisstation gebaut,
weil Flensburg einen Taökessel zum Hafeb hat.
Alles anzeigen
Ich? Oh nein, null Funker, aber finde das schon cool. Kenne eine handvoll Funker, vor allem aus Finnland. Habe auch über Simulation von Antennen promoviert, aber nur die Softwaresimulation, vom praktischen habe ich keine Ahnung. 
-
DL2DW's IEEE Adapter gebaut. Mal gucken wann ich den teste. Mein Ziel ist es ja immer noch eine BBS Software am C64 mit der 8050 als Massenspeicher aufzusetzen. Und dieses Interface kann IEC und IEEE gleichzeitig. D.h. die 1541 kann die Software laden, und die ganzen Downloads kommen auf die 8050. Das wäre glaube ich ein sehr geiles Setup in den 80ern gewesen.
-
Aha! Siehste! Ich sag ja, dass das CBM Interface ziemlich nutzlos ist! Echt verrückt, dass die das so gemacht haben...
-
Danke! Weiß nicht ob ich das diese Woche schaffe, aber kommt auf die Todo Liste!
-
Ne, der Witz ist ja das mit dem Commodore IEEE-488 Interface zu nutzen. Denn das ist bisher ein ziemlich unnützes Gerät!
-
Um das in VICE nachzustellen, versuche ich gerade Files von einer 1541 auf die 8050 zu kopieren.
Welches Filecopy kann ich dazu am besten nehmen?
Also wenn du VICE eh hast, kannst du das mit c1541 in der Shell machen. Ich selber nutze in DOSBox 64copy, weil es einfach sehr praktisch ist.
Hier hast du auch mal mein Image, was ich mit 64copy gemacht habe.
-
Hast du denn mal (irgend ein) CBASE ausprobiert? Das startet ja eigentlich von sämtlichen Laufwerkstypen.
Ja, habe ich. Ich habe die Version von zimmers.net genommen, und beide Disks einfach auf ein D80 Image kopiert. Dann passiert ein CPU JAM:
-
Auf dem PET ist das nicht so schwierig, Steve Punter's Programm läuft auf jeden Fall von der 8050. Habe ich schon mal testweise im Local Mode gestartet. Aber wollte so was auch mal mit dem C64 ausprobieren. Eine 8050 wäre ja wie gesagt ziemlich genial, weil sie 1 MB Storage bietet, was gerade bei einer BBS ja nützlich ist.
-
Ich habe jetzt mal ein IEEE-488 Interface von DL2DW zusammengelötet. Das kann ja auch seriell + IEEE gleichzeitig. Damit sollte es auf jeden Fall möglich sein von einer 1541 als Device 9 zu starten und dann die 8050 auf Device 8 als Massenspeicher zu nutzen.
Das Commodore IEEE-488 Interface hingegen ist echt beschränkt...
-
Eine Art Modul-internes "Bankswitching"?
Genau das. Irgendwo im 'tfw8b'-Blog auch erklärt - und bislang nicht in Gebrauch bzw. verwendbar, da die verantwortlichen Leutz selbst nicht wissen, was sie damit anfangen sollen. 
Wäre gut für Infocom Games. Der Bit Shifter Interpreter kann auch schon 96K auf PETs benutzen durch Bank Switching. Ich weiß gerade nicht, ob das nur für Disk Cache oder auch für die Story verwendet wird, aber je mehr RAM desto besser. Aber ja, man müsste da erstmal was programmieren, was das nutzt...
-
...und das gute ist ja: Es ist OpenSource. Solange die Hardware das unterstützt, könnte man die Sourcen entsprechend Patchen, dass das möglich ist.
-
Für diesen ganzen Kram werden individuelle Treiber benötigt.
Sind also Treiber für die üblichsten Karten im Linux Kernal enthalten? Was wird sonst unterstützt, wenn von "nativen Support für den IEEE-488 Bus" geschrieben wird?
Kennt jemand eine detallierte Stelle, wo man das nachlesen kann? Ich bin leider nicht so bewandert in der LINUX Dev. Doku.
Ja klaro, es werden gängige GPIB Karten unterstützt:
https://linux-gpib.sourceforge…l/supported-hardware.html
Auf alle Fälle ist der Weg noch lange nicht frei für nativen Support von Commodore Floppylaufwerken. Das Commodore DOS läuft halt nur über den IEEE-488 Bus, wird aber von einer Implementierung der Schnittstelle im Kernal nicht weiter unterstützt. Die Funktionen des Busses und des DOS werden leider immer wieder in einen Topf geworfen - und das ist sehr irreführend.
Support der Laufwerke wäre weiterhin über OpenCBM möglich, aber dann halt mit einem Kernel-Backend, statt libusb und XUM Support. Also die IEEE-488 Karte nur als Interface, das man öffnet und dann auf die übliche Art mit DOS-Befehlen mit der Floppy spricht.
-
Der Linux Kernel bekommt bald nativen Support für den IEEE-488 Bus! Damit dürfte endlich der Weg frei sein für nativen Support von Commodore Floppylaufwerken!
Spaß beiseite... das ist natürlich eher für Laborequipment gedacht, aber wer weiß, ob das nicht auch für OpenCBM nützlich sein könnte!
Zitat
Notable with the staging area updates for the in-development Linux 6.16 kernel is word that the GPIB driver code may be ready to leave the staging area in the next kernel cycle (Linux v6.17) in then being promoted to the main driver area in signifying the maturity of the code and being cleaned up to meet kernel coding standards. The GPIB drivers are for the General Purpose Interface Bus that was introduced back in 1972.
While the General Purpose Interface Bus has been around since the 70's, the Linux driver code for it was only added to staging back in 2024 for Linux 6.13. Since then the GPIB code has continued to be improved upon in follow-on kernel releases. While the General Purpose Interface Bus (also known as the HP Interface Bus - HP-IB), it's still in use by some test equipment and thus the Linux kernel driver interest now in the 2020s.
https://www.phoronix.com/news/Linux-6.16-Staging
