CBM 5/6/700 - Discoveries Part 2

• The 500 had a very slow scroll speed. Considering that the C128 40-column screen had as much to do as the 500, what with handling windows etc, and did it about three times faster (500 processor clock speed was identical to a C128 in SLOW mode) the difference was entirely down to the way the screen routines had been written. Upon investigation it transpired that whenever a character was written to either the screen or colour memory, a loop continuously checked what had just been written until it was stable. One can only imagine the state of the early systems that required this bodge. As both calls went through a RAM vector it was a simple matter to replace the loop with code in RAM that just set the values and carried on without checking. This almost doubled the speed and did not give any problems whatsoever - a rewrite of the rest of the screen-handling routines would have been needed to get up to the full possible speed. The offending screen routines were at $E641 (screen) and $E650 (colour memory) with the vectors at $03B7 and $03B9.
• Commodore's manuals for their 8-bit machines were usually quite dire but the thing supplied with the 5/6/700s was really terrible. It couldn't make up its mind as to what the machines were actually called referring to them by both their American and European names. The machines were known as the B256, B128 or P128 in America (Bxxx were the 600/700 series and Pxxx the 500 where xxx represented the memory size. The ESCape key table starting on page 40 used both types of reference. Appendix D, the character codes table, was actually for the VIC-20. Most of the book just pointed out that you could find the information you were after in the Programmers' Reference Guide (if you could find a copy - I was sent a photocopy of it by another ICPUG member).
• Amazingly enough, the manual did contain full pin outs (with a couple of errors) of all the connectors, internal and external, which vaguely indicated how the memory could be expanded above the internal 256K and how other processors could be added.
• The port marked 'User Port' in the manual was, in fact, the IEEE port using the same flat-edge connector as the PET. The User Port itself was an internal set of connector pins and contained TWO eight-bit ports.
• The TI$ clock (TI no longer existed) was a hardware-derived value from the TOD clock on the 6526 and was therefore not subject to the problems that the software clocks had on the C64/128. Unfortunately it was not zeroed at power up. Tl$ was now 7 digits long with the extra digit representing tenths of a second. The manual gave a formula to calculate the equivalent value of TI from TI$ by multiplying VAL(TI$) by 60 - it doesn't take much working out that this was highly inaccurate!
• Running machine code in banks other than 15 was not so easy. Once bank 15 was switched out the machine lost all access to the ROMs including interrupt coding and the Kernel jump table, and also to the RAM work area in zero page and above. However, there were routines built into the Kernel ROM that, once copied into the RAM banks, allowed jumps to be made across banks via code transferred between the system stacks in each bank. It was a pity that it wasn't automatically copied on power-up. The code was at $FE9D to $FF34 ($FEAB to $FF2C in the 500 - but see below) and, if used properly, maintained all the processor register values. By building a new Kernel jump table in RAM where all calls point to this coding it was possible to use Kernel calls from any bank in the normal fashion. The interrupt coding does, however, require rewriting to work properly. This method of banking has the advantage that you gained a completely free zero page and stack in each bank. The 6/700 could use the SYS command to jump to the bank set by the BANK command despite indications in the manual to the contrary. The 500 was, however, missing two small portions of code, one in the BASIC ROM and the other just before the bank switching code and, due to this, SYS would only access bank 15. The extra code required to enable it to access any bank was small enough to be placed in the 1K free RAM in bank 15 at $0400.
• Although the manual did not mention it, the Kernel contained a machine-code monitor accessible by the usual SYS4. It was similar to the PET version (TIM) though not as extensive as the one in the C128. It contained extra commands to switch banking so all banks could be viewed or altered. Using the code described in the previous section above, I managed to get the far superior C128 monitor working on the 600 from bank 3 which allowed assembly and disassembly. Getting it to work on the 500 would have required a bit more work but would not have been impossible.
• When powered up, the 500 positioned its screen memory in 1K of static RAM located at $D000 in bank 15. When using this bank it was possible to turn on the sprites but not to redefine them. Hi-res also could not be set up in this bank as there was not enough free RAM available. After much POKEing about I discovered how to transfer the video access into bank 0, set up the hi-res screen and properly define sprites. As with the C64, there were no specific commands to handle any of the special features of the VIC chip. Unlike the C64 the character set was freely accessible and didn't require special banking POKEs in order to PEEK its values - it lived at $C000-$CFFF in bank 15. Note that the 6/700 could not switch its video out of bank 15 though there was a rumour of either a hi-res or colour add-on for the 700 - whether it ever existed I have no idea.
• The 500 had two standard joystick ports, which could be read by PEEKing locations $DC00 (fire buttons) and $DC01. But the IEEE I/O port was also mapped at $DCOO, so pressing a fire button when trying to load a program caused havoc - a very strange (and stupid) design fault! The 600 had occasional problems when trying to access my 2031 single disk drive but that model was prone to be slow in responding to commands (it also had problems talking to PETs that were using BASIC 2.0 though BASIC 4.0 PETs worked ok) - the slower 500 had no problems.
• As supplied, the 500 came with no TV modulator and no monitor lead either. I obtained a second-hand VIC-20 modulator for £1 and this worked perfectly although I had to remove its connector and hard-wire it in internally. The pin-out of the video port was NOT the same as described in the manual which described the VIC-20 layout. Instead, like the C64, it was an 8-pin DIN configuration but had either a 5 or 12-volt output on one of the extra pins (the voltage depended on the setting of an internal link - mine was at 5, which was correct for the VIC-20 modulator).
• The BASIC, although labelled BASIC 4.0, contained several extra keywords over normal PET BASIC 4.0. With one exception, the DISPOSE command, all were later implemented on the C128. DISPOSE only appeared because of the possibility of running out of stack on these larger memory machines. The later C128, C16 and Plus/4 models got around the problem by implementing a new software stack to handle the GOSUB, FOR and DO/LOOP requirements. One interesting item in the manual was the warning that DELETE with no parameters following it would delete the entire program. In fact, this did not happen and the program would remain unscathed - you had to enter line numbers to perform the delete.