6502 Vs. 65C02 Vs. 65-series



  • 1. Is Asimov down?
    I have been trying for 2 days now and still can't get on to Asimov Apple II ftp site. Is it down? Eric
  • 2. Apple IIGs Software and Games
    Hi, I have an Apple IIGs, but this computer never was sell in Brazil. So, I'm looking for IIGs softwares like PrintShopGS, AppleWorksGS, games, and more. Does anyone can help me ? Thanks and sorry by my terrible Engllish. JosCarlos BRAZIL
  • 3. Web browsers for Apple II?
    I heard that there was an web browser for Apple II GS about a year ago. But now I cannot think of it. I could not any documents on that and other web browsers, either. Are there any web browser for Apple II series? I'll be glad to get some about it on the web. Thanks!
  • 4. How to Install Extended 80 Columns Card ??
    Hello all!!! I just got a Apple ][ PLUS with a non-installed 80 columns card Extender. Did someone here know how to install this ? ( 3 wires remains to "plug" somewhere.... ) The brand name of the extender is : "Multiflex". Please help!!! I've searched google entirely !! Thx!!!

6502 Vs. 65C02 Vs. 65-series

Postby robsgreenneon » Wed, 15 Sep 2004 22:31:23 GMT

I understand the 6502 and the 65C02 are pin for pin identical
processors, but the 65C02 can be clocked faster. I understand too that
all the 65-series processors share the same instruction set. If this
is true, how hard would it be to upgrade the original 6502 with a
16-bit or 32-bit processor. The processor would then be able to use
the lower 8-bits to drive 64K addresses, and the upper bits to give it
an additional 64K or 128K.

Re: 6502 Vs. 65C02 Vs. 65-series

Postby Peter de Vroomen » Wed, 15 Sep 2004 22:53:48 GMT

> I understand the 6502 and the 65C02 are pin for pin identical

Do a Google search on 65c816 and 6502...

The biggest problem is not hardware, but software. In the olden days,
timings weren't implemented by using a timer/clock, but by executing a loop.
This loop is going to be executed faster with a faster processor, which
means all these kinds of loops in the software will have to be patched. And
with only a binary rom, this is pretty tricky. You could disassemble the
rom, but you would still have to fully document it before you know what's
going on.


Re: 6502 Vs. 65C02 Vs. 65-series

Postby Steven N. Hirsch » Thu, 16 Sep 2004 08:55:07 GMT

Not exactly true. As Michael Mahon has explained (quite recently, and in 
far more detail than I could), memory access and video display timing 
are tightly coupled to the CPU clock.  Check the archives of this newsgroup.

This is certainly correct in regards to Woz's diskette driver.


Re: 6502 Vs. 65C02 Vs. 65-series

Postby Peter Watson » Thu, 16 Sep 2004 21:22:57 GMT

Actually that's not quite right on at least two counts. Firstly, there are 
instruction set differences between the 6502 and 65C02. And secondly there 
are instruction set differences between the versions of the 65C02 produced 
by different vendors!

If my memory serves me, the instruction set in the 65C02 as used in the 
Apple II series was a simple superset of the instruction set of the 6502, 
however I believe the timing and/or operation changed in a few fairly 
obscure cases. Also, some of the "unimplemented" 6502 instructions actually 
performed (theoretically) useful operations, but these all vanished in the 
Peter Watson
-- Write to MSDOS disks on the Apple IIgs?
-- Impossible!  ;-)

Similar Threads:

1.Flow control behavior in //c vs //gs vs //e

Here's what I've observed so far:

//c defaults to no flow control (but might respect hardward flow
control optionally), whereas you can turn on XON/XOFF optionally, it is
not on by default.

SSC defaults to xon/xoff flow control, but when you disable xon/xoff it
actually activates hardware (rts/dts) flow-control.  If a pc were set
to no flow control, the apple will just ignore the input from the pc
(whereas the //c would still listen to the pc.

Can anyone verify this is correct (the SSC reference manual is not very
specific about this behavior).

Also, can anyone tell me their observations of the //gs flow control
behavior?  I suspect it is more like the SSC, but have no way to verify
this at the moment other than playing around with Kegs (which has
incomplete serial support at the moment)


2.OS Smackdown: Linux vs OS X vs Vista vs XP

3.6502 / 65C02's Invalid Address Bus

I find an interesting issue that invalid address always occur when
page boundary is crossed.  Low Byte of Address Bus is always correct,
but High Byte of Address Bus is always invalid until extra cycle to
correct High Byte of Address Bus.
    Understanding Apple //e manual claims that 65C02 has fixed invalid
address on fourth cycle, but 65816 is not fixed.  I have not tested
Apple //e and Apple //c yet.

For example.

1000: LDA $C051,X
1003: RTS

X = FF
Cycle 1
Address Bus: 1000
Data Bus: BD
Cycle 2
Address Bus: 1001
Data Bus: 51
Cycle 3
Address Bus: 1002
Data Bus: C0
Cycle 4
Address Bus: C050
Data Bus: IGNORE
Cycle 5
Address Bus: C150
Data Bus: DATA

    65C02 should always place 1002 instead of C050 on fourth cycle
before it places C150 on fifth cycle.  I give three example
instructions from $0FFE through $1003 for you to test on Apple II+,
Apple //e, and Apple IIgs, but I have not tested Apple //e yet.
    You run at *FFEG.  See what happen...GR (Low Graphic Resolution)
is turned on at $C050 on fourth cycle since it is always in TEXT
screen.  Please let me know what you find this out.  What do you

Bryan Parkoff

4.Emulated 6502 Must Match Real 6502

    I have been researching while I have gathered data from many emulators
of 6502.  I have discovered that the programmers do make mistakes when they
do not study 6502 hardware seriously.  Let me give you an example below.

    Real 6502 must initialize 0x00 to Low Byte of Stack Pointer and 0x01 to
High Byte of Stack Pointer (Address at 0x0100), but programmers initialize
0xFF to Low Byte of Stack Pointer and 0x01 to High Byte of Stack Pointer
(Address at 0x01FF).  IT IS NOT THEIR ERROR.  Real 6502 powers up at RESET
initialization.  First, it reads 0x0100 (Not 0x01FF) before it pushes NO
DATA into stack three times.  First byte is High Byte, second byte is Low
Byte, and third byte is Processor Flag Status.  Three bytes CONTAIN NO DATA
(It is always correct).  The stack pointer at address: 0x0100 has decreased
to 0x01FD.
    It is where original Monitor Routine and AutoStart Routine start to push
and pop data at address: 0x01FD.  I am surprised that the programmers did
not write to push NO DATA -- 3 BYTES before they started to initialize the
RESET at 0x01FF.
    It is my goal to write 6502 emulator that is 100% identical to real 6502
machine unlike most emulators are about 95% identical.  It is very
    I do not care what you say -- stop saying that it is not important.  I
would laugh because I expect too much to make 6502 emulator to go into the

Bryan Parkoff

5.Windows Vista Vs Mac "Leopard " Vs Ubuntu 7.10


7. Outlook 2003 VS. Entourage 2004

8. Office vs iWorks vs Open Office

Return to apple2


Who is online

Users browsing this forum: No registered users and 67 guest