Jump to content

Lorin Millsap

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Lorin Millsap

  1. A user port certainly is a serial port. What we aren’t including is a UART or a modem which would allow faster transfers. The user port could also certainly be used as a parallel transfer instead of serial, so with the right interface you could still get respectable speeds. Sent from my iPhone using Tapatalk
  2. The ability to reflash the ROM is not intended for adding user programs. Sure you could, but it’s akin to adding custom programs to your BIOS. It’s intended for the KERNAL and useful extensions. The risk of corrupting the ROM is fairly high. The SD card or other storage device is where you locate your programs. Sent from my iPhone using Tapatalk
  3. You read or write it like RAM but certain requirements have to be met to do so since accidentally writing to ROM would be disastrous. We will document the process once it has been tested since so far we have only ever flashed to ROMs externally. In summary though, you need to have a jumper on the board set, then you need to write a specific sequence enable writing, and during the process timing requirement have to be met. Because of the stakes, it is not something you can casually do. Failures can corrupt the ROM and essentially brick the device. You would need a replacement ROM or a programmer to fix it. Sent from my iPhone using Tapatalk
  4. So, what do I expect from this; for starters, that FLN increments until it reaches BLOCKS. I convert the FLN to string, by using STR$ and removing the space on the left, as I need to combine it with another string. But since it goes wrong here, it has to avail to continue the code. When I run the program it states by 104 that FLN stays 2, and FLNN$ stays 3. When I run the same code in QB64, it works flawlessly, so I'm not really sure on what I'm doing wrong here. Perhaps someone can try this and shed some light? Basic tokenizes variable names which means everything after the first two characters is treated as the same. This means in your code FLN, FLNLL are actually the same variable. Give them more unique names and the behavior should be corrected. It’s a BASIC V2 limitation. Sent from my iPhone using Tapatalk
  5. The hardware does not support this so on the X16, no you can’t. Sent from my iPhone using Tapatalk
  6. Good to know. Has anyone filed an official bug report for this? Sent from my iPhone using Tapatalk
  7. 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
  8. So stop using 640x480. Drop down to 320x240 and all of your problems will go away. Sent from my iPhone using Tapatalk
  9. Absolutely. There is nothing about the design that limits that. In fact the base 512k is just one. Sent from my iPhone using Tapatalk
  10. 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
  11. A lot of this is a good approach to a full RAM test. Sent from my iPhone using Tapatalk
  12. 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
  13. 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
  14. Question. I’m not as much of a programmer, but is MEMTOP not mirrored in RAM? Sent from my iPhone using Tapatalk
  15. That’s not entirely accurate. You can totally have 1536K. Sent from my iPhone using Tapatalk
  16. Yes, absolutely. Sent from my iPhone using Tapatalk
  17. 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
  18. 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
  19. 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
  20. Now that release is getting closer and real hardware expansions may be a thing I’m going to attempt to explain and outline the requirements to implement DMA features to avoid contention and make sure cards work with each other and the base hardware. So firstly clarifying DMA. Just because something is directly connected to the bus does not mean that it is DMA. DMA is more referring to devices that can access things on the bus themselves. So what lines do you have available to implement DMA? There are three lines that are associated and there are a couple rules that need to be followed depending on what you are doing. The first line we need to care about is /ML. This stands for Memory Lock and when this line is active it means that memory is in use. This line is going to be the primary means of DMA arbitration. Before a DMA device takes control of the bus it needs to check the state of this line. If it is active then either a CPU operation is in process that can’t be safely interrupted, or another DMA is already in progress. That means your card needs to have the ability to wait until this line is deactivated before initiating a DMA operation. The second part of this is that once your card has initiated a DMA operation it needs to activate the ML signal to let other DMA devices know that a DMA is in progress. So in summary on this there is only simple first come first served DMA arbitration and each card needs to comply with this basic approach. Always check the Memory Lock status before beginning an operation and always activate the ML signal when a DMA is in progress. In theory you could use the /SYNC line however we aren’t going to encourage that at this time as it may have some useful future applications and using it for DMA may prevent that. The next lines we care about are /RDY and /BE. These two lines can be used in different combinations depending on what you are doing. /RDY essentially halts the CPU in its current state and the CPU doesn’t resume until the next PHI2 high following the release. /BE tristates the CPUs outputs and prevents the CPU from driving the address and data lines. By activating both you essentially disable the CPU and allow the DMA device full control of the busses. For most DMA operations you will assert both lines, but there may be some special cases where you don’t. The next requirement is the access cycles. You still need to comply with the timing requirements of the buses depending on what you are doing. Writes need to be stable about 10ns prior to the falling edge of PHI2 and should be held for 10ns following the falling edge to ensure that the values get written correctly. Reads need to latch on the falling edge of PHI2. Addresses need to be valid at least 10ns prior to the rising edge of PHI2 and need to be held till at least 10ns after the falling edge of PHI2. In some cases accesses can be extended over multiple cycles but the timing must still meet what I’ve outlined above. The PHI2 high time is just over 60ns. The next requirement we are going to ask is that all DMA devices need to return to a safe state and release control in the event of a /RST (reset) signal. DMA devices need to default to a disabled state and then be turned on by the host. So what about arbitration? Well to clarify as per discussions the X16 will use software arbitration. Each DMA device will have a control register which by default is set to false or off and in order to begin a DMA access it would need to be set to true by the CPU. When the DMA access is complete the control register needs to be cleared by the DMA device. If the DMA device needs to perform an operation it can generate an IRQ and the IRQ routine can perform the proper setup and enabling if the DMA operation. Look forward to your questions. And at this point, no DMA has not been tested. So this is all hypothetical until real tests are performed. Edited to reflect items discussed below. Sent from my iPhone using Tapatalk
  21. We do not repurpose the keys on a hardware level. So they will do their original functions on other systems. Hopefully that answers your question. Sent from my iPhone using Tapatalk
  22. Bingo. Many vintage systems did transparency effects this way and it’s actually a very charming approach. Sent from my iPhone using Tapatalk
  23. There will be support for printers on IEC as well as the user port. Sent from my iPhone using Tapatalk
  24. Not all may be present but you can always pull from a molex connector and it’s possible to produce negative voltages if they are required. Sent from my iPhone using Tapatalk
  25. The VERA is basically finished. There are no plans to add new features to it. Sent from my iPhone using Tapatalk
  • Create New...

Important Information

Please review our Terms of Use