8271 disc controller de-cap and craziness -- do not try this at home!

discuss both original and modern hardware for the bbc micro/electron
User avatar
BigEd
Posts: 3591
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by BigEd » Sun Sep 06, 2020 9:09 pm

Diminished wrote:
Sun Sep 06, 2020 8:44 pm
They're transistors, yes? Not resistors?
Yes, depletion-mode transistors, wired as two-terminal devices - for many purposes, rather like resistors (but with a variable resistance.)

guesser
Posts: 493
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by guesser » Mon Sep 07, 2020 1:48 am

I've traced back the input bits 8 and 9 to the small ROM decoder and they're are related to rows 0 and 1 of these decode tables.

I'll need to trace out a bunch of the logic below the left table to see what actually controls them to see which columns activate them and how. :)
A web based teletext editor which can export as Mode 7 screen memory: https://zxnet.co.uk/teletext/editor
Join the Teletext Discord for teletext chat.

User avatar
Pernod
Posts: 2299
Joined: Fri Jun 08, 2012 11:01 pm
Location: Croydon, UK
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by Pernod » Wed Sep 09, 2020 1:26 am

Latest from Sean:
I uploaded 3 more pics; top metal and top metal removed die shots of a 2nd 8273 and a pic of one of the 8271s after Whinking it again.

Since I had 3 8273s, I used a chisel to break the ceramic package at the ends of the milled recess that the die sits in. That way, there would be less ceramic to interfere with the acid, and it would be small enough to fit in a test tube. Since it broke cleanly I tried it with the 8271s, but one die broke in the process. I also wound up chipping the first 8273 die. And it doesn’t seem to have helped the metal removal much. I guess these chips have a thicker passivation layer than other ones I’ve worked with.
- Nigel

BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.

User avatar
Diminished
Posts: 580
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by Diminished » Wed Sep 09, 2020 1:31 pm

Program ROM, first attempt. Mistakes are guaranteed.
program_rom.png
I'll have a shot at reading this algorithmically after lunch, unless someone else fancies doing it.

Raw; I'll get bytes out in a sec.

Code: Select all

10101000 10101001 10101000 10101000 11011100 01101001 11111101 11111001 
10101010 11111110 10101011 10101011 10101010 11111011 11101111 10101101 
01000101 01000101 01110101 01110101 11011111 01011111 00011111 01010111 
01110100 01110111 01010110 01111111 01010111 01011111 00011111 00111110 
01011100 11011101 10010100 11011111 01010100 11010101 10000111 10000110 
01010101 11101100 11110101 01110101 00000100 00111101 10011101 10000010 
00101101 11110101 01111110 10111101 00001101 10010111 01000011 01010111 
01111101 00101001 01101111 01101101 00111101 01111011 01011011 10100000 
01100010 00101001 00111000 00100000 10101100 00001001 10111100 01111010 
10011100 10111100 10011000 10101100 10111000 10111000 01010001 11100101 
11010001 01010000 11110001 01011101 01111000 01011101 00011101 10110110 
01100110 00100010 01110110 00110010 00110110 00100111 10000011 11011011 
10010010 10010110 10011000 11011010 11010000 11010001 11100001 10010000 
01001110 10010110 10010010 10010111 01001000 11111010 11111001 01001011 
11101111 11101010 01010100 11010110 01100110 01110110 01110101 01110101 
01010011 01000010 01000010 01000011 11001010 11001010 11001000 01110000 
00110010 01001110 11011010 11011010 10010010 11011010 10011100 10011110 
01001110 11000110 01001100 01000100 01000110 01000100 10010000 10011111 
11000111 01001111 11100110 11110100 01000110 11001111 10001111 01000100 
01110001 00110111 01100011 01100100 00100101 01110111 01111011 10011111 
00101011 00100001 01110001 00110001 01100011 00100010 01000111 11100011 
01101100 10110110 00100100 11101100 01111100 01111100 00010100 01111010 
00100010 11111110 01110110 10111010 00000000 10010110 11000101 01110111 
00101001 11101011 00101001 00101111 00101001 01101011 11101001 10100100 
11001001 10010010 01001001 01011011 00100100 11101101 00100100 00100000 
00100001 01000111 00101011 01000101 10001000 10101100 00000010 10001110 
00011011 11111011 10111111 11011011 00001011 10101110 10101110 00100111 
10001010 10011110 01101010 01001010 10000010 00010110 10000000 10000100 
00010111 00110110 10010000 10010101 01010011 00110111 00111101 00110100 
10010110 10110010 10010010 11010010 10010101 00110110 11101110 10110110 
01011000 11011001 01000000 01010010 01011000 10011001 11100011 10010101 
10110101 10111101 10000100 10100101 10010100 00111101 01001111 10101000 
10101100 11101100 00100110 00101110 10101100 11101111 01011010 01000110 
01101110 01101011 00101010 01111111 01101110 01001101 01110111 00111111 
00010001 00110111 10110001 10010101 00010001 11100110 10111111 10101010 
10011101 10111101 10010101 00001110 10011101 10011001 11101111 11010010 
10111101 10111001 10010110 11110110 10111011 10010111 11010111 10101010 
10011001 10111011 00100010 11101110 11011101 00110010 00010000 11101011 
11000110 11000110 11100011 01110010 11000010 11100111 10100101 01101011 
11101101 11000100 11111100 01010100 11011110 11111000 11101110 10011101 
00101010 01101001 11111000 00101001 01101100 01111001 11011100 11100010 
01010101 11101111 11110101 01100101 00010001 00111011 10010000 10010011 
11111111 11111010 10101010 01101011 11111110 10101100 00100110 01101011 
00100111 11111111 01110101 10111111 00000110 10011101 11001100 11000101 
01101111 01101111 11011101 00001111 01101111 01110101 01011100 01111110 
10101111 10101111 00101111 00101000 01111011 11111100 01111111 11101010 
11000010 11001110 01000110 11100010 11000010 10000110 10111101 00110101 
00110101 11111100 00111100 10100100 00110101 11011000 11101000 01011010 
10010000 11111111 11110011 11011010 11111101 11110011 01111111 00101011 
10011000 10101000 01101100 10111110 01001000 00101000 11010000 10001000 
01000111 11011111 11000111 01010101 00000111 11011011 11111110 10101011 
11001000 01111011 00011000 11101010 11101000 11110011 11011111 01111101 
11101111 11111011 11111011 10101000 11101111 01110110 11010111 00111011 
01001100 01001111 01101001 01111010 01001000 01001110 00001011 01000111 
10010111 11110111 11011110 11010101 00110010 01011111 00001110 01011111 
11010100 11010100 10110111 10010110 11000100 11010010 00011100 10010100 
01010000 01010001 10011000 01011100 01010000 11010000 01100011 01010010 
11001111 10001111 10000101 10011101 10010101 11011111 01001100 01010011 
11010010 01011101 01110100 01011101 11011001 10111101 11010110 01101111 
01110011 10100010 10100011 10100110 00100111 10110100 11100010 11010111 
01111101 00111111 00101011 10111001 10111001 10001111 11101011 11110110 
11100110 10101110 10101111 10010110 11100111 11101111 01101110 11111101 
00011010 01111110 00011110 01010010 00011000 00101110 11110111 11111111 
00100110 11101110 00101110 10100111 00100010 11101010 11101000 00101111 
00010100 00010100 10011110 10010110 01100001 00110110 00000110 00000110 
01010001 11010001 01011001 01011001 01010001 10010101 11100000 10010001 
11100100 01100100 01100100 01000100 11010110 11100000 11110110 00000100 
00110101 00010001 00010001 00010001 01011001 00000000 11011011 00110101 
11101101 01100100 01001101 01100100 11011111 11100100 11111011 10000100 
00110101 00110101 00110101 00110101 01111101 00110101 11101111 00110100 
10110110 00110111 11011110 11010111 00110111 11000011 11011110 10111111 
01010010 11100010 01111110 01111010 11010011 11100011 00110010 01000010 
10100010 10100010 10100101 10110010 11100010 11110011 10101011 11110011 
10011100 10001000 10001110 11011010 10011100 11011110 00101000 10000001 
10011111 10010100 11010110 11010100 10011101 11001011 01011100 11111101 
11111111 10110101 11110101 10011110 10111111 11111110 10101011 00010110 
01110111 11100010 01111010 01111110 01100011 10111111 00111001 00010110 
10110011 11101111 11101111 11101101 10111111 00111101 10011110 10101011 
00101111 00100010 10110011 10111011 00100110 10000110 11110010 10110001 
10101010 10100000 11101110 10100100 10101001 11101010 01100101 11010100 
10111001 00110011 00011101 00011110 00110011 00011110 01011110 11101000 
01011010 01110100 01010100 00011110 00011110 00101110 10001100 10010110 
01011110 00001011 11001011 10001110 00101110 01001100 10100110 10011010 
11010100 11011100 11010100 01010100 01100000 11001100 10110101 11101001 
11111101 11111101 01101000 00111000 10111101 01100001 00111110 11111010 
11111010 11111011 11010001 01110011 01111000 11000001 11111101 01010100 
01110110 11011110 01010111 11110011 11110010 11110111 10101001 01110011 
01100111 01000101 11111101 01111111 01000110 01110111 01111011 00100101 
00101101 00101100 10111110 10101001 11001001 00000001 11101111 01101111 
10001011 10000111 11100011 01000010 00010010 00100110 11010010 01001110 
00111011 01101010 10100110 10101000 00111101 00111001 10011001 10111010 
10110010 10000010 10010100 11011010 11111010 01111010 11110011 10011011 
11101011 11100001 01100101 00000111 11110001 00100001 00010100 10001101 
11010011 01110111 01111111 01010101 11010110 11000111 11011111 00111111 
00010111 10001111 00110110 11110111 00000110 10011011 01100111 11101101 
10000100 10000101 10110100 11100101 00000000 10010001 11101000 01101001 
10000010 10000000 10000000 11000000 00100100 10000000 01100100 01000010 
01110101 01100111 00111101 00111001 00100101 00111111 10110101 11011010 
01011001 01011001 01011101 01011101 01101001 01001100 00110101 01101011 
00011111 01011011 11001010 01011111 01011011 01011101 11001110 11100110 
01011111 11010111 01010101 01010111 00011101 11011110 00001101 10011011 
01101111 01101011 11111000 01101010 01101111 11100111 01001111 00101110 
11011001 11011001 11001111 00001101 11001001 11001101 10100101 11111100 
10101010 00111010 11101010 11001011 00100010 10011010 10101010 11110011 
10111011 10110001 10101111 10100111 11100001 11111101 11011111 11111001 
01010111 01110101 01010101 01010111 11010111 11010110 11110011 00110101 
11010111 01010011 11010110 11010110 11110010 01110111 01100011 01001110 
01101011 01000001 01111011 01111001 10011101 10110011 11110011 11010101 
Preliminary:

Code: Select all

