Jump to content
candle

Incognito JED experimental upgrade

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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 by flashjazzcat

Share this post


Link to post
Share on other sites
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...)

 

 

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
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:

  1. 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).
  2. A specific resource of Incognito is not responding on time because, in turn, is waiting for something else at boot time (?)
  3. 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...

 

Share this post


Link to post
Share on other sites

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. ;)

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

  • Like 3

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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. :( 

  • Like 1

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites

 

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.

 

  • Thanks 1

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites

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 by flashjazzcat

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...