J1 forth processor in FPGA - possibility of interactive work?

Rickman,

> I'm not sure what he meant by "interactively define new words and 
> execute them".  Someone else, maybe in the Forth group, wanted to do 
> something like that where the basic instruction set could be extended by 
> compiling Forth.

You are overthinking things. What he meant was that he wanted a native J1
Forth system instead of the cross Forth system most projects were using.
So you would connect a terminal to the FPGA board and would see an "Ok"
prompt and then you could define new words by typing ": name ...." on
the terminal. You would also be able to try simple expressions like
"3 4 + ." and see immediately what they do.

With cross development you type in your program in some editor on your
PC, run the compiler and get a bunch of bits to be loaded into the FPGA
board. You turn on the FPGA board and see if it worked or not. If not,
you got back to the editor on your PC and start the whole cycle again.
This works, but it is not how Forth was meant to be used.

-- Jecel

On 6/13/2016 12:52 PM, Jecel wrote:
> Rickman,
>
>> I'm not sure what he meant by "interactively define new words and
>> execute them".  Someone else, maybe in the Forth group, wanted to do
>> something like that where the basic instruction set could be extended by
>> compiling Forth.
>
> You are overthinking things. What he meant was that he wanted a native J1
> Forth system instead of the cross Forth system most projects were using.
> So you would connect a terminal to the FPGA board and would see an "Ok"
> prompt and then you could define new words by typing ": name ...." on
> the terminal. You would also be able to try simple expressions like
> "3 4 + ." and see immediately what they do.
>
> With cross development you type in your program in some editor on your
> PC, run the compiler and get a bunch of bits to be loaded into the FPGA
> board. You turn on the FPGA board and see if it worked or not. If not,
> you got back to the editor on your PC and start the whole cycle again.
> This works, but it is not how Forth was meant to be used.

A target hosted Forth has it's advantages, but I still type my source 
into an editor on the PC and compile by downloading to the target rather 
than loading into a Forth crosscompiler which downloads it for me.  Not 
sure there is a huge advantage either way.  They seem pretty similar to 
me including the need to hit the reset button when I screw up bad enough.

You make it sound like the edit, compile, test loop is somehow much less 
useful when using a PC.  I got rid of my ADM-3A a long time ago.

-- 

Rick C

On Monday, June 13, 2016 at 4:21:21 PM UTC-3, Rickman wrote:
> You make it sound like the edit, compile, test loop is somehow much less 
> useful when using a PC.  I got rid of my ADM-3A a long time ago.

Compare developing a game in Basic on a Commodore 64 with creating the
same game on a PC, using a Basic-to-6502 compiler and downloading it to
the C64 to see if it works. Development is faster in the first option
while the resulting game will be faster in the second option.

What I am saying is that I don't like edit/compile/test loops but
prefer interpreted systems (or those that do a good job of pretending
to be interpreted - see Smalltalks with JIT compilation).

You are free to prefer compiled systems (most people do) but wzab seems
to have the same taste as me and was asking for an option to develop
interactively on the J1 processor itself.

-- Jecel

On 6/14/2016 3:52 PM, Jecel wrote:
> On Monday, June 13, 2016 at 4:21:21 PM UTC-3, Rickman wrote:
>> You make it sound like the edit, compile, test loop is somehow much less
>> useful when using a PC.  I got rid of my ADM-3A a long time ago.
>
> Compare developing a game in Basic on a Commodore 64 with creating the
> same game on a PC, using a Basic-to-6502 compiler and downloading it to
> the C64 to see if it works. Development is faster in the first option
> while the resulting game will be faster in the second option.

That is not at all clear to me.  Your example seems to be compiling 
native on one type of PC vs. cross compiling on another and transferring 
the executable.  I don't expect to have anything like mass storage on 
the target system, so the two options I have are using the PC for 
program storage or using the PC to cross compile.  I can download at 
nearly 1 Mbps today using the ubiquitous USB serial ports.  I don't 
perceive any difference in time of loading an executable vs. loading the 
program source.  Compile times are very fast as well.


