Intersil 6100 emulator via chatbot (done)

Software
1

I made an Intersil 6100 (command line) Emulator (for my Festo device) via chatbot (Google) in c.

It took in total about 3 hours. Still not 100% complete.
It took ca 30 minutes and more than 20 attempts to get correctly reading my RAW binary file.
Several compilation errors.

It currently even has an LCD display (exactly like mine) and I’m currently testing the keys.

I learned a lot. I now have the correct IOTs for my keys and the 4 display locations.
There were also several explanations eg why the test pattern is wrong. But I skipped the RAM test as it’s still not working correctly.

The AI repeated some errors. I had to add more and more IOTs. And with the keyboard, it almost got stuck. But I told more and more about the hardware design.

These are my IOTs. IOTs für Memory Extension (6402, 6414, 6415, 6425), Interrupts (6001, 6002, 6003, 6005), Clock (6314) und FPP (6710). Display using addresses 11, 10, 13, 14 (top left, top right, bottom left, bottom right). Devices are 6abc (ab for device number and c for the function, especially input or output).

I hope that I can continue that session. More info later.

1 Like
Homebrew mini metal PDP-8 (1976) Intersil 6100 code
2

I hope you have lots of good acceptance tests. It feels to me like this approach will always have difficulty with getting to 100% correct - and without care, it might even backslide.

But with a testsuite, I’d have some confidence you could get to 100% passing.

1 Like
3

Yes, but probably it will take another couple of hours.

The hardware design is very complicated. With that many keys, special character encoding etc.
Luckily, I found out most myself. Otherwise it would have been even harder for the AI.

I almost had stopped the chatbot doing the same errors again and again. I had to make major decisions and suggestions myself. Otherwise it would have tested all numpad keys manually for all 4 display locations.

2 Likes
4

I had 2 more sessions, 4 hours each. Although promised, the sessions are not stored. There’s just a very brief summary, mainly with some few hardware facts and next steps. It’s possible to post the previous code, though. But as all conversations are lost, you almost start at zero getting the same suggestions and errors.

After 3 days, the IRQ and keyboard handling still not work properly.

Next time we start again at the very beginning. I previously skipped the RAM test as the test pattern was not correctly read. Even Vince Slyngstad didn’t know why.

There were now assumptions that the LifeBit could cause trouble with another IRQ.
The 6100 CPU has a different behaviour and bugs. One additional cycle after an IRQ. And different pointers for direct/indirect memory access (Instruction Field/ data field).

The recent assumption is, that the 9th EPROM would store a hardware decoding matrix or table for the “syntax” (RAM ?) check.
I doubt that, as there is very few data and even completely unknown how or if that EPROM is accessed by my device at all and how everything is mapped. I assume it just stores device numbers or similar for the PLC.

I’m very curious. Especially about that EPROM.
But with that style and speed. I doubt that I will ever get a full working emulator. It would take years.

Another way is to let the chatbot check the complete firmware ROM. I offered it, but it was only interested in detailed segments with mapping, that I haven’t completely understood yet. Not even the contents of the small 9th ROM 512 Bytes it knows yet.

5

Not sure if anyone is interested.
At least the chatbot confirmed reading this post and already could help me.

Today’s 4th session was 5 hours.
The RAM check now works. I have to check it more closely.
The 9th EPROM should be a Lookup table for Syntax check and display and is loaded to 7400. (I have other values there).
There was a double auto increment when just checking the address. CPU previously would branch to empty memory 122.
Now it runs to 3111 waiting there for a hardware IRQ.

It soon proposed an LCD output and it currently looks like this, top row means read, write, delete, copy

