Chris_F_Chiesa@cup.portal.com (04/02/89)
In an article whose header Portal doesn't pull into the reply, Jean Goulet writes: > I'm looking for 6502 source code for the handler for the Atari 850 > interface module. [...] If you haven't had any other responses to your query, write me e-mail at Chris_F_Chiesa@cup.portal.com and we can discuss this; I may be able to help. The actual 6502 code that handles the 850 Interface Module is downloaded from the 850 itself at boot time, through a sequence of SIO commands that I've never seen documented but which I have investigated on my own. This approach seems capable of allowing a person to "fool" the 850 into sending the handler to the computer under the control of a debugger (DDT, nee Bug/65) whence it may be saved to disk, investigated in memory, single-stepped, etc. I haven't taken it this far myself, but it seems it ought to be fairly straightforward. One concern is that this will NOT produce "source code." At the immediate level, of course, all one would have would be executable code -- but with proper tools that could at least be disassembled. If this is adequate to your needs, Jean, write me and we'll see if we can work something out. If not, best of luck finding the information you seek. (And, while you're at it, tell me more about this "other" handler you've obtained? I've never heard of it.) Cordially, Chris Chiesa
jean@maxwell.Concordia.CA ( JEAN GOULET | DCKS004 | | ) (04/07/89)
In article <16552@cup.portal.com> Chris_F_Chiesa@cup.portal.com writes: > > In an article whose header Portal doesn't pull into the reply, Jean Goulet >writes: > >> I'm looking for 6502 source code for the handler for the Atari 850 >> interface module. [...] > >The actual 6502 code that handles the 850 Interface Module is downloaded from >the 850 itself at boot time, through a sequence of SIO commands that I've never >seen documented but which I have investigated on my own. > ... (And, while you're at it, >tell me more about this "other" handler you've obtained? I've never heard >of it.) > >Cordially, > > Chris Chiesa I too found out that the handler is in ROM in the 850. Thing is, I don't have an 850 (it's awfully tough to disassemble code that you don't have). Luckily if you use FTP and OPEN 36.8.0.46, and go to the 8-bit directory, you'll find ATARIRS.UUE, which you download and uudecode, and you get an ARC file, and then you deARC that, and you get the object code for the handler (apparently a debugged version). Naturally when you disassemble this you get no descriptive comments, and since the program probably uses all sorts of tricks, it would be very hard to understand. Hence my call for source code. Now why would I want to understand this thing? The answer is that I was wondering how tough it would be to build the equivalent of an 850, or an R-verter (or both in fact). This leads me to ask, if you open up the R-verter, what hardware do you see? My guess is that it's got chips for converting RS-232 signals to TTL signals (and vice-versa, using the MC1488 and MC1489). The problem with this guess is that one of these chips needs a +/- 12V supply, and that's a problem if your only voltage source is +5V (from the serial port; that *is* where the R-verter plugs in, right?). Does the R-verter have an external power supply? What is the maximum baud rate of the R-verter? Also, I once heard that there was already a public-domain version of the R-verter (a schematic at least), so if anyone has/knows of this, let me know. Now I have a few questions regarding the 850: - which serial port on the 850 do you connect a modem to? (1-4) - which pins are used on the atari SIO cable, and which RS232 signal does each pin correspond to? The table below is waiting for the answer. (I added a column for the R-verter in case it's different) from 850 from R-verter RS-232 signal SIO port pin # SIO port pin # -------------------------------------------------------------- TD (transmit data) 5? 5? RD (receive data) 3? 3? CD (carrier detect) ? ? RTS (request to send) ? ? CTR (clear to send) ? ? DSR (data set ready) ? ? DTR (data terminal ready) ? ? SG (signal ground) 6? 6? Once I get this info, I plan on using my unused 64K 400 (yes, they exist, contrary to a message from someone saying that you could only fit 48K in that machine; the 64K board was called the Mosaic 64K Ram Select) as the brains for the 850 emulation. That is, the modem will connect to my RS-232-to-TTL converter, and that will be connected to the 400's joystick port, and the 400's SIO port will be connected to the XE's SIO port. The 400 will appear to be the 850 as far as the XE is concerned. That way any software written for the 850 (i.e. virtually every terminal program) will run without any modification. I'll have to write two programs to make it work: one to handle the RS-232-to- joystick port interface, and another to handle the joystick port/SIO port communication interface. The first program will have to do serial-parallel conversion quickly enough to operate at 1200 bps. Timing will be critical too, so I plan on using interrupts triggered by POKEY's hardware timers. If you have any comments of the type 'it is impossible' then let me know. I figure it's possible because I think Supra/MPP has a 1200 bps modem that connects to the joystick ports, and one of the Volksmodems does that too. The second program that'll be running on the 400 will be the one that sends all the right responses to the XE. I think that'll be the hard part. From what I can tell, I need to know the codes that are send out through SIO that do things like identify the device (R:), say how many bytes are coming, do a checksum, and differentiate between sending *text* to R:, and sending *commands* to R: (such as setting the baud rate or setting parity). If this information is already described briefly in a manual somewhere, it would certainly be a great help to have that transcribed in Email here. Otherwise, I'll have to disassemble the 850 handler to find out. Does anyone have documented source code for the 850 handler, or other modem handlers? Jean Goulet Electrical Engineering Class of '89 Concordia University Montreal, Canada
Chris_F_Chiesa@cup.portal.com (04/10/89)
In another article whose header Portal doesn't pull into the reply, Jean Goulet writes: > Luckily if you use FTP and OPEN 36.8.0.46, and go to the 8-bit directory, Ah, it must be nice to be able to do FTP... never had that luxury ... :-) > This leads me to ask, if you open up the R-verter, what hardware do you see? > My guess is that it's got chips for converting RS-232 signals to TTL signals I believe there'd have to be more to it than that; more below, in the section on pin-to-pin SIO/RS232C correspondence. > Now I have a few questions regarding the 850: > - which serial port on the 850 do you connect a modem to? (1-4) Almost ALWAYS port 1. On the real, true, 850 (and most other terminal- driver boards in existence, for this and other computers, apparently!), the different ports are electrically a little different, e.g. not all "control" signals (DTR, CTS, RTS, etc.) are available/present on all ports. Port 1 is the ONLY one on which ALL signals are present, as I recall. > - which pins are used on the atari SIO cable, and which RS232 signal does > each pin correspond to? The table below is waiting for the answer. Alas, there IS NO direct pin-to-pin correspondence; the information is passed in totally different ways, over the CIO connection, than over the RS232 serial port(s). For what it's worth, the SIO pinout looks like this: Each digit represents the "pin number" of the pin at that position: 2 4 6 8 10 12 1 3 5 7 9 11 13 1 - clock input 8 - motor control 2 - clock output 9 - proceed 3 - data input 10 - +5 / Ready 4 - Ground 11 - Audio Input 5 - Data Output 12 - +12 V 6 - Ground 13 - Interrupt 7 - Command Notes: 1) Pins 7, 9, and 13 are "active low." 2) This obviously has little of anything to do with RS232; the cir- cuitry in the 850 interface builds those signals for the ports, the CPU has nothing to do with them. 3) I call your attention to the presence of 12V on pin 12 -- surprise! > (I added a column for the R-verter in case it's different) Alas, I have no information for you about the Rverter... > That is, the modem will connect to my RS-232-to-TTL > converter, and that will be connected to the 400's joystick port, and the > 400's SIO port will be connected to the XE's SIO port. You're going to have to do more than just convert signal levels, from the look of it. (Accidentally deleted the part about needing to know the difference between "sending data" and "sending commands" to the 850... That, I believe, is referred to in the official literature as "data frames" and "command frames" sent over the SIO bus.) This stuff comes from Section 9 of the Atari OS User's Manual... This is the section describing the SIO Serialk I/O Handler... "... All bus transactions are expected to conform to a universal protocol. The protocol includes three forms, stated below (as seen from the computer): Send command frame. Send command frame and send data frame. Send command frame and receive data frame. The values of the W and R bits in the status byte select the command form." (The "status byte" referred to, is that at DSTATS (hex 0303) when an SIO call is made. The W bit is bit 7 (high end), and the R bit is bit 6. W,R = 0,0 means "no data transfer associated with operation" 0,1 means "data frame is expected from the device" 1,0 means "data frame is to be sent to the device" 1,1 is invalid) There's a whole flock of information on the electrical characteristics, byte and frame organization of data etc. over the SIO bus... Too much to type in here-and-now; Jean, send me some E-mail and remind me "section 9, OS Manual, page 145"!