Cross-Human68k toolchain

[kamiboy]

To answer one of my of my questions. To access system memory you just need to switch your program to supervisor mose by using the super IOCS call.

To disable text mode you need to modify the layer video register manually and flip the bit rendering the text layer.

It ia funny that I had no problem getting backgrounds to work and yet no luck with sprites.

It ia prolly something stupid that I am missing. Any help would be appreciated though.

Edit:

Figured out the problem with the sprite. It was showing but it was out of the bounds of screen. I assumed a coordinate of (0,0) would put it n the upper left corner. Turns out only with a coordinate of (9,9) does a single pixel of a 8x8 sprite become visible.

I am not entirely sure how that works, but it is what it is. Must be some padding to each side, I'll experiment some more and will move my discussions and discoveries to its own thread.

[neko68k]

You should wait for VSYNC. You can also wait for HBLANK but you have extremely little time there. Also keep in mind that some things, pcm8 for example, use HBLANK extensively. The entire display area can be as large as 1024x1024.  Oh, sprites are arranged funny. 16x16 are 4 8x8 sections, IIRC:

|1|2| not |1|2|3|4|
|3|4|

I'm fuzzy on exact details right now. I think you can also use 8x8 sprites in 15khz modes. Pallete 0 is the text layer pallete and is shared with graphics pallete ram.

[kamiboy]

How do you wait for VSYNC though? I have not been able to figure that one out.

The display area can be pretty large depending on the video mode that you use, but after taking a look at Akumajo I decided I should stick with 256x256 since that is what it uses.

I am still fuzzy on how all the video mode stuff works though.

[lydux]

The CRTC vblank interrupt is wired to the MFP GPIP line 4.
There is 2 ways to perform this :
- using the cpu vectored interrupt scheme : user vector #0x46, so put your interrupt handler routine at address 0x000118. (see _iomap.txt)
- or the simpliest one and most used : by polling MFP GPDR register bit 4.

Something like this :

Code Select Expand


#include <stdint.h>

/* MFP address */
#define MFP_BASE  0xe88000

struct MFP
{
  uint16_t gpdr;
  uint16_t aer;
  uint16_t ddr;
  uint16_t iera;
  uint16_t ierb;
  uint16_t ipra;
  uint16_t iprb;
  uint16_t isra;
  uint16_t isrb;
  uint16_t imra;
  uint16_t imrb;
  uint16_t vr;
  uint16_t tacr;
  uint16_t tbcr;
  uint16_t tcdcr;
  uint16_t tadr;
  uint16_t tbdr;
  uint16_t tcdr;
  uint16_t tddr;
  uint16_t scr;
  uint16_t ucr;
  uint16_t rsr;
  uint16_t tsr;
  uint16_t udr;
};
#define mfp ((*(volatile struct MFP *)MFP_BASE))

static void inline wait_vblank (void)
{
  while (mfp.gpdr & 4);
}


Oh yes, seems there is something wrong with iocscall _SP_REGST.
My iocscalls C implementations are results of documentation parsing, and I haven't tested them all. As said, the newlib port totally lacks of important features, documentations and testing. I need volunteers to help me on this point.
So thanks for the report ! I'll try to correct this asap.

[kamiboy]

Thanks a bunch lydux. That function will surely come in handy when and if I get further along in this project.

It sure is handy to have access to guy with such insight into the inner workinga of this system. I wish I knew a guy like you in real life, I would learn a lot.

[AnimaInCorpore]

Hello kamiboy,

here is the complete X68000 Pacmania game source code with comments and renamed labels. You may find it interesting which sprite drawing strategy they have used.

You can also make modifications and assemble the source with the Cross-Human68k toolchain to use it on the X68000 with the following command:

Code Select Expand

human68k-gcc -nostartfiles pm2.s -o pm.o && human68k-objcopy -O xfile pm.o pm.X && cp pm.X pacmania/

Cheers
Sascha

[AnimaInCorpore]

Just a quick note about building the toolchain on Linux versions with the GCC 4.7 compiler. Using it leads to a compiling problem which can be fixed by applying this patch.

Cheers
Sascha

[lydux]

Thanks Anima !
Pushed this fix to my repository.

[kamiboy]

Hello kamiboy,

here is the complete X68000 Pacmania game source code with comments and renamed labels. You may find it interesting which sprite drawing strategy they have used.

You can also make modifications and assemble the source with the Cross-Human68k toolchain to use it on the X68000 with the following command:

Code Select Expand

human68k-gcc -nostartfiles pm2.s -o pm.o && human68k-objcopy -O xfile pm.o pm.X && cp pm.X pacmania/

Cheers
Sascha

Thanks Sascha, but assembly is all greek to me. If there are any games coded in C for the X68000 I would be interested in taking a gander at the code. C is infinitely more readable than assembly. Respect for all those old school programmers making games in that language, but I am glad I was never had to work under similar conditions.

By the by, am I the only one who finds the pallet restrictions of the X68000 to be draconian?

Each sprite can only reference the 16 colours in one of only 16 different sprite pallets available in 256 colour mode. The artists who worked on this hardware must have had a hell of a time juggling colours to get games that looked so effortlessly colourful in spite of such limitations.

In any case, I imagine that right there is likely to be the biggest obstacle against porting colourful games from other systems to the X68000.

The only pallet based system I've ever worked on was good old mode 13h in DOS and there you got a nice unrestricted access to 256 colour pallet entries. Then again DOS didn't have any hardware accelerated backgrounds or sprites so I guess it could afford to be less restrictive.

