The online community for MiSTer FPGA enthusiasts
https://misterfpga.org/
README updated:breiztiger wrote: ↑Wed Aug 17, 2022 2:29 pm why floppy is mount in b: drive ?
i have to type B at xt ide scrren to boot B: drive with a booter game ...
It is variable, sometimes it says exact xt, sometimes 1%.breiztiger wrote: ↑Fri Aug 19, 2022 7:59 am 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)
I have carried out a more detailed analysis of this problem debugging this driver, and have come to the following conclusion:spark2k06 wrote: ↑Wed Aug 17, 2022 8:07 am @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:
The crash occurs on line 4. Can you confirm that this problem does not occur on a real PC with MCL86?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
DOSMAX, together with USE!UMB.SYS, can be downloaded from here:
https://github.com/monotech/NuXT/blob/m ... DOSMAX.zip
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
wark91 wrote: ↑Fri Aug 19, 2022 10:40 amYou 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.
suww37 wrote: ↑Fri Aug 19, 2022 10:48 amwark91 wrote: ↑Fri Aug 19, 2022 10:40 amYou could add them in this list below with some screenshot
It will help tracks issues or compatibility.
https://docs.google.com/spreadsheets/d/ ... 1426632805I 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
Pinging @MicroCoreLabs with a quote just in case. This looks a lot like a CPU module bug.spark2k06 wrote: ↑Fri Aug 19, 2022 8:46 amI have carried out a more detailed analysis of this problem debugging this driver, and have come to the following conclusion:spark2k06 wrote: ↑Wed Aug 17, 2022 8:07 am @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:
The crash occurs on line 4. Can you confirm that this problem does not occur on a real PC with MCL86?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
DOSMAX, together with USE!UMB.SYS, can be downloaded from here:
https://github.com/monotech/NuXT/blob/m ... DOSMAX.zip
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?
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;
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 wrote: ↑Fri Aug 19, 2022 8:46 am 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
I have attached a couple of executables in the thread reproducing the problem, download them, the problem is always reproduced from CX > 1.pgimeno wrote: ↑Fri Aug 19, 2022 3:30 pmThe 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 wrote: ↑Fri Aug 19, 2022 8:46 am 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
Wikipedia is not the best source for interrupt information. Ralf Brown's interrupt list has this to say about this function:bbond007 wrote: ↑Fri Aug 19, 2022 3:14 pm @kitune-san
Do you (or anyone) know why the following code does not work on the current PCXT core?
Is this a BIOS issue?
https://en.wikipedia.org/wiki/INT_16HCode: 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;
Thanks!
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
You must wait for sorgelig to make a new Main public.
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?
the error message is following.
Exactly, that is the first byte, but 32 should have been copied.MicroCoreLabs wrote: Does the first byte of the MOVSB get moved successfully? Is the 0x5C the first byte?
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 wrote: 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.
Thats good. So the override is working and so is the MOVSB... just something strange about either the REP or the SEG_OVERRIDE.Exactly, that is the first byte, but 32 should have been copied.
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...this behaviour is reproduced, and both in PCEm and in a real PCXT (8088 in Sergey's Micro8088 project) it works fine.
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 wrote: ↑Fri Aug 19, 2022 6:25 pmThats good. So the override is working and so is the MOVSB... just something strange about either the REP or the SEG_OVERRIDE.Exactly, that is the first byte, but 32 should have been copied.
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.
