Hardware Expansion and Driver Handling in X16 General Chat Posted January 11, 2021 · Edited January 11, 2021 by TheUnknownDad 25 minutes ago, BruceMcF said: I can't follow the argument here. Why do the cards need " bus access" ... for most of them, they will just be accessed BY the CX16. The large majority won't have to "access the bus". And after all, part of the point of the Basic/Kernel is that it is NOT equivalent to DOS ... the Basic is running straight on the BIOS. There is no operating required operating system unless you elect to run one. Otherwise it's like an original IBM PC running Chip Basic when no DOS is installed. The "driver installation" is more along the lines of making the BIOS extensible, in the way the C64 was, except without the extreme RAM limitation and slow mass storage access which got in the way of using that ability. When you allow running on the bare metal, how do you enforce expanding the interface logic? Saying "it's not much" when a lot of boards can be two or three chips without the hardware overhead, and provide that functionality in the support software. I'm not trying to "shoot down" tbe concepts, just explain why I am skeptical that that approach is going to generate a lot of enthusiasm in a system that is explicitly billed as allowing us to program as close to the bare metal as we want to. On the topic at hand, a second approach is for the autostart program to be a sequential file that the system stuffs into the line buffer. It would have to have a reserved channel number, so the programs that are called as a result know not to use that channel number for any information files they use. That solves the subprogram trampling the main program problem. Then if there a marker for the end of the line to stuff into the keyboard buffer -- like :: -- then a called program can take parameters from the rest of the line in the same autostart source file. It checks if that channel is open, if it is, it reads the remaining data in the current line. Then the sequential file will be advanced to the end of the line, and if the file is not at its end when execution returns, will stuff another line into the keyboard buffer. If I am not wrong, putting data on the data lines is actually accessing the data bus. This would still require tristate logic or am I missing a point? If not, there are the buffer chips... I don't know if the most expansion cards would only accept data and never send data. Is that your point? All DOS programs were running on the bare metal, right? They could choose to use some BIOS and DOS functions for I/O but were not bound to it. That was the analogy I was heading to - I didn't try to postulate any equivalence. I understand that we look at different segments of a potential market. Having convenience functions, I have learned so far, is always a good idea. Not having to use them is another. You get the ones without explicit tinker knowledge that are "new to this business", but you would definetly lose the enthusiasts if there are ONLY those functions. I would vote for "give people a choice" so they don't need to go the hard way. Giving design guides that would guarantee interoperability is another nice option. Why should card builders figure out, which cards users will combine? As to knwoledge there is not a single expansion card available - so no ground is lost. If things are easy and premade like "include this fucntionality or if you don't want to design it, these circuits on your board" - card developers will likely be happy with that. If the bus tristate logic would be needed, there should be a guide to this anyway. I think it would be of much value to have some clever thoughts on this before problems arise and others have invested their time already. Regarding the autostart feature: I think that's worth trying. Sounds good so far, though I'd prefer to have some workflow sketch to follow which steps are supposed to happen when. It helps my mind a lot in understanding and debugging processes.