Mr Do! ?

edited August 2010 in New game ideas
Not exactly a new idea (at least twenty-seven years old now :-o), but how about a port of Mr Do! to the Spectrum? There was never an official one, even though they appeared for the BBC, the Amstrad, the C64 and even the Tandy, and the unofficial ones weren't much cop at all, at least until Farmer Jack in Harvest Havoc came along in 2006. That's a great game, but it still lacks some of the complexities that make Mr Do! so great.

The thing is, since Mr Do! is available for download (and use with MAME), and is written for the Z80 CPU, then surely it would be possible for someone with enough talent (i.e. not me) to disassemble the code to learn how everything works, including the monsters' AI, and then produce a version for the Spectrum?

This would be fantastic beyond words. Mr Do! is still my favourite ever arcade game, and it's a tragedy that it was never ported to the Spectrum. We got so many great (and not so great) ports of other games, but not this very playable and surprising deep classic.

If anyone's interested, you can download the game code from:

http://www.romnation.net/srv/roms/23965/mame/Mr-Do-Taito.html

If anyone has the time and the ability, then please consider this. I'm sure it would go down very well in the Spectrum community, and it would fill a major gap in the Spectrum's line up of arcade ports.
Post edited by ewgf on
Thanked by 1Mark R. Jones

Comments

  • fogfog
    edited July 2010
    someone did the same with bezerk , ported it to 64..ermm

    depends what other custom chips were used? for say gfx and sound.. yep you get the logic of the game

    Joffa's source code for his gb version is around.. that "might" be easier for someone perhaps
  • edited July 2010
    I think I read somewhere that there were no custom chips, and just a mono speaker, in the Mr Do! arcade machine. No doubt there's sufficient documentation available, otherwise MAME wouldn't be possible.

    I hope someone takes up this challenge. It's not right that the C64 owners get to play a version of this great game (or at least to look at the cassette and wonder how to load it), whilst our beloved Speccy lacks a version.

    No Mr Do!, but a zillion crappy Dizzy games. Just my luck :cry:



    [If any Dizzy fan wants to produce a version of Mr Do! for the Speccy, then I promise not to slag off that revolting egg for a whole week!]
  • fogfog
    edited July 2010
    the problem is the speccy screen size, look at bob's game and compare the screen layout. hopefully you'll see what i'm getting at


    of course you could make the characters small like say gold digger etc..

    the apple sprite , is what... 4 chars? 2x2 ? so it's either that or 1 char wide/high and obviously no detail.

    have a look at mr. do vs unicorns aka mr do's castle , see what I'm getting at

    c64..



    msx..


    the problem is the vertical playing area.... or lack of.

    I know I'm not ya fav. person in the world now, but speccy artists will confirm my thoughts hopefully.
  • edited July 2010
    Well, if a CPC coder can convert a Speccy game (3D Deathstrike or something like it) to the CPC using Speccy code, then someone can do this.
  • edited July 2010
    Well I counted and the screen is equal to 30 horizontal rows on the spectrum, which if I remember correctly makes the spectrum 8 lines too short to do it.

    That's for height - in width it only takes up 24 blocks so there's plenty of room to spare.

    Too bad the two top and two lower information areas (score, etc) can't be switched to be printed vertically to gain some more room for the height because even if you removed the information areas at the top and bottom and printed them on the sides that's only 4 rows you gain, which would still make the spectrum 4 rows too short to do it.

    It could work if the game were changed up so that the screen would scroll vertically if you need to go down more and then go back up so you can have all 30 rows and do exact level conversions.

    Things seem to fall within 8*8 pixel blocks so that works out well.

    Animated character sprites could have decent detail if they move 8 pixels at a time.

    If smooth animation was wanted then the sprites would have to be one color.


    fog wrote: »
    the problem is the speccy screen size, look at bob's game and compare the screen layout. hopefully you'll see what i'm getting at


    of course you could make the characters small like say gold digger etc..

    the apple sprite , is what... 4 chars? 2x2 ? so it's either that or 1 char wide/high and obviously no detail.

    have a look at mr. do vs unicorns aka mr do's castle , see what I'm getting at

    c64..

    msx..

    the problem is the vertical playing area.... or lack of.

    I know I'm not ya fav. person in the world now, but speccy artists will confirm my thoughts hopefully.
  • edited July 2010
    mrdo.png
  • edited July 2010
    Silly suggestion, but I've heard it was done in the past for some console game - make the game so that you can turn the TV on it's side and play it that way. Can't you get PC monitors that flip round for word processing etc? Then it could be done on emulators, you just need the right equipment. Or, you could bend your head 90 degrees :D
  • edited July 2010
    Sadako wrote: »
    Too bad the two top and two lower information areas (score, etc) can't be switched to be printed vertically to gain some more room for the height because even if you removed the information areas at the top and bottom and printed them on the sides that's only 4 rows you gain, which would still make the spectrum 4 rows too short to do it.

    If you gain 4 rows, the spectrum would only be 2 rows too short, not 4. If you start showing the second row, you'd lose the upper half of the first line and the lower half of the last line, but won't miss anything of what's happening on screen, including position of all enemies, etc... looks like a nice compromise to me.
  • edited July 2010
    ewgf wrote: »
    I think I read somewhere that there were no custom chips, and just a mono speaker, in the Mr Do! arcade machine. No doubt there's sufficient documentation available, otherwise MAME wouldn't be possible.

    I currently have 3 (!!) Mr.Do! boards at home for a project we were working on some time ago. The idea was to make a brand new game based on that board specs that would run on the actual hardware.

    I don't quite remember much of the board details right now, but I could have a look at our docs if anyone's curious. There's also a detailed board diagram somewhere on the net that helped us figure out some of the details that were wrong or poorly implemented in the mame source.

    One thing I do know for sure is that sound is generated by two SN76489 chips, which deliver a whooping total of eight channels.

    The video display hardware was really powerful for its time: two 240x192 independent playfields with hardware scrolling plus colour sprites. The colour palette has 256 colours out of 4096 (12 bits RGB). These 256 colours are algorithmically generated by the hardware from a rom based CLUT which is only 64 bytes long. Figuring this algorithm out turned out to be the toughest part.. it really is a clever, crazy bit of code. Mame sources helped a bit there but we eventually found out mame's algorithm was wrong (we finally got it right and reported the new version to the authors).

    All in all this board is an amazing piece of hardware for its time, even though you could never tell so given Mr.Do!'s simple visuals. I'm sure a pretty decent speccy port could be done. Not quite my kind of game but I'd be delighted to see it happen.
  • edited July 2010
    Sadako wrote: »
    mrdo.png

    Sadako, your links have been removed, are those graphics from an in-progress Spectrum port, or what? Is there a site you can link to, to show us more, please?
  • edited July 2010
    Metalbrain wrote: »
    If you gain 4 rows, the spectrum would only be 2 rows too short, not 4. If you start showing the second row, you'd lose the upper half of the first line and the lower half of the last line, but won't miss anything of what's happening on screen, including position of all enemies, etc... looks like a nice compromise to me.

    yes that's right. but if the graphics are going to stay equal in dimension then the levels would still have to be altered and certain things positioned slightly differently. if not then the cherries or whatever all the way at the top or bottom you'd have to cut them in half or move them up or down 1 character space and if there happened to be another object above or below you'd have to reposition those too and adjust. Whether you make sprites less than 16*16 to get accurate level recreations or you don't and sacrifice the top or bottom of the screen there will be compromise either way.
  • edited July 2010
    ewgf wrote: »
    Sadako, your links have been removed, are those graphics from an in-progress Spectrum port, or what? Is there a site you can link to, to show us more, please?

    I don't know what you mean by links have been removed.

    I just whipped that up after I read your post and uploaded to image shack and posted it here.
  • fogfog
    edited July 2010
    it boils down to the screen res / play area.. errm the other thing I thought, was could you draw only using 1.5 chars ? but because of that maybe easier to have the colour mono. some people do it with fonts, so the lettering is smaller / fits on screen

    the idea with rotating the screen , I saw done with a c64 shoot em up that zzap gave away on a tape.
  • edited August 2010
    Most arcade games from around 1981 used 16x16 pixel sprites. Mr Do! used 12x12 pixel characters within a 16x16 pixel game grid.

    The tightest corners in Pacman were 24 pixels between turns - 16 for the width of the sprites, plus 8 for the width of the walls. I believe this layout is better for a Spectrum conversion of Mr. Do, as it would be working with the screen attributes of the ULA.

    The game maps in the arcade version are 13 units tall, 12 units wide. If the width is reduced to 11 units, this equals 32 character squares, avoiding the need for horizontal scrolling. I'm undecided as to whether the screen colours should be BRIGHT 0, to make the border invisible.

    The game screen will still need to scroll vertically. This requires a buffer of 38*32 bytes, storing a copy of the screen attributes data, except that the ink colour is made the same as the paper colour, to avoid the need to zero out any unwanted pixel bytes. There's enough time to copy it while the ULA is drawing the lower border.

    I believe I can even get the two-channel arcade music on a 16K Spectrum. Custom sound routines are never normally placed below below address 32768, because the RAM contention messes them up.

    Z80 instructions that use just one M-cycle (the single-byte ones, with register operands) take 4 T-states in uncontended time, 8 T-states when contended. The RAM contention pattern on a 16K / 48K Spectrum is 128T (16*8 ) contended, 96T (24*4) uncontended. Therefore a loop containing 40 (16+24) 4T instructions will take one ULA scan-line precisely. A program can poll IN 0xFF to detect the appropriate moment, then run 192 iterations of the sound routine. Better still, 4 T-state instructions aren't affected by I-register contention, so it can use interrupt mode 2 in 16K.

    I didn't want to mention this right now. I have about seven games in various stages of development right now, including this one, with literally thousands of sheets of paper covered in notes. This way, whenever I get stuck on one program, I can work on another one until I solve the first problem. Unfortunately, working continuously at this for several months without a break is significantly affecting my sanity.
  • edited August 2010
    ajmoss wrote: »
    The game maps in the arcade version are 13 units tall, 12 units wide.

    we can use TV/monitor in vertical position:

    tv-vertical.jpg

    32x vertical attributes
    24x horizontal attributes
  • edited August 2010
    velesoft wrote: »
    we can use TV/monitor in vertical position:

    32x vertical attributes
    24x horizontal attributes
    Then the falling apples will fall horizontally, which would be very confusing.

    Besides, the attribute-aligned method I'll be using requires 24x24 pixels per square: it won't work with 12x12 pixel sprites inside a 16x16 pixel square.
  • edited August 2010
    ajmoss wrote: »
    Most arcade games from around 1981 used 16x16 pixel sprites. Mr Do! used 12x12 pixel characters within a 16x16 pixel game grid.

    The tightest corners in Pacman were 24 pixels between turns - 16 for the width of the sprites, plus 8 for the width of the walls. I believe this layout is better for a Spectrum conversion of Mr. Do, as it would be working with the screen attributes of the ULA.

    The game maps in the arcade version are 13 units tall, 12 units wide. If the width is reduced to 11 units, this equals 32 character squares, avoiding the need for horizontal scrolling. I'm undecided as to whether the screen colours should be BRIGHT 0, to make the border invisible.

    The game screen will still need to scroll vertically. This requires a buffer of 38*32 bytes, storing a copy of the screen attributes data, except that the ink colour is made the same as the paper colour, to avoid the need to zero out any unwanted pixel bytes. There's enough time to copy it while the ULA is drawing the lower border.

    I believe I can even get the two-channel arcade music on a 16K Spectrum. Custom sound routines are never normally placed below below address 32768, because the RAM contention messes them up.

    Z80 instructions that use just one M-cycle (the single-byte ones, with register operands) take 4 T-states in uncontended time, 8 T-states when contended. The RAM contention pattern on a 16K / 48K Spectrum is 128T (16*8 ) contended, 96T (24*4) uncontended. Therefore a loop containing 40 (16+24) 4T instructions will take one ULA scan-line precisely. A program can poll IN 0xFF to detect the appropriate moment, then run 192 iterations of the sound routine. Better still, 4 T-state instructions aren't affected by I-register contention, so it can use interrupt mode 2 in 16K.

    I didn't want to mention this right now. I have about seven games in various stages of development right now, including this one, with literally thousands of sheets of paper covered in notes. This way, whenever I get stuck on one program, I can work on another one until I solve the first problem. Unfortunately, working continuously at this for several months without a break is significantly affecting my sanity.

    Wow! This is great news (and at such an otherwise terrible time for the Spectrum forums), I'd love for someone to make a real Mr Do! type game for the Spectrum. Do you have anything that you can show us of the game, yet?

    Please keep us informed of your progress, though of course remember to take a well earned break every now and then - you need a bit of sanity (not much, though) to cope with everyday life.







    velesoft wrote: »
    we can use TV/monitor in vertical position:



    32x vertical attributes
    24x horizontal attributes


    Erm, yep. But it's just the slightest bit impractical, unless you're using either a rotatable LCD monitor, or an I-Pad.
  • edited August 2010
    ewgf wrote: »
    Wow! This is great news (and at such an otherwise terrible time for the Spectrum forums), I'd love for someone to make a real Mr Do! type game for the Spectrum. Do you have anything that you can show us of the game, yet?

    It's all described on paper at the moment. I hope I can produce a playable alpha version by the end of this month, and finish it in time to be considered for this year's Speccy Tour.
  • edited August 2010
    ajmoss wrote: »
    It's all described on paper at the moment. I hope I can produce a playable alpha version by the end of this month, and finish it in time to be considered for this year's Speccy Tour.

    Oh please please please do. Mr Do! on the Speccy would be one of my dreams come true. Bung in Lily Allen (minus the attitude), a total ban of all talentless morons from TV, and a sugar substitute that tastes just like sugar and has no after taste (so I can drink real Irn Bru and real Pepsi again, sort of), and my life would be complete :-)

    Really looking forward to this - please keep us updated on it's progress.
Sign In or Register to comment.