Mastodawn

Texture optimisation now works, working around the OpenGL problems on M1 when drawing on textures. I had a little regression having to implement the flash attribute differently, and also the zoom magnification factor has to be done again.

But hey... 600 FPS now, 200% more up from 200 FPS!

I think I could push it somewhere higher closer to 800 FPS, but I'm content with this already. Further optimisation might risk introducing convoluted and unreadable code.

This improvement leaves a lot of room for doing more processing and for many other things, also allowing for the emulator to be ported to slower machines with ease.

All in all, a good Sunday.

#ZXSpectrum #Spectrum #Speccy #ZXGUI #ZXSpectrum256 #Spectrum256 #retrocomputing #retrogaming

Thomas Sturm Apr 21, 2024

@haitchfive Excellent! Question about the screenshot: is that directory info on the screen? Are you implementing some sort of floppy or Microdrive interface in your emulator?

@haitchfive Apr 21, 2024

@tsturm Yes and no.

It's a number of things:

1) Trying to see if I could fit unix-style listings into the Spectrum standard resolution.

2) Trying to see if I could fit unix-style listings using 51-column and 64-column text still in Spectrum standard resolution.

3) A rudimentary attempt (nowhere near ready) to imagine how Spectrum +3 commands should work, using real local filesystem files instead of +3 floppy images.

4) Trying to see whether I would be able to display a DivMMC-like user interface for loading snapshots using the Spectrum screen, or maybe I should use a native toolkit, or something else that works outside of the Spectrum screen (right now I just drag and drop files into the emulator window).

5) Other ideas, like a sort of Netflix interface but for Spectrum titles.

And then a few things more...

#ZXSpectrum
#Spectrum
#Speccy
#ZXGUI
#ZXSpectrum256
#Spectrum256
#retrocomputing
#retrogaming

@haitchfive Apr 21, 2024

@tsturm I sometimes don't even think of these things, I just get them done, and I only intellectualise them now when I have to write them down to give you a meaningful response. In my brain it was just something I had to do / wanted to do. This written response of why I did it is a honest close approximation. I may not have definite answers for some of the other things 🤣

@haitchfive Apr 21, 2024

@tsturm I did think of microdrives / interface 1, but that feels to me like one of the less good things that Sinclair Research did. The vision was brilliant, the execution less so. Even the cobbled-up-together chimera of the Amstrad floppy drive was a step forward in terms of mass storage for the Spectrum.

I don't have a definitive answer about that but it feels to me like even a global network-mounted drive would be better than re-implementing microdrives.

Say, drive W: means: load from the web. Something like that.

Thomas Sturm Apr 21, 2024

@haitchfive Thanks for the thorough overview - there is a lot of inspiration there for my own emulator, which generally is less ambitious than yours! :)

I have too many projects going on at the same time, but I've been slowly improving support to load TZX files through a simulated tape interface (aka in real cassette time using the original loader code) instead of cramming uncompressed TZX blocks into memory without going through the tape loader code.
(1/3)

@haitchfive Apr 21, 2024

Oh I don't know that this stuff is less ambitious, Thomas!

You are adding real 3D graphics to the ZX Spectrum FFS!
🤣

@haitchfive Apr 21, 2024

In any case, the inspiration is mutual, so thank you for that too. 💫

Thomas Sturm Apr 21, 2024

@haitchfive ...
It kinda works, but way too many TZX files that I have use non-standard blocks with undocumented timings - I have no idea how others have implemented their TZX loaders for undocumented data blocks.

Other than that, I'd like to revisit the idea to create semi-3d games by separating different colors into different visual planes in the Metal renderer... there are 2-3 games where I know this would look great.
(2/3)

Thomas Sturm Apr 21, 2024

@haitchfive ...and then I really should finish the z80 emulation. I just found two more games that crash the Z80 core with undocumented z80 instructions that I never bothered to implement. (3/3)

@haitchfive Apr 22, 2024

@tsturm There are too many undocumented instructions, aye.

Part of the reason why I'm not spending any time implementing them all by hand. My guess was that I was going to give up early if I even attempted to implement 1500+ instructions by hand. I knew right from the start that I would enjoy more the other engineering stuff about the memory, and the ZX Spectrum screen. So I tried to maximise the engineering aspects that I enjoy the most, and minimise work that I personally find the most tedious and formulaic.

So I approached the implementation of Z80 instructions in a way that I would enjoy, creating a generator that lifts the instruction descriptions from a .CSV file, generating the Go implementation of instructions from there.

Apart from keeping me more engaged, it also has the benefit that if I want to make a major change to the Z80 implementation, I can do that, and then just regenerate the instructions code! So, in a way, from that perspective it's better engineering too.

Thomas Sturm Apr 22, 2024

@haitchfive That's probably what I should have done. It actually never even occurred to me to generate the Z80 opcode parser from a list of instructions.

I just grabbed a code shovel and started digging. 😅

Although it was for the most part a Zen-like exercise. The code to parse the Z80 instructions is not complicated. I just ran it against the Spectrum ROM until it crashed, looked at what the next instruction would have been and implemented that. Over and over.

@haitchfive Apr 22, 2024

@tsturm To each their own. I would have given up after the first "over".🤣

@haitchfive Apr 22, 2024

@tsturm I didn't want to leave the tape loading topic unaddressed...

I think Martian Girl was way ahead of us both when she implemented that in clean and readable C++.

I've found it's still a great source of learning and inspiration, as she has distilled and filtered an awful lot of historical (sometimes self-contradicting) documentation and synthesised most important parts of it into something that actually works.

(see highlighted section)
https://github.com/MartianGirl/SpecIde#:~:text=Loading%20of%20tapes,to%20.tap%20files.

GitHub - MartianGirl/SpecIde: Let's try something with SFML.

Let's try something with SFML. Contribute to MartianGirl/SpecIde development by creating an account on GitHub.

GitHub

Thomas Sturm Apr 22, 2024

@haitchfive Ohh - thanks! I'll take a look how they implemented the TZX data blocks. Some of the non-standard high-speed blocks are baffling.

@haitchfive Apr 22, 2024

Duplication of effort tends to trigger red alerts in my brain, and I automatically feel the pain of all sirens going off in unison.

My initial instinct is that you and I should quit working separately on redundant code and merge into a single codebase to reduce our workload.

However, in this case, I must resist my own flawed instincts and steer them towards the right path, because what you and I are doing is not duplication of effort.

Instead, we are engaging in duplication of learning and cross-pollination of ideas, which is actually a great thing to do.

Thomas Sturm Apr 22, 2024

@haitchfive Yeah, the microdrives were an inspired hack that should never have become a real product. I'm pretty convinced that if Sinclair would have embraced a floppy interface and moved to 3.5" disks with the QL. the company might actually have made it into the 2000s..

@haitchfive Apr 22, 2024

@tsturm I agree 💯. Single worst business and tech decision by Sinclair.