I wonder how other contemporary console systems fared in that regard?

Edit:
Anyone privy to the relation between video modes and sprite size being 8x8 or 16x16?

[AnimaInCorpore]

Thanks Anima !
Pushed this fix to my repository.

Great work, you're really fast. Thanks for the fix.

As a note for myself to get this toolset compiled here's the command list which worked for me on an Ubuntu 13.04 machine:

Create a temporary folder (e.g. Temp) and "cd" to it. Use the following commands to build the toolchain:

Code Select Expand

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install bison texinfo flex expect libgmp-dev libmpfr-dev libmpc-dev

git clone git://github.com/Lydux/binutils-2.22-human68k.git
git clone git://github.com/Lydux/gcc-4.6.2-human68k.git
git clone git://github.com/Lydux/newlib-1.19.0-human68k.git

mkdir binutils-build
mkdir gcc-build
mkdir newlib-build

cd binutils-build
../binutils-2.22-human68k/configure --prefix=/usr/local --target=human68k --disable-nls
make -j 16
sudo make install
cd ..

cd gcc-build
../gcc-4.6.2-human68k/configure --prefix=/usr/local --target=human68k --disable-nls --disable-libssp --with-newlib --without-headers --enable-languages=c
make -j 16
sudo make install
cd ..

cd newlib-build
../newlib-1.19.0-human68k/configure --prefix=/usr/local --target=human68k
make -j 16
sudo make install
cd ..

Cheers
Sascha

Edit: typos fixed.

[AnimaInCorpore]

Thanks Sascha, but assembly is all greek to me. If there are any games coded in C for the X68000 I would be interested in taking a gander at the code. C is infinitely more readable than assembly. Respect for all those old school programmers making games in that language, but I am glad I was never had to work under similar conditions.

Oh, sorry... nevermind.

By the by, am I the only one who finds the pallet restrictions of the X68000 to be draconian?

Each sprite can only reference the 16 colours in one of only 16 different sprite pallets available in 256 colour mode. The artists who worked on this hardware must have had a hell of a time juggling colours to get games that looked so effortlessly colourful in spite of such limitations.

In any case, I imagine that right there is likely to be the biggest obstacle against porting colourful games from other systems to the X68000.

Actually there are only 15 colors available for the sprites since the 16th color is transparent.

However, 15 colors are quite good for the sprite design since these colors can be chosen independently from the background palette. So in this case there are up to (when using text layers in fact even more than) 16 x 15 + 256 = 496 colors available. Also many games use bigger sprites than the 16x16 pixel hardware limitation so you can use different 15 color palettes for them.

Cheers
Sascha

[kamiboy]

The raw number of colours is not so much important as much as the limitation that each sprite segment only being able to reference one of 16 different loaded sprite pallets.

That makes creating assets a logistics nightmare more or less. The artist cannot just pick 240 unique colours and draw all assets based on them. Instead they will have to very carefully create a set of 16 colour pallets and draw each segment using only one of each pallet.

The limitation becomes even more draconian when the artist has to create many, many different sprites that has to combined use few enough unique pallets that they can appear onscreen at the same time without breaking though the 16 unique pallet entry requirement.

I suppose it is possible, but I wouldn't want to be stuck being that artist.

So you say that the last colour entry in each pallet is the transparent colour, eh? I was wondering about that actually, thanks. I thought maybe transparency had something to do with the intensity bit of each packed pallet colour entry.

I am still wondering what intensity does exactly. Flipping that bit seems to be doing nothing to the colour in question.

[AnimaInCorpore]

In fact, the first color of each sprite palette is transparent.

An advantage of having a specific palette for each sprite are flashing color effects. For example a sprite is displayed completely white when it has been hit but not been destroyed. This can be done by changing a single value for each sprite. I guess you know this because almost every shooter uses it. But when you have only one global palette you need to have a lot more sprites stored in memory to simulate this effect.

Cheers
Sascha

[kamiboy]

You are right, that is certainly one use. But sacrificing one whole pallet just for that effect is costly, specially when you are only offered 16 pallets in total. Personally I would go for a blinking effect myself and use that pallet entry so I could have more distinct sprites on screen at a time.

I think the true reason for the pallets working like that is some because it then would allow for some smart engineering that either reduced cost or gave better performance, likely to do with some sort of caching issue. Cryptic hardware requirements are always like that.

I suppose one could code some sort of pallet manager that swaps entries in and discards them in tandem with new sprite elements coming into view and going out of the active display area.

Like one could generate a CRC code or some sort of hash for each pallet entry being used by each sprite. Then start with an empty 16 entry array representing the different pallets currently loaded into the pallet memory.

Every time a new sprite is displayed one would then check to see whether the pallet it uses is already loaded or not. If it is then it just uses the existing entry, otherwise the pallet is loaded into a unoccupied slot.

The real challenge is what to do when there are no empty slots to load into. Be best to make the game so that such a scenario does not come to pass.

I am not so sure how taxing that would be on a machine with only 10 mhz to spare. I guess I'll be wiser about the true capabilities of the system once I get much further along.

The easiest and most efficient solution is just to let the artist figure out all that stuff so you only need to load 16 pallets once for each level, or even globally, and not worry about anything else.

[AnimaInCorpore]

Just a short note (again to myself) how to build the toolchain using Ubuntu 14.04:

Code Select Expand


cd Temp

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install bison texinfo flex expect libgmp-dev libmpfr-dev libmpc-dev gcc-4.6

wget http://ftp.gnu.org/gnu/texinfo/texinfo-4.13a.tar.gz
tar -zxvf texinfo-4.13a.tar.gz
cd texinfo-4.13
./configure
make
sudo make install
cd ..

git clone git://github.com/Lydux/binutils-2.22-human68k.git
git clone git://github.com/Lydux/gcc-4.6.2-human68k.git
git clone git://github.com/Lydux/newlib-1.19.0-human68k.git

mkdir binutils-build
mkdir gcc-build
mkdir newlib-build

cd binutils-build
../binutils-2.22-human68k/configure --prefix=/usr/local --target=human68k --disable-nls CC=gcc-4.6
make -j 16
sudo make install
cd ..

cd gcc-build
../gcc-4.6.2-human68k/configure --prefix=/usr/local --target=human68k --disable-nls --disable-libssp --with-newlib --without-headers --enable-languages=c CC=gcc-4.6
make -j 16
sudo make install
cd ..

cd newlib-build
../newlib-1.19.0-human68k/configure --prefix=/usr/local --target=human68k CC=gcc-4.6
make -j 16
sudo make install
cd ..

Actually the reason for the fix is that GCC 4.8 will crash and the newest texinfo is not able to build the documents.

Cheers
Sascha

[lydux]

Ok. Do you know if it's an Ubuntu specific or a generic GCC 4.8 issue ?

[AnimaInCorpore]

Ok. Do you know if it's an Ubuntu specific or a generic GCC 4.8 issue ?

I am not really sure but it seems to be a GCC 4.8 issue. It was a crash like the one reported here: http://sourceforge.net/p/mspgcc/bugs/362/

Cheers
Sascha

[lydux]

Looks like a target bootstrap issue. I'll try installing a GCC 4.8.1 for checking.
Thanks for the report !

[neozeed]

This looks pretty interesting!

I'm trying to run this on Windows 7 x64, but I'm having issues with objcopy....

The output from codeblocks:

Code Select Expand

-------------- Build: default in test (compiler: Human68k GCC)---------------

mingw32-gcc.exe -g  -c D:\x68000\shared\test\main.c -o .objs\main.o
mingw32-g++.exe  -o default\test .objs\main.o  -Wl,-q,-Map=default\test.map,--cref 
Running project post-build steps
human68k-objcopy -O xfile default\test default\test.X
Execution of 'human68k-objcopy -O xfile default\test default\test.X' in 'D:\x68000\shared\test' failed.

Running it from the commandline the output looks like this:

Code Select Expand

D:\x68000\dev\bin>human68k-gcc.exe -v ..\..\shared\main.c -o ..\..\shared\main
Using built-in specs.
COLLECT_GCC=human68k-gcc.exe
COLLECT_LTO_WRAPPER=d:/x68000/dev/bin/../libexec/gcc/human68k/4.6.2/lto-wrapper.
exe
Target: human68k
Configured with: ../../../gcc-human68k/configure --prefix=/ --target=human68k --
host=i686-pc-mingw32 --disable-nls --with-newlib --without-headers --disable-lib
ssp --with-mpc=/home/lmaillet/x68k/tc-w32/packages/mpc-0.8.2/ --enable-languages
=c
Thread model: single
gcc version 4.6.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-o' '..\..\shared\main' '-m68000'
d:/x68000/dev/bin/../libexec/gcc/human68k/4.6.2/cc1.exe -quiet -v -iprefix d:\x
68000\dev\bin\../lib/gcc/human68k/4.6.2/ ..\..\shared\main.c -quiet -dumpbase ma
in.c -m68000 -auxbase main -version -o C:\Users\Jsteve\AppData\Local\Temp\ccR9pw
ci.s
GNU C (GCC) version 4.6.2 (human68k)
        compiled by GNU C version 4.5.2, GMP version 5.0.4, MPFR version 3.1.0,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "d:\x68000\dev\bin\../lib/gcc/human68k/4.6.2/../.
./../../human68k/sys-include"
ignoring duplicate directory "d:/x68000/dev/lib/gcc/../../lib/gcc/human68k/4.6.2
/include"
ignoring duplicate directory "d:/x68000/dev/lib/gcc/../../lib/gcc/human68k/4.6.2
/include-fixed"
ignoring nonexistent directory "d:/x68000/dev/lib/gcc/../../lib/gcc/human68k/4.6
.2/../../../../human68k/sys-include"
ignoring duplicate directory "d:/x68000/dev/lib/gcc/../../lib/gcc/human68k/4.6.2
/../../../../human68k/include"
#include "..." search starts here:
#include <...> search starts here:
d:\x68000\dev\bin\../lib/gcc/human68k/4.6.2/include
d:\x68000\dev\bin\../lib/gcc/human68k/4.6.2/include-fixed
d:\x68000\dev\bin\../lib/gcc/human68k/4.6.2/../../../../human68k/include
End of search list.
GNU C (GCC) version 4.6.2 (human68k)
        compiled by GNU C version 4.5.2, GMP version 5.0.4, MPFR version 3.1.0,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e22b47d21250eae54ddfd9d73f7a6cce
COLLECT_GCC_OPTIONS='-v' '-o' '..\..\shared\main' '-m68000'
d:/x68000/dev/bin/../lib/gcc/human68k/4.6.2/../../../../human68k/bin/as.exe -m6
8000 -o C:\Users\Jsteve\AppData\Local\Temp\ccFQ2fUl.o C:\Users\Jsteve\AppData\Lo
cal\Temp\ccR9pwci.s
COMPILER_PATH=d:/x68000/dev/bin/../libexec/gcc/human68k/4.6.2/;d:/x68000/dev/bin
/../libexec/gcc/;d:/x68000/dev/bin/../lib/gcc/human68k/4.6.2/../../../../human68
k/bin/
LIBRARY_PATH=d:/x68000/dev/bin/../lib/gcc/human68k/4.6.2/;d:/x68000/dev/bin/../l
ib/gcc/;d:/x68000/dev/bin/../lib/gcc/human68k/4.6.2/../../../../human68k/lib/
COLLECT_GCC_OPTIONS='-v' '-o' '..\..\shared\main' '-m68000'
d:/x68000/dev/bin/../libexec/gcc/human68k/4.6.2/collect2.exe -q -o ..\..\shared
\main d:/x68000/dev/bin/../lib/gcc/human68k/4.6.2/../../../../human68k/lib/crt0.
o -Ld:/x68000/dev/bin/../lib/gcc/human68k/4.6.2 -Ld:/x68000/dev/bin/../lib/gcc -
Ld:/x68000/dev/bin/../lib/gcc/human68k/4.6.2/../../../../human68k/lib C:\Users\J
steve\AppData\Local\Temp\ccFQ2fUl.o -lgcc -lc -ldos -liocs -lgcc

D:\x68000\dev\bin>human68k-objcopy -v -O xfile ..\..\shared\main ..\..\shared\ma
in.X
copy from `..\..\shared\main' [elf32-m68k] to `..\..\shared\main.X' [xfile]

D:\x68000\dev\bin>


I should also add that GCC seems to pause while loading and I'm unsure what that is about.  objcopy doesn't give any obvious reason while it is failing, and I

[neozeed]

This doesn't work for codeblocks, but it works for the CLI... I added a -v to objcopy and it gives me different output!

Code Select Expand

D:\x68000\shared>\x68000\dev\bin\human68k-objcopy.exe -O xfile main main.x

D:\x68000\shared>\x68000\dev\bin\human68k-objcopy.exe -v -O xfile main main2.x
copy from `main' [elf32-m68k] to `main2.x' [xfile]

D:\x68000\shared>fc /b main.x main2.x
Comparing files main.x and MAIN2.X
00000002: 34 00
0000000E: D7 2E
0000000F: 35 D8
00000011: 34 00
00000012: 09 08
00000013: 40 7C
00000015: 34 00
00000016: BF 00
00000017: 30 F0

How is that for strange?



But I got the quick hello world working so that's fantastic!!!! 

[neozeed]

Totally pointless, I know.. but



I compiled something not so trivial, and it runs!

using the windows bulid of GCC gets me an exe that doesn't work at all.  I rebuilt the toolchain on OS X, and I'm able to get a working infocom interpreter.  I used the source from 1987 I found here:

http://www.planetemu.net/rom/tandy-radio-shack-trs-80-model-1/infocom-adventure-executor-source-files-1987-infotaskforce-c

[eidis]

 Hi Neozeed !

Congratulations on a work well done ! Could you please post the compiled executable ?

Keep the scene alive !
Eidis

[neozeed]

Hi Neozeed !

Congratulations on a work well done ! Could you please post the compiled executable ?

Sure, if you want it...

I finally managed to get it to build on Windows.  It turns out if you strip the executable before objcopying it, it's removing something important, giving you something that won't work.  I should also add fopen for writing files is broken, so I used open/write and that works for saving games. If you rebuild this 'infocom' with another compiler/OS combination you can load it's save games.  The next step is to get some kind of debugger going, although that kind of means finding a native human68k gcc (was there ever one?).

Also I found this great GPL'd x68000/HumanOS emulator run68.  It's like DOSBox, although it doesn't emulate anything related to the hardware/graphics/sound.  But it does run CLI stuff just fine.  And it makes for testing stuff a bunch more easier.

Code Select Expand

D:\proj\run\test>run68.exe infocom.X minizork.z3
MINI-ZORK I: The Great Underground Empire
Copyright (c) 1988 Infocom, Inc. All rights reserved.
ZORK is a registered trademark of Infocom, Inc.
Release 34 / Serial number 871124

West of House
You are standing in an open field west of a white house, with a boarded front
door. You could circle the house to the north or south.
There is a small mailbox here.

West of House                        Score: 0/0
>

So, obviously there is some file IO issues, and the bigger thing going from here is how to start programming the hardware.  It's all kind of beyond me right now but at least there is some older emulators with source to illuminate something that is going on.

Anyways, here is my development environment, which includes updated libs from the source tree, run68 source & executable along with the Infocom interrupter source + some old Infocom demos.   And here is a xdf disk image that'll boot up and let you try the demos.  I'm sorry you'll have to deal with my insane directory protection because some idiot said my Windows CE build of nethack was malware... 

I suppose I could get a version of hack running on the x68000 before I even think about something as complicated as Doom.

And I wonder if this cross toolset can generate 68881 code that'll at least run in an emulator.

edit:
I did some more testing, and the -msoft-float works great.  Doing a -m68030 -m68881 does generate code that 68000 only emulation chokes on, but the 68030/68881 enabled emulator can run.  Although it does expose some bugs in emulation.

[neko68k]

There is working gcc 2 for human68k. I also started porting chocolate doom about a year ago but it gives "exec error" no matter where I run the tool chain...

[neozeed]

