V079GUVN@UBVMS.BITNET.UUCP (04/28/87)
The readson you are having trouble with the 65C02 is that it doesn't have bank-switching capabilities, and so ProDos, and in general any language that accesses a Memory Card's upper banks will crash. Try the 65802, it may work, I don't know. - The Priest - V079GUVN@UBVMSC (via BITnet)
schumann@puff.WISC.EDU (Christopher Schumann) (04/30/87)
V079GUVN@UBVMS.BITNET writes: > The readson you are having trouble with the 65C02 is that it doesn't have > bank-switching capabilities, and so ProDos, and in general any language that > accesses a Memory Card's upper banks will crash. > - The Priest The 65C02 does, indeed, not have bank switching capabilities built in. Neither does the 6502, or any 65XX microprocessor. The Apple does allow bank-switching, with external (to the microprossor, that is) hardware to allow this. The latest discussion here says that the 65C02 doesn't work in older ][+'s because they have a small(?) timing problem. Chris Schumann (6502 Guru) schumann@puff.wisc.edu
ranger@ecsvax.UUCP (Rick N. Fincher) (04/30/87)
In article <8704281927.aa23754@SPARK.BRL.ARPA>, V079GUVN@UBVMS.BITNET writes: > > The readson you are having trouble with the 65C02 is that it doesn't have > bank-switching capabilities, and so ProDos, and in general any language that > accesses a Memory Card's upper banks will crash. The bank switching in the //e and //c is done by the computer not the processor. The chip that is in the machine is irrelevant. 65C02's cause problems on some //+ machines because of a timing problem. The Rockwell 65C02's seem to work, as do the 65802's (most of the time). Rick Fincher ranger@ecsvax >
yuan@uhccux.UUCP (Yuan Chang) (05/01/87)
In article <734@puff.WISC.EDU> schumann@puff.WISC.EDU (Christopher Schumann) writes: >The latest discussion here says that the 65C02 doesn't work in older ][+'s >because they have a small(?) timing problem. > >Chris Schumann (6502 Guru) schumann@puff.wisc.edu I thought it'd be due to all those "undocumented" instructions that people use like crazy for copy-protection? Unless all they did with the 65C02 was to document those opcodes... Ever seen one of those programs that's made up of more than 5% of those "undocumented" opcodes? Hard as h*ll tracing the thing. -- UUCP: {ihnp4,seismo,ucbvax,dcdwest}!sdcsvax!nosc!uhccux!yuan ARPA: uhccux!yuan@nosc.ARPA INTERNET: yuan@UHCC.HAWAII.EDU AT&T: (808) 395-1732 "I'm an Amigoid, she's an Amigoid, they're Amigoids, - Yuan Chang - Wouldn't _y_o_u like to be an Amigoid too?"
hsu@eneevax.UUCP (Dave Hsu) (05/03/87)
In article <461@uhccux.UUCP> yuan@uhccux.UUCP (Yuan Chang) writes: >In article <734@puff.WISC.EDU> schumann@puff.WISC.EDU (Christopher Schumann) writes: >>The latest discussion here says that the 65C02 doesn't work in older ][+'s >>because they have a small(?) timing problem. >> >>Chris Schumann (6502 Guru) schumann@puff.wisc.edu > > I thought it'd be due to all those "undocumented" instructions that people >use like crazy for copy-protection? Unless all they did with the 65C02 was >to document those opcodes... > Ever seen one of those programs that's made up of more than 5% of those >"undocumented" opcodes? Hard as h*ll tracing the thing. >-- >- Yuan Chang - Nawwww, you just need more practice. The 65C02 did NOT document those opcodes; they simply used them for other functions. If I remember correctly, GE pulled some one-upmanship and used some of the 65C02's undocumented codes to implement some bit manipulation in THEIR 65C02. Besides, the undocumented codes weren't as good as they were cracked up to be for copy protection. Safer to stick with simple stuff like munging disk timings and the unsuccessful-page-crossing bug (which is fixed in the C02, btw) -dave "I don't remember any 6502 anymore" hsu -- David Hsu Nobody In Particular ARPA: hsu@eneevax.umd.edu UUCP: [seismo,allegra]!mimsy!eneevax!hsu USNAIL: EE Computer Facility, Maryversity of Uniland, College Park, MD 20742 "This house is full of m-m-mistakes"
koko@uthub.UUCP (05/04/87)
> 65C02's cause > problems on some //+ machines because of a timing problem. The Rockwell > 65C02's seem to work, as do the 65802's (most of the time). > > Rick Fincher > ranger@ecsvax Also beware of regular NMOS 6502's. If you have peripheral cards with Rockwell or Synertek 6522's on them, Synertek 6502's will not work properly with them. (This may or may not be true, depending on the glue logic present on the card.) Only Rockwell 6502's will work. The problem seems to stem from the fact that the phi1 and phi2 clock signals available at the peripheral sockets are not the usual clock signals output by the 6502 chip itself. Instead they are complementary clocks generated by the same circuit which generates the (external) clock signal supplied to the 6502 itself. Therefore, the available clocks are about 50ns ahead of what they would be if this were not true.