Anyone want to port M.U.L.E.?

JamesD · Post by **JamesD** » Mon Oct 01, 2007 5:28 am

There is a C port of M.U.L.E. to the Speccy underway.
Anyone want to give a shot at porting it to the Oric?

http://www.worldofspectrum.org/forums/s ... hp?t=16690

carlsson · Post by **carlsson** » Tue Oct 23, 2007 1:04 pm

Cool. I begun sketching on a VIC-20 port last year, but didn't come very far. I don't know if there can be any co-operative efforts, but if a M.U.L.E. game is to be programmed from scratch in 6502 machine code, the Oric has more in common with the VIC-20 than it has with the ZX Spectrum. Of course, both Atari 800 and Commodore 64 also are 6502 computers, but I don't believe in the concept of lifting code.

JamesD · Post by **JamesD** » Tue Oct 23, 2007 6:31 pm

Machine code? It's in C. The graphics and sound would need to change but the logic and A.I. should stay the same.

carlsson · Post by **carlsson** » Wed Oct 24, 2007 3:55 pm

Yes, I saw that. I don't know how efficient the C compilers that support the Oric is, but at least cc65 tends to use quite a deal of memory. Since the original game was 48K of tight packed 6502 machine code (Atari 800), I think even a down scaled version would be hard to fit into that memory using a compiled language. It may be excellent for prototyping though, and then hand optimizing some routines, but personally I would try to write everything from scratch in machine code.

Post by **Dbug** » Wed Oct 24, 2007 8:13 pm

In average the code generated by the C compiler is about 16 times slower than what I would do in assembler, and on some tight optimised loops (like graphical stuff), easily 60 times slower.

The size, don't really know, but at least three times larger.

JamesD · Post by **JamesD** » Wed Oct 24, 2007 10:57 pm

I know C is slower and generates much larger code than assembly... esp on the 6502. But M.U.L.E. didn't require fast animation so I doubt that speed would be an issue. And was it large because it required that much code or was it because it loaded up a bunch of pre-drawn graphics screens?

Chema · Post by **Chema** » Thu Oct 25, 2007 8:53 am

C code can be over 5 times larger than asm easily.

Anyway. I have already ported an infocom interpreter (Pinforic, which is quite a complicated program, with virtual -paged- memory management, text compression, etc.) and I would say that if you have the source code (and it is complicated enough), then a good approach would be trying to make it compile and run (even partially) and then try to spot routines that should be optimized (in speed or size) and rewrite them in asm. Normally it is not that difficult if can program in 6502 asm. Even in some cases just removing parameters and setting them as global variables (for instance) is quite a noticeable gain.

Fabrice did all the optimizations in Pinforic and I can't remember the numbers now, but the gain was impressive in both size and speed, and there was not need to rewrite the program from scratch or try to decipher all the logic. True that the end code is over 60% (or more) asm.

Obviously, if you have a clear idea of how it works, then you can try to code it directly in asm, which is the best approach...

Regards,