PAD Serial

Start a work log and update it occasionally with your projects progress
ackerman
Curious PSXDEV User
Curious PSXDEV User
Posts: 29
Joined: Aug 21, 2019

PAD Serial

Post by ackerman » June 7th, 2020, 8:03 pm

Image

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.
All you need is an Arduino UNO, NANO.
 ! Message from: ackerman
It is very important to have the Shendo padtest to check for sending of button presses and to see strange behaviour. You can also use the example anlgctrl that comes with the psyq. Still, we will need to make our own testing routines, since many anomalies arise.

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

40%
The project is divided into 2 sub-projects:
  • 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 Transistor Buffer 4 buttons
Image

Arduino Fake SPI
Image

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
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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:

      Code: Select all

       genframe demo1.exe frame.txt 80010000 2 0
      
      The speed is 160 bps (20 bytes per second).
      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 line

      Code: Select all

       genframe demo1.exe frame.txt 80010000 3 0
      
  • 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.
  • 2020/06/15
  • 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.
Last edited by ackerman on August 21st, 2020, 9:06 pm, edited 59 times in total.

ackerman
Curious PSXDEV User
Curious PSXDEV User
Posts: 29
Joined: Aug 21, 2019

Post by ackerman » June 13th, 2020, 5:26 am

Image
Successfully tested 20 KB (20428 bytes)of PsEXE, both with the RealTerm tool and with our own tool in Turbo Pascal 7 from DosBOX. The sending is extremely slow, using 4 buttons on the control (53 bauds), but it is safe, 100% without loss of synchronicity.
A text file is generated, which contains the sending of 7 bytes per line via usb serial port (9600 bauds).
*
C9BF99888988888888988
8A9BA9DD88B98C8D898B9
D89888888888888888888
888888CA89FBFB888A888
The first 7 bytes contain the header, with the size of the PsEXE in bytes and the memory address.

ackerman
Curious PSXDEV User
Curious PSXDEV User
Posts: 29
Joined: Aug 21, 2019

Post by ackerman » July 5th, 2020, 3:25 am

Here is the first test of mode 3 (464 bauds) in NTSC mode at 58 fps. It takes about 5 minutes to load the 20428 bytes of the compressed psExe executable.

https://www.youtube.com/watch?v=2mlobLj7lo4

ackerman
Curious PSXDEV User
Curious PSXDEV User
Posts: 29
Joined: Aug 21, 2019

Post by ackerman » July 9th, 2020, 8:51 pm

I set a new record with the ARDUINO (fake spi mode), namely 928 bauds at 58 fps NTSC. I used the analog mode sending 16 bits. In each stick, instead of sending one byte, I send 1 nibble, since there is overlap in the communications. As I have commented, all these solutions, prevent us to achieve the maximum speed, but that does not prevent that we cannot take out utility from it using our imagination.

I will upload test videos (20428 bytes sent in 3 minutes and 12 seconds).

From now on, I will make several separate programs for Arduino of each speed, since although the code is simple, it is starting to grow with many combinations, and since repetitive code routines are required for the exact times, better to have separate codes so as not to mess up (analog mode, digital mode, speeds, flanks). The user will compile the one he needs according to the speed he wants to try.
When you add another port and the multitap emulation, if it keeps growing like this, it will be very difficult to maintain.

In the meantime, I also continue with the EXE loader from memory cards. In 2008, I created a loader, which allowed me to load EXE's that were larger than the capacity of a memory (120 KB). The PSX asked us to change each card as if it were a floppy disk. I had developed it to walk around at home, so we had to change code on the fly to use it. I'm modifying it so that a normal user can use it. You can even use it from ANDROID.

https://github.com/rpsubc8/psxmcloader

ackerman
Curious PSXDEV User
Curious PSXDEV User
Posts: 29
Joined: Aug 21, 2019

Post by ackerman » July 10th, 2020, 9:02 pm

