Jump to content

About This Club

A Club for the PlusCart user, and those who want to become a PlusCart user
  1. What's new in this club
  2. I'm cleaning up the store and unsure as to what I want to do with all the older builds of games. Should we scrap them and keep the newest or keep some of them around so people can play older builds of games.
  3. It will not work. The firmware file generated by the unified codebase only contains the firmware and not the firmware updater. The original UnoCart firmware doesn't has a internal firmware update function, so a new firmware has to be included into a ACE bankswitching file which includes the firmware update function. For the UnoCart the firmware bin file is just a normal ROM, but the detection will not match a bankswitching so you will get an error after loading the bin file.
  4. I'm using Unocar on v.17, I don't have this ST-Link programmer. My doubt is, would it be too risky to update directly from the bin file? Has anyone done this and it went well or lost the cart because of it? If the firmware update has a crash, with corrupted data, is there a way to recover Unocart? Thanks
  5. Add a new section to the manual about sharing folders with other users. https://pluscart.firmaplus.de/pico/?Manual#share-folders
  6. Ah well, the spinner -> sprite, and margin stuff proved to be very straightforward, so that's working in the standalone testbed anyway. So now it's on to the frame timing/synch stuff. The vid shows the margins as @alex_79 suggested, and the spinner as a sprite (roughly) centered in the screen. I did like it top-left, but now it can be anywhere. You can see how the transition (the same size margin) will look. Now uses mirrored PF and masking of pf2 (black) to get the borders the same. The changes were very simple. On to the synching issue... plus.mp4
  7. It is what it is because I didn't rewrite, but took the original code and made incremental changes and now it is what it is. I agree that use of a sprite would be much better, and I'll look into it. As with these things, it's a hobby and doing stuff for other people sometimes seems like... work
  8. Thanks for the explanation. Maybe you could use a (quad size) sprite instead of PF1 for the spinning logo? That way you aren't tied to a specific horizontal position. The sprite position, color, as well as PF0 color and data for masking the sides could be set before jumping to the zero page code. But I totally agree that masking the sides is just a very minor cosmetic improvement and doesn't justifies extensive rewrite of the code.
  9. I've had a quick look at this. It's been a while. The "spinner" code that performs a wait loop while the address BUS is inactive (i.e., while the PlusCart is away in the cloud building up the next menu display frame) lives in Zero page. It is very tight; 119 of 121 available bytes are in use. I suspect one of the issues is that the frame size (#scanlines) for this is hardwired, and probably not the same size as the menu frame. There may be other issues related to OS/VB timing; I only had a brief look. The tight usage of ZP means that I can't index to have variable frame size as used for the menu frame, however the fact that it lives in zero page means that I can do some self-modifying trickery which might fix that particular issue. I will try and put aside some time to looking into this soonish. As to the masking of the spinner screen sides; a brief look at it makes the logo look odd because it now becomes (+1 pixel) left-edge aligned to a black edge. It's only a single PF write (PF1) and there's not enough zeropage space to do two writes (PF1/PF2) in the kernel. To create the mask would need SP0/SP1 or similar bands on the sides, in black. Can't use PF because it's coloured white and there's no time/room for colour changes. Starts to become a lot of fiddling for not a lot of functionality. So, I think that's not gonna happen.
  10. Apart from fixing the sync, I think the switching would look better and less noticeable if you mask the sides of the "wait" screen background with the playfield just like in the text kernel, so that they both have the same horizontal size.
  11. Added PlusCart Discord channel invitation link.
  12. BTW, I had a quick look at the disassemblies of "Combat", "Air Sea Battle" and "Start Ship" and it doesn't seem to me that the bit stored into SWCHB is ever read back. The PAL versions of "Combat" and "Air Sea Battle" don't have that code at all. ("Star Ship" is NTSC only). EDIT: It looks like in all three games bit 4 of SWCHB is just set to "1" during gameplay and to "0" in attract mode, but the same info is also stored in a ram location which is what the code actually checks.
  13. there have been several options discussed in this thread: But I think the easiest solution is a switch in the "Setup" menu to disable the exit function (temporary or permanent). ? If we modify the ROMs we might as well make them compatible with the exit function.
  14. I'd like to have that option, too. Perhaps a specific data string that could be scanned for upon ROM load that, if present, would disable the exit code? The downside though would be the extra bytes needed with some ROMs that may be completely full.
  15. The PlusCart exit function is a feature which lets the user exit a game when he presses Reset and holds the joystick to the right (or presses the first paddle button) at the same time. This works fine with most of the games, but a few of the games cannot be exited, because they are not reading SWCHA and SWCHB during all game states. Some of the games are writing to SWCHA/SWCHB and thus might accidentally trigger the exit function. With "Combat" and "Air Sea Battle" this is not a big issue, because the user is still able to play the game if he just don't moves the joystick to the right in demo mode. But very few games arn't playable with the PlusCart, because the exit function is being triggered during the game or when starting the game.
  16. I only happened to discover this because the 2600 I was working on, was sent to me specifically due to issue with player 2's trigger being constantly active. Air Sea Battle made it easy to see the issue because as soon as I pressed reset to start the game, player 2 was constantly shooting. Replaced the 4050 to correct this. But yeah, since the controllers still control the cannons in demo mode, I quickly found out that pressing right on player 1's controller in demo would cause the the Plus cart to reset back to the plus cart menu. So this is a known thing then already I take it and I just wasn't aware?
  17. It does indeed write to SWCHB at address $f325. Bit 4 is set as output, just like "Combat" and "Air Sea Battle".
  18. It is mentioned in several places that "Combat" also uses SWCHB as extra storage. Anyway I remember that I had a look at the code a while ago, and those writes to the RIOT Port B didn't seem to have any real purpose in that game either. These two games were in development while the 2600 console hardware design was still in flux, and maybe that's some leftover code that was needed in an early revision of the console. Or it was used to provide some reference signal in those pins that could be probed with a scope or other diagnostic/debugging device.
  19. @-^CrossBow^- reported on the ZPH stream yesterday, that "Air Sea Battle" is affected by the unintentional triggering of the exit function in demo mode as soon as the joystick is moved to the right. As far as I can see in Stella SWCHB is written at $0177 in the ROM The value written to SWCHB is the ZP RAM location $97 (which had the value $00 during my tests). The cartridge can not determine if it is a read or write to SWCHB so the value $00 is interpreted as the SWCHB state. So it looks like the Reset button is pressed for the exit function. I don't know why SWCHB is written here ( 3 bits can be used as storage), but I am not sure if this is really necessary for this 2K game or if it is a bug or unnecessary code I have hacked a test Version where the write is redirected to the origin ZP RAM location ($0097): /Public ROMs/Classic Roms/NTSC/BY ALPHABET/A-G/Air-Sea Battle - Fix Target Fun.bin It seems to work fine..
  20. ?‍♂️ No. @batari gave us some tips for the implementation of DPC+ on the PlusCart/UnoCart MCU, but also did not offer the driver source code directly:
  21. Ah, I didn't realize PlusCart and Harmony/Melody are competitive products. Did you ask for the sources?
  22. Definitely yes. Yes Any help is gladly appreciated. Recompiling the custom ARM code is not the biggest problem at the moment. The biggest difficulty is the CDFJ/DPC+ driver for the UnoCart/PlusCart MCU. The original drivers are not open source, so there is not much to help us other than the open source code of the emulators. Me too ?
  23. Hi, I was wondering if CDFJ support is still on the radar? I guess it requires assembly-support in PlusCart and then existing games need to be recompiled for the specific ARM chip in the PlusCart, right? Is this something @SpiceWare could provide some guidance on? Note: I have little knowledge on ARM, so forgive me if my questions are a bit ignorant.
  24.  
  • Recently Browsing   0 members

    • No registered users viewing this page.

×
×
  • Create New...