Link Port Viewer

Timendus · Post by **Timendus** » Sun 29 Oct, 2006 2:46 pm

Because PTI still lacks a graphical link port monitor, and my linktest utility really needed a redo (redrawing the screen using puts would reset the link port before setting it back again

), and I once again ran into impossible to debug annoyances, I decided to write a quick oncalc link port viewer.

I'm not entirely satisfied with it yet because it's too slow to keep up with my routines, and therefore useless for debugging my problem that still hasn't been solved

, even if I don't update the screen on every change. It also detects keypresses wrong from time to time (pressing 2 changes the tip sometimes

).

Anyway, here's a download for whoever wants it:
Download

Pressing 1 toggles the tip, pressing 2 toggles the ring, pressing Clear exits. The four dots represent if the line is high (inactive, open circle) or pulled low (active, filled dot) first and second if it's you pulling the line low or the connected calculator(s). This will be clear enough once you try to use it. In the screenshot the current calculator is holding the ring low and the connected calculator is holding the tip low.

The history shows the status of the lines (tip on top, ring bottom) scrolling from right to left on every status change. So if it were fast enough you'd be able to see byte transfers plotted on it.

Request@CoBB: It would be nice to see something like this, but with PC speed instead of TI speed, put into PTI

KermMartian · Post by **KermMartian** » Sun 29 Oct, 2006 3:19 pm

Yeah, I've nagged him in the past for something like this. Good job on it; I bet this will help me debug Cn2 even more than your previous link port tool.

CoBB · Post by **CoBB** » Sun 29 Oct, 2006 6:16 pm

There is problem with this. PTI has no notion of time beyond that needed between two frames, which is a fundamental limitation. I have to rethink this part thoroughly, because it can affect things in weird ways (remember the blinking bug related to raw linking? that was also a time-related issue). I’ll probably have to use 64-bit counters instead of 32 (I want to be able to represent much smaller time quanta than a Z80 clock cycle, since that will be a must for the SE) and drop the display-oriented time concept, which was a pretty stupid thing to introduce in the first place.

I can’t even estimate how much work this change will involve, but it’s likely much less than the one that made it possible to emulate multiple calcs. That was...

Timendus · Post by **Timendus** » Sun 29 Oct, 2006 7:22 pm

My little thingy has no notion of time either, it just records all successive changes that it detects on the link port. This sounds stupid, but in link programming that is all that really matters. The calculators don't have proper timing, so all link software depends on detecting changes anyway.

CoBB · Post by **CoBB** » Mon 30 Oct, 2006 6:23 am

I guess so. Well, it might be possible in this specific case, if I add a global link state tracker (if I were to record them separately for each calculator, I couldn’t determine the proper sequence when merging the data without timestamps), but it still requires some thinking to integrate it properly... I’ll see what I can do.

Timendus · Post by **Timendus** » Mon 30 Oct, 2006 4:44 pm

* Hopes *

Post by **benryves** » Mon 30 Oct, 2006 5:00 pm

I still use your old "ASCII-art" one from time to time. Nice to see it being updated

CoBB · Post by **CoBB** » Mon 30 Oct, 2006 5:38 pm

benryves wrote:I still use your old "ASCII-art" one from time to time. Nice to see it being updated

It was a bit too phallic anyway.

Timendus · Post by **Timendus** » Mon 30 Oct, 2006 5:39 pm

Wow, that's two already... I didn't even know it had a single user before yesterday

Edit:

@ CoBB

KermMartian · Post by **KermMartian** » Mon 30 Oct, 2006 6:01 pm

CoBB wrote:
benryves wrote:I still use your old "ASCII-art" one from time to time. Nice to see it being updated
It was a bit too phallic anyway.

Agreed, that was just freaky. It did the trick though.

DigiTan · Post by **DigiTan** » Mon 30 Oct, 2006 11:20 pm

This one will probably help me clear up the checksum vs. CRC uncertainty.

KermMartian · Post by **KermMartian** » Tue 31 Oct, 2006 4:43 pm

Timendus, I find that as you said, it's too slow. It only sees about 5 of the 8 bits getting sent per byte with Cn2.

Timendus · Post by **Timendus** » Tue 31 Oct, 2006 7:46 pm

DigiTan wrote:This one will probably help me clear up the checksum vs. CRC uncertainty.

Don't trust it too much yet

kerm_martian wrote:It only sees about 5 of the 8 bits getting sent per byte with Cn2.

Really? It sees my entire "CLAP lite" byte transfer as one change... As I said before; it seems your CN is pretty slow in it's current state. Are you going to do much about that?

KermMartian · Post by **KermMartian** » Tue 31 Oct, 2006 11:19 pm

Timendus wrote:
DigiTan wrote:This one will probably help me clear up the checksum vs. CRC uncertainty.
Don't trust it too much yet

kerm_martian wrote:It only sees about 5 of the 8 bits getting sent per byte with Cn2.
Really? It sees my entire "CLAP lite" byte transfer as one change... As I said before; it seems your CN is pretty slow in it's current state. Are you going to do much about that?

Uhhh, no, clearly mine is much faster, at least 8/5ths as fast as yours.

Timendus · Post by **Timendus** » Wed 01 Nov, 2006 12:11 am

You must suck in math even more than I do

I send 8 bits in 32 changes to the port, you send 8 bits in 8 or 16 changes to the port. Of my 32 changes, only one gets detected. The same program detects 5 of your changes. Since your routine uses at least twice as much changes, yet 5 times more are picked up, your routine should be roughly ten times slower than mine to get such a high detection rate. Have you tried sending over a full screen b/w image yet? (Or 768 random bytes) How long does that take? If my little calculation is correct it should take you about 15-20 seconds.