• Please review our updated Terms and Rules here

Mitra 125

I rather doubt that the PDF file itself is actually corrupted, although there is definitely nothing on the latter part of page 14.

Given that the PDF appears to be a scan of a tractor-feed printout, it's almost as though the computer simply didn't output anything but a carriage return (CR) or a new line (NL) for the latter half of the page. Alternatively, the printer might have stopped for some other reason (out of ink?) and there are missing pages. Other possibilities include the operator (user) having explicitly dumped the meaningful regions and avoided printing out a region full of 00h (0) or FFh (255) byte values.

-----

The attached zip contains just a single bin file created with HxD by typing in the hexadecimal code from the first page of the monitor dump PDF (I used PDFSAM to split the original document into separate 1 page PDF files).
^ 0000h - 03C0h

Given you may have done that part already, is there a specific part that you need done?

-----

I've also attached a PNG file (image) created by:

- opening the first page of the monitor dump PDF in SumatraPDF
- copying the image
- pasting it into Paint.NET
- adjusting the black-white levels

The resulting image is pretty faint (like a dot-matrix print out with a dry ribbon), but there is no mistaking 'B' for an '8'.
 

Attachments

  • mitra15_monitor.zip
    mitra15_monitor.zip
    808 bytes · Views: 2
  • mitra15-monitor-dump_page1.png
    mitra15-monitor-dump_page1.png
    3.9 MB · Views: 14
Last edited:
The Mitra-15 has no stack pointer like many computers of the 1970', so each interruption save the context in a specific place and when the flow of instructions returns at the end of interruption processing, it restores the older context
Click to expand...

Complete and utter tangent, but:

The Motorola 6502 technically has a stack pointer, but the stack is of a fixed size and cannot be moved (256 bytes, 0x100-0x1FF). Other aspects of the design require that care be exercised (by the programmer) to not overflow the stack.

Not only that, but a significant share of assembly language programs for the 6502 rely on the zero page (256 bytes, 0x00 to 0xFF) to make up for the very limited number of hardware registers.

The Texas Instruments TMS 9900 has no stack pointer at all, but instead a Workspace Pointer (WP) that points to a set of 16-bit memory words which serves in place of any general purpose hardware registers.
 
see attached files (page 2)

EDIT: I have also included a separate zipped binary that includes both page 1 and page2.

I do hope there aren't any errors, given that I have double or triple checked each line against the original document.
 

Attachments

Last edited:
see attached files (page 3)

I have also included a separate zipped binary that includes both pages 1, 2, and 3 (mitra15_monitor_current.zip)

P.S.

Don't have the patience to keep going tonight, will get back to this later.
 

Attachments

Thank you @Istarian! It's a lot of work!
I guess I have not enough time currently to test my simulator against your binary files but it's incredibly useful.
 
No rush. I still have another ~12 pages to go...

It's all just numbers to me, anyway, at this point. My knowledge of this machine is miniscule and I don't know anything about it's machine code / assembly language.

As it stands I think you would need a way to drop all of this into the simulator/emulator's memory, and jump to the correct entry point...
 
Istarian said:
Do you know enough about the binary executable format/layout to try and dissasemble it?
Click to expand...
I will give it a try today, there is already a usable but not fully tested disassembler in mitra_sys.c and from the user manual the memory is organized in three areas (which may explain the missing dump between 0x33C0 and 0x7C00:
Following the MTR specification, the memory is organized as follows:
* **Zone Moniteur (Resident Kernel):** Starts at absolute address 0.
* **Zone Background:** Reserved for level-0 user programs (probably between 0x33C0 and 0x7C00).
* **Zone Commune:** Used for communication between the OS and user tasks.

I found a thesis in French that provides a lot of information. It says that the initial boot program starts at 0x00.
Here is a translation for launching an internal bootstrapping program from the front panel, with a secondary bootstrap from the paper tape reader of the system teletype (ASR 33):

The microprogram associated with the control panel enables an initial load into main memory via the INI command (bootstrap function).
The INI function initiates the reading of a 256-byte block from a microprogrammed bootstrap for the system ASR 33, selected during the INI command by the position of the control panel switches, and loads it into memory starting at address 0.
Once loading is complete, the "Program Run" button is pressed to enable interrupt processing, allowing the loaded microprogram to handle the "transfer complete" interrupt from the addressed peripheral.
ASR 33 bootstrap program initialization proceeds as follows:
- reading the front panel switches (LD 20).
- verifying that the switches are set to 0.
- switching to register block 1 (the registers associated with the ASR 33 microprogram being 9, 10, and 11). There are 8 blocks of 8 registers for fast context switching.
- initializing the byte count in fast register 9 to 256 (&100).
- resetting the current interrupt register (R8) and the byte address register (R10).
- switching to the program block by setting R12 (fast interrupt processing register) to 0.
- logically complementing R10 (i.e., &FFFF XOR R10); this yields the address -1 relative to the first byte to be stored in main memory.
- issuing the ASR 33 tape read command (without printing), &A3, via an ED 01 instruction.
- entering a wait loop while monitoring the control panel interrupt status (switching to "Program Run" clears the control panel suspension, enabling interrupt processing). After the 128 words have been loaded from the ASR 33, an "end-of-transfer" interrupt is generated; this interrupt must be serviced regardless of the ASR 33's interrupt level. To ensure this, the CPT table contains the same address—at all levels—for the context responsible for taking control.
This bootstrap must now load the remainder of the program, which is located—for instance—further along on the same tape (i.e., also read from the ASR 33).
The bootstrap then places the typewriter in an idle state and modifies the address location containing the CPT address; this ensures that the interrupt generated upon completion of the rest of the tape loading will launch the newly loaded program, regardless of the ASR 33 interrupt number.
The ASR 33 interrupt is disabled, registers R9 and R10 are initialized to read the remainder of the tape, and the tape reading process is started.
The MITRA runs at level zero, executing a `BRU *` instruction while waiting for the "end-of-loading" interrupt that launches the program.
 
Last edited:
A probably buggy Mitra-15 disassembler is available at:

github.com

Mitra-15-for-SIMH/Disassembler at main · JPLeRouzic/Mitra-15-for-SIMH

An attempt at creating a branch for Mitra-15 in SIMH. Work in progress. - JPLeRouzic/Mitra-15-for-SIMH
github.com github.com

I have only tested on a few instructions, a snippet from Pascal Chour disassembled code which is a good reference as there was a disassembler in CII's software.

More tests later. The code was written on Devuan, a Debian derivative so on Windows there are probably some modifications needed to compile it.
 
I've written a very simple python script to reproduce the "text interpretation" column from the listing. When I'm finished cleaning it up I'll share it on here. Now if only the Windows command prompt had a more pleasant font.

see the attached file for example output

This is what the main function looks like:

Python: 
def main(): 
    with open("mitra15_monitor_p1.bin", "rb") as myfile:
        dlen = 0
        lst = []
      
        done = False
      
        while not done:
            data = myfile.read(16)
          
            dlen = len(data)
          
            if len(data) > 0:
                # print(len(data))
              
                for byteVal in data:
                    chardec = decode(byteVal)
                    lst.append(chardec)
              
                res = "".join(lst)
              
                print( f"{dlen} [{res}]" )
              
                lst.clear()
            else:
                print('No more data.\r\n')
              
                done = True

Essential it just opens the file in read binary (rb) mode, reads 16 bytes at a time, feeds each of the read bytes into a decode functions (which spits out either an ASCII character or just a space) and then prints them as a string.
 

Attachments

Last edited:
Many thanks @Istarian,
I tried to find the boot entry which is normally at address 0, but I can't find it.
The boot entry may be starting with something like this:
44yy LEA DG yy (COMMON DATA SECTION)
(some instructions)
04yy LEA DL yy (LOCAL DATA SEGMENT)

But they may have use other instructions...
 
Is that an absolute address of 0 (like 0000H) that corresponds to a fixed memory region or is it relative?

Do "boot entries" apply to all executable binary data or just code that's specifically loaded from paper tape or other media (like a floppy disk)?

What would be the 'normal' way to bootstrap/boot this machine?

NOTE: I will need to re-read what you were saying in post #50, because it wasn't really clicking last time...

Anyway, I strongly suspect that what we're looking at in this "dump" is just a straight dump of a 32K (0000H to 7FFFH) region from some part of memory (RAM or ROM). -- But I don't know if those addresses are absolute/relative.

PS

Is there any significance to the highlighted parts of page 1?

PPS

Just so you know, I can read some French as long as it's not too complex and the words are familiar (inside my vocabulary). And I can probably pronounce other stuff passably even if I haven't the faintest clue of what it means. (Courtesy of a painfully immersive college class in conversational french that was too early in the morning and I barely passed. Well that and some singing in church and elsewhere of songs)

For everything else there is Google translate. :P
 
Last edited:
> Is that an absolute address of 0 (like 0000H) that corresponds to a fixed memory region or is it relative?
I recall having read that but my memory may have failed me. I tried to look at the documentation again but what I find is:
- At reset or power on, all circuits are resetted.
- The operator enters a key sequence on the panel to determine from which device the CPU will boot. It may be the card reader, one of the disks (DRI or Sagem), magnetic tape, etc. This INI function initiates the reading of a 256-byte block from a microprogrammed bootstrap for the selected device, and loads it into memory starting at address 0.
- Then the operator push the button "MAR" to launch this 256-byte bootstrap.
So I guess the CPU at reset reads instructions from address 0, but that does not mean that a memory dump made under the MTR (an OS in modern parlance) reflects the content of memory during the first stage of bootstrap.

So I have to rewrite my cpu_reset() function in order to better simulate the startup process.

> Anyway, I strongly suspect that what we're looking at in this "dump" is just a straight dump of a 32K (0000H to 7FFFH) region from some part of memory (RAM or ROM). -- But I don't know if those addresses are absolute/relative.
Yes we might not look at the bootstrap code, it might be like a dump of a modern OS: It does not inform how the machine booted or what code there was in the primary or secondary bootstrap.

> Is there any significance to the highlighted parts of page 1?
Good catch, I tried to disassemble a few bytes but it does not make sense.

When you will have completed the scan, and if we can't make sense of the dump maybe we could ask to Claude to read the dump and the MTR manual and tell us how to use this dump.
 
jplr said:
When you will have completed the scan, and if we can't make sense of the dump maybe we could ask to Claude to read the dump and the MTR manual and tell us how to use this dump
Click to expand...

I'd honestly rather just read the MTR manual myself, even if I have to translate the whole darn thing one line at a time with assistance. (Google Translate, a French/English dictionary, etc).

Of course, I could just try to make sense of the French as is, but it isn't my native language nor am I fluent. And I'd rather print it out than squint at a PDF on my phone or even look at it on a PC (better, but still not quite natural).

No love for or trust of "AI" over here, even if it does seem do an okay job of putting together information from multiple sources.

At the end of the day, actually reading it through will lead to real human comprehension and not having to trust a computer-based black box to get it right.

-----

From the manual (cover/page 1), translated into English:

Object

This manual describes the real-time monitor available on the MITRA 15 computer (minimum configuration of 8K words of memory and a teleprinter)

It contains descriptions of the instructions, the I/O organization, the handling of interrupts and traps, and the use of monitor modules.
Click to expand...

Under II-1 (STRUCTURE DU NOYAU RESIDENT) the first line, translated into English:

The resident kernel is always located starting at address 0 of the RAM (random access memory).
Click to expand...

I don't know why Google's translation drops absolue (absolute) given the original French or converts mémoire vive (live/living memory?) straight into RAM... Bit sloppy, even if it might be accurate and English-y.

original French:

Le noyau résident est toujours implanté à partir de l'addresse absolue 0 de la mémoire vive.
Click to expand...
 
I don't know whether any part of the MTR is actually read/executed directly from ROM or if it is first loaded into RAM (kind of like PC bios shadowing).

Similarly, is that minimum configuration of 8K words of memory sufficient to make use of the MTR or do you need to have more than that installed?

Personally, I'm not sure if that 8K words are 8-bits wide, 16-bits wide, etc. Because 8K x 8 would pbe 8192 bytes, whereas I presume 8K x 16 would be 16384 bytes.
 
You must log in or register to reply here.
Back
Top