| |
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? =) |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
AFAIK this bit is only needed/used in the VICII of the MAX Machine. If at all :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
I thought so, too. And yet, seems to be a C-64 thing, too, after all. :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
I'd say: Proof or bullshit :) |
| |
Monte Carlos
Registered: Jun 2004
Posts: 360 |
What does "no ram" mean? How is d016 related to ram? |
| |
Jetboy
Registered: Jul 2006
Posts: 337 |
Quote: What does "no ram" mean? How is d016 related to ram?
VIC IS responsible for RAM refresh. Turning VIC off would mean no RAM refresh = mangled memory sooner than later. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Quote: 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? =)
The stx $d016 at $fcef uses the X index result of the cartridge check routine at $fd02 which checks for the CBM80 being mapped into $8004, which is why some might think it is related to "cartridges won't start".
In reality, if a cartridge partially maps the CBM80, maybe the cartridge dump was bad or deliberately like that, then the screen would have a noticeable different X scroll during reset and mem test.
You can see the different screen X scroll during a soft reset if you do: > 8004 0 0 cd 38 30
And compare it with: > 8004 0 0 0 0 0
So it is probably just a visual debugging aid for auto-start cartridges. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
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. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
<offtopic>"VSP Bug" is not related to refresh - see LFTs article</offtopic> |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
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." |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
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 |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
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. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
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. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
>_< |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Quote: >_<
You just don't understand what I wrote and how it's basically identical to the article. That's OK. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Yes, that's it! |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
In other words, from what I wrote earlier, "unexpected DRAM refresh signal timings" (RAS and CAS and the address lines) "flickering unexpectedly" causes "badly refreshed DRAM" aligns with the article "one memory cell gets refreshed with the bit value of a different memory cell". It is precisely to do with refresh of DRAM, or rather bad or faulty refresh in this case. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
The DRAM refresh happens in the refresh cycles. There is no problem there.
You can write "incorrect" once more. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting KrillHowever, $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).
The reset bit does not do anything on the 6569R1. I'm guessing early 6567's, maybe only prototypes even? |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
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: 360 |
Groepaz's bot active again ;-) |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
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: 722 |
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: 722 |
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. :-) |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
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: 722 |
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: 722 |
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: 722 |
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: 722 |
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: 722 |
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: 722 |
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: 722 |
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: 337 |
OMG! OMG! THERE IS PERSON WRONG ON THE INTERNET! |
| |
Monte Carlos
Registered: Jun 2004
Posts: 360 |
So, is this thread actually becoming out of topic? The actual question was about a d016 bit and not HSP. |
| |
Monte Carlos
Registered: Jun 2004
Posts: 360 |
It's good to have different sights on the same thing, although if it gets a one man show, the constructive discussion suffers a lot. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
What iAN CooG and Monte Carlos said.
Quoting GroepazAFAIK this bit is only needed/used in the VICII of the MAX Machine. If at all :) Quoting tlrThe reset bit does not do anything on the 6569R1. I'm guessing early 6567's, maybe only prototypes even?
How likely is it that some (NTSC) C-64 have one of those early VIC-II revisions?
And if unlikely, why could a cartridge fail to start without that store to $d016? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:How likely is it that some (NTSC) C-64 have one of those early VIC-II revisions?
"uncommon but not rare" :) The first batch(es) had the early VICIIs (obviously) - whats probably unlikely is that someone is still using these (64 cycles and everything)
Quote:And if unlikely, why could a cartridge fail to start without that store to $d016?
Could be as simple as "some broken code relies on the value in the register", who knows - i'd like to know who made those claims about which cartridges though (that would give us a chance to answer that question, perhaps). |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Groepaz i'd like to know who made those claims about which cartridges though (that would give us a chance to answer that question, perhaps). Will ask them to chime in. One of the best current coders on this machine, though, with many games under the belt. =)
Was stumped as well by a bug report of one of the testers and the fix.
Some sort of (yet unemulated) VIC-II startup state (unrelated to the reset bit) that only gets unlocked by a store to $D016 is ruled out? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
I'd never rule out weird things like that.... That strange behaviour with one of the sprites that some VICII show was also quite unexpected :)
But as said, without knowing more details its all (a bit pointless) speculation. Once we know these, we can knock up tests and ask people to run them - and we can find out what exactly is happening. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
http://janklingel.de/wordpress/wp-content/uploads/2020/08/MOS-6..
"The RES bit (bit 5) of register $d016 has no function on the VIC 6567/6569 examined as yet. On the 6566, this bit is used to stop the VIC."
6566...
Wikipedia: "MOS Technology 6566 – designed for SRAM/non-muxed address lines (used in the MAX Machine)"
So... SRAM, no need for refresh, by normal reading or by scheduling forced row address _RAS strobes. |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
I suppose from the German: https://riff.2ix.at/c64/vic-txt.html
Das RES-Bit (Bit 5) von Register $d016 ist bei den bisher untersuchten VIC 6567/6569 ohne Funktion. Beim 6566 dient dieses Bit dazu, den VIC zu stoppen. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting KrillCould 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? =)
Is there an example of a particular cartridge lacking that store, not starting on a certain machine?
I think that store was usually omitted when replicating the startup code. I for one never included it. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
That said, it'd also be interesting where AAY64 copied the info from - i only remember that bit being described as "stop" or "test" bit (whatever that means).
And who owns a Max Machine and can run test programs? :) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting chatGPZThat said, it'd also be interesting where AAY64 copied the info from - i only remember that bit being described as "stop" or "test" bit (whatever that means).
It's called RES here: http://archive.6502.org/datasheets/mos_6567_vic_ii_preliminary...
Mapping the C64 states:
Bit 5: Bit 5 controls the VIC-II chip Reset line. Setting this bit
to 1 will completely stop the video chip from operating. On older
64s, the screen will go black. It should always be set to 0 to insure
normal operation of the chip.
Quoting chatGPZAnd who owns a Max Machine and can run test programs? :)
Looks like Macbeth might have one judging from recent videos. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Also in the C64 Programmer's Reference (second printing 1983), p447, this is stated:
"The reset bit (RES) in register 22 ($16) is not used for normal operation. Therefore it should be set to "0" when initializing the video chip. When set to a "1," the entire operation of the video chip is suspended, including video outputs and sync, memory refresh, and system bus access."
pdf: http://cini.classiccmp.org/pdf/Commodore/C64%20Programmer%27s%2.. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Posted a request here
Interestingly, the german "64 Intern" (which is basically a ripoff/translation of the PRG) does not describe bit 5 at all. To me that hints at it perhaps being removed from later editions of the PRG too. Maybe :) |
| |
ws
Registered: Apr 2012
Posts: 251 |
Hej, just something i remembered is, that exactly this (screen going black, machine halting) happened to me a long time ago on my C128 in C64 mode while fiddling around with D016.
I remember this, because that is how i initially learned that one shouldn't just write untreated values into any register ("Oh, that is what this AND + OR is for!").
Sadly i don't own that machine anymore. Did anyone try this on a C128 (the reduced C64-like case version, not D)?
Please excuse if i am too far off topic. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: Hej, just something i remembered is, that exactly this (screen going black, machine halting) happened to me a long time ago on my C128 in C64 mode while fiddling around with D016.
I remember this, because that is how i initially learned that one shouldn't just write untreated values into any register ("Oh, that is what this AND + OR is for!").
Sadly i don't own that machine anymore. Did anyone try this on a C128 (the reduced C64-like case version, not D)?
Please excuse if i am too far off topic.
The C128 PRG does state for $d016: "5 ALWAYS SET THIS BIT TO 0"
here (p547): https://www.pagetable.com/docs/Commodore%20128%20Programmer%27s..
Never noted that before but I've never really dug into the C128. Does that bit do anything? |
| |
Jetboy
Registered: Jul 2006
Posts: 337 |
It does.
I remember fixing some demos to write nicely to $d016 to be able to run them on my c128. There were not many that needed that. I don't remember which ones were those. It was 25++ years ago :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
And you don't mix it up with $d030? |
| |
ws
Registered: Apr 2012
Posts: 251 |
I personally am sure that i don't mix it up with $d030 because i actually wrote one (lost) intro that uses the "switch mhz mode in the border" trick. |
| |
Jetboy
Registered: Jul 2006
Posts: 337 |
> And you don't mix it up with $d030?
There is such possibility.
Fiddling with bit 5 in vice 128 does not matter (both c128 and c64 modes). I do not have real HW to check. |
| |
GeirS
Registered: Jan 2014
Posts: 4 |
Quoting chatGPZTo me that hints at it perhaps being removed from later editions of the PRG too. Maybe :)
I can confirm that the textual description of the reset bit has been removed from Appendix N in my printed PRG (first edition, fourth printing - 1983.) There's just some extra empty space between the "Reset" heading and the next "Theory of operation" heading. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Ha! |
| |
ws
Registered: Apr 2012
Posts: 251 |
i was trying to remember more and then i came across the ECM mode + Bitmap-mode-enabled-at-the-same-time-"bug" again which actually does the black screen thing - but it does not crash. Perhaps the screen blackening happened and i was unable to do anything onscreen and identified that as a halt (i had no monitoring back in the day, let alone real knowledge :shrug:)
so i am not sure if it is actually true that the C128 halted, i just read this thread and remembered "wait i experienced exactly this!" and hastily commented - while i actually should only have asked if this was tried an a C128.
so my apologies, maybe that was a mixed up memory. but it surely was not d030. anyways. maybe i'll dig out the c128 i got in 2015 and try there again later - ofcourse it will most likely not be the same HW revision. Nevermind. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: i was trying to remember more and then i came across the ECM mode + Bitmap-mode-enabled-at-the-same-time-"bug" again which actually does the black screen thing - but it does not crash. Perhaps the screen blackening happened and i was unable to do anything onscreen and identified that as a halt (i had no monitoring back in the day, let alone real knowledge :shrug:)
so i am not sure if it is actually true that the C128 halted, i just read this thread and remembered "wait i experienced exactly this!" and hastily commented - while i actually should only have asked if this was tried an a C128.
so my apologies, maybe that was a mixed up memory. but it surely was not d030. anyways. maybe i'll dig out the c128 i got in 2015 and try there again later - ofcourse it will most likely not be the same HW revision. Nevermind.
Thanks for clarifying.
Illegal vic modes only blacks the screen area. The RES bit should kill the video signal completely, no sync. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Someone on Lemon confirmed that setting bit5 indeed blanks the screen on a MAX Machine |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: Someone on Lemon confirmed that setting bit5 indeed blanks the screen on a MAX Machine
Cool! Would be interesting to know the exact chip version/revision used.
Also, does it require a reset using that but or can it be kept 0 forever? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:Also, does it require a reset using that but or can it be kept 0 forever?
You mean, will a program keep running, or machine crash (require reset to come back)? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: Quote:Also, does it require a reset using that but or can it be kept 0 forever?
You mean, will a program keep running, or machine crash (require reset to come back)?
I mean: does it require a reset using that bit to start operating correctly after power up? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
I still don't understand :) You mean the reset routine would set and then unset the bit? (I think we could find out by disassembling MAXBasic or MultiMAX) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: I still don't understand :) You mean the reset routine would set and then unset the bit? (I think we could find out by disassembling MAXBasic or MultiMAX)
Yes.
Or perhaps starting the thing without a cart or with a dummy cart and see what happens? |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
Quote: i was trying to remember more and then i came across the ECM mode + Bitmap-mode-enabled-at-the-same-time-"bug" again which actually does the black screen thing - but it does not crash. Perhaps the screen blackening happened and i was unable to do anything onscreen and identified that as a halt (i had no monitoring back in the day, let alone real knowledge :shrug:)
so i am not sure if it is actually true that the C128 halted, i just read this thread and remembered "wait i experienced exactly this!" and hastily commented - while i actually should only have asked if this was tried an a C128.
so my apologies, maybe that was a mixed up memory. but it surely was not d030. anyways. maybe i'll dig out the c128 i got in 2015 and try there again later - ofcourse it will most likely not be the same HW revision. Nevermind.
The C128 does have a test bit that stops output, but its on D030 and doesn't use the D016 one as far as I know. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:Or perhaps starting the thing without a cart or with a dummy cart and see what happens?
Then it simply does nothing :) But yes, it'd be interesting if the monitor syncs or not in that case
Quote:The C128 does have a test bit that stops output, but its on D030
Technically the test bit in $d030 doesn't "stop output" - the line counter increases by 1 every cycle when it is set, it still produces a video signal though. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:I think we could find out by disassembling MAXBasic
It writes 0 first (at the beginning of the reset routine), then 8 (in the VICII register init loop). So it doesn't toggle bit5. |
| |
Monte Carlos
Registered: Jun 2004
Posts: 360 |
According to C64 Wiki the 6566 is a revision used in NTSC machines. So not wonder if the PAL world wonders about the reset bit.
https://www.c64-wiki.de/wiki/VIC |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: According to C64 Wiki the 6566 is a revision used in NTSC machines. So not wonder if the PAL world wonders about the reset bit.
https://www.c64-wiki.de/wiki/VIC
The 6566 is used solely in the MAX Machine which is only available in NTSC, yes. |
| |
Fungus
Registered: Sep 2002
Posts: 687 |
I have never seen one in the wild with a 6566. I have seen R4 6567 (less lumas) and R5 6A though. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
As said, its only used in the MAX Machine, it wouldn't work in a C64 even. THAT part is clear :) |
| |
Fungus
Registered: Sep 2002
Posts: 687 |
Yeah, someone should correct that in that wiki. |
