Is it reasonable to ask that a wireless framework be capable of making the Amiga into a wireless access point (going to the internet via ehternet wire) for other devices to connect to over wifi? Or is that too much additional stuff to be part of an initial bounty?

@ChrisH

What relevant APIs are copatible/similar across the 3 Amiga/alike OSes?

TCP/IP stack? PCI? USB? GUI? File access? etc?

Which APIs are different? How much so? What extent of effort is required to overcome these differences?

Some questions extracted from rewriting this topc starter at Amigaworld:

This system at some level will need to interface with PCI and USB, are there other forms of wifi wireless "cards" to potentially use? Would this level of interface be better located in the common library, or would it be better in each individual driver?

Does anyone have a good understanding of Radius? How important is it?

What about other 802.11 imporant keywords that I'm for the moment unaware of?

How do 802.11 A/B/G/N, WiMax, cellular, etc. differ from the driver and software perspective?

Does it make sense to try for a general wireless.library, supporting wifi, wimax, cellular, bluetooth, etc? Or should this forget about other things, and envision more of a wifi.library/802.11.library, then semarate wimax.library, cellnetlibrary, etc? each on top of Roadshow, sortof beside each other in that heirarchy? If split, what would still be common between them, such as GUI interfacing type stuff that could be shared, and begin with this bounty?

What chip vendors forbid open-sourcing drivers for their parts, if any?

@ChrisH

I wouldn't be against an open-sourced implementation, though I'd prefer something that would allow driver coders to do closed source chip drivers should they choose to or need to (as in chip vendor NDA forbids open-sourcing) Open1X is dual-licensed as GPL and BSD. GPL would of course pretty much require allowing the others to benefit. If BSD is chosen, perhaps not so much. I myself would choose which ever allows more drivers to be added. I don't know enough about things to say if that alone chooses BSD over GPL. I'd prefer LGPL over full GPL or BSD, but cest la vie.

I myself am not interested in either AROS or MOS, but at the same time I myself do not necessarily like the idea of going out of my way to exclude anyone from anything. But then it is the policy of amigabounty.net to bounty for whatever the current AmigaOS release is, potentially even excluding 4.0 in the presence of 4.1. I'm not a fan of excluding any 4.x revision users, but majority rules. I have both 4.1 on my AmigaOne XE and 4.0 on my Classic, I really don't like excluding 4.0...

In our small Amiga-alike communities, we do suffer a bit from under-staffing, so we can all benefit from sharing resources as you say. But at the same time, I feel it's an odd thing if all we do is port everything over from Linux. That makes us little more than a more difficult environment to run Linux software, when just running Linux is easier to do that with. I'd like us to all consider that diversity, and reinventing the wheel makes each unique, and diversity and competition can motivate each to improve itself and find better ways to do the same things. That's why there are different Amiga and -alike OSes to begin with. If we really needed to share resources so much, there'd only be one OS, and I decline to speculate which it would have been.

It's partly up to interested developers to negotiate what license they'd like to work with with the bounty committee, and whether they wish to port something like Open1X or if they'd prefer something else or from scratch.

All I want is a decent wireless support for what I use, extendable enough and well documented driver API and protocol API that each driver doesn't need to reinvent the same wheel from the previous driver in the same OS. If we end up with something sharable across them all, that's great. If all we end up with is something for OS4.1, well, that's good enough for me, since I don't have the others.

P.S. What AROS and/or MOS efforts are there to combine with?

Another thought, does anyone know anything about cellular phone modems, either laptop card style or tethering to an external phone via USB cable? I'd like any wireless support we get for AmigaOS to be as extendable as possible, even if there's no immediate use for it, and would like any developer to keep all wireless things in mind for library/API development even if those particular features/drivers/addon libraries are left for the future and/or other developers to make happen...

So, I guess the more technical question is, does anyone know how cellular networking drivers/encryptions/APIs may differ from WIFI/80211.*? What else may be needed for SIM card access to get whatever is needed from them for cellular networking, and what about others in America such as Sprint and Verizon which do not use SIM cards?

What about WiMax?

What other wireless standards (or non-standards) are there that should be included, or at lest possible to add by those who want it later?

I'd like more than just "hey that's a neat idea" discussion, we need some technical discussion from anyone that knows these things to put together a decent plan for API definitions, implementation plan (which features should go in which libraries, and how should they interact with each other), and how best to split different things up into different bounties...

The AmigaOne X1000 looks neat, but I'd still prefer a laptop. One thing a laptop would need, is wireless networkign support, and Wireless networking is currently a bit antiquated, from what I can tell only some old Prism cards can be used for 802.11b speed and now useless WEP encryption. I suppose this could also be useful to desktop users that don't want to run ethernet cables around their house.

So, I'd like to think up a reasonable bounty or set of bounties, to try and help fill this hole. Some things I think should happen for this:

Have as much of this support in a shared library so any wireless chip driver can use that for the settings, search for and connect to routers, handling encryption, and whatever else that is common to usage of all devices. Should be easily updatable to support new types as needed, such as when 802.11 N was added to the list, and for whatever succeeds N later, etc. This library would sit between the hardware driver and the main TCP/IP stack such as Roadshow in OS4.x. Open1X developers indicate that all that Open1X is a TCP/IP stack and control over a DHCP client, which Roadshow and even MiamiDX should offer quite nicely. It sounds like wireless does not need to be integrated into the Roadshow stack itself, which likely makes this more possible if Olaf is distracted with other things.

The wireless chip driver should be as minimal as possible, and the API to the above library should be well documented for anyone to write a driver. It should be supportive of any device type (80211.a, b, G, N, etc), supportive of different security types (WEP, WPA, WPA2, etc) and updatable to future types as needed. I'd like to avoid the multiple API situation on Linux between NDISwrapper, MadWifi, etc. as I saw some mention that Open1X needed to be aware of and be compatible with differences between those driver families, the "Linux native" one, etc. It'd be great if AmigaOS could have a single driver standard.

GUI interface to the library to view/configure settings, encryption type (WEP, WPA, WPA2, etc.), subtype (TKIPP, etc)

Perhaps Open1X (aka OpenSEA xsupplicant?) can be used as a starting point fo rport or to get ideas for a new implementation? (someone else suggested this to me somewhere, I forget who to credit them)
http://www.openseaalliance.org/index. ... task=view&id=50&Itemid=38


I don't know much/anything about RADIUS, it seems to be something additional for Enterprise support of some kind. I don't know that I'd include this as a requirement for the driver bounty, but perhaps encourage to keep this in mind when developing the driver and wireless.library APIs so it's easy to add as a separate bounty task. I saw mention of FreeRADIUS on the Open1X site.

Are there any other additional things that we'd want/like to have?

Any other comments, suggestions, questions to ask, etc?

@JeffShepherd

Quote:

Someone go pull the plug on the black box generator...

Who in Amiga land knows Java as a programmer? We need advice, comments and suggestions from Java experts as to the best way to sort out bounties for various Java features, classes, JDK, etc. so we can begin defining reasonable bounties and moving forward.

Jamiga's sourceforge page claims it to be an implementation of JRE1.4.1. How important is it to update this to a newer JRE spec? I see that Sun has a "draft spec" for Java SE 7 (JRE 1.7?) available now, and gnu classpath claims it needs at least JDK 1.5 to compile. I guess one could compile on a Linux or other host and run on Jamiga... (via retroweaver?)

Seems AWT implementation needs done. Do you imagine that to be a reasonable project, or does AWT need split up into separate tasks to be reasonable for completion?

Any other comments on the current state of Jamiga as a basis to move forward, or what other classes need priority, and what you'd like to see for Java on Amiga, from the Java coder's point of view?

@tonyw

The connector does not have anything running at 800MHz or 1GHz. A1XE memory is 133MHz is it not? The CPU to northbridge bus I think topped out around 200MHz, and I don't think anything on A1XE goes that high.

The 800MHz or 1GHz etc. are derived on the CPU module (inside the CPU?) by multiplying the northbridge bus clock frequency by some selectable number.

You could put a faster CPU on an A1XE module, nobody ever did due to cost and market size. Eyetech slowed down their 1GHz chips due to insufficient heatsink choice, a bigger heatsink would have allowed 1GHz operation. Perhaps some PCB design issue as well, but a good design would not be limited by the PCB for this. No idea if Eyetech/MAI/whoever did a bad job or not, it may be perfectly fine in this context.

@ice2642

I'm very pro-modular. I'd do things similar to your proposal. For how I'd go about it though, it wouldn't be a slot per se, mostly due to connector style of the standard I like. It'd be a module, but lying parallel to motherboard in my ideal design, much like accelerators for A3000/A4000. Not because I want it that way, but because a popular standard I think suitable just already is that way.

One benefit of modular is that you do the hard stuff once, on the module. The motherboard then becomes much simpler, and thus cheaper. And easier to pop out a few different form factors, make an AGP and a MiniITX and a format-X motherboard much cheaper and faster than making complete motherboard designs individually containing everything that could go onto a common module. Granted, if there's only one module, then there's only one performance level. Maketwomodules and 3 carriers, and then you have six configurations but only have to do the hard stuff twice...

@Hans

It's been long enough since I've seen Amiga nterrupt code t forget things exactly, I've been doing some ARM stuff at work to have some thoughts that may or may not work. You mentioned that interrupts are disabled in the reset handler.

In an interrupt handler, I'd think you'd be looking somewhere to see which of a possible set of events triggered an interrupt, to determine exactly what the handler needs to do each time in. For ARM, we use the AIC peripheral to enable/disable interrupts for each other peripheral block (usart, spi, usb controller, etc). Could you check that the Radeon interrupt in Amiga's interrupt controller is enabled or disabled, and if disabled then assume the reset brought us here, if enabled then interrupt brought us here? That'd use the interrupt controller itself as your global flag, though you'd want some assurance that an interrupt event would always look on and a reset event would always look off for that.

