RE: 65GS10

From: Gideon Zweijtzer (
Date: 2002-04-18 08:37:31

  • Next message: "RE: OT - limitation of PC's parallel port (was: Logic analyzer)"
    > wrote:
    >> What locations $0 and $1 are concerned; in my implementation the
    >reads are
    >> always from the local PIO registers, and the writes go to the
    >PIO registers,
    >> but also to the bus, so the rest of the system *does* write
    >those bytes into
    >> RAM. I am not sure if this is the case with the original 6510.
    >The real 6510 or 8502 doesn't drive the data lines when writing to 0 or
    >1.  It does drive the address bus and the R/-W line.
    So the original CPU writes random data to $0 and $1, but still does a write,
    right? So there should be no problem in just writing the actual contents of
    $0 and $1 also into memory.
    >> That the timing is concerned; there are some differences. From
    >the top of my
    >> head:
    >> * branches take 2 cycles untaken, 4 taken, no matter if the page
    >boundary is
    >> crossed or not.
    > > * implied instructions always take 1 cycle instead of 2
    > > * In read/modify/write instructions, the wrong value is not written
    > > first, like what was the case on the 6502.
    >These will break a lot of video interrupt stuff.  It's very common
    >practice to use the 1-byte, 2-cycle instructions and conditional
    >branches for adjusting the timing, and it's also rather common to do
    >something like inc $d019 to acknowledge a raster interrupt.
    Yes, I agree; it will break a lot of video timing stuff. I could put some
    effort in making my 6510 implementation completely 6510 cycle-compliant, but
    I want to focus on the faster CPU.
    Interrupt timing is something else to have a look at. It can be that in my
    implementation the interrupt latency (before it really 'sees' the interrupt)
    can be longer by one instruction.
    The note about the rising and falling clock from Ruud is not entirely true.
    To cut some cycles, I don't need to use the falling edge, but just move some
    logic around over some register barriers. Like I said in my previous post,
    this implementation was optimized for speed, so I couldn't have any logic
    *behind* the flipflops for the address outputs. This implies that the
    program counter is always one cycle ahead already, which introduces a
    problem for a few instructions like a branch when it is taken. (Also for the
    implied instructions, since the PC is already fetching the second byte of
    the next instruction while executing the implied instruction! Of course I
    could stall the CPU for one cycle in this case, so the timing would look
    like 2 cycles again.)
    >> What programs really depend on these timings? Mostly demo's and
    >games. As I
    >> said before, we are aming at a 32 MHz CPU.
    32-bit, 33 MHz.
    >> - The CPU is going to be equiped with 32 (?) 32 bits general purpose
    >> registers.
    I was thinking about 8 registers, although 32 would be awesome. I'd get into
    some problems though when it comes to encoding the instructions in the
    available opcode space that I have.
    >How many flipflops does the FPGA have again?
    Plenty. The one I am using now for the 6510 has 2880 LE's, and thus 2880
    flipflops. FYI: the 6510 only takes up about 920 LE's, and that includes the
    PIO registers at address 0/1.
    Besides; I still have to look into the possibility of using the internal
    block RAM for the registers. I am just afraid that I can't write two
    registers in one cycle and this might be needed in some cases.
           Message was sent through the cbm-hackers mailing list

    Archive generated by hypermail 2.1.4.