QuickOS - A Personal Project for XL/XE Computers

[Zolaerla]

Hiya people!

 

I have a long history of assembly programming (almost all x86, but some MC68K), but never seriously coded on the Atari 8-bit until about... July of this year. I decided to take on updating an old favorite game of mine, but while doing some updates, I broke the custom SIO code in it, and didn't want to just revert back to the old version. So of course I decided to ease into replacing it by making my own replacement gaming OS which was supposed to be nice and quick to code, hence the name of QuickOS. It... was not quick to code... like, at all. Just figuring out how to do SIO directly on the hardware, for example, was a month down the drain. Oof.

 

It is coded using CA65 with lots of scoping for the various pieces, and is designed to be assembled on disc booting up when you first start your game. It is absolutely NOTHING like the Atari OS. There are loads of configuration options, such as an optional boot screen that shows the progress while it's firing up and detecting everything. It supports sped up SIO all the way to divisor 0 (~126KBAUD), though to support high speeds I use a "Loading" progress bar for a simple screen while very high speed SIO is going. See the attached screen shots on a souped up 65c816 system with a U1MB and 3 different drives in Altirra for some samples of it detecting hardware. It's being designed with text screen support, strings, text output scripting, keyboard handling, RAM banking, and high speed SIO as well as the basic detection stuff. No sound or graphics, that'd the game's job to try to make fast. It is aimed towards larger games that need to do a lot of disk loading so detecting things up front and making things speedy during the game is the point. [ Edit: Forgot to mention, it all resides in $D800-$FFE0 at this time and only uses 39 bytes of the zero page and NONE of the rest of RAM since it can save its own data internally -- All of $0200 - $CFFF is free ]

 

If nobody cares, I'm going to work on this thing anyways for my own personal use and still put up the source once testing is all done and "green".

 

In any case, its initial version is in beta format as it needs some quirks worked out, but I wanted to find out if I should bother doing full online documentation and set up and stuff for other people to be able to access it. In other words, do people want such a thing?

Edited November 18, 2022 by Zolaerla
Forgot to mention the free memory

[TGB1718]

Sounds nice, could it run from a ROM? if it can then it's a possible option to install in U1M and Incgnito.

4 hours ago, Zolaerla said:

only uses 39 bytes of the zero page and NONE of the rest of RAM since it can save its own data internally -- All of $0200 - $CFFF is free ]

I suspect not as your saving data internally.

 

Will cartridges work with it ?

[Zolaerla]

7 hours ago, TGB1718 said:

Sounds nice, could it run from a ROM? if it can then it's a possible option to install in U1M and Incgnito.

I suspect not as your saving data internally.

 

Will cartridges work with it ?

It's not designed to be a ROM at all, since about 1/3 the code is in the initialization that gets wiped out after completion. It'd need a ~15KB ROM that loads in standard memory space, switches the ROM memory area to RAM, and copies that up. It'd be weird to set up. The thing is, it's meant to go along with a game with custom options that change the size of it, what features are included, and such.

 

I know practically nothing about how cartridges work on the XL/XE. Doing a quick look up on it, it seems they have an 8KB window at $A000-$BFFF with their own bank switching. I would have to make a different loader to load from that, but it wouldn't be too big a deal. You likely wouldn't need SIO and could disable the DriveIO component assembling a version for it. Are cartridges how most new developing is done these days on the 8-bit Atari?

[flashjazzcat]

If it's an OS, it can be flashed to an U1MB OS ROM slot, completely replacing the OS ROM at boot-time. You'd need to take what you end up with in the Shadow RAM, add an OS checksum, and save it as a 16K binary blob.

[Zolaerla]

27 minutes ago, flashjazzcat said:

If it's an OS, it can be flashed to an U1MB OS ROM slot, completely replacing the OS ROM at boot-time. You'd need to take what you end up with in the Shadow RAM, add an OS checksum, and save it as a 16K binary blob.

The point is to have this go with a game, with options catering specifically to your game. That's why I haven't even considered making this work as a ROM, because it would be different for each game. The idea is you load the game, it puts this into the RAM where the ROM used to be, and uses that to help manage the game instead of the default OS. Sure, I could make a "standard features" version that could be in a ROM, but that kinda defeats the purpose this was made for.

[flashjazzcat]

9 minutes ago, Zolaerla said:

The point is to have this go with a game, with options catering specifically to your game. That's why I haven't even considered making this work as a ROM, because it would be different for each game.

Oh right - sorry. Fully understood.

 

[snicklin]

I think that you will have interest if you do the following:

 

