Null DooM, GCC 1.39, GO32 and DPMI


phew.

DooM via DJGPP v1 GO32

Around the time of the x68000 port of DooM, I was cutting down the DooM source for a null/portable version.  I never could get it to actually run either using EMX or  DJGPP 1.03, as I couldn’t get it to link to save my life with a constant never ending battle of unresolved symbols. After a while I just used what I had towards the x68000 version and concentrated on getting it up and running, and just shelved the null/portable effort.

Later on I wanted to get it running again as part of messing with another cross compiler, as DooM isn’t a trivial application to port and verify correct operation. And in the process of trying to get the null version to build and run on Windows using TDM GCC, I wanted to make sure it at least kept compiling with GCC v1.x.

Once more again I was able to compile individual files but unable to link.  But this time, I just looked at the diffs for binutils, I thought it should be somewhat easy to get hosted on Windows.  Although versions may point to binutils 1.0, I had to use binutils-1.9.tar.gz even though the diffs are against Mar 24 1991, and the source for 1.9 is dated April 17 1991.

My first effort gave me a linker that would happily link, but go32 would either refuse to run the executable, or just crash.  I was going to give up again, but I found mention in another file that DJGPP actually uses the linker from G++, the C++ compiler which was a separate thing in the late ’80s and early’90’s.  This time it worked, and I could link a trivial hello world style application!

Now that I finally had a cross linker actually working, I didn’t want to compile under emulation, so looking at the other diffs, they didn’t look too extensive. I went ahead ,and took DJGPP v1.06 and patched up the compiler & assembler to get a full cross toolchain.  And in no time, I had a null version of DooM running on MS-DOS well at least tested on DOSBox.

This was fun, and all but I didn’t see any easy way to do fun things like hook interrupts so I could get the keyboard & clock like any good MS-DOS program.  DPMI greatly eased this kind of stuff, so looking at the DJGPP history, DJGPP v1 version 1.10 actually adds preliminary DPMI support!  And in the next version, DPMI was much more better supported, however the binary format had changed from a.out to COFF as part of the move to v1.11. I was able to take the memory, and DPMI portions from the final v1.12 libc, and manually build and run them against the v1.06 library / dev tools.

And much to my surprise, it actually worked!  At least having the wrong format didn’t have any effect on how GO32 worked for me.

So feeling lazy, I snagged some of the support code from Maraakate’s revamp of DooM, just to make sure of the timer code, and the keyboard code, and again verified that I can build with the keyboard & timer ISR and I’m able to play the v1.9 shareware & commercial levels fine.  I haven’t done a thing to clean up or update the DooM source itself against all the dozens of bugs and issues with Ultimate DooM, or other games like Chex Quest etc.

I’m sure 99% of people wouldn’t care but you can download it here:

Win32_DJGPPv1_DooM.7z
Download crossdjgppv1

Although I’m using DPMI to drive realtime events, if I looked further at the GO32 v1.06 environments I could either figure out how it operates it’s timer, or modify the extender directly to drive the PIC timer and keyboard as I need.  But overlooking that, the vintage 1991 software is more than capable of running DooM.

Wolfenstein 3D for DOS/4GW update

If you remember a while back, I had found the ‘missing link’ of Wolfenstein to Wolfenstein SDL, Wolf4GW.  Well Tobias has cleaned it up somewhat, and now it compiles on the latest builds of OpenWatcom 2.0c!

The first thing you’ll notice if you try to compile it, is that now it’s a single source file, that includes all the other modules.  And it compiles FAST, for me 1 second fast.

From the changes:

  • Compiles with OpenWatcom v2.
  • Keys (for Run, Shot…) are shown.
  • Hang with optimization is fixed.
  • Missing Spear of Destiny SignonScreen added.
  • Inter-procedural optimization (unity build).
  • External assembler routines re-implemented in C.
  • Better interrupt enablement /disablement.
  • Dead Code removed or #ifdefined.

So, if you want to Wolf3d, or SPOD, I’d check out Tobias’s Wolf4GW if you have a 32bit capable machine.  The maps load instantly, and it just feels all around much more smoother than the old 8086 code.

Porting Quake II to MS-DOS pt4

Bringing it all home for release day.

Bringing it all home for release day.

