fbForth fbForth—TI Forth with File-based Block I/O [Post #1 UPDATED: 06/05/2024]

+Lee Stewart · May 15, 2014

I need some advice regarding cartridge startup code. I think i can get away with a 32KB cartridge (4 banks). Do I need startup code in all 4 banks or just the first and last, i.e., do I need to expect it might start up in any of the 4 banks or can I rely on it's waking up in only the first or last bank?

...lee

+Ksarul · May 15, 2014

So far, we've only seen first or last bank, Lee. It isn't a 100% guarantee, but there are a lot of cart boards out there, and all of them so far (400+ in various flavors from 16K to 512K) follow that pattern.

Tursi · May 16, 2014

Note that that is only true on power cycle, however! If the user can reset at any time (via FCTN-QUIT or another method), the same bank as was active will still be active at the Master Title Page. I've used two techniques... in one, make sure you only allow QUIT from the startup bank (that is, switch before you check it or before you reboot yourself) - this covers all cases except if someone has a hardware reset switch. The other is to put the header in every bank, and just have the first instruction set the real startup bank (this way that's all you need on all the others). This covers all cases of reset.

+Lee Stewart · May 16, 2014

All fbForth words execute with bank 0 current, including MON (the only way fbForth can be quit); but, I obviously cannot control a manual reset switch. I think I will do as you suggest, @Tursi, and just put the header in every bank.

...lee

Tursi · May 16, 2014

It's a real edge case, mind you, the hardware reset switch. They are fairly uncommon.

That said, I like having one in my system

+Lee Stewart · May 21, 2014

I think I've painted myself into a corner with my "clever" usage of labels in ALC (see post #630 above) that will be copied from ROM to RAM! I'm not sure of the best way to fix it. The problem is with jump instructions. I made all labels EQUates that would make them point to their ultimate destinations. This does not work when the labels are jump targets because the code to be copied is originally in ROM space (>6000 – >7FFF), but gets copied to RAM space that is much farther away than 254 bytes ( the limit of the jump instructions).

It's not too big a problem if the labels are isolated to jump instructions; but, if the label is also a branch destination, I'm in trouble! I guess I will have to use 2 labels for that situation—unless someone has a better idea.

...lee

Tursi · May 21, 2014

Since jumps are relative, you should be able to code the jump and its target normally -- it won't matter that the code is copied as long as they remain the same number of bytes apart?

+Lee Stewart · May 21, 2014

Since jumps are relative, you should be able to code the jump and its target normally -- it won't matter that the code is copied as long as they remain the same number of bytes apart?

I agree. So far, it looks like the jump targets I am copying are NOT also branch targets from other code. At least, this puts me on alert for strange bugs later on, when I actually get around to testing the code.

...lee

+Lee Stewart · May 21, 2014

OK—I am nearly ready for the smoke test! I have the following amounts of memory available in banks 0 – 3:

Bank 0: 2610 bytes
- resident dictionary code and parameter fields
Bank 1: 3764 bytes
- all initialization code
- low RAM support code, inner interpreter code
- default font with true LC
- messages
- payload code for MESSAGE and 2 other words
Bank 2: 3468 bytes
- dictionary headers
- payload code for all words that search the dicitonary headers
  - ID.
  - (FIND)
  - TRAVERSE
  - PFA
  - NFA
Bank 3: 8096 bytes
- nothing but the header as yet

I am puzzling over how to manage TASK , the last word in the resident dictionary. The TI Forth programmers duplicated the dictionary entry for TASK with a 14-byte buffer, the purpose for which I cannot guess. I am inclined to ignore the buffer and just copy the duplicate TASK to >A000. The reason for the copy is to accommodate BLOAD and BSAVE , so I need to preserve this behavior. Whatever I do, I need to figure out how to handle that particular dictionary entry because it is in a sort of limbo between the split headers of ROM and the intact dictionary entries of RAM. I'm thinking out loud here, but any suggestions are welcome.

...lee

+Lee Stewart · May 22, 2014

Help!

I'm having trouble setting up Classic99.ini. I have 4 ROM-bank files fbForth200C.bin – fbForth200F.bin, which were split out, using Tursi's DF802BIN.exe, from fbForth200.obj as fbForth2001.bin – fbForth2004.bin and renamed backwards to the lettered BINs.

I am now trying to troubleshoot my code, but I must not have it set up correctly in the INI file, which follows:

