10/10/2021 at 23:57 •
10/02/2021 at 20:45 •
New #BlueRetro update v1.0 is available!
- Add support for BLE generic HID gamepad, mouse & keyboard
- Add support for Xbox Series X|S controller
- Add workaround for PowerA switch controller stopping report after inquiry stop
- Improve Generic HID gamepad default mapping
- Introduce default mapping quirks for inverted and rotated face buttons (8bitdo, PowerA GC)
- Add version string attribute (Displayed in OTA page logs)
- 07/07/2021 at 00:09 • 0 comments
06/24/2021 at 21:09 •
I redesigned how the LED and BOOT switch are used, holding it 3 sec start inquiry scan (and LED start to pulse), short press while inquiry scan is on cancel it (and LED stop glowing), one short press outside of inquiry scan kick out all controllers as before. The LED being solid on still indicate that an error occurred. Holding the switch 10 sec will factory reset the adapter to default config and clear the Bluetooth keys.
See v0.18 release.
06/06/2021 at 14:43 •
I wrote my own testing application with JagStudio this time around to test BlueRetro with my GameDrive (especially the 6D controller support). Source and ROM available on GitHub.
04/30/2021 at 13:08 •
04/20/2021 at 17:15 •
Hackaday.io is nice but the more content I add the harder it is to find the older content. You got to click view all project logs and then click next page forever.
Also while it's possible to comment on the log entry, that feature looks to be universally not used here. Also you can't like a log.
So I'm seriously thinking about posting next status update on the GitHub discussions forum: https://github.com/darthcloud/BlueRetro/discussions
This way everything would be centralized in one place. The reply form is more obvious and you can like/love/etc.
Also I'm thinking of moving a few of the documentation logs to a GitHub wiki page.
What you guys think?
04/12/2021 at 17:22 •
I added CD-i support with version v0.15! Regular pad, mouse & keyboards (K, X & T type) are supported. Any mix of devices is supported for up to 2 players! Refer to wiki for cable schematic and config documentation.
The low level protocol is UART based. It is well documented in various specifications but the most up-to-date one is contained in Chapter 9. Input devices of the Technical Documentation for CDI 605 / 605T Users that can be found on ICDIA.
The spec defines RTS and RXD pin as standard RS-232 levels:
- logical 1: -15V < signal level < +0.8V
- logical 0: +2.4V < signal level < + 15V
But from what I saw in various schematics the logical 1 level is always 0V and the logical 0 is 5V. So when interfacing with a CD-i interface level shifters are enough (no need for MAX232) as long the UART is configured to be inverted.
Pointing devices like gamepad and mouse defined speed of 1200 & 9600 baud in the original spec but only 1200 devices ever got released. Newer CD-i players dropped 9600 support on the front ports and the latest spec actually removed 9600 as a possible baud rate for mouse and gamepad.
For mouse, gamepad & type 'T' keyboard data signaling is 7 bits with 2 stop bits LSB first. For type 'K' & 'X' keyboards signaling is 8 bits with 1 stop bit LSB first.
Unlike most other game system the CD-i inputs are not polled. As long the RTS line is released devices are free to send data when state change.
Devices are identified once at boot time by holding the RTS line low. Once RTS line is released devices are required to send their 1 byte identification followed by their initial status data.
This was a problem for BlueRetro as devices per CD-i spec are required to answer the ID request within 500 ms. However BlueRetro take around 700 ms to read its configuration at boot. To work around this BlueRetro need to be powered externally and powered before powering the CD-i. This give the extra time required to load the config and to be ready to answer the ID request.
Controller & Mouse
'K' & 'X' type keyboards
'T' type keyboard
Later CD-i model like my CD-i 450 only had a single physical front port including 2 serial port. Only the secondary port was compatible with 8 bits UART configuration that keyboards (K & X) and modem required. This posed a problem for CD online application as this made impossible to use the previous keyboard simultaneously with the modem. To answer this issue Philips defined the 'T' keyboard spec that piggy back on the tablet 'T' ID and redefine the data format to include the same data as the 'K' type keyboard.
04/02/2021 at 20:52 •
The low level protocol is pretty much like SPI mode 0 for clock and data line. You got the /LATCH line that can be inverted to be use as a CS. An /OE signal can mute the output from the peripheral when high. The console poll the peripherals 5 times in a row every frame. This look like how PC Engine controllers are polled as well for the multitap. Maybe a multitap was plan for the PC-FX as well?
Data line is inverted and LSB is sent first. Clock may sometimes cycle while LATCH is held low, these cycle must be ignored.
The two controllers are often polled simultaneously.
Getting the ESP32 SPI timing was a bit tricky, In my mind this should be SPI Mode 2 but somehow that was very unreliable. Using Mode 0 timing is rock solid however.
RX: FFFFFF0F (LSB first) ││││ ├┘ ││││ └ ID? │││└ Left, Down, Right, Up ││└ 1, Mode2, 1, Mode1 │└ IV, III, II, I └ Run, Select, VI, V
RX: FFFFFF2F (LSB first) ├┘├┘ │├┘ │ │ │└ ID? │ │ └ Buttons (1, 1, Right, Left) │ └ X axis (8 bits) (Left: -, Right: +, Two's complement, inverted, LSB first) └ Y axis (8 bits) (Up: -, Down: +, Two's complement, inverted, LSB first)
03/29/2021 at 00:45 •
I just added 3DO support with version v0.13! Regular pad, flightstick and mouse are supported. Any mix of devices is supported for up to 8 players! Refer to wiki for cable schematic and config documentation.
The 3DO interface is quite unique as 8 players are supported via a single port! 3DO peripherals for the most part include an input port on them allowing to daisy-chain controller back to back. No extra port on console or multitap are required!
The low level protocol is pretty much like SPI mode 3. You got the CLK, a data output and a data input. Base on my test the console data output is not used by the controller. The big difference with SPI is that there is no chip select signal. Frame start is signaled by holding the CLK line high for 500 us.
Data from daisy-chained peripherals are simply appended to the transmission back to back, first controller transmitted first. 3DO BIOS and some games will always query for 200 bytes of data. Some games only query what they need. Extra read data is always 0xFF.
This is one of the easiest systems to implement in BlueRetro. The only challenge was to generate a chip select signal for the ESP32 SPI hardware. The ESP32 SPI slave hardware is unfortunately not very flexible. I loop back my generated CS GPIO output into the ESP32 SPI CS input.
RX: 8000 ││││ │││└ R, L , 0, 0 ││└ B, C, P, X │└ Up, Right, Left, A └ 8, 0, 0, Down
┌ Y axis (10 bits) (Up: -, Down: +, Two's complement) ┌┴┐ RX: 49000000 ├┘│ └┬┘ │ │ └ X axis (10 bits) (Left: -, Right: +, Two's complement) │ └ Buttons (Left, Middle, Right, 0) └ ID
I didn't RE this one my self, base on:
┌ X axis (10 bits) (Left: -, Right: +, Two's complement) ┌┴┐ RX: 017B08802008020000 └┬───┘ └┬┘└┬┘│││ └ IDs? │ │ ││└ P, X, L, R │ │ │└ Up, Down, Right, Left │ │ └ Trigger, A, B, C │ └ Z axis (10 bits) (Two's complement) └ Y axis (10 bits) (Up: -, Down: +, Two's complement)