Jump to content

Lorin Millsap

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Lorin Millsap

  1. 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
  2. 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
  3. The required hardware is already present. The YM-2151 and the SAA chip aren’t designed for it either. The requirements are minor. Sent from my iPhone using Tapatalk
  4. Ok. So just to sum up where the RS232 serial (not to be confused with the IEC serial) is at, it is implemented as part of the user port and is implemented via one of the 65c22 chips. A lot of that is not set in stone as the routines haven’t been written yet. But that is the functional RS232 serial on the main board. Faster RS232 can be implemented via an expansion card. Such a card will probably have more to it than just a UART. I would imagine that it would have a modern UART chip, the voltage shifting and a 9 pin serial port. Then connected to that it would make sense that it had an ARM Cortex based interface that handles the higher level web interfaces and emulates AT Hayes protocol and it would have both an ethernet port and Wifi. This would use existing open source options. It just wouldn’t make sense to make such a card unless it was more than just a UART. Since ROMs can’t be easily put in the expansion bus there are several methods for handling the driver. Method 1 is that the KERNAL interface software is put on the SD card and the BOOT file loads the patch in during startup. This would make such cards usable in BASIC. Method 2 is that you don’t automatically load the driver at all. But rather software that uses RS232 could load the driver when it’s needed. A suggested method for that is to place the files in a directory such as /drivers/rs232/ and software that uses it can search for an executable in that directory path and run it. Method 3 which adds complexity to the card, is that a microcontroller on the card could do a DMA operation and inject code into system memory. During this operation the CPU is inhibited while the microcontroller accesses system memory. While this may sound like an appealing plug and play option it has drawbacks. Firstly making sure it’s code injection plays nice with other hardware and that it doesn’t use memory reserved for other purposes. Also if something does go wrong it’s possible for the card to lock up the system. In reality this method would likely be a real-time compiler so that the generated code could be relocated. It can be made to work, it’s just in my opinion more complex and more likely to cause issues versus loading the driver from the SD card. If it becomes corrupted it would be harder to fix. Sent from my iPhone using Tapatalk
  5. ST16C550 should work fine. It’s one choice out of many. Sent from my iPhone using Tapatalk
  6. Ok. Thanks for clarifying that. Regardless the point of a UART is it is supposed to reduce CPU overhead. If you have to time your loops that isn’t going to give much gain versus the properly working 6522. Sent from my iPhone using Tapatalk
  7. It’s on the 6502 groups. I don’t have a link offhand. Basically the main one deals with the IRQ not properly clearing which basically means you have to sit there and pull the chip. I don’t know why people keep bringing the 6551 up though. There are parallel bus compatible chips that are faster, cheaper, and have more features that are in active production. They are not readily in a DIP package unfortunately, but you can get them in PLCC which means you can get a through hole socket. Sent from my iPhone using Tapatalk
  8. Indeed. Until we do more testing we don’t know what speeds will be possible. Ultimately for most uses the speed may not be highly relevant. Sent from my iPhone using Tapatalk
  9. There is no currently available 6526. If you look in their list of chips, the 6526 is absent. The constraint on the IEC bus speed is limited by the processing power of the legacy devices. Sure in theory the x16 can do higher speeds, but only if it was talking to a device that was as fast as the x16. Since no such device exists, what’s the point? Because of the way the IEC is wired there really isn’t a way to use it differently. Sent from my iPhone using Tapatalk
  10. There are multiple UART options that are better than the 6551. There are ones that are faster, have more features, some even have multiple UARTs, and they are less expensive as well. Sent from my iPhone using Tapatalk
  11. The ACIA was never in the design because CIA chips haven’t been made since the C64/Amiga days. The VIA has a working shift register. However it has to be compatible with real legacy devices so if still has to follow the timing rules. So it really doesn’t matter what the theoretical speeds are. In theory you can go faster with custom routines in both devices. For networking you probably aren’t going to want to use the serial port. There will be software supported lines on the user port for RS232. Alternately you can use a proper network interface card which should be capable of 128kbps or higher. Sent from my iPhone using Tapatalk
  12. The problem is that other brands are not really an option as they are not in active production and the vintage ones don’t have the speed rating. The other modern UARTs are better in pretty much every way. They have larger buffers, they can handle greater speeds, they don’t have hardware bugs, and they are way less expensive. There are a couple reasons we don’t have it. Personally I wanted a UART but the reasons for not including it were legitimate and it can be added via expansion card. The system will still have onboard capability, just not as fast. Sent from my iPhone using Tapatalk
  13. Actually using a 6551 is not a good idea. The modern in production 6551s have a serious hardware bug. You are better off using a more modern UART. There are lots to choose from. Sent from my iPhone using Tapatalk
  14. It’s not abandoned, there just isn’t a UART. The user port can be used. You can however (not developed yet) get a card with a UART. Sent from my iPhone using Tapatalk
  15. There will not be a UART on board. Sent from my iPhone using Tapatalk
  16. The expansion slot is going to be the recommended method. Reality is there will be KERNAL routines and by default those routines will use some of the user port pins to allow RS232 compatible serial. But by loading in a “driver” during the boot sequence you can reroute those routines to support a real UART for much better speed. So long as software is using KERNAL routines and not direct hardware access the changeover should be mostly seamless. Sent from my iPhone using Tapatalk
  • Create New...

Important Information

Please review our Terms of Use