Woah! I never imagined that calculators could be used for such an awesome feat! haha now we can watch the calculator (instead of TV) :P

holy hell
nice work ben.

Woah, that's amazing. Great work!

Major congrats to Ben Ryves! Very awesome.

Wooow !!

CONGRATULATIONS BEN !!!!

It's just incredible !

This is such an amazing achievement, great work Ben ... you're a bloody genius!

/me needs to go into town to buy a 5v regulator

ew that friggin sucks, the author need to die by watching american idol

j/k awesome work, at least maybe one day we will be able to play our games on huge screens without having to use emulators like VTI, PTI, wabbitemu and tilem

Huh...I tried this once before. I wrote a similar program & connected my TI-86 to my NTSC TV, but it would not sync correctly. Since I had the timings very close (they worked in the prototype I wrote in Visual Basic using the timestamp counter), I assumed it was just because my batteries were low. It would really help if the calculators had clock crystals instead of RC oscillators.

Glad to hear someone got it to work better, though I hope it works in NTSC & not just PAL.

The 83+ SE and 84+ do have crystal timers, with interrupt capability. It would make this work much better.

Oh, well, then that does help. :)

Come to think of it, the NTSC standard seems to be pretty lax about the overall timings (as evidenced by the success of my Visual Basic-based TV signal generator), so I must have gotten the sync pulses wrong or something.

Thank you for the feature. :)

As Michael Vincent pointed out (and as is discussed in the MaxCoderz thread) this would probably work a lot better on an SE or higher, not only for the increased horizontal resolution but so one might use the interrupt timing to leave some CPU time for a game.

You know what other system made the programmer manually generate a TV picture? The ATARI 2600!
(okay, not really, but its video chip was so primitive that you basically had to draw each scanline to the video chip as the screen redrew!)

dont you have to redraw every scanline to the video chip on as the screen redraws on any system?

Many systems have framebuffers. I am not familiar with the Atari, but it is possible that it had no framebuffer, just a video generator attached through DACs to the data lines.

the atari 2600 does not have a frame buffer, and that is the only system i program for, so i am not familiar with frame buffers. on the atari, to make playfeilds (the background) not a mirror image of itself (left side mirrored to right) you have to count machine cycles until the electron beam has reached the center of the screen and then change the values of the video chip (TIA) registers.

A frame buffer sounds very helpful!

Framebuffers are very expensive (memory-wise) so older hardware will typically use a certain number of tiles (or "characters") and use tilemapped displays. There often isn't enough VRAM to store one tile per tilemap entry, which can make simulating bitmapped displays rather difficult.

I have heard of tilemapping, but for some reason that did not come to mind when answering the question. Oh, well.

This is cool, but I still prefer the projector screen, it's bigger and compatible with my 89 TI.
But now I can get away from the emulator mess on the computer!

It would be interesting if somehow the full 96x64 monochrome output could be viewed, and done via interrupts, so that normal OS operation were possible. Someone could then sell very cheap ways to view a calculator on a TV system and perhaps make a fortune selling to schools in place of the expensive TI systems.

Well, if you used an external chip to generate the signal (including some form of buffering, since the data would come in bursts during interrupts), you could output a single frame (on the TI-83+) using 173,553 clock cycles (including the conversion to 2-bits-per-output), yielding 86.4FPS at 15MHz (TI-83+SE/84+(SE) speed). If you limit the framerate to 50FPS, then you get around 6.3MHz left over for the OS, or plain TI-83+ speed. Sounds doable, but it needs an FPGA or microcontroller.

Read that as "on the TI-83+ SE." Of course, you could always just lower the framerate on a plain TI-83+ or a TI-86, but with significant OS/game slowdown.

I doubt a greyscale game like Desolate for the 83/84 would work right with this set up though... Anyone try it?

There's no doubt it wouldn't work off the bat, but some modification of the code routines could certainly be plausible...

Here is the code I used for the above timing (if anyone cares). Let p be the link port. Also, HL should be loaded with the address of the data to output & B with the count. Set B to 0 & repeat the code 3 times to copy enough bytes for a 96x64 bitmap. Put a table at XX00..XX03 of the link values to transfer 00, 10, 01, & 11 (respectively) & load D with XX.

LOOP: / LD C,(HL) / INC HL
[REPEAT 4x]
XOR A / RRC C / RLCA / RRC C / RLCA
LD E,A / LD A,(DE) / OUT (p),A
[END REPEAT]
DJNZ LOOP