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

Text File | 1995-06-26 | 18.0 KB | 323 lines

"  • BackSave gives an error "Internal error: abort on instruction fetch at
   &00009DD0" which I assume is from the interrupt routine not removing
   quickly enough when the program exits, but I'm only guessing. "

More likely it's RO3. I've always said it's a bit screwed up. They added in
all sorts of weird variences from the calls, and so now things like the
contents of R3 matter when in RO2 they don't and thus RO3 dies horribly. TBH
it really pisses me off that Acorn did that.

"    Neat idea, but think of the amount of Wimp_TransferBlocks you need to do
   to complete it… "

Nope, I'm going to cheat. The BackSave program will load the code into a file
in tfs:. And then the program will be fed that file, and since tfs: operates
mostly out of RMA it'll be very quick to load, so the Wimp won't get paused.

"    Or alternatively, you could physically re-map memory so that when you
load the file it is loaded into the right place. "

Very very dodgy. If you have tried playing around with the memory map, you'll
know it's very easy to make the Wimp have a baby. Best leave it alone if
possible IMHO.

"    Alternatively, as the task is going to be suspended during the period of
   the load it would be easier (as we are already intercepting the
   Wimp_Poll's) to use the Poll, Null code to perform the load ever second. "

I could implement a Tornado equivalent of OS_File, which forces USR
mode before the SWI code executes. Or maybe make all apps use a system of:

User selects Save. Task calls Tornado_Save,params and Tornado saves the file
into tfs:. Task returns to normal polling, thinking all is done. The Tornado
module task can then do all the hard work of saving.

Or instead of saving it to disc, maybe into another app, say Zap. Anything is
possible by using this method, which is why tfs: is so important.

"  • FSsource bombed out with FS_Func 15 not supported by TFS, but otherwise,
   I see that it should work, and probably does on RO2. That happens for
   cataloguing, the load ([Int*) doesn't work due to FS_Func 14 not
   supported, but code 10 - Save block as typed file worked fine. "

Bloody RO3! Func 15 is used normally by the filer to display filer windows.
It's proper name is 'Read directory names and info' and func 14 is the same
except it only reads directory names. I can't understand why RO3 is
interfering here, as tfs: does its own matching of wildcards, as the RO2
PRM's says it should.
   Anyway, I want to redo tfs: entirely. I think I may have fucked up the
data structures too much (talk about spaghetti!).

"    Garbage looks good, but there's something up with the way it does it
that
   I can't put my finger on. It's a simple technique, but I think it will
   fall down if you have a heap which is :
    a) allocated 12
    b) free 4096
    c) allocated 12
    d) allocated 4100
   Because on the first pass it will only be able to move c to b, and then on
   the second pass it will need 4100 extra bytes to be able to move d and as
   it hasn't got it lower down the stack that block will be fixed. If the
   stack has 10000 bytes allocated to it, then the largest block which can be
   allocated is 4096, but the free space is 5876. I'm not sure of a more
   efficient method, but it occurs to me that moving large blocks of memory
   should be reduced, so you should move the smallest blocks first and then the
   larger ones. No that's wrong, then you get the same problem. Erm, I'm not
   sure, Heap allocation wasn't one of my strong points - hence why I've
   always used the RMA instead of Wimp_Slot for variable sized datablocks
   (naughty). Hmm, I'd love to hear about how you are going to do it as I'm
   not so sure myself.
   PROCfreeblk - missed out R0 again. Seems to work ok. Now to test FNgrabage.
   Looks ok, but I'm not sure that Showheap works correctly - that could just
   be me though. "

I agree, but using better methods is far more time-consuming, and when you'll
have auto-compression after every heap op, it'll have to be quick. I've
revised the heap garbaging, and fixed a major bug, and if you run HeapExt for
quite a while you'll see fragmentation is pretty minimal. And for Basic, the
heap op's are bloody fast - imagine it in assembler!
   I believe there might be a problem under RO3.5 - Acorn have changed the
