Emulator support for VideoNuLA

[simonm]

Hello gang,
Given RobC's fantastic work in bringing the enhanced ULA project to life, are there any bright sparks on here who might be able to update one of the various Beeb emulators to support/emulate this hardware mod? I'm chomping at the bit to make some cool stuff with it, but it'd be even awesomer if theres an emulated version to help speed up dev/testing. I have no idea if this is even feasible, but thought I'd suggest it anyway.

[edit] even if its not 'emulated' as such, just 'hacked' a bit so that any pokes to the new registers Rob setup are intercepted to change the palette of the rendered output or something like that would be handy. Course once we start playing with the pixel scrolling, we'll probably ask for that too.

Cheers
Simon

[RobC]

I might be up for it if someone could tell me what the required tool chains are. I can do C/C++.

Alternatively, I'd of course be happy to help out with any technical info.

[Pernod]

Considering I'm currently rewriting the video implementation in MAME, this could be considered for inclusion. Need plenty of tech details though

[Rich Talbot-Watkins]

The tricky thing will be getting the 12MHz modes working, as their pixels don't correspond in size with the texels of the canvas of the emulator. I think all emulators handle MODE 7 as a special case (which also has a 12MHz pixel rate) by generating glyphs of the characters, where 12 pixels are stretched into 16 texels, with software filtering. Something like this would be necessary, but at runtime - not really difficult, but just a fairly substantial change from how things are currently done.

[Pernod]

I've had a look at the manual and am impressed with the amount of detail and clarity in there, well done to everyone involved.

Will the ROM and support disk be made available to any emulation efforts, or for purchasers only?

[RobC]

Will the ROM and support disk be made available to any emulation efforts, or for purchasers only?

The support disk contains the ROM image. Happy to make it available but I'm working on some bug fixes at the moment. I'll post it once I've got something to release.

[Pernod]

The support disk contains the ROM image. Happy to make it available but I'm working on some bug fixes at the moment. I'll post it once I've got something to release.

Thanks, I'm not ready for it yet so no rush.

[RobC]

I've posted the latest support disk image here:
viewtopic.php?f=3&t=12150&start=390#p176040

[kieranhj]

[edit] even if its not 'emulated' as such, just 'hacked' a bit so that any pokes to the new registers Rob setup are intercepted to change the palette of the rendered output or something like that would be handy. Course once we start playing with the pixel scrolling, we'll probably ask for that too.

It wouldn't be that hard to hack the extra palette indirection into b-em in video.c. At the moment it has a colour lookup with an 8 entry table based on the 8 RGB values. The horizontal scroll, left blanking and attribute modes will certainly be more work!

[kieranhj]

It wouldn't be that hard to hack the extra palette indirection into b-em in video.c. At the moment it has a colour lookup with an 8 entry table based on the 8 RGB values. The horizontal scroll, left blanking and attribute modes will certainly be more work!

Put in the necessary hacks for just the extended palette at &FE23 only to discover that b-em uses an 8-bit depth back buffer for composing the Beeb screen with a R:3 G:3 B:2 palette. Doh! Can't display 12-bits of colour with this as it stands.

[simonm]

Nice work Kieran! To be fair, I'd be happy enough with that for a kick starter, so even though we're missing a few bits of colour res with that hack, at least we'll know if the code we're writing is gonna work ok on the target hardware.

[simonm]

I've no idea how these emulators work really, but will your special hack work with emulated raster timings etc. so we can muck with the palette during frame render?

[kieranhj]

Nice work Kieran! To be fair, I'd be happy enough with that for a kick starter, so even though we're missing a few bits of colour res with that hack, at least we'll know if the code we're writing is gonna work ok on the target hardware.

I thought I was going mad:

Not grey

I tried quickly just changing the main composition buffer to 24/32 bits but to no avail. Looks like jsbeeb might be an easier candidate, although I don't know any JavaScript. video.js:

Code: Select all

        this.collook = utils.makeFast32(new Uint32Array([
            0xff000000, 0xff0000ff, 0xff00ff00, 0xff00ffff,
            0xffff0000, 0xffff00ff, 0xffffff00, 0xffffffff]));

b-em is my emulator of choice though for debugging and working offline generally. I can send you this exe - it's got my VGM logging implemented along with my pause & single 20ms step feature.

[kieranhj]

I've no idea how these emulators work really, but will your special hack work with emulated raster timings etc. so we can muck with the palette during frame render?

b-em already had awesome debug feature that should the exact horizontal & vertical crtc character (+scanline) being drawn when you break. I also added "raster" (x, y) co-ordinates as things get confusing when you're messing with all the crtc registers.

[kieranhj]

Made some changes to b-em to use a 32-bit composition bitmap and result:

Grey!

It's definitely slower - I'm getting some stutter in Debug build but Release is fine on my laptop. I also completely broke the PAL video mode setting but I never use that anyway. (Will look at it but not immediately obvious.)

[SteveF]

Top stuff! Thanks for taking a look at this!

Is there any chance of even a half-baked version of the attribute modes as well? Perhaps a really crude implementation which looks at the attribute bits and sets the correct colours, then just leaves a background-coloured gap corresponding to the attribute bits? This would be useless for attribute-based graphics, but for attribute-based text it would look OK, especially in the 3-bit attribute modes where there's always a background gap between characters anyway.

[tricky]

I can't remember if ms put support for 16 bit back buffers back in after taking them out in win8. If you build as a legacy app, I think it is ok and may be faster, but I guess SDL may get involved.

Edit, I guess it doesn't matter as your only changing the shader resource.

