MSX Assembly Page

Page 8/10
1 | 2 | 3 | 4 | 5 | 6 | 7 | | 9 | 10

By Grauw

Ascended (10174)

Grauw's picture

21-08-2015, 10:14

The problem with using FCC1H to contain a BIOS slot other than 0 or 0-0 is, it is specified to contain either 00H or 80H, nowhere does it say you have to mask out bits 0-6. So, when building a slot ID, software may simply OR the value, and break.

Also, ignoring the expanded slot bit (like the NEOS does by always setting it to 1) can cause difficult to find bugs. VGMPlay had such a bug, where mysteriously a byte of RAM data got corrupted in the first page of secondary mappers. It was because I ignored the expanded slot bit.

So, NEOS’s behaviour is not proper at all, possibly dangerous. They only do it because it is the only way it could work, but it’s a hack, nothing more.

By gdx

Enlighted (4830)

gdx's picture

21-08-2015, 11:00

Japanese documentations are clear. 0FCC1h can only be 0 or 80h (MSX1 included).
By cons, they are not clear about 0FFF7h. For me, the most logical explanation is the indication of a auxiliary Main-ROM (or internal Main-ROM by default) but it did not seem to be the case.

sd_snatcher wrote:

The spec may have been planned to allow that, but the BIOS of the majority of the MSX1 models do not support the expansion of the slot-0.

This is probably to save hardware.

By Grauw

Ascended (10174)

Grauw's picture

21-08-2015, 11:11

sd_snatcher wrote:

The I/O ports overview page lists #28~#2F as the "second setting Philips NMS1210 RS232 interface", and #30~#38 for the "Philips NMS1251 modem". But the NMS-1210 user manual states that there are two possible combinations for the NMS-1210/NMS-1211/NMS-1212 interfaces.

Thanks, I’ve updated it!

Also thanks for providing a source, appreciated :). Sourced information improves the reliability, and I always enter these in the commit comments. I also put the user manual on resources page.

I noted the manual also says it’s compatible with NMS 1255. I’ve added a listing for that as well.

By hit9918

Prophet (2911)

hit9918's picture

21-08-2015, 18:16

how about taking the keyboard matrix from the machine, from slot 0, not from (fcc1).

keyboard matrixes topic I haven't cracked yet.
Is there a pointer that tells where they are?
I saw matrixes in docs, but no pointer.

By hit9918

Prophet (2911)

hit9918's picture

21-08-2015, 20:37

Quote:

where mysteriously a byte of RAM data got corrupted in the first page of secondary mappers. It was because I ignored the expanded slot bit.

So, NEOS’s behaviour is not proper at all, possibly dangerous

@grauw, it has nothing to do with neos, also would have crashed on a machine with expanded slot 0.

By sd_snatcher

Prophet (3486)

sd_snatcher's picture

21-08-2015, 23:11

hit9918

That seems like a good idea, and indeed would be if possible, but unfortunately it isn't feasible. The problem is that the decoding routines are different for each keyboard layout. i.e.:

- The Japanese layout has the Kana key, that behaves differently from the Western equivalent "CODE".
- The Brazilian layout supports multiple dead keys, like modern PC keyboard layouts
- The Korean routines are different from everything else

Not to mention the Arabic and Russian. I haven't checked yet, but I wouldn't be surprised if they also had different decoder routines too. And that wouldn't also solve the problem of the character set.

But the solution is simple and was provided by l_oliveira too: To have one BIOS file for each region. You just have to flash it with the file that contains the international requirements needed for that machine (keyboard layout, character set, etc).

By sd_snatcher

Prophet (3486)

sd_snatcher's picture

22-08-2015, 02:34

Another contribution:

In this page, its mentioned that "using an interslot call to call the SUBROM is not allowed per the MSX2 standard."

But in the MSX BIOS calls page, there's the following comment for the SUBROM routine: "Use of EXTROM or CALSLT is more convenient". But, AFAIK, CALSLT indeed can't be used to call the SubROM, as mentioned in the first page.

By sd_snatcher

Prophet (3486)

sd_snatcher's picture

25-08-2015, 03:38

Yet another contribution:

The GTPAD BIOS function supports a 2nd light pen port. On Korean machines, it's used for the internal V9938 light pen interface. Credit: zeilemaker54

I updated the Light Pen wiki article to reflect that. But it would also be nice to update MAP:

NEWPAD:
           [20]   Fetch data from 2nd light-pen port (#FF if the pen was touching the screen, thus valid data was read)
           [21]   Read X-position
           [22]   Read Y-position
           [23]   Read light-pen status (#FF if pressed)

Since most of the time GTPAD is used to read all those devices, it would be very useful to have the complete list of GDPAD devices listed there in the MainBIOS article, and a comment that >8 function numbers will be redirected to NEWPAD in the subROM.

Here the complete list, to help:

GTPAD
           [ 0]   Fetch touchpad data from port 1 (#FF if the pen was touching the pad, thus valid data was read)
           [ 1]   Read X-position
           [ 2]   Read Y-position
           [ 3]   Read touchpad status from port 1 (#FF if pressed)

           [ 4]   Fetch touchpad data from port 2 (#FF if the pen was touching the pad, thus valid data was read)
           [ 5]   Read X-position
           [ 6]   Read Y-position
           [ 7]   Read touchpad status from port 2 (#FF if pressed)

(redirected internally to NEWPAD in the subROM)
           [ 8]   Fetch data from 1st light-pen port (#FF if the pen was touching the screen, thus valid data was read)
           [ 9]   Read X-position
           [10]   Read Y-position
           [11]   Read light-pen status on 1st port (#FF if pressed)

           [12]   Fetch mouse/trackball data from port 1
           [13]   Read X-offset
           [14]   Read Y-offset
           [15]   No function (always #00)

           [16]   Fetch mouse/trackball data from port 2
           [17]   Read X-offset
           [18]   Read Y-offset
           [19]   No function (always #00)

           [20]   Fetch data from 2nd light-pen port (#FF if the pen was touching the screen, thus valid data was read)
           [21]   Read X-position
           [22]   Read Y-position
           [23]   Read light-pen status (#FF if pressed)

I replaced "read" with "fetch" in the 1st function of each device because that makes it clear of how the BIOS deals with the devices.

By gdx

Enlighted (4830)

gdx's picture

25-08-2015, 12:40

sd_snatcher wrote:

The GTPAD BIOS function supports a 2nd light pen port. On Korean machines, it's used for the internal V9938 light pen interface. Credit: zeilemaker54

What MSX2? I think not all.

By mars2000you

Enlighted (6019)

mars2000you's picture

25-08-2015, 18:06

gdx wrote:

What MSX2? I think not all.

See last changes in Wiki page : http://www.msx.org/wiki/Light_pen

Quote:

- Daewoo CPC-300
- Daewoo CPC-400S

The Daewoo CPC-300E has the same motherboard as the CPC-300, but lacks both joystick port connectors and the light pen connector. They can be installed afterwards to enable those features.

It's said that the Sanyo MPC-27 also feature this interface, but this is yet to be confirmed.

Strangely, the Daewoo CPC-400 is not mentioned (I think the difference with 400S is the absence of superimposing and digitizing features) ...

Page 8/10
1 | 2 | 3 | 4 | 5 | 6 | 7 | | 9 | 10