English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 20 May 2018, 13:45   #481
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 3,024
Quote:
Originally Posted by meynaf View Post
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.

Quote:
Originally Posted by meynaf View Post
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.

Quote:
Originally Posted by meynaf View Post
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.

Quote:
Originally Posted by meynaf View Post
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.

Quote:
Originally Posted by meynaf View Post
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.

Quote:
Originally Posted by meynaf View Post
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.
Thorham is offline  
AdSense AdSense  
Old Yesterday, 09:25   #482
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 2,763
Quote:
Originally Posted by Thorham View Post
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...


Quote:
Originally Posted by Thorham View Post
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.


Quote:
Originally Posted by Thorham View Post
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.


Quote:
Originally Posted by Thorham View Post
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.


Quote:
Originally Posted by Thorham View Post
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.
meynaf is offline  
Old Yesterday, 11:37   #483
MigaTech
Only Amiga !!

MigaTech's Avatar
 
Join Date: Apr 2017
Location: United Kingdom
Posts: 492
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.
MigaTech is offline  
Old Yesterday, 11:59   #484
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 2,763
Quote:
Originally Posted by MigaTech View Post
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.
meynaf is offline  
Old Yesterday, 15:02   #485
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 3,024
Quote:
Originally Posted by meynaf View Post
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.

Quote:
Originally Posted by meynaf View Post
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?

Quote:
Originally Posted by meynaf View Post
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.

Quote:
Originally Posted by meynaf View Post
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.

Quote:
Originally Posted by meynaf View Post
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 is offline  
Old Yesterday, 15:03   #486
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 3,024
Quote:
Originally Posted by MigaTech View Post
Also if 32 BIT BCD and using wider tricks was faster
It probably isn't.
Thorham is offline  
Old Yesterday, 20:31   #487
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 2,763
Quote:
Originally Posted by Thorham View Post
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.


Quote:
Originally Posted by Thorham View Post
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.


Quote:
Originally Posted by Thorham View Post
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.


Quote:
Originally Posted by Thorham View Post
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


Quote:
Originally Posted by Thorham View Post
Couldn't you use a version from a 32bit Atari?
Perhaps. But that would only solve the problem of the OS itself.
meynaf is offline  
Old Yesterday, 21:07   #488
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 3,024
Quote:
Originally Posted by meynaf View Post
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.

Quote:
Originally Posted by meynaf View Post
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.

Quote:
Originally Posted by meynaf View Post
By minimum I meant OCS.
Lower than 640x200x2bpl isn't supported on OCS? Realaly?

Quote:
Originally Posted by meynaf View Post
You can't do an OS similar to AOS


Quote:
Originally Posted by meynaf View Post
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.
Thorham is offline  
Old Yesterday, 22:06   #489
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 2,763
Quote:
Originally Posted by Thorham View Post
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.


Quote:
Originally Posted by Thorham View Post
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.


Quote:
Originally Posted by Thorham View Post
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 ?
meynaf is offline  
Old Yesterday, 22:35   #490
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 3,024
Quote:
Originally Posted by meynaf View Post
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.

Quote:
Originally Posted by meynaf View Post
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.

Quote:
Originally Posted by meynaf View Post
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.
Thorham is offline  
Old Yesterday, 22:48   #491
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 401
@ Thorham, meynaf

You are just about to prove, that two people can hold a monolog.
Gorf is offline  
Old Yesterday, 22:54   #492
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 401
Quote:
Originally Posted by Thorham View Post
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 is offline  
Old Yesterday, 23:05   #493
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 401
Quote:
Originally Posted by MigaTech View Post
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"
Gorf is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 4 (1 members and 3 guests)
invent
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Has anyone got an Amiga 1200 T12 Gen II? ccorkin support.Hardware 10 14 April 2017 23:18
What do people think about this as next Gen AMIGA? Gunnar Amiga scene 111 05 July 2014 20:59
Classic 1st Gen EA games for the Amiga illy5603 support.Games 8 03 July 2010 02:59
Next-gen Amiga development LaundroMat Coders. General 3 05 October 2002 00:30

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


All times are GMT +2. The time now is 00:24.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.07937 seconds with 15 queries