• Please review our updated Terms and Rules here

XTIDE Universal BIOS

Hi,

Is it the good place to discuss with the XT IDE Authors ?

I would like to add the USB Device CH375 Support to the XT IDE, and make suggestion for speed optimization (XT IDE can be speed up on 8086/8088 easily)
 
Hi,

Is it the good place to discuss with the XT IDE Authors ?
The best place is probably via e-mail to make sure everyone is included in the discussion (I don't think Aitotat visits this forum much anymore). E-mail addresses are at the top of XTIDE_Universal_BIOS\Src\Main.asm. But if you prefer to discuss here in this thread then that is also fine of course.
I would like to add the USB Device CH375 Support to the XT IDE, and make suggestion for speed optimization (XT IDE can be speed up on 8086/8088 easily)
I wanted to add support for the CH375 too a few years ago but the lack of documentation (in english) certainly made it a challenge. If you want to take a stab at it then just go ahead. I'll help in any way I can.

Regarding speed optimizations for 8086/8088; I'm guessing it's going to involve loop unrolling? :)
 
The best place is probably via e-mail to make sure everyone is included in the discussion (I don't think Aitotat visits this forum much anymore). E-mail addresses are at the top of XTIDE_Universal_BIOS\Src\Main.asm. But if you prefer to discuss here in this thread then that is also fine of course.

I wanted to add support for the CH375 too a few years ago but the lack of documentation (in english) certainly made it a challenge. If you want to take a stab at it then just go ahead. I'll help in any way I can.

Regarding speed optimizations for 8086/8088; I'm guessing it's going to involve loop unrolling? :)
Hi,

Thanks.
The lack of documentation is not a problem, there are some .PDF and the existing driver/BIOS.

Yes, I unrolled the loop and removed the sub function CALL, Delays (Not Needed)
I also did a 16Bit I/O Version as the LoTech board allow to use the A1 Adress line instead of the A0 (It is working)

I have multiple things to check :
- How the RAM is used to store variables.
- How to integrate a new "Driver" in XT IDE
- How the BOOT Sequence Work (In case of DUAL Board (CF and USB))
- In fact I have to learn everything about XT IDE First :)
- The CH375 part is not a problem at all, it is soooo Simple.
- How to "Officially" Add my work to XT IDE.
- I found part of the XT IDE can be improved to speedUP the 8BIT PIO for 8086 and 8088... So, the XT IDE Can still be improved.

It is more simple to do a Driver than a BIOS.
For example, the DOS Block driver all work in LBA Mode, So We don't really have to worry about the CHS and associated problems...

Did you start coding something anyway ?
 
Last edited:
Hi,

Thanks.
The lack of documentation is not a problem, there are some .PDF and the existing driver/BIOS.

Yes, I unrolled the loop and removed the sub function CALL, Delays (Not Needed)
I also did a 16Bit I/O Version as the LoTech board allow to use the A1 Adress line instead of the A0 (It is working)

I have multiple things to check :
- How the RAM is used to store variables.
The CH375 supports multiple drives, right? Each drive has its own DPT (Drive Parameter Table) so the drive related variables should probably go there. The rest somewhere else in RamVars (see RamVars.inc).

- How to integrate a new "Driver" in XT IDE
I could describe it but it's a bit involved. LOL :D

Seriously though, I'd recommend that you take a look at the revisions where I added the ADP50L and the XTIDE r2 (Olivetti M24) controllers. Should give you a grasp on what to change and where.

Something to consider is that the amount of RAM for variables is limited, so you will probably need to limit the drive detection count to 4 for Lite mode and 8 for Full operating mode. That is the total drive count, including drives detected on other controllers under XUB control.

- How the BOOT Sequence Work (In case of DUAL Board (CF and USB))
You don't have to worry about that at all. It depends entirely on the order of option ROM initialization and drive detection. The order of drive detection (for drives under XUB control) depends on the controller configuration in XTIDECFG (Primary, Secondary, etc).

