Possibility of 15Khz RGB output on C64 or Minimig?

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.
  • Please read again what I wrote: We do not generate composite sync, so there is no need to look into the electrical side. If the logical side doesn't even match, why attempt it on the electrical side?

    You sound that *you* don't generative composite sync, then in the following comment Alastair said that it depends on the core, and that he does in fact generate composite sync with some of his cores. So I was responding to Alastair's comment.


    most of the cores in question (and the systems they imitate) don't make any attempt to interlace their video. If they do serration at all they either output all-even or all-odd frames.

    Maybe I'm misunderstanding, but it sounds like you're saying that most cores output 240p sync instead of 480i sync? But 240p sync is still a valid composite sync signal that many composite monitors will sync to, right? It's not exactly what we want, but it seems like it might actually work well enough to get a readable picture on the screen.


    I think there is also a lot of now very cheap video equipment on ebay that can do things like fixing and changing sync signals, so I might look around at that.


    By the way, I'm not just asking all these questions for my own personal tinkering -- I regularly put on public exhibitions of old computer technology (see attached picture) and I also work with museums and other organizations helping set up these kinds of displays, and in those cases you often want as much of the equipment as close as possible to the original, especially with displays. Many younger people have never even seen a CRT, and really enjoy seeing this kind of stuff. My second TC64 and docking station are actually at the Museum of Modern Art in New York because they were used to exhibit an artwork from the 80s that was made on the Commodore 64.


    Also, for 15khz RGB, I found a cable that looks like it's what is needed to go directly from the TC64 to a Commodore 1084 monitor:

    https://ultimatemister.com/product/mister-commodore-1084s/

  • Quote

    My second TC64 and docking station are actually at the Museum of Modern Art in New York because they were used to exhibit an artwork from the 80s that was made on the Commodore 64.

    Now i demand a photo (and wonder what kind of artwork this would be) :)

  • Maybe I'm misunderstanding, but it sounds like you're saying that most cores output 240p sync instead of 480i sync? But 240p sync is still a valid composite sync signal that many composite monitors will sync to, right? It's not exactly what we want, but it seems like it might actually work well enough to get a readable picture on the screen.

    The confusion is that there's more to sync than just how many wires are involved.


    TV video standards specify one particular pattern of sync pulses during the vertical sync interval to indicate an even frame, and a different pattern to indicate an odd frame. Normal broadcast video (and the Amiga in interlace mode) alternates between these.


    A "correct" 240p (or 288p) signal would generate a valid sync pattern for either even or odd frames, and not alternate between them - the Amiga does this in non-interlaced modes. (The MInimig core also does this, but it may not be doing it correctly.)


    Most other cores aren't outputting either type of sync pattern - they're simply combining the H and V sync signals into a single pin, generally with an XOR. It's not "correct", but works in practice as you've seen. (The reason is that the cores are written to be used with the scandoubler - being able to use them with a 15KHz monitor is a bonus. In the vast majority of cases it works fine, but no guarantees, your mileage may vary.)


    I think what Jens is saying - correct me if I'm wrong - is that there's no scope for generating the "correct" composite sync patterns in the Chameleon core.

  • Now i demand a photo (and wonder what kind of artwork this would be) :)

    Yes, please elaborate a bit more on that PaulSlocum . I can't spot a C64 on the picture already posted.


    Edit: Oh, I got it wrong. It's about TC64 in a docking station, not about an original C64 setup. But still I'd like to hear more about this.

  • robinsonb5 Thanks for the explanation.


    Tobias The artwork is Mike Builds a Shelter by Michael Smith from 1983. You might say it's like a predecessor to other experimental/art games like Desert Bus, and various artists have made similar games in the 90s and onward.


    https://www.moma.org/collection/works/422172


    It was running on a TC64 when it was exhibited in London years ago. When we did that exhibit, I had a short timeframe and had to ship everything overseas, and a TC64 with an LCD monitor was the easiest solution. But since the museum acquired it, I adapted it to run on a Raspberry Pi with BMC64 because we wanted it to be running on a real composite CRT at the museum. I'm actually hoping that I can get my extra TC64 and docking station back from the museum. The game will be on display at MoMA this summer.

  • Quote

    The artwork is Mike Builds a Shelter by Michael Smith from 1983. You might say it's like a predecessor to other experimental/art games like Desert Bus, and various artists have made similar games in the 90s and onward.

    Can we donwload those somewhere? Never heard about those

  • We've not released the disk image of Mike Builds a Shelter, but eventually we will. I archived the disks myself, I think I used an MMC Replay.


    The Desert Bus ISO was released online about 15 year ago. It's part of Penn and Teller's Smoke and Mirrors for the Sega CD. It's a game where you have to drive a bus for 8 hours in real time to get one point, and there's no pause. You might want to just watch a video instead of actually playing it. :)

  • @robinsonb5 Do you think that the 15khz RGB cores would work with any of the various RGB to composite/svideo converters that have been produced?


    https://www.manualslib.com/man…tsc-Encoding-Iec-843.html

    I'd be very surprised if the Minimig core didn't work with it, since the original Minimig had a composite encoder chip on board. I'm not sure about the other cores - would have to try them and see, I guess.


    (Now the sync issue is more "on my radar" I may end up updating the other cores to produce "correct" composite syncs at some point.)

  • Peter and I did discuss 15kHz some more this Friday. In the end, we'll have to relay the information about the connected monitor type from the menu system to all other cores, so if you have a CRT connected, no core will attempt to fire out 31kHz (or more) and possibly destroy it.


    The most basic idea we came up with is that the cores look at the config data from the menu system. However, Tobias did not document that so far, because it wasn't required to be public information up until now. Also, since the Chameleon core uses dynamic re-programming of PLL outputs (which most other cores probably don't, as that's really fiddly with Altera FPGAs), the internal data like pixel clock and front/back porch timings are most likely useless to other cores.


    In any case, it probably comes down to monitor information being relayed in a fixed spot of the Core0 space of the flash. This info will probably need further interpretation by "some intelligence" of the new core, which won't be a problem for the Minimig core, as that has a separate entity of the TG68k core for running the menu. However, other cores like Atari 2600, Vic-20 and Sinclair cores don't have that, so we *may* revert to a few bits that say "15kHz mandatory" and "15kHz optional", which does not need a processor.


    Again, this is not a confirmation that it'll happen at all, but if it does, it shall be consistent throughout the product. It would not be practical if the menu runs at 15kHz, but other cores don't, and vice versa.


    Jens

  • I made a post on the TC64 FB group about my 15khz TC64 Amiga setup that was one of the most popular posts in a long time, and I've noticed that more people have been trying it out. Somebody did get the Amiga core running on an actual 1084S monitor using the MiSTer 1084S cable (see attached picture). So it does appear that there are more people interested in 15khz support other than just me. :)

  • Oh what does my red hurted eyes see : a picture of my setup :) thanks Paul.


    I indeed managed it to get my 1084s-P1 to run with the TCv2. Meanwhile i also have a VGA Splitter adapter to have a vga flat and the 1084s at the same port. I also mailed with Jens 2 Weeks ago about this cable, and he told me to post documentation and highres picture of the cable here.


    I got answer from the dev of the cable that he will send me the documentation anytime soon, i believe he is from Portugal or Spain, but seems to be very busy man, i still wait for the mail with the documentation, highres picture will follow as soon as i get that too.

  • You might as well open the ends of the cable and take high-res pictures - or is that a molded cable?


    Edit: I see that you've already opened it, so it's not a molded cable :-)

  • So finally i got the "documentation" for the cable wich works with mistvga/tc64v2vga to 1084s-xx



    quite unsure if it is correct since the first picture shows scart on one end but with the pins in the second picture it should be fine i guess - im not much of a techie

  • addition : the above cable is only working with the minimig aga core from alaistar robinson - not with the tc64 menus and / or "c64 emulation"


    Feel free to test with any other core that may comes with 15hz possiblity !