Heaven/TQA Posted August 7, 2003 Share Posted August 7, 2003 weird stuff... i'll double check on real hardware and try to proove my memories... i know that i played around with vscrol... but maybe it was done with a DLI not horizontal but vertical... what happens if we do this? assuming a gr.6 char line dli pha lda #3 sta wsync sta vscrol lda #1 sta wsync sta vscrol lda #5 sta wsync sta vscrol pla rti ??? will check that... hve Link to comment Share on other sites More sharing options...
analmux Posted August 7, 2003 Share Posted August 7, 2003 Is this what you mean? ..well, this is kind of weird too. Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 8, 2003 Share Posted August 8, 2003 if you use a vscrol lookup table like this 0 1 2 2 3 3 3 2 2 1 0 and put this in vscrol via dli every scanline why should it than not be possible to engage an fx like in super turrican on snes ("sahara" effect?" in level 1 the background) like kind if wobbling... should be possible if you scroll through a desired lookup table... hve ps. today i moved my flat... and found original discs / cassetes of druid, arkanoid, tapper, goonies, spindizzy, boulder dash, guild of thieves (big box with all goodies like diary, etc...) am i not lucky? and i found my all time fave on vic 20...submarine commander module!!! Link to comment Share on other sites More sharing options...
analmux Posted August 9, 2003 Share Posted August 9, 2003 I still don't get any interesting results, when using your method. Are you sure you aren't mistaken with Hscrol? It seems to me that antic only updates vscrol when reading a dlist-opcode. I think antic reads the vscrol register only once every graphics line to compute internaly the offset adress for characterset data, and doesn't change it anymore. Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 10, 2003 Share Posted August 10, 2003 i'll double check it today afternoon on hreal hardware... it's nearly 10 years ago... of course i can be completly wrong... but read this in meantime http://www.s-direktnet.de/homepages/k_nadj...dj/mode9++.html hve Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 11, 2003 Share Posted August 11, 2003 check out http://www.howell1964.freeserve.co.uk/Atar...le_counting.htm http://www.howell1964.freeserve.co.uk/Atar...ri_hw/antic.htm maybe some usefull information bits included? hve Link to comment Share on other sites More sharing options...
analmux Posted August 11, 2003 Share Posted August 11, 2003 another way to count cycles I used a year ago was connecting the Halt line with the Lum1/2 line of GTIA. you actually see when DMA happens on the screen. (also DRAM refresh cycles) Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 11, 2003 Share Posted August 11, 2003 via hardware connection? or what do you exactly mean??? Link to comment Share on other sites More sharing options...
analmux Posted August 11, 2003 Share Posted August 11, 2003 via hardware connection? Yes, with a copper wire. you can see black areas where Antic halts the 6502, and lighter areas where not. you can see vertical black bands (at PM positions 48, 56, 64, 72 and 80)where refresh takes place. When you connect the Address0 line to LUM2 of GTIA you even see the refresh address counting. (poke 559,0: se. 4,0,4) Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 11, 2003 Share Posted August 11, 2003 all i need is a kind of wire cable and connect the pins? can you post me how it is done? (i am total hardware dummy) as seem to have a digi cam...possible to post me pics? this is kind of "real debug station" hve Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 11, 2003 Share Posted August 11, 2003 as i've been setup my original 130xe (no fake emu... ) i am experiementing with kernel routines and repositioning of players... just for my stupid understanding... in a rasterline... do i have to position players "in fron of the rasterbeam" or "behind" to make multiplexed sprites? hve Link to comment Share on other sites More sharing options...
emkay Posted August 11, 2003 Share Posted August 11, 2003 as i've been setup my original 130xe (no fake emu... ) i am experiementing with kernel routines and repositioning of players... just for my stupid understanding... in a rasterline... do i have to position players "in fron of the rasterbeam" or "behind" to make multiplexed sprites? hve You have to switch the Playerposition when the Raster-Beam has drawn the first position already... Link to comment Share on other sites More sharing options...
analmux Posted August 11, 2003 Share Posted August 11, 2003 all i need is a kind of wire cable and connect the pins? Yes, you don't need to solder, just making electric contact between the pins. I'll make some weird pics this weekend (have some exams now, doh). do i have to position players "in fron of the rasterbeam" or "behind" to make multiplexed sprites? I assume you mean the electron beam of the television/monitor. If you mean before (in time) by 'in front of' then you must off course make sure to reposition PM in front of the beam (**and after the old position, like Emkay said**). You only have to keep in mind how to change the PM-data. You must reserve CPU time to change them. A simple change of the PMBASE address will not work, because Antic updates the pmdata only once per scanline. There is no problem if you keep the data unchanged. When writing to WSYNC, CPU waits till the end of graphics (PM-position 48+160=208) when the electron beam draws at position 208 (cycle 104) you have 10 cycles left before hblank. On the new line are about 16 cycles left (24 (=48 colorclocks)- 4 refresh, -4 PM data fetch DMA etc.) till the next graphics has to be displayed. Just keep in mind that the refresh cycles are stolen from the CPU when the electron beam is on the left part of the screen. On the right part you simply have more processor time. I even think GTIA is retarded one or two colorclocks compared to antic. Gtia first waits for data on the Antic-bus (the 3 wires that are used for communication from Antic to Gtia), then it displays the graphics. In GTIA-modes it must receive data two times (two consecutive colorclocks) to be able to display 16 different colors or lums. That's why GTIA mode screens have such a weird ratio (4:1). The antic bus commands: 000 backgroundcolor 001 hblank signal 010 start graphics with gr.0/8 type 011 start graphics with other graphics type 100 playfield color 0 or gr.0/8 bitpattern or GTIA-mode 9/10/11 bitpattern (first or last bitpair) 101 playfield color 1 or gr.0/8 bitpattern or GTIA-mode 9/10/11 bitpattern (first or last bitpair) 110 playfield color 2 or gr.0/8 bitpattern or GTIA-mode 9/10/11 bitpattern (first or last bitpair) 111 playfield color 3 or gr.0/8 bitpattern or GTIA-mode 9/10/11 bitpattern (first or last bitpair) --------------------------- I'm also experimenting with the TIP effect to reduce the amount of blank (gr. 11) lines. GTIA (like antic) seems to have a line-buffer to store color information. That's why the next scanline (in TIP, when changing the GPRIOR register to produce the GTIA-bug) contains the same colors as the previous scanline. Well, why should it not be possible to do this more than one time: 1 scanline gr.11 for color information 7 scanlines antic E for lum information in 160 pixels wide resolution. 1 scanline gr.11 for color information 7 scanlines antic E for lum information in 160 pixels wide resolution. 1 scanline gr.11 for color information 7 scanlines antic E for lum information in 160 pixels wide resolution. etc. etc. .... (7 is just arbitrary. It should be possible to repeat it any number of times) Then the screen layout will be more like a C64: You can choose colors in the first line (like in the attribute cells in color-RAM on the C64) and show some beautiful graphics in the other 7 lines. There must be a way. -------------- analmux Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 11, 2003 Share Posted August 11, 2003 ok... i switchted to simple color changes... please have a close look to these screenshots... why are the 1st half of the bars bigger size than the 2nd half??? i have attachted the ATR & the source as well... maybe some of you can sent down wisdom... hve * written by Heaven/TQA * * assembled with XASM / XBOOT * * heaven_tqa @ hotmail.com * 11/08/03 gractl equ 53277 graphp0 equ $d00d sizep0 equ 53256 hposp0 equ 53248 colbk0 equ $d01a dliv equ 512 dlistv equ 560 vbiv equ 546 nmien equ $d40e wsync equ $d40a org $4000 start jsr pminit jsr wait_vbl mva #0 559;switch off screen dma (screen off) mwa #dli dliv;set new DLI mwa #dlist dlistv;custom new display list mwa #vbl vbiv;custom VBL mva #$c0 nmien;enable DLI + VBL mva #34 559;normal screen width loop jmp loop color_cycle inc pos0+1 ;color cycle inc pos1+1 inc pos1+1+5 inc pos1+1+2*5 inc pos1+1+3*5 inc pos1+1+4*5 inc pos1+1+5*5 inc pos1+1+6*5 inc pos1+1+7*5 inc pos1+1+8*5 inc pos1+1+9*5 inc pos1+1+10*5 inc pos1+1+11*5 inc pos1+1+12*5 rts vbl lda 53279 ;start pressed? cmp #6 beq vbl_end ;if pressed skip moving jsr color_cycle;simple color cylce vbl_end jmp $e45f ;back into OS routine wait_vbl mva #1 540;will be decremented by OS every VBL wait0 lda 540 bne wait0 rts pminit mvx #0 hposp0;move player0 into overscan (non visible) mva #15 704;white color mva #0 623;prior #1 mva #$ff graphp0;write directly into GTIA register rts * allign dli on page boundary org $5000 * 114 cycles per rasterline... dli pha txa pha ldx #192 ;192 scanline kernel kernel sta wsync ;sync with rasterbeam stx colbk0 nop ; 2 nop ; 2 nop ; 2 nop ; 2 pos0 mva #48 colbk0; 5 cycle pos1 mva #60 colbk0; +5 = 28 mva #72 colbk0; +5 = 33 mva #84 colbk0; +5 = 38 mva #96 colbk0; +5 = 43 mva #108 colbk0; +5 = 48 mva #120 colbk0; +5 = 53 mva #132 colbk0; +5 = 58 mva #144 colbk0 ; +5 = 63 mva #156 colbk0; +5 = 68 mva #168 colbk0; +5 = 73 mva #180 colbk0; +5 = 78 mva #192 colbk0; +5 = 83 mva #204 colbk0; +5 = 88 dex ; +2 = 90 bne kernel ; +6 = 96 pla txa pla rti dlist dta b($70,$70,$c0,$41) dta a(dlist) org $2e0 dta a(start) demo1.zip Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 11, 2003 Share Posted August 11, 2003 thanks... will think about it tomorrow... i am tired... have to go to work in few hours... btw. the demo works in atari800win 3.1+ so you can double check the "bar width"... hve Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 11, 2003 Share Posted August 11, 2003 could be this the reason as you have explained? "Just keep in mind that the refresh cycles are stolen from the CPU when the electron beam is on the left part of the screen. On the right part you simply have more processor time. " hve Link to comment Share on other sites More sharing options...
analmux Posted August 11, 2003 Share Posted August 11, 2003 why are the 1st half of the bars bigger size than the 2nd half??? It is caused by the cycle stealing for DRAM refresh which happens in the left part of the screen. (at the time the left part is drawed) You can't turn it off. Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 11, 2003 Share Posted August 11, 2003 @ emkay it seems your MCS style gets more complicated than expected... now we are dealing with "1st half" "2nd half" screen... hve Link to comment Share on other sites More sharing options...
Bryan Posted August 11, 2003 Share Posted August 11, 2003 Look back on page 3 of this topic for a picture I posted that shows the lost refresh cycles. This information is all good though, and should be documented for hard-core coding. -Bry Link to comment Share on other sites More sharing options...
analmux Posted August 11, 2003 Share Posted August 11, 2003 Well, repositioning PM by counting back cpu cycles could be tricky, because not on every scanline the same amount of cycles are stolen. Antic DL opcodes with bit 6 turned on steal 2 more cycles. Players steal 4 cycles, the missiles another cycle, every scanline only in hiresolution PM mode. Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 12, 2003 Share Posted August 12, 2003 @ brye thanks for reposting... so my stripes are just non distorted because i don't use any bckgrnd gfx mode weather antic 2,4,e,f or whatever... i have 2 other atari 800xls lying around and i will definitly try the "hardware debug mode" out... hoping not to freeze up one of the babies... (bit i wait for the picture where to connect the pins) maybe this gives me more understanding & insight into the gfx hardware.... hve Link to comment Share on other sites More sharing options...
Bryan Posted August 12, 2003 Share Posted August 12, 2003 I'm looking at the GTIA data, and it would appear to me that there is no buffer in GTIA, but rather Antic contains a buffer for repeated-line modes and for storing a line's worth of characters. The reason I think this is because on the ANx lines, there is no way to signal GTIA to "repeat last line." I'm guessing Antic just sends it again. Does anyone know what happens if you mess with the playfield width in mid-line? -Bry Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 12, 2003 Share Posted August 12, 2003 what time is in florida? do atari guys never sleep??? i downloaded yesterday the "confidential" 50 page atari doc about POKEY including all schematics, etc... is there any other on the net about antic/gtia? i just found (i guess on dan's site) the link to the patent docs... but this is out of the way i even understand one bit of it... the pokey doc contains even signal stuff... if there's one for antic... this could help you guys (to me this means nothing as i am totally non hardware guy) hve Link to comment Share on other sites More sharing options...
Bryan Posted August 12, 2003 Share Posted August 12, 2003 I've got the other documents as well. The Antic one doesn't have any internal diagrams though. It's 1:00 AM here. I'm going to bed shortly, but this is when I usually get home from work. -Bry Link to comment Share on other sites More sharing options...
emkay Posted August 12, 2003 Share Posted August 12, 2003 @ emkay it seems your MCS style gets more complicated than expected... now we are dealing with "1st half" "2nd half" screen... hve 1. This is one point, the Charmode is absolutely necessary... 2. This is why PM multiplexing is a must BTW: Did you remember TMR writing, that the C64 has 65 Cycles in a standard line and on the Dirty-line (DMA-Line) it has 40 cycles less? This is similar to the ANTIC Charmode, but with ~34 cycles left in the DMA line and ~114 cycles left on a standard line.... And then think about, that the ATARI can do ~115 cycles, when C64 is doing 65 cycles... Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Archived
This topic is now archived and is closed to further replies.