Heh, I did a similar thing a couple of years ago when dogfooding my '8-bit homecomputer IDE' for VSCode (https://marketplace.visualstudio.com/items?itemName=floooh.v...).
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...
> 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
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.
> Then again, maybe you, kind reader, can try this out on your Speccy - and tell me if it works?
It does, here is 'Statue' loading and running on Belarusian 'Bajt' ZX Spectrum clone: https://youtube.com/shorts/0LaItots33Q?feature=share
Oh wow! I never expected to see this in a real Speccy until I fix the one I have back home (I'm an expat).
Thank you so much! :-)
It does indeed work! You can see it running here on my +3 in my "retro cave" :)
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.
Thanks, Mark - for both setups!
It's very nice seeing it put to use in actual Spectrum machines - love it :-)
I love this! Happy to see I'm not the only crazy out there trying to port modern renderers to the Spectrum :D I've been meaning to experiment with assembly, but haven't gotten to that yet. This has some good ideas I'd love to play with.
If you want to write faster Z80 code, pretend it's a Game Boy, and use the IX/IY registers sparingly. You can use 256-byte aligned tables. Then you put your index into the low byte of the register pair, and which table into the high byte of the register pair. You don't even need to completely use the table if you don't need all 256 entries, you can treat the rest of a table as free space to put other variables in there.
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.
If you want to fill values into memory, use PUSH xx instructions. Just move the SP to right position and starting pushing. It's faster than LDIR.
Just make sure you don't mind the interrupts also writing to that memory...
It’s a Spectrum. You’re going to do a HALT to sync with the start of the frame and then cycle count to prevent tearing. You can disable interrupts if you know how long you have to render your frame before the beam catches you (or let it pass then start rendering).
So basically an 8080
(2020)
