[Coco] 64K Coco mode and the MC6883

[RETRO Innovations]

On 3/24/2023 9:40 PM, Allen Huffman via Coco wrote:
> I am interested in this topic.
>
> It was only last year that I was watching a video (Robin, 8-Bit Show and Tell) about Commodore 64. He did a thing that did a long PEEK/POKE loop to copy BASIC in to RAM and then another thing to enable RAM mode, then BASIC could be modified.
>
> I had no idea that was possible (I started with a VIC, but moved to the CoCo because the C64 was $600 at the time). It made me curious about what allowed that on the 6502 system but not on our machines.

It's because engineers planned for that, and the RAM decode logic takes 
it into account.  The magic is in the PLA (a programmable array logic 
(yes, the generic term is PAL and the newer versions you can buy today 
are called GALs, but CBM called the specific device used in the C64 a 
PLA.  In reality, they just used a generic Signetics PAL to make the 
PLA, and then later made their own at their foundry.  PALs/GALS grew up 
to be CPLDs.

The definitive document is "skoe"'s treatise on the PLA:

http://skoe.de/docs/c64-dissected/pla/c64_pla_dissected_a4ds.pdf

But, the magic is on page 15

CASRAM is (a bunch of terms, which are defined above in the doc. Anytime 
a term is valid, RAM is *NOT* selected (CAS is an active low signal)

So, the terms are: p0orp1orp2or
p3orp4orp5orp6orp7or
p9orp10orp11orp12orp13or
p14orp15orp16orp17orp18or
p19orp20orp21orp22orp23or
p24orp25orp26orp27orp28orp30

Seems like a lot, but, let's spread them out:

p0(a read of BASIC ROM)

orp1 (read of KERNAL scenario #1)

orp2 (read of KERNAL scenario #2)

or p3 (read of charrom, scenario #1)

orp4 (read of charrom, scenario #2)

orp5 (read of charrom, scenario #3)

orp6 (read of charrom, scenario #4)

orp7 (read of charrom, scenario #5)

or p9 (read of I/O, scenario #1)

orp10(write of I/O, scenario #1)

orp11(read of I/O, scenario #2)

orp12(write of I/O, scenario #2)

orp13(read of I/O, scenario #3)

or p14(write of I/O, scenario #3)

orp15(read of I/O, scenario #4)

orp16(write of I/O, scenario #4)

orp17(read of I/O, scenario #5)

orp18(read of I/O, scenario #5)

or p19 (read of external cart low rom, scenario #1)

orp20(read of external cart low rom, scenario #2)

orp21(read of external cart hi rom, scenario #1)

orp22(read of external cart hi rom, scenario #2)

orp23(read of external cart hi rom, scenario #3)

or p24(Ultimax mode, ignore)

orp25(Ultimax mode, ignore)

orp26(Ultimax mode, ignore)

orp27(Ultimax mode, ignore)

orp28(Ultimax mode, ignore)

orp30 (keep CASRAM high when CAS input from the memory controller is high)

I know that's still a lot, but keep in mind, we're only interested in 
BASIC and KERNAL.  That's terms p0,1,2.  And, notice that they are all 
gated with the read signal.

So, if BASIC or KERNAL is being read, CAS will be kept high, which means 
DRAM is not active (kinda weird how DRAM works, but that's another 
topic).  But, when data is being written to those areas, CASRAM will 
follow the CAS line from the memory controller (in the C64, that's the 
VIC-II, just like the SAM does for the CoCo).

It probably would have been easier to leave the read qualifier out of 
the equations, which would have disallowed access to RAM under ROM if 
KERNAL or BASIC were "banked" in at all.  So, the extra qualifier with 
the read line makes the difference.

The rest of the equations are things like I/O space (You can write under 
that as well, but since I/O can be written, you have to actually bank IO 
out to use the RAM under.  Ultimax is a set of equations that are rarely 
used by most folks, as they flip the unit into emulating the ultimax 
game machine. Out of the box and turned on, Ultimax mode is not enabled, 
so those can be ignored.

Sean's note piques my interest, so I'll see if I can fire up the logic 
analyzer (it'd be nice to have someone write a test program in ML that 
checks all the test cases one right after the other, turning off IRQs, 
and I can capture the entire address and data bus at the CPU and the SAM 
or something for those cycles).  I would think it should also be easy to 
test by writing a small program that does:

switch to all RAM mode and write 00 to the first byte of the various ROM 
areas.

switch back to RAM/ROM mode and write a 01 to those same areas

switch back to all RAM mode and look at the various locations.  00 means 
nothing got written, 01 means it did.

If the writes don't mirror, I assume the SAM simply does not gate the 
locations with R/W in the ROM mode.  So, RAM is deselected in those 
areas (the WRITE or WE line on the DRAM comes directly from the 6883, so 
it's entirely possible that line is not pulled low during a write to ROM 
areas in mode 0)

I think it's also better to replace 0-7 in this case with the various 
signals, as the 3-7 was just a quick way to turn 3 pins on the 6883 into 
7 chip select lines.

0 is Memory Read (puts the DRAM data on the main bus)

1 is ROM #1

2 is ROM#2

3 is the cart port ROM select line

4 is PIA 0

5 is PIA 1

6 is the cart port SCS select line

SLENB from the cart port will deselect all of these lines

Also, if the E signal is high OR outputs 4,5,6,7 (PIA 0,1 or SCS) are 
selected, the output is selected.  THat means that ROMs and main memory 
look to only be selected during a high E signal, while IO is always 
selected.  That was probably a quick way to gate all memory accesses 
with E so they only happen on the second half of the clock cycle, when 
the CPU expects memory.

I *think* there is a way to place a little board under the 6883 and 
enable RAM under ROM writes, by recreating the we line and potentially 
modifying the S outputs when a write in mode 0 to ROM is done, if it 
does not do it today (which I assume is true, since you have to swap in 
the ROM, read, swap it out, write, rinse, lather, repeat)

Jim

-- 
RETRO Innovations, Contemporary Gear for Classic Systems
www.go4retro.com
store.go4retro.com