Jump to content
Lorin Millsap

How to implement slow chips on expansion cards

Recommended Posts

Just for fun and because it has been asked a few times I want to explain what would be required to use a VIC-II or SID or really any chips that are too slow under normal circumstances. I’m not saying either of these is really a useful idea, but it makes a good introduction to how to use such things on expansion cards. Also up front this article is going to use layman’s terms but is still geared at those interested in hardware.

 

Since it’s the less complex option, I’ll start with how you would use a SID chip. Probably the best point to emphasis because it affects any chip you want to interface to the bus is the access window. The CPU in the x16 uses half cycle access for memory or IO. This means that in each clock cycle the first half of the cycle is spent doing internal processor stuff and setting this up for the actual bus access. During the second half of the cycle the cpu performs either a read or a write access to memory or IO. This time we will refer to as the access window. And all chips on this bus need to be able to respond to read/write operations within that window.

 

So how long is this access window? Well it is measured in nanoseconds. To give you some context, if you have a clock running at 1 MHz, there are exactly 1000 nanoseconds in that one cycle. So if our cpu was running at 1 MHz our access window would be slightly less than half that, about 500ns. If we increase to 2 MHz that access window decreases to about 250ns. However I’m doing a rough approximation because there are some factors that also affect how much of that access window is really usable. There is address deciding aka glue logic that reads which address the cpu is trying to address and then selects or enables the appropriate chips. This process is not instantaneous, and the amount of time it takes for the inputs address lines from the cpu) to the outputs (chip select lines from the logic) is going to be referred to here as propagation delay. This delay is also in nanoseconds and for the sake of simplicity we are going to state this value as 20ns.

 

So with this value we will then see our usable access window at 1mhz is closer to 480ns and at 2mgz would be closer to 230ns. So let’s consider this for the 8MHz that the x16 runs at. We get an nominal window of 62 nanoseconds but an effective window of 42 nanoseconds.

 

So what this means is that any chip that will connect to the bus, be it RAM, ROM, IO chips, video chips, audio chips, etc. must be able to respond to a read or write in less than 42 nanoseconds in order to work reliably. There are ways around this and I will get to them later, but I’m just making the point that any chip that connects directly to the system bus must be able to respond within that access window.

 

In the case of a SID chip I’m not sure what it’s access time is, but it’s likely in the 150-200nS range. So it would work at 1-2 MHz reliably and might work with 4mhz. But it won’t work reliably on an 8mhz bus without some type of buffering.

 

So if you were to implement one, you have several option on how to go about it. If you aren’t concerned with reading the chip, then you could use latches. You would need to latch the data and the address and implement some type of timer to extend the hold time. What you are doing in this case is that instead of interfacing to the SID directly you are instead interfacing to a simple latch which just captures the relevant address lines and the 8 bit data. This buffer then outputs those values for as long as needed.

 

To enable the chip to be read requires some additional circuitry. This method can actually be used for both reads and writes and involves halting the CPU to extend the access window across one or more CPU cycles. Basically when an access occurs the RDY line needs to be pulled low while the BE (Bus Enable) line is pulled high. This causes the CPU to be halted in its current state. Using binary counters we can hold this state for as many cycles as we need. Keeping in mind for an 8 MHz bus if we extend the acces by just one cycle what we actually get is 42ns+125ns for a total of 167ns and if we need more time we get an additional 125ns for each cycle we extend that window by. Keep in mind this method does require the use of bi-directional tranceivers or equivalent.

 

Now to use the VIC-II chip is quite a bit trickier. Basically the main issues is the VIC-II needs access to memory. Since there is no way you could make it play nice with the X16 memory space you’d need to give it its own memory. You would need to design some kind of circuit that would act as a bus bridge. this bridge would have to facilitate both reading and writing to the Vic-IIChip-II chip itself but would also have to act as an indirect memory window. This is doable but is not a lighthearted undertaking. I’m not suggesting anyone actually tackle this I’m just saying that it is possible and that this is what would have to take place.

 

I feel I should also add though that doing these things would not make the X16 capable of running C64 software. i’m merely laying out what would need to take place to make it possible to interface with these chips not what would need to take place to emulate another system. This is just a fun thought experiment and a good opportunity for me to explain how it would be done.

 

One follow up too, this is by no means a definitive guide on the actual timing requirements. The reality is the timing is probably more forgiving that what I’ve stated here, my 20ns example is more like a worst case scenario. We don’t have hard figures on the actual timing yet, for that we need to finalize all details of the board and measure multiple samples at different temperatures and voltage ranges. .

 

 

Sent from my iPhone using Tapatalk

  • Like 4

Share this post


Link to post
Share on other sites

Follow up on the SID chip access time. I can’t hold this as definitive, but one datasheet lists the access time as 350ns which means even 2mhz may not be reliable.


Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites

Thank you; I've a had a project in mind for quite a while, one where the retro chip I'll be using runs at 4MHz - I'll need to check the specs again to see what kind of window I'm dealing with, but I'm glad there may be a simple solution to at least make it work, even with the performance hit. 

Share this post


Link to post
Share on other sites
5 hours ago, Lorin Millsap said:

We don’t have hard figures on the actual timing yet, for that we need to finalize all details of the board and measure multiple samples at different temperatures and voltage ranges. .

While a full characterization at some future point will be great, there is an easy way to help expansion card designers now.

1. Specify the voltage (5V, +/- some tolerance if you want to get fancy)

2. Specify the clock waveform (8MHz, 50/50 duty cycle I guess?)