> What I am saying is that I don't like edit/compile/test loops but
> prefer interpreted systems (or those that do a good job of pretending
> to be interpreted - see Smalltalks with JIT compilation).

You still have the loop, you think it is faster the way you are 
describing, but I use the same command line for testing.  I just use the 
PC as an editor.


> You are free to prefer compiled systems (most people do) but wzab seems
> to have the same taste as me and was asking for an option to develop
> interactively on the J1 processor itself.

That's fine if the J1 has facilities for the full development process. 
I can't remember the last time I used a target that was even close to 
being able to support a full development system other than the Raspberry 
Pi.  What sort of J1 hardware are you looking at?

-- 

Rick C

On Tuesday, June 14, 2016 at 5:16:08 PM UTC-3, Rickman wrote:
> > What I am saying is that I don't like edit/compile/test loops but
> > prefer interpreted systems (or those that do a good job of pretending
> > to be interpreted - see Smalltalks with JIT compilation).
> 
> You still have the loop, you think it is faster the way you are 
> describing, but I use the same command line for testing.  I just use the 
> PC as an editor.

"the same command line" might be the key to our differences. In the
native C64 Basic command line I can type something like

PRINT (MADD/4)+1

and see the result. In a cross compiling Basic I can't do that.

> > You are free to prefer compiled systems (most people do) but wzab seems
> > to have the same taste as me and was asking for an option to develop
> > interactively on the J1 processor itself.
> 
> That's fine if the J1 has facilities for the full development process. 
> I can't remember the last time I used a target that was even close to 
> being able to support a full development system other than the Raspberry 
> Pi.  What sort of J1 hardware are you looking at?

The J1 can't address much memory, so a native Forth is possible but would
be a tight fit.

You mentioned a lack of mass storage on the target device, but these days
you can easily have 64Kb of Flash or more.

In any case, my own SiliconSqueak is way larger than the J1 and is meant
for boards with more resources, though not necessarily as large as a
Raspberry Pi.

-- Jecel

On 6/15/2016 5:43 PM, Jecel wrote:
> On Tuesday, June 14, 2016 at 5:16:08 PM UTC-3, Rickman wrote:
>>> What I am saying is that I don't like edit/compile/test loops but
>>> prefer interpreted systems (or those that do a good job of pretending
>>> to be interpreted - see Smalltalks with JIT compilation).
>>
>> You still have the loop, you think it is faster the way you are
>> describing, but I use the same command line for testing.  I just use the
>> PC as an editor.
>
> "the same command line" might be the key to our differences. In the
> native C64 Basic command line I can type something like
>
> PRINT (MADD/4)+1
>
> and see the result. In a cross compiling Basic I can't do that.

There's the problem.  I'm using Forth.  I didn't know we were talking 
about BASIC.


>>> You are free to prefer compiled systems (most people do) but wzab seems
>>> to have the same taste as me and was asking for an option to develop
>>> interactively on the J1 processor itself.
>>
>> That's fine if the J1 has facilities for the full development process.
>> I can't remember the last time I used a target that was even close to
>> being able to support a full development system other than the Raspberry
>> Pi.  What sort of J1 hardware are you looking at?
>
> The J1 can't address much memory, so a native Forth is possible but would
> be a tight fit.

I don't recall the limitation, but I would expect it to be on the order 
of many KB.  Mecrisp is not so large and in fact, I'm pretty sure it has 
been ported to the J1.  I seem to recall this was done using an open 
source package (the only one I've ever heard of) that compiles to a bit 
stream.  In a fit of enthusiasm I believe Matthias Koch ported his Forth 
to this target making the entire effort open source.  I can't recall for 
sure, but I'm pretty sure the hardware is also open source.


> You mentioned a lack of mass storage on the target device, but these days
> you can easily have 64Kb of Flash or more.

64 kB of on target flash is not of much value for storing source.  You 
have virtually no tools for printing, copying, backup, etc.  I use a PC 
for all that.


> In any case, my own SiliconSqueak is way larger than the J1 and is meant
> for boards with more resources, though not necessarily as large as a
> Raspberry Pi.

You mean an FPGA board?  The rPi has a higher end ARM processor.

-- 

Rick C

On Wednesday, June 15, 2016 at 7:14:06 PM UTC-3, Rickman wrote:
> On 6/15/2016 5:43 PM, Jecel wrote:
> > "the same command line" might be the key to our differences. In the
> > native C64 Basic command line I can type something like
> >
> > PRINT (MADD/4)+1
> >
> > and see the result. In a cross compiling Basic I can't do that.
> 
> There's the problem.  I'm using Forth.  I didn't know we were talking 
> about BASIC.

:-)

