Jump to content
IGNORED

Please help with the ColecoVision Opgrade Module


opcode

Help decide what the Opgrade Module should be  

122 members have voted

  1. 1. Please choose the statement(s) which best describe your view about what the OM should be:

    • OM is a pluggable module for the CV with minimum functionality, lowest possible price
      26
    • OM is a pluggable module with advanced functionality, like A/V outputs
      44
    • OM is a standalone device that can plays all the CV games, and also have the OM functionality
      61
    • Who cares about expansion modules?
      4
    • I have a better idea...
      3

  • Please sign in to vote in this poll.

Recommended Posts

Quick question: Do you intend to include some extra routines converted from the MSX BIOS into your BIOS XP? It may help to make porting certain MSX games easier...

 

I am not doing that for different reasons:

1) Different developers used different BIOSes routines. Good developers used only the most basic I/O routines, but anyways, we would need a lot of routines to cover all bases

2) With all the extra RAM it's easier to simply load the MSX routines you need from the MegaCart to the expanded RAM

3) With switchable clock speeds some routines that work ok with 3.58MHz won't work when you switch to 7.14MHz, so you need to design your routines around that

4) I hate BIOSes... :)

 

About remark #3, using the off-the-shelf strategy, the V9958 offers a WAIT line for loading data to the VRAM, so WAIT can be activated and transfers will happen ok no matter which clock speed you select, and without the need of adding NOPs between I/O accesses.

 

And since we are talking about the V9958, here is a picture of it, just waiting for the video PCB... :)

The two larger chips are the V9958, backward compatible with the CV VDP, the TMS9928, which is shown below the two V9958. Bottom chip is a Z80 (the CV CPU), just for size reference. At the top we have the Sony CXA1645, the nice video encoder that will be used with the V9958 to produce (I hope) excellent picture quality, with composite and S-video. Just as reference, the V9958 is about 3".

 

In case you haven't read previous post, and in case you care about those things, here is short list of things the V9958 can offer that the TMS9928 cannot:

 

- 8 sprites per scanline, two sprites can be combined to produce a 3rd color.

- Hardware smooth scroll

- Configurable color palette, 16 colors from 512 (the chip "boots" using the default CV palette)

- A lot more memory, meaning more graphic variety

- New graphics modes, in case someone wants to use them. 256x212 bitmapped with 16 colors, 256x212 bitmapped with 256 colors, 256x212 with 19K colors (yes, that is right 19,000 colors) using YJK encoding (it's similar to JPG), 512x212 with 16 colors

- line interruptions, allows you to program a line # then the CPU will be "notified" via interruption that the desired line has been reached. Useful for changing stuff middle screen, like creating split screens, changing color palettes, or even doubling the # of sprites on screen

- A blitter, or data mover. Can move data while the CPU is doing something else

- Interlacing for double vertical resolution (512x424 max)

post-1432-1250262264_thumb.jpg

Link to comment
Share on other sites

- New graphics modes, in case someone wants to use them. 256x212 bitmapped with 16 colors, 256x212 bitmapped with 256 colors, 256x212 with 19K colors (yes, that is right 19,000 colors) using YJK encoding (it's similar to JPG), 512x212 with 16 colors

Do we have the same old single-colored sprites will all those new video modes?

Link to comment
Share on other sites

- New graphics modes, in case someone wants to use them. 256x212 bitmapped with 16 colors, 256x212 bitmapped with 256 colors, 256x212 with 19K colors (yes, that is right 19,000 colors) using YJK encoding (it's similar to JPG), 512x212 with 16 colors

Do we have the same old single-colored sprites will all those new video modes?

 

With the V9958, each sprite scanline can have a different color, which is both a good and a bad thing.... It's good because you get more colors, it is bad because you now have a sprite color table of 512 bytes that you need to manage and transfer to the VDP. That is why turbo mode is a must.

And as I said before, two sprites (actually more if you want) can be combined to produce a third color (or more) per scanline. As I see it, the resulting sprite capabilities of the V9958 are near those offered by the NES, perhaps a little more flexible. But we still don't have flip bits... On the other hand we have the blitter that can help with that. The V9958 reminds me of some platforms (like the Ataris) where you can get a lot out of the hardware, but that requires some extra effort. Coordinating CPU and blitter operations, as well as using vblank transfers as much as possible are paramount to achieve good results with the V9958. Not an easy chip to program for, but quite flexible... just like the Ataris... :)

Link to comment
Share on other sites

- New graphics modes, in case someone wants to use them. 256x212 bitmapped with 16 colors, 256x212 bitmapped with 256 colors, 256x212 with 19K colors (yes, that is right 19,000 colors) using YJK encoding (it's similar to JPG), 512x212 with 16 colors

Do we have the same old single-colored sprites will all those new video modes?

 

With the V9958, each sprite scanline can have a different color, which is both a good and a bad thing.... It's good because you get more colors, it is bad because you now have a sprite color table of 512 bytes that you need to manage and transfer to the VDP. That is why turbo mode is a must.

And as I said before, two sprites (actually more if you want) can be combined to produce a third color (or more) per scanline. As I see it, the resulting sprite capabilities of the V9958 are near those offered by the NES, perhaps a little more flexible. But we still don't have flip bits... On the other hand we have the blitter that can help with that. The V9958 reminds me of some platforms (like the Ataris) where you can get a lot out of the hardware, but that requires some extra effort. Coordinating CPU and blitter operations, as well as using vblank transfers as much as possible are paramount to achieve good results with the V9958. Not an easy chip to program for, but quite flexible... just like the Ataris... :)

Is it possible to have the old sprites with the new graphic modes?

Link to comment
Share on other sites

Is it possible to have the old sprites with the new graphic modes?

Nop... :)

But then, I thought we weren't supposed to use the new modes... ;)

Well, my question was mostly pertaining to graphic mode 3 (8 sprites per scanline max, etc.). :)

 

Isn't Graphics 3 the same as Graphics 2 but with the new sprites? So what is point of using the old sprites? If you use the old sprites you are back to Graphics 2... :P

Link to comment
Share on other sites

Is it possible to have the old sprites with the new graphic modes?

Nop... :)

But then, I thought we weren't supposed to use the new modes... ;)

Well, my question was mostly pertaining to graphic mode 3 (8 sprites per scanline max, etc.). :)

Isn't Graphics 3 the same as Graphics 2 but with the new sprites? So what is point of using the old sprites? If you use the old sprites you are back to Graphics 2... :P

So you're telling me the only way to have access to the 8-sprites-per-scanline feature is to use that bulky multicolor sprite mode? That's kinda disappointing... :|

Link to comment
Share on other sites

Is it possible to have the old sprites with the new graphic modes?

Nop... :)

But then, I thought we weren't supposed to use the new modes... ;)

Well, my question was mostly pertaining to graphic mode 3 (8 sprites per scanline max, etc.). :)

Isn't Graphics 3 the same as Graphics 2 but with the new sprites? So what is point of using the old sprites? If you use the old sprites you are back to Graphics 2... :P

So you're telling me the only way to have access to the 8-sprites-per-scanline feature is to use that bulky multicolor sprite mode? That's kinda disappointing... :|

 

Kind of... But so is life... :)

Link to comment
Share on other sites

Ok, guys, I think I have everything figured out. From the poll results and considering development times, I am going with the advanced module. During the last couple of weeks I designed all the sub-systems and created PCBs to test each system individually. I am currently waiting for the first PCB to come from the manufacturer (should be shipped this week). I want to wait until that PCB is delivered before ordering anything else, because I never dealt with this particular supplier before. The first PCB includes all the basic systems, like expanded RAM, BIOS XP and PSG. The next two PCBs I am going to order are video and turbo modules. After that audio and IDE. Once all the sub-systems are individually tested, I will create the final PCBs with all systems included. For that I will have the help of my Brazilian friend Ricardo Oazem, who is a very skilled electronic engineer and creator of the VSU expansion module for the MSX:

