Thanks for all the input on this board. I do appreciate it greatly. My XT-IDE kit is coming today so hopefully I can start playing with emm drivers and whatnot a bit later today, granted I get time to head out to the garage later. I will see if I can find the Juko branded 2.32 bios out there somewhere and try to burn that and see if that fixes the 640k barrier.

You can find the Juko ST 2.32 BIOS here:

https://www.ultimateretro.net/en/motherboards/3346

Well I searched for juko 2.32 and downloaded the BIN file out of an archive that was a mame/mess archive. Flashed it on a new AT28C64b chip and the machine does indeed count to 1024k now, however this introduced a new issue where the floppy detection takes a very long time compared to the old BIOS. Additionally the same DOS 3.3 floppy that worked before to boot, now fails and it just resets the computer over and over again instead of popping up a insert boot error replace disk type message.

Went a few posts up and downloaded the 2.30 BIOS attached here and tried that BIOS and it had the same issue. So maybe this board is just configured a tad bit differently than the offical Juko board?

Thanks Turbooo, that wasn't the same link I found for 2.32. I will download this and do a file compare to make sure i downloaded the right BIOS before.

Well that image was duplicated for a 64k image. Split it back down to 8k and did a FC on the two files with the /B switch and no differences encountered, so it must have been the same BIOS file I tried earlier. Maybe this Juko BIOS doesn't like my floppy controller, which I can't seem to find any info on or documentation other than what is printed on the PCB itself.

Assuming that JP9/10 configures the onboard BIOS for your controller card, can you see if setting it to disabled has any effect? I’ve noticed if the floppy drive isn’t detected on my board it will also reboot, I wasn’t sure if it was just my board being wonky/faulty (it was a mystery eBay special) but maybe that’s not the case after all…

That was it Turbooo, jumpering the BIOS in the floppy controller to disabled got me booting off the floppy again. What is the advantage of enabling the BIOS in the floppy controller? Just for High Density support?

That’s the main use case that I’m aware of, anyways.

JP12/13 only let you jumper between AT and PS/2 modes, I wonder if there is some incompatibility that makes it not quite work correctly with an XT.

My Juko NEST also reports 1024kb.
I agree with others that the BIOS on there has probably been replaced with something generic.
But, maybe there was a reason for the swap. Perhaps there's something in that BIOS that's better than the original.
Reporting 640kb rather than 1024kb is really not that big of a deal if you gain something useful.

With the original bios, If the memory count doesn't see or count past 640k, will the juko utilities still see that memory?

Some Juko XT boards can only address 640kb of the 1024kb, but the rest can be used as a ram disk with a driver called CDISK.SYS driver, which creates a 384 KB ramdisk.

See here:
https://github.com/86Box/86Box/issues/4342#is … ment-2044706077

After a little "investigation" I've found these info:
TAMCS00001-1.pdf = https://github.com/86Box/86Box/files/14917165 … AMCS00001-1.pdf

Drivers are here:
JUKO.zip = https://github.com/86Box/86Box/files/14917578/JUKO.zip

The file CDISK.SYS creates a 384KB RAM Disk
The PC supports 1MB RAM but the 384KB are for RAM Disk only

Windows 3.1 034f & New Deal Office with updated kernel 100% can "swap/page" to the RAM disk, or use as EMS, for best results
here is that GEOS kernel btw: https://archive.org/details/geos_20240815

aazard wrote on 2024-08-15, 18:23:

Some Juko XT boards can only address 640kb of the 1024kb, but the rest can be used as a ram disk with a driver called CDISK.SYS […]
Show full quote

Some Juko XT boards can only address 640kb of the 1024kb, but the rest can be used as a ram disk with a driver called CDISK.SYS driver, which creates a 384 KB ramdisk.

See here:
https://github.com/86Box/86Box/issues/4342#is … ment-2044706077

After a little "investigation" I've found these info:
TAMCS00001-1.pdf = https://github.com/86Box/86Box/files/14917165 … AMCS00001-1.pdf

Drivers are here:
JUKO.zip = https://github.com/86Box/86Box/files/14917578/JUKO.zip

The file CDISK.SYS creates a 384KB RAM Disk
The PC supports 1MB RAM but the 384KB are for RAM Disk only

Windows 3.1 034f & New Deal Office with updated kernel 100% can "swap/page" to the RAM disk, or use as EMS, for best results
here is that GEOS kernel btw: https://archive.org/details/geos_20240815

Hi!

Here is disassmbled EMS driver (with some debug support and bug-hunting).

Its decoded and disassembled by my friend and tested on 86Box and real hardware.

https://github.com/indrekis/JukoST_EMS

PS. On Github there link to friens's article about this board and RAM-disk disassembly and extended 384KB works logic.

Does Windows 3.1 034f (a beta release) have support for real mode?

Anonymous Coward wrote on 2026-06-12, 02:12:

Does Windows 3.1 034f (a beta release) have support for real mode?

Hi, I got it running on an first gen Commodore PC-10 with the split mainboard.
The PC-10 has been upgraded with a NEC V20, however. Not sure about 8088 compatibility.
The Windows 3.1 Beta uns fairly well, but EMS support was removed.
So there's only little memory left for to applications (UMBs may help to free used space in conventional memory).
Still, I think it's nice to have access to the classic screensavers and modern Program Manager/File Manager.
The supplied 800x600 SVGA driver works in Real-Mode, as well.

Here are some screenshots taken with an emulator.:
Re: New SVGA Windows 3.x driver supports multiple resolutions and color depth modes
But I can take some screenshots from real hardware, too

Edit: Edited. That's the PC model I'm using, btw.
Has been upgraded with VGA, EMS, RAM/UMB card, 8087/V20 etc.