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

[+arcadeshopper]

I have Ubers if you need one lmk

Thanks, I don't believe there is anything about PALEA5 that is at issue.

 

I suspect it is just the attempt to load a 4ADOS script before the tipi.service has rrstarted. I suspect that the load starts then the service gets terminated in the middle, and we're hung.

 

I don't have an ubergrom to test with... We'll see what I can do to reduce the race condition window.

 

-M@

Sent from my LG-H872 using Tapatalk

[Omega-TI]

Thanks, I don't believe there is anything about PALEA5 that is at issue.

 

I suspect it is just the attempt to load a 4ADOS script before the tipi.service has rrstarted. I suspect that the load starts then the service gets terminated in the middle, and we're hung.

 

 

 

I pretty much agree with that assessment. You should hear the racket that happens when you try to execute a lengthy batch file after a reset or cold boot! I was able to overcome that with a very short batch file, but it does support your suspicion.

[Omega-TI]

@Jedimatt42

 

I have a question concerning the P-Box version of the TIPI...

Is it known what the "maximum functional length" for the cabling between the TIPI card and the Rpi can be?

The reason ask is due to the layout of my system and the need to hide cables. I imagine others may have this concern as well.

As an example, for me, the optimum would be 3 feet, but I could 'get by' with 2^1/2. Doable?

 

@Arcadeshopper

 

If these are going be sold through you, are there plans to offer a couple of selections when it comes to length on the ordering page?

 

-- putting the cart before the horse (thinking ahead)

[+jedimatt42]

@Jedimatt42

 

I have a question concerning the P-Box version of the TIPI...

Is it known what the "maximum functional length" for the cabling between the TIPI card and the Rpi can be?

The reason ask is due to the layout of my system and the need to hide cables. I imagine others may have this concern as well.

As an example, for me, the optimum would be 3 feet, but I could 'get by' with 2^1/2. Doable?

 

@Arcadeshopper

 

If these are going be sold through you, are there plans to offer a couple of selections when it comes to length on the ordering page?

 

-- putting the cart before the horse (thinking ahead)

 

 

You all have zero need to be able to see the PI during operation. If you do, it is a bug, and we should fix it. I very much regret leaking pictures of my debugging OLED display. I'm going to tack the PI on the back of the PEB and forget it is there. I would recommend you stick with the little cable that I've tested with... here is why:

 

PSA - TO ALL OBSERVING: I HAVE ZERO EDUCATION IN ELECTRONICS.

 

I charge ahead, and things work.. if it works, I don't need to learn anything more... If it doesn't work... I need to learn more. I am a software engineer. I have a tendency to forget that digital electronics are an analog art, using ranges of voltage to indicate 2 distinct states.

 

Saturday I learned why there are resisters in the PEB flex cable. I've heard of 'ringing' and 'reflection' and I've observed my 20 cm cable to not create ringing that makes the 2 states ambiguous.

 

I haven't implemented any of the lines you want to extend as 'transmission lines' -- they are luckily unidirectional. I suspect that is getting me a free pass. The PI is made for idiots to succeed. I suspect that is getting me another free pass.

 

When I hooked the PEB card up to the PI 3, the data line from the CPLD to the PI's GPIO became ambiguous... I added a 10k ( small current ) pull up to that, under the theory that the CPLD couldn't drive the distance, but with the resister driving, all the CPLD has to do is bring it to 0 when it wants. How did I know to do this? I've been building an MSX computer from kit, and original design has an issue in this arena. Do I know where this resister should ideally be located? Nope. So I put it where it was easiest to apply as a hack. And that worked. So I updated the PCB layout to include it in the same manner.

 

OMG, electronics is actually physics... I was an aspiring software developer in high school / college, I payed enough attention in physics to calculate the effort required in the class to get a 'C'..

 

I am entirely unqualified to answer questions about length of cable. Other than I have tested 0 cm with the PI Zero W, and 20 cm with the PI 3. I suspect that if I properly designed this as transmission lines I could speed up the interaction between the PI and the CPLD. But what I have works for what I wanted it to do at 0 and 20 respectively.

 

I did recently by a book, but it suggests most of it doesn't matter below 10mhz. I should calculate the speed between the PI and CPLD, it could easily be peaking over 10mhz... I have a software control on that, and we know with shorter signalling delays, it gets messy.

 

I suspect longer cabling could ruin the CPLD or the GPIO on the PI over time. But that is FUD.

 

Anyone still want a TIPI ? LOL...

 

-M@

[+arcadeshopper]

We'll be selling them with the default cable I believe. You can wire whatever you want at your own peril

 

Sent from my LG-H872 using Tapatalk

[Omega-TI]

 

 

You all have zero need to be able to see the PI during operation.

 

Just curious, when did NEED have anything to do with a hobby? I simply like adding gadgets to my TI, the more the merrier!

 

I have found the display useful though, as I have the LED on the TIPI.

[ElectricLab]

Pull-up resistors aren't meant to supply current so much as to prevent a signal line from floating between states. The devices in use with TIPI are high impedance and don't source or draw much current - they're suppose to detect +5 (or 3.3v) and ground for its two states. Putting pull-up resistors in a signal line help prevent floating voltages and helps preven interference from causing voltages in between and causing mis-reads.

[+jedimatt42]

ElectricLab makes my point for me.

 

-M@

[+Vorticon]

 

 

PSA - TO ALL OBSERVING: I HAVE ZERO EDUCATION IN ELECTRONICS.

 

I charge ahead, and things work.. if it works, I don't need to learn anything more... If it doesn't work... I need to learn more. I am a software engineer. I have a tendency to forget that digital electronics are an analog art, using ranges of voltage to indicate 2 distinct states.

 

 

Yup, that pretty much sums it up for me, minus the software engineering bit as I don't even have that Come to think of it, I'm actually flabbergasted that I have managed to get anything to work at all in the past... You've got to love this hobby

[+jedimatt42]

I've been doing 'upgrade' testing/fixes.

 

The upgrade process takes around 6 minutes on my PI Zero W, and around 30 seconds on the PI 3. This varies based on network as well, since it downloads from several locations.

 

I have fixed the TIPICFG tool to wait a few seconds and then poll register RC in the TIPI chip. That register is set to 0xFF now when the upgrade process starts. And it is cleared after the services are restarted.

 

To improve end user patience, I put spinners on the screen, and during the polling I flash the LED in a satisfying way. On for 8 vdp interrupts, and then off for 7. The prior routine wasn't locked up during the long upgrade. It was just polling inside a DSR request that appeared locked up due to the lack of blinky-blinky.

 

Unfortunately you have to upgrade first to get the upgrade. I can imagine ways to solve that, but it isn't worth it.

 

I have also applied the visible polling process to the PI reBoot option, also.

 

There was also a problem with the post-upgrade script, in that it didn't stop services esrly enough. So the tool saying: press R to reload was giving a false sense of completion. During this next upgrade, services are stopped much earlier. Please wait at least 19 seconds before pressing R. Then wait until it completes. There will be no feedback. On a PI Zero there are several long delays with no apparent flash card activity... It isn't hung, it is working. The TIPI light will be on if you've pressed R.

 

I will prepare a pre-upgraded sd image as well.

 

Fixes will include:

 

* Update to ElectricLab's TipiVariables in support of future chatti updates.

* Upgrade process improvement

* TI powerup routine reset reliability improvement

 

After we delight in the upgrade process improvement, I'll tackle some of the pending webui work.

 

-M@

[+jedimatt42]

It is up there.

 

-M@

[Omega-TI]

You know, I've been thinking again...

 

Since the TIPI is on and running 24/7, it would be interesting if there was a program on the RPi side that would poll the server once per hour. If the user had a Chatti message, or if it were their move in chess, they could be informed by the I2C display. Even if it was just a blinking dot, or maybe even the letter "M" for a Chatti message or the letter "C" for the Chess game it would ensure more traffic and fewer waits.

[+jedimatt42]

You know, I've been thinking again...

 

Since the TIPI is on and running 24/7, it would be interesting if there was a program on the RPi side that would poll the server once per hour. If the user had a Chatti message, or if it were their move in chess, they could be informed by the I2C display. Even if it was just a blinking dot, or maybe even the letter "M" for a Chatti message or the letter "C" for the Chess game it would ensure more traffic and fewer waits.

 

You might as well just send each other SMS's at that point...

 

How about a user interrupt service routine that runs in the background in TI XB or your "Disk Operating System" that occasionally fetch the Chatti status, and flashes a number in upper right corner of the 4A's screen? Then at least you are still using the TI. Keeping the knowledge of Chatti in the TI space and out of the TIPI space. That would be cool... getting a PI to do it has no challenge. And is just more programming that isn't for the 4A.

 

I also don't think it would have a great impact toward the outcome you desire. If Atariage never existed, maybe...

 

-M@

[Omega-TI]

 

You might as well just send each other SMS's at that point...

 

 

Sorry, I did not mean to irritate or cross a line. I figured a status message would not be 'too far out-of-line' as it would require the TI user to actually use their TI to read the message or make a move. I don't leave either my PC or my TI on 24/7, but I do my Pi. I've noticed some users never seem to check their TIPI messages, while others can take days to make a chess move. From my point of view it gets boring logging in multiple times... only to find out nothing has happened... a status indicator might get their attention and prompt them into action. I guess it's not to be.

 

Sure, a little E/A 5 program that I could run from DOS to check status would be very cool, but I'm not going to suggest anyone do anything. The principal parties that would know how to obtain that information (you and Corey) already have your hands full.

 

