It's no more a MiSTery

https://github.com/mist-devel/mist-board/wiki

Moderators: Mug UK, Zorro 2, Greenious, spiny, Moderator Team

sebdel
Captain Atari
Captain Atari
Posts: 169
Joined: Fri Dec 30, 2005 9:29 am

Re: It's no more a MiSTery

Postby sebdel » Wed Oct 16, 2019 8:40 am

slingshot wrote:
sebdel wrote:Are you sure it never exits from that loop?

No I'm not, I'm just stepping through it in Hatari and guessing. This is not going anywhere, I will try a different approach.

slingshot
Atari God
Atari God
Posts: 1264
Joined: Mon Aug 06, 2018 3:05 pm

Re: It's no more a MiSTery

Postby slingshot » Wed Oct 16, 2019 8:51 am

sebdel wrote:
slingshot wrote:
sebdel wrote:Are you sure it never exits from that loop?

No I'm not, I'm just stepping through it in Hatari and guessing. This is not going anywhere, I will try a different approach.

If you want to also check on FPGA, I can send you the .stp file I used last time to watch "breakpoints". But hardware debugging is a very tedious, time-consuming and hard job. No wonder why nobody ironing out the last bugs in cores. Better to have test suites or write small test programs, but then you must know what to check.

sebdel
Captain Atari
Captain Atari
Posts: 169
Joined: Fri Dec 30, 2005 9:29 am

Re: It's no more a MiSTery

Postby sebdel » Wed Oct 16, 2019 9:42 am

slingshot wrote:
sebdel wrote:
slingshot wrote:

No I'm not, I'm just stepping through it in Hatari and guessing. This is not going anywhere, I will try a different approach.

If you want to also check on FPGA, I can send you the .stp file I used last time to watch "breakpoints". But hardware debugging is a very tedious, time-consuming and hard job. No wonder why nobody ironing out the last bugs in cores. Better to have test suites or write small test programs, but then you must know what to check.

In this particular case I could unpack the .prg so I can patch it. I will add "color stops" like this:

Code: Select all

stop: move.w $700, $8240.w
   bra stop

I should find where it loops eventually.

slingshot
Atari God
Atari God
Posts: 1264
Joined: Mon Aug 06, 2018 3:05 pm

Re: It's no more a MiSTery

Postby slingshot » Wed Oct 16, 2019 11:31 am

sebdel wrote:

Code: Select all

stop: move.w $700, $8240.w
   bra stop

I should find where it loops eventually.

Clever trick.

ijor
Hardware Guru
Hardware Guru
Posts: 3821
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: It's no more a MiSTery

Postby ijor » Thu Oct 17, 2019 4:13 pm

slingshot wrote: ... DMA and the Shifter don't even have a reset pin


All the custom chipset has hardware reset, including DMA, Shifter and ST MMU. You don't necessarily need a reset pin. They perform reset when they detect some external signals are in a condition that can happen only during Reset. Shifter, e.g, resets when both LOAD and CS are asserted at the same time. Can lookup the others if you are interested.

Did you know the MegaSTE external keyboard doesn't have the reset line, so ikbd reset doesn't work there?


Yes, this is well known. Any software that depends on the IKBD reset signal won't work on the Mega. Not just the MegaSTE, but the MegaST as well.

Btw, great work on MiSTery! :)
Fx Cast: Atari St cycle accurate fpga core

slingshot
Atari God
Atari God
Posts: 1264
Joined: Mon Aug 06, 2018 3:05 pm

Re: It's no more a MiSTery

Postby slingshot » Thu Oct 17, 2019 5:42 pm

ijor wrote:
slingshot wrote: ... DMA and the Shifter don't even have a reset pin


All the custom chipset has hardware reset, including DMA, Shifter and ST MMU. You don't necessarily need a reset pin. They perform reset when they detect some external signals are in a condition that can happen only during Reset. Shifter, e.g, resets when both LOAD and CS are asserted at the same time. Can lookup the others if you are interested.

Now I know why the GSTMCU asserts CMPMCS_N and DCYC_N together at power-on. Would be interesting to know the other combinations, even if it's already a reset signal for most of the chips.

Did you know the MegaSTE external keyboard doesn't have the reset line, so ikbd reset doesn't work there?


Yes, this is well known. Any software that depends on the IKBD reset signal won't work on the Mega. Not just the MegaSTE, but the MegaST as well.

Btw, great work on MiSTery! :)

Thanks! Just if Closure would work in ST mode...

ijor
Hardware Guru
Hardware Guru
Posts: 3821
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: It's no more a MiSTery

Postby ijor » Sat Oct 19, 2019 1:13 am

slingshot wrote:But hardware debugging is a very tedious, time-consuming and hard job. No wonder why nobody ironing out the last bugs in cores.


I think it is relatively easy as long as you can use a software emulator debugger to compare the traces :) It is several orders of magnitude harder when for some reason you can't.

slingshot wrote:Now I know why the GSTMCU asserts CMPMCS_N and DCYC_N together at power-on. Would be interesting to know the other combinations, even if it's already a reset signal for most of the chips.


For MMU is both DEV and RAM asserted at the same time.
For DMA is CS asserted for more than 16 cycles.
Fx Cast: Atari St cycle accurate fpga core

slingshot
Atari God
Atari God
Posts: 1264
Joined: Mon Aug 06, 2018 3:05 pm

Re: It's no more a MiSTery

Postby slingshot » Sat Oct 19, 2019 10:27 am

ijor wrote:
slingshot wrote:But hardware debugging is a very tedious, time-consuming and hard job. No wonder why nobody ironing out the last bugs in cores.


I think it is relatively easy as long as you can use a software emulator debugger to compare the traces :) It is several orders of magnitude harder when for some reason you can't.

True. Btw, I miss some raster position indicator from ST emulators. It was nice in WinAPE, the CPC emulator.

For MMU is both DEV and RAM asserted at the same time.
For DMA is CS asserted for more than 16 cycles.

Oh yeah, FCS_N is asserted at reset for this reason then. I wonder if it can be triggered in software. I think the CPU won't select the DMA chip for 16 cycles.
And even MMU is integrated, RAM_N and DEV_N also going to low during reset.

ijor
Hardware Guru
Hardware Guru
Posts: 3821
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: It's no more a MiSTery

Postby ijor » Sat Oct 19, 2019 11:59 am

slingshot wrote:Oh yeah, FCS_N is asserted at reset for this reason then. I wonder if it can be triggered in software. I think the CPU won't select the DMA chip for 16 cycles.


It's not up to the CPU. It's actually up to the DMA chip itself depending on how many wait states it would produce on an access. But no, I don't think it would happen even in the worst case.
Fx Cast: Atari St cycle accurate fpga core

slingshot
Atari God
Atari God
Posts: 1264
Joined: Mon Aug 06, 2018 3:05 pm

Re: It's no more a MiSTery

Postby slingshot » Sat Oct 19, 2019 12:22 pm

ijor wrote:
It's not up to the CPU. It's actually up to the DMA chip itself depending on how many wait states it would produce on an access. But no, I don't think it would happen even in the worst case.

Yes, but it's not really software-triggerable (I was just speculating if it would be possible to reset the DMA via software - not by changing the direction bit, which does reset the FIFOs in the current implementation).

ijor
Hardware Guru
Hardware Guru
Posts: 3821
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: It's no more a MiSTery

Postby ijor » Sat Oct 19, 2019 12:58 pm

slingshot wrote:
ijor wrote:
It's not up to the CPU. It's actually up to the DMA chip itself depending on how many wait states it would produce on an access. But no, I don't think it would happen even in the worst case.

Yes, but it's not really software-triggerable (I was just speculating if it would be possible to reset the DMA via software - not by changing the direction bit, which does reset the FIFOs in the current implementation).


I think I did understand what you meant. You meant if software could somehow provoke the CPU/GLUE to assert DMA chip select for more than 16 cycles, right? What I meant is that if something like that could be possible or not, it depends on how many wait states the DMA chip inserts (indirectly thorugh GLUE) on a bus access.
Fx Cast: Atari St cycle accurate fpga core

slingshot
Atari God
Atari God
Posts: 1264
Joined: Mon Aug 06, 2018 3:05 pm

Re: It's no more a MiSTery

Postby slingshot » Sat Oct 19, 2019 1:14 pm

ijor wrote:I think I did understand what you meant. You meant if software could somehow provoke the CPU/GLUE to assert DMA chip select for more than 16 cycles, right? What I meant is that if something like that could be possible or not, it depends on how many wait states the DMA chip inserts (indirectly thorugh GLUE) on a bus access.

I think we can agree on this. It depends on how many cycles after FCS_N DMA asserts RDY. It won't be 16 cycles in any case I guess, so no software will depend on it - no problem if this kind of reset is not implemented.

sebdel
Captain Atari
Captain Atari
Posts: 169
Joined: Fri Dec 30, 2005 9:29 am

Re: It's no more a MiSTery

Postby sebdel » Thu Nov 07, 2019 8:32 am

slingshot wrote:
sebdel wrote:

Code: Select all

stop: move.w $700, $8240.w
   bra stop

I should find where it loops eventually.

Clever trick.


Just a quick update on this: I progressed far enough that I could see weird usage of trace vector but then I had to pack my Mist as we are renovating the house. So no more mist for me until at least Xmas I reckon.
Then out of nowhere leonard had a look at 0913 for completely different reasons and apparently this music disk has a protection against ripping, you can read more here: viewtopic.php?f=1&t=37735&start=25#p386003
Sooo, maybe the trace vector decoder is not working? I don't see why it would not but that looks like the most likely explanation now.

slingshot
Atari God
Atari God
Posts: 1264
Joined: Mon Aug 06, 2018 3:05 pm

Re: It's no more a MiSTery

Postby slingshot » Thu Nov 07, 2019 9:11 am

I don't think such bug exists in the CPU. It's more like a timer doesn't switched on after the loading (MFP), or the disk DMA and blitter DMA are conflicting (might be some events don't happen at the right time during DMA). It's hard to tell without digging into it deeper, and I don't want to do it until we have an accurate blitter.

jamesrc
Atari maniac
Atari maniac
Posts: 85
Joined: Fri Aug 12, 2005 11:33 pm
Location: Austin, TX, USA
Contact:

Re: It's no more a MiSTery

Postby jamesrc » Tue Nov 19, 2019 12:37 am

For reasons I don't completely understand, the HIPSid disk/demo doesn't work properly on my MiST.

It starts correctly, but if you select a different music track it never starts to play. The UI continues to be responsive.

http://www.pouet.net/prod.php?which=70807

This was a problem with the old core, too.

I'll go add to the Github Demos issue.


Return to “MiST”

Who is online

Users browsing this forum: No registered users and 2 guests