- In fact I have to learn everything about XT IDE First :)
Have fun! :) (And do not hesitate to ask questions!)

- The CH375 part is not a problem at all, it is soooo Simple.
Some things that come to mind;
* The XUB is made with the assumption that, except for virtual serial drives, there's always an IDENTIFY_DEVICE response. As I understand it, there's no equivalent here so you will have to emulate that, to some extent at least.
* Since the CH375 only supports LBA and not CHS, MODULE_EBIOS (where the LBA stuff in XUB resides) will be a requirement for MODULE_CH375 (Yes, it needs to be an optional module.)
* No IDENTIFY_DEVICE response means there are no P-CHS values. You will need to come up with a sensible way to convert the LBA count to P-CHS, preferably in such a way that it does not waste disk space unnecessarily and also is compatible with "everything else". Perhaps just make it X:16:63? Though that might not be the most efficient way regarding disk space usage. Aitotat might have some idea on how to best do this.
* You will also need to add new strings for these drives since "Master" and "Slave" doesn't make much sense in this context.
* Once a drive has been removed it must not be allowed to be "reinserted" before reboot even if it appears to be the same drive. It's probably obvious why but I'm mentioning it anyway. (As opposed to how the driver works.)

- How to "Officially" Add my work to XT IDE.
Just send a patch to me when ready.

- I found part of the XT IDE can be improved to speedUP the 8BIT PIO for 8086 and 8088... So, the XT IDE Can still be improved.
Yes, I'm aware of that, but only by unrolling the PIO transfer loops even more than they already are, right? The problem is that doing that takes up a lot of ROM space. The current amount of unrolling is a compromise between speed and size. The small builds are too small for more loop unrolling but we might be able to do something about the large builds. Or did you have something else in mind?

It is more simple to do a Driver than a BIOS.
For example, the DOS Block driver all work in LBA Mode, So We don't really have to worry about the CHS and associated problems...
Older DOS versions do not support extended interrupt 13h, so they speak CHS only, which is why we need the LBA to P-CHS conversion as mentioned above.

Did you start coding something anyway ?
No, I did not.
 
The CH375 supports multiple drives, right? Each drive has its own DPT (Drive Parameter Table) so the drive related variables should probably go there. The rest somewhere else in RamVars (see RamVars.inc).
I am still not clear about what is a DTP. I saw in other BIOS Code it is a table for the Disk, and the pointer to these tables is in the IRQ table.
But.. anyway, it need to be in RAM if we want to modify it. (Is it also in RAMVAR ?)
Also, the RAMVar are stored in the PC Ram by stealing 1Kb at the end of the RAM, and it seems to be a really small structure. and you said in another answer that the RAMVAR is small. But 1Kb is Huge.

CH375 can support multiple drive I suppose with USB Hub, but as XTIDE is more for Boot, detect and show only one is sufficent.
Older DOS versions do not support extended interrupt 13h, so they speak CHS only, which is why we need the LBA to P-CHS conversion as mentioned above.
Yes, this is why I say it is more simple in a Driver, we don't have to do the CHS support :)

Yes, I'm aware of that, but only by unrolling the PIO transfer loops even more than they already are, right? The problem is that doing that takes up a lot of ROM space. The current amount of unrolling is a compromise between speed and size. The small builds are too small for more loop unrolling but we might be able to do something about the large builds. Or did you have something else in mind?
I understood the size problem, as doing PIO is more complex on the XTIDE due to the 2 different port for the High and Low. This make the code bigger and even more if unrolled.
Currently the XTIDE read 16Bytes per loop, this is a good comprimize for performance.
I was thinking about doing a lodsw for disk write.. But in fact it is done (I did not read everything in detail, sorry)
Anyway, the 8086 code can be optimized for the Read with a stosw and adding two exchange, it add only one byte to the code and speed up the 8086 read by 10% (If using 16Bit memory)

