[megari]

Hi @djc6,

Thank you for the feedback. Sorry for forgetting to add that crucial piece of information.

I made two tiny improvements to the Wiki page: 1) note that the required type of ICSP cable is probably not supplied with the programmer, 2) link to an imgur gallery showing in detail how to set up things with the Olimex programmer specifically.

If you have the time, please have a quick look if the on-Wiki instructions are sufficiently informative now.

Thank you,
-megari

[megari]

Hmm. That programmer resembles the one from Seeedstudio: Atmel AVRISP STK500 USB ISP Programmer, which is also being sold by Digikey. According to the PDF manual available on Digikey, the programmer type should be set to STK500. This may or may not have an effect.

What drivers are you using for the programmer? Have you tried the libusb32 or libusb-K driver (using Zadig)?

The voltage should be set to 5V. Having target mode off is mainly to protect the programmer itself from burning out from interaction with the PSU. If there is no jumper for it, you can check if the 5V pin outputs any power (you try lighting up an LED through a resistor with it, for example).

Using Atmel/Microchip Studio should be fine, but you may want to try reading the old firmware off the Koryuu just to see that the programmer works reliably. If that works without any errors, flashing a new firmware image should as well. As long as you do not change any fuse settings, bricking the MCU is very unlikely.

[megari]

Please see if these Koryuu programmer tips are of any help.

[megari]

Hi @AJBats,

if you are still struggling with getting the firmware on your Koryuu updated, the instructions on the junkerhq wiki page have been updated with essentially the same process as in the screencast. If you’re willing to give it a try, please let me know if you experience any trouble.

-megari

[megari]

Hi Bill!

Indeed, the issue you are experiencing is quite a mystery. As you detailed above, the results of the troubleshooting ended up being inconclusive, as they pointed to the OSSC on one hand and to the Koryuu on the other. Also, if I remember our correspondence correctly, there were also differences between displays (although this is rather common when the video source is a retro console/computer)?

However, when looking at all the identified configurations with this issue, the only constant factors seem to be the bright flashes (even with just luma+sync), the consoles themselves and the Koryuu. I am quite puzzled by what could cause this, as even the brightest flashes should not affect sync when the physical characteristics of the video path are correct, as I remember us spending quite a bit of effort confirming.

[megari]

Hi @d020!

Hmm, that doesn’t look like expected behavior. Can you tell us more about your setup, please?

I see in your video you have two screens side-by-side. I’m assuming at least the left one is connected to the Koryuu somehow, and the right one looks like a CRT of some sort? Could you describe in detail how the two screens are connected to the MD, and what hardware you have in your video path between the console and the screen(s), please?

Is the console unmodded? Asking this because region mods can affect video timings, although it seems that the output is native to the console (NTSC 240p/480i, possibly line-doubled/deinterlaced to 480p?), and there is color, implying the color subcarrier is derived from the main crystal frequency correctly.

Does the intermittent black screen only occur when running Master System games on the MD, or with MD/Genesis games, too? IIRC, Master System games may have some unusual video modes and/or timings, so that could be a factor.

Are you running the original firmware on your Koryuu? If so, would you be willing to try a newer Release Candidate version, which is most likely going to be very similar to the next official release? It has a lot of bugs fixed, and some new features, too.

I would be delighted to hear any and all reports about Koryuu behavior and compatibility with different kinds of hardware, be they consoles, retro computers, video scalers/line multipliers, transcoders, displays etc. I have been actually hoping for volunteers to pop up. 🙂

[megari]

Hi @aotta,

So, with the NTP version of firmware version 1.1-RC3, you are observing the following behavior:

1. Initial state: Koryuu is off, all video sources connected to Koryuu inputs are off.
2. Koryuu is turned on. The color bars test pattern is not shown. The device connected to the Koryuu (such as the OSSC) indicates no video signal is being produced by the Koryuu.
3. The Koryuu input setting is set appropriately.
4. Some time passes (how long?).
5. The video source connected to the Koryuu input selected above is turned on.
6. The Koryuu continues not to produce a video signal, as indicated by the device connected to the Koryuu (such as the OSSC).
7. After cycling through the input choices on the Koryuu all the way back to the input selected above, Koryuu starts producing a video signal, as indicated by the device connected to the Koryuu (such as the OSSC).

Also, if the input source is active on Koryuu startup, the picture comes up OK, and after the video source is turned off, the color bars test pattern is shown by the Koryuu.

If the above is accurate in its description of what you are seeing, I am stumped. I cannot see how the behavior above is possible, judging from the firmware source code. Are you absolutely sure that you are flashing the correct version (1.1-RC3) and variant (-ntp) of the firmware on the Koryuu? Are you using the pre-built .hex images in the .zip files in the releases/ directory or are you building them yourself from the source code?

[megari]

@əotta I pushed a new tag today (fw_1.1-RC3). Could you try it out for me, please? I would like to make sure that the Koryuu does not fail to automatically wake up from sleep if the currently selected input (in an inactive state) becomes active and starts producing a video signal.

[megari]

@aotta Thank you for testing. It does concern me that the Koryuu fails to wake up from sleep after an input is connected. Does cycling through the different inputs (using the Input Change button) make it wake up eventually?

I’ll try and get some further improvements done.

[megari]

Hi @aotta,

Could you try the 1.1-RC2 NTP version? I reworked the NTP code a bit to try and eliminate corner cases. Now the encoder chip is also explicitly set to sleep mode with all DACs disabled when in free-run mode and in NTP mode.

The writes to subaddresses 0x82 and 0x84 are unrelated to NTP mode.

[megari]

@aotta I tried to find out if there might be something wrong with -ntp (No Test Pattern) firmware, but couldn’t find anything that would explain the test pattern being displayed when there is no input. Could you try and describe me the scenario(s) where the test pattern ends up being displayed despite the -ntp firmware being used, please?

[megari]

For the software side of things, the suggested procedure and choice of software is perhaps a bit outdated. I have been aching to create proper instructions, but all I have at the moment is this very WIP, non-narrated screencast: Koryuu fw Windows 10 flashing setup Screencast

It’s not very good (contains missteps and pauses while thinking), but hopefully better than nothing. Please read the video description if it’s difficult to tell what is going on.

[megari]

If the file @marqs provided does not work for you, Intel’s list of supported 3rd party configuration devices may help create a suitable configuration.

[megari]

@Saldali The official .jic files have been generated assuming an EPCE16 configuration device. However, the one on your OSSC is an MX25L32, which necessitates regenerating the .jic file using it. It doesn’t seem to be officially supported by Quartus Prime, but it may be possible to create a custom configuration device.

EDIT: Pre-empted by @marqs 🙂

[megari]

@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?

Hmm, that’s weird. I’ll try and see if there’s a bug somewhere. Just to confirm we are on the same page, could you check the sha256sum or sha1sum of the .hex files you used, please? That may help me to pinpoint the exact version of the source code they were built from, just in case I made some mistake when building them.

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

Well done saving the unit from becoming e-waste just because of such a tiny component being faulty!
I guess the original atmega328p was OK as well? You’ll be able to save your Arduino Nano then! 🙂

(BTW, if you do not want your saved settings in EEPROM to be wiped every time you program a new firmware, it’d be best to program the EESAVE hfuse. Just be very careful to get it right.)

[Author]

Posts