+tf_hh Posted February 21, 2017 Share Posted February 21, 2017 Edit: And it would do 19,200, 38,400 or better... I create a proof-by-concept solution some years ago using the 16C550 well-known UART from the PC world. This one is easy to integrate in a 8 bit Atari system. I made a breadboard prototype which enables the UART at the PIA address range ( I choose $D340-$D347, but this isn´t fixed). Technically it works. The only problem was... no software. I intented to use the UART interrupt-driven and would code a R: handler for it. But I´m not so good and fast in coding as in doing hardware Such a solution should offer a relocable (address independent) resident R: handler for standard DOS and SDX. If somebody is able to write a device driver, I would digging my basement, search for the breadboard solution and make a modern PCB. Jurgen 3 Quote Link to comment Share on other sites More sharing options...
ricortes Posted February 21, 2017 Share Posted February 21, 2017 I am still campaigning against copper wire. I finally started working on my ESP8266 modules and IMNSHO, that is the way to go. I've got them working and connecting locally and as far as sending a ping to google.com. Not that the fast serial chips like the 16550 aren't great, just that they still require some support like a Lantronix or Intel box server to get them out on the net. I've got all the parts to put an Atari to them but I am getting tugged in all directions right now. Anyway, the ESP8266s start at ~$3 and the really nice ones with on board regulator go for less then $10. The development environment for the ESP8266 is kind of the wild West right now with people doing everything from Lua to BASIC. No need to program them though as the AT command set they come with is good enough for us. Quote Link to comment Share on other sites More sharing options...
ijor Posted February 21, 2017 Share Posted February 21, 2017 Probably not. For that, you need to know how the 850 works. If you enable the concurrent mode, then the serial speed is really up to Pokey. What the 850 does in this case is that it samples the input serial line, and mirrors the output, 1:1. It does this by polling the input line with the CPU, and simply placing the same signal at the output. Thus, the bitrate is limited by the (half the) highest frequency the 1Mhz CPU within the 850 can sample the data. There is a good reason why the 850 is limited to 9600 baud. Just thinking in loud voice. Didn't actually try anything, and I am really not very familiar with the 850 ROM for that matter, but from my experience with custom 1050 code ... It sound that it should be feasible to improve upon the 9600 limit on concurrent mode. The CPU, again, as the 1050, can do over ~52K at the SIO line. Yes, I realize the loop required in this case is more complicated, but yet ... In the worst case it also sounds as it might be possible to perform faster with some buffered mode. Receive from the serial port at, say, 38000 bps, shouldn't be a problem. Then pause the serial input with flow control and transmit over the SIO port at USD high speed. Even when the serial input is stopped while transmitting to the computer, in theory it should be two or three times faster than concurrent mode at 9600 bps. Of course, the actual effective rate would depend on the overall latency of the flow control, and if it can be handled by the modem or the remote end must be paused as well. Haven't done anything with modems for years. Anybody knows, or remember the buffer size of those modems? Of course that alternative hardware can do much better. But the above might require just a custom ROM. 1 Quote Link to comment Share on other sites More sharing options...
thorfdbg Posted February 21, 2017 Share Posted February 21, 2017 It sound that it should be feasible to improve upon the 9600 limit on concurrent mode. The CPU, again, as the 1050, can do over ~52K at the SIO line. Yes, I realize the loop required in this case is more complicated, but yet ... Please understand the difference. In case of the 1050, a dedicated serial shift register does the transfer, but for the 850, the CPU samples the line manually by polling the state of the input. Let's make some computation: At 9600 baud, each bit is 104 us long. The CPU in the 850 is clocked at 1Mhz, this makes 1us per clock. To sample the data reliably, you need to sample *at least* every 52us, or hence 52 cycles. That is *not that much* given that the CPU must sample both incoming and outgoing data, and must check the state of the command line to react on SIO commands. Things would be different if the 850 would simply have a "pass-through" logic (a simple switch) that would directly reroute input to output, but that's not how it is done. 1 Quote Link to comment Share on other sites More sharing options...
ijor Posted February 21, 2017 Share Posted February 21, 2017 (edited) It sound that it should be feasible to improve upon the 9600 limit on concurrent mode. The CPU, again, as the 1050, can do over ~52K at the SIO line. Yes, I realize the loop required in this case is more complicated, but yet ... Please understand the difference. In case of the 1050, a dedicated serial shift register does the transfer, but for the 850, the CPU samples the line manually by polling the state of the input. Not at all. The 1050 uses (almost) exactly the same hardware as the 850. Same CPU at same clock, same RIOT device for the I/O ports. There is no serial shift register in the 1050. The 1050 CPU polls the SIO line manually, same as the 850 does both for the SIO and the serial ports. Unless you mean the serial register at the FDC when reading from the disk? That is not relevant. That is *not that much* given that the CPU must sample both incoming and outgoing data, and must check the state of the command line to react on SIO commands. As I said, I do realize the loop required in this case is a bit more complicated than when simply polling the SIO input. But we know that the USD with the same hardware can poll and receive reliably at ~52KB. That's almost 6 times faster than 9600 bps. Didn't counted instruction cycles, but surely the loop is not that much complicated to require six times more cycles. Edited February 21, 2017 by ijor 1 Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 22, 2017 Share Posted February 22, 2017 The 1050 does bit-bang SIO communications with the CPU like the 850, but there are important differences. The 1050 only needs to deal with half-duplex communication, whereas the 850 has to do full duplex. That means that the 1050 can synchronize its code to the bit phase of the data transmissions in either direction while the 850 can't. The 1050 also has the benefit of being able to ignore command line status during the transfer since it deals with block transfers of a known and relatively short size. BTW, doesn't the 850 have the ability to run test code from the computer? Thought I saw that somewhere in the controller source code. Quote Link to comment Share on other sites More sharing options...
ijor Posted February 22, 2017 Share Posted February 22, 2017 The 1050 does bit-bang SIO communications with the CPU like the 850, but there are important differences. The 1050 only needs to deal with half-duplex communication, whereas the 850 has to do full duplex. That means that the 1050 can synchronize its code to the bit phase of the data transmissions in either direction while the 850 can't. Bit phase synchronizing seems to be here the most complicated issue indeed. Guess that a lot it depends on how much space in ROM is available. Might be an interesting coding challenge. Btw, perhaps the most efficient modern implementation could be to enhance one of the SIO devices such as the newer SDrive-ARM, with just the serial signals available at a simple header, or if the board is not too small, include unpopulated headers for a max232 or similar voltage level converter. 1 Quote Link to comment Share on other sites More sharing options...
sanny Posted February 23, 2017 Share Posted February 23, 2017 If somebody is able to write a device driver, I would digging my basement, search for the breadboard solution and make a modern PCB. I'd volunteer :-) regards, chris 2 Quote Link to comment Share on other sites More sharing options...
guus.assmann Posted February 23, 2017 Share Posted February 23, 2017 (edited) Please have a look at the attached files. This is a PCB for the cartridge slot. And I've build it and checked if I could read the registers. That worked quite fine. The Uart is the same as on the blackbox. It would be better to decode the address a bit further, but that's about all. There's just no software, as I didn't want to spend the time for that. Although it shouldn't be too difficult, I've once written a RTC-clock driver and that worked just fine. BR/ Guus UART.zip Edited February 23, 2017 by guus.assmann Quote Link to comment Share on other sites More sharing options...
ricortes Posted February 23, 2017 Share Posted February 23, 2017 Hello Guus. I've built a 6551 cart too and a real problem is lack of an interrupt line in the cartridge slot. Polling for byte ready really eats up the cycles and you can never go off and do something else w/o losing data. Same design with a ECI type connector would be a huge improvement. 1 Quote Link to comment Share on other sites More sharing options...
Mathy Posted February 23, 2017 Share Posted February 23, 2017 Hello guys Why not turn this into an upgrade for the BB? It has the interrupt line, the 6551 and Bob Puff already wrote the code (which I thought I had on my site somewhere, but apparently I don't). Sincerely Mathy 2 Quote Link to comment Share on other sites More sharing options...
+David_P Posted February 24, 2017 Share Posted February 24, 2017 Or go for the 16550 on the PBI / ECI and get the luxury of a 16 byte buffer. 2 Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted March 29, 2017 Share Posted March 29, 2017 So I have an ICD P: R: Connection and just learned today that ICD advertised it has having an internal R: device handler. I did a search and couldn't find a scanned copy of the manual or any other documentation anywhere, but this thread came up as a search hit due to the posts in the first page. Does anyone here have a copy of the manual or any details they can share? Thanks. Quote Link to comment Share on other sites More sharing options...
Brentarian Posted March 29, 2017 Share Posted March 29, 2017 http://www.atarimania.com/documents/PR_Connection_Owners_Manaul.pdf 1 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted March 29, 2017 Author Share Posted March 29, 2017 You beat me to it... 1 Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted March 29, 2017 Share Posted March 29, 2017 Gah, I swear I looked all through Atarimania last night and couldn't find it! Thanks guys. Quote Link to comment Share on other sites More sharing options...
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.