@Helgis

http://sourceforge.net/projects/amiopenoffice/
The very very little that is there is very very old.

This shows a link to http://amigaopenoffice.org/ and that web page gives a forbidden access error.

There is a bounty suggested for it here
http://amigabounty.net/?function=viewproject&projectid=45
but I guess no one has been interested in taking it on, as it's not progressed even to the "unassigned" status.

@Hans
Quote:

Any discussion on which open-source GUI frontend for GDB, or if a from-scratch new GUI is preferred, should the relevant bounty be opened? I posted a quick list of existing open-source frontends I found on wikipedia in the bounty comments. It's probably not complete.

http://amigabounty.net/?function=viewcomments&projectid=47

@kas1e

There's an amigabounty request for GDB to update to latest GNU release and make it work well.

http://www.amigabounty.net/?function=viewproject&projectid=54


There's also a separate bounty for a GUI interface to GDB.

http://www.amigabounty.net/?function=viewproject&projectid=47

@JeffShepherd

Quote:

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

@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.

@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?!

@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? :)

Seeing where Tao Group is right now, I can't help but giggle about this any less than slashdot people would giggle about an AmigaOS port announcement. Have at it and all, but I see less point for this than a port for OS4 has. DE only really runs on Windows variants, so why not just use or port browsers for Windows variants?

Eh, saw the other post showing how old that project is... I didn't see any dates on anything at their site. Back then maybe it made some amount of sense to support DE with a browser.

Oh well for VESA then. It does make mroe sense to define the software API than the register set, but a standard register set would have been more convenient for this sortof OT discussion.

I hope to get my AmigaOne booting again soon, then I can work on finding time to do something toward Radeon again.

Here's another question toward a VESA generic driver. Is there a standard definition of VESA graphics registers, refresh rates, PLL settings, etc? Previous graphics like VGA and SVGA I think were completely standard everywhere, or at least to a large extent. If there is some absolute standard for all VESA registers, their offsets, sizes, field definitions, etc. then even without an x86 emulation it could be possible to write a driver to that standard register set instead of using x86 stuff, much like the current driver talks directly to Radeon specific registers or Voodoo driver talks directly to Voodoo specific registers. Yes, a great deal of work and all. Who's interested in researching this and has time to do so? I suppose a new thread should be made to further the VESA driver concept if it gets anywhere. If there is a standard register set it's the same kind of work as making or porting the Radeon open-source driver, but probably less as there's probably not much acceleration for lines, rectangles etc. to do as there is in chip-specific drivers.

@joerg

Quote:

I wouldn't mind having some generic VESA mode driver. Why? I've got a particular Radeon card who's chip IDs are not yet in the graphics driver ID list, so the system does not know to load the Radeon driver for it. It thinks there is no graphics card present. How do I add my card's IDs to the list? I could swap graphics cards around. I could have previously set up envoy or samba. There may eb a coupel other ways I haven't thought of. But with none of these already in place, it's an inconvenience. If I find my particular Radeon card somehow does not work withthe current driver, I could use it in VESA mode until we get things working with it properly without constantly swapping cards back and forth. If it fails the test then just reboot with VESA, make some edits, recompile and try again without the power cycle and board swaps. may not sound like much, but saving that small inconvenience would be beneficial to motivation. Sure, it'd be a lot of work to make a VESA driver, but I think it would be useful to have available if some issues could be solved.

You get into the question of how does the computer know what card is a graphics card or not to try the VESA diver with. If it's not already in the graphics card IDs list, do you ned to add your new card, and how? Or will there be some new field setting in uboot, and some list of PCI IDs you can get from uboot to know what the IDs of your new card are without booting Linux or something? You don't want the computer trying to run VESA driver on a sound card or SATA card etc but how will it know which is the graphics card? Wil it end up having the same problem with an unlisted gaphics card as I have with my particular Radeon card, and thus not really solve anything?

We do have the x86 emulation in uboot that runs graphics BIOS. But it lacks some instructions, as can be sen if you try and boot with an AllInWonder 8500-DV card, which fails due to non-implemented instruction error in said emulation. Is there enough there to run BIOS subroutines? I don' t know. Is it available to OS4 using this emulation? I don't know that too, but I am under the impression that anything uboot goes away when OS4 begins, and not much is handed off during the transition.

@Hans

I wouldn't know if you can plug in AGP and PCI-66 together. I would imagine it'd work find in a 66 slot. If not, plug it into a PCI-33 slot instead. As for switching between them, I don't know that too. I just swap cards installed, I've never had two together, habit from early on when that definitely would not have worked, but I don't know if that's changed or not.

Realize that the PCI vendor/device IDs need added to the list before they will be recognized, without that the computer doesn't know to try the Radeon driver on any card. That's my current problem with my A1, I need to swap in an older card in the list to install OS4, start over, edit the list to add my X1950, and then try that card again. Right now all I get is a message that no known graphics card was found to run an OS4 driver, but I do see that printed on the screen connected to the X1950. :) Ugh, if only I had time to fiddle with that stuff.

@Hans

Radeon X1550 pro directly for PCI slot:
http://www.newegg.com/Product/Product.aspx?Item=N82E16814103031
http://www.newegg.com/Product/Product.aspx?Item=N82E16814161074

Radeon X1300 PCI:
http://www.newegg.com/Product/Product.aspx?Item=N82E16814129062

@MikeB

As a user I don't have much interest in PS3. I've got a desktop tied to a desk, I don't have much use for another, which is what the PS3 would be. I do want a laptop, which ps3 doesn't help with.

As a developer for OS4, there could be a few useful things to it. It's got bluray and HDCP, so one coule potentially use this as a platform to create players, drivers, APIs, secure data transfer stuff, etc. to play HD movies. I'd still prefer a laptop though. I'm really not likely to buy any more OS4 hardware that's not a laptop.