Author Archives: Allen Huffman

About Allen Huffman

Co-founder of Sub-Etha Software.

Pi Problems.

I have six Raspberry Pis (three Pi Zero Ws, two Pi 3s, and one Pi 4). Tonight I tried to upgrade some of them.

  • My CoCo-Pi 3 unit booted and I was able to update it and install the latest CoCo-Pi emulator package.
  • My second Pi 3 booted to a kernel panic, and I am having to reinstall.
  • My first Pi Zero W got stuck on the Rainbow screen so I’ll have to reinstall it.
  • My second Pi Zero W has a different operating system running on it that I did not touch.
  • I also have a Pi 4 that is a retro game system, but I did not check it.

What makes these systems, when they just sit here idle (not powered on, haven’t been touched in months) not work? Anyone know?

I’ve had many Pis since the very first one came out, and I’ve had many issues with them over the years.

But I still buy more. Dunno why.

TheVIC20 USA Users Group

The replica Commodore VIC-20, known as TheVIC20, is not for sale in the USA and isn’t planned to be sold here. This is a limited edition version the C64 replica, TheC64, but in a VIC-20 enclosure with some different VIC software included.

It can be ordered from Amazon UK and shipped here, however, and then you use your own 1 amp USB power supply instead of the funky UK one that comes the box.

Although I don’t have one currently, one is being sent to me soon. So I started a users group…

https://www.facebook.com/groups/1228896444155278

Roger Taylor’s FPGA “Real CoCo” on MiSTer

A 1986 MacPlus on the FPGA MiSTer emulation hardware.

Earlier this year, I bought a MiSTer setup through Roger Taylor. MiSTer is an FPGA platform that can run recreations of consoles (Atari, Sega, Nintento, etc.), arcade games, and home computers (Apple, Commodore, etc.). Roger’s Matchbox CoCo FPGA project has been ported to it.

Here is the new Facebook group that covers all the various FPGA platforms Roger is working on:

https://www.facebook.com/groups/realcoco

Here is the MiSTer Wiki project page:

https://github.com/MiSTer-devel/Main_MiSTer/wiki

Here is Roger Taylor’s site:

I just unboxed mine and hooked it up the other night, and I am quite impressed. Being able to act as a virtualized hardware CoCo 3 as well as all the other machines is a game changer. Software emulators like MAME already let you do that, and I hope to do some comparisons between my Raspberry Pi emulator machine and this FPGA device.

And I still need to pick up a few more of the FPGA devices that can run the CoCo…

CoCo text screen can be changed in BASIC?

This writing is inspired by somethingI just saw in a YouTube video by 8-Bit Show and Tell:

In this video, Robin shows off an Easter egg found in the CoCo 2’s BASIC (the same one also found in the CoCo 1 since it was the same BASIC). He was wondering if there was any way to change the screen color (and I remember seeing someone ask this in the CoCo Facebook group but did not realize it was the Show and Tell guy). Australian programmer Nick Marantes gives him a “POKE 359,0:SCREEN 0,1” command to change the screen color… SCREEN can change the screen color? Surely I must have known this back then, but I had completely forgotten.

Thus, this article.

Nuclear Green CoCo Screen

The “nuclear green” screen of the Radio Shack TRS-80 Color Computer is certainly iconic. Black text on a green 32 column screen.

Disk Extended Color BASIC on the CoCo.

The Motorola MC6487 VDG chip contained a number of graphics modes, but only one text mode: 32×16 characters. The semigraphics modes supported up to 8 colors on the screen at the time, but text mode was limited to two colors: black on green. Well, except it was really a dark green on a light green. Here’s a zoomed in look, showing what color the text is compared to the black border:

CoCo “dark green” text on a nuclear green background with a black border.

I guess I sorta remembered this, because there was a way to invert the video to get light text on a dark background, and that background clearly wasn’t black:

Inverted text. Easy to do with a menu setting in the Xroar emulator.

I remember reading an article (probably in Rainbow Magazine) that showed how you could remove the VDG chip, pull up a pin, then plug it back in to the socket and get inverted video. I did that on my CoCo 1 since I thought that looked alot better (but not as good as if it was white on black like an Apple II or TRS-80 Model III).

The Xroar emulator has a menu option to toggle this inverted video.

But there was also a weird “pink” mode that I saw used in some early CoCo games. I recall reading a POKE or something that let you toggle it. You can also do that with the SCREEN command in Extended Color BASIC.

From the manual (page 96):

SCREEN type, color set displays the current graphics or text screen
type is 0 (text screen) or 1 (graphics screen)
color set is 0 or 1
Note: If type or color set is any positive number greater than 1, your computer uses 1.

Although not explained in the manual, you could select two color sets for the text mode. 0 was the normal dark green on nuclear green. 1 is the weird pink mode. But, when BASIC returns to the OK prompt, it resets the mode to 0, so you can’t use this to type things in (without a special POKE to bypass this reset). But, you can enter it in a program and then loop using a GOTO:

Alternate color set for text mode!

As soon as you hit BREAK and return to BASIC, the color resets to the green mode. The inverted mode looks like:

Inverted text color 1.

I don’t recall every using this mode, though I do recall at least trying it out with the POKE.

I do not know how to invert the video in software, but I expect there is a POKE to do that.

Anyway, there you go… alternate color sets for CoCo BASIC that you can access from BASIC using the SCREEN command.

More CoCo items (software, ROM-Paks, MC-10) for sale.

The great purge continues…

My CoCo 1/2/3 ROM-Paks:

https://www.ebay.com/itm/Radio-Shack-TRS-80-Color-Computer-CoCo-ROM-Paks/333745731777?hash=item4db4cbb8c1:g:fpcAAOSwjJFffRgC

Walt Disney cassette software (with boxes and everything):

https://www.ebay.com/itm/Walt-Disney-Radio-Shack-TRS-80-Color-Computer-CoCo-cassette-software-4-titles/333745728555?hash=item4db4cbac2b:g:x0QAAOSwqPBffRU~

Radio Ball (cassette game from Radio Shack):

https://www.ebay.com/itm/Radio-Shack-TRS-80-Color-Computer-Radio-Ball-game-on-cassette-w-packaging/333745757969?hash=item4db4cc1f11:g:tyYAAOSwCthffSKh

My MC-10 setup with memory expansion and Technical Service Manual:

https://www.ebay.com/itm/Radio-Shack-TRS-80-MC-10-computer-memory-expansion-and-software/333745738373?hash=item4db4cbd285:g:KaMAAOSwmZpffRu2

Radio Shack Appliance Light Controllers (Plug ‘n Power aka X-10):

https://www.ebay.com/itm/Radio-Shack-TRS-80-Color-Computer-Appliance-Light-Controller-NIB-X10-Plug-n/333745748407?hash=item4db4cbf9b7:g:wxgAAOSwZu9ffR6k

CoCo 3 “sealed in box” disk software: Where in the World is Carmen San Diego, Microsoft Flight Simulator II, and King’s Quest III:

https://www.ebay.com/itm/CoCo-3-Kings-Quest-III-Carmen-San-Diego-Flight-Simulator-II-NIB/333745755468?hash=item4db4cc154c:g:0bwAAOSwRKRffSGj

CoCo graphics tablet, video digitizer and speech recognition hardware for sale!

The great purge has begun! I have to downsize to about 50% of my current stuff, so it’s time to sell off all the CoCo gear I have that I will no longer be actively using.

First on the list is a Radio Shack X-PAD Graphics Tablet. This is still in the original box, with the original manual and template, as well as the plastic bags that came covering the pak and tablet! It’s as complete as it gets.

https://www.ebay.com/itm/333744740596

Next is the E.A.R.S. speech recognition system that was sold by Speech Systems. Yep, voice recognition on the CoCo! It could recognize 64 voice patterns, if I recall, and used simple BASIC commands to listen and match the voices. It needed a headset that was special so I don’t have a way to test it.

https://www.ebay.com/itm/333744732187

Then there is the Micro Works DS-68B video digitizer! Yep, the one with software that Tim Jenison (later of Newtek and the Video Toaster for Amiga) programmed! It works! But the label has come lose and will need to be “restored” with some glue.

https://www.ebay.com/itm/333744721237

Lastly, the Rulaford Research CoCo MIDI Pak with options — two switches that toggle the ports to THRU and OUT and such. I got this direct from Cecil Houk himself, and used it for years. I no longer have anything with MIDI, so … away it goes.

https://www.ebay.com/itm/333744735920

Please bid and help me raise some much needed money, and downsize at the same time. Thanks!

warning: comparing floating point with == or != is unsafe [-Wfloat-equal] – Part 2

Previously, I started discussing C compiler warnings, with specific intent to discuss this one:

warning: comparing floating point with == or != is unsafe [-Wfloat-equal]

I presented a simple question — what would this print?

int main()
{
    float var1;

    var1 = 902.1;

    if (var1 == 902.1)
    {
        printf ("it is!\n");
    }
    else
    {
        printf ("it is NOT.\n");
    }

    return EXIT_SUCCESS;
}

On my Windows 10 computer running GCC (via the free Code:Blocks editor), I get see “it is NOT.” This goes back to an earlier article I wrote about how 902.1 cannot be represented with a 32-bit floating point. In that article, I tested setting a “float” and a “double” to 902.1 and printed the results:

float 902.1 = 902.099976
double 902.1 = 902.100000

As you can see, a 64-bit double precision floating point value can accurately display 902.1, while a 32-bit floating point cannot. The key here is that in C a floating point number defaults to being double precision, so when you say:

var = 123.456;

…you are assigning 123.456 (a double) to var (a float).

float var1;

var1 = 902.1;

var1 (a float) was being assigned 902.1 (a double) and being truncated. There is a potential loss of precision that a compiler warning could tell you about.

If, with warnings enabled, comparing a floating point using == (equal) or != (not equal) is considered “unsafe,” how do we make it safe?

To be continued…

warning: comparing floating point with == or != is unsafe [-Wfloat-equal]

Ah, compiler warnings. We hate you, yet we need you.

Recently at my day job, I noticed we were running with a very low C compiler warning level. I decided to crank it up a bit then rebuild.

It was a disasters. Thousands of compiler warnings scrolled by as it churned away for about five minutes. Many were coming from header files provided by the tool company! Things like windows.h and even things they included from standard ANSI C headers like stdint.h. What a mess!

I was able to figure out how to disable certain warnings to clean up the ones I could not fix, leaving me with a ton of legitimate warnings in our own code.

Some were harmless (if you knew what you were doing), like comparing signed to unsigned values, which I’ve previously discussed. Some complained about missing or incorrect prototypes.

A favorite useful one is when it complains about initialized variables that could be accessed, such as:

int variable;

switch (something)
{
   case 1:
      variable = 10;
      break;

   default:
      break;
}

printd ("variable: %d\n", variable);

Above, if “something” did not match one of the case statements (1 in this example), it would never be set, and the print would be using whatever random crap was in the space occupied by “variable” later. This is a nice warning to have.

Others were about unused variables or unused parameters. For example:

int function (int notUsed)
{
     return 42;
}

Compiler warnings can notify you that you have a variable declared that isn’t getting used. You can tell the compiler “Yeah, I know” by doing this:

int function (int notUsed)
{
    (void)notUsed; // Not used!
    return 42;
}

Each time you clean up a warning like that, you tell the compiler (and others who inspect the code) “I meant to do that!” And, sometimes you find actual bugs that were hidden before.

I’ve written a bit about floating point issues in the past, but the warning today is this one:

warning: comparing floating point with == or != is unsafe [-Wfloat-equal]

