Nintendo Classic Mini

11/11/2016

11/11/2016

Just saw mention of this, the Nintendo Classic Mini

It includes a USB controller, HDMI, and you have to bring your own USB +5v power supply. It’ll come with 30 pack in games, but no mention of any additional games.

The only thing that stuck out to me is that Mike Tyson’s Punch-Out!!,  is reverted back to the original Japanese Mr Dream.  Kind of lame, but I guess that is licensing for you.

There is more information at the Nintendo page, with a shipping date of November 11th, 2016 for the UK.

Captain Blood reverse engineering project

I found this the other day, and I thought it was pretty damned impressive.

Fractal viewer in C#

Fractal viewer in C#

Kroah has taken the time to reverse how the fractals worked in Captain Blood.  From bringerp.free.fr:

The procedural terrain generator uses 1D fractional brownian motion (fBm) with random mid-point displacement. Up to 10 curves are displayed on screen.

When a new curve appears at the horizon, 7 vertices are computed. Then mid-point displacement with fBm are applied to thes 7 initial points. This results in a discrete curve of 512 samples.

The random number generator and the fBm Hurst parameter H are adapted according to the current terrain type (flat, canyon…). This gives very different visual landscapes (plains, moutains, desert…).

No more fractal computation is done on the discrete curve. When a curve is drawn, only 256 of the 512 samples are used (according to the position of the Oorxx).

The view is 256 pixels wide, so if the visible part of the curve is larger than the 256 samples, the curve will be drawn zoomed with pixels linearly interpolated between the samples. Otherwise the curve will be drawn shrinked without any interpolation and using only some of the 256 samples.

The raytraced fractal landscape is computed from these 10 curves.

It’s pretty amazing to think that there was that much behind the game.

I played this back in 1988 on the lowly Commodore 64, but the Amiga version was simply amazing.  Such was technology back then.

More fun with the System16, kinda, sorta?

So, Ive been playing around with emulators, and for some reason I think it’d be awesome to have a real one.  So I check ebay, and yeah there is a few, Altered Beast, Shinobi, and even an Outrun, and a couple of Hang Ons!  Wow this is so cool, then I check the prices, and shipping and yeah it’s REAL expensive, REAL quick.  And even back when I did own an Altered Beast board, I never got it hooked up as it was ‘too hard’.

So, I’m about to give up on the whole thing, then I spot this Altered Beast board, for sale for a mere €50!  And the shipping isn’t too insane either!  But looking at the PCB board in the picture, and I can tell something is not quite right:

€50 board!

€50 board!

Now for those who don’t know, this clearly is not a System16 board.  However it certainly does have a 68000, and z80 processor!  Could this be some 2nd tier manufacturing job? Or perhaps it’s one of these infamous bootleg boards?

For comparison, here is a real SEGA System16 board

A real System16 board

A real System16 board

As you can see, they really look nothing alike.  Also the other give away is that the far cheaper €50 board is JAMMA compatible.  All the old SEGA boards are not.

What the heck is JAMMA anyways?  You see that edge connector?  That is where you would plug in the power, coin catchers, the player buttons, and the speakers to.  Even in the old days, recycling cabinets was a thing, and having modular boards was a ‘good thing’.  But SEGA didn’t want you to swap out their boards with anyone elses, so they used their own system.  But it’s just a wiring thing, there is nothing digitial locked down, no encryption either (look at HDMI!).  So you can use an adapter, to interface from SEGA to JAMMA.

Anyways, I went ahead and placed the order.

Now doing some more research, and the monitors used in 1980’s arcades were RGB+Sync driven.  Which are ancient, and of course, HEAVY. But a little bit of searching led me to the to the GBS 8200 v4.0.

GBS 8200 v40

GBS 8200 v4.0

AKA known as the “GBS8200 CGA/EGA/YUV/RGB To VGA Arcade Game Video Converter”.  Well this certainly looks perfect!  I mean from the description alone, it’ll do what I want.  Even better they make them a few KM from here, and I could get one for ~ $20 USD.  Perfect.

