On this front there is hopefully not a huge amount that needs to be done. There have been a couple of pin re-assignments, as well as fixing a couple of issues that we knew about:
1. The FPGA pin for A15 has changed, which is easy to fix. In fact, for many purposes, it simply doesn't matter, because many cartridges only use the lower address bits. Anyway, it has been fixed now.
2. The /EXROM and /GAME lines that tell the MEGA65 to bank in ROMs from the cartridge are now proper input lines. On the first revision of the PCB these were connected to a two-way buffer that was really generally only used for output, so we had to periodically pause the bus and set the buffer to input, and read the lines. This can now be simplified, because the lines are pure input.
Fixing those problems didn't take particularly long. But cartridges were still not quite working. After some investigation, I found that there occasional errors reading bytes from the cartridge. Every now and then a byte gets read where some bits are changed from 0 to 1. It doesn't seem that they switch from 1 to 0, however. The R2 PCB has pull-ups on the address and data lines on the cartridge port, which the R1 did not have. Thus it is possible that there may be too much pull-up power, so I have just gone through and disabled all of that work for the R2 PCB.
Of course, that will take a while to synthesise, so I'll try to think about what else could be wrong. First I wanted to make sure that the cartridge port is not being run too fast: The dotclock is actually running at about 6.25MHz instead of 8MHz. The main clock is however running at 1.2MHz, which could conceivably cause problems.
The slow dotclock is because the pixelclock changed from 100MHz down to 80MHz, so I'll fix that while I am here as well. What is a real mystery, however, is that the phi2 clock is only 1/5 of the dotclock instead of 1/8th. I think I realise how this is happening now: The divider is /5 (0 to 4), instead of divide by 8, since the dotclock loop it sits in is counting dotclock phase changes, not clock cycles.
It turned out that the clock was not a problem, but the old logic for the R1 PCB to prime the data lines with charge (because of the lack of pull-ups), which meant that it would take longer for a line to get pulled low -- which is what we were seeing.
Then after this we found a problem where the cartridge_enable line in the CPU is not being enabled when requested, which meant we couldn't actually read the /EXROM and /GAME lines. So we have worked around this in the CPU initially, although the actual root cause is still not exactly clear, as the two locations that clear this flag should only be run under reset, and when the machine is in "secure mode" which is not the default.
After some hunting around this turned out to be caused by trying to keep compatiblity with the R1 PCB, which then confused the VHDL compiler with the way that I was using these signals as outputs as well as inputs. It actually took quite a few hours to get to the bottom of this problem.
In the process, I also finally fixed the problem with some cartridges not working because they only pull /EXROM or /GAME low briefly on reset, typically with a capacitor. The boot ROM now pulls the cartridge reset line low for a little while before exiting to boot, so that such cartridges present their ROMs. This enabled such cartridges as the Epyx Fastload cartridge and Power Cartridge to begin to work. There may be features in them, and many other cartridges, that don't work, but we are getting to the point of having quite a number of cartridges working. Even the Ezyflash works now, although it is mostly rather useless to use a flash memory cartridge on a computer that already has an SD card for bulk storage.
Anyway, this has let us test the cartridge port enough to have confidence that it works physically, and the rest of the compatibility improvements in the future should need to be software/VHDL only.
No comments:
Post a Comment