So, you want to be able to reload 64 colours onto the ULA palette for every screen line? What are you going to use that for, when you can only have 32 different attributes on any one line? And how do you expect the Speccy to be able to operate that fast when even using the fastest multicolour routine around, it can only manage to reload 16 bytes of attribute data per line?
For the existing management system is not possible. This management system is not effective. Using other management system will be able to load the palette in 16 calls to the I/O ports. At present, it is possible for 48 calls to the I/O ports.
I think I see the aim: 256 colour HAM pictures on the Speccy. The thing is, even in 8x1 attribute mode, there's really not a lot of difference between 64 and 256 colours. Most pictures aren't going to use all 256 colours anyway as it's a fixed palette. And if you're using a bog standard speccy you can only do 8x1 across about half the width of the screen anyway.
For the existing management system is not possible. This management system is not effective. Using other management system will be able to load the palette in 16 calls to the I/O ports. At present, it is possible for 48 calls to the I/O ports.
I don't know where you get 48 from. To set a colour takes two OUTs; one to select the colour to update, one to set it. As JoeFish has pointed out, since you have 32 attributes per line you only need to update the palette every two scanlines to change the whole palette on every line. I don't know if it's possible to do 128 OUTs in two scanlines while POPing data off the stack or not, but if it isn't then that's too bad because the I/O method you've proposed breaks all existing software.
This snippet from the slide show tool shows a method of updating the palette. I'm sure there are faster methods:
set_palette:
ld hl, image+6912 ; HL = address of registers
ld c, 0x3b ; set low I/O byte
xor a ; first register
setreg:
ld b, 0xbf ; choose register port
out (c), a ; select register
ex af, af' ; save current register select
ld a, (hl) ; get data
ld b, 0xff ; choose data port
out (c), a ; set it
ex af, af' ; restore current register
inc hl ; advance pointer
inc a ; increase register
cp 64 ; are we nearly there yet?
jr nz, setreg ; repeat until all 64 have been done
I'm cutting in to update CULA64. Timex mode is now enabled.
in fact it was there from the begginning but it's awfully slow. It takes 20 seconds to convert an timex image (palette creation function alone takes 15 seconds). And I didn't find it useful so had removed all of the timex compare commands. Now they are back in but in a seperate function. Standard-mode is almost same as old version (maybe a fraction faster this time). I'm beggining to learn not to expect anything fast from dotnet.
Blimey, that's good. Of course, you know what's next, don't you?
You could do a 128x192 portrait rainbow conversion with that Timex mode for a 48K Speccy, but how about an 8x2 attribute mode for display on a 128K Speccy?
I don't know if it's possible to do 128 OUTs in two scanlines while POPing data off the stack or not, but if it isn't then that's too bad because the I/O method you've proposed breaks all existing software.
There is no doubt that the existing software can not be used in conjunction with the video mode that I propose. Is the existing already in the ULA+ video mode, is sufficiently good that would be eligible to be implemented in the ZX Spectrum? Or is there a better solution to increase the palette of colors?
There is no doubt that the existing software can not be used in conjunction with the video mode that I propose. Is the existing already in the ULA+ video mode, is sufficiently good that would be eligible to be implemented in the ZX Spectrum? Or is there a better solution to increase the palette of colors?
The whole point of ULAplus is a) to work as a hardware replacement for the original ULA, b) to support existing software. Right now there are more than 20,000 titles in the WoS archive. They all work with ULAplus. If you create a brand new video mode that is unrelated to the standard display then, no matter how good it is, you'll be looking at releases that support it in single figures. The Timex has had a hardware 8x1 attribute mode since 1983. I think I am personally responsible for more than half the programs that actually use it.
I want to clarify that I was talking only about the mode palette.
Put it like this - which ports would you use, bearing in mind that you cannot (reasonably) disallow any existing hardware or software. You also need to be aware that there is only limited space on the hardware.
In other words, which ports would you use? Make sure that your chosen ports don't conflict with any other hardware though. This will be internal to the speccy - it's not like you canjust unplug it in order to use another peripheral on the expansion slot.
I want to clarify that I was talking only about the mode palette.
I think Philip wants to clarify that you still haven't proposed anything which is any better.
The main aim of this project is something that can be fitted to the Spectrum permanently, that won't affect its compatibility with the back-catalogue of games.
Your proposal is a system that would alter the palette every time one of these old games tries to change the border colour. I think you're assuming that all the bits on the Spectrum's OUT port address actually work. They don't.
I can think of a workaround to enable you to set the palette via BlackCat's proposed #xxFE method which is to lock and unlock port writing via #xx3B and then set the palette. However, I think that would add an unacceptable level of complexity to the hardware as you'd go from having to deal with three ports to 66 ports. CSmith is in a better position to say if this is doable. I also don't know if it's desirable from a software point of view as you'd have to go locking and unlocking to do in game palette cycling in existing titles.
I can think of a workaround to enable you to set the palette via BlackCat's proposed #xxFE method which is to lock and unlock port writing via #xx3B and then set the palette.
I like the appeal of using #xxYY for some port YY, to allow easy port setting with the block I/O instructions. A full setup would then just require: LD HL,nnnn+&3f; LD BC,#3fYY; OTDR, and many more single CLUT changes would be possible per scanline for HAM effects. This would be the same method as used for the #xxF8 CLUT selection on the SAM. I guess MGT will have chosen that method (and port) knowing a fairly number of Spectrum titles will be run on it.
Having the CLUT locking as another bit in the ula64 enable/disable port would make setting and enabling as easy as it is currently. Whether it's all easy/possible in hardware is another matter I suppose!
I also don't know if it's desirable from a software point of view as you'd have to go locking and unlocking to do in game palette cycling in existing titles.
I'd imagine most colour setups will be set and forget, and anything complicated enough to require cycling could easily be wrapped in an unlock/lock. If port #FE isn't used the locking might only be needed for a small number of titles anyway.
I like the appeal of using #xxYY for some port YY, to allow easy port setting with the block I/O instructions. A full setup would then just require: LD HL,nnnn+&3f; LD BC,#3fYY; OTDR, and many more single CLUT changes would be possible per scanline for HAM effects. This would be the same method as used for the #xxF8 CLUT selection on the SAM. I guess MGT will have chosen that method (and port) knowing a fairly number of Spectrum titles will be run on it.
The difference is the SAM has full port decoding, so writes to the ULA don't affect #xxF8 on the SAM. On the Speccy any even port write hits the ULA. Also, scanline HAM isn't going to be much better than a static 8x1 Timex mode image.
Having the CLUT locking as another bit in the ula64 enable/disable port would make setting and enabling as easy as it is currently. Whether it's all easy/possible in hardware is another matter I suppose!
That's my point. I don't think the gain is worth the cost.
I'd imagine most colour setups will be set and forget, and anything complicated enough to require cycling could easily be wrapped in an unlock/lock. If port #FE isn't used the locking might only be needed for a small number of titles anyway.
If you're using locking then #FE isn't a bad port to pick.
I can think of a workaround to enable you to set the palette via BlackCat's proposed #xxFE method which is to lock and unlock port writing via #xx3B and then set the palette. However, I think that would add an unacceptable level of complexity to the hardware as you'd go from having to deal with three ports to 66 ports. CSmith is in a better position to say if this is doable. I also don't know if it's desirable from a software point of view as you'd have to go locking and unlocking to do in game palette cycling in existing titles.
Ok, I'll bite.
Theoretically possible but is an awful lot of effort and complication because the ULA has A14 and A15 only. Through some fiddling it can get hold of some other address lines by sneaking a peek at the DRAM bus (which is normally output only), however the upper address lines are not visible without the ULA asserting the /RAS signal to the dram, which could be bad, particularly if your code is running in the lower 16k.
Unless we built this and ran tests there would be no way to say for sure. Messy
I can think of a workaround to enable you to set the palette via BlackCat's proposed #xxFE method which is to lock and unlock port writing via #xx3B and then set the palette. However, I think that would add an unacceptable level of complexity to the hardware as you'd go from having to deal with three ports to 66 ports. CSmith is in a better position to say if this is doable. I also don't know if it's desirable from a software point of view as you'd have to go locking and unlocking to do in game palette cycling in existing titles.
You'd also have to lock and unlock it every line if you wanted to actually flush a palette change into the border colour.
Ok, I'll bite.
Theoretically possible but is an awful lot of effort and complication because the ULA has A14 and A15 only. Through some fiddling it can get hold of some other address lines by sneaking a peek at the DRAM bus (which is normally output only), however the upper address lines are not visible without the ULA asserting the /RAS signal to the dram, which could be bad, particularly if your code is running in the lower 16k.
Unless we built this and ran tests there would be no way to say for sure. Messy
That's what I thought. A lot of effort for very little gain. But then as you said, a lot of thought went into this mode.
Theoretically possible but is an awful lot of effort and complication because the ULA has A14 and A15 only.
Ouch - I didn't realise it was quite that limited. All these years I'd assumed it was peripheral makers being lazy about minimal line decoding, eating up chunks of I/O space. Together with the issue of even ULA ports, I have a new found appreciation for finding compatible holes to use!
Site updated with Linux and Windows GUI based screen conversion tools. Note: You'll get the best results from the Linux version as it optionally uses a new algorithm.
@AY Chip: I can't get it to work in command line mode on CentOS, even after recompiling, but the GUI version works fine after installing libSDL_ttf.
Comments
It requires SDL and SDL_ttf libraries.
To compile without the GUI (e.g. if you don't have those libs), use "make nogui"
As usual, I've only done the Linux build. A Windows build will probably be forthcoming from Guesser fairly soon (he's usually pretty quick at it).
Right now, get it at http://dev-null.chu.cam.ac.uk/tar/scrplus0_9.tar.gz; soon it should be hosted on the ulaplus site, in which case go there instead.
I don't know where you get 48 from. To set a colour takes two OUTs; one to select the colour to update, one to set it. As JoeFish has pointed out, since you have 32 attributes per line you only need to update the palette every two scanlines to change the whole palette on every line. I don't know if it's possible to do 128 OUTs in two scanlines while POPing data off the stack or not, but if it isn't then that's too bad because the I/O method you've proposed breaks all existing software.
This snippet from the slide show tool shows a method of updating the palette. I'm sure there are faster methods:
in fact it was there from the begginning but it's awfully slow. It takes 20 seconds to convert an timex image (palette creation function alone takes 15 seconds). And I didn't find it useful so had removed all of the timex compare commands. Now they are back in but in a seperate function. Standard-mode is almost same as old version (maybe a fraction faster this time). I'm beggining to learn not to expect anything fast from dotnet.
get it here:
http://www.veanewmedia.com/ardae/fish/culaplus_v2.rar
You could do a 128x192 portrait rainbow conversion with that Timex mode for a 48K Speccy, but how about an 8x2 attribute mode for display on a 128K Speccy?
- IONIAN-GAMES.com -
Currently at http://dev-null.chu.cam.ac.uk/tar/scrplus0_10.tar.gz; should appear on ulaplus site "this evening", according to aowen.
Screenshot of the 0.10 gui:
The whole point of ULAplus is a) to work as a hardware replacement for the original ULA, b) to support existing software. Right now there are more than 20,000 titles in the WoS archive. They all work with ULAplus. If you create a brand new video mode that is unrelated to the standard display then, no matter how good it is, you'll be looking at releases that support it in single figures. The Timex has had a hardware 8x1 attribute mode since 1983. I think I am personally responsible for more than half the programs that actually use it.
Put it like this - which ports would you use, bearing in mind that you cannot (reasonably) disallow any existing hardware or software. You also need to be aware that there is only limited space on the hardware.
In other words, which ports would you use? Make sure that your chosen ports don't conflict with any other hardware though. This will be internal to the speccy - it's not like you canjust unplug it in order to use another peripheral on the expansion slot.
D.
The main aim of this project is something that can be fitted to the Spectrum permanently, that won't affect its compatibility with the back-catalogue of games.
Your proposal is a system that would alter the palette every time one of these old games tries to change the border colour. I think you're assuming that all the bits on the Spectrum's OUT port address actually work. They don't.
- IONIAN-GAMES.com -
Yes. Now, propose something yourself and explain why it's superior to what's being proposed.
Having the CLUT locking as another bit in the ula64 enable/disable port would make setting and enabling as easy as it is currently. Whether it's all easy/possible in hardware is another matter I suppose!
I'd imagine most colour setups will be set and forget, and anything complicated enough to require cycling could easily be wrapped in an unlock/lock. If port #FE isn't used the locking might only be needed for a small number of titles anyway.
The difference is the SAM has full port decoding, so writes to the ULA don't affect #xxF8 on the SAM. On the Speccy any even port write hits the ULA. Also, scanline HAM isn't going to be much better than a static 8x1 Timex mode image.
That's my point. I don't think the gain is worth the cost.
If you're using locking then #FE isn't a bad port to pick.
Ok, I'll bite.
Theoretically possible but is an awful lot of effort and complication because the ULA has A14 and A15 only. Through some fiddling it can get hold of some other address lines by sneaking a peek at the DRAM bus (which is normally output only), however the upper address lines are not visible without the ULA asserting the /RAS signal to the dram, which could be bad, particularly if your code is running in the lower 16k.
Unless we built this and ran tests there would be no way to say for sure. Messy
- IONIAN-GAMES.com -
That's what I thought. A lot of effort for very little gain. But then as you said, a lot of thought went into this mode.
@AY Chip: I can't get it to work in command line mode on CentOS, even after recompiling, but the GUI version works fine after installing libSDL_ttf.
and here is the latest version of c# conversion:
http://www.veanewmedia.com/ardae/fish/cula64_v3.rar
it includes block boundaries dithering fix (and a selectable boundary enlarging-not very useful) and image exporting as png,bmp,jpg and gif.
if you prefer zip archives (exactly same as above except zip):
http://www.veanewmedia.com/ardae/fish/cula64_v3Z.zip
Fixed in 0.11 (now available, usual place)
Tried this new version today and its very good.. Here are a few example pics, second one (Monica Bellucci) is with Timex conversion:
http://zx-pk.ru/
Great work, everyone!
After all these years, porn on the Speccy is finally possible!
Hurrah!
;)
DAMN! Beat me to it...
what's next? "Gif" tapes?