MiSTer PCXT

[breiztiger]

why floppy is mount in b: drive ?

i have to type B at xt ide scrren to boot B: drive with a booter game ...

[spark2k06]

why floppy is mount in b: drive ?

i have to type B at xt ide scrren to boot B: drive with a booter game ...

README updated:

https://github.com/spark2k06/PCXT_MiSTe ... /README.md

[kitune-san]

@spark2k06

I sent a pull request.

The signal that should have been declared reg (or logic) was declared wire.
This change seems to have improved the "16 / 256 colors" effect display on the 8088MPH.

[spark2k06]

Release 20220818

• Fix wire-declared registers.
• ce_pix fixed to 1'b1 in video_monochrome_converter, by @somhi
• Fix SDRAM input_delay mistake.

https://github.com/spark2k06/PCXT_MiSTe ... n/releases

Other news

This repository will soon become part of MiSTer-devel, as soon as the MiSTer Main release is published. There will no longer be a prebeta branch, it will be replaced by the prerelease branch... for the time being, new pull requests will be made on the usual repository:

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

As soon as it is published in MiSTer_devel, it will be next:

https://github.com/MiSTer-devel/PCXT_Mi ... prerelease

[breiztiger]

with last build from 0818 8088mph crash at this screen with persitant bip

20220819_095544-screen.png (12.85 KiB) Viewed 9223 times

and have 1% at start of the demo (before exact xt speed)

[spark2k06]

with last build from 0818 8088mph crash at this screen with persitant bip
20220819_095544-screen.png
and have 1% at start of the demo (before exact xt speed)

It is variable, sometimes it says exact xt, sometimes 1%.

[spark2k06]

@MicroCoreLabs, I want to try to investigate why the DOSMAX driver crashes on this core, but first, I would like to make sure that it has nothing to do with MCL86. The configuration of the CONFIG.SYS file I have is as follows:

Code: Select all

FILES=30
DOS=HIGH,UMB
DEVICE=C:\USE!UMB.SYS D000-E000
DEVICE=C:\DOSMAX\DOSMAX.EXE /R+ /N+ /P-
SHELL=C:\DOSMAX\SHELLMAX.COM C:\COMMAND.COM C:\ /E:256 /P

The crash occurs on line 4. Can you confirm that this problem does not occur on a real PC with MCL86?

DOSMAX, together with USE!UMB.SYS, can be downloaded from here:

https://github.com/monotech/NuXT/blob/m ... DOSMAX.zip

I have carried out a more detailed analysis of this problem debugging this driver, and have come to the following conclusion:

SSSI_TO_ESDI.png (14 KiB) Viewed 9198 times

It seems that this instruction is not working properly. I don't know if it is a problem with MCL86 or with the core. Below I send a screenshot of PCXT in MiSTer and another one of PCEm (on a real 8088 machine it also happens):

MiSTer_SSSI_TO_ESDI.png (350.82 KiB) Viewed 9198 times

PCEM_SSSI_TO_ESDI.png (11.08 KiB) Viewed 9198 times

I have checked, that if we use DS:SI instead of SS:SI, the operation is correct in MiSTer.

I have created two executables, one using SS as the source and the other using DS as the source. The first one reproduces the problem mentioned in the core, and returns an ERROR message, when on an emulator or a real PC it doesn't happen and shows OK. The other one returns OK in both environments.

@MicroCoreLabs, can you try these tests with MCL86 on a real PC? If it works fine, @kitune-san, can you try it and see if you can find out why it malfunctions with the core?

[suww37]

"kings of the beach" game on "Tandy 1000" gives "packed file error". If I run it in cga mode, it runs normally and I can hear a tandy sound. I want to know what is the cause. The game "Death track" has broken graphics and freezes. On real XT pc, these two games work fine. please check.

[wark91]

You could add them in this list below with some screenshot
It will help tracks issues or compatibility.
https://docs.google.com/spreadsheets/d/ ... 1426632805

[suww37]

You could add them in this list below with some screenshot
It will help tracks issues or compatibility.
https://docs.google.com/spreadsheets/d/ ... 1426632805

I know. However, both games performed well on the previous core.

[spark2k06]

Also be careful where you download them from, sometimes they are modified and only work for 186 (NEC v20) or higher.

[wark91]

You could add them in this list below with some screenshot
It will help tracks issues or compatibility.
https://docs.google.com/spreadsheets/d/ ... 1426632805

I know. However, both games performed well on the previous core.

You can mention it there is some regression since this version with a screenshot of both versions

[pgimeno]

"kings of the beach" game on "Tandy 1000" gives "packed file error".

Does it really say "packed file error" or does it say "Packed file is corrupt"? The difference is important.

[pgimeno]

...

@MicroCoreLabs, I want to try to investigate why the DOSMAX driver crashes on this core, but first, I would like to make sure that it has nothing to do with MCL86. The configuration of the CONFIG.SYS file I have is as follows:

Code: Select all

FILES=30
DOS=HIGH,UMB
DEVICE=C:\USE!UMB.SYS D000-E000
DEVICE=C:\DOSMAX\DOSMAX.EXE /R+ /N+ /P-
SHELL=C:\DOSMAX\SHELLMAX.COM C:\COMMAND.COM C:\ /E:256 /P

The crash occurs on line 4. Can you confirm that this problem does not occur on a real PC with MCL86?

DOSMAX, together with USE!UMB.SYS, can be downloaded from here:

https://github.com/monotech/NuXT/blob/m ... DOSMAX.zip

I have carried out a more detailed analysis of this problem debugging this driver, and have come to the following conclusion:



It seems that this instruction is not working properly. I don't know if it is a problem with MCL86 or with the core. Below I send a screenshot of PCXT in MiSTer and another one of PCEm (on a real 8088 machine it also happens):





I have checked, that if we use DS:SI instead of SS:SI, the operation is correct in MiSTer.

I have created two executables, one using SS as the source and the other using DS as the source. The first one reproduces the problem mentioned in the core, and returns an ERROR message, when on an emulator or a real PC it doesn't happen and shows OK. The other one returns OK in both environments.

@MicroCoreLabs, can you try these tests with MCL86 on a real PC? If it works fine, @kitune-san, can you try it and see if you can find out why it malfunctions with the core?

Pinging @MicroCoreLabs with a quote just in case. This looks a lot like a CPU module bug.

[bbond007]

@kitune-san

Do you (or anyone) know why the following code does not work on the current PCXT core?
Is this a BIOS issue?

Code: Select all

procedure stuffKey(scan : byte; c : char); assembler;
asm
  mov cl, c
  mov ch, scan
  mov ah, 5
  int $16
  {al=0 if success, 1 if failed, but we just ignore that here}
end;

https://en.wikipedia.org/wiki/INT_16H

Thanks!

[pgimeno]

It seems that this instruction is not working properly. I don't know if it is a problem with MCL86 or with the core. Below I send a screenshot of PCXT in MiSTer and another one of PCEm (on a real 8088 machine it also happens):

MiSTer_SSSI_TO_ESDI.png
PCEM_SSSI_TO_ESDI.png

The screenshots don't show the value of CX prior to the instruction, so it's hard to actually tell whether they're working properly or improperly. If CX = 1 then the results are consistent.

[spark2k06]

It seems that this instruction is not working properly. I don't know if it is a problem with MCL86 or with the core. Below I send a screenshot of PCXT in MiSTer and another one of PCEm (on a real 8088 machine it also happens):

MiSTer_SSSI_TO_ESDI.png
PCEM_SSSI_TO_ESDI.png

The screenshots don't show the value of CX prior to the instruction, so it's hard to actually tell whether they're working properly or improperly. If CX = 1 then the results are consistent.

I have attached a couple of executables in the thread reproducing the problem, download them, the problem is always reproduced from CX > 1.

[pgimeno]

@kitune-san

Do you (or anyone) know why the following code does not work on the current PCXT core?
Is this a BIOS issue?

Code: Select all

procedure stuffKey(scan : byte; c : char); assembler;
asm
  mov cl, c
  mov ch, scan
  mov ah, 5
  int $16
  {al=0 if success, 1 if failed, but we just ignore that here}
end;

https://en.wikipedia.org/wiki/INT_16H

Thanks!

Wikipedia is not the best source for interrupt information. Ralf Brown's interrupt list has this to say about this function:

Code: Select all

--------B-1605-------------------------------
INT 16 - KEYBOARD - STORE KEYSTROKE IN KEYBOARD BUFFER (AT/PS w enh keybd only)
        AH = 05h
        CH = BIOS scan code
        CL = ASCII character
Return: AL = status
            00h if successful
            01h if keyboard buffer full
        AH destroyed by many BIOSes

Emphasis on "(AT/PS w enh keybd only)"

It also lists different behaviours for this function on PCjr and Tandy 2000.

You can emulate it by grabbing the circular buffer pointers in the BIOS memory area and inserting the key in the buffer yourself.

[suww37]

Pcxt core don't work after MiSTer update all. When I run the core, it stop at the logo screen. What's going on Has the pcxt core? pcxt core become MiSTer's official?

[spark2k06]

Pcxt core don't work after MiSTer update all. When I run the core, it stop at the logo screen. What's going on Has the pcxt core? pcxt core become MiSTer's official?

You must wait for sorgelig to make a new Main public.

Edit: Sorry, I didn't see that you had already posted it, I'll check it later.

In any case, check the README of the PCXT core. Now you should have pcxt.rom and tandy.rom instead of boot.rom.

[suww37]

Pcxt core don't work after MiSTer update all. When I run the core, it stop at the logo screen. What's going on Has the pcxt core? pcxt core become MiSTer's official?

You must wait for sorgelig to make a new Main public.

Edit: Sorry, I didn't see that you had already posted it, I'll check it later.

In any case, check the README of the PCXT core. Now you should have pcxt.rom and tandy.rom instead of boot.rom.

