Date   

Re: imaging/duplicating HP tape cartridges - lots of questions

Paul Berger
 

From what Ansgar wrote on his site http://www.hp9845.net/9845/hardware/processors/  it does replace the discrete logic controller used in the 9825 and more.  It seems likely that it is more autonomous than the controller on the 9825, able to do some functions on its own.  There is a patent document for the 9845A but I don't know if it gets into the tape drive operation.  The 9835 and 9845 use TACO chips for the tape drive controller.   

Paul.


On 2017-02-20 3:00 PM, Craig Ruff wrote:

On Feb 20, 2017, at 10:50 AM, Paul Berger <phb.hfx@...> wrote:

You could talk directly to it by replacing the processor card or writing custom code for the processor in it  (BPC only version of the processor in 9825), but it would probably take some probing to discover how to talk to the TACO.

I wonder if the TACO chip is an enhanced version of the tape controller in the 9825.  The comments in the 9825 tape firmware listing led me to think some portion of the code might be shared with the 9875, in particular the portion known as the “Tape Driver” that resides in the ROM at 020000.  The 9825 FW keeps track of tachometer pulses to know how far  it has moved the tape, and does the data stream bit serialization/deserialization operations in FW.  It also manages the two levels of the read threshold to check if data will be likely to be read back correctly.


Re: imaging/duplicating HP tape cartridges - lots of questions

 


On Feb 20, 2017, at 10:50 AM, Paul Berger <phb.hfx@...> wrote:

You could talk directly to it by replacing the processor card or writing custom code for the processor in it  (BPC only version of the processor in 9825), but it would probably take some probing to discover how to talk to the TACO.

I wonder if the TACO chip is an enhanced version of the tape controller in the 9825.  The comments in the 9825 tape firmware listing led me to think some portion of the code might be shared with the 9875, in particular the portion known as the “Tape Driver” that resides in the ROM at 020000.  The 9825 FW keeps track of tachometer pulses to know how far  it has moved the tape, and does the data stream bit serialization/deserialization operations in FW.  It also manages the two levels of the read threshold to check if data will be likely to be read back correctly.


Re: imaging/duplicating HP tape cartridges - lots of questions

Paul Berger
 

The HP-IB command set for the drive is documented in the users manual so I would guess in theory you could use it to just read blocks of data from the tape, but I suspect that if the tape is physically damaged, such as when the drive band peels off some oxide you would not be able to read them.  It does say it supports SIF format and I think that is the format that 9825 uses.  The 9875 uses a  TACO to drive the tape drives, but since the TACO chip manages a number of the low level functions on its own, I suspect that it too would have problems with damaged tapes.  You could talk directly to it by replacing the processor card or writing custom code for the processor in it  (BPC only version of the processor in 9825), but it would probably take some probing to discover how to talk to the TACO.  For damaged tapes the best would probably be to talk directly to the drive and just capture the bit stream.  There is a good description of the SIF tape format in the 9875 users guide.  From what I can see in the manuals the drive units in the 9875 are the same as the ones in 9825/35/45.  There seems to be two versions of these drives, one that uses incandescent bulbs for light source for sensor and on that uses IR LEDs, the drives in both my 9825T and 9835A use the IR LEDs.   

Paul.
   

On 2017-02-20 12:58 PM, Jack Rubin wrote:

For archival imaging, no need, at least initially, to do anything with the bit stream other than to capture it. At that point, either one could attempt to read the image itself or else write it back to another tape, hopefully allowing the creation of a new generation of system tapes.

What would be the "best" FACT drive to use from the standpoint of reliability and ease of control?

Does any other machine that uses these cartridges have a richer command set that allows full tape duplication? Does the 9875 dual drive allow this?

Jack



Re: imaging/duplicating HP tape cartridges - lots of questions

Ansgar
 

