ZX Spectrum graphics magic
zxonline.net
zxonline.net
(1) the 48k Speccy had a total of ..96KiB of memory: 16KiB of "proper" DRAM, 16KiB of ROM for its BASIC and ..64KiB of DRAM of which half of was non-functional! Sinclair was buying broken memory chips and binning them to get sets whose either the top or the bottom 32KiB worked. They could get these chips for way cheaper. Each machine would have a jumper to select either the top or the bottom 32KiB working region.
(2) Both the "graphics card" chip (the ULA, or Uncommitted Logic Array, an early form of an FPGA) and the Z80 CPU needed to read from memory. Instead of having multiplexers, the ZX Spectrum just connected the two address buses with resistors, such that the ULA would overpower the Z80 if both tried to set an address to read from. The CPU was completely unaware of this: the ULA would ..freeze its clock signal for a few clock cycles, do its thing, and then let the CPU continue with its read. It was actually slower to read from a specific region of RAM that contained the framebuffer because of this.
(3) the article describes the weird out-of-order memory layout for the screen. The reason it was done this way was because of the 4116 DRAM chips the machine was using. These were 16,384 (2^14) 1-bit memories, arranged in 2^7 rows and 2^7 columns. To address a random location, one would need to first clock in the 7-bit row, followed by clocking in the 7-bit column. If you wanted to access consecutive memory locations with the same row address, the chips had a "fast page mode", where you would only need to clock in the next 7-bit column address. The memory was laid out in such a way that would minimize row address settings.
Hacks, all the way down to the core.
Graphics often looked a little weird, because of the hard limit of one color 'palette' (1 ink color and 1 paper color) per 8x8 pixel grid.
However, if you had cycles to spare, there was a cool hack that allowed one palette for each 8x1 pixel slice. By synchronizing with the ULA, you could overwrite the attribute row at each horizontal blanking interval.
The only time you'd have cycles to spare, of course, is when you weren't doing anything else whatsoever. But it made for pretty "press any key" welcome screens.
I remember a game that had a welcome screen which had matching stripes on the real screen and then drew some pixel patterns on it to create an illusion of drawing individual pixels on the border.
So, did anybody mod the machine by replacing the chips by working ones and making that jumper software-controllable to get 16 + 2 × 32 = 80KiB of RAM?
I googled for that, but couldn’t find it.
Well, I mean, in a way, yes, but that's an uncharitable way to consider it, IHMO. It's a bit like saying "the entire Unix architecture was a series of hacks to make a multiuser OS run in 8 kilowords of memory and 1MB of disk."
I mean, it sort of is, but it's also a very negative way to assess it.
As a former Spectrum 48 owner, I saw it more as inspired ways to get a colour computer with primitive sound for under £175, when the American equivalent in market positioning, an Apple II, was equivalent to in the region of £1750.
> 64KiB of DRAM of which half of was non-functional!
Only some of them, AIUI. Also an inspired way to get around low yields at the time. Allegedly the Intel 486SX was a similar hack: got a 486DX with a working integer unit but broken FPU? Call it an SX and sell it anyway!
This is also how CPU speed binning works. Test one -> can it do max speed? -> yes, mark the whole batch for that speed; no -> test them slower, and remark as slower.
Thus the Pentium 60 and 66... then 90 and 100... then 120 and 133.
> the weird out-of-order memory layout for the screen
Quite possibly inspired by similar hacks by Wozniak in the Apple I and II.
Compare the Amiga, using the graphics chipset to drive the floppy drive. Pros: cheaper and more storage. Cons: nothing else can read the disks.
A good discussion about the setup for Manic Miner by the author is here:
Did not know English, could not read anything, but still spent hundreds of hours first playing, and then tinkering with it.
There was no OS to mess up, and it booted instantly to a Sinclair BASIC prompt.
Ironically, the BASIC + Assembly combo continues to this day, even if done in different tongues.
So I switched to HiSoft Pascal and line and circle became instantaneous but still I didn't dare program Tetris in graphics mode. So I used text/character mode, compiled from Pascal and was fast enough to play. (In regular BASIC, I couldn't make it work).
Then I installed HiSoft BASIC compiler and my regular BASIC was now fast enough for TETRIS. On the other hand if you think that in 48Kb of RAM they had to fit the video RAM about 8 Kb, the BASIC compiler, my BASIC code, the compiled code and use some RAM for stack and variables ... crazy. Fun times...
I had a Spectrum, and then when the QL got relatively cheap, I got one too. Loved 68K assembly.
Given that the 68K instructions were always a multiple of 2 bytes, in its 48K ROM you could have a maximum of 24576 instructions. Now remove the space needed for the bitmap font and some lookup tables, and in the remaining space you had:
- A multitasking operating system (no memory protection, of course), with networking (not TCP/IP of course) and media (microdrive) management, and generic channels kind of in the Unix file spirit
- A (non-re-entrant, single instance) “SuperBASIC” with procedures and functions with LOCal variables, a switch construct (SELect ON), FOR loops with epilogues that would run if not broken out of the loop, and other goodies, which SuperBASIC was also the system shell
- A collection of system calls and a system library, from windowing functions to software floating point (the 40-bit format) operations
Not having a lot of money for software but with the help of some book from the library (titled something like Assembly Programming on the Sinclair QL, don't remember exactly) I even wrote a disassembler in SuperBASIC to decode and grok the ROM. My mind was blown with the density of the ROM code.
I had to mention this when I learned of Daniel J. Bernstein advocating, almost 20 years after QDOS, non-blocking nonblock_read()/nonblock_write() additions to the POSIX model, so that your I/O model wasn't something that you had to coördinate and share with every process that might have the same open file descriptor.
* https://jdebp.uk/FGA/dont-set-shared-file-descriptors-to-non...
There were all sorts of little innovations in the operating systems world back then. Helios was another interesting one, with capabilities.
Other computers of the time (C64, Apple II, BBC / Acorn) had distinct text vs graphics modes, although some had a user-defined font which kind of makes the distinction less firm.
But the spectrum only had a graphics mode.
I recently ported my teaching raytracer to the Spectrum [0], not even using assembler, but the horribly slow native BASIC. It was a ton of fun! It's super slow especially when run on the original hardware, but even then I can't remember something like this from back in the day (and I'd bet something like Microhobby would have listed this as some kind of curiosity); makes me think the Spectrum's limitations weren't even fully explored. Raytracing people were probably working on beefier machines and more serious projects.
https://bizzley.42web.io/assets/it_s_behind_you___the_making...
But that's very different from working in a properly commented and 'macro-assisted' Z80 or 6502 assembly code base.
Well, we didn't have Visual Studio Code, and we couldn't summon Claude to help us through the tricky bits. We used whatever tools were available and a LOT of trial and error in order to master the machine. Because computers were amazing, and having one on your desk you could play with was even more amazing.
I didn't have a Spectrum, because I'm a bloody Yank. I had a VIC-20 and later a TI-99/4A. In the States we had Apple, IBM, Tandy, TI, and Commodore, with Apple pretty much the dominant force in home computing until PCs got cheap enough. Everybody else was pretty niche, so even when affordable computers came out -- like the Timex Sinclair and Timex Sinclair 2068 (which was based on, but not broadly compatible with the Spectrum), there wasn't a huge library of software nor a large programmer/hobbyist community like there was with the Spectrum in the UK. The "bedroom coder" phenomenon was still a thing, but I think the wide availability and low price of the Spectrum enabled more Brits from a variety of backgrounds and socioeconomic strata to become "bedroom coders" than Americans, for whom home computers were pretty much expensive toys.
I had one and it came with a spectrum 48K emulator cartridge that was pretty good but had a bug in the graphics emulation.
The keyboard was much better.
His book is well worth a read: https://bizzley.42web.io/?i=1
POKE 23641,194
RUN
does on zx spectrum. And you get different patterns for different values, say 197. And wait for a minute or so to see something even more interesting.
The two bytes at that address and the one following are used by the BASIC ROM to track the command you're typing in, so maybe an artifact of how the ROM works?
I'm sure this is a BASIC ROM artifact. Would require disassembling the ROM to see what's going on and it's a bit too early in the morning for that :-) EDIT: See flohofwoe's much better answer.
http://www.primrosebank.net/computers/zxspectrum/docs/Comple...
The Spectrum ROM is a wonderful program. The numerical evaluation system was unique. Every number could be replaced by an expression.
https://floooh.github.io/tiny8bit/zx-ui.html?type=zx128
...you can open the step debugger after entering the command (in the menu "Debug => CPU Debugger") and see that execution is caught in an LDDR (reverse block copy) which essentially overwrites the entire RAM, and then gets caught in a loop which causes it to return to that LDDR.
The poke address 23641 is probably some state variable of the BASIC interpreter and by writing to it you're messing up the state in a way that a RUN jumps into a specific place in the ROM which happens to run that LDDR.
Yes, it's the least significant byte of "E LINE Address of command being typed in" in the scratch area: https://worldofspectrum.org/ZXBasicManual/zxmanchap25.html It's cool that they documented all that stuff in the manual!
Write a simple program to make the Spectrum display the "Scroll?" message and then press Capslock and symbol shift together, then press any letter.
The screen fills up with various words. Any insights?
Big nostalgia for that era. Everything was limited, but everything seemed possible.
What got me into computers was:
A = 1; B = 5; C = A+B : C= 6
But:
A = "firstname"; B = "lastname"; C = A+B : C="firstnamelastname".
I dont know why but I still remember the revelation.
MD content is not available