amiga.org
     
iconAll times are GMT -6. The time now is 07:44 AM. | Welcome to Forum, please register to access all of our features.

Amiga.org Amiga computer related discussion Amiga Software Issues and Discussion 68k AGA AROS + UAE => winner!

Amiga Software Issues and Discussion This forum exists for the discussion of the use, issues with, and fun brought about by classic and next generation Amiga software.

Reply
 
Thread Tools Display Modes
Old 04-22-2004, 06:01 PM   #121
whoosh777
Too much caffeine
Points: 5,031, Level: 45 Points: 5,031, Level: 45 Points: 5,031, Level: 45
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Posts: 114
Default Re: 68k AGA AROS + UAE => winner!

Quote:
bloodline wrote:
Quote:
/*
TCP/IP stacks are hard, but Wez is working on one.

Did you not use Datatypes on your Amiga?
*/

no, I've not gone too deeply into graphics as I find it too
open ended and arbitrary, though its very satisfying to look at,

same reason I didnt become an artist,

so when I have needed graphics I've coded it directly eg
iffparse.library for iff files,

or used 3rd party code for a specific picture file,
From now on, you will use Datatypes if you need to support any file type. :-D
maybe I will attempt a test Datatypes program
once I have gcc set up, I'm spending so much
money right now on h/w getting this machine set up,

BTW HP say I can only make 1 set of system recovery CDs
which I did today, and they seem to be saying its only
usable on this system,

the blurb said I got "MS Windows XP Home Edition",
but I got no CD, so its not really Windows XP if I
cannot use it on another system: what happens if I
replace the motherboard + CPU to a clone??

Quote:

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

I bought a USB external drive today so I see what you mean:

40 for 120 Gig, 60 for the case though, probably 10 x the capacity of
an external SCSI for that price,

I think USB outdoes SCSI, but SCSI has advantages (not price) over IDE:

with IDE my machine only has 2 slots,

for me personally I have complete docs for coding cross platform SCSI,
but maybe I can learn to code USB,
If you have 2 IDE slots then you can use 4 devices.
That's right each IDE slot can support 2 devices, it you buy an IDE cable it has three plugs on it, one for the Motherboard and one for each of the devices the slot can support. If you do put more than one device on a single IDE slow, one device must be set to Master, the other must be set to Slave. This is doen using some jumpers at the back of the device.
4 is probably more than enough,

is it possible to externalize the drive??


Quote:
Learn to use the USB, it is much better than SCSI.
I hope I can get hold of well written USB API docs,

Quote:
Quote:
Question: can you outline what is involved in communicating with a
hardware device on the PC?

(thinking about AROS drivers)

explain it in general terms understandable to someone only familiar with
the classic 68k Amiga,

how do you communicate with a generic PC h/w unit?

alternatively select a specific h/w unit and explain how this
is controlled directly in assembler,

eg are there specific absolute memory addresses for say PCI socket 1,
and is there some kind of structuring to the reads + writes,

eg for a write might it be:
write data length to $12340
write pointer to data to $12344
set bit 1 of $12348 to begin the write,
interrupt 123 happens on write completion,

and eg the data itself will be structured in a way
private to that specific device,


I can see that all PCs have the same structure:

some PCI sockets, AGP socket(s), SIMM sockets, maybe IDE socket(s),
maybe USB sockets,

and then a lot of h/w is via these sockets,
you mentioned IDE bus and USB bus, presumably the bus amounts to
an initial socket??

so I presume each socket has an assembler level API,
Ok... firstly we don't use any ASM in the drivers, since you will find the same network card/graphics card/sound card whatever, in an x86 machine, a PPC machine or whatever etc... so that driver should be portable across the CPU types.
I wondered whether h/w interfaces being at such a low level whether one is forced to use ASM,

Quote:
You do not program the PCI slots yourself. As a driver you request infomation about the attached hardware from the PCI drivers (which I think is the pci.library in AROS).
ok, so the drivers are above pci.library,

should be very interesting autodocs,

that should make writing a driver much more doable,

can you show a code fragment from a real driver?

Quote:
You use the PCI drivers for all access to devices on the PCI bus, and since almost everything in the computer is attached via that bus, this is the thing you need to learn about.
can you explain what you mean by a bus?

is it comparable to the data and address buses
connecting a CPU and RAM??

also is the USB bus comparable to the PCI bus?

does IDE have a bus?

Quote:
Everything hangs off the PCI, this is the bridge between the CPU and the hardware. The PCI drivers will provide you with any information you need about the attached hardware.
I'm not sure how good the AROS PCI driver docs are, but it's a pretty standard implementation.
maybe if you make a case study of a specific driver
available it will get people interested in
writing drivers, I would certainly study such,

whoosh777 is offline   Reply With Quote
Old 04-22-2004, 08:53 PM   #122
whoosh777
Too much caffeine
Points: 5,031, Level: 45 Points: 5,031, Level: 45 Points: 5,031, Level: 45
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Posts: 114
Default Re: 68k AGA AROS + UAE => winner!

@Piru,

I think you know tooo much about AmigaOS!

too much knowledge can be a dangerous thing,
I am thankful I dont have such in depth knowledge,

it would cloud my judgement,

De Bono said that forgetting is an essential part of
intelligence as it acts as a filter,

Quote:
Piru wrote:
@whoosh777

Quote:
I havent used the blitter for a long time but what happens if you give the blitter an odd address, do you get an exception or just a horrible crash??
No exception. The lowest bit of the address is ignored, so you would get odd_address - 1.
ok so the blitter is basically quite a maniac!

what happens if you send it off into nonexistent RAM
or into Fastram (which presumably is nonexistent from
its POV),

the last time I looked at the blitter was on my A500,
last century,

Quote:
Quote:
Quote:
Even if the app crashes, there is no way to "remove task" safely, since there is no resource tracking or separated address spaces.
if you had just memory tracking then you could remove the tasks allocated memory + code + stack,
I'm afraid that won't work. The memory allocated by the task can still be in use by other tasks / processes. Also the program seglist could be used by interrupts, hooks or other processes. This is why you can't free the task memory or unload the seglist.
ok I see what you mean, again this is bad system design:
namely not anticipating this type of problem and its
probably going to be difficult to fix this,

My problem is I trust the OS too much,

some OS design criticisms here:

1. shared memory for messaging was a bad decision,
if you do this it should be via some new API call
AllocMessage( struct Task *task, int size ) ;

for sending messages to "task", that way the
message would belong to the recipient managed by the OS,
so you could remove it on removal of the recipient,

the design error was about ownership, AmigaOS made
sender the owner, when in fact it should have been
recipient: if I send you a letter, you own that letter
not me, if I own that letter the world is going to
get really complicated and probably grind to a halt
and give up,


this approach would be better because it would cope
with a task on another machine, ie when you send the
message the OS could copy it if necessary,

2. Code for other tasks to execute which I think is
what you are referring to:

this could have been done by eg

SetupPublicCode( "filename" ) ;

where the OS would load the public code from a file,


exactly same thing for my snoop program:

SetVectorOffset("filename");

The Law of Whoosh:

User progs should be forbidden via API from choosing
public bytes,

(ie user progs cannot delineate public memory areas
to the OS)

This includes: user progs shall *not* set up
struct Message's, OS datastructures shall never
be allocated by user code,
user progs shall not set up
code to be executed by other tasks in no shape way
or form, neither Interrupts, nor jump vectors,

really setting up public interrupts is an OS level
thing so should be disallowed for user programs,

setting up private interrupts is fine,

there need to be 2 types of programs: user programs
and system programs, system programs may set up
public interrupts,

perhaps via a file attribute flag: (like rwed),

or via a "priority" system: each program would have
a priority, only the user via a password may change
program "priority" via Workbench information,

I dont want to enter the minefield of computer security
here, but I know from my understanding of computers that
a completely correct system can be done which will
stand the test of time, ie it will be logically foolproof,


what the OS can do then is when it runs a program
it notes whether its a system program,
if a non system program makes an API call to set
public bytes the task should be suspended and removed,

public datastructures and public code must be entirely
set up by the OS,

You tend to look at things in great depth from
the AmigaOS POV,

however I tend to look at things from the POV of an
abstract generalised OS the way I was taught to by
well qualified theorists,

Its a very safe way to look at things,

Quote:
Quote:
Quote:
Also when the buffering is local it has much better knowlege of the actual buffer usage, so further optimizations are possible that would not be at lower level.
I totally disagree, buffers should be dynamically allocated at the lowest level, preferably not by the programmer, in fact maybe even not by the filesystem but by a lower level still, though integrating the filesystem with the lowest level maybe is the best approach
I totally disagree with you, see below for an example.
all your example proves is how terribly designed
dos.library is,

I didnt realise it was that useless,

so yes your point is correct *relative* to AmigaOS,

I was talking relative to a "sane" system,

Quote:

Quote:
Also choice of caching algorithm can make a huge difference this is part of why I dont want it done by the programmer,

if its not done by the programmer then it can be retargetted ie reimplemented
But the programmer does not need to do it, libc does it for him/her.
given that dos.library is so useless then yes
libc needs to shield out dos.library,
and it may become more efficient but never really
efficient,

I am learning a lot of things from you,
but things I would prefer not to know,

Quote:
Quote:
caches arent everything, filesystem design is equally important at determining speed, a well designed system would be really fast even if the programmer doesnt do any buffering,
read my lips!

(see later),

Quote:

the subroutine call overhead of fputc( fgetc(infp) , outfp) should be quite tiny because this is such a tiny loop it should entirely be in the memory cache, (with fgetc() copying a byte from a low level buffer and fputc() to a low level buffer) note that not only will the instructions of this be entirely in the instruction caches but the file buffer arrays will also be entirely in data caches, so all round very fast,

I think AmigaOS filesystem is much more efficient than that of Windows XP, its a good filesystem, but it could be a lot better,
Well, apparently you don't know how complex the two APIs are, and how much overhead is caused by it.
correct: and I'm quite shocked by your example,

correction: you need to replace the words "how complex" by
"what an incomprehensible mess",

did someone sabotage dos.library,
I'm beginning to wonder,


Quote:
Maybe a simple example will clear it for you.
it did, unfortunately,

Quote:
Lets imagine simple fputc without any buffering, except at the exec device driver level (which you say will be the most efficient):

- fputc calls Write(fh, &ch, 1); to write the char
- Write calls DoPkt with ACTION_WRITE
- DoPkt sets up a DosPacket with ACTION_WRITE and parameters for the write
- DoPkt PutMsg the DosPacket to filesystem MsgPort and Wait for the reply
- filesystem wakes up from Wait() and GetMsg() the DosPacket
- filesystem determines the DosPacket is ACTION_WRITE and process it
- filesystem ACTION_WRITE updates the current block of the file
- filesystem ACTION_WRITE use DoIO CMD_WRITE (or CMD_WRITE64, or HD_SCSICMD etc) to send IORequest to exec device driver
- DoIO use device driver DEV_BEGINIO vector to send the IORequest
- The device driver DEV_BEGINIO link the IORequest to device task for processing, and return
- DoIO WaitIO is waiting for the IO to finish
- The device task will process the IORequest, see that it's CMD_WRITE (or whatever), and update buffers (and perhaps do the actual IO).
- When the IO is finished the IORequest will return (ReplyMsg)
- DoIO's WaitIO call wakes up, and DoIO returns
- filesystem checks for IO error and io_Actual to see write was successful
- filesystem ACTION_WRITE set dp_Ret1 to 1 (written 1 byte) and dp_Ret2 to 0 and PutMsg() the DosPacket back to caller (DoPkt)
- DoPkt's Wait wakes up, and DoPkt GetMsg the reply DosPacket, and moves dp_Ret1 to d0, and dp_Ret2 to pr_Result2 (IoErr) and returns
- Write returns with 1 byte written
- fputc returns with 1 byte written
I'm totally horrified,

Quote:
The above sequence is for writing single byte without local buffering. It involves several task switches (scheduling) and waiting. In all it is very very time consuming and will kill the performance, regardless of caches.
one of the nice things about a lot of AmigaOS is it
doesnt bother with OS tasks, OS API calls are
executed by the task,

not so with dos.library,

IMO the OS being executed by the task is one of the
redeeming features of AmigaOS, your example proves
how useless the concept of separate OS tasks is,

I now understand why AmigaOS is often so responsive,
and why the filesystem can be so unresponsive,

Access to a particular partition should be controlled
via eg semaphores, so only 1 exclusive task should
write to a partition, but many may read a partition,

before a task may write to a partition, it should be
queued up till all current readers have finished and gone,

all this partition access happening via OS library code,
ie not via user code,

Indisputible Fact: only 1 task may write to a partition at a time, many may read simultaneously, (**)

dos.library appears (maybe you'll correct me as you
have memorised AmigaOS) to achieve (**) by
having filesystem tasks,

Now maybe because disks are heavy duty things
you should also make read access exclusive,
otherwise the disk head will keep flitting between
2 positions and take forever, I have to think about
this further,

to keep the design simple it may be best to make
all access to a given physical drive exclusive,
regardless of filesystem, (1)

note how Semaphores achieve exactly the same
goal as filesystem-tasks,

I have to tell you that filesystem-tasks sounds
very Unixish,

IMO (1) is the best approach via Semaphores,

probably I wouldnt use exec's Semaphores but
implement my own ones specifically for the
filesystem(s): general purpose semaphores
are going to be much slower than special
purpose ones,

via the above explanation I can use
exclusion only Semaphores which can be done
very efficiently via eg #?.library code:

TAS (SEMAPHORE_OFFSET,A2) ; fp in non scratch a2,
BEQ continue

; queue up our task and surrender the cpu,
; time overhead here, atypical situation: rare to queue up,

continue: ; we own the semaphore,
; do the i/o eg fputc,


so the semaphore amounts to 2 asm instructions
when there's no queue, using exec would be too
much overhead for fputc,

I think BSET can also be used instead of TAS,
not had time to see which is better,

semaphores require indivisible read-modify-write
asm instructions,

BTW I think you raise some very interesting points,
so maybe your highly specific knowledge has some value!

Quote:
Now, if you put the caching to filesystem the sequence gets a lot shorter:

- fputc calls Write(fh, &ch, 1); to write the char
- Write calls DoPkt with ACTION_WRITE
- DoPkt sets up a DosPacket with ACTION_WRITE and parameters for the write
- DoPkt PutMsg the DosPacket to filesystem MsgPort and Wait for the reply
- filesystem wakes up from Wait() and GetMsg() the DosPacket
- filesystem determines the DosPacket is ACTION_WRITE and process it
- filesystem ACTION_WRITE updates the current block of the file in cache
- filesystem ACTION_WRITE set dp_Ret1 to 1 (written 1 byte) and dp_Ret2 to 0 and PutMsg() the DosPacket back to caller
- DoPkt's Wait wakes up, and DoPkt GetMsg the reply DosPacket, and moves dp_Ret1 to d0, and dp_Ret2 to pr_Result2 (IoErr) and returns
- Write returns with 1 byte written
- fputc returns with 1 byte written

It still involves several task switches (scheduling) and waiting.
basically the design flaw is filesystem tasks,

the OS is just datastructures + code to manage
those datastructures, I think its fine if said code is
executed by user tasks, the code itself would be
library code, why have the silly extra task switch +
messaging overhead of having a filesystem execute
exactly the same code??

Quote:
Now, lets put the cache to fputc:

- fputc puts the char to local buffer
- fputc return with 1 byte written

No task switching is involved. Depending on the buffering mode, only filling up the buffer or linefeed will cause actually flush of the cache (Write).

If you still fail to see my point, I can't really help it.
Not only do I see your point, I also see the cause
of your point and beyond that cause to the fix of the
cause of your point,

your last code fragment underlines my comment that
filesystems should be executed in the calling tasks
context,

note also my comments that there should be
exclusive read + write access at the physical drive level,
its fine to have 5 tasks in parallel accessing 5
different physical drives,

the idea may need some refinements eg you may need
to have exclusive access to all drives of
a given SCSI interface socket,

its all about whether (parallel action) faster than
(serial action),

only verifiable by experiment, = empiricism,

I know that parallel access to a given drive
is really inefficient,

there are 2 totally different issues going on here:

1. datastructure complexity: 5 tasks in parallel
modifying the same datastructures could be too complex,
so you use Semaphores to reduce this to 1 task,

dont use Forbid() Permit() as its a local exclusion
problem, like a local anaesthetic, just
anaesthetize the physical drive, not the entire computer,

2. data transfer speed: if 2 tasks in parallel
access the same drive, with 3cm between the disk head
position, an unacceptable amount of time will be
spent by the head moving between the 2 positions,

Note that the speed issue probably is less relevant
for Ram:, though caching issues will affect speed,
so it may be best not to flit around ram: too much,


IMO you only need 2 levels of caches:

cache for indivisible physical disk reads,
call these cylinders (or maybe tracks),

cache for files, the file write cache probably should be
the size of the largest available free subset of
available indivisible disk reads,

the file read cache will be quite different from
the write cache, may even have a collective file
read cache,


fgetc and fputc would deal almost directly with
this file cache, which is kind of what I was
thinking about in my original comment,

[removed a comment which I realised was false]

Semaphoring adds an overhead of 2 asm instructions
in the typical case (just one user prog, no queues),


once the file write cache is full you read the foreseen
cylinder, write out the cache to the buffer,
write modified buffer to the drive,

the new largest available size will now be smaller
(unless eg file deletions have occured) so the
same buffer could be retained for this file,


If the program flushes the buffer early eg
by closing the file then a different cylinder
may be chosen for the write eg the nearest
cylinder with enough space to reduce disk head
movement,

also for file reads the file cache may only
need to be partially filled, just fill in
the blocks in the current disk read,
no need to fill the whole thing,
possibly achieved via collective read cache,


so if the prog looks at position 100000 of the
file, then say this is in block 200 of the file
and block 200 is in cylinder 10 of the disk,

then cylinder 10 = indivisible disk read (maybe track),
is read to fill in an indivisible disk read cache,
(A)

(read caches are quite different from write caches),

I wont copy other blocks of this file until and unless
requested by the program,

If the program now moves to a totally different
file position in a totally different cylinder,
the cache (A) would still be kept, eg I may keep
allocating such caches according to some policy,

now if the prog references a different subblock of
(A), I copy that over into the file cache,
no disk read required,

I dont just have caches I have caches of caches,

when the collective file read cache is full I will override particular subblocks by new read blocks,
according to a well thought through policy,

anyway I am illustrating here that caching is quite
complex and must not be done by the user program,

user program caches just add an extra array copy
overhead, you are just replacing a function call overhead
with an array copy overhead + index management overhead:

fputc( c , fp ) ;

vs

mybuffer[ i++ ] = c ; /* index management */
/*
unnecessary memory access and index update + address
calculation
*/
if( i==full ) /* index caution */
{
fput_array( mybuffer , full , fp ) ;
i = 0 ; /* index reset */
}
fput_array() has to do memory to memory copying,
via indexing => duplication of indexing effort,
if(i==full) effort also duplicated,

my method: c only gets written to the file cache once,
your method: c is written to memory twice,
read from memory once, 3 x as many memory accesses

your method: indexing happens twice,
my method: indexing happens once,

your method: checking for index full happens twice,
my method: happens once,


in assembler my method could be merely:

move.l c,d0
jsr fputc

if fp is in a nonscratch register argument,
(an argument in favour of nonscratch argument registers )

and an extra 2 asm instructions of overhead for
the semaphoring in OS library function fputc,

1 semaphore per physical drive, pointer to semaphore
is a field in fp,

note that in your method the user progs buffering
is quite a number of instructions which are
themselves memory accesses,

those instruction fetches are probably cached, but
everything here is probably cached,

:instructions, buffers, stack, all in CPU caches,


Quote:
so the OS is sensibly not writing to the hardware till the cylinder or track is full
Only because you write full tracks. If you would do small writes, it would rewrite the same track several times.
[/quote]

for writes my approach would use several track caches,
ie caching of the caches:

eg on a current Intel I may buffer the entire
floppy disk,

if its a 120Gig disk and 200 Mb free Ram I may
dynamically go up to 100Mb of caches,

for the floppy disk write example on Intel sectors referenced would be read,

writing would happen at CloseDevice() time
and only of modified tracks,

so a total minimum of track writes would happen,

There may be some glitches in what I've said
(its late at night)
but the underlying idea is rock solid,


whoosh777 is offline   Reply With Quote
Old 04-23-2004, 09:43 PM   #123
whoosh777
Too much caffeine
Points: 5,031, Level: 45 Points: 5,031, Level: 45 Points: 5,031, Level: 45
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Posts: 114
Default Re: 68k AGA AROS + UAE => winner!

I think in the above post I may have missed out
1 level of indirection with the semaphore,
I often do the wrong amount of indirection
with 68k asm,

so the correct version may be:

TAS ([OFFSET_SEMAPHORE,a2],0)
BEQ continue

....; queue up for exclusive access,

continue:

....

(the queueing up itself could be done via
exec semaphores,
but no queue => no exec semaphores => fast,
)


Well IMO Windows XP filesystem on IDE as seen through WinUAE is considerably slower than FFS on my A1200
via Blizzard SCSI-2,

doing something as trivial as

assign something: somedirectory add

or

echo "hello" >xyz:uvw

takes possibly even 1 minute!

I found I can run my datesorter program on
the whole of Windows XP's filesystem by selecting
"Add PC drives at startup" in WinUAE,

I wanted to see what XP had been up to,

what I observed is there are huge pauses,
sometimes the directory scan will be quite
rapid,

it may be the layering of dos.library above Windows
filesystem though,

so although I've criticised dos.library it may be
quite good compared to the competition,

I bought an ATI-Radeon 9800 SE for 129 today,
not fitted it yet as too many other setup things
to do first,

I found out you *can* have an external IDE drive:
the USB drive I bought is such:

you put the IDE drive in a case with its own
power supply and a USB-2 cable connects it to
the computer,

also I saw for sale USB2 to PS/2 mouse + keyboard
converters,

My A1200 produces much more powerful video output
than this PC,

the A1200 is also much more robust for keyboard and
mouse extensions:

my A1200 can cope with huge extension cables
for keyboard + mouse + monitor eg 5m,