Guess the 9875 uses the TACO tape controller chip, just like the 9845. The chip itself is a great mystery, since sparsely documented (the most comprehensive description I think can be found the the 64940-90905 docs for the 64k tape system). However, I assume in theory it should be capable to be programmed to read & write the tapes on flux reversal level (including random gap lengths).

These are many assumptions, I know, but F.Ulivi has implemented the TACO chip for emulation, which gave us some more findings on it, although still being far from having a complete understanding. The analysis by the way also showed that the 9845 tapes are in fact SIF-tapes, where the full file system is stored into one single, large SIF file with record size of 256 bytes. Consequently, with the SIF utilities for the 9845 you also have access to SIF tapes (on file base, not for reading the low level data).

As a summary, it should be theoretically possible to process any DC100 tape with a device equipped with a TACO chip. Probably except (here it comes) Series 80 tapes. I have a strong feeling that the Series 80 (not equipped with TACO by the way) uses different writing currents and/or read sensitivity, although I did not check them yet (no Series 80 tape drive at hand). I tried to use the tapes from Athana (which are new replacements for DC100 for use in Series 80 computers) with a 9845 and got negative results, but they seem to work in a Series 80.

-Ansgar


Re: imaging/duplicating HP tape cartridges - lots of questions

Jack Rubin
 

For archival imaging, no need, at least initially, to do anything with the bit stream other than to capture it. At that point, either one could attempt to read the image itself or else write it back to another tape, hopefully allowing the creation of a new generation of system tapes.

What would be the "best" FACT drive to use from the standpoint of reliability and ease of control?

Does any other machine that uses these cartridges have a richer command set that allows full tape duplication? Does the 9875 dual drive allow this?

Jack


Re: imaging/duplicating HP tape cartridges - lots of questions

 

About the reverse quick approach, a QIC40 drive uses 20 tracks of data. The DC100 uses 2 tracks, the update is a mechanical adaption to the dimensions of the QIC40 cartridge and an increase of the write current to write to the media. QIC40 and DC100 don’t share any track and modulation configuration.

I’m not sure but I think it’s practically impossible to read a DC100 tape on a QIC40/80 drive.

But it should be possible to connect a DC100 HP FACT drive to something like a Arduino or other micro controller, and read the data as a stream. And so neglecting any error signals generated by missing layers etc…

The program should be something like: rewind to the begin, start slow forward and read everything it says, stop at end of tape.

The next thing would be more complicated because you will have to analyze the captured data with a smart written piece of software.

 

-Rik

 

 

 

Van: VintHPcom@groups.io [mailto:VintHPcom@groups.io] Namens Jack Rubin
Verzonden: maandag 20 februari 2017 16:39
Aan: VintHPcom@groups.io
Onderwerp: [VintHPcom] imaging/duplicating HP tape cartridges - lots of questions

 

Today I found another HP-85 tape of interest - "5010-0567/2630 - CS80 HP85 DIAG TAPE". It is labeled as being in SIF format and part of the HP85 Service System. Again, the existing archived copy consists of a disk image of the tape files which is incomplete and partially corrupted.

I'm still suffering a bit of dis-belief about the problems of imaging these tapes. Setting aside the issues of physically reading the tapes, from what I've seen, tapes have been recovered by copying files to disk which somehow fails to capture some binary system data. Tapes are then "duplicated" by then copying these files from disk back to tape, resulting in incomplete copies.

Hopefully, I'm not truly understanding the process and we do have the ability to do a raw block copy from tape to image and back.

Does anyone know how the "COPY ALL"  tape-to-tape function works on the 2644 terminal? 

Has anyone tried a "reverse QIC" approach? If the 9825/85 "DC100" tape drives can be re-engineered to read QIC-40 tapes, can a QIC-40 drive read an HP tape? If that's the case, then it is a short step to using ftape and dd to start tape imaging.

Jack


Re: imaging/duplicating HP tape cartridges - lots of questions

 


On Feb 20, 2017, at 8:39 AM, Jack Rubin <j@...> wrote:

Tapes are then "duplicated" by then copying these files from disk back to tape, resulting in incomplete copies.

The standard 9825 tape firmware provides no commands to write binary programs back to tape.  Hence the incomplete tape images.


imaging/duplicating HP tape cartridges - lots of questions

Jack Rubin
 

Today I found another HP-85 tape of interest - "5010-0567/2630 - CS80 HP85 DIAG TAPE". It is labeled as being in SIF format and part of the HP85 Service System. Again, the existing archived copy consists of a disk image of the tape files which is incomplete and partially corrupted.

I'm still suffering a bit of dis-belief about the problems of imaging these tapes. Setting aside the issues of physically reading the tapes, from what I've seen, tapes have been recovered by copying files to disk which somehow fails to capture some binary system data. Tapes are then "duplicated" by then copying these files from disk back to tape, resulting in incomplete copies.

Hopefully, I'm not truly understanding the process and we do have the ability to do a raw block copy from tape to image and back.

Does anyone know how the "COPY ALL"  tape-to-tape function works on the 2644 terminal? 

Has anyone tried a "reverse QIC" approach? If the 9825/85 "DC100" tape drives can be re-engineered to read QIC-40 tapes, can a QIC-40 drive read an HP tape? If that's the case, then it is a short step to using ftape and dd to start tape imaging.

Jack


Re: HP Integral PC

Martin Hepperle
 

Rik and David,

thank you for your support. Give me a few days to test the "new" image files and compare with what I have. Maybe I made a mistake or my hardware is ill suited. I hope to come up with a consolidated set of files, I will feed that back to the community. I am working on a 9133L HPDRIVE image with all relevant files already installed.

In the meantime I tested all my copies created with Teledisk and found a few more broken disks:

- Mandel(brot programs)
- FORTRAN Utilities (compiler disk is fine)
- MULTIPLAN
- LISP and PLOT (sic, should be PILOT)
- Diagraph Program (Symbols disk reads fine)


There might also be some differences between the two HP-UX ROM versions (III and V) which were available and it might be that some software works only with a certain ROM version - not sure. My machien has the System V ROMs.

I will be on a business trip for the next 2 weeks so it will take 3 weeks until I have a more complete picture.

Martin


Re: HP Integral PC

David Collins
 

I'm happy to fix the files on the HP museum site if you can send me good ones...

David Collins
Curator
HP Computer Museum


On 17 Feb 2017, at 9:06 am, Rik Bos <hp-fix@...> wrote:

Martin,

 

I’ve uploaded some Integral disks from another source.

You can recreate the images with rawwrite the win version is in the same directory.

I’ve checked the Cpp and basic disks and they seem to be oke.

 

-Rik

 

Van: VintHPcom@groups.io [mailto:VintHPcom@groups.io] Namens Martin Hepperle
Verzonden: woensdag 15 februari 2017 17:43
Aan: VintHPcom@groups.io
Onderwerp: Re: [VintHPcom] HP Integral PC

 

Rik,

thanks for the offer - right now I acquired a 1MB board and will test this first before proceeding to populate the 512KB board.

However I came across another problem with some of the TD0 disk images on the HP-Museum web site. Some of the orginal TD0 files downloaded from there did not produce a working disk image.

If I insert these disks into my Integral it shows an empty directoy - no files visible. I tried different disks and rewrote the same disks a few times - without success.


Using the TD02HPI tool chain from Ansgar Kückes I have produced LIF image files from these TD0 files. I then used them with HPDRIVE. However these files also have some errors. Some files were readable, some not. Therefore I assume that the original TD0 image files are partially corrupt.

