So as I was working on some LCD update things today, I got a little bored and took a little look at the ion fastcopy routine. As most programs for monochrome calcs use some type of LCD update with a buffer, rather than simply writing directly to the LCD ports to reduce flicker, I was wondering what would happen if I just drew this buffer pixel by pixel to the LCD on the TI84+CSE. And the results turned out pretty well; however most text bcalls don't work because they use a different sized font. But they can easily be rewritten. (Also I think I messed up something I wasn't supposed to in the main file, so some enemies seem to run a tad slower. That's easy to find though.

I'm thinking that if I also implemented VRAM swapping along with drawing each line twice, I could double the size. Plus colors are customizable, by that I mean the screen can only be one color.

The cool thing about this is is that mostly all code can be kept the same, all that needs to be fixed is instead of including ion, I just wrote a separate include file that compiles them using my update routine. Now, enough talk. Here's a test of the Mario game 1.2 by Sam Herald on the CSE.

Fun hacking project! Can't wait to see how your further efforts turn out.

Wow looks awesome! I do think it could benefit from pixel doubling etc as thats bound to be very tiny - in 160mode it could work quite nicely I imagine .

Mario on the CSE? Cool!
In all seriousness though, is this going to happen? Mateo, I know you are wrapping up Portal, are you looking for a new project?
Also, does this mean that other games like pheonix or something could be ported this way?

Indeed it does. This makes porting games nicely, but in all seriousness, making a color version would be a major undertaking, I just used the monochrome Mario because I was already working with it. But this means that ports could be feasible, but color support for monochrome games is probably impossible.

Well you could do 1 colour or foreground/background etc ... ?

Or there is the TI-Boy CSE method which could work for grayscale games (specify colours for each shade instead).

Awesome! I agree, if you went to 160 mode and doubled the number of vertical lines, it would look great in 2x res

So this makes porting games to color easier, but not by to much?
Would a black an white port be relativly easy?

Yeah, that is relatively easy for most games. Also adding in a customization for background and foreground would work too. But making it color usually requires a full rewrite.

You could make a game like Pheonix look pretty convincing, isn't it only three colors?

Oh, I just tried that out and it looks quite nice. I unraveled some loops to speed things up too. The only problem is that updating is still a little slow... I need to figure some things out to make it faster.

EDIT: tr1p1ea++ times 1000 for this program: http://www.ticalc.org/archives/files/fileinfo/348/34894.html This makes adding text and stuff that much easier!




Yeah, I could, but the way this works I can only have two colors... Unless... Hmm...

Looking nice, how much z80 ASM do you need to get the program runming on the screen like that?

Honestly, it wan't too hard. As long as you have the source, it is pretty nice to make it work. Of course, you can't use hardware vertical scrolling, but writing a software routine to do that isn't bad.

This took me about ten minutes to change, but quite a bit longer to write the code to make it do it right.


Here's a couple examples that I just randomly selected off of the webs:

3D maze:


Rubiks Cube:


EDIT: So here' the idea that I was thinking about, but not sure if it is feasible at all right now: As tr1p1ea was saying, I could have different colors for different buffers, but that would require updating multiple times per frame, unless there is someway to avoid that...

Very impressive Mateo! I guess it stands to reason that I could port AB5 to the TI-84+CSE, albeit in monochrome and not running as fast as on the non-CSE calcs. But nevertheless it would still be interesting to try. I might give it a go sometime!

You could possibly do something like two 768 byte buffers to simulate grayscale, or 4-colour graphics. For each pixel write to VRAM you'd need to check the respective bit/byte of each buffer to work out what colour is required to be displayed.

Oh, that's a good idea! I might only be able to get 3 colors, because the background needs to have a transparent layer... Unless I'm mistaken? Anyhow, Alien Breed should work fine, just need a hardware to software vertical scroll. I actually tried to build it with both spasm and brass, but for some reason couldn't get it to compile... spasm just decided to quit randomly on Pass 1... It's probably my fault.

Anywho, I'll give that a try and see what materializes.

Hmm... Mobiletunes3 port?



Here's some software scrolling tests:


Hmm... I'm thinking that there could be two options, one to activate small screen mode, which runs a little faster, and then half-res....

a thats cool work there bud! Nice to see someone using some tricks to make some games work like magic on the CSE!

Is it too much work to write versions of the sprite routines and text routines that draw directly to the LCD, and not bother going through a gbuf surrogate at all? That would allow the sprite-draw calls to gradually be replaced with color sprite data and calls to the DCSE sprite routines, if the programmer so desired. I continue to want to help work on this project myself, but you're making huge strides on your own. Good work!

Actually, the code for this is just an adapted form of one of the sprite routines I had for 2 color sprites.... But there's no masking or clipping or other things. DCSE sprites are already supported; you can draw to the screen however you like. It just prints out the data at plotsscreen when updating.

There still needs to be a replacement for the vputs and vputsn bcalls; tr1p1ea's font routine works well, but it doesn't mask out the current pixels it overlays on the characters... Also, I'm not sure, but setting the text inverse flag probably doesn't work right.

Mateo, if you don't mind could you please teach me how to do this?

You should learn assembly first and get some significant experience with the language before attempting something like what Mateo is doing here (otherwise you'll get quite frustrated indeed). We generally recommend using TI-83 Plus Assembly in 28 Days with the Brass assembler, usually in the form of the Doors CS or Doors CSE SDK.