osprey atari coldfire + arm still in development

Latest news in the Atari world

Moderators: Mug UK, Silver Surfer, Moderator Team

User avatar
aRt
Atariator
Atariator
Posts: 21
Joined: Wed May 07, 2008 9:57 pm

osprey atari coldfire + arm still in development

Postby aRt » Wed May 07, 2008 10:12 pm

Dear readers,

The osprey project is still ongoing, it has been standing still for a while due to various reasons i.e. I was also in brasil recently, where Im going back in about 6-8 months.

2 boards are allready produced, the coldfire cpus will be fitted on soon.

More information regarding the osprey atari - check the link below. Page undergoing development, design is subject to better - dont have time to focus on this right now.

have flash enabled boys & gals
- edit - prohosts was too slow - new link
http://artari.co.cc/

aRt. O_o OSprey :)
Last edited by aRt on Sun Jun 01, 2008 4:16 pm, edited 1 time in total.
The Penguin got a TiNT trippin over a bucket while eating MiNT chocolate...

jd
Captain Atari
Captain Atari
Posts: 355
Joined: Thu Nov 09, 2006 12:38 pm
Location: Ruislip, UK

Re: osprey atari coldfire + arm still in development

Postby jd » Thu May 08, 2008 1:43 pm

Looks good.

ppera

Re: osprey atari coldfire + arm still in development

Postby ppera » Thu May 08, 2008 5:55 pm

What browser should I use to see there something relevant ?
I can see only some red bgr. and "Congrat, you won , number huhohohoooo"...
No other working link. Firefox, IE used.

User avatar
rian_ata
Captain Atari
Captain Atari
Posts: 269
Joined: Mon Apr 24, 2006 10:00 pm
Location: Netherlands
Contact:

Re: osprey atari coldfire + arm still in development

Postby rian_ata » Thu May 08, 2008 6:28 pm

With Opera it works. You need to click the 'futuristic looking Atari fuji sign' for example and have Flash installed.

User avatar
bullis1
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2301
Joined: Tue Dec 12, 2006 2:32 pm
Location: Canada
Contact:

Re: osprey atari coldfire + arm still in development

Postby bullis1 » Thu May 08, 2008 6:35 pm

The site works in firefox, but there's nothing to see on it. I assume more information will be uploaded further into the future.
Member of the Atari Legend team

User avatar
karlm
Atari Super Hero
Atari Super Hero
Posts: 713
Joined: Thu Nov 13, 2003 4:09 am
Location: Top of the World - Australia

Re: osprey atari coldfire + arm still in development

Postby karlm » Thu May 08, 2008 11:11 pm

works for me with Firefox 2.0.0.14. Must have flash as aRt said. Also, click on the futuristic fuji logo, the menu title history and the menu title forum. Nothing much to look at the moment but it is there...

karlm

User avatar
aRt
Atariator
Atariator
Posts: 21
Joined: Wed May 07, 2008 9:57 pm

TiNT kernel - web browsing

Postby aRt » Thu May 15, 2008 1:54 am

I was just in contact with cambridge - today or friday the first dev boards are to be dispatched to my location.

The kernel - TiNT - This is Not Tos - will be based upon a mix between the arm debian kernel and MiNT kernel,
as debian is ready to go for this architecture - and even browses the web - looks beautiful...

here is a picture of a prototype running debian - this is a pxa version - though this also runs on arm... note this board is fitted in a case therefore this looks boxy
You do not have the required permissions to view the files attached to this post.
The Penguin got a TiNT trippin over a bucket while eating MiNT chocolate...

User avatar
darklight
Captain Atari
Captain Atari
Posts: 277
Joined: Mon May 08, 2006 7:53 pm
Location: Brisbane
Contact:

Re: osprey atari coldfire + arm still in development

Postby darklight » Thu May 15, 2008 2:23 am

The links are quite fiddly - make sure the mouse has changed into a link cursor when you hold it over the link, before you click it.
Storm Clouds over the Western Front - my WW1 2D dogfighting game for windows
2D Flight Sims - side scrolling aerial combat games

User avatar
samf
Captain Atari
Captain Atari
Posts: 185
Joined: Wed Mar 10, 2004 9:22 pm
Location: Ashburn, Virginia USA
Contact:

Re: osprey atari coldfire + arm still in development

Postby samf » Thu May 15, 2008 3:20 am

aRt wrote:Dear readers,

The osprey project is still ongoing, it has been standing still for a while due to various reasons i.e. I was also in brasil recently, where Im going back in about 6-8 months.

2 boards are allready produced, the coldfire cpus will be fitted on soon.

More information regarding the osprey atari - check the link below. Page undergoing development, design is subject to better - dont have time to focus on this right now.

have flash enabled boys & gals

http://osprey.prohosts.org

aRt. O_o OSprey :)


So this will be an Atari Clone? Will this run all the gem software? What will the cpu speed be? Looks interesting.
Atari Computer Nut
Virginia U.S.A.
C-Lab/CT060 Falcon,
256mb TT Ram, 14mb ST Ram,
4Gig hdd, IDE DVD Drive

User avatar
aRt
Atariator
Atariator
Posts: 21
Joined: Wed May 07, 2008 9:57 pm

Re: osprey atari coldfire + arm still in development

Postby aRt » Thu May 15, 2008 6:20 am

The speed of the arm will be aprox 206Mhz or so - a coldfire will be added and attempted to run at more or less the same speed just above 200Mhz - using its own sdram - running independently of the arm.

ym2149 chipset is intended to be added - here I would like suggestions of other soundchips that may be functionally compatible - capable of sounding like atari stfm chipsound - or maybe an alternative one that just exceeds.

The system will be capable of running what the atari coldfire project could run - just that this babys motherboard fits within the hand and can be reduced to 5mm height by changing connectors to lowprofile ones, currently the dev boards have high profile connectors.

This should yield 235 mips for the arm 225 mips aprox for the coldfire roughly calculated. this should yield 460 mips in total performance if one uses clever programming or 235 and 225 respectively with each their tasks forexample.

