| |
Krill
Registered: Apr 2002
Posts: 2940 |
$D016 bit 5
There is this mysterious bit early on in the KERNAL reset routine:
FCEF: 8E 16 D0 STX $D016 ; VIC: Control Register 2 with X being anything in [0..5].
Now, some people [who?] claim that without this store to $d016, some [which?] cartridges won't start [citation needed].
However, $D016 apparently used to have a mysterious "reset bit" in supposedly early VIC-II revisions (those with only 5 not 9 luma steps, and then the early ones of those).
| Bit 5 | Reset-Bit: 1 = Stop VIC (no Video Out, no RAM |
| | refresh, no bus access) | Could this be the reason why some things on some machines (?) won't start without that store to $D016?
Do any machines still exist where setting $D016 to, say, $f8 would crash them (when running code from RAM)?
Or did this "reset bit" never exist? =) |
|
... 66 posts hidden. Click here to view all posts....
|
| |
Martin Piper
Registered: Nov 2007
Posts: 699 |
Quote: Just read the article :)
The article confirms it's a bad **refresh**, it shows why you're wrong to claim it's not refresh related. You do know that DRAM refresh (good or bad) can happen outside of the normal scheduled refresh slots, right? |
| |
Martin Piper
Registered: Nov 2007
Posts: 699 |
Quote: Quoting GroepazQuote:Incorrect, see "In short, one memory cell gets refreshed with the bit value of a different memory cell."
You didn't understand the article. Its a ras/cas timing violation. Also see the first paragraph. I agree with Groepaz. Root cause is VSP triggers a timing violation. Downstream this causes a metastability condition in the refresh logic as some number of RAS bits can't drop to zero quickly enough before they're latched so the readout in downstream logic will flicker unpredictably. Depending on process variations in the VIC-II silicon lottery coupled with temperature/phase/whatever conditions, congratulations, you may experience the VSP bug.
If someone cuts the brake lines on your car and you crash into a tree, the prosecuting attorney (and insurance agency!) doesn't point fingers at the tree. :-)
" in the refresh logic "
Means it is **refresh** related. Just because it's unexpected or undesired, doesn't mean it's not refresh related. |
| |
Martin Piper
Registered: Nov 2007
Posts: 699 |
Quote: while we're at it, someone could enlighten me how is this ram refresh is done ? I mean like ram bus is 2mhz, where is the extra time VIC has access to the ram ? is this done by reading the contents? etc
The VIC handles the refresh of five 8-bit row addresses every raster line, regardless of the screen enable flag. This means, on the 6567, it refreshes all the rows it needs to within the maximum allowed refresh time. This guarantees just over 2ms to refresh the same row address in a 128 refresh scheme, the maximum delay is just over 3.6ms for a 256 address refresh scheme.
This refresh happens in phase 1 of the clock, whereas the CPU operates in phase 2. The CPU only requires the system bus during the phase 2 clock high part of the clock cycle.
The 6567 normally grabs data during phase 1 cycles, so it doesn't block the CPU, you can think of this as the normal "slow" rate of memory access by the VIC. But sometimes the VIC needs to access more data, like during a bad line or getting sprite data, and at these points it switches to a "high speed" memory access model where it uses both phases 1 and 2, and block the CPU during this time. The BA signal handles this communication of intent to use phase 2 cycles. |
| |
Martin Piper
Registered: Nov 2007
Posts: 699 |
Quote: while we're at it, someone could enlighten me how is this ram refresh is done ? I mean like ram bus is 2mhz, where is the extra time VIC has access to the ram ? is this done by reading the contents? etc
The VIC handles the refresh of five 8-bit row addresses every raster line, regardless of the screen enable flag. This means, on the 6567, it refreshes all the rows it needs to within the maximum allowed refresh time. This guarantees just over 2ms to refresh the same row address in a 128 refresh scheme, the maximum delay is just over 3.6ms for a 256 address refresh scheme.
This refresh happens in phase 1 of the clock, whereas the CPU operates in phase 2. The CPU only requires the system bus during the phase 2 clock high part of the clock cycle.
The 6567 normally grabs data during phase 1 cycles, so it doesn't block the CPU, you can think of this as the normal "slow" rate of memory access by the VIC. But sometimes the VIC needs to access more data, like during a bad line or getting sprite data, and at these points it switches to a "high speed" memory access model where it uses both phases 1 and 2, and block the CPU during this time. The BA signal handles this communication of intent to use phase 2 cycles. |
| |
Martin Piper
Registered: Nov 2007
Posts: 699 |
From this link: http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt
Look for this without the quotes, but with the spaces: "r DRAM refresh" you'll see the diagram above which has the line:
VIC ss3sss4sss5sss6sss7sssr r r r r g g g g |g g g i i i i 0sss1sss2sss3s
The section "3.13. DRAM refresh" goes into a bit more detail. |
| |
Martin Piper
Registered: Nov 2007
Posts: 699 |
Compare another machines like the BBC micro, the DRAM refresh happens due to the way the CRTC generates read addresses for the display in sequence, it reads a lot of data for its display, and this read sequence is guaranteed to touch and therefore cycle all the row address lines of its DRAM. So it uses the normal read operation of its video generation, instead of allocating specific read slots.
Since the VIC doesn't have this reliable read (refreshing) pattern for all the row address lines, it instead generates specific timed refreshes instead. |
| |
Martin Piper
Registered: Nov 2007
Posts: 699 |
Is it refresh related? Yes it is, as per the datasheets:
Datasheet 1: http://datasheet.elcodis.com/pdf2/73/0/730070/hm4864-2.pdf
"*Any cycle* in which *_RAS signal* occurs *refreshes* the entire row."
It doesn't matter if it is _RAS only or not, it is still a refresh.
Datasheet 1: https://www.datasheetarchive.com/pdf/download.php?id=8e4d8a58a2..
"Strobing each of the 256 row addresses with *_RAS* causes all bits in each row to be *refreshed*"
Post #33 in https://csdb.dk/forums/?roomid=7&topicid=89189&showallposts=1
At -59.81us to -59.8us where RAS goes from 1 to 0, per the datasheets, is enough to start the process of *refresh* for that row address.
What this means is that any _RAS (low RAS) is by definition refresh related. |
| |
Martin Piper
Registered: Nov 2007
Posts: 699 |
The NEC PD4164-2 datasheet also confirms it is refresh related... https://datasheetspdf.com/pdf-file/1098100/NEC/UPD4164-2/1
Mentioned by the C64 service manual page 22: https://www.retro-kit.co.uk/user/custom/Commodore/C64/manuals/C..
Refreshing is accomplished by:
Performing *_RAS only* refresh cycles
hidden refresh cycles
or *normal read* or write cycles
So any VIC reads that use _RAS (obviously) are refreshing, hence the problem is refresh related. As I said, refreshing doesn't just happen during the 5 VIC refresh slots per raster line. |
| |
Jetboy
Registered: Jul 2006
Posts: 265 |
OMG! OMG! THERE IS PERSON WRONG ON THE INTERNET! |
| |
Monte Carlos
Registered: Jun 2004
Posts: 355 |
So, is this thread actually becoming out of topic? The actual question was about a d016 bit and not HSP. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
