Incognito STICK(3) and STRIG(3)

[flashjazzcat]

I can observe most of this, but regardless of whether sticks 3 and 4 are enabled in the BIOS or not. $234/5 are the shadows for the light pen coordinates at $D40C/D.

Edited December 3, 2018 by flashjazzcat

[Faicuai]

I can observe most of this, but regardless of whether sticks 3 and 4 are enabled in the BIOS or not. $234/5 are the shadows for the light pen coordinates at $D40C/D.

 

Correct! I DID notice this myself before reporting, but forgot to mention... BIOS setting does not matter. Port 3 and 4 are always being (physically) read for trigger input, in one way or another.

[flashjazzcat]

This isn't especially surprising. Incognito does not sever the motherboard connections to ports 3 and 4, and the reason for joystick 3 and 4 emulation is to overcome to contention for PORTB between extended RAM banking and port 3 and 4 input. In the unlikely event that the intention is to overload PORTB with dual functionality when ports 3 and 4 are enabled in XL/XE mode, I suppose the port would have to be configured as an input first anyway.

[Faicuai]

Ok, quick update here:

1. Have not yet been able to systematically reproduce the glitch on BIOS main screen, but I experienced it TWO times, and I was really paying f-attention.
2. On the two times that I experienced it:
   • I had first gone from BIOS main-screen INTO SIDE loader.
   • Had loaded a title, and then hit "Atari + System RESET" to return to BIOS screen, and experience the endless bottom-top option cycling.
   • Joystick #1 was SELECTED in both side-loader and BIOS main screen.
   • Joysticks 3/4 setting varied from incident, so I could discard it (e.g. it does not make a difference).
   • When the glitch appeared, I intentionally plugged the Joystick into Port #1, #2, #3, #4 and IT DID NOT have ANY effect on on-going glitch.
   • Glitch disappeared as soon as I pressed [Atari + System Reset] again...
   • I had the impression that I may have had a bad PIA but, as it seems, I doubt it...

I am currently testing the above sequence, but with Joystick DISABLED on BIOS SCREEN (but still ENABLED on SIDE loader, though).

Edited December 4, 2018 by Faicuai

[flashjazzcat]

Thanks for the info. It sounds like this isn't related to the joystick at all and there's some issue with your keyboard or POKEY chip.

 

Regarding joystick input settings in the loader and BIOS menu: they're unrelated (neither component knows or cares how the other is set up). The loader has a type-ahead keyboard buffer so if problems surfaced, I'd have expected them to be there rather than in the main BIOS menu, where there's simply a keyboard IRQ handler and some debounce and auto-repeat logic. The joystick handler uses the same debounce and auto-repeat logic and just feeds dummy keystrokes to the menu handler.

Edited December 4, 2018 by flashjazzcat

[Faicuai]

Thanks for the info. It sounds like this isn't related to the joystick at all and there's some issue with your keyboard or POKEY chip.

 

Regarding joystick input settings in the loader and BIOS menu: they're unrelated (neither component knows or cares how the other is set up). The loader has a type-ahead keyboard buffer so if problems surfaced, I'd have expected them to be there rather than in the main BIOS menu, where there's simply a keyboard IRQ handler and some debounce and auto-repeat logic. The joystick handler uses the same debounce and auto-repeat logic and just feeds dummy keystrokes to the menu handler.

 

No, the cause-effect chain currently on-hand suggests that Keyboard or POKEY problem are not likely. The reasons:

1. This glitch began RIGHT after I upgraded to latest BIOS.
2. It happens (apparently random) IF and ONLY IF the [Atari+RESET] combo is pressed. I currently have enabled further OS functionality (cycle-exact to OEM ROM) that requires ATARI key combination, and there is absolutely not a single occurrence of the issue during runtime (applications, games, programming, etc.) Moreover, pressing the RESET key alone, does not cause absolutely any problem, as well. It is ONLY when going back to BIOS screen, with those two keys, and then it disappears permanently by pressing them again.
3. In other words, I can systematically replicate the elimination of the problem, with a one-time action, and HW problems DO NOT usually disappear systematically with one single action. They fester and pester multiple times in your timeline, usually in multiple or unexpected circumstances or locations.

Just a quick favor: could you please, check sure that ALL inputs (joysticks, keyboard scanner variables, etc.) are literally reset in code, right before BIOS screen start-up? In other words, immediate "zero" or data-bytes next to the opcodes at the section that precedes keyboard / ports scan routines or the main menu screen? Of course, that is they are not already (I am not familiar with your BIOS source code...)

Edited December 4, 2018 by Faicuai

[flashjazzcat]

No-one but me is familiar with my BIOS source code, since it is closed-source.

 

If the glitch is so infrequent and random that it was this difficult to observe the exact circumstances in which it occurs, I'm not sure firmware upgrade can be conclusively blamed. For instance, my CPLD once became corrupt at the exact time I flashed a pre-release BIOS update and needless to say it took some time to figure out that it was the CPLD which needed reprogramming and not my firmware.

 

