Jump to content

Photo

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


71 replies to this topic

#26 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,146 posts
  • Location:Beaverton, OR

Posted Sat May 6, 2017 9:58 AM

Last one from me this weekend... and then back to some experiments :) 

 

 

-M@



#27 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 2,620 posts
  • Location:Eagan, MN, USA

Posted Sat May 6, 2017 10:36 AM

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



#28 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,146 posts
  • Location:Beaverton, OR

Posted Sat May 6, 2017 1:41 PM

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. 

 

Attached File  Screenshot_050617_122510_PM.jpg   139.24KB   3 downloads

 

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@



#29 InsaneMultitasker ONLINE  

InsaneMultitasker

    Stargunner

  • 1,637 posts

Posted Sat May 6, 2017 2:27 PM

 
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?



#30 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,146 posts
  • Location:Beaverton, OR

Posted Sat May 6, 2017 7:11 PM

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@

#31 --- Ω --- OFFLINE  

--- Ω ---

    --- Ω ---

  • 10,086 posts
  • Location:Virgo Supercluster, Gould Belt in the Orion arm of Milky Way galaxy.

Posted Sat May 6, 2017 7:32 PM

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

 

Hey, if it's out in time for Christmas this year I'll be a happy camper!   :thumbsup:



#32 --- Ω --- OFFLINE  

--- Ω ---

    --- Ω ---

  • 10,086 posts
  • Location:Virgo Supercluster, Gould Belt in the Orion arm of Milky Way galaxy.

Posted Sat May 6, 2017 7:34 PM

 

When the Fest West presentation gets online, you'll see the more exotic use cases that ElectricLab has built around this. 

 

 

I'm shooting for no later than 10:00PM Monday.... (crossing fingers)



#33 InsaneMultitasker ONLINE  

InsaneMultitasker

    Stargunner

  • 1,637 posts

Posted Sat May 6, 2017 8:02 PM

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.



#34 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,146 posts
  • Location:Beaverton, OR

Posted Sat May 6, 2017 8:28 PM

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@

#35 InsaneMultitasker ONLINE  

InsaneMultitasker

    Stargunner

  • 1,637 posts

Posted Sat May 6, 2017 8:51 PM

The Myarc HFDC manual documents the PAB and DSR opcode specifications in the latter half of the manual. Here are two excerpts that show how it has been done with the older cards.

 

Attached File  hfdc-lvl2.PNG   38.79KB   3 downloadsAttached File  hfdc-lvl3.PNG   39.29KB   3 downloads


Edited by InsaneMultitasker, Sat May 6, 2017 8:52 PM.


#36 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,146 posts
  • Location:Beaverton, OR

Posted Sat May 6, 2017 10:45 PM

Slightly off topic, but what the heck was a 99/Dillo?   ftp://ftp.whtech.com/datasheets%20and%20manuals/Hardware/DSR%20Choices%20of%20PAB%20Processing%2005-16-1983.pdf

 

-M@



#37 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,146 posts
  • Location:Beaverton, OR

Posted Sat May 6, 2017 10:58 PM

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@



#38 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,146 posts
  • Location:Beaverton, OR

Posted Sat May 6, 2017 11:34 PM

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/...ab#entry3661283

 

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@



#39 Shift838 ONLINE  

Shift838

    Stargunner

  • 1,830 posts
  • SHIFT838
  • Location:Texas

Posted Sun May 7, 2017 12:46 AM

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.



#40 Willsy OFFLINE  

Willsy

    River Patroller

  • 2,977 posts
  • Location:Uzbekistan (no, really!)

Posted Sun May 7, 2017 3:09 AM

This is the one!

#41 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,374 posts
  • Location:Germany

Posted Sun May 7, 2017 5:46 AM

 

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.



#42 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,146 posts
  • Location:Beaverton, OR

Posted Sun May 7, 2017 9:47 AM

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

#43 Shift838 ONLINE  

Shift838

    Stargunner

  • 1,830 posts
  • SHIFT838
  • Location:Texas

Posted Sun May 7, 2017 10:11 AM

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!



#44 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 2,280 posts
  • Location:Portland, Oregon USA

Posted Sun May 7, 2017 10:40 AM

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

#45 Shift838 ONLINE  

Shift838

    Stargunner

  • 1,830 posts
  • SHIFT838
  • Location:Texas

Posted Mon May 8, 2017 5:09 PM

Since it has it's own tcp stack I could see new programs utilizing Telnet and FTP maybe for the TiPi?



#46 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • Topic Starter
  • 1,146 posts
  • Location:Beaverton, OR

Posted Mon May 8, 2017 5:25 PM

I've actually mounted whtech's ftp server on the linux side, and then was able to navigate through it with dm2k. :)

But yes, I would hope to see a world of TCP clients open up.

-M@

#47 Tornadoboy OFFLINE  

Tornadoboy

    Space Invader

  • 48 posts

Posted Mon May 8, 2017 8:55 PM

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, Mon May 8, 2017 8:56 PM.


#48 Shift838 ONLINE  

Shift838

    Stargunner

  • 1,830 posts
  • SHIFT838
  • Location:Texas

Posted Mon May 8, 2017 9:47 PM

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.


  • RXB likes this

#49 --- Ω --- OFFLINE  

--- Ω ---

    --- Ω ---

  • 10,086 posts
  • Location:Virgo Supercluster, Gould Belt in the Orion arm of Milky Way galaxy.

Posted Tue May 9, 2017 7:53 AM

I debated  if should crosspost this here, but since it's on-topic and not everyone reads the other thread...

 



#50 RickyDean OFFLINE  

RickyDean

    Dragonstomper

  • 582 posts

Posted Tue May 9, 2017 9:05 AM

"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 ;-)






1 user(s) are browsing this forum

1 members, 0 guests, 0 anonymous users