Atari-Forum

Actually, MiNT started as a free and open source project by Eric Smith. The name MiNT was originally a recursive acronym, in a similar mould to GNU, "MiNT is Not TOS". When Atari saw MiNT running as a preemptively multitasking version of TOS they hired Eric and brought MiNT in house with their own f...

Just out of interest, when you start the Mac side of Spectre GCR the system plays the "Happy Mac" bong before the display appears but is this being generated by the Spectre GCR software before running the Mac Plus ROMs or by the ROM code? I'm just wondering as my TT hard hangs after the bong (and al...

Probably best ask about this on the QL Forum (https://qlforum.co.uk/index.php)

Are you sure that /RAS isn't connected to one of the /CAS lines instead?

/CAS should toggle to refresh, /RAS should only go low during a RAM read or write cycle.

I wonder if it'll work with one of these. (This was part of a job lot I got with my STE a few years ago.)

What hardware does it use to sample the audio?

MegaSTE & TT LEDs are 3mm and use a PVC grommet (6mm outside with 3mm hole) within the bracket.

It wasn't anywhere near the pins.

I also made sure that all the flux was cleaned off too.

The large amount of constant sinusoidal noise was on all the data lines continuously at around 2V (or greater) almost as if it was picking up a clock signal.

Every single data line?

czietz wrote: ↑Sat Sep 26, 2020 8:21 pm Maybe a data or address line was accidentally shorted by the socket? But still: Congratulations on reviving the machine!

No, I'd checked all of that, no shorts at all.

Success!

I removed the empty (Exxos) blitter socket and the machine strung to life. Weird!

Actually, the data lines look clean now. I think the empty socket was acting as an antenna and sending huge amounts of noise onto the buses and causing errors.

I've manually decoded the only two reads of the ROM (using /CE as the trigger on the 'scope). It's correctly reading the first two words of the ROM and then the /CE line doesn't get asserted any more and about a second later the machine reboots. It's almost as if the GLUE is miscounting read cycles ...

Well, I think it may be trying to run something, even if it's junk, as I have a dual TOS switcher ROM with 2.06 in one side and 1.04 on the other. This above is with the 1.04 image selected. There's no decoder for TOS 2.06 in the machine so the jump address will go nowhere and crash the machine if i...

It repeats. /RESET never goes low.

This is what two of the data lines look like... this repeats endlessly.

I suppose you ruled out obvious things such as 5 V supply and clock signals to the MMU? You can see all kinds of strange behavior until TOS has initialized the MMU config register and the video base memory address to sensible values. I think your computer crashes before that happens. I would not fo...

Arne wrote: ↑Sat Sep 26, 2020 3:43 pm Of course it needs CLK16 input. Check if it generates CLK8 and CLK4.

Yes, they're all fine.

frank.lukas wrote: ↑Sat Sep 26, 2020 3:25 pm /CAS is always high ?

Yes.

After trying to install a soldered in 4MB RAM upgrade (which sits under the PSU), plus a blitter socket, the machine just white screens. After reverting the machine to stock (other than the RAM is in sockets and I've left the Blitter socket in place) the machine is still non-functional. All the addr...

If you have an oscilloscope then when it's in the crashy state I'd definitely have a look at all the data lines either side of the 244s It should tell you which data lines look iffy and which side of the buffer chip the problem might be. If the signal looks bad on the memory side then it's a memory ...

Have you tested the voltages with a multimeter to see if it's outputting the correct ones?

The holes going from left to right (with the notch at the top) are: Ground, N/C, Ground, +12V, +5V

There is quite a lot of bus noise on the display. That's just the poor design of the motherboard.

The OSSC takes in VGA and SCART (RGB). VGA is an analogue RGB system.

Here's some sample output onto a 1080p TV.

Not really. The STE is marginal as built and the drift in components with age could have just pushed it over the edge. There should always have been pull-ups on those lines, but it just happens that they have floated high enough to work by a happy accident.

It may be best to zip (or otherwise compress the files), uuencode and then split.

At the other end you'll need to somehow concatenate them together, uudecode and then unzip.

The uuencoding make them safe text files which you can more easily munge without destroying the content.

. i.e. the cumulative propagation delay through the chips is just too high if the voltage is precisely 5V but sneaks in if slightly higher. Any chance you could verify that by swapping the chips for LS versions? I'm not sure you'd be able to get LS chips in SOIC packages and I wouldn't be confident...