Jump to content
IGNORED

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


Recommended Posts

The CPLD is programmed with the exact same image as the sideport TIPI. And the eprom is also exactly the same.

 

The extra PEB signal decoding and rdbena control is handled with the extra chips.

 

So the part that software interfaces with is 100% the same.

 

-M@

Link to comment
Share on other sites

Bad news it takes up 2 slots.

 

Why not do like the Speech Card or Triple tech and make a cut down card that the it sits in the slot within the card.

 

*********** Raspberry Pie *******

*********** Raspberry Pie *******

*********** Raspberry Pie *******

************************************

************************************

Interface slot

Link to comment
Share on other sites

You have to watch out for your PEB variety if you mount the PI inside. Won't work if you have high dividers between you PEB cards at the back.

 

Mainbyte is wrong about which front of PEB has which back. My push button and rocker PEBs both have low backs with external fuse. And we saw a PEB last month that had high backs and an external fuse.

 

-M@

  • Like 2
Link to comment
Share on other sites

The internal TIPI will be the best of both worlds (for me). I'll be able to continue using the specialty hardware in my P-Box, but with the added capabilities of the TIPI, plus it'll help me in my quest for simplification & cord reduction. :)

 

I have a few reasons to keep the RPi outside the P-Box. The first, I have reservations concerning QRM and WiFi signal strength. Second, I'm cheap, so want to share the same RPi between both TIPI units. Third, I already have a customized case coming for it. The fourth reason I'll keep to myself. :P

  • Like 2
Link to comment
Share on other sites

The internal TIPI will be the best of both worlds (for me). I'll be able to continue using the specialty hardware in my P-Box, but with the added capabilities of the TIPI, plus it'll help me in my quest for simplification & cord reduction. :)

 

I have a few reasons to keep the RPi outside the P-Box. The first, I have reservations concerning QRM and WiFi signal strength. Second, I'm cheap, so want to share the same RPi between both TIPI units. Third, I already have a customized case coming for it. The fourth reason I'll keep to myself. :P

 

Fourth reason? Must be a way to hide the porn........ :-D

Link to comment
Share on other sites

Second, I'm cheap, so want to share the same RPi between both TIPI units.

 

If you were cheap, you'd just use the external TIPI with the strange adapter I've told people to forget about, and connect your PEB up to that with the TIPI CRUBASE set to >1000.

 

-M@

Link to comment
Share on other sites

 

If you were cheap, you'd just use the external TIPI with the strange adapter I've told people to forget about, and connect your PEB up to that with the TIPI CRUBASE set to >1000.

 

-M@

My SCSI Hard Drive is at >1000, Corcomp at >1100, PGRAM at >1300, RS232 at >1500

Link to comment
Share on other sites

 

If you were cheap, you'd just use the external TIPI with the strange adapter I've told people to forget about, and connect your PEB up to that with the TIPI CRUBASE set to >1000.

 

-M@

 

I took your advice on the adapter (after your warning) and tossed it. I believe I've taken all of your advice with one exception.

 

Okay, maybe not 'cheap', but how about 'thrifty' (within reason)? I can't bear to part with my P-Box, and some of the cards inside, but I don't like lugging that boat anchor around when I take my TI places. Speaking of taking my TI places, hopefully one of the future usergroup meetings might be a little closer to my place. With a couple of weeks prior notice, I could make arrangements with my work schedule and actually attend, which would be great.

 

Also, what are the available CRU jumper settings for the P-Box version?

Link to comment
Share on other sites

The crubase options for PEB and sideport TIPIs are the same: you have full control of the second nibble.

>1000, >1100, >1200, >1300, >1400, >1500, >1600, >1700, >1800, >1900, >1A00, >1B00, >1C00, >1D00, >1E00, >1F00

The jumper block is from top to bottom:
+8
+4
+2
+1

Add the bits together to get the value you want.

-M@

 

Edit: there are more details here: https://github.com/jedimatt42/tipi/wiki/Design

  • Like 2
Link to comment
Share on other sites

We have confirmed that the TIPI-PEB board does not work in a 'standard' Geneve. So unless you are going to debug it, I advise not buying one with the hopes of it working.

 

The symptom is the same... Even with the crubase up and out of the way >1F00, the Geneve boot process hangs when it should just be booting off a higher precedent device.

 

-M@

Link to comment
Share on other sites

We have confirmed that the TIPI-PEB board does not work in a 'standard' Geneve. So unless you are going to debug it, I advise not buying one with the hopes of it working.

 

The symptom is the same... Even with the crubase up and out of the way >1F00, the Geneve boot process hangs when it should just be booting off a higher precedent device.

 

-M@

 

Hmmm. At least I have the 4A!!!

 

Does anyone recall if the V1.00 boot eprom source was made available for the Geneve? I know eprom dump was made available, just not sure if the source was provided as well.

 

Beery

 

 

Beery

Link to comment
Share on other sites

