MiSTer PCXT

[spark2k06]

Maybe your emulated peripherals are causing more wait-states or otherwise causing more delays than those used on the IBM motherboard?

Yes, most probably.

One other possibility is unintended interrupts due to incorrect debouncing which are 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...

Another important point, right.

[kitune-san]

What is the duty of the 4.77 MHz clock?
Could this CPU core operate at 50% duty?

[kitune-san]

What is the duty of the 4.77 MHz clock?
Could this CPU core operate at 50% duty?

Sorry.I made a mistake.
It is already running at 33%.

[kitune-san]

Please forget it.

Sorry.I made a mistake.
It is already running at 33%.

Could you try the following changes?

in clk_div3

Code: Select all

module clk_div3(clk, clk_out);
 
input clk;
output clk_out;
 
reg [1:0] pos_count = 2'b00; 
reg [1:0] neg_count = 2'b00;
wire [1:0] r_nxt;
 
//always @(posedge clk)
//if (pos_count ==2) pos_count <= 0;
//else pos_count<= pos_count +1;
 
//always @(negedge clk)
//if (neg_count ==2) neg_count <= 0;
//else neg_count<= neg_count +1;
 
//assign clk_out = ((pos_count == 2) | (neg_count == 2));

always @(posedge clk) begin
	if (pos_count ==2) begin
		pos_count <= 0;
		clk_out <= 1'b1;
	end
	else begin
		pos_count<= pos_count +1;
		clk_out <= 1'b0;
	end
end

endmodule

[spark2k06]

Please forget it.

Sorry.I made a mistake.
It is already running at 33%.

Could you try the following changes?

in clk_div3

Code: Select all

module clk_div3(clk, clk_out);
 
input clk;
output clk_out;
 
reg [1:0] pos_count = 2'b00; 
reg [1:0] neg_count = 2'b00;
wire [1:0] r_nxt;
 
//always @(posedge clk)
//if (pos_count ==2) pos_count <= 0;
//else pos_count<= pos_count +1;
 
//always @(negedge clk)
//if (neg_count ==2) neg_count <= 0;
//else neg_count<= neg_count +1;
 
//assign clk_out = ((pos_count == 2) | (neg_count == 2));

always @(posedge clk) begin
	if (pos_count ==2) begin
		pos_count <= 0;
		clk_out <= 1'b1;
	end
	else begin
		pos_count<= pos_count +1;
		clk_out <= 1'b0;
	end
end

endmodule

I have done the test but the behaviour and performance is the same.

[kitune-san]

Does the benchmark use 8253 for the counter?
Perhaps PCLK should be divided by 2 of 4.77 MHz. (2.385MHz)
I was looking at the 8253 datasheet and the PCXT schematic and thought.

[kitune-san]

I think one of the reasons the keyboard is not responding is because of the slow timing of sending clear pulses.
I think PCXT needs to force the PS/2 CLK to drop LOW after receiving the key code or add a FIFO between PS2KB and 8255.

I would like to research. but I have not received the MiSter yet.

[spark2k06]

Does the benchmark use 8253 for the counter?
Perhaps PCLK should be divided by 2 of 4.77 MHz. (2.385MHz)
I was looking at the 8253 datasheet and the PCXT schematic and thought.

I'll try it out and let you know, thanks. I will also do some testing with GWBasic as I did at the beginning of the development with ROM Basic, the instruction execution will almost certainly not use a timer, and I will measure the time with a phisical stopwatch.

[spark2k06]

I think one of the reasons the keyboard is not responding is because of the slow timing of sending clear pulses.
I think PCXT needs to force the PS/2 CLK to drop LOW after receiving the key code or add a FIFO between PS2KB and 8255.

I would like to research. but I have not received the MiSter yet.

That detail is the least worrying for now, a little tapping on the keyboard random keys gets it working (Sometimes it takes you longer than others to get it) and once it does it works continuously.

On a curious note, this happens only after MSDos has finished booting, during the BIOS it always works fine, I know this because I need to hold down the Alt key to get it to load serially.

