OS larger than 16kB

[ivop]

Hi all,

 

Has anybody ever considered creating a larger OS than the current 16kB? With the ability to programatically switch between four OS banks on the U1MB, one could easily consider them a pair of 32kB OSs or even one big 64kB OS

 

Let's consider a 32kB OS. The second bank should have the RESET vector redirected to select the first bank. Both charsets should be present. All the interrupt code. Perhaps some more.

 

After that, you can reuse large parts of the second bank for other code. A driver in bank one can switch banks at a certain point in memory, continue execution in the second bank, switch back at the right memory location, continue execution in bank one again, and return to the userspace program.

 

Any thoughts on this?

 

Regards,

Ivo

[Wrathchild]

potentially stack work would be needed as interrupts occurring when different banks are switched in need also to push the current bank so that it can be restored before returning control to it

[flashjazzcat]

My first thought it that you cannot programatically switch between the four OS ROM banks on the U1MB unless you are the setup menu. Only the reset line being pulled low allows the configuration to be unlocked, which is a pre-requisite for switching ROM banks.

 

There's no real reason you couldn't use extended RAM banks for a similar purpose, though; SDX already greatly extends the core functionality of the machine via drivers which may reside almost wholly in extended RAM banks.

 

[snicklin]

Not a new OS as such  but I have considered a new language that comes with a lot of prebuilt commands, taking up ROM space. You could have a 128kb language on ROM, making a very high level language for rapid development.

[flashjazzcat]

You could have a 1MB or larger language on ROM; just use a banked cartridge.

 

Edited January 31, 2021 by flashjazzcat

[ivop]

3 hours ago, flashjazzcat said:

My first thought it that you cannot programatically switch between the four OS ROM banks on the U1MB unless you are the setup menu. Only the reset line being pulled low allows the configuration to be unlocked, which is a pre-requisite for switching ROM banks.

I suppose the setup menu locks the configuration registers upon exiting, but could it also leave them unlocked so they can still be changed later on?

 

Quote

There's no real reason you couldn't use extended RAM banks for a similar purpose, though; SDX already greatly extends the core functionality of the machine via drivers which may reside almost wholly in extended RAM banks.

I think it could be nice having them in ROM, without having to load or copy them to RAM, and they won't apear in the middle of your RAM space when its code is toggled on and off. One could include phaeron's fast XEP80 driver for example in the extra ROM space that becomes available. Or other E: drivers, possibly selectable from your setup menu. Or various P: drivers. Or D : drivers for joystick port connected harddisks. And so on...

3 hours ago, Wrathchild said:

potentially stack work would be needed as interrupts occurring when different banks are switched in need also to push the current bank so that it can be restored before returning control to it

The idea is to keep all the interrupt code the same in both banks which would mean it doesn't matter which bank is switched in. Only the rest of the OS might be different for a while when the userspace application does a CIO call.

 

Edited January 31, 2021 by ivop

[flashjazzcat]

5 minutes ago, ivop said:

I suppose the setup menu locks the configuration registers upon exiting, but could it also leave them unlocked so they can still be changed later on?

Unfortunately not. Until the config is locked, the BIOS setup menu ROM is fixed in the OS ROM address space. Locking the config is essential anyway, since bad things could otherwise happen because of accidental writes to the control registers in the PIA address range (the registers disappear when once the configuration is locked, to become visible again when RST is pulled low).

7 minutes ago, ivop said:

I think it could be nice having them in ROM, without having to load or copy them to RAM, and they won't apear in the middle of your RAM space when its code is toggled on and off. One could include phaeron's fast XEP80 driver for example in the extra ROM space that becomes available. Or other E: drivers, possibly selectable from your setup menu. Or various P: drivers. Or D : drivers for joystick port connected harddisks. And so on...

The address space contention between code and data in extended banks can be a big problem, for sure. That's the main reason I decided to put my GOS on a bank switched cartridge. Of course this assumes you want or need to use extended RAM banks for data too, which may not be the case. Careful placement of code and data can still overcome these limitations, though (see SDX drivers which place the majority of their code in extended RAM, but are still able to work with data in the extended RAM banking window).

 

[ivop]

15 minutes ago, flashjazzcat said:

Unfortunately not. Until the config is locked, the BIOS setup menu ROM is fixed in the OS ROM address space.

