From: Gideon Zweijtzer (gideonz_at_dds.nl)
Date: 2002-04-18 08:37:31
>ruud.baltissen@abp.nl 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.
Gideon
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail 2.1.4.