|
|
RECENT UPDATE:
|
|
|
|
11/12/2002 Tuesday
Once in a long while web page update...
Ummm, the time flies too fast indeed.
It's been almost a year passed since last time I updated this page...
Many things have came in and will come in, but I refrain to reveal those things just yet.
Anyway, you can see above the result of the 1st poll.
No doubt that the people want Java compatibility.
Well, I thought, okay let's be more specific.
In terms of which feature, do you like Waba VM to be compatible with Java ?
By the way, thanks for your vote on the last one.
The old poll will keep going just for fun :-)
Anyway, here's the new update.
1. Double / Long doesn't work.
Now I'm finding out that Double / Long in this version of VM just doesn't work.
All I can say is that I'll try to fix it, without any gurantee. So two word: Help Me !
2. Where's the new WinCE port ?
Due to the double-buffering problem, I couldn't release it.
If you don't mind about flashy screen, it's working, and even I can put it up here.
Give me an email if you'd like one.
3. A small Waba VM Developer tool.
I made a small Java application to generate the hash code for native methods.
Have fun.
4. Olivier pointed out to me that my thread stuff crashes VM
when a thread object exits a loop and GC kicks in.
I think I've got a solution now, but too lazy to run a compiler.
As long as you don't let threads quit, then everything is fine.
5. Cyrilic display is working on WinCE.
I've confirmed this a year ago, he he he :-)
Stay tuned, I mean it...
|
|
|
|
12/19/2001 Wednesday
Alright. Here I am again.
Many things happened since the last update of this site.
I wish I could spend all of my time doing Waba stuff,
but the reality sets in, I just can't spend enough time doing this.
(Maybe I shouldn't have bought that "Operation Flashpoint" thing... ;-))
I know many people don't care about what I post here anymore,
but I'll keep enhancing Waba for another couple of years.
After that, I don't know.
The people in SmartData Corp. have been taking care of Waba stuff really good,
that they're shipping Waba with their product.
All of my wishes and hopes will go toward their prosperity.
Check them out here: www.smartdata.ch
If any of you need the source files, I'd rather direct you to Waba CVS,
and download them from there. Here's the link.
Anyway, here's the new update.
This time my update only applies to Win32, WinCE platforms.
(Oops, I've been forgetting to install eVC++. I'll post the binaries for WinCE soon.)
I'll port them back as much as I can to PalmOS when I have some time.
1. Native thread support.
So far, my VM has been just simulating multithreading.
But now, it executes threads pre-emptively (means truely multi-task).
Thanks to Monaka-san, some enhancements have been made,
so that "Control" class is no longer extended from waba.sys.Thread.
"Runnable" interface is implemented,
so now we can do multi-threding close to that of Java.
Any "doumo-arigato" letter to him would be appreciated.
I've coded ".signal() = .notify()" & ".signalAll() = .notifyAll()",
but I haven't tested at all (neither sync block and synch methods).
The name change is due to the fact that I just don't know how to override them
without getting some compiler errors. Doh!
Any report is aprreciated.
Try running "TurnBaby" example program, and see what happens.
Clock image is courtesy of Michael Stromberg.
2. Internationalization.
I changed around how Waba had been handling Unicode, and corrected a bit.
Now as far as I can see on my WinNT 4 Japanese,
it's displaying ISO-8851, Kanji characters.
(Cyrilic has been tested and displayed on my iPaq. But the WabaVM posted above doesn't have this feature yet.)
As long as the correct font is selected to be able to display the intended
character sets, it displays fine (I hope this will be the case for
other character sets that I can't test).
Tricky part is that, if your OS doesn't support Unicode natively,
you can't display different code-page character set at the same time (make sense though).
Try "LangTest" example program for both the result, and how to specify characters.
3. Double-Buffering.
Long time ago, I saw somebody posted on Waba newsgroup about the flashing of scroll GUI.
After I made my own scroll GUI, I got to know what he was really talking about (and his frustration).
I've tried so many things and after a couple of months passed,
finally came to a conclusion that I must do the double-buffering inside of VM.
So here it comes, now I've got a smooth ScrollPanel (and a ToolBar).
Also I'm planning to extend this ScrollPanel to PopMenu, TableBox, etc. for more GUI stuff.
Basically, with this update, the VM copies back what's drawn on the off-screen buffer,
when it receives window update event, mouse/pen event, timer event, and key event.
Also, you can call the static method "MainWindow.paint()" to force the screen update.
Try "Scroll" example program for fun.
The small buttons on the 4 corners toggle "free scroll" mode.
In this mode, all the controls inside of the scroll panel are freezed,
and by dragging your mouse/stylus, you can pan around the content.
The long buttons on the 4 sides scroll the content in a predetermined increment.
I designed it like this, so that I can save some space on the tiny PDA screen and for the ease of use.
4. Double / Long stuff.
Thanks to Guilherme C. Hazan for his contribution to waba.sourceforge.net.
This update incorporates his 64Bit stuff, that it handles Double and Long types.
I haven't used the feature yet, but I think there shouldn't be any problem.
5. Waba-Specification Mailing List.
Quite many things are being discussed in this mailing list,
and some of the people are doing pretty good job.
The improvement of Waba will come in (slow but) steady, as I can see.
If you have any good idea, you're welcome to join and discuss related topics.
Check out the archive.
6. Last note...
Thanks to Olivier Bornet from SmatData and Rick Wild for thier help & support.
Ciao.
|
|
|
|
02/01/2001 Thursday
All right. I'm back and alive.
It's been almost a year passed since the first time I put up this page.
I'm quite surprised that after I set up the first Waba CVS account,
many people started to contribute to Waba enhancements and ports.
I really hope someday soon, this neat little VM takes off big time.
However, like some people have mentioned on Waba newsgroup,
that there has to be some coordination toward modifications, don't you think?
We don't really want to take the same fate that Linux took.
So, as a result of possibly the most logical resolution,
I will merge my modification into that of SmartData Corp.'s Waba codes from now on.
It seems like this is the closest I can come close to the "official" version for the time being.
I still post my code here too though.
***
Okay, on to my update.
1. PalmOS Color & Grayscale Fix.
Black & White, 4 Level Grayscale color reversing bug is finally fixed.
Grayscale image display is now more accurate than before (I think).
Also, I think it can handle Handspring Prism 16Bit color too.
Please try it and let me know the results.
Thanks to Kurt Hein, I've figured out about how to implement the following feature.
I added special feature to accommodate odd combination of ROM image and Palm device,
like you get strange image displayed, when a PalmVx unit has Version 3.5 ROM installed.
If this is the case, just tap on the Waba icon first.
Now, you'll see there are two tabs showing "About" and "PalmOS", if you are running on PalmOS.
Tap on "PalmOS" tab, and you'll see manual setting for the screen color depth.
You can force the setting of your screen to let WabaVM know the correct setting.
The default is set to "Automatic", where WabaVM tries to guess (well, it's really my guess anyway...)
the best setting for your Palm unit.
*** Prepare yourself that you'll be warned. ***
You can select a setting from "Automatic", "Black & White", "4 Level Gray",
"16 Level Gray", "256 Color", "65535 Color".
But any incorrect setting may damage your Palm unit severely.
Although most of the time, your Plam unit just crashes or freezes,
and you have to delete and re-install WabaVM again.
*** Okay, you have been warned. ***
Also, "Edit" class is fixed completely (I hope).
I have tested these fixes on my Palm Emulator Ver. 3.08a.
2.Rejoyce. Multi-Threadding is implemented (for PalmOS, WinCE, Win32).
This one of the reason I have disappeared for such a long time.
Other reasons:
It took so long for me to recover my energy I've lost for my last mod.
Carried away with overclocking my CII 566 to 952MHz,
and spent too much time trying to break 995MHz barrier.
Excited too much about my DVD-ROM, and watched over 10 movies.
I've got lazy over the holiday season.
I'm taking classes at local college.
You name it.
Anyway, you can use this feature by inheriting from waba.sys.Thread class.
It works pretty much like Java's Thread class:
Step 1: Write your own class which extends from waba.sys.Thread.
(You have to write out as "waba.sys.Thread",
so that Java compiler doesn't get confused with java.lang.Thread)
Step 2: Override ".run()" method, just like Java.
Step 3: Let it start by calling ".start()", just like Java.
Step 4: But unlike Java from 1.1 to 1.3, you have to ".stop()" it,
just like Java 1.0. :->
Points to be mentioned:
This is a "GREEN" thread implementation.
The value to be specified in ".sleep(int sleepCount)" method is NOT based on mill-seconds,
but rather specifies how many times a thread yields its turn to other threads.
i.e. when you set sleep counts to two different threads as threadA.sleep(1) and threadB.sleep(5),
Thread B gives up 5 turns to Thread A.
The implementation became like this, since there is no high-resolution timer for the given platforms
(PalmOS, Win32, WinCE).
For your convenience (or mine!?), "Control" class is now extended from waba.sys.Thread.
Why? Because I often designate a "Container" object to one functional unit within my application.
If you look at "TurnBaby" example, each container is treated as separate thread unit.
Advantages are:
Even runs on platforms which doesn't support native multi-threading.
Cranks out maximum performance out of your machine ("TurnBaby" example screams on my iPaq).
Disadvantages are:
It blocks everything if ".run()" method calls other time-consuming methods.
i.e. serial and socket communication.
The main thread scheduler (sounds very fancy, but it's very simple)
is always running, even there's no thread is running.
So, it might eat your battery power some more.
Combination of advantages and disadvantages:
Since it blocks everything else, you don't have to do any resource protection.
If I implement native multi-threading, say, on WinCE,
context switch becomes much slower (100ms per thread).
I'll try to implement native thread (someday).
So, I advise you to evaluate these pros and cons to suit your needs (just like Java...)
3. A bit of class enhancements...
Sorry to say, you have to read the comments on top of each class source file for their usage...
"Button" class can display images, and can stay down for toggling.
"ToolBar" class has been added.
"ScrollPane" class has been added, but for some reason, it's broken for the time being.
It has been working before. Only problem with this control is "too flashy".
I don't really know why that is. Could someone help me on this?
What? Duplication of work? It happens quite a lot in this world.
4. Some notes...
ColorWaba was the "DE FACTO" name for my first modification,
but I didn't really name it in the first place.
I have been trying to refer as "modification", but the name has been stuck.
The look and feel of the GUIs are exactly the same as the original Waba.
I didn't do anything on this. It just shows up like this when "Vm.isColor()" returns true.
Oh, by the way, I don't know why iPaq doesn't display some of images.
I've heard there are some bugs on their Win32 API calls on ROM.
Let me know if new ROM update for iPaq would fix this.
5. Last note...
Thanks again to Rick Wild for his help & support.
As you know, he's the man! Give him a raise!
A tout a l'heure!
|
|
|
|
09/07/2000 Thursday
Well, I'm back briefly to answer some of your question.
I have received several responses that I think I'd better mention here.
1. About black & white reversing.
This was intentional, because when I was testing with my color image,
it seemed like the black & white was reversed. So, I reversed the original setting
and now the people started to say that it is reversed. Confused yet?
But unfortunately, I have updated my PC to Overclocked CII 850MHz & Win 2000,
and I haven't installed any of my development environment yet! Ha ha ha...
2. Uninclusion of source code.
Well, my plan was (when I released my code on my web page) that
if I sent my source-code to Rick Wild, he could merge my modification
the way he (the creator of Waba) sees best fit, and make it official.
Unfortunately, since then he's got so busy with his work,
that he can't do anything else.
Also, I was afraid that there will be so many version of WabaVM,
like UltraWaba, ExtremeWaba... you name it.
3. Waba CVS on sorceforge.net
I have set up a CVS account for WabaVM in sourceforge.net,
but there are so many things to learn to use it, so I need more time.
If anyone is interested in maintaining the source code, please let me know.
4. My restriction to Waba newsgroup.
I can't post any message by using my company's web access.
There's no newsgroup server in this company.
5. Again, the oddities of Grayscales...
Right now, ColorWaba is determining how many color depth your Palm has,
just by checking your OS version.
Below 3.0 = 1 bit.
Between 3.0 & 3.3 = 2 bit.
3.3 = 4 bit.
3.5 and up = 8 bit.
Well, it turns out to be that this is not a good way to determine the color depth.
I've looked at some of other open-source Palm application (thanks for who has let me know about it),
and it seems that using the CPU type information (non-EZ, EZ...) is the better way to handle it.
But then, I'm not sure when the improvement will take place. He he he...
6. My departure from PalmOS...
Don't be surprised, but I sold my Palm Vx and now I've got my (precious) iPaq.
So my focus is geared towards more generic feature improvement on WabaVM itself right now.
Does anyone know where to get StrongARM assembly code manuals?
Hasta la vista, baby.
|
|
|
|
06/15/2000 Thursday
Sorry, folks!
If you thought I was dead, you were right!
I have been dead for a long time, due to the heat wave I've experienced last couple of weeks.
But I have resurrected like a zombie, and top of that, I have fixed 2bit grayscale problem!
I have tested it with 3.1 ROM image with my ColorImage example, so it should be fine.
The 2bit grayscale mapping of the color index is as below:
192 to 255 ---> White
128 to 191 ---> Light Gray
64 t0 127 ---> Dark Gray
0 to 63 ---> Black
If there is better way of mapping it, please let me know.
**********
Thanks very much for the responses that I've received from many people.
Now, one of you will be please to see my spelling miss corrected on the start-up screen.
But most of the other people will be please to see 2bit image working for sure!
Also, I've found out through people's responses, I've been forgetting to include
some of modified .class files in the .zip file. Without them, it's very tedious to even
compile .java files. Mea culpa, mea maxima culpa...
Please read the new installation instruction below.
**********
Well, I'll be quite busy for a while for many things going on around me.
Many people's responses from all around the world were what kept me going.
Many thanks to you guys and gals, let's make Waba VM a serious contender for PDA world!!!
Next step: "Edit" class fix in grayscale! Hahahahahahahaha!
|
|
|
|
05/16/2000 Tuesday
Sorry, folks!
I didn't update to the latest .zip file last time.
I just realized today!!! Please don't throw anything at me!
Yet another dreadful trickle release!!!
4bit (16 Color) COLOR COMPRESSED file support is done!
Next step: Yet another dreadful "Edit" class fix in grayscale!
Aaarrrggghhh!!!
|
|
|
|
05/14/2000 Sunday
Heads up, folks!!!
As I have promised, "Image" class now handles 8Bit (256 Color) COMPRESSED BMP files & 4bit (16 Color) COLOR UNCOMPRESSED files!
And for some reason, compressed .bmp files loads faster than the uncompressed ones.
My goal for this implementation of bitmap files for "Image" class is to make it flexible.
Either you can save a little bit of memory, or you can be loose about which type of bitmap files to load.
I didn't use PlamOS 3.5's bitmap APIs, so it is compatible with grayscale Palms
(truly native "compressed" bitmap API is supported only with 3.5 OS).
What? What about the other grayscale fixes?
Ah, I fixed "Radio" & "Button" & "Check" classes, but broke "Edit" class again.
That's because I didn't know how Palm handles Grayscale palette setting. D'oh!
Next step: 4bit color for compressed files to put an end to the "Image" class!
Also, please give me some responses.
I see over 1400 people (including the regular visitors I'm sure),
but I only received several emails from couple of people.
Well, I guess that means everything is going all right then.
P.S. Are there any people from Romania visiting this site?
If so, please write me a email. I'd like to learn / practice some Romainian.
|
|
|
|
05/05/2000 Friday
Sorry for the lack of update recently, because so many things happened and happening.
One is that I'm busy preparing for my choral concert and job hunting.
Even though so many people visited this page and supposedly read my plea below,
nobody responded anything except our hero Rick. (sob) ;-(
Second, since I've got a good deal on K6-2 550 at $71 US(he he he),
I replaced with my good-old P166MMX and oh boy,
it BLEW AWAY my hard disk partitions pretty hard.
Fortunately, I managed to recover all the data (sigh of relief),
but I had to sacrifice my aged Win95(I don't much care, because it's pre A version) partition.
C'est la vie, non?
Third, I redesigned this page's layout for your viewing pleasure.
I didn't use any authorizing tools, but a simple (programmer's) editor, so it took a while.
Before I started to get busy, I was looking at how to implement GIF image,
but sorry for many people who may be coding their web browsers,
that I have decided not to do it because of the LWZ patent issue.
I know there is patent-free LWZ decoding for GIF,
but it can't handle all the GIF formats.
So instead, I'm now looking into COMPRESSED BMP format!
For grayscale folks out there, I'm still working on those UIs, so please be patient...
I may be able to make better 2bit grayscale implementation, but I'm not sure yet.
One tip I have for 2bit image is that you can increase the contrast on it to improve
the image quality. I'll explain it the details later on...
|
|
|
|
04/22/2000 Saturday
I added ".useImagePalette(boolean enable)" which allows you to speed up things a bit,
by choosing whether you just use the system default palette or not.
Because of this change, I had to add 2 new constructors to "Image" class, they are...
"Image(String path, boolean enable)"
"Image(int width, int height, boolean enable)"
As I promised, I boosted the performance of "Image" class.
Guessing it irresponsibly, now it's 5 to 10% faster overall.
I list the order of performance as follows:
Fastest:
1-bit B&W image.
8-bit 256 color image displayed by using ".setPixel()" with system palette.
8-bit 256 color image displayed by using ".setPixel()" with own palette.
4-bit 16 grayscale image displayed by using ".setPixel()" with system palette.
4-bit 16 grayscale image displayed by using ".setPixel()" with own palette.
8-bit 256 color image uses system palette.
8-bit 256 color image uses own palette.
Slowest:
Why 8-bit 256 color image is faster than 4-bit grayscale?
Well, it is one of the great wonders of the world ;->
Again, I've found out grayscale UI color and some other things don't look good (yet).
So that's my next step.
|
|
|
|
04/19/2000 Wednesday
Now that I modified "Edit" & "Window" foundation classes, they work quite good.
UIs background color is same that of "Window"'s default (R:200, G:200, B:200).
Under PalmOS 3.3, highlighting is strange, but please get used to it. :-P
I'm updating the screenshot for this soon.
".setForeColor(int r, int g, int b)" & ".setBackColor(int r, int, g int b)" methods are added
to "Graphics" class to accommodate PalmOS color quirks. It was not as simple as WinCE.
Is anyone out there powerful enough to convince Palm, Inc. to make color handling similar to that of CE?
Because of this quirkiness, "Edit" & "Window" class wasn't really working.
I'm going to add a method like ".useImagePalette(Boolean on)",
so you can choose whether you don't want to change the system default palette or not.
This is necessary for optimization if you matched your images' palette that of the system's palette.
Yamakawa Mike-san from Sweden was quite right about his suggestion!
So I'm tinkering around with this "Image" class for a while.
|
|
|
