680x0 development enviroment on AmigaOS4.1?

Yesterday I was wondering was, is it possible to setup a 680x0 development enviroment on AmigaOS4.1, whit out depending on UAE.

And the answer is yes.

Well first I tried AsmPRO, while program seams to work, it does give me some DSI crashes some times when I start the program, it did compile my code, but when pressing “j” to run it crashed.

So AsmPRO does not work under AmigaOS4.1, I did not like the integrated text/source code editor anyway.

Next I looked at the vbcc package it has a 680x0 compiler, but it can only produce .o files, so I need vlink once found it, I wrote a tiny AmigaDOS script.

Saved it and added script flag to the file using the protect command in AmgaDOS.

Next I found a "hello world" example using google.

Compiled it, and it worked.

So what is this all about, way do I wont to write 680x0 assembler?

Well the answer to that question is, a question I have been asking my self, what if I disassembled some of old programs that don't work anymore, will I be able fix this programs up?

I have limited experience whit assembler, I did make a 3d routine in inline Assembler in BlitzBasic2 and it worked, (I did it that way because did not have the right books, when I was learning assembler.)

Santa is working super hard to make it to christmas.

Bringing the Christmas felling to the Amiga desktop, Excalibur now running on my X1000, I might write some words about it.

It has taken allot more time then expected many of changes has resulted in having to fix new bugs, and many of previews bugs had to be fixed.

The list of changes is not short, its one of the biggest updates so it going to be called version 1.2.

* Button radius option in prefs
* Added border options for toolbar and menu 3D and XEN.
* Corrected many errors in calculations for menu.
* Background color for menu and toolbar are now individual.
* Improved rendering routines for toolbar icons
* Create_script() bug some files did not open when path was a volume.
* Fixed screen open/close notify bug. 
* Added XEN style to screens, clock and border.
* Set_screen_to_front() triggered a unnecessary refresh, bug fixed.
* Now prgram waits for singals like any normal programs does.
* Clock is now running as a subtask, and only renders when time updates,
  less CPU usage!.
* New about window is reaction, and the about event handler is running
  as a own task (bb2 legacy free.)
* CHIPMEM,FASTMEM,GFXMEM and so on, upgraded to unsigned long long int (uint64),
  should salve the negative memory problem.
* Mouse_over_clock() starts clock prefs app when clock is disabled, bug fixed.
* None initialized values in menu, can result in a crash, bug fixed.
* rendering bug when dropping icons on startbar, fixed.
* check_ext() only worked on .info files, bug fixed.
* disk.info was listed on volumes, bug fixed.
* When SYS:WBStartup is missing its created by the install script.
* Menu div can now be a transparent png image.
* menu div image can now be scaled. 

Multi treading in Excalibur

So what was done, the old event loop looked like this, the problem whit this code was that, the program did not wait for signals, it was busy looping due the clock that needed to be redrawn every 1secund, but I was not able to slow it down because that, will cause the events to be not read at correct time, there was a small delay of 0.1 sec in the loop.

 

After rewriting the code, the main event loop, waits for events before checking, it does not do anything unless something happens.

Membar is only triggered every 2 seconds, because we don't need instant update of memory, nor do we want that.

the Clock loop is only updated every 1 seconds.

  

Well so now Excalibur is Multicore ready, allowing Excalibur to wait on many cores at once.

Of cause it more to it then what I written her, most important is the Mutx protection.

Dividing the code.

As it is written in the readme Excalibur was a a BlitzBasic program, typically for basic programs is that every thing is written in as one large source file, (not true for all modern basic programs).

One thing I have done for every version of Excalibur is to split the code up, I will explain it.

A typical basic program looks like this, you have every thing mixed, its complicated to find what your looking for, when every thing is mixed, and also in C there is ways you can speed up complication time by dividing the code in separate .c files.

When the content is split up it looks some thing like this:

As you can see now is easy, now is easy to find what your looking for, but when code is split up the compiler won't find what in the other files until linking. The source won't compile or the compiler will complain about incorrect declarations, to solve this problems you most create .h file that defines the functions whit in the *.c files.

This all well, blitz basic does not know about threads or task, every thing run from start to end, whit nothing running parallel, this is bad, in Excalibur you have a clock it has to update for every second, a good program should only do stuff when something happens, the program should wake up when its signaled to do something, then event routine should check what messages has been revised and act on this, well because clock interfered whit this it was no use checking for signals, and so main loop was running and wasting CPU cycles when noting new head happened, due to being single threaded.

I worked on this and by moving the code out of main application, I have made it easy to handle it all whit the clock.c file, I added a clock_proc function that should be spawned as own sub task, so that all rendering of clock was done in parallel whit main program, whit out interfering whit event loop in the main application, some extra work was need to prevent the code from rendering when window was closed, and allow it render when window was reopened, by using Mutex I fixed it so that variable whit clock.c was set on or off to allow rendering, the main event loop in clock.c was also mutex protected to so that only when variable was not being changed, it was allowed to render.

So way did I go trow all this trouble for just a CPU parentage? Well because Excalibur is a start menu, and its always there, you might need that percentage for your video player so it does not skip frames, or your music, or maybe you playing a game, I don't know but if every one wasted CPU cycles then there wont by any left for your applications.

Its all about the details

Well some work on my hobby, its all about the details.

I'm going back to basic's I know many people like it simple, and are not so interested in all PNG images fancy bling bling, so going back to old colors and styles.

I was looking at workbench prefs and style called XEN, this where you have depth border and you have normal 3d border inside, to make it look like button or fame is not above but inside.

I liked this effect, and so I looked at ways to added it to borders.

Also some work on the selector box has been done, it was not correctly rendered, one pixel wrong there not rendered correct when scroll bar was inside the menu.

I have also worked on the prefs, I have rearrange, the visual effects, so they are nicely grouped by menu and toolbar.

I have also fund a few bugs, they are gone.

Updated a new version of Excalibur today.

Updated a new version of Excalibur today (V1.1.3).

I have been sick a few days after my Italy trip, topically the first day back to work, and you get the flu, anyway that's all over now, the pictures from Italia trip is on my Facebook, so I'm not going to post them here.

I have done few adjustments to Excalibur, nothing to too dramatic, I think I wrote on blog some weeks back some of what did, I hope every one likes the changes, and I hope it runs as it should, I most admit there are lots more to be done, but what's is the point of siting on my changes until every thing is in place, then no one will have opportunity to use my application.

One more thing I forgot note in the changes document was Excalibur now close when you change screen resolution, and reopen when new resolution is opened.

The work never stops

As you all know I been working on NoGuru (NoYellow), so I have been busy whit that for some time, but now I'm back on Excalibur.

I have been working on new menu editor as seen in right window, some work is needed, but its shaping up.

Left windows shows the new prefs program, as you can see I'm now using tabs, some was complained about size of old prefs window being too big.

On Excalibur (toolbar), the screen buttons has been rounded, and so has memory bar, the clock text as been centered, and I have also updated the virtual positioning.

Some at my job asked med create rounded corner on some buttons, as result I came up whit good idea for doing that, its not so often there is synergy between work and hobby.

 

An other project I have been working on, it has stuck on my hard drive for long time, is PublicPaint, I don't know if ever shown you this before, I don't know what to do with it yet..

But did some changes to the source code, so works tiny bit better.

As you can see from screenshot it needs a lot of love, I can't believe how tiny it all looks, most have been using smaller resolution back in 2002/2003.

It says in the about window SDL but its running directly on border less Workbench windows.

I hoping composition can help whit displaying preview graphics like brushes/cut outs, I did not have that when it was ported it to AmigaOS4.