X68000 online programming documentation

[kamiboy]

Back in 2013 when I started dabbling in X68000 programming I would have been dead in the water if it had not been for excellent informative resources such as http://daifukkat.su/wiki/index.php/X68000

Alas, that wiki seems to have up and vanished in the three years since. This is a huge blow to any future hopeful. I contacted what I believed to be the owner of that site and got no reply. Then I tried the wayback machine to try and find archived versions of the wiki, only to find only one or two pages of the wiki are archived.

Anyone know who owned that wiki? For the sake of posterity, and because it would be useful to myself in the future, I would love to have that wiki hosted, or archived somewhere else rather than in the null void if the internet past.

[elmer]

Anyone know who owned that wiki? For the sake of posterity, and because it would be useful to myself in the future, I would love to have that wiki hosted, or archived somewhere else rather than in the null void if the internet past.

It's Alex Marshall's site (aka "trap15") ... http://daifukkat.su

He used to have some PC-FX pages on there that have disappeared, too. Luckily I archived those before the wiki disappeared.

I didn't get any response from him at the email address on that site either.

He still hangs around on a few forums, and I unexpectedly ran into him here ... http://shmups.system11.org/viewtopic.php?f=1&t=54696

I never saw his X68000 pages; may I ask what was on there that isn't available here?

[trap15]

I'm pretty sure there's nothing that was on there that isn't available elsewhere. I don't think I have the database anymore, as it was on a site that suffered a pretty intense breakdown and I sucked a backups, but I'll look through my various backups and see if there is anything there.

I'm pretty bad at email, much like phone calls. I'll get it, read it, intend to respond later, then totally forget about it. Sorry about that.

[kamiboy]

There was a lot of information there that I have not found elsewhere. Trap15, if you could zip up the entire x68000 wiki and forward it that would be awesome.

Examples of information hosted there was inner workings of sprites, etc.

Never would have figured out half of that stuff on my own.

[trap15]

Like I said, I don't know if I even have it anymore. If you know what information you want, I can probably directly explain it anyways. I'm pretty sure most of the info was just translated (mostly machine-translated) from the IOCS documentation.

[kamiboy]

I do not want to bother you with every little detail that I am unsure of, your wiki was gold, google translated or not, the layout alone made looking stuff up was very easy. Please make an effort to locate it if you still have the files.

Can't you just do a search for files of certain names on your PC to locate the files if they still exist? Maybe your storage situation is more complicated than that, but I assure you it will be worth the effort to not let the wiki go to waste. It really was the most useful english language x68000 programming resource on the net.

[trap15]

It was a wiki, which means it's in a single database. I just looked in the only place it would be and I do not have a backup of the database. So yes, it's all gone, sorry. Like I said though, all the information is already available in other documents.

[kamiboy]

Holy "darth vader nooo.gif", batman! That is a great blow to the society.

Do you at least have a package of all the documents that served as the source for the compiled information somewhere?

It would be nice to have it all nicely zipped in one place.

I have some of them, but trouble is they are in encoded in a strange Japanese format that none of my editors can read properly. Someone once told me what the encoding was called, but I am unsure which program I should use to make them readable, as well as copy pasteable.

The good thing about the wiki was that it had information about IOCTS and DOS C library function calls. Most of the documentation I found are about assembly. Furthermore the low level hardware stuff I have not been able to find anywhere else. I guess they might have come from a hard copy programming manual which I obviously do not have at hand.

[elmer]

I have some of them, but trouble is they are in encoded in a strange Japanese format that none of my editors can read properly. Someone once told me what the encoding was called, but I am unsure which program I should use to make them readable, as well as copy pasteable.

Old Japanese docs are usually encoded in SJIS (shift-JIS ... you can look it up on wikipedia).

Notepad++ will happily read SJIS docs, and it will usually auto-detect the encoding. If it doesn't, then you can manually tell it to treat a doc as SJIS in the menu "Encoding->Character sets->Japanese->shift-JIS".

You can then convert the file to UTF-8 with "Encoding->Convert to UTF-8-BOM" at which point it'll be back in a nice modern-day standard that everything can read.

[kamiboy]

Good to know, cheers!

[elmer]

The good thing about the wiki was that it had information about IOCTS and DOS C library function calls. Most of the documentation I found are about assembly. Furthermore the low level hardware stuff I have not been able to find anywhere else. I guess they might have come from a hard copy programming manual which I obviously do not have at hand.

Have you looked at the wiki (and translation project) here ...

http://datacrystal.romhacking.net/wiki/Sharp_X68000

Seems like you could just talk to the guys there, create an account, and add the C prototypes from DOSLIB.H and IOCSLIB.H right into the wiki's assembly documentation ... or do some cut-n-paste and create 2 new pages ... whatever the guys there think is best.

That way you'd have your easily-accessible online wiki (that is backed-up), and you'd be doing the X68000 world a service.

Does that make any kind of sense?

[kamiboy]

Everything you said made perfectly good sense except for the part where I have to do any actual work. My motivation to continue my personal X68000 project already hangs on a hair like the sword of damocles.

Besides, the lost wiki had information about the use and function of those calls, machine translated or not. The point was it saved me time since I could look things up quickly.

