[Peer]

I have to work in between

Yes, same here. Annoying. Keeps one away from the important stuff 😉

Ok, that is good news. Do a “binary” search. Check after level 30. If same, check after level 45. If different, check after level 15, and so on. That should lead to “the point”. If you send me the binary and tell me how to “check”, I’d be happy to assist. I will be away for the next hours, but afterwards I’d be ready to go.

[Peer]

This I would like to classify as “highly unlikely” 🙂

Damn!

Could you still, for the next play-until-crash test, switch this option to the opposite?

Cheers,
Peer

PS: Next theory will be of “++(highly unlikely)” type …

[Peer]

Peephole optimization:

Do you use any post-processing peephole optimization on your VB assembly code? Some chance that in some place the binary might be different than the textual assembly code written by you? Or that what runs in Vide is the tiniest bit different from what is flashed to the EPROM?

Feel free to “unlike” this post 🙂

[Peer]

… again I find it an “unlikely“… cause.

Yes, I know. All those are unlikely causes. I also deem each and every one of them unlikely.

The only likely theory I have right now is “there must be a bug” 😉

I will still keep on pestering you with such things. Maybe at some point we will hit the right unlikely cause? Maybe I will never think in a good direction? One of my hobbies is marathon running. Which is completely senseless in itself. Why would anyone ever want to run 42K without any good reason other than just doing it? A side effect of this is increased perseverance and endurance, and maybe an affection for masochism. I have to admit that I sort of enjoy those brainteaser-like bughunting puzzles. I simply refuse to give up, I hate boredom, and I have to keep my brain busy. And this is so much more interesting than many other things…

At the moment, I do not know any other way to help you than annoying you with unlikely theories 😉

[Peer]

… RAM initialization (non-initialization). How does Vide initialize the RAM? How does a real console do this (or not do this)?

I recall that at some point we had that buggy behavior in Vide where a soft-reset re-initialized the RAM. But I think you fixed this already.

Still, Vide puts something into the RAM cells at startup. Potential cause for simulation / reality mismatch?

[Peer]

Read your latest blog entry, and not giving you any rest:

– The crash still only occurs on the live system not the emulator

– What is the difference between a human playing on the real console, and a 100 hours time-warped demo run in Vide
– What corner / extreme situation does a human easily reach while playing, but the demo mode doesn’t?

– The crash seems to have to do with memory (RAM) corruption

– RAM corruption due to faulty hardware
– What about old and aged RAM chips?

– On my vintage ATARI 800 XL, some years ago I had a faulty RAM chip, with just a very few addresses not working properly.

– At another point I had a beaten and worn Vectrex console in my lab. On that console, the few games I tested worked fine, except for Scramble (indeterministic crashes). The same Scramble cartridge worked flawlessly on my other consoles. At that point I suspected a faulty RAM location (not storing what was written). I wrote a layman’s RAM checker, but that did not find anything. In retrospect I guess my RAM checker was not very good. Due to lack of time, I stopped those experiments. Later I used that console as an organ-donor for other consoles, but the RAM chips should still be in there. Are those socketed? Are there modern replacements available?

– RAM corruption due to faulty software
– See below

– Those two taken together mean – I still do not have a clue!

– Neither have I 😉 Yet!

– What kind of RAM corruption can happen, that is not emulated?

– Faulty hardware RAM location
– Just one faulty bit/transistor could cause this, maybe in some region of the RAM that is not touched by most of the normal cartridges

– Usually RAM corruption is a typical coding bug!

– Agreed. The usual suspects:

– Dynamically linked lists are something where even the most seasoned programmers make mistakes over and over again. You are more than ultimately seasoned 😉 But still, we could give this a try. Can you explain in a few words how you use and build such lists? Phone call? Video chat? Maybe having to explain that to someone else helps…

– Dangling pointers
– Stack overflows/underflows
– Array indexing overflows/underflows
– Incorrect pointer arithmetic
– The pitfalls of signed/unsigned integer arithmetic/conversion/underflows/overflows
– Uninitialized RAM location (possibly zero at console startup, but not set when 2nd game round is played)
– …

[Peer]

Easter weekend wasted.

No. My sympathies for how you feel. I’ve been through similar phases in various projects. But no. Not wasted.

You taught me things! Many things!

