@Zyga: very interesting would be a benchmark where you run your system with extern Busosc vs internal clock based on similar specs. That could give me a good impression whether to expect performance improvements or not.

Unfortunately none of Norton SysInfo versions I have was able to recognize my HDD (Conner Peripherals CFS541A -540MB) and thus test performance.
But I did benchmarks using PC Certify Pro 6.0 and 4_Speed 1.0 by DustBowl Designs.

7.14 MHz is default ISA clock (with BUSOSC soldered back to PCB 😀

PC Pro 6.0 results:

1                          | 20 Mhz | 10 MHz | 6,67 Mhz | 7,14 MHz (default)
2--------------------------+--------+--------+----------+-------------------
3Track To Track Seek (ms)  |    4,1 |    4,1 |      4,1 |      4,1
4Average Seek        (ms)  |   13,4 |   13,1 |     12,8 |     13,5
5Maximum Seek        (ms)  |   47,5 |   47,5 |     47,5 |     47,5
6Access Rate       (kB/s)  |  442,1 |  386,8 |    378,9 |    378,9
7Transfer Rate     (kB/s)  | 2367,7 | 1894,1 |   1515,3 |   1515,3

4 Speed results:

16.67 MHz - 1822 kB/s
27.14 MHz - 1835 kB/s
3  10 MHz - 2127 kB/s
4  20 MHz - 2825 kB/s

Not bad. Nothing less than 50% of improvement! Great.
I wont be sure about data integrity though

Dear all,

It‘s done. Mission complete. Finished!

Thank you all so much for your long-term help!! Especially to mkarcher with some detailed guidance in the background and zyga and also rasz_pl.

At the end I desoldered the Busosc Pin. What happened then:

System booted but could not boot from hdd nor fdd. At the end I had to insert some waitstates for 16BIT IO and 8Bit IO. Then all worked. Even win95 booted so it should be stable.

DMA speed = ISA speed at 13,75MHz (27,5/2).

Results:
- 3DBench from 9,9 to 10,1 [+2%]
- Thruput Average CPU from 7,17 to 7,17 [+0%]
- Thruput Average Video from 6,194 to 8,220 (!!!) [+32,7%]
- Vidspeed L from 7004/3137 to 10959/4181 (!!!) [+56% / +32%]
- Wintach Win95 GDI from 6,89 to 7,72 (!!!) [+12%]
- Doom from 14,24 to 14,92 [+4,78%]

Tja at the end I am happy. Quite sure that I mostly got out the system what’s possible. Only downside is the + 1WS AND that I cannot directly compare Busosc vs IntDivider results as the ISA / DMA speed differs.

Where I am really surprised is the increase in Thruput video & vidspeed. Maybe these numbers do show the potential which cannot be executed in real world benches due to 386sx27,5 as limiting factor.

Thanks to all !!!!!!

Marco wrote on 2023-01-30, 21:55:

DMA speed = ISA speed at 13,75MHz (27,5/2).

At what FCLKDIV are your running? If you are at "BIOS defaults", that would by SYSCLK2/2, i.e. 27.5MHz ISA clock. In that case, it's not surprising at all that you need to add in some wait states to I/O cycles. DMA speed is mostly irrelevant, as the only devices using that DMA clock on a standard IBM PC is the floppy controller and ISA sound cards, and none of them is performance sensitive.

Marco wrote on 2023-01-30, 21:55:

- Thruput Average Video from 6,194 to 8,220 (!!!) [+32,7%]
- Vidspeed L from 7004/3137 to 10959/4181 (!!!) [+56% / +32%]

Considering that you likely increased the clock from 8MHz (BUSOSC/2) to 27.5MHz (SYSCLK2/2), the theoretical bandwidth increase is +240%. Even at SYSCLK2/4, you have a theoretical speed-up of +72%. As even Vidspeed L (which is just measuring bus transfers) doesn't increase that much, you can now be sure that the ISA clock is definitely no longer the bottleneck, at least in the video modes you used to measure the performance.

Marco wrote on 2023-01-30, 21:55:

I am happy. Quite sure that I mostly got out the system what’s possible. Only downside is the + 1WS AND that I cannot directly compare Busosc vs IntDivider results as the ISA / DMA speed differs.

You can try to use AMISETUP to set up FCLKDIV=SYSCLK/4 and zero wait states, and compare performance in different scenarios to FCLKDIV=SYSCLK/2 and some wait states.

Marco wrote on 2023-01-30, 21:55:

Where I am really surprised is the increase in Thruput video & vidspeed. Maybe these numbers do show the potential which cannot be executed in real world benches due to 386sx27,5 as limiting factor.

That's definitely the case. For real-world applications, you only increased the speed of video card access. You did not speed up main memory access. As the 386SX doesn't have an internal cache, and your board doesn't have external cache, the processor relies on getting instructions from RAM fast enough, and might "starve" on fetching instructions. Increasing ISA clock doesn't help with that bottleneck. Finally, the 386 core is considerable worse at instructions per cycle than the 486 core, so a 486DX33 is easily twice as fast in real-world applications, even if you are running 16-bit software that only profits a small amount from the 32-bit bus.

Thanks all tested. The divider seems to be at /2 for isa. Lowering it further to /4 decreases performance too much even with lower waitstates. So I keep the settings as is.

Interestingly the slightly increased isa bus from 12 async to 13,75 sync did. not increase the hdd transfer rate by no means.

Hi guys,

Long time no heard.
After in depth testing I realized that no isa sound card would work anymore. Pnp‘s aren’t detected anymore, sb16 leads to fuzzy screen pictures or no hdd Controller found. I also managed to corrupt my full hdd when running with testing the scc-1.
DMA speed was at 13,75MHz. But same results with lowering it to 6,8xMHz (measured within Amibios tool).

Maybe it is the 14 MHz isa clock, possibly not as i ran before with 12MHz rock stable. I will try to measure the frequency tomorrow and also try the adjustment mentioned by mkarcher.

At the end I can only imagine it’s the isa running at 28mhz. On the other hand this sounds like too unrealistic to be true as it’s more than 300% overclock and win95 all is stable (w/o sound but even with scsi).

I‘ll keep you posted.
Rgs

Update:
Measured and system was indeed running at 27,5MHz Bus speed. I lowered to 13,75 MHz now. Crazy.

Anyway I meanwhile also managed to overclock the cpu further to 30mhz. At first only with lowest bios settings but it survived 5hrs of doom timedemo. Thus cpu wise ok now let’s get closer chipwise.

Previous trials with the 60mhz osci failed so maybe this is an advantage of running in sync. No idea.

Downside my floppy won’t execute / boot files anymore. With highest bios settings I get a parity error and full freeze. With lower settings it just hangs. Reading although is possible. Strange strange. I point to high isa bus and thus the too high DMA clock. IF that’s really the case I then have to roll back to async 🙁(((

PS: the hdd controller failure was due to the soundblaster onboard ide. Which made no problems on my 486 but here it was interfering with the ide controller card. Changed settings now working

As i am having sone minutes of a rest I got in detailed chat with GPT and interestingly it states:

It's unlikely that the Automatic Bus Speed-up on Video Access feature on the VLSI 311 chipset would result in an overclocking of the onboard 386sx/25 CPU.

The clock frequency of the CPU is typically derived from a separate clock generator that is not affected by the Automatic Bus Speed-up on Video Access feature. While the increased clock frequency may improve video processing performance, it should not impact the clock frequency of the CPU or other system components outside of the video memory access range.

That being said, it's possible that overclocking of the CPU or other components could occur if the clock generator settings are manually adjusted or modified in some way outside of their recommended or safe operating parameters.

This means for me that the board uses an external osci to keep 25MHz while being able to adjust (isa bus speed??) when having the bios feature fast video dram access enabled?!

chatGPT is great at generating credibly sounding bullshit. It has no mode where it would say "I dont know", it just makes up good sounding garbage. All stems from the way it works - predicting statistically most likely word based on previous words.

Agree 😀

Anyway the manual indeed states:

The clock generator logic generates
programmable frequency clock signals.
The SCAMP Controller has a unique
expanded clock feature by which the
clock is automatically increased when
video DRAM address range, AOOOOh-
BFFFFh, is accessed. The logic
diagram of the clock generator is shown
in Figure 15.

I should bench / measure this sometime