| [News] AmigaOne no on-board sound? | ANN.lu |
| Posted on 06-Mar-2004 01:38 GMT by lawd | 135 comments
View flat
View list | |
Commenting a recent news item on amiga-news.de, Davy Wentzler of OS4 fame said the on-board sound of the AmigaOne does not work, furthermore explaining the chip is physically not present on AmigaOnes produced the last 9 months.
Frank Gutschow said on 05-Mär-2004, 23:38: "Meines erachtens sollte definitiv wirklich ersteinmal der Onboard-Chip des AmigaOne unterstützt werden."
Davy Wentzler answered on 05-Mär-2004, 23:45: "I'm gonna say it once more: it doesn't work. There's even a big chance, the chip is not physically present anymore on boards manufactured in the past 9 months."
Will Eyetech exchange all defect and component missing AmigaOnes or will they refund users that received broken hardware?
|
|
| List of all comments to this article |
| AmigaOne no on-board sound? : Comment 107 of 135 | ANN.lu |
| Posted by NorthWay on 06-Mar-2004 21:26 GMT | In reply to Comment 84 (Don Cox):
[Memory Protection]
>It was left out because the 68000 doesn't have a built in MMU, not to make life easier for games programmers.
>I am sure it would have been included if an MMU had been present.
I am not 100% sure of that.
The extra cost that would have been added if it was possible to select from both a 68K with and without MMU would have slimmed chances of it getting added.
The memory overhead of Resource Tracking was probably the biggest factor that made it not happen. You'd need something like "Owner", "List(next/prev)", and "Size" (hey, much like Mungwall - what a surprise). That is 16 bytes extra 'wasted' for every AllocMem() (or 12 for AllocVec()).
Remember that the OS was designed for a 128K machine (I think Mindwalker actually was designed to work with only 128K). Then Moore continued to be the law and 256K became the release size.
Now, if RT has a memory overhead, imagine what an protection with an MMU would need. Try to check the size of your average MMU table.
Oh, and how would you handle the different memory ownerships of the running processes? One table per task? Ouch! Multiply the number of tasks with the MMU table size. Still happy with 128K? 256K?
Separating memory spaces would have lots of consequences for the OS design too. Much of the OS calls actually run in the context of your own task and as such you would need to change to a user/supervisor model to enable the libraries to have private data that the tasks can't access.
How would you handle SetFunction()? Would you still change the jump target for all tasks?
There are many more such issues that more competent people than me have asked before.
But HEY! I really like one thing about AmigaOS and that is the single address space. There is some interesting research going on under the moniker SASOS for 64bit machines. A lot of Amiga thinking can make a comeback that way. |
|
| List of all comments to this article (continued) |
|
- User Menu
-
- About ANN archives
- The ANN archives is powered by #AmigaZeux. It was updated daily (news last: 22-Oct-2004; comments last: 18-May-2005).
ANN.lu was created, previously owned and maintained by Christian Kemp, www.ckemp.com.
- Contribute
- Not possible at this time!
- Search ANN archives
- Advanced search
- Hosting
- ANN.lu was hosted by Dreamhost. Sign up through this link, mention "ckemp" as referrer and he will get a 10% commission on any account you purchase.
Please show your appreciation for any past, present and future work on ANN.lu by making a contribution via PayPal.
|
