MiSTer PCXT

[kitune-san]

.data_bus is commented out too. Please

// .data_bus (data_bus),

change to following

.data_bus (CPU_DIN),

[kitune-san]

Could you please check the wiring between the chipset and the BIOS-ROM?

The KFPC-XT assumed the following wiring

Chipset address -> BIOS-ROM(or other devices) addr
Chipset data_bus -> BIOS-ROM(or other devices) din
Chipset data_bus_ext <- BIOS-ROM(or other devices) dout

If you want to connect other devices, you need a chip select circuit.
Sorry. I don't have the environment to develop MiSTer...I can't try quickly.

Thanks for introducing me to DeepL. ツ

[spark2k06]

Could you please check the wiring between the chipset and the BIOS-ROM?

The KFPC-XT assumed the following wiring

Chipset address -> BIOS-ROM(or other devices) addr
Chipset data_bus -> BIOS-ROM(or other devices) din
Chipset data_bus_ext <- BIOS-ROM(or other devices) dout

If you want to connect other devices, you need a chip select circuit.
Sorry. I don't have the environment to develop MiSTer...I can't try quickly.

Thanks for introducing me to DeepL. ツ

Thank you for the information.

I have made the changes you mentioned, and it doesn't work. Now I remember that what I actually changed was directly the processor_ready signal, which I forced to 1'b1 in the 8088 module (MCL86), module that by the way I am using in maximum mode, required by KFPC_XT:

processor_ready_setted_01.png (31.13 KiB) Viewed 20158 times

processor_ready_setted_02.png (27.09 KiB) Viewed 20158 times

However, as can be seen, only the first instruction, a jump to FE05B, is recognised:

first bytes.png (3.95 KiB) Viewed 20158 times

A jump that doesn't really take place. As I made the change at the wrong signal, I decided not to continue. As I said, if instead of processor_ready, I force io_channel_ready to 1'b1, processor_ready stays at 1'b0... so it doesn't work.

[spark2k06]

@kitune-san

I suggest you try to integrate the MicroCoreLab's MCL86 project into your project by yourself, without using the MiSTer environment, and see if you can reproduce some first instructions, including jumps... even if it's not a full BIOS.

Maybe with that test I'll get a better understanding of how you set it up

[spark2k06]

I have just seen all these changes you suggest:

https://github.com/kitune-san/PCXT_MiST ... 7d247e3d70

As soon as I have some time, I'll try it out and let you know.

Thank you very much!

[kitune-san]

Thank you for the information.

I will check on the operation of processor_ready.

The output of AD_OUT seems to change during the process.
You may need a latch before the cpu_address input on the chipset. Just like a real CPU.

Anyway, I will give it a try.

thank you.

[kitune-san]

> You may need a latch before the cpu_address input on the chipset. Just like a real CPU.

this one

[kitune-san]

> I will check on the operation of processor_ready.

I may have found the cause.

.memory_access_ready is deleted in u_CHIPSET.
please set 1.

[kitune-san]

oh miss.

forget memory_access_ready.

enable_sdram is deleted in u_CHIPSET.
please set 0 if you unuse this module.

[spark2k06]

Re-testing with all suggested changes, and disabling sdram temporarily.

Now it works better, it is no longer necessary to force processor_ready to 1'b1. But the same happens as if it was forced, there is no jump to address 0xFE05B.

Probably due to lack of knowledge, I haven't implemented the latch on cpu_address correctly, because it works worse than simply setting cpu_address to the chipset module. Is it possible that it also has to do with the clock operation?, some comments on the pull request I sent you:

https://github.com/kitune-san/PCXT_MiSTer/pull/1

Interesting information I've found... as I say, one thing I don't know is also the role played by the configuration of the clocks:

http://www.ee.hacettepe.edu.tr/~alkar/E ... _week8.pdf

In an original PC we have the 8284A chip, which, starting from a 14.318Mhz clock (supposedly system), generates the others... cpu_clk (clk / 3), Timer (clk / 12)... the keyboard module I think it should work at clk / 2... anyway, this is another issue too where I'm a bit lost.

[spark2k06]

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.

[spark2k06]

