Jump to content
Omega-TI

Totally useless, just for the heck of it, could it be done discussion thread.

Recommended Posts

Disclaimer:  This thread is not intended to implore anyone to go out and actually build any anything arising from this thread, it's mainly to discuss the technical aspects and feasibility of things that have not be done on the TI.

 

Okay, I'll start this out with an idea that will probably get shot down rather quickly...  VIDEO on the TI using the cassette port.

 

With today's supporting technology on the PC, it seems feasible to convert moving video to a standard that the TI can utilize, like Tursi did with Dragon's Lair.

We also have the capability of storing video on modern SD cards and the like... but what if there could be a program on the TI to save a streaming type video file from the TI to the cassette port?  How much video (at TI resolution) could you get on a 30, 60 or 90 minute tape?  Could the TI's cassette port even handle it?  Could the TI even process it fast enough?

 

Why would one even want to do this?  For the sake of it?  Naw, but what about a video game with real images at the right time?  If the tape was started at the beginning (synced with the game) a person could have an adventure type game with 'a little extra'.  Or have a collection of short music videos just for the heck of it.  Maybe something else entirely, who knows.

 

 

 

 

 

 

Share this post


Link to post
Share on other sites

I have an idea.  I don’t really like internal upgrades, but would like the option of better video.  So could a sidecar be designed to provide it?  If you use a V9938 or V9958, it only requires a couple of addresses.  I could envision software that would let you have dual screens.  Maybe you are writing software using a clear 80 column screen and seeing what the screens look like on a stock TI at the same time?  I know custom software would need to be written to use it, but it could be a neat addition.

 

Maybe a simpler approach would be to use some more pins of the PI to receive video data and have the PI run the display.  

Share this post


Link to post
Share on other sites
2 hours ago, Omega-TI said:

Disclaimer:  This thread is not intended to implore anyone to go out and actually build any anything arising from this thread, it's mainly to discuss the technical aspects and feasibility of things that have not be done on the TI.

 

Okay, I'll start this out with an idea that will probably get shot down rather quickly...  VIDEO on the TI using the cassette port.

 

With today's supporting technology on the PC, it seems feasible to convert moving video to a standard that the TI can utilize, like Tursi did with Dragon's Lair.

We also have the capability of storing video on modern SD cards and the like... but what if there could be a program on the TI to save a streaming type video file from the TI to the cassette port?  How much video (at TI resolution) could you get on a 30, 60 or 90 minute tape?  Could the TI's cassette port even handle it?  Could the TI even process it fast enough?

 

Why would one even want to do this?  For the sake of it?  Naw, but what about a video game with real images at the right time?  If the tape was started at the beginning (synced with the game) a person could have an adventure type game with 'a little extra'.  Or have a collection of short music videos just for the heck of it.  Maybe something else entirely, who knows.

Since you ask for it. 🙂 You know how slow it is to load a program from cassette. A bitmap image is 12K. How long does it take to load a 12K BASIC program? A few minutes? And we want to load several images per second. Even with the most clever optimizations I think it would still be a thousand times too slow. 

  • Like 4
  • Sad 1

Share this post


Link to post
Share on other sites
22 minutes ago, Keneg said:

I have an idea.  I don’t really like internal upgrades, but would like the option of better video.  So could a sidecar be designed to provide it?  If you use a V9938 or V9958, it only requires a couple of addresses.  I could envision software that would let you have dual screens.  Maybe you are writing software using a clear 80 column screen and seeing what the screens look like on a stock TI at the same time?  I know custom software would need to be written to use it, but it could be a neat addition.

 

Maybe a simpler approach would be to use some more pins of the PI to receive video data and have the PI run the display.  

I was trying to wrap my mind around this approach with the PI.  

 

Are you thinking of using the Cassette port as the interface to the PI?  Is there an effective baud rate limitation?  Or,

 

Are you thinking of using the TIPI as an interface to the PI?

 

The TIPI/PI combo would need a new protocol and it does allow a pretty large 'in-ram' buffer along with VDP transfers as well.  So, the question becomes do you want to transfer all of VDP to PI and vice versa with up to 16K chunks as images?  That would probably not be too difficult and would be speedy and something I have suggested in a similar thread in the development forum for using the PI as a frame grabber with a camera.  Now, with the 9938 capability, you are going to end up limiting yourself to effective ram.  Basically, what you would write to VDP instead needs to be written to CPU ram, and then you limit yourself to at most a 24K image capture of ram on a TI console.  You would not get into the 9938 specific graphic modes unless you start fragmenting ram chunks which would likely need a SAMS to even consider it.   Then, you would need something on the PI to grab data to display if you wanted to actually see it "live".

 

 

  • Like 2