There is working gcc 2 for human68k. I also started porting chocolate doom about a year ago but it gives "exec error" no matter where I run the tool chain...

is that the loader complaining?  how big is the exe? ... I wonder if a humanOS program can allocate 8MB of ram.

I was going through some docs, and it has primitive multitasking, and shared memory.  And a LOT of thigns that look and feel like MS-DOS.

[neozeed]

There is working gcc 2 for human68k. I also started porting chocolate doom about a year ago but it gives "exec error" no matter where I run the tool chain...

Well I got it to compile...

And I changed i_main to something like this:

Code Select Expand

int
main
( int argc,
  char** argv )
{
    myargc = argc;
    myargv = argv;

printf("hi!\n");


//    D_DoomMain ();

    return 0;
}

Compiled it all together, and got my exec.  Started up xm6g as an 030 with 12MB of ram, Human68k 3.02... run the executable and nothing.

Code Select Expand

12/17/2014  02:36 PM           522,776 dosdoom.X

My source is here, I only butchered it enough to compile, mostly by removing the WAD detection so it'll go for shareware, and hardcoding the wad file size.  I based this on DOSDoom, not that it matters as it wont even behave like a simple hello world executable.

So I guess 500kb exe's are out of the question.

[neozeed]

Sorry to keep bumping this, is there somewhere else I should be doing this?

Anyways in notepad ++ I can open up run68 and actually see the encoded Japanese text so I can at least run it through google translate.

And there it bombs with "未対応のリロケート情報があります" or "There is not supported relocated information".  Although I think it's running out of memory trying to allocate space for the executable?

objdumps of a few executables....

Code Select Expand


dosdoom.X
architecture: m68k, flags 0x00000013:
HAS_RELOC, EXEC_P, HAS_SYMS
start address 0x00000000

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0004ad00  00000000  00000000  00000040  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         0002592c  0004ad00  0004ad00  0004ad40  2**1
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  2 .bss          0004d0a0  0007062c  0007062c  00000000  2**1
                  ALLOC
SYMBOL TABLE:
00000018         .text _start_1
00000020         .text clear_bss
000b3a30         .data rcsid
000b3a61         .data rcsid
000b3a92         .data rcsid
000b3f61         .data rcsid
000e0c60         .bss  basetime.5044

doom

Code Select Expand


infocom.x
architecture: m68k, flags 0x00000013:
HAS_RELOC, EXEC_P, HAS_SYMS
start address 0x00000000

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000e0b4  00000000  00000000  00000040  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00001440  0000e0b4  0000e0b4  0000e0f4  2**1
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  2 .bss          000001f6  0000f4f4  0000f4f4  00000000  2**1
                  ALLOC
SYMBOL TABLE:
00000018         .text _start_1
00000020         .text clear_bss
0001cad4         .data jmp_op1.1348
0001cb14         .data jmp_lowop.1377
0001cb74         .data jmp_hiop.1378
0001ca9c         .data jmp_op0.1319
0000379e         .text L1
000037a8         .text L2

Infocom interpreter.

Code Select Expand


hello.x
architecture: m68k, flags 0x00000013:
HAS_RELOC, EXEC_P, HAS_SYMS
start address 0x00000000

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00002ecc  00000000  00000000  00000040  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000870  00002ecc  00002ecc  00002f0c  2**1
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  2 .bss          000000f0  0000373c  0000373c  00000000  2**1
                  ALLOC
SYMBOL TABLE:
00000018         .text _start_1
00000020         .text clear_bss
00006e78         .bss  initial_env
00005da0         .data impure_data
00006e7c         .bss  initialized.766
00002430         .text __fp_lock
0000243a         .text __fp_unlock
0000245e         .text std.isra.0
Simple hello world

I don't know, keep banging away I guess.  Or try the Sharp C compiler, aparently it's all PD now.

[lydux]

Hi Neozeed,

Strange... Your final executables seems to lack of relocations table which are mandatory with XFiles.

What are the command line used for compilation and linkage ?

[neozeed]

Thanks for taking a look, I hope this doesn't overflow things like crazy...

Hi Neozeed,

Strange... Your final executables seems to lack of relocations table which are mandatory with XFiles.

What are the command line used for compilation and linkage ?

I'm using the Windows build of your tools, and sometimes an OS X cross compile set.  I truncated the output just to show the top section.

Here is that ancient infocom interpreter:

Code Select Expand

human68k-gcc    -c -o support.o support.c
human68k-gcc    -c -o variable.o variable.c
human68k-gcc    -c -o term.o term.c
human68k-gcc -o infocom file.o funcs.o infocom.o init.o input.o interp.o io.o jump.o object.o options.o page.o print.o property.o support.o variable.o term.o
human68k-objcopy -v -O xfile infocom infocom.X
copy from `infocom' [elf32-m68k] to `infocom.X' [xfile]

Which is pretty vanilla.  Just simply compile, and then grab all the objects into a final file.  I noticed that if i didn't use the -v file on objcopy I don't get a working executable.

And that give me this...

D:\proj\run\run68-infocom-gcc-x68000dev.win32\infocom>human68k-objdump -x infocom.x



Building doom is just as straight forward.  First I got it running on MinGW with no input or graphics just load the WAD and initialize itself.

Code Select Expand


