Re: C64 MMU POC

From: Gerrit Heitsch <gerrit_at_laosinh.s.bawue.de>
Date: Wed, 10 Jul 2019 20:11:41 +0200
Message-ID: <f1a628ee-bff5-44e0-c89d-cbf9e0ee3cb6_at_laosinh.s.bawue.de>
On 7/10/19 7:47 PM, Jim Brain wrote:
> On 7/10/2019 12:26 PM, laughton_at_cyg.net wrote:
>>
>> 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.
> The Faks6509 project uses a similar idea, a small state machine to 
> reverse engineer the SYNC pin function.
>>
>> 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)
> 
> Hmm, you thinking of the 65C02S?  Because, I think we determined that 
> the CMOS 6502 and the NMOS 6502 are not cycle exact.  I know the 
> Rockwell 65C02 differs in the execution pipeline and thus it fails with 
> the Fake6509 project.

Hm... could you take an NMOS 6502 and have it run in parallel to a 6510, 
sync'ed at RESET? Plus some logic to tristate the address lines and 
unable to write so it only reads in parallel to the 6510.

Then you should have a source for the SYNC signal.

  Gerrit
Received on 2020-05-29 22:31:23

Archive generated by hypermail 2.3.0.