I spent some time converting a bitmap font, in order to have the GPU render something more interesting than some random garbage.

Now I can display some text, and use the EhBASIC interpreter for POKEing some values to test the GPU... Good !

On this wonderful picture you can see the first output made by the GPU in progress.

I started to design a tile-based rendering engine, which features currently are :

• 32 palettes of 4 colors.
• 256 tiles of 8x8 pixels.
• A 48x32 tile map.

Next thing to do on the GPU : vertical and horizontal offset registers, to enable hardware scrolling.

Well, everything would be perfect, but I discovered that the memory sharing between the T65 core and the GPU caused some problems, with my current CPU halting management at least. So I think I will take some time to fix this issue, before going on further GPU enhancement.

EDIT : It seems that the memory sharing issue is solved now : I'm using the "enable" input of the T65 core instead of the "ready" one, and it works fine.

All my previous video experiments used only one bit per color channel (Red, Green, Blue), bringing a mere 8-color palette. So I decided that I would need more colors this time. Now each color channel use 2 bits (I made a simple R-2R ladder for Digital-Analog conversion) so my system now features 64 colors. I made a simple framebuffer design to see how it would render, and displayed a picture of my son on the telly. It looks much better this way :)

Today, I bought a small 36 cm television with SCART and composite entries, dedicated to my upcoming experiments (it was necessary, as my son who was ignoring the telly until some weeks ago, now wants to watch the same cartoon forever).

Some time ago, I made some TV output attempts using a 5V CPLD from Xilinx, the XC9572. So I reused this design, calculated resistor values to cope with the 3.3V of the FPGA, and used a MAX232 to output the required voltage to have the TV select the RGB input, and everything works fine.

Great! Now that I have this telly available for my tests, and the "analog part" is quite done, I can now focus on the GPU design.

EDIT : 12V is usually expected on the pin 8 of the SCART connector to select RGB input, but the MAX232 output voltage I get is only 8.5V (which is correct according to the datasheet). I tried to connect a plain 5V on this pin, and it works too, so I removed the MAX232. It sounds OK at a first glance, but it also means that I will have to find a better solution to do 5V to 12V conversion, as many TV sets don't select RGB with only 5V applied on this pin, like our main TV.

Once memory issues fixed, I eventually managed to get EhBASIC up and running on my minimal system.

I ended up using a serial interface instead of the USB FIFO, as for some reason I'm getting awful results while writing to it, which is a bit weird as the reading process works fine... Anyway, in a more definitive version of my future system, I won't use this USB FIFO anymore, and I will probably need a serial interface, so everything's fine :)

Wow... When I said in my last posts that everything seems OK, I was just plain wrong.

The SRAM interface, as well as the startup sequence of EhBasic seemed OK, but they weren't. I started to wonder what happened while going further in EhBASIC execution : after displaying correctly the welcome message, it spitted the same character forever (!). I started to suspect the bootloading process, but it became soon sure that it was OK. After many attempts and step-by-step executions (BTW, thank you very much Mr Kowalski for your wonderful simulator, it was very helpful), the problem was located at the SRAM interface level.

In fact, this is not really the interface that is the heart of the problem, but (in my opinion) the architecture of the T65, and the RW pin that lead to timing issues. I tried to make some modifications on the T65 core, but I have not been able to get something working. I think that the main point for a proper behaviour would be to re-simulate the PHI2 clock, but well, that's another story.

I searched the web a bit, and found some running designs involving FPGA Block RAM. So I rewrote a part of my design to use it, and it eventually seems to work !

But well, let's stay cautious about these early results...

I was pretty ignorant about the 6502, so I started to study this microprocessor a bit, with the (great) help of 6502.org, and I was amazed by its simplicity and efficiency, so my future system will use a 6502 instead of a Z80.

I got interested in two pieces of software :

• Lee Davison's EhBasic, a free Basic interpreter for the 6502. It could be a nice feature of my future system :) Forth might come later...
• Michal Kowalski's 6502 simulator, a very nice IDE for 6502 assembly language development. Very good, and EhBasic provided a startup source code for use with this simulator.

It became obvious that a 16-bytes ROM couldn't be used anymore, so I started to connect an EEPROM to the FPGA. I had a 5V parallel EEPROM large enough for this purpose, that I connected to the FPGA I/Os using a 74AHC245 on the data bus to protect the FPGA. But then I encountered many issues : even if my first attempts (a simple ROM reader) seemed OK, I didn't manage to get reliable results from it.
Struggling with this EEPROM was quite boring. Maybe its data were incorrect, but I had no easy way to check them, as my EEPROM programmer is unable to read what it has written. The 74AHC245 is 5V tolerant, with a 3.3V supply, but it isn't a true level converter. Even if according to the datasheets, everything seems OK (the 3.3V FPGA outputs should be able to control the address bus), the results were awful.

So I went to the conclusion that in order to have something reliable, I should either get a 3.3V EEPROM or a real level transciever, and get a real EEPROM programmer (able to program 3V EEPROMs), but I was disappointed because all this stuff would cost some money (especially the programmer)... Another issue is the programming/placing/testing/removing EEPROM chip cycle that is quite painful. The EEPROM programmer is slow as hell, and placing/removing chip is quite boring, even with a ZIF socket.

Then I had a better idea ! I remembered that I had some USB FIFOs chips, so another solution was to design a bootstrap sequence that would download the contents of the "EEPROM" through USB, and write it to RAM (RAM protection being ensured by the design).
So I wrote the design, and a piece of software for this purpose, and it worked ! ROM contents is now downloaded in a few seconds, and I have been able to check that the startup sequence of EhBasic executed well. Good. I used the same startup code that the one used within the 6502 emulator and adapted my design to its architecture (it simulates an ACIA for I/O purposes). Then I had another idea : instead of designing a RS232 interface to communicate with the Basic interpreter, I will use the USB FIFO for this purpose.

Next step : have EhBasic fully up and running, then start to design some video chip for instance.
I already have some ideas about it, but let's focus on the Basic before :)