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
Anyone want to port M.U.L.E.?
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.
Anders Carlsson
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.
Anders Carlsson
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,
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,