Jump to content
FarmerPotato

Bringing up "Geneve 2020": Debugging Help Please!

Recommended Posts

18 hours ago, FarmerPotato said:

Try the xdt99 suite by @ralphb for assembling and making a binary image.  I use xas99, program Flash chips, and plug them in.

 

Here's the Makefile I use (under Cygwin) to assemble and get a binary.  You'll need to separate the high and low bytes into separate EPROMs. I made my life simpler by using the same EPROM in both sockets, with the low address bit hardwired to 0 or 1.

 

@FarmerPotato : Thank you, I will check these out in the next few days...

Share this post


Link to post
Share on other sites
12 hours ago, TheBF said:

I was thinking of a Forth ROM for further hardware exploration but it will need some RAM to work in so first things first.

Once you have RAM,  Forth gives you a nice debugger environment where you can test all the hardware for validity interactively or write simple test programs in Forth or Forth Assembler, to exercise the hardware.

I can cross-compile an image with 9902 communication support.  I have a version running on TI-99.

I have not finished documenting my Forth cross-compiler so I have not shared that yet. It runs in DOSBOX at the moment.

 

Yes, thank you for the encouragement and info , ... and the TI hardware seems to have such a great Fourth implementations and community. I'll definitely be discussing with you further once I have my RAM sorted out.  ... I am also thinking that perhaps I will pick up a TI-99 at some stage to complement the /189  (it's older cousin).

Thanks all for the kind words and feedback. I will let the thread get back to it's primary Geneve 2020 debugging mission now.

  • Like 1

Share this post


Link to post
Share on other sites
On 11/21/2021 at 7:28 PM, devorn said:

Yes, thank you for the encouragement and info , ... and the TI hardware seems to have such a great Fourth implementations and community. I'll definitely be discussing with you further once I have my RAM sorted out.  ... I am also thinking that perhaps I will pick up a TI-99 at some stage to complement the /189  (it's older cousin).

Thanks all for the kind words and feedback. I will let the thread get back to it's primary Geneve 2020 debugging mission now.

You're welcome to drop in--your TM990/189 shares quite a bit of the same challenges.

 

Now that I've got my ROM corrected, I'm going back to the 9902 stuff. I might even look at the 990/189 schematics!

  • Like 1

Share this post


Link to post
Share on other sites

I spent time going over the 9902 behavior in detail.  I found a hardware bug.

 

Reading the Bunyard hardware manual, I saw that CRUCLK is inverted in the 4A, from the 9900, giving it the same polarity as WE*. The 9902 expects valid data on CRUCLK high.  Does the 9902 latch CRUOUT on the rising or falling edge of CRUCLK?

 

The 99105 doesn't have separate CRUCLK, it uses WE* and RD* during CRU cycles.  And I have wired up WE* to the 9902 CRUCLK--wrong. The 9902 is being told that data is valid only before and after the WE* pulse. Backwards!

 

But is it harmful?

 

Sample:
 

CE* active with CRUCLK high
CRUOUT valid, all stable for 333 ns
CRUCLK pulled low for 166 ns, then high again.
CRUOUT valid for 83 ns.
CE* inactive and CRUOUT invalid.

 

Does the 9902 latch CRUOUT on the rising or falling edge of CRUCLK? In this sample, it shouldn't matter.  But maybe it matters sometime.

 

 

 

 

Share this post


Link to post
Share on other sites

 The problem I am stuck on is still this: as soon as a character is read from the 9902 receive buffer register, I see it transmit a bogus FF character.   All other operations are fine.

 

* input up to 80 chars, place in linein, plus crlf
strin 
	li   r2,linein
	li   r3,80
rcvlp
    tb   21
    jne  rcvlp
	
	stcr *r2,8
	sbz  18
	dec  r3
	jeq  rcvend
	cb   *r2+,@crlf      pressed return?
	jne  rcvlp
rcvend
	movb @crlf+1,*r2+    add line feed
	movb @zero,*r2+      null terminate
	
	rt

I've simplified this receive loop so that it doesn't echo characters. It doesn't mess with RTSON or the transmit buffer.  Yet it still sends FF after reading a character.

 

With the system clock at 3MHz (just like the 4A) the timing is thus:


 

STCR *R2,8
8 bits are read
2.2 microseconds pass
XOUT goes low, indicating a start bit, and stays low for the next 4ms (10 bits at 2400 bps). An FF is therefore sent on the line.
333 nanoseconds pass
Begin SBZ 18 which clears the RBRL flag (indicating we have read the character)

	CE* of 9902 goes active
	333 nanoseconds during which the 9902 thinks it has valid data.
	Falling edge of WE* to 9902.
	166 nanoseconds
	Rising edge of WE* to 9902 (this is backwards, my hardware error! but does it matter?)

Time passes while remaining bits of FF go out.
XOUT goes high (stop bit).

The bogus FF begins after the STCR completes, and before the SBZ begins.

 

 

 

Share this post


Link to post
Share on other sites

Yes, CRUCLK for the TMS9902 needs to be the inverted  _WE from the TMS99105

The TMS9902 latches the incoming data on the falling edge of CRUCLK

If you have CRUCLK directly connected to _WE then the 9902 will be latching data as soon as CRUCLK (_WE) goes low and i don't know if the data bus on the TMS99105 will have settled at that point in time. 

