ANTONIA configuration tool incompatibility question

[drac030]

So it seems @_The Doctor__ is right, it is "only" a cosmetic issue. I have not reproduced it yet, though, but it is probably just bad address of the font. Okay, that is much better

 

 

[drac030]

Please test the attached binary and tell me if it works better/worse/not at all.

 

anttest2.arc

 

If it works, I will upload it as the version 1.5 to my website.

[SS]

@drac030 - ANTTEST2 fully loaded and worked with all of the Operating Systems that I tried it with : OSa, OSb, Oldrunner, Omniview, XL/XE rev.3, MyBios, Altirra, and Reverse BASIC XL.

 

The garbled graphics on the flasher screen that I had seen in the previous revision are no longer present. 

 

When I change my configuration to OSa and hit -Accept-, the system does not automatically reboot.  The screen goes black and the computer apparently hangs.  The configuration *does* change to OSa, though, because that is what the system is set to when I reload the ANTTEST2 Configurator.  This is not a problem, just an oddity.  None of the other Operating Systems that I tried caused this behavior.   

 

The video below shows the screen while ANTTEST2 is loading under OSa, OSb, and Oldrunner.  I do not see this effect when loading the Configurator under other Operating Systems.  Again, this is not a problem at all, just another oddity. 

 

All in all, I would say that ANTTEST2 has solved all of the problems that I was previously experiencing.  Thanks.

[SenorRossie]

It seems I am getting different results. 

 

The anttest2 executable loads from omnimnbe.rom and scans the current roms, during this I notice a short screen glitch, where it seems the font is switched to a memory location not containing a font it does switch back to a memory location that contains a font and continues to the next screen, where I can select the memory configuration and slots.

 

No issues during flashing diamgos3.rom and after a successful flash, the machine reboots to the current os (omnimnbe.rom). I reboot the machine (press the button next to the cf slot on the SIDE2, followed by Reset). And load anttest2 again. Same short screen glitch as during the previous run. The next screen displays fine,  but when I select the slot with diamgos3, and press ENTER, the system hangs:

 

As diamgos3 fails to boot completely, I boot the machine with the jumper removed and restored the os to omnimnbe. All other OS's I had installed worked fine, I was unable to crash the anttest2 program again.

 

P.S. The font glitch after starting the application happens with other OS's as well. A small nuisance, if you ask me. 

[drac030]

Here is the test3:

 

anttest3.arc

 

For a reason I cannot see the video. And, as I wrote previously, my ability to test this on the real hardware is rather limited. So again please tell me if it works okay (or not), if there are still any old glitches, or if there are any new ones, and especially if the flasher works well.

 

@SenorRossie are you sure that diamgos3.rom is something that should go to the OS slot? The ANT program, when one is about to switch to the selected ROM, does the following things:

 

1) switches the interrupts off,

 

2) if the active DOS is SDX, enables it so that it would start after a reboot,

 

3) switches to the preselected ROM,

 

4) does a jump to the cold boot OS entry (jmp $e477).

 

So if it hangs in the process, I would suspect that the ROM image does not contain a valid operating system with a valid cold restart vector at $e477.

 

 

[SS]

@drac030 - Everything seems to work on my end with ANTTEST3.  I tested with the same eight Operating Systems that I used previously and had no issues that caused any interruptions or glitches in operation at all.  OSa no longer causes the program to hang; the system now reboots after loading OSa as expected. 

 

The screen does still flash momentarily with garbage graphics while loading under OSa, OSb, and Oldrunner the same as it did in the video that I posted yesterday; screenshot posted below.  However, this does not effect the loading process or program operation at all.  It is only a very few momentary effects on screen and not problematic in any way.  I do not see this effect under any other Operating System. 

[SenorRossie]

7 hours ago, drac030 said:

@SenorRossie are you sure that diamgos3.rom is something that should go to the OS slot?

No, I am not.

 

I copied a few ROM files so I could test the new release. As the diamgos3.rom fails to boot, I figured I should try other ROMs as well. I reported the 'issue' for completeness. 

Not near a system at the moment, but will test the new version later today.

 

I was wondering if it would be possible to add a 'clear' OS and BASIC slot function (as in flash the content from the protected area of the Antonia)? When I flash the same roms via ant, I see the CRC value listed and not the text as when the slot is not updated.

[SenorRossie]

5 hours ago, SenorRossie said:

12 hours ago, drac030 said:

@SenorRossie are you sure that diamgos3.rom is something that should go to the OS slot?

No, I am not.

Well, I should have checked before flashing, the diamgos3.rom file is 64k and should of course be flashed to a cartridge, apologies for that.

 

Anyway, the anttest3 works fine on almost everything I threw at it. No more glitches, fonts remain readable throughout the program, which is great news!

 

As the Antonia uses an 65C816, why not flash Altirra OS for the 816... Flashing works (also using your own 65C816 XL/XE OS v2.41), but when the Altirra 816 OS (md5: ed8d05ad2435cb18a0df4bbc82085259) is used to start the binary (which I load from the SIDE Loader by FJC), the screen corrupts and I am unable to continue can successfully select a different OS by pressing the correct keys in the correct sequence

 

Loading binary

Directly after the application loads (Altirra 816 OS):

 

A bit later

 

I end up with a solid black screen. Until I press keys.

 

Edited May 2, 2020 by SenorRossie
Updated to mention that I can select a different OS by pressing the right keys

[drac030]

Here is the test4, please tell me if the glitch @SS is reporting is still there.

 

@SenorRossie re "clear", I will not make any major changes in the flasher before I get my Antonia working again, sorry.

 

As about the AltirraOS, not so long time ago it contained an unpleasant feature of randomly destroying the contents of the zero page when text was being printed via the "E:" editor with the cursor having been disabled. Perhaps the effects you are observing appear due to that one. I have reported this to @phaeron and he promptly made a fix, so perhaps this is a question of replacing the ATOS image you use with a newer revision.

anttest4.arc

[SS]

48 minutes ago, drac030 said:

Here is the test4, please tell me if the glitch @SS is reporting is still there.

@drac030 - This new version seems to have fixed everything on my end.  Everything is apparently running perfectly now.  Thanks!

[SenorRossie]

9 hours ago, drac030 said:

@SenorRossie re "clear", I will not make any major changes in the flasher before I get my Antonia working again, sorry.

No problem, I can always flash stock OS/BASIC to a slot, it would be a 'nice to have' though

 

9 hours ago, drac030 said:

As about the AltirraOS, not so long time ago it contained an unpleasant feature of randomly destroying the contents of the zero page when text was being printed via the "E:" editor with the cursor having been disabled. Perhaps the effects you are observing appear due to that one. I have reported this to @phaeron and he promptly made a fix, so perhaps this is a question of replacing the ATOS image you use with a newer revision.

The OS came from AltirraOS-3.20.zip (md5:1b3ddad8229231cfbd5e9ca937f4fdc0). The altirraos-816.rom (md5: ed8d05ad2435cb18a0df4bbc82085259) has a CRC value of C7C1 in ant 1.4. I will flash a different version of the AltirraOS 816 and check if that fixes the issue.

 

Thanks!

[drac030]

If everything works, excellent then, I will package this and upload to my website removing the old versions from there, as they apparently have problems I was not aware of.

[SS]

Thanks for all of your help and work on this @drac030.  Very much appreciated. 

[drac030]

Someone on this forum has convinced me to make an enhancement to the Antonia tool ANT, so that it would allow to edit file names of the ROMs stored in the flash memory and save them to a disk file. The idea was that the program has to store checksums along with the names, so that it could decide at loading time if the names still match the contents of the flash or not.

 

