6502.org

A back-burner project of mine is implementing a 6567 series compatible replacement. The component would be FPGA based. It would be register set and functionally compatible but not bus cycle accurate. Output would be VGA / HDMI, no composite.
The 6567 works on the basis of sharing the bus during odd and even phases of the 02 clock. Rather than do this I would have the core track writes to external DRAM and mirror the writes to a 64 kB dual port ram in the FPGA. That way it isn’t required to share the bus between clock phases. And the FPGA could access the memory at full speed. It would speed up the system slightly because there would be no “badlines” required for character fetches. It would also allow for a scan-rate conversion.
But the pinout for the 6567 doesn’t include all the signals necessary to do this. In a C64, the *CASRAM signal and the two highest order multiplexed address lines would have to be fed via jumpers to the board. Other signals may need to be jumpered as well such as the *CHARROM signal. The reset signal to the processor would have to be delayed until the FPGA was ready.
It’s not too bad to jumper three or four signals, but I’m wondering what else I missed.
The replacement would also generate 02 at a slightly different rate (33.3333MHz/32 = 1.04MHz) and the dot clock signal (8.33MHz) which would have to be disconnected in the C64. The reason for the slightly different clock is the FPGA would have it’s own 100MHz osc. and the VGA dot clock is 33.3333MHz.
A couple of links:
http://www.syntiac.com/fpga64.html
http://unusedino.de/ec64/technical/misc ... c656x.html
http://github.com/robfinch/Cores/blob/master/FAL6567

Interesting idea to shadow the CPU's writes!

This is an interesting idea. I do have a few questions, though.

I'm not sure I understand why you would need to jumper anything if you're going for a drop-in replacement? For example, when we talk about the F18a, which is a drop-in replacement for the TMS9918, there is no need to jumper anything. You literally pull out the old TMS and plug the F18a in.

Second, removing bad-lines will effectively render many C64 games unplayable. Not all. But *many* of them. Especially the more advanced/popular ones like Turican. Same goes for the popular demos.

Please don't take this as negative criticism. I *want* this project to come to life! In fact, I thought about doing the same thing for the VIC chip in the VIC-20. I would personally start with the VIC-20 because it's not as advanced as the VIC-II....and I'm an FPGA newbie.

In case you don't know, I collect vintage computers and have been programming the C64 since I was 12. If you ever need any help with this project, I'd be glad to offer some.

A simple drop-in replacement is actually more of a challenge to do.
I wasn't planning on just a drop in replacement, but hopefully an enhancement as well. The circuit also shadows the system RAM / COLOR RAM and possibly the CHARGEN. The VIC chip pinout doesn't have access to the full RAM addressing. It can't write to the RAM for instance. The reason for shadowing memory is that it may allow additional graphics effects, more sprites for instance, or a line draw accelerator. Running against an internal block RAM it may be possible to access it several times during a 02 clock instead of just once.
Another consideration is RESET. The VIC chip generates timing signals for the system (02/ras/cas)which can't run without those signals. Since the FPGA takes time to initialize the system would have to be held in reset by the FPGA. Hence there is at least one jumper to the thing. Much to my disbelief there isn't a reset signal going to the VIC. The TMS9918 is just about as isolated a component as could be made which makes it easy to incorporate in a system. It just looks like an I/O port. The TMS9918 doesn't control anything in the system, it's a simple slave device. Something like the VIC chip acts as a system bus master.
It isn't impossible to make a version which is a simple drop-in replacement but then it wouldn't be any fun as it'd pretty much have to be identical in operation to the original. The color encoding circuitry for NTSC / PAL operation would add to the cost. It would be a lot less expensive to just to get replacements of a real VIC chip. Any idea what the F18a sells for ?
I may have to work on a bad-line emulation then. An emulation of the bus activity of the VIC chip could be made. But I suspect that some games will be broken. The problem would be that the bus activity might not be synchronized to what's being displayed.

Backward compatibility is a real bind! It makes all these kinds of improvement projects much harder than they would otherwise be. That's as true today as it was when Commodore were trying to make successor machines themselves.

The F18a has this issue as well. Although, I haven't personally seen it yet. But it takes 50-100 millis or so to boot up when the host device is ready in microseconds. This is unfortunate but not a big deal as users typically perform a soft reset when this happens.
One of the massive appeals to the F18a (and why I bought one) is the VGA output. For me, personally, VGA makes more sense on a retro computer vs. a retro console like the ColecoVision. But, to each his own. The fact that I get 100% compatibility with a super-crisp image on my TI994/a and VGA monitor is amazing.

