| |
Krill
Registered: Apr 2002
Posts: 2980 |
$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: 723 |
Quote: The DRAM refresh happens in the refresh cycles. There is no problem there.
You can write "incorrect" once more.
From the article you cited: "In short, one memory cell **gets refreshed** with the bit value of a different memory cell."
It refutes what you claim and agrees with what I wrote "badly refreshed DRAM due to signals flickering unexpectedly".
How do you not understand that "one memory cell **gets refreshed** with the bit value of a different memory cell" is synonymous with "badly refreshed DRAM"? It's not like the DRAM is correctly refreshed, the signal are flickering basically changing unexpectedly, when they shouldn't be with relation to the RAS signal. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
I understand exactly what your problem is, but i wont give another hint. It's ok. |
| |
Monte Carlos
Registered: Jun 2004
Posts: 361 |
Groepaz's bot active again ;-) |
| |
Martin Piper
Registered: Nov 2007
Posts: 723 |
Quote: I understand exactly what your problem is, but i wont give another hint. It's ok.
You fail to understand the article. That's what. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Your lack of knowledge and imagination to grasp factually accurate information about specific topics is appreciated. |
| |
Martin Piper
Registered: Nov 2007
Posts: 723 |
Quote: Your lack of knowledge and imagination to grasp factually accurate information about specific topics is appreciated.
The fact is you're wrong and you're refusing to admit it. |
| |
iAN CooG
Registered: May 2002
Posts: 3198 |
Can we have an actual explanation or all we can read here is "you're wrong and an idiot"? That's not useful for anyone, get a room and beat each other out until one remains alive, else please stop. |
| |
Martin Piper
Registered: Nov 2007
Posts: 723 |
Quote: Can we have an actual explanation or all we can read here is "you're wrong and an idiot"? That's not useful for anyone, get a room and beat each other out until one remains alive, else please stop.
One memory cell gets refreshed with the bit value of a different memory cell.
Basically. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Just read the article :) |
| |
Bansai
Registered: Feb 2023
Posts: 49 |
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. :-) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
