Well, 0.63 is out and pretty much nothing has changed.

Nevertheless, I did find out that in 0.62 if you have cycles>=30000, then you get as far as the first intro screen (out of three) and only then it gets stuck.
In 0.63 the same thing also applies...but only if "core=dynamic".
This goes for all of the parameters.

Anyway, I tried another approach and replaced DOS4GW with DOS32A.
As far as 0.62-3, if I now specifically use "core=dynamic", I can then use the normal default cycles (3000) and then get as far as the second intro screen before it gets stuck.
Once again this goes for all of the parameters.

But as for 0.61...DOS32A made the sound finally work!
This was the first time I've heard that game's sound in years!
For some reason, though, you must supply the parameter /s:sblaster (originally the game auto tested for sound) which means your choices for parameters are:
1) none => the game gets stuck in the third intro screen.
2) /s:silent => disables sound, but when you exit the game you get the message:

1DOS/32A warning (9003): real mode interrupt vector had been modified: INT 70h

3) /s:sblaster => sound works, but when you exit the game you get the same message plus:

1DOS/32A warning (9003): real mode interrupt vector had been modified: INT 72h

yes tried it myself. I would guess a timer problem. But didn't look that deep.

Ok, here goes...

In 0.63, if I:
1) I use DOS32A.
2) The conf has "core=dynamic".
3) I specify just enough cycles to reach 100% cpu usage (but NOT more!) - you can, of course, lower it after the game has successfully loaded.
4) Use absolutely NO parameters (not even /s:sblaster).
Then it works...

Now it's not perfect. Sometimes, it gets too fast (e.g. you move left and can't stop it) or too slow (pauses completly and one second later unpauses).

But nonetheless, it works! Yes, with sound!

Of course, now it can't use the modem (can't select the COM port)...

In 0.65 the only difference from v0.63 is rule #3 requires like 20% instead of 100% for some reason.

I'll repeat the instructions for your benefit:
Ok, here goes...

In 0.65, if I:

1. I use DOS32A.
2. The conf has "core=dynamic".
3. I specify just enough cycles to reach 20% cpu usage (but NOT more!) - you can, of course, lower it after the game has successfully loaded.
4. Use absolutely NO parameters (not even /s:sblaster).

Then it works...

Yes, with sound!

Also, modem mode works once again, but it gets stuck randomally.

It worked better in fullscreen some time ago.

The timing problem is still not solved.

After searching around, I've tried more than one set of instructions to get Archon Ultra to work, but have been unsuccessful (including using a conf file posted by someone who said it should work).

My game directory consists of the following:
ARCHON.EXE 499805 8/8/94 9:43AM
ARCHON.PKG 2902220 1/21/94 7:26PM
TITLE.PKG 1018308 1/6/94 6:29PM

I tried getting things to work with and without patching the ARCHON.EXE with DOS32A (to ARCHON1.EXE), but neither works.

Does anyone have this working in 65 and if so can you tell me what to do.

Your files' sizes and dates are perfect.

My latest post with instructions works without a scratch for me in v0.65.

But you must use DOS32A! What's the big deal? Just save a backup of the old archon.exe .

Read DOSBox'a WIKI item about DOS32A which would take you hand by hand through patching archon.exe .

And there's no such thing as archon1.exe .

I got it to work, but then I got sick and forgot to followup here.
Basically, the emulator needs to be given enough cycles - you DO NOT need DOS32A or core=dynamic.
I kept upping the cycles in increments of 1000 until it worked.
At 20000 the game functioned without further tweaking to the default DOSBOX conf.
As an interesting side note, setting core=dynamic got it to work with fewer cycles, and using DOS32A also lowered the amount of required cycles. But why do these when simply upping the cycles to 20000 does the trick?
PS. With both core=dynamic and DOS32A the game still needs about 12000 cycles to run.

I was going to say it's still better to do this but you did it for me with your side note. Besides, who knows what else it improves. Why not improving the game when you can? I apply DOS32A to every game that has DOG4GW.

The fact that it's 12000 cycles for you (and 5900 for me) is exactly the reason I used % and not whole numbers.

That is odd that 5900 works for you.
I thought a cycle should be the same no matter what the host computer.
How much of your host CPU is taken to emulate a certain amount of cycles is the thing that should be different.
In other words, if you have a P4 2GHz and I have a P4 3GHz and we both set Archon to consume 12000 cycles, it should run exactly the same since we both game the game 12000 cycles. Your computer would consume more CPU to achieve those cycles as it's less powerful.
Or is that not how "cycles" works?
Comments anybody?

Qbix has said in the official bug report about this game that it was finally fixed.

So first of all, hooray!

Secondly, when's that "upcoming new version" that was mentioned?

And thirdly, what exactly was fixed?
INT 70h (I forgot to say I don't see INT 72h ever since v0.63 in which I stopped using the parameters)?
The modem getting stuck randomally?
Having to play with the cycles to bypass the startup screen?

Whatever was fixed, I think it's still better to use DOS32A and "core=dynamic" (which if I'm not mistaken always should always accompany DOS32A).

Some system timer stuff got fixed. It will reliable start with up to around 20000 cycles with some dead gaps in between.
I always used dynamic core when testing but never DOS32A.
The modem should still get stuck.

The modem should still get stuck.

?

?

The modem stuck state has not changed.

!
!
!

A serial port bug that could cause random lock ups is still in CVS. Don't know if the game is suffering from that bug though.

0.70 is out and I'm sure everyone waited impatiently for my yearly update of this topic.

So it's like this - with the new defaults of core=auto and cycles=auto, the game works with all or none of its parameters (none, if you forgot, should use sound just the same)! Hooray!
Alas, no matter what, now on exit I always get:

1DOS/32A warning (9003): real mode interrupt vector had been modified: INT 70h

Also, it works directly now with or without DOS32A (I still see no good reason not to use it though), although it seems if I use "core=dynamic" directly (how do I know if it uses it when "core=auto"?), then it once again requires the %20 increase in cycles (5900 cycles in my case) in order to get over the intro screen.

Last but not least, modem play finally works (even with port 23 in XP)!

I've also discovered a stupid bug in the game itself - after you connect and everything is fine, you and your partner better have decided in advance (there's no chat...) who gets the first move. If, say, one of you selects the dark side to start and the other selects the light side to start, then both computers ignore the connection and just start a local game (which, I guess, is at least better than getting stuck).

Alas, no matter what, now on exit I always get:

Um yes, and? If you don't like that warning stick to dos4gw.

Come on, I only wonder if this symptom means something is wrong.

Well int70 has been modified. Shouldn't matter.