False key presses in some games (and stuck keys) #14
Comments
|
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. I'll contact you separately on that. |
This should fix issue MiSTer-devel#14
* remove compiler warnings * remove compiler warnings * - add a 'spare' debug field of 12 bits to report signals under current debugging. The released version is as follow bit 11 : a sector-not-found error has occured bit 10 : a track error has occured bit 9 : the controller went double-density (which is not implemented whatsoever) bit 8 : track in fd1771 is not equal to track in floppy (seek not done) bits 7-0 : counter of 'data_lost' authorized slippage (maximum data_lost recovered we had to wait in a sector read)) - modified the way the motor timing is generated to avoid truncature of results like 20/12 = 1, leading to unwanted timeouts removing multiply and divide operation is a free bonus - other minor corrections * This release tend to make LDOS work. NEWDOS and TRSDOS work fine, but LDOS seems more fragile or more demanding. Anyway, with this release, it boots, and the MISOSYS C compiler get though compiing UNARC/CCC, sort of. - generate a sector_not_found error if - track in controller differ from track in device - track out of bounds (of disk image) - fix controller track stepping bounds so tracks don't get negative. - generate a seek error if the track in the drive is different of the desired track in the controller at the end of the seek op. - add grace steps if data_lost occurs. This is not in the specs of course, but LDOS makes a lot of these errors, so befor we find why, this fixes it. - change HLD head status so that it stays loaded between tracks - lower sector_not_found delay because if the floppy motor goes off before operation is finished, everything gets locked up. - add some debug for error tracking - fix SECTOR_BASE to 0 - Remove all code for sector len = 128 or 1024, just kept 256 aand 512 if double density is implemented one day - In the same spirit, keep controller_type at 0, and keep only one way to compute sd_lba JV1 compatble - remove some useless code - removed "cmd_rx_i" delay because I can't figure out what it does. * - I fixed a boo-boo in my last data-lost tolerent algo. - Fixed the 'BOOT' command in a DO JCL job This should be now a stable release, at least a Release Candidate. LDOS boots and a complete C compiling job works flawlessly (Misosys C compiler, command DO MC (N=UNARC) ) * disk I/O fixes. LDOS stabilized. * Fixes in the "PC" section of the keyboard driver. This should fix issue #14
|
This should be fixed by TRS-80_20241111.rbf |
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: