amiga.org
     
iconAll times are GMT -6. The time now is 03:04 PM. | 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-08-2004, 03:11 AM   #31
Karlos
Sockologist
Points: 50,112, Level: 100 Points: 50,112, Level: 100 Points: 50,112, Level: 100
Activity: 2% Activity: 2% Activity: 2%
 
Karlos's Avatar
 
Join Date: Nov 2002
Location: Barishabaad, Sardistan
Posts: 16,643
Blog Entries: 18
Default Re: 68k AGA AROS + UAE => winner!

@whoosh777

You do realise that trap based emulation on a real 680x0 is very slow? Hardly suitable for introducing support for new instruction opcodes to a real 680x0 CPU, especially if they were used heavily.
__________________
OCA
This isn't SCSI... This is SATA!!!
I have CDO. It's like OCD except all the letters are in ascending order. The way they should be.
Core2 Quad Q9450 2.66GHz / X48T / 4GB DDR3 / nVidia GTX275 / Linux x64, AROS, Win64
A1XE 800MHz / 512MB / Radeon 9200 / OS4.1
A1200T BPPC 240MHz / 256MB / Permedia 2 / OS 3.1 - OS3.9, OS4
A1200T Apollo 1240 28MHz / 32MB / Mediator1200 / Voodoo 3000 / OS3.9
A1200D Apollo 1240 25MHz (ejector seat ROM edition) / 32MB
Karlos is offline   Reply With Quote
Old 04-08-2004, 04:22 AM   #32
bloodline
Master Sock Abuser
Points: 38,902, Level: 100 Points: 38,902, Level: 100 Points: 38,902, Level: 100
Activity: 26% Activity: 26% Activity: 26%
 
bloodline's Avatar
 
Join Date: Mar 2002
Location: London, UK
Posts: 11,888
Blog Entries: 3
Default Re: 68k AGA AROS + UAE => winner!

Quote:
>AROS is an OS. It currently is able to boot x86 machines and
>Openfirmware PPC Machines.

>If you were to Flash the A1 BIOS with an Openfirmware rom (written for the Terron),
> then AROS could boot it.

so you appear to be saying it can already be done!

and you also seem to be saying that the only dependencies are that its
Openfirmware, ie the fact its an A1 is irrelevant,

Has this actually been tried out?

What is involved in this flashing of the A1 BIOS?:

lets say someone orders an A1, how do they get the BIOS flashed?

will this clash with running OS4? : what flash does that require, UBoot?

can you switch back and forth between Openfirmware and UBoot?

Have I understood you correctly: you buy an A1, flash the BIOS, download AROS,
boot AROS?
Yes, the fact that it's an A1 is irrelevant. The hardware is a *standard* PPC machine.

First you would have to get an Openfirmware BIOS image from someone. I don't know if these exist, if they do, then One of the other users of the MAI chipset might have one. Check out the Terron.

I assume the A1 BIOS can be flashed by software... most BIOS's can be.

OS4 needs UBoot to boot, for the same reason AROS needs Openfirmware. THat's what they have been written to use. I don't think it's healthy to keep reflashing the BIOS. If one wants to use an Openfirmware PPC machine I would suggest they get an old Mac or a Pegasos2.

On the PC one can use the MMU to load a BIOS image into memory and then use that instead of the ROM BIOS... I assume the same is true of the PPC machines.

The solution to this problem is to get someone with UBoot experience to adapt AROS to use UBoot instead of Openfirmware, That's the simplest solution all round.

Quote:
>The Loader then preserves all the hardware info from the BIOS into a "safe"
>location... The loader then jumps to the AROS ROM code.
>AROS then takes control of the machine. AROS boots.

does the firmware tell you where all the system memory is located?


are any memory allocation facilities provided or you have to construct these
yourself?

any API provided for reading the drives?

The Firmware tells you how much memory is present (Thoguh it's good practice to check while the OS is booting).

The Memory is always located in it's address space... your question doesn't make much sense :-(. Maybe you mean other memory like PCI space and stuff, yes that sort of information is usually gathered by the BIOS, and AROS uses that information.

AROS provides the Memory allocating functions. The Firmware does not need to know about stuff like that.

Most BIOS firmware does provide a simple API for accessing physical sotrage media... how else are you going to load the OS :-)

Quote:
if I can get an A1 to directly boot AROS and then run UAE above this,
then I think I will go down this path and find out what AROS are doing,


IMO AROS are 10 x as competent as Hyperion,


my interest in this is my own projects that I could run in the AROS
environment so eg I very strictly only use the OS3.0 API and cybergraphics.library,


my interests tend to be nongraphical so eg exec.library interests me
much more than graphics + intuition etc.
Exec really is a masterpiece,
If you want to work on the PPC version of AROS why not help the PPC guys get it running on UBoot?

I think Hyperion are perfectly competant, it's hard work writing an OS from Scratch.

You project should run fine in AROS, if you have a PC there, then you could compile your Apps for AROS right now and use them on your PC with AROS :-)

Exec is a masterpeice! And getting to look at the Exec sources in AROS is really nice :-)
__________________
My iPhone Game: Puny Humans -
http://itunes.apple.com/gb/app/puny-...362230281?mt=8
bloodline is offline   Reply With Quote
Old 04-08-2004, 04:35 PM   #33
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!




@bloodline

>Yes, the fact that it's an A1 is irrelevant. The hardware is a *standard* PPC
>machine.

this thought is running through my mind:

reflash A1 and then run Morphos,
reflash Pegasos and then run OS4,
reflash either and run AROS,


>First you would have to get an Openfirmware BIOS image from someone. I don't know
>if these exist, if they do, then One of the other users of the MAI chipset might
>have one. Check out the Terron.

I assume such BIOS images are "public domain",

I think I have to buy the machine first, I like doing things in the
correct sequence,

>I assume the A1 BIOS can be flashed by software... most BIOS's can be.

can it also be backed up?

would it just be a matter of getting the MMU to write enable the BIOS
and then copy the bitmap?


>OS4 needs UBoot to boot, for the same reason AROS needs Openfirmware.
>THat's what they have been written to use. I don't think it's healthy to keep
>reflashing the BIOS. If one wants to use an Openfirmware PPC machine I
>would suggest they get an old Mac or o Pegasos2.

ok, was there any thinking behind their decision to use UBoot?

maybe someone with a Pegasos2 could make their Openfirmware BIOS image available,
ditto A1 UBoot,

> On the PC one can use the MMU to load a BIOS image into memory and then use that
>instead of the ROM BIOS... I assume the same is true of the PPC machines.

sounds a much better approach,

> The solution to this problem is to get someone with UBoot experience to adapt
>AROS to use UBoot instead of Openfirmware, That's the simplest solution all round.

>The Firmware tells you how much memory is present
>(Thoguh it's good practice to check while the OS is booting).

>The Memory is always located in it's address space... your question doesn't make
>much sense.

I was thinking in terms of the classic machine where the memory may be
in several noncontiguous segments,

it sounds like you are saying its all remapped into 1 contiguous slot,


>Maybe you mean other memory like PCI space and stuff,
>yes that sort of information is usually gathered by the BIOS,
>and AROS uses that information.


>AROS provides the Memory allocating functions. The Firmware does not need to know
>about stuff like that.

ok, not a major problem,

>Most BIOS firmware does provide a simple API for accessing physical
>sotrage media... how else are you going to load the OS

I was wondering about this,

eg if you have some arbitrary storage device eg USB or SCSI or IDE,
I was wondering how a low level initial API deals with arbitrary h/w,
but maybe the storage device sorts itself out,


>If you want to work on the PPC version of AROS why not help the PPC guys get it
>running on UBoot?

quite possibly, maybe a good approach would be the more general problem of
layering Openfirmware above Uboot,

if Uboot and Openfirmware are both quite simple then this layering may not
be a big deal,

and then layer the reverse way round,

what I may do is buy an A1, and then fool around with the UBoot to try
and understand it and then look into what the AROS people are doing,


>I think Hyperion are perfectly competant, it's hard work writing an OS from Scratch.

I challenged one of them to tell us in detail what they are doing:
on an hour by hour basis, or even on a day by day basis,
which OS library or subsystem, which API calls, are they debugging or
writing new stuff, is the delay because of quantity of stuff or
difficulty of stuff,

is it graphics.library or dos.library or what?

the huge time they are taking must be occupied doing something,
exactly what is that which is so time-consuming,

I realize that coding is very time consuming and an interesting program
feature could take 1 week to achieve,

I got no reply,

for all I know they are lying in hammocks sipping amicola and reading
star-trek-fanzines,


basically I asked them for a captains-log, and got silence,


I emailed Hans-Joerg requesting their 68k hosted cross compiler,
I got no reply, not even "no I cannot send you this because...",


the whole point of a 68k hosted cross compiler is to run it on a
68k machine,


Their website tells you next to nothing,


they have had a whole suite of cross compilers available since last year,
and they still havent released it, they promised on their website on
Christmas day to deliver this.
For Christmas 2002 we were promised OS4 under christmas trees and
on Christmas 2003 all we got was a promise under a christmas tree,

:they cannot release stuff thats already been done, time is of the essence,

you see I think now that the OS4 shown at Pianeta was merely a hacked
UAE, OS4 maybe doesnt exist,

KMOS are behaving exactly like Hyperion, no announces, no presence,
no nothing, they sound like a stooge,


>You project should run fine in AROS, if you have a PC there, then you could
>compile your Apps for AROS right now and use them on your PC with AROS

I only have 68k machines, 2 68000 A500s and a 68030 A1200,
I will try and get some stuff onto AROS though this will probably wait till I am
on PPC or PC, I have lots of useful utilities that I have written to manage
my own system,

eg I wrote a recursive date sorter, feed it a list of directories
eg some partitions and it will recursively sort the entirety by date,

it will cope no probs with an entire CD, (you need enough ram for the
list to fit: 1/2 Gig full partition on my 14 meg 030 was no problem)

it takes n log n time so there is no noticeable slowdown,
it just munches its way through whatever you feed it,

it can cope with up to 2^32 entries,

not a big deal but very fast + useful, took 1 or 2 days to write + debug,

:I use it to find out what I was last up to on a partition if I havent
used it for a long time,

I will upload the 68k version to my site later tonight:

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

(not there yet as I type this),

example usage:

dates -r ram: -n c: -r -p #?.c df0: -n df1:

=> recursively scan ram:, then non recursively scan c:,
then recursively scan df0: filtering in pattern #?.c,
then non-recursively scan filtering pattern #?.c df1:,

merged sorted list is output,

:you can filter in any pattern,

for usage info:

dates ?

or

dates

>Exec is a masterpeice! And getting to look at the Exec sources in AROS is
>really nice

it could help me understand the original exec,


whoosh777 is offline   Reply With Quote
Old 04-08-2004, 04:54 PM   #34
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!


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

@bloodline

Ok, the UAE idea, is just that. Run a 68k version AROS on UAE, and run UAE on AROS.

All 68k programs will run in UAE, and they will make OS calls to the 68k version
of AROS Running in UAE... That 68k version of AROS will be specially designed to
allow it to call AROS functions through UAE. So whe the 68k program calls the 68k
AROS in UAE C
o open a window... the 68k version of AROS calls the x86 version of AROS and that
Opens a window.

when the user clicks on a window that is owned by the 68k version of AROS running
in UAE, the event gets passed through to the 68k verison of AROS which passes to
the 68k program.

If the 68k program tried to hit the hardware, it will have no problems since the
Hardware is emulated in UAE.

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

I am gradually starting to understand the problem,
some ideas on this:

break UAE into 2 programs: UAE_chipset_emulator and UAE_68k_emulator,

implement UAE_chipset_emulator via AROS API calls,

run this as a background prog from AROS: it will read + write protect
the classic chipset address range: any read or write accesses will be
redirected to AROS API calls so eg:

a word write of #$c000 to dff09a will be implemented via
AROS Enable() but with SysBase->IDNestCnt unchanged,


No ROM will be used, classic 68k programs will be directly fed to UAE_68k_emulator
which will directly access the data structures of AROS,

x86 AROS may need to be big endian,

problem: (there may be other problems too),

if a 68k prog accesses a jump vector eg jsr -444(a6) for OpenDevice,
the jump vector may be PPC native so you dont want the instruction
emulated:

a huge hack around this is to put PPC native code in the upper half of memory,
ie addresses where bit 31 is 1, and 68k code in the other half,

when the emulator is active read-protect the upper half of memory,
when inactive execute-protect the lower half,

this way when the emulator attempts to read the PPC instruction from
the upper half, you get an exception which toggles
from emulator to PPC CPU,

likewise if the PPC tries to execute a 68k instruction from the lower half,
you get an exception toggling from PPC to emulator,

its just an idea and I havent thought it through too deeply,

but maybe you can fine tune it into real architecture,


whoosh777 is offline   Reply With Quote
Old 04-08-2004, 04:57 PM   #35
bloodline
Master Sock Abuser
Points: 38,902, Level: 100 Points: 38,902, Level: 100 Points: 38,902, Level: 100
Activity: 26% Activity: 26% Activity: 26%
 
bloodline's Avatar
 
Join Date: Mar 2002
Location: London, UK
Posts: 11,888
Blog Entries: 3
Default Re: 68k AGA AROS + UAE => winner!

Quote:
>OS4 needs UBoot to boot, for the same reason AROS needs Openfirmware.
>THat's what they have been written to use. I don't think it's healthy to keep
>reflashing the BIOS. If one wants to use an Openfirmware PPC machine I
>would suggest they get an old Mac or o Pegasos2.

ok, was there any thinking behind their decision to use UBoot?
I think they choose it because it was different from the other PPC machines which all went Openfirmware, That way they could lminit the machine which OS4 runs on, and that it was suitable for thier needs.

Quote:
> The solution to this problem is to get someone with UBoot experience to adapt
>AROS to use UBoot instead of Openfirmware, That's the simplest solution all round.

>The Firmware tells you how much memory is present
>(Thoguh it's good practice to check while the OS is booting).

>The Memory is always located in it's address space... your question doesn't make
>much sense.

I was thinking in terms of the classic machine where the memory may be
in several noncontiguous segments,

it sounds like you are saying its all remapped into 1 contiguous slot,
System Ram (Which AROS calls Fast Mem) is. Note AROS calls the first 16meg of System Ram Chips Mem, as this is DMA able ram.

Quote:
>If you want to work on the PPC version of AROS why not help the PPC guys get it
>running on UBoot?

quite possibly, maybe a good approach would be the more general problem of
layering Openfirmware above Uboot,

if Uboot and Openfirmware are both quite simple then this layering may not
be a big deal,

and then layer the reverse way round,

what I may do is buy an A1, and then fool around with the UBoot to try
and understand it and then look into what the AROS people are doing,
AROS is really modular. One would not layer OF (Openfirmware) on top of UBoot, one would take out the OF boot code and replace it with UBoot Boot code. The advntage of AROS being opensource is that it can be hacked to suit the needs of the user (ie you) :-)

Quote:
>You project should run fine in AROS, if you have a PC there, then you could
>compile your Apps for AROS right now and use them on your PC with AROS

I only have 68k machines, 2 68000 A500s and a 68030 A1200,
I will try and get some stuff onto AROS though this will probably wait till I am
on PPC or PC, I have lots of useful utilities that I have written to manage
my own system,
If you find a PC in the trash/skip/bin then dig it out and run AROS on it, I have several junk machines found that run AROS fine.

Quote:
>Exec is a masterpeice! And getting to look at the Exec sources in AROS is
>really nice

it could help me understand the original exec,
The AROS code does the same as the original code... so it's a great place to really admire the design.
__________________
My iPhone Game: Puny Humans -
http://itunes.apple.com/gb/app/puny-...362230281?mt=8
bloodline is offline   Reply With Quote
Old 04-08-2004, 05:08 PM   #36
bloodline
Master Sock Abuser
Points: 38,902, Level: 100 Points: 38,902, Level: 100 Points: 38,902, Level: 100
Activity: 26% Activity: 26% Activity: 26%
 
bloodline's Avatar
 
Join Date: Mar 2002
Location: London, UK
Posts: 11,888
Blog Entries: 3
Default Re: 68k AGA AROS + UAE => winner!

Quote:
whoosh777 wrote <lots of stuff about emualtion>
I think you need to chat to Crumb...

But Keeping 68k Apps away from x86 apps will be better in the long term... espeacially when adding features like Memory Protection, which 68k apps simply cannot work under.

Basicly keep 68k in the emulator and only let certain OS calls out to the Main AROS, so that the 68k programs can function in the same windowing environment as the x86 apps (without actually going near them).
__________________
My iPhone Game: Puny Humans -
http://itunes.apple.com/gb/app/puny-...362230281?mt=8
bloodline is offline   Reply With Quote
Old 04-08-2004, 05:27 PM   #37
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!

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

@Karlos

You do realise that trap based emulation on a real 680x0 is very slow?
Hardly suitable for introducing support for new instruction opcodes to
a real 680x0 CPU, especially if they were used heavily.

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

one way out is:

use traps as I suggested, here real 68k instructions are at full speed,
but as you point out the extended instructions will be emulated slowly,

SR + PC have to be backed up by the h/w (and possibly other stuff)= 2 move's,
2 moves to get address + instruction, jsr + rts to the emulator code,

bitfield extractions + switch statements, soon be exceeding 20 instructions,

so,

simplified JIT emulation could speed this up, replace the offending instruction by
a direct bsr to its emulation, the extended instructions would need to be
designed to be the right size so a bsr will fit, could be done by always following
it with 2 no-op NOP's, (a general bsr requires 6 bytes),

:this way second time round the only overhead is jsr + rts,

self modifying code,



BTW regarding neat 68k instructions, I think movem of 68000 is very
effective eg:

movem.l d0/d1/d2/d3/d4/d5/d6/d7/a0/a1/a2/a3/a4/a5/a6,-(a7)

:a 4 byte instruction to backup 15 registers,

normally would require 15 instructions:

move.l a6,-(a7)
move.l a5,-(a7)
....
move.l d0,-(a7)

(hope I got the order correct),

----------------------------------------
@Hammer

AMD64(X86-64) exposes 16 GPRs 64bit registers, while Pentium IV**
(with hyper-treading) has 8 + 8 GPRs configuration.

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

16 sounds a good decision,
what about 486 and earlier CPUs?


(the speed advantage of x86 makes me believe that something about
their architecture must be very good, I am curious to know what that is),



@BigBenAussie,

if you have AROS on Linux, why not just use the Linux apps directly on Linux!


for office use why not buy Windows and use MS Apps,
if you have an office you can probably afford this
purchase,


what would be interesting would be Linux-in-a-window to run on any Amiga,


whoosh777 is offline   Reply With Quote
Old 04-08-2004, 07:19 PM   #38
Karlos
Sockologist
Points: 50,112, Level: 100 Points: 50,112, Level: 100 Points: 50,112, Level: 100
Activity: 2% Activity: 2% Activity: 2%
 
Karlos's Avatar
 
Join Date: Nov 2002
Location: Barishabaad, Sardistan
Posts: 16,643
Blog Entries: 18
Default Re: 68k AGA AROS + UAE => winner!

@whoosh777

A trap based emulation which can replace each "emulated" instruction with a jump to handling code the first time it is encountered is probably the way to go. I think that's how stuff like oxypatcher/cyberpatcher work anyway.

As for movem, you'd want to check the CPU before making any performance assumptions. On the 68040, for instance, it often takes longer than multiple move.l instructions (although I'm not totally sure if the same is true for 68060).
__________________
OCA
This isn't SCSI... This is SATA!!!
I have CDO. It's like OCD except all the letters are in ascending order. The way they should be.
Core2 Quad Q9450 2.66GHz / X48T / 4GB DDR3 / nVidia GTX275 / Linux x64, AROS, Win64
A1XE 800MHz / 512MB / Radeon 9200 / OS4.1
A1200T BPPC 240MHz / 256MB / Permedia 2 / OS 3.1 - OS3.9, OS4
A1200T Apollo 1240 28MHz / 32MB / Mediator1200 / Voodoo 3000 / OS3.9
A1200D Apollo 1240 25MHz (ejector seat ROM edition) / 32MB
Karlos is offline   Reply With Quote
Old 04-09-2004, 12:02 AM   #39
Hammer
VIP / Donor
Points: 11,529, Level: 70 Points: 11,529, Level: 70 Points: 11,529, Level: 70
Activity: 20% Activity: 20% Activity: 20%
 
Join Date: Mar 2002
Location: NSW, Oz
Posts: 1,992
Default Re: 68k AGA AROS + UAE => winner!

Quote:
what about 486 and earlier CPUs?
Just 8 32bit GPRs (386 and above).

Quote:
(the speed advantage of x86 makes me believe that something about their architecture must be very good, I am curious to know what that is),
It would be more on the micro-architecture side than the ISA side. "Bang per buck" and legacy support (a.k.a "software investment protection") are the other strengths of X86.

Note that IF PPC32 ISA is a "real RISC", the need for decoding/'cracking' into smaller RISC instructions wouldnt be required in the PPC 970(52million transistors beast)(IBM's own "Athlon" but applied for PPC32 ISA).
Hammer is offline   Reply With Quote
Old 04-09-2004, 06:23 PM   #40
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!


@bloodline

who is Crumb?

>If you find a PC in the trash/skip/bin then dig it out and run AROS on it,
>I have several junk machines found that run AROS fine.

I am trying to decide which path to take, PC or A1?

if I buy an A1 I think I can sell it back to Eyetech,
this reduces the risk of making this purchase,

re: reflashing ROMs, could you also run Mac's OS on Pegasos + A1
as well as Morphos + OS4 + AROS on Macs?


Some AROS questions:

1. what compiler(s) are used for recompiling AROS programs?
2. are commercial AROS programs allowed, eg could they sell an
AROS version of IBrowse?

because if AROS is free programs only I see this as a problem,

I am happy to contribute a lot of work for free and I have done for 68k,
but I would also like to sell some programs,

ambitious free programming work is a very good way to learn,
but you can only do it for so long,

if a developer spends 8 months on an OS3.1 program,
then they will be thinking:

shall I give it for free to AROS
or shall I sell it to Morphos + OS4 + 68k + Amithlon people,

now if they can sell it to AROS people they are more likely
to choose the AROS option,

one way out is to only do a 68k version here they can sell it
anywhere they like which is probably what will happen,

some programs will be done for free and some will be very high quality,
but you wont have row upon row of fantastic stuff, just the occasional gem,

the project would certainly succeed but in the spirit of
gnu,


it will become like http://ftp.gnu.org/gnu where 5% is fantastic eg gcc,
5% is self referential eg sed + awk + automake
(you need this because you need this!) and the rest requires a lot
of work to even determine what it is!

ie row upon row of "what on earth is this bloated archive"?

rpm is a red-hat self referential program, current rpm is some 9 meg compressed,
do I want it? no, so why do I use it? because there is lots of interesting stuff
only available in this format. If everything on the internet is in Betelgeusian
then I have to learn that,


I dont know whether Linux allows commercial programs,


put another way if AROS is free things only then there is a danger of
becoming a charity to impoverished Amiga users (such as me )


but if commercial stuff is allowed then the future is bright,


the government used to give free glasses here, (no longer though)
but they were small lensed plastic framed Buddy Holly ones,
they also provided 15 gold rimmed circular John Lennon glasses,

I like your NHS glasses!

are you poor? or just mean?

commercial glasses OTOH are super duper scratch proof + cool looking with nice shaped lenses, well designed
nose-pieces and you have a big choice also they fit better on your face,

you get free education also but apart from some exceptional schools you may
have to share your class with some thugs, but pay (through your nose) and you
get conscientious teachers + fancy equipment and all sorts of extra opportunities,

you want your sprog to learn the piano?

we'll get sproggo to grade 9 on a Steinway with this top tutor, just 40 per lesson,

(I think its called a Steinway and I think its grade 9 but I could be wrong)

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

@karlos

>A trap based emulation which can replace each "emulated" instruction with a jump
>to handling code the first time it is encountered is probably the way to go.
>I think that's how stuff like oxypatcher/cyberpatcher work anyway.


I think the only way to get faster will be via full blown JIT which
is going to be months and months of work, (68k JIT emulation of 68k),

with such a JIT something like move.l d0,d1 will translate as is,
its the position dependent instructions that will be the problem,
pc-relative instructions will also be a problem because the relative
distance can change,


>As for movem, you'd want to check the CPU before making any performance
>assumptions. On the 68040, for instance, it often takes longer than
>multiple move.l instructions (although I'm not totally sure if the same is true
>for 68060).

I have found that the safest way to write assembler is often
just to use simple minded instructions:

the clever instructions often run slower,

68k actually has some instructions which save neither space nor time!

just use an, dn, xyz(an), -(an), (an)+,
and your code will be pretty good, as well as straightforward to
port to a different CPU,

:it will also be much easier to read + debug,


In fact this applies to C as well, if you write a program in a simple
to understand way its often faster than if you try to make it fast,



2 things that assembly language programmers often forget:

1. instructions need to be loaded from ram:

so eg "move.l d0,d1" doesnt reference ram, but the instruction
itself 00 10 001 000 000 000 has to be loaded from ram:,

2. caches:

loop instructions and the stack are almost certainly in a cache so
are read much faster than you think,

whoosh777 is offline   Reply With Quote
Old 04-10-2004, 12:13 PM   #41
bloodline
Master Sock Abuser
Points: 38,902, Level: 100 Points: 38,902, Level: 100 Points: 38,902, Level: 100
Activity: 26% Activity: 26% Activity: 26%
 
bloodline's Avatar
 
Join Date: Mar 2002
Location: London, UK
Posts: 11,888
Blog Entries: 3
Default Re: 68k AGA AROS + UAE => winner!

@whoosh777

Quote:
who is Crumb?
An A.orger who wants inline 68k emulation in x86 AROS :-)

Quote:
>If you find a PC in the trash/skip/bin then dig it out and run AROS on it,
>I have several junk machines found that run AROS fine.

I am trying to decide which path to take, PC or A1?

if I buy an A1 I think I can sell it back to Eyetech,
this reduces the risk of making this purchase,

re: reflashing ROMs, could you also run Mac's OS on Pegasos + A1
as well as Morphos + OS4 + AROS on Macs?
I'm not sure Eyetech would want to buy your A1 back... not with out a massive loss (more than the Price of a PC!).

I suggest you talk to people and look around for the machine that best suits your needs for the lowest cost.
(click the link for BlackTroll for great prices on AROS PCs)

Yes you can run MacOS on both the A1 and the Pegasos, by using a special program called "Mac-on-Linux", but then you need to run Linux too.
MOS and OS4 don't run on the Mac. AROS should though.

Quote:
Some AROS questions:

1. what compiler(s) are used for recompiling AROS programs?
The Default Compiler is gcc. One AROS dev works in SAS/C on a real Amiga though. But to compile for the x86 you need to use gcc. We also have an x86 Assember program, as well as BASIC, False and Python all included with AROS.

Quote:
2. are commercial AROS programs allowed, eg could they sell an AROS version of IBrowse?
Of course you can run commercial apps on AROS. That fits with my personal computer paradigm:

1. You pay for the harware.
2. You pay for the drivers.
3. You pay for the software.
4. But the OS is free and open source.

In fact the AROS licence even allows you to sell AROS, with certain conditions applying, this is how the MorphOS team are able to use the AROS sources (they bug fix the code they use).

I hope to see comercial software appearing for AROS once it gets better established.
__________________
My iPhone Game: Puny Humans -
http://itunes.apple.com/gb/app/puny-...362230281?mt=8
bloodline is offline   Reply With Quote
Old 04-10-2004, 05:01 PM   #42
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!


@bloodline,

from your reply I think I will go down the AROS path,

my line of action being:

1. decide on machine eg A1 or PC?
2. buy machine,
3. familiarise myself with machine,
if its A1 familiarise myself with UBoot,
4. look into what AROS are doing:
either to contribute directly
or to write or port things to AROS,

so step 2 could be in 3 weeks and step 4 in 7 weeks time,


probably I will always be on the outermost periphery of AROS
and all other projects as I prefer to be standalone,


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,


I am sure I can contribute things to AROS though it may be
several months before I can contribute something substantial,


ambitious projects are slow moving, this is why I am reacting slowly,


I can see that AROS only projects will help tip the balance towards AROS,
"portability" is a virtue but "porting" is strategy,


>>who is Crumb?

>An A.orger who wants inline 68k emulation in x86 AROS

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,

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


If the bytes of RAM are $12 $34 $56 $78 ...........

a big endian CPU sees this the way I have written it and

sees the first int of memory as $12345678

a little endian CPU sees this as .......... $78 $56 $34 $12

and reads the first int (address 0) as $78563412 totally different from
what the big endian CPU sees,

thus the 68k emulator is in danger of clashing with the x86 CPU,

eg addresses will be mangled,

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

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

>I'm not sure Eyetech would want to buy your A1 back...
>not with out a massive loss (more than the Price of a PC!).

they have a buy back policy with a depreciation formula,
not sure where I read this, but you could calculate how much
you lose,

I would only sell back the core machine, I would keep the peripherals,
the peripherals anyway wouldnt be bought from Eyetech


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


:you could then open up the marketting policy,


>I suggest you talk to people and look around for the machine that
>best suits your needs for the lowest cost.
>(click the link for BlackTroll for great prices on AROS PCs)

>Yes you can run MacOS on both the A1 and the Pegasos,
>by using a special program called "Mac-on-Linux",
>but then you need to run Linux too.

I was thinking of directly doing it by reflashing the ROM,
but Mac being Mac probably have some proprietory obstacle to prevent this,

>MOS and OS4 don't run on the Mac. AROS should though.

>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?

(preferably gcc2.95.3-4),


>One AROS dev works in SAS/C on a real Amiga though.

SAS/C 650 compiles considerably faster (seconds) than gcc (minutes)
and produces slightly better code unoptimised than gcc -O2 optimisation,

gcc has its own strengths,

if I can use either I always use SAS/C, sometimes though
the only way to do something is with gcc,


eg ISTR that a really huge static array such as 1 million entries
(eg automatically generated look up table such as
int x[]={ 1 , 2 , 3 , ..., 1000000} ;} )
will crash the Amiga linker but I think gcc will be ok,


>But to compile for the x86 you need to use gcc.
>We also have an x86 Assember program, as well as BASIC, False and Python all
>included with AROS.

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

gcc -c xyz.s -o xyz.o

will assemble xyz.s, gcc uses nonstandard cross-platform assembler syntax though
eg for 68k gcc:

.text
.even

.globl _function

_function:

move.l #0,d0 /* this is a gcc assembler comment */

rts

to compile function()


it doesnt understand xref and xdef, .globl is xdef, xref is implicit,
so it wont assemble traditional 68k progs, they need fixing for gcc


I think it uses c style #define's for its macros, so it wont understand
Metacomco's macros,


