Jump to content

ZackAttack

Members
  • Content Count

    785
  • Joined

  • Last visited

Community Reputation

419 Excellent

About ZackAttack

  • Rank
    Dragonstomper

Profile Information

  • Gender
    Male
  • Location
    Orlando, FL US

Recent Profile Visitors

8,983 profile views
  1. Another option would be to make it configurable so each user can get the font they like best.
  2. They are still in active development. James, I plan to reach out to you again once I have something close to the final release. You were already kind enough to show off the early prototypes and I didn't want to take up anymore of your time until we have a cart worthy version to send you. As @DirtyHairy said, I have been working on a fork with support for bus stuffing. I plan to release it and the source as a universal bootloader once it's fully functional. I'm aiming to have it released before July of this year.
  3. The amount of time it takes to read the address bus and put the corresponding value on the data bus is fairly large. There's only about 400ns (rough estimate) between when the 6502 puts an address value on the bus and when it expects the data value to be returned. Tight polling helps ensure that as soon as the address value changes the new value is worked on right away. If you only polled at a 2.4MHz rate it would eventually be at just the wrong time so that you end up missing the deadline and leave the previous value on the bus too long. There's also the overhead of interrupt processing. That is fairly minimal on ARM, but if you're doing it 2.4 million times per second it's consuming quite a few cycles and leaving very little time for useful work. What I've done with my projects is to anticipate what the next address will be, pre-calculate the corresponding data value, and then poll for it. As soon as the address changes to what I expect I put the data value on the bus and then use the rest of that cycle to do some computations for the next value. This allows time spent on reversing bits for playfield values, looking up colors in a table, masking sprites etc. Regarding DMA. Most banking schemes should be updating pointers or offsets to switch banks because copying a block of data would take too long. If there were block transfers being done, DMA would definitely be a good idea though. If you're asking this because you've encountered a banking scheme which has too much latency it may be the flash cache mechanism. ST claims 0 cycle wait states with their flash accelerators, but I've noticed when debugging firmware with a logic analyzer that there are occasionally visible delays due to flash caching that can cause a missed deadline. It's a bigger problem on the 7800 because the 6502 is clocked faster in that one. Eventually we should run all the critical banking code from SRAM to avoid these caching penalties. I've also noticed that it's dependent on code location in the flash. So making a change to a completely unrelated portion of code can move everything over just enough to cause a problem. Just like in 6502 ASM when you forget to org a lookup table and some changes push it across a page boundary and leave you with an extra cycle in your display kernel all of a sudden.
  4. Yeah, just make sure to leave the system powered on for a minute after running the firmware.bin or until the "update complete" screen is displayed. Whichever comes first. If your firmware is too old to support updates it won't even be able to load the firmware bin file format. Should be safe.
  5. Rather than disabling the carts, you could create a simple rom that puts up some text with a message to the end user and then redirect all their downloads to it. That way they can be informed that the device they purchased is in violation of GPL and where to legally obtain harmony, uno, and plus carts.
  6. I agree with @DirtyHairy, pirated harmony carts is not acceptable and I don't want work with anyone that continues to do so. My stance is either he comes into full compliance for all projects or he's not welcome in any of them. Hopefully he goes with the former since he appears to be capable of making some good contributions to the community. Btw, are we sure that they are in fact pirated? If he designed the board and firmware from scratch that wouldn't be any different than uno and plus cart supporting dpc+ games.
  7. I've been toying around with building my own PCB for the 2600 and I've noticed that the price difference between ENIG gold fingers and hardened gold is quite a bit. Especially in low volumes. Does anyone know if there are existing cart PCBs that have used ENIG for the gold fingers plating and how well they have held up? My concern is that ENIG might seem to work fine for the first couple of years, but will eventually have corrosion or wear problems that only show up after years of service.
  8. That might be a good choice if you have a need for the JTAG functionality in other projects. STM and ESP can use JTAG too, but I have yet to encounter a scenario where it was actually needed or helpful. I just use one of the cheap usb stick type ones from amazon. Just search amazon for st-link v2 and you'll find a bunch of choices like this: https://www.amazon.com/HiLetgo-Emulator-Downloader-Programmer-STM32F103C8T6/dp/B07SQV6VLZ/
  9. Ok, I'll answer my own question in case anyone else wants to go this path. st-link works fine with only the swdio, swclk, and ground connected. I suspect you'd only need the nrst pin connected in the case where PA13 and PA14 are being mapped to alternate functions and are no longer functioning as the SWD port. Since this should never apply to the plus cart the nrst pin can be ignored. Though based on the usb flash instructions the nrst button is the one closer to the usb connector. Perhaps if st-link is ever having connection issues, it's worth a try to reset it. I'm including some pictures with annotations on how I connected the st-link. Excuse the terrible soldering job, it was done in a rush, outside, in the dark, with a flashlight. Once you add the two yellow wires, simply connect them to st-link and a third for ground. I jammed a female hookup wire on there, but an alligator clip or soldered wire would be just as good. Then you can click run/debug from within stm32cubeide, set breakpoints, inspect memory, etc. Don't forget to keep the console powered on when using st-link since it will have no usb cable to power it. I think that's convenient because you don't have to worry about collisions with the console and USB power supplies. Not sure if that matters or not, but I can't imagine it would be a good idea to power the board from both at the same time.
  10. 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.
  11. I want to attach my st-link to the plus cart so I can debug the firmware directly from cubeide and not have to bother with jumpers every time I load a new build. I was able to find the corresponding pins for swdio and swclk but nrst doesn't appear to be brought out to the i/o headers. I assume it's going to one of the buttons on the breakout board. Has anyone had success with flashing/debugging via st-link? Which button is tied to nrst?
  12. 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.
  13. I just added a permissive license to the strong arm repo. I think that's necessary since most will want to modify something and include it with their games. Unocart firmware has a license on github as well: https://github.com/robinhedwards/UnoCart-2600/blob/master/LICENSE It's worth noting that although the unocart is the only hardware that currently supports this framework, the plan has always been to have a stripped down cheaper cart for publishing games. In that scenario the unocart licensing wouldn't apply since strong arm can bootstrapped directly without going through the uno firmware.
  14. It's been a while since I've played with that, but if I recall correctly. There were two types of failures with the early bus stuffing attempts. The first type was when the cart failed to stuff its value onto the bus. The other type was timing related. Some systems, mine in particular, have some unusual address bus activity in the transition time between valid bus signals. The timings are compliant with the 6502 datasheet as far as I can tell. The problem is that the carts don't have access to any clock signals and have to poll the address bus to determine which rom location to emulate or which address location its stuffing a value into. If a transient value is identified as the next location, the cart will produce the wrong value and probably spend too much time doing so to catch the actual value that follows. I completely bypass this problem in the strong-arm framework by keeping track of where 6502 will be reading next, precalculating the corresponding value, polling for the specific address value, and posting the data onto the bus as soon as the expected address is present on the bus. This has the bonus side effect of leaving more time to do useful work on the ARM core between 6502 bus servicing.
  15. Have you ever tried out this other bus stuffing implementation demo on that problematic junior?
×
×
  • Create New...