I've been dabbling with the F83 distribution for DOS from forth.org. ( http://www.forth.org/library/eforth_SOC/eforth_SOC_source/f83/f83v2-ms.lzh )

But I seem to have some odd issue running it.

Specifically, this:

- run F83.EXE
- OPEN META86.BLK
- 1 LOAD

I get a list of 21 screens, and a "Disk Error in ....", with the filename being garbage.

Now, this is on a modern iMac, but I've tried it across 3 separate runtimes.. I've tried it on Virtual Box running MS-DOS 6.22, I tried it on QEMU running MS-DOS 6.22, and I tried it on a Mac specific app called "Boxer", which is DosBox in a wrapper, I don't even know what version of DOS it emulates.

All of them fail the same way.

Now, we all know that F83 uses about this ][ much of DOS. And even more of a conundrum, I'm pretty sure I had this working before.

Mind, I've had other disk errors that would sometimes happen (such as just saving an editor screen). But they were intermittent, and maybe I corrupted something because I was switching back and forth between different BLK files (unlikely though, the mechanic is pretty simply and sound, but.. who knows).

But this replicates every time.

So, anyway, I'm coming back to fundamentals wondering if anyone has tried this (or could try it) and see if it's something local to me, or if there's something else going on. I appreciate this is pretty far from main stream as you can get, but if there was any F83 expertise floating around, I'd think it might be here.

Thanks!

Regards,

Will Hartung

On 1/07/2021 13:50, Will Hartung wrote:
> I've been dabbling with the F83 distribution for DOS from forth.org. ( http://www.forth.org/library/eforth_SOC/eforth_SOC_source/f83/f83v2-ms.lzh )
>
> But I seem to have some odd issue running it.
>
> Specifically, this:
>
> - run F83.EXE
> - OPEN META86.BLK
> - 1 LOAD
>
> I get a list of 21 screens, and a "Disk Error in ....", with the filename being garbage.

Long time since I touched F83 but I get the same result as you.

README.PC says to use:

F83 META86.BLK
OK
BYE

And that appears to work.

If you haven't already tried it you may like to check out DX-Forth for DOS
which is the same class as F83 but closer to Forth-94:

DXDOS444.ZIP

https://drive.google.com/drive/folders/1kh2WcPUc3hQpLcz7TQ-YQiowrozvxfGw

I reposted this, you may get a reply in email.

On Wednesday, June 30, 2021 at 9:20:42 PM UTC-7, dxforth wrote:
> Long time since I touched F83 but I get the same result as you.
>
> README.PC says to use:
>
> F83 META86.BLK
> OK
> BYE
>
> And that appears to work.

Wow, that actually does work. I still have to do the 1 LOAD, but it survives. It was my understanding that F83 <filename> did little more than simply open the file, it doesn't actually execute anything. Which is one reason I didn't bother to try it, "Same thing."

Well that's good, perhaps I can hunt down why the other mechanic fails while this one doesn't.

> If you haven't already tried it you may like to check out DX-Forth for DOS
> which is the same class as F83 but closer to Forth-94:
>
> DXDOS444.ZIP
>
> https://drive.google.com/drive/folders/1kh2WcPUc3hQpLcz7TQ-YQiowrozvxfGw

Thanks, I was drawn toward F83 because it seems to be, of the publicly available Forths, to be the peak of a Forth that's for an 8-Bit machine (even though this is the PC version, it's an 8-bit Forth), still uses Screens, and not really PC specific, and has a metacompiler. My goal, as I get the energy and whimsy, is to port it to my hacked up simulated 6502 machine, which has no file system. If I can get it ported, then I can have a self-hosted Forth on my "machine". I have F83-8086 and F83-8080 which is perfect as I can compare the two to readily see what needs to change in a port.

In that light, I have spent the past few days merging the separate F83 Forth source code files in to a single large file (which is a little harder than it sounds), which will more look like it's (ideally) inevitable destination.

Using your suggestion, I was able to run the first phase with my big file. Which is good. This has vexed me before, now that I know there's a difference, hopefully I can progress more. I was never able to make that connection before. And since I should be able to rebuild the image, perhaps I can actually debug what's going wrong here in the first place.

Thanks for the help.

Regards,

Will Hartung

On 2/07/2021 02:08, Will Hartung wrote:
>
> I was drawn toward F83 because it seems to be, of the publicly available Forths, to
> be the peak of a Forth that's for an 8-Bit machine (even though this is the PC version, it's
> an 8-bit Forth), still uses Screens, and not really PC specific, and has a metacompiler. My
> goal, as I get the energy and whimsy, is to port it to my hacked up simulated 6502 machine,
> which has no file system. If I can get it ported, then I can have a self-hosted Forth on my
> "machine". I have F83-8086 and F83-8080 which is perfect as I can compare the two to readily
> see what needs to change in a port.

