more gcc insanity!

[neozeed]

Code Select Expand

D:\proj\142\gcc-1.42_x68000>gccnew.exe -v -c x.c
gcc version 1.30 Tool#2(X680x0)
hcpp.exe -v -undef -D__GNUC__ -Dmc68000 -Dhuman68k -DHUMAN68K -DMARIKO_CC -Dmariko_cc -D__mc68000__ -D__human68k__ -D__HUMAN68K__ -D__MARIKO_CC__ -D__mariko_cc__ x.c C:\Users\jason\AppData\Local\Temp\x.cpp
GNU CPP version 1.30 Tool#2(X680x0)
hcc1.exe C:\Users\jason\AppData\Local\Temp\x.cpp -quiet -dumpbase x.c -fhuman -version -o C:\Users\jason\AppData\Local\Temp\x.s
GNU C version 1.30 Tool#2(X680x0) (HAS Ver 3.XX syntax)
  compiled by GNU C version 5.1.0.
default target switches:
x.c:      5: Message:ì┼ôKë╗é═ìséφéΩé─éóé▄é╣é±
run68 has.x -e -w -u -i . C:\Users\jason\AppData\Local\Temp\x.s -o x.o
D:\proj\142\gcc-1.42_x68000>run68 ..\hlkb\hlk301.x x.o CLIB.L
D:\proj\142\gcc-1.42_x68000>run68 x
Hello x68000 from GCC 1.30 Tool#2(X680x0)!
D:\proj\142\gcc-1.42_x68000>ver

Microsoft Windows [Version 10.0.10586]


Oh yes, it's Mariko's GCC 1.42 from here, cross compled to run on Windows, and using run68 to run the assembler HAS & the linker HLK.

libgcc is missing and I need to figure out how to get it built, so floating point is out of the question, and I had to stub out ECVT & FCVT to satisfy printf.  But yeah, the GCC driver, the CPP preprocessor & CC1 compiler are native, while the assembler and linker are x68000 executables.  For now you have to manually link, as Im not brave enough to rip into gcc.c just yet, but I'm more so amazed that hello world runs! 

I know this is crazy out of date compared to lydux's work, but this should have a more robust libc ..... or so I'm hoping.

you can download gcc142_x68000.7z if you so wish.  I'm at the 'holy crap it compiled!' stage... so don't expect a lot from it.  I haven't cleaned anything up, so it's full of all kinds of loose ends.

[neko68k]

How fun. I was working on lydux newlib last night(fixed a small bug) and probably will some more today(got some time/date stuff to do). The mariko toolchain is a weird mishmash of stuff. The 2.x toolchain is a mess too. Libc is more complete but its a real mess. It might be more useful to just add XC style object formats to BFD in lydux toolchain that to use the ancient stuff.

[neozeed]

Oh absolutely it's ... interesting.  And I guess kind of typical for the era to rely on the native includes, libs, assembler, linker.  It reminds me of GCC on SGI, RS/6000, MacOS, etc.

I picked this version as it's much more smaller to really dive into, and I already have the old Linux GCC 1.40 with binutils running on Windows that can build Linux 0.10 & 0.11 kernels just fine.  I was really interested to see if I could build the x68000 version of GCC, since all it basically does is read text files.

I was surprised to find out that HAS & HLK have source, but both were written in assembly..

I have some time functions that I used for nethack, but I was beyond lost at that libc and where to impliment them... I guess it's like fixing stdio and file handling......   I really don't know.

I see the GCC 2 stuff uses a gas to has program, so it again relies on HAS.

[neko68k]

Everything relies on HAS, even inline asm is in the HAS syntax It spits out XC objects and HLK takes XC objects and spits out whatever(xfiles or...) The formats are pretty well documented but good luck making any changes to HAS and HLK, that shit is dense.

I'm trying to get POSIX file stuff and date/time stuff going in lydux newlib so I can port over libinet and friends. A lot of the existing stuff in lydux newlib is taken from the oldschool libc implementation. I'm hoping it won't be too horribly hard to do some new stuff. Seems like it will be ok-ish.

[neozeed]

Well I suppose it should be possible to add the XC format... although that too sounds like work! .. lol

I was wondering if DooM would compile and run if built with a HAS backend, as the lydux attempt got me an executable that as far as I can tell does't execute.

[neozeed]

Here this looks ineresting!

aout2hux!

http://netbsd.gw.com/cgi-bin/man-cgi?x68k/aout2hux+1+NetBSD-6.1

https://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/arch/x68k/stand/aout2hux/

So this converts a static a.out to an .x ....

[neko68k]

Isn't that what objcopy is for?

I'm getting kind of annoyed at some of this. Digging around in the old libc and some ioctl lib that libinet depends on and I found that they managed to implement open 3 times. Once in libc, again in libioctl with some additions for tty's and yet again in libinet with yet other changes for socket read/writes. There's more of this too... What the hell guys

[kamiboy]

If you guys should ever need inspiration for compiler related things to work on I would LOVE some sort of debugging capability. I think Ludux was working on something. I am pretty clueless about the way debugging works but I understand that the X68000 supported remote debugging using a serial cable, which can be emulated, or something. The guy doing the english XM6 is onboard as well, I contacted him and he said he would consider any necessary changes to the emulator to enable debugging, as long as we make it easy for him.

[neko68k]

There is a debugger in the IPL. It's what gdb on lydux repo is using. I've never used it though. I'm using a virtual serial null modem in windows to support some simple debug output. I just #screen /dev/ttyS0 on my vm and have it hooked up to those virtual com ports on both ends. It works well. You should be able to use gdb with a similar setup.

[neozeed]

Code Select Expand

del /F doom.a
..\run68 ..\ar.x /b doom.a am_map.o     doomdef.o    doomstat.o   dstrings.o   d_items.o         d_net.o      f_finale.o   f_wipe.o
..\run68 ..\ar.x /b doom.a g_game.o     hu_lib.o     hu_stuff.o   info.o       i_main.o     i_net.o      i_sound.o    i_system.o   i_video.o
..\run68 ..\ar.x /b doom.a m_argv.o     m_bbox.o     m_cheat.o    m_fixed.o    m_menu.o     m_misc.o     m_random.o   m_swap.o     p_ceilng.o
..\run68 ..\ar.x /b doom.a p_doors.o    p_enemy.o    p_floor.o    p_inter.o    p_lights.o   p_map.o      p_maputl.o   p_mobj.o     p_plats.o
..\run68 ..\ar.x /b doom.a p_pspr.o     p_saveg.o    p_setup.o    p_sight.o    p_spec.o     p_switch.o   p_telept.o   p_tick.o     p_user.o
..\run68 ..\ar.x /b doom.a r_bsp.o      r_data.o     r_draw.o     r_main.o     r_plane.o    r_segs.o     r_sky.o      r_things.o   sounds.o
..\run68 ..\ar.x /b doom.a st_lib.o     st_stuff.o   s_sound.o    tables.o     v_video.o    wi_stuff.o   w_wad.o      z_zone.o
..\run68 ..\..\hlkb\hlk301.x -o doom d_main.o missing.o doom.a gnulib.a gnulib2.a clib.l floateml.l

So this has ar build an archive.. Not sure how to convert it to a library.  I used GCC to build gnulib/gnulib2 ... although it says not to do it, but it shuts the linker up.... DooM is too big to run, as always.

Code Select Expand

30/08/2016  01:52 AM           363,514 doom.x

There is not supported relocated information

I saw something about setting relocation values in that aout2hux ... Maybe it needs to be linked to run at a different address?  I really don't know how x68000 memory works.  I guess since so many of them only have 1MB of ram, it must be treated as a low memory thing?  It's sounding like the old days of DOS extenders....

[neko68k]

this is getting complicated... I might just wind up doing a fairly complete port of the old school libc at this rate... too many tabs, too many files open. what folder was I in again? is this the right header or did I open the original? fuuuuuuuu

[kamiboy]

Don't quote me on this, but I very vaguely remember that you can access x68000 memory flatly using a 24bit address. So you can access up to 16mb freely using a pointer. But I had to enable some sort of super mode using a IOCTS call before I could access memory freely through pointers. You could also just allocate a huge chunk using DOS.

What exactly are you trying to do anyway, port doom to the X68000? I doubt that system can run such a game very well. Prolly single digit frame rate even on a XVI.

[kamiboy]

There is a debugger in the IPL. It's what gdb on lydux repo is using. I've never used it though. I'm using a virtual serial null modem in windows to support some simple debug output. I just #screen /dev/ttyS0 on my vm and have it hooked up to those virtual com ports on both ends. It works well. You should be able to use gdb with a similar setup.

I knew about the IPL, but I understand too little of it all to make it work. Can you walk me through it?

[neko68k]

@kamiboy

you have to enter supervisor mode to do a lot of things

Code Select Expand


(dos.h)
extern int _dos_super(int);

(yourprogram.c)
#include <dos.h>
int old_ssp = _dos_super(0);
// do stuff that needs supervisor mode
_dos_super(old_ssp);


No I can't help you with the IPL debugger. I've never used it. I think there's a key combo at boot to start it up. I'm not really sure but I do think it's a kernel debug terminal and not really just a program debugger. I don't really know anything about it. I can tell you that com0com is a good virtual null modem for windows. I just enable two virtual ports and point XM6G at one and VirtualBox at the other one. I just use it for printing messages over serial though, nothing fancy.

[neozeed]

Don't quote me on this, but I very vaguely remember that you can access x68000 memory flatly using a 24bit address. So you can access up to 16mb freely using a pointer. But I had to enable some sort of super mode using a IOCTS call before I could access memory freely through pointers. You could also just allocate a huge chunk using DOS.

What exactly are you trying to do anyway, port doom to the X68000? I doubt that system can run such a game very well. Prolly single digit frame rate even on a XVI.

It's more an exercise in getting the compiler to work.  Just as I'd love to see quake ported over as well, I know that even the 2-3 68060 machines could barely handle it, however I just want to see it, even it it really is only viable under emulation...

I went through hell to find XM6 TypeG 3.13 L40 so I can use the english menus....

[neko68k]

Tons of things have happened since English went away. Whatever floats your boat though.

[neozeed]

this is getting complicated... I might just wind up doing a fairly complete port of the old school libc at this rate... too many tabs, too many files open. what folder was I in again? is this the right header or did I open the original? fuuuuuuuu

That is pretty much my experience last time I looked...  Which is why I started to look at the old ports of GCC to the x68000, however I never could get them to run under emulation.  So a late night with no sleep, and after getting gcc 1.40 for Linux 0.10 to run Windows, I thought it would be fun to see if the x68000 GCC could run on Windows, and yes, it does! 

[neko68k]

I have an hds with working gcc, gcc2, has 3.x,has060 and a bunch of random shit if you want a copy. To be honest though, building any of the old programs is still a huge pain in the butt. Some of it is really dreadful. Versioning is hard to follow. There's almost always some patch or some dependency you have to scour the deepest, oldest parts of the Internet for. There's fun to be had but it's pretty trying all around.

[neozeed]

I have an hds with working gcc, gcc2, has 3.x,has060 and a bunch of random shit if you want a copy. To be honest though, building any of the old programs is still a huge pain in the butt. Some of it is really dreadful. Versioning is hard to follow. There's almost always some patch or some dependency you have to scour the deepest, oldest parts of the Internet for. There's fun to be had but it's pretty trying all around.

It may help.  I just found out the Sharp/Hudson c compiler it total crap.

If it has an error in the code, it prints the line number of the COMBINED source.  Like WTF!  So I have to go through the source, and include the files manually to even begin to figure out where line 2600 is on a file that is only 400 lines long... Like how on earth could they screw this up?  or am I just using the compiler wrong...?

[neozeed]

OK, so a bit more digging and I found out that libgcc was a separate thing back in the day.

I saw it mentioned here:

http://www.xps.jp/cgi/bbs2/wforum.cgi?no=1413&reno=1404&oya=1404&mode=msgview&page=30

