Emulator support for VideoNuLA

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
User avatar
bakoulis
Posts: 249
Joined: Wed Feb 08, 2012 9:45 pm
Location: Athens, Greece

Re: Emulator support for VideoNuLA

Postby bakoulis » Sat Sep 23, 2017 11:10 am

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.
#-o [-o<
2xElectron, 3xBBC B, BBC Master.
2xAcorn A310, A420/1, 2xA3000, 2xA3010, A3020, A4000, A5000.
2xRISC PC, Acorn Pocket Book, Acorn Pocket Book II.

tom_seddon
Posts: 84
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: Emulator support for VideoNuLA

Postby tom_seddon » Sun Oct 08, 2017 8:10 pm

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
Posts: 1819
Joined: Sat Sep 01, 2007 9:41 pm

Re: Emulator support for VideoNuLA

Postby RobC » Sun Oct 08, 2017 8:29 pm

That looks really good Tom =D> =D>

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 :oops:

tom_seddon
Posts: 84
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: Emulator support for VideoNuLA

Postby tom_seddon » Sun Oct 22, 2017 11:00 pm

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
Posts: 463
Joined: Mon Jul 25, 2016 11:05 am

Re: Emulator support for VideoNuLA

Postby Coeus » Sat Nov 18, 2017 2:10 pm

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
Posts: 463
Joined: Mon Jul 25, 2016 11:05 am

Re: Emulator support for VideoNuLA

Postby Coeus » Sat Nov 18, 2017 8:15 pm

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.
Attachments
b-em-master-win32.zip
B-Em, Stardot Master Branch as of 18/11/2017 20:13 comopiled for Win32
(9.21 MiB) Downloaded 5 times

Coeus
Posts: 463
Joined: Mon Jul 25, 2016 11:05 am

Re: Emulator support for VideoNuLA

Postby Coeus » Sun Nov 19, 2017 12:01 am

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
Attachments
b-em-master-win32.zip
B-Em Startdot master branch with NULA compiled for Win32
(9.21 MiB) Downloaded 9 times

User avatar
kieranhj
Posts: 526
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: Emulator support for VideoNuLA

Postby kieranhj » Mon Nov 20, 2017 10:24 am

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/wip/b-em_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
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
kieranhj
Posts: 526
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: Emulator support for VideoNuLA

Postby kieranhj » Mon Nov 20, 2017 10:28 am

RobC wrote: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 :oops:

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. :)
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

Coeus
Posts: 463
Joined: Mon Jul 25, 2016 11:05 am

Re: Emulator support for VideoNuLA

Postby Coeus » Mon Nov 20, 2017 2:37 pm

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
Posts: 463
Joined: Mon Jul 25, 2016 11:05 am

Re: Emulator support for VideoNuLA

Postby Coeus » Tue Nov 21, 2017 12:32 am

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).
Attachments
b-em-stardot-nula-win32.zip
(8.66 MiB) Downloaded 19 times

User avatar
simonm
Posts: 166
Joined: Mon May 09, 2016 2:40 pm
Contact:

Re: Emulator support for VideoNuLA

Postby simonm » Tue Nov 21, 2017 11:03 am

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/

User avatar
bakoulis
Posts: 249
Joined: Wed Feb 08, 2012 9:45 pm
Location: Athens, Greece

Re: Emulator support for VideoNuLA

Postby bakoulis » Tue Nov 21, 2017 7:19 pm

Coeus wrote: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).

=D> =D> =D>
2xElectron, 3xBBC B, BBC Master.
2xAcorn A310, A420/1, 2xA3000, 2xA3010, A3020, A4000, A5000.
2xRISC PC, Acorn Pocket Book, Acorn Pocket Book II.

Coeus
Posts: 463
Joined: Mon Jul 25, 2016 11:05 am

Re: Emulator support for VideoNuLA

Postby Coeus » Tue Nov 21, 2017 9:55 pm

simonm wrote: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:

nula1.png


After Ctrl-Break I get:

nula2.png
(1.2 KiB) Not downloaded yet


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.

User avatar
kieranhj
Posts: 526
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: Emulator support for VideoNuLA

Postby kieranhj » Tue Nov 21, 2017 10:42 pm

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.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
Rich Talbot-Watkins
Posts: 1117
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Emulator support for VideoNuLA

Postby Rich Talbot-Watkins » Tue Nov 21, 2017 10:49 pm

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

Coeus
Posts: 463
Joined: Mon Jul 25, 2016 11:05 am

Re: Emulator support for VideoNuLA

Postby Coeus » Tue Nov 21, 2017 11:42 pm

Rich Talbot-Watkins wrote: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.

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Emulator support for VideoNuLA

Postby tricky » Wed Nov 22, 2017 7:41 am

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
Posts: 1819
Joined: Sat Sep 01, 2007 9:41 pm

Re: Emulator support for VideoNuLA

Postby RobC » Wed Nov 22, 2017 10:41 pm

kieranhj wrote: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
Posts: 463
Joined: Mon Jul 25, 2016 11:05 am

Re: Emulator support for VideoNuLA

Postby Coeus » Fri Nov 24, 2017 9:47 pm

RobC wrote: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:
nula.png

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
Posts: 463
Joined: Mon Jul 25, 2016 11:05 am

Re: Emulator support for VideoNuLA

Postby Coeus » Mon Dec 11, 2017 5:57 pm

kieranhj wrote: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)?

User avatar
kieranhj
Posts: 526
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: Emulator support for VideoNuLA

Postby kieranhj » Mon Dec 11, 2017 9:18 pm

Coeus wrote: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?
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/


Return to “emulators”

Who is online

Users browsing this forum: paulb, tricky and 3 guests