|
|
Joined: Apr 2012
Posts: 335 Likes: 47
Senior Member
|
OP
Senior Member
Joined: Apr 2012
Posts: 335 Likes: 47 |
I see the internal ROM is stored as an array of 8bit values, where the rightmost 5 bits represent the actual characters to form a 5x9 grid. Is this an accurate representation of the ROM, or don't we know?
To implement the rounding I intend to copy the character into an array of 16bit values to form a 10x18 grid, formed by expanding each original bit to 4 bits, then adding subpixels to any diagonal.
ie.
. # -> . . # # -> . . # #
# . -> . . # # -> . # # #
. . -> # # . . -> # # # .
. . -> # # . . -> # # . .
Not sure yet how this will affect double height characters but will find out when this is in.
Is this the correct way to implement this, any comments?
Last edited by Pernod; 03/30/15 10:31 AM.
BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.
|
|
|
|
|
Joined: Apr 2012
Posts: 335 Likes: 47
Senior Member
|
|
OP
Senior Member
Joined: Apr 2012
Posts: 335 Likes: 47 |
I'm in the process of making major changes to saa5050.c. I originally intended to simply implement the character rounding but soon became obvious more was required to get this character generator into shape.
The data in the 'hand made' ROM dump also contained the graphics characters which are not required, they can be generated internally so I'll be implementing the 'graphics generator'. I've removed the graphics from the saa5050 and saa5052 'dumps' and also created 'dumps' for all other character sets 5051, 5053, etc. for completeness. The saa5050 dump contained some erroneous characters which I've also fixed.
Some control codes only take effect at the next character and affected control codes are now handled correctly.
At the moment I need to convert a pixel map of '00010101' (UINT8) to '0000001100110011' (UINT16), each pixel is doubled in width. Anyone suggest a simply way of doing this, or should I check each bit separately?
BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.
|
|
|
|
|
Joined: Mar 2001
Posts: 17,070 Likes: 143
Very Senior Member
|
Very Senior Member
Joined: Mar 2001
Posts: 17,070 Likes: 143 |
For a character generator inner loop, I'd suggest the classic unroll-o-matic: *dst++ = (src & 0x80) ? 0xffff : 0;
*dst++ = (src & 0x80) ? 0xffff : 0;
*dst++ = (src & 0x40) ? 0xffff : 0;
*dst++ = (src & 0x40) ? 0xffff : 0;
*dst++ = (src & 0x20) ? 0xffff : 0;
*dst++ = (src & 0x20) ? 0xffff : 0;
*dst++ = (src & 0x10) ? 0xffff : 0;
*dst++ = (src & 0x10) ? 0xffff : 0;
*dst++ = (src & 0x08) ? 0xffff : 0;
*dst++ = (src & 0x08) ? 0xffff : 0;
*dst++ = (src & 0x04) ? 0xffff : 0;
*dst++ = (src & 0x04) ? 0xffff : 0;
*dst++ = (src & 0x02) ? 0xffff : 0;
*dst++ = (src & 0x02) ? 0xffff : 0;
*dst++ = (src & 0x01) ? 0xffff : 0;
*dst++ = (src & 0x01) ? 0xffff : 0;
|
|
|
|
|
Joined: Jun 2001
Posts: 510 Likes: 24
Senior Member
|
|
Senior Member
Joined: Jun 2001
Posts: 510 Likes: 24 |
At the moment I need to convert a pixel map of '00010101' (UINT8) to '0000001100110011' (UINT16), each pixel is doubled in width. Anyone suggest a simply way of doing this, or should I check each bit separately?
https://graphics.stanford.edu/~seander/bithacks.html Check "Interleave bits by Binary Magic Numbers" OG.
|
|
|
|
|
Joined: Apr 2012
Posts: 335 Likes: 47
Senior Member
|
|
OP
Senior Member
Joined: Apr 2012
Posts: 335 Likes: 47 |
A quick update... the graphics generator is implemented and working in bbcb, ROM characters are unrolled in a similar way to RB's suggestion (not sure how the Binary Magic Numbers would've helped), still to fix character rounding. Also tested poly1, p2000t, abc80x and no obvious side effects noticed so far 
BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.
|
|
|
|
|
Joined: Mar 2006
Posts: 1,076 Likes: 5
Very Senior Member
|
|
Very Senior Member
Joined: Mar 2006
Posts: 1,076 Likes: 5 |
character 'rounding': is this similar to the character 'stretching' done in the vt100/rainbow, where each pixel is an OR of its own source rom value and the rom value of the pixel to its left? i.e. from the font rom the characters look like:
Character: 62
........
X.......
X.......
X.XXXX..
XX....X.
X.....X.
XX....X.
X.XXXX..
........
........
while after the stretching right before being drawn to screen, characters looks like:
Character: 62
........
XX......
XX......
XXXXXXX.
XXX...XX
XX....XX
XXX...XX
XXXXXXX.
........
........
The reason the gaps exist at all in the rom is because the double-width font mode on the vt100/rainbow makes the gap visible for one pixel. I.e. the char stretch is done right before being sent to the display, so the doublewide char going into the stretch circuit looks like:
Character: 62
................
XX..............
XX..............
XX..XXXXXXXX....
XXXX........XX..
XX..........XX..
XXXX........XX..
XX..XXXXXXXX....
................
................
and ends up like:
Character: 62
................
XXX.............
XXX.............
XXX.XXXXXXXXX...
XXXXX.......XXX.
XXX.........XXX.
XXXXX.......XXX.
XXX.XXXXXXXXX...
................
................
LN
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
|
|
|
|
|
Joined: Apr 2012
Posts: 335 Likes: 47
Senior Member
|
|
OP
Senior Member
Joined: Apr 2012
Posts: 335 Likes: 47 |
character 'rounding': is this similar to the character 'stretching' done in the vt100/rainbow, where each pixel is an OR of its own source rom value and the rom value of the pixel to its left? No, definitely different. The ROM contains a 5x9 pixel map: (Done)
Character: 62
X....
X....
XXXX.
X...X
X...X
X...X
XXXX.
.....
.....
which is then mapped to a 10x18 pixel map by doubling in both directions: (Done)
Character: 62
XX........
XX........
XX........
XX........
XXXXXXXX..
XXXXXXXX..
XX......XX
XX......XX
XX......XX
XX......XX
XX......XX
XX......XX
XXXXXXXX..
XXXXXXXX..
..........
..........
..........
..........
then dot information of two rows is compared to detect any diagonal and fill in a dot to round it: (TODO)
Character: 62
XX........
XX........
XX........
XX........
XXXXXXXX..
XXXXXXXXX.
XX.....XXX
XX......XX
XX......XX
XX......XX
XX......XX
XX.....XXX
XXXXXXXXX.
XXXXXXXX..
..........
..........
..........
..........
The method is a little more complex for double height characters, but we'll look at that later.
BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.
|
|
|
|
|
Joined: Mar 2006
Posts: 1,076 Likes: 5
Very Senior Member
|
|
Very Senior Member
Joined: Mar 2006
Posts: 1,076 Likes: 5 |
so the rounding isn't something 'simple' like EPX/scale2x, its somewhat more complex? (maybe with a 3x3 '9-cell' kernel instead of a + shaped '5-cell' kernel like EPX/scale2x uses?)
Is the rounding algorithm documented anywhere?
LN
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
|
|
|
|
|
Joined: Jan 2006
Posts: 3,690
Very Senior Member
|
|
Very Senior Member
Joined: Jan 2006
Posts: 3,690 |
(not sure how the Binary Magic Numbers would've helped) by giving you an example implementation, if you needed one  see https://graphics.stanford.edu/~seander/bithacks.html#InterleaveTableObvious which applies in your case with x=y
|
|
|
|
|
Joined: Mar 2006
Posts: 1,076 Likes: 5
Very Senior Member
|
|
Very Senior Member
Joined: Mar 2006
Posts: 1,076 Likes: 5 |
hmm. if rounding is only diagonals, here's one GUESSED possibility: 1. double the character size 2. for every pixel:
/*
A.B
.N.
C.D
*/
if ( (N == 0) &&
(
((A == D == 1) && (B == C == 0)) ||
((A == D == 0) && (B == C == 1))
)
) N = 1;
This is applied to all pixels at once, hence a pixel set to 1 by this equation doesn't count for calculations of other pixels? This seems somewhat complex to implement in hardware, though, unless it is done by a circuit during output with lookback of the previous 2 lines. Edit: easier code:
/*
A.B
.N.
C.D
*/
if ( (N == 0) &&
((A == D) && (B == C) && (A != B))
) N = 1;
LN
Last edited by Lord Nightmare; 04/08/15 06:22 PM. Reason: better code
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
|
|
|
|
|
Joined: Apr 2012
Posts: 335 Likes: 47
Senior Member
|
|
OP
Senior Member
Joined: Apr 2012
Posts: 335 Likes: 47 |
Finally implemented character rounding: Old  New  This also includes a few fixes to the roms, note corrected 'D'. I'm using a teletext engineering test image for testing and are still some obscure control characters not being handled correctly. Hope to get it submitted for this months release though.
BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.
|
|
|
|
|
Joined: May 2015
Posts: 44
Member
|
|
Member
Joined: May 2015
Posts: 44 |
Nice! I hope it gets submitted for 0.167.
"Three days? That's tomorrow, we better get going!"
|
|
|
|
|
Joined: Apr 2012
Posts: 335 Likes: 47
Senior Member
|
|
OP
Senior Member
Joined: Apr 2012
Posts: 335 Likes: 47 |
Completed my saa5050 updates, here's some screenshots to compare old/new with the real thing. old  new  real  All control codes are now handled correctly. It is still not perfect though, if you look closely you'll notice the bottom scanline is missing from each character row, most noticeable on y and g. This is not a regression as the old screenshot shows this too. I'll get back to it when I understand more of video handling.
BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.
|
|
|
|
|
Joined: Apr 2012
Posts: 335 Likes: 47
Senior Member
|
|
OP
Senior Member
Joined: Apr 2012
Posts: 335 Likes: 47 |
So, I broke malzak and p2000t with this update. I did test them before submitting but obviously not with what actually got submitted. This has been quite puzzling but I think I now have a conclusion The saa5050 outputs characters of 20 scanlines but the mc6845 has R9 set to 18 and so outputs 19 scanlines (I had fudged saa5050 to accommodate this and so broke malzak etc). This explains why I'm missing the bottom scanline in the above screenshots. I've now been reliably informed the bbc actually uses the hd6845 http://www.cpcwiki.eu/imgs/c/c0/Hd6845.hitachi.pdf and on page 90: Maximum Raster Address Register (R9) *
This is a register used to program maximum raster address within 5-bit. This register defines total number of rasters per character including line space. This register is programmed as follows.
Non-interlace Mode, Interlace Sync Mode
When total number of rasters is RN, RN-1 shall be programmed.
Interlace Sync & Video Mode
When total number of rasters is RN, RN-2 shall be programmed. So in interlace mode it would output 20 scanlines when R9 is 18. I see our implementation of hd6845 doesn't implement this so will try to fix this. I also noticed we have a MCFG_MC6845_INTERLACE_ADJUST only used in apricot. Is this a workaround for my issue and the apricot should actually use a fixed hd6845?
BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.
|
|
|
|
|
Joined: May 2004
Posts: 979 Likes: 58
Senior Member
|
|
Senior Member
Joined: May 2004
Posts: 979 Likes: 58 |
Probably related yes. Without the hack the apricot displays 350 instead of 400 lines.
|
|
|
|
|
Joined: Aug 2007
Posts: 62
Member
|
|
Member
Joined: Aug 2007
Posts: 62 |
I know this is old, was digging into SAA5050 behaviour in the P2000 computer.
When I run the test image into the real computer with real SAA5050, all colour control codes are displayed as white box, as they are high value (129-135), same for the boxes between the divide symbol, those are black on white background. To get the image as seen here, you have to use the low ones (1-7), and replace the box value (255) with the non inverted box (127). Also in your rendition "Conceil Flash * Box Steady Gone ?" is visible, on a real SAA5050 only "* Box" is visible and blinks, and "Steady" is continuously visible.
Another minor difference is the 2 lines of 4 "separated" magenta pixels left of Test Page are in reality 2 lines of 6 pixels in magenta.
Back to the rounding. On a CRT the rounding is hardly visible. The image is closer to the original non-rounded one. I have the feeling the odd and even scanlines are roughly at the same spot, and thus more blurring together than above eachother. So the interpolation gives some fuzz to the end of the scanline. A character is clearly visible as 9 scanlines in reality.
|
|
|
|
|
Joined: Apr 2012
Posts: 335 Likes: 47
Senior Member
|
|
OP
Senior Member
Joined: Apr 2012
Posts: 335 Likes: 47 |
I know this is old, was digging into SAA5050 behaviour in the P2000 computer.
When I run the test image into the real computer with real SAA5050, all colour control codes are displayed as white box, as they are high value (129-135), same for the boxes between the divide symbol, those are black on white background. To get the image as seen here, you have to use the low ones (1-7), and replace the box value (255) with the non inverted box (127). Also in your rendition "Conceil Flash * Box Steady Gone ?" is visible, on a real SAA5050 only "* Box" is visible and blinks, and "Steady" is continuously visible.
Another minor difference is the 2 lines of 4 "separated" magenta pixels left of Test Page are in reality 2 lines of 6 pixels in magenta.
Back to the rounding. On a CRT the rounding is hardly visible. The image is closer to the original non-rounded one. I have the feeling the odd and even scanlines are roughly at the same spot, and thus more blurring together than above eachother. So the interpolation gives some fuzz to the end of the scanline. A character is clearly visible as 9 scanlines in reality. Even though those screenshots are a good few years old now I don't think much (if anything) has changed since then. The current behaviour on a BBC Micro is correct, for normal use case. I've never seen an actual P2000T video output for comparison, online videos seem to be all emulated. The current SAA5050 behaviour assumes an interlaced display and applies character rounding, maybe the P2000T is not interlaced? Can you supply some photographic evidence to work with? Adapting the SAA5050 to work with both interlaced and non-interlaced (non rounding) displays is on my TODO list, but is kinda dependant on MC6845 improvements for what I want to achieve.
BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.
|
|
|
|
|
Joined: Jun 2009
Posts: 30 Likes: 2
Member
|
|
Member
Joined: Jun 2009
Posts: 30 Likes: 2 |
|
|
|
|
2 members (Augusto, nerd4gw),
33
guests, and
2
robots. |
|
Key:
Admin,
Global Mod,
Mod
|
|
|
Forums9
Topics9,221
Posts120,756
Members5,053
| |
Most Online1,283
Dec 21st, 2022
|
|
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!
|
|
|
|