So you may be writing the wrong or spurious data to the 9902, maybe triggering the spurious TX

Share this post


Link to post
Share on other sites
11 hours ago, Jimhearne said:

Yes, CRUCLK for the TMS9902 needs to be the inverted  _WE from the TMS99105

The TMS9902 latches the incoming data on the falling edge of CRUCLK

If you have CRUCLK directly connected to _WE then the 9902 will be latching data as soon as CRUCLK (_WE) goes low and i don't know if the data bus on the TMS99105 will have settled at that point in time. 

So you may be writing the wrong or spurious data to the 9902, maybe triggering the spurious TX

Thank you for confirming that - is that fact in the electrical specifications? I could not find any answer in the text (even in 9900 Family Systems Guide which is better edited than the 1977 databook 9902.)

 

In a write, I see data bus valid for ~333 ns before falling WE*. But not very long after rising edge. If it's the kind of latch that is transparent when high (data valid) then internally the 9902 might be unhappy when CE* goes inactive while latch is transparent.

 

I can't deduce where, but the 9902 must hate this behavior.

 

Though there are no writes in my above read loop that malfunctions!

 

Perhaps something in the 9902 is metastable as a result of earlier writes.

 

Maybe it sees bit 7 trashed right after it's set. Usually, when bit 7 of XBR is written, XBR copies to the XSR (transmission shift register) for sending. My XBR gets re-loaded by spuriously setting bit 7 again. Usually a send loop would wait for XBRE though, then load a valid character. At any rate, there is no reason for a read operation to active the XSR! so perhaps we are in undocumented territory.

 

 

I've seen that the oldest 9902s behave very confused (esp the "counterfeit" ones I had first.) and begin transmitting garbage.

The newest 9902A-40s from specspecialties (Ft Worth, TX) behave fine, except for this repeatable case of spurious FF.

 

Anyhow I'll fix the error in wire-wrap. I was about to get a PCB made just to see if it would work better! Saved that.

 

 

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, Stuart said:

Have you got a schematic you can share?

The schematics are in gitlab here:

https://gitlab.com/FarmerPotato/geneve2020/-/tree/master/kicad
 

All in Kicad 5. My parts are in Lib/Gemini so that must be set as a path for Symbols, and for Footprints. 

 

Under cpu, the project is Steven.pro for the 99105 card. I’ve soldered a few things on since (like debounced  switches)

 

 

Under wwbios/wwbios.pro is the wire wrap board I have used, with one 9902 added onto it.

 

Only the 9902 in wwbios is still in use, as I have built and now use the PCB under bios/BIOS.pro


still unbuilt is cru/Ruby.pro which has 5 9902s and all the wrong CRUCLK!


There is no backplane schematic, as I bought an ECB backplane, which is just a 96 trace straight-through. 
 

all the other subdirectories are not relevant. 

I’m approaching the point where the cpu and memory gets rolled up into one 100x160mm main card. And replace the Kontron backplane layout with a very clean NuBus (TI).

 

 



 

 

  • Like 2

Share this post


Link to post
Share on other sites
On 1/11/2022 at 3:29 AM, Jimhearne said:

Yes, CRUCLK for the TMS9902 needs to be the inverted  _WE from the TMS99105

The TMS9902 latches the incoming data on the falling edge of CRUCLK

If you have CRUCLK directly connected to _WE then the 9902 will be latching data as soon as CRUCLK (_WE) goes low and i don't know if the data bus on the TMS99105 will have settled at that point in time. 

So you may be writing the wrong or spurious data to the 9902, maybe triggering the spurious TX

Goldangit. That was the whole problem.

 

It's fixed now with an LS04.

 

  • Like 8

Share this post


Link to post
Share on other sites
11 hours ago, FarmerPotato said:

Goldangit. That was the whole problem.

 

It's fixed now with an LS04.

 

Bonus, progress ensues. I'm glad to see this one move forward again. :)

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, Ksarul said:

Bonus, progress ensues. I'm glad to see this one move forward again. :)

Me too. I was discouraged by the lack of I/O and not sure where to focus.

 

Now I can focus again on getting an interactive BIOS (Forth in kernel).

With that I can test the FAT32 file system on SD (it's a 4-pin SPI interface to a convenient little Diligent PMOD.)

I wrote this on the Lattice Icestick long ago, and it needs support for TIFILES/DSK/FIAD under FAT32.

Once I can load files, much will happen!

Then the keyboard and graphics card.

 

  • Like 4

Share this post


Link to post
Share on other sites

Will the Camel Forth BIO's be accessible via the serial port?

 

If you can run Camel Forth from a serial connection, it would make even that one card very attractive! 😃

Share this post


Link to post
Share on other sites
5 hours ago, dhe said:

Will the Camel Forth BIO's be accessible via the serial port?

 

If you can run Camel Forth from a serial connection, it would make even that one card very attractive! 😃

I run Camel Forth over Serial Port here on my TI-99 for testing Forth code on real iron. :)

We will use a variation of that system to debug hardware for Eric's board (s).

It may stay in the system as a resident boot loader/debugger kind of like OpenFirmware but less sophisticated. 

It's  a nice debug console because you can script/automate things and it runs pretty fast.

 

  • Like 2

Share this post


Link to post
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...