ELKS on Book 8088

[Vutshi]

Description
I have a new and shiny laptop based on the 8088 processor. You can read about the Book 8088 on arstechnica. It's a fascinating device that allows for easy CPU changes. I've already tried the V20, Intel 8088, and a Soviet clone of the 8088, and they all work well in DOS. However, I'm currently having trouble getting it to boot ELKS out of the box.

UPDATE: About hardware details see the blogpost in the comment #1619 (comment)

UPDATE2: More hardware details from Sergey Kiselev:

The schematic of Book8088 is quite interesting.
In addition to the 8088 CPU and the 8087 FPU, it uses an original 8284 clock generator, 8288 bus controller, 8237 DMA controller, 8259 PIC, and 8253 PIT
It looks that they've got most of the discrete logic functionality for an XT motherboard into a CPLD, also the CGA controller functionality is implemented as two CPLDs and the original 6845 CRT controller. According to the pinout, the CPLDs seem to be Altera MAX7000S series or Atmel ATF1500AS series in PLCC84 package.
They also use some kind of microcontroller to implement the XT keyboard, that is interfaced directly to the XT motherboard logic CPLD
The system uses two EPROMs (why not flash ROMs?!) - one 27C512 for the BIOS, and one 27C256 for CGA font
The system memory uses one 512KB SRAM and one 128 KB SRAM chip. CGA uses a 32 KB SRAM for the video RAM

Another technical detail, the data bus of all 82xx controllers, the XT logic CPLD, and the memory are connected directly to the CPU data transceiver. This probably will reduce reliability when using external ISA cards. Typically, these things sit behind an additional transceiver...

Configuration

• Version (commit or release): ELKS v0.6.0 release image hd32-fat.img and hd32mbr-fat.img. Minix versions give identical results.

• Screenshot(s):
  hd32-fat.img starts to boot a little bit:
  
  hd32mbr-fat.img doesn't boot:
  

Additional information

• I suspect that CHS is probably wrong but Book 8088 has no FDD so I can not follow the procedure. Instead I use analyze_mbr.c to read the three CHS bytes of the DOS disk which boots fine:

sudo ./a.out /dev/sdd
** Opening drive /dev/sdd..
** MBR magic bytes in place!
** Analyzing Partition 0
	This is bootable
	Partition is 995967 sectors (486.31MB)
	Starting CHS values C=1, H=1, S=0
	Ending   CHS values C=254, H=63, S=61
	Partition starts at sector number 63 (31.00KB in)
	Partition filesystem id is 6
** Analyzing Partition 1
	This is not bootable
	Is an empty partition
** Analyzing Partition 2
	This is not bootable
	Is an empty partition
** Analyzing Partition 3
	This is not bootable
	Is an empty partition

ELKS gives me parameters which are different:

$ sudo dd if=/media/ubuntu/3.0Tb/1/15/Book8088/hd32mbr-fat.img of=/dev/sdd bs=1024
31783+1 records in
31783+1 records out
32546304 bytes (33 MB, 31 MiB) copied, 14.187 s, 2.3 MB/s

$ sudo ./a.out /dev/sdd
** Opening drive /dev/sdd..
** MBR magic bytes in place!
** Analyzing Partition 0
	This is bootable
	Partition is 63504 sectors (31.01MB)
	Starting CHS values C=1, H=1, S=0
	Ending   CHS values C=16, H=63, S=63
	Partition starts at sector number 63 (31.00KB in)
	Partition filesystem id is 128
** Analyzing Partition 1
	This is not bootable
	Is an empty partition
** Analyzing Partition 2
	This is not bootable
	Is an empty partition
** Analyzing Partition 3
	This is not bootable
	Is an empty partition

[Vutshi]

One more thing. The BIOS of the device can be found here https://github.com/skiselev/8088_bios. The unknown Chinese manufacturer of the Book 8088 just took the Sergey Kiselev's BIOS and modified it a little. He back ported the changes to the master branch recently. As far as I can see the changes mainly concern Turbo mode and keyboard INT 09h.

[ghaerr]

Hello @Vutshi,

Looks like some new fun on your shiny new 8088 laptop! I will read more about it, thanks for the links.

hd32-fat.img starts to boot a little bit:
ELKS****1!

The 1 above means disk read error, and I would guess probably an invalid CHS value as you're probably thinking.

You might also try booting the hd32-minix.img version instead of FAT, as the FAT boot loader is more complicated and uses BIOS Parameter Block values from the boot sector which might not be correct.

Welcome to ELKS MBR Boot Manager
No bootable partition

It is a contradiction that the ELKS MBR says no bootable partition, while the mbr-analyzer recognizes a boot partition. I don't yet know the reason for this, we will have to investigate further.

I would suggest using MINIX rather than FAT boot images, and don't use an MBR image, just a flat image, and see what else we find. This reduces the complexity of the boot and ELKS will boot non-MBR HD images as though they were large floppies, as long as the CHS values are correct. The ELKS HD image CHS values can be changed by editing CONFIG_IMG_SECT/HEAD/CYL values in .config for the MINIX image HD build.

Thank you!

[Vutshi]

Hi @ghaerr

You might also try booting the hd32-minix.img version instead of FAT, as the FAT boot loader is more complicated and uses BIOS Parameter Block values from the boot sector which might not be correct.

We tried Minix versions as well, they give exactly same results as FAT images.

The ELKS HD image CHS values can be changed by editing CONFIG_IMG_SECT/HEAD/CYL values in .config for the MINIX image HD build.

Then what values should I write there? The same as reported by DOS disk which boots well? Note, that I use physically different CF cards for DOS and ELKS.

Best

[ghaerr]

We tried Minix versions as well, they give exactly same results as FAT images.

You mean that MINIX images showed ELKS *****1!? This means error on the sixth sector read. For MINIX images, the CHS should have the boot block at 0/0/1, and continue reading 0/0/2, etc until max sectors, then the head number is incremented, then the cylinder, etc. The ELKS boot prepares a DDPT and attempts to perform a multi-sector read, which could be failing due to BIOS strangeness. Perhaps #undef FAST_READ in bootblocks/boot_sect.S line 54 and build a new image.

Then what values should I write there? The same as reported by DOS disk which boots well? Note, that I use physically different CF cards for DOS and ELKS.

You mean that the CF card is a different size?

I'm not sure what the CHS values should be to correct this at this point, I am hoping that the multi-sector reads desribed above help. However, the FAT boot loader doesn't use FAST_READ and it's still broken. So it likely won't work.

We have had other issues in the past related to the BIOS not handling disk reads after BIOS DISK RESET calls. I don't recall the exact details.

I am also a bit confused with the MBR analyzer showing start sector 0, as sector 1 is the default numbering scheme. Also, ELKS MBR when you typed 1 showed no partition, which is not correct, as there is a partition there. Normally however the partitions start at a cylinder boundary and these are showing Sector 63 (which is usually the last sector of a 63-sector disk numbered 1-63).

We have others running ELKS on Sergey's BIOS. Do you have more information on the changes made required for your laptop? Will it run with the original unmodified Sergey 8088 BIOS?

[Vutshi]

@ghaerr

You mean that MINIX images showed ELKS *****1!?

Yes. But after looking closely I also see three dots in front:

You mean that the CF card is a different size?

Yes, DOS card is 512Mb, ELKS one is 256Mb

We have others running ELKS on Sergey's BIOS. Do you have more information on the changes made required for your laptop? Will it run with the original unmodified Sergey 8088 BIOS?

Currently I run the stock BIOS. As soon as new flash chip arrives I will use Sergey's Book8088 image of his BIOS. Sergey says that XT-IDE BIOS extension is outdated on the stock BIOS, so I will stop experimenting until switching to Sergey's new BIOS image.

[ghaerr]

But after looking closely I also see three dots in front

Ah, I was in error in my last reply: a . means successful read and * means retry. This means that the first three sectors loaded properly, and the fourth had the normal five retries then disk read error.

For MINIX non-MBR disks, the first sector (physical sector 1) would be read by the boot loader, then the ELKS MINIX boot loader (when #undef FAST_READ is not defined so no multi-sector reads), the second sector of the 1K book block is read (physical sector 2), producing the first .. Then, the MINIX boot loader (running from the just-loaded second sector) reads the 1K MINIX super block into memory which would be physical sectors 3 and 4 on cylinder 0 head 0, producing the next two .s. It appears then that the sectors trying to be read after reading the superblock (which would be the location of the root inode) might not be returning the correct data.

What brand floppy emulator are you using with the CF cards? IIRC we have had some issues with floppy emulators as well.

[tyama501]

I have read about that 8088 book article before. Very interesting.

Does the book have floppy emulation from the USB port? (Maybe no?)
If you can boot from the USB with the floppy image, may be you can install to the harddrive with sys command.

[Vutshi]

@ghaerr

Ah, I was in error in my last reply: a . means successful read and * means retry. This means that the first three sectors loaded properly, and the fourth had the normal five retries then disk read error.

Does it make sense that unlike minix, the FAT image didn't manage to produce the three dots?

What brand floppy emulator are you using with the CF cards? IIRC we have had some issues with floppy emulators as well.

I don't really know.
According to the system block diagram the CF card goes into IO chip:

The IO chip seems to be realized on a programmable logic device ATF1508-XT IO:

The arstechnica article says that "Hard disk functionality is provided by an integrated XTIDE controller". It uses XTIDE BIOS extension.

[Vutshi]

Hi @tyama501

Does the book have floppy emulation from the USB port? (Maybe no?) If you can boot from the USB with the floppy image, may be you can install to the harddrive with sys command.

It seems the USB port can be used for storage devices only after booting into DOS and loading CH375DOS.SYS driver
BOOK8088说明书CN new.docx

[tyama501]

〉This reduces the complexity of the boot and ELKS will boot non-MBR HD images as though they were large floppies,

I am not sure the BIOS can handle the disk without MBR. Is it possible?

I think CHS values of the whole disk depends on CF cards and the IDE emulater so it might be better to use the same CF card with the MS-DOS.
Then create a image with H:63, S:61 FAT partition elks image with MBR as the MS-DOS.

[tyama501]

Oh easier way.

If you can load the MS-DOS partition image and elks floppy imge on qemu, may be you can install
to the partition using sys command.

(Although in this case you need to format the MS-DOS first.)

[ghaerr]

I am not sure the BIOS can handle the disk without MBR. Is it possible?

The BIOS disk read functions don't know or care about the MBR itself, as the disk contents are accessed solely though C/H/S parameters. As long as the filesystem starts in the sector following the boot block(s) (1 for FAT, 2 for MINIX), this shouldn't be an issue.

I think CHS values of the whole disk depends on CF cards and the IDE emulater so it might be better to use the same CF card with the MS-DOS.

I am not aware of how CF cards calculate CHS, but if H/S varies with CF card size, this could definitely be an issue. Perhaps try this instead of rebuilding MINIX image with below option:

Then create a image with H:63, S:61 FAT partition elks image with MBR as the MS-DOS.

That's a very good idea - the MINIX ELKS floppies and HD images require the max head and sector value to be stored near the end of the boot sector, and this must match the HD emulator-expected CHS. For FAT ELKS floppies, the max head and sector values are stored in the DOS BPB block at the beginning of the boot sector.

[Vutshi]

@ghaerr
Before going into compiling ELKS images with various CHS values we decided to check what DOS thinks about CHS of the drive. It turns out to be a rather peculiar drive. Some utils don’t see it at all (idediag). Some (CheckIt) report an error but provide the CHS data

The parameters are different from what is reported by analyse_mbr.c. This little program reports raw values of the three CHS bytes. According to Wikipedia it has to be decoded and rearranged to get true CHS but even taking all of this into account I cannot get values which agrees with CheckIt data.
Strange disk. We are waiting for flash chips to flash Sergei’s BIOS with up to date XTIDE BIOS

[ghaerr]

@Vutshi,

Some utils don’t see it at all (idediag). Some (CheckIt) report an error but provide the CHS data
We are waiting for flash chips to flash Sergei’s BIOS with up to date XTIDE BIOS

I had thought that you were already running the updated BIOS with XTIDE support... my latest theory based on your new evidence is that the drive controller isn't fully IDE compliant (thus the errors with DOS diagnostics programs) but that it still works with some boot programs, possibly the result of timing interactions with the existing likely deficient BIOS when booting DOS.

The default ELKS hd32 images are built with heads:16 and sectors:63. The max cylinders doesn't matter at boot time (since without partitions will always be 0), and is only an issue later if it conflicts with the filesystems internal size spec. Even if the HD sector size is 61 not 63, that difference should not produce the results seen in the boot screens, so I'm still thinking that this issue has something to do with the way the drive controller is being accessed by the BIOS. I haven't yet dug into the XTIDE universal BIOS, although your supplied link lists some interesting information in the Known problems section, especially with CF cards and their MBR requirements (!).

[ghaerr]

@Vutshi,

I read the Ars Technica article on the Book 8088, very interesting!

I don't know if you happen to have read the MinusZeroDegrees website about issues relating to XTIDE, I found this particular link interesting: https://minuszerodegrees.net/xtide/XT-IDE%20-%20Problems.htm

That page details some issues with XTIDE and the sometimes requirement for the CF card to have an MBR boot block, or the boot fails. I am guessing the reason might be that the XTIDE controller firmware/software requires the MBR in order to otherwise setup the CHS for the emulated drive (even though the MBR doesn't technically specify the drive CHS values). It is also possible that XTIDE w/CF may require a FAT formatted disk and not work with ELKS MINIX filesystems. We will have to wait and see what is learned with the updated BIOS from Sergey.

Finally, it could be the case that there is a problem with ELKS' MBR tables that render it incompatible with XTIDE, although I suppose that unlikely. I have some seen some BIOS code that handles reading and writing of the boot sector (MBR in this case) specially, and that could be happening here. The proposed solution to this problem is to run FDISK.EXE /MBR on the problem boot CF card using DOS v5.0 or later.

Here is another page of interesting information on XTIDE: https://minuszerodegrees.net/xtide/XT-IDE%20-%20Basics.htm

[toncho11]

https://github.com/jbruchon/elks/wiki/Installing-HD-image-on-physical-media

There are some comments at the bottom of the page that might be important.

[ghaerr]

There are some comments at the bottom of the page that might be important.

Do you mean the issue with boot sometimes failing when IDE probing is turned on? I fixed that a while ago, if configured ON, it will now time out rather than hang if an IDE isn't present. The current Book 8088 boot problem is occurring during the time the boot loader is reading in the kernel, so kernel configuration isn't an issue (yet).

[toncho11]

I see.

@Vutshi is using stock images of the 0.6 release, right. Maybe using the current code base 0.7 will yield better results.

[ghaerr]

Maybe using the current code base 0.7 will yield better results.

Agreed, there's been lots of progress since 0.6. I think we should push out v0.7, since there has been not so much activity and lots of changes?

[Vutshi]

@ghaerr

Agreed, there's been lots of progress since 0.6. I think we should push out v0.7, since there has been not so much activity and lots of changes?

That would be cool as I have some problems currently with my Linux computer which I usually use to build ELKS.
P.S. Our new fash chip is out for delivery. Soon we will try Sergey’s latest BIOS

[toncho11]

@Vutshi It seems a minix image of 0.7 works as pointed in #1370 (comment)

[toncho11]

@Vutshi You should try hd64-minix.img of 0.7 with Rufus.

[ghaerr]

Hello @Vutshi, here's the latest hd64-image.img (soon to be v0.7.0) for you to try, as discussed in #1370 (comment). It's a non-MBR image, I can't remember exactly why ELKS isn't creating an MBR version. We'll likely have to figure out why the 32MB FAT image won't boot after v0.7.0, but hopefully this image will work for you as it did for @tt1542.

hd64-minix.img.zip

[Vutshi]

Thank you @ghaerr, I’ll try it asap!

[ghaerr]

@Vutshi, as per @tt1542's 360k FAT floppy boot working OK described in #1625 (comment), here's a current version for that as well for your testing:

fd360-fat.img.zip

[Vutshi]

@ghaerr
We have made some progress, but we are not fully there yet.
First of all, the latest version of Sergey's BIOS is installed and works well as can be seen in the screenshots below. We tried both ELKS 0.7 images written by Rufus and dd with identical results:
hd64-minix.img.zip

fd360-fat.img.zip

The small fd360 image is tested using two different CF card (32Mb and 256Mb) with the same results. This was done because we noticed a strange behaviour of the 256Mb card. Namely, we cloned a working CF card containing DOS onto this 256Mb card using dd and the cloned version didn't boot at all. The ELKS at least tries to boot from this card...

[Vutshi]

Quite strange. I attempted to create a DOS boot disk using Rufus (which has that option), but unfortunately, Book8088 doesn't seem to boot from either of the two CF cards I have.

I have already placed an order for new CF cards.

[ghaerr]

I just optimized sl to not emit cursor positioning on each character: its running about 40x faster, too fast to see on QEMU. So processing those sequences is a big part of the speed issue, along with all the data. Too much for poor little 8088...

I don't really want to spoil the fun and fix sl, since there may be other ways to use this to speed things up. I think perhaps adding a --fast option (or perhaps --slow?) may be the way to keep riding down the tracks here. Which option would you vote for?

[ghaerr]

@Vutshi, see #1720, sl should run quickly now on 8088's by default. The older slow output can still be produced (for faster system performance measurement or just wanting to actually see the train) by using sl -s.

[ghaerr]

There still may be ways to speed up sl -s processing, but if #1720 is reasonably fast, then it can be summarized that the overhead of processing ESC sequences is fairly high in ELKS, along with the fact that 8x as much data must be produced for each character output.

[toncho11]

@Vutshi you can use ls -U to disable sorting in ls, which would make ls run faster.

[Vutshi]

@ghaerr
This is great! I’ll test the new express train tomorrow.
Is it possible to include sl and time to all ELKS images by default? It seems to fit into 360K image.

[Vutshi]

Btw, can matrix be accelerated in the same way?

[Vutshi]

@Vutshi you can use ls -U to disable sorting in ls, which would make ls run faster.

I thought it was already incredibly fast, completing the listing of a 360K ELKS disk in just 20 seconds. :)

[ghaerr]

Is it possible to include sl and time to all ELKS images by default? It seems to fit into 360K image.

Running df on 360k only shows 10k left, and sl is 13k. My kernel is a development kernel so it might be a bit larger but it seems things are (as always) quite tight on 360k - so no. The original 360k contents were designed for a more technical user. Perhaps we need one with mostly games? This business of exactly what should be one which-sized floppies does need some more discussion.

We do have executable compression that can shrink every executable by 30+%, but some people complained about the decompression speed, especially on slow systems. I have on my list of things to do to possibly compress less-used programs - there isn't a way to do that now, only all programs on disk or none using the image build system.

can matrix be accelerated in the same way?

Looking at the matrix source, it outputs a 6-8 byte sequence per displayed character to set one of 16 colors... so that's likely why its as slow as sl was. Unlike sl and the consecutive position sequences, there's no way to omit the color sequences or matrix wouldn't be shades of green. There may be a way to slightly speed up ELKS console processing of these sequences, but in general its probably not going increase the speed to what we'd want to see. There are other ways of speedup, like drawing directly into the console RAM, but that could be considered a hack and would have to be special cased, as matrix will also run on ELKS and display to your terminal emulator using the ANSI sequences (all using the TUI library, which is kind of cool).

I also notice that matrix is using a delay, which you might consider removing. In elkscnd/tui/matrix.c, see:

void delay(long msecs)
{
    fd_set fdset;
    struct timeval tv;

    return; // <---- ADD THIS LINE
    FD_ZERO(&fdset);
    tv.tv_sec = 0;
    tv.tv_usec = msecs * 1000;
    select(0, &fdset, NULL, NULL, &tv);
}

I can see that the delay processing (for sl, matrix and others) needs to calculate the time per display cycle first and possibly not delay at all on slow systems.

Let see how fast the intercity train is, and then see what makes sense to work on speeding up. What we need is a kernel profiler, actually.

[Vutshi]

Running df on 360k only shows 10k left, and sl is 13k.

Right. I forgot that I like to switch off unused features like FAT and Ethernet. Then I have both more space for fun stuff and more troubles like unbootable FAT ELKS )

