Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

somhi
Posts: 88
Joined: Mon Jul 18, 2022 4:37 pm
Has thanked: 25 times
Been thanked: 25 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by somhi »

kitune-san wrote: Mon Mar 06, 2023 2:21 pm

Is it possible to add the following code to IDE.v and see the signal with Signalap like MiSTer above?

That should be no problem. I'll add that tonight and see if it confirms the debug data that the MiST firmware is showing, which is CHS 0/2/1.

kitune-san
Top Contributor
Posts: 401
Joined: Wed May 18, 2022 11:20 am
Has thanked: 127 times
Been thanked: 412 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by kitune-san »

Thank you!

One correction. "(* noprune *)" before reg.

Code: Select all

(* noprune *) reg [7:0]   sector_number;
(* noprune *) reg [7:0]   sector;
(* noprune *) reg [15:0]  cylinder;
(* noprune *) reg [7:0]   dev_head;

always @(posedge clk) begin
    sector_number   <= tfr[2];
    sector          <= tfr[3];
    cylinder        <= {tfr[5], tfr[4]};
    dev_head      <= tfr[6];
end
somhi
Posts: 88
Joined: Mon Jul 18, 2022 4:37 pm
Has thanked: 25 times
Been thanked: 25 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by somhi »

kitune-san wrote: Mon Mar 06, 2023 2:46 pm

t

More comments from Gyurco:

0/0/1 should be the MBR (and partition table), why does it start with H=2 now? It might disregard the partition table, and automatically assumes a FAT boot sector at 0/2/1? Then the different geometry problem comes in. Looks like the firmware assumes sectors/cylinder=63. What should be used for your image?

BTW, head is at tfr[6], and all of the commands you dumped has 02 in tfr[6]. Also this register has the master/slave selector. Something strange happens with this register. I think you should check writes to 306H.

somhi
Posts: 88
Joined: Mon Jul 18, 2022 4:37 pm
Has thanked: 25 times
Been thanked: 25 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by somhi »

kitune-san wrote: Mon Mar 06, 2023 2:21 pm

Is it possible to add the following code to IDE.v and see the signal with Signaltap like MiSTer above?

Output corresponding to write_device_head stp (address 306):

ksnip_20230306-210038.png
ksnip_20230306-210038.png (208.65 KiB) Viewed 4279 times

cylinder = {tfr[5], tfr[4]} = 0h
dev_head = tfr[6] = A0h
sector = tfr[3] = 01h

Output corresponding to write_sector_count stp (address 302):

ksnip_20230306-215103.png
ksnip_20230306-215103.png (213.13 KiB) Viewed 4263 times

Output corresponding to write_sector_number stp (address 303):

ksnip_20230306-211912.png
ksnip_20230306-211912.png (199.42 KiB) Viewed 4272 times

Output corresponding to write_cylinder_low stp (address 304):

ksnip_20230306-213136.png
ksnip_20230306-213136.png (212.21 KiB) Viewed 4269 times

Output corresponding to write_cylinder_high stp (address 305):

ksnip_20230306-214100.png
ksnip_20230306-214100.png (212.28 KiB) Viewed 4264 times
kitune-san
Top Contributor
Posts: 401
Joined: Wed May 18, 2022 11:20 am
Has thanked: 127 times
Been thanked: 412 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by kitune-san »

RAW image; I don't think it starts with H=2.
As confirmed by Mister before, you can see that CHS=0/0/1 is read out as the boot sector.
Looking at the somhi waveform, I see that the core is writing 0xA0 to 0x306. This means that core is writing H=0.

However, it may have changed just before the write command, so if you like, take the trigger under the following conditions and observe the signal (sector_number/sector/cylinder/dev_head) that you just added.

cpu_address=307h
data_bus=C4h (read multiple sector(s) command)
io_write_n=0h
ide_cs1_fx=9h

First_read.png
First_read.png (57.06 KiB) Viewed 4246 times
somhi
Posts: 88
Joined: Mon Jul 18, 2022 4:37 pm
Has thanked: 25 times
Been thanked: 25 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by somhi »

kitune-san wrote: Mon Mar 06, 2023 10:12 pm

RAW image; I don't think it starts with H=2.
As confirmed by Mister before, you can see that CHS=0/0/1 is read out as the boot sector.
Looking at the somhi waveform, I see that the core is writing 0xA0 to 0x306. This means that core is writing H=0.

