[aotta]

Thank you marqs for reply and info, but there’s something wrong in the order the colors with Atari VCS palette. I use both PAL and NTSC palette with RGBtoHDMI and they works perfectly with my Atari, but even with them translated (rgbtohdmi use bbggrraa values) to your tia_pal table give wrong results. I didn’t understand the logic, even after test and vibe debugging with deepseek, using chart demo roms showed like colors were inverted from row to columns. I tested with my Atari PAL, that use a different shifting phase and logic for palette than NTSC, so i don’t know if NTSC Atari owner got a correct answer with default palette. Other parameters i think are right, and i got crispy colors but purple instead of green, light pink instead of blu, turquouse instead of brown and so on. I don’t want to test each of 104 right colors, so i returned to composite for OSSC, and i’ll use the RGBtoHDMI for Lumacode. Waiting you’ll got the HW to debug it, i think VCS is a good retroconsole to have in your collection!

[aotta]

Thank you Marqs! where could we find some more info about custom lumacode palettes working? I’m interested but can’t try for now the new feature since my PRO has sent back to RMA…

Edited:  sorry, just found the info updated in the wiki, i’ll start from there!

• This reply was modified 5 months ago by aotta.
• This reply was modified 5 months ago by aotta.

[aotta]

Thank you for the support, i’m going to e-mail you

[aotta]

Just an update, i found that AV1_AL is shorted to GND, that’s i think it’s the issue!

Already checked R31 and D49, and the short remains also removing them.

So, it least the U20, but the IC it’s too small to resolder with my skill, so i can’t check it.

Any other idea?

• This reply was modified 5 months ago by aotta.

[aotta]

With 0.80 my OSSC Pro hangs while saving setting to SD, creating 0 len files. I had to return to 0.79.

While waiting for fixing, it’s possible to have the “scan for source at boot” option, like in the first OSSC?

[aotta]

@megari, i flashed the hex in your release RC3 zip files. I did it again, after noticed no difference from the RC2 FW.
And what i get it’s exactly how you listed. About time in 4), i waited same seconds and few minutes, but no changed.
You know my board has some hw issue since arrival, and my replacing the ATMEGA may be added some other oddities to my Koryuu… i think you should’t take my test in care, if i’m the only user that has this result.

[aotta]

hi @megari and Merry XMas!
i just flashed your RC3 bud didn’t found differences from the previous RC2 one: if no input at Koryuu starting, it wake up only with a power cycle or at change input setting’s cycle.
If Koryuu find input signal at startup, it works normally, but show test pattern when input source is powered off.
I dont’ know if it’s the expected behaviour. Tested with both s-video and composite input.

[aotta]

@megari Tested and confirming that cycling inputs wake up video correctly. But i think the original scope of the user asking for the NTP feature was leave Koryuu always powerd and hidden behind the TV/Monitor, so a different approach will be useful (although i think too it’s not so safe for Koryuu’s lifetime).

[aotta]

Hi @megari, you got it! RC2 works fine with both composite and s-video (no) input!
The only (very) minor issue is that, i think, the null input is checked only at startup, so if power on the input after some time, Koryuu continue to sleep.
But i’m very happy to have the NTP working, and interested in looking at changes you made to code!
Thank you!

[aotta]

@megari: i flashed the -ntp firmware on Koryuu and i got test pattern in output composite when no cable it’s connected in input ports. Just tested your RC1-ntp too, same result. I reflashed the default version, and made some “verify” to be sure the fw in the AVR is loaded fine, but found no error in flashing memory. I didn’t found the version 1.0 to make further test, is there some others check i can do?
edited:
after more test, playing with code of your main.cpp, i rid off of the test patter only removing the write in 0x82 and 0x84 subaddress, where you put the #if 0 conditional compiling: in this way, i got no test pattern (and, no computer output too, but i expected this), but…. the OSSC find in any case an output signal and its auto tune set the input to Koryuu!
Wasn’t that the scope of the NTP version? i think i’ll remain to the “default” branch and poweroff the koryuu when not in use.. it’s simpler and more “green” 😉

[aotta]

i can compute che checksum if you want, but i didn’t compile myself the hexes files, i used the one zipped in your github files koryuu-fw_1.1-test1.zip. Setting are stored when stored with both buttons, and parameters to set aren’t so much to need the eesave fuse, i think. Anyway, i used fuse setting found in other forum: H:D1, L:62, E:FF.
About the original AVR, now i’m pretty sure it was fine, but i damaged a couple of pins while desoldering, so it went to e-trash with the arduino nano board… anyway, it was a five euros clone, so it wasn’t a great lost.

[aotta]

you can search for an USPISP or USBASP programmer, you’ll find many at few dollars on all hw store. Choose the one with 6 pin ISP cable.
Then, you can follow the guide you linked, or use ATMEL studio tools (but this last one SW it is compatible only with “MKII programmer”).

[aotta]

@megari, now i can play with FWs, i’ve a question about FW1.1 t1: i tested both “normal” and “ntp” versions, but i got the coloured vertical bars with ntp one’s too. Is it not the version without output if no input signal? i missed something?
Thank you for your patience and support!

Edit: and, for curious guys, the result of my Koryuu surgeon: https://imgbox.com/PsVK3MXM

[aotta]

The lsf204 code is unreadeable after flush, hot gun, and EPA cleaning.. From a pic I got before working on it, it seems a TI (from the logo) LSF204 97A33 P1FC. Thank to your pinout, i removed the Lsf204 at all and rewired isp’s pins to input pads. I programmed the avr without the psu, and it worked too, with avr studio tools reporting 3.3v in reading voltage.. I hope it’s safer in this way.

[aotta]

@megari, i made my homework: desoldered AVR and replaced with a pre-programmed (i took it from an arduino nano) atmega328p, and it worked but still no ISP programming.
In desoldering, i lift a IC’s pad (the pin26 – PC3): Koryuu seems to work fine, but since there is no schematic, can you tell me the right connection, so i can repair it?
So, i try a different way: i bypassed the LSF0204 and directly connected the MISO, MOSI and Reset from ISP port to AVR: Avrstudio and MKII find the AVR and i could program it!
Now i’ve 3 small green wires flying under the Koryuu’s shell, but it finally can be update!
May be my LSF0204 is gone? I found in a Texas Instruments’ datasheet that pins 6 and 9 are not connected in TSSOP 14 pin LSF0204, while in Koryuu they are used.. could it be related to my issue?
Thank you for your support!

[Author]

Posts