a modified version of debian using the TiNT kernel will be attempted put on flash - but without Xserver for starters to make that possible with the ammount of available flash ram - Instead there will be a GEM vdi aes capability from TiNG GLADIS TiNA respectively.

A new .rsc format will also be added for simplicity of application writing, and a GUI engine for skinning terminal / tos apps.

Hopefully there will be some more info in the next week and pics.

regards,

aRt.
The Penguin got a TiNT trippin over a bucket while eating MiNT chocolate...

User avatar
shoggoth
Nature
Nature
Posts: 980
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: osprey atari coldfire + arm still in development

Postby shoggoth » Thu May 15, 2008 9:19 am

I think I've made this comment before, but here I go again.

Sure, OS diversity can be healthy, but I get the impression that we - once again - are about to invent new standards, causing incompatibilities to existing solutions, and in the end causing yet another divide for the platform. A lot of work has been put into the existing mintkernel, which can - with a little work - run perfectly on the ColdFire. Didier has made a tremendous effort in getting TOS up and running on ColdFire development boards, and afaik Olivier Landemarres MyAES runs natively on the ColdFire.

New APIs. A new RSC-fileformat. New GUI toolkits. Sure, I get the idea, but I think that energy should be put into our current *opensource* platform so that the whole community will benefit from it. We've already experienced the hassle associated with MagiC vs. FreeMiNT. Why again?

Sorry if this sounds like bashing. Honestly, that's not my intention. It sure looks like a cool project. I'm just thinking about the bigger picture here.
Ain't no space like PeP-space.

User avatar
aRt
Atariator
Atariator
Posts: 21
Joined: Wed May 07, 2008 9:57 pm

Re: osprey atari coldfire + arm still in development

Postby aRt » Thu May 15, 2008 11:36 am

well sure - MiNT is ok- but is has never quite been easy to compile for.

TiNT is a tint between linux kernel and MiNT - meaning compatible for 2 reasons - the possibilities of running good drivers allready existing - so the benefit of MiNT and linux is there - MiNT has never quite been a system good enough for my use - why port everything? I say modding debian adding MiNT capabilities to the kernel is a way to go.

well sure its possibl to run tos - though tos is not really necessary at all if you ask me - as the tos calls i.e. 99 percent of them - well all the ones we could use that are documented - are not really necessary if one uses MiNT - single tos user system ? it is rather out of date isnt it?

When it comes to MyAES - well - this I believe doesnt necessarily cut it totally for speedy truecolour graphics handling - and there is no extended support for modern graphical needs - so standard aes plus additional features is necessary.

there should be no hassle concerning TiNT vs MiNT - it really should be compatible... MiNT just doesnt cut it - when there are a lot of drivers for the ARM side - allready made - also - MiNT is nowhere near the debian kernel as of now - and compatability with all the calls capable within MiNT should really solve that imo.

well - check out that rsc format - yes I believe that is a thing of the early 90s.... so here - a possibility of some new features would be good - assembly coders have often struggled programming apps that use rsc files - it sometimes becomes totally retarded, but still this is just an extra capability.

the main reason for this being better is - MiNT doesnt quite cut it when it comes to availability of ported software - so - lets have debian kernel with MiNT compatability...

hope this answers some of your questions sir :)
The Penguin got a TiNT trippin over a bucket while eating MiNT chocolate...

User avatar
shoggoth
Nature
Nature
Posts: 980
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: osprey atari coldfire + arm still in development

Postby shoggoth » Thu May 15, 2008 12:14 pm

aRt wrote:well sure - MiNT is ok- but is has never quite been easy to compile for.


In my experience, quite the contrary. Can you elaborate this claim further?

TiNT is a tint between linux kernel and MiNT - meaning compatible for 2 reasons - the possibilities of running good drivers allready existing - so the benefit of MiNT and linux is there - MiNT has never quite been a system good enough for my use - why port everything? I say modding debian adding MiNT capabilities to the kernel is a way to go.


I do get the point, but can you elaborate and examplify this further?

well sure its possibl to run tos - though tos is not really necessary at all if you ask me - as the tos calls i.e. 99 percent of them - well all the ones we could use that are documented - are not really necessary if one uses MiNT - single tos user system ? it is rather out of date isnt it?


Not entirely true. It depends on what level of compatibility you're after. The freemint kernel replaces calls where appropriate, but tunnels unknown calls to the original TOS (afaik). I agree that compatibility with prehistoric TOS-only stuff serves no purpose.

When it comes to MyAES - well - this I believe doesnt necessarily cut it totally for speedy truecolour graphics handling - and there is no extended support for modern graphical needs - so standard aes plus additional features is necessary.


Again, can you elaborate this further? In what way does the AES lack the necessary functionality to handle truecolour graphics? And what is your view on the current version of XaAES?

And I get the feeling we're talking apples and oranges here. Are you talking about the VDI or the AES?

there should be no hassle concerning TiNT vs MiNT - it really should be compatible... MiNT just doesnt cut it - when there are a lot of drivers for the ARM side - allready made - also - MiNT is nowhere near the debian kernel as of now - and compatability with all the calls capable within MiNT should really solve that imo.


Well, see, the problem is that the concept of "should be compatible" has imposed problems on the platform historically. Specifications are interpreted differently, and minor deviations in APIs here and there means coders has to 1. check which OS they're running on an 2. use different sets of routines to handle stuff. I agree that "should be compatible" work for minor projects, but you're talking about a replacement for all OS functions, which is significantly larger.

well - check out that rsc format - yes I believe that is a thing of the early 90s.... so here - a possibility of some new features would be good - assembly coders have often struggled programming apps that use rsc files - it sometimes becomes totally retarded, but still this is just an extra capability.