Oh, that's a pitty. I was hoping that the configuration registers, or at least the OS ROM switch register, could be left unlocked.

 

Even though as you say,

15 minutes ago, flashjazzcat said:

Locking the config is essential anyway, since bad things could otherwise happen because of accidental writes to the control registers in the PIA address range (the registers disappear when once the configuration is locked, to become visible again when RST is pulled low).

accidental writes could mess things up. But I guess proper behaving software should not be a problem, i.e. if they don't use mirror locations?

 

15 minutes ago, flashjazzcat said:

The address space contention between code and data in extended banks can be a big problem, for sure. That's the main reason I decided to put my GOS on a bank switched cartridge. Of course this assumes you want or need to use extended RAM banks for data too, which may not be the case. Careful placement of code and data can still overcome these limitations, though (see SDX drivers which place the majority of their code in extended RAM, but are still able to work with data in the extended RAM banking window).

Yes, the banking scheme and minimal code in main RAM used by SDX is a work of art

[flashjazzcat]

Just now, ivop said:

But I guess proper behaving software should not be a problem, i.e. if they don't use mirror locations?

LOL... well, I guess we discovered that there are people who INSIST on using mirrored locations.

1 minute ago, ivop said:

Yes, the banking scheme and minimal code in main RAM used by SDX is a work of art

Yes, it was extremely well designed by the original author, and the current developers have likewise done a great job of making intelligent and well thought-out improvements.

[ivop]

Some more thoughts. Perhaps a custom U1MB firmware could leave the OS select register unlocked, but reflashing the firmware is not easily done for everybody, and hence will severly limit the spread, and use of a potential new 32kB OS. How about the 32-in-1 Maxflash upgrade? I have no idea how that one works. Can one switch banks while in operation? Downside of this approach is that it won't work together with U1MB, and the 32-in-1 cannot be flashed by the Atari itself, so you have to have some other means to (re)flash new ROMs.

 

 

[Rybags]

The interrupt thing - maybe not such a big problem, just replicate the handlers in each bank.

