[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Zip Chip programming info / disk image?

RedskullDC wrote:

Hi Rich,
<jboothbee@gmail.com> wrote in message 1144774875.138809.136100@i40g2000cwc.googlegroups.com">news:1144774875.138809.136100@i40g2000cwc.googlegroups.com... 


I've already got a Spartan IIe board to emulate a
1MHz 65C02 ok (still testing...)


send it my way and I can do some more testing..

Rich



I'm just using the T65_V301 core from FPGA Arcade
at: http://home.freeuk.com/fpgaarcade/library.htm
I'm satisfied that the logic of the core is fine, since I use it
in another project (not Apple related).
I use the latest Webpack 8.1se SP3 to compile the design.

The Apple2E doesn't use the phase 1/2 clock outputs from the
65c02 which is good, since the T65 doesn't support them.

My UCF file (for the BURCHED board) will be useless to you,
since I saw from your web-site that you are using the
Digilent/Xilinx starter kit board.
(I have both a S3-1000 and S3-400 board on order, which should
arrive in a week or two, so I will port it across as soon as they
arrive).

The only changes I have made at this point to T65 are:

1) An extra process which watches a test push-button on my
burched board, and cycles through the 2 Mode bits to
select the processor model:
-- "00" => 6502, "01" => 65C02, "10" => 65C816
I also force a reset when the mode is changed.
My board has a test led which I illuminate when in 65c02
mode.

2) I've started adding the missing 65C02 instructions.
I guess they are not really important for what the guys at
FPGA Arcade are re-creating.
This is not finished yet though.

The main issues at this point appear to be:

Write data hold time (tDHW in the hardware manual).
The "real" 65c02 guarantees that the data bus on a write
will be valid for at least 80ns after the fall of phase 0.
(tDLY 60ns max + tDHW 20ns min = 80ns).
The T65 code doesn't allow for this at all, since I guess it
was never designed to talk to external hardware.
At 1Mhz, this doesn't seem to be a problem, but the faster
we go, the data from the "65c02" won't be on the bus
long enough for external devices to latch it.
Either a slight delay on the incoming clock, or stretching
the write hold time will fix this if it becomes a problem.


It will definitely be an issue for the peripheral bus.

The only test for most of the hundreds of cards designed for
the Apple II was that they appeared to work in a real Apple II.
As a result, some are quite sloppy, and you'll need to ensure
that the bus is driven and sampled very much as a real Apple II
would do it.


On the read cycles, the "65C02" latches the incoming
data much more quickly, so it is not a problem.
Since the read data has to be stable 40ns before the
fall of  phase 0, (tDSU 100ns min - tDLY 60ns max = 40ns)
the fpga will always latch valid data.
The Access time (tACC) is slightly reduced, but well
within the specs of the drams in the 2E.
Slower drams in earlier apples may not cope as well however.


You should be aware that the Apple II "misuses" the 6502 in
terms of setup and hold times.  The design works, of course,
but any changes in setup and hold margins need to be verified
against the Apple II peripheral bus, memory, and built-in I/O
timings.  (Check Sather's book for details.)


Here is a pic of my set-up:
http://au.geocities.com/redskulldc/65c02.jpg
Simple 40pin DIP header on a bit of veroboard,
with 100ohm resistors on all the lines to protect the
FPGA chip from the 5v levels.

Cheers,
Red





--

-michael

Music synthesis for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."