The F18a DIY alternative with HDMI :)

[Hans23]

There is one thing that I find odd - With the original F18A, one has to put in the first jumper to disable the scan lines display.  With the tn9k_f18a, the solder bridge must be open to achieve the same thing.  Anyway, as the machine is coming up with VGA, it seems unlikely that there is something wrong with the jumpers.

 

I've hooked up the board to the logic analyzer to aid in further troubleshooting.

 

If the timing between when the tn9k_f18a starts in DVI mode and when the TI-99/4A starts initializing the VDP is the issue, here's what those times look like:

 

Between the system going out of reset and the ROM starting to write to the VDP, 3ms pass:

Between power up and the system going out of reset, 80ms pass:

I don't understand enough about the internals of the F18A and the DVI generator, so I'm not really sure if my idea makes any sense.  Let me know if and how I can further diagnose and help troubleshoot.

[Hans23]

It occurred to me that it'd make sense to compare the traces with and without HDMI, and while testing that, I found that it sometimes the machine comes up with the HDMI cable connected, but most of the times it does not.  If it works, things look like this:

If it does not work, here's what we get:

[Duewester]

3 hours ago, Hans23 said:

It occurred to me that it'd make sense to compare the traces with and without HDMI, and while testing that, I found that it sometimes the machine comes up with the HDMI cable connected, but most of the times it does not.  If it works, things look like this:

If it does not work, here's what we get:

Well, @Hans23 you certainly have the tools I envy. I've been playing with a Raspberry Pi Pico and VGA basic to build a rudimentary logic analyzer. Putting that aside though, I'm happy to know that the HDMI random start up isn't just me. AND you may have saved me a tang by trying the jumper hack.

Is it always D3 or does the data line change randomly. So,... the int and clock get stuck high when the boot fails. What's coming back from the tang that's going that? I mean, what signal does the HDMI part of the process comes in that isn't associated with the VGA? Or if it associated, what do we do to get it to stop locking up int and the clock?

[retrocanada76]

Great! Try that jumper on Tang that i told @Duewester. Maybe it helps.

 

if not can you compare with a scope or probe the gromclk, cpuclk, reset, mode and int lines with and without the hdmi plugged ? 

Edited May 21, 2023 by retrocanada76

[retrocanada76]

Cpuclk and gromclk seems delayed when the hdmi is in. On nabu this is not a issue since cpuclk holds the cpu bit that’s not the case with the ti.

 

i can try holding off the dvi interface for a second but i hope is not an electrical issue

[retrocanada76]

well well well, this is something I also see on NABU. The HDMI somehow delay the initailization of the F118A core what takes time to process any write to it. I "solved" it on nabu by holding the cpuclk line but that's not the case for the TI.

When I leave the cpuclk unleashed on NABU, I see the screen gets garbled when hdmi is connect but not when it's not. I can see here it is missing the very few writes to the VDP.

I'll keep looking. But even If I completely disable the DVI interface code the behavior persists. It's something internal to Tang that when hdmi is connect startup is a bit slower.

 

The nabu has a reset button, so pressing it solves the broken boot.

 

@Hans23 can you try resetting the TI when the hdmi screen is not up ? You will need a jumper cable or something to bring down the reset line.

[retrocanada76]

I think I have a breakthrough here.

 

@Duewester and @Hans23 can you please update the github and try the new code ?

 

What i did: I disable the USER SPI flash area. This is something I cannot test on Nabu. Is it really important ? Only on TI ? How to test anyway ?

 

I suspect this user spi flash is totally broken on Tang and when together the hdmi connector may have caused some snafu.

 

Right now, I am not holding down the cpuclk, and my NABU boots up every time with the HDMI.

 

 

 

[retrocanada76]

It might not be the spi flash, i reconnected the lines and it seems stable. The thing about HDMI is that it energizes the tang. Get a tang, plug just the HDMI (the TV must have the source select as hdm). You will see the light on tang on, but a little faint.

Anyway try the code on github. And wait 2 seconds between boots when HDMI is connected.

[retrocanada76]

MY code is booting up faster. that's the difference now.

[Hans23]

I've added a reset switch to my ZIF TI-99/4A and I can confirm that after a manual reset, both the HDMI and VGA output always work.

 

With the latest GitHub version, I see the same behavior as before.

 

Here's how things look like when the HDMI cable is connected and the TI does not come up:

And here's a trace with the HDMI cable connected and the TI coming up (once every few attempts):

Finally, here's a trace without the HDMI cable connected:

What I find interesting is that without the DVI cable, the reset line goes high a lot (80ms) later than without the DVI cable connected.

[retrocanada76]