I have also tried the following, without success:

ALE.png (1.76 KiB) Viewed 19892 times

ALE (When one is present, it indicates that addresses are sent out on AD, otherwise it is the data bus).

[kitune-san]

ALE pulse is short. Therefore, that circuit does not work.

I am considering the following circuit.

Code: Select all

wire [7:0] adout;
reg [19:0] cpu_address;

CHIPSET u_CHIPSET (
	…
	.cpu_address                        (cpu_address),
	.address_latch_enable               (address_latch_enable),
	…
);

i8088 B1(
	…
	.ad_out(adout)
	…
);

always @(posedge clk_cpu) begin
	if (address_latch_enable)
		cpu_address <= adout;
	else
		cpu_address <= cpu_address;
end

[kitune-san]

I think the clock generation in the 8284A can be replaced by a PLL in the FPGA.

[kitune-san]

I don't think 14.318Mhz needs to be generated by PLL.

Please refer to timer_clock in Peripherals.sv for the clock to 8253A. Maybe one more step is needed.

The KFPS2KB does not require a dedicated clock. (but different from the original).

[kitune-san]

I mistake.

NG:

Code: Select all

wire [7:0] adout;

OK:

Code: Select all

wire [19:0] adout;

[spark2k06]

I think the clock generation in the 8284A can be replaced by a PLL in the FPGA.

I now use clock dividers, but there is no problem generating clocks via PLL. The question I have is rather related to which clocks to distribute among the modules. For example, to the chipset module what would you pass? clk_14_318 or clk_4_77? To the CPU module? Would it only work with clk_4_77, or could something faster (turbo mode) be set to 7_26? If so... this is the same frequency that should be passed to the chipset module to be synchronized or it should always carry the bus frequency, that is, 14_318?

[spark2k06]

I mistake.

NG:

Code: Select all

wire [7:0] adout;

OK:

Code: Select all

wire [19:0] adout;

Thanks, I'll try it out and let you know.

[kitune-san]

I think the clock generation in the 8284A can be replaced by a PLL in the FPGA.

I now use clock dividers, but there is no problem generating clocks via PLL. The question I have is rather related to which clocks to distribute among the modules. For example, to the chipset module what would you pass? clk_14_318 or clk_4_77? To the CPU module? Would it only work with clk_4_77, or could something faster (turbo mode) be set to 7_26? If so... this is the same frequency that should be passed to the chipset module to be synchronized or it should always carry the bus frequency, that is, 14_318?

Input the same clock as the CPU to the chipset module: 4_77MHz.

Sorry.I did not assume about the turbo mode.
If turbo mode is needed, the clock supply to the timer (timer_n_clock) should be reviewed.

[spark2k06]

This is already looking better!

Jump_to_FE05B.png (10.56 KiB) Viewed 19657 times

[kitune-san]

> Input the same clock as the CPU to the chipset module: 4_77MHz.

I have created a clock schematic for KFPC-XT. I hope this is helpful.

KFPC-XT_Clocking_Scheme.png (82.78 KiB) Viewed 19520 times

> Sorry.I did not assume about the turbo mode.
> If turbo mode is needed, the clock supply to the timer (timer_n_clock) should be reviewed.

In order to enable turbo mode, I am considering changing CHIPSET on KFPC-XT as follows:

KFPC-XT_Clocking_Scheme_Supports_Turbo.png (96.86 KiB) Viewed 19520 times

But I have no idea to do clock switching.

[spark2k06]

This would be great! I would adapt the clock inputs, no problem there.

Regarding the SDRAM, MiSTer has that type of memory, I'll add it later, for now I'm using BRAM because it makes the debugging process easier.

On the graphic side, I use the Graphics Gremlin project by TubeTimeUS , I don't know if you know it, but it's also very good.

By the way, with MiSTer, switching clocks is very simple, and would be done from the OSD menu.

[spark2k06]

MiSTer PCXT.gif (26.77 MiB) Viewed 19349 times

I update the temporary branch of KFPC-XT:

https://github.com/spark2k06/PCXT_MiSTe ... PC-XT-test

