ANTIC REF (Refresh) output.....is it any use ?

[Level42]

With my tinkering with ANTICs I happened to discover that it _seems_ that my 800XL board works happily even if the REF pin is not connected to the motherboard.....

 

It is hooked up to the MMU though normally so......what good is it ? Am I just lucky that the DRAMs are keeping their memory active enough ?

[Kyle22]

If I am reading you correctly, what you have done will result in the RAM remembering recent data and forgetting areas that haven't been accessed in a while.

 

It is a BAD idea. Just like with the RAMbo XL and others. Some people didn't replace the C012296 ANTIC with the C021697 (21698 in PAL land). It looks like it works for a while, but you will get strange crashes and glitches.

 

You can only disable refresh if you have all Static RAM. Dynamic RAM must be refreshed.

[Rybags]

From the MMU point of view, fairly sure REF just instructs it to not select any ROM or IO space.

 

I suspect that by taking that signal away you're probably not refreshing rows of Ram that live under OS and Basic Rom.

 

400/800 passes the Ref to each memory module where it's processed. AFAIK all factory installed Ram on Atari uses the Ras only refresh method. the REF signal is also passed over PBI/ECI so external expansions can use it if needed.

[Level42]

Thanks, that's clear enough....it needs to stay

[Level42]

If I am reading you correctly, what you have done will result in the RAM remembering recent data and forgetting areas that haven't been accessed in a while.

 

It is a BAD idea. Just like with the RAMbo XL and others. Some people didn't replace the C012296 ANTIC with the C021697 (21698 in PAL land). It looks like it works for a while, but you will get strange crashes and glitches.

 

You can only disable refresh if you have all Static RAM. Dynamic RAM must be refreshed.

Kyle, coming back on this: AFAIK the only difference between the old C012296/14887 and the new C021697/8 is the refresh rate. Do I understand correctly that the older ones refresh slower than the new ones ? Wikipedia says the old ones were used in 400/800/1200XL, the newer ones in all later systems but the 800XL NTSC that i received from the US has an old type ANTiC on board. Of course there's no way to know if it was replaced at one point in time (all VLSI's socketed). But it works fine with the standard RAM.

 

(And I know Wikipedia is often not correct of course....)

 

So if this timing is only critical with later systems, why do old ANTICs still work OK in stock machines ?

 

And did problems only start when the first 3rd party RAM expansions started to surface ?

Edited November 20, 2017 by Level42

[_The Doctor__]

The timing was changed because of the different types of ram that were used and available at the time this was not for just third party modules, there were other issues as well. Combine what kyle and rybags stated with this and you end up with a pretty good picture.

Edited November 21, 2017 by _The Doctor__

[Kyle22]

I think the older ANTIC has one less bit as well.

[+kheller2]

Hmm. I thought most of it had to do with the type of RAM chips that were used. I could be very wrong about this but doesn’t the 600XL and XEGS require the newer Antic?

[Rybags]

Supposedly original Antic can be used in any machine except 130XE.

Antic from 130XE can be used in any machine... not sure if extra Refresh bit is ignored or generates no refresh. XL/XE Ram could probably work fine on half or less the refresh it actually gets anyway.

Edited November 21, 2017 by Rybags

[+bob1200xl]

RAS is Row Address Strobe - it selects one row of the array. When you select any row all the bits in that row are refreshed.

So, ANTIC has to make sure that each row is selected every so often (like every 16ms).

 

A 64K chip is set up as a 256x256 matrix, with 256 rows and 256 columns. This means that ANTIC has to raise REFRESH to the system and put an 8-bit address on the bus, selecting one of the rows for refresh. The DRAM will not use the data bus if REFRESH is active. No matter if REFRESH is not connected - the system does not care and the memory will be refreshed regardless.

 

REFRESH also de-gates all the non-memory devices (ROMs, I/O, etc.), which is also of no consequence on the 8-bit.

 

If you bump the DRAMs up to 256K chips, you need 9 bits of REFRESH to maintain your data, hence the 'new' ANTIC - 9 bits of REFRESH. 512x512 array.

 

Yes, you can probably leave REFRESH disconnected and nothing will go south. ATARI must have it in there for something, but it isn't immediately evident.

 

So, as long as you either read or refresh each row, you're OK. But, if you don't, you'll give yourself a nasty, non-obvious bug.

 

Bob

[phaeron]

I thought the refresh period requirement for the old RAM chips was a lot shorter, as low as 2ms.

 

By abusing vertical scrolling, character modes, and wide playfield width it's possible to reduce refresh to one cycle per scanline in the display region. This in turn increases the refresh interval for a row to as long as 15ms. I wonder if it's possible to induce a refresh failure in an 800 with 3x16K cards this way.

[_The Doctor__]

Row Address Select (Strobed) (RAS)
The RAS circuitry is used to latch the row address and to initiate the memory cycle. It is required at the beginning of every operation.
to enable RAS, a transition from a high voltage to a low voltage level is required. The voltage must remain low until RAS is no longer needed. During a complete memory cycle, there is a minimum amount of time that RAS must be active (tRAS), and a minimum amount of time that RAS must be inactive called the RAS precharge time (tRP).

 

