Re: C64 MMU POC

On Wed, Jul 10, 2019 at 5:48 PM <laughton_at_cyg.net> wrote:
>
> On 2019-07-10 10:56, Francesco Messineo wrote:
> > On Wed, Jul 10, 2019 at 4:40 PM <laughton_at_cyg.net> wrote:
> >>

> >
> > 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?

I think many of us would like to know your ideas on this matter :)


> 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.

yes, but you can't guarantee that valid code tries to execute any
non-crashing instruction.

> > 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?

exactly. That's how the bank switching for RAM/ROM banks work on the
16K language card of the Apple II for example.

Frank