Mit Exomizer wird der ursprüngliche Code (incl. der Lücke darin) so weit komprimiert, daß das Ganze (hoffentlich) nach dem Laden nur bis $1DFF geht (die Chance ist groß, daß das Komprimat nur etwa 2 bis 2,5 KB groß ist).
Nach dem Start mit RUN läuft dann der eingebaute Dekompressor, der stellt den ursprünglich vorgesehenen Zustand von $1001..$1FFF wieder her und startet dann dein Programm.
ich habe den Bildschirm auf 25*30 Zeichen erweitert. Dadurch ergibt sich die Verschiebung automatisch.
Danke. Das war das X im XY-Problem.
Ansonsten so wie J.E.E.K. bereits geschrieben hat - im später als Screen-RAM genutzten Bereich steht eine kleine Kopier-Routine + die Daten, die später ab 7168+25*30 (=7918) bis 8191 stehen sollen, beim Programm-Start braucht das "unten" dann nur Platz für ein JSR.
Das läßt im Original von $1C00..$1DFF vermutlich auch noch so viel Platz, daß Du da noch einige Init-Sachen mit unterbringen kannst, die Du später nicht mehr brauchst.
Edit: oder alternativ - assemblier' den Objektcode so wie Du ihn dir vorstellst, mit der Lücke von $1C00..$1EED gefüllt mit Nullen und packe das Ganze anschließend mit Exomizer. Der bringt das dann problemlos unter 3,5 K (mindestens weil sich die Lücke optimal komprimieren läßt) und der Drops ist gelutscht.
Edit 2: im Dekompressor solltest Du die Anzeige mit dem blinkenden "@" unten rechts ausschalten, da sonst $1FF9 zerhauen wird ...
Mich interessiert was ihr alles so in euren 64er bzw 128er eingebaut oder verändert habt.
Zählt auch der VC-20? 
Dann hätte ich feilzubieten (mit Fotos in den verlinkten Threads):
- VFLI mod (für den VIC-I zugreifbares RAM 'aufgebohrt' von 5K auf 8K, Farb-RAM 16Kx4),
2. S-Video mod (mit eigener Verstärker-Stufe),
3. gefixtes BASIC-ROM: gehebt einen *dicken* Fehler in der Multiplikations-Routine des BASIC-Interpreters.
...
2. und 3. sind "naturgemäß" immer im Einsatz, mit dem VFLI mod stellt der VC-20 Bilder mit der Auflösung von 208x256 Pixeln in 16 Farben dar. Dazu gibt es eine Anzeigeroutine (a.k.a. "Treiber"), die auf dem VC läuft und die neue Hardware so ansteuert wie nötig (aber altes Zeug läuft natürlich immer noch!) und ein Konverter der auf einem PC läuft und beliebige Bilder ins VFLI-Format wandelt.
In meinem aktuellen Programm für den VC20 habe ich den Screen RAM auf $1c00 verschoben und benötige unbedingt die regulären Screen-RAM-Adressen ($1e00-$1fff) für meinem Programmcode.
Und warum das genau?
Was spricht dagegen, wie gehabt $1E00..$1FF9 für den Bildschirm zu nutzen und dann eben $1C00..$1DFF für Code?
[...] Demos laufen mit SD2IEC nur wenn es One-Filer sind. [...]
Das eigentliche Kriterium ist nicht "Demo ist ein One-Filer", sondern: "Demo nutzt KERNAL-I/O".
Das Ausschluß-Kriterium ist also, daß das Programm (egal ob Demo, Spiel, Tool, was auch immer) nicht hingehen darf, und das Laufwerk umprogrammiert um z.B. ein schnelleres Transfer-Protokoll zu ermöglichen (bzw. eines, was erlaubt, Effekte weiterlaufen zu lassen, während die Demo nachlädt).
Leicht OT: Ingo hat etwa ein Dutzend Protokolle von C64-Schnellladern in der sd2iec-Firmware re-implementiert, die erkannt dann diese Schnelllader anhand von Prüfsummen auf dem Code der versucht wird in das Laufwerk zu laden. Auf dem C64 mag das noch angehen, für den VC-20 ist aber effektiv nur Jiffy-DOS als Protokoll verfügbar. Und JD taugt nicht als Track-/IRQ-Loader.
Grob als Anhalt: wenn ein Programm unter VICE mit "True Drive Emulation: Aus" (noch) läuft, dann läuft es im Regelfall auch mit einem SD2IEC. Die von Diddl verlinkte TRSI-Demo "Going Lowres" ist übrigens so eine Multi-Part-Demo, die mit einem SD2IEC auch geht.
... noch in Ergänzung zu den Links von Diddl: Die Quietsche
Ist es das worum es geht?
Das ist genau das erste Diskimage worauf ich im vorherigen Post verlinkt habe, ja.
Wo gibt es bitte den Basiccode für die MINIGRAFIK?
Falls das ein ernstgemeinter Versuch deinerseits ist, an den Quellcode von MINIGRAFIK heranzukommen: der ist auf der Festplatte meines PCs gespeichert, und da bleibt er auch.
Die ausführbare Datei von MINIGRAFIK ist in den *.d64-Dateien enthalten, die ich in einem anderen Thread letztens an einen Beitrag angehängt hatte. MINIGRAFIK läuft entweder für sich als BASIC-Erweiterung, wird also vor Programmen die es nutzen, geladen und gestartet - alternativ kannst Du es auch im Rahmen einer Stapelverarbeitungsprozedur hochfahren, die ein Nutzprogramm gleich mitlädt und das dann automatisch startet.
Also, Du kannst das Tool gerne nutzen, es gibt einem BASIC-Programmierer die Möglichkeit, einigermaßen schnelle Grafik-Routinen in BASIC auf dem VC-20 zu nutzen, ohne daß er sich in Maschinensprache hineinknien muß. Weiterhin dürfte es wohl eine der wenigen BASIC-Erweiterungen sein, für die mehr als nur ein oder zwei triviale Demo-Programme geschrieben worden sind.
Um noch mal auf meine Eingangsantwort zurückzukommen: bei dem Kenntnisstand, den Du hier demonstriest, wäre es vergebliche Liebesmüh', dir den Quellcode zu überlassen. Ohne Detailkenntnisse, wie der BASIC-Interpreter arbeitet, verstehst Du da gar nichts. Ich werde dich nicht davon abhalten (gehen würde das ohnehin nicht) dir mal den Code von MINIGRAFIK im Speicher mit einem Disassembler in irgendeinem Monitor anzuschauen ... viel Erfolg! 
Wenn das Ziel ist, schnell (!) in Assembler Grafik Punkte zu plotten basierend auf X und Y Koordinaten würde ich Tabellen nehmen und nicht in Maschinensprache versuchen die Basic Formeln von Mike 1:1 umzusetzen. [...]
Klar ist das das Ziel.
Ich hab' allerdings keine Ahnung, woher spacer jetzt diese Adreßfunktion hergezogen hat ... die von einer MINIGRAFIK-Bitmap ist erheblich einfacher mit AD=4352+192*INT(X/8)+Y ... wobei die (),Y-Adressierungsart des 6502 50% der Arbeit erledigt.
spacer will da stattdessen eine Bitmap mit 176 Pixeln Breite (336/16 wg. doppelt-hohe Zeichen = 21 Zeichen, 21x8=176) - warum auch immer - und dann höchstens 160 Pixeln Höhe mit zeilenweiser Anordnung der Zeichen bauen (mehr geht nicht, 176 Pixel Höhe gehen nicht bis 8191 rein). Soll heißen: die Programmzeilen im OP sind nicht von mir. 
...
Na, ja, Platz zum Ausprobieren gibt's ja genug. Die 160x192 Pixel von MINIGRAFIK sind trotzdem das Optimum, wenn man von dem durch den Videochip überhaupt nur ansprechbaren Speicher nur die 4 KB von $1000..$1FFF nutzt, weil man BASIC und KERNAL in den unteren 1 KB ($0000..$03FF) in Ruhe lassen will - und auch auf Interrupts oder Polling zum Umschalten von $9002/$9005 verzichtet, damit der Mode auch bei Diskettenzugriffen noch funktioniert.
Und wenn man schnelle Linien zeichnen will (so mit >30000 Punkten/Sekunde - richtig - dreißigtausend!), dann kann man sich auch nicht mehr leisten, für jeden Punkt die Adresse extra neu auszurechnen! An der Stelle muß man dann auch kräftig optimieren, und die bereits vorher berechnete Adresse nutzen (können).
Habe hier ein paar Programme, die ich gerne am VC-20 in einer gepackten und somit RUN-startfähigen Version hätte.
Kleine Anmerkung zum "somit": man kann durchaus (Maschinen-)Programme mit BASIC-Startzeile haben, die nicht gepackt sind; genauso kann man z.B. komprimierte (Level-)Daten haben ohne BASIC-Startzeile. Das eine hat nichts mit dem anderen zu tun.
Vier Hausaufgaben:
1. Mach dir klar, wie die SYS-Zeile funktioniert,
2. Zieh das Buch "VC-20 intern" heran,
3. Finde heraus, was die Zeile "POKE 44,34:POKE 34*256,0:NEW" macht,
4. Finde heraus, was die SYS-Zeile macht, nachdem:
-- der Rechner frisch eingeschaltet,
-- obige Zeile eingegeben wurde, und
-- dein Programm erst dann geladen und mit RUN gestartet wurde.
Bonuspunkte gibt es, wenn Du darlegen kannst, warum das Vorgehen auf echter Hardware unter Umständen dazu führt, daß dir der Rechner komplett abschmiert und Du nur *denkst*, daß es richtig funktioniert hat, weil die Endlosschleife zumindest bis zum Drücken von STOP+RESTORE nicht von dem Absturz unterschieden werden kann.
Fleißpunkte mit Goldsternchen gibt es, wenn Du den off-by-one-Fehler in den STA-Anweisungen findest und die vier Schleifen zu einer zusammengefaßt bekommst, wobei der Akku nicht ständig mit 0 geladen werden soll.
Das letzte Tape, was ich damals™ für meinen VC-20 im Fachhandel gekauft hatte, war Space Scramble von Mastertronic. Das war im September 1986, kurz danach ging das Netzteil vom VC fritten.
Nun ist (lt. kurzer Recherche) Space Scramble von 1984, also noch etwas älter, aber doch schon relativ spät - ich würde jedenfalls die Mastertronic-Titel insgesamt als diejenigen Softwaretitel für den VC ansehen, die zum Schluß der kommerziellen Verkaufsphase des VC am weitesten verbreitet waren und nicht Teil eines Re-Releases bzw. Collection waren.
Na, ja - und so viel an kommerziellen Tapes war das dann für den VC auch nicht. Das meiste eben aus abgetippten Listings ... getauscht mit Kumpels auf dem Schulhof, die ebenfalls dieser Methode der Softwarebeschaffung frönten (lach!) - für den nachfolgenden C116 hatte ich mir dann schon erheblich mehr an Original-Tapes besorgt (Tutti Frutti, Hektik, Winter Olympiade, Gullwing Falcon, F1 Simulator, ...)
1987 war auf jeden Fall nach Produktionsende des VC-20, wenn das also egal ist:
- Lunar Rescue, Astro Nell, Blue Star und Super Starship Space Attack von Cronosoft: link,
- Theater of War, Carling the Spider von Psytronik (Tape-Releases): link
- Avalanche, Mayhem, Down!, Stairrunner, Shifted, Rush (<-bereits genannt): link
- Pentagorat u.a. von TFW8B link
Sorry, aber ich meinte damit die Originalsoftware aus der Zeit.
Dann müßtest Du "die Zeit" schon genauer definieren. Wie gesagt, '87 ist dann eigentlich auch schon zu spät ...
... und nachdem einige Releases gar nicht so alt sind, fällt es schwer von "letzter" kommerzieller (Tape-)Software zu reden.
Bytebreaker : Um es mal mit den Worten eines uns allen bekannten Charakters zu sagen: Noch einen weiten Weg er zu gehen hat.
Den Hintergrund zu dem Codeschnipsel habe ich in einem anderen Thread bereits beleuchtet:
Wo sind bitte die Sonderhefte vom C64/VIC20 in Wolke ?
... weiter unten.
spacer : Das hier jetzt als klare Ansage und versteh' mich nicht falsch - diese 'ominösen' Zahlenfolgen in DATA-Zeilen waren ebenso genau das, was mich Ende 1985, so mit etwa 13 Jahren dazu gebracht hat, mir Maschinensprache selbst anzueignen. Ganz alleine anhand von Literatur (Computerzeitungen und -bücher) und ohne daß ich die Möglichkeit gehabt aber auch genausowenig die Notwendigkeit verspürt hätte, anderen (im echten Leben und online schon mal gar nicht) mit meinem Gefrage dazu auf den Keks zu gehen.
Wenn Du mal an einem nicht-trivialen Programm dransitzt und mit einem Detail nicht mehr weiterweißt, dann kannst Du von meiner Seite aus noch einmal erwarten, daß ich mich bemüßigt fühle auf eine deiner Fragen zu antworten. Alles, was durch Blick in die Standardliteratur (Bedienhandbuch zum VC-20, Programmierhandbuch zum VC-20 (<- beide von CBM), VC-20 intern und ggfs. 1541 intern) nicht zu klären ist, kannst Du gerne hier anbringen. Alles vorher: bitte selbst erarbeiten.
Ach so ja, dein nicht vorhandener Zitierstil ist ebenfalls überarbeitungsbedürftig. Mit dem Versuch, ein komplettes Programm von mir entweder als deins auszugeben oder zumindest zu "vergessen", wo Du es gefunden hattest, warst Du jetzt bei mir damit an den Falschen geraten. Bei so etwas verliere ich üblicherweise nicht den Überblick, selbst dann nicht, wenn der Code weit über 10 Jahre alt ist.
...
Edit: Und nun das obligatorische "Mist, wolfme war schneller!".
Ich denke, ich kann da weiterhelfen.
Die DATA-Zeilen mit dem Maschinencode stammen aus einem Funktions-Plotter für den VC-20, den ich 2006 mal im Denial-Forum veröffentlicht hatte, und der als Prototyp-Testprogramm für einen 160x192-Bitmap-Grafikmodus gedient hat.
Das war noch ganz ohne Unterstützung durch etwa eine BASIC-Erweiterung programmiert.
Der Grafikmodus ist an sich recht fix aufgesetzt, ein paar Schreibzugriffe auf VIC-Register, der Text-Bildschirm mit den nötigen Zeichen initialisiert und dann noch das Farb-RAM mit einer Farbe gefüllt. Das geht in ein paar Sekunden.
Was in BASIC nicht ganz so fix geht, ist, anschließend die 3840 Bytes der Bitmap auf 0 zu setzen. Das erledigt der erste Teil des Maschinencodes.
Der zweite Teil des Maschinencodes implementiert ein ON ERROR GOTO 180 ... das braucht so ein Funktionenplotter sinnvollerweise, damit er nicht abschmiert, wenn eine Formel als (Zwischen-)Ergebnis einen Fehler wie ?OVERFLOW, ?DIVISION BY ZERO oder ?ILLEGAL QUANTITY wirft. Nach dem "Aussetzer" soll der Plot einfach fortgesetzt werden.
...
Kurze Zeit später habe ich dann den Funktionenplotter mit MINIGRAFIK neu implementiert. Da enthält der Maschinencode dann auch nur noch das ON ERROR GOTO.
Ansonsten kann ich auch nichts dazu, wenn spacer so olles Zeug von mir ausgräbt, hier ist der Original-Thread:
http://sleepingelephant.com/ip…in/bb/viewtopic.php?t=952
Viele Grüße,
Michael
spacer
: Die Routine, welche den entsprechenden Grafikmodus einstellt, sieht im Quellcode wie folgt aus:
Nach deren Ausführung kannst Du auf eine Bitmap ab $1100 mit 160x192 Pixeln zugreifen, mit der Adreßfunktion AD=4352+192*INT(X/8)+Y, die Farbattribute stehen im Farb-RAM von $9400 bis $94EF und gelten für Bereiche mit 8x16 Hires-Pixeln, Hires (Bit 3 = 0) und Multicolour (Bit 3 = 1) können gemischt werden. Von $1000..$10EF wird dem VIC-Chip ein Adreßgenerator in die Bitmap zur Seite gestellt, dieser Bereich ist als schreibgeschützt zu betrachten.
Bitmap löschen, Punkte setzen, Linien ziehen, etc. kannst Du jetzt entweder alles selbst machen oder dir anschauen, wie MINIGRAFIK das implementiert.
Viele Grüße,
Michael
Quote from mc71Der VC 20 hat keinen Grafikmodus.
Komisch. Dann machen all die Sachen in den Anhängen hier wohl irgendwas verkehrt ...
Interessant vor allem, dass hier sogar der Rahmen für den Spielinhalt benutzt wird. Oder ist das ein Bug im VICE?
Der VIC im VC-20 hat vier Register, mit denen man die horizontale und vertikale Position und Größe des Anzeigefensters frei einstellen kann. Insofern ist das nichts bahnbrechend neues, auch kein irgendwie gearteter "Bug" in VICE, sondern: wenn man es nutzen kann, nutzt man es eben halt.
Allerdings läßt sich so nur auf einem PAL-VC-20 die nutzbare Bildfläche signifikant erhöhen. Bei einem NTSC-VIC-20 nimmt das Standard-Fenster mit seinen 22x23 Zeichen auf üblichen Fernsehern fast die ganze Fläche ein, da geht kaum noch was extra. Bei PAL hat man hingegen ringsherum durchaus 3 bis 4 Zeichen, die noch dazu passen und dann da zu liegen kommen, wo vorher der Rahmen war - die Größe der Pixel bzw. Zeichen bleibt gleich!
Kleiner Tip: ab und zu mal bei Denial vorbeischauen. Da wird der VC-20 etwas genauer beleuchtet, und die variable Schirmgröße gehört da eher zu den "Basics". 
Hübsch!
Das ROM vom originalen Super-Expander war auch nur 4K groß (in BLK5 von $A000 bis $AFFF) und belegt damit die beiden linken oberen EPROMs.
Für den Inhalt der beiden EPROMs rechts (ab $B000 bis $BFFF) gibt's sicher ein paar nette Kandidaten - evtl. ein relozierter VIC-MON, oder Programmers' Aid. Oder halt was eigenes.
Bin gespannt, was Du da findest, wenn Du die EPROMs mal ausliest.
Vom Design her finde ich nur etwas unglücklich, daß die Bausteine in der benachbarten Reihe jeweils "auf dem Kopf" stehen. Da vertut man sich schnell man beim hinzustecken ...
Nochmal zum eigentlichen Thema.
Gibt es die Möglichkeit für einen alternativen, schmaleren Systemfont des VC20?
... ich hab' hier in einem *.d64 auf meiner HD eine interessante Datei mit dem Namen "HIRES EDITOR" gefunden.
Nach dem Start mit RUN (mind. eine 8K-RAM-Erweiterung ist erforderlich) wird mit 'f1' entweder ein Joystick-gesteuertes (und im wesentlichen unbrauchbares) Malprogramm gestartet, oder mit 'f3' eine "40-Zeichen-Karte", die auf dem eingebauten Videochip läuft und mit schmalen (4x8 Pixel) Buchstaben einen 40x24 Textbildschirm realisiert.
Müßtest Du halt mal testen, wie gut das Tool mit JiffyDOS zusammenarbeitet.
Weiterhin erzeugt das Programm eine geänderte Speicheraufteilung, die Kompatibilität dürfte also auf BASIC-Programme und Maschinenprogramme die nur KERNAL I/O nutzen beschränkt sein.
So... mal sehen was Cloudflare jetzt mal wieder macht... Ctrl-A, Ctrl-C uuu-nd Absenden! 
Der 1. Versuch ist schonmal fehlgeschlagen. Auf ein neues.
Edit: so, beim 2. Versuch ging es jetzt.
[...] Ein Grafik- bzw Bitmapmodus ist es eben nicht. [...]
Och jo, wenn Du das sagst ...
Sowas am C64 muss doch bedeuten, dass man beim Zeichnen schneller ist als mit einer Hires Bitmap. D.h. Wenn man in ein Charset schreibt mit dem man den Textbildschirm gefüllt hat. [...] Mit 4 Charsets, die sich per Rasterzeilenabfrage abwechseln hätte man theoretisch einen Bitmap Vollbildschirm am C64 im Textmodus.
Ich hab' das auch praktisch schon mal gemacht.
Jetzt nicht speziell wegen einer einfacheren Adreßberechnung, sondern weil man dann den Multicolor-Text-Modus verwenden kann und so (wie auch beim VC), Bereiche in Hires und Multicolor mischen kann:
Bitmap mit Multicolour-Textmodus
P.S. ein Glück, daß der erste Teil des Beitrags schon drin war. Beim Edit (um die URL zu ergänzen) hat Cloudflare erstmal auch wieder zugeschlagen.
