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.
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.
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.
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.
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 manage 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
Now with my executable, I can run it on MS-DOS & OS/2!
MS-DOS via DOSBox
and OS/2 2.0!
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
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
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.
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.
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.
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
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
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):
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).
After slightly more than a year since last major GCC release, we are proud
to announce new major GCC release, 6.1.
GCC 6.1 is a major release containing substantial new
functionality not available in GCC 5.x or previous GCC releases.
The C++ frontend now defaults to C++14 standard instead of C++98 it has
been defaulting to previously, for compiling older C++ code that might
require either explicitly compiling with selected older C++ standards,
or might require some code adjustment, see
http://gcc.gnu.org/gcc-6/porting_to.html for details. The experimental
C++17 support has been enhanced in this release.
This releases features various improvements in the emitted diagnostics,
including improved locations, location ranges, suggestions for misspelled
identifiers, option names etc., fix-it hints and a couple of new warnings
have been added.
The OpenMP 4.5 specification is fully supported in this new release, the
compiler can be configured for OpenMP offloading to Intel XeonPhi Knights
Landing and AMD HSAIL. The OpenACC 2.0a specification support has been
much improved, with offloading to NVidia PTX.
The optimizers have been improved, with improvements appearing in all of
intra-procedural optimizations, inter-procedural optimizations,
link time optimizations and various target backends.
See
https://gcc.gnu.org/gcc-6/changes.html
for more information about changes in GCC 6.1.
This release is available from the FTP servers listed here:
http://www.gnu.org/order/ftp.html
The release is in gcc/gcc-6.1.0/ subdirectory.
If you encounter difficulties using GCC 6.1, please do not contact me
directly. Instead, please visit http://gcc.gnu.org for information
about getting help.
Driving a leading free software project such as GNU Compiler Collection
would not be possible without support from its many contributors.
Not to only mention its developers but especially its regular testers
and users which contribute to its high quality. The list of individuals
is too large to thank individually!
While I was looking for System16 stuff, I found the first version of MAME to include the UAE 68000 core starting in release MAME 28, although System16 emulation itself didn’t appear until MAME 33b3, but not playable until MAME 33b4.
So what does it mean? Well at the time the UAE core was the way to go. However from looking at the MAME source, the UAE core that they were using from System16 was already generated, while UAE still included the build68k program to parse the tables, and generate the 68000. Instead they were editing the outputted C. UAE wasn’t GPL until version 0.7(something), 0.7.6 for sure, so I don’t know why they weren’t using it from the source.
Eventually starting in MAME 35b2, the core was replaced with MUSASHI , so Among their reasons for dumping the early UAE CPU core was this laundry list:
New 68000 C core. For testing purposes, this is also being used in the DOS
version instead of the asm core. [Karl Stenerud]
Differences:
1. Faster. This code is, barring ram fetch time, almost twice as fast as the existing C core in MAME. I’ve done extensive speed profiling on both engines. The only problem now is the slow memory access in MAME due to bankswitching et al.
2. Emulation more correct. I found many bugs in the MAME engine (and many, many more in mine for that matter) when I pitted them head-to-head. I have run random instructions from each opcode class at least 10 million times, comparing the resultant CPU states, and have left it running random instructions for 1 billion iterations. In every case, I have adhered to the specs defined in M68000PM/AD REV. 1.
3. Disassembler is correct. The current M68000 disassembler in mame has a tendency to disassemble instructions that have an invalid EA mode.
4. Cycle counting is 99.9% correct. The only instructions which don’t have correct cycle counts are divs, divu, muls, mulu, and they’re not worth counting correctly. (I’m not about to waste emulation time counting 0-1 and 1-0 sequences).
5. > 32 bit friendly. I’ve taken care to ensure maximum portability without sacrificing speed. The result is conditional compiling dependant on your architecture. I’ve also implemented and tested a compatible solution for architectures that lack 8, 16, or 32 bit signed storage types.
6. The code is carefully laid out to be readable.
Also in MAME 35b4 added in was emulation of the NEC uPD7759 chip for speech, fleshing out the System16 emulation.
To compile these ancient versions, and inbetween I was using my Candadian cross DJGPP GCC 4.12 Win32 cross compiler. For Allegro I’ve always found it builds far easier using GCC 2.7.2.1, a vintage compiler from back in the day I could just run in DOSBox.
Alien Syndrome
Obviously with today’s machines, these ancient versions of MAME run fine on DOSBox! It’s really amazing in the scope of emulators running emulators.
A long long time ago, back when I got a Pentium 100 the wonderful world of emulation was really starting to be possible with such a high powered CPU. First was the simple Game Boy emulators, then a Commodore 64 emulator, the incredible Amiga Emulator, the beginnings of SIMH (back when it was only a PDP-11 emulator), and then I found the SEGA emulator, System 16.
It was really cool being able to play 16bit arcade games on the desktop, although rather slowly. From there everyone knows the rise of MAME. But while looking around for a small 68000 C compiler, I came across the source code to an older version of System 16, 0.53 on archive.org. Naturally it’s for MS-DOS, as was everything back in the day. Also slightly interesting is the 68000 emulation, written by Bernd Schmitd of UAE fame. So for the heck of it, I set about getting Thierry Lescot’s System 16 building again. I’ve never used allegro before, so it was a bit of a fight to get a version of it to actually build. It turns out that I should have been building version 2.11 with tools of that era (why on earth was I using GCC 4, and binutils 2.18?) and instead stick with GCC 2.7.2.2 and some much older binutils. And in no time I had build the library, and it’s examples. With that done, I was able to re-build System 16 with GCC 4.1.2 and get a binary!
Back in the day, I actually did have an Altered Beast arcade board. Sadly, it died in a move, someone near and dear just saw the PCB as “garbage” and tossed it. Sigh, but I did have ROM dumps, as I did a refresh of it forever ago. Anyways I still have the ROM files, so I guess that is nice.
Anyways I fired up the emulator and got what is known as the “jail bar” effect, which is from a bad ROM.
Corrupt tiles
Notice the sprites
The System 16 splits it’s memory into a program space, a sprite memory bank, a tile memory bank, and RAM for stack and things like the palette. As you can see the program is certainly running, and the sprites are good. I did some poking around a bit later, and noticed that due to a logic bug, the texture ROMs are actually never loaded!
So, a quick patch, and now we get Altered Beast up and running!
Altered Beast title screen
demo play
Well, now isn’t that great!
Not that I would imagine anyone would really care, I mean MAME is a thing, and even from the readme:
Altered Beast : No sound emulation
So it’s pretty quiet. Additionally, the source is pretty restrictive:
These sources can’t be used for commercial purpose, any new version of the
emulator done with these sources must specify my name somewhere on the screen
et docs and I must be informed about any new release of the emulator.
In a round about way I was looking at old NeoGeo hardware having seen the ‘NeoGeo X’ android device for sale. Â In a round about way I stumbled onto this page detailing various homebrew projects. Â I saw the Neo Thunder, which looked interesting, and more importantly included source code!
What was even better is that there was a download of the full toolchain + emulators to get it up and running! Â I downloaded it, and hit the wall quickly as this was built with cygwin circa 2001, which means it will forkbomb any post Windows XP SP2 system.
Well, I couldn’t just let it die on the vine, so I turned back to my Canadian cross compiler build machine, and quickly built a m68k-elf tool chain. Â As always, first build a native cross compiler for later building libgcc.a and friends. Â I use a 32bit version of Linux with a downgraded MinGW environment so I can use Binutils 2.25.1 and GCC 4.1.2
For anyone who cares, this is my configure strings:
I patched up makefiles to my liking, and I could build all the libs, and all of the sample code (well except for the c++ one, because I couldn’t be bothered to build a c++ compiler). Â Some of it runs, some doesn’t I’m not sure what is going on. Â But for what it’s worth, Neo Thunder actually builds and runs (on mame!).
As always you can MinGW-M68K-ELF(neogeo).7z on my site. Â Be sure to read the 404 page for the username password, as it auto-generates from time to time. Â I don’t know if anyone will care, but it was kinda cool to track down the needed bits, and build out a working version of Neo Thunder.
