Thanks also to you. Yes it’s tricky but fun to dive into with the docu.
Thanks for the explanation. You will be right with part 1.
part 2 I would say following: you don’t need another bios or reprogram anything. All settings are purely hardware signal based.

I attached a Foto:
Red: situation with the 16Mhz osci
Orange: Situation with removed osci where system hangs
Green: how it should be configured w/o 16Mhz osci.

Green and red appear two times as I am not sure about the video dram stuff.

So you see it’s just about providing the right ttl signal to sclkdiv pin.

Would you agree?

>sclkdiv pin

more precisely
>The default values are determined by the status of pins -DKEN (pin 125) and -PPICS (115) at power-on reset

>Slow Clock Divider Bits 1 and 0. Selects the SYSCLK frequency where Clock is BUSOSC or TCLK2
>00 = Clock/2
>01 = Clock/4
>10 = Clock/6
>11 =Clock/8
>Default 01

but it already defaults to /4, meaning that for the worst case of /2 your mobo has to have a pull down resistor on pin 115 .. that is unless your system is unable to function with 50/4 12MHz ISA clock

It’s getting challenging.
Default 01 for sclkdiv(s) would be fine as you stated. 50/4=12,5

But I assume that it is factory set to 00 on this board as my first red line indicates. Bord is supposed to work via external osci with /2 so sclkdivs on 00 by default as it is supposed to work in this mode only.

Or am I mixing things up?

find pin 115 and measure its resistance to ground and 5V supply, on powered off system obviously 😀
potential mod could be as trivial as desoldering one resistor

You are right. Will do so. Thx

Marco wrote on 2022-10-09, 07:11:

part 2 I would say following: you don’t need another bios or reprogram anything. All settings are purely hardware signal based.

I attached a Foto:

You need to understand that sclkdiv and fclkdiv are not pins, but software configurable registers. The state of sclkdiv directly after reset is settable using resistors.
The state of fclkdiv after reset is /6. If there is no clock connected to BUSOSC, the logic state of busosc decides whether sclkdiv or fclkdiv is effective. If BUSOSC is left completely unconnected, the internal pull-up will make it read high ("1"), selecting fclkdiv. Also, if the BIOS enabled ENVDSP, fclkdiv will be used whenever video memory is addressed, even if BUSOSC is low.

So I'm afraid that BUSOSC is pulled high, and the system starts up using fclkdiv with the default divider "/6" (the line before your second green line) and only crashes after the BIOS programmed fclkdiv to /2 (so we will be on the line above your second green line). There are no pins that influence initial fclkdiv and no pins that prevent fclkdiv reprogramming by the BIOS, that's why I expect that a pure hardware solution might likely fail.

Also here thanks. So this brings us back to the debug option?

Marco wrote on 2022-10-09, 17:00:

Also here thanks. So this brings us back to the debug option?

I don't see how debug is going to help. With the 16MHz/24MHz crystal installed, the system is forced into asynchronous mode, and debug can't change it. Without the 16MHz/24MHz crystal installed, the system runs in synchronous mode, but it crashes before we can invoke debug.

Indeed 😀 my fault. You are right. Damn.
Don’t want to give up yet. I will check on the resistors on 115 to further see what could! Be an option

When you try modifying pullups/pulldowns that initialize sclkdiv, consider also to ground the output pin of the removed oscillator to make sure sclkdiv is used instead of fclkdiv.

Hi Marco. Unfortunately I'm not able to answer your private message. Message is still in outbox 🙁
Sorry for off topic.

Me again with an update (or maybe updated question).

I found a working amisetup version - thanks to you - where I can set values we already bespoke.

As I just finished my w95 install plus network I don’t won’t to mess up my Bord fully.

Could you therefor maybe help me out with what exactly you would change here now?

PS: I can also directly change any registered manually
PS2: under option „ext bus osci control“ I can select fast or 10bit (default) only.

