Commander X16

Given that the main memory map appears to be finalized, it does indeed appear to be set in stone that there is no ROM window that puts ROM on a card into the address space, unless a 32byte window in the I/O page will suffice.  There will, however, be User segments available in the flash ROM, so if some card makers want to collaborate on a technique to window into a ROM through one of the 32byte device address spaces and copy code into a RAM bank, then a single ROM image could contain the routines required to do that.

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

13 minutes ago, Lorin Millsap said:

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.

Thanks Lorin, but isn't installing drivers something we love to not have needed "back then"? As I stated, this approach is very technical and maybe inconvenient for users, even though (or maybe bacause) they are retro enthusiasts. Does the design team have a target user group characterized? Could I find this (or a discussion on that) somewhere? I could learn more about the the product philosophy.

I imagine this computer should somehow revive that old feeling of "turn it on and let the fun begin". Here is an expansion card - it "just works"(TM). One part of the old fun was. that it was all selfcontained. No need to tamper around with another system to get up and running.

I am not asking for a design change here - I was asking for the intended use of the system. If that old way of getting things to work would still work, that would be nice and retro too.

I can skip DMA stuff, if there is a way to get my loader being called at the 32 Byte I/O window and that loader copies all needed code into RAM via the CPU. But that would actually require some kernel function to support this while booting. Just like the old cartridges.

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

19 minutes ago, Lorin Millsap said:

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.

 

Ok, many points here, let me get into this.

First of all: Plug and play was or is not a design goal? 

I understand your point regarding SD speed, I am still looking for that PnP usabililty.

From what I have heard and understood so far: physically, the system is extendable, but the way extensions are handled in a software way is not yet looked at?

Regarding hardware conflicts: I don't see the point. It is up to good design, to tell expansions apart. Am I right, that each expansion slot has its dedicated 32 byte I/O area? Or are they simply shared among all cards and you are "not to listen" to other devices I/O by magically selecting a free I/O memory area? So, if there is a way for the card to identify which I/O slot it is in, and there is a clear association, why is there hardware conflicting? We are still in the spec setting phase - so implementation can be regulated. Do it this way and things work out fine. There should also be a way to safely identify all connected expansion cards and the memory slot they are using. Is that already though of and part of the kernel?

What is the main planned usage of these expansions? Is it to take over the whole system or add special funcionality that ought to be used by either ASM or better even BASIC? If the later, how is the supposed way to add new commands in a compatible way? (so that more then one card can add BASIC commands!)

Don't get me wrong - this is no blaming or bashing. I just want to point into a certain direction of thinking about the system. I am eager to help if this direction has not yet been thought of. I believe that once the X16 is out, to have a working eco system, these expansion questions should be worked out already. Giving people a ready built example will help to implement new stuff and drive the eco system. It also sets standards to usage.

If I am all wrong and that expansion system is already all laid out well on hardware and software side (architecture), could you please be so kind to point me to the documentation? That would help me understanding a lot. Thanks.

2 hours ago, TheUnknownDad said:

