Jump to content
Simius

IDE Plus 2.0 - the newestl edition available very soon

Recommended Posts

I don't use SDX, so it is OFF and it stays OFF. OS slot #0. XL/XE OS RevC, Atari 8K Basic, 320K Rambo.

 

A picture is worth... so here are a couple of screen shots before and after turning the IDE OFF and power cycling. To make your life a little more complicated, note that this doesn't seem to happen 100% of the time.

 

-Larry

 

 

 

 

post-8008-0-04340800-1471554097_thumb.jpg

post-8008-0-70321800-1471554140_thumb.jpg

Share this post


Link to post
Share on other sites

I can't obtain this effect on my few computers. Try to download BIOS 1.4 and check if it change something.

Edited by Simius

Share this post


Link to post
Share on other sites

I can't obtain this effect on my few computers. Try to download BIOS 1.4 and check if it change something.

 

This is what I tried to bring forward quite some time ago.

 

The problem seems to relate to the manual switch for SDX. On my 800XL-320KiB-CS with IDE+ Rev C. it goes like this:

 

Set the switch for SDX to OFF and reboot holding <START> to get to the IDE+ menu. SDX will be shown as being ON though it is not available. When now the external cart (e.g. Action) is set to OFF in the IDE+ menu and you reboot, it will start the cart though it shouldn't. When now jumping from the language cart (in Action to the monitor, then to DOS) you end up in the self test menu. Reboot with <START> to the IDE+ menu and set SDX to OFF. The external cart is still "OFF". Reboot and voilà, you'll end up in Atari BASIC. I figured that out with the very first version of my IDE+.

 

If you forget to set SDX to OFF in the menu though it is switched off manually, funny things can happen when an external cart is hopping in on boot when it shouldn't.

 

Another glitch is with the "USpeed SIO". It is incompatible with the FIFO. The system will lock when booting on a FIFO XL/XE with IDE+ high speed on. This setting might be incompatible with some high speed OS as well, though I cannot remember having had this issue as I normally use the Atari OS. The high speed issue is of importance when dealing with SIO2PC devices of whatever kind. If you experience problems when running an IDE+, it might be related to that.

 

Before I found this out I ran into issues giving me some bad hair days.

Share this post


Link to post
Share on other sites

power cycling

If you switch the power off (or hit Reset) when the BIOS is in the middle of initialization, or in the middle of updating time, then no wonder the setting will get lost and get reset to defaults. This is the unfortunate nature of the V3021 RTC, where the settings are kept.

 

Also, re the SDX setting, older interfaces have no means to signalize to the BIOS that the SDX is off, the BIOS must guess it from the presence of a ROM in the memory. As with guesses, it sometimes fails.

 

Rev. E has the flag in hardware, just the BIOS 1.5 does not yet have it implemented.

 

TThe FIFO: it is not the USpeed SIO which is not complatible with the FIFO, it is the FIFO which is incompatible with the USpeed SIO (i.e. there is apparently a hardware problem with the SIO communication based on polling, when the FIFO is on).

Edited by drac030

Share this post


Link to post
Share on other sites

@ Simius/drac030-

I tried to update the bios to 1.4, but the chip erase fails each time. I booted from MyDos, then did a binary load of the bios .com file. Pretty sure this is what I've done in the past. The write protect is not set, since I can write files to the IDE.

 

@ drac030-

I don't think I'm cycling the power in the middle of anything, and certainly not pressing RESET. I'm just turning ON/OFF the IDE with and without cycling the power *after* saving the changes with control X. If I need to do something special to change the IDE setting, please let me know.

 

I'll keep trying to nail this down more concisely. When I'm using the IDE+2, the built-in U.S. is all that I use. I have no real cartridges attached, but BASIC may or my not be active. (I'll see if I can determine if that affects anything.) For my own education, what is the FIFO you guys are mentioning? Presume its a buffer?

 

-Larry

Share this post


Link to post
Share on other sites

@ Simius/drac030-

I tried to update the bios to 1.4, but the chip erase fails each time. I booted from MyDos, then did a binary load of the bios .com file. Pretty sure this is what I've done in the past.

You cannot use previous versions of the BIOS with the rev. E IDE+, because the hardware is different from e.g. rev. D. I think the flasher embedded in the BIOS14.COM will not be able to flash the rev. E ROM properly.

 

I'm just turning ON/OFF the IDE with and without cycling the power *after* saving the changes with control X.

I see. But I cannot reproduce any problem here. Also, there is nothing exceptional about the IDE on/off setting, it is just one bit in 8-byte block of settings. The BIOS reads or writes them all at once. So if changing the settings causes them to be reset to defaults, this most probably means that there was a checksum mismatch during reading the settings. And this most probably means that there is a hardware problem with the (serial) communication with the RTC.

 

If I need to do something special to change the IDE setting, please let me know.

Nothing special is required (except that you never ever switch the power off when the IDE+ menu is on the screen).

Share this post


Link to post
Share on other sites

Here is a retest with no BASIC (and no cartridge).

 

Here's exactly what I did:

 

I selected the settings that I wanted, saved with a cntl-B. These are shown as the test defaults. I checked the setting several times, and there were no changes. I cycled the power -- no changes.

 

I then turned the IDE off and saved with cntl-B (booting to MyDos on SIO). I then checked the settings several times and cycled the power to re-boot. The settings remained stable.

 

Then I turned the IDE back on and saved with cntl-B. Checked the settings several times and they were unchanged. Cycled the power from MyDos and went back to the settings and they were changed as shown.

 

Then I did this same step again and the settings were UNCHANGED. I even cycled the power from the green settings screen (after making no changes) and the settings were still unchanged.

 

@drac030 -- OK, got it about the green screen.

 

-Larry

post-8008-0-57976100-1471609295_thumb.jpg

post-8008-0-76627500-1471609344_thumb.jpg

Share this post


Link to post
Share on other sites

You cannot use previous versions of the BIOS with the rev. E IDE+, because the hardware is different from e.g. rev. D. I think the flasher embedded in the BIOS14.COM will not be able to flash the rev. E ROM properly.

 

Right. Sorry for misleading. Then we need the test software that reads the setting over and over again and indicating if the checksum error occur.

Edited by Simius

Share this post


Link to post
Share on other sites

;-) :thumbsup: I have got my Antonia 800XL to work with IDE+2.0 and a MyDos CF card but the Boot drive: setting will only boot D1: no mater what is set in Bios15 screen or setting the FDISK partition 'B' flag.. And memory selection seems to effect how the interface responds. SDX449b refused to boot SDX cartridge: on or off if on I get a black screen and if off I either boot to MyDos or the Error No Dos message..

