This project aims to send executables and data to the PSX RAM via the command port.
- No modification of the BIOS or the PSX hardware is required.
- It does not pretend to compete with the serial cable, since it is very slow, but it does pretend to be an emergency cable.
- It is being developed in several phases. For emulation, vjoy and ahk vjoy libraries are required.
Warning: The final speed must be divided, possibly by 2, since using an intermediate buffer to pass data from the EXE to the ARDUINO (maximum 115200 bauds), and from the ARDUINO to the PSX, the final speed is lower.
For testing purposes, the demo1.exe file is in memory to be compared with the data reading per series. If any data does not match, it gives ERROR. If we pass another file in the GENFRAME, when comparing it will give error.
The Arduino code for the fake spi in the case of using a PSX to computer usb command converter, in the message you must put a 0xFF o similar in order to avoid error:
(Digital mode) 0xFF,0x41,0x5A,0xFF,0xFF
(Analog mode) 0x73,0x73,0x5A,0xFF,0x80,0x80,0x80,0xFF0xFF
In the real machine, you have to remove
- Arduino + transistor buffer + 4 button control.
- Speed 0 (50 ms 3 bits 60 bauds) 100% funcional (Test in real PSX)
- Speed 1 (25 ms 3 bits 120 bauds) 100% funcional (Test in real PSX)
- Arduino fake spi slave pad
- Speed 0 (50 ms 3 bits 60 bauds) 100% funcional (Test in real PSX)
- Speed 1 (25 ms 3 bits 120 bauds) 100% funcional (Test in real PSX)
- Speed 2 (50 ms 8 bits 160 bauds) 100% funcional (Test in real PSX)
- Speed 3 (25 ms 8 bits 320 bauds) 100% funcional (Test in real PSX)
- Speed 4 (50 ms 12 bits 240 bauds) Doesn't work
- Speed 5 (25 ms 12 bits 480 bauds) Doesn't work
- Speed 6 (50 ms 40 bits 800 bauds) Doesn't work
- Speed 7 (25 ms 40 bits 1600 bauds) Doesn't work
- Speed 8 (50 ms 16 bits 320 bauds) Analog mode 100% funcional (Test in real PSX)
- Speed 9 (25 ms 16 bits 640 bauds) Analog mode 100% funcional (Test in real PSX)
- Speed 10 (50 ms 32 bits 640 bauds) Analog mode 100% funcional (Test in real PSX)
- Speed 11 (25 ms 32 bits 1280 bauds) Analog mode 100% funcional (Test in real PSX)
- Speed 12 (50 ms 64 bits 1280 bauds) Custom msg PAD 100% funcional (Test in real PSX) (psyq and PSXSDSK)
- Speed 13 (25 ms 64 bits 2560 bauds) Custom msg PAD 100% funcional (Test in real PSX) (psyq and PSXSDSK)
- Speed 14 (50 ms 112 bits 2240 bauds) Custom msg PAD 100% funcional (Test in real PSX) (psyq)
- Speed 15 (25 ms 112 bits 4480 bauds) Custom msg PAD 100% funcional (Test in real PSX) (psyq)
- Speed 16 (50 ms 128 bits 2560 bauds) Custom msg PAD 100% funcional (Test in real PSX) (psyq)
- Speed 17 (25 ms 128 bits 5120 bauds) Custom msg PAD 100% funcional (Test in real PSX) (psyq)
- Speed 18 (50 ms 224 bits 4480 bauds) Custom msg PAD 100% funcional (Test in real PSX) (psyq)
- Speed 19 (25 ms 224 bits 8960 bauds) Custom msg PAD 100% funcional (Test in real PSX) (psyq)
- Speed 20 (50 ms 256 bits 5120 bauds) Custom msg PAD 100% funcional (Test in real PSX) (psyq)
- Speed 21 (25 ms 256 bits 10240 bauds) Custom msg PAD 100% funcional (Test in real PSX) (psyq)
- Speed 22 (50 ms 448 bits 8960 bauds) Custom msg PAD 100% funcional (Test in real PSX) (psyq)
- Speed 23 (25 ms 448 bits 17920 bauds) Custom msg PAD 100% funcional (Test in real PSX) (psyq)
- Speed 24 (50 ms 512 bits 10240 bauds) Custom msg PAD 100% funcional (Test in real PSX) (psyq)
- Speed 25 (25 ms 512 bits 20480 bauds) Custom msg PAD 100% funcional (Test in real PSX) (psyq)
Arduino Fake SPI
Code: Select all
Arduino PSX pin
9 PB1 - 9 ACK
10-SS - 6 ATT
11 MOSI - 2 COMMAND
12 MISO - 1 DATA
13 SCK - 7 CLOCK
- 4 GND
Historic
- 2020/08/21
- Created the tool PADREMOT.EXE, so you don't have to use the real control in the initial menu when you have to choose the speeds.
https://github.com/rpsubc8/serialpad/tr ... L/PADREMOT
I am with the CRC's in real time.
- Created the tool PADREMOT.EXE, so you don't have to use the real control in the initial menu when you have to choose the speeds.
- 2020/07/29
- The SEND utility has been created to send the frames to the ARDUINO through the FTDI USB port, from the DOSBOX. I've tested the speed 12 to 25, and everything's OK.
SEND
- The SEND utility has been created to send the frames to the ARDUINO through the FTDI USB port, from the DOSBOX. I've tested the speed 12 to 25, and everything's OK.
- 2020/07/26
- I have increased the communication speed with the ARDUINO UART to 1,000,000 bauds successfully, and I have made multiple attempts at modes to increase the speed, with buffers exclusively for the exact data and cycles. Everything has been correct, but I have not been able to increase the final overall speed of the system. So for now I am going to stop speed testing, and I am going to leave at most the speed mode 25, which leaves us 6419 bits per second, that is, about 802 bytes per second. This speed is the total end of the system. From now on, I'm going to finish the user tools.
All speeds are given in 25 ms and 50 ms, but I have written down all the modes that leave me up to 17 ms in NTSC in each test, which I will publish, so combinations can be made to increase final speeds in certain modes.
- I have increased the communication speed with the ARDUINO UART to 1,000,000 bauds successfully, and I have made multiple attempts at modes to increase the speed, with buffers exclusively for the exact data and cycles. Everything has been correct, but I have not been able to increase the final overall speed of the system. So for now I am going to stop speed testing, and I am going to leave at most the speed mode 25, which leaves us 6419 bits per second, that is, about 802 bytes per second. This speed is the total end of the system. From now on, I'm going to finish the user tools.
- 2020/07/25
- Fix bugs, fix speed 23.Transmission speeds higher than 20480 baud are problematic, given the memory consumption. A limit is therefore reached, which I am trying to solve, by sending data in binary mode. Let's remember, that they are being sent in nibbles and ASCII mode, for ease of testing.
- 2020/07/22
- Created new speed 20 and 21, allowing up to 10240 bauds, sending 256 bits.
Speed 22 and 23 error.
Created new speed 24 and 25, allowing up to 20480 bauds, sending 512 bits.
- Created new speed 20 and 21, allowing up to 10240 bauds, sending 256 bits.
- 2020/07/20
- Created new speed 18 and 19, allowing up to 8960 bauds, sending 224 packaged bits.
- 2020/07/19
- Created new speed 16 and 17, allowing up to 5120 bauds, sending 128 bits.
- 2020/07/18
- Created new speed 14 and 15, allowing up to 4480 bauds, sending 112 packaged bits.
- 2020/07/16
- Use of a custom message ported to psxsdk and also in psyq with timeout. Bit 7 is still a problem, but I'm still working on it as usual. I've created speed 12 and 13, which allows me up to 2560 bauds, but as I'm doing the tests, I'll be able to reach much more speed, with little complication.
- 2020/07/14
- Start migration to psxsdk and direct access to PADSIO for higher speeds (bye bye psyq).
- 2020/07/10
- New speed modes (10 and 11) in analog mode allowing from 1280 to 1856 bauds.
- 2020/07/09
- Working with the analog mode 0x73, 0x5A, and sending nibbles to avoid the failure of sending bytes on the sticks, I have achieved 928 bauds at 58 fps (speed 8 and 9), twice as much as mode 3. I will be uploading videos throughout these days.
- 2020/07/07
- The analogical mode 0x73,0x5A and 0x53,0x5A, that in principle would allow us to multiply x5 the speed, being able to send 4 bytes of the sitcks and 2 bytes of buttons, although by SPI in converter of PSX to PC it works, in real console, it comes to work by periods of time not constant. Let's remember that Arduino's SPI is not a 100% PSX compatible SPI mode 3. So I'm thinking about another way of communication, which although it's slower, it works. Specifically on the sticks if you send nibbles, it works. Until the highest bit in the top of each byte of the stick is activated, it doesn't get out of sync. Using our imagination, we can achieve speeds of x2 and x3.
Obviously, the higher the speed, the more difficult it becomes, especially when trying to emulate a multitap or use two command ports. We will see how far an ATMEGA328 can take us by falsifying the protocol.
- The analogical mode 0x73,0x5A and 0x53,0x5A, that in principle would allow us to multiply x5 the speed, being able to send 4 bytes of the sitcks and 2 bytes of buttons, although by SPI in converter of PSX to PC it works, in real console, it comes to work by periods of time not constant. Let's remember that Arduino's SPI is not a 100% PSX compatible SPI mode 3. So I'm thinking about another way of communication, which although it's slower, it works. Specifically on the sticks if you send nibbles, it works. Until the highest bit in the top of each byte of the stick is activated, it doesn't get out of sync. Using our imagination, we can achieve speeds of x2 and x3.
- 2020/07/03
- I'm going for a very good job. I've already got speed 2 and 3 working on the fake SPI on the Real PSX, and not only that, but I've got in NTSC mode 58 fps (17 ms) a speed of 464 bauds.
In the afternoon I'll upload test videos.
- I'm going for a very good job. I've already got speed 2 and 3 working on the fake SPI on the Real PSX, and not only that, but I've got in NTSC mode 58 fps (17 ms) a speed of 464 bauds.
- 2020/07/02
- I have found a way to make the 0 and 1 speed work with the fake SPI, that is, it behaves as if it were the 4 buttons but with the fake SPI on a real machine.
- 2020/06/29
- The 4-button version with 50 ms and 25 ms is tested and finished in both emulator and real machine. With 25 ms, 120 bauds are reached in real machine. Tests have been made to reduce to 20 ms, getting 150 bauds. Since the version for 4 buttons is finished, I pass to leave more usable the functions and later to the fake spi.
- 2020/06/27
- I change the control reading with the PadRead test to Direct Port communication, so that it works with the fake spi.
The fake spi with arduino is very unstable, so I leave the high speeds temporarily parked until I leave the 4-button mode stable, which has no faults. The fake spi is not a real 100% spi psx, so sometimes it is necessary to add a transistor to the MISO line and the ACK to achieve a physically stable line. Even if we achieve this, from time to time there are losses of datagrams or bits, which is solved by optimizing the speed and resending. These losses are not the same in a PSX to usb command converter, nor in a real PSX. Therefore, we find solutions that work in the usb converter, but in real is impossible and vice versa. A specific case is the flick when the bit 0 (SELECT button) of the first and second byte is activated, in real machine. This is solved by setting the whole byte to 0x00. Since these are temporary solutions, it is better to attack other fronts.
- I change the control reading with the PadRead test to Direct Port communication, so that it works with the fake spi.
- 2020/06/25
- In tests with the analog control, the speed increase is x5 (1600 bauds). Unfortunately, in emulator, there is a problem of data re-injected by fake SPI (0x73,0x5A,0xFF,0x80,0x80,0x80,0x80,0xFF) to the control and scale translation, which prevents the exact reading of the sent bytes (deviation of 1 or 4 units), given that the analog data is translated to the gamepad values in windows and this in the emulator, with scaling. In real machine, there is no such problem, so I have to see how it leaves an intermediate emulation environment. It is reaching the point of no return of not being able to continue with the emulation part, and directly only develop in real machine. Let it end up sending 1 nibble encapsulated in 1 analog byte (dividing by 16), and thus send 2 bytes in analog mode in emulator.Simulation and emulation is more than a solution for development, it is a problem.
- 2020/06/21
- To guarantee results, any flaw I find, I leave it aside, and jump to a less optimal but effective solution. This way, I already have the 1 byte sending with 9 buttons in the fake SPI mode. I send to the arduino 2 bytes with the lower part of the buttons (compatible with emulator no$psx without the direction buttons). You have to leave a wait of at least 1050 ms ((42/2)x 50 ms) when sending with the RealTerm on each line. This is the 2 speed mode:
The speed is 160 bps (20 bytes per second).
Code: Select all
genframe demo1.exe frame.txt 80010000 2 0
I have also created the speed mode 3, which allows 320 bauds (sending 20 KB more or less 8 minutes). You have to leave a wait of at least 1050 ms ((84/2)x 25 ms) when sending with the RealTerm on each lineCode: Select all
genframe demo1.exe frame.txt 80010000 3 0
- To guarantee results, any flaw I find, I leave it aside, and jump to a less optimal but effective solution. This way, I already have the 1 byte sending with 9 buttons in the fake SPI mode. I send to the arduino 2 bytes with the lower part of the buttons (compatible with emulator no$psx without the direction buttons). You have to leave a wait of at least 1050 ms ((42/2)x 50 ms) when sending with the RealTerm on each line. This is the 2 speed mode:
- 2020/06/18
- The 4-button version with arduino with flag (50 ms send 3 bits) is 100% functional.
The 4-button version with arduino without flag (25 ms send 3 bits) works incorrectly. I have tried several options in order not to lose the synchronism, but I can't find a solution, so for the moment I leave the version without flag aside, since I am losing a lot of time.
I'm not going to leave a keyboard or joystick simulation version with the autohotkey or simulation, since a lot of time is lost in leaving something comfortable to the user, and at the end you have to make development versions for simulation and real. I don't have time, so I work directly and the emulations are adapted to my specific cases.
I have added a compression option to remove 1920 bytes in the 2048 header bytes, saving transmission time.
I start with the arduino SPI fake (14 buttons) to achieve more speed, since the basic version works, and you already have the pillars.
- The 4-button version with arduino with flag (50 ms send 3 bits) is 100% functional.
- 2020/06/15
- Finished the tool to generate frames in PASCAL under DosBOX x86 (TP 7) and for Windows32 (FreePascal). These frames are used with RealTerm.https://github.com/rpsubc8/serialpad/tree/master/PASCAL
- 2020/06/10
- Created an intermediate tool to generate text mode frames that can be sent automatically with the RealTerm program. You have to reduce the speed in each character and new line sending in order not to saturate the 64 bytes buffer of ARDUINO.
- Created a prototype in C-- and Turbo Pascal 7 to send data to Arduino (9600 baud) through the serial port under DOSBOX with the port configured as directserial realport. Tests have been done, and everything is OK. This way, it works not only in Windows, but also in Android and other platforms that support the serial port and DOSBOX.
- 2020/06/08
- usb communication arduino nano series 4 button headrest control OK
- A text mode file is generated with all the frames in order to send with the Arduino serial monitor or the SerialSend from the command line at 9600 baud.
- Tests 2020/06/07
- An EXE created with Blade Libs + MIPSGCC + Jum SDKpsyq OK has been sent
- An EXE created with psyq OK has been sent
- An exe compressed with bytekiller OK has been sent
- Emulator simulated sending 2 PADS (14 digital buttons) 20428 bytes 425 seconds, 384 bauds.