Re: C64 MMU POC

On 2019-07-10 10:56, Francesco Messineo wrote:
> On Wed, Jul 10, 2019 at 4:40 PM <laughton_at_cyg.net> wrote:
>> 
>> On 2019-07-08 09:44, Mia Magnusson wrote:
>> 
>> > A good thing about the C128 MMU is that it has two sets of registers.
>> > One full set that sits in the general I/O area, and a smaller set that
>> > sits in the $FFxx range (iirc). That way you can do a limited set of
>> > operations even when the full register set is invisible.
>> 
>> This business of partial access sounds like an unwelcome compromise,
>> made necessary by the lack of some unused addresses to which the new 
>> MMU
>> registers can respond.  So, what if the new MMU registers are made to
>> respond to unused *opcodes* instead?  In other words, don't use memory
>> mapped IO for the new registers.  Create some new instructions.
>> 
>> There are lots of unused opcodes, including several which are followed
>> by an 8-bit operand which the CPU ignores but our MMU hardware could
>> easily capture.  The logic for this is surprisingly simple once you 
>> get
>> used to the idea.
>> 
>> 6510 has a special problem, though.  With no SYNC pin, we'd need an
>> alternative means of knowing when an opcode is being fetched.
> 
> imho not a good idea, with no SYNC pin it's hard to tell what phase
> the CPU is working in.

Thanks for your reply.  I *do* know two ways to solve this.  The 
question is, have I found the best way?

> Also, the "unused" opcodes, unless they crash the CPU, might be used
> for smart tricks like cycle-saving branches, like you branch in the
> middle of some other multibyte instruction to save space/cycles or
> whatever else.

Yup, that's a valid concern.  There are lots of undefined instructions, 
though, many of which might suit our needs.  And some may be rarely or 
never used as cycle-saving branches.  Here again I'd welcome input from 
other folks.

> For example look at the clever LFT's 1541 GCR decoder.
> There's another way to map registers in memory (afaik used as early as
> the Apple II), where the register(s) look only at the address bus (and
> R/W maybe), so you can map new registers on top of existing ones. You
> of course need to have some few accesses on different addresses to set
> or reset register bits. One must only pay attention to not map new
> registers on top of other registers that have some bits set or reset
> when read (like some interrupt flags)

Interesting...  So, you'd read several bytes whose value you actually 
don't care about...  but the decoder hardware would recognize *which* 
bytes you'd read; and, from that, infer what MMU operation you wanted?

cheers
J


> and think about very unlikely
> read sequences that won't be triggered by random register accesses.
> Of course, with this method, such a register can't be read by the cpu.
> 
> 
> Frank