a. Explain why it is better to code for your OS rather than the standard OS. What advantages are there? Other than io speed changes.
b. Explain how coders must code differently with your OS.

c. What features are present/missing.

 

Or is it all the same but smaller and supporting faster io?
 

And just a general comment, that screen looks very verbose. Can you minimise that, but still get across all required info? Every byte counts, even if you have already saved a lot.

 

You have taken on a difficult project there, much kudos to you and thanks for your hard work.

[Zolaerla]

30 minutes ago, snicklin said:

I think that you will have interest if you do the following:

 

a. Explain why it is better to code for your OS rather than the standard OS. What advantages are there? Other than io speed changes.
b. Explain how coders must code differently with your OS.

c. What features are present/missing.

 

Or is it all the same but smaller and supporting faster io?
 

And just a general comment, that screen looks very verbose. Can you minimise that, but still get across all required info? Every byte counts, even if you have already saved a lot.

 

You have taken on a difficult project there, much kudos to you and thanks for your hard work.

 

a. It's designed to be fast and easy to use. The most astonishing thing already is how fast display is compared to the stock OS, though that doesn't take much since the Atari OS has a very weird way of outputting content to the screen. The OS is designed from the beginning to be configured with just the support you want and nothing else. There were multiple goals I had in mind when starting:
1) Easy to integrate into a new game -- it handles the boot and set up itself.
2) Configuration options. If you don't want or need it to load anything once your game is loaded, don't include the DriveIO. If you don't want to use the output scripting (ScreenScript), don't include that (though that's one of its best features). etc.
3) Fast, reusable functions that would actually be useful.

 

b. It uses a heavy register-based set of functions to minimize the code needed. For example, to do a QuickScreenScript, you would do something like:
DisplayData:
  LoadXYImmediate #SampleQSScript
  JSR QuickScreenScript::Output
  JMP QuickKeyboard::WaitKey ; includes RTS

SampleQSScript:
  QSS_Output "We've received "
  QSS_Int32 SomeDWord, "B" ; B - Big Endian
  QSS_Output " units.\n"
  QSS_JSR AnotherFunction ; JSRs to the function mid-script
  QSS_SetY -1 ; -1 = bottom line of the active screen
  QSS_AlignCenter
  QSS_Output "{Press Any Key}" ; { enables highlight mode, } disables it
  QSS_End
 

c. That's where the online documentation would come in.

 

People keep asking questions, so I'm going to guess some people are at least tentatively interested about what it does, so I probably should put up the docs online at least.

As far as the verbosity goes, that entire boot up sequence is optional. Don't like it, turn it off, all of that text won't show up or even be included in the binary. While coding this, however, it's very useful to me to see it booting up like that.

Edited November 18, 2022 by Zolaerla
fixed typo

[TGB1718]

13 hours ago, Zolaerla said:

so I probably should put up the docs online at least.

Would be very interested in seeing them

[xxl]

very nice idea, it would be good to have such a configurable library for disk handling, sound (music+sfx+speach), graphics, e.g. graphical user interface, sprites. even a connector to use the functions of the built-in basic interpreter could be made

 

 

---

here can be a source of inspiration for development:

 

TUI:

 

SFX:

https://forums.atariage.com/topic/320982-sfx-engine/?do=findComment&comment=4840036
 

Edited November 19, 2022 by xxl

[Zolaerla]

Well, getting started on the docs gave me an excuse to finish coding the minimal implementation of the documentation plugin for my CMS, which I've been needing to do anyways.

 

I haven't finished translating all of the components to the documentation format yet, just the kernel and QuickBank, but at least it's enough to see how whether the doc format makes sense as it is or not. The QuickString, QuickScreen, and QuickScreenScript features are where this really shines, since it is definitely oriented towards lots of types of text output, but they are also complex and it will take a while to convert the current text docs.

 

The main kernel information: http://docs.zolaerla.com/QuickOS/Component/Kernel
The QuickBank component: http://docs.zolaerla.com/QuickOS/Component/QuickBank

[Zolaerla]

I finally have converted the docs for QuickString and QuickScreen. Formatting these and coming up with meaningful examples was fairly time consuming, and I'll probably have to add more samples later, but at least the docs are up.

 

QuickScreen is designed for output to optionally multiple areas of the screen. It currently only supports full-width "windows", but I plan on adding optional partial-width window support since that adds so much more functionality:
http://docs.zolaerla.com/QuickOS/Component/QuickScreen

 

QuickString is a large collection of string manipulation functions. I plan on eventually allowing the game creator to pick and choose which functions are available, with some limitations necessary for other parts of the library to function of course:
http://docs.zolaerla.com/QuickOS/Component/QuickString