ROM bugs

ROM 3.0

• The BASIC command ROLL in direction 1 (left), with a shift by 1 pixel and with width of area 2 is incorrect,
  the pixel on the left edge of area (high nibble of byte) does not roll back to the right side (low nibble of byte), so that data is lost as it only duplicates the low nibble of byte on the right to the high nibble of byte on the left.
   
• Type: def keycode 192,chr$ 58 then press F0.
   
• Defining DOS command to Keys
  Whilst helping a friend to construct a small program which defines the “F” key to do different things, I came across an unexpected problem. One of the keys was going to be defined as “DIR1”. We used the following line:-

  10 DEF KEYCODE 195: DIR1

  Now according to the manual, this should work, but what we found is that the machine crashed when “Enter” was pressed to insert the line. Try it yourselves and see.

  I got in touch with Bruce Gordon, who said that he knew about this particular problem. It happens when you define a key to do a DOS command of any type. The syntax check doesn’t do it’s job properly and the machine crashes. This doesn’t happen with “LOAD” or “SAVE” as these are not handled by the DOS, but the ROM.
  You can get around it by putting the DOS command in speech marks like so:-

  10 DEF KEYCODE 195,"DIR1"

  This is accepted by the syntax, because it doesn’t check anything within the quotes. It’s only a small problem, but it could wipe out a lot of work if you used it without thinking.

  Since writing the above, I have found out that the “bug” is not present on the very latest DOS. This is the DOS that you get with your ROM upgrade pack. I would still suggest you use the “fix” though, as it is very easy to load in an older DOS from aprevious disc, without realising it. - K. Purcocks, SAM Supplement 2

• Input buffer bug

  The other thing is a fix for the INPUT bug which crops up in many programs. What happens is you get the character from the last key pressed before the input popping into the INPUT so you have to delete it before proceeding! In the case of Flash! this is usually a 0 in my case as I use a joystick and the 0 is the fire button (the last thing pressed before exiting to BASIC to save or load etc.). To cure it add a line…

  1002 POKE 23611,PEEK 23611 BAND 223 (with line-no. for FLASH)
  - Brian Cavers, SAM Supplement 10

• If you have more than 16k (I think) of label definitions, then BASIC crashes horribly.
   
• When you do INPUT #2 and then do something.
   
• After a program has been loaded from tape, if xos, xrg, yos and yrg are not in memory or if the gap between numeric and string variables is less than 512 bytes then the Sam crashes horribly.

• RESTORE does not seem to work unless you use a line number. “RESTORE:READ A” usually says “Statement end error” or some other weird error.
   
• Storing the address of the FOR statement within a variable might be a good speed-up, but it is rather unstable. Consider:

  100 FOR i=1 TO 10
  110 KEYIN STR$ i+” REM test”
  120 NEXT i

  I have once written a loop (probably similar to the above, but I can’t remember) which went on forever because the Sam kept re-executing the FOR instruction and resetting the control variable - Ian Collier on the Sam Users Mailing List June 19th 1994

• When the reset button is pressed the SAA1099 sound chip is not disabled early enough in the boot sequence so notes being played will continue.

ROM 2.0

ROM 1.0

• Bootstrap code with SamDOS V1.1 loads but does not execute, causing the user to manually CALL the DOS code (CALL 229385 on a 256K or on a 512K CALL 491529).
   
• If you tried to scroll the screen with any character height other than 8, there was a very good chance it would crash horribly.

See also Hardware Bugs and Troubleshooting and Maintenance