Nothing really new for the moment, I'm working on my macro-assembler and Forth implementation. I need also to go to a store to get a breadboard and some straps, to try the joysticks. I'm also thinking about the global architecture of the system.

There are many design constraints, and solutions to find :

• When I did my "picture display" project, It appeared that managing a 640x480 display, even with only 8 colors, needs much RAM access. And it seems that the RAM cannot be accessed by two "devices" at the same time. So, if I keep the full resolution, the future system will probably not be powerful enough to update the whole Video RAM at a good rate...
• What should be the features of the Graphic Processing Unit ? It could manage a basic framebuffer (the simple solution), but it will probably be better to provide stuff like sprites support in hardware. Design decisions have to be taken.

I browsed sites dedicated to Commodore 64 and Sinclair ZX Spectrum... When I looked again to their capabilities, I was like... "whoa!". I didn't remember that these machines has such limitations :) But the fun was here, for sure... (btw, if you don't know this animation, check it out, it's essential : Hey Hey 16K).

The Spectrum hardware reference especially brought a smile on my face... 9 bits used to store 8 pixels ! :)
Another reason makes me quite happy while reading it : the design issues are the same than the ones I forsee (see the chapter on Contented Memory...), and it's becoming obvious that the solutions I will have to find will look much like the ones that all these guys imaginated 20 years ago.

Here is a photo of some joysticks I bought on eBay. My first idea was to decode a Playstation controller I have (there's plenty of information about it, see for instance http://www.gamesx.com/controldata/psxcont/psxcont.htm) but well, a PSX controller is not "old-school", and too complicated for little kids' hands :)

P.S : Some time ago, I was often browsing eBay, wondering "what kind of person would by such a &@#$!" Now, I've changed my point of view a bit :)

I finally got a USB Serial port for my laptop. I programmed the demo PROM from Xilinx to the FPGA, to see that both serial ports work. Good. Now let's try to do some serial communication. Basically, to send a character on a 9600 bauds line, with no parity, 1 start bit, 1 stop bit, all I have to do is :

• lower the level (start bit)
• send the 8 data bits
• raise the level (stop bit)

With levels changes occuring every 1/9600s. So I wrote the following code :

signal serial_data : std_logic_vector(9 downto 0) 
:= "1010000010";

-- the clock is generated with a counter on the 50Mhz clock
-- by changing serial_clk value every 50 000 000/(9600*2)
process(serial_clk)
begin
if serial_clk'event and serial_clk = '1' then
 led_cnt <= led_cnt + "00000000000001";
 if led_cnt >= "10010101110111" then -- 9600 - 9
   TXD <= serial_data(to_int(led_cnt - "10010101110111")); 
   if led_cnt = "10010110000000" then -- 9600
     led_cnt <= (others => '0');
     led_val <= not led_val;
     L(0) <= led_val;			
   end if;
 else
   TXD <= '1';
 end if;
end if;
end process; -- SERIAL

It is supposed to blink a led and send a 'A' character to the serial port every second. Guess what ? It works :)

(I'm particulary proud of this one, because I managed to have it work without looking to anyone else's code :) Yes, it's a bit stupid, but well...)

Now that I have played with the hardware peripherals of the FPGA, It is time to think about the processor of my future system.

As I said at the beginning of the project, I want to have a Forth interpreter in ROM, and better : I want Forth to be the preferred language for programming the system.

There's a lot of literature on the web about Forth and Stack-based computers. Forth uses two stacks the parameter (or data) stack, and the return stack. Most processors handle zero or one stack. A stack-based processor manages natively these two stacks, usually have very few instructions (the term MISC is sometimes used to describe them to compare them to CISC and RISC processors, the "M" stands here for "Minimal").
Because of this, such processors are easy to design. I searched the web a lot, found a lot of hardware designs and Forth implementations, in various languages, but I don't want to use one of them directly.

As a model, or reference implementation of Forth, I will use Bradford J. Rodriguez's CamelForth, roughly for the same reason why I chose the Spartan-3 Starter Board for hardware : documentation.
Bradford J. Rodriguez's Publications helped me a lot to understand how Forth works.

Forth implementations are usually done in either Forth or assembly. But as I still don't know what will be my instruction set, it will be difficult to find an assembler for it :) The idea of Forth in Forth is one of the "mantra" in Forth communities, but it looks a bit confusing to me.

As it is will be my first Forth implementation, I decided to use a language I'm more familiar with (Java, as it's the main language I use at work). Java will here be used as the macro-assembler. My next Forth implementation might be in Forth, who knows :)

There's another reason to use Java (or in general, a more widespread language) : later, I will have to provide tools for building a ROM with resources such a pictures, sound, etc. I think that for each file format that I could need, I will be easier to find the library to handle it.

With all stuff done before (VGA, ROM and RAM), it seems that it is time to make something out of it. Let's begin a simple project : display a picture on the screen.

One thing I forgot to tell about the VGA display : as I don't have DACs, the Red, Green and Blue components have only two values (0=off and 1=on), so it will only support 8 colors :) It means also that each pixel can be stored in only 3 bits, but I will use 4 bits instead, so a RAM word will contain 4 pixels.

Here is what needs to be done :

• Write a small tool to convert the picture. With the "PROM reading" example, Xilinx provides a perl script that reads a file containing hex values, and "appends" it to a design file. So I wrote a perl script too, to generate a file suitable as an input for Xilinx's script.
• In the design, have a first part that reads the PROM, and copy the picture data to the RAM.
• Eventually, design the "main loop", that reads the RAM and output the contents to VGA.

As I had all the different parts needed, after some time, I managed to have a photo of my son displayed on the VGA monitor :)

Xilinx provides a full example for reading user data from the PROM.

The PROM in the starter kit contains the design but as one design doesn't fit the whole ROM space, there is some room remaining for user data. I grabbed the example and had it work without any problem (ref : XAPP694). As opposed to RAM, which has a "parallel" beahviour (you can read/write one word at a time), the PROM has a "serial" behaviour (you have to read/write bit by bit). And because you don't know of what size will be the design, you have to use a kind of "marker" to locate the beginning of the data.

Using ROM directly seems a bit difficult this way, so I decided that in my future designs, I will transfer ROM contents to RAM at boot.

The starter board comes up with 2 banks of 16-bit SRAM.

Having eventually RAM working has been the most difficult part... I haven't be able to make Fabrice Derepas' example work out-of-the-box, and there were many things that didn't look obvious to me, especially all the clock-related stuff. Well, after a day (and a night) spent on it, I eventually had it work.

It seems that the main difficulty was due to the handling of the "data port" of the RAM, that is used either for reading and writing. Using a IOBUF here seems mandatory.

So it ends up with a "two-cycles" operation : first step, put the right address value, and enable output on the IOBUF, second step, disable output on the IOBUF, and fetch the value. I'm not quite satisfied with this part, but well, I can use RAM now, and I think I'll get back to it later, when I'll be more familiar with all that stuff.

Here, Fabrice Derepas' website and fpga4fun.com give examples of VGA display. Basically, here is Fabrice's code (slighty modified) for handling VGA display :

   -- the clock here is a 25Mhz clock
   if (horizontal_counter >= "0010010000" ) -- 144
   and (horizontal_counter < "1100010000" ) -- 784
   and (vertical_counter >= "0000100111" ) -- 39
   and (vertical_counter < "1000000111" ) -- 519
   then
     -- pixel in screen range
     -- with X = horizontal_counter - 144
     -- and Y = vertical_counter - 39
   end if;
   if (horizontal_counter > "0000000000" )
     and (horizontal_counter < "0001100001" ) -- 96+1
   then
     hs_out <= '0';
   else
     hs_out <= '1';
   end if;
   if (vertical_counter > "0000000000" )
     and (vertical_counter < "0000000011" ) -- 2+1
   then
     vs_out <= '0';
   else
     vs_out <= '1';
   end if;
   horizontal_counter <= horizontal_counter+"0000000001";
   if (horizontal_counter="1100100000") then -- 800
     vertical_counter <= vertical_counter+"0000000001";
     horizontal_counter <= "0000000000";
   end if;
   if (vertical_counter="1000001001") then -- 521
     vertical_counter <= "0000000000";
   end if;

Let's take some time to understand these values... On many site you can find information on VGA timing. Here is an example of such a site : http://www.ece.odu.edu/~stough/ece489/vga_timi.html

An horizontal line of 640 dots is 25.17us (micro-seconds) long (the "D" delay), which means that a pixel "lasts" 25.17/640 = 0,039328125us. With our board, as we have a 50Mhz clock, we can easily generate a 25Mhz clock, which pulse lasts 0,04us, which is close enough to the ideal value.

With this basis, it's easy to calculate the others values. For instance, the "B" delay represents a count of 3.77 * 640 / 25.17 = 95,860... (roughly 96), and so on. I found some small differences in counter values on fpga4fun.com Verilog examples, but it doesn't really matter, both work.

Woot ! The board is here !

I open the small box, and first surprise, the board is here, the power supply too, but nothing more... No CD, no manual, no datasheet or whatever...

Riiiight, so I fired up my favorite browser and went to the page dedicated to my brand new S3 starter board. I downloaded all the documents here, and then went to the ISE WebPACK page, to download the software.

After some browsing and attempts, I figured out that the device is a "xc3s200" and the package is "ft256". I grabbed the first example of Fabrice Derepas website, struggled a bit with Xilinx's PACE software (to figure out soon that it was much faster to edit the .ucf file by hand).

I generated then a PROM file with the iMPACT software, not really sure of my parameters' values, then there has been some small "panic" moments when I encountered many "Programming Failed" messages... Finally, the four "F" letters showed up on the 7-segments displays, giving me a pure moment of satisfaction :)

I programmed the device with the Xilinx example PROM, that shows all the features of the board : VGA, serial port, leds, push buttons, switches, 7-segments display...

All seemed to work fine, but I was not able to test the serial link, as my laptop has no serial port. I need to get a USB serial port, as I will need it : in my thoughts about my computer system design (I need to find a name for it quickly, too), I had the idea to use the serial port to communicate with the Forth interpreter.

Then I played a bit with the leds and 7-segments display, wrote a small VHDL utility module to display a 16-bit value on the 7-segment display, under the sight of my wife probably worrying about my mental health :)