04 f0 08 f4 00 f5 ff b8 
00 b9 00 bb 00 bc 01 c8 
f7 02 cf c0 f1 00 f0 00 
ff 03 2e 00 e8 00 80 a1 
88 23 ff 03 2f 00 ec a9 
9c 0f 8b 49 b9 01 fe 49 
ab 9c 0f 8a 47 02 d8 20 
fe 49 02 71 01 47 d9 01 
f5 7e 04 dc 90 f5 7e bb 
02 fc a2 11 03 2e ff fc 
5e 03 d6 00 e1 e8 fe 49 
fc 5e 03 c6 fe 53 00 f8 
00 e1 fd 02 cf bf 2f f9 
89 70 f9 89 70 2f 0a ec 
2f 00 30 c8 3f 40 23 7c 
f1 00 fe 7e f1 ff 03 6f 
c0 8b 7f 40 88 bc 02 ff 
bc 03 ff fc 5e 02 36 fe 
49 02 cf ef b9 00 11 39 
fe 49 01 38 fc a2 98 10 
fe d4 02 cf 7f fd 70 04 
af 62 02 b0 62 01 be ff 
a9 9c 0e 8a af 98 0a fc 
bc b9 00 ff 01 ee ab 01 
3b 4b f0 af 4b f1 af 4b 
f2 af 5b ff d2 aa 9c 0f 
89 af 98 0f 01 d8 00 06 
34 cf df bb 0f ba 03 ff 
cf f7 b8 00 fd 28 33 61 
04 ed b8 02 fd 70 08 f7 
b8 05 fd 22 33 fe ed b8 
06 fd 2a 33 b8 01 fd 29 
33 b8 03 fd 21 02 c8 fb 
ff 21 04 ec 02 60 04 a8 
c8 fb 98 05 fc a9 b8 05 
10 fc bd 12 21 05 ec 11 
00 ed 26 01 36 49 c0 31 
26 e6 8a 31 26 e7 8a 36 
11 02 c8 ef fe 39 02 d8 
10 01 59 c2 50 04 f5 7e 
dc 90 02 d9 01 f5 7e ab 
9c 0f 8b 50 bb 0f ba 02 
13 26 00 37 02 71 04 6e 
a8 9c 0f 8b a9 00 27 0a 
df 10 32 d8 04 00 26 03 
3a f0 00 f1 00 19 14 15 
21 07 ec fc bd 98 03 fc 
a9 b8 05 12 98 07 fe 77 
03 81 90 01 a4 b5 88 90 
2c d5 8b 6d 02 cf ef ff 
98 09 fc a9 b8 05 10 02 
61 20 a2 98 04 fc a9 b8 
05 11 02 98 06 71 10 14 
ff 02 cf ef 01 3a a8 9c 
0f 8a b7 02 d8 08 10 2a 
02 33 df 08 fd 04 cb df 
db 20 fd 02 cf ef fc bd 
03 78 ff e2 29 01 3a 02 
71 04 da 01 a2 88 7c a2 
88 7c 01 7a ff e2 04 56 
e0 7c 04 26 01 3a 98 01 
02 70 10 ee 98 00 01 d2 
fc ac b8 04 12 98 08 fc 
a9 b9 00 ff 98 0e 02 ee 
cf f7 f3 0b df 08 c8 f7 
b8 05 fd 02 cf fb ff 02 
71 01 19 f5 ff 04 f5 ff 
fd f5 7e 04 f5 7e fd 04 
70 01 29 f5 55 02 f5 55 
fd f5 00 02 f5 00 fd 01 
48 c9 36 04 dc 04 00 a2 
b3 02 89 45 cf df 00 f3 
00 f2 00 ea fd df 20 d8 
02 eb fd 63 01 53 cb fe 
02 c8 fe 04 70 04 5b 72 
01 5b 11 02 61 02 60 15 
bb 07 01 48 c9 6a 02 71 
04 8f 02 71 80 81 14 02 
c8 fd 04 cc 6f 73 01 4e 
02 d8 01 fe 53 cc 5b f5 
7e fc 36 01 48 c9 a1 17 
fc 1f bb 06 61 80 62 ff 
cc 5b f5 7e 02 61 04 9f 
18 02 f4 0d ba 09 ff fc 
36 1a 00 24 04 35 fc 33 
19 00 25 04 35 fc 2f 89 
a1 02 60 02 bd 1b 02 c8 
df 01 48 c9 cd 02 61 08 
c5 f4 0c df 04 1c dc 60 
1d cc db f5 7e ba 00 1f 
cc bf 02 70 20 d7 1e 71 
04 e1 71 40 e2 df 20 fc 
36 17 13 f5 7e cc 6f 02 
71 01 9e 04 dc 80 10 08 
aa ec cc 4b ba 04 01 28 
09 ec cc db fc 0f ff aa 
0b ec f5 ff ff f5 7e ff 
fc 3e 01 48 ca 11 ba 01 
ff 02 f4 0d 02 c9 fe 04 
dc 80 fe 23 01 68 04 23 
ba 0b ff 02 70 01 2a 04 
db 01 02 df 04 70 20 31 
10 12 fc 3e 02 c8 df 01 
48 ce 14 ba 09 ff 00 ee 
00 f0 02 38 58 c9 4d 00 
f1 01 bc 00 ff 02 61 04 
47 00 f1 03 fe 4a 00 39 
f0 0c 49 c0 47 f6 59 00 
There's a similar Bx 0x Bx 0x ... sequence near the start as for the 8271 ROM, so hopefully I've swizzled it appropriately.

Byte frequencies:

Code: Select all

     56 02
     42 00
     40 01
     36 04
     30 ff
     24 fc
     19 f5
     18 fd
     17 fe
     14 03
     13 b8
     13 98
     12 df
     12 cf
     12 7e
     10 c8
     10 71
     10 70
     10 10
     10 0f
      8 ec
      8 cc
      8 ba
      8 a9
      8 49
      8 08
      8 05
      7 f1
      7 d8
      7 9c
      7 61
      7 36
      7 20
      7 11
      6 f0
      6 dc
      6 c9
      6 bb
      6 af
      6 a2
      6 48
      6 33
      6 26
      5 f7
      5 ef
      5 bc
      5 b9
      5 8b
      5 8a
      5 89
      5 88
      5 80
      5 5b
      5 2f
      4 f4
      4 ee
      4 db
      4 c0
      4 bd
      4 90
      4 7c
      4 60
      4 4b
      4 47
      4 3a
      4 23
      4 21
      4 14
      4 12
      4 09
      4 06
      3 fb
      3 ed
      3 e2
      3 e1
      3 ab
      3 aa
      3 a8
      3 a1
      3 6f
      3 62
      3 5e
      3 53
      3 40
      3 39
      3 31
      3 2a
      3 29
      3 19
      3 0b
      3 0a
      3 07
      2 f9
      2 f3
      2 f2
      2 e8
      2 d9
      2 d2
      2 cb
      2 bf
      2 81
      2 7f
      2 59
      2 55
      2 50
      2 3e
      2 38
      2 35
      2 2e
      2 28
      2 1f
      2 17
      2 15
      2 13
      2 0e
      2 0d
      2 0c
      1 f8
      1 f6
      1 eb
      1 ea
      1 e7
      1 e6
      1 e0
      1 da
      1 d7
      1 d6
      1 d5
      1 d4
      1 ce
      1 cd
      1 ca
      1 c6
      1 c5
      1 c2
      1 be
      1 b7
      1 b5
      1 b3
      1 b0
      1 ac
      1 a4
      1 9f
      1 9e
      1 8f
      1 7a
      1 78
      1 77
      1 73
      1 72
      1 6e
      1 6d
      1 6a
      1 68
      1 63
      1 58
      1 56
      1 4e
      1 4d
      1 4a
      1 45
      1 3f
      1 3b
      1 37
      1 34
      1 32
      1 30
      1 2c
      1 27
      1 25
      1 24
      1 22
      1 1e
      1 1d
      1 1c
      1 1b
      1 1a
      1 18
