exxos blog - random goings on

Blogs & guides and tales of woo by forum members.
User avatar
exxos
Site Admin
Site Admin
Posts: 23499
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: exxos blog - random goings on

Post by exxos »

ijor wrote: Fri Jun 07, 2019 4:28 pm I told you in the other thread that if you bypass the chipset clock division you will create some subtle wakeup issues.
subtle may have been a bit of a understatement ;) There is like a 1 in 4 chance of it working on power up.. oddly I have not had any issues until this week... I literally was turning it off and on for a couple of weeks soak testing and never had any problems. Icky Still does not have these issues at all.. bizzare..

So the only way forward is to continue with the FPGA stuff. if we develop a FPGA board to fit the current remake board, to replace the MMU & GLUE for starters ( I do not know if this will be better all inside a single FPGA or combine the 2 cores into a single FPGA chip) , but in anycase, could you help fit your cores onto our board ? I know you said it was closed source for the moment, we don't need the source code, we just need the file to program to fit our board...
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: exxos blog - random goings on

Post by ijor »

exxos wrote: Fri Jun 07, 2019 5:03 pm So the only way forward is to continue with the FPGA stuff. if we develop a FPGA board to fit the current remake board, to replace the MMU & GLUE for starters ( I do not know if this will be better all inside a single FPGA or combine the 2 cores into a single FPGA chip) , but in anycase, could you help fit your cores onto our board ? I know you said it was closed source for the moment, we don't need the source code, we just need the file to program to fit our board...
I'm not sure an FPGA it is the only way to solve this issue. There might be other alternatives.

But, yes, of course, I will certainly help you fit my cores regardless.
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: 23499
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: exxos blog - random goings on

Post by exxos »

ijor wrote: Fri Jun 07, 2019 5:12 pm I'm not sure an FPGA it is the only way to solve this issue. There might be other alternatives.
I did try using the MMU 8Mhz (now 16MHz) and running that into the 161 to generate the clocks, but still had random start up issues as before. So I don't think its totally down to wake up states on the MMU causing issues.

If the MMU had a reset pin there wouldn't be any issues (or at least a lot less).

There may well be solutions to fix the Atari chip issues, but IMO time would be better spent in developing a new MMU & GLUE... While getting the Atari MMU to turn faster would be (and is) awesome, its a bit of a dead-end project. The FPGA would allow us to jump to 32MHz for example.

ijor wrote: Fri Jun 07, 2019 5:12 pm But, yes, of course, I will certainly help you fit my cores regardless.
Awesome thanks. This will probably be some months down the line before we get that far with everything else going on as well. We are still trying to get the suska blitter core working currently but progress is slow.
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: exxos blog - random goings on

Post by ijor »

exxos wrote: Fri Jun 07, 2019 5:45 pm I did try using the MMU 8Mhz (now 16MHz) and running that into the 161 to generate the clocks, but still had random start up issues as before. So I don't think its totally down to wake up states on the MMU causing issues.

If the MMU had a reset pin there wouldn't be any issues (or at least a lot less).
I agree that it doesn't seem just a wake up issue.

MMU does have hardware reset, even it is not a dedicated reset pin. IIRC it is when both RAM and DEV pins are asserted at the same time. But note that it won't solve the wakeup issue, because the relevant flops are not initialized on hardware reset. That's precisely the reason that it has a wakeup behavior that only changes across power up cycles.

There is an internal power up signal that does reset those flops. It is activated when even more signals are all asserted together (need to check exactly which ones). But I'm not sure how reliable this is, and also don't know for sure if it's the same across all chipset versions.
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: 23499
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: exxos blog - random goings on

Post by exxos »

ijor wrote: Fri Jun 07, 2019 8:12 pm MMU does have hardware reset, even it is not a dedicated reset pin. IIRC it is when both RAM and DEV pins are asserted at the same time. But note that it won't solve the wakeup issue, because the relevant flops are not initialized on hardware reset. That's precisely the reason that it has a wakeup behavior that only changes across power up cycles.

There is an internal power up signal that does reset those flops. It is activated when even more signals are all asserted together (need to check exactly which ones). But I'm not sure how reliable this is, and also don't know for sure if it's the same across all chipset versions.
Very interesting...
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: 23499
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: exxos blog - random goings on

Post by exxos »

I have been half thinking if CPU DTACK was synchronised to the MMU clock.. that it would actually add in some delays which could help cure some problems... I am thinking, or working, on the assumption that if the CPU is running in a state where it is actually reading DTACK to early, that this is going to screw up the system... And other times on power up, the CPU will be more in phase with the MMU and DTACK is read later and the system works.

Of course there may be other signals which need synchronisation, but really just thinking out loud here in trying to make the startup states not matter..

Mostly the states I have observed so far are..

1) everything works fine.
2) It goes to desktop and floppy refuses to work.
3) System appears to be running (boots from floppy) but video is constantly white.
4) no boot at all.


But then again, I did try a delay on the 8MHz lines and it didn't seem to solve anything.. but I may revisit that more in depth...
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
stephen_usher
Posts: 5580
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: exxos blog - random goings on

Post by stephen_usher »

I’m thinking out loud here, but could you use the MMU clock on power up to trigger the clock on your board in some way so that it’s deterministically in phase with the MMU? Maybe using it to trigger the power to the crystal or crystal signal to the CPU clock generator?
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.
User avatar
exxos
Site Admin
Site Admin
Posts: 23499
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: exxos blog - random goings on

Post by exxos »

stephen_usher wrote: Fri Jun 07, 2019 10:55 pm I’m thinking out loud here, but could you use the MMU clock on power up to trigger the clock on your board in some way so that it’s deterministically in phase with the MMU? Maybe using it to trigger the power to the crystal or crystal signal to the CPU clock generator?
You know that kinda passed my mind as well earlier... but triggering a second osc would never be 100% in phase.. it would drift..

Oddly though, I did trigger my clock board from the MMU clock and still had issues.. so something else is going wonky somewhere as well :(
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: 23499
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: exxos blog - random goings on

Post by exxos »

I was looking at the ste combo schematic and found the clock dividers. Interestingly the reset lines are all tied ultimately to a test pin. I assume its there to allow the debug guys to start the machine from a known state each time. Doesn't help with the ST MMU, but just thought I would look anyway.

I have tried various delays on all the clocks. I used a LS04, so could flip clocks out of phase or use 2 inverters to add a delay. Basically nothing helped.

I did hook up the 161 to the MMU clock to rule out MMU wait states.. Well kinda,. But that still didn't work. It did shift the video a few pixels to the right and wrap around, but those issues I had years ago when doing the mod tests. It seems if the glue is slightly behind the MMU clock it causes shifts in the video.

So while we know the clocks shift on the MMU, I am thinking its not the main cause of issues. Most of the time it seems to be the DMA malfunctioning. So assuming the glue is causing the MMU to confuse what is accessing ram, ie CPU or DMA.

Of course is the MMU and GLUE have random startup states, and I introduce then clocks with the 161, there's no surprise things are going nuts. But again, running from the MMU clock into the 161 should really help solve some issues.

The one solution I can come up with, is to forget the 161 and just down clock the MMU clocks directly with their own flip flops. This doesn't work as a few ns causes the glue to skew the video. So my thought is to go via a flipflop to half the clocks, but then have a inverter to flip the clock out of phase, and add in a adjustable delay line, maybe 5ns steps to realign the clocks again. So the propagation delays are corrected.

As to if that would correct the issues I am skeptical, again as using the MMU clock to drive the 161 didn't help, and that clock would include the wake up states as a stock machine would. So I don't think its simply a clock sync issue.

I think its more as the MMU is running double speed, and the GLUE is still running 8mhz that the MMU may be thinking it can do a DMA cycle when it actually can't. It would be like the glue tells the MMU its got a DMA cycle, so it holds off the cpu and triggers the bus isolators to the cpu... Twice as fast.. Where the cpu may not have finished its cycle yet. I have seen some odd stuff with some graphics missing on boot so maybe that's a clue.

Another probably bad idea , to switch the MMU to stock speeds during any bus grant activity.. But not really a good option either. I mean the system works fine when it starts up OK, so its not like the system can't work that way.

Mostly just thinking out loud with all this. While there are multiple issues, if the DMA issue could be figured out, then that would be half the battle.


EDIT: I may check the phases of the 161 generated clock vs the GLUE generated clock to see if that is shifting in phase causing the issue...
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: exxos blog - random goings on

Post by ijor »

exxos wrote: Sun Jun 09, 2019 1:29 am I was looking at the ste combo schematic and found the clock dividers. Interestingly the reset lines are all tied ultimately to a test pin. I assume its there to allow the debug guys to start the machine from a known state each time. Doesn't help with the ST MMU, but just thought I would look anyway.
The TEST pin is present in ST GLUE and it does can be used for this purpose (it has a different purpose as well). See Troed's method to select GLUE wakeup:
https://blog.troed.se/projects/atari-st ... te-nudger/

But ...
EDIT: I may check the phases of the 161 generated clock vs the GLUE generated clock to see if that is shifting in phase causing the issue...
I doubt your problem, at least your main problem, is related to GLUE wake state. In the worst case this could cause video problems, but shouldn't affect anything else. If your problem is related to wakeup then it is probably at MMU clock division, not at GLUE.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
Post Reply

Return to “MEMBER BLOGS”