+---------------------------------------+
| MODUS: [X] LESEN    [ ] SCHREIBEN [ ] LOESCHEN  [ ] KOPIEREN  |
+---------------------------------------+
|     FESTO FPC 606 OPERATOR PANEL      |
+---------------------------------------+
|  +--------+            +-----------+  |
|  |   F1   |            |   0004    |  |
|  +--------+            +-----------+  |
|  (Funktion)            (Operand/Ad)   |
|                                       |
|  +--------+            +-----------+  |
|  |        |            |           |  |
|  +--------+            +-----------+  |
+---------------------------------------+
|     LIVE PDP-8 INSTRUCTION STREAM     |
+---------------------------------------+
  > PC: 1267 | Inst: 3130 (DCA) | AC: 6000 | L: 0
  > PC: 1270 | Inst: 5232 (JMP) | AC: 0000 | L: 0
  > PC: 1232 | Inst: 1130 (TAD) | AC: 0000 | L: 0
  > PC: 1233 | Inst: 0014 (AND) | AC: 6000 | L: 0
  > PC: 1234 | Inst: 3014 (DCA) | AC: 0000 | L: 0
+---------------------------------------+
| KASSETTE: Einlesen aktiv...          |
+---------------------------------------+

It first turned out that keys work just in this simulated display, but in the real code, there were still IRQ issues. Most are solved.
I simplified the keys. All input is possible just with the numpad and the function keys. And focussed on the input and output. Input from data via cassette worked with a simulated text file. Only one baud setting 1200, the highest is enough (that is F1 0004).

I think more output would be better like of the RAM 0-177. And maybe other memory. And throttle, that I could check the RAM test.
Some stuff is missing, like the syntax check, but that is not important. Important are error messages. I recognized an octal value 364 that I could identify from the manual as E4 (Bus error). The chatbot misinterpreted this as from the cassette, but this is from the PLC losing contact. Maybe this helps finding the lifebit.

6

After 6 days the RAM test still not work, at least I couldn’t watch it.
I once posted all 9 ROMs and error codes and many details.
There were some misunderstandings on both sides.

Eg. I said that the ROM is empty at the beginning, but I forgot that I have filled the RAM. So the chatbot saw that it’s not empty and had a wrong memory mapping.
It might be faster when I code and check it myself. But the mapping is/was still unclear.

According earlier session protocols:
My device should have an own opcode extension via CPSEL, so a PDP-8 group 1 instruction would be falsely expected. (AC 2000o at PC 30).

IOT 6414 should check the status of the display.

ROM 9 probably contains, at least later, special symbols for the display (maybe like a HD44780). Matrix maybe 5x5. I have 4 special characters on the bottom left. Two are a star and a semicolon. I used again another chatbot for comparing the symbols and hex values. How this ROM is accessed is unclear. I have to check it completely for all symbols. And then it can just be simulated.

The star, a * but a bit different

OXOXO
XXXXX
OXOXO
-----
----- ?

That is 54 70 56 30 54 30 (maybe rotated or mirrored)

|Hex-Wert|Binär-Code (Spalte von oben nach unten)|Relevante 5 Bits (Schriftbereich)|Pixel-Form (Spalte)|

|**54**|`0 1 0 1 0 1 0 0`|`0 1 0 1 0`|`. # . # .`|
|**70**|`0 1 1 1 0 0 0 0`|`1 1 1 1 1` *|`# # # # #`|
|**56**|`0 1 0 1 0 1 1 0`|`0 1 0 1 0` *|`. # . # .`|
|**30**|`0 0 1 1 0 0 0 0`|`0 0 0 0 0` *|`. . . . .`|
|**54**|`0 1 0 1 0 1 0 0`|`0 1 0 1 0`|`. # . # .`|
|**30**|`0 0 1 1 0 0 0 0`|`0 0 0 0 0`|`. . . . .`|

70, 56 and 30 should use a slightly shifted bit pattern. Or

  • 54 (\rightarrow ) . # . # . (O X O X O)
  • 70 / 56 (\rightarrow ) # # # # # (X X X X X)
  • 30 / 54 (\rightarrow ) . # . # . (O X O X O)
  • 30 (\rightarrow ) . . . . . (freie Reihe)
7

Correction: The LCD Matrix is 5x8, where only 6 lines are used.
Now ROM 9 is completely understood and is just for the special symbols of the LCD.
The star looking like this

