What is a Teradrive? What you using MS-DOS? Which version? In which location in config.sys or autoexec.bat is your cache enabling program? Are you loading himem? Can you provide your autoexec.bat and config.sys file? Has there been any reports of a Teradrive working with a Rev-to-486 upgrade kit? How much RAM is in the system? Are you using SCSI?

There are several cache enabling programs from different vendors. I will have to dig into my sloppy notes to see what I have tried. I also have a driver which is on a Japanese diskette that won't work on my system. Are you able to run Japanese DOS drivers?

Teradrive is hybrid machine, SEGA Megadrive + IBM 286 PC.
PC side is typical IBM 286 PC with originally AMD 80286 10MHz and max. 2.5MB ram.

I use MS-DOS 6.22 and cache driver (revto486.sys) is located at the first line of config.sys. Loading driver is as follows in sequence. revto486.sys (with /CN /2 /CCM), himem.sys /testmem:off, emm386.exe noems, and then SB Pro2 driver. I remember set of files and buffers is 40 and 20 and of course there is a line of dos=high,umb. If you need whole config.sys and autoexec.bat, I can do it this evening.

There is someone who used this module in the Teradrive, you can find it in the YouTube.
Actually, the problems do not regularly happen. Sometimes no error, sometimes hang up. I feel it's more stable after I attach a heat sink on the CPU. I don't know if adding heat sink really affect in the booting process or not.
I'm using 2.5MB ram and currently use XT-CF, but have a plan to try SCSI (Adaptec 1520B+SCSI2SD).

If you have Japanese driver, could you share it to me? In fact, I have several IO Data and Buffalo CPU Upgrade module to use in the PC9801 system but I don't have official driver. I guess it should be designed to use in PC9801 and the driver could also be for the MS-DOS of PC9801 and may not work in typical IBM compatible PC.

I suggest getting the upgrade adapter working properly with 1x before getting to deep into things. Here are some generic device driver settings for various enabling software:

DEVICE=C:\REVTO486\REVTO486.SYS /BL /CN /CCM /3

DEVICE=C:\KTCL486\LGHT486.SYS /3

DEVICE = C:\PK486BL\PK486BL.COM /I /B /3

You can use DDL (attached) to load them from the command prompt. I recall that it was best to let the config.sys drivers load first.

REVTO486.SYS, where by

/BL is to set register settings for the IBM Blue Lightening chip
/CN sets what is cached, and for /CN, I beleive it caches all but 640k-1MB
/CCM enabled cache of the Cyrix Math Co-processor
/3 this sets multiplier, 3 for 3x, 2 for 2x.
/S shows the current register status
/INT=xx: B,C,or D
/IRQ=xx: B, C, or D /V

I believe IRQ values of B, C, or D are the hex values, whereby, for example, B = IRQ 11, that is, assuming HEX 1 = IRQ 1, HEX 2 = IRQ 2, etc. But perhaps the hex value 0 = IRQ 1? INT is for software INT's.

Some notes I wrote:
The IBM literature says to flusyh cache on INT 15 when using SCSI HDD. Do not cache 14-16 MB if mamory-mapped devices use memory in 14-16 MB area. The other optiosn are to flush the cache on INT 9, 10, 11, 14, or 15.
The REVTO486 software from Evergreen is generally a good starting point, then you can use CTCHIP34.EXE IBM486.CFG to make adjustments and see all the register settings. Refer to the PDF on an explanation of these settings.

I am attaching all that I have for you to experiment with. I've also included the original diskettes from the IO DATA box for the PK486BL3. You may need to have the Japanese version of DOS installed to use the installer on the diskette. I believe the PK486BL.COM file can be found in the downloaded file though (attached).

I spent many weeks on this in the past, but it was many years ago and I have forgotten most of my results that allowed me to run DOOM. The IO DATA unit contains a dip switch which allowed for flushing the cache on I/O read/writes which solved a lot of the issues, but at speed penalty.

For the PK486BL.COM, I have written down these flags

/I
/R
/B
/F
/N
/T {1,2} for turbo
/{1, 2, 3}
/s for reset.com file
/LMCR=xxxx, e.g. /LMCR=00FF (64k)
/LMROR=xxxx, e.g. /LMROR=0000 (64k)
/CMLR=xx, e.g. /CMLR=D0 (13 MB)