Next up is the power, I decided to get a “JAMMA” power supply.  A bunch of searching, and this one was the cheapest one I could find, and again shipping wasn’t too bad, but not great either.  The supply was again around $20 USD, but shipping was $15. OUCH.

MD-9916A JAMMA switching power supply

MD-9916A JAMMA switching power supply

I figured having the ability to screw in would be a ‘good thing’.

Naturally, I need the cables to wire this mess together, so I ordered a “JAMMA Cabinet Wire Wiring Harness Loom” for about $15 USD.  Naturally mine is all in Chinese since I went cheap.  But it’s OK, I have a multi meter so I can test continuity.

Finally I saw a QANBA N1 arcade style joystick in a local mall for $230 HKD.  That is less than HALF the price of the ones I see online in the USA, Europe, or Canada.  So at least that is nice.  Now with all the parts, I just have to wait for the board to arrive.  And wait, and wait.  Nothing updated on ebay, then suddenly I check a few days later, as it’s been two weeks by this point, and it turns out that it’s been sitting in the post office in Hong Kong for a week!  If only they let me know…  SF Express, and FedEx have come without issues.  Oh well, now I have the board!

I can now finally flip it over to reveal:

Graphics board

Graphics board

It’s all 74L TTL logic chips, EEPROMS, and some PALs as well.  There are NO custom SEGA chips at all.  If anything this is what is inside of the SEGA ASIC’s on the System16 board.  Whoa.

Ok, so this is certainly a bootleg board.  A quick search of MAME shows that they have a Datsu ROMset, so maybe this is one?  Nothing on the boards say Datsu, however it does say ALTER/S, and it shows being QA’d on 11/11/88.

Now it’s time to cable this thing up!

But first JAMMA boards are typically key’d so you cant put the adapter in backwards.  There is no key on this board, so I need to check the voltages to make sure I don’t flip it backwards.

JAMMA Standard Pinout

** Solder Side Parts Side **




GND A 1 GND
GND B 2 GND
+5v C 3 +5v
+5v D 4 +5v
-5v E 5 -5v
+12v F 6 +12v
Key, No Pin H 7 Key, No Pin
Coin Counter 2 J 8 Coin Counter 1
Coin Lockout K 9 Coin Lockout
Speaker (-) L 10 Speaker (+)
NC M 11 NC
Video Analog Green N 12 Video Analog Red
Video Composite Sync P 13 Video Analog Blue
Service Switch R 14 Video Ground
Tilt/Slam S 15 Test
Coin B T 16 Coin A
Player 2 Start U 17 Player 1 Start
Player 2 X-Dir Player 2 Up V 18 Player 1 Up Player 1 X-Dir
Player 2 Y-Dir Player 2 Down W 19 Player 1 Down Player 1 Y-Dir
Player 2 X-Clk Player 2 Left X 20 Player 1 Left Player 1 X-Clk
Player 2 Y-Clk Player 2 Right Y 21 Player 1 Right Player 1 Y-Clk
Player 2 Button 1 Z 22 Player 1 Button 1
Player 2 Button 2 a 23 Player 1 Button 2
Player 2 Button 3 b 24 Player 1 Button 3
1 Player 2 Button 4 NC c 25 NC Player 1 Button 4 1
1 Player 2 Button 5 NC d 26 NC Player 1 Button 5 1
2 Player 2 Button 6 GND e 27 GND Player 1 Button 6 2
GND f 28 GND

This is the standard pinnout of a JAMMA harness. Importantly you can see it’s Ground than +5v.  So looking at the 68000 processor to check it’s pinnout:

D4 1 64 D5
D3 2 63 D6
D2 3 62 D7
D1 4 61 D8
D0 5 60 D9
AS 6 59 D10
UDS 7 58 D11
LDS 8 57 D12
R/W 9 56 D13
DTACK 10 55 D14
BG 11 54 D15
BGACK 12 53 GND
BR 13 52 A23
VCC 14 51 A22
CLK 15 50 A21
GND 16 49 VCC
HALT 17 48 A20
Reset 18 47 A19
VMA 19 46 A18
E 20 45 A17
VPA 21 44 A16
BERR 22 43 A15
IPL2 23 42 A14
IPL1 24 41 A13
IPL0 25 40 A12
FC2 26 39 A11
FC1 27 38 A10
FC0 28 37 A9
A1 29 36 A8
A2 30 35 A7
A3 31 34 A6
A4 32 33 A5
 You can see it’s power input is on pin 14.  Likewise, the ground is on pin 53.  Also looking at the edge connector, you can see the two pairs of pins, which correspond to the double ground, and double +5v.
Connecting the harness

Connecting the harness

From there, it was a matter of connecting up the power supply, adding in the power to the video board, connecting the RGBS connector, and powering it up.  It was very cool to get a glimpse of Altered Beast!

Something is wrong

Something is wrong

And hello, it is a Datsu board.  I’ve tried to google about these boards, and all that I could find out is that they seemed to be popular in Italy.  They may have been made in Korea.  There was another variation called ‘Mutant Warrior/Super Warrior‘.  There was some posts about it in an Italian game forum mameitalia.net, and arcadeitalia.net . Google translate works fine enough to read, but they were in smaller places that couldn’t afford mainstream games, so enter the bootlegs.  And this makes sense, as the board I got was from rural France.

I maybe had a picture for 20 seconds, it was frozen, then the screen went black.  I power cycled, to nothing.  I tried it again to a green screen.  And again to a green screen.  At this point I think it’s died.  I let it rest for a few minutes, and try again.  Nothing.  I leave it powered up, and feel the processor, and it’s warm.  It’s doing something, so I think.  So I start to play with the video board, and as I change resolutions, I get an image!.. then it disappears.  Power cycling, and changing resolutions occasionally gives me an image.  I look more closely at the CPU board, and notice that it has 4 standoffs placed on each corner.  There is nothing in the middle, and over the past 28 years the board is sagging.

In order to fix the sag, I decouple the two boards, and spread them out.  I try it again, and it doesn’t show me anything. Eventually I play with all the video board settings, and manually set it to the RGBS input, and then the image stays!  The board is running.  I tweek some of the settings, and the pink goes away, and now it looks correct!

20160430_110924

LOGO

And even the intro animation is OK

Looks good

Looks good

OK, now it’s time to turn it off, and wire up the joystick.

The first step is to remove the joystick ball, and on the QANBA N1 you first flip it upside down, and remove the little cover.

Remove the cover

Remove the cover

to reveal the screwdriver slot to let you hold the stick in place as you unscrew the ball.

slot

slot

Now it pops off, and it’s really easy to remove the USB interface cables, and drag in the JAMMA cables.  Again use a tester to tone out what goes where. DO NOT FOLLOW MY COLORING GUIDE.  I’m pretty sure there is no colour standard, so just because mine is like this, yours will 99.9999% not be.  The only common thing is that each of these buttons needs a ground.

Joystick wired up

Joystick wired up

My harness has a common ground for P1 and P2, so I just tapped up the end and tucked it in the joystick body.  Now with wired up, I can put the joystick back together, and play!

And that is when I could finally see that something was wrong.  I was doing pretty well, then in the 2nd level I saw this weird thing:

An actual wall of text

An actual wall of text

The sprites are working fine, and the gameplay continues.  But eventually the wall of text effect went from the background to the foreground obscuring game play.

foreground tile corruption

foreground tile corruption

So no doubt something is bad on the board.  I need to get it looked at, and see about first dumping and checking the EEPROMS.  Next the RAM on the graphics board, may be suspect as well.  I think the CPU is fine since it runs OK, I’m just unable to really see pass the wall.

For the heck of it, I went and got some powered speakers, and hooked them up:

And it sounds so different from the SEGA version.  An inspection of the board shows that there is no YM2151, but rather a pair of YM2203’s and an OKI M5205 for the speech synths.

