Monthly Archives: May 2016

Stupid GCC error

Posted on by
Reply

So while mixing and matching GCC on Windows, I ran into this issue with stdio.h of all things:

In file included from hi.c:1:0:
\mingw\include/stdio.h:191:65: error: unknown type name ‘size_t’
_CRTIMP int __cdecl __MINGW_NOTHROW setvbuf (FILE*, char*, int, size_t);
^~~~~~

Good grief how could stdio be all screwed up?

Well, it turns out it was my fault.  I had not rebuilt things like SDL, or copied over pcap so I figured I could incorrectly just point a -I to my old includes, and the new gcc would post-pend all use -I stuff.  NOPE it pre-pends them, meaning the old headers now take priority.  And wouldn’t you know it, things have drifted between versions.  So I just manually copied the files and libraries and all was well.

Googling around I did see other people with broken stdio.h but nobody posted the solution.  I guess it’s to embarrassing, but here we are.

DJGPP memory fouled

Posted on by
2
free: memory fouled

free: memory fouled

If you ever get this fun error while trying to exit or shell a program with DJGPP:

combinelo: memory fouled

free: memory fouled

You are mixing libraries built with a different version of the DJGPP runtime.  In my case, I built the allegro library with GCC 2.7.2.2 to use the older binutils but I’m cross compiling with GCC 5, so it’s using the newer runtime.

In my case I just needed to replace the contents of the lib directory with djcrx202.zip, and I was good to go.  I guess I could re-compile allegro, but that takes the better part of forever on DOSBox, and once was good enough.

GCC 6.1.0 for MinGW

Posted on by
5

Since MS-DOS has it’s 6.1.0 I was dying to re-build stuff for 6.1.0.  As I don’t want to build it myself I did mange to find a version on equation.com

I rebuilt Cockatrice III, and that seems to be running fine.

Continuing from my GCC 1.40 on Windows, here is version 6.1.0’s scores:

D:\emx\demo\dhry>gcc610.exe
Dhrystone(1.1) time for 500000000 passes = 53
This machine benchmarks at 9433962 dhrystones/second

D:\emx\demo\dhry>gcc610_O.exe
Dhrystone(1.1) time for 500000000 passes = 18
This machine benchmarks at 27777777 dhrystones/second

D:\emx\demo\dhry>gcc610_O2.exe
Dhrystone(1.1) time for 500000000 passes = 16
This machine benchmarks at 31250000 dhrystones/second

D:\emx\demo\dhry>gcc610_Ofast.exe
Dhrystone(1.1) time for 500000000 passes = 13
This machine benchmarks at 38461538 dhrystones/second

As you can see the scores are actually slower than GCC 5.1.0.  Well that was kind of surprising.  Since I almost never read the manual, I did find out about -Ofast vs -O3/-O2, and yes, it is much faster!  So I guess I should recompile everything with GCC 5.1.0 … But I do prefer the diagnostic messages in GCC 6, it’s very CLANG like.

UAE 0.8.29 on Windows

Posted on by
6
Captain Blood on UAE 0.8.29

Captain Blood on UAE 0.8.29

This one should have been much easier to build, it has support for SDL built in, however the include files are a nested mess, and configure fails part of the way in the process leaving the source kinda messy.  But a few hours over a couple of days, and here we are.

This version doesn’t run at warp speed, has sound, and is great.    It wants a config file though.  You can find the specs in the readme, but something like this:

#cpu_type=68030/68882
cpu_type=68040
cpu_speed=real
sound_channels=stereo
sound_bits=16
sound_frequency=44100
gfx_center_vertical=true
gfx_center_horizontal=true
gfx_color_mode=32bit
floppy0=df0.adf

works fine.  This later (and seemingly last) branch of UAE  incorporates lots from WinUAE, except for the JIT.  It’s dated 2008, so it does include support for the 68030, 68040, and the 68881 and 68882.  It doesn’t have MMU support, so things like Linux/AMIX/NetBSD/Enforcer are out of the question.

I dumped my source tree over on sourceforge, as I’m more so interested that this builds using MinGW.

Ported UAE 0.7.6 to MinGW!

Posted on by
Reply
0.7.6

0.7.6

I can’t find any source of the 0.5 versions, and I had issues with 0.6.x  but with enough mashing of stuff around I did manage to get 0.7.6 to compile, then leaning more on the xwin.c source file I was able to get the SDL output working for 32bit depth (does anyone even have 8bit displays anymore?).  I suppose with this version working I can go back and take a stab at resurrecting 0.6.x

What is cool is that 0.7.6 (perhaps earlier versions of 0.7?) switched from a non commercial license to the GPL 2.0 license.

I managed to ‘fix’ the keyboard in this version so that not only does it not type too fast, but it’ll remember “sticky” keys like shift, control & meta.  So now you can actually use the CLI, and change disks.  Double clicking is an impossibility as it simply runs far too fast.  I compiled in audio support but didn’t bother with the SDL end, as it would sound like noise with it running so fast.

I also updated UAE 0.4, with the fixed keyboard code, and it’s usable now as well, with the same caveat that it simply is just too fast.  UAE is from an era where a 100Mhz computer was a luxury item.  Now some $5 computer, you could pack in breakfast cereal has a 1Ghz processor.

For the 2/3 people who care, I put the binary & source tree on sourceforge here. UAE 0.4 & UAE 0.1 are also available for download, plus all the source code I’ve been able to find.

GCC 1.40 on Windows

Posted on by
2

I know with all the talk of GCC 6.1.0 for MS-DOS, and other platforms, you must be thinking that all this talk of progress, and high versions numbers just isn’t right!  I’ve just started to migrate code to GCC 5.1, and now you are telling me there is a GCC 6!

Where can I turn away from all this so called progress!  I don’t like my C compilers to be C++ programs that require massive HOURS to compile.  Can’t we just go back to the good old days?

And the answer is YES, you can!

While looking for some libraries on another project, I came across this old defunct project called RSXNT. And it’s a port of EMX to Win32 platforms!  Well isn’t that fantastic!

So, considering I was able to build GCC 1.40 and cross compile to Linux 0.11 from Windows, can we do something with this?

Well ancient versions of EMX are very difficult to track down.  Somehow I did mange to find this hybrid of 0.8B & 0.8C.  The EMX runtime & binaries are from 0.8C, but the source code is from 0.8B.  And the best thing is that the 0.8B is based around GCC 1.40!  So with a little bit of tweaking the files, and messing around I got the assembler, linker, and C compiler to build with MinGW!  Sadly the source code to EMXBIND, wasn’t included in the zips that I have, but the aformentioned RSXNT packages included a version of EMXBIND that will run on Windows!  So I managed to mash them together, and for the fun of it, I’m using the old InfoTaskForce interpreter from 1987 to complete the vintage feel.

Compiling & Binding

Compiling & Binding

Now with my executable, I can run it on MS-DOS & OS/2!

MS-DOS via DOSBox

MS-DOS via DOSBox

and OS/2 2.0!

OS/2 (on Qemu)

OS/2 (on Qemu)

Well isn’t that fantastic!

However when running RSXNT’s bind, NTBIND I got this error:

D:\emx_w32\infocom>..\bin\ntbind info2
No relocations in file:
you have not linked the NT library

Great.  Some more digging around, and if you want to make Windows programs, you need to use the RSXNT includes & libraries.  So I shifted the libraries around, and patched gcc to call the linker the same way RSXNT’s gcc driver calls it, and first go this error:

io.o: Undefined symbol __streams referenced from text segment

And looking at the stdio.h there is this:

extern struct _stdio _streams[];

No doubt, the headers & libraries are tied together.  So now making both of the RSXNT versions, I can link the executable. (YES I did try declaring the structure anyways, and I get stdout, but stdin doesn’t work).

Running on Windows 10

Running on Windows 10

Just like EMX before it, RSXNT, requires you to have the RSXNT.DLL file in your path, or in the same directory.  I suppose it’s a fair trade off.  Not that I expect there to be a surge of people cross compiling from Windows to OS/2, or even MS-DOS these days.  GCC 1.40 is ancient, 1991 vintage, but even Linus Torvalds loved it!

For comparison, GCC 5.10 produces a 55,906 byte interpreter, while GCC 1.40 produces a 88,576 byte interpreter.

