How to run a 32 bit Forth under DOS?

[jf...@ms4.hinet.net]

I downloaded the 32 bit os2forth.zip from FIG's compilers page
http://www.forth.org/compilers.html
I can run its forth.com without problem in a DOS box under WinXP
but when I run it in a DOS system (which was booted from a USB drive),
I encounter the following message:
"DPMI Protected Mode Loader for DOS (C) 1993 Rick VanNorman
No DPMI host detected"

I had the "device=himem.sys" in its config.sys file.

Anything else I missed?

--Jach

[humptydumpty]

Hi!

You'll need a Dos Protected Mode extender, like CWSDPMI:
http://homer.rice.edu/~sandmann/cwsdpmi/index.html

Have a nice day,
humptydumpty

[jf...@ms4.hinet.net]

> You'll need a Dos Protected Mode extender, like CWSDPMI:
>
> http://homer.rice.edu/~sandmann/cwsdpmi/index.html

It works, thank you very much!

--Jach

[hughag...@yahoo.com]

On Wednesday, June 11, 2014 2:09:58 AM UTC-7, jf...@ms4.hinet.net wrote:
> I downloaded the 32 bit os2forth.zip from FIG's compilers page
> http://www.forth.org/compilers.html

That is the publicly released version of Laboratory Microsystems UR/Forth. When I worked at Testra, I wrote both my programs (I've mentioned MFX on comp.lang.forth) in 32-bit UR/Forth for DOS, running under a DOS-extender.

I have disassembled the heck out of UR/Forth, and I am aware of some bugs, and I have bug-fixes. Contact me privately if you need any help with the system. Why are you working with MS-DOS though??? This is some kind of retro hobby project?

Laboratory Microsystems (Ray Duncan) no longer sells UR/Forth, which is why this is now available for free download but with no support. Testra has the full source-code to UR/Forth though --- they are the only company that Laboratory Microsystems ever provided the source-code to, afaik. Testra signed a non-disclosure agreement with Ray Duncan though, so I never got to look at the UR/Forth source-code the entire time that I worked there --- I didn't really need to see the source, as I already had disassembled most of it.

[jf...@ms4.hinet.net]

2014/06/12 AM 11:25:15 hughag...@yahoo.com wrote:
> On Wednesday, June 11, 2014 2:09:58 AM UTC-7, jf...@ms4.hinet.net wrote:
>
> > I downloaded the 32 bit os2forth.zip from FIG's compilers page
>
> > http://www.forth.org/compilers.html
>
>
>
> That is the publicly released version of Laboratory Microsystems UR/Forth. When I worked at Testra, I wrote both my programs (I've mentioned MFX on comp.lang.forth) in 32-bit UR/Forth for DOS, running under a DOS-extender.

I have no idea it's related to LMI's UR/FORTH. Our company distributed their
Meta Compiler locally at the age of '90 when they are very active on the market.

> I have disassembled the heck out of UR/Forth, and I am aware of some bugs, and I have bug-fixes. Contact me privately if you need any help with the system. Why are you working with MS-DOS though??? This is some kind of retro hobby project?

Bugs? then I definitely need you help when the time comes:-)

I am working on a Mini-ITX board which has no hard driver attached and I need to
access its whole 4GB memory. I think boot from a USB drive and run a 32bit Forth
might be a good solution.

--Jach

[hughag...@yahoo.com]

On Thursday, June 12, 2014 6:00:10 PM UTC-7, jf...@ms4.hinet.net wrote:
> 2014/06/12 AM 11:25:15 hughag...@yahoo.com wrote:
> > That is the publicly released version of Laboratory Microsystems UR/Forth. When I worked at Testra, I wrote both my programs (I've mentioned MFX on comp.lang.forth) in 32-bit UR/Forth for DOS, running under a DOS-extender.
>
> I have no idea it's related to LMI's UR/FORTH.

Oh, I screwed up --- I was thinking of LMI WinForth, which is not the one that you were describing. I don't actually know anything about OS2Forth by Rick vanNorman.

There was a ROMable version of UR/Forth, although I don't think that it is available since LMI went out of business. If you can get by with a 16-bit Forth (maybe addressing the 4GB as extended memory), you could use ForthCMP from Tom Almy which is ROMable. I did use the MS-DOS version of this, and found it to generate efficient code, but to be difficult to program because it is not interactive like Forth traditionally is but only compiles to an executable.

May I ask what your project does? It seems overly complicated to have MS-DOS and a DOS-extender, when you don't have a disk-drive anyway. Why not use a 32-bit micro-controller such as the ARM or the PIC32?

[jf...@ms4.hinet.net]

2014/06/13 PM 01:01:29 hughag...@yahoo.com wrote：
> There was a ROMable version of UR/Forth, although I don't think that it is available since LMI went out of business. If you can get by with a 16-bit Forth (maybe addressing the 4GB as extended memory), you could use ForthCMP from Tom Almy which is ROMable. I did use the MS-DOS version of this, and found it to generate efficient code, but to be difficult to program because it is not interactive like Forth traditionally is but only compiles to an executable.
>

It's almost impossible to run a "ROM" program on today's x86 board where only PCI, ePCI or SATA interface is available. I will be very happy if someone can tell me how to do that.

> May I ask what your project does? It seems overly complicated to have MS-DOS and a DOS-extender, when you don't have a disk-drive anyway. Why not use a 32-bit micro-controller such as the ARM or the PIC32?

It's a kind of testing machine. The performance this program requires to reach makes me has no other choice except the x86. An ARM running at 200MHz is far away from doing this job.

--Jach

[jf...@ms4.hinet.net]

This Forth.com (DOS version) didn't work when I try to ALLOCATE some memory. It just shows a message "General Protection Fault" and exit to DOS immediately. After a little trace, it was caused by a 2! to the address which the ALLOCATE returns.

Any idea about this problem?

--Jach

[hughag...@yahoo.com]

On Friday, June 13, 2014 4:00:56 AM UTC-7, jf...@ms4.hinet.net wrote:
> 2014/06/13 PM 01:01:29 hughag...@yahoo.com wrote：
>
> > There was a ROMable version of UR/Forth, although I don't think that it is available since LMI went out of business. If you can get by with a 16-bit Forth (maybe addressing the 4GB as extended memory), you could use ForthCMP from Tom Almy which is ROMable. I did use the MS-DOS version of this, and found it to generate efficient code, but to be difficult to program because it is not interactive like Forth traditionally is but only compiles to an executable.
>
> It's almost impossible to run a "ROM" program on today's x86 board where only PCI, ePCI or SATA interface is available. I will be very happy if someone can tell me how to do that.

I don't know either. I've never used an x86 as a micro-controller, and I don't know anybody who has.

The last time I gave any thought to this, was in 1995 when I was working at Testra. In those days, the 80186 as well as the various NEC Vxx chips were sometimes used as micro-controllers, typically running MS-DOS although sometimes running the program out of ROM if the compiler supported generating rommable code. I asked my boss (John Hart) his opinion on the subject, and he said that it was a terrible idea --- it cost too much and it only worked for very pedestrian micro-controller systems due to the slow interrupt response time of the x86 --- it was done primarily by people who wanted to use a compiler (Turbo C, Turbo Pascal, or whatever) that they were familiar from MS-DOS. As far as I know, this is still true --- the x86 is too slow on interrupts to be usable as a micro-controller.

> > May I ask what your project does? It seems overly complicated to have MS-DOS and a DOS-extender, when you don't have a disk-drive anyway. Why not use a 32-bit micro-controller such as the ARM or the PIC32?
>
> It's a kind of testing machine. The performance this program requires to reach makes me has no other choice except the x86. An ARM running at 200MHz is far away from doing this job.

I'm baffled as to what kind of testing you could be doing that requires high speed. Prior to working at Testra, I worked at a company that built a testing machine for the wafers used in semiconductor manufacturing. The machine would poke at the wafer with prods, squirt some juice in with a DAC, and read what came out elsewhere with an ADC. This was an 80286 and it had its own hard-drive. It was pretty pedestrian. It would hold those prods in place for long periods of time --- like 20 milliseconds --- this was not real-time at all.

All in all, I think that a processor normally used in a desktop computer, such as the x86, is a bad idea for use as a micro-controller. At Testra, for their laser etcher, they used a dual-processor board. They had an 8051 with 64MB of memory (they used some parallel ports to provide the upper address lines); this buffered the big data files that the desktop computer uploaded into the laser etcher. They also had the MiniForth that was 16-bit and did the motion-control in real-time. The 8051 would feed it the data as it was needed, so it didn't have to buffer much data --- being a 16-bit processor, the MiniForth had only 64KW of data memory and 64KW of code memory. BTW: The MiniForth has to be used in a dual-processor board anyway, because it needs a pony processor to get it going, as it can't start itself up. The competition in the laser-etcher field was using an MC68020 and it was much slower than the MiniForth --- being slow is a big problem in a laser-etcher, because if you leave the laser sitting in one place too long it will burn a big blotch in the material --- to etch thin sharp lines, your motion-control board has to be extremely fast and you can't have any harmonic feedback.

You haven't described your testing machine in any depth, so I can't really make a recommendation. Offhand though, I would say that a dual-processor is a good idea. Use a fast 16-bit processor such as the PIC24 to do the micro-controller stuff, and use a slow 32-bit processor to buffer the data and communicate with the desktop computer. It is difficult for me to imagine any kind of testing apparatus that this would not work for. The PIC24 is fast because it doesn't use external memory at all --- both code and data memory are internal to the processor --- the downside is that you only get 16KB of data memory.

[Stephen Pelc]

There's always the DPMI server ...

And there's always VFX Forth for DOS, which we still sell, much
to my amazement.

Stephen

--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[jf...@ms4.hinet.net]

2014/06/19 PM 4:56:53，Stephen Pelc写道：

> There's always the DPMI server ...
>
>
> And there's always VFX Forth for DOS, which we still sell, much
>
> to my amazement.
>
>
>
> Stephen
>
>
>
> --
>
> Stephen Pelc, steph...@mpeforth.com
>
> MicroProcessor Engineering Ltd - More Real, Less Time
>
> 133 Hill Lane, Southampton SO15 5AF, England
>
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
>
> web: http://www.mpeforth.com - free VFX Forth downloads

I had found two "still in sell" 32bit Forth, one is your "VFX Forth for DOS" and the other is Marcel Hendrix's "iForth for DOS". But, unfortunately, both have the trial version for Windows and Linux only, not for DOS, and both drop support on their DOS version.

The OS2Forth I tested comes with full source so I will try to spend sometime to figure out the ALLOCATE problem. If I fail, then the paid solution might be taken.

--Jach

[Albert van der Horst]

In article <8eb19c18-30da-4daf...@googlegroups.com>,

A long time ago I made a 32 bits version of ciforth for DOS.
Switching back and Forth to protected mode to use the BIOS
was a real pain. I can't believe anyone would fancy this.
Anyway. You can download the generic system for ciforth, and
try to build what you want.
http://home.hccnet.nl/a.w.m.van.der.horst/ciforth.html

The configuration file to be used is: msdos32.cfg

If you manage to get it running you will have a full fledged system
with pdf documentation and all. The development is on Linux, this kind
of feat is impossible on a Windows system.

A description of how and what to test is :
http://home.hccnet.nl/a.w.m.van.der.horst/testreport.txt

Note that it may fail to work on systems that are younger than
10 years, for unknown reasons. Don't count on me to find out why.

I'll help you with using the generic system though.

It seems that you this works *without* a dos extender. If someone
else is fooling around with protected mode, it fails.

(The booting version works similarly, but without MSDOS. It also
fails for unknown reasons on many modern systems.)

>
>--Jach
>

Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[jf...@ms4.hinet.net]

2014/06/20 PM 6:41:18，Albert van der Horst wrote：
> A long time ago I made a 32 bits version of ciforth for DOS.
> Switching back and Forth to protected mode to use the BIOS
> was a real pain. I can't believe anyone would fancy this.
> Anyway. You can download the generic system for ciforth, and
> try to build what you want.
>
> http://home.hccnet.nl/a.w.m.van.der.horst/ciforth.html
>

Thank you for your info.

I did try MINA(mna4d0d6.zip) a while ago, but it seems is a 16bit system.

Am I wrong?

--Jach

[Albert van der Horst]

In article <fb3705bf-c8d8-4746...@googlegroups.com>,

It is a straigth forward 16 bits msdos Forth that runs in real and in
pseudoreal mode. It was build using msdos.cfg now mina.cfg

For 32 bits however, you are forced to go protected mode.
It is build using msdos32.cfg

For your special wishes there is no pre-build binary.
You must go from source.

[jf...@ms4.hinet.net]

About using the Forth.com in OS2Forth package:
I found that the ALLOCATE fails at "2!" is becasue the allocated memory have to be handled through a valid "Selector" which its current DS register is obviously not. Instead of fixing it, I just grab all the memory the system has and put it into the Forth's hand at the beginning. It's a 32bit Forth so no problem to access them.

I had also try another path of running a 32bit Forth under DOS. Instead of running a DOS version, I tried to run SwiftForth's console mode under the HX DOS extender which has limited Win32 support. But it won't work, don't know why.
http://www.japheth.de/HX.html.

--Jach

[Timothy Trussell]

OS2Forth has the capability of letting the user specify how much memory is allocated on execution, with the default being a 1 meg dictionary size. In the FORTH.4 file, this is found on line 63:

HERE EQU 'EM $01000000 DW \ 1meg dictionary

Changing this to:

HERE EQU 'EM $10000000 DW

will allocate a 16 meg dictionary. Then executing the BUILD.BAT file will rebuild the compiler, and voila, there you go.

The largest dictionary size I tested was 256 megs, and have no idea if it is even possible to allocate the balance of 4 gigs of memory in this way under a 16-bit DOS environment, regardless of having a DPMI system installed.

You may want to browse through the DPMI document that is included in the OS2Forth archive (DPMISPEC.TXT in the STUFF directory on my drive).

Note that under Windows, DPMI functions $800/$801 are non-functional, and deal with allocation/deallocation of blocks of memory, so you cannot test any code on your Windows machine that requires use of these calls.

---

Since you have the capability of booting from a USB stick, you might want to consider using Linux and running gforth, which is a much more complete - not to mention currently being maintained - version of Forth.

--Tim

[jf...@ms4.hinet.net]

Timothy Trussell 2014/06/30 AM 01:19:07 wrote：
> OS2Forth has the capability of letting the user specify how much memory is allocated on execution, with the default being a 1 meg dictionary size. In the FORTH.4 file, this is found on line 63:
>
> HERE EQU 'EM $01000000 DW \ 1meg dictionary
>
> Changing this to:
>
> HERE EQU 'EM $10000000 DW
>
> will allocate a 16 meg dictionary. Then executing the BUILD.BAT file will rebuild the compiler, and voila, there you go.
>
> The largest dictionary size I tested was 256 megs, and have no idea if it is even possible to allocate the balance of 4 gigs of memory in this way under a 16-bit DOS environment, regardless of having a DPMI system installed.
>

Thanks, Tim. I had try but won't work. No matter what the value is, $00100000
or $10000000, the memory map shown after "include build.4" is the same (1MB):

version 3.07 compiled on 09/24/1994 at 15:18:21

1048576 bytes: dictionary size (ORG+$110)
147456 bytes: reserved memory (ORG+$114)
256 cells: user variables (ORG+$118)
2048 cells: return stack (ORG+$11C)
256 bytes: tib (ORG+$120)

> Note that under Windows, DPMI functions $800/$801 are non-functional, and deal with allocation/deallocation of blocks of memory, so you cannot test any code on your Windows machine that requires use of these calls.
>

Oh, I see. But the ALLOCATE fails also under DOS with CWSDPMI host.

> Since you have the capability of booting from a USB stick, you might want to consider using Linux and running gforth, which is a much more complete - not to mention currently being maintained - version of Forth.
>

At this moment I might stick to OS2Forth for a while for 1) It's simpler and with source. 2) I can access the whole 4GB memory now. Thanks for your advice.

--Jach