Jump to content
IGNORED

TIPI - TI-99/4A to Raspberry PI interface development


Recommended Posts

Fascinating project! This would essentially eliminate the need for an IDE card or a RAM disk or even an entire PEB... It would also likely minimize the need for the ever elusive NanoPEB as long as a sidecar 32K RAM device is attached. Paradigm shift...

  • Like 1
Link to comment
Share on other sites

I'm avoiding disk image tech, except to make it easy to import.

 

Something else to consider, is the power of the linux host filesystem. Your media can be a mounted NAS, or the Raspberry PI can share filesystem through samba. And then you can continue to manage things with existing tools like Ti99Dir, to deal with .ark files, and .dsk images...

 

Here my tipi folder is mounted as T: on my primary PC.

 

post-42954-0-84463700-1494099118_thumb.jpg

 

But of course the other way around would work also, with different lifecycle concerns.. but, whatever work you. USB thumbdrives, CF adapters, USB CDROM, USB FLOPPY...

 

And that's just a piece of it. When the Fest West presentation gets online, you'll see the more exotic use cases that ElectricLab has built around this.

 

-M@

Link to comment
Share on other sites

 

Sockets for the DSR Eprom, on either board. :) So we can keep that simple, and updates accessible.

 

Do you envision a DSR EPROM that can be programmed directly from the board/DSR or via the pi? Will all of the DSR live on the card or will you just have a stub on the board that will load the DSR from the pi as needed?

Link to comment
Share on other sites

Do you envision a DSR EPROM that can be programmed directly from the board/DSR or via the pi? Will all of the DSR live on the card or will you just have a stub on the board that will load the DSR from the pi as needed?

I don't want to add 3 months of development time to this, so I'm thinking straight up DSR in EPROM.

 

Architecturally... tons can be added by just extending the python scripts.

 

The mouse demo, required no change to the DSR... doesn't actually use the DSR at all.

The special files, TIPI.DSKMAP, TIPI.STATUS, TIPI.CLOCK, TIPI.HTTP://... TIPI.TCP, all of those were added without having to edit the DSR ROM.

 

TIPI level 3 IO works for all device names, by calling the same assembly routine. This routine copies the PAB, and the full device name to the Raspberry PI. Once it is there, I look up a python object that will handle the devicename based on a prefix match.

If I find something that matches, then that object takes over. If I find nothing there, then I fall back on the file system handler.

 

For mouse, I send a truncated PAB that is just >20, the opcode. And that code being an illegal PAB opcode is used to lookup a low level hander, that in this case just responds with 3 bytes of mouse detail.

 

I'm working on getting the level 2 IO structured similarly. So in theory then we can implement them without changing the DSR. I might error on sending the entire scratchpad FAC space. I don't know... I need to map that out still. Each level 2 item has differing parameters.

 

I'm thinking that TCP should be available in the same way as mouse. Send a code, to get a script in control of the memory mapped I/O, and then hang out there until it releases itself, or the powerup routine runs again.

 

ElectricLab's game uses a mechanism that wants to take control like this. I would like to call this kind of thing 'tinker mode' :)

 

Anyway, enough people have eprom programmers, and having to change the eprom is proving to be pretty seldom. I thought about using a serial flash memory chip, and letting the board present that to the 4A as normal parallel rom, and having the RPi able to program it. But I think I want to get off the breadboard earlier than that. And I have doubts about how necessary that would be.

 

I might want to design a solid 4A to Mojo FPGA adapter to keep ease of DSR development up, and enable future hacking on other projects. But that is going to be driven by pain if it happens.

 

-M@

  • Like 3
Link to comment
Share on other sites

Very nice. And thank you, that helps to clarify things :)

 

I wasn't sure what approach you were taking with respect to the DSR, i.e., EPROM, flash, RAM, etc. At Cecure, I used to dump the DSR into RAM, using one CRU bit to flip between ROM and RAM, and one bit write-protected the RAM, if needed. Not sure if that would be useful here or not.

 

Opcode >20 is valid for hard drive sector IO (level 1) so you might run into some conflicts there, if I understand your statement correctly.

 

One extension that might be helpful down the road is allowing for CPU RAM pabs and buffers. I don't know that many people make use of this in the cards that support it, but it does lend itself to a little more speed during heavy DSR activity and is especially helpful when loading a lot of records or image data. This usually involves setting a high order bit to flag as CPU versus VDP.

Link to comment
Share on other sites

Very nice. And thank you, that helps to clarify things :)

 

I wasn't sure what approach you were taking with respect to the DSR, i.e., EPROM, flash, RAM, etc. At Cecure, I used to dump the DSR into RAM, using one CRU bit to flip between ROM and RAM, and one bit write-protected the RAM, if needed. Not sure if that would be useful here or not.

Always good to hear workflow tricks to make development easier. I will keep that in mind.

 

Opcode >20 is valid for hard drive sector IO (level 1) so you might run into some conflicts there, if I understand your statement correctly.

I'll probably restructure so that the first byte identifies the type of communication: PAB, SUBPROGRAM, TINKER, and then the second byte for Level 3 would be the PAB leading with the opcode. etc, etc... This way community extensions don't have to worry about clashing with disk mechanisms.

 

One extension that might be helpful down the road is allowing for CPU RAM pabs and buffers. I don't know that many people make use of this in the cards that support it, but it does lend itself to a little more speed during heavy DSR activity and is especially helpful when loading a lot of records or image data. This usually involves setting a high order bit to flag as CPU versus VDP.

