Jump to content
IGNORED

New ColecoVision PCB design project


Pixelboy

Recommended Posts

In addittion to that you need to think how you are going to tell your C compiler to do that...

C compilers generally don't generate IN and OUT instructions inline in their code. This is primarily because the C language has no concept of a separate I/O address space.

 

Why don't you use the cartridge memory area for decoding, it is safer. If you want to go with small PLDs, use a 74LS21 to help with decoding. You get 2 4 ports ANDs, you can use one to decode all 4 CS lines, and the other to decode 4 address lines, thus saving you a lot of PLD ports. Oh, and you save the filter, because have you even assembled a cartridge? The more components you use, the longer it takes to assemble, and it is a pain to solder a board full of capacitors and resistors... Can't you use a bigger PLD, Atmel has several such PLDs in DIP format...

Actually, a 74LS133 would be much more useful, since it has 13 inputs, which is great for decoding FFFx addresses. The reason to use a GAL over bigger PLDs is that they are simple, cheap, and available in DIP form. (And the reason to use a GAL vs more TTL is that GALs combine programmable logic with the registers you need for bank select addresses)

 

It also doesn't help that the CV cartridge slot doesn't have any proper clocking other than the pre-decoded chip select lines, which are only valid in the ROM area.

 

However, one of the problems is that usable board space is limited in various forms of CV cartridge cases:

* Coleco cases have vertical ribs that limit width in the first two inches of the board

* Activision style cases have posts that limit the width of the first chip position by a bit more

* both Activision and Coleco style cases have horizontal ribs that prevent you from putting chips in certain areas

* Coleco cases have a second horizontal rib that limits you even more.

 

It's cheaper to be able to use a smaller board, so getting the board as small as possible is a good thing. But there's not enough room for more than an EPROM and one GAL chip* on a short board.

 

*an 8-pin EEPROM and GAL together may be barely possible, but it's going to be real close

Link to comment
Share on other sites

Note to Eduardo, if you're reading this: We're still waiting for you to join us in our private conversation (check your PM Inbox!). If your priorities have recently changed to the point where you're not interested in this project anymore, please let the rest of us know. Thanks. :)

Link to comment
Share on other sites

Note to Eduardo, if you're reading this: We're still waiting for you to join us in our private conversation (check your PM Inbox!). If your priorities have recently changed to the point where you're not interested in this project anymore, please let the rest of us know. Thanks. :)

 

 

Just an idea, but it kind of goes along with your pcb project. How about a cartridge with all the original ColecoVision games on it with a game select like the multi-cart. But the games would be on a EPROM and there would be flash memory and a battery for game saves.

Link to comment
Share on other sites

Just an idea, but it kind of goes along with your pcb project. How about a cartridge with all the original ColecoVision games on it with a game select like the multi-cart. But the games would be on a EPROM and there would be flash memory and a battery for game saves.

Multicarts of original games. If you're talking about commercial games, it's not legal to do so, but there was a couple of coleco multicarts done about 10 years ago. If you're talking about homebrew games, I guess each programmer involved will have to agree or make their own. In both cases, it's not related to the pcb project mentionned here, so it should be in another subject.

Link to comment
Share on other sites

  • 6 months later...

I am very proud to announce that, thanks to the hard work of batari, classics and several others this past year, the Activision PCB is now reality!

 

Yes people, we now have a ColecoVision PCB that supports 64K bankswitching (3 banks of 16K in the upper half of the cart ROM address space) and EEPROM support for data-saving! It can also support regular 32K ROMs. And even better: Two versions of the PCB will be available, one for Activision cart casings, and the other for regular Coleco casings (only the outer shape of the PCB differs between the two variants).

 

I'm a little too busy right now to get into technical details, so I'd like to invite batari and classics to post information and comments.

 

Within the next month or so, I'll try to sort out all the information relative to this PCB and update my Team Pixelboy web site accordingly.

 

Man, this piece of news really made my day! :D

Edited by Pixelboy
Link to comment
Share on other sites

I am very proud to announce that, thanks to the hard work of batari, classics and several others this past year, the Activision PCB is now reality!

 

Yes people, we now have a ColecoVision PCB that supports 64K bankswitching (3 banks of 16K in the upper half of the cart ROM address space) and EEPROM support for data-saving! It can also support regular 32K ROMs. And even better: Two versions of the PCB will be available, one for Activision cart casings, and the other for regular Coleco casings (only the outer shape of the PCB differs between the two variants).

 