[elmer]

OK, that's a little bit sad, but it makes perfect sense. 

Can I ask you ... is an "int" 16-bits or 32-bits in the current compiler?

Does anyone know what size it is in the Hudson compilers?

[elmer]

OK, since this tread seems to have gotten at least a few views ... let me ask this question to the folks here.

This forum and the resources here show (to me) that this is the premiere English-speaking community of X68000 enthusiasts on the planet.

So ... if I have an interest in attempting to follow in the footsteps of such folks as Neill Corlett and Lydux ... then this seems to be the right place.

Which brings me to the question ... I've seen 2 semi-current resources for X68000 programming documentation ...

1) MIJET's site : http://mijet.eludevisibility.org/X68000%20Technical%20Documents/English%20X68k%20Docs.html

2) ROM Hacking's http://datacrystal.romhacking.net/wiki/Sharp_X68000

If (and that's still an "if") I choose to spend some of my time updating lydux's work to newer GCC compilers, and then helping out folks like Kamiboy in getting some modern-C documentation put together ... then where should everything go so that it doesn't get lost, and so that folks that come after me and Kamiboy can benefit from the effort?

[kamiboy]

The sizes of int and long are both 4 bytes in the current compiler. No idea about the Hudson compiler since I never used it. But I think long is supposed to always be four bytes, even though int sizes can vary from compiler to compiler.

As for how to lend any piece of niche information permanence on the internet. Personally I've never trusted internet sources to always be there. I remember distinctly thinking back in 2013 that all this wonderful information about the x68000 might succumb to entropy one day.

I considered saving all the wiki pages to my hard drive so I would always have them, but there were so many, many pages that I got lazy and gave it up. I regret that descision.

[elmer]

The sizes of int and long are both 4 bytes in the current compiler. No idea about the Hudson compiler since I never used it. But I think long is supposed to always be four bytes, even though int sizes can vary from compiler to compiler.

Thanks, I thought that might be the case.

The only guarantees in C are that "int" is at-least 16-bits and that "long" is at-least 32-bits.

My memory of 68000 C compilers is that "int" should be 16-bits because that's the "natural" size on the processor.

You can set that with the "-mshort" flag to the compiler ... as long as your library has been built properly.

The next time that I mess about with newlib I'll have to see about switching "libdos" and "libiocs" to use the modern <stdint.h> types.

I considered saving all the wiki pages to my hard drive so I would always have them, but there were so many, many pages that I got lazy and gave it up. I regret that descision.

The X68000 wiki and the files section here is an absolute godsend ... I really hope that it is all well-backed-up.

[kamiboy]

The x68000 wiki that was lost was ten times better than the one still around. I would never have figured out the, honestly, very strange inner workings of the x68000 graphics hardware without crucial information that I dug out of it.

Not sure what good switching to stdint.h will do, but I think a better use of your time would be to investigate why calling dos_files(..) causes a fault.

[elmer]

Not sure what good switching to stdint.h will do, but I think a better use of your time would be to investigate why calling dos_files(..) causes a fault.

It's part of the same issue ... C stack parameters and alignment.

This is why programmers use stdint.h and don't assume the size of things ...

https://sourceware.org/ml/newlib/2015/msg00420.html

The 68000 is a 16-bit processor, and 68000 C really code should be using 16-bit values wherever possible ... it's a performance issue.

Sure 68020/68030/etc are fine with 32-bit values, but that's not what's in the regular X68000 machines.

[kamiboy]

I know, but I use 32 bit ints in my project. You need those to access the memory otherwise you'd be stuck with only 64k. I do use chars and shorts wherever possible though. So you are going to turn ints into 16 bit integers, eh? That will prolly require me to make changes to my code as otherwise things will break.

I really should define my own types like u8, u16 and u32 to remove any doubt.

[elmer]

I know, but I use 32 bit ints in my project. You need those to access the memory otherwise you'd be stuck with only 64k. I do use chars and shorts wherever possible though. So you are going to turn ints into 16 bit integers, eh? That will prolly require me to make changes to my code as otherwise things will break.

Eeek!

For-gawds-sake, please don't store a pointer in an "int" ... that's the kind of behavior that caused a decade of grief for people looking-at or maintaining C code.

That's precisely why there is stdint.h these days ... it totally standardized exactly how to guarantee the size of parameters.

That includes the use of "uintptr_t" as the type if you want store a pointer in a integer-type (particularly for pointer-arithmetic).

I'll try to leave "int" as 32-bits by default as long as it doesn't compromise the code when you use GCC's "-mshort" flag to force 16-bit ints (which is what I'll be doing in any projects that I do).

Because libdos and libiocs communucate directly with assembly code, with all those little stubs grabbing parameters directly off the C stack ... that is exactly where the size of the parameters is critical.

That's why those particular libs need to be changed to specifically use int16_t or int32_t instead of just "int".

I really should define my own types like u8, u16 and u32 to remove any doubt.

That's what we all did in the 1990s. Then stdint.h arrived.

Even Microsoft finally got off their corporate behinds to support it in Visual Studio 2010 (nearly a decade later than everyone else).

[kamiboy]

Well, as long as the dos_* calls get fixed I can deal with any consequences.