Jump to content
IGNORED

UnoCart-2600 : a DIY SD multi-cart for the 2600


electrotrains

Recommended Posts

I got a chance to test the 2600 UNO on the RetroN77. Sad to say, given what I have read about theR77, I was not expecting much. . The R77 gave me an interesting, but non-functional result. Here is a pic of what it does do:

 

post-16779-0-23515500-1532236370_thumb.jpg

  • Like 1
Link to comment
Share on other sites

  • 5 weeks later...

Got mine in yesterday. Very happy as it works well. Only problem is the same Pitfall II issues that have been reported. I have tried it on both a Vader and Jr with PFII working on neither.

 

 

 

Hmm, I thought the update had fixed this issue. I will have to get a Vader and a Jr for testing as my three units all work accordingly.

Link to comment
Share on other sites

 

 

 

Hmm, I thought the update had fixed this issue. I will have to get a Vader and a Jr for testing as my three units all work accordingly.

 

If there is anything you wish me to test, please let me know. Happy to share my files as well. I have a 4 switch woody, Vader and a Jr. I can try on the Woody later if you wish. It is the only one that I have not tested on as my Vader and Jr have the composite upgrade. Not the woody.

Link to comment
Share on other sites

  • 3 weeks later...

Nowadays, there are even more schemes that allow the VCS to access much more ROM and extra RAM than those 4k. The 3E scheme is one such scheme that allows the software running on the VCS to access up to 512k ROM and 32k RAM (in theory; the implementation for the UnoCard is the first that actually supports this on real hardware).

 

Actually I think the Krokodil Cart was the first to support the full 3E scheme. But for the purposes of compatibility with some other cart - Harmony? I don't recall which, exactly - in any case it was "agreed" that the maximum memory available under the 3E scheme was to be 480K. That's from my memory of discussions nearly 15 years ago. 3E was "invented" as a "let's cram it in there" by Armin Vogl and myself, for programming Boulder Dash, and its limitations were due to the extreme lack of space on the Krokodile cart to implement the bankswitching logic. There are some real "gotchas" in the behaviour of addressing and page boundary crossing. In other words, just switching in the right bank definitely does NOT work - you also have to be aware of the page-crossing differences between "normal" 6507 and as implemented on the 3E scheme.

 

My late reply to this due to me only just becoming aware of this project and the above comment.

  • Like 1
Link to comment
Share on other sites

Actually I think the Krokodil Cart was the first to support the full 3E scheme. But for the purposes of compatibility with some other cart - Harmony? I don't recall which, exactly - in any case it was "agreed" that the maximum memory available under the 3E scheme was to be 480K. That's from my memory of discussions nearly 15 years ago. 3E was "invented" as a "let's cram it in there" by Armin Vogl and myself, for programming Boulder Dash, and its limitations were due to the extreme lack of space on the Krokodile cart to implement the bankswitching logic.

 

 

Thanks a lot for the correction. I must admit that I was thinking only about the Harmony when I wrote this, but I wasn't aware that the Krokodile cart could already handle ROMs that large. Actually, while the Harmony Encore should be able to support full 512k of ROM, it seems that the actual 3E / 3F drivers weren't updated; only ROMs <= 32k work at the moment --- that's what I was referring to.

 

 

There are some real "gotchas" in the behaviour of addressing and page boundary crossing. In other words, just switching in the right bank definitely does NOT work - you also have to be aware of the page-crossing differences between "normal" 6507 and as implemented on the 3E scheme.

 

Could you elaborate a bit? I guess you are talking about the spurious access that happens on a indirect access that crosses a page boundary while the 6507 adds carry to the hight byte, but I don't see the connection to the implementation of 3E yet.

Edited by DirtyHairy
Link to comment
Share on other sites

 

Could you elaborate a bit? I guess you are talking about the spurious access that happens on a indirect access that crosses a page boundary while the 6507 adds carry to the hight byte, but I don't see the connection to the implementation of 3E yet.

My recollection is that (indirect),y addressing CANNOT cross a page boundary. The page is Not incremented. It made programming Boulder Dash very tricky. There may be other limitations, but I cannot recall at this stage. That one I'm sure of.

Link to comment
Share on other sites

My recollection is that (indirect),y addressing CANNOT cross a page boundary. The page is Not incremented. It made programming Boulder Dash very tricky. There may be other limitations, but I cannot recall at this stage. That one I'm sure of.

 

 

