Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!microsoft!brianw From: brianw@microsoft.UUCP (Brian WILLOUGHBY) Newsgroups: comp.sys.apple Subject: Re: 65c802 Summary: Laser boys don't know their own product Message-ID: <50029@microsoft.UUCP> Date: 14 Feb 90 23:25:16 GMT References: <7905@wpi.wpi.edu> Reply-To: brianw@microsoft.UUCP (Brian WILLOUGHBY) Organization: Microsoft Corp., Redmond WA Lines: 107 In an article greyelf@wpi.wpi.edu (Michael J Pender) writes: >A message to laser 128 users, you can pull the 65c02 and replace it, >but there is one side effect - the internal controller for the 3.5 inch >drives won't work right. I'll bet Laser knows about this but are just playing dumb. Either that or the company that designs the stuff, Video Technology, is so completely removed that they don't care. If anyone has a number for Video Technology. please let me know. >I called Laser computer, and they said it's probably a timing problem >due to the way everything else works fine. Well, it's actually because the 65C802 follows the 6502 spec to the letter in Emulation mode, while the original 65C02 in your Laser didn't. To be precise, most newer disk devices (and Ohio Kache's cache card, too) use the RDY (ready) signal on the processor to do pseudo DMA. This signal is normally high (TRUE) to indicate that memory is ready. If it goes low during a memory access, the processor inserts wait states until the memory is ready again. When the 6502 was originally designed, RDY only worked with Read accesses (I don't know why they didn't include Write accesses). When the 65C02 was designed, it was decided to enhance the operation of this signal to work during both read and write. But this made the 65C02 incompatible with a FEW 6502 board designs (but the stock Apple ][ was not affected). WDC, NCR and Rockwell both make chips of this type. At this point in time, many Apple bus devices were designed to work using RDY, but would only work properly with the 65C02, not the 6502. Then, when Western Design Center designed the 65C802, WDM decided that ultimate compatibility with the TRUE ORIGINAL 6502 was desired for the pin-compatible version of the 16 bit processor. Thus the Native mode of the 65C802 does not support RDY during Write, although in the Native (16 bit) mode, the 'C802 changes to work like the 65C02. BTW, the 65C816 always supports RDY, since you cannot plug it into a board designed for the 6502 anyway. >I do however have a spare UDC card that was laying around, so I'm running >on a 65c802 with my 3.5 inch drive running from the external slot. This is how I found out about the problem. I purchased a UDC for my Apple ][ Plus and I had a similar problem because the UDC wouldn't work for me. Now that I have a //e, the UDC works fine with the 'C802. Curiously, if I use the TransWarp in my ][ Plus with a 'C802, then the UDC will work. But a 'C802 on the motherboard causes the UDC to crash. I assume that this is because the TransWarp makes my Plus appear to be a //e (i.e. you have 128K on a Plus with the TransWarp active). Evidently, the Laser 128 has no support for the 'C802 whereas the UDC tries to support it on the //e (and above?) only. There is a bug in the UDC code, too, because it works on my //e but not my ][ Plus (except with the TransWarp as noted). >This way everything works just fine... > >I made an official request that they look into it, and since its just a >timing problem (probably) it can probably be corrected by just >coming out with a new version of ROM. I bugged Laser quite a bit about the UDC troubles I had, but they claimed that they did not support the ][ Plus (even though the document that came with MY board claimed it would work on a ][ Plus - the person on the phone said their documentation was wrong!). If the 65C802 is switched into Native mode, then the RDY signal acts the same as it does on a 65C02 (i.e. Read and Writes are both extended). All that would need to be done is to switch to Native mode (keeping all 8 bit settings) and RDY will work. Note that the UDC ROMs already have 'C802 code in them (carefully planned to be NOPs on the 65C02). >How would I go about reading the Eprom in my laser, and substituting >a different set of code for the UDC roms? If the processor can execute it, then you can copy the data to disk and reassemble it. Then you can make modifications and burn a new ROM. The hitch is that you have to figure out how to understand about 8 K of uncommented assembly which accesses undocumented hardware I/O! Warning, the UDC code is banked in with 8 segments. The 2K range from $C800 to $CFFE is half RAM and half ROM. The 8 1K ROM segments make 8K total ROM - a real bitch to print out and document/decipher. I suppose that the 3.5 interface built into the Laser 128 works similarly, but if it doesn't you're probably completely out of luck in trying to get the UDC code into your Laser. In this case, modifying the existing Laser 128 code is best. >Whatever equipment would be required, I'm sure its available around >the school here somewhere. You'll need an EPROM burner and some method of getting your modified data into the memory of the burner. I would suggest a Apple bus-based EPROM burner. If you have enough slots on that Laser :-) Brian Willoughby UUCP: ...!{tikal, sun, uunet, elwood}!microsoft!brianw InterNet: microsoft!brianw@uunet.UU.NET or: microsoft!brianw@Sun.COM Bitnet brianw@microsoft.UUCP