In retrospect, I probably should have gone with something like the arcade supergun.  I didn’t know it was a thing unfortunately.  My solution is more “traditional” , but it works.

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!

Porting Quake II to MS-DOS pt3

Well it mostly works now.  But did we ever have the biggest fun with the sound and SVGA.

So [HCI]Mara’akate integrated all the Q1 sound code, got it to compile, but nothing not a peep from the sound card.  While I was busy trashing the video code, he spent way too much time on the audio, and then for the heck of it I thought I’d look at the code, although I’m really stabbing in the dark when it comes to audio.  Imagine my surprise when I compiled the code, and ran it and got the sound blasting at full volume!  It turns out that I had my audio set to ‘high quality’ in the client, while he had his set to ‘low quality’.  What it does is govern the frequency between 11Khz and 22Khz.  And if you get this wrong you get *NO* audio. OOPS.  At least it was one of those feeling vindicated moments that his efforts for sound really did work.

Now with audio, it was my time to hurry up and get the video going.  I had basic VGA working so I figured I didn’t want to spend a lot of time on this, so I was going to go with the VESA 2.0 linear frame buffer.  Well this once more again proved to be a bit more involved as the only way I really have to test is emulation via DOSBox and Qemu.  And naturally both of them worked fine, but when [HCI]Mara’akate ran it on his real DOS Box (with GUS of course) it crashed wonderfully.

Now I had taken the VESA init code from Quake 1 to build a table of what 8bit modes are supported, and used the VESA code to switch, along with drawing to the buffer with a simple memcpy.  And we got nothing but crashes.

After looking more around, I found that you had to add 0x4000 to the VESA mode you want if you wanted to access it’s LFB.  Did that work? No still crashed.

Later in the adventure we noticed to get proper access you had enable ‘near pointer acess’ with a call to :

__djgpp_nearptr_enable();

So naturally I would disable it when I’m done, making the call look like this:

__djgpp_nearptr_enable();
memcpy(vid_resolutions[whatmodearewe].address+__djgpp_conventional_base,vid.buffer,(vid.height*vid.width));
__djgpp_nearptr_disable();

Right?

WRONG. Oh so WRONG.  Well OK technically it did work, but if sound is enabled (and why wouldn’t it be?) it would immediately crash with an error in the DMA code.  We ended up wasting over a day trying to figure this one out until I just said screw it, let’s never dsiable the nearpointer, leave it unprotected.  Naturally that actually worked.  The hint is in map_in_conventional_memory, where __djgpp_nearptr_enable(); is called, but of course there is no calls to __djgpp_nearptr_disable();  I’ve thought about going back through the source to ‘clean’ it up to make it lock and unlock memory as needed, but this is 2015 not 1997 so good enough is well, good enough.

So now with VESA and Sound, I thought this would be a great time to tackle the dynamic loading of gamex86.  We will have to re-compile whatever gamex86 DLLs are out there as of course DOS is DOS.  The HX DOS guy Japheth seems to have died, as his site and all the info on that extender seems to have mostly vanished.  I have an old copy, but I never could make it call DOS stuff if you had WIN32 stuff going on.  And if he’s really dead it’s too late to ask him.

Ages ago I remembered this DLL support for DJGPP called DLM, so I thought I’d give that a try.  I was able to take our ‘null’ version of Quake II, and get it to where it can load and unload the gamex86.dlm at will.  So I figured this was going to be an easy win, right?

Wrong again.  Once I started to put in the MS-DOS specific code I got this fun crash:

DLM -> Exiting due to signal SIGSEGV at
0x0014f59d SYM: _dos_lockmem+0x9 DLM: q2.exe [0xf5000]
possibly because of undefined reference to symbol ‘___djgpp_base_address’

DLM call frame traceback :
0x0014dcaf SYM: _Sys_PageInProgram+0x37 DLM: q2.exe [0xf5000]
0x0014e1c4 SYM: _main+0x18 DLM: q2.exe [0xf5000]
0x0000774e
0x00008b6e

