Re: Hardware emulation of 6509 using 6502?

smf wrote
> If you have any doubts about general 6502 behaviour then you should be 
> able to resolve them here

Thanks. It's actually not general 6502 behaviour that's in question.   I'm
wondering about a nerdy little wrinkle that applies only to 6509 -- and to
the emulation circuit. It pertains to the timing of the flip that occurs on
P3-P0 -- I mean the flip from outputting the "normal" high-address bits
(from the Execution Register) to outputting the "alternate" high-address
bits (from the Indirect Register).

With opcode $B1, for example (ie: LDA ind,y), we know cycles 1, 2, 3 and 4
are the opcode fetch, the fetch of the z-page address operand, then the read
of the two-byte pointer.  Then on cycle 5 we have the actual data access
(for now let's assume no page crossing).  It's on cycle 5 that P3-P0
temporarily flip -- they switch to outputting the Indirect Register.  Then
on the next cycle P3-P0 flip back to their default state, which is to output
the Execution Register.  (To be clear: if the Indirect Register and the
Execution Register are *equal* then the flip still happens but there's no
effect because the values are equal.  ie, there's no cross-bank access. 
That means the flip timing can't be wrong -- timing simply doesn't matter.)

So, the 6502 part of the CPU always just does what it normally does.  But if
there's a cross-bank access then the extra stuff that was added for 6509 is
required to /coordinate/ timing-wise with what the 6502 part is doing.  The
Indirect Register must appear in cycle 5 only. 

Luckily that's pretty easy.  But if page crossings are allowed then things
get harder, because when cycle 6 arrives it might be the data access or it
might be the opcode fetch of the next instruction.  We need to know whether
or not to flip to P3-P0 flip back to their previous state --  and there
can't be any mistake about this!  So, what I'm saying is: allowing page
crossings on cross-bank accesses requires extra resources.

Honestly, the 6509 is so minimal in its implementation I wonder if they
bothered!  Instead maybe they took a quick 'n dirty short-cut.  Maybe they
just made a nasty rule that page crossings are illegal on cross-bank
accesses -- and obliged the programmer to deal with that limitation!  It's
just a theory.  Datasheets I've seen don't reveal whether the limitation
exists.  But, in case it doesn't, I included a couple of extra gates to
handle variable timing from page crossings on a cross-bank access.  The
schematic I posted on 6502.org shows this.


Sorry for getting bogged down in nerdy details!  And, again, congratulations
on the progress being made.  This is an idea I would probably never have
brought to fruition (especially since I don't have a CBM to test with), so,
kudos to Jim for moving things to the next level with the circuit board and
Verilog coding.  BTW I'm willing to write some simple test code in assembler
if that'll help.

cheers,
Jeff
http://LaughtonElectronics.com



--
Sent from: http://cbm-hackers.2304266.n4.nabble.com/

       Message was sent through the cbm-hackers mailing list