68k AGA AROS + UAE => winner!

[whoosh777]

bloodline wrote:
@whoosh777

I'm glad you finally had a chance to play with AROS :-)

Cybergraphics is present and correct. You would have noticed that the AROS graphics are either 65536 or 16.8 million colours (ie true colour) by default. That is why the icons can be very colourful.

is the default WB screen 16.8 million or 65536?
new to such things I dont know the difference,

I had another session today, my A1200 is taking a
trillion years to copy the dates over from the
fried partition so I disconnected it from the VGA
and left it chugging away and had another try with AROS,

hence this reply is via Internet Explorer,
ASAP I want to start browsing via IBrowse,


I found many new things this time, eg the text editor
which has exactly the features I want and does
them better than Memacs: search, search + replace,
tabs remaining as tabs and most importantly bracket alignment:

ie if I type:

tab tab { return
the cursor is aligned with the {, this feature
is vital for the way I write c,

with Memacs I can configure it to do this via
numeric return, but with yours I can use either  
return which is much more convenient,

I found so much further stuff this time that
I now think it is very nearly mature,

so I think it can take off without backwards 68k
compatibility,

last night when I tried it out, somehow I didnt
find all the directories,

I still havent found gcc on it, though I found
the includes and gcc libraries, you have a lot
of gcc stuff including libjpeg,

I noticed you have libbz2.a and bzip2, otherwise
I would have ported those, on this machine
it could port instantly. Though something that
ports painlessly on one system may be a major
issue on another,

jpeg is very very portable so it should port to
everywhere very straightforwardly,

If you get a Nvidia (ie GeForce) graphics card you will notice a massive speed up if you select "NVIDIA" at the boot options.

PCWorld had this for £99, is that a good price?

what is the full product name?

Is it A1 and Pegasos2 compatible?

Nvidia vs Radeon? will you eventually have Radeon support?
is it worth me waiting?

If you press Left-Win + Right-Win and Ctrl keys together AROS will reset (this avoids using the BIOS, so allows for a quicker reset).

ok, it was a usage-problem and not a bug,
I take it thats the left control key?

Is there any way I can boot to Windows XP with the
AROS CD still in the drive?

AROS can only read Amiga hard drives at the moment, so it can't see your Windows Hard drive. We need a FAT32/NTFS file system driver in order to read the drive.

can I reconnect my existing SCSI FFS drives to
my new PC SCSI interface and use them AS-IS?

Is there a risk factor as with WinUAE or is it
totally safe?

If you take out the Windows Hard Drive and put a blank drive in there, AROS can format the drive to the Amiga format and you can install AROS onto it.

You are saying that I shouldnt install AROS to this
current internal drive?

I want to try and only use external drives, so I can
selectively switch the power off as a virus precaution,

can I install AROS to some such external drive?
what is the best type of external drive to get?
(low cost + high speed),

Once you get a chance to play with the AROS applications and demos in the "Extras" dir of your AROS CD you will see why we are against a slower "big endien" x86 AROS :-) Once you get a taste of Raw CPU speed... you just want more :-D

It would give you parity with Windows XP,
probably you will even overtake Windows XP for speed,

Its certainly now the fastest Amiga in existence for
the home user, and just as fast as Windows XP,

furthermore its faster than all Macs,
hey everyone I overtook the Macs for under £300,
gloat, gloat, gloat, he he he, :-D

all those debates about Mac vanish,

2 questions on little-endian x86 AROS:

1. Have you a version that runs above Windows?
2. Have you a version of UAE that runs above
either even if its not integrated?

because I may then use that instead of WinUAE
for my 68k environment,

I have some really useful things which can only be
run in 68k,

I tried out some of the Extras programs which looked
very impressive, some of the Windowing is just as good
as Windows XP,

would it be possible to reintroduce an OS1.2 click to back
gadget? maybe via some Prefs program for standard gadgets,
I never liked having to click twice to move an  
in between window out of view on OS3,

I noticed your shell has tab completion via requester
 exactly the way I want it, is the shell King-con or
have you reimplemented it from scratch??

I didnt check whether you've fixed the square bracket
problem on King-Con, on King con if there are square
brackets in the shell output, if you scroll back to
them they vanish! Thats why I use () in the usage info
in my programs such as the above trackdisk.c,

I used the Prefs programs and managed to change the
background colour of the WB, I forget how I did it
but there were 2 colours with a gradient between these 2,
also you can rotate the direction of the gradient,
I removed the gradient by making the 2 colours the same,
as I dont like prettiness in my interfaces,

I like my interfaces to be rough, ready and functional,
thats why I like Memacs and the AROS editor,

The transparent window with a circle on it looked
really interesting, I want to see what the mechanism
for doing this, non rectangular windows should be now
possible,

Maybe I will write a graphics demo, just a bit of fun,
nothing major,

I want to learn what GPL is as well, is it
"graphics programming language" or what?

(not referring to the Gnu Public License also GPL)

[whoosh777]

@Piru,

the above trackdisk.c program for
moving between disk-binary-files and disks
is an example of what I call disposable-programming,

I encounter a problem that needs fixing real fast,
here it was I had to create a disk from a binary
to boot AROS,

so I didnt want to spend too long on this,

I write different grades of program eg ultra-safe,
safe, ok, unsafe, very unsafe,

this one was ok,

My A1200 system is 14Meg, a sector is a few kb at
most, so those 2 allocations will succeed,

if you are going to do something low level like
bypassing the file system to disk then you shouldnt
push a low memory system,

I think anyway that the OS produces a Ram disk full
requester before it returns failure,

Piru wrote:

Code: [Select]

#include <pragmas/exec_pragmas.h>
#ifdef LATTICE
#include <clib/exec_protos.h>
#endif
#include <clib/alib_protos.h>
#include <clib/exec_protos.h>
#include <clib/dos_protos.h>

Use:

Code: [Select]

#include
#include
#include
instead. More portable.

More portable than what?

my code runs on Lattice and gcc,
current machines are all gcc, so I think its as
portable as gcc is,

lots of cross platform c progs dont run on Lattice,
so a lot of programmers out there regard
gcc-compatibility as portability,

my code is as portable as theirs,

Code: [Select]

int ret = 20;

Use:
int ret = RETURN_FAIL;
later, ret = RETURN_OK; and ret = RETURN_FAIL;
[\quote]

0 and 20 are easier to remember than your symbolic
constants, I can never remember those symbolic constants
and what include contains them,

so to save 5 minutes of searching I use 0 and 20
which are totally correct and easier to remember,


[\quote]

Code: [Select]

TrackMP = CreatePort( 0 , 0 ) ;
if( TrackMP==0 ){ printf("CreatePort error\n"); goto cleanup ; }

TrackIO = (struct IOExtTD *)CreateExtIO( TrackMP , sizeof( struct IOExtTD ) ) ;

Use CreateMsgPort/DeleteMsgPort and CreateIORequest/DeleteIORequest. Why use amiga.lib when these routines are in exec.library ?

because the RKMs say so,

time is a resource, I dont have the 10 minutes
to search through the docs for some synonym which
may have subtly different usage,

CreateMsgPort isnt in the OS1 RKMs so its not
backwardly compatible,

Code: [Select]

WriteBuffer = AllocVec( SECTOR_SIZE , MEMF_CLEAR | MEMF_PUBLIC ) ;

geom = AllocVec( sizeof( struct DriveGeometry ) , MEMF_PUBLIC | MEMF_CLEAR ) ;

Allocation can fail. You MUST check for NULL result from AllocVec and act accordingly.

its a small one off allocation,

dont use low level disk progs in a low memory situation,

this program will only fail if you have a few kb in
your WB title bar, the memory overhead really is tiny,
try not to run progs when the title bar says 100000
bytes free memory,


this code was for someone trying to install AROS,
they are in a hurry to get on the PC, they wont be
 running major stuff on their A1200 if they are using
this,

its that bible story of the soldiers who drank
directly from the water, vs those who drank from
their hands,

mixing printf and PutStr / Flush

Don't mix stdio and dos.library calls. This won't work properly (output problems due to buffering). Either use only stdio functions or only dos.library functions.

but it runs ok in my compile,
the buffering issue may be irrelevant because of
the newline, if there's a newline the text
gets flushed out before the function returns (I think),

anyway if the sequencing was wrong, its not a big deal,
main thing is that the correct disk is created,

I expect the users to be intelligent enough to
know what

...1..00..byte..s...

means,

anyway POSIX says that i/o API calls should be
indivisible or something,

not my fault if someone flouts sensible indivisibility
and sequentiality to save a few nanoseconds,

printf anyway must be implemented via PutStr,
so if the output of printf and PutStr gets interleaved
as I have seen then someone has blundered and its not
me, so blame the people who made the OS or the compiler,
but dont blame me,

In fact, there is no need to use stdio in the program, just use dos.library and get rid of all stdio stuff. The code will never be portable anyway, so why use stdio?

I use stdio because its easier to remember,
AmigaOS can print integers but I can never remember the
API call, too much effort,

the program runs correctly,
live with the fact,

havent you got anything better to do with your time?

lots of major programs are written much worse than this,

IBrowse often crashes when I launch it if I use Genesis,
it doesnt crash if I use Miami, my Geek environment
 often crashes if I simultaneously access from another
shell the directory its looking at,

not always, but quite often,

Windows XP couldnt cope with the fact that I might not
have speakers connected,

When I booted up XP after AROS, Windows queried me about
the AROS CD: "what do you want Windows to do?"
"view a slide show of the images?"

next time I'll click yes!

If I write data from Memacs to another file
it read protects it, which causes all sorts of
problems eg if the partition becomes invalidated
then I cannot read that file to salvage it via
c:copy,

total pain,

the validation problem of AmigaOS disks,
thats not just a bug, thats a design flaw,

the validation problem is a bit like the
towers of Hanoi puzzle, when a new file is
entered into the system it has to be done
in such a way that its only truly integrated
via the last disk write, and if the write fails,
(eg crash or power off) then the file system
should be complete and correct but just missing
that file,

:you would achieve this by having duplicates of
certain datastructures, if the newer datastructure
is inconsistent you would use the older one,

a brute force way to achieve this is by
dividing the disk into 2 identical halves both
with FFS,

then you will always write a file firstly to the
first half and then again to the second half,

if either half is invalidated you would then use
the other half and correct the wrong half,

much more elegant mechanisms should be possible,
and Morphos say their system has fixed the problem,
and has other sensible features such as recursively
updating info up the file system tree,

its a typical architecture design problem,
some architects can design an airport or a city
whereas others dont know how to design a garden shed

Code: [Select]

DoIO( (struct IORequest *)TrackIO ) ;

IO can fail. You should implement retry (maybe 5 times), and if retry fail, report the error.

again I have done it exactly as in the RKM's,
I have never known DoIO to fail,

and please note that some of the OS calls
have bugged returns, if you pay attention to the
return, your prog will crash,

I have had major program malfunction by paying too
much attention to silly returns,

some AmigaOS API calls tell you how much data
the call processed and its wrong, the call itself
is fine just the return is wrong,

load an autodoc into your editor and do a search
for "bug", there are many,

so it actually pays to ignore the returns
of some of the unlikely failures, I even
have a feeling that DoIO()'s return may be
unreliable, but as I am connected to my PC
I cannot check the autodocs,


its silly to disconnect h/w while its busy,
dont remove the disk if you've just initiated
a binary write, its asking for trouble,

often when I code I patch the memory allocation via:

void *my_alloc( int size )
{
void *mem ;

while(1)
    {
    char c ;
    mem = AllocVec( size , MEMF_CLEAR );
    if( mem )break ;
    printf("couldnt allocate %d bytes,"
         " free some memory and type any key", size ) ;
    scanf("%c\n",&c ) ;
    }
return( mem ) ;
}

advantage is I dont have to do any error checking,
the error checking being implicit in the call,

that call can only return successfully, only way out
is to type control-C which has an inbuilt exit()
which frees all  C resources,

I wish it would also free all OS resources but it doesnt,
it could though,

the OS (or compiler) actually does this to some extent
via a Ram full message,

IMO error returns are a feature of bad design,

error returns should be an option not the default,

you only rarely want an error return eg to
check for existence of a file or memory space,

here the API should really provide an exists( filename) ;
call and a  largest_contiguous_memory(); call,

every resource API should provide existence() calls,

doing it via error messages could be inefficient,

I try to keep my mind focussed on higher issues
rather than this sort of nit-picking,

[Hammer]

How much of hte 970 transistor count is needed for legacy support? Virtually nothing.

Note that PowerPC 970 applies decode/cracking on PowerPC32 ISA before being executed to FRISC** core. Depending on the instructions, 9 stages are allocated for decoding.

**Further Reduced Instruction Set Computing (FRISC).

I'm not sure what sort of bus the Alpha was using then

A few rhetorical questions;

1. What was the clock speed of that particlar DEC Alpha at 1997 against the Pentium Pro?
2. What was the price differential between the two?
3. What was transistor count between DEC's Alpha and Intel's Pentium Pro?

Alpha 21264 EV6 was release in early 90s and it's an example of 3rd generation Alpha.

Note that, the aggressive OOO (out of order) scheme of the Alpha runs counter to the pure RISC ideal. Also note that the Alpha is a six-issue wide pipeline. There's no way for Intel's 'Pentium Pro' can match that (former)beast.

Incidentally, I'm not the one who started the PPC v Intel debate here

Well, you(and other person) opened some issues in relation to PPC and X86.

[Hammer]

The problem is, it's not a simple linear process where x86 instruction "X" is always decomposed into micro-op codes "a b c". The early stage of decode may work this way but once it has to start processing "a b c", it almost works like a mini compiler, looking to see what rename registers are/will become free, which instructions have dependencies etc. All this takes clock cycles - which is partially why modern x86 CPU's have such very long pipelines and "time of flight" for instructions.

Note that, the PowerPC 970 has 16 stages for integer type instructions, 17 stages for load/store instructions, 21 stages for floating-point instructions, and up to 25 stages for SIMD instructions.

"The depths of the 970’s pipelines vary greatly, depending on the instruction type. All the pipelines begin with nine fetch and decode stages. This large number of initial stages is extraordinary for a classic RISC architecture. It’s more reminiscent of today’s x86 processors".

Why not compare PowerPC 7447A @~1.5Ghz vs PowerPC 970 @~1.6Ghz?

With AMD's K8 processors, completed instructions can exit the pipeline without going thought the rest it. It's estimated that the K8 processors only has 20 stage pipelines (depending on how AMD count its pipelines i.e. pipeline comparison may be comparable with IBM’s way).    

Reference
1. IBM PowerPC 970

[Piru]

I think anyway that the OS produces a Ram disk full requester before it returns failure,

No. It will just crash due to your program writing to zeropage.

More portable than what?

More portable than:

#include
#ifdef LATTICE
#include
#endif
#include
#include
#include

Not to mention easier to remember and shorter to write.

proto/#?.h will work with all amiga and amigalike compilers, instead of just lattice and gcc. Also proto/#?.h will always use optimal features of compiler (inlines instead of stubs on gcc for example).

my code is as portable as theirs,

Don't add non-portability when it can be easily avoided.

Use CreateMsgPort/DeleteMsgPort and CreateIORequest/DeleteIORequest. Why use amiga.lib when these routines are in exec.library ?

because the RKMs say so,

time is a resource, I dont have the 10 minutes
to search through the docs for some synonym which
may have subtly different usage,

CreateMsgPort isnt in the OS1 RKMs so its not
backwardly compatible,

You already crash on OS1.x anyway. V36+ routines you use, without testing for V36+:
- exec/AllocVec
- exec/FreeVec
- dos/PutStr

its a small one off allocation,

dont use low level disk progs in a low memory situation,

These are bad excuses. Crashing under low mem situations is unforgivable. Just test for NULL result.

but it runs ok in my compile,

Another VERY bad excuse.

anyway POSIX says that i/o API calls should be indivisible or something,

Sure. AmigaOS is not POSIX.

printf anyway must be implemented via PutStr,

No. And it's not. Thus the possible problem when mixing stdio and dos.library IO.

the program runs correctly, live with the fact,

It doesn't.

havent you got anything better to do with your time?

Yes. I also try to help beginner programmers, and try to help programmers to avoid basic mistakes. Nothing personal here.

lots of major programs are written much worse than this,

Which is a shame and source of lots of trouble.

again I have done it exactly as in the RKM's

RKRMs are known to take shortcuts all over. You MUST check for I/O errors. Either check result from DoIO() or WaitIO(), or use io_Error field in the iorequest.

, I have never known DoIO to fail,

...Which doesn't mean it never won't. I/O can fail, usually due to bad medium (bad floppy in this case). It is important to tell user if his/her data was not properly read/written.

Load an autodoc into your editor and do a search
for "bug", there are many,

so it actually pays to ignore the returns of some of the unlikely failures, I even have a feeling that DoIO()'s return may be unreliable, but as I am connected to my PC I cannot check the autodocs,

AllocVec() and DoIO() return values are 100% reliable.

its silly to disconnect h/w while its busy, dont remove the disk if you've just initiated a binary write, its asking for trouble,

Which reminds me, your code fails to Inhibit() the filesystem. Anyone accessing the disk simultanously can get corrupt results, even corrupt the written data.

the OS (or compiler) actually does this to some extent via a Ram full message,

No it doesn't. OS will give you NULL ptr.

[bloodline]

is the default WB screen 16.8 million or 65536?
new to such things I dont know the difference,

The actual colour depth is chosen by you at the boot screen. The 16bit displays have 65536 colours, the 32bit (and 24bit) displays have 16.8 million colours.

There is also a VGA option that is just in case you don't have a modern graphics card, that only has 16 colours.

The Nvidia option defaults to 16bit, and the resolution can be adjusted using the screen mode prefs in the prefs dir.

I found so much further stuff this time that
I now think it is very nearly mature,

so I think it can take off without backwards 68k
compatibility,

We think so too.

I still havent found gcc on it, though I found
the includes and gcc libraries, you have a lot
of gcc stuff including libjpeg,

jpeg is very very portable so it should port to
everywhere very straightforwardly,

gcc is not included in the nightly build, at this time, as there are still issues with it.
All graphics manipulation should be done via the datatypes, so that all programs support all types of file. I belive we already have a jpeg.datatype.

If you get a Nvidia (ie GeForce) graphics card you will notice a massive speed up if you select "NVIDIA" at the boot options.


--------------------------------------------------------------------------------


PCWorld had this for £99, is that a good price?

what is the full product name?

Is it A1 and Pegasos2 compatible?

Nvidia vs Radeon? will you eventually have Radeon support?
is it worth me waiting?

Any Nvidia based card will do for AROS. Just get the best you can afford. I would probably not spend more than £150 on one.
The A1 and Pegasos, are compatible with current AGP specs as far as I know.

We have a couple of people working on Radeon drivers.

Is there any way I can boot to Windows XP with the
AROS CD still in the drive?

if you type e during the GRUB boot stages, and go to the boot console, typing "windows" (IIRC) will boot windows.

can I reconnect my existing SCSI FFS drives to
my new PC SCSI interface and use them AS-IS?

Is there a risk factor as with WinUAE or is it
totally safe?

AROS has no SCSI.device so it can't read SCSI drives. I would be surprised if you PC even had a SCSI connector. you are welcome to write a SCSI.device if you wish though.

You are saying that I shouldnt install AROS to this
current internal drive?

I want to try and only use external drives, so I can
selectively switch the power off as a virus precaution,

can I install AROS to some such external drive?
what is the best type of external drive to get?
(low cost + high speed),

Don't install AROS to your Windows hard drive. AROS will reformat it and turn it into an Amiga Formatted Hard drive.

When AROS gets USB support you will be able to install it onto a USB Memory stick (or USB hard drive) and boot from that. But AROS is still waiting USB drivers.

AROS should be able to read an FFS IDE drive fine.

2 questions on little-endian x86 AROS:

1. Have you a version that runs above Windows?
2. Have you a version of UAE that runs above
either even if its not integrated?

because I may then use that instead of WinUAE
for my 68k environment,

I have some really useful things which can only be
run in 68k,

There is not AROS Hosted for windows, yet. But it will come, people are looking into it.
UAE is included with the nightly build, but the GUI doesn't work yet as Adam hasn't linked it. You will also need to provide an Amiga ROM image as the "Real Amiga" build of AROS needs to be matured.

I tried out some of the Extras programs which looked
very impressive, some of the Windowing is just as good
as Windows XP,

would it be possible to reintroduce an OS1.2 click to back
gadget? maybe via some Prefs program for standard gadgets,
I never liked having to click twice to move an
in between window out of view on OS3,

if you select "Execute Command"  and type "opaque" , you will get solid windows :-) You can find the opaque commodity in the Tools dir.

The Click to back gadget was removed because it is redundant. But If you want on, you are welcome to add the code for one, that can be used in different window themes. I will make an OS1.x theme, but I had not planned to include a click to back gadget,

to get better window management, select "Execute Command"  and type "clicktofront double" , you will then be able to double click any where on the window to bring it to the front of the dispaly, then hitting the Depth gadget will drop the window in one click :-) You can find the clicktofront commodity in the Tools dir.

I noticed your shell has tab completion via requester
exactly the way I want it, is the shell King-con or
have you reimplemented it from scratch??

I didnt check whether you've fixed the square bracket
problem on King-Con, on King con if there are square
brackets in the shell output, if you scroll back to
them they vanish! Thats why I use () in the usage info
in my programs such as the above trackdisk.c,

KingCon is not used, all features are coded directly into Zune (AROS's version of MUI), and not as third party add on.

The transparent window with a circle on it looked
really interesting, I want to see what the mechanism
for doing this, non rectangular windows should be now
possible,

We have non regular window support, I think there is a demo called "roundwindow" somewhere.
The mechanism for this is built around the standard AmigaOS layers system. But AROS has enhanced the basicly layers abilities.

I want to learn what GPL is as well, is it
"graphics programming language" or what?

(not referring to the Gnu Public License also GPL)

I have no idea what GPL is (other than a Licence)

Also, I recommend you listen to Piru, he knows his stuff!

[whoosh777]

@Piru

I have implemented some but not all of your suggestions,

so if you revisit the earlier posting of trackdisk.c

you will see its been changed,


I have also improved it to read + write any binaries not just
PC disks, but you can feed in any unit of any
device eg trackdisk.device for
AmigaOS df0: df1: etc binaries, and the default is mfm.device for
MSDOS binaries,

some comments:

shell output is now entirely via dos.library,
I wish I hadnt bothered!:
this is a bit of a pain
because I have to use FPrintf to print integers and its nonstandard:
%ld instead of just %d for integers,

I decided to implement that for the hell of it to see how it went,
probably never again,

c's stdio is much easier to remember, it remains for reading + writing
to the binary file, fopen(), fread(), fwrite(), fclose() so easy
 and logical to remember and use,

but shell messages via dos.library,

c's stdio and memory routines are very well designed and thought through,
so whenever I can use them I prefer them, however dos.library has some
very useful things,

Now c's printf can check for control-C and then it quits,
however this would leave various AmigaOS resources unclosed,
I could fix this "properly" but its some effort,

so instead I have put in a simple control-E to exit via occasional poll
mechanism,
I didnt use control-C as that may be intercepted by a C compiler,
and I wasnt sure of a portable way of disconnecting control-C,

I do rapid control-E polling by checking the tasks SigRecvd flags, if present
I then do a Wait() which immediately clears the flag and returns,
the program then exits in a controlled way freeing all resources,

you are right about DoIO() error returns: if the disk is AmigaOS
and you read it as a PC disk this causes read + write errors
so I have used your suggestion of try 5 times and then give up,
control-E will also quit it before all 5 attempts have happened,

what was unusual was that the DoIO to read the geometry didnt fail,
maybe that only looks at the drive and not the medium,

it looks like the disk has to be formatted as AmigaOS before you can
read/write an AmigaOS binary, ditto PC, ditto etc,


I left the amiga.lib things in as they function fine,


This code could now be used on an arbitrary unit of an arbitrary
device provided it conforms to trackdisk.device structure,

so I think you can use the device name mentioned in the Devs:
entry for a mounted disk,

BEWARE though that this may produce a ginormous file and
writing may totally zap your drive, so use at your own risk,

:eg if you had a 4Gig disk, it would probably try creating a 4Gig
binary, ie its not just the partition but the entirety,


I used your idea mainly because it simplifies the
code,


I left 0 and 20 unchanged as its much easier to remember,
I find it tiresome continuously searching through endless docs
for unmemorable names and usages, this is why I like stdio,
"r" "w" "a" for read write and append is so easy to remember
rather than ACCESS_READ MODE_READWRITE, MODE_READ, etc,
its easy to use the wrong one if you rely on memory,

moral: strings are more portable and easier to remember than symbolic
constants,

I think the code is now watertight, in that it checks for failure
everywhere (except for eg Output() which is unlikely to fail),

:I did this partly because the code now deals with arbitrary disk
devices eg probably even eg unit 3 of 1230scsi.device,

and partly to stop you growling

[whoosh777]

@Karlos,

question for you:

How do you explain the huge speed of 68k FPUs?

68881 and 68882 are much faster than 68k
(I think, otherwise whats the point?)

but these FPUs are much more than CISC they are VCISC IYSWIM ie
very complicated instruction set chips

Sin, Cos, Tan, Log, etc, there is literally an entire app inside
those FPUs, they even do inverse-cos etc,

(calculators also do all that of course)

(sin x == x - x^3/3! + x^5/5! - x^7/7!... but dealing
with ieee specified errors and large x's eg sin(1000) must be some effort to do in h/w)

perhaps s/w done in h/w is the way to get huge speed,

One other note: 68030 and 68060 are both 50MHz but 68060 must
be 10 x as fast,

:I think this is entirely because of caches as both have almost
identical instruction sets and clock speeds,

thus registers + instruction structure is not the only factor for speed,
cache size + speed I think may be a much bigger factor,
Motorola were always a bit tight fisted with their caches,
eg 68020 has microscopic hardly-worth-it caches,

The point of huge caches is eg that a loop containing a huge switch
statement (as would occur in an emulator) would fit entirely in a cache
causing implausibly fast speeds. Your inner RISC thing is
in someways a cache-ROM IYSWIM, and if its done with special
faster than usual RAM it will probably be unbelievably fast,

[Piru]

Now c's printf can check for control-C and then it quits, however this would leave various AmigaOS resources unclosed, I could fix this "properly" but its some effort,

so instead I have put in a simple control-E to exit via occasional poll mechanism, I didnt use control-C as that may be intercepted by a C compiler, and I wasnt sure of a portable way of disconnecting control-C,

This indeed is a problem if you use stdio (output) routines. The only way to avoid this is to use compiler specific ways to disable CTRL-C check, or to drop stdio completely and only use AmigaOS libraries.

do rapid control-E polling by checking the tasks SigRecvd flags, if present I then do a Wait() which immediately clears the flag and returns

Code: [Select]

if (SetSignal(0, SIGBREAKF_CTRL_E) & SIGBREAKF_CTRL_E)
{
}

[whoosh777]

Piru wrote:

Now c's printf can check for control-C and then it quits, however this would leave various AmigaOS resources unclosed, I could fix this "properly" but its some effort,

so instead I have put in a simple control-E to exit via occasional poll mechanism, I didnt use control-C as that may be intercepted by a C compiler, and I wasnt sure of a portable way of disconnecting control-C,

This indeed is a problem if you use stdio (output) routines. The only way to avoid this is to use compiler specific ways to disable CTRL-C check, or to drop stdio completely and only use AmigaOS libraries.

I think it may be possible to hack around it in a
portable way: control C will cause a signal
(possibly SIGBREAK, I'm on the PC so I cant look it up)
 so you have to set up a signal handler which
eg sets a flag and then returns in the way
(which I cant remember offhand) which makes
the signal effectively ignored.

If you dont set up a signal handler then you get
the default handler which exits,

I got around the problem via ctrl-E,

note also that ixemul control-C is different from
noixemul control-C, ixemul's responds to control-C
immediately which is the correct way whereas noixemul
 and Lattice only notice it
when there's a call such as printf(),
I wish lattice hadnt bothered, Lattice does the
signal handler correctly but the signal waits for
eg a printf before it happens,

:the reason ixemul's approach is better is because
if a program is doing some damage you want it to
halt instantly and not wait till it echoes some text, eg the runaway printer problem,

I prefer c's stdio, AmigaOS is too complicated to
remember and nonstandard, eg %d is 16 bit,

I wondered why FPrintf("%d" ,.. was always printing 0,

one other thing I once thought I would speed up a
program which did huge numbers of small memory
allocations by replacing c's memory allocation
(calloc and free) by exec's (AllocMem with MEMF_CLEAR
and FreeMem), I found to my amazement that
the program was now slower,

so c's standard library can be very efficient,
eg if you want to copy an arbitrary size of memory
you need a very good reason to not use memcpy(),
and it deals correctly with overlapping memory,

one of the reasons I use c's stdio and memory
allocation is that *all* c resources are
automatically freed on program exit regardless of
where or how you exit:

main()
{
char *x = calloc( 100000 , 1 ) ;
FILE *fp = fopen( "xyz" , "w" ) ;
}

the memory allocation x and the file fp will automatically
be freed. If I use AmigaOS:

main()
{
char *x = AllocVec( 100000 , MEMF_CLEAR  ) ;
BPTR fh = Open( "xyz" , MODE_NEWFILE ) ;
}

the memory x would be lost from the system,
 and the file "xyz" would be unusable till I next boot,

One other thing dos.library has copied a lot of
 stuff from c eg FPrintf is clearly copied from c's
fprintf(),

do rapid control-E polling by checking the tasks SigRecvd flags, if present I then do a Wait() which immediately clears the flag and returns

Code: [Select]

if (SetSignal(0, SIGBREAKF_CTRL_E) & SIGBREAKF_CTRL_E)
{
}

ok, there's an obscure way to do it,
not sure I will remember it,

[Piru]

one other thing I once thought I would speed up a program which did huge numbers of small memory allocations by replacing c's memory allocation (calloc and free) by exec's (AllocMem with MEMF_CLEAR and FreeMem), I found to my amazement that the program was now slower,

Yes, typical malloc() implementation is faster than direct AllocMem(). Typical malloc() implementation is buffered, it grabs larger chunk from the memory at a time, and gives that back to caller in smaller chunks, much like memory pools of V39+.

so c's standard library can be very efficient, eg if you want to copy an arbitrary size of memory you need a very good reason to not use memcpy(), and it deals correctly with overlapping memory,

memcpy() does not deal with overlapping copies. memmove() and bcopy() do.

Depending on the libc implementation, CopyMem() can be several times faster, however.

Code: [Select]


if (SetSignal(0, SIGBREAKF_CTRL_E) & SIGBREAKF_CTRL_E)
{
}


ok, there's an obscure way to do it,

Yes, peeking task tc_SigRecvd is indeed obscure.

exec/SetSignal() or dos/CheckSignal() is the official way to do it. With CheckSignal() it would be:

Code: [Select]

if (CheckSignal(SIGBREAKF_CTRL_E) & SIGBREAKF_CTRL_E)
{
}

[whoosh777]

bloodline wrote:

is the default WB screen 16.8 million or 65536?
new to such things I dont know the difference,

The actual colour depth is chosen by you at the boot screen. The 16bit displays have 65536 colours, the 32bit (and 24bit) displays have 16.8 million colours.

There is also a VGA option that is just in case you don't have a modern graphics card, that only has 16 colours.

The Nvidia option defaults to 16bit, and the resolution can be adjusted using the screen mode prefs in the prefs dir.

I dont want 16 bit as its less colours than HAM8,
32 bit via byte per component with one extra byte
possibly unused is the best way to do graphics:

you can read/write an entire pixel in one read/write cycle,
ditto each component,

24 bit via byte per component is next best where
each component is via 1 read/write,

16 bit is no good because its 5 + 6 + 5 bits per
component ie its irregular, 15 bits is regular
however 15 and 16 bits are no good because
its slow to access components: shift + mask,

15 and 16 bit are good for reading an entire pixel,
but bad from the component POV,

I found so much further stuff this time that
I now think it is very nearly mature,

so I think it can take off without backwards 68k
compatibility,

We think so too.

you will need to sort out the browser though,
as you operate through the internet,

how difficult is it to implement the TCP/IP stack,
its one area I know nothing about,

I still havent found gcc on it, though I found
the includes and gcc libraries, you have a lot
of gcc stuff including libjpeg,

jpeg is very very portable so it should port to
everywhere very straightforwardly,

gcc is not included in the nightly build, at this time, as there are still issues with it.
All graphics manipulation should be done via the datatypes, so that all programs support all types of file. I belive we already have a jpeg.datatype.

darn! I have to read up about datatypes then,

will you have datatypes for sound then?
its a similar concept,

If you get a Nvidia (ie GeForce) graphics card you will notice a massive speed up if you select "NVIDIA" at the boot options.


--------------------------------------------------------------------------------


PCWorld had this for £99, is that a good price?

what is the full product name?

Is it A1 and Pegasos2 compatible?

Nvidia vs Radeon? will you eventually have Radeon support?
is it worth me waiting?

Any Nvidia based card will do for AROS. Just get the best you can afford. I would probably not spend more than £150 on one.
The A1 and Pegasos, are compatible with current AGP specs as far as I know.

We have a couple of people working on Radeon drivers.

I may wait a bit then, I have lots of figuring out
to do on this new machine,

Is there any way I can boot to Windows XP with the
AROS CD still in the drive?

if you type e during the GRUB boot stages, and go to the boot console, typing "windows" (IIRC) will boot windows.

this is useful info,
I will try this out,

can I reconnect my existing SCSI FFS drives to
my new PC SCSI interface and use them AS-IS?

Is there a risk factor as with WinUAE or is it
totally safe?

AROS has no SCSI.device so it can't read SCSI drives. I would be surprised if you PC even had a SCSI connector. you are welcome to write a SCSI.device if you wish though.

its probably too early for me to attempt a h/w device,
I've just landed on Mars, so I need to do simple minded
things first,

BTW I think scsi.device is quite simple from exec's POV,
all the work is in the 3rd party h/w: interface +
devices making life very easy for the
programmer and OS people,

its just essentially 2 arrays from exec's POV, command and data,  command will be eg 6, 10 or 12 bytes for SCSI-3

(I think, several years since I last looked at this)

exec only needs to know size of command and data (I think),

first the interface transmits command to the h/w,

which eg says "write 1000 bytes starting at position 100",

then the interface transmits "data" which will be the
1000 bytes, everything is transmitted independent of
endianess, most significant byte first ISTR,

thats it, "command" itself may be very complicated eg
for CD-R's, but that is the remote h/w's problem
not exec's,

the great thing about SCSI is it abstracts the
driver problem, its also backwardly and forwardly
compatible,

:you can run a SCSI-3 device from a SCSI-2 interface,
and vice versa, (I think!)

on my A1200 I can connect I think 12 SCSI devices
as I have 2 SCSI interfaces, Blizzard SCSI and
Squirrel SCSI,

you never run out of slots,

try connecting 12 IDE drives to an A1200!

and IDE is just Hard disks isnt it??

SCSI is Hard disks, printers, scanners, D-R, CD-RW, DVD-R, DVD-RW, etc,

:I think at least 10 device classes,

The engineering behind it is very complex,
eg you can have X--Y--Z--computer and switch off Y
while in use and the messages continue no probs
between X and the computer,

You are saying that I shouldnt install AROS to this
current internal drive?

I want to try and only use external drives, so I can
selectively switch the power off as a virus precaution,

can I install AROS to some such external drive?
what is the best type of external drive to get?
(low cost + high speed),

Don't install AROS to your Windows hard drive. AROS will reformat it and turn it into an Amiga Formatted Hard drive.

When AROS gets USB support you will be able to install it onto a USB Memory stick (or USB hard drive) and boot from that. But AROS is still waiting USB drivers.

AROS should be able to read an FFS IDE drive fine.

install it onto a Memory stick!

can you get external IDE's?

booting AROS from CD suggests AROS understands the CD,
how does it manage that?

2 questions on little-endian x86 AROS:

1. Have you a version that runs above Windows?
2. Have you a version of UAE that runs above
either even if its not integrated?

because I may then use that instead of WinUAE
for my 68k environment,

I have some really useful things which can only be
run in 68k,

There is not AROS Hosted for windows, yet. But it will come, people are looking into it.
UAE is included with the nightly build, but the GUI doesn't work yet as Adam hasn't linked it. You will also need to provide an Amiga ROM image as the "Real Amiga" build of AROS needs to be matured.

ok, I have to look into this UAE,
can it be used without the GUI?

I have a real Amiga for the ROM image,

I tried out some of the Extras programs which looked
very impressive, some of the Windowing is just as good
as Windows XP,

would it be possible to reintroduce an OS1.2 click to back
gadget? maybe via some Prefs program for standard gadgets,
I never liked having to click twice to move an
in between window out of view on OS3,

if you select "Execute Command"  and type "opaque" , you will get solid windows :-) You can find the opaque commodity in the Tools dir.

The Click to back gadget was removed because it is redundant. But If you want on, you are welcome to add the code for one, that can be used in different window themes. I will make an OS1.x theme, but I had not planned to include a click to back gadget,

to get better window management, select "Execute Command"  and type "clicktofront double" , you will then be able to double click any where on the window to bring it to the front of the dispaly, then hitting the Depth gadget will drop the window in one click :-) You can find the clicktofront commodity in the Tools dir.

sounds like I will be doing both of these,

on XP there is a problem: I bring a small window
to the foreground to see whats on it to copy into a big window,

problem is the moment I click on the big window to
activate it, it is brought to the front obscuring the
small window which I am trying to read,
takes quite a bit of effort to have the small window
in the foreground with the big window active so it
can be typed into,

I regard this as a design flaw, single clicking should
not depth arrange a window except if the click is on a
gadget,

I need to be able to activate a window without altering
its depth, so I need double-click-to-front,

I noticed your shell has tab completion via requester
exactly the way I want it, is the shell King-con or
have you reimplemented it from scratch??

I didnt check whether you've fixed the square bracket
problem on King-Con, on King con if there are square
brackets in the shell output, if you scroll back to
them they vanish! Thats why I use () in the usage info
in my programs such as the above trackdisk.c,

KingCon is not used, all features are coded directly into Zune (AROS's version of MUI), and not as third party add on.

MUI is 3rd party,

I found Zune very confusing, very difficult to find
what I want on it,

I prefer the other Prefs programs,
direct + uncluttered + self-explanatory + useful,

unpretentious with no bloat,

usually the Prefs settings I want are:

screen colour(s),
keyboard delay + repeat,
keyboard,
mouse speed,
screen fonts:
    (I like big fonts: topaz-8 on a 640 x 256 size,)
screen resolution (I find all fonts wrong on
     the very high resolutions so I may use a lower
     res eg 640 x 256 screen just to get the fonts
     right.)

This is a subjective point but I think
a Prefs programs name should be a self-descriptor,

so Prefs/Mouse and Prefs/Palette etc are exactly
what the name says,

eg Prefs/Serial is for setting the serial port,

but Prefs/Zune, who or what is Zune and why
should I want to change it?

why not

Prefs/ScrimbleZooplig
?

Zune sounds a bit pretentious,

In fact on my first trial of AROS, I tried all
sorts of Prefs progs but not Zune because
the name is a nondescriptor,

I think it would be much better to divide Zune into lots
of small Prefs programs eg Prefs/String_gadget,

somehow (probably from clicking the wrong buttons
on Zune) I got my icons text with white text in a
black outline, I wanted to change this to
usual black text with no outline,

I could not do it, I also was unable to refind
how to change the screen colour. I found it once
but never again and I went around in circles
through Zunes incomprehensible options,
eventually I got fed up and started looking at other
directories instead,

whats wrong with just having Prefs/Palette
or Prefs/Screencolour?

I'm sure Zune can do the above 2 things,
but I gave up trying to find how,

Zune is the only part of AROS which is more
confusing than Windows XP,

Is there an API or full documentation for the prefs?

maybe I will write a shell command:

set_screen_colour r g b

please dont tell me the screen colour is in a file
zune.prefs, oh no, it is isnt it?

In that case I give up!

The transparent window with a circle on it looked
really interesting, I want to see what the mechanism
for doing this, non rectangular windows should be now
possible,

We have non regular window support, I think there is a demo called "roundwindow" somewhere.
The mechanism for this is built around the standard AmigaOS layers system. But AROS has enhanced the basicly layers abilities.

I'll look out for this and try it out,

I can see that nonrectangular windows are going to be
a bit too much of an effort to code,

I think the transparency is a more practical feature
than nonrectangular windows,

I have to try out click to front on the
transparent region, see if I have to click on
the visible part,

[bloodline]

16bit is much better than HAM. HAM is slow, and is only suitable for stationary graphics. Each pixel gets two of it's colour components from the pixel to the left. This requires a massive amount of CPU time to work out.

The human eye is able to see twice as many Green Shades as Red shades so it makes sense to have the 5+6+5 RGB arrangement.
All camera have to have twice the number of Green cells as Red and Blue.
The TV signal devotes most of it's bandwidth to the Green component, and only a a tiny amount to the Blue component.
You eyes almost certainly can't see all 65536 colours that 16bit graphics can produce.

Remember that if you select a 16bit only the final dispaly is 16bit, the internal graphics operate at much higher bit depths. AROS actually uses 32bits for each colour component!


TCP/IP stacks are hard, but Wez is working on one.


Did you not use Datatypes on your Amiga?
The concept is simple. You write a music player program for example. You don't need to know anything about WAV's or MP3's or IFF's or OGG's, all you need to know is the datatype API.
Then the User can install an mp3.datatype or a wav.datatype etc, and your program can use them. No extra work on your part.


You seem hung up on SCSI. SCSI is a very old idea. Hard drives and CD/DVD drives all go on the IDE bus, all other devices go on the USB or the Firewire bus.
AROS can use CD/DVD drives, because AROS has an ide.device.
SCSI is dead, no normal computer equipment use it :-)

IDE's big limitation is the number of devices it can support, which in a normal computer is 4.
IDE is being replaced with S-ATA (which uses the same drivers as IDE, so AROS will support it) but supports more drivers and better speeds.

UAE is usable in AROS, even with out the GUI, you just need to set the configuration in the config text file. You can get the Amiga ROM image from your Amiga.


The thing I hate most about all GUI's is "auto rise", that is when you single click on a window and it is brought to the front of the display. I hate it. AROS does not do this, and I like it that way :-)

MUI is third party for AmigaOS, but Zune is not 3rd party for AROS. Zune is an integral part of AROS. Zune replaces intuition as the window manager (though Zune uses intuition).
It might seem hard to understand, but what you are seeing the whole Zune prefs, You will probably never need to use the Zune prefs (if you are happy with the AmigaOS3.1 look), but Zune gives you the option to change every aspect of the GUI. It allows you to chance how the GUI behaves and provieds advanced features like, list views, and special gadgets, help bubbles etc... if you want them, if not then just ignore it.
It also makes writing GUI's for programs much easier.
As for the name, Zune, I had a vote for a new one, but Zune was chosen, the public spoke, so we kept the name.
You set the screen colour/pattern/gradient/pitcture using the prefs program for that (the name escapes me). You do not use Zune Prefs for that.
Zune Prefs are not something you need to concern yourself with if you don't want to, zune manages the interface regardless (You can still use intuition if you wish, when programming, but for anything other than a simple app, you will be making work for yourself).

I think the transparency is a more practical feature
than nonrectangular windows,

I have to try out click to front on the
transparent region, see if I have to click on
the visible part,

Yes transparency is a more useful feature than nonregualr windows, but nonregular windows are useful for window themeing, some people like themed windows.
The transparent part of the window is not clickable, and events there will go through to the visible window/screen below. You should think of a trasparent region as not part of the window at all!

[Karlos]

Hammer wrote:
A few rhetorical questions;

1. What was the clock speed of that particlar DEC Alpha at 1997 against the Pentium Pro?

I already said. The alpha system there was a single processor set up at 266MHz. The Pentium-II machines brought in as 'upgrades' were 350MHz.

2. What was the price differential between the two?

Not entirely sure. Both systems were expensive, using SCSI, custom designed cards etc., but the alpha had been kicking around in the lab for several years already. The Pentium-II machines were brought in to replace it for 2 reasons:

1) Future versions of the software for which the machine was used were to be for x86 only, a move to sell it to a potentially larger audience (no doubt), so a shift to x86 was unavoidable. It was decided to make the shift early to lessen the upgrade hassles later.

