68k AGA AROS + UAE => winner!

[whoosh777]

by Karlos on 2004/4/11 1:05:26

Quote:



>>Amithlon has a big endian Intel gcc on www.aminet.net,




>They have a 680x0 hosted gcc that produces x86 code for amithlon.

>AFAIK, there is no such thing as big endian x86.

not totally sure, I have this installed,

I created ram:xyz.c

extern int x ;

void f()
{
x = 0x12345678 ;
}

and now compiled it:

bin/i686be-amithlon-gcc -O2 -S ram:xyz.c -o ram:xyz.s

this generated x86 assembler:

 .file "xyz.c"
 .version "01.01"
gcc2_compiled.:
.text
 .align 4
.globl f
 .type  f,@function
f:
 bswap %ebp
 pushl %ebp
 bswap %ebp
 movl %esp,%ebp
 movl $2018915346,x
 movl %ebp,%esp
 popl %ebp
 bswap %ebp
 ret
.Lfe1:
 .size  f,.Lfe1-f
 .ident "GCC: (GNU) 2.95.3 20010315 (release/lcs-2002-02-08)"

not sure what its doing, it looks like neither endianess,
anyone understand x86 assembler?

$12345678 is 0001 0010 0011 0100 0101 0110 0111 1000 in binary,

the above code has

$2018915346 which is 0010 0000 0001 1000 1001 0001 0101 0011 0100 110

which looks totally different,

not sure whats going on,

bswap looks like some kind of byte reversal but what is
it reversing?

(BTW it looks like its using some 1-address code
which is a good move IMO)



I was under the impression that it generates big endian code,
I think its also available for other platforms such as PPC,

when I say big endian, what I mean is that
for 2-byte word and 4-byte long accesses it will reverse the
byte order before accessing ram:

say we have:

int *x;

x* = $12345678 ;


on big endian we would get:

byte[ x ] = $12 ;  byte[ x + 1 ] = $34 ; byte[ x+2] = $56 ; byte[ x+3]= $78 ;

(*A*)

on little endian (read carefully!):

byte[ x+3 ] = $12 ; byte[ x+2 ] = $34 ; byte[ x + 1 ] = $56 ; byte[ x ] = $78 ;

ie

byte[ x ] = $78 ; byte[ x + 1 ] = $56 ; byte[ x + 2 ] = $34 ; byte[ x + 3 ] = $12 ;

so to implement big endian on little endian:


x* = byte_reverse( $12345678 ) ; /* some CPUs may have an assembler instruction for this */

which would do

x* = $78563412 ;

ie

byte[ x ] = $12 ; byte[ x+1]=$34 ; byte[ x + 2 ] = $56 ; byte[ x + 3 ] = $78 ;

identical to what big endian would do see (*A*) above,

so as long as all memory accesses are intercepted with a byte reversal
by the compiler then Intel will behave as if it were big endian,


>>resolve all this via a big endian Intel gcc compile of AROS:

>>68k and x86 can then access identical OS data structures,




>Again, I have no idea what you mean by "big endian intel".

rewording will help:

((big-endian-ram)-emulation) gcc for Intel,

usual Intel CPU but a compiler that
intercepts all memory reads + writes by byte reversal:

for reads:

1.read memory
2.byte reverse it
3. use it,

for writes:

1. have data
2. byte reverse it
3. write it

>Thus 680x0 is big endian by definition but its a bit odd if you consider
>register-only byte/word/long operations - the effect is litte endian.
>That is, a byte/word operation always affects the LSB/LSW of the register.
>Do the same thing on a 32-bit memory operand and you find the MSB/MSW is affected:
>

>Imagine you have the value 0x01000001 in a memory address pointed to by (a0)
>
>move.l (a0), d0
>add.b #1, d0 ; least sig byte is affected
>move.l d0, a0
>
>gives 0x01000002
>
>is completely different behaviour to
>
>add.b #1, (a0) ; most sig byte is affected
>
>which gives
>
>0x02000001

I wasnt aware of this subtlety, usually inconsistencies such as this are
a sign of bad design,

with good design everything should be logically harmonious,

what they should have done is that the most significant register byte should
be affected and that eg

move.b   (a0),d0  

would load the number to the most significant byte of register d0,

I think you have located another design flaw of the 68k architecture,

maybe we should reimplement and improve 68k! eg:

fix this problem,
remove all the silly addressing modes,
remove pointless opcodes,
make all registers general purpose: where it currently says
 effective address=mode xxx register xxx
we replace this by
 effective address=mode xx register xxxx
(x = binary digit),
make exception frames store their size,
create huge caches,


the 68030 MMU OTOH is very well designed,
much better than the PPC MMU,


You know that PPC has a CPU flag that allows you to select whether
its big or little endian,


BTW regarding things which look fast but arent:

I was studying CPU registers + stack in supervisor mode
and other system things when I observed
that my A1200 supervisor stack pointer is at the top of chip ram ie
$200000,

so I thought I would speed it up by moving it to fast ram, I did this,
and then timed some graphics + disk intensive stuff and found it
made no difference at all!

[whoosh777]

by Karlos on 2004/4/12 1:22:32

>Dude, your posts are huge

apologies in advance then!

>Let's see.

>So, there is a compiler for amithlon that generates x86 code that does automatic
>byte reversal for operands during load/save to memory, thus giving a "big endian"
>data model that the 680x0 model is compatible with.

ok, so it is big endian, I wasnt totally sure but from what you say later it is,

>This makes some sense. However, this also means that you have totally killed
>the benefits of a CPU capable of memory operands for the majority of normal code.
>This is because you have to (for anything bigger than a byte) load the operand
>from memory to a register, swap it from its "big" endian representation to
>little endian, perform an operation on it, reverse it again and pump it back
>out to memory.

exactly,

but Intels have huge caches (I think), so its not actually pumping it out
to memory but to the cache,

thus it will be a lot faster than you think,

I believe Amithlon does exactly this, and Amithlon users are
quite happy with its speed: its up to the mark of the more discerning
users whereas PPC isnt,

Note that the above compiler is for Amithlon, which proves I think that
Amithlon uses big endian emulation of RAM,

What does Sysinfo on Amithlon say the speed is??

>Sound familiar? It should. You turned your "complex addressing mode" x86 into a
>load/store architecture.
>
>Unfortunately, x86 doesn't have the register count to make load/store based code
>effective. In fact, it is especially bad at it since it was (like the 680x0)
>designed to be able to have memory operands for most instructions.
>

if it has 8 general purpose registers that is quite sufficient,
you may be underestimating compilers, see later,

>Conversely, load/store code is the domain of CPUs like the PPC, where all
>operations are on registers and to compensate for lack of memory based operands,
>you have plenty of registers.

PPC has toooo many registers, the people who designed it are clueless about
what compilers can do,

you need to look at the assembler output of SAS C which is very high quality
via omd or the output of gcc -O2 -S something.c -o something.s
before jumping to any conclusions,


to compute an expression with M terms you only need approx log_2(M) registers,

so to compute an expression with 64 terms eg

(x1 + x2/(x3 - x4*x5) /(x6+x7+ (x8-(x9/x10))) ................ x64

you only need approx 6 registers regardless of expression complexity,

you dont need 64 registers thats for sure,

IMO CPUs should be designed by s/w people, with h/w engineers to implement,

if you put engineers in charge you end up with interesting and slow CPUs,

IBM dont know how to design CPUs otherwise why did they originally use Intel
and now use Motorolas PPC specification

(I dont know how they did their Mainframes)

>Basically, if what you say is true, the compiler generates code that is
>"big endian" data format compatible at the expense of a large amount of code
>required to wrap fairly simple operations. In other words, speed is secondary
>to compatibility.

never make assumptions about speed, code that looks fast is often slow
and vice versa,

always remember that Amithlon does exactly this,
hands up anyone who thinks Amithlon is slow? (IYSWIM),

Note that in the assembler output the byte reversal happened at compile time,
so there was no run time overhead,


>Can you imagine what any half complicated C expression compiles to where variables
>are loaded from ram each time?
>Instead of being able to perform arithmetic on a register using a memory operand,
> you have to load the memory operand to another register, byte swap it etc.

your description of what happens is correct, but, I need to put you in the
picture of what compilers do:

variables are usually local variables, (unless its badly written code),

lets say you have a C function with 30 local variables,

a naive C compiler would implement that via 30 stack cells, not necessarily a
bad thing as the stack is almost guaranteed to be in the cache,
the byte reversal problem would happen,

However a sophisticated C compiler would implement those 30 local variables
by eg 4 registers so no byte reversal directly necessary,

a given variable say x would be implemented via several registers eg d0 d1 and d2,
conversely a given register say d2 would implement maybe 10 variables,

eg:

f( int x )
{
int y,z, t ;

y = 5 ; z = y + x ; t = z + 2 ;
return( z ) ;
}

in this the return is z = y + x = 5 + x ,

say x is a register d1

a good compiler would implement this as:

move.l d1,d0
add.l #5,d0
rts

2 registers implementing 4 variables,

the variable count is actually irrelevant to the compiler,
it is only interested in the data processing complexity which in
real programs is very low,

real progs tend to do things like:

if( strcmp( x->name , y->name )==0 ){ x->count++ ; thing_free( y ) ; return ; }

:data movement,

here y is absorbed by x and removed,
the maths is trivial nameley increase x->count by 1,


as explained earlier for an arbitrary complexity expression with 1024 terms
a compiler only needs approx 10 registers (it may be 9 or 11 registers),

many 1024 term expressions can be done with much fewer registers eg:

x1 + x2 + x3 +....+x1024 only needs 2 registers:

move  x1,d0
move  x2,d1
add   d1,d0
move  x3,d1
add   d1,d0
move  x4,d1
add   d1,d0
.....
move x1024,d1
add  d1,d0

(**A**)

(on 68k you may only need 1 register:
move x1,d0
add  x2,d0
add  x3,d0
add  x4,d0
.......

In real code from real programs a lot of the time only 4 registers are necessary,

math expressions in real programs are usually very simple, most progs are
about data movement rather than maths,

with 32 registers you could do expressions with 4 billion terms which is
 an impractical ability,

every register requires circuitry eg 64 flip flops and it requires "wires"
from these flip flops to the ALU (arithmetic and logic unit),
also the instruction decode circuitry becomes bigger: to decipher
register 30 = 11110  requires circuitry x4 & x3 & x2 & x1 & ~(x0)
4 AND-gates and 1 NOT-gate, so you will need 32 * 4 = 128 AND-gates,
and probably 32 * 4 / 2 = 64 NOT-gates, 192 components to decode 1 register,

PPC 3 address-code has *3* registers => 3 * 192 = 576 logic gates just
for instruction decode,

now add in the 64 * 32 flip flops for the registers = 2048 flip flops,

so that is already 2624 components,

are you still sure you want 32 registers? I am *certain* I dont!


space is very precious and limited,


this leads to a bigger CPU ie longer wires => higher latency => slower,

it also eats up instruction bits: 32 registers => 5 bits per register,
which doubles instruction size for 3-address PPC or MIPS,


>You also now see why the 1-address code model ain't really so hot at all (sorry,
>but it's true. x86 architecture comes straight from pocket calculator era,
>hence the "accumulator" register )

real compiler code uses exactly the accumulator concept see the code fragment
above: there is no alternative,
computing a mathematical expression is entirely an accumulator-process:

x = (y+z)*t ; load y, add z, mul t, store x,

also its always like this,

this is why accumulator CPUs will be very fast,


>Back onto 68K
>
>I disagree that the 680x0 architecture is flawed by its "odd" register behaviour,
>but I threw it in purely to show that endianness is even more perculiuar than
>many people think. Things are the way they are for a reason. It would be a flaw
>if it wasn't well
> documented that the registers behave that way and you just assumed they behaved
> the same way as memory
>
> The 68K has one of the nicest architectures IMHO. Too bad motorola canned it.
>The memory indirect addressing modes are a bit pointless, but other than that it
>is a fine design.
 
a lot of 68k is very well designed,


> GPUs are just ace for this type of oddness. I know ones which have little
>endian 16-bit words but big endian 32-bit words etc.
>
> Yeah I know the PPC allows big/little endian operation. That's easy for
>load/store based architectures and it's not alone in being able to do it.
>There are ARM cores with the same ability.
 
MIPS also,

 
> As for the supervisor stack thing:
>
> 1) are you sure that the SSP wasnt already remapped somewhere else in fast ram
>buy your 030?
 
yes, translation control register TC=$03ffffff,
bit 31 needs to be 1 to enable the MMU, so the MMU is off,

if I run
CPU fastrom

then TC=$80f17540, bit 31 is now 1 => MMU on,


> 2) the system doesnt exactly spend long in supervisor mode anyway.
>Most OS functions do the bulk of their work in user mode.

difficult to know this except by trying it and timing it,
all h/w interrupts and exceptions will be in supervisor mode,

anyway I timed it and that tells me your comment 2) is true,

> PS: Your asm code for the x86 $2018915346 is a decimal literal that is
>0x78563412 in hex.
>
> Thats your 0x12345678 with the bytes reversed. If your gcc compiler does create
>"big endian" data, it makes sense that integer literals would get statically
>converted in this fashion - the variable "x" now contains 0x78563412 as far as
>the x86 is concerned
>, but a 680x0 would see it as 0x12345678, which is what you are indending.

great!

you've solved this riddle, I couldnt see it,

when I see $ I immediately think that signifies hexadecimal,

have you figured out what the bswap statements are for?

[whoosh777]

@Megol,

-----------





-----------

in the time it would take to reply to your time-wasting I could
write some significant code, so I wont even give you the time of day,

buy your own watch,

you are yet another person who confuses h/w architecture with s/w,

oh well I suppose if you throw enough buzz words into one sentence
maybe it will get you somewhere, anything is possible,

sorry! byee!


@Karlos

>When I said the "big endian" data emulation model was slow,
>I meant compared to normal x86 code - not that it will be slow compared
>to a real 680x0

fair enough,

it will be trickier for 68k emulation to share datastructures with the
host AROS,

:you could run it in its own screenspace without problems,


>becomes slow though because the byte swapping will have to
>
>That is to say, compile 2 programs, one running in the normal x86 little
>endian memory access fashion, and once compiled to support a big endian data
>model. The little endian version will have much less work to do at runtime
>(eg swapping data when loading a
>saving registers) and also the code will be optimal for it's
>"memory based operand" architecture.

probably true, but you need to actually generate both versions and time it
before concluding things,

so many times I have done analysis comparable to yours and then spent
an afternoon "speeding" up the code: but when I run it the original "slow" code
is faster,

nowadays I always backup code fully before attempting "speed ups",

the big endian will certainly be slower, but will it be significantly slower?
eg in the gcc generated x86 asm fragment there was no overhead as the
reversal happened at compile time,

>As for RISC style load/store chips, lots of registers arent bad at all.
>Your main point is that you cant use them effectively and instructions
>increase in size etc.
>
>On the usage front, I beg to differ - just study the PPC open ABI.
> Lots of important stuff (useful for the system) can stay in registers and you
>have lots of volatile registers for passing data to functions directly etc.

you only need 1 register to store the entire system stuff,

register r9 = pointer to struct { void *this, *that, *theother, *execbase, ... } ;

you want execbase in r3?:

move.l 12(r9),r3

1 asm instruction, nothing really,

(I am not talking here about CPU registers eg SRP and TC on 68030 which are
not general purpose registers),

on AmigaOS its quite practical to have no system stuff at all in registers,

(ok the library base goes into a6, but thats it),

all other system stuff can be obtained in one or 2 asm statements
on the rare occasions its needed,

give me a list of specific system things you want in individual registers?

>Stack based passing is only used there when there are more than
>8 parameters to pass to a function and that's not often.

register arguments dont necessarily speed things up:
the registers need to be backed up to the stack and later restored
(==2 extra stack references), so its only useful for heavily used registers,

but if a register is heavily used the overhead for backing up the original
contents becomes irrelevant

so actually stack based arguments are more practical and totally portable,

>Also, the 3 operand instructions allow for lots of optimisations
>with clever compilers. Don't assume gcc is the smartest.
>I can quite assure you it isnt.

SAS C is better than gcc,

3 operand optimisations are a false economy:

to do d0 + d1 + d2 + d3 via 3 address code and lots of registers:

add.l  d0,d1,d4
add.l  d2,d3,d5
add.l  d4,d5,d6

is 12 bytes of instructions and has a register cost of 3 (d4,d5,d6),

load  d0
add   d1
add   d2
add   d3

is a mere 4 bytes of instruction and has 0 register cost,
(register cost == 1 if you count the accumlator register),

that is an efficiency improvement of 3 and 3 respectively,


I do know what I am talking about despite Megols confused attempt,

I think I will argue my point till I am hoarse,


so my time is better spent coding which I am doing right now:
I am currently "improving" my 68k AmigaOS,


after todays posts I will be spending several hours coding to
modernise 68k AmigaOS, this is why I dont have the 1/2 hour to reply to Megol:
priorities,


your comments are constructive so I give it the 1/2 hour,


>Ultimately, it comes down to a system where memory accesses for
>data are rare, since a lot of stuff is created in registers,
>passed arounf in registers and ultimately never ends up in memory unless
>that's its final destination.

well written code will be implemented with minimal memory references,

often the major overhead is h/w i/o eg disks,

>This means memory/caches are hit less, stay valid for longer etc. and
>most memory accesses end up as bursts.

>>IBM dont know how to design CPUs otherwise why did they
>>originally use Intel and now use Motorolas PPC specification

>They don't? As I recall, Motorola used IBM's existing POWER
>(Performance Optimised With Enhanced RISC) architecture to create a desktop CPU,
>the PowerPC (with Apple as the cheif customer).
>It was basically a partnership in which IBM provided the architectua
>e, Motorola provided the fabrication processes and Apple sold them

you are right, Power is IBM's, for some reason I thought it was Motorola,

my point is valid though because Intel is faster,

"Performance Optimised With Enhanced RISC And Nowhere Near As Quick As Intel"

POWERANNAQAI

IBM good Intel bad Motorola hopeless,

>IBM currently make by far the best implementations of the PowerPC architecture,
>surpassing motorola by quite a margin.

true, and Intel is faster,

>On the design complexity front, the large register count is not a big deal.
>You do realise that modern x86 cores (since as far back as the Pentium2)
>use dozens of registers in shadow register files?
>Internally, the architecture is totally different from tha
> code you see in your assembler. Incoming x86 code is decomposed into smaller
>RISC like operations. The core executes these operations and makes use of a
>very large number of registers in the process.
 
but hidden registers are better than visible ones,

I would prefer to have an ultra rapid stack cache rather than lots of registers,

have 32 * 64 bytes of stack cache,

>Hence the objections you raise aren't really valid because x86 and PPC
>both use multi-operand instructions with lots of registers.
>It's just that you see it directly on the PPC and don't on the x86

but then your objections to x86 also arent valid because your criticism
was that x86 has to act on ram operands and now you tell me it doesnt,

>Finally, I dunno what bswap are for, but I expect they probably aren't
>endian conversion operations. I'm not too hot on x86 assembler
 
ok, I wont ask Megol because he's trouble,

>The trouble is, stimulating conversation though it has been,
>I genuinely don't feel I'm helping you get any closer that goal,
>so I'll settle for wishing you luck

fine,

[whoosh777]

@bloodline


>>Getting AROS to boot directly on an A1 sounds a very high priority project, so if it hasnt been completed I may join that project, it also sounds very interesting,


>>I understand AROS already runs above Linux on A1 so AROS is there already but not the way many people want,




>>It would certainly be a great thing to have AROS running Nativly on the A1.

>The PPC Linux hosted version of AROS is coming on rather quickly thanks to Markus,
>who is resolving some stack issues, and attempting to get the Graphics drivers
>to work.

for me the word Linux is underlined here,

can this Linux work be reused in a directly A1 booting AROS?

IMO the future of the Amiga will be entirely powered by 3rd party developers,


I still havent decided between A1 vs PC, I have decided on AROS though!

I feel if I buy a PC I am a turncoat or traitor, however if AROS directly
boots ie no Windows and its not Intel then maybe thats better than
using IBM PPC on the A1?

Its strange that IBM are now "good" and Intel are "bad",

Having read the book "Big Blue" IMO IBM are anything but good,

and there is no basis for thinking Intel are "bad": Intel never
did anything "bad",

MS OTOH IMO are bad,


Now PPC AROS has a very clean boot environment: portable + standard
via Openfirmware and eventually UBoot too,

How clean is PC AROS boot?

(the cleanness of the PPC AROS boot appeals to me),


Re PC AROS if I have understood you:

1. I buy a PC,
2. I download AROS,
3. I directly boot AROS?
4. I run UAE above AROS for full 68k compatibilty?

Is this correct?



In the UK have you any tips about buying a new PC?

Are the places like PCWorld, Comet, Staples, Dixons a good place to try
or should I go to specialist shops eg from computer mag adverts?



>>If you compile AROS with big endian Intel gcc then you can have seamless 68k + x86
>> AROS integration using some variant of my suggestion,

>>read + execute exceptions would toggle between emulated and nonemulated instructions,




>That's true, if we treated all memory access in AROS as Big Endien
>we could have the same 68k emulation method as OS4 and MorphOS use.
>But it has been decided that the performance penalty of running
>a little Endien CPU with Big Endian data was to significant
>(something like 30% penalty) that it was not worth it.

30% is nothing,

if a car goes by at 70mph and 10 minutes later another car goes by at 100mph
would you know the difference (I am talking about perceptions here),
(70mph being 30% slower than 100mph)

can you go both ways: ie have Big endian PC AROS and Little endian PC AROS,


>Besides if we use an integrated UAE we also get Hardware compatibility
>and improved stability so it's a benefit all round.

can you integrate UAE at the RAM level with little endian RAM?

if a 68k program accesses OS data structures ints and words at the byte level
or bytes at the word level the OS will get mangled

most programs wont do this so maybe you dont lose too much,

>>Would there be any point in creating your own AROS PPC platform?


>AROS IS the platform, what hardware you choose to run it on is up to you.
>Be that a Mac, a PC, a Pegasos, an A1 or a washing machine... it's up to you.

!

ok, the answer is no!

everyone says its not a big deal that Eyetech created the A1,
I wondered whether they could prove this by doing their own one,

>>>The Default Compiler is gcc.

>>this is the deciding factor,

>>which versions?

>>I hope you have gcc2.95.3-4 even though its not the most current,

>>is it a specifically AROS gcc or do you reuse generic ones?

>>Have you got 68k hosted cross compiler gcc's (PPC , Intel) for AROS?


>To compile AROS you have to use the latest gcc (3.x.x).
>The AROS native version of gcc is the latest.

do you keep the earlier ones?

>gcc supports the x86, the PPC and the 68k.
>this was a deciding factor in choosing it.
>Since AROS can be compiled for all of those CPUs.

gcc supports all modern CPUs in existence more or less,

certainly all CPUs that run Unix and Linux: there are many,

if you dont have gcc you have to have a very good excuse,
no other programs are compulsory though,


>>you realise that gcc is also an assembler, the moment a platform has gcc
>>it automatically has an assembler:


>Of course, other wise gcc wouldn't be able to output executable code.

not what I meant,
some compilers only have an internal assembler,

some Modula 3 compilers dont even have an internal assembler:
they convert Modula 3 progs to c which is then fed to gcc,

A Basic interpreter such as AmigaBasic I think doesnt have an assembler,
you can write + run progs with it though,

IMO 68k hosted cross compilers are very important,
imagine you have say:

big endian PC AROS, little endian PC AROS, Openfirmware AROS, UBoot AROS,
68k AROS,

ie 5 variants of AROS,

that would require 25 cross compilers to get code from any one AROS to any
other,


however if you have 68k hosted cross compilers then you only need 5
68k-hosted cross compilers,


this would greatly reduce the compiler maintainance overhead,

I think you need 2 68k hosted cross compiler gcc's
for PPC and PC AROS,

:people on all Amiga variants could then start generating AROS native progs,




>But the AROS distribution also includes the x86 assembler NASM,
>for those that want to just ply with x86 asm in AROS.

a real assembler is useful because it will conform with
3rd party assembler textbooks
:gcc assembler *doesnt* conform, it is totally nonstandard,
for me it has become my default 68k assembler though,

