What if? Designing "Geneve 2020". Cool 3D views!

[Anthony Kristler]

this discussion is very insightful, I only have a question, when will this computer be available, i am a very die hard ti fan

[+FarmerPotato]

On 2/14/2024 at 7:31 AM, Anthony Kristler said:

this discussion is very insightful, I only have a question, when will this computer be available, i am a very die hard ti fan

Sorry, I'm not setting any ship dates. It's been my passion for the past four years...

 

 

 

[+FarmerPotato]

Update:

 

I was stuck finding shorts. 
 

First AD15 was shorted somewhere. Probably at the RAM. But so was VCC-GND.

 

I found it last night after desoldering the accused culprit RAM chip again.
 

The short was a solder whisker, on the farthest, unused RAM footprint. The pinout of this RAM is smart but tricky. To reduce switching noise, they put VCC and GND on the middle pins of each side. Which makes them easy to short. I lost a lot of time on the assumption that my RAM had some solder bridge underneath. 
 

 

I'm getting weary of build difficulties. With that short found, I find that my ROMs aren't working. It seems like the two PLCC sockets' springiness has worn out, at least on the side that has chip select and output enable. Weird that its  both. The signal reads perfectly AT the socket, it just doesn't reach the chip pin. (I poked a wire in because the probe tip is too wide.) 

Either I managed to wear out both PLCC sockets at once, or the chips have some weird damage. But I was able to read, rewrite and verify them on the T56 last night. 
 

[+TheBF]

I miss DIP sockets...  

[+FarmerPotato]

15 hours ago, TheBF said:

I miss DIP sockets...  

Seriously considering DIP again for the EEPROM.  When I replace the LS612 memory mapper (DIP-40) there will be room.  And it will simplify the address/data bus route. 

 

--

 

The PLCC-32 sockets were Amphenol brand, fresh from Mouser.  At least 10 insertion cycles so far. 

 

Anyone have advice here?  How to keep PLCC sockets in working order?

(and why would both fail in the same remove/insert cycle?)

 

 

 

[RickyDean]

2 hours ago, FarmerPotato said:

Seriously considering DIP again for the EEPROM.  When I replace the LS612 memory mapper (DIP-40) there will be room.  And it will simplify the address/data bus route. 

 

--

 

The PLCC-32 sockets were Amphenol brand, fresh from Mouser.  At least 10 insertion cycles so far. 

 

Anyone have advice here?  How to keep PLCC sockets in working order?

(and why would both fail in the same remove/insert cycle?)

 

 

 

You can get PLCC 32 sockets that are through hole like these https://www.digikey.com/en/products/detail/amphenol-icc-(fci)/54020-32030LF/4292083?utm_adgroup=General&utm_source=google&utm_medium=cpc&utm_campaign=PMax Shopping_Product_Zombie SKUs&utm_term=&utm_content=General&utm_id=go_cmp-17815035045_adg-_ad-__dev-c_ext-_prd-4292083_sig-Cj0KCQiAxOauBhCaARIsAEbUSQSWaLHTZZieX8zoV9g_ok1u392lSgyfMLlPwjjlA2zEBCxvKYioCJEaAuUTEALw_wcB&gad_source=1&gclid=Cj0KCQiAxOauBhCaARIsAEbUSQSWaLHTZZieX8zoV9g_ok1u392lSgyfMLlPwjjlA2zEBCxvKYioCJEaAuUTEALw_wcB

 

Would that help? These are similar to the ones I used on my Ubergrom builds.

Edited February 24 by RickyDean
spelling, added content

[+FarmerPotato]

1 hour ago, RickyDean said:

Would that help? These are similar to the ones I used on my Ubergrom builds.

I do have those. The surface mount kind, I found, are easier to route. 
 

it's not the PCB to socket, it's the socket to chip that's no  longer making contact. 

[RickyDean]

21 minutes ago, FarmerPotato said:

I do have those. The surface mount kind, I found, are easier to route. 
 

it's not the PCB to socket, it's the socket to chip that's no  longer making contact. 

