The Datafile PD-CD 5/DATAFILE_PDCD5.iso/utilities/t/tornado/QandA/Paul2r

Text File | 1995-07-14 | 8.9 KB | 186 lines

Quoting DigiLink Email Gateway:

>> [millisecond timer] Emm, it's not hugely important as I was merely
>> thinking it'd be nice if
> The timer I've got doesn't actually work on a RiscPC - attaches itself
> directly to hardware vectors so the installer need re-writing.  I'll look
> at the IOMD this weekend.

Cheers.

>> preempted task has two problems: (a) its code must run for a minimum of
>> 1cs,
> Can't you mark tasks as `blocked'?  Then they wouldn't need to be switched
> in.

Haven't marked it into the brief fully yet. BTW, do you have v0.03 of the
brief yet? I can't remember if I sent it to you yet or not.

>> Two points to this which makes it impractical: (a) Using OS_SetMemMap is
>> extremely quick, as it's only MEMC's internal pointers that are being
> altered,
> If OS_SetMemMapEntries is so quick,  why do Acorn reccomend that
> applications for ROS3.50+ use dynamic areas,  and why does my desktop slow
> down when I have an app with a 4M wimpslot?

Because changing the memory map under the Wimp and not having it crash is
extremely difficult (try it!), and I haven't a clue about the 4Mb wimpslot
slowing it down. Sound like maybe OS_Heap is having difficulty manipulating
such a large heap.

>> [subtasks] What do you reckon?
> Need to decide on a policy.  Execute at most once would seem logical - if
> there are any errors then assume that the subtask didn't do anything so
> perhaps start another subtask to try again.  This would mean that subtasks
> would have to work on temp files and not the actual files - if half a file
> is updated and an error occurs (Address exception at 0x12345, for example)
> then you won't have to wonder where to start processing from.

Em, you can't have received that new brief then. Subtasks are carefully
watched by Tornado, and if they crash, fail to start etc. then their parent is
told of this, and the reason why as far as it can tell. It's then up to the
parent what to do about it. And if a subtask exits half way through an
operation, the procedure is thus:
   (a) if the subtask was a continual update subtask, processed data already
returned is kept and usually a new subtask started in attempt to finish off
processing (this depends on the error for the exit of the previous subtask
obviously).
   (b) if the subtask only returns its processed data upon termination, all
data contained on the subtask's heap is cleared and the parent informed.
Usually the parent will examine the error, and decide if a reschedule is
suitable.

>> On RO2, not doing anything about redraw is fine: the window is cleared.
>> Probably RO3+.
> I tried this again to check it - unless you call Wimp_RedrawWindow and
> Wimp_GetRectangle you definately get another Event_Redraw and other apps
> don't get an event.

Oh well. It's been noted.

>> See my problem with inefficiency? If you want to amalgamate all returned
>> rectangles while still allowing for the window to be resized, scroll
>> offsets
> I'll be looking at this over the next few days - I have an app which needs
> to pull chunks of data from CD,  convert from BMP format and use them to
> draw the screen.  There's a total of about 8Mb of sprites,  so I can't
> cache the lot.  This is a good candidate for background redraws,  so I'll
> let you have some of the code when it's done.

Tornado would use a subtask here, that loads in the data multitaskingly,
converts it to sprite format, and passes it to the parent, which uses the
Tornado central renderers to plot it in the window. Brief already has all
these protocols defined. Sound any better? :-)

>> Fraid subtasks are release II, next Christmas. I've written in to the
>> brief most of the protocols: I'll email it out to you when I can.
>> Meanwhile, do
> you > want anything changed in the data structures etc? >
>> :-) _IF_ you had studied the heap data structure more carefully, you'd see

Oh dear - subtasks have just been moved to the current release. Needed for the
central file translators, so it had to be done. And better: they'll probably
be needing a seperate preemptive multitasker - want to do it?

> When I wrote most of my last letter I only had the first release - not
> Brief 0.01 so I didn't have the structure to read (only an introduction to
> the Tornado standard and a file called GBPB)...

Okay, sorry about that. I thought I had emailed it to you though.

>> garbage is done. Anyway, the garbage can be optionally disabled, and even
> then
>> it would be pretty quick, being written in C and all.
> Shurley assembler...

If you want to ... :-). Nah, C will be fast enough, and if it isn't then we
can do a bit of hand-optimising. C's good at this type of thing.

>> Also, any code written specifically for the RPC will use the 32bit mode
>> /all/ the time. Has to, as it's in the aims that Tornado code should be
> Quoting the PRM (5-11):
>PRM> The new generation of ARM chips used have two modes: 26 bit (which is
>PRM> backwards compatible with ARM2 and 3), and 32 bit.  RISC OS 3.5 only
>PRM> supports the 26 bit mode. *You must not execute code in 32 bit mode*.
>PRM> If you try to do so,  you may get unpredictable crashes, especially if
>PRM> you tru to run the code in address space over 64M
> So it looks like 32 bit code is out.  Basically,  if you're in a 32 bit
> mode and an interrupt occurs,  the OS will return to you in a 26 bit mode.
> This is likely to screw any uses of R15 and CPSR.

Bloody typical! Talk about RO3.5 being stop-gap! Okay, we'll deal with it when
we come to it. I 'spose anyway? Dunno ...

>> IMHO it will be when using an internal bus, which is way way way faster
>> than any i/o interface or disc.
> But the code has to be pulled off a disk into main memory.  I don't know if
> translation is done at load time or execute time.  There's a load of Taos
> stuff on http://www.acorn.co.uk/ - do you have w3 access?

Not if the files are on ROM though. AFAIK translation for TAOS is done at load
time, as the program is being loaded in. Then it remains in memory, to be used
if necessary, until it gets flushed.
   Yep, I have www access. And I'll take a look when I can. Thanks.

>> This is *BLASTED* RO3+ for you! RO3 Fileswitch does lots of Func16 all the
>> time, even if they aren't supported (which according to my PRM's it doesn't
> It doesn't do loads of Func16's.  It issues *one* when `Shutdown' is chosen
> from the task manager.  Func16 has nothing to do with wildcards...

Odd. Justin said that was the problem he was encountering.

>> The right is black, and blank, because it's meant to be! In reality,
>> Tornado would auto-shrink and extend if necessary and the appropriate bits
> The heap looks something like this:
> +----------------------------------------------------------------------+
> ||| ||| |||||| ||||    |     |     | |                                 |
> +----------------------------------------------------------------------+
> Okay,  so the small black bits on the left are your small free bits, but
> why are there some lines in the middle.  This is *after* garbage
> collection, btw. If you don't understand this I'll send you a UUcoded
> sprite.

Yes, sorry - you have an older version, with a buggy garbager. The newer one
compacts it all into the left, albeit with a few black bits although in
reality this is the renderer overrating the free space's size.

> As I said,  when I wrote most of that last mail I'd only had chance to read
> through the first archive.  I'd only glanced at the second.  What (and
> where) is LegoCad?  Do I have all the textfiles:

Hmm, almost certainly won't work on RO3.5 - RO3.1 users have had enough
problems. Not much I think we can do here - anyway, it's not really too
important.

> rel0:   GBPB, Info, Readme rel1:   Aims, Brief, Readme
> I seem to have a file (GBPB) which refers to `guideline 5b' but no file
> which has guidelines 1..5a.  I've now had chance to look at the second
> archive properly (all the SWI / *com documentation) I should have a bit of
> a better idea what I'm on about!

:-). Hehe, gbpb was a part of a file I wrote many many months ago. And then
souped up to fit the current agenda :-) - if you know hat I mean!
   Yes, the latest release is a bit bigger (about 100k of text!), and contains
a lot more info. v0.01 is positively undetialed in comparison!

>> Let me know what you think? I'd like some input, and I'll be putting a
> message
>> onto fidonet asking for ideas.
> Don't think you were too popular putting your message in c.s.a.hardware...
> .misc and .programmer seem logical,  but hardware?  Nothing personal,  but
> most denizens seem to be quite hostile towards messages in the wrong groups.

Odd - I got quite a response from c.s.a.hardware. Oh well, the intention was
that the people there would suggest what to put in Tornado to make accessing
hardware better. And they did all right. The usual TCPIP stacks stuff, but a
few gems too.

> I'll get on with this background window redrawing now - let you know how it
> goes.

Cheers. Coding starts next week, so wish me luck! And unfortunately Justin
hasn't replied to my parcel yet. I wish he would - he's holding things up :-(

Cheers,
Niall