Sdw Posted February 11, 2013 Share Posted February 11, 2013 (edited) Say I want to update the graphics for a line currently being displayed, for example like this: I have a standard 160x192 bitmap mode. My DLIST repeats the same address on all lines, so I keep displaying the same 40 bytes over and over. I then have code that looks a little something like this 1) Wait for the first line 2) STA WSYNC 3) Update some of the 40 bytes 4) Repeat 1-3 192 times (yeah, I know I could probably do this with DLI stuff, but I chose the simple, buisy-wait-loop approach for now) How does the graphics fetching work? Will all the 40 bytes for the line have been fetched before I start modifying it, ie. my modify is safe, or will t continuously fetch data, meaning that some of my modifications will be shown mid-scanline? Edited February 11, 2013 by Sdw Quote Link to comment Share on other sites More sharing options...
Xuel Posted February 12, 2013 Share Posted February 12, 2013 See "4.12 DMA timing" in the Altirra Hardware Reference Manual for the exact timing of the fetches. In general, they happen a few cycles before the pixels that they represent are rendered. Depending on your playfield width and HSCROL value you'll have a varying number of cycles between WSYNC writes and the fetch of the first byte. So, if you can fit all of your memory writes into that time period, then you won't have any old data on the upcoming line. Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 12, 2013 Share Posted February 12, 2013 First of all, it's going to be tight to do much useful modification on a per-scanline basis. Out of 114 cycles per scanline, you are already going to lose 40 to playfield DMA, 9 to refresh, 3 to display list DMA, and 4 to the STA WSYNC.. That leaves you with 58 cycles to play with. If you are indexing into the scanline the best write speed you can get is one byte every 4 cycles, with the line buffer in page zero. The short answer is that ANTIC is going to be fetching bytes gradually and so you are going to be racing it for updating the line buffer. ANTIC will be grabbing every other cycle during the active region to fetch bytes AND some extra for refresh, so the 6502 is going to be at a severe disadvantage during that time, writing at less than one-fourth the speed that ANTIC is reading. For a tear-free display, you have the option of either going fast enough to stay ahead of ANTIC or delaying to drop behind it. STA WSYNC releases the CPU right after ANTIC finishes fetching for a line, so you should time your code accordingly. Also, if you do this, make sure you test on real hardware. Emulators vary widely in how accurate they model ANTIC's memory fetches as it's fairly expensive to do it accurately, and some compromise by reading the entire scanline at once. This fib is good enough for most games but will be inaccurate with what you are planning. Quote Link to comment Share on other sites More sharing options...
MaPa Posted February 12, 2013 Share Posted February 12, 2013 Hmm.. Kefren bars effect maybe? 1 Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 12, 2013 Share Posted February 12, 2013 Some advantage could be had by using 2 line buffers, alternate between each scanline. Then you can worry much less about update vs Antic fetches and use of WSync might be able to be restricted to once every 2nd scanline. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted February 12, 2013 Share Posted February 12, 2013 (edited) in my kefren bars approach you have the screen borders to update vram easily. but remember that your display list does not need to be $4f,line_buf_lo,line_buf_hi $4f,line_buf_lo,line_buf_hi $4f,line_buf_lo,line_buf_hi $4f,line_buf_lo,line_buf_hi ... $41,dlist_lo,dlist_hi so it can be $4f,line_buf_lo,line_buf_hi $0f,$0f,$0f,$0f... $41,dlist_lo,dlist_hi (non-sense) --- aaarg... stupid... missing one moring coffee... the $0f,$0f will increment the LMS by +40 each scanline... sorry. forgot everything. the first approach is correct... Edited February 12, 2013 by Heaven/TQA Quote Link to comment Share on other sites More sharing options...
Sdw Posted February 12, 2013 Author Share Posted February 12, 2013 OK, thanks all, it seems that it is a bit more complex than I first thought. I have been testing in Atari800win and thought it looked good when pausing and inspecting the graphics, and it looks OK to the eye on my Atari 130XE, but of course there is movement in the effect, so there could be bugs that I'm not noticing. Hmm.. Kefren bars effect maybe? Yes, that's correct. Good deduction! Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 12, 2013 Share Posted February 12, 2013 Memory fuzzy on this one but you can disable DList DMA and Antic will repeat whatever mode is active. The fuzzy part being that I'm not sure if an LMS <addr> will repeat - I suspect that the mode repeats and the memory scan still updates which isn't what you want. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted February 12, 2013 Share Posted February 12, 2013 Rybags... does that not being repeated out of internal antic line buff? Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted February 12, 2013 Share Posted February 12, 2013 OK, thanks all, it seems that it is a bit more complex than I first thought. I have been testing in Atari800win and thought it looked good when pausing and inspecting the graphics, and it looks OK to the eye on my Atari 130XE, but of course there is movement in the effect, so there could be bugs that I'm not noticing. Yes, that's correct. Good deduction! would it not be better to use Altirra instead of good old A800win? as this was not used in my upcoming production in that presented form... maybe some inspiration. kefrenbars.xex 2 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted February 12, 2013 Share Posted February 12, 2013 and the (messy) source code for MADS. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted February 12, 2013 Share Posted February 12, 2013 (edited) and the (messy) source code for MADS. kefrenbars.zip Edited February 12, 2013 by Heaven/TQA Quote Link to comment Share on other sites More sharing options...
MaPa Posted February 12, 2013 Share Posted February 12, 2013 And still no source code included 1 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted February 12, 2013 Share Posted February 12, 2013 (edited) ok. zip updated Source code is based on Fox code or Eru's... Edited February 12, 2013 by Heaven/TQA Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 13, 2013 Share Posted February 13, 2013 Memory fuzzy on this one but you can disable DList DMA and Antic will repeat whatever mode is active. The fuzzy part being that I'm not sure if an LMS <addr> will repeat - I suspect that the mode repeats and the memory scan still updates which isn't what you want. That's correct, the LMS won't actually do anything while display DMA is off and so the memory scan counter will just keep going as if there was no LMS. Rybags... does that not being repeated out of internal antic line buff? No, you have to play tricks with disabling playfield DMA or stretching mode lines with VSCROL to do that. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted February 13, 2013 Share Posted February 13, 2013 VSCROL trick would be on my list to improve the Kefren FX but well... in the end I kicked that fx so not on my list anymore Quote Link to comment Share on other sites More sharing options...
MaPa Posted February 13, 2013 Share Posted February 13, 2013 I don't think you would improve kefren bars with VSCROL trick.. with VSCROL trick you just repeat data in internal ANTIC buffer and can't modify them. Quote Link to comment Share on other sites More sharing options...
Sdw Posted February 13, 2013 Author Share Posted February 13, 2013 (edited) Interesting take on the kefrens bar Heaven, mine look a bit more "traditional". Hopefully people appreciate the classics as well! I will refrain from looking at the source code, to avoid any accusations of code-stealing! Regarding my own kefrens, think I got it sorted out now, looks OK to my eye both in Altirra and on my 130XE. Looking at the Altirra Hardware Reference Manual, Iif I read it correctly, the first graphics fetch happens on cycle 20, and with my new code, I have all updating done by cycle 16, so all should be good. -edit- oh, quick additional question: How many lines of screen data is it possible to display? At the moment I have 208 lines, dlist looks like this: $70 208 lines of $4e,<scr,>scr $41 I guess 216 should be possible as well, but it seems like I can only get extra lines "upwards", is it possible to have more screen estate "downwards"? Edited February 13, 2013 by Sdw Quote Link to comment Share on other sites More sharing options...
MaPa Posted February 13, 2013 Share Posted February 13, 2013 (edited) You can have up to 240 scanlines, just make sure the 240th is not hi-res one, there is some bug in ANTIC and it will screw the display. (you can have 240 times $4e,<scr,>scr and $41,<dlist,>dlist at the end) Edited February 13, 2013 by MaPa Quote Link to comment Share on other sites More sharing options...
Xuel Posted February 13, 2013 Share Posted February 13, 2013 (edited) If you use 240 lines, you have to update DLISTL/H ($D402/3) with the CPU during VBLANK. If you try to let ANTIC fetch the JVB ($41) instruction it'll already be the next frame by the time it interprets it so you'll get flicker with a blank screen every other frame. You could also just do 239 lines, but 240 is the way real hackers do it. Edit: Fixed DLISTH address. Edited February 13, 2013 by Xuel 1 Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 13, 2013 Share Posted February 13, 2013 240th hires bug can be overcome - it involves changing DMACTL settings at strategic times, but adds a bunch of overhead and complexity to a program. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted February 15, 2013 Share Posted February 15, 2013 sdw... I don't mind "stealing" demo code... it is all about influence mine influence took code by Eru & Fox (sorry mates ) as reference starting point. my code is not able to do a lot of more lines... so much appreciated if you can manage fullscreen Quote 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
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.