6502.org

Hi all.

Some time ago, I built my first SBC. It was based on a 6502, with a very limited set of IO (4x20 LCD screen, and 4 push buttons for input). It was build with a very specific purpose, and it has served me well.

Now, I'm on the very early stages of the design of a full fledge 65816 computer. It's meant to have a standard set of inputs (keyboard, mouse, full VGA or higher screen), and a properly usable OS and tools.

It's a highly ambituous project, and I'm in no hurry to complete it but, to facilite development of the OS and all software, I'm pretty sure I will need something more than pure assembly.

After a few days searching, both in here and in the whole internet, I haven't found anything very useful. It feels like the WDC tools are the only available option, and they seem to be not so well maintained.

Anyway, after some fighting, I've managed to code and compile some small examples, using bits of ASM and C code. I can also run the code in the included emulator.

However, I'm seeing something wrong. I'm not sure if it's my fault, or just an annoying bug in the software.

When I select to run emulating a 6502 (Not a 65816 in emulation mode, but running the emulator as a 6502) I see 16 bit registers! however, If I set the emulated CPU as a 65816... I get 8 bit register in the debug tool.

I've run some code using the registers, and they are correctly emulated, it's just the display now doing its job as it should. It is then, just something annoying... but I could use the tools for my development.

So, my questions to the forum... Is this some known behaviour? Or am I doing something wrong? Is it fixable? Are there any better options?

And, even though I've searched.... I'm sorry if this has come up before.

Cheers!

The WDC tools are mostly functional but are also very archaic... as you might have noticed! I certainly did when I tried out the compiler and had it throw confusing errors and sometimes it would just silently crash for no apparent reason.

I'm sorry I can't help you with your issue as I've never touched the debugger...
But I can point you to another option, Calypsi C for the 65816: https://www.calypsi.cc/

That's what I'm using with my SBC and while it's sadly not open source, it is actively being maintained and C99 complaint. (It also supports binary notation unlike WDC's compiler)

On a side node, once I got my VGA card going I also want to look into some basic OSdev-ing though my approach will be trying to port GEOS to the 65816. I honestly don't know if it would be easier or harder than making something from scratch....

Hi,

Better? I don't know. Let me describe an alternative...

While I use cc65 on the 65C02, I've not tried any C on the '816. The WDC compiler isn't an option for me - and ok, I've not actually tried it, but when investigating it, it's MS Windows only and while it can and does run under WINE, that's really not my thing.

So when I moved from the 65C02 to the '816, after porting my 65C02 OS which has ideas taken from the Acorn MOS, and capable of running some Acorn software in 65C02 emulation mode - e.g. BBC BASIC, I thought about all this 16-bit goodness and what to do with it.

I moved to the '816 because other projects seemed to be using it - it was mooted for the Commander X16 and the Foenix but they turned out to not happen or just be too expensive and taking too much time.

On a personal note, I'm a little disappointed with the '816. Yes, there were some good projects made with it - the Acorn Communicator then the Apple //gs and latterly the SNES but it's not trivial to code for. Going 65C02 to 65C816 is actually a big step. Issues you have to think about are switching between 8 and 16-bit register and memory modes, indexing beyond 64KB, extra stack addressing modes, movable direct page and many others. It has some nice features - maybe multi-tasking with each task having it's own 64KB of RAM? Maybe some high level language to make use of the extra stack addressing modes? Or maybe even a set of good macros for assembler - but then you end up with something like Sweet16 (32?)/Acheron/etc ... But you still need to write code in assembler, even if it is a good macro assembler.

A good C compiler ought to be able to hide this from you - give you the ability to write programs > 64KB, address data structures > 64KB, but yes, there are trade-offs - manipulating what is effectively a variable pointer size - how much hand-holding do you want to give the compiler and how much do you want it to do for you? Anyway ...

So I made my system anyway - kept it simple, used GALs and an ATmega "host" processor - just because I could and it was actually relatively easy to adapt my old 65C02 board.

So here I was, with an 65816 system with 512KB of RAM on my desk - what to do? My intention had been a sort of "what if" ... as in what can I do with todays knowledge that I might not have thought of back then.

And the answer was along the lines of "forget it, there are better CPUs". In 1985 the 68K was real, ARM was on on the horizon as was the 80386, the and here in the UK we were looking at the 32-bit Transputer and the INS32016 (which turned out to be a bit of a dud, but that's another story).

So here I was, with an 65816 system with 512KB of RAM on my desk - what to do? I went back to my ideas of a self-hosting system - what language? Not C, so ... BCPL.

I've been an on/off fan of BCPL since the early 80's. It's capable of self-hosting, the compiler is fast enough on old hardware, the tricky thing was making the current 32-bit BCPL system run on a hybrid 16 bit system with an 8-bit memory bus. The compiler can output a few different code formats - one is a format designed to be translated to native code by some external program, another is a bytecode designed to be interpreted on anything you care to write the bytecode interpreter for. That's the default and is the route I took.

So I wrote my bytecode interpreter (the bytecode is called CINTCODE - Compact Intermediate Code) and I wrote it in such a way to make the memory of the '816 appear as a contiguous 32-bit address space. That way BCPL programs could allocate > 64KB of RAM and iterate over it without any issues. Yes, this can be done in assembler and I think (hope) using the WDC C compiler too, but I had BCPL and wanted to use it.

My bytecode VM is 16KB of '816 macro assembler. It's as fast as I can make it without spending 10x more time on it - loops are unrolled, the execution environment is essentially threaded, there are no JSRs in the run-time of the interpreter - the bytecode dispatcher is built into every single decoded byte-wide instruction (all 255 of them). This takes 29 cycles, or 37 cycles when it has to increment the high word of the VMs program counter. That in itself is the speed limitation - at 16Mhz it's not too bad. Cintcode is very efficient and the compiler makes a good job of optimising it.

So my Ruby '816 boots into the old RubyOS written in '816 code (really 65C02) and can load programs from disk (SD card) via the ATmega - that lets it run BBC Basic with a RAM size of about 28KB, or it can load and run the BCPL OS. This is the 16KB bytecode interpreter/VM and that then boots directly into BCPL which loads up the rest of the BCPL OS. There is a shared library of routines and a command line interpreter. It's also multi-tasking, but bearing in mind there is no memory protection ...

Here is a demo - the "star" prompt is the RubyOS prompt and here we're in 65'816 mode. I run the BCPL program which is a 16KB "ROM" image (BBC Micro users will be familiar with this - it's 16KB from 0x8000) that loads the initial BCPL bootstrap and that then loads up the library and finally the CLI.

https://www.youtube.com/watch?v=ZL1VI8ezgYc

I run a program to calculate Pi to 100 digits - it takes just over 6 seconds. I then execute a script that fires off 12 clock programs, all running concurrently (displaying a random time, but updating once a second), then I re-run the Pi program which then takes just over 8 seconds as you don't get something for nothing.

So I have a CLI, editor, compiler and some unix-like utilities like ls, mv, cp ... The world is my bi-valve, as they say...

There is work to do but I'm not sure I'm up for it right now. Some of the library isn't "thread safe" and while very usable it's not perfect.

So why am I typing all this up ... Don't know. I've sort of lost enthusiasm on it all and not done any work for a year or so, so thinking of re-kindling it - wondering if it could be ported to someone elses '816 system? Or just move onto something else...

And as far as porting goes ... Well, along with history, I have wondered "what next" and moved to another CPU - RISC-V. It's still "retro" from my point of view, being based on the designs of the early 80s... So I wrote a RISC-V emulator in BCPL, used that to run some C programs on my '816 board (C compiled to RV binary), then (re) wrote the BCPL bytecode VM in RISC-V assembler and ran that under my BCPL emulator and it worked and booted by BCPL OS. It wasn't fast, but it did run. Subsequently I've ported it to some real RISC-V hardware (ESP32-C3 with 400KB of RAM) where it absolutely flies. Cycle for cycle, the RISC-V version is 5+ times faster...

Cheers,

-Gordon

Plenty of interesting info.... thanks!

I have the feeling (I had it before posting already) that I'm going to traverse a very obsolete path... The 65816 never surpassed the 6502 in popularity, and it's time is long gone, even though it may be a good fit for some projects.

This, for sure, is a disadvantage when it comes to supporting tools. If I chose to go, let's say, the ARM via, I wouldn't have a problem here.

But, this is kind of an emotional journey. And a purely educational project. Growing up in the 80's, with 6502 computers around, I'm trying to create a parallel-universe alternative to the Commodore Amiga. In this parallel universe, Commodore management was good, and they (not WDC) created the 65816 and used it succesfully in it's 16bit computer lineup. So I'm stuck with 65816.

At least, the ancient software will provide some early 90's vibe!

The early Amiga DOS was written in ... BCPL

https://en.wikipedia.org/wiki/AmigaDOS

-Gordon

I've spent some time recently using cc65 for the '816. The C library doesn't have a '816 target (and if fact only somewhat utilizes 65c02 features) but you can run programs on the '816 in emulation mode. It's not hard to create a custom library for the processor to switch to native mode, 16-bit registers and utilize expanded memory, but as the standard library modules are 6502-based, it's still pretty limited. I've been working to port the code generation and standard library modules to the '816. At over 400 files, it's not a small effort. You can get a fair amount of functionality though with about a third of those. I'm almost to that point now.

ooooh that sounds very interesting! i would love to have a 65816 version of cc65 that can actually make use of it's features like the larger hardware stack, and more addressing modes. do keep us updated on that!
though one thing i can see being an issue is the fact that the compiler has no context for how the segments are placed in memory of the target system (because it's the linkers job to worry about that), which means the compiler doesn't know what addressing modes to use to access the data/bss/rodata/??? segment, or call functions with.
if code and data each fit into 64k then you can stick with JMP/JSR/RTS and Absolute addressing (compiler assumes the Data Bank is correctly set or does it by itself).
but if data takes up multiple banks, the compiler either needs to switch to Absolute Long Addressing, or fiddle around with the Data Bank Register (same for the standard functions).
and if code is larger than 64k then the compiler needs to use JML/JSL/RTL and of course the correct standard library functions.
one way around that is to give the linker's config file to the compiler, so it has a rough idea of where segments sit in memory and can use the appropriate addresing modes.

another option would be to have standard names for the functions and then just have multiple object files for the same function in the library. (this is pretty much what WDC's compiler does with it's ~~, ~_, _~, and __ function prefixes).
or it could just say "screw it" and exclusively use Long addressing modes for both code and data unless functions/data are known to be in the same segment/bank, or the user specifies something manually using function/variable attributes like __near__ or similar.

anyways, i'm sorry i didn't want to derail the thread.
so ultimately you have 2 and half choices for C on the 65816.
1. Calypsi C
2. WDC's Compiler
2.5. cc65 with some tricks and hacks (which is what FUZIX is doing)

It really is frustrating that there's so few choices for 65816 C compilers. I've been working on a full Unix-ish OS for my SBC and so far I'm been doing it entirely in assembly using as65. Yes, it's doable, but it's approaching the point of not even being fun anymore.

I'm eyeing Calypsi, but it's closed source, and I'm worried i will be stuck with a code base that in 5 or 10 years will be only buildable on an abandonware project, or at least having to play the 'can I get this prebuilt binary to work even though it wants 10 year old libraries?" game that I've already played plenty of times with FPGA dev kits. [ I work exclusively on Linux, btw ]

Another big impediment to me switching tool chains is that I have a lot of code and tooling built around as65 and ld65, and all of that would need converted if/when I make a switch (I'd want to keep all my low level code and drivers in assembly). So, if/when I make the jump I want to be sure it's going to work for my needs.

It's really too bad there is no actual 65816 target for cc65, as it would slot perfectly into what I already have. Unfortunately I doubt it will ever happen...even as65 only has bare minimum support.

I usually don't like to talk about work in progress, but as there is some discussion on this topic, I thought I might mention that a 65816 backend for vbcc is currently in work.

Exciting!

Its simply not the right tool for todays work. It costs more than something that can drive an HDMI display board, it's slower (14Mhz vs 1.4GHz), has less RAM (576 bytes on the 265 vs. 2KB on a popular MCU or 32KB on an entry level "IoT" MCU which is cheaper), no integrated peripherals ('134 and '265 excepted, but they're just digital IO with no on-board pull up's) - requires too many support/glue logic chips and so on. Look at tasks where it might be used - and I can't think of any where AVR or PIC or some ARM or even RISC-V based microcontroller wouldn't be used. Even things like DRAM memory sticks have an on-board embedded MCU now, a "smart" charger for your phone has an on-board MCU of some sort (more compute power than we sent to the moon) - the Chinese have a 3 cent microcontroller they use in battery torches, flashing LED strings and so on. (Sure we can do it with a 555, but the MCU is cheaper, smaller, ...) Car electronics? Well you need to be able to talk CAN bus there these days. Car radios? Sure - make it listen to the dials and buttons, drive a digital tuner and display some nice data, but today that's all integrated in the central car computers and live streaming internet radio in a car is a thing now.

I'm sure it lives on in some highly niche embedded stuff (is it really still used in defibrillators? The ones I've used recently all speak to you and without additional hardware that's not going to happen) or everything else is "IoT" so needs Wi-Fi and the software/hardware to drive an IP stack.

We love it and keep using it because "brand loyalty" or we want to play the "what if..." game - even when we know there are better alternatives - I've been looking at RISC-V for some time now. Like early ARM, it's clean and uncluttered and a dream to code for. The last RISC-V development board I bought cost less than a single '816 in DIP form and has on-board Wi-Fi, 400KB of static RAM and can drive a graphical LED panel as well as having serial, I2C, SPI interfaces on-board.

So maybe we need to ask ourselves - and WDC - why is their development package in need of a significant make-over? And who is going to do it, when it will happen and how much will it cost? I'd also be asking why it doesn't work under Linux - a compiler, assembler and linker are just programs - and like the GNU tools they don't need (or really shouldn't need) a GUI. Open source it? What have they got to lose now that e.g. VBCC and cc65 might be catching up... (both which also run under Linux)

-Gordon

My guess, as several other have pointed out, the 65816 time is long gone. There are more powerful alternatives today, which are also more friendly to develop for.
Exactly my situation. I'm going through a rabbit hole that, in the best scenario, is going to cost me several years, and probably no less than 1k euros, just because I feel like to. Just so you can make an idea... my goal is a laptop form factor, with a look and feel in the ballpark of early AMIGAs, ATARI STs, or the Apple II GS.

Getting, or building, a useful tool chain for development, is just of the many matters I need to master

I know myself... maybe in 10-15 years, I'll make my own 65816 IDE with full support for many modern languages . Anyway, I'm still very far away in time from even a simple hello world, plenty of other items to finish before that.

This is going to be fun.

If you feel like taking a look... viewtopic.php?f=4&t=7434

Well you have your dFlat language to start with. Expand the compiler to cope with larger program and data spaces and off you go.

But think what Acorn had on the Acorn Communicator (which pre-dates the //gs) - They had an existing OS which they used on the 6502, so adapting it to the '816 probably wasn't hard (Similar to what I've done). Then they had a BASIC, and again, adapting it to a larger memory model wasn't too hard, neither I suspect was the in-line assembler for the BASIC... write the apps. for it (it was aimed at small businesses, hobbyists/home users never got them) and job done.

Apple did similar for the //gs at the start although they had mostly 8-bit software to make it as compatible with the Apple II as possible, it took a while for more 16-bit software to be available. Even then, AIUI, a lot of the programs, etc. for the //gs were written in assembler. Checking now, it appears the "Orca" suite - assembler, pascal and C compilers were there, but not for some time. (And the C compiler is written in Pascal). Since these projects are on Github under a source available, but no commercial use basis, then maybe some enterprising person can un-apple them and make them generic?
Get dFlat running on it ... Also something to note is that the first version of the OS for the ARM processor was written mostly in BBC BASIC. Writing shed-loads of code today in assembler is brain cell destroying and not sustainable. Once I had BCPL going on my Ruby board program development rocketed, relatively speaking - yes, at the expense of execution time, but not code size. The compiler is still 44KB of compiled bytecode.

-Gordon

as65? Do you mean ca65, the assembler cc65 ships with?
Anyways its understandable to be hesitant to jump onto a closed source platform, which is the main reason FUZIX doesn't use either compiler options for the 65816 according to one of the devs/repo maintainers.
Well we already heard that tmr4 seems to be working on a port, so I guess it's not completely hopeless!
Also what do you mean with the assembler only has "bare minimum" support for the 65816? if you do mean ca65 then the only thing I know it can't do by itself is keeping track of the direct page and data bank register. Which would allow it to automatically choose absolute or direct page addressing modes without having the programmer use prefixes. That would be a nice QoL thing, a directive where you can tell the assembler what the value of those registers is.
But besides that it's fully capable of handling the 65816.
Those are very exciting news, I really really hope the plan is to make it generate ca65 compatible assembly, so that the existing cc65 toolchain can be used instead of having to create a new one from scratch. That would also avoid the issue that was already discussed here, where users are hesitant to switch to a new toolchain because of the work required to port everything.
The only part of the cc65 utility that is not 65816 compatible is the compiler, everything else already supports it. So please atleast consider it.

On a side node, do you have any tips for getting started with a vbcc backend? I tries writing one for my SWEET32 VM for the 65816 (which fittingly requires ca65 compatible assembly to be generated) but using the official documentation and looking at the other targets didn't get me that far. Maybe it's just a bit over my skill level? Hmm...