OS_Heap format, and no doubt will go for some stupid relocatable
implementation like WimpExt uses (which really is crap). WimpExt is also on
the disc.

"  • GBPB document Guidline 5b - Good idea about not pausing Wimp, but
   sometimes it is necessary to load an app as quickly as possible - ie load
   diary whilst on phone, am I free, damn I wish I'd set that time as "

In the end, the task doing all this preemption, multitasking loading etc.
will be written to do this, but Tornado has master control ie; it can really
single-task load it and the task will never know. The structure of the SWI's
will reflect this, and every Tornado task has an !Options (very Mac like,
but the difference will be that this options can be edited with Zap freely
and easily, rather than having to load a specialist app like on the Mac.
Mind you, the Tornado app manager will do it too with far less fiddling),
which contains standard Tornado options (like, multitask this or that?) as
well as app-specific ones. Ultimately, the Tornado application manager,
running from the Tornado module task, will allow very quick and simple
altering of this. Your phone rings, you hit Ctrl-Alt-f12, up pops the Tornado
app manager window, a few quick clicks later and the Database app loads in
single-taskingly. Anyway, if you write your GBPB i/o in assembly, and do it
well, you can load an app almost as fast as OS_File can. For example, in a
past app of mine called Flow, it compressed data on the fly and wrote it to a
file a byte at a time in mode 13. The file is saved at the full 20k/sec that
the floppy drive can offer.

"    longer... I agree with Tornado_StartPreemption, and use a basic version
   of it in my ReadMail application for the utilities which were originally
   single tasking. It that way my ‘multiple-processes’ can be carried out
   concurrently. But I will say that doing this really does slow down the
   single tasking program. "

I have the preemption code, which allows an app to be preempted constantly if
it so wishes. Problem is it isn't very efficient (null ret codes always have
to be returned). That's enclosed. It isn't tested, but I wrote it one night
after a lot of alcohol, so suffice it to say it probably will. :-)
   Next option I have is a TAOS-like method of starting up remote processes.
You've already read about that, but there's no reason all the processes can't
run as Wimp tasks.
   Final option is for the process to be written to work in bits, and Tornado
can have it called. Not perfect.
   Problem is that languages like Basic won't support multiple threading,
like say the main polling loop calls Tornado_Poll, and Tornado_Poll then
returns out of a Tornado_Poll in another part of the code. Do this and Basic
crashes, as it's expecting the second SWI to exist before the first is even
called and exited. C will work, as will assembler, but Basic won't. This
limits things quite a bit, and adds a lot more onto the programmer than is
really necessary.

"    Hang on, if you use top for input, bottom for output (like packdir) and
   both for non-multitasking then what happens if non-multitasking program
   does a lot of input and output (eg packdir). Better to use LED 3 which is
   unspecified in Acorns Hourglass but useable if you get DoggySoft's
   HourMake program (it's PD, I would send it but it's quite big)
   The hourglass standard sounds good though - like the PC when it's
   downloading data in a web viewer, at least those I've seen. "

For a start, it's dangerous for any program to do alot of input followed by
output, with say like byte quantities from the opposite sides of the same
file. Can very badly corrupt the data, as you'd find out when weeding
messageareas in some of my modes. Dunno why, it's badly written IRQ code in
FileSwitch/FileCore I think, and I think the problem doesn't happen if you're
using fast media (not a floppy). But that besides, I agree. I dunno about the
hourglass shapes (I'm not a great designer), but what I do know is I want to
implement changing pointers, where the different things you can do are
represented with the mouse pointer changing every 25cs. And while the mouse
is moving, the arrow shape stays mostly but changes to the ptr(s) for 2
frames say. This way, we can legitimately do a few less obvious options, and
they won't get missed. Plus, the user knows what will happen if say he/she
clicks on a reply button. Handy. And rather intuitive I think.

"    Hmm. I'm not sure I like the way that Tornado tasks have the same style
   of code used for their configuration as Tornado tasks. Better to have a
   central configuration program for Tornado specific settings and to have a
   menu option to configure Tornado. This then initiates an external edit of
   the configuration file stored in that application to alter the settings. "

What was planned was a standard general Tornado options window, common to all
Tornado apps. This window is automatically drawn by Tornado, handled by
Tornado etc. and is a pane in the task's option window. This allows
individual task general Tornado option setting, and Tornado app manager can
allow global options to be set, or enforced as the case may be.

"      flags bits : 0 Set if active immediately
                  1 Required to kill current tasks to set options "

Ooo, not good! No Tornado task should have to quit to reset options. But if
it were absolutely necessary (unlikely IMHO), the task pops up a dialogue,
and reruns itself, keeping the original app intact. When the new app has
loaded, it knows from an option set in its environ. string that an option has
been reset (or the original app sends the new app a message), and requests
the files. The files are RAM-transferred, and if everything's fine the old
app terminates nicely. If the new app couldn't load in, then the original
task remains with options unchanged for the parts which couldn't be.

"  • External Edit spec is available at Arcade as ExtEdit1 (I think) and is
   moderated by Jason Williams in New Zealand. Alex Hayward understands it
   better than I do because he's used it in his OLR and I've only just
   started programming using it.
   External Edit might be useful in implementing your remote process of files
   protocol - just a thought :-) "

External edit dies horribly on RO2 :-). However, in the case of an OLR, OLE
would be used instead. And unfortunately, for remote processes I think would
need their own protocol, or things would get messy. Nice thought though!

"  • Would some sort of special protection for Tornado tasks be possible so
   that if they died they could never lock the machine up ? "

Is done. Tornado hooks into Address exception etc. and catches any such
errors while Tornado_Poll is being used. Problem is reiterative loops which
never end. I reckon a method of hacking out of these using something like
Windows version wouldn't be too difficult. Polling would return, except the
offending task wouldn't be polled. This is so easy I personally can't
understand why Acorn haven't done it yet.
   Mind you, there are just some things that can't be helped. If a task went
out of its way to corrupt memory, there would be little to be done. But
Tornado will also hook into things like OS_Find, closing any open files if
necessary. All will be done to try and tidy up properly.

"  • Virtual single tasking programs ? A single tasking program could ask
   Tornado to either open a sprite window for it's output (VMode style), or
   the task could be interrupted with Alt-Tab and the desktop switched back
   in, the task having been delinked and paged on to disc so that the memory
   remains useable. I have begun work on this be have hit upon a problem with
   the Wimp_Polls subsequently crashing. I think it's a mode problem. Once I
   sort it out I'll tell you. "

This isn't really too difficult. Another (eventual) Tornado general option is
to intercept all non-multitasking programs starting up, and sticking them in
a window, and being preempted. You will need to intercept a lot of SWI's
using a rewriting of &08 (eg; OS_ReadModeVariable etc.), and not pointing VDU
output into a sprite unless a write into the sprite is done (changing vdu
output is slow). Also, you could intercept and change the screen memory base
address, and this would allow a lot of games to work too.
   As for switching the desktop back in during a game say: much the same
IMHO, simply having the Wimp multi-task while the game runs (by preempting
the game and during the polls switching output into a sprite ie; the wimp's
output gets redirected into a sprite instead of the usually preempted task).
Again, replacing most of the OS :-) would help a lot there, but really it's a
lot of work for little gain. Few people have enough memory to run multiple
copies of most games at once in windows and/or with the desktop. And worse
still, as memory increases, so will games demands.
   Even without them being games, most programs are single-tasking for a
reason.
   Good luck though!


"   ND> God, we _do_ think alike! I had the very same idea, and I've done
  ND> a protocol too. Mind you, could I see yours too? Mine's a bit more
  ND> outrageous, like most of Tornado, and no doubt just as impossible
  ND> to write, but hell, one's gotta aim high.

I don't think that mine is quite as extravagent as yours, and I wrote it
before I knew about ExtEdit protocol. The idea was that you could link
documents between packages which didn't specifically know what they were
linking to, eg Almanac. Hang on, I'll have to extract it from my Word
document…

--8<--------
        Simple specification for linkages between entries within files
        ==============================================================
               Linking individual file entries within other files "

Hmm, interesting. Not quite my idea. Here's what I want:

I figure that if all Tornado tasks support OLE, what's to support hotlinking
too? For example, in Impression, we have an empty frame (this is assuming
that Impression were a Tornado app), and we have a graphing package and
spreadsheet also loaded in.

We open a new spreadsheet. We then save this as a hotlinked file into the
graphing package (by simply dragging it say while holding down Ctrl or
something). Then we save the results of the graphing package (also as a
hotlinked file) into the frame in Impression.

Now we alter the spreadsheet. The graphing package picks it up, redoes its
graph, and impression then picks up the altered graph and redisplays it. All
this happens without polling stopping, so possibly if the spreadsheet were
big and were to take a long time to recalculate, the graph in impression
would be updated dynamically.

This is again unbelieveably easy to do. All files, and files contained within
files are kept in tfs: by Tornado (has to). So, Tornado altering a file or
subfile and then informing the task is possible. This opens a huge range of
possibilities for OLE and hotlinking.

<Mmmm, I'm just eating some homemade Irish chocolate. Cost a fortune, but
mmmm is it nice!>

Ok, let's take it further. Imagine a graph listing the occurences of 'peter'
in the name entry of your databases (ie; your phone books). A custom written
task asks Tornado to fill in the address for all people called 'Peter' (this
is supported so, say if you were writing a letter you could ask Tornado to
pull the address for some name from within the word processor *[1] ) and
passes any results to the spreadsheet, as each relevent cell in the
spreadsheet is individually hotlinked to a file within the custom app (ok, so
the custom app would have a lot of files!). Then the spreadsheet recalculates
as it receives new data, the graph redraws, and impression updates its graph.
This would be extremely productive, although admittedly it's a pretty stupid
example (hardly useful eh?).

*[1]: The way Tornado searches for a database entry (ie; the address for a
name) by looking through all available media for all Tornado apps which do
databases (how does it know? =!Options) if such a database app isn't loaded
yet. Then the app is used to examine all the files on available media for
database files, these are loaded in, and a list is made of entries with
'Peter' in. This would normally be put in a dialogue window, and the user
allowed to choose their entry(s), but here it's all passed to a custom app.

My point is that, although this type of sophistication won't be available in
release 1-4 of Tornado, the building blocks /should/ be laid to allow it to
be done pretty easily later. By the time release six/seven comes out, Tornado
tasks will be so far ahead of their rivals _nothing_ will compare. And best
of all, the amount of effort required of the programmer will be about the
same for writing the current style of app.

First things first though (I use the above to try and keep the enthusiasim up
and not let myself slip), _we_ need to do an awful lot of work. That is, if
you're game for it.

Also, I'll remind you, that if this succeeds as it could, it may well become
that we'll be looked to for bug-fixes improvements etc. that normally would
be levied on Acorn. I mean, Tornado will have become such a _huge_ part of
the OS that a lot of people will be breathing down our backs. A problem, but
one I'm looking forward to :-)

Also, finish this, and you now have something v. nice to put on your CV. I
got my exam results yesterday: four B's, four C's. No Cambridge for me!

I have another bloke called Paul Corke also wanting to do something. Me being
a person not wanting to disencourage anyone, I'll send him something that
should stir his blood too.

I read up on TAOS a few days, and was rather horribly surprised how much had
already been developed. Tornado has many TAOS qualities, and I'd like to see
how TAOS copes in real life, in real situations. Despite what Acorn might
think, IMHO TAOS really needs more than four processors as they'll soon find
out when they finish that RPC replacement prototype. I think 16 should be
enough, and if there need to be more processes then double processes can be
run by preemption on the one processor.