[Coco] OS9 68K, MM/1 software and questions

[James Jones]

About the MM/1: I suspect that there were two kinds of mainboard, because
the original, as people have said, used the Signetics 68070. There was a
later version, which I think people may have called the "MM/1a", which used
one of the Motorola CPU32 chips. Had to pause and look it up--the CPU32 is
like a 68020 without bitfield instructions. It is definitely the one to
pick if you have a choice; the 68070 is constrained to the 68000
instruction set, but has one less ALU than the 68000, so in particular,
effective address calculation and arithmetic can't overlap. The 68070 is
thus *slower* than a 68000 running at the same clock rate. The 020
instruction set includes ext.bl, so you can sign extend a byte to a word in
one instruction, more multiplication and division options, scaled indexed
addressing modes, and could work with a 68881(?) floating point
coprocessor, though I doubt that the MM/1a mainboard had one of those.

The version of OS-9/68000 that came with the MM/1 had the pre-Ultra C 68K
compiler, which was about at the level of a post K&R pcc. It had bitfields,
I believe, and enumerations, and one could return (and, I believe, pass)
structs and unions (though it did things the pcc way, and hence recursive
functions returning struct/union would fail). It also had the code to
implement what in the ANSI/ISO C standard is called the "as if" rule. (The
ANSI C standard describes the actions that, if you carry them out, do what
a given C statement/function/program is supposed to do... and then
saying.that actually you can do whatever the heck you want, as long as you
get the same result *as if* you did all that stuff--e.g. for

char c1, c2, c3;

c1 = c2 + c3;

you do NOT have to execute

 ext.b <c2>
 ext.l <c2>
 mov.b <c3>,<c1>
 ext.b <c1>
 ext.l <c1>
 add.l <c2>,<c1>

but instead you can execute

mov.b <c3>,<c1>
add.b <c2>,<c1>

I liked to call it eliminating gratuitous SEX, though that's a 6809
instruction. On sample programs, implementing "as if" sped the resulting
code up by something like fifteen or twenty percent, if memory serves.

Anyway, the 68000's far more regular instruction set and additional
registers mean that using a compiler doesn't incur nearly the penalty that
it does on the 6809. That said, the pre-Ultra C compiler doesn't generate
code nearly as good as that which the Ultra C compiler generates.

About OS-9/6809 vs OS-9/68000: not having a 64K limitation per process is a
big relief; things like deldir don't have to generate scripts that you feed
to a shell to execute. I'm sure there are lots of other differences
("MIcroware BASIC", BASIC09 for OS-9/68000, uses 32-bit INTEGER and
IEEE-754 floating point (I *think* double precision) for REAL, so raw data
files written in BASIC09 won't be correctly read if you just pull the
source code over to the 68xxx. You'll have to write a program to convert
such data), but it's been long enough that I can't bring it immediately
back to mind.

On Fri, Feb 5, 2016 at 9:34 PM, Joel Ewy <jcewy at swbell.net> wrote:

> On 12/30/2015 10:00 PM, Mark McDougall wrote:
>
>> On 31/12/2015 2:11 PM, Joel Ewy wrote:
>>
>> Just found my original GR2K disks.  They take up 4 1.44M floppies.
>>>
>>
>> Oh wow, that's a lot of code/data just for a Lode Runner clone.
>>
>>
> I'm just finishing up backing up GR2K.  I ran into some likely bad sectors
> on the last disk of the original set, but I raised the 'trys' from 7 to 28
> in the /d1 device descriptor, and appear to have retrieved everything
> successfully.
>
> Most of the data is soundtracks for the 30 levels of the game.
>
> JCE
>
> My C port is a direct re-implementation of the original Apple II 6502
>> code. It runs on the Neo Geo (68K @12MHz), albeit with hardware sprites.
>>
>> Would be nice to build under gcc for it... thanks for the info!
>>
>> Regards,
>>
>> I'm just finishing up backing up GR2K.  I ran into some likely bad
> sectors on the last disk of the original set, but I raised the 'trys' from
> 7 to 28 in the /d1 device descriptor, and appear to have retrieved
> everything successfully.
>
> Most of the data is soundtracks for the 30 levels of the game.
>
> JCE
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>