So we type

MADD @ 4 / 1 + .

instead. The point is that I don't have to first put that expression
in a colon definition, compile it, and then send it to the target
board to see the result.

> > The J1 can't address much memory, so a native Forth is possible but would
> > be a tight fit.
> 
> I don't recall the limitation, but I would expect it to be on the order 
> of many KB.

Let me check:

http://excamera.com/files/j1.pdf

"All target addresses - for call, jump and conditional branch
- are 13-bit. This limits code size to 8K words, or 16K bytes."

Data uses 15 bit byte addresses, but the top half of the memory
map is reserved for I/O. So was have 16KB in all to play with.

> Mecrisp is not so large and in fact, I'm pretty sure it has 
> been ported to the J1.  I seem to recall this was done using an open 
> source package (the only one I've ever heard of) that compiles to a bit 
> stream.  In a fit of enthusiasm I believe Matthias Koch ported his Forth 
> to this target making the entire effort open source.  I can't recall for 
> sure, but I'm pretty sure the hardware is also open source.

Ok, so the answer to the original question is "yes"? Good. I've had some
nice machines (Mac, Sun Utra 5+, XO-1 from One Laptop Per Child) with
OpenFirmware (OpenBoot, as Sun called it) and it is a nice token threaded
Forth that can be used interactively. Not only is token threading
really compact, but it can also be used on Harvard architecture chips
like the Atmel AVR8.

> > You mentioned a lack of mass storage on the target device, but these days
> > you can easily have 64Kb of Flash or more.
> 
> 64 kB of on target flash is not of much value for storing source.  You 
> have virtually no tools for printing, copying, backup, etc.  I use a PC 
> for all that.

Normally, I would agree. But for Forth or Basic (as in BasicStamp boards)
it might be enough. Most early microcomputers had 80KB floppy disks.

> > In any case, my own SiliconSqueak is way larger than the J1 and is meant
> > for boards with more resources, though not necessarily as large as a
> > Raspberry Pi.
> 
> You mean an FPGA board?  The rPi has a higher end ARM processor.

The R-Pi also has SDRAM, HDMI output, USBs and Ethernet which is also
the case for some FPGA boards. And those with chips like Zynq have 
FPGAs and ARMs.

What I was saying was that I am also interested in FPGA boards with not
as much memory and with poorer I/O (VGA and PS/2, for example) than
the Pi.

-- Jecel

On 6/16/2016 1:57 PM, Jecel wrote:
> On Wednesday, June 15, 2016 at 7:14:06 PM UTC-3, Rickman wrote:
>> On 6/15/2016 5:43 PM, Jecel wrote:
>>> "the same command line" might be the key to our differences. In the
>>> native C64 Basic command line I can type something like
>>>
>>> PRINT (MADD/4)+1
>>>
>>> and see the result. In a cross compiling Basic I can't do that.
>>
>> There's the problem.  I'm using Forth.  I didn't know we were talking
>> about BASIC.
>
> :-)
>
> So we type
>
> MADD @ 4 / 1 + .
>
> instead. The point is that I don't have to first put that expression
> in a colon definition, compile it, and then send it to the target
> board to see the result.
>
>>> The J1 can't address much memory, so a native Forth is possible but would
>>> be a tight fit.
>>
>> I don't recall the limitation, but I would expect it to be on the order
>> of many KB.
>
> Let me check:
>
> http://excamera.com/files/j1.pdf
>
> "All target addresses - for call, jump and conditional branch
> - are 13-bit. This limits code size to 8K words, or 16K bytes."
>
> Data uses 15 bit byte addresses, but the top half of the memory
> map is reserved for I/O. So was have 16KB in all to play with.
>
>> Mecrisp is not so large and in fact, I'm pretty sure it has
>> been ported to the J1.  I seem to recall this was done using an open
>> source package (the only one I've ever heard of) that compiles to a bit
>> stream.  In a fit of enthusiasm I believe Matthias Koch ported his Forth
>> to this target making the entire effort open source.  I can't recall for
>> sure, but I'm pretty sure the hardware is also open source.
>
> Ok, so the answer to the original question is "yes"? Good. I've had some
> nice machines (Mac, Sun Utra 5+, XO-1 from One Laptop Per Child) with
> OpenFirmware (OpenBoot, as Sun called it) and it is a nice token threaded
> Forth that can be used interactively. Not only is token threading
> really compact, but it can also be used on Harvard architecture chips
> like the Atmel AVR8.
>
>>> You mentioned a lack of mass storage on the target device, but these days
>>> you can easily have 64Kb of Flash or more.
>>
>> 64 kB of on target flash is not of much value for storing source.  You
>> have virtually no tools for printing, copying, backup, etc.  I use a PC
>> for all that.
>
> Normally, I would agree. But for Forth or Basic (as in BasicStamp boards)
> it might be enough. Most early microcomputers had 80KB floppy disks.

I have no idea what you are trying to say with this.  Lots of things 
were done in the early days of programming including using toggle 
switches to enter programs.  I don't wish to duplicate any of that.


>>> In any case, my own SiliconSqueak is way larger than the J1 and is meant
>>> for boards with more resources, though not necessarily as large as a
>>> Raspberry Pi.
>>
>> You mean an FPGA board?  The rPi has a higher end ARM processor.
>
> The R-Pi also has SDRAM, HDMI output, USBs and Ethernet which is also
> the case for some FPGA boards. And those with chips like Zynq have
> FPGAs and ARMs.
>
> What I was saying was that I am also interested in FPGA boards with not
> as much memory and with poorer I/O (VGA and PS/2, for example) than
> the Pi.

I don't know what you are trying to say here.  You mentioned your 
"SiliconSqueak" which I assume is a processor design.  You seem to be 
talking about running it on an rPi which doesn't make sense.  Were you 
just using the rPi as a point of comparison?

-- 

Rick C

Jecel wrote:

[snip]

> 
> What I was saying was that I am also interested in FPGA boards with not
> as much memory and with poorer I/O (VGA and PS/2, for example) than
> the Pi.
> 
> -- Jecel

Many low-end FPGA boards are out there, but in general the peripherals
are richer on the boards with a larger FPGA.  For a bare-bones starter
board with VGA and USB and PMOD, you could look at:

https://www.nandland.com/goboard/introduction.html

However the ICE40 on that board is not very large for playing with
embedded processors.

If you can live with HDMI instead of VGA, then possibly the Scarab
MiniSpartan6+ would be a possibility.  Just be aware that the
SDRAM on that board is single-data-rate and won't work with the
built-in hard memory control block of the Spartan-6.

https://www.scarabhardware.com/minispartan6/

-- 
Gabor

On 16/06/2016 22:39, GaborSzakacs wrote:
> Jecel wrote:
>
> [snip]
>
>>
>> What I was saying was that I am also interested in FPGA boards with not
>> as much memory and with poorer I/O (VGA and PS/2, for example) than
>> the Pi.
>>
>> -- Jecel
>
> Many low-end FPGA boards are out there, but in general the peripherals
> are richer on the boards with a larger FPGA.  For a bare-bones starter
> board with VGA and USB and PMOD, you could look at:
>
> https://www.nandland.com/goboard/introduction.html
>
> However the ICE40 on that board is not very large for playing with
> embedded processors.
>
> If you can live with HDMI instead of VGA, then possibly the Scarab
> MiniSpartan6+ would be a possibility.  Just be aware that the
> SDRAM on that board is single-data-rate and won't work with the
> built-in hard memory control block of the Spartan-6.
>
> https://www.scarabhardware.com/minispartan6/
>
I have used one of these

http://www.ebay.com/itm/251192875961

for a very small system

Dave
G4UGM