batari

Amazon and other huge retailers (that can easily afford the loss), seem to have created the belief that sellers are on the hook for offering free replacements for theft. However, this is a bit different than the usual case. Most of the time when an item is marked delivered and not there when the buyer gets home, we don't actually know whether it was stolen or if the carrier misdelivered, lied or screwed up. So without knowing what happened, morally the seller may be on the hook to resolve the matter. I have had to refund several times when the carrier messed up or when nobody knows what really happened. However, your buyer actually showed you proof that it was stolen, so we see that the carrier did their job correctly and so did you, so morally the onus should not be on you (though, because of big retailers creating some expectation that sellers are responsible for theft after the job was done, you may still lose this one, unfortunately.)

Thanks there will be at least one more revision to this. Aside from making the board shorter, I wanted to add one more possible configuration. This board supports just the Pico, or the Pico+ARM, but I also want it to be capable of just having the ARM chip on its own. I need to change some things around to make that possible.

Since some asked for more info, I thought I would post pictures of the latest prototype. A picture of an assembled board. This one only shows the Pi Pico and 16MB flash chip. The 512k ARM chip (that can play the larger CDFJ ARM games like Elevator Action and Turbo) in the upper corner is not populated on this board. Even without a plastic casing, the HEM can easily plug into a Harmony cart as the board is its own cartridge guide. Shown is the HEM+Harmony plugged into a 7800. Some changes are being made to this board. I will try to make it shorter - its height is mostly due to the limitations imposed by its ability to fit into a modified 2600 shell.

It is possible, yes, but with a caveat. The current Melody driver works on my end, but I have gotten reports from others that sometimes it doesn't boot (though if it does boot, it works fine.) You can test out the Melody driver by using developer mode on a Harmony to burn the game directly to Harmony's memory, and you can see if a Melody version of a Starpath game would work for you. I have been meaning to figure out why it doesn't boot for some people.

It isn't clear if you really understand how these ARM carts work. The ARM chip's IO is directly connected to the hardware and literally produces produces and responds to logic signals in real time just like actual logic can do. They are not just "bare metal" but they are literally emulating hardware in a cycle-accurate way, in some cases down to around 5ns of resolution. At the level needed to emulate certain legacy hardware, there is literally no way to tell the difference between an ARM and an a FPGA. A CPU and FPGA are more similar than FPGA proponents would like to believe. Each is a reconfigurable state machine in its essence, and in this realm there is actually a lot of overlap in the tasks that each can perform in a 100% cycle-accurate way. The only practical difference between the two is an FPGA can be programmed to do many things at the same time and each CPU core can only do one thing at a time. But hardware emulation of a legacy device is not incredibly complicated, and may run 1/50th the speed, maybe even a few hundredths of the speed. So the advantage of doing things in parallel that a FPGA offers is a lot less important. Suppose you can run your FPGA at 100 Mhz, and your ARM at the same speed, but the system being emulated is 1 MHz? Who cares if an FPGA can do 10 things in parallel, if the CPU can do these 10 things one step at a time, as long as you complete the task within the time allotted by the hardware, this benefit goes away and there is no way to tell the difference. CPUs will get faster, and legacy systems will stay the same. Sooner or later as this gap widens, we will have the ability to have a cycle-accurate, drop-in replacement chips that run on a CPU. Although we may not yet at the point where an ARM chip can perform 100% cycle-accurate hardware emulation of, say, the Atari 2600's TIA chip, I think it's just a matter of time before we are.

It's actually 1993 tech, if you consider the ARM core being used was first released in that year.

It's not hard to understand. The ARM carts are programmable carts, so it's essentially like having a 32x and a 32x cart all in one. Like 32x, ARM carts do not bypass any chips and go direct to video out like NES Doom. You're practically just using the console for power. The ARM in DPC+ is just a coprocessor for the 6507, like 32x. If DPC+ is cheating, then so are all 32x products.

Well, to be more clear, I didn't mean to compare ARM carts to the 32X itself, but more to the 32x with a 32x cart plugged into it.

Yes, I would rather see the technology (which basically replicates the Maria and TIA chips in their entirety within the cart itself) being used for this instead, because otherwise you only get the RGB video out from a single cart.

I'd say the "absurdity" is more in the ballpark of the Sega 32x than the project you are referring to.

There’s an RGB video mod for the 2600. So then you have RGB out from any cart, not just the flashcart. https://etim.net.au/shop/shop.php?crn=210&rn=552&action=show_detail

FPGA is emulation. It's hardware emulation (emulation of the lower-level signals and states of hardware), as opposed to software emulation (reproducing the higher-level behavior of the hardware). Thing is, FPGAs aren't necessarily representing every single hardware state or transition. There are almost certainly some optimizations, generalizations and compromises. FPGAs are typically not perfect replacements for retro hardware. They are not even necessarily more accurate than pure hardware emulation, either. Pure software emulation has gotten very good. I think for most people, the fact that it's gotten hard to tell the difference anymore is enough. Also, the line between software and hardware emulation is blurry. Microcontrollers are getting faster, and they are also more and more able to also do hardware emulation, particularly of older systems, meaning they are becoming more and more capable of working with hardware signals in real time just like real hardware and they do it for a much lower price than FPGAs. Hardware emulation from microcontrollers is important distinction from pure software emulation that the FPGA crowd doesn't seem to appreciate, or in some cases, even want to acknowledge, but it is happening and has been for some time, and it will only get better. As the lines blur more and more, I think FPGAs will become less important in retrogaming as they have always been more costly than micros, and I doubt that will ever change.

A11 is not affected by the 7800, so you should be good there. So it sounds like A12 is not going to cause you any problems. That being said, for posterity, my recollection with A12 is that it would go low for about 100ns around the middle of the cycle, so yes, this is rather inconvenient for a lot of devices.

Yes, it is very possible that this is the issue. Essentially, the problem is that on these problem consoles, soon after an address change where A12 is high, it will go low for a short time before going high again. What I had to do is ignore A12 in cases where there should not have been enough time for a legitimate low to occur.

Likely 1000% because you aren't charging enough for these