TS Forum

Well, I noticed that there also were problems in Baseconf (with SD) and supposed that some external device might interfere with the system bus. First idea was that TSFM cable does this, it happens often.
NGS can give noises if it has some internal parasitic capacitance on the bus signals, does it work properly or glitches sometimes?

Now that you mention, I had some glitches with the whole system previously, like not resetting properly, i.e. the ERS screen didn't show up after reset, only after several 0+reset or hard reset, or sometimes the file browser in ERS showed wrong contents when going to the parent directory, such things. But with the few GS games I tried, the NeoGS card itself seemed to work properly.

Also, sometimes some demos heavily stressing the system crashed during initialization in ZXEVO mode, like NedoDemo 2 and some others.

Well, I want to single out the problem source. Could you ensure that all mentioned glitches dissapear as NGS is pulled out?

The demos loaded, the ones that use NGS were without sound of course. The reset glitches seem to be also gone.

The problem with the file browser in ERS mode still occurs. It seems it might be a bug in 0.55. I don't remember this occuring with the last 0.54d revision, but I may have been lucky.
It might be case of out of memory / garbage in the memory contents after sot reset via F12, though. The SD card has the whole VTRDOS tree from the ZXEVO CD.
First I browsed several large subdirectories and then started the Bruce Lee GS variant. I played two minutes and then pressed F12, started the "File browse" menu, which was still in the vtrdos.ru/gamez/b directory, this was still OK.
The wrong directory contents showed up after I selected the parent directory, several duplicate ".." entries with and without the folder icon on the left side and other strange entries.
I will retry it with the last 0.54d later.

The directory listing bug is reproducible with the above procedure with 0.55 very reliably, 3 occurrence out of 3 attempts.
I even tried it with your last firmware binary that has the "FPGA: cache enable separated for 4 CPU windows" changes.
I also tried the same procedure with the pure BaseConf firmware file and it also gives me the same result.

But it doesn't happen with the last 0.54d ROM, SVN r639 from the pentevo Google Code repository plus the BaseConf firmware.
This is the supported configuration by group NedoPC, i.e. their firmware and ROM. I will take this bug report to their forum.

Let me notice that the Baseconf binary in my 'double' firmware is just a compilation from NedoPC repository. Also, CHRV is the main hardware man at the Pentevo project, so he can help you to find out the h/w problems in your case.
As for me, it seems to be a total h/w non-stability. If I were you, I would have examined the system signals with an oscilloscope and made some experiments.
Keep trying!

Thanks, I will ask CHRV. I don't have an oscilloscope, though, only a multimeter. I will ask around

I had other things to pursue since then but I followed the development iof TSconf (flashing new firmware versions as they were released) and now I have a contraindication with this game.
I observed the following with firmware with the IM2 fix and it happens both with and without NeoGS plugged into the machine.
Transition between levels don't lock up, up to level 4. Transition from level 4 to 5 (the first boss level) locks up pretty much always.
The symptom is usually a black screen. Sometimes the spinning gear appears but the 5th level doesn't appear. The gear stops spinning after a while and either it stays on the screen or the screen becomes black.

I used 7MHz and "#7FFD span: 1024K" all the time. The "Cache: ON/OFF" setting makes the difference. With cache on, Bomberman locks up after level 4 is completed, even when the NeoGS is not present. "ZXEvoTS&BASE 17.04.2014 beta"

zboszor wrote:I used 7MHz and "#7FFD span: 1024K" all the time. The "Cache: ON/OFF" setting makes the difference.

All above mentioned settings are overrode by the program itself. It writes $02 to SysConf register at the very beginning, which means: 14MHz, no memory lock (it doesn't matter, coz BM doesn't use $7FFD anyway), no cache.

To be frank, BM is (by some unknown reason) a very whimsy software. For me it is enigmatic why it stresses machine in so fancy way making it glitch. No other code glitches (as far as I know that the moment) on current hardware.
Still to be resolved. Thank you for reporting )

This bug feels like a problem with DMA versus cache or a lost interrupt. Which reminids me of a recent fix in the original BaseConf in r651:

pentevo: int signal length corrected for extensive wait states: while wait_n==0, int length counter doesn't count

Also, the 50/60Hz video refresh rate can be read back and this info is displayed by ERS 0.55c. When was the last time Base+TSConf took a snapshot from Baseconf?

zboszor wrote:This bug feels like a problem with DMA versus cache

Such a bug is possible due to lack of updating cached data being overwritten in DRAM by DMA. But such a bug is 100% deterministic and cannot be spontaneous. So this is not the case.

zboszor wrote:or a lost interrupt

INT can't be lost during DMA, ~WAIT is only formed at GLUclock or RS-232 addressing.

zboszor wrote:When was the last time Base+TSConf took a snapshot from Baseconf?

Well, mr. Noah made the last code merge right before he loaded his Ark. I'll merge it today.

TS-Labs wrote:

zboszor wrote:This bug feels like a problem with DMA versus cache

Such a bug is possible due to lack of updating cached data being overwritten in DRAM by DMA. But such a bug is 100% deterministic and cannot be spontaneous. So this is not the case.

I see.

TS-Labs wrote:

zboszor wrote:or a lost interrupt

INT can't be lost during DMA, ~WAIT is only formed at GLUclock or RS-232 addressing.

What about 14MHz? It's supposed to have extended wait states and the description of r651 from the pentevo SVN looks exactly like that.
You also wrote previously that this game switches to 14MHz. The interrupt signal length problem may trigger this problem if the CPU is stressed.

TS-Labs wrote:

zboszor wrote:When was the last time Base+TSConf took a snapshot from Baseconf?

Well, mr. Noah made the last code merge right before he loaded his Ark. I'll merge it today.

That was quite a while ago, then.
How about a test firmware for Base+TSconf with the same interrupt length fix applied to the TSconf side? Or do we get it automatically after the merge?

zboszor wrote:What about 14MHz? It's supposed to have extended wait states

~WAIT is idle at 14MHz, CPU is delayed by only means of its CLK freezing, and generally CLK is coerced to 7MHz.

zboszor wrote:and the description of r651 from the pentevo SVN looks exactly like that.

It only freezes pending ~INT when ~WAIT is active.

zboszor wrote:The interrupt signal length problem may trigger this problem if the CPU is stressed.

No, ~INT has a length of 32 CPU Tstates of 3.5MHz at maximum. So, it's long enough.

zboszor wrote:How about a test firmware for Base+TSconf with the same interrupt length fix applied to the TSconf side?

I will apply this feature ASAP.

zboszor wrote:Or do we get it automatically after the merge?

No, because merge will only update the binary of Base conf in the combined firmware.

Check current revision, please.

I tried it and unfortunately it didn't help. The same lockup happens after level 4 with the new firmware.

I tried the latest firmware that killed the overclocked 14+ MHz. Unfortunately, it didn't help. I tried both the TRD and SPG format of Bomberman. It's rare that the transition to level 5 doesn't lock up.

Говнокод.

Исправлен злополучный баг.
В процессе поиска по всем банкам игры нашлось 3 совпадения строки 01AF213E0CED79, исправил их все.
Просьба протестировать при случае проходимость.