JonnyQuest wrote on 2025-04-01, 17:19:

I just tried 31/2" 144mb floppy again. Formatted a disk on my XP to Dos boot disk. Made sure BIOS was set to this type of disk on A: ... computer goes directly to blinking cursor. Weird thing is that I can't ctrl alt delete to restart it with drive plugged in.

I didn't know you should set drive to none with Xtide plugged in. I always did autodetect and accepted those settings

Does the green light on the drive constantly stay on?

Also, depending on how XTIDE is configured, it can probe the motherboard's IDE controller, in addition to itself.

It's just a ROM bios that works with (nearly any) IDE controllers. This is why it can live on a NIC.

When it starts, take a picture of its detection/boot phase while the xtide bios is doing its thing.

Rationale: the card should have jumpers to set it as the secondary IDE controller, and the XTIDE bios should be configured to probe addresses for primary and secondary controllers. This is by far and away the most robust way to produce and use an XTIDE card.

(Sadly, some people mistakenly think that the xtide card should be the only controller in the system, and that the bios should only ever probe the primary address. For reasons stemming from simplicity, but being incomprehensible to me. Sadly, some makers of these cards do in fact make and configure them this way, and there is no way to tell unless you check what the detection phase output says.)

If it is configured *sanely*, it should probe both primary and secondary channels.

If it does, set the card for secondary, and put a cdrom or dvdrom drive on it, and attach the DOM to the motherboard, which provides the primary.

I plugged in XTIDE again, this is what comes up now!

I missed it in the pic but at bottom of the screen it says

A to A boots from fdd with hdd mappings A to D boots from hdd with fdd mappings

I have one of the original DOM plugged into XTIDE currently.

I did click ROM boot... went to system error I believe it said.

I don't know what the A to A or to D means?

Is the other DOM 128mb in size?

Meaning of this output.

DOS uses a memory structure called the Interrupt Vector Table, which is a table of memory addresses and config values needed for bios services.

The entry we are concerned with is int13h, which handles disk IO.

This is the service xtide takes over. Disk io includes floppies.

Device 00h is the floppy diskette, as seen from an int13 call.

80h is the first hard disk.
81h is the second hard disk.

This version of xtide does not appear to have eltorito, or perhaps says nothing about it because it did not detect a cdrom.

The messages at the bottom relate to how the bios will present the disks detected. Either as hard disks or floppy disks.

You should let them be seen as hard disks.

(This option is for IDE flopptical drives, like LS120. You dont have one, so there is no need to report as a floppy drive.)

I just happened to try the XTIDE when you were publishing your post weird _w.

I can still try what you suggested... but let me know if my pics offers any other insight

Current DOM plugged in is 128mb

DOM that previously worked is 512mb

XTIDE is finding both DOMS, but does not get a response from ATA/IDENTIFY query, which on more modern drives, returns an ID string along with config data. If the DOM doesnt do that, the xtide bios uses other methods to identify reported geometry, which it is successfully doing.

It is seeing both DOMs

Scratch that, it looks like it's configured to be the primary controller and getting odd responses.

Can you give a picture of the xtide controller?

We need to try setting it to secondary.

Hopefully you can see everything

typical.

This version of the XUB is not configured to probe the primary and secondary IO port addresses for IDE controllers (1F0 and 170, respectively), it is configured to emulate an MFM disk controller (Port 300)

This is what I meant about incomprehensible rationale behind configuring these cards. (Presumably in the name of simplicity and not confusing people, but ultimately it just neuters the the XUB for no real demonstrable reason, other than maybe being able to shirk on the bill of materials when making the card by using a smaller eeprom.)

If you ask me, the *CORRECT* way to configure the XUB, is to have it probe (and gracefully fail, if no controller is found, similar to an ATAPI cd driver probe) 1F0, 170, and 300, in that order, and thus be perfectly configurable with the jumper, to be able to live in any of those configurations, or to work with other controllers that may be present, on those IO addresses. This is by far and away the most robust configuration, and makes the card infinitely more useful for any number of applications, and configuring the card like so many makers do, is not comprehensible to me for this reason. It gives no added utility, and just REMOVES utility.

