Pokeymax version 3 preorder

[_The Doctor__]

Do you also have a real Pokey installed in the motherboard?

 

[Atari8guy]

Nope.  Just the Stereo PokeyMax2.  The Pokey is sitting in a box in my desk drawer

[_The Doctor__]

So one PokeyMax, no real Pokey, and there aren't two PokeyMaxes

I was of the thought that the issue is when there are two PokeyMaxes or a PokeyMax on the MB plus a real Pokey.

This may come down to what core is in use and what combination.

May be we need a spreadsheet with core versions and combinations.

Edited July 17, 2023 by _The Doctor__

[Atari8guy]

I thought the PokeyMax replaced the pokey in the machines...I suppose you could have a stereo board in there (for 2 pokeys), but that seems like playing with fire.  However I only have the pokeymax2, so I'm not sure how the others work.

 

 

EDIT: According to the change log - http://www.64kib.com/pokeymax_files/changelog.txt the TKII issues were addressed in firmware updates 1.18 and 1.19?

Edited July 17, 2023 by Atari8guy

[flashjazzcat]

30 minutes ago, Atari8guy said:

According to the change log - http://www.64kib.com/pokeymax_files/changelog.txt the TKII issues were addressed in firmware updates 1.18 and 1.19?

It reads to me as if this depends entirely on the appearance of 'future TKII firmware' which 'further improves' things. Neither hardware developer appears to think the issue was nailed, anyway.

[Atari8guy]

Yeah it sort of says...."works okay, could work better"...  

 

I trust yours and Mytek's expertise, but mine definitely works fine - use it almost daily.

 

 

[flashjazzcat]

31 minutes ago, Atari8guy said:

Yeah it sort of says...."works okay, could work better"...  

It possibly depends on one's subjective interpretation of 'works okay':

Elsewhere, I was told that cursor movement is 'not as smooth as it should be', but that this 'should not affect usability'. YMMV.

Edited July 17, 2023 by flashjazzcat

[+mytek]

5 hours ago, Atari8guy said:

I think I've mentioned this before and maybe it helps to lock down what the issue might be, but I have a PokeyMax 2 (that FJC installed) in my XEGS and the external Transkey II-GS device and I have zero issues with key repeat or any other functions.

That device uses a parallel connection to the Pokey Key Scan Counter, so apparently no timing issues with PokeyMAX because of that. The latest designs which did come out before there was even a PokeyMAX being sold, changed over to a sampling technique of only two of the possible six Key Scan Counter bits, and then it synchronizes a virtual counter within the PIC chip to match. this was done to free up 4 PIC I/O bits for other purposes This change is especially key to the 576NUC+ and the TK-II-PBJ Pokey piggyback board made for other machines. Both of them absolutely require the new firmware that utilizes sampling & syncing. And this is the only firmware that i have been keeping updated with fixes.

 

Here is a link to legacy versions of the hardware and firmware for those that might be interested: https://ataribits.weebly.com/tk-ii-archives.html

 

That particular legacy firmware received its last update two years ago, and I really have no plans to do anything else with it, nor do i even remember what all has changed as compared to the current firmware.

 

Now a big part of the problem with the new firmware's syncing aspect, has to do with the PIC I/O pins assigned to the Pokey Key Scan Counter bits that are being sampled, which don't have any interrupt aspect. Being able to react to an interrupt when ever these two bits changed states would have allowed for much tighter syncing to the real Pokey counter. Instead I had to resort to using one of the PIC's internal hardware counters and the built-in count-up function tied to the PIC's internal oscillator, which was then divided down to match the speed of the 'real' Pokey counter (this is all setup to happen automatically in the hardware). This way I simply poll the low and high bits of the 'real' Pokey counter and use their states to sync (reset) the PIC's internal counter to match. And from that point on the TK-II routines use that internal counter to know when to toggle the two Key Request lines on the Pokey in response to a PS/2 key press. In theory and in real life with a 'real' Pokey chip it all works perfectly.

 

Since an FPGA alternative imitates how a Pokey chip works, it's not going to be an exact reproduction, and there will obviously be compromises in some areas of operation. For a person who is satisfied with using the original keyboard, and is not trying to put a PokeyMAX in something like the 576NUC+ which only has PS/2, the FPGA solution appears to be working well.

 

Edit: I brought up the fact that I'm not making any money from the sale of TK-IIs earlier, because it is pertinent in my mind to how much of my money is available for R&D on the projects I develop. Currently there is none set aside for purchasing a PokeyMAX (not like it would have mattered with the chip shortages). And without that, it's simply not possible for me to zero in on a fix from the TK-II side of things. Lastly there's little incentive for me to do this, when I have lots of other things competing for my time

 

[Atari8guy]

2 hours ago, flashjazzcat said:

It possibly depends on one's subjective interpretation of 'works okay'

Well that's always the case!  Anyway, seems Mytek has posted information at level way above my pay grade, but seems to explain why my particular version works fine (or "okay"  ).  So I'll shut up now, having added very little to this.

[_The Doctor__]

but had you not made the squeak, no one would know to use the depreciated pic programming. So it's good you spoke of it

[+mytek]

1 hour ago, _The Doctor__ said:

...no one would know to use the depreciated pic programming.

Keep in mind that the depreciated PIC firmware only works with depreciated TK-II hardware (definitely rules out the 576NUC+). As for something like a 400/800/XL/XE both of those depreciated aspects would need to be in play when used with a PokeyMAX in order to have smooth key repeat functionality.  EDIT: this is to the best of my knowledge, although I have not tested such a scenario.

 

This will be the case until such time that either PokeyMAX can be made to look identical to a 'real' Pokey from a Key Scan Counter and Key Response aspect timing-wise, or present day TK-II hardware and firmware can be made to adjust for the differences.

[+mytek]

I was thinking about this a bit, and if the problem relates to the Pokey KR1 line being too quick to change (I'm grasping for straws here), then perhaps adding some capacitance to GND might adjust things enough to render a smooth key repeat. So if anyone that has a PokeyMAX with one of the newer TK-II boards installed would like to give this a try here's a schematic showing the MOD. I have no idea of how much or how little capacitance would be required, but have given a suggested starting value.

 

 

If someone gets a successful result, please let us know what capacitor value worked.

 

If this does something positive, then it might give me clue as to what I might be able to do in the software to have the same effect, thus not requiring the addition of the capacitor.

[foft]

For the software try to consistently change kr1/kr2 within 30uS of the scan pins changing.

[madness77]

Hi, is it still possible to order PokeyMax?

[Duddie]

Yes, but v2b. 

[patjomki]

On 7/17/2023 at 5:57 PM, Atari8guy said:

EDIT: According to the change log - http://www.64kib.com/pokeymax_files/changelog.txt the TKII issues were addressed in firmware updates 1.18 and 1.19?

 

Cannot access this website: Time Out. 😪

[lostboy]

On 9/12/2023 at 5:32 PM, patjomki said:

 

Cannot access this website: Time Out. 😪

Wayback machine has the snapshot: changelog.txt