MiSTer PCXT

[kitune-san]

I added keybord reset logic.
With this change, the keyboard controller test would pass.

I have sent you a pull request.
Please try it.

Sorry. 8088 BIOS does not seem to accept keyboard...
Please give me a little more time.

[spark2k06]

I added keybord reset logic.
With this change, the keyboard controller test would pass.

I have sent you a pull request.
Please try it.

Sorry. 8088 BIOS does not seem to accept keyboard...
Please give me a little more time.

Don't worry, take as much time as you need. As BIOS, you can try the original IBM 8560 or the Juko ST clone, both showed the keyboard error. I have not yet been able to test this pull request.

[spark2k06]

The BIOS of the IBM 5160 does accept the keyboard with this fix, it no longer shows error 301, which is the one related to the keyboard... it only shows error 101:

IBM_5160_Code_101.jpg (65.36 KiB) Viewed 5071 times

Some possible 101 causes:
• Motherboard's 8259 interrupt controller chip (includes supporting chips).
• Motherboard's 8253 timer chip (includes supporting chips).
• Motherboard's 8237 DMA controller chip (includes supporting chips).

http://minuszerodegrees.net/5160/post/5 ... errors.htm

JUKO ST BIOS does not show keyboard errors now either, I accept pull request.

The next big challenge is to get the SDRAM working, so that the 640Kb of main memory is available for testing larger games

[MicroCoreLabs]

The next big challenge is to get the SDRAM working, so that the 640Kb of main memory is available for testing larger games

You will get some nice acceleration if you provide the option to bypass the cycle-accurate BIU and access block-ram located BIOS ROMs and SDRAM at full-speed.

[spark2k06]

You will get some nice acceleration if you provide the option to bypass the cycle-accurate BIU and access block-ram located BIOS ROMs and SDRAM at full-speed.

Yes, I'd leave that for the last step of all... optionally enabling turbo mode at the maximum provided by the MCL86.

[spark2k06]

I just updated this branch from the main branch, keeping SDRAM enabled:

https://github.com/spark2k06/PCXT_MiSTe ... sdram-test

And this is what happens when you pass the tests of ruud:

ruud test sdram 01.jpg (86.44 KiB) Viewed 4932 times

I have even seen it go up to 14Kb. However, every test is different, I've also seen it go as low as 2Kb before displaying the error.

[MicroCoreLabs]

Does your SDRAM controller have exclusive access to the physical SDRAM or does it share it with the SOC-CPU? If it is sharing, then when there are conflicts then you may need to assert wait-states back to the BIU. It would be better if the SDRAM access was exclusive to the MCL86, otherwise it may be difficult to be consistently cycle accurate if there is a CPU which can delay the BIU's accesses and cause wait states.

On the other hand, if the SDRAM is fast enough, it may be transparent to the 4.77Mhz BIU!

[spark2k06]

Does your SDRAM controller have exclusive access to the physical SDRAM or does it share it with the SOC-CPU? If it is sharing, then when there are conflicts then you may need to assert wait-states back to the BIU. It would be better if the SDRAM access was exclusive to the MCL86, otherwise it may be difficult to be consistently cycle accurate if there is a CPU which can delay the BIU's accesses and cause wait states.

On the other hand, if the SDRAM is fast enough, it may be transparent to the 4.77Mhz BIU!

SDRAM is independent of the MiSTer SOC CPU

[wark91]

Is someone have the steps to produce the bios of JUKO ST.

On Mame, the file is just 8Kb but the core required 64Kb for the bios file.
ROM_START( juko8 )
ROM_REGION(0x10000, "bios", 0)
// 0: BIOS ver 2.00 VEGAS COMPUTER COMMUNICATIONS.
ROM_SYSTEM_BIOS(0, "nestv200", "JUKO NEST v2.00")
ROMX_LOAD( "jukoa.bin", 0xe000, 0x2000, CRC(7d78707e) SHA1(8b09a32658a850e7f03254d1328fe6e336e91871),ROM_BIOS(0))
// 1: Flytek (Protek) ST-12 (a 15MHz ST-15 was also available)
ROM_SYSTEM_BIOS(1, "st-12", "ST-12")
ROMX_LOAD( "flytek_st-12_bios_ver_2.20_c_nel_electronics_ltd.bin", 0xe000, 0x2000, CRC(448c3089) SHA1(779d4138d841783d0e2e5ad29c83d9a8cb4497b6), ROM_BIOS(1))
// 2: Juko ST BIOS ver 2.30 / Copyright 1988 Juko Electronics Industrial Co., Ltd.
ROM_SYSTEM_BIOS(2, "nest230", "JUKO NEST v2.30")
ROMX_LOAD( "juko_st_v2.30.bin", 0xe000, 0x2000, CRC(7a1c6dfa) SHA1(0b343f3028ca06c9e6dc69427d1b15a47c74b9fc),ROM_BIOS(2))
// 3: BIOS Ver 2.32
ROM_SYSTEM_BIOS(3, "nest232", "JUKO NEST v2.32")
ROMX_LOAD( "xt-juko-st-2.32.bin", 0xe000, 0x2000, CRC(0768524e) SHA1(259520bb7a6796e5b987c2b9bef1acd501df1670),ROM_BIOS(3))
ROM_END