However, as you probably know, the F18a does more than just provide backwards compatibility. It also enhances the TMS in many ways. Such as an embedded CPU to perform graphics tasks (much like the copper list in the Amiga). But that CPU runs at 100MHz. Other things like smooth scrolling, an extra playfield, 32 sprites on a single line, etc.

So I certainly get why you would want to enhance the VIC-II.

Again...my personal opinion....not having 100% backwards compatibility may restrict who would buy your product. Of course, you may not be interested in that. Maybe you're doing it for your own desires and there's certainly nothing wrong with that. But the reason I haven't tackled the same project myself is that I know it is very difficult to get that 100%. And I'm just not good enough for that. But just thinking about a good VGA (or HDMI) output on a C64 with all the same raster effects is something I would buy.

Well, I won't argue that. But I didn't buy the F18a because I needed a cheap TMS replacement (I have many). I do wonder, however, if you could use an AD725 or something similar? Or, better yet, forget NTSC completely and just use VGA/HDMI?
Yes, they are expensive. But everything in this hobby is expensive. But the F18a's cost is understandable. The FPGA alone is a large chunk of the cost. It's $23 or so the last time I checked. And, the man has to make a little money.
May not be much you could do about that. If your product became popular, I imagine some of the broken games could be patched to work with your device.

Heck, many games aren't compatible on every C64 anyway...even the real hardware. The biggest issue I have is most of the best games are PAL only. Or, have poor NTSC "fixes". That's why I own a PAL version of the C64.

Please keep us posted on this project!
Very true. Even the C128 isn't 100% compatible. Heck, the SID chip came in two versions and I think there are incompatibilities there too. But my original point is that, unless Rob is doing this for his own needs and doesn't care about selling it to the "masses", then not having a large compatibility with games could hurt his appeal for buyers.

And the C64 is a hard target to shoot for. It's so much more advanced than the other 8 bits out there...with the possible exception of the Atari. Atari is more advanced than many people give it credit for.

Yeah, being backwards compatible is almost double the work. It may be simplest to create two controllers one for backwards compatibility and one with new features.

Using internal ram and VGA output I calculated there should be enough memory bandwidth to support 64 sprites. The display logic might not be fast enough though. -> Supporting more sprites means implementing register pages to access the sprite characteristics. The controller should also be able to support higher text resolutions (80x50).

Initially, rather than develop FPGA board hardware, I'm thinking of making up a break-out type board for the VIC chip, with only level translators and pmod connectors. The connectors could then be cabled to something like the Arty FPGA board.

I also disposed of my C64 a few years ago after many years sitting in a closet. So I have to get another machine for testing.

I may have to backtrack on the idea of using a shadow ram. After reading more about the VIC and tricks that could be done with it, I think the shadowing idea would be too incompatible with existing software. Backwards compatibilities. If the FPGA were large enough both compatible and incompatible controller could be included.

I've been studying the VIC-II circuit for FPGA64 (Peter Wendrich (pwsoft@syntiac.com)'s circuit).

I'm not quite sure how I want to approach the circuitry to get it to do what I want.

I have some thoughts on implementing sprites using paged mode to double the number of sprites, but I wonder how to maintain backwards timing compatibility.
I think the hardware should be able to do it, but the only way to know for sure is to build the sucker and try it.

I just spent three hours trying to figure out why the raster 'Y' counter was updating at only half of the horizontal frequency only to realize I was looking at the wrong horizontal sync pulse and it was working after all.

Made some progress on the 'back burner' project in terms of developing the RTL logic. I wrote a wrapper that wraps up the FPGA64 video core to make it look like a VIC-II chip. It incorporates timing signals and a scan convertor. Got the memory access setup to use page mode for sprites. It's about 3,000 LUTs and 80k block ram. (Should fit into a Xilinx 7a15)

This is awesome. Looking forward to seeing this project evolve.

Made up a schematic for FAL6567. Depends on an CModA7 FPGA module, but it would work with any FPGA module with enough I/O and resources onboard. Note it really needs more I/O's. Every single one is used and only eight bit VGA is supported.
The "LS" parts in the schematic are really LCX parts which can be powered by 3.3V and tolerate 5V on the I/O's. The 3.3V supply isn't critical so it's generated from 5V via some diodes. Floating point co-processing is under consideration. It's the kind of thing that only requires registers mapped into the memory space.

Revised schematic, noting that 2 I/O's on the CMod are analog. Down to 6 bit VGA.

Can't read it because of the colors.

Sorry, I did not realize that color would not come across.

Hi Rob,

Did you get any further on this core? I would like to test the core as part of a 6502/FPGA extension to an old machine. Basically my first would be to get VGA output, then to make it somewhat C64 compatible. By also including a 6502 core into the FPGA I was thinking that you wouldn't need to shadow the RAM as its already in there (and can be configured as dual-port).

What do you think?