Jump to content

ZackAttack

Members
  • Posts

    851
  • Joined

Profile Information

  • Gender
    Male
  • Location
    Orlando, FL US

Recent Profile Visitors

10,127 profile views

ZackAttack's Achievements

Dragonstomper

Dragonstomper (6/9)

521

Reputation

  1. 95 is my best so far. The longer delays when the frog watches you really make for some nail-biting moments. I'm not even mad at him for eating me just before I broke into triple digits.
  2. Looks like the changes to the supercharger support in the standard firmware could be made in UCA pretty easily. I'll try to send you a new UCA build to test in the next week or so.
  3. I have some other work in progress that I want to complete before we release a new version. Unless you're seeing glitches/crashes there isn't much point in upgrading.
  4. Correct, currently it makes use of opcodes $84, $85, $86, and $87 It polls for the zero-page address that's being stuffed and puts the value on the bus right away. The value is stuffed until the next address is put on the address bus. Only 6 of 8 bits are stuffed. The other 2 are determined by which opcode is used and what the register values are.
  5. Has anyone considered how to handle the carts/games that do bus-stuffing yet? I think it would be possible to handle with a few extra ICs between the pi3 and the cart. When putting a new address on the bus, the data that may potentially be overridden by the cart is latched to an open collector buffer. Then read in the value from the cart just as you would from a ROM access. If no bus stuffing is taking place, you'll just read back the value you latched. Otherwise, the cart has free reign to pull additional bits low. If the pi3 was replaced with something that has a higher GPIO count, the data bus could be split so that 8 IOs are always outputting to the open collector and 8 IOs are always inputting the resulting bus value.
  6. Not difficult, but it shouldn't be necessary. The upgraders for firmwares only work for their own type. If you're on legacy/standard firmware v17 you can run v18 updater just fine, but you can't run any of the UCA updaters. If you're on a version of the UCA firmware you can run any of the UCS updaters, but you can't run any of the legacy/standard firmware updaters directly. To switch between the two types of firmware you should use the binaries I posted here. 17to2.3.14.bin is to convert any cart on v17 or higher of the standard/legacy firmware to UCA. UnifiedToLegacy17.ace is to convert any cart on UCA back to the standard/legacy firmware. After running either of those to switch which firmware you are using, you can then run the corresponding updates to get to the latest version.
  7. Would you be able to increase the capture rate and/or zoom in? I think you need to be on a scale of 50ns or less to really see what's going on. As far as writing the data bus too early. There is a required hold time where the data bus must remain valid for a short period after the address bus has already changed. If you're not holding for the required time, it would definitely cause problems.
  8. It's been so long, you probably just forgot about it. I got a little sidetracked with hardware development in my quest to make these ARM enhanced games publishable to carts, and then further sidetracked trying to make them support both 2600 and 7800. But thanks to recent collaborations there's been huge progress made and there should be some playable demos coming out later this year.
  9. Ironically, it's been the opposite for me. I tend to spend way more time than I should on the display kernels because this tech allows you to squeeze more out of the TIA. This is a huge understatement. I use Gopher 99% of the time and only bother testing on real hardware when I'm going to share a build with other pluscart users. How about compiling the game and emulator to webassembly and running it in web browsers? It might just be crazy enough to work.
  10. I think it could be helpful to test the timing of only polling for A12. Could you try the following and post the results? A logic analyzer on A12, D0, and A0-A5 would be ideal. If the logic analyzer shows the proper execution of the "lda ($b1),y" instructions, we can start adding in the remaining functionality one piece at a time. That will greatly simplify debugging because you can isolate each change and commit every time the test passes. #define A12_MASK 0x4000 #define MANGLE_DATA(data) ((data & 0b00011111) << 1 | (data & 0b11100000) << 3) static void Test() { // Be sure IRQ disabled __disable_irq(); // Preload data for Data Bus // Leave LDA ($b1),Y on the bus to create a nop-sled. Reset vector will be 0xb1b1 which provides some cycles to collect some timing data. // Eventually the PC will roll over and the Atari will crash. So logic analyzer and/or oscilliscope should trigger on the // First A12 rising edge after the Atari is powered on GPIOA->ODR = MANGLE_DATA(0xB1); // Bus Polling Loop while (1) { // Wait for A12 high while ((GPIOB->IDR & A12_MASK) == 0) ; // Drive Data Bus GPIOA->MODER = 0xa8150554; // 0b10101000000101010000010101010100; // Wait for A12 low while ((GPIOB->IDR & A12_MASK) != 0) ; // Release Data Bus GPIOA->MODER = 0xa0000000; // 0b10101000000000000000000000000000; } }
  11. I've done something similar with the Chameleon Cart. It's using a STM32G0. If you can point me to the code I could take a look and see if anything stands out. Embedding a 4k rom as a const uint8_t[4096] and a small while loop to service the bus should be all you need to get something running. Some things to check based on the pain of developing the Chameleon Cart: Disable IRQ. I've been burnt so many times by enabling them for something and forgetting to disable them again. Avoid initialization of large variables to keep boot time minimal. __attribute__((section(".noinit"))) static uint8_t playfieldBuffer[192*5]; It's fine to leave the 4k binary in flash memory. It's never been a problem for me. static const int8_t rom[4096]= {...}; The code that services the bus should be executed from RAM. The whole zerowaitstate flash gimmick works 99.9% and that .1% will crash ruin your day. Here's what I use when I want to do a quick check with 4K rom. __attribute__((long_call, section(".RamFunc"))) static void Emulate4K() { __disable_irq(); while (1) { if((GPIOB->IDR & 0x1000) != 0) // Assumes A0-A12 are wired to GPIOB0-12 respectively { GPIOA->MODER = DATA_OUT_MODER; // Masked with 0xfff to stay in 4kb array bounds. Can cast to int8/char if your hardware has better alignment GPIOA->ODR = ((int16_t)rom[GPIOB->IDR & 0xfff]) << 6; // Shift value depends on which GPIO pins are wired to data bus } else { GPIOA->MODER = DATA_IN_MODER; } } } Be aware that having the SWDIO/CLK pins on the same GPIO port as your Address Bus inputs can be problematic if you don't mask them away.
  12. Each track (ttt file) will have its own instruments and percussion. They can and should use both channels, but the second channel will be overridden with sound effects as needed.
  13. Yes, to swap in a new ttt file you would need to place a copy of the new ttt file in the assets/sound/ folder and replace 'glafouk - Miniblast.ttt' in source/parse_assets.py with the new file name. Then you should be able to run make to build it with the new music. That would be great. There's support for multiple ttt files in the same project, so all contributions are welcome and appreciated!
  14. @8bitPoet and I have been collaborating on a new game called Mattress Monkeys and could use some help with the background music. We only have a few remaining tasks before we can release a playable demo and would really like to have some original music to go with it. The audio engine is TIA Tracker based and there is a huge amount of storage space for audio data. Please let me know if you'd like to help out. Thanks! Perks include: Access to the latest build of the game Inclusion in credits screen A copy of the finished game cart Forum Topic: Fluid simulation for new 2600 game concept - Atari 2600 Programming - AtariAge Forums Code Repo: mattress-monkeys-2600 Recent Screen Shot:
  15. I assume you'd want a couple assembled PCBs in hand before you'd attempt this. Would it make sense to design the PCB to be as small as possible and fit inside a standard cart? But try to position the ports close to the top and side so there's the possibility of creating a 3d printable shell which exposes the ports? The only downside to this would be the 3d shell having a non standard shape and size. Maybe that would just make it more interesting.
×
×
  • Create New...