Upgrade of the UART Module in the PCXT Core

[spark2k06]

I am moving the question of the UART module upgrade to a new thread:

I have instantiated the module in the same way as the 16550 we are using so far, but it does not recognise the HDD images... with this new module I was hoping that the problems regarding access to them would improve, especially at the maximum speed of the UART (921.6Kbps).

Was there any progress on the UART flow control signals? They may be needed to reliably run at higher bit-rates.

Can I ask which direction the errors are most seen? From the HPS to the core or the other way?

Maybe increasing the size of the UART RX FIFOs may make a significant difference?

Indeed, I can confirm that serdrive makes use of the CTS/RTS signals:

https://github.com/spark2k06/Main_MiSTe ... uxSerial.h

Code: Select all

state.c_cflag |= CRTSCTS | CLOCAL;

So I would like to see how an upgrade to 16750 behaves, also, there is something observed on the current 16550 module, which happens on both the PCXT core and ao486 which shares the same UART module... and that is that the COMTEST application is not detecting the IRQ values, which should be 3 and 4, instead it shows a question mark symbol:

comtest.jpg

However, I will try to see if I can increase the size of the FIFO queue. The ultimate goal is to see if we can make the 921.6Kbps speed more reliable, because at 460.8Kbps it generally works very well.

I'm not sure, but I think the errors occur from the HPS to the core, because they are usually image reading errors. So yes, maybe increasing the FIFO queue will improve the issue.

I have increased queue_depth from 4 to 32, and even then, at 921.6Kbps there are often problems, especially when trying to do a fresh install of MS-Dos:

Code: Select all

COMPONENT gh_fifo_async_sr is
	GENERIC (data_width: INTEGER :=8; queue_depth: INTEGER :=32 ); -- size of data bus

[kitune-san]

Is it possible that a metastable is occurring?
For example, would inserting a flip-flop between the HPS and the uart module improve this?

[kitune-san]

It appears to me that clk_uart is not being used to generate the transmit baud rate.
It may be solved by using the rising edge of clk_uart as a clock enable signal.

I will try it.

[kitune-san]

It appears to me that clk_uart is not being used to generate the transmit baud rate.
It may be solved by using the rising edge of clk_uart as a clock enable signal.

I will try it.

https://github.com/kitune-san/PCXT_MiST ... 84c1309670

[spark2k06]

It appears to me that clk_uart is not being used to generate the transmit baud rate.
It may be solved by using the rising edge of clk_uart as a clock enable signal.

I will try it.

https://github.com/kitune-san/PCXT_MiST ... 84c1309670

The stability is impressive, thanks! I was able to install MS-Dos from scratch at 921.6KBps without any problems, although I selected the CPU at 14.318MHz:

20220913_193000-screen.png (110.29 KiB) Viewed 1654 times

20220913_190504-screen.png (105.06 KiB) Viewed 1654 times

Also, the COMTEST application now detects the IRQ, I don't know what implications it has but @sorgelig should take note and update it for ao486 as well:

20220913_190422-screen.png (169.87 KiB) Viewed 1654 times

While it is also true, that the lower speeds have been lost for serdrive, 115.2Kbs and 230.4Kbps have lost compatibility for all CPU frequencies, and the 921.6KBbps only works at 14.318MHz... this would leave the current compatibility:

Code: Select all

14.318 MHz -> 460.8Kbps, 921.6Kbps
7.16 MHz -> 460.8Kbps
4.77 MHz -> 460.8Kbps

For me it's a lesser evil, and if they can't be recovered, I'll modify the OSD menu options to select only one of these two.

Let me know if there is room for improvement @kitune-san, if not, we'll leave it at that and I'll publish it for the next release.

Thanks again for your invaluable help.

[Flandango]

While it is also true, that the lower speeds have been lost for serdrive, 115.2Kbs and 230.4Kbps have lost compatibility for all CPU frequencies, and the 921.6KBbps only works at 14.318MHz... this would leave the current compatibility:

Code: Select all

14.318 MHz -> 460.8Kbps, 921.6Kbps
7.16 MHz -> 460.8Kbps
4.77 MHz -> 460.8Kbps

For me it's a lesser evil, and if they can't be recovered, I'll modify the OSD menu options to select only one of these two.

Sorry if this question has been answered or for my ignorance, but is there any reason to want lower baud rates?
Are there times when the 460.8Kps baud rate is too fast for the 4.77 and 7.16 Mhz cpus?
If not, and we know the max stable baud rates for each CPU speed, why not simply adjust the baud rate automatically based on selected CPU speed?

[kitune-san]

If low speed communication is required, I would suggest dividing the Uart clock according to the speed setting.

[spark2k06]

If low speed communication is required, I would suggest dividing the Uart clock according to the speed setting.

From what I understand from the following frequency table...

https://en.wikipedia.org/wiki/Crystal_o ... requencies

...A UART clock of 14.7456MHz will allow us to synchronise up to 921.6Kbps without any problem, as long as the CPU bus frequency allows it.

For this reason, I have readjusted the frequency via PLL, which although it has not been possible to have that precision, it seems that with the 14.814814MHz at which it has been configured, plus your pipeline system that you have created, it supports selecting 230.4, 460.8 or 921.6Kbps, this last one, of course, only with the CPU at 14.318MHz.

The 115.2Kbps is missing, which is achieved by taking clk_uart directly to the UART module, so I activate it depending on the selected CPU speed.

All these changes have been uploaded to the prerelease branch:

https://github.com/MiSTer-devel/PCXT_Mi ... prerelease

I'm attaching the RBF file for the moment so you can test it before publishing it in the main branch.

As far as I have been able to verify, the instability of the UART at high speeds was only and exclusively due to the UART version... after the update to the 16750 all these problems have disappeared, and as you have been able to verify, the COMTEST now also identifies the IRQ.

Sorry if this question has been answered or for my ignorance, but is there any reason to want lower baud rates?
Are there times when the 460.8Kps baud rate is too fast for the 4.77 and 7.16 Mhz cpus?
If not, and we know the max stable baud rates for each CPU speed, why not simply adjust the baud rate automatically based on selected CPU speed?

I've thought about it too, but that would mean making changes to the MiSTer Main, and it doesn't get regular updates. When I have to make changes, I prefer them to be more involved, like not depending on serdrive because we have managed to have 8-bit IDE, for example

[Newsdee]

Code: Select all

.clk_uart                           ((status[22:21] == 2'b00) ? clk_uart : clk_uart_en),

Is the UART speed setting still used?
Only found the reference above status[22:21] in the code, but maybe I'm missing something.

If I understand correctly that means only the lowest setting will have any effect?

I was thinking of making a small change to remove this line in the readme:

It is also possible to use 921600, but only with the CPU speed at 14.318MHz.

Basically if "MAX" is selected, the core could switch automatically from 921 Kbauds to 460 Kbauds .

But if the setting is already simplified perhaps it can just be renamed to "MIN / MAX"

[spark2k06]

Code: Select all

.clk_uart                           ((status[22:21] == 2'b00) ? clk_uart : clk_uart_en),

Is the UART speed setting still used?
Only found the reference above status[22:21] in the code, but maybe I'm missing something.

If I understand correctly that means only the lowest setting will have any effect?

I was thinking of making a small change to remove this line in the readme:

It is also possible to use 921600, but only with the CPU speed at 14.318MHz.

Basically if "MAX" is selected, the core could switch automatically from 921 Kbauds to 460 Kbauds .

But if the setting is already simplified perhaps it can just be renamed to "MIN / MAX"

In any case, the status[22:21] bits must be kept representing the baud rate, as it is used in the Main to set the serdrive speed.

You can set a maximum speed automatically if you want according to the CPU speed, but in any case these bits must remain intact, both their offset in status, and what they represent.

uart_main.jpg (27.09 KiB) Viewed 1064 times

[Newsdee]

In any case, the status[22:21] bits must be kept representing the baud rate, as it is used in the Main to set the serdrive speed.

Ah right, it needs to be added to Main instead. I suppose we can leave it alone unless there is need to change something else in Main for PCXT.
Hopefully 8-bit IDE can be added soon so we don't need to worry about baud rate anymore

[spark2k06]

In any case, the status[22:21] bits must be kept representing the baud rate, as it is used in the Main to set the serdrive speed.

Ah right, it needs to be added to Main instead. I suppose we can leave it alone unless there is need to change something else in Main for PCXT.
Hopefully 8-bit IDE can be added soon so we don't need to worry about baud rate anymore

I've created a new thread where I put all my current knowledge about developing a real 8-bit IDE to be compatible with the core... so that we can get rid of all dependency on serdrive, and what I think needs to be done to make it happen, in case it helps:

viewtopic.php?t=5533