MAMEWorld Forums - EmuChat - Re: CPU subclassing for fun and profit

> > I didn't think someone could be that dumb, not to spawn off the T-11 core and
> modify
> > it to be a PDP-11 core. I would guess that Mame gets stupid submissions all the
> time.
>
> Oh, yes
>
> > So lets say I have to modify the T-11 source code into a PDP-11, the first thing to
> > do, is change all 5 files names into PDP11(something).X, correct? Then run a search
> > and replace on all t11_ to pdp11_ in the source code right? I know there is more to
> > it than that, but I found beginning small always the best way in any program. I
> guess
> > then you could add the extra 14 opcodes (plus different modes) which would never be
> > used in Galaxy Game since it uses 33 opcodes (and different modes) for a total of
> 986
> > total opcodes, all of which are available in the T-11.
>
> FAIR WARNING: the T-11 core is not "modern" so these instructions are no longer the
> ideal way to do things, but you work with what you have. Converting the T-11 to C++
> is far beyond the scope of this so we'll leave it in "old" form. That won't affect
> the acceptability of the submission.
>
I know, when I looked at the code, I could tell it wasn't C++, which I like better than C, most of the time.

> That would be one way to do it, yes. I'm not sure you'd actually want to split it
> completely from the T-11 given that when opcode bugs turn up they'll need to be fixed
> both places though.
>
I wasn't sure how the MAMEdevs wanted to do it.

> My suggestion would be to add a CPU type to the T-11's context with "PDP11" and
> "T-11" as possible values (and maybe more in the future - I believe there were
> multiple models of the PDP-11 with different CPUs, right?). You'll also need a second
> CPU_GET_INFO function for the PDP-11 which traps the CPU name and reset function and
> passes all others (default to the original handler. The CPU name would return the
> name for your new CPU and reset would redirect to a new CPU_RESET function which
> calls the existing one then overrides the CPU type to PDP-11 and makes whatever
> changes to the initial PC/SP/etc are necessary compared to a T-11 (if any). The
> original CPU_RESET function should of course set the CPU type to T-11.
>
I will try to get something done in the next couple days. The PDP-11 did have different CPUs, but they were mainly compatible, I think. DEC had many different models and a couple bus types over the years. I think Bill used a PDP-11/20 or PDP-11/15 as the computer to run Galaxy Game but I never asked which one it was, I forgot.

> In t11.h, copy the "DECLARE_LEGACY_CPU_DEVICE(T11, t11);" and change it to PDP11,
> pdp11 (the first is your CPU name that'll be used in drivers etc, the second is the
> name you used for CPU_GET_INFO). In the bottom of t11.c, copy the
> "DEFINE_LEGACY_CPU_DEVICE(T11, t11)" and do the same thing.
>
> Finally, add the new opcodes but only recognize them if the CPU mode is PDP11. (Don't
> forget to add them to the disassembler too - it's OK in this case if the disassembler
> just always knows the extra opcodes).
>
Some of the new opcodes, I not sure about even how to add them like SPL (Set Priority Level), like I said before none of the 14 commands for the PDP-11 compare to the T-11 are used in the game. If you did a Venn diagram of the PDP-11, T-11 and Galaxy Game, each circle would be fully enclosed in the last one. I am not even sure if the PDP-11/20 even had those 14 other commands, since the cheat sheet I have on the Opcodes says those commands are 'Not applicable to all PDP-11s', so I am even sure those Opcodes existed in 1971. I do know the ROL command in Bill's source has either a printer error or compiler error. The values for those commands are different, 61 vs 66, if I remember correctly.

> > One last thought, the PDF spent years on the website doing nothing, until someone
> who
> > was interested in history did something with it, I guess it will spend a few more
> > years before it added to MAME, since you said it will take you 18 months to look at
> > it. I guess a few more years before some real history is added to Mame.
>
> You have to realize, MAMEdevs are largely people who grew up in the 80s and early 90s
> on the classic 8 and 16-bit microcomputers. Minicomputers are quite alien to our
> experience, even moreso than the Apple II or Amiga would be to today's average 20
> year old. 8-byte bytes, byte-addressable memory, the high bit being leftmost, ASCII
> text, those conventions all go out the door when you start dealing with
> minicomputers. We'll get there eventually (as a certified Unix bigot I'd love to run
> the various early Bell Labs and BSD versions in MESS) but there's a substantial
> "everything you know is wrong" factor with those machines that doesn't exist with
> anything made after about 1976.

I was around in the 80s too, I would say most of the MAMEdevs are a little younger then I am. My first video game was Coleco Combat which I would love to emulated in MESS but it all circuits if I remember correctly, played that until it broke and my first real computer was a Commodore 64. I still have one of the controls from the Coleco Combat and I want to modify it to be usable as a Tank controller. I only Minicomputers and Mainframes I used was in College, IBM and a Vax. I know some Universities are still teaching programming on a Mainframe like a IBM MVS system, even though most everyone else has left those for the most part. Programming the MVS in assembly is strange, memory was in 4K segments, and if you wanted to jump out for the segment you were in, it was not simple a jump command, though having 14 or 16 registers was nice, I can't find my command card right now.