That could be a tricky one with the timing differences. The VIC-2 runs at around 8MHz with not a lot of waggle room and the Spectrum at 3.5MHz.
If the box is a frame buffer with own microcontroler, feeded by fast parallel data connection, this is not that important. But there would be also possibility to use Amiga custom graphic chip too (which will consume more memory). VIC II is less complex to use and needs less memory. Imagine a microcontroler with 8x64KB RAM Banks (For 32 screen banks), with command makros for fast primitive and filled vector graphics drawing, direct block Data transfer, Sprites (with automatic multiplexing), Scrolling, Multiple advanced graphics/Text and mixed modes... Connected to the Spectrum via Ports for Command and Data.
[...]Connected to the Spectrum via Ports for Command and Data.
Hmmm don't like it. If the Speccy hangs, it's most probable the screen won't go crazy with the familiar randomly coloured squares, as we all *know* :razz:
That's not a feature, that's a bug, in old-speccy-lingo.
Hmmm don't like it. If the Speccy hangs, it's most probable the screen won't go crazy with the familiar randomly coloured squares, as we all *know* :razz:
That's not a feature, that's a bug, in old-speccy-lingo.
(disclaimer: just-a-joke - Ed.)
You can make a watchdog timer which checks if Z80 hangs, and then fill the buffer with random or predefined data ;).
My thoughts have been turning to ULA+ of late, as I've been toying with the idea of producing a game specifically for the format. At present, there's a lack of graphics editors which support the new mode, so any graphics would need to be designed by first running a palette editor and then loading a Spectrum art package.
I was wondering, is there a defined standard for ULA+ .scr files? It seems to me we'd need 64 bytes for the palette followed by the 6912 bytes for the screen - or maybe even the other way around. It would be nice to have some way to save out a palette, so the 64 bytes can be stripped out and placed in a table in the code so the palette can be recreated.
Oh, and if the maintainer of the ULA+ site is reading this, you can add Utter Tripe to the list of ULA+ games. It makes only limited changes to the palette, but it's rather handy to make subtle differences to the colours, add an orange, and to replace magenta with separate pink and purple.
I was wondering, is there a defined standard for ULA+ .scr files? It seems to me we'd need 64 bytes for the palette followed by the 6912 bytes for the screen - or maybe even the other way around. It would be nice to have some way to save out a palette, so the 64 bytes can be stripped out and placed in a table in the code so the palette can be recreated.
I'm not actually expecting anyone to implement CMYK (mode 3), but it turns out that 8-bits are sufficient for fairly high resolution colour printing.
RGB (mode 1) is the preferred mode (and the one that's currently emulated). It gives the large range of distinct colours and is best suited for use with conversions from 24-bit images. However it is a digital mode and it requires quite a bit of logic to implement, as a result of which there is now...
HSL (mode 2) for use with analogue implementations. The actual colours available won't be finalized until the hardware is finished and it's not emulated in any case. It's really just a compromise to get some ULAplus support into a very simple design.
When I know what the HSL colours are I will write a command line tool for converting mode 1 palette files into mode 2 palette files. Since the Mojons have kindly supplied source code for their ULAplus titles it will be possible to patch them.
For anyone developing ULAplus software now, I would recommend carrying on with mode 1 and forgetting about HSL all together.
Given that, it would seem to me to make sense to change your spec to say the minimum ULA+ support should be modes 0 and 1 and the rest are optional, instead of just specifying 0 (ordinary Speccy) and one other.
Given that, it would seem to me to make sense to change your spec to say the minimum ULA+ support should be modes 0 and 1 and the rest are optional, instead of just specifying 0 (ordinary Speccy) and one other.
The problem with that is that one analogue device in particular is not going to support mode 1. However, other than having a different palette, it will support the rest of the ULAplus features. So far only one program exists that does colour cycling (Chaos) everything else uses a static palette, so it's simple to convert from mode 1 to mode 2. Of course once real hardware exists with mode 2 there's less incentive to develop mode 1 stuff, but if the mode 2 hardware ships I'm reasonably confident that the mode 1 stuff will get there eventually.
The has been a minor update to the spec. This is to accomodate mode specific settings. All will become clear when the HSL mode is finalized. The upshot is that when you're setting the mode, you need to write 01000000b to the register port before writing the mode to the data port. In the original spec 01xxxxxxb was valid for mode select. In practice all existing software appears to send 01000000b to the register port so no software should be affected.
One other thing: It turns out that when using AY Chip's SCRplus conversion tool (or ref's version called CULA) it often helps if you pre-dither the image to the full 256 colour palette. It doesn't work well for every image, but even for 8x8 attribute cells it can dramatically improve the quality of the conversion. For 8x1 attribute cells (Timex mode 2) the results are really good.
Very impressive results! I have a lot of catching up to do, but from what I can see we can now have images that don't have so much "orange" on them. Hopefully those results are not limited to Timex computers. :)
Very impressive results! I have a lot of catching up to do, but from what I can see we can now have images that don't have so much "orange" on them. Hopefully those results are not limited to Timex computers. :)
Full screen 8x1 mode is limited to the Timex. Having said that, if we had some real hardware to figure out the timings against you could change the palette while the screen was drawing and convert images using all 256 colours, either on the original machine or in Timex mode.
Full screen 8x1 mode is limited to the Timex. Having said that, if we had some real hardware to figure out the timings against you could change the palette while the screen was drawing and convert images using all 256 colours, either on the original machine or in Timex mode.
Whoa what is this sorcery? Excuse me for being a total noob and an idiot and all that but one more question: Is this just for emulators or can real hardware spectrum have more colors too? Specifically, what is the best version of Head over Heels I can run on a spectrum 128k toaster with divide and ram turbo joystick interface? Actually, I don?t even know what "ULA" is. Do I need to make hardware changes or some kind of firmware updates to get more colors versions of games working? (or again is it just for emulators).
Okay, so I read about it a bit more and apparently then it?s just for emulators and possibly some future fpga implementation of spectrum, right?
Hello Andrew,
sorry to write here but I don't know how to contact you (no PM and your old GMail address apparently doesn't work anymore). I'd like to test your HAM256 viewer on my FPGA core and also I'd need your advice about some ULA+ and Timex related stuff. Could you please contact me via e-mail: adorigatti@gmail.com.
Whoa what is this sorcery? Excuse me for being a total noob and an idiot and all that but one more question: Is this just for emulators or can real hardware spectrum have more colors too?
Real hardware but at present limited to clones. No plug-in replacement for original hardware yet.
Specifically, what is the best version of Head over Heels I can run on a spectrum 128k toaster with divide and ram turbo joystick interface? Actually, I don?t even know what "ULA" is. Do I need to make hardware changes or some kind of firmware updates to get more colors versions of games working? (or again is it just for emulators).
Games that are primarily monochrome, like HoH, don't really get much benefit from ULAplus. Works better with things like Cybernoid.
Hello Andrew,
sorry to write here but I don't know how to contact you (no PM and your old GMail address apparently doesn't work anymore). I'd like to test your HAM256 viewer on my FPGA core and also I'd need your advice about some ULA+ and Timex related stuff. Could you please contact me via e-mail: adorigatti@gmail.com.
Thank you in advance,
Alessandro
Sure thing, will send you a message from my current email address.
Comments
If the box is a frame buffer with own microcontroler, feeded by fast parallel data connection, this is not that important. But there would be also possibility to use Amiga custom graphic chip too (which will consume more memory). VIC II is less complex to use and needs less memory. Imagine a microcontroler with 8x64KB RAM Banks (For 32 screen banks), with command makros for fast primitive and filled vector graphics drawing, direct block Data transfer, Sprites (with automatic multiplexing), Scrolling, Multiple advanced graphics/Text and mixed modes... Connected to the Spectrum via Ports for Command and Data.
Hmmm don't like it. If the Speccy hangs, it's most probable the screen won't go crazy with the familiar randomly coloured squares, as we all *know* :razz:
That's not a feature, that's a bug, in old-speccy-lingo.
(disclaimer: just-a-joke - Ed.)
You can make a watchdog timer which checks if Z80 hangs, and then fill the buffer with random or predefined data ;).
You Here Now
http://pc.sux.org/tomcat/YouHereNow.tap
C64 original: http://noname.c64.org/csdb/release/?id=97764
I was wondering, is there a defined standard for ULA+ .scr files? It seems to me we'd need 64 bytes for the palette followed by the 6912 bytes for the screen - or maybe even the other way around. It would be nice to have some way to save out a palette, so the 64 bytes can be stripped out and placed in a table in the code so the palette can be recreated.
Oh, and if the maintainer of the ULA+ site is reading this, you can add Utter Tripe to the list of ULA+ games. It makes only limited changes to the palette, but it's rather handy to make subtle differences to the colours, add an orange, and to replace magenta with separate pink and purple.
Egghead Website
Arcade Game Designer
My itch.io page
http://scratchpad.wikia.com/wiki/ZX_Spectrum_64_Colour_Mode#Extension_to_the_SCR_Format has the scr extensions.
do you have a google account...? :)
Thanks for that, just the info I was after.
No Google account, I'm afraid.
Egghead Website
Arcade Game Designer
My itch.io page
bah, okay then I'll update it heh
EDIT: actually I don't seem to actually be able to, pfffft
It would give a feel for what extra smoothing the block edges would get on the real hardware.
Steve.
Steve.
You already have the answer. ;)
http://www.worldofspectrum.org/forums/showpost.php?p=509605&postcount=4
http://zx-pk.ru/
What a shame!
http://www.zxshed.co.uk/sinclairfaq/index.php5?title=ULAplus
I'm not actually expecting anyone to implement CMYK (mode 3), but it turns out that 8-bits are sufficient for fairly high resolution colour printing.
RGB (mode 1) is the preferred mode (and the one that's currently emulated). It gives the large range of distinct colours and is best suited for use with conversions from 24-bit images. However it is a digital mode and it requires quite a bit of logic to implement, as a result of which there is now...
HSL (mode 2) for use with analogue implementations. The actual colours available won't be finalized until the hardware is finished and it's not emulated in any case. It's really just a compromise to get some ULAplus support into a very simple design.
When I know what the HSL colours are I will write a command line tool for converting mode 1 palette files into mode 2 palette files. Since the Mojons have kindly supplied source code for their ULAplus titles it will be possible to patch them.
For anyone developing ULAplus software now, I would recommend carrying on with mode 1 and forgetting about HSL all together.
- IONIAN-GAMES.com -
The problem with that is that one analogue device in particular is not going to support mode 1. However, other than having a different palette, it will support the rest of the ULAplus features. So far only one program exists that does colour cycling (Chaos) everything else uses a static palette, so it's simple to convert from mode 1 to mode 2. Of course once real hardware exists with mode 2 there's less incentive to develop mode 1 stuff, but if the mode 2 hardware ships I'm reasonably confident that the mode 1 stuff will get there eventually.
Full screen 8x1 mode is limited to the Timex. Having said that, if we had some real hardware to figure out the timings against you could change the palette while the screen was drawing and convert images using all 256 colours, either on the original machine or in Timex mode.
Which has now been done: http://www.worldofspectrum.org/infoseekid.cgi?id=0027262
Okay, so I read about it a bit more and apparently then it?s just for emulators and possibly some future fpga implementation of spectrum, right?
sorry to write here but I don't know how to contact you (no PM and your old GMail address apparently doesn't work anymore). I'd like to test your HAM256 viewer on my FPGA core and also I'd need your advice about some ULA+ and Timex related stuff. Could you please contact me via e-mail: adorigatti@gmail.com.
Thank you in advance,
Alessandro
Nebula
Games that are primarily monochrome, like HoH, don't really get much benefit from ULAplus. Works better with things like Cybernoid.
Sure thing, will send you a message from my current email address.