Recent content by pearce_jj

OK, so I've reverted to R631 commit. Auto-make script fix (below) is in place. I won't make another commit - but the next actual commit should work. TortoiseSVN didn't auto-advance Revision.inc for me but I have no experience with that tool other than testing it just now. The fix was to include...

The makefile for the configuration utility (which hasn't changed for seven years) was actually failing at line 131 (@echo...). Now fixed and r632 committed with Copyright.txt updated for 2025 and configuration utility compressed as before. Sorry this has taken so long.

It builds ok (with compression) in a temp folder now and on a backup from a couple of weeks ago, so I’m not sure. Permissions and path looks ok.

The XUB site runs on and builds with Linux. @Krille - sorry missed this. Forgive my ignorance but can you explain the issue with the COM file please?

I’m somewhat intrigued as to how the ROM can be programmed in this configuration - which chip are you using? The board can completely replace the system ROM in slot 8 of a 5155/5160 board. Adding a window mechanism, essentially making the F segment behave like EMS, it might be possible to run...

I experimented a bit with DMA in the context of 8088 corruption style media streaming, but the lousy CGA performance then becomes the next problem. L All of this is just for fun - anyone with real work to do uses something else!

Re disk testing. Tests can only be compared when completed with the same partition and test file size; random throughput is highly skewed by the relationship between the test file size and the FAT allocation unit size. DOS also doesn't keep the entire FAT in memory (since DOS 2) and therefore...

If that card is operating with the original XTIDE Logic design and 16 bit PIO then media compatibility will be patchy due to the timing errors in the design. It should also be noted that CF is a CMOS specification.

Scrolling through the video thumb nails, it's looks ok! Just to note that in respect of EMS4 back-fill, since there is no way to stop the on-board RAM from responding during run time (i.e., without physically removing it from the board) on 5150/55/60, this could be used if the system RAM was...

Nothing from the period should exceed 8.33MHz - this is precisely why VESA local bus appeared, later replaced by PCI and then AGP. Even EISA, commonplace in the x86 server market, ran at 8.33MHz. In fact, ISA uses wait states by default to achieve a cycle time similar to that of the 4.77MHz...

The ISA bus usually runs at somewhere around 8MHz (8.33 often), so the latency of the RAM on an ISA expansion card is not really a factor.

There’s also the timeline - the 386 came to be in 1986 so was already part of the equation by the time, for example, Windows 3 and NT were designed. OS/2 never achieved mainstream status.

All you need is my wipedisk utility. And of course, a lo-tech card for least hassles :)

@rodney - re “I can see the advantage of being able to swap the EMS pages in order to change the game data very fast without even needing to move the data in the pages.” This seems unnecessary on the 286 since it’s protected mode natively provides segmentation whereby loading a new 16-bit value...

Thanks. LIM4 allows for full remapping of conventional memory IIRC so that capability makes sense.