deomsh

@SweetLow I cited Microsoft. Do you think their '2GB' is a mistake?

@jumper You are right, it's even lower than I remembered. On the other hand the article is stating too: 'Although the user interface is limited to 24 MB, the theoretical maximum size of the cache is actually 2GB.' However Q253912 stated: 'Vcache is limited internally to a maximum cache size of 800 MB.'

Now I think I understand you better. About the comment semi-colon: both ways should work. About 512 MB: I never said that for SYSTEM.INI, the MaxPhysPage=20000 was ment for SYSTEM.CB, so for Safe mode (setting MaxPhysPage in SYSTEM.CB is known as Usher's method - please correct me if I am wrong). About MaxFileCache=56320: this is the officially highest value tested by Micosoft and described in Q108079. MDGX mentions this value it too. My entries in MSBATCH.INF were not ment for running Windows 98 SE in general, but for during Setup. Which is the purpose of MSBATCH.INF

I do not understand, can you give an example? BTW there is some information about the ini-directive here: https://learn.microsoft.com/en-us/windows-hardware/drivers/install/inf-updateinifields-directive Otherwise read 'Windows 98 Resource Kit', Appendix C.

I checked differences as far relevant for playback with HDA2.DLL: only differences concerning default mute/ unmute of Nodes. Unmute outputs is currently taken care of by my quasi-universal HDAICOUT.HDA up to node 1F. However: highest node number in AD1984 is 0x26. Unmute inputs is currently NOT taken care of by my quasi-universal HDAICOUT.HDA because of maximum number of verbs.

Nice. Thanks for reuploading the Linux codec info of AD1984. Now only needed for my 'administration': I want to make a quick comparison with the codec dump (found somewere on the internet) I used for the Thinkpad X61 of @sweaterfish . Good luck with your Thinkpad R61.

Help, your so fast So is everything good now?

Now the same surpassing of your codec at index $0. But no modem anymore, this time nothing: CODEC_VID=$0000 CODEC_DID=$0000 CODEC_REV=$000000 You can try with pcipatchB=$7900 in HDACFG.INI (you have an Intel ICH8 Family HDA-Controller Pci Id 8086:284B). Writing to PCI-registers is as always at your own risk, if any. You also can try changing wait-states in HDACFG.INI, set: wait1=$250 wait2=$250 or even higher. Watch HDALOG.TXT for changes and HDACFG.INI for populating CODEC_VID/DID. For now better wait with testing HDAICOUT.HDA, maybe rename extensions to .000 and 001 (in your Windows directory).

Nice to hear Watler's win3x HDA-driver is working with your Thinkpad Z60m. However for now I can not help you with your Thinkpad R61 (Type 7735). In HDACFG.INI your audio device is identified as 14F1:2BFA, this is a modem. HDALOG.TXT first found the HDA-device 11D4:1984 (should be AD1984), but switches (too fast?) to the second device. This is a known issue! You must *somehow* get rid of your modem. Search in this thread for modem, maybe helpful (maybe not).

Check this page: http://www.win3x.org/win3board/viewtopic.php?t=17965&start=7 for HDADRV9J. BTW archive-link provided by Watler is working, but downloading NOT (for me). Here you can download HDADRV9K: http://www.win3x.org/win3board/viewtopic.php?t=27321

On localized version of Windows, the Setup of Windows 98 will add lines for DISPLAY.SYS and COUNTRY to CONFIG.SYS, and lines for MODE and KEYB to AUTOEXEC.BAT (I have Dutch Windows 98FE and Windows 98SE CD-ROMS).

I never used batch.exe, I write my own msbatch.inf (with much help of all sources I can get). The updateinis-lines should be placed under the install-section (before [STRINGS] I guess). See https://leeos.epizy.com/infdoc.html?i=1#UpdateInisSections You can find it on the net, for instance mdgx.com is a reliable source. Simply start your search with site:www.mdgx.com and then what you want to know. EMMExclude will block Windows to use UMB's in the specified region. For instance the NVIDIA Geforce-drivers will block a (smaller) area. Most of the time I do not use UMB's. Usher's method is needed for Safe mode on computers with more than 1.xx GB of memory, just like in 'Normal mode'. However must be written to SYSTEM.CB. My section [Edit.Syscb] is FULLY undocumented, I wrote it by trial and error. You can't say this, unless you prove you can start Windows' Setup WITHOUT first loading HIMEM.SYS. However you can use MSBATCH.INF to write your own CONFIG.SYS and AUTOEXEC.BAT. About /NUMHANDLES=64: RLOEW mentioned them in his PATCHMEM-manual (above 2.75 GB memory).

Good However: your Setup-description not sound like a FULLY unattended setup. Better add following lines to your MSBATCH.INF: [Install] UpdateInis=Edit.Sysini,Edit.Syscb [Edit.Sysini] %10%\system.ini,386Enh,,"MaxPhysPage=40000" %10%\system.ini,386Enh,,"DMABufferSize=64" ; optional %10%\system.ini,vcache,,"MinFileCache=51200" ; Q108079 %10%\system.ini,vcache,,"MaxFileCache=56320" ; Q108079 %10%\system.ini,386Enh,,"MinSPs=8" ; optional %10%\system.ini,386Enh,,"MinTimeSlice=40" ; optional, multitasking slower but more stability ;;%10%\system.ini,386Enh,,"SystemROMBreakPoint=0" ;;%10%\system.ini,386Enh,,"EMMExclude=A000-FFFF" ;;%10%\system.ini,386Enh,,"MaxDMAPGAddress=1000" [Edit.Syscb] %10%\system.cb,Boot,,"*DisplayFallback=0" %10%\system.cb,386Enh,,"MaxPhysPage=20000" ; Usher's-method ;;Inf,Reg and BAT files need always a carriage Return on the end! BTW some WIN.COM-switches included for troubleshooting ('activate' one or more sysini-lines with semi-colons). With these lines in your MSBATCH.INF you should be able to use HIMEM.SYS during Setup (with switch /NUMHANDLES=64 OR /NUMHANDLES=128). If you want to use HIMEMX.EXE, change after Setup.

I have no idea, try Setup without the switch /nr - Setup should ask if you want to process existing Registry (if I remember well). Better backup first, if possible.

Search for MSBATCH.INF + use https://learn.microsoft.com/en-us/previous-versions//cc768165(v=technet.10)

Did you mean searching with Google? I just tested, but I have no problems on Windows 98 FE.

I made a new version of Part 8½ B: Full installation of Windows 98se on a Rloew non-XMS Ramdrive Highlights: Minimum memory requirement lowered from 2GB to 512 MB, of available memory 7/8 part is used for a RLoew 32-bits non-XMS ram-drive (2,118 MB memory gives the max of 2 GB). Minimum memory is tested on my old PCChips M811-board, fully stable with 12 Internet Explorer windows together with 12 MS-DOS-windows (with http://www.proxycrime.com Google is still usable with Internet Explorer 4, even search-settings can be changed); I skipped making the 27MB setup-image, files still copied to (rd,0), but now directly mapped to memory as a Grub4dos mem-drive; Because of the CHS-limitation of floppies in MS-DOS I changed the Grub4dos mapping of boot-USB drives in hard-drive emulation to D: - boot-USB drives in floppie emulation still mapped to B: (with CHS-limit of 1024/255/63, so about 8GB); Choice to run JHRobotics' PATCH9X during Setup if files PATCH9X.EXE and CWSDPMI.EXE are added to the folder SETUP982\PATCH9X, simply extract them from JHRobotics' Freedos image (even possible with 7z). See next two print-screens: Choice of three Setup options (no detection of PCI-bus, no detection of Floppy, no ACPI), with their combinations. Default is still Setup /P I;S=detectfloppy. See next print-screen: I wrote a new Grub4dos-script to localize CONFIG.SYS/ AUTOEXEC.BAT during first boot of Windows. Windows' Setup will add and localize DISPLAY.SYS and COUNTRY.SYS to CONFIG.SYS and MODE.COM and KEYB.COM to AUTOEXEC.BAT. My script LOCALIZE.G4B will read-out these localizations during first start of Windows from directory ONR, and write them to CONFIG.SYS/ AUTOEXEC.BAT inside the 16MB C:-image and to CONFIG.SYS/ AUTOEXEC.BAT on the boot-USB drive. During Setup the whole C-drive was copied to the 27WINONC.982 folder on ram-drive R: - so all is needed is to copy the 27WINONC.982 folder to directory ONR on the USB boot-drive; If accidental deleted re-generation of the 16MB C:-image, including new localization (file LOCALIZE.TAG is deleted while building the image); File WINONRCD.BAT is copied during Setup to the root of the boot-USB drive. Running WINONRCD will prepare all files needed to make a Windows 98 SE 'Live CD/DVD' (running in memory only, so full write-access). Only GRLDR has to be added to SETUP982\WINONRCD (or to Root). If XDVD2.SYS and/ or SHCDX33F.COM are not found in the installation-phase, OAKCDROM.SYS and/ or MSCDEX.EXE have already been extracted from the Windows 98 SE cab's as a fallback. Be aware OAKCDROM.SYS is not compatible with SATA-drives (in IDE-mode). Further last two files are using together about 64 KB conventional memory, first two files only about 4KB! But XDVD2.SYS and/ or SHCDX33F.COM can be added to folder SETUP982\WINONRCD for use with the 'Live CD/DVD'. After running WINONRCD: files 4032KONC.HDD (C:-image), GRLDR, MENU.LST, FAT and FATCOPY.G4B and a few directories are added to directory ONR. Directory GRUB contains same MENU.LST as directory ONR, as fallback. Files added to directory INJECT.CDC before burning are copied to the C-drive while booting from CD/ DVD. ImgBurn is working 'out-of-the-box', no other ASPI-layers needed. Be aware 'El Torito'-boot is in no-emulation mode, and needs four sectors. For instance WINONCD has one sector as default, but ImgBurn has four. Important is to choose ISO9660+Joliet in case of CD-R/ CD-RW and ALWAYS ISO9660+Joliet+UDF is case of DVD+/-R / DVD+/-RW. See next print-screen: The 'empty' version has been growing from 85 files to 120 files, and all-included from 314 files to 385 files. See FILELIST.TXT and ALLFILES.TXT in the README folder. WINONR8.5.1.USB.EMPTY.ZIP BTW an USB-drive is not absolutely needed, possible too is running Windows 98 SE from a RLoew non-XMS ramdrive using a hard-disk image inside Virtual Box or VMware.

Probably a script from Jaclaz: view_bs_008.zip look at https://msfn.org/board/topic/152097-on-superfloppies-and-their-images/page/11/#findComment-1001712

In the file 'a20alwon.zip' you have to take HIMEM.SYS from the folder 'Preferred version'. This one does not need any extra installation. Just rename your current HIMEM.SYS to HIMEM.ORG, or something like that. Normally the file resides in your WINDOWS-directory, So copy it there. If you have a CONFIG.SYS file in your root-directory, you can look where to copy the file. If there is no difference in your way of starting Windows, go back to the original. In that case I have no new ideas for now.

Sweetlow's patch of HIMEM.SYS has to do with access to Extended memory, more I can't say (some A20-gate 'magic'). Use was successful on a NForce chipset with endless hanging before Windows starts. As described in conversation mentioned.

Did you try Sweetlow's HIMEM.SYS mod? See first: https://msfn.org/board/topic/180597-exploring-setup-p-isdetectbus-and-grub4dos-8½-times-win98se-on-usb-drive/page/10/#findComment-1278017

My floppy drive is still in good shape. I did many, many tests with my stopwatch. Reading from a floppy is still too fast to give real differences, but writing does. With switch '/V' copying takes about 1.5 times longer than without. And: copying gives at least one floppy-access 'sound' extra. With 'SET COPYCMD=/V' speed is same as without switch '/V'. My conclusion is that switch '/V' is NOT supported in COPYCMD in MS-DOS 7.1. Maybe just an urban myth I have been following for many years. Sadly i can't find any source. But I found another option: 'VERIFY ON|OFF'. Timing same as with switch '/V'. If used in AUTOEXEC.BAT should working globally (also in all MS-DOS Windows). I asked Copilot if 'SET COPYCMD=/V' is valid, which is doubted by this machine. Interesting source: this conversation. See https://copilot.microsoft.com/shares/1dzXRdWHaiHyJrBShe6uh BTW Copilot mentioned too COPYCMD is not 'natively supported' in MS-DOS - so this machine does not seem to have access to the 'Technical Reference MS-DOS 6.2'.

Good idea, I will look if my old floppy drive is still working. To be continued...

Using a debugger is a bit above my level, but thanks for your suggestions. I did some tests with a stopwatch to see if there is a big difference in copyspeed, simply using COPY without '/V' and with '/V' on the command-line, but no conclusive results so far. To be (more) sure about the placement of /V and /Y in SET COPYCMD I tried your (Gemini's) earlier suggestions too in Virtual Box, and it seems '/Y' must always come first. See following print-screens (Dutch MS-DOS 7.1): I looked in some of my MS-DOS' books, for instance 'Technical Reference MS-DOS 6.2' mentions only 'SET COPYCMD=/Y' (or /-Y).

Thanks a lot. Testing is a bit difficult. I thought I could try with reversed order, for instance: SET COPYCMD=/V,Y but this is not taken, /Y must come first, like in the COPY-syntaxis. No idea how I can test the V-part. I use it just for safety, because I have to copy files on a USB Flash drive in legacy mode.