with a download here.
http://kuwa.xps.jp/x68k/KGARC/ARC/LGCC_P6.ZIP

I thought I'd try to build the old 1987 infocom interpreter ...
http://www.planetemu.net/rom/tandy-radio-shack-trs-80-model-1/infocom-adventure-executor-source-files-1987-infotaskforce-c

In file.c I had to MS-DOS ify it by changing the file modes to binary (r/rb) (w/wb) etc.  minor change.  I used run68 and the binary dist to compile.  Basically running this against all the C files:

Code Select Expand

run68 gcc -S -Iinclude %1.c
run68 has.x -e -w -u -i. %1.s -o %1.o

And trying to link like this:

Code Select Expand

run68 gcc infocom.o infocom.a -o infocom FLOATEML.L

After I'd combined all the objects except for the 'main' one into a library, like what I did with DooM.  OK, and it'll bomb on the libgcc not being found.  I extracted the libgcc source, and built the only needed symbols with HAS.  I should say this is *NOT* the typical libgcc nice highlevel, but a direct port.

Code Select Expand

del /F ..\gnulib.a
del /F *.o
..\run68.exe ..\has.x -DUSE_FLOAT _divsi3.s
..\run68.exe ..\has.x -DUSE_FLOAT _modsi3.s
..\run68.exe ..\has.x -DUSE_FLOAT _mulsi3.s
..\run68.exe ..\has.x -DUSE_FLOAT _divmodsi3.s
..\run68.exe ..\ar.x /b ..\gnulib.a _divsi3.o _modsi3.o _mulsi3.o _divmodsi3.o


Note the USE_FLOAT!!! ... And of course back above, I linked with the floating point emulation library.

Code Select Expand


D:\proj\142\gcc-1.42_x68000\bin>run68 infocom planetfa-37.z3
PLANETFALL
Infocom interactive fiction - a science fiction story
Copyright (c) 1983 by Infocom, Inc. All rights reserved.
PLANETFALL is a trademark of Infocom, Inc.
Release 37 / Serial number 851003

Another routine day of drudgery aboard the Stellar Patrol Ship Feinstein. This
morning's assignment for a certain lowly Ensign Seventh Class: scrubbing the
filthy metal deck at the port end of Level Nine. With your Patrol-issue
self-contained multi-purpose all-weather scrub brush you shine the floor with a
diligence born of the knowledge that at any moment dreaded Ensign First Class
Blather, the bane of your shipboard existence, could appear.

Deck Nine
This is a featureless corridor similar to every other corridor on the ship. It
curves away to starboard, and a gangway leads up. To port is the entrance to
one of the ship's primary escape pods. The pod bulkhead is closed.

Deck Nine                            Score: 0/4451
>


So the upshot, is that LIBC works normally.  I only had to change some file mode code, as to be expected.  I'm still relying on the native HAS/SILK linker.. But hey, it worked!

[neozeed]

Holy crap.  So I re-built libgcc as the one included in the archive for some reason doesn't work.

I don't have a proper 'null' version, so this is only a WOW GCC 1.3 with the Sharp LIBC actually can do some real stuff....

[corpsicle]

Awesome! Is this the last system in the world to get Doom?

[neko68k]

wow, nice job man!

[neozeed]

Awesome! Is this the last system in the world to get Doom?

It's a long long way away from anything....   And if I did it, it would only be practical on emulation...   but where the lydux tool chain broken, this one is running...  ill have to see if the later gcc 2 stuff has reproducible source as I'd rather not use gcc 1.3 ..

[neozeed]

wow, nice job man!

I just got lucky, my Google skills are getting better, we're just lucky x68000 fans are big packrats !!!!

[kamiboy]

T

Awesome! Is this the last system in the world to get Doom?

It's a long long way away from anything....   And if I did it, it would only be practical on emulation...   but where the lydux tool chain broken, this one is running...  ill have to see if the later gcc 2 stuff has reproducible source as I'd rather not use gcc 1.3 ..

