It's a very easy task to find out how many pages your memory mapper has, even in BASIC.

Just switch RAM pages with OUT &HFE,<N>
and POKE somewhere the number of the page.

If after switching to page 8 and peeking you will get 0, on page 9 - 1, etc. - you have only 128K. I hope you got the principle.

Quote:

My personal knowledge in the fields of RAM mapping is slightly above zero But doesn't the native paging mechanism operate with 16K pages, as opposed to 8K pages in Konami ROMs?

You are right 100%.

If I was writing program like ExecROM, I would use the following algorithm:

1) analyze the code of ROM and find out which pairs of 8K pages can be formed during the game at addresses 4000-7FFF and 8000-BFFF.
2) create all the possible pairs and place them in 16K pages of memory mapper
3) on demand, switch on the required pair using memory mapper page in the desired place

Of course, even 128K ROM can theoretically have 16*16=256 possible pairs, but usually you need much less, and usually even 256K RAM (16 pages) is enough to run a 128K ROM.


In fact, many ROM cracks work this way. Some of them use VRAM as well, but this trick is not universal - it is not as fast as working with RAM and requires thorough study of code in ROM and also implies some additional assumptions.

Seems like most (if not all) YIS-503/IIIR owners are in this topic, so I'll post it here

I've tried to arrange what I've learnt about MSX Network, and put it on a page here:

milliways.chance.ru/~tnt23/msx

together with MSX-Link schematics and MSX-Net protocol information I've reverse engineered so far. The work is still in progress, but the most important points are already there.

I replaced network module with SFG-05, I get more kick out of it

Quote:

I replaced network module with SFG-05, I get more kick out of it

Mine came bundled with no options to replace it with around, so I've been somewhat limited on what to have fun with

What is SFG-05 good for?

tnt23, according to your findings the standard sending protocol is very inefficient - it uses 2 bytes to send just 1 byte. This explains why there were many various utilities that used their own protocol to send data.

The way they worked are as the following:
1) using std protocol send small binary receiving program to the student and execute it there
2) now talk to the receiving program using your own protocol - send what you want using whole bytes, send request to switch pages, execute any subroutine you want, etc.

If you want to do something similar, you can study the code of one of the mentioned sending programs.

Well, I myself actually made a network driver for TMT_net, which is a sort of home made network device, made by Hans Tillema (relatively unknown to the MSX-scene, though). I could publish those sources here, as I don't really have faith in him releasing the network device shortly.
Here you can see slash-moi with a friend of mine playing a pre-pre-pre-demo-trial-version of my racing game, especially made for this network device. Heck, let's try to get that bitch working on ObsoNET

About the network protocol - as the card is very low-level, *everything* has to be done by IN-ing and OUT-ing bytes to the network adapter, there's no standard protocol (strong point: everyone can define his (~her) own, otoh, weak point: much work for just getting it all started). The network driver utilises two modes:

• Log in mode: in this mode, every data byte is sent in 3 bytes, with strong checksums for lossless data transfer. The interface is able to join in networks up to 60 computers, which is quite enough for LAN-ing, but you should keep track of those who you communicate with. In this mode, the network driver (and its data tables) are being set-up to be used in the:
• Play mode: in this mode, every data byte is sent in 2 bytes, with a less strict checksum. This part of the driver has been setup so that it will actually ignore corrupt or otherwise lost data. Practically, this never occurs (unless you're really stressing the device).

Please let me know whether you'd like to see those sources. Either I could make them available for download in our downloads database, or send them to the e-mail address of everyone who's interested. Just let me know

cax - I've disassembled a couple of them senders (someone posted his sources through the RU.MSX Fido forum), and they do work as you describe.

However - I like the way the MSX Net was built, so it doesn't violate MIDI standards. You could even connect it (mind the baud rate) with your synthesizer or drum machine, and it still would work. All network packets just look like MIDI SysEx messages

Quote:

Well, I myself actually made a network driver for TMT_net, which is a sort of home made network device, made by Hans Tillema (relatively unknown to the MSX-scene, though).

Can I take a look at the schematics? You know, I just love all those DIY thingies

Quote:

I like the way the MSX Net was built, so it doesn't violate MIDI standards.

tnt23,

I agree, it's cool that the networking protocol is built around MIDI, but if we will be able to understand the way MSX ports work with the YM3802 chip (I hope it's not that hard having the manual of the chip and knowing you disassembled some senders), then we will have enough info to build emulation around MSX-Link and send faster using the mentioned senders. If you remember, there were cool programs that ran MSX-DOS on a networked diskless MSX, accessed drives via the network and did other cool things. Don't you want to use all this cool software ?