What we are planning is to have the beta version of the final module done by the end of this year.

After that starts beta testing, and I am planning 6 months to be safe. During that time 3 or 4 lucky (or perhaps not) persons will playtest the OM, while I finish all the software related to the project. That includes the BIOS, the GUI, and Donkey Kong Arcade. During that time I will also be doing some research about which casing the final module will use.

Now here comes the problem... I am estimating that the final module will costs from $100 to $150 a unit to produce. I plan to sell them at the cost, including DKA. The problem is that several of the ICs we are going to need require orders of 100 units minimum. 100 units also give us the best discounts considering the volume we are planning. Now, if you do the math, $100~$150 x 100 = $10,000~$15,000. That's a lot of money.... I can say for sure that I don't have that money to buy everything upfront. The solution I see is to organize a consortium of potential buyers that will pay for the OM production. Money will be required once the OM is ready for production, but it is very likely that buyers will need to wait a couple of months between payment and receiving their OMs because of all the production times involved.

However, as I said, 100 people should be the minimum number of people involved in the consortium before production starts. And there is more, once (and if) the initial group is formed, another run will happen only if I can get another 100 people.

That said, we still have a long way ahead, and of course I don't want to expend almost a year of my life working on something just to find out that I cannot get 100 people to pay for it later. So here is the deal, I want to start (not now but soon) a list of people interested in participating on the consortium, just to make sure we have enough people to guarantee the project. Again, no money will be required until the OM is completely finished and ready to go into production. But on the other hand you should only be part of the consortium if you really plan to buy the module. Keep in mind that the estimated price is currently $100 to $150.

Here is what you are going to get, but before that let me just make clear again that I am not starting the list yet, so please wait until the list is started to contact me (though comments are always very welcome). I will open another thread once I start the list so stay tuned...

 

OM Specs:

- Expanded memory of 24KB replaces the CV 1KB

- BIOS XP replaces the CV BIOS. BIOS XP is 128KB and offers new GUI

- MegaRAM allows cartridge emulation (up to 128KB)

- Turbo module increases CPU speed up to 150%, with 7.14MHz clock and optional memory WAIT disable

- Video module (V9958) replaces CV internal VDP and is 99% backward compatible. Adds modern video outputs like composite, S-video and analog RGB

- Sound module includes AY-3-8910 as an alternative for the more primitive CV PSG, plus YM2151 (Yamaha FM). The two were the most utilized sound generators during the 80s. Stereo audio outputs included (PSG is mono though)

- Compact Flash interface offers mass storage

- Parallel I/O port and switches offer interesting ways to interface with users. Linking two (or more) CV would be possible

- Other convenience features include spinners disable, NMI disable and more

 

Supposing you absolutely don't care about homebrews, here is what you get with the OM:

- Modern A/V outputs compatible with 99% of all CV games. V9958 video output is beyond what is possible with the TMS9918 (original CV VDP)

- MegaRAM + CF offer a way to play any CV game using ROM images. Similar to Atarimax, but with virtually no limit in the number of games it can hold (FAT16 size limit is 2GB)

 

Now you have the specs, here are some milestones that I think we should reach to ensure the development process of the OM:

- Once all the sub-systems are tested and demoed, we should get 50 people interested to go to the next phase (to guarantee Mr Oazem's involvement)

- Once a PCB containing the full set of features is tested and demoed we should get 80 people interested to go to the next phase (beta-testing)

- To go into production we should get 100 names at least (and of course the money)

 

So how about that? Is that reasonable? How many of you would be interested?

Once again, I am not starting the consortium yet. I will let you guys know once it starts. Until there, comments are welcome. :)

Link to comment
Share on other sites

Eduardo, out of curiousity, I have seen you make note more than once that the stock VDP is the TMS9918. I can honestly state that every ColecoVision that I've ever taken apart for refurbishing/modding (probably somewhere around 75 or more consoles) I've always seen the TMS9928. Now I realize these chips are very similiar, I was just curious why you keep stating that its the TMS9918.

 

With that comment out of the way, like I said before, you're never going to get everybody to agree on what options/features the unit should have, so if the features/options you've mentioned above are the route you want to go, that's fine with me personally. A few questions I do have would be:

 

With the new VDP, will all of the video signals be routed through this IC, rather than the stock VDP?

 

Will the stock VDP even be used anymore at all?

 

Will the stock VDP be used on legacy games?

 

I guess the above questions would also apply to the sound IC, and the BIOS chip as well.

 

If the module will overide the stock BIOS, does that mean that my "Intro Skip" BIOS will no longer work? That would be a real pain in the ass since I am so use to it these days. If I have to sit through a 12 second title delay on legacy games, that would definately suck. Now my "Intro Skip" BIOS is a selectable feature. Meaning that if you do not press a button during the title screen, it will display as normal. If you do press a button, then, and only then, does it bypass the screen and proceed to the game selection screen. If the new BIOS does overide the stock BIOS, I'd like to supply you with this file to be included in the module if possible.

 

If this new module is to plug into the expansion module (front of the console), where will the audio/video outputs be located, in the front of the machine?

 

If so then the A/V cables will need to be routed around/over/under the console to it's rear correct?

Link to comment
Share on other sites

So if I am understanding this correct... for the 1% of current games avaialble that won't be compatible we will simply remove the Opgrade Module and play via RF correct? We would treat this similar to the Atari add-on with the exception that we will want to play all the games using the Opgrade module.

 

This is sounding very interesting! I guess the sweetspot in pricing this would be as low as possible... but the fact that (from what I understand) you get the OM as well as Donkey Kong Arcade for the $100-$150 is pretty decent to me. Considering an Atarimax flashcart is $125 or so, this would be a great deal!

 

Let's see the value here (to me at least... I'm sure others would agree):

 

- Opgrade Module - allowing new and improved Colecovision games! Basically added ram $50 (just a value I picked)

- Donkey Kong Arcade - $40 (similar to PacMan Collection)

- Video Upgrade without modding required - $50 (I'm guessing this may be a bit low... not to mention the shipping saved!)

- Memory card support (similar to Atarimax flashcart) - $125

 

I'm sure there are more value added features but I see the things above listed makes it out to be $265. So $100 - $150 is a very good deal to me! No markup though? I suppose, selling these at cost with the customers being your target market for future OM releases is where you can look for future profits.

 

At any rate... keep us posted.. this is looking awesome!

Link to comment
Share on other sites

Eduardo-

 

Whatever you decide to build, I'll take two. So that's 98 more that you need a commitment on. When you start the list, I'll put my name on it.

 

As a kid I remember attending some type of electronics show in New York at the Nassau Coliseum where Coleco had the Super Game Module on display. Not playable of course, it was just for show. Man, did I want that thing. It's too bad they went the way of the Adam instead...

 

Now almost 30 years later, I may finally get one. That's just too cool.

 

A great look for the OM would be to go as retro as possible, if not "clone" the look of the SGM altogether. This page has a nice closeup:

 

http://www.colecovision.dk/sgm.htm

 

Don't know if that's possible based on your design, but it would look cool if it could be done.

Link to comment
Share on other sites

It is quite incredible Eduardo. :D

 

Great piece of work you put in this major project.

 

But how in relation to PAL TV system, compared to NTSC. ?

 

Would it be possible to sell the OM without the Case, because I have a plan to build my own. ?

Link to comment
Share on other sites

Eduardo, out of curiousity, I have seen you make note more than once that the stock VDP is the TMS9918. I can honestly state that every ColecoVision that I've ever taken apart for refurbishing/modding (probably somewhere around 75 or more consoles) I've always seen the TMS9928. Now I realize these chips are very similiar, I was just curious why you keep stating that its the TMS9918.

 

Yeah, you are right, it is the TMS9928. I just use TMS9918 because it is the main member of the TMS9XX8 family. We also have the TMS9118 and TMS9919/TMS9929 and so on. The difference is the type of video output, VRAM interface or color encoding system (NTSC/PAL). But all basically the same IC.

 

With the new VDP, will all of the video signals be routed through this IC, rather than the stock VDP?

 

Correct. The new I/O decoder maps the V9958 instead of the TMS9928. The only thing is that the V9958 has 4 "I/O ports" instead of 2. Because the way Coleco mapped those ports, and to make sure games are backward compatible, I have added a "VDP mode" register to the OM. Default is 0, when just the first 2 ports are mapped, ensuring compatibility. Mode 1 activates the extra 2 ports (albeit in a slightly different mapping scheme) so all the features of the V9958 can be used. Modes can be selected by software.

 

Will the stock VDP even be used anymore at all?

 

Not while the OM is plugged in.

 

Will the stock VDP be used on legacy games?

No, only the V9958 will be used. And that is why I am not promising 100% backward compatibility. I have tested a few games with BlueMSX and so far the only thing that couldn't work with the V9958 was the original CV BIOS (as ironic as it is). The BIOS had a bug that tried to access an invalid register in the TMS9928. Since the TMS9928 only has 8 registers, it just ignores the extra upper bits and access to one of the valid registers occurs. However the V9958 has 40 or so registers, so a wrong register was being accessed, causing the BIOS to freeze during boot. But since the BIOS is being replaced, that isn't a problem. Of course I haven't tested all 150 plus games yet, so I still cannot guarantee that a few more games aren't using invalid registers or something like that. Aside that, the V9958 offers very solid backward compatibility, with a few improvements...

 

I guess the above questions would also apply to the sound IC, and the BIOS chip as well.

The Texas PSG can still be used, so no problem there. And the BIOS, as I mentioned, is being replaced. The new BIOS should be 100% compatible though, as after boot the BIOS will switch to a memory page that has a copy of the original BIOS (with that bug corrected).

 

If the module will overide the stock BIOS, does that mean that my "Intro Skip" BIOS will no longer work? That would be a real pain in the ass since I am so use to it these days. If I have to sit through a 12 second title delay on legacy games, that would definately suck. Now my "Intro Skip" BIOS is a selectable feature. Meaning that if you do not press a button during the title screen, it will display as normal. If you do press a button, then, and only then, does it bypass the screen and proceed to the game selection screen. If the new BIOS does overide the stock BIOS, I'd like to supply you with this file to be included in the module if possible.

Excellent, we can include that.

 

If this new module is to plug into the expansion module (front of the console), where will the audio/video outputs be located, in the front of the machine?

 

If so then the A/V cables will need to be routed around/over/under the console to it's rear correct?

 

That is still a good question. Preferably I would like to have the A/V outputs located on one of the module sides. However things like final module size and casing need to be determined before we can be sure of that kind of thing.

Link to comment
Share on other sites

It is quite incredible Eduardo. :D

 

Great piece of work you put in this major project.

 

But how in relation to PAL TV system, compared to NTSC. ?

 

Would it be possible to sell the OM without the Case, because I have a plan to build my own. ?

 

Both the V9958 and video encoder can be set to work in PAL mode. However a slightly different PCB would be required. As long as we have enough people interested in the PAL system, I would be more than glad to create a PAL version.

Link to comment
Share on other sites

Something just crossed my mind: Batari's PCB design (for my homebrew Activision casing project) writes to specific unused addresses for bankswitching and EEPROM access. If RAM is now 24K with the OM plugged in, won't that cause potential problems?

 

I don't think so. I believe how long you are bankswitching by reading from RAM areas, that would be ok. You just won't be able to use the RAM area you use as hotspots.

Link to comment
Share on other sites

So if I am understanding this correct... for the 1% of current games avaialble that won't be compatible we will simply remove the Opgrade Module and play via RF correct? We would treat this similar to the Atari add-on with the exception that we will want to play all the games using the Opgrade module.

 

Yes, correct. If the game doesn't work, simply unplug the OM.

About price, I am pretty sure that the electronic part of the device shouldn't cost more than $100. The question is the casing...

Link to comment
Share on other sites

Something just crossed my mind: Batari's PCB design (for my homebrew Activision casing project) writes to specific unused addresses for bankswitching and EEPROM access. If RAM is now 24K with the OM plugged in, won't that cause potential problems?

 

I don't think so. I believe how long you are bankswitching by reading from RAM areas, that would be ok. You just won't be able to use the RAM area you use as hotspots.

Alright, so the programmer simply defines bogus variables in his code linked to those precise addresses, and must then refrain from using those variables in the actual game... Alright, I guess this will need to be tested and documented eventually, to ensure compatibility between the OM and the bankswitched Activision PCB (I really should give a proper name to this thing...). :)

Link to comment
Share on other sites

Something just crossed my mind: Batari's PCB design (for my homebrew Activision casing project) writes to specific unused addresses for bankswitching and EEPROM access. If RAM is now 24K with the OM plugged in, won't that cause potential problems?

 

I don't think so. I believe how long you are bankswitching by reading from RAM areas, that would be ok. You just won't be able to use the RAM area you use as hotspots.

Alright, so the programmer simply defines bogus variables in his code linked to those precise addresses, and must then refrain from using those variables in the actual game... Alright, I guess this will need to be tested and documented eventually, to ensure compatibility between the OM and the bankswitched Activision PCB (I really should give a proper name to this thing...). :)

 

The original CV has RAM mirroed in the 6000h-7FFFh range, right. That is a 8KB memory space, however only 1KB of RAM actually exists.

Usually we use 7000h-73FFh as our access range to the 1KB, right? So your PCB is using the remaining addresses to bankswich. What happens in the original hardware is that when you read 6000h to bankswitch, in addition to bankswitching you will also read the content of memory address 7000h (because the RAM is mirrored). However I suppose you don't care about the actual value of the RAM, you just want to bankswitch.

The OM will work the same, the only difference is that if you read 6000h, then you will actually read 6000h, instead of 7000h, because now you have RAM there. But I suppose that doesn't matter, because, again, you don't want to actually read the memory, you just want to bankswitch. In this case, as I said in my original message, you shouldn't try to use the hospots to store data, otherwise you will end bankswitching when you write/read to those areas.

I hope it's clearer now. :)

Link to comment
Share on other sites

Something just crossed my mind: Batari's PCB design (for my homebrew Activision casing project) writes to specific unused addresses for bankswitching and EEPROM access. If RAM is now 24K with the OM plugged in, won't that cause potential problems?

 

I don't think so. I believe how long you are bankswitching by reading from RAM areas, that would be ok. You just won't be able to use the RAM area you use as hotspots.

Alright, so the programmer simply defines bogus variables in his code linked to those precise addresses, and must then refrain from using those variables in the actual game... Alright, I guess this will need to be tested and documented eventually, to ensure compatibility between the OM and the bankswitched Activision PCB (I really should give a proper name to this thing...). :)

 

The original CV has RAM mirroed in the 6000h-7FFFh range, right. That is a 8KB memory space, however only 1KB of RAM actually exists.

Usually we use 7000h-73FFh as our access range to the 1KB, right? So your PCB is using the remaining addresses to bankswich. What happens in the original hardware is that when you read 6000h to bankswitch, in addition to bankswitching you will also read the content of memory address 7000h (because the RAM is mirrored). However I suppose you don't care about the actual value of the RAM, you just want to bankswitch.

The OM will work the same, the only difference is that if you read 6000h, then you will actually read 6000h, instead of 7000h, because now you have RAM there. But I suppose that doesn't matter, because, again, you don't want to actually read the memory, you just want to bankswitch. In this case, as I said in my original message, you shouldn't try to use the hospots to store data, otherwise you will end bankswitching when you write/read to those areas.

