Boot options? Demos? Blinkenlights? Autorun?

[GaryBoone]

My IMSAI8080 is built and working great. I have some questions now that I haven't found by searching on the website:

1. How can I have my own program boot? For example if I key in Program 3 (p. 48) from the IMSAI manual.

2. The Startup Configuration shows how to boot into two ROMs: XYBASIC and CP/M. Are there others? Eg, some interesting blinkenlights beyond normal operation or other demos? I see the Memory Maps, where it lists xybasic, but the rest are cryptic.

Questions I've been able to answer: (Please add/correct...)

3. The video in the Startup Configuration section says that "the value I'm keying in is described in the configuration guide." Eg: it appears that A8 UP picks the "ROM image for booting from floppy." Where are details about the boot configuration values for each switch?

Answer:
It's the table in the Startup Configuration section under the grey box "Booting into CP/M 2.2".

Similar to question 1 above, the details of what's in the ROMs is needed for the complete answer...

4. Can programs automatically start on powerup? It looks like the RUN switch has to be toggled up to enter running mode. Is there a way to boot into RUN mode on powerup without having to hit the switch?

Answer:
Yes, set the A15 switch 1 in the boot configuration to autorun.

Thanks to highnibble for the kit and to the community for their help. I'm having a great time with this kit!

--Gary

[nbreeden2]

Gary - I see in your post you're digging into the documentation then asking questions. I salute you for starting in the sea of documentation. I'm going to add some background for everyone before I try to answer some of your questions.

I'm known for writing "Walls of text". I hope you all will read over this. I try to build context which is part of why my reply is so long.

Please read to the end then make corrections, ask questions, make this more concise etc.

The design of the emulator is also meant to take you on a learning journey. Reading documentation and figuring out how to set jumpers or DIP switches on various expansion boards. In the IMAGE.zip file you can download or find on the uSD card you'll find the file "IMSAI 8080 User Manual.pdf" - this was the manual that shipped with the original kit and was typically the only documentation the user had. I recommend everyone who is new to the system read this. If you bought a preconfigured system from a store, they would configure it for you. A few days later you could go pick it up and they would spend time trying to show you how to use it but if you didn't have the proper background knowledge it would be difficult to really understand. Most users bought expansion cards from ads in magazines either as kits or preassembled and these had a manual. In the early days you often had to learn to read schematics to figure out how the board worked. Some manuals went into detail, but it was hit or miss and often inaccurate. If one of your relatives built an IMSAI kit back in the day they had to go through all this often at the kitchen table with no one to ask for help. User group newsletter, meetings and magazines helped fill the gap.

Imagine waiting weeks or months to find a solution in a newsletter, user group meeting or magazine to move forward with making it do what you wanted or even work.

IMSAI later went on to what they called Turnkey systems. There was a power switch on the front panel and not much else. You turned it on, and it just worked, like your modern PC today. The IMSAI Turnkey systems often went on to become business machines, manufacturing controllers etc.

You most likely bought the emulator for the front panel experience, Blinkenlights, switches and mystery of it. The kit is meant to be enjoyed from this viewpoint. Being frustrated and struggling is, in my opinion, part of the fun is to try to see it that way. The experience is meant to be learning from doing and reading just as it was back in the day. I know the High Nibble, and this is part of what he hoped to recreate, the mystery of switches and Blinkenlights then taking the journey to really understand it from how the 8080 works, how the IMSAI hardware works and programming in machine language*.

• I define "machine language" as writing out the 8080 opcodes** on paper, looking up the binary or hex values for the opcodes, writing these down, figuring out the address all the instructions*** and data lived at then updating jump addresses to point at the right addresses. You didn't have a text editor, an assembler, a linker. You had manuals, paper and a pencil. If you can't explain why the front panel has red and blue switches grouped in fours you are missing much of the joy the emulator can deliver.
  ** Opcodes are the human readable names of instructions the 8080 can run: JPE 0x1456
  *** Instructions are the bit patterns the 8080 uses, what is in memory: 0xEA 0x56 0x14
  If you don't know what 0x1456 or 0001010001010110b means you have some reading to do.

