Atari 850 - Possible to chain two of them and get 8 com ports?

[JonnyBritish]

Just wondering

 

If I connect two 850's will I end up with

a - an error message

b - 8 com ports?

 

Just curious, not planning to bring up an 8 line BBS etc :-)

[Rybags]

Don't think you can do that - for smart SIO devices, they must have unique device numbers. AFAIK, the 850 has no way to change that like disk drives with their 2 switches.

[UNIXcoffee928]

One of the main problems is that when the Atari system is turned on, the 830 automatically sends it's ROM-based handler to the computer.  The 850 manual states that the handler is 1762 bytes in length. It would be interesting to see a disassembly of the transmitted handler.

 

In any case, the OS itself would receive duplicate handler info. This might crash the system, or may invalidate the functionality of the 850, or it may just just be the case that the system ignores the second 850. Who knows, maybe the second 850 would mirror the functions of the first 850 (printing the same document to two different parallel printers, or sending the same info over RS-232...) the later is highly unlikely, but maybe it would work.

 

Anyway, the one thing that you can't do (out of the box) is to make them two different parallel ports & two different sets of serial ports... unless you were able to hack the handler ROM in the second 850, and replace it with a bit of modified code on an EPROM. The modification should also include a time delay, before sending the modified handler, so as to not clash with the first 850's transmission, and to get to the Atari OS while it's not busy with the first 850. After that, then the modified 850 handler that gets transmitted from 850 #2 would need to be integrated with the OS handler table itself, in a method similar to the standard 850, but with a different entry. 

 

So, yeah, it could be done. It's definitely not an easy hack, but then again it's not entirely crazy-hard, either. I'm pretty sure that anyone who has hacked cartridges & HATABS could do it in a weekend of hackery. It would be pretty cool.

[thorfdbg]

One of the main problems is that when the Atari system is turned on, the 830 automatically sends it's ROM-based handler to the computer.  The 850 manual states that the handler is 1762 bytes in length. It would be interesting to see a disassembly of the transmitted handler.

 

While not a disassembly of the handler, you may find a re-implemented 850 handler here:

 

http://www.xl-project.com/

 

at the atari++ home page. Download the os++ sources, and dig into the file 850.asm. This is the 850 handler. Unlike the original, it does not support multiple units, just one, and has a couple of bugs fixed (specifically parity and character transposition).

 

In any case, the OS itself would receive duplicate handler info. This might crash the system, or may invalidate the functionality of the 850, or it may just just be the case that the system ignores the second 850. Who knows, maybe the second 850 would mirror the functions of the first 850 (printing the same document to two different parallel printers, or sending the same info over RS-232...) the later is highly unlikely, but maybe it would work.

 

The problem is not only the duplication of the handler. The handler would obviously try to install R: twice, resulting in either the first or the second copy active, but this is the least problem. The problem is that both 850 would use the same SIO device identification on the SIO bus, causing endless I/O errors with the communications, i.e. serial communications would fail. Furthermore, for retrieving data, the 850 must take over the SIO bus completely, blocking all other I/O operations on it. This implies that only one 850 can be connected to the SIO bus at once.

 

So, yeah, it could be done. It's definitely not an easy hack, but then again it's not entirely crazy-hard, either. I'm pretty sure that anyone who has hacked cartridges & HATABS could do it in a weekend of hackery. It would be pretty cool.

 

Again, the problem is the concealed mode of the 850 - you could only retrieve data from one of them at a time, and would block the SIO bus completely from any other I/O operation, making the second unit useless. It's a protocol design issue, not a hardware or handler issue.

 

So long,

Thomas

[Rybags]

A second handler would be pointless.

 

A more likely alternative would be to just assign the subsequent SIO devid to the second 850 and have it not ever send a handler.

 

Then, if necessary the default handler would need to be modified to cater for the second 850.

[JonnyBritish]

Interesting discussion guys, as said just curious. I now have 3 Atari 850's. Is there anything out there describing in detail how SIO works. For instance If i plugged a SIO cable into the end of my SIO chain could i take one or more of the outputs and use a micro controller to report what is happening on the bus?

 

thinking it would be a pointless but fun exercise to use a parallax propellor with an LCD to report status of the SIO bus.

[Curt Vendel]

Source code to the 850:

 

850.zip

 

 

Curt

One of the main problems is that when the Atari system is turned on, the 830 automatically sends it's ROM-based handler to the computer.  The 850 manual states that the handler is 1762 bytes in length. It would be interesting to see a disassembly of the transmitted handler.

 

In any case, the OS itself would receive duplicate handler info. This might crash the system, or may invalidate the functionality of the 850, or it may just just be the case that the system ignores the second 850. Who knows, maybe the second 850 would mirror the functions of the first 850 (printing the same document to two different parallel printers, or sending the same info over RS-232...) the later is highly unlikely, but maybe it would work.

 

Anyway, the one thing that you can't do (out of the box) is to make them two different parallel ports & two different sets of serial ports... unless you were able to hack the handler ROM in the second 850, and replace it with a bit of modified code on an EPROM. The modification should also include a time delay, before sending the modified handler, so as to not clash with the first 850's transmission, and to get to the Atari OS while it's not busy with the first 850. After that, then the modified 850 handler that gets transmitted from 850 #2 would need to be integrated with the OS handler table itself, in a method similar to the standard 850, but with a different entry. 

 

So, yeah, it could be done. It's definitely not an easy hack, but then again it's not entirely crazy-hard, either. I'm pretty sure that anyone who has hacked cartridges & HATABS could do it in a weekend of hackery. It would be pretty cool.

[charliecron]

One of the main problems is that when the Atari system is turned on, the 830 automatically sends it's ROM-based handler to the computer.  The 850 manual states that the handler is 1762 bytes in length. It would be interesting to see a disassembly of the transmitted handler.

 

I could be wrong but I think it's more like

 

"When the Atari system is turned on, without a disk drive present, the 850 automatically send it's.........."

 

Minor point but worth noting. When a disk drive is present the handler does not automatically get sent, right?

 

Charlie

[Rybags]

The OS Manual tells you most of what you need to know about SIO.

 

Every device on the bus receives commands and data from the Atari, so it would be very easy to capture an activity log, although I don't know if there's anything out there specifically dedicated to do so in a more verbose manner than e.g. APE.

 

Also, you'd want downstream data from peripherals captured, which is normally sent by APE, not read by it.

 

 

Even if you can't easily capture data that'd normally be "input" from the Atari POV, if you have the command/aux stream logged, you could just recreate it from the Atari with a user program anyway.

[Urchlay]

Every device on the bus receives commands and data from the Atari, so it would be very easy to capture an activity log, although I don't know if there's anything out there specifically dedicated to do so in a more verbose manner than e.g. APE.

 

Also, you'd want downstream data from peripherals captured, which is normally sent by APE, not read by it.

 

AtariSIO's verbose logging is pretty detailed. Can't remember whether it logs its own commands when sending them, but, eh, it's open source, could make it do so if it doesn't.

[UNIXcoffee928]

One of the main problems is that when the Atari system is turned on, the 830 automatically sends it's ROM-based handler to the computer.  The 850 manual states that the handler is 1762 bytes in length. It would be interesting to see a disassembly of the transmitted handler.

 

I could be wrong but I think it's more like

 

"When the Atari system is turned on, without a disk drive present, the 850 automatically send it's.........."

 

Minor point but worth noting. When a disk drive is present the handler does not automatically get sent, right?

 

Charlie

If you are only using the 850 for the parallel port, then the 850 can be turned on after you turn on the system. If you are going to use the serial ports, the 850, & 810/1050 disk drives must be turned on first, before the system is turned on. The 850 will then send the serial handler to the Atari computer, and can be used for serial &/or parallel transmissions. Specifically, pages 9 & 10 of the  850 manual describe this method of operation, while page 11 describes all possible power on scenarios, in Table 2.1.

 

 

- Thanks, Curt, for the speedy info!

 

- Thanks, Rybags, Urchlay, & thorfdbg, for clearing that up, with specifics... I was just throwing some hypotheses out there, about what might happen if you hooked up two 850s with no modifications; it is now apparent that an advanced knowledge of the protocol of the SIO bus also would be needed to solve the problem, if there actually is a worthwhile solution.

 

I do have a second 850 here, that I can test on, if someone who is more familiar with all of the puzzle pieces wants to try something out, but doesn't have the equipment to do so.

 

I, personally, can't totally delve into it, in a hearty fashion, right now; I'm in the midst of hacking a  Draco Casablanca digital video editor system with a 68060 in it... there's not much documentation (only a little info on the earlier two Draco models, that it was based on.)... I'm going to try to get it to run a standard version of Amiga OS, rather than it's built-in application-specific, special purpose version of Amiga OS... and it's going to be taking a chunk of time... I'm really crossing my fingers though, it would be an awesome Amiga to develop on, in preparation for The Coming of Natami. It was originally produced in Germany... maybe someone here from Europe has some tech info on it... If so, I'd be really interested in checking it out.

 

My plan is to put it's SCSI hard drive in my pc, and get enough info from it, in UAE to make a replacement drive to try out in it. Should be cool if I can get it to work, no one else has attempted it, yet. I plan on documenting everything, so that others can make an Amiga out of it... it's a pretty powerful hardware config for an Amiga, and the Casablanca usually sells cheaply, these days... way cheaper than any similarly configured Amiga. Should be really cool. Crossing fingers.

[Rybags]

You'd almost certainly need a firmware change on the 850, unless for some reason they put Serial ID bridges in that you could join to change the ID (most unlikely).

 

The driver would also need to be altered. It appears that multiple device numbers are used, likely for the different ports on the 850. So, maybe something like R1: - R4: (or whatever the range is) for the first one, and R5: ... for the second 850.

 

Fair amount of work, and probably not worth it given that we have other I/O expansion options available to us these days.

[Urchlay]

I'd be curious to know what happens if you do this:

 

1. Turn on first 850 (with a printer plugged into it)

2. Turn on Atari computer

3. Wait for the long beeeeep that tells you the 850 driver's loaded

4. Turn on 2nd 850 (with another printer plugged into it)

5. Try to print something

 

Does the SIO protocol say that all frames have to be ACKed, even for an output-only device like a printer? It's been so long since I had a printer hooked up to an A8 that I honestly can't remember squat about how it works at the SIO level (if I ever knew).

[Rybags]

You'd have both 850s trying to respond to SIO requests.

 

You can simulate the same thing by setting 2 x 1050s to the same devid, or by having a 1050 and APE virtual drive the same.

 

There would be cases where commands would be executed by both, and there might be sufficient difference in response times that the host got "normal" responses, but I reckon it'd be a very intermittent thing at best.

 

Even if it did work, all you're achieving is doubling up on a given action (e.g. printing a line of text), so it wouldn't be of great use.

[charliecron]

One of the main problems is that when the Atari system is turned on, the 830 automatically sends it's ROM-based handler to the computer.  The 850 manual states that the handler is 1762 bytes in length. It would be interesting to see a disassembly of the transmitted handler.

 

I could be wrong but I think it's more like

 

"When the Atari system is turned on, without a disk drive present, the 850 automatically send it's.........."

 

Minor point but worth noting. When a disk drive is present the handler does not automatically get sent, right?

 

Charlie

If you are only using the 850 for the parallel port, then the 850 can be turned on after you turn on the system. If you are going to use the serial ports, the 850, & 810/1050 disk drives must be turned on first, before the system is turned on. The 850 will then send the serial handler to the Atari computer, and can be used for serial &/or parallel transmissions. Specifically, pages 9 & 10 of the  850 manual describe this method of operation, while page 11 describes all possible power on scenarios, in Table 2.1.

 

 

 

I guess I am trying to say, there is a scenario where the 850 will not automatically upload.

 

If you turn on the computer after the 850 & disk drive, and the disk has no handler, the 850 will not upload to the computer.

 

While if you boot without a disk drive it will always send the handler.

[thorfdbg]

I'd be curious to know what happens if you do this:

 

1. Turn on first 850 (with a printer plugged into it)

2. Turn on Atari computer

3. Wait for the long beeeeep that tells you the 850 driver's loaded

4. Turn on 2nd 850 (with another printer plugged into it)

5. Try to print something

Mess on the SIO port... Both 850 will try to acknowledge the command, with the result that the SIO communications will break down because the signals will collide.

 

Does the SIO protocol say that all frames have to be ACKed, even for an output-only device like a printer?

Well, "almost". Yes, on the SIO chain every command has to be acknowledged, including the printer commands.

 

The only exception to this is the tape recorder because it is a "dump" device (it doesn't have any microcontroller on board). This is also the (or *a*) reason why you need a printer interface. Your average 1980's or 1990's printer would only have a parallel port which simply accepts data without much of a protocol. (Things changed nowadays with most printers either being part of a network or using USB for communications, with again requires "intelligence" in the device).

 

So long,

Thomas