RAS may also be used to trigger a refresh cycle (RAS Only Refresh, or ROR). *** There are two modes for ROR. 1) Burst- In traditional DRAM the memory controller can decide to complete all required refreshes in a burst and memory will be unavailable until all rows finish refresh or 2)Distributed- which distributes the refreshes evenly over the retention time and the memory controller is responsible for managing the rows to be refreshed and can take some time.

Column Address Select (Strobed)

(CAS) CAS is used to latch the column address and to initiate the read or write operation.
CAS may also be used to trigger a CAS before RAS refresh cycle. This refresh cycle requires CAS to be active prior to RAS and to remain active for a specified time. It is active low transistion. The memorys' specification will list the minimum amount of time CAS must remain active (tCAS) to initiate a read or write operation. For most operations, there is also a minimum amount of time that CAS must be inactive and is called the CAS prechargetime (tCP). ROR cycles do not requireCAS to be active.

 

The Atari was always designed with add on card and access to the bus in mind. You might also notice a duplication in what each chip can do in terms of counting this or doing that... It was an idea that only a handful of people took notice of, depending on what you are doing in what chip you could use the function in another that might be lest costly or even unavailable when using the chip in a certain way. The was a reference within Atari as to what our resident madman Antic could do and some function outside what you consider as normal.

 

Sadly I see no books on Antics machine language, this is a dirty shame....none of the references (internal or otherwise) have turned up.

Edited November 21, 2017 by _The Doctor__

[Rybags]

I thought the refresh period requirement for the old RAM chips was a lot shorter, as low as 2ms.

 

By abusing vertical scrolling, character modes, and wide playfield width it's possible to reduce refresh to one cycle per scanline in the display region. This in turn increases the refresh interval for a row to as long as 15ms. I wonder if it's possible to induce a refresh failure in an 800 with 3x16K cards this way.

 

I actually did a program that sets up 240 scanlines of Antic 4 badlines to kill off much of the refresh. Some people tried it (especially wanted NTSC users of older machines to try it) but couldn't get any results.

The other thing is the inadvertant refresh due to reads by CPU and Antic graphics, from memory I tried to cram everything into a small space to minimize variety of accesses.

But I do suspect that on some machines the address to row mapping is such that just a sequentially accessing program and graphics situation is sufficient to do read refreshes to many rows.

[ijor]

