Commander X16

4 hours ago, BruceMcF said:

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.

I am kind of puzzled with the overall thinking about expansion cards. I'd believe, to open up a good eco system for these cards, they should be easy to use and obviously more than one at a time, given the system has 3 ports.

Since there is likely buffer chips needed for bus access anyway (this is what I understand so far from Ben Eater's video), the extra cost of such an configuration/identification system is likely one ATTiny on the expansion board, maybe a shift register and three logic gates too. As I am a litte late on the development - there is no expansion card reference design so far, right?

Building an eco system here has been a success to DOS machines too. That is where I see parallels with this machine. You want to make it extendable? Yeah, that what DOS was all about. See that DOS and BASIC/Kernal are mostly of the same use? Of course every program could just try to implement the whole logic for each board it wants to support - but, having Drivers (like TSRs in DOS) they don't need that. They call simple API functions and don't bother about the details. This is where the success story of Adlib and SoundBlaster cards started.

I'd love to see X16 making its way to a whole retro/future eco system. But in my opinion it needs to be started by setting up the right rules/guidelines to do so. To my believe that is where you sell a real system vs. just a computer. So far "systems" have done better in the market.

What would be the cost of turning the table and have a hypothetical look from the other side? We could start implementing stuff (and since it is all software on X16 side, the cost of integration later on is "ok") and see where that leads to. Turning the idea down on first sight - just because it may look like feature creep or over engineering - could miss you a chance of finding new perspectives, ways or even small bits of architecture that would actually help.

oops, posted a question without refreshing the thread, saw that it'd been asked & answered

9 hours ago, TheUnknownDad said:

I am kind of puzzled with the overall thinking about expansion cards. I'd believe, to open up a good eco system for these cards, they should be easy to use and obviously more than one at a time, given the system has 3 ports.



Since there is likely buffer chips needed for bus access anyway (this is what I understand so far from Ben Eater's video), the extra cost of such an configuration/identification system is likely one ATTiny on the expansion board, maybe a shift register and three logic gates too. As I am a litte late on the development - there is no expansion card reference design so far, right?



Building an eco system here has been a success to DOS machines too. That is where I see parallels with this machine. You want to make it extendable? Yeah, that what DOS was all about. See that DOS and BASIC/Kernal are mostly of the same use? Of course every program could just try to implement the whole logic for each board it wants to support - but, having Drivers (like TSRs in DOS) they don't need that. They call simple API functions and don't bother about the details. This is where the success story of Adlib and SoundBlaster cards started.



I'd love to see X16 making its way to a whole retro/future eco system. But in my opinion it needs to be started by setting up the right rules/guidelines to do so. To my believe that is where you sell a real system vs. just a computer. So far "systems" have done better in the market.



What would be the cost of turning the table and have a hypothetical look from the other side? We could start implementing stuff (and since it is all software on X16 side, the cost of integration later on is "ok") and see where that leads to. Turning the idea down on first sight - just because it may look like feature creep or over engineering - could miss you a chance of finding new perspectives, ways or even small bits of architecture that would actually help.

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.

 

 

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.

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

13 hours ago, BruceMcF said:

Why not in one of the unused ROM segments? They surely won't be filling up all 512K of the ROM.

That would work. Additionally, from what I gathered, there are still additional select lines available on the $01 register. We could use one of those lines to select internal or external ROM. So this basically would double the bank count, where half of the banks are the user ROM chip.

So here's the fun part... each 8K bank on the ROM could be a different user-installed program, and the programs that require more than one bank would need to be smart enough to read the current bank register before doing a far jump. The code won't even need to be relocatable, because the 16-bit address would be the same for each bank. 

This does make me think of an additional change for the OS... a small block of RAM should be set aside for driver configuration. I don't think it needs to be much, maybe just a single page, with a set number of addresses per User bank. Assuming there are 8 banks of User ROM, then each bank would have a 32 byte block in configuration RAM. 

So the convention would be...

If the card is in slot 0, the driver software is in bank 0, and the configuration data is in 0-31 of the configuration page. 

If the card is in slot 1, the driver software is in bank 1, and the configuration data is in 32-63 of the configuration page. 

If the card is in slot 2, the driver software is in bank 2, and the configuration data is in 64-95 of the configuration page. 

If the card is in slot 3, the driver software is in bank 3, and the configuration data is in 96-127 of the configuration page. 

That leaves banks 4-7 for option ROM software.

 

 

Actually, we don't even need to do that. From what I gathered, there are still additional select lines available on the $01 register. We could use one of those lines to select internal or external ROM. So this basically would double the bank count, where half of the banks are the user ROM chip.   

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

22 minutes ago, Lorin Millsap said:

 

No you can’t. Not without supporting circuitry on the motherboard. The onboard ROM will still activate it will just end up mirroring.

 

Kevin said the board would support that, here: 

The easy way to do this is put a ROM chip on the expansion card and run a jumper wire from the chip's CS pin to the unused bank pin on the motherboard. Bank out the system RAM and bank in the ROM by setting the correct value in $01, and code is running from the expansion ROM. 

Kevin said the board would support that, here: 
The easy way to do this is put a ROM chip on the expansion card and run a jumper wire from the chip's CS pin to the unused bank pin on the motherboard. Bank out the system RAM and bank in the ROM by setting the correct value in $01, and code is running from the expansion ROM. 
 

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

9 hours ago, TomXP411 said:

Kevin said the board would support that, here: 



The easy way to do this is put a ROM chip on the expansion card and run a jumper wire from the chip's CS pin to the unused bank pin on the motherboard. Bank out the system RAM and bank in the ROM by setting the correct value in $01, and code is running from the expansion ROM.

 

Though the easiest way altogether is just use one of the however many User available FlashROM banks, because the selection logic for that is already done.

It would be straightforward to program the kernel to do a Far call to a specific ROM bank entry point based on the startup code stored in the RTC. Indeed, that could be the autostart mechanism ... if nothing is selected, the utility stores the ROM bank entry point for Basic COLD start, if you select autostart, the utility stores the ROM bank entry point for the autostart routine in Kernel, and you can explicitly specify a Far call location to run start-up code stored in a User segment of FlashROM.

BTW, FlashROM segments are 16K.

A parsimonious way to support ROM on an expansion card would to put the bits of the ROM bank out on an eight pin block header, and a ROM expansion card simply has it's own matching pin block header and a ribbon cable, with the specification that bit7 should be high to select external ROM and then bit5&6 select which card is being addressed. That allows 128K ROM per card. Then the extension required to the prototype logic is simply that internal ROM is not selected when bit7 is high ...

... then it's up to the card to detect that the address is in the ROM range at the same time that the high bit of the ROM bank is high, but that's only ROMB7=A15=A14=1, and ROMB5:ROMB6 matches the value in the jumper block.

But I don't know if the game is worth the candle, since with a single User FlashROM segment you can easily have the program support to access 3-wire serial ROM, and if there are enough GPIO free on the Serial Port after supporting the bit banged serial port, you can bit bang one of the serial ROM interfaces and have thee select pins to allow a User port daughter-board with four sockets for 3 wire serial ROM. Ditto on an expansion card, except it includes the VIA ... but same programming, just different I/O space.

And just as easily, a User FlashROM segment can just load a set of RAM segments with code on the SD card, and you have the equivalent effect, with no additional hardware overhead. And the files from the SD card would likely load faster than data from a serial ROM if it uses base I2C or 3-wire Microwire.