[abc80] Kod synkad med rasterstrålen?

[juhasz]

Ja det räknas ju en hel del på videotiming på s144-147...
Sen måste man ju ta med z80ns nmi-responstid för att kunna räkna cykler...
Robert


Skickat från min Samsung Galaxy-smartphone.
-------- Originalmeddelande --------Från: Anders Sandahl <anders at abc80.net> Datum: 2016-12-22  16:19  (GMT+01:00) Till: Joppe <joppe at agusta.se> Kopia: Andreas Gustafsson <andreas.gustafsson at gmail.com>, Robert Juhasz <juhasz at abc.se>, abc80 <abc80 at abc80.org> Rubrik: Re: [abc80] Kod synkad med rasterstrålen? 
Den finns som PDF: http://www.abc80.net/luxor/docs/ABC80/Mikrodatorns_ABC.pdf

/Anders

> Har någon tittat i "Mikrodatorns ABC"? Där står det mesta om hur
> bildminnet
> och NMI hänger ihop med processor och hastigheter och timing. Jag hittar
> för
> stunden inte min, men den bör finnas tillgänglig hos någon av oss tänker
> jag.
> /Carl-Johan
>
> ---------- Original Message -----------
> From: Andreas Gustafsson <andreas.gustafsson at gmail.com>
> To: Robert Juhasz <juhasz at abc.se>
> Cc: abc80 <abc80 at abc80.org>
> Sent: Thu, 22 Dec 2016 15:42:17 +0100
> Subject: Re: [abc80] Kod synkad med rasterstrålen?
>
>> Tack Robert och Erik!
>>
>> Där ser man, man ska inte tro att man bryter ny mark, det finns
>> folk som varit där för över årtionden sedan redan... abcrez.txt
>> gör precis som jag tänkt att jag skulle göra, så då slipper jag
>> själv räkna ut timingen!
>>
>> Däremot har jag försökt räkna baklänges baserat på den koden,
>>  men får det inte riktigt att stämma med Eriks siffror. Den
>> initiala timingen från HALT tills att grafikoutput börjar i abcrez.txt
>> är cirka 8940 cykler, vilket om varje rad är 192 cykler ger
>> ungefär 46.5 rader. Om displayen är
>> 24:Front porch 240:Vdisp
>> 32: Back porch
>> 16: Vsync Har jag svårt att se hur detta matchar ihop. Jag vet inte
>> om HALT väntar på start eller slut av VSYNC, men oavsett vilket
>> borde det vara antingen 24 eller 16+24 =40 rader till displayens
>> början, inte 46+...
>>
>> När det gäller emulatorer så funkar det *nästan* i ABCWin
>> (åtminstone i den senaste betan som jag fått), dock så verkar det
>> inte stämma riktigt, utan vara ungefär en rasterlinje off. Så
>> emulatorn verkar ta hänsyn till att grafikminnet kan uppdateras
>> dynamiskt under uppritningen av en frame, men från vad jag kan se kommer
>> det en rad "för sent" jämfört med hur det ser ut på riktig
>> hårdvara. Kan man möjligtvis uppmuntra herr Isaksson till att
>> göra ytterligare uppdateringar i ABCWin? :)
>>
>> /Andreas
>>
>> 2016-12-20 14:07 GMT+01:00 Robert Juhasz <juhasz at abc.se>:
>>
>> > Det finns exempel på sån kod i programbanken! Se
>> > http://www.devili.iki.fi/pub/Luxor/software/ABC-klubben/
>> > abc80/hugo/abcrez.txt
>> > (man behöver ju inte rita [UTF-8?]korsâ�¦)
>> >
>> > kolla även in higrez.bac i samma bibliotek för inspiration! Men såvitt
>> jag
>> > sett klarar ingen emulator den (än!) så kör på en riktig ABC80 för att
>> se
>> > [UTF-8?]högupplösningsgrafiken�
>> >
>> > Sen är även högupplösningsinterruptet på 7812 kHz (två rader tror jag)
>> > kopplat till videoklockan så den borde också gå att använda. Har bara
>> sett
>> > den användas för att göra ljud, men man borde kunna rita
>> [UTF-8?]också�
> Kolla in
>> > http://www.devili.iki.fi/pub/Luxor/software/ABC-klubben/
>> > abc80/musik/ljud2.asm
>> > och tillhörande filer för ett exempel på hur den används.
>> >
>> > Ser med spänning fram på resultatet av ditt hackande! ;)
>> >
>> > Robert
>> >
>> >
>> > 20 dec. 2016 kl. 13:41 skrev Andreas Gustafsson <
>> > andreas.gustafsson at gmail.com>:
>> >
>> > Jag har testat lite att dynamiskt skriva om skärmminnet kontinuerligt,
>> och
>> > det ser ut som om ändringar får genomslag direkt, dvs. i teorin om man
>> har
>> > ett A på skärmen men sedan skriver om i skärmminnet så det är ett B
>> när
>> > rasterstrålen är halvvägs igenom uppritningen av det tecknet så får
>> man
>> > undre halvan från ett B.
>> >
>> > För att kunna verifiera detta korrekt måste jag dock ha kod som är i
>> exakt
>> > sync med rasterstrålen.
>> > 'halt' borde ju göra så att man är i ett känt state där rasterstrålen
>> är i
>> > VBL-området (eller?)
>> >
>> > Det enda jag hittat är att ABC80-klockan ska vara 3MHz. Är det exakt,
>> eller
>> > finns det någon som har en exaktare siffra?
>> >
>> > Om vi antar antar att skärmuppdateringsfrekvensen är 50Hz och vi har
>> 312
>> > linjer (standard PAL) så ger 3MHz då får vi dessvärre inte ett jämnt
>> antal
>> > klockcykler per rasterrad, utan 192.30769...
>> >
>> > Det borde dock fortfarande gå att hålla hyfsad synk med rasterstrålen
>> om
>> > man kompenserar för detta.
>> >
>> > Finns det något som "stjäl" cykler från CPUn som man måste ta hänsyn
>> till?
>> >
>> > Det jag helst skulle vilja göra är att köra 'halt', anta att jag är på
>> > rasterlinje 0 då, och sedan köra kod där jag räknat klockcykler tills
>> jag
>> > är exakt där skärmutritning börjar, för att sedan dynamiskt kunna
>> > manipulare skärmminnet efterhand som det ritas ut.
>> > Skulle då även behöva veta hur många linjer ner som första raden av
>> tecken
>> > är.
>> >
>> > All info som någon har är av intresse, annars antar jag att det är
>> > experimenterande som gälller... :)
>> >
>> > /Andreas
>> > _______________________________________________
>> > ABC80 mailing list
>> > ABC80 at abc80.org
>> > http://www.abc80.org/mailman/listinfo/abc80
>> >
>> >
>> >
>> _______________________________________________
>> ABC80 mailing list
>> ABC80 at abc80.org
>> http://www.abc80.org/mailman/listinfo/abc80
> ------- End of Original Message -------
>
> _______________________________________________
> ABC80 mailing list
> ABC80 at abc80.org
> http://www.abc80.org/mailman/listinfo/abc80
>