2) The Pentium-II 350 machines brought in were expected to outclass the older Alpha @ 266.

Embarassingly for the senior IT technician who ordered the changes, the newer machines ran the existing x86 version of the software not only slower than the Alpha, they ran it at a speed that was only marginally greater than running the x86 version under FX32 on the alpha.

Pity they ain't still making them :-(

[Karlos]

@bloodline

Actually, the normal human eye can differentiate several million shades. Even with my colour blindess I can see that undithered 16-bit images are visibly considerably lower quality than 8-bits per gun. Many display cards often use 10-bit resolution (or higher) per gun for their DACs.

However, if you use dithering on 16-bit image data (when reducing down from 24/32-bit), the quality is dramatically improved.

@whoosh777

As bloodline says, HAM8 is slow as hell. It's only tha amiga's unique hardware arrangements that makes it even remotely feasable as a display mode at all. Even then its really only useful for showing still images (including frames of animation). It's not especially useful at all for 'realtime' imagery as generated by GUI's etc. Trust me, there's nothing it can visually do that can't be outclassed by a genuine 32-bit display running even on a fairly low end card.

[whoosh777]

@Hammer

>Well, you(and other person) opened some issues in relation to PPC and X86.
 
I think I touched a raw nerve by saying IBM dont know how to design CPUs,

