Jump to content

Fixes & enhancements for WLL.COM


Drugwash

Recommended Posts

my logo is 2bytes larger. dont know why. (256 colors, 640x, version unknown)

the message on background was no error message. it was info that updates are being installed (classical info while installing anything)

Link to comment
Share on other sites


Wow, nice work you have going here. I'll test it on my laptop too these days and let you know if there are any bugs. ;)

I third the idea of DOS scandisk being the worst disk check utility ever. I think the DOS versions of Norton Disk Doctor or Disk Minder from Network Associates's Nuts & Bolts are a million times better. Those two programs are old enough to be classified as abandonware, and are pretty tough to find too (particularly Nuts & Bolts), so why don't we patch one of those in one of the 95/98 service packs? It takes just a rename.

Link to comment
Share on other sites

Well, well... looks like I missed the party, huh? Eh, I've been kinda busy retouching the installer and tidying up the code.

I think I managed to get it recognize the current active drive and Windows path as well as any %windir% name up to 50 chars. Also added LOGO.SYS automatic copy from current dir to active drive's root dir and reduced buffer size to 32 bytes.

So basically now it's a full-fledged installer/uninstaller and has been renamed as such. Ladies and gentlemen, we are proudly presenting...

WLL INSTALLER/UNINSTALLER v0.0.1.1 : WLL_Installer_0.0.1.1.7z

Next I'll be working on adapting LogoTool to the palette storing-version of WBL and probably adopt the same solution myself in my WLL. Keep in touch. ;)

Note to PassingBy: I've checked your code (finally) and for now there's 2 things that popped at me as not quite right:

1. The way you're moving the bullet is wrong. When the 3 bricks that make the bullet are not identical in shape/looks, the operation at the end of the shaft will make it look like you're cutting out the snake tail. :)

2. The debug versions would not run if the bmp is not present in C:\ - I see this as a flaw, because as a debug version it should run from whatever path and recognize the bmp in the same folder. Solution is to add an IFDEBUG condition that loads and alternate path for the bmp.

There may be problems in VMWare because of the VESA check. I noticed in the original code from Tihiy, that the respective check was disabled, exactly because of VMWare so I didn't touch it in my version either as I have no way of checking the behavior under such environment (as you already know).

Oh and thank you for the nice ideas I got from your code. ;)

Link to comment
Share on other sites

And here's the new version of LogoTool: LogoTool2. Based on first version of LogoTool, it is designed to patch exclusively WBL-style bitmaps (using the palette storage addresses rather than visible area as in the first version).

It is intended for creating SPLASH.SYS animated boot logos, solely for use with PassingBy's WBL.COM.

Please note that the logos created with this tool will not animate on either Tihiy's original WLL.COM or my mod.

Download: LogoTool2 v2.0.0.1

Sorry for the temporary inconvenience, previous version was bad. :(

Oh and the one above got debug info on. :blushing: May be useful to someone though, so I let it be.

Here's the final, working version: LogoTool2 v2.0.0.2

Whew!

Edited by Drugwash
Link to comment
Share on other sites

Hmmm .....

Right, I'm back .....

..... When i've tried it in VMWare, if was kinda catastrophic .....

I should say that in VMWare video register manipulation often produces unexpected results .....

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 ...

Also, i've noticed that you're fade-in before actually starting win.com?

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 ...

And uh... you're already 3KB, are you shrinking memory on loading procedures?

:) ... 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 ...

And I would like to see source, and help you ...

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 ...

The way you're moving the bullet is wrong .....

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 .... :)

The debug versions would not run if the bmp is not present in C:\ - I see this as a flaw, because as a debug version it should run from whatever path and recognize the bmp in the same folder .....

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" ...

There may be problems in VMWare because of the VESA check. I noticed in the original code from Tihiy, that the respective check was disabled, exactly because of VMWare .....

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 ..... :whistle:

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

Edited by PassingBy
Link to comment
Share on other sites

The original SVGACOM code I've been performing test with contains:

  ;call CheckSVGA
;je completelyfail; if textmode ;THIS CHECK IS DISABLED FOR VMWARE!:(

and the actual code is:

CheckSVGA proc near
mov dx,3ceh
in al,dx ; read index reg
mov ah,al
mov al,6
out dx,al ; use Graphic6 reg
inc dx
in al,dx ; read it
dec dx ;
test al,1 ; if bit0=0, then text
mov al,ah
out dx,al ; restore it
ret
CheckSVGA endp

I've stumbled into a fading code myself, while playing with some color shifting routine. The effect however looks incomplete and I miss a timer.

Also switched to palette storing in my code too, so LogoTool v1 will become obsolete.

I've been thinking about watermarking the new logo versions with our own 'magic number' so the code would recognize them at once and instantly reject any other file, be it 640x480 8bpp bitmap or whatever. Would it be OK to use the 'Reserved' space or should we grab another 2-3 palette bytes, for safety? The header's being read first so I thought it would be better to fit it in there before going through any more code. Waiting for your opinion.

I did add zero-palette code to a test version but the image still briefly flashes when pixels are loaded, before going to a complete blank, on my nVidia GeForce4 Ti4200 card.

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.

Link to comment
Share on other sites

Hmmm .....

The original SVGACOM code I've been performing test with contains:
 ;call CheckSVGA
;je completelyfail; if textmode;THIS CHECK IS DISABLED FOR VMWARE!:(

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 .... :)

I've stumbled into a fading code myself, while playing with some color shifting routine. The effect however looks incomplete and I miss a timer.

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

I've been thinking about watermarking the new logo versions with our own 'magic number' so the code would recognize them at once and instantly reject any other file, be it 640x480 8bpp bitmap or whatever. Would it be OK to use the 'Reserved' space or should we grab another 2-3 palette bytes, for safety?

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 ...

I did add zero-palette code to a test version but the image still briefly flashes when pixels are loaded, before going to a complete blank, on my nVidia GeForce4 Ti4200 card.

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

Link to comment
Share on other sites

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 ....
As a beginner, I tried the easier way: less code to mess with. :) Anyway, my first intention was just to embed the coordinates in the bitmap - the rest just came along...
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 ...
He-he... wrong guess. The colors come up fine, but the fading I came up with has only 5-6 steps and the effect is too choppy and fast. I'm using a refresh sync

but I need more steps, it's just not right that way, although the code is small. And I'm trying to relay the least possible on the BIOS, as implementations may differ, from what I've read around.

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 ...
What do you mean by 'valid BMP'? A classic logo with standard-placed animation or just with no animation at all? I thought this system should lead to a new class of animated logos, all with embedded coordinates; that's what I've created LogoTool for: to ease the creation of such logos.

After all, we might as well let the old cycling palette logos run if the user forgot to update LOGO.SYS for the WLL system...

That's for you to decide ... If you meant the header reserved fields then your watermark is limited to 4 or maybe 6 bytes.
I think that should be enough. The recognition code would be simple: if the watermark is present, check coordinates validity and proceed with the code; if it's not present, then either 1) assume classic logo and animate at standard coordinates or 2) assume ordinary bmp and just display a static picture with no animation at all.
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 ...
That's what I did: retrieved palette data to a table, sent blanking palette to the DAC, loaded in the bitmap pixels, sent working palette to the DAC with the fading effect (which is embedded in the palette sending subroutine). I could send you the SVGACOM code I've been working on, if you want (still working in safe mode :) ).

Oh and thanks for the good wishes; it will take some time though.

Link to comment
Share on other sites

Hmm .....

.....

Edit: oh, simulate dirty bit? That's awesome if you can, since i was unable to :}

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 ...

He-he... wrong guess. The colors come up fine, but the fading I came up with has only 5-6 steps and the effect is too choppy and fast. I'm using a refresh sync .....

Then you'll need a 1 or 2 tick timer in between fades ...

Rgds

Link to comment
Share on other sites

I third the idea of DOS scandisk being the worst disk check utility ever. I think the DOS versions of Norton Disk Doctor or Disk Minder from Network Associates's Nuts & Bolts are a million times better. Those two programs are old enough to be classified as abandonware, and are pretty tough to find too (particularly Nuts & Bolts), so why don't we patch one of those in one of the 95/98 service packs? It takes just a rename.

FYI:

N&B scandisk is here:

http://www.mdgx.com/add.htm#TLS

* Helix DiskMinder Hard Disk Scanner + Repair tools v1.03 improved Microsoft ScanDskw for Windows (SCANDSKW.EXE) + ScanDisk for DOS (SCANDISK.EXE) replacements DMindr32 32-bit (DMINDR32.EXE) for Windows 9x/ME + DmDOS 16-bit (DMDOS.EXE) for MS-DOS 5/6/7/8:

http://www.mdgx.com/files/diskmind.php

Direct download [478 KB, English]:

http://www.mdgx.com/files/DISKMIND.EXE

HTH

Link to comment
Share on other sites

Thanks for the links MDGx. I already had the full suite (which i must say it's just like the current "tune-up" programs - ie almost useless), but thanks for your post, as now i noticed i can have media player 10 in my 98. :D

Not that i'd actually use it (MPC+Winamp here), but that preview thingy in the webview is cool, and the wmp10 theme would look much better on it than the wmp9 one. Downloading now. ;)

Edited by Th3_uN1Qu3
Link to comment
Share on other sites

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) ... :wacko:

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

Link to comment
Share on other sites

Thanks for releasing sources, they're awesome and hilarious.

Now, tell me please about what have you achieved :rolleyes:

Does it work better with some cards? What about VMWare?

I am still looking for a better and better and better way to safely trigger the timer int unhook
Well, are you sure it is bad? Ideally, some Windows structures or undocumented interrupts should be checked.

As for scandisk issue, i think that video state/palette save/restore will work, if it does not hang system. I must build a real system with nVidia card to test that.

Link to comment
Share on other sites

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 ...

Now, tell me please about what have you achieved

Does it work better with some cards? What about VMWare?

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 ...

Well, are you sure it is bad? Ideally, some Windows structures or undocumented interrupts should be checked.

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 ...

As for scandisk issue, i think that video state/palette save/restore will work, if it does not hang system. I must build a real system with nVidia card to test that.

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 ... :blushing:

Rgds

Link to comment
Share on other sites

Looks like I missed the party again. I guess I'm jinxed. :(

Anyway, news is I managed to fry the code as much as it now drives Windows into a protection error after the animation. And all I did was just rearrange the routines a bit, trying to shorten the code (there was unnecessary double code in the error message display), changed the %windir% searching routine and added my version of fade in (and fade out which only works in SVGACOM as Windows cuts WLL short when it kicks in).

The same code (with maybe extremely slight differences) runs fine on the Win95 machine (P I 166MHz with S3 Trio64V2/DX videocard). The protection error happened 3 times and once it mentioned CONFIGMGR. I performed a search for this term and the only notable result was inside USBUI.DLL. So I could somehow connect this with Offler's earlier reports about WLL hanging at detecting USB devices (I have a USB webcam permanently connected to my main machine where the errors occured). I may be off-track though. And again I have to blame it on my lack of knowledge and experience - good will seems not to be enough.

I'll check out the new code, see if I can make anything out of it. If anybody wants to check out my code, ask and ye shall receive - I'm reluctant to intentionally releasing bad code publically; might help understanding and fixing the issues.

[EDIT]

Forgot to mention the watermark. I implemented a 4byte watermark in the bitmap, to distinguish an ordinary (or old version of) LOGO.SYS from an embedded coords one. The bytes are at offset 06h: 54h 44h 50h 32h and are automatically written by the new version of LogoTool2 that I will publish if everybody agrees with this system.

I believe the code check would be drastically reduced when using the watermark, as it will assume correct/safe coordinates as opposed to no coordinates at all.

Tihiy, PassingBy: please state your opinion about this. Thank you.

Edited by Drugwash
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...