Slow DSP investigation with DFB1

[Badwolf]

I expect ACE tracker must be using DMA to the DSP and therefore probably DMA out of the DSP to the codec also. Acting as a stream processor in the middle. However Mr Hedberg is really the person you want to ask about that - it could be doing something very different

Daniel's kindly offered to enquire if there was any special consideration needed for CT60 operation, so will be interesting to hear back.

The 'timeout' part means it has probably boot-loaded some code onto the DSP and is trying / failing to get a response. in fact it is not clear from any of that output if any DSP code has been running during the cart pass, although 'external interrupt' suggests something did...

No idea We'd need to study a dump of that code to know what's going on.

Yes, I was working on getting the cartridge code running as software to facilitate quick iteration and hopefully adding of debug output. I shall return to that work, I fancy.

DMA to the DSP is what the Atari's test tool trying to test / visualise: https://github.com/mikrosk/mikrosk.gith ... 30test.zip.

Aha, of course. And that runs nicely (displaying a progressing green bar). I'm hazy on all the different ways data can come and go, so wasn't sure what would use the modified GAL pathway, but presumably that does.

I do have a vague plan to add some more DSP related tests including this one - but I'm bogged down with work just now and not much time to play. If I make any progress on the changes I'll post them here.

Thanks, Doug.

I did wonder if maybe that diag cartridge is using code which assumes a 16MHz Falcon (?) and the breakage might not actually be your GAL/timing changes but incomplete handshaking combined with a speed change. However that problem would also show up with bus speeders - something which could still be tested?

It should be noted the cartridge test has never worked with DFB1. 16MHz or accelerated mode. This hostport speed investigation was partly an attempt to see if it could be made to pass.

Ergo: there's something else that's amiss that affects DFB1 irregardless of CPU speed and DSP hostport timing.

Has the diagnostic cart ever been reverse engineered? If it has, maybe you can see what it's actually doing.

The (68k) code is available at dev-docs.org (which is what I've been playing with) but the 56k code is just regurgitated IIRC. Since that doesn't seem to be running anyway, it's probably not going to hinder the investigation unduly.

BW

[stephen_usher]

Do you have the ROM image somewhere? I could try running Ghidra on it to decompile.

P.S. Seems that there's no need. Older source code is available on the Atari Document Archive (attached) though the source seems to have been slightly messed with with lots of the DSP code commented out for some reason.

[Badwolf]

Do you have the ROM image somewhere? I could try running Ghidra on it to decompile.

The cartridge ROM? No need. We have the source on dev-docs, although I think it's a slightly different version to that commonly used.

https://docs.dev-docs.org/htm/search.ph ... uction+Dia

BW

[stephen_usher]

The cartridge ROM? No need. We have the source on dev-docs, although I think it's a slightly different version to that commonly used.

It's apparently version 1.21 where the normal image is 1.25.

[dml]

Well, a brief scan of the 68k source side of things yielded this, on the DSP ram test:

*------------------------------------
* DSP RAM TEST (comments from RAM1.asm)
;* When the program begins testing, it writes a MT_TESTING to the Host
;* Interface data register, HTX. If the test succeeds, MT_SUCCESS will
;* be put in the HTX register. If it fails, the test ID will be ORed
;* with the 16 bit address of the memory that failed and put in the HTX
;* register. For example, if a $604E5F is returned, the $6 means the
;* random value memory test (see Test IDs below) failed at address $4E5F.
;* The test indicates memory failure if the host (68xxx CPU) does not
;* see a MT_SUCCESS flag in a few seconds (or the program has died from
;* a 56k failure. The complete RAM test took 0.78 seconds on a 27 Mhz
;* 56001. Most of the time is spent running the WalkingOnes test.

...which is what I thought. But it is no clearer what is actually going wrong. If the host data register HTX was not working, none of the other stuff you tried would work either so it must be something interesting about the test itself - or the failure occurred upstream in a previous test case and broke the start of this test.

[stephen_usher]

Did you actually look at the code? It's doing busy loops to act as delays for the timeouts. Faster CPU = shorter timeout.

[dml]

Did you actually look at the code? It's doing busy loops to act as delays for the timeouts. Faster CPU = shorter timeout.

Nope - I was working at that time. I was only scanning for a description of the test.


BW indicated the test fails at 16MHz - so while busyloops are probably not helping at >16MHz, they're unlikely to be the whole story there if I'm following things correctly.

Externally timed delays (or busyloops) are used for the DSP reset/restart cycle while it is briefly powered down but are certainly not needed for communications - unless specifically for a bandwidth test.

I'll have a bit more time to look at the code at the weekend...

[stephen_usher]

Looking at the rest of the code in there, the counters for the timeouts etc. seem to be a bit arbitrary, so possibly determined by trial and error. Also, we have to remember that this is at least four versions before the currently used ROM and it looks like a work in progress, so how much of this reflects the code in the ROM is anyone's guess.

It would be interesting to disassemble the actual ROM and compare it with the source.

P.S. I hope that you didn't read my first message in the wrong way. Reading it again it can sound a bit indignant, but it was meant to be quisical.

[dml]

Looking at the rest of the code in there, the counters for the timeouts etc. seem to be a bit arbitrary, so possibly determined by trial and error. Also, we have to remember that this is at least four versions before the currently used ROM and it looks like a work in progress, so how much of this reflects the code in the ROM is anyone's guess.

True. I was also wondering later exactly how BW is running this ROM. Is it from a real cartridge with the Atari-assumed ROM timings or from the DFB1 flash? Or flash copied to AltRAM? Running the code from something other than the original slow ROMs could well upset those busyloops....

It would be interesting to disassemble the actual ROM and compare it with the source.

It would be quite useful to know what changes were made and where.

Reading it again it can sound a bit indignant, but it was meant to be quisical.

I figured that was the case, I was just very busy in recent days so not had any real time to look at it properly - I knew looking at the details would be an instant rabbithole like everything else!

[stephen_usher]

@exxos do you have the Falcon diag ROM image that you put on your diag cart? If so then that would be useful, thanks.