Next gen Amiga

[Thorham]

Originally Posted by meynaf

But this is only a rough estimate. Sometimes it will be more, and (much more annoying) sometimes it will be less.

My Lua calculator defaults to 30 digits out of ~100, so it's not a problem there.

Originally Posted by meynaf

The problem is, as you say everything is entered and printed in decimal. For this reason, to avoid errors everything should also be computed in decimal.

While that would be nice, the only decimal floating point package I could find that's easy to compile with SASC 6.58 is Mapm, and that's REALLY slow because it's base 100, byte based AND arbitrary precision. I'm using Cephes because it's C89 + pre C89, not because it's ideal.

Because of Cephes' high precision, which you never end up using any, none of this is really an issue. I'd be much more concerned about calculators that use doubles.

Originally Posted by meynaf

But AmigaOS does not know about these limitations. Neither do programs that run on it.

Yes, it does. AOS knows the limits of a screen mode through the monitor system and programs know because the OS knows.

Originally Posted by meynaf

Of course if you throw away everything that annoys you, it becomes easier

It would be interesting to see how far you'd have to go to get it running, though.

Originally Posted by meynaf

Out-of-the-box Atari ST does *not* have an MMU (Falcon and Atari TT should, but this isn't the subject).

Out of the box no, but it makes me wonder if those Amiga accelerators that slot into the 68000 socket could work somehow.

Originally Posted by meynaf

Besides, AOS is so tied to its hardware that you would have to rewrite significant parts of it.

Yeah, that might be a problem right there.

[meynaf]

Originally Posted by Thorham

My Lua calculator defaults to 30 digits out of ~100, so it's not a problem there.

I hope no time bomb will explode in your face. Seen just too many rounding problems with floats...

Originally Posted by Thorham

While that would be nice, the only decimal floating point package I could find that's easy to compile with SASC 6.58 is Mapm, and that's REALLY slow because it's base 100, byte based AND arbitrary precision. I'm using Cephes because it's C89 + pre C89, not because it's ideal.

Because of Cephes' high precision, which you never end up using any, none of this is really an issue. I'd be much more concerned about calculators that use doubles.

If you use existing packages and don't attempt to alter them to your needs, of course you have little choice.

Originally Posted by Thorham

Yes, it does. AOS knows the limits of a screen mode through the monitor system and programs know because the OS knows.

But there is default monitor and it handles more than that. I doubt AOS is able to cope with something that have specs below the minimum.

Originally Posted by Thorham

It would be interesting to see how far you'd have to go to get it running, though.

Too far for it to be of any use, i'm afraid.

Originally Posted by Thorham

Out of the box no, but it makes me wonder if those Amiga accelerators that slot into the 68000 socket could work somehow.

That may be possible, but then many original ST programs (including TOS 1.x) would cease to work.

[MigaTech]

The Coldfire in some ways was restricted over the original 68K. The 68K has a slightly different code format which they simplified on the Coldfire and this causes issues, when coding for compatibility. Also if 32 BIT BCD and using wider tricks was faster, then why did they omit using it in the x86 series and extend to 64BIT?

They state that the x87 FPU was utilised for byte decimal which converts it to floating point but the 68881/68882 did it all differently. What I mean is... that even the Coldfire changed from 80BITs to 64BITs why does it seem restricted? It seems to me that the original 68K and their FPU's were more advanced in some ways, specially when it came to BCD coding. Yet in later tech they removed so much, in favour of redundant instruction sets, meaning less addressing modes.

You talk of an OS with no flaws or limits but doesn't the hardware have to be the same, otherwise you are having to code round the issues.

[meynaf]

Originally Posted by MigaTech

You talk of an OS with no flaws or limits but doesn't the hardware have to be the same, otherwise you are having to code round the issues.

This is what i have always thought.
The complexity one removes somewhere, is just moved elsewhere. And moving it from the cpu to the software is really a bad move (at least today where transistor count does not matter much anymore) because there is a lot more software than there are cpu implementations.

[Thorham]

Originally Posted by meynaf

I hope no time bomb will explode in your face. Seen just too many rounding problems with floats...

Probably because they're used for the wrong thing or in the wrong way. For a calculator with 384bit floats it really doesn't matter much at all.

Also, some examples would be fun.

Originally Posted by meynaf

If you use existing packages and don't attempt to alter them to your needs, of course you have little choice.

Yes, but why would I do that if I already have something that does what I want out of the box?

Originally Posted by meynaf

But there is default monitor and it handles more than that. I doubt AOS is able to cope with something that have specs below the minimum.

But 640x200x2bit isn't under the minimum. The minimum is lowres, and with double scan, 160xSomething, although the screen size will be larger.

Originally Posted by meynaf

Too far for it to be of any use, i'm afraid.

Okay, that might indeed be the case. But don't tell me you can't do an OS similar to AOS.

Originally Posted by meynaf

That may be possible, but then many original ST programs (including TOS 1.x) would cease to work.

Couldn't you use a version from a 32bit Atari?

[Thorham]

Originally Posted by MigaTech

Also if 32 BIT BCD and using wider tricks was faster

It probably isn't.

[meynaf]

Originally Posted by Thorham

Probably because they're used for the wrong thing or in the wrong way. For a calculator with 384bit floats it really doesn't matter much at all.

Also, some examples would be fun.

If your calculator is mature enough for some heavy testing, i might eventually try to catch it.

Originally Posted by Thorham

Yes, but why would I do that if I already have something that does what I want out of the box?

Because, as you wrote it yourself above, it's not ideal.

Originally Posted by Thorham

But 640x200x2bit isn't under the minimum. The minimum is lowres, and with double scan, 160xSomething, although the screen size will be larger.

By minimum I meant OCS.

Originally Posted by Thorham

Okay, that might indeed be the case. But don't tell me you can't do an OS similar to AOS.

You can't do an OS similar to AOS

Originally Posted by Thorham

Couldn't you use a version from a 32bit Atari?

Perhaps. But that would only solve the problem of the OS itself.

[Thorham]

Originally Posted by meynaf

If your calculator is mature enough for some heavy testing, i might eventually try to catch it.

The Cephes library should be more than mature enough. Been around since the early '80s or something. The calculator should also be fine. Would be interesting to see what you can find.

Originally Posted by meynaf

Because, as you wrote it yourself above, it's not ideal.

The problem is that nothing is C89 anymore. Plenty of libraries around, just try to compile them with SASC. Perhaps a custom library in 68k assembler wouldn't be a bad idea.

Originally Posted by meynaf

By minimum I meant OCS.

Lower than 640x200x2bpl isn't supported on OCS? Realaly?

Originally Posted by meynaf

You can't do an OS similar to AOS

Originally Posted by meynaf

Perhaps. But that would only solve the problem of the OS itself.

Yeah, perhaps AOS isn't a good candidate if you want to keep it fast.

[meynaf]

Originally Posted by Thorham

The Cephes library should be more than mature enough. Been around since the early '80s or something. The calculator should also be fine. Would be interesting to see what you can find.

Then i just need something i can run directly and test.

Originally Posted by Thorham

The problem is that nothing is C89 anymore. Plenty of libraries around, just try to compile them with SASC. Perhaps a custom library in 68k assembler wouldn't be a bad idea.

To compile C99 you can try vbcc. Not more difficult to use than sasc.
A custom library in 68k asm is also a good idea.

Originally Posted by Thorham

Lower than 640x200x2bpl isn't supported on OCS? Realaly?

It's not that !
Minimum is OCS.
And OCS is 320x256x5 and 640x256x4.
If the hardware does not support these, it's under the minimum.
M'kay ?

[Thorham]

Originally Posted by meynaf

Then i just need something i can run directly and test.

If you mean Lua code, then all I have is in the archive. If it's C, then you need the Cephes library object file and link it to your own test program because I have nothing that runs directly.

Originally Posted by meynaf

To compile C99 you can try vbcc. Not more difficult to use than sasc. A custom library in 68k asm is also a good idea.

A custom library seems more interesting and not necessarily hard.

Originally Posted by meynaf

It's not that !
Minimum is OCS.
And OCS is 320x256x5 and 640x256x4.
If the hardware does not support these, it's under the minimum.
M'kay ?

Right, that's what you mean If this is a stone cold requirement of the default monitor, then it's indeed not going to work.

[Gorf]

@ Thorham, meynaf

You are just about to prove, that two people can hold a monolog.

[Gorf]

Originally Posted by Thorham

I have no effing clue at all Basing it on a peecee CPU and a peecee GFX card makes it a peecee. Using an FPGA will make it less powerful. You tell me.

Making a good use of both: modern CPUs and FPGAs, until some better solution comes along.

Seems the guys over at FPGAarcade had more or less the same idea:
http://www.fpgaarcade.com/punbb/viewtopic.php?id=1310

rebuild the chipset in the FPGA and make use of a fast CPU via JIT.

[Gorf]

Originally Posted by MigaTech

What about an Amiga with all 3 official Chipsets and the unofficial 4th Gen AAA.

Yes I thing all old Chipsets even with some AAA or Hombre improvements would easily fit on a FPGA.

The two biggest problems are

- the CPU instruction sets and endianness. (but can probably be "solved" with FPGA supported JITs..)

- the unsolved ownership of everything "Amiga" :-(

So lets call it "Agima"

[meynaf]

Originally Posted by Gorf

@ Thorham, meynaf

You are just about to prove, that two people can hold a monolog.

Perhaps, but we also prove we can both discuss without turning it into a flame war.

Originally Posted by Gorf

Making a good use of both: modern CPUs and FPGAs, until some better solution comes along.

Seems the guys over at FPGAarcade had more or less the same idea:
http://www.fpgaarcade.com/punbb/viewtopic.php?id=1310

rebuild the chipset in the FPGA and make use of a fast CPU via JIT.

I have doubts about this solution.
People who don't like emulation won't like it - because it is emulation.
And people who like emulation already have a better solution.

[meynaf]

Originally Posted by Thorham

If you mean Lua code, then all I have is in the archive. If it's C, then you need the Cephes library object file and link it to your own test program because I have nothing that runs directly.

I think i'll pass until you have something that runs directly...

Originally Posted by Thorham

A custom library seems more interesting and not necessarily hard.

Indeed.

Originally Posted by Thorham

Right, that's what you mean If this is a stone cold requirement of the default monitor, then it's indeed not going to work.

I can't be 100% sure of this, but as i told, AOS is quite tied to its hardware. It was certainly not designed with multi-platform in mind.

And of course we could write an OS that is similar
But... who would attempt such a daunting task, for so little result ?

[Gorf]

Originally Posted by meynaf

Perhaps, but we also prove we can both discuss without turning it into a flame war.

For the price of never staying at the same subject....

I have doubts about this solution.
People who don't like emulation won't like it - because it is emulation.
And people who like emulation already have a better solution.

Ok - that would lead to the tiresome discussion of what is emulation and what not.
But granted: it needs to provide a somehow "better" solution.
So it should at least feel as native as possible and not like an emulation - e.g. booting directly into AOS, no visible sign of any other OS, a dedicated machine for the Amiga-experience
It should be compatible but fast and at least rival WinUAE speedwise.
And maybe feel less "JIT-like" (which is fast but with latency)

Since we do not have a new fast 68k-ASIC and of course no new Amiga-like chipset, a compilation of the best (affordable) technologies that are around should be taken into consideration, don’t you think?

[Gorf]

Originally Posted by meynaf

I can't be 100% sure of this, but as i told, AOS is quite tied to its hardware. It was certainly not designed with multi-platform in mind.

3.x runs with not so huge modifications on Draco, Casablanca and Amithlon.
The AOS API has now been recreated at least 3 times with 4.x, MOS and AROS.

[meynaf]

Originally Posted by Gorf

For the price of never staying at the same subject....

That's still better.

Originally Posted by Gorf

Ok - that would lead to the tiresome discussion of what is emulation and what not.

Not something i want to go into, indeed.

Originally Posted by Gorf

But granted: it needs to provide a somehow "better" solution.
So it should at least feel as native as possible and not like an emulation - e.g. booting directly into AOS, no visible sign of any other OS, a dedicated machine for the Amiga-experience

Yes but you know people : they will still grumble this is emulation.

Originally Posted by Gorf

It should be compatible but fast and at least rival WinUAE speedwise.

Be awared that ARM cpu is too slow to match WinUae speedwise (at least when run on a decent machine).
So you need something more clever than just having the onboard cpu execute the code.
And it would be safer to target somewhere between vampire and winuae-jit on core i7.

Originally Posted by Gorf

And maybe feel less "JIT-like" (which is fast but with latency)

That will be difficult.
JIT have latencies more or less by design.
And no JIT means too slow.
Or maybe you have a nice idea to overcome these ?

Originally Posted by Gorf

Since we do not have a new fast 68k-ASIC and of course no new Amiga-like chipset, a compilation of the best (affordable) technologies that are around should be taken into consideration, don’t you think?

Yes but what advantages would we have vs other solutions ?
I think we should aim for something that adds interest to the platform.
Something that would make the platform more enjoyable to code on, so that old coders / demomakers will come back.

Originally Posted by Gorf

3.x runs with not so huge modifications on Draco, Casablanca and Amithlon.

I.e. on machines that do some kind of emulation.

Originally Posted by Gorf

The AOS API has now been recreated at least 3 times with 4.x, MOS and AROS.

And still, many Amiga programs won't work without, again, some kind of emulation. Where's the point here ?
The OS itself is not enough to make an Amiga.

Besides, the APIs are actually the weak point for a coder like me. They're not so practical to code for.
And the 68k, while great, has some design issues.
Same story with the hardware.

So perhaps the best way would be to build a new platform more or less from scratch, respecting the spirit that made the Amiga a great machine, and use emulation for compatibility.
What do you think about it ?

[Gorf]

Originally Posted by meynaf

Yes but you know people : they will still grumble this is emulation.

most modern CPUs are just emulating the legacy ISA ... the line between hard- and software is somewhat blurred today.

Be awared that ARM cpu is too slow to match WinUae speedwise (at least when run on a decent machine).

true, but there is of course always the speed/price ratio - how much bang for the dollar.
(and there its always the multiple-instances/sandbox/cluster approach that could make use of more cores and level the field a little bit)

So you need something more clever than just having the onboard cpu execute the code.

thats what I am trying to figure out. I am still collecting Ideas and evaluating approaches.

That will be difficult.
JIT have latencies more or less by design.
And no JIT means too slow.
Or maybe you have a nice idea to overcome these ?

Some I mentioned already earlier in this thread.
To speed up the first-round(s) of code-execution and reduce the lag, it is probably a good idea to "outsource" some of the work onto dedicated hardware (FPGA). First step would be a fast 68k-instruktion decoder/translater. Thereby one would need to use all sorts of tricks like instruction bonding or recognition of some very often used tuples of instruction and their shortest representation in the target-ISA.

We would need to evaluate where to place the memory controller: using the (mostly faster) host CPU for that or is some extra channel for the FPGA-part better?
The second approach would allow to take care of the endianness swapping in the FPGA before handing data over for calculation to the host cpu.
It could also take care of some memory operations, that would just be very slow on a risc CPU, directly ...
(and we could implement your idea of a dedicated MMU and/or protection unit)

Hotspots in the code would than be translated and optimized by the software-JIT .. preferably in parallel by a second core.

Very hot hotspots could than again be compiled into VHDL for live updating the FPGA - could be working for things like a ray-tracer or fractal generator.

But more clever ideas are welcome!

Yes but what advantages would we have vs other solutions ?

best price/speed ratio.

I think we should aim for something that adds interest to the platform.
Something that would make the platform more enjoyable to code on, so that old coders / demomakers will come back.

I am listening.

So perhaps the best way would be to build a new platform more or less from scratch, respecting the spirit that made the Amiga a great machine, and use emulation for compatibility.
What do you think about it ?

Well - such a platform would probably start as some kind of emulation or FPGA implementation, wouldn't it?

but yes: I like the idea, but this opens of course a myriad of possibilities how to do things

OK - lets just concentrate on one element for now:
What should the cpu look like?

[Dunny]

Originally Posted by Gorf

OK - lets just concentrate on one element for now:
What should the cpu look like?

I think it will be square, flat, with pins on the underside.