Jump to content
Lee Stewart

fbForth—TI Forth with File-based Block I/O [Post #1 UPDATED: 11/16/2019]

Recommended Posts

Hi Lee,

 

I just tried to run it in MESS, and as you said, seems to have some issues there. How is it supposed to start up, with a welcome screen or the like? It seems to have problems reading input at the prompt.

Share this post


Link to post
Share on other sites

Hi Lee,

 

I just tried to run it in MESS, and as you said, seems to have some issues there. How is it supposed to start up, with a welcome screen or the like? It seems to have problems reading input at the prompt.

 

Hi, Michael. Thanks for taking a look at it. The first thing it does after program preliminaries is to read the first four sectors (1st block) of FBLOCKS and LOAD it into the interpreter. That first loads the true lowercase character set from the first 2 sectors of FBCHARS and then presents the welcome screen with the instruction to "Type MENU for load options" before it stops at a blinking cursor to wait for input. The fact that it chokes on perfectly legitimate words after it stops with the '?' would appear to indicate that the program itself did not load properly. I'll have to do some TS soon.

 

...lee

Share this post


Link to post
Share on other sites

Hi Lee,

 

I just tried to run it in MESS, and as you said, seems to have some issues there. How is it supposed to start up, with a welcome screen or the like? It seems to have problems reading input at the prompt.

 

Michael et al....

 

The attached video shows how fbForth should start up. Until I get together a manual, you should consider the TI FORTH Manual-2ndEd(LES) along with fbForthReadme.txt in the uploaded package about 4 posts back as guides for using fbForth—along with any questions to me you might have, of course!

 

...lee

 

fbForth_v0.9_20130619.wmv

Share this post


Link to post
Share on other sites

Hi Lee,

 

I just tried to run it in MESS, and as you said, seems to have some issues there. How is it supposed to start up, with a welcome screen or the like? It seems to have problems reading input at the prompt.

 

Michael...

 

It looks like the problem is that it is indeed not handling the Level 2 SP 014h and 015h routines. Classic99, as I said, works fine in FIAD mode, but does not appear to be handling them, either, in the disk-image mode. I think I am going to have to start over with MESS because, once I get to the '?', I cannot get a line typed before it freezes up. One thing I removed from the executable was loading the lowercase (small caps) character set because that was happening with the block loads (which are not working in MESS) to get true LC, so it was redundant (except in this case! |:) ). Once you get to the '?'—which, by the way, is not a prompt, but rather a system 'WTF?'—type

 

HEX B00 834A ! 4A GPLLNK

 

This will load the lowercase character set from the system GROMs and make it possible to read the screen when LC characters appear. Type ABORT to see the "fbForth" line and then <enter> should get you the 'ok:n' with a blinking cursor on the next line. You should actually be able to use the system, but will not be able to do anything with blocks files until the I/O routines in question above are correctly implemented. I should probably back off of "correctly implemented" until I prove they actually work on the real iron. I'll get back to you on that.

 

...lee

Share this post


Link to post
Share on other sites