That sounds interesting. Will there be a kernel function to step through the expansion slots I/O memory areas and check whether there is a card and let that initialize itself (with maybe even copying a ROM into RAM, patching BASIC vector, stuff like that? That would make expansion slot extensions a lot more flexible and would not bother users to manipulate SD card content. It could even be that there is an address to be jumped at per JSR and that byte holds RTS but could actually contain a small boot code?



We could check whether 32 bytes can make nice init function for expansion cards...



Kernel could check if there is a magic number in I/O space and then hand over execution of code. It should be possible to deactive this expansion card initialization either via keypresses on reset or via menu/system config. Manual starting of this should also be possible then.

I don't follow "would not bother users to manipulate SD card content." It seems a lot simpler to just have a basic program load things up that you want loaded and set it to be the power up autoload program. This all seems like trying to solve problems the hard way because of some desire to not solve them the easy way.

1 minute ago, BruceMcF said:

I don't follow "would not bother users to manipulate SD card content." It seems a lot simpler to just have a basic program load things up that you want loaded and set it to be the power up autoload program. This all seems like trying to solve problems the hard way because of some desire to not solve them the easy way.

I would try to splitt that apart into two aspects: Installing and using.

I want to make sure that everyone can do both. Many of my questions above in the discussion with Lorin are pointing to the "install" part. I am a strong believer in ease of use. I don't doubt, that getting an autoload program from SD is technically the best solution (as long as it then manages things like installing BASIC extensions & stuff like that).

How will the "setup" programm  get on the SD card? What does the user need to decide and what does he need to know to use the expansion card? My way of looking at things is to hide all technical aspects but not to make them unavailable. Meet people at their specific level and give them the opportunity to evolve further by digging deeper - but only if they want to.

Think of "Simon's Basic". As an example, it makes graphics easily accessable - you don't need to know how C64 managed graphical memory. It was "just there". You could also expand things yourself and tamper around with it. But to use it initially, you're not expected to copy anything anywhere, reply to configuration questions, edit config files, change disks, etc.

Why not make it as easiest as possible to start with? This is what my philosophy is so far.

If there are other technical ways of achieving the same - be my guest.  I just wanted to understand how to realize it with the possible X16 architecture so I can implement it in a way that could be used as a tutorial/example.

23 minutes ago, TheUnknownDad said:

I would try to splitt that apart into two aspects: Installing and using.



I want to make sure that everyone can do both. Many of my questions above in the discussion with Lorin are pointing to the "install" part. I am a strong believer in ease of use. I don't doubt, that getting an autoload program from SD is technically the best solution (as long as it then manages things like installing BASIC extensions & stuff like that).



How will the "setup" programm  get on the SD card? What does the user need to decide and what does he need to know to use the expansion card? My way of looking at things is to hide all technical aspects but not to make them unavailable. Meet people at their specific level and give them the opportunity to evolve further by digging deeper - but only if they want to.

That will be however the autoloaded program does it, isn't? Those are all important problems for an autoload program to solve, but if an autoload program has problems solving them, "write a better autoload program" seems to me to be a lot more effective response than "make massive changes to the hardware architecture".

8 minutes ago, BruceMcF said:

That will be however the autoloaded program does it, isn't? Those are all important problems for an autoload program to solve, but if an autoload program has problems solving them, "write a better autoload program" seems to me to be a lot more effective response than "make massive changes to the hardware architecture".

That is totally true.

I wasn't initially asking for hardware architecture change. I was asking for details on how that whole expansion system is supposed to work. I already stated that I am desperately looking for information on the whole process of booting and integration von expansion cards in that process.

Hardware changes are only valid in two cases: 1. something is impossible to realize in software only; 2. things are really, really complicated to solve in software and would be easy with very little change to the design.

I hope too, that both reasons are no longer valid.

On 1/8/2021 at 11:37 PM, TheUnknownDad said:

That is totally true.



I wasn't initially asking for hardware architecture change. I was asking for details on how that whole expansion system is supposed to work. I already stated that I am desperately looking for information on the whole process of booting and integration von expansion cards in that process.



Hardware changes are only valid in two cases: 1. something is impossible to realize in software only; 2. things are really, really complicated to solve in software and would be easy with very little change to the design.



I hope too, that both reasons are no longer valid.

The BASIC interpreter is much less set in stone than the memory map ... if it can be done at the keyword level. DEC Basic was not modular at all when Bill Gates "borrowed" it's design for 8080 Basic, and MS 6502 Basic was a port of 8080 Basic, so structural changes can be a major challenge, but adding a keyword is much more straightforward. So I would hope a main config file loading keyword can be devised that allow loading regular programs without the current problem of the subprogram overwriting the main program.

Then the main program could be a program that reads a filename from a sequential file, loads and runs it. The subprogram runs the config program again, it reads the second filename from the file and runs it. And so on until the end of the file of filenames. Interspersed are section names in some distinctive format which the master config program ignores and grabs the next name .

Then a utility to edit the list of filenames and insert the name of the config program(s) in the section(s) that they belong in, based on an .INFO file, which is run to install the drivers into that list of filenames.

 

On 1/8/2021 at 3:19 PM, TheUnknownDad said:

isn't installing drivers something we love to not have needed "back then"?

I loved this driverless approach in the past, despite it being primitive and obsolete in modern world. And I'm happy that X16 brings back this experience.