Jump to content

DanOliver's Photo


Member Since 18 May 2013
OFFLINE Last Active Aug 3 2018 3:37 PM

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

Posted by DanOliver on Sun Jun 4, 2017 11:27 AM

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.

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

Posted by DanOliver on Sat Jun 3, 2017 6:42 AM

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.


But, just looking at the ballpark numbers...


Cost of cart, box, manual say $10.

Sales price of game $75.

Profit $65

Units sold: 150

Gross profit $9750

Development time: 6 weeks

8 games released per year gross profit: $78,000


Now, yes, anyone can shred those estimates, please, enjoy yourself. Certainly the entire amount wouldn't be collected in 365 days since sales of the last couple of games would spread into the following year. And people can debate whether that's enough money for a person to live on. And I've certainly read long debates here on whether a game could be sold for $75, but a $25 game in 1980 adjusted for inflation is about $75.


Having another person create the cart, box, manual and sells channel would of course reduce the gross profit to $6-12k and yeah, that's not a reasonable income. So yeah, that type of business model isn't very interesting. That's true for most products.


Can any of these hypothetical games be ported to HTML5 or Facebook to leverage the design cost? I see no reason why not. But of course if a person doesn't think it's possible then well, yeah, it certainly wouldn't be possible.


Any of this guaranteed? Let's not be completely silly.

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

Posted by DanOliver on Tue May 30, 2017 9:48 AM

Dan when you wrote Video Games for Atari in the 80's you were given constraints but didn't have to worry about any of the production issues outside of that, and you also didn't have to worry about the size of your target market.

Size of the target market was always a huge concern in designing a game.


At VentureVision production issues for me was a bigger issue than game design. I loved designing the cardboard insert in the box to keep the cart in place, that saved us time and money. I learned the entire production process at Apollo in order to start VentureVision.


At Atari, yes, I lost production control. That sucked. The cart, box, manual to me is as much a part of the game as the game itself.

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

Posted by DanOliver on Tue May 30, 2017 9:40 AM

Fun is the only reason games for old consoles are still programmed.

Are you willing to make money writing 2600 games?


That's unlikely.

Thanks. Been told that type of thing on many ventures by endless amounts of people. Sometimes they were even right.

#3584225 The Video Game Homebrew Crash of 2016

Posted by DanOliver on Wed Aug 31, 2016 9:43 AM

Some of the greatest games are pretty simple, video and otherwise. Just like in movies, lots of special effects will sell some tickets, but that alone can't make a movie great. To me polish means tweaking how the game reacts to user input...smooth, makes sense, player doesn't ever struggle to move. Second is the difficulty level, fun to play while learning how and then also ramps to difficult and then to almost impossible. Give them an experience, feel natural.


This tweaking normally requires very little code changes, hopefully. But it takes a lot of playing, time and very critical eye. You also have to have some level of player in you too. I'm not a great player so I can test the starting and middle level. For the hard I have to guess based on the middle level settings. For impossible it's more technical, figuring out if your joystick movements and windows to accomplish a tasks are possible. If say player has to move 10 lines vertically to accomplish a goal and they can only move one line per frame and you give them 8 frames they can't win, not cool. So something needs a tweak.


If you can get others to test that's great too. IMO that can't be remote, you have to see how they react, how they do, and say nothing while they play. If remote then a video of them playing and the screen is the next best choice. However, player testing is not a substitute for the designer. They'll make suggestions maybe, consider them if you want, but don't lose track that it's your vision and rep on the line.


But, if you really aren't happy with a game then screw it, do another. Release the ROM. Do you want just anything with your name on it or your best effort? Second game will go faster and be better. Only you can judge.

#3582572 Cycle Counting techniques?

Posted by DanOliver on Mon Aug 29, 2016 12:38 PM

I only did it for screen drawing code and only when I got close to working. After counting and a little tweaking I'd know I was maxed out or N cycles under, Any changes from then would be small so just add/subtract the changes. Kind of like counting cards. Pretty quick the cycle counts are memorized so pretty easy. I never put cycle counts in the source file. Too easy to get out of sync and then be misleading for me.

#3581562 Disassembling 2600 Games?

