[Coco] 64K Coco mode and the MC6883

[RETRO Innovations]

On 3/28/2023 3:01 PM, Sean Conner via Coco wrote:
> It was thus said that the Great RETRO Innovations via Coco once stated:
>> OK, here's some of the results, though it is late, and if something
>> looks wrong, it's probably how I am reading things.
>>
>> The first sta $ffdf appears to be at $0197, which has S[2:0]=7, !WE is
>> not active
>    I don't understand.  Is $0197 where the instruction is stored?  That
> doesn't seem right to me, but if it ran, it ran.

I should be more specific:

The sta $ffdf loaded from RAM at $XX97,98,99 (3 bytes).

To speed up the process of analyzing this, I used a 16 channel USB based 
LA here, as my massive HP16702 with 100+ channels is harder to set up 
(better, but not as trivial).  Since I only had 16 channels, and I 
needed 6 for various things we wanted to know (S0,1,2, !WE, R/W, E), 
that left 10 for the rest.  I made a decision to use 8 for lower address 
byte, and just scan through the trace for a write to $df, then $00, $00, 
$00, as that would be the start of your app.  The 1 in $197 is the R/W 
line being part of the pseudo address.  That allowed me to filter out 
all reads of addresses with $df in them, as a write to $xxfd would be 
$00fd, where a read would be $01fd.

Jim

>> followed by the sta $8000, which also has S=7, and !WE active during the
>> second half of the cycle
>>
>> sta $a000 also has s=7, !WE active on back half of cycle
>>
>> sta $c000 also has s=7, !WE active on back half of cycle
>>
>> Those do not match your table, which shows S=1,2,3
>    Those were guesses, based upon my reading of the data sheet [1], which did
> *not* explicitly state the S values for writing in this mode.
True, but the ones you marked as *, were for the RAM/ROM mode, and the 
above were for RAM mode.
>    That's what I was thinking, reading over the MC6883 data sheet and looking
> at the Coco schematic---it just didn't seem right to me.

I've seen it before on other platforms, but it's bad form.  The MC parts 
in use (and MOS at the time as well) were NMOS, and they had pretty 
forgiving drivers.  As well, they did not push/pull to the same degree.  
NMOS pulled hard to ground, and weak to +5V, more like a weak resistive 
pull up, in my opinion, so the CPU driving 1 and the ROM driving 0 would 
just show 0 on the bus, and the CPU would just dissipate heat in the 
pullup transistor.  Since people rarely wrote to ROM, since it does not 
do anything, it's a limited problem.

What struck me as odd was the switch to "ignore, S=7" on writes to RAM, 
but writes to RAM do not pay any attention to the S values and are not 
affected by the state of the 3-8 decoder.  Thus, an external module 
(like MOOH cart) can't move RAM out of the way at all.  SLENB has no 
affect on RAM access.

>
>    I don't need it, as all I was curious about was if writes to RAM in
> RAM/ROM mode go to RAM, which does not appear to be the case.  You didn't
> mention what the BASIC program printed, but I'm guess it said "SWITCH
> NEEDED".

It did.

Jim