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

[Thomas Jentzsch]

So your plan is to bootleg the Harmony, or a similar design, rather than work with the people who created it?

If I understand Dan correctly, he has tried to work with them and it didn't work (of course this would not justify bootlegging).

[Andromeda Stardust]

Problem with open-sourcing the designs is people will bootleg the games. Krikzz has a very big problem with counterfeit Chinese Everdrives on eBay. He releases a firmware update then fans cry foul when they attempt to flash the bootleg copies and it bricks the device. Fortunately for all intents the Atari never existed in the far East so stuff like the Harmony/Melody boards have fallen under the radar. Same with AtariMax and others. Guys devolping these hardware devices did so at great expense and from their own pockets, so it is reasonable they expect to profit a little bit from them, and unreasonable that Dan wants to create his own supply. Dan Oliver will have to reinvent the wheel to some extent if he intends to develop a competing product, or agree to license terms if he uses Melody.

 

Outright cloning the Harmony design would be a dick move IMO but nothing stopping him or anyone else. There is no data encryption in the design. A cloned duplicate could easily be fabricated by cracking open a game, determining the bill of materials, and using a multimeter to trace the PCB, then using a software to reconstruct the layout. Then it's a matter of dumping and flashing the game + BIOS.

 

@Dan, if I could give you one piece of advice, it would be to produce a working game prototype (just a ROM developed using Harmony/Stella would be acceptible, or upload a gameplay video if you don't want it stolen) to prove yourself as a developer, then hardware people like Albert, CPUWIZ, Batari, et al might be more receptive to work with you. Do not attempt to "bootleg" the Melody. AtariAge is 90% of your market so you cannot risk a community boycott on your games.

[Mr SQL]

My goodness. The very last thing I would ever try is to convince anyone is that such things are possible. I don't know why anyone would have the need to try and convince me that such things are impossible. I do understand why people would try and convince themselves.

 

 

X2! Some of the same posters here advised me to study compiler design to write a BASIC and that there wasn't time for real time calculations in a soft blitter chip.

 

I read the Star Castle thread and saw the unfortunate backlash against Solidcorp - I'm more interested in seeing Alex build a fun game or Tom and Andrew create BoulderDash BASIC. And I'd like to see StarDust write a game in batari or Flashback BASIC, maybe with a custom controller in the box! (That would be fun to play and maketing theories could be tested).

 

And I'm highly interested in seeing what you and Solidcorp create next because you have the most potential to make interesting creations - not just because you are video game programmers from the 80's but mostly because you think you can.

[DanOliver]

Problem with open-sourcing the designs is people will bootleg the games. Krikzz has a very big problem with counterfeit Chinese Everdrives on eBay. He releases a firmware update then fans cry foul when they attempt to flash the bootleg copies and it bricks the device. Fortunately for all intents the Atari never existed in the far East so stuff like the Harmony/Melody boards have fallen under the radar. Same with AtariMax and others. Guys devolping these hardware devices did so at great expense and from their own pockets, so it is reasonable they expect to profit a little bit from them, and unreasonable that Dan wants to create his own supply. Dan Oliver will have to reinvent the wheel to some extent if he intends to develop a competing product, or agree to license terms if he uses Melody.

 

Outright cloning the Harmony design would be a dick move IMO but nothing stopping him or anyone else. There is no data encryption in the design. A cloned duplicate could easily be fabricated by cracking open a game, determining the bill of materials, and using a multimeter to trace the PCB, then using a software to reconstruct the layout. Then it's a matter of dumping and flashing the game + BIOS.

 

@Dan, if I could give you one piece of advice, it would be to produce a working game prototype (just a ROM developed using Harmony/Stella would be acceptible, or upload a gameplay video if you don't want it stolen) to prove yourself as a developer, then hardware people like Albert, CPUWIZ, Batari, et al might be more receptive to work with you. Do not attempt to "bootleg" the Melody. AtariAge is 90% of your market so you cannot risk a community boycott on your games.

Wow, I'm a bootlegger now. I guess it doesn't matter that I said ripping off Melody isn't a viable option, that a large part of the community would likely boycott (pretty sure I used the same words as you...but I 'm a bootlegger. More fun to read just the parts.

 

To prove myself as a developer...an interesting idea. I should consider that. Yes, and then the owners of Melody might consider working with me. Great advice if I were a veal calf.

 

Please excuse me from this discussion.

[Thomas Jentzsch]

Dan, maybe (or probably) we misunderstood your intentions. But you should not alienate people here. We are a small community, and nobody wins if we reject people who could be beneficial for our common hobby.

 

I get that you are frustrated by the situation and probably the feedback here too. But please, do yourself and us a favor and assume that by far the most people around here will support anyone who supports our hobby. People are just skeptical about your plans without anything to back up your reputation. Maybe you have some showcases of your previous enterprises you can show us? We have faced too many people with huge plans here (and in real life) that never even started.

[CPUWIZ]

EDIT: not even worth it.

[Mr SQL]

 

@Dan, if I could give you one piece of advice, it would be to produce a working game prototype (just a ROM developed using Harmony/Stella would be acceptible, or upload a gameplay video if you don't want it stolen) to prove yourself as a developer, then hardware people like Albert, CPUWIZ, Batari, et al might be more receptive to work with you. Do not attempt to "bootleg" the Melody. AtariAge is 90% of your market so you cannot risk a community boycott on your games.

 

That seems precocious considing you've already proven you enjoy Dan's Atari games when you placed the warez pirate copies of the game ROM's onto your Harmony cart - unless you also have his carts in your collection, in which case you're double proving you enjoy his games like many Atari fans do!

 

 

People are just skeptical about your plans without anything to back up your reputation. Maybe you have some showcases of your previous enterprises you can show us? We have faced too many people with huge plans here (and in real life) that never even started.

 

Suggesting Dan has nothing to back up his reputation was already disproven by Solidcorp's kickstarter; having written games in the 80's is a marketable attribute modern homebrewers do not have.

 

Why not be more encouraging and optimisic? You have the potential to accomplish more with your own development plans when you keep an open mind

[Andromeda Stardust]

@Dan, I'm not accusing you of bootlegging anything. I was using potential bootlegging operations as reasons why this homebrew hardware stuff is not open source. Harmony can run almost anything, DCP+ or not. So I suggest you get your hands wet and familiarize yourself with modern programming environments, whether Assembly, Batari Basic, or ARM (DCP+), testing on Stella for debuging and on a Harmony cart to ensure hardware compatibility. I think you will find it a lot easier than the vintage workflow back in the day.

 

Your games were great and you will make more great games. I suggest sticking to 6502 ASM if that's what you are most familiar with. You can get quite a lot of code in a typical 32 kbyte ROM.

[Andromeda Stardust]

 

And I'd like to see StarDust write a game in batari or Flashback BASIC, maybe with a custom controller in the box!

Well, there's trollface. I never got much past the "hello world" stage though.

http://atariage.com/forums/topic/218359-troll-face-my-first-atari-2600-rom/?p=2861882

[Mr SQL]

Well, there's trollface. I never got much past the "hello world" stage though.

http://atariage.com/forums/topic/218359-troll-face-my-first-atari-2600-rom/?p=2861882

 

Very cool Stardust, I like it! Keep writing creative programs, imo that is the path to building fun creative games

[ZackAttack]

I started thinking about how to architect this new driver. Regarding sound I think the easiest thing to do is assume there will be an audio buffer which is used to update AUDV0 onces per scanline. The last 5 scan lines of VBLANK should be dedicated to positioning the 5 moveable objects (P0, P1, M0, M1, BL). A few scanlines of overscan will probably be consumed with the overhead of jumping to the TIA RAM routine and calling the game program. There's 3 + 37 + 30 = 70 total scan lines outside of the actual tv picture. Subtract the scan lines that are consumed by positioning and function overhead and it's no more than 64. If we pack two 4bit audio samples into each byte we only need 32 bytes of RAM to hold the audio data during overscan and vblank. This leaves 96 bytes for the tv sync routine. It should also give about 3.8ms of uninterrupted ARM processing time.

 

By dynamically generating the 6502 instructions we can limit the set of instructions to just a few and make it possible to always predict what memory location the 6502 will access next. Rather than trying to poll the address bus for a change and then calculating what data value to put on the bus after the address has changed and been read we can calculate the next data value first and then as soon as the address changes put the new value on the bus and move on to the next instruction. This allows us to be at least one step ahead of the 6502 at all times. It also will free up some valuable arm cycles during the display kernel.

 

What's even cooler about this approach is that it opens the door for more dynamic display kernels. You can move writes to GRPx so they never occur at the same time the player is being drawn. PF scrolling at full resolution is free cause all the bit shifting can be done during the display kernel instead of during overscan. etc.

The overall execution would resemble this:

init:
    point reset vector to $f000
    initialize buss stuffing driver
    use non-bus stuffing writes to copy syncRoutine to TIA RAM at $00A0
    zero syncRoutineAudioBuffer ($0080-$009F

gameLoop:
    //Start of overscan
    enable vblank
    read controller inputs
    give control to 6507 // jmp $00A0 
    set timer to inturrpt just prior to syncRoutine completion
    if last frame missed deadline
        resume game code execution where it was interrupted
    else 
        call game code
    // At this point the ARM is running game code while the 6507 runs overscan and vblank from TIA RAM
    wait for syncRoutine to complete // PC = $f000
    // ARM has taken back control, 6507 is now a slave to dynamicly generated machine instructions
vblankEnding:
    update AUDV0 each scanline
    position objects during last 5 scanlines of VBLANK
    copy 32 bytes of audio samples to TIA RAM at $0080-$009F during the wasted cycles used to time the RESxx strobes
displayKernel:
    disable vblank
    draw the screen while continuing to update AUDV0 each scanline
    goto gameLoop

[ZackAttack]

Spiceware created an excellent blog about how to build a DPC+ game a while back. Referring to part 6 and the collect2 source from part 7 you will see that a DPC+ game is essentially the concatenation of the DPC+ driver, custom arm code, and 6507 assembly. These 3 sections are combined into a single 32kb file which becomes the game.bin file. The harmony cart must detect the presence of the DPC+ driver and then know to turn over execution to it. Since stella is open source and also properly detects DPC+ games it should be trivial to grok the stella code for the detection method and hopefully the entry point. Then we can modify the collect2 build to output a 32kb file which effectively cuts out the DPC+ driver and any 6502 assembly code. Once the build is set up we'll take what we learned from stella and implement it so harmony detects it as DPC+ and executes our entry point. To verify this is working we can simply toggle the MCU IO port between 0x00000000 and 0xffffffff and watch for it with the logic analyzer.

Once we have a good build and detection and entry point are working we can use trial and error to identify the portions of the IO port that are mapped to the data and address bus. Simply toggle one byte at a time and use the logic analyzer to map each byte to the corresponding VCS bus.

At tis point we should have DPC+ detection, entry point to arm code, and port mappings to VCS busses. From there we can start figuring out how to initialize the VCS from whatever state it's in when the entry point is called.

[ZackAttack]

Based on a review of the stella source there appears to be two signatures that may indicate to the harmony cart that a bin file contains executable arm code.

 

I looked at a DPC+ rom with a hex editor and found 0x10adab1e stored in little endian at offset 0x20 and "DPC+" in ascii at offset 0x328.

 

Here is the relevant function from the cart.cxx source file.

bool Cartridge::isProbablyDPCplus(const uInt8* image, uInt32 size)

{

  // DPC+ ARM code has 2 occurrences of the string DPC+

  // Note: all Harmony/Melody custom drivers also contain the value

  // 0x10adab1e (LOADABLE) if needed for future improvement

  uInt8 signature[] = { 'D', 'P', 'C', '+' };

  return searchForBytes(image, size, signature, 4, 2);

}

After reviewing the stella implementation of DPC+ it appears that the driver is simulated rather than executing it in an arm emulator. So there is no indication of where the entry point to the driver is. We probably need to fill the entire first 3KB with ARM NOPs and a very simple output routine at the end. Once that's verified with the logic analyzer a binary search can be performed to pinpoint the exact location of the entry point.

[ZackAttack]

I took apart my harmony cart and traced the edge connector signals back to the MCU with a multimeter. My conclusions are as follows.

 

6507 D0-D7 is wired to LPC2103 p0.8-p0.15

6507 A0-A12 is wired to LPC2103 p0.16-p0.28

 

There is also a ROM chip, FL208KI, which is wired to the SPI0 port. That's going to require further investigation at some point because the chip select signal goes through a solder jumper, SJ5, which is open on my harmony board.

 

A 512KB SRAM chip, AS6C4008, is also present. That's a mystery too since the LPC2103 lacks an external bus interface to quickly access external RAM.

 

 

[ZackAttack]

Here's what the harmony board looks like.

 

[+SpiceWare]

That surprised me, the SD slot and USB port used to be on a daughterboard plugged into a Melody board as seen in photo #3.

[ZackAttack]

Using this article as a reference I was able to put together a basic make file, linker script, and assembly source that generates a 32KB binary image. I then programmed a basic assembly program which should force the data bus low. In order to make it loadable on the harmony I put 8 NOPs to fill the first 32 bytes, followed by the 0x10adab1e magic number and another 128 NOPs to compensate for the unknown entry point. Finally there was the assembly to make the IO pins output 0 on bits 8-15. I built it and loaded it up on the harmony but it just got stuck at the loading spinner and the logic analyzer confirmed that the data bus was not forced low. Next I opened the test binary and a dpc+ binary in a hex editor and compared them. I noticed that there appeared to be a few more magic numbers adjacent to the loadable bytes. So I copied 16 bytes from offset 0x20 instead of 4. Built it again, ran it, and this time the loading spinner went away after a few seconds. I then confirmed with the logic analyzer that the data bus was being forced low and the address bus was still operating normally. The 6507 was operating as if it had an infinite stream of BRK instructions. What's interesting is that the 4 bytes at offset 0x28 is the 32bit value 0x4000008C which would be a fairly low address in the RAM. My guess is that this is how the bin image tells the harmony menu where the entry point for the game is. I plan to change it to a ROM location and remove the extra nops in order to verify that this is in fact how the entry point is specified. Another conclusion from this is that the loading spinner program is stored entirely in VCS RAM. Otherwise, it would have stopped when the ARM MCU went into a bad state. Will need to capture it in action via the logic analyzer in order to figure out how to transition control back to the arm mcu.

[ZackAttack]

Good news. Batari gave me permission to use the DPC+ startup code. So I now have a prebuilt routine to initialize harmony and melody boards. This allowed me to focus on writing the actual driver code. The following C file will compile and run on my harmony cart. What's really cool is that it is running from the ROM instead of the RAM. In fact, there's only about 30 lines of assembly that actually run from RAM right now. Everything else is running in ROM. This leaves lots of memory for game and kernel logic.

 

There's still a huge amount of work remaining, but at least it's starting to look like this will work.

 

Since this is a completely new driver it's not yet supported in any emulators. The only way to run this is with a melody/harmony cart.

 

strong-arm-rainbow-test-pattern.bin

int main()
{
	handleReset();

	int i = 0;

	// Clear memory and registers
	for (i = 0; i < 0x100; i++)
	{
		vcsWrite5((unsigned char)i, 0);
	}

	vcsJmp3();

	while (1)
	{
		vcsWrite5(VSYNC, 2);
		vcsWrite5(WSYNC, 2);
		vcsWrite5(WSYNC, 2);
		vcsWrite5(WSYNC, 2);
		vcsWrite5(VSYNC, 0);

		for (i = 0; i < 37; i++)
		{
			vcsJmp3();

			vcsWrite5(WSYNC, 2);
		}

		vcsWrite5(VBLANK, 0);

		for (i = 0; i < 192; i++)
		{
			vcsJmp3();

			vcsWrite5(WSYNC, 2);
			vcsWrite5(COLUBK, (unsigned char)i);
		}

		vcsWrite5(VBLANK, 2);

		for (i = 0; i < 30; i++)
		{
			vcsJmp3();

			vcsWrite5(WSYNC, 2);
		}
	}
}

[TheHoboInYourRoom]

Works like a charm.

[Andromeda Stardust]

Your demo buzzes in Stella. Might throw it on an actual Harmony and see what it does.

[TheHoboInYourRoom]

Ah yeah, actually the demo does make a slight buzz, but it's at the same frequency as the CRT's own hum so it's probably just some RF interference.