For those of you I still owe hardware to I would like to publicly apologize for the delays.
My personal life has been screwing up everything else since late December.
I have everything (including my work areas) moved to a new location, and all the backlogged stuff should be ready soon.

I would also be the first to admit that I probably cost us the Libre Office port as, while I had the machine, I spent too much time worrying about a bounty proposal.
I should have just shipped it out
Anyway, I still have one MDD to donate to a good cause.

And then I have my own software project to dig into.

Take care all.

Jim Igou

> I would also be the first to admit that I probably cost us the Libre Office port as,
> while I had the machine, I spent too much time worrying about a bounty proposal.
> I should have just shipped it out

Your posting from 2 weeks ago didn't read like this would have changed anything.

No, Eric backed out. But his friend Steve617 is still here. And Libre Office just looks time consuming. Also breaking out the word processor after version 3.5 is going to be a pain. Luckily haywirepc is taking my earliest (and quietest) Power macs, my Quicksilver. And I have decided to keep one MDD. Leaving me with one more to give away.

> No, Eric backed out.

Yes, that's what I read from your posting back then. With that said, what would have been won if you had "just shipped it out" to Eric? I'd even say it would have been a loss because now you can still ship the unit to a developer that has the time to develop for MorphOS.

Thanks Andreas,
You have always offered sound opinions.
That does make me feel better, because I have been kicking myself in the ass about this.
I would like to devote more time to this, but I have to work too.

I also just realized that MorphOS would make a nice basis for emulating my older 68K and 6809 OS-9 software.
I know one of the NitrOS-9 developers (actually I've known him for some time).
Microware let them get away with a 6809 version because they were abandoning that market.
I wonder how they feel about a 68K version (or PPC version that emulates the older two cpus).
Could be a problem because they are still releasing updates for the 68K version.

Still, it would be nice to have access to MorphOS features like TinyGL and 68K JIT.

> I also just realized that MorphOS would make a nice basis for emulating my
> older 68K and 6809 OS-9 software. [...] I wonder how they feel about a 68K
> version (or PPC version that emulates the older two cpus). [...] it would be
> nice to have access to MorphOS features like TinyGL and 68K JIT.

Trance wouldn't be usable for this:

"Trance also interfaces to MorphOS in some fancy ways, there simply is no way to make the service available for any external applications for example."
https://morph.zone/modules/newbb_plus/viewtopic.php?forum=32&topic_id=6106&start=30

And I have my doubts about TinyGL either.

Bad news about those, but I am barely starting to feel comfortable with MUI.
And I wasn't really thinking of an external application.
At least not entirely external.
And I now other authors that have created JIT code.
Pretty intense stuff.
I spent some time studying it this weekend (along with some cool multi-threaded memory controllers for FPGA designs).

Oh, and one video cards down, three to go.
Looks like they will all be on there way before next weekend.

Also, Claus could use a MorphOS key to help develop Cinnamon Writer.
I'd do it, but I'm tapped out and still need to buy one key for the second MDD.

[ Edited by Jim 26.05.2013 - 00:05 ]

> I wasn't really thinking of an external application. At least not entirely external.

At least I can't think of any sensible solution on how to do this without something that's basically an 'external application'. Piru has been pretty clear that Trance can by design only be used for m68k binaries which run directly on MorphOS (and thus using AmigaOS ABI), without any other layer (except Trance itself) underneath. Non-AmigaOS/MorphOS apps, no matter if m68k, PPC or whatever, would have to be run in an 'external application'.

I am too used to applicatons doing things modularly Andreas.
Sure, MorphOS code and external working together.
I am not asking MorphOS to do anything it can't.
That would be what would have to run extenally.
And MorphOS can not differentiate between threads from internal or external sources as long as you don't break anything.
Its not nearly as complicated as you have been making it out.
It just another ASMP scheme that also makes use of Abox resources when it can.

> Sure, MorphOS code and external working together.

Using a MorphOS component like Trance from within an 'external application' requires the component to provide an API for doing so. Piru has been clear that Trance doesn't provide this.

> I am not asking MorphOS to do anything it can't.

Then it seems I'm not clear on what it exactly is you're asking MorphOS to do, and I probably misunderstood your previous postings. Maybe you could elaborate on it in more technical detail?

> That would be what would have to run extenally.

I don't understand. What's "that" referring to?

> MorphOS can not differentiate between threads from internal or external sources
> as long as you don't break anything.

As far as I have understood Piru's statements, the problem with using Trance for m68k binaries that don't run directly on MorphOS (i.e. are using another ABI and thus need one or more layers like a 'box' around them) is not about threads but about lack of option to hook into Trance from within the additional layer.

> Its not nearly as complicated as you have been making it out.

That's neat to hear. Still I'm inclined to hang on Piru's every word when it comes to what Trance can or can't do and what 'external applications' can or can't do with Trance.

> It just another ASMP scheme that also makes use of Abox resources when it can.

I don't see how anything we've discussed in this thread has anything to do with ASMP. And I can't see how ASMP would be a solution to the limitations of Trance as explained by Piru. Maybe I'm just lacking your imagination ;-)

