$d400 inline changes - inspired by $d011 triggering... ;)

[Heaven/TQA]

ok... I only have Atari800win here so I can not check it on real hardware but did ever anybody triggered $d400 midline? I haven't checked the specs or the timings of the Antic/Gtia but just hammered this little flickering (beware!) test together... it was inspired by C64 guys triggering stuff at cycle exact position. so I haven't cared regarding badlines and borders... but I hope you get it...

 

any demo which does $d400 midline changes? (do do not mean triggering the PRIOR register (f.e. Joyride credits part, Visdom II)

 

does this work on real hardware?

 

I want to do things like the Intro of Deus Ex Machina (c64)

 

 

ps. dedicated to Graham/Oxyron

d400.zip

[Rybags]

Yes. Can't say whether it would be of any use, though.

 

If you disable screen DMA, e.g. during the first scanline of a text mode, then Antic will reuse what existing character values are in the buffer.

 

Fairly sure it works on a cycle-exact basis, not just at the start of a scanline. I predominantly played around with DMACTL on the fly to see if I could produce a stable display with 240 scanlines of hires.

 

Also, I do believe if you disable DList Instruction fetch, it will just continue using whatever it already has in the Antic IR. e.g. you could in theory do a GR. 0 screen with 6 bytes (3 x blanks, LMS Mode 2). Of course, you then need to trigger an interrupt near the bottom of screen if you want a border.

 

PMGs - no idea, haven't bothered playing with that on the fly. I guess in a situation where you have DLIs anyway you might choose to disable PMG DMA at the top of screen, which gives you some cycles saved.

 

Wide/narrow/standard display. I think I've played with that a little. Similar case as before - Antic retains previous characters in it's buffer so they get reused in such case that the char values can't be fetched.

 

One thing I haven't tried - disable DList DMA just after a DLI instruction - does the DLI keep occurring?

 

One thing I found out - not quite related to this, but you can enable GRACTL in GTIA (value 3) to let it snoop the bus for PMG data (as normally you do). Disable PMG data on Antic. GTIA will now display whatever data is on the bus instead of what Antic is normally giving to it.

 

In such case that PMG DMA isn't enabled - Antic uses at least one of those cycles to fetch the Display List instruction.

[Heaven/TQA]

Rybags... haven thought yet exactly what you can do with $d400 midline... my idea was not using PMs to cover the screen but simply switch it off...

 

I mean... the c64 guys always do cycle exact $d011 triggering to open borders, sprites etc but I feeel that on Atari side we do not have discovered all this kind of things... usefull or not...depends on the creative use of them...

 

i can only remember the standard "midline" changes

 

- colours

- repositioning of sprites

- GPRIOR

 

the only cycle exact thing is the mode9++ for using vscroll & internal cache for doubling scanlines but that's all...

Edited April 26, 2008 by Heaven/TQA

[Rybags]

You never know - there might be some secrets or useful bugs waiting to be uncovered...

 

Good chance too that it might also involve some playing around with HSCROL on the fly too. Maybe there's some new "super-stretch" screen mode with 400+ pixels across to be discovered.

 

Equal chance that it might produce nothing of use.

 

I know that I was able, on the real machine only, to get GTIA to produce the "GR. 15-like mode" from the word go on a scanline. The useful value there is to mix hires (or GTIA mode) and multicolour on alternate scanlines in a text mode.

[Rybags]

Should add:

 

when playing around with graphics on a real machine, a good Capture card comes in really handy, as it shows everything, including all the overscan areas.

[analmux]

Well, maybe you remember Heaven, from almost 5 years ago? There's a similar trick with $d404 (hscrol). Just do a kernel of f.e. 64 scanlines, and then write 0 to $d404, do 3 or 4 NOPs and write 3 to $d404. The effect is useless but it looks very interesting.

 

Remember these piccy's?

[perry_m]

I did some experiments with cycle-exact DMACTL and HSCROL a while ago. There is some code in atari800 to handle some of these cases.

 

What I found was that if you change the screen width in certain critical areas in the border area you can get some strange effects. For example in antic mode 2 there could be a whole line of the same colour depending on whether the last character of the previous line was set to inverse video. Another effect was in antic mode 6/7 you could get a scanline where the colour of the pixels changed every 4 pixels rather than every 8 pixels, and the character graphics got reloaded every 4 pixels as well, so the graphics got combined with rest of the previous character.

 

I didn't find any useful effects however.

 

It is a pity we do not have the internal schematics of the ANTIC chip because this would make it easy to figure out how these modes work. I was trying to work out a theory of how it worked but I didn't finish it.

 

Basically I think there is an internal counter that sets the start/end of the screen, depending on DMACTL width. If you fiddle with the width in the critcal left hand area you can do things like starting the display twice. This causes the mode 6/7 glitch, I think. And if you do things on the right hand side you can leave the screen display "on" for the next line. This seems to cause the mode 2 glitch.

 

Internally there are some counters that ANTIC uses to determine when to fetch things. DRAM refresh always occurs on 9 particular cycles, unless preempted. If it is preempted, a flag is set and the next avaiable cycle is used. So there is always one cycle of refresh, even during a "badline."

 

For fetching data, the mode 6/7 glitch says something about how this works. I was thinking of something like a shift register being used, which gets loaded with 0001 and shifts 4 times to make 1 fetch cycle. If you load it twice maybe it has 0101 and fetches twice as often.

[Heaven/TQA]

really 5 years passed by? Jesus

 

seriously... there must be some effects which might be usefull like the 40x40... or is the vic2 c64 simply "badly" designed that it leaves holes where you can play with it?

 

but interesting that there are people who played around with it already... but we should open a thread or use this like the "hardsynth" one... but still makes only sense when atari800win is cycle exact enough and emulates the internals correct...

[Heaven/TQA]

http://www.freepatentsonline.com/4296476.html

[Heaven/TQA]

internal timings:

 

http://krap.pl/mirrorz/atari/www.beipmu.co...tic_Timings.txt

The_inner_workings_of_Antic.pdf

Edited April 26, 2008 by Heaven/TQA

[Heaven/TQA]

anorther antic doc

 

http://krap.pl/mirrorz/atari/homepage.ntlw...ri_hw/antic.htm

[Heaven/TQA]

can someone explain me little bit the chart?

 

why is hscrol incremented in 2 steps?

 

on badlines it says CGCGCGCG... ok understood that antic fetches char and then the data but this must remain in the internal buffer as in next line it does not fetch the C anymore but of course the G...

 

and why does R appear only on the left side of the screen? (btw. that was the reason why midline changes on "NOP" basis differ on the left & right half?)

[Rybags]

That's the nature of the beast, I suppose. Refresh cycles aren't symetric when looked at on a scanline basis.

 

I suppose the reasoning might have been to allow DLIs to function with less impedement. By doing almost all of the refresh cycles early in the display, it leaves more cycles free for the DLI, once triggered, to be serviced. If you check the official hardware docs, the actual DLI trigger occurs fairly early in a scanline. But, the 6502 must first finish execution of it's current instruction, then you have to contend with the delays of pushing stuff to the stack, and a couple of refresh cycles, before the OS or user routine gets control.

 

Also, the reckoning in the early days was that programmers would want to do all their screen-related register changes offscreen, so it leaves most of those cycles free.

Of course these days we see it as an annoyance because it makes doing mid-screen changes at near pixel level resolution somewhat harder.

 

Finally, I guess that most of the chosen cycles will always be within the display area, regardless of what screen width is selected, or the value of HSCROL. I'm not totally sure of how it works, but screen DMA "pre-emting" lost refresh cycles on badlines (I think) in some way makes up for some of the lost refresh cycles.

 

I think Atari might have been overly cautious with the number of refresh cycles it does - compare it to the number the C-64 performs. Although we are talking 3-4 years difference in RAM technology so improvements in DRAM obviously occurred over that time.

 

The chart, and increment of HSCROL. I'd assume here that HSCROL=1 has the exact same DMA patterns as HSCROL=0. Probably true since ANTIC changes the data it sends to GTIA twice per machine cycle. Odd values just make ANTIC delay things by the half-cycle. Even values delay DMA by a full cycle.

 

The chart also seems to imply that Antic only does enough DMA in widescreen mode to satisfy the requirements for what needs to be displayed (remembering that you never see a full 384 pixel display).

 

 

One thing I'm interested in trying: See if you can get the Atari to "forget" what's in RAM. By using VSCROL tricks, you should be able to force badlines for the entire display duration. As such, you could eliminate probably 90% of refresh cycle accesses.

Edited April 27, 2008 by Rybags

[Heaven/TQA]

Rybags, as i am not a engineer and not a hardware guy for what does ANTIC do this RAM refreshes?

[Rybags]

There's a few good articles on Dynamic RAM around.

 

I'm not 100% on the theory myself, but over time the capacitors lose voltage and eventually can "forget" the information.

A refresh cycle tells every address on that row to output it's data and refresh the charge.

 

Depending on the type of DRAM, you have a certain timeframe that a row must be refreshed within. Even modern machines have this requirement with most RAM used.

The exception is Static RAM, but it's still way expensive over DRAM, so you only really see it within small caches and on devices which really need it.

 

The row/column arrangement varies, but I believe with the Atari, the rows translate directly to the MSB of the address.

Both old and modern machines tend to be over-engineered in the refresh department, but I guess it's best to be safe - a single dropped bit could be catasrophic for a machine's reliability.

Some time ago I toyed with modifying refresh rates on a VIA chipset - you can increase the period a bit but it gets to a certain point where the machine just crashes.

 

That's why the Atari 130XE needed a different Antic - the older design only rotated through 8 rows, the newer one does 9 (might be wrong here, but that's my understanding).