You can say that again. The differences in architecture are large enough that my head spins at the programming hurdles that one would need to overcome in order to get any graphic to display on an x68000.

[neozeed]

You can say that again. The differences in architecture are large enough that my head spins at the programming hurdles that one would need to overcome in order to get any graphic to display on an x68000.

I found some aviplayer ... it looks somwhat sane to display video.

http://retropc.net/x68000/software/movie/avi/aviplay/
And it can play this avi:
http://cd.textfiles.com/mmplus/MEDIA/VIDEO/AVI/NATURE/FALL.AVI

But I guess it doesn't matter, I fixed up the endian code to actually run, so now it can read the wad file, but once it tries to malloc some measily 68KB of RAM it falls over.  I have xm6 configured for 12MB of ram, which should be more than enough for DooM, but I can't malloc all that much memory. sigh.

[neko68k]

have you set the CPU to run in supervisor mode?

[neozeed]

have you set the CPU to run in supervisor mode?

Noon..... I didn't think that had anything to do with using libc malloc/realloc ..  Ill have to see how to do it.

[neko68k]

I'm pretty sure I posted above about it. It's basically required to do any fancy memory stuff. You'll need it for writing to GVRAM and setting screen modes and stuff anyway.

[neozeed]

I'm pretty sure I posted above about it. It's basically required to do any fancy memory stuff. You'll need it for writing to GVRAM and setting screen modes and stuff anyway.

I can only find mention of a STACK call in the doslib.h ...

from: http://mijet.eludevisibility.org/X68000%20Technical%20Documents/English%20X68k%20Docs/DOS_en.txt

$FF20 ; SUPER(STACK) Switch between Supervisor Mode / User Mode

Example:
   LEA   USERSP,SP
   CLR.L   -(SP)   * Here, STACK = 0
   DC.W   _SUPPER
   ADDQ.L   #4,SP   * (SP) is trashed, so discard it

   MOVE.L   D0,SSPBUF
   MOVE.L   USP,A0
   MOVE.L   A0,USPBUF

   ...   * Additional code in Supervisor Mode

   MOVE.L   USPBUF,A0
   MOVE.L   A0,USP

   MOVE.L   SSPBUF,-(SP)
   DC.W   _SUPER
   ADDQ.L   #4,SP   * (SP) is trashed, so discard it
   ...
USPBUF:   DC.L   0   * USP BUFFER
SSPBUF:   DC.L   0   * SSP BUFFER

Returns:
   D0.L   If STACK = 0, this will be the previous value of SSP.
      The return value will be negative if an error occurred.

Switches between Supervisor Mode and User Mode.

The characteristics of STACK are defined as follows:
STACK  = 0 : USP is copied to SSP, context switches to Supervisor Mode.
STACK >< 0 : STACK is copied to SSP, context switches to User Mode.

HAS doesn't like it thought....

temp\i_main.s       20:   illegal relative error

and line 20 is the jbsr to _SUPER ...

Code Select Expand

_main:
link a6,#0
move.l 8(a6),_myargc
move.l 12(a6),_myargv
pea 1.w
jbsr _SUPER
jbsr _D_DoomMain


[neko68k]

It looks like I'm actually using the iocs version of the super call. I don't know what the difference is. It does switch to a different stack but it also changes context in the CPU.

Code Select Expand


int ssp; // old ssp
ssp = _iocs_b_super(0); // switch to supervisor mode
...
_iocs_b_super(ssp); // return to user mode


[kamiboy]

One potential issue that comes to mind, Doom runs in DOS mode 13h, which gives you flat access to video memory for a 320x200 resolution using one 8bit index palette colour value for each pixel.

The x68000 does give you free access to the memory, but the palette of the X68000 works differently from DOS mode 13h. Instead of one single 256 colour palette you have 16, 16 colour ones, with the first colour always being transparant. So if you try to recreate the DOS palette used by doom you will be 16 colours short due to the transparent colours.

It is possible that doom does not actually use all 256 colours of the dos palette, but I think it is likely that it does.

[neko68k]

You're thinking about PCG. GVRAM can be split up:

16-bit one page
8-bit two page
4-bit four page

PCG uses the second 256 colors as 16, 16 color palettes, The 8 and 4 bit GVRAM modes use the first 256 or 16 entries in palette RAM. Access to GVRAM is word size and pixels are stored 0x00nn or 0x000n. In this case there is only one transparent index, index 0(unless special modes are used, I've already discussed this in another thread). 16-bit is a bit different, you should reference Inside X68000 if you want to know how that is laid out. It's swizzled a bit and obviously doesn't use the palette at all. Furthermore, PCG palette 0 is also the TVRAM palette.

This is a 512x512 8-bit color image loaded into GVRAM page 0. You can clearly see its palette stored in the top half of the palette window.


What's even more interesting is that we might be able to use the 512x512 setup and set the CRTC registers to actually put out 320x200 and get double buffering out of it too because theres so much GVRAM not being used after the CRTC changes plus the entire second empty GVRAM page.

[kamiboy]

Bah, I knew all this a few years back when I researched the x68000 thoroughly, but I've forgotten everything it seems. You are right, the x68000 has many viable alternatives to PCG.

[neozeed]

So I tried this to get around HAS not wanting to assemble the SUPER call...

Code Select Expand

#include <iocslib.h>
#undef SUPER
extern int    SUPER(int);

int
main
        ( int argc,
        char**        argv )
{
int b_ssp;
int ssp;
myargc = argc;
myargv = argv;
ssp=sUPER(0);
b_ssp=B_SUPER(0);
D_DoomMain ();

Then I hex edited the object to replace sUPER with SUPER .... and it locks after the V_Init...  Even the B_SUPER it locks in the same area.  Without going to supervisor mode it gets further but doesn't have enough memory....

Code Select Expand

                            DOOM Registered Startup v1.10                           
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
Z_Init: Init zone memory allocation daemon.
W_Init: Init WADfiles.
adding ./doom.wad
lumpinfo is 1c4ce8
need 2306 lumps 46120 bytes
lumpinfo is 0
Error: Couldn't realloc lumpinfo


bummer. 

[neozeed]

OK OK.. .so libc's malloc sucks.  calling the syscall MALLOC is much better.  I still don't know why GCC barfs on this, so I have to hex edit the objects from mALLOC to MALLOC ... wtf?!

Code Select Expand

                            DOOM Registered Startup v1.10                           
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
Z_Init: Init zone memory allocation daemon.
W_Init: Init WADfiles.
adding ./doom.wad
===========================================================================
                 Commercial product - do not distribute!
         Please report software piracy to the SPA: 1-800-388-PIR8
===========================================================================
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon - [                          ].....
InitTextures
InitFlats............
InitSprites
InitColormaps
R_InitData
R_InitPointToAngle
R_InitTables
R_InitPlanes
R_InitLightTables
R_InitSkyMap
R_InitTranslationsTables
P_Init: Init Playloop state.
I_Init: Setting up machine state.
D_CheckNetGame: Checking network game status.
S_Init: Setting up sound.
HU_Init: Setting up heads up display.
ST_Init: Init status bar.


I need to re-look at the source on Windows and then some big endian OS to make sure it's running in a good null state to re-visit it... but yeah..... 

[neko68k]

Oh nice. You got a repo somewhere?

[neozeed]

Oh nice. You got a repo somewhere?

No.... I should though, shouldn't I?

My code is a laughable mess.

Let me slap something together.....

[neozeed]

OK repo is here:

https://sourceforge.net/p/x68000-doom/code/ci/master/tree/

I don't see any point in doing a binary...... As it doesn't work.

Anyways I run 'make' to well... make. 

to link in the linux directory ( I know rename it!) just run link.cmd which will create a doom library that lk can link against instead of freaking out that the command line options are too long.

hopefully it's not too hard to see the changes, although I should have re-run uncrustify, I guess for that intermediary step, but I didn't.

--edit

Don't go too crazy, I'm going to re-port stuff back from the old DOSDoom, which I have running NULL on Windows, then port back to x68000 ..... sigh I know. maybe a new topic?