IMS Series 8000 (5000SX?) Project

[new_castle_j]

Wonderful! Please send me your latest GEN/PAR files. I had forgotten that the 401 and 930 floppy controllers were supported by the same driver! One other thing to know about IPLALL is that it has a pretty long delay built into it before it probes the hard drive for booting. You will also have to remove the USB sticks from the goteks before it will even try to boot from HDD.

 

[twmiller]

Wonderful! Please send me your latest GEN/PAR files. I had forgotten that the 401 and 930 floppy controllers were supported by the same driver! One other thing to know about IPLALL is that it has a pretty long delay built into it before it probes the hard drive for booting. You will also have to remove the USB sticks from the goteks before it will even try to boot from HDD.

Attached. The current setup I'm running is two GOTEKs and a 40 MB MFM drive. The drives are configured in the PAR files for A and B to be the GOTEKs and C through G to be the five 'partitions' (?) on the MFM drive. I have H through P set to 0FF, (0), though I'm not entirely what the benefit of doing that actually is. I also noticed that in the STDSINGL I have the "MCD740 ; Master Circuit Driver" enabled. 740 is the integrated CPU/IO card, I think, so I probably *don't* need this. I also have all of the printer stuff commented out at the moment, mostly because I have no printers set up for this machine. (I do have a Panasonic 1124 with both parallel and serial inputs that I might try to get working at some point in the future, but that's a ways off.) As I mentioned, STDLOADR.GEN is unhappy about the console for some reason, so it doesn't actually show the memory test being run and even though it's working, you don't see any output until you get the USRSOM message from STDSINGL.SYS.

Among the many things I had done to try and get this thing booting initially was pulling RDY-to-ground on one of the two FD50to34 boards I have. *Removing* that now has the hard drive booting! YAY! But now that I've removed that 'fix', the second Gotek isn't working. Boo!

Questions that I have:

