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.
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.
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.
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.
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
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.
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)
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
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.
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.
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.
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.
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).
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.
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.
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.