the PC can only cope with one 1.8 m extender,
if I put 2 the mouse + keyboard stop functioning,

connecting PC + A1200 to my KVM switch and entirely using
Belkin VGA cables my A1200 produces a perfect screen
whereas the PC produces a double image ghost,

so you cant blame the cabling as its identical,
I blame the feeble PC signals which make the ghost
visible via low signal-to-noise ratio (using analogy
of cassettes and dolby),

I've also located examples of unsophisticatedness in Windows XP's windowing:
example: if I open the directory folders window,
and select some file and select "move this file"
a small window appears for me to select
destination directory,

thing is it seizes control of the user interface,
eg I cannot bring the original window to front,
the small file flashes if I try,

I would be in big trouble if Piru found out
that I wrote a program that seized control of the WB,


I cannot even attempt to rename or move another
file,

on AmigaOS the windowing is fully asynchronous,
1 window cannot seize the environment,

(in OS1.2 the WB was much less asynchronous)

note regarding my comments about exclusive access
to drives, that is only for the rename() api call,

not for the GUI rename where you can still edit the
rename, ie only when you press return should
other tasks be locked out from accessing that
drive, other drives no problem,

so WB is more asynchronous than Windows XP,
ne ne ne-ne ne,

gradually dismantling a few years worth of
PC-better-than-Amiga FUD from the internet,

BTW if I run WinUAE with my original WB disk adf file
in "drive 0" I get AGA WinUAE and it is
indistinguishable from the real thing,

:I actually start thinking I am on my A1200,

:you can even slide down the screens, eg
I ran DeluxeMusic which rendered perfectly,
(imperfect rendering if done via Picasso emulation
eg I cannot access quit from the menu),

I slid down the DeluxeMusic screen, the colours
were slightly different from my A1200 but otherwise
it was correct,

I played Bach Fugue and listened, it was correct
but in higher quality via the PC's AC 97 sound card,

I found the font rendering problem was because
I had selected a variable width font, fixed width
fonts are no problem,

Now IMO if you can slide down the AGA screens it
should be possible to slide down the Picasso screens,

ditto for AROS,

though it may be tricky, dont like those immovable
WB screens,

I went to a lot of PC shops today (even though I shouldnt, surfing the high street!), I saw a 128Mb USB-2 keyring for 29.99,

USB2 is like magic,

now I have a PC when I walk into a PC shop I know what
everything is, I know that those XP screens are merely
a selection of one of the standard backdrops,

those icons are exactly the same as my ones,

when I hear the staff talking I actually know what
they are talking about, the only shop that impresses
me now is Maplins. In PC World when I ask about prices,
I am very tempted to say: "you realise thats a total
rip off!" The staff in a lot of shops actually tell me to try Maplins,

now when I walk into PC shops, its like toys everywhere
for me, and so cheap, and I have total compatibility,

everything in Dixons is now compatible with my system,

this XP machine is the ultimate interface + accelerator
card for my OS3.1 ROM via WinUAE, Windows XP is a great
hardware abstraction layer, it abstracts all hardware in
existence, maybe AmigaOS should be sold as a Windows app??

I've never felt so happy since buying this machine,
its like everything is win-win, every question I ask
the answer is yes, yes you can, yes we do, yes we have,

all the adverts now address me,

I havent forgotten AROS though, IMO there will be
a gradual ongoing transfer of power from WinUAE to AROS,
WinUAE hosted is a vision of what AROS could become,
if you try WinUAE either AGA or in truecolour via
AIAB you will know how fantastic the Amiga on Intel h/w
will be,

the moment AROS gets USB-2 its going to be in such a
strong position,

USB-2 is 480Meg/second (I think),

I found that you can even increase the number of
PCI slots by a PCI card which outputs 2 PCI slots,
so thats what a riser card is,

its like wonderland,

5 keyboards,

128Mb keyring, whats the world coming to!

whoosh777 is offline   Reply With Quote
Old 04-26-2004, 09:18 AM   #124
whoosh777
Too much caffeine
Points: 5,031, Level: 45 Points: 5,031, Level: 45 Points: 5,031, Level: 45
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Posts: 114
Default Re: 68k AGA AROS + UAE => winner!

@Piru

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



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

depends on the docs you use:

Lattice 5 docs p F-145:

``Also note that memcpy and movemem are smart enough to handle overlapping
memory blocks correctly.''

..........

``Unlike memcpy, memccpy does not handle overlapping memory blocks.
If you specify overlapping blocks to this function, the results are
unpredictable''

If that is a lie its a very carefully worded and consistent lie,

The Lattice 5 docs in 3 pages explain 9 memory functions:
memccpy, memchr, memcmp, memcpy, memset, movmem, repmem, setmem, swmem,

vs Lattice 6: 1 page per function,

anyway Lattice 650 p343 of C Library reference:

says the exact opposite:

``The memcpy function does not handle overlapping memory blocks. If you
specify overlapping blocks to this function, the results are
unpredictable.''

Note the exact same word usage, the second sentence of 650 being
verbatim cut and paste from Lattice 5,
so it looks like someone cut modified
and pasted from the Lattice 5 docs to create the Lattice 650 docs,
was something lost in the editting eg the letter c?

possibly their implementation does it correctly but they realised that
other implementations dont so for portability they used the word
"unpredictable",

I am a pragmatist, if there is a flaw in what I say it will emerge
when I turn my words into code. So yes you can find some glitches in
what I say, but in the end its not a big deal because I will find
the flaws anyway. eg I found that I mustnt use fputc(fgetc(),fp)
to copy a large subset of a file just by direct observation
that it was taking much longer than it should:

I didnt know it was because there was an entire task-switch overhead
involved, but I knew it was much too slow,


whoosh777 is offline   Reply With Quote
Old 04-27-2004, 03:49 AM   #125
bloodline
Master Sock Abuser
Points: 39,749, Level: 100 Points: 39,749, Level: 100 Points: 39,749, Level: 100
Activity: 22% Activity: 22% Activity: 22%
 
bloodline's Avatar
 
Join Date: Mar 2002
Location: London, UK
Posts: 11,972
Blog Entries: 3
Default Re: 68k AGA AROS + UAE => winner!

Quote:
I went to a lot of PC shops today (even though I shouldnt, surfing the high street!), I saw a 128Mb USB-2 keyring for 29.99,

USB2 is like magic,
Yes it is, and it's getting old now.

Quote:
now I have a PC when I walk into a PC shop I know what
everything is, I know that those XP screens are merely
a selection of one of the standard backdrops,

those icons are exactly the same as my ones,

when I hear the staff talking I actually know what
they are talking about, the only shop that impresses
me now is Maplins. In PC World when I ask about prices,
I am very tempted to say: "you realise thats a total
rip off!" The staff in a lot of shops actually tell me to try Maplins,

now when I walk into PC shops, its like toys everywhere
for me, and so cheap, and I have total compatibility,

everything in Dixons is now compatible with my system,

this XP machine is the ultimate interface + accelerator
card for my OS3.1 ROM via WinUAE, Windows XP is a great
hardware abstraction layer, it abstracts all hardware in
existence, maybe AmigaOS should be sold as a Windows app??

I've never felt so happy since buying this machine,
its like everything is win-win, every question I ask
the answer is yes, yes you can, yes we do, yes we have,
That's the problem which most amiga users face. They don't realise that they have gone from the cutting edge of technology to the bottom of the pile.

Technology is moving very quickly... In the 10 years since Commodore's demise the whole world of computing has moved on.

Quote:
the moment AROS gets USB-2 its going to be in such a
strong position,

Yes AROS needs a USB stack.

Quote:
USB-2 is 480Meg/second (I think),
Actually its 480Megabits per second which is about 60Meg per second. That's still really fast :-)

Quote:
I found that you can even increase the number of
PCI slots by a PCI card which outputs 2 PCI slots,
so thats what a riser card is,

its like wonderland,

5 keyboards,

128Mb keyring, whats the world coming to!
I wish more people here would take that little leap into the moden computing world :-)
__________________
My iPhone Game: Puny Humans -
http://itunes.apple.com/gb/app/puny-...362230281?mt=8
bloodline is offline   Reply With Quote
Old 04-27-2004, 03:53 AM   #126
NightShade737
Technoid
Points: 5,136, Level: 45 Points: 5,136, Level: 45 Points: 5,136, Level: 45
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: May 2003
Posts: 328
Send a message via ICQ to NightShade737 Send a message via AIM to NightShade737 Send a message via MSN to NightShade737
Default Re: 68k AGA AROS + UAE => winner!

It is only 480Mb/s burst for USB2 though, meaning that although Firewire says it is only 400Mb/s, Firewires rated speed is sustained, so Firewire is actually quite a bit faster than USB2.
NightShade737 is offline   Reply With Quote
Old 04-27-2004, 04:11 AM   #127
Piru
' union select name,pwd--
Points: 30,457, Level: 100 Points: 30,457, Level: 100 Points: 30,457, Level: 100
Activity: 69% Activity: 69% Activity: 69%
 
Piru's Avatar
 
Join Date: Aug 2002
Location: Helsinki, Finland
Posts: 6,946
Default Re: 68k AGA AROS + UAE => winner!

@whoosh777

SAS/C (6.x) memcpy doesn't handle overlapping copies, at least. Looks like they decided to follow the standard and not support overlapping copies with memcpy after all.

Anyway, standard states that memcpy is not guaranteed to handle overlapping copies, so even if some implementation did, you cannot rely on this feature or you're writing non-portable code.
Piru is offline   Reply With Quote
Old 09-07-2011, 09:55 AM   #128
Ezrec
Hobbyist
Points: 2,722, Level: 31 Points: 2,722, Level: 31 Points: 2,722, Level: 31
Activity: 8% Activity: 8% Activity: 8%
 
Join Date: Aug 2010
Location: Pittsburgh, PA
Posts: 57
Default Re: 68k AGA AROS + UAE => winner!

I think this thread could be closed as 'completed as desired'.

It just took 7 years to get around to doing it.
Ezrec is offline   Reply With Quote
Old 09-07-2011, 10:20 AM   #129
Mazze
Too much caffeine
Points: 5,449, Level: 47 Points: 5,449, Level: 47 Points: 5,449, Level: 47
Activity: 2% Activity: 2% Activity: 2%
 
Mazze's Avatar
 
Join Date: Aug 2007
Location: Lohr, Germany
Posts: 123
Talking Re: 68k AGA AROS + UAE => winner!

Quote:
Originally Posted by Ezrec View Post
I think this thread could be closed as 'completed as desired'.

It just took 7 years to get around to doing it.
__________________
AROS - Make Code, Not War
Mazze is offline   Reply With Quote
Old 09-07-2011, 01:06 PM   #130
Terminills
Grand Conspirator
Points: 9,517, Level: 65 Points: 9,517, Level: 65 Points: 9,517, Level: 65
Activity: 16% Activity: 16% Activity: 16%
Othello Champion
 
Terminills's Avatar
 
Join Date: Jan 2003
Posts: 456
Default Re: 68k AGA AROS + UAE => winner!

Quote:
Originally Posted by mazze View Post
+1 =d
__________________
I donate to Aros bounties.

The money is used to purchase the crystal meth and cocaine that it takes to code for 48 hour marathons. Some bounty takers also buy pizza and beer.

Others buy asian hookers. I say, whatever it takes to keep them coding and motivated.

edited by mod: this has been addressed
Terminills is offline   Reply With Quote
Old 09-07-2011, 02:13 PM   #131
psxphill
Defender of the Faith
Points: 7,177, Level: 56 Points: 7,177, Level: 56 Points: 7,177, Level: 56
Activity: 47% Activity: 47% Activity: 47%
 
Join Date: Aug 2009
Posts: 1,677
Default Re: 68k AGA AROS + UAE => winner!

Quote:
Originally Posted by whoosh777 View Post
eg I found that I mustnt use fputc(fgetc(),fp)
to copy a large subset of a file just by direct observation
that it was taking much longer than it should:

I didnt know it was because there was an entire task-switch overhead
involved, but I knew it was much too slow,
using fopen is never a good idea if you want the copy performance. Then you make it worse with the overhead of making read and write calls for every single character. For best speed use no buffering (Open/Read/Write instead of fopen/fread/fwrite) and then read and write in large chunks that are a power of 2 (32k is a good small number ). When copying between different devices you can use multiple threads or asynchronous reads/writes so both devices are busy all the time. When copying on one device it's better to use a much larger buffer and only either read or write.

But unless you understand why you should do these things then it's just cargo cult programming.

However I had to knock up a one off program that had to split some files up and I used fputc/fgetc because it was quicker to code & the run time was a fraction of how long it took to code. Making compromises is the art of being a commercial programmer.

Last edited by psxphill; 09-07-2011 at 02:16 PM..
psxphill is offline   Reply With Quote
Reply

Bookmarks

Tags
aga , uae , 68k , winner , aros

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Winner Z4 busboard for sale Boot_WB Amiga Marketplace 6 07-11-2006 02:40 AM
Winner 4-DEV IDE Interface jgratton Amiga Hardware Issues and discussion 2 01-14-2006 04:22 PM
Elbox: Winner IDE jimmyboy Amiga Hardware Issues and discussion 1 09-15-2005 07:40 AM
Winner Z4 busboard for A1200 Eco Amiga Marketplace 1 05-20-2005 05:25 PM
Meteorite hits lottery winner blobrana CH / Entertainment 5 07-12-2004 08:01 AM