Marco Antonio Simon dal Poz <[EMAIL PROTECTED]> wrote:
> > Thank you for your clear, and complete description.
> > Based upon this, I am one of those people that COULD build a MegaRAM,
> > or make a new/different design of it, if I wanted to.
>
> That's great! It's becoming hard to find MSX people who handles with
> hardware nowadays.
I don't! I did, and I still can/know how to, but I don't 'do' in MSX
hardware anymore these days (sorry)
> > > Yes, no problem. About emulation, BrMSX already emulates some Megaram
> > > models.
> > So I noticed. I just wondered what the use was (still do I think).
> > After all: you can run modified MegaROMs in it (or originals, with
> > the right loader), but what's the use if the emulator can emulate the
> > original MegaROM itself?
>
> We can get the MSX disks with Megarom games ready to run in Megaram and
> run it directly in the emulator, without the necessity of extracting the
> .ROM files from the .DSK file. The main reason is to emulate, in the best
> possible way, hardwares that people used to use in MSX.
That's what I meant! See: You have some original megaROM. Someone
makes a crack of it, or a loader that can run it in hardware like the
MegaRAM. Then there's an emulator.
You say, logical is: have the emulator emulate that MegaRAM, so you
can run these same cracks, modified versions, or with special loader.
I say, logical is: emulate the megaROM itself, with the original ROM
in there. If it can do that, no megaRAM emulation needed for that
purpose.
> > As a pure piece of MSX hardware, this sounds quite usefull, but for
> > emulators, I don't really see the point.
> It's just another kind of memory expansion.
That would best describe it.
> For my personal use, that's a special utility: I use to load "Mega Assembler"
> to Megaram, just to keep the standard RAM (or Mapper) free. I use Megaram
> to simulate the presence of original cartridges.
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.
> > There is one thing you should know:
> > Many megaROMs (most Konami's at least) also have their ROM contents
> > available in unused pages (address 0000-3FFF and C000-FFFFh) of
> > their cartridge-slot.
> > For instance for SCC's, the same block you read at:
> > 4000-5FFFh can also be read at C000-DFFFh
> > 6000-7FFFh can also be read at E000-FFFFh
> > 8000-9FFFh can also be read at 0000-1FFFh
> > A000-BFFFh can also be read at 2000-3FFFh
> > (SCC registers excluded in this case, they are always on the same
> > addresses)
> > Note: the arrangement above is different with other megaROM types.
>
> I'm sorry, I had forget this detail about Megaram: Megaram has only 4
> registers for block numbers. This implies that, when you select a block
> over page 0, it will be selected on page 2, too. The same is valid for
> page 3, that acts on page 1, too.
>
> 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.
BTW:
-------
Some non-megaROM use this effect too. Interesting story:
Some time ago, I broke my head on this puzzle: there exist some (16
K. or so) ROMs, that have their software run in the 0000-3FFFh range
(jump/call-addresses all in that range). Sony's CrazyTrain and some
versions of Konami's Athletic Land are examples of this.
These cartridges start with the well known ASCII "AB", and what
follows is a start-address somewhere in page 0.
Okay, so what?
The point is, that the MSX doesn't recognise a cartridge in page 0,
if it starts with "AB". (!?!!??)
I thought for a while, that maybe the crack authors re-arranged all
those jump- and call-addresses. Naaahh, too much work.
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 traced the entire memory-searching procedure of my MSX, and no: it
searched for "AB", but only in pages 1, and 2. Not in page 0 or 3.
It did search in page 0, but for codes "CD" (I wouldn't know if a
MSX-1 also does that), not "AB" here.
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).
Still, that didn't explain it: in page 0 the MSX would find "AB", and
leave it alone, in page 1 it would find the same "AB", but call an
address in page 0 upon that, where at that time the BIOS would be
switched in.
And no, not some special address in the BIOS, where a few convenient
codes happened to be, either.
I re-traced the memory-searching procedure of my MSX once again, and
then it hit me: the BIOS used interslot-reads and writes for
searching through the slots, and an interslot-call for calling the
init-address of cartridges.
To understand the significance of this, I will show it in
pseudo-code:
Conditions: BIOS & BASIC ROM switched in 0000-7FFFh, RAM
already selected at 8000-FFFFh.
Read (4000h) from test-slot (using interslot-read)
=ASCII "A"? (yep)
Read (4001h) from test-slot
=ASCII "B"? (yep)
Read init-address from (4002h) in test-slot
Make interslot-call to that address, in test-slot
So, the cartridge is started with an interslot-call to page 0, using
start-address and bytes "AB" found in page 1...!!!
If the BIOS-ROM would select each slot, and investigate the bytes
directly, this wouldn't work.
And if this cartridge was only visible in one page, it wouldn't work
either.
Yet another MSX mystery solved....
> In Megaram, you can use the page 0 and page 3 to do a block-switch, that
> affects also the page 2 and page 1, respectively. I think that this is
> also valid for Konami Megaroms. Why did you say that we can't do a
> block-switch of a Konami SCC Megarom?
Just what I wrote. I'm not 100%, but fairly sure of it: for instance,
whatever block you switch in a SCC at address 8000-9FFFh, can also be
read through 0000-1FFFh of the same cartridgeslot. But you can select
that block ONLY by writing to 9000-97FFh (exact address doesn't
matter). Writing anywhere in the 0000-3FFFh area simply has no
effect.
> > If the MegaRAM cannot be read through 0000-3FFFh or C000-FFFFh, that
> > would be a clearly different behaviour than a Konami (or some
> > other) MegaROMs.
>
> I had forget to explain. Megaram can be read and written in pages 0 and 3,
> and can also be "block-selected", but with the mirror effect over the
> pages 2 and 1.
>
> > Not too important, but good to know.
>
> For me it's very important. In my software SDC, I almost used the page 0
> in Megaram. Accidentally I decided to make the program in page 0 and use
> Megaram in page 1 (and RAM in page 2 and 3), so we can use that in MSX
> with only 32kb of RAM (that's because my code was compiled to be written
> in an EPROM, of course without an EPROM you'll need 64kb of RAM).
I do believe it's usefull to have that mirror-effect. It makes the
hardware simpler, it makes it more versatile, and side-effects are
minimal.
The same with the block-select address range: taking the entire same
memory area the block itself occupies as a block-switch range,
probably gives very few problems, and allows many different megaROMs
to run without modifications (and makes the hardware yet more
simple).
> (megaRAM-state after reset)
I meant this: if some program is doing something with a megaRAM, and
you push the reset button, whatever happens after that reset depends
on whatever state the megaRAM was in at the exact time you pushed the
reset button.
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.
In the MSX2+ and Turbo-R some bits will always be erased, when memory
is counted (prevents software from 'coming back' after reset).
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.
With the MegaRAM, all this is not fixed, but depends on how the
megaRAM was set when the reset occurs.
That's what I meant with: reset state "undefined".
Why is this important?
-----------------------------
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.
But if you don't have that reset-effect, the only way to have that
initialising code start on every reset, would be to keep -some- block
ALWAYS selected in for instance 4000-5FFFh range, so that it will
always be there, no matter when the thing is reset.
And having the same block selected _all_ the time in some memory
range, could be a big restriction for that RAMdisk-software.
> > Simple and good method: select (in descending order) each possible
> > block, write its number in it in at some test address, and then
> > (starting with block 0) check up until which block the block number
> > matches what you find at the test address when selecting each block.
> > In pseudo-code:
> >
> > FOR n=255 TO 0 (decending order!)
> > Select block <n>
> > Write <n> to test-address
> > NEXT n
> > FOR n=0 TO 255
> > Select block <n>
> > IF (testadress)=<n> THEN NEXT n ELSE highest block found (=n-1)
>
> I think that this method has a fault: if a 256kb Mapper has 8-bit
> registers and the blocks from 16 to 255 points to null memory, this
> technique can detect 17 blocks insted 16, because when you read the block
> number 16 you get junk, and this junk can be 16 (the probability is
> 0.390625% but it's not 0%).
Okay, test each block to be RAM first ("junk" won't pass then).
Anyway, chances of reading any "null" value other than FFh is small,
and reading a value of 16 (00010000 binairy) is more like 0.001%
> > I wrote a superbly constructed memory mapper detection routine once.
> > Detects ALL (including full 4096, those stupid 192, 384K etc., or no
> > mapper at all) sizes correctly, doesn't change the contents of the
> > mapper, AND does it without using any buffer memory.
> > (mapper size detection built in DOS2 cartridge uses 256 byte buffer
> > memory for that, my routine does without).
>
> That's very good! Can this routine detect multiple mappers installed in a
> MSX?
What's so difficult about that?
Select 1st slot - test mapper size
Select next slot - test mapper size
Select next slot - test mapper size
....etc.
Add total sizes, put it in a table if you like - what's the big thing
here?
> I am thinking in redesign my routine for Megaram size detection, allowing
> non-standard sizes to be detected. And I would like do detect multiple
> Megarams, what I have never made. I think that it would be very good if
> the Mapper-detection and Megaram-detection routines were the same (unique
> routine for all kinds of memories!)
Shall I do that? I'm good at this kind of thing ;-))
> > BTW: Instead of adding the extra EPROM to create a MegaRAM-disk,
> > wouldn't it be easier to put this disk-driver software in the MegaRAM
> > itself, together with the contents of the RAM-disk?
> > (maybe with some extra reset circuitry, or SRAM battery backup).
> > This would also allow really easy update of such disk-driver
> > software.
>
> 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.
This need not interfere with other MegaRAM use. And if you want to
reset the machine with the megaRAM in some other state, simply set
that state, and do a software-reset.
>> (Brazilian vs. European floppy-controllers)
>
> So do I. Recently, Alex Wulms explained to me how these FDCs work, and
> they work like the port based FDC. The main difference is that addresses
> 7FF8h-7FFBh is mapped to ports D0h-D4h. There are other minor differences,
> but they are not important.
You mean the same FDC (2793) is used, just put on I/O ports instead
of memory-mapped? Could you check that, if it's the same IC type?
BTW: I hope you read "these FDCs" above as "these 2793's", because
the 2793 and other FDC's like TC8566 are *really* different.
Differences between the 1793 and 2793 are probably not that big, but
I wouldn't swap diskROMs between these.
> And do you know what's the differences between WD1772 and WD1793?
Forget it..!!
TMS 2793 = "obsolete"
TMS 1793 = older than that = pre-historic
WD 1772 = before that = stone age
> But one of the difficulties is to understand how the all kinds
> of MSX hardware work, because the variability is really big (many kinds of
> FDC, memory expansions, FMPAC, Music Module, GFX9000, IDE, MegaSCSI,
> Novaxis, Gouda, MoonSound, etc etc etc...). Actually I'm trying to make
> small softwares only to understand how these things work. But it's hard to
> find good documentation. Then, I started debugging the hardware that I
> already have. But debugging is too slow and too tiring. So, we had
> achieved almost nothing. :-(
Eehh, that's the whole reason why you have:
-MSX BIOS routines
-disk function calls
-Memman
-DOS2 mapper routines
-replayer source codes coming with music programs
-etc. etc.
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/)
****