So apparently it doesn’t export (or import) djgpp stuff like the base address calculations so we can’t do direct memory access, which means no video and no sound.  Ouch.  I’ll have to hit the lists to see about support.  I don’t like the DXE’s because they cannot be unloaded, so that isn’t much good.  And of course things like the JVM inside of gamex86.dll is right out as JAVA inside of MS-DOS? in 64MB of RAM? Dream on.

So for now, the gamex86.dll is statically linked into the executable.  You are restricted to vanilla gameplay for now.

As an added bonus, I used Rufus 2.2, to setup a bootable MS-DOS USB stick, slapped everything onto there, and booted up on my Xeon, and it works!

Quake II running on MS-DOS

Quake II running on MS-DOS

Now as a super bonus,  [HCI]Mara’akate went above and beyond by adding in a bunch of fixes, and updates from 3.24 and varous stuff from Knightmare.  And then the best part is integrating libogg, so it can now play the ogg sound track!  Really, just place the ogg files in the baseq2\music directory and away you go!

For those who care the bitbucket of the project is here, and binaries are here.

**UPDATE**

For anyone who is interested, I’ve updated the binaries, to include the latest version with built in quakespy technology!  Run an /slist2 and get a list of servers!

/slist2 in action!

/slist2 in action!

For the more adventurous trying to build from source, we are using GCC 2.95.3 and DJGPP 2.04.  All of the sub libraries that you need to build are already pre-compiled in source drop.

At this point the ‘alpha 2’ version contains:

  • VGA
  • SVGA
  • Mouse
  • Keyboard
  • SoundBlaster and Gravis UltraSound Family
  • CD-ROM music
  • OGG music
  • Networking (You need a packet driver)

Installing the packet driver will require a driver from the crynwr project.  You can find a description of some of the drivers here.  Sadly for new cards I think we are left in the dark.

I’ve also compiled a ‘server’ for Linux based on the code, and put it online @ 87.117.247.11:27910

Continued in pt4, and part 5.

Porting Quake II to MS-DOS pt1

