Extending the MTX OS

Everything about programming, including VDP and Sound programming.
Post Reply
User avatar
thewiz
Posts: 137
Joined: 12 Aug 2012 16:08

Extending the MTX OS

Post by thewiz »

Hi,

I am looking to document how the MTX OS can be extended for the Resourced document that Martin and Bill have been updating.

This will cover error messages, Noddy, Panel, Interrupts and USER plus anything else I find. Reading the sysvars there is also USRRST which is examined on calling RST 38 or NMI. Also USERIO which is examined on calling $0079, the keyboard scanning routine.

The are various examples of other people doing this but each tend to expect to run on the machine on its own. What I would like to do is be able to mix and match and have them all working together.

To do this, they need to be stored somewhere where they wont overwrite anything. Ideally it would by nice to save it too. I think there is a sysvar that tells save where the start of sysvars start in memory. That might be useful.

Did Memotech have any ideas on where all these extensions would live in memory?
THIS is what Memotech is doing now.
Bill B
Posts: 593
Joined: 26 Jan 2014 16:31

Re: Extending the MTX OS

Post by Bill B »

I think Memotech would expect user code to either be within CODE lines within BASIC or within a machine code game which took over the machine.

However, I think you are asking where it is possible to install extensions which remain resident through NEW.

There is 256 bytes free between the bottom of system variables and the sound control buffers. I have used that space for updating the keyboard mapping to work with the PS2/USB keyboard interface.

If an SDX is installed, there are gaps in the memory that uses, which I have documented here, also in ReSource. However Rememoriser or CFX probably use some of these spaces.

Otherwise put the code below 0xD700 (the bottom of SDX BDOS) and set STKLIM below the bottom of your code.

When saving to tape, everything between STKLIM and SYSTOP is saved as the second block on the tape.

Ultimately, expansion ROMs (such as SDX or NODE) would install hooks, copy some routines to high memory, and adjust STKLIM
Bill B
Posts: 593
Joined: 26 Jan 2014 16:31

Re: Extending the MTX OS

Post by Bill B »

One of the problems with trying to combine extensions is that Z80 code is not, in general, relocatable.

Therefore there would need to be a global list of where in memory each extension lived, not to be used by any other extension. This could be very wasteful of memory if only loading one extension which lives low in memory.

Alternately, each extension would need to come complete with an installation program, which:
  • Moves STKLIM down by the space required by the extension
  • Copies the extension into the space created
  • Patches the copied code to fix-up jumps and calls to match the installed location
Martin A
Posts: 799
Joined: 09 Nov 2013 21:03

Re: Extending the MTX OS

Post by Martin A »

Realistically #C000 upwards is the only place for extensions. Everywhere else is either read only or liable to be moved without warning.

That means sharing with the variables and disc systems etc.

Since that's going to limit everything to a total of 5k or so on a disc system, exlclusive ownership is probably unworkable.

Putting extensions on a "page" boundary to borrow a 6502 term would simplify the relocation. At there would then just need to be a list of high bytes to adjust.
User avatar
thewiz
Posts: 137
Joined: 12 Aug 2012 16:08

Re: Extending the MTX OS

Post by thewiz »

It seems a shame that with all the extensibility available, having a place to put it is so restrictive. But then its been 35 years since those times and my thinking has become changed by all the software techniques I've come across since.

I think I should think about how someone would of done this BITD. I might also of got a bit excited over this and for Resource should just concentrate on the how.

Then I can write a monolithic extension that includes everything at a set location :D Can have some fun writinh something for developing and running games in Basic.

Thanks for your responses. The bit about STKLIM will be very useful and, being a none hardware or cpm guy, hadn't thought about systems with extra hardware.

Just thought, might have to do something about daisy chaining USER.
THIS is what Memotech is doing now.
Post Reply