Resurrecting the x816 cross-assembler

I wanted to add a follow-up on this specific subject. I spent most of Wednesday trying to track him down. Without going into all the crazy complexities, I've managed to get in contact with his brother who will be having Norman get in touch with me. Cross your fingers.

Nice!

That'd be nice. If I remember well, this cross-assembler had many attractive features. We could still use it through DOSBox, but meh, that is extremely impractical.

Was it written in X86 assembly? I ask because you said it could be "ported to C"... I do not know if it would be necessary to port the whole thing to C to get it run on 32-bit systmes. I have no knownledge in X86 assembly whatsoever, but probably he just need to change some instructions to get it run on 32-bit, similar to how a 6502 program could easily be made to run (although sub-optimally) on a 65c816.

According to its readme, it was written in Turbo Pascal.

Edit: Also, it'd be a fair bit more complicated to port the assembly, as this is software running in an operating system; it'd have to be changed to work with Windows rather than DOS. Furthermore, there's some major differences between 8086 and modern assembly especially regarding how memory is handled (e.g. segmentation).

Free Pascal should compile the Pascal parts.

I'm interested in x816 as well. Free Pascal would allow me to create a native version for myself as needed (given that it works with Mac OS X 10.4 or later for Intel Macs).

An unrelated thread reminded me of this one. I started this thread almost 2 years and wanted to note what all I've "accomplished" with regards to the subject:

Tracking down Norman was both easy and difficult. Most of what allowed me to get the info I dug up was my memory (where he was from, some minor personal details, etc.), combined with some extensive Googling. Relevant info was quite "deep" into search results, and I had to know exactly what I was looking for. I had to keep a Word document with all the details/stuff I found just to make sure I was following the right trail. I have to admit I came across some personal stuff (family matters, incl. property ownership, businesses, deaths, etc.), which made me feel extremely invasive of privacy. I knew Norman "decently" but nothing about his family, so this felt very awkward for me. Part of it is also that he's Chinese, and as a Mandarin speaker I'm familiar with general Chinese culture, so this made it *extra* uncomfortable for me. I wasn't expecting to find the stuff I did is all, and I have no clue what the dynamics/relationships are within the family, so I had to go out on a limb.

The best I was able to do was track down his younger brother on Twitter -- sounds crazy, but I have some random old info from BBS days that connect the two brothers together, so that's how I knew it was the right guy -- but he doesn't use it for anything other than RT's and trying to win free stuff in giveaways. That allowed me to indirectly find his brother on Steam, where I added him. Several days later I had the chance to talk to him (brother). Needless to say, it certainly sounded creepy ("hi I'm this old friend of your brother's during the 90s, blah blah, I wanted to ask him some questions about some old software he wrote, how could I get in touch with him" -- it would make me think "yeah sure, WEIRDO {delete}"), but I did get a definitive answer: Norman's on Facebook, so I should find him and talk to him there. I didn't push the matter any further, and removed his brother from Steam (respecting privacy etc.).

Thing is... I absolutely hate Facebook (way more than any other social media platform). I gritted my teeth for weeks, but eventually took the plunge and re-enabled my account from days of early Facebook days, and found + added Norman + crossed my fingers.

Sadly it's gone no where. I've done this at least 3 times in the past 2 years, but he never adds me back, and due to privacy settings obviously doesn't accept private messages from non-friends. I haven't managed to find him anywhere else.

So I'm kind of at an impasse. I have one final way to try and get in touch with him via phone, but it feels a bit too invasive considering it's a family/work-related phone number. I may end up having to re-add his brother and say hey, your bro didn't get back to me, is there an Email address or something...? The problem with the latter is that it seems pushy -- like for all his brother knows, I'm some weird stalker, or maybe I'm some guy trying to collect on old debts, or who knows what. You know?

That's my status update.

As for the assembler itself:

Given Norman's background and skill set, x816 is certainly a combination of Turbo Pascal and x86 assembly. Turbo Pascal did not have good memory management capability back in the late 90s (read: no native EMS or XMS support) -- I know because I extensively looked at the time so that I could make TRaCER (also in Turbo Pascal) linearly allocate more than ~60KBytes of memory and found nothing (that's why it's so slow: it literally reads from disk N bytes correlating with opcode+operand) -- so odds are Norman coded the XMS support himself. In the early 2000s there was a 386 protected mode extender for Turbo Pascal 7.x called Swallow, but the last x816 release was in 1998.

I use to use x816, it was the best back then. It was the first one I came across that had +/- labels; blew me away... now I just know I was really missing out in my youth.
Sadly the info I have on Ballistics is limited, seems they were an Canadian outfit, CSDB doesn't really cover NTSC land too well. However it seems Minus is also Nuclear Waste (Norman ) the other listed member is Thought Criminal aka Dave O'Neill. Demo groups tend to stick together unless they have a massive break up. Maybe tracking down Dave will get you an "in". or perhaps Y0shi is still around? Gideon Zhi is..

Although as good as x816 was it is a product of the time....

I *am* Y0SHi. :P

Nice to be remembered but I don't have any of the source codes or materials from way back then. I've just begun snooping on the C64 and SNES scene to see what new software/hardware is available for developement. Unfortunately time is very limited with personal commitments.

C64 : We are in the future, more assemblers than you can count on your fingers and toes. VR googles, flash carts, tape carts, sd drives, pi drive emulators, release schedules from multiple publishers, the old gods are back and making stuff again.

SNES : Do you think we could get the source code for X816, so I don't have to write code on my original P133 that I used back when the Y0shi doc was the only doc... At least now we have the official "books" to read Oh and the emulators are better and the debuggers are a bit better than Geiger's, now they don't try and fit into 640x480 so there is more room for buttons

