CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

Information and news about the 68SEC000 64MHz booster.
User avatar
exxos
Site Admin
Site Admin
Posts: 23497
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

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...
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
ijor
Posts: 428
Joined: Fri Nov 30, 2018 8:45 pm

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by ijor »

exxos wrote: Wed Jan 30, 2019 10:07 pmBERR 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.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
User avatar
exxos
Site Admin
Site Admin
Posts: 23497
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

ijor wrote: Thu Jan 31, 2019 1:30 am 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.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
exxos
Site Admin
Site Admin
Posts: 23497
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

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..

1.jpg
1.jpg (48.58 KiB) Viewed 3658 times
2.jpg
2.jpg (49.78 KiB) Viewed 3658 times
3.jpg
3.jpg (43.77 KiB) Viewed 3658 times
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..
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
exxos
Site Admin
Site Admin
Posts: 23497
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

BlankVector wrote: Wed Jan 30, 2019 11:33 pm 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..
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
ijor
Posts: 428
Joined: Fri Nov 30, 2018 8:45 pm

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by ijor »

exxos wrote: Thu Jan 31, 2019 10:56 amThough 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.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
User avatar
exxos
Site Admin
Site Admin
Posts: 23497
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

ijor wrote: Thu Jan 31, 2019 2:10 pm 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: Thu Jan 31, 2019 2:10 pm 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: Thu Jan 31, 2019 2:10 pm 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.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
BlankVector
Posts: 83
Joined: Fri Sep 15, 2017 10:51 pm

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by BlankVector »

exxos wrote: Thu Jan 31, 2019 2:28 pm 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?
Subscribe to my Vretrocomputing channel on YouTube and Facebook. Latest video: Disable the key click in assembly language on Atari ST.
User avatar
exxos
Site Admin
Site Admin
Posts: 23497
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

BlankVector wrote: Thu Jan 31, 2019 4:07 pm - 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: Thu Jan 31, 2019 4:07 pm - 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.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
exxos
Site Admin
Site Admin
Posts: 23497
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos »

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...

1.jpg
1.jpg (75.81 KiB) Viewed 3421 times

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..
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
Post Reply

Return to “SEC 64MHZ BOOSTER”