[Coco] Emulators on a laptop?

Roger Merchberger zmerch-coco at 30below.com
Mon Feb 5 22:06:13 EST 2007


Rumor has it that Mark McDougall may have mentioned these words:
>[snip]
>One of the main reasons why MESS tends to slow down each release is
>because the core code becomes more 'generic' as more and more systems
>are added to the emulator. This is because the core functions, such as
>displaying graphics, reading inputs, playing sounds, etc need to be able
>to handle an ever increasing variety of systems - and hence a greater
>number of 'cases' for each functionality.

Whilst I have absolutely no "problem" with this, if it further slows the 
CoCo emulation down (which should be far faster, IMHO), why do *we* need to 
keep updating it?

Could we not just "standardize" on the earliest working M.E.S.S. that works 
well and stick with it... or are there a lot of bugs still being found in 
the codebase that affect the 6x09 emulation?

I've been looking into what it would take to compile M.E.S.S. ourselves, to 
possibly optimize it for our particular use... it looks a little intensive, 
but nothing that can't be figured out with a little time and/or work...

I saw on the MAME download page that they have an i686-optimized binary for 
download, but not for M.E.S.S. I think it would be safe to hazard an 
assumption (knowing the implications) that most of us might have a 
Pentium-based PC by now... ;-)

If we could "turn off" all of the stuff we don't need and compile an 
optimized M.E.S.S. just for us, that might help a lot with performance & 
memory issues...

>For example code that must handle scalable sprites or rotating,
>scrollable bitmaps is always going to be slower than code hand-optimised
>for 8x8 sprites or 256-colour, fixed bitmaps. However from an
>architecture point of view, it's much more preferable to have a more
>powerful, generic core that handles the most demanding case, as opposed
>to many, albeit faster, distinct implementations for each case.

Yes, but sprite code altogether we don't need - the CoCo has no sprites 
(well, other than implemented in software... GET/PUT/HGET/HPUT)... If there 
was a way we could "slim down" some stuff we don't need, that might help 
immensely...

>A dedicated (well written) Coco emulator is always going to be faster
>than MESS.

Yes, but maybe a *tailored*[1] M.E.S.S. we could at least split the difference?

Just random thoughts...

Laterz,
Roger "Merch" Merchberger

[1] I actually typoed "taylored" first... maybe that would be appropriate 
tho??? ;-)

--
Roger "Merch" Merchberger   | "Profile, don't speculate."
SysAdmin, Iceberg Computers |     Daniel J. Bernstein
zmerch at 30below.com          |




More information about the Coco mailing list