New (alt) BIOS for Ultimate 1MB/Incognito

[flashjazzcat]

I just updated the Ultimate in my PAL 130XE. Any time I go to the "System Clock and Features" menu, it resets the date & time to all zeros and will not let me set it. I have verified that the Ultimate is able to keep Date & Time settings after powering off. But any time I enter the BIOS, it resets everything.

 

EDIT:

When going to that BIOS page, it shows the values for a split second before zeroing them out, if that helps.

 

The only reason the BIOS will reset the clock to 00:00:00, Jan 1 2000 is if it previously read the clock and found the day, date, month, year, hour, minute or second to be out of range (i.e. a clear indicator the time or date is messed up).

 

How have you verified the integrity of the RTC outside of the BIOS (that is, using what software)?

[+Stephen]

 

The only reason the BIOS will reset the clock to 00:00:00, Jan 1 2000 is if it previously read the clock and found the day, date, month, year, hour, minute or second to be out of range (i.e. a clear indicator the time or date is messed up).

 

How have you verified the integrity of the RTC outside of the BIOS (that is, using what software)?

My Ultimate has SDX 4.47 flashed on it. I can set the date & time, then turn off the machine for long periods of time. I'll reboot into SDX, and use TDLINE. The time & date are correct. Also, when launching Ice-T XE from this setup, it also sets the time based off of the correct SDX time.

[Frankie]

I just flashed my SIDE 2 with the new loader. Something is a little strange with it.

This is on an 800XL, no U1MB, just SIDE2 and a RAM 320XL plugged in.

 

The side loader comes up fine, but if I try and change the color all of a sudden it's like the up-arrow key is always on. I reboot, everything is ok. I can go up / down, and play games. But if I try and change the color it starts clicking constantly trying to go up.

 

I also noticed there is no menu for saving your settings.

 

------

 

The same cart in an 800XL with U1MB works fine. Is it trying to save the color settings in the U1MB flash?

Edited April 7, 2016 by Frankie

[flashjazzcat]

My Ultimate has SDX 4.47 flashed on it. I can set the date & time, then turn off the machine for long periods of time. I'll reboot into SDX, and use TDLINE. The time & date are correct. Also, when launching Ice-T XE from this setup, it also sets the time based off of the correct SDX time.

And yet it's not correct when the BIOS reads it. Can you flash this test BIOS and let me know what is reported on the screen:

 

ubiostst.zip

 

