vanaards%t7@uk.ac.man.cs (02/11/91)
There seems to be a trend in these discussions as to what we'd like to see in a new Archimedes machine. Well I'll add to this : Presently there is NO way of undeleting a file - this is a MAJOR mistake. If you're in business & you accidently delete your current work file you've no way of recovering it other that hacking the disk. But with DOS based systems there's no hassle, I've seem many undelete programs. Why place the Econet roms in the machines OS as standard ? How many users actually use Econet. As Acorn consider schools,etc as their main market this may seem good policy - but why not move them off to a podule ? The MEMC chip needs to be replaced, I believe that the current page size is far too large - this is apparent on UNIX boxes. I'd like to see faster screen updates regardless of mode. Now I haven't any sound ideas on how this should be done - perhaps a second bus and screen memory, or a BLITTER chip ? I'd like the TASK manager icon to display the Tasks window without having to go through that menu - perhaps by pressing select only. What about a facility of killing modules from the desktop too ? Some time ago several modules appeared to change the current directory from the desktop, and display the current directory name alongside the OS prompt. These should be incorporated in the new system. A larger string size should be made available to system variables, having a limit to 255 characters for <run$path> tends towards a broad disk heirarchy, either introduce several run$paths, or increase the limit. Group selection of icons within a window would be useful. If you're familiar with the Atari machines you'll know what I mean. Being able to have a rubber banded selection area would make things a lot simpler when operating upon a lot of files. What about passing parameters to programs from the desktop. Select a program and using the menu, enter the command line parameters you want to use. From the few dealers I've been to, they seem to concentrate upon desktop publishing on the Archimedes, perhaps they should be encouraged to promote the business advantages as well. Why use the Archimedes as a DTP machine only, a DOS machine does that, and everyone knows that it's a business machine, thus having everything needed by a prospective business user. If I have any more ideas I'll send them too. PS has anyone noticed that if you hold down the SHIFT key, press the CapsLock Key - the light comes on (as expected) but if you then try to turn CapsLock off whilst holding down SHIFT the light doesn't go off ! +--------------------------------+-----------------------------------------+ | ()()TEVEN () | | | () ()() | | | ()() () ()AN () () | | | () ()() ()()()() +-----------------------------------------+ | ()() () () ()ARDT |JANET E-mail : vanaards@uk.ac.man.cs.p4 | +--------------------------------+-----------------------------------------+
rhh88@ecs.soton.ac.uk (Heywood RH) (02/12/91)
In <1991Feb11.124128.2990@cns.umist.ac.uk> vanaards%t7@uk.ac.man.cs writes: >PS has anyone noticed that if you hold down the SHIFT key, press the CapsLock > Key - the light comes on (as expected) but if you then try to turn CapsLock > off whilst holding down SHIFT the light doesn't go off ! Nope, can't say I have but I give it a try!! ttfn Rik ______________________________________________________ / \ / Richard Heywood (Rik) \ / rhh88@uk.ac.soton.ecs \ \ / \ The Spice must flow / \______________________________________________________/ A very intelligent turtle Found programming UNIX a hurdle The system, you see, Ran as slow as did he, And that's not saying much for the turtle.
gcwilliams@watdragon.waterloo.edu (Graeme Williams) (02/13/91)
In article <1991Feb11.124128.2990@cns.umist.ac.uk> vanaards%t7@uk.ac.man.cs writes: >[stuff deleted] > Why place the Econet roms in the machines OS as standard ? How many users > actually use Econet. Not me, but then just how much space does the Econet code use? > The MEMC chip needs to be replaced, I believe that the current page size > is far too large - this is apparent on UNIX boxes. And be able to address a whole lot more than 4Mb. Lets say 4Gb, that should take care of any expansions for the next year (maybe even *two* yrs :-) ). > I'd like to see faster screen updates regardless of mode. Now I haven't > any sound ideas on how this should be done - perhaps a second bus and > screen memory, or a BLITTER chip ? Does this mean I'll have to learn how to write code for a second chip?? The nice elegant ARM code is plenty enough complexity for me. Also having screen memory separate would spoil the simplicity and elegance of things. (I'm a great believer in keeping things clean and simple and efficient, for a reason why one only has too look at a 386 running DOS.) "Blitter chip" - sounds like Amiga or Atari. No thanks. Crank the ARM's clock speed up another notch instead. >[stuff deleted] > Group selection of icons within a window would be useful. If you're familiar > with the Atari machines you'll know what I mean. Being able to have a rubber > banded selection area would make things a lot simpler when operating upon > a lot of files. Doesn't the desktop enviroment do this? I know if I want to copy a bunch of files from one place to another, I go click-click-click on each of the files (BTW they almost never fill a rectangular region) then drag them inside a rubber band as *one* group to the other directory/device. Here's one thing I'd like to see. The graphics code in ROM for drawing circles and rectangles and such like appears to be very inefficient, it'd be nice if these could be made faster (like by a factor of 3 or 4 in some cases - I believe this is possible) Graeme Williams - a Kiwi in Canada gcwilliams@watdragon.waterloo.edu
seifert@diku.dk (Michael Seifert) (02/13/91)
gcwilliams@watdragon.waterloo.edu (Graeme Williams) writes: [much stuff deleted] >> I'd like to see faster screen updates regardless of mode. Now I haven't >> any sound ideas on how this should be done - perhaps a second bus and >> screen memory, or a BLITTER chip ? >Does this mean I'll have to learn how to write code for a second chip?? >The nice elegant ARM code is plenty enough complexity for me. Also >having screen memory separate would spoil the simplicity and elegance of >things. (I'm a great believer in keeping things clean and simple and >efficient, for a reason why one only has too look at a 386 running DOS.) >"Blitter chip" - sounds like Amiga or Atari. No thanks. Crank the ARM's >clock speed up another notch instead. Agree. BUT! What if the blitter was just another ARM-2? I like that thought. Am I correct in assuming that the ARM-2 is only around 20 pounds? (at the facory?) [more stuff deleted] >Here's one thing I'd like to see. The graphics code in ROM for drawing >circles and rectangles and such like appears to be very inefficient, >it'd be nice if these could be made faster (like by a factor of 3 or 4 >in some cases - I believe this is possible) Just think if they ran on a "blitter" ARM? AFter all isn't it Apple among others who have considered using the ARM for a graphics accelerator? >Graeme Williams - a Kiwi in Canada >gcwilliams@watdragon.waterloo.edu --Michael Seifert seifert@freja.diku.dk
hughesmp@vax1.tcd.ie (02/14/91)
In article <1991Feb11.124128.2990@cns.umist.ac.uk>, vanaards%t7@uk.ac.man.cs writes: > > There seems to be a trend in these discussions as to what we'd like > to see in a new Archimedes machine. Well I'll add to this : > > Presently there is NO way of undeleting a file - this is a MAJOR mistake. > If you're in business & you accidently delete your current work file > you've no way of recovering it other that hacking the disk. But with > DOS based systems there's no hassle, I've seem many undelete programs. This _is_ a major problem, I agree. Is this such a big problem with ADFS? I don't know enough about ADFS to do anything about it, but shouldn't it be just a case of editing a small bit of the directory to mark the file as not deleted, or does ADFS physically delete info about the file... If not, it would just be a case of someone who knew about ADFS writing a small utility. > Why place the Econet roms in the machines OS as standard ? How many users > actually use Econet. As Acorn consider schools,etc as their main market > this may seem good policy - but why not move them off to a podule ? The machine has too few podule ports to make this a viable option IMHO. The hardware, which would be the main cost, isn't supplied, just a small amount of the OS. Is that such a big problem? I'm sure even still, there's some space left over... Even if there isn't, its just a case of plugging in more ROMs, like RISCOS3 to put more in, so it's not actually reducing facilities available... > The MEMC chip needs to be replaced, I believe that the current page size > is far too large - this is apparent on UNIX boxes. Someone mentionned MEMC2... I dunno if this fixes that. > I'd like to see faster screen updates regardless of mode. Now I haven't > any sound ideas on how this should be done - perhaps a second bus and > screen memory, or a BLITTER chip ? Yes, I _want_ direct screen memory access for the VIDC. On the Amiga, you can have up to 5 bitplanes and 4 channels of music going, without impinging on the speed of the machine at all; the relevant chips just use direct access to the memory, and so you don't have the problems the Arc does, of going at under half speed in a big mode, with music. A Blitter chip would similarly need direct memory access; unfortunately however, it would have to be a _very_ fast blitter, ie an ARM coprocessor or something, to be able to viably compete with just getting the processor to do whatever you wanted itself; as it is, the ARM2 can shift 4 * the memory than the Amigas blitter, I believe. The Amiga 3000 has a similar problem of the processor outdoing the blitter. The best thing I think Acorn (VLSI?) could do on a hardware scale, is get this direct memory access thingy; it would double the speed of the Arc for a lot of applications, without being too costly.. OSwise, there are a fair load of things that could be done, but I reckon they did a fairly good job of it on the whole. T.
hughesmp@vax1.tcd.ie (02/14/91)
In article <1991Feb12.212522.14434@watdragon.waterloo.edu>, gcwilliams@watdragon.waterloo.edu (Graeme Williams) writes: > Here's one thing I'd like to see. The graphics code in ROM for drawing > circles and rectangles and such like appears to be very inefficient, > it'd be nice if these could be made faster (like by a factor of 3 or 4 > in some cases - I believe this is possible) I reckon that to provide the functionality to cope with everything that those routines currently can, they would have to go at around current speed. (Although, compared with any other BASIC, that speed is amazing). Remember that these routines can cope with any mode, going off the screen, screen swapping (not difficult), wrapping around the end of screen memory, many colours, many methods of plotting ie OR, EOR, &c., stippling (I think), to name but a few. I reckon that they did fairly well; if you want to write a quick circle routine, get a library of routines, which when you call the initialize code, will assemble the code, and then provide procedures which call the code, ie PROCcircle(x,y,r), and so on. These can have as little error trapping and functionality as you want, with maximimum speed. A nice thing for BASIC would be to be able to define new commands in a module; the commands would be stored as ASCII in the program, just like if you type 10BLABBER 20,30,40 and the interpreter would come across this, and poll the currently installed modules to see if anyone would offer to do it. That would be _gorgeous_, and would allow for a fully expandable instruction set.. > Graeme Williams - a Kiwi in Canada T.
mathew@mantis.co.uk (mathew) (02/20/91)
In article <1991Feb12.212522.14434@watdragon.waterloo.edu>, gcwilliams@watdra > Here's one thing I'd like to see. The graphics code in ROM for drawing > circles and rectangles and such like appears to be very inefficient, > it'd be nice if these could be made faster (like by a factor of 3 or 4 > in some cases - I believe this is possible) As someone else has pointed out, the existing routines are quite general, and you're unlikely to be able to get them any faster without losing some generality. I think they use Bresenham's algorithm for circles, which is about as good as you get. If you really do need lots of circles very quickly, you can write your own very fast algorithms providing you assume a few things. Look at some books on graphics algorithms. If you can assume no clipping, that helps a lot. As far as rectangles go, you may be able to get a factor of 4 or more speedup if you're careful to arrange things suitably. If the video RAM is organized in bitplanes, you can choose your colours carefully so that you only ever need to blit to one or two of them. This is how games on the ST manage to do smooth scrolling; the 68000 wouldn't really be up to whacking 32KB of RAM around every refresh. For general rotation, circles and the like, my favourite trick is to use a circular array of 360 signed words as a look-up table for sin and cos values. You pre-compute 32767 * sin( rad (x)) for x = 0 to 359 and store the answers away. You can then get sin and cos values extremely quickly :-) I used to do this all the time on the BBC micro, in order to speed up graphics demos. ('Course, in them days I was usin' bytes... Aye... We only 'ad one register, and that were t'program counter...) [ By circular array, I mean that if you ask for A[x] where x>360, you subtract 360 and try again. ] It's an obvious trick, but quite a few people seem not to have thought of it... Jeff Minter uses "yakly degrees", which go from 0 to 255 :-) mathew.
Gavin.Flower@comp.vuw.ac.nz (Gavin Flower) (02/22/91)
In article <2042@xenon.kcl-cs.UUCP> wainhous@kcl-cs.UUCP or ZDAC164@UK.AC.KCL.CC.ASH (Andy) writes: >In article <1991Feb11.124128.2990@cns.umist.ac.uk> vanaards%t7@uk.ac.man.cs writes: >> >>PS has anyone noticed that if you hold down the SHIFT key, press the CapsLock >> Key - the light comes on (as expected) but if you then try to turn CapsLock >> off whilst holding down SHIFT the light doesn't go off ! >> *********** This was available on even a BBC model "A" !!!!!!!!!!!!!! -- - Gavin C. Flower ******* These comments have no known correlation with dept. policy! *******
jroach@acorn.co.uk (Jonathan Roach) (02/23/91)
In article <1991Feb13.161140.7781@vax1.tcd.ie> hughesmp@vax1.tcd.ie writes: about ADFS undelete and screen update speed. Just to clarify one or two points: when ADFS deletes a file it removes the directory entry and returns the file's space to the disc's free space pool. There is no record kept of what parts of the free space pool made up what files in the past. This makes undeleteing a file very difficult. Also, I note that saving a file is more likely to destroy that precious old version than straight delete. The above article also concludes: >The best thing I think Acorn (VLSI?) could do on a hardware scale, is get this >direct memory access thingy; it would double the speed of the Arc for a lot of >applications, without being too costly.. Well, the Archimedes already uses DMA for screen and sound. The observed slowdown is due to the CPU and the screen and sound contending for the memory's time. The memory has an upper limit to the quantity of data it can ship out in a given time - for an Archimedes this is never greater than 25600000 bytes per second. For entirely random memory accesses this rate drops down to 16000000 bytes per second, but the Archimedes memory controller often optimises sequential memory accesses thus improving the memory bandwidth. For a mode 15 screen the quantity of data shipped per second is about 8Mbytes, thus leaving about 17Mbytes per second for the CPU - slowing the machine down to 2/3 it's old speed - the machine's CPU speed being almost directly linked to memory bandwidth available to the CPU. Another point to observe is that updating the higher colour and resolution screen modes simply requires more data to be written to the screen memory to fill a given area, thus is bound to take more time. Earlier in the article: >On the Amiga, you >can have up to 5 bitplanes and 4 channels of music going, without impinging >on the speed of the machine at all. which is actually not true. As I understand it the Amiga has the screen and DMA buses separated such that memory expansion beyond a certain point can't be DMAed, but doesn't have its bandwidth swallowed by DMA either, thus enabling the CPU to run at full speed in that area. If the CPU is running in the DMAable area, then its speed will be significantly hit as it contends for the memory's time with the screen and sound. Also, if the CPU is updating the screen or sound information, then those memory accesses to the DMA area may be delayed as the CPU waits for the screen or sound DMA to finish. I might have got the details of the Amiga description wrong, but the basic principles are correct. --Jonathan
daveh@cbmvax.commodore.com (Dave Haynie) (02/27/91)
In article <5345@acorn.co.uk> jroach@acorn.co.uk (Jonathan Roach) writes: >In article <1991Feb13.161140.7781@vax1.tcd.ie> hughesmp@vax1.tcd.ie writes: >>On the Amiga, you >>can have up to 5 bitplanes and 4 channels of music going, without impinging >>on the speed of the machine at all. >which is actually not true. As I understand it the Amiga has the screen and >DMA buses separated such that memory expansion beyond a certain point can't >be DMAed, but doesn't have its bandwidth swallowed by DMA either, thus >enabling the CPU to run at full speed in that area. If the CPU is running in >the DMAable area, then its speed will be significantly hit as it contends >for the memory's time with the screen and sound. That's essentially true. Everything governed by the Amiga custom chips is lock-stepped to the video cycle. Video memory runs two cycles for each single CPU cycle. Resources with their own dedicated DMA slots, such as audio and floppy disk, never contend with the CPU or any other resource. Video display fetch, blitter, and video coprocessor activity, on the other hand, is dynamically assigned. Video display fetch can replace sprite fetch cycles, thus eliminating sprites in return for a larger display. It can also displace CPU access, in return for a deeper display. The CPU can run free out of "Fast" memory, which is on its own bus and these days many times faster than video memory anyway, but the CPU can stall in access to custom chip memory in certain cases, which can degrade system performance. >--Jonathan -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "What works for me might work for you" -Jimmy Buffett