kitune-san wrote: ↑Mon Mar 06, 2023 2:21 pmIs 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.
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
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.
kitune-san wrote: ↑Mon Mar 06, 2023 2:21 pmIs 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):
cylinder = {tfr[5], tfr[4]} = 0h
dev_head = tfr[6] = A0h
sector = tfr[3] = 01h
Output corresponding to write_sector_count stp (address 302):
Output corresponding to write_sector_number stp (address 303):
Output corresponding to write_cylinder_low stp (address 304):
Output corresponding to write_cylinder_high stp (address 305):
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
kitune-san wrote: ↑Mon Mar 06, 2023 10:12 pmRAW 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
It really does have H=2...
we need to look into what is writing this.(bios or mist system)
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
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
kitune-san wrote: ↑Mon Mar 06, 2023 11:49 pmThe 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.
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:
some updates, OS already booting, but freezing thereafter.
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.
kitune-san wrote: ↑Tue Mar 07, 2023 10:10 pmMiSTerPCXT 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.
some updates from this post https://atari-forum.com/viewtopic.php?p ... 12#p444148
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.
kitune-san wrote: ↑Thu Mar 09, 2023 3:13 amAbout 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 amThan 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 amHowever 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 wrote: ↑Thu Mar 09, 2023 3:13 amAbout 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.
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.
kitune-san wrote: ↑Thu Mar 09, 2023 10:55 amkitune-san wrote: ↑Thu Mar 09, 2023 3:13 amAbout 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 ... 9fa62f72d2If 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.
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
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
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.
Aitor, kitune-san, you might check if following commit by Gyurco is of interest in PCXT MiSTer core also.
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.
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.
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.
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:
After:
kitune-san wrote: ↑Tue Mar 14, 2023 3:01 pmPlease 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.
keyboard repetition...
I do not remember what it was. Sorry.
I'm busy today and tomorrow, so I may not be able to reply.
kitune-san wrote: ↑Tue Mar 14, 2023 11:37 pmkeyboard 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.
