Jump to content

Open Club  ·  76 members

StellaRT
IGNORED

Community-Built Unnamed 1970's Video Game Console-Compatible System (WIP)


Al_Nafuur

Recommended Posts

10 minutes ago, MarcoJ said:

Is this an official change to design now?

🤷‍♂️

10 minutes ago, MarcoJ said:

I'm planning to upgrade my board to use the new latches.

We're just poking around in the dark, but it looks like that some sort of latches are needed if we want to go further the Raspberry Pi route.

 

  • Like 1
Link to comment
Share on other sites

With your new version I can't currently get Thomas' V3 ROM to fail, so I did some manual trigger on the working code. The worst I was able to find is change of databus ~5ns after address bus change:

image.thumb.png.453d4bc51c043c242c86a27cb68de002.png

 

It is recorded at 200Mhz so 5ns is the sampling rate ...maybe something between 2.5 ns and 7.5 ns. I will try a 500MHz recording but its hard to find a bad example there. I only get very short recordings at 500Mhz

  • Like 1
Link to comment
Share on other sites

2 minutes ago, Kroko said:

Just tried Decathlon with the new code and latches. Its the first time it runs for me on the PlusCart, too. Before it always crashed almost immediately. Did my first 100m Dash on the PlusCart 😁

 

Yes with the latches the short $0000 addresses are gone and FE and SuperCharger games should run now on the PlusCart without my firmware workaround (ignoring $0000 addresses when counting "cycles"). Have you tested the Decathlon cartridge? Mine isn't working on StellaRT and unfortunately my SuperCharger seems to be dead 😞

 

 

 

  • Like 1
Link to comment
Share on other sites

2 minutes ago, Thomas Jentzsch said:

So, is this the final breakthrough?

Final breakdown at least for my SuperCharger 🤣

The FE cartridge isn't fully convinced that it is talking to a real 2600, and my GameLine module isn't convinced too. Harmony FE and SC are to be tested..

 

Link to comment
Share on other sites

7 minutes ago, Thomas Jentzsch said:

So, is this the final breakthrough?

FE seems to be ok for the way PlusCart handles things, but not for the real cart. Another open question is, why I always end up in the Stella debugger when I first start the PlusCart ? I think it is getting better, but there is still some way to go 😀

Edited by Kroko
Link to comment
Share on other sites

2 minutes ago, Kroko said:

FE seems to be ok for the way PlusCart handles things, but not for the real cart. Another open question is, why I always end up in the Stella debugger when I first start the PlusCart ? I think it is getting better, but there is still some way to go 😀

maybe you have the "-debug" flag set on the command line?

 

Link to comment
Share on other sites

2 minutes ago, Al_Nafuur said:

The FE cartridge isn't fully convinced that it is talking to a real 2600

When you look at how the bus timing is, its easy to see ... we have no accurate 840ns bus cycle. As long as we don't find a way to be at least close enough, I fear it will be hard to satisfy each real cart.

Link to comment
Share on other sites

2 minutes ago, Al_Nafuur said:

maybe you have the "-debug" flag set on the command line?

 

No,

I start it with
sudo ./stella -plr.timemachine 0 -dev.timemachine 0 /home/admin/Desktop/StellaXYZ/roms/CartridgePort.bin

and compile it with
sudo ./configure --host=rtstella && sudo make -j2 all

 

Link to comment
Share on other sites

18 minutes ago, Kroko said:

This is what I get every time, then when I set the PC to Ram_89 and continue its working fine ...
Screenshot2023-11-25231213.thumb.png.f2f936a450c755a1a25d7a005e12c5b3.png

that's not happening with my PlusCart(s). Are you plugin the 5V of the cartridge before starting stella?

 

Link to comment
Share on other sites

36 minutes ago, Kroko said:

When you look at how the bus timing is, its easy to see ... we have no accurate 840ns bus cycle. As long as we don't find a way to be at least close enough, I fear it will be hard to satisfy each real cart.

(most) real cartridges don't have any clocks. So they can't measure/check our timings and only can "react" to bus changes..

Link to comment
Share on other sites

3 minutes ago, Al_Nafuur said:

(most) real cartridges don't have any clocks

Are you sure ? maybe no "real" clocks but RC circuitry for delays connected to pins. To measure the time from a stabilized address and/or databus or some event and by that determine when they would like to read. I have no proof for that statement, but I think there are people who are conviced that these carts doit like that. But lets see...maybe this assumption is incorrect.

  • Like 1
Link to comment
Share on other sites

8 minutes ago, Kroko said:

Are you sure ? maybe no "real" clocks but RC circuitry for delays connected to pins. To measure the time from a stabilized address and/or databus or some event and by that determine when they would like to read. I have no proof for that statement, but I think there are people who are conviced that these carts doit like that. But lets see...maybe this assumption is incorrect.

Yes only circuitry that can "react" to our bus changes (most likely address bus), so we "only" have to make sure that the bus (most likely data bus) is in the expected state at the time when it is checked.

Link to comment
Share on other sites

On 11/25/2023 at 1:50 AM, Al_Nafuur said:

Or maybe a CPU with GPIO ports that can be set in one step.

Rockchip RK3288 has 160 GPIOs and needs only one register write to set a 32 bit port:

http://www.armdesigner.com/download/Rockchip_RK3288_Datasheet_V2.7-20191227.pdf

 

Unfortunately all development boards try to copy the Pi design and don't expose a consecutive 32 bit port.

 

We would have to build our own board and cobble together the parts (HDMI, USB, SD-Card eMMC) from the hardware reference guide:

http://opensource.rock-chips.com/images/a/ae/Rk3288_hardware_reference.zip 

Link to comment
Share on other sites

On 11/25/2023 at 10:27 PM, Kroko said:

With your new version I can't currently get Thomas' V3 ROM to fail, so I did some manual trigger on the working code. The worst I was able to find is change of databus ~5ns after address bus change:

image.thumb.png.453d4bc51c043c242c86a27cb68de002.png

 

It is recorded at 200Mhz so 5ns is the sampling rate ...maybe something between 2.5 ns and 7.5 ns. I will try a 500MHz recording but its hard to find a bad example there. I only get very short recordings at 500Mhz

I tried different timings, but no success with the real Decathlon cartridge.

 

@Kroko can you provide a log from the Decathlon cartridge crashing on your system, maybe we can see something there.

 

 

Link to comment
Share on other sites

6 hours ago, Al_Nafuur said:

 

@Kroko can you provide a log from the Decathlon cartridge crashing on your system, maybe we can see something there.

The trigger is difficult to choose. $1F0-$1FF ? But we would see all Stack hits, also the ones that work fine. So how do we find a good section of the code that we would like to see ?
It would help me if you could identify some address that I can trigger on, so you see the behavior of the cart at or after that piece of code... I only see about 400us at 50 Mz or even less at 100 MHz ...

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...