Since the last update we got some help in a few fields that have really fleshed out this ‘experimental’ port into a full fledged port.  First RayerR helped us with the fun of getting us onto the latest deployment of DJGPP, 2.05 (rc1).  It’s always nice to be in the latest available release.  Next in a passing comment, Ruslan Starodubov had mentioned that he had gotten a much older build of our QDOS to support the Intel HDA sound chipset via the  MPXPlay sound library.  I wrote to the author of MPXPlay, Pádár Attila asking for us to distribute his source in our project, and he granted permission.

So at this point things were looking good.  The only ‘feature’ that modern OS’s really held over us was the ability to dynamically load and unload game modules on the fly.  I had tried to use DLM, but it stripped the DPMI functionality out of the MS-DOS Extender making the port really useless.  I tried to build the newer DXE3 support but had no luck.  I suspect now my native tool chain was interfering with the build process. But Maraakate managed to get it to not only build, but to run!

Adding in DX3 support was relatively painless.  I first looked at DJGPP’s FAQ and downloaded the example code.  In the example code there was small helper functions to make unions and check the symbols.  If they didn’t exist a printf was spit out to alert you about it.  To resolve the issue you simply just add DXE_EXPORT to the other list of missing exports.

Compiling the game code was easy, again referring to the example I saw that basically they compiled it the same, but at link time you use DX3GEN and -U flag to ignore unresolved symbols.

The biggest head scratcher was the Sys_GetGameAPI failing to find GetGameAPI from the DX3.  After some piddling around I noticed that it listed GetGameAPI as _GetGameAPI inside the DX3 itself.  I added the underscore and it worked!

Other things that were relatively to easy to import was R1Q2’s HTTP downloading code.  Compiling CURL was kind of tricky because of the linking order, but thankfully neozeed figured it out quickly.

All of Yamagi’s Quake 2 updated game DLLs were all diff’d by hand using BeyondCompare to make sure I didn’t clash using some newer functions that weren’t available in DJGPP.  I also merged their Zaero code with their baseq2 code by comparing Zaeros code to the Quake 2 SDK, marking every thing that was changed.  The result is a really stable Zaero game code.  If you haven’t played Zaero check it out.  I think it’s a lot better than Rogue, but Xatrix is probably my favourite (even over stock Q2).

Other cool things I’m glad to get into the code was the GameSpy Browser.  It took me quite a bit of work to get it where it is, but it’s really nice to just be able to ping to a master server (a custom GameSpy emulator I wrote specifically for Q2DOS.  Source is not finalized yet, but will be available soon for those curious), pick a server and go!  All in DOS!

So here we are at the end of the journey.  Or at least safe enough for a 1.0 release.

To recap, we have:

* VGA
* SVGA (LFB modes only)
* Mouse
* Keyboard
* SoundBlaster and Gravis UltraSound Family
* CD-ROM music
* OGG music
* Networking (You need a packet driver)
* Loading/unloading game DLLs in DX3 format.
* Intel HDA support -hda
* Mouse wheel support with -mwheel

And I should add, that it works GREAT on my MSI Z87 motherboard.

You can download Quake II for MS-DOS on bitbucket.  And as always the source is available here.

Don’t forget you can always make bootable USB stick with DOS, or CD-ROMs.

Continued in Part 5!

Wolfenstein 3D for DOS/4GW!

After reading about the Blake Stone compile fixes, as it was a Wolf3d port, I came across a post on the forum Wolf3d Haven about trying to find the source code to something called wolf4gw.  Now wolf4gw is a port of the Borland C source of Wolfenstein 3d to Open Watcom C++‘s 32bit MS-DOS extender DOS/4GW, done by ‘ripper’.

The project eventually gave way to wolf4sdl, and as they say the rest is history.

Sadly it seems that just about all the source copies of wolf4gw were lost, except I did manage to find an ‘improved’ version simply refered to as wolf3dx.  From the blurb:

Tricob has released the Wolf4GW-based source code of WolfDX. Included is a text file called (Tricob).TXT.

So I have been using Watcom 10.0 for Duke Nukem 3d, however, this version relies on the _asm inline assembler which was introduced in Watcom 11.  However Watcom 11c had issues with some of the assembly forcing me to go even further to OpenWatcom 1.3.  For me the install was easy, I used CrossOver to install OpenWatcom for DOS-DOS32bit only, copied the compiler into DOSBox, and played mostly with the makefiles, and finally got a working exe!

Screen Shot 2013-07-12 at 11.57.24 AM Screen Shot 2013-07-12 at 11.58.00 AM

I know it may not look like much, but really it is running in 32bit protected mode!

Since all of this is open/freeware/shareware I can redistribute OpenWatcom, the source to wolf3dx, and the shareware levels of Wolfenstein.  Naturally I’m using DOSBox to compile and test, but you can use anything that can run MS-DOS 32bit stuff.

Download my archive here.

DJGPP 1.03 saved thanks to shovelware + cd.textfiles.com

I can’t stress enough just how awesome cd.textfiles.com is for finding ancient stuff!

I’m not sure why I started on this quest but I was looking for some old finicky DOS extender, and started hunting for Go32, the first DOS extender used by DJGPP.  And for the heck of it, I wanted to find the first version, which I pretty much had assumed was lost to the mists of time.

However the CD-ROM shareware collection called MegaROM-1 actually had a ‘full’ copy of one of the first versions of DJGPP, 1.03.

Installation is pretty straightforward, however you have to use pkunzip for all the various old ‘methods’ of storing data in zip files, I found infozip leaves things out..

Also DJGPP 1.03 uses a LOT of environment space.. which is more so a problem for people running real MS-DOS on real machines.. (there are some!)…

Hello World!

It runs in DOSBox, but there is no doubt some stack corruption as trying to run things like dos edit result in:

Packed file is corrupt

But at least we can run more than one copy, or use a native editor.

GO-32 from this era is *NOT* DPMI compliant, nor is it VCPI compliant.  And its based on GCC 1.39, which was a popular level with things like 386 BSD, although it seems early Linux used GCC 1.40 ..  The tool chain by default outputs the GNU a.out format, but relies on modifying the linker that was separately included in G++.  Later versions of GO32 included VCPI support, and near it’s end of life version 1.10 added support for DPMI which greatly simplified things like hooking IRQ’s and doing DMA.

For those who want to play, without the pkzip fun, I’ve slapped it into a single 7zip file.  It’s not even a megabyte.  But it was 1991, when 4MB of ram seemed like an incredible amount of memory!

Quake & QuakeWorld for MS-DOS update

So after a year+ of inactivity I’ve spent some time with Quake (netquake) and QuakeWorld for MS-DOS.  I had modified it to support the WatTCP stack for MS-DOS, allowing you to play over the internet with any MS-DOS PC with a packet driver.

After a good bit of prodding and playing with DJGPP I’ve updated everything to include some new tweaks for a malloc ‘bug’ (Quake assumes the memory is clean, which under DJGPP it isn’t) some limit increases (zone to 1MB, and increases in max edicts, models & sounds), and forcing the sound to 22050Hz.  The source code is now here.  As much as it pained me, I built it with this DJGPP under MS-DOS (On Qemu) and I’m keeping it here, as gcc 3 & 4 are incapable of building a working WatTCP or Quake.

Another big fix for QuakeWorld is that it now can run in 640×480, 800×600, and even 1024×768 if your video card is VESA 2.0 compatible!!!

Basically you can just replace the default exe’s in a Quake1 install and go from there.  If you do not have quake at all, you can always look for the shareware version.  QuakeWorld will require the commercial version for what it is worth. I’ve found it runs best with 32MB of ram.  I don’t know if that is even an issue in this day & age.  Quake1 will run in 16, but I have a feeling QuakeWorld runs in VM (thanks to CWSDPMI) and it does say it is using 32MB … Because I clear the ‘zone’ before Quake runs there may be a 30 second to 1 minute pause.  This is to be expected, just hold tight.

QuakeWorld at 640x480

QuakeWorld at 800x600

QuakeWorld at 1024x768

You can download either Quake.exe or Qw.exe.

Thanks to [hci]maraakate, for the hints on what to update where, and of course the testing on a ‘real pc’!`

Some history on DPMI

This is taken from a post by Michael Sokolov (of Quasijarus fame), all about DPMI.

   Mark H. Wood <address@hidden> wrote:
&gt;<em> Which spec is that? cwsdpmi, as I recall, implements DPMI 1.0, while</em>
&gt;<em> Microsoft has never gone beyond 0.9. There are significant differences</em>
&gt;<em> *in the spec.s*.</em>

   Well, I have turned this semester's last paper in today, so I can spend
a few more hours enlightening the public... Warning: I am going to give a
lecture on DPMI. Feel free to skip this message, but if you do please
refrain from any further participation in the work on Lynx for DOS, since
an understanding of the material I present in this lecture is absolutely
essential to doing any work under DOS beyond 640 KB.

   DPMI has been born in the fall of 1989 in a bright flash of genius of
Microsoft's Ralph Lipe. At that time there was a flourishing DOS extender
industry led by Phar Lap, Rational Systems (later Tenberry Software), and
Ergo (formerly Eclipse and A. I. Architects). A DOS extender is some kind
of software solution (they come in all sorts of flavors) that allows an
application to execute in protected mode and yet retain access to the file
system and other services provided by DOS via an API that closely resembles
that of real-mode DOS (INT 21h and such) but with pointers to buffers and
such addressing memory outside the first MB via protected-mode selectors.

   DOS extenders from Phar Lap, Rational Systems, and Ergo are inherently
flawed in that they are built into apps. This has been done against all
rationale simply because the market demanded that a protected-mode apps
must not have any prerequisites and must run even in a bare environment
without any pre-existing protected-mode software. However, having a
separate DOS extender for every app is not much different from having a
separate power plant for every light bulb. Since they want to have no
prerequisites, these DOS extenders need to take the total control of the
CPU and build their own protected-mode environments. Of course, this
creates a hell of a problem when a machine IS running some protected-mode
software. In the days of Phar Lap and friends, there were two other kinds
of the latter in addition to DOS extenders: LIMulators and multitaskers.
The former are things like CEMM and EMM386 that provide LIM EMS services by
setting up a protected-mode environment and mapping some extended memory
into the UMB space. The latter provide multiple simultaneous DOS sessions
and allow the user to switch between them instantly. They do so again by
setting up a protected-mode environment and using to it manage several
different VMs. The result was that by 1989 there were three kinds of
protected-mode environments (LIMulators, multitaskers, and DOS extenders),
and all three were, oh big surprise, for the most part mutually exclusive.
There were some feeble attempts (VCPI being the primary example) to make
them live together, but they worked by making one environment totally yield
to the other, which is unacceptable for many reasons.

   Microsoft has entered the protected-mode-under-DOS field in the summer
of 1988 when Murray Sargent and David Weise wrote a DOS extender for a big
DOS app called Windows. Until then this app was running in pure real mode
and was limited by the (in)famous 640 KB barrier. Jumping over this barrier
was one of the primary goals for Windows v3.00. Murray Sargent's DOS
extender did this. It was a quick-and-dirty single-app DOS extender just
like the ones from Phar Lap and others. There was a problem, however. When
all this was happening in the summer of 1988, there already was a baby
called Windows/386 v2.xx. It was another protected-mode environment
developed independently by Ralph Lipe in 1987. It was not a DOS extender,
but a multitasker, and its purpose was to manage several independent VMs,
one running Windows and all others being DOS boxes. Although there were
several VMs, each was running in V86 (real-like) mode only, and no VM had
any ability to jump over the 640 KB barrier, even though each VM had its
own 640 KB of memory.

   Windows v3.00 was supposed to include both Windows/386 (so that it could
have the familiar DOS boxes) and Murray Sargent's DOS extender. There was a
problem, however. The two were mutually exclusive! It was exactly the same
eternal conflict between LIMulators, multitaskers, and DOS extenders that
the industry had been wrestling with for a couple of years by then, except
that the conflicting parties were parts of the same product! Clearly a
breath of fresh air was needed. And it came. From no one but Ralph Lipe,
the author of Windows/386. In a bright flash of genius, he realized that
building a separate DOS extender into every app, be it AutoCAD, Lotus
1-2-3, or Windows, is just as ridiculous as building a separate power plant
for every light bulb. However, getting rid of this kludge required adopting
a new industry standard. Just like in order to have the same power plant
serve everyone you have to agree upon a common standard on voltage,
waveform, and power factor, if you are going to have common protected-mode
DOS services for all apps you have to agree on the protected-mode DOS API.
A logical name for the generic API to the protected-mode DOS was DOS
Protected Mode Interface (DPMI), and it is the name that has ended up being
chosen.

   The specs published by the DPMI Committee and distributed by Intel only
vaguely resemble Ralph Lipe's DPMI. The INT 31h API they describe is only
the low-level building-block portion of Ralph Lipe's DPMI. Its high-level
portion is nothing less than a functional specification for Protected Mode
DOS (hence the name). It allows one to develop an add-on to DOS or even a
new version of DOS that would have a protected-mode API directly usable by
protected-mode DOS apps without the need for separate built-in DOS
extenders. Understandably this troubled Phar Lap and others a lot, since
Ralph Lipe's DPMI makes their products unnecessary. This is the setting in
which the most unfortunate event in the history of DOS has happened. Being
too used to Microsoft's evils, the industry had failed to think the problem
through and sided against Ralph Lipe. Before I continue any further, let me
make an analogy. Suppose a group of doctors were able to cure some dreadful
disease against which there were no vaccine and to which everyone were
prone. Suppose that they charged a lot of money for curing this disease and
made a good living on it. Then suppose that some guy came up with a vaccine
that once injected totally eliminated the possibility of getting this
disease. The vaccine would solve a major health problem, but it would also
push the doctors making great money on curing the disease out of business.
What do you think is more important, sparing millions of people of a major
health problem or keeping a group of lucky doctors in business?

   Unfortunately, the industry has chosen the latter. Ralph Lipe agreed not
to publicize his version of the DPMI spec and to create the so-called DPMI
Committee to write a "public" version of the spec that would please Phar
Lap and the rest of the gang. This Committee was practically headed by Bob
Moote, the vice-president and co-founder of Phar Lap and the author of
their 386|DOS Extender. It has prepared a castrated (deprived of the most
essential component) version of DPMI and released it under the name "DPMI
Version 0.9". It essentially comprises the low-level building-block portion
of True (Ralph Lipe's) DPMI. Fortunately, no committee in the world could
prevent Ralph Lipe from doing the right thing, and the Win386 component in
Windows v3.00+ implements the full True DPMI spec. As a result, DOS apps
running under its supervision (e.g., Windows itself) have immediate access
to Protected Mode DOS without built-in DOS extenders. Since this is the new
proper and vastly improved way of writing protected-mode DOS apps (sure
enough, Microsoft itself has used it in its C/C++ Compiler v7.00), Win386
rightfully does not support apps with built-in DOS extenders using kludges
like VCPI. Thus Bob Moote and his gang have made their version of DPMI a
subset of True DPMI rather than a completely different interface, so that
their DOS extenders could run under Win386.

   It is a very unfortunate fact that since Ralph Lipe has agreed not to
send out copies of his True DPMI spec most people associate the name DPMI
with Bob Moote's "Committee". There were, however, a few copies of the True
DPMI spec sent out to people like Borland. It is interesting to note that
the latter company has chosen True DPMI over Bob Moote's creature for their
protected-mode DOS tools. 16-bit Borland C and Pascal compilers are
targeted for the DOS/protected-mode-DOS/Windows triple, and the protected-
mode DOS versions of the tools use nothing but True DPMI. Also Borland
includes a True DPMI implementation of its own with these compilers. Given
that copies of the True DPMI spec are out there, I'm searching for them
much like Agent Mulder is searching for the truth about extraterrestrial
life and intelligence. Fortunately Bob Moote's "Committee" has never made
DPMI a trademark and Ralph Lipe's spec has never got Microsoft's copyright
stamped on it (it was just a rough dev draft quickly typed up in WinWord,
after all), meaning that if/when I find a copy of it I can immediately put
it up on my FTP site.

   Now you may ask "what is DPMI Version 1.0 then?" As I have said before,
Ralph Lipe and Bob Moote had radically different visions of DPMI, the
former seeking an interface between protected-mode DOS and its apps and the
latter seeking an interface for use by Phar Lap's DOS extenders. "DPMI
Version 0.9" has been produced perhaps in an hour by ripping out Ralph
Lipe's high-level APIs, but there are still references to it dangling
around, making it clear to anyone reading the spec that something is
obviously missing. Being dissatisfied with the fact that his ugly "DPMI
Version 0.9" still contained hints toward its original purpose and didn't
completely subvert to his ideology, he set out to write a spec that would
not contain a single word by Ralph Lipe and instead would be geared fully
toward Phar Lap's DOS extenders. The result is commonly known as "DPMI
Version 1.0". I still wonder why did Bob waste his time on writing it, as
it was clear even to a porcupine that it would never be implemented, since
its alleged purpose was light years apart from the real purpose of DPMI
(which started being accepted by the industry, partly because Microsoft and
Borland compilers used it). It is a grave mistake to treat "DPMI Version
1.0" as an improvement upon "DPMI Version 0.9", it is merely a further move
away from True DPMI.

   A very unfortunate fact is that DJGPP and CWSDPMI have chosen to use Bob
Moote's lopsided idea of DPMI instead of its true nature. Certainly this is
due to DJ Delorie simply not knowing about the existence of True DPMI,
which in turn is certainly due to the scarcity of the copies of the True
DPMI spec. It is still a pity, though, that DJGPP uses only the low-level
building-block APIs that are suitable to Bob Moote's selfish interests and
builds a separate power plant for every light bulb (i.e., builds the DOS
API translation engine into every app by making it a part of the
statically-linked libc.a).

   The conclusion of this lecture is that I need to continue searching for
the truth that is out there, so that I could finally bring it to light
after all these years (True DPMI: 1989, "DPMI Version 0.9": 1990, "DPMI
Version 1.0": 1991). This would mean finding a copy of the True DPMI spec,
putting it up on my FTP site, and writing a software development suite that
would produce apps for it, as well as writing a public-domain
implementation of it (to my knowledge all existing ones are commercial,
except possibly the DOS emulation under Linux).

   A billion thanks for reading! If you read up to here, please drop me a
note :-).

&gt;<em> Stuff compiled with DJGPP works just fine for me on Win95 [...]</em>

   OK, so DJGPP is at least correct after all, although severely misguided
because of the lack of knowledge.

&gt;<em> [...] which is (among</em>
&gt;<em> other things) a DPMI provider and certainly written by Microsoft.</em>

   The Protected Mode DOS component of Windows 95 is virtually identical to
that of Windows v3.00 and v3.1x. In all of them it is written by Ralph Lipe
and is the reference implementation of True DPMI.

&gt;<em> The same stuff also seems just fine using cwsdpmi.</em>

   OTOH, when I tried running a True DPMI client under CWSDPMI, it sent
about 2 KB of binary garbage to stdout and exited. Note that this client
does check for BobMootish DPMI hosts that implement only the low-level
building-block API and prints an appropriate error message if one is found,
so what I have seen indicates that CWSDPMI's implementation of the low-
level building-block API is also screwed. Well, it should be no surprise
for anyone that CWSDPMI is a specialized gadget for DJGPP and doesn't even
resemble True DPMI. If you want the latter without running Windows, your
current choices are (to my knowledge) 386Max and QEMM-386 with QDPMI. There
also is the Borland DPMI host, but it's 16-bit only. Oh, and OS/2, Windows
NT, and Novell DOS all implement True DPMI.

   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: address@hidden

   P.S. It is really swinish for me to be bashing Bob Moote, since he has
once done me a significant personal favor, but I simply can't put my
personal interests and obligations above my duty to the industry.

   P.P.S. A lot of my knowledge of this subject has been derived from
direct phone conversations with the key players in this field, including
Murray Sargent, Ralph Lipe, Bob Moote, and Dan Spear (author of QEMM-386
and QDPMI).

jDosBox

So while looking for some Win32s nonsense, I stumbled onto RGB Classic Games, and they have this interesting thing to run dos games online. A quick glimmer of the DOSBox logo flashes by.. So I fire up doom and quickly exit and…

Yes it’s DOSBox.

But in my browser.. A little tearing it apart, and it’s actually a port of DOSBox to JAVA!

Seeing it can run 80386 code, namely DOS4G/W, I figured it’d be interesting to see how it’d handle Microsoft PowerStation Fortran & PharLap TNT.

You can try it if you feel inclined here.

It’s been a boring day

My package from Germany finally arrived…!

And it contains Phar Lap 386 versions 4.1 and 5.0!

But something arrived in the mail. So I spent 2 hours cleaning things up and fighting with Watcom getting a skeleton verison of Doom to build. It’s finally running. Now to do some keyboard/video stuff.

Maybe more later though. But I may have to bench them some how Dos4G/W vs Phar Lap 386…. I donno.