Ok, that's a bit wierd. You aren't using a pointed device to remove the plcc chip from the socket and maybe bending back the pins are you?

[+Ksarul]

I've never had any socket issues with PLCC stuff once I got them seated properly on the board. I have had problems getting them to program in a normal PLCC socket, but once I switched to the flap-style live bug sockets for programming, that problem disappeared too. I haven't had issues with the dead-bug box-style sockets for programming either, but I personally prefer the flap style when programming a bunch of chips.

 

The only thing I could think of that might damage the regular sockets is too much asymmetrical stress on the contacts that make a few of them lose their grip on the chip. Probably near the insertion notches.

[Tornadoboy]

This maybe a stupid question but is there such a thing as a PLCC ZIF (Zero Insertion Force) socket? If so maybe you'd have better luck with those during the proto stage given the repeated removals, then just go with normal sockets once you've settled on the design. 

Edited February 25 by Tornadoboy

[+FarmerPotato]

@Ksarul  Um what do you mean by dead bug, flap, live bug in PLCC? 
 

In the prior board, I used  ZIF DIP sockets (lever) happily. Might go back. At one point I drew two Memory Mezzanine daughter boards, one using DIP. 
 

Amphenol says the PLCC socket life is  25 insertions. My problems are at the short end of PLCC-32 (sides are 7,9,7,9 pins).
 

But then, on microscope  I can't see any gap.

 

I tried two new chips, same problem. 
 

But on one try, I got out 00 instead of Ff when 

I poked two tiny wires into both RD and CE.  Expected 80. (So maybe still got AD15 shorted.)

 

Chips are SST 39SF010 (128K x 8 ) PLCC. 

Guess I'm going to have to swap in new sockets. Again. 

 

[+Ksarul]

Here is an example of the 32-pin flap style test and burn-in sockets. These are always in live-bug configuration (chip is placed top side up in them).

 

Here is an example of the 32-pin square test and burn in sockets. These can show up in live bug or dead bug style (dead bug has the chip placed upside down in the socket).

 

Both types can be obtained without the DIP adapters they are soldered into for use with programmers. I have a couple of each type loose, as one of my programmers expects the bare PLCC sockets in its programming slots (ADVIN gang programmer for PLCC chips).

 

Pomona also makes some really nice plug sockets for the various PLCC chips that give you test points at the top for every pin, but they can be a bit pricey. The 32-pin also only seems to show up in the kits with everything from 20 to 84 pin adapters as well, making them even worse on pricing.

[+FarmerPotato]

On 2/24/2024 at 1:39 PM, RickyDean said:

Ok, that's a bit wierd. You aren't using a pointed device to remove the plcc chip from the socket and maybe bending back the pins are you?

I'm using the puller that came in the XGecu kit. Goes under the corners. 
 

I have damaged chips taking them out. 

[+FarmerPotato]

So I took out the sockets. Put in the last two I have. New chips. Very easy to insert. But still no good. 
 

I also replaced the bridge to the logic analyzer. The DuPont crimps are wearing out and I guess that's why I get so many tiny glitches. 

 

Problem is continuity between the address latch and ROM. Address lines L_A10, 11 are bad. They read solid 0 or 1 at the origin, but wobbly at the ROM. I traced L_A12 as a control. 
 

So likely the ROM was not the problem all along. The floating input could result in the address pointing into all FF. 

The L_A10 and 11 traces have continuity between the two ROMs. I've deduced that the break is a damaged via.  Under the brand new plastic socket.  

I'm stuffing the via with tinned bodge wire. 

 

 

[RickyDean]

36 minutes ago, FarmerPotato said:

So I took out the sockets. Put in the last two I have. New chips. Very easy to insert. But still no good. 
 

I also replaced the bridge to the logic analyzer. The DuPont crimps are wearing out and I guess that's why I get so many tiny glitches. 

 

Problem is continuity between the address latch and ROM. Address lines L_A10, 11 are bad. They read solid 0 or 1 at the origin, but wobbly at the ROM. I traced L_A12 as a control. 
 

So likely the ROM was not the problem all along. The floating input could result in the address pointing into all FF. 

The L_A10 and 11 traces have continuity between the two ROMs. I've deduced that the break is a damaged via.  Under the brand new plastic socket.  

I'm stuffing the via with tinned bodge wire. 

 

 

Understood, don't get frustrated, stay cool and you'll get there. Those little gremlins kick us all at some point or another.

[+FarmerPotato]

Two bugs fixed, one new one. 
 

Via repair was successful. I'm not sure it was the problem though. Continuity measurement was unreliable!  

 

At U3 , the address latch, those outputs for L_A10,11 had poor solder joints.

 

They sometimes conducted when I put pressure on the pin from on top, but not when probing the vias.

 

Similar bug  is L_A3 is shorted somewhere.  I can deduce the addresses that data really came from. 

 

Worst case, L_A4 is shorted to L_A3 underneath the ROM sockets I just replaced.

 

My construction skills are still short of what I'm trying to build. It could be the amount of solder paste. 

 

I imagine little solder paste stencils for 1-chip footprints. With local registration holes. 
 

 

 

 

 

[+FarmerPotato]

No breakthrough.  

 

In layout, I made a terrible mistake:  a LA_3 via is next to a ground pad.  I removed the solder blob, but it still shows as shorted.  I had to bend back the ground pin of the LS259B:

 

 

The vias under the LS259B are to get L_A1, L_A2 and L_A3 into the chip.  It's very cramped at the edge of the board--lesson learned. 

 

 

[+dhe]

Any updates FPo?

[+FarmerPotato]

I made progress on the Forth interpreter, by porting it back to the 4A. This was the kernel from McCann Software's Geneve Forth, however with all the Geneve bits removed.  Now it's the boot BIOS. 

I added 4A versions of the $SYS calls.  I had replaced them with serial I/O.  KEY, ?KEY, ?TERMINAL, EMIT, CR, CLS, GOTOXY.  
 

I wrote a $trace subroutine to emit the word name from the inner interpreter.

 

With my bugs fixed, it gets through COLD and tries 3 LOAD.  It goes off the rails because block I/O is stubbed out. The return stack underflows, and it branches to 0000.

 

Classic99 helps with a breakpoint on  stack underflow. 

 

Next is to decide what screen loads should do.

 

I read  (Chuck Moore?) that screens are virtual memory. 

My plan is that screens are page-size (4K)  and cover all the ROM/RAM (2 megabytes)  Also, any disk file can be mapped into a range of screens,  for reading or editing.
 

Forth will detect the content type in a screen: DIS/VAR, object code, program with GenLink header, TIFILES, others. 

 

The built-in editor will use familiar TIWRITER keys. 

Though text is stored in DIS/VAR sector layout, an added data structure makes it possible to do edits directly on the file.  As a text file is modified, binary tree pointers  are placed at sector end.  If you wish, a file can be re-written as a sequential file. 

 

[+FarmerPotato]

I am frustrated by the soldering of PLCC-32 sockets, surface mount. (I used the thru-hole before and the routing is awful.) 

 

So I asked, are they really saving space?

 

I have two SST39SF010A EEPROM (256K total). The sockets are:

 

PLCC-32: 18 x 21 mm = 373 sq mm

DIP-32: 18 x 41 mm = 723 sq mm

 

So yes, you get two PLCC sockets for one DIP-32. But mistakes are impossible to fix if you put them side by side. 

I also have 3 PLCC sockets for ATF22V10C chips. I've had no problems soldering these.

 

PLCC-28: 18 x 18 = 324 sq mm. 

DIP-24: 10 x 36 = 361 sq mm

 

Kind of a toss-up there. Do I really need them to be socketed? They're fully tested in simulation with no room for changes anyway...

 

SOIC-24: 10.7 x 16 = 166 sq mm

 

Two of those equal one socket--and no hidden traces. 
 

Currently:

3 PLCC-28

2 PLCC-32 

Total 17.5 sq cm

 

Suppose:

3 SOIC-24

2 DIP-32

Total 19.5 sq cm

 

Worth considering. 
 

EDIT: I can flip two SOIC-24 onto the back of the PCB.  Just about pays for swapping two PLCC-32 for DIP-32.
 

