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 wrote:sebdel wrote:Are you sure it never exits from that loop?
It's no more a MiSTery
Moderators: Mug UK, Zorro 2, spiny, Greenious, Moderator Team
Re: It's no more a MiSTery
Re: It's no more a MiSTery
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 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.slingshot wrote:sebdel wrote:Are you sure it never exits from that loop?
Re: It's no more a MiSTery
In this particular case I could unpack the .prg so I can patch it. I will add "color stops" like this:slingshot wrote: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 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.slingshot wrote:
Code: Select all
stop: move.w $700, $8240.w
bra stop
Re: It's no more a MiSTery
Clever trick.sebdel wrote:I should find where it loops eventually.Code: Select all
stop: move.w $700, $8240.w bra stop
Re: It's no more a MiSTery
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.slingshot wrote: ... DMA and the Shifter don't even have a reset pin
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.Did you know the MegaSTE external keyboard doesn't have the reset line, so ikbd reset doesn't work there?
Btw, great work on MiSTery!

Fx Cast: Atari St cycle accurate fpga core
Re: It's no more a MiSTery
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.ijor wrote: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.slingshot wrote: ... DMA and the Shifter don't even have a reset pin
Thanks! Just if Closure would work in ST mode...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.Did you know the MegaSTE external keyboard doesn't have the reset line, so ikbd reset doesn't work there?
Btw, great work on MiSTery!
Re: It's no more a MiSTery
I think it is relatively easy as long as you can use a software emulator debugger to compare the tracesslingshot wrote:But hardware debugging is a very tedious, time-consuming and hard job. No wonder why nobody ironing out the last bugs in cores.

For MMU is both DEV and RAM asserted at the same time.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 DMA is CS asserted for more than 16 cycles.
Fx Cast: Atari St cycle accurate fpga core
Re: It's no more a MiSTery
True. Btw, I miss some raster position indicator from ST emulators. It was nice in WinAPE, the CPC emulator.ijor wrote:I think it is relatively easy as long as you can use a software emulator debugger to compare the tracesslingshot wrote:But hardware debugging is a very tedious, time-consuming and hard job. No wonder why nobody ironing out the last bugs in cores.It is several orders of magnitude harder when for some reason you can't.
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.For MMU is both DEV and RAM asserted at the same time.
For DMA is CS asserted for more than 16 cycles.
And even MMU is integrated, RAM_N and DEV_N also going to low during reset.
Re: It's no more a MiSTery
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.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.
Fx Cast: Atari St cycle accurate fpga core
Re: It's no more a MiSTery
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 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.
Re: It's no more a MiSTery
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.slingshot wrote: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 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.
Fx Cast: Atari St cycle accurate fpga core
Re: It's no more a MiSTery
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.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.
Re: It's no more a MiSTery
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.slingshot wrote:Clever trick.sebdel wrote:I should find where it loops eventually.Code: Select all
stop: move.w $700, $8240.w bra stop
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: http://www.atari-forum.com/viewtopic.ph ... 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.
Re: It's no more a MiSTery
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.
-
- Captain Atari
- Posts: 174
- Joined: Fri Aug 12, 2005 11:33 pm
- Location: Austin, TX, USA
- Contact:
Re: It's no more a MiSTery
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.
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.
Re: It's no more a MiSTery
Well, that long discussion with sebdel was about that. However it's an STe demo (but not sure if the bug is STe specific).
Ah, I see it's a different demo with the same bug (same play engine?) - maybe easier to debug.
Ah, I see it's a different demo with the same bug (same play engine?) - maybe easier to debug.
-
- Captain Atari
- Posts: 174
- Joined: Fri Aug 12, 2005 11:33 pm
- Location: Austin, TX, USA
- Contact:
Re: It's no more a MiSTery
I should have reread the other conversation because I did wonder if it was related.slingshot wrote:Well, that long discussion with sebdel was about that. However it's an STe demo (but not sure if the bug is STe specific).
Ah, I see it's a different demo with the same bug (same play engine?) - maybe easier to debug.
It's not an STe only demo -- it works fine on an STFM, too.
Re: It's no more a MiSTery
Is there any game/test/anything which uses the analogue paddle connected to the STe joystick ports?
-
- Atari maniac
- Posts: 93
- Joined: Sun Sep 24, 2017 6:18 pm
Re: It's no more a MiSTery
Only things I found that support EJP's analog were made for Falcon.slingshot wrote:Is there any game/test/anything which uses the analogue paddle connected to the STe joystick ports?

Re: It's no more a MiSTery
Then not much value of adding support. Cannot even test it.Televicious wrote:
Only things I found that support EJP's analog were made for Falcon.
Re: It's no more a MiSTery
Good news, it's fixed (also the other STe demo disk works).jamesrc wrote:For reasons I don't completely understand, the HIPSid disk/demo doesn't work properly on my MiST.
II'll go add to the Github Demos issue.
-
- Captain Atari
- Posts: 174
- Joined: Fri Aug 12, 2005 11:33 pm
- Location: Austin, TX, USA
- Contact:
Re: It's no more a MiSTery
If you're ever in Texas, I'll buy you a drink or five.slingshot wrote:Good news, it's fixed (also the other STe demo disk works).jamesrc wrote:For reasons I don't completely understand, the HIPSid disk/demo doesn't work properly on my MiST.
II'll go add to the Github Demos issue.
THANK YOU!!
(Quick edit: I don't see any recent commits to your repo, so am I correct in assuming you've not pushed these changes yet?)
Re: It's no more a MiSTery
Not yet, there are some other surprises waiting. I'm afraid I'm too far away for some beer from Texas - but would be good, thanksjamesrc wrote:
(Quick edit: I don't see any recent commits to your repo, so am I correct in assuming you've not pushed these changes yet?)

-
- Captain Atari
- Posts: 174
- Joined: Fri Aug 12, 2005 11:33 pm
- Location: Austin, TX, USA
- Contact:
Re: It's no more a MiSTery
Long weekend here in the States.
Being British, I have no great nostalgic attachment to Thanksgiving, but I'll take the four days off and the meal.
Might be an opportunity to continue my slog through those PoV disks...
Being British, I have no great nostalgic attachment to Thanksgiving, but I'll take the four days off and the meal.
Might be an opportunity to continue my slog through those PoV disks...
Re: It's no more a MiSTery
Good idea, you might report if you found some bugs.jamesrc wrote:Long weekend here in the States.
Being British, I have no great nostalgic attachment to Thanksgiving, but I'll take the four days off and the meal.
Might be an opportunity to continue my slog through those PoV disks...
Meanwhile I fixed POV7 Pro Replay.
Hope I can upload the sources soon (but the git version will require a firmware update for ACSI - however it's not required for floppy demos).