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.
Fixed several bugs and changed the resolution to 1024x600. Several more pixels made a place to display for example long mp3 file names (to do, now they are simply empty)
Edit: a modified video driver added. The rest of the code base is unchanged from the file at the post #128
There was a GUS mentioned in a console emulation topic.
As this is not related to this topic, let's continue here.
I found a .pat file format description:
The GF1 Patch files are multipart sound files for the Gravis Ultrasound
sound card to emulate MIDI sounds in high quality. Each Patch can consist
of many samples (for example, a string ensemble consists of Violin, Viola,
Cello, Bass) which are played depending on the note to play. A patch can also
contain a part to be played before the loop and a part to be played after
the tone has been released.
OFFSET Count TYPE Description
0000h 12 char ID='GF1PATCH110'
000Ch 10 char Manufacturer ID
0018h 60 char Description of the contained Instruments
or copyright of manufacturer.
0054h 1 byte Number of instruments in this patch
0055h 1 byte Number of voices for sample
0056h 1 byte Number of output channels
(1=mono,2=stereo)
0057h 1 word Number of waveforms
0059h 1 word Master volume for all samples
005Bh 1 dword Size of the following data
0060h 36 byte reserved
Following this header, the instruments with their headers follow.
An instrument header contains the name and other data about one
instrument contained within the patch.
OFFSET Count TYPE Description
0000h 1 word Instrument number. ?Maybe the MIDI instrument
number?. In the Gravis patches, this is 0, in
other patches, I found random values.
0002h 16 char ASCII name of the instrument.
0012h 1 dword Size of the whole instrument in bytes.
0016h 1 byte Layers. Needed for whatever.
0017h 40 byte reserved
About the patch, I don't know anything. Maybe somebody could enlighten me.
Each patch record has the following format :
OFFSET Count TYPE Description
0000h 7 char Wave file name
0007h 1 byte Fractions
0008h 1 dword Wave size.
Size of the wave digital data
000Ch 1 dword Start of wave loop
0010h 1 dword End of wave loop
0012h 1 word Sample rate of the wave
0014h 1 word Minimum frequency to play the wave
0016h 1 word Maximum frequency to play the wave
0018h 1 dword Original sample rate of the wave data
001Ch 1 int Fine tune value for the wave
001Eh 1 byte Stereo balance, values unknown**
001Fh 6 byte Filter envelope rate
0025h 6 byte Filter envelope offse
002Bh 1 byte Tremolo sweep
002Ch 1 byte Tremolo rate
002Dh 1 byte Tremolo depth
002Fh 1 byte Vibrato sweep
0030h 1 byte Vibrato rate
0031h 1 byte Vibrato depth
0032h 1 byte Wave data, bitmapped
0 - 8/16 bit wave data
1 - signed/unsigned data
2 - de/enable looping
3 - no/has bidirectional looping
4 - loop forward/backward
5 - Turn envelope sustaining off/on
6 - Dis/Enable filter envelope
7 - reserved
0033h 1 int Frequency scale, whatever that means
0035h 1 word Frequency scale factor
0037h 36 byte Reserved
However it seems to be flawed and lacks detailed informations.
I made a simple tool to decode the .pat file using this format and there is garbage generated. I managed to "repair" this, changing offsets, etc, so now I can find proper wave data... etc.
Now, starting from "original sample rate".. it seems still to be garbage. And these 6 bytes filter data... what are these?
To use these patches for playing midi files, a lot of reverse engineereing has to be done... or maybe someone has an access to better .pat file format description?
In good, old times I had a GUS registers map/description. I don't know if I can find it now...
I managed to find this pdf. It seems to be from the original GUS SDK. There are GUS registers and .pat format described here. It seems the PDF is good enough to make a GUS emulation possible.
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.
Fixed several bugs and changed the resolution to 1024x600. Several more pixels made a place to display for example long mp3 file names (to do, now they are simply empty)
Edit: a modified video driver added. The rest of the code base is unchanged from the file at the post #128
There was a GUS mentioned in a console emulation topic.
As this is not related to this topic, let's continue here.
I found a .pat file format description:
The GF1 Patch files are multipart sound files for the Gravis Ultrasound sound card to emulate MIDI sounds in high quality. Each Patch can consist of many samples (for example, a string ensemble consists of Violin, Viola, Cello, Bass) which are played depending on the note to play. A patch can also contain a part to be played before the loop and a part to be played after the tone has been released. OFFSET Count TYPE Description 0000h 12 char ID='GF1PATCH110' 000Ch 10 char Manufacturer ID 0018h 60 char Description of the contained Instruments or copyright of manufacturer. 0054h 1 byte Number of instruments in this patch 0055h 1 byte Number of voices for sample 0056h 1 byte Number of output channels (1=mono,2=stereo) 0057h 1 word Number of waveforms 0059h 1 word Master volume for all samples 005Bh 1 dword Size of the following data 0060h 36 byte reserved Following this header, the instruments with their headers follow. An instrument header contains the name and other data about one instrument contained within the patch. OFFSET Count TYPE Description 0000h 1 word Instrument number. ?Maybe the MIDI instrument number?. In the Gravis patches, this is 0, in other patches, I found random values. 0002h 16 char ASCII name of the instrument. 0012h 1 dword Size of the whole instrument in bytes. 0016h 1 byte Layers. Needed for whatever. 0017h 40 byte reserved About the patch, I don't know anything. Maybe somebody could enlighten me. Each patch record has the following format : OFFSET Count TYPE Description 0000h 7 char Wave file name 0007h 1 byte Fractions 0008h 1 dword Wave size. Size of the wave digital data 000Ch 1 dword Start of wave loop 0010h 1 dword End of wave loop 0012h 1 word Sample rate of the wave 0014h 1 word Minimum frequency to play the wave 0016h 1 word Maximum frequency to play the wave 0018h 1 dword Original sample rate of the wave data 001Ch 1 int Fine tune value for the wave 001Eh 1 byte Stereo balance, values unknown** 001Fh 6 byte Filter envelope rate 0025h 6 byte Filter envelope offse 002Bh 1 byte Tremolo sweep 002Ch 1 byte Tremolo rate 002Dh 1 byte Tremolo depth 002Fh 1 byte Vibrato sweep 0030h 1 byte Vibrato rate 0031h 1 byte Vibrato depth 0032h 1 byte Wave data, bitmapped 0 - 8/16 bit wave data 1 - signed/unsigned data 2 - de/enable looping 3 - no/has bidirectional looping 4 - loop forward/backward 5 - Turn envelope sustaining off/on 6 - Dis/Enable filter envelope 7 - reserved 0033h 1 int Frequency scale, whatever that means 0035h 1 word Frequency scale factor 0037h 36 byte ReservedHowever it seems to be flawed and lacks detailed informations.
I made a simple tool to decode the .pat file using this format and there is garbage generated. I managed to "repair" this, changing offsets, etc, so now I can find proper wave data... etc.
Now, starting from "original sample rate".. it seems still to be garbage. And these 6 bytes filter data... what are these?
To use these patches for playing midi files, a lot of reverse engineereing has to be done... or maybe someone has an access to better .pat file format description?
In good, old times I had a GUS registers map/description. I don't know if I can find it now...
I managed to find this pdf. It seems to be from the original GUS SDK. There are GUS registers and .pat format described here. It seems the PDF is good enough to make a GUS emulation possible.
P2 GUS emulation sounds interesting. Could be useful for MIDI synthesizer projects with wavetable samples stored in external memory.