MiSTer PCXT

[spark2k06]

The memory I use is as follows:

w9825g6kh

[spark2k06]

Could you tell me what SDRAM chip you are using?

I will not modify the refresh, but increasing the parameter time may stabilize the operation.

I will modify these values to see if it improves.

[kitune-san]

Thank you very much.
It looks like it does not need to be changed.
Ummm...

[kitune-san]

Changed KFSDRAM.sv to always call auto refresh when not reading or writing.

https://github.com/kitune-san/KFSDRAM/b ... KFSDRAM.sv

[spark2k06]

Changed KFSDRAM.sv to always call auto refresh when not reading or writing.

https://github.com/kitune-san/KFSDRAM/b ... KFSDRAM.sv

Unfortunately, it seems to work worse.

I have created two compilations:

SDRAM_PCXT1 -> Older version of KFSDRAM.sv, almost always the initial memory test works fine, but it doesn't run the BIOS correctly. Sometimes the test failed, but only under 7.16Mhz system clock.

SDRAM_PCXT2 -> New version of KFSDRAM.sv, never passes the memory test, neither at 4.77Mhz nor at 7.16Mhz system clock.

Below, I show a video with the tests and provide the files, in case someone else can confirm it, so it's not due to a problem with my SDRAM memory.



Just remember that the first memory test is carried out over a short period of time (but insufficient to carry out the subsequent process of populating the interrupt vectors and stack values in segment 0), which is the reason why the BIOS screen is not displayed, possibly just long enough for the memory to retain the information refreshed in the old version:

Code: Select all

;-------------------------------------------------------------------------
; Test first 32 KiB (MIN_RAM_SIZE) of RAM

	mov	al,e_low_ram_test
	out	post_reg,al
	xor	si,si
	xor	di,di
	mov	ds,di
	mov	es,di
	mov	dx,word [warm_boot+biosdseg*16] ; save soft reset flag to DX
	mov	ax,55AAh		; first test pattern
	mov	cx,MIN_RAM_SIZE*512	; RAM size to test in words
    rep	stosw				; store test pattern
	mov	cx,MIN_RAM_SIZE*512	; RAM size to test in words
.1:
	lodsw
	cmp	ax,55AAh		; compare to the test pattern
	jne	low_ram_fail
	loop	.1
	xor	si,si
	xor	di,di
	mov	ax,0AA55h		; second test pattern
	mov	cx,MIN_RAM_SIZE*512	; RAM size to test in words
    rep stosw				; store test pattern
	mov	cx,MIN_RAM_SIZE*512	; RAM size to test in words
.2:
	lodsw
	cmp	ax,0AA55h		; compare to the test pattern
	jne	low_ram_fail
	loop	.2
	xor	di,di
	xor	ax,ax			; zero
	mov	cx,MIN_RAM_SIZE*512	; RAM size to test in words
    rep stosw				; zero the memory
	jmp	low_ram_ok		; test passed

low_ram_fail:
	mov	al,e_low_ram_fail	; test failed
	out	post_reg,al

;-------------------------------------------------------------------------
;  Low memory error: beep - pause - beep - pause ... - 400 Hz

	mov	al,0B6h
	out	pit_ctl_reg,al		; PIT - channel 2 mode 3
	mov	ax,pic_freq/400		; 400 Hz signal
	out	pit_ch2_reg,al
	mov	al,ah
	out	pit_ch2_reg,al
	in	al,ppi_pb_reg
.1:
	or	al,3			; turn speaker on and enable
	out	ppi_pb_reg,al		; PIT channel 2 to speaker
	mov	cx,0
.2:
	nop
	loop	.2
	and	al,0FCh			; turn of speaker
	out	ppi_pb_reg,al
	mov	cx,0
.3:
	nop
	loop	.3
	jmp	.1

[kitune-san]

I will add precharge(PALL) before the refresh command.
Sorry. I will try after work so it takes time.

[kitune-san]

> Sometimes the test failed, but only under 7.16Mhz system clock.

This seems to be another problem.
Does the CPU bus cycle really support 7.16 MHz?
Let's make it a priority to run at 4.77 MHz.

[spark2k06]

I will add precharge(PALL) before the refresh command.
Sorry. I will try after work so it takes time.

All right, don't be in a hurry. Thank you.

> Sometimes the test failed, but only under 7.16Mhz system clock.