>It should be noted however, that due to the cross platform nature of AROS,
>the use of ASM is actively discouraged. One should use C at all times.
>The only exception is in some low level systems (noteably the exec.library)
>which need to access CPU specific features.

I agree with the policy, however some things can only be done via assembler,


the AROS developers themselves probably need to use asm
to implement low level things,


also to really understand a machine you need to at least understand assembler,

there are a lot of programmers who will only code in assembler,
give them an assembler and they will write fantastic programs,

and they will *never* use C or any other high level language,

you were talking about demo coders, you may need to provide full docs on
coding entirely on assembler on specific platforms if you want
fantastic demos written,


These demos will be unportable but fantastic, the demo coders soon move on
to writing games,


there is a real buzz from directly controlling hardware from asm statements,
switching supervisor stack to fastram was really satisfying even though it
just amounts to:

movea.l  new_stackpointer,a7

but done in supervisor mode, (its more complicated because you have to
also copy the exception stack frame over, I used 11 asm statements to do it
ending in rte,)

you cannot get this buzz from C. You are the controller with asm, with C
the controller is the compiler and the OS,

when you control via asm you start to develop a total
understanding of the system,



With the a500 and a600 there were literally *millions* of users who *never*
even used Workbench, they booted games directly,


this may be why games consoles are so popular,


Now you can also write C demos but its a totally different mindset,

C coding tends to lead to system programs and apps,

I am not into apps myself (except possibly developer apps) as
apps are either too entertaining (paint and songs) or too office-ish,
I want serious fun, not paint-cans and doh-ray-mee and accounts,
(company statistician speaking, pencil behind ear,),


assembler coding leads to games: creatures + music + graphics,


3D games probably needs C, though maybe just the engine needs to be done in C?


