MiSTer FPGA Forum

kitune-san wrote: ↑Mon May 23, 2022 3:47 pm If data readout cannot keep up, try connecting ~interrupt_request[1] to ps2_kbd_clk_in in hps_io.

I made a mistake.
s/~interrupt_request[1]/~irq of KFPS2KB/

kitune-san wrote: ↑Mon May 23, 2022 10:13 pm

kitune-san wrote: ↑Mon May 23, 2022 3:47 pm If data readout cannot keep up, try connecting ~interrupt_request[1] to ps2_kbd_clk_in in hps_io.

I made a mistake.
s/~interrupt_request[1]/~irq of KFPS2KB/

I'm not having any problems with the keyboard at the moment, but if I do, I'll keep it in mind, thank you.

For the time being, I add the speaker connection to be able to hear the BIOS beeps:

https://github.com/spark2k06/PCXT_MiSTer/commits/main

What I can confirm, is that the timer always works properly because the sound is the same, working both at 4.77Mhz and 7.16Mhz, thanks to the separation of the clocks, so that the 8253 module always works with 4.77Mhz.

spark2k06 wrote: ↑Tue May 24, 2022 5:56 am
What I can confirm, is that the timer always works properly because the sound is the same, working both at 4.77Mhz and 7.16Mhz, thanks to the separation of the clocks, so that the 8253 module always works with 4.77Mhz.

I recommend inserting F/Fs between asynchronous clock domains.
https://github.com/kitune-san/KFPC-XT/c ... 9686e829a4

Sorry. I forgot to do this...

kitune-san wrote: ↑Tue May 24, 2022 10:43 am

spark2k06 wrote: ↑Tue May 24, 2022 5:56 am
What I can confirm, is that the timer always works properly because the sound is the same, working both at 4.77Mhz and 7.16Mhz, thanks to the separation of the clocks, so that the 8253 module always works with 4.77Mhz.

I recommend inserting F/Fs between asynchronous clock domains.
https://github.com/kitune-san/KFPC-XT/c ... 9686e829a4

Sorry. I forgot to do this...

No problem. I'll write it down and update it later, thanks!

Just a proof of concept of connecting to the HPS_EXT module and loading a floppy image into memory. In the next beta (version 0.4) I would like to get the OS to boot from floppy.

Ignore the AO486 text, it's because I haven't created the workspace for PCXT in the MiSTer framework (Main_MiSTer) yet.

Now the menu access will be with Win+F12 instead of just F12, like in AO486. This is the reason why, in the video, the camera with which I am recording moves when I access the menu:



To do this, with the HPS ready, it will "only" be a matter of integrating the floppy module in KFPC-XT's Peripherals.sv:

https://github.com/MiSTer-devel/ao486_M ... c/floppy.v

On AO486 readme there is written this :
"Note:
Press WIN+F12 to access OSD on ao486 core. F12 alone acts as generic F12 PC key."

spark2k06 wrote: ↑Wed May 25, 2022 12:51 pm Now the menu access will be with Win+F12 instead of just F12, like in AO486. This is the reason why, in the video, the camera with which I am recording moves when I access the menu:

Yes, that is the reason. Thank you for the clarification.

lroby74 wrote: ↑Wed May 25, 2022 9:00 pm On AO486 readme there i written this :
"Note:
Press WIN+F12 to access OSD on ao486 core. F12 alone acts as generic F12 PC key."

I think I have everything connected properly but I don't quite know how to do it with the DMA signals:
Especially the dma_floppy_tc signal

@kitune-san, maybe you can help me with the best way to transfer these signals to your DMA module. I have created a new branch with all the changes I have made:

https://github.com/spark2k06/PCXT_MiSTer/tree/fdd-test

For a reference on how the floppy module is used together with the DMA in the ao486 core, you can consult the sources here:

https://github.com/MiSTer-devel/ao486_MiSTer

Remember also that in the main module (pcxt.sv), I left the dma_request signal set to 0, I guess I will have to change this:

I have sent you a pull request.
I'm sorry, but I have no way to confirm this on my end...

Just wanted to chime in real quick and thank you both. I am thoroughly enjoying watching you two work through this on the forum.

kitune-san wrote: ↑Thu May 26, 2022 1:40 pm I have sent you a pull request.
I'm sorry, but I have no way to confirm this on my end...

I'll try it as soon as I can, thanks!

It won't boot from the floppy disk image. At the moment I have only added a trace in floppy0_select_n + io_write_n, associating it to one of the 8 available LEDs in the MiSTer.

The detection of at least one OUT 3F2h is confirmed:
I update the sources of the fdd-test branch:

https://github.com/spark2k06/PCXT_MiSTer/tree/fdd-test

I confirm that this same floppy0_select_n signal together with io_read_n does not occur, a test with the LED associated with this combination confirms this.

I think it's going to be a weekend of tests... The issue could be anywhere, timings? DMA? HPS_EXT? who knows

I will look into the floppy module.

KFPC-XT inputs signals to io_read and io_write over several clocks.
I suspect that this is the cause of the problem.

kitune-san wrote: ↑Fri May 27, 2022 1:35 pm I will look into the floppy module.

KFPC-XT inputs signals to io_read and io_write over several clocks.
I suspect that this is the cause of the problem.

Perhaps this is one of the causes.
I am looking at the floppy.sv test bench.
While writing multiple data, there is no change in the io_write signal.
PCXT sends out a write(or read) pulse every byte, so this is not working.

