Faicuai Posted October 6, 2021 Share Posted October 6, 2021 3 minutes ago, flashjazzcat said: o be absolutely clear: there is no extra power-on delay in the most recently uploaded BIOS. Whoaa!!! Very interesting... because I am getting ZERO resets, unless I leave the XEP connected. Now, what I am getting is auto-land on Profile-1, regardless of last-known (before powering-down). Seems we have more clues to the problem, here. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 6, 2021 Share Posted October 6, 2021 (edited) 3 minutes ago, Faicuai said: Now, what I am getting is auto-land on Profile-1, regardless of last-known (before powering-down). What I imagine is happening here is that your profile number is always out of range (i.e. $ff is read back from NVRAM for the reason I described in the edits to my prior post). The BIOS always resets the profile to #1 (internally, $00) if the value read from NVRAM is outside of the 0-3 range. Edited October 6, 2021 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
Faicuai Posted October 6, 2021 Share Posted October 6, 2021 16 minutes ago, flashjazzcat said: What I imagine is happening here is that your profile number is always out of range Makes total sense, because the rest of the settings for ALL profiles, are still there, intact, and no-reset to speak-up during power-up (unless, as I've already said, the XEP remains connected and active, before-powering-up the 800). BTW, do you have any idea or suspicion as to what could be wrong with Ultimate/SD .XEX loader? Have you had a chance to test it? (I know you are working on your high-tech. meta command-processor for SIDE3, just wondering...) Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 6, 2021 Share Posted October 6, 2021 Since the profile number is read before anything else, you might be in a situation where reads from NVRAM just happen to come good immediately after that, just before profile 1 is read. 21 minutes ago, Faicuai said: BTW, do you have any idea or suspicion as to what could be wrong with Ultimate/SD .XEX loader? None at all. I (like Candle) have invested such large amounts of time in the NVRAM read issue that I don't really want to muddy the waters by trying to diagnose interactions between Incognito and other third-party devices right now. My priorities are a) Ship the Australian customer's Incognito 800 back with confidence that it works with the new JED, b) Get paid for that, and c) get my own Incognito 800 in a reliable state which justifies the considerable amount of effort I put into facilitating Incognito plugins. 1 Quote Link to comment Share on other sites More sharing options...
Faicuai Posted October 6, 2021 Share Posted October 6, 2021 1 hour ago, flashjazzcat said: Since the profile number is read before anything else, you might be in a situation where reads from NVRAM just happen to come good immediately after that I think that may be the key to unravel the mystery. Your (plausible) explanation may suggest that: The 6502 is already ahead of everyone else, at that specific point in time (in the corresponding timing-chain, no idea what is involved there). A specific resource of Incognito is not responding on time because, in turn, is waiting for something else at boot time (?) Maybe BOTH resources (6502 and NVRAM ARE, indeed, available) but somehow initial read-outs do NOT work for a very short period of time (something else in the system-bus interferes momentarily). Have you tried to "bang-reading" the NVRAM (a finite # of multiple successive attempts as soon as BIOS-execution begins), instead of a fixed-delay before operations, and leave some sort of trace or signature of such readouts? (just thinking out loud) The only way to trace something like this is to re-draw the complete timing-chain, from CPU board all the way to into Incognito, component-by-component (depending on system-timing) and then check / sample everything (timing-wise) during and right-after power-up... I am not sure if it is only one point to be sampled... it seems multiple points will need to be checked, and maybe some of them at the same time! Having said that, what I am surprised is the effect that PIA has on profile-reset (e.g. when leaving XEP connected to Joy-port #2)... I will have to disassemble the unit, and try with different PIAs, including normal Incognito boot (and check for profile read-out integrity), in an attempt to discard its role on the equation... Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 6, 2021 Share Posted October 6, 2021 I tried a large number of debugging code paths but after investing twenty or thirty hours into it and slavishly backing up all the predictions I made to Candle with observable evidence, I eventually felt that the guy with the four channel scope and years of VHDL experience is the best person to figure it out. 1 Quote Link to comment Share on other sites More sharing options...
Faicuai Posted October 7, 2021 Share Posted October 7, 2021 17 minutes ago, flashjazzcat said: I eventually felt that the guy with the four channel scope and years of VHDL experience is the best person to figure it out. Of course, and by all means!! It's just that when we spend so much time on the same problem, even its surrounding reality somehow warps... ?? You may be surprised to know that a very similar problem occurs with my reference 800 and AVG cart (non-incognito, where I can run all legacy plug-and-play upgrades). On STOCK OS/b rom, the system sizes up ram (all the way to 52KB in RAMROD) before the cart boot-image maps on $A000-$BFFF, which causes (in 48KB config) the D/L and E: buffer set by OS CIO to be obliterated once the cart finally maps, after the fact!!! To this extent, I replaced the stock O/S board with a RAMROD board, and loaded Avery's AltOS 3.31 on EPROM (likely slower than original roms) and somehow everything boots in sync, and AVG cart even text-buffers in $C000-$CFFF for its selector-menu output (!) Anyhow, if there is anything else we can do here, just let me know. More than willing to help you guys after such arduous work. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 7, 2021 Share Posted October 7, 2021 Well, Candle is able to reproduce the issue, and when fixing bugs in my own software, I find this is half the battle. He seems to think the problem is ANTIC rather than 'time since power up' related, so hopefully his superior insights will eventually reveal the solution. 3 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted October 7, 2021 Share Posted October 7, 2021 Really sorry I've been zero help here with testing. I have the requisite hardware, I just have had less than zero time and it's no looking like things will ease up until at least November. I will try to at least get the required equipment accounted for and maybe even on the test bench if I have a few hours late Saturday. Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted October 7, 2021 Share Posted October 7, 2021 54 minutes ago, Stephen said: Really sorry I've been zero help here with testing. I have the requisite hardware, I just have had less than zero time and it's no looking like things will ease up until at least November. I will try to at least get the required equipment accounted for and maybe even on the test bench if I have a few hours late Saturday. Ditto. Have the Incognito, have the ability to program the CPLD, have the scope if needed to measure signals … don’t have the time/motivation/focus to test anything. 1 Quote Link to comment Share on other sites More sharing options...
Faicuai Posted October 7, 2021 Share Posted October 7, 2021 3 hours ago, flashjazzcat said: Candle is able to reproduce the issue Excellent news. Not surprised if Antic is part of the problem. This points to option #3, in my "SciFi" diagnosis: 5 hours ago, Faicuai said: Maybe BOTH resources (6502 and NVRAM ARE, indeed, available) but somehow initial read-outs do NOT work for a very short period of time (something else in the system-bus interferes momentarily). Let's see how this moves forward. Seems like a tough one to crack. Quote Link to comment Share on other sites More sharing options...
Faicuai Posted October 15, 2021 Share Posted October 15, 2021 On 10/6/2021 at 8:10 PM, flashjazzcat said: Well, Candle is able to reproduce the issue, and when fixing bugs in my own software, I find this is half the battle. He seems to think the problem is ANTIC rather than 'time since power up' related, so hopefully his superior insights will eventually reveal the solution. @candle Alright, just a quick update, here: After having gone through multiple cold / power-up cycles, so far, I can say that the latest .JED and BIOS (with no provision for start-up delay), are NOT producing the profile resets shown in the past (which is good!), with the EXCEPTION of defaulting (and booting) to Profile #1, at start-up (its data appears read entirely, with nothing missing, even if that profile was not the last used on the prior session). So that's the only thing I can report, at this point (besides the Ultimate/SD cart .XEX non-functional loader, in contrast to Incognito, SIDE2 and AVG loaders, which all work perfectly). That's all for now. 1 Quote Link to comment Share on other sites More sharing options...
Faicuai Posted October 17, 2021 Share Posted October 17, 2021 @candle, @flashjazzcat Well, just when I thought I had it all covered, I've just discovered how to (literally) induce BIOS profile "amnesia", at-will, programatically. Due to a completely unrelated (and on-going) test effort, I decided to connect back Syscheck v2.x (XL/XE version) on PBI bus, and configure it by DISABLING [external OS] and [external base ram], and ONLY enabling [external Rambo 512KB ram], a test that I had already successfully performed a while-back here on this very same thread. Lo-and-behold, I get profile-forgetfulness right at first power-up. Disconnect Syscheck, and amnesia goes away (other than landing on profile #1). Oddly, when performing this very same test with TurboFreezer external RAM, it works perfectly, with no profile-amnesia (eg. black-and-white on-screen profile on power-up) So there you have it. This may also be confirmed by Jon, if he has the same Hw version of Syscheck as I do. This could also give another hint of what variables do contribute with this issue. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 17, 2021 Share Posted October 17, 2021 (edited) Hard to replicate here since I get corrupt NVRAM reads without anything else connected to the bus. The only way I can even make my SCCC-equipped machine usable at all with the latest JED is by extending the power-on stability delay in the firmware as we previously discussed. My feeling is that a couple of yards of wire connected to the bus would do just as well, anyway; sounds like a timing/capacitance issue which I am hardly qualified to talk about. Candle seems to be of the opinion that this JED is pending rubber-stamping, but I'm really unhappy that this issue persists on at least two machines (and therefore, we can guarantee, many more). Edited October 17, 2021 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
Faicuai Posted October 17, 2021 Share Posted October 17, 2021 2 minutes ago, flashjazzcat said: The only way I can even make my SCCC-equipped machine usable at all with the latest JED Important difference there, as I am running Incognito on a stock Sally board (original, 1983) except for GTIA, which is Sophia-ii. I see your point about a little longer PBI cable-run. What we do need is a PBI / CPLD logic and timing tester, that we can hook up to PBI bus, and test it fully... like the next-gen of SysCheck, which currently makes implicit use of PBI bit does not directly test it. Thx! Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 17, 2021 Share Posted October 17, 2021 Candle was certainly able to replicate the NVRAM issue using certain ANTIC chips (NTSC, if I remember), but I guess not even a four-channel scope and a big brain can divine the answer to this mystery at the moment. 2 Quote Link to comment Share on other sites More sharing options...
foft Posted March 15, 2022 Share Posted March 15, 2022 @candleWould it not be worth bisecting vs the old working Jed? So you can see the specific vhdl change that breaks the Jed? Quote Link to comment Share on other sites More sharing options...
candle Posted March 16, 2022 Author Share Posted March 16, 2022 that doesn't work i have hard time just compiling darn thing - it either fits or not - as most of resources are exhausted Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted March 18, 2022 Share Posted March 18, 2022 (edited) nevermind. Edited March 18, 2022 by Kyle22 Quote Link to comment Share on other sites More sharing options...
foft Posted March 18, 2022 Share Posted March 18, 2022 (edited) On 3/16/2022 at 4:41 PM, candle said: that doesn't work i have hard time just compiling darn thing - it either fits or not - as most of resources are exhausted Ok fair enough. I wonder if some features can be removed temporarily to allow space to check this. Otherwise would need to solder a device with more resources to make it easier to debug. Not that it’s possible to buy any these days I expect! Edited March 18, 2022 by foft Quote Link to comment Share on other sites More sharing options...
candle Posted March 18, 2022 Author Share Posted March 18, 2022 and no compatible devices exists i've also run out of ideas on how to debug it - every test we've conducted passes when machine is working outside the bios and the only issue i've found was that "config reset" when booted first time on cold Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 18, 2022 Share Posted March 18, 2022 Not only do tests conducted outside of the firmware context pass, but so do tests conducted inside the firmware if the power-on stabilisation delay is elongated by a few extra ANTIC frames. The exact same code has a problem if it runs - say - 50ms after the power is applied, but works perfectly if run 100ms after the power is applied and perpetually thereafter until the machine is next power-cycled. No such extended delays are necessary with its predecessor. Presented for info, anyway: conclude what you will. Quote Link to comment Share on other sites More sharing options...
candle Posted March 18, 2022 Author Share Posted March 18, 2022 i just wonder if it would help if we change reset time constant for 800 - it was nessesary for 400, as newer cpld chips needs much longer to configure since they are rewriting flash content to the ram-based fabric just thinking out lound 1 Quote Link to comment Share on other sites More sharing options...
foft Posted March 18, 2022 Share Posted March 18, 2022 It does sound like it’s used before its configured. Perhaps that takes longer for some reason. Is there a ‘config done’ pin so you can check the timing? Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted May 8, 2023 Share Posted May 8, 2023 On 10/4/2021 at 1:59 PM, candle said: and this is finall one for mosaic adventures... main.jed 122.64 kB · 50 downloads Since my Incognito CPLD does not support plugins, I would like to update it and I wondered if I should take the latest jed file from Candle (October 2021) or the one which @flashjazzcat shares on his Incognito page (August 2021): https://atari8.co.uk/wp-content/uploads/IncognitoV2-JED.zip Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.