Hi All,

(My first post, I think!)

I have a question that I thought might be best considered here, even though it's not strictly 6502 related *ahem*, but bear with me.

I'm using Brad R's excellent CamelForth/6809 that I have running on the Vectrex video game console, from 1982. My current project consists of salvaging a 6809 binary from a late 1970's FLEX disk and porting it onto the Vectrex. CamelForth/6809 comes with the 'Chromium' cross-compiler/assembler and I've started converting the FLEX binary, which I've disassembled, into CamelForth assembly.

First tests are good, the assembly works as expected, but then I hit a number of flag tests/branches and associated forward jumps, which the cross-assembler can't handle. Luckily, CamelForth assembler has IF, ELSE, THEN, etc. that in most cases I can substitute in.

But now I'm a bit further into the code, I'm hitting routines where the code flow jumps all over the place, e.g. out of BEGIN, UNTIL, loops, including using out of sequence IF, THEN,. Clearly, if the code was built using IF, THEN, etc. in the first place, I wouldn't be seeing this issue, but it wasn't and it looks like a laborious major restructuring to make it assemble with CamelForth.

My current thought is to abandon the attempt to convert to CamelForth assembly and use a regular assembler with the code as-is and attach the assembled binary to my Forth cross compiled binary and jump to the routines instead.

But before I do that, I thought I'd just ask around if anyone else had done something similar or had any further words of wisdom that might switch a light on.

Thanks for reading.

