Mr Chin

[Tursi]

I decided to take the GCC compiler on a test run of the reason I wanted to port one so long ago, porting. I spent a couple of hours porting the ColecoVision "Mr Chin" game done for CollectorVision to the TI.

 

It worked pretty well, a couple of minor compiler issues easily worked around (and it found a bug in MY code that SDCC didn't).

 

The ColecoVision cartridge was published by CollectorVision and they have given permission for this TI port to be released. You can find information here: http://www.collectorvision.com/game-mrchin.htm

 

and here: http://www.colecovision.dk/mrchin.htm

 

You can even find the original manual here: http://www.beeslife.com/colecovision/colecovision.php

 

And you can find the original release thread here: http://atariage.com/forums/topic/125572-new-game-for-colecovision-mr-chin-ready-to-ship

 

I did one small gameplay enhancement, in that completing a row automatically re-spins all the plates, this should help get a little further.

 

Possibly most importantly, download the game here! Zip includes both a 90k DSK image and TIFILES format files.

 

MrChin.zip

 

(fix for screen blank added 2/22/2014)

 

And a review video of the Coleco version (essentially identical) here:

 

Edited February 23, 2014 by Tursi

[retroillucid]

Glad to see it available for the TI-99.

 

I think I will work on a box and manual for the TI-99

[OX.]

Great work Tursi, look forward to more of these Coleco ports if you can knock them out that quickly

[ti99iuc]

Wow Tursi... great work at all! ... maybe there is an hope to have easy a lot of other Coleco games conversion on the TI? :-):-):-):-)

[Omega-TI]

TURSI - YOU DA MAN!

_______________________________

 

Thanks for adding YET ANOTHER program into the TI community!

[+Vorticon]

 

I decided to take the GCC compiler on a test run of the reason I wanted to port one so long ago, porting. I spent a couple of hours porting the ColecoVision "Mr Chin" game done for CollectorVision to the TI.

 

It worked pretty well, a couple of minor compiler issues easily worked around (and it found a bug in MY code that SDCC didn't).

 

The ColecoVision cartridge was published by CollectorVision and they have given permission for this TI port to be released. You can find information here: http://www.collectorvision.com/game-mrchin.htm

 

and here: http://www.colecovision.dk/mrchin.htm

 

You can even find the original manual here: http://www.beeslife.com/colecovision/colecovision.php

 

And you can find the original release thread here: http://atariage.com/forums/topic/125572-new-game-for-colecovision-mr-chin-ready-to-ship

 

I did one small gameplay enhancement, in that completing a row automatically re-spins all the plates, this should help get a little further.

 

Possibly most importantly, download the game here! Zip includes both a 90k DSK image and TIFILES format files.

 

MrChinTI.zip

 

 

And a review video of the Coleco version (essentially identical) here:

 

Edited September 1, 2013 by Vorticon

[Tursi]

Wow Tursi... great work at all! ... maybe there is an hope to have easy a lot of other Coleco games conversion on the TI? :-):-):-):-)

I wrote the game, so I have the source code. That makes ones life a lot easier.

 

Don't expect ports of Coleco games I didn't write.

[+OLD CS1]

I wrote the game, so I have the source code. That makes ones life a lot easier.

 

Don't expect ports of Coleco games I didn't write.

 

Which begs the question: what Coleco games DID you write??

[Asmusr]

Great game! I didn't quite understand the GCC part. Is it written in C, and was the ColecoVision version also written in C?

[+retroclouds]

Impressive! Thanks Tursi, Collectorvision and insomnia! This is great stuff! 2013 is a great year for new high-quality games for the TI-99/4A. If this is ever published as a cartridge with box and manual, then I will buy it.

Edited September 1, 2013 by retroclouds

[awesp]

Thanks Tursi for sharing Mr Chin with the TI community!

[unhuman]

Couple hours? Dayum!

 

I decided to take the GCC compiler on a test run of the reason I wanted to port one so long ago, porting. I spent a couple of hours porting the ColecoVision "Mr Chin" game done for CollectorVision to the TI.

[+OLD CS1]

Impressive! Thanks Tursi, Collectorvision and insomnia! This is great stuff! 2013 is a great year for new high-quality games for the TI-99/4A. If this is ever published as a cartridge with box and manual, then I will buy it.

 

Hear hear. I, for one, would love to see some TI home-brews immortalized in full retail garb. The AtariAge store flogs a lot of Atari home-brew cartridges with manuals and boxes made to look just like the originals.

[RobertLM78]

Hear hear. I, for one, would love to see some TI home-brews immortalized in full retail garb. The AtariAge store flogs a lot of Atari home-brew cartridges with manuals and boxes made to look just like the originals.

Great idea! I'd love to see some carts for sale (RXB, for one ).

[retroillucid]

We will soon put a TI-99 section on our website

We plan to port some CV games for the TI

They will be available complete in box

 

Stay tune.

[+OLD CS1]

I had a thought last night about programming cartridges in C versus assembly. When you examine a cartridge, would it be readily apparently between one coded in C versus assembly? My thought is that when you program in C, the compiler takes care of all of the code and data placement, whereas in assembly the programmer makes those choices in his or her own style. Does that hold up to scrutiny?

[TheMole]

I had a thought last night about programming cartridges in C versus assembly. When you examine a cartridge, would it be readily apparently between one coded in C versus assembly? My thought is that when you program in C, the compiler takes care of all of the code and data placement, whereas in assembly the programmer makes those choices in his or her own style. Does that hold up to scrutiny?

One would probably be able to deduce it from some code generation patterns the compiler uses (like a fixed function epilog, or specific register usage patterns, for instance), so a trained eye should be able to see the difference. However, with the exception of the calling stack and heap, you still have full control over data placement within memory, and you can even go so far as to define code segments in specific locations (although I'm not sure the TI gcc port supports this). Remember, without a libc library, you're programming pretty close to bare metal. Dynamic memory allocation is typically provided by libc through malloc() and it's cousins, but those are too wasteful to use on a system like the TI IMHO (and would be difficult to pull off seeing it's fragmented memory structure).

 

You really don't lose much when coding in C on the TI in terms of speed. The compiled code will probably be marginally bigger than hand-coded assembly, but in most circumstance the benefit of working in a higher level language beats any improvements in memory usage you would see. At least for me .

[Tursi]

Which begs the question: what Coleco games DID you write??

Answering this would lead to implicit promises I'm not prepared to make. None of the original games, however, I just did a couple of commissions. This is only really doable with C code, Z80 assembly would take a lot of work to rewrite for the 9900.

 

Great game! I didn't quite understand the GCC part. Is it written in C, and was the ColecoVision version also written in C?

Yes, the ColecoVision version was compiled using the SDCC compiler, and the TI port using GCC. The code changes needed were TI versions of the ColecoVision specific functions for graphics and sound, a couple of bug fixes that GCC picked out that SDCC did not, and a couple of workarounds for GCC bugs. It almost worked out of the box (so to speak).

 

This is great stuff! 2013 is a great year for new high-quality games for the TI-99/4A. If this is ever published as a cartridge with box and manual, then I will buy it.

Thank you. I don't intend to ever port this over to cartridge (it would still need the 32k without a lot of work - and I don't know, would a 32k-requiring cartridge be a bit weak for a modern release?) Besides the need to add bank switching to the code (for 8k banks), it uses more RAM than is available in scratchpad, so I'd have to solve that as well. I don't have time for the work it would take, which is why I released it as a disk title instead. CV plans to box up a few special editions with box and manual, though, I believe, but they will be floppy-based.

 

I had a thought last night about programming cartridges in C versus assembly. When you examine a cartridge, would it be readily apparently between one coded in C versus assembly? My thought is that when you program in C, the compiler takes care of all of the code and data placement, whereas in assembly the programmer makes those choices in his or her own style. Does that hold up to scrutiny?

Pretty much, yes. But the GCC compiler does frequently surprise me with rather good code, it's why I've adopted it so fully. In general, C code is recognizable for making a lot of jumps and in particular for its stack use. Once you know what the stack function looks like, you can pick out C pretty quickly, especially at the edges of functions where stack tends to be set up and cleared. For instance, c99 has a function that pushes onto it's stack, so you'll see a lot of "bl *r15" in the code (alternately, there's an 'inline push' option in c99 that will replace this with the two instructions that a push actually is, but I don't recall what they are. It makes the code much larger but much faster). Function calls are generally a bl *r12 followed by the address of the actual function. c99 was a fairly simple compiler with limited optimization, so you'll see a lot of jumping around and steps that could be combined.

 