Crap PHP script:

Code: Select all

<?php

  // expect raw RGBA 32

  $s = file_get_contents("program_rom.data");
  $w = 2112; // pixels
  
  //$s = file_get_contents("8271_test_program_rom.data");
  //$w = 2092;
  
  $bpp = 4;
  $expected_bits_per_row = 64;

  if (FALSE === $s) {
    print "Could not load file.\n";
    die();
  }

  $len = strlen($s);
  $rows = ($len/($bpp*$w));
  //print $len." bytes; ".($len/$bpp)." pixels, ".$rows." rows.\n";
  
  $r = ord($s[0]);
  $g = ord($s[1]);
  $b = ord($s[2]);
  
  //print "First pixel: (r ".$r.", g ".$g.", b ".$b.")\n";

//die();

  $pos = 0;
  $within_bit_row = 0;
  
  for ($row=0; $pos < $len; $row++) { // row
    $found_bit = 0;
    $within_bit = 0;
    $bit = -1;
    $bits = array();
    for ($c=0; $c < $w; $c++) { // column
      $r = ord($s[$pos + ($c * $bpp)]);
      $g = ord($s[1 + $pos + ($c * $bpp)]);
      $b = ord($s[2 + $pos + ($c * $bpp)]);
      $white=0; $black=0; $blue=0;
      $white = (($r==255) && ($g==255) && ($b==255)) ? 1 : 0;
      $black = (($r==0)   && ($g==0)   && ($b==0))   ? 1 : 0;
      $blue  = (($r==0)   && ($g==0)   && ($b==255)) ? 1 : 0;
      if ( ( ! $white ) && ( ! $black ) && ( ! $blue ) ) {
        print "Row ".$row.", col ".$c.": bad pixel! (r".$r.", g".$g.", b".$b.")\n";
        die();
      }
      if ( ! $within_bit ) {
        // look for a bit
        if ($white || $black) {
          // got one
          $bit = $white;
          $within_bit = 1;
        }
        // otherwise blue, keep going
      } else {
        if ($blue) {
          // end of bit
          $within_bit = 0;
          // copy bit to output
          $bits[] = $bit;
          $bit = -1;
        } else {
          // not blue
          if ($white != $bit) {
            print "Row ".$row.", col ".$c.": changed bit! bit = ".$bit.", (r".$r.", g".$g.", b".$b.")\n";
            die();
          }
        }
      }
    } // next column
    
    $nb = count($bits);
    
    if ($within_bit_row == 0) { 
      if ($nb>0) { // non-blue row?
        $within_bit_row = 1; // // first bit row
        $bytes = array(0=>0, 1=>0, 2=>0, 3=>0, 4=>0, 5=>0, 6=>0, 7=>0);
        $bytenum=0;
        $bitnum=0;
        for ($i=0; $i < $expected_bits_per_row; $i++) {
          /*
          print $bits[$i];
          if (($i%8==7)) {
            print " ";
          }
          */
          $bytes[$bytenum] = ($bytes[$bytenum] << 1) | $bits[$i];
          $bytenum++;
          if ($bytenum==8) {
            $bytenum = 0;
            //$bytenum++;
          }
        }
        for ($i=0; $i < count($bytes); $i++) {
          printf("%02x ", $bytes[$i]);
        }
        print "\n";
      }
    } else if ($within_bit_row == 1) {
      if ($nb == 0) { // blue row
        $within_bit_row = 0; // outside bit row
      } 
    }
        
    $pos += $w * $bpp; // next row
  }

