Pure 'What if'-ery: The ZX Spectrum 8K and 256K models

[PeteProdge]

I know we have a lot of knowledgeable hardware folk on this forum and even though we're pretty much all Spectrum fan boys, we're usually grounded in reality.

Calling upon your somewhat unbiased expertise, and yes, this is going to be a question that invites speculation, but I think we can have realistic answers...

If there had been a ZX Spectrum 8K back in April 1982 alongside the 16K and 48K models, how much would the RRP be on that? Would £100 be a sensible ball park figure? (And sure, it'd likely be a commercial flop - interesting for home computing experimentation but obviously severely crippled as a games machine.)

After the 128K +3 in 1987 going for £249 (then later £199), I like to imagine the idea of Amstrad releasing a ZX Spectrum 256K +2 and +3 respectively (tape and disk-drive-based) in 1988. I'm doing pure guesswork that £249 would be the RRP of the +2 and the +3 would be slightly above £300. But I don't really know what RAM prices were like back then, which would have determined the actual price of course. Again, this would be very risky as a commercial venture. By this time Silica Shop are advertising entry-level Atari STs for £299 in Speccy mags! And will Speccy users tolerate the tape loading time of a 256K Speccy game? I've got a feeling this model would reach the same microscopic level of interest from the games market as the Commodore 128 did. And sure, a '256K ZX Spectrum' did work out in 1992 as a Russian clone, but that's definitely an outlier. And yeah, Alan Sugar would never really have gone down this route while he also had to look after the CPC range to preserve.

[Waldroid]

Not sure if an 8K model would be any use - just the Spectrum's framebuffer takes almost 7kB, so not a lot left to do anything much useful apart from very short BASIC programs...

[XTM]

I guess 256k games would have taken over 20 minutes to load from tape, so finally all those idiots you sometimes see commenting on retro things saying "games took 30 minutes to load" would almost be correct

[catmeows]

8K model is probably a nonsense, it is too little. 256K model is basically the direction towards Sam Coupé. The problem with 256K is that you really don't need it so desperately. 8 bit computer with floppy and 128K memory is quite well rounded machine. The next natural step is more likely 16bit with 256K but rather 512K memory.
I think the only viable option that was missed is 80K Spectrum with AY chip and in that case 128K variant would never materialized.

[Waldroid]

I think the only viable option that was missed is 80K Spectrum with AY chip and in that case 128K variant would never materialized.

Yeah, an 80kB Spectrum would've made a lot of sense. It'd need barely any extra circuitry, and then just stuff the upper RAM with 64kb chips instead of 32kb.

But, Investronica put in the work anyway, so it's a moot point.

Sorry Mr Prodge - getting a bit away from the point of your topic! To be honest, I don't know what the bulk prices of DRAM chips would've been back in those days, so hard to say how much different amounts of RAM would affect the RRP.

[catmeows]

Byte magazine 1986/09 lists memories is small quantities:
64Kx1 - $1.29 (ZX 128 +2 uses 16 of these, so it is $20.64 for 128K )
64Kx4 - $6.95 (ZX 128 +2A/+3 use 4 of these, so it is $27.8 for 128K)
256Kx1 - $2.95 (ZX 256 would use 8 of these, so it is $23.6 for 256K)

different dealer in same issue offers 1000+ quantities for this price:
64Kx1 - $0.99 ($15.84 for 128K)
256Kx1 - $3.29 ($26.32 for 256K)

Byte magazine 1987/04 lists memories in small quantities:
64Kx1 - $0.95 ($15.92 for 128K)
64Kx4 - $4.95 ($19.8 for 128K)
256Kx1 - $2.75($22 for 256K)

Please note that prices differ between dealers, so the figures above are really just for illustration.

Another thing is that for the cost of chips you have to add cost of PCB and line routing. In 1988 Amstrad introduced +2A with four 64Kx4 chips, so by that time it was probably cheaper to use only four 64Kx4 chips instead of sixteen 64Kx1 chips.

So, regarding your 256K model. I think that 32 memory chips occupy little too much space. So it would use either 8 64Kx4 memories or 8 256Kx1 memories.
Using 64Kx4 would have advantage to have same contention like previous models. On other side, using 256Kx1 would probably lead to cleaner design, at the cost of slightly different timing (*).
Either way, it looks like 256K models would not be much more expensive than 128K models. The another question is if software houses would ever support third ZX model (considering that there were not so many 128K only games).

(*) Final version of Didaktik M uses just two 64Kx4 chips so whole memory is contended and Z80 clock is increased to 4MHZ. It looks as big change but in reality Didaktik M is almost 100% compatible with ZX 48K. Well, multicolors are broken all the time, but otherwise it works.

[AndyC]

I'd agree with everyone else, an 8K model just wouldn't be viable. Once you've allocated the screen memory and system variables you're very close to being out of memory already.

256K might have been useful, but it absolutely needs a disk drive to make sense because loading that much data from tape would be unbearable.

[1024MAK]

Yeah, an 8K byte machine would have flopped.

A 80K byte or 128K byte machine is relatively easy, as the hardware arrangements are similar to the 48K model. You just need the additional ‘glue’ logic for the bank switching/paging system.

A 256K byte machine would require either, four sets of 64K DRAM chips, with not much hardware circuitry redesign (yes, the PCB would beed an extensive redesign). OR less DRAM chips because you are using 256K DRAM chips. But then all RAM would be contended. Unless you add extra circuitry to buffer memory accesses.

A way around the above problems, would have been to use 64K chips and 256K chips. Giving a 320K byte machine .

But, whichever way they may have thought about it, the 16/32 bit machines were already capturing more of the market.

Interestingly, the base Atari ST model (130ST ) was only supposed to have 128K of RAM, with the next model being the 260ST with 256K. But as the OS was still in development, only a boot-strap ROM was fitted, which loaded the OS into RAM (which used up a lot of the available RAM). Hence the 130ST model was never sold commercially. And the 260ST model was often sold with 512K bytes of RAM installed.

Hence I think a Spectrum model that was priced higher, even though it had more than 128K bytes of RAM, would also have been a flop.

Mark

[1024MAK]

Oh, also…

The other considerations:
8K DRAM chips are 16K chips where only half is certified as being operational.

By the time Amstrad took over, 16K DRAM chips were considered to be long obsolete. As were 32K DRAM chips. One of the reasons for Acorn producing the 64K B+ was that the 16K DRAM chips as used in the BBC A and BBC B were also obsolete. The B+ soon being replaced by the BBC Master (with 128K of RAM).

There are in fact, not very many 8 bit home computers that have more than 128K bytes of RAM.

Mark

[PeteProdge]

Not sure if an 8K model would be any use - just the Spectrum's framebuffer takes almost 7kB, so not a lot left to do anything much useful apart from very short BASIC programs...

You're quite right of course. I really forgotten about those 6,912 bytes of the screen! That's just over 1KB left, so what you end up with is something that's marginally more preferable than a stock ZX81. And you can't POKE higher than 24575, which is only giving you space for scant BASIC programs! Effectively, you have a kind of programmable scientific calculator that plugs into your telly! What games are gonna load on that? I guess even Micro Gauntlet (winner of a Ten Line Only BASIC content) might struggle to fit. (Can someone make a fake 8K Spectrum ROM for an emulator? Would love to see what you can/can't do on this fictional disaster of a machine I've invented!)

A way around the above problems, would have been to use 64K chips and 256K chips. Giving a 320K byte machine .

Ah, now @XTM can revel in these 320K games really taking "30 minutes to load"!

[1024MAK]

(Can someone make a fake 8K Spectrum ROM for an emulator? Would love to see what you can/can't do on this fictional disaster of a machine I've invented!)

Just use CLEAR 24575…
You will have 820 bytes free but no UDGs…

Ah, now @XTM can revel in these 320K games really taking "30 minutes to load"!

Mark

[PROSM]

(Can someone make a fake 8K Spectrum ROM for an emulator? Would love to see what you can/can't do on this fictional disaster of a machine I've invented!)

https://www.connosoft.com/prosm/otherst ... ectrum.zip

I've put up a hacked ROM at this link, which forces the P-RAMT variable to 24575, so the BASIC system thinks it only has 8K of memory. Of course, with such little RAM, the UDGs take a significant chunk of the memory left over from the screen. I've yet to find a useful program that will actually load; not even Line by @patters is small enough to fit!

[Rorthron]

To address @PeteProdge's question about the cost of DRAM, 1988 would have been a terrible time to launch a 256K Spectrum. The DRAM price surged 200% that year. As far as I can see (and the data's far from perfect), the cost would not have been excessive at the start of the year. I think it would have added only around £10 to the BOM cost. However, by the end of the year, the increase in memory prices would have made the 256K model nearly £60 more expensive than the 128K +2/+3 the previous year.

Here's some reference data, though it's noisy and seems to be based on retail, rather than wholesale, prices:

https://jcmit.net/memoryprice.htm

[Guesser]

A 256kB speccy would have been a complete waste of money as almost nothing would use all that memory. Look at how much actually made use of floppy disks...

[PeteProdge]

Just use CLEAR 24575…
You will have 820 bytes free but no UDGs…

Thanks for that! I've just tried Micro Gauntlet (literally 10 lines of BASIC, albeit very long lines) and it spews up a 4 Out Of Memory error, which shows what an utterly utterly terrible idea the 8K Spectrum is and I very much doubt any kind of game could be made for it. (Mind you, on a plain 16K Spectrum, it gives you M RAMTOP no good.)

[animaal]

What would have been interesting with a 256KB machine would have been the performance increases. As has been pointed out, I can't see all that space being filled from a cassette tape.

More likely that extra memory might be used at runtime for lookup tables etc. I think something similar has been done recently, altering Elite to run faster on a 128KB Spectrum. When you have more memory available, it's possible to trade that space for extra speed.

[spider]

Interesting topic and idea.

Regarding 8K:

I can see as said though with the screen eating a fixed 6912 bytes plus then space for Basic workspace etc, there's so little left for anything.

Unless you say "8K ram" (which would exclude the video ram) aka 'User Ram starts at 23296 for 8192bytes aka 8K) which takes you to 31488 , the difference now between the released 16K machine and this is a mere 1280 bytes.


Regarding 256K:

Yes if what is said about it not making much total production cost difference, provided that it was the disk based model only, lets say once production of the grey +2 stopped and then:

The black +2 appeared (a bit earlier) with 128K and the tape player
The black +3 appeared with 256K and the floppy drive.
Potentially given the difference/similarities (in some?) of the +2 and +3 they could of used the same board for the memory too, I daresay if it had happened these days people would be attempting to fit the missing components to turn their +2 into a 256K.

But although there were as we know a fair few 128K games, not that many were 128K only and I cannot immediately think of any +3 only games.

[TMD2003]

Thanks for that! I've just tried Micro Gauntlet (literally 10 lines of BASIC, albeit very long lines) and it spews up a 4 Out Of Memory error, which shows what an utterly utterly terrible idea the 8K Spectrum is and I very much doubt any kind of game could be made for it. (Mind you, on a plain 16K Spectrum, it gives you M RAMTOP no good.)

Eleven lines of BASIC it may be (1-10 and 3500 - what's going on there?), but it's still 4,635 bytes - far too much for this mythical 8K model with barely more room to move than a 1K ZX81.

M RAMTOP no good, 1:4 is because the command is CLEAR 65367 - that's the default RAMTOP for a 48K model, so why does that even need to be there? Changing it to CLEAR 32599, followed by the UDG definition loop to FOR a=32600 TO 32703 will make it work on a 16K model - or better still, FOR a=USR "a" TO USR "n"-1 to work on both models. Once the program has been RUN, it changes REPDEL (presumably to make the controls more responsive) so the delay before the key repeats is too short for easy editing. POKE 23561,35 puts it back to normal.

Despite that, it now gives me 4 Out of memory, 2:10...!

I loaded it into a 48K model, played the game for a bit, then saved it without a CLEAR and it came up as 5,362 bytes. So it's defined around 700 bytes of variables and arrays... which still shouldn't be enough to jam up the 9K or so that the 16K model can actually use. I can see a further problem... which is that the lines are so long that the standard 1K ZX81 memory-saving techniques will result in running out of screen.

Still, I see a challenge ahead...

EDIT: Challenge... FAILED! Taking every value and making it NOT PI, SGN PI, INT PI or a VAL (or even CODE where possible) in BASin, Micro Gauntlet can be cut from 4,635 bytes to 3,142 bytes (and probably more if I could be assured that BASin would treat a token inside a string as a token and not individual text characters even when I've specified a token with the Token Table). It still stops with the same 4 Out of memory, 2:10 as before when populating the very long string p$. Does the 16K model have less string space, or is it running out of stack space below RAMTOP while trying to build the string? I've given it an extra kilobyte and a half to play with and it's still failing. Also, the CLEAR 32599 does need to be in there, as that clears the screen as well as setting RAMTOP to where it shouldn't need to be.

[catmeows]

Can someone make a fake 8K Spectrum ROM for an emulator? Would love to see what you can/can't do on this fictional disaster of a machine I've invented!)

Actually. There was a minigame compo held for several years and there were two categories: 1K and 4K. Some of the 1K entries used extra RAM, many did not. So it may give you idea what is possible. And if there would be 8K model, soon or later someone would use part of screen memory to get more space for data. Using of just 4K for pixels and .5K for attributes would leave 3.5K for code. It is just enough to have a decent Space invanders or Pacman.

https://spectrumcomputing.co.uk/list?group_id=2001

https://spectrumcomputing.co.uk/list?group_id=2004

https://spectrumcomputing.co.uk/list?group_id=2003

https://spectrumcomputing.co.uk/list?group_id=2002

[TMD2003]

And if there would be 8K model, soon or later someone would use part of screen memory to get more space for data. Using of just 4K for pixels and .5K for attributes would leave 3.5K for code. It is just enough to have a decent Space invanders or Pacman.

With that as a prompt... GOT ONE!

GReW's Chromablaster, from the 2016 CSSCGC, loads all the game data into the screen area. I'd have to disassemble it to see what's actually going on, but as far as I know, everything needed to run the game is in the bottom third of the display file, with the attributes used to display the Mega-Chunk-o-Vision score (with PAPER and INK set to the same value), and denote what colour enemies you're supposed to shoot. What all the shash in the top two thirds of the screen does is anyone's guess - that all gets overwritten when the game starts, so it could just be random numbers.

Either way, I tried it with the 8K Spectrum ROM - PEEKing RAMTOP beforehand to make sure it was at its absurdly low value - and it worked just fine. The game's rather capricious with its controls, but fitting it into (probably) 2K was the major achievement.

I wonder what GReW's up to these days? I've got his 2017 CSSCGC site archived after all...

EDIT: on initial inspection, the first three bytes in the screen data correspond to JP 20480 (i.e. the first byte for the bottom third of the display file). So I tried this:
10 LOAD "" SCREEN$
20 FOR n=0 TO 15: PRINT AT n,0,,: NEXT n
30 LET l=USR 20480

It wipes out the "ENERGIES" banner, but does prove that other than the JP instruction, there was nothing in the top two thirds of the screen that run the game. It's all done in the 2K of the bottom third.

So some very small games are possible on the 8K Spectrum, it's just that they'd have to use less of the screen and be very efficiently programmed!

Also, from that year's CSSCGC page:

Ok, one RESET later, I followed the instructions more precisely, and et. voila, we have a game. So, the author has rather cleverly written some natty machine code, hidden it in the area of memory used to hold the screen bitmap, and hopefully relocates it outside of the screen RAM by the time it executes, so as to not overwrite the code when the game is being played.

Simon clearly didn't realise that there was no need to move the game code out of the screen area, given that only the attributes are ever changed in the bottom third. It's the kind of thing I'd have picked up on in 2021, if only anyone had sent me something similar.

[PeteProdge]

GReW's Chromablaster, from the 2016 CSSCGC, loads all the game data into the screen area. I'd have to disassemble it to see what's actually going on, but as far as I know, everything needed to run the game is in the bottom third of the display file, with the attributes used to display the Mega-Chunk-o-Vision score (with PAPER and INK set to the same value), and denote what colour enemies you're supposed to shoot.

Wow! Just given this a go, and it's really not all that bad for a game that's packed into screen memory!

It feels like a typical Atari 2600 game, and many of them were around 4KB or 8KB in size.

And there I was thinking that ten-line (er, eleven-line) BASIC game Micro Gauntlet was the pinnacle of miniature gaming!

Right lads, the 8K Spectrum is a goer, please queue up and pay £250 into my Kickstarter, it's the new Spectrum Next. I'll have it ready by 2037.

[zx_if1]

ok
about 256k speccy
SAM wasn't the only 256k base back then
there was also the timex tc3256 with 256k but it never went on sale
Can you imagine what would have been?
I think it would have been a serious rival for the SAM
a real run for his money imho
maybe if sinclair hadn't sold the spectrum his next model would have been called the zx spectrum + 256k

[highrise]

I've always thought 48k was a decent amount to work with. Some more interesting ideas would be if they had improved storage capacity and added better hardware support for games. Sir Clive kept pushing it as a business machine even though it clearly became a games machine. Imagine instead if the plus model had an AY chip, joystick ports and a cartridge slot that supported 48k games. Actually now i write that, it sounds pretty much like an Spectravideo or MSX So imagine if Sir Clive had green lit a Sinclair MSX.

[TMD2003]

Wow! Just given this a go, and it's really not all that bad for a game that's packed into screen memory!
It feels like a typical Atari 2600 game, and many of them were around 4KB or 8KB in size.

I get the impression that GReW is a bit of a genius with Z80 assembler, which it why it's a shame he's wandered off somewhere (while hosting the 2017 CSSCGC...)

It's a bit like the kind of thing @Dr beep is doing with the 1K ZX81. I had no idea it was possible to pack a hi-res game into that tiny memory, but he's made tons of them - although it looks to me like they all need a hi-res add-on (which is switchable on EightyOne, but I don't have one for my real ZX81).

And there I was thinking that ten-line (er, eleven-line) BASIC game Micro Gauntlet was the pinnacle of miniature gaming!

While trying to cram it into the 16K Spectrum I found that line 3500 is just a copy of line 5 and isn't needed, so it does qualify as a ten-liner after all.

Still couldn't get it running, mind, even after all the VALs and getting shot of line 3500 altogether.

So imagine if Sir Clive had green lit a Sinclair MSX.

Dragon Data almost did exactly that in their dying days, once the Dragon 32 had run its course... then again, its users were at a bit of an advantage (for once!) as they both used versions of Microsoft BASIC.

LINE(160,144)-(188,105),PSET,BF

[1024MAK]

It's a bit like the kind of thing @Dr beep is doing with the 1K ZX81. I had no idea it was possible to pack a hi-res game into that tiny memory, but he's made tons of them - although it looks to me like they all need a hi-res add-on (which is switchable on EightyOne, but I don't have one for my real ZX81).

The unexpanded ZX81 with 1K byte of memory can produce software created hi-res graphics.

A couple of things to keep in mind. I don’t think Sinclair wanted to rock the boat too much with the third party hardware suppliers. Plus he wanted the Speccy to be entry level (cheap). Launching when he did was also more important than getting the microdrives to work. Hence the BASIC ROM being unfinished and the Interface 1 being more complex than it needed to be.

But I do agree that more features could have been added to a follow up model. IMHO, it would have made sense to release a ZX Spectrum 96K+ model. This would have had:

• 96K bytes of RAM (made up of 32K bit chips for the ‘lower’ DRAM and 64K bit chips for the ‘upper’ DRAM, hence no longer needing the unreliable 4116 DRAM chips). Bank switching/paging used to access the extra memory.
• 32K bytes of ROM
• Single Sinclair standard joystick port (Atari pin-out on a 9 way D connector)
• AY sound chip
• Parallel printer port (driven off the I/O port of the AY Sound chip)
• Composite video output on a phono connector
• Microdrive connector
• Power switch
• Plus of course the plus keyboard, case and reset button.

Although a cartridge slot is cheap (only the cost of the connector), I would not have included one, due to the limitations and lack of carts available.

Mark