10 ms·

The Spectrum used the CPU and the ULA for everything. This resulted in a cheaper price for the machine. Meanwhile the BBC had actual hardware. As an example a s

The Spectrum used the CPU and the ULA for everything. This resulted in a cheaper price for the machine. Meanwhile the BBC had actual hardware. As an example a simple beep would tie up CPU cycles on the Spectrum whereas the BBC micro could define a sound envelope for something more than a beep and hand that off to the AY-8192 sound chip. The Z80 had plenty of features that the BBC micro's 6502 did not have, so the code should have been quicker with fewer CPU cycles used and fewer lines of code. But the lack of supporting hardware negated this gain. BBC BASIC was also a more complete implementation of the language. So any code written in BASIC was more efficient just because you didn't have to use your own BASIC workarounds. Being able to drop into assembly language also helped, the Spectrum lacked this option to truly turbo charge your code. The BBC used 16k for BASIC in ROM and had 16k for the OS. This enabled ROMs to be swapped out so you could run BCPL or another ROM, e.g. Fortran. The Spectrum had BASIC and the OS in 16k with 48k available for RAM. The BBC could use more than 32k of RAM if installed, as per the later Master system that used bank switching. I am not familiar with the code but I would be surprised if the BBC Basic ROM was anything less than a work of genius concise code. Every byte counted in those days regardless of what home computer you were programming for.

jlarcombe 6y ago
Yes, also no contention for video memory access on the BBC.
- beagle3 6y ago
  The spectrum also had contention for video memory access; The memory map was: 0->16K: ROM 16K->32K: "Slower" RAM (ULA/Video has preference so may delay CPU) 32K->64K: "Faster" RAM (Same RAM, but nothing other than CPU accesses it)
  - jlarcombe 6y ago
    Yes - that's what I meant - sorry if not clear. BBC ran at full speed all the time (except when interfacing with 1Mhz peripherals). Spectrum clock speed higher but contention for video RAM. Also traditionally the 6502 is regarded as having greater throughout for same clock speed (something to do with the width of the ALU and the complexity of instruction decoding?)
    - beagle3 6y ago
      From my experience (lost of Z80, much lesser 6502, but still some), it's mostly the indirect addressing modes - The Z80 had lousy IX/IY indexed access, and direct HL/DE/BC access. The 6502 had great indirect access through X and Y. So when manipulating memory (which is .. most of the time), The Z80 often needed 3-4 instructions for what the 6502 could do in one. The z80 had more registers and some 16-bit arithmetic.
klelatti 6y ago
BBC Basic was a work of genius (it was written by Sophie Wilson of ARM fame) but not necessarily of concise code. I remember looking at some of the assembly in the 1980s and it was clear that code size was secondary to speed - there was some significant loop unrolling for example. Absolutely agree on the hardware point as Sinclair's real talent was squeezing as much out of basic hardware as possible even at the expense of performance (e.g. CPU driving the screen in ZX80/81). As a commercial decision limiting the ROM to 16k was a very good move in the end for Sinclair. It allowed full colour with 42k of spare RAM whereas the BBC only had c24k after allowing for screen memory, so in the end the Spectrum could support much larger and richer games than the BBC and (later) the Electron.
jhallenworld 6y ago
I recently was curious about the relative performance of the classic CPUs, so I made this table to compare their memcpy performance: https://github.com/jhallen/joes-sandbox/tree/master/classic-cpu https://github.com/jhallen/joes-sandbox/tree/master/classic-...
- klelatti 6y ago
  That's really interesting. Shows that optimising for each CPU presented a different challenge each time. I remember hearing Steve Furber say that they realised that memory bandwidth was the biggest constraint in 8/16 bit CPUs so the ARM1/2 really focused on this and it shows (in fact I think they approached Intel with the idea of commissioning an 8086 with more bandwidth but were turned away - funny how things work out).
- Someone 6y ago
  I think you can speed up the 6502 version by moving it into the zero page and not using indexed mode. Of course, zero page memory is even more restricted than the 64kB you have in total, but that might be worth it in some cases. Even if this isn’t in the zero page, it surprises me that those expensive x indirect loads and stores are cheaper than worth having to increase the source and destination addresses often, but that probably is because my 6502 is very rusty. Also: I stared at that code for a while, but couldn’t figure out why that jmp immer is there. If you move the 3 instructions starting at lastpage to the end, it can be removed, can’t it? (I didn’t check, but there may be further code shuffles that do not decrease the number of instructions, but do decrease the number of branches and with it, the number of cycles spent)
  - jhallenworld 6y ago
    I knew 6502 people would improve it :-) >moving it into the zero page and not using indexed mode I'm not sure I follow.. you mean restrict the memcpy to only within the zero-page? >jmp inner.. Yeah, it doesn't matter to much, not in the inner loop. You could move the start of the code to right after the rts also..
    - 6y ago

jlarcombe 6y ago

Yes, also no contention for video memory access on the BBC.

beagle3 6y ago
The spectrum also had contention for video memory access; The memory map was: 0->16K: ROM 16K->32K: "Slower" RAM (ULA/Video has preference so may delay CPU) 32K->64K: "Faster" RAM (Same RAM, but nothing other than CPU accesses it)
- jlarcombe 6y ago
  Yes - that's what I meant - sorry if not clear. BBC ran at full speed all the time (except when interfacing with 1Mhz peripherals). Spectrum clock speed higher but contention for video RAM. Also traditionally the 6502 is regarded as having greater throughout for same clock speed (something to do with the width of the ALU and the complexity of instruction decoding?)
  - beagle3 6y ago
    From my experience (lost of Z80, much lesser 6502, but still some), it's mostly the indirect addressing modes - The Z80 had lousy IX/IY indexed access, and direct HL/DE/BC access. The 6502 had great indirect access through X and Y. So when manipulating memory (which is .. most of the time), The Z80 often needed 3-4 instructions for what the 6502 could do in one. The z80 had more registers and some 16-bit arithmetic.

klelatti 6y ago

BBC Basic was a work of genius (it was written by Sophie Wilson of ARM fame) but not necessarily of concise code. I remember looking at some of the assembly in the 1980s and it was clear that code size was secondary to speed - there was some significant loop unrolling for example. Absolutely agree on the hardware point as Sinclair's real talent was squeezing as much out of basic hardware as possible even at the expense of performance (e.g. CPU driving the screen in ZX80/81). As a commercial decision limiting the ROM to 16k was a very good move in the end for Sinclair. It allowed full colour with 42k of spare RAM whereas the BBC only had c24k after allowing for screen memory, so in the end the Spectrum could support much larger and richer games than the BBC and (later) the Electron.

jhallenworld 6y ago

I recently was curious about the relative performance of the classic CPUs, so I made this table to compare their memcpy performance: https://github.com/jhallen/joes-sandbox/tree/master/classic-cpu https://github.com/jhallen/joes-sandbox/tree/master/classic-...

klelatti 6y ago
That's really interesting. Shows that optimising for each CPU presented a different challenge each time. I remember hearing Steve Furber say that they realised that memory bandwidth was the biggest constraint in 8/16 bit CPUs so the ARM1/2 really focused on this and it shows (in fact I think they approached Intel with the idea of commissioning an 8086 with more bandwidth but were turned away - funny how things work out).
Someone 6y ago
I think you can speed up the 6502 version by moving it into the zero page and not using indexed mode. Of course, zero page memory is even more restricted than the 64kB you have in total, but that might be worth it in some cases. Even if this isn’t in the zero page, it surprises me that those expensive x indirect loads and stores are cheaper than worth having to increase the source and destination addresses often, but that probably is because my 6502 is very rusty. Also: I stared at that code for a while, but couldn’t figure out why that jmp immer is there. If you move the 3 instructions starting at lastpage to the end, it can be removed, can’t it? (I didn’t check, but there may be further code shuffles that do not decrease the number of instructions, but do decrease the number of branches and with it, the number of cycles spent)
- jhallenworld 6y ago
  I knew 6502 people would improve it :-) >moving it into the zero page and not using indexed mode I'm not sure I follow.. you mean restrict the memcpy to only within the zero-page? >jmp inner.. Yeah, it doesn't matter to much, not in the inner loop. You could move the start of the code to right after the rts also..
  - 6y ago