20 hours ago, TheUnknownDad said:
On card installation process, when running the installation software, expansion cards could be in a "uninitialized phase" and provide a standard interface for information on the card itself, including an interface to get the built-in driver in a byte-by-byte interface, just like data transfer to VERA works, but in the other direction. The install software can get the driver this way and put it on the SD card. Any comments on that idea?
I believe, there should be this two phase standardized talking to expansion cards in any way. By using only few I/O RAM spaces for that communication it would also be possible to add this without really implementing two phases on the card, since it could be like first 8 bytes are init phase standard use, leaving 24 bytes for free use without extra cost of implementing 2 phases on the card. If it needed all 32 bytes, fine - the driver should set it to phase 2 mode after finalizing initialization. Again, any comments?
Cards won't provide a "standard interface". A card might be two VIA chips, a jumper block to select which segment it shows up in, and a quad NAND to handle the /CS and A4 to pick the correct VIA.
A card might be a 65xx bus SPI controller and an SPI serial chip. For the first one, the drivers depends on what it is being used for. If it is for a program that knows it's there, maybe all it needs is a small SEQ file that says which device space it is using. For the second one, the drivers will install as the serial device.
There is no underlying OS to install these cards into, so there is no leverage point to motivate the creator of either card to add any extra hardware. If lots of cards don't t support whatever "standardized" protocol, it's not a standardized protocol, it's just another system that could be used.
The cards come with one or two binary files that are the driver itself and the driver installation program. The driver installation program can easily be a Basic program, but it might be a binary PRG (whether written in Assembler or C, Forth, Pascal, etc). And a SEQ file with instructions, information about potential conflicts, etc.
So, how does fixing the problem with running subprograms not fix the problem with a main CONFIG.BAS program? The only task here is to make it easy to add the driver install programs to an autostart program.
IF the "V2 subprograms trample callers if the callers are smaller" problem is fixed, the main points to "standardize" here are the name of the autostart program and the folder name for holding drivers and driver install programs.