MPC 3000-OS DISC

rokuez wrote:

2wice wrote:

rokuez wrote:i thought that the 3.1 o/s on the 60 basically took up all the memory. In the manual i thought roger linn said they had to work a lot on making 3.1 compact so that it would work on the 60 as well as the 3k. so if u where gogn to have another o/s wouldn't u have to sacrifice some features to add other features?

That's a good point rokuez but some programmers are better than others and may be able to write cleaner, more efficient code so that features could be added without any sacrifices.

So is this something you are claiming "and may be able to write cleaner more efficient code" or do you actually code and know this for a fact about the o/s? typically o/s upgrades require more memory then the previous ones, and i've never seen this not to be the case [i'm not talking about o/s patches or bug fixes].

What 2wice "claims" has so many elements of truth to it.

Software development technology tools have improved a lot since the mid 80's when the MPC60 was first released into the market.

So too has the ability of coders/reversers/re-developers who have been in the embedded computer system development world since day one of the INTEL x86 CPU. ( note ... an MPC60 uses a INTEL 80186 CPU ).

When you mix the two scenarios above together then more features and less bugs can often be the result.

A bonus of retrospective hind sight.

A similar scenario exists in hardware design where the concept of "Logic Device Minimisation" is employed to throw away reduntant hardware while allowing the circuit functions to continue operating in an identical manner.

In particular and where the above comment is concerned ... to minimize the ammount of logic chips that are required in CPU to MEMORY transactions scenarios. Or combinatorial state based logic input to output switching scenarios.

There are plenty of books and tech papers on software optimisation and hardware logic minimisation strategies. ( making stuff grow by shrinking it )

The kind of strategies in initial product development/post product development modification that are employed by most designers I know on a regular basis.

At some point, added features will cause code size to grow.

Think about this point though ...

Some new features in software will, if developed with care ... reuse a lot of code that is already in place.

In other cases a major feature change or fix requires very little code size increase.

In others ... the code size can decrease.

Just my $0.02 ...

Rohan.

"What 2wice "claims" has so many elements of truth to it. "


So in theory yes the idea is there and this idea has been applied succesfully to other technologies, but in practice no because this type of technological upgrade has already been done to the 60 w/ the release of the 3.1 o/s?


"INTEL 80186 CPU"
"In particular and where the above comment is concerned ... to minimize the ammount of logic chips that are required in CPU to MEMORY transactions scenarios. Or combinatorial state based logic input to output switching scenarios"

How many modern features could that intel chip handle to make the 60 have more up to date features with other mpc's (i really want usb transfer for samples and drum pad assignments lets say)? Also how much research and development could one individual realistically do so that software could handle the CPU to MEMORY transactions scenarios and free up more room for the coding of new features?

"Some new features in software will, if developed with care ... reuse a lot of code that is already in place.

In other cases a major feature change or fix requires very little code size increase.

In others ... the code size can decrease. "

What type of current feature changes/fixes could really expand the power of the 60? How much extra would an o/s upgrade costs with these new current feature changes/fixes?


"At some point, added features will cause code size to grow. "

I always assumed that this would occur as soon as a new major technological feature was added especially if it was strictly software, but not necessarily for current feature/function expansion for the 3.1 o/s.

So basically its a matter of integrating the new features software only or new hardware as well ? <-- Maybe if you could comment on what new features software could handle, compared to what could only be made possible through software and new hardware? I assumed that the o/s's memory space was extremely close to be maxed out and that a new o/s with new features not current feature/function expansion/changes/fixes would require new hardware for the additional memory to be used.

rokuez wrote:So in theory yes the idea is there and this idea has been applied succesfully to other technologies, but in practice no because this type of technological upgrade has already been done to the 60 w/ the release of the 3.1 o/s?

One group of orginal developers stopped the development of any further feature set for the 60 and the 3000. ( for many reasons that are well beyond the scope of this forum and right of reply )

rokuez wrote:How many modern features could that intel chip handle to make the 60 have more up to date features with other mpc's

Modern features ?

An 80186 can be coaxed using various work around techniques into performing the same basic math functions as just about any other CPU.
All be that they run at a far slower speed ... because the CPU has a far slower processing speed, no floating point calculation capability, etc ...

rokuez wrote:(i really want usb transfer for samples and drum pad assignments lets say)?

USB transfer has SQUAT to do with the CPU and operating system Rokuez !!!

Drum Pad assignments Sorry not quite certain what you mean.

rokuez wrote:Also how much research and development could one individual realistically do so that software could handle the CPU to MEMORY transactions scenarios and free up more room for the coding of new features?

Don't mix up the comments I made that were addressing two different aspects of a problem.

The fact that the MPC3000 3.16 OS when in ROM, is smaller in size, uses less internal memory to run, runs faster, has less bugs and includes a couple of new features should be a reasonable "proof of concept" example for an existing MPC scenario.

Rohan.

THE CRAFT BEATS wrote:ha ha very funny(not). ok you got me. just trying to ask a question and get a joke of an answer from a dookey shoe ass wannabe producer-engineer mastering lab fool. anyhow thanks to the ones that are not being dooky heads.

"dookey heads"