help - something wrong with my Unnamed copy?

[xhul]

Happy 2023!

 

I finally received a fresh physical copy of Unnamed yesterday.

I know the game isn't exactly supposed to be easy, but i'm starting to believe i may have encountered some sort of nasty bug.

Long story short, i'm stuck at the very beginning, unable to progress any further =[

For now, i managed to find the rusty crowbar in the wooden crate, and that's pretty much it.

There seems to be no more item to find in the area, and the crowbar can't be used on anything (i was expecting to be able to use it on the door or cracked wall but no).

 

So, i would be very grateful if somebody could just tell me if i miss something, but please don't spoil me if that's the case.

 

At least that doesn't seem to be related to eeprom data corruption, since all games (new or loaded) behave the same way.

Other than that progression break, i didn't notice anything else suspicious, the video & audio are fine.

 

Thanks in advance for your time.

[xhul]

Sorry for the double post, but i found the solution.

I underestimated the game big time.

I'm gonna love it.

[+jgkspsx]

Congratulations! I got pretty far but not to the end yet.

[Songbird]

You have to complete this game. It's one of my favorites over the past few years, and I can say that since I didn't design it.

 

[xhul]

1 hour ago, Songbird said:

You have to complete this game. It's one of my favorites over the past few years, and I can say that since I didn't design it.

 

Will do my best to complete it before leaving this world, including the secondary mode.

I reached the chapel, but got stuck again, so i decided it was a good occasion to do a break.

I can't wait to progress further, but the original lynx LCD doesn't do it justice at all, not to mention mine is a dead pixel fest.

Waiting for the bennvenn now, and then i'm back to that wonderful head-scratching.

Thanks for the shipping by the way =]

Edited January 10, 2023 by xhul

[WesleyrpgAust]

This game does look great and it's on my next 'to buy' list the only issue being i don't want to play it on the crappy old screen on the Lynx.

 

Hopefully the Atari Lynx adapter for the Analogue Pocket releases soon!

 

 

[+jgkspsx]

15 hours ago, Songbird said:

You have to complete this game. It's one of my favorites over the past few years, and I can say that since I didn't design it.

 

D'oh, I confused Unnamed and Unseen again. I have completed Unnamed innumerable times

 

If you get stuck and want a spoiler-free nudge in the right direction feel free to message me.

[xhul]

When i created this topic, i initially thought something was wrong with my cart, but like i mentioned earlier, i was 100% wrong at the time.

 

After a decent break, i recently started enjoying the game again, using a fresh bennvenn LCD =]

Unfortunately, that enjoyment was pretty short, cause i'm facing something very different right now, that might not exactly help my progress through the game at all.

Indeed, occasionally, my saves become corrupted, how ironic is that.

Basically, the display gets stuck at the "save loaded" screen, and only the music of the area is properly loaded.

When that happens, the only thing to do is to actually overwrite the save, meaning the loss of all progress =[

It happened to me something like 4 times already.

 

Considering i barely used the game since i purchased it, i doubt the eeprom reached its end of life already, but it could be defective.

The more likely scenario is that saving the game in a very specific context actually triggers the data corruption.

At least i know that on all the occurrences, i just switched from one room to another, and saved before doing anything else (while of course waiting long enough before turning the lynx off).

Following that theory, i was able to replicate the corruption a couple times, but then it magically stopped happening.

For now, my saves & loads seem to work fine, the next step is to manage to corrupt a save in a different context, to fully disprove my theory.

Another explanation could be that a specific memory region on the eeprom is compromised, in which case things could be fine if saves are stored elsewhere.

 

Anyway, i'll continue to try to isolate a potential faulty context, really hoping the eeprom is fine.

Sorry for the long read =P

Edited February 7, 2023 by xhul

[+jgkspsx]

I played through the game dozens of times and saved everywhere. I would be surprised if there were a major code bug in the save code. I would ask @Songbird for a replacement.

[xhul]

1 hour ago, jgkspsx said:

I played through the game dozens of times and saved everywhere. I would be surprised if there were a major code bug in the save code. I would ask @Songbird for a replacement.

I think i'll continue my investigation before ever considering that.

I mean, if that's purely software, it would be good to know how to actually avoid triggering it, but also for the dev to update the product.

Since you have the game as well, i may have a question for you, did you ever use the "erase save" option at least once since you got it?

No matter what your answer is, don't use it, at least for now, because according to my recent tests, it may be involved.

 

So i continued the testing for a while, and was able to corrupt something like 3 more saves in the process.

At least i can say for sure that my theory about rooms being just loaded can be discarded, cause i managed to corrupt a save in a totally different context.

There seems to be some kind of cycle involved, like 9-10 saves ok, then 3-4 saves not, etc.

Doesn't sound good, because that would actually support the defective eeprom region theory.

On the other hand, i need to play a little more with the "erase save" option, because i currently suspect that part of the code does some nasty things.

More to come...

Edited February 7, 2023 by xhul

[+jgkspsx]

Nope, I never deleted a save.

[Songbird]

I did actually see the behavior you described a couple of times during testing, simply by starting a game, saving it in the first room, powering the Lynx off and on, and loading the save. However I found that once I erase a save for the first time, the problem would not repeat. I assumed it was some stale data in the EEPROM, which, once erased, no longer exhibits the problem. Thus I test every Unnamed cart I manufacture to ensure it can both save data to EEPROM and successfully load a saved game. Also we double-checked the EEPROM code routines, and could not find any obvious issues which would result in this behavior.

 

If you are seeing intermittent problems with this, I would recommend just experimenting with saves in the very first room.

 

[xhul]

2 hours ago, jgkspsx said:

Nope, I never deleted a save.

Thanks again.

 

1 hour ago, Songbird said:

I did actually see the behavior you described a couple of times during testing, simply by starting a game, saving it in the first room, powering the Lynx off and on, and loading the save. However I found that once I erase a save for the first time, the problem would not repeat. I assumed it was some stale data in the EEPROM, which, once erased, no longer exhibits the problem. Thus I test every Unnamed cart I manufacture to ensure it can both save data to EEPROM and successfully load a saved game. Also we double-checked the EEPROM code routines, and could not find any obvious issues which would result in this behavior.

 

If you are seeing intermittent problems with this, I would recommend just experimenting with saves in the very first room.

 

Thanks for the reply.

 

Interesting that you witnessed the same behaviour, i feel less alone in some way.
I can confirm that in my case, erasing a save doesn't help, it even looks like it's actually one of the ingredients that trigger the corruption, indirectly.

 

If both the save & load codes are as flawless as they should be, no matter how stale the data was, it shouldn't interfer at all (assuming the eeprom is fine of course).
So if there's actually a flaw in the code, that's a tricky one.

 

I mostly did my tests in the chapel room, because that's where it started happening.
As a matter of fact, most of the corruptions occured in that room, but i've also seen 1 in the starting room, and 1 in the small room where you get the diamond.
But yeah, the starting room is ideal for obvious reasons, and though i've been quite unlucky triggering the corruption there, i'll probably test it a bit more.

 

I may have a few questions that could help me to test in the right direction, if that's ok:

 

1) How do the writings work with such eeprom?
I assume there's a programming command (can't change bits from 0 to 1), and an erase command (sets bits on a whole region), please let me know if i'm far from it.

 

And if you've actually seen the eeprom-related code, and remember enough of it:

 

2) Do you know if saves have a fixed length? If yes, what about their size?

 

3) Do you know how the "erase save" option behave? Does it simply mark the current save as dirty, or does it erase the whole eeprom region?
If it just writes a dirty marker, is the very same routine also executed when saving the game?

Edited February 7, 2023 by xhul

[Songbird]

The "save game" always saves the entire data set which fills about two-thirds of the EEPROM. It doesn't matter how much or how little you have explored. Likewise, the "erase save" option always erases the entire EEPROM and sets it back to default word values ($FFFF).

 

It is possible you have a marginal EEPROM on your cartridge, which makes it an intermittent hardware problem rather than a software problem. Although it would be fair to say we do not have robust handling in the software for any detected hardware problems, thus the game hangs. If you purchased from Songbird, I can replace it if needed. I think I had one other customer who had the very first save glitch like this, but once I walked him through the erase procedure, he confirmed everything worked fine. I'm not aware of any other customers seeing repeated save issues, which is what makes me suspect the EEPROM more than the code.

 

[xhul]

6 hours ago, Songbird said:

The "save game" always saves the entire data set which fills about two-thirds of the EEPROM. It doesn't matter how much or how little you have explored. Likewise, the "erase save" option always erases the entire EEPROM and sets it back to default word values ($FFFF).

 

It is possible you have a marginal EEPROM on your cartridge, which makes it an intermittent hardware problem rather than a software problem. Although it would be fair to say we do not have robust handling in the software for any detected hardware problems, thus the game hangs. If you purchased from Songbird, I can replace it if needed. I think I had one other customer who had the very first save glitch like this, but once I walked him through the erase procedure, he confirmed everything worked fine. I'm not aware of any other customers seeing repeated save issues, which is what makes me suspect the EEPROM more than the code.

 

Thanks a lot for the details.

 

Continued the testing, and managed to trigger 2 more corruptions, in a row.
Cool thing is, i had the exact same progress on those 2 occurrences (chapel room, same inventory, and carefully interacted with the same spots).
Then i thought, if it's code-related only, i might have found a problematic pattern (assuming no exotic stuff is saved such as timestamp, etc).
So, i repeated that exact same pattern on the very next save, but it succeeded.

That means the faulty bits don't always fail to toggle.

Because of that, it's likely the eeprom itself is faulty, indeed.

 

However, I could imagine a code issue that would explain such randomness (pure speculation, considering my knowledge of that eeprom, so i throw this just in case):

Let's assume that when a write command is sent, some time is required before sending another (and that there's no practical way to know when it can be done).

Now, what if occasionally, some writes require a little longer than usual (depending on the eeprom's state at that time).

So, if the waiting code doesn't last long enough to support those rare occurrences, the write could end up being actually interrupted, causing some bits to fail to switch from 1 to 0.

If that's true, such behaviour could technically happen at any physical address, and depend on CPU speed.

 

In my case, i'd estimate the overall probability of corruption to 3-5%.
I really wish the lynx stayed powered without cartridge, so i could have used some code to confirm that the integrity of the eeprom is compromised.

Yes, i got that copy from your shop.
A replacement sounds great, depending on what you can cover (france here unfortunately).
At least, that would be a great opportunity for you to check the eeprom if you can, hoping to grab an actual write failure, so that we're sure the code is indeed fine.

Edited February 8, 2023 by xhul