[there may be SOME argument about how bonafide IDE controllers are not intended to be run in 8bit mode, and the codepath selected when configuring the XUB to be able to assume 16bits mode on 1F0 and 170, and 8bits mode on 300, makes the XUB "Needlessly large" or that old genuinely 8bit machines lacking a 16bit bus may have crashes or other odd behavior when a 16bit IO operation gets asked for on a CPU that cant do it, but again, this simply breaks most of the more valuable use cases of employing an XTIDE card, just because you have foibles about how large the eeprom is, or you want to assume that the card will only ever live in a genuine IBM XT with an 8088/8086 CPU. Which hill do you want to die on? The hill where you have a neutered card, and tell end users that they dont know what they are talking about, just so you can get away with a marginally less expensive chip, or the hill where end users get the most bang out of the project, and their purchase, with the caveat that they should be mindful of putting it in an XT? I would recommend you choose the latter hill. It's the one I choose. EVEN BETTER STILL, would be to add a chip select line, and a second DIP socket, so you can have an 8bit XT rom AND a 16bit AT rom, and a jumper to pick which mode. But that is a bit more expensive to build cards, for functionality that will always be half-disabled. (at any one time, only one of the chips is used for anything. Nevermind the utility of being able to SWITCH without are reflash.)]

Sadly, this is an option set with XTCFG, a program that is used to configure the XUB before flashing it. To change this option, you have to reflash the eeprom. The XUB is TOTALLY CAPABLE of doing this. It is just not configured to.

Sadly, it seems your card was configured in this pointlessly neutering manner, so you will have to disable the onboard IDE controller if you want to use this instance of XT-IDE BIOS.

We are now either limited to 8bit ISA bus transfers on this controller, (so we can get L-CHS/ECHS), OR-- Back to trying to kludge with a virtual machine to get your DOM set up.

I plugged in the previously working 512mb DOM to EXTIDE for try anything...

It's hanging here...

Gotek works?
If so, write a dos boot floppy.
Then assuming you get to dos : "sys a: c:"
That should fix it.

Also fdisk /mbr

But... the only communication to the MB currently is the single IDE. The floppy drives I've tried don't seem to communicate in BIOS. I did purchase a new floppy on Ebay that was touted as being able to work on this system.

Just mentioning that it might be possible to use cable that has two IDE connectors and have two drives on a single interface. Some controller support it.

Stating the obvious but you did also connect the floppy to power right? Just double-checking because I didn't see from the photos a power cable from that power supply. In any case try both sides of the cable, on both the floppy & controller. The floppy light stays on (when data + power cables are connected) if the floppy is connected the wrong side. But at least there is a connection.
Check that the bios enables the right floppy.

Good find on the Gotek, if it's connected on the motherboard (which seems to be a standard 486 with Vesa-local-bus) that could be what gets detected in the bios. You can generally copy a floppy image on a USB, put it on the Gotek and use it on the machine. Probably it was implemented like that so users can upload the CNC plans using a USB stick.

Last note, I use Ontrack Disk Mananger 9.57, booting from floppy, as it has the ability to show you what the CHS is (both translated, non-translated, LBA etc). This is shown in a weird place in the UI, as I recall you have to go to Info->Utilities and it will popup in a window, but memory is hazy now, if you get to that point I'll find the info for you.

Bigger picture, are you trying to fix the CNC or just use the 486 board?

Thanks Maikolator, I did/do have power to floppy. I don't get offended by obvious questions! Will a 3.5" floppy from a XP computer work? I have a working XP tower I can rob from to try.

The Gotek is a early version, no display. I've been watching videos... but they are confusing to me.. and they are all based on display version of Gotek.

FYI, I'm in Hartford WI... not to far from Milwaukee. Anyone close to me and want to make a few bucks?

The CNC will be run from 486. It was standard for this machine/era. Machine does work, as I had it working previously. This whole endeavor started because I needed to get the CNC machines SYS files from one DOM to another.

JonnyQuest wrote on 2025-04-02, 13:31:

The Gotek is a early version, no display. I've been watching videos... but they are confusing to me.. and they are all based on display version of Gotek.

just put the disk images on the usb and have to remember what order they are in, should be alpha numeric. But you only need to put in one image to try to boot.

Pickle wrote on 2025-04-02, 13:37:

JonnyQuest wrote on 2025-04-02, 13:31:

The Gotek is a early version, no display. I've been watching videos... but they are confusing to me.. and they are all based on display version of Gotek.

just put the disk images on the usb and have to remember what order they are in, should be alpha numeric. But you only need to put in one image to try to boot.

Ok, say I put a file on USB...original name Dosboot.img.

Do I have to change it to 0000.img? Does it have to have an exact number of characters? Is 0000 what Gotek looks for as first file? Or should it be 0001.img?

JonnyQuest wrote on 2025-04-02, 14:10:

Pickle wrote on 2025-04-02, 13:37:

JonnyQuest wrote on 2025-04-02, 13:31:

The Gotek is a early version, no display. I've been watching videos... but they are confusing to me.. and they are all based on display version of Gotek.

just put the disk images on the usb and have to remember what order they are in, should be alpha numeric. But you only need to put in one image to try to boot.

Ok, say I put a file on USB...original name Dosboot.img.

Do I have to change it to 0000.img? Does it have to have an exact number of characters? Is 0000 what Gotek looks for as first file? Or should it be 0001.img?

I think you could rename like 01_*.img 02_.img* to get to the exact order but i dont think its necessary.
With no usb the display should be 00, put your usb in and it should select the first image and show D0.

Ok, thanks guys. Don't think I have time today to work on it... but I'll report back.

I mentioned it above, but would a XP 3.5" floppy be compatible on this 486? I have one of those to try too

JonnyQuest wrote on 2025-04-02, 15:19:

I mentioned it above, but would a XP 3.5" floppy be compatible on this 486? I have one of those to try too

there nothing specific about a floppy drive requiring XP. Basically the majority of drives at this point are all 1.44 mb drives. It should work, but you should check in the bios to make sure the drive is set to 1.44 mb.

I'm in the Chicagoland area and could get up there Saturday if it's still not working.