On this picture you can see the result of my DIY session of this evening.

It took me twice the time required... as I did it twice because I wired it the wrong way at first :/

It eventually works... Nothing fancy, it's a, well, "pure passthrough" :) Next stage is to hook some signals to the FPGA board, and make some attempts of pins captures.

Today, I opened my Atari 1040 STe. I wouldn't have needed to do it, but I wanted to have a closer look at what it was made of.

I located the floopy disk controller (see the picture), and it's a strange beast : a custom Atari chip called C302434. I haven't been able at the moment to find its datasheet on the net, but well, it's probably just a matter of time, and it's not absolutely necessary at this stage (and maybe won't be useful at all).

Next stage will be yet another do-it-yourself session, in order to build the passthrough. Hopefully, it shouldn't take too long.

The VGA adapter I was waiting for is finally here. You can see it on the top of this picture (on which you can also see my 6502 board that works now, as I have changed its wiring a bit).

It means that now I'll be able to work on the Atari-related project. And that's what I will do in the next days. Jace is expecting some results of the "passthrough" I want to build, so I will do it as soon as I can, and send him the results (the FPGA board will be used as a kind of digital scope).

So the next site updates should occur in the Atari section. But getting the first results shouldn't take long, and after that, it's up to Jace to work on it, he's the project leader after all :) So I will probably get back soon to "Bixente I+/Electorlux" and "6502-related" projects.

I have made a small 6502 Tester, looking much like my Z80 Tester.

It was more painful than with the Z80. The good news is that it works, the less good one is that, as you can see on the picture, I'm not using the board I built for it.

I encountered some weird results at the beginning, so I suspected my legendary Do-It-Yourself skills and revert back to a solderless breadboard installation. But then I discovered that the reason why it failed was that I was using some I/O pins of the FPGA board which were shared with other functions of the board ! So I changed the wiring a bit... My custom board is probably OK, but well, I'll give it another try when I have a more precise idea of the final "schematics".

Unlike the Z80, the 6502 has its own clock generator. But it can be controlled externally too. For the purpose of having the whole thing "human-readable", I needed to slow down much the clock rate. And then I encountered some weird behaviours of the 6502 while using too slow clocks... Well, after sorting that out, I generated a clock at a reasonable speed, and it worked.

The principles are the same as the Z80 Tester :

• Generation of a slow clock.
• RES tight to a push button.
• Data bus written with the NOP instruction (here 0xEA for the 6502).
• SYNC and R/W signal shown on leds.
• Value of the address bus display when in "opcode fecth" cycle.

As in the Z80 Tester, you can see the PC register incremented one by one. Good.

No new software, but hardware projects has been quite active these last weeks.

• My attempts to use an ARM MCU for Bixente II project didn't bring the results I expected. So the project is a bit delayed, until I find a solution.
  
  
• I've been playing with Z80 and 6502 CPUs. I think I will use one of them (maybe both) for a Bixente I+ project. I have a kind of deadline for it : a meeting/party at the end of August, where a first presentation of the prototype is expected :) DaLk suggested the name Electorlux for the console. Yeah, it sounds good, but well, I'm pretty sure I've heard something like that before... :)
  
  
• The 6502 will be used for another hardware project, courtesy of Devpsx. And the Atari-related project will continue soon hopefully.

As I was fed up with connecting and unconnecting wires on my solderless breadboard, I went to a shop and bought some connectors to make something more "clean".

You can see on this picture the board I just finished. I plan to do the same kind of board for the Z80 later.

Next task : make the design for the 6502 tester...

Some time ago, I was discussing with Devpsx about a hardware project he had in mind. As he's too busy at repairing or building stuff at his house, I told him that I could give it a try. He sent me some 6502 chips for my tests. Thanks, again :)

This project involves 6502 microprocessors. Together with the Z80, they represent "Les Enfants Terribles" of the 8-bit generation of family micro-computers launched in the end of 70's and early 80's.


My first mission is to have it work. For this purpose I will at first do something looking like my Z80 tester, then I will "emulate" a 6532. This chip was often used along with the 6502 to bring RAM, I/O, and Timers (that's why it's also called a RIOT).

When this project will be a bit more advanced, I'll tell you more about its final goal... Stay tuned !

Yes, I know I look ridiculous on this picture, but well, I felt that all the previous pictures were quite boring. I hope this one at least will make you smile :)

This afternoon, I decided to try to make the Z80 MCU work. I spent some time looking at this site to grab maximum information about this CPU I don't know much.

I especially found this page showing how to make a minimal circuit to test a Z80. So I decided to make my own, using a FPGA of course.


You can see on the following picture my own Z80 Tester featuring :

• Generation of a 1-2 Hz (yes, one or two single Hertz :)) clock for the Z80.
• Data bus written with 0s, corresponding to the Z80's NOP instruction.
• The 8 lower bits of the address bus are shown on the 2 lower digits of the display.
• M1, MREQ, WR, RD signals are shown on some LEDs.
• When M1 is active (opcode fetch cycle), the 8 lower bits of the address bus are shown on the 2 upper digits of the display.
• RST tight to a push button.
• BUSREQ, INT, NMI and WAIT tight to Vcc (inactive).