2D games is an inexhaustible genre,
my favourites are Lemmings, boulderdash, tetris,
(all of which could've been done in C),

good games are not actually about impressive graphics but about
engaging your mind in an interesting way,


IMO the best games are 2D, 3D games look impressive as an onlooker
but to actually play I find them a total disappointment: why not just do
something in the real world if you want 3D eg play basketball as a hobby,


learn to drive a real car, driving an arcade car is so sad, please grow up,
if you are going to be sad be sad properly!


computer 3D always sucks because you can literally see the computer slow down
and wince whenever something computationally complex happens,


:the real world never slows down (except in the circus in that film "Big Fish"),


if I could slow down the real world, I would smash a whole column of plates
and utilise the slowdown somehow,



>>so eg commercial AROS IBrowse can be closed source?

>Yes of course software can be closed source.

good, if it wasnt I would say "very interesting but no thank you",


industry is all about closed source design,

closed source => competition + money,
open source => bloat,

open source can be lean and mean but then it gets raided,


if you spend 1 month generating some nightmare cutting edge algorithms for
some API you may not want 3rd party developers to raid your work,


lets say you spent 1 year creating a cutting edge 3D graphics engine,
you could make some serious money from this, not just games:
you could sell it to film companies and make 7 digits of money,


what happens on gnu is developers cover their tracks by coating the
work with impenetrable layers of bloat,

probably same is true of Linux,

Amiga.org is closed source isnt it?


ISTR Mike Bouma paid a fat cheque for AmigaWorld.net, quite right too,
he had the money they had the IP, they made an exchange,
now he has the site, they have the money, everyones happy,


Mike really wanted amiga.org, had amiga.org been open source he would
have just downloaded it and created his own site to compete with amiga.org,

(this is public knowledge based on public discussions between Mike and Wayne),

I think Mike wasnt prepared to pay for Waynes asking price,

maybe Wayne should have rented it out!
(or rented out some forums),


>But it would then be up to the software vendor to provide support for
>the different CPU versions of their software (ie 68k, PPC and x86).
>This can lead to the situation where x86 AROS users get a program that PPC
> AROS users don't get, and Vice Versa.
 
but this is better than no program at all!

Shelves of stuff will only appear if its closed source,

a lot of www.aminet is closed source,

Note that if a 68k version is also done then it reaches all platforms via UAE,
so its just the native compile that would be lacking,

:this is a good reason for having a fully implemented 68k AROS,


>>iospirit announced they have abandoned OS4 development,
>>there was a link to this from AmigaWorld.net at the time of the
>> KMOS takeover,
>>
>>
>>ask iospirit if they will recompile + sell IBrowse to AROS,
>>
>>
>> they have nothing to lose by doing this,
>> they already have an up and running website for selling IBrowse,
 
>If there is demand for it, it will happen.
>Remember that AROS does not at this time have a fully functional TCP/IP stack.
>So general networking software is not a priority.


If AROS has fully integrated 68k compatibility you could use a
3rd party 68k TCP/IP stack until you have your own open source one written,


:you mustnt use Amiga co. OS binaries, but you are free to use 3rd party
68k OS binaries + libraries eg from www.aminet,

can you get the 3rd party TCP/IP stack people to recompile their code for you?
presumably its in OS3.1 c??

IBrowse and other commercial developers may not be aware that
closed source is permitted,


I didnt know and assumed it wasnt permitted except via 68k and UAE,
in fact I was dreading your reply to the question, luckily the answer is
exactly what I want,


you may need to target some publicity at potential commercial developers
about AROS allowing closed source + commercial programs,


AROS publicity tends to tell us that AROS is an open source reimplementation
of OS3.1, the phrase "closed source" is never mentioned,

to this day I dont even know if closed source commercial binaries
are allowed on Linux,

[whoosh777]

by Karlos on 2004/4/14 4:56:20

Hi,

Quote:


>>but then your objections to x86 also arent valid because your criticism was that x86 has to act on ram operands and now you tell me it doesnt


/*
No, that's not quite what I said. I meant the design paragdim of x86,
from the programmer perspective, is that it can use memory direct operands for
x86 level instructions, just like 680x0 does. So you do an add operation of a
memory opetand onto a registem
 or vice versa etc.
 
 It doesn't *have* to use menory operands (adding register to register,
for example is fine), but it doens't have a great deal of registers to spare,
so it makes sense to use memory operands.
 
 Up to the Pentium, this is how the core worked, but it was badly falling
behind newer RISC architectures in terms of performance.
The chip designers could see the advantage of load/store based superscalar CPUs,
but couldn't throw away their existing objecm
 code compatibility.
 
 So they did pretty much what motorola also did with the 68060, and later
cores simply used a lower level RISC style code that incoming x86 "micro-op"
instructions are dissasembled into.
 
 So, from your perspective, as a programmer, the x86 does use memory based
operands, and you can add a memory operand to your accumulator register.
*/

effectively you are saying it has an internal RISC emulator of the CISC code,

/*
 Now, in reality, that add instruction, during execution gets decomposed into a
micro-op load operation to fetch the ram operand, an add, a register file
write and so on.

 If you look at what x86 code is translated into at micro-op level, you see
something very much more like your PPC style code, with lots of register to
register operations, many registers and load/store for memory access.
*/

ok, but this may be exactly why Intel is faster than PPC,

you are regarding this mechanism as worse than PPC,
but I think it may be better than PPC,

I have to talk in terms of 68k which I understand, so pretend we have a
68k version of Intels mechanism ie a PPC inner core interpreting 68k binary,

the advantage is that the binary is typically twice as small which means we
double the instruction access speed,

that inner RISC core when it emulates will be using some inner ultra fast RAM,
ie not external real RAM, thus we combine the small code advantage of CISC
with the fast code execution of RISC,

if a 68k + PPC hybrid were done ie 68k binaries with inner PPC interpretation
of the 68k as with Intel then I think this could be considerably faster
than PPC,

/*
 However, as a programmer, you are not exposed to this level, but it does exist.
This is partly why most chip designers simply shrug off RISC v CISC comparisions
these days, since deep down most modern CPUs are virtually the same.
*/

outer RISC may be inferior to inner RISC + outer CISC,

/*
 Regarding 32 registers on PPC, I wrote plenty of code that makes use of it.
You are incorrect about the implicit register backup required on the stack for
 register based calls because the PPC open ABI defines those registers as volatile.
 Just like you nevm
r need to worry about saving d0/d1/a0/a1 for most 680x0 stuff (and similarly
cannot assume they survive a function call), roughly half the registers of the
PPC ABI are volatile and can be used for argument passing and temporary local
variables.
*/

but say there are 16 such registers then they will not survive across function
calls,

if those 16 registers contain info needed beyond the calls then you have to
back them up to another 16 registers or the stack,

I think the function call convention is actually quite a difficult problem,

the best answer is probably somewhere in between what I am saying and what
you are saying, eg maybe:

1. small number of volatile scratch registers,
2. the first function arguments in non-scratch registers: if function arguments
   are in scratch registers then those registers are no longer scratch!:
   
   scratch registers are short term breathing space,
   
3. further arguments to the stack,

eg on 68k:

a0,a1,d0,d1 as scratch,  and function arguments f(d2,a2,d3,a3)

if you have too many function arguments in registers you
run out of breathing space: the called function has to start using the
stack to free up registers for internal use,
also the calling function may already be using those registers for
something else so it has to back them up somewhere,


if you have too many scratch registers its wasteful,


So I concede that you need some register arguments but I differ with
68k AmigaOS in that I think they should be non scratch and not too many,
not too few either!

I also think you should have uniform register argument usage:

eg argument 1 is always d2,
in AmigaOS the usage is totally erratic eg: Open(d1,d2), FindTask(a1),
AllocSignal(d0), Enqueue(a0,a1)


I also differ in thinking that you only need 1 system variables register if any,
which would point to a structure containing the OS global variables,



/*
I wrote various matrix multiplication code for transforms on ppc (some of the
only hand asm I wrote) that is extremely fast since the entire transformation
matrix' terms remain in registers for any number of vertices processed. 12 floats
defining the buisness end of the matrix are held in volatile registers and you
even get single
cycle 4-operand multiply-add (register*register+register -> register) operations
to help when evaluating the matrix * vector stuff.

Literally, throught the loop the only stuff accessing memory was the instruction
stream, incoming vertices and outgoing transformed vertieces. And the loop, of
course pretty much stays in the cache

There is no way I could get say the 680x0 to get anywhere near the code efficiency
of it.
*/

I can believe that you generated optimal code relative to the PPC architecture,

if the CPU has lots of registers then you should make use of them if it makes
sense,


matrices would be very rapid with lots of registers,


to some extent optimal CPU design may depend on what you are using the
CPU for,


I think the design of an optimal FPU may be totally different from the
design of an optimal CPU,

FPU's are about real maths, whereas CPU's tend to be about
non maths stuff: addresses + flags + counts and such like,
flags are represented as numbers but they are not numbers but
booleans,


the maths involved in most of an OS is generally quite simple,
especially outside of graphics, most of an OS doesnt even require
floating point numbers,


the only use of floating points probably is for things like rendering
rescalable fonts,


/*
I know you don't see large register files as at all useful, but if you look at the
way present x86 processors actually work inside and the way they are going with
the 64-bit designs (IIRC, IA64 has 256 registers) I think you might be in a
minority.
*/

its survival of the fittest, just because some company or even all companies
makes some decision doesnt mean its correct,


most cars use petrol, but alcohol is sustainable and has no pollution:
alcohol turns into carbon dioxide and water, certainly no lead or fumes,
that carbon dioxide came from the atmosphere in the first place via
photosynthesis so its a clean cycle,


somewhere in South America they use alcohol powered cars,
and its quite viable: all you need is prairies filled with sugar cane
which you ferment, but there is probably 12 digit money politics
that makes sure we all use petrol,


I was talking about the fixed problem of what the PPC CPU does,
that a different architecture with the same technology could even be
4 x as fast,


FPUs are a totally different problem, eg vector processing in hardware
could make a huge difference:

have a very wide data bus and very wide vector registers,
then you can load a vector in one read cycle,

also 3D graphics is probably totally different from generic FPU use,
because in theory you could load an entire matrix in one read cycle,

in which case you only need 2 registers 1 for the matrix and one for
the vector,

if you have 32 bit 3 address instructions then you probably need
at least 16 opcodes == 4 bits which leaves 28 bits meaning that
512 registers is the maximum possible,


remember that vector maths is a very narrow slice of what computers are
used for thats why they dont use GPUs as CPUs!


I think we are starting to argue in circles,

[whoosh777]

@bloodline,

I spent several hours yesterday looking at Comet, Staples and PC World,

Comet have an entry-level system for £270 Intel based HP system,
but it uses a shared memory Intel graphics card,

£12.95 delivery charge,

128Meg ATI-Radeon 9xxx looks like its £100 at PC World,

Comet also do a £470 mid-level PC base unit also HP,
with 128 Meg ATI-Radeon 9xxx SE,
it has various things not in the £270 one eg writable DVD whereas
the £270 is read only for DVDs but writable for CDs,

all the systems in Staples seem expensive,

If I make a system from the parts via PCWorld its:
£52.86 for CPU, mobo £47.59, 128Meg RAM £22.33, 128 Meg ATI-Radeon £100,
case £35,

which adds up to £267.80 without s/w or OS,

unbundled MS OS is £160 I was told,

Fast SCSI-2 interface for external drives is 29.95 from PCWorld,

looking at real machines made me realise what an achievement it is
to get AROS to boot directly on PCs,

>>>>It would certainly be a great thing to have AROS running Nativly on the A1.

>>>The PPC Linux hosted version of AROS is coming on rather quickly thanks to Markus,
>>>who is resolving some stack issues, and attempting to get the Graphics drivers
>>>to work.

>for me the word Linux is underlined here,

>can this Linux work be reused in a directly A1 booting AROS?


/*
Yes, when you think of AROS Hosted, think of Linux as a Hardware abstraction layer.
 Running AROS on Linux can be thought of as the same as running AOS3.1 in UAE.

While AROS is running on Linux one can work out all the bugs and issues.
Then you can add the Firmware boot code and boot AROS on it's own.
*/

ok thats good, it means indirectly they are working on a direct boot,


/*
It should be noteed at 99.9% of the AROS source code is cross platform,
it's just the CPU specific/ASM stuff that needs reworking.
*/

as it should be!

/*/*
I feel if I buy a PC I am a turncoat or traitor, however if AROS directly
boots ie no Windows and its not Intel then maybe thats better than
using IBM PPC on the A1?

Its strange that IBM are now "good" and Intel are "bad",

Having read the book "Big Blue" IMO IBM are anything but good,

and there is no basis for thinking Intel are "bad": Intel never
did anything "bad",

MS OTOH IMO are bad,
*/*/


/*
To be honest, the "good"/"bad" lables are a redundant conceptual model.
Nothing is good or bad, things fall into two categories, "Usefull" and "Useless"
with respect to your requirements.
Windows for example is "Useless" if I want to use an OS that looks and feels
the way I want an OS to look and feel, but it is "Useful" is I want to run a
certain peice of software.
*/

an interesting viewpoint,

certainly I dont like at all the Windows interface,
to me it says "go away", whereas the Amiga interface says "FUN-time"!


The bundles provide a full set of s/w, but I am really intent on
bypassing MS.

Its quite insiduous how they force themselves on you the customer,
the default line of action is you end up with Windows and all the MS s/w,

that would be ok if they manufactured the h/w but they dont,
so its not right,


looking at machines I dont get what the big deal is about MS,

they have created a drab looking OS and the only interesting thing about it
I can see is that all h/w is geared to run on it,

Really h/w manufacturers should be forced to release c drivers for their
products so any OS can use any driver,


it is truly sinful that 3rd party h/w can be produced to only run on Windows,


/*
When choosing hardware you must first consider what your requirements are,
then choose what is useful and at the cheapest price. Ignore religious/political
issues like "brand" and "make", these things are unimportant when it comes to
technology.
*/

I am upset though that something so horrible as MS has a stranglehold,
why cant we have a quality monopoly,

/*/*
How clean is PC AROS boot?

(the cleanness of the PPC AROS boot appeals to me),


Re PC AROS if I have understood you:

1. I buy a PC,
2. I download AROS,
3. I directly boot AROS?
4. I run UAE above AROS for full 68k compatibilty?

Is this correct?

*/*/

/*
Yes, just download the AROS CD image, burn that to a CD-ROM,
then put that in the CD drive, turn the PC on...
AROS will boot and run by itself.
*/

sounds painless, so in theory I dont need MS?

now could I do this via the PCs hard disk instead of via CD-ROM?

ie if I download to the hard disk could I boot from that instead?

or if I download to an external SCSI hard drive on the Amiga and
then connect this to the PC via the interface I mentioned,

or is it only possible via CD?




/*
You will presented with an early startup menu allowing you to select
certain hardware options (good news if you have a Nvidia gfx card),
or you can ignore them and it will boot after 5 seconds.
*/

looks like I will get an ATI Radeon if I get a PC or use the
onboard shared graphics Intel card,


/*/*
In the UK have you any tips about buying a new PC?

Are the places like PCWorld, Comet, Staples, Dixons a good place to try
or should I go to specialist shops eg from computer mag adverts?
*/*/


/*
I would build the machine myself. There are plenty of shorps that sell PC parts
for good prices. http://www.dabs.com is a great UK website selling top
quality parts for a low price.
Don't forget that Black Troll sell complete PC's with AROS already
installed for around £160 or so (depending upon the exchange rate).
High Street stores will rip you off.
*/

I will look into these then,

I read this after making yesterdays visit to those shops,
£160 is almost half the price of what I saw,


will the £160 PC come with MS OS or MS s/w or is MS completely absent?

what sort of graphics card?

do you think the shop bundles are there to catch ignorant first timers??

/*/*
>That's true, if we treated all memory access in AROS as Big Endien
>we could have the same 68k emulation method as OS4 and MorphOS use.
>But it has been decided that the performance penalty of running
>a little Endien CPU with Big Endian data was to significant
>(something like 30% penalty) that it was not worth it.

30% is nothing,

if a car goes by at 70mph and 10 minutes later another car goes by at 100mph
would you know the difference (I am talking about perceptions here),
(70mph being 30% slower than 100mph)

can you go both ways: ie have Big endian PC AROS and Little endian PC AROS,
*/*/

/*
30% is far too much. When running AROS on a 3.066Ghz CPU, are you
really happy to write off nearly a whole 1Ghz (919.8Mhz) of performance?
*/

it may depend on your upbringing, I was trained to never put speed as the
top priority, ie robustness + portability + compatibility etc are
higher up the ladder than speed

eg a formula 1 car is very fast but I dont see many people driving them
on the roads!

/*
There is no point to cripple a CPU, AROS runs using the Native byte order
of the CPU, thus it is big endien on 68k and PPC and little Endien on the x86.
*/

I dont mind though and many people are happy with WinUAE and Amithlon which
are big endian on x86,

the be686-amithlon-gcc shows that people are even prepared to produce
big endian compilers for x86,

/*
You could build a Big Endien AROS for the x86 but that would be incompatible
with the faster Little Endian one.
*/

effectively it would be AROS on a different platform,

it would be very interesting to see what exactly the slow down is,
you believe its 30% but as it hasnt been done we dont know for sure

/*/*
Besides if we use an integrated UAE we also get Hardware compatibility
>and improved stability so it's a benefit all round.

can you integrate UAE at the RAM level with little endian RAM?

if a 68k program accesses OS data structures ints and words at the byte level
or bytes at the word level the OS will get mangled

most programs wont do this so maybe you dont lose too much,
*/*/


/*
The Idea for the integrated UAE is so that the 68k and the x86 do not share
Data structures.

But instead allow the two system to synchronise their data.
*/

ok, you've gone down that path,
its going to be much more work,

I suppose if you redirect each 68k jump vector to also call the
corresponding x86 jump vector or something,

will each x86 API call have to synchronise the 68k data structures?

/*
This will allow 68k programs to run in the same environment as the x86 programs.
The only down side is that 68k programs will not be able to call x86
functions and vice versa. This could be possible, but probably not worth it.
The UAE Emulator will be running a 68k version of AROS (specially designed to
synchronise with the x86 version).
*/

I suppose the open nature of AROS means someone else could
 create their own variant of AROS some other way, (I'm not volunteering just yet!)

whereas with AmigaOS we would all be stuck with the company's decision,

/*/*
everyone says its not a big deal that Eyetech created the A1,
I wondered whether they could prove this by doing their own one,
*/*/

/*
Anyone is able to sell Terrons.
I could put a little sticker on it if you like and sell it to you.
*/

see you are telling me its not a big deal,

how much would you sell it for?

/*/*
people on all Amiga variants could then start generating AROS native progs,
*/*/

/*
Since AROS is source code compatible with AmigaOS, it is easy to write your
program on your A1200 in C... and then take that source code to An AROS
machine and recompile for whatever CPU that is running.

gcc has a cross compiler, there is no probelm generating code for any
CPU from any CPU, providing you have the includes of course.
*/

your gcc outputs to multiple CPUs?

68k gcc only appears to output 68k series code,
but it sounds like your one outputs PPC and Intel code,

in which case there isnt an issue except for 68k people as it appears
you havent completed 68k Amiga AROS,

/*/*
computer 3D always sucks because you can literally see the computer slow down
and wince whenever something computationally complex happens,
*/*/

/*
I've guess you've not used a new 3D card then. I have yet to write a program
that causes my Radeon 9000 to slow down even with over 10000 objects
(using the DX7 interface).
*/

but as you throw more and more objects it must eventually slow down?

ie

for( i = 1 ; ; i++ ){ introduce_1000_objects() ; }

must eventually catch up with your CPU power,

how about 10000 explosions?


/*/*
Amiga.org is closed source isnt it?
*/*/


/*
No. Both Amiga.org and Amigaworld.net use xoops which is a great example of
opensource software. Aros-Exec.org also uses xoops.
*/

xoops is opensource but presumably the specific configuration is closed source??

/*/*
Note that if a 68k version is also done then it reaches all platforms via UAE,
so its just the native compile that would be lacking,

:this is a good reason for having a fully implemented 68k AROS,
*/*/

/*
We need the 68k AROS for the integrated UAE Emulator idea.
I also want to run AROS on my A1200. We do have a working 68k AROS,
but it needs to be adapted to boot the Amgia Hardwre.
At the moment it only boots the Palm PDA.
*/

reimplementing AmigaOS via the same custom chips!

you may need to study UAE to understand the custom chips!

(a bit like studying AROS to understand AmigaOS),

I hope you fix some of the existing bugs eg
AGA SetRGB32CM doesnt set the lower 4 bits of the blue component,

also blitter OS calls can fail horribly on bitmaps exceeding
1024 pixels width even though the h/w can cope with huge bitmaps,

according to the autodocs someone forget to set an AGNES big blit flag
they knew that in 1992 and havent yet fixed the bug!


/*/*
to this day I dont even know if closed source commercial binaries are
allowed on Linux,
*/*/


/*
It depends. If you link to a GPL library or use any GPL code,
then your software automatically becomes GPL.

If you link to an LGPL library then you program is not GPL or LGPL.

If you use any BSD code then that does does not cause your code to be BSD.

Simply check the licence of any software you are using to find out what you
can and can't do.
*/

so it can be done,


/*
AROS is covered by the APL, which is similar to LGPL. IF you use AROS source only
the code that you use must remain Opensource. The rest of your program is yours.

Licence issues are very complex.
*/

sounds a good license, some licenses are quite tight fisted!

[whoosh777]

@bloodline,

I decided to buy a cheapest possible high street pre-built system,
mainly to get Windows + a full set of s/w, even though I am trying
to bypass Windows:

it seems I can literally pull out and replace anything in this
eg motherboard or CPU and turn it into a totally different system,
having it pre-built will help me see how its put together, and supplies
me with OS + lots of s/w which would cost a bomb to buy directly,


anyway it has DVD ROM, CD writer, 256 Mb RAM, shared memory gfx card,
floppy drive, keyboard, mouse, lots of sockets eg USB, Ethernet,

I connected it up and installed the system,

now seemed the right time to visit the aros sites, so I visited
www.aros.org, (I think thats the URL),

First I tried your floppy image,

www.aminet.net progs for creating floppies from disk-images are
geared to 880K disks, so I quickly wrote a prog,
found I needed to use mfm.device to access PC1:, I copied the image,
AmigaOS now not recognizing the disk and it failed to boot the PC,
it left the disk running permanently, perhaps there is a bug,
anyway I gave up, I have attached the
prog at the end of this post in case you can see a bug,



Now I downloaded the CD image in about 1 hour, much faster than
via my A1200, (I have unlimited internet but not broadband),

FIRST PROBLEM:

my PC refuses to understand .tar.bz2,

I try the WindowsXP help search facility, tar and untar do *not* exist,

I try google, "MSDOS" and "tar", one link says:
"tar is a unix thing, if you have a tar archive its not for the PC!"

another link is "IT experts", they know about tar for PC, but I have
to subscribe for $9/month to know the answer,


I know how to use tar, but I want the binary,

eventually I give up, basically its currently impossible to extract your
compressed ISO image, all the Gigabytes of Windows XP are to no avail `cos
their search engine says so, XP understands music and videos but not your
compressed CD,

no probs for my A1200,


anyway I burned with no probs the renamed compressed ISO to CD-R on the PC,
then loaded this onto my A1200,


OS3.9 Unarc took too long on decompressing .bz2 so I halted it and tried
Geek:

bunzip2 -fkvL AROS_CD.tar.bz2

45? minutes to decompress to AROS_CD.tar,

Geeks tar was taking too long so I tried Unarc again,
Unarc did it within an hour,

BTW the tar compression is utterly pointless:

AROS_CD.tar.bz2: 17Meg,
AROS_CD.tar and AROS_CD are both about 52 meg, a tiny insignificant
compression,


I would tell you the exact number but Fryingpan (see later) fried my
partition containing the AROS CD binaries, so its deactivated temporarily
via early startup,

The only way to transfer this decompression is via a CD-R:


Next problem, I dont have any CD burning s/w for my A1200,
I tried the free version of MakeCD but every 20 seconds it comes up
with some kind of write error,


So I downloaded Fryingpan from www.aminet.net, the interface takes 10 years
to render, the docs are in png files, and I cannot get it to burn the CD-R,
it understands my drive, but no luck,

Net effect is I cannot install AROS,

If you can make available the full uncompressed CD I can then generate
it via the PC's s/w,

alternatively supply a link to tar and full instructions on how to
decompress this, because Geek things are forbidden territory to my
Windows XP system, probably because they are a Unix thing,


I noticed you have the 17 Meg doubly compressed CD and another 18Meg one,
so probably you have enough webspace to have the full uncompressed CD,


I think it will take 3 hours to download it, but then decompressing
the compressed one takes some 2 hours, so its space-time vs decompression-time,


please remove the .tar compression because it adds an extra hour and
achieves 0.000000000001 % compression improvement IYSWIM,


Anyway net effect is I dont have AROS installed:

my PC cannot decompress it, my Amiga can but I cannot transmit it between the
2 computers except by sending a 52Meg binmail on my A1200 which will
probably take 20 hours to transmit and ?? hours to upload into YAM,

my website is only 30Meg so its not big enough for me to upload it via the A1200
and download it via the PC,


unless you can point me to a free CD burner that will run on my SCSI system,


BTW the reason I want a SCSI interface is for my existing SCSI drives:
2 hard disks and my CDRW,


I looked also into WinUAE and found their webpage totally confusing,
and soon gave up. I have a real Amiga but didnt see any info on how to
capture the ROM, though I didnt look too thoroughly,

[whoosh777]

@NightShade737

/*
Right, so you don't buy a mainstream PC, but then talk about buying parts from
somewhere like Comet, Staples or PC-World. Thats like saving your foot then
cutting your leg off.
*/

I decided in the end that a cheapest possible high street machine is worth
it just for the official s/w, from then onwards I think I will not use those places,
as this is my first PC I decided the convenience was worth it,

BTW I transported it by taxi which was £4 cheaper than the shops transport charge,


PC-World charges £200 for ATI-Radeon 9800, but I saw somewhere on the
internet selling it for £150,

there seem to be many ATI-Radeon versions eg 7xxx, 9600, 9800,

which versions are good and A1 + Pegasos compatible and which arent?

(the earlier versions can be quite cheap, but are they useless?),

PC-World has an Invidia 128Meg (I think) Ge-force or something for £99,


/*
If you are going to build a machine, you use places like Komplett, eBuyer, Scan
and Dabs. Also if you are going for more hardcore parts,
possibly Overclock.co.uk and TekHeads. Going to high street crap places like
Comet and PCW guarentee you nothing than high prices and a dire selection
of parts that are nothing more than marketing gimicks
(i.e. GeForceFX 52XX cards etc).
*/

For further h/w I will look into these links,
can you give a list of graphics cards worth looking into?

where will I get a cheapest possible ATI-Radeon 9800?

£150 is the cheapest I have found, (inc VAT I think),

also where can I get a VGA switcher: ie to switch between my A1200 and PC,
the ones I saw in PC-World are some £80 to £100 which seems a bit expensive
for some wires and a switch, I dont care if it says Belkin or NASA on it,


/*
Oh, you may want a hard-drive for that PC too
*/

they supply a 40Gig one, Windows seems to be pre-installed on it:
no Windows CD,

there is a DVD with 6 Windows progs,

[whoosh777]

I forgot to attach the binary-image to MSDOS disk program,
is this program correct?


#include /* just includes */

#include

#include
#include
#include

int main( int argc , char **argv )
{
int ret = 20 , closer = 0 , SECTOR_SIZE , SECTOR_NUM , sector ;
struct MsgPort *TrackMP = 0 ;
struct IOExtTD *TrackIO = 0  ;
UBYTE *WriteBuffer = 0 ;
struct DriveGeometry *geom = 0 ;
FILE *fp = 0 ;

if( argc < 3 )
 {
 printf("%s binary_file unit [for_real]\n" , argv[0]) ;
 printf("eg\n%s ram:xys 1 1\n for PC1:" , argv[0] ) ;
 return( 20 ) ;
 }

fp = fopen( argv[ 1 ] , "r" ) ;
if( fp==0 ){ printf("couldnt open %s\n" , argv[ 1 ] ) ; return( 20 ) ; }

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

TrackIO = (struct IOExtTD *)CreateExtIO( TrackMP , sizeof( struct IOExtTD ) ) ;
if( TrackIO==0 ){ printf("CreateExtIO error\n"); goto cleanup ; }

if( OpenDevice( "mfm.device" , atoi( argv[ 2 ] )  , (struct IORequest *)TrackIO , 0 ) )
 {
 printf("failed to open drive %d\n" , atoi(argv[2]));
 closer = 0 ;
 goto cleanup ;
 }
else closer = 1 ;


geom = AllocVec( sizeof( struct DriveGeometry ) , MEMF_PUBLIC | MEMF_CLEAR ) ;
TrackIO->iotd_Req.io_Data = geom ;
TrackIO->iotd_Req.io_Command = TD_GETGEOMETRY ;
DoIO( (struct IORequest *)TrackIO ) ;

printf("sector size=%d, numsectors = %d\n" , geom->dg_SectorSize ,
  geom->dg_TotalSectors ) ;

SECTOR_SIZE = geom->dg_SectorSize ;

SECTOR_NUM = geom->dg_TotalSectors ;

printf("sectors/track = %d, numsectors = %d\n" , geom->dg_SectorSize ,
  geom->dg_TotalSectors ) ;

if( argc==3 )goto cleanup ;

/* bytes/sector, sectors/drive, cylinders, sectors/cylinder, surfaces,
sectors/track,
*/
/* only support: full-sector writes on sector boundaries */


WriteBuffer = AllocVec( SECTOR_SIZE , MEMF_CLEAR | MEMF_PUBLIC ) ;

for( sector = 0 ; sector < SECTOR_NUM ; sector++ )
 {
 PutStr(".") ; Flush( Output() ) ;

 fread( WriteBuffer , 1 , SECTOR_SIZE , fp ) ;
 
 TrackIO->iotd_Req.io_Length = SECTOR_SIZE ;
 
 TrackIO->iotd_Req.io_Data = WriteBuffer ;
 TrackIO->iotd_Req.io_Offset = SECTOR_SIZE * sector ;
 TrackIO->iotd_Req.io_Command = CMD_WRITE ;
 DoIO( (struct IORequest *)TrackIO ) ;
 }

ret = 0 ;

cleanup:
if( WriteBuffer ){ FreeVec( WriteBuffer ) ; WriteBuffer = 0 ; }
if( geom ){ FreeVec( geom ) ; geom = 0 ; }
if( closer ){ CloseDevice( (struct IORequest *)TrackIO ) ; }
if( TrackIO ){ DeleteExtIO( (struct IORequest *)TrackIO ) ; TrackIO = 0 ; }
if( TrackMP ){ DeletePort( TrackMP ) ; TrackMP = 0 ; }
if( fp ){ fclose( fp ) ; fp = 0 ; }
return( ret ) ;
}

[whoosh777]

@bloodline,

re: big vs little endian PC AROS,

perhaps a practical path is 2 versions thus:

1. Uncompromising little endian, *no* backward 68k compatibility,
   aimed as the long term version of AROS,

2. Big endian shared OS data structures version for full 68k compatibility,
   as a short term version of AROS in order to attract 68k owners,


A lot of people will not use AROS unless it has full 68k compatibility,
I know this because I mentioned about AROS booting on PCs to someone I know
who has his finger on the pulse of the scene and he underlined the fact
that AROS has limited 68k compatibility. When this guy raises an objection,
you have to listen, anyway I heard him,


usually we criticise people for being too short termist,
but here for the first time is an approach that maybe is too long termist,


The advantage of 2. is all it requires is a 68k emulator,
and a chipset emulator implemented via the AROS API,
ie no ROM,


simply subdivide RAM into 3: 1. x86 code area, 2. 68k code area, 3. other,
when x86 is active execute protect 2.,
when emulator is active read protect 1.,

the paging exceptions toggle between x86 and emulator,

this requires your OS datastructures to be at the byte level identical to
68k,

so its simply a matter of carefully slotting in a 68k emulator, and
also implementing the custom chipset via the AROS API,


/**
I spent several hours yesterday looking at Comet, Staples and PC World,
**/


/*
If it's your first PC it *might* be an idea to get a prebuilt system.
*/

worth it for the Windows stuff, the way they bundle Windows is a bit
like a drug pusher giving you some free drugs to begin with,

/*
But if you are going to do that, then still avoid the high streets.
If you really must go the high street route, then use something like
"Time Computers"... but if possible go to special)
st dealer.
*/

I visited Time, but they seemed a bit expensive and their systems
include eg monitor, possibly they are good value if you also need a monitor,


BTW I looked at the ATI-Radeon demo of a butterfly flying up to a chimpanzee,
when the salesman showed me that you could go to any viewpoint in the sequence
I realised what you meant,

things have moved on a lot since I last looked,

/*
You say you want to avoid M$ Windows. I say that it makes sense to at least have a
copy of 2000 or XP on your machine so you can run the lastest games,
and/or any important apps you might need.
*/

its a way out of compatibility problems, also it has been very revealing to
see just what MS are up to, more on this later,

/*
SCSI is pointless for any home user. Any modern drive
(Like the Western Digital's with thier 8meg caches) will be much cheaper and
offer similar performance. S-ATA is the new way to go so look for that if you can.
Don't forget that UAS2 and Firewire offer good Hard drive suppoer too,
though both are pricey.
*/

SCSI is just for my existing drives: I have 2 SCSI hard disks and 1 CDRW,
I like external drives because I can switch them off if I go on the internet
to prevent viruses,

I want to try and run my system entirely from external drives that way
internet drives will never be on at the same time as my programming drives,

to prevent viruses, I will switch off the one lot and switch on the internet
drive before connecting,

/*
Yes, It is testiment to Michal Shultz, Johan Grip et al,
hard work getting AROS booting the PC hardware.
Though the fact that PCs have a standard BIOS does help.
*/

backwards compatibility is their Achilles heel for alternative OS's?

for me so far this PC looks totally impenetrable,
I am getting a very clear picture now about what Windows really is,
and I think AmigaOS has a lot to offer,

At the moment I am alternating between the 2 systems by reconnecting just
my VGA socket and modem socket, so I can really know the truth now about
AGA A1200 vs current PC,
no more FUD possible because I now have both real things, real Amiga h/w and
real PC h/w

and its a current Windows XP machine,

/*
/*
/*
When choosing hardware you must first consider what your requirements are,
then choose what is useful and at the cheapest price. Ignore religious/political
issues like "brand" and "make", these things are unimportant when it comes to
technology.
*/
*/
*/

/*
/*
I am upset though that something so horrible as MS has a stranglehold,
why cant we have a quality monopoly,
*/
*/

/*
M$ Windows simply offers a standard way for software to talk to both
the user and the hardware. It does that job very well.
I it a shame hadware manufactures often only provide Windows drivers,
and never any source code. but Since windows *is* the standard)
this is little we can do about it, unless we offer a viable alternative for the user.
*/

the guy in PC World agreed that I could use Linux, but they dont bundle Linux,


/*
/*
Yes, just download the AROS CD image, burn that to a CD-ROM,
*/
*/

correction:

``Yes, just download the AROS CD doubly compressed image,
decompress it if you can *to* a PC, burn that to a CD-ROM,''

famous last words!

/*
then put that in the CD drive, turn the PC on...
AROS will boot and run by itself.
*/

not reached this stage yet,

/*
Wndows provides internet access and CD burning software, that alone makes it useful.
*/

I decided it was worth getting Windows, one should know what the competition is
up to, having tried out their system I dont think its a big deal,

IMO you could implement Windows XP in a few megabytes,
I've not seen the API but certainly the functionality is just
a few megs worth,


the OS3.9 CD provided quite comparable music + video viewing programs,
in fact I keep getting deja-vu trying out Windows XP,

when I begun the install I thought "this is OS1.2 MS AmigaBasic",

the install couldnt cope with the fact that I hadnt got any loudspeakers,

the text scrolling is really horrible,

King-Con's AGA shell history scrolling p*sses all over WindowsXP,

I wonder if maybe Windows XP was written in Microsoft's AmigaBasic??

every now and then I get a glimpse of the pre-Windows MSDOS black screen
with pulsating cusor, so they must have recycled some really ancient and
decrepit code,

My AGA Prefs totally outdo what this PC provides, this PC presents me
with about 3 screen resolutions all of which are wrong,

with AGA its near infinite, I believe also that AGA outdoes graphics cards
in such respects,

IMO AGA "high res" ie 640 x 256 screen is perfect, somehow if the res is
too high and there are too many colours I find I cannot focus on the
information.

despite all the graphics power if I change the screen resolution I can
literally see the subrectangles been drawn, slower than my AGA system,

its sufficiently slow that I think I may even be able to figure out what
rendering algorithm they are using, it looks really silly,


this machine is allegedly > 100 x as powerful as my A1200,
something doesnt add up,

please do not ever compare graphics card classic Amigas with AGA Amigas,
apart from the interleaved bitmaps AGA is actually quite fantastic,



Somehow if the interface is too "beautiful" then I cannot
focus my thoughts, so eg I much prefer fixed width fonts: because they
are bland I can focus on what is being said,

in the same way ugly politicians are preferable because
you can focus on the policies and not be distracted by
any charm element,

I wont get any programming done if I used some publishing quality
variable width fonts,

likewise if they sung the news it would be very difficult to focus on
the meaning,

the music player is fantastic sound quality, the sharpness (on my headphones)
felt like my eardrums were being etched, the Mozart was well chosen and well
performed (or is it Beethoven?), but one of the other 2 options has the
most humdrum lyrics ever, something on the level of
"I pared my toenails, then I stood up and looked at the light bulb",
at one point he sings about "breathing in", I will see if I can transcribe
the lyrics and maybe post them somewhere,

/*
To run AROS it needs to be either on a CD or on a floppy.
From the CD you can install it onto a hard drive and once there it can
boot without a Flopyp or CD
*/

I had no luck with the floppy, but there may be a bug in the program I wrote,
rather than debug it I thought I would try the CD path,

I think you need to supply or link to enough PC s/w to do the install,

the floppy binary doesnt seem worth compressing: compressed its 1.2 meg,
decompressed 1.4 meg (I think),

If you can bug fix my program maybe compile it and supply it for people
to install the floppy binary,

/*
AROS needs to be running in order to install itself on to a hard drive.
*/

ok, so its a 2 stage "bootstrap" install,

/*
The Black Troll machine is an AROS system, it does not come with Windows. It might
not be ideal for your needs.

The shop bundles do catch the first timers, but then they do make things very
painless for the first timer too.
*/

I think its only after you buy the machine that it dawns on you that
its not actually a computer but lots of units connected together,
and any of these units can be transplanted for low cost,

PC World told me I could buy a motherboard for a mere £47.59,
less than the CPU: £52.88,
so for less than £100 I can transplant these 2 items and have a totally
different machine,


eat your heart out Dr Frankenstein!

/***
You could build a Big Endien AROS for the x86 but that would be incompatible
with the faster Little Endian one.
***/

/**
effectively it would be AROS on a different platform,

it would be very interesting to see what exactly the slow down is,
you believe its 30% but as it hasnt been done we dont know for sure
**/

/*
It would be a different AROS platform, in the same way the PPC verison of AROS is.

Tests have confirmed that the slow down would be significant.
Amithlon has the advantage that even the lowest spec PC taking a
30% speed hit is still 10 times faster than the fastest real Amiga.
As Amithlon runs software meant for a real Amiga it's no great loss.
*/

/*
But how would you feel if you wrote a program and compiled it for Linux,
Windows and AROS. And the AROS version was 30% slower than the Windows and
Linux versions on the same machine? that sux, no one would bother with the
AROS version because it is crippl)
d. No speed penalty is worth it.
*/

very few people would measure it, the speed critical routines could
always be rewritten in little endian,

the idea of speed being a secondary issue is very much a Unix concept,
its certainly where I learnt the concept from, our department was
Unix through and through,

Unix programs are really bloated and inefficient,
the reason Unix is so widespread and successful is they put portability
and maintainability etc above speed decades ago,

c is also a Unix thing, the idea being that if you write an OS in c,
to port your OS all you have to do is port the c compiler,
we all take this for granted now but that was a radical innovation,
the fact that even AROS hinges on gcc proves this, and gcc is
many times more inefficient than Lattice C,


gcc is slow + totally portable,
Lattice C is very fast and produces faster binaries,
but AROS is using the slow compiler which produces the slow binaries,
all because someone put speed as a secondary issue,


we were taught that what really matters is asymptotic speed,
bubble sort is no good because it is an n-squared algorithm,
good algorithms are n-log-n,

dont worry about constant linear factors we were told again and again,
in lecture after lecture, dont worry even if the linear factor is 300%

Quicksort is said to be probably the fastest sorting algorithm on typical input
with average speed of n-log-n, however in the worst case it is n-squared,
so I wont use it, but a lot of people will and its in the standard c library
as qsort(),


:I will never use it because I believe in
robust algorithms == best worst case behaviour,

if you know a system is using a non robust algorithm
you could bring it to its knees by sending it the worst case situation,

some sorting algorithms grind to a halt or stack-overflow if you send
an already sorted list or a reverse sorted list,


viruses are all about worst case scenarios,

if a star-wars defence system algorithm has bad asymptotic behaviour
all the enemy has to do to defeat it is send a huge number of missiles
ie overload it with computational complexity,

send 2 batches of missiles, the first without warheads the second with,

:who knows it may even cause stack overflow!,
(computers are capable of quite awesome clangers),

or if for speed they are using a 16 bit register for number of incoming
missiles then send the missiles in batches of say 65536,
and it will think its 0 missiles causing 65536 missiles to get through,

(to play it safe exceed 65536 by some "safety" margin),


we were told that the US military likes networks where if you
blow up any node the full message still gets through intact!

they put this above speed, if you put speed topmost then
you could remove error detection and precompute
the path that a message would take which could be much faster,
but instead a message is broken up into pieces and the route is
recomputed afresh each time, the pieces could arrive in the wrong order,
so the receiver has to rearrange them into correct sequence => extra
space + time overhead,

/*
Also if the 68k was "inline" then the AROS would be less stable,
as bugs in old programs would be allowed to creep in and take down the OS.
If we run them in UAE, when they die, you can simily restart them.
The OS remains uncrashed.
*/

UAE will have its own WB screen or UAE + AROS will share the same WB screen?

/**
will each x86 API call have to synchronise the 68k data structures?
**/

/*
It would be up to the 68k verison working with UAE to make sure it
knows what the x86 OS is doing.

If you call a function in a library on the 68k side that function
will then call the coresponding function on the x86 side performaing
any byte order conversions if needed.
*/

probably it is doable in the sense that it may just require a few
minutes to patch each API call,


/***
This will allow 68k programs to run in the same environment as the x86 programs.
The only down side is that 68k programs will not be able to call x86
functions and vice versa. This could be possible, but probably not worth it.
The UAE Emulator will be running a 68k version of AROS (specially designed to
synchronise with the x86 version).
***/

/**
I suppose the open nature of AROS means someone else could
create their own variant of AROS some other way, (I'm not volunteering just yet!)

whereas with AmigaOS we would all be stuck with the company's decision,
**/

/*
You could, if you want, right now get the AROS sources and add in your own
"inline" 68k emulator and make a big endian verison of the x86 AROS.
The devs would even help you as best they can. That is the beauty of
Open source software.
*/

I may study some possibilities, I think at the moment its going to be
a challenge just to get "hello world" up and running on this PC,


this option for anyone at all to take AROS in their own direction
is a robustness feature of the AROS project,


eg with Amiga co. I feel they should have used Intel (or clone) and not PPC,
also I think they should have emulated OS3, released that and then begun on
new work OS4,

had it been AROS, Berndt would have gone down that path some years ago,


Eyetech being a h/w manufacturer strategically cannot go down
the Intel path because they would factor themselves out of the equation!



/****
everyone says its not a big deal that Eyetech created the A1,
I wondered whether they could prove this by doing their own one,
****/

/***
Anyone is able to sell Terrons.
I could put a little sticker on it if you like and sell it to you.
***/

/**
see you are telling me its not a big deal,
how much would you sell it for?
**/


/*
It was a brave market decision to push a PPC platform at that price,
but I guess Eyetech knew people would buy anything with an Amgia Sticker on it.

Sure I'll sell you one, hmmm how does $14 billion sound?
*/

how much profit do you think they make then per board?

is it just a matter of taking a standard PC and replacing the mobo by a Terron?


/**
but as you throw more and more objects it must eventually slow down?

ie

for( i = 1 ; ; i++ ){ introduce_1000_objects() ; }

must eventually catch up with your CPU power,

how about 10000 explosions?
**/


/*
A Modern graphics card has a GPU (a dedicated Processor) that is as powerfull as super computers were 10 years ago. When programming 3D with a modern Graphics Card (using DirectX or OpenGL, whatever) you left the GPU do all the hard stuff and left the CPU )
orry about the game logic.

You will have to see the performance to believe it.
*/

I saw the chimp + butterfly demo in TIME yesterday, so I think I understand now
what you meant,

each leaf in that jungle would take an A500 ages to render,


it made me think of ground-hog-day, the butterfly appears to repeatedly fly
along exactly the same path,


I remember when people would leave their A500 running through the night
to render a teapot + billiard ball and things, (not every night!),


/***
We need the 68k AROS for the integrated UAE Emulator idea.
I also want to run AROS on my A1200. We do have a working 68k AROS,
but it needs to be adapted to boot the Amgia Hardwre.
At the moment it only boots the Palm PDA.
***/

/**
reimplementing AmigaOS via the same custom chips!

you may need to study UAE to understand the custom chips!

(a bit like studying AROS to understand AmigaOS),

I hope you fix some of the existing bugs eg
AGA SetRGB32CM doesnt set the lower 4 bits of the blue component,

also blitter OS calls can fail horribly on bitmaps exceeding
1024 pixels width even though the h/w can cope with huge bitmaps,

according to the autodocs someone forget to set an AGNES big blit flag
they knew that in 1992 and havent yet fixed the bug!
**/

/*
Booting UAE would be much easier than a Rael Amiga, since one could bypass the
hardware bootstrap. Using UAE one might be able to figure out how the hardware
is initilised at power on.
*/

I think the early initialisation is documented at the back of some of the RKMs,

have a look in both the first and second edition RKMs,

Alternatively have a read of some of the assembler-games-writing tutorials
in the Amiga mags of long ago, the cover disks supplied assembler complete with
explanations,

/*
In the 68k version of AROS, one would not have the same bugs as AmigaOS,
unless there is specific reason to copy that bug.
*/

the graphics render bugs need fixing,

I think printer.device retains bugs for compatibility:
ISTR the autodocs discuss these bugs,

[whoosh777]

Edit: the source code has been improved via some but not all of
Pirus suggestions from a reply to this posting in the future!

:the program is also improved now to read + write any binaries
eg AmigaOS and PC,

The PC MSDOS disk binary writer is correct provided you create a binary
by the same method, just tested it out and it correctly copied a PC disk,

you can download the 68020 binary + source here:

http://www.whoosh777.pwp.blueyonder.co.uk/trackdisk.lha

[code]

/************** Usage: ***************/

run with no arguments or just 1 argument ? for usage info

convert disks to and from binary files, usage:

prog binary_file unit (w|r) (device)

w => write to disk read from file,
r=> read from disk write to file
default device==mfm.device for PC disks
trackdisk.device for AmigaOS disks,
use other devices at your own risk: BEWARE


examples:

trackdisk ram:xyz 0 r trackdisk.device ; create AmigaOS df0: binary ram:xyz
trackdisk ram:xyz 2 w trackdisk.device ; write  to AmigaOS df2: from binary ram:xyz
trackdisk ram:uvw 1 r                  ; create PC1: binary ram:uvw
trackdisk ram:uvw 1 r mfm.device       ; create PC1: binary ram:uvw
trackdisk ram:uvw 1 w mfm.device       ; write to PC1: from binary ram:uvw
trackdisk ram:uvw 1 w                  ; write to PC1: from binary ram:uvw


/*************************************/

the improved source with complete headers is:

#include
#include
#include
#include
#include

#include
#include
#include
#include
#include
#include
#include

extern struct ExecBase *SysBase ;

int main( int argc , char **argv )
{
struct Task *task = FindTask( 0 ) ;
int ret = 20 , read = 1 , write = 0 ,
 closer = 0 , SECTOR_SIZE , SECTOR_NUM , sector ;
unsigned SIGNAL = SIGBREAKF_CTRL_E ;
struct MsgPort *TrackMP = 0 ;
struct IOExtTD *TrackIO = 0  ;
UBYTE *WriteBuffer = 0 ;
struct DriveGeometry *geom = 0 ;
FILE *fp = 0 ; BPTR out = Output() ; char *device = "mfm.device" ;

if( argc < 3 )
 {
 FPrintf( out , "convert disks to and from binary files, usage:\n" ) ;
 FPrintf( out , "\nprog binary_file unit (w|r) (device)\n\n" ) ;
 FPrintf( out , "w => write to disk read from file,\n"
  "r=> read from disk write to file\n"
  "default device==mfm.device for PC disks\n"
  "trackdisk.device for AmigaOS disks,\n"
  "use other devices at your own risk: BEWARE\n"
  "\n\nexamples: \n\n"
 "%s ram:xyz 0 r trackdisk.device ; create AmigaOS df0: binary ram:xyz\n"
 "%s ram:xyz 2 w trackdisk.device ; write  to AmigaOS df2: from binary ram:xyz\n"
 "%s ram:uvw 1 r                  ; create PC1: binary ram:uvw\n"

 "%s ram:uvw 1 r mfm.device       ; create PC1: binary ram:uvw\n"
 "%s ram:uvw 1 w mfm.device       ; write to PC1: from binary ram:uvw\n"
 "%s ram:uvw 1 w                  ; write to PC1: from binary ram:uvw\n" ,

 argv[ 0 ] , argv[ 0 ] , argv[ 0 ] ,
 
 argv[ 0 ] , argv[ 0 ] , argv[ 0 ]
 
  ) ;
 return( 20 ) ;
 }

if( argc==3 || tolower(argv[ 3][0])=='w' )
 { read = 0 ; write = 1 ; fp = fopen( argv[ 1 ] , "r" ) ; }
else { read = 1 ; write = 0 ; fp = fopen( argv[ 1 ] , "w" ) ; }

if( argc >= 5 )device=argv[ 4 ] ;

if( fp==0 ){ FPrintf( out , "couldnt open %s\n" , argv[ 1 ] ) ; return( 20 ) ; }

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

TrackIO = (struct IOExtTD *)CreateExtIO( TrackMP , sizeof( struct IOExtTD ) ) ;
if( TrackIO==0 ){ FPrintf( out , "CreateExtIO error\n" ) ; goto cleanup ; }

if( OpenDevice( device , atoi( argv[ 2 ] )  , (struct IORequest *)TrackIO , 0 ) )
 {
 FPrintf( out , "failed to open drive\n" );
 goto cleanup ;
 }

closer = 1 ;

geom = AllocVec( sizeof( struct DriveGeometry ) , MEMF_PUBLIC | MEMF_CLEAR ) ;
if( geom==0 ){ FPrintf( out , "failed memory allocation\n"); goto cleanup ; }
 
TrackIO->iotd_Req.io_Data = geom ;
TrackIO->iotd_Req.io_Command = TD_GETGEOMETRY ;

if( DoIO( (struct IORequest *)TrackIO ) )
 { FPrintf( out , "i/o error, quitting\n" ) ; goto cleanup ; }

FPrintf( out , "sector size=%ld, numsectors = %ld\n" , geom->dg_SectorSize ,
  geom->dg_TotalSectors ) ;

SECTOR_SIZE = geom->dg_SectorSize ;

SECTOR_NUM = geom->dg_TotalSectors ;

FPrintf( out , "sectors/track = %ld, sectors/cylinder = %ld\n" ,
 geom->dg_TrackSectors , geom->dg_CylSectors ) ;

if( argc==3 ){ ret = 0 ; goto cleanup ; }

/* bytes/sector, sectors/drive, cylinders, sectors/cylinder, surfaces,
sectors/track,
*/
/* only support: full-sector writes on sector boundaries */


WriteBuffer = AllocVec( SECTOR_SIZE , MEMF_CLEAR | MEMF_PUBLIC ) ;
if( WriteBuffer==0 ){FPrintf( out , "memory allocation failed\n" ); goto cleanup ;}

PutStr( "type control-E to quit\n" ) ;

for( sector = 0 ; sector < SECTOR_NUM ; sector++ )
 {
 int amount ;
 
 if( task->tc_SigRecvd & SIGNAL )
  {
  Wait( SIGNAL ) ; /* no wait, to clear the signal */
  PutStr("\n***Break\n" ) ; Flush( out ) ;
  goto cleanup ;
  }
 
 PutStr(".") ; Flush( out ) ;

 amount = SECTOR_SIZE ;
 
 if( write )
  {
  amount = fread( WriteBuffer , 1 , SECTOR_SIZE , fp ) ;
  if( amount < SECTOR_SIZE )
   { ret = 20 ; FPrintf( out , "file ends early\n"); }
  if( amount==0 )break ;
  TrackIO->iotd_Req.io_Command = CMD_WRITE ;
  }
 else TrackIO->iotd_Req.io_Command = CMD_READ ;
 
 TrackIO->iotd_Req.io_Length = SECTOR_SIZE ;
 
 TrackIO->iotd_Req.io_Data = WriteBuffer ;
 TrackIO->iotd_Req.io_Offset = SECTOR_SIZE * sector ;

  {
  int err , count ;
  count = 0 ;
  while( 1 )
   {
   if( task->tc_SigRecvd & SIGNAL )
    {
    Wait( SIGNAL ) ; /* no wait, to clear the signal */
    PutStr("\n***Break\n" ) ; Flush( out ) ;
    goto cleanup ;
    }
 
   err = DoIO( (struct IORequest *)TrackIO ) ;
   if( err==0 )break ;
   if( err )FPrintf( out , "DoIO error %ld\n" , err ) ;
   count++ ;
   if(count==5){FPrintf( out , "I give up,\n" ) ; goto cleanup;}
   }
  }

 if( read )
  {
  amount = fwrite( WriteBuffer , 1 , SECTOR_SIZE , fp ) ;
  if( amount < SECTOR_SIZE )
   { FPrintf( out , "file error\n"); goto cleanup ; }
  }
 if( amount < SECTOR_SIZE )break ;
 }

ret = 0 ;

cleanup:

if( WriteBuffer ){ FreeVec( WriteBuffer ) ; WriteBuffer = 0 ; }
if( geom ){ FreeVec( geom ) ; geom = 0 ; }
if( closer ){ CloseDevice( (struct IORequest *)TrackIO ) ; }
if( TrackIO ){ DeleteExtIO( (struct IORequest *)TrackIO ) ; TrackIO = 0 ; }
if( TrackMP ){ DeletePort( TrackMP ) ; TrackMP = 0 ; }
if( fp ){ fclose( fp ) ; fp = 0 ; }
return( ret ) ;
}

[\code]

[whoosh777]

@Karlos

BTW you are in good company with your views, as they are
exactly what we were taught by our computing lecturers,

eg RISC better than CISC, many registers = good idea,

I went away believing that, but several years later
I bought a PC mag and it said that Intel CISC are the
fastest consumer CPUs,

and from my education I had thought "by now RISC such as
in MIPS will have totally superceded Intel",

so at that point I begun to doubt the conventional wisdom,

and then here in the Amiga forums we were told again and again
that Intel totally outdoes PPC RISC, PPC RISC is very similar to
MIPS RISC, this further underlined my loss-of-faith in
the conventional view,

As its off topic, if you wish to continue the discussion
perhaps we should continue via email but possibly not on a
daily basis as time is currently in very short supply!

/*
I sincerely suggest you read the PPC open ABI specification to get a
better understanding of how it works.
*/

where would I find this?, any URL?

/*
The issues you raise almost never occur due to how the ABI is layed out.
Stack based calling is rare (unless you have more than 8 integer/pointer part
meters). Those registers never need to be backed up before a call because the
compiler won't use them to hold anything that needs to survive a call.
*/

if you have a huge number of registers, then subject to that
you could have eg 100 scratch registers, 100 function argument registers,
100 internal function registers etc,

my question is whether you could achieve identical results with say just 16
registers via careful register usage, I think you can and that
 a lot of chip complexity clutter can be swept out, resulting in a much
faster chip,

BTW one area where register arguments is a bit awkward is with
variable argument functions such as printf() and AmigaOS taglist functions,

accessing the n-th argument becomes longer, because your initial 8 registers
will need extra code, the only way out is if the h/w allows you to treat
the registers as an array,

another subtlety is that in c I can do:

int f( int x ){ int *y = &x ; ... }

ie I can take the address of a function argument, its not a big deal but
it means you would have to copy x to a stack cell that now represents x,


here is a taglist fragment from a real program of mine, 26 arguments,
and this is quite typical of intuition.library taglist calls:


screen = OpenScreenTags
           (
           NULL ,
           SA_Interleaved , interleaved ,
           SA_DetailPen , detailpen ,
           SA_BlockPen , blockpen ,
           SA_Behind , TRUE ,
           SA_Depth , depth ,
           SA_Width , width ,
           SA_Height , height ,
           SA_Title , (int)title ,
           SA_ShowTitle , TRUE ,
           SA_AutoScroll , autoscroll ,  
           SA_Overscan , OSCAN_TEXT ,
           SA_DisplayID ,screenmode ,
           TAG_DONE
           ) ;
 

generally taglists are heavyweight API calls so the time factor is
irrelevant,

/*
When I look at well optimised PPC code generated from a good compiler,
I see very little stack usage, very little register backup etc.
*/

count also the register usage, ie how many different registers get used,
IMO this will often be much smaller than you imagine,
(depends how good the compiler is),

BTW IMO optimisation is a relic from the days when computers had
1kb of memory and were 10 instructions/second,

todays computers are so ridiculously fast that optimisation
is no longer the issue it once was,

I once wrote a simple file splitting program, ie

prog  file  1000

will split file into 2 files file1 and file2 where file1 is 1000 bytes
and file is the conctenation of the 2,

I did it via a  fputc( fgetc(in_fp) , out_fp ) ; loop,

it was very slow, so instead I replaced it with a

          amount = fread( array , 1 , 30000 , in_fp ) ;
          fread( array , 1 , amount , in_fp ) ;

loop, this caused a staggering speedup,

Now had I compiler-optimised the original program, it would have
made no difference,

ie the slowness was caused by a factor on a higher plane, way beyond
the scope of a compiler,

Often program speed is determined by what type of h/w i/o caching is used
(as above), or what memory-allocation mechanism is used,

:compiler optimising such programs (eg gcc -O2 -c prog.c -o prog.o)
will not speed it up, the slowness being on a higher plane,

this is why our lecturers were entirely right in telling us to always
focus on the algorithms and not on system-specifics such as computer language,

with disk i/o you can use your eyes and ears, if the prog makes the disk leds
light up smoothly with silence then the algorithm is good, but if the
led's blink rapidly and the drive makes a noise its a bad algorithm,

/*
All the examples you have posted so far tend to deal with linear code,
doing fairly simple arithmetic.

x = a + b * (c + (d*d)); etc.
*/

most of an OS is like this,
take the c: directory, most of the maths is quite trivial,

if you type:

c:list ram: lformat="%p%n" all

the program recursively calls Examine(), it will have the directory name
in a string and then concatenate each filename to this string,
which it then prints,

so the maths really is totally trivial, mainly + to determine stringlength,
its quite a bit of effort to write:
lots of trawling through the dos.library autodocs, my datesorter prog
involves this sort of code,

anyway most of an OS is conceptual rather than mathematical,
eg the concept of a Task doesnt involve maths, a task is a non
mathematical thing, the maths would be eg seeing if another task
has a high enough priority to pre-empt it,

eg if a waiting task is awoken by say control-C in its window,
the OS will see if its priority is sufficiently high to
immediately pre-empt the executing task,

Wait( SIGBREAKF_CTRL_C ) ;

/*
Chuck in function calls (some of which may be inlined),
multidimensional pointer dereferences (that may be used several times
in one expression), etc., and more and more volatile registers
becomes useful to hold temporaries that may be needed more than once
*/

vector maths I think may require totally different CPU architecture,

Oh BTW one thing I thought of is that probably the speed of 3D games
maybe is decided by the speed of the graphics card,

so maybe PPC 3D games and Intel 3D games will run at identical speeds?

maybe even A1200 + ATI-Radeon 9800 will be very impressive??

Graphics cards seem now to be the most expensive part of PCs,
£199 for ATI-Radeon, £80 for VGA switcher box, £53 for CPU,
£48 for mother-board, in PC World,

:puts things in perspective,

[whoosh777]

   
   
     Re: 68k AGA AROS + UAE => winner!
     
     by Karlos on 2004/4/17 17:07:17
     
     Quote:
     
/**    

  IMO you could implement Windows XP in a few megabytes,
  I've not seen the API but certainly the functionality is just a few megs worth,
**/    
     
     
/*
Tell it to Microsoft
     
The truth is
     
1) There's a vast amount of redundancy in windows.
There are literally dozens of different was a user can do the same thing.
*/

too many help options, which also makes it difficult to remember which help option led to some useful help,


/*
2) There's tons of functionality most people aren't aware of and wouldn't
neccessarily use even if they were. Loads of services and other features are
included that the average home user has no idea about.
*/

its an exercise in intimidation and dumbing down,

If you brought in a bulldozer and removed all the progs then
I think the few megs I mentioned would remain,

AmigActive magazine was quite capable of filling an entire CD with
huge amounts of interesting material, thats where I got my free MakeCD
from for example.

:I think any of their coverCD's would give Windows XP a good run for its money!


Windows also have taken much too much trouble in prettifying the interface,
I am much more interested in ease of use and what a prog does than
in the appearance,


/*
3) When updating windows resources,
*/

I havent got that far yet!

/*
it's extremely rare to find that a set
of .dll files or whatever are actually updated as it's not time/cost
effective for MS to bother. Most of the time, newer .dll files are simply added.
There's a lot of historicC
bloat alone that comes from this.
*/

probably I will understand this later,

it seems everything is going to be .xyz

.dll  .exe

/*
4) Most likely your preinstalled windows xp has system restore and other
features enabled. This is basically like having a copy of the
CD in a folder under your xp installlation and if something goes wrong,
you can restore the last working configuration.

In the end, it all adds up to one gargantuan behemoth
*/

annoying that they didnt give me an XP CD,


all the years of MS FUD are very rapidly caking off!

active mice pointers really irritate me, on my A1200 the mouse is totally passive
as you move it along nothing happens till you actively click,


(except those equally irritating help bubbles on some Amiga progs,
with MakeCD I had real difficulty rotating the options because the
help bubble was in the way and I couldnt get around it to the
rotator-thingy it described),


Its going to be really good fun finding out the truth about this system,

[whoosh777]

@that_punk_guy

Re: .tar.bz2 files.

/*
If I recall correctly, TAR is not intended to compress the contents,
it's a simple archiving format. The reason this is done is because you can only
bzip individual files.
*/

I wasnt aware of this, I never paid too much attention to the sizes before,

I only noticed it this time because of the hugeness,

on the Amiga the word "archive" has tended to be used synonymously with
the word "compressed",


/*
It's a "Unix thing" indeed,
*/

actually to be pedantic is it more of a Linux thing?

I say this because I had to port bzip2 myself to the Amiga as it wasnt
on Geekgadgets, I needed it for rpm which is Red hat,
it was the easiest port ever, I think it took 15 minutes to port on my
68030 A1200, a straight recompile,

rpm OTOH is a nightmare port (to classic 68k Amiga, for Linux it will
of course be a mere recompile),

my port of bzip2 is on the rpm.html page of my website,
and its there as a .tar.gz file (for reasons of self-referentiality!)

isnt gzip the Unix thing??


/*
but you can open then on Windows if you have WinRAR.
*/

thanks for the link, this may fix the problem,

/*
It's fully-functional shareware, not difficult to find.
*/

but I am a PC newbie!


/*
Try not to freak out too much.
*/

sorry!

I am really freaked out about DiskSalv though, using it to fix the
damage done by Fryingpan.lha: DiskSalv wiped out the bin directory
of my GeekGadgets,

I only discovered this when I attempted to use something in gg:bin/

luckily I dont trust DiskSalv and copied the entire partition to
another partition before attempting it,

:this backing up of the unwritable partition with 600 Meg of files took
 many many hours,

So I will have to copy all the wiped out stuff back via script,

I think I will never use DiskSalv again, how dare it and FryingPan
wipe out Geek, I wonder what other damage was done, the script I will use
will tell me,

luckily I also have 2 backups of all work directories, though a few weeks of work
is not backed up except backed up to another partition,

I remember the OS3.9 install overwrote everything on the partition,
 

[whoosh777]

@NightShade737

/*
You really need to be a LOT more specific.
You can't just say Radeon 9800, or even worse just GeForce.
The name GeForce has been given to a line of cards spanning ~5 years,
so giving me a price and saying GeForce doesn't mean anything.
*/

I have absolutely no idea, I just bought the PC, so I know zilch about this, its all jibberish to me!

the machine currently has a shared memory Intel extreme graphics card, a cousin of the machine has 9800 SE,

can you name specifics that I should look for?

/*
The price on the 9800 is also useless unless it has an extension (SE, Pro, XT).
 From that price I guess it is an SE, which is a BAD price
*/
/*
(roughly £115 new anywhere else).
*/

which site has it at this price, how does the SE compare with the others,
eg whats missing or is it slower??

will the Chimp + butterfly demo run on all 3?


/*
It could be a plain one with no extension,
but you need to specify. The PC-World sit
 gives me 2 hits, neight for that price.
*/

the PC World one is £199,


/*
 VGA switches can range from £10 to £200,
the price depends on the output quality and the features.
Pay more if you want better quality.
*/

I want cheapest simplest possible, where should I look for a £10 one?

all I want is to connect my PC and A1200 to the same VGA TFT,


so I dont need one which can deal with 8 monitors or does keyboards as well,
merely 2 computer VGA cables in and one monitor VGA cable out,


at the moment I reconnect the VGA cable while all 3 machines are switched off,


/*
 I have no idea on A1 or Peg compatability as I don't care about either.
*/

fine,

I forgot to ask: AROS compatibility also matters, or will they all function
on AROS?

[whoosh777]

 @bloodline,

YAH:-D:-D:-D:-D!!!!!!!!!!

I've done it!

the earlier link to WinRAR did the trick,
so thanks to the guy who pointed that out,
though it was some effort due to the impenetrable
Wind:pissed:ws XP interface, you have to go through a maze whenever you want to switch activity,

First attempt didnt b:griping:t as it was the .tar archive!

So one further decompression via WinRAR and then
burnt :madashell: yet another CD-R (luckily I bought 10),

This time it b:lol::lol:ted!

I had to witness some ancient MSD:crazy:S screens and
then:

a Workbench with
2 icons: Ram: looking like a microchip and the CD's icon,

15.5 Meg graphics ram in the title and 236.7Meg other! :-D

:first time on this new PC that I've seen how much
ram I have!

Up till this point I had only been thinking of AROS as
source code, but here it was entirely a real interface,

It is an Amiga, it has its own flavour but it is
recognisably an Amiga,

and its a truecolour workbench because there is a
colour circle demo program showing a continuum of
colours,

its certainly a reimplementation,

it even has Prefs programmes,
I forget if it was in Prefs but I saw Zune#?
but didnt think of trying it out,
I set my keyboard repeat + delay without probs
via one of the Prefs programs,

I also changed it to a US keyboard as the
positioning of the non-alpha-numeric characters
is better thought out,

I eventually found the shell, via c:Newshell,
I changed the long shell prompt to > via c:prompt,

A lot has been done and a lot of libraries are present,
:kitty: kitty looks real in truecolour)
 
enough is certainly up and running to make it
worth writing programs for,

the fact that I saw a Ram: icon says that
intuition + graphics + dos + exec are done!

which for me is almost everything,
other than the #?.device's, I didnt check
which of these are done,

its going to take some time to get used to
the fact that I can now actually look at the
source code, its like a huge gate has been opened
and we can all walk in and press the buttons on
the control panels of the OS!

:I am so entrenched in the 3rd-party-developer mindset,
vs the OS-contributor mindset,

until now the OS was entirely in the hands of an elite,
who decided on our behalf,

I can already see one program I can create
 by recycling existing code,
the required library being present there,

I couldnt find gcc, so I presume its on
www.aros.org, (or is it www.aros.com?),

I think the things which are missing are
what makes the project interesting from a
programmer POV,

so its almost like you can reinvent the wheel :roflmao:
your own way,

double clicking a text file makes it automatically view,

so I double clicked s:startup-sequence,

its very cheeky because it is a real startup-sequence,
serving the real purpose but its not the official one,

Before you can write programs for AROS you will have to
check whether the required libraries are present,

anyway a lot of existing programs should port very
rapidly as the central stuff is present,

its lucky that I follow the minimalist principle when
coding, ie use the absolute minimum of external dependencies eg I strictly program within OS3.0
and cybergraphics.library,

I presume you have reimplemented cyber??
(I will find out soon enough!),

I noticed arosc.library (I think), so I presume that is
standard c things as a shared library??

this is also my first visit to amiga.org in truecolour
via internet explorer, its a totally different website
via this browser + XP,

Ibrowse is ahead in that there is an editor button
so I can edit in Memacs, also on IBrowse I can
reply to a post via "view in new browser" : where
the reply happens in an Ibrowse folder!,

so eg on Ibrowse you can open all the pages of a
thread as lots of folders, which is really useful!

:not as lots of windows but folders like in YAM,

You can tell that this is a developer driven system
in stark contrast to the kid-gloves approach of
Wind:pissed:ws XP by the fact that
it has a program PCI Tool which shows you in great
detail all sorts of PCI stuff that I dont understand,

they'd never let you see things like
that on Wind:admonish:ws XP,

I got the feeling somehow of an engineering workshop,
that people are actively making the system take shape,
I could almost smell the engine oil,

So I've just seen the little-endian Intel-AROS,
until this point that phrase was just a concept for me,

and in a way it is an OS4 on Intel and you arent
afraid to let people try it out,

will it be possible to see my PC's hard disk on screen?

It will be very revealing to look in it via Amiga:roll:S,

Anyway trying something out is so different from talking about it,

I finished the session by trying out the Amiga's
3 key reset and yes the machine reset, though
XP didnt reboot,

The close down procedure of :ak47: XP :destroy: has a reset button so
it must be possible,