Firing up a FIG-Forth

[whartung]

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.

[BigDumbDinosaur]

whartung wrote:

...and my LDA (X, 1) instructions weren't as indirect as they should have been.

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

[Dr Jefyll]

whartung wrote:

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.

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

Quote:

My current problem is basically it's printing "? Msg #0" for pretty much anything I type after I hit enter.

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

[Dr Jefyll]

Quote:

Whether its a blank line, a number or a forth word -- always that same thing

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!

[whartung]

Quote:

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.

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;

Code: Select all

BEGIN 			Start the conversion process
 	DPL ! 		Store the decimal point counter
 	(NUMBER) 		Convert one digit after another until an invalid char occurs.
 				Result is accumulated into d .
 	DUP C@ 		Fetch the invalid digit
 	BL - 			Is it a blank?
WHILE 			Not a blank, see if it is a decimal point
 	DUP C@ 		Get the digit again
 	2EH - 		Is it a decimal point?
 	0 ?ERROR 		Not a decimal point.  It is an illegal character for a number.
 				Issue an error message and quit.
 	0 			A decimal point was found.  Set DPL to 0 the next time.
REPEAT 			Exit here if a blank was detected.  Otherwise repeat the
 				conversion process.

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.

[cjb]

whartung wrote:

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.

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

[whartung]

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.

[Dr Jefyll]

Quote:

It's getting the CONTEXT value and the text that it's looking for looks good. I don't quite know the structure

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.

Quote:

it's definitely looping through something

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

[whartung]

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.

[Dr Jefyll]

whartung wrote:

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.

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:

Code: Select all

: COMPTEST  ( --- ) KEY EMIT ;

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...

Code: Select all

HEX
: HEXDIGIT. ( n --- ) F AND 30 +
                      DUP 39 > IF 7 + THEN EMIT ; ( isolates the ls nibble of n and outputs the ascii equivalent)

: 10h* ( n --- n*10h) DUP + DUP + DUP + DUP + ; ( shifts n 4 places to the left)

: HEX. ( n --- ) DUP 10h*  DUP 10h*  DUP 10h*
                 HEXDIGIT. HEXDIGIT. HEXDIGIT. HEXDIGIT. ; ( outputs the ascii equivalent of n)

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!

Quote:

My new issue is: "1 1 + ." prints zero.

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

[Dr Jefyll]

cjb wrote:

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

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

Quote:

16-bit addresses, standard in Fig-FORTH, are sign-extended automatically by the 68000 CPU so that 16-bit addresses in the range 8000-FFFF point the CPU to FFFF8000 - FFFFFFFF (i.e. highest 32K). Unfortunately, most systems do not have RAM available, decoded for this upper 32K. Unless your system does, this 68000 implementation will work only in the lowest 32K.

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

Jeff

[whartung]

Dr Jefyll wrote:

But perhaps you prefer to fix the emulator piecemeal, and learn about Forth at the same time.

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).

Quote:

If the compiler seems OK...

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.

[cjb]

Dr Jefyll wrote:

cjb wrote:

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

Hi, cjb. MEM is not listed in my (6502) edition of the Fig glossary

I was referring to the parameter set in the fig-forth assembler source:

Code: Select all

MEM       = $6E00               ;top of assigned memory+1 byte.
UAREA     = MEM-128             ;128 bytes of user area
DAREA     = UAREA-BMAG          ;disk buffer space.

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!

[Dr Jefyll]

whartung wrote:

Struggling this way via getting Forth running is more interesting

LOL! I understand completely!

Quote:

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).

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.

Quote:

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.

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.

[Dr Jefyll]

cjb wrote:

I was referring to the parameter set in the fig-forth assembler source

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

Quote:

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

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