RAM, RAM, glorious RAM :)

Pacman in a UDG system

The question is at root, do we have 1k RAM or 2k RAM to work with.

We have certain requirements

• Each square on the screen needs a byte to itself.
• Each square on the screen needs a nibble or byte for colour (optional background colour)
• We need some space for RAM based UDGs.

RAM based UDGs allow smooth movement. The ghosts and pacman in the picture are built up from two adjacent squares, if moving along a cell line, or 4 if moving arbitrarily (see the diagram - the A can be moved anywher by just redefining those graphics). For Pacman it actually can use ROM UDGs because the objects move only horizontally or vertically in the maze.

If you look through videos of Vic Games it is usually fairly clear which use this sprite approach, and which just write in a specific cell ; the jumps between cells are clearly visible. Some games (e.g. Gridrunner) covert his up partially by being quick.

So I've come up with the following solutions for consideration. I have no idea what the real one(s) were.

In each "solution" I assume that UDGs are split between RAM and ROM, maybe with 128 UDGs in RAM and 128 in ROM. Note that this does not mean 128 are available, just possible.

I also don't allow for coders requiring some storage, which can be acquired either by sacrificing RAM UDGs or by setting the colour to the same as the background and using the character space.

I also didn't consider partial solutions like, for example, having larger areas all the same colour, a bit like the attribute clash problem in the Spectrum.

Solution 1 (1k)

This actually doesn't pass the requirements as above. I came up with a scenario where the upper 2 bits of the character ID, combined with the border setting, create a varying palette of 4 characters, e.g. a byte is 8 bytes of character ID *and* 2 bytes of colour ID mixed. Also, it has an additional option to make the visible border area black irrespective of what the border colour is set to. The table would be at $8000

This is somewhat messy because colours are all over the place, but does sort of work. I would imagine such has a CGA look to it. 

The advantage is that in 1k it allows a 32x24 character array (768 bytes) and 32 RAM based UDGs (256 bytes). The disadvantage is the messiness and the unpredictable display of the colours. It would give you colour, but not always the colour you wanted.

Solution 2 (1k)

This passes the requirements but only by reducing the screen size to 32x20. This gives 640 bytes for the character array and 320 for the attribute (colour) array by using nibbles for colour (e.g. a monocolour background). This only leaves space for 8 UDG (64 bytes) though. 

This allows a full screen with a tiny number of UDGs. The downside is that full screen is 2/3 of the original and would look a bit small.  One could reduce it further and scale it to fit into the line space in NTSC (smaller than PAL) and have a 32x16 Grid occupying 256 scanlines. This would work but would give rather tall looking characters I suspect.

The character map would be at $8000, the attribute at  $8280 with some tweaking to the address (invert bits 7 and 8) to make the addressing work.

Solution 3 (2k)

This is by far the simplest. A 32x24 screen, 768 bytes for Character, 768 bytes for Attribute (could use Nibbles which would halve it) and 64 RAM UDGs. It

I would put the character table at $8000 and the attribute table at $8400 leaving two 256 byte windows $8300-FF $8700-FF, as this would making mapping between the two tables fairly straightforward.

Option 3 is clearly the best, and considering the small extra cost would be well worth it. It would extend the complexity of the games that could be design considerably ; the other two designs are workable but have too many compromises.

The Six Million Dollar (approximately) question.

 

That question is, what RAM is in this machine ? We already know it is small.

This drives how you access it to generate video ; that I will deal with later on. At the moment I'm looking at money.

I was reading Brian Bagnall's book and it seemed that the purchase price of various Commodore devices  for the user seemed to be about 3 times the cost of actually making the things.

Likewise, I have a vague memory that the cost of a Spectrum was about £45 at the factory, so to speak, which fits in roughly with these sorts of costs.

This gives us a production cost for the LC3 of something like £12-15. Which isn't much.

The strip on the right is a price list of chips in "Electronics Today International" April 1983, taken from Watford Electronics' advert.  Obviously these are you and me prices and there's a saving for bulk purchase.

Looking at Mouser, if I buy a single Z80 it would cost me £7.11. If I bought 1,000 of them, it would cost me £4.03 per item. I'll use this as a price guide. 

Additionally we have a similar component cost (RAM + ROM + ULA + Z80 + bits) to a ZX81 as a kit, so it's going to be slightly less than that, though of course we have no keyboard or manual but a sheet like the calculators but we have to add on the costs of building the thing.

Main CPU

So we know a Z80 is needed. In the Watford advert, a Z80A is going for £3, so we'll cost that at £2.00

