Page 1 of 1
Interesting Tests We Could Run For x86
Posted: Thu Sep 22, 2022 7:40 pm
by jordi
I've found some interesting tests that were linked from vogons for verifying x86 CPu
https://forum.osdev.org/viewtopic.php?f ... 9&start=15
I guess it's just a matter of compiling them
Re: Interesting Tests We Could Run For x86
Posted: Thu Sep 22, 2022 7:40 pm
by jordi
Re: Interesting Tests We Could Run For x86
Posted: Thu Sep 22, 2022 8:43 pm
by MicroCoreLabs
Here are the tests I wrote to verify the MCL86 core which touch on the opcodes, addressing modes, and flags.
https://github.com/MicroCoreLabs/Projec ... CL86/Tests
It compiles using A86 into .COM files which run under DOS. I'm sure they are not 100% exhaustive but were good enough to verify the core to a large degree.
Source code is simple and can easily be extended. Upon failure it prints a character using a DOS call so you can track it down in the test source code.
Re: Interesting Tests We Could Run For x86
Posted: Fri Sep 23, 2022 2:02 pm
by Mills
I compiled that, they had some errors (relative jump instructions out of range for 8088/86) I think I solved that, there are some "failed" text but I think that's my fault.
It looks like they did not fail until the program gets stuck, probably because the code is incomplete and they need some kind of "end " instruction.
Re: Interesting Tests We Could Run For x86
Posted: Fri Sep 23, 2022 3:51 pm
by Mills
MicroCoreLabs wrote: ↑Thu Sep 22, 2022 8:43 pm
Here are the tests I wrote to verify the MCL86 core which touch on the opcodes, addressing modes, and flags.
https://github.com/MicroCoreLabs/Projec ... CL86/Tests
It compiles using A86 into .COM files which run under DOS. I'm sure they are not 100% exhaustive but were good enough to verify the core to a large degree.
Source code is simple and can easily be extended. Upon failure it prints a character using a DOS call so you can track it down in the test source code.
It looks like PCXT passed all that tests
![Smile :)](./images/smilies/icon_e_smile.gif)
, this is how it looks like after running "runall.bat":
![20220923_154459-screen.png](./download/file.php?id=7138&sid=ad0e7a8203ae67faed86815a58a677e5)
- 20220923_154459-screen.png (68.9 KiB) Viewed 5145 times
Re: Interesting Tests We Could Run For x86
Posted: Fri Sep 23, 2022 4:11 pm
by MicroCoreLabs
It looks like PCXT passed all that tests
![Smile :)](./images/smilies/icon_e_smile.gif)
, this is how it looks like after running "runall.bat":
Yes, this was the desired result!
I wrote all of these tests on a genuine IBM PCXT using QEdit and then ran them on a PC which had an MCL86 installed. For opcodes which failed I single-stepped the same test on both computers using D86 to see where they diverged.
If I recall correctly, the online emulator PCJs would not complete these tests successfully...
Re: Interesting Tests We Could Run For x86
Posted: Fri Sep 23, 2022 6:34 pm
by thorr
Awesome stuff!
![Smile :)](./images/smilies/icon_e_smile.gif)
Re: Interesting Tests We Could Run For x86
Posted: Fri Sep 23, 2022 8:28 pm
by pgimeno
Is the segment override bug now incorporated as a regression test? It's customary practice to add a test that fails before a bugfix and passes after it, every time a bug is squashed. That's where regression tests take their name, after all: if the bug returns, that's a regression and it will be immediately caught by the test. Some bugs have the bad habit of reviving some time after being squashed.
Best practices also dictate to search for patterns similar to the one that produced the bug, and to elaborate tests that also exercise them. Chances are that if a bug is detected, and there's more code similar to the one that triggered the bug, it will also be similarly bugged. In this case, all segment combinations with all string instruction combinations should probably be exercised by tests, with and without repetition.
Re: Interesting Tests We Could Run For x86
Posted: Fri Sep 23, 2022 9:29 pm
by MicroCoreLabs
These are all good points but I will leave it as a project for someone else.
![Smile :)](./images/smilies/icon_e_smile.gif)
Re: Interesting Tests We Could Run For x86
Posted: Fri Nov 18, 2022 4:33 am
by MicroCoreLabs
Has anyone tried Area5150 with all of the bug fixes and upgrades recently?
Re: Interesting Tests We Could Run For x86
Posted: Fri Nov 18, 2022 4:39 am
by spark2k06
MicroCoreLabs wrote: ↑Fri Nov 18, 2022 4:33 am
Has anyone tried Area5150 with all of the bug fixes and upgrades recently?
Area5150 still has some bugs, but I don't think they are
CPU related. Rather, they are bugs related to the
CGA implementation, and perhaps a few with timings.
On the other hand, I have to debug a couple of bugs in games... and at least one of them (
Bubble Bobble) I'm sure it's timings or something related to the timer.
Re: Interesting Tests We Could Run For x86
Posted: Tue Nov 22, 2022 10:54 am
by kitune-san
spark2k06 wrote: ↑Fri Nov 18, 2022 4:39 am
MicroCoreLabs wrote: ↑Fri Nov 18, 2022 4:33 am
Has anyone tried Area5150 with all of the bug fixes and upgrades recently?
Area5150 still has some bugs, but I don't think they are
CPU related. Rather, they are bugs related to the
CGA implementation, and perhaps a few with timings.
On the other hand, I have to debug a couple of bugs in games... and at least one of them (
Bubble Bobble) I'm sure it's timings or something related to the timer.
Please tell me if you notice anything that I can do to help you.
In area 5150, there are two scenes that slow down.
I assume that many instructions are used which have different number of clocks depending on the source.
For example, DIV or MUL instructions. As I recall, in MCL86, the number of clocks consumed by these instructions is fixed.
However, I have not seen the source code, so this assumption may be incorrect.
Re: Interesting Tests We Could Run For x86
Posted: Tue Nov 22, 2022 11:11 am
by spark2k06
kitune-san wrote: ↑Tue Nov 22, 2022 10:54 am
Please tell me if you notice anything that I can do to help you.
In area 5150, there are two scenes that slow down.
I assume that many instructions are used which have different number of clocks depending on the source.
For example, DIV or MUL instructions. As I recall, in MCL86, the number of clocks consumed by these instructions is fixed.
However, I have not seen the source code, so this assumption may be incorrect.
Yes, I'll let you know, thank you!
I'm closing an issue related to the screen borders and I'll start debugging
Bubble Bobble shortly, as for this one I don't think we'll ever get the source code.
Regarding
area5150, I'm not going to dedicate more effort to it until I have the source code, because I think it will be released sooner or later.
Re: Interesting Tests We Could Run For x86
Posted: Tue Nov 22, 2022 9:40 pm
by thorr
Thanks for your efforts guys. When you get a chance, if either of you have CRT TV's, it would be great if you could work on stabilizing the CRT TV compatibility/modelines to work on more displays. I don't know if they are already correct compared to real hardware, or if work can be done to improve the situation. I don't know if the latest HDMI fixes also fix this problem. It's possible. I can't test at the moment with my paint fume filled room.
Re: Interesting Tests We Could Run For x86
Posted: Tue Nov 22, 2022 11:50 pm
by kitune-san
thorr wrote: ↑Tue Nov 22, 2022 9:40 pm
Thanks for your efforts guys. When you get a chance, if either of you have CRT TV's, it would be great if you could work on stabilizing the CRT TV compatibility/modelines to work on more displays. I don't know if they are already correct compared to real hardware, or if work can be done to improve the situation. I don't know if the latest HDMI fixes also fix this problem. It's possible. I can't test at the moment with my paint fume filled room.
Sorry. I don't have a CRT monitor or a 15 kHz monitor. Also, I am not familiar with video modules.
Perhaps only @spark2k06 can solve this issue.
Re: Interesting Tests We Could Run For x86
Posted: Wed Nov 23, 2022 3:40 am
by spark2k06
thorr wrote: ↑Tue Nov 22, 2022 9:40 pm
Thanks for your efforts guys. When you get a chance, if either of you have CRT TV's, it would be great if you could work on stabilizing the CRT TV compatibility/modelines to work on more displays. I don't know if they are already correct compared to real hardware, or if work can be done to improve the situation. I don't know if the latest HDMI fixes also fix this problem. It's possible. I can't test at the moment with my paint fume filled room.
Sorry, I don't have a
CRT monitor either, just wait for other developers to show interest in this core.
Re: Interesting Tests We Could Run For x86
Posted: Wed Nov 23, 2022 9:39 am
by kitune-san
spark2k06 wrote: ↑Fri Nov 18, 2022 4:39 am
On the other hand, I have to debug a couple of bugs in games... and at least one of them (
Bubble Bobble) I'm sure it's timings or something related to the timer.
Maybe there is a bug in the Timer output in mode 3.
Re: Interesting Tests We Could Run For x86
Posted: Wed Nov 23, 2022 10:01 am
by suverman
Asteroid Pilot:
Basica based game (speed sensitive, run well on PCXT class machines)
https://www.youtube.com/watch?v=6a09BmsHjzA
This does not run on the PCXT core. Seems like Basic uses a method of accessing disk which is not currently supported? Not sure.
Re: Interesting Tests We Could Run For x86
Posted: Wed Nov 23, 2022 10:16 am
by breiztiger
it's basica that doesn't start
Re: Interesting Tests We Could Run For x86
Posted: Wed Nov 23, 2022 10:33 am
by suverman
breiztiger wrote: ↑Wed Nov 23, 2022 10:16 am
it's basica that doesn't start
Sorry if this was a known issue.
Re: Interesting Tests We Could Run For x86
Posted: Wed Nov 23, 2022 10:53 am
by kitune-san
kitune-san wrote: ↑Wed Nov 23, 2022 9:39 am
spark2k06 wrote: ↑Fri Nov 18, 2022 4:39 am
On the other hand, I have to debug a couple of bugs in games... and at least one of them (
Bubble Bobble) I'm sure it's timings or something related to the timer.
Maybe there is a bug in the Timer output in mode 3.
Fixed timer. Pls try it.
Re: Interesting Tests We Could Run For x86
Posted: Wed Nov 23, 2022 10:56 am
by spark2k06
kitune-san wrote: ↑Wed Nov 23, 2022 9:39 am
Maybe there is a bug in the Timer output in mode 3.
This is what I have found out so far. The routine in charge of triggering the start-up music is as follows:
Code: Select all
seg000:F945 sub_1F945 proc near ; CODE XREF: seg000:loc_1F907p
seg000:F945 32 E4 xor ah, ah
seg000:F947 BD 00 00 mov bp, 0
seg000:F94A 8B C8 mov cx, ax
seg000:F94C FA cli
seg000:F94D 8E 06 14 01 mov es, word ptr ds:114h
seg000:F951 26 8B 5E 00 mov bx, es:[bp+0]
seg000:F955 3B CB cmp cx, bx
seg000:F957 73 71 jnb short loc_1F9CA
seg000:F959 41 inc cx
seg000:F95A D1 E1 shl cx, 1
seg000:F95C 8B E9 mov bp, cx
seg000:F95E 26 8B 6E 00 mov bp, es:[bp+0]
seg000:F962 0B ED or bp, bp
seg000:F964 74 64 jz short loc_1F9CA
seg000:F966 89 2E 16 01 mov ds:116h, bp
seg000:F96A 26 8B 5E 08 mov bx, es:[bp+8]
seg000:F96E 89 1E 20 01 mov ds:120h, bx
seg000:F972 26 8B 5E 04 mov bx, es:[bp+4]
seg000:F976 89 1E 1A 01 mov ds:11Ah, bx
seg000:F97A 26 8B 5E 02 mov bx, es:[bp+2]
seg000:F97E 89 1E 18 01 mov ds:118h, bx
seg000:F982 8B D5 mov dx, bp
seg000:F984 8B EB mov bp, bx
seg000:F986 8B 36 0E 03 mov si, ds:30Eh
seg000:F98A BF 00 00 mov di, 0
seg000:F98D 8B 0E 3C 00 mov cx, ds:3Ch
seg000:F991 8B D8 mov bx, ax
seg000:F993 83 F9 02 cmp cx, 2
seg000:F996 75 01 jnz short loc_1F999
seg000:F998 49 dec cx
seg000:F999
seg000:F999 loc_1F999: ; CODE XREF: sub_1F945+51j
seg000:F999 ; sub_1F945+7Aj
seg000:F999 26 8B 03 mov ax, es:[bp+di]
seg000:F99C 0B C0 or ax, ax
seg000:F99E 74 19 jz short loc_1F9B9
seg000:F9A0 89 84 58 01 mov [si+158h], ax
seg000:F9A4 89 84 6A 01 mov [si+16Ah], ax
seg000:F9A8 C7 84 22 01 01 00 mov word ptr [si+122h], 1
seg000:F9AE 89 9C 8E 01 mov [si+18Eh], bx
seg000:F9B2 A1 1A 01 mov ax, ds:11Ah
seg000:F9B5 89 84 A0 01 mov [si+1A0h], ax
seg000:F9B9
seg000:F9B9 loc_1F9B9: ; CODE XREF: sub_1F945+59j
seg000:F9B9 83 C6 02 add si, 2
seg000:F9BC 83 C7 02 add di, 2
seg000:F9BF E2 D8 loop loc_1F999
seg000:F9C1 8B EA mov bp, dx
seg000:F9C3 26 8B 46 0A mov ax, es:[bp+0Ah]
seg000:F9C7 0B D2 or dx, dx
seg000:F9C9 C3 retn
seg000:F9CA ; ---------------------------------------------------------------------------
seg000:F9CA
seg000:F9CA loc_1F9CA: ; CODE XREF: sub_1F945+12j
seg000:F9CA ; sub_1F945+1Fj
seg000:F9CA B8 00 00 mov ax, 0
seg000:F9CD 0B C0 or ax, ax
seg000:F9CF C3 retn
seg000:F9CF sub_1F945 endp
And the music is in the background. This routine seems to activate sequences of music that are repeated in a loop... until they are all there. From what I've seen, he has modified the interrupt table to replace the timer routine, with the following code:
Code: Select all
seg000:08C2 ; ---------------------------------------------------------------------------
seg000:08C2 50 push ax
seg000:08C3 53 push bx
seg000:08C4 51 push cx
seg000:08C5 52 push dx
seg000:08C6 1E push ds
seg000:08C7 55 push bp
seg000:08C8 56 push si
seg000:08C9 57 push di
seg000:08CA 06 push es
seg000:08CB B8 C1 31 mov ax, 31C1h
seg000:08CE 8E D8 mov ds, ax
seg000:08D0 D0 0E 2C 01 ror byte ptr ds:12Ch, 1
seg000:08D4 F7 06 30 01 FF FF test word ptr ds:130h, 0FFFFh
seg000:08DA 75 54 jnz short loc_10930
seg000:08DC B8 40 00 mov ax, 40h ; '@'
seg000:08DF 8E C0 mov es, ax
seg000:08E1 26 8B 16 63 00 mov dx, es:63h
seg000:08E6 80 C2 06 add dl, 6
seg000:08E9 B9 2C 01 mov cx, 12Ch
seg000:08EC
seg000:08EC loc_108EC: ; CODE XREF: seg000:08EFj
seg000:08EC EC in al, dx
seg000:08ED 24 08 and al, 8
seg000:08EF E1 FB loope loc_108EC
seg000:08F1 B0 36 mov al, 36h ; '6'
seg000:08F3 E6 43 out 43h, al ; Timer 8253-5 (AT: 8254.2).
seg000:08F5 A0 1A 01 mov al, ds:11Ah
seg000:08F8 E6 40 out 40h, al ; Timer 8253-5 (AT: 8254.2).
seg000:08FA A0 1B 01 mov al, ds:11Bh
seg000:08FD E6 40 out 40h, al ; Timer 8253-5 (AT: 8254.2).
seg000:08FF E3 2F jcxz short loc_10930
seg000:0901 81 F9 13 01 cmp cx, 113h
seg000:0905 72 05 jb short loc_1090C
seg000:0907 83 2E 1A 01 0A sub word ptr ds:11Ah, 0Ah
seg000:090C
seg000:090C loc_1090C: ; CODE XREF: seg000:0905j
seg000:090C 81 F9 E1 00 cmp cx, 0E1h ; 'ß'
seg000:0910 77 0C ja short loc_1091E
seg000:0912 A1 2E 01 mov ax, ds:12Eh
seg000:0915 2B C1 sub ax, cx
seg000:0917 78 05 js short loc_1091E
seg000:0919 83 06 1A 01 02 add word ptr ds:11Ah, 2
seg000:091E
seg000:091E loc_1091E: ; CODE XREF: seg000:0910j
seg000:091E ; seg000:0917j
seg000:091E 89 0E 2E 01 mov ds:12Eh, cx
seg000:0922 8B C1 mov ax, cx
seg000:0924 FF 1E 96 00 call dword ptr ds:96h
seg000:0928 FF 06 24 01 inc word ptr ds:124h
seg000:092C D1 2E 26 01 shr word ptr ds:126h, 1
seg000:0930
seg000:0930 loc_10930: ; CODE XREF: seg000:08DAj
seg000:0930 ; seg000:08FFj
seg000:0930 FB sti
seg000:0931 A1 08 01 mov ax, ds:108h
seg000:0934 01 06 06 01 add ds:106h, ax
seg000:0938 73 0C jnb short loc_10946
seg000:093A FF 06 1E 01 inc word ptr ds:11Eh
seg000:093E D1 2E 20 01 shr word ptr ds:120h, 1
seg000:0942 FF 2E 02 01 jmp dword ptr ds:102h
seg000:0946 ; ---------------------------------------------------------------------------
seg000:0946
seg000:0946 loc_10946: ; CODE XREF: seg000:0938j
seg000:0946 A1 10 01 mov ax, ds:110h
seg000:0949 01 06 0E 01 add ds:10Eh, ax
seg000:094D 73 04 jnb short loc_10953
seg000:094F FF 2E 0A 01 jmp dword ptr ds:10Ah
seg000:0953 ; ---------------------------------------------------------------------------
seg000:0953
seg000:0953 loc_10953: ; CODE XREF: seg000:094Dj
seg000:0953 A1 14 01 mov ax, ds:114h
seg000:0956 01 06 12 01 add ds:112h, ax
seg000:095A 72 0E jb short loc_1096A
seg000:095C B0 20 mov al, 20h ; ' '
seg000:095E E6 20 out 20h, al ; Interrupt controller, 8259A.
seg000:0960 07 pop es
seg000:0961 assume es:nothing
seg000:0961 5F pop di
seg000:0962 5E pop si
seg000:0963 5D pop bp
seg000:0964 1F pop ds
seg000:0965 assume ds:nothing
seg000:0965 5A pop dx
seg000:0966 59 pop cx
seg000:0967 5B pop bx
seg000:0968 58 pop ax
seg000:0969 CF iret
seg000:096A ; ---------------------------------------------------------------------------
seg000:096A
seg000:096A loc_1096A: ; CODE XREF: seg000:095Aj
seg000:096A 07 pop es
seg000:096B 5F pop di
seg000:096C 5E pop si
seg000:096D 5D pop bp
seg000:096E 1F pop ds
seg000:096F 5A pop dx
seg000:0970 59 pop cx
seg000:0971 5B pop bx
seg000:0972 58 pop ax
seg000:0973 FA cli
seg000:0974 2E FF 2E 7A 09 jmp cs:dword_1097A
seg000:0974 ; ---------------------------------------------------------------------------
seg000:0979 90 db 90h ; É
seg000:097A 3C 00 23 15 dword_1097A dd 1523003Ch ; DATA XREF: sub_1072C+5w
seg000:097A ; sub_107A6r ...
The last part of this code is intended to continue the original timer routine:
Code: Select all
seg000:0973 FA cli
seg000:0974 2E FF 2E 7A 09 jmp cs:dword_1097A
seg000:0974 ; ---------------------------------------------------------------------------
seg000:0979 90 db 90h ; É
seg000:097A 3C 00 23 15 dword_1097A dd 1523003Ch ; DATA XREF: sub_1072C+5w
seg000:097A ; sub_107A6r ...
I don't know if it will help you at all, but if I find out more or narrow down the exact problem I'll let you know.
Re: Interesting Tests We Could Run For x86
Posted: Wed Nov 23, 2022 11:16 am
by kitune-san
Code: Select all
seg000:08F1 B0 36 mov al, 36h ; '6'
seg000:08F3 E6 43 out 43h, al ; Timer 8253-5 (AT: 8254.2).
seg000:08F5 A0 1A 01 mov al, ds:11Ah
seg000:08F8 E6 40 out 40h, al ; Timer 8253-5 (AT: 8254.2).
seg000:08FA A0 1B 01 mov al, ds:11Bh
seg000:08FD E6 40 out 40h, al ; Timer 8253-5 (AT: 8254.2).
I think this modification will work because it is set to mode 3.
Re: Interesting Tests We Could Run For x86
Posted: Wed Nov 23, 2022 11:25 am
by spark2k06
kitune-san wrote: ↑Wed Nov 23, 2022 11:16 am
Code: Select all
seg000:08F1 B0 36 mov al, 36h ; '6'
seg000:08F3 E6 43 out 43h, al ; Timer 8253-5 (AT: 8254.2).
seg000:08F5 A0 1A 01 mov al, ds:11Ah
seg000:08F8 E6 40 out 40h, al ; Timer 8253-5 (AT: 8254.2).
seg000:08FA A0 1B 01 mov al, ds:11Bh
seg000:08FD E6 40 out 40h, al ; Timer 8253-5 (AT: 8254.2).
I think this modification will work because it is set to mode 3.
These routines, they work... but the music sounds too fast in the core, when in a real
PCXT the speed is correct.
Edit: Wait, I didn't see that you sent a new binary, I'll try it right now
![Smile :-)](./images/smilies/icon_e_smile.gif)
Re: Interesting Tests We Could Run For x86
Posted: Wed Nov 23, 2022 11:31 am
by spark2k06
kitune-san wrote: ↑Wed Nov 23, 2022 10:53 am
kitune-san wrote: ↑Wed Nov 23, 2022 9:39 am
spark2k06 wrote: ↑Fri Nov 18, 2022 4:39 am
On the other hand, I have to debug a couple of bugs in games... and at least one of them (
Bubble Bobble) I'm sure it's timings or something related to the timer.
Maybe there is a bug in the Timer output in mode 3.
Fixed timer. Pls try it.
It's working! Thanks... let's try the demos now
![Smile :-)](./images/smilies/icon_e_smile.gif)
Re: Interesting Tests We Could Run For x86
Posted: Wed Nov 23, 2022 11:41 am
by kitune-san
I sent pull request.