Jump to content

Photo

Casio PV-1000


28 replies to this topic

#26 carlsson ONLINE  

carlsson

    Metagalactic Mule

  • 5,233 posts
  • Location:Västerås, Sweden

Posted Thu Nov 30, 2017 4:41 AM

On many systems, the text based graphics system is arranged like this:

 

Screen matrix that holds an index to each character on screen, e.g. 32x24 or 22x23 (many other combinations possible depending on hardware). Each position has one index, but each index can be used many times on the screen.

 

Colour matrix that holds a combination of background and foreground colour for each character on the screen, arranged in the same way as the screen matrix. Some systems have one single background colour for the entire screen, while others will let you define both the background and foreground colour for each character. Often those are separated so the bottom 4 bits define the foreground and the upper 4 bits define the background. It would allow up to 16 different colours for each, but it isn't to say that the hardware will recognize so many combinations.

 

ROM memory which has the graphic definitions of each character, and this is what the indexes in the screen matrix refers to. By changing pointers, on some systems you can allocate an equally large part of RAM memory instead which you fill with your own character definitions for custom graphics, thus replacing the the ROM.

 

The colour clash that appears on early systems is due to the fact that each character (usually 8x8 pixels, but some systems may have 6x8, 6x9, 8x14, 8x16 etc pixels big characters) can only have one background and one foreground at a time, sometimes only one foreground in case the background is fixed for the entire screen. Thus when a moving object (software sprite) of one colour runs into another object of a different colour, the programmer will have to decide which object's colour should have precedence, while at the same time keep redefining the graphics to get the effect of a software sprite. I think this may be what is referred to as a black box above, that a software sprite rather does not try to merge with other objects if the colours are not matching, but instead is surrounded by blank (black) space.

 

A system that has hardware sprites is not affected by this, as those sprites are defined separately and can move freely on top of other graphics, using its own foreground colour.

 

From what I observed, it seems like the PV-1000 might have higher colour resolution per character than just one background and one foreground colour. Systems like the Acorn Electron, BBC Micro and I think Oric-1 are examples of such. While they mostly seem to be character based and would have cases of colour clashes, if colours can be defined e.g. per line that makes up the character, they can be prettier and in some cases make it possible to have 3-4 different colours within one 8x8 cell.

 

In high resolution bitmap modes, you might be having bitplane graphics or other ways to set the colour of each pixel but that is a very memory hungry method that is quite unusual to use in games where a lot of stuff needs to move and possibly be redefined on the go. Thus your way of thinking is relevant, but usually not applicable to how character based graphics tend to work.

 

Also Nitrofurano tends to stop by here every now and then. Perhaps he'll be around shortly in case you want to ask if he has experimented any more with Boriel's ZX BASIC compiler on the PV-1000. I have never studied it in detail to see if it has general purpose graphics commands that the compiler translates to best suitable, or if just the main engine parts of a program would be portable within different targets of the compiler and the A/V stuff will need tailoring and knowledge of the particular target. It seems to me that most Z80 based systems have unique graphics, but perhaps there is a defined baseline.



#27 pacman000 OFFLINE  

pacman000

    Moonsweeper

  • Topic Starter
  • 310 posts

Posted Fri Dec 1, 2017 12:42 PM

https://translate.go...Sx9WAeKL1Ww-zIQ

Looks like the Casio PV-1000 shows up on Yahoo Japan Auctions fairly often. 10,000 to 38,000 Yen or:

$89.63-$340.60 USD
$113.94-$432.987 CND
$117.704-$447.27 Australian Dollars
67.23 - 255.4751 British Pounds

Not sure what it would be like trying to order something from someone in another country tho.

#28 pacman000 OFFLINE  

pacman000

    Moonsweeper

  • Topic Starter
  • 310 posts

Posted Sat Dec 2, 2017 1:31 PM

 

Video explaining 8-bit computer graphics.



#29 carlsson ONLINE  

carlsson

    Metagalactic Mule

  • 5,233 posts
  • Location:Västerås, Sweden

Posted Sat Dec 2, 2017 3:11 PM

Nice tutorial, I've seen it before. However he mentions 8K of memory for a 320x200 display which corresponds to a monochrome bitmapped display. Not all computers or consoles had the memory capacity for a such display, and even those who did had similar colour restrictions like he mentions in the video and which I mentioned in my post above.

 

Based on the emulation pictures of the Casio, it seems like it really used a text based display with custom character generator, which uses e.g. 32x24 = 768 bytes for the screen matrix, another 32x24 = 768 bytes for the colour matrix (with the possible disclaimer it may support more colours per cell and thus use more memory for the colour matrix), and then 256 * 8 = 4096 bytes for the character generator assuming it supports all possible 256 values - it might be restricted to 128 characters and that the hardware automatically inverts any character with an index above 127. That would be 768 + 768 + 4096 = 5632 bytes, a bit less than 9 * 1024 = 9216 bytes.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users