ZackAttack

I'm not too familiar with this situation. Are you saying the project is bigger than it needs to be due to compatibility with Diablo specific hardware? I looked into this some more and found that adding 7800 support is going to increase the size over 128KB even with the savings from switching to arm based text kernels. For now, it seems the easiest solution is to compile the non-critical functions with -Os instead of -O3. I tried this with a few of the larger files and was able to save a few KB. Eventually we may need to move some stuff out of the firmware, but for now playing with -O at the file level seems to be a viable solution.

The switch to the arm based 36char kernel should free up the 2K used by the 3 regions of firmware rom. Of course, the 36char kernel will take up some of that, but it should be much less.

That's a good idea. We could reserve 3 lines for the full name. 108 characters should be plenty. Maybe even do the scrolling as well. Activating the submenu with a long button press sounds good. I think we'd want to stay on the submenu after the long press is released. There can be links to go back or start game.

I do like the option of having a suffix to provide a manual override. That can always be handy to work around issues with the feature. My proposal would be a simple .noexit suffix like this: MyGameFile.noexit.bin. Then the menu code would remove the .noexit from the display name and put a "no exit" icon on the left most character. We could make that a special 7 pixel wide character and anchor it in place. I like the idea of providing a menu before launching a ROM so users can configure options like 2600/7800 mode, exit/no exit, online/offline, etc. I'm not sure how the Harmony does it. I was thinking it would be done by scrolling the filename horizontally when it exceeds 36 characters. Maybe only scroll the selected line? Whatever we decide, I can include it in the work I'm doing for 7800 support. That already has me making significant changes to the menu system and exit rom routines.

This is what the score could look like if we put it all on one line. The lives remaining can either be as it is or replace it with 1-3 sprites when the total lives are 3 or less.

@Al_Nafuur I've approved the PR, but left the merging for you to complete.

I can review it now.

Ah, you're right. I totally forgot that there are two colors per line in the mattress region. Sorry about that. To keep things simple, let's draw carpet, bedpost, and sheet with COLUBK and mattress with PF. We can make the bedposts 12 pixels wide and align them with the PF. I tested this out in Gopher2600 with the hmove triggered every line to mask the left 8 pixels. Level 1 is a little asymmetric, but I think it's an acceptable compromise in order to keep things moving along. It should also be much less noticeable in the final render. Here's a screenshot. Difficulty levels are represented by each respective third of the screen. Bedposts are in brown, carpet in pink, sheets change color twice per third and triangles are the mattress. Diagonal line made of PF is just for reference.

You don't have to line up the color change if you draw the bed posts with COLUBK and change COLUPF inside the bedpost. That means carpet and bed are PF and bedposts are background. Then you have a few cycles where the color change can happen without visual artifacts. I was also thinking it could probably be done without ARM, but I'm going to go the ARM route because it's quicker and makes it much easier to create a 7800 version later on. I created a repository for it in github and put together the minimum code to draw an asymmetric PF. I'll continue to add more here and there until the display kernels are complete. You'll need arm-none-eabi toolset to build and Uno or Plus carts with UCA 2.3.14 or higher firmware to run it. You can also run it in Gopher2600 if you build Gopher2600 from the latest source. ZacharyScolaro/waterbed-bouncers-2600: https://forums.atariage.com/topic/344323-fluid-simulation-for-new-2600-game-concept/ (github.com)

Theres only a few file types that support 7800 mode, so I was thinking of basing it on file extension to avoid the overhead of parsing file headers for each file. a78, e78, and eds would be for Atari 7800, elf 7800, and elf dual system file types respectively. a78 and e78 are 7800 only, eds is both, and everything else would be treated as 2600 only. I was also learning towards option 1 (Hide any files that can't be run until a power cycle unlocks again.), but my only concern is that it could be confusing to have the contents of the folder change after you exit the first rom. Maybe we do 1, but also show notice the first time you return to menu that the system is now locked in whichever mode and that some files will be hidden until you power cycle. I was going to add a loading progress percentage for the 7800 mode, we can update the percentage for every n bytes that are downloaded. We could do the same for 2600 eventually once we sort out DMA and IRQs.

Using STA, STX, STY, and SAX to limit stuffing to 6 bits is a main part of it. I think @batari was who suggested it. It also tests stuffing low over high and vice versa because we found that some bits on some systems only work one way or the other. Bus-stuffing is implemented in the latest UCA firmware. You can review the vcsInitBusStuffing() function in United-Carts-of-Atari/vcsLib.c at main · Al-Nafuur/United-Carts-of-Atari (github.com) to see exactly how it works. You are correct that A, X, and Y must be a certain value when using the vcsWrite() function. This is accomplished by calling vcsLda2(), vcsLdx2(), and vcsLdy2() respectively. I'll try to post an example project to demonstrate the use of these functions soon. Really, this whole topic should be updated soon since the introduction of the elf format with UCA firmware v2.3.14 makes it possible to use GCC directly. It's much easier to build now and no longer requires the use of the STM IDE. In the meantime, there are a few projects to reference in United-Carts-of-Atari/source/ElfTests at main · Al-Nafuur/United-Carts-of-Atari (github.com) Just have arm-none-eabi version of GCC and run make to build. You will need an Uno or Plus cart with Unified firmware 2.3.14 or higher, or Gopher2600 built from the latest source to run the resulting binaries.

I think it's probably possible without bus-stuffing, but it's nice to know we can!

I was asking so we could create a repository for the code in github. How about waterbed-bouncers for the project name? The title can be whatever you decide on later. You're the one making the title screen, right? 😁

I've been working on adding the ability to boot the Uno and Plus carts as a 7800 cart and I'd appreciate some feedback on potential implementations of the menu system. Some background info: When the system is powered on the cart will detect if it is in a 2600 or 7800. When cart is in a 7800 it will pass the BIOS checks and take over execution as a 7800 cart. Before the TIA can be accessed the console must be locked into either 2600 or 7800 mode. In 7800 mode everything but audio can be accomplished without locking the console into 7800 mode. Once locked into a mode, a power cycle of the console is the only way to unlock. TLDR; Everything but audio can be done in the menu, but once a ROM is loaded the cart will be limited to 2600 or 7800 until the next power cycle. There are a few options to consider. Prompt the player with a choice of modes when powered on and immediately lock it to either 2600 or 7800 only. Add a user setting to determine locking behavior. Always start as 7800 unlocked, and lock to whichever console is chosen first. If the selected ROM supports both modes, default to the 7800 mode. Once locked to a mode, we need to restrict the menu somehow. Hide any files that can't be run until a power cycle unlocks again. Show all files but have some GUI indicator that they are locked out and prevent selection. The menu system in 7800 mode uses 8x12 glyphs. The screen resolution for text is 320x192 (PAL is taller). For now, the 2600 fonts will be used scaled to double the width. The 7800 has enough RAM to hold a full page of text. This allows the text to remain on screen while loading from SD/WIFI.

Sorry, I was trying to ask if it would make sense to implement a more standardized form of BASIC. I wasn't trying to suggest you needed to make your specific kernel available to everyone. Something DPC+ like is a good idea. I should start a new topic for a UAC version of BASIC. Not sure which forum would be the best place to put it though.

@8bitPoet Do you have a title or project name for it? Any devs, comfortable with C, interesting in collaboration? I think I could throw together most of the display kernel fairly quickly.

From a gameplay perspective this looks like a winner. From a technical perspective it looks completely feasible. Here on my thoughts on how this could be achieved. The fan can be done by using a player for the down rod and light and playfield for the blades. The bonus items can use the same player repositioned in the vertical space between the fan and the fruit. The fly can use the ball Monkeys use one player each, but since only one of them flies up at a time, they only consume both players on the bottom of the screen. Curves for the headboard and the mattress can be done with background color changes and playfield. Left and right edges of the mattress can be smoothed with a missile and player being moved since only one monkey reaches that region at a time. The score and lives remaining can use the 18 characters kernel (36 character with double width glyphs) This would translate well to the 320-pixel wide mode of the 7800. The curves will be super smooth.

Would it be worth it to split from bB and implement something more general? With a finite collection of canned 2600 display kernels, we could mirror each with an equivalent 7800 display kernel. Then developers would just need to have an asset folder for each system to build games that run in both 2600 and 7800 modes.

Once the naming poll closes, the plan is to move the codebase to github and create a backlog where we can keep track of feature requests. These can be added there once it's ready. Seems like for UnoCart it should always start up within the SD card content if the SD card is available since the normal use case is to play games. Perhaps we can avoid adding an option for it.

Just posted the beta for this.

If you watched the Nov 24th ZeroPage Homebrew Twitch Stream, then you know a new version of firmware for the Uno and Plus carts is in the works. Today I'm happy to announce the beta availability of version 2.3.14 of the common firmware for the UnoCart. New Features Relocatable ELF file format Allows a single bin file that can be used with Chameleon, Uno, and Plus carts. Bus stuffing support ACE-UF00 file format Allows a single bin file that can be used with Uno and Plus carts. Used by Lord of Biscay RPG demo (Awesome playable demo by @MarcoJ) Menu option to disable/enable exit on Right+Reset. This option defaults to enabled when system is powered off and then on again. Reduced loading times of ACE format files 17to2.3.14.bin- Upgrades from v17 of the original Uno firmware to v2.3.14 of the new common codebase firmware. DO NOT POWER OFF UNTIL "UPDATE COMPLETE" IS SHOWN UnoCart_2.3.14.binUnoCart_2.3.14.elf- Files to program directly with ST-LINK. Useful if you did not heed the warning above and bricked your cart UnifiedToLegacy17.ace- Downgrade from v2.3.14 or higher of the common codebase firmware back to the original Unocart firmware. Just in case you want/need to roll back the upgrade. Here's a link to the show in case you missed it.

There may be other factors involved. I have not yet reviewed the entire USB application notes to validate the current design.

I think we also need to include an external oscillator for the USB to work properly. The built in RC based oscillator is not accurate.

License looks straight forward. Putting everything in github should make it compliant. Some of those capacitors will need to be moved closer to their corresponding ICs. I think it would be a good idea to bring the esp-01 pins out to the pin header as well. Could make programming and debugging a lot easier. There's plenty of room to add the SPI flash. Any objection to losing the redundant D0-D7 connections? With the latest firmware that shouldn't be necessary, and I'd be concerned about it potentially interfering with bus stuffing.

I like this!