3. Publish a schematic of the logic between the 65C02 and the expansion slots.  Everything else can be omitted.  There should be no secret sauce here, it's just simple glue logic.

I think that covers the most important stuff.  I'm sure someone will chime in if I forgot something.  Anyone capable of designing an expansion card should also be able to derive the timing requirements from the above information and device datasheets.

Obviously the logic and timing is subject to change.  Anyone designing to a moving target needs to embrace the possibility of breakage in the future.

Share this post


Link to post
Share on other sites
While a full characterization at some future point will be great, there is an easy way to help expansion card designers now. 1. Specify the voltage (5V, +/- some tolerance if you want to get fancy)

2. Specify the clock waveform (8MHz, 50/50 duty cycle I guess?)

3. Publish a schematic of the logic between the 65C02 and the expansion slots.  Everything else can be omitted.  There should be no secret sauce here, it's just simple glue logic.

I think that covers the most important stuff.  I'm sure someone will chime in if I forgot something.  Anyone capable of designing an expansion card should also be able to derive the timing requirements from the above information and device datasheets.

Obviously the logic and timing is subject to change.  Anyone designing to a moving target needs to embrace the possibility of breakage in the future.

 

Ok. Sure.

 

1 Voltage is 5v. Tolerance is 10%

2. 8MHz clock with a 50-50 waveform. I do not have specs for the Rise/fall time at the moment.

3. The only glue logic on the expansion bus is the IO address decoder. I’m not sure what the real propagation delay is but it’s safe to assume 20ns.

 

 

Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites
4 hours ago, Lorin Millsap said:

it’s safe to assume 20ns.

Is it?  It is hard to judge without seeing the logic.  20ns sounds reasonable-ish for typical delays.  It sounds low for worst-case delays. Consider letting expansion card designers decide how aggressive they want to be with the timing.

I am puzzled why you mention BE in your example.  Most expansion cards can ignore BE (leaving it undriven).  Only cards that need to drive the address bus need to drive BE low to take control.

Share this post


Link to post
Share on other sites
Is it?  It is hard to judge without seeing the logic.  20ns sounds reasonable-ish for typical delays.  It sounds low for worst-case delays. Consider letting expansion card designers decide how aggressive they want to be with the timing.
I am puzzled why you mention BE in your example.  Most expansion cards can ignore BE (leaving it undriven).  Only cards that need to drive the address bus need to drive BE low to take control.

I only mention it because a DMA scheme would pull it low and the line is present. For waitstate you don’t want to use it, for DMA you do.

As to letting designers decide how aggressive to be, we don’t know how close you can push it but it’s best to meet the criteria we will spec rather than the absolute limit. Some machines will be more forgiving than others depending on factors like the chip run, temperature, humidity, voltage, etc. the requirements are way tighter on 65xx systems than with comparable intel, Z80, of 68k systems. I’m just trying to say that when people are designing cards they need to take the safety margins into consideration. If you have a chip that needs 50ns to work reliably and it exceeds the 42ns window it would be better to buffer or plan on wait stating than to gamble that it might work most of the time.


Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites
23 minutes ago, Lorin Millsap said:

As to letting designers decide how aggressive to be, we don’t know how close you can push it but it’s best to meet the criteria we will spec rather than the absolute limit.

I agree, assuming you correctly specify the worst case timing.  Like I wrote before, I am dubious “assume 20ns” meets that criteria.

Sorry, I can’t help being picky about timing, what with it being my livelihood and all.

Share this post


Link to post
Share on other sites
I agree, assuming you correctly specify the worst case timing.  Like I wrote before, I am dubious “assume 20ns” meets that criteria.
Sorry, I can’t help being picky about timing, what with it being my livelihood and all.

All I can say is we don’t have a solid figure on that yet. When we know that for certain we will publish it in an official spec sheet with timing charts.


Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites
11 hours ago, Lorin Millsap said:

Follow up on the SID chip access time. I can’t hold this as definitive, but one datasheet lists the access time as 350ns which means even 2mhz may not be reliable.


Sent from my iPhone using Tapatalk

2MHz should be reliable enough. C128s were sold with both models of SID chip, and those were definitely used at 2MHz. 

It sounds to me like a first task for third party developers would be to build an 8:1 clock divider, along with some sort of buffer to read from the CPU bus and stretch that cycle on the expansion card side. If we're only talking about writing data (to a SID or VIC), then that should actually work fairly well. I'm just not sure what kind of hardware that would require - I expect a CLPD would be the device of choice, with address and data latches. 

I think I even have a process to make it happen, but I know nothing about programming CLPDs. 

 

Share this post


Link to post
Share on other sites
2MHz should be reliable enough. C128s were sold with both models of SID chip, and those were definitely used at 2MHz. 
It sounds to me like a first task for third party developers would be to build an 8:1 clock divider, along with some sort of buffer to read from the CPU bus and stretch that cycle on the expansion card side. If we're only talking about writing data (to a SID or VIC), then that should actually work fairly well. I'm just not sure what kind of hardware that would require - I expect a CLPD would be the device of choice, with address and data latches. 

I think I even have a process to make it happen, but I know nothing about programming CLPDs. 
 

Well if you are using logic chips, all you need to divide the clock is a binary counter or a few flip-flops. For your buffer all you need is a few latches. Then a few minor supporting gates and flip-flops and you could do the simple interfaces without any programmable logic at all. Consider all of our glue logic on the main board is done with common logic chips and no programmable logic. The bus clock is present on the expansion connector.


Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use