I'm not sure if you are aware... so figured I'd bring it to your attention. I see that you are using a lot of CInt(…) calls. If you don't need the behavior (which you most likely don't) of the rounding that CInt() does; you might want to change all of these calls to CInt(Fix(…)). These will then be optimized by the compiler to a single IL operation (Conv.I4). This is a recent enhancement to the compiler. When you make this call using the CInt(Fix(value)) pattern, it will "truncate" and cast the numeric value (dropping the fractional) in the most efficient manner possible.

If you would like assistance in making these changes, let me know and I'd be happy to coordinate toward a pull request.

As a side note, I'd be very interested in how much of a difference this would make as I have found that significant calls to CInt() can indeed add up. This is (or was) something that was a serious performance impact for projects just like yours (emulation). That's why I've been championing for this change for over 5 years while simultaneously fighting against proposals to add new keywords just for this; that's a whole other story. ;-) This process went through three different VB language leads... so it was definitely a process. In the end, it was what I proposed all that time ago and everyone using this pattern (which is widely used) benefits. So now I'm very curious as to whether or not the fight was worth it in a real-world example. Assuming it is, I'd love to share the results with the members of the VB team that helped to gitterdone.

I've put together a small program to test branching and found several branch ops fail:

The file I'm attaching has been modified to focus on just the failed ops in order to (hopefully) be able to repro easier.

branch2.zip

(I found this code in a forum from 2011 while searching (what seems like an impossible search) for any programs that can exercise an x86 emulator.)

I don't know if this is causing the issue(s); however, it's a start.

Playing around with different versions of what eventually became qbasic.exe (BASIC PDS 7.1, QB 4.5), very similar issues happen as qbasic.exe... so at least it's consistent. The thought crossed my mind as to whether or not there might be any command line compatibility

C:\>qbasic /?

Results in a bunch of a's and e's... and not entirely in the same positions as where the proper text should be. This might be of interest since this, in theory, should be less code as the console help is usually one of the first points that most apps would hit... at least it's what I'm thinking in my head.

I did try all of the switches, not really any noticeable affect.

I also wondered if it would execute if I loaded it with a file...

I created the following (test.bas):

PRINT "HELLO WORLD!"

and then...

qbasic test.bas

Interestingly enough, it seems to have the same text problem... odd. So whatever the issue is, it appears to be carrying through to the interpreter as well. Strange.

I'm not familiar enough with the code base and, well emulation, yet to know if this might help.

Where do I find the SdlDotNet assembly referenced in x8086NetEmu?

Found another strange situation that seems like it might be useful to investigate further...

After playing around with QBASIC.EXE; what would happen if I tried to use QB4.5. The QB.EXE executable exhibits similar behavior as QBASIC.EXE; however, there are other files that could be used to explore. I set out to compile some code:

Same TEST.BAS as the QBASIC.EXE ticket.

BC - works. Builds a .OBJ file (whether or not it's correct might be suspect... see below.)
LINK - fails with:

LINK : fatal error L1104: BRUN45.LIB : not valid library

This same process works as expected in DosBox. The resulting EXE built in DosBox copied to here also works as expected. So programs compiled in QB45 appear to work. I also have some TSR's that are built in QB45 along with other tools... those also appear to work as expected.

It is also interesting to note that the text being presented is all displayed... unlike what happens when trying to use:

C:\>QB /?

I started to think that maybe there is something "odd" with ANSI.SYS not being loaded. With it loaded, still the same problems. I also confirmed that it appears to be working using a custom prompt using ANSI characters. So don't think that's the problem.

To make things even more interesting, I have an old XREF tool (Don Malin's Cross Reference Program (c) 1992 v 2.24). This tool appears to have the same menu UI and overall user interface elements... and works.

Not sure if this is useful or not; but I did come across the source for the BIOS...

http://www.phatcode.net/downloads.php?id=101

I tried v2.6 and v2.0; same results as the one included (which displays as 2.5).

Where do I find the assembly for the CachedBitmapUtility reference in FastCGAWinForms?

As discussed here, can you please update to your latest local source?

Thanks in advance.

I copied some of the files from the download available at:

https://whenimbored.xfx.net/2012/10/x8086netemu-an-8086-emulator-in-vb-net/3/

/disks
/roms
Perfect DOS VGA 437.ttf
settings.dat

Into the x8086NetEmu\bin folder.

I then launch the x8086NetEmuConsole project (after finding SdlDotNet). However, it then crashes at:

cpu.SimulationMultiplier = Double.Parse(xml.<simulationMultiplier>.Value)

In ParseSettings()

After adding this entry to the settings.dat file with a value of 1, things appear to work.

So the questions are:

1. What is this value for?
2. What should the value be set to as a default?
3. What values are available and what does changing it one direction or the other accomplish?

Looking for different diagnostics (MSD.EXE fails), I found...

ftp://ftp.sac.sk/sac/utildiag/diags.zip

on

http://www.bttr-software.de/freesoft/system.htm

It works in many cases; and in others, it locks up. Not sure of it's usefulness; but figured I'd add it to the possibilities list.

One thing that does jump out at me is the System BIOS Type: XT, Unknown BIOS Type
And the CPU Type: Intel, 80188.

Does that seem correct?

Updating to the latest code, it appears that it is now using a reference to TupperFormula I'm seeing 4 errors related to 2 lines in ButtonIcon.vb (lines 44, 48) in that project. Parameter h not specified and Pixel is not a member of DirectBitmap.

Is there a newer version of that project?

I also found a copy of CheckIt.

Running the System Board Test:

CPU General Functions - Success
CPU Interupt Bug - locks up. (This test passes in DosBox.)

The Video tests are acting very strange. The log states that they passed; however, the screen just flashes strangely and immediately returns to the menus.

I found the binaries:

http://www.minuszerodegrees.net/software/software.htm