[UserCart0]
name="fbForth 2.0"
rom0=C|6000|2000|MODS\fbForth200C.bin
rom1=C|6000|2000|MODS\fbForth200D.bin
rom2=C|6000|2000|MODS\fbForth200E.bin
rom3=C|6000|2000|MODS\fbForth200F.bin

...lee

+Lee Stewart · May 22, 2014

OK—combining the binaries into a single binary and using the following seems to be right, though I don't have a clue how to get it to work in MESS and the other emulators:

[UserCart0]
name="fbForth 2.0"
rom0=3|0000|8000|MODS\fbForth200.bin

Now the debugging can begin in earnest!

...lee

+mizapf · May 22, 2014

How do you switch the four 8K ROMs? Maybe this is already available as a cartridge type in MESS.

+Lee Stewart · May 22, 2014

How do you switch the four 8K ROMs? Maybe this is already available as a cartridge type in MESS.

CLR @>6006 for ROM bank 0 – CLR @>6000 for ROM bank 3—using 379s.

...lee

+mizapf · May 22, 2014

OK, we have a cartridge type "paged379i". You simply concatenate all ROM files to a single 32K file (starting with bank 0), name it for instance "allroms.bin". Then create a file "layout.xml" with this content:

<?xml version="1.0" encoding="utf-8"?>
<romset version="1.0">
   <resources>
      <rom id="romimage" file="allroms.bin"/>
   </resources>
   <configuration>
       <pcb type="paged379i">
          <socket id="rom_socket" uses="romimage"/>
       </pcb>
   </configuration>
</romset>

and create a ZIP file with this layout.xml and the allroms.bin. Finally change the zip suffix of the file name to rpk.

Edited May 22, 2014 by mizapf

+Lee Stewart · May 23, 2014

Thanks, Michael. I will give it a try when I get a little further along with my debugging.

...lee

Tursi · May 23, 2014

Help!

I'm having trouble setting up Classic99.ini. I have 4 ROM-bank files fbForth200C.bin – fbForth200F.bin, which were split out, using Tursi's DF802BIN.exe, from fbForth200.obj as fbForth2001.bin – fbForth2004.bin and renamed backwards to the lettered BINs.

I am now trying to troubleshoot my code, but I must not have it set up correctly in the INI file, which follows:
[UserCart0]
name="fbForth 2.0"
rom0=C|6000|2000|MODS\fbForth200C.bin
rom1=C|6000|2000|MODS\fbForth200D.bin
rom2=C|6000|2000|MODS\fbForth200E.bin
rom3=C|6000|2000|MODS\fbForth200F.bin
...lee

I know you got it to work by combining, but what you wanted to do here was use a cartridge type of '3' to enable the 379 switching. After that, the first parameter (what you have here as >6000), represents the offset in the "379 EPROM Space". So you would use 0000,2000,4000,6000 (or the reverse order, depending on your ROM order). As defined above, all the files just overwrote each other in the standard 8k ROM space.

rom0=3|0000|2000|MODS\fbForth200C.bin
rom1=3|2000|2000|MODS\fbForth200D.bin
rom2=3|4000|2000|MODS\fbForth200E.bin
rom3=3|6000|2000|MODS\fbForth200F.bin

+Lee Stewart · May 23, 2014

Thanks, Mike. I understand it now.

...lee

+Lee Stewart · May 26, 2014

We have liftoff! :-o

I now have fbForth 2.0 working in cartridge space. I'm sure there are bugs—but, right now, it works.

Splitting out the resident dictionary headers from bank 0 into bank 2 has already pulled me up short with VLIST , the dictionary word listing word. I had to define 2 new words, BNK2@ and BNK2C@ , which will get the cell contents and byte contents, respectively, of an address on the stack that might be in bank 2, as is the case with link field and name field addresses in the resident dictionary. I can see that I will need to devote some space in the manual to this issue.

Later tonight or tomorrow, I will post the fbForth 2.0 (beta) cartridge binary, FBLOCKS file for fbForth 2.0 and directions for loading the binary in Classic99 and MESS (yet to be tested). Right now, I have to do some yard work. :mad:

...lee

Willsy · May 26, 2014

WOW! Awesome job, Lee! I can't wait to take it for a spin! :thumbsup: :thumbsup: :thumbsup: :thumbsup: :thumbsup:

+Lee Stewart · May 26, 2014

OK—here it is:

fbForth200-beta01.zip

Put the BIN file in the Classic99 MODS folder and the FBLOCKS file wherever DSK1 is.