Zeile    Grafik-Matrix (5x8)    Binär-Code    Realer Hex-Wert
Z1:      .  #  .  #  .          01010         54 / 34 exact match 54
Z2:      .  #  .  #  .          01010         54 / 34
Z3:      #  #  #  #  #          11111         7F / 70 exact match 70
Z4:      .  #  .  #  .          01010         54 / 34
Z5:      .  #  .  #  .          01010         54 / 34
Z6:      .  .  .  .  .          00000         30      exact match 30
Z7:      .  .  .  .  .          00000         00
Z8:      .  .  .  .  .          00000         00

I have 4 small special symbols. One arrow can be inverted. And I have a half zero and 1, which can be displayed separately.
Most symbols are not much of interest and are special function when the PLC is attached.
Both * and ; for programming codes FURTHERMORE, and ELSE are internally a “1” in the 6 digit Festo code on left. I also have a little dot in the middle of the display and an underline.

The header is 128 bytes using multiplexing and bank switching. So most symbols are not completely stored separately. 3 bits are control bits (7,6,5), 5 bits are graphic data. The first symbol is the half zero and 1.

Zeile    Grafik-Matrix (5x8)    Binär-Code    Realer Hex-Wert
Z1:      #  #  .  #  .          11010         5A / 3A
Z2:      #  .  .  #  .          10010         52 / 32
Z3:      #  .  .  #  .          10010         52 / 32
Z4:      #  .  .  #  .          10010         52 / 32
Z5:      #  .  .  #  .          10010         52 / 32
Z6:      #  #  .  #  .          11010         5A / 3A
Z7:      .  .  .  .  .          00000         00
Z8:      .  .  .  .  .          00000         00

Header 05 00 Start Flag. 01 03 enables extended graphics mode, 01 93 set Matrix to 5x8, 25 9C 23 40 set page and column address (40 CGRAM).

In fact the LCD is not dot based but has free form segments, so the star has diagonal lines, but the data is the same. Rather looking like this


 \  /
  \/
xxxxx
  /\
 /  \
8

RAM-Test maybe solved after 9 days.
According the chatbot the RAM test is only checking address 0 (and 10, auto index pointer) and not the full page 0 (0-177). And it was self deleting (its own pointers, targets 30-34 and the display register at 40). The test would be so fast (much less than 1 sec) that even with a high brake it isn’t visible.
This was tested and a RAM error E9 displayed, followed by the indefinite loop at 535.
There was also a critical opcode 7421 at 410 which is MQL from the EAE (Extended Arithmetic Element) extension. (Most 8E emulators should have this).

The IOT 6414 at the RAM test checks the Bus Ready signal which is at 154. I think that caused the wrong test pattern.
And as said there was a custom opcode change via CPUSEL.

To me this is not a real RAM test if only one cell is tested. Previously it says that there wouldn’t be any RAM test at all.

File I/O is I think device 43. IOT 6436 and 7. File import coming next. We currently simulate an input by an L key (LOAD) instead of F1 with all parameters (like baud settings) and address. That code location was previously unknown, same for the key mapping.
After the import, I would do a printout.
Error messages and syntax check is not that important, maybe knowing the location.

9

Finally! A major breakthrough in session 12.

After the RAM test, we implemented data import and export/print (via TTY only). Import works, but output is not 100% perfect. One of 4 words missing a “1” what is for SONST (ELSE), DANN (THEN) and AUßERDEM (FURTHERMORE). Also the mnemonics (Festo-BASIC) is not printed/converted yet.

I first made some mistakes. I always used my patched firmware with pre-filled RAM. I though that the RAM test would overwrite it anyway. But as the RAM test is just at ADR 0, and ADR 0 and 1 are used for the PC, that probably caused some more issues.

Another interesting fact is, that there are values written to 3 of the 4 display sections while the RAM test. Not the test pattern. These don’t show up on the real device, either the RAM test is too fast or the display is not turned on yet.

Another major mistake was, that I didn’t recalled the correct keys. Import and export are not read and write (that is for the EPROM cartridge) but copy (to cartridge).

Some parts are just simulated, like the CRC check (simple addition). Without it, the import wouldn’t work.
I have to closely check the C code and also check where the original code sections are in the firmware.