1. Why does FMTF format the floppy without any complaints, but then fail to verify it? (But the standalone 'verify' command has no issues verifying it after the format.)
2. What are CMD files relative to COM files? On disk three of the LFT14 disk set (TurboDOS 1.41) there are a bunch of .CMD files. They don't seem executable, and most of them seem to have a .COM counterpart on disk 1.
3. Turbogen seems to work, but I noticed that it pretty emphatically states that it's for 1.40 and below, and DO NOT use it with 1.40+ or anything above.
4. What is FMTW for? Why did I not have to do anything other than a low level format to get the five drives on the MFM drive working?
5. Is there anyway to see how much memory is left for programs after booting? I did try running Wordstar 4.0 and it choked with an 'out of memory' error. (TurboPascal had no issues compiling a 'Hello, world!' app, though!
6. Is there a ready-to-go serial solution? Has anyone patched KERMIT or XMODEM (or anything else suitable) to allow you to easily move files onto and off of the system using the second serial port on the 442?
7. What's WD1100P referring to when it talks about DOS Floppy support?
8. Why did STDLOADR.GEN have RTC442 included in it, but the STDMASTR.GEN that I based STDSINGL.GEN off of only had IO442? Oh, I think that the loader had INT442 and RTC442, and the std master (template for my single) had IO442. I bet that IO442 probably includes both of those plus some other stuff, and loader is probably just using those two drivers by themselves in order to be 'slimmer'.

 

[new_castle_j]

Why does FMTF format the floppy without any complaints, but then fail to verify it? (But the standalone 'verify' command has no issues verifying it.
-- I noticed that too, it has something to do with the Gotek, when I format a real floppy disk, the whole process works without a glitch. Perhaps it's some kind of timing thing? Maybe FMTF expects some kind of delay in between formatting the last track and letting the R/W head seek back to the first track before starting to verify.

What are CMD files relative to COM files? On disk three of the LFT14 disk set (TurboDOS 1.41) there are a bunch of .CMD files. They don't seem executable, and most of them seem to have a .COM counterpart on disk 1.
-- The CMD files are the equivalent 16-bit versions of the .COM files, you will also see 16 bid driver files with a .O extension and TLINK.CMD is the equivalent to GEN.COM

Turbogen seems to work, but I noticed that it pretty emphatically states that it's for 1.40 and below, and DO NOT use it with 1.40+ or anything above.
-- Turbogen is a "value add" utility from IMS, it was never part of the Software 2000 distribution, it's purpose is to patch in option parameters into a .SYS file by directly fiddling with the bits in the .SYS binary. It only works with bog standard IMS GEN/PAR files.

What is FMTW for? Why did I not have to do anything other than a low level format to get the five drives on the MFM drive working?
-- FMTW is a low level formatter and it also writes the partition tables, by default it will divide the drive into equal sized CP/M compatible (8MB) partitions. If you want to change the change the number of partitions, run PRTWIN. PRTWIN will divide the winchester into any number (1-15) of equal-sized partitions. If PRTWIN is run, ERASEDIR must be run on every partition. ERASEDIR is what writes the file directory table.

Is there anyway to see how much memory is left for programs after booting? I did try running Wordstar 4.0 and it choked with an 'out of memory' error. (TurboPascal had no issues compiling a 'Hello, world!' app, though!
-- There is a utility called TPA.COM that will display the "Transient Program Area" which is the amount of free RAM for running programs. You will find that on a fully loaded 8-bit master processor, there won't be much left which is fine since you're not supposed to be running programs on the master, that's what the slave processors are for. You don't want the master doing anything else besides servicing the disk and other I/O requests from the slaves. Typically you wouldn't have a console attached to the master either and once you've got your slave processors up and running, you should replace the CON96 or CONSOL driver with CONREM so you can remote connect to the master console from the slaves to do any admin type functions like formatting a disk.

Is there a ready-to-go serial solution? Has anyone patched KERMIT or XMODEM (or anything else suitable) to allow you to easily move files onto and off of the system using the second serial port?
-- I think I have a copy of MEX for IMS hardware, I will have to look.

What's WD1100P referring to when it talks about DOS Floppy support?
-- IMS (L/F Technologies) had an add-on product called L/F Link which ran on their 16-bit slave boards, it allowed you to boot a copy of MS-DOS 1.x and maybe 2.x. The MS-DOS kernel actually ran under the supervision of the TurboDOS kernel and you could run LOTUS 1-2-3 or any other well behaved DOS console program that didn't try to access PC hardware directly. With the WD1100P driver, you could read/write 360K DOS 5.25 floppies. I've been trying for years to get a copy of LF-Link from a friend who thinks he has a copy in his basement ... if you're reading this Ken, I'm still interested.

 

[twmiller]

Maybe I'll poke around with the Gotek settings and see if I can get a setting to fix the verify issue, but I'm not really concerned about it. Verify is a lot more important with real media than it is with virtual media.

I can lose the CMD files off of the hard drive (I don't have a 16-bit board (that's the 186, I assume?) and probably won't be getting one anytime soon).

I'm not going to concern myself with Turbogen or FMTW.

I'll try to find a copy of TPA.COM and if you have MEX, that'd be awesome.

Also not going to worry about WD1100P for the same 16-bit reasons.

I removed MCD740 from the STDSINGL.GEN file and it works without any issues. I also removed INT442 and RTC442 and replaced them with IO442 in the STDLOADR.GEN file and now the terminal is working when loader is running the memory test.

 

[new_castle_j]

Attached is the TPA.COM file for checking how much memory is free.

 

[twmiller]

On the left is a serial connection to the master processor, where I've pulled up a directory and run TPA. On the right is one of the two A862 MPU boards, running Wordstar.
The primary processor has about 17k free. When I ran TPA on the slave processor, it had about 51k free.

 

[new_castle_j]

Brilliant! it's all working!

Try doing a FMTF and select single sided disk, it appears to work and verify. Perhaps there is something with our Gotek config that doesn't play well with double sided emulated media?

I located a disk in my collection that has a hand written label that says: "Mex for IMS, Movit, Etc." The contents of this disk are in the attached image file. I've never used it and it doesn't come with any instructions, see what you can do, if you get it to work, let me know.

I'm also including another extremely useful program on that disk DSTAT.COM It will scan the directory of your disk and give you a summary of how many files are in each of the 32 user areas. Nice to have when you are trying to remember where you put something.

 

[twmiller]

Brilliant! it's all working!

Try doing a FMTF and select single sided disk, it appears to work and verify. Perhaps there is something with our Gotek config that doesn't play well with double sided emulated media?

I located a disk in my collection that has a hand written label that says: "Mex for IMS, Movit, Etc." The contents of this disk are in the attached image file. I've never used it and it doesn't come with any instructions, see what you can do, if you get it to work, let me know.

I'm also including another extremely useful program on that disk DSTAT.COM It will scan the directory of your disk and give you a summary of how many files are in each of the 32 user areas. Nice to have when you are trying to remember where you put something.

That looks like it's set up to use the serial port address on the 971 CPU board, which is 2DH. The 442's second port is (I believe) 12H. Having said that, I think I can stick this second 442 in as the secondary IO card and have it sit with it's first serial port at 20H, which one of the versions of MEX on that disk seems to support. I'll give it a shot tomorrow.

 

[twmiller]

In addition to the two GOTEK drives that are pretending to be 8" Floppy Drives, I now also have a MFM Emulator Rev D that is currently is pretending to be a 140MB MFM hard drive. Since one of my goals is to set this thing up so that at least one (hopefully more*) of the terminals is accessible via telnet (think a cross between a BBS and sdf.org, but...you know, with TurboDOS!), I wanted to not have any mechanical media involved if I'm going to be leaving it on 24/7.

I was first able to use the MFM Emulator to clone a copy of the ST-251 (seen sitting on the shelf behind the workbench) and verify that it didn't have any issues booting. It worked like a charm. Created the image with no complaints, and booted right off of it. Then I tried to create the 190MB drive and it failed. A bit of trail and error showed that the issue wasn't the track count but seemingly related to the number of heads defined, though I'm still playing with this. I'm pretty sure it's actually an issue with the low-level formatter, not the drive emulator itself. I think maybe I need a later one, or the one from TurboDOS 1.43 or something.

I managed to create a *proper* no-twist cable for the GOTEKs, and when that is used, both GOTEKs work without issue on a single FD50to34 board. Yay! I'm back to having functional A: and B: 'floppy' drives, which will make loading the hard drive MUCH easier.

The software isn't completely there yet, but it's *really* starting to come along. I need to figure out the best way to partition these bigger drives. It looks like the default partition is 'CP/M' friendly, so it keeps each drive at 8MB and change. That's a LOT of drive letters, even with a 140MB drive. I can use PRTWIN to create less (i.e. bigger) partitions that are TurboDOS friendly, but I'm not sure what the implication of that is, in terms of compatibility. (I don't plan to run CP/M on this system, but I do plan to run CP/M *software*, and I'm not sure whether that software will choke on larger drives or whether it won't care.)

I'm at the point now where I need to start thinking about building / acquiring a case for this thing, so if anyone has any good ideas, I'd love to hear them. (And yes, that black desk fan behind the computer *is* turned on and acting as the main cooling for the system. It keeps the regulators (which are undervolted to begin with) nice and cool!



*if anyone has some spare IMS 8-bit MPU 'slave' processor boards they wish to part with for this project, let me know! I'd love to take them off your hands! lol

 

[new_castle_j]

There is a jumper on the 1100 Hard disk controller that allows it to be used with hard drives with more than 8 heads. Jumper JA should be shunted between pins 2 and 3 if you are going to use more than 8 heads.

TurboDOS will support a single hard disk partition up to 1 GB, and I can't remember if it was 8 or 16 partitions per drive. I've never seen CP/M software choke because of the available disk space. The software from IMS didn't give you full control over the hard disk and it's partitioning scheme, they kind of steered you into what they thought was best, but other vendors let you define individual partition sizes and how many directory entries per partition, what the block size was, some even allowed you to define the interlace scheme.

There were several BBS's that leveraged TurboDOS and had custom remote access software that had each slave processor connected to it's own modem, the sysop could remote in and mirror a session or do chat with the users, I'm looking forward to see where you go with this.

 

[twmiller]

There is a jumper on the 1100 Hard disk controller that allows it to be used with hard drives with more than 8 heads. Jumper JA should be shunted between pins 2 and 3 if you are going to use more than 8 heads.

This was exactly the issue. Changing that jumper 'fixed the glitch'. 190 MB 'hard drive' happily verifying.

TurboDOS will support a single hard disk partition up to 1 GB, and I can't remember if it was 8 or 16 partitions per drive. I've never seen CP/M software choke because of the available disk space. The software from IMS didn't give you full control over the hard disk and it's partitioning scheme, they kind of steered you into what they thought was best, but other vendors let you define individual partition sizes and how many directory entries per partition, what the block size was, some even allowed you to define the interlace scheme.

I think that six 30 MB drives seems to be right for the era, and relatively easy to compartmentalize.

There were several BBS's that leveraged TurboDOS and had custom remote access software that had each slave processor connected to it's own modem, the sysop could remote in and mirror a session or do chat with the users, I'm looking forward to see where you go with this.

Yeah, my goal is to set it up so that you can 'telnet' into a terminal just like you would have been able to log in locally on a terminal back in the day, and let the user access various games/apps/etc. In that respect, I was thinking it'd be kind of similar to sdf.org. But I also want to have inter-slave communications set up, so that multiple people can log in and the same time and chat, etc, and also set up some bulletin boards and a custom forum. This would obviously be more fun/interesting with more than just two users on, which is why I eventually want to try and track down more MPU boards. I have a pretty good set of ideas laid out, I just need to start implementing it. This week I need to familiarize myself with the USERID.SYS stuff, how security / privileges work, etc. I *think* it's all doable, though.

 

[twmiller]

@new_castle_j Do you know if it's possible to 'deconstruct' a REL that's made of other RELs? I'm wondering if there's a way I could remove SPB186 from the MCD740.REL in the interest of saving memory, since I don't have (and probably won't get) a 186 slave. I don't see anything that resembles an 'unpackage' command.

I do have logins working now, so both the slave terminal ports pop up the 'system login' prompt and require a user to login, and a privileged user to do anything destructive. So far it seems like the only drawback from the 32MB partition sizes is the amount of time it takes to pull up a directory. I've changed from NORLOD to FASLOD in the stdmastr.gen and it seems like the actual commands themselves execute pretty well. editing a text file in particular is SO much faster on the hard drive than it was on the floppies.

 

[new_castle_j]

I am not aware of any way to 'deconstruct' a .REL in the way you are describing. In the case of MCD740.REL, I don't think you will be saving much if you did manage to extract SPB186 out of it. SPB186 is the bootstrap code for the 186 slave, and it's minimal. The real meat of that .REL is the circuit driver which IMS designed the 8-bit and 16-bit slaves to share the same code.

There is some tuning you can do to increase the performance of the file system. Make sure you're using a hashed directory and the biggest performance boost will be if you dedicate the left over RAM in the Master processor to disk caching, you can set parameters like # of disk buffers and the buffer delay, it will cache the directory and working files in RAM for example and flush buffers to disk at an interval you choose. The drawback is that if you forget and power down while data is still in the buffers, it will be lost. The big reason for having a 16-bit Master processor with optional 1MB of RAM was to have a large disk cache to service all of the slaves.

 

[twmiller]

Now that I have a fat 'hard drive' on this thing, I spent some time last night loading it up with some software. Wordstar, dBase, TurboPascal, BASCOM, Z80ASM, Infocom games, etc. I want to go through the software in the TurboDOS folder of the Walnut Creek CP/M disc and see if there's anything interesting in there.

I spent a little bit of time working Modem7. I've found the correct overlay for the IMS 44x IO board. The instructions for building it are CP/M specific (they include using DDT and SAVE for adding the overlay to the main executable), so I moved the code over to my RC2014 running CP/M 2.2 and was able to build it following the instructions, and use DDT to add the overlay to the modem7 binary but the working executable doesn't quite work. The instructions specifically refer to modm715, and I've only been able to find modm700, so it's possible that I just need to track down the right version of code to mod.

If worse comes to worse, I'll jump back over to the MEX code and see if I set up by second IO board with the address its expecting.

 

[new_castle_j]

I have a dim memory of the vanilla MEX distribution walking you through a setup wizard, and one question you were prompted with was if you are using TurboDOS, and if so, it would configure itself to use the COM channel driver instead of going direct to hardware.

There should be a program called MONITOR.COM that comes with TurboDOS, it's their equivalent to DDT, but of course the procedure for using it would be a little different.

I'll also post a copy of Kermit that I have which is reported to be configured for TurboDOS, using the COM driver entry point so it's not hardware specific. I haven't used this program so you'll have to report back if it works. I went straight into implementing ARCNet in my systems and file transfers from a DOS PC with USB drive are trivial to/from TurboDOS so I never needed modem software.

 

[twmiller]

I'll also post a copy of Kermit that I have which is reported to be configured for TurboDOS, using the COM driver entry point so it's not hardware specific. I haven't used this program so you'll have to report back if it works.

It works.


I didn't have to do anything other than plug in the second serial port on the MPU and I was able to connect to this BBS in Germany that's running on an RC2014.