Bringing up "Geneve 2020": Debugging Help Please!

[devorn]

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

[devorn]

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.

[+FarmerPotato]

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!

[+FarmerPotato]

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.

 

 

 

 

[+FarmerPotato]

 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.

 

 

 

[Jimhearne]

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

[+FarmerPotato]

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.

 

 

 

 

 

[Stuart]

Have you got a schematic you can share?

[+FarmerPotato]

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

 

 

 

 

[+FarmerPotato]

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.

 

[+Ksarul]

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.

[+FarmerPotato]

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.

 

[+dhe]

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! ?

[+TheBF]

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.

 

[+FarmerPotato]

On 1/17/2022 at 8:32 AM, 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! ?

Yes, there will always be a Forth console you can boot into. The boot sequence,  that checks out your hardware, will be written in Forth, like Open Firmware. 

 

There will be some NVRAM (8K perhaps) that can hold your boot preferences. Two or three Forth words there can start MDOS or GPL from your disk if you like. 
 

Like any BIOS there will be a key that drops you into the Forth console or some kind of config menu. 

Yes, the CPU, BIOS memory, and console serial port will be on card. Theoretically , you could hook up 5V and have a minimal system without a backplane. 

Im consolidating this onto one full size 160x100mm Eurocard now. The working cards were 80x100 CPU and 100x100 BIOS.  It shrinks a little, if I don’t add too many new ideas…

 

 

 

 

 

[+FarmerPotato]

Work on Geneve 2020 has been slow to nonexistent in the past 6 months. My father was hospitalized, so I went to care for him. He  passed away in August. 
 

I had to tear down my hardware workbench. But it’s back up now. 
 

Aisler.net made me happy today. I uploaded a PCB on Sunday and it arrived on Friday. Shipping was $31  from Germany to US though. I used their fast turnaround service.  9 x $3.33 little PCBs. (3 sq inches). Regular Beautiful Boards is more like 2 weeks. Their prices have been going down.
 

I have this crazy idea of getting a board nice enough to show for TI Faire in a month. One week turnaround will help. 
 

I might put “made in Germany” on the next PCBs…

 

 

 

 

 

[+FarmerPotato]

On 1/17/2022 at 1:53 PM, TheBF said:

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. 

 

I’m grateful @TheBF is willing to do Camel99 for me. And put up with my constant delays. I’ve still not got it to run on my memory board. 
 

So last week, I wire-wrapped a 612 memory mapper, junking my memory board , which had  the 22V10 hold the mapper registers.

 

If I’d used a LS259 register, that 22V10 would  not have been such a waste of time. Premature Optimization is the root of all evil. 

The 612 lets me configure the ROM and RAM just like a 4A. Supervisor mode works because interrupts or XOPs put the 612  into pass mode, like TI designed it.  Pages 0-3 map 0000-7FFE transparently to ROM and 8000-FFFE map to RAM.  A15 (MSB) is the ROM/RAM select. So in map mode every other 32K is ROM then RAM. This will do for now. 
 

[+FarmerPotato]

Beyond the 612…

 

On paper I’ve got a memory mapper that has evolved into a two level “cache” or PMMU.  Inspired by reading the 1990 TI Cache Memory ACT data book. (The original data sheet for the 612 is in that book, and so many other long-vanished cache chips! And application notes.)

The latest memory mapper keeps the page registers 1 byte, two per word, which keeps it as simple as possible to emulate 9640. No shenanigans required to update half a  word. It fits easily  in one XL9572XL chip. 

 

(Prior, I actually wrote a state machine in Verilog with 4 microcode instructions, just to allow MDOS to update the lower 8 bits in each of 2 page registers at once! Page registers being the 16 bit physical address lines A27:12. All ripped out now!)
 

Now, A second level RAM takes the 8 bit page numbers and looks up  the 16 bit physical page. Finally, A27:12 plus logical A11:0 go onto the backplane, or select onboard memory. (A27 being the MSB.)
 

I studied  TI’s 1990s era ABT Advanced BiCMOS data book. Designed for fast VMEBUS applications.

 

The ABT573 , 244 and 245 chips have typical propagation delay of 4 to 6 ns. An XC9572XL will add 10-15ns. Combined with cheap, fast 10 ns cache RAM, the memory mapper can get the job done in under 40 ns. This is the window for the 99105 address setup, at full speed 6 MHz. Testing starts at 3 MHz though. 
 

 I will have to add a little delay for the external ALATCH, to let the address to  settle on the backplane. That might be as bad as 10-40 ns, I dunno. This bites into the RD or WR pulse. 
 

(The backplane, just like the 99105, multiplexes the address and data lines. ALATCH high tells you that the lines have the address. ALATCH low tells you it’s become the data bus. You just connect ALATCH to a 573 latch ENABLE pin and it does the job.)
 

(On the backplane, ALATCH  is the NuBus START signal. Yeah I adopted TI’s NuBus in this iteration.)

 

 

 

 

 

 

 

 

 

[+9640News]

Sounds like progress!

And sorry to hear of the passing of your father.

[+dhe]

3 hours ago, FarmerPotato said:

Regular Beautiful Boards

 

I'm sure were all interest in seeing a photo! 😃

 

3 hours ago, FarmerPotato said:

I might put “made in Germany” on the next PCBs…

For the true retro-feels - How about - "Made in West Germany"

[jbdigriz]

Just now catching up on this thread. Been very busy and distracted. Amazing progress. My sympathies on your loss.

[+FarmerPotato]

On 9/30/2022 at 3:18 PM, dhe said:

 

I'm sure were all interest in seeing a photo! 😃

 

For the true retro-feels - How about - "Made in West Germany"

Actually, Aisler is in The Netherlands, but they use a fab in Germany.