• Please review our updated Terms and Rules here

IMS Series 8000 (5000SX?) Project

Both the new IMS ROM and the older IPLALL ROM read tracks 17, 18, then hang out for a bit on 19 while the memory test is running, and then they jump back to track 0. They never advance to track 20. I just tried a different USB-to-serial adapter with a terminal app called serial, with Screen in the CLI, and with ZOC. Same behavior with all three.
 
Plunking around with the settings for Flash Floppy, but I think the fact that it can actually read OSLOAD and get through the memory test probably means that the floppy is working.

On the first copy of the IMS CP/M disk from a few pages back, I was able to pull off the IPL.ASM file for the CP/M boot ROM. I spent a bit of time today getting a little RC2014 running CP/M 2.2 set up as a 'development' machine. I was able to actually build it correctly, I think. (That is to say, I built something that matches the .ROM that was attached with that disk image.) What I spent a bit of time on this evening, though, is working to re-write the minimonx CP/M bootstrap to use the IMS400 floppy settings instead of the IMS430. That IMS code has all of the settings for the 8" on the 400, so I think I can get all of the missing information I need to try and bootstrap at least CP/M from that. At the very least, I guess, I'm getting a little more CP/M experience and getting a bit of exposure to z80 assembly.
 
I've meditated on your scenario for a few days and I think your CPU and Memory are fine, but something in the I/O board or Floppy may be the source of the issue. If you send me your address I will send you my floppy and I/O board so you can experiment with them and see if you can make progress.
 
I've meditated on your scenario for a few days and I think your CPU and Memory are fine, but something in the I/O board or Floppy may be the source of the issue. If you send me your address I will send you my floppy and I/O board so you can experiment with them and see if you can make progress.
Yeah, I’ve been fooling around with a bunch of settings to no avail. I really feel like i just need to get the floppy going long enough to bring up one of these hard drives, then i’ll be in a much better place to try and figure out what’s going on with the floppy.

Do you have any other images that you were able to boot off of on the Gotek? Thinking that something positive may have happened with the Gotek configuration, I went back and spent some time trying to get that CP/M image and rom to boot, but had no luck at all.

Thanks!
 
Last edited:
I never went back and tried the CP/M image from the Gotek. I recall that CP/M required a jumper to be moved on one of the boards in order to boot. I think it was one of the vectored interrupt jumpers. Once I got TurboDOS, I lost interest in CP/M.
 
Gotcha. My goal is definitely to get this thing up and running with TurboDOS (which is what the computer I'm attempting to 'recreate' was running). My interest in CP/M in-and-of itself is as a means to get TurboDOS up. On an unrelated note, I saw that someone has created some TurboDOS drivers for this little RC2014 retro-not-vintage system I have, too. It might be kind of cool to get TurboDOS running on that and see if I can't set up a RS232 network between the retro RC2014 and the vintage IMS. I'm sure it'd be super-pokey, but kind of neat to see it in action.
 
Last edited:
It may not be totally unrelated since the someone who created the TurboDOS drivers for RC2014 is a friend of mine. The TurboDOS community is very small.
 
It may not be totally unrelated since the someone who created the TurboDOS drivers for RC2014 is a friend of mine. The TurboDOS community is very small.

Oh, that's very cool. Did they do a writeup or post about it anywhere? Just curious. It's definitely on my list of things to check out. I've got the User's Guide and Implementor's Guide for 1.4 printed out from bitsavers and have been gone through them. It's funny how much more knowledge about hardware was required to run software when this was current.
 
I think the only writeup was on GitHub, it was a fairly simple port to RC2014 because of the RomWBW firmware, it does all the heavy lifting, the TurboDOS drivers just hook into it.
 
@new_castle_j Borrowed boards showed up. System works with both of them installed. Will spend some time this evening figuring out whether it's the floppy, the IO, or both. :) Also spend some time this weekend trying to get TurboDOS onto those hard drives. I wonder if it's worth taking a look at the 1.4 boot disk to see if I can get that to boot on this system for the HDD install.

1712945730628.png
 
Excellent progress!! I think it's going to take some work to get TurboDOS 1.4x going on this set of boards. I don't think the 1.4x distribution disks from IMS included drivers for the model 401 floppy controller. We may have to fiddle around for a while and see if the older 1.3x drivers will work in a 1.4x operating system.
 
Excellent progress!! I think it's going to take some work to get TurboDOS 1.4x going on this set of boards. I don't think the 1.4x distribution disks from IMS included drivers for the model 401 floppy controller. We may have to fiddle around for a while and see if the older 1.3x drivers will work in a 1.4x operating system.
So it appears that the issue is not with the floppy controller, it's with the IO card. Something about the 442 that doesn't allow it to boot while the 444 does. (Neither of my 442 io cards work, which makes me think it’s configuration or something, rather than a broken card.)

The input on the system is a little glitchy when booted. Sometimes the key typed doesn't reflect the key received. I'm going to try a different terminal app and a couple of different serial-to-usb widgets to see if that's something on the terminal end or something on the IMS end. It happens with either memory card, and with either floppy controller. It’s not something I’ve seen with the keyboard when using the monitor ROM.
 
You're not going to believe this. I switched the jumpers for the JJ, JK, and JL block to match the jumpers on your 444 and my 442 now boots. I never tried it that way because the manual *clearly* says that the way yours is jumped is for boards after 1981, and for boards prior to that, the interrupt jumpers should be set the way I was setting them. I never doubted those settings (the ones the manual said to use) were correct, because that's how both IO boards were jumped when I got them. Is...is that a firmware thing? Is it because I'm running the IPLALL ROM?! This makes no sense. Anyway, thanks for loaning me your cards. I literally needed them for three hours before I got my cards working, and that was MOSTLY just to prove that the computer itself does actually work. >sigh< Computers....

Also, the keyboard issue was totally related to that USB-to-serial adapter. This is the second time on this project I've been bit by that. The first one didn't work at all. The second works with the monitor ROM, but not with TurboDOS.

@new_castle_j What do you think the next step I take should be? Get TurboDOS onto a hard drive? TurboDOS 1.2, or 1.3?
 
Can you get 2 Gotek's wired up and working as Drive A and B?
There's going to need to be some merging of files from different floppies in order to get the end result of running the 1100 Hard Disk controller with the rest of the boards.
 
Can you get 2 Gotek's wired up and working as Drive A and B?
I think I should have everything I need to make that happen, with maybe the exception of a 34-pin cable with two connectors that doesn't have the flip. I also have a second FD50to34, so it's possible I could set that up as drive two and hang it off the second connector on a 50-pin connector. There are a couple of options. I'll fool around and see if I can get any of them to work.
 
And...success! Two Goteks hooked up!
1712963984370.png

This was a copy of the original boot disk on the second Gotek. After this I was able to format it as a 2-sided double density turbodos formatted disk and it both formatted and verified without any complaints, then pulled up an empty directory. I think we're in business!
 
Excellent! Have you familiarized yourself with the GEN and PAR files and how they are used to generate a new OS? There should be a copy of wordstar on the boot disk and you can view and edit them with "WS STDSINGL.PAR" for example. We will need to look at the .GEN file for the OS that is currently being used and make note of the drivers files that are being referenced. Then we need to see if that set of files exist on the TurboDOS 1.41 disk images I posted earlier. Any files that are missing, we will have to try an see if we can substitute older versions of those drivers. You can do a practice run generating an operating system with the GEN/PAR files that are already on the disk, try "GEN STDSINGL.SYS" and watch the process.
 
'Familiarized' is probably the best word for it. GEN files are basically the recipe of drivers (both software and hardware specific, it seems) that the GEN program will use to build the system? PAR files are the parameters that pass any needed configuration parameters for the GEN files associated with the build (how to map the drives, set up the printers, etc.)? PAR files apply patches to the code that's generated when all of the REL files are put together into the OSLOAD or OSMASTER. That's my understanding so far, though that might be a simplistic view. It looks like the only specific 'board' associated GEN files with this build are the DSK401 for the floppy controller, and SPD463, BRT442O and RTC442 which are all for the 442io board. I assume that setup related to the 451 processor card and the 464 memory card are in the NITIMS driver, which seems to be an overarching 'IMS hardware' driver?

I didn't see anything in the PAR or GEN files for STDSINGL that told the system how much memory was installed, though I did notice that even with my second memory card jumped for card two and installed, it still only sees 64k, so I assume there's something that needs to happen (probably in the PAR file?) that tells it that there's more than 64k.

When you run the 'GEN' command, is the STDSINGL.SYS file that's created a new OSMASTER.SYS? (And the OSLOADR.GEN/PAR creates OSLOAD.COM?)
 
Last edited:
Yes, you have the idea correct, and there's a few caveats involved, but you've got the concept.

If you run GEN STDSINGL.SYS, it should read in the STDSINGL.GEN and STDSINGL.PAR files and output a STDSINGLE.SYS file. Then if you want to test that operating system, you would run OSLOAD STDSINGL.SYS The other way to boot to your new operating system would be to rename it OSMASTER.SYS and power cycle the machine, but if your new Operating System has errors in it, then you will have to reboot from a backup disk that has a working OSMASTER.SYS on it.

64K is the maximum amount of memory an 8-bit system can directly address, it is possible to add a second 64K memory card and also include the Banked Memory Driver in your GEN file (BNKMGR) to allow bank switching, but if you are going to run any slave processors in an IMS system, they required the master processor to not use banked memory.
 
64K is the maximum amount of memory an 8-bit system can directly address, it is possible to add a second 64K memory card and also include the Banked Memory Driver in your GEN file (BNKMGR) to allow bank switching, but if you are going to run any slave processors in an IMS system, they required the master processor to not use banked memory.
Got it. So it’s 128k of banked memory on the master running alone, or 64k on the master and the ability to use slave processors. I have two IMS 862 slave processor cards that were not part of the original board set, but I did (in the IMS 5000 documentation, I believe) come across how to configure them to work with the 451, so I think they’re usable with my setup. They’re a bit newer than the other cards (1982 versus 1979), so I’m not sure if support for them is baked into TurboDOS 1.2 (which also seems to be dated 1982) or if I need a to use 1.3 or 1.4 with them.
 
Back
Top