nav search
Data Centre Software Security DevOps Business Personal Tech Science Emergent Tech Bootnotes
BOFH
Lectures

back to article
ZX Spectrum reboot latest: Some Vega+s arrive, Sky pulls plug, Clive drops ball

Anonymous Coward

As with all these cases, eveyone out for themselves, the customer comes last

Shame on all involved.

24
0

Re: As with all these cases, eveyone out for themselves, the customer comes last

define "everyone". There's a bunch of names in that story, and I don't believe it applies to all of them.

3
3
Silver badge

Re: As with all these cases, eveyone out for themselves, the customer comes last

Caveat emptor? The successful legal challenge against Indiegogos "orders" not withstanding presumably all the "customers" knew what they were getting into by using a crowdfunding site?

I feel sorry for them - but tempered by the fact no-one can claim they didn't know what they were getting into.

12
0
Silver badge

Re: As with all these cases, eveyone out for themselves, the customer comes last

Crowd funding proves not only can get you millennials to work for cheap with no benefits by calling something sharing but you can get them to pony up the venture capital as well without having to deal with pesky things like having to give out company shares for the cash.

8
1
Silver badge

Re: As with all these cases, eveyone out for themselves, the customer comes last

Crowd funding is often successful in getting stuff made that there isn't necessarily a big enough market to sustain a product, but enough people that would want one that would not be able to get one otherwise.

It has its place.

3
0
Silver badge

Re: As with all these cases, eveyone out for themselves, the customer comes last

The phrase "A fool and his money are soon parted" proved correct once again. Hopefully some of the suckers who invested in this have learnt a valuable lesson - ie that the laws of good financial governance arn't put on hold just because the money is being raised on some trendy hipster crowd funding site.

0
1
Silver badge

Re: As with all these cases, eveyone out for themselves, the customer comes last

>It has its place.

Perhaps but the wonderful thing about this capitalist wonderland is there are plenty of tangible easy to buy things I can find to spend my money on to entertain myself today instead of pie in the sky stuff in the future on a wing and a prayer. More power to others to spend their money how they wish but Gen Xers like me are big on money in the bank (we tend to save like our grandparents not our less responsible parents generation) or in viable sensible investments with a track record of delivering. Idealism isn't always high on the list. But sure go on change the world. YOLO.

0
0
Silver badge

Re: As with all these cases, eveyone out for themselves, the customer comes last

Change the world? Who is claiming that?

I've backed several things via Kickstarter and IndieGogo and in every case I've received something excellent, interesting and useful that I would not have otherwise had. By using simple diligence (it's not hard), I haven't been involved with a single failure or financial loss and in all cases I've enjoyed watching the process of getting the item to the backer over the months. Because most projects that get fully funded, actually get delivered. You only read about the failures and it creates the false impression.

It's not a big deal and it's not a scary big nasty bogey picker that frightens genxers who were happy to blow cash on smoking, rainy holidays, and drinking shit beer for years on end whilst stinking of Brut 33 and Old Spice. That old generation that ran up debt paying through the nose for shit from the catalogue and countless K-Tel and Ronco eternal drawer-dwelling tat.

1
0

Re: As with all these cases, eveyone out for themselves, the customer comes last

Crowd funding is not all bad. I've seen some genuinely good products on various crowdfunding sites (e.g. the Pebble watches, which were bloody good). The trouble is, it's a lot easier to come up with an idea, and build a prototype than it is to manufacture something. This is the trouble Tesla are having with the Model 3, and they are experienced at manufacturing. A company may have a load of good designers and engineers, but how much manufacturing experience do they have? Even if they outsource the manufacturing (which I believe RCL have), they still need engineers who can predict the problems the factory is likely to have and come up with solutions.

Then there are the shysters who set up a crowd funding campaign looking to vanish with the money. After all, it's relatively cheap to set up a convincing looking site, and come up with an impressive video to sell your project, and you could get away with millions..

0
0
Silver badge

It looks a bit... "cheap"

As title, insert appropriate four letter word as applicable

25
0
Silver badge

Re: It looks a bit... "cheap"

Watching the reviews on YT only make it worse...

Damage from build and construction, really bad control quality - stiff and with no tactile feedback, constant crashes on menu screens, paper logo under the screen cover, the list goes on...

19
0

This post has been deleted by its author

Silver badge

Re: It looks a bit... "cheap"

If I remember correctly, the original ZX80 not only refreshed its dynamic memory in software, but had stripes painted on the back that gave the impression of having cooling vents where none were in fact present. Compared with its family heritage, it looks positively upmarket.

16
4
Silver badge

Re: It looks a bit... "cheap"

The ZX80 fetches its display in software, but contains only static RAM.

Rather than bother with all that nonsense of counters and whatever for fetching video, the processor just executes the display buffer. Well, it tries to, but the parasitic video steals the opcodes it is actually fetching and forces a NOP onwards. That gives the character code, and hijacking of the Z80's refresh cycle gives it a chance to get the actual pixels for that row of that character.

So most of what the Z80 in a ZX80 is doing is executing NOPs.

17
0
Silver badge

Re: It looks a bit... "cheap"

This is the most thorough review I've found so far.

So, rather glad I decided not to go for it.

2
0
Silver badge

Re: It looks a bit... "cheap"

"So most of what the Z80 in a ZX80 is doing is executing NOPs."

Even for its day the ZX80 was a pretty nasty design when compared to the Apple II, TRS-80, PET or other 8 bit computers that had come out a few years before. If it had been dirt cheap that would have been fine but it wasn't, it was actually quite expensive at 100 quid assembled which is probably equivalent to 300-400 quid or more now.

1
2
Silver badge

Re: It looks a bit... "cheap"

And what was the price of the Apple II, TRS-80, and PET?

5
0
Coat

German tank problem

Did they use the German tank problem approach for the serial numbers?

26
0
Silver badge

Re: German tank problem

I hope so. That's a wonderful bit of maths.

13
0

What we need

is someone to do a BBC Micro reboot. Then we can revive those old Z80 vs 6502 arguments that took up so many lunch breaks at school. Silly really - the 6502 was always faster.

40
3
Silver badge

Re: What we need

Faster at the same clock rate, but slower at the C64's ~1Mhz than at the Spectrum's ~3.58Mhz, which is most of what mattered.

20
1
Silver badge

Re: What we need

Why? The originals are still going strong. I've got three of them, plus a cheese wedge co-pro, so I can play Elite Executive Edition :-)

There was also an Arm 1 cheese wedge that went on fleabay a year or two ago, for a little over four grand.

Mine can also read a FAT 32 USB stick and has compact flash cards that mimick winchester drives, courtesy of Retro Computers. Nip over to StarDot - https://stardot.org.uk/forums/ - for BBC goodness :-)

18
0
Silver badge

Re: What we need

Faster at what? The Z80 had some more sophisticated instructions, such as LDIR which the 6502 doesn't have. So, if the 6502 was faster, the Z80 was certainly more memory efficient - you could do more per instruction on a Z80 than a 6502. And only putting three registers on the 6502 was just dumbfuckery of the highest order. Shame on Peddle!

9
10

Re: What we need

Wow. That went better than I expected.

Next up Shimano is better than Campag, vi is better than Emacs ....

46
1
Silver badge

Re: What we need

And only putting three registers on the 6502 was just dumbfuckery of the highest order.

It's my understanding that the 6502's original target market was controlling microwave ovens, for which its capabilities (notably the 256-byte machine stack) are just fine.

But yeah, the Z-80 was a far more sophisticated processor than the 6502. If you compare it to a 6809, well, them's fightin' words...

18
0

Re: What we need

@Herring'

Interested in your thoughts regarding Betamax v VHS . . . .

36
0

Re: What we need

Remember how popular the original Microchip PICs were, despite subroutines only being allowed in lower pages and memory segmentation pointer.

4
0
Silver badge

Re: What we need

Interested in your thoughts regarding Betamax v VHS

Video 2000

I contracted for a while at Pye TVT in Cambridge (working on a TV video effects console for the 1986 World Cup). Pye was a subsidiary of Philips, and there was a factory shop. Lots of employees, contractors and their friends and families ended up with Video 2000 recorders. Rumour had it that e.g. Dixons allocated the cassettes equally to all shops, and the manager of the Cambridge branch spent a lot of time on the phone talking to other branches to get their spare stock sent to him.

Getting back on topic, I also worked on the Acorn Archimedes and the Sinclair QL.

27
0

Re: What we need

As far as I'm aware, for a 6502 of given clock speed, you could expect broadly equivalent performance from a Z80 clocked at double that speed or slightly more.

In other words, the Atari 800's 1.79 MHz 6502 would have been roughtly equivalent to the Spectrum's 3.5 GHz Z80 (#), the BBC Micro's 2 MHz 6502 a little faster... and the C64's 1 MHz 6502 was still on the slow side.

(#) Though the Atari's custom graphics hardware (including hardware scrolling, hardware sprites and multicolour character-based modes) meant that it didn't have to inefficiently use CPU cycles on certain things that the simpler Spectrum would have needed to.

12
0

Re: What we need

is someone to do a BBC Micro reboot.

It should be done at Raspberry Pi 3 IMHO. Open, DIY project. No silly IGG scams anymore.

@Z80 vs 6502:

Z80@Amstrad != Z80@Speccy; Only few specific games could run faster / equivalent at Speccy, compared to C64 etc (6502/6510); e.g. those based on Freescape / 3D Construction Kit iirc.

Compare it to the Novagen's Encounter @ C64 or Atari 8-bit.

Uridium? Speccy does not have VIC-II (hardware scrolling, sprites etc). Impossible. Spectrum version has 20FPS compared to the 50Hz update of the original.

However, isometric games @Speccy becomes that nice touch / genre, those 2,5 D graphics looks nicer and plays smoother (then at C64), although technically inferior.

BUT: Z80 version at Amstrad (Schneider) is totally different story. It is just faster/stronger machine.

7
0

Re: What we need

I should also add that the 6809 was apparently superior to both... but unfortunately let down by being paired with uninspiring supporting hardware in its most famous applications. (The Tandy CoCo and its near-clone, the Dragon 32 both featured the same dated graphics chip as the Acorn Atom and the sound was similarly limited.)

14
0
Silver badge

Re: What we need @DrBed

The Z80 in the Spectrum is not only nominally clocked at 3.58Mhz but also genuinely runs at that speed for as long as you avoid the physical chips that are shared with the ULA. E.g. on a 48kb Spectrum that means that as long as your code is in the top 32kb of RAM rather than the bottom 16kb.

The CPC is nominally clocked at 4Mhz but via use of the WAIT line permits a Z80 memory access on only one in every four cycles, regardless of what you're accessing. The standard fetch cycle is four cycles long, so single-byte instructions that don't cause a memory access run without a speed penalty (once you're in phase, anyway) but everything else is subject to delays. As a result code often ends up running more slowly than it would on a ZX Spectrum.

It depends how often the Spectrum code is seeking to update the display though, obviously. And the CPC's main problem isn't this clocking scheme or that one, it's the annoying large percentage of titles that are so lazy as just to be the Spectrum code plus some extra work at the end to translate the Spectrum graphics to anything that looks sort of right. It's almost a revelation every time you load a game that was converted properly, like Chase HQ, Robocop or Gryzor.

9
0

Re: What we need

It's a long time ago now, but, IIRC, one big difference between the 6502 and Z80 was that the 6502 was pipelined, but the Z80 wasn't, so even a NOP took four clock cycles on the Z80.

5
0
Silver badge

Re: What we need @/dev/null

A NOP takes four cycles because there's no memory bandwidth to fetch anything else until four cycles later; the Z80 spent two cycles fetching the NOP opcode, then decoded and performed it during the two cycles when it was issuing a DRAM refresh. As soon as the refresh ends it can seek out the next thing. That's why it's also four cycles for all the other single-byte instructions that don't imply any other accesses to memory — register-to-register arithmetic and moves, and a few others.

7
0
Silver badge

Re: What we need

If you're desperate to recreate the Beeb experience, there's a stripped-down version of RISC OS (i.e. just BBC Basic) available for the RasPi:

https://www.riscosopen.org/content/sales/risc-os-pico

Direct link to the file: http://packages.riscosopen.org/RISC-OS_Pico.zip

6
0
Silver badge
Happy

Re: What we need

Interested in your thoughts regarding Betamax v VHS . . . .

U-matic.

13
0

Re: What we need

I should also add that- although I'm far less familiar with the C64 than the Atari 800- as far as I'm aware, the former also benefits from custom hardware scrolling, hardware sprites and character-based graphics that allow it to outperform (e.g.) the Spectrum on most games despite its slower CPU.

Unless it's a CPU intensive game that doesn't benefit from such features (e.g. 3D games) in which case it'll suffer.

5
0
Silver badge

Re: What we need

> vi is better than Emac

Different category: that's not even open for debate.

9
3
Anonymous Coward

Re: What we need

U-what?

1
2
Silver badge
Flame

Re: What we need

Obviously emacs is better than vi.

4
5

Re: What we need

"Wow. That went better than I expected.

Next up Shimano is better than Campag, vi is better than Emacs ...."

Don't be absurd. Shimano is far better than EMACS.

22
0
Silver badge

Re: What we need

The 6502 and Z80 clock issue is really a precursor to the great RISC vs. CISC debate.

Generally, the 6502 would execute each instruction in about 2 clock cycles, although there were a few that only needed one. The Z80 required between 4 and 13 clock cycles per instruction depending on what the instruction was (this is from memory), so although it generally had a faster clock speed, and more sophisticated instructions, for many of the simpler operations that these processors typically ran, the 2MHz 6502 in the BBC performed tasks faster than the 3.75 MHz in a Spectrum.

The memory access was also more simple for 6502, which enabled it to work with slower memory than the Z80, mainly because memory and CPU clock speeds were linked together.

For complex workloads, the Z80 could run rings around a 6502, but in order to do that, you would need to have work that needed 16 bit registers, and used the complex instructions to their maximum benefit.

The Z80 was more memory efficient (so long as you used all of the instructions) although clever use of the indexed addressing modes of the 6502 could save memory, and allowed you to use zero page memory almost as registers on a 6502, negating some of the benefit of the Z80's more generous register set. The Z80 also had the basic support for bank-switched memory and port driven I/O, neither of which the 6502 had.

It's also worth remembering that processors of this age executed instructions strictly in the sequence they were written, with no overlapping or super-scalar execution, and all memory read and writes went strictly to the RAM, no caching or pre-fetich of instructions or data.

So the Z80 was a more sophisticated processor, but not necessarily a faster one than the 6502.

18
0
Silver badge

Re: What we need @PeterGathercole

I think you're off by one; the shortest 6502 instructions take two cycles, and the most common ones — those which read from or write to the zero page — take three.

But the issue in a real machine is that a 6502 uses only half a clock cycle to perform an entire memory access whereas the Z80 uses at least two. So pick your clock speed as a function of those constraints and your memory speed.

7
0

This post has been deleted by its author

Re: What we need

The C64 also benefited from the SID audio synth-on-a-chip. Unlike "chip music" from other 8-bit micros which typically waggled a DAC around to make PWM noise, the C64 was actually playing music on a viable musical instrument via simple digital registers. The most notable technical thing about it is that once you started playing a note, you didn't have to tie up the CPU to keep on playing it; ... like you did on the Speccy. Another reason why Spectrum games tended not to have in-game music but C64 games did.

Another aside: the SID was used in a couple of real synths; although their makers were always desperate for supply.

The "my CPU is better than your CPU" debate is really irrelevant when your CPU is doing everything and mine is just asking other parts of the architecture to do stuff. The same applies to Firewire vs USB.

12
1

Re: What we need

> "Obviously emacs is better than vi."

Well, it's certainly more fully-featured. About the only thing it lacks is a decent text editor...

24
0
Silver badge

Re: What we need @cream wobbly

I'm not sure it's accurate to say that other micros typically had to live-toggle a bit. Of the successful ones I'm pretty sure that's only the Apple II and the 16/48kb Spectrum.

None of them is a match for the feature set of the SID, but the 128kb Spectrum and CPC share the AY which is three channels of square wave and/or noise with volume envelopes; the 8-bit Atari has the POKEY which is four channels of more-or-less square wave; the BBC has an SN76489 which is three square waves plus a noise channel, etc.

The SID's killer feature is phase accumulation for pitch selection rather than simple division, giving much finer control — in a SID there's a 24-bit counter, the top few bits of which are used to form the output level, and an amount that is added to it at each cycle. Plus some analogue filters. On the other chips there is the input clock and then there is an integral divider. So you're controlling the reciprocal of pitch, reducing useful precision.

Nevertheless, the other chips don't require active CPU participation as the 48kb Spectrum does, and the musical opportunities are still fairly decent.

5
0

Re: What we need

> cream wobbly; "The C64 also benefited from the SID audio synth-on-a-chip. Unlike "chip music" from other 8-bit micros which typically waggled a DAC around to make PWM noise"

(Edit:- @ThomH; If I'd refreshed the page before posting this, I'd have seen that you'd already made much the same point in your reply!)

That's true as far as the original (pre-128K) Spectrum goes- along with some other machines (IIRC the Apple II and Dragon 32). However, it's far from accurate to imply that DAC waggling was "typical" of the majority of 8-bit computers.

Many had separate sound chips:-

- The Atari 800 (which came out in 1979) had a four-channel custom chip called POKEY.

- Several 8-bit computers used the Yamaha AY-3-8912 sound chip, including the Amstrad CPC, the Spectrum 128 (though admittedly that came later on), the Oric-1 and Atmos, and MSX.

- Several more used the Texas Instruments SN76489, including their own TI-99/4A, the BBC Micro and the Coleco Adam (and the ColecoVision console it was based on)

Others had sound generation integrated into multi-function custom chips:-

- Commodore's own VIC 20 (i.e. the direct predecessor to the C64) already included tone generation facilities as part of the VIC chip

- Similarly, the Commodore 16 and Plus/4 included tone generation within the TED chip

- Even the relatively primitive Atari VCS (admittedly not a personal computer) had two-channel audio generation as part of the TIA chip.

The point here isn't whether or not these were up to the standard of SID. It's that they were separate sound generation facilities that- like the C64's- freed the CPU to do other things.

6
0
Silver badge

Re: What we need

the 2MHz 6502 in the BBC performed tasks faster than the 3.75 MHz in a Spectrum.

The memory access was also more simple for 6502, which enabled it to work with slower memory than the Z80, mainly because memory and CPU clock speeds were linked together.

The BBC had 4Mhz memory multiplexed between the 2Mhz CPU and the video display, so the CPU always never had to wait to access the memory.

The Electron on the other hand had the same 2Mhz CPU but used a contended memory model (similar to the Spectrum). When the video output needed to access the memory, the CPU was paused. On the Electron this meant the machine was pretty slow, far slower than BBC and slower the Spectrum. Unlike the Spectrum, it had no uncontended RAM area.

5
0

Re: What we need

And don't forget that massive 6502 stack - a whopping 256 bytes.....

3
0

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

The Register - Independent news and views for the tech community. Part of Situation Publishing