[kitune-san]

Are there any keys that are not particularly responsive?
For example: R-Alt, R-Ctrl, Numeric Enter ...

[spark2k06]

Are there any keys that are not particularly responsive?
For example: R-Alt, R-Ctrl, Numeric Enter ...

From the BIOS, at least everything that can be pressed works, the function keys, ESC and Alt Left. In MSDos, when booting, none of them work... until you get it to work with the method I mentioned. It doesn't happen all the time, but it happens almost all the time.

[kitune-san]

On a curious note, this happens only after MSDos has finished booting, during the BIOS it always works fine, I know this because I need to hold down the Alt key to get it to load serially.

This may happen if keyboard interrupts are not accepted while the OS is loading....
Are you operating the keyboard when loading the OS (DOS)?

[spark2k06]

The keyboard issue, who knows, could be related to the timer clock you mentioned.

[spark2k06]

Are you operating the keyboard when loading the OS (DOS)?

I try to release the Alt key in time before the OS starts loading, yes.

Also, what is the speed of clk_uart?

By the way, I forgot to answer this. The uart rate is 1.8432... needed for a maximum of 115.2Kb transfer.

[MicroCoreLabs]

I have some thoughts and suggestions:

The maximum_mode BIU I wrote will only work with a 33% duty cycle 4.77Mhz clock. The state machine actually only looks at the 4.77Mhz clock once, and afterwards just counts 100Mhz clocks to time events within that bus cycle. This saved me gates as well as provided 10ns granularity within the bus cycle. But it also means that it will only work with a 4.77Mhz clock!

If one of your design goals is to allow the bus frequency to change, then you will need to update the BIU with a method more sensitive to the clock, but I don't think this is necessary as there are better ways to accelerate the MCL86, but Ill get to that in a minute.

One thing I should note is that the BIU is *not* the MCL86 x86 core! It is just a bus interface unit which you can customize in any way that you want. I have documented the protocol in which he EU requests bus cycles from the BIU, so as long as you are compatible with that, then you can develop any local bus protocol you wish. The maximum mode, for example, requires an external 8288 which adds gates, affects timing, and must be emulated correctly - so why not eliminate it and integrate these signals into the BIU in a similar way to the 8088's minimum mode? What I am stressing is that your FPGA's internal bus interface does *not* need to be compatible with any physical peripherals, so it can free you to make your own which might be more convenient.

Another note is that I have never tried running the MCL86 faster than 4.77Mhz clock, so I'm not 100% sure it works with a bus frequency as fast as 7-8Mhz. It might, but I haven't tried it. The way I achieved acceleration was done in a different way which I will describe now.

There are two ways to I accelerated the MCL86. One was to simply remove the clock cycle accuracy which was done with one line of code:

Code: Select all