For an attempt at porting some code, I choose Nethack 1.3d, and used the MS-DOS based makefiles.  It didn’t work so well, but I was able to patch in enough of the unix based termios logic, and thanks to EMX/RSXNT’s built in termios capabilities I was able to get a working version!

Nethack 1.3d on Windows 10 x64

Nethack 1.3d on Windows 10 x64

I don’t know if there really was any advantage to compiling with GCC 1.40, but it was great to see that this 1991 compiler could handily compile the 1987 based code.

How about some speed comparisons?  I dug out the ancient dhrystone.c, and gave it a shot.  I had to define 500,000,000 passes, as my computer is fast.  GCC 1.40 only offers -O for optimization, while GCC 5.1 offers many more levels, but for this quick experiment they really aren’t needed.

D:\emx\demo\dhry>gcc140.exe
Dhrystone(1.1) time for 500000000 passes = 57
This machine benchmarks at 8771929 dhrystones/second

D:\emx\demo\dhry>gcc140_O.exe
Dhrystone(1.1) time for 500000000 passes = 40
This machine benchmarks at 12500000 dhrystones/second

D:\emx\demo\dhry>gcc510.exe
Dhrystone(1.1) time for 500000000 passes = 43
This machine benchmarks at 11627906 dhrystones/second

D:\emx\demo\dhry>gcc510_O.exe
Dhrystone(1.1) time for 500000000 passes = 16
This machine benchmarks at 31250000 dhrystones/second

D:\emx\demo\dhry>gcc510_O2.exe
Dhrystone(1.1) time for 500000000 passes = 14
This machine benchmarks at 35714285 dhrystones/second

D:\emx\demo\dhry>gcc510_Ofast.exe
Dhrystone(1.1) time for 500000000 passes = 11
This machine benchmarks at 45454545 dhrystones/second

As you can see, GCC 1.40 produces the slowest code.  While it’s optimized code did beat out GCC 5.10 with no optimizations, turning on optimizations did blow it away.  And again GCC 5.1 beat out the older 1.40 for executable sizes.

29,960 gcc510_O.exe
29,996 gcc510_O2.exe
30,472 gcc510.exe
70,656 gcc140_O.exe
74,752 gcc140.exe

And this time by over a 2x lead!  It is fair to say that the new versions of GCC, despite being significantly larger do indeed produce smaller and faster code.

For anyone who’s read this far, I guess you want to take it out for a test drive?  Remember it is still EMX based, which means is wants to live on the ROOT of your hard disk.  I’m using the ‘D’ drive for myself, so if you are using C or whatever you’ll need to alter the environment vars.

You can download the exe’s and combined source here: gcc-1.40_EMX-OS2_RSXNT.7z

[ANNOUNCE] DJGPP port of gcc-6.1.0

Posted on by
Reply

This is announcement of an update of DJGPP port of GCC-6.1.0

GCC used to stand for the GNU C Compiler, but since the
compiler supports several other languages aside from C,
it now stands for the GNU Compiler Collection.

See
https://gcc.gnu.org/ml/gcc/2016-04/msg00244.html
for original announcement of gcc-6.1.0 release

  • WARNING: This GCC port is for DJGPP v2.05 *
  • Build for DJGPP 2.03p2 is not and will not be available. *

Warning: DJGPP port of binutils-2.22 or newer is recommended.
Version 2.19 and 2.20 may work but are not tested
It is however recommended to use binutils-2.22
or newer

Use of DJGPP port of binutils-2.22 or newer is however required for

building gcc-6.1.0 for DJGPP.

