Hi x68000 users !
I've finally decided to release my human68k target toolchain.
A way to develop for X68000 using your Linux or Windows box.
My github page : https://github.com/Lydux (https://github.com/Lydux)
Notes:
Actually, newlib lacks of some important low-level functions. I haven't time to maintain it actually. So, any help will be highly appreciated. (Codes/bugs/documentation/...)
Lastest updates:
Sources : 11/23/2012
Windows binaries : 11/26/2012
Setup for Unix like OS
1 - Environment settings
(change as your needs)
# export HUMAN68K_TC=/opt/human68k
# export HUMAN68K_TC_SRC=$HUMAN68K_TC/src
# export PATH=$PATH:$HUMAN68K_TC/bin
# mkdir $HUMAN68K_TC $HUMAN68K_TC_SRC
2 - Binutils
Binutils provide an assembler/disassembler and various tools for executables manipulation.
# cd $HUMAN68K_TC_SRC
# git clone git://github.com/Lydux/binutils-2.22-human68k.git
# mkdir binutils-build
# cd binutils-build
# ../binutils-2.22-human68k/configure --prefix=$HUMAN68K_TC --target=human68k --disable-nls
# make all install
3 - GCC
C compiler. Handle some specificities of the X68000.
# cd $HUMAN68K_TC_SRC
# git clone git://github.com/Lydux/gcc-4.6.2-human68k.git
# mkdir gcc-build
# cd gcc-build
# ../gcc-4.6.2-human68k/configure \
--prefix=$HUMAN68K_TC \
--target=human68k \
--disable-nls \
--disable-libssp \
--with-newlib \
--without-headers \
--enable-languages=c
# make all install
4 - Newlib
Provides common functions for programming in C and does all startup code for communication with human68k kernel.
Provides also system call functions (IPLROM = iocscall, Human68K = doscall)
# cd $HUMAN68K_TC_SRC
# git clone git://github.com/Lydux/newlib-1.19.0-human68k.git
# mkdir newlib-build
# cd newlib-build
# ../newlib-1.19.0-human68k/configure --prefix=$HUMAN68K_TC --target=human68k
# make all install
5 - GDB (optional)
A debugger. It can control the rom monitor embedded inside the IPLROM via a null modem cable.
# cd $HUMAN68K_TC_SRC
# git clone git@github.com:Lydux/gdb-7.4-human68k.git
# mkdir gdb-build
# cd gdb-build
# ../gdb-7.4-human68k/configure --prefix=$HUMAN68K_TC --target=human68k --disable-nls
# make all install
Notes
By default, the toolchain will create an ELF binary file, which is not directly compatible with human68k.
The objcopy tool from binutils provide a way to convert your file easily.
Assuming a simple hello.c source code :
For XFile :
# human68k-gcc hello.c -o hello.elf
# human68k-objcopy -O xfile hello.elf HELLO.X
Or for RFile (can also be used for pc relative SRAM target binary) :
# human68k-gcc -mpcrel hello.c -o hello.elf
# human68k-objcopy -O binary hello.elf HELLO.R
The toolchain also allow you to disassemble an XFile (Usefull for reverse engineering !) :
# human68k-objdump -D ANYFILE.X
Objdump can also show symbols and relocations (relocations does not point to the correct symbol actually)
# human68k-objdump -x ANYFILE.X
Setup for Windows
1 - Download the necessary packages
Download the lastest Windows binary version of Code::Blocks from official website : http://www.codeblocks.org (http://www.codeblocks.org)
Download the cross-Human68K toolchain packages for Windows :
Binutils-2.22 : http://nfggames.com/X68000/Development/toolchain/binutils-2.21-human68k-win32-3.zip (http://nfggames.com/X68000/Development/toolchain/binutils-2.21-human68k-win32-3.zip)
Gcc-4.6.2 : http://nfggames.com/X68000/Development/toolchain/gcc-4.6.2-human68k-win32-1.zip (http://nfggames.com/X68000/Development/toolchain/gcc-4.6.2-human68k-win32-1.zip)
Newlib-1.4.0 : http://nfggames.com/X68000/Development/libraries/newlib-1.19.0-human68k-1.zip (http://nfggames.com/X68000/Development/libraries/newlib-1.19.0-human68k-1.zip)
Make-3.82 : http://nfggames.com/X68000/Development/toolchain/make-3.82.zip (http://nfggames.com/X68000/Development/toolchain/make-3.82.zip)
Download the Human68K Wizard for Code::Blocks : http://nfggames.com/X68000/Development/toolchain/codeblocks-wizard-human68k-1.zip (http://nfggames.com/X68000/Development/toolchain/codeblocks-wizard-human68k-1.zip)
2 - Installing the toolchain :
Just extract all toolchain packages into a directory of your choice. (Ex : C:\X68000\DEV)
3 - Installing and configuring Code::Blocks :
Install Code::Blocks like any other application and start it.
Go to "Settings->Compiler and debugger" menu.
Make a copy of the "GNU GCC Compile" (should be selected by default) by clicking on the "Copy" button. Name this new compiler "Human68K GCC".
Now go into the "Toolchain executables" tab, and change all values by these one :
(http://i.imgur.com/NT2G4.png) (http://imgur.com/NT2G4)
Note : The debugger is not available yet, I have to figure out how to to use it for remote debugging a real x68000 or an emulator.
Of course, change the "Compiler's installation directory" by the one you have choosen.
Now, extract the "Human68k Wizard for Code::Blocks" archive into the directory "share\CodeBlocks\templates\wizard" of your Code::Blocks installation directory (by default, it should be "C:\Program Files\CodeBlocks")
Stay in this wizard directory and edit the file "config.script" (using windows notepad is ok).
Search for these lines :
RegisterWizard(wizProject, _T("arm"), _T("ARM Project"), _T("Embedded Systems"));
RegisterWizard(wizProject, _T("avr"), _T("AVR Project"), _T("Embedded Systems"));
RegisterWizard(wizProject, _T("tricore"), _T("TriCore Project"), _T("Embedded Systems"));
RegisterWizard(wizProject, _T("ppc"), _T("PowerPC Project"), _T("Embedded Systems"));
and add this one after :
RegisterWizard(wizProject, _T("human68k"), _T("Human68K Project"), _T("Embedded Systems"));
Restart Code::Blocks, this is now a template "Human68K Project" with a familiar icon when you create a new project.
(http://i.imgur.com/lgr40.png) (http://imgur.com/lgr40)
It will create a simple "hello world" application, you can try building it in order to check that your toolchain is correctly working.
You can also create a new library for Human68K by choosing "Static Library" instead of "Human68K Project".
Happy coding ! :)
Built and working. http://i.imgur.com/SmUog.jpg (http://i.imgur.com/SmUog.jpg)
I'll get right to work :)
Good ! ;)
I see you are on windows, this toolchain should compile as well under MSYS or cygwin.
I also have a ready to use native packages of binutils, gcc, gdb and make for windows which I should drop here for the code::block tutorial. But I can eventually upload them now if you need...
Doesn't matter. I run both windows and linux pretty regularly.
Excellent toolchain, just installed with minor problems (I didn't know I needed Bison and Flex, and the configure for binutils didn't yell at me about it).
I should make a simple bash script to install this for easy automation ;)
Great work. Many thanks for that.
However, I have a problem assembling the following simple source code ("test.asm"):
.global main
.text
main:
move #33,%d0
lea hello,%a1
trap #15
clr.w -(%sp)
dc.w 0xff4c
.data
hello:
.asciz "Hello World!"
.end
It's been assembled with
human68k-as test.asm -o test.elf
and converted to an executable format using
human68k-objcopy -O xfile test.elf test.x
It seems that the address of the text label "hello" cannot be resolved.
A disassembly of the ELF output via
human68k-objdump -D test.elf
gives
test.elf: file format elf32-m68k
Disassembly of section .text:
00000000 <main>:
0: 303c 0021 movew #33,%d0
4: 43f9 0000 0000 lea 0 <main>,%a1
a: 4e4f trap #15
c: 4267 clrw %sp@-
e: ff4c Address 0x0000000000000010 is out of bounds.
.short 0xff4c
Disassembly of section .data:
00000000 <hello>:
0: 4865 .short 0x4865
2: 6c6c bges 70 <hello+0x70>
4: 6f20 bles 26 <hello+0x26>
6: 576f 726c subqw #3,%sp@(29292)
a: 6421 bccs 2d <hello+0x2d>
...
As you can see the "lea" loads the wrong address. So does anyone know what's wrong?
TIA
Sascha
Hi AnimaInCorpore !
Nothing is wrong ! You have just assembled your source, and converting it to an XFile. But not created an executable !
So, the result of AS will produce a relocatable elf32-m68k object. Which is expected.
Take a look :
$ human68k-objdump -tr test.o
test.o: file format elf32-m68k
SYMBOL TABLE:
00000000 l d .text 00000000 .text
00000000 l d .data 00000000 .data
00000000 l d .bss 00000000 .bss
00000000 g .text 00000000 main
00000000 g .data 00000000 hello
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
00000006 R_68K_32 hello
See ? There is a relocation inside your text section, at offset 0x00000006 and does point to the symbol "hello" which is in the data section.
This is because at this stage, the object have absolutly no clues about the futur size and loading address for the text and data sections. Chances are they will grow up. And only the LINKER will know them !
That's said, while your code is (almost) good, you are missing some things if you want to go into pure assembler with Human68k. A startup code in fact (crt0) and a linker script. Both are provided within the toolchain and are directly used by gcc at link time.
So, just use GCC instead of AS :
# human68k-gcc test.S -o test.elf
This way you will get a working executable.
Note : use .S extension with assembler sources. GCC does not know about .asm, and will complain about the file format.
One last thing, take it as an advice : avoid using iocscall functions if a superset is available as doscalls.
So :
.global main
.global hello
.text
main:
move.l hello, %sp@-
.word 0xff09 | _DOS_PRINT
clr.w %sp@-
.word 0xff4c | _DOS_EXIT2
.data
hello:
.asciz "Hello World!"
.end
Might be better, because IOCS_B_PRINT does not necessary know the current cursor location, while DOS_PRINT does. Iocscalls are more suitable to SRAM based programs.
Have fun ! :)
Hello lydux,
thanks a lot for the help and suggestions.
For my dirty source I have just taken two snippets from a disassembled program to see if the reassembling would work so this was no real "programming" attempt.
Finally using GCC works perfect and the resulting output can be executed after being converted to the xfile format.
I suppose that you have some experience in programming for the X68000? Have you been a developer on the X68000? I was active in the Atari ST scene many years ago and have written some demos for it.
Cheers
Sascha
Quote from: AnimaInCorpore on September 07, 2012, 07:27:36 AM
I suppose that you have some experience in programming for the X68000? Have you been a developer on the X68000?
Not at all ! I'm just an hobbyist with knowledges into various domains, and (very) interested into this machine. I study it since about 2 years now. What I have done for the x68000 is an application of what I've learned here and there.
It still remains many things I don't know yet !
Quote from: AnimaInCorpore on September 07, 2012, 07:27:36 AM
I was active in the Atari ST scene many years ago and have written some demos for it.
I don't know the ST very well on software side (more about the hardware), but I'm pretty sure development is simplier on x68000 because of more supportive devices and many more or less powerfull syscalls provided by the bios (iocscalls) that simplify a lot the development process. We really would like to see homebrew applications here you know ! ;) At least, something that could be more interesting than an "hello world".
Quote from: AnimaInCorpore on September 07, 2012, 07:27:36 AM
For my dirty source I have just taken two snippets from a disassembled program to see if the reassembling would work so this was no real "programming" attempt.
It's not that "dirty", it totally reflects how it could be simple to get into x68000 programming ! With 4 lines of simple asm code, you initiate an executable, print an "hello world" string on screen, and exit to the OS shell properly.
And what I've modified in your code is just an advice, not necessary the way to go. As is, it will work as it should.
Anyway, if you want to go further, a must have for development is the punigrammer manual. The lastest known one is the 5.1 :
http://nfggames.com/X68000/Mirrors/x68pub/x68tools/PROGRAM/ETC/PUNI5_1.ZIP (http://nfggames.com/X68000/Mirrors/x68pub/x68tools/PROGRAM/ETC/PUNI5_1.ZIP)
Files are in japanese (encoded as Shift-JIS) but easy to understand using a translator. The archive contains almost all that have to be known about the x68000. Especially those "iocscall.txt" and "doscall.txt" files.
"Inside X68000" is also a good litterature :
http://nfggames.com/X68000/Pic/Inside%20X68000/ (http://nfggames.com/X68000/Pic/Inside%20X68000/)
Unfortunatly as JPG scan. So translation is a bit difficult. I use an OCR scanner to get the text, this gives me good results.
Have Fun !
Finally !
Here is the tutorial for using the toolchain for Windows users.
Setup for Windows
1 - Download the necessary packages
Download the lastest Windows binary version of Code::Blocks from official website : http://www.codeblocks.org (http://www.codeblocks.org)
Download the cross-Human68K toolchain packages for Windows :
Binutils-2.22 : http://nfggames.com/X68000/Development/toolchain/binutils-2.21-human68k-win32-2.zip (http://nfggames.com/X68000/Development/toolchain/binutils-2.21-human68k-win32-2.zip)
Gcc-4.6.2 : http://nfggames.com/X68000/Development/toolchain/gcc-4.6.2-human68k-win32-1.zip (http://nfggames.com/X68000/Development/toolchain/gcc-4.6.2-human68k-win32-1.zip)
Newlib-1.4.0 : http://nfggames.com/X68000/Development/libraries/newlib-1.19.0-human68k-1.zip (http://nfggames.com/X68000/Development/libraries/newlib-1.19.0-human68k-1.zip)
Make-3.82 : http://nfggames.com/X68000/Development/toolchain/make-3.82.zip (http://nfggames.com/X68000/Development/toolchain/make-3.82.zip)
Download the Human68K Wizard for Code::Blocks : http://nfggames.com/X68000/Development/toolchain/codeblocks-wizard-human68k-1.zip (http://nfggames.com/X68000/Development/toolchain/codeblocks-wizard-human68k-1.zip)
2 - Installing the toolchain :
Just extract all toolchain packages into a directory of your choice. (Ex : C:\X68000\DEV)
3 - Installing and configuring Code::Blocks :
Install Code::Blocks like any other application and start it.
Go to "Settings->Compiler and debugger" menu.
Make a copy of the "GNU GCC Compile" (should be selected by default) by clicking on the "Copy" button. Name this new compiler "Human68K GCC".
Now go into the "Toolchain executables" tab, and change all values by these one :
(http://i.imgur.com/NT2G4.png) (http://imgur.com/NT2G4)
Note : The debugger is not available yet, I have to figure out how to to use it for remote debugging a real x68000 or an emulator.
Of course, change the "Compiler's installation directory" by the one you have choosen.
Now, extract the "Human68k Wizard for Code::Blocks" archive into the directory "share\CodeBlocks\templates\wizard" of your Code::Blocks installation directory (by default, it should be "C:\Program Files\CodeBlocks")
Stay in this wizard directory and edit the file "config.script" (using windows notepad is ok).
Search for these lines :
RegisterWizard(wizProject, _T("arm"), _T("ARM Project"), _T("Embedded Systems"));
RegisterWizard(wizProject, _T("avr"), _T("AVR Project"), _T("Embedded Systems"));
RegisterWizard(wizProject, _T("tricore"), _T("TriCore Project"), _T("Embedded Systems"));
RegisterWizard(wizProject, _T("ppc"), _T("PowerPC Project"), _T("Embedded Systems"));
and add this one after :
RegisterWizard(wizProject, _T("human68k"), _T("Human68K Project"), _T("Embedded Systems"));
Restart Code::Blocks, this is now a template "Human68K Project" with a familiar icon when you create a new project.
(http://i.imgur.com/lgr40.png) (http://imgur.com/lgr40)
It will create a simple "hello world" application, you can try building it in order to check that your toolchain is correctly working.
You can also create a new library for Human68K by choosing "Static Library" instead of "Human68K Project".
Happy coding ! :)
This is a great day for the X68K.Thanks you, master Lydux!
Master Lydux, this is out of this world ! Keep up the good work !
Eidis
Quote from: lydux on September 09, 2012, 09:10:10 AM
Anyway, if you want to go further, a must have for development is the punigrammer manual. The lastest known one is the 5.1 :
[...]
"Inside X68000" is also a good litterature :
[...]
Thanks for the links to the documentation. I am not sure if the first is much different from the one I have found so far here:
http://datacrystal.romhacking.net/wiki/Sharp_X68000 (http://datacrystal.romhacking.net/wiki/Sharp_X68000)
So unfortunately it seems that there's no official english documentation. :(
Anyway, thanks for your effort and advice.
Cheers
Sascha
I also very highly recommend Inside X68000, it's the best resource available in any language.
Also check this. http://daifukkat.su/wiki/index.php/X68000 (http://daifukkat.su/wiki/index.php/X68000)
There is also source available for many old things here http://nfggames.com/X68000/Mirrors/x68pub/ (http://nfggames.com/X68000/Mirrors/x68pub/) Most(some, many, all? I'm not really sure...) will not build in the new toolchain without some work.
FYI: thanks to the Human68k toolchain the following project has become a reality:
The X68000 games porting experiment (http://www.atari-forum.com/viewtopic.php?f=68&t=24111)
Cheers
Sascha
Quote from: AnimaInCorpore on November 12, 2012, 04:12:52 AM
FYI: thanks to the Human68k toolchain the following project has become a reality:
The X68000 games porting experiment (http://www.atari-forum.com/viewtopic.php?f=68&t=24111)
Cheers
Sascha
Impressive work, congratulations!And what about porting games to X68000 instead?Obviously I mean arcade games which use 68000 CPU
P.S.
I'm wondering if this software can be useful to make also some porting to Amiga:
http://aminet.net/search?query=x68000 (http://aminet.net/search?query=x68000)
Quote from: caius on November 12, 2012, 08:43:57 AMImpressive work, congratulations!And what about porting games to X68000 instead?Obviously I mean arcade games which use 68000 CPU
P.S.
I'm wondering if this software can be useful to make also some porting to Amiga:
http://aminet.net/search?query=x68000 (http://aminet.net/search?query=x68000)
Thanks.
In fact, I was already thinking about porting from/to every M68000 system (like Atari ST, Amiga, X68000, Sega Saturn, NeoGeo, Arcade). Due to the fact that I have an Atari Falcon the current porting experiment goes this way first. Also I was in doubt that it will work anyway but luckily it does. ;)
Cheers
Sascha
Nice job Anima !
I would like to know more. Any plan on release some source code of your tools ?
I guess you have written for Mint a human68k/iocs emulation layer for some syscalls and graphics chips, and if I understand correctly a human68k decompiler ?
It reminds me that I may have somewhere a patch for the x68k toolchain that add a new processor called "human68k" which add those bastards syscalls instructions using the lineF exception. So when disassembling an XFile, it will show "dos_#####" instead of ".short 0xff##". Interested ?
Hey lydux!
neko and I just ran into a problem while working on some code. Whenever I use .set, it seems that the symbol it creates isn't marked as "absolute", so when Human68k dynamically links it, it relocates the symbol even though it''s not supposed to. Example:
.set OBJTYPE_COUNT, 2
LEA.L (objinit_lut), A0
MOVE.L #OBJTYPE_COUNT-1, D0
1:
MOVEA.L (A0), A1
JSR (A1)
ADDQ.L #4, A0
DBRA D0, 1b
Instead of loading 1 into D0, it'll load VMA + 1 (which in a lot of cases is like $5F801), which is obviously completely wrong.
I tried messing around with the source in the BFD folder, but I have no idea how BFD really works, so I was unable to fix the problem. Any help would be appreciated!
EDIT: Also, if anyone wants me to add more documentation to the daifukkat.su wiki, let me know. I translate things as I need them and add them there, but if there's any information anyone wants, I can do them anyways.
Hello Trap15 !
Well, I have tried to reproduce your problem but was unable to.
Here is the asm code I used, based on your, GAS style :
.extern objinit_lut
.set OBJTYPE_COUNT, 2
lea.l objinit_lut, %a0
move.l #OBJTYPE_COUNT-1, %d0
1:
movea.l %a0@, %a1
jsr %a1@
addq.l #4, %a0
dbra %d0, 1b
Correct ?
$ human68k-as test.S -o test.o
$ human68k-objdump -t test.o
test.o: file format elf32-m68k
test.o
architecture: m68k, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
private flags = 0:
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000012 00000000 00000000 00000034 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 00000000 00000000 00000000 00000048 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 00000048 2**2
ALLOC
SYMBOL TABLE:
00000000 l d .text 00000000 .text
00000000 l d .data 00000000 .data
00000000 l d .bss 00000000 .bss
00000002 l *ABS* 00000000 OBJTYPE_COUNT
00000000 *UND* 00000000 objinit_lut
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
00000002 R_68K_32 objinit_lut
The OBJTYPE_COUNT symbol is effectivelly marked as absolute, and no relocation against it, as expected.
At this time, nothing is used related to the xfile backend.
Now, convert to xfile (it will use bfd)
$ human68k-objcopy -O xfile test.o test.X
$ human68k-objdump -x test.X
test.X: file format xfile
test.X
architecture: m68k, flags 0x00000003:
HAS_RELOC, EXEC_P
start address 0x00000000
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000012 00000000 00000000 00000040 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
SYMBOL TABLE:
no symbols
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
00000002 R_68K_32 .text
$ human68k-objdump -D test.X
test.X: file format xfile
Disassembly of section .text:
00000000 <.text>:
0: 41f9 0000 0000 lea 0x0,%a0
6: 7001 moveq #1,%d0
8: 2250 moveal %a0@,%a1
a: 4e91 jsr %a1@
c: 5888 addql #4,%a0
e: 51c8 fff8 dbf %d0,0x8
Off topic : there is a bug here. I shouldn't be able to do this, as test.o is not marked as executable, objcopy shouldn't allow converting it to xfile.
Only one relocation in .text section at offset 2 which should normally be the external symbol "objinit_lut". And the "move.l #OBJTYPE_COUNT-1, %d0" remains a 16 bits opcodes, so no relocation possible.
I have missed something ?
Hm that's interesting. It seems like it only causes the bug if the .set is in another file and it's marked .global maybe?
So try doing two source files:
.global OBJTYPE_COUNT
.set OBJTYPE_COUNT, 2
LEA.L (objinit_lut), A0
MOVE.L #OBJTYPE_COUNT-1, D0
1:
MOVEA.L (A0), A1
JSR (A1)
ADDQ.L #4, A0
DBRA D0, 1b
Link them together into an elf, then copy that to an xfile. I think that'll manifest the bug?
Hum well... That's different !
test: file format elf32-m68k
test
architecture: m68k, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
private flags = 0:
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000018 00000000 00000000 00000034 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 00000000 00000018 00000018 0000004c 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000018 00000018 0000004c 2**2
ALLOC
SYMBOL TABLE:
00000000 l d .text 00000000 .text
00000018 l d .data 00000000 .data
00000018 l d .bss 00000000 .bss
00000000 *UND* 00000000 objinit_lut
00000002 g *ABS* 00000000 OBJTYPE_COUNT
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
00000008 R_68K_32 OBJTYPE_COUNT+0xffffffff
00000002 R_68K_32 objinit_lut
test: file format elf32-m68k
Disassembly of section .text:
00000000 <.text>:
0: 41f9 0000 0000 lea 0 <.text>,%a0
6: 203c 0000 0000 movel #0,%d0
c: 2250 moveal %a0@,%a1
e: 4e91 jsr %a1@
10: 5888 addql #4,%a0
12: 51c8 fff8 dbf %d0,c <.text+0xc>
...
The output is correct. This is the use of this symbol which seems wrong to me here !
I feel a misunderstand about the purpose of a symbol.
At compile time, it does not know nothing about OBJTYPE_COUNT and will mark it as an undefined symbol, assuming this refer to something available later at linking time. So, the assembler have no other choice than creating a 32 bits relocation here.
Now, the purpose of the .set directive is to create an arbitrary symbol, and assign a value to it. By definition, a symbol is an information used by linkers and debuggers to reference something within the address space. At runtime, a symbol means nothing, as it have no allocated space, its own address is just 0 !
So, by using an immediate addressing to OBJTYPE_COUNT, you will get 0 and keep the relocation at linking time.
I think what you want is the value of the symbol :
LEA.L (objinit_lut), A0
MOVE.L OBJTYPE_COUNT-1, D0
1:
MOVEA.L (A0), A1
JSR (A1)
ADDQ.L #4, A0
DBRA D0, 1b
Obvious he ? :)
Nope, that doesn't work because then it tries to read a long from VMA+1, which not only is also incorrect, but causes an address error.
The issue is that the relocation should be marked as "absolute", so when Human68k tries to load it, it doesn't try to relocate it. Going from the xfile.c source in bfd/, I'm guessing you need to add support for the absolute section, or something along those lines.
Edit : Urgh.... I have written a large message here, but I've probably said shit ! You're probably right, there maybe a bug with relocations to an absolute symbols. Forgive me, let me some times to check carefully.
For those who wants to go with pure assembler code with this toolchain, here is a simple skeletton of code you can start to work with.
It contains a minimal startup code that will initialize the program environment and a ready to use Makefile that will compile all assembler files, and create the final XFile.
Also, it does not use the libc at all, so you are on your own.
All you have to do is to modify the user source code (main.S), and 2 top lines of the Makefile to your needs.
Then, go to this directory and type "make".
Note to Windows users : This should work for you as well, you just have to add the directory which contains binaries of the toolchain in your environment variable "PATH".
Links : http://nfggames.com/X68000/Development/samples/x68k-asm-skel.zip (http://nfggames.com/X68000/Development/samples/x68k-asm-skel.zip)
Happy coding !
Thank you as always, Master, au revoir!
To trap15 and neko68k : you got me guys ! :)
I finally understand your problem. The fact is that ld when resolving all symbols on final link, will rewrite the content needed by a relocation with the address of the value it point to. But in your case, you're using an arbitrary defined and external symbol, later marked absolute, like a constant, not an address like a normal symbol should be.
I were wondering is this is legal... Of course it could be, why not ? I personnally never do this, because the toolchain provides a preprocessor, which is much more powerfull in this way.
But because the symbol were totally resolved, I saw no point why ld continue to emit this relocation !
I finally went to binutils mailing list, and found a thread with a similar issue. (with a shared library on an x86)
According to binutils developper, this is not really wanted, but as they said an "historical mistake". Such behavior is sometimes needed.
So yes, something is wrong here. Here is the fix :
https://github.com/Lydux/binutils-2.22-human68k/commit/2dabd9fa7bab0abaa9e5502087ad48efec9c6678
I guess I have to thanks you, and hope it will work now.
Hee hee, I do seem to have a habit of breaking things ;)
That patch works perfect, no problem now.
I preferred to not use the preprocessor because then I'd have to #include files, and it's a lot more friendly to just make everything global symbols that don't require any dependencies.
For the windows setup what distribution of GCC do you have installed? You need one to get the include header files like "stdio.h", right?
I went with MinGW.
Right now when I try to build I get a long string of warnings if stdio.h is included and used. If I remove that and try to build basically an empty main{} program I get the following error and no object file:
-------------- Clean: default in FDR68K (compiler: Human68K GCC)---------------
Cleaned "FDR68K - default"
-------------- Build: default in FDR68K (compiler: Human68K GCC)---------------
human68k-gcc.exe -g -c E:\X68K\DEV\projects\FDR68K\main.c -o .objs\main.o
as: unrecognized option `-m68000'
Process terminated with status 1 (0 minutes, 22 seconds)
0 errors, 0 warnings (0 minutes, 22 seconds)
All windows binaries packages have been cross-compiled from my linux workstation using a personnal toolchain relying on mingw32 C runtimes.
I'm not very familiar with windows, but I guess if you wish to use this toolchain under mingw, you will have to use msys and compile each packages like you will do under linux (see first post of this thread).
Quote
For the windows setup what distribution of GCC do you have installed? You need one to get the include header files like "stdio.h", right?
Those headers are part of the C library (newlib in our case). GCC does not provide headers (or very few, which are used internally).
Quote
human68k-gcc.exe -g -c E:\X68K\DEV\projects\FDR68K\main.c -o .objs\main.o
as: unrecognized option `-m68000'
Process terminated with status 1 (0 minutes, 22 seconds)
0 errors, 0 warnings (0 minutes, 22 seconds)
Something is wrong here... human68k-gcc try to use the host AS (i386) as assembler ! That's why you get an "unrecognized option `-m68000'" error.You should see "human68k-as" instead here.
What have you done exactly ?
What I did was I dowloaded all the windows packages that you linked to. Dumped them all in a folder, then followed your guide to setup Code::Blocks.
Finally I created a new x68k project and tried to compile. At first I got error messages regarding stdio.h missing, so I figured that is because my include folder being empty since I had no proper GCC distribution installed.
So I downloaded mingw and installed it to the same folder so as to populate the include folder. I then added the include folder to the list of project search folders and tried to recompile.
I got a bunch of warnings about the contents of stdio.h this time and still no binary. So I opted to remove stdio.h and printf from main.c and tried to recompile and I got the message that you saw.
I suppose I could just move the contents of your setup code to an emulator and just use the C compiler for Human68K.
All this linux setup stuff goes way, way above my head. I am used to more userfriendly compilers that do everything for you like VC and Xcode.
Quote
All this linux setup stuff goes way, way above my head. I am used to more userfriendly compilers that do everything for you like VC and Xcode.
I'm aware of this, that's why I've created a mostly ready-to-go windows toolchain.
Ok. First of all, you normally do not need to change anything within the toolchain. Just extract all packages into a single directory and that's all.
Your problem is a path issue : the c compiler (gcc) does not use the correct assembler (as) not even the correct post-processor (cc1, the one that will deal with headers files).
So, make sure :
- All packages are unzipped into the same directory (without subdirectories).
- Your "Human68K GCC" compiler settings in Code::Blocks point to the correct directory.
- Your Windows environment variable "PATH" does not contains a directory that point to another toolchain. To check for this, just open a command prompt, and type "as -v". It should not find anything.
Okay, the main issue seemed to have been that a few important lib and include header items were unzipped in the human68k folder.
I am not sure whether you did this on intention or not but I moved them to the project folder.
I am talking about the contents of newlib-1.19.0-human68k-1.zip and binutils-2.21-human68k-win32-3.zip
Once I did that and added the "lib" and "include" folders to the "Human68K GCC" compiler the build process got a bit further. But then ld would complain about not finding crt0.o.
No idea why that is. Perhaps it is due to my moving the aforementioned items. Anyway I awkwardly solved that issue by copying crt0.o around into different folder until the build process completed. In the end it had to be present in my project root folder.
Now that I can build a valid "Hello world" program I can finally start to look at some more advanced stuff.
Are there any good sample codes for how to place DOS and IOCS calls in C?
Quote
Okay, the main issue seemed to have been that a few important lib and include header items were unzipped in the human68k folder.
I am not sure whether you did this on intention or not but I moved them to the project folder.
That's normal and not my decision. The idea behind this is to let you use multiple c runtimes/libraries for differents target but sharing the same processor, so using the same compiler.
Quote
Once I did that and added the "lib" and "include" folders to the "Human68K GCC" compiler the build process got a bit further. But then ld would complain about not finding crt0.o.
No idea why that is. Perhaps it is due to my moving the aforementioned items. Anyway I awkwardly solved that issue by copying crt0.o around into different folder until the build process completed. In the end it had to be present in my project root folder.
Now that I can build a valid "Hello world" program I can finally start to look at some more advanced stuff.
Again, it's highly probable that your c compiler use a wrong preprocessor ! Compiling a simple "hello world" might work actually, but you will get troubles for more advanced sources (like operations that involve cpu endianness, or specific target definition : "#ifdef HUMAN68K") .
Quote
Are there any good sample codes for how to place DOS and IOCS calls in C?
Unfortunatly not really... I lack of time for trully testing the newlib port and provide samples as I personnally not use Human68K very often.
But anything you can provide this way is highly welcome ! (bugs, demos, documentations, ...)
All I can tell you actually is to check headers files "iocs.h" and "dos.h" which contains all prototypes you need and look for the corresponding description in japanese inside the punigrammer manual (iocscall.txt and doscall.txt)
As a sample, here is a quick simple ROM dumper that will use 3 doscalls :
/*
* Simple bios dumper for Human68K
*
* Various ROM locations in address space :
* CGROM : 0xf00000 --> 0xfbffff (768KB)
* Internal SCSI ROM (X68000 only) : 0xfc0000 --> 0xfdffff (128KB)
* IPLROM :
* X68000 : 0xfe0000 --> 0xffffff (128KB)
* X68030 : 0xfc0000 --> 0xffffff (256KB)
*/
#include <stdio.h>
#include <dos.h>
#define IPLADR ((const char *) 0xFE0000)
#define IPLSIZE (128 * 1024)
int main (int argc, char **argv)
{
const char *filename;
int fd;
printf ("Simple X68000 IPLROM dumper by Lydux\n");
if (argc != 2)
{
printf ("Usage : %s output_file\n", argv[0]);
return -1;
}
filename = (const char *) argv[1];
/* Create a newer empty file */
fd = _dos_create (filename, 0); /* Normal mode (erase if existing) */
if (fd < 0)
{
printf ("Error while creating file \"%s\" !\n", filename);
return -1;
}
/* Write to the file */
_dos_write (fd, IPLADR, IPLSIZE);
/* Close handle */
_dos_close (fd);
printf ("Done !\n");
return 0;
}
Okay, that seems pretty straight forward.
I have begun to identify the IOCS calls that are relevant to my purpose. Trouble is all I have to go on is this: http://datacrystal.romhacking.net/wiki/X68k:IOCS (http://datacrystal.romhacking.net/wiki/X68k:IOCS)
The above is fine if you plan on doing assembly coding but quickly become inadequate when trying to place the same calls through C. There should be some sort of resource that documents the input/output parameters of the C IOCS function calls.
Does not matter whether it is in English or Japanese, as long as I can dump the text into a translator.
If that is not possible then could someone explain to me whether I understand the following correctly.
If I understand correctly d1 and d2 are both registers often used for passing/receiving DOS/IOCS function call parameters.
Now, in the doc I often see things like d1.hb and d1.b. Does that refer to the high and low byte area of said register (assuming that it is a 16 bit register of course)
The Sharp C books will have what you are looking for. There are other books with similar overviews. They're pretty common on y!j. Otherwise, just realize that you're doing the asm anyway, just called through a func that inlined the asm. Realistically if you need any kind of performance at all you should be writing asm anyway ;D
Yeah, I figured all the IOCS and DOS function calls did were to pass their parameters into the right registers, but it seemed that the two first parameters in that particular case were being packed into the same resister.
Anywaste, after a bit of experimentation I figured it out. The "hb" part just needed to be shifted up << 8 bits and ored together with the "b" part. Pretty much as I figured it would be.
As for assembly, no thank you. As much as I enjoy programming for old school systems assembly is where I draw the line.
I have no experience at all with 68000 assembly, but once long, long ago I wrote a simple breakout game prototype in x86 assembly, that is it as far my assembly experience goes.
Takes too damn long to even do the simplest stuff in assembly. I am lazy, hard to motivate and the rare supply of enthusiasm that I can muster burns out fast. Sticking to C means I can at least get to finish a program with a level of complexity a notch or two above "Hello World".
For tools and such it is not necessary to do anything but C anyway. Hell, you might even get away with going the Basic route. For game projects on the other hand, well, I can certainly see the argument for coding some inner loops in assembly. But I think you could still get away with keeping most of the project coded in C.
Do what makes you happy I guess :) FWIW I've seen very little C at all in the wild. Even the simplest tools were written in asm. Remember, you've only got 10mhz and maybe 2MB of ram to work with :)
Questions, questions.
Master lydux, your arcane knowledge is needed.
First an inquiry regarding accessing memory in old fashioned C.
Is is possible to use regular old C pointers to access areas of interest in the X68000 memory at whim?
Say, for an example, that I wanted to mess around with the Sprite Data memory area, which is located at 0xEB0000.
Could I just:
unsigned char *sp = 0xEB0000;
then start reading and writing ala:
sp[0] = 0x01; //etc. etc.?
It would seem that I cannot do as such as I get bus errors when I try. Any way to do that correctly other than using appropriate IOCS function calls to manipulate the Sprite Data bits in memory in addition to other areas of interest?
I ask because using IOCS function calls is slow as opposed to just raw access.
In any regard, I've noticed an discrepancy between the IOCS call _iocs_sp_regst in the cross-chain and the definition of said function as found here: http://daifukkat.su/wiki/index.php/X68000/IOCS/SP_REGST (http://daifukkat.su/wiki/index.php/X68000/IOCS/SP_REGST)
In the cross-chain that function has 6 input parameters whereas that website only claims there to be 5. Calling the function with different parameters and keeping an eye on how they change X68000 memory I've come to the conclusion that in the cross-chain the second parameters seems to be doing naught.
It is thus I find:
_iocs_sp_regst(spriteID, ?, x, y, info, priority)
Where does this discrepancy come from? Is that website's definition of IOCS C function calls obsolete or what? Are there any sources up to date with the calls in the cross-chain?
More questions.
Say for a simple game, how does the render cycle look like?
I am currently trying to get a single sprite to show up on screen and have had no luck.
I assume one first changes the video mode, then calls the init sprite function call and sets sprites to ON so they are visible.
Then one uploads the sprite graphic data to PCG, and updates the sprite register so there is a sprite with the desired location whose data references the graphic in PCG.
I've gotten that far, but I have nothing on the screen so there must be more to it?
Does one have to call a certain function to have the system rasterize sprites?
How does one wait for vertical retrace and all that jazz by the way. There are way too many unknowns and reading through IOCS calls I do not seem to be able to find that I am looking for.
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.
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.
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.
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 :
#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.
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.
Hello kamiboy,
here (http://www.atomic-skulls.de/temp/pm2.s) 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:
human68k-gcc -nostartfiles pm2.s -o pm.o && human68k-objcopy -O xfile pm.o pm.X && cp pm.X pacmania/
Cheers
Sascha
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 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51969#c1).
Cheers
Sascha
Thanks Anima !
Pushed this fix to my repository.
Quote from: AnimaInCorpore on June 18, 2013, 05:44:01 PM
Hello kamiboy,
here (http://www.atomic-skulls.de/temp/pm2.s) 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:
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?
Quote from: lydux on June 18, 2013, 09:51:19 PM
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:
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.
Quote from: kamiboy on June 18, 2013, 10:49:30 PM
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. ;)
Quote from: kamiboy on June 18, 2013, 10:49:30 PM
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
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.
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
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.
Just a short note (again to myself) how to build the toolchain using Ubuntu 14.04:
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
Ok. Do you know if it's an Ubuntu specific or a generic GCC 4.8 issue ?
Quote from: lydux on May 27, 2014, 10:05:11 PM
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/ (http://sourceforge.net/p/mspgcc/bugs/362/)
Cheers
Sascha
Looks like a target bootstrap issue. I'll try installing a GCC 4.8.1 for checking.
Thanks for the report !
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:
-------------- 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:
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
This doesn't work for codeblocks, but it works for the CLI... I added a -v to objcopy and it gives me different output!
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?
(http://i.imgur.com/aOX1q9G.png)
But I got the quick hello world working so that's fantastic!!!! ;D
Totally pointless, I know.. but
(http://i.imgur.com/l6Z79JK.png)
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 (http://www.planetemu.net/rom/tandy-radio-shack-trs-80-model-1/infocom-adventure-executor-source-files-1987-infotaskforce-c)
Hi Neozeed !
Congratulations on a work well done ! Could you please post the compiled executable ?
Keep the scene alive !
Eidis
Quote from: eidis on December 14, 2014, 09:11:07 PM
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 (http://sourceforge.net/projects/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.
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 (http://vpsland.superglobalmegacorp.com/install/x68000/run68-infocom-gcc-x68000dev.win32.7z). And here is a xdf disk image that'll boot up and let you try the demos (http://vpsland.superglobalmegacorp.com/install/x68000/infocom.xdf.7z). 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... :o
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.
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...
Quote from: neko68k on December 17, 2014, 02:03:24 AM
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.
Quote from: neko68k on December 17, 2014, 02:03:24 AM
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:
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.
12/17/2014 02:36 PM 522,776 dosdoom.XMy source is here (http://vpsland.superglobalmegacorp.com/install/x68000/cdoom-human68k.7z), 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 (http://doom.wikia.com/wiki/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.
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....
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
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.
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.
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 ?
Thanks for taking a look, I hope this doesn't overflow things like crazy...
Quote from: lydux on December 22, 2014, 02:56:47 AM
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:
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.
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!!!!
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 (http://sha-bang.de/nethack.html)). 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.
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.
462,822 nethack.x
And it runs under run68 and XM6 TypeG!
(http://i.imgur.com/2QOmITe.png)
(http://i.imgur.com/DAIwLK2.png)
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 (http://vpsland.superglobalmegacorp.com/install/x68000/nethack13dr-x68000.7z). 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:
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));
_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 (https://github.com/adoxa/ansicon).
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.
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))
Quote from: costa on April 26, 2015, 06:20:18 AM
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.
Yep, that weird.
I run from command line and it worked!
Same commands from within the CodeBlocks IDE does not.
Quote from: costa on April 26, 2015, 09:33:05 AM
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
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:
SR=$0004:PC=$0006F81C
Here's the test code I'm trying to compile and run:
#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...
Quote from: Super on January 18, 2019, 07:06:18 AM
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:
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).
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!
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.
I just tried neozeed's GCC package and that was able to compile a properly-running Hello World program! Thanks for your help :)
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.
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.
Quote from: kamiboy on January 19, 2019, 07:56:03 PM
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.
At least you got lucky, it was unable to build a null version of doom that would even attempt to execute.
The GCC port is modified to use the HAS assembler, which at least produces stuff that'll run.
I always ran into problems eventually. Even Soldam, which is 99% assembly, stopped working eventually under lydux toolchain.
I don’t think running something as comprehensive as doom is a good benchmark for that toolset. It is perfectly fine for doing your own projects from scratch. Porting code from other platforms, not so much.
I've been playing around with the X68K using neozeed's GCC and was able to figure out how to load data into PCG-RAM, but I ran into a bit of a problem:
The data gets loaded fine, but for whatever reason it's twice as wide as it should be:
(https://cdn.discordapp.com/attachments/222573230953594881/541894314125688843/unknown.png)
There isn't a whole lot of information out there on exactly how the X68000 formats it's graphical data (or at least not any information that I could find), so any tips (or possibly even utilities) would be highly appreciated.
I've attached my data file below in case you want to examine it. Note that I didn't create a palette for it, so it would theoretically use palette colors #61 (a dark teal-ish color by default) and #FF (a very-slightly-greenish white by default).
PCG is 4-bit 1-dimensional packed into 8-bits. So you have 4-bit pixels where rows are stored sequentially in RAM.
[edit]
that is to say, two 4-bit pixels for each 8-bits. The high nibble is the left pixel, the low nibble is the right pixel.
[edit edit]
And 16x16 data is stored as 4 8x8's like so:
1|2 = 1|3|2|4
3|4
Thanks for the clarification, neko!
One hex editor session later, I was able to create a 192-byte file that, when loaded into PCG-RAM, shows a smiley face and a stick figure:
(https://cdn.discordapp.com/attachments/222573230953594881/542025269221785610/unknown.png)
My advice; grab a copy of the PUNI (https://nfggames.com/X68000/Mirrors/Groundzero%20Organization/x68tools/develop/docs/puni/PUNI7_2.zip) docs and a copy of Inside X68000 (https://archive.org/details/InsideX680001992). Nearly everything is covered at least a little in the PUNI docs and anything missing or in need of detail is almost certainly in Inside X68000. There is also some info on the wiki (https://gamesx.com/wiki/doku.php?id=x68000:x68000#software_development)in English but it's pretty incomplete.
Quote from: Super on February 05, 2019, 02:56:14 AM
Thanks for the clarification, neko!
One hex editor session later, I was able to create a 192-byte file that, when loaded into PCG-RAM, shows a smiley face and a stick figure:
(https://cdn.discordapp.com/attachments/222573230953594881/542025269221785610/unknown.png)
awesome job~!@
Hey all, I just succeeded on building this toolchain on modern Linux (Ubuntu 18.04). There are a few tricks needed to get it to behave and I wanted to leave them here for posterity.
First, you will need to configure the tools with --disable-werror since newer versions of GCC have more warnings and these will break the build with werror. Second, newer Texinfo will choke when trying to build the docs, so add "MAKEINFO=true" to every make command to nop it out. Finally, when building GCC, you will need to apply this patch or GCC will segfault when building libgcc: https://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_7-branch/gcc/ira-int.h?r1=191605&r2=191604&pathrev=191605
I hope this helps. Happy hacking!
Quote from: UD2 on July 18, 2019, 04:05:22 PMHey all, I just succeeded on building this toolchain on modern Linux (Ubuntu 18.04). There are a few tricks needed to get it to behave and I wanted to leave them here for posterity.
Thanks for the info. I've created a short script which should work on modern machines incorporating your mentioned "ira-int.h" changes (https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=42001763ab5dc5d784f5af3599c7ecf98566fdad;hp=24f23714fc3ee778213e10e70fff624406da8447). Please read the comments in this script when you're about to compile it for an aarch64 system (like Raspberry Pi 4).
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install bison texinfo flex expect libgmp-dev libmpfr-dev libmpc-dev build-essential git
mkdir gcc_x68k
cd gcc_x68k
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
wait
printf 'diff --git a/gcc-4.6.2-human68k/gcc/ira-int.h.bak b/gcc-4.6.2-human68k/gcc/ira-int.h\nindex 049a07f..ddf1200 100644\n--- a/gcc-4.6.2-human68k/gcc/ira-int.h\n+++ b/gcc-4.6.2-human68k/gcc/ira-int.h\n@@ -1123,8 +1123,13 @@ static inline bool\n ira_allocno_object_iter_cond (ira_allocno_object_iterator *i, ira_allocno_t a,\n \t\t\t ira_object_t *o)\n {\n- *o = ALLOCNO_OBJECT (a, i->n);\n- return i->n++ < ALLOCNO_NUM_OBJECTS (a);\n+ int n = i->n++;\n+ if (n < ALLOCNO_NUM_OBJECTS (a))\n+ {\n+ *o = ALLOCNO_OBJECT (a, n);\n+ return true;\n+ }\n+ return false;\n }\n \n /* Loop over all objects associated with allocno A. In each\n' | patch -p1
cd binutils-build
../binutils-2.22-human68k/configure --prefix=/usr/local --target=human68k --disable-nls --disable-werror # --build=unknown-unknown-linux # add this for aarch64 machines.
sed -i 's/MAKEINFO = makeinfo/MAKEINFO = true/g' Makefile
make -j 4
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 --disable-werror # --build=unknown-unknown-linux # add this for aarch64 machines.
sed -i 's/MAKEINFO = makeinfo/MAKEINFO = true/g' Makefile
make -j 4
sudo make install
cd ..
cd newlib-build
../newlib-1.19.0-human68k/configure --prefix=/usr/local --target=human68k --disable-werror # --build=unknown-unknown-linux # add this for aarch64 machines.
sed -i 's/MAKEINFO = makeinfo/MAKEINFO = true/g' Makefile
make -j 4
sudo make install
cd ..
Hello all,
I succeeded to install on windows 10 the linux toolchain binaries available on https://www.target-earth.net/wiki/doku.php?id=blog:x68_devtools using the windows linux subsystem (ubuntu 20.04LTS)
went like a breeze :) and i builded the ipl dumperfrom lydux without any troubles. Thanks Lydux and Megatron
Hi everyone,
I'm new in this forum, I just signed up in fact.
I have been researching about programming for the X68000. I have built a fairly good wealth of knowledge I'd like to share and exchange should there were anyone interested.
I'm writing also a blog that deals with the X68000 and have a github with plenty of examples.
I tested this buildchain by the way and was very helpful at the beginning.
Hi there,
I have notices from some time ago that Lydux toolchain in windows stopped generating correct executables.
Needless to say that I reinstalled it a few times with the same outcome.
I wonder whether anyone else is experiencing the same issue.
I have tried the Linux version and it does work. I managed to make it work in a docker container in Docker Desktop and trick Code::Blocks to compile with it.
I'll make a tutorial on how to do it but I'd like that anyone confirm that they have the same problem.
Hi there, I cloned Lydux's toolchain in my github at https://github.com/FedericoTech/newlib-1.19.0-human68k
There I fixed some buggy functions so that I can compile all the examples I did at https://github.com/FedericoTech/X68KTutorials
I did a Pull Request on Lydux so if he ever sees it and accepts them they would be also available in the official branch.
I hope it helps.