Suggestions for a ROMable 8080 FORTH?

[Richard]

[Please do not mail me a copy of your followup]

This is for an embedded system with a serial port but no other
standard peripherals. So I don't need (or want) things like disk I/O,
editor, etc., just a ROMable FORTH implementation where I can adjust
the various areas of RAM based on the device's memory map.

Any suggestions? I looked at forth.org FIG-Forth implementations, but
the one they have for 8080 says it is not ROMable.

Thanks!
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[dxforth]

On Tuesday, 24 September 2019 05:22:14 UTC+10, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> This is for an embedded system with a serial port but no other
> standard peripherals. So I don't need (or want) things like disk I/O,
> editor, etc., just a ROMable FORTH implementation where I can adjust
> the various areas of RAM based on the device's memory map.
>
> Any suggestions? I looked at forth.org FIG-Forth implementations, but
> the one they have for 8080 says it is not ROMable.
>
> Thanks!

A couple old references.

1. Forth Dimensions v4n4 describes putting 8080 Fig-Forth into ROM.

2. ROMable 8080 & Z80 Stackworks SL5 (formerly commercial, now GPL):

http://www.softsector.aplaholm.se/cpm/sl5/

[hughag...@gmail.com]

Doesn't your DXForth system run on CP/M?
Is that 8080 or Z80?
It seems like a ROMable 8080 Forth system would be right up your alley.

Why would anybody use an 8080 for an embedded board?
That was a bad idea in the 1980s too.
The 65c02 was popular, as were the MC68xx chips.
The Z80 may have gotten some use, although I never heard of it.

For the most part, the 8051 dominated the embedded board world.
Previously, there was the 8048 (I don't recall when the 8051 emerged).
Nowadays we still have 8051-derived chips, such as the C8051.

[dxforth]

Gave up all that when I left electronics.

[Richard]

[Please do not mail me a copy of your followup]

hughag...@gmail.com spake the secret code
<89bd839a-3d2c-4f15...@googlegroups.com> thusly:

>Why would anybody use an 8080 for an embedded board?

This is for a retro computing project. The system design is fixed,
but changing the ROM is possible.

[Richard]

[Please do not mail me a copy of your followup]

dxforth <dxf...@gmail.com> spake the secret code
<5ab30874-edde-42ef...@googlegroups.com> thusly:

>1. Forth Dimensions v4n4 describes putting 8080 Fig-Forth into ROM.

I'll see if I can dig that up electronically or maybe find a dead tree
edition in someone's collection.

>2. ROMable 8080 & Z80 Stackworks SL5 (formerly commercial, now GPL):
>
> http://www.softsector.aplaholm.se/cpm/sl5/

Ooh, looked at the manual for this and it seems really promising:

"Subsets of the development system can be created using a minimum
of 2K bytes of storage. Thus, a complete and user-oriented
package can be developed at a high-level, debugged, and then
implemented in EPROMs or very small memory systems."

[hughag...@gmail.com]

I think they mean 2KB of RAM. Presumably the EPROM is 8KB or 16KB.
You could have an on-chip Forth development system, but the dictionary
would be in EPROM so it won't allow you to make new definitions.
It would allow you to have a command-line for debugging.
Your program is going to be pretty small because the dictionary
headers are taking up a lot of the EPROM, plus you have a lot of
compile-time code that takes up space but isn't used at run-time.

For a small-memory system like this, I would use a cross-compiler.
This way your application program can use the full 8KB or 16KB EPROM.

One of the few things that I know, is how to write a cross-compiler.
This skill is pretty much obsolete because it is only useful for
small-memory systems such as your retro 8080 board.
Modern boards have an ARM Cortex and megabytes of memory,
so they can support a traditional on-chip Forth development system.
There are small boards (such as with the MSP-430) that have a small
memory, although they still have enough FLASH for an on-chip Forth.

Do you have an application program in mind?
It is not meaningful to worry about the question of what
development system to use, if you don't know what the goal is.

BTW: There are forums devoted to 6502 and Z80 nostalgia, and I've heard of
CP/M nostalgia (I have a KayPro-10, although I don't play with it anymore).
I've never heard of anybody being nostalgic for the 8080. Nobody liked it.
There is a reason why the Z80 upgrade was popular!

Forth is inefficient on the Z80 if you use the IX or IY registers
as a data-stack, because IX and IY instructions are very slow.
I thought of a design for a Z80 Forth that used the SP register
as the data-stack, but used IY as the return-stack.
This could be reasonably efficient. I never implemented it though.
Forth on an 8080 is going to be bloated and ugly because you don't have
enough registers, or addressing-modes. I wouldn't do it. Not fun!

[Cecil - k5nwa]

On 9/24/2019 2:19 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> dxforth <dxf...@gmail.com> spake the secret code
> <5ab30874-edde-42ef...@googlegroups.com> thusly:
>
>> 1. Forth Dimensions v4n4 describes putting 8080 Fig-Forth into ROM.
>
> I'll see if I can dig that up electronically or maybe find a dead tree
> edition in someone's collection.
>
>> 2. ROMable 8080 & Z80 Stackworks SL5 (formerly commercial, now GPL):
>>
>> http://www.softsector.aplaholm.se/cpm/sl5/
>
> Ooh, looked at the manual for this and it seems really promising:
>
> "Subsets of the development system can be created using a minimum
> of 2K bytes of storage. Thus, a complete and user-oriented
> package can be developed at a high-level, debugged, and then
> implemented in EPROMs or very small memory systems."
>

Forth.org has a PDF version of all the Forth Dimensions magazine.

< http://forth.org/fd/FD-V04N4.pdf >

--

Cecil - k5nwa

[hughag...@gmail.com]

On Tuesday, September 24, 2019 at 2:13:42 PM UTC-7, Cecil - k5nwa wrote:
> Forth.org has a PDF version of all the Forth Dimensions magazine.
>
> < http://forth.org/fd/FD-V04N4.pdf >

I skimmed though that issue. Those were the good old days of Forth!
Lots of vendors, so a lot of diversity and original thinking.
Most of the articles contained code, unlike now when the ANS-Forth cult
almost never write any code, but deliver only hot air.
Only one article discussed a standardization issue (making TRUE -1 ).

It would have still been possible to save Forth at that time.
What was needed was a viable Forth Standard.
Forth-79 was very weak and largely ignored due to being inadequate
for writing commercial programs. For a Forth Standard to be viable
it would have needed to provide features for writing programs,
but yet be simple so as to not restrict creativity.
I still think that this is possible --- 2019 is very late though.

I liked Leo Brodie's cartoon. :-)

I didn't find any advertisement from Hartronix (now Testra) for their
bit-slice Forth chip --- that must have come one or two years later.
I never worked on that chip, so it is not directly interesting to me.
That was a "scrap of brilliant era of Forth" though (Ilya's term).

[David Schultz]

On 9/23/19 2:22 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> This is for an embedded system with a serial port but no other
> standard peripherals. So I don't need (or want) things like disk I/O,
> editor, etc., just a ROMable FORTH implementation where I can adjust
> the various areas of RAM based on the device's memory map.
>
> Any suggestions? I looked at forth.org FIG-Forth implementations, but
> the one they have for 8080 says it is not ROMable.
>
> Thanks!
>

eForth works pretty well from ROM. I don't know if there is an 8080
version but it shouldn't be too hard to create one.

I see a Z80 version here: http://www.forth.org/eforth.html


--
https://web.archive.org/web/20190214181851/http://home.earthlink.net/~david.schultz/
(Web pages available only at the Wayback Machine because Earthlink
terminated that service.)

[hughag...@gmail.com]

On Tuesday, September 24, 2019 at 3:39:51 PM UTC-7, David Schultz wrote:
> eForth works pretty well from ROM. I don't know if there is an 8080
> version but it shouldn't be too hard to create one.

Just off the top of my head, here is a simple register map for the Z80.
I'm assuming here DTC or ITC --- STC is also possible though.
I can provide NEXT code if anybody doesn't know how this would work.
I'm not allowing for local variables --- that is also possible though.
This design has the top-of-stack of the return-stack in a register
to boost the speed of DO loops --- may be more important than locals.
The choice of design depends upon the kind of applications expected.

A ---- general purpose
BC --- top-of-stack (return-stack)
DE --- general purpose
HL --- top-of-stack (data-stack)
IX --- instruction pointer
IY --- return-stack pointer
SP --- data-stack pointer

You said that it "it shouldn't be too hard to create" an 8080 Forth.
What register map would you use for that? Show us how easy it is!

Here are your registers:
A ---- ???
BC --- ???
DE --- ???
HL --- ???
SP --- ???

[Richard]

[Please do not mail me a copy of your followup]

hughag...@gmail.com spake the secret code

<981fb44d-668f-40bb...@googlegroups.com> thusly:

>On Tuesday, September 24, 2019 at 12:19:33 PM UTC-7, Richard wrote:
>> dxforth <dxf...@gmail.com> spake the secret code
>> <5ab30874-edde-42ef...@googlegroups.com> thusly:

>> > http://www.softsector.aplaholm.se/cpm/sl5/
>>
>> Ooh, looked at the manual for this and it seems really promising:
>>
>> "Subsets of the development system can be created using a minimum
>> of 2K bytes of storage. Thus, a complete and user-oriented
>> package can be developed at a high-level, debugged, and then
>> implemented in EPROMs or very small memory systems."

>I think they mean 2KB of RAM.

I think you should look at the manual :-). It's talking about the
code space, e.g. ROM space, required.

[hughag...@gmail.com]

On Tuesday, September 24, 2019 at 9:22:52 PM UTC-7, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> hughag...@gmail.com spake the secret code
> <981fb44d-668f-40bb...@googlegroups.com> thusly:
>
> >On Tuesday, September 24, 2019 at 12:19:33 PM UTC-7, Richard wrote:
> >> dxforth <dxf...@gmail.com> spake the secret code
> >> <5ab30874-edde-42ef...@googlegroups.com> thusly:
> >> > http://www.softsector.aplaholm.se/cpm/sl5/
> >>
> >> Ooh, looked at the manual for this and it seems really promising:
> >>
> >> "Subsets of the development system can be created using a minimum
> >> of 2K bytes of storage. Thus, a complete and user-oriented
> >> package can be developed at a high-level, debugged, and then
> >> implemented in EPROMs or very small memory systems."
>
> >I think they mean 2KB of RAM.
>
> I think you should look at the manual :-). It's talking about the
> code space, e.g. ROM space, required.

Okay --- I'll download it and read it later.

My recollection from the bad old days (low memory systems) is that
ROM or EPROM was usually big, but RAM was usually small.
For example, the Vic-20 had only 5KB of RAM, but a big ROM for BASIC.
I bought a 16KB RAM expansion, which I was pretty happy about.
I had a multi-slot expansion card, so I could also run HES Forth.
That 5KB was really only good for machine-language games in cartridge.

When you say that you are doing a "retro computing project" do you mean
that you are using an old board from those days, or that your are
building your own board now?
I don't understand the idea of using old hardware, as it is very slow.
Using a retro processor such as the Z80 in soft-core is interesting though.

If you are building a board now, but want a retro processor, I would
really go with the Z80 rather than the 8080 so you have enough registers.
It would be possible to get a soft-core Z80 that has 64KB internal,
and runs significantly faster than the old 4 Mhz. Z80 chip, likely
also with more efficient instructions (not those 19-cycle whoppers
for accessing the IX and IY data). Such an FPGA is likely available.
Such an FPGA would actually be useful for real applications.
There likely are faster processors, such as the MSP-430, but the
Z80 is still realistic for modern use --- the 8080 is not realistic.

Especially interesting would be a soft-core Z80 that can run legacy
Z80 machine-code, but which has some extra instructions for
supporting Forth better than the old Z80 did, for new programs.
Even more interesting would be this idea done for the MC68000. :-)

[dxforth]

z80eforth by Ken Chen appears to be mostly 8080:

http://www.forth.org/eforth.html

; o Registers assigment:
; SP -- SP
; IP -- BC
; RP -- Memory
; UP -- Memory

I noted a number of Z80 OUT instructions that would need converting.

[hughag...@gmail.com]

You'll also need a calendar to benchmark it.

[dxforth]

Speed bottleneck is DTC NEXT and the Z80 version is no different
from 8080. The extra Z80 registers are of marginal help when
programming as few primitives have more than 3 parameters.

[Rick C]

On Tuesday, September 24, 2019 at 3:17:39 PM UTC-4, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> hughag...@gmail.com spake the secret code
> <89bd839a-3d2c-4f15...@googlegroups.com> thusly:
>
> >Why would anybody use an 8080 for an embedded board?
>
> This is for a retro computing project. The system design is fixed,
> but changing the ROM is possible.

There are a number of posters here who aren't actually very familiar with hardware or understand the whys and wherefores. The 8080 got widespread use in embedded systems because it was the first truly useful 8 bit micro on the market and quickly got market share. The 8080 software was upward compatible with the 8008 which was not nearly as well received, but did get attention and laid a foundation of use. So updating to the 8080 did not starting over to rewrite your assembly language code.

The Z80 was a better processor, mostly because of the instruction set improvements because Intel came out with the 8085 specifically for lower cost embedded applications which provided pretty much all the hardware improvements of the Z80 and a few extra.

