As I mentioned in my introduction post, I'm toying with a home built simulator and assembler and trying to get the FIG 6502 assembly listing going.

From the anecdotes I've seen here, it seems that the list is solid and that I shouldn't be second guessing it or looking for bugs in it per se.

I've already found several bugs in my simulator. My two recent ones were my INC instruction was actually DECrementing (bad), and my LDA (X, 1) instructions weren't as indirect as they should have been.

Throughout the debug process, I've been adding simple features to the simulator to aid me getting this up to speed.

Now, though, while the inevitable problem may well be with a bad instruction implementation, I'm running in a lot of high level Forth words.

I'm using the JSR TRACE feature and I've added to that the capability of dumping the parameter stack in my tracings. This looks really helpful.

My current problem is basically it's printing "? Msg #0" for pretty much anything I type after I hit enter. Whether its a blank line, a number or a forth word -- always that same thing.

I think the problem is within the NUMBER routine. But still not sure. The Forth is harder to debug at this level than the assembly is.

I guess Msg #0 is the "don't know what this is" error. Not sure on that either.

Anyway, figured I'd just chime in and let others know what my progress is.

Comments always welcome.

Did you mean to say LDA (1,X)?

_________________
x86? We ain't got no x86. We don't need no stinking x86!

Yoiks! That's pretty ambitious, I'd say -- you could be getting tripped up from a heckuva lot of different directions.


First I'd check to see if the machine makes it into the word INTERPRET. Assuming it does, the first operation there is to -FIND the delimited string you've input to the command line. -FIND calls (FIND) which is what does the actual dictionary search. Lots of scope for things to go wrong along the way... Try entering DUP or something you know ought to be found. IOW, don't worry about NUMBER right now.

Let us know how far you get. Do you have adequate Fig FORTH doc, BTW?

cheers,

Jeff

_________________
http://LaughtonElectronics.com

I maybe should've explained that INTERPRET first checks whether the input string is a Forth word -- that's what -FIND is for. Only if that fails does it attempt to treat the string as a number. Conclusion: NUMBER may or may not be broken, but if the machine can't find a known word like DUP or SWAP then something else has already gone wrong. My suggestion is to look for the first problem first.

On the plus side, we know most of your simulator is working properly, simply based on the fact you're able (I assume) to get the greeting upon program start, and that you have a command prompt and can type in a string and see your keystrokes echoed. That's saying a lot!

_________________
http://LaughtonElectronics.com

Oh yea, it's definitely getting that far.

the number '1' is a Forth word, so -FIND and (FIND) should find it. But that's clearly failing because as I understand it, FIND is tried first and if it fails, then NUMBER is tried.

I have some archive of a Fig doc, that seems to be missing Chapter 7. It's in some mostly plain text format, but there's obvious garbage at the start and end. But it's legible.

In Chap. 8, it describes the NUMBER code, and I can see exactly what code is failing.

From that document there's this excerpt;


That "is it a decimal point?" is where I'm getting the error message from. But clearly, that's not the issue -- in this case, it simply shouldn't even be here. So it's something else. That implies -FIND or (FIND).

It could be as simple as Forth seeing my LF (line feed, ascii 10) while it's looking for a CR. I found the one reference in EXPECT, perhaps there are others. It's not "configurable" like DEL/RUBOUT/BS is in a user variable(?, I think). No, nothing glaringly obvious at least.

Since (FIND) is machine code, that could easily be a bug in the simulator. It's clear that NEXT and friends is all working, or we wouldn't be this far. They work much better now that INC does the right thing lol.

But if it's in (FIND) I should have a decent chance of hunting it down, as I said, it's easier to debug machine code that Forth at this point.

MEM can't be greater than $7F00. The words that scan and add to the dictionary do signed comparisons with pointers.

Well, it's not the memory being too big, not yet at least, though I didn't know it had that limitation.

I'm in the process of trying to figure out (FIND). It runs for a bit before it exits, it's definitely looping through something. It's getting the CONTEXT value and the text that it's looking for looks good. I don't quite know the structure of the back end of the dictionary, so I'll have to decipher that so I can watch it click along to see what part of the scanning is failing, and why.

Myself, I've always found the linking of multiple vocabularies rather daunting to keep straight in my head. Luckily, in your current situation you're only concerned with one vocabulary -- and only one search path for (FIND) to traverse. So, don't be too concerned about the complexities of how (FIND) gets supplied with the first address in its search path. Just check that, once begun, (FIND) is moving from link to link, backwards through the dictionary.
You could note some of the addresses it's looping through and see if it makes sense on the assembly source listing. According to my Fig listing (I expect yours is the same; it's available on this site), the highest word in memory is MON which links back to VLIST which links back to TRIAD then INDEX then LIST and so on. Sooner or later the chain reaches DUP and SWAP and all our familiar favorites, so if you typed in DUP for instance and (FIND) can't find it then you know there's a problem. Happy hunting!

