RCBus 68000 & Dean Nethertons Tang Nano 20K V9958 Board

[Mark Durham]

A quick post to the group to show Dean's FPGA V9958 board working in my RCBus 60000 system. I've ported Dean's demo code that plots a mandelbrot set over and let it do its thing with the following result:

For those interested, here's my RCBus 68000 system:

The backplane is an SC701 from Steve Cousins with the 68000 processor in slot 1, the ROM/RAM board in slot 2, the quad serial board in slot 4 and Dean's V9958 board in slot 6. The spaghetti wiring on the right is my LA connected to one of Steve's SC115 breakout boards.

[Harry Speer]

Well Done, Mark !! 
Harry

[Ronny Ribeiro]

Well done, indeed!

Ronny

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/retro-comp/bc09b26f-7aa3-447b-81e2-b1c70b7925dan%40googlegroups.com.

[Dean Netherton]

Nice one Mark --- looking very neat indeed.

I like the colour scheme of the brot.  My original C code is not a great implementation ..

Now, I wonder how my 8/24-bit eZ80 and compares, performance wise, to your 68K  .  I know the C compiler for the eZ80 is not very efficient. 

Dean

[Mark Durham]

Dean,

My 68K is currently clocked from a 7.3728MHz source and usually has a 4 clock wait for RCBus accesses. That took around 14 min 12 sec to plot. I reduced the wait down to 1 clock and it made no measurable difference on a stopwatch - which I kinda expected as it's primarily a mathematical process. I did try higher system clocks such as 18.432MHz (my 68K is a 20MHz device) but I suspect that I may be missing (or messed up) a check to see if the FPGA is ready for the next command as the plotting froze after a few dozen pixels on the first line.

Out of curiosity I had a brief look at the extended modes just to see if there was an option to stretch the display. I don't know the correct terminology - upsampling maybe? - or if it's even possible within the FPGAs capabilities.

My little display panel indicates that it is receiving a 720x480 image @ 60Hz at power on. When the mandelbrot program is running, it changes to a 720x576 @ 60Hz - i've configured graphic mode 6 for PAL 212 lines. Is there a way to expand (stretch?)  the 512x212 image size of graphic mode 6 (or any of the other modes) so that the image output occupies the whole width and/or height of the panel (keeping the aspect ratio).

Mark.

[Dean Netherton]

> That took around 14 min 12 sec to plot.

OK.  I need to find some time and test my eZ80's performance.  (I thought the rule was, if you are old like me, you get lots of free time!)

>  check to see if the FPGA is ready for the next command as the plotting froze after a few dozen pixels on the first line.

Yep - I am not sure what version of my C/ASM code you based this on - but yep - there is a status flag you need to test to confirm the previous command has completed.  The FPGA implementation of the V9958, is faster than the real chip, but it still only running at 27Mhz - and various VDP commands can still require a few cycles to complete -- its further complicated by the need for the VDP to wait for access to the DRAM, to avoid contention when it's reading the memory for the HDMI output)

>  Is there a way to expand (stretch?)  the 512x212 image size of graphic mode 6 (or any of the other modes) so that the image output occupies the whole width and/or height of the panel (keeping the aspect ratio).

Thats a good question - simple answer no - but my extended screen modes are the way to get a full screen fill.

Let me try and explain the operation and challenge to achieve full screen fill.  It can get a bit complicated.....

As HDMI only supports a fixed set of resolutions, with the lowest being 640x480, and given that highest resolution of a V9958 chip is 512x212, we will need some upscaling to be implemented.  

To fully and accurately upscale 512x212 to one of the standard HDMI video modes, we needs a real fancy upscaler, like the RetroTINK.  Those devices, have very fast and capable FPGAs and support circuits to do true partial pixel interpolated upscaling.  The little Tang Nano FPGA cant really compete with that.  

The first issue for the module, is its ability to generate HDMI signals in the first place.  The HDMI video modes it can generate, are dependant on having an appropriate pixel-clock frequency. The Tang Nano is configured to use a 27Mhz signal for the pixel-clock. 

If we look at the list of the HDMI video modes, that use a 27Mhz pixel clock - (ignoring modes requiring a higher clock - I dont think the FPGA could go much higher than 27Mhz), we can see that there are really only 2 modes that make sense -- one for 60Hz (480p) and one for 50Hz (576p).

(https://en.wikipedia.org/wiki/Extended_Display_Identification_Data)

The other challenge, is the rate of access to the DRAM of the module.  If the FPGA logic is running at 27Mhz (and the onboard DRAM is overclocked a bit), we need 4 cycles to read/write a 32 bit word of memory.  We need to read all of the bytes of the screen image at 50 or 60 times a second to keep up with the required HDMI data stream rate.  We also need time to actually squeeze in some writes to the memory (as directed by commands from the CPU).  Thus, to populate the full 720x576 pixels, can quickly become a bit of a performance challenge.

The upstream developers of the V9958 emulation, choose a simple pixel doubling technique - every line is repeated - and pixels widths are stretch proportionally if required.  But any upscaling is pixel aligned - no partial pixel interpolation.

The original resolutions of the V9958, even when doubled, are still short of the HDMI resolutions - hence the borders around the image.  

For my extended modes, I tried to utilise the full pixel area of the specific modes - eg 720x576 or 720x480, with different pixel doubling in the vertical and horizontal directions. Some modes are line doubled - halving the effective resolution, and some have their width doubles, halving the horizontal resolution. My modes are detailed here: https://github.com/dinoboards/V9958-Super/blob/main/docs/vdp_super_res.md

But in all VDP graphics modes, the HDMI signal is still going to be mapped and output in HDMI mode 2 or 17.  

Additionally, you will notice in the table above, modes 2 & 17 have equivalent modes for widescreen (3 & 18) - these are essentially the same modes (just different meta data in the header of the HDMI signal).  I am not sure monitors will adjust appropriately - I think most monitors may have menu options to override the displayed aspect ratio.

I honestly cant remember where I left my mbrot c implementation at -- need to revisit it - and then confirm or adapt it to work in my extended modes -- will do that as soon as I find that free time I was promised! 

Cheers

Dean

[Mark Durham]

Dean, I'll certainly check that register. The code is based on your latest code on github.

I feel I'm short changing you when simply saying "thanks for the info" after the detailed explanation you've just provided.

I'll certainly look into those extended modes too.

Mark.

[Mark Durham]

After a further bit of experimentation I managed to display my first bitmap image. This is graphic mode 6 - 512x212 16 colours:

This is an AI generated image that I then resized and colour reduced using an old JASC PaintShop Pro program. There's only 3 bits for each R, G & B component of the 16 colour palette.

If you are wondering what image I was trying to coerce the AI image generator to produce, then this short description of the first location from the Colossal Cave Adventure should invoke some retro nostalgia for those who played it:

"You are standing at the end of a road before a small brick building.  Around you is a forest.  A small stream flows out of the building and down a gully."

[Mark Durham]

Second bitmap image, this time in graphic mode 7 - 256x212 and 256 colours - 3 bits for R, 3 bits for G and 2 bits for B:

Halving the number of horizontal pixels is more than made up for by the increased number of colours - from 16 to 256. It took around 2 seconds to write the image but I think it can be quicker as i'm plotting each point individually. There's a command that the V9938/58 has called HMMC - which is a high speed move of data from the 68000 into VRAM.

The AI didn't quite get the stream flowing out of the building but for somebody graphically challenged like me, the AI results are damn impressive.

[Dean Netherton]

Looks great Mark.

Mixing cutting edge image generation with 1998 video rendering.  Graphics mode 7 (256x212 and 256 colours) you used is certainly very capable - and a nice, simple and clean bitmap layout - its very easy to use the commands to write direct to VRAM for this mode.

I liked the idea of the prompt for the image - neat.

If you are looking to go very advanced with the video rendering, you may want to look into the VJK colour space video modes, supported by the V9958 -- these extend graphics mode 7.  These modes support a very large colour space - enabling near photo realist image displays.  A pretty impressive feat for late 1980's.  

Not explored these modes much myself.  I am not sure, but I think the draw pixel and line commands will not work -  direct writes to the VRAM (such as the HMMC you mentioned) are probably the best way.

These modes achieve the higher colour depth, by having a kind of separate luminance and chroma encoding of the image.  A higher resolution for the luminance (black & white) and a lower colour resolution - but with increased colour depth.  With this feature enabled, you can get something like 19268 colours in one image - and still keep memory size to under 64K.

You need to 'convert' your source image, which I assume is a standard 24bit RGB colour space, to the YJK encoded colour space.  (There is a PC application to do this - but I have not been able to get it to run on my linux PC - but the source code is there - (https://marmsx.msxall.com/msxvw/msxvw5/index_en.php).  

But I dont think the translation is too hard - just follow the algebra conversion expression (see Grauw's linked article below)

More infor: 

* https://map.grauw.nl/articles/yjk/ 

* https://en.wikipedia.org/wiki/YJK

the V9958 datasheet has a section (I think the wiki article was copied from there...)

* https://github.com/dinoboards/yellow-msx-series-for-rc2014/blob/main/datasheets/yamaha_v9958.pdf 

Dean