* No IDENTIFY_DEVICE response means there are no P-CHS values. You will need to come up with a sensible way to convert the LBA count to P-CHS, preferably in such a way that it does not waste disk space unnecessarily and also is compatible with "everything else". Perhaps just make it X:16:63? Though that might not be the most efficient way regarding disk space usage. Aitotat might have some idea on how to best do this.
Thanks for all the tips.
Regarding this specific point, I am aware about the 504Mb disk limit support, due to the problem of using 8Bit for Head.
The XT IDE anyway show big disk with 265 Heads, instead of the physical limit of 16 that existed in the past.
Do you know how the old DOS version behave it there is more than 16 Heads ? Do they just ignore and do like if there is 16, then we lose a lot of space (As 16 Heads are used out of 256)
If we show the USB Disk as x.16.63 like you propose, this block the size to 504Mb, then the boot on FAT16 Disk > 504Mb and FAT32 will not be possible.

With CF, I purchase 256Mb, 512 CF, so I suppose the XT IDE show them as having 16 Heads. this will be more a problem for USB Key as if we want ot use USB, this is with big Keys (4Gb or more) and we need to still have windows able to read them.
 
With the "standalone" CH376 BIOS (https://gitlab.com/hakfoo1/v40-bios/-/blob/main/disc.asm), I queried the device for a LBA sector count, then set the geometry to 16 heads, 63 sectors, and as many cylinders could fit. This caps at 504Mb, and the drives seem to work when taken to another PC (although, obviously, wasting a lot of space). This is based on the assumption that flash drives are cheap and disposable in a way CompactFlash never got to be.

My naive thought is that it doesn't matter how you do the CHS->LBA math as long as it's the ONLY system trying to "set it", and the other systems either access content only LBA direct, or rely on some stored-on-disc info to determine the chosen geometry. It would get uglier if you had one device trying to map a specific CHS location assuming 16 heads/63 sectors, and then another device used 256 heads/63 sectors without actually confirming.

https://github.com/homebrew8088/8088-PC-Compatible/blob/main/bios/CGA_bios/asm/int13.asm does something interesting; it walks the partition table to try to read geometry info out of the Volume Boot Record. I assume this is prone to failure if the partitioning is nonstandard, but it does effectively let people "throw their hands up" and rely on the (assumed) bigger machine that formatted the drive to know its geometry.
 
Is the 16 head limitation fixed in any BIOS limitation? I recall on some controllers, if you had over 1024 cylinders, the high order two bits of DH would get "borrowed" to extend the range of cylinders. But that still left a possible range of 63 heads.
 
Isn't there commands one can call to query the Flash drive controller, ISTR there is and there are set commands that all reputable manufactures should include, It was years ago i read some spec sheets for flash drives though.
 
With the CH375/6, you're not talking directly to the drive, you're talking to the adapter, which handles all the USB overhead. (In certain modes, it will even handle FAT12/16/32 directly and let you address files).

After you do the "mount" operation as part of activating the drive, you can pull back a description structure, which provides model name and some other fields that I recall skipping because they weren't directly useful, then you can also do a "Get capacity" call which returns a LBA count. That's half the problem solved, and how you convert CHS to that is a policy choice

An interesting idea to make use of a bigger drive indirectly-- what if you used a variable offset for the CHS -> LBA calculations?

I could see this being used in two ways:
1) Simulating a system with multiple physical discs-- make access to "disc 0" start with offset 0, and "disc 1" adds an offset of 504Mb/8Gb/whatever, so they don't overlap.
2) As a "disc jukebox" feature-- store the "offset" value somewhere non-volatile (maybe the last few sectors of the disc, or as a NVRAM-backed configuration value), and you could switch between multiple images by changing the offset and rebooting.

The drawback is you'd need special software to touch anything but the first "disc" on another machine.
 
