Safe Mode DOS Prompt Only

Push F8 and select "safe mode dos prompt only", then start up with a batch file, but i can't find a way to initialize the pci soundblaster, e.g. the pci port, so I'm running silent or with pc speaker, for the moment. It's some 50 kb short of conventional memory in Windows / exit to dos, for to execute, I think it's something with the auto double buffer, and no way to expand it found yet.

149 kb of the total 640 conventional memory is occupied in some core boot process and can maybe inflict damage on my system, if reconfigured.

Well it's some penalty having a soon four year old system, with close to 2,500 applications installed, now on its third motherboard, that never have been reinstalled, or given up on me.

One can wonder, the program should technically ececute in the 512 kb L2 cache of my processor ! as it now works with up to 4 Mb's page size !! and its no easy way to expand / re allocate conventional memory space.

Fantastic,,,, or simply Microsoft ??

This "safe mode dos prompt only" trick can maybe be of use for other old dos proggies.

More On Soundblasters Absence In DOS...

As I promised to come back in the event of my soundblasters absence in dos,,,

It's fixed, but the remedy is machine specific so it can only be applied on my and identical machines.

The tip you can forward to eventual Q's by others is.

They shall install full dos support for their sound blaster in Windows, then open dosstart.bat, normally residing in their Windows folder and autoexec.bat,

Then copy the sound blaster initiation strings from autoexec.bat and dosstart bat to the batch file used to boot up to a wolfenstein friendly dos environment.

Problem Solved

The following lines in config.sys did it, now i have close to 600 kb of conventional memory on my full Windows boot, and all wolfenstein / spear exe's run without any problems.

With exception for some TC compiled wolf3d exe's that probably induces floating point errors on my PIII ATC2.

No one of the "multible level selection" TC compiled wolf3d.exe's have work'd on my machine, either they latch or run in extreme slow motion

DEVICE=C:\WINDOWS\HIMEM.SYS

DOS=HIGH

DOS=UMB

DEVICEHIGH=C:\WINDOWS\EMM386.EXE AUTO RAM

+ loaded the cd rom driver 'DEVICEHIGH" recommended to make that with all drivers launched from this file.

Took for granted that emm386 loaded high by itself,, but not so even in the most recent dos versions, mysterious as the whole "OS" e.g. a statically launched virtual machine commonly named windows 32 depends on dos as the kernel is a thunk'd 16 bit app, MS is seemingly most devoted to make graphics one can click on.

Well...

This rised some thoughts about the wolf3d exe,,, as it's an awesome task to rewrite the assembler part of the code, while the c part relatively easy should compile with bcc32 or Lcc in 32 bit mode, that is to link the asm files ti a dll or a library making relatively few modifications, then link the final 32 bit exe to the 16 bit asm generated code. Most a matter of finding time + inspiration.

As you had the source code at one of your sites i assume that interest can exist for an IDE that works for Bcc32 / tasm (32/52) / Tcc / Bcc + gcc and Sun Java to some extension.

I assembled the V IDE executable on the basis of Bcc32 generated assembler mnemonics + added make file generation for assembler projects + a absolute complete syntax hlg for the just over 1000 intrinsics of all tasm's.

Also added full duplex TLS so it's possible to run a lot of copies of the exe at the same time, don't know the limit on a high memory machine, never had need for more than 20 at the same time, the program is close to fully independent, and works directly on the cpu under / with its own locally thrown T hread L ocal S torage databases.

The program has never crashed, it choked once while i tried to open 180 c source files of a class libray at the same time, it's not complete, a bit ugly in it's gui interface but very useful, and rock stable.

If interested, then you can download it at http://spiff.tripnet.se/~iczelion/files/vide.zip its just a bit over 700 kb / not a foundation abused code hog, containing some sample project files for tandem c(++) / Assembler programs.

The original c++ source was made by Bruce Wampler, http://www.objectcentral.com/ where a lot of fundamental documentation is available.

One other soft widget that is useful is BOCHS at http://bochs.sourceforge.net it's an emulator that enables almost all operational systems to run in a window on almost whatever source boot.

Personally tested linux on my W32, and it runs as a train, not extremely fast but reliable, on its own disk image, without any additional boot records.

Hope the "tip" with config sys can be of use.

New Wolf 3D exe DOWNLOAD

It slows down general performance, and is only useful if running the program under Borlands turbo debugger. It's just to go to the TC ide and uncheck, menu item: options / compiler / advanced code generation / debuginfo in obj . Or, if running a make file either take away the -v or /v compiler switch or add a - behind like -v- or /v-.

The raw uncompressed exe shall only be some 350 to 370 Kb and will perform realtime. Preferrably, also check fast floating point and fast huge pointers located in the same menu.

The thing with Wolfenstein / Spear is that it's the only game of this type able to respond to maximum reaction speed. Quake / Doom / Duke Nukem / and so forth have to much irritating inertia, even on super fast machines.

I did original Spear of Destiny at 28 minutes if remember right, but not now takes some exercise for that.

Now as downloaded an array of worlds from your site, not knowing if the c code are changed or not, and hence reluctant to replace the original exe's full with turbo debug info, please inform your friends to recompile their exe's.

The package will turn leaner and faster, ++ as the exe becomes more explicit, disables save game corruption / differences between essentially similar executables that I've seen now and then.

Some additional compiler info.

As of the TC wolf3d src package, the add debug info was checked simultaneously with the optimization switches.

This is generally not to recommend, in the first place,, optimization will / can not take place while compiler generates debug info in the obj files.

Optimization switches activated in debug mode can instead generate "spurious pointers" in the final executable.

This explains, to a great part why essentially similar debug mode compiled Wolf3d exe's save the games in slightly differing formats.

I tested my optimized exe with the save game files of the Iron wolf package, and all worked as this exe also was optimized ,without debug info.

It's compressed with the same compressor as the original Wolf3d's LZ exe by Fabrice Bellard, highly opimized for 16 bit dos.

My exe is compressed with UPX that is optimized for 32 bit exe's, hence the slightly larger format.

Both are 100% compatible, due to being generated without obj debug headers.

Hope this will add undertanding to my remarks about debug mode executables as when done with optimization switches enabled instead can cause problems.

No Debug Headers DOWNLOAD

Just thought of the fact that not so many have Tasm installed,and that Assembler is quite tricky.

Sending you the optimized obj files with no debug headers.

Its just to extract to the obj folder of Wolf3d src and recompile changed source files, with debugswitches off / optimization on, and then link to the ececutable.

Enclosed general tips in the zip file.

The older files are not optimized, as I don't have the source / no time to make a full disassembly of said obj files.

They make no difference, just a slightly larger exe, compared with the original.

PIF icons DOWNLOAD

The pif icons, are not so nice with the ones in pifmgr.dll, so I send you some more appropriate that I've cut out / edited, from a variety of sources.

Final remarks....

My critics of the wolf3d compilations, I'm very itchy about such, as code perfectionist.

Just passed my critics, in consideration of that one can't have knowledge of everything. and compiling / assembling is a science itself. In the case with Wolf3d, its very simple measures needed to make the perfect exe, as the source is a masterpiece.

The implemented switches have generated an exe, that on my machine, never fails,now used for all sets with exception for some with extensive source code changes, that I dont have access to.

I have "reswitched" / tweaked codes by several professional programmers before.

It's very easy to forget tuning of the engine, when applying due diligence on the actual code, not for to talk about the very special knowledge needed for said tuning.

Especially with Borland Assemblers / Compilers, as all components are generic and even can call themselves during process. Never compress a Borland make or compiler / Assembler, or attempt to run it with a non Borland make.exe.

P.J.

Wolf 3D Quirks Tuned-Tc Obj.zip Wolf3D-No-Debug.zip Wolf3-d.zip

As the code of Wolf3d is quite complex, and takes some inspiration / transpiration to go through....

Here is the remedy for a final solution, to create a foundation to expand the code, and make it applicable even for today's L2 cache multi ghz ATC2 processors.

Executables compiled according to this implementation are rock stable and very explicit in their object handling.

This application have been tested on Totengraeber and Megademo sourcecode with phenomenal result when it comes to program stability. On my 0.18 um PIII ATC2, that uses the same L2 cache as the PIIII series.

ID_SD.C and ID_CA.C, compile to functional obj files, with tasm5 inline / Bcc 3.1 when disabling automatic far data / fast floating point and fast huge pointers.

Just to make a batch compile with a dummy project renamed copy of original project file, not implementing those switches, and save D_SD.obj and ID_CA.obj to a storage folder.

The rest of the switches shall be implemented for the main exe project, and recompiled with all mentioned switches implemented, but linked with the dummy project generated ID_SD.obj and ID_CA.obj.

Above mentioned switches are of great importance for a harmonic executable that suits a huge array of processors even PIII / PIIII ATC2 ones, but simply don't work with the inline assembler of above mentioned files.

If I find time / inspiration then I will rewrite the inline ASM of these files.

This contemporary remedy works exquisitely, and for the Tcc 3.0 that is identical to Bcc 3.1 the enclosed optimized / Tasm 5 assembled / Bcc 3.1 compiled ID_SD.obj and ID_CA.obj, can be used.

The only difference between Bcc 3.1 and Tcc 3.0 is that the former is a windows development platform including all headers / foundations to generate / handle 16 bit windows API calls, while TC++ strictly is a dos dev platform. They are using exactly the same prj file format, or,, Bcc 3.1 was adopted to the Tcc 3.0 prj file format.

I can't take this further.

And everything points to a final solution for the creation of source code expansions.

With my Best !!!

Peter Johansson

Click BACK to return