Home Web Design Computing Music

CBM 5/6/700 - Discoveries Part 1

At the time I obtained the 500 and 600 there was precious little available information about them. So I set about delving into their internals and POKEing around to see what I could discover. The following list is an expansion of the information I sent to Adwells:

  • The 600 may well have been the replacement for the 500. It used the same casing, with the exception of the back panel that held the connectors and the colour of the LED at the front - green for 500, red for 600. The keyboard layout was identical but the control key functions differed on the 500 because of the need to control colour.
  • The operating system of the 600 - Kernel and BASIC - was identical to that of the 128K 700 series though the character generator chip was different as the 700 had 9x14 pixel characters. When the system powered up, it first checked to see if it was a 700 with a built-in screen (bit 7 set on the port at $DF02) and, failing that, tested bit 6 to see if it was running at 50 or 60 Hz after which it set the 6845 video chip accordingly. The code for this was at $E260. BASIC was at $8000 to $BFFF, the Kernel was at $E000 to $FFFF with the I/O chips and screen memory at $D000 to $DFFF (all in bank 15).
  • There were several sets of ROMs around for these machines. Early ones apparently contained the code to run the cassette port though this was dropped to make room for the IPC code to interface with the second processor. Any attempt to load or save to tape on the later versions gives the error '?DEVICE NOT PRESENT'. The remaining cassette coding jumped through only one vector (at $036A) before going off to the error message. To determine which call was being processed through the vector would mean checking the return address left on the stack. The electronics side of the cassette port worked properly, so it would have been possible to reinstall the code in either RAM or as an add-on cartridge.
  • The ROM numbers for both my machines were:
    500600
    Kernel901234-02901244-03B
    BASIC hi901235-02901242-02
    BASIC lo901236-02901243-02B
  • The ROMs were, in fact, 2764 EPROMs sitting in adaptor sockets in the 600 and in an adaptor board in the 500. Adaptors were needed because the EPROMs were 28-pin and the sockets in the board were 24-pin for 2364 ROMs.
  • RAM banking on the 5/6/700s was handled purely by the 6509 CPU and was quite unlike that of the C128 where the bottom 1K of memory was never banked at all (the C128's 8502 CPU could only access the bank that was currently set by the Memory Management chip). See page 4 for more information on the 6509.
  • Unless upgraded, the number of RAM banks available depended upon the model number - the second digit in the model number indicated the size: 0 meant 64K, 1 was 128K and 2 was 256K. My 500 was actually marked 510 and, similarly, the 600 was really a 610 - both came with 128K. Adding new banks of RAM didn't mean that you would automatically get access to them from BASIC - this was actually determined by the BASIC ROM. I managed to obtain the source assembler code for the 6/700 series and it could be plainly seen that it could be conditionally compiled for all three RAM sizes. No doubt, making one system that catered for all sizes would have slowed the machines down.
  • The way the RAM banks were used was as follows (the numbers are the RAM bank number):
    500 (128K)6/700 (128K)6/700 (256K)
    BASIC Program011
    All Variables12-
    Simple Integer/FP Vars--2
    Array variables--3
    Strings--4
  • When the machines powered up they checked each RAM bank in succession by writing to EVERY LOCATION (non-destructively - the original value was restored after the write). As each bank took around 2 seconds to be fully checked this meant that a machine upgraded to the maximum possible 896K of memory would take over half a minute before the power-up message came up. For the 500 all the timings were doubled as it had a 1MHz system clock whilst the 6/700s ran at 2MHz. Note that the 500 allowed a possible expansion up to 960K instead of 896K as its first bank was bank 0 (theoretically the 6/700 could go up to 960K as well by adding RAM in bank 0 but this would never be checked by the operating system which always started at bank 1).
  • Although BASIC use of memory was determined by the BASIC ROMs, the Kernel could realise that extra memory existed provided it was contiguous - i.e. a system having banks 1 to 6 and 8 would not recognise bank 8 as it would halt its search when bank 7 was found to be empty. BASIC used the top of the highest bank found to store the function key definitions and the RS-232 input buffer. There was no RS-232 output buffer - each data byte was sent straight to the 6551 chip and then the system looped until either the byte had been processed or the STOP key was pressed. Other buffers were placed at the top of bank 1 (bank 0 in the 500) - these were the 160-character input buffer, the random number used by RND and various odd bytes used by maths routines. These were all located by pointers in zero page (bank 15) and so could be shifted down if the user needed the memory for other purposes. When using the RS-232 channel the computer could be made to do automatic ASCII to PETSCII conversion, and vice versa, by using a secondary address above 127.
  • On opening up a 128K machine you could see where the extra 128K of RAM was meant to go. Unfortunately the boards were flow-soldered, which meant that all the pin holes for the empty RAM banks had been filled in and required an hour or two of careful de-soldering before any new chips or sockets could be inserted. The chips required were the once-standard 64K by 1-bit dynamics (4164, 4564, 4864 etc.) at around 150nS. Also needed were a couple of electrolytic capacitors (10 to 20uF in the 600, 2 to 10uF in the 500) and some 0.2uF decoupling capacitors. The electrolytics went just to the left of the RAM chips (to the right in the 500) and the decouplers went in between each RAM bank - the existing RAM banks would give an indication as to what was required.