A small update, providing great results... :)



Games I've tested so far run fine, and the rendering issues I encountered were due to a bad handling of the BYR register update... Sounds silly, but it changed everything :D

Here is a preview of my current project : a PC Engine hardware clone in a FPGA.



It is in a very alpha stage, but well, some games work. There are many bugs remaining but the first results obtained are quite encouraging.

For people that can read French, see my "project log" here : http://heliscar.com/greg/blogpce.txt

After many tedious hours of soldering, here are the 8 first Guimauve 2ooo Apple //c VGA adapters :



More to come soon, after the official announcement that will occur during VieuMikro event.

I fixed the mistakes I made on the previous prototype, and I managed to add a small feature : it is now possible with the help of a jumper to choose between color mode, or green-and-black monochrome mode, for those who (like me) had a monochrome display, and prefer to use this mode which provides a crisper picture.

Here is a picture of the final PCB, assembled.



I still need to tweak the CPLD code a bit, but it should be now only a matter of weeks until first boards are available for those who might be interested. I'll tell more about it later.

The Chat-Mauve-clone-but-with-VGA-output needed a name, and here it is : "Guimauve 2ooo".
Here are some pictures of the first prototype, which works fine !





You may wonder what happened to what should have been a nice board ? ;) Well, I made two stupid mistakes so I add to cope with them :

• The part I selected in Eagle as the DB-15 connector on the Apple side had its pin numbering "reversed".
  
• I totally "forgot" that one of the components expected a 5V power supply, while all the others use 3.3V, so I added it.
  
  

I will have to redesign the board but well, it won't be much of a big deal.

I just finished designing the board, using parts I already own for the most :



It has been designed to be the more "homebrew-compliant" possible : it is single-sided, and there will be only a single wire to add. Next step, order parts, and build the PCB (or have it manufactured), then hope the whole thing will work ;)

Here is a new picture, with VGA colors fixed. I still use a 2-bits R-2R ladder for output, so the colors are still a bit different from what's produced by the original adapter, but I can't say that the result is better or worse, so I'll probably keep it this way.
On the left, the original adapter's output on a LCD TV, on the right, VGA output of my adapter.



The image isn't very crisp (I get a better image using Starter Board's own VGA output, even if it only features 1 bit per component). It means that it's now the time to make a proper board, instead of having such a mess of wires hanging around ;)
The desing still uses less than 60 macrocells, so it could fit into a XC9572XL for instance, which is probably what I'm gonna use at the end.

I managed to modify the VGA adapter of the Apple II+ on a FPGA to meet the requirements of my previous post.
It stills runs off the FPGA but, it uses the board's SRAM instead of internal block ram. The design fits well in a XC9572 CPLD, which is quite fine.


Colors are still a bit off, but text display works nice, showing that interleaved SRAM access works. Now I need to fix the colors (shouldn't be much of a big deal, as I already solved the issue on the SCART version), then use a CPLD, to be as close as possible of what would become a final version ;)

My "Chat Mauve" video adapter clone is now working, at least for a basic rendering.
Let's start with a picture of my mess :



On the main TV you can see it running. On the secondary TV, you can see the monochrome NTSC output provided by the Apple //c.
My design is currently running on the FPGA board, but is simple enough to run off a small CPLD. I just wanted to keep all my logic analyzer stuff in place to do some tweaking. For now, I just use a 2-bit R/2R ladder for each R,G,B output, and the screen rendering displays an horizontal resolution of 140 (instead of 280 for a HiRes screen), as my primary goal was to test the full range of colors available.

Here you can see a picture of the original Chat Mauve adapter rendering (displaying Little Computer People, a really nice game, let's call it the grandfather of the Sims) :



Now a picture of the same game, using my adapter :



As you can see, the colors are a bit different, and you can see the effects of the "half-resolution" screen rendering. Well, apart from the screen rendering, which can be probably easily fixed, the result is quite nice. I might test a 3-bit R/2R ladder if if want to get closer to the actual color display but it already looks nice.

Another thing that camed to my mind when I started this project was to make a VGA output, instead of a simple clone of the current adapter. During my quest for information on Internet, I found this project : Apple II+ on a FPGA.
It contains almost everything I need, as it can output video to a VGA screen. The 0.1 version of this project is pretty close to what I've found so far by analysis (and it also provides a 140 pixels wide rendering). The 1.0 version provides an interesting color-generation scheme, which looks pretty tricky to me, with my current knowledge of the Apple video generation internals.

I'm sure this project will be helpful, but for the VGA rendering, I will need to rework some parts, as :

• The 1.0 version of the VGA display uses a 28Mhz clock, instead of the 14Mhz clock provided on the video connector.
  
• It uses a dual-port internal BlockRAM, where I plan to use (whenever possible) a single port SRAM. Dual-port RAM is quite expensive, so I'd rather use standard single-port RAM (and it will make the (hopefully) upcoming board easier to route).
  
• It also relies on vertical and horizontal blank, whereas the video connector only provides composite blank.
  
  

Well, it's already a first major step for my project, but there's much more to come... Stay tuned ;)

It's been some time now since my last site update, mostly because of my lack of time...
Anyway, back to "work" with a new project : design a "Chat Mauve" video adapter clone at first, then maybe an enhanced version. The "Chat Mauve" adapter was designed to provide a RGB output on a SCART connector, for Apple //c computers. At Silicium, despite owning many Apple //c units, we've been able to find only one of those adapters so far, hence this idea of making a clone.
The adapter comes in a very small beige box. I opened it, expecting to find only a couple of passive components or simple logic chips in so few space, and I found myself quite surprised, as the box contains only a single custom chip (along with its voltage regulator) !
As expected, I didn't find anything useful on the web, so I searched for some information about the Apple //c video output and Apple II computers hardware. After some reading, it seems that making a RGB output out of the video signals provided isn't a trivial task, but doesn't seem too hard either.

Then I remembered a nice project I found on the web some time ago : the SUMP Logic Analyzer. It's an open-source FPGA-based logic analyser, with a client software in Java. It uses the Spartan-3 Starter Board as a primary target, which is fine, as I own one of those. So I decided to give it a try, as it should fit nicely for the project's purpose.

First step : put all the adapter's connector signals on a breadboard, and see which ones are used by the custom chip.



No big suprise here, almost all of them are used... Second step, set up the logic analyzer...



... and start analyzing, which is what I'm about to do now. I spent some time these last days to add a VHDL export to the SUMP Logic Analyzer Client, so I could use analyzer results as testbenchs for the upcoming design. On a side note, I'm using my Samsung NC10 "netbook" to run the logic analyzer client... Who said that netbooks are only suitable for basic tasks ? ;)

As you may (should :P) know, a Floppy Drive Emulator has been designed by Jean-Francois Del Nero. See http://torlus.com/floppy/ for more information.

His interface uses programmable logic (CPLD or FPGA) to deliver a perfect timing and emulation of a floppy drive. However, various projects exist, based on microcontrollers.
So I wanted to give it a try myself, using a microcontroller. I chose a LPC2106 mounted on a convenient DIP board (LPC-H2106 from Olimex), and started to work on it last week.

Unlike the current CLPD-based version from Jeff, it uses SD cards for storage, as in his WIP FPGA-based standalone version. With great help of Jeff, I eventually managed to get some good results, as you can see on these pictures :





Thanks again Jeff for your time and patience ;)

As you're probably aware of, MCU are easier to use, and cheaper than programmable logic. However, they bring some limitations, and in such a project where timing is critical, there are some features (especially floppy write support), that are probably not possible with a MCU "alone". However, this work could be a good start to study solutions that could mix external (programmable) logic and MCUs, in order to keep the cost as low as possible, and make it easy to assemble by hand.
Stay tuned !

Yay! The board works now :)

I made another bunch of attempts with the full system, but none of them were succesful. Then I removed the SRAM to keep only the CPU and the EEPROMs. Running the CPU at very low speed showed up the beginning of a startup sequence, but nothing really "stable".

After a while, I got a stable startup sequence, but it didn't do what I expected, so I performed another EEPROM read and I found out that the ROM contents has changed! This is due to another design mistake : the EEPROMs were connected like RAMs (i.e the WE pin was connected to the CPU), and the EEPROMs I use behave like RAMs, so my failed previous attempts corrupted the EEPROM contents!

So I tied the WE pins of the EEPROMs high (see the resistors above the EEPROMs), and continued my tests. I found out another short circuit, then after a while, EhBASIC booted up correctly.

I found one minor glitch, i.e the CE pin for the external memory doesn't work, but well that's nothing, as it's not mandatory, and I think I'll be able to fix it easily.

Next things to do, run the board at full speed, which probably requires to work at 5V (I'm still testing with 3.3V, which seems OK at least at low speed). But before doing so, I will need to get some extra components (mostly level translators), and design another board for power supply, clock and basic I/O. It means that I probably won't work on it for some days (weeks) for now. It will allow me (and my family that had to cope with my bad mood during this debugging process) to rest for a while...

I corrected the short circuit I discovered last night, then started to test the memory-related logic. I found out another "bug" here not related to the board itself, but to the design. Fortunately, it was easy to fix with a single wire, as you can see on this picture. Now I am able to read correctly the contents of one of the two EEPROMs. Good! Next things to do, perform the same tests with the other EEPROM and the SRAM...

I made some extra tests on my board, but I got nothing working right. So it seems that I need to test things one by one.

First, I needed to ensure that the EEPROM writer was working, so I made a quick design on the Spartan-3 Starter board, that reads the contents of the EEPROM, and outputs the result on the serial port. I wrote a small program on the PC to catch this output, and everything went fine.

It means two important things :

• The EEPROM contents is OK, so the EEPROM programmer works (even if as I said before, it is unable to read what it has written).
• Driving the 5V EEPROM with the 3.3V FPGA seems ok, at least for those tests.

Next step, be able to perform the same with this EEPROM installed on my board. Yesterday I already discovered one short circuit, and I'm pretty sure that I will find other ones. The debugging process will be tedious but well, it might be worth the time spent on it.

I spent a large part of the day to debug my board. Using a simple multimeter, I checked every conection, and corrected many bad ones. Then I flashed the EEPROMs with EhBasic, and made a simple design on my FPGA board, to test the whole thing... that of course failed. Even if I expected it to do so, I'm still disappointed about it.

Fortunately, I designed the board to make address and data busses, as well as control pins, easily available on connection headers, and components are mounted on sockets. So I will be able to remove the CPU, and control the other chips from an external source (the FPGA board), to test all the memory-related logic, and verify the contents of the EEPROMs (As I wrote some time ago, my EEPROM programmer isn't reliable, at least for reading, but I suspect it to be unreliable for writing too).