Karlos pointed out that PowerPC is an IBM thing and not a Motorola thing,

in which case why has the Amiga taken on an IBM CPU???

@Piru

>No. It will just crash due to your program writing to zeropage.

this problem is easily fixed by:

1. moving the vbr away from the start of memory, as in fact appears to happen
if you run "cpu fastrom", Sysinfo shows where the VBR is,

2. the OS should then write protect the first page of memory after the
   pointer to ExecBase has been set up in position 4,

Now when my prog tries to read from disk or file to position 0 the MMU will
intercept this and a "first page write violation" requester should come up,
"click to remove task",

as all its reads begin at the start of the array zero problems would result,

its not my fault if the OS designers put the most critical
OS vectors right above 0,


BTW my program with device set to trackdisk.device creates uncompressed .adf
files, I found this by comparing its output to that of something from
www.aminet, in trying to set up WinUAE,


I have set up WinUAE now with AIAB, its absolutely fantastic and its
the identical ROM of my A1200 so its the real AmigaOS,

so the XP machine is like a huge graphics card accelerator for my ROM,

It has the exact same quality as the Windows XP environment,
as its basically an XP app, with emulated Picasso screen,
the speed tests were absolutely staggering: it filled an entire screen
with characters instantly, it was like rain in a thunderstorm,
it said equivalent to 1662 MHz 020 and 5234 MHz FPU,
100 x speedup of FPU!, 30 x speed up of CPU (I think)
361 MIPS, 673 MFlops, I havent run Sysinfo yet,


There are some font render bugs, I ran Memacs with a large font and it doesnt
quite erase a character if you type del, so you end up with a lot of
detritus in the bitmap,

There seem to be long delays from double clicking an icon till it runs,
but once it runs it moves like greased lightning,

The way WinUAE deals with hard-drives and floppies is they are
files on the Windows drive, so the hard drives on the WB seem to be
the subdirectories of a particular directory on XP,

thus to transfer Amiga files over you just copy them over on Windows into
those subdirectories,


the AIAB backdrop is visually more stunning than any of XP's also the
AIAB icons + icon text are actually better than XP's if you like that
type of icon,

the amount of graphics ram seems a bit limited though, its either 8 or 16 MB,
(I forget which),

AROS should be much faster still, they say power is an aphrodisiac,
I think once any developer starts coding on AROS they are going to become
totally hooked,


>Sure. AmigaOS is not POSIX.

I'm not advocating POSIX, gcc is largely
POSIX compliant, so AmigaOS is very nearly compliant,

what I meant was that indivisibility and sequentiality are crucial
design features, its very pedestrian if 2 i/o API calls of the same
Task violate this, ie Putstr(...) ; printf(...) ;

its no use blaming the programmer, both those calls dont reference any
resources so it should be safe to call them both,


>>printf anyway must be implemented via PutStr,