And another new record.
I got 1856 baud at 58 fps with speed mode 11. I have given it a twist, and I have managed to pack in the 4 byte analog mode. It's quite confusing to explain, but basically, as the bit 7 of the sticks gives problems, I've left it unused, allowing to use the 3 bits of the high part. Using also the 4 bits of the lower part of the buttons, as well as the 4 lower parts of each stick, gives us 32 usable bits, that is, 4 bytes.

Code: Select all

 (7 bits x 4 sticks ) + (4 bits buttons) = 32 bits
I have been adjusting to use 60 fps, but sooner or later it gets out of sync, so for now, the maximum is 58 fps.

On the real PSX I manage to send 20480 bytes in 1 minute and 36 seconds. (1856 bauds)

ackerman
Curious PSXDEV User
Curious PSXDEV User
Posts: 29
Joined: Aug 21, 2019

Post by ackerman » July 12th, 2020, 6:32 am


ackerman
Curious PSXDEV User
Curious PSXDEV User
Posts: 29
Joined: Aug 21, 2019

Post by ackerman » July 15th, 2020, 1:51 am

These days I've been having fun like a kid with new toys.
I've removed the check against the memory executable, so I can load whatever I want for testing (I haven't uploaded it to the repository).

I've been testing all the homebrew and demos from the demoscene with the cable at 1856 bauds.
Since it loads to memory, I have tested and it works with .psx files, the .exe compressed with Bytekiller, Crunchykiller, upx, blade libraries, psxsdk, psyq, etc...
Although it can be slow for demos from 200 KB onwards, thanks to the compressors, like the Bytekiller, you can leave the Paradox intro ( AVH's First PDX-Intro) from 159744 bytes to 69812 bytes, which means a loading time of 5 or 6 minutes.

Image
http://www.pouet.net/prod.php?which=48715

Although I've been testing to emulate a multitap to achieve more speed, I think it's time, to leave this path, since as the PSX BIOS overwrites the PAD messaging, also rare messages arrive, and frames are desynchronized. The effort applied regarding the speed improvement, doesn't compensate. Let's remember, that for the moment, we already have, even if it's at 1856 bauds, a cable, that for intros and small projects, serves as a spare.

To achieve more speed, the time has come to migrate everything to PSXSDK for direct access to PADSIO and messaging.
I'm creating new messages, and testing with the PSXSDK, and so far they're going well.
We'll see how fast we can go.

ackerman
Curious PSXDEV User
Curious PSXDEV User
Posts: 29
Joined: Aug 21, 2019

Post by ackerman » July 16th, 2020, 8:38 pm

I throw a question to the forum, if you can help me.

In the psxsdk to send a custom message, it works perfectly:

Code: Select all

void SendData(int pad_n, unsigned char *in, unsigned char *out, int len)
{
	int x;
	int y;
	int i;	
	PADSIO_MODE(0) = 0x0D;
	PADSIO_BAUD(0) = 0x88;	
	if(pad_n == 1) PADSIO_CTRL(0) = 0x3003; else PADSIO_CTRL(0) = 0x1003;		
	for(y=0;y<400;y++);	/*Slight delay before first transmission*/
	for(x = 0; x < len; x++)
	{
		/*Wait for TX ready*/
		while((PADSIO_STATUS(0) & 4) < 1);
		
		PADSIO_DATA(0) = *in;
		in++;

		/*Read RX status flag*/
		while((PADSIO_STATUS(0) & 2) < 1);
		
		*out = PADSIO_DATA(0);
		out++;
	}	
	PADSIO_CTRL(0) = 0;
}
However, in the psyq, it doesn't work.
I've managed to make it work, but by setting a timeout:

Code: Select all

void SendData(int pad_n, unsigned char *in, unsigned char *out, int len)
{	int x;
	int y;
	int i=0;
	int j=0;
	unsigned int cont_timeout=0;
	
	PADSIO_MODE(0) = 0x0D;
	PADSIO_BAUD(0) = 0x88;
	
	if(pad_n == 1) PADSIO_CTRL(0) = 0x3003; else PADSIO_CTRL(0) = 0x1003;		
	for(y=0;y<400;y++);	//Slight delay before first transmission
	for(x = 0; x < len; x++)
	{		
		while((PADSIO_STATUS(0) & 4) == 0); //Wait for TX ready		
		PADSIO_DATA(0) = in[i++];		

		//Read RX status flag
		cont_timeout=0;
		while(((PADSIO_STATUS(0) & 2) == 0)&&(cont_timeout<3584)) cont_timeout++;				
		out[j++] = PADSIO_DATA(0);		
	}		
    //sprintf (gb_cadLog,"Test %04x %04x %04x %08x",PADSIO_BAUD(0),PADSIO_MODE(0),PADSIO_CTRL(0),PADSIO_STATUS(0));
	PADSIO_CTRL(0) = 0;
}
Bit 1 of the JOY_STAT (0x1F801044) RX FIFO Not Empty , is never set. The timeout in particular I have put it from 3584, otherwise, it gives problems.

To clarify, I've removed all access to the memory cards, and pads. Only the custom message is sent. I have started listening to the SPI (logic analyzer) port, and I only send and receive the data I send.

Why is that?

ackerman
Curious PSXDEV User
Curious PSXDEV User
Posts: 29
Joined: Aug 21, 2019

Post by ackerman » July 18th, 2020, 10:18 pm

New record, 4480 bauds (NTSC 25 ms 40 fps)

I also got it to work at 6222 bauds NTSC(18 ms 55 fps).

ackerman
Curious PSXDEV User
Curious PSXDEV User
Posts: 29
Joined: Aug 21, 2019

Post by ackerman » July 20th, 2020, 9:04 pm

New record, 11200 bauds at 50 fps.
Goodbye siocons at 9600 baud. :lol: :lol:

fulas
Curious PSXDEV User
Curious PSXDEV User
Posts: 10
Joined: Jul 05, 2017

Post by fulas » July 21st, 2020, 7:39 am

Wow , it seem that you are having a hard work, congratulation sir, nice to see you around here. Salu2 amigo.

ackerman
Curious PSXDEV User
Curious PSXDEV User
Posts: 29
Joined: Aug 21, 2019

Post by ackerman » July 21st, 2020, 11:17 pm

Salu2 fulasypescados. Que se note que somos Españoles. Somos legion. :D :D :D :D :D

In the end, after many, many, many years, I set out, as I told you, to finish projects I had started from PSX. The truth is that what takes more, are the field tests, because I begin to make tests, and the results, sometimes are good and sometimes bad, and it is necessary to make changes. There's still a lot to do to make it comfortable for the end user, but I'm leaving the code so that anyone can do what they want and improve it.

I think it was about time to have a cable to be able to program a PSX in a comfortable way without even having to solder and with components to walk around the house, like an ARDUINO.

ackerman
Curious PSXDEV User
Curious PSXDEV User
Posts: 29
Joined: Aug 21, 2019

Post by ackerman » July 23rd, 2020, 4:19 am

PARADOX Intro Load Demo (69812 bytes) with speed 25, at 20480 baud:

https://www.youtube.com/watch?v=prJoN1dYN0M

ackerman
Curious PSXDEV User
Curious PSXDEV User
Posts: 29
Joined: Aug 21, 2019

Post by ackerman » July 30th, 2020, 2:12 am

Bye bye RealTerm and Windows.
I have finished the SEND utility, which is similar in operation to the REALTERM, but working in DOSBOX.
It is required to edit the DOSBOX configuration file.

Code: Select all

serial1=directserial realport:com21

Code: Select all

SEND frame.txt 1050 115200

ackerman
Curious PSXDEV User
Curious PSXDEV User
Posts: 29
Joined: Aug 21, 2019

Post by ackerman » August 1st, 2020, 3:59 am

I am creating a charger for speeds 12 to 25, selectable from a PAD controller connected to port 1 or 2. I also allow to choose the ARDUINO connected to port 1 and 2.
Since you cannot have both the control and the ARDUINO at the same time, by sharing SPI, when selecting the speed, you can detect the disconnection of the control, or you can give it 10 seconds to disconnect.
It is also possible to restart the charger by jumping to the PSXSerial, or restart the program.
Image
This charger will serve as a test to see which speed is the most suitable, and then a version with the specified speed will be recompiled.

ackerman
Curious PSXDEV User
Curious PSXDEV User
Posts: 29
Joined: Aug 21, 2019

Post by ackerman » August 5th, 2020, 11:05 pm

Image
https://www.youtube.com/watch?v=Viej-9QA1Ro

Speed test 25, sending multiple files, pqbload tool style, with TIM, BGD, CEL and EXE
Arduino connected to port 2.
Command connected to port 1.
Sending from DOSBOX, arduino mute (STOP option).
Command disconnection detection.

ackerman
Curious PSXDEV User
Curious PSXDEV User
Posts: 29
Joined: Aug 21, 2019

Post by ackerman » August 21st, 2020, 9:09 pm

Image
https://www.youtube.com/watch?v=1j3ar96UkrU

You no longer need a remote control to select speeds. In speed mode 24 and 25 of ARDUINO I have added the commands 33 and 34 to be able to act as a digital control or as a custom.
Muting the ARDUINO is allowed so as not to interfere.
From the DOSBOX remapping to COM1, it is allowed to press the basic buttons. Not all the buttons have been set, only the ones I need.

ackerman
Curious PSXDEV User
Curious PSXDEV User
Posts: 29
Joined: Aug 21, 2019

Post by ackerman » October 24th, 2022, 1:14 am

Sorry for the delay in writing, but there is little time to spare.
So far the main problem we had in testing was the speed of the serial port, in particular the input, especially on an arduino nano atmega328.
This problem is easily solved by doing without it, i.e. storing the PSXEXE in the arduino's flash and sending it.

[youtube]https://www.youtube.com/watch?v=xqR8o6ID_J8[/youtube]
https://www.youtube.com/watch?v=xqR8o6ID_J8
  • 00:00:17 - Hitmen psxserial load.
  • 00:00:23 - Padsioup charger that uses the command port to receive data.
  • 00:00:32 - Self-selection of speed
  • 00:00:45 - Loading FIRE.EXE
The test was carried out at 20480 bps, i.e. 2560 bytes/s or 2.5 KB/s.
The FIRE.EXE has been sent compressed with the UPX in 16384 bytes.
In the 45th second the EXE is sent and ends in the 52nd second, i.e. 7 seconds.

With a simple atmega328 we can program in PSX. This test is ideal for making small intros.
Higher speeds can be achieved.

ackerman
Curious PSXDEV User
Curious PSXDEV User
Posts: 29
Joined: Aug 21, 2019

Post by ackerman » October 27th, 2022, 3:38 am

Test at 40960 bps, 5120 bytes/s, 5 KB/s

[youtube]https://www.youtube.com/watch?v=dSjpWYAxPPk[/youtube]
https://www.youtube.com/watch?v=dSjpWYAxPPk

00:00:02 - Automatic speed selection
00:00:05 - 10 Seconds wait to remove the controller from port 1 if connected
00:00:16 - Start loading of the 16384 bytes
00:00:20 - End of the 16384 bytes loading

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 534
Joined: Nov 12, 2012
Contact:

Post by nocash » October 29th, 2022, 4:15 am

Set your goal a bit higher. 2Mbyte/s should work in theory, and at least 100Kbyte/s should probably work without problems.

Or is there some hardware issue that prevents higher speeds? I am sure that could be fixed by adding some resistors or diodes in the console or in the cables.

And why do you use a 10 seconds transfer delay??? If the (second?) controller disturbs the transfer, couldn't you just detect if it's disconnected, and then start without delay?

Uh, and what is that drawing with L1,L2,R1,R2 buttons about? I hope you don't put your data into that 4bit slot? You can simply transfer a continous bitstream (except the first byte; which is reserved for selecting whether the data goes to the joypad, the memory card, or to your cable).

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests