ychh0, I am unable to open your rar archives. I tried, both, 7-zip 9.20 and WinRAR 3.0. Are you able to archive them in an older RAR format or ZIP?

feipoa wrote:

ychh0, I am unable to open your rar archives. I tried, both, 7-zip 9.20 and WinRAR 3.0. Are you able to archive them in an older RAR format or ZIP?

7-zip 9.20 is ancient. It works for me, I'm using 7-zip 18.04 x64 version. Note you need both RAR files in the same folder to decompress it.

lol. I generally don't update my non-internet-based software unless I need to. Perhaps this is one such time. I'm still using Adobe Photoshop 5.0 and Acrobat distiller 5.05, for example. In fact, I only just started using 7-zip a few years ago.

7-zip is free, WinRAR is not - that's my main argument. Also LZMA2 on ultra is maybe slower but offers better compression so a one-time CPU cost is perfectly acceptable I think. Lastly, LZMA2 can be multi-threaded pretty well, RAR on the other hand not so much and the program itself is very Intel-optimized to the point that it hurts perfomance on AMD CPUs. No such problems with 7-zip. Oh and it can take advantage of CPUs with hardware AES support for much faster encryption/decryption. Frankly I'm surprised people on Windows use other archivers at all.

Indeed, 7-zip version 19.00 was able to un-archive the Revto486 manual.

Edit: I originally wrote "uanble" instead of "able" by mistake.

ychh0, how's your progress coming? There's a lot of helpful information in that Evergreen manual that you can try, but there are even more settings to play with using CTCHIP34.EXE.

feipoa wrote:

ychh0, how's your progress coming? There's a lot of helpful information in that Evergreen manual that you can try, but there are even more settings to play with using CTCHIP34.EXE.

I didn't try CTCHIP34.exe.
Instead I tried to find which process usually hang up and I found that mostly when loading emm386.exe it hang up.
Currently if I do not load emm386.exe, only loading himem.sys it's almost perfect and I feel it's more stable when load himem.sys first and then revto486.sys and lastly loading emm386.exe as follows.

DEVICE=C:\DOS\HIMEM.SYS /MACHINE:2 /TESTMEM:OFF /NUMHANDLES=100
DEVICE=C:\REVTO486\REVTO486.SYS /CN /2 /CCM
DEVICE=C:\DOS\EMM386.EXE NOEMS HIGHSCAN X=E000-EFFF NOMOVEXBDA D=64

And I have another problem now.
I'm not satisfied with the transfer rate of XT-IDE and I recently tried to install Adaptec 1520B with SCSI2SD v6.
I tested two different system, one is original setup (286 10MzHz CPU) it's transfer rates reach to about 1.5MB/s (using iotest.exe), but the other system with revto486 (IBM 486SLC2 66MHz, CPU clock 16MHz) it's only 0.6MB/s~0.8MB/s furthermore frequently hang up. I guess it's also related with revto486 and I heard that Anonymous Coward also had such problem.
I'm now looking at this problem now.

For one of my motherboards, I needed to load the drivers in a particular order:
1) HIMEM
2) ASPI2DOS (for Adaptec 1520B)
3) Revto486

I suggest looking into the more advanced options of the Revto486 driver and CTCHIP34. Also read the information I provided on hidden settings for the IBM Blue Lightning. /INT=13 may help for some HDD issues.

What was the result of testing the Japanese IO Data driver program?

I have written in my notes that when viewing Revto486 settings with CTCHIP34 that it is setting it up such that the 1st 640K is cached and that the next 384K is uncached. Have you tried setting the 1st 640K to uncached? This would be Cache Region Control Register Byte 0, lo-byte. Try setting it to 00000000. You can also try adjusting the Cache Region Control Register Byte 4. I noted that decreasing the cache range to 8.5 MB allowed booting to Win3.11, so setting byte 4 to 01111000. You might try just setting the first 64K block after 1 MB as non-cacheable as well.

I made note that you can get a performance boost if you set XTOUT to 0. The increase was 58 realtics in DOOM. The Kingston BL2 driver has XTOUT set to 0 by default, but the Evergreen driver sets it to 1.

feipoa wrote:

I have written in my notes that when viewing Revto486 settings with CTCHIP34 that it is setting it up such that the 1st 640K is cached and that the next 384K is uncached. Have you tried setting the 1st 640K to uncached? This would be Cache Region Control Register Byte 0, lo-byte. Try setting it to 00000000. You can also try adjusting the Cache Region Control Register Byte 4. I noted that decreasing the cache range to 8.5 MB allowed booting to Win3.11, so setting byte 4 to 01111000. You might try just setting the first 64K block after 1 MB as non-cacheable as well.

I made note that you can get a performance boost if you set XTOUT to 0. The increase was 58 realtics in DOOM. The Kingston BL2 driver has XTOUT set to 0 by default, but the Evergreen driver sets it to 1.

Yes, you're right. Until now according to my tests, excluding 0~64kB, 512kB~768kb(or 832kB) caching region and including 768kB(or 832kB)~1024kB caching region increase performance. With default caching region of 0~640kB, the transfer rate is about 600~800kB/s but with proper adjustment of caching region it goes up to 1.8~2.2MB/s. (IOTEST read 1.8~1.9MB/s, Norton SI disk bench 2.0~2.2MB/s). I set revto486.sys driver with /M1L=E0FE option to do this adjustment of caching region. In my case, high cache region (above 1MB) doesn't affect the performance.

Should the APSI2DOS driver be loaded during booting? I set BIOS boot enabled and boot from the SCSI2SD, so I thought loading driver is not necessary. Does loading APSI2DOS driver affect stability or performance?

Does setting the full 1 MB to "not cached" solve your stability problem?

Best way to answer the question of what effect loading ASPI2DOS has is to load it and run a disk benchmark. For Windows 3.11, ensure you have 32-bit disk access and 32-bit file access enabled.

What is the result of trying the Japanese IODATA driver?

The documentation with the I-O Data driver also states that the order must be: HIMEM.SYS, PK486BL.COM, then EMM386.EXE

feipoa wrote:

What is the result of trying the Japanese IODATA driver?

The documentation with the I-O Data driver also states that the order must be: HIMEM.SYS, PK486BL.COM, then EMM386.EXE

Would you please let me know test conditions? I just tried Winbench96 on windows3.1 the result is much lower than you posted. (Below 0.4MB/s)
Did you use smartdrv.exe both read and write cache? Did you load adaptec driver. Asp2dos.sys and so on? How did you set scsi2sd setup configuration?
I’m now re-search settings to increase transfer rate....

Hello. For the Adaptec AHA-1540C, I am loading these drivers in config.sys:

DEVICE=C:\Adaptec\ASPI4DOS.SYS /P134
DEVICE=C:\Adaptec\ASPIBUF.SYS

ASPIBUF is only needed if your system has more than 16 MB of memory.

I am not using smartdrv or EMM386. I am only using HIMEM.SYS. The CPU is an SXL-40.

Here are my config.sys settings:

1NUMLOCK=ON
2DOS=HIGH,UMB
3LASTDRIVE=E
4STACKS=9,256
5DEVICE=C:\WINDOWS\HIMEM.SYS /TESTMEM:Off /V
6DEVICE=C:\Adaptec\ASPI4DOS.SYS /P134
7DEVICE=C:\Adaptec\ASPIBUF.SYS
8DEVICEHIGH /L:1 =C:\DOS\DISPLAY.SYS CON=(EGA,,2)
9DEVICEHIGH /L:1 =C:\WINDOWS\IFSHLP.SYS
10DEVICEHIGH /L:2 =C:\Adaptec\ASPICD.SYS /D:ASPICD0
11DEVICE=C:\DOS\SETVER.EXE
12SHELL=C:\DOS\COMMAND.COM C:\DOS\ /E:1024 /P

Autoexec.bat looks like:

1LH /L:2 C:\DOS\MSCDEX.EXE /D:ASPICD0 /M:12 /L:D
2C:\WINDOWS\ESSCFG.EXE /A:220 /I:5 /D:1 /B:330 /J:E
3C:\WINDOWS\ESSVOL.EXE /V:8 /L:8 /W:8 /M:0 /C:8 /S:8 /A:8
4CYRIX -b -m- -xA000,128 -xC000,256
5REM CYRIX -f -r -cd -i1
6c:\ps2suppc.com
7LH /L:2 c:\mouse.com
8DRAM 40
9@echo off
10C:\WINDOWS\NET START
11PROMPT $p$g
12PATH C:\WINDOWS;C:\MOUSE;C:\DOS
13SET DIRCMD=/P /A
14SET TEMP=C:\TEMP
15SET TMP=C:\TEMP

Deunan wrote on 2019-04-05, 20:35:

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).

Did you patch the IO.SYS of MS-DOS or Towns OS? If you did, could you share the information?
According to the documents of CXSET, IO.sys should be patched. But how to do is difficult to find.

Thanks

ychh0 wrote on 2020-07-29, 07:23:

Did you patch the IO.SYS of MS-DOS or Towns OS? If you did, could you share the information?
According to the documents of CXSET, IO.sys should be patched. But how to do is difficult to find.

I've made some changes to my own cache enabler and now the Psygnosis games seem to boot, at least some of them, but there are still the other issues I've mentioned.

Patching IO.SYS would be best but I have no idea how, and there are a few different versions as well. No, I just inject the cache enabler via AUTOEXEC.BAT - that's a good place since all the resident CONFIG.SYS stuff is already loaded and none of the user apps have been run yet. I've modified the ODE firmware to do on-the-fly injection. Obviously it won't work with pure TOS apps though, that system doesn't use AUTOEXEC at all.

There's an alternative to enabling the cache, one can inject code to enable FAST mode or reduce RAM/VRAM waitstates. This approach also offers nice performance boost, and has virtually no downsides. I will add it as an option to DocBrown and Wizard soon. But I'm not spilling the beans on that one - the research took quite some time and I don't want other people to profit from my work.

Deunan wrote on 2020-07-30, 10:27:

I've made some changes to my own cache enabler and now the Psygnosis games seem to boot, at least some of them, but there are st […]
Show full quote

ychh0 wrote on 2020-07-29, 07:23:

Did you patch the IO.SYS of MS-DOS or Towns OS? If you did, could you share the information?
According to the documents of CXSET, IO.sys should be patched. But how to do is difficult to find.

I've made some changes to my own cache enabler and now the Psygnosis games seem to boot, at least some of them, but there are still the other issues I've mentioned.

Patching IO.SYS would be best but I have no idea how, and there are a few different versions as well. No, I just inject the cache enabler via AUTOEXEC.BAT - that's a good place since all the resident CONFIG.SYS stuff is already loaded and none of the user apps have been run yet. I've modified the ODE firmware to do on-the-fly injection. Obviously it won't work with pure TOS apps though, that system doesn't use AUTOEXEC at all.

There's an alternative to enabling the cache, one can inject code to enable FAST mode or reduce RAM/VRAM waitstates. This approach also offers nice performance boost, and has virtually no downsides. I will add it as an option to DocBrown and Wizard soon. But I'm not spilling the beans on that one - the research took quite some time and I don't want other people to profit from my work.

That’s a good idea, enable FAST mode or reduce WS. Let me study it.

As for modifying ODE firmware, which do you mean that modifying ODE firmware? modifying DocBrown firmware or CD images? I studied cache enabler parameters and will test some configurations for 486SXL2 (FM Towns Tower) and 486SXLC2 (Marty). For DocBrown or Wizard if there is a way to modify or setting firmware to inject cache enabler it will be great.

Actually I started to do things about FM Towns recently and I just finished checking hardwares of FM Towns tower units. Though some units need to replace capacitors of power supply, majority seem working well. And one 4th gen. tower’s cpu is socketed also. I plan to study FM Towns tower first and setup Marty next.

There were some people who patched io.sys to increase compatibility, it should be great to do that but still I cannot find any information about it.

And I wonder which games or programs need more CPU power. Majority of FM Towns games or programs will need just 386DX-16MHz performance. I guess CPU replace with 486SXL2 or 486SXLC2 and reducing WS should be enough for those. And enabling cache may be needed only for such games that released late, requiring much more CPU performance.

Hey, I have PK-X486S50-3 installed in a hot-rodded IBM 5162. I was able to enable the cache and clock doubling via:

DEVICE=C:\REVTO486\REVTO486.SYS /BL /CN /2 (also tried adding /INT=13 /IRQ=6 but didn't help)

Benchmarking & DOOM seem to work, however when I try to play Jazz Jackrabbit I get a "Cannot enable A20" error. This game does work fine with a slower "Makeit486" Cyrix chip upgrade installed.

Any thoughts on how to resolve?

Also, I notice the enabling the onboard 87DLC causes the system to lock up, so I just have to keep it disabled via the first dip switch.

Did you review my thread documenting register settings for various CPUs? Register settings for various CPUs

Under the Blue Lightning subsection:

1Many systems have trouble with the IBM Blue Lightning BL2/BL3/DLC3 chip. Use HIMEM with /TESTMEM:on for an initial test. The following HIMEM settings have helped the BL3 work on many of my systems,
2/MACHINE:1
3/CPUCLOCK:ON
4
5e.g. in config.sys, DEVICE=HIMEM.SYS /TESTMEM:on /CPUCLOCK:on /MACHINE:1 /V

Also try Machine:3 or some of the others.

These two settings helped with my A20 errors.