We have confirmed that the TIPI-PEB board does not work in a 'standard' Geneve.

 

I'm sorry to hear that, I empathize with those that were looking forward to getting one.

 

Not being a Geneve owner, I have to ask a question out of my sheer ignorance... what is a 'non-standard' Geneve and what makes it different from a 'standard' Geneve?

 

Will the TIPI work in a non-standard Geneve?

Link to comment
Share on other sites

The "most" standard Geneve is one with the V0.98 eprom. It had 512K ram + another 32K high speed ram along with 128K VDP ram.

 

Upgraded Geneves couild have the V1.00 eprom, Memex mods, more ram, an additional 32K high speed ram chip double stacked on the existing 32K chip, another 64K vdp ram, a gal chip upgrade on the VDP wait states, and there may be other upgrades I am not aware.

 

In my earlier email reference above with the V1.00 eprom, I do not know if the rewritten boot eprom that added a host of other booting opportunities from other devices, would incur the same issue(s) Matt observed. If that source code was available and there were issues, one "might" be able to program around the problem. It is just an unknown factor someone besides Matt would need to explore.

 

It could be something as simple as not running the TIPI power up routine when initially loading MDOS or it may be something unsolveable.

 

Beery

  • Like 1
Link to comment
Share on other sites

 

I'm sorry to hear that, I empathize with those that were looking forward to getting one.

 

Not being a Geneve owner, I have to as a question out of my sheer ignorance... what is a 'non-standard' Geneve and what makes it different from a 'standard' Geneve?

 

Will the TIPI work in a non-standard Geneve?

 

Omega, earlier in this thread I referred to my 2meg Genmod Geneve as 'non-standard' : anything else, I was lumping into 'standard'. That isn't very clear, since most Geneves have in the very least had a memory mod to allow running current versions of MDOS.

 

My Geneve having a mod that changes the meaning of lines inside the PEB raises extra doubt when it comes to hardware compatibility.

 

-M@

Link to comment
Share on other sites

I was just reading that... Thanks Mizapf, you've got some nice technical documentation on the Geneve. I'd love to see the 'bare-metal programmers guide to the 9640' that explains things like

 

---

 

Anyway, I mispoke... Greg tested with the crubase at >1800

 

Even so... if it was at >1F00, nothing in the Geneve, according to Ninerpedia uses bits >1F00 to >1F06, and those are the only crubits it would have been using (had I been telling the truth) ... so it shouldn't have mattered... my board should have just been undetected if that were the case. Except, who knows what it means for the boot rom to 'look' for x or y.

 

What am I allowed to do, and not do in the powerup routine? The VDP must be in the memory map at the 4A locations, for something like a TIFDC that sets up VDP buffers and stack pointers in there.

I poke the scratchpad ram to set a playlist for the 4a's interrupt service routine. That could be really bad... I'll try and remove that. It has outlived its usefulness on the 4A... it just provided me some functional assurance when first plugging a board in - "Woot! the ROM works!"

 

What is the memory map / environment for a powerup routine on a card during the boot process? I imagine the workspace pointer is up in the onboard cpu ram?

 

Don't answer that... let me see if this does: http://ftp.whtech.com/Geneve/GENPROG.ZIP

 

-M@

  • Like 1
Link to comment
Share on other sites

The boot EPROM does scan through 0x1F00 though it does not powerup 0x1100. I forget the reason for this. And next time I will clarify my CRU statement with a 'best practices' clause. The Geneve boot eprom sets up a rudimentary TI environment, including GPLWS R13/R14/R15 and the 0x8370 pointer. I don't recall seeing anything peculiar in your TIPI powerup code. If you're going to remove the sound list code, try restricting your device list to TIPI to help rule out interference.

  • Like 1
Link to comment
Share on other sites

The boot EPROM does scan through 0x1F00 though it does not powerup 0x1100. I forget the reason for this. And next time I will clarify my CRU statement with a 'best practices' clause. The Geneve boot eprom sets up a rudimentary TI environment, including GPLWS R13/R14/R15 and the 0x8370 pointer. I don't recall seeing anything peculiar in your TIPI powerup code. If you're going to remove the sound list code, try restricting your device list to TIPI to help rule out interference.

 

Interesting... I've never tried the TIPI without the TIFDC in... that might be fun...

 

I'll do those things one step at a time...

 

----

 

My powerup routine does the following:

* set latches that the PI can read to 0x00 ( 0x5FFD and 0x5FFF )

* set crubit 2 on - to signal tipi.service reset on PI

* copy a small sound list into VDP 0x1700

* poke that address into cpu >83CC, and enable sound list poking >83CE and >83FD ( I don't recall why )

* release/clear crubit 2 - so signal to PI has had some minimal duration.. I don't know if it gets this far... the PI responds immediately when the bit goes high.

* IF crubase is >1100 - setup VDP file buffers, cause on a 4A, someones got to (using the >8370 pointer)

 

-M@

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