Dropcheck Posted October 31, 2018 Share Posted October 31, 2018 I am considering taking a dive into recreating a mini-version of the Atari 850. I'm not that familiar with the 850, never having owned one in the day and not really ever working with one either. I have some documentation on it and the rom code. Specifically it will have 1 parallel and 1 serial port. Maybe two versions - one with industry standard wired DB9 and DB25 ports and one with Atari wired DB9 and DB15 ports. What are the strengths and weaknesses? 7 Quote Link to comment Share on other sites More sharing options...
Level42 Posted October 31, 2018 Share Posted October 31, 2018 Heh, it's just a 2600 without a TIA 1 Quote Link to comment Share on other sites More sharing options...
+kheller2 Posted October 31, 2018 Share Posted October 31, 2018 I am considering taking a dive into recreating a mini-version of the Atari 850. I'm not that familiar with the 850, never having owned one in the day and not really ever working with one either. I have some documentation on it and the rom code. Specifically it will have 1 parallel and 1 serial port. Maybe two versions - one with industry standard wired DB9 and DB25 ports and one with Atari wired DB9 and DB15 ports. What are the strengths and weaknesses? Is there a benefit to doing a mini 850 vs an ICD P:R: connection? Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 31, 2018 Share Posted October 31, 2018 Please don't do the 850. Please just let it die. Having spent far too much time with one, and writing software for it, it just needs to die peacefully in its sleep, and not be dragged along by recreation. Why? The 850 suffers from a blind spot in abstraction, you can't, by design, assert the handshaking lines that are present on the first serial port. What? They're right there, it's in the manual. Yes, but only if you're not in concurrent mode. Guess which mode the 850 is in 99% of the time, when you're using it for modem communication? While the 850 is in concurrent mode, it grabs hold of the bus and doesn't let go until concurrent mode is off. While this is happening, it is acting like a simple voltage converter, moving serial bits on and off the RS232 to SIO and vice versa, using the on-board CPU to do so. Because you need to send a fully framed SIO command to assert the different handshake lines, the 850 (and the SIO bus) have no out of band way to pull this off, without literally stopping the process of listening for in-band serial data. So you send a command to the handler to drop concurrent mode (which flips essentially the only handshake that can be done to tell the 850 to go back into command mode), then you send a command to assert the new CTS status, and... oops, some data flew by that you couldn't catch. Flip back into concurrent mode, and... yeah, you lost that data. Repeat. Not to mention the double abstraction of the CPU and voltage conversion (going both directions) slows down the effective transmission/reception rate that the 850 can process (9600 is IT.) So please, can we start working towards connectivity solutions that don't have such ridiculous brick wall design flaws? -Thom 6 Quote Link to comment Share on other sites More sharing options...
Dropcheck Posted October 31, 2018 Author Share Posted October 31, 2018 Is there a benefit to doing a mini 850 vs an ICD P:R: connection? I wouldn't have a problem redoing the ICD P:R connection either. I just have no documentation and do not own one to make signal tracings. Quote Link to comment Share on other sites More sharing options...
manterola Posted October 31, 2018 Share Posted October 31, 2018 It might be great to do an ESP8266 that can "upload" its own R: handler or accept 850 handler (for compatibility reasons), as we have talked many times before. The SIO2wifi thing we have with rverter handler works great, but it is not enough, given the possibilities of the processing power and memory of a cheap esp8266 module. Quote Link to comment Share on other sites More sharing options...
+mytek Posted October 31, 2018 Share Posted October 31, 2018 I wouldn't have a problem redoing the ICD P:R connection either. I just have no documentation and do not own one to make signal tracings. Unless I'm mistaken, I believe the PR Connection utilized a Rockwell 6502 based microcontroller chip with the custom firmware in the embedded ROM, which you would be hard pressed to find in this day and age. However if you could extract that code, then it might be possible to use a 6507 with a 6532 and a standard EPROM to make an equivalent to the Rockwell device. But most likely it would also require remapping some of the memory I/O locations in the firmware to match the new hardware. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 31, 2018 Share Posted October 31, 2018 I love how the one person who has actually dug into the 850 is being ignored, here. -Thom Quote Link to comment Share on other sites More sharing options...
Mathy Posted October 31, 2018 Share Posted October 31, 2018 (edited) Hello Lenore, guys How about this: A new intelligent device with one centronics port (maybe even bi-directional) and a least two RS232 ports. And two SIO ports so it doesn't have to be at the end of the chain. With internal connectors for upgrades that can be added later on. Like a Wifi-Modul or MIDI. The device should be able to communicate a lot faster than the 850. Maybe Thom could write the new OS for this device? (OS as in "the firmware inside the device", not a new OS for the Atari) Sincerely Mathy (developer of ideas, not of hardware, unfortunately) Edited October 31, 2018 by Mathy 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted October 31, 2018 Share Posted October 31, 2018 (edited) You are not the one person, Hello Lenore, guys How about this: A new intelligent device with one centronics port (maybe even bi-directional) and a least two RS232 ports. And two SIO ports so it doesn't have to be at the end of the chain. With internal connectors for upgrades that can be added later on. Like a Wifi-Modul or MIDI. The device should be able to communicate a lot faster than the 850. Maybe Thom could write the new OS for this device? (OS as in "the firmware inside the device", not a new OS for the Atari) Sincerely Mathy (developer of ideas, not of hardware, unfortunately) I like all of this except Thom is not the one to write the OS... it's just not his thing. There is a group of excellent BIOS, OS, and Hardware/Firmware Hero's on the forums who would get us there with it as close to perfect as possible and in a timely fashion. The faster more intelligent device with an 850 'mode' would be the winner, coupled with a proper handler/driver things could really work out, I think a SIO based unit is needed to be an across the line solution.... but remember how much easier, faster, and controllable a PBI solution would be ... a PBI solution could easily be with Printers(if intelligent enough convert for usb printers in a couple modes), 3 serial ports (at least one 20ma) and a lan port.. in fact a true multi I/O with modern ports in general. all that being said... the 850's secrets have been lost to time but a hack or modification could get folks what they want out of it as well. We aren't using all it has to offer and the common everyday built in handler as well as it's companion handler/drivers could be changed to work with whatever hack as well. This area of the Atari has been neglected and forgotten for far too long... a device that could handle divisor zero sio could allow for a multitude solutions. serial stream watch dog choices could be used if you have data flying in at such speed and servicing 300 thru 56k connects.... I'd like to hear more of what Lenore has in mind... we can come off as attacking her ideas, when we talk about what we want or our frustrations dealing with a device. I like the idea of a meaner leaner smaller footprint faster 850, and perhaps the firmware of such could be tweaked to handle flow the way some folks understand it. Edited October 31, 2018 by _The Doctor__ 1 Quote Link to comment Share on other sites More sharing options...
MrMartian Posted October 31, 2018 Share Posted October 31, 2018 I have some notes so far about taking the SDrive-MAX (ATMega32) and adapting it up to the Mega2560... It would give all the SD card goodness there is now, plus two serial ports with full flow control, parallel port, and if I'm feeling jaunty I may also add in the hardware for a WD1772 to control real floppies. I've been toying with an All-in-one SIO peripheral so long, and never thought about developing on an arduino until the SDrive thingy.. So, all the pieces are finally coming together for me.. Except time.. 6 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 31, 2018 Share Posted October 31, 2018 Thanks, Doc, for speaking for me. Really appreciate it. -Thom Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted October 31, 2018 Share Posted October 31, 2018 (edited) I am but a good little chimp, repeating what I've seen and heard. On the off chance I even mimic things to such a degree and make digits wiggle on square pushy things. I mash these repeatedly and funny stuff happens on the glowing thing in front of me. It's great fun! Happy Halloween, Ichabod Chimpanzee... Edited October 31, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Dropcheck Posted October 31, 2018 Author Share Posted October 31, 2018 Unless I'm mistaken, I believe the PR Connection utilized a Rockwell 6502 based microcontroller chip with the custom firmware in the embedded ROM, which you would be hard pressed to find in this day and age. However if you could extract that code, then it might be possible to use a 6507 with a 6532 and a standard EPROM to make an equivalent to the Rockwell device. But most likely it would also require remapping some of the memory I/O locations in the firmware to match the new hardware. I hope not. Supra did much the same thing with the MicroPrint Printer Buffer. I was able to find someone to 'read' the MCU, but it's not an easy process even for him. 1 Quote Link to comment Share on other sites More sharing options...
+Nezgar Posted October 31, 2018 Share Posted October 31, 2018 There's 'better ways' to do it, but reimaging/replicating somewhat hard-to-find / expensive hardware has it's own value and can be done quicker, and is a good 1st step to something improved afterwards. Reimaging the P:R: connection might be the simplest first step since it's a single custom controller chip (PIC?) that does the RAM, ROM, CPU, and PIA. I'd be willing to lend a P:R: Connection for reverse engineering. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted October 31, 2018 Share Posted October 31, 2018 timing between the two always felt or seemed slightly different to me..... never bothered to scope them out or check how the handler/ drivers affected such things... Quote Link to comment Share on other sites More sharing options...
+mytek Posted October 31, 2018 Share Posted October 31, 2018 I hope not. Supra did much the same thing with the MicroPrint Printer Buffer. I was able to find someone to 'read' the MCU, but it's not an easy process even for him. Well I fear that I am correct. Check out this link: http://atariage.com/forums/topic/268787-icd-pr-connection/?do=findComment&comment=3825639 Quote Link to comment Share on other sites More sharing options...
Dropcheck Posted October 31, 2018 Author Share Posted October 31, 2018 The faster more intelligent device with an 850 'mode' would be the winner, coupled with a proper handler/driver things could really work out, I think a SIO based unit is needed to be an across the line solution.... but remember how much easier, faster, and controllable a PBI solution would be ... a PBI solution could easily be with Printers(if intelligent enough convert for usb printers in a couple modes), 3 serial ports (at least one 20ma) and a lan port.. in fact a true multi I/O with modern ports in general. That PBI thing comes very close to what SpaceCowboy is attempting with his project. My own version was much more old school. Essentially I didn't get into anything other than the bus framework that Atari had started. Quote Link to comment Share on other sites More sharing options...
sanny Posted October 31, 2018 Share Posted October 31, 2018 Please don't do the 850. Please just let it die. Having spent far too much time with one, and writing software for it, it just needs to die peacefully in its sleep, and not be dragged along by recreation. Why? The 850 suffers from a blind spot in abstraction, you can't, by design, assert the handshaking lines that are present on the first serial port. What? They're right there, it's in the manual. Yes, but only if you're not in concurrent mode. Guess which mode the 850 is in 99% of the time, when you're using it for modem communication? While the 850 is in concurrent mode, it grabs hold of the bus and doesn't let go until concurrent mode is off. While this is happening, it is acting like a simple voltage converter, moving serial bits on and off the RS232 to SIO and vice versa, using the on-board CPU to do so. Because you need to send a fully framed SIO command to assert the different handshake lines, the 850 (and the SIO bus) have no out of band way to pull this off, without literally stopping the process of listening for in-band serial data. So you send a command to the handler to drop concurrent mode (which flips essentially the only handshake that can be done to tell the 850 to go back into command mode), then you send a command to assert the new CTS status, and... oops, some data flew by that you couldn't catch. Flip back into concurrent mode, and... yeah, you lost that data. Repeat. Not to mention the double abstraction of the CPU and voltage conversion (going both directions) slows down the effective transmission/reception rate that the 850 can process (9600 is IT.) So please, can we start working towards connectivity solutions that don't have such ridiculous brick wall design flaws? -Thom While I do understand your pain, Thom (and I'm feeling the same pain currently white trying to improve the cc65 serial driver), a new 850 "compatible" SIO device sounds like a good idea. Since it provides it's own driver which gets downloaded at boot time, it can work totally different to the 850 under the hood. Imagine a device with 64k input/output buffers which autonomously handles all the RS232 details. The serial line would be disconnected from the SIO bus, and the computer would just read/write the device's buffers. No "concurrent mode". We could go up to 115200 baud or whatever. regards, chris 5 Quote Link to comment Share on other sites More sharing options...
Dropcheck Posted October 31, 2018 Author Share Posted October 31, 2018 There's 'better ways' to do it, but reimaging/replicating somewhat hard-to-find / expensive hardware has it's own value and can be done quicker, and is a good 1st step to something improved afterwards. Reimaging the P:R: connection might be the simplest first step since it's a single custom controller chip (PIC?) that does the RAM, ROM, CPU, and PIA. I'd be willing to lend a P:R: Connection for reverse engineering. I appreciate the offer. In the event that it turns out to be a 'MCU' that needs to be read, are you willing to hazard harm to it? Without that the only thing I could do would be to signal trace the board and reproduce schematics. A board could be made, but the user would have to salvage the 'MCU' from an original board to use it. With a rom dump of the MCU I could devise substitute circuitry. Quote Link to comment Share on other sites More sharing options...
Dropcheck Posted October 31, 2018 Author Share Posted October 31, 2018 Well I fear that I am correct. Check out this link: http://atariage.com/forums/topic/268787-icd-pr-connection/?do=findComment&comment=3825639 You would have to say that..... Quote Link to comment Share on other sites More sharing options...
Dropcheck Posted October 31, 2018 Author Share Posted October 31, 2018 Please don't do the 850. Please just let it die. Having spent far too much time with one, and writing software for it, it just needs to die peacefully in its sleep, and not be dragged along by recreation. Why? The 850 suffers from a blind spot in abstraction, you can't, by design, assert the handshaking lines that are present on the first serial port. What? They're right there, it's in the manual. Yes, but only if you're not in concurrent mode. Guess which mode the 850 is in 99% of the time, when you're using it for modem communication? While the 850 is in concurrent mode, it grabs hold of the bus and doesn't let go until concurrent mode is off. While this is happening, it is acting like a simple voltage converter, moving serial bits on and off the RS232 to SIO and vice versa, using the on-board CPU to do so. Because you need to send a fully framed SIO command to assert the different handshake lines, the 850 (and the SIO bus) have no out of band way to pull this off, without literally stopping the process of listening for in-band serial data. So you send a command to the handler to drop concurrent mode (which flips essentially the only handshake that can be done to tell the 850 to go back into command mode), then you send a command to assert the new CTS status, and... oops, some data flew by that you couldn't catch. Flip back into concurrent mode, and... yeah, you lost that data. Repeat. Not to mention the double abstraction of the CPU and voltage conversion (going both directions) slows down the effective transmission/reception rate that the 850 can process (9600 is IT.) So please, can we start working towards connectivity solutions that don't have such ridiculous brick wall design flaws? -Thom Just because I didn't respond to you, doesn't mean I was ignoring you. I specifically asked for strengths and weakness of the Atari 850. I wanted to know if there were areas where I could make slight changes that would reap benefits. I also needed time to think through and research. It seems that at least some of the issues you raise are actually a limitation of the SIO protocal in a real time two way communication process with no real buffers or UART. At least I'm not seeing a real buffer or UART in the 850 schematic. Not sure about the rest of the issues as I don't have enough experience with the Atari 850 to say yeah or nay. You raise some issues and they are not inconsequential. But we only have SIO and PBI interfaces to work with on the Atari, and I have to start with what's already been done to see how to do it differently or better. Recreating the hardware is part of that process. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted October 31, 2018 Share Posted October 31, 2018 You also have the cartridge port. -Thom Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted October 31, 2018 Share Posted October 31, 2018 cart = partial pbi... pass thru would of course be possible 1 Quote Link to comment Share on other sites More sharing options...
DavidMil Posted October 31, 2018 Share Posted October 31, 2018 But, But... What will I ever do without my teletype port and my old printer that prints so fast, the roll fed paper shoots up into the air when it exits the VW bug sized printer? (I never really had one). David 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.