Jump to content
IGNORED

ST/Amiga serial speed not a priority?


Recommended Posts

Hey folks,

 

Just curious -

 

The Atari 8bit SIO serial port operated at 19200 bps by default; and looks like it's reliable to much higher speeds (52000+ bps for Happy disk upgrade?, even more for other modifications). For serial modems, of course the highest we really saw was 9600 bps (via Atari 850 interface, which launched with the 800).

 

I was always curious why the ST (and Amiga's Paula now that i've researched) seem to have trouble pushing more than 19200 bps reliably (without CPU acceleration)? I know for the ST there are some patch routines that enable 38400 bps operation; although i'm not sure how reliable that is (I assume if the ST can keep up with MIDI at 31250 bps, 38400 isn't too far out of reach). On the OCS amigas (1000, 500), and even the stock CPU Amiga 1200 faster than 19200 bps is somewhat tenuous.. you *might* get 38400 bps on the Amiga 1200 with the lowest screen resolution/colors..

 

Why was a faster serial port not a priority for the ST or Amiga? I know modem speeds were quite slow but this 'step back' always seemed rough to me on the ST. (Before I switched to PC I had a USR modem that could do 21.6 kbps.. hampered by the ST's 19.2 kbps serial port).

 

If I'm off on any assumptions, feel free to correct - I'm asking for education :).

 

Thanks!

John H

Link to comment
Share on other sites

I think you can get 38400 on the ST if you upgrade the serial port driver. With the same updated driver, the Falcon can easily work at 115200. As to why, I don't really know, someone with better technical knowledge should be able to explain.

 

However, I don't think you should compare it to the A8 SIO port. SIO is custom serial interface while the ST/Amiga serial ports were following the industry standard. I guess we should compare to what pc's had at the time.

Edited by Christos
Link to comment
Share on other sites

Ok, I'm going to attempt a couple of educated guesses here. Keep in mind that they're only guesses and I haven't looked deep into the subject so I may be way off here :). With this disclaimer out of the way...

 

The problem with the serial port is that there's no DMA capability. That is, there's no magic hardware that handles I/O - the cpu must take care of this on its own. Which means in order to handle a steady speed rate we're going to need interrupts.

 

Let's assume that the machine is running at 50Hz vertical display frequency. So for a transfer speed of 19200 baud we'll have to interrupt 19200/50=384 times inside a vertical blank (or a frame if you prefer).

 

Now, let's say we take around 100 cycles to service each interrupt, that's 384*100=38400 cycles per VBL. This is not an unreasonable number I think.

 

Each VBL in 50Hz consists of about 313*512=160256 cycles.

 

If we divide the number of cycles per VBL with the total number of (guesstimated) cycles taken for the interrupts we get a factor of 4.17333. Which is bigger than 1, which means that if we attempt such a transfer we won't get overrun by ourselves. So that's fine. Also, if we assume 60Hz or 71Hz (for NTSC and mono monitors) then this factor gets lower, but still larger than 1 by a good margin which is again fine.

 

When we double the speed to 38400 that factor becomes half of the above, around 2.08. Now this again looks safe but for starters if we allow 60 and 71Hz it starts getting close to 1 which isn't good. Also a factor of 2 there means that the rest of the system is running at half the optimum speed due to us hammering the serial port. Now, add the cost of mouse/keyboard interrupts, any vertical blank routines, timers, software screen refreshes etc and we're not left with much CPU time.

 

So yeah my guess is that 38400baud is stretching it a bit. If we take over the system (i.e. freeze it during transfer) and use all available cycles for ourselves then it's doable. But with the system running? Probably asking too much of the poor thing.

 

Before I forget, the numbers above are for unidirectional transfers, if you add bidirectional (i.e. send/receive) then we need to halve those factors. This gets even more dangerously low!

 

Anyway, that's my take. I haven't coded any serial comms on the ST so like I said it's mostly guesswork. Anyone has better insights - feel free to correct any of this!

  • Thanks 1
Link to comment
Share on other sites

The ST can run very high serial speeds if retrofitted wih a Z85230 ESCC controller (similar to the one found in the Mega STE/TT030/Falcon030 models and thus compatible with these), though.

Did not know you could actually retrofit the STfms.. I switched from ST to PC originally back in 1989-1990 (USA), so no such upgrades were available at that time..

 

I was just curious why the engineers never pushed for much more serial speed with a 'much faster' 16-bit generation.

Link to comment
Share on other sites

Ok, I'm going to attempt a couple of educated guesses here. Keep in mind that they're only guesses and I haven't looked deep into the subject so I may be way off here :). With this disclaimer out of the way...

 

<snip>

 

Anyway, that's my take. I haven't coded any serial comms on the ST so like I said it's mostly guesswork. Anyone has better insights - feel free to correct any of this!

 

The math makes perfect sense to me.. Was POKEY using DMA on the A8 to allow for the higher reliable speeds, despite the much slower bus (8bit * 1.77-1.79 mhz vs 16-bit and 7-8 mhz) and slower CPU?. I guess 1985 was too early for buffered serial ports ?

Link to comment
Share on other sites

Just been sending AT commands to an HC-06 Bluetooth module plugged directly into the A8 SIO port here at 57k, bypassing the SIO software protocol, so the A8 serial implementation isn't too far removed from the standard. 126Kbps is pretty reliable with a short NMI and IRQs turned off, all driven by the CPU.

Link to comment
Share on other sites

ST has the DMA port for using HDD and Amiga has the edge connector for it's HDD + Ram expansions.

 

