@Hammer
>Well, you(and other person) opened some issues in relation to PPC and X86.
I think I touched a raw nerve by saying IBM dont know how to design CPUs,
Karlos pointed out that PowerPC is an IBM thing and not a Motorola thing,
in which case why has the Amiga taken on an IBM CPU???
@Piru
>No. It will just crash due to your program writing to zeropage.
this problem is easily fixed by:
1. moving the vbr away from the start of memory, as in fact appears to happen
if you run "cpu fastrom", Sysinfo shows where the VBR is,
2. the OS should then write protect the first page of memory after the
pointer to ExecBase has been set up in position 4,
Now when my prog tries to read from disk or file to position 0 the MMU will
intercept this and a "first page write violation" requester should come up,
"click to remove task",
as all its reads begin at the start of the array zero problems would result,
its not my fault if the OS designers put the most critical
OS vectors right above 0,
BTW my program with device set to trackdisk.device creates uncompressed .adf
files, I found this by comparing its output to that of something from
www.aminet, in trying to set up WinUAE,
I have set up WinUAE now with AIAB, its absolutely fantastic and its
the identical ROM of my A1200 so its the real AmigaOS,
so the XP machine is like a huge graphics card accelerator for my ROM,
It has the exact same quality as the Windows XP environment,
as its basically an XP app, with emulated Picasso screen,
the speed tests were absolutely staggering: it filled an entire screen
with characters instantly, it was like rain in a thunderstorm,
it said equivalent to 1662 MHz 020 and 5234 MHz FPU,
100 x speedup of FPU!, 30 x speed up of CPU (I think)
361 MIPS, 673 MFlops, I havent run Sysinfo yet,
There are some font render bugs, I ran Memacs with a large font and it doesnt
quite erase a character if you type del, so you end up with a lot of
detritus in the bitmap,
There seem to be long delays from double clicking an icon till it runs,
but once it runs it moves like greased lightning,
The way WinUAE deals with hard-drives and floppies is they are
files on the Windows drive, so the hard drives on the WB seem to be
the subdirectories of a particular directory on XP,
thus to transfer Amiga files over you just copy them over on Windows into
those subdirectories,
the AIAB backdrop is visually more stunning than any of XP's also the
AIAB icons + icon text are actually better than XP's if you like that
type of icon,
the amount of graphics ram seems a bit limited though, its either 8 or 16 MB,
(I forget which),
AROS should be much faster still, they say power is an aphrodisiac,
I think once any developer starts coding on AROS they are going to become
totally hooked,
>Sure. AmigaOS is not POSIX.
I'm not advocating POSIX, gcc is largely
POSIX compliant, so AmigaOS is very nearly compliant,
what I meant was that indivisibility and sequentiality are crucial
design features, its very pedestrian if 2 i/o API calls of the same
Task violate this, ie Putstr(...) ; printf(...) ;
its no use blaming the programmer, both those calls dont reference any
resources so it should be safe to call them both,
>>printf anyway must be implemented via PutStr,
>No. And it's not. Thus the possible problem when mixing stdio and dos.library IO.
printf is dos.library IO:
I wrote a small simplified version of SnoopDOS, I give it any jump vector
and when I type control-E it tells me how often its been used,
this tells me:
SAS C 650 and 68k gcc *both* implement printf() via dos.library Write(),
probably printf(...) is implemented via fprintf( stdout , ...) which
in turn calls Write()
buffering should be inbuilt at a low level,
dos.library buffering sucks with titchy static buffers per drive,
(c:AddBuffers) buffers should be dynamically allocated at use time and
they should be big it makes a big difference to performance,
most drives most of the time are asleep so if you have 10 partitions
that is say 8 asleep buffers, its so wasteful,
it annoys me when people vent their anger at me for what is really an
architectural flaw, I will redirect that anger to where it rightfully
belongs though,
this is how I would implement PutStr() :
int PutStr( UBYTE *str )
{
int len ;
len = strlen( str ) ;
if( len==Write( Output() , str , len ) )return( 0 ) ;
else return( -1 ) ;
}
ooh that was difficult,
my prog tells me they havent used any of Write(), FPuts(), VFPrintf(),
>Which reminds me, your code fails to Inhibit() the filesystem.
>Anyone accessing the disk simultanously can get corrupt results,
>even corrupt the written data.
I suppose you take out an insurance policy every time you cross the road??
I used it quite painlessly to turn my WB3.0 floppy into an ADF file
and it boots quite fine to WinUAE, smooth as clockwork,
you should take a stroll down
www.aminet sometime,
its "storm in a teacup" time,
some people get their kicks by being unconstructive,
but the constructive people always win in the long run,