I suspect the latter are for setting cacheable ranges. I don't think PK486BL.com would even run on my machine. The software may have been expecting the Japanese version of MS-DOS.

The IO DATA PK-A486BL60 and BL75 series were upgrades for the PC-9801DA, RA and PC-98RL.

This is what the IO DATA box and diskettes look like. You'll also want to read this PDF on the register settings for this CPU (attached last).

I have also written down that this config.sys order was required when using the Buffalo BL3 adapter on a particular motherboard:

Himem.sys /Testmem:off /Machine:1 /v
ASPI2DOS
REV2486 /BL /CN /CCM /3

I also know that when using a different chip, the TI486 SXL2, that I often ha to disable caching on 1 MB boundaries to get it stable in Windows 3.11. If you are able to find out a similar setting for the IBM BL2/BL3, that might be what the problem is with your instability. I suspect no such analogy exists for the BL2/3 registers though, or perhaps I recall incorrectly.

On another motherboard, the SiS Rabbit, I have written in my notes that the Buffalo BL3 booted into Win3.11. BL3 at 100 MHz completed the DOOM timedemo with sound (3909 realtics), but when playing the actual game, it would hang after a few seconds. Unfortunately, I did not note the exact settings used. I recall the BL3 working rather well with the SiS Rabbit chipset. On another motherboard, based on a VIA chipset, for some reason, I needed to have the Cyrix FPU installed on, both, the adapter and the motherboard to get it working. Sounds like a bad idea though.

There is also some valuable information about this chip and its workings here: http://www.os2museum.com/wp/ibm-blue-lightnin … ds-fastest-386/

Just my 2 cents: The problem might be cache related but not due to flushing/range. There might be some tight I/O loops or otherwise optimized code that was meant to be fast on 286/386 so it's basically very close to what the hardware can take. Any CPU prior to 486 will always be slowed down by having to fetch instructions from memory while 486 can execute code from internal L1 cache. This presents 2 problems:

- the code/loop will execute faster and might violate hardware timings, making things unstable
- there won't be any memory accesses between I/O accesses visible on external bus, some chipsets can't deal with it correctly

This is especialy true for non-PC systems. While I know nothing about Teradrive, in fact this is the first time I've heard about it, I have some experience with 386-to-486 upgrades (both SX and DX) in PCs and FM Towns systems.

While it's nice to be able to also speed up the last part of DOS boot process by enabling the cache early in CONFIG.SYS, it might be safer to do it later, possibly as the last thing in AUTOEXEC.BAT, once COMMAND.COM is fully loaded and all interrupts have been covered by the required drivers.

Thanks for valuable advices to feipoa and Deunan. (Special thanks to feipoa for the IO DATA PK series driver! I searched official driver for PK-X486S50 for a long time but no success)
I’ll try step by step.

feipoa wrote:

I suggest getting the upgrade adapter working properly with 1x before getting to deep into things. Here are some generic device […]
Show full quote

I suggest getting the upgrade adapter working properly with 1x before getting to deep into things. Here are some generic device driver settings for various enabling software:

DEVICE=C:\REVTO486\REVTO486.SYS /BL /CN /CCM /3

DEVICE=C:\KTCL486\LGHT486.SYS /3

DEVICE = C:\PK486BL\PK486BL.COM /I /B /3

You can use DDL (attached) to load them from the command prompt. I recall that it was best to let the config.sys drivers load first.

REVTO486.SYS, where by

/BL is to set register settings for the IBM Blue Lightening chip
/CN sets what is cached, and for /CN, I beleive it caches all but 640k-1MB
/CCM enabled cache of the Cyrix Math Co-processor
/3 this sets multiplier, 3 for 3x, 2 for 2x.
/S shows the current register status
/INT=xx: B,C,or D
/IRQ=xx: B, C, or D /V

Some notes I wrote:
The IBM literature says to flusyh cache on INT 15 when using SCSI HDD. Do not cache 14-16 MB if mamory-mapped devices use memory in 14-

16 MB area. The other optiosn are to flush the cache on INT 9, 10, 11, 14, or 15.
The REVTO486 software from Evergreen is generally a good starting point, then you can use CTCHIP34.EXE IBM486.CFG to make adjustments

and see all the register settings. Refer to the PDF on an explanation of these settings (the pdf is located in the next post down).