Share this post


Link to post
Share on other sites

setting will only boot D1: no mater what is set in Bios15 screen or setting the FDISK partition 'B' flag.

Yes, there is some problem with this which I do not completely analyzed yet.

 

And memory selection seems to effect how the interface responds.

Which setting is a problem and how it affects the interface's behaviour?

 

SDX449b refused to boot SDX cartridge: on or off if on I get a black screen

Last time I checked it worked fine here.

Share this post


Link to post
Share on other sites

Hi Konrad-

 

I've downloaded the NVTEST.COM. Can you tell me what to expect? It says "IDE+ found at PBI #1" (or words to that effect). "Testing..."

 

Will it run until completion or am I supposed to do something else? Or? If I press a key, it aborts to MyDos, but if no key is pressed, it just keeps testing with no info provided to the screen. Maybe needs SDX?

 

Thanks,

Larry

Share this post


Link to post
Share on other sites

It reads the NVRAM contents, calculates the checksum, compares with the one it had read from the NVRAM. When there is a mismatch, it displays a message ("CRC error" etc.) and continues. When there is no mismatch, it just keeps doing it in a loop, until you abort it.

 

Later it came to my mind that there may be yet another reason for checksum errors: an intermittent problem with access to the interface's RAM. The current test calculates everything in the computer's RAM, so if you run it for few hours and it displays no errors, I think we will modify the test so that it would use the IDE+ RAM instead and see if there is a difference.

Share this post


Link to post
Share on other sites

Ok, so try this one. It reads the NVRAM settings to the IDE+ RAM and calculates the checksum reading the values from there.

 

It will also acknowledge its activity by printing a message every 16384 iterations (i.e. probably about once per minute). When you abort it, the total number of errors counted will be printed (65535 means "65535 or more").

nvtest.zip

Share this post


Link to post
Share on other sites

I just wanted to jump and say that watching this real time debugging across continents is quite fascinating!

Share this post


Link to post
Share on other sites

After 18 hrs, the original version is still "testing..." with no error messages. I'm switching over to the second version.

 

After several passes with the new tester, there are no errors. I'll let this run a good chunk of the day, but looks like this is not measuring the issue with my "E."

 

My issue only surfaces when the IDE setting has been switched OFF then ON, followed by cycling the power and going back to the menu to see the changed settings.

 

-Larry

Share this post


Link to post
Share on other sites

My issue only surfaces when the IDE setting has been switched OFF then ON, followed by cycling the power and going back to the menu to see the changed settings.

I know, but as I said before, this tells me nothing, as:

 

1) changing even one setting causes all the setting data be written anew to the RTC

 

2) your issue is that from time to time all the settings get reset to defaults - and this can only happen when there is a checksum mismatch.

 

The cause may be: a) faulty RAM, b) faulty RTC, c) faulty communication between the CPU and the RTC, d) faulty ROM.

 

RAM and ROM stability may be also tested using the KMKDIAG program included in the BIOS distribution.

 

Also make sure that you have the "1.5a" version flashed there, i.e. the 1.5 with the fix I wrote about a while ago.

 

When the new test does not detect anything in your system, I can modify the procedure once more so that it will also write to the NVRAM.

Edited by drac030

Share this post


Link to post
Share on other sites

OK, will re-flash. It currently has what was shipped which must be 1.5. And I'll also run the KMKDIAG program. Hope the issue can be found, but the work-around is just not to turn the IDE OFF. Pressing SELECT for the temporary bypass seems to cause no problems.

Share this post


Link to post
Share on other sites

Reflashed. KMKDIAG shows no issues.

 

But since I reflashed, I have not had the settings change after using the procedure I mentioned. I don't know if that makes any sense to you guys, but I'll keep trying the same OFF-ON changes and see if it continues to hold the settings.

 

-Larry

Share this post


Link to post
Share on other sites

No errors reported with this second test, but also no menu-changing issues since I reflashed. (?)

 

Incidently, after two successive all-night testing sessions, I'm impressed with the stability of the Antonia/E combination. Not one hiccup.

 

-Larry

Share this post


Link to post
Share on other sites

I have no idea why reflashing helped, but I am glad that it did. Causa finita, as it seems.

 

rdea's interface seems to have problem with RAM access, if I understand correctly. In any case, nothing to do with the firmware.

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

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