Game announcements are not my main focus here in Vintage is the New Old anymore – it is very hard to keep up and there are plenty of other ways to be up to speed with what is new in the retro gaming world, like, for example, Saberman’s YouTube channel, which does a fantastic job showing footage of most (if not all) new retro games coming out every day.

Through Saberman’s YT channel, I learned about Veggies vs. Undead, a redemption of the famous casual game developed by PopCap Games, Plants vs. Zombies. This release caught my attention because probably my favourite genre is tower defence games, and Plants vs. Zombies is, in my opinion, one of the best tower defence games released in the past few years.

I’ve played PvZ for hours and hours on my phone and tablet. The slightly different approach PopCap took from the usual tower defence game got me hooked, and the comic-style graphics made it even better. The zombies are hilarious, and even the more boring plants have their charm.

When I first saw Veggies vs. Undead in action, I thought it looked pretty good, and the C64 graphics caught the PvZ style almost perfectly. The next step was to download the game and try it myself.

After playing it for a few minutes, to my surprise, there are no compromises in bringing the game to the 8-bit platform! The same gameplay is all there; the different zombies and plants are present, the graphics are excellent, and the music completes it. When I realized I had spent the past two hours playing it non-stop!

As PvZ, Veggies vs. Undead levels introduce new plants and new zombies that will help you get through the ranks and raise the difficulty level, respectively. As in the original, you can also play at night, where you have to rely on mushrooms to get you “sunlight” to buy the plants faster. This mode is challenging, and easy to lose control and the game!

Mr. Mortal Wombat developed the game, and it is available on itch.io! If you want the casual gaming feeling, but using a much cooler machine, Veggies vs. Undead should be on your list to try next!

Link: Mr. Mortal Wombat

Scene World was prominently featured in the 04/2023 issue of the German design magazine PAGE.

featuring logos from Retromantis, Black and JSL made for Scene World Magazine!