So, no. Not wasted! And we gained more insight about the VIA.

OK, back to square one. We are programmers, and we shoot with our minds! This is what we do. So, on your feet, soldier!

(I am not militaristic, I am just quoting from Dark Tower, and Aliens / Terminator 😉 )

Encouraging Cheers,
Peer

[Peer]

Quite some communication these days…

Yeah, I asked tons of stubborn und probably stupid questions, trying to seek reason where there possibly is none. And Chris answered all of them patiently 🙂 Thanks!

… and I hope that the bug can be trackex down, soon.

I learned quite a bit about the VIA, and I hope I did not distract Chris from more important or more promising things. Right now, I do not see any “logical” explanation (meaning processor-logic related), and I guess that the faulty/glitchy/aged VIA theory unfortunately is a viable option.

I did not find the time to play VB45 a lot, but I let my glitch-seekers run on my consoles for quite some time. No discoveries yet. Chris, if you think that more such testing makes sense, then I will also run them on the other consoles in my lab when I get there next time. I could also try some more modifications of the test program, and send the binaries to Helmut as well.

Cheers,
Peer

Edit: Yes, I read EF’s comment. Indeed very interesting. But also a bit scary 😉

[Peer]

… the timing (setup, hold) could be different, or slighty more sensitive, for micro-cycle reads. No problem when reading from ram or rom, but sensitive when reading from the VIA? Or especially from a faulty/glitchy/aged VIA?

Just speculation, of course.

Btw, I googled “6522 hardware bug” and found (besides the shift-reg bug) some “timer/interrupt race condition bugs” mentioned, but no details whatsoever.

Headachy cheers,
Peer

[Peer]

Sure, no one would do that intentionally. But what if …

… if reading PORTB by means of ldb is safe (a macro-cycle read), but reading PORTB by means of INC/DEC (a micro-cycle read) can be “glitchy”, yielding whatever unexpected value which is then processed?

Edit: this relates to your post 4945

[Peer]

That is what is what I still find confusing. INC and DEC would both have the same effect on PB0, but what about the other pins? If the read-cycle e.g. fetches an 8-bit zero, then the write-cycle of INC would put a 0 to PB6, while DEC would put a 1 to PB6. Am I missing something here?

[Peer]

And just for the sake of completeness, can you give me a code example where you used the DEC just like you used the INC in the VIA post?

[Peer]

So in other words, writing PB7 (when it is in its default state and when it is in output mode) does not have any effect at all?

[Peer]

Nope.. Ramp wouldn’t cause a crash…

Oh, come on, I am running out of pins. Please, give me a crash! 😉

Here is why I asked this:

I did some experiments on a real console. I left VIA_DDR_b as it is configured by Init_VIA(). So, PB7 and PB4-0 are in output mode, and PB6+5 are in input mode. I then did write/reads to VIA_port_b. Reading PB4-0 gives me the last pattern I stored. Fine. PB6+5 I ignored. But no matter which 8-bit value I put in VIA_port_b, when I read PB7, it always yielded a one. The asm code is:

ldb	_n
stb	*_dp_VIA_port_b
ldb	*_dp_VIA_port_b
stb	_m

So there is nothing inbetween the write and the read. Now, suppose that I use the following code:

ldb	#0
stb	*_dp_VIA_port_b
inc	*_dp_VIA_port_b

My theory is that the same thing should happen, i.e. the inc reads a one in PB7 and then actively writes a #129 to VIA_port_b, and thus sets ramp to high.

I cannot verify this, because reading VIA_port_b after the inc instruction would be also prone to always reading a one in PB7.

But I was “hoping” that there might be some exotic context in which inaccidently setting ramp to one in this way (by using inc) could cause a crash, or possibly an endless loop, or some disruption of the timers, or … ?

Please, give me a crash! 🙂

[Peer]

I had to get up early today and hide some Easter eggs, real ones – not code, in the garden for the kids. Now Iam sitting here with a first cup of coffee, waiting for them to wake up, and I cannot stop thinking about VB.

So, next try. What would happen, if PB7 at some point, in whatever strange context, unintentionally changes its value? I know it is just the ramp signal, but could that lead to a crash?

… I will write again later. They have woken up 🙂

Happy Easter to you all!

[Author]

Posts