In any case: when you say the problem 'disappears permanently' by pressing the Atari-Reset key combo a second time, do you mean it never comes back until you power cycle the machine again?

 

Regarding initialisation: I have looked again, but it is frankly difficult to see how user input could run away with itself in such a manner, especially since the key pressed immediately prior to the issue appearing is not the down arrow key but the Atari Logo key. The keyboard is initialised well before the BIOS menu appears, since it has to be readable before anything appears on the screen and while the splash screen (if enabled) comes up. When the Atari Logo key is released - as it eventually must be - the main loop is basically idling, waiting for a keyboard IRQ or some joystick input to take place.

 

The other problem is that it's impossible thus far to duplicate the issue on any hardware but yours. If there is another Incognito or U1MB user who has experienced this, they have said nothing about it, and the keyboard and joystick handling code is identical in the Incognito and Ultimate 1MB firmware (aside from some variation in the actual scan code expected for BIOS entry, of course). Even a problem only present on NTSC machines (my 800 is PAL) would probably have exhibited itself on an NTSC Ultimate 1MB machine by now.

 

I take it all joystick input is disabled at this point, so we can basically rule that out and focus on the keyboard?

 

PS: Try switching the BIOS hotkey from Atari to Start and see if that makes a difference.

Edited December 4, 2018 by flashjazzcat

[Faicuai]

No-one but me is familiar with my BIOS source code, since it is closed-source.

 

If the glitch is so infrequent and random that it was this difficult to observe the exact circumstances in which it occurs, I'm not sure firmware upgrade can be conclusively blamed. For instance, my CPLD once became corrupt at the exact time I flashed a pre-release BIOS update and needless to say it took some time to figure out that it was the CPLD which needed reprogramming and not my firmware.

 

In any case: when you say the problem 'disappears permanently' by pressing the Atari-Reset key combo a second time, do you mean it never comes back until you power cycle the machine again?

 

Regarding initialisation: I have looked again, but it is frankly difficult to see how user input could run away with itself in such a manner, especially since the key pressed immediately prior to the issue appearing is not the down arrow key but the Atari Logo key. The keyboard is initialised well before the BIOS menu appears, since it has to be readable before anything appears on the screen and while the splash screen (if enabled) comes up. When the Atari Logo key is released - as it eventually must be - the main loop is basically idling, waiting for a keyboard IRQ or some joystick input to take place.

 

The other problem is that it's impossible thus far to duplicate the issue on any hardware but yours. If there is another Incognito or U1MB user who has experienced this, they have said nothing about it, and the keyboard and joystick handling code is identical in the Incognito and Ultimate 1MB firmware (aside from some variation in the actual scan code expected for BIOS entry, of course). Even a problem only present on NTSC machines (my 800 is PAL) would probably have exhibited itself on an NTSC Ultimate 1MB machine by now.

 

I take it all joystick input is disabled at this point, so we can basically rule that out and focus on the keyboard?

 

PS: Try switching the BIOS hotkey from Atari to Start and see if that makes a difference.

 

OK, I believe I have had enough time and testing to provide some final comments, at least for now.

 

After I switched off the JOYSTICK for user-input on BIOS main menu, the issue has disappeared. It has not repeated itself, especially during the sequence / circumstances that it appeared before (going back to main BIOS menu with Atari+RESET keys).

 

Please, go ahead and proceed with your planned BIOS release, as I don't see any point in holding such timeline because of this hard-to-trace issue. I will run a 'burn-in" tests of controller-ports readouts, for a long time, to see if random / false reads appear on their own (have never seen it outside of BIOS screen, but will that first to fully discard).

 

I will keep you posted with anything meaningful. A HUGE thanks for your support!!!

[flashjazzcat]

Thanks: I appreciate the follow-up. I was inclined to discount the keyboard entirely the more I thought about this over the past couple of days (simply striking a key would surely break the deadlock), and if the problem is related to the joystick - which it appears to be thanks to you confirming that the issue goes away when joystick control is disabled - it's unlikely to be a bug since the initial shadow (StickState) of the joystick input bits is set to $0F at the same time the keyboard is initialised, and this completely neuters input from the joystick until the bits on the port read differently:

 

	lda PORTA 	; Stick
	cpx #$FF	; port 1?
	beq IsPort1
	lsr @
	lsr @
	lsr @
	lsr @
IsPort1
	and #$0F
	cmp #$0F
	bne @+
	sta StickState	; stick state = neutral
	beq Return
@
	cmp StickState	; previous stick input
	bne StickChange	; direction change
	ldy Timer
	beq DoRep
Return
	lda #$FF
	rts

StickChange		; stick direction changed
	sta StickState

Unless there's something pulling bits low on PORTA, the joystick handler bails out with $FF in the accumulator (i.e. the 'no key' scan code).

 

In any case, on the machine in question it seems reasonable to suppose PORTA is not reading as it should in certain circumstances.

 