It needs to be modified to send the edges of the io_write, io_read and dma_ack pulses to the floppy.

Reference: Write cycle of 8088/8086

The truth is that this module works correctly in the ao486 project, so I deduce that it will have some dependencies of this core.

This is an awesome project. I hope that it can be developed as much as possible from scratch because there are strange issues with ao486 that so far haven't been resolved without having to find workarounds. Some of this has to do with the drives from what I recall. I look at it as a chance to start over from the beginning and let it grow from there into the future with future chips like the 286, etc. The PCEM source code might be a great resource.

kitune-san wrote: ↑Fri May 27, 2022 3:20 pm It needs to be modified to send the edges of the io_write, io_read and dma_ack pulses to the floppy.

Added latches.
https://github.com/spark2k06/PCXT_MiSTe ... n:fdd-test

I'm sleepy...

Oops.
FDD DMA transfers will not work with this wiring.

Fix
https://github.com/kitune-san/PCXT_MiST ... 0353ce7233

@kitune-san, don't spend too much more time trying to improve this module, because we should start by understanding and seeing how the core interacts with the hps_io module and the framework, using the ao486 workspace as an example:

https://github.com/MiSTer-devel/Main_Mi ... upport/x86

First of all, ao486 is using the hps_io module with the WIDE parameter set to 1, that is, it works at 16 bits. So, forget about this issue for the moment, I will try to see how to adapt the part of the framework used in ao486 to our needs, but I don't know how far I can go, probably without @sorgelig's help, we will be stuck on this issue... same for the IDE module and the VHD loading

What I did want to have put at least, is the dynamic loading of the bios rom from ioctl, as @JasonA started to do, as it would serve us to track in the BIOS by traces, without having to resynthesize the entire core at each change. I've started something following the initial steps he started, but it doesn't finish loading the BIOS, see if he can come up with something. All the changes so far would be available here:

https://github.com/spark2k06/PCXT_MiSTer/tree/fdd-test

The issue is quite complicated, because without the OS loading there is little we can do . The other alternative we have at the moment is to use the secondary SD card that MiSTer has to load by floppy or IDE together with Universal XTIDE BIOS from the I/O port 300h, these are the signals... in case you can think of how we can connect it @kitune-san:
We almost had it, but OS loading is going to be the next tough challenge to tackle.

I can take a look at anything needed

I ordered the DE10-Nano and MiSTer IO board.
However, it will take some time before they are actually in my hands and I can debug them.

When loading the BIOS using ioctl from outside of PXCT, I would assume the procedure would be as follows.
1. Input a lock signal to the CPU when idle (s1,s2,s3=1,1,1).
2. Switch the bus (XT-BUS -> ioctrl(hps_io))
3. Rewrite (or read) BIOS.
4. Switching the bus (ioctrl(hps_io) -> XT-BUS)
5. Unlock the CPU.

Loading the bios is quite simple:

boot.rom would have an ioctl_index of 0, and is auto transmitted via the hps on boot. Hold the core in reset during its download. once download is complete, release the reset.
it is also possible to debug the loading of the bios via the OSD. using a conf_str of "F1, rom, Load BIOS" it would be manually selectable and then have an ioctl index of 1 instead. reset is unnecessary in this state, as debugging of the ioctl dout and addr can be monitored with the debugging tool of choice.

i am not sure of the endian type you will need now. The Next186 core uses Intel endian, with low and high reversal. If the ioctl WIDE configuration for 16bit is causing problems, i would recommend going back to 8-bit and recreate the 16-bit bios data. You can see something similar to this in my various Next186 core attempts.

i made an initial attempt a few days ago to integrate verilator but due to time constraints and the multiple errors generated, will need to come back to that very soon.

Thank you both, I will take your advice into account. On another note, I have tried to add the SDRAM signals to have 640KB + HMA available initially:

https://github.com/spark2k06/PCXT_MiSTe ... sdram-test

But as usual, something is missing or I don't take into account. maybe, latches?

The BIOS beeps continuously at startup, indicating a RAM failure.

Certainly, there is a lack of consideration for asynchronous clocks.
The CPU clock is 4.77 MHz or 7.16 MHz, but the SDRAM clock is 50 MHz.

latch...Hmmm...

The ram.v appears to be a standard approach and Quartus Prime should be able to synth that properly.

What are the ram issues?

The RAM.V module from the KFPC-XT project is precisely what I use now, and there is no problem in synthesising it right now. The problem is possibly related to the clocks, as kitune-san rightly points out.

Why is the following signal inverted?

kitune-san wrote: ↑Sat May 28, 2022 12:55 pm Why is the following signal inverted?

Code: Select all

	assign SDRAM_nCS = ~SDRAM_CS;
	assign SDRAM_nCAS = ~SDRAM_CAS;
	assign SDRAM_nRAS = ~SDRAM_RAS;
	assign SDRAM_nWE = ~SDRAM_WE;

Because they originally carry the 'n', I understand that they work in reverse, 1 = disabled and 0 = enabled. Since the KFPC-XT signals do not, I assumed that they had to be negated.

I have tried leaving them as they are, and it still doesn't work.

A bug was found in RAM.sv of KFPC-XT.
The RAM access range was 00000h-9FFFFFh, but it was 00000h-7FFFFFh.
An error may have occurred when accessing 80000h-9FFFFFh.

https://github.com/kitune-san/KFPC-XT/c ... 4cfde55893