I am still not clear about what is a DTP. I saw in other BIOS Code it is a table for the Disk, and the pointer to these tables is in the IRQ table.
But.. anyway, it need to be in RAM if we want to modify it. (Is it also in RAMVAR ?)
Also, the RAMVar are stored in the PC Ram by stealing 1Kb at the end of the RAM, and it seems to be a really small structure. and you said in another answer that the RAMVAR is small. But 1Kb is Huge.

Drive Parameter Tables are where the drive related variables are stored. Yes, they are a part of RAMVARS. While 1 KB could be considered a lot, keep in mind that it is supposed to store up to 8 DPTs (perhaps even more with virtual serial drives?) and all the other variables needed, plus a 256 byte stack if the BIOS has been made with RELOCATE_INT13H_STACK. This is all available only when XUB has been configured to use Full operating mode. In Lite mode RAMVARS are stored at the top of the interrupt vector table (at 30:0h) where there's a lot less room available. (I don't know exactly how much space we use in each scenario.)

The two pointers you mentioned that are stored in the actual interrupt vector table (at interrupts 41h and 46h) are updated by XUB to point to the DPTs in RAMVARS when using MODULE_COMPATIBLE_TABLES. This is apparently for compatibility with some software. You will have to ask Aitotat if you need more info about that.

CH375 can support multiple drive I suppose with USB Hub, but as XTIDE is more for Boot, detect and show only one is sufficent.

There's no reason to limit the support to just one drive. If we can detect , display and boot from one drive then doing the same with additional drives should be very easy. As I understand it the CH375 starts counting drives (LUNs) from 0 and can go as high as 255. While XUB can't support that many drives it should at least support the first 4 or 8 depending on whether it is running in Lite mode or Full operating mode.

I understood the size problem, as doing PIO is more complex on the XTIDE due to the 2 different port for the High and Low. This make the code bigger and even more if unrolled.
Currently the XTIDE read 16Bytes per loop, this is a good comprimize for performance.
I was thinking about doing a lodsw for disk write.. But in fact it is done (I did not read everything in detail, sorry)
Anyway, the 8086 code can be optimized for the Read with a stosw and adding two exchange, it add only one byte to the code and speed up the 8086 read by 10% (If using 16Bit memory)

I'm struggling to understand what part of the code you're talking about. Can you give an example of what it looks like now and how you want to change it?

Thanks for all the tips.
Regarding this specific point, I am aware about the 504Mb disk limit support, due to the problem of using 8Bit for Head.
The XT IDE anyway show big disk with 265 Heads, instead of the physical limit of 16 that existed in the past.
Do you know how the old DOS version behave it there is more than 16 Heads ? Do they just ignore and do like if there is 16, then we lose a lot of space (As 16 Heads are used out of 256)
If we show the USB Disk as x.16.63 like you propose, this block the size to 504Mb, then the boot on FAT16 Disk > 504Mb and FAT32 will not be possible.

With CF, I purchase 256Mb, 512 CF, so I suppose the XT IDE show them as having 16 Heads. this will be more a problem for USB Key as if we want ot use USB, this is with big Keys (4Gb or more) and we need to still have windows able to read them.
The "Physical CHS" values (P-CHS) are presented by the drive in the IDENTIFY_DEVICE response. The upper limits for those are set by the ATA specification and are (should be) a maximum of 16383:16:63. The P-CHS values are then converted in various ways into "Logical CHS" values (L-CHS) that the BIOS (and DOS) uses. This is what's commonly known as the "geometry translation" and how it is done should preferably be the same across all software/BIOSes for obvious reasons.

The L-CHS values have some limitations. For example, DOS do not support 256 heads which is why the max head count is almost always 255 (some BIOSes allows changing the max to 256). Another limit is the 1024 cylinder count due to how the interrupt 13h interface was originally designed. The infamous 504 MB limit comes from the combination of the 1024 cylinder limit imposed by the interrupt 13h interface and the 16 head limit from the ATA specification.

