Hello, Guest the thread was called4.9k times and contains 32 replays

last post from Mike at the

VC20: Programmierung

    Aufgrund des Theads "Textadventure(s) auf Deutsch?" hatte ich mir mal spaßeshalber den VC20 etwas genauer angesehen. ( cbm-warrior: Danke für die Info!) Nachdem ich in der Wolke nach Literatur gesucht hatte, aber in bezug auf vertiefende Themen nicht so sehr fündig geworden bin (ein wenig in Assembler programmieren kann ich schon), habe ich mir mal die Threads in dieser Kategorie angesehen, jedoch auch nichts zum Thema "Programmieren auf dem VC20" gefunden. Liegt es daran, daß die Programmierung wegen des 6502 und der Nähe zum C64 in der Kategorie "Programmieren/Asm" mitbehandelt wird, oder gibt es heutzutage schlicht niemanden mehr, der noch für den VC20 programmiert?
    Dabei hätte ich eigentlich der Interesse halber noch einige Fragen, z. B.:
    - Gibt es noch VC20 mit der ursprünglichen Ram-Ausstattung von 5kb oder sind alle Geräte inzwischen aufgerüstet auf mindestens +8?
    - Für welche Speicherkonfiguration programmiert man für gewöhnlich?
    - Ist es sinnvoll, das Programm im Speicher abzulegen, oder sollte man besser ein 8kb-Modul nehmen? Oder geht das nicht, weil üblicherweise der Modulschacht anderweitig belegt ist?
    - Gibt es irgendwo Netzseiten über spezielle Programmierung von z. B. Pseudo-Rasterinterrupts? Wie ist das mit der Erhöhung der Auflösung?
    - Gibt es vielleicht Demos? Oder gar Sourcecode dazu?


    Ich bitte um Verzeihung, wenn ich hier dumm frage. Bislang hatte ich nie Zugang zu einem VC20, und daher ist das Gerät völliges Neuland für mich. :(

    Hab vor ner Weile einen seeehr mitgenommenen vc20 bekommen. Musste vor der Reparatur erstmal die ganzen Spinnen rausekeln. Aber er scheint nun zu gehen. Die f7 Taste fehlt leider noch.


    Aber ich hab leider nie etwas für den vc20 programmiert. Das Gerät ist im Urzustand. Hab keinerlei Erweiterungen. Wenn Du also Hardware zum Testen bräuchtest...


    EPROM Brenner für ein Modul hätt ich auch da...aber keine Platine dafür.

    Alle VC20 haben 5KB RAM wovon 3,5KB nutzbar sind.


    Damals war RAM extrem teuer.


    Es gab RAM Erweiterungen mit 3KB.


    Und später gab es welche mit 8KB.
    Die 8KB sind mapbar und über DIP Switch einstellbar.


    Es gab auch ROM Module mit 8 und 16KB (Spielmodule).
    Manche haben auch noch RAM mit gebracht.



    Die Final Expansion (FE3) ist eine moderne Erweiterung für den VC20 die jede erdenkliche Speicher Konfiguration nach bilden kann.

    Quote from M. J.

    Gibt es noch VC20 mit der ursprünglichen Ram-Ausstattung von 5kb oder sind alle Geräte inzwischen aufgerüstet auf mindestens +8?

    Die allermeisten VC-20 haben nach wie vor die Standard-Ausstattung an internem RAM. Eben die 5K. Üblicherweise werden Speichererweiterungen extern angesteckt. Interne Speichererweiterungen sind eher nicht-Standard. Es wird zumeist darauf verzichtet, weil es eben auch ohne Umbau auf der Hauptplatine extern geht. Außerdem gibt es viele Programme für die Grundversion, die mit einer größeren Speichererweiterung nicht ohne weiteres laufen, da ab +8K RAM der Speicher gründlich umorganisiert wird.


    Quote from M. J.

    Für welche Speicherkonfiguration programmiert man für gewöhnlich?

    Einfach gesagt, man nimmt soviel RAM-Speicher wie das Programm eben braucht.


    Du findest eigentlich alles von Grundausstattung über +3K, +8K, +16K, +24K, +32K (BLK1..3 und BLK5) bis +35K (+32K plus +3K).


    Ein "weiches" Limit, welches ich mir mal gelegentlich gesetzt habe, ist +16K. Das ist die größte offiziell von Commodore vertriebene Speichererweiterung. Wenn man auf Original-CBM-Teile besteht, erfordert alles darüber hinaus den Einsatz einer Modul-Box und das ist extrem umständlich.


    Quote from M. J.

    Ist es sinnvoll, das Programm im Speicher abzulegen, oder sollte man besser ein 8kb-Modul nehmen? Oder geht das nicht, weil üblicherweise der Modulschacht anderweitig belegt ist?

    Programmier' ganz normal so in BASIC und Assembler, wie Du es vom C64 gewohnt bist. Überall, wo RAM eingeblendet werden kann (vom Modul) kannst Du auch ROM einblenden. Gibt auch einige *neuere* +32K ROM Module. Wohlgemerkt, ohne das dazu Paging nötig wäre.


    Einfacher ist es aber, eine große RAM-Speichererweiterung zu nutzen.


    Quote from M. J.

    Gibt es irgendwo Netzseiten über spezielle Programmierung von z. B. Pseudo-Rasterinterrupts? Wie ist das mit der Erhöhung der Auflösung?

    Sofern Du mit Englisch zurechtkommst, wirst Du zu diesen Themen im Denial-Forum mehr als fündig:


    http://sleepingelephant.com/ipw-web/bulletin/bb/index.php


    Läuft aber, wie ich bereits mehrfach hier im Forum64 angemerkt habe, anscheinend völlig unter dem Radar hier.


    Quote from M. J.

    Gibt es vielleicht Demos? Oder gar Sourcecode dazu?

    Gibt schon einige. Dieses Jahr gab's auf der Revision sogar mal insgesamt vier Beiträge (2 Bilder, 1 Demo, 1 Intro) für den VC. Da ist aber auch sicher noch Luft nach oben. ;)


    Sourcecode zu Demos ist ja wohl allgemein eher rar gesät. Aber auch zu raffinierteren Programmiertechniken - siehe den Link oben. :)


    ...


    Ich bin ja auch in Denial unterwegs. Meld' dich dort an, und wenn Du beim Stöbern was interessantes findest, schreib mir da kurz eine PM.


    Gruß,


    Michael



    P.S. und wie oobdoo auch gerade eben schrieb - das "VC-20 intern" von Data Becker ist ein must-have. Ist in der F64-Wolke.

    Quote from oobdoo

    Hast Du Dir das Intern angeschaut?

    Danke. Hab's gefunden und mir die genaue Speicherbenutzung angesehen. Welche außer den üblichen verdächtigen (wie FAC#1 und FAC#2) Zeropageadressen sind eigentlich frei für die Assemblerprogrammierung (, wenn man notgedrungen aus Speichermangel auf die Kernalroutinen zurückgreifen muß)?

    Quote from daybyter

    Wenn Du also Hardware zum Testen bräuchtest...

    Also so echte Hardware ist schon eine feine Sache, allerdings wäre ich ohne Zusatzhardware wie Brenner nicht direkt in der Lage, das Gerät auch zu nutzen. Als Floppy steht mir nur eine alte 1571 mitsamt Zoomfloppy (dank TRW) und ein paar Disketten zur Verfügung, aber kann man die überhaupt an einen VC20 anschließen? Wahrscheinlich würde ich für eine Programmierung auf dem VC20 wohl zunächst auf einen Emulator zurückgreifen. (Wenn ich daran denke, daß ich es noch nicht einmal schaffe, meinen C128 oder Amiga wieder aufzubauen... )

    Quote from Mike

    Denial-Forum

    Ah, danke für den Tip. Da kann ich mal ein wenig stöbern.

    Quote from Mike

    Sofern Du mit Englisch zurechtkommst

    A little Englisch can i still from earlier.

    Quote from Mike

    Meld' dich dort an

    Das mit dem Anmelden ist so eine Sache bei mir. Wenn ich überlege, wie lange es gebraucht hat, um mich hier anzumelden...

    Quote from Mike

    Ein "weiches" Limit, welches ich mir mal gelegentlich gesetzt habe, ist +16K.

    Okay, ein guter Richtwert. Wegen der Anfrage nach Textadventures hatte ich mal geguckt, wieviel Platz ein sehr simpler Parser mitsamt Ein-/Ausgabe verschlingt und kam dabei tatsächlich auf das geschätzte 1 KB. Dazu gehört aber noch die Aktionsüberprüfung und -auswertung, die sicherlich ein weiteres kb benötigt. Dann wäre der Speicher von $1000..$17ff für das Programm an sich belegt, und es blieben bei einem Speicher von 5 kb noch der Bereich von $1800..$1dff übrig für die eigentlichen Daten, d. h. Strings und Adventurecode. Nicht gerade sehr üppig. Daher wären +16K sicherlich sinnvoll.

    Quote from Mike

    Außerd.em gibt es viele Programme für die Grundversion, die mit einer größeren Speichererweiterung nicht ohne weiteres laufen, da ab +8K RAM der Speicher gründlich umorganisiert wird.

    Das ist ein Punkt, den ich immer noch nicht richtig verstanden habe. Wenn der Speicher so umgestaltet wird, kann ein Assemblerprogramm, welches für $1000 geschrieben wurde, auf einem +3 oder +8-System nicht mehr mittels "LOAD"<name>,8" geladen werden, da sich die Ladeadresse verschoben hat. Auf erweiterten Systemen müßte man solche Programme mit "LOAD"<name>",8,1" laden und per SYS aufrufen. Mit anderen Worten: So einen Basic-Programmkopf mit SYS-Befehl, wie man ihn vom C64 kennt, macht dann keinen rechten Sinn mehr, oder? Oder ist es vielleicht so, daß man den (externen) Speicher nach Bedarf von außen einfach ein- oder ausschaltet, damit dann ein Programm in einer bestimmten Konfiguration läuft?

    Quote from M. J.

    Oder ist es vielleicht so, daß man den (externen) Speicher nach Bedarf von außen einfach ein- oder ausschaltet, damit dann ein Programm in einer bestimmten Konfiguration läuft?

    Genau das. Zumindest in erster Näherung.


    Prinzipiell gibt es drei verschiedene "Haupt"-Speicherkonfigurationen am VC-20:


    1. nicht-erweitert: BASIC bei $1001 (bis $1DFF), Bildschirm bei $1E00 (bis $1FFF),
    2. +3K: BASIC bei $0401 (bis $1DFF), Bildschirm bei $1E00 (bis $1FFF) und
    3. alles mit +8K oder mehr: BASIC bei $1201 (bis $3FFF, $5FFF oder $7FFF), Bildschirm bei $1000(!).


    Sobald eine große RAM-Erweiterung drin ist, wird eine evtl. auch gesteckte +3K Erweiterung für BASIC weggesperrt, da es aus Hardwaregründen nicht möglich ist, den Bildschirmspeicher bei $0400 zu haben. RAM in BLK5 ($A000..$BFFF) zählt für BASIC auch nicht, da nicht mit dem "normalen" BASIC-RAM an einem Stück. BASIC-Stubs mit den SYS-Befehlen werden entsprechend auf die passende der drei o.g. Konfigurationen ausgeführt. Und dann stellt man eben zuvor die richtige Erweiterung, oder eben keine ein.


    Lästig ist eben, daß "mehr" Speicher eben nicht bedeutet, daß auch "mehr" Programme laufen. Die drei genannten Konfigurationen schließen sich effektiv gegenseitig aus. Du mußt also immer genau den Speicher stecken, der spezifiziert ist. Zwei Ausnahmen:


    - Reine BASIC-Programme für einen nicht-erweiterten VC laufen in der Regel auch mit einer +3K-Erweiterung. Bringt jetzt nicht sooo viel.
    - Programme für +8K laufen auch mit +16K und +24K und Programme für +16K laufen auch mit +24K.


    Deswegen ist es für die dritte Option am sinnvollsten, man macht direkt den vollen Ausbau, mit +35K (also: +32K *plus* +3K!).


    Und jetzt kommt die zweite Näherung - mit diesem Vollausbau am Start kannst Du durch:


    POKE642,16:POKE644,30:POKE648,30:SYS64818


    auf die RAM-Konfiguration des nicht-erweiterten VC-20 zurückstellen. Und mit


    POKE642,4:POKE644,30:POKE648,4:SYS64818


    bekommst Du die RAM-Konfiguration der +3K-RAM-Erweiterung. Diese Änderungen gelten dann bis zum nächsten Reset oder Power-Cycle. Und damit entfällt das lästige Umstecken der RAM-Cartridge. :)


    (... mit meiner zuvor erwähnten "Lieblings"-Erweiterung, der 16K, geht allerdings nur das Zurückstellen auf "ohne Erweiterung", da diese Cartridge kein RAM im Bereich der +3K-Erweiterung zur Verfügung stellt. Probiert man es trotzdem, steht zwar die "richtige" Anzahl an freien Bytes in der Einschaltmeldung - aber die Bytes eines eingegebenen/geladenen Programms landen im Nirvana ...)

    Quote from M. J.

    - Ist es sinnvoll, das Programm im Speicher abzulegen, oder sollte man besser ein 8kb-Modul nehmen? Oder geht das nicht, weil üblicherweise der Modulschacht anderweitig belegt ist?

    Naja, entweder läuft das Programm aus einem Modul, dann ist der Modulschacht durch das Programmmodul belegt
    Oder das Programm läuft im RAM, dann ist der Modulschacht durch die RAM-Erweiterung belegt.
    So oder so, der Modulschacht ist bei einem nicht gemoddeten VC20 immer belegt. :D


    Mein VC20 soll aber demnächst eine interne Speichererweiterung bekommen (RAM/ROM-Board von Nicolas Welte).

    Quote from detlef

    So oder so, der Modulschacht ist bei einem nicht gemoddeten VC20 immer belegt.

    Sowas habe ich schon befürchtet. :( Da vermute ich mal, daß bei den meisten am ehesten ein Ram-Modul gesteckt ist.

    Quote from Mike

    Und jetzt kommt die zweite Näherung

    Guter Tip. So kann man sich das Umstecken der Hardware sparen.

    Quote from Diddl

    Und später gab es welche mit 8KB.

    Quote from Mike

    - Programme für +8K laufen auch mit +16K und +24K und Programme für +16K laufen auch mit +24K.

    +8kb sind wohl die beste Wahl. Das gibt massig viel zusätzlichen Speicher von $2000..$3fff, und es ist noch relativ kompatibel.


    @alle: Vielen Dank für die schnellen Antworten! Der VC20 ist schon irgendwie eine interessante Kiste und auf jeden Fall eine Herausforderung für einen Programmierer. ^^

    Quote from daybyter

    Wäre es lustiger zu schauen, was man ohne Speicherausbau machen könnte?

    Das ist eine gängige Disziplin und Du findest da auch massig Beispiele.


    Allerdings ist der interne Speicher des VC-20 auch genau nur der, den der Videochip ansprechen kann. Alles am Expansionsport, bzw. auf der "CPU-Seite" von Adreß- und Datenbus (dazu zählt auch die Erweiterung von Nicolas Welte) ist für den VIC nicht ansprechbar.


    Das führt nun zu einem nicht ignorierbaren Resourcen-Konflikt zwischen Programm- und Grafikdaten beim nicht-erweiterten VC-20. Mit einer Speichererweiterung kann man hingegen die Programmdaten weitestgehend im Erweiterungsspeicher halten und den internen Speicher hauptsächlich für Grafikdaten nutzen. Nur so kriegt man sinnvoll eine große Bitmap am VC-20 hin.

    Quote from daybyter

    Wäre es lustiger zu schauen, was man ohne Speicherausbau machen könnte?

    Lustig schon. ^^ Meine ersten Überlegungen gingen genau diesen Weg: Mal schauen, wie weit man mit 5kb kommt. Realistisch gesehen sind 5 kb aber wohl zu wenig für ein Textadventure (, was der Anlaß für mich war, mir den VC20 mal anzusehen). Wieviel Spiel am Ende in 5kb paßt, kann ich aber wohl erst sagen, wenn ich konkret ein egal wie kleines Adventure kompiliert habe inklusive Stringkompression. Dazu müßte ich aber vorher den Compiler überarbeiten, der den komprimierten Bytecode erzeugt. Eine direkte Programmierung eines Adventures in Assembler würde ich nicht probieren wollen, da a) es viel zu umständlich ist, b) der Platzbedarf mit steigernder Zunahme des Adventurecodes in reinem Assembler deutlich größer wird als die Kombination Bytecode+Interpreter, zumal Besonderheiten wie indirekte Sprünge in Bytecode einfacher zu realisieren sind.

    Uhi, da wird's mit 3,5 KByte aber echt knapp. Selbst ganz dünne FIG-Forth-Varianten brauchen gleichmal mind. so viel Platz.
    Da müsste das Forth-Basissystem schon im ROM liegen, damit man in den 3,5 KByte für weitere Programme hat.


    Man könnte freilich probieren den Forth-Source-Code, der nicht selten als Assembler-Source vorliegt, so zu verschlanken,
    dass für eine Anwendung nur genau jene Words (samt Abhängigkeiten) erstellt werden, die tatsächlich gebraucht werden. Das müsste man aber alles per Hand machen - ich wüsste jetzt nicht, dass es entspr. Assembler oder einen entspr. Sourcecode gäbe, der dahingehend ausgerichtet ist.

    Es gibt derweil eine aktuelle Portierung von Forth (nach 83'er Standard) auf dem VC, von Simon Rowe:


    http://sleepingelephant.com/ip…n/bb/viewtopic.php?t=7557


    (... auch auf Denial ...) Die Implementierung ist insofern recht modern, daß sie nicht mehr mit "Screens" arbeitet, sondern den Full-Screen-Editor vom KERNAL ganz normal nutzt und ansonsten auch auf Dateien bzw. Libraries von Diskette zugreifen kann.


    Aber das Hauptexecutable ist schon mal 8K groß und mit weniger als einer +24K-Erweiterung will man auch gar nicht erst loslegen.


    ...


    M.M.n. kriegt man sicher "fertige" Programme/Spiele auf dem nicht-erweiterten VC-20 (entweder in BASIC oder mit Cross-Entwicklung) hin, aber der Anspruch "Entwicklungssystem+ausführbares Programm" führt schnell zu klaustrophobischen Anfällen.

    Ich würde da den Reiz sehen mit weniger einfach auszukommen. Also Standardkonfiguration.


    Ausserdem könnte man Routinen / Grafiken / Text von Disk nachladen. Muss ja nicht zwingend alles auf einmal im Speicher sein.