(The text translates as “pixelated till today, the diskmag “Scene World” for C64 fans and coders can be downloaded for fitting hardware at https://sceneworld.org”)

In our new episode we are happy to talk to Julia Minamata. She is the developer of ‘The Crimson Diamond’ – a text parser EGA mystery adventure game to be released soon on Steam! Follow amateur geologist and reluctant detective Nancy Maple to the ghost town of Crimson, Ontario to investigate the discovery of a massive diamond. Sounds like a wonderful classic adventure experience! Enjoy! Interview starts at 12:57 minutes

Listen to / watch: https://scene.world/crimsondiamond

Darren Doyle from Greyfox Books has announced today that his book about the SEGA Mega Drive is available for free as a downloadable PDF. Although this alone is good news for all Mega Drive (and Genesis!) fans, the reason Doyle decided this route is unfortunate, to say it lightly.

After publishing “Atari: a Visual History” and “Coin-Op: The Arcade Guide“, Grayfox Books wanted to create a similar book dedicated to the SEGA Megadrive. Back in 2021, they created a Kickstarted campaign aiming to publish the new book as a physical copy. Still, at some point during the process, the initiative caught SEGA lawyers’ attention, and Greyfox Books were notified that they should stop the project through a Cease and Desist notification. I am no lawyer, but I think there is no merit in this request; but like most Retro Gaming projects that are made out of love and are usually not profitable, who would have the resources to fight back? I imagine Darren had the same thinking and decided to give up simply.

Thankfully, Doyle had his heart in the right place and thought that although he couldn’t sell the book, nothing would prevent him from letting the community enjoy his work for free.

The Mega Book Collection is a Digital PDF Book containing over 290 pages (full colour) to celebrate the incredible 16-bit Sega generation across three of their famous Sega Megadrive addons in one great visual opus. The Sega Megadrive, The Sega MegaCD addon and the Sega 32x addon. Also in the book, you can read about an exclusive interview with “Chris Shrigley” founding member of Core Design, along with a main feature covering the company’s Sega Megadrive days.

The 19th edition of MSXDev has started. The competition that began in 2003 has brought to life many high-quality games for the MSX.

The 2023 edition will follow the previous year’s “freestyle” approach, where the game can be created for any MSX machine that was ever sold.

If you think you will try to create something this year, you have roughly eight months to develop the next MSX best game of the year. The MSXdev23 enrollment program officially started on February 15, 2023 and ends on October 14, 2023.

As for prizes, the MSXdev relies entirely on the support of the MSX scene by accepting donations and sponsored items. This tradition has fared well and should be no exception this year. Join the dev and donate to the cause.

You can find all details for the compo by following the link below.

Link: MSXDev 2023

Recently I learned about an exciting project that started a couple of years ago: ugBasic.

ugBasic is a cross compiler of BASIC dialect specialized in programs that are very efficient by design on various 8-bit platforms built on top of 6502, Z80 and 6809. This is a tall order, but ugBasic seems to pull it off very well.

ugBasic comprises several compilers, one for each platform, and an IDE where you can code your BASIC programs and deploy them to the specific platform of your choice. The BASIC can use or not line numbers and offers modern features like subroutines using labels and functions, for example. There are keywords to manipulate sounds and graphics as well.

The IDE is very powerful, and setting up your target platforms, and the emulators is very simple. After you are all set up, you will see a menu option to compile your program for each platform, and another one to bring up the emulator and load the program there to be executed.

The language managed to group the commands very well, covering the most common characteristics of the 8-bit machines that it supports. The example below clear the screen to Black sets the colour to yellow and draws a few circles on the screen.

BITMAP ENABLE
CLS BLACK
INK YELLOW
CLIP 20,20 TO 50,50
r = (POSITION) 0
FOR r=4 TO 96 STEP 4
    GR LOCATE 10, r
    CIRCLE ,,r+9
NEXT

HALT

The project’s page on GitHub has many examples, and the online documentation is excellent (My pet peeve: Google Ads all over the place makes it a bit annoying to read it on mobile devices, like any website that displays this type of advert).

I’ve tried many of the examples, and although they all compiled and ran on all my targets (Plus/4, Atari, CoCo), I’ve got different results. This shows that, even with a powerful tool like ugBasic, writing for different platforms still requires you to know how the specific target works and adjust your program accordingly – for example, all machines have different address maps, and if you need to resort to POKING data directly to memory, no magic will make it work in all targets. This is not a flaw with ugBasic, but the expected behaviour when dealing with so many radically different machines. Remember that there is no 100% “write once, run everywhere”!

If you want to see ugBasic in action, you can check Soko64, a Sokoban game made for the Commodore 64, and 4 Gravity, a Connect 4 clone. The latter is probably a more suitable game to compare different platforms since it is available for the C64, Dragon, Atari, Olivetti PC128, and the VIC-20.

ugBasic is a Windows-only application, so if you are a MacOS user like me, you will need to resort to Parallels or another method to run Windows applications.

Link: ugBASIC

NOTE: If what I describe in this article applies to other implementations of BASICs that use reserved string space, please leave a comment and let me know.

I was in junior high school when I started learning to program BASIC. Initially, this was done by reading a book a classmate had and then writing programs out on paper. We’d then go in to a Radio Shack and type them in on a TRS-80 Model 3.

I really started to learn after my dad got me a $299.99 Commodore VIC-20. I stayed up all night going through the manual and typing in examples.

A year later I would do it all again with the manuals that came with my next computer, a 64K Radio Shack TRS-80 Color Computer.

Since I had learned under Radio Shack Model III Basic, CBM BASIC V2, and Extended Color BASIC, I was aware that different BASICs had different commands and features. The VIC-20 used “GET A$” while the CoCo used “A$=INKEY$“. Same dance, different song.

When I began exploring my old VIC-20 programs a few years ago, I dove back in to CBM BASIC and learned there were more differences than I was aware of back in 1982. For example, CBM BASIC seemed to allow declaring as many strings as you wanted until you were out of memory. On Color BASIC, string memory was pre-allocated and defaulted to 200 bytes. You used the CLEAR command if you want to increase or decrease that amount.

If Microsoft did both variants of BASIC, why such different string handling?

Color BASIC string storage

On the CoCo, memory looks something like this:

+---------------+
| BASIC ROM use | 0-1023
+---------------+
|   32x16 text  | 1024-1535
+---------------+
| DISK ROM use  | (if present)
+---------------+
| EXT BAS gfx   | (if present)
+---------------+
| BASIC Program |
+---------------+
|   Variables   |
+---------------+
|     Arrays    |  
+---------------+
|               |
|               |
+---------------+
| String Space  | (200 bytes, default)
+---------------+

Variables that are strings and Arrays that are strings will have entries that point to the actual string data elsewhere in memory — either in String Space or as constant string data in the program itself. For example, typing this in a program:

10 A$="This string will be in program space."

…will consume 0 bytes from the String Space area. Those types of hard-coded strings work even if you set String Space to none using CLEAR 0. But, the moment you want to modify the string using LEFT$, RIGHT$, etc., it will be copied in to String Space memory so the modifications can be done.

If you type this directly as a command:

A$="This string will be in string space."

…it will go to String Space since there is no program to hold those characters. If you want to force a constant string to be in string space, you can simply add “” to it, like this:

10 A$="This string will be in string space."+""

By doing that addition/concatenation with plus, a new string has to be made that will hold the original string plus the new one. BASIC doesn’t bother to check to see how large the new string is — which is 0 in this case. BASIC could have been much smarter about a lot of things.

But where does it all go?

In the first 1K of RAM that is reserved for us by the BASIC ROMs there are a series of 2-byte memory locations that BASIC uses to track string space. There is an excellent book that came out in the 1980s called Color BASIC Unraveled. It was a commented, disassembly of the BASIC ROM with other editions came out for Extended, Disk and CoCo 3 BASIC. In the original book, it listed these areas of interest:

From Color BASIC Unravelled, page A1.

The first column is a line number in this source listing, followed by the memory location where the code (or reserved memory in this case) is. We see that TXTTAB (“beginning of BASIC program”) is two bytes starting at hex &H19 (25 in decimal). To see where a BASIC program starts, we can type:

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

Next is VARTAB (“start of variables”) at hex &H1b which, as our memory map showed, is directly after the BASIC program. Thus, to see how large a BASIC program is, you could subtract the two:

PRINT (PEEK(27)*256+PEEK(28)) - (PEEK(25)*256+PEEK(26))

This is great fun at parties, but not important for this article.

Instead, we will look at three near the end: FRETOP (“start of string storage”), STRTAB (“start of string variables”) and MEMSIZ (“top of string space”).

FRETOP

FRETOP (&H21 / 33) will be where the reserved String Space starts. This memory is protected from BASIC, so the BASIC program, variables and arrays cannot grow past this location.

MEMSIZ

MEMSIZ (&H27 / 39) is the end of that String Space area, and it is always at the end of BASIC memory. On the CoCo, that could be 4094 on a 4K CoCo, 16382 on 16K CoCo, 32766 on a 32K CoCo, 32766 on a 64K CoCo.

If you are paying attention you may have noticed two things: 1) the memory location seems to be one byte short of what 4K, 16K or 32K should be, and 2) on a 32K or 64K CoCo, you only get the first half of memory for BASIC.

Both are true. The reason for the first is “I don’t know*.” The reason for the second is “because ROMs and 1980 design and compatibility and reasons.”

I did find it interesting that on a Color Computer 3 (released in 1986 with 128K, expandable to 512K), the value is 32767. Someone at Microware, where the enhancements to Microsoft BASIC were done, must have fixed this and given us that one extra byte. And to think, we spent all those years telling folks that upgrading to a 128K CoCo 3 wouldn’t give you any more memory for BASIC.

But I digress…

Those areas show the start and end of the reserved string space (well, almost, since the first actually points to one byte before it begins since it’s really the “top of free RAM” and represents the last byte BASIC could use).

STRTAB

STRTAB (&H23 / 35) marks the address inside that area of memory where the next string will be added. If string space is empty, it will be the same as MEMSIZ. If every last byte of string space is taken, it will be FRETOP.

These values are used by BASIC to know where to insert new strings, or tell if you just need to be shown that wonderful ?OS ERROR (out of string space) message.

Looking at String Space

Here is a simple example of what string space looks like. In this example, it is showing what would have been a CLEAR 16 with only 16 bytes reserved for String Space. I did this just so it would be simple to look at:

FRETOP                                     MEMSIZ
 |                                            |
[.][.][.][.][.][.][.][.][.][.][.][.][.][.][.][.]
                                              |
                                           STRTAB

When a new string is created, BASIC will move STRTAB the length of the string, then copy the string in to memory. The variable table elsewhere (after BASIC program) will have an entry with the size of the string and that memory location. Let’s add a ten byte string:

A$="1234567890"

FRETOP                                     MEMSIZ
 |                                            |
[.][.][.][.][.][.][1][2][3][4][5][6][7][8][9][0]
                   |
                STRTAB

We could then create a new 4 byte string:

B$="ABCD"

FRETOP                                     MEMSIZ
 |                                            |
[.][.][A][B][C][D][1][2][3][4][5][6][7][8][9][0]
       |
    STRTAB

And now we have only 2 bytes left. We could do C$=”XY” and that would work, but if we tried C$=”XYZ” we would receive ?OS ERROR.

Trash Day

When strings are replaced with shorter strings (such as A$=”HI”), or empty strings (such as B$=””), those new strings will first be added to string memory if there is room. If they can, the variable table entry will be updated to point to the new string. The bytes used by the old string will still there, but nothing points to them so they are now considered free/unused.

When a string needs to be allocated and there isn’t enough room between FRETOP and STRTAB, BASIC will attempt garbage collection. It will look for any free/unused string memory, then pack all the used strings down and adjust pointers accordingly. If there are a bunch of strings in use, the BASIC program will pause for a moment while this happens.

Too. Many. Words.

So rather than write about this, here is a simple program that lets us see the string memory and watch what happens as strings are replaced.

0 ' STRSPACE.BAS
10 CLS
20 GOSUB 200
30 PRINT@320,"TYPE A STRING:":PRINT:PRINT:PRINT:PRINT
40 PRINT@352,;:INPUT A$:GOSUB 100
50 GOTO 20

100 ' SHOW STRINGS
110 GOSUB 200:VR=1088:L=FT+1
120 IF L<=ST THEN C=96:GOTO 160
130 C=PEEK(L):IF C<32 THEN C=96:GOTO 160
140 IF C<64 THEN C=C+64:GOTO 160
150 IF C>=96 THEN C=C-96
160 POKE VR,C
170 VR=VR+1:IF VR>VR+288 THEN RETURN
180 L=L+1:IF L>MS THEN RETURN
190 GOTO 120

200 ' GET/SHOW STRING INFO
201 ' FT = FRETOP
202 ' ST = STRTAB
203 ' MS = MEMSIZE
210 FT=PEEK(33)*256+PEEK(34)
220 ST=PEEK(35)*256+PEEK(36)
230 MS=PEEK(39)*256+PEEK(40)
240 PRINT@0,"FT:";FT;" ST:";ST;" MS:";MS;
250 RETURN

This program will INPUT A$, then display the (default) 200 byte string buffer. Each time you enter a new line, the old A$ is orphaned (marked free/unused) and the new A$ will be added at the end. When you finally fill up all 200 bytes, BASIC will clean up the string space, moving everything down but the current A$ (which is in use, but about to be replace) and then adding the new A$, orphaning the old one. It looks like this:

STRSPACE.BAS

It’s pretty neat to see it actually work. And, with this routine, you could actually write a little demo to test specific things, like this:

0 ' STRSPAC2.BAS
10 CLS
20 GOSUB 200
30 A$="1234567890123456789012345678901234567890"+"":GOSUB 100
31 B$="ABCDEFGHIJKLMNOPQRSTUVWXYZ"+"":GOSUB 100
32 C$="abcdefghijklmnopqrstuvwxyz"+"":GOSUB 100
33 A$="":GOSUB 100
34 D$="********************************"+"":GOSUB 100
35 E$="================================"+"":GOSUB 100
36 F$="ARE WE OUT OF STRING SPACE YET? IF NOT I WILL ADD MORE"+"":GOSUB 100
37 G$="HELLO"+"":GOSUB 100
99 PRINT@352:END

This code would add A$, B$ and C$. Then A$ would be added as nothing, making the old A$ data available for purging at the next garbage collection time. D$, E$ and F$ are added, and during this, garbage collection will be needed and you’ll see the old A$ disappear. Finally, a short G$ is added to the end.

…or any other combination of adding strings or replacing strings that you’d like to see happen.

And yes, this routine is very very slow, so if anyone is interested, I’ll do a follow-up article with the display routine done in assembly language.

Conclusion

Is this useful? Not really. Most of us just use a CLEAR value large enough that our program won’t crash when using strings and get on with it.

But … in 1983 I wrote a cassette-based BBS (bulletin board system) called *ALLRAM* BBS. It stored the userlog and messages in RAM. At the end of the day, the SysOp (system operator) could save them to tape, and reload them the next time the BBS was ran. I had to make sure that even at 100% (every userlong entry full to the longest strings, every message line full to the longest lines) the BBS would not crash. I had to calculate string usage for worst case. But, had I understood how BASIC worked back then, I could have made a much smarter routine that would make the code automatically purge older messages when string space was about to run out. (I actually have an article I am working on for my website that deals with this.)

I guess the conclusion is … maybe it might be useful?

I definitely think is is kind of cool to see what is going on. I had no idea any of this went on, and didn’t care, when I was learning BASIC back in the early 1980s.

If you find this article kind of cool, consider buying the hosts of this website a cup of coffee. (That’s their donation page. Give it a click sometime.)

Until next time…

* I don’t know, but William “Lost Wizard” Astle did.

The BASIC keyword “VAL” turns a string in to a number, and one of the routines it uses scans a string that it expects to be terminated with a 0 at the end. Strings in String Space have no such termination, but apparently that’s how this routine operates. In order for it to work on a string stored at the very end of String Space, it temporarily POKEs the byte after string space to a 0, thus creating a 0-terminated string. After the routine is over, it restores the original byte. If String Space had gone to the last byte in RAM, the next byte would have been ROM and this would not work. Microsoft left that byte free for this purpose.

When Microware patched Microsoft Color, Extended and Disk BASIC for the CoCo 3, they replaced the RAM scan that Color BASIC used with a different one, and either intentionally “fixed” this, or didn’t know it was done that way for a reason. On the CoCo 3, the BASIC ROMs are copied from ROM in to RAM and then patched, so the entire 64K is running out of RAM, and thus VAL is temporarily patching the first byte of the Extended BASIC ROM at 32768 (&H8000). Since no active code is there, it does not harm and “just happens to work.”

Either clever, or an oversite, but no harm done, and as a consequence, I guess we get that one extra byte for our programs.

During the last MSX users’ meeting in Barcelona, Konamiman has announced a new project that he has been working on for a while: Nestor, a new Z80 cross-assembler. The main objective was to be able to build Nextor without having to use CP/M emulation to run MACRO-80, but since Nestor is a general-purpose Z80 assembler, if can be use for any project using the ZILOG microprocessor.

Here are some of the features you might find very attractive:

• Multiplatform. Runs on any machine/OS that supports the .NET 6 runtime; of course, this includes Windows, Linux and macOS.
• Almost fully compatible with Microsoft MACRO-80 for Z80 code (Nestor80 can’t assemble 8080 code). Most of the incompatibilities are for obscure or undocumented features.
• Can produce absolute and relocatable binary files. Relocatable files conform to the format used by Microsoft LINK-80.
• Supports Z80 undocumented instructions and R800 instructions.
• Over 50 program arguments for fine-grained customization of the assembling process and the listing file generation (but all are optional and have sensible defaults). Pass arguments in the command line, in a file, and/or in an environment variable.
• Detailed, comprehensive error reporting, unlike MACRO-80.
• Use unlimited length, arbitrary character encoding symbols in your code:
• Modern string handling: it’s possible to choose the encoding to be used when converting text strings (supplied as arguments to DEFB instructions) to sequences of bytes, and most of the C# string escape sequences are allowed in strings
• Nested INCLUDEd files (MACRO-80 allows only one level for INCLUDE) and of course, support for arbitrary paths for included files.
• Additionally, to being compatible with MACRO-80 it also borrows a few features from other assemblers, like Sjasm-style modules and relative labels
• Programmatic API. The Assembler.dll library file can be referenced and used from any .NET language in order to assemble code from an IDE or any kind of custom tool. Here’s a simple example in C#:

Source: MSX Resource Center
Link: Nestor80 on GH

It is that time of the year when we all get excited about BASIC, but only if it is restricted to 10 lines of code! And, for the third time, I am honoured to be part of the judging panel!

Once again, you can show off all your skill in writing compact BASIC code for the 2023 Basic 10Liner contest, which as of this article, is already on and waiting for your entries!

The rules a the same as last year, as follows:

Legal systems

All 8-bit computer systems

Authorized BASIC dialects

All line-orientated BASIC dialects are allowed with a restriction in the category “PUR-80”

​Since the jurors do not have the original hardware of all approved systems available, all systems must have an available emulator. The authors must provide a recommendation for an emulator and briefly describe how to start the game. Additionally, they must include a screenshot in jpg or png format or an animated screenshot in gif format.

Categories​

“PUR-80”: Program a game in 10 lines (max 80 characters per logical line, abbreviations are allowed). Attention: In this category, only factory-built-in BASIC variants are allowed

Category “PUR-120”: Program a game in 10 lines (max 120 characters per logical line, abbreviations are allowed)

Category “EXTREME-256”: Program a game in 10 lines (max 256 characters per logical line, abbreviations are allowed)

​Category “SCHAU”: Code a program in 10 lines (max 256 characters per logical line, abbreviations are allowed). The program can be a demo, a tool or an application program.

Deadline for submissions

Saturday, March 25, 2023, 6 p.m. CET

Award ceremony

Saturday, April 1, 2023 at NOMAM

For more details, head over to the official page!

Hidden easter egg image in Tandy Color Computer 3.

The most famous Tandy/Radio Shack Color Computer (“CoCo”) easter egg has to be the hidden photo of the CoCo 3 programmers that shows up if you hold down CTRL-ALT while turning the machine on. (Alternatively, you can hold down CTRL-ALT and hit the reset button on the back of the machine to also display it.) I had the pleasure of working with two of them during my days at Microware, the company that worked on the CoCo 3 BASIC enhancements for Radio Shack.

But, there’s another easter egg, which I’d bet they added first, since it followed in the footsteps of a pre-existing Microsoft easter egg that was in the original 1980 Color BASIC 1.0 ROM.

CLS 100 easter egg

The CLS command is used to clear the screen. On the 32-column text screen, specifying a number from 0-8 will fill the screen with color blocks. That functionality was extended on the CoCo 3’s 40 and 80 column text screens, except on the new hardware it could clear the screen to a true background color.

For the original CoCos, Microsoft included an easter egg in the CLS command. If you used a number greater than 8, instead of filling the screen with colored blocks it would display the word “MICROSOFT”.

When Microware (not Microsoft) did the BASIC enhancements for the CoCo 3, they included a similar easter egg for the 40 and 80 column screens. If you did a CLS number outside of the range of 0-8, it would display “Microware Systems Corp.”

CoCo 3 CLS 40/80 column screen easter egg.

BUT, they added one special easter egg that you can only see once, then it disables itself (until the next power cycle or cold start). By typing CLS 100 you get to see the names of two of the programmers that worked on the project:

CoCo 3 CLS 100 40/80 column screen easter egg.

From that point on, if you type CLS 100 again you will only see the “Microware Systems Corp.” message.

In addition to making this easter egg a “one shot”, the programmers also took steps to hide their names so they would not be easily found by looking at the ROM code.

From Super Extended BASIC Unravelled, this note can be found in the memory map:

“Super Extended BASIC Unravelled” note about CLS 100 easter egg.

On startup, the ROMs are copied in to RAM, and these zero bytes from the ROM will be in RAM at that range.

“Super Extended BASIC Unravelled” CLS 100 uninitialized table.

Then, during the CoCo 3 initialization code, there is a routine that copies the author names to that location. The data it copies is not the authors’ names directly — it’s an encoded version of the authors’ names:

“Super Extended BASIC Unravelled” CLS 100 encoded table.

Each of those bytes has its bits flipped. If the value in binary was 11110000, it would be encoded as 00001111. That effectively hides what those bytes represent from anyone just PEEKing around memory looking for text. A routine in the ROM will start copying those bytes in to the destination location, inverting the bits as it does so. It looks like this:

“Super Extended BASIC Unravelled” CLS 100 decode routine.

Here is the CLS code, which has special check for the value of 100 that will branch to a different routine:

“Super Extended BASIC Unravelled” CLS 100 dispatch routine.

The routine that is called when 100 is specified will display the easter egg and then wipe out the above BEQ (Branch If Equal) instruction that calls it by replacing it with the NOP (No Operation) instructions. Below is the code that displays the egg and then disables it:

“Super Extended BASIC Unravelled” CLS 100 display routine (and kill function).

LF730 gets a pointer to the decoded author name message and displays it, then it stores NOP byte at F6F4 and the memory location after it. That changes the two bytes the started out as “BEQ LF730” to “NOP NOP” effectively making the “CMP #100” useless since there is no longer an operation after it to make use of the results of that compare.

After those two bytes are changed to NOP, there is a loop that starts at the memory location where AUTHORMS is located (F71B) and starts putting NOP bytes there until it gets to F74D. That destroys the evidence by wiping out everything in this table…

“Super Extended BASIC Unravelled” CLS 100 uninitialized table.

…and everything after it (the code) up to the LF74D label:

“Super Extended BASIC Unravelled” CLS 100 display routine (and kill function).

Thus, after CLS 100, the code that would have jumped to the routine is gone, the routine it would have jumped to is gone, and the data that the now gone routine would have displayed is also gone.

Nice.

Here is a short BASIC program that will dump the hex values of the name bytes on up through the code that displays them, then prints the name bytes out as text.

0 ' COCO3NAMES.BAS
10 WIDTH 40
20 FOR L=&HF71B TO &HF74C
30 PRINT HEX$(PEEK(L));" ";
40 NEXT
50 PRINT
60 FOR L=&HF71B TO &HF72F
70 PRINT CHR$(PEEK(L));
80 NEXT

If you boot a CoCo 3 and run this program, you will see it contains the bytes for the name text and the 6809 code:

Contents of CLS 100 easter egg memory before it has been shown.

Then if you type CLS 100 and run the program again you will see that those bytes are now all the NOP byte (&H12). Since this is not a printable character, nothing is printed after the hex values:

Contents of CLS 100 easter egg memory after it has been shown.

And that is more than you probably ever wanted to know about how the CLS 100 CoCo 3 Easter Egg works.

So let’s do a bit more…

Restoring (and customizing) the egg

Just for fun, I wrote this short BASIC program that does three things:

1. Restore the easter egg text to the memory from &HF71B-&HF72F.
2. Restore the display routine at &HF730 that prints the easter egg text and deletes the easter egg text and the routine.
3. Restore the “branch if equal” that is supposed to happen after comparing the value of CLS to be 100.

And, as an added bonus, there is a line that will insert a “return from subroutine” RTS instruction in the display routine so it will not run the code that wipes out the easter egg text and display routine.

If you have already done a CLS 100, this code would restore the easter egg and let you run it again:

10 ' COCO3EGG.BAS
20 WIDTH 40
30 ' RESTORE EGG TEXT
40 EG$="T.Harris & T.Earles"
50 ' ROOM FOR UP TO 19 CHARS
60 LN=LEN(EG$)
70 IF LN>19 THEN LN=19
80 ' STORE THE EGG TEXT
90 FOR I=0 TO LN-1
100 POKE &HF71B+I,ASC(MID$(EG$,I+1))
110 NEXT
120 ' ADD CR and 0 BYTES
130 POKE &HF71B+I,13
140 POKE &HF71B+I+1,0
150 ' RESTORE DISPLAY ROUTINE
160 FOR L=&HF730 TO &HF756
170 READ V$:POKE L,VAL("&H"+V$)
180 NEXT
190 ' RESTORE CMP #100 "BEQ"
200 POKE &HF6F4,&H27:POKE &HF6F5,&H3A
210 ' DISABLE EGG KILL (RTS)
220 'POKE &HF73D,57
230 END
240 ' DISPLAY ROUTINE DATA
250 DATA 8D,40
260 DATA 17,FF,57
270 DATA 8D,41
280 DATA 8E,F7,1A
290 DATA BD,B9,9C
300 DATA 34,10
310 DATA 30,8D,FF,B1
320 DATA 86,12
330 DATA A7,80
340 DATA A7,84
350 DATA 30,8D,FF,CE
360 DATA A7,80
370 DATA 8C,F7,4D
380 DATA 25,F9
390 DATA 35,10
400 DATA 39

The DATA statements are organized like that to match the bytes shown in the Unravelled book’s listing of this routine. This helped me find and fix typos.

Line 220 is commented out, but if you uncomment it, it will place an RTS after the “JSR STRINOUT” in the LF730 display routine, causing it to return rather than do all the code that replaces stuff with the NOP bytes. The CLS 100 easter egg can then be seen over and over again without a reboot.

And, as an added bonus on top of the other added bonus, you can change the easter egg string in line 40 to be anything you want, provided it is 19 characters or less. (Anything longer will just be cropped to the first 19 characters.) I changed mine to read “Sub-Etha Software” and had that message as my CLS 100 easter egg.

Until next time…

Not long ago, I posted about the development of Angry Birds for the Apple II, including the gameplay video showing it in all its glory!

One of the things that most impressed me when I saw Angry Birds was how low-resolution graphics could look so good on a game. It is not the only example of excellent low-res games out there, but it is undoubtedly one of the latest.

Angry Birds was built using DOLORES, a library that makes it easier to access and manipulate the double-LORES mode with 80 x 48 pixels in 16 colours available on the Apple IIe enhanced.

This graphics mode doesn’t have a lot of documentation available and even lacks more modern articles and websites talking about it. This gap is what DOLORES aims to fill out! Keep in mind that DOLORES offers & functions to be accessed via AppleSoft Basic, so no machine language is really required to get started.

If you are interested in creating games like the Apple II’s Angry Birds or even lovely demos using this superb and colourful resolution, a good start is to visit the 8 Bit Shack website. There is an article there that covers the basics of the library so you can get started.

Link: 8bitshack.org

With my busy life, this is not exactly hot news, and you all might have seen it elsewhere, but I thought it would be nice to write something about it anyways.

The Apple Lisa was released 40 years ago, and although it is considered a commercial failure, it paved the way for how you interact with the computer you are using to read this. The GUI that it showed is not Apple’s invention, as we all know. Still, it is undeniable that they are responsible for bringing it to the mass microcomputer market, first on the Lisa (not exactly affordable at the time), then to the Macintosh. Many followed the trend and created GUI for computers from the 80s, including Microsoft Windows, GeOS and many more.

To celebrate the 40th anniversary of its release, Apple and the Computer History Museum released the complete source code of Lisa’s operating systems and applications. The package contains Lisa Office System 3.1, launched in April 1984 and comprises about 26MB and over 1,300 commented source files, divided nicely into subfolders that denote code for the main Lisa OS, various included apps, and the Lisa Toolkit development system.

You can access the source code by following the link at the end of this article.

Even Apple is doing why not us?

Apple is well-known for keeping tight control of its ecosystem, locking its users to their hardware and software as much as possible. Still, even with that philosophy, they saw that releasing old source code is important to preserve computer history. You can argue that, for them, Lisa’s OS is worthless these days, which is probably true. However, it is not common for large corporations to open their secrets to the public, so whether you like Apple or not, it is commendable that this was possible.

That made me think about our contemporary retro computing and retro gaming community. I am certain that we are in the golden era of the retro, where the once old and worthless are now vintage and very valuable (vintage is the new old, right?).

With this boom, the interest in new products, either hardware or software, has risen tenfold, and the community is responding to this demand. Every year you see new hardware accessories or fully-fledged computers being released and sold for reasonable prices. Software is even more prevalent, with literally hundreds of new games being released for free or for a price, games that are better than anything released back in the day!

So, from that perspective, we are living in a paradise, where we can re-play all the games and use all the applications from when the computers were new, but also we can use and enjoy many new products that are helping to keep our old computers alive!

However, there is a dark spot in this otherwise sunny paradise. Many of these products are kept closed by their creators, and future generations will not be able to see and understand how they were made after we all go back to dust.

Yes, we all are going to die, some sooner than others. We all hate to think about that, but it is true. Hopefully, we all be still around for many decades, but we know what is coming. Every year, we read the sad news about computer pioneers passing away, some going way too soon, I agree, but some left us just because their time here has expired.

It is time to make arrangements!

I understand a lot of the great projects out there, hardware or software, are responsible for an essential part of their creators’ income, and releasing their sources (code, project plans, PCB layouts, etc.) could jeopardize their business. This is fair, and I don’t think there is anything wrong with keeping your creations under wraps if you think that is the best way to protect your interests.

However, it would be vital for computer history if you could, for example, start releasing some of your old and not-as-popular projects to the public. Also, think about making arrangements in case something happens. And I am not only talking about death. Throughout my 10+ years looking into the retro computer and gaming community, there were so many projects that I saw getting lost forever just because their creators lost interest and went to do something else.

That is another point. Are you tired of doing whatever you are doing? Please, make sure you give the projects to the community before you turn off the lights of your retro cave.

There are many ways to do so. You could transfer the projects to a friend you trust, or a group of friends you know wouldn’t “steal” it and start selling it themselves. Also, opening the source won’t necessarily break the bank. Fujinet is an excellent example of an open-source project where people can still produce and sell hardware for profit.

Software projects might be easier, where you can send them to Gihub or Gitlab with instructions on how to rebuild them. Is your code a mess that only you understand? Welcome to the club! Don’t be ashamed of showing how you did. At that point, everybody knows what you did and how good is the final product. If there are some ugly coding skills behind it, who cares – the important is that you made it!

Don’t let the fantastic contributions you made to the retro computer community die with you. Give them away to the rest of us!

Link: Lisa Source Code

Although I started out my home computer life with a Commodore VIC-20, I ended up moving to a 64K Radio Shack TRS-80 Color Computer (“CoCo”) mostly because of its Microsoft Extended BASIC. Having built-in commands like PLAY, DRAW, PAINT, LINE and CIRCLE let me do graphics that anyone with an Extended BASIC CoCo could run. On my VIC-20, I had the Super Expander cartridge which added some extra memory and new commands to the VIC, but programs you wrote using it were useless to anyone who did not also own that cartridge.

Side Note: The CoCo started out as a 4K machine in 1980 with Microsoft Color BASIC. This 8K ROM had no graphics commands at all – but it could plot color text blocks on the screen. A later 8K ROM containing Extended BASIC added “high resolution” 256×192 graphics, and then when a disk controller cartridge was plugged in, it brought along a third 8K ROM with Disk BASIC.

@

Last year, I was experimenting with Extended Color BASIC and the “GET” and “PUT” commands. I knew that the documentation was incorrect about them in regards to how much memory they required and I was trying to figure out how they worked.

During my research, I discovered something I was unaware of. I was looking at the Extended Color BASIC Unravelled disassembly book to try to find clarification on why something I was seeing was happening. Reading through it revealed a syntax I was unaware of for the following commands:

• CIRCLE
• GET
• LINE
• PAINT
• PUT

Much like the CoCo BASIC “PRINT@” command, the ‘@’ sign is allowed on these commands as well. It does nothing, and is merely skipped:

CoCo’s Undocumented “@” Sign Syntax

A note in the Unraveled book says:

It is interesting to note that the “@” symbol does not do anything! It is there to make the command syntax consistent with the “PRINT @” concept and to make it compatible with other versions of Microsoft BASIC.

– Extended Color BASIC Unraveled II

Since this was not documented in the manual (as far as I know), I had never been aware of this syntax.

Drive numbers

When all you had was a cassette recorder, loading and saving was simple:

CLOAD "PROGRAM"
CSAVE "PROGRAM"

When all you had was a single disk drive, loading and saving was simple:

LOAD "PROGRAM.BAS"
SAVE "PROGRAM.BAS"

When you had more than one disk drive, loading and saving was still simple… Just add a colon and the drive number after the filename:

LOAD "PROGRAM.BAS:0"
LOAD "PROGRAM.BAS:1"
COPY "PROGRAM.BAS:0" TO "PROGRAM.BAS:1"

And we liked it that way…

Over in the CoCo Discord chat, I learned from William “Lost Wizard” Astle that the drive number can also be put at the start of the filename:

SAVE "1:PROGRAM.BAS"
LOAD "1:PROGRAM.BAS"

CoCo Disk BASIC drive numbers BEFORE the filename?

He did point out that various alternate/enhanced DOSes (such as RGB-DOS, which added hard disk support) did not support this syntax. Which is fine by me, because it’s just weird.

I should also not that in the manual, examples used the slash (“/”) instead of the dot for separating the extension, such as “PROGRAM/BAS”. While this syntax was used even with the later 1987 revision of the CoCo 3 manual, it at least did mention that both slash “/” and dot “.” could be used to separate filename from extension. And although this one line reference existed in the 1981 manual as well, I expect many of us may have missed it and used the slash back then. I sure did.

Parameters where there are none

If you had the original manual revision, you may have been taught things slightly different from later editions. For instance, clearing the screen. The CLS command can be followed by a number to fill the screen with a color.

But the early edition manual demonstrated this using parenthesis, which I’ve never seen done:

CLS(3)

It works. Try it

There certainly are basic commands that require parenthesis — such as CHR$(), ASC(), VAL(), INT(), etc. — but CLS was certainly not in that list.

So why does it work? After a moment of thinking about this, I realized it’s just normal math grouping for numbers, like this:

PRINT 3*(5-1)

The parenthesis make sense there, but they sure look odd if you add them for no reason, such as this:

PRINT (42)

It works. Try it

And whoever wrote the manual was using them for CLS too. But why?

No device is a device?

Another thing that surprised me was learning that the original Color BASIC manual did not cover all of the commands available. For example, it did not mention printer listing with LLIST and PRINT#-2, or opening and reading/writing to/from cassettes. Later revisions to the manual added these, and maybe other, missing commands.

Folks using a printer learned that, while PRINT by itself goes to the screen, doing PRINT#-2 makes the output go to the printer.

#-2 is a device number for the printer.

When accessing a cassette file, device #-1 is used:

OPEN "O",#-1,"TAPEFILE"
PRINT #-1,"THIS GOES TO THE CASSETTE FILE"
CLOSE #-1

Disk Extended Color BASIC added disk device numbers, and allowed opening up to fifteen files at a time using devices #1 to #15 (though by default only two were available unless you used the FILES command to reserve memory for more):

OPEN "O",#1,"DISKFILE.TXT"
PRINT #1,"THIS GOES TO A DISK FILE"
CLOSE #1

Unknown to many is device #0, which is the text screen. The use of it is optional, since PRINT by itself assumed screen.

PRINT "THIS GOES TO THE SCREEN"
PRINT #0,"SO DOES THIS"

It works. Try it

But, it was useful when creating a program that allowed the user to select output to screen or printer.

10 INPUT "OUTPUT TO S)CREEN OR P)RINTER";A$
20 IF A$="S" THEN DV=0
30 IF A$="P" THEN DV=-2
40 PRINT #DV,"THIS GOES TO SCREEN OR PRINTER"

I recall writing programs that would also allow outputting to a tape or disk file, so if one of those options was chosen, I would make sure to create the output file:

10 INPUT "OUTPUT TO S)CREEN, P)RINTER, T)APE OR D)ISK";A$
20 IF A$="S" THEN DV=0
30 IF A$="P" THEN DV=-2
40 IF A$="T" THEN DV=-1:OPEN "O",#-1,"TAPEFILE"
50 IF A$="D" THEN DV=1:OPEN "O",#1,"DISKFILE.TXT"
60 PRINT #DV,"THIS GOES TO... SOMEWHERE!"
70 IF DV=-1 THEN CLOSE #-1
80 IF DV=1 THEN CLOSE #1

Yuck. But you get the idea.

On a whim, I wondered what happened if you tried to CLOSE #0 (nothing). Or CLOSE #-2 (nothing). Then I wondered what happened if you tried to open those devices:

10 OPEN "O",#0,"SCREEN"
20 PRINT #0,"HELLO, SCREEN"
30 CLOSE #0

It appears BASIC just ignores OPEN/CLOSE to the screen device, or for the printer device:

10 OPEN "O",#-2,"PRINTER"
20 PRINT #-2,"HELLO, PRINTER"
30 CLOSE #-2

This means my multi-output program could have been made much, much simpler by not needing special cases to do the OPEN/CLOSE:

10 INPUT "OUTPUT TO S)CREEN, P)RINTER, T)APE OR D)ISK";A$
20 IF A$="S" THEN DV=0
30 IF A$="P" THEN DV=-2
40 IF A$="T" THEN DV=-1
50 IF A$="D" THEN DV=1
60 OPEN "O",#DV,"OUTFILE"
60 PRINT #DV,"THIS GOES TO... SOMEWHERE!"
70 CLOSE #DV

The only extra thing one might want to do is name the file different if going to disk since disk filenames allowed for a three character extension. While you can try to add an extension to a tape file…

OPEN "O",#-1,"TAPE.TXT"

…it’s not really an extension. The filename can be up to 8 characters, and the dot is treated as part of those eight characters. In this example, the file name would be “TAPE.TXT”. But if you had done “OUTPUT.TXT”, the tape name would be “OUTPUT.T” (8 characters). Not pretty, but it works.

Maybe we take care of that with:

10 INPUT "OUTPUT TO S)CREEN, P)RINTER, T)APE OR D)ISK";A$
20 IF A$="S" THEN DV=0
30 IF A$="P" THEN DV=-2
40 IF A$="T" THEN DV=-1
50 IF A$="D" THEN DV=1:EX$=".TXT"
60 OPEN "O",#DV,"OUTFILE"+EX$
60 PRINT #DV,"THIS GOES TO... SOMEWHERE!"
70 CLOSE #DV

That would add an extension (“.TXT”) only for disk files.

Anyway, I thought it was interesting that BASIC allowed OPEN/CLOSE on printer and screen devices, and I expect if I looked at the ROM disassembly, I’d find extra code there that just returns (not doing anything) when those device numbers are used.

