exxos's Atari, Amiga & retro forum

Interesting that MFP and SND CS is done via GLUE...

I let GLUE see /AS always from CPU (running TOS206 so GLUE doesn't decode 104 space) But makes no odds..


EDIT:

What is just before YM init in code ? Maybe that is still active on bus when YM init tries to happen and it corrupts the bus causing invalid YM address...

exxos wrote: 30 Jan 2019 22:07BERR I am still suspect.. Ijor thinks its not possible for error for BERR in my setup... Though Things to seem to point in that direction..

I didn't say, or at least I didn't mean, that problems with BERR are not possible at all. I say that slow BERR deassertion should not cause the CPU to get BERR on the next cycle. And even if that would be possible (say, the SEC is different in this regard), the behaviour would be different. If the CPU would get two bus errors in a row, that would be a double fault and the CPU would halt. You wouldn't see any errors, it would just freeze.

But that doesn't rule out other type of problems related to BERR. And if you are overclocking the CPU beyond the specs, then all sort of issues are conceivable. IMHO, you need a good LA to diagnose this efficiently.

Interesting that MFP and SND CS is done via GLUE...

Everything connected to the CPU bus, except Blitter, gets CS from GLUE. It must be like this because GLUE and Blitter are the only chips that see the full address bus.

ijor wrote: 31 Jan 2019 01:30 Everything connected to the CPU bus, except Blitter, gets CS from GLUE. It must be like this because GLUE and Blitter are the only chips that see the full address bus.

I took the blitter out ages ago to make things easier.

Though one problem with the GLUE, is it keeps DTACK low right up unitl S2 of the next bus cycle when it decodes ROM. Do you know if it does that for other things it decodes ?

That is the reason I stop GLUE seeing /AS for ROM cycles as its DTACK take forever to release. Though maybe GLUE is doing that with other cycles which I haven't taken into account.

The scenario is CPU accesses a SND register, GLUE issues DTACK, CPU completes cycle, starts a new cycle, GLUE still has DTACK low from previous cycle and CPU re-reads that DTACK. Eventually the CPU does something else, maybe access RAM, but if GLUE keeps DTACK low, the CPU may read the last SND DTACK access and complete the RAM cycle to early causing corruption.

RAM access works fine, I ran YAART last night, no issues at all. I think the problem with the diagnostic cart is it only does things one at a time in tests, whereas TOS is accessing various things almost at random, so I think something is overlapping causing bus corruptions. I never thought about GLUE decoding other address ranges and that is at least something I can do some tests with now..

I have a idea to add in some clocked delay lines for IO ranges, RAM and ROM ranges work fine... Idea is any space (not ROM and RAM) being accessed, CPU sees DTACK as normal, BUT, I add in maybe 2xclk8 delays before I let the CPU see DTACK again. GLUE should have set DTACK high in that time, so there shouldn't be any issues of the CPU re-reading a previous DTACK cycle.

I added in some code which only allows DTACK to the CPU after 3xCLK8 clocks, which should be enough by far.. But it does not seem to have made any difference :(

I rebooted the machine three times and got these errors..

Incidentally, my ROM DTACK routine only allows DTACK to the CPU when ST_DTACK has gone high. So there should not be any issues with the ROM decoding..

BlankVector wrote: 30 Jan 2019 23:33 Surprisingly, this happens precisely after writing to the YM2149 to initialize the I/O ports. Is this a clue of something?
Or maybe some random parts of EmuTOS are trashed, and this time the random innocent victim is YM2149 I/O initialization?

I'm assuming GLUE would issue DTACK after writing to YM register, so I can't see there being a issue there... I can only think maybe the address is corrupted, and its writing to some other address, which is invalid, and causes a BERR..

exxos wrote: 31 Jan 2019 10:56Though one problem with the GLUE, is it keeps DTACK low right up unitl S2 of the next bus cycle when it decodes ROM. Do you know if it does that for other things it decodes ?

That is the reason I stop GLUE seeing /AS for ROM cycles as its DTACK take forever to release. Though maybe GLUE is doing that with other cycles which I haven't taken into account.

The scenario is CPU accesses a SND register, GLUE issues DTACK, CPU completes cycle, starts a new cycle, GLUE still has DTACK low from previous cycle and CPU re-reads that DTACK. Eventually the CPU does something else, maybe access RAM, but if GLUE keeps DTACK low, the CPU may read the last SND DTACK access and complete the RAM cycle to early causing corruption.

n the case or ROM access, GLUE uses combinatorial logic to assert DTACK. So GLUE would deassert DTACK on S7 right after the CPU deasserts AS. This is just following Morotola bus protocol specifications. But again, DTACK is open drain so the raising edge would be slow and it might extend slightly more. It is possible that a CPU running much faster would then see DTACK still low at S2 . I would need to double check it, but I think that even then at S2 it should be harmless unless it extends beyond S4.

But when accessing the sound chip, GLUE uses synchronous logic. This is done on purpose for inserting wait states because the sound chip is not that fast. But then DTACK pulse would extend much more than S7 and S0 (let alone the slow raising time for being open drain). And this indeed can be a problem if the CPU is running at a faster clock.

So you definitely need to decode, at the very least, for I/O access and take proper action. Note that MFP and MMU handle their own DTACK. Chip selection is still performed by GLUE.

ijor wrote: 31 Jan 2019 14:10 n the case or ROM access, GLUE uses combinatorial logic to assert DTACK. So GLUE would deassert DTACK on S7 right after the CPU deasserts AS.

That doesn't actually happen though with ROM access. I documented it a long time ago, I think TF even noticed the same.. That Based on normal 8MHz timings, GLUE DTACK stays low right up until S2 of the next bus cycle. There is about 20-40ns difference between DTACK going high and /AS going low in the next bus cycle. That time is only there with 1K pull ups on DTACK. Pretty much DTACK can been seen as staying constantly low during all ROM access.

OTHO, I believe the STE sets DTACK HI about 40ns after /AS goes high. But the STFM chipset doesn't. This is why I am forced to isolate /AS when using faster ROM access for TOS104, because GLUE's DTACK control would cause to many issues. Another issue is GLUE sets DTACK low right after /AS , maybe 20ns..

ijor wrote: 31 Jan 2019 14:10 But when accessing the sound chip, GLUE uses synchronous logic. This is done on purpose for inserting wait states because the sound chip is not that fast. But then DTACK pulse would extend much more than S7 and S0 (let alone the slow raising time for being open drain). And this indeed can be a problem if the CPU is running at a faster clock.

The CPU still waits for DTACK, so even if DTACK arrived 20 clocks later, it wouldn't cause the CPU to do anything to fast. But the assumption is DTACK arrives in reasonably the right place.. In fact in terms of RAM access, DTACK is actually asserted a little bit faster than when data is actually ready. So I have to add in some delays there to compensate

ijor wrote: 31 Jan 2019 14:10 So you definitely need to decode, at the very least, for I/O access and take proper action. Note that MFP and MMU handle their own DTACK. Chip selection is still performed by GLUE.

MFP DTACK seems to behave reasonably well.. Similar with MMU DTACK.

At the moment, I just cannot see it being a DTACK related issue. I've got that many delays and waits everywhere machine is running slower now than a stock machine and it hasn't made any difference.

I have even been very careful around the bus grant stuff and added in safeguards and delays there as well.

I don't really understand why EMUTOS dies when accessing the YM registers.. The diagnostic cartridge passes sound test fine and I even hear the audio, so is not like there is even a error in that part of the design..

I am just assuming at this point that whatever was accessed before the sound registers in EMUTOS is actually the issue and is then causing the sound register to malfunction after that cycle.

exxos wrote: 31 Jan 2019 14:28 I am just assuming at this point that whatever was accessed before the sound registers in EMUTOS is actually the issue and is then causing the sound register to malfunction after that cycle.

This really looks like an EmuTOS bug :(
Something writes the value $7747 at address $0000c7bc between EmuTOS startup and before YM2149 initialization. The fact that the trashed code is just after YM2149 initialization may be completely random. YM2149 may not be actually related to the bug.
Questions are:
- Why is that address trashed? By what?
- Why this only happens on Exxos machine?

BlankVector wrote: 31 Jan 2019 16:07 - Why is that address trashed? By what?

I have no idea.. But also remember that TOS206 is generally happy... TOS104 has a odd error trying to format a floppy but otherwise works okay..

I'm assuming EMUTOS is based on pre TOS1.x sources ? so maybe EMUTOS has a extension to the faults I see in TOS104... ?

BlankVector wrote: 31 Jan 2019 16:07 - Why this only happens on Exxos machine?

Because exxos machine is only machine running 40 / 50MHz ?

I was trying to think if there was some loops of code acting as delays somewhere.. And when the CPU & ROM are running faster those delays are practically nothing at those speeds.. However, I don't think this can really happen because there is still the ST-RAM bottleneck... which is still 8MHz..

I can only think, (still) that is relating to BERR... But access to YM chip wouldn't cause the BERR as hardware is there...

EDIT:

But as EMUTOS runs at 16MHz, but not 50MHz, It seems more like a hardware issue ? But again I don't know what.

That debug version you sent me.. It seems to run though each setup step then error in the same place.. but.. What about doing the setup and reading back the values setup in each register it sets ? Maybe that would give some clues ?


EDIT:

I constantly get this same error today... With the debug version...


This SEC CPU is supposed to be 100% compatible with the 68000, but maybe its not ? But even so, that wouldn't explain why 16MHz works..