DPC+ support !

[+Al_Nafuur]

new fonts and animated wait logos are cool, but what about DPC+ support?

 

I am (trying) to develop a DPC+ support for the PlusCart and the UnoCart. The DPC+ Bankswitching is working so far, so Chaotic Grill is running on the PlusCart.

 

The ARM code is not fully supported right now. Currently the DPC+ ROMs must be patched or recompiled to fit the memory layout of PlusCart and UnoCart, which differs from the Harmony's ARM. And the IRQ driven audio is not implemented yet.

 

So far I managed to recompile some of SpiceWares DPC+ examples and run on PAL systems. It seems that there is a timing issue in my DPC+ implementation, so these binaries are not working on (slightly faster) NTSC systems.

 

For reading a write from the 6507 the PlusCart (and the UnoCart) waits for the address bus to change, and uses the last value read on the data bus.

e.g:

https://gitlab.com/firmaplus/atari-2600-pluscart/-/blob/master/source/STM32firmware/PlusCart/Src/cartridge_emulation_dpcp.c#L217

 

this approach wastes a lot of time, and not much time is left for the operations afterwards without missing the next 6507 request/cycle.

 

I tried to use the read timing of @ZackAttack's SnoopDataBus function from his vcsLib, but without success.

 

For further testing I would like to have a modified stella build with altered memory settings for the PlusCart/UnoCart:

ROM base: 0x20000000

RAM base: 0x10000000

 

Harmony settings are:

ROM base: 0x00000000

RAM base: 0x40000000

 

maybe someone can provide this. Maybe this changes could be done for CDFJ too ?

[Prizrak]

I'm just as eager as anyone for DPC+ and CDFJ to be implemented, this last hurdle would completely make the PlusCart my go to cart rather than going between it and Harmony. It's a pretty large order to get both bankswitching formats but I'm sure we will get them implemented at some point.

[+Andrew Davie]

So it appears to me that you're essentially trying to "guarantee" that you have the correct data byte by waiting until the address bus changes, and then using the last data byte read BEFORE that change.

 

But, couldn't you do some sort of time check which looks at how long since the address bus changed *previously* and then just wait until the appropriate time for the data bus to be "stable".  That way you'd gain back the time between stability of the data bus, and the (eventual) change of the address bus by the 6507.  Another way of putting that; instead of taking the absolute last possible instant of the valid data "valid time range", you could try to shift that earlier using a timer/counter since the address bus was changed.

 

Edit:

 

Something like

 

    while (CurrentTime() - PreviousAddressChangeTime < TimeForDataToBecomeValid) {}
    data = DATA_IN. ; read the valid data now we know address is stable
                                                                             

 

 

 

 

Edited September 16, 2020 by Andrew Davie

[+Al_Nafuur]

5 hours ago, Andrew Davie said:

Something like

    while (CurrentTime() - PreviousAddressChangeTime < TimeForDataToBecomeValid) {}
    data = DATA_IN. ; read the valid data now we know address is stable
                                                                             

 

Something like this would be cool. We could measure the time between the address bus changes at emulation startup while the VCS is still in the RAM waitroutine. An then calculate the time it should take until the data at a write cycle is valid on the Data bus:

iirc this kind of measurement is used by SpiceWare to test if it is a PAL, NTSC or SECAM console (because they all have different CPU clock rates). I just don't find the thread right now. Has he published any c code about this detection? 

 

 

[+Andrew Davie]

Effectively shifting your handling from just after "tDHW" to just after "tMDS" if I read that correctly.

By my reckoning about 110 "somethings" according to the top scale. About 1/2 a cycle in legible units.

[ZackAttack]

How many NTSC systems has this been tested on? How long does it take to reproduce? What does the failure look like?

 

I played chaotic grill for 10-15 minutes on my ntsc 7800 without seeing any issue. If it weren't for the flicker I may have played all night. That game is awesome.

 

I suspect this may be an issue with detecting the wrong address. Specifically this line of code:

		while ((addr = ADDR_IN) != addr_prev) addr_prev = addr;

When working with the uno firmware I noticed that my JR would hold a transient address on the bus long enough for that code to pick it up. So the cart essentially services two memory accesses for each address change in the console. For simpler schemes like a 4K ROM it doesn't really matter because the f407 is so fast, but I could see it being a problem for more complicated ones like this.

 

I'll test with the JR tomorrow and hopefully see a failure.

 

[+Al_Nafuur]

9 hours ago, ZackAttack said:

I suspect this may be an issue with detecting the wrong address. Specifically this line of code:

		while ((addr = ADDR_IN) != addr_prev) addr_prev = addr;

When working with the uno firmware I noticed that my JR would hold a transient address on the bus long enough for that code to pick it up. So the cart essentially services two memory accesses for each address change in the console. For simpler schemes like a 4K ROM it doesn't really matter because the f407 is so fast, but I could see it being a problem for more complicated ones like this.

This code is used at almost every Bankswitching in the UnoCart and PlusCart. But in 3E, 3F and 0840 bankswitching there is a "new more robust test for stable address (seems to be needed for 7800)" used:

		while (((addr = ADDR_IN) != addr_prev) || (addr != addr_prev2))
		{	// new more robust test for stable address (seems to be needed for 7800)
			addr_prev2 = addr_prev;
			addr_prev = addr;
		}

maybe we should use this at the DPC+ bankswitching too..

 

[ZackAttack]

Tested on two more systems tonight.

NTSC Light Sixer: works fine

NTSC JR: Plus cart firmware did not load. Will need to debug that before I can proceed with DPC+ test.

[pseudografx]

Hi, been a while since last activity in this conversation, but has there been any progress in bringing DPC+ support to the Plus/UnoCart?

[+Al_Nafuur]

On 7/13/2023 at 1:34 AM, pseudografx said:

Hi, been a while since last activity in this conversation, but has there been any progress in bringing DPC+ support to the Plus/UnoCart?

Unfortunately no progress