superfury wrote:

@reenigne: If your EU cycle counts for those instructions(the totals, excluding specific timings in between(e.g. part before and part after memory access only being applied after a memory transaction(e.g. mov al,[bx]), then those should be working(theoretically). The CRTC should be functioning correctly(and everything related, like CPU waitstates for horizontal timings etc.), seeing as the 4K colors part still works.

I'd need a start CS:IP address(e.g. segment:offset) to check said code, though, to start checking it.

Easiest way to figure that out is to just stop the emulator while the effect is running. It should be executing that code most of the time (the entire vertical active raster period, if it's working correctly). If you do that and the code at CS:IP doesn't look like that part of the source, restart and stop again until it does.

@reenigne: I'll have to try that.

I have also added two command-line parameters to UniPCemu's source code, debuggerout and debuggerin. debuggerout enables code that uses printf to print logging data logged to debugger.log. debuggerin verifies logged blocks(lines in the case of debugger.log) using input on stdin. When they don't match, <VERIFY:MISMATCH> is logged on a the row after the mismatching line.
Newlines are handled in a universal way(it takes input using any valid newline format, \r,\n,\r\n or \n\r. All are converted to a single newline for comparison.

Then, to compare emulators using this, you can use a simple command-line pipe (| I think?) to verify and compare emulation debuggers(debugger.log is logged as well btw). So like "a/UniPCemu_x64.exe debuggerout | ../b/UniPCemu_x64.exe debuggerin" to compare a with b's version of UniPCemu(or any other emulator supporting it for that matter).

Although, perhaps, logging the mismatch before said line/block(multi-line log, shouldn't be the case with debugger.log) might be easier to diagnose?

Edit: One big pro on this new functionality is that I can use it to compare those pesky multi-GB loggings of UniPCemu with the Windows 3.0/3.1 protected-mode boot logs(assuming no timing/hdd handling differences). Although I hope those use the XT-IDE BIOS as well, but I doubt that.

I made an executable version of XTCE: http://www.reenigne.org/misc/xtce.zip . Doesn't
need any DLLs except for the VC++ runtime which you can get at https://www.microsoft.com/en-us/download/deta … s.aspx?id=52685 if it complains about vcruntime140.dll being missing.

Give it a .com file on the command line. It'll execute it for (by default) 4096 cycles (or until CS:IP ends up at 0060:00FF (which is where it will end up if you do a RET or RETF from the initial SS:SP) whichever happens first), dump a cycle-by-cycle trace to the console, and print the total number of cycles executed at the end.

The program takes up to three integers on the command line, after the filename of the program to execute:
1) Cycle on which to start logging (number of cycles to skip from beginning of log). That way you won't have to scroll through all your setup code each time.
2) Cycle on which to stop logging (e.g. if you want to get a log of one iteration of a loop, but then a total cycle count for all iterations of the loop).
3) Cycle on which to stop executing if you want more than 4096 cycles.

(The command line order of these three numbers is the same as the chronological order in which they occur).

Note that there's no BIOS or DOS loaded, so you can't call any interrupts unless you set them up yourself first. Also you won't get any IRQ0s or DRAM refresh DMAs (so timings will be a little faster than on real hardware) unless you set those up first.

You can load a file that is more than 64kB (just a flat memory-dump format like an extended .com, not an .exe). If you do that you'll need to set up your own stack before doing a PUSH or enabling any hardware interrupts, or the part of your program at the just-under-64kB mark will get stomped on (I could have set up the initial stack to be at the end of RAM but then we wouldn't have CS==DS==SS like a .com file does).

There's no keyboard, mouse, disk, serial, parallel, CGA, speaker, DRAM decay or host interface yet. There's partial PIT, PIC, DMAC and PPI (just enough to get accurate timing for the tests that I've written so far).

So, CLI HLT on 60:FF? Where's the executable loaded? And the initial stack SS:SP?

superfury wrote:

So, CLI HLT on 60:FF? Where's the executable loaded? And the initial stack SS:SP?

The executable will be loaded at 0060:0100 with an initial SS:SP of 0060:0000. It doesn't matter what instruction is at 0060:00FF, that's just the CS:IP that emulator looks for to know when to stop.

It's been pointed out to me on IRC that the current version of xtce.exe attempts to load a ROM from a fixed path on drive Q: . This ROM isn't actually used (so the contents don't matter) but the test harness that I was previously using this emulator inside of needed it to be there so that certain invalid opcodes (which caused CS:IP to end up in ROM space) worked the same on the emulator as on the real hardware. If you don't have a Q: drive one you can create one with something like "net use q: \\localhost\c$\Users\Me\Documents\q" or patch the binary to look at a drive you do have. I will fix XTCE when I can, but it might be a couple of weeks before I have time.

So:
- SS:SP = 0060:0000
- CS:IP = 0060:0100
- 0060:0000 = 00FF
- 0060:0002 = 0060
- 0060:00FF = terminate once reached.
- DS=ES=0060
- Physical memory address 0x700=Executable base address
(- FLAGS=0002)

Is thal correct/all?

superfury wrote:

So: - SS:SP = 0060:0000 - CS:IP = 0060:0100 - 0060:0000 = 00FF - 0060:0002 = 0060 - 0060:00FF = terminate once reached. - DS=ES= […]
Show full quote

So:
- SS:SP = 0060:0000
- CS:IP = 0060:0100
- 0060:0000 = 00FF
- 0060:0002 = 0060
- 0060:00FF = terminate once reached.
- DS=ES=0060
- Physical memory address 0x700=Executable base address
(- FLAGS=0002)

Is thal correct/all?

Right. All other registers are initialised to 0.