- This topic has 522 replies, 8 voices, and was last updated 4 years, 8 months ago by
.
-
Posts
-
Why would VIA know if a “port b” request is “micro cycle” or “macro cycle”?
All there is – is a request on the BUS with address lines coded to “$d000”.
The internal address decoding logic ensures that “read request” is answered by VIA.
VIA is only interested in BUS requests… for all it knows the request could come from the PiTrex (hehe – which sometimes really it really does!)
… 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,
PeerQuite some communication these days and I hope that the bug can be tracked down, soon. Please let me know if I can help at some point by running some code/binary on my three Vectrex consoles or in ParaJVE.
Last not least: Happy Easter to everyone!
@Peer:
The latest comments from EF to the blog entry:
11th of April 2020 – Vectorblade updateMight be interesting to you – about the 6522…
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,
PeerEdit: Yes, I read EF’s comment. Indeed very interesting. But also a bit scary 😉
Got a crash using the Beta 45.
Theory about faulty VIA cause rejected. Easter weekend wasted. Stopping for today… getting a headache.
Rollback of code will comence soon (old code is faster and shorter – so I will take all changes back).
Stupid thing is – I modified the code at so many places which had nothing todo with the faulty stuff – I can not just switch back to the old code… I must take the changes back one at a time manually…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,
PeerMir fällt dazu Folgendes ein:
Vorgestern hatte die Apollo 13-Mission ihr 50-jähriges Jubiläum. Die Mission wurde die erfolgreichste Mission der NASA.
@Chris: I want to encourage you too! Vectorblade is Great and believe me: thanks to your creativity, your perseverance and all the support of your friends here, you will succeed! 👍🏻😊
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)
– …… 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?
– 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?
I also played “live” (not demo) in Vide. It is really boring – but one does what one has todo. I even played about 500 levels in one piece. This is all no guarantee, that a crash can not happen in Vide – just makes it “unlikely“.
– RAM corruption due to faulty hardware
– What about old and aged RAM chips?Yes – this might be a cause. Although again I must say “unlikely“. Since the crash happened with at least 3 different consoles. Two of mine and Jeromes. Don’t know if any other crashes happened to any other beta testers.
Also – there are many other games, that use “full” RAM (at least all my other games). So I’d dare say, that if it is indeed a faulty RAM – it should manifest itself within other games too.Usually RAM corruption is a typical coding bug!
… which should be detactable in Vide – that is what I wrote it for :-).
For the linked list – yes, that is a bitch. But still – it is code wise the same as I used in Release/Shongololo/ParticleDemo and others. It has been tested and proven ok over and over again… again – I find it highly “unlikely“.RAM initialization (non-initialization)
Vide “pseudo” randomizes RAM contents. Per default RAM contains the low byte of the address.
so e.g. $c8a0 would contain $a0, $c8a1 contains $a1.Dunno – what is the hardware spec of uninitalized RAM? If the BIOS initializes it -> so it would in Vide!
The 2114 RAM specification is included with Vide – but doesn’t say anything about uninitialized RAM (Static random-access memory – https://electronics.stackexchange.com/questions/248950/sram-isnt-blank-on-powerup-is-this-normal seems to suggest its contents is more or less “random”).But also…
– I tend to initialize RAM, that I use 🙂
– Vide gives out a warning if you read uninitalized RAM (at least my version does)… again I find it an “unlikely“… cause.
So…
Everything seems to be unlikely. Fine – than we don’t have a problem. Good that we cleared that up.
Wait … the crash is still there!
“How often have I said to you that when you have eliminated the impossible, whatever remains, however improbable, must be the truth?”
―My vote at the moment goes to…
Vide is dumb – and somewhere I made a coding mistake :-)!So you know what we are talking about…
http://vectrex.malban.de/tmp/crash_82.mp4
http://vectrex.malban.de/tmp/crash_101.mp4
… 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 😉
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 🙂
-
- The forum ‘Vectorblade beta test’ is closed to new topics and replies.