• Please review our updated Terms and Rules here

a forth portable

Re: a forth portable

vic user said:
i never knew there was a computer out there that used forth as much as it does:

http://www.old-computers.com/museum/computer.asp?st=1&c=877

has anyone used, has, no more about this computer?

chris

Oh no, don't get CP/M User started! (We don't know if he's had his medication today 8)). He can rave for hours about the wonders of the Jupiter Ace, a UK-made computer with forth in ROM...

--T
 
vic user said:
sorry terry but,
now i really want to know more! :)

i no nothing of the jupiter ace.

chris

I think I'll let CP/M U respond to this one. He is, after all, our resident expert on 'em. All I know is what I read on the web, and you can dig up all that info with any search engine. I do know that they fetch a pretty handsome price whenever they do come up on eBay.

--T
 
Jupiter Ace looks like a ZX80, but with rubber keys like the Spectrum. This is because they were designed by the same guy, and I also think the users' manuals were written (or edited) by one guy only, so they are quite alike in clearity. While ZX80/81 is black text on white background, I think the Jupiter operates in reverse video.

Some years ago I read about a guy developing a Forth environment for Gameboy, and he had managed to load the ROM and boot halfways into an environment, but then it crashed. Not sure why he wants a Forth environment, but maybe he was planning to auto-load some software written in Forth utilizing Gameboy hardware. It probably is cool, but I would have preferred a Forth environment on a PC which could byte-compile your program into machine code to load into the Gameboy...

Sun's SPARC machines have a boot PROM environment which resembles Forth (some guy even wrote a Breakout program to run in the boot PROM, but some primitive to draw graphics was missing), and I think that the portable SPARC-book might have included this boot environment too. In that case, it is yet another portable Forth-like computer! :)
 
