19,200 on an 850 UltraSpeed Possible?

[+tf_hh]

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

[ricortes]

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.

[ijor]

 

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.

[thorfdbg]

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.

[ijor]

 

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

[phaeron]

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.

[ijor]

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.

 

[sanny]

 

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

[guus.assmann]

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

[ricortes]

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.

[Mathy]

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

[+David_P]

Or go for the 16550 on the PBI / ECI and get the luxury of a 16 byte buffer.

[+DrVenkman]

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.

[Brentarian]

http://www.atarimania.com/documents/PR_Connection_Owners_Manaul.pdf

[Kyle22]

You beat me to it...

 

[+DrVenkman]

Gah, I swear I looked all through Atarimania last night and couldn't find it! Thanks guys.