With this simple design, it's easy to see the CPU timings, and you can watch the Program Counter incremented one by one. Hurrah, it works :)

Later, I will try to set up all the proper interfaces (RAM, IO, interrupts...).

If you want the source of the design, let me know, and I'll comment it and publish it on my site.

After some time spent reading various topics about the LPC2106, I got many ideas. One of my first ideas was to use the I2C capabilities of the MCU, to communicate with the FPGA, by using either a I2C FIFO component, or some VHDL design. But finally, I thought that I didn't really need to have I2C, but that a custom (and simplier) synchronous serial interface should be OK.


So I set up the design for it, and after some time... It works !


I'm now able to send correct data to the FPGA, at a quite slow rate, but it's a much better result than I had before :) I will probably try to use more pins again, to mix serial and parallel interfaces but well... As my GPU will manage sprites and tiles, speed should not be an issue.

I will still take a small break (on Bixente project), as I want to set up the Z80, and work a bit on other projects before getting into the design of the GPU, which should be a rather complex part.

I'm a bit disappointed. I spend many hours on trying to get some trustworthy responses from the GPIO pins, without success. I did many attempts, for instance cutting the bus width by a half in order to have the FPGA echo the values sent by the MCU, and designed some synchronization stuff, but I still encounter some unpredicable values.

Maybe there are some electrical issues... Well at this moment, I think I need to take a break, and do something else...

I see two things I could play with :

• The USB module for the Atari-related project (see Atari section). But I'm still waiting for that VGA adapter.
• The Z80 MCU. This one at least has a external memory interface :) I could try to work it out, as it may be useful for some hardware emulation project (and well, maybe I could use it for some kind of Bixente I+ project :))

Well, I found this thread (and this thread too) on LPC2000 Yahoo Group.

Some people have measured an average speed of GPIO port switching on the LPC2106 of about 3Mhz, what people at Philips seem to confirm (or at least be aware of). So I guess the problems I encounter may come from pin sampling, as this morning, my attempts on increasing the cache size led to no improvement.

That is a bit disappointing... I need to either consider another solution for the CPU, or adapt my design to cope with this issue... but the performance of the whole stuff won't probably be what you could expect from a system embedding a 60Mhz-capable CPU.

EDIT : BTW, I also found the reason why P0.02 and P0.03 pins seemed "broken" while searching the LPC2000 group. Theses pins are also used by the I2C interface, so need pull-up resistors...

I finally set up the basic interface between the CPU and the GPU.

Instead of designing a SRAM-like interface, as of I thought at first, I decided to design a kind of micro-code. The interface is made of 16 data bits (the "argument"), 1 bit for synchronization, and 2 bits for the "instruction set" which is :

• LEA : Load Effective Address - the 16-bits argument is loaded into a special address register.
• STF : STore and Forward - store the 16-bits argument into the memory location pointed by the address register, and increment the address register.
• LD : LoaD - reads the memory location pointed by the argument (not implemented yet).

Compared to my previous idea of a 16-bits address bus, along with a 8-bit data bus, it has many advantages :

• Writing 16 bits in the worst-case scenario would require 2 operations, no more than with a 8-bits data bus.
• The SRAM I'm using is a 16-bits one, and my future GPU will probably use structures at least 16-bits wide. Performing 8-bits access would not be performant (it would require to read the memory before any write operation), and probably useless.
• With special "instructions", like the STF one, it will be more performant than a standard RAM access, for many operations.

So I finally connected 19 GPIO pins of the LPC2106 to the extension port of the FPGA board. I designed a 16 entries cache, and reused parts of Bixente I (the RAM and video controllers) to perform a quick Speccy-like video rendering (see previous news about it). Unfortunately, although my previous tests about GPIO pins sampling seemed OK, as you can see on the picture, there are some synchronisation issues.

In fact, there are many possible reasons for them :

• The FPGA and the LPC2106 have their own clocks. I probably need to look forward to use the same for both.
• The RAM controller is poorly designed and the cache size is probably too small.
• The whole design by itself is made of many parts that are somewhat asynchronous. Once I made up my mind about the whole architecture, it would be easier to get a coherent design for every part.

Anyway, it's not that bad for some hours of work :)

My next "assignment" is to solve these synchronization problems.

After some web searching, I finally found a proper startup code and linkscript that allows me to use GCC to code for the LPC2106. Software tools-related problems solved :)

I made my first attempts designing an interface between the FPGA and the LPC2106. I need a rather fast interface, even if the GPU will probably provide a tile/sprite engine, that usually needs less memory access than a bitmapped mode.

I connected 16 GPIO pins at the moment, after some hours of head-scratching, before I found out that two pins don't seem to work properly.
Anyway, I used two other pins, and it worked.

I will probably make a 24-bits write-only interface :

• 15 bits for addressing
• 8 bits of data
• The last bit for synchronization.

More to come in the next days...