Some "purists" will state that "machine language" and "assembly language" are the same. I use the terms to differentiate between doing it by hand vs using software tools like assemblers. I ask that the "purists" not jump on this discussion to point this out. If you want this discussion, please create a "New discussion".

Back in the day when someone spent as much money as a decent used car cost for an IMSAI there was plenty of frustration when it didn't just do something automatically, or even work. In 1977 I bought a used Chevy Impala for $300, I made $1 an hour. As a teenager the car was the priority, I drooled over computers like the IMSAI but didn't have the money.

Let’s now pretend we're at a user group meeting at the local high school and your questions have come up. I've wandered to the front of the room as I think "Can I answer this?".

The IMSAI doesn’t have an automatic 'Power On Reset'. It’s up to the user to RESET and start (RUN) the machines. This was due to the fact the early machines only had RAM so on powerup there was nothing to reset too, RAM is volatile, on power up it holds random data. The user had to toggle in the instructions and data they needed then RUN it, this could be a loader for paper-tape, a floppy disk, a game etc.

Some expansion cards added a 'Power On Reset' but you have to have an address to reset to. Resetting to address 0x0000 was straight forward as the RESET switch does this. The ROMs used for CPM need to be in high memory as CPM expects to have access to lower memory as RAM, the CPM manuals have the memory maps. You'll find many ROMs started at 0xD800 but there were plenty of other start addresses.

So, how does CPM get booted if the machine resets to address 0x0000 when the ROM lives at 0xD800? On reset the ROM is remapped from 0xD800 to 0x0000 in hardware. The machine is then started (RUN Switch), the first instruction in the remapped ROM is executed. The first thing the CPM loader ROM does is change a hardware configuration bit to remap the ROM back to 0xD800, then it does a jump into the remapped ROM. The magic here is the hardware forces the ROM to stay mapped at 0x0000 for three CPU cycles. This allows time to read a jump instruction from ROM while at 0x0000. When the three CPU cycle delay is done the ROM is then mapped back to 0xD800 and off we go to boot CPM. Confusing, yes, it took me some time to understand this.

If you don't know what a CPU cycle is, you have reading to do.

BASIC in ROM typically lives in low memory. You would typically change physical jumpers, so the XYBASIC ROM is at 0x0000 permanently. The emulation does this with soft jumpers. This gets the heart of why there are various MEMORY map sections supported in the emulator.

The front panel on the IMSAI works by forcing an 8080 instruction onto the address/data bus, letting the 8080 run the instruction then halting the 8080 CPU. Load address, Examine and Deposit all work like this. This is another reason it's hard to do an automatic boot in the design of the IMSAI, at power up the front panel is in control. You control this by Pressing Reset (address is set to 0x0000) then Run which starts the process as described above. If you disassemble the ROM, you'll see the 8080 instructions that do this bit of magic.

In IMAGE.zip or on the uSD card you'll find the file MPU-A-ROM.hex - you'll see it in the High Nibbles documentation here:
https://thehighnibble.com/imsai8080/configure/#memory-maps
in the "MEMORY 1" section.

The CPM boot ROM (MPU-A-ROM.hex) code looks like this; all values are in HEX notation; I hope I have this right:

; Press RESET, the CPU address is reset to 0000; the ROM at D800 is mapped to 0000 by the RESET signal in hardware.
; Press RUN
0000----3E----MVI 40---------; Load 40 into the A register
0001----40
0002----D3----OUT F3--------; Output the A register to port F3 (ROM remap control)
0003----F3
; This is where the three 8080 cycle delay happens, the next three bytes are read in low memory
0004----C3----JMP D810-----; Jump to address D810
0005----10
0006----D8
; The ROM is now remapped to D800, the three 8080 cycle delay end here.
D810----C3----JMP DDAF----; We start to boot CPM
D811----AF
D812----DD
DDAF----C4----CNZ DD70
DDB0----70----MOVE M,B
DDB1----DD---CALL E67E
.
.
.
If you don't understand this read the "8080 Assembly.pdf" manual.