Import (and so the keys) should start at 5427. The first IOT there is 6414.
Also interesting, the mapping of the EPROM cartridge. It’s at 3200, but on bank 1, as bank 0 is my ROM.
The TTY function is stored at 115. 4 is import, 2 is export.

10

After switching to more hardware-based emulation there were some steps backswards. Keys for import and printing were not accepted anymore. One major issue was timing. We now have 50ms and some cycles between the simulated key sequence. Then, import was working but the values were wrong. We now have a different design, showing the amount of words that were read and the CRC, but changed the status line later. The 6 digit Festo code is stored as an octal word on the cartridge at 3200. 011001 (.WENN ESB EAS 1) is stored as 1101.

+---------------------------------------+
| MODUS: [ ] LESEN [X] SCHR. [ ] LOES. [ ] KOPI.     [IDLE] |
+---------------------------------------+
|  STATUS: ISR-Hardware-Kanal aktiv.    |
+---------------------------------------+
|  +--------+            +-----------+  |
|  |  140   |            |   0534    |  |
|  +--------+            +-----------+  |
|                                       |
|  +--------+            +-----------+  |
|  |   *000 |            |           |  |
|  +--------+            +-----------+  |
+---------------------------------------+
| LIVE INJECTED KEY: 0000                |
+---------------------------------------+
|     LIVE PDP-8 INSTRUCTION STREAM     |
+---------------------------------------+
  > PC: 2635 | Inst: 5423 (JMP) | AC: 0000 | IF: 0 | DF: 0
  > PC: 5434 | Inst: 5635 (JMP) | AC: 0000 | IF: 0 | DF: 0
  > PC: 5054 | Inst: 4017 (JMS) | AC: 0000 | IF: 0 | DF: 0
  > PC: 0020 | Inst: 1417 (TAD) | AC: 0000 | IF: 0 | DF: 0
  > PC: 0021 | Inst: 3131 (DCA) | AC: 7176 | IF: 0 | DF: 0
+---------------------------------------+
|    INTERNES RAM: ZELLEN 000o - 177o   |
+---------------------------------------+
  000: 7261 5427 0000 0000 0000 0000 0000 0000 
  010: 0534 0140 0000 0000 0000 0000 0000 5056 
  020: 1417 3131 5531 5434 1423 2023 5021 7400 
  030: 0602 0600 0601 0603 0604 0007 0010 0514 
  040: 0370 0004 7777 7777 0652 0600 0514 0047 
  050: 4314 7777 6314 4000 0014 0014 0014 0014 
  060: 0000 0000 0000 0000 0000 0000 0000 0000 
  070: 0000 0000 0000 0000 0000 0000 0000 7617 
  100: 0000 0000 4524 0000 0000 0000 0000 0000 
  110: 0000 0000 0000 0000 0000 0002 0000 1525 
  120: 0000 0000 0000 0000 0000 0000 0000 0000 
  130: 0000 7176 0000 0000 2667 0000 0000 0000 
  140: 0001 1523 0004 0400 0000 0000 0000 0000 
  150: 0000 0000 0000 0000 0000 0000 0000 0000 
  160: 0000 0000 0000 0000 0000 0000 0000 0000 
  170: 0000 0000 0000 0000 0000 0000 0000 0000 
+---------------------------------------+
|  CARTRIDGE-RAM (FELD 1): 3200o-3237o  |
+---------------------------------------+
  3200: 1101 1301 3110 2110 0000 0000 0000 0000 
  3210: 0000 0000 0000 0000 0000 0000 0000 0000 
  3220: 0000 0000 0000 0000 0000 0000 0000 0000 
  3230: 0000 0000 0000 0000 0000 0000 0000 0000 
+---------------------------------------+

Some more RAM values discovered. 104 for Key intern, 117 for amount of words. IOTs for Cartridge reading/handling are 6426 and 6427.

