MOS 6526 CIA as a FPGA

jc2048  wrote:

When you're developing it, you can do it piece by piece rather than doing the whole design and then trying to make it all work. Indeed it will be better like that. Get a simple bit going first and then build on it. The bus interface has to be first because its shared by everything. After that, the simplest output is the I/O port since it's only some latches (the tri-stating happens at the FPGA's I/O pins and is very simple to do). Get that working so that you can write to it and see the data appear and read from it and get correct data back, then move on to each of the other parts in turn. That makes the testing more manageable as you focus on one part at a time.

 

At the present time, from the datasheet and the research from Wolfgang Lorenz, I have been doing just that as you've suggested. I have gone function by function and simply mapped it out and drawn to which I believe in this journal that I keep of all my projects. The system data bus, as you're saying, has been the easiest to track thus far and just seems like connections to the 6510 in the system. I had also thought if I can make a test verification board with an actual 6526, I could extrapolate a bit with the readings I would be getting off a scope so I would how things are being edge-triggered. I imagine all that would be is the 6526 broken out by its pins, ports and buses and tested for signalling in one of two states from the other gates that are related to them.  

 

Timing might cause you a few problems. The FPGA will be much faster than the old device, so by comparison things happen almost instantly. The most obvious problem on the bus side is the data hold time when reading from the device. The FPGA will tristate in a few nanoseconds after the phase two edge, so you're going to have to contrive some way to extend that to the original minimum time otherwise other chips in the system won't have time to latch the data. (One way you might consider would be to lock an internal clock to 16x the phase two clock and then use that to time the extra delay that you need.)

 

So far in the 6526 datasheet I have seen the timing and it is in means of nanoseconds. I have never messed with a FPGA before, so I cannot believe how much more faster these gate arrays can go. Though if they are going faster and the chips wouldn't be able to latch properly, and needing to to 16x fast then the phi2 clock, perhaps something like a PLL would be able to do that? That's the only device that coming to mind being here in a radio shop. 

 

 

The FPGA has flip-flops as part of the fabric - you don't have to build them from logic gates. They have asynchronous set and reset, but can also be used as clocked D-types or JK or T (you get to choose - the FPGA is designed so that they can be individually configured as any of the standard types). If you use VHDL, the synthesis will do that for you and pick whatever is appropriate (and most efficient) to suit what you describe as the behaviour. If you're saying that some of the original is asynchronous and depends on natural delays in the chip, you're going to have to move away from that and go for a properly clocked design. You'd find an asynchronous design very, very difficult to manage in the FPGA because you don't know how the timing will fall for a particular synthesis and mapping run and trying to constrain the timing gets complicated very quickly.

 

In the Wolfgang Lorenz research, I was finding out most of the flip flops are edge triggered. Which edge I am not certain yet, but the ^ on the flip flops was a dead give away and something new that I learned last night lol. I was thinking of S/R but thinking of it more, I think either D-type or J/K might be more appropriate to accommodate the clock, and it might be set up in a Master-Slave kind of configuration that's going into a specific bit decrement counter; sometimes it's been two or three that I believe I am reading here with a tri-state buffer in between the flip-flop. I do hope a synchronous operation will prevail, though then again I have never done anything like this, even though whatever it turns out I do have some references to either/or, so in relation to the FPGA hopefully I'll have some of my hair left if attempting to do so. 

 

 

When you're developing it, you can do it piece by piece rather than doing the whole design and then trying to make it all work. Indeed it will be better like that. Get a simple bit going first and then build on it. The bus interface has to be first because its shared by everything. After that, the simplest output is the I/O port since it's only some latches (the tri-stating happens at the FPGA's I/O pins and is very simple to do). Get that working so that you can write to it and see the data appear and read from it and get correct data back, then move on to each of the other parts in turn. That makes the testing more manageable as you focus on one part at a time.

Timing might cause you a few problems. The FPGA will be much faster than the old device, so by comparison things happen almost instantly. The most obvious problem on the bus side is the data hold time when reading from the device. The FPGA will tristate in a few nanoseconds after the phase two edge, so you're going to have to contrive some way to extend that to the original minimum time otherwise other chips in the system won't have time to latch the data. (One way you might consider would be to lock an internal clock to 16x the phase two clock and then use that to time the extra delay that you need.)

The FPGA has flip-flops as part of the fabric - you don't have to build them from logic gates. They have asynchronous set and reset, but can also be used as clocked D-types or JK or T (you get to choose - the FPGA is designed so that they can be individually configured as any of the standard types). If you use VHDL, the synthesis will do that for you and pick whatever is appropriate (and most efficient) to suit what you describe as the behaviour. If you're saying that some of the original is asynchronous and depends on natural delays in the chip, you're going to have to move away from that and go for a properly clocked design. You'd find an asynchrounous design very, very difficult to manage in the FPGA because you don't know how the timing will fall for a particular synthesis and mapping run and trying to constrain the timing gets complicated very quickly.

Sorry I didn't get back to you sooner, fell into a funk here, not because of the engineering, just other worldly things.

I like what you're saying here. So from the datasheet I have sectioned it out like puzzle pieces and included what pins do what and how they all work. So far the only confusing part was the handshaking with /PC and /FLAG and that all seems to be triggered on negative edges and the /PC just runs for one clock cycle making data ready or accepting it, so I believe.

Been reading the Write and Reading timing diagrams and there is a lot going on with pulses and such and how fast this is all happening. If I know how to simulate this it would be helpful, seeing I am more visual than comprehending this all abstractly. WIth Xilinx I was watching some videos where it was using their ISE and Webpack was involved where schematics were being created. I have this research from Wolfgang Lorenz which shows the 6526 purely software, except the serial port and TOD. I'm waiting for my FPGA now so I can get my hands on the software and see what I have here in a simulation sense. I believe mostly I am working with S/R flip-flips and something about a decrement counter and some tri-state buffers from the looks of things.

If I do figure this out I think I should get my engineering badge too LOL. Thanks for your help!

The block diagram is high-level and conceptual, it's not meant to tell you how it's implemented. Back then, it was meant to be an aid to understanding for a design engineer using the chip or a programmer understanding what they were doing setting the registers.

You're in the situation where you're reverse engineering the device. The different blocks will function differently from each other. The ports will  be latches. The serial port will be a shift register, with parallel load and store for the data-bus side and the serial in and out connected to rx and tx. The counters will be, er, counters (carry on like this and I'll earn my engineer's badge).

You'll need to work in from both sides, on the one hand the register access from the processor buses and on the other back from the IO pins, and try and make it all match up. You've got a reasonably good spec to work with - the datasheet will do a reasonable job of showing you what the chip should do if you get it right. The trickiest bit may well be some of the details of the timer circuits and how they trigger other parts.

It always used to be the case that you could do a design using purely schematic-capture in Xilinx Webpack, if you wanted, but I'm not familiar with the latest design suites, nor what their competitors allow, so don't quote me on that. If you have the confidence to do this as hardware design with logic, you probably wouldn't find it too difficult to master VHDL.

O h yes, I do have it all printed out and in front of me. That's presently what I have, ports A and B plus the timers. That's where I am going to make a schematic of some sort.