The main problem was testing as I remembered that previously I was not able to boot the relevant machine from any storage (SIO simply did not work and HDD did not spin up), but yesterday, to my surprise, when I inserted IDE+ into that computer, everything worked. So I was able to test my "dry" code on a real machine and clean up issues I spotted.

 

Long story short, here is a new version of the ANT program, 1.6b (where b stands for BETA). It has the requested feature and it seems to work. There however still may be glitches I did not notice, so if there are any Antonia-users interested, please take a look and report back any issues.

 

There are two versions: ANT.EXE and ANTCRC.EXE. The "CRC" version uses CRC-16 routine taken from this place http://www.6502.org/source/integers/crc.htm to calculate sums of the ROMs, whereas the former calculates straight, Atari-style checksums. CRC-16 should be more reliable, but checksums are easier (and faster) to calculate.

 

The CRC version stores ID file as ANTROMS.ID2, and the checksum version uses ANTROMS.ID1. The file will be stored in the program's path under SDX 4.4, in current dir in earlier versions, and on "D:" in other DOS-es.

 

I also found some issue in the flasher, which during my tests once or twice entered infinite loop during flashing. While I am not completely sure on the reason, I have verified the flashing routine against the documentation and found something suspicious. The fixed routine did not hang afterwards through the entire day, so I believe that if it was an issue to fix, it is now fixed.

 

The way to "clear" the flashable portion of the ROMs is this:

 

a) switch the ROMs into recovery mode (to the non-flashable part of ROMs)

b) power-up the computer

c) execute ANT

d) go to ANT Flasher menu

e) Answer "Y" to the "This ROM is protected. Accept it anyways?"

f) allow the program to buffer the ROMs

g) select "Flash all"

h) when the message "Toggle the switch now..." etc. appears, toggle the switch.

 

The program should then flash the flashable portion of the ROMs and reboot.

 

 

 

ant16b.arc

Edited October 18, 2020 by drac030
typos

[SS]

@drac030 - I just saw this new update.  I will try to get to testing it this coming weekend.  The ability to edit the ROM file names sounds like a perfect update!  Looking forward to this.  Thanks for your continued work on this. 

[SS]

@drac030 - Everything in these new versions worked fine and loaded under all of the Operating Systems that I tried them with.  I was able to rename all of my slots EXCEPT for "Altirra BASIC V1.55".  For some reason, even though I tried saving the ID file numerous times, the BASIC description keeps reverting to the name "AB09".  Otherwise, I experienced no other issues.

[drac030]

16 hours ago, SS said:

For some reason, even though I tried saving the ID file numerous times, the BASIC description keeps reverting to the name "AB09".

Try this one, then. I hope that this problem will not appear again.

 

I noticed that the ROM-selection menu, when it got wider, also became slower to redraw and less responsive to up/down cursor commands; so I have optimized screen writes to avoid drawing text which has already been drawn.

 

The CRC version is now faster by one fourth, but the initial scan is still 3 times slower than on the checksum version (6 vs 2 seconds). Therefore both versions of the program are doing the full scan only when it is really necessary. Also, the results of the CRC calculation are now different than in beta-1 (same algorithm, but the data is supplied in reverse order). In the checksum version nothing changed in this respect.

 

"Load ID file" invokes the file selector, and "Save ID file" allows to edit the destination file name, so that one could have multiple ROM sets with ID files corresponding to them.

ant16b2.arc

Edited October 21, 2020 by drac030

[SS]

On 10/21/2020 at 2:16 PM, drac030 said:

Try this one, then. I hope that this problem will not appear again.

 

@drac030 - This seemingly fixed everything on my end.  I didn't actually try switching everything around with all of my loaded Operating Systems this time but the Configurator Tool did save my ID file changes correctly in both the regular and CRC versions. 

[drac030]

Ok, thank you for testing. Here is the final version:

 

ant17.arc

 

I have also uploaded it to my website.