batari

Yes, some of the same board(s) that Penult is being released on will also support this game.

I don't think they would do much in that regard (and maybe snap off in the process.) It's impossible to insert a cart backwards anyway due to the board being off-center. I think the pegs were mainly so the shell could be used for 2600 games as well (and indeed it was) because they 2600 does need them.

There are firmware update instructions on on this site: https://7800.8bitdev.org/index.php/Concerto

Correct, it's still available, and it's on sale for $69. There have been some times when it was sold out for a few weeks or a month, so some may have checked at just the wrong time. In fact, it's been on sale for a little while, and probably will be at least until the end of the year. The current version has been engineered so I could lower the price for you all. It's the same Concerto, electrically and functionally, but through a combination of board design and economy of scale of certain parts that are shared with other projects, I am finally able to sell it for less. For the $69 sale price of Concerto, you even get a built in HOKEY on the board, no need to add your own. As a part of the design, the HOKEY is soldered on, so there is no socket for a real POKEY or socketed HOKEY. I do still have older boards version with the 40-pin socket, but its price begins at $89, as these are costlier and more time consuming to produce. As for HOKEY, I know many want those, and I have a bunch of them ready, but I had been holding off until the 0.97 firmware that supports the CEM #0 device is ready. I have a bunch of CEM #0 devices also ready. I have just been so busy, at first with PRGE preparation but also with my continuing efforts making homebrew boards for AtariAge and Champ Games, that I have had trouble finding the time. The firmware does work, there are just a few things I need to address, which I plan to do this week so I can get an initial release of HOKEY and CEM #0 out this month. I will make a separate post about HOKEY/CEM #0 later.

Sorry, I forgot to contact you about this. I went and looked at the tracking and though I did see the "recipient unknown," I don't see anything about it being returned. I see the tracking was updated yesterday with: Shipment arrived in the recipient's region Germany So weeks later, it's still in Germany? I'm sorry for the delay in shipping, these things happen, but given the tracking was updated just yesterday, I would give it a few more days to see if DHL figures out the issue, otherwise I am willing to send a replacement.

I got E.T. carts in the last few lots of ebay commons I bought a few years ago. None were in good condition, but still, I don't think they are rare at all. If someone is charging more for loose E.T. carts, it's only because of the lore. Same with Adventure.

Wow, cut that thing off. It's totally not needed. 0.1uF is all you need for a cart like that. I've seen some with 1uF as well, but there should be no need for more than that.

An idea that might better fit the A8 crowd is to use $0C, as there is nothing connected there. I didn't use $0C because that is reserved in HOKEY. Beyond that, HOKEY doesn't support SIO, and I am not sure if it ever will, so it's probably not going to be an issue to use $0D for it.

I've been so busy trying to prepare for PRGE this year that I have put off some of the things I wanted to do in this realm. One example of that is to let programmers know how to support dual POKEY on HOKEY in your games and demos, while also supporting other dual POKEY implementations. For many reasons, mostly because I wanted to fit HOKEY into a standard POKEY socket without a form factor bigger than a real POKEY, and did not want to require extra connections outside the POKEY's normal pins (the A4 address line is not available on POKEY's footprint), dual POKEY on a HOKEY is supported with a form of bankswitching. The bankswitching is transparent to other POKEY replacements (or a real POKEY), and to HOKEY, $440 and $450 (for instance) would be mirrors. So here is how it works: Stores to the $440 or $450 mirrors will each go to HOKEY's 16-byte address space. To switch the current POKEY, store a 0 or 1 to offset $0D in POKEY address space, so $45D would work in this example. On a real POKEY, offset $0D is a holding register for SIO, and storing there would have no effect on other POKEY implementations in the 7800 realm. It's also pretty inconsequential to store there even when outside the 7800 realm, as I doubt anyone is using music and SIO at the same time. So all you need to do is store a zero to $45D before any group of writes to $44x, and a store 1 to $45D before a group of writes to $45x, and everything will work on HOKEY and any of the current dual POKEY implementations. Hopefully that makes sense.

HOKEY supports dual POKEY, so I can try this demo in a bit and see how it works there. HOKEY use a transparent form of bankswitching to support two POKEYs in the addressable space of 16 bytes, and responds equally to $440 or $450, so a properly-written program will work on either HOKEY or other dual-POKEY implementations with separate address space.

I did a deep dig into an old hard drive and found this. Apparently, an F6 conversion for the game. thwockf6.bin

I found the problem with this demo. As I suspected, the fault appears to be in the demo's programming, and that it's not really a fault in the Concerto. The problem is that they are putting the DLL in cart ROM. According to GCC, the DLL needs to go in system RAM only - it should never go in cart ROM. As a result, I expect that this demo won't work on most real hardware, and would fail on most cartridge boards. I know I said above that GCC said not to put character maps in ROM either but programmers do anyway, but the worst thing character maps in ROM will do is cause graphics glitches, but the game will otherwise work, so this isn't that big of a deal. Putting the DLL in ROM, however, will likely crash the system, as we are seeing here, and the access time is likely to be a much bigger problem. That being said, I expect that the CEM device will also allow this demo to function on systems where it otherwise crashes - though, I would not consider this a "fix" because DLL in ROM is not something we should expect any hardware to support.

Well, a general method for dumping arbitrary CDFJ games isn't possible, but it is possible to support most individual CDFJ games. Of course, having to explicitly support each individual game means that only existing (e.g, finished) games can be supported, so I am modifying the CDFJ driver so that future arbitrary CDFJ games can be supported, and that new games in development can be tested.

I tried this on four different Concertos and it worked perfectly on every one of them. It didn't even need the CEM device to work (one did have minor graphics glitches, but they didn't affect the program running.) However, a cursory look at the binary reveals a lot of weird programming, so I think it's possible, or maybe even likely, that the problem is with the demo itself and not the hardware you are trying to run it on. I will investigate this further and see what else I can find.

Essentially. It's a a port of the original bupchip sound code. In any case, it will not be using ADPCM samples.