Fixes & enhancements for WLL.COM

[holli]

I wouldn't mess with the palette

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.

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.

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!

Edited March 5, 2008 by holli

[Drugwash]

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.

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.

I already knew that, just got a bit confused by all those numbers.

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)

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!

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!

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. Edited March 5, 2008 by Drugwash

[holli]

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!

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

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.

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.

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.

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

[Drugwash]

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.

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.

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.

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!

Edited March 6, 2008 by Drugwash

[holli]

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.

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.

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.

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.

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.

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

[Drugwash]

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.

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.

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.

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.

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.

It doesn't dissapear if it waits for a keypress.

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.

I'm happy about you like my idea. This tool don't have to be programmed in assembler. E.g. you can 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!

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.

Edited March 9, 2008 by Drugwash

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

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"

It doesn't dissapear if it waits for a keypress.

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

[Drugwash]

If I don't see an error message or a logo because I'm not in front of the pc, It doesn't matter...

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.

[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

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

[Drugwash]

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

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.

[holli]

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.

[Drugwash]

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.

[holli]

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!

Edited March 7, 2008 by holli

[Drugwash]

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.

Edited March 9, 2008 by Drugwash

[Offler]

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