deomsh

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.

I have a basic question about MS-DOS batchfile: syntaxis of COPYCMD. Should I use: SET COPYCMD=/Y,V or SET COPYCMD=/Y,/V or is there no difference and can I use both? BTW internet search gives no results in this case (for me).

Add MinFileCache=1024 and on next line MaxFileCache=1024 and reboot. There is a good chance this will cure copy-errors.

What are your values in SYTEM.INI, [vcache] ?

Thanks, good to hear lower wait1 and wait2 are working on your system. About stability: same erratic behavior with vcache at 1024? Higher MinTimeSlice set in SYSTEM.INI can improve stability, but your system will become less responsive. Default is 20 (ms) without any setting in [386Enh]. If you want to try, just add: MinTimeSlice=40 and reboot. You can go up in steps of 20. Highest value I ever needed was '120'. About midi: you can try the Yamaha synthesizer. It's all in this thead. Just search for 'midi'.

Congratulations. I'd like to know for my notes regarding the High Definition Controller of your Intel 81 chipset: was pcipatchB=$7900 really needed, or does pcipatchB=$0000 the same?

See: https://msfn.org/board/topic/186747-can-anyone-help-me-to-install-high-definition-audio-device-on-realtek-alc887-chip-especially-deomsh/#findComment-1278735

There is no specific HDAICOUT.HDA for ALC887 as far as I know. Using another tailormade one depends first on the same Codec Index mentioned in HDACFG.INI. I have an ALC887 codec on my Asus board P8H61E. All I needed is two settings in HDACFG.INI: 1) pcipatchB=$7900 (Option on Intel H81 chipset too) 2) VolumeWidget=$0C As always: writing to chipset controller registers with pcipatchB is at your own risk (if any).

Thanks for testing. As such we are done. Actually there are a few loose ends I'd like to now about your system. First is regarding wait-states in HDACFG.INI. Defaults are: wait1=$100 wait2=$100 I you have some spare time please test both wait1 and wait2 with following values: $80, $60, $40, $20 - until you are experiencing some sort of problems. If $20 is still good, then go on with $15, $10 and $5. Even lower better in steps of '1'. Always reboot Windows in between. Also there is a (possible) reward: the lower the shorter you have to 'wait' during starting Windows (in my experience).

Good to hear. I made a normal version of HDAICOUT.HDA for VT1708B with minimum number of verbs. I removed the GET-verbs and commented out Node ID 25, can be activated again at any time (and by switching the Selector Widget in Node ID 1D, or by enabling Input 5 in Node ID 16). Node ID 1C is still active, so a Speaker connected to that node can be driven. DAC0 at Node ID 10 is set to to Stream 1/ Channel 0 and 44.1kHz/ 16-bits. The commented-out verb just below is for switching to 48kHz/ 16-bits. Headphone-amplifier is enabled for Node ID 1D, if this gives noise, switch to normal output (Commented-out verb just below). I added Power Up verbs to all remaining nodes, just in case a laptop-user with codec VT1708B wants to try. I hope this (hopefully) final version is still working. HDAICOUT_VT1708B.HDA.000

Great! With 'volume adjust as well', did you mean WAVEOUT.EXE?

Thanks. I checked everything. Please try debug-version. IF this version gives sound in your Windows 98SE installation, you can try in HDACFG,INI: SleepingWidget=$10 VolumeWidget=$1D OutputWidget=$10 If VolumeWidget is right, WAVEOUT.EXE should be working too. I'd would like to see HDAICIN.TXT of VERY cold Windows 98 boot afterwards. HDAICOUT_DEBUG4_VT1708B.HDA

Thanks a lot for your observations! Maybe 'Stream 0' is simply the wrong stream. In your post from March, 4 I saw from HDAICIN.TXT I probably was using 'Stream 1' in that version of HDAICOUT.HDA. To be sure, can you please upload after starting Windows XP the latest HDAICOUT.HDA, HDAICIN.TXT, HDALOG.TXT and HDACFG.INI from your Windows directory in your Windows 98SE installation? So latest WITH sound after reboot from Windows XP.

Interesting the 'Very cold boot no pop'. Can be a HDA-controller problem, but also that Stream 3 is not used by HDA2.DLL? Next version, should work at least with warm reboot from Windows XP. But we come closer and closer to the same settings as used in my quasi-universal HDAICOUT.HDA, only specified on Node/ Widget level. In an 'Alsa Information Script' containing VT1708B was mentioned 'enable_msi : 0', so on the level of the the HDA-controller. I looked in the ICH7 datasheet, it seems that MSI is enabled by default in the High Definition Audio Controller Registers. So disabling MSI with pcipatchB=$6200 is worth a try. But as always: writing to chipset registers is at your own risk (if any). Please try next version of HDAICOUT.HDA with the HDACFG.INI-value of: pcipatchB=$0000 pcipatchB=$7900 pcipatchB=$6200 I don't need any log's for now, only your ears and (good) skills handling the files. HDAICOUT_DEBUG3_VT1708B.HDA

Thanks for the log's. I hope the pop you hear does mean that the HDA-controller is working with HDA2.DLL in Windows 98, otherwise things will become more complicated. After analyzing HDAICIN.982/XP2 I found that your jack is connected to Port E (Node ID 1D). Because there is (currently?) no speaker to deal with, I will concentrate on your headphones. I made a print-screen of the playback part of the Functional Block Diagram of VT1708B: In HDAICOUT_DEBUG_VT1708B.HDA I tried to: 1) fully 'open' the playback path from AOW0 (Node ID 10 = DAC0) to Mixer MW0 (Node ID 16) to Port D (Node ID 1C); 2) switch input of Port E (Node ID 1D) to AOW3 (Node ID 25 = DAC3), surpassing the mixer. I was not sure about which Port (Node ID) was connected to the headphone jack. Earlier the Headphone Amplifier of Port D (Node ID 1C) was activated after reboot from XP (and NOT Node ID 1D). I overlooked maybe AOW3 (Node ID 25) is connected to Stream_3 (I usually set DAC's to Stream 0). Apart from the picture, numbering of streams is mentioned nowhere in the datasheet! My 'GET' Verb in first DEBUG-version gave Stream 0 in the response. I set AOW3 (Node ID 25) as connected to Stream 3 in the second DEBUG-version, together with some other changes I want to examine. Please try, I will need HDAICIN.983 and if needed HDAICIN.XP3. Please listen carefully and report everything you can hear. BTW make sure HDAICIN.983 is made after a VERY cold boot and not after shutting the computer down from Windows XP. With 'very cold boot' I mean shutting down your thin client, remove the power cable, press the power-on switch a few times and wait at least 2 minutes. Of course this is not applicable to the VERY warm reboot needed from Windows XP. HDAICOUT_DEBUG2_VT1708B.HDA Edit: I wrote 'I usually set DAC's to Stream 0', but this is not true, my memory must have been playing tricks om me, I usually set DAC's to Stream 1 (but not this time). Intel's High Definition Audio Specification (Rev 1.0a on page 160): 'Although the link is capable of transmitting any stream number, by convention stream 0 is reserved as unused so that converters whose stream numbers have been reset to 0 do not unintentionally decode data not intended for them.' Not earlier mentioned in this thread.