Please recommend a VGA to parallel LCD board or IC

[timeandfrequency]

@DC1MC :
OK, I understand : regarding that demanding application, only a top notch compiler like the Keil will do the job.

Of course, if you need time to organize your equipment, I will reschedule my trip to a date that is more convenient for you. Personally, I don't need an inventory list. The fleemarket modus (like at FACW events) is fine too : you walk, see, love and buy .

[ahrlad]

The RTD2660 SDK needs a modern optimizing compiler that is able to do code banking and extreme optimization (from 128KB available currently I've seen ca. 113KB used), absolutely no other compile can beat Keil (unfortunately), ah and it needs also to support customizable CPU instruction, mostly for banking.

SDCC can absolutely compile code that runs on the RTD2660, there's at least one open source project that has (very) basic functionality implemented. There's also a firmware using the SPI functionality of the chip, programming it with an AVR mcu.

For extremely simple needs - single input interface, single video format, single lcd panel, no OSD - you could just write the values into the scaler, using no more than a few kilobytes.

I made a custom PCB for this chip a while back. I got stuck and gave up on the software side though, it's pretty punishing getting to a place where you can debug and test it properly.

[ahrlad]

Regarding 15kHz operation, the chip is definitely capable of decoding video in that form, but no available firmware does it, as far as I know. The only example I know of is a 5 inch screen labeled Eyoyo, which at least supports 480i operation.

[Tantratron]

Hello @ahrlad, could you provide some web link on the different reference you have mentioned, namely (1) one open source project with basic functionality (2) firmware using the SPI functionality of the chip, programming it with an AVR mcu ?

If I wanted to try writing some values into the scaler, what mean should I use, is it possible to write the registers on the fly while the RTD2660 board is running, kind of debug or live control and if yes, through what port and protocol ?

By all means, if there is a way to create a simple project (no ISD, one input, single video format, single panel) not requiring to be hostage taken to buy the expensive Keil, that could be a serious revival and freedom.

Thank you to confirm the RTD2660 might be able to direct process a 15 KHz interlaced mode from a RGBS signal so there is hope even though nobody has published that specific firmware or what registers should be written.

Thank you in advance, Albert

[ahrlad]

Hello @ahrlad, could you provide some web link on the different reference you have mentioned, namely (1) one open source project with basic functionality (2) firmware using the SPI functionality of the chip, programming it with an AVR mcu ?

The first, using the internal 8051 controller, compiled with sdcc:
https://github.com/KerJoe/ORTD2662

The second, using a custom AVR over SPI:
https://github.com/specadmin/RTD2660AVR

There's also leaks of different versions of OEM firmwares out there, they can be compiled through keil. Here's one:
https://github.com/danyaPostfactum/RTD2662

If I wanted to try writing some values into the scaler, what mean should I use, is it possible to write the registers on the fly while the RTD2660 board is running, kind of debug or live control and if yes, through what port and protocol ?

I think you probably could, but not when using a vanilla firmware. The easiest way to access the mcu without a dedicated setup is using the i2c bus exposed through the VGA connector on typical scaler pcbs, which is how you can easily flash firmware from linux. The interface can also be used to write into the scaler registers, but all standard firmware disable the i2c interface on boot (to program the pcb, you typically have to power cycle it to interrupt that process). If you were to disable that check in firmware, you could probably write the desired values directly into the scaler and restart the video decoding to check if it works, but the firmware will probably rewrite those values after a bit.

By all means, if there is a way to create a simple project (no ISD, one input, single video format, single panel) not requiring to be hostage taken to buy the expensive Keil, that could be a serious revival and freedom.

Thank you to confirm the RTD2660 might be able to direct process a 15 KHz interlaced mode from a RGBS signal so there is hope even though nobody has published that specific firmware or what registers should be written.

Thank you in advance, Albert

Look at the composite decoding example of the ORTD2662 firmware linked above. You could use the ScalerWrite functions to input the exact values of your input signal and display interface into the scaler and be done - a lot of the complexity involved comes from measuring and decoding an incoming signal. If you have very exactly one known signal to decode, and don't desire pwm control over backlight or measuring signal or OSD or any of that stuff - you could just write the number of pixels and the pixel clock into the scaler registers, together with the display panel values. It still wouldn't be simple exactly, but very doable.

[Tantratron]

EDIT: What do you know, there IS software for the MacOS for the clip programmer:
https://github.com/YTEC-info/CH341A-Softwares

Now, for which version and how compatible, this question remains to be answered by fruit lovers  ?!?

The CH431A was delivered, see this post https://www.eevblog.com/forum/repair/ch341a-serial-memory-programmer-power-supply-fix/msg5714735/#msg5714735 regarding if still risky to use it without any modification ?

I'll try in the mean time to see if it does work with my iMac under MacOS

Thanks again, Albert

[Tantratron]

Here is an update where I've installed on my iMac the CH431A driver and the G-flash application CH431A github MacOS and G-flash MacOS


It seems all work (see attached picture) where the CH341A is found, the grabbers are installed on the PCB800099-V9 but for some reason, it will no know the flash NOR chip so no READ is possible.

I've tried another RTD2660H board (PCB800196-V6), same problem.

Stupid question but when connecting the grabbers and the CH341A, it will USB power all the PCB so could it be the RTD2660H receives power via the CH341A then boots so flash chip reading is corrupted or interfered ?

Any ideas or suggestions ?

[ahrlad]

Here is an update where I've installed on my iMac the CH431A driver and the G-flash application CH431A github MacOS and G-flash MacOS


It seems all work (see attached picture) where the CH341A is found, the grabbers are installed on the PCB800099-V9 but for some reason, it will no know the flash NOR chip so no READ is possible.

I've tried another RTD2660H board (PCB800196-V6), same problem.

Stupid question but when connecting the grabbers and the CH341A, it will USB power all the PCB so could it be the RTD2660H receives power via the CH341A then boots so flash chip reading is corrupted or interfered ?

Any ideas or suggestions ?

You probably have to disable the check for spi vendor/chip, if you can't find your exact chip in options. As long as you use a compatible chip it should work okay.

e: that is, the application seems to say it detects some form of spi device, but it's a bit unclear. It might also be bad connection to the pins.

Honestly, the best solution I've found is to use an old, bad laptop with Linux, connect to the PCB with vga, and control it through SSL. A used 2014 Chromebook or similar is basically e-waste and works fine. Or any development board with exposed i2c pins.

[Tantratron]

Honestly, the best solution I've found is to use an old, bad laptop with Linux, connect to the PCB with vga, and control it through SSL. A used 2014 Chromebook or similar is basically e-waste and works fine. Or any development board with exposed i2c pins.

Well yes and no because in this post https://www.eevblog.com/forum/projects/please-recommend-a-vga-to-parallel-lcd-board-or-ic/msg5708163/#msg5708163 and this other post https://www.eevblog.com/forum/projects/please-recommend-a-vga-to-parallel-lcd-board-or-ic/msg5708289/#msg5708289 DC1MC might have a point. It is not clear how the internal boot memory inside the RTD2660 works into allowing then the I2C communication from VGA pins to SPI NOR flash memory. Say we unsolder the flash chip or its stored firmware is bricked, is it still possible to rewrite or reflash via I2C/VGA correct firmware ?

[ahrlad]

Honestly, the best solution I've found is to use an old, bad laptop with Linux, connect to the PCB with vga, and control it through SSL. A used 2014 Chromebook or similar is basically e-waste and works fine. Or any development board with exposed i2c pins.

Well yes and no because in this post https://www.eevblog.com/forum/projects/please-recommend-a-vga-to-parallel-lcd-board-or-ic/msg5708163/#msg5708163 and this other post https://www.eevblog.com/forum/projects/please-recommend-a-vga-to-parallel-lcd-board-or-ic/msg5708289/#msg5708289 DC1MC might have a point. It is not clear how the internal boot memory inside the RTD2660 works into allowing then the I2C communication from VGA pins to SPI NOR flash memory. Say we unsolder the flash chip or its stored firmware is bricked, is it still possible to rewrite or reflash via I2C/VGA correct firmware ?

I can confirm it works with a fully blank spi flash chip, and I've also recovered lots of corrupted/interrupted chips. The functionality is on by default. The biggest hurdle with it is you need to interrupt the firmware immediately on boot, so you want a programmer that continuously polls the i2c bus - there's an open source one that does this very reliably.

It's not as quick as a direct spi connection to the chip, but I don't recall it taking more than about 10 seconds.

[Tantratron]

I can confirm it works with a fully blank spi flash chip, and I've also recovered lots of corrupted/interrupted chips. The functionality is on by default. The biggest hurdle with it is you need to interrupt the firmware immediately on boot, so you want a programmer that continuously polls the i2c bus - there's an open source one that does this very reliably.

It's not as quick as a direct spi connection to the chip, but I don't recall it taking more than about 10 seconds.

Many thanks for teaching all these tricks so I can pathwork my learning curve with RTD2660H.

Would it be possible that you share the open source repository continuously polling the i2c bus to prevent the boot ?

So if I understood right, inside the RTD2660H there is a local core boot memory or simplified Kernel which will always allow i2c transfer with the external SPI NOR flash, maybe some other vital low level function ?

[ahrlad]

I can confirm it works with a fully blank spi flash chip, and I've also recovered lots of corrupted/interrupted chips. The functionality is on by default. The biggest hurdle with it is you need to interrupt the firmware immediately on boot, so you want a programmer that continuously polls the i2c bus - there's an open source one that does this very reliably.

It's not as quick as a direct spi connection to the chip, but I don't recall it taking more than about 10 seconds.

Many thanks for teaching all these tricks so I can pathwork my learning curve with RTD2660H.

Would it be possible that you share the open source repository continuously polling the i2c bus to prevent the boot ?

So if I understood right, inside the RTD2660H there is a local core boot memory or simplified Kernel which will always allow i2c transfer with the external SPI NOR flash, maybe some other vital low level function ?

It is implemented on some very low level yes. I don't remember which programmer I used, but I've got it somewhere on my home computer, I'll post it later.

[Tantratron]

If I wanted to try writing some values into the scaler, what mean should I use, is it possible to write the registers on the fly while the RTD2660 board is running, kind of debug or live control and if yes, through what port and protocol ?

I think you probably could, but not when using a vanilla firmware. The easiest way to access the mcu without a dedicated setup is using the i2c bus exposed through the VGA connector on typical scaler pcbs, which is how you can easily flash firmware from linux. The interface can also be used to write into the scaler registers, but all standard firmware disable the i2c interface on boot (to program the pcb, you typically have to power cycle it to interrupt that process). If you were to disable that check in firmware, you could probably write the desired values directly into the scaler and restart the video decoding to check if it works, but the firmware will probably rewrite those values after a bit.

Regarding your last post about programmer doing continuously polling on the i2c to prevent external firmware to be launched, does the same technique would be used as you mentioned yesterday (see quote), being able to write live the scaler registers ?

[Tantratron]

You probably have to disable the check for spi vendor/chip, if you can't find your exact chip in options. As long as you use a compatible chip it should work okay.

e: that is, the application seems to say it detects some form of spi device, but it's a bit unclear. It might also be bad connection to the pins.

I’ve created an issue on the gitbub providing G-flash for MacOS and the developper updated with v1.4 which now works, see attached screenshot.

As for the Get Chip type, it detects SFDP-capable chip but when viewing the BIN file, it seems to be the same as when I did use a SALEAE logic analyzer to decode the SPI flow of that chip.

So that part CH431A is solved now under MacOS but I'll investigate more what you suggested regarding VGA-i2c flow access, ideally under MacOS with an Arduino DUE (i.e. modification of arduino Adafruit) or I'll jump into installing Linux in my iMac partition.

[ahrlad]

Regarding your last post about programmer doing continuously polling on the i2c to prevent external firmware to be launched, does the same technique would be used as you mentioned yesterday (see quote), being able to write live the scaler registers ?

No, I don't think that'd work, the firmware would just halt completely or rewrite the values after resuming.

[ahrlad]

I’ve created an issue on the gitbub providing G-flash for MacOS and the developper updated with v1.4 which now works, see attached screenshot.

As for the Get Chip type, it detects SFDP-capable chip but when viewing the BIN file, it seems to be the same as when I did use a SALEAE logic analyzer to decode the SPI flow of that chip.

So that part CH431A is solved now under MacOS but I'll investigate more what you suggested regarding VGA-i2c flow access, ideally under MacOS with an Arduino DUE (i.e. modification of arduino Adafruit) or I'll jump into installing Linux in my iMac partition.

That's great! Glad you got it working.

[Tantratron]

If I wanted to try writing some values into the scaler, what mean should I use, is it possible to write the registers on the fly while the RTD2660 board is running, kind of debug or live control and if yes, through what port and protocol ?

I think you probably could, but not when using a vanilla firmware. The easiest way to access the mcu without a dedicated setup is using the i2c bus exposed through the VGA connector on typical scaler pcbs, which is how you can easily flash firmware from linux. The interface can also be used to write into the scaler registers, but all standard firmware disable the i2c interface on boot (to program the pcb, you typically have to power cycle it to interrupt that process). If you were to disable that check in firmware, you could probably write the desired values directly into the scaler and restart the video decoding to check if it works, but the firmware will probably rewrite those values after a bit.

Have you tried or do you know how the RTD2660H (i.e. PCB800099 board) would react if the external SPI NOR flash is blank (full of FF) ?
In other words, what would occur from the Kernel embedded microOS inside the RTD2660 if it does not find any valid firmware on 25x040 external memory ?
Would this allow the i2c communication to be available to program say few scalers or parameters via VGA-i2c in order to get a primitive working (i.e. LCD display) ?

[Tantratron]

I can confirm it works with a fully blank spi flash chip, and I've also recovered lots of corrupted/interrupted chips. The functionality is on by default. The biggest hurdle with it is you need to interrupt the firmware immediately on boot, so you want a programmer that continuously polls the i2c bus - there's an open source one that does this very reliably.

It's not as quick as a direct spi connection to the chip, but I don't recall it taking more than about 10 seconds.

There is still something I do not understand when you connect a i2c programmer into the VGA port of RTD2660 board. Some of these programmers are sold on eBay or AliExpress, some other being available on github under AVR, Linux. When you connect the programmer to flash the firmware via VGA-i2c pins, the RTD2660 has boot (the board has power supply) so the flash's firmware is active. Then what is the mechanism to allow the firmware to be flashed if the stored on board firmware has been targetted to boot ?

Do these programmer actually do continuously poll the I2c bus to allow the writing of a new firmware ?

Let's go back to my initial question, namely the condition to write live in the scaler registers ?

I'm bit lost now  :'(

[ahrlad]

There is still something I do not understand when you connect a i2c programmer into the VGA port of RTD2660 board. Some of these programmers are sold on eBay or AliExpress, some other being available on github under AVR, Linux. When you connect the programmer to flash the firmware via VGA-i2c pins, the RTD2660 has boot (the board has power supply) so the flash's firmware is active. Then what is the mechanism to allow the firmware to be flashed if the stored on board firmware has been targetted to boot ?

Do these programmer actually do continuously poll the I2c bus to allow the writing of a new firmware ?

Let's go back to my initial question, namely the condition to write live in the scaler registers ?

I'm bit lost now  :'(

I'm not exactly sure what you're asking but I'll give it a try 

When using an i2c programmer connected to the vga i2c/ddc pins, the programming software does this (using the i2c bus):

Code: [Select]

  printf("Attempting to read chip ID... ");
  const FlashDesc* chip;
  bool cnt = false;
  int i = 0;
  char rotate[] = "|\\-/";
  do {
    i++;
    if (!WriteReg(0x6f, 0x80)) {  // Enter ISP mode
      if (cnt == false) printf("Write to 6F failed, keep trying...  ");
/.../
    else {
/.../
    b = ReadReg(0x6f);
    if (!(b & 0x80)) {
      if (cnt == false) printf("Can't enable ISP mode, keep trying...  ");

The register involved, 0xff6f, is the program_instruction register. Setting bit_7 to 1 enables programming the chip. Then you can use it to program the flash by writing the appropriate SPI commands, then the data, over the i2c interface.



I don't know exactly how standard firmwares disables this functionality on boot, I can't find the code for it. The program can still find the pcb over its i2c address - 0x4A - since the i2c bus is used for monitor ddc stuff. But it won't allow "enable ISP mode" in that state. I do know that I had to first put the programming software into the "Can't enable ISP mode, keep trying..." state, then power cycling the pcb until it worked. It's probably something involved with enabling DDC functionality over those same pins.

In practice, you would connect the board to your computer with either a full vga cable, or the vga ddc/i2c pins connected to your programmer. Then you would power on the board. Then you would run the programming software with your i2c bus, getting to the "keep trying..." point, and then power the board off and on. The programmer will write 0x80 into 0xff6f, thus enabling programming mode, and halting the mcu. then it'd program the chip.

To answer your last question, I'm not really sure! I'm somewhat confident you can use the i2c functionality to access other mcu registers than those used for programming the SPI flash chip, and use those registers to read and write to the scaler registers. Actually I'm all but certain, I know I managed to get it to reset the scaler after programming, though that might not be a scaler register. But doing complex stuff that way isn't going to be simple, you'll probably be looking at significant effort. It'd require a custom firmware in any case, which'd require a lot of functionality to work before sending commands to it over i2c would be helpful or necessary.

The programming software I used is this one, I had to hack it to bypass the SPI flash vendor check. The chips I've encountered all worked fine with the winbond op codes.

[Tantratron]

Many thanks @ahrlad for your last post with lot details and food for thought. I'm going to digest, read and think what will be my next move or project, one option being to use my arduino DUE then try to see what can be done via the VGA-i2c access per your suggestions.

Maybe one last question since I've lately purchased a USB-CH341A programmer to read or write the SPI NOR memory (25 serie). Do you think I can actually use the same USB interface to I2C link with VGA-i2c port, namely use its 24 serie output fed into one of my RTD2660 board ?

How about the voltage level for the VGA-i2c level (5v or max 3.3V) since the CH431A has a know issue about this topic ?

[DC1MC]

Well, now that there is an interesting discussion regarding and changing live scaler registers I've decided to do what no one did before, reading the available source code 

So, there are two ways of messing up with the registers:

 - Over UART (yes, we do have an UART) and over the I2C interface via the DDCCI commands.

I have to say the the available source code trees seem to have been HEAVILY edited to remove or strongly restrict the debugging functionality, the UART communication is restricted to the bare minimum and DDCCI commands, where available can be deduced only via header comments, the .C files have been removed and replaced with .OBJ files (with some effort the C code can be reconstructed). Also on the DDCCI path, there are two compile time selectable options: DDC and DDICDBG, and even there the cool debug commands are commented in the header , but they can be uncommented .

So let's start with the simple one: sending commands over the UART:
- A firmware has to have enabled _RS232_EN , that is #define _RS232_EN _on, so far NONE of the firmware that I have access to it have this option enabled, so keep this in mind.

BTW, your firmware has all the relevant compile time options defined in: Core/header/MainDef.h

In case you decide to recompile your firmware (or ask me to do it ) with this option enabled, a couple of functions are available, most interesting are (all defined in Uart.h and Uart.c):
UartCMDScalerRead() and UartCMDScalerWrite() that do what one would expect to do, albeit in a clumsy mode.
Funny stuff is that even they have I2C read and write functions and command codes defined in the header, they have been mercilessly cut off from the command interpreter !!!, along with other debug stuff.


 -The next bit thing is the DDCCI interface, as this is the post boot way to send commands over I2C
As said before, you have to have _SUPPORTDDCCI turned _on to have any I2C activity at all and then define _DDCCI_ for "normal" stuff and _DDCCIDBG_ for extra goodies.
Please examine ddcci.h and ddccidbg.h for nice functions and structures definitions, what is implemented or not in those .obj files remind to be seen .

That's about it as ALL the firmware that I have access in the source doesn't have either __DDCCI__  or __DDCCIDBG__ enabled, but maybe some of the installed binary firmware do has at least one of this enabled and studying these files my offer a gimple of how the commands are formatted and what are the I2C slave addresses in which one must send commands.


Cheers,
DC1MC

[Postal2]

... Maybe one last question since I've lately purchased a USB-CH341A programmer to read or write the SPI NOR memory (25 serie). Do you think I can actually use the same USB interface to I2C link with VGA-i2c port, namely use its 24 serie output fed into one of my RTD2660 board ? ...

RTD2660 is supported by my old program for LPT port, everyone copied it long ago, because I posted the source code. However, many wanted to use CH341. At first, a DLL was made for my program, and that suited me. But then "their" programs were made, and no one thanks me anymore.

I released the source code for RTD2660 on February 27, 2014. All programs made after that use it.

And I have NOT posted the source code for working with eMMC via FT232H (even FT232RL), so you won't find another solution. This is to make it clear what is happening when you post the source code.

Where did you score the Postal2 source code from? Forget openrtd2662.ru, nothing open about it.

I managed to reverse engineer how the postal2 reads the flash from the RDT2662 via the VGA DDC lines, it mostly makes sense, however I can not figure out how they calculate the CRC.

https://www.mattmillman.com/info/lcd/rovatools/

[ahrlad]

Well, now that there is an interesting discussion regarding and changing live scaler registers I've decided to do what no one did before, reading the available source code 

So, there are two ways of messing up with the registers:

 - Over UART (yes, we do have an UART) and over the I2C interface via the DDCCI commands.

I have to say the the available source code trees seem to have been HEAVILY edited to remove or strongly restrict the debugging functionality, the UART communication is restricted to the bare minimum and DDCCI commands, where available can be deduced only via header comments, the .C files have been removed and replaced with .OBJ files (with some effort the C code can be reconstructed). Also on the DDCCI path, there are two compile time selectable options: DDC and DDICDBG, and even there the cool debug commands are commented in the header , but they can be uncommented .

So let's start with the simple one: sending commands over the UART:
- A firmware has to have enabled _RS232_EN , that is #define _RS232_EN _on, so far NONE of the firmware that I have access to it have this option enabled, so keep this in mind.

BTW, your firmware has all the relevant compile time options defined in: Core/header/MainDef.h

In case you decide to recompile your firmware (or ask me to do it ) with this option enabled, a couple of functions are available, most interesting are (all defined in Uart.h and Uart.c):
UartCMDScalerRead() and UartCMDScalerWrite() that do what one would expect to do, albeit in a clumsy mode.
Funny stuff is that even they have I2C read and write functions and command codes defined in the header, they have been mercilessly cut off from the command interpreter !!!, along with other debug stuff.


 -The next bit thing is the DDCCI interface, as this is the post boot way to send commands over I2C
As said before, you have to have _SUPPORTDDCCI turned _on to have any I2C activity at all and then define _DDCCI_ for "normal" stuff and _DDCCIDBG_ for extra goodies.
Please examine ddcci.h and ddccidbg.h for nice functions and structures definitions, what is implemented or not in those .obj files remind to be seen .

That's about it as ALL the firmware that I have access in the source doesn't have either __DDCCI__  or __DDCCIDBG__ enabled, but maybe some of the installed binary firmware do has at least one of this enabled and studying these files my offer a gimple of how the commands are formatted and what are the I2C slave addresses in which one must send commands.


Cheers,
DC1MC

Yeah, being able to write directly into the scaler registers when running would certainly make testing much easier! If you're working with an unmodded or modded retail firmware though, you'll sooner or later start to work against it - the firmware is set to continuously measure the input signal, and compare it to the MODETABLE list of supported resolutions.  Even if you were to, say, set the scaler's input Hfreq to 15kHz, the scaler would be reset when the sync() functions run next time. You're looking at disabling a lot of functionality in the firmware to get it to work, which, in my experience, gives unpredictable results.

At some point, when you're somewhat confident with how the scaler works, it would be simpler to have a firmware that just turns the display on and then polls some pin(s) or interfaces for values to write into the scaler registers. The ORTD2662 firmware I linked to would be much easier to adapt that way, it's worth a look before spending the time required to get a working knowledge of the retail firmware code! The retail firmwares are very complicated and as you say, some of the code is hidden in blobs. You can still get an idea from reading the assembly files though, many of the blob functions are simple.

[Tantratron]

RTD2660 is supported by my old program for LPT port, everyone copied it long ago, because I posted the source code. However, many wanted to use CH341. At first, a DLL was made for my program, and that suited me. But then "their" programs were made, and no one thanks me anymore.

I released the source code for RTD2660 on February 27, 2014. All programs made after that use it.

Back in 2014, what method did you use to post publicly your source code on internet ?
Was it on forum or through github ?
Did your spirit was open source ?

[Postal2]

Back in 2014, .....

You are probably wondering what are the chances that publishing the code and the sudden insight of others after that are connected? I can't tell you, but if you want stories about how people stole it and answered a direct question "why from you?" - then I will tell you. By the time of publication, the code was already old, and everyone who needed it was carefully watching what I was posting. And I have no complaints. People want to look smart. I post at my own discretion. For example, I don't post how to work with eMMC via FT232H.

If you ask me for some code, I will most likely post it in an archive right here. Someone will download it, make their own program, and will honestly say that they did it all themselves. I don't mind, and it won't surprise me at all.

Here, take the source code and make a program for yourself.