I have uploaded two files to my GDrive. One shows the assembly language along with the actual machine code and the other shows just the machine code in both HEX and Octal format. I do appreciate you sharing this video and the assembly code that goes with it. I will probably do a video on this myself, but I will of course mention your video as the source. drive.google.com/file/d/1A67tI6vSVFGBOQX6U6e01cZNc--xb_Rg/view?usp=sharing drive.google.com/file/d/1YiP_CU7k3IMhLT4qQq5PjctmASihr2q8/view?usp=sharing
@@bzotto Thank you, I like going over the assembly code. The program looks very simple. However I was not able to put together how C was designated to be a pointer to the DB? Does this look anything like what you actually keyed in ? 06 01 0E 0F 0A D3 FF 0D F2 0D 00 0E 0F 1E 1F 15 C2 0F 00 1D C2 0F 00 C3 04 00 F8 F1 E3 C7 8F 1F 3F 3F 1F 8F C7 E3 F1 F8 FC FC
@@jeffnay6502 Sorry, I hand assembled it and threw away the papers. But I can explain C: The register pair (B,C) is used as a 16-bit pointer to the table of light patterns. Because the table lives at 0x0100-0x010F, the high byte (B) is always 0x01 and doesn't change. The low byte, in C, cycles from 0x0F down to 0x00 and then resets back again. The (confusingly named) "LDAX B" instruction takes the (B,C) pair as an address, and loads into A the byte at that address. That byte is the 8-bit pattern for the LEDs (inverted, because the IMSAI displays the complement of what's in A when you OUT FFh). Does that help?
It looks like the hex code that I was able to come up with did actually work. I just had to make sure that I loaded F8 @ 0100h while loading the program using the front panel switches. Thank you Ben
Interesting crossover here...have you heard of the Knight Rider Historians by chance?
No?
@@bzottoWell you should check us out, having done such a fantastic job with this!
I have uploaded two files to my GDrive. One shows the assembly language along with the actual machine code and the other shows just the machine code in both HEX and Octal format. I do appreciate you sharing this video and the assembly code that goes with it. I will probably do a video on this myself, but I will of course mention your video as the source.
drive.google.com/file/d/1A67tI6vSVFGBOQX6U6e01cZNc--xb_Rg/view?usp=sharing
drive.google.com/file/d/1YiP_CU7k3IMhLT4qQq5PjctmASihr2q8/view?usp=sharing
Can you share that code???
Sure can. Enjoy: gist.github.com/bzotto/8bd0021441c3d10b8526b4c42cd6f627
@@bzotto Thank you, I like going over the assembly code. The program looks very simple. However I was not able to put together how C was designated to be a pointer to the DB?
Does this look anything like what you actually keyed in ?
06 01 0E 0F 0A D3 FF 0D F2 0D 00 0E 0F 1E 1F 15 C2 0F 00 1D C2 0F 00 C3 04 00 F8 F1 E3 C7 8F 1F 3F 3F 1F 8F C7 E3 F1 F8 FC FC
@@jeffnay6502 Sorry, I hand assembled it and threw away the papers. But I can explain C: The register pair (B,C) is used as a 16-bit pointer to the table of light patterns. Because the table lives at 0x0100-0x010F, the high byte (B) is always 0x01 and doesn't change. The low byte, in C, cycles from 0x0F down to 0x00 and then resets back again. The (confusingly named) "LDAX B" instruction takes the (B,C) pair as an address, and loads into A the byte at that address. That byte is the 8-bit pattern for the LEDs (inverted, because the IMSAI displays the complement of what's in A when you OUT FFh). Does that help?
@@bzotto Now that makes sense to me. Thank you. Do you still have the HEX or OCT code?
It looks like the hex code that I was able to come up with did actually work. I just had to make sure that I loaded F8 @ 0100h while loading the program using the front panel switches. Thank you Ben