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

[+jedimatt42]

"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

 

We've used a PI 3 to date. The PI side code is all python so far. Although I've started working on a C library for python to get some signalling performance back. I want to reduce the number of wires to the PI's GPIO, but that means more GPIO operations, which turns out to get slow. Khz in python, instead of Mhz in C...

 

-M@

[Omega-TI]

Hi Corey,

Could you please label the three items in the photo. Also, will this really ALL be in one package upon completion?

 

[+jedimatt42]

Since that photo is from my hardware, I'll go... ( Did you get a closeup of Corey's wire wrap edition? )

 

A - a Raspberry Pi breadboard adapter. This is called a PI Cobbler.

B - a Mojo FPGA dev board, the big chip is a Spartan 6 LX9 (this will not be in the final version)

C - a Raspberry Pi 3

 

Will it fit? Sure. Except the Raspberry Pi.

 

The parts on the breadboard are gross overkill for this project. The FPGA is effectively 1000 logic chips, and a pile of RAM. I'm using it to prototype an eprom 2 latches, 2 shift register, a flip flop for a crubit, and the address decoding logic. That all gets expressed in verilog.

 

Other chips on my breadboard are logic level converters. 5v to 3.3v where needed.

 

A CPLD such as what is on the FinalGROM99 is more than capable of replacing all my chips and the FPGA, except it doesn't have RAM built in. So we'll use the CPLD, and an EPROM.

 

I'm working on reducing the pin count to the Raspberry Pi, so we can use a small package CPLD.

 

And then I want to include a 74'244/5 to act as a logic level converter heading back into the 4A's data bus.

 

So, 3 chips, some LEDs, a connector to attach to the 32k board, and a small ribbon connector out to the Raspberry Pi.

 

I do not intend to attach the PI 3 directly.. the PI 3 needs cables like USB power and optionally ethernet and it would be awkward to attach and use the USB power. So I want to keep that on a flexible ribbon cable.

 

The PI cobbler is 40 pins, but I only really need 8. (Based on theoretical design I wrote down last night)

 

-M@

[Omega-TI]

I like the idea of a plug-in board to the side of your 32K card and the RPi being on a cable plugged into that.

I've never needed, owned or used a RPi before, but this project is so exciting and shows so much promise for the future that I have bite the hook!

[+jedimatt42]

I've been working on a few internal things:

 

Updating schematic toward what a production board should be. I hate KiCad usability, I love KiCad's availability.

 

C library module for python, to handle the GPIO directly. This boosted my send rate to the TI from 4k/sec to 6k/sec.

 

I worked out a second CRU bit, so the DSR powerup routine is actually signalling the Raspberry PI with an interrupt to reset the PI side service scripts everytime the 4A console is back at the title screen. This makes the python side robust... file handles are closed, sockets are closed, cached file contents are freed. Great for a resilient experience.

 

And, I spent a ton of time watching MSX GR8NET videos yesterday, so I finally got off my behind, and implemented opcode 5 ( load program image ) for TIPI.HTTP special file handler. Here's a quick demo:

 

 

-M@

[Shift838]

that is awesome! loading programs from the web directly via TiPi.... Love it...

[+Vorticon]

Are you going to put out some form of documentation for setup and use for the technically challenged?

[Omega-TI]

that is awesome! loading programs from the web directly via TiPi.... Love it...

 

That's slicker than snot on ice! The days requiring PC in the mix to get programs may soon be numbered.

I wonder if a 'new' version of something like DM2K will arrive on the scene shortly afterward that will allow a newbie to directory and download or simply run a program without having to know and type a long URL?

[Omega-TI]

Are you going to put out some form of documentation for setup and use for the technically challenged?

 

I'm hoping for pre-assembled & ready to install myself.

[Sinphaltimus]

So my 2017 wishlist is FG99 and TiPi.

 

Indeed an exciting year.

[Omega-TI]

So my 2017 wishlist is FG99 and TiPi.

 

Indeed an exciting year.

 

Total agreement so far. Of course I also want a WiFi UberGROM when/if they become available assembled for my second system.

My main concern at this point is continued software support for all the varied devices.

[+jedimatt42]

Are you going to put out some form of documentation for setup and use for the technically challenged?

The plan is to print and assemble boards for the technically challenged.

 

For the technically inclined, I'm trying to finalize using a parallel to serial input shift register, so my wiring to the Raspberry Pi is just 8 wires. After that, I'll update the github docs, and clean out the theoretical, in favor of the actual.

 

Mind, the Mojo FPGA dev board is not the target. The target is an Eprom, and a buffer chip, and an xc9572xl qf64 for all the glue.

 

---

 

I need to find an 8 bit parallel input to 1 bit output shift register to model. I made something up in verilog, but my input clocking is goofy. I can tell I have fallen into one of those declarative vs. procedural traps with verilog.

 

-M@

[mmartin]

awesome work congratulations

 

exelent matt !!!! really wish one!

Edited May 28, 2017 by mmartin

[Shift838]

sounds like this project is coming along nicely..

[+jedimatt42]

At the low level I have managed to get the signals to the Raspberry PI down to 8 lines.

 

2 pins - 1of4 register selector

1 pin - data in

1 pin - data out

1 pin - shift clock

1 pin - shift latch

1 pin - common ground

1 pin - cru controlled reset signal

 

By doing this, I might be trading a little speed, for flexibility. But I believe I've recovered the speed by implementing the Raspberry PI GPIO as a C module called from python.

 

This also leaves things like the Raspberry PI standard I2C pins open for little devices, such as this thing I just got in the mail:

 

 

Hoping to augment this so the python code can log status information out to the little OLED display. A little diversion from the otherwise broken heap that I have right now.

 

The communication routines for low level data exchange work right now over the 8 wire setup, but I've broken something else. My mouse pointer demo works, but when I click and draw on the screen, it doesn't draw, instead VDP registers start changing. Maybe I screwed up my copy of the libti99 library... Everything was good until I inserted a LIMI 2 in the mouse demo to try and show that I needed to manage the interrupt state during the DSR. Inserting LIMI 2 was to prove that the interrupt service routine in the console would cause real problems. Unfortunately removing it didn't restore things to a working state... very confusing.

 

I believe I have learned that anytime you are writing code that relies on multiple VDP operations to keep the write or read address incrementers in a sound state, you must wrap in the LIMI 0 ... LIMI 2 setup. ( My mouse demo performs LIMI 0 once, and stays that way )

 

Some where along the lines I removed the LIMI 0 from my actual DSR entry point, and have been incredibly lucky. With that back in place, though, things are still crashing. I suspect I screwed up my timing in controlling when I'm asserting data on the databus, most of my changes were in rewriting all that verilog.

 

So learning how to write the simulation tests will be the next challenge.

[+jedimatt42]

   _____________
  /____________/|
  |    RIP..   ||
  |            ||
  |    You     ||
  | Remembered || 
  | To The End |/
~~~~~~~~~~~~~~~~~~~~
 

SD Card on my Raspberry PI just died...

 

Oh well, plenty more where that came from. But rebuilding the OS image is not what I was hoping to do this afternoon.

 

-M@

 

[+arcadeshopper]

It works....

 

Sent from my LG-H830 using Tapatalk

[+arcadeshopper]

Until it doesn't!

 

Sent from my LG-H830 using Tapatalk

[Shift838]

   _____________
  /____________/|
  |    RIP..   ||
  |            ||
  |    You     ||
  | Remembered || 
  | To The End |/
~~~~~~~~~~~~~~~~~~~~
 

SD Card on my Raspberry PI just died...

 

Oh well, plenty more where that came from. But rebuilding the OS image is not what I was hoping to do this afternoon.

 

-M@

 

 

 

I have experienced SD card corruption. I have found that the Pi does not like it when you just simply turn it off. You must do a nice shutdown. It seems after many times of just cutting the power the SD card gets corrupted. I then have to throw my image back on it. Since then, I just putty into it and do a sudo shutdown command. I have not had any more issues since I started shutting it down via console (about 9 months ago).

