Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user Nicron ! (Registered 2024-05-21) You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > $D016 bit 5
2023-08-05 18:22
Krill

Registered: Apr 2002
Posts: 2854
$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....
 
2023-08-06 09:21
Martin Piper

Registered: Nov 2007
Posts: 645
Although the programmer's reference guide does show d016 db5 as "RST" high. Hmm :)

The reset cartridge test at $fd02 does happen very early on after machine reset, the jsr does use the stack though. Hypothetically if the VIC defaults to being "in reset" and the memory refresh is off, this might mean the memory for the stack could fail... For the same/similar reason some machines fail with the VIC HSP using a "DMA delay" (DRAM refresh or whatever you want to call it) screen scroll.

Theoretically the delay between setting the stack memory, checking the cart, and reading the stack back with an rts could be small enough to not experience memory corruption.

This might explain why the $d016 set without "reset" is very early in the reset code, to make sure the VIC is refreshing memory...

All this would need to be tested if there are any VICs that do default to "reset on" and do not refresh the DRAM.
2023-08-06 09:33
Martin Piper

Registered: Nov 2007
Posts: 645
Although the HSP/VSP DRAM issue does seem to be related to unexpected DRAM refresh signal timings, rather than lack of refresh timings. DRAM that isn't refreshed *at all* would tend to decay slower than badly refreshed DRAM due to signals flickering unexpectedly.
2023-08-06 14:28
chatGPZ

Registered: Dec 2001
Posts: 11147
<offtopic>"VSP Bug" is not related to refresh - see LFTs article</offtopic>
2023-08-06 15:02
Martin Piper

Registered: Nov 2007
Posts: 645
Quote: <offtopic>"VSP Bug" is not related to refresh - see LFTs article</offtopic>

Incorrect, see "In short, one memory cell gets refreshed with the bit value of a different memory cell."
2023-08-06 15:03
Oswald

Registered: Apr 2002
Posts: 5028
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
2023-08-06 15:08
chatGPZ

Registered: Dec 2001
Posts: 11147
Quote:
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.
2023-08-06 15:09
Martin Piper

Registered: Nov 2007
Posts: 645
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

https://c64os.com/post/flitiming1
Look for the text "The top two lines show /RAS and /CAS."

It seems to be a good explanation.
2023-08-06 15:11
Martin Piper

Registered: Nov 2007
Posts: 645
Quote: Quote:
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.


Incorrect. I understand perfectly, that why I wrote the correct comments in the post above "unexpected DRAM refresh signal timings" and "badly refreshed DRAM due to signals flickering unexpectedly".

Note how what I wrote corresponds to the "which means that its output will flicker rapidly" from the article.
2023-08-06 15:12
chatGPZ

Registered: Dec 2001
Posts: 11147
>_<
2023-08-06 15:13
Martin Piper

Registered: Nov 2007
Posts: 645
Quote: >_<

You just don't understand what I wrote and how it's basically identical to the article. That's OK.
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
void256
DJ Space
Guests online: 81
Top Demos
1 Next Level  (9.8)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.7)
5 Edge of Disgrace  (9.6)
6 Comaland 100%  (9.6)
7 Uncensored  (9.6)
8 No Bounds  (9.6)
9 Bromance  (9.5)
10 Lunatico  (9.5)
Top onefile Demos
1 Layers  (9.6)
2 It's More Fun to Com..  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 TRSAC, Gabber & Pebe..  (9.5)
7 Rainbow Connection  (9.5)
8 Dawnfall V1.1  (9.5)
9 Quadrants  (9.5)
10 Daah, Those Acid Pil..  (9.5)
Top Groups
1 Oxyron  (9.3)
2 Booze Design  (9.3)
3 Censor Design  (9.3)
4 Crest  (9.3)
5 Performers  (9.3)
Top Organizers
1 Burglar  (9.9)
2 Sixx  (9.8)
3 hedning  (9.7)
4 Irata  (9.7)
5 MWS  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.054 sec.