This would check the whole system interrupt controller status for Radeon interrupt enable, not checking inside the Radeon's own interrupt status values for which particular Radeon event triggered a Radeon interrupt.

@Ludde

Quote:

leave Nvidia out of your list. There's a lot of it out there, but they don't even have the courtesy to say no or any response whatsoever when you ask for documentation to allow us to create drivers for their stuff. They also do not have the courtesy to even say no or any other response whatsoever when asking about availability of some of their products. Their complete lack of response to us in any way is a very loud NO, we cannot use their stuff on AmigaOS. (And don't say "Amiga" when asking, I didn't, and they still completely ignored us) Unless you're a giant company like Asus or Gigabyte, they don't give a rat's ass. Guess how little they care about the current size Amiga market.

Though Intel and AMD/ATI are possibilities, should the powers tha tbe choose to go x86.

Now, I would like to see AmigaOS go x86 at this point. PA Semi is gone, there doesn't seem to be "high-end" direction for powerPC at Freescale anymore, and I feel weird getting excited about ideas I'd imagine up for the MPC8536 or AMCC chips. I don't want to buy another desktop, and they don't want to port to iBook or Powerbook to get laptops. And I'd love to dual-boot, not dual-lug. Unless/until my XE dies, I don't expect to buy any more Amiga hardware, and I'll be really unhappy to downgrade from G4 ATX to Sam's specs. I think the Sam guys are amazing to do what they've done so far, I just want a lot more performance and expandability, they just offer less than what I have now. Hopefully they'll come out with a higher-end board someday. But going x86 would give we the users a lot more than waiting and hoping that somebody is crazy enough to develop and sell PowerPC hardware we wish for. And it's only getting less possible for such crazies to even do that, with the higher-end chips going away.

Quote:

I have an AmigaOne, I'd be pretty pissed if it stopped running on it. Personally, I think it's a heck of a lot better than the Sam specs in terms of expandability and performance. It's in no way perfect of course, but the only other thing in its class for us Amiga users is the Peg2, which is also unbuyable today.

@Slayer

Quote:

I would call 10 months for a hardware design, prototype, test, debug, respins, and finally production to be incredibly optimistic.

I've been working on my hardware design for about 5 years, and have yet to do a single PCB trace layout for it. Others in the PowerPC hardware universe are beginning to do something reasonably close to my idea, so I may try and make use of that someday, even if it's not exactly what I'd like. (Though what I'd like became impossible with the deaths of PA Semi and Uli Electronics, my second-best is still to me better than what I see happening out there) It'll be at least May before I can shell out the big bucks for an evaluation of the (IMNSHO) 3rd-best solution, according to that vendor.

@Slayer

Making hardware is a lot more involved than porting open-source. Trust me, I've wanted to make a highly modular platform for ages. I've been cooking my idea in my head for about 5 years now... I woul dnever ask for bounty money or people to donate to one for such a thing though. What if I never get something sellable? It would take *_MUCH_* longer than a couple months to do...

@nexus

Quote:

I'd prefer Konsole. I don't want all of KDE, but Konsole would be cool.

@Raziel
From your link:

Quote:

Uh, Mobile Intel 915GM chipset?!

@Cyborg

My motivation for wXwidgets is for CodeBlocks and KiCad which is a PCB design program.
http://www.lis.inpg.fr/realise_au_lis/kicad/
http://kicad.sourceforge.net/wiki/index.php/Main_Page

I'm trying to find out what portions of WxWidgets it uses.

The austhor of KiCad tells me this:
..uses mainly wxCore (wxBase + obviously the graphic layer) , wxGL
(opengl layer) and some of wxNet (wxSocket client and server)
and wxSahshWindows from wxAdvanced

@salass00

Is there anything more recent happening that than sourceforge thing? Looks awfully quiet and most of the cvs repository is dated two years ago. A couple things are 11 months or 9 months old, but still not terribly inspiring. And no user package for download. I've found a couple apps using wxwidgets that I'd love to see ported.

@Atheist

I'd really prefer a small MiniITX case. Something standard so I can buy what I want for reasonable price. I don't want a keyboard style one, because I have a nice KVM setup, would buy a larger KVM if I must, but would have trouble finding room for two keyboards.

@orgin

My own personal interpretation of the AmigaOne Partners contract would allow it. I also read it to allow any new hardware platform so long as it is marketed "for the Amiga platform". That of course doesn't amount to a hill of beans, we'll just have to wait for the lawsuit to run its course to find out what a meaningful opinion from a judge turns out to be.

From the contract, the term "Target Hardware" is defined as (with my bold font)
Quote:

IMHO that "but not limited to" allows more than just the CSPPC, BPPC and AmigaOne. Until a judge rules on everything caution and paranoia may be prudent, but what fun is prudent in our community? :)