PS3: from what you/we figured out so far I would set fastclockdivider to /4 (and ensure a ground signal from the ext osci slot which I would take out)

What would you say? Thanks again

The options shown for "slow clock divider" make no sense. They should read "/2", "/4", "/6" and "/8" (so just like the "fast clock divider", but with "/8" instead of "reserved"). If you are able to adjust these settings using AMISETUP, you don't need to modify the BIOS code.
If you set "slow clock divider" and "fast clock divider" to the same value, you don't need to ground the output pin of the removed oscillator, as it doesn't matter whether the board chooses the slow or the fast divider.

BTW: messages are displayed in your outbox until the receiver reads them. They are in your "outbox" and their "inbox" at the same time. Only after reading, the message is moved from your "outbox" into your "sent messages" folder.

So I played around with both settings and I compared the bit settings with the manual table 16 (the one with green yellow red highlighted rows). If I select the values in amisetup that fit to these bits (00,01,10,11) it is not working anyway. System hangs at Boot/ won’t start at all etc.

Eg fastclock option /4 sets but 01. same as in the manual. Etc etc.

At least happy that I could restart the system with the ext osci then again. Puh.

The selectable values per option I cannot change.

Ps: at least I could enable slow refresh which „boosted“ my NU SI index from 19,1 to 19,7

Marco wrote on 2022-10-11, 09:24:

Ps: at least I could enable slow refresh which „boosted“ my NU SI index from 19,1 to 19,7

That's a common trick to pull. Be aware that normal RAM modules are not specified to run at "slow refresh". Memory chip manufacturer started selecting chips that they guarantee to work reliably with slow refresh as "low power" chips and sold them in a separate bin. This means that using slow refresh on standard modules might cause system instability with certain RAM access patterns (think rowhammer) at elevated temperatures (with RAM chips getting up to 60°C). For hobby use, this is likely no issue, but you should keep in mind that you are running out-of-spec to revert to "standard refresh" in case you get issues next summer.

Marco wrote on 2022-10-11, 09:24:

So I played around with both settings and I compared the bit settings with the manual table 16 (the one with green yellow red highlighted rows). If I select the values in amisetup that fit to these bits (00,01,10,11) it is not working anyway. System hangs at Boot/ won’t start at all etc.

Eg fastclock option /4 sets but 01. same as in the manual. Etc etc.

The time has come to dump your BIOS. Possibly they initialize to "known working" values early in the boot process before they apply the CMOS values. But guessing is no longer useful, I expect we tried all the reasonable stuff, so to understand the issue in more detail, reverse engineering a BIOS dump (I can do that) is required. You should be able to use NSSI to dump the BIOS.

Oh, ok. Honestlx - I would more than much appreciate that.

I therefor added two zips:
BIOS_AMI: Backups made by AMISetup
BIOS_NIS: Backups made by NISS

At first - thanks so much upfront. Pls let me know when I can help for whatever.

Thanks!

mkarcher wrote on 2022-10-11, 16:04:

Marco wrote on 2022-10-11, 09:24:

So I played around with both settings and I compared the bit settings with the manual table 16 (the one with green yellow red highlighted rows). If I select the values in amisetup that fit to these bits (00,01,10,11) it is not working anyway. System hangs at Boot/ won’t start at all etc.

Eg fastclock option /4 sets but 01. same as in the manual. Etc etc.

The time has come to dump your BIOS. Possibly they initialize to "known working" values early in the boot process before they apply the CMOS values. But guessing is no longer useful, I expect we tried all the reasonable stuff, so to understand the issue in more detail, reverse engineering a BIOS dump (I can do that) is required. You should be able to use NSSI to dump the BIOS.

I took a look at the BIOS. It's complicated: Your BIOS already has the notion of "power-on defaults" and "BIOS defaults", and the names actually make some sense: When you power on the machine, the BIOS configures the chipset first according to the "power-on defaults" (at POST code 13), no matter whats in the CMOS. The power-on default is fclkdiv = /6, sclkdiv = /4. In case the CMOS contents is considered valid, the BIOS copies the settings from the CMOS into the chipset at POST code 8C (near the end of the POST). That's all fine, but there is a important catch: If the BIOS considers the CMOS contents bad, you get the BIOS defaults loaded. The "BIOS defaults" are intended to be a sensible starting point for you to adjust CMOS settings. The BIOS default values for the clock configuration are fclkdiv = /2, sclkdiv = /4. So as soon as "BIOS defaults" are loaded, you get a configuration that fails after the memory test if you run in synchronous mode.

You should be able to exit this configuration by entering BIOS setup using the DEL key (still at "power-on defaults"), and loading power-on defaults into the CMOS. This will also load power-on defaults of the hidden options, so you get back to fclkdiv = /6.

I don't see a reason for the system to fail booting if the CMOS is "valid" and contains fclkdiv = /4 or /6.

Thanks a lot mkarcher.

I might be mistaken but I think you mixed some things.
Loading bios default stands for loading standard settings. Loading power on defaults for safe settings. I double checked this in the amisetup. There it is written exactly as I stated with safe settings and standard settings. It’s just a bunch of bios settings.

Anyway I tried the following:

1. Post - bios - loading power on default.
- system very slow nu si 14,7
- looked in amisetup whether other divider options are there: no
- removed ext osc: system wouldn’t even boot but 9 beeps

2. tried the same again with loading bios defaults
- same as 1. but only fast
- yes right the system now wouldn’t even reach the post screen neither. Don’t ask me why!

Is there still hope? Maybe I mixed up stuff?

Marco wrote on 2022-10-12, 18:44:

I might be mistaken but I think you mixed some things.
Loading bios default stands for loading standard settings. Loading power on defaults for safe settings. I double checked this in the amisetup. There it is written exactly as I stated with safe settings and standard settings. It’s just a bunch of bios settings.

You are not mistaken, but I think I did not confuse anything, too. Let me explain the process in detail:

1. When you turn on the computer, the chipset starts with the values explained in the data sheet. Some of them are adjustable by external resistors.
2. Quite early in the power-on process, at the time the POST code 13 is sent to port 80, the BIOS overwrites the datasheet / strap values with the power-on defaults. No matter what's in the CMOS.
3. Then the complete POST runs with the safe slow settings from the power-on default.
4. At the end of the POST, at POST code 8C hex, the BIOS loads the values that are currently stored in the CMOS setup into the chipset.
5. Finally, booting from floppy/hard disk is started.

There are power-on and BIOS defaults for all the hidden options as well as the visible options of the setup. Whenever you load default values in the CMOS setup, even the hidden options are reset to the default value. For fclkdiv, the BIOS default and the power-on default differ. So after you loaded power-on default, the hidden, unchangeable (without AMISETUP) option for fclkdiv is different than after you loaded BIOS defaults.

Marco wrote on 2022-10-12, 18:44:

Anyway I tried the following: […]
Show full quote

Anyway I tried the following:

1. Post - bios - loading power on default.
- system very slow nu si 14,7
- looked in amisetup whether other divider options are there: no
- removed ext osc: system wouldn’t even boot but 9 beeps

Wow, that's actually interesting insight. 9 beeps is "BIOS ROM checksum error", issued at POST code 06, so before the power-on defaults are loaded. As I am very confident that the BIOS ROM checksum isn't actually bad, this seems to indicate that the BIOS ROM is accessed too fast due to the higher ISA clock. As fclkdiv defaults to /6, you should be safe if the fast divider is chosen (50MHz / 6 is around 8MHz). So it seems like your system tries to verify the BIOS checksum at sclkdiv (did you ground extosc output: if yes: this forces sclkdiv!). If pulldowns are installed on the two pins configuring SCLKDIV, sclkdiv is initialized as /2, and trying to read the BIOS at 25MHz is going to fail.