[B-Roll] Investigating DSTB1 AltRAM issues on the STFM
Вставка
- Опубліковано 19 жов 2024
- Introducing the 'B-Roll' series.
I've not a lot of time of late to work on any projects and to produce videos, so to keep in touch I've started a new series of non-narrative videos that I'm going to call 'B-Roll'.
This is the sort of thing larger channels would have a second channel for. Less edited, less produced, probably no conclusion. More behind-the-scenes, stream of conciousness type output to show what I'm working on and how without necessarily telling a story.
Feel free to go big on the thumbs down if this is not something you want more of, else expect more of these than 'main' videos for the time being.
~~~
Today I'm trying to work out what's wrong with my DSTB1. I'm working on a new SDRAM driver in the firmware and getting nowhere. I then realise my booster seems to be unpredictably unreliable in 'release' configuration having worked beautifully in the past.
What gives?
Issue report: www.exxosforum...
DSTB1: github.com/dh2...
YAART: www.atari-foru...
/ thetechnoshed
I have set up a total of 5 DSTB1 and operate them in different MegaST (without Blitter), a 1040STF (with 4MB) and a 520ST (with 4MB), in conjunction with Lightning ST, STG(A)TW/ET4000 with a Transputerlink, everything works without problems. By default with EmuTos1.2.1. I didn't change the bus termination. I don't currently use ACSI.
I am very satisfied, the acceleration is clearly noticeable. Nice job, David. Thank you.
Well that's very nice to hear. Many thanks for the feedback. I think perhaps I need to build another one to rule out that this one's simply been through too many experiements!
I spent months trying to get hard drives to work reliably on my STFM, including all the exxos mandatory fixes, CMOS CPU swap, new power supply, etc. The thing that finally resolved my problem was building the DMA fixer pcb that appeared on atari-home de in June last year (the thread is named "1040 STE - Zusammenspiel zwischen GSTMCU und DMA-Baustein").
I don't think mine is a DMA issue -- although the original issue reported may be -- I think my DSTB1 is suffering from mistreatment!
The STFM doesn't suffer from the same as the STE DMA problems relating to the RDY signal which that board attempts to fix. I never heard or found such timing problems on the STFM. Also you don't fit a CMOS CPU to a STFM like on the STE. In Fact I say the exact opposite. I think your mixing up a whole lot of stuff there..
@@exxosuk I just know it's consistent and repeatable on my machine (my only Atari), which has always had DMA issues with hard drives. Testing with jookie's DMA HD test tool I get errors but if I fit the board I don't. I was getting desparate so some of the fixes I attempted later on went beyond what was suggested for the STFM, including the CMOS 68k.
@@SanguineBrah Jookies test program uses 16bit tests which don't trigger the DMA problem. Only 32bit access does AFAIK which TOS uses. I could run jookies program all day and tests would pass. Save desktop on a STE, and the drive gets trashed. So if your getting errors with jookies program, then I would assume your hard drive is bad or maybe SD card, or something hard drive related, bad connection etc. Also don't assume all hard drives work, there are a lot of drives about these days and people do have problems with them. Also the driver you use could be a problem.. If you did all the the fixes and it didn't help, its a indication that you have problems not with the machine specifically, but something else. If a STFM works in general, then the DMA pullups tend to be enough to solve problems with the hard drive. But these machines do suffer a lot with bad connections on the chips and even bad solder joints. Even flexing the motherboard slightly can destroy multiple solder joints causing various weird problems. The list is unfortunately endless. Is why it is always preferable to have a second machine to try things on.
I guess the error occurs with a specific access pattern. This would point to some voltage problems on the lines. That can be bad contacts, cold solder joints, flaky ICs. Everything that pulls down one or more address/data lines enough to make it marginally work. It's hard to find without an oscilloscope.
Possible. I suspect it's more related to timing -- the OS will access RAM back-to-back and in odd orders whereas the testing software has to go off and fetch instructions. It proceeds evenly and linearly.
I have a scope, but it's hard to scope stuff thats' buried on the bottom of the board or is under the CPU!
One day you'll make a video with the keyboard screwed onto that Atari ST and we'll all be aghast.
I would speak to the guys who created the cloudy/storm hardware, whoever programmed their firmware would most likely be able to help. They're probably the only people who have designed a similar alt-ram device on a CPLD of recent times.
Whilst I like the Storm guys and am happy to speak to them, they are making a commercial product so don't really want to get into territory where they may feel uncomfortable answering.
Runs fine during RAM test, then run a program and it crashes. Welcome to the world of Atari ;)