Jump to content

PassingBy

Member
  • Posts

    87
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Malaysia

Everything posted by PassingBy

  1. Hmmm ..... Hey there erpdude8 , I'm in a bit of a tight schedule right now ... and away from my dev systems ... If you could hold out just for another couple of days or so, I'll post an updated pack to match the latest NUSB by Maximum-Decim ... It's already been tested for months now on several W98FE systems but I haven't gotten round to include an un-install routine yet ... That's on the to-do-list ... I apologise for being lame and not having the updated pack posted much earlier ... @barbarien: The explorer is the pretty much the same used in nusb33e (maybe some resource is different here and there but definitely no code patches were done). So, no major differences there. It's there to handle usb insertion messages correctly ... Rgds
  2. Hmmm ..... As I mentioned earlier, FP and EDO does not play well together ... If I recall correctly (my memory is a wee bit hazy here ... it's been quite a long while ...), it's due to different bus cycle/signal timings between the EDO and FP ... While they share the same pin counts but mixing FP with EDO makes the FP goes 'huh?' as the EDO are able to retrieve more bits within the same cycle and the FP says 'what !? where !? when !?' ... Again, this is not something BIOS memory timings can help much ... It's like trying to make an unbuffered DDR module work with a registered DDR module (well, something like that) ... They just don't play nicely ... My last socket 3 was a generic SiS496 pci that also does not work with mixed FP+EDO ... Memory region errors usually does not appear under DOS as DOS kernel is loaded and stays within the first 1 MB ... All the rest will become XMS/EMS ... If the defective region(s) is above 1MB then DOS never crash, the later loaded apps will kindly do that when they use the defective regions ... Win9x is different as the kernel loads high up in memory and if this is where the defective region is located then it usually throws up BSODs very very early ..... On another note, Intel triton was intended for the socket 7 pentiums (p75-p233mmx) ..... The UMC8881 were socket 3 for the much more earlier i486 family ... The AMD X5-133 is not anywhere near the same as the AMD K5/K6, it's really just a turbo-boosted 486 ..... Rgds
  3. Hmmm ..... Me sorry for missing on this .... my bad ... well then, this issue does crops up when the dos environment space is almost used up ... kindly refer to this for a solution : http://support.microsoft.com/kb/q230205/ Rgds
  4. Hmmm ..... Ahhh ... nostalgic issues ... pcchips M919 (socket 3) ... please have a look here to see if this will help you : http://th2chips.freeservers.com/m919/ -and- http://th2chips.freeservers.com/m919/unoff/m919.html I assume the M919 is a 72pin SIMMs versions ... please check that you're not mixing FP ram and EDO ram ... they don't play well together ... Last but not least is the possibility that one of the SIMM may be having a defective region ... try the free memory tester from simmtester.com ... If I recall correctly, unbranded (or unknown manufacturer) SIMMs back then were prone to stability and mixing issues ... Rgds
  5. Hmmm ..... I've checked my notes and asked someone to double check for me ..... and we had a 6600gt and a 6800xt that requires agp voltage increased to 1.6v to make it work stable ... and that's enough?? It seems to easy; I already tried forcing detection but you know the result... Yes, put this in the [Mfg] section : %NVIDIA&DEV_00F6.DeviceDesc% = NV30, PCI\VEN_10DE&DEV_00F6&SUBSYS_040110B0&REV_A2 -or- %NVIDIA&DEV_00F6.DeviceDesc% = NV30, PCI\VEN_10DE&DEV_00F6 and this into the [strings] section : NVIDIA&DEV_00F6.DeviceDesc="NVIDIA GeForce 6800 GS AGP" I've looked at 8198 and 8216 driver set and the above needs to be added ... It is already included in 8269 set ... While you're at it, try reducing ram to 512mb to see it's not win98 memory management issue ... Rgds
  6. Hmmm ..... There's another part of equation that you need to look at. Is the motherboard agp chipset driver working ? Is the gf68gs an upgrade for an older agp card ? Or built on a new system ? Does the gf68gs have enough power ? etc etc etc ..... I believe this indicates that the motherboard agp driver support is not working (happens on clean installs) ..... The steps required (driver must be last installed) to have a functional agp subsystem : 1. Install agp driver support for win98 (ie. Intel, VIA, SiS, NF2, Ali etc etc) 2. Install DX (6.1 and above, if my mind is not hazy. Some cards requires specific DX) 3. Install driver (you will need to add PCI\VEN_10DE&DEV_00F6&SUBSYS_040110B0&REV_A2 to your INF if required) If all the above is correctly installed but you still have non-functional gf6800gs then you may need to inspect other h/w (card itself, motherboard caps, PSU, etc etc) ..... Rgds Edit: Edit last paragraph
  7. Hmmm ..... Thanks awergh ! much appreciated ..... Will give it a go soon ... I'm wondering about daedalus, is it a non released stuff by alexanrs ? My apologies if I'm off topic but does daedalus implement only 32bit icon support or will it be able to integrate some other stuff in NT4VU (perhaps icon text bk) ? Rgds
  8. Hmmm ..... UberWOW ! Tihiy's done it again .... Rgds
  9. Hmmm ..... Tested about a week ago with v1.7.x and v1.9.x ... yes, they both will work but the toolbar icon gives solid red background on my tests ... Last to work out-of-the-box with no problems is v1.6.3 ... Rgds
  10. Hmmm ..... @awergh Can you kindly post nt4vu packs on multiple hosts please ? divshare wants premiums for downloads in certain geos ... That's not gonna help ... Rgds
  11. Hmmm ..... I've looked for a copy of the driver and found one ... A quick look at the INF suggests that this driver will allow the phone to be used as a modem ... If that's what you intend to do with the phone then I believe it may be possible (but not gonna be easy) to whip up something for win98 ... If you hope to transfer "data files" with this driver then its no go ... The driver uses usb CDC not MSD ... The only way to transfer "data files" thru CDC requires 2 level : 1. USB to UART bridge (that's where you see unimodem, vcomm, modemui etc etc) 2. Application to read/write using additional commands (defined by manufacturer) This reminds me of an old IXLA digital camera I used a long time ago that uses similar methods ... Rgds
  12. Hmmm ..... I'm back with time to spare now ... unfortunately WLL is still on hold as my VMware testbed system needs rebuilding, again ... The last I tinkered with WLL, I planned for a new "animation routine" ... time will tell if it'll be implemented ... I'll be looking into some usb related stuff for a while and will resume here once that's done ... Rgds
  13. Hmmm ..... @jmsallo Could you please make a zip/rar of the HP P1006 w9x folder driver for me ? ... I'd like to have a look at it and see if I can add some "stuff" to make it work ... I have looked through some HP models (1010, 1022, 2014, 2015) recent drivers and I believe I've found the the reason for the "inability" for HP to provide full w9x driver support. It seems that HP rights (read: license) to redistribute the usb printing support expired last June 2007 ... (Of course I believe that they could have just written their own usb support like what they did for their D640 series but that's not what I'm here for) ... I'm in the process of modifying some HP P2015 drivers to see the level of usb printing support required ... basically I wanted to know if basic printing can be done with basic drivers (stripped down) ... Rgds
  14. Hmmm ..... Thanks for the heads up ... went for a search and found 'em ... It's not officially posted yet on videolan site, so get your copy of 0.8.6f here and let's see if they rocks ... http://download.videolan.org/pub/videolan/vlc/0.8.6f/win32/ Rgds
  15. Hmmm ..... Sorry guys, I'm in a wee bit of a tight schedule right now ... WLL/WBL have to take a back seat for another week ... What's being done so far : 1. I've made tests on VMWare ... and while I don't experience any hanging yet, the animation does not seem to work properly ..... I'm also experiencing system restarts whenever I mount vmdisk to copy over some files (not related to WLL/WBL) ... I may need to rebuild the XP again ... 2. On my Nvidia test system, somehow the dirty bit got 'stuck' ... I'm (will be) trying to retrace what I did or why it got stuck ... but the thing is, scandisk seems to display correctly without any blue-screen/distortion each and everytime it starts ... WBL is currently in use for the test without scandisk.alt and autoscan=2 (auto) ... will see if WLL produce the same ... 3. Using scandisk.alt method as with RP7 still gives 50-50 result ... I going to take a step back (and take a breather) to see if there's anything that I missed ... Fine with me, as long as you're happy ... Rgds
  16. Hmmm ..... Not yet and no plans either ... If my mind is not too hazy, I believe the last that works on w95 out-of-the-box would be 61.76 but that was many moons ago the last I tested ... If I'm not mistaken above 66.94 has cpl api issues ... Apparently ..... but highly probable only the driver sub-system will still work if at all ... The highest that I got to work properly on w95 was 77.72 ... driver sub-system (VxDs) will work fine but certain modules like control panel uses win98 api and those need patching ... However, I do believe 82.69 will also work if we remove cpl modules ... Rgds
  17. Hmmm ..... ... Glad you enjoyed 'reading' it ... To be honest, its for the fun and pleasure of doing some asm after such a long time ... Its the rush in the brain thing ... I've almost forgotten how asm can drive people either nuts or to bliss ... It does seems to work better (that's subjective I must say) on my test systems (gf2/fx, ati rage, i810, s3) ... the brick doesn't jump out of the shaft anymore on my test PCs especially on i810gfx ... I believe the timer will be (logically) unhook correctly ... I did the re-entrant code much earlier but you posted updated WLL before me though (really, ask Drugwash) ... As for VMw, I'm prep'ing an amd with enough juice to run vmw ... It will be ready very soon for me to make test runs with vmw ... While doing TSRs and int wrapper way back then we knew we shouldn't do int in another int (unless we positively 100% know what to expect)... just that I believe there must be a better way to know when to stop that timer ... a pre-windows handshake/talkbalk flag or something hopefully simple yet bulletproof ... I agree ... saving and restore state/palette will have to be done earlier in WLL/WBL ... i'll see if it can be done with int 10h or needs port access ... but if WBL gets fat then it'll be just code options ... maybe can be done in scandisk.alt ... (oh boy, more stuff to read up ...) BTW, there's a bug in the source code within bankswitch function ... I've accidentally erased 2 pop lines ... You can d/l the fixed source & binaries or add the 2 lines yourself ... Rgds
  18. Hmmm ..... As announced earlier, the source code is now released for all to see ... It shows the current state of WBL ... the hardest part was to say something in the readme.txt ..... I am still looking for a better and better and better way to safely trigger the timer int unhook ... if anyone have any idea what I'm talking about, pls advise something useful (to the codes) ... I am now looking over the scandisk issue ... Enabling the dirty bit is not difficult but to simulate it (without actually writing it) for win.com to detect it is too much hassle (possible but takes away time)... I made a quick-n-dirty patch to turn on dirty bit for my test runs ... I'm following WLL method by using scandisk.alt for now and it seems there's some housekeeping to do before scandisk.alt will work correctly ... out of ten test runs, five works and another five hangs ... I must figure that out first ... There's another approach that I'll be working on and that is to detect dirty bit before logo displays ... I know this will work better than scandisk.alt .... need to read up a bit more on that too ... Any comments/feedback, pls leave it here ... Rgds
  19. Hmm ..... Work on the scandisk issue just started ... have successfully triggered scandisk using 'dirty bit' ... it wasn't that difficult after all ... Let's see if my approach works ... Then you'll need a 1 or 2 tick timer in between fades ... Rgds
  20. Hmmm ..... That's probably why I missed it ... I didn't use svgacom style for test runs ... I embed my debug routines into WBL for certain debugging purposes ... switch them off for final binaries ... makes life more enjoyable .... Let me guess, the image doesn't show the proper color palette once you're done with the fade-in ? ..... That's because the palette register expects those values as RGB but BMP stores them in reverse as BGR ... There's so many timer routines that we can use ... My favourite two were and still are [a] hook timer int 8/1c (with increased resolution) BIOS timer calls depending on requirement ... for simple ones, BIOS timer calls is usually sufficient ... You can find the code floating around and here's the code in its simplest form (remember, its not refined code, a more refined version will have more checks in it) ... Delay proc near ; bx contains no of ticks. Each tick is 1/18th of a second. push ax push dx mov ah,0 ; Get system timer tick int 1Ah ; Call ROM BIOS time-of-day services add dx,bx ; add our delay value to dx mov bx,dx pause: int 1Ah cmp dx,bx ; Delay duration passed ? jl pause ; nope, wait sum more pop dx pop ax ret Delay endp That's for you to decide ... If you meant the header reserved fields then your watermark is limited to 4 or maybe 6 bytes ... There's 246 bytes still unused in the palette table after embedding the coordinates ... 'watermark / magic number' just adds 'complexity' to something that should be simple to use ... Quote from Albert Einsten: "Everything should be made as simple as possible, but not simpler." I now believe that while the embedded coordinates makes 'brick/progressbar' positioning easier, it also 'locks out' other valid bmps ..... I will make minor adjustments to WBL to display a valid BMP even if the coordinates are invalid ... If you were making changes to WLL then you'll have to replace the original palette setup routine with the zero-palette routine ... Once the bmp have been loaded, start the fade-in cycle ... Can't focus too much on the code these days, as I have some health issues to attend to, but still trying to keep up with the news. Take care and get well ..... Rgds
  21. Hmmm ..... Right, I'm back ..... Uh-oh, will do VMWare test runs later ... perhaps in the next 2-3 days (my underpowered PC no longer have the turbo button) ... Yeah, that kinda sucks ... I have a feeling its not the vga registers, probably something else ... i'll look into it soon ... well, worse case scenario is I put some checks for VMw environment and skip whatever that bugs VMw ... Yes, that is correct. Fade-in happens before win.com. I had fade-in done using three different methods : 1. integrated into Timer (lazy messy work, off to recycle bin) 2. chained to Timer (I like this one, its so smooth but it's fat) 3. moved to Loadbmp (I prefer this one coz I can dump it) All three have pros and cons. I chose no. 3 to minimize final memory usage. Two tables are used to skip palette register read/compare. If I use only one reference table, I'll have to read/compare palette registers and I'll lose some speed. Method ex-1 & 2 will animate, fade AND run win.com seemingly all at once ... but this makes it fat ... Fade-in code squeezed to less than 200 bytes. Plus two table and after win.com, WBL ate 3.5KB (that's 4KB locked out) which is not acceptable to me ... I want slim WBL not fat cellulite eye candy ... 2048 bytes is the most WBL will eat and no more ... I don't want to be too creative and save table in offscreen vga ram ... I'll keep it simple and still have the impression of fade-in, so method 3 works best for me ... method 2 is also available for anyone to make test runs ... Yeah, the zero palette code was missing ... on i810 I didn't notice it but on the ati it was glaring at me ... That's already fixed ... Method 3 fade-in delay is about 1 tick (55 ms, 1/18th sec) apart (on my slow machine it looks like 2 ticks)and it allows for a delay anywhere between 1 to 65535 ticks apart using BIOS timer unless it overflows (that's only theoretically, but I'm lazy to actually measure it ...) For fade-in to work nicely across the board, I now wait for retrace. Without it, logo flickers badly ... ... WBL can be a truckload feature full ~64KB in filesize but must use no more than 2048 bytes "resident" before win.com ... Currently WBL (fade-in method 3) is about 1.8KB "resident" ... Codes are split into retained/expendable sections ... Sure, let me put more lame comments and a nice readme first ..... It'll be ready for release this weekend ... yeah, definitely coming soon to a computer near you ... There's no right or wrong here ..... (I did mentioned to you before that it was supposed to be my "major re-arranged version") ... I've given it some thought before I replaced it. I want something easy to use and lame easy to code ... The brick is working to my minimum specs and everyone's invited to do whatever to it (once released) ... its a limitation but definitely not a bug .... Ok, as you wish ... it's now added to the source and I no longer will post debug binaries since the source will be available soon ... In your case : "Use the source, Luke" ... I must have missed that original code or the original code have missed me ... was it checks for mode change or something else ? I've just implemented a different way (better way? maybe) to check for mode change and drop that int 10h vesa mode check ... I believe that when win.com loads it disables VESA extension and VESA function AL=03 becomes text mode function AL=03 ... That's probably why text mode appears before windows loads ..... To everyone, I have made many small changes to WBL codes ... The new WBL archive will have both fade-in methods for test runs ... also contains new unhook trigger, fixed off-shaft-brick draws and missed-erase-brick draws (I do hope so and I need feedback on this), flicker free fade-in and some other minor fixes ... The target/objective for this current exercise is deemed to be fulfilled if no related bugs is reported ... New target/objective that will be looked into : - VMw erratic/hang issue; -and- - scandisk screen display issue Oh boy, this will take a while ..... Rgds
  22. Hmmm ..... I may have an idea or two ..... I have a plate full to chew right now; will be back in a couple of days to whack scandisk issue ... (I'll read up a bit and simulate dirty bit ... then I'll see how to add it into a nice cocktail) 1. Logo validation routine: a. splash.sys must exist b. Filesize 308,278 bytes (301K) c. Must have BMP signature d. Must be bmp ver 3 (40bytes header) e. Must be 256 color. f. Must be 640px width g. brick size width & height must be non-zero I will stick to embedded data in palette table as no random color dots will appear at the top left of screen as with recent svgacom versions. It's the current best solution for variable brick position & size. However, there is a limit to the brick/progressbar size. It is fixed to 512 bytes ... This is not a bug but a feature ... (Note to meself: check for bricksize out of range) Enlarging the brick size will eat up dos low memory ... wbl has a very humble target of not eating more than 2KB before win.com ... moving to higher memory is not in the pipeline ... 2. Text in background means message outputs are sent after wbl changed gfx mode ... probably some error msgs from memory manager or something that caused the reboot ... (There's a dos console-output-redirect-to-file TSR utility somewhere that may help you get those msgs ... it'll eat up memory though ...) 3. This is an 'inheritance' from wll.com ... Gfx/text mode changing/swapping is the issue ... I'll see if I can make them play nice and still stay within 2KB limit ... A working solution to this is also linked to scandisk issue above and may take a while to get properly cooked (nope, it's not fastfood) ... Anyone who made test runs, kindly leave a note whether its working or otheriwse ... Inputs (pros & cons) are appreciated ... Rgds
  23. Hmmm ..... I've added a nice touch to WBL today ... A simple fade-in routine for the bootsplash logo ... WBL will now fade-in the logo and animate brick/progressbar simultaneously ... Get it from below, make test runs and let me know how it goes ... http://www.msfn.org/board/Fixes-and-enhanc...745#entry746745 Rgds
  24. Hmmm ..... I've been wanting to give wll.com a good whack since some time last year ... Finally, Drugwash took up the challenge of doing something to wll.com ... I have been helping Drugwash with his attempt and I promised him that I'll look at some of the more annoying issues with wll.com last weekend ... Drugwash is currently doing some stuff with io.sys patcher and I will temporarily oversee bugs squashing until I quit or someone better takes over .... (yeah, I sucks) ... A week has passed mixing this 'cokctail' and the result is a clone based on wll.com and renamed to wbl.com ..... I hope those who were having issues (or not) with wll.com could spend a few minutes making some test runs with wbl.com ... No installation is necessary to test it out ... If you find bugs with it, please report. If it works good, you can just copy it over wll.com ... Wbl.com have been tested on Nvidia, Ati & i810 gfx ... I have made major changes and re-arrangements. Source code will be released within a week if no annoying issues are brought up ... Anyone who wishes for the source code now, please pm me (as I may make/add more changes to it) ... There are now 6 files in the archive: 1. readme.txt - some notes & description of progressbar creation 2. splash.sys - bmp logo file with embeddedd coordinates data 3. wbl.asm - the source code 4. wbl1.com - brick animation without fade-in 5. wbl2.com - brick animation with fade-in (mehotd 2 - more memory usage) 6. wbl3.com - brick animation with fade-in (method 3 - less memory usage) Important: these must should be run in pure dos ... running in dos box may crash it as it will make direct memory access here and there ... update: wbl1.com and wbl2.com can be run within windows ... wbl.com will not ... To make test runs, copy splash.sys to root folder C:\ and run wbl1.com ... See if any visual smear/glitches occurs ... I'm interested to know if there's any issues here ... (my test runs shows no issues) wbl2.com is usefull when you want to see each brick/bullet/progressbar movement on screen ... If you have RP7 logo applet installed and willing to make test runs, copy splash.sys to root folder C:\ and copy wbl.com as wll.com (Don't forget to make backup copy of wll.com) ... Reboot, see result and please report any issues ... (This is the real test) Alternatively, boot to dos ... copy splash.sys and wbl.com to root directory and run wbl at prompt ... Changes to the bmp logo file: Basically still a bmp file with coordinates embedded in the 4th byte palette table. It is unused for 256 color bmps and deemed safe for use ... Offset are listed below, two bytes required for each ... Offset for embedded val (from BOF) topHor : offset 57 & 61 topVer : offset 65 & 69 width : offset 73 & 77 height : offset 81 & 85 shaftw : offset 89 & 93 Changes to wll.com and reborn as wbl.com 1. Timer chain/re-entrant/safe unhook 2. Internal stack allocation 3. Code re-arrangements & comments 4. Replaced brick animation routine 5. VESA checks 6. BMP file/header checks 7. Banks calc'ed using vesa wingranularity 8. Various cleanups Target of this exercise: 1. Resolve intermittent brick glitches (drawn way off shaft) 2. Resolve ati screen bubu .. Thank you & rgds p/s: Before I forget again, thank you Tihiy for the source codes ..... WBL archive with source codes WBL_with_source.rar Edit/Added: Added WBL (fade-in) archive Removed older versions WBL source code & binaries
  25. Hmmm ..... VMM32.VXD = all compiled Vxds required by windows during setup or after certain windows updates (ex: win95 osr2 usb update). All unnecessary data in VxDs are removed when it is compiled into vmm32.vxd ... Most of the time updated Vxds are placed in the VMM32 folder without being re-compiled into VMM32.VXD ..... Generally, the latest versions will be in VMM32 folder. Removing them will force windows to load the "older" ones in vmm32.vxd ..... This is correct ... To manually compile vmm32.vxd, go here : http://www.helpwithwindows.com/techfiles/vmm32.html I have made my own batch file ... It's in one of my archived storage, if you want it then let me know and I'll look for it ... There's also sample batch archive at http://rosecitydownloads.com/vmm32.zip that can-be/was used with the guide ... mine automated the whole process ... Rgds
×
×
  • Create New...