Jump to content

Lorin Millsap

Members
  • Content Count

    26
  • Joined

  • Last visited

Community Reputation

12 Good

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. So one exception case I can bring up for a DMA capable card what could take control without CPU is again part of a disk controller card. See a disk controller that’s more advanced than the onboard SD card would be useless if the KERNAL doesn’t know about it. That means to use it you either need to reflash the KERNAL with one that supports the card, or you need to load the KERNAL patch from the onboard SD with each restart, or the card needs a way to inject the relevant code into the host. The first two options do have their own respective drawbacks, but are viable. The third option is the one I want to focus on however as it would require DMA. See the default IO ranges are only 32 bytes in size and this is simply too small for a ROM. Now you could do a type of indirect addressable ROM, but the KERNAL would have to know it’s there and how to use it and while it could be a viable option, it probably not a very good one. But an option that circumvents all memory limitations and can support fully automated loading is DMA injection. So the method here is something like a disk controller would have a microcontroller on it to handle something like SATA anyway. This microcontroller could take over the system bus following a reset and inject the proper patches into RAM. There is obviously a risk that these patches could overwrite something, but that can be addressed in software and these patches would redirect the vector table to the new routines before returning to the stock routines. So the code would probably get placed in an area reserved for KERNAL use anyway. Since this method would not get triggered by the CPU it would need to have a way to be disabled, likely a jumper or switch. As the KERNAL matured we can come up with a clean method for KERNAL extensions to load without conflicting with each other. Also since in theory you could have more than one such card (that auto injects code) so such a card would probably need something that adjusts how long it waits after a reset before attempting DMA so that you don’t get two cards trying at the same cycle. So in this case if the delay (priority) is different the second card will detect that the _ML line is low and will not attempt DMA until it is clear. So the first card would be able to complete its injection before the second card would be allowed to operate. Now I’m not saying we are designing such a card, I’m just throwing out a use case for the sake of discussion because it’s in use cases that we can figure out if it’s even practical. Because if we are honest loading a few files off the SD card to do the same thing is not a deal breaker. The drawback off loading the patches off the SD card is it would require the appropriate SD card with the files be inserted. By using the DMA code injection the expansion card becomes bootable on its own. You could also NetBoot from a network card. Before it gets brought up again, the expansion slots are not meant to be used as cartridges, as anyone can see using DMA is not exactly simple. Software should be distributed on full sized SD cards. Think of this as a really high capacity floppy drive. A disk controller card would be the equivalent to installing a hard drive on your Amiga and the SD card like the floppy. It essentially becomes an install media at that point instead of the everyday use drive. Sent from my iPhone using Tapatalk
  2. Good points. I will try to change to wording just to try to clarify that DMA cards must be enabled one at a time. That part will largely be a software side issue not a hardware issue. This is a good point to discuss and clarify. Perhaps a good way to specify is that all DMA operations need to be activated by setting a flag host side. This would mean DMA devices would never just start unannounced. That should minimize the potential for conflicts. Good point on read/write/modify operations. I will update the guide accordingly. It also occurred to me that we can pull _ML during DMA so that one card can let the rest of the system know that an operation is in progress. As to accessing IO space there are times when you would want DMA to alter IO. Avoiding conflicts there is going to largely be a software side issue, if you don’t want a VERA auto increment being disrupted, don’t invoke a DMA operation during a VERA access operation. If DMA based systems are designed so they have to be activated host side that makes it easy to avoid certain conflicts in software. Sent from my iPhone using Tapatalk
  3. 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
  4. 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
  5. Hence why DMA cards need to provide at least some stuff on their own. There is a reason I made this point number 1. It wasn’t to say hey we’d like your feedback on how to accommodate this. This is a big warning that the X16 doesn’t provide arbitration so heads up. We aren’t going to provide DMA arbitration. Not happening. DMA capable cards should make at least some effort by checking first. Is a clash still possible? Yes. But no DMA card should work autonomously. This method should work well enough, many multi master type setups do the same. Your second paragraph is literally what my second rule states. So in a hypothetical let’s say you have a Z80 card that needs access to the host IO. It has several approaches. You could have it put in a request in some set of registered or shared memory then trigger an IRQ on the host and the host handles it, or you can have DMA. If you then had say a network card, it would stand to reason that the Z80 card would not know how to use the network card anyway. So the network card should be disabled anyway. Same to a coprocessor card or a blitter engine, etc. all those would need to be activated by software that knows how to use them. None of these would ever act autonomously. I’ll hear you out but reality is these hazards need to be considered by the card designer, it is not in our scope to accommodate them. Sent from my iPhone using Tapatalk
  6. 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
  7. It was possible to achieve 9600 baud on the c64. Im pretty sure that is using shift registers. On the legacy CPLD SPI interface, the problem isn’t that it can’t be done. The problem is a lack of pros. A parallel bus interfaced UART is going to way outperform an SPI one. It will cost less too and require fewer supporting components. Reality is that the UART was removed from the design because we simply don’t have the resources for it and we need to move the project forward. We can easily implement a functional equivalent using the hardware we already have.
  8. 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
  9. Yes I’m aware if the SPI master. However it’s based on an off language for an obsolete chip. There is no reason to try to use an I2C or SPI here. It makes sense on microcontrollers that don’t have exposed buses and IO is precious. But here it doesn’t make much sense. And yes, existing RS232 dongles should work fine. The onboard should work fine. We don’t know what speeds it can do yet, but 56kbps doesn’t seem unreasonable. That’s almost 8k per second. Sent from my iPhone using Tapatalk
  10. I figured now that I let out some information about the expansion bus and I’m sure there will be hardware enthusiasts eager to develop expansion cards, j figured some guidelines need to be laid out. Before we can get into how to do DMA I want to make sure I define it as other systems may do it differently or apply a slightly different meaning to it. DMA stands for Direct Memory Access and will refer to any operation where the CPU is yielding control to another device. It is not the same as wait states, and it is not the same as bus sharing. Also and device that passively watches the bus but does not interfere or alter that bus in any way is not DMA. So for starters I’ll explain the means by which DMA can be implemented. There are several lines on the expansion bus that are central to DMA, pin 8 which is RDY, and pin 12 which is BE. Also _ML(b) pin5 and SYNC pin 10. So what do these pins do? Starting with RDY this line is normally high and when it is high it allows the CPU to run. When this line is pulled low the CPU will halt in its current state. On its own this is how wait states can be implemented, but it requires its use in conjunction with the BE line in order to act as DMA. The BE or Bus Enable line is also normally high and when it is high it means the CPU is driving the address lines and during a write operation, the data lines as well. Pulling the BE line low will cause the CPUs output lines to go into a high impedance state, or in simple terms, it turns them off so that the CPU no longer influences the state of the address or data lines (and a few other outputs as well). So if you pull both the RDY and BE lines low, the CPU effectively becomes disable and thus allows another device to take full control of the system bus. _MLB is an active low signal and it stands for Memory Lock and when this line is pulled low it means it’s not safe for a DMA operation. The SYNC pin is normally low but goes high when the CPU is ready to fetch an Opcode. This pin could be used for certain DMA operations, but will usually be left unused. So just some examples of what you could use this for include debugger hardware, block copy functions, high speed disk controllers, high speed network controllers, coprocessors, compatibility cards, freeze/replay cards, etc. Now it may seem like you can do just about anything with this, there are some things to be made aware of and consider and that is a large part of why I’m writing this guide. So let’s get into the things to be considered before DMA can be implemented. 1. There is no real onboard DMA arbitration. What does this mean? It means the X16 has no onboard means to prevent DMA conflicts. So as an example if you had a Z80 card and it happens to be performing a DMA access to VERA and in the middle of that another DMA card tries to perform an operation those two will end up in conflict garbled data sent to unintended addresses. My recommendation is that all DMA capable cards check the state of the _ML, RDY, and BE lines before attempting a DMA operation. If any of these are low it means that memory is not clear or another DMA operation is in progress. the card should wait until they are both high on the next high phase system clock. This solution is probably not perfect but it should help avoid most conflicts. When a card is performing a DMA operation it should pull _ML (MLB) low time indicate it is performing an operation. 2. DMA devices should be inherently disabled and only assert control when enabled. To clarify what this means is that with limited exception DMA cards should never perform DMA operations without first being granted permission by the host typically by setting a flag. Examples could be a disk controller which could inject data directly into system memory. Such a controller should not do so until the host indicates that it is safe to do so by setting a execute flag. If a card needs to get the attention of the host it can do so using the _IRQ line. 3. DMA devices need to respect the RESET line. A reset should restore the devices back to their default state and these devices should not get stuck in a DMA state. If a RESET occurs during a DMA operation the operation must be aborted. 4. DMA devices need to respect the speed ratings of all main board components that they can access. These specifications have yet to be more clearly defined and we will release timing charts as we get closer to a finished design. 5. While DMA devices do not necessarily have to operate on the host clock, they must not interfere with the system clock and in most cases this clock needs to be involved in timing the RDY and BE signals. Also read and write operations do need to meet the system clock requirements. I will edit this post with relevant information and look forward to discussion and questions regarding it. Sent from my iPhone using Tapatalk
  11. 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
  12. 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
  13. 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
  14. 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
  15. ST16C550 should work fine. It’s one choice out of many. Sent from my iPhone using Tapatalk
×
×
  • Create New...

Important Information

Please review our Terms of Use