This seems to be another problem.
Does the CPU bus cycle really support 7.16 MHz?
Let's make it a priority to run at 4.77 MHz.

OK. I will always test at 4.77Mhz at first.

[kitune-san]

I will add precharge(PALL) before the refresh command.
Sorry. I will try after work so it takes time.

https://github.com/kitune-san/KFSDRAM/b ... KFSDRAM.sv


Continuing, I will look for any timing issues that may have occurred when the refresh was inserted.

[spark2k06]

I will add precharge(PALL) before the refresh command.
Sorry. I will try after work so it takes time.

https://github.com/kitune-san/KFSDRAM/b ... KFSDRAM.sv


Continuing, I will look for any timing issues that may have occurred when the refresh was inserted.

I confirm that with this change you have made, it now works as it did at the beginning, it passes the first test but does not start the BIOS.

[kitune-san]

Have you already done the following changes?

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

[spark2k06]

Have you already done the following changes?

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

Yes, that change is applied, but even just 32Kb from segment 0 would be enough for the BIOS to work, just fill 256 bytes with the interrupt vectors, plus a few other values, and set the stack on that same segment. As I said, the funny thing is that the initial test is done correctly but then these small "random" reads/writes necessary for the BIOS to work no longer work.

[spark2k06]

I didn't know that Universal XTIDE BIOS had virtual disk support via serial port:

https://www.xtideuniversalbios.org/wiki/SerialDrives

While we sort out the IDE and Floppy issue, I will try to investigate this line of work, the first step is to implement a UART module.

[spark2k06]

I think this will be a good basis to start with:

https://github.com/MiSTer-devel/ao486_M ... l/soc/uart

[kitune-san]

Have you already done the following changes?

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

Yes, that change is applied, but even just 32Kb from segment 0 would be enough for the BIOS to work, just fill 256 bytes with the interrupt vectors, plus a few other values, and set the stack on that same segment. As I said, the funny thing is that the initial test is done correctly but then these small "random" reads/writes necessary for the BIOS to work no longer work.

I have found that with the default settings the refresh time exceeds 64 ms.
I would recommend changing the parameters.

However, you have already tried high cycle refresh.
This SDRAM problem would not be solved.

I think I would wait to research until the MiSTer arrives at my home.

Screenshot from 2022-06-02 19-53-16.png (77.91 KiB) Viewed 10471 times

[kitune-san]

> I think I would wait to research until the MiSTer arrives at my home.

s/wait/suspend/

[spark2k06]

> I think I would wait to research until the MiSTer arrives at my home.

s/wait/suspend/

Perfect, no problem. We leave in stand-by the SDRAM integration, I for my part will try to advance in the boot even from UART, for it I will integrate this module and I will do some tests... for the moment we will continue with 256KB of BRAM memory available as conventional RAM.

Let's see if we are lucky and we can see soon the OS booting, and a first benchmark, like the LandMark 1.14, and thus see to what extent it would be a cycle-accurate core, plus see how much it would improve in turbo mode:

[spark2k06]

I have already synthesised a version with UART support, as you can see... COM1 (3F8h) is detected:

serial_com1.jpg (238.37 KiB) Viewed 10319 times

But as it usually happens, when you need something you just don't have it, and in my case it's a DB9 -> USB cable to connect to the PC, where I would mount the image:

serdrive.png (10.46 KiB) Viewed 10319 times

For this reason, while I get the cable... I attach the core in case someone has the possibility to test it. Whoever does it, save the boot.rom file in the games/PCXT folder so that it loads at startup. And during the boot (in 7.16Mhz better, because I don't know why now the keyboard doesn't work with 4.77Mhz), keep pressed the "Alt" key to boot through the serial port.

Actually, I still don't know if a DB9 -> USB cable would work for me. UART signals in the core:

uart_core.png (12.75 KiB) Viewed 10296 times

I have tested it on a real PCXT, it boots with COM1 without any problem:

uart_pcxt_real.jpg (120.43 KiB) Viewed 10257 times

EDIT:

Warning!

According to what Antonio Villena tells me, it seems that a signal converter is required... just in case, be careful with the tests you do, it is almost better to discard it just in case for the moment.

[spark2k06]

Beta 0.5

* Added UART module from ao486 project (COM1 assigned to USER I/O pins)
* Automatic loading of the BIOS ROM from /games/PCXT directory
* BIOS ROM hot swapping from the OSD menu
* Updated the code to the latest version of the SDRAM module of KFPC-XT, but not yet implemented in the core... needs to be revised and improved, it does not work properly.

