From mint-bounce@lists.fishpool.fi Mon May 4 04:41:56 2009 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=Re3+mCO39OQGuNYzQAFCSm1pKXBg3oUhnZaSE+AH9zc=; b=hJqAvRQHQR0RhVQVMsAy1XWDNfGes5Yx9VctzRQiFsGWVbpAl47rYXSuA13in1OZhz BtmQD8ki7eKJHVnrXHL8SO/7XJF9w1tgZQKpBojAsnt3lH06I/wsvZpuPUGzmSdk6PII gpII7VkPLgSBQvpQuf4r8LDWTpcnbI8dUJTGM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=ZfnoYhrinU0iEQ7VmErBTZ3d+x7hDIeuvSTc3xDAvrZpoSgkRgvw8gK6KhVjuO5yJQ D6aLPCurvI6w85Y0E28dLnsw1xyMUR2i94/yEb2AffPO4MHgb1wbc5lg8+OBBagE6bl9 mvggf1+uJtWW2WUU0bTMUmOrEc7193VwSrj+c= Message-Id: <4DDDC00A-6634-409B-A776-C96988A541A4@gmail.com> From: Peter Persson To: mint@lists.fishpool.fi In-Reply-To: <1241422433.8225.27.camel@petr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [MiNT] EmuTOS for ColdFire Date: Mon, 4 May 2009 10:38:52 +0200 References: <49FE9448.8020606@freesbee.fr> <1241422433.8225.27.camel@petr> X-Mailer: Apple Mail (2.930.3) X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: pep.fishmoose@gmail.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: > ... The CF step is unnecessary, IMHO. There is no m68k > cleaning that could be reused for a completely different CPU... If "cleaning up" means getting rid of assembler dependencies, sure it helps! > ...If I still were an active Atari developer I would > soon become bored by generating several different binaries (for m68k, > for CF, and for anything else that might appear) especially when I > wouldn't have a chance to test them out properly (I don't plan on > buying > CF). I consider myself an active developer, and this step doesn't bother me at all. Besides, the issue you mention would be the same regardless if we port the system to ColdFire first or not. > Also, the more different CPUs the worse situation is with the user > base. > In plain words - every time you upgrade the hardware to an > incompatible > one you loose part of users. And you don't gain any because there > are no > newcomers on the horizon... Of course this doesn't matter if you don't > care about your potential users - if you do everything for yourself > only... Like Maurits pointed out, this has happened before. Using the same logic, there would be no sence in upgrading to the TT or falcon to begin with. Some of us get motivated by new hardware. Personally, if it wasn't for the CT60, I wouldn't have returned to the platform 5 years ago. New hardware could motivate me for another 5 years. While on the subject; adding a CT60 to the system severely crippled compatibility with legacy stuff (a rough estimate says I lost compatibility with 95% of my games collection), but this didn't bother me at all. I think this is the case for most CT60 users actually; the good side tends to outshine the bad sides. > Please note that I am not in any way against ACP or any other hobby/ > fun > project someone might come up with. I just can't agree with the logic > that is presented here in some mails. I think things work > differently in > real world (and I am talking from my own experience when I release the > multi-platform software I happen to develop). The real world? So the rest of us lives in happy fluffy land, is that it? :-) Maybe I misinterpret you (again), but If I try to sum your post up, I get the impression it's all about "porting to a new architecture is bad in every possible way". But the alternative is to A: look at some FPGA softcore (which is probably not going to happen, and if it does, it will not beat the 060) or B: look at emulation (which isn't an option to some of us). Sure, porting the OS to x86 could be an idea, but then again looking at e.g. AROS (which has been in development since forever) this means being plagued with (severely) limited hardware compatibility. -- PeP