Well, nothing really new...

Still doing hardware stuff (see Atari and FPGA sections).

But I just realized how messy what is supposed to be our living room is now...

Yesterday I got the USB module working, for the purpose of my current hardware project (see the Atari section).


Next stage of this project involves getting my hands into the Atari ST itself, but before doing that, I need to get a VGA adapter (I don't want to use the telly, and I expect such an adaptor to be delivered to me soon).



So I decided to work a bit on Bixente II project, by having my LPC-H2106 board from Olimex up and running. You can see the board on the picture (surrounded by an ellipse), next to the USB module and wired to one of the extension port of the FPGA board.

I set up the following connections :

• Ground and Power pins.
• One switch of the FPGA board to control the P0.14 pin, in order to select either the ISP mode (to program the flash memory for instance) and user application mode.
• One push button of the FPGA board to control the RST pin.
• TXD and RXD pins of UART0 connected to the FPGA board's serial interface, in order to use the ST3232 (that is equivalent to the MAX2332) and the DB9 connector.
• One led of the FPGA board connected to P0.7 (see below).
  

Everything worked fine, and I have been able to flash a sample program that blinks a led (available at Olimex's website). Good.
I also suscribed to a Yahoo group called LPC2000 that seems to be active and provide lots of information about these ARM MCUs.
More particularly, I was looking for information about the way to use a free toolchain, instead of the commercial ones that are very expensive (for a hoobyist, at least). And it looks that a standard GCC build, and proper specs/linker/startup files (found on this group) should do the trick. Very Good.

Now I need to spend some time reading the documentation, and then begin to make my own programs. I'm quite familiar with ARM programming, but I need to see what kind of I/O I can use and how, in order to make, at first, a video interface for the console.

I have been able to set up the USB module and control it with my FPGA board.

It was a bit painful, for some reasons :

• I started to use the "Virtual COM Port" driver. I'm pretty sure it works well... when everything works (which was not the case at the beginning of my attempts). Otherwise, it would completely freeze (this crap of) HyperTerminal, leaving a process you cannot kill, and an unavailable COM port until next reboot ! A true nightmare, so I decided to use the other driver, and found a test program providing the features needed for early tests (and that you can kill, when it's hung, at least).
• As you can see on this picture, my DIY skills are horrible. And because of some bad wires/soldering, some electrical shortcuts appared. It's fixed now, and I've been quite lucky that neither the module nor the FPGA board nor the PC (!) has burned during the testing.
  

Everything is fine now. I wrote a quick design to read the USB module's FIFO, and it works. Great news !

I have now some new projects beginning :

• Bixente II. I already have made some kind of "proof-of-concept" with Bixente project. Now I want to do someting more "serious", with hardware parts and software tools that you could find in nowadays handheld systems. See the FPGA section for more details.
  
  
• A hardware project on Atari computers, for which I have opened a new Atari section. Some software projects should appear too in this section.
  
  
• As my PassMe has arrived, I am now able to run code on my Nintendo DS. I have some game ideas in mind so watch out the NDS section for updates.

Some parts arrived, as you can see on the picture, and I expected others (mostly samples) to come in the next weeks.

Here you can find :

• A LPC-H2106 evaluation board from Olimex featuring a Philips LCP2106 ARM7 MCU. It will probably become the CPU for my Bixente II project :)
• A DLP-USB245M evalutation board from Future Technology Devices. It's a USB controller that will be useful for many purposes, one of these being related in my Atari section.
• A Z8400 MCU. Yes, a good old Z80 MCU. It will probably be used in a future hardware emulation project.
• Some samples from Analog Devices, that will bring hopefully decent sound and video to Bixente II.

Yeah, my PassMe is here ! After some time struggling with it, I finally managed to work it out (it seemed that the transportation harmed it a bit), and applied the firmware patch.

With all the reverse engineering work done at this date, I think I'm ready to get into NDS development, and I have some ideas in mind for it. Wait and see...

Here it is, a new section, dedicated to Atari computers...

Why such a section ? Well, I must admit that although I had a Atari ST when I was younger (that I used mostly for music and gaming), I was not (and still am not) a fanboy of this stuff.

But there is still lots of people doing Atari-related stuff, like demos/intros/games coding, retro-gaming sessions and demo-parties, and also a lot of hardware hacking and mods... As you may have guessed, this is the last point that convinced me to enter (back) into this "world" (and also that it could become the first "computer" for my son, as my wife and I are a bit afraid when he comes and hits our laptops keyboards).

So here is a picture of the beast : an Atari 1040 STE I catched for a few bucks on eBay, along with some spares and books I got from Rajah : a 68020 CPU, some 68881 and 68882 FPUs, a 68851 MMU, and RAMs. In the middle of the picture, an interesting piece of hardware I purchased some time ago : a USB module. Yeah that's it : Jace had a hardware project in mind (see his site), that looked interesting to me, so I will try to give some help if I can...

The idea is to replace the floppy drive and the need to use floppy disks by a small board connected to a PC or Mac through USB. More details coming soon...