What the emulator does is replace the hardware configuration jumpers from the expansion boards and implements them as soft jumpers. This is why there are several [MEMORY x] sections, each representing a set of what were physical jumpers but are now soft jumpers.

On my Dropbox is a ZIP file with two PDFs in it. One has a mapping table I created for the NVM front panel switches to help clarify them. The second document describes how to get into and setup the NVM for various ROMs and other items like what CPU, what clock speed for the CPU etc. Pretend I handed out photocopied pages of these.

When you download this you may end up with a ZIP file in a ZIP file. If the first ZIP file results in a second ZIP file, go ahead and UNZIP it.
https://www.dropbox.com/scl/fo/v2oxwemfl6h510rt2vkvl/h?rlkey=hasr86n1q20eyanwgnntx421v&dl=0

Link to the emulator startup configuration documentation (Non-Volatile Storage, NVS) – this is how the soft switches are set as described above:
https://thehighnibble.com/imsai8080/configure/#startup-configuration-non-volatile-storage-nvs

The example Memory Maps:
https://thehighnibble.com/imsai8080/configure/#memory-maps

[willjlong]

Good stuff Neil!!

[GaryBoone]

Thanks, Neil, for that detailed and clear explanation of how the boot works, and thanks too for the dropbox docs.

So to have the system boot to a program that I write, it seems I would have to have my opcodes stored into one of the ROM locations, then set the boot configuration to start running at that location. I'm guessing I could replace one of the hex files in the IMAGE/imsai/roms folder of the firmware or add my own. I'm not finding any documentation on how to do this process. Are there some notes somewhere?

BTW, it looks like the dropbox docs need to updated to reflect that A15 is the NVS_AUTO_RUN setting.

[nbreeden2]

Well crud, I thought the DropBox files had this update.

[nbreeden2]

If you write a program meant to be stand alone you can toggle it in directly on the front panel.
You don't need to replace a current ROM image in the uSD ROM folder, there are USER ROM locations available, more below.

I believe I have this correct? I don't have my IMSAI at hand to test on.
This is a good 8080 OPCODE list: https://www.pastraiser.com/cpu/i8080/i8080_opcodes.html
If you find the OPCODE on the web page the HEX value should match what I list below

I've used "-" below to represent spaces as the post keeps losing my formatting.

0000---DB---IN----; Input from port FF to the A register, read the front panel switches
0001---FF
0002---D3---OUT--; Output to port FF, the front panel LEDs
0003---FF
0004---F2---JP-----; Jump 0000
0005---00
0006---00

To be toggled in from the front panel
DATA---Switch-----Comment
====--=====---==============
xx------RESET------Address = 0000
DB-----DEPOSIT---Write to address 0000
FF------DEPOSIT---Write to address 0001
D3-----DEPOSIT---Write to address 0002
FF------DEPOSIT---Write to address 0003
F2------DEPOSIT---Write to address 0004
00------DEPOSIT---Write to address 0005
00------DEPOSIT---Write to address 0006
xx------RESET------Address = 0000
xx------RUN

xx means doesn't matter.

If you make a mistake, it's easiest to start over. The user manual goes into more detail for other way of correcting a miss-entered program.
Both RESETs set the address back to 0000, this is why RESET/DEPOSIT and RESET/RUN work

RESET
SINGLE STEP
SINGLE STEP
SINGLE STEP
. . .
Will let you step through what is in memory byte by byte and see it run

RESET
EXAMINE
EXAMINE
EXAMINE
. . .
Will let you confirm what you entered without running it

In the mapping file I created on the DropBox it's very leading.
"ROM 7 at 0000H"
"ROM 6 at 0000H"
Should be read as
"User ROM 7"
"User ROM 6"
I thought I had fixed this in the uploaded version.... :(

To emulate burning an EPROM these are the steps.
You can create an INTEL HEX file, put the file in the ROMs folder on the uSD card, create a [MEMORY xx] map to define the ROM name and address it uses, setup up the NVM to access that ROM in the slot the [MEMORY xx] config defines.
The HEX file emulates an EPROM
The [MEMORY xx] definition emulates putting a EPROM on an expansion board
The NVM entry emulates setting the jumpers on the PCB with the ROM (I call these soft jumpers)

Creating an INTEX HEX file is tricky, it has a very specific format, there are a lot of control bytes on each line with the actual bytes that represent to program sandwiched in the middle.

[nbreeden2]

As I mentioned in my previous post creating an INTEL HEX file is tricky. These files represent/emulate physical EPROMs in the emulator.

How I do it for small programs is this:
I hand assemble/create the program to get the BYTES for the EPROM.
On my Windows machine I run the control program for a USB EPROM programmer.

• I don't need to have the USB programmer attached, I ignore the "No Programmer Found" message.
  I hand enter the program into the DATA EDIT area of the software.
  I do a FILE->Save As
  I pick the INTEL HEX option and save the file.
  The software calculates all the control bytes I mentioned in the previous post.

[nbreeden2]

To create larger assembly programs:
I use the "Telemark" assembler. http://www.cpcalive.com/docs/TASMMAN.HTM
This is not TASM, that is a different assembler.
TELEMARK runs from the command line (command shell, CMD.EXE) under Windows 8,9,10 and hopefully 11.
I use the "8085" definition file, it understands the 8080 opcodes.
The "Z80" definition file doesn't understand 8080 opcodes, it expects Z80 opcodes which are different.
I write the assembly program using NOTEPAD++ paying attention to the syntax Telemark expects.
I save the source as an .ASM file
One of the "Assemble" options in TELEMARK writes an INTEL HEX file. I then transfer this file to the uSD card in the ROMs folder.

[GaryBoone]

I'm on macOs. I see that I there are Mac-compatible cross-assemblers such as https://github.com/Megatokio/zasm. Instead of cross compiling, though, could we not just use the ASM built into CPM? Maybe for short programs, ED wouldn't be too painful? And we could test directly before committing to firmware? Then I just have to move the hex file to the right place and complete the other setup as you describe above.

I see that the IMSAI manual Program 3 includes the assembly code in addition to the octal that could be keyed in directly. And I see that the "CP-M 2.2" manual in the image at http://imsai8080.local includes a chapter on ASM ("Section 3") and that it outputs HEX files.

[nbreeden2]

Gary, again thanks for reading the manuals. :)
If you use an assembler under CPM (or even TELEMARK as I do) there are a few things you need to keep in mind based on my experience.

• If your code has any dependencies on CPM such as calls into CPM it won't run standalone as CPM isn't in memory. It could run from inside CPM then not work standalone. Macro assemblers may hide this fact.
  • CPM provides a common API that hides the details of different cards behind the scenes, a BIOS so to say. This makes CPM portable. Any code in ROM that runs on one machine and uses CPM API calls should, in theory run on any other same CPU based CPM machine.
  • If you hard code things like ports or UART I/O this most likely won't work on other machines.
  • Every CPM machine allowed the user to decide what ports did what, what memory addresses might be used for memory mapped I/O, what brand cards they used and the particulars of that card etc. Ten physical IMSAIs could have 10 completely different I/O cards, port mapping etc.
• If the program ends and doesn't use the proper CPM exit call then CPM will most likely need to be cold started as it expects some portions of memory to be untouched when a user application is run. This isn't a big deal but kind of a pain.
• A HEX file isn't necessarily the same as an INTEL HEX file. There is also a different format, the Motorola HEX file as I recall. There may be others.
• I know of no assemblers for CPM that can write an INTEL HEX file. They may exist, I just don't know.
• The DR supplied text editor is a pain. Line editors are a pain. I use a modified version of TE under CPM, it expects a VT100 and is full screen. I can't share it as it violates the "use" clause requirements for attribution, I removed this to free up memory.
  https://github.com/MiguelVis/te
  I use a couple of different C compilers under CPM, I don't recall which ones. All my stuff is in storage in another state so I can't look it up. One supports ROMable code.
  I use TELEMARK because I know it. I've done assemble coding for other systems, typically 8080 based SBCs. Having a common tool chain is useful in my case. I recently disassembled the monitor from a Lawrence Livermore Labs 8080 trainer. After cleaning up the disassembled code I'm able to assemble a bit exact copy of the original ROM.
  I did the same for the WOZMON and WOZ 4K BASIC ages ago and modified them (converted to serial I/O) to run on my S-100 system running on a 6502 CPU card. TELEMARK supports the 6502 so it fit into my same tool chain.
  If you decide to use OCTAL be aware SPLIT-OCTAL and OCTAL are different when you get to values greater then 8 bits wide.

