Re: Disabling memory refresh in UltiMax mode Re: 6510 handling of $00 and $01 registers

>>> I am fairly sure that R/W and the address lines will be asserted.  
>>> I vaguely remember that the data lines are left floating.
>>
>> That is correct.  We don't have die pictures of a 6510 yet, but
>> it seems like the 00/01 thing forces the DBE signal low, and
>> that is all it does (and the actual register stuff of course).
>
> Now, thinking harder, reads from 0 and 1 should be shown on the  
> address and data bus too. (The data bus would be driven by the  
> memory chips, as usual.)

Of course :-)

>>> One more tidbit: on the 128, you can programmatically enable  
>>> UltiMax mode on the MMU (GAME=0, EXROM=1, enter 64 mode) and let  
>>> the VIC-IIe fetch its data from an unconnected address. In the  
>>> mid-1990s, I played a bit with this, trying to write a test  
>>> program that would display the data fetched by the processor. It  
>>> did not occur to me back then to research whether you can disable  
>>> memory refresh and corrupt the RAM in this mode.
>>
>> The row address gets delivered to the RAM no matter what, so there  
>> is no problem there?
>
> The row address is the low-order 6 bits, right?

Low eight on the VIC-II in the C64 (there is a mask option to make it
low seven, to work with 16k DRAM chips).

> The VIC-II will do 5 memory refresh cycles per raster line, reading  
> from $3fxx using a 8-bit counter. But, will $3fxx always be visible  
> to the VIC-II in the UltiMax mode?

It doesn't matter, the row addresses are always delivered to the RAM,
whether the VIC is reading from ROM or open bus or whatever.  The PLA
selectively switches off #CAS only, not #RAS.

>   Does this change if you make VA14 or VA15 nonzero? IIRC, in  
> UltiMax mode, the VIC-II should see data from ROML or ROMH, and  
> only the first $1000 bytes should be fetched from RAM.

Here's my PLA decode for Ultimax mode:


not exrom and game:
===================
0000..0fff, cpu: ram
8000..9fff, cpu: cartridge low
d000..dfff, (cpu read and ba) or cpu write: i/o
d000..dfff, cpu read and not ba: ram
e000..ffff, x1x, cpu: cartridge high
e000..ffff, x0x, cpu: ram

3000..3fff, 7000..7fff, b000..bfff, f000..ffff, vic: cartridge high
0000..0fff, vic: ram
8000..9fff, vic: ram
d000..efff, vic: ram
rest open bus


As you see, the CPU can read from dxxx (well, not really -- it will
drop the result on the ground, not RDY), and read/write to [ef]xxx
as well.  (The "x0x" etc. are the P2..P0 bits).  The VIC sees more,
and it sees the cartridge ROM at various places.

The PLA does nothing with VA14 except for the character ROM, and
VA15 isn't even connected :-)

Let me know if you want the decodes for the other modes.

Btw, this is from the original actual PLA; it could be that the
later NMOS and CMOS decoders do something different for the
(undocumented) edge cases.


Segher


       Message was sent through the cbm-hackers mailing list