search

dschmenk / PLASMA

Proto Language AsSeMbler for All (formerly Apple)
MIT License
189 stars 26 forks source link

Porting to a New Target #9

Closed cr1901 closed 7 years ago

cr1901 commented 8 years ago

Very cool project. I plan to play around with PLASMA and see if it fits my needs in the coming days, but might as well ask now.

I have a 6502 FPGA impl that I'm looking to add a runtime to in the future. It's a custom design, so it wouldn't match any existing targets, Apple or otherwise. Will adding an assembly file under vmsrc for my custom target that implements the interpreter loop and the VM instructions be sufficient to port to a new board?

Looking over the source now, the main purpose of using ACME seems to be to emit bytes/opcodes that the PLASMA VM understands, also taking into account "inline" assembly, loading modules, and loading the program itself into memory for the VM; is this an accurate assessment? I will take some time to play with PLASMA hopefully sometime by next week.

dschmenk commented 8 years ago

Probably the biggest question is: what kind of storage do you support? Most of the PLASMA environment works by loading and executing modules.

There are two files to look at when porting to a new environment, the opcode interpreter and the command parser/system library. The simplest version to look at when supporting a new platform would be the Apple 1 code: src/vmsrc/plvm01.s and src/vmsrc/a1cmd.pla. If you have a basic 64K memory map, then almost nothing needs to be done for the byte code interpreter. The Apple 1 file I/O is very basic: it only reads and writes an entire file at a time. Porting the command parser should be just a matter of mapping the file I/O to whatever your platform supports and making sure the heap manager start at the top of RAM.

If you don't want a command parser and only want to load a single program, then replace the command parser with your program and link the byte code interpreter into it.

As for the build process, plasm, the PLASMA compiler, spits out assembly. The default is the cc65 format, but with the -AM flag it spits out acme formatted assembly. The assembler will then create the actual module file. I append some meta information after the module name which is used when transferring the file to the Apple ProDOS filesystem (the #FE1000 stuff).

cr1901 commented 8 years ago

Probably the biggest question is: what kind of storage do you support? Most of the PLASMA environment works by loading and executing modules.

Serial line, and 512kB RAMdisk (unfortunately) for now. A virtual COM port driver will halt the 6502 and load program to internal RAM using the serial line. RAMdisk is backing storage while power is applied. Will need to include a command to dump the RAMdisk contents to a file on my host computer, and load files via the serial line to a "file" on the RAMdisk. Perhaps I should ensure the upper part of the address space (the ROM) is loaded w/ FPGA configuration, which includes the command parser.

Basic 64k memory map w/ incomplete addr decoding (no bank switching); the onboard RAM is used solely as a RAMdisk.

dschmenk commented 8 years ago

In that case, you probably want to build stand-alone programs that link the VM right in. Just look at how the Apple 1 'a1cmd' gets built. You can replicate that process to build your programs.

cr1901 commented 8 years ago

Okay cool... works for me! What's the license for PLASMA? When I get to this point, do you mind if I pull in your code as a submodule, with minor changes to autogenerate the VM based on the created memory map? I love 6502 hardware, but I've found that I drag my feet when actually writing software; having a runtime to start with would make it easier for me to test/play!

dschmenk commented 8 years ago

Doh! Added: GPL. Enjoy.