ZackAttack

If you're not going to use WSYNC then you need to make sure your kernel is an exact multiple of 76 cycles. Looks like you're 3 cycles short which probably results in everything looking wrong. I'm not sure that the timing on the PF writes is acceptable either. You may be updating them with the right side data before they've completed the left side. An easy way to check is to draw the left side all on and the right side all off. Stella debugger will definitely be your new best friend.

It's pretty obvious at this point that I've done a terrible job at communicating in my first post. Please allow my to clarify some things. The term false advertising is used in a technical sense. If it turns out that this is a case of false advertising, I'm sure it was the result of an honest mistake and would never suspect anyone related to the harmony product of intentionally misleading customers. There's actually a more specific term which is used when it was intentional, but I'll refrain from using it here to avoid having it associated with the harmony product. I have no idea if the user batari is managed by a single person or multiple people involved with the product. I only mentioned that I messaged batari directly to make others aware that I tried the official support channel before posting to the forum. I have recommended this product to others on the forum in the past and will continue you to do so after making them aware of this minor potential limitation. I thought I should offer some possible solutions since I was reporting what I perceive as a problem. I never meant for this to be taken as a list of demands. After reading some of the replies I now see how this is speaking on behalf of others. Sorry about that. If and when I get permission to edit that post I will remove this portion of the post to make things right.

Have you considered drawing some of those with missiles it balls? You can draw basic things with resizing and moving them.

It's attached to the other post that I linked in the original post. Omegamatrix was nice enough to make another 3E test rom, which is also attached in that topic, but neither of us have had a chance to test the harmony with his yet. Here's a direct link to the test ROMs. 3E_tests.zip Thanks. I'll look into making another 512KB test program with the Arcadia Supercharger bank switch type and report back the result.

I'm not sure what you're trying to accomplish, but it might be useful to know that you can coarse position and draw a player on the same line if you enable multiple copies. The first copy won't be drawn, but the second and third would be. There is also a RESP trick which can be used to draw more than 3 copies of the player per line. Circus AtariAge is a good example of that.

The test roms that I originally posted use one page of RAM. So I limited it to 510KB of ROM in order to keep the total at 512KB. So I guess really it's a 34KB program that's working since the 32KB bin file is the one that worked on the harmony. I'll try the 512KB bin that you posted sometime this weekend. Btw, stella will auto detect a 3e game if you put HEX 85 3e a9 00 in the image.

Thanks for taking a look. According to the kevtris blog using the TIA mirrors is only necessary for 3F. It also doesn't explain why my 32KB test program doesn't crash too. Would it be a valid test to take your 32K rom and concatenate it with itself to create a 64K test ROM? Of course if that works we could continue to double it up to 512K for testing purposes.

If you read my post carefully you'll see that myself and others have tested with 3E bank switched ROMs which are larger than 32KB and which work in stella but do not work with the encore. So your analogy is wrong because it implies no one has ever had in their possession 1 million dollars to test with. I don't know that it doesn't work for sure. However, as the other post shows, I'm not the only one that ran into the problem and I was pretty careful about how I tested it. This is a product that is specifically advertised to support it. I think it's quite reasonable that the burden of proof is on the vendor. I provided the same program with multiple ROM sizes to show that 3E games work fine if they are 32KB. That is certainly not my intention. I simply want an already good product to do everything it was advertised to do when I purchased it.

I've previously posted about getting a larger game to work on the Harmony Encore and also messaged Batari directly. There has been no reply to either. The website couldn't state it any more clearly that up to 512KB games are supported, but I have yet to find any documentation on how to make such a game or any examples of such games already existing. Does the encore really have support for 512KB homebrews or is this a case of false advertising? I'd like to propose some potential remedies to this situation. (ordered by my preference) Provide an example 512KB ROM which can be run on the harmony encore. Provide a new firmware release which adds support for 512KB games. This must be done in a timely manner. My opinion is that 6 months or less would be reasonable. Open source the firmware so the community can add support for 512KB games. Provide a partial refund for all harmony encore owners with an amount similar to what it costs to upgrade form a regular harmony to the encore.

Interesting. I got those errors too, but didn't notice before because DASM keeps going and generates a working bin file for me. My build script automatically runs the bin so I don't bother looking at the output if stella pops open with a working program. The macro below couldn't be expanded in the first two passes, so it takes up 0 bytes. Then after SPRITE_HEIGHT is calculated it evaluates the REPEAT macro and causes an extra 18 bytes to be inserted into the bin, moving the location of everything after it. I've reordered things to prevent this problem. I assume you guys are using a different OS or different version of DASM, and that's why the error failed the build completely for you, but not me. REPEAT SPRITE_HEIGHT BYTE $ff REPEND Here's an updated asm file that should build for you too. mask_draw_demo3.asm

