frozen-signal / apple_iie_mmu_iou Goto Github PK

The game The Black Cauldron has some weird artifact.

The 'blank' screen (before the scene is drawn on) has some artifact, but the portions that have been drawn are correct.
Here's what it looks like while the scene is being drawn:

On rare occasions, the game will fail to load, hanging on a loading screen. On even more rare occasion, the game will run perfectly.

Possibly linked to #39
Hopefully, not due to DRAM about to fail.

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.

Presently all Apple IIc features (VLC HIGH) has been excluded from this implementation.

Currently all soft-switches of the IOU are cleared when RESET_N goes LOW.
The correct behaviour is that RESET_N LOW should not change the ITEXT and MIX soft-switches

Possibly related to #4

Maybe a bus problem that would prevent the CPU to access C03X?

the MUX RA has changed. Need to update the test.
The test is disabled in the meantime.

This is what it looks like:

Probably related to #14

This is how the lines are displayed in text mode:

The computation of the memory address for each line is incorrect.

With a RAMWORKS 1 and 3, the RAM is not recognized when using this setup:

• 6502 with unenhanced ROMS
• Slow RAM (4164) on a row other than the first.

Will work if a:

• 65C02 with enhanced ROMS is used instead
  or
• The slow RAM is replaced with faster 100ns DRAMs

The implementation in this repository works, but just for safety, bring the signal timings of the IOU and MMU closer to the ASICs.

Presently all Apple IIc features (VLC HIGH) has been excluded from this implementation.

As of writing, this is what is displayed with a real MMU and a IOU programmed with the sources of this repository:

Check if there is a bus conflict on RA0-RA7.

The DRAM ICs used by the Apple IIe requires a hold delay on /CAS. Fortunately for the Mainboard's RAM access, the column address is valid until the falling edge of Q3, which is more than enough hold delay.
But for the AUX memory, the column address is strobed on the falling edge of Q3. This may cause a problem because, in the current implementation, that's when ORA0-7 becomes invalid.
So, there might be a race condition for the column address strobe on the AUX DRAM.
Maybe add a delay to make ORA0-7 remain valid a short time past the falling edge of Q3 would make it safer?

As of writing, this is what is displayed with a real MMU and a IOU programmed with the sources of this repository:

Check first if there is a problem with LGR/TXT_N or CLRGAT_N.

At power-on, POC remains HIGH and RESET_N goes immediately High-Z.
Expected behaviour is:

• POC should remain HIGH for ~2.4 ms, then driven LOW.
• RESET_N should be LOW while POC is HIGH, remain LOW until the video scanner overflows (TC=1), then driven High-Z on the next PHI_1.

Create a document / datasheet describing timings requirements for the IOU and the MMU

Implementing a hardware solution with the current state of the project is not a trivial task.

Some games are not working when using a specific setup. Not exactly sure what could be the problem. Possibly another timing issue.
This setup works without problem:

• 6502 with un-enhanced ROMs
• 80-Col Expansion card (820-0067-D)
• Apple 5.25 Drive Controller Card (655-0101-E)

But using instead a 65C02 with enhanced ROMs will cause problems with Doulbe HiRes games. For example, Aliens will hang when switching to the graphic mode.
Seems to be tied to the 80-Col card, but it's possible to re-create the problem without the card present. For example, Aliens normally can run without the 80-Col card. But will still hang without it.

Apple IIe Diagnostic v2.1 also reports problems with the 80-Col card.