D-Type
-
Posts
50 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Everything posted by 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
-
It's whatever you choose to provide, from binary only to full boxed edition with overlay, plastic box protector and other bells and whistles. @phoboz releases his games on a loose cart, I think they originally came with just a hand-written label (maybe they still do). Vectrex – Atari and Vectrex (tjocktv.se) AFAICT, he seems to have sold plenty because they're well done, fun to play and people talk favourably of them, I certainly enjoyed playing SpideX in the most recent Vector War X. And here's the thing...his games are on GitHub, you could download the code and make your own cart, so no wonder they're popular titles ?
-
Thanks for your explanations. I like this inline optimisation, because (I think) I can understand it! However, it looks to me that you can only inline code-primitives, loops and data words i.e. you couldn't put one of your own non-primative words in the loop. Am I right? On one hand, putting your own words in the loop would dilute the inline optimisation significantly anyway, but on the other hand, if you inlined primatives only, couldn't you could put it in a dedicated code word instead quite easily? Also, didn't you show an inliner some time back that did inline non-primatives, but not at the code level, at the reference level (using the CFA? Sorry, I'm no guru). IIRC, then I guess this is a different inliner? I'm always interested in ways of speeding up my CamelForth 6809 system, but have more learning to do first ?
-
Never touched the yoke on mine. I think there was some discussion about that on the "Vectrex fans unite" Facebook forum recently, try having a search around there?
-
I calibrated one of mine recently and I aligned everything with the middle of the three, when I did that, the top and bottom extended lines also lined up well also.
-
Hi Albert, I finally received my AtariVox, thanks for shipping, the package is very nice. I also had some initial issues getting it to work, due to the switch settings, but luckily I remembered a thread on the Facebook group that mentioned it. That thread mentions the switches are reversed, but it looks to me that the settings as shown in the manual I have are simply swapped between VecVox and VecVoice. Another thought, when you look in the manual at the switches, it's not obvious if the white square or the black square indicates where you put the switch. You can work it out from the photo in the manual that it's the black square, but that actual switches on the device are definitely white! Now, after hearing someone on the Facebook forum had some issues with their AtariVox, I gave mine a tryout on three different Vectrexes using Berzerk Ultimate/VecVox. - Two worked OK. - One didn't, you could make out parts of sentences initially, but the sentences became more broken after 5 or 10 seconds playing and then were not audible after maybe 20 to 25 seconds. A Vectrex power cycle restored it to partial working but then becoming broken again. I didn't test a Vectrex reset. I'd be interested to know if there is a solution to this.
-
Look great!
-
Thanks for the explanation. It all seems so simple, but I don't yet understand the inner workings enough to really judge ? 10 bytes doesn't really seem much of an overhead...does anyone care about memory usage these days? Maybe it's a problem on the '99, I know it has some strange architectural challenges, maybe that's one of them. I read also the Inlining thread, it wasn't how I remembered it, but it's food for thought for my own Vectrex future enhancements! Currently I'm working on interfacing the Vectrex BIOS routines from Forth i.e. creating an API. Nothing public yet, but I'll be putting v1 on Github eventually. It actually already is on Github, but Private.
-
What is the state of the art for '99 Forth cross compilers regarding macro inlining of small code words? I was thinking about how to improve the speed of my 6809 Vectrex/Camel Forth and came to a similar conclusion as this thread i.e. instead of rewriting the compiler as STC (not enough time, never going to happen) I could make it make it STC-ish by inclining code and reducing the call overhead. (I remembered the inlining thread that came after this one and searched for it, but first came across this thread - will reread the inlining thread next. Simple inlining was actually what I was thinking about using initially, but of course the mind wanders...)
-
Postpone still confuses me as I learned and used Forth 83 for 10 years in the 90s. From memory, Starting Forth print editions don't mention Postpone, only Compile. (But there is an ansi'fied web & pdf version which has text modified to describe Postpone instead, I think.) The definition of Compile is much easier to understand and it does what you expect, so I started with that, as it's used by Postpone. Honestly, learning Compile or Postpone on their own isn't enough, you need to learn about immediate and compile modes etc. together else none of it makes sense. Starting Forth covers it all over a few meaty chapters, but you might need to read and think about it several times before it sinks in. (At least I had to.) Maybe try the SF chapters in the first edition pdf that's on the web and understand Compile, then deal with about Postpone later on?
-
My serial port is provided by an ARM-based multicart that puts a UART into my address space and it gives me 921,600 baud with a 256 byte buffer both ways, which doesn't fill up. Thus the test is quite "clean"!
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord