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

[Great Hierophant]

The main Wizardry program would probably have required two disks on the Atari as opposed to one on the Apple.

 

The C64 could do four player MULE. Only one joystick was required for the development phase, but two joysticks were used during the auction phase along with two sets of keys on the keyboard.

[zzip]

The main Wizardry program would probably have required two disks on the Atari as opposed to one on the Apple.

Yeah but many Atari RPGs required 4 or 5, so no big deal there! lol

 

The C64 could do four player MULE. Only one joystick was required for the development phase, but two joysticks were used during the auction phase along with two sets of keys on the keyboard.

Depends. Can the C64 interpret two separate keypresses simultaneously? Lots of the computers of that era couldn't handle that.

[JamesD]

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.

I think most of the people capable of doing it are just more interested in other projects.

MULE is fun but it's definitely not pushing the envelope of what is possible.

 

Wizardy was a combination of things. Not having UCSD Pascal, a fast disk drive, or even expanded RAM to preload code and data to eliminate delays.

Fast loaders, and expanded RAM are common now, but in 1981 when Wizardry came out, that wasn't the case.

And there still isn't a version of UCSD for the Atari. That's mostly due to UCSD's creators and Atari though. Neither one pursued it.

*edit*

Come to think if it, by the time Atari came out with a 64K model in 1983, UCSD Pascal might have been sold to a private company.

64K was one of the requirements of running UCSD Pascal.

Edited May 16, 2017 by JamesD

[zzip]

Wizardy was a combination of things. Not having UCSD Pascal, a fast disk drive, or even expanded RAM to preload code and data to eliminate delays.

Fast loaders, and expanded RAM are common now, but in 1981 when Wizardry came out, that wasn't the case.

And there still isn't a version of UCSD for the Atari. That's mostly due to UCSD's creators and Atari though. Neither one pursued it.

Oh yes, thanks for reminding me! Didn't UCSD have a virtual memory system in its runtime? And that was the cause of needing a fast disk drive?

 

So porting Wizardry would have meant rewriting it in a different language. I would still maintain Atari could handle the game itself, if rewritten in Action! or something. But again it's an effort they weren't interested in, so they just said "not possible"

Edited May 16, 2017 by zzip

[Great Hierophant]

I think most of the people capable of doing it are just more interested in other projects.

MULE is fun but it's definitely not pushing the envelope of what is possible.

 

Wizardy was a combination of things. Not having UCSD Pascal, a fast disk drive, or even expanded RAM to preload code and data to eliminate delays.

Fast loaders, and expanded RAM are common now, but in 1981 when Wizardry came out, that wasn't the case.

And there still isn't a version of UCSD for the Atari. That's mostly due to UCSD's creators and Atari though. Neither one pursued it.

Wizardry was ported to the IBM PC, C64, NES and many other computer systems. I doubt that all of them had a Pascal runtime available to compile code suitable for each system.

[JamesD]

Stop focusing on the hardware not possible and focus on the software not possible for them.

Wizardy was written by a couple college students just writing it for fun.
The guy doing the coding wasn't even a CS major if I remember right.
Do you really think they could have created Wizardry in assembly?

 

Action didn't come out until 1983. These guys wrote it somewhere in the 1979-80 time frame.
Even assemblers were pretty primitive at that time.

There wasn't even a Tiny Pascal compiler for the Atari.

The IBM version probably used Turbo Pascal. RAM and disk drive speed wasn't an issue.
I do think there was a version of UCSD Pascal for the IBM though. I'm not sure what year it came out though.

The C64 version came out in 1985. With a potential market of several million machines, it pays to hire some guys to convert it to assembly.
All the design work was basically done, so they didn't have to work that out at all.

The NES uses a cart and tile based graphics system that doesn't have to worry about loading from a disk drive or how much RAM there is.

Wizardry didn't get ported to the Atari because the Atari didn't have the market of the other machines.

FWIW, there was a Pascal compiler for the C64 called G-Pascal that might have been able to do the job with a little work 1983.

UCSD Pascal could have been ported to the Atari, it just wasn't, and by the time Wizardry was being ported to other machines,

people saw the Atari as a small market in comparison to the IBM, C64 and NES.

Edited May 16, 2017 by JamesD

[Bill Loguidice]

The C-64 port of the Wizardry trilogy didn't release until 1987 (it even got Wizardry V, but not IV). By then the Atari 8-bit disk market was probably deemed not worth the porting effort.

[zzip]

Stop focusing on the hardware not possible and focus on the software not possible for them.

Wizardy was written by a couple college students just writing it for fun.

The guy doing the coding wasn't even a CS major if I remember right.

Do you really think they could have created Wizardry in assembly?

 

Action didn't come out until 1983. These guys wrote it somewhere in the 1979-80 time frame.

Even assemblers were pretty primitive at that time.

There wasn't even a Tiny Pascal compiler for the Atari.

When I read their quote about "not possible to port to Atari" it was definitely post 1983 because I didn't read game/computer mags until 83.

 

 

Wizardry didn't get ported to the Atari because the Atari didn't have the market of the other machines.

 

FWIW, there was a Pascal compiler for the C64 called G-Pascal that might have been able to do the job with a little work 1983.

UCSD Pascal could have been ported to the Atari, it just wasn't, and by the time Wizardry was being ported to other machines,

people saw the Atari as a small market in comparison to the IBM, C64 and NES.

Which I'm sure is the correct answer. I'm just pointing out that devs were saying "Not possible" when they really meant "too much work/ not enough market/ or we just flat aren't interested"

[Bill Loguidice]

Which I'm sure is the correct answer. I'm just pointing out that devs were saying "Not possible" when they really meant "too much work/ not enough market/ or we just flat aren't interested"

 

I agree, but I believe Sir-Tech at the time also had a general "not possible" attitude, being beholden to their Pascal-based dev system for way too long (much like Infocom with their dev environment). To prove the idea wrong, Silvern Castle was made in 1988 for the Apple II in AppleSoft Basic: http://finkjsc.a2hq.com/silverncastle/

[JamesD]

This article claims they created port of Wizardry by porting UCSD Pascal ports.
That might actually be easier than converting the game to assembly.

http://gaming.wikia.com/wiki/Wizardry

[MarkO]

Wizardry was ported to the IBM PC, C64, NES and many other computer systems. I doubt that all of them had a Pascal runtime available to compile code suitable for each system.

Actually, UCSD P-System was available for the IBM-PC at the original Ship Date... It was the Third OS available for the IBM-PC, after CP/M-86 and PC-DOS v1.00.

 

( Remember that PC-DOS was shipped with the Machine and Included in the Cost, where as CP/M-86 and the UCSD P-System were an extra cost.. Look which one Won Out... )

 

MarkO

Edited May 18, 2017 by MarkO

[carlsson]

Can the C64 interpret two separate keypresses simultaneously? Lots of the computers of that era couldn't handle that.

I haven't played M.U.L.E. with four players a lot on either the Atari 800 or the C64, but I strongly think you can push multiple buttons on the C64 and read out their values individually. Some music programs allowed you to play three note chords on the keyboard that way, and it would work rather well.

 

If you are curious, there are some code examples and discussion here:

http://codebase64.org/doku.php?id=base:reading_the_keyboard

[Great Hierophant]

Thought I would bump this thread with this four player digital joystick adapter that is easy to build : http://lukazi.blogspot.com/2016/04/apple-ii-4play-joystick-card.html

 

Also, I'm sure a Mockingboard could do justice to the music of M.U.L.E.

[thorr]

I didn't read the entire thread and I am not familiar with M.U.L.E. but the joystick adapter caught my attention. I also did not read the article about the joystick adapter. In my complete ignorance, my opinion is that a special joystick adapter could be created for any Apple II including the Apple IIc that allows four Atari style joysticks. It would just require that the software knows about it and is programmed for it. The idea is that the Apple II supports analog X, analog Y and two buttons in the joystick port. The analog portion has a range from 0 to 255 for X and for Y. This could be divided up using resistors and the Atari joysticks buttons and directions. It would just require calibration before using it. So for example, Atari Joystick 1 would have 8 directions and a button for a total of 9 values. Multiply this by two and you have 18 values that can be divided up on the X axis. The other two Atari Joysticks can use the Y axis. 256 divided by 18 = 14 ohms of separation required between each direction or button. That would be the trickiest part, but it could be created using small potentiometers that can be adjusted on the circuit board so each one registers correctly in its range by the Apple II. While this is probably possible, I doubt anyone would go through the trouble to create this and program this just so they can have four joysticks and play M.U.L.E. on the Apple II.

[thorr]

Just an edit to the above, there would be 14 values (not ohms) of separation between each direction or button. So for example, 0 to 13 would be up, 14 to 27 would be down, etc. You would then calibrate the potentiometers to fall in the middle of each range and program M.U.L.E. to accept values between 0 and 13 for up, etc.

 

Also, I didn't account for having nothing pressed on the joystick. This could be handled by dividing up the range further, so it would be 10 positions for each joystick instead of 9. So 20 positions to divide up for two joysticks on X and another 20 on Y. 256 divided by 20 is 12.8 so effectively 0 to 11 would be no direction or button, 12-23, would be down, etc.

 

Thinking out loud as I type, the buttons are another issue because a button can be pressed while a direction is going at the same time. To handle this, the buttons need to be used, but there are only two buttons on the Apple II joystick and we would need four. Another way to handle it would be to divide it all in half again and have the lower half of the 256 range be without the button pressed and the upper half be with the button pressed.

 

Now another problem I just thought of is the two joysticks on each axis could be used at the same time. Again, the ranges could be divided up to have 0-3 is nothing on both joysticks, 4-6 is up with no button on the first joystick, 7-9 is up with no button on the second joystick, 10-12 is up with no button on both joysticks, 13-15 is up with button on the first joystick, etc. I don't feel like doing the math, but this is becoming very precise and there are up to 512 values plus two buttons from the Apple II side that could be used to interpret all the combinations that could happen on the four Atari joysticks. This would require a way to very exactly inject ohm values that would be read by the Apple II and I am not sure if this would be possible with high quality electronics or not. Again, it is all theory and probably possible, and totally not worth the effort.

Edited September 30, 2017 by thorr

[Great Hierophant]

The thing I like about the 4joy adapter is that the thing is ingenuously simple by Apple IIe standards. It just puts a single digital joystick at a single memory location, dictated by the location of the card. All you need to do is to initiate a read of that location and the latch places the value on the bus. The value represents the position of the joystick plus the button(s). Plus the memory locations for each of the four cards are sequential, so the whole reading would take no time at all.

[thorr]

Except, I have an Apple IIc so I am biased against a card solution. :-)

 

A much simpler solution than my previous suggestion of using the joystick port would be to use the modem port. Set it to 9600 Baud and send input that way depending on the position of the four joysticks. You could have 10 joysticks if you wanted and it would work great. In my college days, I actually wired up two Motorola 6809 CPU's to talk to each other via a null serial modem connection using nothing but chips and lots of wires. It was very easy to do.

 

For four joysticks, you could send one byte for each joystick value in a continuous loop of four bytes. The byte would use binary. You could implement a one or two button joystick. The left two bits would be 00, 01, 10, or 11 to say which of the four joysticks that byte was for. The next two bits would be used for up to a two button joystick (00,01,10,11) for the possible button presses, leaving four bits for the directions which is enough for 16 directions of which you only need 9 including a centered joystick and the four main directions and four diagonals. So it would be very easy to implement four one-button or two-button digital joysticks.

Edited September 30, 2017 by thorr

[Eric Badger]

Is the source code for MULE available?  Might be fun to port.

 

 

[carlsson]

There was someone (in Germany?) who supposedly owned the one and only copy of the source code. I don't know if it has been returned to Ozark, or for that matter duplicated and published. They seem to be quite active on protecting the trademark. For the 40th anniversary in late May there was a very nice feature where all the surviving crew members had given their input on the development process.

https://www.carpeludum.com/m-u-l-e-online/

[MarkO]

On 8/5/2023 at 10:06 AM, Eric Badger said:

Is the source code for MULE available?  Might be fun to port.

 

 

Potatohead posted this link back in 2014:

 

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

 

Looks like the Disassembly is still there...

 

MarkO

[potatohead]

On 9/29/2017 at 9:56 PM, thorr said:

much simpler solution than my previous suggestion of using the joystick port would be to use the modem port. Set it to 9600 Baud and send input that way depending on the position of the four joysticks.

In the 90's I was doing a lot with SGI computers and serial was how they did many distinctive controllers.   I was surprised to see 9600 baud serial as the default for most of these devices.  

 

9600 baud is about 1kbyte / second, give or take.  If you want a response every frame, you get about 16 bytes, again give or take.

 

This is more than enough to do a handful of analog joysticks, with buttons.

 

There were a couple ways it was done:

 

One was a simple, full read of everything, looped into RAM over and over, and the other was a call and response, where you send over an identifier and get values back, and that seemed to favor the more complex interfaces.

 

Serial gaming controllers could work pretty great, given a system has fairly low overhead serial comms.  The experiences I had were great.

 

Edit:  LOL, saw my older post where I basically said all this.

 

Ah well.  Carry on peeps! 

Edited September 2, 2023 by potatohead

[MarkO]

41 minutes ago, potatohead said:

<< BIG SNIP >>

 

Edit:  LOL, saw my older post where I basically said all this.

 

Ah well.  Carry on peeps! 

I've found myself doing that here on AtariAge too...   After a few years, it all seems to Blur Together...

 

MarkO

[carlsson]

On 9/1/2023 at 6:50 AM, MarkO said:

Looks like the Disassembly is still there...

Yeah, it is better than nothing. On the other hand, we don't know how much logic was explained in the original source code anyway, or if they used separate documentation for that and the coding was just straight ahead assembly language. Now I'm not sure exactly how much use you would have of the source code vs a disassembly if you would attempt to port a game, as quite a bit would need to be rewritten even if the CPU is the same. As far as I understand, Ozark did quite a lot of work to convert the A8 version to C64, introducing some new bugs/behaviors while possibly ironing out some others. There was a reason why the A8 version came out in May and the C64 version in November (?) the same year. Sure, the C64 itself had only been on the market for 8-9 months at the time of the original EA launch so perhaps not practically possible for the Ozark, or for that matter Free Fall etc development studios, to have C64 versions already but I would have expected 2 more months rather than 6-7 months for the original development studio to adapt their game.