Juko D16-X, can the bios be upgraded?

[Gustavo]

Again, thanks for testing. I just want to mention this;

This setting is drive dependant and should work regardless of controller used. You should not disable Block Mode Transfers unless you experience problems with it (i.e. the drive you are using is not compatible with it). If you ever change the drive to something that actually supports it (a real harddrive, for example) you will lose quite a bit of performance, unless you also reflash the settings of XUB. It won't hurt having it enabled for CF cards, even if most CF cards do not support more than 1 block per transfer.

OK, thanks for the explanation!

 

[Krille]

BTW, is the controller detected if running "Auto Configure" in XTIDECFG (with a drive connected)?

 

[Gustavo]

Got the card working in 16 bit mode with JP5 (ALE) in 2-3 position and JP2 OPEN, but filesystem got corrupted after a while. Needs more testing.

BTW, is the controller detected if running "Auto Configure" in XTIDECFG (with a drive connected)?

No, it found 0 controller.

 

[Istarian]

Got the card working in 16 bit mode with JP5 (ALE) in 2-3 position and JP2 OPEN, but filesystem got corrupted after a while. Needs more testing.

No, it found 0 controller.

Unless the computer has major problems or you did something dumb the filesystem corruption is probably the fault of either the hard drive or the interface/adapter card.

E.g.
turning off the machine while it was still writing to the disk (a bad idea/dumb move)

 

[Gustavo]

No. I think this board is not 100% compatible with XUB in 16-bit mode. Note that the eBay seller got some kind of corruption too:

"weird random crashes and read errors that went away as soon as I changed to a different controller & drive. I was unable to resolve this with different jumper settings. It seems to just be one of those weird compatibility problems. "

Note that the JUKO's manual talks about "implementation of the timing of the control signal."

 

[Krille]

Got the card working in 16 bit mode with JP5 (ALE) in 2-3 position and JP2 OPEN, but filesystem got corrupted after a while. Needs more testing.

No, it found 0 controller.

Ok. If you can get it to work reliably in 16-bit mode then I'll add that as the default device type/transfer mode to the auto detection. If not, I'll make 8-bit mode the default.

 

[Gustavo]

Gave it another go in 16-bit mode. Filesystem got corrupted on the first boot.

Maybe there is some delay in the routines of the original JUKO driver/BIOS.

 

[Gustavo]

Ok. If you can get it to work reliably in 16-bit mode then I'll add that as the default device type/transfer mode to the auto detection. If not, I'll make 8-bit mode the default.

I could not make 16-bit mode work reliably. It's better to make 8-bit the default.

 

[maxtherabbit]

I could not make 16-bit mode work reliably. It's better to make 8-bit the default.

Wouldn't that completely defeat the purpose of the card? Whole point is ATA (16-bit) drives in XTs right?

Have you tried any real hard drives? Or just CF cards?

 

[Istarian]

Gave it another go in 16-bit mode. Filesystem got corrupted on the first boot.
View attachment 1313118
Maybe there is some delay in the routines of the original JUKO driver/BIOS.

Perhaps there is a problem with the circuitry involved in reading from the disk? I don't see why there should be corruption in the absence of writing to the disk.

Timing problems could maybe result in spurious writes or the wrong data being read/written, but I'm not sure how you would be able to tell for sure if that was happening.

Maybe try booting from some other media that you know won't touch the disk unless you ask it to?

 

[Gustavo]

The board works fine with the original BIOS in 16-bit mode. Must be some software issue.

Here is a table with the results so far:
- Board set to 8-bit/XT drive: XUB works fine (in 8 bit);
- Board set to 16-bit, ALE JP5 in default position: XUB does not work, CF device name shows garbage;
- Board set to 16-bit, ALE JP5 in alternate position (2-3): XUB boots to DOS but corrupts filesystem;
- Board set to 16-bit, ALE JP5 in default position: Original JUKO BIOS boots system. Works fine, but limited to specific HD sizes.

 

[Krille]

Maybe there is some delay in the routines of the original JUKO driver/BIOS.

I guess you could say that. It is extremely inefficiently coded. This is the write loop in version 1.2;

seg000:06F5                 mov     cx, 256
seg000:06F8                 mov     dx, 320h        ; DATA_REGISTER
seg000:06FB                 cld
seg000:06FC                 cli
seg000:06FD
seg000:06FD WriteSector:                            ; CODE XREF: seg000:0701j
seg000:06FD                 lodsw
seg000:06FE                 xchg    ah, al
seg000:0700                 out     dx, ax
seg000:0701                 loop    WriteSector
seg000:0703                 sti

And the read loop;