D:\proj\cdoom>make
human68k-gcc   -DNORMALUNIX -c doomdef.c -o dos/doomdef.o
human68k-gcc   -DNORMALUNIX -c doomstat.c -o dos/doomstat.o
human68k-gcc   -DNORMALUNIX -c dstrings.c -o dos/dstrings.o
human68k-gcc   -DNORMALUNIX -c i_system.c -o dos/i_system.o
human68k-gcc   -DNORMALUNIX -c i_sound.c -o dos/i_sound.o
human68k-gcc   -DNORMALUNIX -c i_video.c -o dos/i_video.o
human68k-gcc   -DNORMALUNIX -c i_net.c -o dos/i_net.o
human68k-gcc   -DNORMALUNIX -c tables.c -o dos/tables.o
human68k-gcc   -DNORMALUNIX -c f_finale.c -o dos/f_finale.o
human68k-gcc   -DNORMALUNIX -c f_wipe.c -o dos/f_wipe.o
human68k-gcc   -DNORMALUNIX -c d_main.c -o dos/d_main.o
human68k-gcc   -DNORMALUNIX -c d_net.c -o dos/d_net.o
human68k-gcc   -DNORMALUNIX -c d_items.c -o dos/d_items.o
human68k-gcc   -DNORMALUNIX -c g_game.c -o dos/g_game.o
human68k-gcc   -DNORMALUNIX -c m_menu.c -o dos/m_menu.o
human68k-gcc   -DNORMALUNIX -c m_misc.c -o dos/m_misc.o
human68k-gcc   -DNORMALUNIX -c m_argv.c -o dos/m_argv.o
human68k-gcc   -DNORMALUNIX -c m_bbox.c -o dos/m_bbox.o
human68k-gcc   -DNORMALUNIX -c m_fixed.c -o dos/m_fixed.o
human68k-gcc   -DNORMALUNIX -c m_swap.c -o dos/m_swap.o
human68k-gcc   -DNORMALUNIX -c m_cheat.c -o dos/m_cheat.o
human68k-gcc   -DNORMALUNIX -c m_random.c -o dos/m_random.o
human68k-gcc   -DNORMALUNIX -c am_map.c -o dos/am_map.o
human68k-gcc   -DNORMALUNIX -c p_ceilng.c -o dos/p_ceilng.o
human68k-gcc   -DNORMALUNIX -c p_doors.c -o dos/p_doors.o
human68k-gcc   -DNORMALUNIX -c p_enemy.c -o dos/p_enemy.o
human68k-gcc   -DNORMALUNIX -c p_floor.c -o dos/p_floor.o
human68k-gcc   -DNORMALUNIX -c p_inter.c -o dos/p_inter.o
human68k-gcc   -DNORMALUNIX -c p_lights.c -o dos/p_lights.o
human68k-gcc   -DNORMALUNIX -c p_map.c -o dos/p_map.o
human68k-gcc   -DNORMALUNIX -c p_maputl.c -o dos/p_maputl.o
human68k-gcc   -DNORMALUNIX -c p_plats.c -o dos/p_plats.o
human68k-gcc   -DNORMALUNIX -c p_pspr.c -o dos/p_pspr.o
human68k-gcc   -DNORMALUNIX -c p_setup.c -o dos/p_setup.o
human68k-gcc   -DNORMALUNIX -c p_sight.c -o dos/p_sight.o
human68k-gcc   -DNORMALUNIX -c p_spec.c -o dos/p_spec.o
human68k-gcc   -DNORMALUNIX -c p_switch.c -o dos/p_switch.o
human68k-gcc   -DNORMALUNIX -c p_mobj.c -o dos/p_mobj.o
human68k-gcc   -DNORMALUNIX -c p_telept.c -o dos/p_telept.o
human68k-gcc   -DNORMALUNIX -c p_tick.c -o dos/p_tick.o
human68k-gcc   -DNORMALUNIX -c p_saveg.c -o dos/p_saveg.o
human68k-gcc   -DNORMALUNIX -c p_user.c -o dos/p_user.o
human68k-gcc   -DNORMALUNIX -c r_bsp.c -o dos/r_bsp.o
human68k-gcc   -DNORMALUNIX -c r_data.c -o dos/r_data.o
r_data.c: In function 'R_GenerateLookup':
r_data.c:323:26: warning: incompatible implicit declaration of built-in function
'alloca' [enabled by default]
r_data.c: In function 'R_InitTextures':
r_data.c:452:19: warning: incompatible implicit declaration of built-in function
'alloca' [enabled by default]
r_data.c: In function 'R_PrecacheLevel':
r_data.c:763:19: warning: incompatible implicit declaration of built-in function
'alloca' [enabled by default]
human68k-gcc   -DNORMALUNIX -c r_draw.c -o dos/r_draw.o
human68k-gcc   -DNORMALUNIX -c r_main.c -o dos/r_main.o
human68k-gcc   -DNORMALUNIX -c r_plane.c -o dos/r_plane.o
human68k-gcc   -DNORMALUNIX -c r_segs.c -o dos/r_segs.o
human68k-gcc   -DNORMALUNIX -c r_sky.c -o dos/r_sky.o
human68k-gcc   -DNORMALUNIX -c r_things.c -o dos/r_things.o
human68k-gcc   -DNORMALUNIX -c w_wad.c -o dos/w_wad.o
w_wad.c: In function 'W_AddFile':
w_wad.c:205:13: warning: incompatible implicit declaration of built-in function
'alloca' [enabled by default]
w_wad.c: In function 'W_Reload':
w_wad.c:262:16: warning: incompatible implicit declaration of built-in function
'alloca' [enabled by default]
human68k-gcc   -DNORMALUNIX -c wi_stuff.c -o dos/wi_stuff.o
human68k-gcc   -DNORMALUNIX -c v_video.c -o dos/v_video.o
human68k-gcc   -DNORMALUNIX -c st_lib.c -o dos/st_lib.o
human68k-gcc   -DNORMALUNIX -c st_stuff.c -o dos/st_stuff.o
human68k-gcc   -DNORMALUNIX -c hu_stuff.c -o dos/hu_stuff.o
human68k-gcc   -DNORMALUNIX -c hu_lib.c -o dos/hu_lib.o
human68k-gcc   -DNORMALUNIX -c s_sound.c -o dos/s_sound.o
human68k-gcc   -DNORMALUNIX -c z_zone.c -o dos/z_zone.o
human68k-gcc   -DNORMALUNIX -c info.c -o dos/info.o
human68k-gcc   -DNORMALUNIX -c sounds.c -o dos/sounds.o
human68k-gcc   -DNORMALUNIX -c i_main.c -o dos/i_main.o
human68k-gcc   -DNORMALUNIX  dos/doomdef.o dos/doomstat.o dos/dstrings.o dos/i_system.o dos/i_sound.o dos/i_video.o dos/i_net.o dos/tables.o dos/f_finale.o dos/
f_wipe.o dos/d_main.o dos/d_net.o dos/d_items.o dos/g_game.o dos/m_menu.o dos/m_misc.o dos/m_argv.o dos/m_bbox.o dos/m_fixed.o dos/m_swap.o dos/m_cheat.o dos/m_random.o dos/am_map.o dos/p_ceilng.o dos/p_doors.o dos/p_enemy.o dos/p_floor.o dos/p_inter.o dos/p_lights.o dos/p_map.o dos/p_maputl.o dos/p_plats.o dos/p_pspr.o dos/p_setup.o dos/p_sight.o dos/p_spec.o dos/p_switch.o dos/p_mobj.o dos/p_telept.o dos/p_tick.o dos/p_saveg.o dos/p_user.o dos/r_bsp.o dos/r_data.o dos/r_draw.o dos/r_main.o dos/r_plane.o dos/r_segs.o dos/r_sky.o dos/r_things.o dos/w_wad.o dos/wi_stuff.o dos/v_video.o dos/st_lib.o dos/st_stuff.o dos/hu_stuff.o dos/hu_lib.o dos/s_sound.o dos/z_zone.o dos/info.o dos/sounds.o dos/i_main.o \
-o dos/dosdoom
human68k-objcopy -v -O xfile dos/dosdoom dosdoom.X
copy from `dos/dosdoom' [elf32-m68k] to `dosdoom.X' [xfile]


I had truncated the output from objdump because it is so large.  I've attached it to this message for both the infocom interpreter and doom.

Thanks again!!!!

[neozeed]

Ok, so it must be something about DOOM... I thought I'd try something else, and build NetHack 1.3d (the somewhat modernized source here).  So I configured for a MS-DOS build, gutted out the msdos OS support file, and managed to get a runnable executable.  The console input is all screwed up, I guess I should dig into the libc and flesh out things like getch, and the time/date functions... But yeah it runs.

Code Select Expand

nethack.x:     file format xfile
nethack.x
architecture: m68k, flags 0x00000013:
HAS_RELOC, EXEC_P, HAS_SYMS
start address 0x00000000

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00052394  00000000  00000000  00000040  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         0001122c  00052394  00052394  000523d4  2**1
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  2 .bss          0000343a  000635c0  000635c0  00000000  2**1
                  ALLOC

The output from objdump is larger than the executable.

Code Select Expand

462,822 nethack.x

And it runs under run68 and XM6 TypeG!




Ive got it reading the system time/date so it has some randomness to it.  For the little Ive tested.  Exiting out of the game doesn't kill the temp files just yet.

My source dump is here.  And it's mostly playable (it runs better on run68, better ansi support with ansicon).  Since getchar bombs I just call  _dos_getc... which works pretty much the same (isn't it just a macro on other platforms?).  But more so that an exe bigger than 115kb can run.  Although DOOM is larger I may have to inflate the exe


For my own reference..

Time & Date:

Code Select Expand

       
      time_t rawtime;
      rawtime=_dos_gettim2();
      printf("Hour %d Minute %d Seconds %d\t\r",((rawtime >> 16) & 0x1F),((rawtime >> 8) & 0x3F),(rawtime & 0x3F));
      rawtime=_dos_getdate();
      printf("day of week %d year %d, month %d day %d\n",(rawtime>>16&0x7ff),(((rawtime >> 9) & 0x7F) + 1980),((rawtime >> 5) & 0xF),(rawtime & 0x1f));


Code Select Expand

_dos_c_cls_al ();
_dos_c_color(i);
_dos_c_locate(i,i);

Colours are 0 black, 1 cyan?, 2 yellow, 3 white. BOLD, inverse and inverse BOLD... Is there a way to get more colours?

Also I need to figure out the cursor control better.  But I did find _dos_getch so I can read the keyboard.  Dying/exiting again relies on fprintf, so I'm once more again substituting for _dos_open/_dos_write.  I need to look into the newlib as to why writing files doesn't work, its just annoying to me.  So right now it's using the ANSI screen driver to move stuff around, and I know already its incomplete compared to MS-DOS ansi.sys / nansi.sys or even ansicon.

Code Select Expand


int kbhit()
{
int rc;
rc=_dos_k_keysns();
if(rc>0)
rc=1;
return (rc);
}