Again it was me, having most of the ideas. Posting more hardware details and PDP-8 code. I would expext from a chatbot that it asked for that instead of trying 10 times different versions of code. I/we did some more mistakes. Again wrong key S instead of K (but sequence for printing is (almost right). It’s a bit different then import. More parameters and 2 more keys needed (ADR and ASF).

1 Like
11

The RAM test is still a mystery.
I forgot that I have an error message that displays the defective RAM cel, so there must be indeed a full RAM check with the test pattern. Not sure how this is solved, that the RAM not overwriting itself, especially the PC. Maybe multiple bank switching or excluding address 0 and 1 for the PC.

On my post

I think I have 256 words of RAM. And the page 0 only has 128. So the mapping is still unclear.

I have C code where the RAM test working at some parts, I think patched. And I have code where import and export works (except for translating the code to mnemonics).

It is difficult to merge the 2 codes (sections in different files) and the chatbot also couldn’t merge them without errors.
Import now works,values are also correctly written, but export doesn’t work. Maybe due to wrong checksum, or timing or interrupt issues. I once had an internal undefined interrupt error (would be a hardware defect) but this was solved. I also had resets. I think timing issues.

The chatbot has several reasons for this and that. But most is probably wrong. It’s amost impossible to explain everything in 5 hours. After 4 or 5 hours the chatbot sometimes terminate the session, probably due to full space.

12

At least the RAM test is now completely understood. No more progress otherwise for 6 days.

The chatbot was right in an earlier session that a RAM test would be extremely fast (ms).
Today, it also explains that and gave a workaround. But only when I recalled that a RAM cel is fetched one by one on the fly, checked and a 0 is written back.

The 6100 has an interal hardware flag but my hardware is not synchronous, so IRQs between the RAM test must be blocked. Due to the missing real hardware, there would be a RAM error message/loop at 541.

A workaround is, preventing writing the 0s back. And for the first time, I’ve seen the test pattern (2525, starting at address 11).

Later, the loop at 605 has a hardware IOT 6400 interacting with the link bit. Furthermore a logic trap at 7327.

Here is the code for the workaround
main:

while (running) {
        cpu_step();
        
      // 🎯 FIX SITZUNG 18: Der Oszillator darf ERST blinken, wenn der RAM-Test vorbei ist!
        // Der RAM-Test endet bei Adresse 00445o. Erst ab PC >= 00446o ist das RAM geschützt.
        if (PC >= 00446 && loop_cnt % 200 == 0) {
            *(memory + 00154) = (*(memory + 00154) == 0) ? 1 : 0;
        }

        // INTERNEN SYSTEMZUSTAND SCHÜTZEN
        if (PC >= 00446 && loop_cnt % 100 == 0 && !export_triggered) {
            *(memory + 00115) = 0; 
            *(memory + 00116) = 0; 
        }

im6100:

switch (opcode) {
...
case 3: { 
            if (IF == 0 && tracked_addr >= 07400 && tracked_addr <= 07777) {
                // Hardwareschutz des oberen Speicherbereichs im Feld 0
            } else {
                // 🎯 REINER TEST-EINGRIFF FÜR SITZUNG 18:
                // Wenn der RAM-Test schreibt (PC < 00446) und versucht, den geretteten Wert 
                // (der 0 ist) wieder zurückzuschreiben, blockieren wir das Überschreiben!
                // Wir erzwingen, dass das echte Prüfmuster der CPU im RAM stehen bleibt!
                if (current_pc >= 00415 && current_pc <= 00420) {
                    // Wir lassen das Muster im RAM eingefroren stehen
                    memory[tracked_addr] = AC ? AC : 02525; 
                } else {
                    memory[tracked_addr] = AC; 
                }
            }
            AC = 0; 
            break; 
        }

We 're still at the import and export of data. Import and writing to cartridge work. I think there’s no CRC check for an import. But definitely for an export.
Maybe it’s easier to emulate the programming (writing) as there are several syntax and key errors known when entering the 6-digit Festo code.
It’s quite easy to write a simulator. (I even wrote a translator myself for BASIC, 2 years ago). But I want to understand and find the code section. I’m only sure for the section for a printout/export.

13

Some major progress in session 20, 2 days ago.
For the first time we have real actions from the PDP-8 (as far as possible) instead of simulating.
Import is (was) working but not the export yet.

The chatbot seemed to be much smarter at the beginning (update?) asking for PDP-8 code and much less compiling errors.

TTY IOT is 6431, 6434 transferring contents from 101, previously loaded from 132. IOT 6411 polling checking if terminal is ready for another character. Checksum calculation should be at 175.

The first digit of the 6-digit Festo code (bit for the condition WENN DANN SONST AUßERDEM - IF THEN ELSE FURTHERMORE) should not be written into the octal word to the cartridge, maybe digit 4 as well. The internal state machine already knows the logic. Not sure about this, especially digit 4. That is probably wrong (at least if the last 4 digits are an address).

There’s a Lifebit at 154 (also containing the CRC) blinking with 0 and 1. This is important preventing IOT 6400 (hardware timer) jumping to 742 (or leaving the loop at 600) due to missing real hardware. I previously thought that the lifebit is only working if there’s an attached PLC.

IOT 6414 is for reading the keyboard. 6032 keyboard clear.

During the RAM test, all IRQs and the lifebit have to be disabled due to activated hardware flags as the CPU is not synchronous with the firmware.

Yesterday’s session was a desaster. Severe compiling errors. Not even noticing that the fault is on a different file. Even after that it couldn’t be fixed and combined 2 SRC files into one. Emulator runs but the ROM isn’t read correctly. Although I’ve sent earlier correct code. For the first time no number on the session protocol. Maybe an older chatbot version?

Today’s session was again much better. But as we have real hardware emulation there are still issues. Somehow after about 4 hours there are often stepbacks. For the first time I’ve seen values in both RAM and display while RAM test and also after it, RAM completely filled. Pointers and maybe code, I detected long ago.
We’re currently again stuck at the RAM test.

14

Reading this, I can’t help but think that it would be quicker and easier to write the code yourself. You also then have one entity that fully understands it, rather than two that don’t.
I had a similar experience when I was told that someone had created a cycle accurate Z80 emulator in 4 hours or so using an LLM. That was interesting as I’d done the same a couple of weeks earlier, by porting an open source cycle accurate Z80 emulator to my hardware platform in about the same amount of time. OK, I copied the emulator, but then that’s really what LLMs do, with an averaging step added, really.

1 Like
15

My programming skills (in C) are very limited.
But I think I now have enough code and skills to try it myself.

One problem is, that the hardware details of the device to be emulated are not completely understood.
TTL-driven keys, unknown timings, unknown memory and keyboard mappings, interrupts, external devices and the like and maybe even more secrets.

I did some big progress today, implementing a debug and diagnosis part for checking the keys and the display output.

The correct timing might have been found. I think the timing between the keys might be different, maybe due to different keyboard sections and the internal key check. These are my assumptions. And it’s all work in progress. Currently RAM-Test, Keys, and file import working again. The export is much more difficult including reading the amount of words and CRC calculation. Then reading the mnemonics and functional units tables and their allowed combinations and then build an output. Although most of the code sections are known it’s not easy (and all from the PDP-8 hardware and not simulated with C).

16

I found some more facts by re-reading my manual and re-reading my 3 year old post on this forum.

My device has 2 pages of RAM (confirmed on the PCB). 0-377. Hence the start at 400. Only page 0 of ROM is empty. The RAM test deleting the ROM at 200-377 as well. Hence the crashes. I noticed this before at some time, but didn’t recall. So the mapping is a bit complicated.

I always wasn’t sure if the 6 digit Festo code is correctly converted. Now I have the proof. At least the code is wrong, although the values are correct (by coincidence). It’s packed lossy.

I always wondered how to pack 16 or 14 bits into 12.

1 7 7777 would be 16 bits. The bus is 16 bits wide, but everything is stored as 12 bits.
I found a new sample with a checksum. And most likely the first bit isn’t stored. As I have a syntax check while programming.
When having just 14 bits and the first isn’t stored, the 13th bit can be stored with the help of the checksum and bit masking. Can anybody help when I post these samples with checksums?

It all depends on the size of the last 4 digits, the word (used for address and functional units). I also have 2 lookup tables for the units <1000 and >1000. And the address might be just 0777 as well. The addresses / RAM carts come in different sizes and have dip switches and other hardware to check the right location and size.

17

I made some major discoveries almost all by myself.

I have a fast, late 1983 im6100A with 8Mhz, hence the delicate timing especially for the keys. Confirmed on the photo I posted here.

I have re-checked the specs for the RAM cartridge. According the seller, it has 4 RAM chips a 4 bits. So 16 bits. I previously was sure, that the 16 or 14 bits are packed into 12 bits as this is possible (see the previous post) and the CPU is 12 bits. According my manual the bus is 16 bits as well. The packing and word order is still not completely understood. The condition bit, digit 1 (.WENN/IF) of the 6 digit code is stored at 105, I found 2 years ago when finding the code for a printout. I recently found code for the other digits.

Digit 2, the instruction is maybe stored at 133. Digits 3-5, the functional unit is maybe stored at 132, 104 and 103. And the complete word/address digits 3-6 is maybe stored at 106.

The cartridge has another larger RAM and maybe firmware. So some calculations, packing, CRC and syntax check might be done there. A full emulation would be then very hard to impossible without having that ROM.

The ROM 200-377 is mapped to field 2. This is confirmed with a logging including field changing instructions. All other ROM is in field 0. I found very late, that I have RAM in 200-377 as well and the RAM test will overwrite it.

Today I have seen for the first time RAM being written there.
The ROM 200-377 is only used for copying code into RAM at 44. I found these 4 “tables” long ago. 2 sharing the source 200 and 250 with different length. So that’s why the tables were not copied when the RAM test deleting them and I also haven’t noticed that as the ROM is not regularly accessed there. The matrix for the functions F0-F7 starting at 63 must be loaded later, otherwise the long tables at 44 would overwrite them.

IOT 6400 is not a timer (but for the key matrix) and at 154 is not a lifebit. I do have a lifebit but not there.

The RAM is not that simple. A single cell is for different purposes. 10-13 not having just the octal values for the LCD. There are also the usual Auto index registers and also other values are stored here. There are 4 IOTs 6410-6413 pushing the values to the LCD cells. The RAM is self-modifying and destructive so this is very hard to track. Parts of the RAM also seems shifted.

I previously found the code copied to 172-177. This is for printing often used characters like 0 ,LF ,CR. By checking the code, I found earlier values stored at around 162-171 as well. I assume there to be a printer buffer. But might also serve for other storage.

I found a key buffer. This amount is included in the tables 62 and stored at 43. 7773 would allow 5 keys to have a full sequence.

Most of the hardware emulation is still not working. I found 2 more IOTs yesterday. Hard to find as some 6xxx are addresses, others values. The code has many pointers, values, and constructed-JMP tables. Even the key codes haven’t been found yet. I might have found some today, but need more checks later.

18

Another big, but late progress. I didn’t take care about the RAM check anymore, but I noticed that some opcodes not working correctly. Like 7421 MQL, MQA, BSW, RAL etc. Suddenly I had a test pattern in the RAM. Some opcodes were still not working, and some missing. Then they were fixed according the datasheets. But first not handled correctly afterwards. 2 years ago I noticed that there are 3 turns of a RAM check. But now I found 6 different test patterns, worth making a a clip.

First run with still wrong opcodes. But manually loaded tables to 44 and 63. 2nd run with correct RAM check and standard values without the tables

That is also a proof that the RAM is 2 pages -377. I already have the ROM 200-377 in field 2. As there are instructions like AND 352, the ROM obviously has to be mirrored after the RAM check to RAM field 0 as well.

I had error E8 4 (IRQ ROM error) at cell 40 but today this was obviously fixed. I now have bit masks of the keys that work, but still might have the wrong representation of the real keys. At least they each have different results.
The double or triple use of RAM cells is still very hard to follow. RAM and timing is very volatile.
Maybe there are still wrong or missing opcodes, there are many combined 7xxx opcodes. Many 7xxx words are addresses, same for 6xxx IOTs. So it’s not that easy what are opcodes at all.