M.U.L.E. - For the Apple, is it Impossible?

[Great Hierophant]

Dan Bunten, the designer of M.U.L.E., claimed it would have been impossible to port the game to the Apple II (CGW, 12/84, p.40), despite that it was ported to the Commodore 64, the NES, the MSX, NEC PC-88, Sharp X1 and the IBM PC. The game was developed on the 6502-based Apple 400/800 machines. The Apple II uses the same CPU but is slower, but the C64 runs at the same speed. All Apple IIs can be upgraded to 64KB.

 

Fortunately, there is not a lot of music in MULE. There is one main song and a couple of little themes. Even with the Apple II's extremely limited sound capabilities, music and animation can be done at the same time (Prince of Persia is an example). The IBM PC has very similar sound hardware and sounds OK.

 

The Apple II has just enough hi-res artifact colors for 4-player MULE. Blue, orange, green and purple over white and black backgrounds should work just fine. The IBM PC port supports only 4-color CGA and PCjr. graphics and uses artifact color to support four differently colored players.

 

Control is slightly tricky. The Apple II gameport can support two joysticks or four paddles (analog) with but only has an odd number of buttons (3) to share between them. Most joysticks used two buttons and hogged the socket/port. Two players could use a joystick and two players could use the keyboard, just like with the C64 and PC.

 

Even though the Apple II does not have sprite graphics, this shouldn't be much of a problem when the game only needs to keep track of four objects at any one time. The IBM PC doesn't have sprite support either and the port does not suffer from any slowdown.

[Rybags]

I'd say yes, almost definitely requiring more than 48K though.

 

Not really a lot of moving objects so that should be no problem. Biggest moving objects are the colony and pirate ships that periodically appear. Other than that, the player and a mule is about all that moves most of the time.

 

Colour requirements - at least you want 4 unique colours which indicate each player's plots, ideally extra colours for each of river, mountain ranges, Wampus (dot), town outline, background. That makes 9 - realistically you could have shared for the river/wampus and town/mountains which knocks it down to 7.

 

Music is mostly when next to nothing else is going on so maybe some PWM trickery could be employed there.

[potatohead]

"Required Mockingboard" seems like a reasonable solution to good music. Some basic tones and such can happen with the speaker.

 

Because there isn't a ton of demanding on screen action, double high res delivers plenty of colors. Of course, that makes it //e or better...

 

High res does do 6 colors, though the artifacting is strong. Patterns and some basic pixel art work pretty well as additional colors. Having 6 to work with helps this out considerably. Clash would have to be managed.

Edited August 22, 2014 by potatohead

[The Usotsuki]

Pitfall 2 required a Mockingboard for BGM.

 

Works for me.

[Great Hierophant]

I never thought about the Mockingboard, but it would be a fair solution for music. You could borrow the music from the MSX port, since those computers also use an AY-3-891x.

 

I am wary of using double high res graphics, as I would imagine this port would have been done in 1983-1984, before DHR graphics were really supported. The river should be blue, and maybe a purplish tinge to the mountains, but I think the town needs to be black and white to avoid confusion with player parcels.

[Blackbag]

Interesting. Being an Apple II user growing up, I never played M.U.L.E. but it's classic status hasn't eluded my attention.

Has anyone created a commented disassembly of the game, or ported it to other platforms in a modern language? Would be helpful to see the game logic.

 

If colors are a concern and there's not a lot of demanding action, I'd agree that DHGR would be nice to use. The simultaneous 4-player control does seem to be a problem, though.

 

Rich

[JamesD]

Keep in mind that many games used mixes of dot patterns to represent other colors so you aren't really stuck with just 4.
It just has to be good enough to tell the objects apart.
The biggest challenge on the Apple isn't the graphics, it's going to be how players input.

MULE doesn't exactly require a lot of speed either because there won't be a lot of sprites moving on the screen at the same time.

[Great Hierophant]

Of course, high resolution graphics are generally preferred because the performance is better on 1MHz 6502s. If the game looks sufficiently clear with high resolution 6-color graphics on a TV screen through an RF modulator, it should be used.

 

As far as control is concerned, four way control plus button is only required on a player's development phase. Ideally, each player could have his turn at the keyboard. Then for the auction phase, each player only needs a two way control and no button. Four paddles would work here. Fortunately, the Apple II, II+ , IIe and IIgs has the four paddle input pins on their DIP-16 and IIe/IIgs DE-9 connector, so a passive adapter would work here. The Apple //c does not, so two players would need to share the keyboard for the auction phase.

 

Ideally, someone could design an expansion card that could handle four digital joystick inputs. That would require 20-24 bits of data to read, which could easily be implemented in TTL-logic.

[Keatah]

I played mule briefly for the 1st time. Possible on the Apple II? Absolutely.

[potatohead]

Comments in French can be found here:

 

http://bringerp.free.fr/RE/Mule/downloads.php5

 

(at least I think it's French. I may stuff a bunch of this through translate.google.com later to understand more)

 

Frankly, I like the idea of an add on card for more joystick inputs. Maybe it's time to put a PIA, along with some other thing, onto a card and get it out there. Honestly, I want to put one of those Parallax Prop Chips into an Apple. Been chipping away at it. The idea of taking other controller data seems like a good fit for that project.

 

Or... Maybe it's possible to do with the Super Serial? A lot of people have that one. SGI had a nice controller setup for their 3D visualization / fly through rooms. Typically, those ran on an Onyx machine. Expensive as hell! But, the joystick and buttons was serial, 9600 baud, and it was just fine. Could work for something like this, but would require somebody make a box.

 

Failing that, the paddles idea is a workable one.

Edited August 24, 2014 by potatohead

[Osgeld]

you dont really need a card you could use the existing analog lines and step them, programming your game to interpret the different steps as different digital controllers

 

for instance if you express your joystick range for 1 axis as 0-255, using a divide by 32 approach

 

0 = no input

1-32 could be player 1 left

33-64 could be player 1 right

65-96 could be player 2 left

97-128 could be player 2 right

 

keep going and before you know it you have left right control for 4 digital sticks using ONLY 1 analog axis, use a divide by 16, and you could have 4 directions * 4 joysticks + using the second axis 4 buttons * 4 joysticks, and you could do it in less than a paragraph of applesoft within 30 min

 

This would allow you to not go though the expense and development of a internal card, and would be compatible with the apple IIc series, along with the LC2 apple II card (not sure how GS joysticks are implemented, but I would assume they are the same as the other 2 latest models) via an external adapter box.

 

wired correctly one could do this totally with a resistor dac, but thats a lot of resistors and wires, and you would run in to the dick move of your jerk buddy holding a direction or button and effectively locking out all the controls while its not his turn

 

Using a micro (fan of atmel myself) and a digital potentiometer, allows you to avoid that + with the software interface you could easily talk to cheap and easily available off the shelf controllers such as NES or Genesis without mods to the controllers. Even a basic arduino and a slow arse SPI digital pot would be more than fast enough to multiplex the controllers seamlessly for humon interface, hell I used one to draw low resolution graphics on my oscilloscope.

 

 

 

 

 

[Rybags]

I'm not sure that getting MULE going on A2 warrants creating a new controller interface/standard.

 

The ability to run 3 paddles is sufficient. On the Atari 800 you can have 3 players by paddle and 1 by joystick.

At least 1 joystick is mandatory there as it is required (shared in some cases) for each player to do their development phase.

 

On A2 you should be able to use keyboard as replacement for joystick, so 3 paddles + kb would be sufficient.

[Osgeld]

I dont think so either, its a slow turn based game, take your turn at the keyboard and get off your arse, just like back in the day lol

 

but just offering my 2 cents, if its required everyone have their own controller an external box is much preferred to designing a whole new internal card to reinvent the wheel

[potatohead]

I agree. Was just musing about things really. No matter how input was done, M.U.L.E. seems like a great title for the Apple.

[carlsson]

The land selection and auctions are just about the only times all four players need to act at the same time. Previously I've read something about the problem of pushing multiple keys on the Apple ][ and have them read out the respective values, but I don't know if it is a misunderstanding, hoax or just as complex as on all other computers with keyboard matrices.

 

If it wasn't for IBM pushing the PCjr and specifically ordering a port of M.U.L.E, it probably never would have come to development. Dunno about the NEC and MSX2 ports, whether they're entirely licensed or not. The MSX2 version supposedly is rather hampered compared to the Atari/C64 and even NES versions.

 

For that matter, I haven't seen anything about M.U.L.E. for the CoCo series neither, which may have been a bit more affordable and gaming-oriented than the Apple ][, now if Electronic Arts and Ozark had seen possibilities for the game on additional platforms.

 

Regarding sound and music, I realize that Archon exists for the Apple and it has almost as much music and sounds as M.U.L.E. has, so for that matter it'd almost be a no brainer. Inputs and possibly colour resolution might be tougher nuts to crack, albeit not impossible.

[JamesD]

The Apple keyboard isn't directly read by the CPU and the keyboard chip sends keys that are pressed but it doesn't say when they are released like an IBM keyboard does so you can't tell when keys are held down together.

At least that's what I seem to remember, I could be wrong.

 

The CoCo and Tandy in general got no respect from most major software companies.

Edited August 26, 2014 by JamesD

[mjmahon]

The //e, IIc, and IIgs do have key rollover and "any key down" sensing, so if multiple keys are pressed and held, it's possible to tell when they were pressed and when the last one was released.

[Great Hierophant]

The Apple IIe has an AUX keyboard connector on the motherboard, typically used for a numeric keypad. Even the Platinum IIe has the connector, even though the machine has a built-in keypad. With a small PIC, you could easily have a joystick send scancodes as directional and button presses, and four paddles could handle the rest. Or you could just have the adapter accept four joysticks.

[mjmahon]

Note that any keyboard adapter will allow "users" to interfere with each other's "keystrokes".

 

Each axis of a digital joystick has three permitted states, usually requiring two bits. Each button is another bit. Therefore, four single-axis joysticks with one button each require 12 independent bits (since they can all be operated asynchronously).

 

An analog joystick joystick input can only be read reliably to within 1% or so--allowing a maximum of 6 independent bits to be read. (And, since any switch can be operated at any time, a sample-and-hold would be needed to guarantee no false reads as a result of a switch changing state in the middle of a read.)

 

So analog sensing is out unless the inputs won't change during the read, and can reliably provide only about 6 independent bits of input per read.

 

If you really need a lot of parallel inputs, use a general-purpose parallel port card with an external joystick adapter.

[cybernesto]

Someone could try to clone the Sirius Joyport. There are already some games that support multiple inputs with it. If 4 Paddles and keyboard control are enough this should work. Unfortunately it is not compatible with the IIc

[carlsson]

To be honest, I'm not entirely sure if the two defined keysets in M.U.L.E. on the C64 are guaranteed not interfer with joystick port #1, but I suppose they won't. Also I don't know if the PC/PCjr, NEC, MSX2 or for that matter the NES version of the game support four players. I know there are four player adapters for the NES, perhaps the game supports one of those?

 

With that said, it might have been feasible to release a version of the game that only supported two human players, although of course it is more fun if you can skip the computer players entirely.

[Rybags]

On C64 with some programming effort you can mask key vs joystick interference to a degree, especially keys misinterpreted as stick directions.

But whatever input method gets used here... you definitely don't want any interference going on.

 

That aside though, it's a minor technical issue vs actually getting the game itself ported over.

[Great Hierophant]

Sorry for reviving an old post, but this card neatly solves the four joystick issue for the Apple II (except the //c) : http://lukazi.blogspot.com.au/search?q=4play&max-results=20&by-date=true

[Keatah]

Don't apologize for reopening an old thread. This is a classic computing forum for discussion of old things. So it fits right in. And if anyone complains they're likely one of those "self-appointed moderators" trying to feel important or something. Pay no attention.

[zzip]

I think "It's not possible" really means "We're not interested in doing it" MULE could be done, with some tradeoffs. The other versions had tradeoffs. Maybe you couldn't do 4 player, but the XL/XE and C64 couldn't do 4-player either. The XL/XE could do three players if you used paddles. You could mix joystick and keyboard on apple.

 

The Wizardry guys said the same thing when asked about porting Wizardry to Atari. "Not possible" Looking at that games graphics, I see nothing the Atari couldn't do. Supposedly the problem was the disk drive. Again, I'm sure tradeoffs could be made.