So: has anyone here created disks from the three TD0 files listed below? All other files which I had created so far (about 15( work fine.

Possibly corrupted disks:

  • IPC BASIC
  • IPC BASIC Bonus disk
  • C Preprocessor

 

IPC BASIC Bonus disk

- completely unreadable

IPC BASIC disk
defective files:
   README
   hpgl.data
   load_rt

C Preprocessor disk
defective files:
   cc
   copyhard
   cpp
   rm
   size
   strip

C Documentation on Preprocesor disk
man3/
   putc
   regex
   setbuf
   setjmp
man2/
   shmap
   signal
   stat

 


Re: HP Integral PC

 

Martin,

 

I’ve uploaded some Integral disks from another source.

You can recreate the images with rawwrite the win version is in the same directory.

I’ve checked the Cpp and basic disks and they seem to be oke.

 

-Rik

 

Van: VintHPcom@groups.io [mailto:VintHPcom@groups.io] Namens Martin Hepperle
Verzonden: woensdag 15 februari 2017 17:43
Aan: VintHPcom@groups.io
Onderwerp: Re: [VintHPcom] HP Integral PC

 

Rik,

thanks for the offer - right now I acquired a 1MB board and will test this first before proceeding to populate the 512KB board.

However I came across another problem with some of the TD0 disk images on the HP-Museum web site. Some of the orginal TD0 files downloaded from there did not produce a working disk image.

If I insert these disks into my Integral it shows an empty directoy - no files visible. I tried different disks and rewrote the same disks a few times - without success.


Using the TD02HPI tool chain from Ansgar Kückes I have produced LIF image files from these TD0 files. I then used them with HPDRIVE. However these files also have some errors. Some files were readable, some not. Therefore I assume that the original TD0 image files are partially corrupt.

So: has anyone here created disks from the three TD0 files listed below? All other files which I had created so far (about 15( work fine.

Possibly corrupted disks:

  • IPC BASIC
  • IPC BASIC Bonus disk
  • C Preprocessor

 

IPC BASIC Bonus disk

- completely unreadable

IPC BASIC disk
defective files:
   README
   hpgl.data
   load_rt

C Preprocessor disk
defective files:
   cc
   copyhard
   cpp
   rm
   size
   strip

C Documentation on Preprocesor disk
man3/
   putc
   regex
   setbuf
   setjmp
man2/
   shmap
   signal
   stat

 


New file uploaded to VintHPcom@groups.io

VintHPcom@groups.io Notification <VintHPcom+notification@...>
 

Hello,

This email message is a notification to let you know that a file has been uploaded to the Files area of the VintHPcom@groups.io group.

File: IMG.rar

Uploaded By: Rik Bos

Description:
Integral software (Imagedisk images) Basic, C, Utils, Software development rom etc...

You can access this file at the URL:
https://groups.io/g/VintHPcom/files/Intergral%20Software/IMG.rar

Cheers,
The Groups.io Team


Re: HP Integral PC

Martin Hepperle
 

Rik,

thanks for the offer - right now I acquired a 1MB board and will test this first before proceeding to populate the 512KB board.

However I came across another problem with some of the TD0 disk images on the HP-Museum web site. Some of the orginal TD0 files downloaded from there did not produce a working disk image.

If I insert these disks into my Integral it shows an empty directoy - no files visible. I tried different disks and rewrote the same disks a few times - without success.


Using the TD02HPI tool chain from Ansgar Kückes I have produced LIF image files from these TD0 files. I then used them with HPDRIVE. However these files also have some errors. Some files were readable, some not. Therefore I assume that the original TD0 image files are partially corrupt.

So: has anyone here created disks from the three TD0 files listed below? All other files which I had created so far (about 15( work fine.

Possibly corrupted disks:

  • IPC BASIC
  • IPC BASIC Bonus disk
  • C Preprocessor


IPC BASIC Bonus disk

- completely unreadable

IPC BASIC disk
defective files:
   README
   hpgl.data
   load_rt

C Preprocessor disk
defective files:
   cc
   copyhard
   cpp
   rm
   size
   strip

C Documentation on Preprocesor disk
man3/
   putc
   regex
   setbuf
   setjmp
man2/
   shmap
   signal
   stat



Figured out the unknown 9825T instructions

 

Thanks to a suggestion by Tony Duell, I determined the unknown instructions are handled by the A25 board mapping circuitry.  Instructions with the bit pattern 0701xx trigger a write to a control register that does some “magic”.  They are a NOP as far as the 9825 CPU components are concerned.  When the instruction is seen, it latches the state of the low 4 bits of the MAD bus into A25 register U42, which in turn determines the state of the /ForceRAM (bit 3), /ForceROM (bit 2), /DiagRd (bit 1) and ALLROM (bit 0) signals.  Note that if you are following along on Tony’s schematics, the MAD bus is a negative logic bus, so a 1 bit in the instruction encoding will end up as a 0 bit in the register.

The upshot is that instruction 070113 causes the /ForceROM instruction to be asserted, ensuring that the copy of the data from the banked ROM into low RAM works as expected.  The 070117 instruction restores the normal state of the address mapping circuitry.

This gives me a strong indication that the disassembly of the 98228A ROM is proceeding correctly.  Installing a 98228A in a non-T machine will just display an error message and hang the system until it is powered off and the ROM is removed.


Re: Using VGA TFT monitors on HP 9000/300 series

Paul Berger
 

I have an NEC EA192-M when I got it I had initially tried it with a 1024x768 98545A card and was disappointed to find it would not sync giving an out of range message.  The native resolution of this monitor 1280x1024 so today I decided to try it with the   1280x1024 A1416A card an was very happy to find that it synced and looks nice.  I did have to adjust the position a little but other than that it works great.

Paul.

On 2017-02-06 4:32 PM, Ansgar wrote:

I currently use a NEC 1770NX (the "NX" is important!) and am quite satisfied. Not every monitor with sync-on-green works well, this one does (and looks damn good). I guess for proper operation the horizontal sync capabilities are essential. Jon from hpmuseum once said (and it is still on his web site) that the  NEC LCD1800, LCD1810, LCD2010 and LCD1830 are good replacements for the higher resolution HP monitors, but I personally like the more compact 17" and especially the more decent 1770NX. The NEC starts hsync at ~30 kHz (original VGA timing). The low res monochrome video boards, however, provide a 15 kHz hsync, which is supported only by some LCDs with composite video input. My DELL for example has that kind of input, but still does not detect the output from the low res HP 300 monochrome boards, So I am glad I still have my 82913A at hand.

I also tried with an LM1881 sync splitter, but it cannot replace a true sync-on-green input circuit (the LM1881 does not correct the wrong black level, or shall I say dark-green-level...).



Re: 98228A bank register

Paul Berger
 

Yes it latches on the falling edge of ALE which means it is actually latching the lower 3 bits of the address, but what I observed on the logic analyzer was address and data where the same.

Paul.

On 2017-02-12 10:54 AM, Craig Ruff wrote:
Just to make sure I don’t go off on a tangent, the bank register is latching the low order 3 bits of the address used to address the register at the falling edge of ALE, and not the data value written later on in the data transfer phase of the write cycle?


98228A bank register

 

Just to make sure I don’t go off on a tangent, the bank register is latching the low order 3 bits of the address used to address the register at the falling edge of ALE, and not the data value written later on in the data transfer phase of the write cycle?


Re: 9825 disassembly status

 


On Feb 11, 2017, at 8:28 PM, Paul Berger <phb.hfx@...> wrote:

I can send it to you if you are interested  , it is about 35MB in size.

Sure, that would be great.  The 16 bit image and the 8 bit images are consistent for address 030313, I expect the other “invalid” instruction location is too.  The value being placed into A at 030270 looks odd too.  Is it possible some other page of the ROM gets mapped to 054000 (0x5800)?  It may be the instruction trace can shed some light on the issue.


Re: 9825 disassembly status

Paul Berger
 

Craig,

I can assure you that those instructions get executed and the 9825 does not blow up, I just cranked up my 16700B to check if I had saved any execution traces and there is one, it contains a little over 685,000 state captures, I do not know what commend it is a trace of any more, but it is not one of the data file functions as it does not touch the address where I found the defective bit.  I can send it to you if you are interested  , it is about 35MB in size.

Paul.



On 2017-02-11 7:18 PM, Craig Ruff wrote:

On Feb 11, 2017, at 4:00 PM, Paul Berger <phb.hfx@...> wrote:

You understand that there are two 1K word windows into the  ROM and the bank selection is done by write to the area occupied by the base page ROM, I think my writeup included with the package gives a good description of how it works.

Yes.  At the moment, I’m looking at the code in bank 0 that appears to be associated with bank selection of the other banks.  There are two instructions that my disassembler flagged as invalid bit patterns.  They are at (octal) word addresses 30272 (pattern 070113) and 30313 (pattern 070117).  These do not match any instructions described in the 9825A patent, nor in the 9835 Assembly Language manual (the 9835 CPU is a superset of the 9825 CPU).  The instruction at 30272 happens immediately after a dir (disable interrupts) instruction, and the one at 30313 immediately before an eir (enable interrupts) instruction.  The rest of the code in this sequence copies blocks of 16 words from one location to another, I have not yet determined what this data is.

These apparently invalid instruction bit patterns do not occur as instructions in the entire contents of the other 9825T ROMs.  I have not yet looked at the contents of banks 2-7, nor do I have tentative labels or definitions for base page temporary locations being used.

Notes about the disassembler output.  

The second column are word attribute tags derived from the disassembly process.  The ‘r’ indicates ROM, ‘i’ the word is considered to be an instruction, ‘c’ means a conditional jump, ‘u’ means unconditional jump.

Symbols in the operand column surrounded by braces on a line following an instruction are alternative names known for the operand location.  They may or not apply semantically to that specific instruction.  For example, at 30273, the operand address is the decimal 152 constant in the base page rom.  It is also known, via an equate as b230 (octal 0230).

30256 ri   004177  selbank?  ldb  p0          ; perform pre bank select stuff?
                                  {kpa,dpa,ppa,zero} 
30257 ri   035742            stb  op1       
                                  {tvar3,op1e} 
30260 ri   004177            ldb  p0        
                                  {kpa,dpa,ppa,zero} 
30261 ri   035767            stb  77767     
30262 ri   004077            ldb  p58       
                                  {b72,colln} 
30263 ri   025044            adb  stolendsk 
30264 ri   035763            stb  77763       ; save address stolen+58
30265 ric  011335            cpa  77335     
30266 riu  067315            jmp  selbnkjmp   ; bank already selected?
30267 ri   031335            sta  77335     
30270 ri   022676            ada  31676       ; «(31676) = 055750»
30271 ri   070430            dir            
30272 ri   070113            INVALID              ; «Unknown instruction, load something into A?, something else entirely?»
30273 ri   030047            sta  p152        ; «write to 0230, select bank 0? Is this an argument word?»
                                  {b230} 
30274 ri   104000            ldb  a,i       
30275 ri   174510            sbr  9         
30276 ri   035762            stb  77762     
30277 ri   104000            ldb  a,i       
30300 ri   174606            sbl  7         
30301 ri   174506            sbr  7         
30302 ric  044000            isz  a         
30303 ri   100000            lda  a,i       
30304 ri   134001            stb  b,i       
30305 ri   005763            ldb  77763     
30306 ri   071417            xfr  16        
30307 ri   020127            ada  p16       
                                  {adr2,b20,ar2a,d16} 
30310 ri   024127            adb  p16       
                                  {adr2,b20,ar2a,d16} 
30311 ric  055762            dsz  77762     
30312 riu  067306            jmp  *-4       
30313 ri   070117            INVALID              ; «Unknown instruction, store A into something?»
30314 ri   070420            eir
30315 ri   030041  selbnkjmp  sta  00041       ; select bank (1)? and jump to code at 077763?
30316 riu  165763            jmp  77763,i



Re: 9825 disassembly status

 


On Feb 11, 2017, at 4:00 PM, Paul Berger <phb.hfx@...> wrote:

You understand that there are two 1K word windows into the  ROM and the bank selection is done by write to the area occupied by the base page ROM, I think my writeup included with the package gives a good description of how it works.

Yes.  At the moment, I’m looking at the code in bank 0 that appears to be associated with bank selection of the other banks.  There are two instructions that my disassembler flagged as invalid bit patterns.  They are at (octal) word addresses 30272 (pattern 070113) and 30313 (pattern 070117).  These do not match any instructions described in the 9825A patent, nor in the 9835 Assembly Language manual (the 9835 CPU is a superset of the 9825 CPU).  The instruction at 30272 happens immediately after a dir (disable interrupts) instruction, and the one at 30313 immediately before an eir (enable interrupts) instruction.  The rest of the code in this sequence copies blocks of 16 words from one location to another, I have not yet determined what this data is.

These apparently invalid instruction bit patterns do not occur as instructions in the entire contents of the other 9825T ROMs.  I have not yet looked at the contents of banks 2-7, nor do I have tentative labels or definitions for base page temporary locations being used.

Notes about the disassembler output.  

The second column are word attribute tags derived from the disassembly process.  The ‘r’ indicates ROM, ‘i’ the word is considered to be an instruction, ‘c’ means a conditional jump, ‘u’ means unconditional jump.

Symbols in the operand column surrounded by braces on a line following an instruction are alternative names known for the operand location.  They may or not apply semantically to that specific instruction.  For example, at 30273, the operand address is the decimal 152 constant in the base page rom.  It is also known, via an equate as b230 (octal 0230).

30256 ri   004177  selbank?  ldb  p0          ; perform pre bank select stuff?
                                  {kpa,dpa,ppa,zero} 
30257 ri   035742            stb  op1       
                                  {tvar3,op1e} 
30260 ri   004177            ldb  p0        
                                  {kpa,dpa,ppa,zero} 
30261 ri   035767            stb  77767     
30262 ri   004077            ldb  p58       
                                  {b72,colln} 
30263 ri   025044            adb  stolendsk 
30264 ri   035763            stb  77763       ; save address stolen+58
30265 ric  011335            cpa  77335     
30266 riu  067315            jmp  selbnkjmp   ; bank already selected?
30267 ri   031335            sta  77335     
30270 ri   022676            ada  31676       ; «(31676) = 055750»
30271 ri   070430            dir            
30272 ri   070113            INVALID              ; «Unknown instruction, load something into A?, something else entirely?»
30273 ri   030047            sta  p152        ; «write to 0230, select bank 0? Is this an argument word?»
                                  {b230} 
30274 ri   104000            ldb  a,i       
30275 ri   174510            sbr  9         
30276 ri   035762            stb  77762     
30277 ri   104000            ldb  a,i       
30300 ri   174606            sbl  7         
30301 ri   174506            sbr  7         
30302 ric  044000            isz  a         
30303 ri   100000            lda  a,i       
30304 ri   134001            stb  b,i       
30305 ri   005763            ldb  77763     
30306 ri   071417            xfr  16        
30307 ri   020127            ada  p16       
                                  {adr2,b20,ar2a,d16} 
30310 ri   024127            adb  p16       
                                  {adr2,b20,ar2a,d16} 
30311 ric  055762            dsz  77762     
30312 riu  067306            jmp  *-4       
30313 ri   070117            INVALID              ; «Unknown instruction, store A into something?»
30314 ri   070420            eir
30315 ri   030041  selbnkjmp  sta  00041       ; select bank (1)? and jump to code at 077763?
30316 riu  165763            jmp  77763,i

8221 - 8240 of 8330