Basically, while you can do…

int a;
int b;

if (a == b) { ...something... };

…you cannot…

float a;
float b;

if (a == b) { ...something...}

…at least, you can’t without getting a warning. Due to how floating point works, simple code may fail in interesting ways:

int main()
{
    float var1;

    var1 = 902.1;

    if (var1 == 902.1)
    {
        printf ("it is!\n");
    }
    else
    {
        printf ("it is NOT.\n");
    }

    return EXIT_SUCCESS;
}

What do you think that will print?

To be continued…

Bit shifting in BASIC

VIC-20 character blocks, bit shifted.

Recently, I had the urge to be lazy and have the computer do my work for me. I was designing some 8×8 graphics characters for the Commodore VIC-20 and wanted one for each offset position in a 2-character block (see image to the right).

Using modern tools like the Windows-based CBM prg Studio I could have easily edited each one by hand to get the desired result (which is what I did to create that image), but I thought it might be more fun to just design one character and write a program to create the other shifted frames.

I have bit shifted in C programming many times (because it has a bit shift operator) but I don’t recall ever knowingly doing it in BASIC.

Bit shifting basics

Bit shifting is where you take all the bits in a byte (or word, or long, whatever) and move them left or right. Here is an example of shifting the byte value 00111100 to the right:

Before: [ 0 0 1 1 1 1 0 0 ]
After : [ 0 0 0 1 1 1 1 0 ]

If you just want to shift and don’t care about the bit that “falls off the edge,” it is as simple as multiplying or dividing the value by 2.

To demonstrate this, we first need a program that will display a byte as bits.

0 REM bitsslow.bas
10 Z=&H00:GOSUB 500
20 Z=&HF0:GOSUB 500
30 Z=&H0F:GOSUB 500
40 Z=&HFF:GOSUB 500
50 END

500 REM PRINT BITS
510 FOR ZB=7 TO 0 STEP -1
520 IF Z AND 2^ZB THEN PRINT"1"; ELSE PRINT "0";
530 NEXT
540 PRINT:RETURN

The routine at line 500 will print the value in variable Z as bits. It is hard coded to only work with a byte (0-255). When I run that, this is what it displays:

00000000
11110000
00001111
11111111

Those lines correspond to &H00, &HF0, &H0F and &FF. I show them in hex so the bit pattern is easier to see (0=0000, F=1111).

A bit faster…

My bit printing routine is so slow that you can see it print the digits one at a time. This is due to the math that goes on in line 520 for each bit check. To speed things up, we could pre-calculate an array of those powers of two (1, 2, 4, 8, 16, 32, 64, 128) and use that instead:

0 REM bitsfast.bas

5 GOSUB 1000

10 Z=&H00:GOSUB 500
20 Z=&HF0:GOSUB 500
30 Z=&H0F:GOSUB 500
40 Z=&HFF:GOSUB 500
50 END

500 REM PRINT BITS
510 FOR ZB=7 TO 0 STEP -1
520 IF Z AND ZB(ZB) THEN PRINT"1"; ELSE PRINT "0";
530 NEXT
540 PRINT:RETURN

1000 REM INIT BIT ARRAY
1010 FOR ZB=0 TO 7
1020 ZB(ZB)=2^ZB
1030 NEXT
1040 RETURN

Line 5 will GOSUB to our initialization routine which sets up the power-of-two array ZB(). After that, the routine at 500 can be called as it previously was, except now it will print so fast you can’t really see it printing.

Now let’s use this routine to demonstrate bit shifting by multiplying or dividing by 2.

Bit shifting left

0 REM bitshftl.bas
5 GOSUB 1000
10 Z=1 '00000001
20 FOR A=1 TO 8
30 GOSUB 500
35 REM *2 TO SHIFT LEFT
40 Z=Z*2:NEXT
50 END
500 REM PRINT BITS
510 FOR ZB=7 TO 0 STEP -1
520 IF Z AND ZB(ZB) THEN PRINT"1"; ELSE PRINT "0";
530 NEXT
540 PRINT:RETURN
1000 REM INIT BIT ARRAY
1010 FOR ZB=0 TO 7
1020 ZB(ZB)=2^ZB
1030 NEXT
1040 RETURN

In line 10, Z starts out with 1, which is the bit pattern of 00000001. It is then multiplied by 2 in a loop eight times, each time shifting the bit one place to the left. The output looks like this:

00000001
00000010
00000100
00001000
00010000
00100000
01000000
10000000

Bit shifting right

And if we start out with Z being 128 (bit pattern 10000000) and divide by 2, it will shift right:

0 REM bitshftr.bas
5 GOSUB 1000
10 Z=128 '10000000
20 FOR A=1 TO 8
30 GOSUB 500
35 REM /2 TO SHIFT RIGHT
40 Z=Z/2:NEXT
50 END
500 REM PRINT BITS
510 FOR ZB=7 TO 0 STEP -1
520 IF Z AND ZB(ZB) THEN PRINT"1"; ELSE PRINT "0";
530 NEXT
540 PRINT:RETURN
1000 REM INIT BIT ARRAY
1010 FOR ZB=0 TO 7
1020 ZB(ZB)=2^ZB
1030 NEXT
1040 RETURN

This will display:

10000000
01000000
00100000
00010000
00001000
00000100
00000010
00000001

Pretty simple. And if that were all I wanted to do, I’d be done.

But that was not all I wanted to do, so I am not done.

I wanted to shift bits right in one byte and have the bits that shift out end up shifting in to a second byte, like this:

    1st Byte  2nd Byte
1) [00001111][00000000]
2) [00000111][10000000]
3) [00000011][11000000]
4) [00000011][11100000]
5) [00000001][11110000]
6) [00000000][11111000]
...etc...

I spent far too much time coming up with an approach that would get me which bits were going to be shifted off to the right (using AND), and then placing those in a new variable and then shifting those bits to the left to line up where they would have ended up if I had just shifted a 16-bit value…

…then I realized that was silly, because I could just use a 16-bit value in BASIC!

16-bits in BASIC

You may have seen things like this which print out memory locations BASIC is using:

PRINT PEEK(25)*256+PEEK(26)

In Color BASIC, memory locations 25 and 26 contain the 16-bit address for where BASIC memory starts. Since PEEK only works on a single byte, it takes two PEEKs to get the two bytes that make up the 16-byte address, and some math to turn the two 8-bit values into one 16-bit value.

On my virtual CoCo in the Xroar emulator, memory location 25 contains 38 (&H26) and memory location 26 contains 1 (&h01). To turn those two 8-bit values into a 16-bit address, I need to somehow shift the 38/&H28 left eight times into a new 16-bit value, and then add (or OR) in the 1/&H01 value.

In C, one of the ways we’d do this is by using the bit shift operator:

uint16_t Result;
uint8_2  Byte1;
uint8_2  Byte2;
Byte1 = Peek(25); // Made up function to get a memory value.
Byte2 = Peek(26);
Result = (Byte1 << 8) | Byte2; // Shift Byte1 left 8 bits,
                               // OR in Byte2.
// Or...
Result = (Byte1 << 8) + Byte2; // Since the right 8 bits are empty,
                               // adding would have the same result.

…but there are many other ways to do the same thing, some much faster than these two approaches.

Back to BASIC

Shifting left can be done by multiplying the value by 2. To shift once, you might have:

V = V * 2

To shift twice, you could do:

V = V * 2 * 2

…but that looks silly. You’d just multiply by 4. And to bit shift three places (2 * 2 * 2) you could multiply by 8. See the pattern? They are all powers of 2 (2, 4, 8, 16, 32, 64, 128, 256, etc.)

So to shift 8 places left, you multiply by 256. Thus, the C example I gave earlier is represented in BASIC by:

10 B1=PEEK(25)
20 B2=PEEK(26)
30 R=(B1*256)+B2

Tada! When I first saw things like “X=PEEK(Y)*PEEK(Z)” back then, I did not understand why it worked, I just knew it did. And I was also confused at why the CoCo was like that, since on the VIC-20 it would have been “X=PEEK(Y)+256*PEEK(Z)”. See the differences? On the CoCo’s 6809 processor, a 16-bit value is YYZZ, but on the VIC-20’s 6502 processor it is stored the opposite as ZZYY. Thus, on my VIC, you would take the second location and multiply it by 256 then add the first location.

But I digress.

A bit more…

The previous example shows how you are effectively shifting a byte (B1) left 8 places so it ends up at the top 8-bits of a new 16-bit value. Something like that would work very well for shifting an 8-bit value into different positions of two characters (two bytes).

My approach would be this:

  • R will be the result, a value representing 16-bits (two bytes, 0-65535 in range).
  • Since I am shifting right (in this example), my first step is to get the 8-bit source value into the top 8-bits (left most bits) of the R result variable.
  • Next I will shift that entire R variable to the right, and then extract the left and right 8-bits as separate variables which is my output values.

Extract? Well, that will be the reverse of what we just did. In C, you can turn a 16-bit value into two 8-bit values like this:

uint16_t Source;
uint8_2  Byte1;
uint8_2  Byte2;
Source = 0x1234;           // Some 16-bit value.
Byte1 = (Source >> 8);     // Shift left 8-bits to the right.
Byte2 = (Source & 0x00ff); // Mask off top 8-bits.

…though there are many other (faster/better ways to do this). But, we could do this in BASIC the same way.

If shifting left is multiplying by 256, then shifting right must be dividing by 256.

10 R=&H1234
20 B1=(R/256)
30 B2=(R AND &HFF)

IMPORTANT NOTE: As I got to a later point in this article, I discovered a huge problem with this approach. If you didn’t already know it (I didn’t), I’ll explain it in just a bit… When I write, I’m usually learning as I type, and I decided to keep this stream of consciousness intact.

That is the first time I’ve ever done it that way in BASIC (duplicating the way C does it). The way I’ve commonly seen it done in BASIC is this:

10 R=&H1234
20 B1=INT(R/256)
30 B2=R-(B1*256)

Here is a simple test program:

0 REM split1.bas
10 S1=&H12
20 S2=&H34
30 R=S1*256+S2
40 PRINT HEX$(S1)" "HEX$(S2)" -> "HEX$(R)
50 D1=INT(R/256)
60 D2=R-(D1*256)
70 PRINT HEX$(R)" -> "HEX$(D1)" "HEX$(D2)
Using BASIC to split 16-bit values, or combine two 8-bit values.

Benchmark digression

Have I been doing it wrong since the 1980s? Is the C-style way (using AND) any faster than the BASIC way (using INT)? Let’s try the C-style way using my trusty benchmark program:

0 REM split2.bas
5 DIM TE,TM,B,A,TT
6 R=&H1234
10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 IF Z=42 THEN 100
40 B1=R/256
50 B2=R AND &HFF
70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END

This shows 1143. (Of course it could be made faster using hex and removing spaces and such, but this is just for comparison with the second version.)

And now let’s try it the traditional BASIC:

0 REM split3.bas
5 DIM TE,TM,B,A,TT
6 R=&H1234
10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 IF Z=42 THEN 100
40 B1=INT(R/256)
50 B2=R-B1*256
70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END

This version reports 1498! Well I’ll be darned… INT and a divide and a subtract and a multiply is slow than a divide and an AND. Well, once I write it out like that, I guess it makes sense.

I suppose applying some things I learned in C to BASIC is paying off.

But I digress…

Are we there yet?

So getting back to the original task, I should be able to combine 8-bit values and split 16-bit values and shift them any way I want.

First let me modify the bit printing routine to handle 16-bit values.

IMPORTANT NOTE: Here’s the bit I was talking about earlier…

I thought I could just change the 0 to 7 into 0 to 15 to cover all 16 bits, but that resulted in an ?FC ERROR (function call). A bit of testing revealed that AND only works on values from 0 to 32767 (&H7FFF). That is the maximum value of a 16-bit SIGNED integer, which uses 15-bits for the number and 1-bit for the sign (+ or -).

Yipes! So I could only easily show 15-bits, and I really want that extra bit.

Note to Self: Look into the Color BASIC Unravelled book and see why this is.

So, it looks like I’ll just have to modify my 8-bit print routine to print each byte of a 16-bit value separately. Good thing we learned how to do that earlier in this article!

16-bit bit printing

Here is how I had to modify the routine:

0 REM bits16.bas

5 GOSUB 1000

10 Z=&H0000:GOSUB 500
20 Z=&HFF00:GOSUB 500
30 Z=&H00FF:GOSUB 500
40 Z=&HFFFF:GOSUB 500
50 END

500 REM PRINT BITS
501 ZZ=INT(Z/256):GOSUB 510
502 ZZ=Z-ZZ*256:GOSUB 510
503 PRINT:RETURN
510 FOR ZB=7 TO 0 STEP -1
520 IF ZZ AND ZB(ZB) THEN PRINT"1"; ELSE PRINT "0";
530 NEXT
540 RETURN

1000 REM INIT BIT ARRAY
1010 FOR ZB=0 TO 7
1020 ZB(ZB)=2^ZB
1030 NEXT
1040 RETURN

Whew! That works, and prints the following:

0000000000000000
1111111100000000
0000000011111111
1111111111111111

Okay, so I did not discover any amazing speedup (at least if we want to use values larger than 32767), but I did get it to work.

I saved the best bit for last…

Now we can try a little test to see if we can start with an 8-bit value, shift it to the left side of a 16-bit value, the start shifting one bit at a time right, then splitting up the resulting two bytes at each step. I will use a test byte of &HFF (11111111).

0 REM shift16.bas

5 GOSUB 1000

10 Z=&HFF  '11111111
15 Z=Z*256 '1111111100000000
20 FOR A=1 TO 8
25 REM SPLIT INTO TWO BYTES
26 B1=INT(Z/256)
27 B2=Z-(B1*256)
28 PRINT HEX$(B1)TAB(3)HEX$(B2)TAB(5)" = ";
30 GOSUB 500
35 REM /2 TO SHIFT RIGHT
40 Z=Z/2:NEXT
50 END

500 REM PRINT BITS
501 ZZ=INT(Z/256):GOSUB 510
502 ZZ=Z-ZZ*256:GOSUB 510
503 PRINT:RETURN
510 FOR ZB=7 TO 0 STEP -1
520 IF ZZ AND ZB(ZB) THEN PRINT"1"; ELSE PRINT "0";
530 NEXT
540 RETURN

1000 REM INIT BIT ARRAY
1010 FOR ZB=0 TO 7
1020 ZB(ZB)=2^ZB
1030 NEXT
1040 RETURN

And it displays:

Color BASIC shifting a 16-bit value and splitting it up into two 8-bit values.

Success!

I could now incorporate that routine into my code, and take the data for one 8×8 character (like the solid circle I started this article with) and end up with 16 8×8 characters representing each position it could be within a 2×1 block of characters.

2010 DATA 60,126,255,255,255,255,126,60

In conclusion…

Wow. That was a really long way to go to show multiplying by 256 and dividing by 2, wasn’t it? But maybe there are some useful routines in these examples.

And now it’s my turn to ask you:

  • Do you know a better/faster way to print 16-bit values in binary?
  • Do you know a faster way to combine two 8-bit values into a 16-bit value, or split a 16-bit value into two 8-bit values?
  • Is there a better/faster way to to bit shifting than multiplying or dividing by powers of 2?

Let me know in the comments, and maybe there will be a part 2 on this topic.

Until next time…