I'll be going into lurker mode now on this topic.

[+jedimatt42]

Important message in the support thread:

 

http://atariage.com/forums/topic/277635-tipi-usage-and-support/?p=4047770

 

-M@

[jjh76]

What is the cheapest windows 10 compatible burner that will work for upgrading the dsr?

[+jedimatt42]

The eprom used is a 27C256.

 

To find the cheapest you'll have to sort ascending by price, and check for compatibility with that chip.

 

Most people find the 'mini-pro' tl866 sufficiently cheap.

 

-M@

[+jedimatt42]

I tested a TIPI in my Geneve yesterday. I have a Genmod Geneve, with v1.00 genmod version boot rom.

 

I had full AMA-AME decoding enabled on the board, despite Genmod instructions only indicating the need for AMA-AMC.

 

With the DSR ROM installed in the board, even with the CRUBASE set to >1800 (far after the TIFDC's >1100), the Geneve would not even boot off of the TI Floppy Disk controller.

 

With the DSR ROM removed from the board, I was able to go into Minimemory in GPL and read/write to the crubits, as well as the memory mapped latches.

 

The latter means custom software written for the Geneve should be able to use the TCP/IP services of TIPI. However, existing 4A software that uses those services expects the message code to be in the DSR, and determines the CRUBASE by scanning DSRs. So CHATTI, TELNET, SNEK, and anything using the BASIC extensions will not work on the Geneve.

 

Using a TIPI on a Geneve ( to my ability to test ) is only for those willing to write all their own software and/or OS extensions.

 

That is the end of my ability to test, and so the end of my ability to speak about the TIPI and Geneve.

 

The community is free to learn and share other information and support the Geneve themselves.

 

-M@

[+InsaneMultitasker]

What device names and subprograms were present in the TIPI EPROM that was installed? What do you mean by, "the Geneve would not even boot off the TI floppy disk controller" - lockup? no access to the TI controller or something else?

 

The boot eprom first looks for the horizon ramdisk by checking for a device starting with "HD". If found, it looks for subprogram >10 and if found, ramdisk boot code is executed.

 

Next the boot eprom looks for device WDS starting at CRU 0x1000. If found, it looks for device DSK1 on that same CRU. If THAT is found, LOAD/SYS is loaded via opcode 0x07.

 

If neither the ramdisk or wds (hfdc) device are found, the final test is for the boot eprom to detect a controller at 0x1100 then determine which low level routine to use.

 

My guess at this point is your TIPI EPROM has a WDS device name in its linked list, the boot eprom finds DSK1 on the TIPI cru, then hangs or does some other weird thing. You might want to try a TIPI EPROM with just TIPI in the device name list. Then you can determine (1) will the Geneve boot with TIPI in the system when there are no unexpected device name combinations and (2) can you read the TIPI EPROM contents via GPL. (You can do this by placing a value of 0xBA into memory address 0x8002, the memory mapper byte for the 0x4000 page. Assuming Genmod allows that sort of thing.

 

Edit: was missing the word 'no' in item (1) and needed to clarify which eprom I was referring to in a few sentences.

Edited June 13, 2018 by InsaneMultitasker

[+mizapf]

In the last days I rewrote the Geneve mapper emulation in MAME and also checked the description of the Genmod. I was wondering about the AMA/B/C story as well.

 

In order to address a full 2 MiB space, which contains up to 2^21 bytes of memory, you need 21 bits. Accordingly, AMA/B/C will not suffice; these are just 3 additional address bits to the existing 16 bits. This allows for 2^19 = 512 KiB.

 

...

 

I just had a closer look. The Genmod document tells you to solder a wire to pins 8 and 9 of the Geneve edge connector; these are SCLK and /LCP, typically unused, and here used for AMD and AME. So they are actually using them, but don't call them AMD/AME.

 

The only issue remains with the peripheral cards. If they do not decode AMD/AME, they will show up four times in the address space (for AMD/AME = 0/0, 0/1, 1/0, 1/1). Maybe they did not consider it an issue?

[+9640News]

Which eprom version are you using with your GenMod Geneve?

 

The only other thing I could think to suggest, to confirm no decoding issues, is to run MEMTEST to make sure there are no pages with errors. With a GenMod, no pages at >3A and up to >FF should have been tested as the GenMod stock eprom was modified for the GenMod. Still, running the MEMTEST program would confirm no memory issues that could have caused the system to fail.

 

Beery

[+9640News]

 

The only issue remains with the peripheral cards. If they do not decode AMD/AME, they will show up four times in the address space (for AMD/AME = 0/0, 0/1, 1/0, 1/1). Maybe they did not consider it an issue?

 

Ron did consider this and that was why a number of cards required modification. If someone had the GenMod package, and ran Memtest, they would see if there were bad memory pages at >3A, >3C, >7A, >7C, >BA, >BC, >FA, >FC. I think page >BA was already mapped out, and not 100% sure if pages from >F8 to >FF were useable. They may be good memory, but may not be useable. I know you would never want to use page >FF as that was the page referenced when no memory was mapped because you had to have something in the mapper.

Beery

[+jedimatt42]

What device names and subprograms were present in the TIPI EPROM that was installed?

See the TIPI wiki for a list of device names: https://github.com/jedimatt42/tipi/wiki/Devices

 

subprograms: I suspect you are asking about level 2 IO routines: >1x, except the first that is sector read/write, as shown here: https://github.com/jedimatt42/tipi/blob/master/hardware/dsr/dsrlist.a99

 

 

What do you mean by, "the Geneve would not even boot off the TI floppy disk controller" - lockup? no access to the TI controller or something else?

I had the crubase of the TIPI board set to >1800 so it should be clear of any DSK1 device search ( since my TI FDC is at >1100 , and is installed, and normally works )

 

With the TIPI at >1800, and the DSR installed, the TI Floppy controller light turns on, selects the SYSTEM/SYS (if I recall correctly) file, but it never reads a track per the little display on my gotek drive.

 

The boot eprom first looks for the horizon ramdisk by checking for a device starting with "HD". If found, it looks for subprogram >10 and if found, ramdisk boot code is executed.

 

Next the boot eprom looks for device WDS starting at CRU 0x1000. If found, it looks for device DSK1 on that same CRU. If THAT is found, LOAD/SYS is loaded via opcode 0x07.

 

If neither the ramdisk or wds (hfdc) device are found, the final test is for the boot eprom to detect a controller at 0x1100 then determine which low level routine to use.

 

My guess at this point is your TIPI EPROM has a WDS device name in its linked list, the boot eprom finds DSK1 on the TIPI cru, then hangs or does some other weird thing. You might want to try a TIPI EPROM with just TIPI in the device name list. Then you can determine (1) will the Geneve boot with TIPI in the system when there are no unexpected device name combinations and (2) can you read the TIPI EPROM contents via GPL. (You can do this by placing a value of 0xBA into memory address 0x8002, the memory mapper byte for the 0x4000 page. Assuming Genmod allows that sort of thing.

 

Edit: was missing the word 'no' in item (1) and needed to clarify which eprom I was referring to in a few sentences.

There are no HD devices in the TIPI DSR ROM, and no WDS devices. WDS only shows up if one of the other crubits on the board is 'set'. It is 'not set' by default.

The POWERUP routine on the board does appear to execute as I do see it reset the TIPI services on the PI.

 

Someday when I am bored, I'll give that a try... I believe we went through the same process when I couldn't get ROMPAGE to work with my TIFDC but I could see the TIFDC DSR ROM.

 

Which eprom version are you using with your GenMod Geneve?

 

The only other thing I could think to suggest, to confirm no decoding issues, is to run MEMTEST to make sure there are no pages with errors. With a GenMod, no pages at >3A and up to >FF should have been tested as the GenMod stock eprom was modified for the GenMod. Still, running the MEMTEST program would confirm no memory issues that could have caused the system to fail.

 

Beery

What it says on the screen is "v1.00" ... "genmod version"

 

I can maybe test that with the DSR pulled... with the TIPI board installed there should be 2 bytes that fail to retain a value written to them.

Normally memtest indicates I have 1900000ish bytes of ram. Someday.

 

----

 

My priority is getting this project working on the 4A. I'm really not interested in the Geneve in GPL mode. And getting TIPI to work in MDOS is an OS rewrite. So this is an extremely low priority for me.

 

Maybe it will just work on a normal Geneve. Maybe it is just tripping over my 150ns eprom. Maybe the propagation delay on all the logic in the CPLD is too slow.

 

Anyway, all the design files and software are up on github. If you want something like TIPI to work, dig in.

 

My original point stands: I cannot (am not able to) offer any support for the Geneve. I believe I have confirmed that I do not have a known working platform like yours to test in and develop in.

 

-M@

[+InsaneMultitasker]

Interesting problem with a sprinkling of deja vu for me, alas I can't remember the situation. Too many years ago. Your device page doesn't list the WDS device names but I knew they existed somewhere/somehow, hence my train of thought. I think we've always known the TI is the target, so no surprises there. I'm sure a few AA participants will want to play/test when the PEB cards are available. My free time is very limited from now through October, so I won't be digging into anything new for some time.

[+9640News]

Please keep in mind my thoughts with the Geneve were the possibility of using it in GPL mode under Rompage so that it would use TI-99/4A programs. That would require no MDOS updates, etc. Any programming on the MDOS side would be trying to understand the communication I/O when using the TIPI DSR.

 

Beery