Commodore als Firma neu aufstellen, um moderne Maschinen zu bauen ... Für ersteres braucht man schon ordentlich Geld und Manpower und natürlich eine Bombemidee.
Eine Idee gibt es hier schon: Neuer Retro-Computer im 8-Bit Style
Beiträge von ogd
-
-
Das ist der Nachteil von Programmen, die sich nicht an die Programmierschnittstelle von GEOS halten. GeoBASIC nutzt undokumentierte Routinen im GEOS-Kernal
Aus Schludrigkeit oder bietet die API nicht die erforderliche Funktionalität?
-
Hier wäre es interessant deutsche Softwareschmieden zu fragen wie das das gehandhabt haben oder hätten. Auf Anhieb fällt mir kein deutsches Softwarestudio ein, dessen Titel indiziert worden wären. Allerdings habe ich da jetzt auch nicht wirklich nach gesucht.
Hans ippisch ist heute noch stolz, das erste indizierte deutsche Spiel ("Solider") für Rainbow Arts geschrieben zu haben.
-
Ich nehm einfach meist emacs und ein Makefile
Für Anfänger/Einsteiger eher suboptimal.
-
Wem interpretiertea Basic zu langsam ist, sollte einen Compiler benutzen.
-
Wahrscheinlich zu starker Fokus auf die Schulen?
Oder kann es auch sein, dass die Jungs damals das ganze Potenzial von COMAL gar nicht richtig erkannt haben?
Ein Compiler hätte Comal vielleicht zu einer größeren Verbreitung verholfen. So blieb es nur eine Lehrsprache.
-
Wie kann man einen RAM-Speicherbereich auf Disk (#8/1541) ohne vorlaufende RAM-Startadresse (Dateigröße nur 8kb) speichern ?!?!?!
Den Bereich byteweise abspeichern. Eine Datei zum Schreiben kann per OPEN "<filename>,p,w" geöffnet werden.
-
Das Kung Fu Flash 2 ist ein Software definiertes Modul ...
Man muss nur das Modul in C beschreiben wie es hier für das PageFox Modul gemacht wird ...
Das PageFox habe ich sogar hier, aber kein KFF2. Wenn man das auch mit einer Ultimate Ii+ machen könnte, würde ich das gerne mal ausprobieren.
-
Würde man ein Ultimax OS-Modul benutzen braucht man das C64 RAM nicht retten, da es deaktiviert und nicht nutzbar ist.
Aber das C 64-RAM von $0000 bis $0fff ist dann immer noch benutzbar, oder? Und welches RAM benutzt dann der VIC?
-
OK, ich skiziere mal, wie ich mir das aus Programmierersicht vorstellen:
* Der C 64 bootet vom 'Modul' und aktiviert das neue OS
* Das Modul lässt sich per Software deaktivieren, startet ein PRG und ist bis zum nächsten Reaet unsichtbar
* Im Adressraum gibt es:
- einen fixen RAM-Bereich, das nicht gebankt wird ($0000-$0fff)
- einen möglichst maximalen RAM-Bereich, das gebankt werden kann ($????-$????)
- (optional) einen ROM-Bereich, das geflasht werden kann ($e000-$ffff)
- (optional) die Granularität des RAM-Banking ist konfigurierbar
- (optional) der ROM-Bereich ist auch Banking-fahig
- (optional) der vom VIC sichtbare RAM ist Banking-fähig
-
Es geht um eine Hardware die ein komplett neues OS mit RAM paging ermöglicht. Kompatibilität mit existierender Software ist daher nicht relevant.
Ja, genau. Nur wäre es nett, wenn das Modul sich softwaremäßig deaktivieren lassen und dann herkömmliche Software starten könnte.
-
Kurz gesagt so ein Modul zu bauen ist kein Problem es ist nur nicht mit irgendwelche C64 Software kompatibel.
Man muss also ein eigenes OS mitliefern
Das wäre in diesem Fall kein Problem, weil das Modul ja fur ein neues OS verwendet werden soll
-
Es würde schon reichen, das im Prinzip wie Easyflash zu machen. Nur das nicht ROM, sondern "Arbeits"-RAM in den Adressraum der CPU eingeblendet wird.
Werden denn in den üblichen GAME-Konfigurationen Schreibzugriffe auf ROML/ROMH auch von der PLA an die Cartridge via R/#W durchgereicht?
Da bin ich überfragt. Ich kann Hardware nur programmieren, aber weder entwerfen noch bauchen. Den Verweis auf Easyflash habe ich deswegen gebracht, weil man damit das Kernal ohne HW-Mods ersetzen und mehrere Bänke zur Verfügung hat. Ob und wie es technisch realisiert werden kann, ist natürlich eine andere Frage.
-
In dem die Memory Map so aussieht:
Überall wo BLANK steht kann man dann extern Speicher einblenden.
Diese Memory Map ist allerdings nicht besonders nützlich wenn ich kein Spiele Modul am Expansion Port habe.
Es würde schon reichen, das im Prinzip wie Easyflash zu machen. Nur das nicht ROM, sondern "Arbeits"-RAM in den Adressraum der CPU eingeblendet wird.
-
Was würdest du dir den wünschen was nicht mit REU oder GEOram, bzw. deren nachbauten abgedeckt ist?
Der Minimalwunsch wäre eine am Expansionsport ansteckbare Erweiterung, die RAM-Bänke (1kB oder größer) in den Adressraum der 6510-CPU einblenden und das Kernal mit FlashROM odee so ersetzen kann.
-
Da wuerde ich GEOram nehmen....
Ein Georam ist doch eher eine Ramdisk.
-
Weil das hier leider eingeschlafen ist:
Gibt es einen Hardware-Designer, den die Idee, eine "Easyflash mit RAM-Bänken" reizen würde?
-
Ich habe mittlerweile den Eindruck, dass COMAL-Programme, die Gebrauch von allen Features der strukturierten Programmierung machen, während des Ablaufs deutlich mehr Speicherplatz verschlingen als einfache V2-BASIC Programme.
Das würde auch den Minimalismus von Microsoft Basic erklären, dass auch mit sehr wenig RAM auskommen musste.
-
Es ist jetzt eine globale Variable geworden. 😩
Gut, dass wir darüber gesprochen haben
-
In modernen BASICs wie VB gibt es dafür STATIC-Variablen. Wenn man die innerhalb einer Prozedur deklariert, dann steht der Wert auch beim nächsten Aufruf der Prozedur noch zur Verfügung. Sowas hat COMAL aber leider nicht.
Comal ist ja stark von Pascal inspiriert und in Pascal gab es auch keine nicht-globalen, statischen Variablen, die ein Prozeduraufruf überleben. Deshalb wird man leider auch in Comal auf globalen Variablen zurückgreifen müssen.
Genau für solche Fälle sind die globalen Variablen doch gedacht: Sie stehen allen Prozeduren übergreifend zur Verfügung.
Wenn man die Sichtbarkeit auf eine Prozedur begrenzen könnte, wäre das schon besser.
Man entwickelt ein Zusatzpaket, das die Funktionalität zur Verfügung stellt. ... Muss auch erst geladen und vorbereitet werden, bietet also praktisch keine Vorteile.
Ein Paket scheint für mich schon die sauberste Lösung zu sein.
