Weer even een nieuw topic omdat ik al een paar weken onder de radar aan het werken ben aan een Intellivision RGB mod.
Als intro:
De Intellivision is helaas standaard alleen in staat om RF uit te sturen. Als je echter wat beter kijkt dan vind je dat er gebruik gemaakt wordt van een LM1886N DAC. Dit IC gebruikt de 3bit digitale rgb kleuren die de Intellivision aan maakt. Het is dus theoretisch mogelijk om met een modern digitaal naar analoog IC een RGB beeldje te krijgen. Ik heb daarvoor de adv7125 gebruikt. Een 8bit rgb DAC... beetje overkill, maar wel erg goed! Ik heb een test pcb ontworpen en krijg een zeer mooi rgb beeldje.
Het vervelende is dat niet iedere Intellivision deze LM1886N aan boord heeft. Met andere woorden... deze rgb mod werkt alleen op een beperkt aantal consoles. Dat moet beter kunnen.
Ik ben er wat dieper in gedoken. Voor de geïnteresseerden... Dit wordt waarschijnlijk een technisch verhaaltje over adres bussen, PROM's, kleuren, bits, digitale video signalen, oscilloscopen, clocks, PLD's, VHDL en meer. Kort gezegd... Ik probeer een Intellivision rgb mod te maken die universeel te gebruiken is (in ieder geval op alle PAL machines). Als alles uiteindelijk werkt zoals ik het voor me zie dan heb ik direct 1 printplaatje wat vast gesoldeerd wordt aan de onderkant van het moederboard van de Intellivision.
Inmiddels zit ik er zover in dat ik een diagnostische cartridge besteld heb om de kleuren te kunnen decoderen. Ik ben al een heel eind en start zodra ik kan aan wat VHDL code om een nieuwe kleuren decoder te maken.
Ik neem diegenen die het leuk vinden hier graag in mee de komende weken/maanden.
Happy gaming! :-)
-----------------------------UPDATE-------------------------------
Voor de mensen die nog iets meer willen weten...
Hieronder even een simpele schematische weergave van hoe de (europese) Intellivisions werken. Althans... sommige...
Het handige is dus het stukje aan de rechterkant. Dit is de DAC. DAC staat voor digital-analog-converter. Oftwel een chip die het digitale signaal om zet naar een analoog signaal wat een oude beeldbuis tv "begrijpt". Het probleem is dat deze DAC in de intellivision het digitale kleuren signaal omzet naar RF. RF kennen we allemaal als de "kabel aansluiting" op consoles waarbij je de goede frequentie moest opzoeken om beeld te krijgen. Een gruwelijk slecht signaal, zeker in deze tijden van LED en OLED tv's.
Het punt is dat we graag analoge rgb video signalen naar onze scart connectoren willen sturen voor de beste analoge beeldkwaliteit. Wat kunnen we doen? Juist! De digitale rgb signalen "aftappen" en die naar een nieuwe DAC sturen die wel netjes analoog rgb uit stuurt. Dat lukt dus prima met een van de modernere chips die op de markt zijn. Probleem opgelost zou je zeggen.
Helaasch...
Er zijn blijkbaar ook Europese Intellivisions die op een andere manier werken en die geen enkele manier hebben om de digitale rgb signalen af te tappen. Dan is er dus een probleem. De amerikaanse console hebben hetzelfde probleem. Nergens in de console is er een digitaal rgb signaal te bekennen dat af te tappen valt.
Hoe werkt dit dan verder binnen in?
Alles is in de Intellivision terug te leiden naar de STIC. STIC staat voor Standard Television Interface Chip. de STIC is verantwoordelijk voor het maken van een 4 bits code die het beeld vertegenwoordigt. Met 4 bits (een bit kan 1 of 0 zijn) kun je 16 kleuren maken. Hoe kom je daar aan? 2^4 = 16. Dus... 16 mogelijke kleuren in de Intellivision. Waarom staan er dan in het plaatje hierboven 5 lijntjes vanaf de STIC? Dat komt omdat het 5e signaal voor het sync signaal zorgt. (kort door de bocht het synchronisatie signaal waardoor alle pixels goed op het scherm verschijnen. Zonder sync signaal geen beeld!)
Nu... V1, V2, V3, V4 en V5 geven dus een "code" met enen en nullen die naar een stukje ROM geheugen gestuurd wordt. Het ROM geheugen vertaalt dit naar een digitaal rgb signaal. Dat betekent dus dat de kleuren signalen "gecodeerd" uit de STIC komen en door het stukje kleuren ROM "gedecodeerd" worden. Als je dus dit kleuren signaal kunt decoderen en vervolgens kunt omzetten naar analoog (dat gedeelte heb ik al onder de knie) dan betekent dit dat een mod mogelijk is waarbij je niet het digitale rgb signaal af tapt, maar het gecodeerde signaal van de STIC zelf. En die zit in iedere versie van de Intellivision. Ik gok er op dat IEDERE pal Intellivision zal werken met deze mod, en ik zou eigenlijk wel eens willen weten wat NTSC consoles er mee doen... Ik denk dat er weinig nodig is om deze er ook mee te laten werken.
Waarom is er dan nog geen degelijke rgb mod voor de Intellivision?
Laten we wel zijn... de meeste die-hard modders voor dit soort spul komen uit Amerika. Maar als het op de Intellivision aan komt hebben de Amerikanen een achterstand. In geen enkele NTSC Intellivision zijn er digitale rgb signalen aanwezig. Dat betekent dat met een Amerikaanse console het nagenoeg onmogelijk is om de STIC kleuren te decoderen. Zij hebben immers geen toegang tot de digitale rgb signalen in de console. Wij als europeanen wel. Ik vermoed ook dat dit de reden is dat er wel Amerikaanse mods bestaan, maar dat men daar altijd rommelt met de kleuren van de console. Men gaat af op wat men ziet op de tv en programmeert deze in een mod. Vaak zijn er verschillende kleuren palletten te gebruiken, maar geen enkele is precies.
Tot zover deze update. Waar ik momenteel op wacht is PLD (Programmable Logical Device) IC's waarin ik de code kan zetten om de kleuren te decoderen en een diagnostische cartridge voor de Intellivision (deze gebruik ik om achter het digitale rgb signaal te komen). In de volgende update zal ik wat meer laten zien over hoe de kleuren in elkaar steken, welke bit codes de kleuren hebben, hoe ik de kleuren decodeer met een oscilloscoop en hoe ik de IC's wil programmeren.
Happy gaming! :-)
-----------------------------UPDATE-------------------------------
Zoals beloofd een update waarin we even wat beter gaan kijken naar de kleuren.
Ik begin even met de STIC. In de vorige update hebben we gevonden dat de STIC alle kleuren gecodeerd verstuurd. Kunnen we dan niet achter de codes van die kleuren komen? Jazeker wel! Het Internet geeft in de datasheets de volgende tabel:
Wat hierin interessant is, zijn de waarden die horizontaal voor V1, V2, V3, V4 en V5 staan. Dit zijn bits, dus enen en nullen. Zo is er bijvoorbeeld te zien dat bij de "kleur" zwart alle data lijnen een 0 weergeven. (logisch, want zwart betekent geen kleur, dus geen signalen.) De oplettende kijker ziet dat V5 pas helemaal onder in de tabel relevant wordt. Bij alle kleuren staat V5 op nul. Dit betekent dus al dat V5 totaal geen rol speelt in wat de kleuren precies doen. V5 zorgt voor het blanking en sync signaal. Beide signalen hebben we nodig om een beeld te maken.
Even terug naar de kleuren. Want hoe kunnen we nu verifiëren dat deze tabel ook klopt voor onze Europese Intellivision? Dit is het moment waarop de oscilloscoop komt kijken. Hier is nog een keer het plaatje waar we mee begonnen.
Ik heb de vier signalen die voor een kleur zorgen eventjes gearceerd. Als we op deze plaatsen de oscilloscoop aansluiten kunnen we de signalen bekijken. Superhandig! Echter is er 1 probleem. Tijdens het spelen van games zullen de pixels steeds op een andere plaats getekend worden (logisch... het beeld beweegt), dus om zaken goed te analyseren hebben we een statisch beeld nodig. Laat nu toevallig elke Intellivision game een intro scherm hebben met in ieder geval de helft van alle kleuren er al op! Kijk maar naar bijvoorbeeld Astrosmash. Hieronder ze je de 8 kleuren waar ik het over heb.
We gaan dus eens kijken naar een lijn met pixels op de oscilloscoop en hoe dan de code eruit ziet. Ik heb even een screenshot gemaakt van wat je dan op de scope te zien krijgt. Van links naar rechts hebben we een lijn met bits die achtereenvolgens V1, V2, V3 en V4 voorstellen. Als je dan van boven naar beneden de bits leest krijg je een kleurcode van 4 bits. Ik neem bijvoorbeeld even de 4e verticale lijn met bits. Dit is V1 = 0, V2 = 0, V3 = 1, V4 = 0. Ga je dan kijken welke kleur er overeenkomt met deze code in de kleurentabel uit de datasheet dan zien we dat dit "grass green" is. Kijken we in het opstart scherm van Astrosmash dan blijkt deze 4e kleur inderdaad groen te zijn. Of het daadwerkelijk "grass" green is valt over te discussiëren, maar zo hebben ze het genoemd. Alle 8 kleuren zijn op deze manier te achterhalen.
De oplettende kijker ziet wellicht steeds "tussen de kleuren door" van boven naar beneden de binaire code 1101 terug komen. Dit is natuurlijk de achtergrond kleur. Volgens de tabel is 1101 brown. In ons scherm is dit groen! Dit is een bekend fenomeen en op verschillende fora zijn er discussies te vinden over het waarom hiervan. Mogelijk een last minute design wijziging van Mattel. In ieder geval niets bijzonders en geheel volgens verwachting :-)
Helaas is het zo dat de andere 8 kleuren moeilijker zijn. Deze zitten niet in het statische beeld van het introscherm. Dit is de reden dat ik een diagnostische cartridge gekocht heb. Deze cartridge test de console en laat zodoende ook een statisch scherm met alle 16 mogelijke kleuren zien. Zodra ik deze heb kan ik alle kleuren die uit de STIC komen verifiëren met de datasheet waarden zodat ik er absoluut zeker van ben dat dit voor mijn Europese console klopt.
In de volgende update neem ik jullie mee hoe we deze 4 bits kleuren code van de STIC decoderen naar een digitaal 3-bit rgb signaal.
- Spoiler: weergeven
Alright... Tijd voor een update. En een goeie ook!
We zijn geëindigd met de kleuren code van de STIC en we weten al dat de STIC een 4 bit signaal naar de kleuren ROMS toestuurt. Volgens het kleuren kaartje in een vorige update kennen we ook alle mogelijke kleuren combinaties met bijbehorende 4 bit code uit de STIC. Dat is mooi! We kunnen dus al deels in kaart brengen hoe de kleuren ROMS werken, want de input kant kennen we dus al. Tijd om te kijken naar wat die kleuren ROMs eigenlijk uitpoepen, want als we dat kunnen achterhalen dan weten we de input en output van deze stukjes geheugen en kunnen we beginnen met wat Boolse wiskunde.
Volgens dit plaatje lopen er per kleur drie lijntjes naar buiten. digitale rgb lijntjes wel te verstaan.
Als we nu op het openingsscherm gaan kijken op de testcartridge dan zien we dat dit scherm onder andere alle kleuren laat zien.
Dit betekent dat als we weten op de oscilloscoop waar we moeten kijken, we de datalijntjes r0, r1, r2, b0, b1, b2 en g0, g1 en g2 kunnen gaan besnuffelen. We kunnen dan precies achterhalen wat elke datalijn doet voor elke kleur. (btw... ik heb hier geen opleiding voor gevolgd. Met boerenverstand en wat simpele truukjes op een scope kom je een heel eind!)
Hieronder zal ik een plaatje posten van hoe de beeldlijnen van de msb's (Most Significant Bits) van iedere kleur eruit zien. Tevens heb ik het sync signaal toe gevoegd. We kijken hier naar een representatie in bits van 1 lijn met pixels. dus van links naar rechts zijn dit de bits die het geheugen uitspuugt voor alle kleuren op de b2, g2 en r2 lijn. Als we nu de probes van de oscilloscoop verplaatsen naar b1, g1 en r1 kunnen we deze ook besnuffelen. Tevens doen we dit voor b0, g0 en r0. Dan is het plaatje compleet! We kunnen dan alles in een excel bestand plaatsen en de tabel afmaken. Een deel van de tabel post ik hieronder ook.
Op deze manier heb ik dus de input en de output van de stukjes kleuren ROM bepaald. Als je het complete plaatje hebt (wat ik nog even niet openbaar ga maken) dan kun je hiermee de logische wiskunde achterhalen om te bepalen wanneer er een bit naar elke datalijn verstuurd moet worden. We nemen bijvoorbeeld in het plaatje hierboven even het blauwe kanaal. En dan specifiek de LSB van blauw (onder de L)
Ik zie dat deze datalijn een "1" moet geven in twee situaties. Namelijk bij (v4=0 & v3=0 & v2=0 & v1=1) of bij (v4=0 & v3=0 & v2=1 & v1=1). als het geheugen deze bitcodes door krijgt van de STIC moet het geheugen een 1 uitsturen om de lsb van blauw. In mijn complete tabel zijn er 8 situaties waarin lsb blauw (ik noem hem "b0") een 1 moet uitsturen. Op deze manier maak je dus een lange logische specificatie voor hoe b0 zich dient te gedragen ten gevolge van een bepaalde input bitcode.
Dit doe ik voor alle uitgestuurde signalen.
Via het programma winCUPL is het bijna kinderlijk eenvoudig om eproms te programmeren. Hieronder een linkje hoe dat er uit ziet. Je geeft dus aan welk soort IC je gebruikt, en zet er vervolgens in welke poot welke input is. Het zelfde doe je voor de output pootjes. Daarna volgen de logische vergelijkingen. Ik heb er eentje hieronder laten staan., die van b0. Deze heb ik sterk vereenvoudigd. (Het is mogelijk Boolse algebra te vereenvoudigen, zoals je met normale algebra ook kunt. Anders worden de formules zo langdradig...) WinCUPL gebruikt voor "is nul" het uitroepteken. Het "en" symbol is &, het "of" symbool is #.
Vervolgens heb ik de gecompileerde jedec bestanden met een eprom brander in 2 eprommetjes gebrand. Ik heb twee atf16v8a's gebruikt. Deze eproms gebruik ik tevens om het sync signaal en het blanking signaal aan te maken. Dit alles wordt doorgestuurd naar een digitaal naar analoog convertor met bijbehorende standaard schakeling. Ik gebruik hiervoor een adv7125 van Analog Devices. Dit ding werkt op de kloksnelheid van de intellivision, dus voor PAL 4Mhz. Ook de clock valt prima af te tappen van de STIC. Alles bij elkaar is dit het prototype.
En dat geeft deze ouput.
Prima dus en alle kleuren kloppen!
Nu... dit alles heb ik gedaan omdat ik de wens had een klein pcb te maken wat gemakkelijk op de intellivision vast te solderen valt. Ik wil het zo doen dat dit precies tussen de pootjes van de STIC (DIP 40 package) past op de onderkant van het moederboard (wat op de Intellivision gek genoeg naar boven wijst haha.) Daarvoor is dit het uiteindelijke resultaat, ontworpen in Eagle. Deze printplaat heb ik inmiddels besteld en ik hoop binnen een week of twee met een update te komen waarin hij geïnstalleerd is :-)
-----------------------------UPDATE 26-5-2022-------------------------------
Inmiddels zijn we bijna een jaar verder... dit project heeft een tijdje in de kast gelegen en is inmiddels een hele andere kant op gegaan!
Ik ben gestopt bij de 2 geprogrammeerde EPROM chips die de kleurentabel van de Intellivision bevatten. Allemaal leuk en aardig, maar het sync signaal wat de Intv standaard aanmaakt (en wat dus mijn EPROM chips netjes namaken) is niet volgens standaard televisie specificaties. Dit betekent dat mijn Framemeister het signaal we slikt, maar een heleboel andere scalers niet. Sterker nog... de meeste CRT tv's hebben er ook moeite mee en laten geen beeld zien.
Even heel kort iets over een sync signaal. De consoles die wij zo graag gebruiken en op een rgb scart poort willen aansluiten genereren een synchronisatie signaal. Dit signaal geeft aan waar de tv wel en geen data (pixels) kan projecteren. Een beeldbuis tekent lijnen van links naar rechts, beginnend boven aan het beeld. Als alle beeld lijnen getekend zijn schuift de elektronen straal terug naar linksboven en begint de opbouw van het volgende beeld.
Het sync signaal geeft aan waar er nieuwe lijnen beginnen en eindigen, en waar de laatste lijn getekend is zodat er een nieuw beeld start. We praten dan over Hsync (horizontale sync) en Vsync (verticale sync). Hsync zijn korte pulsen, Vsync is een langere puls. In de tijd van Hsync beweegt de elektronen straal terug naar links om de volgende lijn te starten. In de tijd van Vsync beweegt de elektronenstraal naar linksboven om het volgende beeld te beginnen.
Sync is dus in feite twee signalen. Wat we doen is deze signalen samenvoegen tot iets wat we Csync noemen. Hsync en Vsync samen vormen dus Csync.
Hieronder een plaatje (van HD retrovision) hoe een Hsync en Vsync eruit zien op een oscilloscoop:
Hierin wordt dus bij elk getal een beeldlijn getekend, en als de grote puls van Vsync bereikt wordt gaat de elektronen straal terug naar links boven voor het volgende beeld.
Waarom nu dit verhaal?
De correcte manier om deze twee signalen samen te voegen levert onderstaan plaatje op:
De Intellivision maakt zelf dit signaal aan:
Hier is iets mis mee. Er missen een aantal korte Hsync pulsen voor de langere Vsync puls als we beide plaatjes met elkaar vergelijken (deze specifieke pulsen heten in het Engels equalization pulses. Die zijn belangrijk!!) Verder zijn er bij de Intellivision geen Hsync pulsen tijdens Vsync. (In het Engels noemen we deze drie pulsen serration pulses. Ook deze spelen een rol bij een Csync signaal). Met andere woorden... Na al deze moeite komen we tot de conclusie dat de Intellivision zelf een verkeerd Csync signaal aan maakt waardoor dus apparaten als de OSSC of de verschillende RetroTinks hier niet op kunnen "locken". Dit is de reden dat veel mensen met RGB mods voor een Intellivision problemen ervaren.
Maar... Wat kunnen we doen? In feite hebben we een aantal opties die we eigenlijk alleen kunnen toepassen met een fpga. Een fpga is een Field Programmable Gate Array. Eigenlijk niets anders dan een programmeerbare groep met logische schakelingen. Een fpga laat het bijvoorbeeld toe om een compleet eigen sync signaal te creëren. Dit kan helemaal opnieuw, of we kunnen het bestaande sync signaal gebruiken van de Intellivision en er op de correcte manier onze eigen pulsen aan toe voegen zodat alle timings in het gemaakt Sync signaal volgens PAL specificaties zijn.
Als test ben ik begonnen met een ICE40 HX8K fpga test boardje. Ik heb er voor gekozen om dit in Verilog te doen. Het programmeren van een fpga vereist een hele andere denkwijze dan software programmeren!!! Je programmeert in feite hardware, en hardware voert processen niet sequentieel uit, maar parallel. Ondanks dat de syntax wel wat weg heeft van C# vergt dit dus echt een andere benadering. Het leuke van de ICE40 series is dat ze een open source ontwikkel platform hebben in de vorm van IceStudio. Dit geeft de ontwikkelaar de mogelijkheid om via een grafische user interface schakelingen te bouwen.
De uitdaging ligt hem dus in het creëren van een stukje ROM waar de kleuren in opgeslagen worden, maar vooral het opnieuw ontwikkelen van het Sync signaal. Via allerhande counters e.d. kom ik op het volgende test schema uit, waarmee het sync signaal met de benodigde pulsen op de goede timings uit komt:
Ik heb deze test opstelling gebruikt:
Dit geeft me tot nu toe in ieder geval beeld op mijn Framemeister. Maar... Framemeister slikt zo'n beetje alles. Het is dus wachten op mijn OSSC om te zien wat deze met het signaal doet.
In de tussentijd is het mogelijk om dit model uit te breiden. Denk aan verschillende kleuren opties, een menu in de mod, maar zeker ook een linebuffer om vga resoluties en hoger mogelijk te maken. Sky is the limit. Zelfs hdmi behoort uiteindelijk tot de mogelijkheden, echter wel via een snellere fpga.
Voorlopig wacht ik dus op een OSSC en ontwerp ik de printplaat. Ik wil graag wel de grootte van bovenstaande printplaat die ik al gemaakt heb aanhouden, puur omdat de installatie dan erg eenvoudig is. Compact design en efficiënt. Zodra ik meer weet over de OSSC zal ik hier weer een update plaatsen.
.
.
