The Datafile PD-CD 5

home *** CD-ROM | disk | FTP | other *** search

/ The Datafile PD-CD 5 / DATAFILE_PDCD5.iso / utilities / t / tornado / TNdemo1 / Readme < prev

Wrap

Text File | 1996-03-06 | 11.4 KB | 214 lines

Readme for tornado 0.10b (06-03-1996) by N. Douglas This is a temporary release of what is a small taster of what is to come. In this archive is !Tornado, the resource directory but with only the kernel, and !TornWin, a demo tornado window. This is a tornado window as it should hopefully end up looking like. This is merely an intermediate program. I'm still writing it, as you'll see if you look through the code. ATM, I'm doing the icon stuff, and when that's done I'll finish off the string and attribute handling properly, including visual linking to code fragments. Then I'll convert the lot into assembler (then release), whack it into the shell module which isn't being released with this, and finish the multitasker (then release). I suppose that at this stage tornado would be something which theroretically people could actually write for. Why release it now? -=-=-=-=-=-=-=-=-=- I thought I'd release this copy now, mainly for two reasons. Firstly, a lot of people seem to think I'm some kid who came up with a good idea, flashed it around the networks and then got bored and went away. I'd like to say to all those who have been saying this *GO* *SCREW* *YOURSELVES*. I'd also _quietly_ ask that if you lot are so full of yourselves, then why don't you sit down and try planning and writing all this crap out, especially when you have a major amount of study for rather important exams soon. I'd love to see your (feeble and pitiful) attempts, honest! :) Secondly, there has been a slight but noticeable increase in the number of people who are getting very gloomy about the future of RISC-OS, the architecture and Acorn in general. I hope this will show you that things aren't going to the dogs quite as easily as some of you might think, that some people are actually doing things about it. Cheer up! ;) Just as a statistic, I've been watching hensa's top 50 for a while now, and I've noticed that since its appearence in AU, it's never left the list - and seeing as I'd prefer it not to, I decided to knock out this. Some people already have a much much older version of this program, which on the front does the same thing, but in fact is a totally different program (I had to start all over because the code was getting too messy + it didn't use the kernel at all). So, if you have a copy, and are thinking "This hasn't changed much in 3 months or so", well, you're wrong! Bugs -=-= You'll notice that it all still has a few bugs. Firstly, scrolling by the scroll bars corrupts the display - and don't ask me why, I think it's rounding errors. I only finished this bit today (scrolling), so I still have a bit of leeway. Next, the tornado kernel has a MAJOR bug with post-wimp-slot heaps - it hates extending them (again, I don't have a clue why - it hasn't any problems with extending anything else). Next, the fonts aren't recached on mode change - changing mode from hires to lores or vice versa causes problems. In addition, nothing is done on mode change - so the RISC-OS dummy window may unstick from the tornado one by a pixel or two for example as RISC-OS tends to realign windows to the eigen factors on mode changes. It also works much better if you reinitialise it before use (hence the yucky *RMReInit in the !Run file), mainly as it's becoming quite a horrible bit of code which has been tweaked a lot. When I first wrote the memory routines back in July-August 95, they worked perfectly. Since, I've changed the heap data format three times, tweaking the code each time. Also, they were written for speed, meaning the source is about as incomprehensible as the debugger output, so my skills as an assembly programmer were sorely tested, and I think I must have missed something somewhere surely. However, I'm sure the bugs will slowly iron themselves out in due course. You may think it runs very slowly. This may be because you are running it from a slow medium, and a log file is continually written to by the program - if so, either copy it to a quicker one (eg; RAM disc) or edit the !RunImage (change line 220 to log%=FALSE). The other thing is that you may have a 'slower' machine - it takes three seconds on mine to redraw fully in Mode 20 with a standard palette. When dragging things around and over it though, do note how the window doesn't always redraw fully, but given a chance it does. This is a taster of what multitasking redraws look like - not hugely impressive here because the redraw code's in Basic, but when in assembler it should really kick ass. Also, of course, Basic won't multithread, so in fact it should be even more impressive with many sections being redrawn simultaneously. You'll notice how it doesn't leave things unupdated like Win95 or System 7.x - this is because redraw threads are placed in the top priority, so they get the most CPU time. In fact, on tornado, redrawing is the THE top priority of all - nothing can be higher. BTW, if it looks real gammy - there are two reasons for this. First, and probably most likely, is that you don't have enough colours on the screen - although I can't test it, it should look gorgeous in 24bit (and be quick too as there shouldn't be any need for colour translation tables). Anyway, in Mode 21 on my machine is looks bloody fine. Second reason is if you aren't using a hires display. I haven't implemented lores operation yet (nor will I until /way/ into the future - after when the multitasker has been written), so it simply scales the sprites down to fit (which looks crap). Documentation -=-=-=-=-=-=- The two files _Kernel and _Shell give a few bits and pieces about each relevent module and what they will do. In particular, _Shell has a good few updates on the docs older than this release. The program MultiTtest implements a model of the tornado multitasker - would anyone with experience in multitaskers contact me as I have precious little information on how they should work? Currently, the multitasker takes current CPU speed (based on screen mode, CPU speed etc) and the load on the RISC-OS desktop into account when sharing out time between individual tasks, and attempts to obtain the maximum efficiency it can (time spent executing code against time spent in multitasking the code). The testbed multitasker as supplied was fed the data for the processors below, given eight tasks to switch between and told to (a) turnaround all tasks in 25cs and then pass control to the wimp and (b) turnaround all tasks in a second but every 25cs pass control to the wimp. Here's the results: Type (a) multitasking: CPU MIPS Efficiency cs per task turnaround time (secs) 8Mhz Arm2 4 99.75% 2 0.2 12Mhz Arm250 6 99.87% 3 0.26 25Mhz Arm3 12 99.93% 3 0.25 33Mhz Arm3 15 99.95% 3 0.25 30Mhz Arm610 26 99.97% 3 0.24 33Mhz Arm700 35 99.98% 3 0.24 ??Mhz ArmXXX 50 99.98% 3 0.24 Type (b) multitasking: CPU MIPS Efficiency cs per task turnaround time (secs) 8Mhz Arm2 4 99.92% 7 0.62 12Mhz Arm250 6 99.95% 7 0.6 25Mhz Arm3 12 99.97% 7 0.58 33Mhz Arm3 15 99.98% 7 0.57 30Mhz Arm610 26 99.99% 7 0.56 33Mhz Arm700 35 99.99% 7 0.56 ??Mhz ArmXXX 50 99.99% 7 0.56 The MIPS values are approximate, and the Arm700 one is for a prototype chip, not the production one. As you can see, the switcher is very optimised, achieving at worst a loss of 0.25%, and obviously the faster the processor the less the loss is. Anyway, while all this is all well and good, there is a problem. As you can see, the multitasker can only handle a minimum of 1cs slices. Now, I don't know much about other architectures, but 1cs is an *awfully* long time, and it gives very little scope for multithreading as you only need ~25 processes running for cascade overload (ie; when total time to turnaround exceeds time allowed for turnaround). This is _nothing_, as another testbed of mine proves that when you move a tornado window around a lot you can start up to a hundred new redraw threads. Obviously, 100cs is > than 25cs, and cascade overload happens just like that! :((( So, what I'm wondering is, does ANYONE know of any method past this? Maybe a different method of multitasking? Perhaps a method of scheduling interrupts for periods smaller than 1cs on existing Acorn machines? You can hook code onto the internal hardware ticker vector, which oscillates at (I think) 2Mhz, but this is unsuitable for interrupt code as - well, how the hell would you do it? Anyone got any ideas? Please contact me then! As a final point, I think the kernel's Tornado_Hourglass call still works - if it does, have fun! (and make sure you save your work first!) Cheers, Niall Douglas Methods of contacting me: -=-=-=-=-=-=-=-=-=-=-=-=- I am plugged into the various networks at the following addresses: Niall Douglas@fidonet#2:443/13.68 Niall.Douglas@443-13-68.conqueror.co.uk - this is an internal Irish address and so is very cheap for me to use. Please send anything to here if you're on fidonet. The internet address attached to it is very unreliable at the moment (probably disconnected for good :( ), so if you don't get a reply try the other ones below. Niall Douglas@fidonet#2:257/501.13 ndouglas@digibank.demon.co.uk - this is in the UK, which is at cross-channel rates for me (ie; VERY EXPENSIVE). The internet address attached, unfortunately, also is expensive, so if you use this address, please do NOT send anything largish, only smallish messages. tornado@ucc.ie - this is my local internet PoP, but irritatingly doesn't have an offline mail reader ie; I have to do all mailing while online which mounts up. It's great for large uucodings though ie; if you want to send me a file, do so through this address. Finally ... -=-=-=-=-=- I'd like to thank the following people: - Ricky Sarge, for your help with the memory copying code - Nava Whiteford, for your support and saying how wonderful my ideas are ;) - Justin Fletcher, for inspiring me with that data streaming and eyes and hats and arrows etc stuff. BTW, how's Caroline? (rotten joke). If you're wondering, Laura's doing just fine ... I still keep socialising with her ... I'm thinking of asking her to my graduation dance ... ooar! ;) - Colin Turner, for being so /you/! - John Stonier, for never answering your mail! ;) - all the blokes on the Acorn fido-scene, and various people from the internet for all your ideas and support. I hope I do justice to your requests! Last but not least ... -=-=-=-=-=-=-=-=-=-=-= I'm looking for work in England for the summer for July and August. I'm hard-working, excellent at computers ('specially Acorns of course), and willing to take almost peanuts for pay! As you can see above, I'm pretty handy with the programming, and I've serviced and upgraded my computer entirely by myself. I can fix (almost) any problem with an Acorn, and can go a long way to a solution with Macs, PCs or Unix boxes. I should get around 500 out of 600 points in my Leaving Cert in June and would be willing to work anywhere in the UK. If you are interested in employing me (and why not???), then email me above and ask for a CV. I'll be emailing all the Acorn-related companies with email addresses anyway, when I get a list that is!