I hope it's clearer now. :)

Alright, I understand all that. But allow me to submit an example: Let's say I create a 64K (bankswitched) game that is actually designed to fully use the 24K of RAM offered by the OM. This game defines a large array of bytes (a large dynamic map of the game world, for example) which covers a significant amount of RAM between 6000h and 6FFFh. If I access a specific address within that array of bytes which happens to be a hotspot for bankswitching or EEPROM access, will I always trigger an unwanted effect? If yes, then I guess I should limit my array of bytes to the 2000h-5FFFh range...

 

EDIT: I just reviewed the tech notes that batari posted in the PCB thread. He wants to define bankswitching hot spots after 73FFh. With the OM opening up the full 24K of RAM, I would guess that the start of the main stack should remain at 73FFh, otherwise if it's set at 7FFFh, the hotspot will be triggered when the stack reaches a certain height...

Edited by Pixelboy
Link to comment
Share on other sites

What A/V outptuts do you intend on making externally available on the module? Composite video, S-Video? If I'm not mistaken the 9958 outputs R-G-B natively, will this be availalbe as well, or only if it was to be hacked?

 

Will the OM require any additional power, or will it draw all it needs through the expansion slot?

 

I assume for pricing sake, you intend on using an off the shelf enclosure, is this correct or are you considering having one custom made? From my research custom enclosures don't really cost that much, but the engineering to create one, and then the mold are rediculously expensive unless thousands or more would be produced to help offset the cost.

Link to comment
Share on other sites

Something just crossed my mind: Batari's PCB design (for my homebrew Activision casing project) writes to specific unused addresses for bankswitching and EEPROM access. If RAM is now 24K with the OM plugged in, won't that cause potential problems?

 

I don't think so. I believe how long you are bankswitching by reading from RAM areas, that would be ok. You just won't be able to use the RAM area you use as hotspots.

Alright, so the programmer simply defines bogus variables in his code linked to those precise addresses, and must then refrain from using those variables in the actual game... Alright, I guess this will need to be tested and documented eventually, to ensure compatibility between the OM and the bankswitched Activision PCB (I really should give a proper name to this thing...). :)

 

The original CV has RAM mirroed in the 6000h-7FFFh range, right. That is a 8KB memory space, however only 1KB of RAM actually exists.

Usually we use 7000h-73FFh as our access range to the 1KB, right? So your PCB is using the remaining addresses to bankswich. What happens in the original hardware is that when you read 6000h to bankswitch, in addition to bankswitching you will also read the content of memory address 7000h (because the RAM is mirrored). However I suppose you don't care about the actual value of the RAM, you just want to bankswitch.

The OM will work the same, the only difference is that if you read 6000h, then you will actually read 6000h, instead of 7000h, because now you have RAM there. But I suppose that doesn't matter, because, again, you don't want to actually read the memory, you just want to bankswitch. In this case, as I said in my original message, you shouldn't try to use the hospots to store data, otherwise you will end bankswitching when you write/read to those areas.

I hope it's clearer now. :)

Alright, I understand all that. But allow me to submit an example: Let's say I create a 64K (bankswitched) game that is actually designed to fully use the 24K of RAM offered by the OM. This game defines a large array of bytes (a large dynamic map of the game world, for example) which covers a significant amount of RAM between 6000h and 6FFFh. If I access a specific address within that array of bytes which happens to be a hotspot for bankswitching or EEPROM access, will I always trigger an unwanted effect? If yes, then I guess I should limit my array of bytes to the 2000h-5FFFh range...

 

Since your bankswitching scheme uses some of the 6000h-7FFFh range, you shouldn't try to use that memory for anything but bankswitching. In addition to that, 4KB of the 24KB of the expanded memory is reserved for the BIOS XP. So you shouldn't try to use memory mapped in the 5000h-5FFFh range.

With all of that you are left with 13KB of expanded RAM, but you still have the MegaRAM (128KB mapped as 8KB pages in the same range as cartridge).

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