MiSTer PCXT

[Mills]

I have solved the sound problem, using the cpu_clock signal instead of the clock of the sound modules, as it runs at 100Mhz, so it sounds pitched.With these changes, I have updated the prebeta 1.3 branch:

https://github.com/spark2k06/PCXT_MiSTe ... e_beta_1_3

I attach here the binary of this prebeta so that the rest of the users can test it.

On the other hand, apart from some applications and games that we know crash, there is another crash point to investigate, and it is here (application CheckIt 3.0):

protected_mode.png

@kitune-san just made a pull request for the prebeta 1.3 making use of the 100Mhz sound modules as well, but getting the signal from cen_opl2 properly. I have tested it and it works fine. I have accepted the changes, I attach here the corresponding RBF file:

It sounds OK, some OPL2 tests

pcxt_opl2.7z

(10.51 MiB) Downloaded 184 times

(a bit of noise produced by a cheap cable I used to connect to my computer).

[kitune-san]

I speeded up access to SDRAM.
I changed it so that wait state does not occur on SDRAM access except during refresh.

It is still in the testing phase.There may be SDRAMs that do not work well.

https://github.com/kitune-san/PCXT_MiST ... cess_speed

PCXT.zip

(973.34 KiB) Downloaded 161 times

[breiztiger]

with your mod kitune-san core seem to be more as real pc xt speed (0.79 vs 1.02 in checkit 3.0 main system benchmark)

[Mills]

I speeded up access to SDRAM.
I changed it so that wait state does not occur on SDRAM access except during refresh.

It is still in the testing phase.There may be SDRAMs that do not work well.

https://github.com/kitune-san/PCXT_MiST ... cess_speed

PCXT.zip

Nice, works much better.
8088mph demo reports only a 6% deviation from a real 8088 4.77, also the demo reaches the final part and it plays the MOD file correctly .

[MicroCoreLabs]

Thanks for the quick update. Now, the most important thing left is the turbo mode (7.16Mhz). "prince of persia" is too slow.

This should be fun!

As I mentioned before, to run the BIU at anything other than 4.77 Mhz will require some updating to make it sensitive to the bus clock. Currently it only looks at a single 4.77 Mhz clock edge and then paces the rest of the activity using 100 Mhz clocks. This is a simple update, but you will get much more impressive results in other ways.

First of all it is easy to disable the MCL86 clock accuracy with just one line of Verilog which can provide a performance improvement in the 20% range.

But the big speed improvements come when the four-cycle BIU state machine is bypassed when accessing RAM and ROM. The most recent time I did this was on the MCL86jr which uses an SRAM external to the FPGA running at 100Mhz. I dont think I was mirroring the BIOS ROMs and was able to achieve a 4X speed improvement which would be close to a 20 Mhz PCXT equivalent. If you mirrored the BIOS ROM it would be even faster.

There is also no reason the MCL86 cannot be run at greater than 100Mhz. This was a convenient speed which the Xilinx Spartan-6 was able to achieve and was used to count clock cycles to achieve cycle accuracy. If you did not need cycle accuracy you could run as fast as the FPGA technology allows and get even more performance.

Here's the PCjr experiment. It is the same MCL86 core and microcode using a minimum-mode BIU. 512 KB of SRAM is also attached to the FPGA.

https://microcorelabs.wordpress.com/202 ... test-pcjr/

[spark2k06]

I speeded up access to SDRAM.
I changed it so that wait state does not occur on SDRAM access except during refresh.

It is still in the testing phase.There may be SDRAMs that do not work well.

https://github.com/kitune-san/PCXT_MiST ... cess_speed

PCXT.zip

As far as I have been able to test, it works well... so I copy it to the prebeta 1.3 branch:

https://github.com/spark2k06/PCXT_MiSTe ... e_beta_1_3

Users can test the same binary you have shared.

On the other hand, apart from some applications and games that we know crash, there is another crash point to investigate, and it is here (application CheckIt 3.0):

protected_mode.png

I have discovered that the culprit of the CheckIT application crashing at this point is none other than the use of the UMB!SYS driver for the UMB memory, so I won't use it for the moment, until I find out the cause, I will try driver options or other older versions... now it makes sense that the DOSMAX application crashed, everything can be related.

Thanks for the quick update. Now, the most important thing left is the turbo mode (7.16Mhz). "prince of persia" is too slow.

This should be fun!

As I mentioned before, to run the BIU at anything other than 4.77 Mhz will require some updating to make it sensitive to the bus clock. Currently it only looks at a single 4.77 Mhz clock edge and then paces the rest of the activity using 100 Mhz clocks. This is a simple update, but you will get much more impressive results in other ways.

I think it is not yet the time to spend time on this, there is still room for improvement to achieve the exact cycle of an original PCXT in this core... the first objective of this core.

