news and information, including source repository (soon), has moved to
Invaders (with sound) is running on the RC10.
been just over 1 year but I've finally targeted a project - the NES -
to the RC10. Quite a cool
little board - with an on-board joystick, stereo audio output and the
ability to program the flash with several FPGA images that can be
loaded via a menu. However, without any external memory or secondary
storage it won't be suitable for all platforms.
- Chris has added an (unfinished) square-wave voice to the NES sound
implementation. Sounds reasonably accurate, and once he has finished
that the 2nd square wave is very similar so that will be 3/5 voices
Gubener has released his 68K
core on opencores. I've modified the Cabal project to use it, but
am yet to try running it as the PACE-2 hardware isn't quite adequate -
I'll need Chris' DE2.
has been registering domains and other administrative tasks in order
to get the PACE subversion repository hosted online. That means we
should (finally) have PACE source available soon!
Chris (1-channel) sound module into NES. The Tennis tune is sort-of
recognisable, so that's a good start!
Tennis is running on my new PPU implementation. Added the image (tile)
step is to implement sprites... this will be fun (NOT)...
implemented the PPU registers but Tennis still isn't running...
although I've since discovered that I hadn't hooked up the VBL to the
NMI correctly... I'm sure it's something that I'll resolve soon. Once
the game is running I need to implement the internal PPU palette RAM
and then start on the sprites...
PPU now renders the Tennis tilemap almost pixel-perfectly and can also
be scan-doubled for VGA output. The "almost" refers to the
left-hand pixel, which appears to be rendered from the previous
scanline... but I'm not convinced it's not a scan-doubler problem -
it's too difficult to tell on the the composite output.
step is to implement the palette memory and PPU register interface,
and hook up the 6502 core to see Tennis running...
Didn't achieve much tonight - frigging around with !@#$%^ scan doubler
which didn't work on any of the monitors at work - no idea how it
worked on my Compaq SVGA monitor at home because the clocks were
completely wrong!?! Have added all the cartridge connector signals,
the CPU and some address decode logic and data mux - synthesis still
optimises-out the CPU entirely for some reason... a job for another
I've added logic to calculate the palette for each pixel, but it's
still rendered in greyscale... weird because the attribute byte
appears to be correct (it fixes some of the inconsistencies in the
greyscale image)... not quite sure what is going on...
Tennis tilemap rendered in greyscale with the new PPU...
working on a proper NES implementation, starting with a native (NTSC)
PPU that outputs composite video - so I can scan-double to output VGA.
Right now the video counters and blank/sync signals are generated,
with a test-pattern filling the tilemap area. Currently WIP is getting
it to render the Tennis tilemap from a static VRAM image.
porting Gary Becker's AppleFPGA
to PACE-P2 & DE2. I'm having similar problems to someone else who
has been attempting to port this design. Definitely some weird stuff
Mario Bros is as complete as it'll get. To get it running I had to
implement horizontal scrolling (vertical mirroring), background
colour, Sprite #0 Hit detection and sprite priorities. A few graphical
glitches and the mystery of no title logo (I suspect it has to do with
pattern table mirroring) which I'm not overly worried about (it's
merely a feasibility study) but otherwise completely playable.
don't think I'll pursue this design any further, aside from adding
sound support (Chris?). Next step is to start again from scratch, and
build the PPU as it was originally designed. Not sure when I'll tackle
Crew is complete. It required implementation of vertical scrolling
and horizontal mirroring.
up - Super Mario Bros, with horizontal scrolling and vertical
mirroring. I also need to keep hassling Chris to finish his NES sound
core... although both of us will probably be side-tracked for a week
or two on another project that could turn into real (paid) work.
I can start a Super Mario Bros game. Need to implement horizontal
Chris tells me he has finished the triangle wave generator. 4 more
channels to go...
decided to see how far I can stretch the PACE architecture to emulate
the NES more completely. To this end I've started with "Wrecking
Crew", which ran immediately except for the scrolling tile-map.
I've implemented vertical scrolling, which appears to work, but the
in-game tile-map isn't quite rendered correctly. Still, it's pretty
now starting to think that the NES itself really isn't very
complicated, and I'm increasingly surprised that a NES hasn't turned
up by now in the public domain. I don't think that I need to add much
more to my implementation to complete the core NES emulation.
The devil, of course, is in the mapper variations and a complete
implementation would have to emulate all known mappers and have some
mechanism for enabling the correct mapper when a cartridge image is
Sprites are _almost_ working. There's also an "off-by-1" bug
in the controller inputs which is eluding me...
is working on the NES APU (sound)
Fixed the sprites! Just need sound and fix the controller bug...
Fixed the controller inputs! Tennis is fully playable - aside from
sound the _only_ aspect that is not faithfully emulated is the sprite
palette. I'm using a fixed palette lookup dumped from Tennis running
in an emulator, so the in-game sprite colours are correct, but
unfortunately the asterisk on the title screen for selecting singles
or doubles happens to be invisible.
morning I fixed attribute RAM writes and added palette registers. As a
result, all Tennis tile-maps have correct colours. To do: controller
input and sprites - and sound.
I've added controller inputs. I can start a game but it freezes -
probably unimplemented PPU functionality - possibly to do with the
sprites? I need to add sprites next...
got PACE rendering the NES Tennis
tilemap, with correct palette.
NES Tennis actually runs!!! Yes -
I can't believe it either!!! Next to do is to add sprites, fix writes
to the attribute table, and add controller input - then I should be
able to actually play it.
- We've had a bit of a break from PACE over the last 2 months - doing
small PCBs for other retro projects (here
& here). This trend might
continue for a bit yet... see how it pans out...
implementation of a "NES". I use quotes because initial
plans are to implement only enough logic to see Tennis running.
The assumption is that it uses only the most basic PPU features, and
that I can fudge enough functionality within the existing PACE
architecture without having to actually attempt implementing a PPU as
such - basically I'll be cheating as much as I can.
delivery of a new PACE hardware platform today - hereafter named PACE-P3M. It's a small battery/USB/DC-powered board with EP2C35, DRAM,
FLASH, SD/MMC slot and a built-in 240x320 back-lit LCD display.
Pictures etc to follow.
order of the day was to get Space Invaders up and running!
strictly PACE-related, next order of business was getting DOOM running
on it. Managed to get the hardware side of things ported from
PACE-P2/DE2 - hopefully tomorrow we'll be able to run the actual DOOM
Bally Astrocade running on PACE-P2 and DE2 with sound.
disassembling Cabal in order to help Wolfgang debug the 68K - at least
I know where it's going wrong now...
someone emailed me asking if I had ported MikeJ's Bally Astrocade to
my hardware, I decided to port it to PACE-P2 this weekend. Turns out
it was the only platform not to have been brought across from the old
PACE source tree. Doesn't quite work just yet...
progress on 1541...
last really annoying bug has got me stumped before I can start
removing the NIOS. It appears to be timing-related, which is baffling
because the FIFO in the design should eliminate all such timing
issues?!? Interestingly, Chris has a similar problem with his design,
so perhaps there's a nuance of the 1541 design that we've missed...
is complaining again that my PACE-P2-JAMMA board is holding up his 68K
I started playing with Cabal again, using Wolfgang's 68K core from his
project. I've flagged a few bugs which Wolfgang has been quick to
sort out - and this afternoon I got Cabal running (VBLANK interrupt
and all) for the first time - up to the point where it shows the
number of credits on the screen. Very exciting, not so much for Cabal
but for a few other rather ambitious projects I have in mind...
1541 emulation is now reading the G64 image off Compact Flash. No FAT
file-system - the image is written directly to the media in a
proprietary format - one raw track per 16 CF sectors. The NIOS
software is now written to behave like a potential logic-only design,
which is the next and final step.
too exciting. Finally made up a cable so I can use the Gamecube
controller on the PACE-P2
hardware - have been playing Lode Runner with the (wireless) Wavebird!
Much nicer than trying to use Chris' 20-year-old half-working
joysticks... I should try the X-Arcade
hooked up the OCIDE controller to the NIOS but haven't had a chance to
finish the software to read the G64 image off Compact Flash -
hopefully I'll get the chance this weekend. When that's going, the
last step is to remove the NIOS altogether. Then I'll release the
source for 1541 emulation.
is working on writing to virtual disk images.
at last! The final problem was simply the Track 0 sense
input. Here's a photo of Lode
Runner running on FPGA64 with internal 1541C emulation.
are so close to a working 1541,
it's agony. We've narrowed the problem down to stepping - the DOS
quite happily steps inwards, but has trouble stepping out. It's to do
with the stepper motor controls coming out of the 6522 - they're just
not right... Chris has implemented the entire mechanism in VHDL - it
just needs a memory interface. My version has a FIFO doing most of the
work, still with a NIOS back-end. Next step for me is to replace it
with the OCIDE core and a small state-machine to read G64-encoded data
directly off Compact Flash...
Or part-success at least. I can list the directory on a Lode Runner
disk image, and load the initial program. It brings up the Lode Runner
loading screen, but finally times-out with a disk error. I suspect
inaccurate timing is the cause - a software solution simply isn't
accurate enough. I've started putting more of the logic into hardware.
More details as they emerge...
the lack of progress reports, I have actually been working on the 1541
implementation - progress has been frustratingly slow. I have a NIOS
running the MESS 1541 emulation code, reading a D64 image and GCR-encoding
it sector-by-sector on the fly before feeding it to the 1541 6502. As
of tonight, I can confirm that the DOS is reading at least 1 sector
header correctly, with correct checksum. The behaviour I observe is a
LOAD"$",8 spinning on track 1 for about 5 complete
revolutions before returning a FILE NOT FOUND error. I'm getting
closer at least...
Chris is working on his state-machine (no processor) implementation of
the drive mechanism.
got FPGA64 on the DE2 talking to a real 1541, and although he can list
directories it's still flaky as he can't successfully load a full
fixing a bug in the 6522 core, FPGA 1541 emulation is definitely
communicating with both FPGA64 and a real C64 - the device is present
and the 1541 power-up error message "CBM DOS v2.6 1541"
can be read back from the emulated drive.
step is to emulate a raw disk stream - hopefully the guys from C64
Preservation Project can supply us with a few example images
to try. It'll be interesting to see how critical the timing is for
stuff like the BYTE READY and SYNC signals from the drive logic.
of a 1541 drive inside an FPGA (together with the FPGA64 C64 core) is
going extremely well. I've connected the 6502, ROM, RAM and VIA6522's
and LOAD"$",8 returns "SEARCHING FOR $" - which
means it's talking to the 1541 firmware. Next task is to emulate the
gate array functions and drive mechanism.
is making an interface board that will let us connect a real C64 to an
FPGA-1541, or alternatively, an FPGA-C64 to a real 1541 drive.
MikeJ's VIC-20 to the PACE2 framework. Builds OK but (composite) video
not synching properly. WIP.
& I are looking at implementing 1541 emulation in an FPGA -
reading from Compact Flash and/or SD/MMC card. Ultimately we could
produce stand-alone boards to plug into real C64 units!
Derogee's SID to the FPGA64 implementation on the Nanoboard -
Peter has been updating his FPGA64
(C64) project, and others are playing with it, I decided to finally
port the latest version to the PACE2 framework. Builds but does not
include any ROM images - I need to work out why they're missing from
has also done a SID
implementation in VHDL which I might try to hook up as well.
- Haven’t spent much time
on PACE proper in the last few months, but have been working on
related projects. One involves Tutankham, the other is a port of DOOM
to the NIOS running in an Altera FPGA.
- In the mean-time, MikeJ of fpgaarcade.com
has added Videopac (a.k.a. Odyssey2) and Scramble/Frogger
to his list of releases, so when I had a few minutes spare
here-and-there I worked on porting them to the PACE-P2 hardware. Videopac
is complete, Scramble/Frogger
is done but not working yet.
- Tutankham is working. Now the
fun really begins...
- Started work on Tutankham. The reason I chose this, however, is
actually not for PACE itself but for another project I am working on
which I am not going to reveal at this point. It (PACE implementation)
should be relatively easy, given that it's a bitmap-only display. I've
already got the video display working (no palette) after an hour or
- Decided to have a go at finishing off the Coco. Worked on the 6883
(SAM) and realised there's not a lot to it without the video refresh
logic or the double-speed mode - just a register and a couple of
counters really. I've broken the Coco atm but the 6883 is almost
complete excepting the aforementioned.
- A quick fix to the ZXGATE TRS-80 character ROM - copying the data
for character codes $40-$5F down to $00-$1F results in a legible
display in Level II ROM BASIC.
- Fixed the PS/2 problem - the "1us" tick was actually
around 750ns - as a result the PS/2 clock was out of spec for one of
my keyboards. Increasing it to around 1us solved the problem.
- Finally got the scan doubler working with the ZXGATE version of the
TRS-80 (60Hz). Ended up using a tweaked version of the doubler from
the fpgaarcade Space Invaders project. Now for some weird reason PS/2
input is suddenly broken...
- I ported the Space Invaders from fpgaarcade (again) in the
process of studying the problem of running the design without any
internal memory resources (except for the scan doubler). The design
holds off CPU RAM accesses - but not ROM accesses - if the video is
fetching from RAM. Hence the problem. In theory you could do the same
for ROM accesses, but I haven't tried it yet.
- Asteroids is working and the display is surprisingly decent
considering the implementation uses only an internal 24kB RAM block
for the video. The display is reduced to 512x512 and the phosphor
decay is simulated by simply erasing the screen from start-to-end one
byte for every 2 pixels drawn. It flickers a bit but still looks
pretty good all things considered...
- Taking a leaf out of Eric's book, I've simulated MikeJ's Asteroids
Deluxe core. I wrote a small program to display the output
of the 1st 1,000,000 unique vectors. Next step is to calculate pixel
rates and put together something in the FPGA...
- Started porting MikeJ's Asteroids
Deluxe after reading of Eric's
experience with it
as well. I don't think I have the right hardware to make it playable,
but I should get some sort of display running, so it's more of a
learning exercise than anything else.
- Brought the AdventureVision port up-to-date with the new framework.
Only a handful of platforms remain to be updated.
- ZXGATE TRS is still giving me grief - no keyboard input and the
scan-doubler doesn't sync. Argghh!!
- Brought the Colecovision port up-to-date with the new firmware
- Finally, managed to get 1-chip MSX (OCM) working.
Yes, the ROMs are loaded from the EPCS4.
- Figured out how to change the address of the MSX ROMs in the EPCS
device. I can now fit both the EP2C35 design and the ROMs into the
EPCS16 and have it boot (after a manual reset).
- Added some text/html
notes on porting the OCM.
- Started porting the 1-Chip MSX design to PACE-P2. I can get the OSD
(On Screen Display - a dump of the VDP register values) showing on
VGA, but no way of booting the ROMs yet. Information is scant, but I
believe the ROMs are read into SDRAM from the EPCS4 configuration
device by the 512-byte IPL ROM.
- Attempted to add a the scan-doubler from Arnim's Ladybug design to
the ZXGATE TRS design. Not very successful yet -back to simulation to
look at sync frequencies etc.
- ZX Spectrum now running (helps if you connect the RAM address bus)
but video is rolling.
- After I fix the video problem on the Spectrum, I'll get to work on
the Jupiter ACE.
- *Update* A productive evening -
I fixed the Spectrum video issue and also ported the Jupiter ACE and
TRS-80 implementations to PACE-P2. All had to be modified slightly to
produce composite sync.
- ZX81 is now working. I had to change the original design slightly to
generate true composite sync.
- ZX Spectrum (ZXGATE) is
WIP. Video is rolling and screen filled with (coloured) garbage.
- Attempted to port the ZX81 project from ZXGATE
from scratch again - I was unsuccessful last time. This time I at
least get video - albeit what is seemingly a single-character-high
white line across the bottom quarter of the screen, which changes when
I type on the keyboard. I had to modify the source to generate
composite sync - I think that's still not quite what the ADV724 is
- Fixed the VGA output for the Lady Bug games - thanks for the tip
Arnim! Picture-perfect now!
- Re-ported John Kent's System09 to the new firmware architecture and
- Completed ports of Lady Bug, Cosmic Avenger and Dorodon - both
composite and VGA output versions.
- Chris finished the Gamecube controller module and we integrated it
into the PACE project tonight. Input options now comprise PS/2, Maple
Bus (Dreamcast) and Gamecube controllers. Here's a picture
of Pacman on the DE2 with the Nintendo Wavebird controller connected.
- I haven't had much luck with Cabal. I'll hand it over to Chris
whilst I finish my JAMMA PCB layout.
- Had a bit of time to kill so I thought I'd port Arnim Läuger's
Lady Bug to PACE-P2.
- Cosmic Avenger and Dorodon are WIP (Lady Bug hardware).
- I've was inspired by someone working on a non-related Donkey Kong
project to re-attempt to port Katsumi
Degawa's Donkey Kong to PACE-P2. This time I was successful
- it was trivial in the end...
- Chris wanted a lesson in starting a port of an arcade game - so
tonight we ripped the text and background tile graphics from Cabal and
built a project to display the text RAM contents on a VGA monitor. The
rest is now up to him... ;)
- Been working on hardware
- Since there's been a lot of activity on the Coco mailing list lately
concerning development of an 'enhanced' Color Computer, I thought I'd
finish porting my WIP Coco project to PACE-P2. As a first-pass effort,
it outputs composite PAL 60Hz. As you can see,
there's issues with the video generation, but it's running...
- Added support for the JAMMA interface to the PACE framework. JAMMA
inputs operate in parallel with the PS/2 keyboard inputs.
- Added Chris's MapleBus (Dreamcast) interface to the DE2 project.
This comprises support for the Dreamcast Controller peripheral
(currently only the Astropad is working) which emulates the JAMMA
- Added 'JAMMA' support for a number of games, including Pacman, Space
Invaders, Galaxian and Moon Cresta. These games are now playable on
the DE2 using the Astropad.