On Mon, 15 Mar 1999, Alwin Henseler wrote:
> Hi Marco!
>
> (this is not via the MSX mailing-list)
But it shouldn't be any problem if it was via the list. BTW, I think that
these informations can be very interesting for other people, like Alex
Wulms and other hardware people.
> > On Thu, 4 Mar 1999, Alwin Henseler wrote:
> >
> > > Okay, just so that anyone can build this, or emulate it (oops...),
> > > can you please fill in the details?
>
> 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.
> > 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.
BTW, using BrMSX you can "get a feeling" about my SDC (Super Disk Copy).
SDC can be downloaded from http://www.lsi.usp.br/~ricardo/msx.htm
> Okay, you can use it as a RAM expansion. But doesn't the MSX have a
> thing called a memory mapper for that purpose?
Yes, but I think I already said that Megaram was born earlier than Memory
Mapper. When Memory Mapper was created, I didn't want to buy because I
already had Megaram. So, I need to make conversions of some Mapper
programs to run with Megaram.
> 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. 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. Of course I could use BrMSX to load MEGAASM.ROM
instead use my adapted version of "Mega Assembler" to run in Megaram, but
it's easier to use what is already ready!
> BTW. my question was just out of curiosity. I've heard this MegaRAM
> mentioned earlier, but what was it? How does it work? At least we all
> know what it is now, when we mention it ;-))
That's the idea! I don't understand why some people complain about
technical discussions on the mailing list.
> > > -EXACTLY what memory ranges do these blocks occupy?
> >
> > There are blocks in the area 4000h-5FFFh, 6000h-7FFFh, 8000h-9FFFh and
> > A000-BFFFh.
>
> 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).
> So, you can also READ (not block-switch) the ROM contents of a Konami
> SCC through page 0 of the cartridgeslot it's in.
> Although I doubt it, a cartridge COULD use this mirror effect for
> some purpose, and maybe work different if not available.
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?
> 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 see a shortcoming here: because
> a) the reset state of a normal MegaRAM is not defined in any way, and
Perhaps I had said somethings that aren't 100% true. I'll try to correct
them: the reset state of a normal Megaram is exactly the same before the
reset. This allows a Megarom game loaded into Megaram be executed after a
reset (hardware reset or software reset).
The initial state (when you turn on your MSX) of Megaram is unknown.
> b) you can use the same, full address range the blocks occupy, for
> switching these (instead of a limited address range),
Yes, you can. But the block contents is mirrored from page 0 to 2 (and
vice-versa) and from page 3 to 1 (and vice-versa).
> it is possible that the MegaRAM is mistaken by some programs for
> normal, non-mapped (not memory mapper either) RAM:
If you select some different blocks (for example 0, 1, 2 and 3 for the
page 1 and 2 regions), and put it in "write enable mode", it's possible
that some programs treat it like a normal RAM. And there's no problem
with it!
> There are some programs who search for RAM by reading an address,
> then writing a modified byte back, and reading the address again to
> see if it CHANGED. (If you do it proper, you check if the value read
> back matches the one you just wrote, rather than just looking if it
> changed).
Perfectly.
> Depending on the contents and state of the MegaRAM at that time, a
> MegaRAM might in this way be mistaken for normal RAM. (okay, I
> would call this a bug, in a program that detects RAM this way).
Yes, it might be. And I wouldn't call this a bug, for me it's a feature!
> Second, if write-enable or block-switch state is undefined after a
> reset, it could ofcourse be in write-enable state at the time of
> reset, and behaving as normal RAM then, be detected as such (be it
> at 4000-BFFFh only).
The state is undefined only when you turn on your MSX. After a reset, all
states are kept.
But that's a good question! The computer could think that it's a normal
RAM if the state is "write enable mode" while the slots are being scanned.
I don't know how to answer your question, I guess that the start-up state
should be "block select mode", but I'm not sure.
> >> -How are unused bits in block numbers handled?
> > This is a big story. (...)
> > This mess happened (..)
>
> It's not really such a mess. The same thing happened with memory
> mappers. There was a time that you could have a memory mapper of
> 384K, or 768K built into your computer (at a time when RAM chips were
> precious).
Really? I have never seen Memory Mappers different from power of 2 from
256kb.
> I also used to build mapper expansions once, but never did that,
> because I knew such sizes would give trouble. I only used 256, 512,
> 1024, 2048K etc.
This sounds better, and it's easier to find the size of the Mapper via
software.
> The only trouble is that REALLY dumb mapper size detection mechanisms
> won't work. Is that a problem?
Maybe, but it's a software fault (really bad software).
> Not at all: it makes sure that you have trouble with programs, that
> were written by some eggheads/stupids, that don't how to program in
> the first place. In other words, these troubles will be with programs
> that often give many other troubles as well. And because of that, get
> ignored and replaced by other (better) software anyway.
>
> For mapper size detection, I have seen things like:
>
> OUT (port),xx
> IF IN (port)=yy THEN "big enough" ELSE "not big enough mapper"
I have never seen such a stupidity! This gives many troubles with Turbo-R
and Mappers higher than 256kb.
> Ofcourse this is no way to properly determine the size of a memory
> mapper. So who cares if someone writes a program this way and it
> doesn't work?
Some Mappers can have 8-bit registers, discarding the highest bits. This
yields for this kind of software to detect a 4Mb Mapper when it has much
less.
> If you don't know a good way to determine mapper size, and you need,
> say 256K, it's easy: simply don't even try do determine the mapper
> size, put "256K required" on the box of the software you make, use
> mapper blocks 0 to 15, no higher, and it'll work everywere where
> there's a working 256K or bigger mapper. Right?
Right, but when it crashed in a MSX without Mapper, I think that it would
be better if the software explains to the user exactly what's the matter.
For example, Pumpkin Adventure III has this problem. In my MSX2 with 64kb
of RAM, it says: "Disk error" and in my Turbo-R A1ST it runs perfectly.
> 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%).
> I am 100% sure this way all different MegaRAM sizes are determined
> correctly, no matter how exactly they were built.
SDC uses a similar technique, but it tests twice each block at the same
address, to be sure that there's real memory, not a coincidance of junk.
The other difference is that SDC doesn't test all blocks, just blocks 31,
63, 95, 128, etc...
> Separating MegaRAMs and MegaRAM-disks is just a matter of testing the
> effect of the extra I/O port.
Exaclty, but for all softwares that use Megaram, there's no need to
distinguish normal Megaram from Megaram-Disk. The important is the
quantity of RAM, the EPROM is always discardable.
> If it exists, you can change the MegaRAM-disk from (EP)ROM state into
> RAM state and vice versa (using both I/O ports), and detect that ->
> MegaRAM-disk.
Yes, but usually there's no need for that.
> If it doesn't exist, messing with both I/O ports will not have the
> effect it should have with a MegaRAM-disk -> normal MegaRAM.
Perfectly.
> 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?
> If you really need it, I could write a MegaRAM detection/size/-disk
> detection routine as well, using the same principle.
> Please ask me if you think that would be usefull.
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!)
> > For Megaram-Disk (of all sizes), after a software reset the state is not
> > changed, but after a hardware reset or a power-on, the "show EPROM mode"
> > is selected (because this is the way to the system recognise it as a disk
> > interface)
>
> One question: is this EPROM only at 4000-7FFFh, or also 8000-BFFFh?
> (32K, or 16K mirrored)
This EPROM is only at 4000h-7FFFh. In "show EPROM mode", the page 2 if
full of junk (no data present, open data bus).
> 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.
The big defect of Megaram-Disk is that, after a reset, the ramdisk if
formatted, what means that the FAT and the root directory is erased. I
would like to modify this Megaram-Diskrom to never erase the contents of
the ramdisk, but the EPROM is soldered!
The other fault of Megaram-Disk is that it doesn't work with Turbo-R (and
probably with many others address based interfaces). I really don't know
why this happens, perhaps because the Megaram-Diskrom is bad programmed.
> The FDC used in European MSX machines is either a TMS 1793 or 2793
> (Texas Instruments, maybe Western Digital made it too but I'm not
> sure about that). The TMS 1793 is VERY old, used only in some older
> Philips MSX-2 (VG8230), better forget this one.
> All other European MSX's, and separate disk interfaces (Philips,
> Toshiba, Sony etc.) that I've seen, use the TMS 2793.
> I have datasheets of it, but only on paper. Looking for datasheets in
> electronic format, I also came up empty sofar (Texas Instruments:
> "obsolete", ask .... for it, asking .... for it: no reply)
> It wouldn't surprise me if datasheets of this part, in ELECTRONIC
> form, simply still don't exist today, anywhere, at all.
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.
> The hardware using the TMS 2793 is about the same in all cases: a
> diskROM is present in 4000-7FFFh, the FDC occupies a few addresses (
> 7FFxh) through memory-mapped I/O, and mirrored at BFFxh of the same
> slot (only the FDC, not the ROM; rest of page 2 is empty). This can
> be used for faster data transfer if going to/from 4000-7FFFh.
> With minor differences, the hardware functions about the same. Put a
> diskROM from a separate disk interface inside some machine, or the
> other way round, and it'll work somehow.
Ok, the Turbo-R diskrom has the same features. I was debugging it and
found code that is moved to F0xxh area and controls addresses BFF2h-BFF5h
to transfer data directly to page 0 and page 1.
> Only other FDC's I came across sofar, are the TC8566, built into
> Turbo-R, and other Japanese-built MSX2+ machines. Some people
> seem to have datasheets of it, I have never seen any.
I had talked to Alex Wulms and he had said it has these datasheets, but
that's only in paper. So, I couldn't get it. If you know some cheap way of
sending information from paper to other countries, please contact me.
> And I've seen a WD 1772 floppycontroller once, in a Korean-built
> MSX2 (Daewoo CPC-400). This is a pre-type of that 1793, don't think
> you or I will ever come across that one again (although I also saw it
> inside an Atari ST once ;-))
And do you know what's the differences between WD1772 and WD1793?
> I would suggest putting your energy to a more usefull goal.
> In Europe we have several of such fast copiers that control FDC
> hardware directly, and some that can use all sorts & sizes AND even
> multiple mappers (is not that difficult anyway, I wrote a program
> using multiple mappers years ago), so: we have that.
Ok, that's a good idea. The main idea is to get the knowledge used to make
the disk copier and create an entire new operating system, much more
efficient. 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. :-(
> I almost forgot - the reason why I wrote you:
> If I would put this info about how the MegaRAM works, on my webpages,
> would it be okay to include your name & e-mail, so that people might
> ask you about it?
That would be very good! The data is here:
Marco Antonio Simon Dal Poz
E-mail address: [EMAIL PROTECTED]
Homepage (always under construction): http://www.lsi.usp.br/~mdalpoz
> You seem to know what you're talking about here, and I myself don't
> have a MegaRAM.
Many things that I said were extracted directly from software experiences,
because when I bought my first Megaram, there weren't any kind of
documentation available! I first learned how to make a "block switch" just
analysing the contents of the loader of the Megarom games. Some time
after, I created my own loader, much faster than the original ones.
For example, Metal Gear II (512kb Megarom) uses approximately 2/3 of a
720kb disk. This spends some time to load, and so I made a small routine
that directly accesses the FDC (port based FDC) and loads the entire game
into Megaram in less than half the time! Then the performance had became
good.
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/)
****
