OPENSTEP 4.2 Display issues (86Box v3.7.1)

[tmcintos]

Describe the bug Fonts in OPENSTEP 4.2 generally do not look right; font metrics seem to be wrong. This is is visible in menus and elsewhere, but it is especially apparent in Terminal, where backspace/delete does not work properly, failing to fully erase the previous character, leading to "overtype" behavior that makes text unreadable when editing.

This seems vaguely similar to #1204, except much less severe. Perhaps that problem was not fully fixed?

To Reproduce Steps to reproduce the behavior:

1. Install OPENSTEP 4.2 + OS42MachUserPatch4, e.g. as described here: https://openstep.bfx.re
2. Launch Terminal app.
3. Type some text, hit backspace/delete, observe text not properly deleted.
4. From Terminal menu, select Font > Font Panel...
5. In Font Panel, select 12 or 14 and click Set.
6. Observe actual font size is unexpectedly set to a non-integer value.
7. Click Set repeatedly and observe that font size is progressively reduced by a fractional amount.

Expected behavior Font should be set to the selected integer value. Repeatedly clicking Set should have no effect.

Menu text should look more like shown in this image:

Screenshots Partial erase upon backspace:

"overtype" behavior when editing:

After selecting 12pt font size and clicking Set; note fractional font size:

After clicking Set again, note font size reduced:

Desktop (please complete the following information):

• OS: macOS 12.6 (21G115) on M2 MacBook Air
• 86Box version: 86Box v3.7.1
• Build information: [build 4032] [730af4dd5]

Additional context

• Changing any of the following appears to make no difference in this behavior:
  • Socket / CPU
  • Motherboard
  • RAM size
  • Graphics card / driver
  • Graphics mode

Config file:

[General]
vid_renderer = qt_software
video_fullscreen_scale = 1
mouse_sensitivity = 0.79
vid_resize = 2
window_fixed_res = 1152x872

[Machine]
machine = p65up5_cp55t2d
cpu_family = pentium_tillamook
cpu_speed = 233333333
cpu_multi = 3.5
cpu_use_dynarec = 1
time_sync = local
fpu_type = internal
cpu = 18
mem_size = 524288

[Video]
gfxcard = stealth64v_pci

[Input devices]
mouse_type = ps2

[Sound]
fm_driver = nuked
sndcard = sb16_pnp

[Storage controllers]
hdc = ide_pci_2ch

[Novell NE2000]
mac = 7e:2b:2c

[Network]
net_type = slirp
net_host_device = en0
net_card = ne2kpci

[Floppy and CD-ROM drives]
fdd_01_type = 35_2hd
fdd_01_check_bpb = 0
fdd_02_type = none
cdrom_01_speed = 72
cdrom_01_parameters = 0, atapi
cdrom_01_ide_channel = 0:1

[Hard disks]
hdd_01_parameters = 63, 16, 2080, 0, ide
hdd_01_fn = hd0.vhd
hdd_01_speed = ramdisk
hdd_01_ide_channel = 0:0

[Realtek RTL8029AS]
bios = 0
mac = f0:ee:42