In none of what I'm writing am I saying 'this is the best way' or even recommending someone follow my path. What I'm mostly trying to communicate is how the emulator works when it comes to ROMs, jumpers etc.

I'd love to see other approaches, tools etc. This is the best part of this experience, seeing what others have done, figured out or are thinking. That was the very soul of user group meetings back in the day. It's cool that we are finding some of that here.

[donfroula]

This is a very helpful discussion. Thanks for the nice explanation of how boot ROM remapping works! I verified the sequence you explained by single-stepping through various memory map configurations.

Given the information provided, I think I can create a custom memory map and .hex ROM file. I tried the trick of using my TL866CS programmer software to generate the Intel Hex files. It works just fine. I'll try creating a custom setup with a simple program and see if it works.

Best,

Don
K9CLF

[nbreeden2]

Awesome, glad to hear this. :)

[donfroula]

Motorola "hex" files were known as SREC or S-Record files. Assemblers that produced this format were limited to those supporting the Motorola line. Any Intel assembler would be highly unlikely to provide that format as an output file. There are a few Linux command line converters that can move between formats or convert a binary file to Intel Hex.

There are a few variations of Intel Hex that added support for larger address spaces.

[nbreeden2]

Nice, I learn something new everyday.

[donfroula]

With the stock Memory Map 2 selected (configuration "0000 1010 0101 1000"), the first three memory locations on a reset are: 0xC3 (JMP), 0x03, 0xD2

This is a JMP to address 0xD203, which in fact occurs at the next single-step with address LEDs showing that address.

I assume the ROM is being remapped for the first three instructions to a base address of 0x0000, then mapped back to it's normal address for the JMP.

So, the base address of the Memory Map 2 ROM is 0xD200 rather than 0xD800? The memory map configuration for #2 shows the base ROM address at 0xD800.

=================================

[MEMORY 2]

• Memory configuration for running MPU-A ROM and VIO ROM:
• 240 pages RAM, 8 pages ROM (replaces or overlays RAM)
• 8 pages of RAM and 8 pages of ROM for the VIO from 0xf000
  ram 0,0xf0
  rom 0xd8,8,mpu-a-rom.hex
  ram 0xf0,8
  rom 0xf8,8,viofm1.hex
• Start address of the boot ROM
  boot 0xd800

Don

[nbreeden2]

This will be another wall of text, sorry.
As I don't have my IMSAI at hand I can't verify all of this.
I also haven't used the VIO so again, I can't verify all of this, it's based on my working knowledge of the emulator.

First, let's discuss the CPU board as implemented in the emulator.
The MPU-A functionally is identical to the original IMSAI MPU-A board when the clock is set to 2MHz with 8080 processor.
--- You can change the clock to 4MHz and a Z-80 processor BUT these were never a valid configurate for the MPU-A.
The MPU-B option as implemented in the emulation isn't a configuration that shipped and is NOT the MPU-B CPU board IMSAI shipped.

In the official IMSAI MPU-B manual we find the following, it is the only part of the manual that applies to the emulator 'MPU-B'

MPU-B in the emulation is the MPU-A with an extension to add the MPU-B memory mapper. MPU-B is a poor name choice as it's the same name as the IMSAI MPU-B board. Remember, the emulation is NOT a full MPU-B board.
This is the reason the docs state: MPU-B (only with MPU-A ROMs).

The section of the IMSAI MPU-B manual that applies is this:

CONTROL PORT AND SOFTWARE MEMORY CONTROL

The MPU-B control port is a single I/O mapped port address (F3). It is a write-only port and
only two of the eight data bits are active. The two bits control whether group 0 or 1 circuits
appear in the memory space or not. When they are 0, the circuits appear in the memory
when they are 1, the circuits do not appear in the memory space and whatever memory
is installed in the system at that location then appears•

Control port:
Group 0 control: bit 6
BIT 6 = 0 2K ROM appears at 0000-07FF
BIT 6 = 1 System memory (as installed) appears at 0000-07FF

You said - With the stock Memory Map 2 selected (configuration "0000 1010 0101 1000"), the first three memory locations on a reset are: 0xC3 (JMP), 0x03, 0xD2

I don't see the sequence C303D2 in any of the ROMs so I'm not sure what you're reading, this leaves me wondering if you're seeing RAM?
To test if it's seeing RAM try DEPOSITing 0x00 to one or more of the three locations, if it successfully writes you're seeing RAM.

When you enter the NVM setup are you seeing the bits you're expecting? If not the NVM wasn't updated correctly "0000 1010 0101 1000".
Verifying the switch settings.
You said - "0000 1010 0101 1000" which maps too:
0 Halt on power on
0 N/A
0 N/A
0 N/A
1 MPU-B memory mapping with MPU-A ROMs only.
0 [MEMORY 2]
1 [MEMORY 2]
0 [MEMORY 2]
0 CPU Speed bit 6 is used (not running as fast as the emulator can run the virtual CPU)
1 4MHz
0 No undocumented opcodes
1 Z-80 CPU
1 STA Mode
0 No Boot Messages
0 No Boot Messages
0 POST Disabled

From the WebUI can you verify that [MEMORY 2] is configured correctly.
The emulation doesn't need to be running to do this, the CPU halted is fine.
I believe this is done by opening SYS: then one of the glyphs will show the config. If it's not SYS: then it is another icon in the WebUI.
I've added comments below (the "--- " lines won't be in the [MEMORY 2] config).

[MEMORY 2]
Memory configuration for running MPU-A ROM and VIO ROM:
240 pages RAM, 8 pages ROM (replaces or overlays RAM)
8 pages of RAM and 8 pages of ROM for the VIO from 0xf000
ram 0,0xf0
--- RAM from 0x0000 to 0xC7FF
rom 0xd8,8,mpu-a-rom.hex
--- ROM from 0xD800 to 0xDFFF
ram 0xf0,8
--- RAM from 0xF000 to 0xF7FF - The VIO uses this memory block.
rom 0xf8,8,viofm1.hex
--- ROM from 0xF800 to 0xFFFF
Start address of the boot ROM
boot 0xd800

On RESET the ROM "mpu-a-rom.hex" should be mapped at 0x0000 to 0x0FFF - this is what "boot 0xd800" does

On power up while halted can you RESET then EXAMINE (not SINGLE STEP or RUN) 0x0000-0x0007 - I would expect to see this.
I've again had to use "-" as SPACES to keep the columns lined up as the forum messes this up:

; Address 0x0000-0x0003 will remap the ROM mpu-a-rom.hex back to 0xD800 after the 3 CPU cycle delay
; Press RESET, the CPU address is reset to 0000; the ROM at D800 is mapped to 0000 by the RESET signal in hardware.
; EXAMINE 0x0000-0x0006 - Do not RUN or SINGLE STEP
0000---3E---MVI 40-----; Load 40 into the A register
0001---40----------------; This is the BIT 6 mentioned in the MPU-B note memory mapper discussed above
0002---D3---OUT F3-----; Output the A register to port F3 (ROM remap control)
0003---F3
0004---C3---JMP D810---; Jump to address D810
0005---10
0006---D8

If you find these bytes, then the mpu-a-rom.hex file is mapped correctly at RESET

Enter F800 on the address switches the press EXAMINE to read the byte there.
Now EXAMINE (not RUN or SINGLE STEP) the viofm1.hex ROM image at 0xF800 to 0xF807, you should find:
F800 C3
F801 15
F802 F8
F803 C3
F804 7E
F805 F8
F806 C3
F807 E2

If you find these then the VIO ROM is positioned correctly in the memory map.
I leave it as an exercise for the reader to disassembly the VIO ROM.

Let me know what you find.

[donfroula]

