Thanks by the way the card you use, is it low profile? what's the power consumption?

Hi I have a Sam460ex with Radeon AMD Sapphire 6450 card. The VGA and DVI outputs work OK but I didn't get HDMI to work, I even talked to HDR about it but we concluded it didn't work.

But then I was messing around today with my config and discovered HDMI works on UBOOT with this card. Apparently I never tried this before or at least it didn't work that time.

So now I'm thinking maybe it does work and I just have wrong settings somewhere. Thoughts?

@Spectre660

This is basically what AEON do, give you a USB with the Enhancer drivers already installed on it so you can boot from that rather than an actual CDROM.

Any system that uses the standards based way of logging in, rather than the platform's proprietary login system, is considered insecure. Because it can't then be integrated with modern 2FA methods.

I'm not an expert but I thought one needed to use IFF DEEP format for 24 bit images, ILBM could only do up to 8 bit images couldn't it? plus HAM.

I know that, why do you feel the need to tell me?

@broadblues

Don't think I said it was

@discreetfx

Am very sympathetic to your objective of finding developers and excited you're willing to fund some project, but i'm not sure starting with porting Swift is a realistic goal, what is the end you are trying to achieve for which you think Swift is the means?

I assume you are not the original discreteFX guy behind imagefx etc?

@LiveForIt

Amiga API is of course not object oriented, even BOOPSI is accessed from regular C even if it has OO architecture - but there are attempts to wrap it, like APP/OO libraries. The question is are those any good?

Are you sure you want to do Swift? Even if the language is portable, there is apparently a Linux version, it's not going to be super useful without the whole Mac/iOS set of APIs.

MorphOS for example does have an Objective C environment but it doesn't have an implementation of Cocoa and the various 'kits' needed to make Swift do cool things like games and whizzy animated UIs.

It's still hugely ambitious, given we never even got a complete Java, but it's ever so slightly more realistic to do something like porting the Android runtime which could then potentially allow AOSP to run and thus Android apps and games as long as they don't assume and need ARM native code.

Well i think the answer is to not spend any time on timberwolf at all, even if its bugs were fixed it'd still be slow and out of date standards wise. Odyssey/Wayfarer are much faster than timberwolf on the same hardware.

@LiveForIt

I meant, if you need to maintain some global statefulness over the top of a device driver, that's what a handler could be used for.

It's unfortunate, but Firefox itself has been almost completely rewritten at least twice since the version used to make Timberwolf. So little if any of the Timberwolf code would be useful in making a new port from a more recent version.

It's a real shame that Mozilla corp doesn't use the enormous funds it gets mostly from Google in exchange for Google being the default search - it's hundreds of millions of dollars - to support bringing their technology to niche platforms and help make the web accessible to all.

Instead they pissed the money away on vanity projects like firefox OS or buying platform neutral services like Pocket that shouldn't be a part of Mozilla's business.

I was involved in discussions with them around 12 years ago to support them in porting Firefox to Symbian OS, and the sums involved were tiny relative to their budget, but the fact is the people who run Mozilla have no business sense and dithered and dithered about doing it until the window of opportunity had passed. The guy I was dealing with got fed up with Mozilla and left to join the Nokia maemo team.

@geennaam

That's essentially what a filesystem or other handler does isn't it?

Wouldn't it be better if the window's state was separate from whether it was open or not, such that it could be closed and opened (for example after a screenmode reset) without needing to be destroyed and reinitialised? I appreciate intuition doesn't do that but it'd be nice if the window class abstracted it.

@LiveForIt

I don't deny it's a lot of work. But if they are rewriting Workbench anyway for OS4 it might have made sense to do it back then. After all, they have spend 20 years so I think it's not more work than the way they actually did it.

Most OS operate with a window server, window server process owns the windows and controls, application just 'rents' them. In this way one well tested and well written component can take the big responsibility away from apps developers. Why Workbench instead of Intuition though? Because workbench is single place that knows about all kinds of resources, files, icons, windows, processes, ports, devices, whilst intuition is only one subset of that.

@nubechecorre

As far as i know you need a special disk drive designed just for this purpose

Another thing they could have done, since they didn't go down the full sandbox path, is to just allocate a whole 512KB of RAM for every 68K process (and more if set in say, a ToolType), and let the 68K process get all it's allocations from that pre-reserved space. Then if it overruns or accesses illegal addresses it doesn't matter. If it calls OS functions, it should only be reading anyway not writing to memory owned by the OS. Exceptions could be made for filesystems or device drivers, which are more likely to be extensively tested and 'play nicely'. 68K apps shouldn't be communicating through writing to public / shared memory and if they are, fine, create a named memory section exclusively for 68K apps to share and let them all have access to that by default. But not access to memory used by PPC code.

Any memory allocations made by a 68K process should default to SHARED but PPC code should be protected by default.

Sure, it's maybe not efficient but memory is cheap and ample now. And chances are low anyone needs to run 4000 68K apps simultaneously. Even Cinema 4D, lightwave or page stream are happy with only 16MB, they never expected to get more.

@Hans

Couldn't you use a named memory section, where a task needs to know the memory area name to gain access to it? And then generate a unique random name in the initialisation, passing the name to the threads as they are spawned.

Try contacting Hans. If he can find quirks for your particular card documented in the linux drivers he might be able to add better support for it in his driver.