Stand Alone Forth
Thomas D. Dean
data collection/control processor. The data collection will write to disk.
I used a system at SLAC, developed/maintained by Connie Logg on an
LSI-11. This version was bootable, loading some screens and droping
into an interactive session.
Initially, I have a AMD-PC with an ASUS motherboard, 512MB RAM, floppy
and 70G disk.
I want to boot a system initally from floppy for development and later
from the hard disk.
I want to use BIOS I/O as much as possible.
What source should I use? Is it possible to get a processor into a
flat, 32-bit mode?
MarkWills
Perhaps ForthOS could be used as a starting point? ForthOS is, as the
name implies, a self-hosting system, relying on no underlying
operating system. It supports floppy and hard disks.
You don't mention the interfaces your data collection application will
use: TCP/IP, Serial (RS232/485), Digital, Analog. I'm not sure if
ForthOS has an IP Stack.
In fact, here's the introduction from the ForthOS website:
ForthOS is a complete, standalone operating system for the PC. It
includes command line, compiler, debugger, editor, and filesystem. You
can give it a test drive by booting the standalone CD (image provided
so you can burn your own). If you like it, you can install it onto a
disk partition and boot directly from your hard disk.
ForthOS is the basis for the author's own experimental software work;
unlike many other Forth systems, this one is a real tool in day-to-day
use as a part of a larger development. It is a fully standalone
system, with a metacompiler used to generate new versions of ForthOS
while running under ForthOS. Please read about its legal status; the
short version is that ForthOS is in the public domain.
ForthOS supports:
* System features:
* 32-bit addressing
* Command line history and editing
* Multi-tasking
* Pentium-based real time clock
* Auto-pause for console output
* Block-oriented file I/O
* A filesystem which organizes ForthOS blocks
* Multiboot/GRUB compliant bootloading
* Multiple virtual screens with screen flipping using function keys
* IDE
* VGA
* RS-232 (COM) ports
Forth language features:
* The original eForth vocabulary
* Many additional vocabulary words, mostly standards based
* Vocabularies
* VOCAB.WORD extension to find WORD in VOCAB regardless of current
search order.
* Structures and enumerations
* A full object oriented extension with classes and inheritance
* A variant on local variables (more closely related to a lambda
binding) with optional input and output stack format enforcement.
* Scoping of identifiers (Local and scrLocal).
Tools
* vi-like full screen editing with shadows
* Debugger
* Heap memory allocator
* x86 assembler
Looks like it doesn't do TCP/IP. If you are wanting do data capture
from serial devices, ForthOS looks like a good choice, although it
looks like it is no longer an actively developed project.
I wonder if there is any real reason why you require a "stand alone"
Forth though? This seems like a somewhat arbitrary requirement, if you
don't mind me saying so. Having an underlying operating system (and
the resources it provides) may make things like network based
communications easier.
There are a number of excellent commercial Forth offerings, that run
on top of conventional operating systems such as Windows and Linux.
MPE in the UK (www.mpeforth.com) and Forth, Inc in the USA
(www.forth.com).
If cost is an issue, an excellent GNU ANS compliant Forth exists in
the form of GForth, which is available on Linux/Unix and Windows
platforms, and possibly others.
Hope this helps.
Mark.
ember
ciforth might be worth a look: http://home.hccnet.nl/a.w.m.van.der.horst/forthimpl.html
there is a 32bit standalone binary available
Regards
Emma
Thomas D. Dean
MarkWills wrote:
> I wonder if there is any real reason why you require a "stand alone"
> Forth though? This seems like a somewhat arbitrary requirement, if you
> don't mind me saying so. Having an underlying operating system (and
> the resources it provides) may make things like network based
> communications easier.
The standalone requirement is to get away from the resource uses by the
OS. Things like delayed response, interrupts off, etc. I have tried
this with Linux and keep missing data while the OS is doing other
things. The data stream does not stop.
Stephen Pelc
<tom...@speakeasy.org> wrote:
>Initially, I have a AMD-PC with an ASUS motherboard, 512MB RAM, floppy
>and 70G disk.
>
>I want to boot a system initally from floppy for development and later
>from the hard disk.
>
>I want to use BIOS I/O as much as possible.
>
>What source should I use? Is it possible to get a processor into a
>flat, 32-bit mode?
Nearly all DOS extenders do just this. There are plenty around.
It's quite possible to use the DOS as a program loader and then
be in a flat 32 bit address space.
We have used several, including commercial and free. We can
recommed WDOSX and we've looked at the HX DOS extender, which
appears to be current. A good starting point is:
http://en.wikipedia.org/wiki/DOS_extender
The big advantage of the DOS extenders is that they avoid you having
to deal with the hardware and the file system. Treat them as a program
loader and you'll be fine.
For hard real-time systems in 32 bit mode, an x86 is a dog unless
you roll your own from the beginning and avoid task and interrupt
gates like the plague. Note also that modern PC hardware does not
have to support VGA graphics emulation, so relying on specific
video hardware modes will lead to problems. If you really want to
run protected mode and be hardware independent, there are plenty
of small Linux distros, e.g. Puppy and DSL, that will run in far
less than you have. There are also plenty of Forths from free to
commercial for Linux. We even ship (and use) a version for 386/486
class CPUs.
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
Stephen J. Bevan
> The standalone requirement is to get away from the resource uses by
> the OS. Things like delayed response, interrupts off, etc. I have
> tried this with Linux and keep missing data while the OS is doing
> other things.
So, you've used sched_setscheduler to set the policy of your data
collection process to either SCHED_FIFO or SCHED_RR but your process
is still getting interrupted by other things?
Mikael Nordman
Even Linux RT processes need to let the kernel schedule normal
prioritised processes otherwise the system will appear to hang.
Defragmentation and bad device drivers may then may block interrupts for
tens of milliseconds.
You need to use a non-fragmenting memory allocator in order to get
decent real time performance. Typically found in an RTOS.
If there is an incoming data stream requiring hard real time attention,
it is best to use a dedicated processor with a bare embedded Forth or an
RTOS. If that is not enough you will need to use an FPGA or other HW
solution. Linux can then be used for the user interface, communications
and database.
Mikael
--
http://flashforth.sf.net
MarkWills
Where is the data coming from? Ethernet port? Serial port? Analogue
IO?
If it serial, then speed won't be an issue, even with a complex OS
like Linux, since it's easy capable of running a 1 mega bit serial
port. I doubt very much if your data source can sustain that data-rate
constantly.
One more thing: If speed is *really* an issue, then you don't want to
be using the BIOS for your IO as you mentioned in your first post,
you'll want to be doing it yourself in hand coded assembler.
Regards
Mark.
Tarkin
Oddly enough, I'm in the alpha stages of coding this exact thing.
My research had shown that ciforth and ForthOS were the only
readily-available, non-commercial protected-mode x86 forths
out there. The author's notes on ciforth had some dire warnings;
ForthOS has a dependency on GRUB I don't care for.
Since I like learning about wheels, I decided to try my hand
at a standalone, protected-mode x86 forth.
So far, I've got a floppy bootloader working*, and a strange
microkernel blob that displays 'TASK A' and 'B TASK',
the contents of the Global Descriptor Table, and a countdown
all on the screen (the countdown is the output of a PIT
interrupt service routine).
Is yet possible? Oh yes. 'What one fool can do...'
And this fool has gotten from boot to flat, 32 bit
protected mode.
*works in emulation, real h/w testing planned for this week.
HTH,
Tarkin
Ivan Tikhonov
> On Jun 19, 4:07 am, "Thomas D. Dean" <tomd...@speakeasy.org> wrote:
Have you looked at colorforth? (http://colorforth.com)
MarkWills
Sounds good Tarkin, keep us informed!
Mark
Tarkin
egads, glaring omission on my part.
Yes, I worked with colorForth and variants for a while.
I couldn't get over the keyboard.
TTFN,
Tarkin
Ivan Tikhonov
> Yes, I worked with colorForth and variants for a while.
> I couldn't get over the keyboard.
> Tarkin
You can modify it.
MarkWills
Hi Tarkin,
I haven't got around to trying colorForth yet on my PC, but I believe
the latest version supports normal QWERTY keyboard layout.
Mark
Jeff Fox
> I haven't got around to trying colorForth yet on my PC, but I believe
> the latest version supports normal QWERTY keyboard layout.
The last public release has QWERTY in yellow by default. You
have to press a key in the editor to turn it into a white comment
and recompile with WARM to get DVORAK keyboard operation.
qwerty/dvorak, stand-alone/hosted, blocks/files, and
shannon/ascii/html utilities addressed most of the
issues (excuses) people had so long ago.
Best Wishes
Stephen J. Bevan
> Even Linux RT processes need to let the kernel schedule normal
> prioritised processes otherwise the system will appear to hang.
No they don't, and yes the result is that if your RT process spins
then the system will appear to hang if you only have one CPU. That's
why the default under Linux is to only give RT 95% of the CPU, getting
100% requires changing the default. Since the OP didn't give any
information about what the performance requirements, my question was
an attempt to elicit what had been done with Linux before arriving at
the conclusion it was not suitable. I was expecting either "No I
didn't try that" or "Yes, did that and still have a problem because
..." which would provide some details of the problem.
Rabbit
All well and good. Not to chastise, but, for being science minded you
did not give anyone enough data to forge a real solution. Hmmm, guess
all the diverse posts indicate that.
Let's try this:
A boot-able device - floppy.
A bunch of storage - 70Gb HD (modern fast buffered interface to be
this size).
Enough program memory to calculate rocket launchings - 512Mb.
Hello - Processor type and speed???????
Now the rest is required:
1) Type of data being sampled.
2) Total samples per second, real or desired.
3) Are there more than one kind of data being acquired?
4) Size of sample data - like 16 bits per as the sample is a 12 bit a/
d.
5) Is the sample data collected to be processed in any way - like real
time plotting, etc?
6) Does the sampling device or interface require lots, or any,
application hand holding?
or
7) Do we just snag it, store it, process later?
however - and THE most important - disregarding all prior
8) WHAT PC INTERFACE IS THE SAMPLED DATA COMING IN ON? (NIC, async,
bus card, EPP - what?)
Number 8 is the lynch-pin, determining the actual capability of any
platform configuration, the other six items really only are used in
suggesting data handling.
You'll get a real answer that works if you inform us as to 1 thru 8
plus uP Hz and type.
Cordially,
Rabbit
Howerd
Could you post a link to this latest version of colorForth?
It doesn't seem to be available from www.colorforth.com...
TIA,
Howerd
Josh Grams
> Could you post a link to this latest version of colorForth?
> It doesn't seem to be available from www.colorforth.com...
Jeff's release announcement to the cf e-mail list is here:
http://www.strangegizmo.com/forth/ColorForth/msg02570.html
Download is ftp://ftp.ultratechnology.com/ColorForth2.0a.zip
--Josh
Howerd
Thanks for the links.
Interesting stuff, but there's no _source_ for the system I suppose...
Regards
Howerd
Albert van der Horst
MarkWills <markrob...@yahoo.co.uk> wrote:
>On Jun 19, 9:07=A0am, "Thomas D. Dean" <tomd...@speakeasy.org> wrote:
>> I am interested in using/developing a stand alone forth for use as a
>isk.
>>
>> I used a system at SLAC, developed/maintained by Connie Logg on an
>> into an interactive session.
>>
>> Initially, I have a AMD-PC with an ASUS motherboard, 512MB RAM, floppy
>> and 70G disk.
>>
>> I want to boot a system initally from floppy for development and later
>> from the hard disk.
>>
>> I want to use BIOS I/O as much as possible.
>>
>> flat, 32-bit mode?
>
>Where is the data coming from? Ethernet port? Serial port? Analogue
>IO?
(I no longer have the original post. Replying on Markwills.)
You can do that, standalone and even in MSDOS, switching back
and forth to real mode for system calls. ("Int 11" in Gate parlance)
Real working code examples on my site below.
Use the generic system on Linux, and make a runnable binary,
or just borrow code snippets.
>
>Regards
>
>Mark.
Groetjes Albert
--
w
--
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