Jump to content
IGNORED

The state of TIPI and the Geneve 9640 - success-ish.


jedimatt42

Recommended Posts

--- Update after 30 days ---

 

So, I set a time limit on resolving this issue. There are not enough Geneve users to sink a ton of time into this. The problem at hand was that at the low level, sending data to the TIPI on a stock Geneve was not working. This was fixed with a CPLD update on the TIPI. The update can be applied by anyone, instructions to do so are on the TIPI wiki: https://github.com/jedimatt42/tipi/wiki/CPLD-Programming-With-PI.

 

This shows TIPI to function in GPL under ROMPAGE mode. The storage system is not supported by MDOS.

 

Further, there are errors receiving data from TIPI when using the 'recvmsg' function in the TIPI ROM from MDOS mode. This seems to only happen when the destination memory buffer is external to the Geneve in the PEB. That points to a hardware flaw in TIPI still. But value vs. time prohibits further hardware investigation on my part.

 

Some experiments in software workarounds are still pending. Probably the vrecvmsg routine in TIPI ROM will work just fine, as it reads into VDP memory.

 

Again this is only a problem if you are addressing external CPU ram in the PEB, such as a MEMEX card or a Myarc 512k card modified for the Geneve.

 

-M@

 

 

--- Original Post ---

 

Ok, so Tim has put in my hands a Geneve that reproduces the problem with TIPI.

 

I've built a test cartridge that exercises the TIPI in GPL/ROMPAGE mode, and a corresponding python script.

 

What we see is that I cannot write to the 8 bit latches in the CPLD at 0x5FFD and 0x5FFF.

 

This is all I know so far, all the rest of TIPI works... reading from the latches set by the PI work fine, reading the ROM works fine, the crubits work fine.

 

---

 

I've been sitting on this for a while. but I have a lot of other things I want to do in my hobby life... So...

 

For the next 30 days, this will be my HOBBY priority. and if I do not have a solution by then, I am done. The only interest I have in getting it to work on other peoples' Geneves is gaining a little bit of knowledge.

 

But I need to make a good effort, and then admit defeat and move on, or rejoice in success! ( I am hoping for the latter )

 

I don't build TIPIs... I won't build TIPIs. So if the outcome requires physical changes, you'll all have to find someone to build them.

 

---

 

So, if you want this to work, now is a good time for you to learn how to read verilog, and assembly, and pester me.

 

Beery has been feeding me clues for a while... Given some of what he has fed me, and the lack of information out there, I'm going to start back at the prototyping process to figure out how to latch 8 bits in the DSR address space on write. Seems simple enough... But I have to pretend I don't know how to do it on a 4A or I'm trapped in the loop.

 

---

 

Interesting thing I read last night in the 9995 datasheet... the WE and CRU_CLK signal are the same pin...

 

-M@

  • Like 5
Link to comment
Share on other sites

 

Beery has been feeding me clues for a while... Given some of what he has fed me, and the lack of information out there, I'm going to start back at the prototyping process to figure out how to latch 8 bits in the DSR address space on write. Seems simple enough... But I have to pretend I don't know how to do it on a 4A or I'm trapped in the loop.

 

-M@

 

I've tried to find clues in notes others have written over the years of things that are different. Whether any of them prove fruitful for Matt's debug work, only he can determine.

 

Finger's crossed!

 

Beery

Link to comment
Share on other sites

Progress Report:

 

I modified the CPLD code tonight to turn the LED on if there is any WE* (low) signal on the bus... regardless of it is for TIPI or not...

 

I would expect to see this lit up while loading from the floppy drive.... or my test program... which enabled the CRU bit 0 for TIPI, then wrote and read to 0x5FFE a bunch, and 0x5FFF a bunch...

 

Neither a low byte or high byte write operation triggered the WE* (active low) signal. This is extremely astonishing.

 

If this is business as usual on a Geneve, there is no wonder TIPI doesn't work.

 

So... I went off to re-read ti-tech pages...

 

