ZX81 Pseudo hi-res graphics mode for SuperCharger BASIC

[Mr SQL]

ZX-81 pseudo hi-res graphics mode for SuperCharger BASIC

 

I found an interesting way to do ZX-81 pseudo hi-res graphics in SuperCharger Disk BASIC writing this prototype for the 2022 BASIC programming contest!

 

Here's the code and two versions of the Alpha build for Jupiter SS, one using pseudo hi-res and one using regular bitmapping:

 

Jupiter_SS_Firestorm_GAMMA.bin  BASIC10Liner2022Jupiter_Pseudo_Hi_Res_GAMMA.txt

Added algorithmic chiptunes and parallax scrolling, ready for the BASIC contest!

 

Manual and program design:  Jupiter_SS_Firestorm_GAMMA_Instructions_and_program_design_20220320.txt

 

Jupiter SS prior development builds:

Jupiter_SS_Firestorm_BETA.bin

 

Jupiter_SS_Alpha.bin

   Jupiter_psuedo_hires.bin

 

Description:

The BASIC listing uses either the visual sprite graphics or BASIC data statements, since the contest only allows line numbers and no visual ASCII art designers I used data statements from classic BASIC. A data statement with a series like $D5,$AE,$7C takes four bytes per byte and the BASIC 10 liner contest allows only 10 lines of 120 characters for the entire game. The pseudo hi-res mode allows a lot of data to be fit but is even more limiting with many bit patterns getting up converted to $FF by DASM behind the scenes limiting the bit patterns available to BASIC.  But the ZX-81 pseudo hi-res technique works with the remainder!

  About pseudo hi-res:

Clive Sinclair created an incredible learning machine with technology waiting to be explored with a unique design like the Atari 2600; pseudo-hires mode discovered on an unmodified ZX81 imparts a hand drawn texture look that adds more to this graphics mode.

 

I had expected only the hilighted pattern substitution shown in the screenshot. There are many more occurring but there is still plenty of potential using the available patterns and substitutions for the missing ones, there is no other pattern substitution in the Alpha build yet so the pseudo hi-res sprite is looking like a Hammerhead with the FF's (11111111) showing where the substitution patterns are needed.

 

 

Edited March 22, 2022 by Mr SQL
Manual

[stepho]

If I understand the ZX-81 technique right, they are displaying only the top row of pixels from each row of ASCII characters to get a much higher resolution than normally available (albeit with restrictions).
But since the 2600 doesn't have ASCII characters, I don't see how this relates to the 2600.

[Mr SQL]

10 hours ago, stepho said:

If I understand the ZX-81 technique right, they are displaying only the top row of pixels from each row of ASCII characters to get a much higher resolution than normally available (albeit with restrictions).
But since the 2600 doesn't have ASCII characters, I don't see how this relates to the 2600.

Good question, SuperCharger BASIC has a PRINT command for working with real hi-res graphics like a modified ZX-81:

10 print %11111111(player0,0)
20 print %11000011(player0,1)
30 print %11111111(player0,2) 

We just printed three rows of pixels on the player1 sprite, which has 8 rows. Built in functions loadplayer0(n) and loadplayer0upsidedown(n) contain loops that read 8 rows of the sprite library starting at index n and load the player sprites much like this - you can write similar functions in vwBASIC.

Printing strings on the world with the PRINT@ command:
-------------------------------------------------------
You can poll,flip or set the individual pixels or bind the sprites to them with vwpixel but you can also print a binary string to the virtual world, 8 bits at a time much like the BASIC PRINT@ command.

print %10101010(virtualworld,3)

BASIC also supports ASCII text in the data statements, however not all ASCII characters are available to use (PETSCII chars  all convert to 255 or 11111111) imposing pattern substitutions for the pseudo hi-res.

 

Graphics drawn using the top row of ASCII character definitions in the ZX-81 ROM require pattern substitutions because not all 256 pattern combinations of 8 binary digits are available from the top rows to draw with:

........ NULL ASCII Character
..XXXX.. 4+8+16+32 = 60 "<"
.XXXXXX. 2+4+8+16+32+64 = 126 "~"
XXX..XXX 1+2+4+32+64+128 = 231 "τ"
XXX...XX
XXXXXXXX
XXXXXXXX
XXX...XX

  

[stepho]

I still don't see the benefit for the 2600

The ZX81 doesn't have a true hires graphics mode, so anything that displays better than block graphics is good (in this case, by displaying the top lines of ASCII characters with a very impressive technique).

 

The 2600 has a low res background that can't directly show ASCII characters.
If it did show ASCII characters it would be by transforming the ASCII characters into background graphics.
So we gain no benefit by using ASCII.

 

Likewise for using ASCII characters in player/missile graphics.

 

The ASCII characters take up 8-bits each.
The final display is also 8-bits - except not all combinations can be displayed.
So again, no benefit.

 

Or have I missed something?

[Mr SQL]

On 12/7/2021 at 1:35 AM, stepho said:

I still don't see the benefit for the 2600

The ZX81 doesn't have a true hires graphics mode, so anything that displays better than block graphics is good (in this case, by displaying the top lines of ASCII characters with a very impressive technique).

 

The 2600 has a low res background that can't directly show ASCII characters.
If it did show ASCII characters it would be by transforming the ASCII characters into background graphics.
So we gain no benefit by using ASCII.

 

Likewise for using ASCII characters in player/missile graphics.

 

The ASCII characters take up 8-bits each.
The final display is also 8-bits - except not all combinations can be displayed.
So again, no benefit.

 

Or have I missed something?

 

Using the subset of available bit patterns from ASCII allows more graphics data to be stored in data statements.

It's useful for BASIC Programming contests to reduce the size of listing.

 

[stepho]

Not sure how replacing 8 bit graphics with 8 bit ASCII characters saves memory.

[Mr SQL]

 

Here's the BASIC listing now using pseudo hi-res graphics!

 

BASIC10Liner2022Jupiter_Pseudo_Hi_Res_BETA.txt  

 

ROM is in the 1st post.

 

Details

--------

Pacman Red's walking man sprites illustrated above are converted into pseudo hi-res using the available 7-bit ASCII codes (about 110 out of 255 possible combinations) to fit more frames of character animation in a 10 line BASIC program.

 

I was going to have the character turn into a Jet too but the Firestorm graphics were already present in the code.

 

There's still space free in the program so I may add more before the contest!

 

[stepho]

Ok, now I understand what you are trying to do.
It's got nothing to do with the ZX81 method of using the top rows of the character generator ROM to display hires graphics.
It's just a way of encoding data statements.

Instead of doing:

data $40,$41,$42

you are doing

data "@AB"

by relying on:

• ASCII '@' being $40
• ASCII 'A' being $41
• ASCII 'B' being $42
• etc

I can see that this would work, excepting of course that you already pointed out that non-visible ASCII characters can break it.
Naturally, I would avoid it as being unnecessarily cryptic unless you really, really needed to squeeze the number of characters down - like in the 10 line contest with limited character line length.

[Mr SQL]

1 hour ago, stepho said:

Ok, now I understand what you are trying to do.
It's got nothing to do with the ZX81 method of using the top rows of the character generator ROM to display hires graphics.
It's just a way of encoding data statements.

Instead of doing:

data $40,$41,$42

you are doing

data "@AB"

by relying on:

• ASCII '@' being $40
• ASCII 'A' being $41
• ASCII 'B' being $42
• etc

I can see that this would work, excepting of course that you already pointed out that non-visible ASCII characters can break it.
Naturally, I would avoid it as being unnecessarily cryptic unless you really, really needed to squeeze the number of characters down - like in the 10 line contest with limited character line length.

ZX81 pseudo hi-res graphics inspired the technique to approximate missing patterns in the set. 

 

There are 256 possible bit combinations between 00000000 and 11111111 but only a subset is available,

 

SuperCharger BASIC has a PRINT statement that prints binary strings on the screen and on the sprites, similar to the ZX81 bit painter it is 8 bits wide.

 

All 256 bit patterns are available to the PRINT statement except when the subset is limited like the subset in ZX81 pseudo graphics mode where approximations must be used in place of the missing patterns that are lost. 

 

Here's an example from chapter 5 of the BASIC Programming manual:

Visually redefining part of a sprite:
-------------------------------------
10 print %11111111(player0,0)
20 print %11000011(player0,1)
30 print %11111111(player0,2) 

We just printed three rows of pixels on the player1 sprite, which has 8 rows. Built in functions loadplayer0(n) and loadplayer0upsidedown(n) contain loops that read 8 rows of the sprite library starting at index n and load the player sprites much like this - you can write similar functions in vwBASIC.

Printing strings on the world with the PRINT@ command:
-------------------------------------------------------
You can poll,flip or set the individual pixels or bind the sprites to them with vwpixel but you can also print a binary string to the virtual world, 8 bits at a time much like the BASIC PRINT@ command.

print %10101010(virtualworld,3)
---------------------------------------
Prints the binary pattern block at the position of the 3rd byte - the table is 12 bytes accross to hold the 92 pixel wide virtual world, and 20 bytes deep, as per it's ASCII art definition. You can calculate the @ index by multiplying rows x 12 (row length) and adding to find the target byte column. 

 

[Mr SQL]

Latest version to the first post, think it's ready for the contest.

 

New features:

Added parallax scrolling and algorithmic chiptunes. Used the print command to draw the board.