Posts by robinsonb5

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.

  • Chameleon Core update 9o released

    Quote from Jens

    Not sure if this is a fundamental problem of understanding, or if you just used the wrong words and meant the right thing. Just to be clear: Our VIC-Sync feature NEVER increases the vertical frequency - it will increase the line count, thus reducing vertical frequency. This is where the requirement of "just under 50.2Hz" comes from

    Yes, thanks - I worded that ambiguously, but when I said "increase it again" I was referring to the total number of lines, not the frequency.


    If I'm understanding the sync feature correctly, then one could begin with the "ideal" modeline which will have 625 lines, remove a couple of lines from the front porch to increase the vertical frequency, and then the VIC-Sync logic would put them back again when it delays the sync pulse? (With the occasional extra line - or perhaps missing line - due to phase drift effects.)

  • Chameleon Core update 9o released

    Quote from Tobias

    It doesnt seem to be 100% right though - because the C16 core works fine here. Also, we have another "problem" with Chameleon - the 50Hz modes have to be slightly faster than 50Hz (actually faster than 50.125Hz), else the "VIC-Sync" will not work (Thats why all the other 50Hz modes are actually 50.2Hz)

    Interesting - I wasn't sure it was right because the way the border counting works in the core makes it a bit tricky to figure out exactly where the pulses fall.


    The need for a higher framerate is why you reduced vtotal from 625, yes?


    The 576p broadcast video standard - which ultimately is what we're imitating here - is defined in ITU-R Rec 1358-1 - albeit not in a form that can be copied-and-pasted into a modeline. If I'm reading it right, what it defines amounts to:

    modeline "576p" 27.69 720 741 806 886 576 581 586 625


    (Again, I guess you could reduce the 625 to increase the vertical frequency, and trust in the VIC Sync to increase it again.)


    But I will measure exactly what the Minimig core generates.

  • Chameleon Core update 9o released

    Quote from Tobias

    i wonder what the exact setup for those cores is (didnt i ask it before, i cant find it now...) robinsonb5 do you know? couldnt find it with a quick look at the sources (and i cant read verilog at all...)

    I don't know off the top of my head, but I can measure them.


    The thing to understand about those cores is that they're not doing any kind of scan conversion or smart scaling - they're simply scandoubling the PAL 288p or NTSC 240p TV-compatible signal. And the scandoubler *really* means it when it says double. Each row is sampled, then emitted again at double the pixel clock - pixel data, sync pulse, porches and everything.

    So from a modeline perspective, the horizontal parameters wouldn't change, while the pixel clock and vertical parameters would all double, compared with vanilla 240 or 288p.

    Technically the back porch would be reduced by 1 (doubled to 2) and the front porch increased by 1 (2) due to the buffer delay.
    (Also I believe serration pulses are only inserted when the scandoubler's disabled.)


    In last month's update thread I did post what I believe is a modeline matching the C16 core -

    Modeline "720x576x50" 28.38 720 732 798 912 576 580 586 624 -HSync -VSync

    Since 625 is the number of lines in a complete PAL frame, I suspect it's important for VTotal to be as close to that as possible.

  • Chameleon Core update 9o released

    Quote from turrican9

    Divided by two it's 736. This takes into account the full overscan. If i go just a tiny bit up or down with the pixelclocks then i get the problem that the monitor switches to other resolutions at coldboot. I may manage to change the horizontal to lets say 1470 and keep it stable. I could experiment more if you want

    You can probably reduce it to 1440 and put the extra 32 clocks into the front porch instead without upsetting anything.

    Likewise, if you halve all the horizontal values as well as the pixel clock you should, in theory, end up with a true 720x576 mode that has exactly the same timings. If you can get that working stably, then you'll have useful settings for other people to refer to.

  • Chameleon Core update 9n released

    Quote from Tobias

    Interesting... can you tell the exact timing too? I calculated (with a tool called "umc") a VGA mode for a 720x576x50 mode, and the result is nowhere close to 31kHz vertical frequency


    Code
    1. Modeline "720x576x50.20" 26.807603 720 736 808 896 576 580 584 596 -HSync +VSync

    None of my monitors can make sense of this, its detected as 640x480 and half the image does not show.

    I've just looked at the video code of the C16 core to try and figure out a matching modeline. The borders make it a bit tricky, but I think the following is plausible:

    Code
    1. Modeline "720x576x50" 28.38 720 732 798 912 576 580 586 625 -HSync -VSync

    Try different permutations of the sync signals, too - both those and the width of the vsync pulse carry information that the monitor may or may not take any notice of.


    (Without the scandoubler, the pixel clock and vertical values would all be halved and the horizontal values would stay the same.)


    Edit: Ah - I see you've figured it out - nice one! :D

  • Chameleon Core update 9n released

    Quote from Tobias

    I wonder if anyone can find out some more details on the modes those cores are using (*)... i am playing around with it atm, but so far none of my monitors can make sense of it :/ (*) vertical frequency at least would help, perhaps also the resolution of the (emulated) image they are displaying.

    These cores aren't doing any upscaling or framerate conversion - when the scandoubler's disabled they're aiming to output the same signal as the original machine - i.e. PAL or NTSC. Some monitors are happy to display that, many are not.


    The scandoubler doesn't touch the vertical frequency, it simply buffers a line of video along with its sync pulses and spits it out again twice at double the speed. So if the original core's emitting PAL 576i (or more likley 288p), the scandoubled signal will be 50Hz vertical, 31.25ish KHz horizontal, and should be recognised as 720x576 (otherwise known as 576p) if the monitor supports that mode. If the monitor doesn't support that mode it'll either display nothing or make a best guess (most likely 800x600) which then might or might not be scaled correctly.

  • PC Engine on v2

    Quote from Jens

    I remember we've exchanged quite a few eMails where I've thrown you a number of hints on how to debug the SD-Ram issue, but I'd of course be interested in what the final solution was!

    The only solution I found was not to do ACTa NOP ACTb RDa NOP WRTb.

    On the newer Winbond chip the write appears to cancel the read and the data never arrives. This behaviour appears to be absolutely deterministic, and doesn't change with clock speed or phase shift. That pattern works on every other chip I've tested (including the older Winbond chip on TC64v1 - though fails with Micron's verilog simulation model), and is used in the SDRAM controllers of the upstream MiST Genesis and PCEngine cores. I suspect that this access pattern is not actually legal, and just happens to work on other chips by taking advantage of undefined behaviour.


    I ended up re-writing the controller more or less from scratch - it still makes heavy use of bank interleaving, but doesn't attempt to overlap reads and writes quite so aggressively.

  • PC Engine on v2

    After a long struggle figuring out an SDRAM problem and getting the internal firmware to fit in just 20k of block RAM, the enhanced PC Engine / TurboGrafx16 core is out now: http://retroramblings.net/?page_id=969


    Supergrafx games are now supported.

    CDROM games in bin/cue format are now supported.

    The core has a 19-bit audio DAC, allowing the PC Engine audio to have 18-bits resolution and be mixed with 16-bit CDDA audio.

    For those wanting to try out CDROM bin/cue support, please note that you need a SuperCD BIOS file such as (syscard3.pce) which you will load as though it were a game ROM. Then you can mount a .cue file. However, please note that only images with a single .bin file are currently supported - images split over multiple .bins or with the music in .wav/.mp3 files won't work.

  • P96 3.0 screen dragging question

    Quote from Jens

    It can surely be implemented on the Chameleon - there's plenty of memory, and adding the required regsiter/functionality is within the realm of "possible" on the 25k LE-FPGA.

    By the way, the screen-dragging functionality doesn't seem to be properly documented in the carddevelop.lha archive.

    I think there should be some mention of the SetScreenSplit() in the PrivateInclude/CARDDEVELOP.HTML file, but it doesn't seem to be there?


    (Minimig leaves the 25kLE FPGA *very* full, by the way, and because of that the existing RTG functionality is a bit "creative". It doesn't even have a CRTC - instead it uses the AGA chipset generate the sync pulses.)

  • OneChipMSX on v2

    Quote from turrican9

    Cannot initialize the SD card with this core. Both my TC64 V2s have the same problem. Both have different SD cards

    Probably the same problem as the older megadrive core, since they have very similar control modules.

    I'll update it some point in the not too distant future - there are upstream improvements, too.

  • Chameleon Core update 9n released

    Quote from turrican9

    So your monitor probably dont reckognize this resolution and switches to 800x600 instead

    That would be my guess. The scandoubler's output isn't going to match a standard VESA mode, so a monitor that doesn't recognise 576p is probably going to round up to the next nearest plausible resolution.


    (With my ports of MiST cores you can enable/disable the internal scandoubler by holding down the menu or F12 button for more than 1 second.)

  • C16 / Plus 4 - another member of the family

    Quote from turrican9

    awesome! Just tried it. Noticed when i load a prg game, go to the menu and try to load another game it crashes and i have to restart the unit in order to load another game.

    Yes, currently it's splatting the new program straight over the top of the one that's already running, which causes a crash.

    If you reset the core from the menu before loading a new PRG it's fine. But yes, this needs fixing.


    Quote from turrican9

    oh, and i could not get autofire to work in the new version of commando. Not tried other games in this regard.

    There's no autofire support yet - which might be why it doesn't work! ;)

  • Megadrive/Genesis core port to V2

    Quote from el_pasi

    Hi Alastair and thanks for another core :-) I have tried running this with Standalone TC V1, but is it more picky with SD-cards than earlier cores? It didn't run autoboot.md and if I choose "Load *.bingenmd", there is just blank page and I can only choose <Back . I'm using same card, which works with for example SMS,NES,Vectrex-cores.

    Interesting - it shouldn't be any pickier than SMS, NES and Vectrex, since it's exactly the same supporting code. I think I increased the SD card clock speed, though, since megadrive ROMs can be large - I'll check. I may need to reduce that again for reliable operation on V1.