Yes, yes, and yes. It's just too blocky to actually enjoy.

I myself am not a big fan of Calc FPS in general, but I do think the walls look very blocky compared to other raycasters I have seen.  For instance, Runer's Axe raycaster provides a good example of a raycaster that does textured graphics well.  I think with such a limited screen size, scaling up an image is just not an option, since so much of the screens detail is needed in order to present a convincing illusion of 3D, especially when the walls are at a distance.

I think one issue that might be related to the limited 3D effect is actually the chosen textures as well.  The defining portion of a wall in a raycasting environment is its top and bottom edge, which leads me to believe that wall textures in raycasting games should always generally try to keep the tops or bottoms of wall textures a solid color (probably black) to give the user as much clues as possible to determining where the walls actually go. 

In summary, I think the scaling of the original image is what is holding back the graphics.  I understand you did the scaling because you had no desire to rewrite the gemeni graphics routine yourself correct?  I think the enemies have good visibility, although if possible I might suggest including a white mask around them so that it becomes even easier to separate them from the background.

Sorry for not browsing through all the threads is this has been answered, but how did you implement the grayscale?

I used the following reasoning when I made Gemini:
*) I valued fluid graphics and controls above pretty much everything else. This ruled out grayscale, large screen space and other things that munch fillrate.
*) I tried to utilize as many pixels individually as possible, early pixel-doubling tests looked too blocky imho and I opted for the reduced viewport instead.
*) I wanted things to be pretty clear, which is really hard with a nearest neighbour scaler, but mipmapping was not viable on the TI83s. Instead I tried to make textures and sprites with rather large white or black areas instead of putting a lot of details in, can't remember how well I managed...

Imho, I'd trade grayscale for per-pixel fidelity and speed in any game, in this case I'd trade casting every column individually to grayscale in a heartbeat. Grayscale is wonderful for "lazy" 2D graphics (i.e. shuffling around rather than redrawing) but 3D graphics should focus on accurate transforms and there were still a bunch of glitches in Gemini at release.

Look into the table generator program, there's a rounding problem in there which produces jagged texturing that I never solved. Looking down a wall, a horizontal band in a texture should monotonically reach the center of the screen, but there's noticeable jumping in screen space. This is just arithmetics in a C program and would need no tinkering in the z80 code. And as I mentioned in another post, play around with the perspective tables a bit to make the walls a wee bit fatter.

Instead of stretching the screen, why don't you just use only a part of the screen? Sure you'll have a lot of blank area, but I'll look so much better.

Because so many people complained about lack of fullscreen in Gemini.  Assuming that new fidelity will solve the blocky walls, there will be no need to stretch the screen or use only part of the screen.

EDIT: Btw, to answer your question coelurus, the Ti-83+ SE and Ti-84+ calculators have extra RAM, so I was able to create two textures for each wall, thus allowing 3-way grayscale

I tried the 15MHz switch on the TI83+SE when Gemini was finished and it was way too fast, what are the major reasons that Elimination can not go from 64 to 96 columns? Compared to Gemini's target freq at 6 MHz, 15 MHz is more than doubled up and 96/64=1.5. Grayscale+background?

I can't remember the results of my profiling tests, which is slower of the casting and the texturing?

The texture scaler was based on looping 1:1 in screen space, having the coord LUT increase texture offset and a mem read for every pixel. What about walking 1:1 in texture space + drawing piecewise vertical lines in screen space? More overhead for piece setup but fewer mem reads. Lots of things to try here actually:
For small slivers, the 1:1 screen space code is probably optimal.
For big slivers, storing textures in a vertical rle-fashion could be interesting, to piece together the vertical lines.
Sorry, getting carried away, but I still think the wall LUT generator needs to be looked over, the jumpy texture coords are probably a major reason why the graphics look a bit more blocky than they should. I think I'll have a look myself.

People complaining about the small viewport in Gemini (which they rightfully did) isn't really reason enough to double pixels. Again, on a 96x64 screen, the spatial extent of every pixel counts so treat every pixel with love and cut the fancy additions and do 96 proper casts. Doubling for 96 would use only 48 casts, but the non-uniform scaling is pretty bad. Just my opinion of course...

I think some ornamental objects are a tad too detailed, could you try and reduce the complexity a bit and rely instead on big white/black areas? Outlines don't need to be very thick then.

I had trouble with telling where walls were at first but I quickly got used to that. My main complaint seeing the enemy sprites, I usually have to rely completely on the health bars for them.
A friend stumbled upon this gpl raycasting maze for the 83+ a while ago. I haven't had a look at the source though. http://www.ticalc.org/archives/files/fileinfo/272/27287.html