Expansion serial card?
Re: Expansion serial card?
Dilwyn is traveling for the next week or so. He won't be making any updates during that time.
Would you be willing to send me the files directly also? I'm impatient to find out if this represents a solution to my problem
dave funny symbol sinclairql point com
Would you be willing to send me the files directly also? I'm impatient to find out if this represents a solution to my problem
dave funny symbol sinclairql point com
Re: Expansion serial card?
What??? A welsh man looking outside his wonderful country? Seems curious to me, but ok, I'll see it from the other side .Dave wrote:Dilwyn is traveling for the next week or so. He won't be making any updates during that time.
- XorA
- Site Admin
- Posts: 1368
- Joined: Thu Jun 02, 2011 11:31 am
- Location: Shotts, North Lanarkshire, Scotland, UK
Re: Expansion serial card?
Its ok I promised not to shoot him with a bow at midnight when he crossed the Scottish borderRalf R. wrote:What??? A welsh man looking outside his wonderful country? Seems curious to me, but ok, I'll see it from the other side .Dave wrote:Dilwyn is traveling for the next week or so. He won't be making any updates during that time.
- NormanDunbar
- Forum Moderator
- Posts: 2277
- Joined: Tue Dec 14, 2010 9:04 am
- Location: Leeds, West Yorkshire, UK
- Contact:
Re: Expansion serial card?
I think you have to stab him with a dagger, only a dagger, if he's caught inside the walls of Chester city after dusk.
In the same way that we Jocks can be legally killed on the Queens Green, in York, but only with a bow and arrow.
Or so I'm told.
Cheers,
Norm.
In the same way that we Jocks can be legally killed on the Queens Green, in York, but only with a bow and arrow.
Or so I'm told.
Cheers,
Norm.
Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
-
- Font of All Knowledge
- Posts: 3973
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: Expansion serial card?
Here are the files I sent to Dilwyn.
I have also added the serial port driver update.
The files are not compiled by me, I can moy coment on the contents of each file. There looks to be duplicate JED files.
I have also added the serial port driver update.
The files are not compiled by me, I can moy coment on the contents of each file. There looks to be duplicate JED files.
- Attachments
-
- THarmanSerBoardUG_v0_05.zip
- (1.2 KiB) Downloaded 128 times
-
- serplot.zip
- (121.67 KiB) Downloaded 113 times
-
- serpcl.zip
- (88.07 KiB) Downloaded 118 times
-
- serpcb.zip
- (128.22 KiB) Downloaded 121 times
Regards,
Derek
Derek
Re: Expansion serial card?
Still alive after meeting XorA .... No Scots tried to kill me yet, apart from that pesky white van driver on the A1 near EdinburghRalf R. wrote:What??? A welsh man looking outside his wonderful country? Seems curious to me, but ok, I'll see it from the other side .Dave wrote:Dilwyn is traveling for the next week or so. He won't be making any updates during that time.
Guess I have to go to Scotland now before they declare independence and force me to carry a passport
--
All things QL - https://dilwyn.qlforum.co.uk/index.html
All things QL - https://dilwyn.qlforum.co.uk/index.html
Re: Expansion serial card?
Not to spoil the fun, but what exactly do you intend to connect a serial port to? Especially at higher speeds than 230400?
Let's not nix up our serial ports. Standard serial RS232 has little to no resemblance to I2C or SPI. The latter are intended to be local (short distances, centimeters) and relatively high speeds. They are also in a way synchronous, since there is a clocking system built in implicitly (I2C) or explicitly (SPI). SPI can in theory work at speeds around 100MHz, so obviously it is intended to communicate with a whole different class of device than RS232 is.
Let's also review the reason why a serial port is needed by the thread starter - to connect an ethernet chip with a built-in TCP/IP stack processor. The reason it uses SPI is because it is intended to interface with a port limited microcomputer chip or a system on a chip. There are ethernet chips with inbuilt TCP/IP stacks that interface using a 'parallel' interface, i.e. standard address and data lines, which would be the logical way to do this. In some cases it IS a good idea to implement SPI but in that ces, it whould be implemented as multiple SPI interfaces. While it is possible to use a single SPI interface with multiple devices, it becomes more and more difficult if the devices are very different. For instance, there are serial flash memory chips, which use fast SPI or quad SPI (4 bit serrial), and it is easy and natural to use several with a bunch of chip selects, on the same SPI bus. But when devices are dissimilar, then problems arise because various protocols for various devices have to be handled multiplexed on the same bus. Also, a proper SPI implementation almost must use some sort of a CPLD implementation as there is not only serial to parallel to serial conversion to be done, but also buffering, cock generation and/or gating etc. SPI and QSPI is also a basis for the SD memory card protocol.
A note on Terry Harman's fast serial - this was built using a long obsolete serial to parallel chip and a hardware FIFO for reception. Hardware is added to implement hardware handshaking. It is a very old design that coould these days be done with a CPLD or even better, with a small microcontroller.
I cannot over-emphasize the importance of hardware handshaking. There are some caveats to do with buffering (hardware FIFOs) when this is implemented. but some chips do not implement it and rely instead on CPU interrupt response - like the 16450 or 16550 chips the PC serial ports are based on. Simply put, these are just rubbish, which is one reason why serial ports never really worked right on the PC. The 16550 attempted to get around this in a particulairly stupid way forced by the need for compatibility. The chips will generate an interrupt to the CPU when a byte is received, and rely on interrupt response for the CPU to stop the transmitting device from sending a new byte if the CPU cannot immediately process it. But as serial speeds increased, and windows multitasking never really was that good, the CPU could not react in time and the receiver would get over-run, a new byte would be received before the previous one was read by the CPU. The 'solution' was to build in a FIFO buffer, so the sending device could continue to fill the FIFO while the CPU was reacting to it not being empty any more - configuration registers were used to set a treshold, how many received bytes are still present in the FIFO when the interrupt is generated. But, the underlying problem remained. In a few years serial speeds went from 2400 to 115200, so over a 16x increase in speed, and the 16-byte FIFO was thus exhausted. Guess what, they did attempt 64 byte FIFOs for the next gen chips, again the underlying problem remained. The stupid part is, the way RS232 works, it is explicitly known when handshaking is to be done by (simple!) hardware, so it could have been easily implemented at the early stage.
These days old ACIA chips are best avoided. Besides, there is something called a 68681, which will implement two buffered ports capable of working up to megabits.
Final note - most USB to serial adapters are capable of a few high bit rates, but this is not easy to do over standard RS232 wires and signals since most TTL to RS conversion chips will not work reliably over cca 400kbits/s. With direct TTL communications, 1Mbit is possible and in some cases 3Mbits, although it is not always possible to generate these baud rates on every serial interface. At high speeds, most of these ports also either require or provide a serial clock.
Let's not nix up our serial ports. Standard serial RS232 has little to no resemblance to I2C or SPI. The latter are intended to be local (short distances, centimeters) and relatively high speeds. They are also in a way synchronous, since there is a clocking system built in implicitly (I2C) or explicitly (SPI). SPI can in theory work at speeds around 100MHz, so obviously it is intended to communicate with a whole different class of device than RS232 is.
Let's also review the reason why a serial port is needed by the thread starter - to connect an ethernet chip with a built-in TCP/IP stack processor. The reason it uses SPI is because it is intended to interface with a port limited microcomputer chip or a system on a chip. There are ethernet chips with inbuilt TCP/IP stacks that interface using a 'parallel' interface, i.e. standard address and data lines, which would be the logical way to do this. In some cases it IS a good idea to implement SPI but in that ces, it whould be implemented as multiple SPI interfaces. While it is possible to use a single SPI interface with multiple devices, it becomes more and more difficult if the devices are very different. For instance, there are serial flash memory chips, which use fast SPI or quad SPI (4 bit serrial), and it is easy and natural to use several with a bunch of chip selects, on the same SPI bus. But when devices are dissimilar, then problems arise because various protocols for various devices have to be handled multiplexed on the same bus. Also, a proper SPI implementation almost must use some sort of a CPLD implementation as there is not only serial to parallel to serial conversion to be done, but also buffering, cock generation and/or gating etc. SPI and QSPI is also a basis for the SD memory card protocol.
A note on Terry Harman's fast serial - this was built using a long obsolete serial to parallel chip and a hardware FIFO for reception. Hardware is added to implement hardware handshaking. It is a very old design that coould these days be done with a CPLD or even better, with a small microcontroller.
I cannot over-emphasize the importance of hardware handshaking. There are some caveats to do with buffering (hardware FIFOs) when this is implemented. but some chips do not implement it and rely instead on CPU interrupt response - like the 16450 or 16550 chips the PC serial ports are based on. Simply put, these are just rubbish, which is one reason why serial ports never really worked right on the PC. The 16550 attempted to get around this in a particulairly stupid way forced by the need for compatibility. The chips will generate an interrupt to the CPU when a byte is received, and rely on interrupt response for the CPU to stop the transmitting device from sending a new byte if the CPU cannot immediately process it. But as serial speeds increased, and windows multitasking never really was that good, the CPU could not react in time and the receiver would get over-run, a new byte would be received before the previous one was read by the CPU. The 'solution' was to build in a FIFO buffer, so the sending device could continue to fill the FIFO while the CPU was reacting to it not being empty any more - configuration registers were used to set a treshold, how many received bytes are still present in the FIFO when the interrupt is generated. But, the underlying problem remained. In a few years serial speeds went from 2400 to 115200, so over a 16x increase in speed, and the 16-byte FIFO was thus exhausted. Guess what, they did attempt 64 byte FIFOs for the next gen chips, again the underlying problem remained. The stupid part is, the way RS232 works, it is explicitly known when handshaking is to be done by (simple!) hardware, so it could have been easily implemented at the early stage.
These days old ACIA chips are best avoided. Besides, there is something called a 68681, which will implement two buffered ports capable of working up to megabits.
Final note - most USB to serial adapters are capable of a few high bit rates, but this is not easy to do over standard RS232 wires and signals since most TTL to RS conversion chips will not work reliably over cca 400kbits/s. With direct TTL communications, 1Mbit is possible and in some cases 3Mbits, although it is not always possible to generate these baud rates on every serial interface. At high speeds, most of these ports also either require or provide a serial clock.
Re: Expansion serial card?
Very technical, Nasta, compliments! In those days with my Atari MST4 and a Best Fax modem, I had a lot of difficulties running QFax under D Level with receivin Fax docs. I had a lot tries with Jonathan Hudson. This was no problem with Atari Fax programs but with QFax, so I always thought, it is not a hardware, instead a software problem.
Re: Expansion serial card?
I think, today a Fax device is still important, so a suitable and working SER device is needful.Ralf R. wrote:Very technical, Nasta, compliments! In those days with my Atari MST4 and a Best Fax modem, I had a lot of difficulties running QFax under D Level with receivin Fax docs. I had a lot tries with Jonathan Hudson. This was no problem with Atari Fax programs but with QFax, so I always thought, it is not a hardware, instead a software problem.