Ok on the 6502 port. I suppose for Laxen and Perry it was easy to port to four
popular OS whose 'DOS' was essentially the same. BTW there exists a port of CP/M
to 6502 should you be looking at expanding your system that far:

http://www.z80.eu/dos65.html

On Thursday, July 1, 2021 at 9:08:48 AM UTC-7, Will Hartung wrote:
> Wow, that actually does work. I still have to do the 1 LOAD, but it survives. It was my understanding that F83 <filename> did little more than simply open the file, it doesn't actually execute anything. Which is one reason I didn't bother to try it, "Same thing."
>
> Well that's good, perhaps I can hunt down why the other mechanic fails while this one doesn't.

I'm pretty sure I figured it out, as with many, in hindsight it makes complete sense.

Now, in CP/M, there is a system level FCB (File Control Block) that is assigned to the first argument of the command line. The raw assumption that the first argument after the name of the command is a file.

I assume DOS (and its CP/M roots) works the same way.

When you specify the file name from the command line, that's the FCB that is used.

Now, in F83, when you do "OPEN META86.BLK", the FCB is allocated right there in the dictionary. In fact, F83 defines a word META86.BLK that returns the address of the FCB.

Since this is the meta compiler, the first thing it does is disable FENCE, and then FORGETs the word OUT. I can't at the moment say why OUT vs any other word, but that doesn't matter. The key point is the OUT is defined before the META86.BLK created by OPEN.

So, what happens is when we start reading the blocks and adding new words to the dictionary, in time, the FCB defined for FILE.BLK gets stomped on. And that's when we get the error.

This, naturally, doesn't happen with the system provided FCB, as its not part of the dictionary.

Thus the distinction between specifying the file name on the command line and opening it after startup, especially for this particular case.

Kind of an epiphany, and I appreciate you taking to time to try it out.

Thanks again.

Regards,

Will Hartung

On 2/07/2021 13:25, Will Hartung wrote:
> On Thursday, July 1, 2021 at 9:08:48 AM UTC-7, Will Hartung wrote:
>> Wow, that actually does work. I still have to do the 1 LOAD, but it survives. It was my understanding that F83 <filename> did little more than simply open the file, it doesn't actually execute anything. Which is one reason I didn't bother to try it, "Same thing."
>>
>> Well that's good, perhaps I can hunt down why the other mechanic fails while this one doesn't.
>
> I'm pretty sure I figured it out, as with many, in hindsight it makes complete sense.
>
> Now, in CP/M, there is a system level FCB (File Control Block) that is assigned to the first argument of the command line. The raw assumption that the first argument after the name of the command is a file.
>
> I assume DOS (and its CP/M roots) works the same way.
>
> When you specify the file name from the command line, that's the FCB that is used.
>
> Now, in F83, when you do "OPEN META86.BLK", the FCB is allocated right there in the dictionary. In fact, F83 defines a word META86.BLK that returns the address of the FCB.
>
> Since this is the meta compiler, the first thing it does is disable FENCE, and then FORGETs the word OUT. I can't at the moment say why OUT vs any other word, but that doesn't matter. The key point is the OUT is defined before the META86.BLK created by OPEN.
>
> So, what happens is when we start reading the blocks and adding new words to the dictionary, in time, the FCB defined for FILE.BLK gets stomped on. And that's when we get the error.
>
> This, naturally, doesn't happen with the system provided FCB, as its not part of the dictionary.
>
> Thus the distinction between specifying the file name on the command line and opening it after startup, especially for this particular case.
>

CP/M doesn't keep track of open files so the application has to do it via FCB's.
F83 appears to allocate them in data space as named words needed. DX-Forth for
CP/M does it a bit more like MS-DOS and its FILES= command.

On 7/1/21 10:25 PM, Will Hartung wrote:
> Now, in CP/M, there is a system level FCB (File Control Block) that is assigned to the first argument of the command line. The raw assumption that the first argument after the name of the command is a file.
>

The CP/M CCP does some setting up activity before starting a program.
Part of the program space is occupied by the base page. Which contains
bits like a copy of the command line, and up to two FCBs that the CCP
parsed from the command line.

https://en.wikipedia.org/wiki/Zero_page_(CP/M)

--
http://davesrocketworks.com
David Schultz