- XM6 X68000 EMULATOR DRIVER
- XM6 X68000 EMULATOR FULL
- XM6 X68000 EMULATOR PORTABLE
- XM6 X68000 EMULATOR PC
I tried downloading GCC 1.42 and building an i386 SYSV to AT&T 3b1 cross compiler as it too is 68000 based, and I got the same issue. I tried re-building, re-configuring my host setup, and I still had the same issue.
After some investigating it turns out that m_swap was not being compiled correctly but rather the endian order was being reversed!
XM6 X68000 EMULATOR DRIVER
Then with a lot of improvements, and an added keyboard driver it was starting to look like DooM!Īnd then Neko68k had a major breakthrough with the video, timer and keyboard, and we now have a playable port! Issues while cross compilingĪround this time I had noticed that when I built a cross compiled version the video for me was garbled. There is no correct palette setup at this point, there is all kinds of issues but you can see the startup logo being painted! Null DooM running on the 圆8000 DooM comes to lifeįrom there, Neko68k was able to do something amazing, add in system support! Which to be honest would have taken me forever to do, I was more impressed that I was even able to get the null version running, but Neko68k blew me away with this:
I could then get from failing malloc to this: Once when he shared his disk image, I was able to see how his GCC setup worked, and more importantly linked, so I could alter the GCC cross compiler I was using, and get much further in terms of progress. I wasted some time by trying to bypass the Sharp LIBC malloc function by calling the HumanOS’s malloc directly which did get further but ran into issues when switching from usermode to supervisor mode to directly access the hardware. Over on nfggames Neko68k had mentioned that he had a disk image with a working version of GCC, that uses different includes/libraries that was able to get further. Starting the actual port aka platform issuesįor some reason the SHARP/Hudson LIBC has issues doing a realloc. After it was running with minimal changes, it was time to start the real fun.
(Sprite)(Disk_1_of_2)-2.png "xm6 x68000 emulator"){kind=icon}
I figured that by having a ‘known good’ build with the a very close compiler level would be a good start as I don’t want to fight too much with the compiler. Having learned the ‘null’ lesson of Quake 2 the hard way, I started out with a working copy from Windows, via GCC 1.40 for Windows/RSXNT. To convert C++ comments to C is quite simply:Īnd away we go. The key thing is the configuration file that tells uncrustify what to do.
Uncrustify.exe -replace -c 1.cfg cl_main.h The pain is that it doesn’t seem to take wildcards, but you can use make to have it do your work for you, or just a batch file… In order to convert the comments, I came across this great tool, uncrustify. So the first phase was to convert all the comments.
XM6 X68000 EMULATOR FULL
Since I’m using such an ancient version of GCC the first stumbling block is that DooM is FULL of C++ style comments, which older K&R & ansi based compilers of the late 1980’s simply cannot handle. One platform that mysteriously was lacking DooM was the SHARP 圆8000.Īfter a bored day of playing with the source to Mariko’s GCC 1.42 / 1.30 that targets the 圆8000, I thought I would take a stab at trying to compile DooM.
XM6 X68000 EMULATOR PORTABLE
And thanks to it being written in C is also an incredibly portable game.
XM6 X68000 EMULATOR PC
DooM is without a doubt one of the most popular PC games of all time.
0 kommentar(er)