The newer Antic, revision E, has an 8-bit refresh counter. The older one (AFAIK, we still don't have schematics of the old release) has 7-bit.

 

The timing between refresh cycles should be the same. But because the counter has one more bit, it takes twice the time to reach each value. If the RAM chips do use 8 bits (depending on the organization it might not), that would mean each RAM row would refresh at half the frequency.

 

[+bob1200xl]

Yeah... what you said. I haven't found my books, yet.

 

Are we mixing up REFRESH with HALT? REFRESH puts out 9 cycles every scan line, even if you hold down RESET.

 

REFRESH doesn't even go to the REFRESH pin of the DRAMs, so we're not doing a 'proper' refresh.

 

There are 8 address pins on the DRAM - we only refresh 7 of them? (a 7 bit counter?)

 

Bob

[ijor]

REFRESH doesn't even go to the REFRESH pin of the DRAMs, so we're not doing a 'proper' refresh.

I'm not sure what you mean by that. There is no REFRESH pin on the DRAM chips. Refresh goes to the logic that handles RAS and CAS. If you apply RAS only, the DRAM chips would refresh the selected row.

 

There are 8 address pins on the DRAM - we only refresh 7 of them? (a 7 bit counter?)

There are 7 address pins only on the original 16 Kbit DRAM chips used in the 400/800 RAM modules. So a 7-bit refresh counter was enough then. 64 Kbit RAM chips (8 address pins) appeared on later machines and that needed the new ANTIC with an 8-bit refresh counter.

[+bob1200xl]

Pin 1 of the DRAM is REFRESH. When you assert pin 1 things happen inside the chip. Different things than RAS only. Atari never uses the REFRESH pin.

 

The 1200XL uses the same DRAM as the 800XL or XE systems. Same ANTIC in the 1200XL as in the 400/800.

 

Bob

[_The Doctor__]

since my grey matter isn't what it used to be maybe I am unclear so these should help. antic refresh is used to drive the memory control logic... things need to be synchronized.... also look up various dram pin-outs a couple examples within do and do not apply depending on the machine. Just quick google yielded pretty good results, close enough to what I laid out

 

explanations

https://www.ece.cmu.edu/~ece548/localcpy/dramop.pdf

 

http://faculty.cs.niu.edu/~berezin/463/lec/06memory/03ram01.html

 

http://archive.arstechnica.com/paedia/r/ram_guide/ram_guide.part1-4.html

 

visualizations

https://www.google.com/search?q=pin+1+of+ram+chip+refresh+ras&client=firefox-b-1&tbm=isch&tbo=u&source=univ&sa=X&ved=0ahUKEwio5rvLkdHXAhUCwYMKHV06ByIQsAQIQg&biw=1366&bih=646

Edited November 22, 2017 by _The Doctor__

[ijor]

Pin 1 of the DRAM is REFRESH. When you assert pin 1 things happen inside the chip. Different things than RAS only. Atari never uses the REFRESH pin.

 

Where do you see that? Exactly on which chip? On the old 16K and 64K chips pin 1 was either -5V, or not connected on newer single voltage chips.

 

The 1200XL uses the same DRAM as the 800XL or XE systems. Same ANTIC in the 1200XL as in the 400/800.

I see. Don't know. I would assume the 1200XL has extra logic to complement the 7-bit counter, but really don't know.

[dmsc]

Hi!

 

I actually did a program that sets up 240 scanlines of Antic 4 badlines to kill off much of the refresh. Some people tried it (especially wanted NTSC users of older machines to try it) but couldn't get any results.

The other thing is the inadvertant refresh due to reads by CPU and Antic graphics, from memory I tried to cram everything into a small space to minimize variety of accesses.

But I do suspect that on some machines the address to row mapping is such that just a sequentially accessing program and graphics situation is sufficient to do read refreshes to many rows.

From the 800XL schematic, the waveforms are like:

 

PHI2    ________________________________________________|---------------------------------------------------|______________
R/W     X|~~~|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX|~~~|XXXXXX
ADDR    A|~~~|AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA|~~~|AAAAAA

SEL     __________________|--------------------------------------------------|_____________________________________________
MA0     0|~~~~|00000000000|~|888888888888888888888888888888888888888888888888|~|00000000000000000000000000000000|~~~~|00000

/RAS    ------------|_________________________________________________________________________________________|------------
/CAS(R) ----------------------|____________________________________________________________|-------------------------------
/CAS(W) --------------------------------------------------|________________________________|-------------------------------

In the diagram, ADDR = 16bit address bus (from 6502 or Antic), SEL = select to LS158, MA0 = output of LS158, A0 to memory chips.

 

This shows that when RAS is selected (goes to low), the memory address is selected from A0 to A7, and when CAS is selected, the memory address is selected from A8 to A15.

 

So, Row address == A0:A7, Column address == A8:A15. Then, if you simply access 256 contiguous bytes in memory, you refresh all DRAM. In order to test a bad refresh situation, you should arrange screen DMA to only access the same low address in each row, and also set the CPU to execute code from those same addresses.

 

Another detail, all memory accesses generate a RAS signal (effectively refreshing the current row), only the CAS signal is inhibited on non-RAM accesses.

[Rybags]

The newer DRam types have the refresh pin but as mentioned, those chips support both types of refresh and Atari only uses Ras-only regardless.

 

A curious thing though is that the 64K machines do in fact have 8 address pins on the DRams but still work fine with the original Antic.

 

One thing re the refresh killer I want to try - do a ROM based version which could minimize Ram access to a bare minimum regardless of the fact that a sequential Ram based program would auto refresh in itself.

[ijor]

So, Row address == A0:A7, Column address == A8:A15. Then, if you simply access 256 contiguous bytes in memory, you refresh all DRAM. In order to test a bad refresh situation, you should arrange screen DMA to only access the same low address in each row, and also set the CPU to execute code from those same addresses.

 

Another detail, all memory accesses generate a RAS signal (effectively refreshing the current row), only the CAS signal is inhibited on non-RAM accesses.

 

Interesting. That would explain why refresh problems are hardly seen in practice.

 

So perhaps the 1200XL (or any machine with 64 Kbit RAM chips and the older ANTIC for that matter) is missing one bit refresh counter, but in practice it is mostly not even needed.

[_The Doctor__]

Mostly proved not to be good enough as explained before....

[Rybags]

Another consideration - contemporaries such as C64 and Plus4 only provide 5 refresh cycles per line. By the time XL was out the DRams were better and so Atari's scheme was probably at least 200% overkill.

[Level42]

I can only follow half the info here so forgive me if I sound stupid but...

 

From my o-scope measurements I seem to remember that REF is faster on the newer ANTIC than on the older, which , with my limited knowledge, feels strange as you would expect newer types (single voltage) of memory to need less refresh cycles.

 

Could it have to do with PBI appearing on the 600XL and 800XL ? Asking this because this is one of the main differences between 400/800/1200XL and 600/800XL.....Does it have to do with 1064 maybe ?

 

I will be trying an old type NTSC ANTIC in a PAL 130XE. Any suggestions for programs that really ask the most of ANTIC ? I noticed an ANTIC stress test mode in Atari's salt software but that seems to just display a static screen. Wouldn't be any of the recent demos be more of a challenge to ANTIC ?

 

[EDIT] I do assume that REF is generated in hardware on ANTIC and also automatically and independently of any software (setting) [/Edit]

 

Apart from that i wonder if any of the RAM test programs would notice if I would lift out the REF pin out of the socket....

Edited November 22, 2017 by Level42