Half-Life for Dreamcast has some functional multiplayer components

You can set the linker entry point to be whatever you want AFAIK. I'm not sure what you want to change in the CE kernel, you would need to locate and modify the loader to inject your console commands before the target binary is executed if I understand what you are trying to do.

As far as I can tell his patch just inserted a nop in place of the conditional JZ/JNZ whatever check.

 

Pretty much as I see it, since we know how and know that we can manipulate the kernel. Make all of the changes we need in the kernel, then have the hacks point to the new functions in the kernel

The top priority thing should be loading that hl.dll because then we'd need little hooks/hacking. But for example, we can add new drivers and registry entries for the BBA and mic, then in half-life just add the call to WinCE for the new functions. The same with internet also, connect within the kernel and have half-life call the functions from WinCE (those "InternetOpenHandle" imports/exports from wininet.dll in the WON PC version)

This imo would have the highest probability of working with minimal bugs/errors. Since adding the internet and hardware support within the half-life binary would be a lot heavier of a modification than just adding calls already defined in WinCE

Also @Trident6 , that video I posted a few posts back of injecting a DLL into a running PC game process, could the same method be applied to WinCE Dreamcast since we now know how to access the kernel?

 

Though I cannot understate that before multiplayer gets looked into, we must figure out how to load mods on the Dreamcast

Multiplayer would be somewhat pointless without mods and mods would be somewhat pointless without multiplayer. If we did actually pull this off and get it working, it would be the best thing on the Dreamcast with a potential massive amount of new great games both online and offline

 

Hey wait, I just thought of this, since we know the 1st_read.bin/0winceos.bin for a WinCE game is where the kernel loads, I can try using a 1st_read.bin from starlancer/max pool/4x4 evo. All of which are WinCE, and have multiplayer. I'd just have to rename the binary to the name of the game's binary (starlancer.exe etc)

This probably will not do anything for half-life directly, but it may allow the WinCE loader program to boot with a kernel that half-life will boot with

Meaning using any of the WinCE kernels I made using the Image Configuration tool, halflife_dc.exe would not boot. But if we're using the kernel from starlancer/maximum pool/4x4 evo, half-life may load

And if it does not, we can use the WinCE viewer to see the registry entries for a multiplayer WinCE game. Then either use the kernel for said game or use it as a template for the kernel to be used when someone with the skill actually attempts to get this working

 

I would need to look at the WinCE kernel structure to be sure about the details, but in general code injection on an embedded system of this nature is not hard to do. Whether it is from a sideloaded DLL or directly into the kernel itself really isn't important. Judging from the looks of it, it appears that 0winceos.bin is the actual kernel, and that in turn loads in the core CE DLL's at startup, finds the target exe, loads that and any additional required DLLs, and then executes. Again this is just from a quick look, I didn't load the kernel up in IDA to check.

Something to keep in mind is that if you are debugging with a BBA, getting multiplayer to work is a non-starter. You could try with a coder's cable over serial I suppose, but I don't know how prohibitive the transfer rate will be.

Also, if all you are trying to do is test command line parameters at startup, you can put a breakpoint on WinMain() and just set the parameters at that time instead of trying to hijack the load process. WinMain() should always load to a fixed location, though it will depend on how the MMU is initialized. This was written way before ASLR was really an issue so I don't see it being a problem. Alternatively you can just find the switch table where the arguments are parsed and invert the conditional on the ones you want to check. This will only work for binary options though, not ones that take a parameter (resolution=xxx or whatever).

 

Well considering WinCE for the Dreamcast does not support debugging over BBA or modem I do not think that will be an issue lol

If I was able to code at all I may have gotten a lot farther than this. Unfortunately I can not. If you do this I can test in minutes. But doing that stuff is about outside of my skill level

 

I am planning on isolating and statically linking the gdbserver code from KOS into the serial loader or manually inserting it into the kernel. If I don't have a debugging interface, all the speculation in the world won't change a thing.

 

If I recall correctly fellow member @FuzzyFish tried to implement BBA support in 4x4 Evolution (WinCE title), even though this never came to fruition perhaps he can still chime in on this matter.

 

Having a BBA debug method for WinCE and WinDBG would allow me to do a bunch of fiddling. I hope you have good luck with that

Something else I'll be testing later is half-life's 1st_read.bin with the CE loader. The "GDI graphics driver" had to be disabled in the WinCE kernel for HL to boot. Which would make the CE loader not display anything. If the loader has display I can look at the registry for HLDC and see if I can find hints of multiplayer

 

Half-Life's kernel/registry cannot be viewed in CE loader because it does not use the GDI graphics driver that CE loader uses to display everything

There's probably a way to do this using the dev software and coders cable by loading a debugger program with WinDBG (i think CEMON.EXE or something), then exploring the registry. I'm also pretty sure there's an included registry editor that functions similar to WinDBG

I will test Starlacer next. Maybe later today or tomorrow

Edit: To clarify, you must rename halflife_dc.exe to hldc.exe, rename ce_debug_program_here.exe to halflife_dc.exe. This way 1st_read.bin (where the CE kernel information loads into ROM) opens said debug program using the Half-Life CE kernel and registry

 

A massive thanks to PCwzrd13 for sending me a link to an eBay listing for a Dreamcast coders cable. I bought it without hesitation. I greatly respect PC for this deed