Well I think the HDMI cable is powering up and moving the TI... The hdmi cable pin 18 is the EDID: 

 

 

What if we sever this pin from an hdmi cable ? This is only out of speculation. The Tang does not answer to EDID. All DDC pins are grounded. Then we could make a small adapter using the female/male solder connectors from aliexpress.

 

 

 

 

 

 

[Hans23]

I was wondering why the TN9k would start with just the HDMI cable connected.  Now I know.  I'll see if I can disconnect pin 18 on the Tang itself.

[Hans23]

Lifting the pin was not as straightforward as I had hoped.  I'll put a diode into the 5V rail to see whether that is the problem.

[Hans23]

22 minutes ago, Hans23 said:

I'll put a diode into the 5V rail to see whether that is the problem.

And the diode solves it!  Nice work!

I'll update my schematics and PCB and will send a pull request with the compact version.

Edited May 21, 2023 by Hans23

[retrocanada76]

from these traces, you can look at grom/cpuclk. once it start ticking it means the FPGA code has been loaded and the tang is ticking.

 

But it if you look for the failure startup, we have mode changing before grom ticking. Mode is address bus line 0. The 9900 is moving before the tang finishes loading.

 

Maybe the hdmi cable causes an variable delay on the tang startup. This seems to be electrical. Even if I don't do DVI, the behavior is the same. I tried putting a tape on the cable pin but it still lights up the led.

 

Do you have these cheap hdmi switchers with a button ? They might help. I have one here but I cannot find. My garage leprechaun is playing with me...

[retrocanada76]

3 minutes ago, Hans23 said:

And the diode solves it!  Nice work!

I'll update my schematics and PCB and will send a pull request with the compact version.

WOW! Where is the diode ?

 

[Hans23]

The diode is in series with the 5V line coming from the TI.  It prevents the TI from being powered from the TN9k.  I'll need to find a smaller Schottky diode for the actual fixed schematics, the SS34 that I've bodged in is way too bulky and 3A are definitely not needed

[Hans23]

Fixed schematics are here: https://github.com/hanshuebner/tn9k_f18a/blob/compact/KiCad/tn9k_f18a_compact/tn9k_f18a_compact.pdf

 

I'll sleep on it before I send a new order to JLCPCB.

 

Thanks again!

[retrocanada76]

Great fix. Definitely needed. I have 1N4001 handy here.

 

[retrocanada76]

so @Duewester as a quick fix for your fat board, cut the green mark (blue trace under the board) and put a diode 1n4001 between these pins as shown:

 

[retrocanada76]

The diode seems to work. But with the hdmi still we need to wait one second for a power cycle. Looks like the HDMI connector there slows down few things. Anyway many of my retro computers cannot be power cycled too fast due to old memory contention...

 

[Hans23]

To be on the safe side, use a Schottky diode.  A 1N4001 drops 1.1V, pushing down the 5V supply to about 3.9V, which may not be enough to safely power the voltage regulators on the TN9k.  Schottky diodes have a voltage drop in the order of 0.2V and thus should preserve some operating margin.

Edited May 22, 2023 by Hans23

[retrocanada76]

 

19 minutes ago, Hans23 said:

To be on the safe side, use a Schottky diode.  A 1N4001 drops 1.1V, pushing down the 5V supply to about 3.9V, which may not be enough to safely power the voltage regulators on the TN9k.  Schottky diodes have a voltage drop in the order of 0.2V and thus should preserve some operating margin.

1n4001 was the only rectifier i had in hand. Which Schottky through the hole would you suggest ?

[Hans23]

7 minutes ago, retrocanada76 said:

Which Schottky through the hole would you suggest ?

Diodes with a really low forward voltage drop are only available in SMD packages, but the Vishay/Diodes Incorporated SB110 has 0.48 Volts which should be OK. The TN9k uses a TMI7003C voltage regulator, but the data sheet is not clear on how much higher the input voltage must be in order for the output voltage to be stable.  3.9V->3.3V might be OK, but 4.5V->3.3V surely is on the safe side.

[Duewester]

On 5/20/2023 at 2:15 AM, retrocanada76 said:

@Hans23 wow, that's surgical precision! Try my latest push to the repo i made the power on faster.

 

Aynway if the board does not work, can you try using a scope to see if the signals are coming to the TANG ?

here the cheat sheet for the pins:

I need you to check if the ~CSW is actually strobing. ~CSR is used when the CPU reads from the VDP. These signals come from the LVCs, if not strobing, check both ports on them. Who knows the TI might be electrically different.

 

 

What about the HDMI breakout? Perhaps it could be an option for next board rev.