Page 23 of 29

Re: PSNee further development

Posted: October 25th, 2018, 10:04 am
by Kabcorp
Hi superg, thanks for your reply.
It says PSnee 7 is automatic for multiRegion right? If I read I can see only the PSone have to set the region?
Is debug via serial possible on ATtiny45/84?

Re: PSNee further development

Posted: October 25th, 2018, 10:16 am
by superg
Kabcorp wrote: October 25th, 2018, 10:04 am Hi superg, thanks for your reply.
It says PSnee 7 is automatic for multiRegion right? If I read I can see only the PSone have to set the region?
Is debug via serial possible on ATtiny45/84?
Yes, it can be automatic but just for debugging I suggest to force it. You can debug on ATtiny 45 by using physical IC pin 2. 84 is supported only in my branch for now.

EDIT: you can also try reducing hysteresis level to 10 and 7 respectively, maybe that will help:

Code: Select all

  if (hysteresis >= 14) {
    hysteresis = 11;
This is quicker than wiring up for serial debug.

Re: PSNee further development

Posted: October 25th, 2018, 10:23 am
by Kabcorp
superg wrote: October 25th, 2018, 10:16 am Yes, it can be automatic but just for debugging I suggest to force it. You can debug on ATtiny 45 by using physical IC pin 2. 84 is supported only in my branch for now.

EDIT: you can also try reducing hysteresis level to 10 and 7 respectively, maybe that will help:

Code: Select all

  if (hysteresis >= 14) {
    hysteresis = 11;
This is quicker than wiring up for serial debug.
Ok I'll debug the pin and trying to change this part of code.
But sorry I can't see how I can force the region :/

Re: PSNee further development

Posted: October 25th, 2018, 11:20 am
by Kabcorp
Maybe I'm doomed...
When I monitor the pin 2 (PB3) of the Tiny45, I can't get correct values from psnee baudrate (115200 or 500000)

Re: PSNee further development

Posted: October 25th, 2018, 12:05 pm
by superg
Kabcorp wrote: October 25th, 2018, 11:20 am Maybe I'm doomed...
When I monitor the pin 2 (PB3) of the Tiny45, I can't get correct values from psnee baudrate (115200 or 500000)
It should be 115200 for the software uart. What do you use to monitor?

Re: PSNee further development

Posted: October 25th, 2018, 9:52 pm
by Kabcorp
(with #define PSNEEDEBUG and #define USINGSOFTWARESERIAL)

I tryed with 4 softwares, all give me the same not correct symbols like the baudrate is wrong.
The wires are like this:

USB TTL TX -> ATtiny pin 2 (PD3)
USB TTL GND -> ATtiny pin 4 (GND)

Re: PSNee further development

Posted: October 25th, 2018, 10:09 pm
by Kabcorp
Ok.. by using mySerial.begin at 9600 instead of 115200 AND monitoring at 1200, I have my "START" debug print
the result:

START
m 0
340A88880AC0900AA1183C01
202804113C81001822010420
001080108E402C01200AC6C0
00A24202DAA880CA86180E00
906CA4058760041CC6101D07
34D8400E86504CC6E4130CC1
89311359430A8E81452201E5
206006E3A101A88C0D400405
A0220821748E388CB0D10A28
1078261F0011F2021822A602
4A280CCA410E1170060531AE
020D60000EF003F04001C000
003B000DC0803A000B80006E
011CC0011EC0000AC8000549
0014C0013CA1001CC0000CE8

Re: PSNee further development

Posted: October 25th, 2018, 11:49 pm
by rama3
Do you have very long wires anywhere by chance?
The only long wire in the whole debug setup should be the USB one, as USB is buffered.

Also, what are you fuse settings? The oscillator may be in 1Mhz mode.

Re: PSNee further development

Posted: October 26th, 2018, 12:05 am
by superg
Kabcorp wrote: October 25th, 2018, 10:09 pm Ok.. by using mySerial.begin at 9600 instead of 115200 AND monitoring at 1200, I have my "START" debug print
This:
rama3 wrote: October 25th, 2018, 11:49 pm Also, what are you fuse settings? The oscillator may be in 1Mhz mode.
Add this line to see what is your F_CPU define.
DEBUG_PRINT(F_CPU);
If you have a discrepancy between chip / pc baud rate (it's exactly 8x times in your case), F_CPU define and oscillator mode might be different, make sure it's all the same (8MHz internal oscillator and F_CPU is 8000000).

Re: PSNee further development

Posted: October 26th, 2018, 12:36 am
by rama3
Superg:
As I wrote the chip code, I actually wanted to read the fuse settings in the sketch, and display a warning somehow if they were wrong.
I think this wasn't possible, or at least not without some trickery.
If you happen to know how, this should definitely be added!
Once bad fuse settings have been detected, the chip could just blink the onboard LED rapidly (for Pro Micro, etc).
On an Attiny, it should probably shut down every operation except debug prints.

Re: PSNee further development

Posted: October 26th, 2018, 2:17 am
by superg
rama3 wrote: October 26th, 2018, 12:36 am Superg:
As I wrote the chip code, I actually wanted to read the fuse settings in the sketch, and display a warning somehow if they were wrong.
I think this wasn't possible, or at least not without some trickery.
If you happen to know how, this should definitely be added!
Once bad fuse settings have been detected, the chip could just blink the onboard LED rapidly (for Pro Micro, etc).
On an Attiny, it should probably shut down every operation except debug prints.
I'll check out if that can be done. I'm kind of new to Arduino, I used to do a lot of embedded things back in the day using the official tools.

Re: PSNee further development

Posted: October 26th, 2018, 3:24 am
by Kabcorp
superg wrote: October 26th, 2018, 12:05 am Add this line to see what is your F_CPU define.
DEBUG_PRINT(F_CPU);
If you have a discrepancy between chip / pc baud rate (it's exactly 8x times in your case), F_CPU define and oscillator mode might be different, make sure it's all the same (8MHz internal oscillator and F_CPU is 8000000).
I compile at internal 8mHz and the F_CPU is at 8000000

Re: PSNee further development

Posted: October 26th, 2018, 3:33 am
by Kabcorp
rama3 wrote: October 25th, 2018, 11:49 pm Do you have very long wires anywhere by chance?
The only long wire in the whole debug setup should be the USB one, as USB is buffered.

Also, what are you fuse settings? The oscillator may be in 1Mhz mode.
Nope, 5cm 30gauge wires

Re: PSNee further development

Posted: October 26th, 2018, 8:39 am
by Kabcorp
Ok it works, the ATtiny45 I used was broken somewhere. Thank you for your help guys!
I stuck on the point: Code should have .h for modifying parameters and adding hysteresis parameters in it too.
And.. goto in C in 2018? =))
Cheers

Re: PSNee further development

Posted: October 26th, 2018, 9:06 am
by superg
Kabcorp wrote: October 26th, 2018, 8:39 am Ok it works, the ATtiny45 I used was broken somewhere. Thank you for your help guys!
I stuck on the point: Code should have .h for modifying parameters and adding hysteresis parameters in it too.
And.. goto in C in 2018? =))
Cheers
Oh, goto might be cleaned later, and it's not necessarily bad and totally acceptable in Linux kernel for instance.
As of .h, valid point from C/C++ programmer standpoint but this is Arduino environment and from what I see they have a concept "sketch" which is usually a single file.

Re: PSNee further development

Posted: October 26th, 2018, 1:36 pm
by rama3
Yeah, the GOTO was very useful earlier. Maybe not so much in the latest iteration?
It's fine to use it, as long as a few conditions are met (such as no multi threading or interrupts that can change the state).
Basically, best to only consider it for use with micros ;p

Arduino allows header files, if you want to put something there.

Re: PSNee further development

Posted: October 28th, 2018, 2:10 am
by Kabcorp
Anyway, good job guys!

Re: PSNee further development

Posted: October 28th, 2018, 4:09 am
by rama3
Cheers :)

I don't like that the hysteresis value apparently isn't working for all cases.
It was a narrow decision between 2 games' different anti modchip routines, so the whole thing isn't optimal yet.
(One of the games surely was Dino Crisis NTSC-U, the first game to ship with that code. The other might have been a later title, where the check is done with different timing, maybe Silent Hill NTSC-J.)

Re: PSNee further development

Posted: October 28th, 2018, 8:09 pm
by daywalker
Hi, first of all, this is a great project!

I wanted to use this code to make a mod chip based on the AtTiny25. For that, i modified the code a little. Some parts, i think, are a bit simpler than in the original PSNee code. Others aren't ;) Also i wanted to use Atmel Studio to get rid of some overhead introduced by using the Arduino port manipulation commands and abstractions. Right now the code is using 646 bytes program memory and 25 bytes ram.
You can check out my code here: https://github.com/danielheinrich/PsNee
Let me know what you think and of course i am always glad if you find any bugs or other things to improve!

Tested the code successfully yesterday evening on an AtTiny85 on my PU-22 board!

Re: PSNee further development

Posted: October 29th, 2018, 12:45 am
by rama3
Oh, that's interesting!
You can override fuses in code? Is this possible on the other Atmels as well?

You inject the license symbols 6 times. That could be too much for some anti mod games. It's possible that you're still in the sending loop while the game has long moved the laser, and thus it becomes detectable.