Ticket #45468

(Volkov Commander) On-screen garbage, memory exception or hang

오픈 날짜: 2022-08-27 04:46 마지막 업데이트: 2023-08-01 03:54

Reporter:
소유자:
Type:
Status:
Open [Owner assigned]
Component:
MileStone:
(None)
Priority:
5 - Medium
Severity:
5 - Medium
Resolution:
None
File:
3

Details

Hi Mateusz,

I think, I found an incompatibility between SvarCOM and Volkov Commander.

When returning to VC from a program I started from VC 4.05, e.g., my build of FED editor 2.24 or FreeDOS EDIT from the FreeDOS 1.3 release, I see some garbage on the screen.

This doesn't happen with FreeCOM 0.85a, also from FD 1.3.

I tested with SvarCOM 2022.3 and 2022.4. Also tried the SvarDOS default kernel in contrast to the FD 1.3 kernel 2043 (May 13 2021).

With VC 4.99.08 alpha things are even getting more worse: After quitting the "guest" program, I'm not in VC again, but at the DOS prompt.

When JEMM and other stuff is loaded, I often get a memory exception 06. Sometimes the machine hangs w/o or after the exception.

I guess, either some register or memory region gets corrupted.

In VCBUG.7z you can find a floppy image with VC 4.05 and 4.99.08 alpha, FD kernel 2043, SvarCOM 2022.4, FED, FD-EDIT to play with.

Cheers,

Robert

Ticket History (3/8 Histories)

2022-08-27 04:46 Updated by: bttr
  • New Ticket "On-screen garbage, memory exception or hang" created
2022-08-27 04:55 Updated by: bttr
  • Details Updated
2022-08-27 18:13 Updated by: mateuszviste
댓글 올리기

Hi Robert, thanks for the detailed trouble description. I have booted your image under VBox and I can confirm that: - with VC499, quitting the guest application returns directly to SvarCOM instead spawning back a VC instance - with VC405, running EDIT, leaving it, and then quitting VC leaves a 3 weird characters on the console (similar to " = Ef")

When booting with FreeCOM as the command shell, none of these issue appear (ie. everything works as expected).

I didn't have any Exception 06, but that's because I didn't try loading JemmEx. Exception 06 means "invalid opcode" so it usually hints that either the codeflow jumped into some area of memory that wasn't supposed to be executed (like an invalid pointer set in an INT handler) or that part of the in-memory code has been corrupted by something.

From the top of my head I can only guess this might be related to how SvarCOM swaps in and out itself. VC certainly performs a similar task, and maybe they both end up screwing each other. FreeCOM performs no such swapping, which could explain why it works more reliably in this case.

I will investigate this in coming days.

2023-08-01 03:53 Updated by: mateuszviste
  • Summary Updated
2023-08-01 03:54 Updated by: mateuszviste
  • Summary Updated

Attachment File List

Edit

You are not logged in. I you are not logged in, your comment will be treated as an anonymous post. » Login