whartung:
Thanks for your source and assembled binary. I got it to run in my py65 implementation using the standard 6502 model that Mike put together, and my M65C02A model, after making a correction to my M65C02A model ADC/SBC instruction N flag process. The N flag was only being set correctly for its 16-bit mode. My 8-bit figForth implementation works in both the 65C02 and M65C02A models. My M65C02A (8/16-bit) figForth port still emits the sign on message, but nothing else.
Your earlier response caused me to find and check several other fig Forth 1.0 listings. They all had LESS implemented in exactly the same way, with the same comment in its header. "Altered from the model". That got me to consider that I had a problem with the processor model itself, which as it turned out, was a correct assumption. After correcting that error with the ADC/SBC N flag for 8-bit operations, and putting TRAVERSE back to its original configuration, I was able to run my 8-bit figForth implementation in both the py65 65C02 and my M65C02A model.
For tracing Forth, I've added a trace out consisting of the registers and the return and parameter stack to the jmp (abs) instruction in my model. To do the same for my 8/16-bit port, I will have to modify nxt instruction to provide the same tracing capability. With tracing of the Forth instructions, I should be able to locate the errors in my M65C02A figForth port.
Once again, thanks for your help.
Help on fig-FORTH 1.0 Bring Up
Re: Help on fig-FORTH 1.0 Bring Up
Michael A.
Re: Help on fig-FORTH 1.0 Bring Up
MichaelM wrote:
Thanks for your source and assembled binary. I got it to run in my py65 implementation using the standard 6502 model that Mike put together, and my M65C02A model, after making a correction to my M65C02A model ADC/SBC instruction N flag process. The N flag was only being set correctly for its 16-bit mode. My 8-bit figForth implementation works in both the 65C02 and M65C02A models. My M65C02A (8/16-bit) figForth port still emits the sign on message, but nothing else.
In my case, I was debugging the CPU simulator, the assembler for that simulator, and the FIG Forth all at the same time. It's good times when you can't trust anything
.Re: Help on fig-FORTH 1.0 Bring Up
whartung wrote:
I would check to make sure the basics work, notably entering numbers, "." to print the top of stack, things like that.
Quote:
Debugging Forth can be quite challenging if the fundamentals don't work, as you're in the mix of high level and low level code.
I would not blithely be changing constants in the code as is without a firm foundation as to why they are the way they are. There are a lot of assumptions in the raw FIG source code. The code DOES work. The bugs that are in the original FIG source are edge cases, rather than with the fundamental model.
I would not blithely be changing constants in the code as is without a firm foundation as to why they are the way they are. There are a lot of assumptions in the raw FIG source code. The code DOES work. The bugs that are in the original FIG source are edge cases, rather than with the fundamental model.
.Re: Help on fig-FORTH 1.0 Bring Up
I also check the depth with DEPTH . . The data stack depth should be zero when your Forth first boots.
I then type an undefined word ( random keys and a carriage return ) to see if the error handling works. I also type HEX HERE . to see if the size is what I expected.
I then type an undefined word ( random keys and a carriage return ) to see if the error handling works. I also type HEX HERE . to see if the size is what I expected.
Re: Help on fig-FORTH 1.0 Bring Up
Thanks for the pointers and encouragement.
I'm tracking it down, but I suspect I'm behaving a bit like Elmer hunting that wascally Wabbit.
There are a number of elements of my system that are not fully debugged, including the processor model itself. I have run unit tests for all of the implicit addressing modes, and successfully executed by Pascal compiler's Sieve of Eratosthenes program.
Some of the issues that I've found are related to the extensions that I've put into the model to support base pointer (X) relative and stack pointer relative addressing modes. Specifically, base pointer relative addressing requires negative offsets to access local variables and positive offsets to access the function/procedure parameters. Unfortunately, my initial concept, which sign-extends the first address operand, will not work as I had imagined. So I've had to back out that feature from my processor model. As I've been doing that, the behavior of figForth is improving.
I know that for my M65C02A 8/16-bit implementation up to QUERY everything appears to be working like the 8-bit implementation on the same processor model. Therefore, what I have to understand are the differences in behavior between some of the 16-bit extension to 8-bit zp instructions. It is a slow slog, and once completed, I'll go back to focusing on generating the remaining unit tests for the processor model.
On the way in to work this morning, I came up with a solution to my base pointer relative problem, and I'll have to incorporate that into the processor model and the Verilog code. This deviation into py65 and the M65C02A processor model will pay off. I am able to set up the processor model as I need it to behave, and to test its behavior with the Pascal, Forth, assembler, and Python unit tests far faster than in the iSIM FPAG simulation environment.
I'm tracking it down, but I suspect I'm behaving a bit like Elmer hunting that wascally Wabbit.
There are a number of elements of my system that are not fully debugged, including the processor model itself. I have run unit tests for all of the implicit addressing modes, and successfully executed by Pascal compiler's Sieve of Eratosthenes program.
Some of the issues that I've found are related to the extensions that I've put into the model to support base pointer (X) relative and stack pointer relative addressing modes. Specifically, base pointer relative addressing requires negative offsets to access local variables and positive offsets to access the function/procedure parameters. Unfortunately, my initial concept, which sign-extends the first address operand, will not work as I had imagined. So I've had to back out that feature from my processor model. As I've been doing that, the behavior of figForth is improving.
I know that for my M65C02A 8/16-bit implementation up to QUERY everything appears to be working like the 8-bit implementation on the same processor model. Therefore, what I have to understand are the differences in behavior between some of the 16-bit extension to 8-bit zp instructions. It is a slow slog, and once completed, I'll go back to focusing on generating the remaining unit tests for the processor model.
On the way in to work this morning, I came up with a solution to my base pointer relative problem, and I'll have to incorporate that into the processor model and the Verilog code. This deviation into py65 and the M65C02A processor model will pay off. I am able to set up the processor model as I need it to behave, and to test its behavior with the Pascal, Forth, assembler, and Python unit tests far faster than in the iSIM FPAG simulation environment.
Michael A.
Re: Help on fig-FORTH 1.0 Bring Up
I am sure that you've been waiting for my next update with bated breath , but I can report that the 16-bit version of my figForth project has successfully executed the VLIST command.
With NEXT being implemented as a processor instruction, Y is not put back to 0 as it is in the 8-bit version's figForth. Therefore, the problem with the 16-bit version's ability to INTERPRET the output of the QUERY command lay in the ENCLOSE function. That function was using the contents of Y on entry to clear the upper half of a number of values being computed on the PS.
Setting the Y register to 0 in the ENCLOSE function has allowed the 16-bit version to correctly execute the VLIST command. Furthermore, I have been able to execute some immediate commands from the command line like "10 10 + ." and "10 10 - .". These commands are correctly interpreted as 20 and 0.
However, although the * (multiply) routine is the same between the two versions, the commands "10 10 * 10 * ." or "10 10 * ." both yield incorrect results. Back to looking for instruction or Y register initialization errors. It is good that the 16-bit figForth implementation is now interpreting and executing immediate commands from the py65 console.
, but I can report that the 16-bit version of my figForth project has successfully executed the VLIST command.With NEXT being implemented as a processor instruction, Y is not put back to 0 as it is in the 8-bit version's figForth. Therefore, the problem with the 16-bit version's ability to INTERPRET the output of the QUERY command lay in the ENCLOSE function. That function was using the contents of Y on entry to clear the upper half of a number of values being computed on the PS.
Setting the Y register to 0 in the ENCLOSE function has allowed the 16-bit version to correctly execute the VLIST command. Furthermore, I have been able to execute some immediate commands from the command line like "10 10 + ." and "10 10 - .". These commands are correctly interpreted as 20 and 0.
However, although the * (multiply) routine is the same between the two versions, the commands "10 10 * 10 * ." or "10 10 * ." both yield incorrect results. Back to looking for instruction or Y register initialization errors. It is good that the 16-bit figForth implementation is now interpreting and executing immediate commands from the py65 console.
Michael A.
Re: Help on fig-FORTH 1.0 Bring Up
Just checking, Michael... but you haven't forgotten this, have you? UM* (multiplication) bug in common 6502 Forths
In FIG Forth, * calls U* (which is the FIG name for UM* ). And U* is buggy, as Garth described. The bug is fixed in the Forth source code but not in the assembly language source file. That said, I suspect that, even with the bug, 10 10 * . would probably work correctly. So, maybe the problem lies elsewhere. Does 100 . work?
Yup -- back in the 20th century, I, too, had to tweak FIG Forth, since my KK Computer also implements NEXT as a processor instruction.
-- Jeff
In FIG Forth, * calls U* (which is the FIG name for UM* ). And U* is buggy, as Garth described. The bug is fixed in the Forth source code but not in the assembly language source file. That said, I suspect that, even with the bug, 10 10 * . would probably work correctly. So, maybe the problem lies elsewhere. Does 100 . work?
MichaelM wrote:
With NEXT being implemented as a processor instruction, Y is not put back to 0 as it is in the 8-bit version's figForth. Therefore, the problem with the [...] function was using the contents of Y on entry to clear the upper half of a number of values [...].
-- Jeff
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html
https://laughtonelectronics.com/Arcana/ ... mmary.html
Re: Help on fig-FORTH 1.0 Bring Up
Dr Jefyll wrote:
Just checking, Michael... but you haven't forgotten this, have you? UM* (multiplication) bug in common 6502 Forths
Re: Help on fig-FORTH 1.0 Bring Up
I have the updated source in my figForth file. Both the 8-bit and 16-bit versions have the exact same source. At the 8-bit version of the figForth runs just fine in py65's 65C02 model and the M65C02A model. The problem probably lies in one of the primitives that I've modified to take advantage of the 16-bit operations of the M65C02A processor model.
My 8-bit figForth (using the M65C02A processor) uses some 65C02 instructions and that's why it doesn't run with the py65 6502 processor model. whartung's figForth binary runs unmodified in my py65 environment if I change to the 6502 processor model. I did not run it with the py65 65C02 model, but I did run it with my M65C02A model, and it ran just fine with my processor model.
By the time we get to INTERPRET, most of the primitives have been exercised, but I am sure that there a few which have not been used yet. One of those primitives is probably assuming that Y is 0 on entry. I have to find those primitives and add the code to initialize Y to zero.
I've had to fix this issue once before when I previously got figForth to run on my M65C02 development and my Chameleon Arduino form-factor board. So I was expecting to have to do some of this type of bug fixing. The hardest ones to find and correct have been those associated with the sign-extension of the zp address byte. But since I am not all familiar with Forth, or the figForth model, finding the errors in my processor, my assembler, and the ported FigForth code has just been a hard slog.
Certainly glad that I unit tested all of the implicit addressing mode instructions. Some of the issues I've found have been processor model based, but I've yet to find a problem with any of the instructions that I've previously unit tested.
My 8-bit figForth (using the M65C02A processor) uses some 65C02 instructions and that's why it doesn't run with the py65 6502 processor model. whartung's figForth binary runs unmodified in my py65 environment if I change to the 6502 processor model. I did not run it with the py65 65C02 model, but I did run it with my M65C02A model, and it ran just fine with my processor model.
By the time we get to INTERPRET, most of the primitives have been exercised, but I am sure that there a few which have not been used yet. One of those primitives is probably assuming that Y is 0 on entry. I have to find those primitives and add the code to initialize Y to zero.
I've had to fix this issue once before when I previously got figForth to run on my M65C02 development and my Chameleon Arduino form-factor board. So I was expecting to have to do some of this type of bug fixing. The hardest ones to find and correct have been those associated with the sign-extension of the zp address byte. But since I am not all familiar with Forth, or the figForth model, finding the errors in my processor, my assembler, and the ported FigForth code has just been a hard slog.
Certainly glad that I unit tested all of the implicit addressing mode instructions. Some of the issues I've found have been processor model based, but I've yet to find a problem with any of the instructions that I've previously unit tested.
Michael A.
Re: Help on fig-FORTH 1.0 Bring Up
MichaelM wrote:
Certainly glad that I unit tested all of the implicit addressing mode instructions. Some of the issues I've found have been processor model based, but I've yet to find a problem with any of the instructions that I've previously unit tested.
There's a lot of code that run the "happy path" through the processor and simply never execute some things.
Then there's the developer do just flat out wrong things. For example, in mine, I found that I hand the instructions TAX and TAY EXCHANGE the registers, (A = X, X = A) rather than just one way.
Oops.
That's fun to isolate.
I also noticed on mine as I'm going through it to make a 65816 version, that my BIT instruction is wrong. BIT works differently in IMMEDIATE mode. In IMMEDIATE mode it only sets the Z flag, vs the N and V flags in the other addressing modes.
That 6502 vetting suite (Klaus's? I think?) apparently does not check that -- as I know my system passed that suite. (Maybe it does check it today.)
All I can say is I'm glad no-one is using my simulator to run aircraft or medical radiation equipment.
Re: Help on fig-FORTH 1.0 Bring Up
Quick update. The multiply function STAR is not the issue. It yields the correct results when tested in a standalone manner. I am looking at the next function, DOT, now. It appears to blow up, filling the stack with a lot of zero entries.
(The old figForth multiplication and division routines have long been ripped and replaced by the 6502.org recommended updates.)
(The old figForth multiplication and division routines have long been ripped and replaced by the 6502.org recommended updates.)
Michael A.
Re: Help on fig-FORTH 1.0 Bring Up
Well it's been a couple of days since the last update. Yesterday I got the interpreter to work. I found that the initial port of the U/ function (the updated version) was giving the incorrect results. So I backed up, and re-ported it. That appeared to correct those errors with the interpretation of immediate mode commands.
However, compiling a simple colon definition failed. So back into the debug mode. This morning, after slogging through a comparison of traces of the 8-bit fig6502a and the 16-bit fig6502b implementations, I finally located the place where the compile mode of the 16-bit implementation failed.
Again it turned out to be a PyAsm65 issue. The parser function, a set of nested regular expressions, failed to recognize the syntax for a zero-page indirect instruction, and generated a zero-page direct instruction instead. The result being that the name length byte returned by (FIND) was incorrect. I updated the parser, and the 16-bit implementation now works as expected.
Will have to review the PyAsm65 parser in greater detail and come up with some tests to verify that it correctly recognizes the 49 total (16 standard and 33 extended) addressing modes supported by the M65C02A. Even with all of these problems, I am still pleased with the progress I've recently made with this project. The figForth source really stretched the assembler compared to the source from the Pascal compiler. I suppose that should have been expected since the figForth source relies on some optimized assembler for much of its runtime code; the Pascal compiler uses only a very limited number of instructions and addressing modes.
However, compiling a simple colon definition failed. So back into the debug mode. This morning, after slogging through a comparison of traces of the 8-bit fig6502a and the 16-bit fig6502b implementations, I finally located the place where the compile mode of the 16-bit implementation failed.
Again it turned out to be a PyAsm65 issue. The parser function, a set of nested regular expressions, failed to recognize the syntax for a zero-page indirect instruction, and generated a zero-page direct instruction instead. The result being that the name length byte returned by (FIND) was incorrect. I updated the parser, and the 16-bit implementation now works as expected.
Will have to review the PyAsm65 parser in greater detail and come up with some tests to verify that it correctly recognizes the 49 total (16 standard and 33 extended) addressing modes supported by the M65C02A. Even with all of these problems, I am still pleased with the progress I've recently made with this project. The figForth source really stretched the assembler compared to the source from the Pascal compiler. I suppose that should have been expected since the figForth source relies on some optimized assembler for much of its runtime code; the Pascal compiler uses only a very limited number of instructions and addressing modes.
Code: Select all
morrisma@toshiba:~/Development/PProjects/Py65MAM/py65$ python3 monitor.py
Py65 Monitor
PC AC XR YR SP VM NVMBDIZC
M65C02A: 0200 0000 0000 0000 01FF 0000 00110000
0000 0000 0000 01FF 0000 DFLYXSIZ
0000 0000 0000 00000000
.cd ../../PyAsm65/figForth
/home/morrisma/Development/PProjects/PyAsm65/figForth
PC AC XR YR SP VM NVMBDIZC
M65C02A: 0200 0000 0000 0000 01FF 0000 00110000
0000 0000 0000 01FF 0000 DFLYXSIZ
0000 0000 0000 00000000
.load fig6502b.bin 400
Wrote +5737 bytes from $0400 to $1A68
PC AC XR YR SP VM NVMBDIZC
M65C02A: 0200 0000 0000 0000 01FF 0000 00110000
0000 0000 0000 01FF 0000 DFLYXSIZ
0000 0000 0000 00000000
.g 400
fig-FORTH 1.0b
: star 42 emit ; OK
: stars 0 do star loop ; OK
: margin cr 30 spaces ; OK
: blip margin star ; OK
: bar margin 5 stars ; OK
: f bar blip bar blip blip cr ; OK
f
*****
*
*****
*
*
OK
mon
PC AC XR YR SP VM NVMBDIZC
M65C02A: 1A65 1A63 009D 0002 01FF 11EF 00110001
005F 0103 1AEE 01FF 1A63 DFLYXSIZ
005F 0000 0000 00000000
Michael A.
Re: Help on fig-FORTH 1.0 Bring Up
That's great - and thanks for showing the transcript. I think it helps show how useful it is to have an emulator, and how to use py65.
Re: Help on fig-FORTH 1.0 Bring Up
After digging deep into the innards of Tali Forth, I decided to understand how another Forth works. So I used my Python utility to convert the web site's Fig Forth source to the Ophis assembler format. I also added a Makefile to build it and run it on Py65Mon. So far so good.
It starts and begins tracing for quite a while, but then crashes. But I don't have a known good to compare the trace to.
Does anyone have the trace output from a Fig Forth that works?
FYI, here's the source I ported: https://github.com/Martin-H1/FigForth
It starts and begins tracing for quite a while, but then crashes. But I don't have a known good to compare the trace to.
Does anyone have the trace output from a Fig Forth that works?
FYI, here's the source I ported: https://github.com/Martin-H1/FigForth
Re: Help on fig-FORTH 1.0 Bring Up
Martin:
I will try and regenerate a trace for the 8-bit figFORTH implementation and post it here or on github, or PM it to you. I was just in the processor model looking at how I implemented the trace feature, and it looks like it will work. However, there a feature in my trace that I can't remember how it works.
It may be a day or two before I can get a trace run for you. I will be out of town for the next few days, but I will take the computer with me. If the opportunity arises, I'll work on tracing the 8-bit figFORTH implementation that I got to work. Otherwise, it may be sometime next week before I can get a trace for you.
I will try and regenerate a trace for the 8-bit figFORTH implementation and post it here or on github, or PM it to you. I was just in the processor model looking at how I implemented the trace feature, and it looks like it will work. However, there a feature in my trace that I can't remember how it works.
It may be a day or two before I can get a trace run for you. I will be out of town for the next few days, but I will take the computer with me. If the opportunity arises, I'll work on tracing the 8-bit figFORTH implementation that I got to work. Otherwise, it may be sometime next week before I can get a trace for you.
Michael A.