Uncommitted Logic Array

In the Wikipedia Gate Array article it says "Ferranti introduced in 1982 a computer-aided design tool for their uncommitted logic array (ULA) product called ULA Designer. Although costing £46,500 to acquire, this tool promised to deliver reduced costs of around £5,000 per design plus manufacturing costs of £1-2 per chip in high volumes,"

Probably volume wouldn't be initially that high, so maybe £2 for the ULA.

System ROM

Jim Drew wrote in a forum posts regarding this question " EEPROMs of this size didn't exist back in the early to mid 80's. We were all using EPROMs (UV erased) or OTP ROMs for production runs. OTP ROMs were 1/2 the price of EEPROMs, and masked ROMs were 1/2 the price of OTP ROMs."

If that's correct, and there's a ROM in it with the "Operating System" then that could be a 2716 (£2.25) or perhaps a 2764 (£4.25), giving again another £2 or so to the cost.

RAM Memory

There's various options for RAM, most of which are on the advert. All prices are those prices so halve them or thereabouts.

• 1k SRAM as 2x2114 = £1.90 (say £0.95)
• 2k SRAM as 1x6116 = £3.50 (say £1.75)
• 4k DRAM as 8x4027 = £15.20 (say £7.60)
• 16k DRAM as 8x4116 = £6.80 (say £3.40)

I did consider the option of using a 8k RAM chip but these didn't appear until mid 1984 and were also relatively expensive. 

One can discount the 4027s immediately. 

On paper the DRAM looks tempting, but the design is full of 'minimum RAM' statements. Obviously it's small compared to a 48k Spectrum, but given how much of that would be used for non-variant code and the console is meant to be driven by cartridges it's quite a reasonable chunk. 

That leaves us with 2 options. A pair of 2114s at £0.95, or a single 6116 at £1.75.

We already have, maybe £6 of ICs, plus the usual plugs, sockets, PCB, case and so on. Two choices, one double the other but costing double the price.

The next article will deal with this choice. 

Note: One option this does not consider is the "duff RAM chip" Spectrum design. I did find a note that states "They only appeared for a very short time around '80/'81" and the general consensus of opinion is this is a one-off.

What can we assume ?

One thing we know about Sinclair is there was quite a lot of recycling.  The ZX80 BASIC is the classic example. IME, this 4k ROM is a work of genius - display driver, BASIC, tape I/O all on ROM and somehow managing to provide a useable programmable machine in 1k of RAM. 

Then we had the ZX81 which is much the same with floating point added.

Then we had the Spectrum, which has (I think) much of the same code, which is why it is so jaw droppingly slow. The original's purpose wasn't to be quick ; it was to make efficient use of space. It's significantly slower than comparable machines of the era.

With this in mind, I'm going to start making some assumptions. Any comments anyone has on these are appreciated.

The CPU is clocked as 3.5Mhz, and the display is 32 characters across.

These two are indelibly linked. The pixel clock on a Spectrum is 7Mhz, which is why the Speccy is clocked at 3.5Mhz. 

I don't know the 32 characters it just seems logically consistent. The machine most like the LC3 AFAICS is the Vic 20, which is 22x23 and it does look a bit chunky and elongated.