In the video I show the possibility of frequency switch between 4.77Mhz and 7.16Mhz (Turbo mode), although it is currently not enabled until we have adapted the corresponding modules (chipset, timer...).

test 2

• Signals fixes in the main module (PCXT.sv) suggested by @kitune-san
• Signal fixes in the Graphics Gremlin module and support of the same in the Peripherals module.
• Temporary modification of the test BIOS based on Next186 (in the future this BIOS will not be used, but an original one from PCXT).
• Splash Screen update.

Upcoming tasks

• Enable keyboard module.
• Enable IRQs.

[pgimeno]

Awesome progress!

Will there be an option for cold/warm boot? From the video it seems to be doing a warm boot only, though I might be misunderstanding something.

[spark2k06]

Awesome progress!

Will there be an option for cold/warm boot? From the video it seems to be doing a warm boot only, though I might be misunderstanding something.

Thank you!

What you are seeing in the video is a hard reset, although it may be that what is throwing you off is that you don't see the splash screen again. This is because, with it enabled (it's configurable via OSD), I have it programmed to only show it once for 5 seconds, only when the core loads. The splash screen is not BIOS-specific, but is loaded directly into the VRAM of the Graphics Gremlin at core startup. In fact, if for whatever reason the BIOS did not start booting, the splash screen would be displayed permanently, with the cursor blinking.

You will also be able to do warm restarts, as long as the BIOS Keyboard interrupt has not been hooked and is avoided, by using CTRL+ALT+DEL.

[kitune-san]

As you might already know,

KF8259 and KF8255 should be configured when using the keyboard(KFPS2KB).
Also, a reset pulse should be output after reading the key code.

KFPC-XT Keybord Control Diagram.png (83.21 KiB) Viewed 19267 times

[spark2k06]

As you might already know,

KF8259 and KF8255 should be configured when using the keyboard(KFPS2KB).
Also, a reset pulse should be output after reading the key code.

KFPC-XT Keybord Control Diagram.png

Thanks for the detailed information

[pgimeno]

As you might already know,

KF8259 and KF8255 should be configured when using the keyboard(KFPS2KB).
Also, a reset pulse should be output after reading the key code.

KFPC-XT Keybord Control Diagram.png

Isn't all that done by software?

I mean, the 8255 is present in the original PC, and the BIOS should configure it; and ditto for the 8259. As for the reset pulse, the typical key read sequence in a keyboard interrupt handler is:

Code: Select all

  IN  AL,60h ; read the keycode
  MOV AH,AL  ; save it for later
  IN  AL,61h ; preserve bits 0-6
  OR  AL,80h ; set bit 7
  OUT 61h,AL ; send high level in bit 7 (pulse start)
  AND AL,7Fh ; clear bit 7
  OUT 61h,AL ; send low level in bit 7 (pulse end)
  MOV AL,20h
  OUT 20h,AL ; send interrupt acknowledgement to 8259

or something to that effect.

[kitune-san]

Yes, key code reading and reset pulse output should be done by software.

[kitune-san]

Sorry. I found a bug in KFPS2KB.

I was thinking that after receiving 0xF0, if the 8th bit of the next code is set to 1, it can be converted to the XT key code.
But It was wrong.

Comment out part of the code as shown below.

Code: Select all

        else if (recieved_flag) begin
            if (irq == 1'b1) begin
                // Error
                irq         <= 1'b1;
                break_flag  <= 1'b0;
                keycode     <= 8'hFF;
            end
//            else if (register == 8'hF0) begin
//                // Set break flag
//                irq         <= 1'b0;
//                break_flag  <= 1'b1;
//                keycode     <= keycode;
//            end
//            else if (break_flag == 1'b1) begin
//                // Break code
//                irq         <= 1'b1;
//                break_flag  <= 1'b0;
//                keycode     <= {1'b1, register[6:0]};
//            end
            else begin
//                // Make code
                irq         <= 1'b1;
                break_flag  <= 1'b0;
                keycode     <= register[7:0];
            end
        end
        else begin
            irq         <= irq;
            break_flag  <= break_flag;
            keycode     <= keycode;
        end
    end

If XT code is required, conversion on the BIOS side is necessary.