I do not want people to have to continually rewrite their code once the software base starts growing.
Anyone writing software for the super ULA before the hardware actually exists and who doesn't expect there to be some changes is... naive. As this thread is showing, there isn't even a firm specification for the functionality yet.
While the stuff I'm working on won't be ready for a few weeks, I can't speak for other developers. If the spec keeps changing, some programmers will probably lose interest. Nobody wants to have to patch software after it has been released.
Personally, I don't care too much about palette switching timings, changing palettes will be a rare event anyway. I'm quite happy to go along with whatever is decided - odd or even ports, it's just a bit in the c register. Changing from 64 to 32 colours would be a bigger change (I'd prefer 64), but it's no big deal so long as a final decision is reached soon.
Anyone writing software for the super ULA before the hardware actually exists and who doesn't expect there to be some changes is... naive. As this thread is showing, there isn't even a firm specification for the functionality yet.
[strike]Well, the 64 colour mode will not change from the point of view of how the display is composed and the 256 colour palette will not change either. Everything else can change. Additional modes could be added though as currently only two of the available 64 modes have been assigned (normal mode and 64-colour mode).[/strike]
However, right now we have a standard that allows software developers to experiment with the mode. I see no benefit to changing the current implementation [strike]until hardware testing is complete. Then we can work towards a completely accurate emulation and software will only have to be changed once.[/strike]
Ok
First I agree with everyone ;-)
Secondly, sorry to everyone for not spotting that we'd missed A0 in the address decoding sooner!
Ports
To avoid the "solder a wire" problem, the new ports on the ULA+ should have A0 low as well. When you think about it, this is a good idea as A0 low means "ULA Port". However, additional lines can also be low to tell the ULA+ which port we're talking to. So FEh is the existing ULA port, 3Ah the new port.
Previously we found a port with a low byte address that clashed only with the ZXPrinter and it's lame address decoding, the upper byte was chosen around A14 and A15 as we have those address lines fed to the ULA raw. This gave us the two ULA+ ports required.
Unfortunately, this will clash with Spectranet.
Now, aowen, we have a choice - and you've done the research here. Changing the low byte address to be 3A instead of 3B introduces the A0 low. So, given that A0 is low, and therefore a ULA port, does that keep it out of the way of all other IO peripherals??? In which case, the address decoding can be much much simpler. the ULA+ IO gets activated on A0 being low, and the ULA+ then does a full decode of the low byte to find out which port: standard ULA IO, Register select or data.
EDIT: So do we need the high port address. Can we not have two low addresses with A0 low, say 3A and 7A ?
Contention
What started me posting today, was that I was trying to determine the contention timing for you all ;-)
I think we know what we all want. Access to the palette registers at each scan line. There will be so much data being passed back and forth, that I can only see this being allowed during the border. There isn't much time (see earlier post) to do this, but you can select a palette entry and repeatedly write to it - you might get to update it four times in the border of one scan line, but once would be enough. Or you might be able to update two palette entries per scanline. Update to the palette registers during a pixel update will contend until the right-hand border is hit.
What I'm still finalising is the border colour handling. If the border colours are as on the standard speccy, then no problem. No contention.
If the border colours come from the palette (assume CLUT 1 for now), then to avoid contention, changes to the border colour and palette must be kept apart. Therefore, changing the border colour with an out FEh will load the border colour from the palette and store it. Changing the palette entry for that colour will not affect the border colour until the next out FEh, which will cause a reload from the palette.
The second problem with the border colour is if it is changed during a pixel display update. It will want to load it's border colour from the palette, which will be squirting out ink and paper colours. Eeek! Contention.
Border Solution
I know what needs to be done. For every attribute byte loaded, get the palette entry for ink and paper and store in output registers. Every time the border colour is changed, get the palette entry and store in the border output register. As access to the border colour port is contended, and the ink and paper palette entries are fetched during the contended period, the border colour load won't collide with them.
This also infers that you might be able to update the palette during the pixel part of the scanline....
Everything has raced on ahead of me. Emulator take-up, software being written etc. Can we agree that any software that relies on a particular palette contention model and access timing (ie dynamic palette changing), that is written now, should expect to have to be modified when the timings are finally published?
It's a bit much to expect the timings soon, as there is a heck of a lot of development and research and prototyping to carry out. But that shouldn't matter just yet as this is still all in development.
Rest assured that the 64colour mode is implementable, but we need a clear description of what people want or expect, so we can provide the closest possible implementation to that without breaking standard ZX Spectrum timing.
Nobody wants to have to patch software after it has been released.
[strike]This is my main fear. I propose the following solution:
1) Assume there will be a change to the ports.
2) Use a fixed 64-colour palette. Do not change the palette in software.
3) Set the palette using the output from the palette editor. Then it can be updated in situ without having to recompile the software.
For example: Subacuatic uses a fixed palette. Since #xx3B is a safe port it can carry on writing to it, I'll just add a new palette to the start of the tap/tzx that replicates the original settings and the software will continue to work.[/strike]
However, right now we have a standard that allows software developers to experiment with the mode. I see no benefit to changing the current implementation until hardware testing is complete. Then we can work towards a completely accurate emulation and software will only have to be changed once.
Yes. Absolutely.
And don't spend hours creating wonderful colour effects via palette updates, as there will be contention to deal with in the real hardware.
Anyone writing software for the super ULA before the hardware actually exists and who doesn't expect there to be some changes is... naive. As this thread is showing, there isn't even a firm specification for the functionality yet.
while week ago it looked like it is fully specified.
words about naivity really does not help at all.
but back to topic, i really dont care if changes in CLUT appears on scan-line basis or on vertical blank. i would like to know
1) are ports going to be changed ? (low priority, CLUT will be setted on one place in code, with carefully designed code, its a matter of four pokes)
2) will be values written on port interpreted in different way ? (high priority)
3) will be interpretation of attribute byte changed ? (high priority)
4) is timing for muliticolors same like on old ULA (medium priority)
5) when changes in CLUT will be applied ? on vertical blank / on hz blank / just after out ? (very low priority)
points 1-3 probably covers about 80% software written in future
points 1-4 probably covers about 95% software written in futute
point 5) realy doesn't matter, while uncertainity on this point is a bit limiting, most effects can be done with classic multicolor or will work even with change on vertical blank. without interrupts raised on specified scan line it is like classic multicolor - too much inpractical to be used widely
[strike]Spectranet is still in development. Winston *can* change the ports it uses.
As far as I can tell #xx3A should be ok, but I don't know what it might do to hardware that's not on Philip's list. I picked #xx3B because everyone deliberately avoided it owing to the ZX Printer clash (which was resolvable). #xx3A still hits the printer as well as the ULA. It's probably safe but I don't know what a write to #xx3A would do on a machine with no ULAplus. We need hardware testing. [/strike]
[border colours]
I think the border colour needs to map to the paper colour (non-bright for the standard mode, bright for 512x192 mode). Various games set the border colour to match the paper and one of the main aims of the mode was backwards compatibility with games. Personally I don't care if you can't do palette cycling in the border -- you still have 8 colours to play with. Others may disagree.
Everything has raced on ahead of me.
I take full responsibility for that and apologize unreservedly.
Does this mean there is no record of what Speccy colour (0-7) the border is set to at any one time, only its actual output colour? I was wondering if the border could fetch its palettised colour on the raster fly-back even if you haven't done an OUT 254 lately. That way a change to the palette would automatically be reflected on the next line of the border, and apply right across. Or is this additional trouble to store the low-level border colour index?
I'm only asking because the uncontended border time is clearly precious, and if you're writing new attributes as part of a rainbow effect, having to stop in the middle to change the border colour on the flyback is a right pain. Having said that, it would be far worse to lose the ability to change the border colour multiple times per line.
Either way, being able to change at least one of the colours per row is good news.
while week ago it looked like it is fully specified
The port number seems to need to be changed, and there will be contention somewhere. That's all.
i would like to know
1) are ports going to be changed ? (low priority, CLUT will be setted on one place in code, with carefully designed code, its a matter of four pokes)
2) will be values written on port interpreted in different way ? (high priority)
3) will be interpretation of attribute byte changed ? (high priority)
4) is timing for muliticolors same like on old ULA (medium priority)
5) when changes in CLUT will be applied ? on vertical blank / on hz blank / just after out ? (very low priority)
1. Yes. probably.
2. No. This is the area where a lot of thought has been spent, including the register bit field designations. What hasn't be discussed at length is the border colour handling.
3. No. See 2.
4. Standard ULA timing will not change, as a fundamental principle. I've just spent 2 years discovering why the ULA timings are as they are, so I'm going to be true to the original. The idea that old games can be recoloured infers that new-palette handling must not change the timing. Palette updates however will be contended.
5. Changes in the CLUT will be applied after the register write. Might be at exactly that moment (contention excepted), or very shortly afterwards (buffering may be required.... we will see).
Edit: EXCEPT (I think) when you change the palette entry that the border is displaying. You will probably need to reset the border colour to see the change take effect.
point 5) realy doesn't matter, while uncertainity on this point is a bit limiting, most effects can be done with classic multicolor or will work even with change on vertical blank. without interrupts raised on specified scan line it is like classic multicolor - too much inpractical to be used widely
Choose your own scan-line interrupt register is possible? We'll see.....
1) are ports going to be changed ? (low priority, CLUT will be setted on one place in code, with carefully designed code, its a matter of four pokes)
No.
[strike]If the palette is set in only one place it should be done using the palette file format, then the palette editor can change the ports for you. Also it's only one POKE, as I only set the low byte once.[/strike]
2) will be values written on port interpreted in different way ? (high priority)
No.
[strike]I am completely against this. Much consideration was given to the current scheme and it has proved easy to use and efficient in code.[/strike]
3) will be interpretation of attribute byte changed ? (high priority)
No. The scheme is fixed. Additional schemes may be added, but no-one writing for this mode should worry about fundamental changes to the mode [strike]beyond the low-byte of the port address.[/strike]
4) is timing for muliticolors same like on old ULA (medium priority)
5) when changes in CLUT will be applied ? on vertical blank / on hz blank / just after out ? (very low priority)
Timing is uncertain until the hardware exists. Assume nothing until then.
Does this mean there is no record of what Speccy colour (0-7) the border is set to at any one time, only its actual output colour? I was wondering if the border could fetch its palettised colour on the raster fly-back even if you haven't done an OUT 254 lately. That way a change to the palette would automatically be reflected on the next line of the border, and apply right across. Or is this additional trouble to store the low-level border colour index?
I think that automatically loading the border colour register during the pixel display portion may be possible. I'd like to avoid reading the palette ram outside the pixel display area to avoid contention with you wonderful chaps who are writing to the palette ram as you go...... cake, eating and all that ;-)
I'm only asking because the uncontended border time is clearly precious, and if you're writing new attributes as part of a rainbow effect, having to stop in the middle to change the border colour on the flyback is a right pain. Having said that, it would be far worse to lose the ability to change the border colour multiple times per line.
Either way, being able to change at least one of the colours per row is good news.
It's got to do what people want it to do (within technical reasonability).
The border issue needs experimentation, because we want to avoid contention with the palette updates. Loading a new colour when an out feh is issued should work, though the timing will be slightly different to a normal ULA in terms of when the border colour changes. Automatically changing the border colour when the palette changes is tricky if we want to avoid contention. Doing so when the CPU is contended anyway (pixel display update) seems the safest.
I need to try all this and see what works with the minimum impact.
I'll have to get back to you all.
if soldering a flying lead to the z80 is an issue, just put one of these:
on the end of the lead, it's just a clip that can clip onto an IC leg
I can think of a number of reasons not to use an even port. If Guesser's solution will work (i.e. if it is impossible to damage any of the hardware by connecting the flying lead to the wrong pin, and latency isn't an issue) then I think that is the best solution (with no change to the existing specification).
I think that automatically loading the border colour register during the pixel display portion may be possible. I'd like to avoid reading the palette ram outside the pixel display area to avoid contention with you wonderful chaps who are writing to the palette ram as you go...... cake, eating and all that ;-)
Understood.
The thing I'm getting at is that if you change the border colour once per line, you probably want the right-hand half and the left-hand half to line up. From experience, the only way to do that is to change the colour during the horizontal raster fly-back. If you change it during the pixel phase, you end up with the colour split in the right border higher than the left border.
If there's no automatic way to do it on the first flyback following a palette change (without impeding other data flow), then I might as well time it myself and call OUT 254 at the right moment. I can't see a way that automatically updating the border colour during the pixel phase would help much.
if the MSB is 0x10xx xxxx it collides with the Spectranet - not that the Spectranet cares, but it means every time it changes memory pages the pallette will change!)
OK, I'm confused. I thought (and the databaseentries say the same thing) that the Spectranet is fully decoded, and will respond only to ports 0x80ed and 0x80ef (33005 and 33007 - can't make Freebase display in hex as far as I know...)
So why do we think the new ULA using ports 0xbf3a and 0xff3a (or even 0x??3b) will clash?
The thing I'm getting at is that if you change the border colour once per line, you probably want the right-hand half and the left-hand half to line up. From experience, the only way to do that is to change the colour during the horizontal raster fly-back. If you change it during the pixel phase, you end up with the colour split in the right border higher than the left border.
If there's no automatic way to do it on the first flyback following a palette change (without impeding other data flow), then I might as well time it myself and call OUT 254 at the right moment. I can't see a way that automatically updating the border colour during the pixel phase would help much.
I know exactly what you're talking about.
It's the conflict between changing the palette and changing the border colour again. Old software will be ok, because they just out FEh when needed. For us who want to change the palette entry and change the border colour, the worse case scenario will be having to do 2 OUT's.
The requirement is in this thread, so I'll see what we/I can do.
I thought (and the databaseentries say the same thing) that the Spectranet is fully decoded, and will respond only to ports 0x80ed and 0x80ef (33005 and 33007 - can't make Freebase display in hex as far as I know...)
Indeed. That's what Winston implied in this thread. :-)
Reading through the thread, it appears to me that the biggest reason the 64 colour mode implementation is currently held up is possibility of pallette changes in border per-scanline and its affect on contention. My question then is, do we really need this? Are the rewards worth the investment? There is a *lot* we can do with just the paper-ink combo and 64 colours that this new mode provides us, so we maybe just over-reaching here. Just my 2 cents.
Indeed. That's what Winston implied in this thread. :-)
Reading through the thread, it appears to me that the biggest reason the 64 colour mode implementation is currently held up is possibility of pallette changes in border per-scanline and its affect on contention. My question then is, do we really need this? Are the rewards worth the investment? There is a *lot* we can do with just the paper-ink combo and 64 colours that this new mode provides us, so we maybe just over-reaching here. Just my 2 cents.
Which is where I started from in this thread.
Knowing the things people would like to do, helps sort out the behaviour and timing requirements. Some may not be possible, as we want to remain compatible with the Spectrum timing.
But if built from the requirements of people who are writing software for the Spectrum, the new ULA will be used and bought by people, so the effort is worth it, if you see what I mean.
Good 2 cents though, reminds people to keep it real. :grin:
Spectranet is still in development. Winston *can* change the ports it uses.
As far as I can tell #xx3A should be ok.
Any port with A0 = low should be OK, because every other peripheral in the world avoids ports with A0 = 0 because the ULA decodes them. (Well, there may be a few unusual exceptions. The Spectranet does listen to A0 = 0, but only to monitor border colour changes).
The problem with decoding just A15/A14 with A0 = 1 is not so much other peripherals will end up listening to that, but I/O instructions for other peripherals will end up changing the palette. For example, the Spectranet does a complete 16 bit port decode, so when you change the palette, it won't do anything to the Spectranet. But when the Spectranet changes its memory pages (which it does with practically every call) it'll end up also changing the palette. This may be an issue with other things, too.
It's a thorny problem, for sure.
Another approach to take is somewhat like flash memory uses - a sequence of I/O operations, so that the palette doesn't get inadvertently changed, although that may be overkill :-)
(Incidentally, I wouldn't suggest any potential emulator writer from emulating the Spectranet CPLD just yet either, it's still in a state of flux, and I may end up using the XC95144 in the final item with a whole raft of extra stuff)
But if built from the requirements of people who are writing software for the Spectrum, the new ULA will be used and bought by people, so the effort is worth it, if you see what I mean.
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! ;)
So why do we think the new ULA using ports 0xbf3a and 0xff3a (or even 0x??3b) will clash?
No, I was confused, an out-of-caffiene-error, I fear. (In any case my thought pattern was not that it'd make the Spectranet do something unusual, but that the Spectranet would make the ULA+ do something unusual).
In any case, what I'd love to be able to do is show video over the network with the ULA+ at next June's Vintage Computer Festival :-) And RetroEuskal too!
CSmith and I have conferred. The ports are not changing. Do not adjust your emulator. You are being returned to your normal 64-colour program. The ULA replacement will not require any soldering. The only thing that we can't tell you yet is exactly how the timing and border will function. That will become clear over time.
Yeah, we agree given current info. But need to remain flexible, because there is a chance of back-tracking:
Some thoughts:
A flying lead for /IORQ would mean implementing a second contention model for the new ula io ports. Not necessary if we use the existing port enable with A0 low. Also the last time I had flying leads off a CPLD chip, it became unstable.
Let's stay where we are and see where the hardware needs to go. We can't completely rule out a necessary future port change, cos we just don't know.
Comments
Anyone writing software for the super ULA before the hardware actually exists and who doesn't expect there to be some changes is... naive. As this thread is showing, there isn't even a firm specification for the functionality yet.
While the stuff I'm working on won't be ready for a few weeks, I can't speak for other developers. If the spec keeps changing, some programmers will probably lose interest. Nobody wants to have to patch software after it has been released.
Personally, I don't care too much about palette switching timings, changing palettes will be a rare event anyway. I'm quite happy to go along with whatever is decided - odd or even ports, it's just a bit in the c register. Changing from 64 to 32 colours would be a bigger change (I'd prefer 64), but it's no big deal so long as a final decision is reached soon.
Egghead Website
Arcade Game Designer
My itch.io page
[strike]Well, the 64 colour mode will not change from the point of view of how the display is composed and the 256 colour palette will not change either. Everything else can change. Additional modes could be added though as currently only two of the available 64 modes have been assigned (normal mode and 64-colour mode).[/strike]
However, right now we have a standard that allows software developers to experiment with the mode. I see no benefit to changing the current implementation [strike]until hardware testing is complete. Then we can work towards a completely accurate emulation and software will only have to be changed once.[/strike]
First I agree with everyone ;-)
Secondly, sorry to everyone for not spotting that we'd missed A0 in the address decoding sooner!
Ports
To avoid the "solder a wire" problem, the new ports on the ULA+ should have A0 low as well. When you think about it, this is a good idea as A0 low means "ULA Port". However, additional lines can also be low to tell the ULA+ which port we're talking to. So FEh is the existing ULA port, 3Ah the new port.
Previously we found a port with a low byte address that clashed only with the ZXPrinter and it's lame address decoding, the upper byte was chosen around A14 and A15 as we have those address lines fed to the ULA raw. This gave us the two ULA+ ports required.
Unfortunately, this will clash with Spectranet.
Now, aowen, we have a choice - and you've done the research here. Changing the low byte address to be 3A instead of 3B introduces the A0 low. So, given that A0 is low, and therefore a ULA port, does that keep it out of the way of all other IO peripherals??? In which case, the address decoding can be much much simpler. the ULA+ IO gets activated on A0 being low, and the ULA+ then does a full decode of the low byte to find out which port: standard ULA IO, Register select or data.
EDIT: So do we need the high port address. Can we not have two low addresses with A0 low, say 3A and 7A ?
Contention
What started me posting today, was that I was trying to determine the contention timing for you all ;-)
I think we know what we all want. Access to the palette registers at each scan line. There will be so much data being passed back and forth, that I can only see this being allowed during the border. There isn't much time (see earlier post) to do this, but you can select a palette entry and repeatedly write to it - you might get to update it four times in the border of one scan line, but once would be enough. Or you might be able to update two palette entries per scanline. Update to the palette registers during a pixel update will contend until the right-hand border is hit.
What I'm still finalising is the border colour handling. If the border colours are as on the standard speccy, then no problem. No contention.
If the border colours come from the palette (assume CLUT 1 for now), then to avoid contention, changes to the border colour and palette must be kept apart. Therefore, changing the border colour with an out FEh will load the border colour from the palette and store it. Changing the palette entry for that colour will not affect the border colour until the next out FEh, which will cause a reload from the palette.
The second problem with the border colour is if it is changed during a pixel display update. It will want to load it's border colour from the palette, which will be squirting out ink and paper colours. Eeek! Contention.
Border Solution
I know what needs to be done. For every attribute byte loaded, get the palette entry for ink and paper and store in output registers. Every time the border colour is changed, get the palette entry and store in the border output register. As access to the border colour port is contended, and the ink and paper palette entries are fetched during the contended period, the border colour load won't collide with them.
This also infers that you might be able to update the palette during the pixel part of the scanline....
Everything has raced on ahead of me. Emulator take-up, software being written etc. Can we agree that any software that relies on a particular palette contention model and access timing (ie dynamic palette changing), that is written now, should expect to have to be modified when the timings are finally published?
It's a bit much to expect the timings soon, as there is a heck of a lot of development and research and prototyping to carry out. But that shouldn't matter just yet as this is still all in development.
Rest assured that the 64colour mode is implementable, but we need a clear description of what people want or expect, so we can provide the closest possible implementation to that without breaking standard ZX Spectrum timing.
Fun, init? :grin:
[strike]This is my main fear. I propose the following solution:
1) Assume there will be a change to the ports.
2) Use a fixed 64-colour palette. Do not change the palette in software.
3) Set the palette using the output from the palette editor. Then it can be updated in situ without having to recompile the software.
For example: Subacuatic uses a fixed palette. Since #xx3B is a safe port it can carry on writing to it, I'll just add a new palette to the start of the tap/tzx that replicates the original settings and the software will continue to work.[/strike]
Yes. Absolutely.
And don't spend hours creating wonderful colour effects via palette updates, as there will be contention to deal with in the real hardware.
words about naivity really does not help at all.
but back to topic, i really dont care if changes in CLUT appears on scan-line basis or on vertical blank. i would like to know
1) are ports going to be changed ? (low priority, CLUT will be setted on one place in code, with carefully designed code, its a matter of four pokes)
2) will be values written on port interpreted in different way ? (high priority)
3) will be interpretation of attribute byte changed ? (high priority)
4) is timing for muliticolors same like on old ULA (medium priority)
5) when changes in CLUT will be applied ? on vertical blank / on hz blank / just after out ? (very low priority)
points 1-3 probably covers about 80% software written in future
points 1-4 probably covers about 95% software written in futute
point 5) realy doesn't matter, while uncertainity on this point is a bit limiting, most effects can be done with classic multicolor or will work even with change on vertical blank. without interrupts raised on specified scan line it is like classic multicolor - too much inpractical to be used widely
[strike]Spectranet is still in development. Winston *can* change the ports it uses.
As far as I can tell #xx3A should be ok, but I don't know what it might do to hardware that's not on Philip's list. I picked #xx3B because everyone deliberately avoided it owing to the ZX Printer clash (which was resolvable). #xx3A still hits the printer as well as the ULA. It's probably safe but I don't know what a write to #xx3A would do on a machine with no ULAplus. We need hardware testing. [/strike]
[border colours]
I think the border colour needs to map to the paper colour (non-bright for the standard mode, bright for 512x192 mode). Various games set the border colour to match the paper and one of the main aims of the mode was backwards compatibility with games. Personally I don't care if you can't do palette cycling in the border -- you still have 8 colours to play with. Others may disagree.
I take full responsibility for that and apologize unreservedly.
I'm only asking because the uncontended border time is clearly precious, and if you're writing new attributes as part of a rainbow effect, having to stop in the middle to change the border colour on the flyback is a right pain. Having said that, it would be far worse to lose the ability to change the border colour multiple times per line.
Either way, being able to change at least one of the colours per row is good news.
- IONIAN-GAMES.com -
on the end of the lead, it's just a clip that can clip onto an IC leg
1. Yes. probably.
2. No. This is the area where a lot of thought has been spent, including the register bit field designations. What hasn't be discussed at length is the border colour handling.
3. No. See 2.
4. Standard ULA timing will not change, as a fundamental principle. I've just spent 2 years discovering why the ULA timings are as they are, so I'm going to be true to the original. The idea that old games can be recoloured infers that new-palette handling must not change the timing. Palette updates however will be contended.
5. Changes in the CLUT will be applied after the register write. Might be at exactly that moment (contention excepted), or very shortly afterwards (buffering may be required.... we will see).
Edit: EXCEPT (I think) when you change the palette entry that the border is displaying. You will probably need to reset the border colour to see the change take effect.
Choose your own scan-line interrupt register is possible? We'll see.....
No.
[strike]If the palette is set in only one place it should be done using the palette file format, then the palette editor can change the ports for you. Also it's only one POKE, as I only set the low byte once.[/strike]
No.
[strike]I am completely against this. Much consideration was given to the current scheme and it has proved easy to use and efficient in code.[/strike]
No. The scheme is fixed. Additional schemes may be added, but no-one writing for this mode should worry about fundamental changes to the mode [strike]beyond the low-byte of the port address.[/strike]
Timing is uncertain until the hardware exists. Assume nothing until then.
I think that automatically loading the border colour register during the pixel display portion may be possible. I'd like to avoid reading the palette ram outside the pixel display area to avoid contention with you wonderful chaps who are writing to the palette ram as you go...... cake, eating and all that ;-)
It's got to do what people want it to do (within technical reasonability).
The border issue needs experimentation, because we want to avoid contention with the palette updates. Loading a new colour when an out feh is issued should work, though the timing will be slightly different to a normal ULA in terms of when the border colour changes. Automatically changing the border colour when the palette changes is tricky if we want to avoid contention. Doing so when the CPU is contended anyway (pixel display update) seems the safest.
I need to try all this and see what works with the minimum impact.
I'll have to get back to you all.
- IONIAN-GAMES.com -
I can think of a number of reasons not to use an even port. If Guesser's solution will work (i.e. if it is impossible to damage any of the hardware by connecting the flying lead to the wrong pin, and latency isn't an issue) then I think that is the best solution (with no change to the existing specification).
The thing I'm getting at is that if you change the border colour once per line, you probably want the right-hand half and the left-hand half to line up. From experience, the only way to do that is to change the colour during the horizontal raster fly-back. If you change it during the pixel phase, you end up with the colour split in the right border higher than the left border.
If there's no automatic way to do it on the first flyback following a palette change (without impeding other data flow), then I might as well time it myself and call OUT 254 at the right moment. I can't see a way that automatically updating the border colour during the pixel phase would help much.
- IONIAN-GAMES.com -
OK, I'm confused. I thought (and the database entries say the same thing) that the Spectranet is fully decoded, and will respond only to ports 0x80ed and 0x80ef (33005 and 33007 - can't make Freebase display in hex as far as I know...)
So why do we think the new ULA using ports 0xbf3a and 0xff3a (or even 0x??3b) will clash?
I know exactly what you're talking about.
It's the conflict between changing the palette and changing the border colour again. Old software will be ok, because they just out FEh when needed. For us who want to change the palette entry and change the border colour, the worse case scenario will be having to do 2 OUT's.
The requirement is in this thread, so I'll see what we/I can do.
Cheers Joefish.
Indeed. That's what Winston implied in this thread. :-)
Reading through the thread, it appears to me that the biggest reason the 64 colour mode implementation is currently held up is possibility of pallette changes in border per-scanline and its affect on contention. My question then is, do we really need this? Are the rewards worth the investment? There is a *lot* we can do with just the paper-ink combo and 64 colours that this new mode provides us, so we maybe just over-reaching here. Just my 2 cents.
Bytes:Chuntey - Spectrum tech blog.
Which is where I started from in this thread.
Knowing the things people would like to do, helps sort out the behaviour and timing requirements. Some may not be possible, as we want to remain compatible with the Spectrum timing.
But if built from the requirements of people who are writing software for the Spectrum, the new ULA will be used and bought by people, so the effort is worth it, if you see what I mean.
Good 2 cents though, reminds people to keep it real. :grin:
Any port with A0 = low should be OK, because every other peripheral in the world avoids ports with A0 = 0 because the ULA decodes them. (Well, there may be a few unusual exceptions. The Spectranet does listen to A0 = 0, but only to monitor border colour changes).
The problem with decoding just A15/A14 with A0 = 1 is not so much other peripherals will end up listening to that, but I/O instructions for other peripherals will end up changing the palette. For example, the Spectranet does a complete 16 bit port decode, so when you change the palette, it won't do anything to the Spectranet. But when the Spectranet changes its memory pages (which it does with practically every call) it'll end up also changing the palette. This may be an issue with other things, too.
It's a thorny problem, for sure.
Another approach to take is somewhat like flash memory uses - a sequence of I/O operations, so that the palette doesn't get inadvertently changed, although that may be overkill :-)
(Incidentally, I wouldn't suggest any potential emulator writer from emulating the Spectranet CPLD just yet either, it's still in a state of flux, and I may end up using the XC95144 in the final item with a whole raft of extra stuff)
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! ;)
Bytes:Chuntey - Spectrum tech blog.
No, I was confused, an out-of-caffiene-error, I fear. (In any case my thought pattern was not that it'd make the Spectranet do something unusual, but that the Spectranet would make the ULA+ do something unusual).
In any case, what I'd love to be able to do is show video over the network with the ULA+ at next June's Vintage Computer Festival :-) And RetroEuskal too!
Good... Gold-plating and feature creep would kill this before it started.
Andrew
Some thoughts:
A flying lead for /IORQ would mean implementing a second contention model for the new ula io ports. Not necessary if we use the existing port enable with A0 low. Also the last time I had flying leads off a CPLD chip, it became unstable.
Let's stay where we are and see where the hardware needs to go. We can't completely rule out a necessary future port change, cos we just don't know.
(exit stage left)
:-)