USERPORT DDRB corruption

[YazanMehyar]

I've been using the MMFS in my FPGA project that emulates the BEEB. I've tried out some games that work perfectly. However, Some don't. One such game is Snapper (aka Pacman). Placing a .ssd image on an MMBEEB.IMG file and DBOOTing it successfully leaves me facing an empty maze with no action whatsoever. This may seem to be an issue related to FPGA, but I've read on this post (http://stardot.org.uk/forums/viewtopic.php?t=7877&start=30) that the SUPERMMC may not restore the DDR to its previous state (all outputs). In more detail:

//This code sample seems to exist in Snapper
 .LOOP
CMP $FE60
BEQ LOOP

I believe it is testing the bit 7 (counting from 0) which is related to the T1 timer pulsing bit 7. The MOS6522 datasheet shows that bit if both DDRB[7] is 1 and ACR[7] (auxiliary control register) is 1 then then a PB7 (as affected by the timer) appears on the PORTB when read by the processor.

Going over the code, a few adjustments in USERPORT.asm may cure the problem. MMC_DEVICE_RESET is called from MMC_BEGIN1 (& MMC_BEGIN2, which is called from several places). MMC_DEVICE_RESET seems to be the only block of code which writes to the DDRB without considering previous values.

The issue is seen with MMFS.rom (I tried none other).

[hoglet67]

I'll look into this, possibly over the weekend.

To help me reproduce, please can you attach the Snapper .ssd image you are using for testing.

Is the source for your FPGA project available to look at somewhere?

[hoglet67]

Yazan,

I have done a bit of experimentation.

1. I can't reproduce the problem on either a real Model B (with a SY6522 VIA) or my own BeebFpga. It's possible this is because I'm using a Snapper .ssd that has been "fixed". Please attach the .ssd file you are using.

2. The following test program shows PB7 toggling, regardless of whether PB7 is set as an input or an output:

   10 ?&FE62=&00:     REM also works with &FF
   20 ?&FE6B=&C0
   30 ?&FE65=&40
   40 REPEAT
   50 PRINT ~?&FE60
   60 UNTIL FALSE

   So this looks to me like you have a VIA Emulation Bug.

Can you check your VIA emulation is clearing PB7 when &FE65 is written, as per this fix: https://github.com/hoglet67/BeebFpga/commit/509d024580626da80c7b33a6ec9bad21775af5f8

[YazanMehyar]

Thanks for getting back to me, Here's the .ssd file I'm using. I haven't made the project open source yet, but I'm planning on it. I did a similar workaround and made the user VIA return PB7 when reading port B (FE60) instead of outport B bit 7 regardless of the ACR. This seems to work.

Regarding clearing PB7, I do so unless Timer 1 is in free run mode. Apparently, I misinterpreted the spec. I'll do the fix and report back.

Snapper-v1-alt.ssd.zip

.

[hoglet67]

I've tested Snapper-v1-alt.ssd on a real Model B with MMFS 1.28 (using *DBOOT to launch after a Ctrl Break) and it works fine.

So I think inspite of what the data sheet says, when ACR bit 7=1 DDRB seems to be ignored, at least on the SY6522. I've just verified that with a scope.

Anyway, I will go ahead and update MMFS to not affect DDR bits 2..7.

I'll push a new release in a few minutes.

[hoglet67]

FYI, I'd introduced a bug in SAVE in 1.31, please use 1.32 instead. https://github.com/hoglet67/MMFS/releases/tag/mmfs_1_32_0

[YazanMehyar]

I'm happy to report disregarding the DDR if ACR bit 7 is set works.