Jump to content

Lorin Millsap

Members
  • Content Count

    166
  • Joined

  • Last visited

  • Days Won

    11

Lorin Millsap last won the day on February 19

Lorin Millsap had the most liked content!

Community Reputation

194 Excellent

3 Followers

Recent Profile Visitors

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

  1. The hardware does not support this so on the X16, no you can’t. Sent from my iPhone using Tapatalk
  2. Good to know. Has anyone filed an official bug report for this? Sent from my iPhone using Tapatalk
  3. Those are fair questions and I’ll answer as clearly as I can. I’ll start with why IO devices of the normal type like the VERA are impractical to put there. So to begin its good to clarify that it’s important that most of ZP be reserved for the intended ZP usage using a couple registers is fine because it leaves the bulk of the space free. Two registers which were also reserved on the 6510 is not a big deal. But tying up lots of registers is. I won’t disagree that having the VERA there wouldn’t be very useful, the main reason is you need to create a logic exclusion case where a 32 byte range are read or written from the VERA instead of RAM. This requires a fair amount of logic and that introduces timing delays which can cause lots of problems especially on reads. And creating an exclusion case for VERA (a 32 byte range) is more costly from a component/complexity than turning the entire ZP into IO. But turning the whole range into IO is too costly from a software/overall functionality standpoint to be considered either. So how then do we do an exclusion for two registers in ZP? The simple answer? We don’t. The bank registers are in fact RAM and latches. We don’t disable the RAM on reads or writes. The RAM at those locations is always active. However what we do implement is a shadow technique where on a write event to those locations a pair of latches (one for each address) will capture the contents of the data bus on the falling edge of the clock. This does not disable the RAM from also latching those same values, and in fact when you read those locations what you are reading back is the RAM, not the latches themselves, since they can’t actually be read. This isn’t a problem since the RAM will always (with one small exception) contain the last written value. The exception is on a hard reset. On a reset the latches always return to zero whereas RAM does not. So in theory after a reset the value stored in RAM and the value in the latch will mismatch. In practice this isn’t a problem since the reset routine will write to those locations which corrects the mismatch. So the trick we are doing while it does add a few parts, has no impact on the timing of the system. It’s very simple and it’s inexpensive. The parts used cost much less than devoting a relatively costly 65c22 to do the same task. And we aren’t eliminating the 65c22 gets freed up to do more important things. End result is the X16 has more free IO for the user than the Commodore machines did. Sent from my iPhone using Tapatalk
  4. So stop using 640x480. Drop down to 320x240 and all of your problems will go away. Sent from my iPhone using Tapatalk
  5. Absolutely. There is nothing about the design that limits that. In fact the base 512k is just one. Sent from my iPhone using Tapatalk
  6. That’s interesting. I might need to bring that up with Micheal. Because what should happen if you try to access banks that don’t actually exist is the CS lines will not connect to anything. If the CPU writes a nonexistent address then no CS line is ever asserted so the data will just float on the buss till it gets changed by something driving the buss. On a read again since no CS line goes active the buss will just kinda float. Unused banks do not mirror. Sent from my iPhone using Tapatalk
  7. A lot of this is a good approach to a full RAM test. Sent from my iPhone using Tapatalk
  8. I guess in this case a custom version of the routine is unlikely so using the ROM vector would be safe. The real hardware does not mirror the ram. So if you attempted to read or write banks that don’t exist what you will get is garbage. Sent from my iPhone using Tapatalk
  9. For at least most KERNAL routines they are located in RAM in a vector table. The problem with using the ROM vector table is new routines that supersede the KERNAL functions can be pointed to using the RAM vectors whereas if you use the ROM vectors you don’t get the benefit of the new routines. The commodore systems would copy the KERNAL vectors to RAM locations which meant you could inject patches. I don’t know if this routine in particular has a RAM vector or not. Sent from my iPhone using Tapatalk
  10. Question. I’m not as much of a programmer, but is MEMTOP not mirrored in RAM? Sent from my iPhone using Tapatalk
  11. That’s not entirely accurate. You can totally have 1536K. Sent from my iPhone using Tapatalk
  12. Yes, absolutely. Sent from my iPhone using Tapatalk
  13. So not to get to particular but often looking at use cases can be helpful. A network card can be a good example. Say someone makes a Wifi card that is capable of higher speeds. It could handle the heavy loads of tcp/up stacks and security and even some decompression and decryption. It could then put the raw data in its own buffer and send the system an IRQ. The IRQ handler would then see what it needs to do and set up a DMA transfer. The card then takes over the system, copies its buffer to system memory then returns control back to the X16 main cpu. This could allow much faster speeds than would be possible with bit banging or even using a dedicated UART. The same could be true of a SD expansion card, if you wanted to save a file it could just send the parameters to the controller card and then when the appropriate control register is activated the expansion card can take over a memory dump to file operation. Sent from my iPhone using Tapatalk
  14. This is already finished. You have software arbitration. I’m simply explaining how it works not asking how we should do it. So DMA is allowed but needs hardware devs to design it such that it has to be enabled in software and that each DMA system is only enabled when it’s needed. Sent from my iPhone using Tapatalk
  15. On the DMA you aren’t going to get hardware arbitration. However if your default state is DMA disabled, then you can handle it in software by making sure that DMA accesses only occur when they are enabled by the CPU and that when control is restored they can be disabled until they are needed again. So examples could include a network card that generates an interrupt when it needs to get the CPUs attention, then the handler routine sets up and enables the DMA function which could read or write a section of RAM then when it is finished the controller clears its DMA flag (so it’s automatically disabled until it gets turned back on by the CPU) and things return to normal. The same approach would be used for disk controllers, etc. So long as DMA defaults to off it helps avoid most conflicts and if combined with IRQ handlers it would allow a fairly clean way to avoid contention since under this approach DMA only starts when the CPU tells it to. You would still want to check /ML since a DMA may not start immediately and it’s possible a CPU instruction could set /ML. And example where you may not always want to set /BE is when you are wanting to monitor the CPUs output. In many cases you could do this passively. But in certain diagnostic situations you may want to see what the CPU is doing. One example too would be where you want to capture the CPU output, modify it, then write it to some location. But most common situations would never do this and so most of the time you would enable both /RDY and /BE. As to the clock, the CPU clock is cleaned up so you always get nice square waves. If you think this is a good explanation and approach I can add it to my original post. Sent from my iPhone using Tapatalk
×
×
  • Create New...

Important Information

Please review our Terms of Use