I'm a little too busy right now to get into technical details, so I'd like to invite batari and classics to post information and comments.

 

Within the next month or so, I'll try to sort out all the information relative to this PCB and update my Team Pixelboy web site accordingly.

 

Man, this piece of news really made my day! :D

 

Great news!!

 

It would be wonderfull if Daniel could add support for this in his Library for SDCC .

Link to comment
Share on other sites

another thing i'm just thinking. Is there an emulator that will support that bank switching and eproom saving?

 

Would be very usefull for developpers.

Well, classics will likely support these features in his SD card, so testing on real hardware will be possible. As for emulation, once some pieces of software has been made public, I'm hoping dvik will include support for it under blueMSX.

 

These issues will be addressed over time. Right now, I'm just too busy preparing for the release of my 6 Team Pixelboy ColecoVision titles. I'm still on track for a late October release, if anyone here is wondering, but there is still a lot of work to be done. Once that work is behind me, I will put some more time and effort into the PCB project, mostly for documentation purposes.

Link to comment
Share on other sites

What I think may happen is using SDCC to compile a main bank and then programmers deal with the other banks with or without SDCC (without CCI) and make sure the logic is correct.

 

Well, I don't think any library for SDCC can handle the logic of bankswitching, but can certainly have the simple codes in order to make the switchs. It will be programmers responsability to make each bank properly, not the compiler to cut into banks a regular project.

Link to comment
Share on other sites

What I think may happen is using SDCC to compile a main bank and then programmers deal with the other banks with or without SDCC (without CCI) and make sure the logic is correct.

 

Well, I don't think any library for SDCC can handle the logic of bankswitching, but can certainly have the simple codes in order to make the switchs. It will be programmers responsability to make each bank properly, not the compiler to cut into banks a regular project.

That's actually one of the first things I'll want to investigate, when I get the chance: How does one go about "placing" code and data in specific banks in C language, so that everything fits together? It's not obvious to me...

Link to comment
Share on other sites

That's actually one of the first things I'll want to investigate, when I get the chance: How does one go about "placing" code and data in specific banks in C language, so that everything fits together? It's not obvious to me...

 

#pragma is your friend ;). You'll have to use it to force static const data and code into the banked segments.

Link to comment
Share on other sites

That's actually one of the first things I'll want to investigate, when I get the chance: How does one go about "placing" code and data in specific banks in C language, so that everything fits together? It's not obvious to me...

 

#pragma is your friend ;). You'll have to use it to force static const data and code into the banked segments.

Thanks Groovy, I'll look into that. :)

Link to comment
Share on other sites

Well, classics will likely support these features in his SD card, so testing on real hardware will be possible. As for emulation, once some pieces of software has been made public, I'm hoping dvik will include support for it under blueMSX.

 

Testing on real hardware , in my case , does not really help me during developpement. Because usually when i have the time for developpement , it is when i'm on vacation or not at home and so far from a Coleco.. Most of my games are done on my netbook while outside my country. So i can not wait 3 weeks to be able to test my dev! :|

 

I really hope also that dvik will support it in BlueMSX.

Link to comment
Share on other sites

The code for saving and loading games on the eeprom based board should be easy to plug in to any existing SDCC project. I believe the only requirement is that you save your currently selected bank number before calling the eeprom read/write routines, then restore it afterward if need be.

 

I'll leave it to Luc to release the source code for those routines as he sees fit.

 

Thanks for giving me the chance to help out, I enjoyed working with both of you. :)

 

Steve

Edited by classics
Link to comment
Share on other sites

The code for saving and loading games on the eeprom based board should be easy to plug in to any existing SDCC project. I believe the only requirement is that you save your currently selected bank number before calling the eeprom read/write routines, then restore it afterward if need be.

 

I'll leave it to Luc to release the source code for those routines as he sees fit.

 

Thanks for giving me the chance to help out, I enjoyed working with both of you. :)

 

Steve

And thank YOU, Steve, for helping us out! :D

 

Batari and I have agreed to run one final prototype run and test it with your test software before placing an order for 1800 PCBs. This will likely add about one month to the final testing cycle, but I think it's worth it.

 

Beyond that, I'll get around to documenting everything eventually, hopefully sooner rather than later.

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