seg000:07A2                 mov     cx, 256
seg000:07A5                 mov     dx, 320h        ; DATA_REGISTER
seg000:07A8                 cld
seg000:07A9                 cli
seg000:07AA                 push    ax
seg000:07AB
seg000:07AB ReadSector:                             ; CODE XREF: seg000:07B4j
seg000:07AB                 in      ax, dx
seg000:07AC                 mov     es:[di], al
seg000:07AF                 inc     di
seg000:07B0                 mov     es:[di], ah
seg000:07B3                 inc     di
seg000:07B4                 loop    ReadSector
seg000:07B6                 pop     ax
seg000:07B7                 sti

Each word of data is byte-swapped before writing and the reading is done with a long delay between IN instructions. The byte-swapping makes the on-disk format incompatible with everything else and there are far better methods of creating the required delay between reads (assuming that's the reason behind the convoluted read loop). Interrupts are disabled during transfers so disk transfer benchmark results will probably be a bit inflated. Generally speaking, the BIOS is full of weird and very inefficient code but that's par for the course when it comes to option ROM BIOS code from the '80s and early '90s.

 

[Gustavo]

I'm not 100% sure, but I remenber that CF cards written by the Juko's ROM can be read by a modern machine. So the card probably swaps the bytes another time, making the disk format compatible. I'll verify that information and reply here.

 

[maxtherabbit]

I'm not 100% sure, but I remenber that CF cards written by the Juko's ROM can be read by a modern machine. So the card probably swaps the bytes another time, making the disk format compatible. I'll verify that information and reply here.

You sure the thing was in 16bit mode when you recorded that memory?

 

[Krille]

I'm not 100% sure, but I remenber that CF cards written by the Juko's ROM can be read by a modern machine. So the card probably swaps the bytes another time, making the disk format compatible. I'll verify that information and reply here.

Don't bother. Soon after posting I realized that the code in the read loop is equivalent to a single STOSW which means it doesn't swap when reading. So there has to be a swap done in hardware, and it is probably done when writing as you said.

Let's see if all it takes is a simple byte-swap. The attached file is the XT version of XUB r632 configured for this controller with a quick hack consisting of XCHG instructions added to the write loop. If this works I might be able to add proper support for these controllers.

 

[Gustavo]

Thanks. Will try as soon as possible

 

[Krille]

I went ahead and added proper support for this controller. The attached file is a full release of XUB r633 and it includes everything. Once this is confirmed working I will commit the changes to the repository.

Gustavo, please help me check that the following works;
1.) "Auto Configure" in XTIDECFG should now detect this controller (the detection will configure the BIOS to use 16-bit transfers).
2.) Manual configuration can be done of course. Just select "Juko D16-X" in the list of device types/transfer modes. It will display the base address and control block address but not the IRQ selection option since there are no IRQ selection jumpers on this controller. The addresses are displayed mostly for informational purposes - you can change them but that will not work unless you modify the hardware, obviously.
3.) The original BIOS appears to only support one drive? If you can, please try using two drives (master and slave). If it doesn't work for some reason, then I might add code to disable detection of the slave drive on this controller when running "Auto Configure".

Merry Christmas everyone!

 

[Gustavo]

I went ahead and added proper support for this controller. The attached file is a full release of XUB r633 and it includes everything. Once this is confirmed working I will commit the changes to the repository.

Gustavo, please help me check that the following works;
1.) "Auto Configure" in XTIDECFG should now detect this controller (the detection will configure the BIOS to use 16-bit transfers).
2.) Manual configuration can be done of course. Just select "Juko D16-X" in the list of device types/transfer modes. It will display the base address and control block address but not the IRQ selection option since there are no IRQ selection jumpers on this controller. The addresses are displayed mostly for informational purposes - you can change them but that will not work unless you modify the hardware, obviously.
3.) The original BIOS appears to only support one drive? If you can, please try using two drives (master and slave). If it doesn't work for some reason, then I might add code to disable detection of the slave drive on this controller when running "Auto Configure".

Merry Christmas everyone!

Hi Krille!

Tried the new version with the board in 16-bit mode. JP5 had to be in alternate position (2-3), otherwise the BIOS wouldn't detect the CF card (shows garbage as the device name).

1. Auto Configure worked fine.
2. Worked fine too. Just selected D16 from menu and everything was right.
3. Unfortunately I don't have another CF card adapter or a IDE hard disk, but configured the CF adapter as slave. XTIDE BIOS detected the drive correctly, but couldn't boot from it.

It seems there are no more file system corruption. I really did't understand why.

Merry Christmas!!

 

[Gustavo]

"...which means it doesn't swap when reading. So there has to be a swap done in hardware, and it is probably done when writing as you said."

You did explain it before.

So everything is working as expected!

 

[Krille]

CF cards often do not work jumpered as slave so I'm guessing that's the reason for the failure to boot. If there's no problem with corruption I think we can call this a success! Have you done any performance testing? I expect XUB to have quite a bit higher throughput than the original BIOS due to loop unrolling (and being more efficiently coded in general).

I'm too tired now so I'll commit the updated code tomorrow. Thank you Gustavo for the help with testing!