6502 Vs. 65C02 Vs. 65-series

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)

thanks!
-B

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.

0FFE: LDX #$FF
1000: LDA $C051,X
1003: RTS

6502
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
think?

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
strange...
    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
perfection.

-- 
Bryan Parkoff

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

6. FUNCTION GETPIVOTDATA EXCEL FOR WINDOWS VS. EXCEL FOR MAC 2004

7. Outlook 2003 VS. Entourage 2004

8. Office vs iWorks vs Open Office