After renaming boot.rom, bios now works on pcxt core. But hdd.img can't be booted. It doesn't seem to recognize the image. Do I still need the uart commands in misiter.ini?

[suww37]

"kings of the beach" game on "Tandy 1000" gives "packed file error".

Does it really say "packed file error" or does it say "Packed file is corrupt"? The difference is important.

the error message is following.
Packed file is corrupt

[pgimeno]

That's weird. Has this core implemented something like an A20 gate or an HMA area?

[MicroCoreLabs]

Does the first byte of the MOVSB get moved successfully? Is the 0x5C the first byte?

I am wondering if you are getting an interrupt between repeats of the MOVSB opcode. Remember that the real 8086 will only remember the first prefix opcode in between interrupts.

Your sequence of 0xF3 0x36 0xA4 is REPeat, Segment_Override_to_SS, MOVSB. So if there is an interrupt/trap then it will resume at the 0x36 0xA4 and will lose the REPeat opcode. This is unique to the 8088. The 80286 and beyond can remember more prefixes between interrupts.

Im still checking my microcode, however I was noticing that if one byte is successfully moved using MOVSB then the segment override is basically working at least once. I will check to make sure the override works between MOVSB repeat cycles but, as I noted, you will lose the REP opcode if there is an interrupt between iterations.

[spark2k06]

Does the first byte of the MOVSB get moved successfully? Is the 0x5C the first byte?

Exactly, that is the first byte, but 32 should have been copied.

I am wondering if you are getting an interrupt between repeats of the MOVSB opcode. Remember that the real 8086 will only remember the first prefix opcode in between interrupts.

Your sequence of 0xF3 0x36 0xA4 is REPeat, Segment_Override_to_SS, MOVSB. So if there is an interrupt/trap then it will resume at the 0x36 0xA4 and will lose the REPeat opcode. This is unique to the 8088. The 80286 and beyond can remember more prefixes between interrupts.

Im still checking my microcode, however I was noticing that if one byte is successfully moved using MOVSB then the segment override is basically working at least once. I will check to make sure the override works between MOVSB repeat cycles but, as I noted, you will lose the REP opcode if there is an interrupt between iterations.

I don't know if it is receiving interrupts during the copy, but it is curious that only one byte is always copied. In the previous post I have provided a couple of very simple .COM files where this behaviour is reproduced, and both in PCEm and in a real PCXT (8088 in Sergey's Micro8088 project) it works fine.

[MicroCoreLabs]

Exactly, that is the first byte, but 32 should have been copied.

Thats good. So the override is working and so is the MOVSB... just something strange about either the REP or the SEG_OVERRIDE.

As a quick test, would it be possible to move the CLI to before the repeated MOVSB so see if it is true that an interrupt is messing up the REP?

Its been a while since I looked at this code, however I also wonder if your single-stepping is also causing the prefix(s) to be eliminated for the MCL86. I believe that I am allowing the TRAP to come between REP iterations, but maybe thats not accurate?

Could you also write a small .com file to copy from one place to another with the same prefixes and then only after the com file runs look at the results. Would be interested to see if the sequence, if not interrupted, works successfully at all. I am not setup to duplicate this at the moment.

[MicroCoreLabs]

this behaviour is reproduced, and both in PCEm and in a real PCXT (8088 in Sergey's Micro8088 project) it works fine.

Hmm.. this is not actual 8088 silicon, correct? The testing I did was against the real Intel 8088 to duplicate the exact behavior - especially for things like Interrupts, TRAP, and repeats. There are "bugs" in the real 8088 that I tried to duplicate which are accidentally or intentionally "corrected" in many 8088 emulators... The loss of prefixes between interrupts are one example...

[spark2k06]

Exactly, that is the first byte, but 32 should have been copied.

Thats good. So the override is working and so is the MOVSB... just something strange about either the REP or the SEG_OVERRIDE.

As a quick test, would it be possible to move the CLI to before the repeated MOVSB so see if it is true that an interrupt is messing up the REP?

Its been a while since I looked at this code, however I also wonder if your single-stepping is also causing the prefix(s) to be eliminated for the MCL86. I believe that I am allowing the TRAP to come between REP iterations, but maybe thats not accurate?

Could you also write a small .com file to copy from one place to another with the same prefixes and then only after the com file runs look at the results. Would be interested to see if the sequence, if not interrupted, works successfully at all. I am not setup to duplicate this at the moment.

I will try it tomorrow. Just stress that the problem occurs with the SS segment as the origin. Being DS there is no problem.

[MicroCoreLabs]

Of course the SS is necessarily modified when an interrupt is taken. The DS is not. Suspicious, no?

I believe the sequence you isolated is being interrupted in the middle of the REP, possibly after the first copy. And on the genuine 8088 which has a bug where only the prefix preceding the MOVSB is saved.

Also, I suspect that DEBUG will also debounce the REP and maybe the reason you only see one successful copy.

Maybe you can allow this sequence to run and use a breakpoint on an opcode after the sequence to see if all bytes were copied.

[akeley]

Congrats on the official release. It's been very exciting watching this core grow. Break out the bubbly!