Balancing compatibility with innovation .. ZXPand(+)

Any discussions related to the creation of new hardware or software for the ZX80 or ZX81
sirmorris
Posts: 2811
Joined: Thu May 08, 2008 5:45 pm

Balancing compatibility with innovation .. ZXPand(+)

Post by sirmorris »

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 :oops:

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
dr beep
Posts: 2076
Joined: Thu Jun 16, 2011 8:35 am
Location: Boxmeer

Re: Balancing compatibility with innovation

Post by dr beep »

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.
Lardo Boffin
Posts: 2169
Joined: Sat Nov 26, 2016 2:42 am

Re: Balancing compatibility with innovation

Post by Lardo Boffin »

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!
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
User avatar
PokeMon
Posts: 2264
Joined: Sat Sep 17, 2011 6:48 pm

Re: Balancing compatibility with innovation

Post by PokeMon »

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. ;)
sirmorris
Posts: 2811
Joined: Thu May 08, 2008 5:45 pm

Re: Balancing compatibility with innovation

Post by sirmorris »

That is a good idea Karl, it is quite an obtuse title.
nollkolltroll
Posts: 325
Joined: Sat Sep 27, 2014 8:02 pm
Location: Stockholm, Sweden

Re: Balancing compatibility with innovation .. ZXPand(+) programmers

Post by nollkolltroll »

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.
/Adam
sirmorris
Posts: 2811
Joined: Thu May 08, 2008 5:45 pm

Re: Balancing compatibility with innovation .. ZXPand(+) programmers

Post by sirmorris »

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
* ???
Moggy
Posts: 3266
Joined: Wed Jun 18, 2008 2:00 pm

Re: Balancing compatibility with innovation .. ZXPand(+) programmers

Post by Moggy »

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.
User avatar
Paul
Posts: 1517
Joined: Thu May 27, 2010 8:15 am
Location: Germanys west end

Re: Balancing compatibility with innovation .. ZXPand(+) programmers

Post by Paul »

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.
sirmorris
Posts: 2811
Joined: Thu May 08, 2008 5:45 pm

Re: Balancing compatibility with innovation .. ZXPand(+) programmers

Post by sirmorris »

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! 8-)

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...
Post Reply