However, it may have changed just before the write command, so if you like, take the trigger under the following conditions and observe the signal (sector_number/sector/cylinder/dev_head) that you just added.

cpu_address=307h
data_bus=C4h (read multiple sector(s) command)
io_write_n=0h
ide_cs1_fx=9h
First_read.png

ksnip_20230306-233503.png
ksnip_20230306-233503.png (206.04 KiB) Viewed 4235 times
kitune-san
Top Contributor
Posts: 401
Joined: Wed May 18, 2022 11:20 am
Has thanked: 127 times
Been thanked: 412 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by kitune-san »

It really does have H=2...
we need to look into what is writing this.(bios or mist system)

somhi
Posts: 88
Joined: Mon Jul 18, 2022 4:37 pm
Has thanked: 25 times
Been thanked: 25 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by somhi »

ok perfect. We will find out what is happening, with your help and Slingshot's help on Atari-forums.
All updates on my side go to the new mist branch https://github.com/somhi/PCXT_DeMiSTify/tree/mist

kitune-san
Top Contributor
Posts: 401
Joined: Wed May 18, 2022 11:20 am
Has thanked: 127 times
Been thanked: 412 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by kitune-san »

Thanks.

To confirm that the BIOS is really writing H=2, could you please try the following conditions to see if it triggers

cpu_address=306h
data_bus=02h or X2h
io_write_n=0h
ide_cs1_fx=0h

The fix suggested by slingshot2 in the atari forum may solve the problem

somhi
Posts: 88
Joined: Mon Jul 18, 2022 4:37 pm
Has thanked: 25 times
Been thanked: 25 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by somhi »

kitune-san wrote: Mon Mar 06, 2023 11:49 pm

The fix suggested by slingshot2 in the atari forum may solve the problem

Good news is that we sorted out the CHS boot sector problem, so now it loads the right CHS 0:0:1.

Bad news, is that it gets stuck booting after reading the boot sector.

Tried in SiDi (thanks Carlos) and Deca_MiST targets with different boot images.

Attachments
photo_2023-03-07_15-09-59.jpg
photo_2023-03-07_15-09-59.jpg (106.29 KiB) Viewed 4081 times
photo_2023-03-07_15-10-01.jpg
photo_2023-03-07_15-10-01.jpg (77.96 KiB) Viewed 4081 times
somhi
Posts: 88
Joined: Mon Jul 18, 2022 4:37 pm
Has thanked: 25 times
Been thanked: 25 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by somhi »

more debugging from Gyurco at https://atari-forum.com/viewtopic.php?p=444112#p444112

Missing images for you
However looks like it starts to correctly execute the MBR from 7c00:

pcxt1.png
pcxt1.png (73.86 KiB) Viewed 4020 times
somhi
Posts: 88
Joined: Mon Jul 18, 2022 4:37 pm
Has thanked: 25 times
Been thanked: 25 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by somhi »

some updates, OS already booting, but freezing thereafter.

kitune-san
Top Contributor
Posts: 401
Joined: Wed May 18, 2022 11:20 am
Has thanked: 127 times
Been thanked: 412 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by kitune-san »

MiSTerPCXT used a specific table for geometry calculation(storage CHS).
However OS seems to have already booted, so it may not be related to this issue.

https://github.com/MiSTer-devel/Main_Mi ... p#L54-L198

somhi
Posts: 88
Joined: Mon Jul 18, 2022 4:37 pm
Has thanked: 25 times
Been thanked: 25 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by somhi »

kitune-san wrote: Tue Mar 07, 2023 10:10 pm

MiSTerPCXT used a specific table for geometry calculation(storage CHS).
However OS seems to have already booted, so it may not be related to this issue.

https://github.com/MiSTer-devel/Main_Mi ... p#L54-L198

some updates from this post https://atari-forum.com/viewtopic.php?p ... 12#p444148

kitune-san
Top Contributor
Posts: 401
Joined: Wed May 18, 2022 11:20 am
Has thanked: 127 times
Been thanked: 412 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by kitune-san »

About the keyboard:
The XT keyboard returns 0xAA when it receives a reset signal.
When the MiSTer core receives the reset pulse from the CPU, it sends 0xFF to the PS/2 keyboard to receive (0xFA)0xAA.
I thought this would be useful for detecting keyboard not connected, but it actually seems to be an annoying feature.
I think changing the keyboard module to monitor the reset pulse and return 0xAA directly when it receives it would solve the problem.

