Newbie to the 65816. WDCtools C compiler and debugger issue.

[kernelthread]

drogon wrote:

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.

True, on pretty much any objective criterion (except maybe device complexity) an ARM or AVR knocks it into a cocked hat. On the other hand, given that WDC is still in business, someone must be using the 65C02 and the 65C816. What tools to they use? I suppose they must use the WDC tools. Maybe the commercial versions of those tools are better? Or maybe the applications for those processors use very mature and carefully handcrafted assembler code of a relatively modest size?

[BigEd]

Just to note, I see TurboRascal (aka Turbo Rascal Syntax Error) supports the '816.
https://github.com/leuat/TRSE#readme
https://retrogamecoders.com/introductio ... ogramming/
https://lemonspawn.com/turbo-rascal-syn ... but-begin/
It's an open source cross-platform IDE for a pascal-like language, supporting various CPUs.

[drogon]

kernelthread wrote:

drogon wrote:

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.

True, on pretty much any objective criterion (except maybe device complexity) an ARM or AVR knocks it into a cocked hat. On the other hand, given that WDC is still in business, someone must be using the 65C02 and the 65C816. What tools to they use? I suppose they must use the WDC tools. Maybe the commercial versions of those tools are better? Or maybe the applications for those processors use very mature and carefully handcrafted assembler code of a relatively modest size?

I'm suspecting a combination of all the above - especially the bit about mature applications. I also suspect it's relatively cheap to do a fab. run of an existing design that hasn't changed for a very long time (e.g. wafers with the 6551 Tx flag bug) or at least cheap enough to make supplying existing chips worthwhile. Maybe there is a chip fab. plant somewhere geared up to make old fashioned chips with (say) < 10K transistors on-board at a good price (in which case - where/how/what/how much - as hobbyists are now making their own ICs, perhaps there is space for such an outlet aimed at hobbyists?)

Or is WDC sitting on a huge stockpile of chips that can quickly be run through a silkscreen printer to update the date codes? Who knows.

-G

[drogon]

BigEd wrote:

Just to note, I see TurboRascal (aka Turbo Rascal Syntax Error) supports the '816.
https://github.com/leuat/TRSE#readme
https://retrogamecoders.com/introductio ... ogramming/
https://lemonspawn.com/turbo-rascal-syn ... but-begin/
It's an open source cross-platform IDE for a pascal-like language, supporting various CPUs.

I've looked at this on/off for some time, but ... From what I can gather, the '816 support is aimed at the SNES platform. I'm not sure just how generic it might be. The assembler is 6502 only from what I can see.

And .. (Personal opinion) .. like Forth and Marmite, Pascal has it's enthusiasts and those less-so. Once I had systems I could program in C, I left Pascal behind, but like Forth, I've been paid to write Pascal applications in the past. (No amount of money will make me eat Marmite though!!!) The other great distractor for me is the IDE. I have an IDE. I've been using my IDE for over 30 years. It works for me. Give me the command-line tools so I can use them with my IDE.

I have a sort of half-baked plan to write a Pascal compiler - in BCPL to produce code that would run under my BCPL Bytecode VM system. The down-side is that it would probably not be faster than compiled BCPL but at least it would be Pascal.

-Gordon

[vbc]

Proxy wrote:

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.

I am afraid I have to disappoint you here. The vbcc65816 backend is using vasm and vlink just like the 6502 backend for a number of reasons:

• I prefer the pretty common, more standard syntax that vasm and most assemblers use.
• vasm/vlink support much more input/ouput file formats.
• vasm/vlink support a few features that vbcc uses which ca65 does not support.
• The existing 6502 backend already uses vasm and changing that would be additional work.

However, if there is some demand, it should be possible to add the object format used by ca65 to vlink, allowing to link files created with ca65 with vbcc-generated code. I have not looked deeper into this yet. vlink already supports o65 format, but I think the format of ca65 is something different.

Quote:

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...

The chapter "Backend Interface" in vbcc.pdf should contain the information regarding creating a backend. The source code contains a "generic" backend that can serve as a simple starting point for creating new backends. It does not create code for a real machine but it is intended to get you up running quick. You start by choosing the number of registers, memory-operands vs. load-store-architecture and two- vs three-address instructions. You might already get some output looking remotely like what you need. Of course then the real work starts and you have to get the format right, handle all the special cases, optimize the code etc.

Btw. you might choose another name for your VM. When googling it (without adding extras like 65816), I pretty much only get results on cyber-attacks...

[Proxy]

vbc wrote:

I am afraid I have to disappoint you here. The vbcc65816 backend is using vasm and vlink just like the 6502 backend for a number of reasons:

• I prefer the pretty common, more standard syntax that vasm and most assemblers use.
• vasm/vlink support much more input/ouput file formats.
• vasm/vlink support a few features that vbcc uses which ca65 does not support.
• The existing 6502 backend already uses vasm and changing that would be additional work.

However, if there is some demand, it should be possible to add the object format used by ca65 to vlink, allowing to link files created with ca65 with vbcc-generated code. I have not looked deeper into this yet. vlink already supports o65 format, but I think the format of ca65 is something different.

awww, sad
but i guess i did get used to Calypsi C's toolchain as well, so switching (for me atleast) shouldn't be much of an issue besides taking a weekend to get something up and running for my SBC.
a few questions though, does vlink support the PGZ output format? i even got ca65 to use this output format using some manual assembly magic. though i'm not married to it, so if there are better already supported options that doesn't require a lot of overhead like ELF, then i'm willing to rewrite my bootloader.

also, how do you define "more standard syntax"? one thing i dislike about really old assemblers is how strict they can be with their formatting, like instructions have to be lowercase only, instructions always have to be atleast 1 whitespace character away from the start of a line, or you HAVE to use EQU instead of just =. just ancient limitations that IMO shouldn't exist in modern tools anymore. and ca65 gives you a lot of freedom in how you format your code.

vbc wrote:

The chapter "Backend Interface" in vbcc.pdf should contain the information regarding creating a backend. The source code contains a "generic" backend that can serve as a simple starting point for creating new backends. It does not create code for a real machine but it is intended to get you up running quick. You start by choosing the number of registers, memory-operands vs. load-store-architecture and two- vs three-address instructions. You might already get some output looking remotely like what you need. Of course then the real work starts and you have to get the format right, handle all the special cases, optimize the code etc.

hmm, guess i'll have to just sit down and just chew through the documentation with the example code open at the same time to draw some parallels. thanks anyways!

vbc wrote:

Btw. you might choose another name for your VM. When googling it (without adding extras like 65816), I pretty much only get results on cyber-attacks...

yea i didn't google the name before deciding it. i might rename it to "SWEET32VM", "SW32VM", or "65VM32"...
hmm, i'll have to think on that for a bit.

[vbc]

Proxy wrote:

awww, sad
but i guess i did get used to Calypsi C's toolchain as well, so switching (for me atleast) shouldn't be much of an issue besides taking a weekend to get something up and running for my SBC.

Yes, I think that assembler uses a syntax more similar to that of vasm.

Quote:

a few questions though, does vlink support the PGZ output format? i even got ca65 to use this output format using some manual assembly magic. though i'm not married to it, so if there are better already supported options that doesn't require a lot of overhead like ELF, then i'm willing to rewrite my bootloader.

I had not heard of that format so far, and I think it is not yet supported. But, having had a look at it, I quite like it. Pretty much the simplest multi-segment format you can think of. It would be very easy to add to vlink, so we will probably do that.

Quote:

also, how do you define "more standard syntax"? one thing i dislike about really old assemblers is how strict they can be with their formatting, like instructions have to be lowercase only, instructions always have to be atleast 1 whitespace character away from the start of a line, or you HAVE to use EQU instead of just =. just ancient limitations that IMO shouldn't exist in modern tools anymore. and ca65 gives you a lot of freedom in how you format your code.

vasm aims to be compatible to a large number of existing assemblers and provides a number of different syntax modules. The oldstyle syntax module that is usually used with 6502 will, for example, allow = as well as equ, and upper-case as well as lower-case. I think it requires instructions not to start at the beginning of a line, because it allows labels without semicolons. The std syntax module allows opcodes at the beginning of a line. You can have a look at the chapter on the different syntax modules in vasm.pdf and choose a suitable one.

[GARTHWILSON]

Proxy wrote:

as65? Do you mean ca65, the assembler cc65 ships with?

No; this is Andrew Jacobs' As65 assembler which has program-structure capability built in.  My impression, as I view them from a distance, is that As65 is far better than ca65.  Andrew died Jan 8, 2021, and Bill Chatfield ("gungwald") took over development, producing DEV65 (but it assembles for other µPs also).  It additionally supports relocatable code and multiple output formats.  It's available for download in a pre-built binary that is easy to install and run on any system with Java 1.6 or later.  Mike Naberezny later got nearly all of Andrew Jacobs' website restored and put here on 6502.org, with Andrew's daughter's permission.

[Proxy]

are you sure? I assumed it was a typo or similar because he mentioned ld65 (which doesn't exist in the dev65 kit) and also said "too bad there is no actual 65816 target for cc65, as it would slot perfectly into what I already have".

[tmr4]

GARTHWILSON wrote:

My impression, as I view them from a distance, is that As65 is far better than ca65.

A closer look might be worthwhile for those wanting more features, control and flexibility in their assembler. The downside? It will take longer to get up and running with ca65. I especially like that ca65 gives a lot more flexibility specifying a hardware configuration. I hated this when I started using ca65 because I came from an assembler more like As65. But now I wouldn't go back.

[jmthompson]

drogon wrote:

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?

I've actually had that thought, because I have a nostalgia for the Orca suite. I owned both the Pascal and C compilers back in the late 80s/early 90s and used them for my shareware projects. And since they were CLI tools they would (in theory) adapt well to running on Linux. Alas, I'm trying to not add new projects to my plate right now lest I may never finish jrcOS.

[jmthompson]

GARTHWILSON wrote:

Proxy wrote:

as65? Do you mean ca65, the assembler cc65 ships with?

No; this is Andrew Jacobs' As65 assembler

Nah he is right, I typo'd in my post and said as65 when I meant ca65. My project is based entirely around the cc65 suite of tools. It's just that in my mind "ca65" always becomes "as65" for some reason.

[jmthompson]

Proxy wrote:

as65? Do you mean ca65, the assembler cc65 ships with?

Yeah, I always mix up the name...

Proxy wrote:

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.

Specifically the direct page. And not so much tracking DB as (1) not understanding DP not being at $0000 and (2) inability to have more than one such segment. The latter in particular has made it challenging for me lately; I won't go into all the details here to avoid derailing the thread. It's nothing insurmountable; it just makes things a bit more complex than they'd otherwise need to be.

In retrospect my choice of words was a bit harsh. I actually really like ca65 and ld65 in general. It just has some rough edges.

[tmr4]

jmthompson wrote:

Specifically the direct page. And not so much tracking DB as (1) not understanding DP not being at $0000 and (2) inability to have more than one such segment.

Try specifying the run attribute with a start address of $0 for the DP segments that aren't located on the zero page.

[jmthompson]

tmr4 wrote:

jmthompson wrote:

Specifically the direct page. And not so much tracking DB as (1) not understanding DP not being at $0000 and (2) inability to have more than one such segment.

Try specifying the run attribute with a start address of $0 for the DP segments that aren't located on the zero page.

Hey, that seems to have done it! It throws warnings about BSS segments having run attributes, but it does link and the resulting code seems to work.