Well...I just tried it on my nanoPEB and I get nothing! :_( It spends several seconds loading the compressed object file, shows a blue screen with a blinking cursor and a '?' and absolutely no words are recognized. I even tried a regular uncompressed object file to no avail—it just took longer to load. It works as it should in Classic99 and Win994a. Right now, I have no clue how to troubleshoot this. :-o I would hate to have to go back to file-record I/O, which would require me to read 8 records of a file, one at a time, instead of 4 sectors of a file, all at once!—especially, when I'm not even sure that's the problem. Anybody have any ideas?

 

...lee

Share this post


Link to post
Share on other sites
It looks like the problem is that it is indeed not handling the Level 2 SP 014h and 015h routines. Classic99, as I said, works fine in FIAD mode, but does not appear to be handling them, either, in the disk-image mode.

 

Classic99 does support 14 in image mode (not 15, which is writing). I believe it works correctly, although I only did minimal testing myself. Perhaps it's worth setting a breakpoint right after the DSR call and just making sure the right data got into memory?

 

If it works in Classic99 with FIAD but not with DOAD, this could be a VDP memory layout issue... we can look at the differences between the startups with the Classic99 debugger - if you breakpoint at the same point in each boot, you can dump memory to see what's different.

 

Share this post


Link to post
Share on other sites

... If it works in Classic99 with FIAD but not with DOAD, this could be a VDP memory layout issue... we can look at the differences between the startups with the Classic99 debugger - if you breakpoint at the same point in each boot, you can dump memory to see what's different.

 

I guess I have a little work to do. We'll see whether sleeping on it does any good! :sleep:

 

...lee

Share this post


Link to post
Share on other sites

When I run under Classic99, I get different application behaviour depending on whether I run from the disk image or from the raw files.

 

The raw files startup like this after FBFORTH is loaded (I filtered out the TIFILES detection references, they are irrelevant here):

 

Information request on file FBLOCKS (Type >00, 252 Sectors, Records Per Sector 2, EOF Offset 0, Record Length 128, Number Records 504)
Reading drive 1 file FBLOCKS sector 0-3 to VDP 1000
Reading drive 1 file FBCHARS sector 0-3 to VDP 1000
Reading drive 1 file FBLOCKS sector 0-3 to VDP 1000

 

But the version on the disk image does this:

 

Information request on file FBLOCKS (Type >00, Records Per Sector 2, EOF Offset 0, Record Length 128, Number Records 504)
Reading drive 1 file FBMSGS sector 12-15 to VDP 1000
Reading out of range... aborting.

 

Ignoring that my debug message for information request is different in the two systems (that's a bad on my part ;) ), it's odd that the disk image version goes straight to FBMSGS after getting the information request on FBLOCKS, and that the FIAD version does not attempt to load FBMSGS at all.

 

As a test, I created a new disk image (180k to bypass the issues you had building a 90k disk to start), using the FIAD files. This failed in the same manner, so it does not seem that the program itself is damaged. To verify this theory, I also went the other way (copied the files from the disk image back to a new folder). Sure enough, all was well! So we can be pretty confident that the disk image and the program itself are intact.

 

I'll dig a little deeper.. I was going to do some TI work tonight anyway ;)

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Tursi Holmes... on the case again!!! Seriously... this guy is a freakin' mad man when it comes to debugging. =) Rest easy tonight, Lee.

 

***On a similar note, the debugger in Classic99 has caused me more "slap forehead" moments than anything else in my short TI career. The debugger does not lie. =)

Share this post


Link to post
Share on other sites

... I'll dig a little deeper.. I was going to do some TI work tonight anyway ;)

 

Wow! Thanks for all your work, Tursi. The way the initial file access should work is

  1. FBLOCKS is checked for file information.
  2. Sectors 0-3 of FBLOCKS are read and interpretation started.
  3. Partway into that interpretation, sectors 0-3 of FBCHARS are read.
  4. Sectors 0-3 of FBLOCKS are re-read and interpretation of those sectors is finished.

At this point, the only reason FBMSGS should be read is to get an error message. The "block # out of range" message is in sectors 12-15 of FBMSGS.

 

I'll get back to this later this morning. Thanks, again!

 

...lee

Share this post


Link to post
Share on other sites

Some apparent bugs in Classic99 were happening on the Image Disk side of things:

 

Bug 1 - Image disk Information Request did not return sector count (was returning 0 incorrectly - I believe incorrectly! FIAD had a big overhaul of the information request recently that got Archiver working correctly under Classic99...)

 

Bug 2 - SBRLnk code 0x14 was obviously never tested, cause it didn't work ;) It tried to get a cluster list from sector 0, which wasn't ever going to work.

 

Fixing those two issues made FBForth work from the disk image in Classic99. But that it does not work on hardware is troubling.

 

I will see if I can duplicate the hardware tests next...

 

Share this post


Link to post
Share on other sites

Just to confirm that it does fail as described on my hardware too - blue screen with a blinking cursor. I don't get the '?' on my real TI, although I see it under MESS. I can type words but it doesn't like them.

 

Unfortunately, I did not get any further tonight. I wanted to make sure it was not related to the CF7, and it took me some time to finally get the data transferred onto a 5.25" floppy. (But I had several adventures on the way that I'll share in another thread later).

 

I have fairly high confidence in Classic99's disk system these days being compatible with the TI disk controller, except in very few key points. One is memory usage - but since I update the RAM pointers this has not been an issue for a while, and there's no indication that FBForth is doing anything weird to VRAM. The other is the file information call, which FBForth is clearly making decisions on. My suggestion for the next test would be to make a small program that executes the same information request on FBLOCKS, and just dump the returned data to the screen. We should look and see if it differs (on the Classic99 side, test against FIAD until I get these other fixes out). Classic99 has clearly done something wrong here, and has probably led you down the wrong path, but if we can isolate what, it will hopefully be easy for you to fix your code. I would be surprised if it was much more than this.

 

 

 

Share this post


Link to post
Share on other sites

Wow! Thanks for all your work, Tursi. The way the initial file access should work is

  1. FBLOCKS is checked for file information.
     
  2. Sectors 0-3 of FBLOCKS are read and interpretation started.
     
  3. Partway into that interpretation, sectors 0-3 of FBCHARS are read.
     
  4. ---------> Sectors 0-3 of FBLOCKS are re-read and interpretation of those sectors is finished. <----------

At this point, the only reason FBMSGS should be read is to get an error message. The "block # out of range" message is in sectors 12-15 of FBMSGS.

 

I'll get back to this later this morning. Thanks, again!

 

...lee

 

Is that strictly true, Lee? I would expect sectors 0-3 (exactly one block) to be in a block buffer, so a round-trip out to the disk drive would not be necessary.

Share this post


Link to post
Share on other sites

If you want to do debugging in MESS, here are some tips. (I think I'll have to write that down somewhere.)

 

Start MESS with the option -debug. This will lauch a debugger window. The most important things to know are:

 

- F5: Run

- F11: Single step

 

There is a command line at the bottom right. Interesting commands are those for handling breakpoints.

 

- bpset <hexaddr>

- bpclear <bpnumber>

- bplist

 

When the execution reaches a breakpoint, it stops right there, after executing the line. You see the current workspace on the left.

 

You can open a memory dump window using the window menu or Ctrl-M. Note that earlier MESS versions had the issue that reading of GROMs or VDP was not blocked, so when you scrolled over these addresses, the emulated system would crash or react in some unforeseeable way. I fixed that in the latest release.

 

In the current case I would suggest to put a breakpoint at D01A, then enter Editor/Assembler and load and run FBFORTH. You can then continue setting more breakpoints and so on.

 

Michael

Share this post


Link to post
Share on other sites

...

4.
--------->
Sectors 0-3 of FBLOCKS are re-read and interpretation of those sectors is finished.
<----------

...

 

Is that strictly true, Lee? I would expect sectors 0-3 (exactly one block) to be in a block buffer, so a round-trip out to the disk drive would not be necessary.

 

Yes, because I am reading FBLOCKS, FBCHARS and FBMSGS all as blocks files, so I need to save the interpreter's place and EMPTY-BUFFERS in between switching files. Perhaps, I should change this, but that will increase code and complicate matters.

 

...lee

Share this post


Link to post
Share on other sites

Just to confirm that it does fail as described on my hardware too - blue screen with a blinking cursor. I don't get the '?' on my real TI, although I see it under MESS. I can type words but it doesn't like them.

 

Unfortunately, I did not get any further tonight. I wanted to make sure it was not related to the CF7, and it took me some time to finally get the data transferred onto a 5.25" floppy. (But I had several adventures on the way that I'll share in another thread later).

 

I have fairly high confidence in Classic99's disk system these days being compatible with the TI disk controller, except in very few key points. One is memory usage - but since I update the RAM pointers this has not been an issue for a while, and there's no indication that FBForth is doing anything weird to VRAM. The other is the file information call, which FBForth is clearly making decisions on. My suggestion for the next test would be to make a small program that executes the same information request on FBLOCKS, and just dump the returned data to the screen. We should look and see if it differs (on the Classic99 side, test against FIAD until I get these other fixes out). Classic99 has clearly done something wrong here, and has probably led you down the wrong path, but if we can isolate what, it will hopefully be easy for you to fix your code. I would be surprised if it was much more than this.

 

It looks as though the DSK-image version of SBR 014h is not reporting back the proper number of sectors in the file. The AIB still has 0 in that spot (AIB+2). I used the # of records ( AIB+8 ) to calculate the # of sectors and tried again. I think it got a little farther—at least I can now get the interpreter to accept core-dictionary words. It still chokes on reading any files. I will put back the loading of the small-caps character set from GROM for lowercase until we can figure out what I'm doing wrong. I will post that in a bit.

 

...lee

Share this post


Link to post
Share on other sites
It looks as though the DSK-image version of SBR 014h is not reporting back the proper number of sectors in the file. The AIB still has 0 in that spot (AIB+2). I used the # of records ( AIB+8 ) to calculate the # of sectors and tried again. I think it got a little farther—at least I can now get the interpreter to accept core-dictionary words. It still chokes on reading any files. I will put back the loading of the small-caps character set from GROM for lowercase until we can figure out what I'm doing wrong. I will post that in a bit.

 

I've already found and "fixed" that in Classic99 (see post #137 - there were two bugs that will prevent it from working at all) -- on my wip build, FBForth on a disk image works exactly the same as FBForth on FIAD files now. My concern is that hardware does not work the same way, so Classic99 is doing something wrong. If we can get the data returned from the information call on hardware, that will go a long ways towards proving whether it is correct. ;) Until I release the update, though, testing on Classic99's side will HAVE to be on the FIAD side.

 

Share this post


Link to post
Share on other sites

Yes, because I am reading FBLOCKS, FBCHARS and FBMSGS all as blocks files, so I need to save the interpreter's place and EMPTY-BUFFERS in between switching files. Perhaps, I should change this, but that will increase code and complicate matters.

 

...lee

 

Doh! I see - they are different files. Sorry. My bad! As you were, carry on :-)

Share this post


Link to post
Share on other sites

I am really at my wits' end! Manually setting up the call for file information (SBR 014h with access code=0) for both the nanoPEB and the CorComp disk controllers results in nonsense . When I did that in Classic99 in FIAD mode, it worked like a champ. It's as though those other controllers did not implement SBR 014h and 015h or they're trampling on my scratchpad storage locations—my AIB is 835Ch–8365h. I don't have a choice with the TB. That has to be 834Ch–8350h. Maybe I should move the AIB back a few bytes.

 

...lee

Share this post


Link to post
Share on other sites

WooHoo!! :grin: :-o I got it working on MESS and the real iron with my nanoPEB!!! I guess I'll need to await Tursi's fix to check it out on Classic99 with a DSK image. There were 2 changes necessary. Changing the AIB to 8320h and swapping the bytes of the number of records in the file before storing in AIB+8 did it. (The need for byte swapping is because the number of records in a file is recorded that way in the FDR.) I was lucky I had 8320h–832Dh free. I don't know what the DSR is doing to memory at ARG, but very little of the right information was making it there.

 

The corrected files are attached.

 

...lee

 

FBFORTH090_DSK002.zip

Share this post


Link to post
Share on other sites

WooHoo!! :grin: :-o I got it working on MESS and the real iron with my nanoPEB!!! I guess I'll need to await Tursi's fix to check it out on Classic99 with a DSK image. There were 2 changes necessary. Changing the AIB to 8320h and swapping the bytes of the number of records in the file before storing in AIB+8 did it. (The need for byte swapping is because the number of records in a file is recorded that way in the FDR.) I was lucky I had 8320h–832Dh free. I don't know what the DSR is doing to memory at ARG, but very little of the right information was making it there.

 

The corrected files are attached.

 

...lee

 

 

The HFDC Manual does a relatively good job of documenting the memory locations for the various level 1 and 2 routines. You may have been stomping on a few of the pointer words and bytes, such as 0x8350 (error return) and PAB setup by putting your AIB in the first ranges.

 

I usually place my AIB at 0x8300 and 0x8310 or thereabouts. If you intend to use hard drive devices, be sure you reserve sufficient AIB space to account for the extra bytes required.

 

If you are tight on space, saving then restoring the scratchpad used by the AIB bytes is a less desirable but workable option.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...