emkay Posted August 12, 2003 Share Posted August 12, 2003 Pleas take note: With the PM-Multiplexing you can set proper 8bit Colorblocks in the "slower" first half and before the DMA Line... In the last "faster" half you can set the Player positions and Player colors new for "this line" and the next line too. And you will have time to change other colors though... Only Handycap is the DMA Line which does not allow viewable changes. But this line can be "bridged" by PM-Blocks and the Charmode itself... .... 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 Supplemental Contrary .... it seems you will get closer to my MCS(++) Idea.... Here are some more ideas: Using Gr.0 not Gr.12 (Antic 2 instead of 4)... You can active handle the PRIOR Settings and create a ADMIRANDUS-like Screen with graphics and Hires Text... for a Club magazine in DTP Style... By using of charmode you would have to switch line 0 to a GTIA Mode. And no one will recognize it by a Charset that does not use line 0..... So you can create a screen with Hires Text and 256 color Graphicsmode, or MCS Style graphics... or Hires/color interleave pictures etc. etc. etc. ... side a side .... or you can create Screens for games like the last ninja with "endless" colors.... Link to comment Share on other sites More sharing options...
analmux Posted August 12, 2003 Share Posted August 12, 2003 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... Well, the atariscreen is indeed 114 clockcycles per scanline, but normal graphics AND textmode fontdata already steal 40 cycles. When screendata in textmode is read, another 40 cycles are stolen, so: first line of char.mode gives us 114-80=34 cycles other seven lines give us 114-40=74 cycles and then you have to subtract the number of cycles stolen by refresh and PM data and DL data fetch. (another (max.) 17 cycles) It's far worse than you think. -------- 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. Well, there is no way Antic can send aditional color information to GTIA when a TIP (GTIAbug) line is drawn. It contains too much data to be sent from Antic, so the only way is that GTIA has a buffer too. Antic --> GTIA communication is established at twice the CPU clock speed (colorclocks). And only 3 bits are sent in one colorclock, while TIP mode would need more bits per colorclock, so there is no way. All together Antic sends no COLOR-information, but only playfield information. AND in TIP mode you don't screw up Antic but GTIA by writing multiple times per scanline to register GPRIOR which is clearly a GTIA register!! Link to comment Share on other sites More sharing options...
Bryan Posted August 12, 2003 Share Posted August 12, 2003 Well, there is no way Antic can send aditional color information to GTIA when a TIP (GTIAbug) line is drawn. It contains too much data to be sent from Antic, so the only way is that GTIA has a buffer too. I'm just saying look at the Antic and GTIA datasheets. Antic is said to have a shift register that can hold up to 48 characters, and a line buffer. GTIA doesn't have one mentioned, nor does it have one visible in the schematic. I've seen TIP, but what does it do that requires more bandwidth than usual? I'll go read up on it if you point me in the right direction (maybe Heaven's site?) -Bry Link to comment Share on other sites More sharing options...
emkay Posted August 12, 2003 Share Posted August 12, 2003 first line of char.mode gives us 114-80=34 cycles other seven lines give us 114-40=74 cycles You are wrong. Fullscreen Antic 4 does stop out the CPU about 4% more than standard ANTIC e or f The 4% is a resulting of the 960 Char-positions more to read and the smaller DList compared to antic e PM cost the same on Antic 4 or e ANTIC stores the Screen-bytes and reads the charmem when on antic e the linear buffer is read. In addition, the Charmode never must use more than 4K. Once again: The C64 has to do everytime DMA for 40chars in 25 charmode lines + color-data. Only if the VIC would read in 16Bit words, it would have an advantage compared to ANTIC that reads allways bytes per cycles. Link to comment Share on other sites More sharing options...
emkay Posted August 12, 2003 Share Posted August 12, 2003 Please remember: 12 colorchanges by INX STA $$$$,x (7 cycles) are already 84 cycles .GED switches 14 colors in the viewable area of a scanline and Heavens "Kernal" has additional 28 Cycles... Heaven : Would you try to explain the 5 cycles? Did you try the Kernal in page 0 ? Link to comment Share on other sites More sharing options...
emkay Posted August 12, 2003 Share Posted August 12, 2003 OK a LDA # STA $$$$ uses 6 cycles... 6x12=72 But how is to count on the XASM routines? Link to comment Share on other sites More sharing options...
analmux Posted August 12, 2003 Share Posted August 12, 2003 first line of char.mode gives us 114-80=34 cycles other seven lines give us 114-40=74 cycles You are wrong..... Don't contradict me. A scanline consist of 228 colorclocks, thus 114 cycles. I'm 100% sure that in a charmode like Antic 2 or 4 EVERY scanline takes away 40 cycles and the screendata-line takes additional 40 cycles, so the difference is 12.5 % (=9/8). The 7 dlist commands that are not used in charmodes 2/4 don't have a significant contribution. Take a look at the next post. Link to comment Share on other sites More sharing options...
analmux Posted August 12, 2003 Share Posted August 12, 2003 <> [/img] Link to comment Share on other sites More sharing options...
emkay Posted August 12, 2003 Share Posted August 12, 2003 Analmux I know already the difference of 4% between charmode and graphicsmode and there is nothing to doubt about! Link to comment Share on other sites More sharing options...
analmux Posted August 12, 2003 Share Posted August 12, 2003 As I promised, I would make some digipics of the atariscreen when connecting the pins GTIA-lum2 to Antic-Halt with a cable. The black areas are the places on screen where a Halt signal takes place. Picture 1/2/3: In the upper (se. 4,0,12) border you clearly see the 9 refresh cycles on PM positions 48,56,64,72,80,88,96,104 and 112, this means that memory is refreshed at the time-intervals in which the TV-electronbeam draws the darker vertical bands. Refresh happens on the left side. When antic reads charmode lines (antic mode 2) it steals 80 cycles, and no refresh takes place. You can see this in every first scanline of a charmode-row. In the other 7 scanlines it takes away 49 cycles (40 character data + 9 refresh). The lighter areas show the available CPU-cycles. It's also visible that (like I said before) GTIA has a retardation compared to Antic. The Halts take place one cycle before Antic needs memory access. Then it has to shift the data in its shift-register, to send the bitpatterns via the ANx-lines to GTIA. That's why you see the halts stop two or three characters form the right screenborder. Picture 4/5: Here I connected addressbus 0 (picture 4) and addressbus 1 (picture 5) to GTIA lum 2. Again, you can see the 9 refresh bands in the upper border, but now you can see a bit of busactivity. You see the address-counting for refreshing consecutive RAM-blocks. In the rest of the screen you also see the memory access of antic for screendata etc. Picture 6: The upper chip is the Antic, the lower chip is GTIA. Here Lum 2 and Halt are connected with a cable. I recommend not to try this yourself. You might destroy electronic components. --------- analmux Link to comment Share on other sites More sharing options...
analmux Posted August 12, 2003 Share Posted August 12, 2003 O.k. Let's compare antic 4 with antic E antic 4: 1 (dlist instruction) + 80 (screendata + fontdata) + 7 * (40 + 9) = 424 cycles antic E: 8 (dlist instructions) + 8 * (40 + 9) = 400 424/400=1.06 so it's 6 % !!!! (the other way round: 400/424=0.943 is 5.7 %) I don't now if there are (after this) other cycles stolen. Link to comment Share on other sites More sharing options...
emkay Posted August 12, 2003 Share Posted August 12, 2003 Another ground to calculate on: TV lines are counted on 262 thus: 1,79MHz/60/262=114 NTSC 1,77MHz/50/262=135 PAL Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 13, 2003 Share Posted August 13, 2003 well... the last time i calculated cycles was somewhere 1991... so please forgive me in the "5 cycle" bug... of course lda 2, sta abs, 4 cycles... ergo 6... i never was good in maths... that's why i am working in the marketing department and not in the engineering... we are used to "go creative with reality"... i'll check this hardware modification to see the "GPU" working... hve Link to comment Share on other sites More sharing options...
Heaven/TQA Posted August 13, 2003 Share Posted August 13, 2003 @ mux seems hot in netherlands as well... as the last pic shows... stupid question...does your modification has any implication on the hardware except visible stuff? f.e. does it slows down the CPU or the GTIA or ANTIC? just thinking... hve Link to comment Share on other sites More sharing options...
analmux Posted August 13, 2003 Share Posted August 13, 2003 Emkay No, every rasterline is exactly 114 cycles. A Pal (50 Hz = Europe) screen counts 314 or 312 rasterlines and a NTSC (60 Hz = America) screen counts 262 rasterlines. I still don't get how you computed that 4%. I'm very curious. (Although I didn't mention the extra CPU time in the Vertical Blank period etc.) Link to comment Share on other sites More sharing options...
analmux Posted August 13, 2003 Share Posted August 13, 2003 @ mux seems hot in netherlands as well... as the last pic shows... stupid question...does your modification has any implication on the hardware except visible stuff? f.e. does it slows down the CPU or the GTIA or ANTIC? just thinking... hve Yes, very hot.... I never thought about that, but it could be that CPU is halted when LUM2 output of GTIA is low (f.e. when it shows a setcolor 4,0,8 or 4,1,0) so the CPU might be slowed down. Antic has main buscontrol, so isn't slowed down. GTIA doesn't access the bus at all (just waits for some pokes), or looks for PM data at certain times (that's why you see flickering blocks of PM when PM-DMA is off, it's just CPU bus activity you can see then). But in this case all setcolors have the LUM2-bit on, so additional Halts don't occur. --------------- There is some light in the darkness. Not every CPU cycle is used for memory access. For example a CLC instrution takes 1 cycle to read the mnemonic from memory and another cycle to clear the CarryFlag. This could be done when in the meantime Antic accesses the memory, so some instructions seem to be faster in DMA modes. Think about a PLA instruction. It takes 4 cycles. 1 for the instruction read 1 for stack read 2 additional for whatever Link to comment Share on other sites More sharing options...
emkay Posted August 13, 2003 Share Posted August 13, 2003 Emkay No, every rasterline is exactly 114 cycles. A Pal (50 Hz = Europe) screen counts 314 or 312 rasterlines and a NTSC (60 Hz = America) screen counts 262 rasterlines. I still don't get how you computed that 4%. I'm very curious. (Although I didn't mention the extra CPU time in the Vertical Blank period etc.) Simple: Swith off interrupts and build a calculating program... With Antic 2 or 4 the program runs 4% slower than on Antic e or f BTW: Heaven's DLI uses around 108 cycles and he uses WSYNC though. How does that fit into 114-40 cycles? Link to comment Share on other sites More sharing options...
analmux Posted August 13, 2003 Share Posted August 13, 2003 BTW: Heaven's DLI uses around 108 cycles and he uses WSYNC though.How does that fit into 114-40 cycles? Isn't it because he turned off the screen (poke 559,0) so antic doesn't steal the cycles? Link to comment Share on other sites More sharing options...
analmux Posted August 13, 2003 Share Posted August 13, 2003 Simple: Swith off interrupts and build a calculating program... With Antic 2 or 4 the program runs 4% slower than on Antic e or f Could it be that your counting program used instructions that do not use EVERY cycle for memory access? Like I said a few posts back, there are certain instructions that take more clockcycles than they access memory (PLA, CLC etc.) Link to comment Share on other sites More sharing options...
emkay Posted August 13, 2003 Share Posted August 13, 2003 BTW: Heaven's DLI uses around 108 cycles and he uses WSYNC though.How does that fit into 114-40 cycles? Isn't it because he turned off the screen (poke 559,0) so antic doesn't steal the cycles? 559 is at #34 .... Link to comment Share on other sites More sharing options...
emkay Posted August 13, 2003 Share Posted August 13, 2003 Alike if there is more or less cycle stealing... The c64 is allways the slower machine... But programs like the fullscreen rotozoomer are not done by counting cycles, just by coding the routines on the available hardware... And, without sprites and by using only 4 color bitmap for this, the C64 can in no way take advantage by the VIC to do this.... Link to comment Share on other sites More sharing options...
analmux Posted August 13, 2003 Share Posted August 13, 2003 559 is at #34 That's right, but look at this: dlist dta b($70,$70,$c0,$41) dta a(dlist) org $2e0 dta a(start) The Dlist doesn't read any graphics data!!! the DLI is activated in the $co instruction, and then $41 which means wait till VBlank. Link to comment Share on other sites More sharing options...
emkay Posted August 13, 2003 Share Posted August 13, 2003 Here you can see how wide a bar is with DMA activated. The bar of a GTIA Mode mid-scanline is exactly as wide as the Bars in Heavens program... Link to comment Share on other sites More sharing options...
analmux Posted August 13, 2003 Share Posted August 13, 2003 That's a nice picture. It's something a C64 can't do 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.