Share this post


Link to post
Share on other sites
22 minutes ago, Asmusr said:

Since you ask for it. 🙂 You know how slow it is to load a program from cassette. A bitmap image is 12K. How long does it take to load a 12K BASIC program? A few minutes? And we want to load several images per second. Even with the most clever optimizations I think it would still be a thousand times too slow. 

I still find the idea of developing a very low bandwidth video encoding protocol for the 9918A interesting. 

 

Edit: I found this, just for fun:

https://gizmodo.com/hacker-figures-out-how-to-capture-horrible-quality-vide-1842660879

Edited by Asmusr
  • Like 1

Share this post


Link to post
Share on other sites
49 minutes ago, Asmusr said:

Since you ask for it. 🙂 You know how slow it is to load a program from cassette. A bitmap image is 12K. How long does it take to load a 12K BASIC program? A few minutes? And we want to load several images per second. Even with the most clever optimizations I think it would still be a thousand times too slow. 

I think you're right!!!

Share this post


Link to post
Share on other sites

But there is still something there. As the cassette port could "kick" off a byte to the pi that could enable the pi to launch a video. Maybe, possibly, but also putting a host processor between the cassette port and rasberry pi.

But clicking a mouse on an icon on the raspberry pi could do the same thing.

Now, you could write an app that sorts videos and runs from the cassette port, would be only a viewable txt file to add, edit txt information.

Edited by GDMike

Share this post


Link to post
Share on other sites
1 hour ago, BeeryMiller said:

I was trying to wrap my mind around this approach with the PI.  

 

Are you thinking of using the Cassette port as the interface to the PI?  Is there an effective baud rate limitation?  Or,

 

Are you thinking of using the TIPI as an interface to the PI?

 

The TIPI/PI combo would need a new protocol and it does allow a pretty large 'in-ram' buffer along with VDP transfers as well.  So, the question becomes do you want to transfer all of VDP to PI and vice versa with up to 16K chunks as images?  That would probably not be too difficult and would be speedy and something I have suggested in a similar thread in the development forum for using the PI as a frame grabber with a camera.  Now, with the 9938 capability, you are going to end up limiting yourself to effective ram.  Basically, what you would write to VDP instead needs to be written to CPU ram, and then you limit yourself to at most a 24K image capture of ram on a TI console.  You would not get into the 9938 specific graphic modes unless you start fragmenting ram chunks which would likely need a SAMS to even consider it.   Then, you would need something on the PI to grab data to display if you wanted to actually see it "live".

 

 

I was thinking if the TIPI. Was expanded to work similar to the TMS or V chips.  A couple of pins to select ports, a pin as a read/write signal, a pin to toggle to tell the PI to read the pins, and eight pins for data.  I think there are plenty of pins left on the PI for that.  So you would have software on the PI that would store the screen data and display it.  A PI-0 might not have enough speed and memory, but a 3, 3+, or 4 should.  If using the V9938 or V9958, the TIPI just have to have the circuitry to create the ports at an unused address and whatever circuitry is necessary to get the signal to a monitor. 
 

I would prefer the addition to the TIPI because it would get us all the way to modern displays without any additional hardware.

 

These are just ideas I have that I definitely don’t have the skills to implement on my own, so I am bringing them to the community.

 

 

 

Edited by Keneg
  • Like 1

Share this post


Link to post
Share on other sites

Why reinvent the wheel?

 

If you are going to use the Pi to function as a display, just make the TI speak X.

 

We have "local telnet" data transport.

 

 

X windowing system was initially intended to operate over a network transport.  We already have that.  The PI already has libraries to display content from a remote X source. The TI just needs to tell the Pi what to display.

 

 

 

ALTERNATIVELY---

 

If somebody has one of those very very rare hexbus video display systems, and wants to dump the graphics routines inside it, we could derive a suitable X library to handle hexbus video messages. This would have synergy with the CC40 and pals.

Edited by wierd_w
  • Like 1

Share this post


Link to post
Share on other sites

Then I guess there's always the option of just doing a TIPI or cassette port version of the sort of "cheating" I did with my TI-99/4A Gaming Control Centre Project, where the TI-99/4A controls via RS-232

 

1) An analogue picture-in-picture device

2) A PDU

3) An RGB matrix switch

 

And therefore, the TI-99/4A can on command during program execution power/select/display video sources and adjust their location and size on screen.

  • Like 2

Share this post


Link to post
Share on other sites

I like the idea that, using the pi to display data that the TI sends or could possibly send as a basic command, I think that's what commander is doing?

 

Share this post


Link to post
Share on other sites

One could also use something like the somewhat rare Video Controller from TI. It was designed specifically for interactive video functionality. . .and can save programs, data, and video on the tape or laser disk.

 

  • Like 3

Share this post


Link to post
Share on other sites

Yeah, the hexbus HX1100 Video Interface 50-53.

 

Emulating one would have synergy with the CC40.  However, we dont even know what the bytcode instructions to drive the sorry thing are! Somebody with such a rare beast needs to dump its innards for examination.

 

Or do you mean this thing? (and it's sidecar version)?

http://www.ti99.eu/?page_id=1223&lang=en

Edited by wierd_w
  • Like 1

Share this post


Link to post
Share on other sites
3 hours ago, Asmusr said:

Since you ask for it. 🙂 You know how slow it is to load a program from cassette. A bitmap image is 12K. How long does it take to load a 12K BASIC program? A few minutes? And we want to load several images per second. Even with the most clever optimizations I think it would still be a thousand times too slow. 

Pointing on the obvious ;)

Anyway, it isn't *completely* hopeless - I've seen several FastLoaders, including one I've helped test for the CoCo. 

https://github.com/MyTDT-Mysoft/COCO-FastLoader

Share this post


Link to post
Share on other sites
1 hour ago, Keneg said:

I was thinking if the TIPI. Was expanded to work similar to the TMS or V chips.  A couple of pins to select ports, a pin as a read/write signal, a pin to toggle to tell the PI to read the pins, and eight pins for data.  I think there are plenty of pins left on the PI for that.  So you would have software on the PI that would store the screen data and display it.  A PI-0 might not have enough speed and memory, but a 3, 3+, or 4 should.  If using the V9938 or V9958, the TIPI just have to have the circuitry to create the ports at an unused address and whatever circuitry is necessary to get the signal to a monitor. 
 

I would prefer the addition to the TIPI because it would get us all the way to modern displays without any additional hardware.

 

These are just ideas I have that I definitely don’t have the skills to implement on my own, so I am bringing them to the community.

 

 

 

Thinking about it, you might be able to use the TIPI, or at least a modified one, with a new DSR specific to your needs.  It would talk to a PI, possibly cabled up to one that may already be a TIPI/PI combo on the other GPIO pins.  The other direction is to rewrite the python code and wipe out the PI code that interfaces to the TIPI to do your "new stuff" with video.

 

It may not be so much as hardware as just writing new software...…… from scratch.

  • Thanks 1

Share this post


Link to post
Share on other sites

If it could be done with just software on the existing TIPI units, that would be very nice.  To be clear, I was thinking mainly a text screen to make writing code easier.  It would then require modification of the programming language to send text to the alternate screen.  You could then edit code, run it to see the output on the TI, edit again, etc.  another use for it might be to create graphics for the TI.  You could enter commands on the alternate screen and have the graphics change on the composite screen immediately.  I would think this would speed up development a lot.

  • Like 1

Share this post


Link to post
Share on other sites

I still think that the existing setup, with the "Dummy network pipe" we have for telnet and pals, would work just fine as a transport for X server messages.  That's principally just bytecode instructions being sent over the wire already.

 

https://www.x.org/releases/X11R7.6/doc/xproto/x11protocol.html

 

If the TI learns to speak X, you can draw whatever the hell you want on the PI, using existing libraries.

  • Like 1

Share this post


Link to post
Share on other sites
3 hours ago, Asmusr said:

That's cute, but back in the day I recorded my NES composite video directly into the line-in on my boombox, and my video was nearly as watchable as his with no effort at all. ;) (Nearly because the sync signals were pretty much non-existent, so it slipped all the time, and definitely would not play on a modern device).

  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...