'What if' Spectrum fantasy computer

[andydansby]

Along the same thought process as viewtopic.php?f=24&t=9738&sid=a2fb99f69 ... 1e0daa664a. What if Sinclair released a 64 K RAM ZX Spectrum that loaded the first 16K RAM from a ROM in 1982. In this scenario, when you first turned on the machine, the first 16K of RAM would be loaded from a side ROM. The OS and BASIC would load and the machine would operate normally.

A normal BASIC program would see no change, and would program just like a normal 48K machine. However, games and program data would be able to take advantage of the full 64K, via a custom loader.

Alternatively, if you could load a different programming language in the first 16k. Any of the Hisoft programming languages or "White Lightning" could take advantage of. this additional 16K. Same advantage would go for Tasword.

[Ralf]

Well, you would have extra 16kB, that's all. For a bigger price of the machine.

You could also make some tweaks to Basic but that would be of limited usage.

However in 1982 they wouldn't know how to use that extra memory properly anyway;)

In 1985 they made Shadow of the Unicorn https://spectrumcomputing.co.uk/entry/4 ... he_Unicorn
It does something similar to your idea, replaces the ROM with its own code.
But the game turned out at best so-so.

[Waldroid]

Investronica made the Inves Spectrum+ which had 64kB.

Sadly, they didn't have the vision to go the extra foot and add a smidgeon of circuitry to allow the ROM to be turned off, so the bottom 16kB is just wasted. Such a pity!

Noel of Noel's Retro Lab has done some nice videos about the machine:

[Juan F. Ramirez]

In that parallel universe, Imagine would have finished their megagames (Bandersnatch), they'd have been a great success, the company wouldn't have gone bankrupt, so it would have never been taken over by Ocean and Denton Designs would have never existed so The Great Escape or Where Time Stood Still would have never existed or have been different...

Well, just my silly thoughts... supposing Bandersnatch fitted in those additional kbs!

[1024MAK]

Having a machine that has a shadow RAM/ROM area is not difficult. If however you were intending on going on this route, it may have been beneficial to use part of the first 16K for the screen RAM.

The problem with the Sinclair computers is that they were designed and implemented with only a limited plan on expansion. And no plan on what any future model would be like.

Looking back, the ZX81 replaced the ZX80, but software wise, the ZX81 is not compatible.
The ZX Spectrum is not compatible with the ZX80 or the ZX81.
Hence, any future Sinclair computer after the ZX Spectrum would unlikely be compatible. And this was exactly what happened, the QL and the Z88 were not backwards compatible.

Whereas, some of the 1980s computer manufacturers did at least outline some potential expansion provision, and documented it.

Why? Well, I don’t think at the time of the development of the ZX Spectrum, anyone realised the importance of having backwards software compatibility, as there was no home computers with a vast software library (at least, not in the U.K.).

After the success of the rubber key 48K model. In terms of RAM, there was nowhere to go. Until the Spanish wanted to break the 64K address limit of the Z80, and have banked/paged memory.

The other problem with a ZX Spectrum with 64K bytes of RAM, is that in a 48K machine, the physical DRAM chips are split into two sets. One is accessed only by the Z80. The “lower” 16K is also read by the ULA to provide the video data (and hence is “contended”). Hence these two sets are effectively on different busses.

If you had a 64K machine, the most cost efficient is to use 64K chips. Now you have the problem of all RAM being contended. Unless you add extra circuitry to add buffering. But that would have required extra development time…

Mark

[Joefish]

Along the same thought process as viewtopic.php?f=24&t=9738&sid=a2fb99f69 ... 1e0daa664a. What if Sinclair released a 64 K RAM ZX Spectrum that loaded the first 16K RAM from a ROM in 1982. In this scenario, when you first turned on the machine, the first 16K of RAM would be loaded from a side ROM. The OS and BASIC would load and the machine would operate normally.

Not quite so simple, as then you'd still need another tiny ROM holding the handful of instructions to boot up and copy the ROM to RAM.
Simpler to have paging so it boots up with the ROM in the bottom of the address space by default, then lets you switch it out and have RAM in that address space later instead. You just need the ULA to be able to divert a few of the address lines, like it does in 128K paging.

It's what the C64 did. If you programmed that in BASIC, you only had access to 32K of RAM. The rest of its 64K of RAM was hidden behind paged-in ROMs and mapped-on peripherals, while BASIC was active.

[spider]

I thought about shadow RAM for the lower 16K too, effectively giving a 64K Speccy.

Regarding the standard ROM, a thought occurred. What if...

The machine had 64K of ram

Upon power up a ROM was read due to initial paging state, this merely copied itself into the lower 16K then paged the ROM out, and carried on executing the 'image' of the ROM (but its sat in the lower RAM 0-16383) , copying itself minus perhaps the paging code.

Upon a hard reset, the sequence would begin again and its not going to take long to LDIR 16K , I suppose if that's not that easy it could of copied itself to higher memory, paged itself out then relocated down and wiped the copy from the higher memory.

I know what I mean, I just can't quite phrase it correctly.

Games and other commercial software could overwrite this space as they saw fit once a loader was up and running, and also simple turboloaders would of been easy as a tiny tiny bit of code would of been needed to alter the 'rom but its ram' timing.

EDIT... Great Minds as I'd not read the topic properly! Honest.

[AndyC]

It's only a dozen bytes or so to LDIR the ROM in place if you assume writes to those addresses always go through to RAM even with the ROM paged in (ala the Amstrad CPC). There would easily be enough space in the ROM to house a routine to do it at startup.

I can't see Sinclair having gone for the idea though as it would seem somewhat wasteful under ordinary circumstances (his notion of ordinary being writing BASIC programs). I suspect if it was going to be a 64K machine, he'd have wanted all the RAM to be usable from BASIC rather than seeing it as a benefit largely for machine code programs.

[Joefish]

But if the ROM is able to page itself out once it's copied itself into RAM, what's the point? Why not just tell the user how to do the paging, if they want to? It's not like the ROM can mysteriously access hardware features that other code can't. If ROM code can do it, so can any code. And copying the ROM into RAM is riskier too, as it means it can be accidentally corrupted, whereas a paged-in ROM cannot.

[AndyC]

We'll "ROM" routines could have used self modifying code. UDGs wouldn't have had to be treated separately by the PRINT routine (modifying them could just alter the copied RAM directly). User code could modify BASIC behaviour etc.

I'm not saying it's a good idea, just that it's a possible one.

[1024MAK]

Not quite so simple, as then you'd still need another tiny ROM holding the handful of instructions to boot up and copy the ROM to RAM.

Not entirely true. The computer starts up with the ROM in the memory map for reads only. All writes go to RAM. The first thing the ROM code does, is copy itself to RAM. Then it does an OUT to a particular address (can also be done by other methods), this then flips a flip-flop which disables the ROM and allows reading from RAM. All further reads then come from RAM, hence execution is also from RAM.

The primary advantage is that such a computer has a memory map that is better for CP/M. Although on the Speccy, the screen memory gets in the way.

Mark

[XTM]

In that parallel universe, Imagine would have finished their megagames (Bandersnatch), they'd have been a great success, the company wouldn't have gone bankrupt ...

So, no Bruce Everiss ramblings about piracy killing the industry then?

[Mpk]

Although on the Speccy, the screen memory gets in the way.

Given that we're building a fantasy machine here, what's the best way to resolve that?

Also, can we have a joystick interface with more than 1 button?

[RST#08]

Some general principles here, although this is just for 16K ROM/RAM and optional 32K upgrade, not 128K. But principles are similar. Anything above 32K for the upper memory would obviously need (fairly simple) paging circuitry.

https://archive.org/details/your-spectr ... ew=theater

Coincidentally, three pages later is an advert for the SP80 from East London Robotics, also listed in the database here:

https://spectrumcomputing.co.uk/entry/1 ... dware/SP80

Not sure if this was only available as a daughterboard for Issue 1 machines (instructions seem to suggest so), but I do know they did sell a 48K upgrade kit for Issue 2 machines (comprising some 4532s and a few logic chips), because I bought one!

Edit: The advert asks customer to specify 'which issue', so presumably was available for Issue 2 etc.

[1024MAK]

Given that we're building a fantasy machine here, what's the best way to resolve that?

Also, can we have a joystick interface with more than 1 button?

The solution is not hard, it’s just a case of using bank switching/paging. Ideally, so that to the Z80, the screen memory can be put in to either the normal part of the memory map, or an alternative position. Obviously including not being in the Z80 memory map at all if required. This does however mean that if wanting to use CP/M, we need 80Kbytes or more of RAM.

Yes, a joystick port can have eight input lines, of which, four are direction inputs and four are fire or function buttons. However, if using a 9 pin D connector (Atari joystick compatible), if we include a +5V supply, then we will have a maximum of three fire button inputs.

Mark

[RST#08]

Yes, a joystick port can have eight input lines, of which, four are direction inputs and four are fire or function buttons. However, if using a 9 pin D connector (Atari joystick compatible), if we include a +5V supply, then we will have a maximum of three fire button inputs.
Mark

Agree. Not a joystick expert, but IIRC, Bits 5 and 7 on Port +FEh are not used for input so these could be used to extend the existing 8x5 keyboard matrix to provide up to 16 additional buttons or keys on the keyboard without affecting existing software.

[AndyC]

Yes, a joystick port can have eight input lines, of which, four are direction inputs and four are fire or function buttons. However, if using a 9 pin D connector (Atari joystick compatible), if we include a +5V supply, then we will have a maximum of three fire button inputs.

But that assumes.a fairly simplistic design that's Atari "compatible". You could, however, do something like the CD32 and use those spare lines for a minimal serial interface and then add as many buttons as you like.

[1024MAK]

Yes, I was referring to using a Kempston compatible joystick port using an Atari compatible 9 pin D connector.

If you want more input buttons, there are a number of ways of doing it. For the 128K machines, you can use the RS232/MIDI/KEYPAD/AUX ports to form a keyboard matrix (4 x 4) to get you 16 buttons with very little extra circuitry.

You can use the keyboard matrix, which gives you 40 buttons!

Or using one line, using a serial communication protocol, you can have 255 buttons! Or more!

Mark

[catmeows]

Given that we're building a fantasy machine here, what's the best way to resolve that?

Also, can we have a joystick interface with more than 1 button?

IMHO - you would need same timing scheme as used in CPC, that would allow to use single set of 64K chips. Screen would go somewhere to the top of RAM (last 8K).

Speaking of serial joystick, Nintendo used simple solution in their NES gamepad - it needs just single shift register and three lines: one is to signal parallel load of buttons (up to 8), one is clock for serial shift and the last is data line where you see bits shifted out of shift register.