Bill Beech and recent work on Intel 80/10 & ISIS system

Last edit July 15 2012 (c) Herb Johnson

Introduction

[Bill Beech NJ7P contacted me in June 2009 to exchange manuals and resources about our Intel System 310 Multibus systems. We've talked about a number of Multibus 8080 and 8088 subjects. See the linked Web for links to all those activities, and about Bill and his other work on the Web.

We also discussed at that time, how to emulate and run Intel's 8080-based ISIS OS. Later on, Bill obtained an Intel 80/10 8080 CPU board, and decided to build an ISIS system around it. This Web page is about our ongoing discussions of his 80/10 and ISIS and CP/M. My half of the conversation is in italics, some embedded comments of mine are in []'s. Bill also produced a Web page about his 80/10 and related systems and the software tools he's built.

- Herb Johnson

JUne 2009: disk images, assemblers

Working right now on a pubic domain assembler for 8048/8051/8085/z80 that I built for the N8VEM computer group. [See our "tools" discussion Web page for details. - herb]

Dec 28 2009: I want to bring up the emulation of an intel 310 on the SIMH group. So far, all their machines are single processor. Have been through [Udo Munk's Z80PACK] stuff and I have written an SWTP 6800 emulator in SIMH. Should be in the next release. I want to explore the tcpip entry as it is a clean way to get vt-100 emulation.

I have looked at the catweasel stuff and the [Intel ISIS and software] disk images on bitsavers.org and now understand them. They are simply full track reads from index hole to index hole. I suspect using a track write would restore the image to the 360 kb 5 1/4 inch disks. Now I need to find a source of 5 1/4 inch DD disks.... Looks like we will need a bunch and I don't have a stash of them.

[D]iscussions of the "catweasel stuff" seems to trip over the same issues. [I covered how the ISIS disk images were created, on this Web page. - herb] Look. The catweasel hardware reads flux changes. That's a fact. But catweasel SOFTWARE can interpret that binary stream in any number of ways, to create disk images (or files) any way the programmer decides to do. My understanding of the recent ISIS image files, is that [the sectors] are in the same order as an ISIS-II program running on an ISIS system would "read" the diskette [them], as a bunch of files plus boot track plus directory sectors.

This is true. If I can find the right ROM image, I could boot up those disks on hardware or the altair 8080 emulator.

SOme [disk images] may be 8080-based, some may be 8086. Udo Munk includes an old ISIS-II 8080 emulator which runs under his CP/M-80 emulator. He uses it to run Intel's native products like PL/M. It does not emulate ISIS file structures, it reads and runs ISIS programs under CP/M.

Otherwise, I suppose you could "boot" the ISIS system disk, once you emulate the floppy controller to read the image files and assume no interleave. Simpler, would be to break up the disk image into actual files in a directory, and only emulate the hardware to execute the programs - an ISIS-II emulator more in the generic CP/M emulator tradition (and the ISIS CP/M emulator I believe). In between would be to "run" ISIS the OS, but write your own BIOS to support whatever hardware you run it on. - Herb

[PS in Jan 2011 I wrote: There's a Unix ISIS emulator now available; and a disassembly of the CP/M ISIS emulator. Check my 2011 S-100 Web pointers for descriptions and links. - Herb]

May 2010 and 80/10 CPU board

Herb, I bought a "working" iSBC 80/10 off eBay a couple of weeks ago. I have it working with an iSBC 032/048/064 memory card. I have an iSBC 208 floppy controller to add to it [with Intel 8272 FDC + 8237 DMA chips]. That fills the three-slot multibus cage that I have. Going to try and get ISIS-II and CPM to work with it. Unfortunately, using a PC switching PS to run it. The multibus backplane has a -5v regulator from the -12. -5 is used on the 80/10 for the CPU and the 2708's. RS-232 uses the -12 and works fine under the current configuration.

Going to make a reversible mod on the CPU to use one 2732 versus 4 2708's. Also, I need to be able to switch the ROMS out of the memory map once it boots so I have R/W memory through the full 64KB of memory.

Nothing wrong with these changes. You need not disable the ROMS, just accept a smaller RAM space. Why not just use a few K of ROM at the very top, and leave it in? That's enough for a bootstrap and a ROM monitor also. Later on, you can use an I/O bit to switch ROM and RAM, just be sure to be running from RAM when you do that!

The ROM is addressed low (0000-0FFFH). It would require major changes to the board to readdress. What I will do is have it stay low, will boot from 0000H, and have the ROM copy the monitor image to 0FC00H, jump there, and then disable the ROM. This can be done with just a few connections and no board changes.

I imagine the board is designed to disable ROM as you noted. I have not worked with the 80/10 in some time. It's reasonable for it to start with ROM at 0H and then disable it later, if reset forces the CPU to run from 0H. Of course your copied "monitor image" must have been assembled to run at FC00H. For development you could assemble your monitor twice, once also at 0000H and run on monitor without transfer. Then you can verify your copy and transfer and always "fall back" without reset, until you have confirmed your work.

Actually, it does not have the capability to disable the ROM or RAM. It is easy to use a couple of bits out of the two 8255's to perform the task. I have a bunch of Zendex 8085 SBC boards which are a newer design. They use more modern ROMs and I suspect they allow the ROM to be moved high once it boots. I have to draw a schematic and thankfully, they are double sided PC boards. Yet another task.

Suggestion: use the low ROM monitor to run some memory tests, make sure that RAM card doesn't have soft bit errors. 8080 code for testing RAM is around in old CP/M archives. I find memory chips get "soft" with age, and yours are among the oldest.

This is first on the list. I actually have two of the 64K boards and a bunch of 512/1024/2048/4096 KB memory cards. Even have a few EX cards that are error correcting. Don't know but suspect they should work fine in an 8-bit system. I can test these as I get this working better and perhaps get an 88/45 or 286/10 working.

I am back bringing up an OS without having it all figured out beforehand. I am going to use 3.5 inch drives and stay with the 512 byte sectors. Don't know whether I will use 720KB or 1.44 MB.

Look carefully at the 208 controller. and look at whatever 3.5 inch drive you use. You probably want drives which will run at two speeds of rotation to support DD and HD. Otherwise you will need to set the drives at ONE speed and run DD only. I doubt you want to use the IBM method of changing DATA speeds instead of rotation speeds. (if this makes no sense, do some homework on these issues, check my Web pages [on 3.5 and 5.25 inch drive speeds and densities].

Reread your Web pages and see there is really no clear path. I think I will stay with 3.5 inch drive and build on the knowledge I got from working on the 8272 non-dma driver for the N8VEM. I have the scope and logic analyzer to fall back upon if I get into a bind.

I might make the initial disk drive a 5 1/4 DSDD drive just to make this a bit easier. There should be no problem with that. The N8VEM has problems with the SD disk controller and the 1.44 drives. I believe I have a disk emulator that would make this a whole lot easier....Bill

A 5.25" 360K drive would be contemporary with the 80/10. The head will have a wider track than a 1.2M drive used as 360K, which improves reading old diskettes. Otherwise use the 1.2M drive but be SURE it is running at the correct rotation speed for 360K operation, and be sure to "double step" for 40 tracks. I have not followed the N8VEM [project] in any detail.

The "problems" with SD vary because so much technology has changed since SD was in common use. It's not easy to "solve" because modern chips and drives have all but abandoned single-density work, and so one has to very carefully know how each piece - drive, controller, data density scheme - operate.

This is true. [In 1980 I had] finally standardized on track 0 head 0 as sd, and all the rest DD for my S-100 CPM and CPM-86 systems. I placed a copy of the disk DPB at the start of track 0, sector 4, as an identity sector. I reconfigured the bios based on the ID. Allowed me to have up to 1.2 MB on a DSDD 8" disk. Now I can only read them on the S-100 systems, as none of the PC controllers I have here will do SD. And I have tested more than 20 of them, including the old discrete data separators, with [Dunfield's] test routines.

Well, those test routines are from whomever contributed them. Dave Dunfield has some nice diskette support software too. He has accumulated a list of PC's floppy controllers and their format support, based on reports from use of his tools. Check his classicmp Web pages (Google will find them) for more about that, or follow my pointers to him.

My impression is that some people have chosen specific floppy drive brands and models, and specific FDC chips, and established how to make those work. Some of that is discussed on my Web site, but I try to work on providing FUNDAMENTAL information so that others know what the issues are.

That's the best information to provide. It is better to understand the underlying problem than just provide a quick fix. And remember, this is supposed to be fun!

Well, there's any number of "fixes" or "solutions" that people put together. And then, someone else says "that won't work for me, I do *this*...." (as you have for instance). I decided that there was not a Web site for the fundamental information, so I accumulated that information, while pointing with Web links to other people's solutions.

[As for SD for the boot tracks and DD for the rest,] I frankly don't care for that solution. that means any other hardware or software trying to read your diskettes, will "see" the SD track and "decide" you have SD disks, and then trip when the next track is not SD. Or, vice versa. And it means a unique format program, no [post-1980] formatting program will create mixed SD/DD diskettes. So I don't know what this "solves", you are welcome to tell me.

Well, in 1980 as I defended your rights in Korea, I thought this was a great idea. My machines could tell a 3740 disk from mine by the contents of the ID sector. All 0E5H meant 3740. Otherwise, the DPB was there and the system handled any sort of DD disk format I could build a DPB for (and write a formatter for it). I had Byte and PC magazine and not a hell of a lot else to glean information from (i.e. I worked in a vacuum). And Compupro used this same solution so I thought I had it right. I left Korea that time in 1984. 30 years of hind sight have proven I should have never make that track SD. But the idea of an identity sector is still a good idea if you have many different format DD disks.

OK, I thought you made that decision RECENTLY! I agree with you, some kind of "identity sector" is useful, I've seen various implementations of that. Sometimes it's the first bytes of the first sector.

Further progress on the 80/10

May 2010: Herb, Here is some early documentation of my iSBC 80/10 adventure. [Since updated - Herb]

I will keep the identity sector but just make the entire disk DD. I can write a simple program to correct the 8-inch disks on the Compupro S-100 system when I get back to playing with it again. I have the Compupro, the Dell 2650 (which hosts mane virtual machines - cut my power bill way down), the Intel 310, the iSBC 80/10 and the N8VEM all in one relay rack here in my radio room.

I did not document my findings - all I had were DD DD only. I am still on the hunt for a board that will do SD and DD for the PC. I still have operational machines on the network here with ISA bus. The hunt continues.

July 9th 2010

Herb, Added to the write up on the iSBC 80/10. I got an EPROM adapter built for 27C256 EPROMs. Over kill for a 2708 replacement, but I have a bunch of them here, so I used them! I am running into problems making the EPROM address space go away under program control. It is a bit more complicated than I initially thought. I know what line(s) need to go away for the external RAM to appear in the memory map, but have to figure out the easiest way to make it happen. I am running a monitor of my own design on the board, now.

Aug 2010: The Multibus is still on the bench. I have modified the board to individually switch out the onboard ROM and RAM. I am at the point of writing a loader to copy the monitor into high RAM jump to it, so the monitor can switch out the ROM and RAM.

I have a DSDD 8" drive to connect to the controller to start getting an OS running on it. I will start with ISIS-II. Good on posting some of the discussion on [your] Web site. I need to update my page as well. - Bill

In Sept 2010

The Multibus is still on the bench. I have modified the board to individually switch out the onboard ROM and RAM. I am at the point of writing a loader to copy the monitor into high RAM jump to it, so the monitor can switch out the ROM and RAM.

I have a DSDD 8" drive to connect to the controller to start getting an OS running on it. I will start with ISIS-II.

2011

Jan 2011: Herb, I have the 80/10 working with the hardware to disable the onboard RAM and ROM. I also have a SIMH emulator working to emulate this system. Working on emulating the iSBC208 floppy controller board. So slow progress is being made.

I also scored an iSB86/12A board off eBay last week. At least we have the manuals for that one! ROMs are unique to the original user.

Sure would like to find a copy of the Intel Relocatable Object Module Formats for the 8085! [That is, the] ISIS PLM compiler and ASM80 output relocatable object code in the version 4 format. [See our "tools" discussion Web page for more discussion of OMF. - herb]

I might add I have a double sided double density 8-inch floppy disk drive to start with on the iSBC208. It just looks easier to go with a drive it is designed for before fighting with the 3.5-inch drives. I have a lot of good 8-inch floppies to use, so that is no problem. I have about half the iSBC208 emulator working under SIMH. I will bring up CP/M first. Simple to write a BIOS for the iSBC208.

Will let you know when I have CP/M and ISIS-II up on the emulator and on the hardware. The ISIS-II code I have is for an older board so the I/O will have to be changed to work on the 208 controller.

I have disassembled the isis.t0 (booter) and isis.bin programs from ISIS-II V4.1. They are built to use the old two-board floppy disk controller or one with the 8271 controller. As I said, I have gotten pretty good at writing PLM from the disassembly. Almost all of ISIS was written in PLM. I need the source code to modify for the iSBC208 and later the iSBC214. The 214 is a combination of the iSBC215G, iSBX207 and iSBX208. I have several of them and they are direct replacements (no code change) for the three boards. So very slow progress on this. - Bill

I have powered up the 310 occasionally, to check the connectivity through the terminal server. I want to get the 80/10 and emulator completed, then attack the 88/45 and 188/48 boards. I'll need to create emulators for the 8088, 8086, 80188 and 80186 to get that stuff working as I like. I found the 8086 emulator for the Altair 8800, but I prefer to roll my own.

Later, Bill wrote: "What hardware reference manuals do you have there that aren't on the network? I am looking for the iSBC215G, the iSB214, iSBC88/45 and the iSBC188/48. I bought the iSBC86/12A off eBay because the manual was on Bitsavers. It is much easier to get one of these machines up if you have the hardware reference manual!"

[I found an Intel manual index which told me:

144780        iSBC 215G Winchester Disk Controller Hardware Reference  Manual
134910-002    iSBC 214 Peripheral Controller Subsystem Hardware Reference Manual
143824        iSBC 88/45 Advanced Data Communications Processor Board Hardware Reference Manual
138079-002    iSXM 188/48 Installation Manual
174345-002    iMDDX/300 Diagnostic Software iSBC 188/48 Advanced Communicating Computer Test Reference Manual

My list of Intel Multibus manuals is on my Intel Multibus Web page. I think it's complete. Some manuals I had are listed on this Web page. But I don't have what you have asked for. - Herb]

Bill replied: "I have been looking for more manuals all the time. There have got to be more of them out there somewhere. I sure wish I had kept the ones we had at work.... We had HRMs on every board we used. Intel provided us with new stuff as it came out for the 310/320. Not a lot of the earlier stuff.... Hindsight is 20/20.."

"I appreciate all the help you have provided. You have turned up some things that I had not found. [The Web] is a very dynamic world. I redo searches every few months in case a new document has been added to the web. I have been impressed with the work Al [Kossow of bitsavers.org] has done, and try to keep him fed with manuals I have that he is missing as he seems to be the central repository."

[I (Herb) said: Now you see why I'm trying to show, on my Web site, there's still interest in this technology, about this era. Someone else who has other Intel manuals, will search the Web and see your request, with any luck. (I also dicussed with Bill where he might get more manuals, places I've mentioned on my Intel/Multibus Web pages. - Herb ]

May 2011: "I have made progress on the iSBC80/10, iSBC064 and iSBC208. The emulator I wrote is actually booting to CPM. Not working completely right, but close. I am to the point of trying to run the code on the actual hardware. I am having a problem being "one" with the 8272. I did not like the i8272 code from the Altair emulator, so I wrote my own. I am using the software driver from the iSBC208 manual so I know that code is solid."

Sept 2011: "I have burned my latest EPROM monitor for the real hardware. I have added the iSBC-208 controller and two each TEAC FD55BR DS/DD 360K 5.25 inch floppies to the controller. I am able to home and seek both drives as well as turn on and off the motors. I am currently figuring out how the head load should work. Then I should be able to get the drives to read and write.

"I have the code for the 8-bit driver in a file that does assemble with my assembler. I used a lot of it in my monitor ROM. In my emulator, the monitor actually reads in all of CP/M. On the real hardware, it hangs.... I suspect the 8-bit driver is geared for 8-inch drives which have control differences from the 5-inch drive, as you well know. I believe I will need to make a couple of small modifications to the ROM code to get the hardware to at least read the some of the disk.

"Now my quandary is whether to build a CP/M system that uses the standard DOS 40 track, 9 sector, 512 byte format or revert to something else. I was thinking of having the CP/M image as an actual "first" file in the file system, and a boot loader that would load it in. I could them have only one reserved track on a disk.... Completely non-standard but then what is standard for this stuff? "

Actually, Digital Research provided with CP/M 2.2, sample BIOS code for Intel MDS-800 Multibus system. But floppy controller BIOS's are tricky, there's many ways to try to capture the bits from the floppy at high speed for a 2MHZ 8080 processor. This Web link is to a page with many code samples and discussion for another floppy controller and an 8080. - Herb

"The MDS-800 used the old two-board discrete controller, I believe. Intel also produced i8271-based controllers (I believe they were the iSBC-202 and -204). The iSBC-208 uses the i8272. The problem may lie with the multibus DMA implementation versus the iSBC-80/10 processor board. It does not contain the bus arbiter that other boards had, so I may run into problems interfacing the new controller with the older processor board. That is what 'scopes and logic analysers are mad for."

Related issue: "Here is another quandary. We always need a way to load initial software into these old systems. If we don't have a disk-compatible system, we need to upload executable code to the hardware. I usually use an older terminal server to provide the serial connection to the hardware. I have a load function to load a hex image into the hardware memory."

" But currently, on the iSBC-80/10, every other line of the hex file loads. I am over running the serial input of the iSBC. In mon80e, I even tried to implement an xmodem receiver. I am debugging it as we speak. But there aren't many telnet programs that provide xmodem transfer (TeraTerm Pro does). I need to find a way to be able to load and store binary images on these old systems that is target platform independent. Any ideas?"

Bill and I discussed his hex loader, and I made the point that it's an important resource. He looked harder at the code to improve efficiency, and got it to run at 9600 baud without complications. - Herb

later in Sept 2011: "Great progress today. The iSBC-208 [floppy controller] driver is interrupt driven. I finally put the 'scope on the multibus interrupt line that was being used [and found the problem]."

"I saw interrupts from the 8272 where I expected to see them, when the chip initialized. But something keep the processor calling the interrupt handler while the multibus line was NOT active. Dug into the CPU card and found that there was a jumper from the 8251 for receive interrupt. Once a character was sent, it held the CPU interrupt line active. Switched the jumper to disable the 8251 receive interrupt and the disk exerciser now will step and home each drive using the driver from the iSBC-208 hardware manual. Next step is to get the software to read an actual sector off the drive."

Floppy operations on the 80/10

by early November Bill said: "Currently, the 3-slot chassis contains the 80/10, 064 and the 208. .....The failure is my trying to cobble the Intel iSBC208 [floppy controller] and the 80/10 and make them work together. I had to make one wire change on the back of the multibus [System 310] frame. There is probably another or a jumper change still missing.... I know for sure no actual DMA transfer takes place as I don't get any data in the buffer."

Not long after that email, he added "I can now reliably read from either of the drives on the iSBC208. I had been turning the motor off too soon after a read, and the drive remained selected and the FDC busy waiting, perhaps for the index hole again. So I need to implement a timer to turn off the motor. Now to see what I can do about building CPM80 disks. The Kaypro is still out in a shed. The wind is blowing like mad and I don't want to mess with the shed while it blows."

[Herb said: For a proper BIOS and BOOT and FORMAT for that controller, you might look at some CP/M code for a S-100 controller with the same floppy "chip" - presumably it's Intel's..... Once you have CP/M-80 running, you'll be able to test other code and formatting." - Herb]

"I have a lot of experience with CPM-80 and CPM-86. Most of it was gained with my S-100 bus system and running CPM-80 and CPM-86 on it (8085/8088 CPU card). I am going to retain the "native" 512 byte sectors, 320 KB format for CPM-80, so I will have to use deblocking. I already have my BIOS with that built in, and set up for the [Andrew Lynch et al's project] N8VEM. I will port that to the "MDS-80" look alike and see what happens."

"I was looking at the system today and thought about putting a iSBX 218 FDC set up for an 8 inch drive on the system, as well. Then I would have one system with both drive types available for copying disks or imaging disks. Imaging is much easier on a CPM or Linux machine than a DOS machine.

"And, I have an order outstanding for 10 each 60 GB PATA/IDE hard drives. I plan to interface one of these to one of the 8255's on the CPU card. Again, the BIOS code is part of the N8VEM code. They used discrete components rather than an 8255, but the porting should be fairly simple.

[Bill mentioned rewiring the ROM socket on the 80/10 for a larger and more recent PROM.] No, [a daughterboard] was the first adapter. This time I cut the wiring on the bottom of the board to pins 18-21 of A23. I connected them to three pins on A42 that I had used for the old adapter. I did not have clearance for an adapter. The CPU is below the RAM card, now." Later he added, "My original adapter used 27256's. They programmed fast[er than the 2732's]. But I cannot afford the height of the adapter because of the board spacing. That is why I removed the original adapter. Could not get the RAM board in. 2732 is the last of the 24-pin EPROMS - 2764 is first of the 28-pin ROMs."

"I need to build some sort of case for this machine. I want to keep the 2 each 5.25-inch drives external so I can use them elsewhere, as well. Same for the single 8-inch drive. I have an aluminium case for the 5.25s where I bring out the data and power on a DC-37 connector. Will look into a minibox to house the 8-inch drive and power supply." - BIll

progress on OS installation

[Within a few days: ] "I have it reading either disk solid. I also assembled the CCP+BDOS+BIOS source for the iSBC 80/10. I was able to load the hex image directly into memory. This means I don't need the Kaypro to build disks. All I need is to write a simple sysgen program to copy the running image to the disk. I have a lot to work out to get this all working, but we are close.

I have all the tools I need to build CPM-80 or CPM-86 files here on my PC. Anything I am missing I can write here, as well....[Now] I need to settle on the disk format. The first method is to write the entire CCP+BDOS+BIOS image onto the boot disk starting at cylinder 0, head 0, sector 1 and continuing. The current CPM80 image requires 18 512-byte sectors. If I use both sides of cylinder 0, this will take it all. There is no room to expand BIOS to handle the IDE drive. So I would need to take two cylinders for the boot image.

The other solution is to do it like DOS - place BIOS in one file and CCP+BDOS in another on the bootable disk. I can force them to be on the first blocks of the file system, just as DOS does by placing them on a freshly formatted disk first. Then I would need to write a simple boot program to load BIOS.SYS and execute it. BIOS will then load CCP+BDOS from CPM80.SYS. I use this method to bring up CPM86 on the S-100 system. Leaning towards this solution.

The nice thing is being able to debug on the actual hardware. That should allow me to progress more quickly." - Bill

Herb said: "Two cylinders seems to be the typical max for most CP/M OS's. That's four tracks on a two-sided diskette. The downside is that it eats two whole tracks on every formatted diskette, rather than one, an extra 2.5% of the disk, so your directory begins in the same track/sector/side. It's probably tolerable. If you need more space, go to 80 track drives!" - Herb

Bill replied: "It appears CPM86 reserves 1 track. I am heading that way. A number of CP/M systems had to deal with bigger BIOS'es. Some load a minimal BIOS, and then have THAT BIOS load a larger one. Heath/Zenith does something like that. There's probably discussions of this in the more sophisticated CP/M programming books or magazine articles."

Herb said: "One approach I've seen, is to stick in the command line buffer, the loader for the rest of the BIOS or a bigger BIOS. Then, when CP/M is loaded from the boot tracks, CP/M comes up and reads the first command - to load a file named (whatever) and run it. The file can have a front end bit of code, to move the rest of the file "up" in memory to wherever it needs to be, from wherever it was loaded. It's a little tricky, to assemble the code for the BIOS in one location, but include it in the file." - Herb. Bill noted: "This is a kludge of simply putting the OS files in the file system on the disk as is done with DOS."

Herb continued: "Or, write a stubby bit of code, that itself reads the BIOS file by name, and loads it using CP/M. It's more disk access to do that, but the "stub" just opens the file for read, and reads it into the proper memory location directly, and does any cleanup/initializations needed. Either way, the stub and the BIOS extension have to be co-assembled with the BIOS so everything lines up. With either scheme, you don't need to stick the extended BIOS in any particular part of the diskette. It's incrementally more efficient to put it in the lower tracks."- Herb

Bill responded: "Indeed, if the system files go on first then you don't need much code - they appear linearly on the floppy beginning at a fixed point. If you rewrite them, all bets are off.

Herb said: "It gets hard to manage all this, when there's a hard drive involved. If you want to boot from floppy OR from hard drive, you are kind of screwed if you are short of space. Some people choke on the idea, that you have to load CP/M from floppy, and THEN load hard drive support code. Well...this is 1970's 80's technology, I'm not much put out by this. One could have a big ROM that boots either floppy or hard drive, put the code in there and disable it once either is booted, to free up RAM space.- Herb

Bill says: "I manage this by using one header file in all the builds to set the CPM size and origins of each piece. N8VEM took the big eprom to the limit."

"Further update. I decided to start with a SSDD floppy format. I use a DOS formatted DSDD floppy [of 9 sectors of 512 bytes per track]. I initially placed the boot/id sector on track 0, head 0, sector 1. This boot loader can be replaced with another as I find the cleanest solution. I have a simple routine to write the boot sector onto the disk. The system is placed on the disk from track 0, head 0, sector 2 through track 1, head 0, sector 9. I have plenty of room for CCP+BDOS+BIOS in this layout. I can load the CPM80 into the 80/10 in hex format. I have a simple sysgen routine that will write it to the disk as described above. The boot routine reads the 6 512B sectors containing the BIOS in one operation into the proper place in memory and calls the BIOS cold start routine. The BIOS cold start routine reads CCP+BDOS in in two operations (one for each track), as it does on a warm start. Then it is off to the CCP. Unfortunately, we are blowing up logging on the drive. But I am able to read and write to the floppies. I continue to debug my BIOS."

"My BIOSs all supported SD 3740 and DD sytem 34 disks with 128, 256, 512 and 1024 byte sector sizes. I reduced some gaps to get another sector on a disk. This was all in the 8-inch drive realm. Here I am with 5-inch drives in 2011 where the standard has been settled. Looks like DSDD 9 each 512 B sectors is the rule (DOS 360K). And we use the same sector size on the PATA/IDE drives. I am going to rewrite my BIOS to support these standards. Basically, one floppy definition. I am using the 2 reserved tracks to get it working. Then I will place the system all on both sides of cylinder 0. The file system will start on cylinder 1. All this will reduce the complexity of my code. But I have a lot of work to make the conversion. I have to use the CPM blocking/deblocking which I have used in my S-100 BIOS." - Bill

[By a few days later:] "The system booted up today and gave me the "A0>" prompt! Still a major bug in the floppy disk driver which requires I do a board reset on the iSBC 208 after each read. Have to find that bug and squash it. It forces the drive to home before each read." - Bill

2012: linker and object module format

[Read my Web page on Bill Beech's software tools for more information about his work with linkers and Intel's object formats. - Herb]

Contact information:

Copyright © 2012 Herb Johnson