I also wondered about the timing, as each block of 8 pixels requires 3 reads (character#, pixels and colour), but the Vic 20 does this easily enough. I recall when reading Bagnall's book that a major problem in producing the 40 column VIC they were considering was memory speed. But I found that the speed of the Vic's SRAM chips is quite slow (about 300ns access time), the LC3 being a couple of years ahead.

The ROM and cartridges occupy the first 32k of memory space. The rest is RAM or RAM expansion space.

I don't know this. There has to be a split point somewhere. Being a Z80, it resets from zero, and all the vectors are there. A few smart machines do allow this to be switched around, but I seriously doubt this is one of them. So half way seems as good as any and it would be easy enough to change. The most likely alternate is $C000, which gives up to 48k for program ROM ; the downside is that for the BASIC you are then limited to 16k.

Other hardware is standard Speccy stuff. Joystick, Sound, Tape I/O and the Border latch.

Much of the hardware could be just copied straight from port $FE. The tape interface is a few resistors and capacitors and a diode, and it worked well enough, not brilliant but okay.  Code exists to read/write to tape that is well tested. (as long as you don't write square roots).

The sound is just an add on to that.  And this is an argument against having the tape I/O in the BASIC cartridge, because the console would have to beep as a bare minimum.

I'm not so sure about this, it depends on how much space there is in the ULA. The alternatives - a D/A converter would take up too much processor time,perhaps and a hardware implementation like in the Vic 20 isn't complicated but takes up ULA space. And developers know how to make the beeper beep.

Finally, the input. Nobody mentions this anywhere but presumably there's some sort of joystick port. Games would be a bit boring otherwise. (It might improve "The Great Space Race")

Why not use the port that everyone already knows, the Sinclair Joystick port that was in the Interface 2 and is directly connected to keys 1-5 on the keyboard (which does not exist...) - there were at that time a vast number of alternative joystick devices you could buy. 

So while I'm at it I might as well keep the border bits as well.  

Finally a Frame Sync (50Hz) Interrupt on IRQ using IM1.

What we know ?

 So what do we know. Well, not much, in the github there's a list of what I could find out, and really it's pretty minimal. 

Some of it is clearly not true or metaphorical, especially.

1) The two chip solution. You might get it down to 3 ; a RAM chip, the Z80 and the ULA (by not having the inbuilt ROM and putting it on each cartridge - depends how big it is). 

Technology in 1983 didn't allow a two chip solution. ULAs didn't have enough RAM on it. RAM is the main driver of this design. 

I'm guessing Sir Clive was referring generically here to 'big chips' ?

2) The multitasking in 100 T-States. You could do task switching with the control of switching given to the Z80 in this, so say use RST8 when you want to yield, but you can't do real multitasking switches this quickly unless you don't use half the registers.

Why ? Well a Z80 has to save the following registers : AF AF' BC BC' DE DE' HL HL' IX and IY. that's by my counting 10 register pairs. The quickest way of writing these to memory is to push them on a stack, which takes 11 T-States or 15 T-States for IX and IY, so to save all of these and not do anything else is 11x8+15x2 = 88+30 = 118 T-States. Then you have to load the new state in, which  is another 118 T-States, then there's a couple of EXX and EX AF,'AF required. Then there's the saving and loading of the SP, and figuring out the next task. 

You can cheat ; you can store AF BC DE HL in the alternate set very fast, and then use them, but that means you can't use the alternate set and only have two tasks. If you task switch manually you can make preserving the state the applications job, or only guarantee AF BC DE HL

(Have I missed something obvious ?)

I'm not quite sure I see the point of this either. This is meant to be a cheap game console. I doubt things like the NES and Master System and any other consoles of the time multi tasked, and when they did it would be game specific. 

If I was bashing the price down, I'd have no OS at all (like the NES) which saves you the cost of putting the ROM in the unit ;  is there so much common code that you can justify giving the machine an Operating System permanently. 

There's a similar question over the tape interface. Given the "BASIC module" is a seperate sell, like the Intellivision or several other machines of that era, it would be cheaper to put the tape I/O hardware on the BASIC module. I'd actually have it cascading, so the BASIC module has it's own cartridge slot, because assuming minimal RAM on the LC3, which it states repeatedly, a BASIC cart will need some RAM in it to store programs in.

Welcome to the Sinclair LC3

Artists impression of the LC3

The Sinclair LC3 is an unreleased prototype produced post Spectrum. The plan was to produce a rock bottom price machine - even compared to the Spectrum. Hence "Low Cost Colour Computer" 

It did exist - there seems to be little question of this (unlike Loki / SuperSpectrum) probably as a breadboard design or maybe a little further.

The picture shows what it was thought to look like, basically a microdrive cartridge (probably slightly bigger as it would barely fit in a microdrive) with a slot in the front for a cartridge.

The image is courtesy of the excellent "Lairds Lair" youtube channel, there is a video about this machine here.  Another good article is in the Register.

I have contacted (or tried to) Martin Brennan and Steve Berry with some ideas and specific questions. I suspect they get a fair few regarding Sinclair machines, but they are more vagaries like "send me anything you have". To date, neither have replied ; both are busy men and as I said probably get pestered a lot.

You never know though. I did this with the Microvision, with the same sort of idea - I had more information for that - the CPU (TMS1100/Intel8021) and the Harris LCD chip ; Dan Boris had already worked out the PCB. So I'm merrily coding away, and I get contacted by decap wizard Sean Riddle saying he's got some ROM dumps of Microvision cartridges. So it went from a theoretical project to a real one running real code. 

One thing I've learnt doing this for 25 years is, if you don't ask you don't get, and sometimes what you *do* get is amazing. That's a story for a later date .... but a hell of a story.

To start with, I will look at what is known, what is claimed, what might be, and what we can guess at (in an educated fashion....)