Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The MMU still seem to have timings issues when used with a RAMWorks III card #47

Closed
frozen-signal opened this issue May 1, 2024 · 1 comment
Labels
bug Something isn't working MMU Related to the Apple IIe's MMU (344-0010)

Comments

@frozen-signal
Copy link
Owner

With this setup:

  • Rockwell R6502
  • Unenhanced ROMs
  • ASIC IOU
  • RAMWorks III

The games "The Black Cauldron" fail to load and the game "ALIENS" have visual glitches.

@frozen-signal frozen-signal added bug Something isn't working MMU Related to the Apple IIe's MMU (344-0010) labels May 1, 2024
@frozen-signal
Copy link
Owner Author

frozen-signal commented May 3, 2024

This is an interesting issue, it seems that the CPLD itself is the cause.

The RA bus on the Apple IIe is shared between the MMU and the IOU; the MMU drives the bus when PHI_0 is HIGH, and the IOU drives it when PHI_0 is LOW. When the MMU or IOU is not driving the RA bus, it 'disables' it's output to the bus. If we consider the MMU, it drives the bus from the rising edge of /RAS in the previous cycle (i.e. /RAS is HIGH, but PHI_0 and Q3 are LOW) to the falling edge of Q3 of the current cycle (i.e. while both PHI_0 and Q3 are HIGH). A requirement of the RAM used in the Apple II serie is that the RA bus must hold it's value for some short delay past the falling edge of Q3. One way to do this, when using an Altera device, is to use the LCELL primitive; it adds ~5 ns per LCELL and is useful when precise timing is not required.

The LCELL primitive is a buffer and should not modify the signal. So, with this VHDL code:

    TEST_SIGNAL <= Q3 nand PHI_0;
    INITIAL_DELAY : LCELL port map(
        A_IN => TEST_SIGNAL,
        A_OUT => TEST_DELAYED(0)
    );

    g_GENERATE_DELAY: for i in 0 to 8 generate
        DELAY : LCELL port map(
            A_IN => TEST_DELAYED(i),
            A_OUT => TEST_DELAYED(i+1)
	    );
    end generate g_GENERATE_DELAY;

    LCELL_DELAYED <= TEST_DELAYED(9);

This just connect TEST_SIGNAL through a serie of 10 LCELLs. We would expect LCELL_DELAYED to be the same as TEST_SIGNAL, delayed by ~50ns. But that's not what we have:
RigolDS0
Yellow is TEST_SIGNAL,
Cyan is LCELL_DELAYED,
Magenta is PHI_0,
Blue is Q3

The above image is a bit crowded, so this is just TEST_SIGNAL and LCELL_DELAYED:
RigolDS1

You can see LCELL_DELAYED dropping but TEST_SIGNAL is not! It's the LCELLs that are causing this drop; this is what a 2-LCELLs looks like:
RigolDS3

Normally, LCELLs behave as expected, but in the above case, I think it's due to the fact that TEST_SIGNAL is computed from two slow-changing signals:
RigolDS2

As you can see the drop is ~50ns after the PHI_0 / Q3 change.

Should be fixed soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working MMU Related to the Apple IIe's MMU (344-0010)
Projects
None yet
Development

No branches or pull requests

1 participant