Interestingly, the input and output of the PIO port is controlled by CRU instead of WE*.

The TI floppy controller should be using WE according to Thierry. Although since input and output registers are at a distinct block selectable by A12, I'm not sure if WE* really matters...

 

Thierry's pages have given evidence of a few interesting things regarding the even-odd address voodoo. The memory mapped registers for PIO is a high-byte, as are all of the memory mapped registers for the TIFDC. However, in his IDE controller description he directly addresses the difference in the 9995 and 9900 write order. So yes, you can write to either the low or high byte. TIPI is not using 16 bit registers, so it should not matter than my reigisters are mapped into low bytes. I will revisit that after I figure out where the WE* signal went...

 

Tomorrow night I'll have to go in with the logic probe.

 

-M@

  • Like 3
Link to comment
Share on other sites

I wonder if the GenMod WE* signal was modified and thus why a GenMod/MEMEX system works?

 

I do know Ron did some work at the chip level with the GenMod/MEMEX that if he detected an unmodified card that did not have the extra address decoding, it would disconnect itself from the system. Here are Ron's notes in a PDF in the Hardware section of whtech:

 

The MEMEX, as shipped, assumes that you may have a card in the P—Box which does not fully decode the address bus as defined by the original TI specs. Although the 99/4A only used a 16-bit address bus, TI set aside 3 additional lines (AMA, AMB, AMC) for future expansion. Some cards, such as the CorComp disk controller and the Horizon ramdisk do not currently decode these lines (easily corrected on both cards). Normally, placing a peripheral card on the bus without taking this into account could result in damage to the bus transceiver chips on cards which would simultaneously "answer" the bus. The MEMEX board takes care of this in two ways. First, if it detects another card answering the bus, it immediately (in a few nanoseconds) "disconnects" from the bus to prevent damage to itself or the other card.

 

Second, a DIP switch (SW2, default=off) is provided to lock out those addresses (pages >82, >5E, >AE, >B2, >BA, >SA, >AA, >BA) which may not be decoded by such cards.

 

I do not know if this offers any clues, so throwing it out there..............

 

Beery

  • Like 2
Link to comment
Share on other sites

Looking at my hardcopy schematic that I presume shipped with the Geneve, the WE/CRU_CLK line from the 9995 goes through an unlabeled chip (an updated schematic shows it as PAL 202), before going out to the PEB bus. This same chip controls if the bus transceivers are enabled. http://ftp.whtech.com/Geneve/schematics/Page1L_GeneveSchematic.jpeg

 

The logic probe should confirm this easily enough.

 

-M@

Link to comment
Share on other sites

Logic probe confirms that WE* is pulsing low when I write to the TIPI. That gets through the 74'244,

 

Using the LED to observe it, by mapping the LED to ~WE in the verilog is showing that the CPLD sees WE*.. I just had to turn off the lights in the room to be able to see it.

 

This is good... The Geneve is not uber-crazy... only mega-crazy.

 

It also appears that the CRU_CLK is combined with the MEMEN before it goes to the PEB bus, so it is not pulsing even though it starts as the same pin on the 9995 as WE.

 

-M@

  • Like 4
Link to comment
Share on other sites

I've been able to get it too work by simplifying the code that controls the signal to the 74'245 bus chip on the TIPI board.

 

It now allows data in to the CPLD whenever the TIPI crubit is enabled and the address is in the DSR space, regardless of if it is a memory operation. All I did was remove the && ~TI_MEMEN. Latching operations still require ~WE and fully decoded address.

 

This should be ok, as the ROM chip is controlled for read operations from >4000 to >5FF8, and the direction is of the '245 is separately controlled considering DBIN.

 

My best guess is that this helps have the data available to my chips when the WE actually goes LOW...

 

Code is on a branch in github... Requires reprogramming the CPLD.

 

I need to test it on sideport TIPI w/4A and GENMOD Geneve to make sure I didn't break anything... So it isn't done yet...

 

-M@

  • Like 4
Link to comment
Share on other sites