Anyway, XUB already has code to do the P-CHS to L-CHS translation. All we need is a way to come up with the best possible P-CHS values from the LBA count presented by the CH375. It's very possible that X:16:63 is the standard way of doing that. I'm just not sure (which is why I recommend asking Aitotat about it).
 
With the "standalone" CH376 BIOS (https://gitlab.com/hakfoo1/v40-bios/-/blob/main/disc.asm), I queried the device for a LBA sector count, then set the geometry to 16 heads, 63 sectors, and as many cylinders could fit. This caps at 504Mb, and the drives seem to work when taken to another PC (although, obviously, wasting a lot of space). This is based on the assumption that flash drives are cheap and disposable in a way CompactFlash never got to be.

My naive thought is that it doesn't matter how you do the CHS->LBA math as long as it's the ONLY system trying to "set it", and the other systems either access content only LBA direct, or rely on some stored-on-disc info to determine the chosen geometry. It would get uglier if you had one device trying to map a specific CHS location assuming 16 heads/63 sectors, and then another device used 256 heads/63 sectors without actually confirming.

https://github.com/homebrew8088/8088-PC-Compatible/blob/main/bios/CGA_bios/asm/int13.asm does something interesting; it walks the partition table to try to read geometry info out of the Volume Boot Record. I assume this is prone to failure if the partitioning is nonstandard, but it does effectively let people "throw their hands up" and rely on the (assumed) bigger machine that formatted the drive to know its geometry.
Hi,

Nice to have you here :)

Is it in your plan to work on your bios and integrate it in XT IDE ?
I found interesting code in your BIOS and in the original BIOS, so do a "Merge" of these BIOS with XT IDE can result in something nice.
I suppose that it should be done linke XT IDE Does : Use X/255/63 for Big Disk and LBA is used anyway to support > 8GB
There is already a P-CHS to V-CHS Conversion code in XT IDE, so "We" can simply build a P-CHS (Physical) from the number of sectors (MAX LBA) and use the existing code to do the rest... So that the USB and Compact Flash images become compatible.

Read the Boot sector BPB is probably not good as these are written by the DOS, (Format) and may not be equivalent to the full disk CHS. Also, the goal of Xt IDE is to be able to partition and format disks, so most of the time, disks will be "Empty"
Or... detect empty disk Vs not empty ones. (Anyway, anything can be tested :) )

Your BIOS does not support extended BIOS functions, but anyway, this is for Fast Machines and have a working BIOS/Driver for fast machine will be difficult, the target (For me at the moment) is for slow PC.
 
We can also do the combinaison of Both the BIOS and the Block Driver, to be able to BOOT and create an initial partition/Boot sector and to mount other partition and access mode data. But who will need it ? more than 8Gb on a 8086/256...

Anyway, The Ideal target should be to use the CH376 and its capacity to read a FAT32 Disk. Then, have the Disk image as .IMG Files and build a configuration text file to tell the BIOS the .IMG File to use to BOOT... Like this we can simply add Floppy emulation as well.
 
I'm not sure how much of the BIOS I worked on is directly reusable, because it made assumptions about how the CH375/6 was wired that are sort of specific to the "EMM Computers" mainboard design. I expect these are different than the "add-on card" used-- I know the port numbers are different at a minimum, and maybe it makes more sense to use an interrupt-driven model instead of the busy-waiting it does.

I figured the main value here is that it's a known working and readable reference, while the "official" modules and BIOSes were undocumented and apparently have terrible performance.

I took a look at the CH376 datasheet as a refresher about the FAT stuff-- the 375 datasheet doesn't cover it in any depth. I always thought the difference between the 375 and 376 was that the latter could handle SD cards, but maybe there's more in it.

It seems like it might be possible to say "I want to open file X, then seek to sector offset 123456 in that file, then read", but I wonder if that's going to have surprise performance gotchas, i. e. having to walk its way through a potentially fragmented filesystem to the 123456th sector of the file, compared with a more block-oriented "read sector 123456". Some of this is probably fine if you're doing a low-intensity "I write one sector every few hours when someone saves configuration data" style operation, but a disc getting a lot of random seeks might not do well.
 
We can also do the combinaison of Both the BIOS and the Block Driver, to be able to BOOT and create an initial partition/Boot sector and to mount other partition and access mode data. But who will need it ? more than 8Gb on a 8086/256...

Anyway, The Ideal target should be to use the CH376 and its capacity to read a FAT32 Disk. Then, have the Disk image as .IMG Files and build a configuration text file to tell the BIOS the .IMG File to use to BOOT... Like this we can simply add Floppy emulation as well.
I never even (and still don't) use more than 8G (more like 4G because of bios limitations on some 486 bioses) on sub pentium machines (aka non windows machines (to me))
 
I understood the size problem, as doing PIO is more complex on the XTIDE due to the 2 different port for the High and Low. This make the code bigger and even more if unrolled.
Currently the XTIDE read 16Bytes per loop, this is a good comprimize for performance.
I was thinking about doing a lodsw for disk write.. But in fact it is done (I did not read everything in detail, sorry)
Anyway, the 8086 code can be optimized for the Read with a stosw and adding two exchange, it add only one byte to the code and speed up the 8086 read by 10% (If using 16Bit memory)

Freddy, you should read more of the source; some of the optimizations (other than unrolling) you are mentioning are already in the codebase. They are enabled via different assemble-time defines. For example, on M24 systems, you can't do a 16-bit read from port I/O, but you can do a a 16-bit write to memory, so there is a special define for M24 systems. So there are different builds for different targets with different optimizations: 8088, 8088+chuck mod, M24, 80186+, etc.
 
Freddy, you should read more of the source; some of the optimizations (other than unrolling) you are mentioning are already in the codebase. They are enabled via different assemble-time defines. For example, on M24 systems, you can't do a 16-bit read from port I/O, but you can do a a 16-bit write to memory, so there is a special define for M24 systems. So there are different builds for different targets with different optimizations: 8088, 8088+chuck mod, M24, 80186+, etc.
Yes it is what I wrote, the memory Write Optimization with lodsw is present (For Disk Write).
But the stosw optimisation is not present, and it is faster on 8086 with 16Bit memory (I confirmed it with the ISA USB)

In the ISA USB I did this:
If OPT_8088 Eq Yes
REPT 64
in al,dx
stosb
ENDM
ret
elseIf (OPT_8086 Eq Yes )
REPT 32
in al,dx
xchg ah,al
in al,dx
xchg ah,al
stosw
ENDM
ret
endif

The Read Speed go from 185Kb/s to 200Kb/s on the 8086 8MHz so I suppose It will be faster on XT IDE as well (But with a smaller increase)

In XTIDE Code:
; If 8088/8086
in al, dx ; Load low byte from port
xor dl, bl ; IDE Data Reg to XTIDE Data High Reg
stosb ; Store byte to [ES:DI]
in al, dx ; Load high byte from port
xor dl, bl ; Restore to IDE Data Register
stosb ; Store byte to [ES:DI]

There is no distinction between 8088 and 8086 and it is better as there are nore 8088 Around.

Anyway, we can do this for 8086:
in al, dx ; Load low byte from port
xor dl, bl ; IDE Data Reg to XTIDE Data High Reg
xchg ah,al
in al, dx ; Load high byte from port
xor dl, bl ; Restore to IDE Data Register
xchg ah,al
stosw ; Store word to [ES:DI]
 
It seems like it might be possible to say "I want to open file X, then seek to sector offset 123456 in that file, then read", but I wonder if that's going to have surprise performance gotchas, i. e. having to walk its way through a potentially fragmented filesystem to the 123456th sector of the file, compared with a more block-oriented "read sector 123456". Some of this is probably fine if you're doing a low-intensity "I write one sector every few hours when someone saves configuration data" style operation, but a disc getting a lot of random seeks might not do well.
Hi,
I agree, it may be slower, but not that much as the ISA BUS Transfer is soo slow anyway. I think that the advantage (Select multiple disk, Floppy disk emulation with disk swap on the fly> No more need of Gotec as well) may be so usefull.
When we have all the code, it is not really complex to add, so worth a try one day.
I'm not sure how much of the BIOS I worked on is directly reusable, because it made assumptions about how the CH375/6 was wired that are sort of specific to the "EMM Computers" mainboard design. I expect these are different than the "add-on card" used-- I know the port numbers are different at a minimum, and maybe it makes more sense to use an interrupt-driven model instead of the busy-waiting it does.
You added support of some BIOS functions that are not in the Original BIOS, but are in the XTIDE anyway.
The Original BIOS added more init code, and perform read/Write retry (More IRQ Status code are supported) so it is more reliable.

The more complexe part is that the CH375 Chipo does not use the IOCHRDY Signal, then, the CPU must not be too fast to read/Write data.
Also, of course, the delay code is different for each CPU Speed (This is not a big problem, but I suppose difficult to debug)
It seems that we need to add delays here and there from a 286 CPU
 
In XTIDE Code:
; If 8088/8086
in al, dx ; Load low byte from port
xor dl, bl ; IDE Data Reg to XTIDE Data High Reg
stosb ; Store byte to [ES:DI]
in al, dx ; Load high byte from port
xor dl, bl ; Restore to IDE Data Register
stosb ; Store byte to [ES:DI]

There is no distinction between 8088 and 8086 and it is better as there are nore 8088 Around.

Anyway, we can do this for 8086:
in al, dx ; Load low byte from port
xor dl, bl ; IDE Data Reg to XTIDE Data High Reg
xchg ah,al
in al, dx ; Load high byte from port
xor dl, bl ; Restore to IDE Data Register
xchg ah,al
stosw ; Store word to [ES:DI]

The first example is 8 opcode bytes and two bytes written, for a total of 10 memory I/Os. The second example is 11 opcode bytes and two bytes written, for a total of 13 IOs. Even though the STOSW on 8086 is a single I/O, they look roughly the same speed "on paper"... but of course benchmarking with the 8253 timer on hardware is the only way to truly know.

Just FYI: Here's a link to when I helped benchmark some new transfer code that was for 8-bit I/O transfers, but on an 8086 CPU (the Olivetti M24 can't do 16-bit I/O due to a hardware design flaw): https://forum.vcfed.org/index.php?t...-v2-0-0-beta-testing-thread.30259/post-863851
Earlier in the thread somewhere is the difference in the code, so that might be a point of direct comparison.
 
The first example is 8 opcode bytes and two bytes written, for a total of 10 memory I/Os. The second example is 11 opcode bytes and two bytes written, for a total of 13 IOs. Even though the STOSW on 8086 is a single I/O, they look roughly the same speed "on paper"... but of course benchmarking with the 8253 timer on hardware is the only way to truly know.

Just FYI: Here's a link to when I helped benchmark some new transfer code that was for 8-bit I/O transfers, but on an 8086 CPU (the Olivetti M24 can't do 16-bit I/O due to a hardware design flaw): https://forum.vcfed.org/index.php?t...-v2-0-0-beta-testing-thread.30259/post-863851
Earlier in the thread somewhere is the difference in the code, so that might be a point of direct comparison.
Yes, on the paper, but I tried anyway and saw a big difference on my Amstrad PC.
And as the full code is smaller for the CH375 compared to the XTIDE, the speed increase will be lower on XTIDE.

Then, for the XTIDE it is not worth the effort.
For the CH375 it is a great improvement and simple to use (Just use a .SYS file instead of the other).
 
Back
Top