I have heard of this... This should be easy... I have 2 variety of send and receive message routines in the DSR, one for buffer in VDP, and one for buffer in CPU RAM. This isn't spec'ed in the TI documents. Do we have documents on how this addressing works? I can imagine, that if the high bit is set, the RAM must be in the upper 32k memory expansion. Do we just not allow the buffer to be in the lower 8k expansion?

 

I already have the messaging into CPU RAM, so that I can receive small messages right into workspace registers.

 

-M@

Link to comment
Share on other sites

It'll be good for us to overview all of what Myarc did from a feature set point of view... I for one, have never had a 'harddrive' on my TI before. This link below has what looks like the latest version of the docs InsaneMultitasker illustrated:

 

ftp://ftp.whtech.com/datasheets%20and%20manuals/Hardware/Myarc/MYARC%20HFDC%20Manual%204th%20edition.pdf

 

-M@

Link to comment
Share on other sites

A little project background cause I like that sort of thing:

 

This project has been a collaboration between ElectricLab and myself since December 31st 2016. He sent me a PM after posting: http://atariage.com/forums/topic/260513-ti-interface-proof-of-concept/?hl=%2Belectriclab&do=findComment&comment=3661283

 

He showed us his KnightRider/KITT demo, and I had to reproduce the effect. It was too fun... Not long after he had the thing talking to the GPIO pins on the Raspberry PI, and had soft-leds going back and forth in the PI's console with a python script.

 

I think, our first meet up with that hardware running, we worked from 8pm to about 3am, tired punchy, getting a little comms program written in MiniMemory BASIC, using CALL LOAD to control sending data, by the time we realized it was stupid late, we had a BASIC program that would let us type away on the TI keyboard (CALL KEY style) and the text would show up on the TI screen and remotely on the PI's console. Backspace (Alt-S) and Enter were supported and wrapping... and it was just fun, but pointless.

 

The first version of the communication protocol, we knew wasn't viable, but was strickly timing dependent... we had one 8 bit output channel. Set to a character value, wait a moment (CALL SOUND) set to 0x00 then wait a moment again...

 

Later we both developed handshaking protocols, using signalling lines separate from the data lines.

 

At a peek, we've both seen ~8K/sec transfers. This was pretty exciting.

 

I have since changed the RPi -> TI data ports to use shift registers, and added error correction because my breadboard drives me nuts. However, today I've instrumented it, and found that has cut my transfer rates in half... about 4k/sec.

 

-M@

  • Like 3
Link to comment
Share on other sites

Simply AMAZING!

 

I for one would love to see a PEB card as well. That would be awesome. I would buy a couple...

 

So, if using a DSR with the TIPI for disk access I am also wondering if a DSR for a Serial port or 2 could be worked in somewhere to allow the TI to recognize a USB Serial device as RS232/1 and RS232/2 if plugged in to the Raspberry.

 

I development for the TI-99/4A by the dedicated TI'ers never cease to amaze me. Yet another reason I love this machine.

  • Like 3
Link to comment
Share on other sites

 

I guess this was the nickname of the nickname of the 99/8, which was "Armadillo".

 

 

It'll be good for us to overview all of what Myarc did from a feature set point of view... I for one, have never had a 'harddrive' on my TI before. This link below has what looks like the latest version of the docs InsaneMultitasker illustrated:

 

This is the version that I produced by OCR of the original manual, reviewing it for errors, and incorporating the latest changes.

  • Like 3
Link to comment
Share on other sites

...

So, if using a DSR with the TIPI for disk access I am also wondering if a DSR for a Serial port or 2 could be worked in somewhere to allow the TI to recognize a USB Serial device as RS232/1 and RS232/2 if plugged in to the Raspberry.

Other than some BASIC programs, it doesn't seem like anything that uses RS232 uses the DSR for communications. There won't be a 9902 on board, so it just wouldn't be compatible with much of anything. Getting serial devices on the PI accessible sounds great, but I'd stick with Level 3 IO. And at that point, is there a benefit to calling it "RS232/1" ?

 

I'd rather let you do that through special file support.

 

That got me thinking, the DSR entry for special files should be renamed to something other than 'TIPI' so they don't collide with actual files.

 

-M@

Link to comment
Share on other sites

that's right. I was not evening thinking there was not a 9902 on board. You are right. of course. Still the DISK IO access is a huge leap. The PI is showing more and more use cases for all types of projects!

Basically with direct disk and tcp access who needs serial?

 

Sent from my LG-H830 using Tapatalk

  • Like 3
Link to comment
Share on other sites

I've got a 994/a PCB built into an old internet fire wall case and I'd ultimately love to have everything self contained in the box without having to use a monstrous PEB, if this can be used for file storage that would be perfect! I've already got a Unbuntu, Retropie box, Windows 10 and Windows 7 machines on my desk, adding a TI will be icing on the cake!

Edited by Tornadoboy
Link to comment
Share on other sites

I've got a 994/a PCB built into an old internet fire wall case and I'd ultimately love to have everything self contained in the box without having to use a monstrous PEB, if this can be used for file storage that would be perfect! I've already got a Unbuntu, Retropie box, Windows 10 and Windows 7 machines on my desk, adding a TI will be icing on the cake!

 

I did an All In One 99/4A with PEB and all very recently. You can read all about it HERE with final pictures at the end of the thread.

  • Like 1
Link to comment
Share on other sites

"TIPI", I like what's happening here, looking forward to it. Will this work with a raspberry Pi 3, and could the code be ported to a beaglebone? Thinking out loud, don't know anything about them, but do have two Beaglebones, white and black. I am going to experiment in a few months and see if I can go in the same direction. Cool things going on in the TI community ;-)

  • Thanks 1
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...