I can now make a good deal more progress and researching once the cable arrives if there are no issues with the cable
This is awesome

It was a little over $20 too. Would have cost me $80 to make one from a neo geo cable and raw material

I'm really looking forward to playing with the WinCE kernel/registry. Lets hope the retail debug method actually works
Going to install WinXP to a spare hard drive tomorrow

 

WOW! Only $20! You lucky bastard! Keep us all updated! Congrats man!

 

I actually got two lol
One is the ones from Lik-Sang and another is really long and does not have a chip, looks like a pro dev cable
Not bad for $15 and $5.80 shipping

I was doing some stuff with these cables. I have to figure out how to use the DC-Tool (not the KOS DC-Tool) to access the command shell. I can only debug for now. There is .EXEs to do so, but its going to take me probably another 10 CD-Rs to figure out

I tried boot half-life and seeing the debug log, but once halflife_dc.exe is loaded the debuger stops. Though it does say in the log that you can use parameters, so thats a start



Stuff I can use but need to figure out

• CEHEAPWK.EXE - "Windows CE HeapWalker" - Not sure what this is
• CEPVIEW.EXE - "Windows CE Process Viewer"
• CEFILEVW.EXE - "cefilevw MFC Application" - Looks like file viewer
• CEREGEDIT.EXE - "CEREGEDIT MFC Application" - Registry editor, this will come in handy
• CEZOOM.EXE "cezoom MFC Application" - Not sure what this is either
• CESPY.EXE - "cespy MFC Application" - Not sure what this is
• DCTOOL.EXE - Remote command line shell for WinCE, getting that to work via COM1/coder cable is my priority at the moment
• CEMGRC.EXE - MSDN page from 2002 says this starts the client side server to be connected to all the tools above, but needs special command line parameters. This may be what gets DC-TOOL to work via COM port, but I have not figured it out yet

Thats all for today, I'll be doing more stuff with this tomorrow
I need a GDEMU, re-rendering and burning CDIs over and over takes the most time of any of this

 

If somebody with the know-how wants to hexedit DC-TOOL so it automatically uses COM1 instead of SCSI for a Katana box, here is the binary

It may not be possible, but it'd save me a lot of time

 

Stuff I can use but need to figure out

• CEHEAPWK.EXE - "Windows CE HeapWalker" - Not sure what this is
• CEPVIEW.EXE - "Windows CE Process Viewer"
• CEFILEVW.EXE - "cefilevw MFC Application" - Looks like file viewer
• CEREGEDIT.EXE - "CEREGEDIT MFC Application" - Registry editor, this will come in handy
• CEZOOM.EXE "cezoom MFC Application" - Not sure what this is either
• CESPY.EXE - "cespy MFC Application" - Not sure what this is
• DCTOOL.EXE - Remote command line shell for WinCE, getting that to work via COM1/coder cable is my priority at the moment
• CEMGRC.EXE - MSDN page from 2002 says this starts the client side server to be connected to all the tools above, but needs special command line parameters. This may be what gets DC-TOOL to work via COM port, but I have not figured it out yet

Thats all for today, I'll be doing more stuff with this tomorrow
I need a GDEMU, re-rendering and burning CDIs over and over takes the most time of any of this[/QUOTE]

ceheapwk.exe - Heap walker (explorer), used to debug dynamically allocated memory at runtime. Pretty advanced stuff, probably not going to help you much.

cezoom.exe - Screenshot program iirc.

cespy.exe - Used to capture CE API calls at runtime, actually might be pretty useful for IPC and other things depending on how you approach it.

 

Great! Thanks. I'm hoping I can get all of them to work on retail unit. I'll have a lot more to fiddle with. I'm not betting too hard on the parameters loading this dll thing. It would certainly be cool and amazing if it did. But I really want to see what these other parameters do like '-rouge' '-proghack' etc

There could even be some hidden dev menus and stuff only meant to be accessed via dev box/DC TOOL. But who knows, hopefully we'll see

 

It seems my issue with DC-Tool not working is not having the correct version of WNASPI32.DLL. I've tested many different versions, and one somewhat works, but crashes the rest of the progs. This leads me to believe I should be using Windows 98 instead of Windows XP because I was reading that WNASPI32.DLL came standard with a new install of Win95/98

The WinDBG says the kernel I'm using is from September 21 1999, I'm not sure if XP was even out then
I hope I do not need to reinstall everything, that took many hours the other day because I messed up my Windows 7 boot manager and had to repair it twice

 

Windows XP Release date.

Released to
manufacturing August 24, 2001; 14 years ago
General
availability October 25, 2001; 14 years ago

So yeah think 98 would be your best bet here.

 

Remember all the stuff about the second disc having Team Fortress Classic and Counter-Strike? Maybe the second disc had Half-Life Multiplayer on it, instead of being on the main disc, considering if multiplayer was present on the main disc, it could have been on the second disc instead of on the main disc, it'd make sense to move it a multiplayer game to the second disc where all the multiplayer games are.

 

Well, considering the fact they were not really that close to releasing that disc I doubt it ever existed other than the code we have now with the leaked build. They had plans for it but that was gonna happen much later after the singleplayer disc was released. Oh what could have been...