https://github.com/spark2k06/PCXT_MiSTe ... 456f1942e6

It remains to test the correct operation of the UART module assigned to the USER I/O port by loading the OS with XTIDE Universal BIOS, but in theory the core would be ready for it. That will be the moment when we will see the true potential of the core.

[spark2k06]

I have built myself a DB9 -> USB cable with an adapter:

db9-usb.jpg (167.56 KiB) Viewed 10094 times

From the next pinout of the DB9 connector:

Code: Select all

DB9 MiSTer
 
1 - DSR
2 - N/C
3 - TX
4 - RTS
5 - VCC (5V)
6 - CTS
7 - RX
8 - GND
9 - DCD
Shield - DTR

logically, by crossing the signals: TX <-> RX, DSR <-> DTR and RTS <-> CTS. I have not connected VCC because it is not necessary in this case. The USB is already powered directly from the PC.

It looks like there is communication, but I get checksum error and the HD image is not detected:

serdrive.png (5.44 KiB) Viewed 10094 times

Last changes:

https://github.com/spark2k06/PCXT_MiSTe ... 009305dfa0

There always seems to be a problem... I'll get back to the floppy or IDE booting line of work.

[spark2k06]

Good news and bad news. The cable I built myself works fine, tested on the ao486 core with the same BIOS:

UART_ao486.jpg (162.96 KiB) Viewed 10023 times

The bad thing is that I've transferred the UART module to the PCXT core wrong, but I'm sure there's a solution

[spark2k06]

It looks like there is communication, but I get checksum error and the HD image is not detected:

serdrive.png

@kitune-san, Can you think of any improvements in this area that would make the read/write correct... it seems to be a synchronism issue:

Code: Select all

	wire  [7:0] uart_readdata;
	
	uart uart1
	(
		.clk               (peripheral_clock),
		.br_clk            (clk_uart),
		.reset             (reset),

		.address           (address[2:0]),
		.writedata         (internal_data_bus),
		.read              (~io_read_n),
		.write             (~io_write_n),
		.readdata          (uart_readdata),
		.cs                (uart_cs),

		.rx                (uart_rx),
		.tx                (uart_tx),
		.cts_n             (uart_cts_n),
		.dcd_n             (uart_dcd_n),
		.dsr_n             (uart_dsr_n),
		.rts_n             (uart_rts_n),
		.dtr_n             (uart_dtr_n),
		.ri_n              (1),

		.irq               (uart_interrupt)
	);

The instance of this same module in ao486, which can be seen to work well, can be found here:

https://github.com/MiSTer-devel/ao486_M ... l/system.v

[kitune-san]

As I have written before, the ao486 bus does not seem to be designed for long write/read signals.
I think that long write/read signals need to be converted to short signals.

For example: (Note: This code has not been tested.)

Code: Select all

logic	prev_io_read_n;
logic	prev_io_write_n;
logic	[7:0]	write_to_uart;
logic [7:0] uart_readdata_1;
logic [7:0] uart_readdata_2;
logic [7:0] uart_readdata;

always_ff @(negedge clock) begin
	prev_io_read_n <= io_read_n;
	prev_io_write_n <= io_write_n;
end

always_ff @(negedge clock) begin
	if (~io_write_n)
		write_to_uart <= internal_data_bus;
	else
		write_to_uart <= write_to_uart;
end

uart uart1
(
	.clk               (clock),
	.br_clk            (clk_uart),
	.reset             (reset),

	.address           (address[2:0]),
	.writedata         (write_to_uart),
	.read              (~io_read_n & prev_io_read_n),
	.write             (io_write_n & ~prev_io_write_n),
	.readdata          (uart_readdata_1),
	…
);

// Timing of the readings may need to be reviewed.
always_ff @(negedge clock) begin
	if (~io_read_n & prev_io_read_n) begin
		uart_readdata <= uart_readdata_1;
	else
		uart_readdata <= uart_readdata;
end

Also, what is the speed of clk_uart?

[spark2k06]

As I have written before, the ao486 bus does not seem to be designed for long write/read signals.
I think that long write/read signals need to be converted to short signals.

You're a genius... now I can actually boot the OS. I can't test much now but the Army Moves game at 4.77Mhz works fine

[MicroCoreLabs]

An additional fact. MCL86 can be used in maximum and minimum mode. I have not found examples of use in maximum mode, I have only seen examples in minimum mode, which is how I use it in the initial phase of this project, where, at the execution and operational level, this module works correctly.

So, unless I'm wrong, it's the first time it's been used in maximum mode.

Hi,

This is Ted Fried, the developer of the MCL86 core. Yes, the MCL86 has been used in both maximum mode (IBM 5150/5160) and minimum mode (IBM PCjr), but I believe I only posted a simple minimum-mode example to GitHub. I could post the maximum mode example if it would help you, however it appears that you already have it running to a large degree. I am impressed with how fast this integration is progressing. Please let me know what I can do to help!

Thanks,
-Ted

[spark2k06]

Hi,

This is Ted Fried, the developer of the MCL86 core. Yes, the MCL86 has been used in both maximum mode (IBM 5150/5160) and minimum mode (IBM PCjr), but I believe I only posted a simple minimum-mode example to GitHub. I could post the maximum mode example if it would help you, however it appears that you already have it running to a large degree. I am impressed with how fast this integration is progressing. Please let me know what I can do to help!

Thanks,
-Ted

Thanks, yes, I managed to integrate it, with the help of kitune-san, the author of the also great KFPC-XT project.

In recent times, some amazing projects have been developed around the early PC era, such as MCL86, Graphics Gremlin, and recently KFPC-XT. Not to forget also the BIOS of a PCXT clone like Sergey Kiselev's.

I am not a hardware engineer and have only recently got involved in FPGA project development, in fact, I consider myself a simple puzzle piece builder in this sense, metaphorically speaking. Kitune-san's help in taking these last steps of integration with his project has been key.

Thanks for your interest in the project, there is still a lot to fix to achieve the goal I had planned for this core, a PCXT as real as possible, and as cycle accurate as possible... I will keep you in mind for new improvements or to solve problems that may arise, I really appreciate it

[spark2k06]

beta 0.6

* UART module implementation fix, thanks to @kitune-san

https://github.com/spark2k06/PCXT_MiSTe ... 31ceebc562

The first tests are not very satisfactory. First of all, the core performs at half of an original 4.77Mhz PCXT:

benchmark 1.jpg (42.91 KiB) Viewed 9474 times

Switching to 7.16Mhz does not improve the results much either:

benchmark 2.jpg (137.5 KiB) Viewed 9474 times

When booting the OS, the keyboard doesn't usually work, you have to press many keys at the same time and randomly for it to start working. Other times it doesn't, the keyboard works fine from the beginning.

Finally, there are games that work and games that don't... we have to start finding the reasons why.

[MicroCoreLabs]

When running the MCL86 micro sequencer core at 100Mhz and the bus interface at 4.77Mhz you should achieve cycle accuracy. I glanced at your code and it appears that you are instantiating it correctly, so one thing to check is the number of wait-states that are being generated or recognized. If your READY signal is not available at the correct clock edge then it will result in and additional 4.77Mhz clock cycle which will slow things down. This is the first place I would look - at the number of 4.77Mhz clocks for every BUI bus cycle. Perhaps the wait-state logic needs some attention.

[spark2k06]

When running the MCL86 micro sequencer core at 100Mhz and the bus interface at 4.77Mhz you should achieve cycle accuracy. I glanced at your code and it appears that you are instantiating it correctly, so one thing to check is the number of wait-states that are being generated or recognized. If your READY signal is not available at the correct clock edge then it will result in and additional 4.77Mhz clock cycle which will slow things down. This is the first place I would look - at the number of 4.77Mhz clocks for every BUI bus cycle. Perhaps the wait-state logic needs some attention.

Understood, thanks for the suggestion. I'll try to take a look at what you say, many of the errors I'm sure are due to a lack of detailed knowledge of both worlds, FPGA hardware design and the PC architecture itself.

I will check it as soon as I can.

[MicroCoreLabs]

Good chance the problem is related to the bus interface. My project routed the BIU to the FPGA's IO's and through bus buffers to real peripherals on the IBM PC's motherboard. Because your project is contained completely on-chip, you may need to tweak the BIU timing to match the characteristics of your internal bus structure and emulated peripherals.

One other thing to check is unintended interrupts due to incorrect 8259 emulation or INTR debouncing which could be slowing the system down with unnecessary bus and stack operations. These interrupts could be operationally harmless, but still take dozens of bus cycles to process...