Hello, Guest the thread was called2.8k times and contains 61 replays

last post from Korodny at the

Modul (Flash-Speicher, WiFi ...) und passendes grafisches OS

  • Die Idee ist so simple wie genial: Auf PDF drucken lassen und Dank WiFi einfach auf den PC schicken/holen.

    Genauso würde ich das beim C64 auch machen wollen (und habe das sicherlich schon mehrfach erwähnt). Nur, dass ich versuchen würde, das Ergebnis gleich übers Netz auf einen modernen WiFi-Drucker zu schicken. Viele können PDFs und PS-Dateien einfach so drucken, ohne weitere Treiber.

  • Die Idee ist so simple wie genial: Auf PDF drucken lassen und Dank WiFi einfach auf den PC schicken/holen.

    Genauso würde ich das beim C64 auch machen wollen (und habe das sicherlich schon mehrfach erwähnt). Nur, dass ich versuchen würde, das Ergebnis gleich übers Netz auf einen modernen WiFi-Drucker zu schicken. Viele können PDFs und PS-Dateien einfach so drucken, ohne weitere Treiber.

    Das wäre natürlich noch einen Tick eleganter.


    Ich bin von dem Teil echt stark begeistert. Wenn man den Preis berücksichtigt, den es bei der ersten Produktion gekostet hat - 65 Dollar bzw. 55 Euro - (leider momentan nicht verfügbar) ist das fast schon ein "Wunderwerk".


    Sowas auch für den C64 und es würden sich ganz neue Nutzungsmöglichkeiten für den alten Brotkasten eröffnen: Mal kurz eine Mail losschicken, einen Text mit Geos gestalten und über WiFi an den Netzdrucker ausgeben, danach in den Szene-Chat einloggen ... man darf ja mal träumen ... :D

  • Sowas auch für den C64 und es würden sich ganz neue Nutzungsmöglichkeiten für den alten Brotkasten eröffnen: Mal kurz eine Mail losschicken, einen Text mit Geos gestalten und über WiFi an den Netzdrucker ausgeben, danach in den Szene-Chat einloggen ... man darf ja mal träumen ... :D

    Du sprichst mir aus der Seele!!!

  • So utopisch scheint der Gedanke ja gar nicht zu sein:


    https://vintageisthenewold.com…net-for-the-commodore-64/

    Hatte von #FujiNet nichts mitbekommen, weil ich bei Atari schon länger wieder raus bin. Kaum erfahre ich davon, lese ich schon von einer in Entwicklung befindlichen C64-Umsetzung. Wow.


    Seit der zitierten Ankündigung im von jenpie verlinkten Artikel gab es auch schon Entwicklungsfortschritte, die veröffentlicht wurden:


    [External Media: https://youtu.be/q6IYi3TIGNI]


    [External Media: https://youtu.be/9XTJOJWP9sM]


    [External Media: https://youtu.be/irJ-ZtGiGGI]


    [External Media: https://youtu.be/KkgXSpBv4wY]



    Edit: Updates zur C64-Umsetzung gibt's wohl auf Twitter und auch im YouTube-Kanal, dessen Videos ich verlinkt habe.

  • 20 KB nach Laden des Launchers. Ich glaube 30 KB sind für Anwendungen frei.

    Hmmm... halte ich persönlich immer noch für viel zu wenig. Wenn ich das richtig verstanden habe, soll dieser wenige Speicher dann u. U. noch auf mehrere Programme aufgeteilt werden. Um unter diesen Bedingungen zu programmieren, bräuchte man unbedingt einen externen Ramspeicher und einen Programmaufbau, bei dem die zu bearbeitenden Daten ständig in einen Puffer geladen und von dort geschrieben werden. Da das aber ziemlich langsam ist, stellt sich schon die Frage, welche Art von Programmen für solch ein System angedacht sind.

    Wenn man sich Greg's Videos ansieht, ist klar dass da nicht viel Speicher übrig bleiben kann: Er hat nicht nur einen Fenstermanager implementiert, sondern auch ein echtes UI-Toolkit - inklusive Layout-Boxen und komplexer Listviews (beide in Echtzeit in der Größe veränderbar), Tabs, Drop-Down-Menüs, Scrollbars usw. Das System verwaltet einen Text- und einen Grafikbildschirm und kann an beliebiger Y-Position zwischen beiden umschalten usw. usf.

    Und nun wieder die Preisfrage: Wer braucht diesen ganzen Kram? Da sich sein System für Spiele nicht eignet (einerseits wegen des Speichermangels, andererseits wegen der vorgeschriebenen Zeichenausgabe) bleiben eigentlich nur Tools als anvisierte Programmgruppe übrig. Doch selbst da dürfte man schnell an die Grenzen kommen. Der Witz dabei ist, daß man unter diesem System ja nicht einmal einen Texteditor schreiben kann, denn ein solcher sollte eigentlich im Bitmap-Hires-Modus seine Texte anzeigen, um so entweder auf 80 Zeichen pro Zeile zu kommen oder ein Lowcost-WSYIWYG zu gestalten (Fettdruck direkt erkennbar). Auch ein Spreadsheet sollte man heutzutage eher als Grafik ausgeben denn als Text. Also ich hätte keinen Plan, was ich mit dem OS machen sollte... :nixwiss:

    Sicher, aber wenn ich nur Original-Commodore-Laufwerke habe, brauche ich ja kein *OS*, sondern maximal ein einfaches UI-Toolkit? Als 'OS' taugen Action Replay o.ä. für 15x1-Besitzer deutlich mehr als alles andere.

    Das ist auch immer die Frage, was man beim C64 unter einem "OS" verstehen will. Die einen denken dabei an einen Filemanager, die anderen an eine GUI-Bibliothek, wieder andere an Treiber für 1541 und Maus und noch andere an Multitasking und Speicherverwaltung. Für mich persönlich gehören weder Filemanager noch GUI-Bibliothek zu einem OS. Ein Filemanager ist eine App, und die GUI-Bibliothek eine Standardbibliothek, die vom OS bereitgestellt werden kann, um Programmierern die Arbeit zu erleichtern und dem Anwender programmübergreifend eine vertraute Umgebung zu schaffen. Richtig OS sind eigentlich nur die Treiber sowie die Verwaltung von Ressourcen wie Speicher und CPU. Letzteres finde ich für den C64 einfach überdimensioniert. Dafür ist der 6502 nicht gemacht, und es macht meiner Ansicht nach auch keinen Sinn, so etwas wie Multitasking auf dem C64 zu implementieren, da es in der Praxis keinen nennenswerten Vorteil bietet, dafür aber jede Menge Nachteile mit sich bringt. Treiber hingegen können schon nützlich sein, doch auch da wäre es sinnvoll, wenn eine App selbst entscheiden könnte, welchen Treiber sie überhaupt braucht. So wäre es z. B. möglich den Maustreiber nur dann zu laden, wenn das Programm auch eine Maus benutzt.

    Im Endeffekt ist die beste Lösung immer noch, daß das "OS" aus einer Sammlung von diversen Bibliotheken besteht, darunter die erwähnten Treiber als auch die GUI.

    Die Programme sollen sich bitte zur Laufzeit die benötigten Routinen aus dem OS holen und gut ist – dann sind alle auf dem gleichen Stand.

    So in etwa, nur daß die Routinen halt in getrennten Dateien vorliegen, die einzeln geladen werden können, und nicht als ein großer monolithischer Block, der viel Speicherplatz verbraucht, egal welchen Teil man davon wirklich benötigt.

    Für so eine Vorgehensweise wäre aber besser eine andere Hardware geeignet wie z. B. ein OS auf einem Steckmodul mit SD-Karte als Speicher.

    Das ist allerdings richtig. Wer nur die C64-Basisausstattung (C64, 1541, Bildschirm, Joystick) hat und nur Games zocken (und Demos angucken) will, der braucht keinerlei zusätzliches OS – allenfalls einen Game-Launcher. Also entweder setzt man die Hardware-Anforderungen höher an (moderne Massenspeicher-Lösung?, Maus?, Speichererweiterung? LAN? ...) oder aber man liefert gleich einen unverzichtbaren Teil davon mit.

    Beim Vorschlag des neuen Steckmoduls wäre so ein Gamelauncher quasi mit eingebaut. Das wäre die universalste Lösung.

    Würde man aber den nötigen Zusatz-Speicher für ein OS (in welcher Form auch immer) mitliefern, könnte man mit den schon vorhandenen Laufwerken machen, was immer man möchte. Zudem gibt es auf dem C64 keine einfachere Lösung, um ein OS zu "installieren" als ein Modul in den dafür vorgesehenen Schacht zu stecken – auf jeden Fall deutlich simpler als eine anfängliche GEOS/MP3-Installation.

    Und genau das ist der springende Punkt: Alle Laufwerke bleiben wie sie sind, dafür können die Teile des OS (oder auch andere, beliebige Daten) geladen und gespeichert werden, ohne daß man hierfür auf Kernal-Routinen zurückgreifen müßte. Also keinen Konflikt mit Speicheraufbau, IRQ, Sprites usw. Gelingt es technisch, dem Modul noch ein Autobootrom beizufügen, lassen sich Desktop/Launcher/Filemanager direkt nach einem Reset starten, ohne daß man extra eine Diskette einlegen muß. Und da beim Laden nicht auf den seriellen Bus zugegriffen werden muß, werden die Daten, z. B. Spiele, auch noch schneller geladen als beim SD2IEC. Daher verstehe ich ehrlich gesagt auch nicht, wieso nicht schon längst jemand diese Hardware gebaut hat, zumal die Grundlage dafür in der Form des Sidekick64 bereits vorhanden ist.



    Ich habe mal die Idee mit dem Modul inkl. OS in den Bereich Hardware ausgegliedert:


    Modul (Flash-Speicher, WiFi ...) und passendes grafisches OS

    Der Link scheint bei mir nicht zu funktionieren und verweist nur auf den Anfang dieser Seite...

  • Speziell das letzte Video ist super interessant.

    Ja, das ist schon interessant.


    Das sind genau die Möglichkeiten, die auch einen Einsatz des C64 im heutigen Alltag interessanter machen. Man könnte den C64 neben den bisherigen Verwendungszwecken auch für heutzutage relevante Einsätze verwenden. Mal einen kurzen Text auch direkt vom C64 auszudrucken oder einen Chat damit besuchen oder auch mal am C64 den Wetterbericht aufrufen. Oder eine Online-Highscoreliste für das Lieblingsspiel benutzen, die auch die Scores anderer Spieler online einpflegt. Oder ... oder ...


    Das wäre schon reizvoll und mal "was anderes" als das 453. Freezer-Steckmodul oder die 342. SD2IEC-Variante. ;)

  • Ich fände eine "Komplettlösung" ganz schön. Also sowohl das OS selbst als auch die notwendigen Erweiterungen (Speicher, WiFi, SD-Karten-Laufwerk, usw.) alles auf einem Modul, das ich dann nur noch in den C64 stecken muss. Und alles ohne weitere Konfigurationsorgien. Einfach einstecken und loslegen. DAS wäre für mich eine wirklich reizvolle Sache und dafür würde ich gerne - auch etwas mehr - Geld ausgeben.

    Was wäre zum jetzigen Zeitpunkt realistisch?

    1.) Auf Basis des Sidekick64 läßt sich ein Modul erstellen, welches eine SD-Karte als großen Massenspeicher verwendet. Wie dabei die SD-Karte intern organisiert wird, ist zunächst zweitrangig. Soll heißen: Entweder a) der Massenspeicher entspricht 1:1 dem Aufbau der SD-Karte, oder b) der Massenspeicher wird auf einer FAT32-formatierten SD-Karte als Datei angelegt.

    2.) Dieser Speicher läßt sich wie bei der GeoRam über ein Fenster bei $de00 lesen und schreiben, wobei das Schreiben im Vergleich zur GeoRam aber ein dauerhaftes Schreiben ist.

    3.) Der C64 sieht nicht die interne Struktur der SD-Karte. Sollte der Speicher als Datei auf der SD-Karte organisiert sein, hat der C64 keinerlei Zugriff auf das Inhaltsverzeichnis oder andere Dateien auf der Karte, nur auf die Bytes innerhalb der Datei.

    4.) Die Kommunikation mit dem Speicher läuft ähnlich ab wie bei der GeoRam. In Registern (im Bereich $dfxx) schreibt man einen Befehl sowie die Adresse des Blocks, den man lesen/schreiben will. Nach Schreiben des Befehls wird der neue Block angezeigt. Das geschieht am besten so, daß das Modul diesen Block in einen internen Cache lädt. Wurde dieser Cache vorher beschrieben, wird der Inhalt auf die SD-Karte kopiert. ==> Es gibt keine getrennten Befehle zum Lesen und Schreiben, sondern nur zum Setzen eines Blocks.

    5.) Mit einem gesonderten Befehl läßt sich eine Basisadresse festlegen. Alle weiteren Adreßangaben sind relative Offsets auf diese Basisadresse. Damit läßt sich der Speicher in unabhängige Bereiche teilen.

    6.) Der Speicher enthält kein Dateisystem in der Form der 1541 oder 1581. Man könnte theoretisch ein Dateisystem einrichten, sollte es aber nicht, da man dafür extra einen Dateisystemtreiber benötigt. Besser ist es, den Speicher einzuteilen nach dem TLV-Prinzip.

    7.) Nach diesem Prinzip lassen sich alle möglichen Programme auf die SD-Karte schreiben und mittels eines Launchers schnell starten. Man kann aber auch Bibliotheken dort ablegen oder einen Filemanager oder einen Desktop oder...

    8.) Günstig wäre ein zusätzliches Autobootrom, welches die Anfangssektoren nach einem Bootprogramm durchsucht und dieses startet. Alternativ könnte nach einem Reset der interne Fensterzeiger auf einen Bootblock zeigen, der bei $de00 eingeblendet wird und sich dann mittels SYS 56832 starten läßt.


    Was also nicht direkt dabei wäre, wäre ein 1541 kompatibles Dateisystem. Es stünde aber jedem offen, ein solches in einem Block des SD-Kartenspeichers einzurichten und mit einem Dateisystemtreiber zum Laden von Programmen zu versehen. Wichtig dabei ist aber, daß dieser Dateisystemtreiber sich dann im C64 befindet und nicht Teil der Hardware ist (wie beim SD2IEC).

    Günstig wäre es auch, wenn man WiFi zusätzlich in die Hardware aufnehmen könnte (mit Registern bei $dfxx). Aber zur technischen Umsetzung kann ich nichts sagen.

    Ebenso handelt es sich hierbei nicht um eine Speichererweiterung im Sinne einer GeoRam oder REU, da der Speicher nichtflüchtig ist und besser nicht andauernd neu geschrieben werden sollte. Ob sich zusätzlich zu dem SD-Kartenspeicher noch Ram-Speicher auf dem Modul unterbringen läßt, der dann wie die GeoRam angesteuert werden kann, weiß ich ebenfalls nicht. Ich glaube allerdings auch nicht, daß solch ein zusätzlicher Ramspeicher dringend notwendig ist. Bei einem OS kommt es viel mehr darauf an, feste Routinen oder Daten schnell nachzuladen, aber weniger Ramspeicher extern auszulagern.


    WIe gesagt: Das Sidekick64 bietet heute schon an, die oben skizzierte Hardware zusammenzustellen. Daraus würden sich jede Menge neue Möglichkeiten für den C64 ergeben, ohne daß man die eigentliche Hardware verändert. Und wer auch immer sich darüber beschwert, daß das Steckmodul einen Prozessor hat, sollte sich besser auch keine 1541 zulegen. ^^

  • Naja, das sind keine brandneues Features, und schon lange möglich mit dem Flyer Internet Modem (welches im März nach knapp 8 Jahren mal wieder ein neues Firmware-Update bekam). Leider wird dies aktuell nicht angeboten.

    http://www.retroswitch.com/products/flyer/


    Da er Brandon aber seine Webseite neu aufgezogen hat, gehe ich mal davon aus, dass da wieder was kommt...

    FlyerUsersGuide12.pdf

  • Wenn ich das richtig verstanden habe, soll dieser wenige Speicher dann u. U. noch auf mehrere Programme aufgeteilt werden.

    Ich meine, Greg hätte geschrieben, dass er kein Multitasking für Apps anbieten will, daher macht es eigentlich kaum Sinn, den Speicher für Programme aufzuteilen. 30 KB frei für Programme finde ich voll OK, wenn man zusätzlich Zugriff auf weiteren schnellen Speicher hat. Dann muss dort ja nur der Programmcode liegen und Daten könnten größtenteils außerhalb verwaltet werden. (Wie bei "unserem" angedachten Modul).


    Der Witz dabei ist, daß man unter diesem System ja nicht einmal einen Texteditor schreiben kann, denn ein solcher sollte eigentlich im Bitmap-Hires-Modus seine Texte anzeigen, um so entweder auf 80 Zeichen pro Zeile zu kommen oder ein Lowcost-WSYIWYG zu gestalten (Fettdruck direkt erkennbar). Auch ein Spreadsheet sollte man heutzutage eher als Grafik ausgeben denn als Text. Also ich hätte keinen Plan, was ich mit dem OS machen sollte...

    Das ist halt das Problem bei allen UIs und OSes, die den Textmode verwenden – letztlich kommen immer die gleichen Programme dabei heraus, weil man die C64-Möglichkeiten nicht wirklich erweitert. Der einzige Anreiz für Drittentwickler wäre, dass ihnen ein wenig Arbeit bei der UI-Entwicklung abgenommen wird. ich glaube auch, dass das zu wenig Anreiz sein könnte.


    So in etwa, nur daß die Routinen halt in getrennten Dateien vorliegen, die einzeln geladen werden können, und nicht als ein großer monolithischer Block, der viel Speicherplatz verbraucht, egal welchen Teil man davon wirklich benötigt.

    Genau so.


    Beim Vorschlag des neuen Steckmoduls wäre so ein Gamelauncher quasi mit eingebaut. Das wäre die universalste Lösung.

    Richtig, ein App-Laucher oder Desktop wäre natürlich immer im Paket enthalten. Wichtig dafür wäre, dass auf vorhandenen Laufwerken (nicht im Modul) die dort eingesetzten Dateisysteme unterstützt werden, z.B. durch Kernal-Routinen.


    Und genau das ist der springende Punkt: Alle Laufwerke bleiben wie sie sind, dafür können die Teile des OS (oder auch andere, beliebige Daten) geladen und gespeichert werden, ohne daß man hierfür auf Kernal-Routinen zurückgreifen müßte.

    Vom Eindruck her verpasst man dem C64 dadurch eine schnelle interne Festplatte für das OS, Programme usw. und die vorhandenen "Disklaufwerke" stehen (weiterhin) als Wechselmedien zur Verfügung.


    Und da beim Laden nicht auf den seriellen Bus zugegriffen werden muß, werden die Daten, z. B. Spiele, auch noch schneller geladen als beim SD2IEC. Daher verstehe ich ehrlich gesagt auch nicht, wieso nicht schon längst jemand diese Hardware gebaut hat

    Ich auch nicht so ganz. Wobei das EasyFlash schon sehr in die Richtung geht – nur wird dort der Flash-Speicher (was anderes ist eine SD-Karte ja auch nicht) quasi als ROM verwendet, statt ihn nicht nur lesbar sondern auch ähnlich schnell beschreibbar zu machen. Woran das genau liegt, weiß ich nicht. Selbst über den IEC-Bus wäre/ist Flashspeicher schneller beschreibbar.


    Der Link scheint bei mir nicht zu funktionieren

    Danke für den Hinweis. Ist repariert.

  • 30 KB frei für Programme finde ich voll OK, wenn man zusätzlich Zugriff auf weiteren schnellen Speicher hat. Dann muss dort ja nur der Programmcode liegen und Daten könnten größtenteils außerhalb verwaltet werden. (Wie bei "unserem" angedachten Modul).

    Kleiner Haken: Es gibt außerhalb der eingebauten 64kb des C64 keinen schnellen Speicher. Speicherzugriffe bei der REU oder dem GeoRam (oder auch "unserem" Modul) sind im Verhältnis zu einem Direktzugriff des Prozessors auf echtes Ram (und sei es über Bankswitching) bis zu 100 mal langsamer. Ursache dafür ist einerseits die langsame Übertragung der Daten (bei der GeoRam müssen alle Daten per Hand aus dem Fenster bei $de00 in den Speicher kopiert werden) als auch das zugrundeliegende Speichermanagement, da jede App quasi ihren eigenen Treiber für ein virtuelles Ram mitbringen muß, bei dem vor einem Zugriff erkannt werden muß, ob sich eine Adresse im Puffer befindet, und wenn nicht, der Puffer neu beladen bzw. der alte veränderte Inhalt vorher geschrieben wird. Das ist alles andere als einfach und im Ergebnis halt sehr langsam. Wichtger Punkt dabei: Daten lassen sich nicht außerhalb verwalten, sondern nur im C64, was ein vorgehendes Laden in den Puffer zwingend nötig macht.

    Man stelle sich folgende einfache Aufgabe vor: In einem Texteditor soll an einer bestimmten Stelle eine neue Zeile eingefügt werden. Zu diesem Zweck muß der hintere Textanteil umkopiert werden, was bedeutet, daß man stückweise diesen Teil in den Speicher laden und dann an eine neue Position zurückschreiben muß. (Gleiches gilt natürlich auch fürs Zeilenlöschen.) Selbst mit dem DMA der REU ist dies immer noch ein aufwendiger Akt. Oder man will einfach nur den Text nach einem Wort durchsuchen. Auch dann gilt wieder, daß der Text in einzelne Häppchen zerlegt, geladen und durchsucht werden muß.

    Schlimmer wird es noch, wenn man den Speicher nicht nur einfach linear ansprechen will wie bei einem riesigen Textblock, sondern sowas wie Zeigerstrukturen verwalten möchte oder structs. Dann muß man zunächst die Zeiger umwandeln in Offsets auf den externen Datenträger, dann kann man bestenfalls ab diesem Offset die Daten in den Speicher laden (REU) oder muß beim Kopieren schauen, ob die Daten in den nächsten Speicherausschnitt des Speicherfensters hineinragen, und dann noch eine Speicheranfrage stellen (GeoRam).

    Wie gesagt: Schnell geht anders. Die erfolgreichste Methode, eine GeoRam einzusetzen, ist dann zumeist, sie wie eine Ramdisk zu verwalten, von der stets ganze Blöcke (= Sektoren) geladen oder geschrieben werden. Das setzt aber voraus, daß das Programm intern bereits so organisiert ist, daß es seine Daten blockweise verarbeitet (wie z. B. der Infocom-Interpreter).

    So oder so benötigt man ein virtuelles Speichersystem, was die Komplexität einer App drastisch steigert. Im schlimmsten Fall geht ein Programmierer so vor, daß er keinen internen Cache verwendet, sondern für jeden Zugriff auf ein Element eine neue Übertragungsanfrage an das OS stellt. Doch dann geht die Geschwindigkeit völlig baden.


  • Unter meinem Titelbild steht nicht ohne Grund " Der ewige Schüler " ;-)


    Ich hatte den Namen zwar mal gelesen, aber mich nie wirklich damit beschäftigt. Die Eigenschaften waren mir bis eben tatsächlich neu.


    Danke für die Infos.

  • Das Teil kannte ich bislang auch noch nicht. Danke für den Hinweis! :thumbup:


    Es klingt schon ganz gut, was für mich persönlich hier ein Nachteil ist: Nur LAN. Hier hoffe ich mal auf eine Neuauflage mit WiFi.

  • Nachteil ist: Nur LAN. Hier hoffe ich mal auf eine Neuauflage mit WiFi.

    Dafür wird voraussichtlich „bald“ eine neue Hardware kommen ;)

    Mehr kann ich aber noch nicht sagen.

  • WIe gesagt: Das Sidekick64 bietet heute schon an, die oben skizzierte Hardware zusammenzustellen. Daraus würden sich jede Menge neue Möglichkeiten für den C64 ergeben, ohne daß man die eigentliche Hardware verändert. Und wer auch immer sich darüber beschwert, daß das Steckmodul einen Prozessor hat, sollte sich besser auch keine 1541 zulegen. ^^

    mir fehlt die Zeit mehr als Hilfestellungen zu geben, aber ein paar Hinweise/Anregungen könnte ich gleich loswerden, nachdem ich das Sidekick64 ein bisschen kenne...


    Filesystem: Stephan Scheuer hat neben den REU u.a. Releases auch eine Toolchain für GeoRAM, mad^bkn hatte gefühlt über Nacht deren Dateimanagement für Pets Rescue und Alpharay auf eine GeoRAM-ähnliche Erweiterung umgestellt und dann gibt's natürlich noch GeoRAM/NeoRAM-Drive von enthusi (und einen C128 Port) --- Filesysteme mit Speichererweiterungen gibt es also viele Beispiele, die man anschauen kann


    Man sollte auch immer im Hinterkopf behalten, dass man auf dem Sidekick mehr emulieren kann, als man auf echter Hardware i.d.R. umgesetzt hat, z.B. mehr Auskodierung von Adressen. So wäre es ein Leichtes die IO-Bereiche mit mehr Registern zu belegen (und z.B. RAM und "Disk" parallel/im Wechsel zu betreiben, oder Teile eines IO-Bereichs für Register und RAM-Erweiterung zu nutzen). Man könnte ebenso einfach seriellen Speicher emulieren oder Speed Code on-the-fly generieren lassen, z.B. für "OS-Routinen" (hierzu verwendet https://www.dropbox.com/s/9cem…f9w/rotozoom.mp4.mp4?dl=0). Zudem gibt es noch die Möglichkeit Speicher bei $8000 und $a000 einzublenden (letzteres read-only, weil spezielle Beschaltung zum transparenten Wechsel in Ultimax nur für den Kernal mit Kabel existiert).


    Netzwerk: einfach mal emulaThor fragen, er hat (W)LAN-Features und Modem für's Sidekick implementiert


    Das noch nicht veröffentlichte Sidekick20 kann auch einen VIC emulieren (oder ersetzen und den VC20 ohne betreiben), aber auf dem C64 müsste man einen Schritt weitergehen und gleich die CPU mitlaufen lassen. Fragt man sich, ob man nicht gleich BMC64 für das Sidekick kompiliert ;-) Dennoch: eine grafische Ausgabe über HDMI kann man immernoch programmieren mit Features nach Wunsch (man kann es ja bei 320x200 und 16 Farben belassen... oder einen VDC emulieren), aber ich habe es so verstanden, dass das nicht gewünscht ist.

  • Fragt man sich, ob man nicht gleich BMC64 für das Sidekick kompiliert

    Eben. Das ist halt immer ein fließender Übergang und für jeden individuell verschieden, wo hier die Schmerzgrenze "jetzt ist es mir zu wenig Original" liegt.


    Ich habe z.B. einen C64 ohne Motherboard bekommen, dafür mit einem Keyrah drin. Den stecke ich an meinen SiDi (MiST-Klon) an und wenn ich hier den C64-Core laufen lasse, dann sehe ich nicht einmal optisch einen Unterschied zum C64. Trotzdem ist es kein original C64!


    Für mich ist die "Schmerzgrenze" die, dass alles an "Berechnungen" usw. weiterhin nur vom C64 bewältigt wird. Ob ein Datenträger eine echte Diskette, eine SD-Karte oder ein Modem mit Netzzugang vom Server ist, ist mir persönlich völlig schnuppe. Wenn aber plötzlich Grafiken oder Sounds ausgespuckt werden, die ein echter C64 von sich aus nicht kann, oder ein Tempo hingelegt wird, das 100-1000 mal schneller als der C64 ist, dann wird für mich es "unecht". Das kann der C64 halt nun mal nicht und "soll" er auch weiterhin nicht "können können". ;)

  • Für mich ist die "Schmerzgrenze" die, dass alles an "Berechnungen" usw. weiterhin nur vom C64 bewältigt wird. Ob ein Datenträger eine echte Diskette, eine SD-Karte oder ein Modem mit Netzzugang vom Server ist, ist mir persönlich völlig schnuppe. Wenn aber plötzlich Grafiken oder Sounds ausgespuckt werden, die ein echter C64 von sich aus nicht kann, oder ein Tempo hingelegt wird, das 100-1000 mal schneller als der C64 ist, dann wird für mich es "unecht". Das kann der C64 halt nun mal nicht und "soll" er auch weiterhin nicht "können können". ;)

    sehe ich i.W. auch so und wollte nur auf Möglichkeiten hinweisen. Ich finde eine gute Grenze (das ist aber natürlich nur meine Meinung) ist: was man damals (tm) hätte technisch umsetzen können, auch wenn es sehr aufwändig/teuer gewesen wäre, ist noch OK. Netzwerk, Druck nach PDF und SD-Massenspeicher natürlich ausgeschlossen.