?>
^^ Notes on this:
- the only colours it accepts are white, black, and blue (#ffffff, #000000 and #0000ff). Anything else will cause an error. So don't use antialiasing.
- it expects bit squares all the same size, in perfect rows, and with blue spaces in between (perfectly aligned columns aren't needed). Set up guidelines in your photo editor before you start.
- image width needs to be entered manually into the script ($w). So does the filename.
- input must be a raw RGBA32 bitmap. GIMP will export one of these for you (a .data file).

Now there's a semi-automated way of doing this, and we have many more photos than we did at first, I might read out the 8271 program ROM too, just to get a second opinion on that one.

Yet another edit: in case anyone wants to check my bits (hush), I've attached the transcription with transparency (8273_program_rom_transparent.png), so it can be overlaid over the die shots. This is at 50%.
Attachments
8273_program_rom_transparent.png

User avatar
Rich Talbot-Watkins
Posts: 1680
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by Rich Talbot-Watkins » Wed Sep 09, 2020 11:35 pm

Hey, that's great work! =D>

Do you think you could run this process through the best photos we currently have of the 8271 and get a new dump of the ROM (as we've found a few transcription errors here and there, but there may be more). Also, will the tool work on the narrow ROM which contains the entry points, both the inputs and the outputs? Turns out that they're a crucial part of how things work, and it's hard to understand the details without them!

Well, Chris and I have been beavering away, and we have a virtually complete disassembly of the 8271 ROM, here:

https://docs.google.com/document/d/1bQT ... WCyQ4lFVM/

It's early days, and the whole scheduler / task system thing is still barely understood, but we've got a pretty good handle on how a lot of the byte processor works.

We have the opcode map fairly complete, thanks to a combination of staring blankly at lists of hex, a bit of luck, a little intuition, and plenty of coffee! And, as per the conference paper, there do indeed seem to be 46 distinct instructions (not that we've figured them all out yet)!

As things gradually started to take shape, from a meaningless block of hex to living, breathing assembly language of our own invention, we started to figure out some of the secrets from within: how commands are decoded and dispatched, how the parameter count is determined, and the implementation of plenty of the commands (which also explains some of the weird quirks Chris found through experimentation). We also found an undocumented mode in the read IDs command!

Hopefully we should be able to unlock the remaining mysteries soon, but there are some opcodes whose function remains unknown, and I don't know if there'll be any way to figure them out without... making sense of the die shot #-o

User avatar
Diminished
Posts: 580
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by Diminished » Thu Sep 10, 2020 12:30 am

Blimey! =D>

Unfortunately I still have to go through the ROM by hand and manually mark each bit with a coloured square. This isn't some image processing magic. :( But at least this way, the final step of converting to hex is automated.

However, your timing is good, because I have just a few minutes ago completed this process for the 8271 program ROM. So I can now compare my dump to guesser's manual readout. It's different in quite a few places, so I'm checking those now.

I'm really looking forward to reading what you've done. What was the key to working out what was going on?

The narrow ROMs -- you want those for the 8273, not the 8271?

guesser
Posts: 493
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by guesser » Thu Sep 10, 2020 12:35 am

Rich Talbot-Watkins wrote:
Wed Sep 09, 2020 11:35 pm
Do you think you could run this process through the best photos we currently have of the 8271 and get a new dump of the ROM (as we've found a few transcription errors here and there, but there may be more).
Have you got a list of places you suspect errors? My transcription of the ROMs were done before we had the cleaner die photos, so I should probably go through and do them again (or better still, have a way to extract them from my vector file so I don't make any stupid typos).
Rich Talbot-Watkins wrote:
Wed Sep 09, 2020 11:35 pm
It's early days, and the whole scheduler / task system thing is still barely understood, but we've got a pretty good handle on how a lot of the byte processor works.

Hopefully we should be able to unlock the remaining mysteries soon, but there are some opcodes whose function remains unknown, and I don't know if there'll be any way to figure them out without... making sense of the die shot #-o
I'm amazed you can work out so much of this without any of the logic! :o
A web based teletext editor which can export as Mode 7 screen memory: https://zxnet.co.uk/teletext/editor
Join the Teletext Discord for teletext chat.

guesser
Posts: 493
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by guesser » Thu Sep 10, 2020 12:46 am

Diminished wrote:
Thu Sep 10, 2020 12:30 am
Unfortunately I still have to go through the ROM by hand and manually mark each bit with a coloured square. This isn't some image processing magic. :( But at least this way, the final step of converting to hex is automated.

However, your timing is good, because I have just a few minutes ago completed this process for the 8271 program ROM. So I can now compare my dump to guesser's manual readout. It's different in quite a few places, so I'm checking those now.
Since we got the new images I've vectorised the ROM but not transcribed that to bits yet. I'm not 100% confident I've not made any mistakes, but some of the bits were ambiguous before in the dirtier images.

Can you do any processing magic to extract the bits automatically from something like this? (being a vector file I can export it at whatever resolution is best)

EDIT: Thinking about it I don't know how consistent the vertical spacing of the lines is. I guess if that varies too much you couldn't just calculate a fixed offset and would have to scan downwards to find the gaps. :?
Attachments
foo.png
A web based teletext editor which can export as Mode 7 screen memory: https://zxnet.co.uk/teletext/editor
Join the Teletext Discord for teletext chat.

User avatar
Diminished
Posts: 580
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by Diminished » Thu Sep 10, 2020 1:30 am

There were a lot of differences between the two dumps, but predictably the majority of those mistakes turned out to be my own. Having corrected those, I see four differences between my 8271 dump and guesser's. I've checked the differing rows multiple times, but since I've marked up a grand total of 13,824 bits today, these could easily be my own mistakes too and my brain is simply too stubborn to acknowledge them.

Here is the diff. The differences are on ROM rows 1, 27, 28 and 64.

Code: Select all

$ diff -u guesser.txt mine.txt --- guesser.txt 2020-09-10 00:39:40.789125225 +0100
+++ mine.txt    2020-09-10 01:23:06.941091783 +0100
@@ -1,4 +1,4 @@
-0000000  fc 06 02 f7 00 ff b9 04
+0000000  fc 06 02 f7 00 ff b9 00
 0000008  ba 00 bb 00 bc 00 be 00
 0000010  04 f0 08 fd 02 f6 00 cf
 0000018  bf 00 f5 01 f4 01 03 98
@@ -24,8 +24,8 @@
 00000b8  cf b9 01 10 51 f4 d3 02
 00000c0  5f 18 c5 df 30 ba 01 13
 00000c8  ee fc de 0b fc c8 03 f4
-00000d0  03 3e 02 01 f0 0c b9 08
-00000d8  04 70 08 f0 04 ff 00 21
+00000d0  03 be 02 01 f0 0c b9 08
+00000d8  04 f0 08 f0 04 ff 00 21
 00000e0  eb 87 01 f0 10 04 63 80
 00000e8  ec 01 d8 08 01 3b 3c f8
 00000f0  01 6b ff f9 ea 94 93 2b
@@ -61,7 +61,7 @@
 00001e0  33 f4 00 98 ff fc ef f5
 00001e8  00 02 f5 00 f3 05 ff 04
 00001f0  f4 ff 35 c8 f3 db 01 bb
-00001f8  08 02 35 18 04 f0 08 e0
+00001f8  08 02 35 18 04 f0 08 f0
 0000200  05 15 fc 58 ed f0 00 f5
 0000208  ff 00 a5 65 1f 14 01 f3
 0000210  04 26 04 ee f5 01 be 04
 
And yeah, I don't see any reason why you couldn't come up with something to extract a dump from a vector image like that.

guesser
Posts: 493
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by guesser » Thu Sep 10, 2020 1:52 am

Yep, those are all stupid transcription errors on my part that I made when marking up the drawing.
A web based teletext editor which can export as Mode 7 screen memory: https://zxnet.co.uk/teletext/editor
Join the Teletext Discord for teletext chat.

User avatar
Diminished
Posts: 580
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by Diminished » Thu Sep 10, 2020 1:56 am

It was a pretty damn good effort.

guesser
Posts: 493
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by guesser » Thu Sep 10, 2020 2:00 am

It's because I marked up the transistors to ground as 0s and the lack of a transistor as a 1 (which we determined later was reversed). I realised too late how counter-intuitive that was, and it caused a lot of errors, most of which I caught a split second after writing the digit and had to undo and amend. #-o
A web based teletext editor which can export as Mode 7 screen memory: https://zxnet.co.uk/teletext/editor
Join the Teletext Discord for teletext chat.

User avatar
scarybeasts
Posts: 580
Joined: Tue Feb 06, 2018 7:44 am
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by scarybeasts » Thu Sep 10, 2020 4:39 am

Diminished wrote:
Thu Sep 10, 2020 12:30 am
What was the key to working out what was going on?
I think the breakthrough sequence was approximately:
- Rich starts looking at the byte processor PLA and observes two apparent ranges of 16 opcodes: 0x20-0x2F and 0x30-0x3F. These are candidates for direct register load and store.
- I noticed that these 0x20 and 0x30 ranges are often preceded by an 0x0x opcode -- so perhaps this is some form of bank select, given that there are 32 registers.
- I then got a bit lucky and was looking at code that happens to correspond to the SPECIFY / WRITE_SPECIAL_PARAMETER code. These routines do simple and well know operations. The appearance of the constant "3", i.e. 3 parameters to SPECIFY, was a nice clue. From previous black box testing, I also knew to expect a load of R7 for the first command parameter -- the command parameters tend to be loaded into R7, R6, R5... as the command is parsed.

Our current SPECIFY disassembly is below in case anyone wants to see a little routine that is fairly understandable, and get a feel for the instruction set.

Once you get one or two pieces that seem to fit, other discoveries typically fall like dominoes. i.e. you see constants that look like masks (AND #imm), you see where the DEC must be to maintain a counter, ...


Cheers
Chris

Code: Select all

.command_SPECIFY
066   00		SEL RB 0
067   27		MOV A, I7		; R7 ($07) (param 1)
068   30		MOV I0, A		; R0 ($00) = destination index
069   F1 03		MOV I1, #$03		; R0 ($01) = count of 3 extra parameters
06B   14					; seems to set PARAM callback to
						; .wakeup_PARAM_4_SPECIFY, then YIELD

; ** entry point (3, segment 9, routine 4 5 6 7 C D E F)
.wakeup_PARAM_4_SPECIFY
06C   03		SEL RB 3
06D   2E		MOV A, IE		; R30 ($1E) (ext PARAM)
06E   00		SEL RB 0
06F   E8		MOV [I0], A
070   00		SEL RB 0
071   80		INC I0
072   A1		DEC I1			; R1 ($01), decrement count
073   8A 8C		BZ $08C			; branch if done
075   FF		YIELD

User avatar
scarybeasts
Posts: 580
Joined: Tue Feb 06, 2018 7:44 am
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by scarybeasts » Thu Sep 10, 2020 4:50 am

Diminished wrote:
Thu Sep 10, 2020 1:30 am
Here is the diff. The differences are on ROM rows 1, 27, 28 and 64.
Magnificent, thank you! I already had the bytes at $D1 and $D9 as surely incorrect based on context.
I'll merge the other fixes into the document.


Cheers
Chris

User avatar
Rich Talbot-Watkins
Posts: 1680
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by Rich Talbot-Watkins » Thu Sep 10, 2020 10:18 am

scarybeasts wrote:
Thu Sep 10, 2020 4:39 am
I think the breakthrough sequence was approximately:
...rewind a bit more! It's interesting to document how it's possible to start extracting order from 1k of random data.

- The very first breakthrough was Chris reversing the dumped bits and noticing 'interesting' looking constants like E5 (default byte for formatted sectors), C7 (clock address bits) and so on. This gave us the first signs of the possibility of two byte opcodes (F4 xx and F5 xx to load immediate constants into registers).
- Then I noticed that FC-FF might be jump instructions, looking at the code at $2AB. At first I thought the bottom two bits of the opcode coded the top two bits of the destination address, but it became more and more evident that FC was more like a CALL, and FE more like a JMP. Knowing that the 8048 has JMPs within the current page, we tried that and it seemed to work.
- Chris proposed FD as a RET instruction (based on the routine at $178) which was delimited by FDs, and which we figured must be some kind of 4 bit shift.
- Then I spotted that 88-8C seemed to work as a conditional branch, and we spotted what looked like loops with backwards branches.
- At this point, this gave a lot of structure to the code, and we started trying to guess which opcodes might be 1 byte and which might be 2.
- Next breakthrough came when we had a list of the entry points from the narrow ROM; these coincided with various addresses which we had earmarked as the start of routines. Getting the PLAs dumped then helped to clarify which opcodes were from the same family and must therefore be the same length.
scarybeasts wrote:
Thu Sep 10, 2020 4:39 am
- Rich starts looking at the byte processor PLA and observes two apparent ranges of 16 opcodes: 0x20-0x2F and 0x30-0x3F. These are candidates for direct register load and store.
- I noticed that these 0x20 and 0x30 ranges are often preceded by an 0x0x opcode -- so perhaps this is some form of bank select, given that there are 32 registers.
- I then got a bit lucky and was looking at code that happens to correspond to the SPECIFY / WRITE_SPECIAL_PARAMETER code. These routines do simple and well know operations. The appearance of the constant "3", i.e. 3 parameters to SPECIFY, was a nice clue. From previous black box testing, I also knew to expect a load of R7 for the first command parameter -- the command parameters tend to be loaded into R7, R6, R5... as the command is parsed.
Worth also mentioning that at some point around then, Chris had the insight that there may well be three byte opcodes, which also performed a conditional branch - this is the range between $40 and $7F, which perform a throwaway AND or a XOR between a register and an immediate constant, and then branch if zero/not zero. This finally allowed us to finalise the structure of the code.

The task/event/scheduling system is the last remaining big mystery. We're making progress in understanding the flow (including how the format state machine works), but there are plenty of things which fit together but utterly nonsensically!

User avatar
Diminished
Posts: 580
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by Diminished » Thu Sep 10, 2020 11:06 am

Ah, so that unknown 2-bit ID was a register bank?

I've tried to mark up the program counter table for the 8273, but it's basically impossible to achieve any sort of accuracy at all with the muck on the current photo, so I don't think it's even worth bothering at this stage.

We'll have to hope Sean can flow us a cleaner one.

User avatar
Rich Talbot-Watkins
Posts: 1680
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by Rich Talbot-Watkins » Thu Sep 10, 2020 11:11 am

No, the unknown 2-bit ID remains unknown! At least in some cases it seems to be hardcoded according to the event which occurs (index pulse, parameter register write, etc); there also seems to be an opcode ($EE) which forces it to 2, along with a 4-bit index from the current selected register bank (opcodes $00...$0F). The register bank operates in blocks of 8, but only the first 3 bits are significant when accessing registers. In some opcodes, the bottom bit is also ignored!

As an aside, Chris and I both commented, upon seeing the 8273 ROM dump, that we realised we were able to disassemble it in our heads! :shock:

guesser
Posts: 493
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by guesser » Thu Sep 10, 2020 11:26 am

What are you calling the 2-bit id? The extra two inputs to the narrow ROM (jump table?), or the high two output bits?

I've not kept up with what names you're using for different parts sorry.
A web based teletext editor which can export as Mode 7 screen memory: https://zxnet.co.uk/teletext/editor
Join the Teletext Discord for teletext chat.

User avatar
Rich Talbot-Watkins
Posts: 1680
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by Rich Talbot-Watkins » Thu Sep 10, 2020 11:30 am

guesser wrote:
Thu Sep 10, 2020 11:26 am
What are you calling the 2-bit id? The extra two inputs to the narrow ROM (jump table?), or the high two output bits?

I've not kept up with what names you're using for different parts sorry.
The inputs to the narrow ROM are what I'm calling the 2-bit ID - the high two output bits are just the top two bits of the 10-bit output address; nothing remarkable about them as far as I know (unless you know differently!).

guesser
Posts: 493
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by guesser » Thu Sep 10, 2020 11:37 am

Rich Talbot-Watkins wrote:
Thu Sep 10, 2020 11:30 am
The inputs to the narrow ROM are what I'm calling the 2-bit ID - the high two output bits are just the top two bits of the 10-bit output address; nothing remarkable about them as far as I know (unless you know differently!).
That's what I thought, ta. So those extra two input bits should be explained by persisting with tracing out the decoding of the decode PLA thing.

Have you correlated your assumed opcodes back to the physical columns of the two blocks (or have I misunderstood where all that's come from)?
A web based teletext editor which can export as Mode 7 screen memory: https://zxnet.co.uk/teletext/editor
Join the Teletext Discord for teletext chat.

User avatar
Diminished
Posts: 580
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by Diminished » Thu Sep 10, 2020 11:44 am

Hey, guesser, you know the program counter table?

You seemed to read what turned out to be the program counter values out of the right-hand side of each cell, am I right?

What's on the left-hand side of each cell? Are they likely to be another set of PC values in there? I'm not sure why there would be values encoded in silicon there that aren't used for anything.

Have I misunderstood something?
(Yes)
Last edited by Diminished on Thu Sep 10, 2020 1:27 pm, edited 1 time in total.

User avatar
Rich Talbot-Watkins
Posts: 1680
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by Rich Talbot-Watkins » Thu Sep 10, 2020 11:46 am

guesser wrote:
Thu Sep 10, 2020 11:37 am
Have you correlated your assumed opcodes back to the physical columns of the two blocks (or have I misunderstood where all that's come from)?
Yes - in as much as we can determine the smallest blocks of opcodes which the PLA handles in the same way, and presume them to be small variants of the same thing.

For example, we can see that there's a signal which is fired for $0x, and nothing more specific than that, therefore all opcodes from $00...$0F must work in a largely identical way.

Meanwhile, there's a signal which fires for $FC...$FF, but also signals which fire uniquely for each of $FC, $FD, $FE and $FF; so we can assume that each one works distinctly, but that they also have a certain amount in common. In this case, they're all opcodes which set the program counter in some way.

User avatar
Rich Talbot-Watkins
Posts: 1680
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by Rich Talbot-Watkins » Thu Sep 10, 2020 11:50 am

Diminished wrote:
Thu Sep 10, 2020 11:44 am
What's on the left-hand side of each cell? Are they likely to be another set of PC values in there? I'm not sure why there would be values encoded in silicon there that aren't used for anything.
They are a 10 bit key, broken up as (2, 4, 4). There are three opcodes which build a key in certain distinct ways, and use it to look up a new address to jump to. The scheduler itself also jumps to these addresses when the processor yields or is asleep, based on a hardcoded (we think) key associated with each event type. Each event can be assigned a wake-up routine (opcodes $B8...$BF) which specifies the final 4-bit part of the key.

Perhaps that's not what you're talking about though.

User avatar
BigEd
Posts: 3591
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by BigEd » Thu Sep 10, 2020 12:06 pm

Brilliant progress, an excellent journey, and thanks for building some kind of narrative for it!

guesser
Posts: 493
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by guesser » Thu Sep 10, 2020 12:37 pm

Rich Talbot-Watkins wrote:
Thu Sep 10, 2020 11:46 am
Yes - in as much as we can determine the smallest blocks of opcodes which the PLA handles in the same way, and presume them to be small variants of the same thing.

For example, we can see that there's a signal which is fired for $0x, and nothing more specific than that, therefore all opcodes from $00...$0F must work in a largely identical way.
What I mean is, an opcode number means nothing to me looking at what output lines go where as each column just looks like a random number to me.
A web based teletext editor which can export as Mode 7 screen memory: https://zxnet.co.uk/teletext/editor
Join the Teletext Discord for teletext chat.

User avatar
Rich Talbot-Watkins
Posts: 1680
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by Rich Talbot-Watkins » Thu Sep 10, 2020 12:58 pm

The PLA just takes 16 inputs, 8 matching set opcode bits and 8 matching unset opcode bits. Each column represents some property or behaviour of a given opcode; most opcodes will fire more than one PLA column as they will share broad functionality with others, while specific behaviour will be due to a particular line firing which only matches a specific opcode pattern, with no or few "don't cares".

If you look at the PLA Dump in the document, you can see the inputs transcribed in a form which makes it easy to see how they match opcodes, "x"s for bits where we don't care. This allows us to easily determine the smallest ranges of values which must correspond to opcodes in a single family, and this has been invaluable in working out the opcode meanings.

The number of PLA columns is not related to the number of different instructions. These columns just represent particular aspects of an instruction, some of which may well be shared by many instruction types. We haven't looked at where these columns go, and we don't know their meanings - figuring out the actual meaning of each opcode has just been done by intuition up to now. But it's handy to be able to see that an instruction range we're pretty confident about shares a particular PLA line with another range of instructions, and thus is probably ALU related (or whatever).

User avatar
Diminished
Posts: 580
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by Diminished » Thu Sep 10, 2020 1:27 pm

Rich Talbot-Watkins wrote:
Thu Sep 10, 2020 11:50 am
Perhaps that's not what you're talking about though.
No, it wasn't, but it's OK ... I started typing up a post to explain what I meant, and in doing so I realised I'd misunderstood something (specifically, the don't-care combinations in the PC decoder input).

User avatar
Diminished
Posts: 580
Joined: Fri Dec 08, 2017 9:47 pm
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by Diminished » Thu Sep 10, 2020 2:40 pm

How do the registers work, Rich? I see a lot of MOV Ix type stuff, but then you have references to Rx in the comments.

What about the register banks? What's the dealio with those?

(I can wait for answers, just as long as someone writes this stuff up properly afterwards. :D)

guesser
Posts: 493
Joined: Mon Jun 26, 2006 10:21 pm
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by guesser » Thu Sep 10, 2020 5:06 pm

Rich Talbot-Watkins wrote:
Thu Sep 10, 2020 12:58 pm
If you look at the PLA Dump in the document, you can see the inputs transcribed in a form which makes it easy to see how they match opcodes, "x"s for bits where we don't care. This allows us to easily determine the smallest ranges of values which must correspond to opcodes in a single family, and this has been invaluable in working out the opcode meanings.
Oh yes I see, they're listed in order of the columns with the gaps for the gnd metal every 8 👍

I think the second one from the left table has an error. The bits are 0000xxxx, not 0001xxxx. The '0' select line folds around from underneath the next row of bits.
A web based teletext editor which can export as Mode 7 screen memory: https://zxnet.co.uk/teletext/editor
Join the Teletext Discord for teletext chat.

User avatar
Rich Talbot-Watkins
Posts: 1680
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: 8271 disc controller de-cap and craziness -- do not try this at home!

Post by Rich Talbot-Watkins » Thu Sep 10, 2020 5:15 pm

Diminished wrote:
Thu Sep 10, 2020 2:40 pm
How do the registers work, Rich? I see a lot of MOV Ix type stuff, but then you have references to Rx in the comments.

What about the register banks? What's the dealio with those?
So, we know there are 32 internal registers (we can see them in the photo!). But this is a lot to encode inside an opcode byte, so, instead, registers are accessed relative to a base register, which is set by specifying what we're calling a register bank.

Register banks are selected by opcodes $00...$0F. Each bank is 8 registers, so opcode $02 would suggest a base register of $10.

Let's look at opcodes $F0-$F7. They are two byte instructions which load their immediate operand into the register specified in the bottom 3 bits.

Code: Select all

00      SEL RB 0          ; select register bank 0
F3 22   MOV I3, #$22      ; load register $03 with $22
01      SEL RB 1          ; select register bank 1
F4 7F   MOV I4, #$7F      ; load register $0C with $7F
02      SEL RB 2          ; select register bank 2
F5 18   MOV I5, #$18      ; load register $15 with $18
Any of the register operations from $80 upwards work like this. The I2 syntax is just something we invented for the purposes of disassembly - the opcode can only reference a register index from I0...I7, but the actual register it touches will depend on the current register bank.

There is a big block of opcodes from $20-$7F which work a bit differently... they use the bottom 4 bits to specify the register, so they go from I0...IF. However they ignore the least significant bit of the register bank! In other words, if you have register bank 1 selected (base register $08), these instructions behave as if the base were still $00:

Code: Select all

00      SEL RB 0          ; select register bank 0
23      MOV I3, A         ; load register $03 with A
01      SEL RB 1          ; select register bank 1
24      MOV I4, A         ; load register $04 (not $0C) with A
2C      MOV IC, A         ; load register $0C with A
02      SEL RB 2          ; select register bank 2
25      MOV I5, A         ; load register $15 with A
Now I said there were 32 internal registers, but this is literally only half the story! Because if you select register bank 4 (a base of $20), you get access to I/O ports which are mapped to registers $20...$27 (and mirrored every 8...): this was not just an abstraction in the read/write special register command, but is actually presented like this at the MPU level. Not only are the drive control ports here, but the bit processor functionality is exposed here too, for performing the actual bit serialization tasks, all appearing like simple basic registers!

The register banks (opcodes $00...$0F) have a second, perhaps primary, use: they specify the 4 bit segment index used as part of the key which jumping to one of the preset entry points. We don't fully understand all the mechanisms which exist for this, but one which is well understood is the opcode $EE which jumps to the entry point keyed by (2, RB, *) where 2 is the 2-bit ID, RB is the 4-bit selected register bank, and * is a "don't care" in this case.

Since JMPs and CALLs are restricted to addresses within the current program counter page, the $EE mechanism is used liberally to call common routines which may not be in the current page.

Post Reply

Return to “8-bit acorn hardware”