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 (http://retropc.net/x68000/software/develop/c/gcc_mariko/), cross compled to run on Windows, and using run68 (https://sourceforge.net/projects/run68/) to run the assembler HAS (http://retropc.net/x68000/software/develop/as/has/) & the linker HLK (http://retropc.net/x68000/software/develop/lk/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 (http://vpsland.superglobalmegacorp.com/install/x68000/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.
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. :)
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.
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.
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.
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 ....
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 :(
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.
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.
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.
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....
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
(https://i.imgur.com/YiRuH0fl.png) (https://imgur.com/a/BbBgc)
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.
Quote from: neko68k on August 30, 2016, 02:46:42 AM
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?
@kamiboy
you have to enter supervisor mode to do a lot of things
(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.
Quote from: kamiboy on August 30, 2016, 07:24:48 AM
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....
Tons of things have happened since English went away. Whatever floats your boat though.
Quote from: neko68k on August 30, 2016, 07:17:10 AM
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! :)
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.
Quote from: neko68k on August 30, 2016, 12:08:46 PM
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...?
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:
run68 gcc -S -Iinclude %1.c
run68 has.x -e -w -u -i. %1.s -o %1.o
And trying to link like this:
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.
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.
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!
(http://i.imgur.com/An5IGkj.png)
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....
Awesome! Is this the last system in the world to get Doom? :D
wow, nice job man!
Quote from: corpsicle on August 31, 2016, 01:47:50 AM
Awesome! Is this the last system in the world to get Doom? :D
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 ..
Quote from: neko68k on August 31, 2016, 01:54:21 AM
wow, nice job man!
I just got lucky, my Google skills are getting better, we're just lucky x68000 fans are big packrats !!!!
T
Quote from: neozeed on August 31, 2016, 09:42:33 AM
Quote from: corpsicle on August 31, 2016, 01:47:50 AM
Awesome! Is this the last system in the world to get Doom? :D
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.
Quote from: kamiboy on August 31, 2016, 05:46:13 PM
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.
have you set the CPU to run in supervisor mode?
Quote from: neko68k on August 31, 2016, 11:57:37 PM
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.
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.
Quote from: neko68k on September 01, 2016, 12:16:04 AM
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
Quote$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 ...
_main:
link a6,#0
move.l 8(a6),_myargc
move.l 12(a6),_myargv
pea 1.w
jbsr _SUPER
jbsr _D_DoomMain
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.
int ssp; // old ssp
ssp = _iocs_b_super(0); // switch to supervisor mode
...
_iocs_b_super(ssp); // return to user mode
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.
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.
(https://i.imgur.com/nXrvgE0m.jpg) (https://i.imgur.com/nXrvgE0.jpg)
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.
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.
So I tried this to get around HAS not wanting to assemble the SUPER call...
#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....
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. >:(
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?!
(http://i.imgur.com/KZ8i0gP.png)
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..... :P
Oh nice. You got a repo somewhere?
Quote from: neko68k on September 01, 2016, 03:12:39 PM
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.....
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?
I was busy with work today but I did find an hour to play some more, and re-do the source from DOSdoom (http://doom.wikia.com/wiki/DOSDoom) as a reference, and now it loads up without crashing on XM6 in 68030 mode with 12MB of ram! .... From there it'll complain about the Demo being from a different game.
No video, no keyboard even! .... I had to remove the supervisor code otherwise it just locks.
I need to play more with the compiler to figure out why I can't directly call MALLOC, I don't like having to hex edit the object files, but I did make it so now I only have to edit a single file (missing.o)
i_system.c won't build for me and I'm not really sure what you were trying to do there. This bunch of stuff exists at file scope and, well, it doesn't make sense :D
/* */
/* I_GetTime */
/* returns time in 1/70th second tics */
from toplev.c / GCC 1.42
#ifdef __human68k__
return ONTIME ()* 10000;
#else
#ifdef USG
times (&tms);
return (tms.tms_utime + tms.tms_stime) * (1000000 / HZ);
[edit]
I mean, I can comment that out. Just not sure if you were meaning to do something there or if its just leftovers.
Quote from: neko68k on September 02, 2016, 02:27:09 AM
i_system.c won't build for me and I'm not really sure what you were trying to do there. This bunch of stuff exists at file scope and, well, it doesn't make sense :D
/* */
/* I_GetTime */
/* returns time in 1/70th second tics */
from toplev.c / GCC 1.42
#ifdef __human68k__
return ONTIME ()* 10000;
#else
#ifdef USG
times (&tms);
return (tms.tms_utime + tms.tms_stime) * (1000000 / HZ);
[edit]
I mean, I can comment that out. Just not sure if you were meaning to do something there or if its just leftovers.
I meant to put that block in comments.... I was re-diffing my changes to GCC, when I saw in toplev.c how the x68000 port of GCC figures out how much time it spent doing something, which for the sake of quickly porting I don't care about, but I saw the ONTIME system call, so I wanted to remember it.... which seemed like a good plan, but I didn't wrap it in /*** ****/ .....
Also I just re-diffed gcc 1.42 vs 1.30 x68000 which really is 1.42, and I was thinking of putting all the errors and warnings back in English....... Yeah i know that won't win me any fans.
That'd sure be nice. I'm trying to get it built with my gcc2 toolchain. I'll keep you posted.
Bus error...
And GDB runs out of memory trying to load a debug build
(https://i.imgur.com/FqFgqGtm.png) (https://i.imgur.com/FqFgqGt.png)
[edit]
it looks like i_main.o never winds up in the final binary. If I make sure it gets linked(not part of doom.a) with doom.x I get 'undefined reference to ___main'. I've tried all kinds of combinations of stuff and I don't really know what to do at this point.
Quote from: neko68k on September 02, 2016, 07:15:12 AM
[edit]
it looks like i_main.o never winds up in the final binary. If I make sure it gets linked(not part of doom.a) with doom.x I get 'undefined reference to ___main'. I've tried all kinds of combinations of stuff and I don't really know what to do at this point.
Is this building with GCC 2?
is it the 2.4 thing or the 2.9?
I'm wondering if 1.30/1.42 works with GDB?
Also where did you get your GDB from? And what libraries are you linking against? I tried that lib32 thing, but it bombs out at various places, I had best luck with the SHAPR/Hudson includes/libs although there are certainly some corruption in the headders.. possibly the libs too. I should copy them myself out of the disk images to see if the images are actually corrupt. Otherwise I'll have to see if I can yahoo a copy of SHARP/Hudson C compiler.... for something less than $100 USD.
Yeah gcc2. It reports 2.6.3. It might not be the most recent. I remember is being a bit of a mess to put together in the first place. I can't remember where I got my libs from anymore. I'm fairly certain I've linked against them before. I did try it with the XC libs and had the same result. 1.30/1.42 isn't working for me right now. I haven't really investigated the issue. What versions of HAR and HLK are you using? I'd like to try using the same and see if it matters.
I think GDB will probably work with the 1.30/1.42. There are two different versions here (http://nfggames.com/X68000/Mirrors/x68pub/x68tools/UNIX/GDB/). 43 works well but it doesn't tell you what method the crash happened in. 060 tells you what method crashed but it has some issues with crashing itself. Kind of a mixed bag :/
Fixed my 030 problem. You cant use the XM6i memory option and boot human68k. Only for NetBSD.
Anyway. Your build goes a lot further in 030 mode. It hangs the machine completely after the ST_Init: line. The CPU actually stops.
[edit]
Fixed my gcc toolchain too. Had to do some finagling with the makefile and your batch files but I can build a working executable now.
(https://i.imgur.com/xQzYT7Tm.png) (https://i.imgur.com/xQzYT7T.png)
[editedit]
Oh yeah, I almost forgot. I don't have any problems using whatever malloc I have hooked up. I can't remember if its malloc() or _dos_malloc()/MALLOC() but with my setup it doesn't complain about it.
I'm using HAS 3.09 it says..
X68k High-speed Assembler v3.09 Copyright 1990-94 by Y.Nakamura
The linker I'm using is actually the hlk301
X68k SILK Hi-Speed Linker v3.01 Copyright 1989-94 SALT
03/11/1987 12:00 PM 4,352 AR.X
28/07/1994 11:24 PM 52,614 has.x
24/07/1994 10:18 PM 28,486 hlk301.x
24/07/1994 10:18 PM 28,486 LK.X
I noticed that both GDBs actually runs much better in 68000 mode.. they do take FOREVER to load symbols, even running with no waiting. I'd hate to do this on real hardware!
GDB for X680x0 (Human68k) version 0.90
based on GDB 4.4, Copyright 1991 Free Software Foundation, Inc...
(gdb) r
Starting program: C:/crusg/doom.x
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.
Exceptional Abort by address error
By Memory Access of 0x13ae77
at 0x13cc04 <R_InitSpriteDefs+194>: move.l (a0),-16(fp)
system status = I/N=I R/W=R FC=1
0x13cc06 in R_InitSpriteDefs
()
(gdb) quit
The program is running. Quit anyway? (y or n)
So now I have a location that makes the 68000 unhappy, meanwhile switching to 030 mode, and it runs fine. :\
I started taking some assembly files from libc32, and I think I'm actually able to enter supervisor mode now, as I did get the text mode to jump. I'm still 1000000% uncertain how to do anything graphic wise on the x68000.
I'm going to update a binary package of my cross build tools for Windows. run68k isn't perfect but it is doing a great job of at least running HAS/HLK on Windows.
Here is the binary package of what I'm using to cross compile.
https://sourceforge.net/projects/gcc-1-30-x68000/files/x68000-gcc130.7z/download
Awww shit
https://youtu.be/WHrFUizISPs (https://youtu.be/WHrFUizISPs)
Quote from: neko68k on September 02, 2016, 07:02:30 PM
Awww shit
https://youtu.be/WHrFUizISPs (https://youtu.be/WHrFUizISPs)
WOW... ok now you gotta give me a diff or something... !!!!!!!!!!!!!!!!!!
Holy balls, you actually have something being drawn on screen? That is phenomenal, congrats.
Fixing up the graphics should be easy enough.
Quote from: kamiboy on September 03, 2016, 12:33:53 AM
Holy balls, you actually have something being drawn on screen? That is phenomenal, congrats.
Fixing up the graphics should be easy enough.
I sure hope so! I'm going crazy here to see what the deal was/is....
I'm not really sure if you want to merge this with your repo. I am using different libs, using the batch files a little differently, different linker/archiver/assembler versions than you... It works a treat on the emulation with my HDS. I'm happy to share that image if you'd like a copy. It will probably need some small path changes in
autoexec.bat and you'll need to enable some emulation options(I think just Nereid 16MB RAM).
Repo (https://sourceforge.net/u/neko68k/x68000-doom-n/ci/master/tree/)
As far as work to be done is concerned:
- The palette is wrong, I haven't checked its format yet but I have some macros handy that'll convert various formats to the x68000 5551 format.
- The actual in-game display is wrong. It looks like it's writing to a different sized buffer that doesn't like being copied directly to screens[0]. For example, copying a 320x200 buffer to 512x512. There are a couple of #defines in doomdef.h for this but they dont seem to have an effect on the actual raycasting side of things. Menus and the HUD and stuff should work though
- The keyboard isn't hooked up at all. This should be pretty easy.
- MIDI is probably possible. I thought a long time ago about this... It is possible to convert the Doom music to regular MIDI files and there are drivers that'll just play those with a load to ram and calling a user trap.
- Sound will probably be a mess. It'll be necessary to mix effects(if theres even enough headroom for more than one sample) then convert them to IMA ADPCM and DMA the result to the MSM.
Fixes:
- Palette is sort of working. It's grayscale and I don't know why. It's probably something simple.
- In-game display has been fixed.
Problems:
- Transparent color... Probably easy to work around.
- Everything else.
(https://i.imgur.com/ZxjzmZdm.png) (https://i.imgur.com/ZxjzmZd.png)
What sort of frame rate are you getting? More than 1fps?
I'd love a HD image or even a zip.. Sourceforge let's you host files..
-edit
I found patch level 30 of gcc 2.6 something
http://www.kyagroup.com/soft/gcc/
There is some source/patch fragments to a 2.95 .... does x68000/HumanDOS have anything like long filename support? I'm really a total n00b at this kind of thing.
It's great looking at all the source changes you have in there, I am missing like... everyhthing.
I also found some more library stuff..
http://shq.dyndns.org/x68pub/x68tools/UNIX/GCC/c_pack.zip
along with patches to the gcc 1.30 thing!
So much more work to do........
:)
Quote from: kamiboy on September 03, 2016, 10:51:43 AM
What sort of frame rate are you getting? More than 1fps?
It's wAy way way way ahead of the game to even go down that road, but the Atari Jaguar DooM has a bunch of assembly optimizations... and it's 68000 based as well... but first step is to basically get it kind of running before looking at the i386 optimizations and borrowing the equivalents from the Jaguar. I know it's going to be fun going from GAS syntax to HAS.....
neko68k if you can upload the libs & includes you use at least... it'll help me a bunch.... for some reason when I try the lib32 stuff I found, it doesn't malloc memory... sigh back to square one for me. :'(
Human68k does support longer file names than the traditional 8.3. I cannot remember how long though. If I remember correctly there is a hard limit a few characters longer than 8, but not too many.
Quote from: kamiboy on September 03, 2016, 05:17:06 PM
Human68k does support longer file names than the traditional 8.3. I cannot remember how long though. If I remember correctly there is a hard limit a few characters longer than 8, but not too many.
Oh nice.
Well.. I tried and failed miserably to get GCC 2.95 running.. the later builds just don't work and crash. The older ones can't seem to find my include path, or lib path.. or temp path on top of that. Ill have to wait for neko to upload a disk image, or even a zip of his GCC setup with setup scipts so I can make heads or tails of it.... There is a source patch to the first release of GCC 2.95 that does patch into the source cleanly so I have some hope of being able to build a cross compiler, in the style of how I did GCC 1.30 to at least get GCC native, and use the assembler/llinker via run68....
So close... so far away.
So close that I can taste the shores of hell on my tongue. It taste like Cacodemon.
From Wiki:
Human68K does not support the VFAT long filenames standard of modern Windows systems, but it supports 18.3 character filenames instead of the 8.3 character filenames allowed in the FAT filesystem. Human68K is case sensitive and allows lower case and Shift JIS encoded Kanji characters in filenames, both of which cause serious problems when a DOS system tries to read such a directory. If a X68000 user restricts himself to use only filenames according to the 8.3 characters scheme of DOS, using only Latin upper case characters, then a disk written on the X68000 is fully compatible with other Japanese standard platforms like e.g. the NEC PC-9800, the Fujitsu FMR and FM Towns computers. The Japanese standard disk format used by the X68000 is: 77 tracks, 2 heads, 8 sectors, 1024 bytes per sector, 360 rpm (1232 KiB).
Quote from: kamiboy on September 03, 2016, 09:47:24 PM
So close that I can taste the shores of hell on my tongue. It taste like Cacodemon.
From Wiki:
Human68K does not support the VFAT long filenames standard of modern Windows systems, but it supports 18.3 character filenames instead of the 8.3 character filenames allowed in the FAT filesystem. Human68K is case sensitive and allows lower case and Shift JIS encoded Kanji characters in filenames, both of which cause serious problems when a DOS system tries to read such a directory. If a X68000 user restricts himself to use only filenames according to the 8.3 characters scheme of DOS, using only Latin upper case characters, then a disk written on the X68000 is fully compatible with other Japanese standard platforms like e.g. the NEC PC-9800, the Fujitsu FMR and FM Towns computers. The Japanese standard disk format used by the X68000 is: 77 tracks, 2 heads, 8 sectors, 1024 bytes per sector, 360 rpm (1232 KiB).
Oh crap. CaSe SeNSiTiVe???? Ugh. that may explain some weirdness I've seen, but it still doesn't help my memory issues................ 18.3 well that's a nice change!
Ok, so...
Yeah it does longish filenames. There is a program that allows more, TwentyOne (http://nfggames.com/X68000/Mirrors/x68pub/x68tools/HUMAN/TwentyOne/). It allows, unsurprisingly, 21 characters. It also allows things like 'dot' files, i.e '.dashrc'. That wiki article is a little off. It isn't case sensitive by default though TwentyOne is able to enable that feature.
I do know about all the stuff on the shq mirror. It is mirrored locally. The link above takes you to that mirror. A lot of my toolchain stuff came out of there.
Speaking of my stuff, here is my HDS (https://www.dropbox.com/s/yjisqolhc2ep78y/X68000.zip?dl=0). You'll need to boot this from SCSI0. The autoexec.bat will need to be slightly modified. All lines that refer to h:\temp may be need to be different depending on how many other drives you have set up. You can see what drive it was assigned by the driver by paying attention during boot. Theres probably an option to specify one but I never bothered.
Also in the emulator you will need to enable Nereid with 16MB of ram. The temp directory goes in a RAMdisk in Nereid RAM.
This project is in a:\proj\x68000-doom. That source is old though, I build on a host disk with WINDRV. It's much faster. There is a binary that works in a:\proj\x68000-doom\x68k There's a whole pile of other stuff on that disk.
As for performance, right now it _might_ be barely playable at 100MHz. I'm hooking up keyboard today so I'll let you know.
(https://i.imgur.com/xPWLP6mm.png) (https://i.imgur.com/xPWLP6m.png)
It moves! Very slow. This is 100MHz. It runs pretty well with VM turbo mode enabled.
https://www.youtube.com/watch?v=GpD0ucnUIkI (https://www.youtube.com/watch?v=GpD0ucnUIkI)
Very interesting we are both on GCC 1.30/1.42 ...
gcc version 1.30 Tool#2(X680x0) patchlevel 5
gcc_cpp -+-s:131072 -v -undef -D__GNUC__ -Dmc68000 -Dhuman68k -DHUMAN68K -DMARIKO_CC -Dmariko_cc -D__mc68000__ -D__human68k__ -D__HUMAN68K__ -D__MARIKO_CC__ -D__mariko_cc__ hi.c e:\temp\hi.cpp
gcc_cc1 -+-s:131072 e:\temp\hi.cpp -quiet -dumpbase hi.c -fhuman -version -o e:\temp\hi.s
has -e -w -u -i a:\USR\INCLUDE e:\temp\hi.s -o hi.o
a:\usr\bin\hlk.r -v hi.o a:\USR\LIB\libc.a a:\USR\LIB\libgnu.a
And I think the key bits are here:
SET include=a:\USR\INCLUDE
SET GCC_AS=a:\usr\bin\has060.x
SET GCC_LINK=a:\usr\bin\hlk.r
SET lib=a:\USR\LIB
SET HAS=-m 68030 -u -w -i a:\usr\include
SET SILK=-x -l
SET GCC_OPTION=LFIOAMP
I found patch set 4 & 5, Ill have to see if I can apply them, and integrate these build settings into my stuff. I have a makefile that can build and link without any manual steps too.. I have to run today, but Ill get something done. It was incredible to fire doom.x though..!
mine freaks out doom.wad vs DOOM.WAD ... sigh. But yeah I could rebuild your project files with my makefile thing and got a working EXE so that works at least.
Super awesome on the video and keyboard stuff! We can port other far more impractical stuff!
Was there ever anything like wattcp for x68000?
TCP/IP is basically BSD sockets. It should be dead easy to get it working. https://argrath.ub32.org/x680x0/internet.html (https://argrath.ub32.org/x680x0/internet.html)
Huzzah, it lives! But at what cost? Single digit frame rate at 100mhz is quite dire. Maybe a god level coder could optimize it to be playable on a high end 68030, but it will always be nothing more than a novelty.
Hopefully the work you did on the build toolchain can benifit future game development on the X68000 in the future.
Quote from: kamiboy on September 04, 2016, 08:28:12 PM
Huzzah, it lives! But at what cost? Single digit frame rate at 100mhz is quite dire. Maybe a god level coder could optimize it to be playable on a high end 68030, but it will always be nothing more than a novelty.
Hopefully the work you did on the build toolchain can benifit future game development on the X68000 in the future.
Yes hopefully... I need to purge the disk image as mine just hopelessly gives me corrupt results, instead of a native binary that "works" .... It's very interesting to see its actually gcc 1.42 hiding as 1.30 but compiled by 2.6 ....
Once I get something more reproducible it'll open a little more options, but gcc 1.42 is crazy old... the source patches for 2.95 don't give a directory that can actually compile some key stuff is left out. I'm no gcc expert by any stretch, but I think the c preprocessor from 2.x can work on 1.x so maybe we won't have to lean on uncrustify for converting c++ comments to k&r style.
Actually I was amazed to see the null version run on emulation, but with neko68k filling in some of the much needed x68000 bits it makes the platform much more accessible!
I don't know much about build tools, or GCC in general. But what advantages would your build environment provide over the one by Lydux which is based on a newer version of GCC?
I assume you cannot compile doom using Lydux's toolchain, but why? I do remember him talking about his standard C library implementations being buggy, and incomplete, so that might be it?
Quote from: kamiboy on September 04, 2016, 10:17:48 PM
I don't know much about build tools, or GCC in general. But what advantages would your build environment provide over the one by Lydux which is based on a newer version of GCC?
I assume you cannot compile doom using Lydux's toolchain, but why? I do remember him talking about his standard C library implementations being buggy, and incomplete, so that might be it?
Well the Lydux libraries leave a LOT to be desired... mostly that they don't work. I tried to fix some time functions, and it ended up just becoming a mess. I had tried to do a 'null' doom to see what it would do, and even putting a printf 'hi' in the start of main didn't work. There is other fundamental issues going on in there. Also the Lydux tool can't use the x68000 object format so you can't just switch to a different libc, if the issue was even revolving around libc. Sure there was some native GCC versions to the x68000 but I never could make heads or tails of them.
So switching gears I went to find out how the native stuff worked, and here we are.
The Lydux tools died, and with no debugging at all it's impossible to say what on earth is going on. There could be a whole host of issues, and I'm not even sure where to begin. But with a native compiler and thanks to run68 being able to run the assembler and linker on Windows (they are coded in assembly, so porting to C would take effort...) is a big help. It's easier to deal with crashes, and memory corruption when you fire up the emulator to run a single process (a-la run68 to assemble or link only), where running the toolchain in an emulator like xm6 suffers the same problems as trying to write software on MS-DOS, which is an unstable environment + unstable testing + unstable tools means lots of issues. SO for me, being able to compile outside of the emulator is a MASSIVE boon.
(http://i.imgur.com/YR4HeCx.png) (http://i.imgur.com/YR4HeCx.png)
So yeah, the only issue I have is with m_fixed.c, which as my host CPU is little endian, but the 68000 is big endian. And I took the source dump for GCC as is, so it doesn't know it needs to swap bit field operations to work.. So you end up with this:
#- .dc.l $00000000,$40f00000
#+ .dc.l $40f00000,$00000000But otherwise, it's so much faster, and easier to edit with native tools, and not worry about having to reboot the VM constantly to compile and test, only to test so it's much nicer. ... Not to mention it's nice to compare what is going on with a native vs cross build, which is how I found the issue with m_fixed .....
I'm amazed to see the system stuff Neko68 has put in, I never expected to actually be able to see anything on the screen!
By the way, I tried to copy your doom.x from the other thread over to my Compact for testing on actual hardware. Alas I fiund out that the SCSI CD drive I bought cannot read CD-RW discs, so no dice. I have no other easy way of getting big files over to my machine since it uses an internal CF.
If you still want it tested I could try burning a CD-R. I really need a better way to transfer files...
Quote from: kamiboy on September 05, 2016, 06:59:43 AM
By the way, I tried to copy your doom.x from the other thread over to my Compact for testing on actual hardware. Alas I fiund out that the SCSI CD drive I bought cannot read CD-RW discs, so no dice. I have no other easy way of getting big files over to my machine since it uses an internal CF.
If you still want it tested I could try burning a CD-R. I really need a better way to transfer files...
There really isn't much to test. It runs like a dog. There are some minor visual issues. The keyboard doesn't work that great as it is. It's based on a very very old version of doom too which kinda stinks.
Ultimately it will require an 030 bare minimum in low detail mode. It'll never be playable on, say, an XVI. Even a Red Zone might not hack it.
I'm starting to work on porting over optimizations from adoom for the Amiga. It should make a huge difference. I'd also like to port all these changes forward to something like chocolate doom, but that's for later.
I totally missed that gcc2 was on your disk along with gcc .... the first thing I found is that in the bin directory there is a copy of g2as & g2lk that are too old, renaming (or deleting them) lets the ones in the \usr\bin fall next into the path and they seem better......
But yeah, no ___main to link to.
Quote from: kamiboy on September 05, 2016, 06:59:43 AM
By the way, I tried to copy your doom.x from the other thread over to my Compact for testing on actual hardware. Alas I fiund out that the SCSI CD drive I bought cannot read CD-RW discs, so no dice. I have no other easy way of getting big files over to my machine since it uses an internal CF.
If you still want it tested I could try burning a CD-R. I really need a better way to transfer files...
I wouldn't go through that much hassle, it really isn't worth it. I was just more so curious to see what it would do on real hardware as it crashes on xm6 in x68000 mode, but runs on x68030 mode. My idle curiosity isn't worth a CDR.
What did kids use back in the day? terminal programs, null modems? sneakernet?
I think something like this [ur=http://www.ebay.com/itm/TCP-IP-Converter-Module-Serial-RS232-to-Ethernet-Networking-Over-LAN-or-WAN-/262215910700l]http://www.ebay.com/itm/TCP-IP-Converter-Module-Serial-RS232-to-Ethernet-Networking-Over-LAN-or-WAN-/262215910700[/url] may be something to look into... if I read it right, it'll let you basically telnet from a serial program. You could enjoy all those dozens of Internet BBS's and transfer files that way if you have a terminal program with something like zmodem support.
For file transfer there are a couple of options other than disks. There is direct (http://www.gamesx.com/wiki/doku.php?id=x68000:file_transfer_between_windows_pcs_and_x68000_machines_using_null_modem_cable) serial null modem where you could use TeraTerm on a windows machine and muterm on the x68000 and just zmodem stuff to the x68000. Another option is serial null modem with a PPP (//http://) server on the other side. That'll get you TCP/IP and all that good stuff. My HDS is set up to support internet with Nereid ethernet emulation. Turn that on in the options and follow those instructions and you can get real internet access inside the emulator :D
Yeah my disk is a little crufty in places. It's old and I haven't done anything with the native compilers in years.
Back in the day the kids used floppies. My solution though was the SCSI CD drive I imported from Japan. maybe there is a brand that will read CD-RW disks, but it is a bit too pricy to experiment.
Perhaps I should invest in a SCSI MO drive. I have been fascinated with the technology ever since I found out that those MO disks from the Resident Evil series were not just some made-up piece of tech, but actually existed in Japan.
I've never seen one of those mo disks. I used to have a next cube, but the drive never worked. I always wanted the mo disks from the matrix, but I never did research what it's was....
I can't find anyone who will decap my x68000 I may just take an iron to it and hope for the best. I took it apart which was a mission in its how right. It's crazy how many places fix phones or old shitty xbox 360's but nobody will touched my x68000... :(
I always thought the disk from Matrix was just a mini-disc, but I supposed it could have been an MO. They are basically the same technology.
Those NeXT machines sure were sexy, the addition of something as exotic as an MO drive only made them sexier in my opinion.
As for your X68000, recapping them yourself is not that hard. You won't find anyone who can solder at the places you mentioned, you need to find an old school repair person, one who worked in 90's tech, they'll know what is what.
Quote from: kamiboy on September 06, 2016, 02:20:03 AM
I always thought the disk from Matrix was just a mini-disc, but I supposed it could have been an MO. They are basically the same technology.
Those NeXT machines sure were sexy, the addition of something as exotic as an MO drive only made them sexier in my opinion.
As for your X68000, recapping them yourself is not that hard. You won't find anyone who can solder at the places you mentioned, you need to find an old school repair person, one who worked in 90's tech, they'll know what is what.
You know, it should be crazy easy, there is so many people in Hong Kong that used to make stuff like this, but for whatever reason I can't find anyone. I can find people who want to work with new stuff like crazy, but old stuff? no way. If anything I'd imagine it should be so much easier to repair 1980's electronics, but as soon as I pull out this x68000 I get the immediate NO NONONONONONONO1!!!
Maybe they have a bad reputation?
I see an x68030 on yahoo auctions, but 700 USD seems a bit steep... But I guess that is the pinnacle short of one of the 3 68060 machines.
Bah, I steer clear of the 68030 machines and other such oddities. I don't want a machine that will have problems running some games. A Compact XVI and a twin tower stock 10mhz is the optimum setup for me. I already have the Compact, all I need is the tower and I am set. I don't really see the point of the extra performance. All the games that interest me run fine on a 10mhz machine, and if not I always have the 16mhz mode on the XVI which I can toggle on and off at will.
Are these the optical drives you have in mind?
http://www.vcfed.org/forum/entry.php?568-MD-Data
They look cool
Damn, that SONY drive is damn sexy. Alas that is not the one. That is a spinoff tech based on minidiscs that never really caught on. I am looking to get an MO drive, which was a somewhat successfull portable storage solution post floppies. You can find tons of them for sal on Yahoo.
Playable binary (https://www.dropbox.com/s/h2iv1x5oueg4619/doom.zip?dl=0)
shoot is bound to Z
and the arrows control the dude
space is use
run is not bound
This will only be playable in emulation for now. 030 with 8MB RAM is required. 100MHz and the smallest view is recommended. No-wait and turbo mode are both pretty great to play. There is a graphical glitch where some pixels are black. Probably something with the CRTC registers. I'll figure it out later. Anyway, enjoy. :D
Quote from: neko68k on September 06, 2016, 06:33:57 PM
Playable binary (https://www.dropbox.com/s/h2iv1x5oueg4619/doom.zip?dl=0)
shoot is bound to Z
and the arrows control the dude
space is use
run is not bound
This will only be playable in emulation for now. 030 with 8MB RAM is required. 100MHz and the smallest view is recommended. No-wait and turbo mode are both pretty great to play. There is a graphical glitch where some pixels are black. Probably something with the CRTC registers. I'll figure it out later. Anyway, enjoy. :D
Wow totally awesome! and you can exit without crashing out! Super cool job!!!!!!
It actually wasn't crashing. It fails to save and restore the text mode palette. I'm not using it anyway so I took it out.
I need to figure out to capture the keyboard inputs so they aren't piped to the shell. Seems like I used to know how to do that... Though I don't think I've ever used BITSNS before so I dunno.
Did you update the source repo?
I'd like to try to use the current io on quake.....
It's up now. It was a really dumb small change for the keyboard. The tic timer should be a lot more accurate now. This gives a little speed boost. A better boost was making every other line blank instead of doubling lines for the aspect ratio. That helps a good bit.
I'm trying to get it to draw directly to GVRAM because it's much much faster that way but it seems easier said than done. :/
It's broken in some fundamental way but....
Host_Init
Added packfile ./id1/pak0.pak (339 files)
Added packfile ./id1/pak1.pak (85 files)
PackFile: ./id1/pak1.pak : gfx/pop.lmp
Playing registered version.
PackFile: ./id1/pak0.pak : gfx.wad
Console initialized.
Exe: 07:24:58 Sep 8 2016
8.0 megabyte heap
PackFile: ./id1/pak0.pak : gfx/palette.lmp
PackFile: ./id1/pak0.pak : gfx/colormap.lmp
256k surface cache
========Quake Initialized=========
PackFile: ./id1/pak0.pak : quake.rc
execing quake.rc
PackFile: ./id1/pak0.pak : gfx/conback.lmp
PackFile: ./id1/pak0.pak : default.cfg
execing default.cfg
Unknown command "volume"
FindFile: ./id1/config.cfg
execing config.cfg
Unknown command "joystick"
Unknown command "_snd_mixahead"
Unknown command "bgmvolume"
Unknown command "volume"
Unknown command "vid_window_y"
Unknown command "vid_window_x"
Unknown command "block_switch"
Unknown command "vid_windowed_mode"
Unknown command "vid_fullscreen_mode"
Unknown command "_windowed_mouse"
Unknown command "vid_stretch_by_2"
Unknown command "vid_config_y"
Unknown command "vid_config_x"
Unknown command "_vid_default_mode_win"
Unknown command "_vid_default_mode"
Unknown command "_vid_wait_override"
Unknown command "vid_nopageflip"
FindFile: can't find autoexec.cfg
couldn't exec autoexec.cfg
3 demo(s) in loop
Playing demo from demo1.dem.
PackFile: ./id1/pak0.pak : demo1.dem
the Necropolis
PackFile: ./id1/pak0.pak : maps/e1m3.bsp
PackFile: ./id1/pak0.pak : progs/player.mdl
PackFile: ./id1/pak0.pak : progs/eyes.mdl
PackFile: ./id1/pak0.pak : progs/h_player.mdl
PackFile: ./id1/pak0.pak : progs/gib1.mdl
PackFile: ./id1/pak0.pak : progs/gib2.mdl
PackFile: ./id1/pak0.pak : progs/gib3.mdl
PackFile: ./id1/pak0.pak : progs/s_bubble.spr
PackFile: ./id1/pak0.pak : progs/s_explod.spr
PackFile: ./id1/pak0.pak : progs/v_axe.mdl
PackFile: ./id1/pak0.pak : progs/v_shot.mdl
PackFile: ./id1/pak0.pak : progs/v_nail.mdl
PackFile: ./id1/pak0.pak : progs/v_rock.mdl
PackFile: ./id1/pak0.pak : progs/v_shot2.mdl
PackFile: ./id1/pak0.pak : progs/v_nail2.mdl
PackFile: ./id1/pak0.pak : progs/v_rock2.mdl
PackFile: ./id1/pak0.pak : progs/bolt.mdl
PackFile: ./id1/pak0.pak : progs/bolt2.mdl
PackFile: ./id1/pak0.pak : progs/bolt3.mdl
PackFile: ./id1/pak0.pak : progs/lavaball.mdl
PackFile: ./id1/pak0.pak : progs/missile.mdl
PackFile: ./id1/pak0.pak : progs/grenade.mdl
PackFile: ./id1/pak0.pak : progs/spike.mdl
PackFile: ./id1/pak0.pak : progs/s_spike.mdl
PackFile: ./id1/pak0.pak : progs/backpack.mdl
PackFile: ./id1/pak0.pak : progs/zom_gib.mdl
PackFile: ./id1/pak0.pak : progs/v_light.mdl
PackFile: ./id1/pak0.pak : progs/flame2.mdl
PackFile: ./id1/pak0.pak : progs/flame.mdl
PackFile: ./id1/pak0.pak : progs/zombie.mdl
PackFile: ./id1/pak0.pak : progs/h_zombie.mdl
PackFile: ./id1/pak0.pak : progs/w_g_key.mdl
PackFile: ./id1/pak0.pak : progs/ogre.mdl
PackFile: ./id1/pak0.pak : progs/h_ogre.mdl
PackFile: ./id1/pak0.pak : progs/wizard.mdl
PackFile: ./id1/pak0.pak : progs/h_wizard.mdl
PackFile: ./id1/pak0.pak : progs/w_spike.mdl
PackFile: ./id1/pak0.pak : progs/demon.mdl
PackFile: ./id1/pak0.pak : progs/h_demon.mdl
PackFile: ./id1/pak0.pak : progs/g_nail.mdl
PackFile: ./id1/pak0.pak : maps/b_shell1.bsp
PackFile: ./id1/pak0.pak : maps/b_bh25.bsp
PackFile: ./id1/pak0.pak : maps/b_bh10.bsp
PackFile: ./id1/pak0.pak : progs/g_shot.mdl
PackFile: ./id1/pak0.pak : maps/b_shell0.bsp
PackFile: ./id1/pak0.pak : maps/b_rock0.bsp
PackFile: ./id1/pak0.pak : maps/b_nail1.bsp
PackFile: ./id1/pak0.pak : progs/armor.mdl
PackFile: ./id1/pak0.pak : maps/b_nail0.bsp
PackFile: ./id1/pak0.pak : maps/b_rock1.bsp
PackFile: ./id1/pak0.pak : progs/g_rock.mdl
PackFile: ./id1/pak0.pak : progs/invisibl.mdl
Sys_Error: Globals are missaligned
For some reason it barfs on a native compile with -m68881 ... -msoft-float seems OK, although I guess since none of this is real it really doesn't matter.
Yes! 68000 and 68882 support plz! ^_^;;;;;
@neozeed
I got all the colors to work. Some sick TVRAM hacks. You should have a look.
(https://i.imgur.com/kltyRY4m.png) (https://i.imgur.com/kltyRY4.png)
Quote from: neko68k on September 08, 2016, 04:54:06 PM
@neozeed
I got all the colors to work. Some sick TVRAM hacks. You should have a look.
(https://i.imgur.com/kltyRY4m.png) (https://i.imgur.com/kltyRY4.png)
Damn, that's pretty amazing! I never thought it'd make it past the null version, but you've taken it that last mile!
Totally awesome!
All kinds of other 68000 based systems had DooM, I wondered why the x68000 didn't have one. Even the 68000 based Jaguar had one. Still it's pretty great to see!
I dunno why it never happened in the old days. It seems like the scene was really drying up between 96 and 99. It may have just not been lucrative or maybe too unknown.
I've been wanting to do this for years. You made the breakthrough on building and running it. I figured it'd be pretty quick work to get an unoptimized version running. I was right. :)
DOOM was a big deal in the west, not Japan. if the X68000 had been sold in the west a version of DOOM would have been all but guaranteed.
I suppose the PC-98 got DOOM because the machine was so close to IBM PC's that porting it took almost no effort, and so even with very few sales it would still net a profit.
Quote from: kamiboy on September 09, 2016, 12:00:11 AM
DOOM was a big deal in the west, not Japan. if the X68000 had been sold in the west a version of DOOM would have been all but guaranteed.
I suppose the PC-98 got DOOM because the machine was so close to IBM PC's that porting it took almost no effort, and so even with very few sales it would still net a profit.
I suppose when you think about 1993, the year the x68030 came out, it was a new-ish machine for the timeframe of when DooM launched. But the cost of licensing & porting may have simply been too much. Sad to say but Intel cleaned Motorola's clock, and the 88000 & PowerPC just couldn't compete. On the PC side, with the launch of Windows 95, it was pretty much over for the PC-98 as well.
I have a PC-98, I haven't been messing with it as much as I should, but I did finally buy a floppy drive, and a pack of diskettes, and I got DooM to install! .. it crashes the second you press any key. Another platform I know next to nothing about hardware wise...
Quote from: neko68k on September 08, 2016, 11:56:42 PM
I dunno why it never happened in the old days. It seems like the scene was really drying up between 96 and 99. It may have just not been lucrative or maybe too unknown.
I've been wanting to do this for years. You made the breakthrough on building and running it. I figured it'd be pretty quick work to get an unoptimized version running. I was right. :)
Ever since I ported Quake 2 to MS-DOS, I've been wanting to do something off the wall... I'll have to write about it, although in the 80/20 rule, you really did 80% of the work, lol
Quake 2 for DOS huh? I didn't know that was you. Great work.
I just pushed an update to the key handling. Pretty much everything of value is mapped. Fn-keys, all the alphanumeric, some symbols(+, -, <, >), basically everything needed to play the game properly. Reduced the number of loops there too, so that's nice. I might add the other three XFn keys and the two OPT keys later... I'm sick of staring at tables of numbers for tonight.
Most important thing for DOOM control wise is joypad support. I hate the fact that it is not easily playable using a controller in DOS. I hate playing anything using a keyboard. If you want easy joypad support I an upload the code I wrote for my game project.
It will be hard to map all essential functions of the game to two buttons, but if interaction and strafing is mapped to button A, and shooting to button B while running is toggled on all the time by default that should suffice for the most part.
Quote from: neko68k on September 09, 2016, 12:50:18 PM
Quake 2 for DOS huh? I didn't know that was you. Great work.
I just pushed an update to the key handling. Pretty much everything of value is mapped. Fn-keys, all the alphanumeric, some symbols(+, -, <, >), basically everything needed to play the game properly. Reduced the number of loops there too, so that's nice. I might add the other three XFn keys and the two OPT keys later... I'm sick of staring at tables of numbers for tonight.
Cool, I'll get off my butt and merge later tonight or tomorrow.
First it was Quake 1 for MS-DOS & OS/2 were my babies... Then after some asking I did QuakeWorld, I never played it before as I hate online games, since I suck and never got involved. Oddly enough I had QuakeWorld running on the first shot, since it's basically Quake as far as the system support stuff is involved. Mara'akate has been after me for some time to do Quake II, but I just kept putting it off until all those servers in the Netherlands shuttered basically killing off QuakeWorld. If I can be bothered to find one of those Vodoo cards, maybe Quake 3 could be a possibility. I may want to see how a software GL may or may not handle it, now that we live in the era of 3Ghz processors maybe it's practical.
But just like all the others, I just seem to get the ball rolling, and others that know a shit tonne more about the platform fill in the gaps, which TBH is totally fine by me. I'm just happy to have kicked that rock off in motion.
I should verify it with Linux or SunOS in Qemu, but I built a stock GCC 1.42 i386-sysv -> m68k-3b1 cross compiler, and it messes up the endian order too. I guess points for consistency. At least with DooM, it's a single file that is trivial to churn out some assembly, although I guess since I have to run the assembler, and linker under emulation, I could just run the compiler as well, maybe save the pre-processor and driver as native executables. I need to play more with some 68881 stuff and some better test programs to know if this thing is actually doing anything worth a damn. The default target for the x68000 is a stock 68000 with no FPU. I don't get why there is the exception with the straight x68000 with more RAM. I may have to re-build a compiler that simply cannot generate any 68010 or higher instructions, and force the assembler as well, in case it's getting cute somewhere.
part of me wants to get musashi running as the 68000 emulation core in run68, the other half wants to spend more time, and break down Quake1/QuakeWorld with GCC 1.40 / EMX to get a known 'good' state and try again. I don't think MAME has x68030 emulation, to say tell it you have a 68040 running at 200Mhz or something crazy assuming the ROMS dont go mad.
Quote from: kamiboy on September 09, 2016, 08:57:57 PM
Most important thing for DOOM control wise is joypad support. I hate the fact that it is not easily playable using a controller in DOS. I hate playing anything using a keyboard. If you want easy joypad support I an upload the code I wrote for my game project.
It will be hard to map all essential functions of the game to two buttons, but if interaction and strafing is mapped to button A, and shooting to button B while running is toggled on all the time by default that should suffice for the most part.
I absolutely detest controllers and DooM, but for the sake of people who do like them, plus a nice 'skeleton' to show how to program them, I'm 100% all in on that!
I'm guessing you would have to slap the keyboard for weapon change, or give up strafing which means basically dying a lot in DooM. It's been forever since I played DooM on the 32x, or any other console, but I don't recall it being "fun" although I bought it simply for the novelty aspect.
There is a way to do use more than two buttons on the X68000. If you use a FM Towns pad certain games will recognise the start button, but I think it is just toggling both A and B buttons at the same time for start, so not sure. It works in Akumajo.
In any regard, yes, for only two buttons using the keyboard for weapon change is necessary. But you do that rarely enough that it is not a big issue. But some people either do not have a keyboard for their X68000 or do not have one hooked up all the time, so thinking of joypad support is important.
I'll upload my code when I get home.
Quote from: kamiboy on September 09, 2016, 09:34:03 PM
There is a way to do use more than two buttons on the X68000. If you use a FM Towns pad certain games will recognise the start button, but I think it is just toggling both A and B buttons at the same time for start, so not sure. It works in Akumajo.
In any regard, yes, for only two buttons using the keyboard for weapon change is necessary. But you do that rarely enough that it is not a big issue. But some people either do not have a keyboard for their X68000 or do not have one hooked up all the time, so thinking of joypad support is important.
I'll upload my code when I get home.
Maybe a second joy pad? Or a combination like hold a+b and up / down to cycle?
Now that we have stuff building I may take another stab with the sharp compiler, but if it's still giving errors on the combined sources.... Yuck.
Here is the pad code. Should be easy enough to figure out how it works from the code, but feel free to ask if any qustions should crop up.
Quote from: kamiboy on September 10, 2016, 01:03:14 AM
Here is the pad code. Should be easy enough to figure out how it works from the code, but feel free to ask if any qustions should crop up.
cool, it looks sane enough. I was also thinking with the genesis, there was A/B/C + start. Or if you had the 6 button controller, which really is 7 buttons..
http://www.digitpress.com/library/manuals/32x/doom.pdf
This is going to feel a little clunky no matter what I guess....
"Most important thing for DOOM control wise is joypad support"
*cry*
Well, in my eyes nothing is more clunky than playing on a keyboard. Can you tell that I am not a PC gamer yet? Pasocoms do not count, of course, because on there any game worth its salt has joypad support.
I just found out I have to be on the road this weekend. Sigh.
I merged the code, and did a build. It's all up on the sourceforge pages now. I went ahead and hit the publish button on my blog as well.. Neko68k did a fantastic job with the port!
I'll try to do something with the joy pad, I'll have to pick one up to make sure it's doing the right thing if even in emulation.
It's so cool not just watching, but playing.
I think the access libc call for detecting the wads is not working right, I'll have to get a bunch more wads and try it. Also the freedoom levels, except m1e1 won't play on vanilla do it just needs replacing.
Quake built with gcc 1.40 fails on NT in the apparent same place as the x68000.... Very strange. I can't get djgpp 1.3 to link it correctly.. But it would be interesting to verify. It's based on gcc 1.38.
Nice writeup. I'm taking a weekend break. I'll get back to it on Monday. Here's the general plan.
I need to write a key mapping program. It isn't quite mapped 1:1 for some of the additional keys on the X68k keyboard and it can make changing the keys in doomrc kind of unclear. I'd like to just fix it up in Doom and get rid of the translation table and the ASCII table. It isn't really necessary now that I know how it all works internally and this is never getting pushed upstream so who needs all that portability cruft.
I'm still interested in porting over Amiga optimizations. Someone on IRC suggested I check out Doom Attack. The source is much less unruly than ADoom. It'll take some work to get it all going but it will help a lot. Still 030 minimum but probably not some nonexistent 100MHz machine.
I'll also take a look at getting joystick going. Hooking that up should be easy, even for the MD controllers.The controls for 2 button will be less than ideal though. I guess while I'm in there I can do mouse also though that'll have to be tested on hardware. The mouse emulation is a little weird and mouse in Doom is a little weird too :)
I dunno about the WAD stuff. It runs the first 3 episodes of the Ultimate DooM WAD for me. Of course, ep 4 is missing because it isn't supported and I haven't check but I expect the Doom 2 IWAD won't work either. 1.10 is a very old version of Doom. I haven't tried any PWAD's yet.
It's really unfortunate that low detail mode is totally broken. That seems to net a huge performance increase. Maybe it'll get working with the Amiga stuff.
I need to do some digging/testing to find out why the first element of each row of the palette is either black or invisible. I don't think my image loader has this problem. They switch to one or the other with the intensity bit but it isn't really making sense why it's not drawing the color. While I was working on it, at one time some purple color ended up in color 0 and that actually got drawn on the screen. ~shrug~ That TVRAM hack is cool and it was a good learning experience but it's slow and I think it's unnecessary.
For the Sprite palette the first entry of each palette row not being a colour, but see through is normal. That is how that palette works. I am not sure which palette you are using, but it might function the same.
I'm using GVRAM. I need to check but I'm fairly certain that the image viewing stuff I wrote previously doesn't have this issue and I have seen for sure that it worked like I want it to, if minimally, when I was porting the palette stuff in Doom.
Fixed GVRAM colors. GVRAM0 and GVRAM1 must be enabled in vidcon register 2. Pushed the update to my repo.
*vidcon_r2 = 0x23;
Almost networking...
https://imgur.com/a/RhTI8
I have zero knowledge of programming the YM2151 ... is it general MIDI?
Anyways I found...
Qmus2mid.c
in https://www.doomworld.com/3ddownloads/ports/middoomv.zip
It's an early port that apparently can play the MUS files in the wads as MIDI. I haven'b built it or tried just yet. Just bored on the train. 8)
My understanding of sound hardware might leave a lot to be desired but even I can answer that. An FM module is NOT midi, they are completely different things. Midi plays back ROM samples, but an FM module is basically a programable sound generator. You configure the registers for a given channel to produce a certain kind of synth sound, then you somehow you tell the FM to generate the programmed sound on said channel.
If you want to use midi with DOOM you will need to send General Midi commands to an external midi module. The way that works on an X68000 is through the use of a midi interface card, such as the official CZ-6BM1. You would either have to figure out hot to program that baby yourself, or find out how to use a third party library such as Z-Music, which I imagine will make things a LOT easier.
I do not remember whether the original DOS version of DOOM had GM, GS or LA midi support or not. If it did then you can make that work on the X68000 and the music will sound 100% accurate to the DOS version of that soundtrack. If not then my guess is it will sound pretty terrible.
One day in the far future I will have to look at all this audio stuff as well. But sound hardware is a scary big black box for me right now, so I avoid it.
Ok, I just read a bit about the DOOM MUS files and it seems that they are basically just midi files. I assume they are GM, which means the best way to play them on an X68000 is as I described, through an external midi module through a interface card. Try to figure out how Z-music works for midi playback, or better yet put music on the back burner and focus on other things.
I was planning on converting mus 2 mid then using an existing music driver. I hadn't decided on which driver but I guess zmusic is as good as any. The MIDI card doesn't really look that tough to program on it's own though. You set up a timer and push midi commands to a register and it buffers some number of them and processes them based on the timer. There are some details in Outside X68000.
Networking almost works, btw. It kind of seems like the network stack on the X68 is a little too limited to pull it off. I still have some things to try but that plan might be dead in the water :(
I reverted a tonne of stuff back to English for GCC. No binaries yet, I need to hammer the rest, although I did change quite a bit, there is still so many more it seems.....
Just some fun, non-doom stuff I'm fooling around with.
https://www.youtube.com/watch?v=aU2d_cCGNkA (https://www.youtube.com/watch?v=aU2d_cCGNkA)
Doom running on hardware. https://twitter.com/pipixvi/status/785991914306674688
We are doomed.
Single digit FPS even at 40mhz. Damn, no wonder Intel CPU architecture took over the computing world. At 40mhz DOOM would run buttery smooth on even 386.
Doom at 40mhz on a 386 wasn't written entirely in C.
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.
Almost the entire game can be ported from well tuned Amiga source. I'm just not that interested.
Quote from: neko68k on October 13, 2016, 08:26:32 AM
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.
Quote from: kamiboy 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.
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.
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.
Quote from: kamiboy 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.
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.
Quote from: neozeed on October 14, 2016, 07:03:04 PM
Quote from: kamiboy 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.
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
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
Here ya go. https://sourceforge.net/projects/gcc-1-30-x68000/files/ (https://sourceforge.net/projects/gcc-1-30-x68000/files/)
Quote from: costa 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
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.
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.
(https://i.imgur.com/Nfmj8PYm.png) (https://i.imgur.com/Nfmj8PY.png)
Quote from: neko68k 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.
(https://i.imgur.com/Nfmj8PYm.png) (https://i.imgur.com/Nfmj8PY.png)
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!!!
I redid my developer HDD a while back. It's all cleaned up and reasonably well organized ;) You should grab a copy (https://www.dropbox.com/s/mg7v2259ntsyxsi/X68000%20-%20Dev%20-%205-29-2017.7z?dl=0).
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 (http://retropc.net/x68000/software/develop/lib/libcdon/) 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 (http://retropc.net/x68000/software/develop/c/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.
(https://i.imgur.com/FhwVrafm.png) (https://i.imgur.com/FhwVraf.png)GCC2
(https://i.imgur.com/OHUNa4Bm.png) (https://i.imgur.com/OHUNa4B.png)GCC1
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..