Google Bildersuche rulez.
Jetzt weiß ich auch, dass die gute Frau kein Fieber hat. Anbei, wie das Foto eigentlich aussehen soll, und eine schnelle Umwandlung in NUFLI. Als MUIFLI ginge da noch einiges. Ich habe vor dem Konvertieren das Bild um ~16/15 in die Breite gestreckt, damit das Seitenverhältnis mit dem PAL-C64 exakt beibehalten wird.
Danke für das Aufspüren des Originals! Hier mal zum Vergleich die Dame in 208x256 VFLI auf dem VC-20: 
Der Vollständigkeit halber hier noch die VFLI-Konversion zum Ausprobieren auf echter Hardware oder in Emulation (dazu im VICE unter "Cartridge/IO settings" den Haken an "Enable VFLI modification" setzen). 
Danke für das Aufspüren des Originals! Hier mal zum Vergleich die Dame in 208x256 VFLI auf dem VC-20:
Gerne. 
Mit dem VC20 und den Sondermodi muss ich mich auch mal auseinandersetzen. Hab ja so ein Ding her wegen der Palettensache. Für den Modus brauche ich aber mehr RAM, oder?
Das mit dem RAM hat mich bisher davon angehalten, viel mit dem Teil zu machen. Jedes Programm will da gefühlt nen anderen RAM-Ausbau.
Mit den etwas satteren Farben des VC20 und ihrer "natürlichen" Helligkeit kann man durch Mischen bestimmt einen größeren Farbraum Farbraum abdecken als mit dem C64.
Du kennst Dich vermutlich am besten aus mit dem VIC-I. Darf ich Dich bei gegebener Zeit mal löchern wegen der Grafikmodi?
mfg Tobias
Für den Modus brauche ich aber mehr RAM, oder?
Die Grafikdaten kommen alle im internen RAM (was eben durch den VFLI mod auf der "VIC-Seite" auch um 3 KB erweitert wird) bzw. im erweiterten Farb-RAM unter. Die Displayroutine braucht allerdings auch noch Speicher, mindestens in BLK1. In der Emulation stellst Du am besten einfach den RAM-Vollausbau ein und - wie oben bereits beschrieben - unter "Cartridge/IO" den Haken an "enable VFLI modification".
Auf echter Hardware ist der Umbau der Hauptplatine entsprechend dem verlinkten Thread zwingend erforderlich. Ohne den Umbau bekommt man eine derartige Anzeige nicht über die volle Bildschirmbreite hin *), auch nicht mit einer RAM-Erweiterung die ansonsten den Vollausbau macht. Das liegt daran, daß jegliche externe (RAM-)Erweiterung aus Sicht des VIC auf der 'falschen' Seite der Bus-Buffer liegt. Der VFLI mod bindet darum den Speicher zwischen $0400..$0FFF so ein, daß er auch vom VIC gelesen werden kann (und der CPU als +3K-RAM-Erweiterung erscheint), zudem hat das Farb-RAM jetzt 16 Bänke a 1K Nibbles.
Für den VFLI-Modus wird die Bank des Farb-RAMs jetzt in jeder Rasterzeile umgeschaltet, dadurch sind die Farbattribute (wie bei den FLI-Modi des VIC-II) nur noch 1 Pixel hoch. Da der VIC-I ohnehin in jeder Rasterzeile das Text-RAM und das Farb-RAM neu liest, muß man das noch nicht mal extra neu anstoßen, darum gibt es auch nicht den vom VIC-II bekannt FLI-Bug, sondern man kann die volle Breite des Bildschirms ausnutzen.
Der "Text-"Bildschirm, der die Bitmap addressiert, liegt bei $0400..$059F, die Bitmap geht von $0600..$1FFF.
Die globalen Farbregister (Hintergrund, Rahmenfarbe und Hilfsfarbe) werden ebenfalls in jeder Rasterzeile umgeschaltet, dazu stehen zwei 256 Byte große Tabellen bei $2D00..$2EFF im Speicher (nach $2000..$2CFF werden die gepackten Farb-RAM-Daten geladen). Die Farbspalten rechts im Beispielbild oben zeigen an, welche Farben für diese Rasterzeile gewählt wurden (die dienen praktisch als "Debug-Ausgabe" und werden am VC so nicht angezeigt - man sieht nur den Wechsel der Rahmenfarbe links und rechts).
Mit den etwas satteren Farben des VC20 und ihrer "natürlichen" Helligkeit kann man durch Mischen bestimmt einen größeren Farbraum abdecken als mit dem C64.
In etwa ja. Lediglich sehr starke Orange-Töne im Original tendieren dazu, im Konversions-Ergebnis "auszubluten".
Darf ich Dich bei gegebener Zeit mal löchern wegen der Grafikmodi?
Das ist eigentlich alles Multicolour-Textmodus. Was anderes kennt der VIC-I nicht.
Ich hab' aber mal eine recht ausführliche Liste in Denial veröffentlicht. Mit allen Display-Modi die programmtechnisch gesehen entweder auch so unproblematisch "ab Werk" gehen, oder für die mindestens entweder ein Konverter oder sogar ein Editor existiert: A round-up of all know VIC-I display modes
VG,
Michael
*) was ohne Umbau geht, sind 104x256 Pixel mit ansonsten gleichen Eigenschaften - also 1 Pixel hohe Attribute und Umschalten der 3 globalen Farben in jeder Rasterzeile. Zwei Beispiele dazu siehe hier. Dann bleibt aber 0% Rechenzeit übrig - die CPU ist voll damit beschäftigt, Farb-RAM-Daten herumzuschaufeln ... mit dem VFLI mod und 208x256 Pixeln läuft die CPU immerhin noch im oberen und unteren Rahmen.
Google Bildersuche rulez.
Jetzt weiß ich auch, dass die gute Frau kein Fieber hat. Anbei, wie das Foto eigentlich aussehen soll, und eine schnelle Umwandlung in NUFLI. Als MUIFLI ginge da noch einiges. Ich habe vor dem Konvertieren das Bild um ~16/15 in die Breite gestreckt, damit das Seitenverhältnis mit dem PAL-C64 exakt beibehalten wird.Danke für das Aufspüren des Originals! Hier mal zum Vergleich die Dame in 208x256 VFLI auf dem VC-20:
Das ist ja supergeil! Was sind das für Artefakte am rechten Bildschirmrand? Ist das so gewollt, oder ein Nebeneffekt? Schade, dass man einen Mod machen muss, aber ich bin immer wieder beeindruckt, was der VIC20 so alles kann.
208x256 Pixeln
Danke für die Erklärung.
Sind die Pixel bei Deinen Angaben immer gleich "groß"?
Im Startbildschrim sind das 176x184 Pixel, oder? Wird bei den anderen der Rahmen verwendet?
"The screen normally shows 22 columns and 23 rows of 8-by-8-pixel characters; it is possible to increase these dimensions up to 27 columns, but the characters would soon run out the sides of the monitor at about 25 columns."
https://en.wikipedia.org/wiki/Commodore_VIC-20
Wenn man für VFLI auf der Platine rumlöten muss, lass ich das lieber. Ich hatte das mit dem VFLI schonmal gelesen, aber wohl wieder verdrängt.
Gibt es denn viele User, die die Hardware deswegen umbauen?
mfg Tobias
Display More208x256 Pixeln
Danke für die Erklärung.
Sind die Pixel bei Deinen Angaben immer gleich "groß"?
Im Startbildschrim sind das 176x184 Pixel, oder? Wird bei den anderen der Rahmen verwendet?
Wenn man für VFLI auf der Platine rumlöten muss, lass ich das lieber. Ich hatte das mit dem VFLI schonmal gelesen, aber wohl wieder verdrängt.
Gibt es denn viele User, die die Hardware deswegen umbauen?
Da wurde doch neulich erwähnt, dass jemand an einem VIC Ersatz am Expansionport arbeitet. Vermutlich könnte man den dann mit VFLI Mod schon integriert auch bauen? Die Erklärung in Mike's Thread war doch, dass das Video RAM für den VIC auf der falschen Seite der Bus Buffer sitzt oder so. Wenn man den VIC jetzt aber am Expansion Port hängen hat, kann man doch vermutlich direkt auch das RAM dort reinwerfen...? Naja, ich habe keine Ahnung, aber wäre cool, wenn eine solche Erweiterung direkt alles auf einmal erledigen könnte.
Was sind das für Artefakte am rechten Bildschirmrand? Ist das so gewollt, oder ein Nebeneffekt?
Das ist die "Debug-"Ausgabe des Konverters, über die man entnehmen kann, welche Hintergrund-, Rahmen- und Hilfsfarbe für diese Rasterzeile ausgewählt wurden. In der echten Anzeige (egal ob auf dem VC oder in Emulation) sieht man das so nicht, nur die Änderung der Rahmenfarbe ganz knapp links und rechts neben dem Displayfeld ist erkennbar.
Sind die Pixel bei Deinen Angaben immer gleich "groß"?
Ja. Der VIC-I erzeugt immer gleich große Pixel.
Im Startbildschrim sind das 176x184 Pixel, oder? Wird bei den anderen der Rahmen verwendet?
Der Textbildschirm hat eine Pixelauflösung äquivalent zu 176x184. Die wäre nur äußerst unpraktisch als Hires-Auflösung, da man um eine Bitmap aufzuspannen sinnvollerweise die doppelt-hohen Zeichen (mit 8x16 Pixel Definition!) des VIC-I hernimmt und dadurch die vertikale Pixelanzahl durch 16 teilbar sein muß. 184 ist nicht durch 16 teilbar.
Die 208x256 Pixel des VFLI-Modus nehmen fast die komplett sichtbare Fläche der meisten Röhren ein. Auf meinem Sony PVM ist an allen Seiten nur noch ca. 2 mm Platz. Das Motiv hat nicht das 4:3 Seitenformat. Ich habe es nicht beschnitten, sondern stattdessen oben und unten schwarze Trauerbalken gesetzt und von den 256 Zeilen werden hier nur 182 benutzt.
Wenn man für VFLI auf der Platine rumlöten muss, lass ich das lieber.
Tja. Das geht nicht nur dir so.
Da wurde doch neulich erwähnt, dass jemand an einem VIC Ersatz am Expansionport arbeitet. [...]
Ich weiß zwar jetzt nicht welches Projekt Du da genau meinst, aber das wird dann ohne größeren Aufwand genauso kompatibel zu nicht-trivialen Anwendungen sein wie die 40/80-Zeichenkarten, die es so gibt. Nämlich ca. 0%.
In Denial gab es vor einiger Zeit mal unabhängig voneinander von zwei Bastlern den Vorschlag, die Schreibzugriffe der CPU auf das interne RAM mit der externen Cartridge mitzuschreiben und so einen Framebuffer auf der Cartridge zu aktualisieren. Da beim VC-20 der Adreßbus am Cartridge-Port aber nicht vollständig vorliegt (nur A0 bis A13), läuft das auf eine nahezu komplette Nachbildung der CPU außen hinaus, die mit Hilfe der Daten auf dem Datenbus den Befehlsstrom im Lock-Step mit ausführt und so die komplette Adresse rekonstruieren kann.
Damit das den VFLI-Modus nachbilden könnte, müßte man zusätzlich noch das Update der globalen Farbregister und der Farb-RAM-Bank mit synchronieren - dazu müßten die interne CPU, die externe CPU, einer der internen VIAs (die VFLI-Displayroutine macht einen 'Rasterinterrupt' mit einem VIA-Timer), der VIC-I Chip und der externe Videochip auf den Taktzyklus genau zusammengebracht werden. Ich erwähne hier nur, daß die beiden erwähnten Bastler noch nicht mal soweit gekommen waren um überhaupt auf diese Problematik zu stoßen.
Liest sich alles kompliziert, ist es auch, und ist aus meiner Sicht komplett mit Kanonen auf Spatzen geschossen. Der Umbau der Hauptplatine ist die technisch einfachste Lösung.
Wenn man den VIC jetzt aber am Expansion Port hängen hat,
Am Expansion-Port könnte man aber auch jeglichen anderen CRTC hinhängen, z.b. den 80Zeichen-VDC vom C128 oder auch gleich eine PC-EGA- oder gar VGA-Karte.
Letztere könnte man auch gleich als pseudostatische RAM-Erweiterung nutzen, die hat genug RAM für BILD und VC20 Max-Ausstattung
Und ist genausowenig kompatibel zu "normaler" VC20 Software wie die die VIC-Mods etc. auch...
Hab in meiner Lehrzeit Ende der 1980er mal mit sowas gespielt, da es die EGA-Karten mit min. 64 KB Speicher, manche auch "Super-EGA" mit bis zu 256KB damals quasi zum Nulltarif gab, jeder wollte VGA und damals wurden oft Gehäuse, Netzteil, Tastatur etc. weiterverwendet, natürlich auch die Bildschirme, aber speziell die EGA-Schirme waren nicht mehr sehr gefragt, da gab es auch viele aus Fernost, die nicht unbedingt qualitativ sehr hochwertig waren (aber natürlich auch andersrum welche, die weit mehr konnten als EGA, z.b. die ersten NEC-Multisyncs, Taxan, Eizo etc....)
Jedenfalls fielen neben CGA- und Herculeskarten auch ab und an EGA-Karten *) als "Elektroschrott" an und wurden natürlich dankbar "entsorgt" von uns in der Technik...
Und da gerade die VGA-Karte über ihren flexiblen Speicherausschnitt eigentlich schon perfekt geeignet ist fürs Banking in 8bit-Systemen, war die Idee sehr naheliegend. Hab erst vor Kurzem einen wirklich wilden Kabelverhau wieder gefunden mit dem ich mal eine 8bit-ISA-Karte an nem VC20 hängen hatte, am C64 verpfuschte einem ja der VIC2 das Bustiming, insofern war der VC20 da die deutlich bessere Wahl für Experimente...
*) Die hatten auch oft die 41464-Chips drauf, die man sowohl für die späten C64 als auch zum Aufrüsten der C(1)16 gut brauchen konnte... Wobei das waren reine "Auftrags"arbeiten, denn den C16 nahmen wir damals -als vom C64 kommend- nur als Teil des Untergangs von C= wahr, zudem liefen die überproportional oft mit Datasette, was ja nun für Disketten- und oft schon Festplattenverwöhnte "Techies" überhaupt nicht ging...
Gibt es eigentlich Adapter um PC ISA-Karten den 8-Bit-Commodore-Rechnern zugänglich zu machen?
256 Zeilen werden hier nur 182 benutzt.
Aber nur bei diesem Motiv, oder?
Darstellen kann man mit VFLI komplett ohne Letterbox ein Bild mit den vollen 208x256 Pixel, richtig?
Und ist genausowenig kompatibel zu "normaler" VC20 Software wie die die VIC-Mods etc. auch...
Moment! Um das mal klarzustellen, auf meinem mit VFLI mod versehenen VC-20 läuft auch noch nahezu alles an Software, was es für den VC-20 gibt!
Ich habe mir nicht mal die Mühe gemacht, einen Umschalter einzubauen. Die zusätzlichen +3K lassen sich problemlos per Software wegblenden, wenn ein Programm mal explizit die Speichergrenzen des original nicht-erweiterten VC-20 braucht. Steckkarten sind ebenfalls nicht betroffen, da auch mit +3K der Bildschirm immer noch an der gleichen Stelle ist.
Software, die den Userport benutzt, ist bei meiner Variante zunächst außen vor, da vier Bits von VIA #1 Port B zur Ansteuerung der Farb-RAM-Bank genutzt werden. Da muß man halt wissen, was einem lieber ist. Den Userport dafür herzunehmen war jedenfalls einfacher, als noch einen weiteren Chip mit lesbarem Portregister ins Adreß-Dekoding einzuhängen.
...
Demgegenüber wird jede Software bei einem externen Videochip die Grätsche machen, sobald sie Direktzugriffe auf den normalen Bildschirmspeicher des VIC-I macht. Gleiches gilt für die Cartridge-Firmware, wenn ihr von einem Programm die KERNAL-Vektoren zur Behandlung von CHRIN und CHROUT weggenommen werden. In der Praxis braucht es also nur einen Fingerschnipp, und die tolle 40/80-Zeichenkarte macht - nichts mehr.
Aber nur bei diesem Motiv, oder?
Darstellen kann man mit VFLI komplett ohne Letterbox ein Bild mit den vollen 208x256 Pixel, richtig?
Ja. Sonst hätte ich mir nicht vorher schon die Mühe gemacht, das mit den Trauerbalken noch extra zu erklären.
Die komplette Displaygröße von VFLI ist 208x256 Pixel. Hier mal ein anderes Bild als Beispiel, diesmal nicht als Konverter-Preview, sondern in echt von meinem umgebauten VC-20 mit Sony PVM Röhre:
also, das Bild war jedenfalls vertikal beschnitten auf 160px bzw. 80 doppelt hohe px
Nach Möglichkeit nimmt man die Originalquelle her und ich hab mich eben dazu entschieden, für die Konversion nach VFLI nicht links und rechts abzuschneiden, sondern oben und unten um die schwarzen Trauerbalken zu ergänzen. Mit 182 von 256 maximal möglichen Pixeln war die verbleibende vertikale Auflösung ausreichend genug.
Display MoreUnd ist genausowenig kompatibel zu "normaler" VC20 Software wie die die VIC-Mods etc. auch...
Moment! Um das mal klarzustellen, auf meinem mit VFLI mod versehenen VC-20 läuft auch noch nahezu alles an Software, was es für den VC-20 gibt!
Ich habe mir nicht mal die Mühe gemacht, einen Umschalter einzubauen. Die zusätzlichen +3K lassen sich problemlos per Software wegblenden, wenn ein Programm mal explizit die Speichergrenzen des original nicht-erweiterten VC-20 braucht. Steckkarten sind ebenfalls nicht betroffen, da auch mit +3K der Bildschirm immer noch an der gleichen Stelle ist.
Software, die den Userport benutzt, ist bei meiner Variante zunächst außen vor, da vier Bits von VIA #1 Port B zur Ansteuerung der Farb-RAM-Bank genutzt werden. Da muß man halt wissen, was einem lieber ist. Den Userport dafür herzunehmen war jedenfalls einfacher, als noch einen weiteren Chip mit lesbarem Portregister ins Adreß-Dekoding einzuhängen.
...
Demgegenüber wird jede Software bei einem externen Videochip die Grätsche machen, sobald sie Direktzugriffe auf den normalen Bildschirmspeicher des VIC-I macht. Gleiches gilt für die Cartridge-Firmware, wenn ihr von einem Programm die KERNAL-Vektoren zur Behandlung von CHRIN und CHROUT weggenommen werden. In der Praxis braucht es also nur einen Fingerschnipp, und die tolle 40/80-Zeichenkarte macht - nichts mehr.
Es ging mir rein um die Nutzung der neuen "erweiterten" Modi, da muss ein Programm doch auch explizit wissen, dass der Mod vorhanden ist, oder?
Zudem: Userport halte ich immer für kritisch, da daran sehr oft Parallel-Drucker, oft RS232 (Modem), manchmal Floppy-speeder oder auch Eprommer hängen, sprich eigentlich fast immer irgendetwas! Das Alles lahm zu legen ist daher in meinen Augen nicht das Optimum.
Eine über den EXP angebundene VGA würde -wenn man es intelligent genug angeht *)- sich aus Sicht es VC20 IMMER wie eine 32k Extension verhalten, die man ja beliebig (blockweise)abschaltbar machen kann.
Von dem, was die VGA Karte aus diesem RAM heraus darstellen kann, müsste natürlich die Anwendung dann wissen und auch die Speicherende-Vektoren des Basic gegebenenfalls neu setzen, um ein Überschreiben durch Variablen zu vermeiden. Wäre also klassische 2-Schirmbetrieb, der VIC bleibt ja ansprechbar und sein Bildschirmspeicher auch zunächst der primäre. Kann man natürlich (z.b. für ne CBM-Textverarbeitung mit 80Z-Betrieb) auch im System ändern *), aber dann muss man eben aufpassen, dass die Vektoren nicht wieder zurückgestellt werden oder weiter verändert werden...
Die Register der VGA-Karte würden sich in einem der I/O-Bereiche befinden, könnten aber auch versteckt "unter" dem ROM liegen (es wird ja hauptsächlich -bei EGA sogar ausschliesslich!- da rein geschrieben). Unter dem ROM natürlich nur dann, wenn A14 und A15 am EXP nachverdrahtet sind, aber dieser MOD ist ja eigenltlich Allen, die sich mit der Materie etwas beschäftigt haben bestens bekannt und hat auch keine negativen Auswirkungen, es sei denn, man hat Module, die das NC falsch interpretieren, dann müsste man diese Module (mir ist jetzt keins bekannt!) eben auch modifizieren, sprich notfalls den Kontakt von der PCB abziehen oder die abgehende Leiterbahn unterbrechen...
*)A0 der VGA sollte geschickterweise mit einer höheren Adressleitung, ab A11 getauscht werden, denn VGA hat immer -aus 8bit-Sicht- hintereinander Char-Vektor und Farb-/Attributspeicher liegen. Das beißt sich natürlich mit der Art, wie der Kernal damit umgeht... Aus reiner Speicherkarten-"sicht" ist die Vertauschung beliebig, solange man in diese Adressleitung nicht via Auswahllogik eingreift...
Es ging mir rein um die Nutzung der neuen "erweiterten" Modi, da muss ein Programm doch auch explizit wissen, dass der Mod vorhanden ist, oder?
Der Display-Treiber ist im Source verfügbar und wenn der Modus eingeschaltet ist, kann die Grafik über die Bitmap bei $0600 bis $1FFF und die 16 Bänke im Farb-RAM so angesprochen werden, wie irgendein Programm es für sinnvoll hält.
Als Anwendung gibt es im Moment derzeit den Picture-Viewer; irgendwelche Linienzieh-Routinen, etc. sind ein Klacks - das muß ich nicht unbedingt auch noch frei Haus anliefern. Für die Bitmap am C64 kriegen die Leutz sowas ja auch hin.
Ohne VFLI mod kann man den Display-Treiber auch starten, dann gibt's eben nur Murks auf dem Bildschirm. Man kann tatsächlich testen, ob das RAM bei $0400 bis $0FFF so verbaut ist, daß es der VIC-I lesen kann - der Test beruht aber auf Zugriffen auf offenen Speicher und nutzt parasitäre Kapazitäten der Datenbus-Leitungen auf dem Mainboard. Daß das immer 100% klappt, kann man nicht garantieren.
Userport halte ich immer für kritisch, da daran sehr oft Parallel-Drucker, oft RS232 (Modem), manchmal Floppy-speeder oder auch Eprommer hängen, sprich eigentlich fast immer irgendetwas!
... und bei mir eben die oberen vier Adreßleitungen des Farb-RAMs vom VFLI mod! Dafür ist es ein Userport!
Wie ich schon geschrieben habe, das war einfacher, als noch einen weiteren Port-IC mit zusätzlicher Adreßlogik reinzuhängen. Es steht jedem frei, den zusätzlichen Aufwand zu betreiben, der Display-Treiber ist in 5 Minuten angepaßt.
Noch in Bezug auf andere Nutzung des Userports lehne ich mich mal soweit aus dem Fenster: einen Parallel-Drucker hat man damals(TM) vielleicht mal dran gehängt, mir ist kein Parallel-Speeder für den VC-20 bekannt, ein EPROM-mer am VC-20 ist eher was für noch nerdigere Bastler als der VFLI mod es abverlangt, und RS-232 kam erst in den letzten paar Jahren mit den WiModems wieder in meinen Fokus, da war der VFLI mod aber schon lange in Betrieb. Wenn ich nicht an meiner Mega-Cart ohnehin einen Reset-Taster hätte, wäre ein Reset-Taster die einzige andere Nutzung die mir so in den Sinn käme.
Noch zur Nutzung eines externen Videochips, evtl. mit Firmware:
muss man eben aufpassen, dass die Vektoren nicht wieder zurückgestellt werden oder weiter verändert werden...
Das hast Du gar nicht mehr unter Kontrolle wenn irgendein Programm läuft. Wie gesagt, das macht einmal schnipp und dann tut sich auf der Grafikkarten-Ausgabe nichts mehr. Alles jenseits von KERNAL-konformer Textein- und -ausgabe ist da zum Scheitern verurteilt.
Unter dem ROM natürlich nur dann, wenn A14 und A15 am EXP nachverdrahtet sind, aber dieser MOD ist ja eigenltlich Allen, die sich mit der Materie etwas beschäftigt haben bestens bekannt und hat auch keine negativen Auswirkungen, es sei denn, man hat Module, die das NC falsch interpretieren [...]
"Unter dem ROM" geht beim VC-20 rein nur per Expansionport grad mal gar nichts, auch dann nicht wenn man die beiden NC Leitungen mit A14 und A15 belegt. Es gibt keine Möglichkeit, das KERNAL- oder BASIC-ROM von außen stillzulegen, außer man "überschreibt" grob den Adreßbus mit stärkeren Treibern und das ist schaltungstechnisch Ober-Pfusch! Davon ab ist beim VC-20 CR der Y Pin mit Audio In bereits vorbelegt.
Insgesamt ist eine Änderung des Expansionsport-Pinouts eine erheblich wildere Bastelei als mein VFLI mod, der sich sauber einfügt und korrekterweise RAMx am Expansionport stilllegt, damit externe Cartridges da nicht mehr reinreden können (nur so als Hinweis: die ansonsten offenen Eingänge des LS133 die dann noch am Ex.Port hängen liegen so bei 2,4 V und damit für CMOS-Inputs als Chip-Select genau im undefinierten Bereich. Darum gehören die mit 4,7 K hochgelegt!)
"Unter dem ROM" geht beim VC-20 rein nur per Expansionport grad mal gar nichts,
Wieso???
Kann ein ROM durch pures Schreiben auf eine seiner Adressen verändert werden?
NEIN!
Also kann für reine Schreibzugriffe durchaus etwas Anderes, wie eben ein Video-Chip parallel dazu selektiert sein. Nur Rücklesen geht auf diese Weise nicht, ist aber auch nur in Ausnahmefällen (Light Pen, Power-Save modes, extremes Multitasking, also alles WEIT jenseits dessen, was man damit am VC20 wohl so treiben könnte) notwendig.
Thema Rückstellung von div. Vektoren:
Dagegen kann man ja Maßnahmen ergreifen, wie z.b. diese Vektoren mittels NMI wieder auf die sinnvolle Einstellung umzustellen, wenige Programme dürften die Vektoren "zyklisch" verbiegen, d.h. nach Programmstart einmal Run/Stop & Restore und gut ists. (zur Not im eigenen Kernal, damit dieser Vektor nicht auch noch verbogen werden kann...)
Eprommer am VC20 hab ich eigentlich immer als Grundausstattung gesehen, hatte ich lange vor der ersten Floppy! Aufwand ist minimal (auch damals!) Ein Steuerprogramm selbst in Basic erstellbar (brennen dauert dann eben etwas länger...), alles kein Hexenwerk...
Paralleldrucker ist gerade "heute" interessant, da es doch einige gebrauchte aber gute und bewährte Laserdrucker (wie die HPs ab LJII/III ...) gibt, die Epson oder IBM-Proprinter emulieren können, aber eben meist zur ne parallele Schnittstelle haben. Wiesemann & Co. IEC-Interfaces hatten meist nur sehr zu wenige Konfigurationsoptionen, besser geht das über den Userport. Ein VC20 mit 40/80-Zeichenkarte (und eventuell IEEE488) kann viele CBM 30x/40x/8xxx Programme "out of the box" ausführen, darunter auch die wirklich professionellen Programme fürs Büro von damals...
Das Audio-IN auf dem Y-Pin des CR äussert sich, wenn man es nicht abklemmt in Störgeräuschen, aber bringt den Rechner nicht zum Abschmieren und beschädigt auch nix. Merkt man also schnell ;-/
Und dieser "Mod" ist seit min. 1982 bekannt, wurde u.a. in div. Zeitschriften veröffentlicht und war wohl bei den Modulbox"Usern" einer VC1020 / VIC1010 auch "en vogue", zumindest hatten sämtliche Modulboxen samt VC20, die ich bislang in Händen halten durfte alle diesen Mod!
Aber bitte nicht falsch verstehen: meine Ausage richtete sich NICHT GEGEN Dich oder Deinen mod, sondern gegen eine externe Erweiterung mit nochmals VIC-I oder ähnlich, denn darin sehe ich heute keinen wirklichen Sinn mehr, auch nicht darin, den VIC aus dem Gerät in ein Modul zu verfrachten, denn 99,99% der Software für den VC-20 wurde VOR 1990 geschrieben, kann also nix von diesen Mods wissen und ich weiß nicht, ob die Pics in Zeiten von 4k HDR noch Jemand vom Hocker reißen und eine zu (nahezu) 100% beschäftigte CPU ist für Spiele oder "Anwendungen" auch nicht so der Bringer...
Daher die frevlerische Aussage: wenn ich schon was ändere und dabei Geld in die Hand nehme (und mich vom damaligen WERKS-Standard entferne), dann kann da heute auch gleich was "Vernünftiges" verbauen und das fängt für meinen persönlichen Geschmack bei ungefähr SVGA an.
Oder: Es gibt ja sogar Anleitungen im WWW, wie man aus nem ATMEGA oder ähnlichen kleinen Controllern nen serielles Terminal mit Auflösung und Farbanzahlen machen kann, die weit über dem liegen, was der VIC so konnte, d.h. könnte man auch da 10 EUR für die HW in die Hand nehmen, ein paar Zeilen Code im Atmel ändern und nen Latch a la LS373 etc. an den EXP hängen (anstatt der lahmen seriellen) und dafür dann nen passenden Kernal auf CBM-Seite basteln...
Software, die den Userport benutzt, ist bei meiner Variante zunächst außen vor, da vier Bits von VIA #1 Port B zur Ansteuerung der Farb-RAM-Bank genutzt werden. Da muß man halt wissen, was einem lieber ist. Den Userport dafür herzunehmen war jedenfalls einfacher, als noch einen weiteren Chip mit lesbarem Portregister ins Adreß-Dekoding einzuhängen.
ich bin auch schon seit Jahren geneigt, mir das mal nachzubauen. Passende SRAMs liegen schon lange hier.
Der Userport-Konflikt gefällt mir auch nicht so richtig gut. Ich habe jetzt für mich entschieden, dass ein zusätzliches Portregister an der gleichen, oder sogar einer anderen Stelle viel zu viel Aufwand wäre. Es tut auch z.B. ein 74LS244 in die vier Portleitungen eingeschleift, um dann per Hardwareschalter das RAM vom Userport abzukoppeln. Es wären sogar noch vier separat schaltbare Leitungen frei für andere Modifikationen an den restlichen Portbits
Gibt's noch Bilder von den nötigen Umbauten für den VFLI-Modus?
Im anderen Forum sehe ich die Bilder zumindest nicht, falls es sie dort noch gibt:
http://sleepingelephant.com/ip…n/bb/viewtopic.php?t=4882
Ist das hier auch VFLI?
http://sleepingelephant.com/ip…n/bb/viewtopic.php?t=5140
https://www.commodore-news.com/news/item/1569/de/desktop
Laut Text sind es Bilder mit 104*256 Pixel, also wie Du hier beschreibst:
*) was ohne Umbau geht, sind 104x256 Pixel mit ansonsten gleichen Eigenschaften - also 1 Pixel hohe Attribute und Umschalten der 3 globalen Farben in jeder Rasterzeile. Zwei Beispiele dazu siehe hier.
Die beiden Beispiele füllen nur den halben Bildschirm, beim Link oben sieht es nach Vollformat aus.
Danke und Gruß,
Tobias
Mit dem VC20 und den Sondermodi muss ich mich auch mal auseinandersetzen. Hab ja so ein Ding her wegen der Palettensache. Für den Modus brauche ich aber mehr RAM, oder?
Das mit dem RAM hat mich bisher davon angehalten, viel mit dem Teil zu machen. Jedes Programm will da gefühlt nen anderen RAM-Ausbau.
den Umbau hätte ich nicht durchführen wollen, aber ich habe den VFLI-Modus in Sidekick20-HDMI-Ausgabe implementiert -- alle möglichen RAM-Erweiterungen sind auch dabei, damit kann man mit einem (fast *) unmodifizierten VC20 die VFLI-Demos anschauen... (Release kommt bald)
* ein Signal muss man für eine VIC-Emulation abgreifen und zum Expansionsport führen
edit: jetzt sehe ich es erst im Post von root42 -- ja das ist der "VIC am Expansionsport"
Mike war mir nicht bewusst, dass der "VFLI-Mike" hier ist 
-- unterstützen Vice oder andere Emulatoren eigentlich inzwischen den NTSC-Interlace-Modus?
