Marco Antonio Simon dal Poz <[EMAIL PROTECTED]> wrote:
> > I still have a 256K memory mapper, where I added a write
> > protect-switch for similar purposes. Make sure it's write protected
> > when starting your machine (so that it's not used as normal RAM), put
> > some software in it using a debugger or so, flip the write-protect
> > switch, and voila, the RAM just became ROM, reset & overwrite-proof.
> > Can enormously speed up some devolopment or research work, if you
> > have a use for it.
>
> Yep, that's very useful. How did you make this write-protection that can
> be enabled or disabled? This sounds very interesting if you have another
> slot with RAM.
Simple: cut some signal that enables writing to the (D?)RAM, put a
switch in between, and a few KOhm pull-up resistor on the
disconnected input(s). Similar to SCC cartridge switches.
> > > So, you can use Megaram on page 0 and page 3, but when you're in "block
> > > select mode" and do a LD A,04h / LD (0000h),A the block 4 is selected for
> > > the area 0000h-1FFFh and also for 8000h-9FFFh. The opposite is also valid,
> > > when you do a LD A,04h / LD (8000h),A the block 4 is selected for the area
> > > 8000h-9FFFh and also for 0000h-1FFFh. That's exactly what you said about
> > > many Megaroms (the most part of Konami ones).
> >
> > No, that makes this the same as with SCC's. Other Konami megaROMs
> > have a different arrangement, and non-Konami megaROMs might not
> > do this at all.
>
> Why does this make the same as with SCC's? AFAIK, all Konami Megaroms
> behave in this way. And I don't know why Konami had changed LD (4000h),A
> by LD (5000h),A and so on.
Nope!
For SCC's:
4000-5FFFh and C000-DFFFh have same contents
6000-7FFFh and E000-FFFFh " "
8000-9FFFh and 0000-1FFFh " "
A000-BFFFh and 2000-3FFFh " "
With a hardware reset, these ranges are reset to block 0, 1, 2 and 3,
respectively.
Hardware speaking: address line 15 (A15) is a don't care / ignored.
For some other Konami megaROMs (like Vampire Killer), it works like
this:
4000-5FFFh and 0000-1FFFh have fixed contents: block 0
6000-7FFFh and 2000-3FFFh have same contents
8000-9FFFh and C000-DFFFh " " "
A000-BFFFh and E000-FFFFh " " "
I'd read: address line 14 (A14) is a don't care.
With a hardware reset, the memory ranges are initialised as with the
SCC's (block 0 (fixed), and 1, 2, 3 selected)
This is just 2 different megaROM types. For other megaROMs, this
might be yet different again. And even megaROMs using the same mapper
IC need not always work the same, there's always variations possible
in how things are connected inside a cartridge.
> Is Crazy Train really made by Sony? AFAIK, it's made by Konami.
Doesn't the title screen show the name Sony?
> > Then I figured, maybe in the original cartridge, it once read "CD"
> > (the MSX-2 subROM is recognised by this, also occupying page 0), and
> > was changed in those crack versions to "AB", for whatever reason.
> > Until I got my hands on an original of Athletic Land, and: it
> > occupied page 0, and it started with "AB", and with start-address in
> > page 0.
> > But how could this thing start then?
>
> I didn't know that 41 42 xx xx can't be used for page 0. Can it be used
> for page 3?
No, "A", "B", xx, xx only works for pages 1 & 2. Ofcourse, there's
nothing preventing you from putting code or data in a ROM in page 3,
just a bit difficult to use.
> > But then I found out, that this cartridge also showed it's contents
> > in all other pages (4000-FFFFh). It was only 16 K, but simply
> > mirrored 4 times in the cartridgeslot (simply said: address lines 14
> > & 15 not decoded, but don't cares).
>
> Then there is a great trick!
In hardware, it's easy to understand: if you have a ROM that should
be in 1 page only, you have to combine signals for
(read+slotselect+desired memory range accessed). If you just combine
(read+slotselect), your ROM shows up in all pages. It looks a 64K ROM
then, but it's simply a smaller ROM that responds to several
address ranges. Nothing mysterious about that.
> Does River Raid and Beam Rider do the same? A long time ago, I had tried
> to copy these cartridges, but they were in page 0. After had copied it, I
> disassembled it and I saw that it was really a game made to run in page 0.
> But the copy didn't work! Last week I downloaded them from funet, and I
> saw that they were made to run in page 2, with internal calls to page 2.
> So, I couldn't understand: the original cartridge has internal call to
> page 0, with all the code in page 0, and the version from funet were made
> do run in page 2? What happened with these games?
There exist different versions (updates? bugfixed?) of some
cartridges. Athletic Land for instance, exists in page 0- and a page
1-version. And I've got 3 different versions of Monkey Academy. Their
contents is shifted compared with both others (changing jumps and
calls throughout the ROM), but if you play them, I couldn't find any
difference!
> Yep, I don't know why ROM doesn't search for cartridges in page 0. Perhaps
> this is due to hardware limitations (pins PAGE1, PAGE2, PAGE12 or
> something like that).
I don't know either. It's no hardware limitation, though.
> > Yet another MSX mystery solved....
>
> Yes, and there's no documentation in this level. This was very well
> solved, how many days did you spend tracing the ROM?
Not days!....couple 'o hours....
> My question is: why the data behavior is symmetric (pages even and pages
> odd) and the block-switching isn't, I mean, why in Konami Megaroms the
> block number can't be selected via pages 0 and 3?
Maybe to prevent accidental page-switches? Anyway, for megaROMs it's
not difficult: most of the IC's used, simply get connected to all the
higher address lines, so that they can decode ANY combination of for
instance address lines A12-A15. What is done with that, is decided by
the IC design.
> > If you have a memory mapper, the (MSX2 and higher) BIOS will
> > select blocks 3,2,1 and 0 for page 0,1,2 and 3. So you will
> > always have the same blocks in there after reset, no matter
> > what mapper blocks were selected at reset-time.
>
> If a program selects the block 15 in page 1 and have a 41 42 xx xx, it
> won't be executed after a reset. I don't think that it's a good feature of
> Memory Mapper.
I do. How else should you know what blocks are selected after
restart, when mapper registers can be read-only, or reading back
unreliable?
For an extension, no problem: you can set it any time before use. But
a memory mapper is mostly already in use when the rest of it is
accessed. When blocks selected were not defined after reset, a
program resetting a mapper could be switching away itself ! So this
is as it *should* be.
>
> > In the MSX2+ and Turbo-R some bits will always be erased, when memory
> > is counted (prevents software from 'coming back' after reset).
>
> Is it good or bad?
Good! There is some software that starts by resetting itself, and
beacuse a software reset does NOT cause this clearing of memory, this
still works on 2+ and Turbo-R.
> > With a SCC cartridge, you will always find certain blocks in each
> > memory area after reset, otherwise the game might not re-start each
> > time.
>
> You're saying that SCC cartridges have an internal startup circuit, aren't
> you?
A hardware reset just *resets* these block selections to pre-defined
values, just like it resets the Z80's program counter to 0.
> Yep, and I think that's good, because when you turn on your MSX, the state
> is completely undefined, but there's no useful data in Megaram, so the
> current selected blocks aren't important. But after a reset, the
> conservative characteristics are ever used to allow the software loaded
> into Megaram to be restarted properly. This can happen specially when a
> block number isn't changed in region 4000h-5FFFh or 8000h-9FFFh.
It stays a disadvantage. Best would be to have a hardware reset
disable the write-enable state, select a fixed block in some
memory range and disable blockswitching as well, until its I/O
port(s, for megaRAM-disk) is accessed. At hardware reset only! A
software reset IN ITSELF doesn't do a thing to hardware, and leaves
settings you make, alone.
That would make it suitable for use as a reset-proof (and bootable!)
RAMdisk, and prevent it from being seen as RAM after power-on. For
software using the megaRAM, the very first access to its I/O-port
would make it behave as a normal one.
> > Suppose you want to make a RAMdisk-software using the megaRAM, that
> > you want to be reset-proof.
> > *If* a reset would force the megaRAM in block-select (read-only)
> > mode, and select say, block 0, for some/each memory range, then a
> > reset would make that RAMdisk write-protected at once, and you could
> > just put initialising code in that block 0.
>
> Then you have a problem: when you make a reset, the ROM looks for slots
> with RAM, and when a byte is written to each slot, the Megaram, in block
> select mode, will have another selected block, that difficultly will be
> the same that was selected. Then, the RAMdisk-software won't be run.
That would be fixed with the above.
> > And having the same block selected _all_ the time in some memory
> > range, could be a big restriction for that RAMdisk-software.
>
> Yep, but it's unavoidable, because the RAMdisk-software makes the
> management of the Megaram used as a ramdisk, and to do it, it's necessary
> that the software be present to the bus, so one memory block will be
> fixed. I think that this restriction is much worse with Memory Mapper.
Not so! Software inside the megaRAM could copy some of itself into
other RAM, and call that copied code. That code could even switch
away the megaRAM entirely. Many diskROMs do this kind of thing.
> [...mapper detection routine...]
"MARUJO" <[EMAIL PROTECTED]> wrote:
>> For mapper size detection, I have seen things like:
>> OUT (port),xx
>> IF IN (port)=yy THEN "big enough" ELSE "not big enough
>> mapper"
>
> Registers aren't user RAM memory.
> Registers only controls expanded address bus!
(port) = mapper-port (FC-FFh)
> I don't believe it. Full detection if 8 cartridges of
> different quantities of RAM ? Withouth IN A, (F_h) ope
> rations ?
Yup, can do that, and no IN,(xx) in it.
BTW: MemMan does this too, or should be able to.
And MSX-DOS 2 as well...
And 2+/Turbo-R on a hardware-reset....
> [... ramdisk software using Megaram blocks instead of using an EPROM ...]
> > > This would require a disk to be specially booted to convert Megaram to
> > > Megaram-Disk. But Megaram-Disk is supposed to work like a disk-interface,
> > > and like that, it should work fine when it's connected alone, without
> > > disk-drives. Then, there's no way to make it without an EPROM.
> >
> > If you would modify it to have a clearly defined state after reset,
> > you could.
>
> But how could I load the RAMdisk-software? Don't say by tape!
Examples:
With harddisk-interface & megaRAM connected, install megaRAM
software. Reset, and: harddisk + megaRAM-disk available.
Install software from floppy. Reset with CTRL: drive A=megaRAM-disk,
B=floppy (or the other way round).
With battery backup-upped SRAM: install megaRAM-software on any
machine with a diskdrive, then use megaRAM-disk on ANY machine (with
OR without other drive).
Or use Flash EPROM for the megaRAM?
Greetings,
Alwin Henseler ([EMAIL PROTECTED])
http://huizen.dds.nl/~alwinh/msx MSX Tech Doc page
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****
