»

[olsen]

Originally Posted by k4lmp

Anybody know of a good serial driver to replace serial.device to speed up the serial port? Mine instead of the next step above 19,200 being 38,400, it is 31, some odd number. and that is it. If there is a better one, can I rename the file serial.device?

Don't bother, seriously. The known speed problem (or rather the problem of transmission reliability at high serial link speeds) will not go away by dropping in a different device driver.

The root of the problem is in the limitations of the serial port hardware of the Amiga. Reports of getting better performance out of it through custom drivers are, unfortunately, more magical thinking than reliable behaviour.

Save yourself the trouble. If you badly need a serial link which provides for more reliable performance at high speeds and goes easy on the CPU load, you would be best advised to look for a Zorro II multiport serial card. Provided you can get a hold of one of these, the results will be much better than what the built-in Amiga serial hardware can even hope to deliver.

[LoadWB]

Originally Posted by olsen

The root of the problem is in the limitations of the serial port hardware of the Amiga. Reports of getting better performance out of it through custom drivers are, unfortunately, more magical thinking than reliable behaviour.

I'll have to call shenanigans on this. I experienced measurably better performance out of particular serial drivers. Without looking at my old Miami config file I cannot recall off the top of my head which one, but I was able to get stable and reliable performance with a 56k modem on one of the alternate serial.device drivers whereas I could not with others.

[zipper]

A 060 processor and RTG card did allow quite reliable 56k even on my A500 and std device.

[olsen]

Originally Posted by LoadWB

I'll have to call shenanigans on this. I experienced measurably better performance out of particular serial drivers. Without looking at my old Miami config file I cannot recall off the top of my head which one, but I was able to get stable and reliable performance with a 56k modem on one of the alternate serial.device drivers whereas I could not with others.

Lucky you

Back in the day I toyed with the idea of rewriting the serial.device driver in plain 'C' just to prove that it can be done. As part of this exercise, I reviewed the original serial.device source code which, strangely enough, wasn't poorly written at all.

If you properly did your job in the network front-end (slip.device, cslip.device, ppp.device) which called upon the serial driver to move its data around, and enabled the recommended control options (8N1, RTS/CTS, high-speed mode) you enabled a code path through the serial.device RBF interrupt handler which was as short as it could be. From what I know, your typical custom serial.device variant reproduced exactly this code path, and removed every other optional code path which the original serial.device had to support (7E1, xON/xOFF, etc.).

The big problem remained, no matter what device driver you put your trust in: the receive buffer of the built-in serial hardware has just enough room for one word to be stored at a time. Once the receive buffer is full, the hardware triggers an interrupt and your interrupt handler has to be fast and lucky to pick it up before the next incoming word overwrites it. This works reasonably well for transmission speeds up to 57.600 bps (assuming fair weather), but gets flakier the more you demand of the hardware.

If your display mode (e.g. 16 colour hires interlaced) puts extra load on the bus, you'll make it harder for the rbf interrupt to be serviced quickly. If you write to disk, hit the keyboard, etc. you're asking more interrupts to be serviced while the serial rbf interrupt also has to have its day. If you run more programs in the background, same effect.

It's easy to throw off the serial receiver because it's so easy to trip it up at high speeds: incoming words are getting more likely to be trashed because there is basically no safety buffer to avoid exactly that. There is very, very little which your serial.device driver replica can do to alleviate the situation.

What works consistently well, and very well indeed is to use serial device hardware which has a FIFO, and which can be found on any Amiga serial card made since the early days.

[Gulliver]

On the other hand, the speed of the serial port for data transfers is not really interesting at all. Lets look at the numbers:

The newest Amiga Zorro serial cards like Hypercom, VarIO, etc can reach 46KB/s, some of them can exceptionally reach 62KB/s
The vast majority of Amiga Zorro serial cards like the Vector Connection, IOBlix, etc can reach 11.5 KB/s
The low end Amiga Zorro serial cards like Multiface, GVP IOExtender, etc will never achieve anything beyond 6.1KB/s
Clockport based serial cards can reach speeds resembling those of the high end Zorro serial cards.

I know numbers are a bit dissapointing.
The parallel port is often faster, and even more in some expansion cards (500KB/s), it is in some aspects a better choice than the serial port. It can be used thru a PLIP driver for TCP-IP connections.

[djos]

I got this response from Brandon (maker of the c64 flyer) regarding a version for Amiga's:

I've definitely thought about it The "problem" is that Amiga peripherals don't have the same intelligent / high-level interfaces that the Commodore 8-bit machines do, so it wouldn't be a plug-and-play solution like the Flyer. I would have to write device drivers and/or additional software on the Amiga to make something like the Flyer work.

This wouldn't necessarily be a bad thing (and it would be a really fun project), but it would take much more than some hardware modifications and I don't have the spare cycles currently.

I love the Amiga, and I'd definitely like to do something with it at some point!

Brandon