Author Topic: more gcc insanity!  (Read 5680 times)

Offline neko68k

  • MassiveMember
  • ****
  • Posts: 287
Re: more gcc insanity!
« Reply #120 on: October 14, 2016, 12:02:45 am »
Doom at 40mhz on a 386 wasn't written entirely in C.

Offline kamiboy

  • ThrobbingMember
  • *****
  • Posts: 542
Re: more gcc insanity!
« Reply #121 on: October 14, 2016, 12:09:17 am »
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.

Offline neko68k

  • MassiveMember
  • ****
  • Posts: 287
Re: more gcc insanity!
« Reply #122 on: October 14, 2016, 12:11:19 am »
Almost the entire game can be ported from well tuned Amiga source. I'm just not that interested.

Offline neozeed

  • BigMember
  • ***
  • Posts: 81
Re: more gcc insanity!
« Reply #123 on: October 14, 2016, 06:59:42 pm »
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.

Offline neozeed

  • BigMember
  • ***
  • Posts: 81
Re: more gcc insanity!
« Reply #124 on: October 14, 2016, 07:03:04 pm »
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.

Offline kamiboy

  • ThrobbingMember
  • *****
  • Posts: 542
Re: more gcc insanity!
« Reply #125 on: October 14, 2016, 10:18:54 pm »
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.

Offline neko68k

  • MassiveMember
  • ****
  • Posts: 287
Re: more gcc insanity!
« Reply #126 on: October 15, 2016, 12:50:44 am »
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 :D 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. :P

Offline costa

  • MassiveMember
  • ****
  • Posts: 147
Re: more gcc insanity!
« Reply #127 on: October 23, 2016, 10:14:46 am »
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. :D

Offline neko68k

  • MassiveMember
  • ****
  • Posts: 287
Re: more gcc insanity!
« Reply #128 on: October 23, 2016, 10:48:12 am »

Offline neozeed

  • BigMember
  • ***
  • Posts: 81
Re: more gcc insanity!
« Reply #129 on: October 26, 2016, 11:09:21 am »
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. :D

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.

Offline neko68k

  • MassiveMember
  • ****
  • Posts: 287
Re: more gcc insanity!
« Reply #130 on: January 23, 2017, 10:28:46 am »
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.