Quote:

Quote: I like the way the MSX Net was built, so it doesn't violate MIDI standards. tnt23, I agree, it's cool that the networking protocol is built around MIDI, but if we will be able to understand the way MSX ports work with the YM3802 chip (I hope it's not that hard having the manual of the chip and knowing you disassembled some senders), then we will have enough info to build emulation around MSX-Link and send faster using the mentioned senders. If you remember, there were cool programs that ran MSX-DOS on a networked diskless MSX, accessed drives via the network and did other cool things. Don't you want to use all this cool software ?

I don't think transfer speed is an issue, at least for me

In fact, network access is already present in that CP/M portion of our Network modules. It just uses some specific command packets I will have to further document on my page, together with higher level protocol logic. It would be a real challenge to come up with, say, remote network drive emulation by means of some Windows driver or Linux daemon. This, I believe, would give one more flexibility in remote program loading under CP/M - if only .COM files run equally smooth under MSX CP/M and MSX-DOS.

tnt23,

I talked about emulated teacher computer sharing his drives with student machines, and such a software exists from the time I was a schoolboy, so I really don't understand why do you see a real challenge in just using a ready software.
All we need to revive all those cool network utilities is understanding of how to send and receive a single byte on the low level, but if you prefer to study a higher level protocols - that's your choice and I wish you good luck.

Quote:

tnt23, I talked about emulated teacher computer sharing his drives with student machines, and such a software exists from the time I was a schoolboy, so I really don't understand why do you see a real challenge in just using a ready software. All we need to revive all those cool network utilities is understanding of how to send and receive a single byte on the low level, but if you prefer to study a higher level protocols - that's your choice and I wish you good luck.

Sure I share your point of view, where a decent MSX-Net emulation would bring one a familiar classroom networking environment. Now that the YM3802 is no longer an enigma, this shouldn't be very hard. (If you're interested in having NETROM [disassembled] sources, let me know)

Well, maybe I'm not quite interested in having 'Teacher' machine simulation, but rather prefer fiddling with things at the PC side. That's because I feel I don't really like complicating things too much (one would have those .DSK images fed into MSX emulator, then send programs to the real machine), it seems to me more attractive to just have files on PC's drive accessed directly as if it were on a CP/M networked drive, which YIS-503 seems to be able to talk to right out of the box. It's like that seamless integration I got once when hooking my old Mac to my Linux box without running any Mac emulators on the latter.

Again, as I probably mentioned before, my primary goal had been to work out a way of loading MSX games onto my diskless MSX

Quote:

Can I take a look at the schematics? You know, I just love all those DIY thingies

I don't know whether or not Hans would like his schematics be published. I could ask him for you, though.

Quote:

If you're interested in having NETROM [disassembled] sources, let me know

tnt23,

sure, this is very interesting, please share the sources.

BTW, I have a cable that connects PC soundcard gameport to the MIDI IN and MIDI OUT of my synthesizer. If you are saying MSX NET can work using pure MIDI SysEx messages, is it possible to make PC and MSX exchange data using this cable ?

And if yes, does it mean we can convert, for example, binary file we want to send into .mid or .syx format and just play it over the cable ?