more gcc insanity!

[neko68k]

Doom at 40mhz on a 386 wasn't written entirely in C.

[kamiboy]

Well, there is that of course. Maybe a wizard level coder could rewrite the inner most loops in assembly and make it playable at 40mhz.

[neko68k]

Almost the entire game can be ported from well tuned Amiga source. I'm just not that interested.

[neozeed]

Doom running on hardware. https://twitter.com/pipixvi/status/785991914306674688

wow that's amazing!  I wonder what the specs are.  I tried to leave a commet on the blog, but '投稿を受け付けることができません。' .... You will not be able to accept the post.


Sigh.  Oh well.

[neozeed]

Well, there is that of course. Maybe a wizard level coder could rewrite the inner most loops in assembly and make it playable at 40mhz.

Don't forget we are using GCC 1.40 which is not exactly the fastest C compiler out there.  The 2.x series of GCC is much faster, especially once they remerged the EGCS stuff back intro the tree in the 2.95 releases. 

This is the downfall that lydux's toolchain for whatever reason can't even get a NULL version of DooM running, and we have this ancient compiler version that is 100% C...  There wasn't a crazy amount of ASM in the i386 version of DooM.  The Jag version uses a bunch, but you'll have to port the ASM syntax and all that fun.

If it was 1994-1997 you would still have that viability window, and all the work would make sense.  This is more a 'holy crap!' type thing... and it's impressive on it's own.

[kamiboy]

I believe the specs are written in the video description. Neptune-X 40mhz, if memory serves me right.

In any regard, you are certainly right that this project exits but for the novelty of it. There is not point in doing a proper port of DOOM for the X68000. In terms of Japanese computers there is already a perfect port for the PC98, and in general terms one is already spoilt for choice as to platforms to play the game on.

Even if someone put in the effort one a tiny fraction of X68000 owners could benefit from it since it would require a pretty hefty and rare CPU accelerator board to be playable even after assembly optimisation.

The Lydux toolchain not working is unfortunate, but I can use it in my personal projects so I am happy. I  ran into a problem a while back that had to do with word sized memory alignment of structs. Perhaps that might be the source of your troubles as well. At least if you are using any DOS or IOCTS calls.

[neko68k]

I believe the specs are written in the video description. Neptune-X 40mhz, if memory serves me right.

In any regard, you are certainly right that this project exits but for the novelty of it. There is not point in doing a proper port of DOOM for the X68000. In terms of Japanese computers there is already a perfect port for the PC98, and in general terms one is already spoilt for choice as to platforms to play the game on.

Even if someone put in the effort one a tiny fraction of X68000 owners could benefit from it since it would require a pretty hefty and rare CPU accelerator board to be playable even after assembly optimisation.

The Lydux toolchain not working is unfortunate, but I can use it in my personal projects so I am happy. I  ran into a problem a while back that had to do with word sized memory alignment of structs. Perhaps that might be the source of your troubles as well. At least if you are using any DOS or IOCTS calls.

XVI with 40MHz Xellent30. Accelerators are more common than I expected. I have 9 reported out of 40 respondents plus someone with a CPU overclock. I think that's mostly Western users too. The Japanese scene could be quite a bit different.

There are several issues with the Lydux toolchain. The linker scripts don't produce correct relocation data, so Doom doesn't work. The Newlib implementation is also extremely incomplete and the work involved in getting it up to speed is no small feat.

I'm just happy that we got it to run at all. If anyone wants to get it going on lesser machines; the source is there. It gave me an excuse to learn how to use the TVRAM write and simultaneous access masks which I am now using in my own project. I also know how to use the X68 network stack now. It's useless for streaming because it doesn't have any async I/O(no async file I/O at all actually, not just sockets), all the calls are blocking and there are no timeouts for failure to read/write a socket. It's not great On that note, networking in Doom does almost work. I tested it quite a bit against XDoom in a Linux VM but the X68 side pretty much falls over because of the limitations I mentioned.

Well, there is that of course. Maybe a wizard level coder could rewrite the inner most loops in assembly and make it playable at 40mhz.

