Enhanced mode 1 pictures

[davidb]

Thanks, Kees!

It looks like there is still a bit of debugging required but hopefully nothing too complicated.

[jgharston]

I just get the screen filling and Bad key.

That's odd. What system configuration are you using?

Tried it on a BBC which repeatedly gives Bad command, and on a Master which repeatedly gives Bad key.

[tricky]

This is probably my fault for jumping on Davidb's thread. I may be wing, but I believe Davidb's is for the electron and mine is for beebs, but has only been tested on model bs.

[jbnbeeb]

Thanks Tricky and DavidB for explaining what your code does and overview of how it works. Now I need to find some time to study the code!
It'd be good to make use of this approach for a loading screen for a game...

[davidb]

Yes, my code is Electron only, I'm afraid. I'll add some checks to the code to make sure it complains if you try to run it on anything else.

[davidb]

This is probably my fault for jumping on Davidb's thread. I may be wing, but I believe Davidb's is for the electron and mine is for beebs, but has only been tested on model bs.

Actually, I think it's my fault for not mentioning my code was for the Electron until late in the thread. (I think I mentioned it in the other threads.)

I'm actually a bit surprised to see that the Electron has more favourable characteristics than the Beeb when it comes to changing the palette as quickly as possible. Yet another reason for everyone to own at least one Electron.

[CharlesMouse]

Ooo, very nice chaps.

Would the following be of any interest / relevance?
http://users.axess.com/twilight/sock/hi ... color.html

[steve3000]

Great work!

Really impressive to see this - I've just downloaded the parrot and imageviewer to run on my beeb and they work perfectly. I was initially going to set up my electron to take a look - but I notice there's a ROM file in the electron download, does this mean I need sideways RAM?

It's really interesting to read how you sorted out the timing and optimised dithering. If you were at the Wakefield show, you may have seen my 'RasterMan' code demo - which does similar scanline-accurate palette redefining on the Archimedes (16 palette entries + MEMC values redefined accurately each scanline) - but even at 8MHz this wasn't straight forward...although the really tricky bit was enabling sound output and keyboard input... but that's a story for another time.

So, again, very well done

[paulb]

Ooo, very nice chaps.

Would the following be of any interest / relevance?
http://users.axess.com/twilight/sock/hi ... color.html

Using different "fields" of the image is an interesting idea, certainly, although I would worry a bit about flicker. But one of the challenges with MODE 1 is that you can only choose four colours per line, and even if you were to combine them with a different four colours, alternating between them, it's a difficult trick to choose the right colours in the first place. With sixteen colours, I would say that the challenge diminishes somewhat: you can cover more of the colour space.

And then, I think the above method also changes the displayed image, because otherwise, all pixels of one colour on a line would all be alternated with one other colour, and there would otherwise be no good way of addressing each of the pixels so as to give them all individual adjustments. You can do bank-switching on the BBC and Electron, but MODE 1 requires 20K already, so you would need something like shadow RAM (I guess) for the adjusted image.

I have to admit that I've never paid much attention to dithering practices much before now, so I've been stumbling around trying to find and apply decent-enough techniques, starting out with very simple colour estimation and then applying some simple probabilistic techniques. It's been informative to see tricky's dithering examples - I discovered how to get the Python Imaging Library to "quantize" to eight colours in a specific palette for very similar input images - but I think that the optimisation required is still awkward.

Since I can't be bothered to apply the fancy error correction principles that would be necessary, I'm going to draw a line under my own efforts, but the results aren't too bad (here, with some extra saturation):



I think there's definitely a trade-off between colour accuracy and resolution, which means that the more something looks like the original picture, the less the benefits of the extra resolution remain available. I remember once being told by a family friend that he didn't see the point of having more colours than what the BBC Micro had - probably in the context of the Archimedes which would have been new at the time - because you could always combine those primary and secondary colours. Well, I think it's clear that adding a few bits to the colour depth is significantly more desirable than increasing resolution and dithering a limited palette, at least at such shallow colour depths.

Edit: It looks like I didn't properly reduce the number of colours in the above, so a bit more work is required.

Edit #2: OK, it's time for "spot the difference":

[davidb]

Great work!

Thanks!

Really impressive to see this - I've just downloaded the parrot and imageviewer to run on my beeb and they work perfectly. I was initially going to set up my electron to take a look - but I notice there's a ROM file in the electron download, does this mean I need sideways RAM?

Either that, or you need a way to burn the code to ((E)EP)ROM. I don't know exactly how you put ROMs into sideways RAM, if you have it.

It's really interesting to read how you sorted out the timing and optimised dithering. If you were at the Wakefield show, you may have seen my 'RasterMan' code demo - which does similar scanline-accurate palette redefining on the Archimedes (16 palette entries + MEMC values redefined accurately each scanline) - but even at 8MHz this wasn't straight forward...although the really tricky bit was enabling sound output and keyboard input... but that's a story for another time.

So, again, very well done

Thanks again! I saw the video of your talk on RasterMan on YouTube, so it means a lot to me that you appreciate the effort made around this and the similarities between the 8 and 32-bit systems.

[tricky]

I was impressed with the palette swapping at Wakefield and looking forward to the finished demo.

[steve3000]

I was impressed with the palette swapping at Wakefield and looking forward to the finished demo.

I saw the video of your talk on RasterMan on YouTube, so it means a lot to me that you appreciate the effort made around this and the similarities between the 8 and 32-bit systems.

Thanks - it is great to push the limits of these machines, both 8 bit and 32 bit. I especially like the fact that none of this requires any special/modern hardware and all the code could have been written and worked back in the day . As for RasterMan, I am very close to the finished demo and hope to have it ready for release by the London show, but our 15-week-old is seriously eating into spare time...so can't guarantee it.

Thinking about the dithering techniques you've used above - I wonder how complex it would be to do something similar to optimise an image for display on the Archimedes 256 colour palette, with palette redefinition on a scanline-by-scanline basis (eg. using RasterMan)? The problem here is the Arc 256 colour palette is restricted in how it can be programmed because there are only 16 palette entries. So 8bpp pixel data is picked from the base 4096 palette using the 16 programmable palette registers (lower nibble of 8bpp pixel byte gives the palette entry, from which VIDC then pulls 8 low bits of RGB data, 3 R, 3 B and 2 G) + the 4 high RGB bits which come from the upper nibble of the pixel byte (1 R, 1 B and 2 G) - total 12 bits (4096) colour information from 8 bits of pixel data. RasterMan can redefine the 16 palette registers each scan line, which allows an optimised image to display all 4096 colours - and I've done this with a specially designed example image (below). However, the ultimate goal would be to display a scanline by scanline palette-optimised and dithered picture in a similar way you're doing for the beeb/elk.

RasterMan4096k-320x256.png (3.8 KiB) Viewed 4917 times

tn_DSC_0275.png (156.21 KiB) Viewed 4917 times

Edit: not quite sure how I get images to auto-display on the new board?

[davidb]

Edit: not quite sure how I get images to auto-display on the new board?

I think certain image formats just work. For PNGs, I sneakily add them to the message then use the img tags to refer to their URLs. Like this:

[jgharston]

Either that, or you need a way to burn the code to ((E)EP)ROM. I don't know exactly how you put ROMs into sideways RAM, if you have it.

Using a SRLOAD command, such as the one on JGH Disk 6 (archive image)
*SRLOAD filename address romnumber
eg: *SRLOAD FRED 8000 4 would load the file FRED into SRAM bank 4.

[tricky]

If you want to see how someone else did something on the board, quote them, copy the but you want and then cancel.

[1024MAK]

If you want to see how someone else did something on the board, quote them, copy the but you want and then cancel.

Yep, Tricky and his good tricks
But does not work if the admin or moderator has locked the topic

Anyway, back to the topic, more pictures please

Mark

[paulb]

Well, I had a few realisations (and took a tip or two from tricky), and found a more productive path. Spot the difference from my last post...



Again, apologies to the artist for my modifications to make the following artwork more demanding:



But if it persuades someone to port the game to the Electron... (In contrast to those miserly Beeb owners not tolerating a single game being available for the Electron but not for the Beeb. )

I'll make my code available shortly. It's simple stuff, really, and not a proper exploration of image processing techniques, but I've stumbled across something that works a lot better than my initial experiments.

[danielj]

!

d.

[davidb]

I guess I know what I'll be working on this evening.

[tricky]

I have fixed one of my bugs, but there are still a couple left!

Attached is a zip of Tga2beeb.exe that will convert a TGA in 24/32 bit RAW/RLE to a .cols (palette info), .equb (image) and produce_eg.tga so you can see what it should look like. You can just drop the TGA on the exe (windows only) and the output should go to the same folder.

There is also game.asm, which you can use with beebasm, or copy out the sync and palette changing code to display in your own app. By default it will return after !&80=-frames.

I run the combined image, palette and display code with:

10 *TV255,1
20 MODE1
30 VDU 23;3,&29;0;0;0
40 VDU 23,1;0;0;0;0
50 ?&81=&FE
60 *VIEWER

line 30 is because my LCD won't sync properly with the normal h-sync pulse width of 8 (&28).
You could set all colours to black around line 50 so as not to see the image loading, but I like to see something going on.

Also attached is a zipped ImgDisc1.ssd witch cycles through the images, displaying each for just over 10 seconds.

Sorry for the "dump", but time is a bit short at the moment.

[davidb]

Thanks, tricky! I'll try to take a look at this tomorrow. I appreciate the "dump" in any case.

[jregel]

Sorry, got my maths wrong!
There is actually time to reprogram TWO colours per scan line, which is a blow as I have just finished converting my converter to four colours per line!
I'll code the converter and displayer tomorrow and post some more images, maybe even an ssd.

I curious, what is causing the constraint so only two colours can be changed per scan line? Would the BBC Master be able to do better since I believe it's a bit faster?

[paulb]

Sorry, got my maths wrong!
There is actually time to reprogram TWO colours per scan line, which is a blow as I have just finished converting my converter to four colours per line!
I'll code the converter and displayer tomorrow and post some more images, maybe even an ssd.

I curious, what is causing the constraint so only two colours can be changed per scan line? Would the BBC Master be able to do better since I believe it's a bit faster?

I believe that the constraint is the number of cycles available to perform the palette reprogramming operations before the next scanline. I don't think the video circuitry changed significantly between the BBC and the Master, so I doubt that any general performance improvements would make the difference between it not working on the Beeb and it working on the Master. (There might be some instruction cycle count changes between the 6502 and 65C02, but I've never looked into this, so I can't be sure, but I guess there'd need to be significant changes for it to make a difference.)

Personally, I think Acorn got a bit too lazy with the Master series and didn't bother to evolve the design in ways that might have made the machines more interesting, but then again their focus was on the 32-bit stuff by then.

[paulb]

Another day, some more discoveries (some frustrating, some rewarding). Once again, the usual test picture:



Another test picture that people might remember:



And I now think that some random fixes have improved the rendering of my unauthorised title screen variant:



All these saturate and darken the image for extra effect, but merely darkening photographs produces some surprisingly nice results, and I think they're all still using four colours per line. It's quite a surprise to look and see what combinations get used.

As I said to davidb, I think this would be great in conjunction with the Mega Games Cartridge, firstly to have some kind of "MODE 7 light" for the games selection menu, but also to possibly have some cover art images.

The conversion code will be forthcoming...

[1024MAK]

Looking much better

Mark

[paulb]

Looking much better

I've since improved the dithering further. It really helped to have tricky's parrot on hand to show the way.

[tricky]

I just use a Floyd someone dither where the difference between the current pixel colour channels and what I will display is spread over the pixel to the right and the three pixels below on the next row. To pick which colours to use, I pick the combination with the least sum of differences squared for each channel (rgb). As I can only change two colours, I do a lookahead to make sure I don't back myself into a corner with the colours, but I have at least one bug when I look more than two rows ahead. What it also needs is a way to ignore day nearly black and not put a white pixel every twenty to get the correct overall brightness, but as I guess Francis has already tried these things, i'm hoping that he will add support for this type of encoding to his excellent image converter.

[jms2]

I've been following this thread from the start but I've only just had time to study it carefully and try out the demo files. They are really impressive!!

I'm particularly amazed that you guys have managed to do something completely new using just the original hardware. Got some questions though:

1) I have tried Tricky's code on BeebEm and DavidB's on Elkulator. I can see that Tricky's approach to dithering etc is better developed, but is it the case that both machines can be made to perform the same (albeit using ROM code on the Elk)? Or is one potentially better than the other?

2) In Elkulator I could see some flickering/wrongly coloured lines in places. Is that unavoidable, or a quirk with my version of Elkulator?

3) Might it be possible, in principle, to create a unified file format which runs directly on the BBC but calls the ROM code on an Elk?

[tricky]

The beeb requires four registers to be programmed per colour and has time for eight register writes, so only allows two colours for a full width image, it is about 100 mode 1 pixels per colour. The electron as far as I can tell sets all four colours with only two writes total, so is much better at this. The beeb can partially program the palette, but it is quite hard to produce the image, if someone can write the encoder, you canhave all eight colours per scan line, but in fixed byte wide patterns.

[davidb]

I've been following this thread from the start but I've only just had time to study it carefully and try out the demo files. They are really impressive!!

Thanks!

I'm particularly amazed that you guys have managed to do something completely new using just the original hardware. Got some questions though:

1) I have tried Tricky's code on BeebEm and DavidB's on Elkulator. I can see that Tricky's approach to dithering etc is better developed, but is it the case that both machines can be made to perform the same (albeit using ROM code on the Elk)? Or is one potentially better than the other?

I think it's easier to get 4 unique colours per scanline on the Electron. As tricky noted, it may be possible to do 8 colours on the BBC but it could be a lot of work to preprocess the images. paulb has been working hard on improving the dithering on the Electron so you should see some very impressive pictures shortly.

2) In Elkulator I could see some flickering/wrongly coloured lines in places. Is that unavoidable, or a quirk with my version of Elkulator?

It should be possible to get steady images. I hard-coded some checks to make sure that this happens but it's entirely possible that it's not reliable, either on different versions of Elkulator or on real hardware. I'm trying to do this in a way that should figure out the correct delays on whatever the code happens to be running on.

3) Might it be possible, in principle, to create a unified file format which runs directly on the BBC but calls the ROM code on an Elk?

In theory, yes, though it depends on how many colours you change between scanlines. If only 2 change per scanline, as I believe is the case for tricky's images, then it's just a matter of generating suitable palette values for the Electron from those used for the BBC.