Rybags Posted May 30, 2006 Share Posted May 30, 2006 A couple of additions. As in my previous post, if Missile DMA isn't active, ANTIC uses that cycle to fetch the DLIST instruction. There is also the instance where the Address data (from an LMS) gets loaded where a normal Player 3 data access would occur. I haven't tried Jump DLIST instructions yet (who ever uses that anyway?) Also, does anyone know what triggers GTIA to read the data bus? Without PMG DMA enabled on ANTIC, it only seems to read it when ANTIC is doing DLIST instruction fetches. That is also the case if you disable screen DMA, but leave DLIST DMA active. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 30, 2006 Share Posted May 30, 2006 the jump instruction is good if you have parts of the display changing... f.e. logo panel, you could simply use the jmp command to change that... think of demos where top and bottom stay the same but the middle of the screen change several times... Quote Link to comment Share on other sites More sharing options...
pps Posted May 30, 2006 Share Posted May 30, 2006 oh...it was not joyride...can not remember which polish demo it was... joyride has just 2 gfx modes per scanline. I can remember, that it was the Our 5oft Part of the Unity Demo (ABBUC & Pokey), which showed us the '3 graphics mode in a scanline' effect. btw was this Demo ever released in finished version, I remember a version, where you have many tbr messages? Quote Link to comment Share on other sites More sharing options...
Sheddy Posted May 31, 2006 Share Posted May 31, 2006 (edited) the jump instruction is good if you have parts of the display changing... f.e. logo panel, you could simply use the jmp command to change that... think of demos where top and bottom stay the same but the middle of the screen change several times... it's a shame it causes a blank line when used - it would be much more useful if it didn't. Edited May 31, 2006 by Sheddy Quote Link to comment Share on other sites More sharing options...
Bryan Posted May 31, 2006 Share Posted May 31, 2006 So here's a question... does jump also cause the loss of VSCROL info like blanks do? (I'm guessing yes) -Bry Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 31, 2006 Share Posted May 31, 2006 (edited) Probably, since it is effectively a 1-blank line display instruction. A much better system would have been a Load Register instruction (like the Amiga) where subsequent data (say, up to 4 bytes) could be loaded into ANTIC or GTIA registers. Instruction code $41 could be used, then subsequent data would specify the address and operands. Example: INS: $41 Address: bit 7 specifies ANTIC (0) or GTIA (1) register, bits 6-5 specifies number of bytes to load (1-4) bits 4-0 specifies address ($00-$1F) So, a JMP DLIST would be $41,$20,<DLIST low>,<DLIST high> Extra logic could be added so that opertions involving Player graphics or position registers were executed at mid scan-line (for reusing PMGs within a scanline). Since we "lose" the JVB instruction, functionallity would have to be provided by a register within ANTIC. All we need now is for someone to email that idea back to 1978. Edited May 31, 2006 by Rybags Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 31, 2006 Share Posted May 31, 2006 (edited) Ed: wrong info Edited May 31, 2006 by Rybags Quote Link to comment Share on other sites More sharing options...
Bryan Posted May 31, 2006 Share Posted May 31, 2006 A much better system would have been a Load Register instruction (like the Amiga) where subsequent data (say, up to 4 bytes) could be loaded into ANTIC or GTIA registers. Yeah, just think if we could go back and help Atari out. Also, think of the code available for a killer in-store demo. -Bry Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 31, 2006 Share Posted May 31, 2006 Actually, loading POKEY using DMA would have been really nice too... digitized effects at the cost of just some memory and a couple of hundred stolen cycles per frame, instead of near 100% CPU cycles doing it the conventional way. Quote Link to comment Share on other sites More sharing options...
Bennet Posted June 1, 2006 Author Share Posted June 1, 2006 "A much better system would have been a Load Register instruction (like the Amiga) where subsequent data (say, up to 4 bytes) could be loaded into ANTIC or GTIA registers." Given that Jay Miner was the lead engineer who worked on the 2600, then 400/800, then the Amiga, you could say that he just didn't think of that idea yet (or there was some reason why it wouldn't work). If anything, Jay got it right with the Amiga 4 channel digitized audio with variable frequency playback, plus a decent amount of system memory. So, did anyone have any comments, surprises, or anything on my Antic timing diagrams? Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 1, 2006 Share Posted June 1, 2006 One slight "surprise" is the way the refresh cycles are bunched together... it means that the CPU is more or less stangled for a time - but I suppose it's better to lose those cycles early in the display than during overscan/Hblank. Just how over-engineered is the refresh system? Could they have gotten away with less? But I suppose there is a "worst case" scenario where you can get 2 "badlines" in a row where barely any refresh takes place (40 column textmodes with VSCROL=7) Do the refresh cycles access a different memory row in succession or do they just do some sort of random read? Quote Link to comment Share on other sites More sharing options...
Bennet Posted June 2, 2006 Author Share Posted June 2, 2006 Yea, especially on the high resolution character modes, the CPU is frozen. Which made me wonder how other computers of that era did their high resolution displays given you can only read so many bytes per scanline. I think the refresh system could have gotten away with less but probably not much less. I think the refresh circuit increments sequentially whenver it gets a cycle to run. I like how it handles getting preempted. I also wondered if there was a way to alternate the VSCROL on some high res modes to make a bunch of 1 scanline 48 column text mode lines, but I didn't think further than that. Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 2, 2006 Share Posted June 2, 2006 The C-64 only runs at half the RAM speed, so VIC does refresh and much of the screen DMA on the "alternate" cycles. The BBC micro apparently has RAM running at 4 MHz and the CPU at 2 MHz. Supposedly, all refresh and screen accesses are transparent. I remember running a long loop in assembler - from memory it was sufficiently faster than on an Atari to prove those facts. Z80 based computers don't have the pipelining advantage of the 6502 and memory accesses are less frequent. They probably suffer a slightly smaller penalty from DMA - but it's common knowledge that a Z80 needs to run at about a 60% or higher clock speed to match a 6502. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 2, 2006 Share Posted June 2, 2006 is this somehow "standard" or does this depend on your researches? Theory ------ ANTIC contains internal 4-bit register DCTR, which counts scanlines. Normally for every line of mode it counts from zero to a value specific to the mode (in our case of ANTIC 15 mode it's zero). It's different after enabling vertical scrolling. In first scrolled line DCTR counts from VSCROL to 0, in the subsequent normally, and in the last from 0 to VSCROL. "Counts from a to b" means: first DCTR is loaded with a, and near the end of every line DCTR is compared with b, if there's equality, next DL instruction will be fetched; otherwise DCTR is incremented by 1. Consider following DL: $2f $0f and VSCROL=13 (decimal). We will see: - first line 4 times (DCTR values 13,14,15,0 - DCTR wraps from 15 to 0, because it's 4-bit) - second line 14 times (DCTR values from 0 to 13) Similarly for VSCROL=3: - first line 14 times - second line 4 times What is important, the screen data repeated in several scanlines is fetched from main memory only once. Obtaining the mode ------------------ As should be now easy to figure out, to have each line shown 4 times, we create following Display List: b($6f),a(screen) b($0f) b($2f) b($0f) ... and only have to update VSCROL register in proper moments. Following picture should help in understanding what happens (in this English translation I'll just use ASCII art, I hope it's readable :-) ). DCTR 13 @------------------------- 14 -------------------------- 15 -------------------------- 0 -------------------------- 0 ========================== 1 ========================== 2 ========================== 3 ====!==================*## \--visible screen--/ '-' - first line of mode (bit 5 in DL is set) '=' - second line of mode (bit 5 in DL is clear) '@' - here VSCROL must contain 13 '!' - here starts DLI '*' - here VSCROL must contain 3 '#' - here we put 13 into VSCROL This picture shows two lines of mode, i.e. 8 scanlines. It also shows the timing (scale is not preserved) - as time goes by, each scanline is displayed from the left to the right. First VSCROL must contain 13 decimal (it's a 4-bit register, so high nibble of value written to $d405 may be anything). As soon as ANTIC loads DCTR with this value, first line of mode is guaranteed to be displayed correctly. Then the second line will be shown and only near the end of last scanline VSCROL is required to contain 3. So we have much time to write 3 to VSCROL. We may do it e.g. on DLI in the first line. It's much worse with preparing to display third line of mode. As you see on the picture ('#') there's little time to put 13 into VSCROL (just a few cycles). Quote Link to comment Share on other sites More sharing options...
Bennet Posted June 2, 2006 Author Share Posted June 2, 2006 (edited) is this somehow "standard" or does this depend on your researches? It makes sense to me. but the formatting makes it very hard to read here. Any way to edit out those extra line breaks? It looks like the file came from an Atari! Sounds like it's saying how you can make Antic display multiple lines of Mode F? (or any other mode) by setting VCTR to an invalid value through scrolling. Based on the internal workings I've seen this is to be expected. Edited June 2, 2006 by Bennet Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 10, 2006 Share Posted June 10, 2006 Another attribute, although possibly not useful: If you disable screen DMA by setting just bits 0,1 of DMACTL to 0 (ie- still allow DLIST DMA) on a badline, ANTIC doesn't fetch character codes. As shown, it reuses what it has buffered. This screen is just a single DLI which does WSYNC, clear bits 0,1, WSYNC again and enable widescreen. Since the first line of the widescreen didn't do character fetches, it reuses the line above's characters (although only 40 were fetched). The extra characters to the right are buffered from the last line displayed (ie - previous frame, with VBLANK and several normal lines displayed subsequently). Quote Link to comment Share on other sites More sharing options...
Bennet Posted June 12, 2006 Author Share Posted June 12, 2006 Another attribute, although possibly not useful: Very useful! I never tested this myself, but what you did shows that the Antic's does not start counting through video memory always at the start of wide, it starts when the playfield starts. As in, if the numerical character values lined up vertically it would mean it always start at wide, and they don't. Is there a way to see what happens if you switch off the DMA mid-scanlile? Or on scanline 4 of the character mode to see if it stops fetching character graphics for the remaining lines? (or if it simply grabs bus noise) Quote Link to comment Share on other sites More sharing options...
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.