Jump to content
Lorin Millsap

Hardware Expansion and Driver Handling

Recommended Posts

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

  • Like 4

Share this post


Link to post
Share on other sites

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

  • Like 3

Share this post


Link to post
Share on other sites

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

  • Like 4

Share this post


Link to post
Share on other sites

I should say I'm not really qualified to comment about the hardware 🙂 But I do think the conversation should keep going. We chatted about this at length yesterday and I thought there were some good ideas, but also not sure how they would be implemented. Like if there could be a hardware standard of sorts that might include cards responding the same way to a special string of data put in the I/O spaces, one could probe for cards.

But at the same time, I think a config file would avoid this as you say and I kinda find it interesting a user given the X16 is now part Commodore and part PC DOS in a way 🙂 Bonus points if the file is called config.sys 😛

This led us to wondering what the concept of a "driver" would be for various cards and what that would mean. Like say if someone builds a GUS style soundcard that has it's own memory. One could then load a buncha high quality PCM data for triggering for "hardware accelerated" playback of higher quality samples (kinda like how GUS was used with Impulse Tracker on PC and I'm sure several games). A card like this probably wouldn't need to issue an IRQ too often, at least once it's been loaded with sounds (I could be wrong here heh) since, once loaded, the application just needs to tell it what sound to play and optionally at what frequency.

I'm not sure what a driver would look like here. At minimum, programs just need to know which of the 5 I/O spaces the card is configured at. In that context, a 'config.sys' style file might be useful, though particularly with perhaps some Kernel/ROM support so the code that fetches and reads the config doesn't have to be implemented by the program. The program just asks the kernel "at what address is XYZ" - beyond that though I dunno what else there might be needed here.

That said, an I/O card would probably need more driver style support. As in it might be nice to have a library for the card that makes it easier to use in applications. Say if someone wanted to implement a serial interface, a driver could abstract some of the work of the lower level comms so that applications can just worry about the data being sent or received (rather than, say, stop bits or ECC or any of that). In those cases though, being able to jump to the driver code by flipping a ROM page feels like it might be more convenient than having to use the SD card or eat up working RAM? But I would guess writing to the ROM isn't particularly trivial for a typical end user?

Related aside, that also makes me wonder...do we anticipate more than 255 or 65k cards made for the X16? I know "640k is enough for anybody!" but if the cards were limited, they could be given a unique ID which could be part of a card-database file on the SD card? Or maybe that's getting too complicated. It'd just simplify things so the app can ask the kernel: "Does card 123 exist in the system? If so, which I/O space is it at?"

The other thing we talked about was cards that would need to fire IRQs and what the impact of that would be. But I think that might fall on the app side - apps should know what hardware they want to use and so having them setup the IRQ routine for the hardware they care about makes sense? I dunno I'm starting to ramble on here so maybe I'll just leave it here for now.

 

I think my grand takeaway, and again I don't have enough suitable knowledge to really say in fairness, is having a hardware and software standard card makers agree to abide by could also make this easier for everyone. Easier said than done since everyone has an opinion, but I think given the goals of the X16, a solution that is easier to understand over one that was the most efficient, to me, makes sense - but yet again I dunno what that actually means in practical terms 🙂 I do get the feeling it's a bit of the wild west at the moment and so hopefully we see more feedback come about here. I think it's a hugely important topic myself so I'm glad you spent a lot of time to explain a bit of how this all works and hopefully start a good conversation over this.

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 2

Share this post


Link to post
Share on other sites

I really appreciate bringing this topic together in one new thread.

Also thank you for explicitly describing the hardware environment expansion cards will live in. I hope to see more specs about the expansion ports soon (like pin setup, timing diagrams, electric parameters and later on also size etc...) These specs might already exist somewhere - I am sorry, I didn't search for them yet.

I think we are already developing a common mindset. I support the main idea, a "driver" is "premade code to provide a higher level API" for accessing functions provided by expansion cards. In my opinion, we should have a look on which "hooks" does a driver need towards the system to integrate nicely. I would say, main aspects of these hooks could be "installation", "initialization" and "usage".

Installation is where the system should try to seemlessly integrate the expansion card into the system. If the card complies to a to-be-defined standard, it could be identified as a new card, drivers could be searched for, interactively be requested by a system installation software (my favourite). This aspect splits up into: identification of new cards, identification of (and possibly user support on) configuratin conflicts, getting "drivers" into the boot system and configure specific settings for that card/system setup.

You clearly stated, the selected way so war is dip-switch-like selection. There could be a standard for this, telling people to configure cards in slot 1 to line 1,... This is a guidance not to run into trouble by stting up simple rules. Card developers need to support ALL ids. Again, this is just a convention - and a good one I believe.