[Vutshi]

see #1720, sl should run quickly now on 8088's by default.

At last, the train has evolved into the true era of steam power, ready to conquer the 8088 tracks:

The older slow output can still be produced (for faster system performance measurement or just wanting to actually see the train) by using sl -s.

Since now it is so fast we can probably restore pause after each frame, at least with sl -s

UPDATE:
No need in the slow option. usleep(40000) is working as expected in MartyPC by slowing down the train just by 8 seconds which is exactly how long it runs in QEMU.

[Vutshi]

Holy cow!
There is a second train :)

[toncho11]

@Vutshi you can use ls -U to disable sorting in ls, which would make ls run faster.

I thought it was already incredibly fast, completing the listing of a 360K ELKS disk in just 20 seconds. :)

In the past ls on FAT was slow, but I see you do not use FAT.

[ghaerr]

No need in the slow option. usleep(40000) is working as expected in MartyPC by slowing down the train just by 8 seconds which is exactly how long it runs in QEMU.

Good to know that the timing function is working properly in MartyPC. When you test again on real hardware, that will be interesting to see whether Book 8088 and Schneider also work properly, as I've been suspecting some possibly timer related discrepancies on either of them.

I think what is needed for both sl and matrix is a new function that calculates a minimum cycle time between drawing (set to 40000 or whatever), based on real time. Then the total delay, not just the end-of-cycle delay, will be specified. Then, the programs will run at the same speed (or slower) on all systems.