Don't forget we are using GCC 1.40 which is not exactly the fastest C compiler out there.  The 2.x series of GCC is much faster, especially once they remerged the EGCS stuff back intro the tree in the 2.95 releases. 

This is the downfall that lydux's toolchain for whatever reason can't even get a NULL version of DooM running, and we have this ancient compiler version that is 100% C...  There wasn't a crazy amount of ASM in the i386 version of DooM.  The Jag version uses a bunch, but you'll have to port the ASM syntax and all that fun.

If it was 1994-1997 you would still have that viability window, and all the work would make sense.  This is more a 'holy crap!' type thing... and it's impressive on it's own.

It also doesn't help that i386 Doom was originally built with a commercial compiler. I forgot EGCS was a thing. You're making me feel old.

[costa]

Is this updated / latest / greatest version of this C toolchain available for download - it it could compile a full project like Doom to a working game, it should be possible to do simpler things like device drivers, ROM modifications, etc.

[neko68k]

Here ya go. https://sourceforge.net/projects/gcc-1-30-x68000/files/

[neozeed]

Is this updated / latest / greatest version of this C toolchain available for download - it it could compile a full project like Doom to a working game, it should be possible to do simpler things like device drivers, ROM modifications, etc.

Well it's not late by any stretch... but it's great as it actually can build stuff.  There is ONE big flaw though, when doing bitwise operations the cross compiled stuff on GCC 1.4x keeps it in the host order.  I built a x86->68020 based SUN compiler as a test, and when doing the endian specific code for DooM, it also did the same thing.

I guess I should dig in the source, find out where the instructions are emitted, back trace it to find out how the ASM code is generated, and htonX it...

What little source fragments of the GCC 2.x stuff I could find is incomplete.  And it all relies on tools like gas2has ... and of course it's all HAS + Sharp compatible linker backend.

[neko68k]

I don't know if there's still interest here but I got gcc 2.6.3 to work. There's some really serious visual corruption though It seems to perform pretty well on 50mhz 060 though.

[neozeed]

I don't know if there's still interest here but I got gcc 2.6.3 to work. There's some really serious visual corruption though It seems to perform pretty well on 50mhz 060 though.

There is always interest!

the visual corruption is some nonsense on I think it's the boolean type was a word (size 4) and now it's a byte (size 1) ... IIRC.

post how you got gcc2 to work!!!

[neko68k]

I redid my developer HDD a while back. It's all cleaned up and reasonably well organized You should grab a copy.

It seems fairly correct and up to date. It includes all 3 toolchains, XC, GCC 1.30 patchlevel 5, and GCC 2.6.3, all the usual libs and some other ones too(libnetwork<-BSD sockets There's a debugger in there too, SCD. It's pretty decent. It's sort of graphical. It shares a bunch of commands with DB, the other debugger. You can search for labels and click for breakpoints and a ton of other stuff.

The Doom source in there is a little more recent than whats on the repo. It has networking hooked up but it doesn't really go. I tested it against linuxdoom on NetBSD x86 and it'll initially connect but it fails waiting for some packet that seems to be sent but it just disappears into the ether.

You can look in /proj/doom and run make and it'll build with GCC2. If you make -f Makefile.gcc it'll build with GCC instead.

I must have mixed up screenshots before. That one is with this GCC and actually any version of the Doom source. With GCC2 the corruption is similar but worse. I went back to some known working code and it does the same thing. So it must be in the libs or maybe I'm off a version on the assembler, I have no clue. All three GCC builds I know of have the same issue. I haven't managed to test a different LIBC. There is an allegedly updated LIBC 1.1.32A DON version, that didn't work for me at all. I could go back to the libs we've been using in the Windows tools but those didn't work with GCC2. There is also that newer build GCC 2.95.2 but I haven't been able to get that to work either. Clearly more investigation is necessary. It'd be so good to have GCC2 working.

GCC2
GCC1

[neozeed]

the GCC2 corruption sure looks a lot like when I was facing the endian issue with GCC 1 ...  Oddly enough I would have expected 2 to be ok, as gcc 1 didn't seem to have anything about cross compiling from little to big endian..