[+mizapf]

I think I read somewhere that SD cards do not have wear leveling like SSDs. This would mean that journaled file systems pose a considerable threat to the SD lifetime.

 

As for the shutdown, sure, this is a full-blown Linux system that has file buffers and write-back caches, so a power-down will likely break the file system.

[+jedimatt42]

I was just editing code on it over ssh, saved the file, and bam, lost network connection to it.

 

I'm rolling log files like crazy. Too much debugging output.

 

I'll have to look into wear leveling, and adjust my default logging... Maybe linux still supports a ram disk...

 

-M@

[+jedimatt42]

http://www.zdnet.com/article/raspberry-pi-extending-the-life-of-the-sd-card/

 

For my own future reference.

 

-M@

[+jedimatt42]

TIPI update, or "How I spent most of my 4th of July weekend":

 

I have spent the better part of June futzing around with a flaky broadboard trying to verify that the reduced wiring model to the Raspberry PI will work. I'm convinced it does.

 

So I've started on pcboard layout. First go at a layout and routing looks like this:

 

 

I'm fairly certain, that I'll have to basically do it all over again I think the CPLD footprint is going to be too small. Not 100% sure the size of the part. So I've ordered parts, and will do a fitting on paper.

 

I also need to read the spec on the JTAG interface. I've seen it done without pull-up resisters, and I've read that they are advised. I've also read that they are built into the CPLD... so I'll need to clarify that.

 

Corey wanted extra LEDs for debugging... but there are only 4 I/Os on the CPLD unused. I have brought them out to solder pads instead.

 

I've wired the TI external interrupt to the CPLD, just in case we want to do interrupt work in the future. But so far all of the things I've demonstrated do not require TI interrupt handling.

 

I'm aiming at a 32k eprom with CRU based bank switching.

 

Other things wrong with this pcboard layout:

Overall size doens't match my 32k board.

via's are too small for my comfort

header drill sizes are too small for my comfort - with the 32k board, I started having trouble getting the headers in on some prints... inconsistency in the plating I suppose.

I expect to find I do need 4 pull-ups on the JTAG port.

I need to migrate the verilog to a new project targetting this chip instead of my FPGA. And verify that my pin assignments are satisfactory.

 

Something that is nice about working with the CPLD, is that I can just untangle traces by re-assigning pins... This is true of the Raspberry PI connection as well. If this wasn't the case, I'd have gone nuts...

 

Once I get parts, to test fitting, I'll have to scrap this, and start over. but with a good idea of how to route. And then once Corey and I have hardware, there is a ton of software work to do still.

 

I have a side project that I'm working on with SMD parts, so I can practice.

 

-M@

[Shift838]

Once you get this perfected are you planning on making a PEB card version as well. That would be great if so, so that not only 99/4A PEB users could take advantage of it but maybe even Geneve users ?

[+jedimatt42]

I intend to make a PEB version. I've avoided using signals on the sideport that are not present inside the PEB so it relocates more easily. RDBENA signal should be the only extra thing to drive, and the same or inverse of my control of the on board buffer.

 

Anyone have a KiCad template for the PEB card? I have the docs/dimensions/specs, but if anyone has already done the EDA work, it would save me a day of my life.

 

I have to figure out how to actually measure my 32k board outline and measure parts placement for this...

 

As for the Geneve... Master DSR is going to make that a pain. The Level 3 access to special files isn't going to work as I understand it because they don't translate down to the lowever level sector IO.

 

But, I'm sure I will try... I have a Genmod Geneve, and DSK1 of the TIFDC doesn't work in ? DSR/ROM-MAP mode ? so I doubt I'll succeed. Unless I can come to understand that. Michael has said I need to add decoding of AMD & AME address lines. But All of the Genmod documentation says otherwise.

 

I started the 32k project as a step to learning how to build this sort of thing, so that eventually I could build storage for my Geneve. That is still the long term goal.

 

-M@