Yes, but then again, we'll end up with yet another format, which means programs written for TiNT will not be compatible with MiNT. I'm not only thinking of backwards compatibility (well, sideways if you ask me), but also the other way around. And we're talking ColdFire performance (well, or ARM), which means we can afford to use high level languages for all but time critical stuff (i.e. a mixture of C and assembler, quite common today I believe). In this context, does the current RSC-format constitute a major obstacle for coders today?

the main reason for this being better is - MiNT doesnt quite cut it when it comes to availability of ported software - so - lets have debian kernel with MiNT compatability...


Can you elaborate that further? Also, what kind of setup have you used - system specifications, VDI, AES-version, kernel version, OS distribution etc?

hope this answers some of your questions sir :)

[/quote]

Well, not really, and again I don't mean to bash your ideas. I feel that what you're about to do constitutes major development work for quite some time, and I question how the platform would benefit from this approach compared to investing the same amount of time improving the current FreeMiNT/XaAES.
Ain't no space like PeP-space.

User avatar
GokMasE
Captain Atari
Captain Atari
Posts: 221
Joined: Sun Mar 02, 2003 11:16 pm
Location: Sweden
Contact:

Re: osprey atari coldfire + arm still in development

Postby GokMasE » Thu May 15, 2008 12:30 pm

shoggoth wrote:Well, not really, and again I don't mean to bash your ideas. I feel that what you're about to do constitutes major development work for quite some time, and I question how the platform would benefit from this approach compared to investing the same amount of time improving the current FreeMiNT/XaAES.


My thoughts exactly. I don't think that yet another platform within the platform is the best way to evolve.

Regards,

/Joakim

User avatar
christos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2456
Joined: Tue Apr 13, 2004 8:24 pm
Location: Greece
Contact:

Re: osprey atari coldfire + arm still in development

Postby christos » Thu May 15, 2008 12:35 pm

I must agree with the above. Magic vs FreeMiNT was very bad, but they both had TOS as a common denominator. TiNT as you propose it seems to me like a kind of WINE for the MiNT API. While this is not a bad idea, it seems to me like an idea closer to ARANYM than to an Atari clone. I however am most interested in hearing more about how you think about it. I am also most certainly not bashing your idea.

User avatar
aRt
Atariator
Atariator
Posts: 21
Joined: Wed May 07, 2008 9:57 pm

Re: osprey atari coldfire + arm still in development

Postby aRt » Thu May 15, 2008 7:34 pm

shoggoth wrote:
aRt wrote:well sure - MiNT is ok- but is has never quite been easy to compile for.


- In my experience, quite the contrary. Can you elaborate this claim further?

MiNT is not totally bsd - or totally like freebsd - here one needs to adapt code, and settings - there may be lack of libraries - there is no use in discussing this really, we should both listen to someone who has done a lot of porting of apps - or works with hardware. I do believe a debian-like kernel is better suited for supporting peripherals than MiNT - and ofcourse there are lots of drivers allready available with no porting - adaption necessary or atleast a lot less. MiNT is cool - I used to love it - but still - why be more distant from lots of support than necessary?

TiNT is a tint between linux kernel and MiNT - meaning compatible for 2 reasons - the possibilities of running good drivers allready existing - so the benefit of MiNT and linux is there - MiNT has never quite been a system good enough for my use - why port everything? I say modding debian adding MiNT capabilities to the kernel is a way to go.


- I do get the point, but can you elaborate and examplify this further?

Well - debian runs debian binaries - MiNT runs tos binaries / applets specifically for MiNT - let us say forexample - in MiNT there has been a lot of work only to improve the filesystem support, availability of simple software - most bsd - linux - freebsd geeks love to be able to have less hassle obtaining software, drivers - iousbstorage drivers, be that drivers for certain peripherals - web cams etc. Here one can wait for a year or two before there is a good software, applet or driver for MiNT - whilst debian would give one access immediately -
well sure its possibl to run tos - though tos is not really necessary at all if you ask me - as the tos calls i.e. 99 percent of them - well all the ones we could use that are documented - are not really necessary if one uses MiNT - single tos user system ? it is rather out of date isnt it?


-Not entirely true. It depends on what level of compatibility you're after. The freemint kernel replaces calls where appropriate, but tunnels unknown calls to the original TOS (afaik). I agree that compatibility with prehistoric TOS-only stuff serves no purpose.

Now, I cant remember the last time I used a TOS application with such calls - though - sure I will take into account implementing this coldfire TOS version. you have a point - it could be nice and very little adaption would be necessary imho - some registers/hardware addresses to change/patch a few instructions here and there.

When it comes to MyAES - well - this I believe doesnt necessarily cut it totally for speedy truecolour graphics handling - and there is no extended support for modern graphical needs - so standard aes plus additional features is necessary.


-Again, can you elaborate this further? In what way does the AES lack the necessary functionality to handle truecolour graphics? And what is your view on the current version of XaAES?

-And I get the feeling we're talking apples and oranges here. Are you talking about the VDI or the AES?

Application Environment Services - well yes we are talking apples and oranges here because I love apples and oranges, but mostly due to a typo from me sorry for that ;) Still I do not really want to use this XaAES even though there is a nice development strategy for future support concerning visual effects. Here there should be an AES capable of such as forexample mac os x - and a more advanced GUI not relating totally on bitmap - bitmap is in the past apart from necessary cases imo. I cant really say I fancy the squarishness and simplicity of AES or XaAES - Ive never seen any innovative button possibilities - or customshaped applets that are handled well. Id also like to free the coldfire from handling disk-, AES-, VDI-, etc related tasks as the LCD is accessible from a strongARM chip. And if this needs porting to work on a strongARM chipset - then Im not very interested, Im not saying it is an unnecessary piece of software for others - I just want to rely on something else - atleast, as a final product.

there should be no hassle concerning TiNT vs MiNT - it really should be compatible... MiNT just doesnt cut it - when there are a lot of drivers for the ARM side - allready made - also - MiNT is nowhere near the debian kernel as of now - and compatability with all the calls capable within MiNT should really solve that imo.


-Well, see, the problem is that the concept of "should be compatible" has imposed problems on the platform historically. Specifications are interpreted differently, and minor deviations in APIs here and there means coders has to 1. check which OS they're running on an 2. use different sets of routines to handle stuff. I agree that "should be compatible" work for minor projects, but you're talking about a replacement for all OS functions, which is significantly larger.

I agree, this has been somewhat troublesome - though this could depend on binary-type stated within the apps being run themselves - and there are MiNT sources available to more or less copy the necessary - its just why be stuck in the past while debian rolls on into the future?

well - check out that rsc format - yes I believe that is a thing of the early 90s.... so here - a possibility of some new features would be good - assembly coders have often struggled programming apps that use rsc files - it sometimes becomes totally retarded, but still this is just an extra capability.


-Yes, but then again, we'll end up with yet another format, which means programs written for TiNT will not be compatible with MiNT. I'm not only thinking of backwards compatibility (well, sideways if you ask me), but also the other way around. And we're talking ColdFire performance (well, or ARM), which means we can afford to use high level languages for all but time critical stuff (i.e. a mixture of C and assembler, quite common today I believe). In this context, does the current RSC-format constitute a major obstacle for coders today?

hmm... true interesting point, I must admit I am very cought up in what is possible rather than copying an applet from this system to MiNT users running other aes/vdi servers etc. I do have sources for a commercial rsc editor from atari that could be bettered I believe, but here I would really want xml instead, being read in - compiled if file has changed and cached on disk. or then again I could say- anyone up for squareish buttons - windows, and 16/256 colours? I must admit I havent seen a rsc editor since the one that came with my devkit for falcon - but I am rather not into the conservative :D

the main reason for this being better is - MiNT doesnt quite cut it when it comes to availability of ported software - so - lets have debian kernel with MiNT compatability...


Can you elaborate that further? Also, what kind of setup have you used - system specifications, VDI, AES-version, kernel version, OS distribution etc?
falcon 030 standard - anyways - check out the software list - it is not that long... cant be compared to what exists for debian.

hope this answers some of your questions sir :)



Well, not really, and again I don't mean to bash your ideas. I feel that what you're about to do constitutes major development work for quite some time, and I question how the platform would benefit from this approach compared to investing the same amount of time improving the current FreeMiNT/XaAES.[/quote]

Well FreeMiNT and XaAES are great products on their respected hardware and probably the only choice - still I feel Id do no good porting this to ARM which frees the coldfire chip from OS / gfx strain. Then again it might be interesting to test FreeMiNT on the coldfire part - though I really would appreciate modding a debian kernel - with MiNT capabilities instead for 2 binary types, as these two cpus need to interact even on kernel level. I totally agree that you have good strong points - it is just that software availability and support for new hardware grows faster within the debian community.

I appreciate your ideas and opinions on this - I will for sure check up on the TOS for the coldfire part. And please kick my butt if I need to realize a good point as with the TOS, for this does no harm :) I actually appreciate it.

regards

aRt
The Penguin got a TiNT trippin over a bucket while eating MiNT chocolate...

User avatar
shoggoth
Nature
Nature
Posts: 980
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: osprey atari coldfire + arm still in development

Postby shoggoth » Thu May 15, 2008 9:21 pm

To make sure I understand you correctly, I've tried to sum up my interpretation of your posts below:

1. Applications will run on the ColdFire, while the ARM runs the OS.

2. You're not interested in porting FreeMiNT or XaAES to this system, but you're prepared to write most of it from scratch. You'll keep Linux binary compatibility, including support for Linux device drivers. On top of that you'll add a freemint-compatible GEMDOS/XBIOS/BIOS/AES/VDI trap interface.

3. Your new GUI sports tons of nifty features based on new technologies. Applications can take advantage of such features by using new function calls. This GUI will run on top of X to keep X compatibility.


My conclusions:

Just for the record - Debian is a distribution, not a kernel nor a binary format.

Why would I write an application that takes advantage of the features offered by this system? If I do, I'll break compatibility with current kernels/AES:s (FreeMiNT/XaAES/MyAES). Since I break compatibility, it makes much more sense for me to write a Linux/X application. On top of that, it would be much easier, since I could use commonly available GUI toolkits such as GTK.

Running the OS on the ARM and run the applications on the ColdFire sounds like quite a complex solution to me. Why not just use the ARM as a coprocessor, e.g. as a graphics accellerator for the VDI? You could even port well known libraries such as LibJPEG/PNG etc. and make a wrapper lib for the ColdFire side to handle it.

Linux is not BSD is not HP/UX is not Solaris is not FreeMiNT. This is normal within the Unix world. It's nothing weird about that, and actually freemint is Posix enough to work really well in that context. Porting command line stuff is often only a matter of running the configure script and typing "make" in Bash. Some ports are more extensive, but not more than you'd expect if porting to any other GUI. I don't consider myself an expert on this subject, but I've personally ported a number of applications, and I've also coded a few device drivers.

We're not BSD or Linux geeks. We're using Atari computers and (in many cases) FreeMiNT.
Ain't no space like PeP-space.

User avatar
aRt
Atariator
Atariator
Posts: 21
Joined: Wed May 07, 2008 9:57 pm

Re: osprey atari coldfire + arm still in development

Postby aRt » Fri May 16, 2008 5:02 am

shoggoth wrote:To make sure I understand you correctly, I've tried to sum up my interpretation of your posts below:

1. Applications will run on the ColdFire, while the ARM runs the OS.

wrong.

2. You're not interested in porting FreeMiNT or XaAES to this system, but you're prepared to write most of it from scratch. You'll keep Linux binary compatibility, including support for Linux device drivers. On top of that you'll add a freemint-compatible GEMDOS/XBIOS/BIOS/AES/VDI trap interface.

wrong, from scratch - wots gotten into you ? :D


3. Your new GUI sports tons of nifty features based on new technologies. Applications can take advantage of such features by using new function calls. This GUI will run on top of X to keep X compatibility.