[Rybags]

REFRESH.zip

 

So much for supressing the RAM Refresh.

 

This program (LOAD in BASIC) generates 230 or so lines of GR. 0, and uses a DLI to force badlines on every single one.

 

Therefore, the number of refreshes Antic performs per frame should be drastically reduced.

 

Had it running on my 130XE for >15 minutes - no funny business happened, no flipped bits that I could find in RAM.

[peteym5]

I am entirely sure what this technique will really do. Does a really weird flicker from what I can tell. Would be cool if something did open up more time for a DLI considering the first thing you have to do is save your registers and restore them when done.

[Rybags]

Here's a thought - maybe try enabling/disabling screen DMA on a line in conjunction with GPRIOR changes.

 

Maybe a different result from the current known could be achieved?

 

Re the refresh thing - I left it running all night but nothing spectacular happened.

 

Probably the RAM they used in later machines needed less refresh cycles than the older stuff.

 

Can someone test the program I previously posted on a 400/800 with original RAM?

[Oswald]

REFRESH.zip

 

So much for supressing the RAM Refresh.

 

This program (LOAD in BASIC) generates 230 or so lines of GR. 0, and uses a DLI to force badlines on every single one.

 

Therefore, the number of refreshes Antic performs per frame should be drastically reduced.

 

Had it running on my 130XE for >15 minutes - no funny business happened, no flipped bits that I could find in RAM.

 

