Balancing compatibility with innovation .. ZXPand(+)
Balancing compatibility with innovation .. ZXPand(+)
So here's the thing.
ZXpand provides a number of facilities for the programmer including a set of function entry vectors. These ensure that code written for one version of the ROM stands a very good chance of working with the next. It' turns out that not many people know about these, which is probably my fault as I never updated the documentation
Most programmers hit the hardware directly. In some ways this isn't a bad thing as the hardware interface is more stable than the software one, but it does mean that everything could break when a big change comes.
Hardware compatibility has been retained for the move to ZXpand+. I'm pretty sure that I can keep software running unmodified on both platforms. That is my aim.
However.
Is it reasonable to expect that some software might break* or go on to exist in multiple versions** should some feature or other get changed in the interest of innovation?
Discuss.
*and subsequently get fixed
** normally something I hate
ZXpand provides a number of facilities for the programmer including a set of function entry vectors. These ensure that code written for one version of the ROM stands a very good chance of working with the next. It' turns out that not many people know about these, which is probably my fault as I never updated the documentation
Most programmers hit the hardware directly. In some ways this isn't a bad thing as the hardware interface is more stable than the software one, but it does mean that everything could break when a big change comes.
Hardware compatibility has been retained for the move to ZXpand+. I'm pretty sure that I can keep software running unmodified on both platforms. That is my aim.
However.
Is it reasonable to expect that some software might break* or go on to exist in multiple versions** should some feature or other get changed in the interest of innovation?
Discuss.
*and subsequently get fixed
** normally something I hate
Re: Balancing compatibility with innovation
I understand your dilemma, but can't it be solved by paging in another ROM?
(S)He who pages in the ROM knows that software might need paging back the old ROM.
(S)He who pages in the ROM knows that software might need paging back the old ROM.
-
- Posts: 2169
- Joined: Sat Nov 26, 2016 2:42 am
Re: Balancing compatibility with innovation
Ah the joys of 'breaking changes' in APIs or in this case people who find sneaky ways past them!
It is entirely reason and necessary (in my opinion) not to prevent innovation due to issues like this. Obviously it will cause some discomfort from time to time but needs to be done.
Innovate away!
It is entirely reason and necessary (in my opinion) not to prevent innovation due to issues like this. Obviously it will cause some discomfort from time to time but needs to be done.
Innovate away!
ZX80
ZX81 iss 1 (bugged ROM, kludge fix, normal, rebuilt)
TS 1000 iss 3, ZXPand AY and +, ZX8-CCB, ZX-KDLX & ChromaSCART
Tatung 81 + Wespi
TS 1500 & 2000
Spectrum 16k (iss 1 s/n 862)
Spectrum 48ks plus a DIVMMC future and SPECTRA
ZX81 iss 1 (bugged ROM, kludge fix, normal, rebuilt)
TS 1000 iss 3, ZXPand AY and +, ZX8-CCB, ZX-KDLX & ChromaSCART
Tatung 81 + Wespi
TS 1500 & 2000
Spectrum 16k (iss 1 s/n 862)
Spectrum 48ks plus a DIVMMC future and SPECTRA
Re: Balancing compatibility with innovation
I am not too deep into ZXpand technology.
In general compatibility rules and it is always worth to try.
I remember that IBM did pointed out to use the BIOS interface rather than controlling hardware directly on base of io addresses.
By the way - maybe better to extend the thread title with "ZXpand(+)" to get more attention as it looks like a more general or theoretical question. Why not ask the programmers what they used in the past and what they can spare.
In general compatibility rules and it is always worth to try.
I remember that IBM did pointed out to use the BIOS interface rather than controlling hardware directly on base of io addresses.
By the way - maybe better to extend the thread title with "ZXpand(+)" to get more attention as it looks like a more general or theoretical question. Why not ask the programmers what they used in the past and what they can spare.
Re: Balancing compatibility with innovation
That is a good idea Karl, it is quite an obtuse title.
-
- Posts: 325
- Joined: Sat Sep 27, 2014 8:02 pm
- Location: Stockholm, Sweden
Re: Balancing compatibility with innovation .. ZXPand(+) programmers
Proper API calls are very nice to have if I code stuff that aren't on the bleeding edge of performance. When speed is of importance I never look back, banging the HW directly is the only way to go to get the last cycles of performance.
Since I release source to my ZX81 projects I don't feel bad about using either approach.
Since I release source to my ZX81 projects I don't feel bad about using either approach.
/Adam
Re: Balancing compatibility with innovation .. ZXPand(+) programmers
I broke a few things last night with one too many optimisations and it made my opinion a little clearer.
I've come to the conclusion that It's all in the balance. If I got a new board and nothing worked any more then I'd be disappointed. If a few key pieces such as ZXpand-Commander work out of the box then I'd be reassured.
Are there any other programs which are considered must-work-unmodified? I'm only thinking of those which rely heavily on ZXpand features.
* Dragon's Lair
* ???
I've come to the conclusion that It's all in the balance. If I got a new board and nothing worked any more then I'd be disappointed. If a few key pieces such as ZXpand-Commander work out of the box then I'd be reassured.
Are there any other programs which are considered must-work-unmodified? I'm only thinking of those which rely heavily on ZXpand features.
* Dragon's Lair
* ???
Re: Balancing compatibility with innovation .. ZXPand(+) programmers
For anyone wanting to explore the musical side of things I would say xpand dependant programs like the tracker-compiler and music players, turbosound etc which the xpand allows to use extensions other than ".P" should be usable from the off.
Re: Balancing compatibility with innovation .. ZXPand(+) programmers
We also have a slide show for ZXPand and the new version of powerbasic that was made for ZXPand compatibility.
In theory, there is no difference between theory and practice. But, in practice, there is.
Re: Balancing compatibility with innovation .. ZXPand(+) programmers
I've had a real good clean up of the ROM code. Saved a fair few bytes and as far as I can tell retained a very high degree of compatibility. Yaay!
For the new features I'm considering a new vector for opening/reading/writing 'streams'. Not only files on SD card but also directory listings, serial (and by extension midi), and perhaps (space allowing) AY.
In conjunction with the existing vectors I think most of the useful ZXpand features could be exposed to the programmer in a manner allowing for innovation whilst giving me space to fettle, as is my wont.
Is it good enough to expect people to use machine code (most do) or should I make a thing which would allow easier access to BASIC programmers? What kind of things do BASIC programmers want? Finding files on the card? Block loading/streaming? A monkey riding a goat?
Should I get off my fat lazy ars technica and write a document? Perhaps this might make the options a little clearer...
For the new features I'm considering a new vector for opening/reading/writing 'streams'. Not only files on SD card but also directory listings, serial (and by extension midi), and perhaps (space allowing) AY.
In conjunction with the existing vectors I think most of the useful ZXpand features could be exposed to the programmer in a manner allowing for innovation whilst giving me space to fettle, as is my wont.
Is it good enough to expect people to use machine code (most do) or should I make a thing which would allow easier access to BASIC programmers? What kind of things do BASIC programmers want? Finding files on the card? Block loading/streaming? A monkey riding a goat?
Should I get off my fat lazy ars technica and write a document? Perhaps this might make the options a little clearer...