C64R MK2 with VIC-II emulator circuit

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.
  • I hesitate to post this as it is a project that may never get off the ground, but


    I have been looking at the C64 Reloaded MK2 for potential use to test a VIC-II circuit.


    If I develop my own VIC-II circuit will the MK2 be able to determine the chip, or will it croak if things are not perfectly timed? The emulator does not output composite signals, sync, luma, etc. It outputs HDMI. What would be required to get working output? (There is possibly composite sync without colorburst available as the signals need to be generated by the emulator).


    Potentially more sprites will be supported (16 or 24) as an option, by using past page mode (FPM) of the dynamic RAM and modifying the ras, cas signals. Ras and cas are not evenly distributed across the phi02 clock to give more time for burst access. The split is approximately 2/3 of a clock for FPM access and 1/3 of the clock for non FPM access. I think this should work for DRAMS 200ns and faster.


    I think the C64 PAL chip does not care about the timing of RAS and CAS coming from the VIC-II.


    Ras cycle:


    BUS_SPRITE: rasr <= 32'b11100000000000000000011110000000;


    Cas cycle:


    BUS_SPRITE: casr <= 32'b11111000011000011000011111100000;



    I was wondering if this would be compatible given that the board is using static RAM? I assume that the RAS and CAS are passed through latches to the SRAM and if CAS pulses high and low multiple times the SRAM will receive the proper addresses. I am also assuming RAS and CAS are not synchronized to the PHI02 clock.


    I appreciate any comments

  • Just a hint: A new VIC chip with extended capabilities will require all new software. In other words: You'll be creating a new platform. Not sure if that's what people like to do.


    We're capturing RAS and CAS addresses on the edges that the VIC chip generates. These should be pretty close to what the original chip provides. Your idea of double-cas will not work in any C64 (not just the C64RMK2), because you'll only change the upper half of the address bus, not the lower half (note that RAS addresses are A0-A7), so you can only flip pages, but not consecutive addresses. Thought about this a lot of times, but never found any good use for double-CAS on a C64.

  • Okay. What happens if the chip cannot be detected correctly? Will the computer still operate? Could there be a setting for a custom chip? I note there are a couple of projects to emulate the VIC-II but it is tricky to get exact. A couple are VGA output.


    I can get a luma signal generated, but what components of the signal are necessary? Can it just be as simple as the output of a voltage divider (a pair of resistors)? I am trying to keep the number of components to a minimum and have only digital outputs available. I do not really want to mix things with transistors AKA AppleII style. What would happen if sync were fed to a resistor divider? Would it be enough to be useful for the C64RMK3? I am assuming there is a low-pass filter of the luma signal being used to detect average voltage level? Or are the sync pulses filtered out and timed? If it is just a voltage that is being looked for I would be inclined to use jumpers and resistors to set it.

    Chroma output could be provided too via a pair of resistors, that might give mono output for diagnostic purposes.


    For my project there is also an 80-column mode with a 30Hz refresh (VIC sync would be 7.5kHz, 30Hz) from the memory (still outputs at 60Hz though but not at the VIC outputs).

  • Refresh addresses must be on A0 to A7 when RAS is applied, but when an valid address is supplied they need to be bits A8 to A13. CAS still always needs the low eight address lines A0 to A7 as far as I know or page mode would not be possible with DRAM. Most DRAM chips use eight address bits for CAS and fewer for RAS. I was planning on using triple CAS + single CAS. I think the VIC-II chip handles switching the address bits around.

  • You got me studying the schematics and much to my disbelief the row and column addresses are indeed interchanged. It could only work with 64k DRAMS. Thanks, I will have to scrap the triple CAS idea.

  • What happens if the chip cannot be detected correctly? Will the computer still operate?

    Yes, it'll work, and the remote control menu lets you override voltage settings and clocking settings if required (see Wiki for documentation).


    Could there be a setting for a custom chip?

    No, the C64RMK2 is feature-complete. We won't make changes to it's specs any more.

    I can get a luma signal generated, but what components of the signal are necessary?

    PAL/NTSC recognition is taken from the sync signals. HMOS/NMOS recignition is done by looking at the output level when using 5V-only supply. If that's too low, the NMOS chip is detected, and voltage will be raised to 12V on the Vdd pin.

    Can it just be as simple as the output of a voltage divider (a pair of resistors)?

    Maybe, if carefully adjusted. You should be fine with providing the sync signals for your desired source clock.

    Would it be enough to be useful for the C64RMK3?

    C64RMK3 will not be using a VIC-II chip socket. We're still talking about the current C64RMK2.

    I will have to scrap the triple CAS idea.

    Maybe not scrap, but work with a different addressing scheme. Also, I wouldn't try triple-CAS, as even double-CAS will be a challenge in this noisy system. Yes, you have over 500ns cycle time (a bit less on NTSC systems), but transition times of over 30ns on any address line will cause huge pain. You have a large number of mainboard revisions to test with, and each revision has been equipped with different-brand TTL chips, so the timing model for a really "compatible" C64 product is *VERY* complex, even if you're only going with the standard 2M accesses and no tricks. Chameleon experience talking here...


    So if 80 colums is your goal, you could work with a local character set (kept in block RAM of the FPGA) and double-CAS for the badline, making alternate accesses to pages, completing a 2k read (and again, keeping it in block RAM) in the same time that the normal VIC-II takes to read 1K characters. It would cause a delay in display update of up to one frame. If you're keeping local charset anyway, you could even skip on badlines and use the 1MHz VIC cycles for transferring the 2k in just a few lines, increasing CPU availability (no badlines!) and getting rid of the double-CAS pain, which I personally would not attempt for a mass-produced product.

  • PAL/NTSC recognition is taken from the sync signals. HMOS/NMOS recignition is done by looking at the output level when using 5V-only supply. If that's too low, the NMOS chip is detected, and voltage will be raised to 12V on the Vdd pin.

    I am leaving the 12V Vdd disconnected, so that should be good, There's a four bit luma DAC now in my design so the level should be programmable as needed.


    C64RMK3 will not be using a VIC-II chip socket. We're still talking about the current C64RMK2.

    What is the C64RMK3 like or is it too early to describe. Is there going to be a video chip slot or is the display fixed format? Would I be better to wait for the MK3?


    I am trying to make a flat generic board that would allow play in the VIC-II compatibility. There are many possible circuits that could be placed in the FPGA. But for my purposes I think I will stick to VIC-II compatibility to begin with. It should be possible to upgrade the circuit at a later date, so I have been toying with different ideas.

  • What is the C64RMK3 like or is it too early to describe. Is there going to be a video chip slot or is the display fixed format? Would I be better to wait for the MK3?

    The MK3 is planned to be an FPGA-only version with all classic and modern interfaces. It will probably not appeal the the purist folks (which I believe make the majority of the community), so we will continue to produce the MK2, which is the last that will use the original chips.

  • The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.