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

[Rybags]

REFRESH2.zip

 

Here's another Refresh killer. Tried to make it more severe, but my machine doesn't seem to mind it.

Entire 240 scanlines are badlines in GR.0, and the screen will probably roll.

Sits in a tight loop - VBlank does nothing except set the Dlist pointer back.

Screen just rereads the same RAM area, the one containing the DLI.

Display List is rather big, so quite a bit of various RAM access there.

 

I'm thinking if this will work, maybe it needs an NTSC machine since it has a lot less free scanlines beside the 240 displayed (22 vs 72). And, possibly an older 400/800 at that.

 

I looked up a datasheet on 4164 RAMs (as used on some XEs). Seems that they require all rows refreshed every 2 ms.

That would translate to 10 times per PAL frame, or approx. once every 31 scanlines.

 

Normally there would be about 250 refresh cycles in that time period - my program reduces that to just 31.

[Rybags]

Thanks, 1050 - I missed your post as I was just typing that lot in...

 

Yes, I checked some schematics over earlier and worked out the CAS/RAS thing to an extent.

 

That's why I compacted the program a bit so that it only used short routines and in a small area (although the Dlist is rather huge).

 

I'm thinking here maybe the LSB of the address is the row?

 

Two reasons I'm thinking this:

1. More likely to "hit" rows often during normal machine operation.

2. Spread the load? Constant changing rows would probably mean slightly cooler silicon?

[1050]

Thanks, 1050 - I missed your post as I was just typing that lot in...

You are welcome, Rybags

 

I'm thinking here maybe the LSB of the address is the row?

My opinion is, I really want it to be like that, but I can't figure out how to make the horsey go there from here. It looks like to me that if ANTIC moves it's refresh counter in a 1, 2, 3, manner at some point the row won't change but I really don't know what's inside ANTIC let alone how it all works - I'm just trying to marry what I glean from data sheets with what I can verify under the hood of my XL which is too darn little to be of much use. First I need a really good long sample of the actual refresh clock, like maybe a 1,000 cycles of it and I've only seen snipets of it. And I don't even understand the snipets.

 

Two reasons I'm thinking this:

1. More likely to "hit" rows often during normal machine operation.

2. Spread the load? Constant changing rows would probably mean slightly cooler silicon?

1) If by normal you mean any non-refresh mode, data fetch or store then no, I don't think so. Normal operations should NEVER be relied upon to refresh the memory even though it does refresh that particular row. As I understand it, the entire 64k of 800XL memory is refreshed using refresh cycles.

 

2) I never considered cooler silicon as a part of the picture at all, but the need to cover all the rows asap is vital. But the coverage can't be haphazard as that might let one linger too long and the data in it go bad from unuse.

 

Unless ANTIC's RAM address counter is designed to use the standard address mux pattern to hit all the rows 1, 2, 3, ect., I just can't figure it out in my head. But maybe that's just me. In the middle of all this, it is the refresh clock driving the MMU and not the phase 2 clock, so that just adds to my mental requirements of what the refresh clock needs to be. Like I said, my horsey is stuck and won't go. Thanks for the interesting disscussion guys - I think I'm out?

[Rybags]

Confused a bit here too...

 

but bottom line - that program eliminates about 216x8 = 1728 refresh cycles per frame.

 

Add to that the program is tightened down, and the only other accesses happening are a brief part of the VBlank Stage 1, and DList accesses.

Thinking here that maybe the more modern tech in my 130XE means it needs less refreshes?

 

Another thing about RAM - supposedly it "remembers" it's contents much better in cold conditions. Maybe if I run this program again in the middle of next Summer's heat, the results might be different.

 

Anyways - I guess this whole thing is a bit off-topic anyway. Maybe we'd be better off playing around with HSCROL, DMACTL and GPRIOR, and see if there's some hidden magic waiting there.