on x86 it would also be .text, .even, .globl, /* comments */,
which reduces the learning curve,

to compile eg specific 68040 instructions you would type:

gcc -m68040 -c xyz.s -o xyz.o

(the default is 68000 + no FPU),

gcc -m68881 -m68020 -c xyz.s -o xyz.o

for 68020 + FPU code,

>Of course you can run commercial apps on AROS.
>That fits with my personal computer paradigm:
>
>1. You pay for the harware.
>2. You pay for the drivers.
>3. You pay for the software.
>4. But the OS is free and open source.

this is a deciding factor for me,

so eg commercial AROS IBrowse can be closed source?

(I think they wont do it open source)


>In fact the AROS licence even allows you to sell AROS,
>with certain conditions applying, this is how the MorphOS team
>are able to use the AROS sources (they bug fix the code they use).
>
>I hope to see comercial software appearing for AROS once it gets better established.
>


there is an opportunity immediately available for you here:


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,


IBrowse is currently the flagship commercial program for the Amiga,


this would be a major coup,


tell them that you are working towards directly booting AROS on the A1,


AWEB is also now open source, so recompile that and you also get that,
(possibly it may need some work to compile it on gcc)

whoosh777 is offline   Reply With Quote
Old 04-10-2004, 06:05 PM   #43
Karlos
Sockologist
Points: 50,112, Level: 100 Points: 50,112, Level: 100 Points: 50,112, Level: 100
Activity: 2% Activity: 2% Activity: 2%
 
Karlos's Avatar
 
Join Date: Nov 2002
Location: Barishabaad, Sardistan
Posts: 16,643
Blog Entries: 18
Default Re: 68k AGA AROS + UAE => winner!

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.

Quote:
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".

x86 is little endian. 680x0 is big endian. Each has it's advantages and disadvantages.

Fundamentally the only difference is that on a big endian system, the lowest byte address of a multibyte object is the most significant, whereas for a little endian system, its the least significant.

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

On little endian systems like x86, the equivalent code for each of the above fragments generates the same result, affecting the LSB in both cases.

Of the common CPUs kicking around, only load and store architecture (as typified by RISC) tend to support endian swapping modes since all operations they perform are on registers. Never operating directly on memory operands and providing both big and little endian load/store instructions is how the PPC does it, for example.
__________________
OCA
This isn't SCSI... This is SATA!!!
I have CDO. It's like OCD except all the letters are in ascending order. The way they should be.
Core2 Quad Q9450 2.66GHz / X48T / 4GB DDR3 / nVidia GTX275 / Linux x64, AROS, Win64
A1XE 800MHz / 512MB / Radeon 9200 / OS4.1
A1200T BPPC 240MHz / 256MB / Permedia 2 / OS 3.1 - OS3.9, OS4
A1200T Apollo 1240 28MHz / 32MB / Mediator1200 / Voodoo 3000 / OS3.9
A1200D Apollo 1240 25MHz (ejector seat ROM edition) / 32MB
Karlos is offline   Reply With Quote
Old 04-11-2004, 04:00 PM   #44
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!


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 is offline   Reply With Quote
Old 04-11-2004, 06:22 PM   #45
Karlos
Sockologist
Points: 50,112, Level: 100 Points: 50,112, Level: 100 Points: 50,112, Level: 100
Activity: 2% Activity: 2% Activity: 2%
 
Karlos's Avatar
 
Join Date: Nov 2002
Location: Barishabaad, Sardistan
Posts: 16,643
Blog Entries: 18
Default Re: 68k AGA AROS + UAE => winner!

Dude, your posts are huge :-D

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.

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.

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.

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.

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.

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.

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 ;-) )

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.

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.


As for the supervisor stack thing:

1) are you sure that the SSP wasnt already remapped somewhere else in fast ram buy your 030?

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


-edit-

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.
__________________
OCA
This isn't SCSI... This is SATA!!!
I have CDO. It's like OCD except all the letters are in ascending order. The way they should be.
Core2 Quad Q9450 2.66GHz / X48T / 4GB DDR3 / nVidia GTX275 / Linux x64, AROS, Win64
A1XE 800MHz / 512MB / Radeon 9200 / OS4.1
A1200T BPPC 240MHz / 256MB / Permedia 2 / OS 3.1 - OS3.9, OS4
A1200T Apollo 1240 28MHz / 32MB / Mediator1200 / Voodoo 3000 / OS3.9
A1200D Apollo 1240 25MHz (ejector seat ROM edition) / 32MB
Karlos 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