Given that, for research purposes, I can see a need for -s (slow, send all escape sequences totaling 36k etc), and -f (fast, skip any delays as described above). This will be useful for getting a visual on how fast or slow a system is, while the default operates at the designed cycle speed.

There is a second train :)

What?! Did you actually type sl -lR / by mistake? :)

There's actually four options: -a for there's been a train accident, -F for fly mode, -l for logo, and -c for C51 train (vs D51 normal).

You better get out and try these, conductor. Especially -F, since you've probably not yet seen a train fly.

[Vutshi]

What?! Did you actually type sl -lR / by mistake? :)

Yes, the program actually works as intended — it confuses people.
We also did the mistake in reverse during the first attempt to time the train:

Initial guess was that time is not functioning. :)

[Vutshi]

Interesting new blogpost about Book8088.

The author of the MartyPC emulator also acquired Book8088 and noticed it was slightly faster than the original IBM XT due to faster static memory. He fixed this difference with a hardware hack, enabling the machine to run the tricky 8088MPH demo.
Apparently Book8088 is a very close replica of the IBM XT.

[Vutshi]

Hi @ghaerr,

The railway system has resumed operations, now operating more efficiently than ever:

Even the slowest train is now over twice as fast as the original, preventing tests of time overflow. We had to stack three trains together to surpass the 32-bit barrier:

It took some time to discover how to feed a shell script to time. Unlike my macOS, ELKS doesn't recognize ./script.sh as a valid executable.

Best

[ghaerr]

Hello @Vutshi,

Thanks for your follow up testing and screenshots. Glad to see we now have timely train service, and that time also works!

ELKS doesn't recognize ./script.sh as a valid executable.

What?! Geez. I'm testing that over here and no problem. I would guess you're probably running sash as /bin/sh? sash doesn't support shell scripts. (In certain circumstances sash will fork/exec /bin/sh to run more complex commands, but not normally for shell scripts marked executable). You can tell whether you're running ash (bash) by typing set at the prompt - it will return the environment, whereas sash will error.

[Vutshi]

What?! Geez.

I think I was unclear. What doesn’t work is time ./script.sh

[ghaerr]

What doesn’t work is time ./script.sh

Oh, I see now. It looks like time just execs (calls the kernel directly) it's argument, and for ELKS, the kernel doesn't support an auto-loaded "script processor" in the shebang-style #/bin/sh etc nor will it default to exec'ing a shell to run a shell script without a shebang, both like most modern systems do.

We could change this to internally call system(...), but that has it's own problems: 1) on slow systems when a shell script isn't passed, this method would still have to load in /bin/sh regardless, which could significantly slow down the reported timing as well as require up to twice the memory; and 2) on systems configured without ash as /bin/sh, system would run sash which may not work well as sash doesn't support all shell scripts.

Overall, I'm not sure if an attempted fix buys us very much... what do you think?

[Vutshi]

@ghaerr I think it is better to keep it simple; leave it as it is.

[Vutshi]

I think now we can close this issue given that there are no more issues with Book8088.
I have some questions regarding Schneider. Clock has to be adapted to its RTC chip and keyboard layout needs some tweaking. I’ll open a new issue about it.

[ghaerr]

Sounds good @Vutshi!

[rafael2k]

I want to buy a Book 8088 to run ELKS on bare metal. Which version should I buy?
In https://aliexpress.com/item/1005005528944178.html I see both CGA and VGA versions. Will both work with ELKS? Will the ISA adapter also work (I'd love to use NIC!)?

[ghaerr]

Hi @rafael2k,

Sounds fun! I wasn't aware that Book had a VGA version, but for the extra $20 its probably worth it. Although the VGA version hasn't been tested, I'm pretty sure it should work out of the box. If not, we'll be able to get it running for you. ELKS supports EGA/VGA out of the box, and the console will run in whatever monitor mode the BIOS has been setup to use.

I'm less sure about the ISA adaptor, it should work with a NIC but we've seen some compatibility issues with 8- vs 16-bit NICs and ISA busses, depending on the NIC and chip used.

[rafael2k]

Cool! I'll give to myself as birthday a VGA version. NIC would be just a bonus for me indeed, but I'll try to find some different ones to test. Any problem I let you know.

Cheers and thanks for the wonderful work on ELKS!