[Coco] 64K Coco mode and the MC6883
RETRO Innovations
go4retro at go4retro.com
Tue Mar 28 16:21:24 EDT 2023
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
More information about the Coco
mailing list