Since I hope, the install/config software is all included (no batteries needed...) I would hope, that there is a built-in way to control the boot process if there are errors (possibly unexpected ones) arising. Like "hold F8 during reset will boot in 'no driver loaded' safe mode". Just to bring in one idea how this could be solved.

Convention should also tell developers how to tell the installation program, what driver is needed, which options it has, things like this. 

A convention has the advantage that there could be a reference implentation and automated tests against it. Card developers could then test their implementations before distribution, that rises quality a lot and makes the users happy, too 🙂

Since things get a litte lengthy here, I'd like to talk about "initialization" and "usage" in the next post.

 

Share this post


Link to post
Share on other sites

So "initialization" is the process of running initial code and integration of other parts of it for future use in a "Terminate-Stay-Resident" like of way. I strongly appreciate a way of identifying that the driver loaded and initialized ok. So I believe a hook to the kernel in form of a return code including a possible error message would be great. The user likes to be informed that the card will not work as expected. Even more he would like to know what did not work out during this boot. It is an essential part of debugging in real world situations...

Initial code is "easy" since it will executed once at boot time. Providing an API to be called on demand or even by interrupts is to be looked at too. Again - a good convention would tell e.g. that the code always has to be relocatable and location is given during initial boot phase. Therefore the kernel should know what the driver needs - which is a convention again, as it does not need to be implemented in code. Might be metadata for the installer, which will do that definition of the memory layout for all stay-resident drivers and give that as options to the driver's init code.

It would be nice to provide a design philosophy to developers which would say: make your device as easy to use as possible, (but not any easier...) - so please provide a BASIC extension which adds high level function calls to access your cards functionality. If that is not possible, provide at least and in any case a "low level" API, namely (relative) entry points to functions, a description for those including how to provide functions arguments. This way the cards functions can be made use of by other users and developers at high or low level. Wait, did we say relocatable code? ok, so how do programs find that location? aahh, there is a kernal call for memory addresses of expansion card drivers, right? great!

I hope I could make my point clear without any offense. I believe that few functions are needed and a good convention with a test suite for developers.

Result would be a real product, still fully flexible but more compatible. Why bother to integrate more than one expansion port if no rules are set how to operate more than one card 😉 

I am eager to hear/read your thoughts on this.

 

P.S. You wrote, that you had a chat yesterday - is there a public chat like a discord channel or was that some internal chat only? If it was public, would you mind telling me how to join that? Thanks!     

Share this post


Link to post
Share on other sites

The argument against the  config files being Basic is Basic doesn't handle calling subprograms very well.
Now, it can be gimmicked with something along the lines of

10 IF F1 THEN 20:F1=1:LOAD"F1.BAS":RUN

20 ...

... and then the subprogram loads the main program.

However, this only works if the main program is bigger than the subprogram, otherwise the subprogram trashes the variable space of the main program.

One idea is to fix this with a special load keyword for the main config program that loads it AS IF it was a fixed size, even if it is smaller, so it is known what size subprograms can be without trashing the main program. If the filename is fixed, like CONFIG.BAS, then the main program load keyword doesn't need to include the filename, and it can simply be the last basic command in any subprogram.

So, for example, suppose that CONFIG is the keyword. It loads CONFIG.BAS and when the load is finished sets the program end vector to $7FFF. Now subprograms that are smaller than 30K can be run without trashing the main program.

This makes the High RAM and end of Low RAM memory management orthogonal to the configuration file system.

I also like the idea of a way for a driver to check whether it is already loaded. One idea is to have a defined High RAM segment that contains user readable configuration data like a HighRAM segment BAM, which could also contain a linked list of names of loaded drivers, so an installation program can check whether it's not yet loaded, or perhaps it's been loaded but taken out of the API chain.

 

 

Edited by BruceMcF

Share this post


Link to post
Share on other sites

Parameters can be placed in seperate files that could be of SEQ type. All we need to know is, which parameters to put there and which size/format they should have. The driver could then still be a single BASIC or assembler program.

However, the problem with subprograms would not be solved by this idea.

I think it would be a good idea to make a sketch a workflow of the whole process in which we could "top down" detail each step further. At the end there should be a full blown workflow of our suggested activities, each part has to do when following that convention. After having identified, which parts need additional software or software changes, we could start working on these and finalize a RC for the expansion convention. Sketching the workflow will also help others to understand, what our intent is and get a better understanding of the overall process. Would that be ok for you? If so, any suggestions where such a sketch could be graphed online, so we all could interactively change it? Would Google be a candidate?

While reading a note from another user, it came to my mind, that there could be a non DMA, non overlapping solution for the "include a driver in the card" thing:

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?

Share this post


Link to post
Share on other sites
3 minutes ago, paulscottrobson said:

