Jump to content
tmp

AVGCART

Recommended Posts

11 minutes ago, mytek said:

Off the top of my head I believe that is correct for most all TK-II hardware, except I think the 576NUC+ variant does send one instance directly following power-up via one of it's keyboard power activation key presses (being used to clear the key buffer since it is a null key).

this was the reason why i gave up and changed the autorun hotkey, first issue was with xegs but that could've been that anti-idle thing but then NUC issue was reported

i still don't understand what's going on there, it's either that combo is being held for too long on powerup or it's being sent too late (after OS gave control to cart)

  • Like 1

Share this post


Link to post
Share on other sites
22 minutes ago, mytek said:

Yeah it's probably very tempting, considering that not all CTRL+SHIFT keys actually work on the stock Atari Keyboard.

Indeed, and especially since I need more shortcuts for the SIDE3 loader, given that all the unmodified keys trigger the live search.

22 minutes ago, mytek said:

BTW with the TK-II installed, it's PS/2 key offers a lot more possible combinations ;)

If you mean that the unusable SHIFT+CTRL combinations become usable, that's great, but since these are inaccessible on a machine without TK-II, it's not sensible to map them to anything one cannot live without on a stock machine.

22 minutes ago, mytek said:

except I think the 576NUC+ variant does send one instance directly following power-up

Ah - maybe a few AVG users have NUCs, then.

22 minutes ago, mytek said:

I keep calling CTRL+SHIFT+A the null key for a good reason. If you run the following program you'll see it comes up with a value of 255 when first entering RUN. This reflects the fact that no key has been pressed following the commencement of this simple program.


10 PRINT PEEK(764):GOTO 10

If you then press CTRL+SHIFT+A nothing will initially change, it'll continue to display 255. If you hit any other key it will display and hold the value for that key. Then by pressing CTRL+SHIFT+A  it'll revert to 255 once again. 255 also happens to be the value that can be POKED to clear the key buffer. And the other thing that will be noticed is that when pressing this null key combination, there is no key click sound emitted - because it's the null key :)

That's the way I was previously thinking about it. In fact, I speculated to another hardware designer last night that the reported issue might be caused by a PS/2 keyboard adapter which conflates the fact that $FF is 'no key' in the Atari OS with the fact that $FF is also the scan code for SHIFT+CTRL+A. In essence, it appears I was correct. You're right, of course, in saying that $FF is 'no key' as far as the CIO keyboard handler is concerned, but this is only because the OS implementation decided to use a particular value to clear the pending key register, instead of using a separate register which would enable all 256 codes to be valid (as per SKSTAT and KBCODE, subject to the unusable scan codes).

 

Any OS needs to adhere to this methodology, but there is no reason at all for applications to do so if they choose to read the keyboard hardware directly.

Edited by flashjazzcat
  • Thanks 1

Share this post


Link to post
Share on other sites

I asked @tmp to change the auto key combo because it was causing an issue with the NUC+ when I was testing the cart port; Turns out he'd already changed it but not released the update because another user of a keyboard addon had hit the same problem. This is just a normal example of devs working in cooperation.

 

All this drama over a key combo being unexpectedly changed seems a little contrived. If you really want the CTRL+SHFT+A combo to turn on auto start on the AVG it's also going to conflict with any key macros you have created that use it to make SDX do something for you. 

 

It's probably a good idea to glance (a bit more carefully than previously) over the TK-II key map, it has a lot of functionality that I'd guess most people wouldn't realise it has if they just got one to replace a broken keyboard or something. If you are hitting against CTRL+SHFT+A you are almost certainly hitting against a lot of the simpler key combos too.

 

 

 

Share this post


Link to post
Share on other sites
4 minutes ago, Mr Robot said:

If you really want the CTRL+SHFT+A combo to turn on auto start on the AVG it's also going to conflict with any key macros you have created that use it to make SDX do something for you. 

Genuine question: how can pressing a key combo in the AVG menu affect something which works at the SDX CLI?

Edited by flashjazzcat
  • Like 1

Share this post


Link to post
Share on other sites
24 minutes ago, tmp said:

i still don't understand what's going on there, it's either that combo is being held for too long on powerup or it's being sent too late (after OS gave control to cart)

The NUC+ has a slight pause at startup to allow the keyboard to init because we hit an issue early on in the development. This delay (I think it was 500ms) is probably enough for the Atari to hand over control to the AVG before the keyboard becomes active and the TK-II sends that first null key.

 

Share this post


Link to post
Share on other sites
3 minutes ago, flashjazzcat said:

Genuine question: how can pressing a key combo in the AVG menu affect something which works at the SDX CLI?

If anyone can find a way, _The Doctor__ can

Share this post


Link to post
Share on other sites
36 minutes ago, tmp said:

this was the reason why i gave up and changed the autorun hotkey, first issue was with xegs but that could've been that anti-idle thing but then NUC issue was reported

i still don't understand what's going on there, it's either that combo is being held for too long on powerup or it's being sent too late (after OS gave control to cart)

There is a delay imposed by the NUC before reset is released on powering up (total time maybe 1-1/2 to 2 seconds?). It's absolutely required by the FujiNet to allow it time for full initialization. Only after this delay can the null key send clear the key buffer which is needed by the NUC following its power-up sequence. So yes, the null key will be sent a bit after power-up due to the imposed reset release delay. However it is a quick send maybe 30-40 ms and then released.

 

Edit: I see Mr Robot already covered some of this while I was writing this post :)

 

30 minutes ago, flashjazzcat said:

That's the way I was previously thinking about it. In fact, I speculated to another hardware designer last night that the reported issue might be caused by a PS/2 keyboard adapter which conflates the fact that $FF is 'no key' in the Atari OS with the fact that $FF is also the scan code for SHIFT+CTRL+A. In essence, it appears I was correct. You're correct, of course, that $FF is 'no key' as far as the CIO keyboard handler is concerned, but this is only because the OS implementation decided to use a particular value to clear the pending key register, instead of using a separate register which would enabled all 256 codes to be valid (as per SKSTAT and KBCODE, subject to the unusable scan codes).

 

Any OS needs to adhere to this methodology, but there is no reason at all for applications to do so if they choose to read the keyboard hardware directly.

 

Probably in a lot of situations the null key could still get used for a menu selection, so long as it isn't something that is looked at within the first couple of seconds following power-up with a 576NUC+, and of course the screen saver disable aspect in the NUC would need to be turned OFF (and left OFF).

 

30 minutes ago, flashjazzcat said:

If you mean that the unusable SHIFT+CTRL combinations become usable, that's great, but since these are inaccessible on a machine without TK-II, it's not sensible to map them to anything one cannot live without on a stock machine.

I would never suggest using keys that only exist on a TK-II PS/2 keyboard combination exclusively. But sometimes it can make life easier if they are used as enhancement instead. Some of which you've already done in your BIOS.

 

Edit: I modified the SDrive Control program to use some of these keys to better navigate the menus. And although my version is exclusive to the TK-II, if I had the source code I could have likely made it work for both the stock Atari keys as well as the PS/2 keys.

  • Like 1

Share this post


Link to post
Share on other sites
3 minutes ago, Mr Robot said:

If anyone can find a way, _The Doctor__ can

Well, pragamatically, the way I understood the problem he reported is that TK-II was issuing SHIFT+CTRL+A at the SDX command prompt in just the same way it was issuing SHIFT+CTRL+A in the AVG menu, causing a problem in both instances. I just mean that I don't see any co-dependency between SDX and AVG choosing to attach functionality to SHIFT+CTRL+A.

  • Like 1

Share this post


Link to post
Share on other sites
12 minutes ago, mytek said:

There is a delay imposed by the NUC before reset is released on powering up (total time maybe 1-1/2 to 2 seconds?). It's absolutely required by the FujiNet to allow it time for full initialization. Only after this delay can the null key send clear the key buffer which is needed by the NUC following its power-up sequence. So yes, the null key will be sent a bit after power-up due to the imposed reset release delay. However it is a quick send maybe 30-40 ms and then released.

well, if i understand the issue correctly, it's still being held when the cart starts so that's after os inits, clears all ram, etc so i still think it's being sent too late or held for too long

Share this post


Link to post
Share on other sites
1 hour ago, tmp said:

well, if i understand the issue correctly, it's still being held when the cart starts so that's after os inits, clears all ram, etc so i still think it's being sent too late or held for too long

Just checked the code. Following power-up, there is a 500 ms delay before reset is released, then a 2 second delay following that, after which the 'null' key is sent for approximately 32 ms and then released.

 

So yes you are correct that the null key press is coming late after reset has been released. I must have had a reason for doing this, but it escapes me for the moment.

 

Edit: I think I figured out the reasoning, and it has to do with the ability to hold down one of the console keys as part of the boot process. Because the 576NUC+ requires some key presses to activate power (ALT+~ or 1-4), I implemented an alternative method for held console keys. So when the NUC is turned OFF, pressing a console key momentarily, latches that key so that when you do turn ON the system, that console key is being held. Approximately 2-1/2 seconds following power-up all latched console keys are released (e.g., after that 2 second delay, the console key latch register is cleared). BTW, if you change your mind after pressing a console key when the system is off, pressing ALT+0 will unlatch it.

 

So I think all I need to do is move the null key send to just before the 2 second delay, and leave the console key latch register release after the 2 second delay. Should work, but I'll need to try it to be sure.

  • Like 1

Share this post


Link to post
Share on other sites
On 7/29/2021 at 3:03 PM, tmp said:

i'm unable to test this, if you can send me the corrupted files together with the original ones, i could take a look if there's any interesting pattern (whole hd images would be better but that's probably too complicated)

Well, continued to further test typical admin. / maintenance work on SDX... 


This may (or may not) be related, but there is I/O corruption, right from SDX prompt (also when attempting to perform CLX integrity check, it will yield un multiple sector-read errors, all at seemingly random locations):

 

9DBCF1E8-6DF6-4C12-A251-A78D68F318B0.thumb.jpeg.fd8d9e1e1bdc35f6374cb32c813a900d.jpeg

 

What is strange though, is that a lower-level read-test off IDE controller passes multiple times with flying colors:

 

4410F5BE-AF0B-4035-BA83-61B5906BCB6A.thumb.jpeg.69d8d17f5928beeb49a7c8f8524d91cc.jpeg

 

All tests above on my 040-0077 800 (CTIA / GTIA), with 512KB AXLON ram expansion and stock OS/b roms.

 

I can't really tell if the problem is coming from read-attempts of the card, or running code from SDX-cart image itself... (because low-level IDE tests do seem to work well)

 

This particular error sequence, however, is much more infrequent when plugged on my 800/Incognito/Sophia-2 and completely inexistent when running SDX and PBI HD/CF off Incognito, fyi... 

 

Any ideas of what could be wrecking the I/O requests?

 

 

 

 

Share this post


Link to post
Share on other sites
28 minutes ago, Faicuai said:

Well, continued to further test typical admin. / maintenance work on SDX... 


This may (or may not) be related, but there is I/O corruption, right from SDX prompt (also when attempting to perform CLX integrity check, it will yield un multiple sector-read errors, all at seemingly random locations):

 

9DBCF1E8-6DF6-4C12-A251-A78D68F318B0.thumb.jpeg.fd8d9e1e1bdc35f6374cb32c813a900d.jpeg

 

What is strange though, is that a lower-level read-test off IDE controller passes multiple times with flying colors:

 

All tests above on my 040-0077 800 (CTIA / GTIA), with 512KB AXLON ram expansion and stock OS/b roms.

 

I can't really tell if the problem is coming from read-attempts of the card, or running code from SDX-cart image itself... (because low-level IDE tests do seem to work well)

 

This particular error sequence, however, is much more infrequent when plugged on my 800/Incognito/Sophia-2 and completely inexistent when running SDX and PBI HD/CF off Incognito, fyi... 

 

Any ideas of what could be wrecking the I/O requests?

This seems to be something strange not related to the AVG cart at all.

The first error message on your picture above pops up from time to time when using/testing SDX. Unfortunately, I could not find the source for it so far.

Running SDX on a 800XL with IDE+ Rev C and 256 KiB Compy Shop memory extension. The files are not found though they even there, as DIR reports.

The other errors show up from time to time as well. It is not predictable when it will happen. But as I saw it several times in Altirra as well running an exact mirror of my system setup it is real, seems to be hard to come by ...

  • Like 1

Share this post


Link to post
Share on other sites
11 minutes ago, GoodByteXL said:

This seems to be something strange not related to the AVG cart at all.

The first error message on your picture above pops up from time to time when using/testing SDX. Unfortunately, I could not find the source for it so far.

Running SDX on a 800XL with IDE+ Rev C and 256 KiB Compy Shop memory extension. The files are not found though they even there, as DIR reports.

The other errors show up from time to time as well. It is not predictable when it will happen. But as I saw it several times in Altirra as well running an exact mirror of my system setup it is real, seems to be hard to come by ...

something for the 4.49 folks to look at then...

Share this post


Link to post
Share on other sites
1 hour ago, GoodByteXL said:

But as I saw it several times in Altirra as well running an exact mirror of my system setup it is real, seems to be hard to come by ...

Now. THAT is weird... showing up in Altirra? Oh well...

 

What I can say is that I can successfully perform a full CLX operation on a 32 MB APT partition through AVG, when plugged on my 800/Incognito, and NO sector-read errors. Rock-solid on that particular host (with exception of Incognito-HD to AVG-HD sector transfers, which can be performed on-board the 800 bus, although writes seemingly creating unwarned VTOC corruptions (no visible errors during I/O).

 

Seems like a combination of [AVG + SDX SIDE drivers + Host timing]. It is potentially complex to resolve but 100% sure it is there. No doubt.

 

(NOTE: I just swapped the RAMROD OS board for my regular / backup OS board, on my reference 800, and the problem repeats identically. I do wonder, however, how is AVG timing itself with respect to the host system, since there is RAS on 800's left-cart port, while PHi2 is only available on right-cart port)...

Share this post


Link to post
Share on other sites

0021 was released, not much was changed since the last beta, it contains fix for Flight Simulator II

 

0021
====
- XEX loader now doesn't occupy $0800 page
- ATR/ATX emulation fixes (Bruce Lee, Ultima, Flight Sim II)
- Allow IDE emulation together with ATR emulation (SIO)
- Show COM/EXE files in browser
- Increased limit of virtual drives to 8 (SIO)
- Autorun key changed from 'A' to 'N' due to issues with PS/2 adapters
- Added saving facility (used by FloB)
- Stacking SpartaDOSX with another CAR (CTRL-SHIFT-RETURN)

 

  • Like 3
  • Thanks 2

Share this post


Link to post
Share on other sites

Thank you tmp...Com and exe is handy, saves mass renaming to xex and I like to keep the files as they were released..

Edited by Mclaneinc

Share this post


Link to post
Share on other sites
4 hours ago, tmp said:

Stacking SpartaDOSX with another CAR (CTRL-SHIFT-RETURN)

So how does this work?

 

...by placing an SDX/SIDE cart image on the same directory containing the cart to be stacked?

 

 

 

Share this post


Link to post
Share on other sites

ctrl shift return sets the stacked cart

then just select the sdx cart per usual

bobs your uncle

Share this post


Link to post
Share on other sites
37 minutes ago, Faicuai said:

So how does this work?

 

...by placing an SDX/SIDE cart image on the same directory containing the cart to be stacked?

you need to have /_AVGCART/SDX.CAR on your sd card, try one of these for now, then you can launch e.g. some OSS cart by using ctrl-shift-return and it will try to stack it with SDX.CAR so SDX should boot and CAR should start the stacked cart (which should have access to hdd)

@a8isa1 was playing with it so he probably knows more than me how well/bad it works

 

Edited by tmp
  • Like 1

Share this post


Link to post
Share on other sites

Hi tmp, just a note, the PDMPLAY in the update is still the wrongly named Covox version and not the PDM mono version which I imagine should be the default. Xuel released an updated correct name AV Play 1.1 zip

 

Just in case any non Covox people wonder why it's gone silent after the 0021 update  :)

  • Like 1

Share this post


Link to post
Share on other sites

thanks for reporting, should be fixed, for some reason i thought the problem was only with his zip but apparently i had also the wrong version

Share this post


Link to post
Share on other sites
33 minutes ago, tmp said:

thanks for reporting, should be fixed, for some reason i thought the problem was only with his zip but apparently i had also the wrong version

is that to say all of the 0021 links are now updated with pdm player oops corrected version?

Edited by _The Doctor__

Share this post


Link to post
Share on other sites

Hi tmp, having issues with ABUSE both ATR and ATX, tried various with U1MB set to OSB, I only have Altirra Basic or Basic C but surely one would be ok... It feels like its not getting BASIC??

 

Same image works on Altirra..

 

Sample file used

 

Abuse v2.9 (1981)(Don't Ask Software)(US)[!][BASIC][OS-B]

 

Edit: Also tested Color Print which I picked because it needed Basic and sure enough, it was going to dos saying only type one letter which is what happens if Basic isn't enabled..its an ATX, I thought just pressing fire or return would be right, no need to hold Option to disable basic..

Edited by Mclaneinc
  • Confused 1

Share this post


Link to post
Share on other sites
35 minutes ago, tmp said:

thanks for reporting, should be fixed, for some reason i thought the problem was only with his zip but apparently i had also the wrong version

Pleasure...The actual fixed Xuel file says corrected names in the title..

Share this post


Link to post
Share on other sites

Color print now works under XL with Basic C when set to XL in U1mb, still no joy with abuse...Don't know what Color print was coming up like Basic was off, admittedly it was in OSB mode..

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