The 8048 and 8051 were used in much more constrained systems since they had rather limited internal memory and once you start tacking on external memory the system cost quickly approached that of an 8085 system.

To what purpose will your retro board be used?

--

Rick C.

- Get 2,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

[Richard]

[Please do not mail me a copy of your followup]

Rick C <gnuarm.del...@gmail.com> spake the secret code
<e23edd01-0889-49d8...@googlegroups.com> thusly:

>To what purpose will your retro board be used?

This thread's already diverged enough, but suffice to say that the
original ROM is 8080 assembly. I'm investigating the practicality of
replacing the assembly with FORTH so that I can modify/extend the ROM
more readily.

[Rick C]

On Wednesday, September 25, 2019 at 11:54:37 AM UTC-4, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Rick C <gnuarm.del...@gmail.com> spake the secret code
> <e23edd01-0889-49d8...@googlegroups.com> thusly:
>
> >To what purpose will your retro board be used?
>
> This thread's already diverged enough, but suffice to say that the
> original ROM is 8080 assembly. I'm investigating the practicality of
> replacing the assembly with FORTH so that I can modify/extend the ROM
> more readily.

Ok, if you are worried about thread drift I guess you are new here. I won't bother you any further.

--

Rick C.

+ Get 2,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

[dxforth]

On Thursday, 26 September 2019 01:37:17 UTC+10, Rick C wrote:
> ...

> The Z80 was a better processor, mostly because of the instruction set improvements because Intel came out with the 8085 specifically for lower cost embedded applications which provided pretty much all the hardware improvements of the Z80 and a few extra.

AFAIK the 8085 came out after the Z80 - the former essentially a single-rail
8080. As previously mentioned the 8085 was processor of choice for embedded
apps by companies such as Siemens, apparently unconvinced of the Z80's
superiority in that role. For users the new Z80 instructions were a case
of 'user beware' as they could take more time to execute than the equivalent
8080 code. OTOH one could save space using Z80 code.

[hughag...@gmail.com]

DXForth is right about this.
Apparently, Rick Collins isn't "actually very familiar with hardware
nor understand the whys and wherefores."

The 8085 was used for micro-controllers.
The Z80 was mostly for small computers running CP/M.
The IX and IY registers had an indexed addressing-mode.
IX was usually for local variables, and IY for structs, neither of which
are important in micro-controllers that mostly do I/O.
The Z80 was also used in video game machines, although the 6809 was better.

The 8048 and later the 8051 killed the 8085 for micro-controllers.
They had instructions for accessing 1-bit variables, and so they were
useful in PLCs that primarily read 1-bit sensors and flip 1-bit switches.
There were versions of the 6502 that worked with 1-bit data,
so the 6502 persisted in micro-controllers. The Z80 got obsoleted
by the x86 for small computers, and CP/M got obsoleted by MS-DOS.