This image was converted from a jpg of a photograph, posterized into 8 colours in the paint program Gimp, converted into a character set and laid out according to the video/attribute memory of Panasonic with a separate program written in Processing. The output binaries were transferred into CJR files using bin2cjr programmed by Markku Reunanen. The CJR files were then converted into WAV files, and loaded into a real Panasonic JR200 with Audacity. The image is taken with a camera and brought back to the mac for some editing before posting it on the blog. So, the image has made quite a journey!What you see here is a redefined character set on a character display with attributes, not a bitmap. 256 characters of the ordinary character set plus the user-defined 64 characters gives a total of 320 characters. (The shown image uses 275 unique characters) The attributes in the video memory determine whether a character is composed of the normal character set, the user-defined set, or the crude pseudo-bitmap graphics.
Dithering is a possibility when converting images from high color and high resolution, but it can drastically increase the number of unique characters needed. Especially Floyd-Steinberg dithering will result in too much variation, so a flat pattern dithering is recommended. Personally I think dithering easily looks ugly so it is better used sparingly.
 |
| Dynamite Dan on the Panasonic? |
Apart from the character display, the Panasonic graphics capabilities very much resemble the ZX Spectrum. Here is a mock-up made out of a screenshot grabbed from Dynamite Dan running on a Spectrum emulator and transferred to the Panasonic. Many 8-bit games make use of repetitive background graphics, so the limitation in the character set would not necessarily prevent making games similar to the Spectrum.
Accessing the screen and attribute memory
What follows is rather detailed information about character displays, using the Panasonic as an example. The character displays are blissfully simple to program, and it shows the kind of directness nowadays missing from computer programming. Fiddling around with the character memory is is also a neat visual way into understanding the workings of the old computers.
This will be painfully thorough, and is likely to be uninteresting to an expert!
A classic 8-bit computer has a bunch of memory that appears to the user as a series of address locations, like 65536 bytes. For convenience, the memory represents everything that is in some ways accessible to the user. Portion of this memory would be reserved for the video. Changing the contents of those memory addresses would have a direct effect on screen.
The Panasonic screen layout is at the memory positions ranging from $C100 to $C3FF. As the screen grid has 32 x 24 characters, this makes exactly 768 bytes. The attribute memory is located in positions between $C500-$C755, again 768 bytes. This indicates the colours for each of the 32 x 24 cells on screen.
What is visible on the Panasonic display is dictated by the contents of the screen memory, the attribute memory and the character graphics memory. The attribute memory and the screen memory are in clear correspondence with each other. For each cursor grid location on the screen there is a memory location in screen memory and the attribute memory. The character memory is from where the pixel patterns for the character are derived.
All the memory can of course be accessed from the BASIC. The POKE command is used to change memory contents, so...
POKE $C100,$41
...would result the character 'A' appearing at the top left corner of the screen, as this memory area is reserved for the screen memory. Furthermore,
POKE $C500,$16
...makes that character appear yellow on a red background.
The attribute memory contents dictate what colour the corresponding characters have on the screen. But there's more to it. Now, as each byte can denote a value of 0-255, this would mean the Panasonic can display 256 unique characters on screen. Yet because of the additional features in the attribute memory, it is possible to have more. The attribute cells not only determine the colour of the characters, but they tell how the screen memory contents will be interpreted.
Sadly, this does not mean there are 512 or 768 characters, as the practical number of additional characters is 64, making up the total of 320. This is likely because the video memory would have exceeded 4 kilobytes, something the computer designers apparently wanted to avoid.
What follows is rather detailed information about character displays, using the Panasonic as an example. The character displays are blissfully simple to program, and it shows the kind of directness nowadays missing from computer programming. Fiddling around with the character memory is is also a neat visual way into understanding the workings of the old computers.
This will be painfully thorough, and is likely to be uninteresting to an expert!
A classic 8-bit computer has a bunch of memory that appears to the user as a series of address locations, like 65536 bytes. For convenience, the memory represents everything that is in some ways accessible to the user. Portion of this memory would be reserved for the video. Changing the contents of those memory addresses would have a direct effect on screen.
The Panasonic screen layout is at the memory positions ranging from $C100 to $C3FF. As the screen grid has 32 x 24 characters, this makes exactly 768 bytes. The attribute memory is located in positions between $C500-$C755, again 768 bytes. This indicates the colours for each of the 32 x 24 cells on screen.
What is visible on the Panasonic display is dictated by the contents of the screen memory, the attribute memory and the character graphics memory. The attribute memory and the screen memory are in clear correspondence with each other. For each cursor grid location on the screen there is a memory location in screen memory and the attribute memory. The character memory is from where the pixel patterns for the character are derived.
All the memory can of course be accessed from the BASIC. The POKE command is used to change memory contents, so...
POKE $C100,$41
...would result the character 'A' appearing at the top left corner of the screen, as this memory area is reserved for the screen memory. Furthermore,
POKE $C500,$16
...makes that character appear yellow on a red background.
The attribute memory contents dictate what colour the corresponding characters have on the screen. But there's more to it. Now, as each byte can denote a value of 0-255, this would mean the Panasonic can display 256 unique characters on screen. Yet because of the additional features in the attribute memory, it is possible to have more. The attribute cells not only determine the colour of the characters, but they tell how the screen memory contents will be interpreted.
Sadly, this does not mean there are 512 or 768 characters, as the practical number of additional characters is 64, making up the total of 320. This is likely because the video memory would have exceeded 4 kilobytes, something the computer designers apparently wanted to avoid.
Defining the characters
$D000 begins the memory portion reserved for the appearance of the 256 standard characters themselves. As the characters are made from 8x8 pixel, each takes up eight bytes. 256 characters takes 2048 bytes of memory, or $800 in hex.
 |
| A detail of how the bitmap is divided into different characters. Each cell refers to a 8x8 pixel character and has its own attributes, background and foreground colour. |
So, again in BASIC,
POKE $D000,$FF
changes the first byte in the first character into $FF (255). This has an immediate visible effect on the Panasonic screen, as clear background is made up of this first character. The screen will be filled with horizontal lines. POKEing the location back to zero will rid of the line.
The following POKEs give a nice brick effect:
POKE $D000,$FF
POKE $D001,$4
POKE $D002,$4
POKE $D003,$4
POKE $D004,$FF
POKE $D005,$40
POKE $D006,$40
POKE $D007,$40
This is a bit painful. The classic way of inputting user defined graphics would be something like this:
10 FOR A=0 TO 7
20 READ B
30 POKE $D000+A,B
40 NEXT A
50 DATA $FF,$4,$4,$4,$FF,$40,$40,$40
No comments:
Post a Comment