In this build, errors in the time and date no longer prompt a reset of the clock. Instead, when an out of range value is found it should (hopefully - I didn't test the output) display "RTC Error: index = a, value = b", where a is a value from 6 to 0 and b is the errant value itself. The index refers to which time/date field triggered the error:

 

0 = Sec (0-59)

1 = Min (0-59)

2 = Hour (0-23)

3 = Weekday (1-7)

4 = Date (1-31)

5 = Month (1-12)

6 = Year (0-99)

 

So if you see the error message, you should also see - as the "value" - a number which does not fit within this range.

 

Once we've established what's happening, maybe we can figure out why.

 

EDIT: Did you happen to perform the 100pF reset line fix on U1MB? The reason I ask is because other drivers in the system read and set the RTC when the U1MB config is locked, while the BIOS depends on the presence of RAM at $D1xx, $D5xx, $D600-$D7FF. The stability issue Hias helped me fix resulted in these RAM areas spontaneously disabling themselves while the U1MB config was unlocked (i.e. while the BIOS was open). If this happens just as the BIOS reads the RTC, just after you've pressed reset, problems will occur.

 

The side loader comes up fine, but if I try and change the color all of a sudden it's like the up-arrow key is always on. I reboot, everything is ok. I can go up / down, and play games. But if I try and change the color it starts clicking constantly trying to go up.

That's extremely odd. Does this also happen if you change any of the other options?

 

I also noticed there is no menu for saving your settings.

None is needed, since settings are committed to NVRAM as soon as you change them (I realize this behaviour is inconsistent with the BIOS, but it's covered in the manual and there are good reasons for it). Perhaps this writing to NVRAM, rather than the selection of colour itself, is what's upsetting your system?

 

The same cart in an 800XL with U1MB works fine. Is it trying to save the color settings in the U1MB flash?

Ah... then allow me to deploy the phrase "hardware problem".

 

It's saving the settings in the U1MB NVRAM, as described above.

Edited April 7, 2016 by flashjazzcat

[+Stephen]

And yet it's not correct when the BIOS reads it. Can you flash this test BIOS and let me know what is reported on the screen:

 

ubiostst.zip

 

In this build, errors in the time and date no longer prompt a reset of the clock. Instead, when an out of range value is found it should (hopefully - I didn't test the output) display "RTC Error: index = a, value = b", where a is a value from 6 to 0 and b is the errant value itself. The index refers to which time/date field triggered the error:

 

0 = Sec (0-59)

1 = Min (0-59)

2 = Hour (0-23)

3 = Weekday (1-7)

4 = Date (1-31)

5 = Month (1-12)

6 = Year (0-99)

 

So if you see the error message, you should also see - as the "value" - a number which does not fit within this range.

 

Once we've established what's happening, maybe we can figure out why.

 

EDIT: Did you happen to perform the 100pF reset line fix on U1MB? The reason I ask is because other drivers in the system read and set the RTC when the U1MB config is locked, while the BIOS depends on the presence of RAM at $D1xx, $D5xx, $D600-$D7FF. The stability issue Hias helped me fix resulted in these RAM areas spontaneously disabling themselves while the U1MB config was unlocked (i.e. while the BIOS was open). If this happens just as the BIOS reads the RTC, just after you've pressed reset, problems will occur.

OK - let me try re-flashing. I have not applied the "reset line fix", as I never had issues with this machine before. I don't recall your beta version having this issue.

[flashjazzcat]

OK - let me try re-flashing. I have not applied the "reset line fix", as I never had issues with this machine before. I don't recall your beta version having this issue.

Great - I'll be intrigued by the output. Nothing whatsoever changed since the beta regarding SPI transfers, so this is strange indeed.

 

Regarding the cap fix: depending on the test results, it might be worth doing anyway, since it appears to have no side-effects and the contents of the RTC buffer being different to the time/date values in the NVRAM has all the hallmarks of RAM not being where we expect it to be.

Edited April 7, 2016 by flashjazzcat

[+Stephen]

OK - let me try re-flashing. I have not applied the "reset line fix", as I never had issues with this machine before. I don't recall your beta version having this issue.

Well, that works perfectly. This does not reset the time.

 

EDIT:

Reflashed the V1.0 BIOS and it is now working. Very strange, because I did flash that BIOS twice before. The only difference was I flashed all three at the same time.

[flashjazzcat]

Well, that works perfectly. This does not reset the time.

Great, but that's not quite the information I was hoping to derive from this test. It appears that at some point the RTC values read are wrong, and then soon after they are miraculously correct.

 

Do you see no error message at all? This isn't a change I propose to keep in future versions, so I'd rather try and get to the bottom of the problem.

[flashjazzcat]

Reflashed the V1.0 BIOS and it is now working. Very strange, because I did flash that BIOS twice before. The only difference was I flashed all three at the same time.

Did you power-cycle the machine after the update? In any case: glad to hear things are working, and thanks for the update.

[Panther]

I was going over the OS ROMs on my Incognito and discovered that the four Colleen ROMs in the stock firmware are:

Colleen OS 1: OS A Actual: OS A NTSC (Stock)
Colleen OS 2: OS A + FastChip Actual: OS B NTSC (Stock)
Colleen OS 3: OS B Actual: OS A NTSC (Stock)
Colleen OS 4: OS B + FastChip Actual: OS B NTSC (Stock)

[flashjazzcat]

I was going over the OS ROMs on my Incognito and discovered that the four Colleen ROMs in the stock firmware are:

Colleen OS 1: OS A Actual: OS A NTSC (Stock)

Colleen OS 2: OS A + FastChip Actual: OS B NTSC (Stock)

Colleen OS 3: OS B Actual: OS A NTSC (Stock)

Colleen OS 4: OS B + FastChip Actual: OS B NTSC (Stock)

What's the practical upshot of this observation? UFLASH should preserve the existing ROM descriptions during an upgrade, so the descriptions in the BIOS as distributed are pretty arbitrary (and presumably reflect what was on my Incognito when I received it).

[Panther]

This is what was on the Incognito as I received it.

[+Stephen]

Did you power-cycle the machine after the update? In any case: glad to hear things are working, and thanks for the update.

Yes, I let the uFlash reboot the machine, then I immediately turned it off to do a cold boot. Sorry this isn't much helpful information. I'll continue messing with this machine tonight and see if anything else acts up, but until this, it never has. It's been a rock solid stable machine.

[flashjazzcat]

This is what was on the Incognito as I received it.

I may not be absorbing things very well tonight. You're saying the ROM content doesn't match what's written on the menu, as you received it? In that case, best thing to do is edit them so they're correct. Sorry if I'm not grasping the issue.

[Frankie]

 

 

--wrong thread

Edited April 7, 2016 by Frankie

[flashjazzcat]

So then if you don't have a U1MB installed you can't change any settings on your SIDE/SIDE2 cart? It doesn't have it's own NVRAM?

Yes, SIDE/SIDE2 have their own NVRAM (they have the same DS1305 chip as Ultimate, decoded at the exact same address). No, Jon, carts can't put hardware registers on page $D3.

 

Sorry this isn't much helpful information. I'll continue messing with this machine tonight and see if anything else acts up, but until this, it never has. It's been a rock solid stable machine.

It's all helpful, and I'm sure we'll see many more quirky behaviours making themselves known as time goes on. Talking of rock solid stable machines, I have to tell you that this is the description I used to apply to my heavily upgraded 1200XL until a month or so ago. This was my benchmark machine. If it worked in the 1200XL, it simply worked. RWCRC passed without error every time. Memory tests were always 100 per cent.

 

Then - as release time for the final BIOS approached - I noticed my 1200XL would, every now and then, hang on a black screen when I pressed reset. I noticed this in the past (with various BIOS revisions, including Candle's original), but had always assumed it was the pesky VBXE adapter working loose. But since I'd noticed something similar on Jetboot Jack's 1200XL (fixed by the 100pF cap), I started seeing a correlation between the two and so applied the 100pF cap to my 1200XL's U1MB as well. Result: complete banishment of the reset hanging problem (this was before I tried to install Rapidus, of course).

 

Although it may not apply in your case at all, the moral here is that even the machines ascertained to be completely stable sometimes have lurking, hidden issues revealed by new software revisions, etc. This 100pF cap fix has found its way onto my (rock solid) 130XE as well, solving some issues with Rapidus.

Edited April 7, 2016 by flashjazzcat

[Frankie]

 

 

That's extremely odd. Does this also happen if you change any of the other options?

 

 

None is needed, since settings are committed to NVRAM as soon as you change them (I realize this behaviour is inconsistent with the BIOS, but it's covered in the manual and there are good reasons for it). Perhaps this writing to NVRAM, rather than the selection of colour itself, is what's upsetting your system?

 

 

Ah... then allow me to deploy the phrase "hardware problem".

 

It's saving the settings in the U1MB NVRAM, as described above.

 

Yes, SIDE/SIDE2 have their own NVRAM (they have the same DS1305 chip as Ultimate, decoded at the exact same address).

 

 

 

The strange behavior happens for any setting change with all three of my carts. They all work when in machines with U1MB but when used with a machine that doesn't have it, they are not happy.

[Panther]

I may not be absorbing things very well tonight. You're saying the ROM content doesn't match what's written on the menu, as you received it? In that case, best thing to do is edit them so they're correct. Sorry if I'm not grasping the issue.

 

Yes, that is correct. I just wanted to point out that they did not appear to ship with the ROMs as listed.

I can't seem to find the Newell FastChip ROM anywhere though.

[flashjazzcat]

The strange behavior happens for any setting change with all three of my carts. They all work when in machines with U1MB but when used with a machine that doesn't have it, they are not happy.

No wonder: I am incredibly stupid. I somehow forgot to change the SPI bus control register address in the SIDE/SIDE2 build of the loader.

 

Please try this and let me know if it works:

 

sload103.zip

 

If it does, I'll put it on the website tomorrow. If you want to use the ATR flashers I already released, just replace the ROM file on the ATR with this one. The same ROM is good for SIDE and SIDE2.

 

Thanks for spotting this!

[+Stephen]

No wonder: I am incredibly stupid. I somehow forgot to change the SPI bus control register address in the SIDE/SIDE2 build of the loader.

 

Please try this and let me know if it works:

 

sload103.zip

 

If it does, I'll put it on the website tomorrow. If you want to use the ATR flashers I already released, just replace the ROM file on the ATR with this one. The same ROM is good for SIDE and SIDE2.

 

Thanks for spotting this!

I bet that's why when I tried to flash my SIDE2 it hosed the SDX portion of my Ultimate Luckily, the ATR flashed for SDX fixed that, and I didn't have to pop chips out of the U1MB

[flashjazzcat]

I bet that's why when I tried to flash my SIDE2 it hosed the SDX portion of my Ultimate Luckily, the ATR flashed for SDX fixed that, and I didn't have to pop chips out of the U1MB

No - the SPI register pertains to RTC access.

[+remowilliams]

Please try this and let me know if it works:

 

Hah, I might have found that weirdness out tonight as I pulled an unexpanded 130XE off the shelf for some testing.

 

Just flashed it to a SIDE2, changing colors does not cause issue and the other stuff seems to work still

[Frankie]

No wonder: I am incredibly stupid. I somehow forgot to change the SPI bus control register address in the SIDE/SIDE2 build of the loader.

 

Please try this and let me know if it works:

 

sload103.zip

 

If it does, I'll put it on the website tomorrow. If you want to use the ATR flashers I already released, just replace the ROM file on the ATR with this one. The same ROM is good for SIDE and SIDE2.

 

Thanks for spotting this!

 

Everything's working normally!

[Roydea6]

sload103.zip

 

 

Thanks for spotting this!

Thanks for the quick fix, I had not even noticed 'till' read here.

[Kyle22]

Incognito works fine for me, Thanks.