Page 2 of 47

Re: MiSTer PCXT

Posted: Wed May 18, 2022 12:03 pm
by kitune-san
.data_bus is commented out too. Please

// .data_bus (data_bus),

change to following

.data_bus (CPU_DIN),

Re: MiSTer PCXT

Posted: Wed May 18, 2022 1:05 pm
by 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. ツ

Re: MiSTer PCXT

Posted: Wed May 18, 2022 4:16 pm
by spark2k06
kitune-san wrote: Wed May 18, 2022 1:05 pm 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
processor_ready_setted_01.png (31.13 KiB) Viewed 20161 times
processor_ready_setted_02.png
processor_ready_setted_02.png (27.09 KiB) Viewed 20161 times
However, as can be seen, only the first instruction, a jump to FE05B, is recognised:
first bytes.png
first bytes.png (3.95 KiB) Viewed 20161 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.

Re: MiSTer PCXT

Posted: Wed May 18, 2022 4:22 pm
by 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 :)

Re: MiSTer PCXT

Posted: Wed May 18, 2022 5:33 pm
by 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!

Re: MiSTer PCXT

Posted: Wed May 18, 2022 9:10 pm
by 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.

Re: MiSTer PCXT

Posted: Wed May 18, 2022 9:44 pm
by kitune-san
> You may need a latch before the cpu_address input on the chipset. Just like a real CPU.

this one

Re: MiSTer PCXT

Posted: Wed May 18, 2022 11:40 pm
by 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.

Re: MiSTer PCXT

Posted: Wed May 18, 2022 11:49 pm
by kitune-san
oh miss.

forget memory_access_ready.

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

Re: MiSTer PCXT

Posted: Thu May 19, 2022 4:19 am
by 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.

Re: MiSTer PCXT

Posted: Thu May 19, 2022 5:11 am
by 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.

Re: MiSTer PCXT

Posted: Thu May 19, 2022 6:00 am
by spark2k06
I have also tried the following, without success:
ALE.png
ALE.png (1.76 KiB) Viewed 19895 times
ALE (When one is present, it indicates that addresses are sent out on AD, otherwise it is the data bus).

Re: MiSTer PCXT

Posted: Thu May 19, 2022 11:08 am
by 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

Re: MiSTer PCXT

Posted: Thu May 19, 2022 11:36 am
by kitune-san
I think the clock generation in the 8284A can be replaced by a PLL in the FPGA.

Re: MiSTer PCXT

Posted: Thu May 19, 2022 12:31 pm
by 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).

Re: MiSTer PCXT

Posted: Thu May 19, 2022 3:20 pm
by kitune-san
I mistake.

NG:

Code: Select all

wire [7:0] adout;
OK:

Code: Select all

wire [19:0] adout;

Re: MiSTer PCXT

Posted: Thu May 19, 2022 3:43 pm
by spark2k06
kitune-san wrote: Thu May 19, 2022 11:36 am 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?

Re: MiSTer PCXT

Posted: Thu May 19, 2022 3:44 pm
by spark2k06
kitune-san wrote: Thu May 19, 2022 3:20 pm 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.

Re: MiSTer PCXT

Posted: Thu May 19, 2022 4:22 pm
by kitune-san
spark2k06 wrote: Thu May 19, 2022 3:43 pm
kitune-san wrote: Thu May 19, 2022 11:36 am 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.

Re: MiSTer PCXT

Posted: Thu May 19, 2022 5:38 pm
by spark2k06
This is already looking better! :)
Jump_to_FE05B.png
Jump_to_FE05B.png (10.56 KiB) Viewed 19660 times

Re: MiSTer PCXT

Posted: Fri May 20, 2022 3:11 pm
by 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
KFPC-XT_Clocking_Scheme.png (82.78 KiB) Viewed 19523 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
KFPC-XT_Clocking_Scheme_Supports_Turbo.png (96.86 KiB) Viewed 19523 times
But I have no idea to do clock switching.

Re: MiSTer PCXT

Posted: Fri May 20, 2022 3:54 pm
by 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.

Re: MiSTer PCXT

Posted: Sat May 21, 2022 5:22 am
by spark2k06
MiSTer PCXT.gif
MiSTer PCXT.gif (26.77 MiB) Viewed 19352 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.

Re: MiSTer PCXT

Posted: Sat May 21, 2022 12:59 pm
by 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.

Re: MiSTer PCXT

Posted: Sat May 21, 2022 1:23 pm
by spark2k06
pgimeno wrote: Sat May 21, 2022 12:59 pm 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.

Re: MiSTer PCXT

Posted: Sat May 21, 2022 1:28 pm
by 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
KFPC-XT Keybord Control Diagram.png (83.21 KiB) Viewed 19270 times

Re: MiSTer PCXT

Posted: Sat May 21, 2022 1:30 pm
by spark2k06
kitune-san wrote: Sat May 21, 2022 1:28 pm 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 ;)

Re: MiSTer PCXT

Posted: Sat May 21, 2022 2:51 pm
by pgimeno
kitune-san wrote: Sat May 21, 2022 1:28 pm 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.

Re: MiSTer PCXT

Posted: Sat May 21, 2022 2:57 pm
by kitune-san
Yes, key code reading and reset pulse output should be done by software.

Re: MiSTer PCXT

Posted: Sat May 21, 2022 3:12 pm
by 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.