The Mahler Project – The ZX Spectrum Orchestra [video](youtube.com)
youtube.com
The Mahler Project – The ZX Spectrum Orchestra [video]
https://www.youtube.com/watch?v=LxPXLIALJJI&feature=youtu.be
5 comments
That's probably down to the 128K Spectrums having a slightly faster clock speed than the original 16/48K model (3.5469MHz versus 3.5 exactly). I knew this would cause the timings to drift (hence the need for the RasPi to provide a time source) but I overlooked the effect this would have on pitch...
(On the other hand - since the BEEP routine was being called from BASIC, adding in a pitch adjustment calculation may well have slowed things down enough to throw the timing off again :-) )
(On the other hand - since the BEEP routine was being called from BASIC, adding in a pitch adjustment calculation may well have slowed things down enough to throw the timing off again :-) )
I liked the mistuning. Gave it a lovely, medieval sound.
Are the internals of the project documented anywhere? I'd love to see how you did the synchronisation (and why you had to use that interloping Acornesque Pi instead of another Spectrum as conductor - was it a file server as well?) and see some code...
A purist would doubtless sigh after a Spectrum only network using Interface 1's ZX Net and Microdrives, but (a) life is too short (b) I doubt anyone else would care and (c) I am not that man. :)
Are the internals of the project documented anywhere? I'd love to see how you did the synchronisation (and why you had to use that interloping Acornesque Pi instead of another Spectrum as conductor - was it a file server as well?) and see some code...
A purist would doubtless sigh after a Spectrum only network using Interface 1's ZX Net and Microdrives, but (a) life is too short (b) I doubt anyone else would care and (c) I am not that man. :)
I doubt that's fixable.
The Spectrum's crystal was chosen for low price, not for closely matching performance (even day-to-day on the same host), so matching would require finding the hosts' CPU frequencies at that moment and compensating for the differences. Possible using the Spectronet, hardly easy.
The Spectrum was a great machine. The kind where the only way to get amazing results was amazing programming. There was no hardware to help the CPU — if you wanted to so something, you had to write code. But that's about the only nice thing I can say about the Spectrum. Build quality, suitability as musical instrument, and so on and so forth... nah.
The Spectrum's crystal was chosen for low price, not for closely matching performance (even day-to-day on the same host), so matching would require finding the hosts' CPU frequencies at that moment and compensating for the differences. Possible using the Spectronet, hardly easy.
The Spectrum was a great machine. The kind where the only way to get amazing results was amazing programming. There was no hardware to help the CPU — if you wanted to so something, you had to write code. But that's about the only nice thing I can say about the Spectrum. Build quality, suitability as musical instrument, and so on and so forth... nah.
You're right, the Oric-1 was a much better machine.
> the only nice thing I can say about the Spectrum...
A restart was always a button-press away if you messed something up. (At least the Spectrum+ had a hard reset button on the side). Not to forget that the OS and BASIC environment were in ROM and took a fraction of a second to boot.
A restart was always a button-press away if you messed something up. (At least the Spectrum+ had a hard reset button on the side). Not to forget that the OS and BASIC environment were in ROM and took a fraction of a second to boot.
Yes... it was friendly to budding hackers like myself in many ways. Pretty clearly intended to be a computer, not what another commenter calls "better machine".
In the original Spectrum, there was no reset button. Nor was there a power switch. So if your machine code got stuck, you'd remove the power plug from the jack and put it back in, to get that power-on self test black screen and then a BASIC prompt.
And, eventually, the jack would wear out for those of us who wound up with more bugs than was good for the power jack. Some people actually had to replace the power jack because of this. You can still get those as spare parts, btw. http://www.dataserve-retro.co.uk/contents/en-uk/d7.html
And, eventually, the jack would wear out for those of us who wound up with more bugs than was good for the power jack. Some people actually had to replace the power jack because of this. You can still get those as spare parts, btw. http://www.dataserve-retro.co.uk/contents/en-uk/d7.html
The Z80 has a non-maskable interrupt that jumps to a fixed location in the ROM, so anyone handy with a soldering iron could have wired up a little push-button to the NMI pin to trigger it ... in the Specrum ROM this was supposed to then read an address from a fixed area in the system variables area of RAM and jump to it, except that due to a bug you could only jump to 0, ie a full reset. This always seemed a terrible shame.
Yes, I recall looking at that code in the ROM disassembly and trying to figure out that what the heck is this supposed to mean.
Another nice thing to say was that the CPU was clocked balzingly fast for the time period.
Also it has a real actual genuine soul connected to a higher plane of existence that you communed with every time you used it.
Also it has a real actual genuine soul connected to a higher plane of existence that you communed with every time you used it.
The Spectrum was underclocked - the Z80A can run at 4MHz. Like many machines of the period, the 3.5MHz comes from the display timings (or very much appears to). There's a good diagram here: http://www.zxdesign.info/vidparam.shtml. Summary: 2 pixels/cycle makes 224 cycles per line; (224 cycles/line) * (312.5 lines/PAL frame) * (50 PAL frames/sec) = 3,500,000 (cycles/sec).
(I don't know if there was a 7MHz clock that was divided by 2, or what, or if the thing could genuinely produce 2 pixels per cycle.)
4MHz was somewhat high compared to the 6502-based systems that made up some of its competition, but for many operations the Z80 doesn't run terribly efficiently. Opcode fetch takes 4 cycles and memory read/write takes 3 cycles, making the memory bandwidth of a 4MHz Z80 about that of a slighty-more-than-1MHz 6502. (The 6502 would read or write 1 byte every cycle.) This downplays the value of the Z80's register set and 16-bit operations, though; 6502 zero page is a bit of a poor substitute in many cases, because you lose a cycle from having to read the address byte.
(Compare INC $xx - 5 x 6502 cycles, 2 x opcode, 1 x read, 1 x dummy, 1 x write - with - with INC r - 4 x Z80 cycles, all opcode fetch and then it's done. On the other hand, ADC A,n takes the Z80 8 cycles, because it has to read 2 opcode bytes - something the 6502 will get through in 2.)
(I don't know if there was a 7MHz clock that was divided by 2, or what, or if the thing could genuinely produce 2 pixels per cycle.)
4MHz was somewhat high compared to the 6502-based systems that made up some of its competition, but for many operations the Z80 doesn't run terribly efficiently. Opcode fetch takes 4 cycles and memory read/write takes 3 cycles, making the memory bandwidth of a 4MHz Z80 about that of a slighty-more-than-1MHz 6502. (The 6502 would read or write 1 byte every cycle.) This downplays the value of the Z80's register set and 16-bit operations, though; 6502 zero page is a bit of a poor substitute in many cases, because you lose a cycle from having to read the address byte.
(Compare INC $xx - 5 x 6502 cycles, 2 x opcode, 1 x read, 1 x dummy, 1 x write - with - with INC r - 4 x Z80 cycles, all opcode fetch and then it's done. On the other hand, ADC A,n takes the Z80 8 cycles, because it has to read 2 opcode bytes - something the 6502 will get through in 2.)
True, but you've glossed over the soul that 6502-based computers didn't possess.
I suppose I'm just by nature not a very spiritual person.
I've spent a lot more time using the 6502, but I like both. They are represent two very different styles. The Z80 is a lot more practical in many respects, with its 16-bit registers and relocatable stack pointer. Some 6502-style register-indexed indirect addressing modes wouldn't have gone amiss, though...
I've spent a lot more time using the 6502, but I like both. They are represent two very different styles. The Z80 is a lot more practical in many respects, with its 16-bit registers and relocatable stack pointer. Some 6502-style register-indexed indirect addressing modes wouldn't have gone amiss, though...
The C64 does have a soul in its SID chip.
Clock speed does not equal performance.
For instance, the Z80's fastest instructions took four cycles, where the 6502's fastest instructions took two cycles.
The Z80's slowest instructions took 23 cycles, and the 6502's slowest took seven cycles.
And even that comparison is over simplified.
For instance, the Z80's fastest instructions took four cycles, where the 6502's fastest instructions took two cycles.
The Z80's slowest instructions took 23 cycles, and the 6502's slowest took seven cycles.
And even that comparison is over simplified.
Matt's blog post on the topic:
http://matt.west.co.tt/spectrum/the-mahler-project/
Bhaa, do it with the loading sounds. That would be impressive. https://www.youtube.com/watch?v=RYLoGAL85MI
Seriously though, amazing! I would have loved to be involved.
Seriously though, amazing! I would have loved to be involved.
If you want to just hear it and see the setup without all the preamble, here it is: https://youtu.be/WiFEicJ6grM?t=6m57s
(Starts at 6:57 if that part of the link doesn't work.)
(Starts at 6:57 if that part of the link doesn't work.)
Trivia / plug: Matthew Westcott, the creator of this project, is also the lead developer on https://wagtail.io/
One interesting thing is, to me at least - a musician, is that the Spectrums are not necessarily in tune; the first one playing the melody seems sharper than all the others. I wonder if the devs were aware of this, and tried fixing it?..