An additional Spectrum emulator, featuring real composite video

[rastersoft]

I tried the --help already, but there is neither help specific for ZX Spectrum, nor any option for tape motor...

[Tommo]

Ugh, that means I’ve omitted a line of code; C++’s lack of reflection means some repetition, alas.

It should be exactly the same as the ZX80/81 option; —automatic-tape-motor-control.

[Ast A. Moore]

Ah, thanks! Just checked the latest version (emulating a +2A) against Woody’s Special. It’s getting pretty close timing-wise.

[Tommo]

I'm now looking into all of the above and have discovered an interesting thing: M.O.N.J.A.S. assumes the data bus will contain FF during an interrupt acknowledge cycle. There's no 257-byte table of palindromic addresses, just a single instance of the interrupt handler's address at $9bff.

My understanding was that the content of the data bus during an interrupt acknowledgement was at best 'not reliable'. I guess I should go and search more on this. My emulator is getting this wrong.

[rastersoft]

My understanding was that the content of the data bus during an interrupt acknowledgement was at best 'not reliable'. I guess I should go and search more on this. My emulator is getting this wrong.

Well, the floating bus contains what the ULA is reading at that very moment from the video RAM. Since the interrupt happens when the ULA is painting the upper border, it isn't reading the VRAM and that means that the bus will contain FF. It will contain something different only while painting the PAPER zone.

Monjas does use this not only to avoid a full table for interrupts, but also to detect when the ULA starts painting the PAPER and start copying the back buffer into the video buffer, thus maximizing the available time for that by keeping the writing behind the beam.

[AndyC]

Strictly speaking you can't guarantee that the bus will have FF on it. If there is nothing plugged in to a Speccy you will get it, but there are external peripherals that will break code that assumes that's always the case - which is why a 257 byte table is usually the recommended approach.

[rastersoft]

Yes, I know. The problem is that I really don't have space for the table: currently I have only 5 bytes free in the upper 32 kbytes.

Anyway, modern interfaces do decode IORQ and RD/WR, so that shouldn't be a problem.

[rastersoft]

And also I REALLY need to be able to detect when the ULA is painting the PAPER to ensure that the game doesn't have tearing, so...

[Tommo]

My understanding was that the content of the data bus during an interrupt acknowledgement was at best 'not reliable'. I guess I should go and search more on this. My emulator is getting this wrong.

Well, the floating bus contains what the ULA is reading at that very moment from the video RAM. Since the interrupt happens when the ULA is painting the upper border, it isn't reading the VRAM and that means that the bus will contain FF. It will contain something different only while painting the PAPER zone.

Monjas does use this not only to avoid a full table for interrupts, but also to detect when the ULA starts painting the PAPER and start copying the back buffer into the video buffer, thus maximizing the available time for that by keeping the writing behind the beam.

That makes me wonder why the traditional advice was always to do the 257-byte lookup table then — possibly it's due to a risk of hardware expansion either generating interrupts at a different time, or just plain leaking onto the data bus some other way?

Anyway, that was a definite bug in my emulator. It's all a bit to do with the specific way I've implemented things, but since I'd forgotten to handle the interrupt acknowledge cycle at all in my implementation of the Spectrum's bus, the low part of the IM 2 vector was not anything related to anything meaningful. I've set it to a fixed 255 for now, which I guess is technically accurate on the hardware I emulate but I should probably add a bit more exposition.

Otherwise, at least one more bug remaining before it's worth posting another release, which is that regular-speed loading doesn't seem to work at a clock rate of 3.5Mhz. I'm at a loss as to why not — there's no coupling between file format and machine in my emulator, it should be completely immaterial what rate a tape posts data at to how it is observed. But clearly either an issue persists there or I've just done something dumb in the specific Spectrum bindings to a tape player. I'll figure it out, hopefully.

If I can also get official 10.13 support back in quickly, I'll wait for that too. It's a hassle that the newest version of Xcode that operates under 10.13 can seemingly no longer open the same project files as current Xcode, so I have to code, build, Airdop over, test, and repeat. But it'll be worth it.

Anyway, M.O.N.J.A.S. is fixed in the next version:

[Ast A. Moore]

Since the interrupt happens when the ULA is painting the upper border, it isn't reading the VRAM and that means that the bus will contain FF. It will contain something different only while painting the PAPER zone.

Keep in mind that this isn’t the case for the +2A/+3. As I mention in my Floating Bus Guide,

During idling intervals (i.e. when the ULA is drawing the border or in between fetching the bitmap/attribute byte), the bus latches onto the last value that was written to, or read from, contended memory, and not strictly 0xFF.

So, if you want to make sure it returns 0xFF, you’ll have to either write that value anywhere in contented memory, or make sure that a value is read from it (and it will always have the lowest bit set).

EDIT: I see you already took care of it in your game. I’ll leave my post as is, though, for educational purposes for those who might be interested.