(And sorry it's not pure 6502. Actually, I have the idea to create a new cartridge for the Vectrex that would halt the 6809 and instead contain an '816 and a program ROM, which could then take over the system. People have already done it with an ARM, why not a '816?)

_________________
P*h*i*l*l*i*p EEaattoon in real life

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Oh wow, you're right, I'm not a newbie after all, although most of my posts were 16 years ago, I guess they slipped my mind!


I hesitated before posting that I was using a 6809 as this is really just a structured-assembly & Forth question and I knew structured-assembly was definitely on topic here, but I thought I'd just be transparent up front.

The '816 part is definitely real, though, as there are a lot of 6502 programmers out there and due to the 6809 not having the power to provide much in the way of on-the-fly animation, you need to pre-calculate animation vector lists and that quickly eats up the 48KiB of usable address space. The '816 expanded memory management could be a more elegant solution than is currently used.

So, my project...what I'm actually trying to do is port the first Sargon chess engine from the SWTPC 6809 to the Vectrex 6809. The custom user interface interface part I will strip out and initially I'll run the engine from the Forth interpreter via a terminal I have connected. Later, I'll create an interface for the vector monitor, using Forth.

I have an early non-working iteration of the 6809 code, but the actual working** binary code was updated quite a lot afterwards, but that later source code is lost, so I've disassembled the working binary to get something that resembles the source code and re-engineered it with the comments etc from the non-working early version.

**Actually it's mostly working, you can play a game on the SWTPC, but it doesn't make the same moves as the original Z80 real Sargon engine does, I need to fix that.


I do this with my CamelForth on the Vectrex, I call the BIOS ROM routines that allow me to draw on the screen, read the joystick, play music etc. via the 6522/AY38910/DAC, without having to write my own drivers.

One part I've already converted is this code below (almost assembles). The layout I'm not too sure about, but the problem is the MP15 branch half way down, it jumps out of a BEGIN, UNTIL, loop and that's going probably going to break an IF, THEN, compilation. The MP20 branch does the same thing again. I could probably fix this routine quite easily, either by restructuring the code or changing the Forth cross assembler to not use the same address variable for BEGIN, and IF, patching, but subsequent routines are much more complicated.

I guess I'm just batting round the pros and cons of Forth jumping to a separately assembled block of code as opposed to merging the assembly source with the Forth source, the latter being much neater and would mean I don't need to stitch the separate binary code together.

_________________
P*h*i*l*l*i*p EEaattoon in real life

It sounds to as if the problem is that the 'Chromium' cross-compiler/assembler allows only structured control flow -- IOW, it will accept IF, ELSE, ENDIF, in the source code but not BNE BEQ and so on.

I have dealt with a similar situation when using Bill Ragsdale's RPN assembler for 6502. It sometimes happen that I want to use conditionals in an unstructured way, and I accomplish this by adding snippets in the source code, snippets which cause the necessary bytes to output. For example, ...
D0 C, DESIRED_DESTINATION HERE 1+ - C,
... will cause a BNE opcode then its 8-bit offset to be assembled.

This is somewhat messy, but it lets me "break the rules" and bypass the compiler security checking which otherwise insists that IF pair with ENDIF and so on... and the code Phillip is trying to reproduce breaks the rules in the same way.

If you search on this forum for "compiler security" then you'll find there's another (arguably less messy) way, and that involves juggling items the assembler has on stack instead. Here is one post in that vein.

In Brad R's documentation, does he talk about bypassing compiler security checking?

Returning to my example, it's a backward branch which I assemble. DESIRED_DESTINATION is a constant created previously, of course. But it'll save memory if the associated address can simply be left on the stack.

This is not a complete description; for example I haven't addressed the question of forward branches. If necessary I will, but I'm hoping you will instead find the necessary answer in Brad's doc or in other posts on this forum.

Edit: missed your latest post while I was typing, Phillip.

If you tell me what is the destination of the MP15 branch half way down then I'll try to illustrate a solution.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Jeff, thanks for your thoughts.

So you have a similar problem with an 'engineering' workaround, glad I'm not alone. The Forth assembler will handle BEQ, etc, but it can't handle a forward reference as the target. In the listing I gave (I now added line numbers) the BEQ,/BNE, on lines 33 and 40 jump out of the BEGIN, UNTIL, to line 46. Similarly, the BCS on line 37 jumps right past the code snippet I've gave.

I hadn't thought to review the documentation of the assembler, I guess I should have a look, but I'm not expecting it to be accommodated, I think it stated somewhere that it's not supposed to be a full-blown assembler, it's for putting together speed-up routines for Forth purposes. For new code design, I think it's control structures would be quite beneficial.

Perhaps I should look into changing the assembler to be able to handle forward references cleanly.

I just looked in the manual for MPEs VFX forth and it too offers both IF, THEN, etc. and labels, including forward referenced ones, it even has an example showing the same code written with each method. It can also work in prefix and postfix modes - oh the luxury!

I'll also checkout the links you provided - thanks!

Phil

_________________
P*h*i*l*l*i*p EEaattoon in real life

Myself, I expect Brad will have something to say on the subject, so start your investigation here. The problem you're experiencing is fairly common, I suspect.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Since IF/THEN already handles forward branching, just rewrite the definitions and add them to the assembler.
Maybe something like this which allows for up to 3 forward branches that overlap:

: IF1 HERE 1- 0 ! ;
: IF2 HERE 1- 2 ! ;
: IF3 HERE 1- 4 ! ;
: THEN1 HERE 0 @ - 0 @ C! ;
: THEN2 HERE 2 @ - 2 @ C! ;
: THEN3 HERE 4 @ - 4 @ C! ;

The zero-page addresses 0,2,4 are locations that are free for use but can be made into variables instead if preferred.

Now the code becomes

Add these words to work with inline absolute code.

: IFABSL HERE 2- 0 ! ;
: IFABSH HERE 2- 2 ! ;
: THENABSL HERE 2- 0 @ ! ; \ absolute address points to lo-byte
: THENABSH HERE 1- 2 @ ! ; \ absolute address points to hi-byte




becomes

Thanks for your thoughts, guys.

I read the other threads mentioned and though Brad's assembler documentation and it's sparse, with nothing on forward references. In fact, the only reference I had seen was actually in the Camel Forth primitives declarations, where he uses HERE EQU <LABEL> to create backward references in few circumstances where structured programming might have been a bit verbose.

But I did come across this text below, regarding the Forth assembler, in one of Brad's papers:


So clearly, he wasn't a fan of labels and from what I can see of the source code, there's no specific functionality to accommodate them, but this does provide food for thought.

Now as I was thinking about this, I also came up with the idea of following a HERE EQU <LABEL> with a dummy C, address and then storing the target address using something like HERE <LABEL> C! (but with the subtraction to make it relative). I'm actually doing this a part of the regular CamelForth cross-compile, because the Vectrex has a hardcoded program start address, so I have to create a placeholder JMP address at that hardcoded address to then boot Forth and I backfill that placeholder when I know where it should JMP to.

And, now I see the suggested IF1, IF2, and IF3, as a less kludgy way of doing the same. It's not pretty, but it looks like it could do the job. I guess it would be something like the existing structured conditionals I found, but not using the stack for storage:

Now I need to do some more experiments - thanks again!

_________________
P*h*i*l*l*i*p EEaattoon in real life

After studying this some more, I realize that one may have to create quite a few IFx/THENx statements. The (MP15) at lines 40 and 43, requires there to be a another IF3/THEN3 and IF4/THEN4 to be created. Line #46 would then have THEN1 THEN3 THEN4

To me, this started looking like an array of addresses. I then came up with this to simplify things:

: ARRAY <BUILDS 2 * ALLOT DOES> 2 * + ;
6 ARRAY BRANCHES ( reserves 6 cells ) \ Branch #'s are 0-5 and this number can be easily adjusted to handle more cells
: IFBR ( n --- ) BRANCHES HERE 1- SWAP ! ; \ store address in array
: THENBR ( n --- ) BRANCHES @ DUP HERE SWAP - SWAP ! ; \ restore address, calculate branch offset and store offset

now the code becomes:

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thanks - I will consider this also!

_________________
P*h*i*l*l*i*p EEaattoon in real life

I've done an experiment and, roughly, I have a working proof of concept.

The following code (lots of commented out lines, as they don't assemble yet):

assembles to: (copied from the Vectrex "VIDE" emulator debugger, <<< lines added manually)


I've also just read through Garth's links and it looks like he's already done this almost exactly, with his clean label version!

However, just doing this PoC has brought to my attention that the CamelForth assembler doesn't produce a list file, so the only way to look at the code is via the debugger and that's a bit clunky and there are still no labels brought across. (I actually have a fix for that, but it's more work.)

Given the code I have is actually disassembled from a mostly working programme, I'm leaning towards a relative simple reassembly with a standalone assembler and call the binary code subroutines from Forth for debugging. I have other improvements to make in CamelForth, it doesn't have a CASE or ?DO words for starters, which is already fiddly. The whole point of this exercise is to make working Vectrex programs, improving Forth for Forth's sake is a secondary priority. (Though a lot of fun and Garth's clean labels solution is tempting ).

Also, converting between postfix and prefix and changing all branches to structures is bound to introduce bugs that will need extra testing and will still be messy because the code wasn't originally written with structure in mind.

Nonetheless, whichever way I go, this has been a super learning exercise, I really appreciate your input to the conversation.

_________________
P*h*i*l*l*i*p EEaattoon in real life