> Hi,
>
> I'm very impressed with a J1 forth processor: http://excamera.com/sphinx/fpga-j1.html
> I'd like to use it to implement simple non-time critical control and
> debugging layer
> in my FPGA based DSP system.
> However to accomplish it I need to add possibility of interactive work
> via console
> connected either by UART or by JTAG.
> Has anybody tried to extend the J1 published in http://excamera.com/files/j1demo.tar.gz
> with possibility to interactively define new words and execute them?
> --
> TIA & Regards,
> WZab
>
I have the ep8080, the ep16, and ep32 cores now working along with a
resident version of eForth in each of those CPUs, the next CPU will be
the J1 but first I will need to take a slight detour.
I will continue working on the ep32 core for a while as a learning
vehicle to learn VHDL, so after some minor upgrades such as adding an
additional address register, and additional instructions, when I feel
comfortable with VHDL I will proceed to the J1 CPU.
The first step will be to create a J1 Meta-compiler so I can create a J1
version of eForth that resides in the J1 CPU. If by then you do not have
a resident Forth compiler you might be interested in the J1 native
version of eForth. Once that is working with the existing J1 CPU Verilog
code, I will proceed to create a version of the J1 in VHDL.
If you are interested let me know and I can do the above in a slightly
different order, but no matter what I will need to learn VHDL first as
the J1 is written in Verilog for a different FPGA than the ones I have so.
Maybe all the above is not necessary as there is a native eForth
implementation available that I just found. Along with it is code to
implement a serial port so the J1 can talk to the outside world.
< https://github.com/samawati/j1eforth >
--
Cecil - k5nwa
Reply by Matthias Koch●June 22, 20162016-06-22
>> 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.
Exactly, Swapforth by James Bowman and my descendant Mecrisp-Ice with
optimisations run happily in HX1K FPGAs, Icestick and Nandland Go are supported.
If you wish to add more opcodes to the CPU or need gates for something else,
you should go for the HX8K breakout board instead.
Matthias
Reply by Jecel●June 18, 20162016-06-18
Rick,
sorry that I am not addressing the rest of your post, but I think we
have both said all there is to be said about the subject and won't
reach an agreement.
> If I thought anyone was interested and could find a software guy to team
> up with, I would produce an FPGA board which connected to the fast
> interfaces on a CPU like the rPi or maybe a BeagleBone and use the
> resources on the processor board as a low cost I/O processor for the
> FPGA. That reminds me of the array processor I used to work on that had
> a compute head on one board and the entire rest of the two rack cabinets
> (including two 68010 processors) were support to get data in and out of
> the compute head.
While perhaps not using the fast interfaces, there are FPGA expansions
for the boards you mentioned:
http://www.bugblat.com/products/pif/http://valentfx.com/logi-pi/http://valentfx.com/logi-bone/
The way to have the fastest possible interface between the FPGA and
the processor is to use a chip like the Xilinx Zynq, which includes
two ARM cores. There are many variations of the Zed board with this
chip:
http://zedboard.org/
The one most like what you were describing is probably the Parallella
board, which is essentially a Zed board in a Raspberry Pi form factor
plus an Epiphany chip with 16 (or 64) floating pointer processors:
https://www.parallella.org/
-- Jecel
Reply by rickman●June 18, 20162016-06-18
On 6/17/2016 1:37 PM, Jecel wrote:
> Rickman,
>
>>> 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.
>
> I am saying some programming environments are pretty small and some embedded
> processors are getting large enough that the two can meet. Sure, small can
> mean primitive and awkward but not necessarily. I find stuff build around
> Eclipse pretty unusable so consider the GB of disk and RAM that they need
> a waste.
I have no idea why you are bringing Eclipse into a Forth discussion.
Programming from a PC is the easiest way to work unless your target is
heavy enough to support an operating system. So in the Raspberry Pi I
program directly on the target. Any embedded board, even with an on
board Forth compiler, the PC gets used as the host for most development
work while debugging is on the target. I load the code which is one
command and takes maybe a second. I test a few words or word from the
command line until I find a bug and make changes. I forget the stuff
just loaded, load the new code and in less than 5 seconds I'm back to
debugging. Hardly an onerous cycle. In fact, I barely know I'm working
from my laptop on a remote target until I get the target locked up and
have to walk to the other room to push the reset.
>> 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?
>
> Sorry about the confusion. SiliconSqueak is indeed my own processor and
> I was talking about implementing it on low end FPGA boards (Gabor and
> Dave Wade have just suggested some nice options in this thread) and
> comparing their resources with those available on the Raspberry Pi.
I haven't spent much time looking at FPGA boards. I build products with
FPGA but they are seldom on boards that would support other than fairly
primitive processors that are doing simple control functions. My
current product does not have a processor, but the FPGA is maxed out.
The FPGA is also obsolete and eventually the board will need to be
redesigned. When this happens the code will need to be ported and some
of the slow speed stuff might be better in a soft CPU.
> The Squeak virtual machine (both the original interpreter and the new
> Cog JIT compiler) runs very well on the Raspberry Pi thanks to the
> foundation's efforts to make Scratch more usable. This means you can
> either run some software on the Pi with these VMs or on an FPGA board
> with my processor. That makes comparing the two options interesting,
> though an FPGA board costing around $100 might have less resources
> than a Pi board costing $5.
If I thought anyone was interested and could find a software guy to team
up with, I would produce an FPGA board which connected to the fast
interfaces on a CPU like the rPi or maybe a BeagleBone and use the
resources on the processor board as a low cost I/O processor for the
FPGA. That reminds me of the array processor I used to work on that had
a compute head on one board and the entire rest of the two rack cabinets
(including two 68010 processors) were support to get data in and out of
the compute head.
--
Rick C
Reply by Cecil Bayona●June 17, 20162016-06-17
On 5/13/2011 7:34 AM, wzab wrote:
> Hi,
>
> I'm very impressed with a J1 forth processor: http://excamera.com/sphinx/fpga-j1.html
> I'd like to use it to implement simple non-time critical control and
> debugging layer
> in my FPGA based DSP system.
> However to accomplish it I need to add possibility of interactive work
> via console
> connected either by UART or by JTAG.
> Has anybody tried to extend the J1 published in http://excamera.com/files/j1demo.tar.gz
> with possibility to interactively define new words and execute them?
> --
> TIA & Regards,
> WZab
>
Its king of a round way to what you want, but the following is
interesting and might accomplish what you wish.
The ep16 CPU contains within it's zip file the following;
weForth - a Windows version of eForth used to create a development system.
Meta compiler - for the ep16 but easily modified for other stack machines
eForth source - not in assembler but in Forth primitives be
meta-compile into the target CPU
Documentation - not just for the CPU, and more importantly for the software.
This package will result in a copy of eForth that would be resident in
the target CPU
I am working with the ep32 which comes with the same software to learn
VHDL, my next target is the ep16, followed by the J1, when I get there I
will be modifying the target compiler to generate J1 primitives and in
so doing ending with a copy of eForth that resides inside the J1. You
can wait until I get there or you can Download the code for the ep16 and
modify it yourself.
Theoretically the J1 has many new instructions built in without changing
the FPGA code, you would have to add the extra instructions that are
already there but nor used to the metacompiler software, it looks like
it's a relatively simple task.
Have fun going Forth.
--
Cecil - k5nwa
Reply by Jecel●June 17, 20162016-06-17
Rickman,
> > 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.
I am saying some programming environments are pretty small and some embedded
processors are getting large enough that the two can meet. Sure, small can
mean primitive and awkward but not necessarily. I find stuff build around
Eclipse pretty unusable so consider the GB of disk and RAM that they need
a waste.
> 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?
Sorry about the confusion. SiliconSqueak is indeed my own processor and
I was talking about implementing it on low end FPGA boards (Gabor and
Dave Wade have just suggested some nice options in this thread) and
comparing their resources with those available on the Raspberry Pi.
The Squeak virtual machine (both the original interpreter and the new
Cog JIT compiler) runs very well on the Raspberry Pi thanks to the
foundation's efforts to make Scratch more usable. This means you can
either run some software on the Pi with these VMs or on an FPGA board
with my processor. That makes comparing the two options interesting,
though an FPGA board costing around $100 might have less resources
than a Pi board costing $5.
-- Jecel
Reply by David Wade●June 17, 20162016-06-17
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/
>
>
> 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
Reply by rickman●June 16, 20162016-06-16
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
Reply by Jecel●June 16, 20162016-06-16
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