How to write software for the MARK I Forth computer?

[Manuel Rodriguez]

The MARK I forth computer http://www.aholme.co.uk/Mk1/Architecture.htm is
a homebrew project build with TTL logic chips. It contains stackmachine
based microcode on the hardware level. I like the idea for building the the
hardware from scratch. And as far as i can see the inventor of the MARK I
has produced a working system. What is missing right now is the software
side. Perhaps this would become more demanding that wiring the cables?

Sure, in the literature many examples are given how to program the Forth
system for a new system. The Jonesforth tutorial is a famous example
in doing so. But what comes then? I mean, without an operating system
the best computer is not able to do anything. Is it possible to program
a Forth operating system from scratch, or has the forth community find
a way around this task with a programming technique nobody is aware of
it? My bet is that real Forth coders don't write the software by itself
but using program synthesis to generate the sourcecode with recursive
evolution. Am I right?

[hughag...@gmail.com]

An operating system deals with the I/O. You would have to have some I/O ports before the concept of an OS would make any sense.
You asked: "What comes next?" The answer is, you have to think of some task that your computer could do and provide I/O ports that do this, then program it.
You probably still don't need an OS --- your program would just access the I/O ports directly.

You don't have interrupts; any program you write will need a paced-loop. So, the first I/O peripheral you need is a timer to pace the paced-loop.

Apparently you have a UART already, and you have KEY and EMIT working with it.
The computer just sits and waits for KEY to give it some data. When it gets a full line of data, it interprets it.
You could have your paced-loop poll the UART and fill up the buffer, then it stops what it is doing and interprets the line when it is full.
In the meantime, it does some task on every iteration through the paced-loop.

A possible task that it could do would be controlling the irrigation for a lawn/garden by turning on/off the solenoid-controlled valves.
Your computer should work as well as the control box you would buy at Home Depot or a landscaper-supply store --- might even be easier to program.
The downside is that you don't have a low-power sleep mode ---
you will burn up a lot of electricity waiting for the big moment when a valve needs to be flipped or somebody sends some data down the UART.
You might be converting so much electricity into heat that you will not only be irrigating your garden, but you will also be heating your home.

Have fun! Let us know what you come up with...

Maybe later you can upgrade to using DXforth on a Z80 to control your irrigation system. ;-)

[dxf...@gmail.com]

DX-Forth is for desktops. For controller apps I'd suggest something
rom-able (Camel Forth or SL5 :)

[Manuel Rodriguez]

Am Montag, 29. Oktober 2018 01:18:44 UTC+1 schrieb dxf...@gmail.com:
> DX-Forth is for desktops. For controller apps I'd suggest something
> rom-able (Camel Forth or SL5 :)

I've watched the websites of all the three projects: DXforth, Stackworks
Forth and Camel Forth. All these systems look very similar to the CP/M
operating system which was introduced in the 1970s, early 1980s. That means,
they are providing low level hardware access and it's possible to program
on top of the Operating system dedicated applications. And exactly this
seems to be a bottleneck. How long does it take to expand a CP/M like
operating system into a workstation computer which has connection to the
Internet, is able to run Windows32 programs or provides a webbrowser?

Software engineering has nothing to do with stackcomputers or IO-ports, and
the task can not be solved with DXforth. Software engineering implies man
years, lines of codes, version control systems and compiler languages. It
is not an technical issue which can be solved by the engineers, it is
a management problem. Or to make it short: It's not possible to extend
DXforth into a working operating system. Not because of technical
constraints, that something is wrong with the wires or with the inner
loop of the interpreter, but because of economical / project management
reasons. That means, if a single person sits down and is trying to write
a large scale codebase he will not be ready in 100 years.

[Bernd Linsel]

http://www.ultratechnology.com/1xforth.htm

--
Regards,
Bernd Linsel

[hughag...@gmail.com]

I think it is possible for Ed (the DXforth guy) to write a better OS than CP/M for the Z80, and do the job in significantly less than 100 years.
Actually, it would be impossible for him to write a worse OS than CP/M. ;-)

Getting people to use your OS is the problem. How many people use Menuet?

Anyway, this doesn't really have anything to do with the Mark 1 computer.
As I said, I doubt that you need an OS at all. Are you really going to have device-drivers for its I/O??? Just access the I/O ports directly.

I don't think the Z80 had a low-power mode.
Maybe one of the modern versions, such as the Rabbit or eZ80 do though.
It might be possible to upgrade DXforth for one of these processors, and make it run without benefit of CP/M.

I actually own a Kaypro-10 --- I wrote a program in Turbo Pascal for it.
I got the computer and a box of software packages from a thrift store for a few dollars in the 1990s.

[Paul Rubin]

Manuel Rodriguez <a...@gmx.net> writes:
> How long does it take to expand a CP/M like operating system into a
> workstation computer which has connection to the Internet, is able to

> run Windows32 programs or provides a webbrowser? ... It's not possible

> to extend DXforth into a working operating system.

I don't think anyone proposed running Windows32 programs or web browsers
on the MARK I Forth computer or under dxforth. Writing a simple OS in
Forth is very feasible and it has been done many times.

Example: http://sources.vsta.org/forthos/

[dxf...@gmail.com]

As I understand it the MARK I comes with a rom-resident Fig-forth with
KEY and EMIT pointing to a serial port. There is an unused 8255 I/O chip
in the schematics that you should be able to program using C@ C! in a
similar manner to the UART.

[Manuel Rodriguez]

Am Montag, 29. Oktober 2018 19:27:12 UTC+1 schrieb Bernd Linsel:
> http://www.ultratechnology.com/1xforth.htm

Some of my question were answered in the Chuck Moore interview. He
explained, that good software is small software which has only a little
amount of codelines.

Quote: “For instance, how large should the TCP/IP stack be? But I should
not be very big, a kiloword.”

The problem is, that Moore is probably right. What he describes is a
software / hardware combination much more efficient than what is known
today. And I don't like such kind of revolution. Moore is a high tech
heretic and we are well advised to not follow him.

[Paul Rubin]

Manuel Rodriguez <a...@gmx.net> writes:
> Quote: “For instance, how large should the TCP/IP stack be? But I
> should not be very big, a kiloword.” The problem is, that Moore is
> probably right. What he describes is a software / hardware combination
> much more efficient than what is known today.

It seems doable. The J1 IP library is maybe a few hundred words. It's
for a camera application so it doesn't need or have TCP but TCP/IP could
probably be done in a kiloword of F18-like code (3-4 MISC instructions
per word).

http://excamera.com/sphinx/fpga-j1.html

[Manuel Rodriguez]

Am Dienstag, 30. Oktober 2018 10:10:06 UTC+1 schrieb Paul Rubin:
> The J1 IP library is maybe a few hundred words. It's
> for a camera application so it doesn't need or have TCP but TCP/IP could
> probably be done in a kiloword of F18-like code (3-4 MISC instructions
> per word).

That's right, and here comes the problem. IT experts are trained to update
their software regularly, especially if the device is connected to the
internet. That means, the admin is trying to run the “dnf update”
command from the Fedora operating system on the PC which needs 10 Gigabyte
in size. A TCP/IP stack with a few hundred words, which is probably error
free, doesn't need this kind of update procedure. So, the admin doesn't
know what to do with his free time and he can argue, that he can read a
book about Artificial Intelligence which will make things more complicated.