(In this series, I’m going to go over the process of porting Quake II to MS-DOS.  Now of course the question will pop up why? And the answer is simple enough, after [HCI]Mara’akate added in gamespy support, something was noticeably off, and that is fewer and fewer people are playing Quake 1 these days.  So what to do?

Well apparently Quake II has an active following, so it’s time to move our creeky but favorite OS, MS-DOS into the Quake II Arena!

So the first thing to do is to grab a copy of the GPL source to Quake 2, along with a copy of the game, and get started on making a ‘null’ version of the game.  Null versions of the game have no graphical output, no sound, and ‘function’ at a very basic level.  It’s something to strive for as a first base in hitting that home run of a functional port.  Thankfully iD wrote really portable and modular software.  Unfortunately they tended to let their ports drift as they were writing the engine so the null code doesn’t actually work out of the box.  And the project makfiles leave a little to be desired for me, as they have a bunch of i386/Dec Alpha magic which doesn’t leave much in the room for weird ports like MS-DOS.

Now I should mention that before I’d gotten started the first thing I decided that like QuakeWorld for MS-DOS (and OS/2) I would use GCC as it is a known working compiler out of the box.  If you can, don’t fight so many battles of unknowns at once.  Another thing is that I am going to cross compile from OS X and test with DOSBox.  Of course you may want to use something else, and I know my tastes drift, but for now this is what I’m using. I’m using my old OSX to DJGPP cross compiler with GCC 2.95.3, which serves me well.

So the first thing was to compile and run the null version with native tools on OS X.  After a bit of struggle I got here:

$ ./q2
Added packfile ./baseq2/pak0.pak (3307 files)
Added packfile ./baseq2/pak1.pak (279 files)
Added packfile ./baseq2/pak2.pak (2 files)
Console initialized.
Sys_Error: ref_soft::R_BeginFrame() – catastrophic mode change failure

Well that’s great, how to figure this one out?

One thing I did to make it easier to work with the flow of Quake is to make the Sys_Error procedure contain a divide by zero.  Now why would I purposely put a divide by zero in the code?  Simple it lets me back trace the code when Quake catches it’s own faults so I can see what went wrong where, vs what would look like a clean exit.  From my example:

(lldb) bt
* thread #1: tid = 0xf14f9, 0x000c0853 q2`Sys_Error(error=0x000c17d4) + 98 at sys_null.c:28, queue = ‘com.apple.main-thread’, stop reason = EXC_ARITHMETIC (code=EXC_I386_DIV, subcode=0x0)
* frame #0: 0x000c0853 q2`Sys_Error(error=0x000c17d4) + 98 at sys_null.c:28
frame #1: 0x0003a0cb q2`Com_Error(code=0, fmt=0x000c17d4) + 368 at common.c:215
frame #2: 0x000c0523 q2`VID_Error(err_level=0, fmt=0x000cc8a8) + 81 at vid_null.c:45
frame #3: 0x000a6d38 q2`R_BeginFrame(camera_separation=0) + 592 at r_main.c:1145
frame #4: 0x000a4cfc q2`R_Init(hInstance=0x00000000, wndProc=0x00000000) + 276 at r_main.c:333
frame #5: 0x000c0740 q2`VID_Init + 362 at vid_null.c:122
frame #6: 0x00007900 q2`CL_Init + 55 at cl_main.c:1795
frame #7: 0x0003c2cb q2`Qcommon_Init(argc=1, argv=0xbffffc40) + 754 at common.c:1469
frame #8: 0x000c09ac q2`main(argc=1, argv=0xbffffc40) + 24 at sys_null.c:128
frame #9: 0x000019ad q2`_start + 212
frame #10: 0x000018d8 q2`start + 40
(lldb)

Now I know that R_BeginFrame was where the error was occurring, and looking at the code:

if ( ( err = SWimp_SetMode( &vid.width, &vid.height, sw_mode->value, vid_fullscreen->value ) ) == rserr_ok )
{

else
{
ri.Sys_Error( ERR_FATAL, “ref_soft::R_BeginFrame() – catastrophic mode change failure\n” );
}

We can see that the vid.width/vid.height aren’t being setup correctly.  Turns out there was a bunch more work to be done setting up vid_null!

 

After looking closer at the files, I notice as I’m stitching them together is that Quake II relies on DLL’s as part of it’s base functionality.  I drifted out of Quake after Quake 1, so I never played II before.  So I didn’t know this.  Obviously DJGPP doesn’t support DLL’s that can be loaded and un-loaded at will (Yes I know about DXE’s, but as the FAQ states, they cannot be un-loaded.  And I’m not going to fight DJGPP’s LIBC).  So looking further in the source, I saw these fun defines:

-DREF_HARD_LINKED -DGAME_HARD_LINKED

So at one point there was support for ‘hard linking’ in the ‘REF’ video driver, and the ‘game’ logic driver.  But it did kind of drift out of the code.  But looking at the Win32 version I could see that putting this functionality back in should be easy.  And to be honest if I learned any lesson from this, is that I should have been pulling the Win32 version apart by injecting null into it until it ran as a null platform, then use that as the basis.  Lesson learned.  Always start with a known good!  Quake II was built with Visual C++ 6, but I only have Visual C++ 4.2 installed on Crossover.  Yes I know again this is me being difficult.  But it didn’t take much time to get a simple project that has two DLL’s and a Win32 exe running.  Then I took on the ‘ref’ video driver and got that linking inside of the main EXE.  Now with one DLL ‘eliminated’ it was time to work on the game dll.

The game DLL posed the biggest challenge because it passes a reference to internal functions to it, and exports various functions back to the game engine.  So I ended up altering the engine to not call the game import/export directly but setting it up myself.  The hardest thing was that I couldn’t pull in the game header file, but rather I had to copy the prototypes myself.  Another interesting thing with the way Quake II works is that the game dll has to be able to be unloaded and loaded at will.  It wasn’t hard to simulate this, but I wasn’t expecting it.  Again this is probably because I never really played Quake II.

Now that I had Quake II building without DLL’s I could then take the next step of removing all the IO and re-replacing it with the null code, and now I had something that looked like it was doing something.

Added packfile ./baseq2/pak0.pak (3307 files)
Added packfile ./baseq2/pak1.pak (279 files)
Added packfile ./baseq2/pak2.pak (2 files)
execing default.cfg
execing config.cfg
NULLsock Initialized
Console initialized.
768k surface cache
ref_soft version: SOFT 0.01
——- sound initialization ——-
Sys_FindFirst [./baseq2/autoexec.cfg]: UNIMPLEMENTED!
==== InitGame ====
——- Server Initialization ——-
0 entities inhibited
0 teams with 0 entities
————————————-
====== Quake2 Initialized ======
loopback: client_connect
==== ShutdownGame ====
Sys_Error: Draw_Pic: bad coordinates

This turns out because I didn’t allocate the screen properly.  Looking at the code:

if ((x < 0) || (x + w > vid.width) ||
(y + h > vid.height))
{
ri.Sys_Error (ERR_FATAL,”Draw_Pic: bad coordinates”);
}

We can see it pretty plainly.

Now since we were going somewhere I started to write some MS-DOS code, and switch out of the null set of mind!

First a simple VGA mode 13 setup which gives us 320×200 resolution with 256 available colours.  And for good measure I did a simple VGA palette setup that I knew worked from a prior program.  Next we just blit our buffer onto the screen, and we get this:

Quake II on MS-DOS first screen

Quake II on MS-DOS first screen

Which is exciting and disappointing at the same time.  I then took the palette code from DOS Quake, and got something just as ugly.  I tried the code from OS/2. Same thing.  I tried all kinds of things and was going nowhere.

At this point Mara’akate added in the Linux clock code, and now we had this!

Quake II with a bad palette

Quake II with a bad palette

It wasn’t until much more digging around I saw some 320×240 screen setups that I realized there was something wrong there, and then I saw this gem in the linux port’s code:

/*
** SWimp_SetPalette
**
** System specific palette setting routine. A NULL palette means
** to use the existing palette. The palette is expected to be in
** a padded 4-byte xRGB format.
*/

In traditional VGA palette setups it’s 768 bytes that needs to be read/and pushed to the card.  I even checked Quake 1 is 768 bytes, but now in Quake II, it’s 1024 bytes!  OOPS!  Sometimes (ok a lot of times) you really need to check other ports or a ‘known good’ to see how they did things.

Quake II running on MS-DOS!

Quake II running on MS-DOS!

Pretty awesome!

So where to go from here? Obviously things like better keyboard input, the mouse, sound and networking need to be done.

Continued in pt2, pt3pt4, and part5.

Shadowrun Hong Kong!

I just saw this pop up on Steam, Shadowrun Hong Kong!

WooHoo!

WooHoo!

I was hoping this is available right now, but it’s slated for ‘summer’ which is soon!

$19.95 USD

$19.95 USD

With any luck, later on it’ll come to Android too.

shadowrun FASA 7100Anyways for those of you who don’t know Shadowrun started life as a FASA based tabletop game, then made the transition later to a video game for the SNES, and Genesis.

Shadowrun is set in a dystopian cyberpunk future that blends magic and dragons as well.  It’s very similar to Palladium’s RIFTS which introduced a world with technology and magic, although it wasn’t as focused on the new and exciting genre of cyberpunk.

Those who loved the top down game, were later saddened with FASA’s demise.  Microsoft picked up the property and in 2007 released their own spin on the game.  It was not well received.  In a nice twist of fate, the game was re-licensed to the original developers who release Shadowrun games to this day.

Shadowrun on the Genesis

Shadowrun on the Genesis

.And yes, while I’m on the gratuitous Hong Kong action there is always Sleeping Dogs.

Woof

Woof

Besides that, what else is there?

Mahjong, I guess.