>No. And it's not. Thus the possible problem when mixing stdio and dos.library IO.

printf is dos.library IO:

I wrote a small simplified version of SnoopDOS, I give it any jump vector
and when I type control-E it tells me how often its been used,

this tells me:

SAS C 650 and 68k gcc *both* implement printf() via dos.library Write(),

probably printf(...) is implemented via fprintf( stdout , ...) which
in turn calls Write()

buffering should be inbuilt at a low level,
dos.library buffering sucks with titchy static buffers per drive,
(c:AddBuffers) buffers should be dynamically allocated at use time and
they should be big it makes a big difference to performance,

most drives most of the time are asleep so if you have 10 partitions
that is say 8 asleep buffers, its so wasteful,

it annoys me when people vent their anger at me for what is really an
architectural flaw, I will redirect that anger to where it rightfully
belongs though,

this is how I would implement PutStr() :

int PutStr( UBYTE *str )
{
int len ;

len = strlen( str ) ;
if( len==Write( Output() , str , len ) )return( 0 ) ;
else return( -1 ) ;
}

ooh that was difficult,

my prog tells me they havent used any of Write(), FPuts(), VFPrintf(),

>Which reminds me, your code fails to Inhibit() the filesystem.
>Anyone accessing the disk simultanously can get corrupt results,
>even corrupt the written data.


I suppose you take out an insurance policy every time you cross the road??

I used it quite painlessly to turn my WB3.0 floppy into an ADF file
and it boots quite fine to WinUAE, smooth as clockwork,

you should take a stroll down www.aminet sometime,

its "storm in a teacup" time,

some people get their kicks by being unconstructive,
but the constructive people always win in the long run,