Is DMA Access going to be a thing with peripherals, specifically Vera ?

 

As I understand it, it has only few advantages but many drawbacks. Timing is much more critical. If I got it right, it works by suspending the 65C02 and using the bus all by yourself. That might lead to unexpected results as this could happen at any time, I guess transfer start should be triggered by 65C02 code.

I am not sure about the speed advantage, maybe someone could help me here: 

I believe DMA can write one byte to any address (on an active bank) in 1 clock tick, so effectively writing at 8 MByte/s. Using memory mapped I/O this is reduced to the speed of READ,INCREMENT,LOOP cycle, so at best like this - sorry, my 6502 assembler is a bit rusty... 

(Transfer 256 bytes memory mapped IO with auto decrement on external side):

  LDY #$0
loop:
  LDA $MEMORY_MAPPED_IO_ADDRESS  ; 4 ticks
  STA $TARGET_ADDRESS, Y   ; 5 ticks
  DEY  ; 2 ticks
  BNE loop  ; 3 ticks (given that code is page aligned)

So, transfering would cost like 14 ticks, not using zero page tricks if that is possible. So let's just say 10 ticks optimized - DMA transfer is still at least 10 times faster. Is that true?   

 

Share this post


Link to post
Share on other sites

Ben Eater talks about DMA and the RDY pin on the 6502 in this video: 

From around 6:30 he talks about how his video card "pauses" the CPU to read the memory.

I am pretty sure that VERA will never use DMA as it has it's own memory. Other peripherals might use DMA, but I think that IRQ and/or polling will be a lot easier. 

 

Share this post


Link to post
Share on other sites
13 hours ago, BruceMcF said:

I also like the idea of a way for a driver to check whether it is already loaded. One idea is to have a defined High RAM segment that contains user readable configuration data like a HighRAM segment BAM, which could also contain a linked list of names of loaded drivers, so an installation program can check whether it's not yet loaded, or perhaps it's been loaded but taken out of the API chain.

oh yeah ! That's sound very nice to my ears :):)

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites
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.

I thought KERNAL would be in ROM, and would run directly from there. So how do I change its vector entries in ROM?

Share this post


Link to post
Share on other sites
6 hours ago, Cyber said:


I thought KERNAL would be in ROM, and would run directly from there. So how do I change its vector entries in ROM?

The vector table is copied into ZP at bootup. This is how it's accessible from any bank.

  • Thanks 1

Share this post


Link to post
Share on other sites
10 hours ago, Cyber said:


I thought KERNAL would be in ROM, and would run directly from there. So how do I change its vector entries in ROM?

There is a set of vectors that various I/O routines use, between the hardware stack at $01xx and the Golden RAM at $0400-$07FF.

At power up they are set to point to Kernal routines but you can install drivers by copying the current vectors, writing in vectors pointing to your driver, your driver checks if it is the device being called, if not, it SHOULD jump to the previous driver. So the two main tasks of driver installation are hooking the driver code into the vector chain, and finding places to put the driver code ... typically the end of system RAM, Golden RAM or bank accessing code in one of those two and driver code in a RAM or User ROM segment if the driver code is longer. The Low RAM part could be as short as a far call to the routine in its segment, but if the device checking is done in Low RAM and you only far call when it IS your device number, that would make a faster device chain.

Edited by BruceMcF
  • Thanks 1

Share this post


Link to post
Share on other sites
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.

Edited by BruceMcF

Share this post


Link to post
Share on other sites
On 1/8/2021 at 9:14 AM, Lorin Millsap said:

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

1. Serial ROM... I think the EasyFlash and GMod use this system to save games. 
2. Vector reading from card ROM the same way VERA is vectored. Some sort of latch on the card would set the address on the ROM chip, which would put the data on a particular address on the card. 

Those approaches would still require cooperation from the Commander, though... and since this means running a program from SD, there's little reason to store data on the card when one can just read it from the SD card.

The only thing I can think of that would be useful is a ZIF socket on the motherboard for a user ROM... then a user could install a driver or utility ROM for an expansion card. 

Share this post


Link to post
Share on other sites
24 minutes ago, TomXP411 said:

The only thing I can think of that would be useful is a ZIF socket on the motherboard for a user ROM... then a user could install a driver or utility ROM for an expansion card. 

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

Again, the driver installation program can easily look for an .INFO file that includes an entry if the driver is available in ROM and what bank and addresses to install into the vector chain. As long as a generic program can be added to a list of programs to run, that would appear to be covered by the upgrade from 128K to 512K FlashROM.

Edited by BruceMcF

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Edited by kelli217

Share this post


Link to post
Share on other sites
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.

 

 

Edited by BruceMcF

Share this post


Link to post
Share on other sites
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.

Edited by TheUnknownDad

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use