• Please review our updated Terms and Rules here

IMS Series 8000 (5000SX?) Project

new_castle_j said:
I added the interleave value to your img.cfg file and got the raw disk image to work in the FlashFloppy Gotek. It works the same as the HFE file though, it can be read/written to once the machine is booted via hard disk, but it can't be booted from the Gotek. The .img file also seems to read/write data faster than the HFE file. There must be some kind of debug mode that the Gotek can be put into to get an idea of why it hangs on boot. I'm attaching my image and config for you to play with. I'm using the same 34 to 50 pin adapter that you are, but I have none of the jumpers shunted.
Click to expand...
Yeah, with the interleave added I'm now seeing the same behavior with the .img files as I see with the .hfe files. Out of curiosity, is that TDOS.img in your attachment a raw dump of the LFTD14-1.IMD image you had posted earlier? I ask because it behaves slightly differently (and doesn't COMPLETELY match up when I do a diff in the hex editor, though it's pretty close). Now with the FF.CFG file and a raw disk image of LFTD14-1.IMD that I used IMDU to create, I see it jump to track 24, then 25, then 26 and then it jumps back to track 0. Rinse and repeat. With your image it seems to jump to track 24, but then gets stuck on track 25.

I think I need to understand the TurboDOS boot method a little bit more so I can actually look at those tracks on the disk in the floppy emulator tool and try to figure out what it's looking for (and presumably not finding to its satisfaction). Off to bitsavers.
 
Last edited:
twmiller said:
Yeah, with the interleave added I'm now seeing the same behavior with the .img files as I see with the .hfe files. Out of curiosity, is that TDOS.img in your attachment a raw dump of the LFTD14-1.IMD image you had posted earlier?
Click to expand...
It's slightly modified from the original LFTD14-1.IMD. I did some writing to it from my booted system before zipping it back up and posting.
 
new_castle_j said:
It's slightly modified from the original LFTD14-1.IMD. I did some writing to it from my booted system before zipping it back up and posting.
Click to expand...
Oh, I meant to comment on the speed difference you were seeing: those HFE disk images are huge (relatively speaking), because they're storing a recording of the actual magnetic flux of the floppy, I think, not just the bits the way a RAW image does. I'm not at all surprised that you're seeing a performance boost with the .img files.
 
A bunch of 74x chips came in from mouser today, so I was able to replace the missing chips on the second IMS 400 IO card, and also stick the 74ls420 I had stolen from the hard drive controller to replace a bad one on the CPU card. I haven't gotten to the point of testing the two MPU cards yet (need an OS for that), but all of the other cards are now working!
 
twmiller said:
@new_castle_j Could this be the problem? Only diskettes with 512 bytes per sector are bootable? 1024 bytes per sector can be written and read. (Kind of sounds like what you're seeing on your working system.)
This is from here: http://www.bitsavers.org/pdf/industrialMicroSystems/turboDos/turboDos1.4_mast16bInst_85.pdf

View attachment 1276714
(No idea if this really is relevant at all, just caught my eye that 1024 bps can be read/written, but not bootable, which seems to be exactly what you're seeing...)
Click to expand...

Not related, they are talking about the new disk format they introduced for 16-bit master processors... good question though.
 
My suspicion is still that there's something screwy with the Gotek. Things behave like they should during boot, first the disk directory is parsed and the file OSLOAD.COM is found, the drive seeks to the place on the disk where OSLOAD is, but then something chokes. A successful boot would bring OSLOAD into memory and execute, then go back to the disk directory and search for OSMASTER.SYS (the full operating system), seek to that file and bring it into memory.
 
new_castle_j said:
My suspicion is still that there's something screwy with the Gotek. Things behave like they should during boot, first the disk directory is parsed and the file OSLOAD.COM is found, the drive seeks to the place on the disk where OSLOAD is, but then something chokes. A successful boot would bring OSLOAD into memory and execute, then go back to the disk directory and search for OSMASTER.SYS (the full operating system), seek to that file and bring it into memory.
Click to expand...
So you think that number of bytes per sector thing is a red herring? (I wasn’t sure whether that just applied to a later version of TurboDOS, and I’m not sure where the 1600 series lines up with the board set that you’re using, but I know it’s obviously later since it’s an LF Technologies model, not an IMS model.)
 
Last edited:
twmiller said:
So you think that number of bytes per sector thing is a red herring?
Click to expand...
Yes it's a red herring in this case, I am using 1024 byte sector physical floppy disks to boot my series 800 board set. I really think some advanced troubleshooting on the Gotek is what will move things forward. I saw that there is a way to flash the firmware to a "diagnostic" mode and have it log what it's doing. That sounds like the next step to me.
 
new_castle_j said:
Yes it's a red herring in this case, I am using 1024 byte sector physical floppy disks to boot my series 800 board set. I really think some advanced troubleshooting on the Gotek is what will move things forward. I saw that there is a way to flash the firmware to a "diagnostic" mode and have it log what it's doing. That sounds like the next step to me.
Click to expand...
Gotcha. There's a 'log' version of the firmware available in the 'log' subfolder of the main flash-floppy download. That seems to be the closest I can find to a 'diagnostics' mode or ROM. I'll stick that on one of my Goteks and see what kind of information it dumps to the log.
 
These don't seem to be that useful to me. Still poking around to actually see if I can find some information on what these actually mean. The documentation for the 'logging' mode is not great. In fact, as far as I can tell, it doesn't seem to exist at all beyond 'there's a logging version you can use if you want to'. The RDATA underrun on the HFE file is the only thing that looks like an actual error. That error is not duplicated with the .img attempts.

This is the original IMD just straight converted to HFE:
Code: 
Name: 'LFTD14-1_IMD' Type: hfe
Attr: 20 Clus: 000021e9 Size: 3864576
Fast Seek: 13 frags
Cache 27 items
Trk 52: skip 197ms
RDATA underrun! 0-1ac-200
Cache 103 items

This is my version of LFTD14-1 converted to a raw img by the DOS IMD app:
Code: 
Name: 'LFTD14.ims' Type: img
Attr: 20 Clus: 000003fa Size: 1260544
Fast Seek: 10 frags
Cache 32 items
Trk 0: skip 477217ms
Trk 0: skip 477218ms
Trk 49: skip 477217ms
Cache 103 items

This is the version of the raw image that you had attached with the IMG.CFG file:
Code: 
Name: 'TDOS.ims' Type: img
Attr: 20 Clus: 00000010 Size: 1260544
Fast Seek: 17 frags
Cache 32 items
Trk 0: skip 477217ms
Trk 0: skip 0ms
Trk 48: skip 477217ms
Cache 103 items
 
Yeah, doesn't look like much to go off of, there is a FlashFloppy Facebook group for support, I'm not sure what question I would formulate to ask though. Maybe start playing with the FF.CFG file and add more options into it and test and see if any of them do any good?
 
One thing I noticed when I was using a different tool to convert the original LFTD14-1.IMD to HFE:
"disk-analyse: IMD: trk 153, sec 5: Sector data unavailable"

I think IMD on the DOS machine also mentioned that one sector was 'unavailable'. I think it's unlikely that this particular sector (if it's even bad) will prevent the disk from booting, but I thought it merited mentioning. (Thinking this might just be some quirk of the diskette's format, I also tried converting the other two LFTD14-? IMD images, and the both converted without any complaints, so it's just the first diskette image.)
 
Last edited:
new_castle_j said:
Yeah, doesn't look like much to go off of, there is a FlashFloppy Facebook group for support, I'm not sure what question I would formulate to ask though. Maybe start playing with the FF.CFG file and add more options into it and test and see if any of them do any good?
Click to expand...
Yeah, I think I'll do that (start playing with the FF.CFG file). I don't have a FB account, and am not *super* inclined to get one, but if worse comes to worse... (I might buy an 8" drive before that happens, though. lol)
 
Last edited:
I can warm-boot my system from the Gotek, just can't cold-boot it. What I mean is, with the system booted from hard disk, I can copy the boot files (OSLOAD.COM and OSMASTER.SYS) to the Gotek, then execute the command OSLOAD OSMASTER.SYS and it will boot and the Gotek serves up the data just fine. I don't know what it means, something is different with how the ROM accesses the floppy vs. how TurboDOS accesses the floppy?

It might be possible to boot your system to the minimonx ROM, use the serial transfer to upload OSLOAD.COM into memory at HEX 0100, then jump to that memory location and it may kick off the rest of the boot and pull in OSMASTER.SYS from the Gotek. Not a very elegant solution though.
 
new_castle_j said:
It might be possible to boot your system to the minimonx ROM, use the serial transfer to upload OSLOAD.COM into memory at HEX 0100, then jump to that memory location and it may kick off the rest of the boot and pull in OSMASTER.SYS from the Gotek. Not a very elegant solution though.
Click to expand...

I can definitely give that a shot. I've got the serial copy working pretty good. Where do I find the OSLOAD.COM? When I use the cpm tools I have to look at the LFTD14-1.IMG file, I see these files, but they don't seem to include OSLOAD.COM or OSMASTER.COM.
1712087601087.png
 
Looks like you're not seeing all the files, I'm attaching a copy of the disk contents here. You can find OSLOAD and OSMASTER.SYS in disk 1
 

Attachments

  • Files.zip
    755.3 KB · Views: 1
new_castle_j said:
Looks like you're not seeing all the files, I'm attaching a copy of the disk contents here. You can find OSLOAD and OSMASTER.SYS in disk 1
Click to expand...

Yeah, as soon as I hit 'post' on that previous message my curiosity got the better of me and I used the script I cycled through to find the proper def file for those CP/M disks. I found a number of them that would return the full listing that included OSLOAD.COM and OSMASTER.COM.

From the minimon9 readme file, for the GO command: "Start addresses and breakpoints must be precise and must be on command bytes, not data bytes." Once uploaded to 0100, is 0100 a 'command byte' or a 'data byte'. How can I tell the difference? (Or can I not without the PRN file from when it was assembled?) Sorry if this is a ridiculous question, as I may have mentioned, I'm a bit out of my wheelhouse at the moment... lol
 
My interpretation is that you do not want to set any breakpoint, you just want to execute starting at Hex 0100. So I think the command would be something like
G0100[CR] or
G0100,0[CR]
 
You must log in or register to reply here.
Back
Top