I am attaching all that I have for you to experiment with. I've also included the original diskettes from the IO DATA box for the PK486BL3. You may

need to have the Japanese version of DOS installed to use the installer on the diskette. I believe the PK486BL.COM file can be found in the

downloaded file though (attached).

I spent many weeks on this in the past, but it was many years ago and I have forgotten most of my results that allowed me to run DOOM. The IO

DATA unit contains a dip switch which allowed for flushing the cache on I/O read/writes which solved a lot of the issues, but at speed penalty.

For the PK486BL.COM, I have written down these flags

/I
/R
/B
/F
/N
/T {1,2} for turbo
/{1, 2, 3}
/s for reset.com file
/LMCR=xxxx, e.g. /LMCR=00FF (64k)
/LMROR=xxxx, e.g. /LMROR=0000 (64k)
/CMLR=xx, e.g. /CMLR=D0 (13 MB)

I suspect the latter are for setting cacheable ranges. I don't think PK486BL.com would even run on my machine. The software may have been

expecting the Japanese version of MS-DOS.

The IO DATA PK-A486BL60 and BL75 series were upgrades for the PC-9801DA, RA and PC-98RL.

Thanks for valuable advices (Thanks for the IO DATA PK series driver! I searched official driver for PK-X486S50 for a long time but no success)
I’ll try step by step.

I just tried location of revto486.sys and the location seems to be little related with the problem.
And as for /INT and /IRQ parameter, what is the meaning of B, C, D? If this is a parameter to specify caching conditions, it could be the key to make booting more stable. Unstable booting may come from the not specified caching condition.

Thanks!

Deunan wrote:

Just my 2 cents: The problem might be cache related but not due to flushing/range. There might be some tight I/O loops or otherw […]
Show full quote

Just my 2 cents: The problem might be cache related but not due to flushing/range. There might be some tight I/O loops or otherwise optimized code that was meant to be fast on 286/386 so it's basically very close to what the hardware can take. Any CPU prior to 486 will always be slowed down by having to fetch instructions from memory while 486 can execute code from internal L1 cache. This presents 2 problems:

- the code/loop will execute faster and might violate hardware timings, making things unstable
- there won't be any memory accesses between I/O accesses visible on external bus, some chipsets can't deal with it correctly

This is especialy true for non-PC systems. While I know nothing about Teradrive, in fact this is the first time I've heard about it, I have some experience with 386-to-486 upgrades (both SX and DX) in PCs and FM Towns systems.

While it's nice to be able to also speed up the last part of DOS boot process by enabling the cache early in CONFIG.SYS, it might be safer to do it later, possibly as the last thing in AUTOEXEC.BAT, once COMMAND.COM is fully loaded and all interrupts have been covered by the required drivers.

Do you use CPU upgrade module in the FM-Towns? Is there a cache program for the FM Towns? I also have a plan to use CPU upgrade in the FM Towns but I thought operating system and hardware are different, it may not be possible to use cache driver. Would you please let me know in detail about the cache program? I have FM towns Marty and FM Towns II (gray tower type) and also 486SXLC2 upgrade module for 386SX and 486SXL2 upgrade module for 386DX.

ych0: I have edited my original post to talk about what IRQ B, C, D are for. I didn't realise I had word wrap enabled when I posted, so I have fixed this as well. The documentation on this is very poor and I have had to derive some of the information from the INI files. I suggest looking more deeply into what information. You might need a week or two.

I suggest loading revto486.sys using the DDL program I provided. e.g. DDL REVTO486.SYS /BL /CN /CCM /2 at the end of your autoexec.bat or manually. I recommend this even if you don't think loading it first is the problem.

Deunan: I suspect there is truth to your comment on the sytem not being able to handle a faster CPU. But isn't there various PAL-like circuits on the upgrade module to handle such timing issues? I suspect the IO DATA unit, which was designed around the PC-98 system should, in the least, will work on the PC-98. The Evergreen upgrade module was destined for a broader user base.

For the TI 486SXL2-50 or SXL-40, there hasn't been a 386 motherboard that I haven't been able to get working with L1 enabled by setting non-cacheable regions, flush type, or disabling caching at MB boundaries. The SXL2 upgrade CPU acts very similar in terms of instability, for example, if you are using a DMA SCSI controller and do not disable caching on each 1 MB boundary. Of course, the issue with the BL2/3 could be entirely different.

There is also the Transcomputer upgrade module, noted here: 386 upgrade kits and the Transcomputer 486HPi - Am5x86-160 anyone? , which can upgrade a lowly 386 to an AMD Am5x86-160 with L1 enabled. This is substantially faster, and I have not yet experienced any issue with it.

feipoa wrote:

ych0: I have edited my original post to talk about what IRQ B, C, D are for. I didn't realise I had word wrap enabled when I po […]
Show full quote

ych0: I have edited my original post to talk about what IRQ B, C, D are for. I didn't realise I had word wrap enabled when I posted, so I have fixed this as well. The documentation on this is very poor and I have had to derive some of the information from the INI files. I suggest looking more deeply into what information. You might need a week or two.

I suggest loading revto486.sys using the DDL program I provided. e.g. DDL REVTO486.SYS /BL /CN /CCM /2 at the end of your autoexec.bat or manually. I recommend this even if you don't think loading it first is the problem.

Deunan: I suspect there is truth to your comment on the sytem not being able to handle a faster CPU. But isn't there various PAL-like circuits on the upgrade module to handle such timing issues? I suspect the IO DATA unit, which was designed around the PC-98 system should, in the least, will work on the PC-98. The Evergreen upgrade module was destined for a broader user base.

For the TI 486SXL2-50 or SXL-40, there hasn't been a 386 motherboard that I haven't been able to get working with L1 enabled by setting non-cacheable regions, flush type, or disabling caching at MB boundaries. The SXL2 upgrade CPU acts very similar in terms of instability, for example, if you are using a DMA SCSI controller and do not disable caching on each 1 MB boundary. Of course, the issue with the BL2/3 could be entirely different.

There is also the Transcomputer upgrade module, noted here: 386 upgrade kits and the Transcomputer 486HPi - Am5x86-160 anyone? , which can upgrade a lowly 386 to an AMD Am5x86-160 with L1 enabled. This is substantially faster, and I have not yet experienced any issue with it.

\

I just captured manual of rev to 486, driver part. I guess adjust INT and IRQ may improve stability of booting. Though I don't know which INT or IRQ is sensitive to the stability. How about your opinion?

And do you know this upgrade module? This is also made by Evergreen and heard this is "rev to 486" but I guess this is not for 286 or 386 machines.

That is almost certainly an upgrade module for 5v 486 systems that is a laptop AM5x86 + voltage regulator. I have one for my CWD4002 in an attempt to keep thermals down in its tiny no-airflow case relative to a 5v DX2-66.

Ohhh, you have the Evergreen Revto486 full manual? Where did you find it? Are you willing to scan and PDF the whole manual? The manual is quite rare and would be a great asset.

The CPU upgrade that you list is the same as what I have, download/file.php?id=32747&mode=view

I have enclosed the manual for it. That is an Evergreen 586 Upgrade interposer module. It contains an AMD Am5x86-133 chip with an onboard voltage regulator for use in 5V 486 systems. The only way to use it on a 386 is if you insert it into a Transcomputer, shown here:

download/file.php?id=32735&mode=view
download/file.php?id=32736&mode=view
download/file.php?id=32748&mode=view

I added a fan to mine. download/file.php?id=33342&mode=view

I've upgraded my Marty with 486SXLC2 but it's a 3V3 variant with 5V tolerant I/O. Seems to work fine but I've been able to source a 5V 486SXLC just in case it dies - it's a 40MHz part but since Marty uses 16MHz clock I can still use the hidden clock doubling feature. Obviously that required soldering and use of hot air or IR lamp to lift the original chip without damaging the PCB. Marty's are rare and costly as it is. BTW a small heatsink is recommended, these upgrades use twice the power (at the very least!) and get way hotter than original 386SX.

Gray tower Towns can require soldering as well - only the first 2 gens had the PGA CPU socketed. Same deal, hot air, even more work cleaning the through holes to install a socket. Once you do have socket there you can just put in any 486DLC or SXL that's 5V rated. There's no need for any custom upgrades, although having one might help you enable the cache without serious code patching - depends on what it can do.