Posted by DanOliver on Sun Aug 28, 2016 8:16 AM




I agree! With todays CPUs this is no more real fun!  :(


Also it is impossible to control the hardware directly. You only have the API of the driver.

And not to forget: Hardware changes so fast you don't have the time to invent special tricks.

When you are familiar with some hardware, then it is obsolete because of a newer one!


Cycle exact coding... Racing the beam by counting the cycles... Rasters by switching backgound color...

On todays hardware? - Forget it!

I take a different view only because I like to. Modern CPUs are more complex than a 6502, but they're still CPUs. I'd say there are even more tricks, a lot more, that can be done in Assembly.


And we can certainly write drivers. Yes, hardware changes...true of the 2600 too. It's heyday was what, 4,5,6 years?


Racing the beam is fun. But so is dealing with pipelines, caches, multi-cores, etc... Basics are easy to learn by debugging in Assembly and seeing what tricks the compiler is doing.


But yes, to what end. Most programs are so large these days and CPUs so fast it would be hard to even measure a speed improvement. I do still like writing apps that are small in size for what they do. Pretty easy too. And I think there's some value there. Less code = easier to maintain and tweak, faster downloads, faster builds.

#3581179 Disassembling 2600 Games?

Posted by DanOliver on Sat Aug 27, 2016 5:52 PM


Although there is hope, I had a 20-something programmer ask me the other day, "how do I use bitwise operators?" ;)


I guess the hope part is they had heard of bit operators? Head in hands.

#3581027 Disassembling 2600 Games?

Posted by DanOliver on Sat Aug 27, 2016 1:41 PM

And entire RAM variable map on one sheet of graph paper.


I started in AppleSoft Basic, a game, and quickly hit the performance wall and switched to Assembly but didn't get far before hiring out. Back in those days high level languages had a bigger performance hit than today so switching to Assembly didn't have a negative stigma it would later. And today Assembly is so out of the question for almost everything. Not sure that's such a good thing. Some programmers I work with today seem to be rather unaware there's any hardware at all, that memory is infinite and see no problem with a 300 MB app when 1 MB would have been enough. State of software today depresses the hell out of me...hate to use anything new it's so bad. Programming for the mob and the mob don't care. I watched a panel of current day programmers/game designers saying this same problem is infiltrating current games. Holding users hands through the entire game, making games super easy, in order to appeal to the mob. Games for gamers might be going away.

#3580920 Disassembling 2600 Games?

Posted by DanOliver on Sat Aug 27, 2016 9:46 AM

Here's a mind tweak...I don't think the 2600 is difficult. Takes what, a hour or two to read the entire spec. In a day or two you can have most 6502 op codes and 2600 registers fairly well memorized. The difficult part, what makes the 2600 so intriguing, is using that simple hardware to create something as complex as a game. Modern systems flip that. Takes months to begin to learn things like  Unity, OpenGL or whatever, plus the hardware. Once learned getting a game on screen is easy although time consuming.


That's what makes the 2600 so fun to me. Easy to learn, impossible to master.

#3580901 The Video Game Homebrew Crash of 2016

Posted by DanOliver on Sat Aug 27, 2016 9:16 AM

Honestly, I would learn Assembly, but I feel like learning enough to write an Atari 2600 game would take at least a decade.  I'd have better luck with bB IMO.

From way, way back I always thought the concept of Assembly being hard was over blown and distorted. In many ways Assembly is much easier. For example, I wrote a database on the Apple III in Basic. It was a fun, relaxing, powerful language. Fast to get the program up. But as data was added it got too slow and I started having to write more and more speed ups. Pretty soon working in Basic became a nightmare. Converting to Assembly at that point made the entire process easier.I don't know Atari Basic, hear nothing but good things. I wonder if part of the "lack of polish" I hear are programmers hitting a wall. No idea.


6502 is a pretty small instruction set and a lot of it isn't needed. Address indirection is the only concept I ever saw people getting hung up on. The biggest part of Assembly is the same as for any language. Game design #1. I see some people mixing up programming tricks and design. Tricks are nice but can't substitute for good design, Data structures, memory management. I assume just as hard in Basic as Assembly.


The only Assembly that I'd say is difficult is the screen kernel. Basic, I think, provides that for you. So lift a kernel out of some other game. Tweak it. That's what we all did back in the day. After a while it might make sense, and you're on your way.


I'd certainly suggest trying Assembly. In my experience people either pick up programming (any language) and it consumes them, or they don't. You know really fast, like a day or so. There doesn't seem to be any indicator who picks up programming and who doesn't, intelligence, good with math...that's all crap. Some of the dumbest people I've met were great programmers.


One thing though might make a difference...Assembly and the 2600 I think would be difficult trying to learn on weekends. For example I learned Assembly and my first game over say a 6 week period, but full time. Meaning I was thinking about it in the shower, and probably while asleep. If I spread that over weekends, full time on weekends, it would have been a little over 5 months. Getting the momentum back up each weekend...don't think I could do that myself. Intensity I think is really needed. So if you get a chance to devote a month or two you might have a better chance. Everyone is different, so I don't know.


Devoting a month or two to a hobby might sound extreme, but the only way you're actually going to get thru it is if you love it. And if you love it you'll never want to stop programming. And luckily programming pays well. So a month or two could be a great investment in yourself.


For the people who don't really like programming but push through anyways because they want to create a game..my hat is really off to you. That would take a strength I'd never have.


Going back to polish...again, nothing to do with Basic vs Assembly. Polish is where the rubber meets the road. You've worked so hard on the game, it's working, you want it released and the pain to end...that's when you nut up and polish...that's the hard part. To me that's what separates professional from hobby. Again, harder imo for the hobbyist because they have the choice to polish or not. Professional the only choice you have is polish or find another job. You eat or don't eat based on your product. Eating is a great motivator.

#3579497 Disassembling 2600 Games?

Posted by DanOliver on Thu Aug 25, 2016 1:32 PM

To add to Frye's defense, and other developers of the day, and by extension myself, there was a different set of constraints. If I'd taken 6 months to make a better Space Cavern I wouldn't have been employed long enough. Peoples' jobs were on the line and speed to market was key in most cases. Not to diminish work done since, but having the time to think long and hard about better ways, all we've learned since, being able to leave a games for a few weeks or months, time for a design to blossom, not having a career on the line, are nice advantages. Not huge advantages by any means. 2600 is still about as hard as it gets no matter the date.

#3578793 Looking for a few people to make a game with!

Posted by DanOliver on Wed Aug 24, 2016 2:51 PM

I think the concept of "which is the good guy" is a very sweet concept, a modern concept. That can transcend the 2600. I wouldn't get too caught up in the implementation too much, or even 2600 limitations. More like designing Pac Man, better to design a great game and scale it to the 2600. Just stay in the ballpark, low res, not too many sprites. There sure have been some low res few sprite indie games in the past 10 years.


The other way is to design specifically to the 2600, which is how virtually all were done back in the day. That really has to be done by a programmer who can find a few tech tricks. This can result in very good games, but not classic games. For example few original 2600 games were ported to more powerful systems, or were big hits off the 2600. I can't think of any, hopefully some others can.

#3578647 Disassembling 2600 Games?

Posted by DanOliver on Wed Aug 24, 2016 11:24 AM

I guess I make a distinction between rewriting my own code and other people's code. Harder for me to get into another programmer's head, understand their style, different skill set needed in addition to the base skill set. I've refactored a little bit of regular code in the past, it's a very different experience. Doing that with 2600 code...gotta be difficult. Maybe a different mind set.


Code can certainly always be improved given time.


Yeah, fun is fun, that's the bottom line.

#3577822 Disassembling 2600 Games?

Posted by DanOliver on Tue Aug 23, 2016 9:42 AM

The Shaman sure looks like Demon Attack. For learning it's a very interesting idea to recreate a game. A way to really judge skill since you can compare side by side. I once saw painters in front of the Mona Lisa in the Louvre painting a copy. Puzzled the hell out of me, seemed dishonest but they were right there for everyone to see. Asked them and they said it was part of learning. Made sense. I assume they do something to their painting to make it clear it's a copy.


I don't see how DMCA allows copyrighting an idea. That always had to be done via a patent. But, none of that really matters, only how many lawyers you have.