Bank switching 1MB

[Bank switching 1MB]

I'm creating a new banking scheme that will handle up to 1MB. My understanding of the Atari is that addresses $0X3E and $0X3F are owned by the TIA, but unused. So writing to 003E, 013E, etc. will have no effect on the system. I plan to divide the 4K ROM address space into 16 banks that are each 256 bytes in size. Each bank will have their own set of 256 pages to choose from. (16*16*256=1MB) Writing a value to 003E will select which page to map to Bank 0. Writing a value to 013E will select which page to map to Bank 1 and so on all the way up to 0F3E/Bank F.

 

1) Am I missing any obvious design flaws?

2) Would anyone else be interested in using this banking scheme?

[custom bankswitching scheme]

Is there any documentation on how to create a new bank switching scheme on the harmony encore?

 

Does this require bios changes or is it simply creating an additional file to put on the sd card next to the rom image?

[Do you want the bB page to be many pages instead of one?]

I always thought the document was really good as it is now. Though I do wish it encouraged the use of aliases more. I think it would help beginners if they weren't using single letter variable names.

[Sonic The Hedgehog on the 2600]

8 way scrolling and support for a level editor is functional. Scrolling platforms off the left and top still needs to be implemented.

 

http://youtu.be/IBsCQDi9o9I

[P0 glitch]

Thanks for the info. Now I know why it was 2 pixels. Also, that link has a lot of other useful docs.

[Sonic The Hedgehog on the 2600]

The platform tile is almost complete. I'd like to get some suggestions on what colors and sprite graphics to use for the platform. It's a quad sized P1. It can be any size and the color and sprite graphic can be changed every scanline since this is a single line kernel. Here's what I have. It looks ok, but I think someone more artistic could do a lot better.

 

[P0 glitch]

Apparently I can't count. The problem was I had an extra 12 cycles in a sleep statement and that must have strobed HMOVE at a time that caused both P0 and P1 to get moved over 2 pixels to the right. Thanks for the suggestions.

[P0 glitch]

Does anybody have any idea what could cause P0 to be shifted over like this? HMOVE is strobed after every WSYNC and HMP0 is always $00 during all 192 scanlines. On the top portion I write to COLUP1, HMP1, and GRP1. On the bottom portion I write to COLUBK.

 

[*** RFC for new atari 2600 Multicart/Supercart ***]

Hmmm -- well, C/C++ support doesn't really have anything to do with a cart. That has to do with the architecture, the 6502 has C/C++ support right now, you can always get a compiler and generate 6502 machine code and then write games, just like there is Batari BASIC. It's just that the memory, math, and video kernels require you to code in ASM for a lot of things. But, I guess if someone wants to couple a 64K cart with bankswitching, extra RAM, and an API of functions and pre-written video kernels, and then put a C/C++ 6502 compiler on top, that could be done, but that's a different kind of project. I think the Batari guys would be better suited to do that since they already have a BASIC based solution, coupled with the Harmony they could get that working in a few months. But, I think this goes back to BASIC is a lot easier than C/C++, so a complete toolchain and hardware solution for C/C++ games would definitely allow better games, but I wonder if it would scare away as many programmers

I was thinking that ALL the code would be run on the cart. There would be an API with the bare essentials for interfacing with the 2600. That API could be emulated in a library so game development could be completely done in a modern IDE such as Visual Studio. There could also be a library of prebuilt engines similar to what batari basic offers. The benefit of this would be the ability to produce the best looking games with much less effort than writing in 6507 assembly.

 

But, the grand scheme of app stores and DRM and all that is applicable to something where you have development companies spending a lot of money and developing professional level games. Right now, as far as I can tell there are a handful of actual finished working homebrews and programming the 2600 is so complicated, there aren't a lot of people that want to take on the challenge since their is no ROI.

If the cart supports DRM you could potentially release games that can only be played on real hardware. It might encourage more homebrews to be developed if there is a way to release the game without the hassle and risk of producing a quantity of carts. There's also the benefit to players who want to purchase homebrews to play on real hardware but can't afford to pay $50 a cart. In theory an emulator could be run on the cart to allow for DRM of 6507 coded games too.

 

However, I like the idea allowing 2600 players to play with each other via a network and hardware, I have always thought that would be cool. But, you would need a meeting place, then a way to log your 2600 onto the network, then there is no way really to play a game "networked" other than to hack it such that one player sends his controller commands to the other player and then the video stream is shared. Playing two 2600's at the same time with the same game, and then remotely sending the joysticks to each wouldn't work without synchronization. In other words, the games would have be to designed as networked in the first place.

Agreed. I figured this feature would be limited to new games and hacks. Anything not originally designed for online multiplayer would probably suck at it anyway.

 

Hmmm - anyway, I kinda want to keep this to just a cartridge for the 2600 that adds memory, and some features. But, I want to target players not programmers (since there are like 50 of them , but even still there aren't that many players either than actively care about multicarts -- I think I am coming to the conclusion that the harmony (great product by the way), has covered the market need more than enough. And sure, I could add features to it, but those features would have to target players, and I am not sure there is enough there to get a good amount of sales for the engineering effort...

 

Continues to think.....

The harmony is a great product and the support for it on the forums is top notch.

 

What if the cart could also be built as a stand alone system? Then the market for it wouldn't be limited to people that still have a working 2600. If the cart has a decent FPGA on it, both operating modes should be possible with a single hardware design.

 

[file menu is corrupted]

Quick update on this. I picked up another 2600 and a 7800 off craigslist today. The menu is correct on both of these consoles. So either the first console has faulty hardware or there is a compatibility issue. I'm going to see if we can't figure out exactly what causes it.

[*** RFC for new atari 2600 Multicart/Supercart ***]

We're already writing games in C that target the ARM chip within the Harmony - see Draconian^*, Frantic^*, Space Rocks, Stay Frosty 2 and Timmy!^*. Due to the nature of the 2600, key portions must still be written in 6507 assembly. It's entirely possible somebody could develop a "batari C" that would hide the 6507 code like batari BASIC does.

 

I thought the ARM only had a few cycles available for game code. Isn't it spending most of it's time feeding the 6507?

[*** RFC for new atari 2600 Multicart/Supercart ***]

IMO, the cart would need to match all the functionality of the Harmony Encore and then provide something extra on top of that. Features I would like to see include:

* Support for online gameplay

* App Store with DRM so games could be sold cheaply over the internet without worrying about piracy

* Ability to develop games in C++

* Support file system access in the game so they can be much larger than what's out there now

* Bluetooth controllers

 

I know everything I just said is the exact opposite of keeping it simple, but simple is boring.

[Can anyone please help me?]

Thanks i finally got it to work, it was a matter of making a loop for the screen and to change it from firing to pressing up.

Glad to hear you got it working.

 

If you're having problems with the deathscreen being skipped in situations where the player is pressing up when they die, you may need to make the loop ignore the controller input for 30 frames or so to give the player some time to release the joystick/button before proceeding. Another option is to add logic that requires the up button be released and then pressed before proceeding. I hope that makes sense, it's difficult to explain.

[Sonic The Hedgehog on the 2600]

I haven't had much time to work on this lately. There has been some progress made on getting the platform tile done. I think once I have the first tile working properly the rest will be a lot easier. It's building the first one that can be used as a template for the others that is really tripping me up. I also got my harmony encore last week and fixed all the bugs that cropped up on real hardware. So what I have so far has now been tested on real hardware finally.

 

I've also been thinking about how to get a decent looking loop in the game. Any feedback on this would be helpful. The idea is to use the M1 and the BALL to draw an 8 pixel thick oval in brown and then use P1 to draw the rings inside the loop. P1 would be set to 2 copies medium and wide to put a ring on each side of the loop. The COLUP1 would have to be set before and after the missile is drawn so the rings and oval can be the correct color. The P1 M1 and BALL objects can be positioned in a few scanlines right before the loop starts. P1 will need to be repositioned after the top 2 rings get drawn. There should be enough vertical space between the rings that HMP1 can be used fore the repositioning. At the bottom of the loop the background color can be changed to green for 4 scanlines and then brown to draw the ground and the objects turned off during the drawing of the grass. Finally the HMM1 and HMBL registers would need to be updated each scanline to move the missile and ball in an arc. Here's a mock I did in mspaint. I know the oval border isn't 8 pixels like it should be, but other than that I think it's doable.

 

[Sonic The Hedgehog on the 2600]

Wowie wow wow. 1MB?! I bet a lot of that is just map, level, sound, music, etc, data. Zippy is 64k in size. I think once you get past 64k, you need start using the melody board.

It actually wouldn't need anything as fancy as the melody board just a simple bank switching chip and a giant eeprom. It wouldn't really "need" all of the 1MB, but hey a 1MB eeproms is less than a buck on digikey. So why not pack it full of levels and sprite animations?

[Creating screen mocks]

That would be really neat. I wonder if it would be possible to have it create the complete code required for a tile in my graphics engine. Might have to look into doing that one day. Sounds like it would be challenging.

[Ninja Wall Jump game - WIP]

 

As a ninja, you already have many skills. But there are many more to learn.

Does this mean we can expect more games from the ninja franchise? I hope so.

[Mallard Hunt]

Ducks are now speeding up.

Great now I can reach a score of 20. You should check out the fixed point math http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#fixedpoint If you used that you could ramp up the speed a little slower.

[Mallard Hunt]

If you get stuck on the shot effect I can probably provide some assistance.

 

I'd also like to suggest slowing the mallards down at first and increasing their speed as your score goes up.

[Can anyone please help me?]

I think it's because you have the title screen right after the deadscreen. So you're drawing the deadscreen first and then immediately drawing over it with the title screen. Maybe add a loop right after the dead screen to draw the screen and wait for input like you did for the title screen?

[Mallard Hunt]

I'm talking about how the lead shot spreads out a little as it travels away from the shotgun. It would look like this when you fire.

 

 

Maybe the mallards could have a death animation too. Either dropping out of the sky or exploding into bits.

[Mallard Hunt]

Nice job on the hunter! A bigger crosshair might help. Or, maybe when the shot is fired you could change the crosshair to a 8x8 square of random pixels to simulate a shotgun. That would probably look really cool. It might take some skillful bit manipulations to get a decent looking shot pattern, but I bet it would be worth it. Not to mention a good exercise in programming.

[Mallard Hunt]

I found the control to be somewhat awkward. Have you considered having a hunter centered at the bottom of the screen and using the paddle controller to aim the direction of his rifle?

[Creating screen mocks]

I want to mock up my level tiles before I code them. Are there any tools that let you easily edit a complete frame? Since the level is made up of P1, M1, Ball, PF, and COLUBK I need an editor that would support placing and changing those. Has anyone created that yet?

[file menu is corrupted]

I was able to download the eeloader in step 1 just fine. Step 2 worked fine too. I can't perform step 3 though because I can't read the menu to select the upgrade option. Also, the root menu, that has the firmware version, doesn't allow me to select anything but the top row which takes me back to the file menu.

 

Is the menu system in the eeprom loader image or the hbios file?

 

Perhaps I need to send this cartridge back