ZackAttack

Did you try moving those files and changing the extension? You should be able to get the batch file to do it for you.

It's been a while, but if I remember correctly bB and vbB put the bin files in different locations. One of the two moves the bin file into a \bin folder. -l"%~p1\bin\%~n1%~x1.lst" would handle the scenario where the .bin file was moved to the \bin folder. If that's not the case then there is no need to add \bin\ to the path and that can simply become -l"%~f1.lst" and -s"%~f1.sym". The important thing is that the .sym, .lst, and .bin files are all in the same place once the build is complete. Then stella will find the lst and sym files needed for labels in the debugger. See this post for more details about what the %~?1 is doing. In summary, try this instead: dasm "%~f1.asm" -I"%bB%"/includes -f3 -l"%~f1.lst" -s"%~f1.sym" -o"%~f1.bin" | bbfilter Please let us know if that works. I don't have bB or vbB installed on this computer so I'm unable to verify at the moment.

This post should help.

You don't need to write any code for this. Just use the stella debugger. Set a break point before and after the section of code you want to profile and take note of the "F. Cycle" value at each breakpoint. Of course, this will only tell you how many cycles a routine takes for whichever code path is executed. It may not necessarily reflect the worst case scenario or the average. You'd really need to analyze the generated assembly listing to determine that.

Since this is a prototype bus stuffing driver you can only run this bin on an actual harmony cart. Rather than having a full frame buffer it only stores the color and height for each of the 40 columns. There should be plenty of resources left to make an actual game. The quantity of sprites will be severely limited though because the only way to reposition them will be via HMOVE. Joe's demo was used as a reference for some of the fixed point math implementation. Latest Version: raycaster-2018-6-15.bin - Fixed vertical bar glitches Previous Versions: Raycaster_2018_06_13.bin

Maybe there is a difference between the charge time of paddle controllers and the sega controllers which can be used to distinguish them?

I really like this idea, but I'm concerned that it would make the game unloadable on SD carts like harmony and uno. Perhaps if we allocate 128KB to firmware on the uno there would be enough room for a zip and json library. I was thinking it would be nice to provide additional scheme information in a more explicit way for some of the fancier roms. I. E. 3e with 48KB ROM and 24KB of RAM. But, yeah, there would be cases where the offset just points to the header that's embedded in the bin. Would be really cool to capture the screenshot as a frame worth of 6502 execution so it could be replayed on hardware. You could have a slideshow mode to select which game to play. URL good, DRM bad. If you want DRM just make it fit in the MCU and enable memory protection. There's a lot of potential here, but it's not part of the critical path for implementing MegaFlex or ARM Custom Executables. So let's shelve the metadata discussion for now and revisit it when someone is available to work on it.

The basic idea is to run everything on the ARM chip in the cart and feed the VCS with a small subset of its instruction set so it's easy to keep track of the 6507 CPU state. The result is a few C functions that look suspiciously like 6507 instructions. There's just enough room to do some extra work in between function calls so it makes it possible to capture some ARM cycles that were previously lost during active frame rendering. Of course this requires a cart with an ARM chip and is therefore limited to 32K on the harmony carts. The good news is that someone else released an opensource cart which includes a much more powerful MCU. Once I've updated the firmware and ported over the driver it should be possible to make ARM enhanced games as large as 448K. You can see it in action now if you have a harmony cart. I posted a demo back in December which demonstrates a C kernel in action.

Ok, this is a great idea. I'm in. What I'm proposing is an optional VCS Metadata header which when present can enhance the user experience by providing metadata and a small icon to use in menu programs. More complex schemes like the ones we're working on can have an additional structure in the file which may or may not be part of the embedded bin. In theory we can retroactively apply this header to existing ROMs. The menu program can detect if all the files in a folder contain thumbnails and switch to thumbnail view automatically. I just added a header file to my fork. Let me know what you think.

Would you be as interested in C/C++? I've been working on new frameworks which make writing the display kernels in C possible.

Perhaps there could be a routine that you can call which specifies a region of RAM to be copied to ROM or SD card depending on how the game was loaded. You'd have to reduce the game size by however much you intend to save in order to fit it into flash.

Noted. ROM size will be limited to 448KB. If the file is larger than that it will need to handle its own loading for everything over 448KB. The custom ARM code can just stomp on the firmware's memory since it will not transfer control back to the firmware. How the memory is used will be entirely implementation defined. I was mostly thinking it would be nice to know how much RAM is used for emulation and future hardware design purposes. Thanks for pointing out the CCM. I'll have a field for RAM data size, and RAM code size to make this more useful. Great, I was hoping there would be some routine that could be reused for this. I think it would also be good if the header includes a magic number and the file size and is embedded in the beginning of the file. Then the firmware could detect the presence of a game in flash and automatically run it if there is no SD card present.

Stella will enforce the limitations of the 2600 and whichever banking scheme you use. DASM is going to enforce ROM size too since you'll run into trouble if your code is too big to fit before the reset vector at the end of the ROM. Stella is awesome, but no emulator is perfect. You do need to test on real hardware eventually. The more clever you get, especially with regard to TIA, the more frequently you need to test on real hardware. If you're serious about making a homebrew, a programmable cart such as the Uno or Harmony is a must buy. You should check out SpiceWare's Collect tutorial. He'll walk you through creating a complete game in assembly with excellent explanations along the way.

Actually, forget I said anything about 1MB. I don't want the hardware to be any more difficult or expensive than it needs to be and I also don't want to create a situation where there are games that only work for some of the Uno Cart owners. I'll restrict my rom usage to 448KB (64KB for firmware). If a game needs to be larger than that it can make use of the SD card or some other form of external flash memory.

I was thinking betas and trials too. If shipping only 1mb isn't possible it's not a big deal. Either way this is going to be a beast. Has a 512k variant already made it into the wild?

If possible you should only use 1mb for sd based carts and save the 512k for publishing homebrews. Since the SD card is more suitable for development it makes sense to give it the extra storage.

Received my cart from MacRorie over the weekend flashed the new firmware and finally got to hear those test ROMs running on actual hardware! A couple of notes for anyone else who needs to upgrade their firmware. Programmer software can be downloaded for free from ST's site by clicking "Get Software" at the bottom right. The USB programmer can be bought from amazon prime for less than $10. I used 3 short lengths of hookup wire to connect from the programmer leads to the PCB. I think it's solid core 22awg or 24awg wire. @MacRorie, IMO it would have been nice if the connector on the cart was a 3 pin male connector like the jumper connector used for TV mode selection. The bin files needed to be renamed to have a .3f extension in order to work with this version of the firmware. My first attempt kept the .bin extension and resulted in a bad rom error. The whole operation takes just a few minutes and should be easy enough for just about anyone. BACK TO THE FUTURE!!!!

I think the MegaFlex scheme that DirtyHairy is working on is probably what you're looking for here. We do want to have some form of bB support for that one. What I'm proposing would support saving to a save file on the SD card of saving to built in flash for non SD card variants. In theory you could enhance the cart hardware to battery back up some of the RAM, but that would add to the cost of each cart. Really once you're executing custom ARM code you can do whatever you want with the hardware. I'm just trying to figure out what the best way to get to the point where the custom ARM code is running.

The project is feasible, but you're going to have to learn a ton about Atari 2600 programming before you make any real progress. To accomplish a 1 player mode you will need to understand how to disassemble and reverse engineer the existing game, how to implement bank switching to make room for the AI, how to program in assembly to write the AI, and a million other skills I'm probably forgetting. Btw, I think there's a dedicated hacking forum though I'm not sure if that's technical or just a place to post hacks. Why not start off with one of the several good tutorials on 2600 programming? Then focus on disassembling this game. I think you're months away from even attempting to modify it. I took a quick look at it and don't see this as being a quick one or two byte change. You're going to need to produce a buildable disassembly to get anywhere with this. Another good starting point would be to try hacking colors or graphics. That's probably just data and could be done directly in stella. SWCHB is the port you read for console switches. For player joysticks you need SWCHA. For the second player button you need INPT5. For what you're trying to do it needs to be SWCHA since the second player button is not used for defense selection.

I'm going to implement a new scheme for the UnoCart firmware to enable custom ARM code execution. This is what I have in mind, please let me know how I can improve it. Create a new file type with its own header and extension Put a driver uuid and version fields in header to make life easier for emulators Specify ROM size in header up to 512KB. Specify RAM size in header up to 192KB. Specify ROM checksum in header. Use ROM checksum to avoid reflashing ROM if the selected game is already there. Load 6507 routine into zeropage and pull D0-D7 high with built in Pull-up resistors so 6507 can run on its own while ROM is being loaded. Once program is ready it will pull D0-D7 low to signal a jump to $f000 Store the full file path in RAM before handing control over to the game so it can load additional data from files larger than 512KB. Also, enables games to save to themselves or a similarly named save file.

A 2k ROM mirrored to 4k could use bit 12 of PC.

My vote is for MegaFlex. I not a big fan of naming things after myself. Besides CTZ sounds like some sort of Cadillac.

Obviously the other objects are what you have to collide with to set the collision flags. Despite this being the dumbest thing you could probably do with the VCS, you could actually sacrifice some objects to gain a few more bits of memory. At least it sounds feasible in theory. Position the ball to whatever value you'd like to retain (0-159), disable the ball during field rendering and enable it in overscan, use PF and/or P0 to find the current position of the ball. Don't forget collisions are only detected when vblank is disabled. So you'd need to color everything black during the detection phase to avoid visible artifacts. Of course in practice you will run out of the 5 objects before you run out of the 128 bytes of RAM, that guy clearly has no grasp of reality, and there almost is certainly no game that has ever or will ever attempt to do this. But you could if you wanted to Actual Fun Fact: Coloring everything black and using collision registers to readback the value of a TIA register is used by the bus stuffing driver to detect which data bits can be successfully bus stuffed or not.

I would think we'd just have the same page mapped to two slots.