START
 BL *12
 DATA GRF1   * grf1()
 LI 8,1
 BL 15       * push '1'
 LI 8,1
 BL 15       * push '1'
 LI 8,C$28
 BL 15       * push 'c$28'
 BL *12
 DATA SAY    * say(1,1,c$28)

(of course, that's source code, the assembly would have all numbers and no labels )

 

GCC is a bit smarter, but you'd still start to recognize patterns. As a modern optimizing compiler, it's capable of re-ordering code and even removing any code blocks or function calls deemed unnecessary. In particular, it's surprisingly smart about the stack (to me, anyway), skipping it when possible for function calls and preferring registers. But all compilers are dumb somewhere, after looking at the code for a while you'd start to work it out. The stack based-storage is the main giveaway, not to say a programmer would never do that in assembly, but it's less common.

 

getbonus
	dect r10            * make room on stack
	mov  r11, *r10      * save return address
	li   r1, >A         * R1=10 
	mov  r1, r2         * R2=R1 (also wanted 10, compiler knew this was preferable to another LI)
	li   r3, LC0        * R3=LC0
	bl   @writestring   * writestring(10,10,LC0)

[RXB]

Using the AMS or SAMS with the RAG C Compiler allowed 1024K of memory for the TI.

 

For gaming that would present a ton of new things that can be done.

 

I am really amazed at how little it is being used. Or only RAG C Compiler does this!

[+Ksarul]

Thanks, Tursi! I've always wanted to see a game like this one on the TI for some weird reason--and now you've gone and made one. Many, many thanks!

[+nanochess]

A question, if the game is in DSK format 90K or 180K, how much RAM space it's available for program/data?

[+arcadeshopper]

I decided to take the GCC compiler on a test run of the reason I wanted to port one so long ago, porting. I spent a couple of hours porting the ColecoVision "Mr Chin" game done for CollectorVision to the TI.

 

It worked pretty well, a couple of minor compiler issues easily worked around (and it found a bug in MY code that SDCC didn't).

 

The ColecoVision cartridge was published by CollectorVision and they have given permission for this TI port to be released. You can find information here: http://www.collectorvision.com/game-mrchin.htm

 

and here: http://www.colecovision.dk/mrchin.htm

 

You can even find the original manual here: http://www.beeslife.com/colecovision/colecovision.php

 

And you can find the original release thread here: http://atariage.com/forums/topic/125572-new-game-for-colecovision-mr-chin-ready-to-ship

 

I did one small gameplay enhancement, in that completing a row automatically re-spins all the plates, this should help get a little further.

 

Possibly most importantly, download the game here! Zip includes both a 90k DSK image and TIFILES format files.

 

MrChinTI.zip

 

 

And a review video of the Coleco version (essentially identical) here:

 

 

Very nice! copied it over to the F18a 4/a and works great!

 

Greg

[Centurion030]

Tursi,

 

Since this was a good test of the GCC compiler, would porting the Contiki system-especially the older versions with the GUI?

 

James

[Tursi]

A question, if the game is in DSK format 90K or 180K, how much RAM space it's available for program/data?

For a disk title on the TI you have 32k of CPU memory, in two separate blocks (one is 8k, one is 24k), in addition to the 16k of video RAM. In general, GCC uses the 24k block for the program and data, and the 8k block for stack (as does c99).

 

Since this was a good test of the GCC compiler, would porting the Contiki system-especially the older versions with the GUI?

Hard to say. There are still some compiler bugs, generally dealing with converting between bytes and ints, so you would have to be prepared to troubleshoot the compiled code. This is easier when you wrote the original program than when you're porting someone else's. The TI also has less memory available than the C64, but the various ports of Contiki show that you can get around that. I have toyed with it at a conceptual level more than once, but never gotten very deep.

[+OLD CS1]

Any chance I can solicit an Extended BASIC loader for Mr. Chin?