So what your a planning is something like ShapeShifter, where the alien OS runs alongside MorphOS ?

The problem I see here (without any knowlegde on Trance) is that the guest-OS would load 68k-binaries without going through the dedicated MorphOS functions on handling Amiga-Hunk-files (which these files aren't). At this point you have 68k code in the system not flagged as such by Trance.


"Better" way, make your guest OS run inside UAE (I think I saw someone running ATARI-TOS in it), or if you are really brave start with UAE's 68k(JIT)-EMU !

Actually, I don't know if your problem is imagination, application, or a stubborn streak.
A lot can be done outside of the original intent of the OS' authors if nothing prevents it.
And, ASMP is only one potential solution to the issues you have mentioned.
The real trick to any of this is getting the result you want without bringing something else down.
Its a matter of transarency.
In one system I worked with, we created a driver for an onboard peripheral that inserted an extra memory read or write inseted during a period that the cpu wasn't able to access memory.
In another, we asserted a 6809 bus halt singal while a peripheral accessed system reasources, then elinquished it. Transparent to everything except the system clock (THAT was actually the harder work around).
For a third, we re-wrote system drivers to eliminate 68K ISA bus access so an NEC V20 could concerently run X86 applications, The 68K essentially, was aware of the V20 but not vice versa.

So, to wrap your imagination around it Andreas, think about this. The tactic is developing a work around the side steps the issue by having another process do it outside of normal OS resources or control.
Luckily there is no supervisory process under MorphOS.
If MorphOS ever runs under a hypervisor, well its still not impossible, just a lot harder.
I worked with one project on a OS-9 system where we created a low priority process that acted like a deamon. It roved around looking for dead proceses and removed them (when you've only got a limited amount of memory, you make sure you don't have any leaks).

This whole discussion points out a difference in the way you and I approach things.
You have always been very linear. So its inherent that when your told something is a limitation ou accept it.
I tend to jump around more and look for a hack that will circumvent the limitation.
And its worked for me in the past with hardware and software projects.
Considering your background with Amiga software and hardware, I am sure you have seen this approach before.

That probably expains why my Snow Leopard install isn't on Apple hardware.

If you doubt me, or if any of the developers questions the idea (which I doubt since I can see signs that they used this approach before), get me minimal kernel documentation and I will provide you an example.




[ Edited by Jim 26.05.2013 - 13:43 ]

@ Kronos
Yeah, now I am dealing with someone that has obviously run into (or over) similar obsticles.
I like the ideas you have mention,
There is also Mess.
In fact Mess would work much better if it could be run independantly (outside or alondside Abox).

One of the things I really like about MorphOS is its use of JIT as it is less resource intense then full emulation.
And nothing prevents additional JIT processes.

I just started researching this approach two days ago when I realized that only a few attempts had been made to emulate a 6809 this way and even fewer 6309 implementation.
If trance is too tightly coupled to allow MorphOS' built-in JIT, another interpreter could be run.
Luckily there has been more work on this processor.

It was this, and the question of transparently multiplexing memory access for multiple 6309s that brought me some surprising answers.

There is a lot you can do that you are not supposed to be able to.

> I don't know if your problem is imagination, application, or a stubborn streak.

My "problem" is that your idea contradicts what Piru (and other MorphOS Team members) told us about how Trance was conceived. So either Trance offers the functionality required for your idea or it doesn't. According to Piru, it doesn't. You can't really blame me for believing him, can you?

> A lot can be done outside of the original intent of the OS' authors if nothing prevents it.

It's not about (artificial) prevention of any kind. It's about whether the basic concepts are there for your idea to even have the slightest chance to get implemented. If I got Piru right, the sheer conception of Trance prevents it from being used the way you want to. Of course, you might be brave (or insane?) and attempt to hack MorphOS by replacing Trance with your own m68k JIT compiler that actually can be used like you want to. But then, that wouldn't be Trance anymore, would it?

> ASMP is only one potential solution to the issues you have mentioned.

I still can't see how. Maybe a more detailed explanation would help me here.

> The real trick to any of this is getting the result you want without bringing something
> else down.

Yes, this would mean that the Trance substitute you're going to implant into MorphOS should provide all functionality of Trance, as well as the new functionality added to make your idea a reality.

> The tactic is developing a work around the side steps the issue by having
> another process do it outside of normal OS resources or control. [...]
> I tend to jump around more and look for a hack that will circumvent the limitation.

To "work around", "side step" or "circumvent" the issue of Trance lacking the required functionality would mean to use your own m68k JIT compiler ("another process") instead of Trance (akin to Kronos' proposal to use UAE with its own m68k JIT compiler). But then, how would this be using Trance, which is what we're talking about here? Working around the missing functionality of Trance by using another solution instead of Trance would amont to *not* using Trance at all.

> when your told something is a limitation ou accept it.

You really think too linear of me. It depends on the specific nature of the limitation (artificial or by conception). Artificial limitations can often be circumvented with not too much effort. Working around conceptual limitations usually involves severely altering or even completely replacing the limited object.
The limitation we're talking about here is of the latter kind. So yes, you can try to hack the functionality you'd need into Trance without sacrificing its current functionality. I don't think that's possible for anyone without source code access though. Replacing Trance on the other hand wouldn't be a way of using Trance, obviously.

> If you doubt me

Yes, in view of Piru's statements about Trance I doubt that you can use it the way you'd like to, i.e. running on MorphOS a non-Amiga m68k OS inside an encapsulated environment and using inside this 'box' MorphOS' own Trance for the JIT compilation from m68k to PPC code.

> or if any of the developers questions the idea (which I doubt since I can see signs
> that they used this approach before)

Which "signs" are you talking about here? Where did the MorphOS developers use "this approach" before?

> get me minimal kernel documentation and I will provide you an example.

Unfortunately, the Quark API documentation isn't public. And I'm not sure how Quark API access would help with using Trance, which is a task running on top of ABox, which in turn is a task running on top of Quark, from within a 'box' running on top of ABox. But then, I'm just a layman with severe lack of programming background :-)

> I like the ideas you have mention

Kronos' idea (I can see only a single one in his posting) is basically about avoiding Trance completely and using another m68k JIT solution instead.

> There is also Mess.

As far as I kow, MESS doesn't have JIT compiler (called 'DRC' in MESS/MAME parlance) for converting m68k code to PPC code.

> Mess would work much better if it could be run independantly (outside or alondside Abox).

Why?

> JIT [...] is less resource intense then full emulation.

You can have full emulation with JIT (e.g. UAE on x86) or without JIT (e.g. UAE on PPC), and you can have transparent emulation with JIT (e.g. MorphOS with Trance) or without JIT (e.g. MorphOS with Trance switched off).

> nothing prevents additional JIT processes.

Exactly. In order to realize your idea you could use your own m68k JIT compiler (or UAE with upcoming m68k JIT compiler as Kronos suggested), which would mean avoiding Trance.

> If trance is too tightly coupled to allow MorphOS' built-in JIT, another interpreter
> could be run.

Exactly, and you could even run a JIT compiler instead of an interpreter.

> Luckily there has been more work on this processor.

Yes, m68k JIT compilers are not too scarce, but unfortunately mainly for x86 and not for PPC.

What about a kind of a "Wine" approach. I.e. an API wrapper for your 68k OS to MorphOS. For an implemantation like that Trance should do the 68k work.

[ Editiert durch Zylesea 26.05.2013 - 19:23 ]

Its a interesting idea Zyleasea, but while they are both micro kernal OS', there is a lot of differences between OS-9 and MorphOS.
For one, OS-9 only allows for position independent coding.
Which explains why there wasn't an X86 version until the '386 was released.
This started with the 8-bit version, and is part of every other version.
Current, the only actively developed versions are the 68K port and the X86 version.
However, a wrapper presents an interesting idea.
How about wrapperS.


And since supporting the 8-bit version first was my main target, the whole issue of 68K JIT don't really interest me yet.

6309 JIT is challenging though. I've only found a few people that had tried to implement this.

Also, I'm not doing anything to bite the hand that once fed me.
Microware used to treat us very well (including giving us a discount on Basic09 that allowed us to offer the lowest price in the US on the 68K version).
They've let 8bit knock off like NitrOS-9 to be developed because they left that market.

Personally, I don't like Basic. I always preferred Pascal, so I've modified the 8 bit version of Pascal09 to run on a modified 130XE.

So, as I work on my main project.
I'm also looking at a JIT implentation for the 6309 that will run in a PPC environment.
Its going to be a busy summer.

Andreas is right. Its all a little crazy.
But the whole idea of re-implenting the AOS 3.1 API was a little crazy and its been done three times now.

BTW - Anyone need a spare part for a Honda RC30?
I'll be selling those off this year too.

>As far as I kow, MESS doesn't have JIT compiler

no, but one former Amiga developer was consider it for 6309 emulation

>> As far as I kow, MESS doesn't have JIT compiler

> no, but one former Amiga developer was consider it for 6309 emulation

Please refrain from misquoting me. What I wrote is this:

"MESS doesn't have JIT compiler [...] for converting m68k code to PPC code."

In fact, MESS does have many JIT compilers (whether also for 6309 emulation I don't know).

Don't get testy Andreas, that was not a mis-quote it was a partial quote that didn't deliver your full intent.
And I never meant Mess would be suitable for the 68K emulation tasks I've mentioned.
Also, you're awfully fixated on 68K code.
I have already said that might not be legal.
I don't want to emulate something that still licenses for several hundred dollars if it ruffles Radysis' feathers.
I could get started with the 6309 work immediately since the 8bit derivative is now open.

Frankly the 68K stuff that was done would compare poorly to Amiga related packages because the GUIs were just getting started and the hardware was focused more on multi-user institution.

> that was not a mis-quote it was a partial quote that didn't deliver your full intent.

It is a misquote, obviously, as it is a partial quote that turns my true statement into a false statement.

> I never meant Mess would be suitable for the 68K emulation tasks I've mentioned.

You were not clear about that when you mentioned MESS the first time. You replied to Kronos who talked to you about m68k emulation:

"I like the ideas you have mention,
There is also Mess.
In fact Mess would work much better if it could be run independantly (outside or alondside Abox).
One of the things I really like about MorphOS is its use of JIT as it is less resource intense then full emulation."

So you clearly referred to m68k emulation right before and right after your two sentences about MESS. How should anyone not conclude that the part in between was about m68k emulation as well?
But well, thanks for clarifying your confusing statement.

> you're awfully fixated on 68K code.

Huh? How do you come to that conclusion? *You* were the one talking about using Trance for your ideas, and as you might know, Trance is for running m68k code. I've merely replied to that idea and gave my opinion.

OK, to claify, my initial intent is to see if I can get 8 bit 6309 based NitrOS-9 software runningunder MorphOS.
Incorporating JIT 6308 translation instead of straight emulation would be a better way to approach this.
For those who aren't familiar with ita, NitroOS-9 is a Level I and Level II OS-9 compatible operating system.
One of the NitrOS-9 developers, Boisy Pitre, is the designer of the 6809/6309 adapter that I use to run a Hitaci processor in my Atari 130XE.
Boisy and his partners Mark Marlett and Aaron Wolfe own Cloud-9, a company specializing in hardware for the Tandy Color Computer including static ram expansions and hard drive interfaces.

Since the source code for NitrOS-9 is available, it ould bea really complicate (but not impossible) project.
Running 68K software would require a lot more work and would likely incur the roth of Microware's current owner Radysis as they are still selling and supporting the 68K version of OS-9.
Also, GUIs aren't unified across the OSK base, so our own native software looks and runs better.
OS-9's strength was always its multi-user support and its compact size (using a microl kernel similar to Quark).
While I'm nostalgic about the OS-9 68K system I used to build, I'd hate to have to go back to using crude software like the text editor VED that I used to edit text files under OSK.
A 68K expansion of NitrOS-9 would be interesting.

All this takes a backseat to the software I've been working, and will be working on this summer.

So...if trance interfers with my ability to run straight 68K code under MorphOS (which I'm not convinced it does), that problem is not important for quite awhile.

Anyway, we're way off topic.
I created this thread to let the four people I owe video cards to an update on my progress. Since its creation, I've completed the hardware modifications and just need to flash three out of the four.
Then cards get shipped to AmigaDave, Soviet, CountRaven, and Coolamiga_N (and I keep two for my own use).
Once done I can get back to polishing my coding under MorphOS and leave the hardware alone until G5 support is released.

Jim, saw your pms but I just found the time to reply.

Forget about the hardware man! Take care of yourself and your family first. Doesn't matter if we (I) wait a couple more or less. Just you be safe. What are friends for if not at least show some patience? After all, imo you are a great asset to the MorphOS community, by providing all this service for free! No one can possible complain to you.

Anyhow, regarding the card(s). Don't want to add to you, any (extra) money. I really want to notify me regarding ANY extra cost that you may have encountered so far.

Take care :)

> my initial intent is to see if I can get 8 bit 6309 based NitrOS-9
> software runningunder MorphOS.

For emulation of 6809 (which NitrOS-9 should run on as well), have you had a look at the following programs?

http://aminet.net/package/misc/emu/D32
http://aminet.net/package/misc/emu/flex

They're closed source so not suited as base for own developments. However, they might work on MorphOS.

> Since the source code for NitrOS-9 is available, it ould bea
> really complicate (but not impossible) project.

You mean closed source would make it less complicate?

> if trance interfers with my ability to run straight 68K code under
> MorphOS (which I'm not convinced it does) [...]

Who said that Trance would interfere with your own m68k emulation solution? What's been said is that you can't *use* Trance for your idea but have to use another emulation solution instead. I see no reason why that other solution couldn't run beside Trance.

No, I had not seen those before.Thanks.
Some of our customer used to use Flex,.
It's a much simplier OS, but some people just want to get up and running and have a CLI they can call up their programs with. Its similar to Peter Stark's StarDOS system.
I hink the first time I saw Flex was on a friend's SWTPC system.
I wish I'd bought that hardware when he offered it to me.
Southwest systems are going for about $3000 currently.

I'd prefer to work with the 6309 instruction set.
Its a superset of the 6809 instruction set with some neat additions and the 6309 processor has some added features like a 32 bit register (yeah, an 8bit processor with 16 and 32 bit registers).