New version of Frogger (was: A demo of what is looking like a new Frogger for the beeb)

[tricky]

Thanks Bagpuss,
The old code sets the ULA colours to Black, Red, Blue, Green (or something like that) and then redefines how those colours should be displayed multiple times as the frame is "drawn".
The new code does nearly the same thing at startup, but for about 12 colours (inc 4 flashing ones) and then changes which of the twelve colours are displayed on screen.
I have only tested the NuLA code on B-Em as I still haven't installed my NuLA!
The code does not reset the NuLA when you press BREAK, so that might be what is messing with mode 7, although I thought that Rob reset the NuLA on BREAK, if not, ?&FE22=&40 should do the trick.
Can anyone see a flaw in this:

Code: Select all

    Write 40 to FE22 - NuLA Reset (logical mode  - IIRC)
    Write 18 to FE20 - ULA  Set mode 1, no interlace, flash 0
    Write DA to FE23 - NuLA set colour D (ULA A)
    Write 54 to FE23 -      to red:A green:5 blue:4
    Write C0 to FE23 - ...
    Write 04 to FE23 - ...  set other NuLA colours
    Write A8 to FE23 - 
    Write 0D to FE23 - 
    Write 9E to FE23 - 
    Write 30 to FE23 - 
    Write 8C to FE23 - 
    Write CD to FE23 - 
    Write 7C to FE23 - 
    Write CD to FE23 - 
    Write 60 to FE23 - 
    Write CD to FE23 - 
    Write 5E to FE23 - 
    Write 3D to FE23 - 
    Write 3E to FE23 - 
    Write E0 to FE23 - 
    Write 21 to FE23 - 
    Write C0 to FE23 - 
    Write 1E to FE23 - 
    Write 00 to FE23 - 
    Write 00 to FE23 - 
    Write 00 to FE23 - 
    Write 07 to FE21 - ULA  Set Mode1 colour 0 to Black
    Write 17 to FE21 -      ...
    Write 57 to FE21 - 
    Write 47 to FE21 - 
    Write 27 to FE21 - ULA  Set Mode1 colour 1 to Black
    Write 37 to FE21 -      ...
    Write 77 to FE21 - 
    Write 67 to FE21 - 
    Write 87 to FE21 - ULA  Set Mode1 colour 2 to Black
    Write 97 to FE21 -      ...
    Write D7 to FE21 - 
    Write C7 to FE21 - 
    Write A5 to FE21 - ULA  Set Mode1 colour 3 to Black
    Write B5 to FE21 -      ...
    Write F5 to FE21 - 
    Write E5 to FE21 - 
    Write 18 to FE20 - ULA  Set mode 1, no interlace, flash 0

From here on, it is only ULA turning flash on and off and changing which of the four mode 1 colours are which logical (physical?) colour.

[Bagpuss]

Just in case it helps, this is what the game actually looks like:

I've just noticed that the colours for the bottom and middle 'kerbs' are green instead of magenta.

[RobC]

Just a few random thoughts as I've unfortunately not had time to look at this properly yet...

1) I'm seeing the same incorrect behaviour on my machines. I've tried one with the "Spectrum" upgrade and one without so I don't think the "Spectrum" upgrade makes any difference.
2) There's no automatic reset of VideoNuLA on Break. This was a deliberate decision on my part to allow people to load games with SHIFT-Break etc. after setting the palette. You can reset it with ?&FE22=&40 or *VNRESET (if the ROM's installed).
3) On power-up or after being reset, VideoNuLA defaults to physical-mode mapping (i.e. logical colours are mapped to physical colours before being mapped to analogue colours). You have to do ?&FE22=&11 to switch to logical-mode mapping (which bypasses the standard palette at &FE21). I guess that you want the default physical mapping as you're using the standard palette to switch colours?
4) In the (pseudo) code posted, are you deliberately trying to set all 4 logical colours to black? If so, should colours A,B,E & F be set to 7?

[crj]

There's no automatic reset of VideoNuLA on Break. This was a deliberate decision on my part to allow people to load games with SHIFT-Break etc. after setting the palette.

I get the impression both that the programmable logic is quite tight for space and that products already in the field would be a problem, but...

One solution to that quandary would be to have a "reset inhibit" flag. Explicit reset clears that flag then resets, but Break attempts a reset without clearing the inhibit flag.

An alternative option would be a "reset deferred" flag. In that state, the next reset merely clears the flag. That would let you set things up for the next game you launched, but still have things reset cleanly when you stopped playing it.

(The Rolls-Royce solution would be to provide both!)

[RobC]

One solution to that quandary would be to have a "reset inhibit" flag. Explicit reset clears that flag then resets, but Break attempts a reset without clearing the inhibit flag.

Would Break be connected up to the VideoNuLA reset functionality via the ROM? If so, I could probably fit the reset flags in memory so space on the CPLD mightn't be an issue (which is good as I'm currently using every LAB!). Doesn't help those who choose not to fit the ROM of course...

[tricky]

I have spent quite a bit of time trying to understand what is going on and I think the problem is that I am missing something about programming flashing colours.
It took less than a minute to fit my NuLA as my case screws were out for some reason then about 10 minutes checking before I powered on!

I think that I should be using the default mode as I basically want:

MODE 1
set extended/NuLA palette colours to Frogger colours, so most are close to the original colours, blue is unused.
set the flashing colours to the extra not so close colours choosing combinations for the top half of the screen where the "first" colour is what my original frogger uses and the second colour in the bottom half (I set ULA flash 0 down to the end of the water and ULA flash 1 after that).

I then redefine mode 1 colour 0 to be one of the flashing colours that is blue when the ULA flash bit is 0 which I have redefined with NuLA to be dark blue (don't know why I didn't just use blue). I may have some colour EOR 7 mistakes, but the big problem that I am having is that the flashing colours don't get redefined and/or displayed as I am expecting - probably because my assumptions are wrong!

Here is a test program that I have been using this evening to try to understand what I am doing wrong.

Code: Select all

  20MODE1
  30*FX9 20
  40*FX10 5
  50?&FE22=&40
  60?&FE22=&10
  70?&FE22=&80:?&FE22=&90
  80IF INKEY(-2)?&FE22=&8F:?&FE22=&9F
  90FOR Y%=0 TO &FF STEP &11
 100?&FE23=Y%:?&FE23=Y%
 110NEXT
 120FOR Y%=&FF TO 0 STEP -17
 130?&FE23=Y%:?&FE23=Y%
 140NEXT
 150FOR C%=0 TO 3
 160COLOURC%
 170PRINT"COLOUR ";~C%
 180NEXT
 190IF INKEY(-1) ?&FE22=&40
 200REPEAT
 210FOR Y%=0TO15
 220PRINTTAB(0,4)"COLOUR ";~Y%;
 230PROCpal(&A0+Y%)
 240Z%=INKEY(100)
 250NEXT
 260UNTIL0
 270END
 280DEFPROCpal(C%)
 290C% = C% EOR 7
 300?&FE21=C%
 310?&FE21=C%+16
 320?&FE21=C%+64
 330?&FE21=C%+80
 340ENDPROC

The idea is that lines 30 and 40 set the flashing so that the ULA flash 0 colour is on for longer (although again I might have this wrong).
50 resets NuLA
60 is already the default, but I have been playing
70 clears the flashing bits but 80 sets then if run with CTRL pressed
90-140 sets the 16 colours to the greyscale palette (more playing)
150-180 just show the 4 mode 1 colours
190 resets NuLA if run with SHIFT held, so that I can test that the rest of the code works
200-260 cycle MODE 1 colour 3 (white to start) through the 16 ULA palette options, displaying which is currently selected.
PROCpal actually reprograms the 4 ULA palette entries for one colour (3/white here).

When I run with SHIFT, I get what I expect and the 8 non-flashing colours are displayed, the the 8 flashing combinations.

When I run in NuLA mode, I get get black to mid-grey displayed from 0-7 and the same again for colours 8-15.

In mode 2, this seems to work (I get the 16 greys) , but in mode 1, I only get 8 twice.
If it was mode &11, I think I should get a mess of 4 grey levels, but in &10 I am expecting 16.

Please can anyone suggest what I am doing wrong?
In b-em I get the 16 levels of grey, but I must have an early NuLA implementation that works like my brain

[SteveF]

Hi tricky,

I don't know what's going on, but a couple of thoughts:

• I think line 70/80 should be irrelevant, because 90-140 program the entire palette which implicitly makes all colours non-flashing.
• We recently fixed some behaviour related to flashing colours in b-em (but it may still have bugs, of course) - it might be worth building yourself a copy of the latest b-em code from the master branch and seeing if that gives you different behaviour (it sounds like you're experiencing discrepancies between real hardware and b-em - maybe with a newer b-em the two will at least be consistent, even if not what you want)

Your code does look superficially correct to me, but my understanding of NuLA is heavily b-em influenced so I may have the wrong mental model.

Cheers.

Steve

[crj]

(Full disclosure: I don't actually have a VideoNuLA, so please don't mistake this for a feature request from a customer!)

Would Break be connected up to the VideoNuLA reset functionality via the ROM? If so, I could probably fit the reset flags in memory so space on the CPLD mightn't be an issue (which is good as I'm currently using every LAB!).

I can easily believe doing it in memory is the more straightforward option. And on reflection that might actually be enough. Plenty of games trample memory, or just use *FX200 to administer a coup de grace, but provided reset-enabled was the default for zeroed memory you'd get a reset once the game was over. Conversely, nothing much is going to happen to damage your ROM's private word between you setting up the palette and hitting shift+Break.

I had actually intended that it be a setting in the hardware, where no video game could hurt it. But hey. (-8

Doesn't help those who choose not to fit the ROM of course...

No. But they're not going to get a VideoNuLA reset on break anyway.

As a dumb question out of morbid curiosity, is it possible to program VideoNuLA's extended palette to be all one colour, or illegibly low contrast? If so, I guess people without the ROM just have to power cycle.

[tricky]

You can set all colours the same, but typing ?&FE22=&40 (or the decimal equivalent) blind is quite easy and could be added to the disc for SHIFT BREAK convenience.
I'm going to add ESCAPE to quit cleanly, resetting NuLA if I can find the bytes.

[RobC]

Still haven't had time to look at this but your code looks right and, given that it's working in mode 2 but not mode 1, it looks like a hardware bug.

I may not have a chance to look at this further today but I should be able to tomorrow.

[tricky]

Thanks Rob, I may just be misunderstanding the way the extended palette is applied.
Here is another test program - WARNING it FLASHES!

TEST1 - change extended palette colours 3 and 4 to to lime and salmon respectively, then change the background colour (byte value 0) using the ULA palette to be one then the other and back to black for each of mode 2, 1, and 0.

Code: Select all

 10 *FX9 10
 20 *FX10 10
 30 ?&FE22=&40
 40 ?&FE23=&3A:?&FE23=&66
 50 ?&FE23=&46:?&FE23=&A6
 60 MODE2
 70 ?&FE21=&03
 80 X%=INKEY(100)
 90 ?&FE21=&04
100 X%=INKEY(100)
110 ?&FE21=&07
120 X%=INKEY(100)
130 MODE1
140 ?&FE21=&03:?&FE21=&13:?&FE21=&43:?&FE21=&53
150 X%=INKEY(100)
160 ?&FE21=&04:?&FE21=&14:?&FE21=&44:?&FE21=&54
170 X%=INKEY(100)
180 ?&FE21=&07:?&FE21=&17:?&FE21=&47:?&FE21=&57
190 X%=INKEY(100)
200 MODE0
210 ?&FE21=&03:?&FE21=&13:?&FE21=&23:?&FE21=&33:?&FE21=&43:?&FE21=&53:?&FE21=&63:?&FE21=&73
220 X%=INKEY(100)
230 ?&FE21=&04:?&FE21=&14:?&FE21=&24:?&FE21=&34:?&FE21=&44:?&FE21=&54:?&FE21=&64:?&FE21=&74
240 X%=INKEY(100)
250 ?&FE21=&07:?&FE21=&17:?&FE21=&27:?&FE21=&37:?&FE21=&47:?&FE21=&57:?&FE21=&67:?&FE21=&77

TEST2 does the same, but using colours 8 and 15 (F), which I would expect to do the same thing, possibly flashing between salmon and lime.
On my NuLA, this test works as per TEST1 for mode 2 (no flashing), but reverts to black and white for modes 1 and 0.

Code: Select all

 10 *FX9 10
 20 *FX10 10
 30 ?&FE22=&40
 40 ?&FE23=&8A:?&FE23=&66
 50 ?&FE23=&F6:?&FE23=&A6
 60 MODE2
 70 ?&FE21=&08
 80 X%=INKEY(100)
 90 ?&FE21=&0F
100 X%=INKEY(100)
110 ?&FE21=&07
120 X%=INKEY(100)
130 MODE1
140 ?&FE21=&08:?&FE21=&18:?&FE21=&48:?&FE21=&58
150 X%=INKEY(100)
160 ?&FE21=&0F:?&FE21=&1F:?&FE21=&4F:?&FE21=&5F
170 X%=INKEY(100)
180 ?&FE21=&07:?&FE21=&17:?&FE21=&47:?&FE21=&57
190 X%=INKEY(100)
200 MODE0
210 ?&FE21=&08:?&FE21=&18:?&FE21=&28:?&FE21=&38:?&FE21=&48:?&FE21=&58:?&FE21=&68:?&FE21=&78
220 X%=INKEY(100)
230 ?&FE21=&0F:?&FE21=&1F:?&FE21=&2F:?&FE21=&3F:?&FE21=&4F:?&FE21=&5F:?&FE21=&6F:?&FE21=&7F
240 X%=INKEY(100)
250 ?&FE21=&07:?&FE21=&17:?&FE21=&27:?&FE21=&37:?&FE21=&47:?&FE21=&57:?&FE21=&67:?&FE21=&77

Hopefully this is clearer than my previous posts.

I would appreciate it if anyone with a NuLA could check that they get what I do, although my Frogger now looks like the pictures posted, so I don't think my NuLA is any different to anyone else's.

[RobC]

I'm pretty sure it's a hardware issue as if it works in mode 2 then it should work the same way in other modes.

I'll take a look at the VHDL when I get home but I know that the various modes are covered in a big "IF-THEN-ELSE" statement so it's entirely possible that I've made an error for some modes. [One thing to try is whether it works correctly in the 12MHz modes as, from memory, they are covered in the same section of code as mode 2 and mode "8".]

If it is a hardware issue, I'll hopefully be able to come up with a fix to reprogram the boards.

[tricky]

modes 4 and 5 behav the same as 0 and 1, I'll have to look up the settings for mode "8".

[tricky]

Mean time, here is a NuLA version with auto detect for the ROM.
You can hold CTRL (until game starts) when you choose your keyboard layout to force NuLA mode.
The game will now quit cleanly if you press escape, resetting NuLA and doing a near power on boot.

Code: Select all

LDX #&7F : STX &FE4E : JMP (&FFFC)

As usual, let me know if there are any issues!

[RobC]

I've had a look through the VHDL and this is definitely a bug

I made a typo when I took the prototype code and ported it to the production board - not sure how I missed it but I certainly shouldn't have used signal names that look like each other

The good news is that I think I have a fix - it works with the combined version of Frogger and some other tests I've tried. I'll do some more testing over the weekend and report back if all is well.

I will of course upgrade existing boards to the latest build (including Spectrum functionality) for free. Please contact me if you want your board upgraded - probably easiest to do it via e-mail if you have my contact details.

I'll also put something in the main VideoNuLA thread when I'm satisfied that the fix works.

Sorry for any inconvenience.

[tricky]

Rob, thanks for checking so quickly.
As it only seems to affect flashing colours in non 16 colour modes, I'm not surprised that it slipped through.

Are you saying that the version that doesn't check for the ROM actually has the correct colours, brown logs etc?

I hope that everyone understands that we do this as a hobby and that we do our best.

My games all end up being patched.

I'm just glad that you are so helpful and offer such great support and am just sorry that it will take more of your time.

[RobC]

Rob, thanks for checking so quickly.
As it only seems to affect flashing colours in non 16 colour modes, I'm not surprised that it slipped through.

I can't really believe that I missed it. I even worked on code just below it (to implement the Spectrum and Thomson modes) and didn't see it...

Guess it's just a case of seeing what you want to see. I know that I tested the programming of the flashing colours in modes 0 and 1 at some point but it must have only been on the prototype.

Are you saying that the version that doesn't check for the ROM actually has the correct colours, brown logs etc?

Yes - the version Andy was having problems with (from 10.00pm on the 28th) has brown logs and dark blue water when used with the revised board.

I'm just glad that you are so helpful and offer such great support and am just sorry that it will take more of your time.

No problem - I'm sorry that the error crept in and glad that the fix fits! Reprogramming the boards doesn't take very long so my time isn't an issue. More sorry for those who've already returned their boards once to have the Spectrum upgrade. At least anyone who hasn't already returned their board gets that benefit.

I will be at the Wakefield RO Show for anyone coming along to that and can provide a .pof file and instructions for anyone with their own Altera JTAG programming setup.

For everyone else, do feel free to send your boards back to me - please do include your contact details with the board though. I'm happy to cover return postage.

[tricky]

Rob, do you happen to know if the cheap xilinx copy programmer listed for the Matchbox Copro will work?

[RobC]

Rob, do you happen to know if the cheap xilinx copy programmer listed for the Matchbox Copro will work?

I've never tried it but I'll give it a go later today...

[Bagpuss]

Rob, do you happen to know if the cheap xilinx copy programmer listed for the Matchbox Copro will work?

I did wonder about that, as I've got the Xilinx too. I think it should, but I ended up buying this.

Works well, unless you're using Windows 10 x64. If you are, then the drivers that come with the latest Quartus Lite 17.1 will bluescreen Windows every time you install them.

I found that installing the Windows 7 x64 driver from this thread, solved the problem. You do have to disable windows driver signature enforcement to get them to load, but I can put up with that for something that works.

I've now flashed Rob's fixed code, and it all works fine. I've done some more testing today with a variety of MODE 1 games, and everything looks good. I might also have spent some time with Prince of Persia.

[RobC]

I did wonder about that, as I've got the Xilinx too. I think it should, but I ended up buying this.

I've just tried using my cheap Xilinx USB Platform Cable but, unfortunately, it wasn't recognised by the Altera Quartus software. Might be worth a quick try in any case although a brief google seems to indicate that you have to mod it to work as an Altera USB Blaster.

I connect my Altera USB Blaster up to the VideoNuLA boards by using 6 female-female Dupont leads (the type used to connect to Raspberry Pi GPIO pins) and a right-angle pin header.

I don't bother soldering the pin header to the board but just hold it in place during programming. It doesn't take long and you can always start again if you lose connection. I've written some instructions for anyone who wants to program their boards themselves.

I've now flashed Rob's fixed code, and it all works fine. I've done some more testing today with a variety of MODE 1 games, and everything looks good.

Thanks Andy - I really appreciate your help particularly as my test setup is hard to get to at the moment!

[tricky]

I've just ordered one of those too as it was easier than finding my Xilinx in my office
The cheapest I could find without waiting for China was £6.99 https://www.ebay.co.uk/itm/altera-Mini- ... OSwT6pVmSY~ as the one listed is out of stock. From china, they start at about £2.25!

[Bagpuss]

I've now flashed Rob's fixed code, and it all works fine. I've done some more testing today with a variety of MODE 1 games, and everything looks good.

Thanks Andy - I really appreciate your help particularly as my test setup is hard to get to at the moment!

No worries. Glad I could help. Have done some more testing over the bank holiday, and haven't found any issues.

[RobC]

Have done some more testing over the bank holiday, and haven't found any issues.

Thanks again - I've done some more testing too so am confident that the fix works. I've put something over in the main PaletteMate/VideoNuLA thread to inform people who haven't been reading this.

[tricky]

Thanks Rob,
here is Frogger on my updated NuLA and what is hopefully the final version that will work with or without NuLA and with or without its ROM; also resets the palette if you quit with ESCAPE.

Obviously, I'm rubbish at photographing a TV with a cheap phone!

[sPhilMainwaring]

This should possibly be a separate thread and, thanks to old age I've probably asked elsewhere, but is NULA emulation supported on BeebEm, BEm or jsbeeb at all so we can appriciate Tricky's game in all its glory?

[tricky]

It is in B-Em, on hoglets branch in github although, I downloaded a version from one of Kieran's links, I can't find it now!

[sPhilMainwaring]

Thanks Tricky

Hoglet's doesn't seem to have a Windows executable

If you find Keiran's link could you stick it here please

Tarrrrrrr

[hoglet]

My fork is really old now.

The NuLA changes were merged back into the stardot/b-em repository master branch back in November, so any build since then should include it:
https://github.com/stardot/b-em/releases

Dave

[tricky]

Can we get this version on bbcmicro.co.uk (if it isn't already)?