In general simply swapping the 386 for a Cyrix/Ti 486 CPU will get you some 50% performance boost - that's without cache enabled. Enabling it makes it 100%, and clock doubler is another 100%. But the cache is a huge catch. There are some programs for that written back in the day but these are Japanese in origin, poorly documented and hard to find assuming you even know what to look for. I've done a lot a lot of dissasembly and code analysis on these (Towns TBIOS as well) and eventually came up with my own program and a method of injecting it (and other patches) into ODE images. But that is a complicated subject, I could be writing about this for hours and still not cover everything. The short version is this: You can't just "run a cache program" and expect things to work. Also, Towns is not a PC, any PC program that tries to mess with interrupts in any way will crash the machine.

Many PC chipsets actually have some support for cache and maybe even directly for Cyrix/Ti chips. That's why it's usually easy to get these 486 upgrades running with little hassle. If you want to upgrade your Towns, better be prepared to either stop at chip replacement without ever enabling the cache, or to study the subject A LOT.

Deunan wrote:

I've upgraded my Marty with 486SXLC2 but it's a 3V3 variant with 5V tolerant I/O. Seems to work fine but I've been able to sourc […]
Show full quote

I've upgraded my Marty with 486SXLC2 but it's a 3V3 variant with 5V tolerant I/O. Seems to work fine but I've been able to source a 5V 486SXLC just in case it dies - it's a 40MHz part but since Marty uses 16MHz clock I can still use the hidden clock doubling feature. Obviously that required soldering and use of hot air or IR lamp to lift the original chip without damaging the PCB. Marty's are rare and costly as it is. BTW a small heatsink is recommended, these upgrades use twice the power (at the very least!) and get way hotter than original 386SX.

Gray tower Towns can require soldering as well - only the first 2 gens had the PGA CPU socketed. Same deal, hot air, even more work cleaning the through holes to install a socket. Once you do have socket there you can just put in any 486DLC or SXL that's 5V rated. There's no need for any custom upgrades, although having one might help you enable the cache without serious code patching - depends on what it can do.

In general simply swapping the 386 for a Cyrix/Ti 486 CPU will get you some 50% performance boost - that's without cache enabled. Enabling it makes it 100%, and clock doubler is another 100%. But the cache is a huge catch. There are some programs for that written back in the day but these are Japanese in origin, poorly documented and hard to find assuming you even know what to look for. I've done a lot a lot of dissasembly and code analysis on these (Towns TBIOS as well) and eventually came up with my own program and a method of injecting it (and other patches) into ODE images. But that is a complicated subject, I could be writing about this for hours and still not cover everything. The short version is this: You can't just "run a cache program" and expect things to work. Also, Towns is not a PC, any PC program that tries to mess with interrupts in any way will crash the machine.

Many PC chipsets actually have some support for cache and maybe even directly for Cyrix/Ti chips. That's why it's usually easy to get these 486 upgrades running with little hassle. If you want to upgrade your Towns, better be prepared to either stop at chip replacement without ever enabling the cache, or to study the subject A LOT.

How about using "rev to 486" or "make it 486" CPU modules instead of direct soldering? For example CPU upgrade module for 386SX (just plug on the existing 386SX CPU) or upgrade module for 386DX(remove existing 386DX CPU and install the upgrade module, PGA type). I wonder just change CPU clock doubler is activated. If then both FM Towns Mary and FM Towns 2 Tower (I have First and Second generation FM Towns Tower with PGA socket) will operate at 32MHz with TI486SXLC2 or TI486SXL2 resulting performance increase even though without cache. As for cache side, it would be very tough project.

feipoa wrote:

Ohhh, you have the Evergreen Revto486 full manual? Where did you find it? Are you willing to scan and PDF the whole manual? The […]
Show full quote

Ohhh, you have the Evergreen Revto486 full manual? Where did you find it? Are you willing to scan and PDF the whole manual? The manual is quite rare and would be a great asset.

The CPU upgrade that you list is the same as what I have, download/file.php?id=32747&mode=view

I have enclosed the manual for it. That is an Evergreen 586 Upgrade interposer module. It contains an AMD Am5x86-133 chip with an onboard voltage regulator for use in 5V 486 systems. The only way to use it on a 386 is if you insert it into a Transcomputer, shown here:

download/file.php?id=32735&mode=view
download/file.php?id=32736&mode=view
download/file.php?id=32748&mode=view