Jeff

_________________
http://LaughtonElectronics.com

Figured the hot tip was just to try MON since it should succeed immediately.

It took me a little while to grok what was going on with the EORs to facilitate comparison, an idiom I was not accustom to.

In the end, though, it worked well since I just had a few instructions to work through. As it turned out my AND instruction was setting flags based on the operand, but not the result -- oops. Amazing it got as far as it did.

So, it's finding words now. My new issue is: "1 1 + ." prints zero. Stack looks good, so it's probably in the number formatting routines somewhere.

But progress is progress.

Well, not that amazing, really. Bugs related to setting flags could be very subtle, and go unnoticed for a very long time indeed! So, if your goal is to thoroughly debug your 6502 emulator, really the best bet is not Forth but a test program written to specifically and exhaustively test 6502 function. If you post in the Emulation and Simulation section of the forum I'm sure someone can suggest such a program.

But perhaps you prefer to fix the emulator piecemeal, and learn about Forth at the same time. Here's a bit of code that may prove helpful:
Type this in at the command line (followed by CR) just to test that the Forth compiler works. You can omit the comment, of course. Later when you execute COMPTEST it should wait for a keystroke then echo it. If the compiler seems OK...

HEX. lets you print out a number from stack (in hex only). It doesn't use Forth's pre-existing numeric output routines, and therefore could prove extremely handy as a tool for debugging said routines!

Just for starters, try "1 1 + HEX." instead. If that fails, you could fall back to testing "1 1 + HEXDIGIT." or simply "1 HEXDIGIT.".

-- Jeff

_________________
http://LaughtonElectronics.com

Hi, cjb. MEM is not listed in my (6502) edition of the Fig glossary, so I drew a blank on what you could be referring to. Then I remembered something about 68000 Fig Forth. Page 2 of the 68K Fig assembly listing says

So it's not an issue affecting 6502. Is this what you were talking about, or is there something else? Cheers,

Jeff

_________________
http://LaughtonElectronics.com

Yea I've thought about a more exhaustive test. Struggling this way via getting Forth running is more interesting . Learned some interesting stuff debugging (FIND).


The compiler is (appears to be) good. It seems to be something else. For example, just entering a number (say 123) is causing issues. So I'm going to dig in to NUMBER, and see what's what. Detail is that I seem to be mostly in high level Forth right now, which seems to pretty much work, rather than low level assembly (which is obviously questionable).

I modified the JSR TRACE routine to show word nesting, as well as to dump the current parameter stack - that makes it MUCH easier to follow along to see what's going on. It appears I have some problem in U*, but I'm still working on that one. I was suspecting ROL for a bit but that seems ok so far.

I was referring to the parameter set in the fig-forth assembler source:
I was seeing the same problem as the OP when I had MEM much higher in memory, something that I'd been tracing the problems it caused for 2 straight days-- but then it struck me, and seconds later, everything worked!

LOL! I understand completely!
Well, all words eventually nest down to assembly, so we know if the assembly is buggy then all bets are off in regard to any high level Forth. And since the Forth compiler is itself written in Forth, you need to be on guard for compiler bugs too.

Sounds good. I'm sure you realize numeric input and numeric output are two different sections of code, and that both get invoked if you were to enter something like "123 .". Right now numeric input & output might both be buggy. So if (for test purposes) you want to bypass numeric input, KEY and constants like 1 (value 1) and BL (value 20h) can put a known value on stack. If you want to to bypass numeric output, you could use something like HEX. (in my last post).

Speaking of numbers, you'll eventually want to take action regarding Garth's warning about the U* aka UM* multiplication bug if you haven't already. But no rush -- this bug is rarely the source of any trouble, and likely isn't to blame for any obvious problems presently on your plate.

-- Jeff

PS- I notice 6502.org has a copy of the Fig Forth 6502 assembly source under Monitors, Assemblers, and Interpreters, here. This version does include the U* bug.

_________________
http://LaughtonElectronics.com

Thanks, cjb. That clarifies MEM for me, but somehow I'm still drawing a blank on the overall issue.

Heck, it's been ages since I mucked with Fig Forth but I used to understand the words that scan and add to the dictionary! CREATE is the main one for adding to the dictionary, and looking back I see it uses unsigned U< to trigger the "dictionary full" error. Looking at (FIND) and -FIND nothing jumps out at me. Also I searched the assembly source to find code that uses < > and 0< (which do signed comparisons) and once again noticed nothing suspicious. What am I missing?

Cheers,

Jeff

_________________
http://LaughtonElectronics.com