I've also been working on it in the background;
so here is what I know;
Phar Lap compiler does its own virtualization, so everything you
see with respect to interrupts becomes virtualised (all those
random memory references are actually holding information
about register states before/after interrupt.).

Im not sure, but I think it second guesses us on quite a few points;
ie if EMS is enabled, it allocates all the space, deallocates it with its
own method, reallocates it with its own method deallocates it with
our method etc.. which is why we are always out of memory enabling
EMS.

Sounds like you have been getting further though, I have yet to pass
the Interrupt error message. Dosfreak claimed to have an intro screen
up and running (with then "latest CVS", message dated 1/1/2k4)

Online RalfBrown Interrupt List - (Was wondering if these might help:)
http://www.delorie.com/djgpp/doc/rbinter/ix/21/25.html

Also from memory Phar Lap was the team that almost single handedly
developed VCPI. (Which later was 'absorbed/altered'(?) into DPMI).

Heres a snapshot of some notes I'm working on with regards to
getting EMS & Crusader.

If you already know the tabled registers and pushed constructors
you can ignore this one. (Where table[BP+x/2] = AX,BX,CX,DX,SI,DI).

[Suggested debugging to the beat of "Love Hina - Sakura Saku" (think Lemmings)]

IS this a typo in EMS.cpp ?
#define........EMM_MAX_HANDLES........100......../* 255 Max */
shouldn't it be
#define........EMM_MAX_HANDLES........0x100......../* 255 Max */ ?
----------------

Looking at how INSTALL works, (flooding the EMS to capacity, then
testing free memory), I suspect that the 0x255 to port 0x64 might
be a request for the CPU to swap to disk.
btw Int 2F: 4300 = Get HIMEM.sys installed,
.................4301= Get Himem.sys entry point.
................(1600-1685 = windows extensions).

I've measured how many cpu cycles it takes from the counter at 0F8F: 0040 intialization to counter test in dependepce to dosbox's cpu_cycles:

Dosbox cycles...................cycles length
600.................................620,000
4050..............................4,2 million
8500..............................8,7 million
15400.............................16 million

behavior is linear and factor is about 1000.
Dosbox's "cycles" is number of instruction per millisecond performed, right ?
This means that Crusader waits 1 second for interrupt to change counter!
(Probably does the speed measuring before with the help of timer interrupt?)

I did some debugging under plain DOS. My results:

• The "increase counter" (01D7:0065) function IS called.
• The function is called at 0377:19A9. At that point, one pointer is picked out of the function table. The call is part of a function that begins at 0377:1913. This function is called a few times in DOSBOX but it always picks other functions.
• The "pick function" (0377:1913) function is called from 0367:2CB7. Unfortunally, that address is never reached in DOSBOX for reasons still unknown.

Erk. 250mb if anyone wants the snapshot log from around just before
the XMS page deallocate and the dos prompt. (Guestimate ~4gig for the full snapshot). (Logging XMS adds a whole new dimension .. ).
Stats ~16 seconds realtime = 16hours HeavyLogging time.
(And I only started logging in the last hour!)

I am curious about those missing FPU instructions; if anyone can decipher
what they mean into something I can cross reference eg "FWAIT"; at least then I can test its none of those.

Anyhow there are a lot of disconnected FPU statements;

0017:00006D1E push es
0017:00006D1F push bx
0017:00006D20 mov es,[bp-02]
0017:00006D23 mov bx,[bp-04]
0017:00006D26 fwait
0017:00006D27 db 26
0017:00006D2A pop bx
0017:00006D2B pop es
0017:00006D2C leave
...
0017:00009C86 cmp byte es:[4842],00
0017:00009C8C je 00009C8F ($+1)
0017:00009C8E fwait
0017:00009C8F mov word es:[4846],00

Are these purely because the simulator choked on the instructions;
or are we mis-decoding something?

(Also is our memory "safe", the PharLap stuff grabs EVERY available page)

Someone might like the flow of ints .. this is run with XMS enabled,
(logging just before the 6th last PIC event.)

Srecko: Yes, at appears you may be correct;
unfortunately DOSBOX doesnt log time real/otherwise, but if you take
a look at the INT-Snapshots (attached above) you will notice a pattern
with the XMS page allocate and otherstuff, followed by
INT 8, and INT 1C; (Time related).
It appears Crusader uses these quite a bit, and then "gives up".

As you point out, we could link timer ticks to "dosbox time"=cycles/1000.
Will try that later.

he, got "no regret" to work with a little hack. for some weird reason it seems to test the interrupt vector 0... if the low byte of the offset is set to 0 it starts up correctly... "no remorse" got past the interrupt error too but exits later with another error... i wonder what that test is for... could be a bug though 😀

start dosbox, enter debugger, press enter
type : sm 0 0 0
start crusader

the test is performed at 0367:2B37

I think you mean no remorse that works with the hack, no regret still errors. Great progress though.

Please disregard my previous mumblings, they were directed at
CRUSADER: NO REMORSE;

Thanks

How do you enter the debugger mode?

Dosbox.Guide.Debugger:
Guide to the DOSBox debugger

Good news everyone ! Finally I fixed the problem. Pharlap extender wants the indos-flag in a low memory segment (it was located at 0xD000 in dosbox), so I moved it a bit...
Besides this fixed the ultima 8 intro too.

Thanks for all the help 😀

Wow, that's great news Finster. How many FPS are you getting during gameplay?

Cool indeed 😀

Oh well time to move on 😀

ehm finster i did try to move it to a low segment but it didnt work ?

from dos_tables.cpp

1void DOS_SetupTables(void) {
2	dos_memseg=0x00A7;
3	Bit16u seg;Bitu i;
4	dos.tables.indosflag=RealMake(DOS_GetMemory(1),0);
5	dos_memseg=0xd000;
6	dos.tables.mediaid=RealMake(DOS_GetMemory(2),0);

or am i doing something completley wrong ? (altough ES seems to point to A7 after the interrupt)

tkcmd wrote:

ehm finster i did try to move it to a low segment but it didnt work ?

yeh, that probably wont work, cos the dos memory allocation overwrites it again (starts at segment 0x60). Use the cvs or remove the old lines reagarding indos flag and add the following :

1	dos.tables.indosflag = RealMake(0x5f,0xf);	
2	mem_writeb(Real2Phys(dos.tables.indosflag),0);

that did the trick
but here it looks that the cvs hasnt been updated for over 2 weeks
is that normal ?
Or is anonymous access not beeing updated atm?