If I am not mistaken, reading the initial vector from zeropage wraps at the boundaries, but adding y may cross a page boundary. If this happens, you'll pay a penalty cycle (for read instructions --- it's always there for write / RMW instructions) during which a read access happens to the address with the wrong (not incremented) high byte. The other addressing quirks that I am aware of are:

  • A similar penalty / invalid access cycle in absolute indexed addressing
  • Zeropage indexed address wraps at the page boundary
  • Indirect addressing (JMP) cannot cross a page boundary; the high byte will be read from byte 0x00 of the same page
Edited by DirtyHairy
Link to comment
Share on other sites

I'll rephrase to try to make it clearer. In normal 6502 you can use (zp),y to access data over multiple pages, with the final "calculated" address being able to cross page boundaries. In the 3E scheme as implemented in hardware on Krokodile Cart and Boulder Dash hardware, you cannot do this. (zp),y addressing is limited to a single page. The calculated address does not correctly cross the page if (zp)+y is not in the same 256 byte block as (zp) is pointing to. It's a hardware limitation of the scheme as originally implemented on the Krokodile cartridge due to insufficient firmware on that hardware to properly implement this particular addressing mode.

 

 

 

 

 

 

 

If I am not mistaken, reading the initial vector from zeropage wraps at the boundaries, but adding y may cross a page boundary. If this happens, you'll pay a penalty cycle (for read instructions --- it's always there for write / RMW instructions) during which a read access happens to the address with the wrong (not incremented) high byte. The other addressing quirks that I am aware of are:

  • A similar penalty / invalid access cycle in absolute indexed addressing
  • Zeropage indexed address wraps at the page boundary
  • Indirect addressing (JMP) cannot cross a page boundary; the high byte will be read from byte 0x00 of the same page

 

Link to comment
Share on other sites

I should have known that. :dunce:

 

Didn't know Pitfall II had compatibility issues with some Ataris. Kinda cool Chetiry GB runs on the same 1982 technology. :grin:

 

Only with the Uno-2600 cart on certain 2600s it appears. Was trying to figure out the common denominator. MacRorie has been looking into things with this game.

Link to comment
Share on other sites

 

Only with the Uno-2600 cart on certain 2600s it appears. Was trying to figure out the common denominator. MacRorie has been looking into things with this game.

 

 

I am looking, but I need the help of the programmers. :-) This code they talk is scary! ;-)

  • Like 1
Link to comment
Share on other sites

ZeroPage Homebrew has just placed an order for an UnoCart (thanks MacRorie!!) and we will be debuting the very first (I believe) UnoCart exclusive game in an upcoming ZeroPage Twitch livestream!

 

This WIP game has not been publicly announced anywhere so stay tuned to our social media and our AtariAge forum thread for more details! :-) We're really looking forward to playing around with the UnoCart on the show!

Edited by cimmerian
  • Like 3
Link to comment
Share on other sites

...and we will be debuting the very first (I believe) UnoCart exclusive game in an upcoming ZeroPage Twitch livestream!

 

This WIP game has not been publicly announce anywhere so stay tuned to our social media and our AtariAge forum thread for more details! :-) We're really looking forward to playing around with the UnoCart on the show!

 

My UnoCart is jealous...

 

post-21941-0-50436000-1536895783.jpg

  • Like 2
Link to comment
Share on other sites

ZeroPage Homebrew has just placed an order for an UnoCart (thanks MacRorie!!) and we will be debuting the very first (I believe) UnoCart exclusive game in an upcoming ZeroPage Twitch livestream!

 

This WIP game has not been publicly announced anywhere so stay tuned to our social media and our AtariAge forum thread for more details! :-) We're really looking forward to playing around with the UnoCart on the show!

So homebrew that can't run on Harmony? Does it utilize the arm coprocessor? I hope it comes to the AA store. If not, I may have to buy an UNO... :cool:
  • Like 2
Link to comment
Share on other sites

This homebrew is not able to run on the Harmony OR the Stella emulator, only a UnoCart (hence my purchase)! I'm not able to reveal anything about the game until the broadcast so I can't really say anything more. Should be very interesting!!

 

So homebrew that can't run on Harmony? Does it utilize the arm coprocessor? I hope it comes to the AA store. If not, I may have to buy an UNO... icon_shades.gif

  • Like 2
Link to comment
Share on other sites

This homebrew is not able to run on the Harmony OR the Stella emulator, only a UnoCart (hence my purchase)! I'm not able to reveal anything about the game until the broadcast so I can't really say anything more. Should be very interesting!!

 

Sounds fantastic. Please let us know when you decide to stream the new game! :cool:

  • 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...