6502.org

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?

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

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

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

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

Yes, I think that assembler uses a syntax more similar to that of vasm.
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.
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.

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.

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

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.

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.

Yeah, I always mix up the name...
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.

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.