I'm curious why single-stepping yields a different result than examining the memory. The single-stepping mechanism on the IMSAI/Sim shows one result while the EXAMINE/EXAMINE NEXT shows another. If the ROM is mapped to 0x000 on a reset, I should be able to see the ROM code and single-step through three instructions before the ROM is mapped back to its normal space, yet this does not happen. I see only what are apparently RAM values. I checked and the RAM values at 0x000 and up (as viewed through single-stepping) change after a power cycle., so they are certainly RAM. I guess the single-step action must disable the ROM remapping somehow.

I checked the memory map using the SYS: widget on the web interface. It shows the following:

This agrees largely with what you said it should be, except the main RAM block shows at 0000H - EFFFH rather than 0000H - 0xC7FF.

Using the EXAMINE switches, I do see the exact initial three instruction remapping and JMP sequence you described. After the JMP instruction if I advance to address 0x0010, I see the same data at 0xD810 (0xC3, 0xAF, 0xDD) that you describe below but still mapped to low memory at 0x0010, as I am not executing the code. I guess at this point RAM is at address 0xD810 if I examine it?

; The ROM is now remapped to D800, the three 8080 cycle delay end here.
D810 C3 JMP DDAF ; We start to boot CPM
D811 AF
D812 DD
DDAF C4 CNZ DD70
DDB0 70 MOVE M,B
DDB1 DD CALL E67E

In the VIO ROM, my address at which the data you mention is found is off by one.

You stated:
F800 15
F801 F8
F802 C3
F803 7E
F804 F8
F805 C3
F806 E2
F807 FB

But I see the same data offset by one address:
F800 C3
F801 15
F802 F8
F803 C3
F804 7E
F805 F8
F806 C3
F807 E2

Interesting exercise.

Best,

Don Froula
K9CLF

[nbreeden2]

I'm curious as well. Sorry about getting the data offset by one, I'm completely working from memory and what I can see in the IMAGE.zip download file.

As I think about the 3 CPU cycles that get injected after the OUT F3 instruction to set the ROM back to D800 I'm now wondering if this doesn't work using SINGLE STEP?

The offset by one was due to me making an error when I copied the HEX values out of the .hex file. :( I'm going to correct it in the earlier post.

[nbreeden2]

An update. I've been discussing this thread with the High Nibble and now have a better but not perfect understanding of how the MPU-B functionality was added to the MPU-A CPU. There are several things that need to be taken into consideration as to how the front panel works when single stepping with the MPU-B ROM memory mapping active before there is a definitive answer as to why there may be issues with displayed data.
The original IMSAI's CPU-A and Front Panel (CPA) use a ribbon cable to directly tie the front panel to the 8080 data pins on the MPU-A. This is how the "instruction injection" to the 8080 occurs to provide the front panel operations such as setting an address, EXAMINE and DEPOSIT.
The 8080 CPU has 8 pins that provide the data bus for it. When writing to memory or a port it outputs the data onto these pins, when reading from memory or a port it reads the data on these same pins. The are known as "bi-directional" because they can both read and write data.
The hardware that connects the 8080s data pins to the S-100 bus breaks these out into 8 pins on the S-100 bus/edge-connector that are labeled DO0 thru DO7. DO is "Data Out" as seen from the 8080 CPU. There are also 8 pins on the S-100 bus/edge-connector labeled DI0 thru DI7. DI is "Data In" as seen by the 8080. There is logic on the CPU-A board that controls the direction of the data and connecting the pins on the S-100 bus to the CPU depending on if it's writing or reading.
In an original IMSAI we ended up with independent DO and DI busses AND the ability to inject instructions/data directly into the MPU-A CPU, this is all a balancing act defined in the design of the hardware. Adding the "MPU-B ROM remapping" to the MPU-A adds a fourth data path independent of the S-100 bus and front panel to get data into the 8080 CPU. Balancing all of this is tricky, adding a fourth data path (MPU-B ROM remapping) makes it even tricker. Based on research it appears IMSAI had intended to add the "MPU-B ROM remapping" to the MPU-A design but never released it.
There will be more to come in the future on all of this.