But I do agree, the Spectrum was popular enough. Adding new features wasn't important to its ongoing popularity or survival as a platform. It just seems to me a shame that the 128k wasn't much of an improvement over its predecessor when it would have been so easy to do more.
I think the problem with the 128K was that it didn't have that killer app that was required to push its sales. There really wasn't a game that made you think "I have to buy that". I stayed with my 48K rubber key (okay, I had a DK'tronics keyboard) right through the 128K era. Every game that game out for the 128K came out on the 48K, with less levels maybe, but essentially the game was just as enjoyable as the 128K version. Having these extra colours at the time might have swayed my opinion though...
The 512x192 mode would have been nice for serious software and the one 'natural' mode that Timex missed would have been a no-clash 256x192 mode with four colours, just like on the CPC. This sort of thing would have subtracted from Amstrad's market share.
But I do agree, the Spectrum was popular enough. Adding new features wasn't important to its ongoing popularity or survival as a platform. It just seems to me a shame that the 128k wasn't much of an improvement over its predecessor when it would have been so easy to do more.
It still amazes me to this day that Sinclair didn't reverse license the Timex 2068 to release as the 128k in the UK/Spain.
Even so, I honestly think that if this new colour mode had been included in the Spectrum (48 and/or 128 ) then Commodore would never have been as successful in the UK.
EDIT: Why could they have not reserved an additional area of 'system RAM' for the CLUT? Maybe right after the attribute space?
The ULA is timed to make two byte fetches prior to drawing each horizontal 8 pixels. That's one from the pixel area and one from the attribute area. If you want to do another lookup you'd need another byte fetch in that same time to maintain the same horizontal resolution. Your ULA would have to be able to run 50% faster and the 16k DRAMs holding display data would have to be faster as well. DRAMs work by having an address split in half and presenting the two halves of it to the chip in two cycles -- the first half of an address is called the row and the second half is called the column. The ULA gets its two display file bytes by presenting the row part and then reading bytes from two different column addresses. Ie- two bytes are read using three address strobes rather than four. This allows the DRAM chip to be slower grade and therefore cheaper. I'm not sure you could extend this (another column cycle) to fetch the third byte, not due to techincal reasons but because it may introduce inconvenient holes in the memory map. At that time RAM was a major system cost and faster RAM meant more $$.
Another thing that could have been done is split the 16k video ram into two 8k pieces. And fetch the attr/pixel bytes from one 8k block (note the change in byte fetch order) while at the same time thje pixel data was being fetched, a CLUT fetch was performed on the other 8k block.
Anyway, we're probably talking more $ or non-trivial changes to how the ula did things although I'm not suggesting this is impractical.
If any1 has any other good c64 pictures I could include (hires only!) then do give me a shout !!! :)
A good idea might be to convert some hi-res C16 or +4 screens, as this has 120 colours + 8 shades of black.
BTW - does the new ULA+ do the same as the TED in the C16, as in is black the same regardless of the other colours? (Like when there is no difference between 'bright' and normal black on a standard Speccy).
The ULA is timed to make two byte fetches prior to drawing each horizontal 8 pixels. That's one from the pixel area and one from the attribute area. If you want to do another lookup you'd need another byte fetch in that same time to maintain the same horizontal resolution. Your ULA would have to be able to run 50% faster and the 16k DRAMs holding display data would have to be faster as well. DRAMs work by having an address split in half and presenting the two halves of it to the chip in two cycles -- the first half of an address is called the row and the second half is called the column. The ULA gets its two display file bytes by presenting the row part and then reading bytes from two different column addresses. Ie- two bytes are read using three address strobes rather than four. This allows the DRAM chip to be slower grade and therefore cheaper. I'm not sure you could extend this (another column cycle) to fetch the third byte, not due to techincal reasons but because it may introduce inconvenient holes in the memory map. At that time RAM was a major system cost and faster RAM meant more $$.
Another thing that could have been done is split the 16k video ram into two 8k pieces. And fetch the attr/pixel bytes from one 8k block (note the change in byte fetch order) while at the same time thje pixel data was being fetched, a CLUT fetch was performed on the other 8k block.
Anyway, we're probably talking more $ or non-trivial changes to how the ula did things although I'm not suggesting this is impractical.
Interesting... I imagine that the subject of improving the 128k ULA was at the very least brought up during its development... I wouldn't be surprised if you've hit the nail on the head as to why it never happened. Although they were in a hurry to produce it, so it may not have been discussed. Either way, they should have reverse licensed the 2068 ULA at the very least!
It still amazes me to this day that Sinclair didn't reverse license the Timex 2068 to release as the 128k in the UK/Spain.
The 2068 had some problems too, for one it wasn't finished :-) Timex did do some things right -- the new video modes, built in joysticks, the AY chip, the cartridge slot, the foresight for fully bankswitched memory. All internal memory can be turned off with a single edge connector signal, allowing the full 64k address space to be switchable. The 128s, with the exception of the +3, cannot do this and they suffer for it (sort of, think CP/M implementations, the present day SymbOS, or any future kind of real operating system that people like to dream about).
However, the basic system was buggered. They split the 24k it occupied into 16k in the main bank and 8k in a spillover bankswitched bank. And how they made changes to accommodate new commands doesn't meet with Geoff's approval :-D (and I think we can trust him on it). Timex had always promised a 16MB bankswitching scheme. The unfinished code can be found in the ROMs and from what has been reverse engineered, it is clearly an over complicated ill-thought out scheme. The wrong way to go :-( Perhaps the less than ideal design was the result of trying to rush a machine to market before it was ready. They did socket the ROMs for possible future update.
But yeah if Spanish law required 64k machines to have spanish in them or somesuch then a 72k english TS2068 probably circumvents that law :-)
BTW - does the new ULA+ do the same as the TED in the C16, as in is black the same regardless of the other colours?
No, but you can set the every 8th colour to black if you like.
@AA: It's not 64 bytes per CLUT, it's 64 bytes total.
Sinclair *did* license the 512x192 mode. They were going to use it in the Pandora.
The 128K was the way it was because Sinclair was given a design spec by Investronica. Investronica probably didn't know the SCLD existed.
Oh and there are some interesting facts about the T/S2000 series that I'd love to share but can't yet. If anyone knows Darran Jones can they ask him to reply to my email (or email me if he's lost it).
Oh and there are some interesting facts about the T/S2000 series that I'd love to share but can't yet. If anyone knows Darran Jones can they ask him to reply to my email (or email me if he's lost it).
Hmmm... You do know I'm writing a book about this kind of stuff don't you? Is this information of historical relevance that wouldn't be out of place in a book on the history of the Spectrum, perchance ;)
Hmmm... You do know I'm writing a book about this kind of stuff don't you? Is this information of historical relevance that wouldn't be out of place in a book on the history of the Spectrum, perchance ;)
Don't publish until you see an article by me on the development of the T/S 2000 series then. At that point the information will be in the public domain. If I can get my publisher to agree to first rights only then I'll happily let you include any copyright material in your book.
Pardon my current ignorance, but what would it take to overcome the limitations of having two colours per cell?
I'm guessing that to do so would require such a major re-development that it might as well be called a different computer?
I've already mentioned two ways to do it in this thread :P It is very easy, in fact a natural extention of the ula. A 256x192 mode with a choice of four colours for each pixel is possible as well as a 256x192 pixel 32x192 using all colours, as implemented in the Timex machines. The ula as it is fetches two bytes to draw each 8 pixels. If you superimpose those two bytes you get two bits per pixel drawn, or a choice of four colours. The 32x192 mode uses the second byte as attribute as in the usual spectrum mode but instead of mapping pixel addresses redundantly to attribute addresses (so each 8 vertical pixels map to the same attribute address) we map each pixel address uniquely to a second display file. You can do this by adding a constant offset to the pixel address. This was what was done by Timex to get the 32x192 mode.
These are simple and natural evolutionary steps to take, hence the question on why Sinclair didn't do it in the 128k. Andrew's pretty much answered that question, I think. The spectrum was done at Sinclair which was concentrating on the QL as the next step not the 128k. The 128k was made at Investronica's behest.
I don't think these changes would make the machine 'less spectrum'. They are simple answers to the question, how do you draw 8 pixels when you have two bytes to describe them?
[/quote]
Or could it actually be achevied by developing a mega ULA to replace the current one?[/QUOTE]
If you want better than four colours per pixel then you need something different.
it's just a bit of extra logic in the ULA, I don't know how much space there was left in the original ULA, I'm sure chris smith can tell you.
As AA has pointed out - gazillions of gates and flip-flops. 64 * 8 Flip-Flop/latches for the palette storage = 512, plus a 640 2-input-nor gates for the multiplexing (4*16*8 + 16*8 ).
That would take 832 matrix cells of the ULA, plus the other necessary circuitry. The 5C000 ULA had 440 matrix cells in total, so you'd need at least two ULAs of that size. This is so impractical that external memory would have been required for the palette. Propagation delay will have been the major issue, leading to other colour effects similar to the two-levels-of-intensity effect and the edge-artifact with flashing cells.
As devices are much larger and efficient these days, it is likely to fit into a reasonably cheap CPLD. Worse case, a small amount of external memory may be required, or FPGA is used instead, as this will have the internal memory required. The design has been proven, but not synthesised, so I don't know how big a CPLD/FPGA is required.
I've already mentioned two ways to do it in this thread :P It is very easy, in fact a natural extention of the ula. A 256x192 mode with a choice of four colours for each pixel is possible as well as a 256x192 pixel 32x192 using all colours, as implemented in the Timex machines.
Thing is, there isn't an easy method of doing it that doesn't take up more screen memory. Both of these methods will go up from 6.75K to 12K of screen data. Not impossible as they can still be drawn from the lower 16K RAM bank. The problem I can forsee is you may have to add a new ROM in as well, to work around it and draw on it. Though you could activate the extra mode exclusively from machine code...
The problem I can forsee is you may have to add a new ROM in as well, to work around it and draw on it. Though you could activate the extra mode exclusively from machine code.
For the 32x192 attribute mode you don't need a new ROM or machine code, just use ColorPRINT. There's also a version available that works on the standard 48K Speccy using your software 8x1 attribute mode.
For the 32x192 attribute mode you don't need a new ROM or machine code, just use ColorPRINT. There's also a version available that works on the standard 48K Speccy using your software 8x1 attribute mode.
That's not my point. If the system variables and the start of the BASIC area aren't shifted up to allow for a 12K screen then you're not even going to be able to type LOAD "" to load any modified routines. And if the ROM's printing routines aren't modified you won't be able to see yourself type LOAD "" on the screen. Even if the Speccy started in normal mode, you couldn't switch to a mode that needed extra screen memory from BASIC unless the ROM was given the ability to relocate the BASIC program. You would need a machine code routine to relocate any BASIC you'd already entered, switch to the new graphics mode, then add its own colour printing routines. And that's assuming you leave a gap in the middle of the screen memory map so the system variables don't have to move, which is a horrible idea. And of course we're also assuming that people are willing to load an extension from tape all the time - personally, I'd prefer a replacement ROM!
If the system variables and the start of the BASIC area aren't shifted up to allow for a 12K screen then you're not even going to be able to type LOAD "" to load any modified routines.
That's exactly what ColorPRINT does. It shifts BASIC up past the second screen area. It stores its own code in the gap between screens, and the extended UDG set at the top of the RAM and what's left is available to BASIC.
And if the ROM's printing routines aren't modified you won't be able to see yourself type LOAD "" on the screen.
Providing you set the attribute map to something sensible, which ColorPRINT does, the standard printing routines will still set the bitmap, so you can see yourself typing.
Even if the Speccy started in normal mode, you couldn't switch to a mode that needed extra screen memory from BASIC unless the ROM was given the ability to relocate the BASIC program.
The original ROM already has this ability. ColorPRINT works by calling the MAKE_SPACE routine.
You would need a machine code routine to relocate any BASIC you'd already entered, switch to the new graphics mode, then add its own colour printing routines.
Yes, that's what ColorPRINT does.
And that's assuming you leave a gap in the middle of the screen memory map for the system variables, which is a horrible idea.
Unfortunately there's no other way around it, however, you can locate the new printing routines in the gap.
I've done an image converter to produce 64-colour screens subject to the various restrictions. It's a bit quick&dirty at the moment, but it works.
I've only built it for Linux so far, but it's basically plain C with SDL_image, so you should be able to find ways to build it for other OSes.
Source tarball (0.1, stable): http://sites.google.com/site/ulaplus/ulaplus0_1.tar.gz
Latest dev tarballs: http://dev-null.chu.cam.ac.uk/tar/ulaplusHEAD.tar.gz (but only during about 12:30-22:30GMT, because the rest of the time my comp is offline)
I've only built it for Linux so far, but it's basically plain C with SDL_image, so you should be able to find ways to build it for other OSes.
I tried to build some win32 binaries last night but got bogged down in library hell.
if anyone can get mingw to cross compile against the win32 SDL_image library files I'd be very interested to know what you did...
Of course, the other way to avoid colour-clash is to pair up pixels to give independent four-colour pixels at half the resolution. You can use the attribute byte to describe two of those colours (palettised if you like) and have the other two colours as common settings over the whole screen. You don't need any more memory to store the screen, and you don't add a processing overhead of having to shift more data to draw to the screen. You don't even necessarily need a mode switch - you could use the FLASH bit of the attribute to toggle each character separately between a high-res two-colour or low-res four-colour square.
But then a lower resolution most definitely starts to look un-Spectrum like - you're well on your way to C64 territory by then. Tall pixels rather than wide ones may be preferable, but if the ULA can only read two bytes per 8 pixels then you couldn't have both that and attributes. It'd be cool to see it though.
Personally, I think the biggest improvement that could have gone into the ULA from the beginning was a screen pointer, even if only over the lower 16K of RAM. I suppose now if you want that, you just start with a 128.
I am very impressed with the extra colours ... I'm a bit daft and thick, how is this accomplished? I've heard about the new ULA thingie but I'm just wondering are the new colours implemented as new instructions (MC/Basic/C/whatever) or what?
Not exactly - it uses the 8 colour codes on the screen as indices into a palette table. You then use OUT commands to set up the palette. You can use either BASIC or Machine Code to do that. So you can redefine any of the normal 8 colours to be any of 256 different colours.
It also does a bit more since the palettes for INK and PAPER are independent, and you can use the BRIGHT and FLASH bits to switch in different palettes too.
I've succeed in getting my toolchain to compile the converter for windows
(it's rather hacky cause it's not really been ported to windoze yet. It attempts to open a file called input.jpg, and the output will be written to stdout.txt, just rename this to .bmp or .scr depending on your input switch)
It's really amazing what more accurate colour can do for an image, even if still very blocky. I can see Buzzsaw may have to have a custom palette, if only to stop people buggering about with my graphics... :x
It's really amazing what more accurate colour can do for an image, even if still very blocky.
if you squint at the images (or run a medium strength blur filter over them) the blocks all blur into smooth lines.
I'm wondering what these would look like on a crappy old telly, that should blur things a bit :)
There's a bug in the windows build that means .scr files won't work.
However the Linux version is now pretty stable. I wrote a slideshow program for the extended .SCR format and Dunny has kindly wrapped it in an importer. Both tools are now hosted on the ulaplus site, and I've put together a 32 picture slideshow from the desktop backgrounds on the MacOS 8.5 CD.
Note: You can select multiple items in MakeSlideshow's open dialog but clicking Add again will clear your previous selection.
Comments
I think the problem with the 128K was that it didn't have that killer app that was required to push its sales. There really wasn't a game that made you think "I have to buy that". I stayed with my 48K rubber key (okay, I had a DK'tronics keyboard) right through the 128K era. Every game that game out for the 128K came out on the 48K, with less levels maybe, but essentially the game was just as enjoyable as the 128K version. Having these extra colours at the time might have swayed my opinion though...
https://twitter.com/bobsstuffgames
https://www.facebook.com/bobs.stuff
http://www.bobs-stuff.co.uk
It still amazes me to this day that Sinclair didn't reverse license the Timex 2068 to release as the 128k in the UK/Spain.
Even so, I honestly think that if this new colour mode had been included in the Spectrum (48 and/or 128 ) then Commodore would never have been as successful in the UK.
Andrew
The ULA is timed to make two byte fetches prior to drawing each horizontal 8 pixels. That's one from the pixel area and one from the attribute area. If you want to do another lookup you'd need another byte fetch in that same time to maintain the same horizontal resolution. Your ULA would have to be able to run 50% faster and the 16k DRAMs holding display data would have to be faster as well. DRAMs work by having an address split in half and presenting the two halves of it to the chip in two cycles -- the first half of an address is called the row and the second half is called the column. The ULA gets its two display file bytes by presenting the row part and then reading bytes from two different column addresses. Ie- two bytes are read using three address strobes rather than four. This allows the DRAM chip to be slower grade and therefore cheaper. I'm not sure you could extend this (another column cycle) to fetch the third byte, not due to techincal reasons but because it may introduce inconvenient holes in the memory map. At that time RAM was a major system cost and faster RAM meant more $$.
Another thing that could have been done is split the 16k video ram into two 8k pieces. And fetch the attr/pixel bytes from one 8k block (note the change in byte fetch order) while at the same time thje pixel data was being fetched, a CLUT fetch was performed on the other 8k block.
Anyway, we're probably talking more $ or non-trivial changes to how the ula did things although I'm not suggesting this is impractical.
Write games in C using Z88DK and SP1
BTW - does the new ULA+ do the same as the TED in the C16, as in is black the same regardless of the other colours? (Like when there is no difference between 'bright' and normal black on a standard Speccy).
Regards,
Shaun.
Interesting... I imagine that the subject of improving the 128k ULA was at the very least brought up during its development... I wouldn't be surprised if you've hit the nail on the head as to why it never happened. Although they were in a hurry to produce it, so it may not have been discussed. Either way, they should have reverse licensed the 2068 ULA at the very least!
Andrew
The 2068 had some problems too, for one it wasn't finished :-) Timex did do some things right -- the new video modes, built in joysticks, the AY chip, the cartridge slot, the foresight for fully bankswitched memory. All internal memory can be turned off with a single edge connector signal, allowing the full 64k address space to be switchable. The 128s, with the exception of the +3, cannot do this and they suffer for it (sort of, think CP/M implementations, the present day SymbOS, or any future kind of real operating system that people like to dream about).
However, the basic system was buggered. They split the 24k it occupied into 16k in the main bank and 8k in a spillover bankswitched bank. And how they made changes to accommodate new commands doesn't meet with Geoff's approval :-D (and I think we can trust him on it). Timex had always promised a 16MB bankswitching scheme. The unfinished code can be found in the ROMs and from what has been reverse engineered, it is clearly an over complicated ill-thought out scheme. The wrong way to go :-( Perhaps the less than ideal design was the result of trying to rush a machine to market before it was ready. They did socket the ROMs for possible future update.
But yeah if Spanish law required 64k machines to have spanish in them or somesuch then a 72k english TS2068 probably circumvents that law :-)
Write games in C using Z88DK and SP1
No, but you can set the every 8th colour to black if you like.
@AA: It's not 64 bytes per CLUT, it's 64 bytes total.
Sinclair *did* license the 512x192 mode. They were going to use it in the Pandora.
The 128K was the way it was because Sinclair was given a design spec by Investronica. Investronica probably didn't know the SCLD existed.
Oh and there are some interesting facts about the T/S2000 series that I'd love to share but can't yet. If anyone knows Darran Jones can they ask him to reply to my email (or email me if he's lost it).
Citation? I did not know that.
Ditto... I don't remember that.
Hmmm... You do know I'm writing a book about this kind of stuff don't you? Is this information of historical relevance that wouldn't be out of place in a book on the history of the Spectrum, perchance ;)
Andrew
Don't publish until you see an article by me on the development of the T/S 2000 series then. At that point the information will be in the public domain. If I can get my publisher to agree to first rights only then I'll happily let you include any copyright material in your book.
Just so I know who'll have to miss out on pressies this christmas so I can buy one.
;)
Pardon my current ignorance, but what would it take to overcome the limitations of having two colours per cell?
I'm guessing that to do so would require such a major re-development that it might as well be called a different computer?
Or could it actually be achevied by developing a mega ULA to replace the current one?
I've already mentioned two ways to do it in this thread :P It is very easy, in fact a natural extention of the ula. A 256x192 mode with a choice of four colours for each pixel is possible as well as a 256x192 pixel 32x192 using all colours, as implemented in the Timex machines. The ula as it is fetches two bytes to draw each 8 pixels. If you superimpose those two bytes you get two bits per pixel drawn, or a choice of four colours. The 32x192 mode uses the second byte as attribute as in the usual spectrum mode but instead of mapping pixel addresses redundantly to attribute addresses (so each 8 vertical pixels map to the same attribute address) we map each pixel address uniquely to a second display file. You can do this by adding a constant offset to the pixel address. This was what was done by Timex to get the 32x192 mode.
These are simple and natural evolutionary steps to take, hence the question on why Sinclair didn't do it in the 128k. Andrew's pretty much answered that question, I think. The spectrum was done at Sinclair which was concentrating on the QL as the next step not the 128k. The 128k was made at Investronica's behest.
I don't think these changes would make the machine 'less spectrum'. They are simple answers to the question, how do you draw 8 pixels when you have two bytes to describe them?
[/quote]
Or could it actually be achevied by developing a mega ULA to replace the current one?[/QUOTE]
If you want better than four colours per pixel then you need something different.
Write games in C using Z88DK and SP1
That would take 832 matrix cells of the ULA, plus the other necessary circuitry. The 5C000 ULA had 440 matrix cells in total, so you'd need at least two ULAs of that size. This is so impractical that external memory would have been required for the palette. Propagation delay will have been the major issue, leading to other colour effects similar to the two-levels-of-intensity effect and the edge-artifact with flashing cells.
As devices are much larger and efficient these days, it is likely to fit into a reasonably cheap CPLD. Worse case, a small amount of external memory may be required, or FPGA is used instead, as this will have the internal memory required. The design has been proven, but not synthesised, so I don't know how big a CPLD/FPGA is required.
- IONIAN-GAMES.com -
For the 32x192 attribute mode you don't need a new ROM or machine code, just use ColorPRINT. There's also a version available that works on the standard 48K Speccy using your software 8x1 attribute mode.
- IONIAN-GAMES.com -
I've only built it for Linux so far, but it's basically plain C with SDL_image, so you should be able to find ways to build it for other OSes.
Source tarball (0.1, stable): http://sites.google.com/site/ulaplus/ulaplus0_1.tar.gz
Latest dev tarballs: http://dev-null.chu.cam.ac.uk/tar/ulaplusHEAD.tar.gz (but only during about 12:30-22:30GMT, because the rest of the time my comp is offline)
hope AY doesn't mind me posting these images that he converted up here:
the obligatory lena:
and something appropriate:
I tried to build some win32 binaries last night but got bogged down in library hell.
if anyone can get mingw to cross compile against the win32 SDL_image library files I'd be very interested to know what you did...
But then a lower resolution most definitely starts to look un-Spectrum like - you're well on your way to C64 territory by then. Tall pixels rather than wide ones may be preferable, but if the ULA can only read two bytes per 8 pixels then you couldn't have both that and attributes. It'd be cool to see it though.
Personally, I think the biggest improvement that could have gone into the ULA from the beginning was a screen pointer, even if only over the lower 16K of RAM. I suppose now if you want that, you just start with a 128.
- IONIAN-GAMES.com -
Never heard of her.
It also does a bit more since the palettes for INK and PAPER are independent, and you can use the BRIGHT and FLASH bits to switch in different palettes too.
- IONIAN-GAMES.com -
(it's rather hacky cause it's not really been ported to windoze yet. It attempts to open a file called input.jpg, and the output will be written to stdout.txt, just rename this to .bmp or .scr depending on your input switch)
this should be considered very much an ALPHA release until it's properly patched to work on a windows command line.
http://alistairtesting.no-ip.org/ulaplus/scrplus%20ALPHA.zip
Edit: here's a picture converted with it :)
- IONIAN-GAMES.com -
if you squint at the images (or run a medium strength blur filter over them) the blocks all blur into smooth lines.
I'm wondering what these would look like on a crappy old telly, that should blur things a bit :)
it's making the files the wrong length for some unknown reason
However the Linux version is now pretty stable. I wrote a slideshow program for the extended .SCR format and Dunny has kindly wrapped it in an importer. Both tools are now hosted on the ulaplus site, and I've put together a 32 picture slideshow from the desktop backgrounds on the MacOS 8.5 CD.
Note: You can select multiple items in MakeSlideshow's open dialog but clicking Add again will clear your previous selection.