Could have other advantages. 

Edited June 8 by FarmerPotato

[+FarmerPotato]

I'm playing with a data structure with many uses. 
 

I start with the heap sort that I got from Anna Stack's Algorithms in Forth. 

 

For i>0 define 

LEFT(i) = i*2

RIGHT(i) = i*2+1

PARENT(i) = i/2 (round down)

 

With an array of 2^n nodes, you have a binary tree.   (Node 0 is not used.) The usual pointers left, right, up are implicit, though trees can't be spliced. 
 

Using this, Heap sort takes O(log n) time to do  INSERT and MIN operations on this, while using no additional memory.  Not our topic here. 
 

In a word processor or sequential file, a chunk i is preceded by the text in node LEFT(i) and followed by text in node RIGHT(i).  The top of the tree is approximately the middle of the file. HEAD and TAIL pointers are useful but easily recomputed. 
 

Nodes may be null (not the same as empty.)  

 

The file is traversed in-order: recurse  left, do self, recurse right. 

 

The tree must be kept balanced. Else, when appending lines,  LEFT(i) could quickly exceed 2^n. When all 2^n nodes are used, then n may be increased by doubling the amount of fixed storage.  Until then, the tree is kept compacted.  
 

(Note that 2^n corresponds to the number of sectors in the file, not the number of lines.) 
 

One way to stay balanced:

 

When an insert operation requires a new node at LEFT(i) or RIGHT(i) , first find the  unused node with lowest j. If j is equal to whichever of those, continue. Else ROTATE(i,j)

 

Generally speaking, ROTATE begins with the hole at j. The hole migrates  upward to the common ancestor of i and j, then downward to i. Migration is a series of node swaps. There are two cases when i is reached, depending on whether we are making a left or right child. 

 

Each node might hold 256 bytes of memory, storing counted strings. (Max length 254.)  Additional overhead is needed to cache total lines counted before or after each node. 

 

In this way, a file may be loaded into a fixed amount of memory, and edited in a way that minimizes block moves of memory. 
 

When no more nodes can fit  in memory, the first recourse is to pack two consecutive nodes into one. This can be made efficient if each node keeps the byte count used in its sector.  Otherwise, there must be an expensive compaction of all lines in memory. (This compaction is what TIWRITER does.) 

 

If the node structure is hidden inside the 256 bytes itself,  the structure can be backed by disk storage. Then a file can be edited by making small patches, no need to load the whole file.  
 

With this structure, records can be inserted or scratched from a sequential file of variable size records. 
 

A VARIABLE, SEQUENTIAL file can be used as if it were FIXED,RELATIVE.  

With object libraries in DIS/FIX 80, individual modules can be re-assembled and re-written in place.  (A library is many object files concatenated.)

 

EDIT: 

With this structure, goto line number is a binary search.  Subsequent/preceding lines are local. Access by line number  is O(n), where n is  approximately the number of sectors in the file. 

 

TIWRITER keeps an ordered array of pointers to line buffers, so has O(1) lookup but O(N) to rearrange/insert. 
 

 

[+TheBF]

I am wondering if using HeapSort is the optimal way to this.

It seems like it might be more overhead that needed. ??

 

I just found this over on Rosetta Code. 

Tree traversal - Rosetta Code

 

Looks pretty clean.  I think I need to try it.

 

 

[+TheBF]

Ok this uppercase version with two library files included, compiles on Camel99 Forth. 

You need to have the system disk in DSK1. 

 

A couple of things jump out at me:

 

Look how simple it is to make the NODE data structure.  Now I will add comments to make it clearer that this is a data structure creator but holy cow that's sweetly simple. 

 

This version uses the DEFER word DEPTHACTION to hold the code that will run an be applied all the nodes.

Pretty neat and saves a lot of duplicate code. 

 

\ BINARY TREE (DICTIONARY)  from rosettacode.org

NEEDS VALUE FROM DSK1.VALUES 
NEEDS DEFER FROM DSK1.DEFER 

: NODE ( L R DATA -- NODE ) HERE >R , , , R> ;
: LEAF ( DATA -- NODE ) 0 0 ROT NODE ;

: >DATA  ( NODE -- ) @ ;
: >RIGHT ( NODE -- ) CELL+ @ ;
: >LEFT  ( NODE -- ) CELL+ CELL+ @ ;

: PREORDER ( XT TREE -- )
  DUP 0= IF 2DROP EXIT THEN
  2DUP >DATA SWAP EXECUTE
  2DUP >LEFT RECURSE
       >RIGHT RECURSE ;

: INORDER ( XT TREE -- )
  DUP 0= IF 2DROP EXIT THEN
  2DUP >LEFT RECURSE
  2DUP >DATA SWAP EXECUTE
       >RIGHT RECURSE ;

: POSTORDER ( XT TREE -- )
  DUP 0= IF 2DROP EXIT THEN
  2DUP >LEFT RECURSE
  2DUP >RIGHT RECURSE
       >DATA SWAP EXECUTE ;

: MAX-DEPTH ( TREE -- N )
  DUP 0= IF EXIT THEN
  DUP  >LEFT RECURSE
  SWAP >RIGHT RECURSE MAX 1+ ;

DEFER DEPTHACTION

: DEPTHORDER ( DEPTH TREE -- )
  DUP 0= IF 2DROP EXIT THEN
  OVER 0=
  IF   >DATA DEPTHACTION DROP
  ELSE OVER 1- OVER >LEFT  RECURSE
       SWAP 1- SWAP >RIGHT RECURSE
  THEN ;

: LEVELORDER ( XT TREE -- )
  SWAP IS DEPTHACTION
  DUP MAX-DEPTH 0 ?DO
    I OVER DEPTHORDER
  LOOP DROP ;

7 LEAF 0      4 NODE
              5 LEAF 2 NODE
8 LEAF 9 LEAF 6 NODE
              0      3 NODE 1 NODE VALUE TREE

CR ' . TREE PREORDER    \ 1 2 4 7 5 3 6 8 9
CR ' . TREE INORDER     \ 7 4 2 5 1 8 6 9 3
CR ' . TREE POSTORDER   \ 7 4 5 2 8 9 6 3 1
CR TREE MAX-DEPTH .     \ 4
CR ' . TREE LEVELORDER  \ 1 2 3 4 5 6 7 8 9

 

[+FarmerPotato]

@TheBF Thanks!  That's a nice binary tree. I should study other data structures in there. 
 

For Word processing:  I'm not doing a general binary tree--no pointers. The one  feature from Heapsort is  the fixed-memory space, in place tree manipulation.

My "pointers" are just integers, and LEFT, RIGHT, UP are just integer math, since the tree is predictably laid out as 2^n cells per layer. To traverse does not require  recursion or a stack. It's like a mouse-in-the-maze right hand wall follower. 
 

. The node content is just a pointer into a block buffer. In operations, only pointers are swapped--to compact the tree or insert. 

Box Diagrams Need General Binary Trees

 

In a different  algorithm, my hierarchy  diagram box and lines drawing code, I do use a general binary tree. (Here I also pass xt's --for the style to draw the box or line.)

 

In C, I implemented the drawing algorithm with two stacks, two while loops, no recursion. My Forth code for that is ugly and I can take hints from this nice tree implementation. 
 

In my box diagram drawing code, I use the names DLINK and RLINK instead of LEFT/RIGHT. Left links point down in the printout. Right go.. well, right! (Across the page.)
 

[+FarmerPotato]

On 6/2/2024 at 10:26 PM, FarmerPotato said:

Forth gets through COLD and tries 3 LOAD.  It goes off the rails because block I/O is stubbed out.

When it branches to a garbage address, the GPL interpreter writes to *R15, obliterating the NEXT routine! Fun. Restarting with PC=A210 is hopeless. 😩 

 

Right now, 3 LOAD goes off the rails in the ERROR routine.  There's no screen of error messages, then it calls TYPE on garbage data.
 

 

My trace prints endless  1+ DUP C@ EMIT ?;S
 

 

So I will put in the TIFORTH error strings (little "message" word)