By accident I got involved into an ASM discussion, related to WLL.COM, the well-known animated boot logo loader in Tihiy's Revolutions Pack. As my ASM knowledge is limited to the Z80 stage years ago and holli - the other person interested in improvements - is about at the same level, I thought I'd start this thread in seek for help from some ASM knowledgeable people.

I'll point out the main issues that we wanna fix:
1. Get rid of the blank screen & halt at startup, when LOGO.SYS is missing or a different version found
2. Be able to load custom boot logos made by users, where the progressbar is placed at different coordinates

Now, the second issue may be much simpler to fix now, after the hint offered by Tihiy (thank you! ) regarding video organization by banks. However, the first one is stuck because of the lack of knowledge regarding filesize comparison in ASM, in DOS (16 bit) mode.

The discussion that took place in the Revolutions Pack thread should be moved here soon. Any help is welcome.

Oh, I'd love it if you could fix up WLL.COM!

Just a small question: were you also planning on fixing the glitch where the loading screen stops moving and inverts colors whenever a DOS program (likely in Autoexec.bat) trys to display output text?

Hmmm, didn't know about that one (but I have a hunch Tihiy did ). I suspect it's because the screen is in VGA mode at the time when other module tries to display text. Obviously this shouldn't happen - it should either continue the animation or switch to text mode and display whatever needs to be displayed.
I'm afraid that'd be a little too much, at least for me. Let's hope some good people would pass by and lend a hand.

For now I managed to understand 95% of how the animation works, so the progressbar can now be placed at whatever position. Haven't yet checked the limits - if any - for progressbar size and animation width. There's a little quirk about the number 13 in the constants and I can't work it out for the life of me.

Next I'm trying to automate the calculation of the bank according to the user-given coordinates.
Then I'll try to find an empty space in the bitmap header for the specific coordinates. Only 8 bytes needed (4 WORDs).
After that, find a way to load the coordinates from the file into the constants (would they become variables?).

Most of the code regarding the checks if file exists and file size matching is in place, but the latter is still incomplete.

Then you can't say 95%.

=

Do you get it now?

I'm absolutely uninterested in this project unless it will fix bugs for me
Latest available source i've recovered from marxo is attached.
Click to view attachment

Hi folx,

first at all sorry for entering so late... I tried to compile a WLL.COM and a SVGACOM.COM, but I had to learn how to use the compiler first.

Now you can see that I'm not the man to code any source in assembler. I don't understand assembler code, but I think I'm able to understand some logical coherences.
If I could help in this project, then it can be only something like brainstorming about some logical things and no coding instructions. Sorry.

But I'm happy that someone wants to help fix the issues in WLL.COM.



If you'll help us to resolve the problems with WLL.COM, you'll get your bugfixes...

So let's do it!

Stay blessed,

Holli

Tihiy, I already figured out the replacements for the value of 8, but as I said before, it's the 13 that I have no idea where it comes from. However, beyond this, when I replace the values exactly as you pointed out, I get the progressbar out of its track to the right on first run. This didn't happen with the original values. That's why I'm confused about that 13.

Anyway, the most important thing we still need to find is the file size check routine, which doesn't work.

I'll have a look at the new sources in the mean time... unless I fall asleep (been awake for 22 hours already )

Oh holli: welcome to the team!

[EDIT] I got to a result finally with the file compare routine, although it's not exactly that but just reading filesize from the bitmap itself and comparing with the known value. But it works, so...

That animation still gives me more headache than this tooth, but for now I'll let it be. What I wanna do now is find an elegant way of centering those strings on screen, 'coz now... ugh!

Enjoy the attached modified SVGACOM.ASM and the rest of the package. On with the work!

[EDIT 2] Today I just noticed a video memory corruption when running the previous version of SVGACOM.COM that was attached here, so I slightly modified it, saving the registries at startup and restoring them before exit - hopefully it will prevent such corruption in the future. That happened while testing under Windows, dunno the implications when run in pure DOS mode at Windows startup.
[EDIT] Link removed. File is available for download further on in the thread. [/EDIT]


P.S. Is there no moderator willing to move those posts here from the RP 7.x thread? Just to clean that one up, at least...

OK, first point has been completely implemented. There are 2 different error messages according to whether LOGO.SYS is completely missing or it's an old/different version.
The file size check is now correct - no more reading the values in the header but actually calculating it.
[EDIT] I forgot to say that the error strings are now automatically centered on screen, so they can now be changed at will (within the 80 characters limit) and this may also leave room to translations, using an external text file. If this function is needed, tell me and I'll try to implement it.
The file would have to contain 2 strings of maximum 80 characters each, terminated with a dollar ($) sign.
[/EDIT]

I couldn't find an empty space in the logo header (still uncertain about 34 bytes that I have no description for), so I decided to load the data in the visible area. It will be 5 WORDs not 4 as I previously stated and will be more or less visible in the top-left corner of the screen, depending on the rest of the image.

I also managed to get the data from the image to program's buffer and I'm now working on integrating it with the program. Three more values need to be calculated (bank, progrstep and progrstart) and I'll be done with this part. I might need some help with the bank part, since I couldn't find any pertinent information on how to calculate each bank's boundary.

Still, TASM is complaining about a couple of lines so I won't be releasing anything until I find and fix the issues. Jeez, I'm shoving ASM into my brains with the bulldozer!

OK, here's the troublesome part - in this struct I pass the progressbar data read from LOGO.SYS:

The compiler wouldn't let me use the parapro.xxx values directly in the instructions where they need to be, so I did this:

However, now I'm getting the error Need register in expression in two identical lines containing progrwidth, lines that I have not changed whatsoever:
mov [copylen],progrwidth

Anybody can tell me why and how to fix this?

Hi Drugwash, the answer, why 13 "steps", is easy to know: If you replace the original "Windows 98" \LOGO.SYS with a screenshot of a "Windows XP" startup logo, you'll fast know, what I mean. The Progress bar of the Windows XP startup logo contains a progress bar witch have three blocks of 6 pixels spaced by 2 pixels (that's why "8"!). To move the three blocks of the progress bar from left (1 block shown) to the right (also only one block shown), you need 17 steps.
Have a look at the lines "progrbegin" and "progrend":



"progrbegin" starts three -8*3 steps before the visible animation, "progrend" stops three steps after the visible animation +8*3. progrmax = progrstart+8*13. So you have 13+3+3 = 19 steps, 17 visible and two steps where no block is shown.

You can get a 640 x 480px scaled WinXP startup logo by the google picture search. Mostly you have to move the Progress bar to the first position, but that's not that hard...

By the way both ("Windows 98" and WinXP) progress bar sizes are 22x9 px.



Thanks for your welcome. I hope, I can help...

Sorry that I don't try your source soon, but that's my second step after I downloaded a program to handle 7zip archives... *g*

Be blessed,

Holli

Actually your help is greatly appreciated and most welcome. I think I can now fully understand how this all animation works, 'coz until now I was just shooting in the dark and killing no rabbits.

Thanks to more help from PassingBy I should soon be able to fix the remaining issues with the values that need to be calculated. The issue with the parapro.xxx variables is already fixed.



If you try the version I attached above, please fix the animation values to match the correct ones, as I altered some that I shoudn't have. To check all its functionality you need to perform 3 checks:

1. Without any startup.bmp in the same folder
2. With any old-version LOGO.SYS renamed to startup.bmp

3. With the embedded startup.bmp


Please note that the version posted does not have the error messages centered, but the one I'm working on does.

I'm happy that programming needs a lot of mathematics, so I can help you without understanding some assembler code.
I made this XP startup logo (it really looks the same like the original - there's no difference!). And if I saw the progress bar, I noticed, how it works. Without the three blocks of the progss bar it is really hard to realize how it works.

I used your source and it's awesome! The animation runs on my laptop (the original source won't do this). You also created a nice logo. But there are a few things:
1. The size of the progress bar (14px) seems not optimal for animating. Try to think in three blocks spaced by 2px regarding the terms above, you should use 13px or 16px. If you use 13px progress bar, use progrstep=5 (3px block + 2px space) or progrstep=6 (4px block + 2 px space) for 16px progress bar. Then you need a progrmax=progrstart+progrstep*X where X = (lengh of animation + 2 px / progrstep) - 2.
To explain the formula: I used the XP \LOGO.SYS and figured out the relationship of the animated witdh, the animation width, the progrstep and the 13.
You can do your own brainstorm and you'll find the same formula.
So, I decided to enhancd the animated block with 2px and set "progrstep = 6" the animation lengh of the startup.bmp (180px) don't fit with this parameters, so I enhended it with 4px, so X = (184px + 2px / 6px) - 2 = (186px / 6px) -2 = (31) -2 = 29. The resulting "progrmax" line is:


Please note: check out the parameters progrstep, progrwidth and X before you create your startup logo.

2. Threre is a visual glitch by moving the progress bar: on my notebook (ATI Rage 128 Pro graphics) the animated progress bar is a block of foreground color (magenta) , on my desktops the correct bar is moving, but the background color (black) switched to the foreground color (magenta) after redraw the progress bar.

Hope I was helpful for this progress bar stuff...

GOD bless,

Holli

Edit: I checked out your error messages. But I don't like to press a key while starting up my system ('cuz I often turn the computer on and go to get a coffee... ;-). It is possible to put out an non centered massage in the first two lines like this:

Thanks!
___

The "XP" \LOGO.SYS seems so real! I shocked some people with using it as a screensaver under XP.
(If you also want to shock someone, take my attachment and store it into C:\WINDOWS of a Windows XP system. Then import the "screensaver.job" file into your scheduler (just drag and drop) and activate it. Every time, when the system is idle for more than 5 minutes, Windows XP "reboots". To stop rebooting and return to Windows XP press any key.... )

Click to view attachment

With some more invaluable help from our friend PassingBy as well as the excellent analysis and findings from holli above, I was finally able to surpass the remaining mysteries of bank calculation and I can now proudly present...

THE FULLY BMP-DEPENDANT VERSION OF SVGACOM!

The package contains detailed instructions on how to calculate and add the parameters to your bitmap logos.
Please only test this on a non-critical machine as it may contain bugs.

I'll be waiting for feedback regarding (im)proper operation on different systems, with your own logos.

If everything goes well with this code, then we'll go to phase 2, which is integration with WLL.COM and hunting for any clashes with the existing WLL code.

[EDIT] Link removed. File is available for download further on in this thread. [/EDIT]

Enjoy!

@ holli: I have intentionally left the 14px 'bullet' in the example bitmap so users can see what happens with miscalculated values. In the example animation, they will notice the 'bullet' is cut to the right by 1px, because of a bad length conception.

If you don't want the keypress in case of error (although I highly recommend it as it should be a one-time stop until the issue is fixed by restoring an appropriate LOGO.SYS), you may comment out the following 2 lines in the allset: subroutine:
mov ah,00h ; waits for a key to be pressed
int 16h
Related to that, you may also modify the Preskey string at the end of the code with any other string you like - just make it less than 80 characters long and make sure it terminates with a dollar sign ( $ ).

Hi Drugwash,

nice work, I love it!

I took your source and made my "Windows XP" logo. But...uh, 5 ugly pixels in the top left corner! So I did a dirty thing. I searched a place in the header where I can put the neccessary information in. At offset 26h I find four 0000h blocks. The needed 5th block was 0001h. I was very bad and overwrote the 0001h. I can't notice any visible glitch. So I changed the source
to and it works fine.
At this point I've got a tiny question: why do you use 1078 instead 0436h for the offset? Or can both be used?

(Hm...don't I wrote some posts ago I cannot put any assembler code here?!? )

Thank you very much for your great documentation! A dummy like me can very easy work with it. But...only one tiny thing... *ggg*

must be
Your're amazing! The shaft length in the picture is 118px wide (that's WinXP logo standard - I don't altered it). With your formula I must give a shaft size of 120px. If I don't, your code decreases the number of passes by 1. It's cool. But I must remember that if I build a new logo, otherwise I'll wonder why not the full shaft size is being used... ;-)

Thats all folx.

I hope, my explanations are use- and helpfull.

Stay blessed,

Holli

Edit: I commented out the keypress code and changed the row and col coordinates to display the text in the top left corner. But when the program terminates, the text was deleted. How can the program terminating without erasing the text?
I tried the program on my Compaq Armada 1750 laptop and the visual glitches of the animated bar are already present :-(

I've been searching for an empty space too, but after carefully checking the bitmap header structure (which is detailed to the end of the code - the BMPHEAD part, 54 bytes long) I came to the conclusion that it'd be safer to use a visible address, at least temporary.

What you did was hack into the palette and that is not at all recommended, as it will alter colors depending on bitmap content. For example, look at my startup.bmp and at offset 26h you'll find C4, 0E, 00, 00, C4, 0E, etc. That's part of the palette which is 256*4 bytes long.

There are still 34 bytes that I don't know anything about, but they're not empty (at least in my bitmap).

As for 1078... he-he... I confess I could never stand hexadecimal. Never ever. So as much as I can, I use decimal - it just feels easier, that's all. Not to mention the compiler kept complaining about a perfectly legit hex value, driving me up the walls, until I realized it was considering it as a label (the value started with a letter) so I had to add a zero in front of it. Well, decimal values don't give such headaches.

Darn, you're right about the commands in the readme - I did put the right ones in the batch but the readme just slipped me. Thanks for noticing, I just fixed them now.

Dunno what to say about the shaft... I noticed a small discrepancy myself, but I blamed it on bad calculation of starting point. I did mention about the 2 extra px in the readme though.

Hmmm... you bypassed the automatic string centering code? I wonder why... And that keypress - that's why I put it there: because the screen gets wiped out and the user has no possibility to acknowledge the error and thus attempt to fix it, which already defeats the purpose of error messages themselves.

Regaridng your laptop... I know OEMs are kinda naughty; it would be no wonder if Compaq did something to the videocard that prevents it from correctly switching banks or something along that line. But I can't say for sure, that's why I asked more people to test on different machines, to get some feedback whether the code is faulty or different hardware configurations can misbehave.

Latest news: I already compiled a version of the WLL using the latest sources offered by Tihiy but I have no guts to test it on my main machine and the test one doesn't have 98SE on it (yet). So... dunno what to say. I think I'll wait until tomorrow (heck, it's already tomorrow - 2:30 AM here).

Ah, now I know why my bytes are empty: The WinXP-Logo is original a 4bit picture, increasing the colors to 256 may let some colors be 0000 (black), so I can use the offset 26h...

Yeah, and here my idea: If vou create a new Logo, be sure to edite the first 6 colors of the palette to black, so you can put your information into the palette. Be sure that everything black in the picture uses the 6th color...

Hm... I write 01h (8bit) or 0001h (16bit) instead 1h by habit. Every digit of the hex are 4bit of the binary. So, if you have to read some BCD code (often in PLCs), every hex digit is a digit of the BCD. So 0123h is 0123BCD ;-)

It's also a habit...I like error messages when they displayed in "normal" reading order (top left). Why must the program blank the screen "after" it terminates? Cannot the program leave the screen how it is? WIN.COM needs some time before blanking the screen, thats time enough to read the error message. I tried to built in a delay of 2s, but I can't figure out where to find the time delay for progress bar moving and I don't know how it works.

What about a boot disk (WinXP is able to create a WME one)? You also can use a bootable USB stick, if your BIOS can use USB media as boot devices. Or try a W98-CD to boot from. But it can be that your new computer don't contain a floppy drive. That's the biggest bulls***. A computer without a floppy drive isn't a computer...
Return to topic: what's about a config file like logo.ini containing the neccesary information for the animation?

I wouldn't mess with the palette, it's hard to know which colors are used and which not. If you create a multicolored logo bitmap you'll see it can very easily be screwed up. Personally I hate that black logo with a passion - the first time I ever saw XP boot I thought to myself "whadda heck, is this a funeral of some sort?"

Here's a detailed explanation of the bitmap header content - if you can find a legit location for the 10 bytes...

Error message position on screen and persistance would have to be Tihiy's call, if he ever decides to use the modified WLL in RP. As for blanking the screen, after displaying the message, the routine goes to faileddrawing:, where int10h is called again with 02h in ax so it forces the screen to go in text mode again - I believe this may be the reason. You may try to bypass those 2 instructions, see if the message stays on screen.

My test machine is an ancient Pentium I @ 166MHz (not even MMX) and it does have a floppy but no possibility to boot off USB (I dont' have an USB stick anyway). I'll start messing with it soon - maybe I'll just try installing soporific's UBCD, should be an interesting additional experience. As for XP: you wouldn't honestly think I'd ever allow that thing on any of my machines, would you?!



Regarding ini files... argh, they're a pain. Of course it would be possible, but we should try to minimize the file number, make everything as compact as possible.

Otherwise, anything can be read in from a text/ini file: from settings to translated/localized error messages (as I mentioned in a previous post). But imagine: if someone forgot to copy LOGO.SYS to their drive, wouldn't they also forget about the ini too?

Dunno, this should also be Tihiy's call, if an ini should be used or not.

Yes, your're right, BUT...
...the palette (starting at offset 36h) gives you LOTS of free bytes. Exactly 256. Every color in the palette is stored in 4 bytes:

1st: blue
2nd: green
3rd: red
4th: unused

So that's why your first byte of the image (visible area) is at offset 0436h (1078):

Header data area: 54bytes
Fixed space reserved for color palette: 256 (colors) * 4 bytes = 1024bytes

54 + 1024 = 1078! Offset count starts with 00h, so the first byte of the visible area is at 1078.

O.k. a free block of 5 bytes is easier to handle, but why not use bytes at 39h, 49h, 59h 69h and 79h (this order is easier to keep in mind instead of 39h, 3Dh, 41h, 45h and 49h)

I'm worry I cannot change the source to use these bytes, so I cannot test it.


I'll check this out.

Be blessed,

Holli

Edit: Yeah, I checked it out and you're right. Now the program exits whithout erasing the screen. To implement this was really not that hard... ...thanks!

Today I gave a spin to the new WLL.COM. Mostly, it works. But... the code as it is, is more like a proof of concept - it has no protection against insane values assigned to progressbar coordinates.
Moreover, the buffer is way too small (512 bytes) to fit an insanely large 'bullet' (progressbar).
Finally (or maybe not), badly chosen coordinates could place the bullet between video banks and there's no protection agains that either, nor any code to handle the situation correctly.

I will try to address these issues as well as I can.
The buffer, for one, can theoretically be enlarged to max. 65536 bytes (010000h). According to buffer size, there's a limited size that the bullet can take: progW*progH =< buffsize. For now, I'll limit progH to 102 (66h) to fit in a video bank and progW to 65536/102=642 (8202h) which is insane enough already. I will probably add an extra check so if the bullet position crosses the boundary between video banks, its height will be limited to fit in one of the banks. That's gonna be some nasty code and also useless if I manage to get the drawing routine to draw cross-banks. But that's just wishful thinking, for now.

One thing I might have nailed, accidentally, is the hang at startup. I'm not 100% sure of that because it happened to me only after I added in a call to a certain procedure, but for safety I protected the corrupt registry around both calls to the said procedure and hopefully this would fix the issue. Needs extensive testing though.

The current code won't be released until I put the protections in place, otherwise crashes might (and definitely would) happen, with wrong values. In the mean time I'd like to ask users of non-English Windows 95,98/SE and ME to attach here their IO.SYS and COMMAND.COM zipped, so I can analyze them for a related part of this project (if that's allowed, of course - don't wanna break the board rules). Don't forget to mention the language they're for.

@ holli: Sorry, I had the edit open already while you posted, didn't notice your post.
I already knew that, just got a bit confused by all those numbers.

Theoretically it would be possible, but practically we'd ask too much from logo creators. It's already too much to hexedit the bitmap and add subsequent values - scattering the locations around would just confuse the heck out of people.
Then, to read the values in and store them would be a little more tedious. Right now it's: open file, move offset pointer at 1078, read 5 words, store them in struct, close file. What you suggest would be: open file, move offset pointer to first byte offset, read byte in AL, move pointer to second byte offset, read byte in AH, store AX to first struct WORD, increase struct pointer by 2, repeat all this times five, close file. Ugh!
You're welcome! Now when I release the actuall WLL and you'll have the old LOGO.SYS in place (or even if you won't, there will be the one embedded in IO.SYS), you'll see the error message, then the animation in original logo will run as usual, then the text will show up again for a second or two before Windows kicks in. You won't like it. I know because I've tested this today.

I knew that, but I only wanna give some alternatives.


No, you're not right. RP7 replaces IO.SYS with a version that doesn't contain a logo file. If I used an old or none logo file, the error message appears correctly all the time until WIN.COM blankes the screen. That's what I want.


Hm... just an alternative: What's about a tool to store the animation information into the \LOGO.SYS? So you can check the parameters in this tool and you can keep the WLL.COM clean from it and the logo creator don't need to hexedit the bitmap. If possible, the logo creator can give this tool the logo name (a syntax like "logocfg <bitmapname>") and the tool stores it as \LOGO.SYS and backup an existing \LOGO.SYS as \LOGO.BAK (an old LOGO.BAK will be overwritten).
O.k. such a tool is a lot of work, but If you want an easy handling for the user - violá!

Stay blessed,

Holli

Uhm... sure... RP7... What if I don't install WLL with RP7? The tests I've performed were using self-patched IO.SYS and COMMAND.COM, withouth the call to the animated bitmap (or the embedded bitmap itself) removed.

The idea is to make WLL a bit more wide-range, usable on Win95/98/98SE/ME - all language versions. For this, I need to patch the existing IO.SYS and COMMAND.COM in place, instead of relying on already patched (and English-only) versions of them.

And the original animation wouldn't be that bad, in case the new LOGO.SYS is missing. The error message would pop up, the user would acknowledge it but the start process would still have an animation - the old one, but better than a blank screen, IMHO.

That's actually a very good idea! It would save the creators the task of converting decimal values to hex and then hunting for hex editors and patching the bitmap. I'll look into creating such tool, but first we need to agree on parameters location, as I'm still not convinced about the non-usage of every fourth byte in the palette.

For now I'm still working on protecting the code from insane values. Wasted a few hours because of a stubborn ROL instruction, that worked fine in the debugger but not at all in practice. Had to replace it with SHL. Argh!

Why wanna do the work twice? Please have a look into the uncompressed RP7 package. You'll find the folder "logo" in it. Open it and you'll see some subfolders like 1031 (english), 1033 (german), ... containing IO.SYS and COMMAND.COM for various languages.

Yes, but you don't see the error message or it disappears too fast for reading. If something wrong with the logo, it would be better none is displayed.

I'm happy about you like my idea. This tool don't have to be programmed in assembler. E.g. you an use C, C++, Turbo Pascal, Delphi or any other language you like. I'm worry about not being a programmer.
But please, give the unused bytes in the palette area a try...thanks for your work!


GOD bless,

Holli

Because there's no patched IO.SYS and COMMAND.COM for Win95, Win98Gold and WinME. I see no reason why those systems couldn't benefit from this animated logo.
It doesn't dissapear if it waits for a keypress.
I'm as much a programmer as you are. Maybe just a bit more stubborn.
Dunno any of the above-mentioned languages and to be honest, I'd never be able to learn any of them. I've been lurking around C programmers for a few years and I couldn't get anything of it into my head - ASM is just the reminiscent of my old playing with Z80 code.

Now, regarding the code at hand... I've added some protection but it's not 100% foulproof. Then, I realized the buffer cannot be bigger than 32768 bytes or corruption will occur. And finally, the cross-bank bullet is gonna be a pain in the arse - my brains are close to a shortcircuit already.

EDIT] Link removed. File is available for download further on in this thread.

That's a very good idea. I can give you german versions of IO.SYS and COMMAND.COM from Win95 rev. A and B, Win98SE and WinME, if it's allowed. Otherwise ask google.de for +"startdiskette" +"deutsch" +"download"

As I mentioned before: If I turn on the computer and go to get a coffee, I want the computer to be ready. I don't want to come back, press a key and wait five minutes until the computer completing the start up process. If I don't see an error message or a logo because I'm not in front of the pc, It doesn't matter...

Thanks for your new release, I'll test it tomorrow, because it's late...

Stay blessed,

Holli

Current logic is:
- if you bother to install WLL is because most of the times you're in front of the PC and want to see a nice logo
- if you don't see the logo you wanted and you don't get a comprehensive explanation for that, you'll get p***ed off and start posting around
- if you do get the explanation, most likely you'll fix the error and you'll never be bothered by the message again
- if you're not in front of the PC at boot time, you don't need WLL because you're not gonna see any logo anyway

Well, this apart, seems that the new code kinda borked WLL. While it works in SVGACOM, when applied to WLL makes it hang after the animation. I found that the hard way, when this morning my machine wouldn't boot anymore - backups to the rescue.

So now I got even more on my plate. I'll worry about minor details later.

But IF I sit in front of the PC I wanna see a beautiful logo... *lol*

O.k. let's stop some off topic here. One question: In QEMU emulation (Windows and Linux host) the logo always displayed corrupt. It doesn't matter if WLL or SVGACOM. I think, that's a problem of the emulator and connot be fixed. Am I right?

Be blessed,

Holli

You will, as soon as you fix the error by simply copying the correct LOGO.SYS to C:\. I'd do it for you, but I can't, so I just force you to do it yourself. See how stubborn I am?

I'm afraid I cannot test QEMU or any other kind of virtual machine here, because my most powerful machine is a 400MHz Pentium II that runs exclusively on Win98SE, while the other 2 are 166 and 200 MHz respectively, the former with Win95B and the latter with Win98SE (that was my primary machine until Nov 2006). However I believe that the display corruption could be QEMU's issue, since the code works fine on my 400 and 200 MHz machines.

The one with Win95 has a 2MB PCI CirrusLogic videocard and also displays a corrupt logo (all image is 'packed' into the first video bank) but I considered it a videocard issue, probably no/bad VESA implementation. I left this investigation for a later time.

Hm, QEMU emulates a Cirrus Logic (5440?) PCI video card. And yes, the logo was displayed only in the first video bank, too. So that could be the problem.

I believe so. My card's chipset is CL-GD5446-V.
You may contact me directly to send those files, if you want; I'm online now.

*lol* The Linux QEMU launcher told me it's an GD5446 PCI video card....what a cool emulater - it also emulates the hardware bugs.

Edit: QEMU can emulate an other video card without this bug!

OK, time for some more playin' around. I see a lot of interest in this project - 5 downloads, whoa! - and also lots of feedback... not. Oh well, nobody's gonna die from that. It's just that the last version of SVGACOM wasn't performing very well, at least not when patched into the actual WLL code. So I had to change a few things, mainly internal subroutine positioning and handling. It worked fine on my main machine and the 200MHz test one.

Still, I'm not gonna publish the WLL code for now as it lacks a few things and the final position of the parameters inside the bitmap has not been decided yet. However, I have created a first version of a bitmap logo patcher, using the current parameter positioning. So I give you the latest SVGACOM version and introducing LogoTool. They should work fine with each other, but please calculate progressbar position and size so it would not cross between video banks, otherwise the animation would appear corrupt. This is the protection I didn't yet manage to put in place and the main reason I'm holding back the WLL release.

[EDIT]
I have removed links to the respective version of SVGACOM. Please use the latest available further on in the thread.
LogoTool is included within the SVGACOM package.

compiler work, for most people it will be unusable - just because they dont know how to compile, or not willing to download any assembler.

1. standard wll does not work for me now. i dont know why.
2. svgacom does not work at all. i get some unreadable message and later "press a key to start windows".

I am not sure if i did things correctly. first of all i compiled svgacom, then i put it in c: with your logo. then i executed svgacom in dos mode, but i get no image - only the message. than i tried replace logo sys with your logo but still no effect and same err message

later i tried to replace wll by svgacom files but with same effect

That's why there's an already compiled SVGACOM.COM in the package: for people that can't/won't spend time compiling. The ASM file is there just for those who wouldn't trust a precompiled file.
That's what I need to find out and fix. You'll have to offer me details about your hardware and software environment you've been testing it with.
The message should be very clear, in English and read either File C:\LOGO.SYS is not present or File C:\LOGO.SYS size mismatch, followed by Press a key to start Windows... a few lines below.
(In the version posted below I have changed the error messages to reflect the real name of the required file for this testing version of the code)

That would be the standard message that should display with a WLL standard installation. However, in case of SVGACOM, the name of the file that it's looking for is not LOGO.SYS, but startup.bmp. I intentionally shipped the last 2 versions of SVGACOM with a renamed bitmap file, so a distracted user would get the error message at first run and attempt to fix the problem. My bad is that I forgot to mention the real name that the bitmap should bear.

If you got anything else but one of the above 2 messages, please describe what you saw and/or post a screenshot if possible.
OK, so first of all you can run SVGACOM in Windows too, there should be no problem. Then, as I mentioned above, the name of the test logo file should be startup.bmp. Just place SVGACOM.COM and startup.bmp together in the same folder and run SVGACOM.COM - the logo should be displayed. If it does, please tell me if you notice anything unusual in the animation shaft or at the bitmap itself. If there's any error, please describe as accurate as possible.
SVGACOM cannot replace WLL. It is intended solely as a test for the animation itself and does not contain the necessary routines to start up Windows, so replacing WLL with SVGACOM will only result in Windows being unable to boot.

One last consideration: LogoTool will ask to save the file as LOGO.SYS, for maximum convenience for when WLL.COM will be released. However, as mentioned above, the SVGACOM code requires the file to be named as startup.bmp, so please make sure you save your file as startup.bmp, for now. For the time being, do not overwrite your current LOGO.SYS in the C:\ folder with the one saved by LogoTool.

I hope the information above will be helpful. Thank you for testing, so far!

Here is the latest version of SVGACOM, with fixed error messages and improved readme. I have packed LogoTool together with it and also added a readme for it. Enjoy!

[EDIT] Link removed. File is available for download further on in this thread. [/EDIT]

the actual trouble with svgacom was that i didnt know that the file must be named startup.bmp, because in the pack i downloaded was startupOK.bmp.

also the error message was not written in english. it was an amount of random symbols with no sense to me.

right now i was able to execute svgacom with your bitmap (very ugly ).

with this i can test these things:
- when or where to execute svgacom while bootup

(wll had one error. in some versions of io and command it executed as last thing when dos boot was complete, so user has seen all the dos text underlying, in the italian version of these files i was able to see logo as first thing during boot and user was not bothered by the text)

- what about scandisk
- what about dos
- what about my graphics driver which has currently broken logo graphics during boot

edit:
a) when svgacom was executed standalone from autoexec it prevented execution of other programs in line.
when svgacom was execcuted as wll.com i had similar error as before. logo apeared but windows was not starting. this also occurs with normal wll... maybe the problem is in my windows but i dont know where search.

Please reread the edited post above. SVGACOM cannot be run instead of WLL, as it lacks the code that calls the startup of Windows. So Windows will never start with it, because it can't. SVGACOM is only part of WLL, intended for animation tests only. I only intend to post the whole WLL code when I would have rendered it as foulproof as possible. Got a working version here for personal use but it still has the same quirks that SVGACOM has.

Regarding the garbled error messages, there's not much info you offered me so I'm not sure where to start searching for faults. I'll investigate the issue though. One thing you could do is open SVGACOM.ASM, scroll to the end of file until you find the string definitions, and replace the text with something shorter and/or use some special characters (please don't remove the dollar sign ($) at the end of the string), compile the code and test it, both in DOS mode and under Windows (make sure the logo bitmap is not there, so you can actually get the error message). Tell me how it went.
Obviously, since the code contains a wait for a keypress to exit. WLL instead contains a timer that allows execution of other modules during the animation.

this is the error message when i execute svgacom without startup.bmp

http://www.slayershrine.wz.cz/wll.jpg

i cant help more in this phase - maybe later when the svgacom will be "bootable"...

Thank you for reporting! Issue fixed. Please download this version: SVGACOM with LogoTool

Changelog:
- added automatic string centering for 'Press a key to exit...'
- rearranged centering routine into a procedure
- removed superfluous file close

Please tell me if there's any more problems.

P.S: If you find my test bootscreen ugly, I'll be waiting to see one created by you. After all, that's why I put all this work into this code: to allow everyone unleash their creativity.

i like Tihyis black windows 98 bootlogo, but i want to replace XP window logo by embossed win9x logo if i found one suitable (with black frames )

edit:
i executed svgacom in windows mode. when startup.bmp was present i get very bad error - system was frozen. after reboot i get bsod about VWin32.vxd. at next reboot scanreg automatically restored backup and later system worked fine...

WLL updated <--??
Yeah, after 2 years of inactivity, i've updated it. If it will work okay with video cards it can work with, i'll include it into RP8. Otherwise, it dies.

- Fixed behavior when \logo.sys is not found or not appropriate;
- Improved timer hook to fix problems with reentrability, race conditons and unhooking.

This is strange, because I've tested it 1 minute ago under Windows98SE English, with 18% free System/GDI resources, SlimBrowser, Miranda IM, Metapad, XVI32 all running and it worked just fine, without a glitch. I'll perform some more testing tomorrow on the other machine.
Still you haven't offered any information on your hardware that could help diagnosing the issues.
Perfect timing... should I keep wasting my time on what I've developed so far so should I just scrap it?

[EDIT] Links removed. File is available for download further on in this thread. [/EDIT]

I'm very tired any probably not thinking very clear at the moment.

to Tihiy:
1. green stripes after initialization of graphic card are fixed. No stripes, but the screen remains black. its not bad while it does not bother so much. i dont know if possible but i would appreciate if the logo appear again - but this problem may be in my graphics driver.

2. I have fixed the problem when wll was not loading image and it dropped to dos instead of executing win. the problem is in "Buffers" parameter in config sys. as you know i was using value 99,8. with this value wll does not load

i changed the value to 33, but with it the system has frozen during winboot at usb hub device. i set it to 20 and system was able to boot.

without wll was system able to boot even with maximum value, now i had to slow down because it was causing trouble.

to drugwash:
tommorow i will look at your product

What do you want to say? It was working some time ago for you, but now is not? Was working with other version? Other DOS settings? Other logo? Does svgacom work? Old wll?

well.. wll, old or new is very unpredictable. i was unable to find any constant behaviour until today.

previously i had Ati Radeon9800. with it worked wll almost perfectly. some months ago i bought ati x850xt. very powerful chip indeed, but the driver has never been released as full version. it was only in beta phase...

this caused green stripes with original wll (from rp7) when system has initiated graphics driver on background during boot process. new wll does not have this bug.

the trouble when wll drops to dos is a mystery for me. previously i thought it was caused with BIOS settings, and maybe i was partially right... but now i have fixed the trouble just by lowering BUFFERS in config sys...

also the freezing during boot is quite obvious... i was creating a boot logo for velvet98... i put there incorrect color format (RGB instead of Indexed color). logo was black and white and the system has frozen. Only wrong bmp format of logo sys may cause freezing during booting...

until i dont find the constant behaviour for this program i cannot give full report

svgacom has more constant behaviour, but still testing...

Aha, got it now. In newest version, wll won't load non-256 color bitmaps, just FYI.
Looking forward for your logo! When/if you finish it, post full color version too, please!

256 color version has been just released wait a minute or two...

...

http://slayershrine.wz.cz/logo1.bmp

24bit color version.

also system has frozen again during reboot. logo was ok in this case - again system has frozen in same place when usb was initialising...

Would USB load ok if you don't use wll? Are you sure it is freezing on usb loading? Does animation stop when it happens?
Your logo is marvellous, however, i think progress bar should be changed to look more elegant for this logo. Or logo should be enlarged.

i did not found larger logo and upscaling is not the quality way... the image was too choppy then. Velvet maybe will change in near future - including the progress bar (dark red or silver maybe). I just want to have theme which is fully Win98 and looks as created for one system...

When Wll is not used the usb will load correctly, but... i bought the USB2.0/Firewire combo just two weeks ago. it worked without trouble. Since Immolator is still some kind of experiment i cant hardly say that the driver was not the reason of this...

In recent days i did some crash tests. First of them was keeping machine running without forced reboot. this worked. also i reinstalled some drivers - especially sound card to see if it affect stability. Also SVGACOM crash and fact that all values in my config sys are really mad

right now i am sure that Buffers=99,8 cause that wll will drop to dos without loading logo and later windows and maybe freezing is caused by wll. it happened only today when i sucessfully used wll on my system, and never before...

(logo updated a bit )

The animation routine still has its quirks, apparently. I've had a crash too in SVGACOM today, although I haven't changed anything in that routine since last time. Happened under Windows, on my main machine, after I had run certain applications. However, after a reboot, I started it again and it worked correctly.

Offler, I tested LogoTool on your bitmap - it's a jewel. And heck, I managed to fix the not-updating edit boxes.
So - while there's no major change in WLL code today (apart from fixing a missing registry restore)...

I present you WLL.COM with the improved LogoTool v1.0.1.0 (this package contains SVGACOM too).

Tihiy, I'm working on the WLL installer/uninstaller.

i have identified one trouble:
when i turn on the computer for the first time (turn on power button), system will surely freeze during bootup while using wll. after next reset (with reset button) it will boot correctly. Reason still unknown all i know that system will freeze at same line in bootlog:

[0009456D] Starting Hlavný rozbočovač USB (USB\ROOT_HUB\PCI&VEN_1106&DEV_3038&SUBSYS_30381106&REV_62&BUS_00&DEV_09&FUNC_01)

i try some bios settings to fix this. maybe related with irq, while this device use large amount of them.

fixed: i have set IRQ in BIOS for usb...

Offler, it would be useful if you could specify which WLL version you're testing and which are you having troubles with. Tihiy's version has a small buffer value (512 bytes) while mine takes 2048 (2kB) and also has extra code related to the animation routine. Any of those differences may lead to different behavior on certain machines.

On another note, I've had no feedback related to LogoTool: did anyone test it yet? Is it working correctly? Any bugs or feature requests?

Oh and to my shame , I've always forgot to mention that the LogoTool idea is entirely holli's so I think he should get the deserved credit for it. Thank you very much holli for the excellent idea! I hope you like LogoTool!
I'm still considering the palette storage for the coordinates, but I first wanted to have the animation routines and LogoTool established and working - changes can be made afterwards, if palette usage is proven harmless.

for now i have only tested tihiys version, and base version from RP pack, because i had even trouble to get wll work correctly. now i have to re-read whole topic here because i miss some info (i forget it) how to get work svgacom along with wll.

It would help if you downloaded my pack above and read the readme files carefully.

It is explained - and I said that through this thread too - that SVGACOM.COM is just the animation part of WLL.COM and is intended solely for the purpose of testing the animation routine that I have slightly modified regarding progressbar coordinates' source.

SVGACOM.COM can be run in Windows mode or in DOS mode, manually, but it will not do anything else but display the animated logo. On a keypress, it will exit. That's all.
When testing it under Windows, please do so right after a fresh reboot, as in some rare cases it may corrupt the video memory, after some other applications have run - I couldn't find a pattern here, as it only happened to me twice in all the tests I've performed.

In my package there is also a fully working WLL.COM, based on my version of SVGACOM.COM, with Tihiy's latest timer changes added in. I have this version installed on my main machine.

Also there is LogoTool, a neat little application written in AutoHotkey (the AH script is included, of course), that allows one to quickly patch their bitmaps with the progressbar coordinates, to make it work with my version of SVGACOM/WLL.

They all need testing, otherwise I'm working in vain here.

[EDIT] While working on the installer, I noticed a weird instability in the FindWin procedure. I copied it entirely from WLL only with minor changes to a couple of labels. While testing under Windows, it would randomly fail. As the respective code is not implemented yet, I put text display instead of the install and uninstall routines and while running the very same compiled code a few times in a row, I would sometimes get 'Uninstall succesful' and sometimes 'Couldn't find the Windows folder'. I wonder how could the very same file yield different results when run a few subsequent times in the same environment? Could this be the reason for the random hangs at startup with WLL?