Good... Gold-plating and feature creep would kill this before it started.
Andrew
absolutely.
Which is why aowen and I are nervously discussing this.
As the hardware chap, I'm also concious that it needs to work as a physical device, so I'm cautious.
Bottom line: we're only discussing the merits or pitfalls of a port number change at this early stage of development, and contention timing. Everything else about the design is gold-plated and very well thought out.
Just wanted to make that point again, as a lot has been discussed in this thread.
Everything else about the design is gold-plated and very well thought out.
"Gold-plated" as in the software dev term meaning 'everything but the kitchen sink' design that never quite finishes.
I'm looking forward to this device. I'd really hate it to get stalled due to a never-ending process of adding new features... "Super-ULA" -> "Mega-ULA" -> "Ultra-ULA" -> "Vapour-ULA"...
(Sorry, but this is - to me - the most exciting Spectrum development of the last few years.)
"Gold-plated" as in the software dev term meaning 'everything but the kitchen sink' design that never quite finishes.
CSmith meant well defined.
I'm looking forward to this device. I'd really hate it to get stalled due to a never-ending process of adding new features... "Super-ULA" -> "Mega-ULA" -> "Ultra-ULA" -> "Vapour-ULA".
Allow me to reassure you: this is not a committee. The original design spec which this mode evolved from is almost 10 years old now and has gone through a series of refinements. Chris now has the onerous task of implementing it in hardware. Other modes are of course possible, but they won't be implemented unless there is a good reason to do so.
(Sorry, but this is - to me - the most exciting Spectrum development of the last few years.)
I understand how you feel and from the response so far it's clear that many people share your enthusiasm. Rest assured, Chris and I are determined to get this right.
I have my fingers crossed for you both. Increasing the colour pallete and still having colour clash to me feels like the natural 'evolution' and something like this should have been included in the 128k when it came out.
I'm positively salivating (as I'm sure many others are) at the prospect of having actual hardware in my sweaty palms!!
I feel like a kid again back in 82 all excited at christmas waiting for my first Speccy!
Fair enough. But then, I don't really see too many software developers, apart from joefish (who will probably 'wow' us with something anyway - border or not!), actually clamouring for this feature. Unless guys like jonathan, bobs, robpearmain, na_th_an , et al (and who knows, even frobush!) actually join their voices with joefish, I have to say the request of the requirement is in the minority to all intents and purposes! ;)
In my defence, I would consider those posting here as a sample of all the prospective users rather than the entire crowd. There are other demo coders who could use and abuse this in more ways than we have imagined.
What I like about changing the palette per row (or at least one colour of the palette per row) is that it can have an effect right across the screen, 256 pixels wide or even border to border, which you can't do by re-writing attributes as there's not enough time to do them all. Even if that's all you can manage to do per row, it's still a great effect. You can do things that make it look as if there is no border. Does it benefit games? Is it something that will degrade gracefully on an ordinary Spectrum? Do we care at this point?
While this is still fluid, I'd like to help (if I can) to make sense of the possibilities. Once it's finished, or any of it is found to be impossible or detrimental to the main operation, then I guess the discussion is over and we get what we're given.
While this is still fluid, I'd like to help (if I can) to make sense of the possibilities. Once it's finished, or any of it is found to be impossible or detrimental to the main operation, then I guess the discussion is over and we get what we're given.
Thanks.
I will probably call on you for some test code then to save me dividing my brain in two between hardware and software ;-)
Full width effects and all that....
In my defence, I would consider those posting here as a sample of all the prospective users rather than the entire crowd. There are other demo coders who could use and abuse this in more ways than we have imagined.
I think that's my cue :-) I have to agree that per-scanline palette changes would greatly increase the demoscenish appeal regarding doing unexpected creative things with it - but on the other hand, having a discussion now about which unexpected emergent features we want the hardware to have is defeating the object a bit... IMHO it's far better, and more in the spirit of Sinclair hardware, to do the simplest most elegant thing that works and let the software people figure out the implications of that. (But, just to be clear, I'm not personally committing to doing anything with this just yet...)
Also, definitely don't be shy about making changes to the spec at this stage. It's a natural consequence of having an open development model, and an open development model is absolutely the right thing here. Anyone developing software for this right now needs to be aware that it's in a beta phase, and is liable to change - if they don't agree with that, they can wait until it gets an official '1.0' release. (I'm thinking of the Django web framework here, which spent several years - and much of its rise in popularity - in 0.x releases, during which time they didn't commit to a stable API.) Sure, it does take the edge off the marketing buzz if there's no grand "everyone in the world can start using this" launch event, but that's far outweighed by having a process that ensures we end up with the best possible product.
...having a discussion now about which unexpected emergent features we want the hardware to have is defeating the object a bit... IMHO it's far better, and more in the spirit of Sinclair hardware, to do the simplest most elegant thing that works and let the software people figure out the implications of that.
I see your point - I suppose the border control is very much in that vein. If you can change the palette, but have to do OUT 254 to get the border to notice, then the developer can choose when (if ever) to flush the change into the border, or just keep that palette change for the attributes. Automatically flushing it means more work for CSmith and wouldn't allow for that choice. Similarly, if there are timing issues with changing the palette whilst the screen is being drawn, then we wouldn't want those issues hidden by automatic VBL or HBL synchronisation - we'd just have to learn and work with the contention and timing, and just trust that any delays can be minimised by the design. I suppose the point then is to keep things open-ended rather than to lock anything down.
Also, definitely don't be shy about making changes to the spec at this stage. It's a natural consequence of having an open development model, and an open development model is absolutely the right thing here.
It's not an open development model though. Some things are already set in stone, and CSmith is the final arbiter of what does and doesn't go in. On the other hand a community contribution to refining the bits that are not set in stone is most welcome.
I would like to state again that developers should feel confident about writing software now, providing it doesn't use palette cycling or border effects. If it becomes absolutely necessary to change the I/O ports due to some unforeseen problem with the physical hardware it will almost certainly be only the low-byte of the port address that changes. If you are developing software now and you want future-proof it then code for this eventuality.
It's not an open development model though. Some things are already set in stone, and CSmith is the final arbiter of what does and doesn't go in.
That leads to an interesting question: when the design is completed, is the source for the new ULA going to be freely available and if so under what licence?
Not as I understand it, which is that if you write to the palette registers when you're not in vsync, it contends the Z80 until the vsync happens.
How long does that give you to write a whole set of palette changes though? Is it enough? A quick skim of the faq suggests vsync is at most 16 scanlines and some back-of-a-fag-packet maths seems to suggest that's potentially a bit tight. Taking multiple frames to redefine the palette would severely limit its usefulness in the long run.
I completely agree that the hardware design has to be the driving factor. If it can't be done in hardware (or can't within a reasonable cost) then the design has to change and anyone developing right now has to live with that. Not that anyone wants the design to change, unless absolutely necessary.
That leads to an interesting question: when the design is completed, is the source for the new ULA going to be freely available and if so under what licence?
CSmith is best placed to answer this. However, I know it is his intention to give the community the ability to build their own replacement ULAs without having to rely on him as the sole supplier. I suspect the 'source' will be distributed under the hardware equivalent of the GPL. From my point of view the soft specification of ULAplus will always remain open. All the text I've written on the wiki and the ULAplus site is covered by a CC license.
On the other hand, if a company is going to invest in bringing the Harlequin SE to market then I would expect them to go for patent protection on elements of the implementation. But it's far too early to speculate.
Just a small update. The screen converter is now at version 0.5 for Linux and Windows and there's a slide show maker for Windows. I've uploaded a few more slide shows to demonstrate the mode and there's one more on the way. The mode seems particularly well suited to converting art rather than photo-real images.
Here's the link again, in case you've been living in a cave:
Palette cycling is possible -- you can get all 256 colours on screen at once. However doing a flip-screen display would depend on knowing the precise timings, and we won't know those until the hardware is completed.
I was just interested, I'm guessing some fan with a lot of times on his/her hands will attempt it someday.
sure, someone will try. but i would say that this time it is not worth to do it.
moving from fixed 8 colors to unstable fixed 36 (or so) could be seen as good deal but moving from custom 64 colors to unstable semicustom 2K colors is not so much exciting.
LCD, if you're following this topic, please let us know if the AVI conversion tool could include a ula+ mode.
I've just been experimenting with full motion video* and it looks not bad actually. if someone can find a nice colourful and contrasty source (SHORT!) video clip for me I'll put a demo together
*the traditional "flashload a tap crammed full of screens" format
Comments
...because as Philip has pointed out, the hardware is still in development. However, we will endeavour not to change the ports, right Chris?
Which is why aowen and I are nervously discussing this.
As the hardware chap, I'm also concious that it needs to work as a physical device, so I'm cautious.
Bottom line: we're only discussing the merits or pitfalls of a port number change at this early stage of development, and contention timing. Everything else about the design is gold-plated and very well thought out.
Just wanted to make that point again, as a lot has been discussed in this thread.
Absolutely. Just trying to lay it out for everyone, to manage expectations, so no one gets caught out.
"Gold-plated" as in the software dev term meaning 'everything but the kitchen sink' design that never quite finishes.
I'm looking forward to this device. I'd really hate it to get stalled due to a never-ending process of adding new features... "Super-ULA" -> "Mega-ULA" -> "Ultra-ULA" -> "Vapour-ULA"...
(Sorry, but this is - to me - the most exciting Spectrum development of the last few years.)
Andrew
CSmith meant well defined.
Allow me to reassure you: this is not a committee. The original design spec which this mode evolved from is almost 10 years old now and has gone through a series of refinements. Chris now has the onerous task of implementing it in hardware. Other modes are of course possible, but they won't be implemented unless there is a good reason to do so.
I understand how you feel and from the response so far it's clear that many people share your enthusiasm. Rest assured, Chris and I are determined to get this right.
I'm positively salivating (as I'm sure many others are) at the prospect of having actual hardware in my sweaty palms!!
I feel like a kid again back in 82 all excited at christmas waiting for my first Speccy!
What I like about changing the palette per row (or at least one colour of the palette per row) is that it can have an effect right across the screen, 256 pixels wide or even border to border, which you can't do by re-writing attributes as there's not enough time to do them all. Even if that's all you can manage to do per row, it's still a great effect. You can do things that make it look as if there is no border. Does it benefit games? Is it something that will degrade gracefully on an ordinary Spectrum? Do we care at this point?
While this is still fluid, I'd like to help (if I can) to make sense of the possibilities. Once it's finished, or any of it is found to be impossible or detrimental to the main operation, then I guess the discussion is over and we get what we're given.
- IONIAN-GAMES.com -
(not sure what it means)
2) Can't locate a version of Spin that supports this. The link from earlier on in this Thread is already 404ing on me.
Colour Look-Up Table.
http://sites.google.com/site/ulaplus/
Emulators are in the left menu. I try to keep the links updated with the latest release.
Ta very nicely!
I will probably call on you for some test code then to save me dividing my brain in two between hardware and software ;-)
Full width effects and all that....
I think that's my cue :-) I have to agree that per-scanline palette changes would greatly increase the demoscenish appeal regarding doing unexpected creative things with it - but on the other hand, having a discussion now about which unexpected emergent features we want the hardware to have is defeating the object a bit... IMHO it's far better, and more in the spirit of Sinclair hardware, to do the simplest most elegant thing that works and let the software people figure out the implications of that. (But, just to be clear, I'm not personally committing to doing anything with this just yet...)
Also, definitely don't be shy about making changes to the spec at this stage. It's a natural consequence of having an open development model, and an open development model is absolutely the right thing here. Anyone developing software for this right now needs to be aware that it's in a beta phase, and is liable to change - if they don't agree with that, they can wait until it gets an official '1.0' release. (I'm thinking of the Django web framework here, which spent several years - and much of its rise in popularity - in 0.x releases, during which time they didn't commit to a stable API.) Sure, it does take the edge off the marketing buzz if there's no grand "everyone in the world can start using this" launch event, but that's far outweighed by having a process that ensures we end up with the best possible product.
- IONIAN-GAMES.com -
It's not an open development model though. Some things are already set in stone, and CSmith is the final arbiter of what does and doesn't go in. On the other hand a community contribution to refining the bits that are not set in stone is most welcome.
I would like to state again that developers should feel confident about writing software now, providing it doesn't use palette cycling or border effects. If it becomes absolutely necessary to change the I/O ports due to some unforeseen problem with the physical hardware it will almost certainly be only the low-byte of the port address that changes. If you are developing software now and you want future-proof it then code for this eventuality.
That leads to an interesting question: when the design is completed, is the source for the new ULA going to be freely available and if so under what licence?
How long does that give you to write a whole set of palette changes though? Is it enough? A quick skim of the faq suggests vsync is at most 16 scanlines and some back-of-a-fag-packet maths seems to suggest that's potentially a bit tight. Taking multiple frames to redefine the palette would severely limit its usefulness in the long run.
I completely agree that the hardware design has to be the driving factor. If it can't be done in hardware (or can't within a reasonable cost) then the design has to change and anyone developing right now has to live with that. Not that anyone wants the design to change, unless absolutely necessary.
CSmith is best placed to answer this. However, I know it is his intention to give the community the ability to build their own replacement ULAs without having to rely on him as the sole supplier. I suspect the 'source' will be distributed under the hardware equivalent of the GPL. From my point of view the soft specification of ULAplus will always remain open. All the text I've written on the wiki and the ULAplus site is covered by a CC license.
On the other hand, if a company is going to invest in bringing the Harlequin SE to market then I would expect them to go for patent protection on elements of the implementation. But it's far too early to speculate.
http://alistairtesting.no-ip.org/ulaplus/scrplus%20BETA.zip
read the readme file carefully and remember that it's still not perfect.
it's built from AY's version 0.4 code, I'll get one ported from the latest code soonish...
Here's the link again, in case you've been living in a cave:
http://sites.google.com/site/ulaplus/
Tried to do ones of the wife, they came out not very good, the blocks change the shape of her eyes.
I know its not ready for the 128k yet but imagine using different palletes on each of the two screens, is that possible?
- IONIAN-GAMES.com -
moving from fixed 8 colors to unstable fixed 36 (or so) could be seen as good deal but moving from custom 64 colors to unstable semicustom 2K colors is not so much exciting.
I've just been experimenting with full motion video* and it looks not bad actually. if someone can find a nice colourful and contrasty source (SHORT!) video clip for me I'll put a demo together
*the traditional "flashload a tap crammed full of screens" format
http://pc.sux.org/tomcat/Why2.tap
original: http://noname.c64.org/csdb/release/index.php?id=84456
TC