the type of RAM does make a difference aswell. here's a little story: on my c128 I have used the 80 column video chip's 64k RAM as a 2nd bank in c64 mode. (in c64 mode you cant acces the 2nd 64k of the c128 but you see the 80col chip and can access its own RAM). Now, this extra ram can not be banked in, it has to be swapped 'by hand' through 2 registers. To speed up the process I've found I can set the RAM refreshes freq. of this chip to the lowest value (yes its changeable), and have the ram contents still stable. Now at some point I have managed to kill these RAMS, they were replaced. From that point I kept loosing RAM contents with lowest refresh rate.

 

also some c64 effects effectively changes the RAM refresh timings, and they simply not run on all c64s.

[frogstar_robot]

Now at some point I have managed to kill these RAMS, they were replaced. From that point I kept loosing RAM contents with lowest refresh rate.

 

Back in the 80s, one of the Atari magazines, Antic I think it was, ran a gag article called PaperWeight with type in program. This program purported to trigger a "self-destruct" register that Atari had supposedly embedded should they need to dispose of some A8s ET-style. All it did was throw up an "April Fool!" type gag.

 

This suggests a way to do it for real .

[Bryan]

Rybags, as i am not a engineer and not a hardware guy for what does ANTIC do this RAM refreshes?

Dynamic RAM is much cheaper than Static RAM, but it forgets its contents if cells aren't refreshed at regular intervals, like a leaky cup. You don't have to actually re-write the contents, since the chips have circuitry to do most of the work. You just have to give them the spare cycles (and a row address). I'm sure the refresh scheme was designed for worst-case DRAM, and on most machines you could use fewer refresh cycles if you could take control of it.

 