Once I know I don't have to place exemption for side port or 4A or GENMOD usage, I will merge in the change and make the jedec file available. So that any new boards others are building can be at latest.

If you have a Xilinx programming cable the software required is free. I use a knockoff / counterfeit cable. If you are not in the USA a programming cable should be cheaper than round trip shipping.

I haven't sold any TIPI's to anyone for use on a Geneve. I have tried to be extremely clear contrary to some excited posts that it did not work. But there might be a couple of you with 9640s that want interchangeable PEB cards. At some point I'll declare a plan.

(Edit: I have found and tested a procedure to program the CPLD from the Raspberry PI, you just need 5 female to female jumper cables such as those with single pin Dupont connectors. https://github.com/jedimatt42/tipi/wiki/CPLD-Programming-With-PI )

-M@

  • Like 3
Link to comment
Share on other sites

Ok, I've reprogrammed my sideport TIPI, my 4A's TipiPEB and it all worked.

Worked also with my GENMOD Geneve.

 

So I've merged the CPLD code into the main codebase. And closed the github project issue.

 

The CPLD .jed file is available for download on my website. https://www.jedimatt42.com

 

I use Xilinx ISE 14.7 'webpack' license (the free option) -- This software is here: https://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/design-tools.html

 

There is an entire internet out there on how to install and use it... I do this on an unsupported Ubuntu variant, which required some 3rd party usb-driver for the programming cable, usb permission modifications, and LD_PRELOAD command to glue things together... I cannot answer questions about how to set this up on Linux. I didn't take notes, and would just have to do the same research you can do.

 

Windows should be much easier. Use Windows.

 

--- In case you are not familiar with ROMPAGE mode on your Geneve ---

 

TIPI DSR file features only works in ROMPAGE mode under GPL.

 

While in ROMPAGE mode under GPL, my physical floppy controllers do not work. I've tried a TI model and a Corcomp model ( and genmod decoding on the Corcomp model )

The board can be accessed in MDOS if you are a programmer. Right now, there is no software that does this. See BeeryMiller's other threads.

 

I expect historically access to a floppy or Myarc storage device worked in ROMPAGE, as I've heard tale of people loading the HDX DSR into an HDX board. I think Fred Kaal's DSR for the IDE controller could also be loaded... Those are the only 2 devices I've heard of people using ROMPAGE to access. Unless they program them on a 4A, and then transfer them to the Geneve...

 

Anyway, TIPI seems to work, just don't hold any expectations that it is useful.

 

My TELNET client does not work in 80 column mode, as it is optimized for the F18A. 40 column mode works. TIPICFG works. CALL TIPI works...

 

--- If you still want me to upgrade your board ---

 

Respond to this thread with a picture of your Geneve. I don't know how I want to handle this yet... But I'd like to know how many of you there are. ( If you don't have a Geneve, I won't do it, no need ) And how many boards need updating.

 

-M@

Link to comment
Share on other sites

While in ROMPAGE mode under GPL, my physical floppy controllers do not work. I've tried a TI model and a Corcomp model ( and genmod decoding on the Corcomp model )

the same holds true with the TI FDC & CorComp FDC with a standard Geneve. Which doesn't really make sense, since to boot from either card the Geneve must access the ROM and memory mapped addresses on the card.

 

The Myarc cards, Horizon RAMdisks, the SCSI card, the IDE card, the MBP Clock card, the SIDblaster, and a few other cards all operate fine under rompage mode (which just places the external bus into memory in place of the Geneve's software DSR). the TI/CC cards use VDP whereas the others do not; I can't see that as the culprit but who knows. I am home alone this weekend and have my PEB set to do some repair work. I'll toss the cards into the PEB to look around.

 

The TIPI fix does open up a few possibilities. Well done.

  • Like 4
Link to comment
Share on other sites

Matt,

 

If you have the capability and still have the older CPLD code base, or perhaps even with the current code base, can you check something?

 

No problems on the GPL/Rompage side of things.

 

On the MDOS side of things I have seen two things with my TIPI card. It could very well be something I am not considering, but I think some of my debugging tests has ruled that out.

 

I can open a socket and connect to my BBS, I can close the socket, and I can write to the socket and can confirm I am sending output as expected because I can blindly type and login to my BBS.

 

The recmsg routine is giving me problem as well as the status of the open socket.

 

Both with the Open Socket command as well as the Read socket command, the only output I am getting is >33 when I do the read at instruction >4010 in the TIPI DSR.

 

If you have some code, can you confirm you are getting what you would expect? Or, I can send you over my code?

 

Beery

Link to comment
Share on other sites

You are on a GENMOD Geneve... Go into ROMPAGE mode of GPL, into BASIC, run: CALL TIPI

If TIPI config works, then those communications routines are fully functioning. CALL TIPI("TIPI.NET.TELNET") also worked fine, again using those same message routines...

 

I usually call those routines with WP set to the 4A's GPLWS. >83E0, but I tried to write them so it didn't matter.

 

This was true before and after the change... It is an absolute pain in the @$$ to get files onto my Geneve for use in MDOS...

 

On the 4A, here is how I call the recvmsg for the mouse driver:

 

https://github.com/jedimatt42/tipi/blob/2096b4238bb5845937375229ed4e25caccc3aec0/examples/tiartist/tipim.a99#L63

 

If that doesn't help, post your code and I'll give it a read...

 

-M@

Link to comment
Share on other sites

So... 2 things:

 

1. I was reading the GENMOD installation manual and noticed that it instructs you to cut pin 56 (MEMEN) from the path sourced by the big gate-array, and wire it up to the new GAL tacked onto the back of the board. This would explain a significant timing difference that was allowing me to include MEMEN in my equations for transitioning the '245 on TIPI.

 

And most importantly:

 

2. ArcadeShopper said he'll work with you guys over shipping and handling services, and I'm happy to meetup with him and reprogram/test boards he has received. I'll defer to Greg then for details on how that service will work / cost...

 

Thanks Greg!

 

-M@

Link to comment
Share on other sites

Tipi geneve upgrades

 

Ship to me. In a box with static bag and bubblewrap. I supplied these originally hope you hung on to them :)

 

I'll collect a group and meet matt to program.

 

Return shipping i can take paypal or cards I'll use your box so tough to estimate but this is the top end.

 

Usa 8

Can 18

Eu 15

 

Please pm or email to lmk its on the way.

 

Ship to

Gregory McGill

16200 SW Pacific Hwy Ste H144

Tigard Or 97224

 

Sent from my LG-H872 using Tapatalk

Link to comment
Share on other sites

Tipi geneve upgrades

 

Ship to me. In a box with static bag and bubblewrap. I supplied these originally hope you hung on to them :)

 

I'll collect a group and meet matt to program.

 

Return shipping i can take paypal or cards I'll use your box so tough to estimate but this is the top end.

 

Usa 8

Can 18

Eu 15

 

Please pm or email to lmk its on the way.

 

Ship to

Gregory McGill

16200 SW Pacific Hwy Ste H144

Tigard Or 97224

 

Sent from my LG-H872 using Tapatalk

 

Greg,

As it looked like Matt got my code working on his system, I will be sending my TIPI out to you tomorrow unless he sees something different with the older CPLD code when he test things out. With your timetable, and trying to meet up with Matt, what kind of timeframe are you anticipating for a turn around. Just trying to get a feel, no pressure, etc.

Beery

  • Like 1
Link to comment
Share on other sites

 

Greg,

As it looked like Matt got my code working on his system, I will be sending my TIPI out to you tomorrow unless he sees something different with the older CPLD code when he test things out. With your timetable, and trying to meet up with Matt, what kind of timeframe are you anticipating for a turn around. Just trying to get a feel, no pressure, etc.

Beery

Week or so once the boards are here depends on how many and any stragglers

 

Sent from my LG-H872 using Tapatalk

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