Re: C64 MMU POC

On 2019-07-10 12:01, Francesco Messineo wrote:
> 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.

How strong a guarantee do we need?  In the 1980's I built a computer 
that uses 65C02 (CMOS) undefined opcodes, so I'm familiar with those -- 
and some of them are very ill suited for cycle-saving branches etc.  I'm 
*not* familiar with NMOS undefined opcodes.  But it's reasonable to 
suppose there may be some which could serve the MMU function but 
otherwise are never (or almost never) used.  It's true this can't be 
100% guaranteed.

As for the missing SYNC pin: one solution consumes PLD resources to 
create a state machine.  That seems like (and may indeed be) a rather 
expensive solution.  But it would be no surprise if someone who's 
willing to engage with the challenge (this is crucial) found it simpler 
than initially imagined.

Failing that, I know of a $10 IC that's available in surface-mount which 
exactly matches the cycle-by-cycle behavior of an NMOS 6502/6510  ;o)


I also like the Apple II language card approach you and others 
mentioned.  But all these ideas have pros and cons, and deserve 
consideration.  I decided to speak up because creating new instructions 
is a powerful idea, yet one that's somewhat uncommon and thus easy to 
overlook.

J.


>> > 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  for example.
> 
> Frank