Turbo modes or higher frequencies might be interesting in the future, but right now it doesn't make so much sense, having the ao486 core that offers just that, and with VGA gaming modes... more in line with the requirements of games that need higher speed.

[kitune-san]

- Changed so that read/write commands during SDRAM refresh do not generate wait state.
- Fixed a bug in KF8237.
- Wired between Timer 1 output and DMA0 request.

These changes would be able to run the original PCXT BIOS.

https://github.com/kitune-san/PCXT_MiST ... am_and_dma

PCXT.zip

(971.94 KiB) Downloaded 130 times

[spark2k06]

- Changed so that read/write commands during SDRAM refresh do not generate wait state.
- Fixed a bug in KF8237.
- Wired between Timer 1 output and DMA0 request.

These changes would be able to run the original PCXT BIOS.

https://github.com/kitune-san/PCXT_MiST ... am_and_dma

PCXT.zip

Thanks for the update, I have tested it and it works fine, I have uploaded the changes to the prebeta 1.3 branch:

https://github.com/spark2k06/PCXT_MiSTe ... e_beta_1_3

Now the original IBM5160 BIOS does indeed work. Moreover, it seems that this BIOS makes the benchmark used by the 8088MPH demo even closer to what is considered a real PCXT at 4.77Mhz:

8088mph_3_percent.jpg (129.38 KiB) Viewed 4711 times

And CheckIt shows almost similar results to a PCXT at 4.77Mhz, although it is curious that it identifies 4.56Mhz:

checkit.jpg (113.52 KiB) Viewed 4711 times

The IBM5160 BIOS requires the entire F000h segment to work, so XTIDE must be moved. I have taken the opportunity to update the core to be able to load it in the EC00h segment, so that anyone can use it. For this purpose, I have also prepared a new IBM5160 BIOS downloader, it is all available in the prebeta 1.3 branch.

I attach in this post the RBF binary with these changes.

[wark91]

Great improvements !!!

[spark2k06]

I forgot to mention that the IBM 5160 BIOS has some incompatibility with the keyboard. It works, but if you press SHIFT to print a character, it seems to stay permanently pressed... this doesn't happen in the other BIOSes.

[breiztiger]

the caps key prob is already present with other bios and previous build (for me at least ...)

[spark2k06]

the caps key prob is already present with other bios and previous build (for me at least ...)

The problem I identified in the rest, and only using KEYB, is with the AltGr key... no problems with SHIFT for other BIOSes in my case.

edit: correction, also with SHIFT... but only if keyb or keyb /e is used for others BIOSes.

[kitune-san]

I forgot to mention that the IBM 5160 BIOS has some incompatibility with the keyboard. It works, but if you press SHIFT to print a character, it seems to stay permanently pressed... this doesn't happen in the other BIOSes.

Please try an older version (e.g. Image of 11/08/82 revision).

[remax]

Please try an older version (e.g. Image of 11/08/82 revision).

Seems OK for me. Same results under checkit than with the other 5160 bios.

Metric cycle count of 1616 -> 4% deviation under 8088MPH

[spark2k06]

Please try an older version (e.g. Image of 11/08/82 revision).

Seems OK for me. Same results under checkit than with the other 5160 bios.

I haven't had a chance to test it yet, but I guess it will happen like with the rest of BIOS, from using KEYB it will stop working properly.

Can you check it?

[remax]

I haven't had a chance to test it yet, but I guess it will happen like with the rest of BIOS, from using KEYB it will stop working properly.

Can you check it?

With Keyb FR

It feels likes CAPS LOCK works ok, but shift has no impact on the capitalization.

ALT GR seems to screw everything up (perhaps it stays ON)... So yeah, i guess we can say it's not woking properly.

[spark2k06]

With Keyb FR

It feels likes CAPS LOCK works ok, but shift has no impact on the capitalization.

ALT GR seems to screw everything up (perhaps it stays ON)... So yeah, i guess we can say it's not woking properly.

OK, so that's what I expected, in a nutshell:

• IBM5160 BIOS from '82, Sergey's and Juko ST's work fine initially.
• latest revision of IBM5160, or any other from the use of KEYB, no longer works fine when pressing SHIFT or AltGr

[remax]

For those wanting a KEYB FR equivalent : look here : http://www.win3x.org/win3board/viewtopic.php?t=718

This driver has his caveats but at least it works.

[Mills]

Please try an older version (e.g. Image of 11/08/82 revision).

Seems OK for me. Same results under checkit than with the other 5160 bios.

Metric cycle count of 1616 -> 4% deviation under 8088MPH

I got 3% with otiginal bios, and 7% using juko's.

I tried the ibm basic and my keyboard does not work there, I'll test another one with cable and see if it works.