// Instruction cycle accuracy counter. This can be tied to '1' to disable x86 cycle compatibiliy.
assign BIU_CLK_COUNTER_ZERO = (clock_cycle_counter==13'h0000) ? 1'b1 : 1'b0; 

If you force this signal to '1' then the micro sequencer will not wait until the timing-accurate clock count is reached and will immediately begin execution of the next opcode. This gives a decent bump to the performance of the core.

The other way was to integrate some of the RAM and ROM into the BIU and provide the option to bypass the four-4.77Mhz-clock local bus cycle and simply return the data in a few 100Mhz clock cycles. This provides tremendous acceleration! When running MIPS.EXE it showed this IBM PCjr was running about as fast as an 8Mhz PC AT: https://microcorelabs.wordpress.com/202 ... r-mcl86jr/

My suggestion would be to stick with the 4.77Mhz clock for now and later-on add hooks for acceleration which include eliminating cycle accuracy and having the option for RAM/ROM to run outside of the slow 4.77Mhz 8088 local bus controller.

[spark2k06]

Thank you very much for the detailed information MCL86, I agree, I will de-prioritise the use of turbo mode for now and focus only on 4.77Mhz.

[akeley]

Thank you all for making this happen.

I was able to load the earlier betas (and display on a 15kHz TV, to my great delight) but the latest one gets stuck on the splash screen. Is this to be expected on my standard MiSTer setup, or can I somehow get it going? Itching to try some software on this core...

[spark2k06]

Thank you all for making this happen.

I was able to load the earlier betas (and display on a 15kHz TV, to my great delight) but the latest one gets stuck on the splash screen. Is this to be expected on mys tandard MiSTer setup, or can I somehow get it going? Itching to try some software on this core...

Place the boot.rom file from the repository in games/PCTX

[spark2k06]

beta 0.7

* 4.77Mhz CPU clock with 33% duty cycle, thanks to @MicroCoreLabs
* Peripheral clock now works at half cpu clock, for correct synchronisation with the 8253 timer, thanks to @kitune-san
* Turbo option is disabled for the moment, requires a redesign of the BIU... for the to-do list

https://github.com/spark2k06/PCXT_MiSTe ... 09bf6bcd41

Does the benchmark use 8253 for the counter?
Perhaps PCLK should be divided by 2 of 4.77 MHz. (2.385MHz)
I was looking at the 8253 datasheet and the PCXT schematic and thought.

That seems to have been the problem. The CPU was actually running at 4.77Mhz, now the results are more consistent with this same benchmark:

benchmark.jpg (215.94 KiB) Viewed 6809 times

However, not all benchmarks work correctly, each one will use its own calculation methods and they do not always work correctly. For example, the great 8088MPH demo gives these results at startup:

8080MPH.jpg (223.28 KiB) Viewed 6809 times

Of course, this demo cannot be expected to work perfectly for the time being, but it will be a good example for fine-tuning all the details of the core. In fact, many games do not even work properly, for example:

AlleyCat: It freezes, sometimes with a continuous beeping sound. Possibly problems with the timer or interrupts.
Last Mission: The keyboard doesn't work, so you can't start playing. Possibly because of problems with interruptions.
Abadía del crimen: The keyboard doesn't work, so you can't start playing. Possibly because of problems with interruptions.
Solomon's Key: The keyboard doesn't work, so you can't start playing. Possibly because of problems with interruptions.
Centipede: During the game, the ship moves by itself to the left and up, and continuously firing... possibly because of problems with interruptions.

As for the 8088MPH demo, apart from the initial benchmark, the timings initially seem correct and the music from the PC-Speaker as well, however:

* Sometimes it slows down, then goes back to normal.
* The CGA part does not display well in cases where the composite video feature is to be used, where at the moment it is not implemented in this core.
* When it gets to the back to the future part, it stops the execution.


In short, numerous problems that will have to be checked.

On the other hand, user somhi has created a fork for the SocKit board, and has realised that only the Rx and Tx signals are needed to load the OS via UART:

https://github.com/somhi/PCXT_SoCkit

[MicroCoreLabs]

If I remember correctly, the 8088MPM demo makes frequent use of the HALT opcode and is very dependent on timer interrupts, so this is consistent with your suspicion that interrupts/timers are causing problems with the the other games. I also think the demo will only run through to the end if you have the full 640KB of RAM, so halting early is probably normal.

One thought about your test results showing the core is a little fast.. If you are not implementing the DRAM refresh cycles then your BIU, and system, will be slightly faster than the stock IBM PC.

Great progress!

[spark2k06]

By the way, there are not only games that don't work, there are games that do work in the current state of the core, and they work very well and at the right speed

MiSTer_PCXT_GAMES_OK.png (595.06 KiB) Viewed 6682 times

Examples of monochrome display simulation in green, amber and B&W, available from the OSD menu of the MiSTer:

MiSTer_PCXT_MADMIX.png (386.31 KiB) Viewed 6682 times

[wark91]

Great Milestone !!!

[thorr]

I don't remember ever seeing Paku Paku before, but that game appears to be a genius creation. It has 16 color graphics in CGA. It does this by using text and extended ASCII characters in 16 colors to create the graphics. When I saw the screenshot above, I thought the core already had Tandy/PCJr graphics capabilities, but it is just that game doing fancy stuff in a 16 color text mode. Very cool! https://www.classicdosgames.com/game/Paku_Paku.html

[suverman]

Thank you for adding the amber, green and black white simulation to the core. Perfect <3

[spark2k06]

I don't remember ever seeing Paku Paku before, but that game appears to be a genius creation. It has 16 color graphics in CGA. It does this by using text and extended ASCII characters in 16 colors to create the graphics. When I saw the screenshot above, I thought the core already had Tandy/PCJr graphics capabilities, but it is just that game doing fancy stuff in a 16 color text mode. Very cool! https://www.classicdosgames.com/game/Paku_Paku.html

The implementation of Tandy modes seems to be partial, so it probably does not work well..... would require a major overhaul. The original Graphics Gremlin project from TubeTimeUS, on which I have based it, is as follows:

https://github.com/schlae/graphics-grem ... in/verilog

Regarding this project, I also intend to add a second module to have both CGA (via HDMI) and MDA (via VGA) optionally from the OSD menu, let's see when I can test it, could be very interesting!

[spark2k06]

@kitune-san, I have just tested your solution in the branch test_ps2_lock:

https://github.com/kitune-san/PCXT_MiST ... 1053f352e2

I can confirm that now there is never a problem with the keyboard when starting the OS, thank you very much, I add it to the master branch. This doesn't solve the games where the keyboard doesn't work, but it is very useful to have the keyboard always available from OS startup.

[kitune-san]

It seems to me that keyboard and timer interrupts do not work when disk access (interrupt) occurs.

[spark2k06]

It seems to me that keyboard and timer interrupts do not work when disk access (interrupt) occurs.

In any case, your proposal solves the problem after OS boot, so it works. On the other hand, I understand that during the operation of a game it is not usual to access the disk, so the fact that in some of them the keyboard does not work must be for another reason, possibly related to interruptions, but not disk access.

[kitune-san]

KF8288 may be incorrect about the treatment of halt states.

I will continue to investigate.

[spark2k06]

... In fact, many games do not even work properly, for example:

AlleyCat: It freezes, sometimes with a continuous beeping sound. Possibly problems with the timer or interrupts.
Last Mission: The keyboard doesn't work, so you can't start playing. Possibly because of problems with interruptions.
Abadía del crimen: The keyboard doesn't work, so you can't start playing. Possibly because of problems with interruptions.
Solomon's Key: The keyboard doesn't work, so you can't start playing. Possibly because of problems with interruptions.
Centipede: During the game, the ship moves by itself to the left and up, and continuously firing... possibly because of problems with interruptions.

I would like to make one point here. Last Mission and Abadía del crimen work correctly, but for some reason this core has some incompatibility with Sergey Kiselev's PCXT BIOS. Now I'm testing with JukoST BIOS and in these games the keyboard works, however, during the BIOS boot it always shows this message:

Juko ST Bios.jpg (82.34 KiB) Viewed 6055 times

Despite this, however, the keyboard functions correctly.

The other games have the same behaviour, but I am surprised by Solomon's Key... I think it should work with cursors and the character doesn't move, but the rest of the keys work (F1 to exit, any key to start the game, etc...).

Also as a curiosity, I have tried other ROMs, such as the original IBM ROMs like ibmjr, ibm5150/5160 and they don't work.

Finally, I attach the latest version of the XTIDE Universal BIOS and HD detection via the serial port by default, which can be loaded into memory from the OSD menu, as it will be loaded from address F0000h. The same you can do with JukoST, in this case you would have to prepare with a hex editor a 64Kb ROM with the XTIDE Universal BIOS at the beginning and JukoST at the end (from FE000h) and the same, you can load it in memory from the OSD menu.

Edit: I also notice that with JukoST, the screen scrolling when doing a DIR is much smoother and faster than with Sergey Kiselev's PCXT ROM.