If you run into any more problems, please attach the asm file instead of pasting it's contents into your post. You have to use the "More Reply Options" to attach files to your post. DASM treats any line without white space as a label and wouldn't assemble what you pasted above because most of the indentation got lost. It appears as though all the leading tabs were removed at some point.

I took those sprites from the free sprites thread and didn't notice that they were more than 8 bits wide. So yeah, let's just call that a bug in the example code.

I'm not sure what you mean by slice. Atari doesn't have the notion of sprites built in. It keeps drawing the 8 bit wide player graphic every line. So you create a sprite by changing the GRP0 register each line, or every other line in 2lk. The height is controlled by the software you can make the Sprite as tall as the screen if you want.

Yeah it's using the frame count to index into the array of graphic pointers to produce the animation effect. You're correct, that's reserving ram for the different variables. Pointers need two bytes of course.

Happy to help. Just for fun I went ahead and optimized for the 1LK variant. The mask only takes 256 bytes because it exploits the natural wrap around of the 8 bit Y register. Keeping everything aligned properly is critical to avoiding a 1 cycle penalty for crossing pages. So the net is a couple bytes of RAM, 150 bytes of ROM, and 2 cycles during the kernel. Of course a 2LK will consume much less ROM space for mask and graphics and single colored sprites would save a bunch of resources too. mask_draw_demo.asm

Don't have time to comment it for you. If the code isn't self explanatory, feel free to ask some follow up questions. I left out some optimizations for the sake of reduced complexity, if you intend to have a single kernel for the entire screen the mask could be reduced to 256 bytes. mask_draw_demo.asm mask_draw_demo.bin

I'm not sure that's severe enough punishment. Perhaps we could make a custom cart with some switches to program it one byte at a time and require them to use that for all future development. Of course it would be stored in RAM so you have to program it again if you cut the power.

You know, with bus stuffing something like this could probably be achievable. Though it would be helpful to replace rings with something that can be drawn with missiles and balls too. Like coins, bananas, apples, etc. Or ditch the smooth scrolling and it's super simple to implement.

I assumed that there would be some modules which can be mixed and matched. That's why I suggested wrapping them in header files with some sweet preproc magic to fix up the offsets of everything. Each module header would know how big it is and would calculate offsets for its symbols based on some global modules size variable after which it would increase the global modules size by the amount of itself. Regarding debugging. Users of Spice C shouldn't need to debug the prebuilt kernels. You could do what I do for strong-arm and have a special debug cart class which runs win/Linux/mac binary and then you just build it as part of stella and debug it that way. This is how I'm developing Wushu Masters. I do everything in visual studio and only bother building for ARM when I'm ready to test on actual hardware. Of course you could just as easily use eclipse, gdb, or whatever other toolchain that is capable of building/debugging stella source.

Just a thought here. Since all the 6502 code is going to be part of the framework. Why not just include it as bins which can be pulled into the C build. That way users of Spice C don't have to configure dasm at all. You build the C files and it spits out the 32KB file. It should be fairly simple to accomplish with a few header files, some preprocessor directives, and maybe some linker script magic.

You meant 40 PF pixels right?

I think you might be able to mock this up in batari basic pretty quickly. It might be worth a try so you can get a better feel for the limitations of the system. For what you describe I believe the Multisprite Kernel with a HUD is what you want. If you prefer to go the assembly route you can do better graphics, but it's going to take longer to learn what you can do and how to do it.

That looks reasonable. I think you also need to consider how the sprites will move (horizontally, vertically, both etc.), cart hardware you plan to use, and which programming language/tools you're comfortable with.

With the right framework C will make programming the Atari more accessible since it'll be a standardized language that many people already know. bB is a very specialized version of basic. A VB.net programmer couldn't just pick it up and start writing a game immediately without first learning some things about the Atari. C also leaves the possibility of using more modern IDEs and having source level debugging. Little things like conditional breakpoints can be huge time savers. This is no longer true. I write my display kernels in C code that runs on the ARM chip and use the time in between emulating the ROM to calculate the next few bytes of ROM on the fly. It's kind of like having a display kernel which is made up of only LDA# STA tia_reg repeated over and over, but instead of hardcoding it in ROM you create it dynamically just before it's executed by the Atari. I have this concern too and recognize that there will be people that compare a game built in 2018 with an ARM chip to a game built with only 2K of ROM back in the day. But I've also considered that someone is going to keep pushing the limits of what a 2600 cart can do. So I might as well join in with the fun and just make it a point to educate people that newer technology in the cart allows for visuals that were once impossible on the system. Besides no matter how much processing power there is on the cart, you still can't overcome the limitations of the TIA.