wrong.

gem - is not really beautiful - it is a square box - like your understanding here - as I am not using X :D I didnt even think I mentioned X - you sound like you want to take over here... go ahead if u like - Im sure u really know this lol


My conclusions:

Just for the record - Debian is a distribution, not a kernel nor a binary format.

sure - but try running a binary for MiNT or an app written for it in debian.


Why would I write an application that takes advantage of the features offered by this system? If I do, I'll break compatibility with current kernels/AES:s (FreeMiNT/XaAES/MyAES). Since I break compatibility, it makes much more sense for me to write a Linux/X application. On top of that, it would be much easier, since I could use commonly available GUI toolkits such as GTK.

break what compatability? Nobodys said that is supposed to happen... jeezes dude... why would I write a linux/x app? have I dissed MiNT is that it? MiNT doesnt cut it - it is a distribution with problems.... as it is only atari users that use it - they are not considered hardware software experts.

Running the OS on the ARM and run the applications on the ColdFire sounds like quite a complex solution to me. Why not just use the ARM as a coprocessor, e.g. as a graphics accellerator for the VDI? You could even port well known libraries such as LibJPEG/PNG etc. and make a wrapper lib for the ColdFire side to handle it.

I want to releave the coldfire from stress and make this efficient - the arm has direct access to devices - the coldfire does not. Still
there needs to be some code that communicates with the arm, so this is not an os on one cpu or the other but it uses both... ofcourse there would have to be some part that enables a system call from the coldfire - to reach the arm asking it to perform a task...

Linux is not BSD is not HP/UX is not Solaris is not FreeMiNT. This is normal within the Unix world. It's nothing weird about that, and actually freemint is Posix enough to work really well in that context. Porting command line stuff is often only a matter of running the configure script and typing "make" in Bash. Some ports are more extensive, but not more than you'd expect if porting to any other GUI. I don't consider myself an expert on this subject, but I've personally ported a number of applications, and I've also coded a few device drivers.

yes, a matter of running a configure script or modifying it - I used to do this some times - but still - there is a reason to wait or expect MiNT users to be able to port a device driver source code or another piece of software - most people want to use other ppls stuff.

We're not BSD or Linux geeks. We're using Atari computers and (in many cases) FreeMiNT.



oh no - he is not a geek! Eeeek!


ooops ;)
The Penguin got a TiNT trippin over a bucket while eating MiNT chocolate...

User avatar
aRt
Atariator
Atariator
Posts: 21
Joined: Wed May 07, 2008 9:57 pm

Re: osprey atari coldfire + arm still in development

Postby aRt » Fri May 16, 2008 6:35 am

I was thinking of what you mentioned...

Here in didiers patched TOS there are several things to consider that do not fit the Osprey.
TOS accesses hardware for disk access, graphics, sound, etc. The Osprey will use the ARM for this so the Coldfire may run applications without slowing down its own bus - and the Coldfire will have its own RAM - and a CF slot. This Coldfire module is intended to be exchangable for future purposes.

Using MiNT would be a good idea for some - here on this board Ive chosen - there is flashram - I would not want to tamper too much with the existing code for flashing - it is not done by a simple controller - it is software controlled - meaning sometimes one has to write 4 times (NAND I believe) to the same nibble to achieve a given state - this is also how some other flash controllers work. Implementing this into MiNT is possible ofcourse - but still - I would have to port a CFslot driver - audio driver - framebuffer driver - the works.

System calls from the coldfire will trigger the kernel running on the strongARM 1110 chip - meaning I would have to patch TOS yet again, which is a possibility but a lot of work - I will see this as a last priority.

One of the top priorities of the OS of osprey is to have speedy graphics for truecolour - concerning mapping, lines, curves the works. Here I see no reason to trust the present VDI accelerators to have a great performance - here the bus is also stressed by the LCD controller - meaning it will slow down the performance of the cpus access to memory.

This Osprey is also a tiny machine - its about the size of a grown mans hand - here one needs to be innovative. For this matter there is a distribution - a debian one that can be altered - as an underlying linux system is more than good enough for running a GEM replacement on top of.

As I said - I want to releave the Coldfire of stress - therefore yielding in processing power - as the apps could go on calculating while other tasks are left to the ARM - here a skilled programmer could really do wonders imo.

There are also plans to fit a touch screen if possible and/or not too expensive.

I welcome good ideas - no problem - but still - there is a necessity for an AES that is optimized for performance and still yielding an interface where one could even have a round window - or atleast non-squarish buttons - there is no reason to live in the past, even though this was not bad at all regarding functionality. but yes, just to show off a product before it is finished - XaAES could be put into use for a demonstration atleast - or be a fallback, and TOS could be interesting to patch for some odd apps to run.

If you could refer me to a link of apps that do not run in MiNT so I could quickly gain an insight on which apps do not run please do so.

regards,

aRt.
The Penguin got a TiNT trippin over a bucket while eating MiNT chocolate...

User avatar
shoggoth
Nature
Nature
Posts: 980
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: osprey atari coldfire + arm still in development

Postby shoggoth » Fri May 16, 2008 9:31 am

First of all, do try to get the quoting right. I do not like appearing mis-quoted like this. There is a preview feature.

aRt wrote:
shoggoth wrote:1. Applications will run on the ColdFire, while the ARM runs the OS.

wrong.

So. Well you did state that the kernel runs on the ARM, and that system calls are forwarded to the ARM CPU. So which is it?

2. You're not interested in porting FreeMiNT or XaAES to this system, but you're prepared to write most of it from scratch. You'll keep Linux binary compatibility, including support for Linux device drivers. On top of that you'll add a freemint-compatible GEMDOS/XBIOS/BIOS/AES/VDI trap interface.

wrong, from scratch - wots gotten into you ? :D


I'm just trying to figure out the technical details round your project. So far we've only talked features, and I would like to know how works.

3. Your new GUI sports tons of nifty features based on new technologies. Applications can take advantage of such features by using new function calls. This GUI will run on top of X to keep X compatibility.

wrong.


So it won't have X-compatibility? How are you going to run all those nifty Debian apps then?

gem - is not really beautiful - it is a square box - like your understanding here - as I am not using X :D I didnt even think I mentioned X - you sound like you want to take over here... go ahead if u like - Im sure u really know this lol


GEM != square box, not necessarily t least. So it won't be GEM-compatible, then?

My conclusions:
Just for the record - Debian is a distribution, not a kernel nor a binary format.

sure - but try running a binary for MiNT or an app written for it in debian.


That wasn't the point.

Why would I write an application that takes advantage of the features offered by this system? If I do, I'll break compatibility with current kernels/AES:s (FreeMiNT/XaAES/MyAES). Since I break compatibility, it makes much more sense for me to write a Linux/X application. On top of that, it would be much easier, since I could use commonly available GUI toolkits such as GTK.

break what compatability? Nobodys said that is supposed to happen... jeezes dude... why would I write a linux/x app?


Ok, so then you're not going to add, for example, a new resource format, after all?

have I dissed MiNT is that it? MiNT doesnt cut it - it is a distribution with problems.... as it is only atari users that use it - they are not considered hardware software experts.


MiNT is not a distribution, it's a kernel. Which distribution are you referring to?

Running the OS on the ARM and run the applications on the ColdFire sounds like quite a complex solution to me. Why not just use the ARM as a coprocessor, e.g. as a graphics accellerator for the VDI? You could even port well known libraries such as LibJPEG/PNG etc. and make a wrapper lib for the ColdFire side to handle it.

I want to releave the coldfire from stress and make this efficient - the arm has direct access to devices - the coldfire does not. Still
there needs to be some code that communicates with the arm, so this is not an os on one cpu or the other but it uses both... ofcourse there would have to be some part that enables a system call from the coldfire - to reach the arm asking it to perform a task...


Ok, but I trust it you'll only run 68k applications on one of them, right?

Again, if the Arm has direct access to the hardware, why not just let it handle VDI accelleration and I/O, and run a proper OS on the ColdFire?

yes, a matter of running a configure script or modifying it - I used to do this some times - but still - there is a reason to wait or expect MiNT users to be able to port a device driver source code or another piece of software - most people want to use other ppls stuff.


Well, if you're not running X, then the users will not only have to run configure scripts and build it themselves, they would have to manually port the application to your own GUI - whatever that is. And, since most pre-compiled stuff is compiled for x86, the user will still have to compile their own binaries.

Sorry if this sounds a bit harsch, again this is not my intention, all I'm trying to do is to get a grip on the technical details, and so far it's ambiguous to say the least. I trust this thing will be GPL anyway, so coders can fool around with it as needed?
Ain't no space like PeP-space.

User avatar
shoggoth
Nature
Nature
Posts: 980
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: osprey atari coldfire + arm still in development

Postby shoggoth » Fri May 16, 2008 9:54 am

aRt wrote:I was thinking of what you mentioned...
Here in didiers patched TOS there are several things to consider that do not fit the Osprey.
TOS accesses hardware for disk access, graphics, sound, etc. The Osprey will use the ARM for this so the Coldfire may run applications without slowing down its own bus - and the Coldfire will have its own RAM - and a CF slot. This Coldfire module is intended to be exchangable for future purposes.


No, Didiers work is available in source form, including stuff that touches hardware. This is also pretty clear in the source code once you read it, and adding support for your architecture shouldn't be that difficult.

Using MiNT would be a good idea for some - here on this board Ive chosen - there is flashram - I would not want to tamper too much with the existing code for flashing - it is not done by a simple controller - it is software controlled - meaning sometimes one has to write 4 times (NAND I believe) to the same nibble to achieve a given state - this is also how some other flash controllers work. Implementing this into MiNT is possible ofcourse - but still - I would have to port a CFslot driver - audio driver - framebuffer driver - the works.


System calls from the coldfire will trigger the kernel running on the strongARM 1110 chip - meaning I would have to patch TOS yet again, which is a possibility but a lot of work - I will see this as a last priority.


Well, I wouldn't try to patch TOS to run on the strongARM. It wouldn't make sense at all. TOS should run on the ColdFire, and could handle the forwarding of system calls to the ARM-thing. TOS itself doesn't impose any significant overhead in this context.

One of the top priorities of the OS of osprey is to have speedy graphics for truecolour - concerning mapping, lines, curves the works. Here I see no reason to trust the present VDI accelerators to have a great performance - here the bus is also stressed by the LCD controller - meaning it will slow down the performance of the cpus access to memory.


Well, you still need a VDI, or your Atari applications will not be able to run. When you say "present VDI accelerators" - what exactly are you referring to?

This Osprey is also a tiny machine - its about the size of a grown mans hand - here one needs to be innovative. For this matter there is a distribution - a debian one that can be altered - as an underlying linux system is more than good enough for running a GEM replacement on top of.


Sure thing, I'm fine as long as you don't induce unnecessary incompatibilities on the platform, because that's the last thing we need.

I welcome good ideas - no problem - but still - there is a necessity for an AES that is optimized for performance and still yielding an interface where one could even have a round window - or atleast non-squarish buttons - there is no reason to live in the past, even though this was not bad at all regarding functionality.


There is nothing that prevents you from adding this to current AES:s, and ensuring compatibility over the platform at the same time. This way *everyone* would benefit from it.

In what way are the current AES:s not optimized for truecolour performance? I asked you this before, but I don't think I got a clear answer to that one.

If you could refer me to a link of apps that do not run in MiNT so I could quickly gain an insight on which apps do not run please do so.


How do you mean? Do you mean TOS apps which doesn't run in FreeMiNT, or Linux applications which doesn't compile right out of the box?
Ain't no space like PeP-space.

User avatar
aRt
Atariator
Atariator
Posts: 21
Joined: Wed May 07, 2008 9:57 pm

Re: osprey atari coldfire + arm still in development

Postby aRt » Fri May 16, 2008 2:37 pm

shoggoth wrote:First of all, do try to get the quoting right. I do not like appearing mis-quoted like this. There is a preview feature.

aRt wrote:
shoggoth wrote:1. Applications will run on the ColdFire, while the ARM runs the OS.

wrong.

So. Well you did state that the kernel runs on the ARM, and that system calls are forwarded to the ARM CPU. So which is it?

true - but there needs to be a kernel on both cpus.


2. You're not interested in porting FreeMiNT or XaAES to this system, but you're prepared to write most of it from scratch. You'll keep Linux binary compatibility, including support for Linux device drivers. On top of that you'll add a freemint-compatible GEMDOS/XBIOS/BIOS/AES/VDI trap interface.

wrong, from scratch - wots gotten into you ? :D


I'm just trying to figure out the technical details round your project. So far we've only talked features, and I would like to know how works.

ok I understand.

3. Your new GUI sports tons of nifty features based on new technologies. Applications can take advantage of such features by using new function calls. This GUI will run on top of X to keep X compatibility.

wrong.


So it won't have X-compatibility? How are you going to run all those nifty Debian apps then?

for me it is the linux system that is interesting - not X, this is due to drivers available for myriads of devices.

gem - is not really beautiful - it is a square box - like your understanding here - as I am not using X :D I didnt even think I mentioned X - you sound like you want to take over here... go ahead if u like - Im sure u really know this lol


GEM != square box, not necessarily t least. So it won't be GEM-compatible, then?

I stated GEM capabilities - ofcourse GEM compatible is an intent.


My conclusions:
Just for the record - Debian is a distribution, not a kernel nor a binary format.

sure - but try running a binary for MiNT or an app written for it in debian.


That wasn't the point.

Well maybe I was a bit unclear then for it sure is a point to me - there needs to be a distinguishment between binaries that utilize parts that debian has that lack in MiNT


Why would I write an application that takes advantage of the features offered by this system? If I do, I'll break compatibility with current kernels/AES:s (FreeMiNT/XaAES/MyAES). Since I break compatibility, it makes much more sense for me to write a Linux/X application. On top of that, it would be much easier, since I could use commonly available GUI toolkits such as GTK.

break what compatability? Nobodys said that is supposed to happen... jeezes dude... why would I write a linux/x app?


Ok, so then you're not going to add, for example, a new resource format, after all?

yes, here again it seems you are being a bit of a wisecrack. surely, the .rsc format is not that easy to expand - but there needs to be support for that - in addition I will add a new format - hopefully xml format that can be precompiled before runtime.

have I dissed MiNT is that it? MiNT doesnt cut it - it is a distribution with problems.... as it is only atari users that use it - they are not considered hardware software experts.


MiNT is not a distribution, it's a kernel. Which distribution are you referring to?
So there is no mint distribution? Excuse me for being a retard then :D Well if you could try to have some understanding - usually one installs MiNT or freeMint and it comes with loads of applets for a shell... unless you download just MiNT - but anyway....

Running the OS on the ARM and run the applications on the ColdFire sounds like quite a complex solution to me. Why not just use the ARM as a coprocessor, e.g. as a graphics accellerator for the VDI? You could even port well known libraries such as LibJPEG/PNG etc. and make a wrapper lib for the ColdFire side to handle it.

I want to releave the coldfire from stress and make this efficient - the arm has direct access to devices - the coldfire does not. Still
there needs to be some code that communicates with the arm, so this is not an os on one cpu or the other but it uses both... ofcourse there would have to be some part that enables a system call from the coldfire - to reach the arm asking it to perform a task...


Ok, but I trust it you'll only run 68k applications on one of them, right?

The intent is to run coldfire apps on the coldfire MCF5272 to be specific so I dont have to answer the same question again ;)
though, there could be a possibility of running a 68k emu lib on one of the two as well as this allready exists, and yes is thought of.


Again, if the Arm has direct access to the hardware, why not just let it handle VDI accelleration and I/O, and run a proper OS on the ColdFire?

Ofcourse this is not a bad idea either - though, the application environment service that need some calculation when many windows and buttons are on screen could also be done there for maxing the coldfires capacity for the apps - this will ofcourse be tested - it is just an opinion of mine that it would be good to have the coldfire doing as little as possible as the AES and VDI are closely related task-wise - i.e. they have a relation in practice.


yes, a matter of running a configure script or modifying it - I used to do this some times - but still - there is a reason to wait or expect MiNT users to be able to port a device driver source code or another piece of software - most people want to use other ppls stuff.


Well, if you're not running X, then the users will not only have to run configure scripts and build it themselves, they would have to manually port the application to your own GUI - whatever that is. And, since most pre-compiled stuff is compiled for x86, the user will still have to compile their own binaries.

Why ? manually port to my GUI? I have not said - no to gem compatability - that is infact my intent. and here u mention x86?

Sorry if this sounds a bit harsch, again this is not my intention, all I'm trying to do is to get a grip on the technical details, and so far it's ambiguous to say the least. I trust this thing will be GPL anyway, so coders can fool around with it as needed?


Well, all you are trying to is definately not to get a grip on technical details, several times you state I am saying things Im not.. :P
- gem capability is not deviance from compatability necessarily - but thanks for the info on the TOS sources, that I like

GPL for everything is not a plan, no. The GUI will not be GPL, neither will the VDI or the AES. This is to avoid too much fooling around - as one ends up with various versions and many problems.
Last edited by aRt on Fri May 16, 2008 3:14 pm, edited 1 time in total.
The Penguin got a TiNT trippin over a bucket while eating MiNT chocolate...

User avatar
aRt
Atariator
Atariator
Posts: 21
Joined: Wed May 07, 2008 9:57 pm

Re: osprey atari coldfire + arm still in development

Postby aRt » Fri May 16, 2008 3:05 pm

shoggoth wrote:
aRt wrote:I was thinking of what you mentioned...
Here in didiers patched TOS there are several things to consider that do not fit the Osprey.
TOS accesses hardware for disk access, graphics, sound, etc. The Osprey will use the ARM for this so the Coldfire may run applications without slowing down its own bus - and the Coldfire will have its own RAM - and a CF slot. This Coldfire module is intended to be exchangable for future purposes.


- No, Didiers work is available in source form, including stuff that touches hardware. This is also pretty clear in the source code once
- you read it, and adding support for your architecture shouldn't be that difficult.

ah, that is pretty cool - I will definately look into this - though, I figured since most software runs pretty well in MiNT there was no real reason to.



Using MiNT would be a good idea for some - here on this board Ive chosen - there is flashram - I would not want to tamper too much with the existing code for flashing - it is not done by a simple controller - it is software controlled - meaning sometimes one has to write 4 times (NAND I believe) to the same nibble to achieve a given state - this is also how some other flash controllers work. Implementing this into MiNT is possible ofcourse - but still - I would have to port a CFslot driver - audio driver - framebuffer driver - the works.


System calls from the coldfire will trigger the kernel running on the strongARM 1110 chip - meaning I would have to patch TOS yet again, which is a possibility but a lot of work - I will see this as a last priority.


-Well, I wouldn't try to patch TOS to run on the strongARM. It wouldn't make sense at all. TOS should run on the ColdFire, and could
- handle the forwarding of system calls to the ARM-thing. TOS itself doesn't impose any significant overhead in this context.

Good then we agree here.

One of the top priorities of the OS of osprey is to have speedy graphics for truecolour - concerning mapping, lines, curves the works. Here I see no reason to trust the present VDI accelerators to have a great performance - here the bus is also stressed by the LCD controller - meaning it will slow down the performance of the cpus access to memory.


- Well, you still need a VDI, or your Atari applications will not be able to run. When you say "present VDI accelerators" - what exactly are
- you referring to?

Now you are saying I have stated I need no VDI? Im saying I will not use any present VDI sources from the atari scene as they are not efficient enough - here I will create, not port. Just as there is no real reason to use XaAES either, unless as a fallback - well, atleast not until the future brings along more goodies....

This Osprey is also a tiny machine - its about the size of a grown mans hand - here one needs to be innovative. For this matter there is a distribution - a debian one that can be altered - as an underlying linux system is more than good enough for running a GEM replacement on top of.


- Sure thing, I'm fine as long as you don't induce unnecessary incompatibilities on the platform, because that's the last thing we need.

Nope, no such intent - it is to be compatible - but with extra features for a bit more modern look, feel, operation.

I welcome good ideas - no problem - but still - there is a necessity for an AES that is optimized for performance and still yielding an interface where one could even have a round window - or atleast non-squarish buttons - there is no reason to live in the past, even though this was not bad at all regarding functionality.


-There is nothing that prevents you from adding this to current AES:s, and ensuring compatibility over the platform at the same time.
- This way *everyone* would benefit from it.

- In what way are the current AES:s not optimized for truecolour performance? I asked you this before, but I don't think I got a clear
- answer to that one.

Well, ofcourse here I must admit I have not used the latest versions myself - but atari has always been a slow experience - and most people that do have the capabilities of coding speedy routines - they do make demos and avoid system stuff at all cost. Im sure I could outdo present routs, etc. AES gets complex with many windows / interfaces to process - also all parts are not necessary to process if they overlap... I am very fond of mac os x and they way they handle things, and it is an intent to eventually have vector based gfx - not bitmap - which also means the AES needs to be restructured and still maintain compatability ofcourse. If you look at the sources of AES by digital research that now are public - u may get an idea.

ofcourse I would love to just use existing AES - use mint etc - it is just that there is a demand for software that works plus has device drivers for various devices as stated before. Im not that interested in jumping into other peoples projects working with code and structures not known to me - here I feel it is good enough to base myself on the original versions I have the sources for.

If you could refer me to a link of apps that do not run in MiNT so I could quickly gain an insight on which apps do not run please do so.


How do you mean? Do you mean TOS apps which doesn't run in FreeMiNT, or Linux applications which doesn't compile right out of the box?


Yes, Tos apps that dont run well in FreeMint. This is a very interesting subject, incase one could chuck out TOS.
The Penguin got a TiNT trippin over a bucket while eating MiNT chocolate...

User avatar
aRt
Atariator
Atariator
Posts: 21
Joined: Wed May 07, 2008 9:57 pm

Re: osprey atari coldfire + arm still in development

Postby aRt » Fri May 16, 2008 3:18 pm

thx for your interest anyways, this has become pages and pages just between me and you - Id like to focus on something else than discussing who said what and how it could be misinterpreted in a forum and get on with something else - first I state this then the opposite - sorry for being an arse - but I get this opinion - though thx for the info on the TOS by didier and available sources. More info will appear as the project goes on. :D

There is a reason to not base oneself on the same as everyone else, it is called option of diversity - and yes - there could still be compatibility.
The Penguin got a TiNT trippin over a bucket while eating MiNT chocolate...

mikro
Hardware Guru
Hardware Guru
Posts: 2035
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: osprey atari coldfire + arm still in development

Postby mikro » Fri May 16, 2008 6:12 pm

aRt wrote:thx for your interest anyways, this has become pages and pages just between me and you - Id like to focus on something else than discussing who said what and how it could be misinterpreted


dude, I assure you there are more readers involved and actually, that guy has asked quite good questions whereas you answered nearly none of them.

i can say only one thing -- try to look / study oAESis / oTOSis project by NoCrew. They were really good, motivated and not alone and even with all this the project never got into any usable form (but sources are free, though). You're taking too much for yourself and ... your presentation doesn't seem very reliable, too.. :/

but... i can be wrong and we're going to see nice atari project in 10, erm 5, erm 1, erm... did I say it's impossible for one person? :)


Social Media

     

Return to “News & Announcements”

Who is online

Users browsing this forum: No registered users and 4 guests