Search the Community

*** UPDATE 08/18/2023 *** This project has been superseded by the newer elf format and should not be used for any new projects. I'm currently working on some comprehensive libraries for parsing assets, fixed point math, collision detection and more. C++ Libraries and examples will be posted once ready. For now, you may reference the elf tests embedded in the UCA repository here: United-Carts-of-Atari/source/ElfTests at main · Al-Nafuur/United-Carts-of-Atari · GitHub.

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

I think I've achieved horizontal playfield scrolling with via bus stuffing and the Strong-ARM driver. If you have a harmony cartridge please try it out. Current Version: Cherry-Tree-Scroll3.bin - 1/25/18 Optimized driver with lookup table and self modifying ARM code, fixed graphic data glitch Past Failures: Cherry-Tree-Scroll2.bin - 1/6/18 disables VBLANK during stuff detection because collision registers won't be set if VBLANK is enabled. Cherry-Tree-Scroll.bin Not supported in emulators yet. Here's what it looks like for those who don't have a harmony cart.

Here is a ROM that uses the power of the Harmony cart to display 10 colored sprites per line. It uses a prototype driver that isn't supported in emulation so you'll have to put it on a Harmony cart to run it. I'd like to get some feedback on how well this works on different systems. I've tested on a NTSC JR and 7800 and the results were good. Thanks to rbairos for providing the converted audio and graphics. Current Build: back-to-the-future4.bin Edit: 12/18/2017 - Uploaded version 4 with proper driver fix and an additional second of audio samples Edit: 12/16/2017 - Uploaded version 3 with extra nops to increase hold time Older Builds: back-to-the-future3.bin I've included a picture of it running for those who don't have a harmony and would like to see. There's more to it than what's in the picture though, so I'd recommend running it if you have the hardware handy. Here is the code for the display kernel. It's pretty messy due to the extreme optimization and complete misuse of the 6507 JSR instruction. In order to compensate for artifacts from the JSR instruction the ball is used to mask some pixels. There wasn't enough time to both resize it and enable it every scan line. So CTRLPF is used to do both by changing the size and the PF priority. The ball is always enabled, but it is shown or hidden based on the PF priority. Since JSR is used to write to GRP1 and GRP0 it's called a second time to write to AUDV1 and AUDV0. This allows for 5bit sampled audio, though this demo is only using 4 bits because of space constraints. After the GRP and AUD registers are written to a TXS is performed to reset the SP back to GRP1. The X register is preloaded with the address GRP1 in vblank and remains that value during the entire frame. Y is used for the color of the right most sprite and is loaded on the previous scan line. JSR values are computed by subtracting the number of bytes consumed by the instructions until the next JSR. Each JSR is effectively loading the values that will be stored in the next JSR when the PC gets pushed to the stack. The JSR must always target an address in the ROM. So D12 is always set. Because there are about 30 bytes between each JSR there are some values which require D11 to be set as well in order to avoid starting outside of ROM space. This is why 0x800 is added if D12 was cleared by the previous subtraction. This also increases the ball size to 2 so it covers both pixels represented by D12 and D11. Whether or not the ball was enabled was determined by D12 in the original value. There is a slight artifact if you have the second to last sprite with the pattern xxx1000 and the last sprite has a value less than 32 or so. In this case you end up with xxx1100. There simply isn't enough time to move the ball over one in order to mask just D11, so D11 remains visible. This is a very small percentage of the time and isn't very noticeable so it should be acceptable. It takes about 6 lines of vblank and overscan to fill the audio buffer, position objects, and initialize everything for the next frame. The 6507 runs a routine from ZP RAM for the other 64 lines. This routine updates the audio registers and performs the vsync. During those 64 lines the ARM CPU is currently idle. All the display kernel lookups are done between putting bytes on the 6507 data bus. Hopefully this provides enough time to load in more data from the EEPROM or the SD card. It at least provides ample time for some game logic and audio calculations though. Eventually I'll be posting the entire source to GitHub for everyone to enjoy, but I want to stabilize the design some more first. for(; i < 192;) { // Left group starts cycle 0 vcsJsr6(jsrl); // G, I Graphics <-e1 results in I=$ff vcsWrite5(GRP0, pGraphics[i*10]); // A graphic vcsWrite5(GRP1, pGraphics[i * 10 + 2]); // C graphic vcsWrite5(GRP0, pGraphics[i * 10 + 4]); // E graphic vcsWrite5(COLUP0, pColors[i * 10 + 0] << 1); // A color vcslda2(pColors[i * 10 + 2] << 1); // C color vcssta4(COLUP1); // C color vcslda2(pColors[i * 10 + 4] << 1); // E color vcstxs2(); // Should be 36 cycles prior to here vcssta3(COLUP0); // E color vcslda2(pColors[i * 10 + 6] << 1); // G Color - 41 // 0x20 - 23 = 0x09 => sample will offset range by 0-15 giving 0x20-0x2f vcsJsr6(0x1009 + ((sampleOffset & 1) ? pAudioSamples[sampleOffset >> 1] >> 4 : (pAudioSamples[sampleOffset >> 1] & 0xf))); sampleOffset++; vcssta3(COLUP1); // G Color vcssta3(GRP1); // Flush delay register vcssty3(COLUP0); // I Color - 56 i++; jsrr = (((unsigned short)pGraphics[i * 10 + 7]) << | pGraphics[i * 10 + 9]; // H and J graphics bytes vcsWrite5(HMP0, 0x80); ctrlpfr = ((jsrr & 0x1000) >> 10) ^ 0x5; vcssta3(HMP1); jsrr = (jsrr | 0x1000) - 33; //31 bytes between JSRs vcssta4(HMBL); if ((jsrr & 0x1000) == 0) { jsrr += 0x800; ctrlpfr |= 0x10; } vcsldy2(pColors[i * 10 + 9] << 1); // J Color vcsWrite5(HMOVE, 2); StaggeredFrame: if (i >= 192) { break; } // Right group starts cycle -1 vcsJsr6(jsrr); // H, J Graphics <-de results in J=$ff vcsWrite5(GRP0, pGraphics[i * 10 + 1]); // B graphic vcsWrite5(GRP1, pGraphics[i * 10 + 3]); // D graphic vcsWrite5(GRP0, pGraphics[i * 10 + 5]); // F graphic vcsWrite5(COLUP0, pColors[i * 10 + 1] << 1); // B color vcsWrite5(COLUP1, pColors[i * 10 + 3] << 1); // D color vcslda2(ctrlpfr); vcssta3(CTRLPF); vcslda2(pColors[i * 10 + 5] << 1); // F color vcstxs2(); // Should be 39 cycles prior to here vcssta3(COLUP0); // F color vcslda2(pColors[i * 10 + 7] << 1); // H Color - 44 // 0x20 - 22 = 0x0a => sample will offset range by 0-15 giving 0x20-0x2f vcsJsr6(0x100a + ((sampleOffset & 1) ? pAudioSamples[sampleOffset >> 1] >> 4 : (pAudioSamples[sampleOffset >> 1] & 0xf))); sampleOffset++; i++; jsrl = (((unsigned short)pGraphics[i * 10 + 6]) << | pGraphics[i * 10 + 8]; // G and I graphics bytes vcssta3(COLUP1); // H Color ctrlpfl = ((jsrl & 0x1000) >> 10) ^ 0x5; vcssta3(GRP1); // Flush delay register jsrl = (jsrl | 0x1000) - 30; //28 bytes between JSRs vcssty3(COLUP0); // J Color - 59 if ((jsrl & 0x1000) == 0) { jsrl += 0x800; ctrlpfl |= 0x10; } vcsWrite5(CTRLPF, ctrlpfl); vcsWrite5(HMCLR, 0x00); vcsWrite5(HMOVE, 2); vcsldy2(pColors[i * 10 + 8] << 1); // I Color }