I've come to the conclusion that it wasn't coding on assembly level that made development in the 80s slow, but old vs modern tooling. E.g with good tools coding in assembly isn't all that much less productive than coding in a higher level language (unless you're just glueing together 3rd-party packages of course).
With a good macro assembler you're already much closer to a highlevel language like C than to machine code, and with a quick 'edit-compile-debug' loop using an emulator for running the debugee that allows to inspect the entire machine state (and not just the CPU state) you get pretty much the same productivity as working in a "proper" high level programming language, just with a slightly different approach to abstractions (in assembly code, subroutine calls and data layout are your abstraction tools, not the type system of a highlevel language).
Here's the demo I built (no sound, because I suck at sound):
Source: https://github.com/floooh/kcide-sample-kc854 (note: if you're logged in to Github you can just press '.' (dot) to start into the web-version of VSCode which after a little while will ask to install recommended extensions).
Running in emulator via WASM: https://floooh.github.io/kcide-sample/kc854.html?file=demo.k...
Well, perhaps a bit of both, coupled with the fact that there were extremely restrictive hard limits to deal with - processor speed, amount of memory, as well very limited instructions sets such as the 6502 (although you got used to that).
As far as tooling, macro assemblers have been around for a long time. When I used to work for Acorn Computers in the early 80's, some people chose to use MASM, while others just used the BBC BASIC assembler. I'm not sure that it really made much difference. Fighting the limited hardware - speed and memory - was always the challenge.
Another factor that made development difficult/different was just the slow speed of iteration, especially if you were dogfooding as we were at Acorn and developing on the same impoverished hardware you were developing for. A combination of slow build times and a less expressive language (assembler) made for a very different feel to development - you were making more of a commitment to design choices rather than them being fluid and easy/fast to change. When TurboPascal came on the scene many people found it revolutionary just due to the speed.
I do think that language and libraries (which only becomes possible with capable enough hardware that efficiency isn't the main concern) makes a big difference to development though - you can just think at a higher more abstract level. How great it is in C++ to be able to use something like std::map with no concern for efficiency, when back in the day you'd be hand coding a custom hash table and sweating every cycle of the hash function.
It does, here is 'Statue' loading and running on Belarusian 'Bajt' ZX Spectrum clone: https://youtube.com/shorts/0LaItots33Q?feature=share
Thank you so much! :-)
https://share.markround.com/sphere.jpg
I have also uploaded it to my TNFS site[1], which you can also access through an emulated Speccy in a browser (or a real Spectrum if you have a Spectranet/Spectranext card fitted):
https://jsspeccy.markround.com
Press option 4 on the main menu when it loads for recent uploads.
It's really cool and very, very smooth. I wasn't quite sure what to categorise it as on my site, so I filed it under "demos" as I think it's a very impressive bit of code :)
Thanks for sharing!
-Mark
[1]=More details at https://tnfs.markround.com or on my "DevOps for the Sinclair Spectrum" series of articles which are linked from both sites.
edit: At the time I made the post, the thread title was something like "Doing Z80 40 years later", and did not mention the ZX spectrum.
[dead]
It's very nice seeing it put to use in actual Spectrum machines - love it :-)
