The LaST Upgrade - Part 15 - Bad DMA "fix"

[exxosuk]

http://exxos.www.idnet.com/IMPULSE/atari/last/DMAfix/

I had a hour tonight so uploaded the image of the cap mods to the DMA so the mod can be tried on any Atari Machine.

I am not saying this is a "fix all" solution as it is not. Though if you are suffering from random not booting from hard drive, or getting random corruption viewing files in GEM, then its most probable my fix will solve your problems. Of course you need to make sure your PSU is good to start with as that could be the reason the DMA appears to be going faulty, as a side note, the floppy drive will come up random faults too. Using Ecopy, it flags up sectors it cannot format, but those sectors that error are already random. If they were always the same sector then the floppy would be bad. So floppy drive issues can be linked to hard drive issues if the PSU has gone bad.

If people can post what hard drives work and don't work, with what machine and motherboard revision number, and with what number of DMA, then we might be able to get to the bottom of the DMA related issues once and for all. It would help if people could verify their PSU is good as it could otherwise taint the results, A scope to check the 5V ripple is needed.

For those who do not know about the other parts of my series go here http://exxos.www.idnet.com/IMPULSE/atari/last/

[+DarkLord]

That's a great series Chris. I've looked it over before and bookmarked it.

 

Recommended reading for all enthusiasts!

[GadgetUK]

I've applied the caps after seeing your page a few months ago and they did fix the problem where my STFM wouldn't always see the UltraSatan. Previously i would hazard a guess at 20% of the time I would just get the desktop with floppy icons, but after the caps were added I've had the UltraSatan boot every single time without fail. Thanks again =)

[exxosuk]

That's a great series Chris. I've looked it over before and bookmarked it.

 

Recommended reading for all enthusiasts!

 

Thanks Ron I don't have much time for Atari stuff as I used too, but I try and do what I can when I can

[exxosuk]

I've applied the caps after seeing your page a few months ago and they did fix the problem where my STFM wouldn't always see the UltraSatan. Previously i would hazard a guess at 20% of the time I would just get the desktop with floppy icons, but after the caps were added I've had the UltraSatan boot every single time without fail. Thanks again =)

 

Glad to know it is still working for you I put a link to your youtube channel in there somewhere too

[GadgetUK]

Thanks =). Any news on the 16Mhz TOS yet?

[exxosuk]

Rodolphe can only work on it weekends so its a bit slow going, tho hes noticed TOS is attempting to boot, but after a few instructions , TOS issues a RESET, so the ST resets. it does that a few times before it crashes. So I am just waiting for him to trace it all though. We don't know why TOS is issuing the reset, that's what needs to be looked into next.

 

I said to him just today actually, the PAK020 board I have, actually does exactly the same thing. I am on the lookout for a basic PAK020 to try out, the one I have here I assume is faulty, though its only on loan. I just find it really odd that on I think 4 or 5 STFM's, our board and the PAK board does not work, could be just coincidence, but unless I can find a working PAK020 to try in my ST here, its hard to debug things. People must have got the PAK020 working on STFM's surely ?! baffling to say the least.

 

Rodolphe did say if he can't find out the problem easily, he will build a small 68K setup on bread board and just run the CPU and TOS and step though it that way step by step.

[dsmall]

Here are some ideas which I hope are useful:

 

(1) The Motorola 68xxx processors have a little-known feature: If RAM for the stack isn't set up, they cannot multiply or divide. They use the stack for holding temporary results.

It'll probably double-bus-error because it can't write the crash stackframe to RAM. Double bus errors can be a bitch to figure out.

If you're using those instructions in the custom part of your board, look out.

 

(2) Hang a scope on the cartridge selects (FAxxxx and FBxxxx) and see if it gets pinged early on, by TOS looking at the diagnostic cartridge port. That's very early in system startup, should give you more information about how far the machine gets. If it gets that far, then look at the next thing -- setting up chips in the order the system does it.

See how many of the chips get initialized. You may also want to check the glue chip and make sure it's generating decodes for the big chips.

 

(3) You could make a custom cartridge for the cartridge port. It just needs to have the right magic number and address to jump to in it. The system jumps there early on. That would give you

a chance to see if the CPU is working. Say, do a loop inside the cartridge, and check things with an oscilloscope -- is it hammering on RESET, or hammering on the cartridge?

You could also write a baby debugger to single-step through the Atari ROM code.

 

(3) Timing after RESET?

Generally, whenever a chip gets a RESET, it's a good idea to wait a few cycles after to give the chip time to wake up, wonder why it has a hangover, and such.

When the ST is spun up, it takes awhile for the RAM controller to be initialized. I'd say give it more than 2 microseconds to reawaken.

(This is why "reset-proof" Ramdisks aren't. When the RAM controller is down, it's not refreshing the RAMs, which leaves holes in the RAM data.)

 

(Note: The floppy controller chip needs a hard RESET to recover after changing frequencies from low-density to high-density floppies.

This causes random errors and drove a lot of people like me into "The Cliffs of Insanity" when switching between low and high densities.

Finally, we ran a seperate wire to the floppy controller chipand manually kicked its RESET pin, then waited for it to wake back up.

 

There's a good oscilloscope picture of the glitch that happens here.)

 

Since you're trying to get the machine basically running, I'd use a hard coded delay loop, and wait a bit after each big chip gets its RESET.

Doing shift instructions, especially long shifts, are a pretty good method; it's something like 4 cycles + 2*N where N is the number of shift places.

With the better barrel shifter in the 020 this may not help as much.

 

If I remember right, MOVE.L (A7),(A7) eats a lot of cycles. I had to do this to give the SCC (serial chip in Mac) lots of time to wake up after RESET.

 

(5) Early on, when the machine is turned on, it does a RESET instruction. That makes the 68xxx send out a RESET to the big chips.

If it crashes early on, it goes back and does another RESET. You could take a look at the RESET pin with a 'scope and see if it's happening once, or in a loop, triggering away.

It tries to tell you what chip would not initialize but that's very sketchy.

(6) Reset on the ST has some interesting quirks... Have a look at the very start of the BIOS code. In many places, if something doesn't work, it jumps back to the resethandler, which may issue a RESET.

 

Let me know what results you're getting, and I'll try to help.

 

Thanks,

 

David Small

Edited August 15, 2014 by dsmall

[doctorclu]

Wow, good to see you Dave! (creator of the Spectre (Mac emulator for the ST)) and various speed upgrades for the ST.

 

So how have things been? Just recently got a ST sent to me so might have to play more with Spectre. Maybe one day we'll get System 7 working on it.

[rustynutt]

Apple said in a statement it is "aware" of the hacking allegations and is "addressing the matter."

Image hacked from Apple archives which it forgetfully stashed up its iCloud:

[+DarkLord]

Nice button. Maybe I should get a T-shirt that says something like:

 

"I'm seriously PAK-ing" or something like that.