[Tommo]

Minor addendum: my issue actually seems to be that neither the 128kb nor the +2 will load tape software correctly from the ROM routine if running their correct ROMs, even if from 48kb BASIC. If I start either of those with the 48kb ROM then software loads fine, and similarly turbo loaders work as expected.

That the issue persists in 48kb mode seems to take some keypad-related issue off the table, as well as a potential fault in my paging logic that's affecting the 64kb ROMs only.

So I guess this is not going to be the quick fix I was hoping for. I'll post another message here if and when I get a new release out. Maybe the issue will turn out to be something interesting rather than something stupid.

[rastersoft]

That makes me wonder why the traditional advice was always to do the 257-byte lookup table then — possibly it's due to a risk of hardware expansion either generating interrupts at a different time, or just plain leaking onto the data bus some other way?

Well, this is just MY opinion, nothing else, but (again, in my opinion), there are two possibilities:

- the floating bus wasn't very well understood, so people just noted that sometimes the bus had a value different from 255 and so, "just in case", they recommended to always use the table.

- some badly designed interfaces, like the original Kempston, only decoded one bit of the address and the IORQ line, but not the RD line, so if an interrupt happens, and the return address has that bit address set to zero (in the case of the kempston joystick, the A5 bit), it will insert a value in the bus, and thus a table would be needed (I learned this just some days ago, but also discovered that the solution they gave to me -alas, to ensure that I register has bit 5 set to one- doesn't work).

But again, I'm just speculating, it's only an opinion, not something based on deep research.

[Ast A. Moore]

so people just noted that sometimes the bus had a value different from 255 and so, "just in case", they recommended to always use the table.

Well, that’s actually by design. That’s how the CPU can handle numerous devices, each having its own interrupt vector and thus branching code execution to an appropriate ISR.

[Tommo]

- some badly designed interfaces, like the original Kempston, only decoded one bit of the address and the IORQ line, but not the RD line, so if an interrupt happens, and the return address has that bit address set to zero (in the case of the kempston joystick, the A5 bit), it will insert a value in the bus, and thus a table would be needed (I learned this just some days ago, but also discovered that the solution they gave to me -alas, to ensure that I register has bit 5 set to one- doesn't work).

Yeah, if this diagram is accurate:



Then the value on the address bus during an IM 2 interrupt acknowledgement will be the current program counter (i.e. the return address to be), and by the time the data bus is sampled IORQ and M1 will be active. So the advice re: I doesn't really seem to make a lot of sense.

Having dug that up, I can see that I definitely don't have the proper address value being loaded during an interrupt acknowledgment, so that's somewhere else that my contended timings might run askew. Otherwise with the PC visible for four cycles without MREQ at all, or IOREQ for the first two, I guess you'd expect three full contended cycles for addresses that hit a contended page plus another one if the address appears to hit port FE?

[rastersoft]

so people just noted that sometimes the bus had a value different from 255 and so, "just in case", they recommended to always use the table.

Well, that’s actually by design. That’s how the CPU can handle numerous devices, each having its own interrupt vector and thus branching code execution to an appropriate ISR.

Well, yes but no. If you know that you have peripherals X, Y and Z, that put in the bus the values A, B and C respectively, you don't need a full table, but only the entries for those three values: IA, IB and IC. Having a full-filled table with the same value is a trick needed only when you don't know what value can be at the bus.

[Tommo]

I haven't yet managed to figure out what's going on with the +2/128kb tape loading so I chickened out; given the large improvement in compatibility that comes from better dealing with the interrupt acknowledgement cycle I've switched the default machine back to the +2a and updated the release.

Other changes relevant to the discussion above:

• the SDL version is now aware that there are ZX Spectrum command-line options;
• the macOS version should now run on Metal-capable macOS 10.13 machines; and
• timing has been nudged further closer to correct.

The timing issue is actually pretty embarrassing, amounting to the fact that I apparently don't know that a - (- b) is a + b. With the net effect that contention started one column late in 48kb and 128kb, and a column and a bit in +2a/+3.

I'll keep working on the other issues.

Same links as always:

• repository, for building yourself;
• Snapcraft, for pre-built Linux Qt binaries if your distribution is one of those that uses that packaging system; and
• Mac binaries.

If you want to build yourself then as well as the Cocoa and Qt targets there's also the option of building for SDL. In all cases the binding is supposed to be native to that framework — think of the general project structure as more like an emulation library plus three distinct bindings that use that library for their three distinct platforms. There's no attempt to introduce some extra UI layer that somehow makes Qt look like Cocoa, and the SDL version is heavy on command-line invocation being primarily aimed at the associate-with-a-file-type crowd.

[Ast A. Moore]

• the macOS version should now run on Metal-capable macOS 10.13 machines

I can confirm that it does indeed!

• timing has been nudged further closer to correct.

Aye. It’s much closer now. The bottom stripes are still off and the flashing stops and starts spontaneously after a while, but it’s definitely closer. (I’m talking about Woody’s Special on a +2A.)

Keep up the good work!

[Tommo]

Sorry, very minor — I had to put out a new release already anyway, having accidentally forced a regression in the Atari ST, and that includes a fix for the 128k/+2 tape loading bug, which I mentioned above and am therefore following-up on.

I had accidentally treated the second ROM page as contended, because a faulty test spotted that bit 0 is set in the page numbering but failed to observe that it's a ROM. Naturally that broke the edge duration counting loops. I did not see the same effect on the +2a and +3 because they didn't make the same error of conflating ROM and RAM. I did not see the same effect with the 48kb ROM on a 128kb or +2 because the 48kb ROM has only a single page.

So, fairly dumb.

Anyway, if I'm going to keep releasing every two days then I'm going to stop spamming this board. I'll announce only when there's a substantial improvement in the Spectrum emulation — not a mere tweak.

[Ast A. Moore]

if I'm going to keep releasing every two days then I'm going to stop spamming this board.

I’d rather you did keep “spamming.” Much easier to keep track this way. So, I’m all for it.

[rastersoft]

I tested it now with Escape from MONJAS and it works fine. Unfortunately... what a crappy image in Composite mode!

[Tommo]

if I'm going to keep releasing every two days then I'm going to stop spamming this board.

I’d rather you did keep “spamming.” Much easier to keep track this way. So, I’m all for it.

It should be fine, usually I don't release very often. The past week is probably an all-time frequency peak. But it's a fairly niche emulator, and I don't want to introduce too much noise into the forum just because other authors are more disciplined and more organised with their release schedules.

I tested it now with Escape from MONJAS and it works fine. Unfortunately... what a crappy image in Composite mode!

Yeah, my emulator is kind of the opposite of most on this: because it's a full composite encode and decode, each time I revise the decoder I try to make the output better rather than worse. None of what it displays is a put on, it's genuinely the best that I've yet managed for decoding.

Though, heavy caveat on that: the Metal decoder does a better job than does the OpenGL. There's a few reasons for that but the main ones are that the Metal decoder is newer, having been added reactively upon Apple's deprecation of OpenGL rather than because I thought that having multiple decoders would be fun, and that the debugging tools I have are much better for Metal than for OpenGL. But it's all subjective stuff, no inherent reason why the OpenGL version needs to be worse. So it's on my radar for improvements, probably soon.

If you're already using the Mac version then, clearly, this doesn't explain anything.

For the curious:

• the OpenGL does a worse extraction of colour from luma, relying on a spread of point samples to approximate a box rather than an actual box;
• it also does a worse job of scheduling intermediate work, running shaders line-by-line when it really should specify only one or two boxes, and the performance implications of that limit how much work it can do;
• that being the case, it doesn't make any attempt to sharpen luma after extraction, unlike the Metal port, so edges are even softer than they really should be.

Actually, I guess I am boxed in by OpenGL on doing source texture management suboptimally, but I doubt that's a big loss.

Ummm, on the plus side, at least you can now start the emulator up in 16kb or 48kb mode and enjoy some dot crawl. Which just happens, because the clocks differ. Speaking extemporaneously, I guess the pixels are also going to be about 1.7% wider in 48kb mode.

On a separate plus side, if I switch to OpenGL ES while I'm working on it, I might get Raspberry Pi and web compatibility. It'll probably need to be ES 3 though, which means recent Pis and WebGL 2.

[rastersoft]

I tested it now with Escape from MONJAS and it works fine. Unfortunately... what a crappy image in Composite mode!

Yeah, my emulator is kind of the opposite of most on this: because it's a full composite encode and decode, each time I revise the decoder I try to make the output better rather than worse. None of what it displays is a put on, it's genuinely the best that I've yet managed for decoding.

The problem isn't your emulator, the problem is the composited signal itself Your emulator does a great job emulating all the process.

Anyway, it's true that in a real TV it looks better, but I don't know if it is really a problem in your emulator, or that the TV I'm using does some post-procesing.

[Tommo]

Minor bump: a new version is available that can at least load state snapshots, SZX, Z80 or SNA, and which adds joystick input. It also eliminates some hard-coded constants (yuck!) in the Qt/X11 build so as hopefully to be more accepting of different keyboards.

Same links as always, but to save people the scrolling:

• Mac binaries;
• Snapcraft listing (i.e. Linux Qt binaries, or search your built-in software catalogue if you're on Ubuntu or a distribution in that constellation); and
• repository, from which you can also build for SDL.

[arjun]

... I don't want to introduce too much noise into the forum just because other authors are more disciplined and more organised with their release schedules.

Not me then!

[RMartins]

Excelent work @Tommo