I managed to do it for 5160 because it is just two files of 32Kb to merge.

Thanks !

[kitune-san]

It's speculation because I don't know the details of that BIOS.
Program will not work if there is no data at entry address FFFF0.
Perhaps it works if you fill the first 56k of the file with zeros and merge the ROM file into the remaining 8k.

..Or merge ROM files 8 times.
$ cat 8k_bios > boot.rom
$ cat 8k_bios >> boot.rom
$ cat 8k_bios >> boot.rom
$ cat 8k_bios >> boot.rom
$ cat 8k_bios >> boot.rom
$ cat 8k_bios >> boot.rom
$ cat 8k_bios >> boot.rom
$ cat 8k_bios >> boot.rom

[spark2k06]

Exactly, that's the right thing to do, as I suggested in a previous post:

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.

[spark2k06]

..Or merge ROM files 8 times.
$ cat 8k_bios > boot.rom
$ cat 8k_bios >> boot.rom
$ cat 8k_bios >> boot.rom
$ cat 8k_bios >> boot.rom
$ cat 8k_bios >> boot.rom
$ cat 8k_bios >> boot.rom
$ cat 8k_bios >> boot.rom
$ cat 8k_bios >> boot.rom

For Windows CMD:

Code: Select all

copy /y /b 8k_bios+8k_bios+8k_bios+8k_bios+8k_bios+8k_bios+8k_bios+8k_bios boot.rom

[wark91]

Thank you both !
I missed that post !

[Akuma]

..Or merge ROM files 8 times.
$ cat 8k_bios > boot.rom
$ cat 8k_bios >> boot.rom
$ cat 8k_bios >> boot.rom
$ cat 8k_bios >> boot.rom
$ cat 8k_bios >> boot.rom
$ cat 8k_bios >> boot.rom
$ cat 8k_bios >> boot.rom
$ cat 8k_bios >> boot.rom

For Windows CMD:

Code: Select all

copy /y /b 8k_bios+8k_bios+8k_bios+8k_bios+8k_bios+8k_bios+8k_bios+8k_bios boot.rom

For Linux:

Code: Select all

cat 8k_bios 8k_bios 8k_bios 8k_bios 8k_bios 8k_bios 8k_bios 8k_bios > boot.rom

or

Code: Select all

cat 8k_bios$notexistvar{1..8} > boot.rom

[kitune-san]

I added keybord reset logic.
With this change, the keyboard controller test would pass.

I have sent you a pull request.
Please try it.

Sorry. 8088 BIOS does not seem to accept keyboard...
Please give me a little more time.

I found the cause.
The reason is that 8088bios disables the interrupt mask after keyboard reset.
With the previous fix for 8259, interrupt edges during masking are not accepted. (Meaning that no interrupts are accepted after the mask is unmasked.)
The modification of the keyboard controller this time is such that 0xAA is received from the keyboard after the keyboard reset pulse（port_b[6]) is output.

As a result, interrupts from the keyboard are received before the mask is unmasked.
Then, since interrupts are not accepted, the system enters a deadlock state in which no data is received from the keyboard thereafter.

[kitune-san]

As a countermeasure, I am considering the following
- No forced LOW of clock by IRQ
- If the next data is received before the interrupt is released, temporarily set the IRQ signal LOW. (At this time, the scan code is 0xFF.)

EDIT:
I will try to fix 8259 module.

[spark2k06]

As a countermeasure, I am considering the following
- No forced LOW of clock by IRQ
- If the next data is received before the interrupt is released, temporarily set the IRQ signal LOW. (At this time, the scan code is 0xFF.)

EDIT:
I will try to fix 8259 module.

I have tested the pull request you created:

https://github.com/spark2k06/PCXT_MiSTer/pull/8

Overall kernel performance is similar, IBM 5160 BIOS error 101 still occurs... but the downside is that the interrupt level 0 error in the SuperSoft test ROM has returned with this patch.

[spark2k06]

I have tested the pull request you created:

https://github.com/spark2k06/PCXT_MiSTer/pull/8

Overall kernel performance is similar, IBM 5160 BIOS error 101 still occurs... but the downside is that the interrupt level 0 error in the SuperSoft test ROM has returned with this patch.

On the other hand, the one that causes the problems with Interrupt Level 0 in the SuperSoft test is the one called "Fixed 8259 interrupt request logic", the other commit also passes the tests.

I see that you are focusing on the performance of the ROM that I have left set by default, that of a clone of 8088 PCXT of Sergey Kiselev, I keep it because it is Open Source, but it may have its bugs or incompatibilities with this core. In fact, one thing I have noticed with this BIOS is that the execution of the DIR command has a quite slow scroll, compared for example with the consolidated Juko ST BIOS, which is the one I am starting to use for all the tests.