I added a fan to mine. download/file.php?id=33342&mode=view

Please see attachment. I took pictures and converted to PDF file (There is no scanner here....)
According to manual, it seems that using INT or IRQ parameter may increase stability. But I wonder which INT or IRQ should be included when booting, especially just loading revto486.sys system hang up or error occurs like missing command.com and so on. Do you have any idea about it?

ychh0 wrote:

How about using "rev to 486" or "make it 486" CPU modules instead of direct soldering? For example CPU upgrade module for 386SX (just plug on the existing 386SX CPU) or upgrade module for 386DX(remove existing 386DX CPU and install the upgrade module, PGA type). I wonder just change CPU clock doubler is activated. If then both FM Towns Mary and FM Towns 2 Tower (I have First and Second generation FM Towns Tower with PGA socket) will operate at 32MHz with TI486SXLC2 or TI486SXL2 resulting performance increase even though without cache. As for cache side, it would be very tough project.

For 386SX on Marty the short answer is yes, it'll work with a snap-on module - there's even a guy who tried that and made videos on YouTube. But the problem is Marty is a console and as such it's pretty tightly packed, there's just no room for any add-ons over the CPU unless you start modding and cutting away stuff. And even then the floppy drive will be in the way. Plus from what I've heard these snap-on things are a bit unreliable - poor contact or loss of contact to pins due to temperature changes. In the end you'd have to see for yourself and experiment but don't get your hopes up.

The 386DX on gray tower Towns can't be replaced or bypassed (PGA version of 386 doesn't have FLT# input) unless it's in a socket. If not, soldering is the only option available. But it can be done, I've modded 2 of my towers, and I don't do soldering for living (though I do have tools and experience).

As for clock doubler I have some more bad news - firstly, without cache enabled it doesn't give any significant boost, you're already almost 100% bus-bound just running a 486 core there. Secondly and worse yet, it will interfere with some TBIOS code like pad-to-mouse emulation on Marty when enabled without code patching.

Deunan wrote:

For 386SX on Marty the short answer is yes, it'll work with a snap-on module - there's even a guy who tried that and made videos […]
Show full quote

ychh0 wrote:

How about using "rev to 486" or "make it 486" CPU modules instead of direct soldering? For example CPU upgrade module for 386SX (just plug on the existing 386SX CPU) or upgrade module for 386DX(remove existing 386DX CPU and install the upgrade module, PGA type). I wonder just change CPU clock doubler is activated. If then both FM Towns Mary and FM Towns 2 Tower (I have First and Second generation FM Towns Tower with PGA socket) will operate at 32MHz with TI486SXLC2 or TI486SXL2 resulting performance increase even though without cache. As for cache side, it would be very tough project.

For 386SX on Marty the short answer is yes, it'll work with a snap-on module - there's even a guy who tried that and made videos on YouTube. But the problem is Marty is a console and as such it's pretty tightly packed, there's just no room for any add-ons over the CPU unless you start modding and cutting away stuff. And even then the floppy drive will be in the way. Plus from what I've heard these snap-on things are a bit unreliable - poor contact or loss of contact to pins due to temperature changes. In the end you'd have to see for yourself and experiment but don't get your hopes up.

The 386DX on gray tower Towns can't be replaced or bypassed (PGA version of 386 doesn't have FLT# input) unless it's in a socket. If not, soldering is the only option available. But it can be done, I've modded 2 of my towers, and I don't do soldering for living (though I do have tools and experience).

As for clock doubler I have some more bad news - firstly, without cache enabled it doesn't give any significant boost, you're already almost 100% bus-bound just running a 486 core there. Secondly and worse yet, it will interfere with some TBIOS code like pad-to-mouse emulation on Marty when enabled without code patching.

I just found the cache s/w for FM Towns. Would you try this?
www.vector.co.jp/soft/towns/hardware/se014605.html

Yes, these are the programs I mentioned. CX.COM will also work on Marty - except you'll still get the issues with mouse I mentioned, plus I've yet to find out why all the Psygnosis games hang on 486 upgrade. There are a few runtime swtiches but it's nothing like on the PC - these programs are already tailored to the specific FMT architecture and you only select which one of the predefined settings you want to apply.
Note that you still have to inject these programs into game images (both the file itself and the change to AUTOEXEC.BAT to run it).