x68000 "text" mode is 95x30

//_dos_c_window(80,24); //FUNC(23):CONCTRL    mode=15
//_dos_c_cls_al(); //[2J clear screen and home cursor
//_dos_c_cls_ed(); //[0J Clear screen from cursor down
//_dos_c_cls_st(); //[1J Clear screen from cursor up
//_dos_c_locate(0,0); //FUNC(23):CONCTRL    mode=3
//_dos_c_print("hi\n"); //FUNC(23):CONCTRL    mode=1


always always fflush(stdout) after doing anything to the screen when you move the cursor or change colors.

[costa]

Hi.

What could be possibly wrong with these?
I compiled the sample hello world without errors (apparently, as shown below), but the SAMPLE.X will not run:
"Can not run the file".

The binary is not being generated correctly for any reason.
Any tip to setup this toolchain correctly?

Thanks



-------------- Build: default in SAMPLE1 (compiler: Human68K Compiler)---------------

human68k-gcc.exe -g  -c C:\Toolchain\Sources\SAMPLE1\main.c -o .objs\main.o
human68k-gcc.exe  -o default\SAMPLE1 .objs\main.o  -Wl,-q,-Map=default\SAMPLE1.map,--cref 
Output file is default\SAMPLE1 with size 223.70 KB
Running project post-build steps
human68k-objcopy -O xfile default\SAMPLE1 default\SAMPLE1.X
Process terminated with status 0 (0 minute(s), 3 second(s))
0 error(s), 0 warning(s) (0 minute(s), 3 second(s))

[neozeed]

human68k-objcopy -O xfile default\SAMPLE1 default\SAMPLE1.X

You are probably having the same issue I have with objcopy on windows, in that it works 50% of the time.  re-run it manually as:

human68k-objcopy -v -O xfile default\SAMPLE1 default\SAMPLE1.X

And you have a 50/50 chance of a working executable.

[costa]

Yep, that weird.

I run from command line and it worked!
Same commands from within the CodeBlocks IDE does not.

[neozeed]

Yep, that weird.

I run from command line and it worked!
Same commands from within the CodeBlocks IDE does not.

You can change the command line that code blocks uses to include the -v, but eventually it'll stop working so you'll have to remove it.  The windows tools are slightly older than the source, so I don't know if it was fixed.  I haven't tried to build gcc on mingw in forever, let alone a cross compiler

[Super]

Apologies for bumping a nearly four year old thread, but I'm having a bit of a problem with this toolchain.  It compiles the test Hello World program just fine, but when I go to run it, it gives me this address error on the X68K:

Code Select Expand

SR=$0004:PC=$0006F81C

Here's the test code I'm trying to compile and run:

Code Select Expand


#include <stdio.h>

int main(void)
{
    printf("Hello world!\n");

    return 0;
}


Trying to dump the file using human68k-objdump ends up with an error as well: "File truncated".
I've attached the compiled executable below if you want to test/examine it yourself, any idea what could be causing the problem?  I suspect it might be related to the issue with objcopy, but I'm not 100% sure...

[neozeed]

Apologies for bumping a nearly four year old thread, but I'm having a bit of a problem with this toolchain.  It compiles the test Hello World program just fine, but when I go to run it, it gives me this address error on the X68K:

Code Select Expand

SR=$0004:PC=$0006F81C

How did you build it?  I had massive problems if I stripped anything.

To be honest, you'll probably have better luck with my 'packaged' and englishified cross gcc 1.37

https://sourceforge.net/projects/gcc-1-30-x68000/

With the latest download here:

https://sourceforge.net/projects/gcc-1-30-x68000/files/x68000-gcc130_15-9-2016.7z/download

The real 'star' of the package is run68 which lets you run x68000 CLI based EXE's

You'll need to edit \x68000\env.cmd & \x68000\bin\run68.ini

change d: to whatever drive you are running it from (or fix the path).

Code Select Expand


C:\x68000>gcc hello.c -o hello.x
hello.c:      9: Message:Optimization is not done

C:\x68000>run68 hello.x
...Hello world!


I think I was messing with run68 back then. so too many '.''s... I think was something to do how null doom exhausted memory.  It's probably me just unfamiliar with the platform in general.

Anyways good luck!

[neko68k]

I'm also going to say don't use this toolchain. Most of the time it works for simple stuff but anything with even a little complexity falls over for a variety of reasons. I exclusively use native tools and previously used neozeed's win32 package with great success during the Doom port.

[Super]

I just tried neozeed's GCC package and that was able to compile a properly-running Hello World program!  Thanks for your help

[neozeed]

Great!

I'm super glad that you are on the way for writing software!

There is one big caveat I just remembered, gcc 1.x doesn't handle cross endian stuff very well.  In the doom port, there is a fixed point math statement that compiles backwards. It's not just this x68000 gcc that does it, an i386 to SUN3 does the same thing. (maybe it's the 68000 target??).

It's just something to be aware of.

My (lame) ports of Nethack and other useless stuff were never impacted by this.

It's literally one line of C which becomes 2 statements in 68000 asm if I recall correctly.  So odds are that you may not even run into it.  All of neko's 68000 platform code compiled and runs correctly without any worry (and we were so lucky to have one user with a beefy enough 68030 run it on real hardware too!!!).

Feel free to post follow up's, or whatnot.

Don't fear raising the dead.

[kamiboy]

If it is the ludyx toolchain youbare talking about I have developed many complex projects using it. Including a pretty comprehensive 2D platformer game engine.