[kieranhj]

Quick update. I hacked together an implementation of the attribute modes in b-em which seems to work OK against the extended VDU modes defined in Rob's NULA ROM. For the 6/12MHz pixel modes it is just doubling every 3rd pixel, so looks a bit chunky in places, but good enough for now.

I am in pm conversation with Rob to get more implementation details to hopefully make it as accurate as possible. I will keep you posted. All code is going into my GitHub account in a branch of a pre-Stardot repo fork: https://github.com/kieranhj/b-em/tree/feature-nula.

[kieranhj]

Quick BASIC program to cycle the extended modes:

Code: Select all

   10REM VNTEST
   20ON ERROR MODE 7:REPORT:PRINT" at line ";ERL:END
   30*VNVDU ON
   40REPEAT
   50READ M%
   60IF M%<0 THEN END
   70READ TW%,TH%,GW%,GH%,FG%,BG%,MEM%
   80MODE M%
   90PRINT"MODE ";M%
  100PRINT"TEXT RESOLUTION = ";TW%;" x ";TH%
  110IF GW%=0 THEN PRINT"Text only" ELSE PRINT"GRAPHICS RESOLUTION = ";GW%;" x ";GH%
  120PRINT"COLOURS = ";FG%;" foreground, ";BG%;" background"
  130PRINT"MEMORY USAGE = ";MEM%;"K"
  140FOR COL%=1 TO FG%
  150COLOUR COL%
  160PRINT"COLOUR ";COL%
  170NEXT
  180REPEAT UNTIL GET
  190UNTIL FALSE
  200END
  210DATA 96,80,32,480,256,4,1,20
  220DATA 97,40,32,240,256,12,1,20
  230DATA 98,80,25,0,0,4,1,16
  240DATA 99,40,32,240,256,4,1,10
  250DATA 100,40,25,0,0,4,1,8
  260DATA 101,80,32,0,0,8,1,20
  270DATA 102,80,25,0,0,8,1,16
  280DATA 103,40,32,0,0,8,1,10
  290DATA 104,40,25,0,0,8,1,8
  300DATA 0,80,32,640,256,1,1,20
  310DATA 1,40,32,320,256,3,1,20
  320DATA 2,20,32,160,256,15,1,20
  330DATA 3,80,25,0,0,1,1,16
  340DATA 4,40,32,320,256,1,1,10
  350DATA 5,20,32,160,256,3,1,10
  360DATA 6,40,25,0,0,1,1,8
  370DATA -1

[SteveF]

Thanks for doing this, it looks great!

I hate to be that guy but... could someone please post a binary? I don't have a Windows development environment. I installed mingw's gcc and make OK, but installing Allegro looks surprisingly fiddly and error prone and I wussed out.

[kieranhj]

Thanks for doing this, it looks great!

I hate to be that guy but... could someone please post a binary? I don't have a Windows development environment. I installed mingw's gcc and make OK, but installing Allegro looks surprisingly fiddly and error prone and I wussed out.

No worries, the b-em build environment is a bit fiddly these days as it is a few years old and the Allegro 4 library is a pain.

Please don't consider this an official build but should be sufficient to mess around with the NULA extended palette and attribute modes. No support for scrolling / blanking and no warranty given as to the accuracy of the emulation!

https://bitshifters.github.io/content/w ... 170728.zip

[SteveF]

Thanks Kieran, that's working a treat!

[RobC]

Steve reported a problem with the 3-bit attribute mode over in the VT100 thread. It seems that the rightmost pixel in every block is being set to black irrespective of how the original palette is setup at FE21.

Here's some code which illustrates the issue - it relies on the VideoNuLA ROM and the extended VDU drivers having been turned on with *VNVDU ON.

Code: Select all

10 MODE 101
20 FOR I=0 TO 15 STEP 2
30 ?&FE21=(I*16)+((I DIV 2) EOR 7)
40 ?&FE21=((I+1)*16) EOR 7
50 NEXT I

Here's the output from B-Em:

B-Em mode 101

And here's what it should look like:

Corrected mode 101

[kieranhj]

Steve reported a problem with the 3-bit attribute mode over in the VT100 thread. It seems that the rightmost pixel in every block is being set to black irrespective of how the original palette is setup at FE21.

That's probably me misunderstanding the intended behaviour in 3-bit attribute modes from the manual and forcing the rightmost pixel to be literally 0 rather than palette entry 0. Will take a look at it when I get chance. Thanks for repro code - makes it much easier to test!

[RobC]

That's probably me misunderstanding the intended behaviour in 3-bit attribute modes...

Or me not explaining it properly in our e-mail discussion!

[kieranhj]

Try this: https://bitshifters.github.io/content/w ... 170913.zip It seems to work OK now with your test program.

The manual says "The rightmost pixel is always assumed to be zero/blank (the space between the characters)" so I was incorrectly interpreting this as always logical colour 0 (still mapped through the palette.)

The correct behaviour is pixel 0 forced to be zero still taking into account the attribute value for the byte. So the logical colour should be 0/2/4/6/8/10/12/14 accordingly. A small fix.

[SteveF]

Thanks Kieran! I've given the new version a test and it works a treat - I've posted a screenshot of my test program under the new version back over in the STEM thread.

[RobC]

Thanks Kieran and sorry for the confusion.

Good to see it working.

[RobC]

Thanks Kieran and sorry for the confusion.

Good to see it working.

[bakoulis]

Can someone pass the changes of VideoNuLA at stardot brunch?
So, we will have a b-em brunch with Music5000, tube and VideoNuLA support!