Thanks again for all the info provided.

[_The Doctor__]

Just an aside, while reading on candles site, he mentions that his email had changed and he did not update it across the board everywhere, so he does not receive email or notifications from all over anymore, some where on his site is a new email or email link, you have to use that to communicate with him. Probably old news but just in case, maybe concise to the point list of whatever all have been dining on with a header of, We know your busy so right to the points...

just an idea, and probably old news. I haven't seen much else about it though

[flashjazzcat]

I don't know what 'maybe concise to the point list of whatever all have been dining on with a header of' means, but my most recent conversations with Candle were conducted via AtariAge PM as recently as January 2018. There is a post here which he says he no longer uses email at spiflash.org, but that was written seven years ago.

[_The Doctor__]

almost a year ago then. okay. so it's old news then.

[flashjazzcat]

Well, the change of email I'm talking about happened seven years ago but if you can link to the passage on his site which mentions something more recent I'd be happy to read it.

[_The Doctor__]

almost a year ago when you mailed back and forth, so no it's old news. I expect a critique on my breathing next... I paused to0 long between breathes or I breathe out when I should breathe in... since no dates for when folks had contact were given (that I am aware of until now) I was curious why people have reported no contact possible at all. I can see why one might get frustrated and go about normal life rather than deal with things the way they get though.

[flashjazzcat]

I'm sorry - where is this going? Post 60 was quite difficult to follow but you appear to be suggesting Candle recently changed his email address, and this was based on something you read on his website of which I am completely unaware. In what way exactly am I presenting a critique? I've asked you a simple question. Is doing so unacceptable or in some way overwhelming?

[_The Doctor__]

I don't know but I don't intend to have a 60 post spat over any of it, I noted, 'it's probably old news', old news does not infer it's new. But I am sure there is some mechanical issue with anything I type where you are concerned. So I leave you to it. This is pretty much old news as well. Being perfectly content with of just one exception in that you are not. It's okay to make mistakes in life. But that's just my opinion. I never expected this sort of response, it's boorish at this point.

 

I'll still wish you a Merry Christmas and a Happy New Year, and hope you all the best.

Edited December 6, 2018 by _The Doctor__

[flashjazzcat]

I hadn't visited Candle's site in a long time, and you gave no indication of when it was you saw the information you mentioned. One would imagine 'recently'. The fact I spoke to him eleven months ago doesn't mean new information could not have surfaced in the meantime, although now I look it appears his site in in the same stripped-clean state it's been in for some years.

 

But it's no problem. I was just trying to figure out what you were talking about. Peace out!

[Faicuai]

Thanks: I appreciate the follow-up. I was inclined to discount the keyboard entirely the more I thought about this over the past couple of days (simply striking a key would surely break the deadlock), and if the problem is related to the joystick - which it appears to be thanks to you confirming that the issue goes away when joystick control is disabled - it's unlikely to be a bug since the initial shadow (StickState) of the joystick input bits is set to $0F at the same time the keyboard is initialised, and this completely neuters input from the joystick until the bits on the port read differently:

 

	lda PORTA 	; Stick
	cpx #$FF	; port 1?
	beq IsPort1
	lsr @
	lsr @
	lsr @
	lsr @
IsPort1
	and #$0F
	cmp #$0F
	bne @+
	sta StickState	; stick state = neutral
	beq Return
@
	cmp StickState	; previous stick input
	bne StickChange	; direction change
	ldy Timer
	beq DoRep
Return
	lda #$FF
	rts

StickChange		; stick direction changed
	sta StickState

Unless there's something pulling bits low on PORTA, the joystick handler bails out with $FF in the accumulator (i.e. the 'no key' scan code).

 

In any case, on the machine in question it seems reasonable to suppose PORTA is not reading as it should in certain circumstances.

 

Thanks again for all the info provided.

 

 

Ok, two additional data-points, for future reference:

 

1. When using [Atari+Reset] back-to-BIOS combo, and LEAVING Joystick permanently plugged on port 1, the glitch seems to disappear.

2. When using [sTART+Reset] back-to-BIOS combo, and NOT plugging the Joystick on port 1, the glitch also seems to disappear (have not seen it again).

3. Have NOT yet tested leaving the Joystick connected to Ports 2,3 or 4. That's for future.

4. When the glitch appears, and I press "ESC" to go back from where I invoked the BIOS, and then come back, the glitch immediately stops.

 

I will continue to test #2 for longer, but if it remains stable, it seems that the issue is routing us to whomever is handling / scanning or [is related to] the keyboard. It is getting locked up with a ghost reading, as a product of the "switch" that takes place when pressing such keys-combination.

 

As discussed above, NO action required at all on your side, just to keep you informed, so you can see that I am doing my homework... :-)

Edited December 8, 2018 by Faicuai

[Kyle22]

Hey Admin(s) Can you please the title of this thread to Stick(2) and (3)? I obviously made a typo. Just noticed it now.