Cartridge ROM mapping

Discuss the games, programs, utilities... and vaporware!
User avatar
MADrigal
Site Admin
Posts: 1267
Joined: Sun Sep 15, 2013 1:00 pm
Contact:

Re: Cartridge ROM mapping

Post by MADrigal » Mon Mar 27, 2023 5:47 pm

Thanks @username@ excellent stuff!!

I look forward to someone having real hardware being able to test and post results :)
User avatar
Scouter3d
Posts: 676
Joined: Mon Jun 28, 2010 7:02 am
Location: Wien
Contact:

Re: Cartridge ROM mapping

Post by Scouter3d » Mon Mar 27, 2023 6:33 pm

Hi, and here are some real-hardware-test-results...

I used the original Multicart and one of my Everycarts (based on the CSL PCB)

The Multicart uses the "swapped" ROMs, the Everycart uses "flat" addresses...

And the results were as expected:

First the Multicart with the fitting "memcromb.bin":
20230327_182616.jpeg

Then the same ROM (wrongfully) in the Everycart: (the two 16k areas are switched...)
20230327_182811.jpeg

With the fitting "memcflat.bin" the Everycart also completes the test successfully :0)
Great for checking the mapping :0)

Cheers, TOM:0)
You do not have the required permissions to view the files attached to this post.
User avatar
MADrigal
Site Admin
Posts: 1267
Joined: Sun Sep 15, 2013 1:00 pm
Contact:

Re: Cartridge ROM mapping

Post by MADrigal » Mon Mar 27, 2023 6:39 pm

Excellent thanks Tom!
Does this confirm that there's no mirroring made via hardware by the console?
All 32k ram area accessible normally?
L
User avatar
@username@
Posts: 335
Joined: Tue Oct 22, 2013 6:59 pm
Location: Scotland

Re: Cartridge ROM mapping

Post by @username@ » Mon Mar 27, 2023 7:36 pm

The "mirroring" is an artefact of missing address lines, nothing more.

The console is just reporting what it sees, as without the required address lines, you'll just wrap to what's actually connected.

This is great news as it means folks with any multicart can start thinking of how to practically use the available space.

Let the updates begin ....

For me, next I'll knock up a simple proggie to create 32K images with the ROM at the correct memory location.

Sorry for the edits - VPN keeps dropping !!

@Tom - as always - thanks for taking the time to run these - it's very much appreciated.

Although memc is pretty dumb - it should be enough to check own build multicarts, just in case you employed a drunken lobster to spotweld the pcb for you :)

@kevgal - Hope you get the same results!
kevgal
Posts: 71
Joined: Mon Aug 04, 2014 9:19 pm

Re: Cartridge ROM mapping

Post by kevgal » Mon Mar 27, 2023 9:54 pm

Yep, more experimenting.
I think the main issue I'm having is identifying what roms were originally 2 eproms or 1 eprom.
2 eprom games take up the whole 32k space while single eprom games occupy the lower 16 space (as far as what the hardware 'sees')
This means theres no way of knowing what games that are less than 16k were 1 or 2 eproms without trial and error.
May have been better if they were all stored as either 16k or 32k regardless of original size? Or at least identified as single or multiple roms (Rom1, Rom2) ?
I also suspect the 6k games are the wrong way around and the 8k versions are correct, not sure why they work in the emulator though?
User avatar
@username@
Posts: 335
Joined: Tue Oct 22, 2013 6:59 pm
Location: Scotland

Re: Cartridge ROM mapping

Post by @username@ » Mon Mar 27, 2023 10:15 pm

The ROMs and subsequent images are really straight forward.

The Multicart is just a sliding 32K window - hence the 32K images.

Each 32K image is arranged as two 16K blocks - ar$e backwards - so high memory first.

This gives you, in 4K blocks

$8000
$9000
$A000
$B000
$4000
$5000
$6000
$7000

So - take the simplest ROMs - 4K - they just sit at $B000. All ROMs have vectors which must be present at $BFE0

$8000 == EMPTY
$9000 == EMPTY
$A000 == EMPTY
$B000 == SONIC INVADERS
$4000 == EMPTY
$5000 == EMPTY
$6000 == EMPTY
$7000 == EMPTY

For an 8K ROM, it would be

$8000 == EMPTY
$9000 == RMPTY
$A000 == AUTOCHAS
$B000 == AUTOCHAS
$4000 == EMPTY
$5000 == EMPTY
$6000 == EMPTY
$7000 == EMPTY

If you can shift the mindset to memory location rather than individual EEPROM size - life will be much easier.

There is only one ROM - an early version of BASIC which has one bit inverted - so you can choose to either waste 4K or just flip the bit.

Tomorrow I'll get an image thingy done - which may make your life much easier :)
User avatar
@username@
Posts: 335
Joined: Tue Oct 22, 2013 6:59 pm
Location: Scotland

Re: Cartridge ROM mapping

Post by @username@ » Tue Mar 28, 2023 11:30 am

ROM image creator.

Knocked up in lunch break - so let me know if you hit any issues.

I took the executive decision to fix the byte at $7223 for BASIC - saves writing and having a panic attack :lol:

Good luck!
You do not have the required permissions to view the files attached to this post.
User avatar
MADrigal
Site Admin
Posts: 1267
Joined: Sun Sep 15, 2013 1:00 pm
Contact:

Re: Cartridge ROM mapping

Post by MADrigal » Tue Mar 28, 2023 12:30 pm

Thanks pal. I should publish the fixed basic on the cvemu website as a download rom
User avatar
MADrigal
Site Admin
Posts: 1267
Joined: Sun Sep 15, 2013 1:00 pm
Contact:

Re: Cartridge ROM mapping

Post by MADrigal » Tue Mar 28, 2023 6:00 pm

kevgal wrote:
Mon Mar 27, 2023 9:54 pm
2 eprom games take up the whole 32k space while single eprom games occupy the lower 16 space (as far as what the hardware 'sees')
The key with commercial (VTech) CV games is not how many EPROMs, but their size and how they are soldered in the PCB. That determines where each EPROM is mapped.
6K games: Planet Defender, Deep Sea Adventure, Tennis and Tank Attack which you may find in original cartridges as:
* 1x 4K + 1x 2K EPROMs, or
* 1x 8K EPROM or PROM (with 2K either empty/dummy/random or a repeat of the 2K portion and in any case that would not be used)
All 6K data stays in a single 16K bank in this case being 8000-BFFF, often "mirrored" as a result of PCB logic/missing data lines
Other commercial "multi-EPROMs" programs are 10K (8+2), 12K (8+4) and 18K (8+8+2). But I have also found one BASIC interpreter (12K program) in a single 16K PROM. And potentially the 18K game could exist as 16+2. Never seen personally but logically it may well exist.

Note I am talking about *original* VTech games, with PCBs/EPROMs configured to save money on EPROMs, or based on VTech's availability of EPROMs.

Earlier cartridges featuring 6K games would have 4K + 2K EPROMs (cut on costs/etc), and later versions of the same game would almost always have 8K PROMs (non-rewritable)

With new (homebrew) games we can do whatever we want, even 32K games. With some tweaks (to be confirmed though) I believe one can make a 48K game using the usual middle 32K (4000-7FFF + 8000-BFFF) plus the upper 16K C000-FFFF bank. Part of it (F800-FFFF) is the 2K BIOS, but there is a way to "disable" it and make use of that data space if needed.

Hope this helps.
User avatar
Scouter3d
Posts: 676
Joined: Mon Jun 28, 2010 7:02 am
Location: Wien
Contact:

Re: Cartridge ROM mapping

Post by Scouter3d » Tue Mar 28, 2023 6:20 pm

MADrigal wrote:
Tue Mar 28, 2023 6:00 pm

With new (homebrew) games we can do whatever we want, even 32K games. With some tweaks (to be confirmed though) I believe one can make a 48K game using the usual middle 32K (4000-7FFF + 8000-BFFF) plus the upper 16K C000-FFFF bank. Part of it (F800-FFFF) is the 2K BIOS, but there is a way to "disable" it and make use of that data space if needed.

Hope this helps.
Hi @Madrigal, thank you very much for your explanation of the different original-cartridge populations/mutations.

A bit, of what you mentioned above (using 48k...) is done in the CSL Cart (uses the highest 16k for BIOS and BASIC and provides 32k RAM), and in the MegaSDCart (Patched and expanded BIOS, and menu-program in the highest 16k) with a bit of trickery it also would be easy to access an even greater ammount of RAM / ROM space thru page-swapping...

One idea for pageswapping would be to use a few unused addresses in the highest 16k to select a Block of RAM/ROM to swap accessing this address would increment the "pagenumber" to swap in... The MegaSDCart allready uses quite a similar technique to communicate between Creativision and the Arduino.

Cheers, TOM:0)
Post Reply