Also, because 4.77 MHz is slow, there was concern that the keyboard would send the next data before the CPU could process the key code.
To avoid this, the core dropped the PS/2 clock line to Low between the time the keycode was received and the time the CPU received it.
In practice, this concern was unnecessary and only interfered with the operation of other cpu monitoring the same PS/2 bus.

About the Clock:
Gyurco is correct.
At the time I joined the MiSTer PCXT project, each module was running on a different clock that was not synchronized.
I proceeded to change several modules to run at the same clock as the chipset, with the exception of video. In doing so, due to my negligence, I created CE signals from the clocks that were in use prior to the change.

However, I think you need to pay attention to the cpu clock.
This signal is monitored on both edges by both the CPU and chipset modules.

somhi
Posts: 88
Joined: Mon Jul 18, 2022 4:37 pm
Has thanked: 25 times
Been thanked: 25 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by somhi »

kitune-san wrote: Thu Mar 09, 2023 3:13 am

About the keyboard:
The XT keyboard returns 0xAA when it receives a reset signal.
When the MiSTer core receives the reset pulse from the CPU, it sends 0xFF to the PS/2 keyboard to receive (0xFA)0xAA.
I thought this would be useful for detecting keyboard not connected, but it actually seems to be an annoying feature.
I think changing the keyboard module to monitor the reset pulse and return 0xAA directly when it receives it would solve the problem.

Also, because 4.77 MHz is slow, there was concern that the keyboard would send the next data before the CPU could process the key code.
To avoid this, the core dropped the PS/2 clock line to Low between the time the keycode was received and the time the CPU received it.
In practice, this concern was unnecessary and only interfered with the operation of other cpu monitoring the same PS/2 bus.

About the Clock:
Gyurco is correct.
At the time I joined the MiSTer PCXT project, each module was running on a different clock that was not synchronized.
I proceeded to change several modules to run at the same clock as the chipset, with the exception of video. In doing so, due to my negligence, I created CE signals from the clocks that were in use prior to the change.

However, I think you need to pay attention to the cpu clock.
This signal is monitored on both edges by both the CPU and chipset modules.

Great, thanks for comments kitune-san.
Gyurco has done some improvements on the MiST port, so now it even can boot with Tandy BIOS.

slingshot2 wrote: Thu Mar 09, 2023 3:13 am

Than the problem must be that the firmware never receives the FF command, so never responds with AA. However it receives strange commands, like FC and FE, which are not really expected. I also think the best would be to generate this first response locally in the core, and don't send commands to the keyboard.

slingshot2 wrote: Thu Mar 09, 2023 3:13 am
somhi wrote: Thu Mar 09, 2023 3:13 am

It's a pity MiST doesn't have more BRAM to enjoy the games that need 4 CGA pages (128 kB). PCXT core is really a BRAM eater! :)

However the SDRAM runs at a really conservative speed (50MHz), thus there are plenty of room expanding it to handle the CGA framebuffer.
And the MDA and CGA framebuffers really need to be merged.

I will try to tackle the last part to use same MDA and CGA framebuffers, if not I'll ask for help.

kitune-san
Top Contributor
Posts: 401
Joined: Wed May 18, 2022 11:20 am
Has thanked: 127 times
Been thanked: 412 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by kitune-san »

kitune-san wrote: Thu Mar 09, 2023 3:13 am

About the keyboard:
The XT keyboard returns 0xAA when it receives a reset signal.
When the MiSTer core receives the reset pulse from the CPU, it sends 0xFF to the PS/2 keyboard to receive (0xFA)0xAA.
I thought this would be useful for detecting keyboard not connected, but it actually seems to be an annoying feature.
I think changing the keyboard module to monitor the reset pulse and return 0xAA directly when it receives it would solve the problem.

For example:
https://github.com/kitune-san/PCXT_DeMi ... 9fa62f72d2

If you have time, please try this.

kitune-san
Top Contributor
Posts: 401
Joined: Wed May 18, 2022 11:20 am
Has thanked: 127 times
Been thanked: 412 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by kitune-san »

My SDRAM(KFSDRAM) module was not intended for use as video RAM or dual port RAM.
It really only provides simple functions. Burst mode and multi-bank are not supported.
Perhaps it would be better to create a new RAM module.
Or, if there is an existing high-speed SDRAM module, it is better to use it.

