exxos's Atari, Amiga & retro forum

Smonson wrote: ↑Mon Sep 10, 2018 3:35 am To eliminate the possibility of power supply issues, could you try running the machine with the stock shifter installed, but with the FPGA board connected to just +5, ground, and vysnc? If possible, from somewhere connected close to the shifter socket. Then it should run through video generation just by itself and possibly introduce power supply or ground noise.

That is a good idea.

In fact, both shifter and FPGA could actually be soldered on top of each other ? If Troed solders a socket on top of the shifter, plugs the shifter into the MB, then the FPGA into the socket.. then he can run both at the same time ? If both outputs work, that would be interesting..

If troed has a diagnostic cart, might be worth running with that to see if any bad bits in RAM test show up before the reset.. I'm thinking bus loading issues when the FPGA is installed...

Might also be worth running VSYNC via a 100R resistor as well...

Smonson wrote: ↑Mon Sep 10, 2018 3:35 am In fact, both shifter and FPGA could actually be soldered on top of each other

Hmm, the problem with that is they'll both try to drive the outputs (data bus, 16mhz clock). Also I have tied the unused pins to ground on the shifter socket adapter PCB, so those would short out some of the shifter's pins, such as the RGB lines, if they're connected.

exxos wrote: ↑Mon Sep 10, 2018 10:12 am If troed has a diagnostic cart, might be worth running with that to see if any bad bits in RAM test show up before the reset.. I'm thinking bus loading issues when the FPGA is installed...

Might also be worth running VSYNC via a 100R resistor as well...

Yeah I have. Although if that was the problem I cannot see how it would always be a reset - should be bombs and corruption. VSYNC issues would also just cause the display to flicker/blank out - not reset.

I only checked with the LA that VCC didn't short out before RESET - I'll do the dual load as well as scope it also.

(The 520 runs off a picoPSU and the doubleST a recapped regular Atari PSU running at 5.11V - so they're not similar in that aspect)

troed wrote: ↑Mon Sep 10, 2018 10:28 am Yeah I have. Although if that was the problem I cannot see how it would always be a reset - should be bombs and corruption. VSYNC issues would also just cause the display to flicker/blank out - not reset.

Yeah it should yes, but knowing how screwy these machines are, whos to say the extra load on VSYNC isn't causing ringing on the GLUE, causing GND bounce or something and causing the GLUE to malfunction causing the reset.

That's the kinda of screwy problems I am fighting all the time with these machines, also why its long term easier just to create a new motherboard

Its easy things to try.. may not help, but never know, and it rules some things out

exxos wrote: ↑Mon Sep 10, 2018 10:34 am but knowing how screwy these machines are, whos to say the extra load on VSYNC isn't causing ringing on the GLUE

Yeah, I agree. It could also be bad grounding since my entire board is powered and grounded through a single pin each in an IC socket, which is probably not the best if it's going to draw hundreds of milliamps of current.

The fact that my machine is incredibly stable makes me think that whatever the problem is, it must be near some threshold where I'm just under it and you guys are just over it. It feels like an analogue problem.

Smonson wrote: ↑Mon Sep 10, 2018 10:50 am Yeah, I agree. It could also be bad grounding since my entire board is powered and grounded through a single pin each in an IC socket, which is probably not the best if it's going to draw hundreds of milliamps of current.

The fact that my machine is incredibly stable makes me think that whatever the problem is, it must be near some threshold where I'm just under it and you guys are just over it. It feels like an analogue problem.

Yeah, I see that type of issue all the time. Like with my boosters, can work perfect for days on one machine, then identical other MB and nothing but trouble It could be literally anything..

I mean if the ribbon cable is half the length that could make or break something for example. Running gnd through a thin cable isn't likely helping issues.. Might be something else Troed could try, is making the cable as short as possible..

Yeah analogue is where I'm lacking all knowledge. Adding a fat ground wire is an immediate thing I can check of course.

Ringing backwards on VSYNC causing GLUE to trip up is actually the best explanation so far as to what can happen that causes _resets_ always

this is awesome stuff keep up the good work, id buy one for each ste/stfm

I'm not less confused.

Fatter GND and resistor on VSYNC made no difference. So just to rule out the possibility that the FPGA is fine and _both_ my doubleST and 520ST are weird I pulled up a non-recapped pure stock-as-stock-can-be 1040 STF and put it in there.

Booting without a disk in the drive, or with the floppy disconnected, first gave me a similar impression to the 520. Reset pretty soon after boot, and the the VSYNC LED on the FPGA starts flashing.

But if I insert an original disk (Closure, is what I had close by) there are no resets. The demo runs fine (bar the bitplane and pixel errors in the FPGA emulation that I think can be fixed easily).

If I boot without the drive connected and get to the desktop then that has pixel errors compared to on the 520 where it's perfect, so it's not the case of the 1040STF being "better" at running the FPGA. Now I'll get back to the 520 and connect a floppy drive to it ... haven't tested with that at all before.

(Closure gets rid of TOS directly after the boot sector has loaded the first screen - so this problem might be due to something TOS does ... ??)

Wow.

It absolutely is. Connected up an HxC slim to my beautiful internal floppy header in the 520ST and booted ... Closure. No resets at all.

So previously I had looked at /MONOMON with my LA to see if it triggered - since one of the few ways an ST resets cleanly is when TOS detects a mono monitor having been plugged into the monitor port. There's no way I know of for the Shifter to induce that, but hey ...

And of course, a boot sector demo like Closure disables TOS /MONOMON check. So I guess I'll have to think hard about that theory again.

(Removing power from the HxC slim is enough for the 520ST to then start with the spurious resets on the next boot again)