On Fri, 19 Mar 1999, Alwin Henseler wrote:
> > 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.
In this way it's really simple! I was thinking that you had created an
additional port to write enable or disable.
> > 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:
> 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:
> 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.
Ok, now I undestand. For the most part of Megaroms it's not important. But
it's good to know! Thanks for these details that I didn't know.
> > Is Crazy Train really made by Sony? AFAIK, it's made by Konami.
>
> Doesn't the title screen show the name Sony?
Because my diskdrive is broken, I can't see. But I think that it's Konami.
Perhaps I can download from Funet and test it in BrMSX.
> > 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.
For page 3 the ID code is 41 42 xx xx or 43 44 xx xx?
> 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.
Yes, everything becomes clear when hardware descriptions are known.
> > 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!
Why someone would do it? Is it some kind of unuseful work? But my main
problem was that I couldn't copy River Raid and Beam Rider cartridges.
> > 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.
Perhaps it's only an ENASLT limitation. But ENASLT isn't used while
cartridges are being reserched over the slots. AFAIK, the startup routines
use only CALSLT.
> > > 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....
Good for you! Nowadays, I can't spend an whole day tracing code, only 2
hours at maximum. :-(
> > 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.
I know, the IC was designed this way, but what was the idea behind block
numbers can't be selected via pages 0 and 3? Nobody knows.
> > > 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?
Research for specific data in all blocks! Or, as in MegaramDisk, you can
keep the block numbers in software-reset and select blocks 3, 2, 1 and 0
after a hardware-reset.
> 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.
But if you load an adapted version of a Megarom game, it's possible that
after a software reset it won't be restarted. You have an advantage fixing
startup block numbers, but your the disadvantage that software won't be
executed (supposing that it behaves like a Megarom). So, I still don't
know if it was a good solution.
In a MSX1 with a Memory Mapper cartridge you don't have this feature.
> > > 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.
All right, I was thinking that this happens with software reset, too.
> > > 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.
This startup circuit puts only the block 0 in area 4000h or put also
blocks 1, 2 and 3 in area 6000h, 8000h and A000h?
> > 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.
Thinking in this way, MegaramDisk was a good solution, because after a
hardware reset it puts its ROM to the bus, and keeps the current state
after a software reset.
> 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.
Good idea, but if Megaram is connected in a slot "previous" to the RAM
slot, the system will write a byte in Megaram while testing for RAM slots,
and will select another block in area 4000h. So, my ramdisk software
(loaded in block 0 selected at 4000h) won't run with my Megaram startup
circuit!
> > > 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.
Then your idea is to create a circuit that disables write and disables
block selecting simultaneously, and enables block selection or write after
an access on port 8Eh? That's not compatible with the most part of
Megaroms!
> > > 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.
Good idea! But not so good for machines with only 64kb of RAM, that is
always full.
> > 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.
But how about with Megaram alone?
> 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?
The best idea!
Greetings from Brazil!
-----------------------------------------------------------------
Marco Antonio Simon Dal Poz http://www.lsi.usp.br/~mdalpoz
[EMAIL PROTECTED] "Apple" (c) Copyright 1767, Sir Isaac Newton
/"\
\ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML
X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
/ \
****
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/)
****
