Juan Castro strikes again, this time providing a short program for me to try on a CoCo 3 (I used the Xroar Online emulator) that shows another quirk in the handling of 16-bit values on the CoCo.
The reason this requires a CoCo 3 is because it makes use of the ONERR GOTO command that was added for Super Extended Color BASIC.
I recall using these back in my CoCo 3 days. On page 227 of the Color Computer Computer 3 manual is this description:
ON ERR GOTO line number
“Goes to the line number if an error occurs during program execution.”
There are two special variables that get set when an error is trapped by “ON ERR”.
ERNO
“Returns an error number that corresponds to the error that occurred.”
ERLIN
“Returns the line number where the error occurred.”
So in this simple program, with a mis-spelled “PRINT” command…
10 ON ERR GOTO 50000
20 PRUNT "I TYPE POORLY"
30 END
50000 PRINT "ERROR";ERNO;"IN LINE";ERLIN
When I run that, I see:
ERROR 1 IN LINE 20
1 must be the value of ?SN ERROR. The manual says to look for “BASIC Error Messages” in the back of this book, but the page is titled ERROR CODES. It is on page 321. It lists errors 1 to 39.
But that is not important for this post.
ERLIN, which you see reported the error was in line 20, has a problem.
If the line number with the error has the high bit set (higher than 32767), it gets reported as a negative number! Changing the program to make the PRUNT typo happen on a later line shows this:
10 ON ERR GOTO 50000
32768 PRUNT "I TYPE POORLY"
32769 END
50000 PRINT "ERROR";ERNO;"IN LINE";ERLIN
If I run this version, I see:
ERROR 1 IN LINE-32768
If the error line is moved to 32767, you will it it report properly.
The book Super Extended BASIC Unraveled II mentions this bug on page 33:
“The ERLIN function will return a negative number if the line number in which the error occurred is greater than 32767. This is caused by the fact that the ERLIN function returns the line number as a two-byte integer instead of a floating point number, as it should.”
– Super Extended BASIC Unraveled II, page 33
I did not know there was a 2-byte integer routine in the ROMs. Always learning something new! (Or, re-learning in case I actually did learn this decades ago.)
Thanks, Juan, for getting my dusty brain thinking.
Until next time…
This is likely related to that Microsoft Basic for the 6502 returns negative numbers for FRE() if there is more than 32767 bytes free. Perhaps the most known cases is on a C64 with nothing loaded where the 38911 basic bytes free is reported as a negative number.
Related as in that it uses 16-bit integer code.
My VIC-20 never had that much RAM so I never saw such a value. I should look up the lineage of the CoCo version and see where it came from. I’d like to find some emulators with the father/grandfather of Color BASIC and experiment on them.
The VIC 20 can only have contiguous ram below address 32768 (where the char rom is mapped), so it can’t trigger this. Similarly PETs have the screen ram at 32768, and with the first 1k reserved for various internal usages the max basic RAM is 31k.
There is the “LOS 96” thing that uses the full 96 of a PET 8096 or 8296, but afaik it uses 32k for the ram loaded BASIC and whatnot, 32k for variables and 32k for program code, so each part is also max 32k.
I think this was fixed for the Plus/4 and also the C128 which both have more than 32k free.
Man, adding 32K to the VIC back then must have been expensive. I had the Super Expander cartridge, but didn’t understand as a kid why it moved all my POKEs around.
All of these systems represent the numbers as floats, don’t they? I wonder why the signed representation is used.
It must had been expensive in 1980, but in 1983-1984 it wasn’t that expensive any more.
The reason for addresses moving around is due to a combination of the choice of having 5k rather than 8k on a stock VIC 20, minimizing chip count and having a split bus where the ram, VIC chip and the character ROM have bus accesses on each flank of the 1MHz clock, while the CPU, the other ROMs and any expansion memory “only” having accesses on one flank of the clock, like most 6502 and 6800 systems. The result is that the screen has to be within built in memory, and being able to add either +3k or +8k (or more) resulted in the built in memory being split in a 1k block at the start of address space, and a 4k block from address 4k to 8k. That way you can either add 3k in the 1k-4k gap, or add more memory starting at address 8k. Unfortunately due to the screen having to be internal memory and that Basic can’t (easily) use non-contiguous memory a 3k expansion can’t be used from basic when also having any expansion starting at address 8k.
I have no idea why, but for some reason the character ROM starts at address $8000 (32k) and all I/O are located at $9000, while an additional free 8k block sits at $A000-$BFFF, commonly used for auto starting cartridges (the first 4k is used by the ROM in the Super Expander cart), but it’s fully possible to have RAM in this space. The only real use cases for RAM here is to be able to run copies of cartridges, run some modern games and demos using all possible memory, and also I think that some 40/80 col video cartridges used part of this space for their screen memory.
I almost have a feeling that they actively wanted to prevent it being “too easy” to run PET software on the VIC 20. If the address space $8000-$9FFF and $A000-$BFFF had been swapped, it would had been easy to make those 40/80 col third party carts use $8000 for their screen memory and thus have that at a PET compatible location. Not sure to what extent PET software used other I/O directly but I would think that productivity software probably wrote to the screen directly but used the Kernal API for everything else (especially since the keyboard layout differed between different models, there were the “Graphic” and the “Business” keyboard layouts and also all regional versions). Technically it would be really simple to modify the hardware in a VIC 20 to allow this, just swap two outputs of a 74xx138 3-to-8 decoder chip, but would then of course need a modified Kernal ROM as all I/O would move.
Going off on a tangent, I find it surprising that no-one made a better PET emulator for the C64. There seems to have been some sort of official product that basically just moves the screen to $8000 instead of $400 (1k) and moves start of basic from $800 (2k) to $400, and obviously sets end of basic to $7FFF, but otherwise I think it just switches to black background/border and white text. Especially since Commodore owned the right to their own ROMs, it would had been possible to load copies of modified PET ROMs into RAM (and swap out the stock C64 ROMs). The only remaining differences would be where I/O ports reside and also that address 0 and 1 are used for I/O on a C64 which would interfere with the BASIC function USR that on a PET (and VIC 20) uses address 0, 1 and 2 to contain a JMP instruction and it’s two byte address.
Your VIC-20 memory layout description helps. But when you say “internal” memory, do you mean something about how the VIC chip worked was hard-coded to work with a specific area of memory? Or was that memory coming from the VIC chip itself?
I did not realize the C64 internals had such a close match to the PETs, though I clearly recognized the VIC/PET BASIC being very similar.
1980 is an interesting date for the VIC. I thought Commodore was a US company, but wiki shows a 1980 Japan, then 1981 for the rest of us. And this bothers me. When I got my VIC, William Shatner ads were on TV about “the first fully featured color computer for under $300” or something. My dad got mine for that $299.99 or whatever price. It must have been very new to release here. But I am pretty sure I got mine in 1983, or 82 at the earliest. I have comments saying 83, so I know I had it by then. Surely it didn’t stay at $300 for two years before dropping.
I skipped the C64 because it was $600 or something when I got my $300 CoCo 1. But that price was not real. Radio Shack salesman used his discount to get it for me and upgraded it to 64K for me, for $300. Not sure what retail on that would have been. If I could have gotten a $300 C64, I am sure my computing path would have been quite different.
I’d have known how to use SID and sprites ;-)
Internal as in “built in to the computer” rather than “as an expansion cartridge”.
The VIC chip in the VIC 20, like the VIC-II in the C64 (and VIC-IIe in the C128) can technically address 16k, of which 16 bytes are reserved for it’s internal registers. However on the VIC 20 only the RAM built in to the computer and the character ROM are connected to the VIC chip. There is a well known mod (at least well known nowadays as a vintage computing thing) to expand the internal memory to 8k in a way that makes all 8k addressable by the VIC chip, but technically it would be possible to have 12k (minus 16 bytes) addressable by the VIC chip while still being compatible with all software.
All Commodores 8-bit 6502 computers used a rather similar BASIC and Kernal, although there were differences. IIRC there are three different “main” versions for the PET range. The Kernal and Basic in the VIC 20 and the C64 are very similar (the source code for the C64 Kernal has provisions to select between 6526 CIA and 6522 VIA I/O chips. I’m not 100% sure but I would think that selecting 6522 chips builds a VIC 20 Kernal, or at least something similar).
But also thanks to Microsoft creating the 6502 basic some similarities exists between the Commodores and the other computers that also used Microsoft 6502 basic.
It’s unfortunate that Microsoft didn’t enforce their customers to keep the low memory usage identical for all Microsoft 6502 basic implementations. The result is that the addresses that point to start/end of memory, end of program / start of variables, start of strings and whatnot, are at the same place on a VIC 20 as on a C64 but at different addresses on an Apple II (running “Applesoft” which is Apples name for their version of Microsoft 6502 Basic).
Btw fun fact: Commodore bought their license for the 6502 basic for a one time fee. I’ve read that Jack Tramiel, the boss of Commodore, said to Bill Gates “I already have a wife” when Bill wanted a per-unit license fee.
I’m not sure if this deal carried on through all the years as Commodore would become a customer of Microsoft again when they started selling PCs and also they included a Microsoft basic for the Amiga with Kickstart/Workbench 1.2 and 1.3. (The really early 1.0/1.1 used a Basic from IIRC Metacomco, the company who also made the DOS part of AmigaOS, while starting with 2.0 Basic was scrapped and replaced with Arexx).
Re Japan: Afaik Commodore realized that Japan would start competing in the home computer market, so the idea was to do most of the VIC 20 development in Japan. I don’t really get how that would had helped stop competition from other companies in Japan, but this is the story that’s been told.
I don’t think I’ve ever seen this confirmed, but I would guess that the initial name VIC 1001, used in Japan, might had been due to the PET being called PET 2001. The 1001 is obviously the reason for why all accessories ended up having 1xxx model names, and that numbering scheme continued being used for all Commodore 8-bit home computer accessories. 11xx=RAM expansions, 19xx = ROM carts, 15xx = “major” hardware like printers, disk drives, cassette decks and whatnot. Although IIRC there were also a 1902 monitor intended for the C128, and I can’t remember what numbers the C64 carts had.
And yes, the C64 was really expensive when new, but the price dropped fast.
From what I recall the VIC 20 over here in Sweden cost about the same as a 16k ZX Spectrum, both before and after the price was reduced at I would guess the autumn of 1983. I also remember that the Atari 600XL was in between the price of a VIC 20 and a C64, and that made it decently competitive. However the Atari 800XL cost more than a C64. Also the cassette deck for the Ataris were super expensive, even when compared with the fairly expensive one for the Commodores. IIRC in mid 1983 a Commodore Datasette cost about 600 SEK, the Atari 1010 casssette deck about 1000 SEK, while a cheap off-brand cassette recorder cost about 200 SEK while the more expensive on-brand IIRC cost up to 400-500 SEK (that would be for example one of those slightly odd Grundig CR480/485 that would both act as a portable mono cassette recorder and also as a stereo cassette deck. I.E. it was stereo when using line levels in/out, but the built in mic and speaker was mono. Reasonable but I think they made a mistake in not providing stereo headphone output). Not sure what the exchange rate was but divide SEK by 10 and you get approximately some sort of dollar in some country :)
Btw re SID and sprites:
On one hand I get why Commodore got shit from media at the time for not having any basic commands for anything more advanced than changing text foreground colors. But om the other hand I think that the fact that having to POKE everything made it easier to switch to assembler. And also it probably saved cost on ROMs, and it didn’t matter for all who only ran programs that they hadn’t made themselves.
An amazing thing is that AFAIK the C64 product line was still slightly profitable at the bitter end at Commodores bankruptcy after Q1 1994. Looking back at things, it would had been great if the 8-bit / C64, the Amiga range and the PC range had been three separate compartments, protected from dragging each other down. If that had been the case I think that the C64 might had survived even longer, and could had had a second life similar to the legally questionable NES clones (“Famiclone”) that existed in parts of the world in the 1990’s.
Oh, going off on yet a tangent:
In the early 00’s the “C64DTV” was developed and sold. An implementation of an improved C64 in a single chip, with an added disk drive emulator of sorts. Something that I think seems overlooked is that the joystick shape/form they used was what was called the Competition Pro in the 1980’s, and that is also the shape used for the joysticks included with “The C64 mini”, “The C64” (and the almost identical “The VIC20”) and afaik also “The A500”. I assume that those who made the C64DTV got a license for that joystick (possibly even remaining tooling?) and later on sold a sub-license to those making all those “The…” things. If that license hadn’t existed I would assume that the shape of the joysticks for those “The…” things would had looked different.
Great stuff here. I did not know there had been an MS BASIC for Amiga. Also, the C64DTV — was that the thing the female designer created wayback? I recall hearing about that, and how it was hackable to be a computer.
The addresses in BASIC moving around is interesting. I note that the VIC was similar, but completely different addresses, and handles strings VERY differently than Color BASIC. Color BASIC reserves string space, so it has the stack, variable table, and string space. But the VIC “just works” and I do not know how that works over there.
I took a step down (less colors, no dedicated sound, no programmable characters) to go to a 1980-era CoCo because of seeing Extended BASIC with “DRAW” and “PLAY”. If the Super Expander capabilities had been built into the VIC, I expect I would have stayed with the VIC until I could afford a C64 (assuming it had the same). And only in my VIC research did I find there had been a C64 version of Super Expander. I have not looked into what that could do, but I can only imagine it added sprite commands and more music capabilities.
Amiga, of course, was the greatest thing ever. It took PCs a decade or more to even catch up. A real shame. Imagine where we would be had Amiga won out.
“Contiguous”… Does this imply you can have memory expansions in blocks at other locations?