UK Vintage Radio Repair and Restoration Discussion Forum - View Single Post

SiriusHardware · 1st May 2019, 10:32 pm

I've been mucking about with the VDU again tonight, and here are a couple of snippets arising from that.

Earlier, I said that the relationship of screen RAM locations to text character positions was the way you'd logically expect, but I also said I didn't think that applied to bitmap / graphics mode. I don't know why I thought that, because the allocation of memory locations to pixels does follow the most obvious scheme you could imagine.

The first byte of screen RAM is represented by the first eight pixels at the upper left of the screen, with the LSB state indicated by the rightmost pixel of eight and the MSB state indicated by the leftmost pixel of eight.

The second byte of screen RAM is represented by the next eight pixels to the right, the third byte of screen RAM by the next eight pixels to the right of those and so on, so that the first eight bytes of screen RAM are mirrored by the uppermost 64 pixels. The next eight bytes are represented by the second line of 64 pixels, the eight bytes after that are represented by the third line of pixels and so on. All just as you would hope / expect.

The second snippet of information is the VDU character set, which is as follows: (Each character, followed by its MK14 VDU hex code).

Code:

@ 00   A 01   B 02   C 03   D 04   E 05   F 06   G 07   H 08   I 09   J 0A   K 0B   L 0C   M 0D   N 0E   O 0F
P 10   Q 11   R 12   S 13   T 14   U 15   V 16   W 17   X 18   Y 19   Z 1A   [ 1B   \ 1C   ] 1D   ^ 1E   _ 1F
  20   ! 21   " 22   # 23   $ 24   % 25   & 26   ' 27   ( 28   ) 29   * 2A   + 2B   , 2C   - 2D   . 2E   / 2F
0 30   1 31   2 32   3 33   4 34   5 35   6 36   7 37   8 38   9 39   : 3A   ; 3B   < 3C   = 3D   > 3E   ? 3F

Please note these characters and codes are correct for the character generator IC originally supplied with the MK14. I don't know if this is true for the alternative character generators which are being supplied with Martin L's VDU clones.

I didn't forget the character whose code is 0x20 - that would be 'space' which is why you don't see anything there in the table. At first glance this is awkwardly different to the standard ASCII character set, but in fact some portions are the same and other values are easily derived from the original ASCII values.

Assuming you have some genuine ASCII text which you want to display on the MK14, then:

Send characters with codes in the range 0x20 to 0X3F to the VDU unchanged, as they are the same as in standard ASCII. This range includes the numerals 0 to 9.

For characters with codes in the range 0x40 to 0x5F, - mainly upper case letters, but also including the '@' character whose code is 0x40 - subtract 0x40 from the ASCII code to convert it to the VDU code.

For characters with codes in the range 0x61 to 0x7A - lower case letters - subtract 0x60 from the ASCII code to convert it to the VDU code

If the original ASCII character does not fall within any of these ranges I convert it to 0x3F, which is the code for a question mark '?'.

1st May 2019, 10:32 pm	#181
SiriusHardware Dekatron Join Date: Aug 2011 Location: Newcastle, Tyne and Wear, UK. Posts: 11,586	Re: MK14 schematic revisions I've been mucking about with the VDU again tonight, and here are a couple of snippets arising from that. Earlier, I said that the relationship of screen RAM locations to text character positions was the way you'd logically expect, but I also said I didn't think that applied to bitmap / graphics mode. I don't know why I thought that, because the allocation of memory locations to pixels does follow the most obvious scheme you could imagine. The first byte of screen RAM is represented by the first eight pixels at the upper left of the screen, with the LSB state indicated by the rightmost pixel of eight and the MSB state indicated by the leftmost pixel of eight. The second byte of screen RAM is represented by the next eight pixels to the right, the third byte of screen RAM by the next eight pixels to the right of those and so on, so that the first eight bytes of screen RAM are mirrored by the uppermost 64 pixels. The next eight bytes are represented by the second line of 64 pixels, the eight bytes after that are represented by the third line of pixels and so on. All just as you would hope / expect. The second snippet of information is the VDU character set, which is as follows: (Each character, followed by its MK14 VDU hex code). Code: @ 00 A 01 B 02 C 03 D 04 E 05 F 06 G 07 H 08 I 09 J 0A K 0B L 0C M 0D N 0E O 0F P 10 Q 11 R 12 S 13 T 14 U 15 V 16 W 17 X 18 Y 19 Z 1A [ 1B \ 1C ] 1D ^ 1E _ 1F 20 ! 21 " 22 # 23 $ 24 % 25 & 26 ' 27 ( 28 ) 29 * 2A + 2B , 2C - 2D . 2E / 2F 0 30 1 31 2 32 3 33 4 34 5 35 6 36 7 37 8 38 9 39 : 3A ; 3B < 3C = 3D > 3E ? 3F Please note these characters and codes are correct for the character generator IC originally supplied with the MK14. I don't know if this is true for the alternative character generators which are being supplied with Martin L's VDU clones. I didn't forget the character whose code is 0x20 - that would be 'space' which is why you don't see anything there in the table. At first glance this is awkwardly different to the standard ASCII character set, but in fact some portions are the same and other values are easily derived from the original ASCII values. Assuming you have some genuine ASCII text which you want to display on the MK14, then: Send characters with codes in the range 0x20 to 0X3F to the VDU unchanged, as they are the same as in standard ASCII. This range includes the numerals 0 to 9. For characters with codes in the range 0x40 to 0x5F, - mainly upper case letters, but also including the '@' character whose code is 0x40 - subtract 0x40 from the ASCII code to convert it to the VDU code. For characters with codes in the range 0x61 to 0x7A - lower case letters - subtract 0x60 from the ASCII code to convert it to the VDU code If the original ASCII character does not fall within any of these ranges I convert it to 0x3F, which is the code for a question mark '?'.