Cartridge ROM mapping

Discuss the games, programs, utilities... and vaporware!
User avatar
@username@
Posts: 320
Joined: Tue Oct 22, 2013 6:59 pm
Location: Scotland

Re: Cartridge ROM mapping

Post by @username@ » Sun Mar 26, 2023 2:46 pm

OK - so it doesn't exist - which is my point.

Assuming kevgal is up for it - I believe it's time to kill off this insane hall of mirrors forever.

All it does is add another level of complexity which is not needed.

How about we look at knocking up a diagnostic image for the hardware - just to ensure that it has been wired correctly?

By dropping the mirroring in each 32K window, you then open up 28K free space in the case of the 4K ROMs for say a copy of the manual or similar.

You could even add an inversion in the hardware to make some of the 32k windows down to 16K/16K selectable - so twice as many.

You can also add BASIC listings with the BASIC ROM - so no looking for audio leads etc and waiting for stuff to load.

I'm sure there are much better ideas people have - but let's at least start by making it easy for the next guy - you shouldn't need to keep chopping up images to get them to work. The software does not care how big it's original ROM was - just that it's at the right memory address to run.

Sound like a plan?
User avatar
MADrigal
Site Admin
Posts: 1189
Joined: Sun Sep 15, 2013 1:00 pm
Contact:

Re: Cartridge ROM mapping

Post by MADrigal » Sun Mar 26, 2023 3:11 pm

All your ideas are excellent to create new things.
The memory map in the above post by Tom is a representation of how the original cartridges had eproms wired in.
You may find a 6k game as a 4k + 2k eproms, or a 8k EPROM with some duplicate or empty data in it. Or a 12k program in a 16k EPROM with 4k duplicated or empty data. It is just the way Vtech operated to save a few bucks in making cartridges. The PCBs themselves had wires, cuts, solderings, bridges etc to accommodate the various changes. I have seen at least 4 different PCBs to accommodate these things. And within these, a lot of variations.
Mirroring is afaik totally unnecessary from the software/program execution perspective, except one particular version of Basic that makes use of it. But that's how it is, the cartridges were made like that.
For new productions, it would be excellent to use the available rom space to store heaps of things, yes!
User avatar
MADrigal
Site Admin
Posts: 1189
Joined: Sun Sep 15, 2013 1:00 pm
Contact:

Re: Cartridge ROM mapping

Post by MADrigal » Sun Mar 26, 2023 3:18 pm

I'm not sure what you mean by "diagnostic image for the hardware" etc.
Do you mean console hardware, or cartridge hardware?
Console hardware: all 32k is available natively. I believe there's hardware mirroring of the first 1k ram, mirrored 4 times. This should be documented in Wizzdom I believe. Easy to verify by pokeing the normal addresses and the allegedly mirrored 1k banks.
Not sure about the 2k bios. Probably not mirrored because the rom space where the bios resides is the same where you could add the 16k ram expansion that results in 14k available and 2k lost because they clash with the bios
Again Wizzdom documents it.
It would be great if the cv had 4k ram, not just 1k but that would require a lot of re engineering of the console hw
User avatar
@username@
Posts: 320
Joined: Tue Oct 22, 2013 6:59 pm
Location: Scotland

Re: Cartridge ROM mapping

Post by @username@ » Sun Mar 26, 2023 3:24 pm

The diagnostic image would be something like a flat 32K which has a page aware program on each page - so it knows if it's at the right place and can check that the other pages are coming up with the correct memory location - as that appears to have been the initial issue here.

It's just to eradicate any error with the cartridge build.

With the MegaSDCart you have all 32K to poke to - so knock yourself out :0)
User avatar
@username@
Posts: 320
Joined: Tue Oct 22, 2013 6:59 pm
Location: Scotland

Re: Cartridge ROM mapping

Post by @username@ » Sun Mar 26, 2023 3:24 pm

To overcome the lack of RAM - both HAPMON and the Shop advert thing had an EEPROM at $4000.
User avatar
MADrigal
Site Admin
Posts: 1189
Joined: Sun Sep 15, 2013 1:00 pm
Contact:

Re: Cartridge ROM mapping

Post by MADrigal » Sun Mar 26, 2023 3:57 pm

@username@ wrote:
Sun Mar 26, 2023 3:24 pm
With the MegaSDCart you have all 32K to poke to - so knock yourself out :0)
That's because the CV maps the 32K perfectly on the cartridge, using the /ROM1 and /ROM2 pins each covering 16K. This is shown in Tom's diagrams of the CV cartridge slot for MK1 and MK2 (which are slightly different). But there are also single address lines that let you map the 32K directly as addresses (not using the /ROM1 and /ROM2 "shortcuts" to get into the 2x 16K banks). But the MK2 has something different in this.
User avatar
MADrigal
Site Admin
Posts: 1189
Joined: Sun Sep 15, 2013 1:00 pm
Contact:

Re: Cartridge ROM mapping

Post by MADrigal » Sun Mar 26, 2023 3:59 pm

@username@ wrote:
Sun Mar 26, 2023 3:24 pm
To overcome the lack of RAM - both HAPMON and the Shop advert thing had an EEPROM at $4000.
The EEPROM at $4000 serves as "bank /ROM1" and is read as normal data. The use of a writable EEPROM (as opposed to an EPROM or PROM) is so that you can store the text permanently, even when the console is switched off.
kevgal
Posts: 71
Joined: Mon Aug 04, 2014 9:19 pm

Re: Cartridge ROM mapping

Post by kevgal » Mon Mar 27, 2023 12:54 am

@username@ wrote:
Sun Mar 26, 2023 2:46 pm
OK - so it doesn't exist - which is my point.

Assuming kevgal is up for it - I believe it's time to kill off this insane hall of mirrors forever.

All it does is add another level of complexity which is not needed.

How about we look at knocking up a diagnostic image for the hardware - just to ensure that it has been wired correctly?

By dropping the mirroring in each 32K window, you then open up 28K free space in the case of the 4K ROMs for say a copy of the manual or similar.

You could even add an inversion in the hardware to make some of the 32k windows down to 16K/16K selectable - so twice as many.

You can also add BASIC listings with the BASIC ROM - so no looking for audio leads etc and waiting for stuff to load.

I'm sure there are much better ideas people have - but let's at least start by making it easy for the next guy - you shouldn't need to keep chopping up images to get them to work. The software does not care how big it's original ROM was - just that it's at the right memory address to run.

Sound like a plan?
Yep the whole mirroring thing is annoying. I tried with empty sections which worked in the emulator but not in the real thing so I gave up, otherwise it would take forever to try each combination .
The Idea was to make a 32k rom cart to add the potential Basic+Listing games to include, and shouldn't be to hard to make it a mix of 16k/16k and 32k slots.
Hopefully greater minds then mine have been inspired!
kevgal
Posts: 71
Joined: Mon Aug 04, 2014 9:19 pm

Re: Cartridge ROM mapping

Post by kevgal » Mon Mar 27, 2023 1:22 am

MADrigal wrote:
Sun Mar 26, 2023 3:18 pm
I'm not sure what you mean by "diagnostic image for the hardware" etc.
Do you mean console hardware, or cartridge hardware?
Console hardware: all 32k is available natively. I believe there's hardware mirroring of the first 1k ram, mirrored 4 times. This should be documented in Wizzdom I believe. Easy to verify by pokeing the normal addresses and the allegedly mirrored 1k banks.
Not sure about the 2k bios. Probably not mirrored because the rom space where the bios resides is the same where you could add the 16k ram expansion that results in 14k available and 2k lost because they clash with the bios
Again Wizzdom documents it.
It would be great if the cv had 4k ram, not just 1k but that would require a lot of re engineering of the console hw
I have changed the 1k ram to 4k. Is good for anything?
User avatar
@username@
Posts: 320
Joined: Tue Oct 22, 2013 6:59 pm
Location: Scotland

Re: Cartridge ROM mapping

Post by @username@ » Mon Mar 27, 2023 3:02 pm

OK - here's a little test utility.

There are two styles in the zip, flat memory $4000->$C000 and romb $8000->$C000 + $4000-$8000.

Hopefully the second one should give what you expect.

Basically each 2K page has a valid program with the address to check in each.

They should be inline, so $4000 == $4000 and so on.

In emulation only the flat one will be successful.

Good luck!
You do not have the required permissions to view the files attached to this post.
Post Reply