You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi
I've been adding some features to this core myself in my own branch including:
More accurate phosphor colours
Simulation of CPU to Video ram contention (black lines)
I could do with talking to someone about how to handle working together on features since the first feature is incompatible with the latest merge. I was also looking at adding Disk support.
During this work I've been testing various games including games from Big Five and some do not work correctly. For example when Attack Force is running on the core, when you are in the main game loop (not menu) it always thinks that the down and space keys are pressed. Also Meteor mission thinks the right key is permanently pressed. Both these games were off a DSK collection and I had converted the CMD to a CAS file using CMD2CAS.EXE. This bug is something that happened betweened the last official release on the 1st of April, and the current Master branch (as of 4 days ago). The release version from the 1st of April did not have this issue, but there was a major rewrite of keyboard routine after that according to the commit history.
On debugging this issue I wrote the following simple basic program (for the TRS-80):
10 PRINT PEEK(14591)
20 GOTO 10
This code reads the address 0x38FF that will read and combine all keyboard address rows and the results are all OR'd together. Some games use this mechanism to check for a return of 0 indicating no keys are pressed before bothering to scan the address rows individually. Also, they can read multiple rows using this mechanism if they need keys from two rows, but don't care if other keys on the keyboard trigger the action (they are alternative key options for the user).
If you run the above program it should print 0 when no keys are pressed but sometimes it does not. You can force this condition by running the program, then pressing the Left Shift key and holding it down, then pressing and holding down the 8 key on the top row, then releasing the Left Shit key, then finally releasing the 8 key. When you do this, the above code will still report the * key is still held down by returning 4 (bit 2 of 0x3820 for the '*').
I was planning to try and work out what is causing this issue and fixing it in my commit, but after seeing the latest merge, I'm now concerned this core is under active development and I should be co-ordinating my work with whoever is the main contributor.
The text was updated successfully, but these errors were encountered:
While testing, I hadn't seen the specific issues you describe, but I did see double-presses (when a key was held) while playing frogger, so I'm not shocked. However, I wonder what type of keyboard you are using (i.e. US style or otherwise - may alter key scancodes), and whether you have it set to TRS-80 keyboard mapping or PC mapping.
On the other points, there has been a lot of work in the past 2 months to stabilize the core and fix bugs/issues, but much of that should now be complete. I was thinking of adding disk support next, but would be happy to coordinate on that.
Hi
I've been adding some features to this core myself in my own branch including:
I could do with talking to someone about how to handle working together on features since the first feature is incompatible with the latest merge. I was also looking at adding Disk support.
During this work I've been testing various games including games from Big Five and some do not work correctly. For example when Attack Force is running on the core, when you are in the main game loop (not menu) it always thinks that the down and space keys are pressed. Also Meteor mission thinks the right key is permanently pressed. Both these games were off a DSK collection and I had converted the CMD to a CAS file using CMD2CAS.EXE. This bug is something that happened betweened the last official release on the 1st of April, and the current Master branch (as of 4 days ago). The release version from the 1st of April did not have this issue, but there was a major rewrite of keyboard routine after that according to the commit history.
On debugging this issue I wrote the following simple basic program (for the TRS-80):
10 PRINT PEEK(14591)
20 GOTO 10
This code reads the address 0x38FF that will read and combine all keyboard address rows and the results are all OR'd together. Some games use this mechanism to check for a return of 0 indicating no keys are pressed before bothering to scan the address rows individually. Also, they can read multiple rows using this mechanism if they need keys from two rows, but don't care if other keys on the keyboard trigger the action (they are alternative key options for the user).
If you run the above program it should print 0 when no keys are pressed but sometimes it does not. You can force this condition by running the program, then pressing the Left Shift key and holding it down, then pressing and holding down the 8 key on the top row, then releasing the Left Shit key, then finally releasing the 8 key. When you do this, the above code will still report the * key is still held down by returning 4 (bit 2 of 0x3820 for the '*').
I was planning to try and work out what is causing this issue and fixing it in my commit, but after seeing the latest merge, I'm now concerned this core is under active development and I should be co-ordinating my work with whoever is the main contributor.
The text was updated successfully, but these errors were encountered: