Jump to content

Lorin Millsap

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Lorin Millsap

  1. No. You are not understanding that at all. The bank registers are mapped are located in memory locations $00 and $01. They are latches that capture writes to those locations. As long a the memory model doesn’t change then you can read those locations too and the value they contain is always the same as what is written. But if you make that area of memory swappable suddenly the value stored in those locations will not match what is stored in the latches. There is no practical or simple way to do it. Our goal is a simple memory model. As I’ve stated before the use case is not really that useful. A relocatable ZP makes more sense and that requires a different CPU. Once you start remapping too much you are moving away from banking and starting to look more like a full MMU. Sent from my iPhone using Tapatalk
  2. The system is not intended to multitask. It is a direct to hardware system and while you could do simple multitasking, it’s not our design goal. They are used as quick access stash points for code, most programs will only use maybe a couple dozen tops. If you aren’t using BASIC you can repurpose all the ones reserved for BASIC and the same goes for KERNAL ones. So from a dev standpoint it’s not needed furthermore your dev tools would have to keep track of which ZP you are accessing. The ZP banking is already shadowed. What you are asking is not a simple change. This lands firmly in the category of the hardware is set and this isn’t going to happen. In fact most future changes are bug fixes. Sent from my iPhone using Tapatalk
  3. Because how many variables do you need? It adds complexity and it’s not as useful as you think. Also the banking is stored in zero page so that wouldn’t work. Sent from my iPhone using Tapatalk
  4. The internal ROM is writable, with limitations. However you may have the routines you can put on slots, that doesn’t mean the KERNAL knows that they exist or how to use them, and patching the routines is actually easier and cleaner to do again through the SD card. Easier to implement and easier to fix if you screw up. Sent from my iPhone using Tapatalk
  5. You are probably right. The board as it is now doesn’t support that though the pins are free. It just needs a way to disable the onboard ROM and select a separate one instead and that just doesn’t exist on the current design. This could be accomplished via a single 138 chip connected to the extra 3 pins, with the first select going to the onboard ROM. If a larger connector was used for the expansion then you could put ROMs on the expansion. However o don’t think that’s going to happen as it drives up cost and uses more board real estate. So from that standpoint I would rather see a couple I2C lines on the expansion instead if we wanted ROMs. I don’t know that it will happen though. Technically if you wanted I2C you could just use a pin header and a jumper to the existing I2C pins on the user port. Sent from my iPhone using Tapatalk
  6. No you can’t. Not without supporting circuitry on the motherboard. The onboard ROM will still activate it will just end up mirroring. If you hooked up an extra ROM then both the extra ROM and the internal ROM would activate. You would need to add an extra circuit that disables the onboard ROM and then an extra ROM would work. Sent from my iPhone using Tapatalk
  7. On a lot of this it boils down to system side software support, much of which is not yet implemented. An idea I advocate is that the config files are in plain text, and that some code in the KERNAL reads them one line at a time and then dumps them into the buffer in BASIC, so line numbers don’t matter so much, and a program getting overwritten is less of an issue as it’s just doing it all in immediate mode. There are some limitations to this, things like condition checks and branches often rely on line numbers. But it would work well enough for loading in subprograms, including assembly. If it calls an assembly program we just have to trust that it returns control, otherwise the rest of the “script” won’t get executed. Sent from my iPhone using Tapatalk
  8. Works fine if all you wanna do is display static bitmap images. No tiles, no sprites, no scrolling. Sent from my iPhone using Tapatalk
  9. Please refrain from discussing DMA on this thread as that’s really another topic. In fact much of this conversation is so far off topic. No there isn’t gonna be any way the cards can self identify themselves on initialization. For the most part they’re just gonna be off-the-shelf logic chips. A SID chip can’t identify itself. To get into cards that are true plug-and-play you’re getting into really complex stuff that we just simply are not going to do. If you wanted to sign something that goes that fine he just has to stick within that 32 bike limit and have some kind of usability. But the system itself frankly doesn’t care. It’s a simple as this you want to put in a new card you install the new card. It won’t do anything without software but it’s installed. If you want to use it then you have to install software that works with it. And you have to tell the software how you’ve installed it. If specific software directly supports the card you don’t need a driver. If you want the car to work with BASIC in the KERNAL then you do need a driver. The prime example of this is going to be say a proper RS 232 card. If you plug in the card by itself it’s not gonna do anything it’s not gonna break any software it just won’t do anything. So then you install a kernel extension patch and configure it to use I/O5. All the KERNAL patches effectively does is make sure that all RS 232 data goes to the card instead of the built-in bit bang serial. It basically just puts a new set of routines in memory somewhere, and changes the vector entries so they point to the new routines. Sent from my iPhone using Tapatalk
  10. Oh certainly. Things that needs drivers are things that the KERNAL supports. The KERNAL at this moment doesn’t care about sound. So technically a sound card wouldn’t need driver support. That would be a case where each program that uses sound features would need to support such cards. The types of cards that would require drivers are the types of things where the KERNAL supports those functions. This would include things like RS232/network, storage, keyboard/mouse, etc. BASIC uses the KERNAL routines so anything that interfaces via the KERNAL will automatically work in BASIC. So a driver is really just a standardized API. Which in this case are just a simple jump table for standardized routines. A driver just hooks into that standard. If there are no existing routines to handle a certain function then you don’t need a driver either, software that can use the hardware will just directly access the hardware. Sent from my iPhone using Tapatalk
  11. Very familiar with them. They are great for making things like thermostats, interface panel displays, and smart appliances, applications where having less than 1fps is ok. Sent from my iPhone using Tapatalk
  12. That is it exactly. So picture if you will soldering one of these boards yourself and you make a mistake and say for example happen to bridge a power and ground. That short may not damage any chips but it could potentially vaporize a trace. In theory most power supplies are going to be able to detect dead shorts and shut off themselves but you can’t really rely on that because they might still allow an awful lot of current before they sense it as a short. I for one feel that putting some kind of fuses that are some value we consider normal and safe would be better than just allowing The power supplies full output unrestricted. Sent from my iPhone using Tapatalk
  13. On the subject of potentially having a ROM on the expansion cards, a potential solution could be bringing SPI or I2C into the expansion slot. Then you could place a ROM on that card but this alone does not fully address some of the issues so the code in this ROM would need to have enough flexibility to handle the issues. The main issues 1. the code still needs to be able to account for the address the card has been assigned to. So you either need a way to assign what ID the card is or to auto detect the cards ID. 2. You cannot execute code directly from a serial ROM so it still needs to be copied to RAM in a way to doesn’t overwrite other important code. 3. The code has to set itself up or in order words it is self modifying code. It needs to basically load into a staging area, then execute and copy its routines to a safely assigned area and tie itself into the KERNAL vector table and tie in relevant IRQ. This is all doable, but whether it’s located in a ROM on the card or gets placed on the SD card it still has to account for and dolce the same problems. Locating it on the SD card allows greater flexibility. Putting it on a built in ROM kind of black boxes the code to a degree. Yes it may have a degree of plug and play ease if set up correctly, but it brings new challenges too. Sent from my iPhone using Tapatalk
  14. So obviously for hardware you may need to have an installer of some sort. It might be possible in some cases to have the installer try to auto detect the hardware, but it’s probably fine to just have the installer ask how you’ve set your jumpers or dip switches. Then it could say inject some lines into your config file and place the files where they need to be. I’m not opposed to this option as it is highly flexible while also being reasonably user friendly. It’s obviously not plug and play. But it’s not crazy difficult either. Sent from my iPhone using Tapatalk
  15. Ok, many points on this subject are spread across multiple other threads and I’d like to have a specific thread where these ideas can be hashed out and discussed and pros and cons of various approaches can be addressed without distracting other threads. I suppose I should start by explaining in as clear of terms as possible what the design approach has been as it appears there is confusion on this topic. How the IO logic is broken down in simple terms. There are a total of 8 active low select lines. Three of these lines are used by integrated hardware. The first handles both ViA chips, the second handles video, and the third handles audio. This leaves 5 lines free to support expansions. Each IO line or range spans 32 bytes of addressable space. Most chips will use far less than this, but in the even a chip used more you could utilize more by occupying more than one select line. This is large enough for IO devices but not really large enough for a ROM, at least not a directly mapped ROM. Now on to how these IO select lines are routed. They are all routed to every expansion slot. In other words the system has no distinction for which slots perform which functions. As far as the X16 is concerned all expansion slots are essentially equal. The upside of this is it allows expansion cards to be configured in a flexible way, but the downside is it does leave room for configuration errors. A cards physical slot has no bearing on how it gets mapped to memory. So how then are we proposing that cards get mapped to the IO lines. By physical jumpers or dip switches on the card. What happens if two cards have the same address? There will be bus contention and it won’t work. Real damage is unlikely, but that hardware simply won’t work until the conflicting lines are corrected. This is a problem PCs did have however we have way simpler select options, you only have 5 potentially valid ranges so even if you tried by trial and error it wouldn’t take long to get a valid configuration. So the next major issues that can come up are IRQ handling and DMA. On the X16 there is no IRQ prioritization in hardware. There are two types of IRQ events. The first and more common is a standard IRQ which is invoked in hardware by pulling the IRQ line low. This will cause the CPU to complete its current instruction, then push its registers to the stack and then jump to the IRQ vector. It will then determine what caused the IRQ in software. This is the way the commodore machines handled it and even though you spend CPU cycles polling a few registers to determine what caused the interrupt, it for the most part works and is still handled faster in most cases than other CPUs of the era. IRQ events occur on a first come first served basis. In other works if an IRQ is triggered while an IRQ event is being handled the second IRQ is not handled until the first one is completed. Also the CPU can be set to ignore this type of interrupt. The second type of IRQ is a NMI or Non-Mashable Interrupt. This uses a separate NMI line and this type always gets priority. Even if the CPU is set to ignore interrupts, NMI will still interrupt normal operation. Even if the CPU is handling a standard interrupt, a NMI will take precedence. I’ll skip DMA for now. So now that I’ve explained the basic architecture that allows us to look at the issues you might run into and how you can best handle them. 1. Hardware can technically be at any one (or more) of 5 address ranges. 2. Hardware can potentially trigger IRQ or NMI events 3. Standardized ways of utilizing certain types of hardware and making it accessible to software may be desired. 4. The actual code to handle the hardware needs to reside somewhere in memory and needs to do so in a way that doesn’t conflict with other drivers. This code probably needs to have some degree of relocatability and any vector tie ins need to be configured based on where the code is located. So the approaches may vary based on what you are trying to do. So I encourage civil discussion. We don’t want any complex or severe changes. But that doesn’t mean we can’t discuss options and possible solutions. My primary approach is that as things develop we will try to get an auto boot feature working. The details on that haven’t been sorted yet, but I’m of the opinion that a type of config file written in plain text similar to dos allows a good balance between ease of use and flexibility. I’m in the fan base too that these config files are essentially BASIC while functioning like a DOS batch file. So you can potentially do some pretty powerful things without having to know assembly. These files can be configured to load drivers and even pass arguments in some cases. So my thinking is that a driver can be loaded and told where it’s hardware is located. The driver may load a config file or something, there are several ways it could be handled, but the main things is where the hardware is located since that also affects where the IRQ hooks need to be if there are any, and can provide a clean way that hardware can be accessed by relevant programs without having to build drivers into the programs themselves. Sent from my iPhone using Tapatalk
  16. Well the way it works will probably be simple. You install your card, and that card will immediately be able to be used for software that supports it. If you want seamless KERNAL integration, well handling IO is the KERNALs job so extending its functionality through the SD which can be configured to load on powerup will be pretty seamless. You may have to run an installer the first time. Plug and play was not a design goal. From my standpoint if the primary storage method was slow and clunky carts and IO mapped ROM makes sense. But when your SD card is about as fast as the CPU can handle it doesn’t make sense to do anything. And what happens if you put two cards with a ROM? How would it know which one takes priority? How would it know where to put it in memory without conflicting? On systems like the C64 you had one expansion slot, so you really didn’t have to worry about conflicts caused by two expansion carts. On our design you’ve got 4 physical slots and 5 IO slots they can be mapped to. It does not differentiate which physical slot you put a card into. Putting ROM on the expansion brings in all the difficulties of first generation ISA and the endless hardware conflicts that entailed. And the benefits of putting a ROM on the card does not offset the problems it creates when you have a more elegant and flexible solution known as put the driver on the SD card. Sent from my iPhone using Tapatalk
  17. I see I'm a missing a point here. I know that every component has its own eaxct current drain, so the whole board will also drain needed current only, even if PSU can provide more. I know that PSU might be too low on power, when board drain more current, than PSU can provide. But how can it be vice versa, how can it be too much power? It’s too much power when you make a mistake and fry something catastrophically. We are looking at implementing perhaps self resetting fuses or something. Sent from my iPhone using Tapatalk
  18. Yup that is definitely finalized. Wanna load software/drivers? Put them on the SD card. As Adrian shared, the SD load routines are extremely fast. Why bother with ROM when your storage medium is not really going to keep you waiting. The only ROM method available via the expansion slots is DMA. However there really isn’t DMA arbitration so good luck with that. Yeah it will work but it’s way more complicated for minimal benefit. Sent from my iPhone using Tapatalk
  19. Technically yes, but then you have 2 devices driving the bus at the same time and they may have different timing. At best that’s a bad practice and at worst you could damage something and most of the things in between involve data corruption and unstable operation. You only ever want on thing driving the busses at any given time. The banking latches work because they never drive the bus. Sent from my iPhone using Tapatalk
  20. I think you misunderstood me you can read them technically the value stored in RAM and the value stored in the registers should always be the same. The only exception is during initial power up the ram might contain random values but is soon as the post rouroutine writes the bank it will immediately be updated and match. There is no condition once it is set where the value you read back will ever be different than the actual value stored in the latch. Sent from my iPhone using Tapatalk
  21. Part of my thinking as I’m the one who pitched the ZP banking feature to Kevin was that by making it a ZP feature it speeds up all banking operations. This includes many KERNAL functions since those are often in banked ROM, as well as user code that uses banked RAM. Admittedly in theory using ZP for VERA makes some sense for speeding up access, the added circuit complexity isn’t desirable and you have to be aware that the more memory decoding you add the more potential it has to add unwanted timing delays which could result in stability issues. On this I suppose I should clarify how the latches basically work and to do that I need to explain how the normal IO space works. So as you know there is a RAM and ROM in the base 64k memory map. By default the RAM is selected with exclusions. If the address lands in the ROM memory range the RAM is excluded and the ROM gets addressed instead. The same is true for the banked RAM range. This also applies to the IO range. This allows any of the chips in those ranges to be addressed correctly without any bus contention. However how the zero page latches work is a little bit different. The latches “shadow“ the ram. Basically the latches themselves are write only. When you write to $00 or $01 you write to RAM and the latches. The RAM is not excluded the way it is for other address ranges. When you read $00 or $01 you are reading from RAM. Now if you wanted to move VERA to zero page you would need to add exclusion logic to the RAM so that it doesn’t conflict. But every bit you add does 2 things. Firstly your part count goes up which drives up cost, but also you add propagation delays which if you get enough will cause unstable operation or non operation. Sent from my iPhone using Tapatalk
  22. Apart from Stephen’s comment it would also be a logic nightmare. You can’t just randomly place whatever you want wherever in the memory map. There are reasons why things are put where they are. Sent from my iPhone using Tapatalk
  23. Because the price deal on the cases gives us a power supply built in. It’s less expensive than sourcing an external low noise power supply and it gives us multiple voltages. Sent from my iPhone using Tapatalk
  24. Because the moment you do that you no longer have access to ZP for use in your programs and that is a really bad thing. Use if ZP isn’t a little faster it’s a lot faster. ZP can be thought of almost like 256 processor registers. The 6510 had an IO port built in at $00 and $01. Sent from my iPhone using Tapatalk
  25. And BLOAD doesn’t work because? Sent from my iPhone using Tapatalk
  • Create New...

Important Information

Please review our Terms of Use