MiaM's MEK6802D5E - 6802-enkortsdator - bygga ut?

[Platis]

Antar att du behöver lite logik för blankningsignaler och sånt också!?

[Jan Almqvist]

Ja, det är riktigt. Det kommer förmodligen från bitar på räknarna. Här sviker minnet, det är 30 år sedan. Kanske använde jag mej av preset på räknarna och släpper blanking när de slår om från "minus" till 0. Det fungerar i horisontell ledd eftersom jag använder 64 positioner. I vertikal ledd är det säkert någon mer logik inblandat pga 24 eller 25 rader.

[MiaM]

En variant är ju att trigga blankning på "pixelvärden" "utanför kanten" och räknarvärdet före första synliga pixeln är också högsta räknarvärde och triggar nollställning av räknaren.

Jag undrar om det kanske faktiskt är enklast att ha separata räknare för minnet v.s. displaypositioner? På så vis går det enklare att ha ett "binärt ojämnt" antal tecken horisontellt utan att behöva antingen ha oanvänt displayminne eller krångla med multiplicerarlogik (!).

Jämför t.ex. VIC-20 som har fyra register för att reglera bildstorleken. Två väljer startvärde på X/Y-positionsräknarna och två väljer antal tecken i X- respektive Y-led. All skärmdata ligger sekventiellt i minnet. (Sen kan man som sidospår kritisera Commodore för dumheten att skärmeditorn i ROM inte kan ställas om för annan skärmstorlek än standard 22*23 trots att "alla" TV/skärmar på den tiden kunde rymt lite mer).


En riktig fulvariant på synkgenereringen är att använda en färdig synkgenerator och sen bara använda monovippor för att trigga starten av skärmpositionen. Det blir nog inte bra alls.

För övrigt så är väl de flesta konstruktioner av den här typen ökänd för att inte ge korrekt videosignal enligt alla specar. Jag minns att en av de stora fördelarna med Amigan var att videosignalen faktiskt var helt korrekt med avseende på detaljer i synkpulser o.s.v.


Det vore kanske läge att ge sig på lite feature-creep och implementera något likt chipset'et i Ataris 8-bit-datorer, som kan sägas vara föregångare till Amigan.

[Jan Almqvist]

Med tanke på att specen för både RF och videosignalen är, om inte 100 år gammal så åtminstone från före 1956 och gjord för att fungera med dåtidens rör-teknik, så borde den inte vara svår att uppfylla.

[MiaM]

Ja, standarden är riktigt gammal, men hur många som byggde "hemdatorer" förr läste verkligen standarden och tyckte det var ekonomiskt försvarbart att uppfylla alla delar? Jag tänker på sådant som alla dessa specialvarianter av pulser/flanker under v-synk-intervallet o.s.v.

Dessutom måste man ju tyvärr bryta mot standarden en smula så fort man vill ha en signal som inte är interlace, fast det är väl ett mindre problem i sammanhanget.

Det har väl också gjorts en del förenklande "fusk" i form av att avvika något med t.ex. synkfrekvenserna eftersom det då går att få jämnare förhållanden mellan pixelklocka, färgbärvågsklocka och synkfrekvenserna. Exempelvis ger ju C64 vad jag minns stabilare färger än vanliga TV-signaler på en halvdålig TV. Jag kan minnas fel här.

[Platis]

Jag undrar om det kanske faktiskt är enklast att ha separata räknare för minnet v.s. displaypositioner? På så vis går det enklare att ha ett "binärt ojämnt" antal tecken horisontellt utan att behöva antingen ha oanvänt displayminne eller krångla med multiplicerarlogik (!).

Det är väl så ABC-80 funkar!

Jämför t.ex. VIC-20 som har fyra register för att reglera bildstorleken. Två väljer startvärde på X/Y-positionsräknarna och två väljer antal tecken i X- respektive Y-led. All skärmdata ligger sekventiellt i minnet. (Sen kan man som sidospår kritisera Commodore för dumheten att skärmeditorn i ROM inte kan ställas om för annan skärmstorlek än standard 22*23 trots att "alla" TV/skärmar på den tiden kunde rymt lite mer).

http://www.boray.se/commodore/museum.html


Har man ändå tänkt skriva till en massa register så är väl en 6845:a annars ett klockrent val som är mer flexibel och tillhör familjen så att säga!

Skulle man vilja ha en enkel lösning så är en 6847:a ingen dum ide(laser200, MC-10, dragon32 m.fl).
Fast teckenupplösning på 32x16 , enkel grafik + färg, inbyggd teckengenerator, inga register, olika grafiklägen etc kan väljas med en dip/strömbrytare!

[MiaM]

Ja, t.ex. ABC-80 har nog separat räknare.

Det verkar inte vara nån sport att använda en färdig krets, då kan man lika gärna ta ett gammalt PC-grafikkort. Det är iofs också en intressant idé, jag är rätt sugen på att göra ett ISA-buss-interface till 6802-kortet. Det kan ju inte vara särskilt krångligt sånär som på att det kommer säkert finnas obskyra kort som inte kommer fungera.

[Platis]

Jag tycker du ska bygga nåt eget! Har man separata räknare kunde man ju ha flera olika minnes/tecken plats-räknare där man kunde välja mellan tex 32x16, 40x24, 64x16, 80x24! Det svåra är kanske att få till minnesadresseringen på ett enkelt vis!

Är inte ISA en 16-bitars buss? Eller den kanske stöder både 8 och 16-bit! Utbudet av kort borde ju vara stort iallafall!

[MiaM]

ISA var endast 8-bit på de första PC-burkarna; när 286:an kom så blev bussen 16-bit men eftersom det behövdes bakåtkompabilitet med befintliga kort så gjordes 286:orna så att de kan köra 8-bit mot bussen. Därmed blev det enkelt för korttillverkare att lägga "det mesta" som 8-bit-grejer trots att bussen klarar 16-bit. Exempelvis så är dataöverföringen 16-bit men kommandona 8-bit på MFM-kontrollern som satt i IBM's första 286:a och det är den som emuleras av alla IDE/PATA-diskar. Det gör att man kan stoppa i ett 16-bitars IDE-kontrollerkort i en 8-bitarsmaskin och med "rätt" hemkokat bios (XT-IDE-projektet typ) ändå köra disken men bara få halva kapaciteten eftersom 8 av de 16 bitarna vid skrivning/läsning bara trillar ut på en oansluten del av busskontakten Andra exempel är att nästan alla BIOS som sitter på kort är 8-bitars trots att kortet i övrigt är 16-bitars. Om man nu vill nyttja alla 16 bitarna från en 8-bit-maskin så kan man ha ett par latchar/d-vippor så att man före en ISA-buss-skrivcykel kan ladda en vippa/latch med data för 16-bit-delen, och omvänt vid en ISA-buss-läscykel kan man låta en vippa/latch laddas med data från 16-bit-delen och läsa av den vippan/latch'en separat efteråt (utan att det då går ut någon cykel på ISA-bussen).


Jag funderar förresten extremt löst på att titta hur grafiken gjordes i 8-bitars Atari-hemdatorerna (400/800/600XL/800XL/65XE/130XE och vad de nu hette). Det var ju ett mellansteg i utvecklingen från Ataris VCS/2600 tv-spel och Amigan, i princip. Det blir kanske alldeles för mycket jobb att bygga själv men jag gillar principen att kasta bort sånt som automatisk återställning av räknare/pekare vid v-synk utan istället ha en enklare hjälpprocessor/displaylistgrej som kan sköta sånt som att ladda pekare/räknare, växla grafiklägen/inställningar o.s.v.

[Platis]

Ja, jag förstår hur du tänker! Det skulle väl typ räcka med en 8048:a eller nåt, en PIC? Ataris grafik-kretsar tror jag både gav väldigt bra bild för sin tid + att dom hade ovanligt många grafiklägen, typ 10st eller nåt! Har en 800xl nånstans!

[MiaM]

Du vill inte byta bort 800xl-burken?

Jag minns att de burkarna kunde visa 16 eller möjligtvis 8 färger samtidigt i lägsta upplösning, och de hade dessutom så många färger i paletten att det gick att göra snygga övergångar, så det gick att göra riktigt snygga grafikprogram som de samtida 8-bit-burkarna inte klarade.

Samtidigt verkar basic/rom-koden ha varit särdeles korkat skriven med en massa grejer som slöade ner datorn i form av att vid varje vblank kopiera en radda saker från ram till i/o-register och allt vad det nu var... Eller så var de kanske långsamma även rent hårdvarumässigt, mer avancerad grafik kräver ju fler busscykler varpå processorn blir utan en del cykler.

Sidospår på det: Det är lite ironiskt att vic-20 som klarar grafiken helt utan att "stjäla" cykler från processorn har interna ram'et och grafikkretsen på en sidan och processor, rom och externt ram på andra sidan av en dubbelriktad buffer. Hade vic-20 behövet stjäla cykler så hade det alltså hårdvarumässigt gått att göra så att det bara märkts då processorn använt internt ram men inte rom, externt ram och i/o... C-64 har ju bara ett enda ram och expansioner var extremt ovanliga men inget hade hindrat en motsvarande buffert så att basic/kernal-rom-koden kunnat köras samtidigt som grafikkretsen använder ram'et.

[Platis]

Vill gärna gå dej till mötes MiaM , men jag har bara den atarin i samlingen så jag vill nog behålla den! Men det finns en del annat jox!

Atari 800XL video!


VIC20 var väl en snabbare maskin än C64:an på en del saker!?

[MiaM]

Eller coolare saker på Atari 8-bit

https://www.youtube.com/watch?v=jeahY45QSIA


VIC-20 hade ju (obetydligt) högre klockfrekvens men den största skillnaden var ändå att C64's grafikkrets stal många cykler från processorn.

[Platis]

Bara älskade soundet!

[Platis]

Verkar vara trevligt pyssel.
Det fick mig mig att surfa in på http://www.swtpc.com/mholley/index.html
och läsa lite om 6800.

Den här ligger ute på eaby!
http://www.ebay.com/itm/291367941775?_t ... NA:US:1120