TheHighNibble
-
|
Hello everyone. I'm experimenting with my new imsai8080 replica. I dont't fully understand the configurations using "mpu-b(a) style bank switched rom" and the associated memory maps. My questions are a bit vague I'm afraid, but I'll try anyway. One of my first questions would be ; where do these ROMs come from ? For example the mpu-a rom ; who wrote them ? Is that an IMSAI product or card ? What was their "real life" equivalent in a real imsai8080 ? In real life, how would that have worked ? Does it just go in 0000H adress space replacing RAM there, and counting on the fact the processor start reading at 0000H ? My second question would be , what is exactly an "mpu-b style bank switching" ; for me "bank switch" usually implies that space is freed - but that doesn't sem to be the case here? What is switched ? Or is it the fact it switches between 256 bytes pages ? All in all, what exactly is that bank switching (that really seems to be at the core and the RAM and ROM system) I hope my question makes sense :) I've edited it multiple times to try to narrow down my question. thanks for your help ! |
Beta Was this translation helpful? Give feedback.
Replies: 8 comments 6 replies
-
|
There is a lot of documentation for the IMSAI. There is no way the High Nibble can summarize it all for you on his website. Google is your friend here. In the MAN: folder on the WebUI desktop you will find a PDF of the original IMSAI manual. There is a lot of good info here. MPU-B is the 8085 version of the IMSAI CPU Board. It supports bank switching, reading that section will help you understand band switching. A google search identifies several sources for the manual. One link is: Bank switching allows different memory blocks to be swapped in and out. On system start the ROM is active on the bus instead of the RAM at the same addresses (0xD800-0xFFFF has ROM active). The ROM contains the code necessary to boot from floppy. As CP/M is started the ROM is disabled and RAM is enabled at the same address space. The code that is in the ROMs was written by IMSAI. If you are trying to deposit into memory while CP/M is running you can't do that. The IMSAI needs to be stopped first. With it stopped you can then examine and deposit values into memory. To deposit at address 0x0000 there are several steps A test: You should end up with: Set A15...A0 to 0s (all down) If you did this correctly the Programmed Input switches now control the Programmed Output LEDs. ================== If you want to manually start CP/M you can do this. Power cycle the system (On the Front Panel PWR OFF then PWR ON) Above you reset the system; examined address 0xD800 setting the start address to 0xD800 then told the CPU to start running at that address. Hope this helps |
Beta Was this translation helpful? Give feedback.
-
|
Hi Neil, Thanks for taking the time to answer me, As I just told to Dave myself, one thing that is fundamentally unclear to me and maybe to other newcomers (which is why I'm putting my question in public) is that the imsai8080 replica, especially in cpm mode, is actually a system with 2 or 3 expansion cards. I believe it's important to understand all that for someone to really understand what they're doing. As much as the stock system is easy to understand (64K no ROM) anything beyond that requires explanations. (Or you're just using cpm and not asking yourself too much questions :) ) And even what I call "stock" is not even stock (ram size). One first element I didn't understand is that you're saying the MPU-B(A) board is actually a replacement of the CPU board, not an expansion card. Does this mean that by "creating" (with the switches in the replica) a system with say a MPU-B style switching but a intel8080 I'm actually spawning a system that had, back in the day, no real life equivalent ? There was no system with both a "stock" 8080 and the bank switching ? I see conflicting information about where the ROM is located ; unless I'm mistaken (which is possible but I just rechecked), I think Dave's doc say that (in the cpm2.2 scenario) ROM is at D800 whereas I seem to remember that in your own doc on your github, for the same NVS switches activated - you said it was at 0000H (which I liked because that explained why I couldn't write on top of it). You clealry say that in cpm mode with cpm rom, rom goes at 0000H. (page 2 of Switch Settings-V6.1.pdf ) Taking the ROMs out of the way for a moment ; the processor has to start somewhere ; does it start reading at 0000H or D800H ? I was able to write (key in) software by starting at 0000H (just as you did above) so I would say that the processor starts reading there, at address zero. So how does it accept a ROM located at D800 ? What makes it jump there if there are no instructions at 0000H ? Altough I'd like to be sure of where the ROM actually is in that scenario - you're confirming that the switching is indeed freeing up space, so after bootstrapping, the system is seen as having 64KB of RAM again. I'll read the PDF you're linking to know more. I still hope and believe my message will help someone with the same doubts in the future, |
Beta Was this translation helpful? Give feedback.
-
|
Googling myself on the topic, I seem to have dug out the topic of "RST vector, interrupts", and the likes, and it also seem another chip than the 8080A is involved to explain why the cpu suddenly jumps some place else than 0000H (which is as I expected the stock bootstrap address for a 8080 and 8085, according to chatgpt). I imagine that the explanation is something like "the mpu B board has this or that chip working along with the 8085, inserting this other card in the S100 bus does this and that which triggers a new bootstrap address in place of 0000H, executing the ROM code". And the ROM we're all talking about was physically located on the MPU-B(a) board. Something like that :) Again the imsai8080 replica makes the user believe all that is easy - but switching from the 8080 with just RAM to the cpm with ROM and floppy would physically mean, back in the day, removing all the guts of the poor thing and switching boards. So really, I believe we're talking about two entirely different things when we switch from "full RAM 8080" to "ROM reading capable MPU-B". |
Beta Was this translation helpful? Give feedback.
-
|
I am replying with my current understanding of how the emulation works. Dave and or Udo may correct so look for that. You are correct the emulation is of a system with various cards installed. At the minimum in this config is the CPU, RAM cards, ROM card, I/O card and floppy controller card. Note that the ROM could be implemented on its own card or on the CPU card. Both were valid configurations. For the emulation it implements MPU-B bank switching however it doesn't emulate the 8085 CPU from that card. Some 3rd party CPU cards implemented MPU-B bank switching with a different CPU on the card. Sorry the docs differ. Let me try to explain - all values are in HEX: The 8080/Z-80 upon reset sets the PROGRAM COUNTER to 0000, Fetches the byte there and executes it. ROMs however in the IMSAI are in upper memory. So how can this work? Upon a power cycle or EXT.CLR of the system the memory map ends up looking as follows: MPU-A ROM at D800 So, a read from address 0x0000 will actually read the byte at 0xD800 and will get the first byte from the ROM. Let's look at the beginning of the boot ROM in its physical location (all values are in HEX): D800 3E LD A,40 After a power cycle or EXT.CLR the bank switching has the ROM active in the address space at D800 0000 3E LD A,40 Notice that these are identical to the contents at D800, this is because we are actually reading from D800 (the physical ROM). The hardware in the IMSAI is remapping 00xx to D8xx (shadows the ROM at 00xx), the CPU has no idea this is happening. The emulation faithfully emulates this behavior. What happens at system start looks like this. Notice where the address changes from 0006 to D810, this is where we moved from the shadow ROM to the physical ROM. 0000 3E LD A,40 ; Load the A register with 40 Now that we are running from the ROM (physical addresses D8xx) the code (or potentially hardware) will take care of disabling the shadow ROM so that RAM will occupy the 0000 block address space. From here the ROM proceeds to initialize the system then to boot CPM. Hope some of this makes sense? |
Beta Was this translation helpful? Give feedback.
-
|
It should be noted there were several ways to get an S100 machine booting from a ROM in high memory. |
Beta Was this translation helpful? Give feedback.
-
|
In my "Boot Switch Settings - V4.x.PDF" I can see the ROM settings aren't really clear. Let me try to explain. In the ROM matrix in the PDF you will see this: The first 8 rows have to do with ROMs that are meant to be at address 0000H and would map those ROM into the system at address 0000H. These are NOT the IMSAI ROMs such as "mpu-a-rom.hex" and "mpu-a-vio-rom.hex" The next 8 rows have to do with the IMSAI ROMs such as "mpu-a-rom.hex" and "mpu-a-vio-rom.hex". In the diagram it states "ROM ADDR" which is meant to convey the actual address for the ROM. If you look at the CFG:->[MEMORY xx] section you can see how the ROM is mapped into the system (this is described in some detail below). With this hopefully understood lets move on to how the emulation is configured. I am assuming [MEMORY 1] as the memory map below. The Memory Map is set via the front panel switches as described on the High Nibbles web page at the URL in the summary section of this post. Looking at the 3 arrows to the right you see "Down Down Up" or "0 0 1" which in binary is 1. This is how the emulation knows what [MEMORY xx] map to use, in this case [MEMORY 1] Your system may use [MEMORY 2] so it will look a little different from what I show below. [MEMORY 2] has a 2nd ROM loaded. In the WebUI open SYS: - You will see a Memory Map section, mine looks like: Looking at this you can see the ROM that is loaded and its address range. If there was a 2nd ROM to be loaded you would also see it listed here. From the SYS: Window click the little [*] gear icon in the upper right. The CFG: window will open. In this window select "system.conf" and scroll down. You will find a section under [MEMORY 1] which looks like this (Using this one is set by the configuration word bits I just described above): What do these lines mean? Lets open "mpu-a-rom.hex" in a text editor; you will see rows of data like this: This format is what's known as an "INTEL HEX FILE" format. Google for more info. Let me break it down quickly. The first row can be broken out like this, it is all in HEX: You can ignore the 1st part ":20" In a previous message I listed the first few bytes we should find in the ROM: If you compare the addresses in this and the data values in the HEX file you will see it matches. And in the WebUI in the SYS: , CFG: and "system.conf" sections you'll see some of this data as well. The emulation based on the settings described above will open up the HEX file "mpu-a-rom.hex" and will parse the contents. it will create a virtual ROM in the emulation starting at address D800H and will load the data into it. All of the setting described above are how the emulation knows to load this file. It will know this is a bankable ROM and cam be shadowed (PHANTOMed) to address 0000H In summary: The 4 bits in the ROM section of the configuration word determine which [MEMORY MAP] in SYS:->CFG:->[MEMORY xx] to use. The "Memory Map" section in SYS: makes this easier to read as it's in a more human readable form. Yeah, it's a lot to take in. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @nbreeden2 ; Thanks for taking the time, Most of what you say is clear to me and if that's any relief I do have some experience with low level operation of CPUs, altough it's the first time I really try to dig into areas I've usually avoided. It seems those early computers basically fought with the fact all the Intel reset vectors (RST0-RST7) where very low in the address space, whereas certain software (you talk about cpm; maybe others ?) expect the lower space to be free. One last question ; the "shadowing" has to stop at some stage ; who does that , how and when ? Can this be reversed (the shadowing be put back) ? |
Beta Was this translation helpful? Give feedback.
-
|
There is a typo in the example code in the previous replies. I'm indicating a jump to D880 in some places when it actually is jumping to D810. Bank Switching / Shadow ROM are often controlled by bits on one or more I/O ports. I found this info for the MPU-B bank switching: A RESET will set the CPU to a knows state and start execution at 0000. With CPM loaded this becomes a soft start. In this state the Shadow isn't active. You can use the front panel to watch all this happen. This is how I actually determined there was Shadow ROM happening. I could examine the bytes at D800, looked for them at 0000 and found them there. I then booted CPM and STOPed the machine. From the front panel I could see that the bytes at D800 and 0000 were different which indicated the ROM had been switched out of the active address space. RESET didn't bring the ROM back onto the bus, RESET/RUN does a soft boot for CPM so this made sense. EXT.CLR however brought the ROM back into the address space and again I could see the ROM shadowed at 0000. EXT.CLR is External Clear so this makes sense to me. I then single stepped using the front panel to watch the code in ROM execute and could see when the address bus changed from 0006 to D810. Reset isn't the same as RST 0. Resetting the 8080/Z-80 results in getting the CPU back to a known state, fetching the instruction as address 0000 and executing it. RST 0 has a vector address in RAM. In the event of a RST 0 interrupt the system jumps to whatever address the RST 0 vector points at (where the handler is at). At https://obsolescence.wixsite.com/obsolescence/cpm-internals there is a decent description of how CPM boots, it doesn't 100% follow how I believe the IMSAI works but is very close. The CPM boot process will take care of setting up the RST vectors as needed. Debug typically uses RST 7. The other vectors are open for other uses. Some hardware might generate an interrupt when a byte is received on the UART, the particular build of CPM will need to be setup the interrupt vector. I don't believe the emulation as configured uses interrupts, instead polling is used to check for a byte received in the UART. Note that CPM is customized for different hardware, you have to write a BIOS for your specific hardware. CPM makes standard calls for disk I/O, serial I/O etc. There is a section in the CPM manuals that gets into how to write the BIOS. The code isn't really killing itself as you said. The emulation takes care of enabling shadow on power up or EXT.CLR. When the OUT to F3 happens the emulation or original hardware knows the code wants to disable the shadow function and does what it needs too to disable shadow. My guess is with Shadowing enabled the hardware (or emulated hardware) is adding D800 (probably ORing it) to the address the processor is asking for. Net result is the CPU asking for 0000, hardware adds D800, so the resulting address is D800. The CPU has no idea this is happening. When the out F3 occurs there looks to be a sequence the hardware uses to stop adding the D800 offset. Again the CPU has no idea this is happening. The net result is a clean handoff to the ROM at D800, the CPM boot loader being loaded into RAM then executed and CPM come up. As CPM starts it initializes memory as needed such as setting up the reset vectors, setting up UARTs etc. To close the loop here: Once the shadow function is disabled we now have ROM at D800 and RAM from 0000...D7FF. The code in the ROM reads the CPM boot loader from the floppy (drive 0, track zero, sector 0) someplace into RAM and passes control to it. This code most likely does the out F3 sequence to then disable to ROM resulting in RAM from 0000...FFFF (bank switches the ROM bank out / the RAM back in). The boot loader code then proceeds to bring CPM up. It's very possible I have some of the details wrong here but the sequence is going to result in a flow like I laid out above. You asked how to enable shadow, the MPU-B manual covers this. This also give insight into how port F3 controls shadowing. In this document Later on we find: So, we come back to the code: We see the out F3 at address 0002/0003 - this starts the control command to disable the shadow so RAM will be in low memory. |
Beta Was this translation helpful? Give feedback.
-
Just a nitpick about the RST description above. There is no vector in RAM for a RST instruction. The CPU instead performs the equivalent of a CALL instruction - but the address that is called is deciphered from the instruction op-code bits 5..3 (see below).
Tony |
Beta Was this translation helpful? Give feedback.
-
|
Tony is correct here. My description was misleading. There are probably more issues in all I wrote as most of it was written from memory. |
Beta Was this translation helpful? Give feedback.
-
|
Which might also be an explanation about why CP/M insists on using the lower memory, which is a bit the start of every problem about bootstrapping from power off state. We have a CPU hardwired to start at 0000h, but needs just a few bytes above that to be empty and respected for the RST1-7 to be able to operate. Which makes it necessary to bootstrap from 0000 (shadowing) but also to "not be there anymore" at the soonest. With all the "vectors" (okay they are not vectors) beeing actually hardwired in the CPU in the low memory space, any application is kind forced to free up that space (and use it) if it ever wants to use RST at all. Which explains the convoluted memory allocation of the first bytes. I'm probably looking at this with newcomer eyes and there is complexity I don't even know about, but it just seems the entire bootstrapping problem could have been avoided if the RST "vectors" would be at the opposite side of RAM (highest bytes) - and you just fill up the ram with NOP at boot time. You then put your rom/boostrap anywhere and remove it/NOP it once read. But then again the cpu would need to know how much ram is installed. Each time I try to think of a better way to do what they did, with the specs beeing what they are, I really end up finding that the solution they came up with is actually the best... I want to thank @nbreeden2 Neil (and others) for taking the time, and I think anyone who owns one of our kits should spend some time reading this to understand the basics of the system . You don't build on sand. It is I think very important, if you're really into this system, that all of this boot process is crystal clear for you. You're not writing novels Neil, you give everyone a bit of your wisdom and it'll be saved under a Norwegian mountain for centuries. |
Beta Was this translation helpful? Give feedback.
-
|
This is all very interesting, Something that is important, I think, is that CP/M is really meant to be cross platform, so it provides a basic set of operations on various hardware. So it's more a driver than a ROM in the sense of Apple II roms for example, that are providing their own BIOS for hardware that never changes. So you end up with this convoluted process to load a platform agnostic driver in RAM from within a hardware agnostic platform, able to use ROM or not, located at misc places and misc sizes, that can bootstrap software thru misc medias, and then disappear. Your CPM PDF also talks about the currently selected drive byte, that should be something very easy to show with the CP-A panel and would make a great demonstration (for students, etc) of the CPA while running CP/M. |
Beta Was this translation helpful? Give feedback.
-
|
Windows implements a HAL *Hardware Abstraction Layer" and relies on the BIOS to bridge the gap between how Windows thinks the hardware should look and how it actually looks.
The CPM Programmers Manual lists the functions CPM needs to run and how to call them. The CPM Alteration Manual covers how to write 'drivers' that implement these functions. An example: CPM is built for the amount of memory you have installed. If you add or take away RAM CPM itself needs to be modified to know how much RAM the system has. CPM needs to run in as little as 20K RAM though the minimum suggested is typically 48K. This means code like that to automatically determine the amount of installed memory is a luxury it can't afford. The process to change CPM is interesting in that I can use my bootable CPM floppy in A: to modify CPM then write the modified version to another floppy such as the B: drive without changing CPM on the A: floppy. This is what allows you to customize CPM for another system or for a change in your system. If you were replacing the RS232 card with one that used a different UART you might need to customize CPM for that new card. If you were writing a BIOS for another system with different hardware I could use this process on my system to create a working CPM it. On the CPM floppy in the A; drive you will see SYSGEN60 and SYSGEN64. These are literally used to update CPM for 60K and 64K RAM. There is a manual process that uses these. You will also find BIOS.ASM, the assembler source for the BIOS on the A: floppy. There are other BIOS.* files as well including BIOS.PRN which is the assembler output most likely for the current BIOS being used by CPM booted from that floppy. If you want to understand how floppy drives are implemented the code is here. The CPM Alteration Guide will help you understand it. Note: It is possible to assemble the BIOS but never link it so the BIOS source and lasting file may not match what CPM is running. While running CPM open LPT: in the WebUI. A new TAB will open in the browser that represents a printer. On the TTY: it should look like: While PIP is running open the new TAB and you can see the BIOS.PRN file being printed. How LPT: is implemented in CPM is in the BIOS. Search PRINTER or LPTST or LPTOUT in the printer output tab. At the * prompt in PIP press enter to exit PIP. Remember that with CPM running the IMSAIs front panel address and data switches are locked out. Only the control switches are active. This was also true on the original IMSAI. To look at memory contents you would need to stop CPM. Then you could use EXAMINE to look at particular memory addresses. however....... So, no, IMO there is no 'easy' way to demonstrate what you mentioned above. Digital Research (who wrote CPM) envisioned an open hardware world. From what I can determine ALTAIR was about getting the thing running in the base configuration they sold. There were few to no considerations for an OS. The system was meant to be controlled via the front panel. IMSAI looks to have followed the same course. Eventually floppy then hard drives became within reach of the home hobbyist and there was CPM, configurable across many platforms. There were MANY other OSes. One OS expected the user to keep track of what tracks on the floppy were used for what on paper. Literally write down that the life program in on track 17. A simple editor is on 23 etc. etc. etc. BASIC with I/O extensions (cload/csave) were used as OSes. Eventually load/save were added to save to a floppy. OSes like this BASIC example were written for a very specific set of hardware and typically weren't customizable. There is lots of other stuff that happened in the S-100 world back in the day as well that predated the floppy drive era. All of these were available on the IMSAI.
For paper tape the user often had to toggle a loader into memory then execute it to load the program off of tape. There was typically no ROM in these systems, this is why the front panel existed in the first place. On my PDP8 there was no ROM. I have to manually enter the IPL (Initial Program Loader) in via front panel. This was just smart enough to load a more sophisticated loader from a floppy. This loader then gets ran and the OS is loaded into memory. This is a lot like the CPM loader only the IPL portion in the emulation is in the Boot ROM. If you look at video or photos of old systems there is often a paper taped to the front of the machine. Often it had the listing for the IPL to make it easier to enter via the front panel. If you want to see an example of an early software monitor you can view one on my YouTube channel I'm know for writing novels, sorry for all this being so darn long. Also sorry for drifting so far off target. -Neil |
Beta Was this translation helpful? Give feedback.
-
|
Wow! Nice explanation! Thank You |
Beta Was this translation helpful? Give feedback.
There is a typo in the example code in the previous replies. I'm indicating a jump to D880 in some places when it actually is jumping to D810.
Bank Switching / Shadow ROM are often controlled by bits on one or more I/O ports. I found this info for the MPU-B bank switching:
The address ranges that may be occupied by the MPU-B are 2K at 0000 or 4K at D000. The control I/O port is at F3.
If you look art the code snippets in my previous posts we can see an OUT to port F3 in the ROM.
A RESET will set the CPU to a knows state and start execution at 0000. With CPM loaded this becomes a soft start. In this state the Shadow isn't active.
The EXT.CLR front panel switch resets the IMSAI back to shad…