The attitude to serial at the time tended to be that it was a dying interface and parallel ones would be the norm and it did head that way for while. Of course parallel hit the big wall in that once you get into the 100 Meg/second range the bits start arriving at different times, so logically it was back to serial.

And thanks to nice ideas like differential pairing and encoding methods like 8b/10b we can now get bitrates into the gigabit range on a single pair, with modern protocols like USB 3 and PCIe in fact using a sort of hybrid of serial/parallel in that multiple serial lines transmit multiple bytes at a time that are reassembled at the receiving end.

 

I'm not sure when the FIFO type serial buffering became widespread on PCs but even in their case weren't they limited to about 115 kb/sec ?

The other thing with a lot of those peripheral interface chips is they seem to only allow a subset of bitrates as well. Unlike Pokey which tends not to land on exact industry standard bitrates but has a wide possible range where arbitrary rates are possible and of course has that built in 5% of so allowance of drift and automatic resyncing.

  • Like 1
Link to comment
Share on other sites

Hello all,

 

In my opinion, the calculation ggn has made, applies to "controlled bit banging"

Also, for serial communication, there's: Start-bit, data bits 7 or 8, parity and one or two stop bits. (just below 50% overhead)

 

Most serial port periperals have a UART capability. This reduces the amount of processing power needed.

The UART takes care of the timing and addition of the extra bits, also does "flow-controll". And often it has a buffer.

So the CPU gets an interrupt once the byte is send or received. And there's also a 'Data overrun flag"

 

For the 8-bit, the 850 modul did all of this work for the computer.

And without the 850, the Pokey did part of the work, like a Uart would.

 

So there's more to the story I think..... And it's not really possible to compare the systems, as the results are reached in completely different ways.

 

BR/

Guus Assmann

Link to comment
Share on other sites

  • 4 years later...

I know this is an old thread, but I just found it and I think it is worth to provide an answer, well at least the for ST side.

 

The maximum bitrate for the serial port in the ST, a standard ST, is 19200 bps. And this is a hardware limitation, not a software one.

 

The ST doesn't bitbang the serial port. It has an UART, actually USART, chip. This the 68901 usually called MFP. The 19200 bps limitation arises from the maximum serial clock that the hardware can generate. The MFP can receive an external clock to drive the serial communication, but in the ST this clock is actually wired to the output of an MFP timer itself. That is, one of the MFP own timers is used to generate the serial clock.

 

The math is as following: 2.4576 MHz /4 /2 /16 = 19.200 KHz

 

2.4576 MHz is the frequency of the crystal that clocks the MFP timers.

/4 because that is the minimum prescaler of the MFP timers.

/2 because each time the timer overwarps it toggles the output pin. But you need two toggles, one up and one down to generate the clock's cycle pulse.

/16 because the MFP (normally, see below) divides the serial clock by 16.

 

That's the origin of the maximum 19200 bps.

 

Having said that, it is worth to note that it is possible to configure the MFP to use serial clock directly without dividing it by 16. That would bring the serial rate to a whooping 19200*16 = 307 Kbps!

However this configuration is meant to use in synchronous mode. In synchronous mode both ends of the transmission share the same clock signal, not just the same clock frequency. The MFP receiver can't work reliably at asynchronous without using the /16 configuration (and there is no configuration in between, it's 1/1 or 1/16).

 

But that's a limitation of the receiver. In theory, it is perfectly possible to transmit using the 1/1 serial clock divisor. This is because from the point of view of the transmitter, transmission is actually always synchronous. I didn't test it and I don't know if somebody tried, but I suppose this should work. And it should be possible to implement some kind of "asymmetric" protocol receiving at 19.2 Kbps and transmitting at 307 Kbps. This could be very useful to transmit files from the ST. It would probably require custom software at the other end, besides special software at the ST side as well, of course.

 

 

Edited by ijor
  • Like 4
Link to comment
Share on other sites

Serial port (RS232) is really something outdated, well, long time ago. Only reason why someone wants to use it may be having some device with it, and wants to communicate, transfer with it and Atari ST.  And even speed of 307 Kbps sounds as slow now - some 35 KBytes per/sec - about floppy speed range.

Of course, real thing why only few people cares for serial port on Atari now is that you don't have where to connect it. Well, could use something like RS232-USB adapter, I guess. But then, why not go with PARCP, USB version ? Or NetUsBee ...

 

Btw. as I remember, there are some HW mods/hacks to make Atari ST serial port faster. That needs for sure some SW/driver too.

Link to comment
Share on other sites

6 hours ago, ParanoidLittleMan said:

Serial port (RS232) is really something outdated, well, long time ago

Not completely dead, quite a lot of modern equipment (Cisco routers, switched, hubs) all require

initial setting up via it's serial port, I used the have to use a USB to Serial adapter to connect my

laptop to these devices. Obviously once set up you could use Ethernet

Link to comment
Share on other sites

I know the MC6850s were used for MIDI in the ST but those chips were used elsewhere for serial/RS232. From my understanding, there's little difference between the MC6850 and the MOS/Synertek/Rockwell 6551. Unless I'm misremembering, the 6551 in the Apple Super Serial Card II for the Apple II could do about 120Kbps. And Rockwell had a version of that chip which was basically 2 - or 3 - built into a single chip.

 

Joe Decuir said that the Atari 800D - the limited developer version - had 2 MC6850s for serial transfer of programs but didn't remember exactly why they went with the Motorola solution over the 6551 from a variety of other chipfab company choices...

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...