Jump to content
IGNORED

Designing a cartridge that supports 100% C/C++ game development


Recommended Posts

  • 2 weeks later...

Through some experimentation I confirmed that allowing the PC to go from $1FFF to $2000 will result in the address at $0000 being read. So it would seem that only 4KB of ROM space can be accessed before the 6507 is given a JMP $1000 instruction. So it looks like it's not possible to send a full frames worth of register updates without having a few JMP instructions sprinkled throughout.

 

Is there some clever way to avoid having to issue a JMP instruction in order to keep the PC in the ROM address space?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

I'm hoping you can pull this off. Seems like you're kicking butt. I know nothing about hardware but would like a crack at programming for this. I looked into running code in the Harmony ARM back when I first heard there was a Harmony cart and heard also what you posted...not many cycles left.

 

When thinking of doing a game on an ARM I did come to the conclusion that if I did that I may as well just skip the VCS and target a PC instead....but I still think it'd be pretty cool to see what a super charged VCS could do. So I'd sure be interested in writing for this when you're ready. I'd also be interested in licensing your design and/or buying boards when you're ready.

 

Wish list: It would be really cool from my perspective if a board could be designed that could do both a standard EPROM or Sara or something AND the ARM...even if a few jumpers are needed or some traces cut. I have no idea if that would be possible but it'd be nice to order one large batch of boards and be able to produce either type.

 

One interesting thing from my perspective is that a game written for the VCS using your ARM scheme would be closer to being an easier port to desktops, pads, phones.

 

My 2 cents on C++...

I have experience with 6502, C/C++ and making frameworks. Been doing C++ for 15-20 years and I've been working on my own app framework for many years that was originally used to make PC/Mac games. A strange thing has recently happened...I'm not liking C++ anymore. I still like OOP but even that is starting to seem like a Model T. The problem started recently when trying to imagine what programming would be like in 100 years. I'm moving more back to C in order to implement more advanced features....which is kind of how C++ was first implemented. My point is if you find yourself fighting C++ you could consider just C. Lots of people look at C as old and Assembly as medieval and that C++ is easier but I'm not so sure that's true. Seems like a lot of C++ programmers think C++ is easier but only because they know very little about C++.

 

I've been working on a VCS development system and if that could help with your project I'd be willing to help. Mostly I spend time on the framework, but the goal is a cool dev sys.

  • Like 4
Link to comment
Share on other sites

I'm hoping you can pull this off. Seems like you're kicking butt. I know nothing about hardware but would like a crack at programming for this. I looked into running code in the Harmony ARM back when I first heard there was a Harmony cart and heard also what you posted...not many cycles left.

Have you seen my blog series DPC+ ARM Development? It's up to part 12, though currently on the back burner due to RL. I plan to resume it after CGF.

 

When thinking of doing a game on an ARM I did come to the conclusion that if I did that I may as well just skip the VCS and target a PC instead....

There's still the TIA limitations to deal with around how to use the limited abilities to create even more complex games like Draconian (my take on Bosconian). My blog series on it shows what's going on behind the scenes, like the kernel which updates all 5 moveable objects on every scan line, along with being able to reposition an object (any one of the 5) on ever single scan line.

Link to comment
Share on other sites

I hadn't seen your blog series,. Just read it. Very cool, thanks.

 

I'm not too keen to program for Harmony because I was unable to find a way to produce carts. Having carts to sell would be half the fun for me. So I'm hoping ZackAttack will be open to licensing.

Link to comment
Share on other sites

My 2 cents on C++...

I have experience with 6502, C/C++ and making frameworks. Been doing C++ for 15-20 years and I've been working on my own app framework for many years that was originally used to make PC/Mac games. A strange thing has recently happened...I'm not liking C++ anymore. I still like OOP but even that is starting to seem like a Model T. The problem started recently when trying to imagine what programming would be like in 100 years. I'm moving more back to C in order to implement more advanced features....which is kind of how C++ was first implemented. My point is if you find yourself fighting C++ you could consider just C. Lots of people look at C as old and Assembly as medieval and that C++ is easier but I'm not so sure that's true. Seems like a lot of C++ programmers think C++ is easier but only because they know very little about C++.

 

Funny, that's more or less the same development cycle I've been through (but with other tools). OOP never helped me writing cool stuff.

 

I do think this project is interesting from a hardware point of view.

Edited by roland p
  • Like 1
Link to comment
Share on other sites

Dan, are you more interested in just "overclocking" the 2600 (like SpiceWare), or are you more interested in development on real hardware? I am having a hard time figuring it out and I am mostly just curious. I saw your other post about the software to the devkit you used back then.

Link to comment
Share on other sites

I'm not too keen to program for Harmony because I was unable to find a way to produce carts. Having carts to sell would be half the fun for me.

 

Melody is Harmony, only difference between the two is the Harmony cartridge has a daughterboard plugged in. The daughterboard contains the SD card reader, USB port, and I believe extra flash ROM which holds the various bankswitch drivers and menu software.

 

Any game that's written to utilize the features of the Harmony can be sold as a stand-alone game using Melody. Chetiry, Epic Adventure, Seaweed Assault, Space Rocks and Stay Frosty 2 are all examples of this - some used just extra RAM, some for DPC+ bankswitching (updated version of the DPC coprocessor used in Pitfall II), and some use DPC+ with ARM.

Link to comment
Share on other sites

I'm hoping you can pull this off. Seems like you're kicking butt. I know nothing about hardware but would like a crack at programming for this. I looked into running code in the Harmony ARM back when I first heard there was a Harmony cart and heard also what you posted...not many cycles left.

Thanks. I was hoping to be further along by now, but the custom hardware is proving more difficult to implement than I anticipated.

 

When thinking of doing a game on an ARM I did come to the conclusion that if I did that I may as well just skip the VCS and target a PC instead....but I still think it'd be pretty cool to see what a super charged VCS could do. So I'd sure be interested in writing for this when you're ready. I'd also be interested in licensing your design and/or buying boards when you're ready.

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.

 

Wish list: It would be really cool from my perspective if a board could be designed that could do both a standard EPROM or Sara or something AND the ARM...even if a few jumpers are needed or some traces cut. I have no idea if that would be possible but it'd be nice to order one large batch of boards and be able to produce either type.

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

 

One interesting thing from my perspective is that a game written for the VCS using your ARM scheme would be closer to being an easier port to desktops, pads, phones.

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.

 

My 2 cents on C++...

I have experience with 6502, C/C++ and making frameworks. Been doing C++ for 15-20 years and I've been working on my own app framework for many years that was originally used to make PC/Mac games. A strange thing has recently happened...I'm not liking C++ anymore. I still like OOP but even that is starting to seem like a Model T. The problem started recently when trying to imagine what programming would be like in 100 years. I'm moving more back to C in order to implement more advanced features....which is kind of how C++ was first implemented. My point is if you find yourself fighting C++ you could consider just C. Lots of people look at C as old and Assembly as medieval and that C++ is easier but I'm not so sure that's true. Seems like a lot of C++ programmers think C++ is easier but only because they know very little about C++.

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.

 

I've been working on a VCS development system and if that could help with your project I'd be willing to help. Mostly I spend time on the framework, but the goal is a cool dev sys.

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.

 

 

There's still the TIA limitations to deal with around how to use the limited abilities to create even more complex games like Draconian (my take on Bosconian). My blog series on it shows what's going on behind the scenes, like the kernel which updates all 5 moveable objects on every scan line, along with being able to reposition an object (any one of the 5) on ever single scan line.

Excellent point. Even with all the extra digital horsepower, the games will still have that 8 bit VCS feel to them.

 

Melody is Harmony, only difference between the two is the Harmony cartridge has a daughterboard plugged in. The daughterboard contains the SD card reader, USB port, and I believe extra flash ROM which holds the various bankswitch drivers and menu software.

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.

  • Like 1
Link to comment
Share on other sites

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.

The issues with Melody have all been fixed.

 

The limitations of Melody are just like that of the 2600, in that you do your programming during overscan and vertical blanking and the chip is busy during the active screen. So, maybe 20-25% of the actual frame is available for C code. If I have read this right, this design would avail the ARM for 100% of the frame. Right?

 

It should be noted that Melody is cheap and simple, a single-chip design. I don't know how many chips this will have (7-8 maybe?) but you're certainly going to be hitting a much higher price point.

 

However, I'm unclear if this is actually an SD flashcart like Harmony? I see the SD card in the block diagram. If that's the case then certainly you can target that higher price point.

Link to comment
Share on other sites

The issues with Melody have all been fixed.

 

The limitations of Melody are just like that of the 2600, in that you do your programming during overscan and vertical blanking and the chip is busy during the active screen. So, maybe 20-25% of the actual frame is available for C code. If I have read this right, this design would avail the ARM for 100% of the frame. Right?

 

It should be noted that Melody is cheap and simple, a single-chip design. I don't know how many chips this will have (7-8 maybe?) but you're certainly going to be hitting a much higher price point.

 

However, I'm unclear if this is actually an SD flashcart like Harmony? I see the SD card in the block diagram. If that's the case then certainly you can target that higher price point.

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.

Link to comment
Share on other sites

Dan, are you more interested in just "overclocking" the 2600 (like SpiceWare), or are you more interested in development on real hardware? I am having a hard time figuring it out and I am mostly just curious. I saw your other post about the software to the devkit you used back then.

Real hardware I assume is like a 4k board?

 

The biggest issue is getting my hands on a board that I could put a game on and get into production. Board availability has really been driving what board I target. If ZackAttack can get this working, get a prototype board working, is willing to license it I'm pretty sure I'd be all in. If I could figure out how to get a Sara board made I'd target that. Bank switch board, same deal.

 

I was interested in Harmony/Melody but the more I learned (whether valid or not) the less interested I became and went back to targeting some kind of EPROM board.

Link to comment
Share on other sites

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.

That's the way I look at it too. I assume we're not talking about a huge amount. If such a board cost say $15 more than a 4k board but allowed for more CPU bandwidth better graphics, a chance to do the best game ever on the VCS...sign me up. If price is really an issue I'd rather just sell the cart, even a bare board, no manual, no box.

Link to comment
Share on other sites

Real hardware I assume is like a 4k board?

 

The biggest issue is getting my hands on a board that I could put a game on and get into production. Board availability has really been driving what board I target. If ZackAttack can get this working, get a prototype board working, is willing to license it I'm pretty sure I'd be all in. If I could figure out how to get a Sara board made I'd target that. Bank switch board, same deal.

 

I was interested in Harmony/Melody but the more I learned (whether valid or not) the less interested I became and went back to targeting some kind of EPROM board.

 

No, I was not talking about custom bankswitching, everyone could do that back in the day. Forget it, you seem to be a bit touchy on this. All good.

Link to comment
Share on other sites

I was interested in Harmony/Melody but the more I learned (whether valid or not) the less interested I became and went back to targeting some kind of EPROM board.

The Harmony/Melody is super flexible in what you can do with it. The way the cartridge works is:

 

6507 <--> ARM <--> Flash (ROM) and SRAM (RAM)

 

So the ARM emulates everything about the cartridge, even for a simple 4K game.

 

If I could figure out how to get a Sara board made I'd target that. Bank switch board, same deal.

ARM code is already written for the Harmony/Melody to emulate a number of bank switch formats, with or without extra RAM like the Sara board:

post-3056-0-64892800-1434897475_thumb.png

 

You'll notice DPC+ is not one of the formats listed - BIOS update 1.05 for the Harmony added support for custom bankswitch formats. For those you give up some of the ROM space for the ARM code that drives the custom format - that's why DPC+ is limited to 28K of ROM (utilized as 6 x 4K banks plus 4K Display Data).

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

Any updates on your excellent work, ZackAttack?

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.

Link to comment
Share on other sites

  • 5 weeks later...

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.

 

post-40226-0-47246900-1441299561_thumb.png

	//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);
  • Like 3
Link to comment
Share on other sites

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.

 

post-40226-0-04991500-1441341564_thumb.png

  • Like 4
Link to comment
Share on other sites

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?

Edited by ZackAttack
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...