Re: Detect a C128 from C64 mode

From: Greg King <greg.king5_at_verizon.net>
Date: Fri, 24 May 2013 12:21:56 -0400
Message-id: <7515B121850B4E609AC63B032378D921@Kaiser>
From: "Gerrit Heitsch"; on Thursday, May 23, 2013; at 2:20 PM -0400
>
> On 05/23/2013 08:08 PM, Spiro Trikaliotis wrote:
>> * On Thu, May 23, 2013 at 10:17:23AM -0400, Greg King wrote:
>>
>>>> Unfortunately, I don't think any of these work; they all set
>>>> the test-mode bit (bit 1) to 1 (on)?
>>>
>>> Does that matter?  The original test bit (in $d016) crashed the
>>> system because it disabled the dynamic RAM refresh (therefore, it
>>> was removed).
>>
>> You mean: There are chip revisions where the test bit actually does
>> something? On my 6569 (datecode from early 1983), it was a no-op.
>
> Besides, in the C64, DRAM-refresh happens in EVERY RAS-cycle, no matter
> whether CPU or VIC are acessing ROM or RAM. This is due to RAS being
> connected directly to the RAM, while CAS is gated by the PLA. So, even if
> CPU or VIC access ROM, the lower 8 address bits are latched by RAS into
> the RAM, and address a row. Which will be written back at the end of the
> cycle, and therefore refreshed.
>
> Unless you have RAM that really insists on 128cycles/2ms for the 4164 or 256cyles/4ms for the 41464 (most do not, and keep the 
> data quite a bit longer), just the memory read cycles by VIC, necessary to display the image, should be enough to keep the RAM 
> from becoming forgetful.

I can't remember whether or not that reset-bit stopped the clock generator; but, I know that it stopped everything else -- the 
VIC-II didn't touch memory, in any way!

It must have caused serious trouble; otherwise, Commodore's engineers wouldn't have botherred to disable it. 


       Message was sent through the cbm-hackers mailing list
Received on 2013-05-24 19:01:21

Archive generated by hypermail 2.2.0.