exxos's Atari, Amiga & retro forum

Nice old little bench...

8-)

stephen_usher wrote: 07 Dec 2025 16:34 In other stuff, I've been attempting to design and print station furniture based upon photos from the early 1980s...


img064.jpeg


Not quite there yet, but getting close.


IMG_4813.jpeg

Looks great, just needs some dirt and graffiti now :)

Well, one of the cart sockets kind people are sending me arrived today so I fitted it to the board.


The results so far are better but not working.

NetUSBee's diagnostics work up until it tries a load of "write using read", which fails consistently. UIPTool at least reliably reads the MAC address now though. This is a great improvement as previously it would get zeros most of the time.

Spectre GCR still hangs, probably because the write using read is failing and it's not getting a signal back that it expects.

I'm going to have to get a logic analyser on the address bus along with UDS and LDS and the ROM chip select lines. I did notice some *VERY* short (<100ns) address line activity. If this corresponds to a period when one of the ROM select lines is low then that would definitely confuse things sitting on the cartridge port. If this is the case then it "feels" as if a revision of a PAL has a timing issue when accessing the cartridge port address, which may not affect reading from ROMs etc. but may confuse "write using read" devices.

With the NetUSBee diagnostics there is another good result, it doesn't crash whilst trying to exercise the write/reads.

Previously the system would become unstable after about 10 seconds of the diagnostic trying to write to whatever the diagnostics try to write to. Now it will continuously loop for minutes and the system is stable and I can just Ctrl-C out of the program.

Well, according to the logic analyser all the signal timings look good with the address being on the bus right until the exact end of the /ROM3 or /ROM4 signals. The addresses are set up long before the /ROM3 or /ROM4 signals go low.

The only thing that I can think of is that the TT is sampling the data bus early and the data isn't on the bus yet. That would be /DTACK generation timing for the cartridge port, which then would be either the MMU or a PAL.

Then again, that wouldn't explain why writing to the NetUSBee network registers isn't working.

Have you checked the 5V rail on your board ? Adding some ceramics of different values may help ?

exxos wrote: 09 Dec 2025 16:32 Have you checked the 5V rail on your board ? Adding some ceramics of different values may help ?

Yes. 5V rail is steady and good and my board has a huge capacitor between GND and +5V and uses one GND plane and one power plane. There are no active components on the board.

This TT has never been able to run the NetUSBee, which is why I developed this filter board. The address lines on the cartridge slot ring like bells, so that a transition to 5V will overshoot and then dive back down to around 1V and then up again and after a 100ns or more it will settle down. This board has stopped that from happening at least.

Oh... This is interesting, suggesting a timing issue... uiptool.tos is only able to read the MAC address from the ethernet chip if it's (a) running from TT-RAM (prg) and the cache is enabled. Turn off the cache and it gets all zeros, run it from ST-RAM, all zeros.

So, there must be something fundamental on this particular revision of the TT hardware that's preventing non-ROMs in the cartridge port from working (in addition to the rubbish address bus).

I decided to do some experiments with pull-ups.

First I removed the 10K pull-ups and run a test of UIPTOOL: MAC address consistently bad with random values for most of the entries.
Then I replaced them with 2.2K pull-ups...

UIPTOOL: good MAC address, still no networking.
Spectre GCR: For the first time ever it's booted to the question mark icon!

So, it is timing and the 2.2K pull-ups are bringing the lines high just a nanosecond or more faster and allowing many things to work.

Maybe you could cheat and delay the control lines on the port?