Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: Niding on May 09, 2017, 08:06:38 AM
-
(http://apollo-core.com/bringup/V500AROSBoot2.jpg)
Originally posted by Gunnar von Boehn in;
http://www.apollo-core.com/knowledge.php?b=1¬e=5580
Screenshot showing the NG-AMIGA OS AROS, booting on A500+Vampire.
This screen show normal Amiga video out.
Optimized drivers for SAGA are under development.
-
Good news :-)
it is also important for the future standalone device because Aros includes everything needed out of the box. And of course it solves any legal problem
-
Tempted to order one for my 500+ although probably get in the super long waitlist
-
bad photos but here we go again.
https://ibb.co/cXQAo5
http://ibb.co/ijTrvk
http://ibb.co/dFART5
aros can, not only boot on an amiga. it can utilize an rtg card. it can utilize networking card. it can utilize poseidon stack and usb hardware as it has been reported by another member of a1k. i need yet to test it.
all that using genuine amiga device driver.
above some snapshots of browsing the web with an amiga 4000 and own on aros68k.
the speed is probably comparable to that of netsurf.. google needs few seconds to load, even if some graphics may load later, but the page is usable.
-
Originally posted by Gunnar von Boehn in:
http://www.apollo-core.com/knowledge.php?b=1¬e=5768&z=xjN63L
"There is some movement of AROS, the open source AMIGA OS.
Three things are needed to build AMIGAs.
A) A good 68K CPU
B) The real AMIGA chipset, ideally enhanced
C) AMIGA OS
AROS can offer the OS.
To Support this Open Movement, we hereby announce that we will open source SAGA (the enhanced AMIGA chipset)."
The Apollo team has made a enhanced 68k CPU, cloned and enhanced the chipset so only a modern OS is missing.
-
bad photos but here we go again.
https://ibb.co/cXQAo5
http://ibb.co/ijTrvk
http://ibb.co/dFART5
aros can, not only boot on an amiga. it can utilize an rtg card. it can utilize networking card. it can utilize poseidon stack and usb hardware as it has been reported by another member of a1k. i need yet to test it.
all that using genuine amiga device driver.
above some snapshots of browsing the web with an amiga 4000 and own on aros68k.
the speed is probably comparable to that of netsurf.. google needs few seconds to load, even if some graphics may load later, but the page is usable.
Agreed, horrible photos.
So, what was the point?
BTW - I did not know that anyone had gotten AROS 68K to work with RTG cards yet.
How long until that extends to PCI video cards?
-
I wouldn't have thought it matters how a graphics card is connected as long as the driver conforms to an RTG standard supported by the operating system.
-
Agreed, horrible photos.
feels good to deliver something you can again complain about.
So, what was the point?
simply thst aros isnt simply booting on amiga hardware. it is a further proof that is is binaty compatible, for those who constantly question it. it is also about to be usable. what you see is a webkit css browser in action, even if outdated by almost ten years, it is working for basic tasks.
BTW - I did not know that anyone had gotten AROS 68K to work with RTG cards yet.
How long until that extends to PCI video cards?
amiga rtg cards have been working with it since years.
-
I wouldn't have thought it matters how a graphics card is connected as long as the driver conforms to an RTG standard supported by the operating system.
it does matters. aros pci subsytsem device drivers for amiga pci bridges are not complete.
-
feels good to deliver something you can again complain about.
Glad to be of service. :)
Still, those were A2000s, weren't they?
That is reassuring.
And you can't cobble a PCI bus to that anyway.
it does matters. aros pci subsytsem device drivers for amiga pci bridges are not complete.
Bingo, Amiga PCI bridges are pretty kludgy.
I'm not sure you can fault AROS for incomplete support here.
Those devices are fairly proprietary.
Still, it would be nice to support a Radeon 9200 or a Voodoo3 instead of a Zorro bus card.
-
Still, those were A2000s, weren't they?
no. a4ks- dont you recognize an amiga when you see one?
Bingo, Amiga PCI bridges are pretty kludgy.
I'm not sure you can fault AROS for incomplete support here.
i dont fault anyone. its a question fo time, priorities and dedication. netbsd has support for those.
-
no. a4ks- dont you recognize an amiga when you see one?
I only gave it a brief glance.
And I wasn't really expecting to see a machine that isn't compatible with a Vampire accelerator pictured in a thread about Vampires and AROS.
-
AROS always worked on old amiga hardware
-
Is Mike still around here? Would be interesting to see if he'll be able to/want to add the SAGA code to the FPGA Arcade boards.
-
AROS always worked on old amiga hardware
Great statement of the obvious (fact is it really needs something powerful like an A4000 if you're not using a Vampire), but again, the thread is about running AROS on Vampire equipped hardware.
-
Is Mike still around here? Would be interesting to see if he'll be able to/want to add the SAGA code to the FPGA Arcade boards.
Hi, sometimes yes.
I've no idea what SAGA is? If it's documented / open source then potentially, I see it as a 3rd party add-in to the original machines, much like an RTG graphics card.
I'm trying to model the original hardware/CPU as accurate as possible. Additions I have made, such as expanding the address range of chipset memory pointers for example, are configurable.
I'm spending time working on a Slower CPU which is more accurate :)
(and the rasp pi compute module running just CPU emulation)
/Mike
-
Hi, sometimes yes.
I've no idea what SAGA is? If it's documented / open source then potentially, I see it as a 3rd party add-in to the original machines, much like an RTG graphics card.
I'm trying to model the original hardware/CPU as accurate as possible. Additions I have made, such as expanding the address range of chipset memory pointers for example, are configurable.
I'm spending time working on a Slower CPU which is more accurate :)
(and the rasp pi compute module running just CPU emulation)
/Mike
It's a Verilog clone of the AGA chipset but with extra features that weren't part of the original chipset. In the thread linked below Gunnar announced he's open sourcing it.
-
cool to have AROS be vampirzed too :)
-
I just read the thread. We already have two hdl implementations of the AGA chipset, mine and the minimig derived one. We have extensions such as extra memory, RTG, AHI audio etc already.
I guess the game here is to add propriety extra features and build a new platform, but that potentially breaks back compatibility. For them it makes sense to open source that part of the design to encourage people to use those features. Personally I'm much more interested in a new, cycle accurate (and high performance compatible) open source CPU, which is what we are working towards.
Why not just compile AROS to cheap modern CPU platforms?
/Mike
-
Open Source Amiga, don't exists.
It's Amiga or not.
AROS = Amiga REPLACEMENT O.S.
So, it's "like" but.
-
Open Source Amiga, don't exists.
It's Amiga or not.
AROS = Amiga REPLACEMENT O.S.
So, it's "like" but.
its amiga it runs on, and it runs amiga software on it, which is all that matters to me.
-
Open Source Amiga, don't exists.
It's Amiga or not.
AROS = Amiga REPLACEMENT O.S.
So, it's "like" but.
Amiga is hardware.
AROS is software.
AROS runs on Amiga hardware.
Your problem is?
-
I just read the thread. We already have two hdl implementations of the AGA chipset, mine and the minimig derived one. We have extensions such as extra memory, RTG, AHI audio etc already.
I guess the game here is to add propriety extra features and build a new platform, but that potentially breaks back compatibility. For them it makes sense to open source that part of the design to encourage people to use those features. Personally I'm much more interested in a new, cycle accurate (and high performance compatible) open source CPU, which is what we are working towards.
Why not just compile AROS to cheap modern CPU platforms?
/Mike
I must say I'm more interested in the ARM board being made to run a 68k emulator and appear as a real 68k cpu to the Amiga than anything else at the moment.
As i understand it the SAGA core is fully backward compatible with the original AGA chipset though.
-
Amiga is hardware.
AROS is software.
AROS runs on Amiga hardware.
Your problem is?
I don't have any problem.
But I call the things by his name.
Amiga is hardware and his OS.
Others is "like".
-
But I call the things by his name.
exactly. in this case the os is aros. simple, really.
-
"
I must say I'm more interested in the ARM board being made to run a 68k emulator and appear as a real 68k cpu to the Amiga than anything else at the moment.
though.
This is what I'm doing. The FPGA will have a cycle accurate 68000/20 based closely on the original device, probably with some optional speed ups similar to the current design.
The 68060 add on board is pretty much done, and I'm playing with the PI compute module as a fast 68060 emulator. It has something called SMI which allows me to directly connect it to the FPGA. As the PI is just running the CPU, it's very fast even on a single core.
David has been doing some excellent bare-metal work here emulating the 6502.
https://github.com/hoglet67/PiTubeDirect
-
I must say I'm more interested in the ARM board being made to run a 68k emulator and appear as a real 68k cpu to the Amiga than anything else at the moment.
As i understand it the SAGA core is fully backward compatible with the original AGA chipset though.
you might change your mind if this ever happens :
"But we actually want to reach more.
We know that we can put APOLLO in to an ASIC.
And we know that then we can compete and beat even G3/G4/.. latest PowerPC or ARM Asics in performance."
(citation : ) http://www.apollo-core.com/knowledge.php?b=1¬e=5768
-
I don't have any problem.
But I call the things by his name.
Amiga is hardware and his OS.
Others is "like".
No, Amiga is hardware. There are many OS's that run on Amiga hardware. An Amiga doesn't stop being an Amiga because you run Linux/MINIX/BSD/MorphOS/TOS/AROS on it.
-
"
This is what I'm doing. The FPGA will have a cycle accurate 68000/20 based closely on the original device, probably with some optional speed ups similar to the current design.
The 68060 add on board is pretty much done, and I'm playing with the PI compute module as a fast 68060 emulator. It has something called SMI which allows me to directly connect it to the FPGA. As the PI is just running the CPU, it's very fast even on a single core.
David has been doing some excellent bare-metal work here emulating the 6502.
https://github.com/hoglet67/PiTubeDirect
Looks good!
Are there any of the x86-based RPi style boards that have similar SMI functionality? I've always fantasised about an accelerator card that was nothing but a screaming fast x86 running a CPU emulator. :)
-
I just read the thread. We already have two hdl implementations of the AGA chipset, mine and the minimig derived one. We have extensions such as extra memory, RTG, AHI audio etc already.
I guess the game here is to add propriety extra features and build a new platform, but that potentially breaks back compatibility. For them it makes sense to open source that part of the design to encourage people to use those features. Personally I'm much more interested in a new, cycle accurate (and high performance compatible) open source CPU, which is what we are working towards.
Why not just compile AROS to cheap modern CPU platforms?
/Mike
Where do I start?
- AROS runs hosted on Linux on the RasPi already. There's hardly any software that runs on ARM AROS. Same goes for x86 and AMD64.
- Running UAE4ARM on a RasPi 3 is good enough to emulate an A1200 quite well already.
- The SAGA core implements the chunky and YUV modes as a third playfield by re-purposing a register in AGA that was intended for a greyscale monitor that was never produced. It's not a separate RTG mode, it's all integrated. THat's actually the main reason for AROS: new graphics drivers that work as one.
- Since the closed-source 68080 core performs as well per clock as a Core2 Solo, it'll keep up with the modern systems quite nicely! Especially when compared to an ancient 68060 clocked at twice the clock speed! Note: The minimum clock speed of the '080 is 78 MHz already so I hope you can clock your 68060 board at a minimum of 144 MHz... ;-)
-
I just read the thread. We already have two hdl implementations of the AGA chipset, mine and the minimig derived one. We have extensions such as extra memory, RTG, AHI audio etc already.
I guess the game here is to add propriety extra features and build a new platform, but that potentially breaks back compatibility. For them it makes sense to open source that part of the design to encourage people to use those features. Personally I'm much more interested in a new, cycle accurate (and high performance compatible) open source CPU, which is what we are working towards.
Why not just compile AROS to cheap modern CPU platforms?
/Mike
you can compile AROS almost for anything today including ARM, X86, ARM64 and even PPC. Thanks for hint...
-
I don't have any problem.
But I call the things by his name.
Amiga is hardware and his OS.
Others is "like".
in this case... why do you use a SAM?
-
it sounds like he dislikes competition...
-
Where do I start?[/LIST]
- AROS runs hosted on Linux on the RasPi already. There's hardly any software that runs on ARM AROS. Same goes for x86 and AMD64.
The CM3 module is emulating just the CPU - so it looks like a fast 68K
- Running UAE4ARM on a RasPi 3 is good enough to emulate an A1200 quite well already.
Running the chipset in the FPGA and the CPU in the ARM gives (in my view) the best of both worlds. And there will be a CM4 etc in future cheaply to speed up the CPU. It also has local memory and HDMI out obviously as well.
- The SAGA core implements the chunky and YUV modes as a third playfield by re-purposing a register in AGA that was intended for a greyscale monitor that was never produced. It's not a separate RTG mode, it's all integrated. THat's actually the main reason for AROS: new graphics drivers that work as one.
If this is documented then it would be trivial to add the additional modes to any of the current hardware FPGA platforms
- Since the closed-source 68080 core performs as well per clock as a Core2 Solo, it'll keep up with the modern systems quite nicely! Especially when compared to an ancient 68060 clocked at twice the clock speed! Note: The minimum clock speed of the '080 is 78 MHz already so I hope you can clock your 68060 board at a minimum of 144 MHz... ;-)
113MHz, but it has MMU and FPU.
-
you might change your mind if this ever happens :
"But we actually want to reach more.
We know that we can put APOLLO in to an ASIC.
And we know that then we can compete and beat even G3/G4/.. latest PowerPC or ARM Asics in performance."
(citation : ) http://www.apollo-core.com/knowledge.php?b=1¬e=5768
Sounds remarkably clueless for someone that has produced a working core.
Current predictions of faster speeds in FPGA are extremely unlikely without adding cache to the processor.
Much higher speeds in an ASIC will require further re-engineering of the cpu.
Do you actually think you just turn up the clock speed of a cpu like a rheostat in an analog circuit?
A small team of developers is going to make a 68K derivative outperform 2GHz 64bit PPC and ARM cpus?
"we know..."
REALLY?
When monkeys fly out of Gunnar's butt.
-
@mikej:
actually your plan to emulate solely the 68kcpu on another rchitecture and making it look to the system like a fast 68k is what i and few others proposed all along. the difference is, that i thought in this case of an amiga accelerator design.
your concept sounds very good nevertheless and imho is a good complementary alternative to apollo/vampire approach/proposal. i wish you a lot of luck with it and stand by watching. how it unfolds.
what concerns aros 68k its very easy tm make it boot on amiga hardware. so it shouldnt be a problem to boot it on your board. i think there are people doing this (kola?). aros is working with p96 drivers via wrapper. they need to be loaded via arosbootstrap.
-
@ mikej
Sounds good Mike.
And the goals are realistic.
Hey, functional MMU and FPUs, what an idea!
Instead of focusing on features that aren't supported by existing software.
-
@Iggy
Gunnar never claimed to outperform 2 Ghz CPUs... he wants to beat them per Mhz. He is a CPU guy so it is his personal motivation obviously (next to other things)
Regarding CISC they say it would be possible to do one with 1.2 Ghz. If true I do not know
-
Sounds remarkably clueless for someone that has produced a working core.
Current predictions of faster speeds in FPGA are extremely unlikely without adding cache to the processor.
Much higher speeds in an ASIC will require further re-engineering of the cpu.
Do you actually think you just turn up the clock speed of a cpu like a rheostat in an analog circuit?
A small team of developers is going to make a 68K derivative outperform 2GHz 64bit PPC and ARM cpus?
"we know..."
REALLY?
When monkeys fly out of Gunnar's butt.
PPC and ARM are RISC machine punching bags. Gunnar used to work on PowerPC cores at IBM so he should know. It AMD64 that's the instruction set to beat.
As for caches in an FPGA, there are bigger and more expensive FPGA models than what we're using....
Looking forward to the butt monkeys in Germany. ;)
-
113MHz, but it has MMU and FPU.
Do you see any possibility to make an acc card for "real" amiga hardware using the RPi Compute module?
-
Gunnar used to work on PowerPC cores at IBM so he should know.
Yeah, he _used_ to. What happened?
-
@Iggy
Gunnar never claimed to outperform 2 Ghz CPUs... he wants to beat them per Mhz. He is a CPU guy so it is his personal motivation obviously (next to other things)
Regarding CISC they say it would be possible to do one with 1.2 Ghz. If true I do not know
That is closer to reality. It will still require a lot of reworking.
The problem with "quotes" is that they are usually fragmentary and often taken out of context.
That "we know" comment being a good example.
Inferring "we know" an ASIC descendant of the 68080 will outperform high end PPC and ARM cpus (with no mention of a "per mhz" basis).
-
Hey, functional MMU and FPUs, what an idea!
as a comptent person you probably are aware that 68k mmu emulation wont work with jit. without jit emulated 68k cpu is slower than apollo core. that has been measured.
-
as a comptent person you probably are aware that 68k mmu emulation wont work with jit. without jit emulated 68k cpu is slower than apollo core. that has been measured.
I was talking about the real 68K here. What is possible on the quad core 1G ARM remains to be seen when it is just running CPU emulation.
I'm more interested in performance per $. A CM3 module is something like 30$ and has 1G RAM and HDMI out. It's tough to compete with that with the FPGA.
I started this looking at the zynq SOC chips which have a fast FPGA device and on-board ARM, but it's still more cost effective to strap the CM3 module onto a spartan7 FPGA or something similar.
http://www.fpgaarcade.com/punbb/viewtopic.php?id=1221
-
Do you see any possibility to make an acc card for "real" amiga hardware using the RPi Compute module?
This was discussed. I have no interest in doing it, the accelerator market is somewhat saturated. It's much easier to interface the compute module directly to the FPGA as you can control timing. To fit in a 68K socket you would need a bridge device so you are losing the cost benefit. Perhaps a zynq with embedded CPU core would be interesting, but they are quite pricey.
"We know that we can put APOLLO in to an ASIC."
I can put anything into an ASIC. My day job is working for a fables ASIC house that actually makes chips (specialist high performance 28nm CPUs amusingly). I keep meaning to run the TG68K CPU through the Cadence synthesiser and get a timing estimate - it would probably go at least 500Mhz, maybe more.
That doesn't mean it's going to happen though. Licence costs for the tools, cells and memory compilers are very steep, as are the production costs. We make high price devices so there is a business case. I don't see a fast 68K processor selling for more than a few$ - it's got to compete against Atmel etc who make really quite nice ARM based SOCs.
There is test, characterisation and a million other things to consider apart from having just the RTL.
NXP still make 68K devices. While making a few hobby FPGA designs is not going to interest them, they will aggressively protect their IP if you try to make a business out of it.
The vampire core is fun and seems to work well, but I don't believe it's going to take over the world (unless ARM was to vanish tomorrow).
/Mike
-
This was discussed. I have no interest in doing it, the accelerator market is somewhat saturated. It's much easier to interface the compute module directly to the FPGA as you can control timing. To fit in a 68K socket you would need a bridge device so you are losing the cost benefit. Perhaps a zynq with embedded CPU core would be interesting, but they are quite pricey.
"We know that we can put APOLLO in to an ASIC."
I can put anything into an ASIC. My day job is working for a fables ASIC house that actually makes chips (specialist high performance 28nm CPUs amusingly). I keep meaning to run the TG68K CPU through the Cadence synthesiser and get a timing estimate - it would probably go at least 500Mhz, maybe more.
That doesn't mean it's going to happen though. Licence costs for the tools, cells and memory compilers are very steep, as are the production costs. We make high price devices so there is a business case. I don't see a fast 68K processor selling for more than a few$ - it's got to compete against Atmel etc who make really quite nice ARM based SOCs.
There is test, characterisation and a million other things to consider apart from having just the RTL.
NXP still make 68K devices. While making a few hobby FPGA designs is not going to interest them, they will aggressively protect their IP if you try to make a business out of it.
The vampire core is fun and seems to work well, but I don't believe it's going to take over the world (unless ARM was to vanish tomorrow).
/Mike
500MHz? Sounds realistic with a little tweaking.
Possibly higher with cache and a bit more work.
But once its finalized in dedicated silicon, no more changes...;-(
-
500MHz? Sounds realistic with a little tweaking.
Possibly higher with cache and a bit more work.
But once its finalized in dedicated silicon, no more changes...;-(
You can park some wafers during production so you can do metal mask changes later without re-running the whole process. Let's you correct minor bugs for less cash.
The amount of verification done on ASIC designs is huge to avoid this kinda thing. ...
-
You can park some wafers during production so you can do metal mask changes later without re-running the whole process. Let's you correct minor bugs for less cash.
The amount of verification done on ASIC designs is huge to avoid this kinda thing. ...
At least we are talking about somewhat realistic speeds again.
And here is where your idea of an accurate recreation really helps.
But an '020 at a few hundred MHz still faces a pretty tough competition from the much more competent superscalar '060.
Ideally, a new 68K would be as compatible as the '020/'030 but have pipelining and scalar advantages that would speed up operations and make them more concurrent.
-
as a comptent person you probably are aware that 68k mmu emulation wont work with jit.
It is perfectly possible to emulate an mmu in a jit.
You could probably even use the native mmu.
-
Ideally, a new 68K would be as compatible as the '020/'030 but have pipelining and scalar advantages that would speed up operations and make them more concurrent.
Hi Iggy -
This is what the Apollo core does. I am sure you know that but just in case you don't, there is a good write-up on the Apollo core wiki in the instruction fusing, bonding and other goodness. I believe most instructions are down to 1 clock.
Cheers!
-
It is perfectly possible to emulate an mmu in a jit.
You could probably even use the native mmu.
thats not what toni says, im afraid.
-
Ideally, a new 68K would be as compatible as the '020/'030 but have pipelining and scalar advantages that would speed up operations and make them more concurrent.
The whole "compatible as the 020/030" issue was pretty much solved in the 1990's. I'd rather not have another project poisoned.
If someone is going to do something like a 68060, then doing a 68060 clone would be ideal.
-
according to what ive been told again, 020 represents the widest possible instruction set of the whole 68k family. all the others cpus except few small exceptions use the subset of instructions available on 020 (and 6888x, counting fpu in). apollo identifies itself as 040 but provides all the extensions there have been to 020 instruction set.
so, if this is true, apollo core is functionally the most compatible alround 68k implementation there is.
-
according to what ive been told again, 020 represents the widest possible instruction set of the whole 68k family. all the others cpus except few small exceptions use the subset of instructions available on 020 (and 6888x, counting fpu in). apollo identifies itself as 040 but provides all the extensions there have been to 020 instruction set.
so, if this is true, apollo core is functionally the most compatible alround 68k implementation there is.
"020 represents the widest possible instruction set of the whole 68k family"
Fair statement.
The '030 isn't really that different.
"and 6888x, counting fpu in"?
FPU is now functional?
-
according to what ive been told again, 020 represents the widest possible instruction set of the whole 68k family. all the others cpus except few small exceptions use the subset of instructions available on 020 (and 6888x, counting fpu in). apollo identifies itself as 040 but provides all the extensions there have been to 020 instruction set.
so, if this is true, apollo core is functionally the most compatible alround 68k implementation there is.
I think old software mis-identifies the Apollo as an 040, I've also seen old software mis-identify it as an 060 recently where-as some new software can correctly identify it as an Apollo "68080". So it would be wrong to say the Apollo identifies itself as an 040.
-
what i wanted to say actually is that i suspect, whatever the core is being identified as, the software supposedly will work, as all instructions are available.
-
a member of apollo team has posted a video of aros running on vampire expanded amiga.
maybe not that much to see but the degree of responsivity and the 68k cpu recognition is probably what was intended to be demonstrated.
https://youtu.be/V83Az5BrTow
config, apparently: V500 in an A2000 + ZorroII PicassoIV (1024x768/16).
-
128MB of addressable memory (chip+fast), SOLD!
Pack me one of those mofos up, we now have enough power to run AROS on an A2000.
-
thats not what toni says, im afraid.
What does toni say?
Because toni has a lot of experience with winuae and not a hypothetical jit that runs natively on x64. So I can't tell whether you misunderstood what he was saying, or whether to disagree with him.
what i wanted to say actually is that i suspect, whatever the core is being identified as, the software supposedly will work, as all instructions are available.
Unless it needs the instructions to trap.
-
a member of apollo team has posted a video of aros running on vampire expanded amiga.
maybe not that much to see but the degree of responsivity and the 68k cpu recognition is probably what was intended to be demonstrated.
https://youtu.be/V83Az5BrTow
config, apparently: V500 in an A2000 + ZorroII PicassoIV (1024x768/16).
That really was a beautiful sight! This is what happens when people cooperate and share ideas. On one hand we have the open source AROS and on the other side the pure joy to follow technology coming out of Team Apollo. This is real progress , this is what all that work was for and the more open we get the more the promise of an exciting future starts to shine. Let us continue to build on these partnerships.
-
yesterday toni fixed an annoying bug we were tracing for years, that prevented aros to fully boot from some internal amiga ide controllers (a4k, probably a600), which may have also caused some problems to boot it on vampirized hardware. tested it succesfully this night and hope toni commits it soon.. ;)
-
This thread could also be titled
[AROS] The AMIGA Future Is NOW! Vampire!
-
yesterday toni fixed an annoying bug we were tracing for years, that prevented aros to fully boot from some internal amiga ide controllers (a4k, probably a600), which may have also caused some problems to boot it on vampirized hardware. tested it succesfully this night and hope toni commits it soon.. ;)
If it's this https://github.com/ezrec/AROS-mirror/commit/7f51cc5dcc9b49e29bdc99b1007a91cd676da10d then
Then the patch only skips reading the alternative status register if you have an IDE doubler. So I would expect it will only affect you if you are using an IDE doubler.
Reading the status register acknowledges an interrupt and you're supposed to write your code so that it only reads it when you're processing interrupts. The alternative status register doesn't acknowledge interrupts, but you can't read it when you are using an IDE doubler. IDE has cs0 and cs1, each has the potential for 8 registers but cs1 only has 2 that aren't commonly used (I think the original scsi.device from commodore doesn't use them). IDE doublers use the amiga cs1 for the second set of drives cs0 & don't give any way of accessing the drives cs1 registers.
I've not found what it actually does if you ask for the alt status and it can't read it. Although if it falls back to reading the actual status, then it would explain the behaviour.
Fortunately in that place the alt status is only used in DEBUG mode for logging, so now it's not being read then it's just logging the wrong value.
This line will potentially cause a problem if you have an IDE doubler and are using irq mode and compile in DEBUG:
DATAPI(bug("[ATAPI] Status after packet: %lx\n", ata_ReadAltStatus(bus)));
Ideally the code would be changed to avoid needing to read the alternative status register in all circumstances, at least it should only use it for logging and skip the logging when you are using an IDE doubler.
-
@psxphill
i cannot judge this, as im not familiar with the lowlevel hardware subjects. in fact tonis patch fixed ide behaviour on two different a4000 models i tried this with (no ide doubles) and didnt negatively affected a1200 (tested).
i passed your comments over to toni. but considering your insight maybe it would be better if you talked to him directly about such matters. you could join in aros dev ml, if only to see whats been posted and eventually comment on it.
the problem booting vampire is still unsolved and vampire related code starts to be poured in. i think it would be valuable to have competent people review and discuss it.
-
i cannot judge this, as im not familiar with the lowlevel hardware subjects. in fact tonis patch fixed ide behaviour on two different a4000 models i tried this with (no ide doubles) and didnt negatively affected a1200 (tested).
It's certainly possible that there is a bug so that it always thinks the a4000 cannot access "alt io". I don't believe it's an actual limit on the a4000 because this http://amigakit.leamancomputing.com/catalog/product_info.php?products_id=599 exists.
It may also get it wrong on a600/a1200 or vampire but I can't find that part of the code in the git mirror, so either it's missing from git or the code is generated with some macro fu that makes it hard to search for.
This is when the alt io stuff was originally added.
https://trac.aros.org/trac/changeset/46722/AROS
This is where ide doublers are detected....
https://github.com/michalsc/AROS/blob/master/arch/m68k-amiga/hidd/gayle_ata/probe.c
and then this is where they are used
https://github.com/ezrec/AROS-mirror/blob/148fa41943c6090ddc3a82efa2259a43ce23faea/AROS/arch/m68k-amiga/devs/ata/ata_amiga.c
But I haven't figured out how that builds a ATA_BusInterface yet.
FWIW it looks like whoever wrote https://en.wikibooks.org/wiki/Aros/Developer/Docs/Devices/ATA knew about the issues too.
-
from toni:
Do I really need to explain this when it should have been obvious by
actually looking at the code?
AltStatus is by design not used with A600/A1200/A4000 IDE because it is
practically guaranteed there are Gayle/A4000 IDE based IDE designs that
don't implement altstatus (or devcon) at all or have some weird internal
IDE doubler hardware because Commodore A600/A1200/A4000 IDE driver never
used either registers.
altstatus read gets automatically redirected to normal status read if
altio is not set which caused the original problem because this code was
also waiting for interrupt at the same time. It was obvious bug and
obvious fix, driver is designed to support non-AltIO mode but didn't
check it properly here.
Setting it to FF is just not to cause compiler warnings and also set it
to impossible value, anyone who reads the log should also know what it
can mean.
please, dont shoot the messanger;)
-
FWIW it looks like whoever wrote https://en.wikibooks.org/wiki/Aros/Developer/Docs/Devices/ATA knew about the issues too.
must be jason, the other aros68k developer, who is now gone inactive. as you see he didnt get past this point, which is now fixed by toni.
-
from toni:
please, dont shoot the messanger;)
That explains it. I was starting to come to the conclusion that it never read the alt status on amiga, even though the code in some places was giving the impression that it would. I couldn't track down where it fell back to reading the actual status. Aros is unfortunately not a panacea. You can blame me for being dumb, but
building barriers around source code that mean you can't just follow code easily is a bad idea. It's why I stepped out of AROS development in the first place, I was coincidentally building a custom 68k kickstart but I only had an amiga at home and wrestling with building it with the compilers available was just too much hassle. I made some progress & had "something" that booted, but ultimately I got a Windows laptop (circa 2001) and my Amiga use faded away.
"because it is
practically guaranteed there are Gayle/A4000 IDE based IDE designs that
don't implement altstatus (or devcon) at all"
I disagree with "practically guaranteed", the registers are in the drive & All gayle/a4000 IDE designs support reading the registers or you wouldn't be able to fit a 4 port ide adapter in the first place. It's only the ide doubler that affects it & in your test sample then none of them had one. However I'd argue against using alt status apart from logging and not to read it at all when it's impossible to read it, which in this case is what toni did. However there are still a load of cases where it reads the alt status, some in DEBUG code and some are always read which he hasn't done anything about. Which leaves race conditions waiting to happen. I am perfectly happy to leave him to it.
-
"because it is
practically guaranteed there are Gayle/A4000 IDE based IDE designs that
don't implement altstatus (or devcon) at all"
I disagree with "practically guaranteed", the registers are in the drive & All gayle/a4000 IDE designs support reading the registers or you wouldn't be able to fit a 4 port ide adapter in the first place. It's only the ide doubler that affects it & in your test sample then none of them had one. However I'd argue against using alt status apart from logging and not to read it at all when it's impossible to read it, which in this case is what toni did. However there are still a load of cases where it reads the alt status, some in DEBUG code and some are always read which he hasn't done anything about. Which leaves race conditions waiting to happen. I am perfectly happy to leave him to it.
look: discussing it with me doesnt make any sense. you are on eab. if you dont want to register on aros ml, yo might still open a thread there and post your considerations and proposals, toni might or might not comment upon. thats how things may be trated constructive rather than only talking without any consequences.
what concerns c++ classes and stuff, bebbos amiga-m68k gcc6.3.0 patches will probably find their way on aros. toni expressed interest and bebbo has joined the list. he even started experimenting with compiling aros with his compiler but he is now silent for a while, both on eab as on aros ml. hope this will not fall asleep.
-
yesterday toni fixed an annoying bug we were tracing for years, that prevented aros to fully boot from some internal amiga ide controllers (a4k, probably a600), which may have also caused some problems to boot it on vampirized hardware. tested it succesfully this night and hope toni commits it soon.. ;)
Excellent - that may also fix the same issue for MIST and Minimig?!
I must test when I get home! :)
-
@kolla
im simply not aware of these issues. let alone aros team is. can you get serial log in case it doesnt boot?
-
@kolla
im simply not aware of these issues. let alone aros team is. can you get serial log in case it doesnt boot?
I can give it a try when I finally get home... :p
Anyways, it may be faster to just contact Chaos, a developer of the Minimig core for the MiST and also the original Minimig, he is well aware about this problem.
http://somuch.guru/minimig/minimig-mist/#comment-3192
:)
-
I can give it a try when I finally get home... :p
Anyways, it may be faster to just contact Chaos, a developer of the Minimig core for the MiST and also the original Minimig, he is well aware about this problem.
http://somuch.guru/minimig/minimig-mist/#comment-3192
:)
sorry. on the site you linked to i dont see how i can contact him direcly to make him aware. either you supply me with contact details via pm or you might want to contact him yourself. keep in mind its convenient to keep people working on something offloaded rather than forward everything up to them. they are too few. at least thats what im trying to do myself. an effort like that to be succesful needs to be distributed.
-
Why is AROS on Vampire (future standalone or existing one) better thing than AROS on x64 hardware?
What are the advantages?
-Dooz
-
Why is AROS on Vampire (future standalone or existing one) better thing than AROS on x64 hardware?
What are the advantages?
-Dooz
its like asking in what amiga is better than a current pc.
it isnt better, its just another platform, except that you can run all the amiga software natively. that extends the available propsal enormously.
btw, a bit offtopic, but heres aros running a warpos demo on my 150mhz cyberstormppc:
https://ibb.co/k0Kt3F
-
its like asking in what amiga is better than a current pc.
it isnt better, its just another platform, except that you can run all the amiga software natively. that extends the available propsal enormously.
btw, a bit offtopic, but heres aros running a warpos demo on my 150mhz cyberstormppc:
https://ibb.co/k0Kt3F
Thanks wawrzon for explanation since I am not very familiar with AROS. More questions I have.....
So in AROS 68k I can run AmigaOS3 68k applications directly without recompile at the same speed like Vampire card that we have today? Also I can use RTG or SAGA chipset like real AGA? Also with improved AGA in the future?
On the other hand what happens when I start AOS3 68k application under AROS x86? I guess it is emulated with 68k software emulator under x86 AROS or application must be recompiled?
Thanks!
-Dooz
-
Thanks wawrzon for explanation since I am not very familiar with AROS. More questions I have.....
So in AROS 68k I can run AmigaOS3 68k applications directly without recompile at the same speed like Vampire card that we have today? Also I can use RTG or SAGA chipset like real AGA? Also with improved AGA in the future?
On the other hand what happens when I start AOS3 68k application under AROS x86? I guess it is emulated with 68k software emulator under x86 AROS or application must be recompiled?
Thanks!
-Dooz
Just to expand on warwzon mentioned:
If using AROS on 68k, as warwzon said, you get to use the pool of existing 68k software just 'as is', you get to use your classic Amiga hardware that you know and love, and potentially AROS for this platform can become very polished as it's not a constantly moving taget as is the case with the pc, with fully documented hardware. As I understand it you are able to use either AGA or RTG, and I think I read somewhere thay SAGA drivers are planned to be developed too.
If using AROS on a pc (with the notable caveat of sourcing compatable hardware), you get the pure grunt of a multi-GHz machine (and hopefully in the not too distant future, multi-core support). This means easily watching movies, rapid browing of the internet, detailed 3d gaming (open source titles that have been ported, e.g. Cube) and the option of running natively on netbooks and laptops. However, as you've identified, if you want to use 68k software you do need to run it enulation via Janus (a fork of UAE). There are various integration options that make these look like they are running native, but they do slow down the enulation. I just run an OS3.x workbench on its own screen and launch my 68k applicaitons from there; it only takes 15 s or so to boot and its easy enough to switch between Wanderer and Workbench via left-command M.
Of course, there is no need to choose between the two; just have both. AROS is of course free, presumably you have the Amiga hardware and, again stressing the careful choice of compatable hardware, a pc or laptop for x86 AROS could be picked up pre-loved for as little as £30, or maybe even for free with if your current x86 hardware is compatable. You can set it up to dual-boot too, so you could have it installed alongside Linux or Windows on a machine.
Cheers,
Nigel.
-
So in AROS 68k I can run AmigaOS3 68k applications directly without recompile at the same speed like Vampire card that we have today?
without recompile. aros supports ks1.x-3.x apps. which doesnt mean that just everything will run fine as of today. but this is aimed at. what concerns speed, the os itself isnt as fast as the genuine one yet, but we are getting there. many things like larger png icons are slowing down the experience initially, but running a binary is at the same or close to the same speed as on the original os.
Also I can use RTG or SAGA chipset like real AGA? Also with improved AGA in the future?
yes.
On the other hand what happens when I start AOS3 68k application under AROS x86? I guess it is emulated with 68k software emulator under x86 AROS or application must be recompiled?
-Dooz
i never attempted that. to be honest i dont know if and how to run 68k binary under aros x86. there have been at least some une implementation ready or underway and i guess distributions provide that. other than that the app needs to be recompiled to run native on the target platform.
-
to be honest i dont know if and how to run 68k binary under aros x86.
You have to run them under uae, which would either use kickstart or aros 68k. It's possible to have the 68k windows appear as if they are on the x86 desktop. You can't use 68k libraries in x86 programs etc.
To mix 68k and x86 applications under the same aros instance would require something like the amithlon gcc compiler that generated x86 code that was big endian. I don't think anyone has ever looked at doing that, but for me this would be awesome. Especially with a decent jit that can compile 68k & ppc binaries into x86 (or x64).
-
You have to run them under uae, which would either use kickstart or aros 68k. It's possible to have the 68k windows appear as if they are on the x86 desktop. You can't use 68k libraries in x86 programs etc.
To mix 68k and x86 applications under the same aros instance would require something like the amithlon gcc compiler that generated x86 code that was big endian. I don't think anyone has ever looked at doing that, but for me this would be awesome. Especially with a decent jit that can compile 68k & ppc binaries into x86 (or x64).
there was a project that tried to implement something like Petunia on X86 Aros but failed. I cannot remember name but found it on web. I could try to find it if you are interested, cannot say much how far it got
-
@dooz
as some already explained Aros 68k works on both amiga hardware and UAE using its own kickstarts. You can execute basically any 68k software written and compiled for 3.x as long the needed libs are implemented. You can even add libs or replace existing ones like replacing Zune with MUI 3.8 what I do in my distribution. Of course when using Zune you can also run Aros specific software.
On the other platforms (X86, X64 and ARM) you can only run Aros software compiled for the specific platform. You cannot directly run 68k software in X86 because there is nothing like Petunia but you can use UAE for it.
-
I guess it would simplify things a lot regarding m68k emulation layer if one built AROS for a big-endian architecture. I had plans to get an ARM board capable of running Linux in big-endian mode, and then build AROS hosted on that, but I never got around to ordering any board. At the time I was looking at the nVidia Jetson TK1.
-
I guess it would simplify things a lot regarding m68k emulation layer if one built AROS for a big-endian architecture. I had plans to get an ARM board capable of running Linux in big-endian mode, and then build AROS hosted on that, but I never got around to ordering any board. At the time I was looking at the nVidia Jetson TK1.
PPC possibly?
But then you've kind of got MorphOS.
-
To mix 68k and x86 applications under the same aros instance would require something like the amithlon gcc compiler that generated x86 code that was big endian. I don't think anyone has ever looked at doing that, but for me this would be awesome.
This has been discussed in the history of AROS. Getting AROS compiled using the amithon gcc should be possible with some (dedicated) development work. This was not used for AROS as we want to have AROS run at maximum native speed when running on the native platforms and thus not use of unnatural endianess or structure packing.
-
This was not used for AROS as we want to have AROS run at maximum native speed when running on the native platforms and thus not use of unnatural endianess or structure packing.
I understand why the decision was made, I just think having the option would be more interesting.
In my opinion, an AROS that allows seemless mixing of 68k/ppc/x64 would outweigh the loss of speed on what are insanely fast cpu's. It may also persuade someone to do a x64 accelerator for the Amiga.
-
its simply a matter of interest and contribution. if there were people actually willing to make it happen, one could at least fork aros if not branch it out withing its own source tree. same for support for ppc platforms. whoever wants may step in and update these targets. this thread should be about currently available constructive options and how to help with these.
-
This thread is great. For someone that knows MorphOS and AmigaOS very well can anyone recommend a distro of AROS that will work (if one even exists) that installs on real Amiga hardware and will let me run Amiga apps? I have a spare A4000 and 1200 I would love to do some testing with once I get home late Friday! I also have a Vampire 500+
-
@Acill
there is olafs distribution (aros vision) but it is very huge (about 1 gb) and includes a lot of contributions, which makes it probably to heavy a starting point for amiga hardware. also it is not up to date, and latest changes have fixed a number of amiga hardware issues ans well as sped up aros on amigas. id advise to start with a4000, except you have 040 or 060 in your a1200.
download amiga-m68k-bootiso here:
http://aros.sourceforge.net/de/nightly1.php
decompress it to a bootable amiga partition.
then you have to do two changes:
edit your s-s adding this line at the beginning of it:
boot/amiga/AROSBootstrap ROM boot/amiga/aros.hunk.gz
it will softkick aros from your amiga rom. optionally you can add p96 driver files in the same line as arosbootstrap to activate your rtg card, like that for instance:
boot/amiga/AROSBootstrap ROM boot/amiga/aros.hunk.gz boot/amiga/PicassoIV.card boot/amiga/CirrusGD5446.chip
the other thing, not necessary but advisable is to delete prefs/env/sys/theme.var to get rid of decoration. it will be too heavy on aga for now due to alphablending and such. it can be turned on again later. ah and disable the window and desktop backgrounds in wanderer prefs, they take ages to load.
ill try to put up together a simple out of the box distribution next days if people are interested, i just dont have any server at hand.
-
its simply a matter of interest and contribution. if there were people actually willing to make it happen, one could at least fork aros if not branch it out withing its own source tree.
As you say there is no fatwah on somebody working on it. Not even need for fork or branch, just make it a separate cpu, e.g. i386be and x86_64be.
-
As you say there is no fatwah on somebody working on it. Not even need for fork or branch, just make it a separate cpu, e.g. i386be and x86_64be.
Sounds like a winner to me, Staf.
If I had the time, I'd try to resurrect the PPC port.
But neither AROS variant was originally focused on 68K applications.
Once up and running, the real work would have to commence.
-
If I had the time, I'd try to resurrect the PPC port.
yet you have time to engage in flamewars on forums. sam ppc target has built last time 26.02.15. it shouldnt be that hard to "resurrect", but if you ask me, i dont care.
But neither AROS variant was originally focused on 68K applications.
Once up and running, the real work would have to commence.
majority of amiga applications i tried work with aros anyway. so what is this comment supposed to mean?
-
there was a project that tried to implement something like Petunia on X86 Aros but failed. I cannot remember name but found it on web. I could try to find it if you are interested, cannot say much how far it got
I attempted to create a 68k emulator which could integrate into AROS (and allow 68k programs to run as first class citizens), but I ran into two problems.
Firstly, the (likely little endian) endianness of the host processor mean all multibyte memory access MUST be byte swapped, this means that host applications and 68k applications cannot share any data structures. Not a massive issue, but it did mean that all Host Operating system structures needed to have big endian equivalents in memory. I solved this by creating a set of classes which could be accessed like regular 68k exec style libraries for big endian data and via method calls for host endianness access. I planed from the beginning to deal with this.
The second problem which didn't occur to me until I had actual built the software was the address space issue. 68k applications only have 32bit pointers, so live within 4gig... But any modern host processor will be 64bit, this is a bigger problem, as now all 68k applications need to live in a single 4gig memory allocation and simply cannot access any host structures which my well be anywhere in a potential 16 exbibytes (https://en.wikipedia.org/wiki/Exbibyte) of memory!
These two things coupled with the fact that many (older) Amiga applications expect the Amiga Chipset to be present, mean that running AROS 68K on UAE in AROS is actually a more elegant solution.
You can find a link to the project here:
http://www.amiga.org/forums/showthread.php?t=72059
-
Firstly, the (likely little endian) endianness of the host processor mean all multibyte memory access MUST be byte swapped, this means that host applications and 68k applications cannot share any data structures.
This is why you would use something like the amithlon gcc compiler to make a big endian x86/x64.
I've never seen an emulator that uses byte swapping. For a 32 bit cpu then 32 bit data that is aligned would be written natively & bytes are written by xor'ing the address with 3. Aligned words are written by xor'ing the address with 2. Unaligned data is handled with shifting.
The second problem which didn't occur to me until I had actual built the software was the address space issue. 68k applications only have 32bit pointers, so live within 4gig... But any modern host processor will be 64bit
It wouldn't be the end of the world to limit an application to only working within the first 4gb of ram if it loads a 68k library.
These two things coupled with the fact that many (older) Amiga applications expect the Amiga Chipset to be present,
A lot don't. Some packers write to colour registers to show progress, some programs wait for mice button presses. They can be handled with something a lot more light weight than uae.
-
This is why you would use something like the amithlon gcc compiler to make a big endian x86/x64.
I've never seen an emulator that uses byte swapping. For a 32 bit cpu then 32 bit data that is aligned would be written natively & bytes are written by xor'ing the address with 3. Aligned words are written by xor'ing the address with 2. Unaligned data is handled with shifting.
The problem I have is that my software has no idea what the data size of 68k application's data structures actually are. I have found examples where data was written sequentially as bytes and then read back using long words. but as long as the 68k only sees big endian data and the host processor only sees native endian data everything works a treat. I planned to handle this from the start so this part works fine.
Remember a goal of my emulator was to allow the host processor and 68k emulated processor to exist in the same environment as the 68k emulators on AOS4 and MOS do.
It wouldn't be the end of the world to limit an application to only working within the first 4gb of ram if it loads a 68k library.
Again, you miss the problem. As soon as the host operating system can allocate memory above the 4gig limit of the 68k, then the 68k applications and the native applications are unable to share data structures (a fundamental requirement in AmigaOS).
Neither AOS4 or MOS run on 64bit CPUs so they don't have to worry about this issue... AROS run on modern x86 and ARM CPUs, both of which are 64bit, so I my emulator simply cannot assume it will be running on a system with 4gig or less of RAM.
A lot don't. Some packers write to colour registers to show progress, some programs wait for mice button presses. They can be handled with something a lot more light weight than uae.
If you read my original thread, you will see that I did reserve the custom chip address space for lightweight (i.e. not timing correct) hardware emulation, to increase compatibility.
The problem is that these three issues, make UAE a far more attractive option, especially since UAE now runs far faster on a modern 64bit CPU than any Amiga ever could.
On topic: The Vampire CPU is a super fun idea and it is very exciting to run AROS on it! By doing this one can optimise the OS for Vampire specific features.
-
you can still run 68k emu within 32bit aros target platform, like i386. at least the pointers are the same size for first, solution for 64bit can be then postponed.
but it turns again in highly theoretical utopic discussion. please stick to goals within reach for the time being. which is aros-m68k on vampire or stuff like that.
currently some support for the most active developer might be appropriate:
http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=10523&forum=4&post_id=104849#forumpost104849
he delivered essential sppedups last weeks which also essentially affects m68k platforms.
-
one can optimise the OS for Vampire specific features.
we can optimize os as a whole. since nick last commits after wider aros/vampire discussion aros is actually usable on my a4000/060 and bearable with 040.
-
The problem I have is that my software has no idea what the data size of 68k application's data structures actually are. I have found examples where data was written sequentially as bytes and then read back using long words.
You can't ever know, which is why you need to use the same endian all of the time. You can't change the endian of the 68k legacy code, so that leaves compiling your native code to use big endian. This was the path that amithlon went for when it added support for native code. It's the only workable solution.
we can optimize os as a whole. since nick last commits after wider aros/vampire discussion aros is actually usable on my a4000/060 and bearable with 040.
Hopefully more interest in AROS 68k will continue that to the point where it's usable on even an 020. I'm not sure that 68k compilers have had much love in a long time.
-
Hopefully more interest in AROS 68k will continue that to the point where it's usable on even an 020. I'm not sure that 68k compilers have had much love in a long time.
probably best amiga crosscompiler in a while and aros 68k backend candidate:
http://eab.abime.net/showthread.php?p=1163255&highlight=gcc6#post1163255
(available as source, so after its been tested changes can be merged into the 6.3.x diff, it can then even be built native for 68k, as aros compilers do)
-
There was also this attempt at a Trance style 68k emulator for x86 AROS but it was never finished.
https://github.com/moggen/emumiga/blob/master/README