somhi
Posts: 88
Joined: Mon Jul 18, 2022 4:37 pm
Has thanked: 25 times
Been thanked: 25 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by somhi »

kitune-san wrote: Thu Mar 09, 2023 10:55 am
kitune-san wrote: Thu Mar 09, 2023 3:13 am

About the keyboard:
The XT keyboard returns 0xAA when it receives a reset signal.
When the MiSTer core receives the reset pulse from the CPU, it sends 0xFF to the PS/2 keyboard to receive (0xFA)0xAA.
I thought this would be useful for detecting keyboard not connected, but it actually seems to be an annoying feature.
I think changing the keyboard module to monitor the reset pulse and return 0xAA directly when it receives it would solve the problem.

For example:
https://github.com/kitune-san/PCXT_DeMi ... 9fa62f72d2

If you have time, please try this.

Ok, tested KFPS2KB_direct keyboard with deca port and I don't get any message errors during YUKO STt BIOS start up.

But I'm getting always keyboard controller Failed in the diagnostic BIOSes, while before that change I was passing the test, so not sure If I'm going to implement this modification.

EDIT: same for KFPS2KB tried with deca_MiST port

I need also to keep the following part because of reason explained in comment below.

ksnip_20230309-232039.png
ksnip_20230309-232039.png (44.62 KiB) Viewed 3612 times
somhi
Posts: 88
Joined: Mon Jul 18, 2022 4:37 pm
Has thanked: 25 times
Been thanked: 25 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by somhi »

I'm happy to let you know that I finally managed to boot HD image with a particular geometry using the MiST IDE like Gyurco did.
My image that It was working well with serdrive didn't work, but the freedos image from the mister repository did work.
Gyurco implemented a geometry table in the MiST firmware

somhi
Posts: 88
Joined: Mon Jul 18, 2022 4:37 pm
Has thanked: 25 times
Been thanked: 25 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by somhi »

I will try KFPS2KB_direct also on a MiST port and see what the difference is.

EDIT: Did not work that module with MiST ports as appeared the keyboard controller error anyway

somhi
Posts: 88
Joined: Mon Jul 18, 2022 4:37 pm
Has thanked: 25 times
Been thanked: 25 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by somhi »

https://youtu.be/OSOuhu4ImLg
Testing unified CGA / MDA VRAM memory seems to work quite well.
Now is even possible to change video mode on the fly.

somhi
Posts: 88
Joined: Mon Jul 18, 2022 4:37 pm
Has thanked: 25 times
Been thanked: 25 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by somhi »

Aitor, kitune-san, you might check if following commit by Gyurco is of interest in PCXT MiSTer core also.

https://github.com/somhi/PCXT_DeMiSTify ... 12cd8d5f87

kitune-san
Top Contributor
Posts: 401
Joined: Wed May 18, 2022 11:20 am
Has thanked: 127 times
Been thanked: 412 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by kitune-san »

I'm beginning remember. I think at the time I was only thinking of running it on MiSTer.
The PS/2 module uses 4 signals (ps2_kbd_clk_out, ps2_kbd_clk_in, ps2_kbd_data_out, ps2_kbd_data_in) in MiSTer.
This is different from the actual bidirectional signals.
Perhaps in MiSTer, ps2_x_in does not go low when the ps2_x_out signal is low. (It stays high). (However, I have not confirmed this to be the case.)
This is why it works well on MiSTer (and not on other ports) I think.

So it will not work well if implemented as follows.
assign ps2clk = ps2clkout ? 1'z : 1'b0
assign ps2clk_in = ps2clk
Perhaps KFPS2KB recognizes the wrong clock edge as soon as it completes reception.
This is because the clock is set to LOW after each byte is received.

Anyway, I think it is appropriate to disable ps2_x_out on other ports and output AA from KFPS2KB as I suggested before.

UPDATE:
I checked the code. the above problem does not occur if the clock edge is not entered with ps2data=0.
Since ps2data is not controlled except for transmission, this would not be the cause of the keyboard getting stuck.
I still think we have to look at the waveform to see what is happening.

kitune-san
Top Contributor
Posts: 401
Joined: Wed May 18, 2022 11:20 am
Has thanked: 127 times
Been thanked: 412 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by kitune-san »

The reason for the error in diagnostic BIOS is not clear without seeing the waveform.