[Monitor #1]

[Monitor #2]

[tmcintos]

Confirmed that the problem is not observed when booting same disk image under Bochs:

[jvernet]

It’s related to FPU emulation not enough accurate.

Envoyé de mon iPhone

Le 17 oct. 2022 à 07:36, tmcintos @.***> a écrit :



Confirmed that the problem is not observed when booting same disk image under Bochs:

[bochs]https://user-images.githubusercontent.com/1097927/196097023-a086a089-6ba8-4ddc-a47b-01e1f0601386.png

— Reply to this email directly, view it on GitHubhttps://github.com/86Box/86Box/issues/2718#issuecomment-1280314313, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AD4OSKDDFS4Q3RMQE44S37DWDTQUBANCNFSM6AAAAAARGUXUQE. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[tmcintos]

It’s related to FPU emulation not enough accurate.

That’s what I figured. Is it a known issue?

[rderooy]

It’s related to FPU emulation not enough accurate.

That’s what I figured. Is it a known issue?

https://github.com/86Box/86Box/issues/507

[tmcintos]

I see there it says:

For the problem with fonts on NextStep, it's not directly related to 64 or 80 bits maths, it's a bug somewhere in the 87 emulation. I saw that with Previous, a 68040 emulator for 68k Nextstep, got same kind of behaviours with fonts and display problems.

So it seems these may be considered separate issues, or at least this sounds like a subset of that larger problem. Hopefully the fix for this does not need to wait for that larger problem to be resolved, as it appears to be moving slowly without a clear path forward.

[OBattler]

It's moving slowly because there's no way to improve the emulated FPU's accuracy without destroying performance, at least on anything that's not x86 and x86_64 - which is a problem, given that we support ARM and ARM64 hosts as well. And even on x86 and x86_64, the required full 80-bit precision is only doable with the legacy x87 instructions (SSE doesn't have an 80-bit precision mode, and neither does AVX, which is out of the question anyway, since even I'm still on CPU's that don't support AVX).

And yes, precision does matter here - as we're emulating the x87 in 64-bit precision, that causes a lot of rounding errors, hence these glitches and also the mouse movement problems in Linux guests (and borked SB16 volume controls in a specific Linux guest that I don't remember which exact distribution it is now).

[tmcintos]

In fact I am running on macOS / arm64.

So is there no lead on a solution for this? I might be interested in spending some time on the problem if there were any leads to pursue.

it seems like if nothing else, an option to prefer FPU correctness over performance would be in order.

Performance is meaningless if the result is unusable, as it is in this case. The current behavior makes 86Box useless for this application, which is a big disappointment.

[OBattler]

I'm all for SoftFloat as an option, the reason why it hasn't been done yet is because noone on the Dev team currently has the time for it as we have a lot of other stuff to do before we get around to that.

[OBattler]

Try the latest 86Box build, it appears TC1995's implemenation of the FXTRACT FPU opcode (previously unimplemented) fixes the fonts in OpenStep 4.2

[wurensh]

I can confirm that on macOS with Apple Silicon the latest experimental build (with new recompiler) does indeed fix the Openstep font issue. Thank you for fixing this!

[tmcintos]

@wurensh

I can confirm that on macOS with Apple Silicon the latest experimental build (with new recompiler) does indeed fix the Openstep font issue. Thank you for fixing this!

Interesting. I cannot reproduce this result.

Using the builds found here https://ci.86box.net/job/86Box/ (4.0 build 4595 macOS Universal, both ODR and NDR), I see no improvement vs. what is shown in my original screenshots above. This is running on the same system (M2 MacBook Air) with latest macOS (Ventura 13.3.1 (22E261)).

Is it possible the fix was reverted between build 4584 and 4595?

What is your OPENSTEP configuration? I have 86box configured for Socket 7 / i430HX / MMX 233MHz / 512MB with PCI S3 Vision 964 (Diamond Stealth64 VRAM), with OPENSTEP 4.2 configured with "DiamondStealth 64 VRAM (S3 968) PCI", 1152x864/75MHz RGB:888/32 (though I don't think the particular graphics configuration matters, based on past testing).

[wurensh]

Is it possible the fix was reverted between build 4584 and 4595?

This seems to be the case unfortunately. I've just tried both 4595 builds (with and without new recompiler support) and the fonts are broken again.

Build NDR-4584 however continues to work well for me with the fonts rendering beautifully.

FWIW my machine config is Slot 1/[i440BX] HP Vectra VEi8/PPro @ 166MHz/64MB RAM. Display is #9 9FX 771 (PCI) 4MB. I've tried multiple graphics cards and resolutions and I agree that it seems unrelated.

[OBattler]

Yes, it turns out that the 32-bit address variants of the FXTRACT x87 instruction were accidentally removed from the ops tables, this has now been corrected. OpenStep now works correctly again.

[tmcintos]

Retested with build 4604 (ODR); no other changes to my configuration.

Verified this build fixes all the original issues noted above:

• incorrect font rendering
• fractional font size in Font Panel
• overtype problems in Terminal

Also checked the NDR variant and saw similar results.

Thanks!