delton@pro-carolina.cts.com (System Administrator) (02/22/89)
I think this was discussed before probably a few years ago but I forget...
What's the shortest way (code size wise) to test for a 65C02 in software
(disregarding reading ROM ID bytes since the ROM's and CPU's don't
necessarily go together). Mainly I need to differentiate between the 6502 and
65C02.
It could be done by setting up an address crossing a bank boundary or by
trapping the BRK vector and using an illegal opcode but both of these seem a
bit messy. Anyone know a quicker/easier method?
UUCP: [ sdcsvax nosc ] !crash!pro-carolina!delton
ARPA: crash!pro-carolina!delton@nosc.mil
INET: delton@pro-carolina.cts.com
Pro-Carolina: 803-776-3936 (300-2400 baud, login as 'register')
US Mail: 3207 Berkeley Forest Drive, Columbia, SC 29209-4111GREYELF@WPI.BITNET (02/27/89)
Would anyone out there like a 65c02 emulator for the 6502? If so I'll write one. -- Michael J Pender Jr Box 1942 c/o W.P.I. greyelf@wpi.bitnet 100 Institute Rd. greyelf@wpi.wpi.edu Worcester, Ma 01609 Who me? I was in Holland buying drugs at the time.
brianw@microsoft.UUCP (Brian Willoughby) (02/28/89)
In article <8902221021.AA05592@crash.cts.com>, delton@pro-carolina.cts.com (System Administrator) writes: > What's the shortest way (code size wise) to test for a 65C02 in software > (disregarding reading ROM ID bytes since the ROM's and CPU's don't > necessarily go together). Mainly I need to differentiate between the 6502 and > 65C02. > > It could be done by setting up an address crossing a bank boundary or by > trapping the BRK vector and using an illegal opcode but both of these seem a > bit messy. Anyone know a quicker/easier method? I don't have the code in front of me, but my test for the 65C02 involved the fix to the indirect JMP ($xxFF) instruction. The 6502 is supposed to get the low byte of the address from $xxFF and the high byte from $(xx+1)00 (i.e. the first byte of the next 256 byte page in memory), the error in the 6502 is that the internal logic didn't increment the upper byte when fetching the indirect address, and the upper byte of the destination is fetched from $xx00. At first I was unsure whether it was valid to assume all 6502's had this error. But I changed my mind when I found an old pre-//e program which used this 'bug' to prevent the uninitiated from easily disassembling their code. It turns out that this game was the only program which wouldn't run on my 65C02 enhanced II+. The algorithm: The trick is to have two routines which start at addresses exactly $0100 bytes apart. Thus the low byte of the starting address of each routine is the same. Store this low byte of the address at $xxFF (i.e. any address ending with $FF). Then store the upper byte of the '65C02 detected' code at the first address of the next page ($(xx+1)00 or $xxFF + 1). Store the upper byte of the '6502 detected' code at the first address of the same page ($xx00 or $xxFF - 255). Then execute JMP ($xxFF), (you pick a page value for 'xx'). A 6502 will jump to '6502 deteced' and a 65C02 processor will jump to '65C02 detected'. If you would like to test for 65C802, then you can put the detection code in the 65C02 routine after you are certain that you are on at least a 65C02 machine. The 65C02 turns all unimplemented instructions into NOP, so a 65C802 test can only be performed with a 65C02 or higher. I think I will go home and get the 65C802 detect code if anyone is interested. Brian Willoughby microsoft!brianw #include <std.disclaimer> /* My comments here bear no relation to my work at MicroSoft */
dvac@drutx.ATT.COM (Daniel Vachon) (03/01/89)
In article <8902270448.AA19901@wpi>, GREYELF@WPI.BITNET writes: > Would anyone out there like a 65c02 emulator for the 6502? > If so I'll write one. > -- > Michael J Pender Jr Box 1942 c/o W.P.I. This is by no means a flame... I think it would be a waste of time to write such an animal. A 65c02 will run in any machine that has a 6502 that I have seen. I have had a 65c02 in a Franklin Ace 1000, an Apple ][+, and of course a //e. It runs fine in all the above. And since they only cost about $8, it seems more sensible just to buy one.... I appreciate the offer... Effort is nice to see! If anyone is wondering about the 65c02 and where to get it.... LOcally, I got mine at Fistells Micro-Electronics down on Colfax in Denver, Colorado... If you want one mail order, I would suggest Jameco Electronics... Later -Dan
jetzer@studsys.mu.edu (jetzer) (03/01/89)
In article <765@microsoft.UUCP>, brianw@microsoft.UUCP (Brian Willoughby) writes: > In article <8902221021.AA05592@crash.cts.com>, delton@pro-carolina.cts.com (System Administrator) writes: > > What's the shortest way (code size wise) to test for a 65C02 in software > > (disregarding reading ROM ID bytes since the ROM's and CPU's don't > > necessarily go together). Mainly I need to differentiate between the 6502 and > > 65C02. [lots of gory details deleted] Here is a routine that someone posted just recently (within a month and a half or so). All I know for sure is that a 65C02 does return a $43, and a ZIP chip will also return the $43. I assume it will correctly identify the other types of processors (I pulled the 6502 out of my unenhanced //e and put the 'C02 in it after I put my ZIP Chip in my enhanced //e). Best as I can figure, it load the acc with #0, then tries to do a BRA (a 'C02 opcode, the "80 02") over an RTS. If you're on a 'C02 or better, it takes the branch, else it returns. Then it loads acc with #38, and tries to perform operation EB on it. This must be an '816 code, which the C02 ignores (or treats as a NOP), loads acc with #43, and returns. (Sorry I can't attribute the code to the original poster. I was getting ready to download it [with lotsa other stuff], and I always strip the headers before transfer to cut down on the xfer time.) ------------------------------------------------------------------------- This might do the job -- this will return what kind of processor you have, no matter what your ROMS are like. 300:A9 00 80 02 EA 60 A9 38 EB A9 43 EB 60 The accumulator holds your processor type: $00 for 6502 $38 for 65816 or compatible $43 for 65C02 If you like you can add "8D FF 02" to the end of that, and store the result in 767 where you can say A=peek(767) -- Mike Jetzer "Hack first, ask questions later."
blackman@phoenix.Princeton.EDU (Scott Michael Blackman) (03/02/89)
In article <450@studsys.mu.edu> jetzer@studsys.mu.edu (jetzer) writes: >> > What's the shortest way (code size wise) to test for a 65C02 in software >> > (disregarding reading ROM ID bytes since the ROM's and CPU's don't >>> necessarily go together). Mainly I need to differentiate between the 6502 and >> > 65C02. > >Here is a routine that someone posted just recently (within a month and a >half or so). All I know for sure is that a 65C02 does return a $43, and > I was the one who posted this a long time ago. (Gosh, I had forgotten completely about it. It loads the accumulator with the correct ASCII value such that you can just print "65" chr$(x) "02". This is how it works: It loads the accumulator with a starting value of $00, skips the 80 02 EA only if it's a 6502 (80 01 causes the 6502 to hang -- the 01 does it, hence the reason for the EA). So if it's a 6502, it then does an RTS. Now, it loads then accumulator with a $38 (ascii for "8" for the 65802 16-bit processor) and does an EB. That's an XBA, which switches the lo and hi bytes in the 16-bit accumulator (obviously if you're on a 65c816) Then it loads the accumulator with ascii "C" and changes the hi and lo again. If the XBA's work, you wind up with "8" and if they don't, you have a "C" (because EB does nothing on the 65C02). So this program (which I do confess came directly from a Call - A.P.P.L.E. example) will differentiate between the 6502, the 65C02, and the 16-bit 65C816/65802 group. You say the Zip Chip looks like a 65C02. If they did it well, it could be indistinguishable from the "real" 65C02 except for the timing. And here's the original program again, reposted (all 12 bytes of it!): >This might do the job -- this will return what kind of processor you have, >no matter what your ROMS are like. > >300:A9 00 80 02 EA 60 A9 38 EB A9 43 EB 60 > >The accumulator holds your processor type: $00 for 6502 > $38 for 65816 or compatible > $43 for 65C02 > >If you like you can add "8D FF 02" to the end of that, and store the >result in 767 where you can say A=peek(767) (actually you add 8D FF 02 before the last 60, and then tack on the 60 after that) Anyway, (oops Mike I just erased your address) -- Scott "WhiteWoman" Blackman __ ARPA: blackman@phoenix.princeton.edu, blackman@pucc.princeton.edu [__] UUCP: ...allegra!princeton!{phoenix|pucc}!blackman BITNET: blackman@phoenix.UUCP, blackman@pucc