Like they said, they don't have the source code anymore.

The hardware situation is much better than it was, particularly with the SD2SNES able to emulate nearly every special chip (including one that never existed in the first place). There's also the 21fx, a USB bootloader which hijacks the bus via the expansion port and can do some pretty neat stuff - then again, last I checked the availability was along the lines of "build it yourself"...

Also, with higan in its current state, emulation is far better than it was. Not to mention that the DSP-type special chips have all been decapped and dumped; higan LLEs them now.

The assembler situation is workable but could be better, and there is AFAIK no VR headset (though someone did notice that Hyperzone has hidden Famicom 3D System support and messed around with it a bit). Overall it does seem like the development scene is pretty slow even compared with the NES and Mega Drive, never mind the C64...

It was a summery of how things have changed/not changed that he listed he was checking in on, the joke being the C64 has flown to mars, the SNES we are still using Win95. I wasn't asking for their code, as you have pointed out as they pointed out they don't have it

(slightly off-topic, sorry.)

I very desperately want to get the 21fx manufactured and for sale to any interested parties.

It's the only dumper that analyzes the entire 16MiB address map, and supports (or at least, can support) every type of media possible -- BS-X flash carts and ROM carts, SA1 BS-X 16-bit flash carts, Sufami Turbo carts, S-DD1, SPC7110, and the firmware that is dumpable (basically, non-NEC uPD chips.) Still needs Nintendo Power support, I guess. But anyone can add anything using very simple C code.

It's also a perfect way to build a large suite of real hardware tests for emulation, including for things like the SA-1 and SuperFX, without having to hack up cartridges (can't do a lot of testing with anything that relies on ROM data, however.)

Homebrew's a bit trickier, limiting you to 128KiB WRAM, plus whatever the cartridge plugged in at the time provides. No room on the B-bus to expand things more. Cartridge bus version was planned, but ...



There's been a persistent barrier in that even the best, structured 65816 code is basically a write-only language (I've had to abandon several fan translations due to code rot.) And the CPU is just too slow and too limited (*one* accumulator, *two* index registers, awkward 8/16-bit toggling) to pull off a higher level language.

What has made the Mega Drive a breakout hit in homebrew is that you can write the non-critical sections in C. Any attempts at C with the 65xx chips produce unusably slow code.

I disagree. The 816 is relatively suitable for C, its stack modes in particular are useful for that; not as well as m68k, but far from unusable. I have several titles shipped in C for the NES, and Little Medusa for SNES, and given it's not unusably slow for NES, how could it be for the 1.5-2x faster SNES?

It's not the lack of suitability, but the lack of a compiler. Genesis has the latest GCC, arguably the best compiler in the world. SNES has nothing*, though I managed to use cc65 on it, cc65 doesn't count as a "real" SNES compiler in that it doesn't support it fully. It works, but it produces 8-bit code, which is not as fast as it could be on a 16-bit processor.

You can expect more SNES titles now that we have cc65 set up. Even with its limitations, it's a massive productivity improvement over asm.

*No, the WDC blob does not count. See previous threads.

while I will agree that 65816 is not the most readable language, and write only as you put it. I will however point out that 65816 is good solid chunk a head of 6502 in this regard, and the superlative specs of the SNES make it less of an issue compared to a C64.

@Calima

I'm curious regarding your cc65 comment for the snes. What are the limitation to expect? Since I like more and more to write c code for the nes the logical thing would be to write some for snes too but it's always good to be aware about the trade off to do so.

In general, cc65 is limited in that it's not a C-level optimizing compiler. It just translates what you write, and applies some asm-level optimizations. SNES specifically, it doesn't do banking, but just like with NES banking, you can work around that, with trampolines for example.

For banking that is not a big issue. What I would be more concerned is the comment about 8 bit generated code. That seems not much convenient. For UI screen it may be ok but more intensive code, I guess it need to be written in asm anyway.

yeah so not, direct banking, no 16bit code, not ,s stack relative commands, no faster 65816 versions of opcodes, the 65816 has a 6502 emulation mode.


How do you make a trampoline on the SNES, it doesn't have banking registers. Does CA65 at least you do something like I guess it also forces you into LOROM only?

Honestly if you want to use C on the SNES you would be better of using the OCRA/C https://github.com/byteworksinc/ORCA-C it will at least make native 65816 code and use ,s

ORCA-C's license has a no commercial use clause. That's a dealbreaker, so I didn't even look further at what it might be able to do.

When told to compile for 816, cc65 uses the best instructions it knows, which are the 65c02 extensions IIRC. Thus the code is better than when targeting NES, even if it doesn't know about 816-exclusive instructions. cc65 allows inline asm, and a SNES trampoline might work by a jump table, but many other ways too. Lorom yes, since it expects RAM in the same address space. It does not use the 6502 emulation mode, it runs natively, meaning any asm functions you've written can use anything new.

That's not much different from the NES; the speed-requiring functions are written in asm and everything else in C.

but does it understand 65816 asm or only 65c02 asm?

Also the ORCA suite is available to purchase https://juiced.gs/store/opus-ii-software/ which given its a language development suite would be fine for commercial purposes.

Yes, a paid version would not have that limitation. It would then still need to run on an Apple II (emulator), you couldn't change it, etc. which may not be obstacles to you.

cc65 inline asm passes it verbatim. ca65 supports 65816 fully.

To expand on this, cc65 just generates asm, not an object file. So any inline asm simply doesn't get translated from C to asm, instead being copied over.

I guess for my current needs cc65 is more than enough. I'm not ready to jump on a snes project yet but I may want someday to experiment a little bit so this could be what I'm looking for.

Maybe by the time I really make some project some new compiler etc may comes out, who knows? I'm used to take long break so I'm in no rush