J1 forth processor in FPGA - possibility of interactive work?

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

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

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.

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.

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

"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.

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

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

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.

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.

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

--

Rick C

:-)

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.

Let me check:

"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.

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.

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

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

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 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

[snip]

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:

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.

--
Gabor

I have used one of these

for a very small system

Dave G4UGM

Rickman,

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.

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

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

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 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.

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

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.

While perhaps not using the fast interfaces, there are FPGA expansions for the boards you mentioned:

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:

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:

-- Jecel

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

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.

< >

--
Cecil - k5nwa