Announce: Acheron VM

Let's talk about anything related to the 6502 microprocessor.
User avatar
barrym95838
Posts: 2056
Joined: 30 Jun 2013
Location: Sacramento, CA, USA

Re: Announce: Acheron VM

Post by barrym95838 »

Garth and Bruce are quite familiar with the fig-FORTH bug, and Garth helped me to recognize my "17th bit" problem here with some failing test cases. Is that the type of data you're seeking?
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)
sark02
Posts: 241
Joined: 10 Nov 2015

Re: Announce: Acheron VM

Post by sark02 »

Hi White Flame,

Your presentation popped up in my youtube frontpage, so I just watched it last night. I have to say, very nice work! Some very smart and clever choices, and I like that you acknowledged the historical architectures that used some of the ideas (even if you learned of them after the fact, and so came up with them independently).

Have you investigated how well the VM might be applied to a 'C' compiler?
richard.broadhurst
Posts: 10
Joined: 20 Jan 2013

Re: Announce: Acheron VM

Post by richard.broadhurst »

I enjoyed the presentation; I was expecting a VM for a "known" 16 bit processor and was very pleasantly surprised.
I was also wondering about it being the target of a compiler, as I have tried a few times to write a Cish compiler for 6502, but always end up half inventing a new 6502ish language instead!
I'm from a (VIC-20 then) BBC Micro background which is 6502, unlike its later version the Master which is 65c02.
White Flame
Posts: 704
Joined: 24 Jul 2012

Re: Announce: Acheron VM

Post by White Flame »

The parameter passing/return scheme isn't really compatible with C's stack notions, which is the biggest issue. But a "mostly C-ish" language should be able to target it, using C syntax expressions and pointer operations, but a different function parameter model.

While a higher level language is obviously beneficial, the ability to create custom instructions is a good part of what keeps Acheron code fast, and that's more a low-level thing. Using an existing language like C would always require the system to do a bunch of extra stuff to maintain the C environment, which is always going to be a drawback on the 6502. I still haven't settled on what an optimal language on top of Acheron would be yet.
quincy451
Posts: 1
Joined: 20 Jun 2021

Re: Announce: Acheron VM

Post by quincy451 »

wanted to do some work with the ancheron VM...started with the basics...
makefile is given which uses ca65
but I am on windows.
gnu make installed.
cc65 installed.

I run make which would execute:
rm -r obj
rm -r bin
mkdir obj
mkdir bin
ca65 -l obj/acheron.o.lst src/acheron.asm -g -o obj/acheron.o -I src
ld65 -Ln bin/labels -C src/acheron.cfg -m obj/map -o bin/acheron.prg obj/acheron.o
# Display size information for each component. Only the above line is necessary for the build.
grep '^[^_]* Size=' obj/map
grep '\._size__' bin/labels
dir bin/acheron.prg

but at the ca65 step I get this:
rm -r obj
RemoveDirectory(C:\retro\6502\acheronvm-master\acheronvm-master\obj)
rm -r bin
RemoveDirectory(C:\retro\6502\acheronvm-master\acheronvm-master\bin)
mkdir obj
mkdir bin
ca65 -l obj/acheron.o.lst src/acheron.asm -g -o obj/acheron.o -I src
src/acheron.asm:38: Error: String constant expected
115 / 128 opcodes defined
make: *** [obj/acheron.o] Error 1

it's having a issue with this macro:
.macro reportSize label, filename
label:
.include filename
.ident (.concat("_size__", .string(label))) = * - name
.export .ident (.concat("_size__", .string(label)))
.endmacro


specifically the .include filename

Any ideas?
Post Reply