On Wed, 17 Mar 1999, Alwin Henseler wrote:
> Marco Antonio Simon dal Poz <[EMAIL PROTECTED]> wrote:
>
> > 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)
That's ok, nobody can make money with MSX hardware nowadays. But I think
that people who handles with hardware should be able to work together to
create a new MSX more powerful and still keeping the backward
compatibility.
> > 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.
Then I say: both are logical! After Megaram had been created, some people
created some software specific to take profit of 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.
>
> That would best describe it.
Yes, and there are some softwares that use it exactly in this way (and not
just for Megarom simulation).
> > 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.
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.
> > 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.
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.
> 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.
Is Crazy Train really made by Sony? AFAIK, it's made by Konami.
> Okay, so what?
> The point is, that the MSX doesn't recognise a cartridge in page 0,
> if it starts with "AB". (!?!!??)
MSX doesn't recognise??? Then you found a bug in my SDC. Well, it's not
really a bug, but that hinders that I write it to an EPROM and create a
cartridge with it.
> I thought for a while, that maybe the crack authors re-arranged all
> those jump- and call-addresses. Naaahh, too much work.
Really, too much work (and unuseful).
> 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?
> 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.
You traced it? Wow, this really should give too much work! Is it harder
than tracing diskrom?
> 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!
> 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.
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?
> 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:
Ah! That I knew. BIOS uses RDSLT, WRSLT and CALSLT for all routines that
handles with slot scanning.
> 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.
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).
> 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?
> > 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.
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?
> > 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.
More versatile? I don't think so. This mirror-effect turns impossible to
select a continous region of 64kb of Megaram, which is a limiting factor
of using Megaram.
> 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).
Yep, that's the good part of the Megaram.
> > (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.
Exactly. It's good to allow the game to be restarted after a reset.
> 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.
> 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?
> 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?
> 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".
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.
> 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.
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.
Megaram-Disk have a special effect: after a software reset, the current
state is kept, but after a hardware reset, the "show EPROM mode" is
selected.
> 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.
Yes, and I think that the RAMdisk-software shouldn't spend more than 16kb.
If it has only 8kb, then the fixed block is reasonable.
> 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.
[... method described to find Megaram slot ...]
> > 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%
Then I would like to know why in my MSX2, in an empty slot, I get
equiprobably FFh and 7Fh.
[... superbly routine to find any kind of Mapper ...]
> > 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?
There's no big deal, but nobody had made it (neither me)! I think that a
fixed size table isn't good, because it spends too much memory. I would
prefer a table in the following format: slot number (in 1000xxyy format)
and size (in number of 8kb blocks), next slot number and size, finished by
a FFh.
> > 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 ;-))
So do I, but since you have a better routine than I, it's easier to you to
make this routine. And this would be very useful for a new operating
system (that necessarily would use more than 64kb of RAM).
[... 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!
> 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.
Given that Megaram-Disk should work without any disk-drive, where would we
load the ramdisk-software from?
> >> (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.
I think that the FDC is the same, but I personally can't check that,
because I don't want to tear the original stamp from the disk interface.
But I know a person that has an already opened disk interface. I will ask
him to bring the his disk interface to me and I will check its FDC. And I
know that Turbo-R FDC is very different, because I am still tracing its
diskrom. And I couldn't create my own sector reader, I don't know why!
> > 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
Do you know a FDC that supports 1.2Mb and 1.44Mb drives and is still being
produced, and have good documentation?
> > 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.
The main idea is to create an entire new BIOS, much more efficient and
fast, which allows the creation of an entire new operating system! That
would be great, but the lack of technical informations if hindering this
kind of project. :-(
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/)
****
