IntSDX Banking

[flashjazzcat]

Anyone know where to find information on the banking bytes for Lotharek's IntSDX mod? I aim to transfer a (modified) Maxflash SDX image to IntSDX but doubtless the banking registers are different. I haven't had time to start trawling the Polish forums yet... and Lotharek's incommunicado at the moment.

[drac030]

Why don't you use the intSDX image?

[flashjazzcat]

Why don't you use the intSDX image?

Because I want to flash it with the ROM published here for the MaxFlash IDE cart. It has the MyIDE driver on the CAR: device (as we discussed last night). I'll still have to work through the binary and change the internal MyIDE references to the external registers for it to work with my setup.

[trub]

Instead of using a hacked (and outdated) image, I would suggest extracting the driver and use it with the current SDX version.

 

Of course it should be then loaded from the command line or via a custom CONFIG.SYS. For testing & development having the standalone driver is the best solution anyway. 

[flashjazzcat]

Instead of using a hacked (and outdated) image, I would suggest extracting the driver and use it with the current SDX version.

 

Of course it should be then loaded from the command line or via a custom CONFIG.SYS. For testing & development having the standalone driver is the best solution anyway.

Agreed. However I don't yet understand how to edit the binary image of the latest version in order to embed the driver into the CAR volume. Can you offer assistance?

[drac030]

You do not need to edit any images. You just copy the driver binary from CAR: to your disk, and load it from there under intSDX.

[flashjazzcat]

You do not need to edit any images. You just copy the driver binary from CAR: to your disk, and load it from there under intSDX.

The driver needs to be on the CAR device and loaded by the default CONFIG.SYS in order to boot from the MyIDE device.

[drac030]

You mean, without the MyIDE OS? Seem so, I didn't think about it.

[flashjazzcat]

You mean, without the MyIDE OS? Seem so, I didn't think about it.

Indeed so. The idea is to use this device with a stock OS.

 

Of course there's one complication: CONFIG.SYS cannot be read from the MyIDE drive when booting, since the stock OS SIO routine won't recognize the MyIDE drive, and the MyIDE driver will be loaded via CONFIG.SYS. That's why the on-cart CONFIG.SYS would need DEVICE MYIDE in it, and user customisation would be limited to AUTOEXEC.BAT. That's unless there's a clever way of patching in the MyIDE driver before CONFIG.SYS is read. In any case, it's a minor and unavoidable limitation.

 

So, you can see that a way is required to patch the MYIDE.SYS file into the existing CAR volume, as well as to edit the resident CONFIG.SYS.

Edited September 2, 2010 by flashjazzcat

[trub]

The idea is to use this device with a stock OS.

The driver will allow for accessing MyIDE device from DOS routines only. Some programs will fail if they use stock OS SIO to access a disk.

 

BTW. If you have a customized OS (MyIDE OS), put DEVICE SIO /A in CONFIG.SYS. The /A option will redirect SDX to use MyIDE-customized OS SIO. The same applies to The MUX OS which is required to run The Multiplexer hardware. 

[flashjazzcat]

The driver will allow for accessing MyIDE device from DOS routines only. Some programs will fail if they use stock OS SIO to access a disk.

Naturally this is correct.

 

If you have a customized OS (MyIDE OS), put DEVICE SIO /A in CONFIG.SYS. The /A option will redirect SDX to use MyIDE-customized OS SIO. The same applies to The MUX OS which is required to run The Multiplexer hardware.

DEVICE SIO /A is what I use at the moment when I'm testing MyIDE with SDX (I couldn't use the two together otherwise). Unfortunately this has the side effect of making all the connected SIO devices run slowly/unreliably because the SDX high-speed SIO routine is no longer used.

 

So much for what I already know. So, any guidelines of adding files to CAR:...???

Edited September 2, 2010 by flashjazzcat

[trub]

Unfortunately this has the side effect of making all the connected SIO devices run slowly/unreliably because the SDX high-speed SIO routine is no longer used.

You can turn OS SIO for individual drives with MAP command (like MAP 1 OS). Other drives will still use SDX SIO.

 

intSDX 128 hardware (described here) uses the banking scheme similar to the older SDX carts (see here). An extra bit select lower or upper 64k. So $D5Ex selects banks from the first half (but located upper in the rom image), while $D5Fx is used to select banks from the other half.

 

