Emulator support for VideoNuLA

[bakoulis]

I have tried to compiled the Nula version for my Linux Mint box, but with no luck.
Please, someone put the Nula changes at stardot/b-em master brunch, because this works great for me.

[tom_seddon]

I've added Video NuLA support to b2, including smooth scrolling. Hasn't made its way to the repo yet, but here's a video of it in action: https://www.youtube.com/watch?v=VHmkvWwNq8s

YouTube made a bit of a mess of the video, sadly, but hopefully it's just about discernible :)

There's still a bug somewhere, though, because there's an extra 4-5 scanlines at the top compared to what you see in B-em or in Rob's YouTube video.

--Tom

[RobC]

That looks really good Tom

The extra scanlines could be related to the interrupt timing...

When I was tweaking the row timings to get the multiple ruptures working, I found that adjustments in the timings sometimes caused extra scanlines at the top of the display (I guess because the overall frame timing wasn't quite right).

It's possible that the timing is more critical than it should be as I ended up getting it working more by trial and error than by calculation/design

[tom_seddon]

If it doesn't look like that on the real hardware then it's something I've done wrong ;) - which I'm certain will turn out to be the case. I've noticed that the Planetoid/Defender scrolling in my emulator is nasty too, which is suggestive...

--Tom

P.S. all this stuff is now up on GitHub. The Windows build can now also save out better quality videos, that play back at 720p50/1080p50 on YouTube, so I uploaded a new one: https://www.youtube.com/watch?v=TYb7XjnMsaA

[Coeus]

Kieran's VideoNULA work on B-Em is now in the master branch of the Stardot B-Em repository: https://github.com/stardot/b-em

As mentioned earlier in the thread this does use more host CPU than the non-NULA version so I'd be interested on people's view on this. What sort of host hardware do people run on? Is this an issue? On my desktop machine it doesn't really make any difference but I have a laptop on which it takes the CPU usage from 25% to somewhere between 50% and 75% depending on mode.

Another question - as B-Em's default configuration is to support VideoNULA should the NULA software to run on the emulated BBC be part of the package, in the way we distribute other ROMs or are people happy to fetch these separately?

[Coeus]

So to aid those on Windows in trying out this master branch here is a pre-compiled version. The ZIP should contain all you need - sounds, disc, tapes, DLLs etc. and will run from the directory you unpack it into - no need to install.

[Coeus]

And to follow up my previous post, here is a version for Windows with a compiler warning fixed - see https://github.com/stardot/b-em/issues/31

[kieranhj]

Hey folks,

After meeting RobC at ABUG this weekend, and excitedly trying my real NULA for the first time, I implemented the missing horizontal scroll and left blank features from b-em. This is not an official release as the changes will need to be rolled up into the Stardot repo master branch after a suitable amount of testing & scrutiny. But those who are interested let me know how you get on - the SOTB demo seems to work as expected.

Ahh, the forum won't let me upload the file so try this instead: https://bitshifters.github.io/content/w ... 171120.zip

There's also a small bug fix to reduce some of the CPU usage which should improve MODE 3/6 performance issue as identified by SteveF.

On the topic of support, really NULA should be toggled under a tick box the same way that BeebSID is etc. I will look at adding that but will only be for the Windows interface. I still don't have the official build environment setup (MinGW) so I'm building through Visual Studio.

Cheers,
Kieran

[kieranhj]

When I was tweaking the row timings to get the multiple ruptures working, I found that adjustments in the timings sometimes caused extra scanlines at the top of the display (I guess because the overall frame timing wasn't quite right).

It's possible that the timing is more critical than it should be as I ended up getting it working more by trial and error than by calculation/design

Hey Rob, I think there are some timing issues with the SOTB demo - if you enable "full borders" in the display options for b-em there are about 3 character rows being "displayed" outside of (above) the visible region?!

There is also a tiny glitch somewhere - I get double pixel scroll alternating every 8/9 frames if I single step the 50Hz frames - hard to tell if this is b-em or the tight timing required for all the ruptures? Still looks awesome though.

[Coeus]

Kieran,

I will check that out and will be interested to see what the fix is for the CPU usage in Modes 3 and 6.

On the question of enabling/disabling I note there is already a flag that will disable Video NuLA which can be set by writing to one of the registers and which, according to Rob's documentation, at least for the real hardware, is a one way street, i.e. once written to a power-cycle is needed to re-enable Video NuLA. One possibility would seem to be to expose that flag via the UI, i.e. although there is no mechanism from within the emulated BBC to re-enable Video NuLA the person using B-Em would be able to do this, without a reboot, from the UI.

The other possibility is to swap implementations, i.e. to have NULA and non-NULA versions of pal_convert, videoula_write, mode7_render and video_poll and use a pointer to function technique for video_init to set up pointers to the correct implementation according to whether NULA is required or not. That would require an emulator re-start to change whether NULA was enabled but otherwise could have an advantage for someone who isn't using NULA but is trying to run on older, slower hardware. It may also not be all that hard to do. I had a quick go at making the NULA support prior to this update a compile-time option and that was straightforward so the only additional work is to work out how to compile the same file twice, once with each option, in a way that doesn't generate duplicates of the common bits.

P.S. I am quite happy to provide Linux versions of GUI changes, as long as we are talking simple stuff and not some highly windows-specific dialog.

[Coeus]

Ok, so I have created a branch on the Stardot B-Em repository which has the horizontal scroll and blanking changes above merged into the master from the B-Em Stardot repository. Additionally, this version has an option to enable/disable Video NuLA as Kieran suggested above - it is in the Video section of the menu so for Windows:

and for Linux:

There is also a Windows build attached to this post (though missing some of the non-NULA disc images such as PanOS and Master 512 discs in order to get it to fit as an attachment).

[simonm]

Just a thought on the latest B-Em developments - GitHub releases looks like it might be a convenient way to distribute the various compiled binaries for B-Em ... for those of us without a build environment anyway. You can create a tagged release and upload compiled binaries as attachments.

https://help.github.com/articles/creating-releases/

[bakoulis]

Ok, so I have created a branch on the Stardot B-Em repository which has the horizontal scroll and blanking changes above merged into the master from the B-Em Stardot repository. Additionally, this version has an option to enable/disable Video NuLA as Kieran suggested above - it is in the Video section of the menu so for Windows:

win.png

and for Linux:

lnx.png

There is also a Windows build attached to this post (though missing some of the non-NULA disc images such as PanOS and Master 512 discs in order to get it to fit as an attachment).

[Coeus]

Just a thought on the latest B-Em developments - GitHub releases looks like it might be a convenient way to distribute the various compiled binaries for B-Em ... for those of us without a build environment anyway. You can create a tagged release and upload compiled binaries as attachments.

https://help.github.com/articles/creating-releases/

That looks very useful, Thanks.

And now for an issue. After running the SOTB demo and hitting Break I get:

After Ctrl-Break I get:

nula2.png (1.2 KiB) Viewed 5926 times

This is on an emulated Master 128 which had mode 131 (shadow mode 3) set as its default mode. If I change to mode 7 all is well. This makes me wonder what the behaviour of a real Video NuLA is in this situation. The B-Em video emulation does have a reset function but it doesn't seem to get called and it may npt be necessary to reset everything maybe just the pixel scroll/borders.

[kieranhj]

This is expected behaviour on real NULA. You can reset to default state with ?&FE22=&40 but this isn’t issued automatically on break by the hardware.

At ABUG SimonM was pondering a standard on break handler routine to deal with this issue so that all NULA demos exit nicely.

[Rich Talbot-Watkins]

Out of interest, what's the reason for not reverting to defaults on reset? I would have expected it to work like that!

[Coeus]

Out of interest, what's the reason for not reverting to defaults on reset? I would have expected it to work like that!

I am not the expert here, but looking at the BBC micro circuit diagram it doesn't look like the video circuits in general take the reset signal. The RST line for the 6845 appears to tied high and the video ULA doesn't appear to have a RST line. This would not have been a problem with the original hardware because the OS will have code to establish sensible defaults as part of selecting a new screen mode as part of its general initialisation but obviously that doesn't know about NuLA.

There is a service ROM for NULA which extends the VDU drivers as well as having some program in a ROM filing system. Maybe it would be a good idea for that to write &40 to &FE22 to do the reset in response to one of the service calls issued during Break - call 3 looks like a good candidate though probably a number would work.

[tricky]

3 gets eaten, or only sent to DFS, but as you say there are other options.
The master changed the service calls, and I haven't looked at the compact.

[RobC]

Hey Rob, I think there are some timing issues with the SOTB demo - if you enable "full borders" in the display options for b-em there are about 3 character rows being "displayed" outside of (above) the visible region?!

Sorry for not replying sooner - life has been quite hectic this week and I missed this thread!

When I've got some more time, I'll take a look at the timing issues - as I may have mentioned, the version I posted was a rushed job when I lost the original version that I'd spent hours playing with!

On the reset issue, the hardware retains the settings unless it's sent a reset command (or the machine is powered off) as it doesn't get the ~RST signal.

From a software pov, it would be easy to hook into a hard/soft reset in the ROM (and the code already does this to redirect vectors etc. on all models) but I deliberately decided that the palette and attribute modes should be available across hard resets. Happy to provide a version that issues a reset on Break to anyone who wants one. (I think having a standard handler for NuLA demos is a great idea.)

[Coeus]

From a software pov, it would be easy to hook into a hard/soft reset in the ROM (and the code already does this to redirect vectors etc. on all models) but I deliberately decided that the palette and attribute modes should be available across hard resets. Happy to provide a version that issues a reset on Break to anyone who wants one. (I think having a standard handler for NuLA demos is a great idea.)

Rob, thanks for getting back. I can see why it can be good to keep the palette and attribute mode across a break. The issue I was having appears to be with the left blanking and horizontal scroll so maybe these could be reset on their own? Trying this in B-Em resetting nula_left_blank and nula_horizontal_offset to zero solves the issue so that on hitting Break form within the SOTB demo I now get:

or some variation of that as the exact colours seem to depend on exactly when you hit the key. I think that's an improvement in that you can now see what you're typing and, if you wants to reset the palette etc. you can see to type the command to do so. If you agree, checking how those variables in B-Em get set the ROM code would need to do something like:

LDA #&20
STA &FE22
LDA #&30
STA &FE22

[Coeus]

There is also a tiny glitch somewhere...

Kieran,

On a slightly different tack it has been reported that the NuLA palette colours are not used in Mode 7 on B-Em. I have had a go at implementing this in the GitHyb sf/nula-mode7 branch, and it seems to work, but I'd still be grateful if you would review this and let me know if I have understood things correctly.

In video.c there is a three-dimensional lookup table, mode7_lookup. I found the code to initialise it in video_init rather obscure but looking at the way it is being used in mode7_render how I think this works is that the mode 7 characters have been resampled/smoothed so that each pixel now has a weight, or opacity, rather than being just on or off and this lookup table specifies, for each combination of foreground colour, background colour and weight (from resampled/smoothed character), which colour should go into the 32 bit bitmap that is then blitted to the host screen/window.

On that basis I came up with this to generate a version of this lookup using the NuLA palette instead of the fixed values:

Code: Select all

static void mode7_gen_nula_lookup(void) {
    int fg_ix, fg_col, fg_red, fg_grn, fg_blu;
    int bg_ix, bg_col, bg_red, bg_grn, bg_blu;
    int weight, lu_red, lu_grn, lu_blu;

    for (fg_ix = 0; fg_ix < 8; fg_ix++) {
        fg_col = nula_collook[fg_ix];
        fg_red = getr(fg_col);
        fg_grn = getg(fg_col);
        fg_blu = getb(fg_col);
        for (bg_ix = 0; bg_ix < 8; bg_ix++) {
            bg_col = nula_collook[bg_ix];
            bg_red = getr(bg_col);
            bg_grn = getg(bg_col);
            bg_blu = getb(bg_col);
            for (weight = 0; weight < 16; weight++) {
                lu_red = bg_red + (((fg_red - bg_red) * weight) >> 4);
                lu_grn = bg_grn + (((fg_grn - bg_grn) * weight) >> 4);
                lu_blu = bg_blu + (((fg_blu - bg_blu) * weight) >> 4);
                mode7_lookup[fg_ix][bg_ix][weight] = makecol(lu_red, lu_grn, lu_blu);
            }
        }
    }
    mode7_need_new_lookup = 0;
}

The kernel of this is the calculation of where, between the foreground and background colours each weight should sit. Is this linear calculation right or should it be logarithmic or something else? What about the sign of (fg_red - bg_red)?

[kieranhj]

The kernel of this is the calculation of where, between the foreground and background colours each weight should sit. Is this linear calculation right or should it be logarithmic or something else? What about the sign of (fg_red - bg_red)?

Hey Steve,

Sorry not had much chance to do Beeb stuff of late. zxguesser mentioned to me that the NULA palette wasn’t working in MODE 7. I remember now why I didn’t implement it.. because of this lookup!

In this instance a simple linear interpolation between fg and bg colours would appear correct - doesn’t need to be anything more complicated. The sign of (fg - bg) is fine because this is what you want - all bg at 0 and all fg at 1 (well 15 in this case.)

Actually that’s something you might want to think about - dividing by 15 so that the range does go all the way from bg to fg colour values. I can’t remember what the original lookup table did offhand, was this >> 4 as well?

[Coeus]

n this instance a simple linear interpolation between fg and bg colours would appear correct - doesn’t need to be anything more complicated. The sign of (fg - bg) is fine because this is what you want - all bg at 0 and all fg at 1 (well 15 in this case.)

Thanks for looking, Kieran. With reference to the sign I was thinking "What is the forefound colour is dimmer, at least for that colour component, than the background colour so the expression (fg - bg) is negative.

Actually that’s something you might want to think about - dividing by 15 so that the range does go all the way from bg to fg colour values. I can’t remember what the original lookup table did offhand, was this >> 4 as well?[/quote]

That's an idea. I'll see if I can pick that up again when I am back in front of my home PC.

[kieranhj]

Thanks for looking, Kieran. With reference to the sign I was thinking "What is the forefound colour is dimmer, at least for that colour component, than the background colour so the expression (fg - bg) is negative.

Don't worry, it's correct and standard for simple colour interpolation - you are just doing a lerp between bg & fg so the negative expression correctly transforms the result from bg to fg when the lerp value = 1:

Code: Select all

result = bg + lerp * (fg - bg)
lerp = 0.0 -> result = bg + 0.0 * (fg - bg) = bg + 0*fg - 0*bg = bg
lerp = 1.0 -> result = bg + 1.0 * (fg - bg) = bg + 1*fg - 1*bg = fg

Although at the moment with the >> 4 the result will never quite reach the fg value:

Code: Select all

result = bg + weight * (fg - bg) / 16
weight = 15 -> result = bg + 15 * (fg - bg) / 16 = bg + 15*fg/16 - 15*bg/16 = bg/16 + 15*fg/16 = (bg + 15*fg)/16

So should really be:

Code: Select all

result = bg + weight * (fg - bg) / 15
weight = 15 -> result = bg + 15 * (fg - bg) / 15 = bg + 15*fg/15 - 15*bg/15 = bg + fg - bg = fg

[Coeus]

Thanks, Kieran. I have made that change and pushed to sf/nula-mode7. I will also a Windows binary release to GitHub.

[guesser]

Thanks, Kieran. I have made that change and pushed to sf/nula-mode7. I will also a Windows binary release to GitHub.

The UI seems to be missing, the relevant nula code doesn't appear to have been merged in that branch.

[Coeus]

Thanks, Kieran. I have made that change and pushed to sf/nula-mode7. I will also a Windows binary release to GitHub.

The UI seems to be missing, the relevant nula code doesn't appear to have been merged in that branch.

Now fixed - see the revised ZIP file attached to the release.

[guesser]

That's great, sorry to be such a nuisance

...that said, there is one other minor issue with the mode 7 nula, I notice it is allowing colour 0 to be remapped. I don't have the real hardware so don't know what should actually happen but the manual says "However, due to the way that the teletext mode/mode 7 works, changing colour 0 (black) will affect the rest of the colours and leave colour 0 as black".
That's being very nit-picky and makes me sound ungrateful though which I'm certainly not

[RobC]

I don't have the real hardware so don't know what should actually happen...

Redefining black in mode 7 causes the display's reference voltage to change. This effectively causes whatever colour you've set black as to be "subtracted" from all the other colours. (This only applies to mode 7, modes 0-6 are unaffected.)

Having said that, I don't have a strong opinion on whether an emulator should mimic VideoNuLA exactly or attempt to be an idealised version.

As an example, I would have liked to have been able to add border control to the hardware but it would have meant another flying lead and possibly another level shifter. However, I've left space in the command set for it and it could be easily implemented in an emulator.

[Coeus]

Having said that, I don't have a strong opinion on whether an emulator should mimic VideoNuLA exactly or attempt to be an idealised version.

Rob, thanks for the clarification. That is most of the info I would need to implement it. Does that mean a straightforward simple subtraction for each of the R, G and B components separately would be close or is some more complicated maths involved?

As for whether to do this, I am assuming there is not a body of software at the moment that uses the hardware in ways beyond its design in the way there is software that does this with various other things, like undocumented CPU instructions, and if you think you may revise the design in future that's a warning for people not to do that. On the other hand, one use case of an emulator is to develop software and it can help if the emulator is accurate and doesn't fool you into doing things the real hardware can't do. On that basis I am happy to implement this.