-Bry

[Fröhn]

REFRESH.zip

 

So much for supressing the RAM Refresh.

 

This program (LOAD in BASIC) generates 230 or so lines of GR. 0, and uses a DLI to force badlines on every single one.

 

Therefore, the number of refreshes Antic performs per frame should be drastically reduced.

 

Had it running on my 130XE for >15 minutes - no funny business happened, no flipped bits that I could find in RAM.

 

the type of RAM does make a difference aswell. here's a little story: on my c128 I have used the 80 column video chip's 64k RAM as a 2nd bank in c64 mode. (in c64 mode you cant acces the 2nd 64k of the c128 but you see the 80col chip and can access its own RAM). Now, this extra ram can not be banked in, it has to be swapped 'by hand' through 2 registers. To speed up the process I've found I can set the RAM refreshes freq. of this chip to the lowest value (yes its changeable), and have the ram contents still stable. Now at some point I have managed to kill these RAMS, they were replaced. From that point I kept loosing RAM contents with lowest refresh rate.

 

also some c64 effects effectively changes the RAM refresh timings, and they simply not run on all c64s.

The normal bitmap display already refreshes the RAM. You only lose RAM contents in memory rows which do not get accessed for a while.

[Rybags]

I guess it might come down to how the rows are mapped.

I assumed that they would just correspond to the high byte of the address.

 

Maybe I'll have to try harder - possibly a display list that just reuses the same 40 byte area of RAM for every single line.

And, lock down the machine a bit more. Disable interrupts and just run in a tight loop.

[Rybags]

<double post>

 

Stupid interweb.

Edited April 30, 2008 by Rybags

[1050]

I guess it might come down to how the rows are mapped.

I assumed that they would just correspond to the high byte of the address.

There is a design "trick" used on the XL where the machine's address lines are matched in pairs going into the RAM's address mutliplexers. A8 is matched with A0, A9 with A1, A10 with A2 such that any change in an address results in a different row (and column?) being refreshed as long as ANTIC keeps changing the refresh address for each refresh cycle issued as the general theory says it does. That counter is not available for tinkering with as it's all internal to ANTIC. I don't see a way to do what you are wanting to do with that bit of business in the way. Freddie does something similar but just how I've not a clue. That Address line matching rule is like the third line in RAM bibles (data sheets and application notes) from day one, under the heading of how to effectively refresh RAM. One apparently can't do it right without the matching in other words, so I've come to expect it everywhere.

 

The RAM's address mutliplexers are two 74LS158 logic chips that 'swap' four pairs of inputs to four outputs on the phase 2 clock transition and thus generate first the RAS address and then the CAS address onto the RAM's address lines A0 thru A7. So for RAS on the RAM's A0 line, the machines's A8 is used and for CAS, the machines's A0 is used because of the matching outlined above. I might have it backwards (RAS A0-A0 and CAS A8-A0) but the basic idea remains the same. The RAM's A7 line winds up being multiplexed out of the machine's A15 and A7 lines to round out this explaination which I hope makes some sense. The scheme of which is to make a new RAS address out of each and every incrementing or decrementing address that ANTIC uses during it's refresh cycles. So then the only way DRAM memory can fail us is to not run enough refresh cycles in a given amount of time. I'm thinking the bar is just set too high, let's face it - she's just too well built all around.