Anyway, I would rather recommend patching the existing intSDX image by modifying its CONFIG.SYS and putting the driver in. If you have problems with that, write me a PM. 

[flashjazzcat]

You can turn OS SIO for individual drives with MAP command (like MAP 1 OS). Other drives will still use SDX SIO.

 

intSDX 128 hardware (described here) uses the banking scheme similar to the older SDX carts (see here). An extra bit select lower or upper 64k. So $D5Ex selects banks from the first half (but located upper in the rom image), while $D5Fx is used to select banks from the other half.

Konrad mentioned that the MAP command might do the job. Unfortunately once the SDX SIO handler is present, access to the HDD is then lost so it's impossible to issue the command to map the HDD to the OS SIO routine. Useful information, though: thank you.

 

PM on the way...

[drac030]

fjc: MAP.COM is on the cartridge. You do not need a hdd access to run the command. You only need the regular SIO.SYS module (SIO without /C or /A), however, to actually do the mapping.

[flashjazzcat]

fjc: MAP.COM is on the cartridge. You do not need a hdd access to run the command. You only need the regular SIO.SYS module (SIO without /C or /A), however, to actually do the mapping.

I think I forgot that SDX uses the OS SIO vector for the whole duration of CONFIG.SYS processing (I'm assuming that's correct)? So we can play around with drive mapping without ending up with a "stranded" HDD. OK.

[drac030]

Honestly, I don't understand how CONFIG.SYS using OS SIO is related to MAP.COM.

[flashjazzcat]

Sigh... OK.

 

When booting from a MyIDE HDD, if at the instant CONFIG.SYS loaded SIO.SYS without any switches, DOS switched to using the high-speed SIO code, the end of CONFIG.SYS would be lost, since the SDX high-speed SIO code cannot read the open file on the MyIDE HDD. If, on the other hand, CONFIG.SYS is entirely processed by the OS SIO routine, we can install the SDX SIO driver and then re-map drive 1 to the OS SIO before the SDX SIO driver gets it hands on it. See?

 

I boot my MyIDE drive with "DEVICE SIO /A" in CONFIG.SYS. Presumably this means the high-speed code isn't installed at all. If I then type "SIO.SYS" at the command prompt, I lose access to the HDD. Sure - I can then remap by hand - but my concerns centered around communication with the disk persisting during remapping and device installation, that's all.

 

EDIT:

 

DEVICE MAP.COM 1 OS

 

in CONFIG.SYS takes care of MyIDE access on drive 1, and high-speed SIO access on all other drives. That's great - exactly what I wanted when using the MyIDE OS

 

Now to the driver...

Edited September 2, 2010 by flashjazzcat

[drac030]

When booting from a MyIDE HDD, if at the instant CONFIG.SYS loaded SIO.SYS without any switches, DOS switched to using the high-speed SIO code, the end of CONFIG.SYS would be lost, since the SDX high-speed SIO code cannot read the open file on the MyIDE HDD. If, on the other hand, CONFIG.SYS is entirely processed by the OS SIO routine, we can install the SDX SIO driver and then re-map drive 1 to the OS SIO before the SDX SIO driver gets it hands on it. See?

 

No. This is a no-problem, because CONFIG.SYS is loaded entirely by the OS SIO. It is visible (or rather audible) when using a serial drive and the stock OS.

 

I boot my MyIDE drive with "DEVICE SIO /A" in CONFIG.SYS. Presumably this means the high-speed code isn't installed at all. If I then type "SIO.SYS" at the command prompt, I lose access to the HDD. Sure - I can then remap by hand - but my concerns centered around communication with the disk persisting during remapping and device installation, that's all.

 

If you need the default SIO.SYS, then why you don't drop the "/A" and have the default module loaded instead of loading the /A first and then a next SIO module on top of that manually?

 

Just load the regular SIO from the CONFIG.SYS. You then have to load MAP.COM (with appropriate parameters) directly from the CONFIG.SYS as well and have disks remapped as you wish.

[flashjazzcat]

Didn't notice your post while composing mine. You'll notice this is exactly what I've done and it works.

Edited September 2, 2010 by flashjazzcat

[trub]

 For more sophisticated setups you may also create a config file (text) and pass it to MAP as a parameter. More details in the manual.

[flashjazzcat]

For more sophisticated setups you may also create a config file (text) and pass it to MAP as a parameter. More details in the manual.

Indeed so. It's a case of "read the manual".