On Sun, 28 Mar 1999, Alwin Henseler wrote:
> > > > Is Crazy Train really made by Sony? AFAIK, it's made by Konami.
> > >
> > > Doesn't the title screen show the name Sony?
>
> We were both right. The title screen shows: "Sony HitBit - Crazytrain
> - (c) 1983 Konami". So I guess, that's: made by Konami, 'presented'
> by Sony.
> Can we rest this silly item now?
Sure! But I don't think it's silly, because it's part of the MSX history.
> > For page 3 the ID code is 41 42 xx xx or 43 44 xx xx?
>
> Alex Wulms explained it quite well: you can put your ROM software in
> any page(s) you like. The CSxx-signals are not essential, but just
> for the convenience of the cartridge makers. The BIOS only searches
> for "AB" in pages 1 and 2. And MSX2 and higher for "CD" in page 0
> (subROM).
Ok, now that's 100% clear.
> There's no direct relation between each piece of your ROM software,
> and the need to have "AB" or "CD" in some location. This only needs
> to be at A place where it is searched, so that your software can
> start.
It depends of the page for that the software was designed. CD for page 0
and AB for page 1 or 2. The rest is tricks with the mirror effect.
> Examples: most 32K ROMs, and megaROMs have "AB" only in page 1. THAT
> is found, the init address called, and the code there determines in
> what slot it is, selects that slot in page 2 as well, and if needed,
> continues with ROM mapper initialisation.
Right, all Konami with at least 32kb of ROM has this routine (I verified
these games by myself).
> There's no reason either why you couldn't have "AB" codes in pages 0
> or 3, either. However the BIOS will only FIND these "AB" codes if
> they're in pages 1 or 2. So if you want your software to start, you
> should ALSO have this "AB" and init-address in page 1 OR 2 (or
> both). If you have "AB" in pages 0 and/or 3 ONLY, and not in pages 1
> or 2, then your software won't be found/called.
All right, then we should use the mirror effect. It's interesting that a
trick is part of the standard!
> > [...different cartridge versions...]
> >
> > 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.
>
> Why? Bugfixes? 'Hooks' for easy development/testing? Who cares? They
> just are.
Since I couldn't copy these cartridges, I care, because there's some
hidden trick that I couldn't understand.
> > > 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.
>
> It's NO hardware limitation. And it's NO limitation of slotswitch
> routines either. The routines like CALSLT, RDSLT, WRSLT, ENASLT etc.
> can all work with ALL 4 pages. Only condition is that the stack is
> not in the same page you are accessing.
No way! ENASLT can't work in page 0, because the OUT (A8h),A command, that
does the slot switching, resides in page 0. All the other routines (RDSLT,
WRSLT, CALSLT, CALLF) do a CALL to F38xh, where the OUT (A8h),A resides,
and so they can't work in page 3.
Conclusion: the condition is that the PROGRAM COUNTER is not in the same
page you are accessing.
> > 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?
>
> A hardware reset resets all these 4 memory ranges to blocks 0,1, 2
> and 3, simultanious. The same goes for most other Konami megaROMs.
> How this is for other megaROMs, I don't know.
Ok, my question was about reset put only block 0 or all four blocks.
That's clear now.
> > [...megaRAM initialisation...]
> > 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!
>
> The idea is like this: you add another single bit register. This gets
> cleared or set with a hardware reset. In this hardware reset state,
> this bit disables both blockswitching and writing to the megaRAM. Any
> ACCESS to the megaRAM's I/O-port toggles this bit, re-enabling the
> functions AS THEY ARE FOR THE MEGARAM.
>
> So this extra 1-bit register wouldn't get involved in normal megaRAM
> control, but only toggle between "disable normal megaRAM functions"
> and "enable normal megaRAM functioning".
But, if I load a Megarom game into Megaram, play the game, and do a
hardware reset, with your single bit register Megaram will behave like a
standard ROM cartridge, and the loaded game won't run (and will put the
MSX in crash!).
> Ok, it would take some more electronics. That's for the designer to
> decide: give it more functions, making it more powerfull or
> versatile. Or keep the hardware as simple as possible, limiting its
> possibilities.
Your idea is interesting, but is incompatible with almost all Megarom
games. Perhaps it's possible to compatibilize them.
> > > > But how could I load the RAMdisk-software? Don't say by tape!
> >> (..)
> > But how about with Megaram alone?
>
> What's the use for a megaRAM alone, if it's normal RAM based
> (clearing data with power-off)? Don't you always need another drive
> to save the data more permanent?
Well, my idea was to put a battery in my Megaram, and modify the ROM code
to not erase the MegaramDisk contents after a (soft or hard) reset.
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/)
****
