ZackAttack

I tried a completely different approach from scratch today and still I end up with 4 gaps. On the plus side the gaps are all close to the left side. So I could chop it off at the second gap and have around 130 pixels @ 30Hz. Think I'm going to table this until I have the hardware to test with. That way I can be sure I'm not just fighting stella.

Originally I had 5 gaps, but I did fill one with a missile. The problem I'm having with doing that is that I'm using tripled players NUSIZ setting for both players and thus also both missiles. In the case where I did use the missile I had an extra write at just the right time to disable the missile before its 2 copies got drawn.

I've been trying to leverage bus stuffing to create a 160x192 single color image with 30hz flicker. I've got it to the point that all but 4 columns are drawn using 30hz flicker. For the remaining 4 columns I can only fill in the gaps with the ball object. This unfortunately requires 15hz flicker for those 4 columns. My test bitmap doesn't exactly look great in stella and I'm waiting on some parts to arrive before I can test this on real hardware. Do you think the 15hz flicker could be overlooked considering the potential for having a full 160x192 frame buffer to draw to?

I think as you become more familiar with programming the system, especially if you go the assembly route, you will find that the true limitation of the system is how often and when a TIA register can be written to. Limiting rom size will mostly just limit the amount of game content you can fit in. Writing a solid 4k game is an admirable goal, but I hope you keep an open mind when it comes to utilizing more complex cart hardware. At the end of the day you can give a 4k and 32k cart to a user and they will only judge them on gameplay and graphics. That said. Welcome to the forum. I'm sure whatever cart technology you work with will be a fun and challenging experience.

Yes, that is indeed excessive. I'm guessing that my cartridge will draw about 100ma. It's not like a raspberry pi would fit inside a cart anyway. Why not just use an external power supply for it? It's been my experience that you can supply 5V to the Atari through the cartridge port and it will run just fine without the Atari being plugged in. Which is useful for allowing an external device to hard reset the system.

After thinking about how to simulate the FPGA behavior for generating buffer empty interrupts and other low level actions that will need to be handled by the ARM MCU I've come to the conclusion that some basic ARM code should be baked into the cartridge. That way instead of having to deal with hardware interrupts and stuff, you can just write against a simple API. VCS<FPGA<ARM<OS<API<[GameFramework]<YourGameCodeHere Here is my proposal for the first version of the API layer. void OnStartup(void * apiContext, void * fpGetFunction) The OnStartup function is implemented by the game code and exported from the dll so it can be called by the API after the system initialization is complete. A pointer to the GetFunction() function is provided so the game code can request function pointers for the rest of the API. This will allow new functions to be added in the future without breaking existing game programs. void * GetFunction(int Id) Returns a function pointer to the API function that corresponds to the requested Id. Null is returned for invalid Ids. void CreateBuffer(void * apiContext, int size, CommandBuffer & buffer) Allocates a new command buffer that can hold as many as <size> commands and returns a CmdBuffer structure which is used to read and write commands from the buffer. void ActivateBuffer(void * apiContext, int id, int commandCount) This is a blocking call that will return once the provided buffer has become active. Once a buffer is actively being used it is no longer safe to write new commands to the buffer. If all the commands in a buffer have been completed before ActivateBuffer is called again, the active buffer will be reactivated and all its commands will be executed again. bool GetReadResult(void * apiContext, uInt8 & value) If the read result queue is empty false is returned. Otherwise the address and value are set based on the next available result from the read result queue. Poll this function if you need the result of a read command before proceeding. pseudo code for consuming the API: OnStartup() { GetPointersForAllUsedFunctions(); CreateBuffers(); //GameLoop while(GameRunning) { DrawScreen(); ActivateBuffer(); ReadInputs(); UpdateGameState(); } } Thoughts? Suggestions?

Just for fun I wrote a small C# program to convert bmp files into a set of commands. The algorithm I'm using to map colors to the VCS palette is pretty awful. The results are still pretty neat. Everything is drawn only using the playfield. There are still plenty of cycles left to draw some players too thanks to the bus stuffing. Each image was converted to a 40x192 size. The leftmost 4 PF pixels have to be the same color per scan line, and then every 6 PF pixels after that must use the same color per scan line.

Made some more progress. Stella can now simulate the fpga hardware that translates the command queue into 6502 instructions. The screenshot isn't very impressive, but it's generated from the code below which is entirely in c++. Right now it's just pulling the commands from a static queue. Next up is simulating sniffing values off the data bus. //Build command queue std::vector<uInt8> queue; //3 Lines of VSYNC Write3(queue, VSYNC, 2); // make sure we don't reflect playfield Write3(queue, CTRLPF, 0); for (int i = 0; i < 37; i++) { Write3(queue, WSYNC, 0xff); } Write3(queue, VSYNC, 0); //40 lines total of VBLANK for (int i = 0; i < 37; i++) { Write3(queue, WSYNC, 0xff); } Write3(queue, VBLANK, 0); //Now we're drawing screen //Draw 192 scanlines for (int i = 0; i < 192; i++) { Write3(queue, COLUBK, i); Write3(queue, WSYNC, 0xff); } //overscan //Enable VBLANK Write3(queue, VBLANK, 2); for (int i = 0; i < 30; i++) { Write3(queue, WSYNC, 0xff); } //JMP back to $f000 because the ROM address space is limited Jmp(queue);

