MiSTer FPGA Forum

In parallel with the MiSTer development I'm currently porting and updating the PCXT core to other non MiSTer FPGAS. The aim is to allow people who don't own a MiSTer to help in the development of the core, and port those improvements back to the MiSTer PCXT core.

Currently I'm maintaing at https://github.com/somhi/PCXT_DeMiSTify the following direct ports for:

• Altera Max 10 - DECA FPGA
• Altera Cyclone IV - NeptUNO FPGA
• Altera Cyclone V - SoCkit FPGA

The port is nearly the same for all three boards and is made with a fantastic tool called DeMiSTify to support porting MiST cores to other boards. Porting from MiSTer requires a more initial effort but after that porting to any FPGA supported by DeMiSTify is easy.

PCXT could be ported without too much effort to any Altera FPGA with SDRAM and enough BRAM resources to handle the core. Porting to Xilinx FPGAs would require more effort, as it seems all System Verilog code must be recoded to Verilog.

The main stopping factor to universalize the PCXT core is to move BIOS and VRAM into the SDRAM controller. Until that only a few FPGA boards can handle the core, while others would work but with reduced specs (e.g. DECA port cannot handle Tandy graphics as it can only fit 32 kB for CGA in BRAM). This is well explained by @spark2k06 in Saving BRAM To Facilitate Ports and New Developments thread.

I'm also maintaining a MiSTer compatible port for Cyclone V - SoCkit FPGA at https://github.com/sockitfpga/PCXT_SoCkit/

somhi wrote: ↑Thu Sep 22, 2022 9:54 pm Thanks to Kitune-san new BIOS loader into SDRAM, now it was possible to run PCXT on a 25 kLE, 76 kB (608256 bits) [66 M9k blocks] memory FPGA.

somhi wrote: ↑Fri Sep 23, 2022 11:59 pm Latest compilation used 60 M9K blocks. How many does it have MiST ?

somhi wrote: ↑Sat Sep 24, 2022 9:13 pm First he had to change to another monitor because the MDA resolution at 70 Hz it does not work in all monitors.

kitune-san wrote:

kitune-san wrote: ↑Tue Sep 27, 2022 2:07 pm Maybe this is it?
https://github.com/spark2k06/PCXT_ZXUno ... HW/KFPC-XT

KF8237 (DMA) is changed in the FDC test branch.
I would recommend updating when needed.

kitune-san wrote: ↑Tue Sep 27, 2022 3:19 pm I'll take a look when I have time. I think it will be very time consuming.

When operation is unstable, first suspect timing constraints.
Basically, expect the operation to be unstable without timing constraints.
For example, using a clock that is not output from the DCM, will it be placed correctly?
What is the treatment between clocks that are not synchronized?

Unfortunately I do not have a Xilinx board...

Newsdee wrote: ↑Sun Sep 25, 2022 11:45 am Would CGA fit if MDA is removed? (maybe a compiler flag so both variants can be done)

• Composite real video output

• Getting keyboard to work directly with the core and with the OSD without keyboard controller error

kitune-san wrote: ↑Tue Oct 18, 2022 12:07 am I will put a timeout process in the transmit logic.

kitune-san wrote: ↑Tue Oct 18, 2022 12:23 am However, there are few times when the PC transmits data.
Would the same problem occur if you open the OSD after DOS has booted?

somhi wrote: ↑Tue Oct 18, 2022 7:39 pm

kitune-san wrote: ↑Tue Oct 18, 2022 12:23 am However, there are few times when the PC transmits data.
Would the same problem occur if you open the OSD after DOS has booted?

It still happens but it is after loading the BIOS that the keyboard dies.
I don't know why some BIOS reset the core after loading while others don't (diagnostic BIOS do it).
The ruud diagnostic BIOS is the more likely to freeze the keyboard after being loaded into SDRAM.

I've tried the new send data patch (thanks for it) but I'm still experimenting keyboard freezes.
Before I could have freezes with the OSD open while the BIOS was booting up the system.
Now it seems I only get freezes after loading some BIOS into SDRAM.

kitune-san wrote: ↑Wed Oct 19, 2022 12:09 am If the OSD is the trigger of the problem:
Each time data is read, the core sets ps2clk low.
This may be causing problems.
Inserting logic to ignore the ps2clockout output from the core while the intercept is asserted may improve the problem.

PS2_KEYBOARD_DAT    <= '0' when ((ps2_keyboard_dat_out = '0') and (intercept = '0') ) else 'Z';
PS2_KEYBOARD_CLK    <= '0' when ((ps2_keyboard_clk_out = '0') and (intercept = '0') ) else 'Z';

kitune-san wrote: ↑Tue Oct 18, 2022 12:23 am Does the keyboard freeze only when the OSD is opened?
If you don't open the OSD, can you use the keyboard without problems?

kitune-san wrote: ↑Wed Oct 19, 2022 3:11 am

kitune-san wrote: ↑Wed Oct 19, 2022 12:09 am If the OSD is the trigger of the problem:
Each time data is read, the core sets ps2clk low.
This may be causing problems.
Inserting logic to ignore the ps2clockout output from the core while the intercept is asserted may improve the problem.

For example:

Code: Select all

PS2_KEYBOARD_DAT    <= '0' when ((ps2_keyboard_dat_out = '0') and (intercept = '0') ) else 'Z';
PS2_KEYBOARD_CLK    <= '0' when ((ps2_keyboard_clk_out = '0') and (intercept = '0') ) else 'Z';

ps2_keyboard_dat_in and ps2_keyboard_clk_in signal is not included in the condition.

kitune-san wrote: ↑Thu Oct 20, 2022 3:04 am What is the reboot procedure after loading bios?
Could you check if the chipset reset signal is output during reboot?
Also, One point of concern is whether the intercept signal is low when the keyboard hangs up.