EDIT: Looks like I have the caps lock problem, I was trying to use quotations with my spanish keyboard and it also failed.

[remax]

I got 3% with otiginal bios, and 7% using juko's.

I tried the ibm basic and my keyboard does not work there, I'll test another one with cable and see if it works.

Which "original" bios ?

The "09MAY86" ? (this one has keyboard problems and a 3% speed deviation)

The "08NOV82" ? (this one seems to works fine with a 4% speed deviation)

Another one ?

[Mills]

I got 3% with otiginal bios, and 7% using juko's.

I tried the ibm basic and my keyboard does not work there, I'll test another one with cable and see if it works.

Which "original" bios ?

The "09MAY86" ? (this one has keyboard problems and a 3% speed deviation)

The "08NOV82" ? (this one seems to works fine with a 4% speed deviation)

Another one ?

The one generated with the python script in the github repository.

[remax]

Use this one :

Code: Select all

import os
import glob
import zipfile
import requests

URL = "http://www.minuszerodegrees.net/bios/BIOS_5160_08NOV82.zip"
response = requests.get(URL)
open("ibm5160.zip", "wb").write(response.content)

with zipfile.ZipFile("ibm5160.zip", 'r') as zip_ref:
    zip_ref.extractall()

try:
    os.remove("ibm5160.zip")
except:
    print("Error while deleting file : ibm5160.zip")

rom_filename = "boot.rom"
ibm5160_basename = "BIOS_5160_08NOV82_"

with open(rom_filename, "wb") as romf, open(ibm5160_basename + "U19_5000027_27256.bin", "rb") as f:
     romf.write(f.read())

with open(rom_filename, "ab") as romf, open(ibm5160_basename + "U18_1501512.bin", "rb") as f:
     romf.write(f.read())

fileList = glob.glob(ibm5160_basename + "*.bin")

for filePath in fileList:
    try:
        os.remove(filePath)
    except:
        print("Error while deleting file : ", filePath)
        

    

[spark2k06]

@jordi has contributed to the update of the script, now you get it from the '82 revision:

https://github.com/spark2k06/PCXT_MiSTe ... e_beta_1_3

On the other hand, on a curious note... I see that CheckIT gives better results than 86Box (PCEM), which is more accurate:

checkit.png (23.98 KiB) Viewed 4380 times

However, 86Box has no performance deviations in the 8088MPH demo... perhaps an ad hoc adaptation of 86Box to make this demo work?

[remax]

I wonder something : Is the 5160 is really supposed to match 1:1 with a 5150 speedwise ?

EDIT : Seems so ; We're aiming to 350 Dhrystones and 6,7 for Math

https://mastodonpc.tripod.com/bench/checkit.html

[wark91]

After some tests, I found one game Commander Keen 4 (CGA version) raised a divider issue at the start of the game.
20220624_084649-screen.png

I tried the same HDD on PCEM and it can goes in game:
Screenshot from 2022-06-24 08-57-50.png

Thanks.

For information, I tried "Commander Keen 4 (CGA version)" again with this rbf : PCXT_PREBETA_1_3_03.rbf
It is working with the bios "IBM-XT-5160-01-10-86.rom"
but the issue above remains with the bios "JUKO-ST-v2.30.rom"

[remax]

I had no problem with both bios with commander Keen 4

[wark91]

Ok maybe my JUKO ST rom is not ok. I will check thank you !

[flynnsbit]

I had no problem with both bios with commander Keen 4

What DOS OS are you using as your default?

Loading both UMB and LTEMM?

[remax]

msdos 6.22uk

I use LTEMM but have disabled UMB.

Code: Select all

     Nom: CGAGRAPH.CK4
  CRC-32: dfb947bb

     Nom: GAMEMAPS.CK4
  CRC-32: e553f51f

     Nom: KEEN4C.EXE
  CRC-32: d93fe496

     Nom: AUDIO.CK4
  CRC-32: 4ac87d4a

(but honnestly i find JukoST bios far behind in term of compatibility at this point)

[flynnsbit]

Juko is fast for sure. I have a somewhat solid setup with DOS 5, 4DOS as the command shell loading into emm, FREESP, UMB+LTEMM, MyMenu and I just transferred about 100 games to it. I am slowly working through testing but I am still running into Drive C disk errors that force me to restart the core. simple things like editing config.sys or autoexec.bat can cause a general failure reading drive c.

I've been debugging serdrive and I can see some crc errors but I can't figure out if it is me or the core. I moved all my setup local instead of over the network and that helped a bit.

Are any of you having stability issues with the disk still? "General failure writing drive C. Abort, Retry, Ignore, Fail?"

It seems to only happen when I use an app that needs to swap to memory with LTEMM loaded, but I am not positive on that yet.