In fact, this BIOS doesn't have any problems with the keyboard, like Sergey's 8088 ROM does. Besides, with the last changes you made, it doesn't show any keyboard error, and the original IBM 5160 BIOS doesn't show 301 code either, so, in this sense I think we could consider the keyboard problem solved, and I could accept the commit "Fixed interrupt_to_cpu to be set back to LOW when interrupt request disappears" if you consider it convenient.

I assume Sergey's 8088 BIOS has some "bugs" that might require future revision to make it compatible with this core.

[spark2k06]

In summary, the ROMs we should use for core development are:

- SuperSoft tests
- Ruud tests
- IBM 5150/5160 BIOS
- Juko ST BIOS

And finally, in the future, adapt and improve the Sergey's 8088 BIOS, since it is OpenSource and is the current candidate to be kept on GitHub.

[spark2k06]

beta 0.9

• 640Kb main memory with SRAM, until SDRAM is available... but perfect for porting to other FPGA

I have created a SRAM branch with this core version, it is only possible to use it with the dual memory addon 32Mb SDRAM and 2 Mb SRAM:

https://github.com/spark2k06/PCXT_MiSTer/tree/sram

SDRAM_SRAM_DUAL.png (264.75 KiB) Viewed 4025 times

[MicroCoreLabs]

With 640KB the 8088 MPH Demo should be able to run to completion. The music at the end uses the prefetch queue extensively, so it's a good test of the BIU.

[held]

With 640KB the 8088 MPH Demo should be able to run to completion. The music at the end uses the prefetch queue extensively, so it's a good test of the BIU.

[kitune-san]

@spark2k06
The problem with SDRAM not working is caused by the lack of timing constraints.
In my environment, it works fine by adding the following to PCXT.sdc.

Code: Select all

# core specific constraints
set_input_delay -clock { FPGA_CLK2_50 } -max 6 [get_ports { SDRAM_DQ[*] }]
set_input_delay -clock { FPGA_CLK2_50 } -min 3 [get_ports { SDRAM_DQ[*] }]
set_output_delay -clock { FPGA_CLK2_50 } -max 2 [get_ports { SDRAM_DQ[*] SDRAM_DQM* SDRAM_A[*] SDRAM_n*  SDRAM_BA SDRAM_CLK }]
set_output_delay -clock { FPGA_CLK2_50 } -min 0 [get_ports { SDRAM_DQ[*] SDRAM_DQM* SDRAM_A[*] SDRAM_n*  SDRAM_BA SDRAM_CLK }]

[kitune-san]

@spark2k06
The problem with SDRAM not working is caused by the lack of timing constraints.
In my environment, it works fine by adding the following to PCXT.sdc.

Code: Select all

# core specific constraints
set_input_delay -clock { FPGA_CLK2_50 } -max 6 [get_ports { SDRAM_DQ[*] }]
set_input_delay -clock { FPGA_CLK2_50 } -min 3 [get_ports { SDRAM_DQ[*] }]
set_output_delay -clock { FPGA_CLK2_50 } -max 2 [get_ports { SDRAM_DQ[*] SDRAM_DQM* SDRAM_A[*] SDRAM_n*  SDRAM_BA SDRAM_CLK }]
set_output_delay -clock { FPGA_CLK2_50 } -min 0 [get_ports { SDRAM_DQ[*] SDRAM_DQM* SDRAM_A[*] SDRAM_n*  SDRAM_BA SDRAM_CLK }]

Humm... I disabled signaltap and it no longer passes.

[kitune-san]

Humm... I rebased the commit and disabled signaltap and it stopped working.

[kitune-san]

In the latest commit, the PCXT.sdc file appears to have been removed from the project.
I added the PCXT.sdc file to the project again and confirmed that SDRAM works.

2022-06-18 123540.png (15.7 KiB) Viewed 3744 times

[dmckean]

Another fantastic milestone!

Now we just need either floppy or IDE support so those of us without COM adapters can play along at home.

[spark2k06]

In the latest commit, the PCXT.sdc file appears to have been removed from the project.
I added the PCXT.sdc file to the project again and confirmed that SDRAM works.

2022-06-18 123540.png

I have synthesised with the latest changes to the branch you have created:

https://github.com/kitune-san/PCXT_MiST ... /add-sdram

It does not seem to be working properly:

SDRAM_01.jpg (82.05 KiB) Viewed 3720 times

If you have a working version, can you update this branch with the changes, or... can you provide the synthesised .rbf file here for me to test?

[thorr]

Now we just need either floppy or IDE support so those of us without COM adapters can play along at home.

I am not sure if IDE would even work with this. Back then, the drives were RLL or MFM from what I recall.

[spark2k06]

With 640KB the 8088 MPH Demo should be able to run to completion. The music at the end uses the prefetch queue extensively, so it's a good test of the BIU.

It turns out that at some point it stopped working as "well" as it used to. It used to go further but now, even with 640Kb of RAM, it stays in this part of the demo, in a loop:



This is the current mismatch with a real 8088, according to the demo benchmark itself:

8088mph_01.jpg (123.04 KiB) Viewed 3711 times

However, the demo not working properly at the moment is the least of the problems, in the end everything can be related, but I prefer that little by little we solve other aspects such as IDE and SDRAM support properly, so that it can start to be used by more users.