Modify the Classic99.ini file to have the following at the end. Change "UserCart0" to a non-conflicting number:

[UserCart0]
name="fbForth 2.0"
rom0=3|0000|8000|MODS\fbForth200.bin

As always, let me know of any bugs etc.

...lee

+Ksarul · May 26, 2014

Neat! I'm glad you've made it this far, Lee! More fun things for cartridge space. . .

+Lee Stewart · May 27, 2014

And—here's the MESS package:

fbForth200-beta01-MESS.zip

...lee

Willsy · May 27, 2014

Lee,

Looking super cool! Now we need the manual ;-)

Some (minor) observations:

1) typing COLD in 80 column mode:

Only half of the screen is cleared (CLS is not 80-column aware)
The title/copyright notice etc is not formatted correctly (suggestion: your boot code in your FBLOCKS determines the video mode and formats appropriately)
After executing COLD (in 80 column mode) only the top 12 lines of the screen scroll. To reproduce, try this:

TEXT80
: TEST 500 0 DO I . LOOP ;
TEST
COLD

Now hit enter a few times... See? It's performing a 40-column scroll, but since we're in TEXT80 that only amounts to half of the screen.

2) MENU leaves two values on the stack.

3) Typing gibberish does not cause the data stack to be flushed. This may be by design/original TI Forth behaviour - if so, no biggie. "Standard" Forth behaviour is to clear the data stack. I have got into the habit of typing sdsdsdsdsd to clear the data stack in TF so it was a surprise, that's all.

Looking awesome, Lee! :thumbsup:

+Lee Stewart · May 27, 2014

On 5/27/2014 at 6:50 AM, Willsy said:

Lee,

Looking super cool! Now we need the manual

...

Looking awesome, Lee!

Thanks!

Some (minor) observations:

1) typing COLD in 80 column mode:

Only half of the screen is cleared (CLS is not 80-column aware)
The title/copyright notice etc is not formatted correctly (suggestion: your boot code in your FBLOCKS determines the video mode and formats appropriately)
After executing COLD (in 80 column mode) only the top 12 lines of the screen scroll. To reproduce, try this:

Yeah, I see that as a bug in in the E/A3 version, as well—bummer! The problem is that the COLD / BOOT sequence is not graphics mode aware. It assumes text mode, unfortunately. One of the problems, which is next on my list to change, is that graphics modes are part of the graphics packages in FBLOCKS, not the resident dictionary. Now that I have more room in ROM, I intend to hoist that all into ROM space. In fact, I started on that before I made the push to get a working cartridge system, but didn't have enough room in bank 0. That's when the idea to split the headers arrived in my noggin—so, I just pounded away at that until I had a working system. Now, I need to get on with making COLD graphics-mode aware, which will be awhile because putting the graphics package into ROM space is no small task!

2) MENU leaves two values on the stack.

Not for me it doesn't. MENU does not clear the stack, but it doesn't put anything there, either. Tell me more.

3) Typing gibberish does not cause the data stack to be flushed. This may be by design/original TI Forth behaviour - if so, no biggie. "Standard" Forth behaviour is to clear the data stack. I have got into the habit of typing sdsdsdsdsd to clear the data stack in TF so it was a surprise, that's all.

Actually, typing gibberish does clear the stack. It then "helpfully" places the values of IP and BLK on the stack to aid in locating where the problem occurred. This is extremely helpful when loading new code from disk, but mostly irritating with input from the console. If you want to manually clear the stack, SP! is your friend.

I probably will wait until I have graphics in ROM space to fix the problem with COLD .

...lee

Willsy · May 27, 2014

2) MENU leaves two values on the stack.

Not for me it doesn't. MENU does not clear the stack, but it doesn't put anything there, either. Tell me more.

Ah. I've got it now. My bad. The two values on the stack were from me typing menu (lower case) which was rejected. I then typed MENU which worked, but the previous error was left on the stack. No problem.

Actually, typing gibberish does clear the stack. It then "helpfully" places the values of IP and BLK on the stack to aid in locating where the problem occurred.

Indeed. Those are the two values that I thought MENU was pushing on to the stack.

Yeah, I see that as a bug in in the E/A3 version, as well—bummer! The problem is that the COLD / BOOT sequence is not graphics mode aware.

Got it. Sounds like you're right on top of it. Have at it, boy, have at it :thumbsup:

fbForth fbForth—TI Forth with File-based Block I/O [Post #1 UPDATED: 06/05/2024]

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members