Brainstorming: M.U.L.E. 2600

[Cybergoth]

Hi there!

 

So this weeks question is: "How about doing M.U.L.E. for the 2600?"

 

This is probably the one title I know the least about. I never really played it at all.

So I've been researching material regarding it, here's what I have in hands so far:

 

Lemon64 link for the C64 version:

http://www.lemon64.com/games/details.php?ID=1558

 

Atarimania link for the A8 version:

http://www.atarimania.com/detail_soft.php?...VERSION_ID=3589

 

A youtube video of the C64 version:

 

I'm no expert on this game, so I need help! (Is it actually a game? )

 

Are there any M.U.L.E. experts here? Is it doable on the 2600? What are the essential bits of the game? What would be difficult to replicate on the 2600? How many different screens does it have? How would it look like?

 

Greetings,

Manuel

[Big Player]

Of course MULE is a game. It's a strategy game. And wow the C64 sound sucks compared to the Atari version.

 

I'm not an expert on the game. About a year ago, I got the 5200 conversion that Bryan Edwaard made.

 

I'm assuming you would use lots of extra RAM/ROM as in Andrew's Not Boulder Dash project.

 

The graphics aren't that complex--for the Atari 8-bits. I've read that Dan/Dani Bunten wished the graphics could have been nicer but there were too many processes going on during the game.

 

You have a 9 X 5 grid. Here would be your worse case scenario for the display. You would need to move at least one sprite around that map. If you only used one sprite you would have to find a way to display if the player were dragging a MULE or not.

 

Edit: Corrected name.

Edited June 23, 2023 by Big Player

[Cybergoth]

You have a 9 X 5 grid. Here would be your worse case scenario for the display. You would need to move at least one sprite around that map.

 

That looks a bit like a good application for supercats Ruby Runner display engine. I think it even is 9 X 8 already.

 

It's hard to tell how much information this screen holds.

If I'm not missing anything, each cell seems to require:

 

• A General Type (How many are there?)
  
• Background info (River/Rocks - How many?)
  
• 1-8 dots. (Stock?)
  
• 1-4 dots. (Productivity?)
  

 

It says production #12 on the screen. Does that mean there's also screens #1 - #11 or is #12 just some date information? How many of these production screens exist in the game?

[mos6507]

If you authored it for Chimera you could even support all 4 players.

[Prodos8]

This site has an excellent break down of the game play (very detailed) - http://bringerp.free.fr/RE/Mule/mule_document.html

[Thomas Jentzsch]

I wondered about M.U.L.E. before too. It is a GREAT multiplayer game!

 

The graphics seem very doable for the 2600.

[Cybergoth]

If you authored it for Chimera you could even support all 4 players.

 

How so? I mean what would it offer in regards of a 4 player game, that more RAM/ROM alone couldn't?

 

This site has an excellent break down of the game play (very detailed) - http://bringerp.free.fr/RE/Mule/mule_document.html

 

Uihajh, Kroah did it again!

[+SpiceWare]

Chimera has 2 expansion ports. Per this blog entry each port could have one of the following plugged into it:

• Dual RS232
  
• Dual PS/2
  
• Controller Port
  
• Genesis adapter (maybe)
  
• PC Gameport w/MIDI (uses both expansion headers)
  

[Thomas Jentzsch]

Well, you could do the bidding screen with paddles and the other screen with a joystick. But that would require either an Y-adapter or constant changing with more than two players.

[Cybergoth]

So the game requires 4 joysticks or just 4 buttons?

[+remowilliams]

So the game requires 4 joysticks or just 4 buttons?

Four joysticks for four players with their own sticks. Hence this being an Atari 800 specialty title for that many players.

 

Or three players using one joystick (round robin) and two paddles on two port machines.

 

I can't see how you'd get that many land plots with the required symbols displayed on the 2600 though.

Edited December 30, 2007 by remowilliams

[supercat]

I think it even is 9 X 8 already.

 

10x8 presently. Vertical height is a tradeoff with CPU power (each tile must be a multiple of 4 scan lines tall). I've roughed out a version that's 11 tiles wide, but it's a lot more complicated and the colors aren't as flexible. The 10x8 version takes advantage of the fact that it only has to write the PF registers once per "big" line (the PF repeats every 20 pixels, and only the middle portion is unblanked).

 

I think MULE could be done reasonably well with a RAM-expanded 2600. I've posted on the Wizard of Wor threads my thoughts about a joystick splitter. Using a couple of those would seem better than trying to stick controllers into a Chimera or something.

 

Otherwise, it should be possible to have four players using one joystick, two paddles, and the SELECT/RESET switches.

[Cybergoth]

I think MULE could be done reasonably well with a RAM-expanded 2600.

 

That's my major concern with this project right now. There still is no extra RAM release on the market. If for example Boulder Dash or Ruby Runner or Elevator Action or anything else with more RAM was readily available in the store already, proving that their approach really can be mass produced with reasonable cost, I'd be happy to try for myself.

 

But until such a major breakthrough happened, I wouldn't risk to develop anything requiring extra RAM

 

See for example the Mappy thread. If johnnywc had been relying on this info he'd sit on an unreleasable sara game right now.

 

Same with Boulder Dash. I have a feeling that the planned, limited 200 cartridges release may simply come from Kroko refusing to build more of them, because they're going to be a PITA to assemble?

[TROGDOR]

You've forced me to play my hand.

 

 

MULE01.BIN

I started working on M.U.L.E. in July of this year. I was not planning on announcing it until it was much farther along. This is only version 0.01, so there's not much to it. However, I have spent hours researching the feasibility of this game on the 2600. My intention is to make this game work with a standard 8k or 16k ROM, and no expanded memory.

 

Other people are obviously welcome to develop their own versions of the game, but I wanted to disclose my development so you are at least aware that I've also been working on this.

 

For player control, the players would use 1 joystick and 2 paddle controllers. This would allow 3 simultaneous human players. The control would be similar to the C64 implementation, where players would take turns using the joystick for mule placement, but during trade, all three players could trade at the same time using the joystick and 2 paddles.

 

Because of limited RAM, I was thinking about limiting the game to only 3 players. If possible, a 4th player would always be controlled by the computer.

 

The trade screens are very easy to implement, with a triple copy wide spaced sprite, and bg graphics for the trading bars. The trading value displays could be shown in a similar fashion.

 

For the main screen, I considered two possibilities. Either reducing the total number of land lots to simplify the display and RAM requirements, or using a multi-screen solution, similar to Hunt the Wumpus, where there are actually 4 screens displaying all the land lots, rather than 1. Or maybe even making the mule placement similar to Adventure, where each land lot has it's own screen. A consolidated screen would be used for the land grab phase.

 

I've spent over 200 hours playing the C64 version of this game over the past 20 years, and I consider it possibly the greatest video game ever written.

 

Unfortunately it's very late and I need to go to bed. I'll look through my dev notes tomorrow.

Edited January 2, 2008 by TROGDOR

[Cybergoth]

Other people are obviously welcome to develop their own versions of the game, but I wanted to disclose my development so you are at least aware that I've also been working on this.

 

Oooohhh

 

Now this is excellent news, to see this great project already in such competent hands!!

[vdub_bobby]

Other people are obviously welcome to develop their own versions of the game, but I wanted to disclose my development so you are at least aware that I've also been working on this.

 

Oooohhh

 

Now this is excellent news, to see this great project already in such competent hands!!

Yes indeed!

 

But...

But I forbade myself from starting any more projects until I finish some of my existing projects.

 

[Cybergoth]

Well, he already started M.U.L.E. before that and actually it's just a typo and was originally supposed to read:

 

But I forbade myself from touching any other project until I finished M.U.L.E.

 

[TROGDOR]

Yes indeed!

 

But...

But I forbade myself from starting any more projects until I finish some of my existing projects.

 

The MULE work was done back in July, and was supposed to remain unannounced. Like I said, you guys forced my hand.

 

I have other projects that I tinkered with in 2007 that also have not been announced yet. I'm staying focused on Stellar Fortress. There will be another Stellar Fortress update in the coming week.

[Kroko]

Same with Boulder Dash. I have a feeling that the planned, limited 200 cartridges release may simply come from Kroko refusing to build more of them, because they're going to be a PITA to assemble?

I don't think it has to do with me. We did not discuss how many boards I am willing to make, so I guess the reason has to be something else. The good thing is, if you make only a few, you can do it by hand. If you make many, you can let them make for a reasonable price. Of course the quality of the game has to justify the increased costs. I think notBD is absolutely worth the additional costs.

 

or anything else with more RAM was readily available in the store already, proving that their approach really can be mass produced with reasonable cost, I'd be happy to try for myself.

Maybe the situation changes in case Andrew decides to release notBD, because in that case there would be demand for a lot of boards with RAM.

[supercat]

For player control, the players would use 1 joystick and 2 paddle controllers. This would allow 3 simultaneous human players. The control would be similar to the C64 implementation, where players would take turns using the joystick for mule placement, but during trade, all three players could trade at the same time using the joystick and 2 paddles.

 

What about adding player four using select/reset to move up/down in the auction screen (otherwise use either button in the land-grab screen, etc.)

 

The trade screens are very easy to implement, with a triple copy wide spaced sprite, and bg graphics for the trading bars. The trading value displays could be shown in a similar fashion.

 

The multi-resp trick should allow four pairs of sprites to be shown without too much difficulty, though the amount of temp-RAM required could be a problem in an unexpanded cart (assuming a need for four four-digit numbers on a line). Five scan lines at eight bytes each would be 40 bytes of temp-RAM, assuming you had enough scan lines between numeric readouts to prep each group.

 

For the main screen, I considered two possibilities. Either reducing the total number of land lots to simplify the display and RAM requirements, or using a multi-screen solution, similar to Hunt the Wumpus, where there are actually 4 screens displaying all the land lots, rather than 1. Or maybe even making the mule placement similar to Adventure, where each land lot has it's own screen. A consolidated screen would be used for the land grab phase.

 

Simplest approach to easing the graphics display without affecting main gameplay would be to rotate the "format" 90 degrees, so as to be 5 wide by 9 tall. Showing 5 plots across shouldn't be a problem (see Casino). Alternatively, if you use interleaved color for the plot outlines, you could then use 30Hz flicker to show the contents of the plots. The icons wouldn't be colorized, but if the plot outlines are colorized it should be clear who knows what.

 

RAM is going to be very tight if you don't even use a SuperChip. Is there some problem with CPUWIZ's boards and supply of SARA chips that would preclude their use?

[+batari]

RAM is going to be very tight if you don't even use a SuperChip. Is there some problem with CPUWIZ's boards and supply of SARA chips that would preclude their use?

I hear that the supply of NOS Superchips is exhausted and future chips would have to be harvested from existing games. There was a post about it a little while ago.

 

With that, I picked up my two-year-old Superchip replacement project and got it working, but I need 4 IC's (EPROM, SRAM, 22v10 PLD, and a 74123 to generate clean, reliable RAM write signals.) I don't think I can get it working with three unless I used a CPLD in place of the 22v10, which would sort of defeat the purpose of reducing the pin count.

[supercat]

I hear that the supply of NOS Superchips is exhausted and future chips would have to be harvested from existing games. There was a post about it a little while ago.

 

Must have missed it. Sure didn't take as long as I'd expected. Is the demand for +RAM games that great, or is someone hoarding them?

 

With that, I picked up my two-year-old Superchip replacement project and got it working, but I need 4 IC's (EPROM, SRAM, 22v10 PLD, and a 74123 to generate clean, reliable RAM write signals.) I don't think I can get it working with three unless I used a CPLD in place of the 22v10, which would sort of defeat the purpose of reducing the pin count.

 

The 4A50 board would be ready to manufacture if I knew there'd be enough demand. In lots of 50, I think the unit cost, assembled, was something around $30 each. The only places I can see possible cost savings for even a minimalist board would be:

 

-1- Using a +5 volt PLD/CPLD instead of a 3.3 volt one would eliminate the need for a +3.3V regulator, though the 3.3 volt CPLD (XC9536XL) is probably about as cheap as anything.

 

-2- The 4A50 board uses a 14.31818MHz oscillator as a time base. Using a lower-precision time base could save a little cost.

 

The 4A50 banking scheme relies upon the features of the XC9535XL and the precision of the oscillator. Other banking schemes probably would not. Nonetheless, I don't see much room for saving cost for other RAM schemes.

 

I'm still puzzled, though, where'd all the SARA chips go?

[mos6507]

The 4A50 board would be ready to manufacture if I knew there'd be enough demand.

 

It's a chicken and the egg situation. If you want games targetted to it you have to build some one-offs for developers.

[+batari]

I'm still puzzled, though, where'd all the SARA chips go?

Don't know, but CPUWIZ said he sold them all and has ceased production of the boards.

[TROGDOR]

For player control, the players would use 1 joystick and 2 paddle controllers. This would allow 3 simultaneous human players. The control would be similar to the C64 implementation, where players would take turns using the joystick for mule placement, but during trade, all three players could trade at the same time using the joystick and 2 paddles.

 

What about adding player four using select/reset to move up/down in the auction screen (otherwise use either button in the land-grab screen, etc.)

Yes, that would work. I have a personal pet peeve about using the console switches as controllers. It worked nicely for PhasorPatrol back in the day. But now that my original Atari is almost 30 years old, I treat it like a Fabergé egg. That means no more frying, and no more using the switches as game controllers.

 

The trade screens are very easy to implement, with a triple copy wide spaced sprite, and bg graphics for the trading bars. The trading value displays could be shown in a similar fashion.

 

The multi-resp trick should allow four pairs of sprites to be shown without too much difficulty, though the amount of temp-RAM required could be a problem in an unexpanded cart (assuming a need for four four-digit numbers on a line). Five scan lines at eight bytes each would be 40 bytes of temp-RAM, assuming you had enough scan lines between numeric readouts to prep each group.

The tough part is the total cash display, which could be up to 6 digits per player. I'd change the format slightly. The bottom of the screen would show the four player's total cash amounts, one total per line. Then you'd only need 12 reusable bytes for 6 digit pointers.

For the main screen, I considered two possibilities. Either reducing the total number of land lots to simplify the display and RAM requirements, or using a multi-screen solution, similar to Hunt the Wumpus, where there are actually 4 screens displaying all the land lots, rather than 1. Or maybe even making the mule placement similar to Adventure, where each land lot has it's own screen. A consolidated screen would be used for the land grab phase.

 

Simplest approach to easing the graphics display without affecting main gameplay would be to rotate the "format" 90 degrees, so as to be 5 wide by 9 tall. Showing 5 plots across shouldn't be a problem (see Casino). Alternatively, if you use interleaved color for the plot outlines, you could then use 30Hz flicker to show the contents of the plots. The icons wouldn't be colorized, but if the plot outlines are colorized it should be clear who knows what.

I agree. The 90 degree rotation will be required if you want to display any kind of detail, especially plot color. To compromise RAM usage, a 5 x 8 lot layout would probably be ideal. The number 8 is easier to work with anyway.

RAM is going to be very tight if you don't even use a SuperChip. Is there some problem with CPUWIZ's boards and supply of SARA chips that would preclude their use?

RAM will be very tight. But resources are always tight on the Atari 2600. I want to try to do it in 128 bytes. It may not be possible. But I want to try.

 

I have nothing against add-on boards or extra RAM. It's just a personal development preference. For everything I've worked on, the target has always been the base 128 bytes of RAM, and let the ROM be as large as it needs to be. It would certainly be easier to make the game with an extra 512 bytes of RAM, but who develops for the Atari 2600 because it's easy??

 

If the extra RAM is needed, I'd probably switch to a two load Supercharger CD. (Mostly because I already have a Supercharger.)

Edited January 3, 2008 by TROGDOR