Oh yea, that's a kinda a missing feature. PS/2 keyboards have auto-repeat internally, USB only reports currently held keys. OTOH, you can easily implement it:
If you get a key-down event, store it and reset the timer to the initial wait value
If you get a key-up event matching the stored down event, delete the stored event
If timer expires while a down event is stored, repeat it, reset timer to repeat value
The initial wait and repeat times being different is important to making it feel good.
There is a standard problem with the spccog : UTF16
Edit: converted, hacked, upgraded, now the player uses 1.2. This version has several lines added that sends the data to the prop2play oscilloscope. However play timer doesn't run, I have to find why. And enable VU bars
Preliminary mp3 support. To make a proper mp3 support I still have to do a lot of things, but now it plays, although the samplig frequency is not yet adjusted as it should be.
The binary uses hdmi at p0, av at p8, usb at p16
There are still a lot of bugs in mp3 related player code to fix.
And I have a problem now with very long file names that cannot open. As i can remember, there is a restriction somewhere in the player that has to be raised or removed, but now the palyer crashes while trying to open the file with too long file name.
Also, the Flexprop's LFN fails on the files that have non-standard (in this case Polish) letters in their names. It then escapes to a short file name with ~ in it.
But there are also a lot of possible garbage in mp3 files themselves.
The code that skips id3v2 based on its length field was not good enough for several mp3 files I am using to test the player. After the proper id3v2 there was a lot of zero bytes left in the file before the first mp3 frame in the file. (and these id3 tags can be gigantic.... the player surprised me with the text "tag detected, size=1.001705e+06")
So, the version I attached here, has an enhanced algorithm that if there in no mp3 frame header and also no ID3 tag, it searches for the first FFFx or FFEx in the file. It does it also after the id3v2 tag.
Edit: yes, I restricted the file name length in the player... 640 kB 38 characters should be enough for all.... That is not true for these mp3s.
It seems the picture is 500x485. Somewhere in the future maybe I will write a proper id3 decoder; now it only reads the length, then skips the tag only to find a (EDIT: hundreds of ) kilobyte(s) of zero bytes after. I don't know who and with what coder coded this file as it of course came from the internet.
Edit: The picture is 1356x1314px and 976 kB
It seems I need a mp3 cleaner tool. While skipping a kilobyte of zeros is fast enough, searching a header 200 kB after the end of ID3 - someone inserted over 200 kB of zeros there - byte by byte is too long.
0.32
File name length limit raised from 39 to 78 chars
Zeros after id3tag now skipped much faster.
This version is now much more usable for mp3 files playing.
The zip contains changed player.bas and a binary, the rest is unchanged from 0.31
Directories needs rescanning (R key) after upgrade from previous versions. I have to add a version tag to directory cache files to avoid this.
Comments
Oh yea, that's a kinda a missing feature. PS/2 keyboards have auto-repeat internally, USB only reports currently held keys. OTOH, you can easily implement it:
The initial wait and repeat times being different is important to making it feel good.
Yes, I have this already done for a Pi so I only have to copy this here. The mouse double click is already implemented in the player.
Also, I see your SPCcog is still at V1.0. Update to 1.2 to fix some sample clipping/precision issues (mostly in modern modules)
Now I have to find where I hacked SPCCog to get oscilloscope data to be displayed...
There is a standard problem with the spccog : UTF16
Edit: converted, hacked, upgraded, now the player uses 1.2. This version has several lines added that sends the data to the prop2play oscilloscope. However play timer doesn't run, I have to find why. And enable VU bars
Oh yeah, the old usual. Just convert to UTF-8, it will be fine.
Allegedly prop tool's getting deprecated, maybe we can finally have UTF-8 as the standard.
EDIT: Weird tangent: the Tortoise Git diff GUI can compare files that are encoded differently. How interesting.
030a
Upgraded SPCcog to 1.2
Added keyboard autorepeat - important for keys 7,8 (sample rate control by keeping the key pressed)
Several bugs fixed
Fixed too long timeout for mouse double click, that was very annoying. There is only changed .bas and binary in the zip
Preliminary mp3 support. To make a proper mp3 support I still have to do a lot of things, but now it plays, although the samplig frequency is not yet adjusted as it should be.
The binary uses hdmi at p0, av at p8, usb at p16
This binary has heap size 16k instead of 8k. Mp3 files still play; reduced heap size made problems with displaying file lists
There are still a lot of bugs in mp3 related player code to fix.
And I have a problem now with very long file names that cannot open. As i can remember, there is a restriction somewhere in the player that has to be raised or removed, but now the palyer crashes while trying to open the file with too long file name.
Also, the Flexprop's LFN fails on the files that have non-standard (in this case Polish) letters in their names. It then escapes to a short file name with ~ in it.
But there are also a lot of possible garbage in mp3 files themselves.
The code that skips id3v2 based on its length field was not good enough for several mp3 files I am using to test the player. After the proper id3v2 there was a lot of zero bytes left in the file before the first mp3 frame in the file. (and these id3 tags can be gigantic.... the player surprised me with the text "tag detected, size=1.001705e+06")
So, the version I attached here, has an enhanced algorithm that if there in no mp3 frame header and also no ID3 tag, it searches for the first FFFx or FFEx in the file. It does it also after the id3v2 tag.
Edit: yes, I restricted the file name length in the player... 640 kB 38 characters should be enough for all.... That is not true for these mp3s.
A megabyte of tag? lol. Let me guess, cover art in too high resolution / quality?
It seems the picture is 500x485. Somewhere in the future maybe I will write a proper id3 decoder; now it only reads the length, then skips the tag only to find a (EDIT: hundreds of ) kilobyte(s) of zero bytes after. I don't know who and with what coder coded this file as it of course came from the internet.
Edit: The picture is 1356x1314px
and 976 kB
It seems I need a mp3 cleaner tool. While skipping a kilobyte of zeros is fast enough, searching a header 200 kB after the end of ID3 - someone inserted over 200 kB of zeros there - byte by byte is too long.
Another glitch.... These mp3s can have "," in their file names. Then the line
stops inputting on this "," and the result is the truncated filename... Input has to be replaced by get....
0.32
File name length limit raised from 39 to 78 chars
Zeros after id3tag now skipped much faster.
This version is now much more usable for mp3 files playing.
The zip contains changed player.bas and a binary, the rest is unchanged from 0.31
Directories needs rescanning (R key) after upgrade from previous versions. I have to add a version tag to directory cache files to avoid this.