Bart Trzynadlowski's Home Page  

Old News

This is an archive of old news that has appeared on the main page starting with December 29, 2002 (when the site moved to trzy.org.) Updates prior to then have never been archived.

January 8, 2006: I'm pretty sure that I've fixed the remaining problems with my video game system. I have one more test to do but, because the board is not at my house, it'll have to wait for another couple of days. In the meantime, I wanted to go ahead and release the project. Should I find any problems, I'll post an update here.

Watch out, Sony, because there's a new console in town: The BartStation. Featuring eye-popping 8-color graphics and a scorching 8 MHz of processing power! It uses a Z80 and a Spartan-3 FPGA to provide VGA output. Sega Genesis controllers are used for input. Unfortunately, there is no sound. It was a fun project and I think people might find it useful as it demonstrates how to design a complete (albeit very simple) Z80 computer system and how to create a simple VGA output controller in VHDL.

Here are some pictures of my implementation: The complete system, a close-up of the running. The release package contains schematics, documentation, the VHDL code, and$ I haven't written a complete game for it and probably won't because I'd like to move on to bigger and better things :) Grab it from the circuits section.

January 1, 2006: Happy New Year! The new site is up! How do you like it? It's best viewed at 1024x768 or higher with Firefox. If something appears funky, email me. There were some issues with IE regarding my abuse of tables so it's quite likely some people will experience misaligned tables and images. I'm now being hosted by Hacking Cult -- thanks a lot, drx!

I did a project for one of my EE classes at the end of last semester which was pretty cool and which I'd like to polish up and release. It was a simple "video game system" based on the Z80 microprocessor and the Spartan 3 Starter Board. This particular FPGA board provides a VGA connector which allowed me to connect my system to a standard computer monitor. I wrote a simple display controller in VHDL which provides an interface to the Z80 CPU. The Z80, its memory, and the control pad port were all implemented on a breadboard with discrete ICs. I used a Sega Genesis control pad because of its simplicity and the fact that it uses a standard DB-9 connector. The project was largely a success but there is a persistent glitch when writing to the framebuffer which is either the result of a flaw in my VHDL logic or involves the FPGA-Z80 interface. I would like to fix it before making a release but it has been several weeks and I've yet to figure out what could be wrong.

The problem is that when writes to the framebuffer are made (by the Z80), they are sometimes not committed to memory and the display ends up having "holes" in it. Writing several times to the same pixel will usually fix the problem. The VGA core accepts data through an input port that I designed to be clocked by the Z80's WR signal. I believe I have ruled out any electrical issues although I have observed some problems with using an external input as a clock signal (which is not synchronized with the FPGA's 50 MHz clock) and had to add logic to "synchronize" events triggered externally with the internal clock. The port is clearly receiving data as it should because the internal framebuffer write pointer is always incremented. The problem seems to be contained within two processes: The input port and the SRAM state machines. My VGA core allows writes to the framebuffer to occur during the active display. In such cases, writes are simply supposed to take priority over reads and the pixels output during that brief time will be undefined. Below is the relevant VHDL code with unimportant parts of the input port logic removed to clarify how SRAM writes are initiated. Note that the SRAM write procedure should be the same as Fabrice Derepas' code (one of only two examples I could find for my board), which works.


--
-- Input Port State Machine
--
process(clk_50mhz, input)
begin
    if input(8)'event and input(8) = '0' then   -- input clock, falling edge
        --
        -- Removed some code here and only retained the data write stuff.
        --
        sram_data_write(2 downto 0) <= input(2 downto 0);
        sram_write_addr <= write_addr;
        write_addr <= write_addr + 1;
        write_trigger <= not write_trigger;     -- trigger a write
    end if;

    --
    -- Writes are triggered when write_trigger changes. They are synced
    -- to the main 50 MHz clock here.
    --
    if clk_50mhz'event and clk_50mhz = '1' then
        if write_trigger /= write_trigger_prev then
            sram_do_write <= '1';
        end if;
        if sram_state = SRAM_WRITE then
            sram_do_write <= '0';
        end if;
        write_trigger_prev <= write_trigger;
    end if;
end process;

--
-- SRAM State Machine
--
process(clk_50mhz)
begin
    sram_oe <= '0'; -- OE is always low
    if clk_50mhz'event and clk_50mhz = '1' then
        case sram_state is
        when SRAM_WAITING =>
            if sram_do_write = '1' then -- write requested
                sram_addr <= sram_write_addr;
                sram_ce <= '0';
                sram_we <= '0';
                sram_io_t <= '0';   -- Xilinx IOBUF direction
                sram_state <= SRAM_WRITE;
            elsif sram_do_read = '1' then   -- read requested
                sram_addr <= sram_read_addr;
                sram_ce <= '0';
                sram_we <= '1';
                sram_io_t <= '1';
                sram_state <= SRAM_READ;
            else
                sram_ce <= '1';
                sram_io_t <= '1';
                sram_we <= '1';
            end if;
        when SRAM_READ =>
            sram_ce <= '1';
            sram_we <= '1';
            sram_io_t <= '0';
            sram_data_read_buf <= sram_data_read;
            sram_state <= SRAM_WAITING;
        when SRAM_WRITE =>
            sram_ce <= '1';
            sram_we <= '1';
            sram_io_t <= '0';
            sram_state <= SRAM_WAITING;
        end case;
    end if;
end process;

If anyone has any ideas as to what the problem may be, I'd be very interested in hearing from you.

July 15, 2005: It's been almost a whole year since I've put any work into my dynamic recompiling PowerPC emulator. Since then, Stefano has kept plugging away at his fork of the project and is remarkably far along (his can run far enough into Scud Race to hit floating point code.) A few weeks ago I dug out my project again and have devoted a little bit of my spare time at work to it. Unfortunately, I still can't say whether I'll be able to finish it and resume working on Supermodel because I'm very busy with other matters. However, drppc can now recompile the first basic block of Scud Race (minus the support code which will be needed at the end to transfer control to the next block.) Here are the results:

July 10, 2005: I built a little Z80 circuit which counts up on 3 LEDs. Not very impressive but I just wanted to test out the Z80 since I've never build a microprocessor-based circuit before. Perhaps this project might be of use to other people who are contemplating working with simple CPUs but aren't sure where to start. I hope to perhaps make a complete homebrew computer or some simple robots. We'll see where my curiosity takes me.

June 1, 2005: I wanted to see if I could write a fast Sega Genesis graphics engine with correct sprite priorities without having to write a whole emulator so back in March I whipped up a neat little program, genren, which takes save state files (as produced by Gens and Genecyst) and renders the display to a BMP file. The graphics engine uses 8-bit color and encodes sprite/tile priority information into the unused upper 2 bits of each pixel. I learned this interesting approach a few years ago from Charles MacDonald. Unfortunately this technique does not allow for in-frame palette tricks (such as the water effect in Sonic games) and makes implementing shadow/highlight mode impossible. It would be easy to write an RGB color-mode engine by simply modifying the tile drawing routines, however. genren currently does not support interlace mode, the window, and some miscellaneous features. Maybe I'll update it in the future, maybe not.

August 13, 2004: I've created a page for a dynamic recompiling PowerPC emulator project I'm working on for Supermodel. Currently, we're still in the planning stages but we have written some code to prototype our ideas and we're confident that the project will be successful if we can find time to keep working on it. The project is being discussed on the Dynarec Mailing List.

November 30, 2003: vram2bmp Version 0.2 has been uploaded. It turns out that there was a bug in my code after all. The sprite renderer was ignoring H- and V-flip for sprites as a whole but the tile rendering code was handling H-flip for individual tiles within a sprite. This resulted in some sprite images being drawn incorrectly. The sprite code has been rewritten so that flipping occurs properly along both axes. It should be bug free this time, but you never know... ;)

November 22, 2003: Pascal Bosquet discovered a problem in vram2bmp (my Genesis VRAM dumping program) which caused tiles to appear in an inverted order when using the supplied binary. It was fixed with a recompile so I'm assuming there isn't a problem with the code. I've uploaded a new build which also includes vram2pcx, a modification by Pascal that outputs PCX files. If anyone finds any problems, let me know!

May 12, 2003: The "68000 Undocumented Behavior Notes" have been updated with new information on the BCD instructions. A big thanks goes out to James Ponder for helping out with this update.

January 13, 2003: Added a link to Graham Toal's Static Binary Translation HOWTO which was posted to the Static Recompilers mailing list. It's a very informative read for those interested in the subject and is particularly interesting because it's much more accessible than academic texts on the subject and provides lots of code sprinkled throughout the text.

January 3, 2003: Happy New Year! I'll be spending 8 days in Maui (with no computer access) starting tomorrow.

December 29, 2002: Thanks to Sega Xtreme, I now have a new place to host my pages. Unfortunately, dynarec.com is no more, which means I've got a new email address:

Some of us from the old dynarec mailing list started up a few new lists on Yahoo! Groups which anyone is welcome to join, if they're interested in the subjects (beginners are welcome, but you should be interested in the topic and have some programming experience):

  • Dynarec: Discussion of dynamic recompilation (dynamic binary translation)
  • Static Recompilers: Discussion of static recompilation
  • Compilers 101: A group to discuss implementation of compilers. It's targeted at the beginner level, but newbies and veterans alike are welcome to participate

I've uploaded my old node-based BSP code in the "Graphics Programming" section, below. Now that I'm on vacation until late January, I hope to get some work done on my 3D leafy BSP engine and C compiler. I hope to find time someday to post some pages describing how BSPs work based on my experimentation with them.

[Return to Top] [Home]
Copyright (C) 2006-2007 by Bart Trzynadlowski