Oh, and there is also a device #-3 in Extended Color BASIC, but you can’t do anything with it. That device number seems to be associated with the DLOAD command (which was removed on the CoCo 3) and is just used internally. But that’s the subject of a potential future article…

To be continued…

There are certainly other undocumented things — such as the hidden MICROSOFT “encrypted” easter egg, and the “bug” in the PLAY command which allows it to play notes that do not exist on a piano keyboard. If you know of other items like this, please leave a comment.

Until next time…

There is a recording of Remute’s concert in the Digital Retro Park in Offenbach Germany that took place on the 14th of January 2023:

A message from David Pleasance for all orders who ordered his german book of “Commodore the inside story”:

RetroRGB is THE portal to learn all about how to get the picture the best way out of such retro consoles to your modern TVs! Robert Neal is the master behind behind this portal which is the go-to address for console info of all kind as well, thanks to its extensive Wiki which is a whole database, YouTube videos, podcast and so much more! Time to speak to the man! Interview starts at 21:41

Listen to/watch at: https://scene.world/retrorgb

After having announced the judging panel (here), Planeta Sinclair posted the list of all games that will run for “best of” in different categories, including the most important: GOTY.

To elect the nominees, first, the judges had to go through a list of 130 names and vote for five favourites (10 for GOTY). The result of this list is what comprises the nominees for this year. The results will be announced during a special show that will happen on January 29th, live and online.

Here is the list in alphabetical order:

Graphics

• Donum
• Loxley
• Ringo
• Rubinho Cucaracha
• Tiny Dungeons

Loading screen

• Chez Maxime
• Drift! 2K22
• Mecki: Winter Hibernation
• Mr. Hair and the Kitty Katakombs
• Rubinho Cucaracha

Sound

• Beethoven’s Revenge
• Bufonada
• Castle Escape
• Donum
• Ringo

Puzzle

• Crímenes Ilustrados
• The Cubic Experience
• Tenebra
• Tiny Crate
• Yokai Monk

Adventure and RPG

• Bufonada
• Don Quixote 16K
• Hakkenkast
• Loxley
• Tiny Dungeons

Platform

• Castle Escape
• Mr. Hair and the Kitty Katakombs
• Ringo
• TCQ
• The Vectornauts

Action

• Botanic
• Chez Maxime
• Dig Dug Doug
• Ms. Nampac
• Rubinho Cucaracha

Text Adventure

• Colour Beyond Time
• Donum
• Habitación 310: El Despertar
• Italianate
• The Mystery of Markham Manor

BASIC

• Amidar
• Casio Handheld Games Emulator
• Donkey Kong 3
• Loxley
• Micro Profanation

Portuguese-Brazilian

• Blue Diamond
• Lost Comic Book
• Maze Walls
• TCQ
• The Towering Inferno

Spanish 

• Bufonada
• Colonos III
• Donum
• Federation: Underwater
• Yokai Monk

GOTY

• Bufonada
• Castle Escape
• Don Quixote 16K
• Donum
• Hakkenkast
• Loxley
• Ringo
• Rubinho Cucaracha
• TCQ
• Tiny Dungeons

Link: Planeta Sinclair

Logiker’s Vintage Computing Christmas Challenge 2022 had more than 200 entries, which is a staggering number, and we can say the challenge was a success!

Logiker has now posted a YouTube video/slide show displaying not only the results (which should be the same on all of them, of course!), but also the code that generated it.

There are some very interesting ones, including a program for the TI-59 calculator with the printout and an obscure Kenbak-1 (this article’s top photo). Modern languages are also present, like Javascript and Python.

Even if you fast-forward, ensure you don’t miss Logiker’s comments throughout the video. There are some clever solutions, and even a Space Invaders redemption with the star! The challenge is really just a fun idea to make us think outside the box, and I think it worked!

It looks like the emulator developers have been working hard these past few weeks. YAPE 1.2.2 was released today, bringing important changes.

These are the most important new features and bug fixes that made it to this release:

• SID card mouse emulation (in DirectInput mode)
• Manufacturer-dependent RAM powerup patterns
• copy the emulator window to the clipboard as a bitmap
• the 32-bit build now has an opcode trace window
• quotation mark printing bug (MPS-803)
• drive VIA emulation accuracy improvements

YAPE is the most reliable emulator for the Plus/4 (sorry Vice!), and it’s been developed for 10+ years it is available in Windows as well as multiplatform editions, although the latter lags several versions behind the former.

Link: YAPE

Following the usual end-beginning-of-the-year articles or videos showing the best of 2022, The Game Beaters YouTube channel has published a very informative video about the best NES Homebrew games of 2022.

The video is a curated list of the best 10 NES games out of almost 100 games, demos and proof of concept releases for the Nintendo Entertainment System released only in 2022! Except for the first place, the list has no particular order and, of course, follows the author’s personal taste.

The video does well, giving the reasons a game made it to the list, and looking at each one of them, we can see the NES scene has been very active indeed, and in its case, quantity and quality go hand to hand throughout the last year.

There are also some honourable mentions, like Get It Together, which caught my attention. It is a puzzle-platform game, but the way you can solve the puzzles is very unique. You play a scientist who developed an immortality syrup, but during an attack, a bomb is thrown into the lab, and the syrup gets spread all over the scientist’s body, which is blown into pieces.  Your job in this game is to manipulate the pieces of your body to flip the switch and leave each area. Each body part has a different means of moving, and you can put them together in any order. For example, your head rolls, your legs can jump, and even your butt can fart and fly around.

Alwa’s Awakening

The best game, according to the author, is Alwa’s Awakening, a Metroidvania-style game with 400 unique rooms to go through, solving puzzles and moving forward through the game. The graphics and soundtrack are amazing, and I agree that this game is among the best NES games I’ve seen! Although the game is not original and has been available on many platforms in the past 5 years (including on Steam), the NES version was developed from the ground up and completely developed in 2022.

The other games featured in the video are:

• Bass Def Adventures
• Angana, Scoude of the Goblin King
• Dungeons and Doomknights
• Yeah Yeah Beebiss 2
• The Arm Wrestling Classic
• The Adventures of Panzer 2
• Orebody: Binders Tale
• Full Quiet
• Garbage Pail Kids

Most of the games listed here are not free or at least will have a physical edition as well. You can follow the links for more details.