I can see bitmaps and text on my LifeDrive (SVN 0.54a)

Its as slow as hell because I am using a pixel by pixel blit using the WinPaintPixel PalmOS function. I just need to find a reliable way to blit to the screen and it should be much faster. Also when I exit it still crashes but I am sure I will find the solution to the crash very soon. Also note because I don't have a blitter, there is no transparency on the Palm version. Once I use a blitter, I will have no transparency issues.

Mounting VFS Folders (SVN 0.53)

Mounting VFS Folders works but what is even more cool is that the drives appear like windows drives so for example: I did not have to change a single path in my test file to test VFS browsing on the simulator. So for example C:\xec\ works also on the handheld using the first VFS slot (most devices have a single VFS slot) and mapping it to the C drive. This makes it easy for me to transition between the two platforms (Windows & PalmOS).

So what's next? First I need to make sure that read/write VFS files works on the handheld and then I need to figure out how I will blit the bitmaps to the offscreen buffer.

I have alot more work. The next biggest problem I can see on the horizon is dealing with launching Screens apps. Both for the launching and making it easy for them to call back into the kernel. I hope I can find a solution that is easy not only to write but to compile.

Another issue, I am having problems with the offscreen buffer which is some of the simulators is treating my bitmaps as low density. I spent a few good hours trying different calls but with no avail. I have decided to focus on improving the platform independent code and then returning to focus on the platform dependent code. This means that my current target device will be the LifeDrive.

UIList added (SVN 0.52a)

I just uploaded the new UIList component which deals with a collection of items and deals with scrolling them in a unique way. Here is a demo of what it can do with simple strings:

If you noticed at the end of the video, I run the same demo on my LifeDrive and it works (apart from the lack of font & bitmaps). I was so sure the speed was going to be terrible but I guess its not that bad after all (remember that I am using standard Palm draw functions, no special ARM blitter).

I will create a mini app to browse the objects in the system, so that I can debug the VFS stuff directly on my LifeDrive.

Moving along (SVN 0.51)

I doubt I will actually be at 'release' for 1.0 but it will probably be for demo release. I still have alot to do, but I am very happy with the progress and how the code is very streamlined. Note that if you want to take a chance you can find the Safire.prc file here:

http://screensos.svn.sourceforge.net/viewvc/screensos/Safire/garnet/make/

Note that its only been tested on the simulator and NOT on my LifeDrive yet. So please take care, since I not only have no warranty but I don't know if it will even work.

VFS Component Coded (SVN 0.50)

I have finished writing the FSDisk implementation for PalmOS using the VFS API. It took much shorter time then I thought it would. I used most of the FSDisk Win32 implementation. I now need to test & debug it and fix its bugs using the PalmOS Simulator.

I am a little PalmOS rusty (SVN 0.49a)

Here is a video showing the PalmOS version running on the simulator side by side with the windows version:

I have not coded for PalmOS for some years and I need to re-learn alot of the basics. Its very frustrating returning to the limited platform but its a great exercise.

I am getting there, but its taking forever. I am trying as hard as I can. About compatibility, I am currently targeting the simulator which is PalmOS 5 but if PalmOS 4 devices are still around when I get to release Screens, I don't see a problem being PalmOS 4 aware.

From the video you can see I still have a long way to do to get both versions identical. I am missing two major pieces which is the VFS component and the drawing of bitmaps. The first is harder than the second. The performance on the simulator is not that bad, hopefully it wont differ too much on an actual device. It also has a crash when releasing the objects, got to see what the issue is.

I do know that once I tackle these issues once I can more or less forget about them. This is the important part of the platform independency is that I don't have to interact with the platform API all the time.

I don't know if Screens will ever be released, but at least I am trying.

I have a PRC File (SVN 0.46)

I don't believe it! I have a PRC file that is compiled from the latest source code! I found a solution for the errors I was getting in PRC-Tools by using one of the latest cygwin1.dll files which seems to suddenly remove all my previous 'cygwin alloc' problems on vista.

I had to do alot of pluming for Screens to compile for PalmOS because of multi-segments. So I devised a platform independent way of dealing with multi-segments by having a PACKAGE name. So all functions in each component define their package. So all the UI functions have the PACKAGE(UI) at the end of their definition.

I do plan to make a readme file when I can actually get the code running. Yep, I still have to debug the code and make sure it actually runs. Once it runs, I will attach the prc file so you can all check it out on your devices.

Note that I still have the Disk component to write to interface with the PalmOS VFS stuff but that is not important at the moment. What I will be focusing on now is getting the demo running on the Simulator (and then having fun with it on my LifeDrive).

Screens is really getting there!

Thank you so much for all your help!

Moving along (SVN 0.43)

Screens is moving along slowly but so far, so good. I did some more bug fixes and added the check box component (which was mostly the button code). The video gives a demo of the check boxes.

I still don't know how I will finish the PalmOS port since I have no way to debug or even completely compile (I can do partial compiles) Screens for PalmOS since its not supported on Vista which is a shame. If someone else wants to finish the porting for PalmOS please help since I don't have the resources at the moment to do so. If you do want to port it and have questions, please send them to me at zhamilton1@yahoo.co.uk

I wonder what I should do next...

Trying to draw (SVN 0.41)

I have written most of the drawing code (still have the blitting function to implement) however while it compiles, I am sure it won't run and will need alot of debugging to get it working but I do know that the structure is mostly there. I did alot of copying from a previous project I had worked on a few years ago so I still have alot of work to comment the display code.

At least I know that the bulk of the code is platform independent and has been checked, so once I get something drawn on-screen I know I will be seeing the exact same thing you saw in the alpha demo app that ran on windows.

I am actually very happy that the code is becoming mature but I am still worried about how the performance will be on PalmOS. Hopefully it wont be too bad.

I still have the FSDisk component to port which maps to the VFS functions which I have never used before which will probably take me some time to port.

I will try and continue improving platform independent code at the same time so that I don't get stuck too long in the PalmOS port. I still have alot yet to write.

More PalmOS Code (SVN 0.40)

I have uploaded some more PalmOS components that although they have not been tested or compiled will provide me with the code to use when I can get an environment to compile in. I still have two files left to code for PalmOS to get the current platform dependent code written which is the FSDisk component which will be mapped to VFS PalmOS API functions and the UIDisplay component which maps to mostly Form and Window PalmOS API functions.

I am really worried about the performance factor when I run the test app on my LifeDrive device. If the performance is really bad, I hope that some little optimizations will help because I really don't want to have to re-write Screens for the 30+ time.

I looked back at the 1src posts I did between 2002-2004. I am so sorry that I did not live up to my own expectations. I really did think each time that I was going to release something and every time I failed. I am working very hard that this wont happen again. But if you look at my history, I am normally wrong. Forgive me.

Alpha Video (SVN 0.39)

Just uploaded SVN 0.39 which includes multi-line text and some minor changes to the threading component.

I am amazed at the progress so far and hope that it will continue.

I have decided to show you all what Screens Environment test app currently looks like. Note that this is just to test its capabilities and not how Screens will finally look in any way at all. Here is the video:

I don't know what component I will be working on next but I am very excited about the current state of Screens. This is the most featured version of Screens yet in the last 5 years! I feel that my design is rock solid so far and hope it stays that way. I am a little concerned at how I will port to PalmOS without a good environment to compile and test.

Thread Tweaks (SVN 0.38)

I did some work the thread component to make it more self manageable. It allows to use it by just creating threads using CoreThreadNew and calling CoreThreadProcess which returns when every thread has finished. I also added support for a parameter to be passed to the thread function. I think this is one of the easiest API's for using threads.

#include "CoreThread.h"

void main() {

CoreThreadNew(thread1, NULL);

CoreThreadNew(thread2, NULL);

CoreThreadProcess();

}

I hope the implementation will be compatible with PalmOS when I port the thread component.

Cooperative threading works (SVN 0.37)

It works even in release mode! It uses a simple setjmp/longjmp implementation which I will try to make even smaller. It uses stack copying and hope to make it with enough comments for future help to developers. It took me quite a while to get it working and there was not much information on how to use setjmp/longjmp in this design.

Note that the only dependencies of the CoreThread component will be the CoreMemory component which has no dependencies itself so you can always just use the thread code in your project since its public domain.

I would like to thank the users that have been testing the versions of Screens including those that helped me with the fonts. It really helps me the support, every word counts.

Nearly cooperative (SVN 0.36)

I have been trying for the last few days to try and get some basic multi-threading done however while it compiles and works wonderfully in debug mode, it is not saving/restoring the stack correctly in release mode. I am trying to figure out the differences between debug/release mode and while I turned off optimizations, it still happens.

I hope I will find a solution. I am using setjmp/longjmp which is known to not work in all situations. If you want you can try and diagnose it for me at my SVN repository: http://screensos.svn.sourceforge.net/viewvc/screensos/

If I get it working it will be really nice. Because its cooperative, its much easier to manage and will allow me to port it with more ease.

Note that I do stack copying which while its not exactly known for its performance, it has a higher rate of compatibility with function calls.

Wish me luck!

PalmOS Font Displayed (SVN 0.34)

I have converted the PalmOS High-Res Font to work on Screens. Its just a bitmap and an XML file that Screens uses to draw text very easily. You can easily understand the XML file where it specifies the character code, offset and width of the character in the bitmap file. Its uploaded to SVN.

I am amazed at the development this month. You can tell just by looking at the number of posts this month. I hope that this continues and that Screens will continue to evolve.

Text Alignment (SVN 0.31)

I have added text alignment and text in buttons so now I can display centered text in buttons which works very nicely. Screens is starting to get functional which is very nice.

I do need a better font though but meanwhile I think I will take the PalmOS font and convert it to my XML/Bitmap hybrid font format so it will work with Screens. Note that I use ASCII format and not Unicode at the moment.

I will start adding version numbers in the post titles to keep track of the changes in SVN in the blog.

I can draw text!

Finally... the moment has arrived... I can draw text on-screen using a custom made font (just took a snapshot of some capital letters and threw them into a bitmap and then described them in the XML file)

The format of the XML is very simple and the bitmap is just a 256 color bitmap where the palette is ignored and the index is the transparency from 0-255. If someone wants to create a better looking font, I am very interested.

The XML attributes are as follows: (the tag name is entry)

char - the character index in decimal (32 = space)

offset - the left position in the bitmap where the character starts

width - the size in pixels of the character

I am very happy I have got to this moment, since now have enough visual features to display something useful. This is a very important milestone for Screens.

Nearly can see text

I am very close to finishing the basic drawing of text on-screen. I have uploaded the changes already. Although I currently draw the entire font bitmap, I do draw it with a specific color. What I need to do now is mount the XML file and build an array of the characters offsets and widths so I can draw text elements easily.

Note that all this code including the zip and XML code is platform independent and therefore will help the PalmOS code base as well.

Things moving along

I am still getting problems with compiling for PalmOS on Vista using PRC-Tools. It works sometimes and then other times fails completely.

So I am jumping between advancing the feature set of Screens and porting to PalmOS. I am a step forward in the font engine dealing with the bitmap side since the XML side is more or less complete.

I hope I can find a more reliable compiling experience so that I can port to PalmOS faster.

Starting to Port to PalmOS

I have decided to port to PalmOS before dealing with the text & font component so that I can know the code performance.

It took me a long time to get to compile anything on vista with the PalmOS Developer Suite. Luckily I found the following article to help me compile on vista: http://charlesmcp.blog.com/1552399/

However I am still having the following error:

C:\PalmOSCygwin\bin\m68k-palmos-gcc.exe (8776): *** couldn't allocate cygwin heap, Win32 error 0, base 0xA40000, top 0xA4A000, reserve_size 40960, allocsize 40960, page_const 4096

Any ideas?

Bug Fixes

I am constantly trying different stuff to find bugs and fix them. You can see from my SVN activity that I am very active on Screens.

I just dealt with little/big endian issues and now I can easily read and write data in its little or big endian format without much work. This is crucial since PalmOS is big endian while Windows is little endian. The zip & bitmap format is little endian so on windows it does not conversion while on PalmOS it will swap all the variables it reads from the formats.

Luckily I had taken into account alignment so I had the macros for reading formats already, so I just had to make a slight modification to them for it to handle endianity issues.

I did find a potential problem that could cause problems with this Screens code base which is performance on PalmOS. Hopefully it wont be too bad or not bad enough that it cant be fixed. Currently I do notice a performance bottleneck when loading bitmaps which I will try to improve as time goes on.

Abstraction does have a performance price.

Uncompressed ZIP Component works

OK, I have decided to postpone zip compression to a later release since its not needed at this time for the font component. Screens can handle uncompressed zip files and mount XML files and draw bitmaps directly from within an uncompressed zip file.

This functionality is exactly what I needed for my font format which is an uncompressed zip file with an XML & bmp file. I am very happy with the results and the code has already been uploaded to SVN.

What's so cool is that the XML & bitmap component have no idea they are accessing their data inside of a zip file which is makes this design so powerful, less clutter and easier to use.

So now I have to design my XML font format and bitmap layout. I am designing it that you can use a bitmap & text editor to edit a font file. Once I have designed the font format, I will write the component to understand the format and draw text on screen.

Note that Screens is currently not supporting Unicode. I don't find it a crucial feature at this moment in development. Everything is currently ASCII.

Its going really well

I don't believe how far I have come in such a short time. This last month has been unbelievable. OK, I'll control my enthusiasm...

The zip component development is going very well. I now mount objects with the file names of the zip content. I still have to decompress the content yet which I might do on the fly if possible.

ZIP component going forward

OK, it is harder than I thought it would be and it looks like it will take some more time just to support the basic deflate compression method in a zip file. But all this information is a learning experience for me which is nice.

Currently I know the number of files in a zip file but I still cannot seem to know their file name. Oh well, I will probably find it out soon. Once I know their names, I will start working on the deflate decompression function which I have no idea about at all so it will probably take trial & error.

If I succeed, then Screens will support zip files for anything and not just for the font files. I am currently supporting very basic I/O with the file name in both the disk and zip files. I am sure I will add more information in the future such as attributes and date/time stuff.

ZIP Component progress

I have started working on the zip component which just like the XML component, mounts a file stream and creates child objects that allow to access the uncompressed file data easily once mounted. I am trying to support basic zip files (no encryption or other fancy features) so that it will work with my XML+bitmap font design.

So far, I have already find the information I need for understanding the zip format and I am now writing the routine that understands the zip format. So far, its straightforward but since this is my first time writing a zip extractor, it should take me some time.

Of course because its object oriented, I can do things like mounting an XML inside a zip file which should be interesting.

Answers

Q. About how what is the maximum size of the read only cache?

A. The maximum size is the maximum that the allocation function allows (platform dependent). Because of its temporary nature, it just does a big allocation and if it fails, it returns NULL that it cannot give a read-only cache. The read-only cache is destroyed when you close the object.

Q. Also How do I compile the SVN files? do I compile them as a dll or exe?

A. Currently it compiles in visual studio 2005/2008 (but I am sure it would be GCC compatible - if not let me know). I use Visual Studio 2008 express edition which is free from Microsoft.

Create a new empty console exe application, add all the files to the project and compile away. I designed it to be very simple to compile and I hope you will agree with me. No macros, no setup... just the default settings should do fine. The flags that visual studio adds by default are:

WIN32;NDEBUG;_CONSOLE

If you have any issues compiling or find any bugs please tell me.

XML Component complete

I have finished coding the XML component and uploaded the changes to SVN. Tags are mounted as FSFolder objects while Attributes are mounted as FSFile objects.

I am amazed how things are suddenly moving very easily. But I doubt that the font & text component will be as easy. I will probably have to create a container component first to hold both the font XML and the bitmap font, so I will see if I will create a new one or use an existing format.

XML Component progress

Just to let you know that things are moving nicely.

I have nearly finished the XML component but currently lacking support for tag attributes and for the creation of the objects that are mounted under the XML file object.

This will allow me to mount any XML object stream and access its tag and attributes as simple objects. Because of the object oriented design, the XML component is not aware of how the stream is built, only that it supports direct stream access.

Update

It looks like I am going to have to use my own bitmap font format. However it will be using a standard 256 color bmp file for the glyphs and an XML file for explaining the glyphs in the bitmap file. These could be easily put in a zip container and when I add zip support to Screens, Screens will able to use the font directly from within the zip file.

Although I don’t yet deal with 256 color bitmaps, rather only 24bit, I will add support for 256 color bitmaps soon for the font.

For now, I am writing the XML component which is very basic and is designed for quickly reading tags & attributes as objects without much verification at all. The font component then reads the XML and makes sense of it.

I added support for caching small files and the ability to access them in a read-only cache without the overhead of having to manually allocate a buffer and read bytes in bit by bit. If the entire file cannot be allocated in memory, you cannot use the read-only cache.

I don't believe how Screens is moving along. A few of you that have tested the versions have given me feed back... thanks!

Bitmaps can now be displayed

This is the furthest I have ever gone from a code perspective in Screens in the last 5 years which is something. I always find some problem (complexity, speed...) which required a re-write of the object architecture.

I can now display bitmaps on-screen clipped to a region. What's cool is that the bitmap is loaded once into an element object and then the drawing is done from in-memory using a new feature: direct object streams. An object can allow a direct pointer to its stream if it can support it. The disk file system does not support direct object streams while the default object streams do support direct object streams.

The next work is to start on the font and text components so I can display text on-screen. This is a very crucial piece for Screens to display anything useful. I will be very happy if I can get text displayed on-screen. So far, so good!

The changes have been uploaded to SVN.