Date   : Tue, 08 Jul 2008 20:22:05 +0100
From   : info@... (Sprow)
Subject: ROM type byte inconsitancies

In article <080708085502@...>,
   Jonathan Graham Harston <jgh@...> wrote:
> More Tube oddities:
>  
> Documentation such as the New Advanced User Guide says that the
> ROM type byte indicates the code in the following way:
>  
>   x0 0000 6502 BASIC
>   x2 0010 6502
>   x3 0011 68000        
>   x8 1000 Z80          
>   x9 1001 32016        
>   xB 1011 80186        
>   xC 1100 80286        
>   xD 1101 ARM          
>  
> However, the 32016 reference manual says the ROM type byte for a
> 32016 ROM should be x9 OR 2, ie xB - the same as 80186.
>  
> The 32016 client OS does: AND &D, CMP &B so both the documented
> ROM byte and the programming example ROM byte are recognised - but
> also a 80186 ROM byte!

I'm confused:

 9 AND 13 = 9
 11 AND 13 = 9

so shouldn't the 32016 client be doing AND &D, CMP &9?

> Additionally, various documentation say that bit 1 should always
> be set. Why? 

The Master MOS's OSByte ROM header checking does

  IF bit6 clear "This is not a language"
  AND 13 * 2
  IF nonzero "I cannot run this code"

so 13x2 (%11010) seems to be being used to deduce whether it can be run by
the MOS or not. This would reject Electron ROMs which had the "firm key"
bit4 set, but oddly would also reject 6502/68000.

> That's probably why the example 32016 code sets bit
> 1, so uses a ROM byte of &B, but that means ARM ROMs should be &F,
> not &D, and the Archimedes RomFS manual specifies &D and used &D
> in examples (aside: as does the Sprow ARM CoPro manual).

Yes, I too read the RomFS manual and decided 13 was a good number to use.
I do
        ; Is it ARM code?
        AND     r2, r2, #&F
        TEQ     r2, #ROMImageTypeProcARM

Sprow.