Also, if the transfer rate of the PS/2 keyboard is fast and stuck, it is still necessary to drop the clock to low after reception.
Or add a keycode FIFO.

kitune-san
Top Contributor
Posts: 401
Joined: Wed May 18, 2022 11:20 am
Has thanked: 127 times
Been thanked: 412 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by kitune-san »

The keyboard error in the diagnostic BIOS also occurred on my patched MiSTer. (https://github.com/kitune-san/PCXT_DeMi ... 9fa62f72d2)
I will take a look at the waveforms a bit and report back if I can find a countermeasure.

kitune-san
Top Contributor
Posts: 401
Joined: Wed May 18, 2022 11:20 am
Has thanked: 127 times
Been thanked: 412 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by kitune-san »

somhi wrote: Thu Mar 09, 2023 10:22 pm

But I'm getting always keyboard controller Failed in the diagnostic BIOSes, while before that change I was passing the test, so not sure If I'm going to implement this modification.

Fixed.
To sum up, the time between the input of the reset pulse and the generation of the keyboard interrupt was too short.
Prior to the modification, the keyboard interrupt routine was not executed.
Also, some BIOSes clear the interrupt mask and then reset the interrupt confirmation variable.
Since the interrupt occurs before the confirmation variable is reset, it is judged that the interrupt did not occur and an error occurs.
Therefore, a counter for output delay was created.

Please try it. if you have time.
https://github.com/kitune-san/PCXT_DeMi ... 37cd149685

Before:

2023-03-14 221957.png
2023-03-14 221957.png (13.34 KiB) Viewed 3198 times

After:

2023-03-15 000841.png
2023-03-15 000841.png (14.04 KiB) Viewed 3198 times
2023-03-15 000905.png
2023-03-15 000905.png (11.36 KiB) Viewed 3198 times
2023-03-15 000949.png
2023-03-15 000949.png (14.54 KiB) Viewed 3198 times
somhi
Posts: 88
Joined: Mon Jul 18, 2022 4:37 pm
Has thanked: 25 times
Been thanked: 25 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by somhi »

kitune-san wrote: Tue Mar 14, 2023 3:01 pm

Please try it. if you have time.
https://github.com/kitune-san/PCXT_DeMi ... 37cd149685

Thanks! That is working perfectly fine either in Deca or Deca_MiST ports.
I've updated the devel branch with it and cleaned redundant code also.
I still have KFPS2KB and KFPS2KB_direct which maybe could be merged in one. You did the KFPS2KB_direct modifications, and don't remember well if it was also for the very same reason of removing the keyboard error. If it's that the case, I could only use KFPS2KB. I'm going to try it.

EDIT1: I'm trying just the KFPS2KB for deMiSTify ports and seems to be working as well as KFPS2KB_direct.

EDIT2: kitune-san, don't remember also if the repetition of keys with a keypress was solved by your side or by DeMiSTify side. I would like to remove it to check if that is causing more problems with the keyboard, although with the latest changes it seems to be working better.
MiST ports doesn't have repetition and keyboard do seem to work better.

kitune-san
Top Contributor
Posts: 401
Joined: Wed May 18, 2022 11:20 am
Has thanked: 127 times
Been thanked: 412 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by kitune-san »

keyboard repetition...
I do not remember what it was. Sorry.

I'm busy today and tomorrow, so I may not be able to reply.

somhi
Posts: 88
Joined: Mon Jul 18, 2022 4:37 pm
Has thanked: 25 times
Been thanked: 25 times

Re: Extend PCXT Development to Improve MiSTer Core (DeMiSTify Ports)

Unread post by somhi »

kitune-san wrote: Tue Mar 14, 2023 11:37 pm

keyboard repetition...
I do not remember what it was. Sorry.

I'm busy today and tomorrow, so I may not be able to reply.

When you press a key for long time, eg "b", with MiST framework, it only prints one "b" in the screen.
With keyboard attached directly to the core (demistified ports), it prints lots of "bbbbbbbbb". That is what I referred as keys repetition.
After some time pressing I can hear a beep, so maybe keyboard buffer if there is one is full I guess. It depends on the timings of the core, I can hear more or less beeps during the same time, and some keys are lost if typewriting fast.

Don't know how it works on MiSTer. I was guessing that maybe removing the keys repetition, It could improve the performance of the typewriting.

Post Reply