Cleary you have excellent taste in sailboats. Looking forward to see where you go with this game. I'm sure the finished graphics will be amazing.

Not sure if you realized this or not. It is possible to create an asymmetric playfield instead of repeating or mirroring the left half. It just requires a kernel that updates the PF registers twice each scan line. The drawback to doing this is that you don't have much time to update the rest of the graphics. A common compromise is to only update the PF1 and PF2 registers twice while leaving the left and right 4 PF pixels blank. This gets you a 32 pixel wide playfield with only 4 PF register writes instead of the 6 that are required for a full asymmetric playfield.

Real life has been getting in the way a lot lately. I have been working on it a little bit here and there though. The current task is modifying stella to emulate the c++ cartridge. I decided to get it working in stella first so I can have test programs and data to assist with the creation of the hardware. Once I have something running in stella I'll post an update. Until then there isn't really much to see, unless you like browsing git logs.

I'd just copy the vcs.h that you used and put an extra comment on the top to inform everyone where it came from and where to get the latest version should they want to use it for their own project. Worrying about the licensing of vcs.h seems a bit silly imo.

Perhaps with macros you could make it into an emulator

I hope you're able to keep all the backgrounds without losing any resolution. They look really good. Are you using or planning to use DPC+ for this?

Off to a great start! Have you thought about how you're going to implement the AI? That should be pretty interesting.

I was basing my guess at you being new to programming off your post count not your progress. I actually think Yoshi's house looks pretty good and assumed the Mario sprite was just a place holder for a colored sprite later on.

Since the 6507 cycle is 3 TIA cycles and each PF pixel is 4 TIA cycles there should be a spot where you can strobe RESP0/1 and have them be in alignment. Once they are in alignment you can strobe RESP0/1 every 36 TIA cycles (12 CPU cycles) to keep them in aligned. Ball missiles and background could be used to fill in the 4 pixel gap between each player graphic.

If you're new to programming I'd recommend starting off with a smaller and simpler project before you try to tackle a demake of SMW. You'll need to have an understanding of game engines and level editors for this project.

Source level debugging would be nice.

What was the idea that won't work?

Couldn't you just check the X coordinate in addition to the collision flag?

Cool, glad to hear you got that worked out. This design will definitely have a higher cost than the melody board. The chip count of the finished design will only be 2-3. All the 74ls chips will be replaced by the FPGA. The prototype has to use them because the fpga dev board has diodes wired to all the I/O pins which would pull the busses to 3.3V if they were directly connected to it. I also did it that way because it's a lot cheaper to replace a 74ls chip than an Atari. I think the higher price point will be ok if it has DRM support that allows the games to be purchased as digital downloads or as SD cards. That way you only have to buy the expensive part once. It should coexist nicely with the harmony/melody this way. Of course you could still release a version of it with no SD support to make it a more authentic collectors item like the in box copies sold on this site. You just better have an awesome game to justify the price premium.

Thanks. I was hoping to be further along by now, but the custom hardware is proving more difficult to implement than I anticipated. I plan to release all of my work under one of the "Do whatever you want with this" type licenses. I may also do a run of boards if there is enough demand. It would probably be possible to replace the ARM with some a ROM or flash memory and just program the FPGA differently. The biggest obstacle here would probably be the cost of building the non-ARM version. It would be hard to justify the extra expense without the extra capabilities that the ARM version provides I'm counting on that in order to enable using Visual Studio and other IDEs to develop VCS games. It could go both ways too. A framework for creating vintage looking smartphone apps could be made available which produces VCS compatible projects. The FPGA and ARM microntroller are loosely coupled. It wouldn't be difficult to replace the ARM with any other programming device as long as some basic UART support exists. It's not really tied to a specific language either. Most of my professional experience is in C# and I would love to have a C# version available one day. This sounds very similar to what I'm hoping to acheive. Any help is greatly appreciated. I'll send you a PM to discuss further. Excellent point. Even with all the extra digital horsepower, the games will still have that 8 bit VCS feel to them. That's an important difference though. I remember seeing a thread about how some of the melody games didn't work on all systems, but the same games worked fine on the harmony. It has me thinking that a small battery to keep the FPGA initialized during console power cycles would be a good idea. That way the FPGA initialization doesn't have to race the 6507 reset delay.

Well if you jump every scan line you lose the time it takes to write to a register. Sure only having 24 register writes instead of 25 isn't that big of a deal. If you only jump every 4000 bytes it makes the program more difficult to write. I wonder if it would be noticeable if I skipped an audio sample every 80 scan lines in order to make space for the jmp.