D-Type

That looks like a very usable compilation, faster than my CamelForth 6809, though I do have 100+ extra BIOS interface words in the dictionary. I have an end of line delay inserted to get a reliable compile over serial. I have no optimisations yet for the dictionary, because I don't code on the target, only debug, but I have looked into removing headers and replacing with a minimal perfect hash for the pre-compiled dictionary words, which could make compilation a magnitude quicker. I reckon the hashes would take up less space than the headers, I don't have SEE and don't really have need for it, so hashed names would work fine. The gotcha then is how do you know if the word you're using interactively is in the dictionary? You don't, but I don't think that's a big issue and I figure you could make a recognizer that would override the dictionary search, maybe an underscore at the start of the word for all hashed words, it is only for interactive use, after all. Alternatively, there are techniques for storing a dictionary in the lowest number of characters, but then you're back to using more ROM space and slowing things down again. Always compromises!

Ha! Not only does the Vectrex have no available IRQ lines to use, it also has 1k of RAM, some of which is used by the BIOS, so adding ring buffers to the stack, pad etc. wouldn't leave you with much dictionary space, there's only ~#750 bytes as it is, from memory. Thus cheating is permissable! 🙂 Here are my Forth and equivalent assembly I/O words (pics).

Great achievement! It's been 25+ years since I programmed ring buffers. For my Vectrex running CamelForth 6809 I used a UM245R, which connects to USB, has built-in Tx/Rx buffers and a Data Available signal that the CPU polls via a 6522 VIA. The KEY, KEY? and EMIT code words are just half a dozen instructions and it can DUMP the full 64K address space to TeraTerm in a couple of seconds. In fact it's so fast that the 1.5MHz 6809 can't actually overflow the buffer!

Possibly a power switch issue. It's not a standard power switch, it switches two separate power lines /after/ the transformer and sometimes one of them has a bad contact initially, which usually shows up as a monitor not switching on for a few minutes or more. Try leaving the Vectrex unit switched on and then power it off at the wall socket for a few hours or overnight.

https://atari.com/pages/atari-x plus other pages in the help and FAQ section

Thanks for the offer. I work for a large financial institution that deals in commercial digital assets and utilizes distributed ledger tech. IMHO classic retro gaming has no need for things such as NFT to represent an asset, the physical hardware is the asset, and I'm not a collector anyway. Modern retro, well, not really my thing, if you can find use for crypto, go for it 🤷‍♂️

Then you should get that off your website ASAP. When I looked at your website and saw Token and blockchain everywhere, I was horrified. General people fear blockchain and crypto because they don't understand it and atari.com doesn't do a very good job of explaining what it is or why it's beneficial to anyone who would be browsing the website.

The original 1990's source is at CamelForth.com, but I suggest having a look at the below link, where the source code has been converted to run under Gforth using plain text files instead of blocks. Brad's original ran on an obscure 6809 computer, mine is running on real and emulated Vectrex video game console. (The original is also stored in the same Github repo, my commit history takes it from Brad's original to what it is today.) VecForth/include.fs at master · phillipeaton/VecForth (github.com)

Brad R's CamelForth 6809's Chromium Cross Compiler was the main reason I got back into Forth, it was a hobbyist version of what I'd used professionally in the 90s (MPE Z80 x-compilers). Brad's version is mostly implemented and hides all the e.g. TC. target stuff, but it doesn't easily let you use local words of the host PC forth when cross-compiling, you have to figure that out yourself. It's fuzzed my head for the past 5 years also, I had considered thinking to NOT use Forth as the language of the cross-compiler, use something else, but as I've got the hang of it, I'm liking the elegence again. Well done for getting yours working!

I asked this question on the PiTrex forum some time back, after some investigation I did regarding the various Pi versions out there. The PiZero is based on the same CPU as the original Pi, so there's a good chance that could be made to work, but you might still have to know what you're doing, software-wise, as well as having to sort out the physical differences.

https://scratch.mit.edu/projects/249324997/ And this is Graham Toal's Scratch version of the algorithm. Graham is one of the 6809 Vectrex community.

https://nbickford.wordpress.com/2011/04/03/the-minsky-circle-algorithm/ I think this might be Minsky's quick elipse algorithm. Worth a look?

Bernd Paysen's Mini-OOF I think is quite neat, I've never actually used it, but at least it's easy to understand as it's only one block of code: https://atariwiki.org/wiki/Wiki.jsp?page=Mini-OOF

: NEXT, Y ,++ [] JMP, ; \ 6809 DTC

No