R/W in figforth

[powersoft_51]

Here my source file zipped.

[powersoft_51]

The assembly file zipped.

[BruceRMcF]

Note that in the original version 1 source I have, LIST calls .LINE which calls BLOCK, so the verification that the Block system is working independent of the SCR system -- that I suggested up the thread -- is one way to start to pin down where LIST is hanging.

Where that is shown as hanging is just where it would be calling .LINE which is therefore the first time it calls BLOCK.

Edit: Yes, looking at your assembly file, it's the same definition of .LINE and (.LINE) (see L2838), so that's halting just where BLOCK is being called.

[Dietrich]

Obviously there is an error in the program, which causes LIST to crash. Often such errors in 6502 systems occur due to misalignment a the code adress, which then is called by NEXT with a JMP (code). If this code adress is at $xxFF, the code misjumps and crashes. Thats a well known bug in all 6502 variants.
You needo check that after each modification, eg. after modifying u<. To do this I use a little tool:

Code: Select all

3 list
SCR # 3
  0 ( Compiler security check                 4.2.22 )
  1 hex
  2
  3 FB variable P
  4
  5 : CS  ( P ! ) context @ @
  6 cr ." Check Compiler Security " cr
  7 begin ( dup id. ) dup   pfa
  8   dup ( dup 0 d. ) 0FF and P @ =
  9   if dup 0 d. swap ID. cr else swap drop endif
 10   lfa @ dup 0=
 11 until
 12 drop ;
 13
 14 ;S
 15
ok
3 load ok
cs
Check Compiler Security
ok

The code checks the PFA being at $xxFB which translates to a JMP ($xxFF) in the NEXT code
If any of these are detcted you must insert an appropriate numper of fill bytes in you assembler code and recheck until everything is ok. Otherwise this error is difficult to find and pretty nightmarish to debug - why would I know that ...

Dietrich

[BruceRMcF]

Yes, is it an NMOS 6502 or a 65C02 in the target, and if emulated, is it set to simulate the 6502 or 65C02?

There are a handful of timing differences between the two, and some useful new opcodes, but not having the ($xxFF) bug is one of the bigger advantages of the 65C02 for fig-Forth.

Pinning down whether the crash is due to BLOCK being called or prior to BLOCK being called could also be used to help scan for a ($xxFF) bug problem in the listing of the assembled code.

[SamCoVT]

I loaded the provided asm file into the Kowalksi simulator with a 65C02 processor selected for simulation (to avoid any JMP ($xxFF) issues) and I/O starting at $F000 to match the code for INCH and OUTCH. I assembled the code in the Kowaslki simulator and ran it. I was able to verify the lockup still happens when running LOAD, even with 65C02 processor used in simulation.

In the asm file you provided, I see R/W (RSLW in the code) is calling DDISC, which is a word that is specific to the disc hardware in a specific machine (looks like a Rockwell System-65 based on the comments at the very top). That word JSRs to routines that do not exist, and this is why the simulation stops (you hit a BRK instruction). The first non-existent routine, which is the one that breaks things, is at $E1FE, and I believe you will see the PC has stopped at that value if you open the Registers and Status window in the simulator after it locks up.

You will need to modify R/W to do something different. Dietrich provided a version that uses an area of RAM instead. If you have actual hardware, you will need to modify it to use that (but then you won't be able to run that code in the Kowalski simulator, as it won't know how to simulate that hardware).