I just don't trust the whole forth-in-ROM concept. I always thought the whole forth thing was that it's an extensible language, in which the user can write his own primitives to add commands to the basic kernel of the language. How does this work with ROM-based software? Does the Jupiter Ace store user-extensions on cassette tape, or what? (There goes forth's speed advantage, eh?)

--T
 
I was reading a bit about Forth, yesterday, and there was a mention that the creator was not pleased with a version of Forth that came out, as he said it went against the spirit of what he intended Forth to be.

I wondert if this is related to your comment Terry?

Chris
 
Re: a forth portable

"Terry Yager" wrote:

>> i never knew there was a computer out there that used
>> forth as much as it does:

>> has anyone used, has, no more about this computer?

> Oh no, don't get CP/M User started! (We don't know
> if he's had his medication today 8)). He can rave for
> hours about the wonders of the Jupiter Ace, a UK-made
> computer with forth in ROM...

Medication today? The Jupiter Ace is a one of a kind, very
rare, but occasionally shows it's face. There's an emulator
for this machine though (which isn't too bad) & some
commercial software (mostly games written in FORTH).
Unfortunately, I can't remember which FORTH it was, the
machine came out around 1983 (which was one standard
of FORTH), but the Ace used FORTH-79.

Unfortunately the creator was hoping the Ace would have
been big with it's built-in FORTH, but in a way it was up
against CP/M which had FORTH a plenty for it, the Ace
while it's Z80 based, didn't run CP/M, lack of Disk drive &
RAM were the main concerns. Also with the success of
BASIC in just about every other machine in it's time &
the simplicity of it, the Ace failed due to the lack of interest
of FORTH. That doesn't mean it was a terrible language, it
can be quite a powerful language when subroutines are
built into the system. The language itself looks daunting
to learn, which is why BASIC won hands up.

Hardware wise, the Ace can be closely compared with a ZX81,
except the language seems to seperate them & are worlds
apart. Unfortunately, I don't know how Assembly is access
via a Ace, but it might be interesting to see if an assembly
program written in a ZX81 would work on an Ace.

Cheers,
CP/M User.
 
"Terry Yager" wrote:

> I just don't trust the whole forth-in-ROM concept. I always
> thought the whole forth thing was that it's an extensible
> language, in which the user can write his own primitives to
> add commands to the basic kernel of the language. How
> does this work with ROM-based software? Does the Jupiter
> Ace store user-extensions on cassette tape, or what?
> (There goes forth's speed advantage, eh?)

Personally, I think it's rather Cool having FORTH-in-ROM, cause
it shows that it can be a system in itself. FORTH is more than
just a Language, it's a systems language, the idea being with
the compiler isn't to compile programs for use in CP/M or for an
assembler to compile, but code which is compiled within for
FORTH to run. Having subroutines is what makes it powerful &
since they sit on the stack, they ready for use (unlike BASIC
which has to interpret the code & then run it). The ACE uses RAM
to store the routines hence an area called the stack, personally
I don't have a real Ace to tell you how the programs were saved
to tape & the emulator has a different way of saving the
programs as such it saves the contents of the memory which
captures the routines used by the program.

Cheers,
CP/M User.
 
"vic user" wrote:

> I was reading a bit about Forth, yesterday, and
> there was a mention that the creator was not
> pleased with a version of Forth that came out, as
> he said it went against the spirit of what he
> intended Forth to be.

Charles Moore (the creator of FORTH) created this
language because he was unhappy with the way
the other languages (of the time) worked, I know
this for a fact.

I'm not sure which implentitation of FORTH he's
unhappy with, but I would say the Ace follows his
guidelines, later versions of FORTH would perhaps
go against the trend & offer routines for this
language, this would then me something that
Charles wouldn't of had in mind.

Cheers,
CP/M User.
 
Actually, isn't everyone who uses forth running a slightly different dialect than everyone else's version, the language being extensible and all? Could that have something to do with it's lack of popularity, the non-standardness of it? (I do know that forth's followers are very loyal to it, even to this day).

--T
 
"Terry Yager" wrote:

> Actually, isn't everyone who uses forth running
> a slightly different dialect than everyone else's
> version, the language being extensible and all?

There are many versions of this Language/System
going around or indeed written, as well as being
quite a few standards going around (like FORTRAN).

> Could that have something to do with it's lack of
> popularity, the non-standardness of it? (I do
> know that forth's followers are very loyal to it,
> even to this day).

Nowadays people have adapted a standard of FORTH
which is determined by one of the earlier standards,
FORTH-83 I believe is what they use. Which means
that previous versions of FORTH going around such
as the one for the ACE (FORTH-79) are classed as
outdated.

I can also say for a fact that back in 1984 it was
possible to incorporate Assembly into FORTH.
Assembly as we all should know, is a language of
the CPU, which makes it harder for a program to be
portable (not impossible - just harder)!

Cheers,
CP/M User.
 
Interesting. I kinda thought FIG-FORTH was the most popular standard (but IIRC, it's based on the -83 version). I used to fool around with it a little on my KayPro. Not actually writing my own code, just compiling and running other people's stuff. It is kinda wierd, especially if yr not acustomed to using RPN (not an H-P calculator fan).

--T
 
Re: secondary storage device; while tape may be slower and less random accessible than a disk, is it such an odd media to store Forth (and other) programs on? I realize that you want an editor environment and keep screenfuls of definitions which will become tricky using tape and little RAM, but is that the only viable way to work with the language?

FWIW, both Commodore and third-party developers released Forth on cartridge (ROM plugin) both for VIC-20 and C64. The VIC cartridge included a 3K RAM expansion to give a little more workspace (a total of 6.5K). It was developed with disk access in mind (editor disk sold separately), but some tape routines were included as well.

Re: Z80 machine code program on the Jupiter Ace - I would assume that memory maps etc are different, but maybe software which doesn't make ROM calls would work. Sounds more like a generic Z80 program though.
 
The prime law of CP/M (or any portable OS) is: A system call is a system call, is a system call, or to paraphrase: Assembly language is assembly language, is assembly language. There's no reason pure generic Z80 code wouldn't work on the Jupiter Ace. That's probably the language the FORTH is written in anyways.

--T
 
Ayep, that is what I meant. Machine code which doesn't make any assumptions (or at least no assumptions which can not be looked up by reviewing hard coded memory positions) about the target machine. I know too little about the Z80 to know if there are certain memory addresses which have to contain specific information, like memory address of graphics memory or I/O chips, stack pointer, maybe even some typical ROM calls.

In an operating system, I believe you should differ between system (OS) calls and ROM (BIOS) calls, as you should not bypass the system anyway. Since neither ZX81 nor Jupiter does CP/M (AFAIK - I may be wrong here), they would not bother about a common jump table or otherwise. Perhaps sir Clive would not even have liked if a machine, designed by the same people who designed his, even was partitially firmware compatible...
 
carlsson said:
Ayep, that is what I meant. Machine code which doesn't make any assumptions (or at least no assumptions which can not be looked up by reviewing hard coded memory positions) about the target machine. I know too little about the Z80 to know if there are certain memory addresses which have to contain specific information, like memory address of graphics memory or I/O chips, stack pointer, maybe even some typical ROM calls.

As I understand the Z80, it isn't p'ticular about such things. Other processors that I use regularly are, like the Hitachi 6301, which is more than just a microprocessor. It is a single-chip microcomputer, with it's own memory space (RAM & ROM) on-chip, as well as it's own I/O ports. Writing to or reading from certain memory locations on that chip will obviously access that memory or I/O port.
With CP/M, system calls are sacred in that they mustn't be changed, and if they are, then it's no longer CP/M. The system calls are what make CP/M portable among many different types of hardware. The system call will do exactly the same thing on any hardware it's run on. The differences in hdwre are accounted for in the BIOS, which is different for each different combination of hardwares that the different machines use. The TRS-80, which also uses a Z80, is a whole 'nother animal. It uses memory-mapped I/O, in which certain memory locations are for certain purposes. F'rinstance, if you want to write something to the screen, you don't have to use a system call, you can just write to a specific memory address and that is where the screen's memory lives, so writing to that address automatically writes on to the screen. That's the big reason they had so much trouble porting CP/M to the Trash-80, and even when they did port it over, it wasn't-quite-the-same.
In an operating system, I believe you should differ between system (OS) calls and ROM (BIOS) calls, as you should not bypass the system anyway. Since neither ZX81 nor Jupiter does CP/M (AFAIK - I may be wrong here), they would not bother about a common jump table or otherwise. Perhaps sir Clive would not even have liked if a machine, designed by the same people who designed his, even was partitially firmware compatible...

In some computers there is little or no difference between the two. When the OS lives in ROM, then you have to CALL the ROM to CALL the system (like the TRS, running in BASIC mode, without TRSDOS being loaded). CP/M, OTOH, keeps it's system on disk, where it is read into memory at boot-time. The OS is always memory-resident, but it's modular design allows certain portions to be overwritten by the user's program, provided the program handles the functions of the OS that have been over-written. The BIOS is the only part that cannot be overwritten, except by another BIOS version, which still must be compatible with the hardware. The IBM-PC & compatibles OTOOH, keep thier BIOS in ROM, and the BIOS must be the same on every different set of hdwre it's run on. That's what made it so difficult (at first) for other manufacturers to clone the IBM, without stepping on IBM's copyrights.
Well, I guess that sufficiently confuses the issue...ok, daddy, I'll shut up now...

--T
 
From "Terry Yager":

> ...That's the big reason they had so much trouble porting
> CP/M to the Trash-80, and even when they did port it over,
> it wasn't-quite-the-same...

Trash-80?!?

CP/M User.
 
"carlsson" wrote:

> In an operating system, I believe you should differ
> between system (OS) calls and ROM (BIOS) calls,
> as you should not bypass the system anyway. Since
> neither ZX81 nor Jupiter does CP/M (AFAIK - I may
> be wrong here), they would not bother about a
> common jump table or otherwise.

Just on that, the ZX81 is quite an interesting machine &
I know it's had heaps added to it since my book is 20
years old. However, even back then it could have 64k
available for it. I don't want to knock this machine, but
I was just wonderning if 80x25 text is available for it?
I guess CP/M could be made to work in 32x24 if that
was important. The only other issue I believe is the
character set the ZX81 uses, I don't believe it's ASCII,
I don't know how that'd tie in with CP/M. Since I've
seen CP/M programs written to reprogram keys, it's
easily applied for the change. I guess the only thing
remaining is for someone to port CP/M to a ZX81 with
those modifications?

Cheers,
CP/M User.
 
Back
Top