2024-01-09 – Corrected a PMODE 1 size typo from 8×18 to the correct 8×16, and a 16×17 typo.
Here is a quickie…
I did not know this was possible “back in the day,” and do not think I have ever tried it until now.
In Extended Color BASIC you can use “GET” to get a block of memory from the screen and store it in array memory. You can then “PUT” it back on to the screen.
But, if you know where the array memory is (using the VARPTR function) you can POKE bytes directly in to the array and then just PUT it without ever needing to GET.
10 ' GET/PUT ARRAY (2 ENTRIES) 20 DIM B(1) 30 ' PRE-ALLOCATE VARIABLES 40 DIM A,D,L,V 50 ' 256x192 (32X24 OF 8X8 CHARS) 60 PMODE 4,1:PCLS:SCREEN 1,1 70 ' GET ADDRESS OF ARRAY DATA 80 V=VARPTR(B(0)) 90 ' POKE 8X8 DATA IN TO IT 100 FOR L=V TO V+7:READ D:POKE L,D:NEXT 110 ' PUT THE DATA ON THE SCREEN 120 PUT(0,0)-(7,7),B 130 GOTO 130 140 ' BOMB DATA 150 DATA 24,24,60,118,122,126,126,60
This demo puts an 8×8 bomb on the top left of the screen. The bomb was one of the characters from my VIC-20 game Factory TNT.
VIC-20 Factory TNT character set in CBM prg Studio.
It does not look like you can use a multi-dimensional array got GET/PUT (does anyone know if this is possible?). Pity. If that were possible, I had something I wanted to try.
How much array memory do I need?
To know how many DIM array elements you need for an object, run this program:
0 REM pmodes.bas 5 CLS:INPUT "W,H";MW,MH:PRINT 10 FOR M=0 TO 4:READ M$ 20 PRINT "PMODE";M;"(";M$;")" 30 NEXT 40 PRINT 50 PRINT "M W X H W X H PXLS BYT E" 60 PRINT "- -- -- -- -- ---- --- --" 70 FOR M=0 TO 4 80 W=MW:H=MH 90 PRINT USING "# ##X##";M;W;H; 100 PRINT" -> "; 110 IF M<4 THEN W=W/2 120 IF M<2 THEN H=H/2 130 P=W*H 140 B=P/(8-4*(M AND 1)) 150 E=INT(B/5+.5) 160 PRINT USING "##X## #### ### ##";W;H;P;B;E 170 NEXT 180 IF INKEY$="" THEN 180 190 GOTO 5 999 GOTO 999 1000 DATA "128 X 96 X 2" 1010 DATA "128 X 96 X 4" 1020 DATA "128 X 192 X 2" 1030 DATA "128 X 192 X 4" 1040 DATA "256 X 192 X 2"
Type in the width/height and it shows you the memory requirements for that object on each PMODE screen. If it says it needs two elements, that is a DIM X(1) because DIM starts at 0. DIM X(3) would give you four — X(0), X(1), X(2) and X(3).
PMODE width and heights
Be aware that all PMODE screens use coordinates of 256×192, and scale to whatever resolution is being used (128×96, 128×192 or 256×192).
On a PMODE 4 screen (256×192), doing LINE(0,0)-(7,7),PSET,B draws a box that is truly 8 pixels wide by 8 pixels tall.
On a PMODE 2 or 3 screen (128×192), the same command would draw a box that was 4 pixels wide and 8 pixels tall.
On a PMODE 0 or 1 screen (128×96) would be drawing a box that was 4 pixels wide by 4 pixels tall.
If you truly wanted an 8×8 object on a PMODE 0 or 1 screen (128×96) screen, you would have to draw it as 16×16. An 8×8 object on a PMODE 2 or 3 screen (128×192) would be drawn as if it was 8×16.
Here is a short program that draws a 16×16 pixel box on each of the five PMODE screen types. It adjusts the width and height based on the mode to know how big of a box it has to draw which would appear as 16×16:
10 FOR M=0 TO 4 20 W=16:H=16 30 PMODE M,1:PCLS:SCREEN 1,1 40 IF M<4 THEN W=W*2 50 IF M<2 THEN H=H*2 60 LINE(0,0)-(W,H),PSET,B 70 LINE(0,0)-(W,H),PSET 80 LINE(W,0)-(0,H),PSET 90 IF INKEY$="" THEN 90 100 NEXT 999 GOTO 999
And that is not confusing at all ;-) But it did mean that you could draw anything as if it were a PMODE 4 screen and then draw it on any lower resolution screen without changes — you could just lose detail.
But I digress. It looks like I should write a new article series…
If I would have told my teenage-self that one day I would be corresponding with Radio Shack ROM-Pak game programmer, Rick Adams, I would have not believed myself. Rick became a very well known name in the CoCo community, and I remember seeing his name in the title screen of Radio Shack ROM-Paks. Temple of ROM was one I played at Radio Shack, but never owned. I just recall thinking it was like a fancy version of my all-time favorite Atari VCS game, Adventure.
But I digress…
It started with a message containing a screen shot:
Rick had simplified the program by breaking up the pattern in to sections he could GOSUB to and print a few lines. It was simple, and smaller than printing the whole thing.
“Why line 2046?” I asked. Apparently, the PDP-8 BASIC he was using had that as the highest line number. This was one of many restrictions this version of BASIC had. Through our chat, I learned it had a limit to the length of a string, and could not do things like MID$(A$,1,1)=”A” which were methods I had been toying with.
The next thing he sent me was optimizing this pattern further, breaking it up in to just one part of the diamond shape:
1 DIM A$(4) 10 FOR I = 1 TO 4 20 READ A$(I) 30 NEXT I 40 FOR I = 1 TO 4 50 PRINT A$(I);A$(I);A$(I) 60 NEXT I 70 FOR I = 3 TO 1 STEP -1 80 PRINT A$(I);A$(I);A$(I) 90 NEXT I 300 DATA " * " 301 DATA " * * " 302 DATA " * *" 303 DATA "* " 2046 END
This proof-of-concept code worked by loading this pattern in to an array. It can print the top array string three times across the screen, then continue through the pattern. Then, for the reverse diamond, print the array backwards. This version was clever, though it left off the right-most asterisk of the bottom/middle row, which could be handled by adding an extra IF/PRINT for those lines. Neat!
But, even when packing everything together (the PDP-8 BASIC has its own way of combining lines using a backslash), it did not look like it would be the smallest approach to this challenge.
A bit later, I received this screen shot:
This, my friends, is what a programmer comes up with when they are tired of typing in Microsoft BASIC. Rick has a front-end (pre-processor?) that allows him to write nicely readable (for BASIC) code and then have it converted to Microsoft BASIC for loading on a CoCo.
I typed that in (well, not literally) to a CoCo and saw that it worked. But what is it doing? Let’s look at a packed CoCo version of this code he provided (adjusted to work on the 40 column screen):
This looks like a similar approach that Jason Pittman had mentioned he was working on — drawing the pattern as if it was two asterisks that just get further apart as they move down the line (then closer together as it continues).
Rick’s version appears to work by starting with an empty string – generated using the STRING$(20,32) for a string of 20 CHR$(32) spaces. As it goes forward through the loop, it changes the character in the string at position J+I to be an asterisk, then the character at position J-I to be an asterisk . At the top/bottom of each diamond, the offset is 0, so it is just putting the asterisk on top of itself.
Let me break this apart, closer to his original pre-preprocessed source. I will put some extra spaces in to space out the loops:
1 GOSUB 100 2 FOR K=1 TO 3 3 FOR I=1 TO 3 4 GOSUB 100 5 NEXT I 6 FOR I=2 TO 0 STEP -1 7 GOSUB 100 8 NEXT I 9 NEXT K 10 END 100 A$=STRING$(20,32) 101 FOR J=4 TO 16 STEP 6 102 MID$(A$,J-I)="*" 103 MID$(A$,J+I)="*" 104 NEXT J 105 PRINT A$ 106 RETURN
Line 100 – The subroutine creates an A$ of 20 space characters.
Line 101 – The FOR loop of 4 TO 16 STEP 6 will produce values of 4, 10 and 16. That matches the top spacing of the peak of the diamond shapes in the pattern:
Line 102 – at position J-I (I is set by a FOR loop before it GOSUBs to this routine) will be places an asterisk at that location inside the A$. The outer FOR I loop is 1 TO 3, calling this routine each time, so it would look like this:
I=1, J=4, 10, 16 (producing 4-1, 10-1 and 16-1 ... 3, 9 and 15). "..*.....*.....*....."
I=2, J=4, 10, 16 (producing 4-2, 10-2 and 16-2 ... 2, 8 and 14). ".*.....*.....*......"
I=3, J=4, 10, 16 (producing 4-3, 10-3 and 16-3 ... 1, 7 and 13). "*.....*.....*......."
Line 103 – this line does the same thing, but uses the position of J+I so the asterisk moves to the right each time:
I=1, J=4, 10, 16 (producing 4+1, 10+1 and 16+1 ... 5, 11 and 17) "....*.....*.....*..."
I=2, J=4, 10, 16 (producing 4+2, 10+2 and 16+2 ... 6, 12 and 18) ".....*.....*.....*.."
I=3, J=4, 10, 16 (producing 4+3, 10+3 and 16+3 ... 7, 13 and 19) "......*.....*.....*."
Since these two lines are adding asterisks to the same A$, the results actually look like this:
Line 104 – is the NEXT for the FOR/J, so it goes through all three entries (4, 10 and 16).
Line 105 – prints the modified string.
Line 106 – returns back to the main code.
You will notice that calling this routine like this misses the top line. Let’s look at the start of the program to see how it gets there:
Line 1 – This initial GOSUB to 100 is what draws that top line. When the program starts, all variables are zero. So the routine enteres with I set to 0, which would make J+I and J-I just be the J value, putting an asterisk at the 4, 10, and 16 positions:
"...*.....*.....*...."
Well. That’s clever.
Line 2 – This is just a FOR loop to draw the pattern three times.
Line 3 – This is the FOR loop that draws the top part of the diamond, but since I always starts at 0, it doesn’t draw the “top” row — that was done by LINE 1, and then when it draws the reverse/bottom of the diamond it will finish that pattern, which is the last row and start of the next diamond. (Confused yet?)
Line 4 – Draw the line for the top part of the diamond (inside the I loop of 1 to 3).
Line 5 – This is the NEXT for the top-to-bottom I loop.
Line 6 – This is a second I loop, that goes from 2 to 0.
Line 7 – Calling the GOSUB routine, so now it will be drawing like this:
I=2, J=4, 10, 16 (producing 4+2, 10+2 and 16+2 ... 6, 12 and 18) ".....*.....*.....*.."
I=1, J=4, 10, 16 (producing 4+1, 10+1 and 16+1 ... 5, 11 and 17) "....*.....*.....*..."
I=0, J=4, 10, 16 (producing 4+0, 10+0 and 16+0 ... 4, 10 and 16) "...*.....*.....*...."
And the second part of the GOSUB doing the right side of the pyramid shape:
I=2, J=4, 10, 16 (producing 4-2, 10-2 and 16-2 ... 2, 8 and 14) ".*.....*.....*......"
I=1, J=4, 10, 16 (producing 4-1, 10-1 and 16-1 ... 3, 9 and 15) "..*.....*.....*....."
I=0, J=4, 10, 16 (producing 4-0, 10-0 and 16-0 ... 4, 10 and 16) "...*.....*.....*...."
I have to admit, this year’s Logiker challenge stumped me. I had a few “clever” ideas on how to reproduce the pattern, but the code was larger than just printing out the pattern from arrays of strings.
Meanwhile, Jason Pittman kept posting revisions of his concept in the comments. In a response to part 2, he shared this:
This is the last attempt I came up with. It uses the same “-3 to 2 … ABS()” from the other example I sent on part 1. I think one potential trick here is to treat it as if you are holding a rubber stamp that stamps out three asterisks that are six spaces apart. You want to make this pattern by stamping it twice on each line. You’re keeping track of a starting position on each row (1027 + 32 for each row) and an offset to add and subtract to the starting position for each row. On the first line, the offset is zero, so you stamp it twice on top of itself at the starting position. On the next line, the offset is 1, so you stamp it twice, but one time you add -1 and the other time you add +1 to the starting position. Does this make any sense?
This was an optimization of his original approach, but it had one limitation that might prevent it from solving the challenge: The CoCo’s 32×16 screen is too small to display the entire image, and POKEing characters on the screen would be limited to just 16 lines of text. He was aware of this, and his program does POKE the full image, but it is POKEing past the end of the visible screen. Would this count? RUNning the program displays the pattern over and over again (which was done to avoid having a new line with an endless loop GOTO):
POKEing past the visible screen works here because I am emulating a Disk Extended BASIC CoCo, and the memory after the text screen is reserved for four pages of PMODE high resolution graphics. But, I suspect, if I ran this on a cassette based CoCo, it might be POKEing in to memory used for the BASIC program itself.
Perhaps the CoCo 3 could help, since it has 40×25 and 80×25 text modes? Jason tried that:
I may play around with LPOKE. This should get it on the 40 column screen. I bet there is a crafty way to (a) not do the last line manually outside of the loops (b) remove one of the FOR loops (c) Shoot, there’s probably some crafty wizard way to do it in one FOR loop with logical operators, but I wouldn’t ever find it.
In this version, Jason uses LOCATE(x,y) to position the cursor. That is what the CoCo 3 used instead of PRINT@ for text positioning. And it works!
It also feels better to use built-in BASIC text commands versus POKEing in to memory.
But he wasn’t done! He added this version:
10 WIDTH 40 20 FOR S = -15 TO 33 STEP 6 30 FOR X = 0 TO 18 40 IF S+X < 19 AND S+X >= 0 THEN LOCATE S+X,X:PRINT "*"; 41 IF S-X >= 0 AND S-X < 19 THEN LOCATE S-X,X:PRINT "*"; 50 NEXT X 60 NEXT S 70 GOTO 70
This one draws the same pattern, but in a very different way. It draws diagonal lines going down from the points at the top. Try it! It’s cool!
And, then this odd one, which creates the pattern by drawing the asterisks RANDOMLY, eventually getting them all on the screen.
…seems like it should be simple. Three asterisks, then six, then six, then four, then six, then six, then three… Spaces that go five, three, one, zero and then back up. Unhelpful.
But, it’s also just one pattern repeated across the screen three times…
* * * * * * *
And then it’s reversed, so I think if we can do the above, we can do the whole pattern. We see spaces of three, two, one, zero on the left, and zero, one, three, and five in the inside.
Color BASIC does not have a SPC() option (my VIC-20 did, I think) for outputting spaces, but TAB() will go to a specific column. Maybe we can figure out which column the asterisks should be in:
This gives us 4, 10 and 16. Then 3 and 5, 9 and 11, and 15 and 17. Then 2 and 6, 8 and 12, and 14 and 18. Finally, 1 and 7 and 13 and 19. I don’t know why, but I kind of like thinking about it as tab positions.
10 FOR SP=3 TO 0 STEP-1 20 PRINT TAB(SP);"*";TAB(6-SP); 30 IF SP<3 THEN PRINT "*"; 40 PRINT 50 NEXT
That would give us one of the pyramid shapes. To complete the bottom, we’d do another FOR/NEXT loop. At least, that’s what I would do. BUT, in a comment to part 1, Jason Pittman had a smarter idea:
Awesome! I’ve got an idea on this one but I’m not going to jump ahead this year and I’m just going to follow along.One thought here is that you could combine the two print loops on 100 and 110 by coming up with a series that goes “0 1 2 3 2 1”. I did it by replacing 100 and 110 with this: “100 FOR A=-3 TO 2:PRINT A$(ABS(ABS(A)-3)):NEXT”
Or, you could shorten that a little if you reverse the direction of the array (so that it looks like “VVV”) and use “100 FOR A=-3 TO 2:PRINT A$(ABS(A)):NEXT”
– Jason Pittman
I could print one diamond like this:
10 FOR A=-3 TO 3:SP=ABS(A) 20 PRINT TAB(SP);"*";TAB(6-SP); 30 IF SP<3 THEN PRINT "*"; 40 PRINT 50 NEXT
That prints almost the entire diamond, except for the final asterisk. Because, if I wanted to print three of them, I’d do this in a loop, then print the final asterisk row at the end.
Unfortunately, as I start going down this rabbit hole, I find the code of loops and such ends up looking larger than some much simpler approaches, like one shown to my by Rick Adams. His code was written for a PDP-8 BASIC, which lacks things like ELSE and MID$. His technique was to have strings representing parts of the pyramid:
" * " " * * " " * *" "* "
…then to print each string three times across the screen. This produced:
" * * * " " * * * * * * " " * * * * * *" "* * * "
…and then do it backwards. There is a missing “*” on the right, that gets printed with an “IF”. In a chat, we bounced around some ideas to shrink the code, but looking at his approach, it seems everything I try to do gets larger:
Try “run length encode” where DATA statements represent the spaces. Print that many spaces, then an asterisk, and repeat.
Try DATA statements showing the positions of the asterisks. DATA is large than a string.
Try simulating a “SET(x,y)” to draw it, but using PRINT@ on the CoCo. Alas, the CoCo 32×16 screen is too small to fit the whole pattern, so even if this was smaller, it would still require extra code at the end to scroll the screen and print the final few lines (as the top portion scrolls off). BUT, using a CoCo 3 40/80 column screen would work using LOCATE x,y instead. But still, larger.
Is there an elegant solution to this challenge that doesn’t involve just PRINTing strings?
Legendary Color Computer game programmer, Steve Bjork, is no longer with us.
I have much to say about Steve. I considered him good friend, and alwauys enjoyed meeting up with him when I would visit Southern California. I had not been in touch since the Covid-era, and I wish I had. This news comes as quite a shock.
I hope to share some fun stories about hanging out with Steve. Though many know him from his video games on TRS-80, the Color Computer, Gameboy, Genesis, Super Nintendo, and I think even something on Playstation, I knew him as my Disneyland/theme park friend.
As a local, Steve grew up around Disneyland, and even worked there in the 1970s as a Jungle Cruise skipper.
I spent many days hanging out with him at Disneyland, and early on he would tell me, “there’s more to see in California than Disneyland.” He would become my tour guide during these trips — taking me to Magic Mountain (where he worked in the 1970s), Knott’s Berry Farms, and places like Fry’s Electronics and In and Out Burger. Many of the things I love about visiting California are directly traced back to Steve suggestions.
My finances prevented me for visiting for many years, but I did meet up with him again in 2017. Then he introduced us to Rock and Brews – a restaurant connected to KISS members Gene Simmons and Paul Stanley.
There was always a new experience I would never have discovered on my own as an ignorant tourist ;-)
There are fun trivia things about Steve… He was an extra in The Goonies (if I have the movie correct), as a reporter. He was an extra in the movie Rollercoaster, I believe loading folks on a coaster. He has an Internet Movie Database entry through his work on One On One (basketball) and The Mask (Super Nintendo). He was a magician at some point — a tidbit that came up during an early theme park visit, complete with him presenting a “Hot Rod” trick he had with him (a trick I knew well from my younger days as an amateur magician).
There are many tales about his time in the software industry – such as a story about folks working on the TRON movie visiting computer places to ask questions. I think he worked for Datasoft at the time, which was “just down the road” from the Disney Studios.
If you look at the startup screen for The Rocketeer on Super Nintendo, I believe I heard Steve was the one wearing the suit for the photo (1992). Apparently props and such were loaned out so they could be used for reference for the game.
Steve also had a haunted house effects company — creating custom hardware and software to do things like make animated skulls talk to audio. An article about one of his products (“Wee Little Talker”) was featured in Nuts and Volts magazine (September 2017). You can see a photo of a circuit board with “Copyright 2017 Steve Bjork” on it. The article was co-written by his haunt partner, Steve Koci, who also passed away in recent years. Their business, Haunt Hackers, last updated in 2021 with a “closed due to Covid” message on the now-defunct website.
And people knew him. Once I was at Disneyland with him for some special opening event. A Disneyland manager type walked up to him and said “Steve Bjork, you’re my hero!” This person had known him through computer clubs back in the 80s. And that wasn’t the only time I saw something like that happen.
So while he popped up in CoCo discussions frequently (and got re-engaged in later years via the CoCoTalk YouTube show), it was also no surprise to see him pop up in an electronics publication or a haunted house message forum. I even remember reading a Disneyland fan site report about some event out there, and Steve Bjork was there presenting some kind of plaque to someone involved with a restaurant.
He did so much, and was still designing and programming new things right up to his final years.
This image is 19×19, so while it will fit on a Radio Shack Color Computer 1/2 screen width-wise, it’s a bit too tall to fit height-wise. The challenge allows for it to scroll off the screen, which is something we had to do for past challenges.
Logiker 2023 Challenge pattern.
I can think of a number of ways to approach this.
The pattern is made up of only four unique lines, so you could print them A B C D B C A B C D and so on. There’s probably a simple way to do that with a FOR/NEXT loop and an array of those four lines.
10 CLS 50 A$(0)=" * * * 60 A$(1)=" * * * * * * 70 A$(2)=" * * * * * * 80 A$(3)="* * * * 90 FOR I=1 TO 3 100 FOR A=0 TO 3:PRINT A$(A):NEXT 110 FOR A=2 TO 1 STEP-1:PRINT A$(A):NEXT 120 NEXT 130 PRINT A$(0) 333 GOTO 333
If we had a larger screen (like the 40 or 80 column screens on the Color Computer 3), we could use LOCATE x,y to plot the pattern using some line drawing type math.
We could try the RLE (run length encoding) compression from past years to see if we could compress it down to spaces and characters.
We could try using math to figure out a pattern.
These all seem fun.
I hope to find some time to experiment. I don’t plan to “enter,” since one of the asks for the challenge is to not share your work until after the challenge ends.
VAL() takes a string and converts it in to a floating point numerical variable. The value of “1E39” is a number in scientific notation, and this appears to cause a problem.
In Microsoft BASIC, the notation “1E39” represents the number 1 multiplied by 10 raised to the power of 39. This is also known as scientific notation, where the “E” indicates the exponent to which the base (10 in this case) is raised. So, “1E39” is equal to 1 * 10^39, which is an extremely large number:
There is a classic Commodore one-liner program that prints a maze. I have discussed it on this site several times in the past:
10 PRINT CHR$(205.5+RND(1));GOTO 10
I converted it to use CoCo ASCII “/” and “\” characters:
10 PRINT CHR$(47+(RND(2)-1)*45); : GOTO 10
I have since noticed that the 10 PRINT book even has a version for the CoCo in it:
https://10print.org/10_PRINT_121114.pdf page 55
Recently, Jim Gerrie posted a video of a new one-liner MC-10 version of the maze that truly fit on one 32-column line of the MC-10:
https://www.youtube.com/watch?v=7FQ_ht5u2y4
His approach of using MID$() looked much simpler than the CHR$ version of the Commodore original. I am pretty sure my VIC-20 had MID$ so surely the C64 had it as well. Why wasn’t it used? Perhaps this was an example of code obfuscation. “Type in this mysterious code and see what you get!”
Indeed, in a quick test, using MID$() is smaller and faster:
Now, doing the MC-10 version with CHR$() would be longer on the CoCo since we can’t type those characters like the MC-10 allows. We’d have to use CHR$(140)+CHR$(138) embedded in the MID$ to make that work (and be much slower since it would parse those numbers for every byte of the maze it prints). But…
0 PRINTMID$(CHR$(140)+CHR$(138),RND(2));:GOTO
…does work.
To make it faster, we’d need two lines and a string:
Even with that, the GOTO is slower than the MC-10 version since it has to parse a number, and then has to skip a line each time. You could get around that by doing it like this, and starting it with “RUN 1”:
I recently shared the story about my first commercial CoCo product, the Huffman K1 Librarian. This was a MIDI librarian for the Kawai K1 synthesizer. In that article, I mentioned that I later sold my K1 to buy a more-better Kawai K4 synthesizer. What I did not remember is that I apparently made a K4 librarian, as well!
The K4 version was very similar to the K1 original, but the menu was updated to reflect how patches were organized on the K4. It appears the K4 has single patches, blocks of patches, and a way to transfer everything at once.
It also had the same disk command menu.
This version shows a 1991 copyright, so two years after the K1 original in 1989. Although the title screen references Rulaford Research, I do not recall it ever being a product they sold. I’m not sure if anyone ever had a copy of it other than myself. If you know otherwise, please leave a comment.
Thirty two years later and I am still (re)discovering stuff.
Although I was “this close” to having my *ALLRAM* BBS sold by a well-known CoCo company back in 1983 it wasn’t until 1989 that something I wrote appeared for sale in the pages of Rainbow Magazine.
Rainbow Magazine, November 1989, Page 111.
I had gotten my first musical keyboard (a Suzuki Keyman PK-61) during high school, and then acquired a Casio CZ-101 synthesizer. After graduation in 1987, I purchased the CoCo MIDI interface from Rulaford Research. This started my love for MIDI and creating keyboard music which I still enjoy today (just without MIDI, as it’s been replaced by virtual instruments on a computer and USB piano keyboards).
There were two main types of MIDI programs. A sequencer allowed recording the keys pressed on a MIDI keyboard and playing them back. This was a high-tech player piano, but instead of a roll of paper with holes punch in it triggering hammers hitting strings, it was serial byte codes going to a synthesizer or sound module playing notes. Lester Hands’ sequencer was quite an achievement for a 64K CoCo.
The second type of program was called a librarian. These programs would use special messages the synthesizer supported to download sound data (the “patch” or “voice” as keyboards called them) and save it to tape or disk. You could later upload that information back. This allowed saving out all the sounds a keyboard made, and loading in new ones. Or, backing up custom sounds you created.
There was a third type know as an editor, but I never had any of those so I cannot really comment on them.
I recall buying a Casio CZ-101 Librarian from Rulaford Research.
I eventually saved up enough to buy a Kawai K1 full-size synthesizer. I learned enough about how the CoCo MIDI hardware pak worked (thanks to my Commodore friend Mark finding the data sheet) to create routines to read and write data through it. This, and some technical information on the SysEx (system exclusive) MIDI messages of the K1 led me to create a librarian for that synth. I had been in communication with Cecil Houk of Rulaford Research and he suggested putting my name in the title so it would be an instantly unique title (rather than something generic like “Kawai K1 Librarian”).
The end result was the Huffman K1 Librarian, shown here at version 1.2. I have no recollection of what changed between 1.0, 1.1 and this version.
At the time, while many of us had copies of software we did not purchase, I didn’t like having copies of anything that asked me to not copy it. I included the message “Support the future of music on the Color Computer. Please do not pirate this program.” on the title screen.
The main menu allows sending a single patch (voice) to and from the K1, or a block (which was a bank of many patches).
I do not recall much about how the K1 LCD screen looked, but I know it used an uppercase “I” or “E” (internal/external) as well as lowercase “i” or “e” for the singles voices.
The voices were divided up in to four banks (lettered A to D) with 8 patches in each. It was basically octal! This is the only time I’ve seen base-8 numbering used (though in this case, it would be like A1-A8 to D1-D8 rather than 00-38 in octal).
To dump (upload) a patch to the synthesizer, you had to type the name of the patch file. I built-in a Directory command similar to how the Casio Librarian did it.
This may have been the first time I ever made use of DSKI$ to manually parse the directory table of the CoCo’s disk format.
I also added a disk menu to give a fuller directory, kill files, rename files, and copy files.
Here was my copyright notice in REMarks at the top of the program. From looking at the CLEAR command, that reminds me that my assembly language MIDI routines loaded at &H7000.
Also note I set a variable DR (current drive) with a PEEK, rather than hard-coding a default of drive 0. This meant if the user had done a “DRIVE 1” and was running it from that drive, it would default to using drive 1. I had forgotten about this technique.
I guess I typed too soon. At the end of my programmer version notes, so now I know about 1.1 (add error checking) and 1.2 (more error checking). Nice.
Beyond looking at the menu screens, today I have no way to do anything with this program. I sold my Kawai K1 long ago, and upgraded to a K4 :) I eventually sold that and replaced it with a Yamaha W7.
Humble beginnings, and fun times. I hope you enjoyed this look back at my earliest commercial product.