For me the obvious thing to have with a >16K OS would be a built in Dos with minimal Ram footprint.  And a decent monitor as well.  Just between those two you might be looking at most of the Rom space used (also noting you'd have to replicate the built in character sets and possibly the FP Rom portion).

[ivop]

7 hours ago, Rybags said:

The interrupt thing - maybe not such a big problem, just replicate the handlers in each bank.

For me the obvious thing to have with a >16K OS would be a built in Dos with minimal Ram footprint.  And a decent monitor as well.  Just between those two you might be looking at most of the Rom space used (also noting you'd have to replicate the built in character sets and possibly the FP Rom portion).

I believe I said similar things in the first post   But FP ROM is a good call! As for a built-in DOS/DUP and monitor, that's a great idea! Perhaps @candle can incorporate a new feature in the PBI device he's creating (U1MB+SIDE3+...) where one can leave the OS bank select register unlocked, and perhaps the BASIC bank selection, too, which could lead to bigger languages in an 8kB window.

 

I have read @phaeron 's U1MB implementation, and if that's how the hardware currently works, I see no way around it. It seems 32-in-1 OS is not emulated by any of the emulators, and I'm having a hard time finding its programming documentation

Edited February 2, 2021 by ivop

[thorfdbg]

4 hours ago, Rybags said:

For me the obvious thing to have with a >16K OS would be a built in Dos with minimal Ram footprint. 

Exists already, look into Os++ that comes with Atari++. It includes a Dos which takes only page 7 + disk buffers. The latter can be relolcated behind the Basic ROM or the Os if you need even lower footprint.

[thorfdbg]

1 hour ago, ivop said:

I believe I said similar things in the first post   But FP ROM is a good call! As for a built-in DUP and monitor, that's a great idea! @candle

 

All existing already .. see above. Os++ has a faster FP ROM, a DOS and a DUP, all in the regular 16K ROM.

[ivop]

2 hours ago, thorfdbg said:

All existing already .. see above. Os++ has a faster FP ROM, a DOS and a DUP, all in the regular 16K ROM.

But if I'm not mistaken, you took out the PBI code, isn't it? PBI code really is necessary these days.

 

And wouldn't you like to have 10-12kB extra ROM space (for each extra bank) to enhance the current OS? HATABS can hold up to 12 drivers!

 

But alas, there's no hardware support ?

 

[thorfdbg]

13 hours ago, ivop said:

But if I'm not mistaken, you took out the PBI code, isn't it? PBI code really is necessary these days.

 

And wouldn't you like to have 10-12kB extra ROM space (for each extra bank) to enhance the current OS? HATABS can hold up to 12 drivers!

 

But alas, there's no hardware support ?

 

By whom? Frankly, the number of PBI devices is rather low... the whole thing is grossly underdocumented, so I don't dare to look into this dark area of the Os.

[flashjazzcat]

3 hours ago, thorfdbg said:

By whom?

Probably over a thousand U1MB users, not to mention IDE Plus, MIO, etc. What Apple would call 'a very small percentage'.

[+Stephen]

3 hours ago, thorfdbg said:

16 hours ago, ivop said:

But if I'm not mistaken, you took out the PBI code, isn't it? PBI code really is necessary these days.

 

And wouldn't you like to have 10-12kB extra ROM space (for each extra bank) to enhance the current OS? HATABS can hold up to 12 drivers!

 

But alas, there's no hardware support ?

 

By whom? Frankly, the number of PBI devices is rather low... the whole thing is grossly underdocumented, so I don't dare to look into this dark area of the Os.

I'd guess everyone using a hard drive of some sort (Ultiate 1MB + SIDE2/SIDEB, IDE2+, etc.)?  I won't use my daily machine without HDD these days.

[flashjazzcat]

28 minutes ago, Stephen said:

I'd guess everyone using a hard drive of some sort (Ultiate 1MB + SIDE2/SIDEB, IDE2+, etc.)?

Not to mention those without a hard drive who enjoy the U1MB's built-in OS agnostic high-speed SIO driver which is capable of divisor 0 transfers.

 

In fact, the PBI/NewDevice API is a perfect way to extend the functionality of the OS without having to write a new operating system at all. All the U1MB PBI BIOS is essentially doing is incorporating driver code into the OS without changing the underlying OS. If one is going to rely on third-party hardware anyway (U1MB or some new variant thereof) in order to have a 32K bank switched OS presumably packed with driver code, you might as well just build additional PBI device handlers into it (the stock OS supports up to eight) to accomplish what you want. PBI handlers can even register themselves as HATABS device drivers, so you could have - say - a PBI 80 column display driver which didn't require the loading of any drivers at all.

[ivop]

3 hours ago, flashjazzcat said:

Not to mention those without a hard drive who enjoy the U1MB's built-in OS agnostic high-speed SIO driver which is capable of divisor 0 transfers.

?

3 hours ago, flashjazzcat said:

In fact, the PBI/NewDevice API is a perfect way to extend the functionality of the OS without having to write a new operating system at all. All the U1MB PBI BIOS is essentially doing is incorporating driver code into the OS without changing the underlying OS. If one is going to rely on third-party hardware anyway (U1MB or some new variant thereof) in order to have a 32K bank switched OS presumably packed with driver code, you might as well just build additional PBI device handlers into it (the stock OS supports up to eight) to accomplish what you want. PBI handlers can even register themselves as HATABS device drivers, so you could have - say - a PBI 80 column display driver which didn't require the loading of any drivers at all.

Yes, maybe it's a better idea to increase the PBI ROM space significantly instead of leaving the OS ROM bank switch register unlocked. Although an option to have that ability could still be nice, because with a 2kB PBI ROM window, you might have to split up drivers to fit in several banks, which is not needed if you can temporarily switch in ~10kB of new ROM code. I'd say implement both options

 

[flashjazzcat]

21 minutes ago, ivop said:

Yes, maybe it's a better idea to increase the PBI ROM space significantly instead of leaving the OS ROM bank switch register unlocked.

I'm expecting much more PBI ROM and RAM space for future expansion, but there are not currently any plans to implement multiple discreet PBI device handlers on the same hardware.

22 minutes ago, ivop said:

Although an option to have that ability could still be nice, because with a 2kB PBI ROM window, you might have to split up drivers to fit in several banks, which is not needed if you can temporarily switch in ~10kB of new ROM code.

The 2KB ROM window is hardly a limitation at all. The existing U1MB PBI BIOS ROM is 8K in size, but split across 4x 2KB banks. Inter-bank JSRs are accomplished by macros which call the entry code which is located at the same location at the top of every 2KB bank (where the exit wrapper is also situated). Overheads are small, although one obviously seeks to avoid inter-bank calls in speed crtitical sections. But you can scale this up as large as you need to go without too much trouble. Likewise the SIDE3 loader does a lot of bank switching (although the banks are 8KB in size there). The OSS languages (BASIC XL, Action!, etc) are other good examples of very efficient, tightly coded bank-switched ROMs (they have one static 4K ROM bank and a 4K banked window).

 

[ivop]

43 minutes ago, flashjazzcat said:

I'm expecting much more PBI ROM and RAM space for future expansion, but there are not currently any plans to implement multiple discreet PBI device handlers on the same hardware.

I'm a VHDL/Verilog n00b, but it would be nice if the PBI ROM of say 128kB (64 banks) would be split in two or more PBI devices.

 

But if not, the first PBI ROM bank could install several drivers that all dispatch through the first bank, and select the bank they need for further processing.

 

Quote

The 2KB ROM window is hardly a limitation at all. The existing U1MB PBI BIOS ROM is 8K in size, but split across 4x 2KB banks. Inter-bank JSRs are accomplished by macros which call the entry code which is located at the same location at the top of every 2KB bank (where the exit wrapper is also situated). Overheads are small, although one obviously seeks to avoid inter-bank calls in speed crtitical sections. But you can scale this up as large as you need to go without too much trouble. Likewise the SIDE3 loader does a lot of bank switching (although the banks are 8KB in size there). The OSS languages (BASIC XL, Action!, etc) are other good examples of very efficient, tightly coded bank-switched ROMs (they have one static 4K ROM bank and a 4K banked window).

 

Very true. The same way you do inter-bank JSRs and return would be needed between the main OS bank and the "other" banks(s). Bigger window size is always welcome, but it's indeed questionable if timing critical routines need more than 2kB

 

 

Edit: either way, it would be completely in the spirit of the original OS. No OS changes are necessary. And considering that most drivers probably need more than 2kB anyway, a dispatch bank would not significantly increase the execution time.

Edited February 3, 2021 by ivop

[flashjazzcat]

23 minutes ago, ivop said:

I'm a VHDL/Verilog n00b, but it would be nice if the PBI ROM of say 128kB (64 banks) would be split in two or more PBI devices.

On the face of it, having a couple of discreet device handlers isn't a bad idea. If device #1 is reserved for the PBI HDD and SIO, device #2 could be repurposed to suit the needs of the user (FujiNet, etc).

23 minutes ago, ivop said:

The same way you do inter-bank JSRs and return would be needed between the main OS bank and the "other" banks(s). Bigger window size is always welcome, but it's indeed questionable if timing critical routines need more than 2kB

Writing the PBI BIOS and later the loader was definitely an education in writing banked ROMs/carts. The LJSR macro encodes the destination bank and address in 2 bytes of in-line data following the call to the LJSR function (this is possible thanks to the fact only 11 bits are required for the target address; the bank number is packed into the high 5 bits.

Edited February 3, 2021 by flashjazzcat

[thorfdbg]

On 2/3/2021 at 3:12 PM, Stephen said:

I'd guess everyone using a hard drive of some sort (Ultiate 1MB + SIDE2/SIDEB, IDE2+, etc.)?  I won't use my daily machine without HDD these days.

Oh well, maybe we have very different ideas what kind of a system this should be. Any kind of hard disk handler will take even more of my precious RAM. If I would want a faster or more powerful machine - I have a PC, thank you.

[+Stephen]

11 minutes ago, thorfdbg said:

Oh well, maybe we have very different ideas what kind of a system this should be. Any kind of hard disk handler will take even more of my precious RAM. If I would want a faster or more powerful machine - I have a PC, thank you.

But this is a feature Atari provided to us all the way back in 1984.  It's not like I'm advocating putting in an accelerated CPU or anything.  No worries - we have so many nice upgrades which allow for switching OSes, so it's not like a missing feature would cripple a machine.

 

Again though - I wonder about how people seem to use their machines.  Should we not use floppy disks because we have cassette?