Build for current stable version of DJGPP (djdev205) is
available
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/
and mirror sites (see http://www.delorie.com/djgpp/getting.html)

gcc610b.zip GNU GCC 6.1.0 for DJGPP V2
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gcc610b.zip

gcc610d.zip Documentation for GNU C compiler
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gcc610d.zip

gpp610b.zip GNU C++ Compiler 6.1.0 for DJGPP V2
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gpp610b.zip

gfor610b.zip GNU Fortan 95 compiler 6.1.0 for DJGPP V2
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gfor610b.zip

gcc610s.zip GNU GCC 6.1.0 sources for DJGPP
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gcc610s.zip

objc610b.zip GNU Objective C and Objective C++ compiler and
runtime libraries v6.1.0
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/objc610b.zip

gfor610d.zip Documentation for GNU Fortran compiler
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gfor610d.zip

ada610b.zip GNU Ada compiler
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/ada610b.zip

ada610d.zip Documentation for GNU Ada compiler
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/ada610d.zip

Binaries are built and tested mostly under Windows Vista Business (SP2)

Source RPMS needed for building Linux to DJGPP cross-compiler

Binary RPMs for both i686 and x86_64 are available. I built these binary RPMs
in CentOS 6.7 chroot under Fedora 23. Binaries are statically linked with GMP-6.1.0
MPFR-3.1.4 and MPC-1.0.3 to avoid unnecessary dependencies and increase
compatibility with other Linux distributions. For example they are expected
to work without problems in other reasonably recent Linux distributions
(like Fedora, RHEL-6 and newer, etc)

gcc610s2.zip is no more provided as patching GCC using DJGPP tools
has not been tested and even attempted by me for a long time.
DJGPP source file gcc610s.zip is a side product of building
gcc-6.1.0 Linux to DJGPP cross-compiler RPM packages. See source
RPM for patches applied to original FSF version of GCC-6.1.0.
You can find the same contents in the file

ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-gcc-6.1.0/djcross-gcc-6.1.0.tar.bz2
Cross-compiler SRPM:

ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-gcc-6.1.0/djcross-gcc-6.1.0-2ap.src.rpm

Cross-compiler binary RPMs (built under CentOS 5.11 i386, are expected to work on other recent enough RPM based Linux distributions, I myself have tried Fedora 19 x86_64):

GNU C compiler:
ftp://ftp.delori3.com/pub/djgpp/rpms/djcross-gcc-6.1.0/i686/djcross-gcc-6.1.0-2ap.i686.rpm

GNU C++ compiler:
ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-gcc-6.1.0/i686/djcross-gcc-c++-6.1.0-2ap.i686.rpm

GNU Ada compiler:
ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-gcc-6.1.0/i686/djcross-gcc-gnat-6.1.0-2ap.i686.rpm

GNU Fortran compiler:
ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-gcc-6.1.0/i686/djcross-gcc-gfortran-6.1.0-2ap.i686.rpm

GNU Objective C and Objective C++ compilers:
ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-gcc-6.1.0/i686/djcross-gcc-objc-6.1.0-2ap.i686.rpm

Tools for GCC 6.1.0 (currently only fixincl, most users do not need this):
ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-gcc-6.1.0/i686/djcross-gcc-tools-6.1.0-2ap.i686.rpm

Info files of GCC-6.1.0 (a separate RPM file as these files are expected to
conflict with system compiler info files, but You do not need to install them…):
ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-gcc-6.1.0/i686/djcross-gcc-info-6.1.0-2ap.i686.rpm

Substitute i686 with x86_64 For x86_64 binary RPMs in the URLs above.

You need also cross binutils (choose required binary RPM file or build from SRPM)
ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-binutils-2.24-1ap.src.rpm
ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-binutils-2.24-1ap.i686.rpm
ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-binutils-2.24-1ap.x86_64.rpm

You need also DJGPP development libraries, include files and some tools (eg. stubify)
ftp://ftp.delorie.com/pub/djgpp/rpms/djcrx-2.05-5.i686.rpm
ftp://ftp.delorie.com/pub/djgpp/rpms/djcrx-2.05-5.x86_64.rpm
ftp://ftp.delorie.com/pub/djgpp/rpms/djcrx-2.05-5.src.rpm
Note that one can use
ftp://ftp.delorie.com/pub/djgpp/rpms/djcrx-bootstrap-2.05-1.src.rpm

for bootstrapping

See
http://gcc.gnu.org/gcc-6
for more information about GCC-6.1.0 and about changes in comparison
with earlier versions

Also see file gnu/gcc-6.10/readme.DJGPP (from gcc610b.zip and
gcc610s.zip) for more information about this port.

There is also my web page about DJGPP port of GCC

http://www.iki.fi/andris.pavenis/djgpp/gcc

I cannot promise however, that I’ll update it very often.
However new versions may appear there earlier (including ones not available
from ftp://ftp.delorie.com).

Andris Pavenis <andris DOT pavenis AT iki DOT fi>

More fun with the System16, kinda, sorta?

Posted on by
10

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.