MSX complaints

Page 1/6
| 2 | 3 | 4 | 5 | 6

By NYYRIKKI

Enlighted (5399)

NYYRIKKI's picture

01-05-2016, 03:18

Ok, I know that we all love MSX, but was it really best that they could do? Was it a flawless design? I think we can all agree that "No" is correct answer although MSX is pretty good standard.

I decided to open this topic so that we can document here together the clear design faults and bugs that we know to exist. I hope that you don't make this general wish list in ie. "I hope they would have added possibility to override video output with cartridge" style, but try to limit this close to existing design and changes that would have clearly made the design better to all of us without big extra HW costs. I know the exact rules are not easy to write, so please use your own consideration and try to explain your point of views.

To get this started I wrote few example points to both categories and I bet I'll continue pretty soon:

Known bugs:
-----------

- Paint algorithm does not always work correctly on MSX1.

- Double meaning of #FCC1: It represents if Slot 0 is expanded and where the BIOS is. (This was tried to fix in MSX2+ standard but obviously it was way too late.)

- They forgot to include calls to HBGFD and HENFD hooks when implementing DOS2 ROM to MSX tR.

Design flaws:
-------------

- Slot selecting: They implemented main slots in a reasonable way, but for some unknown reason they made Subslot selecting with memory mapped I/O. This is still today the biggest single issue that causes software incompatibility and makes changing slots a real pain.

- PSG register 14: It seems they added joystick port pin 8 write support later, but did not fix the order of bits making it unnecessarily hard to write general I/O routines that support both joystick ports with same routine.

- BASIC PRINT USING statement... Who thought that it is good idea to make the BASIC incompatible between different region versions?

- Disk BASIC. This is a real mess both internally and visibly. The commands don't use same logic than rest of BASIC (See ie. DSKO$) and legacy support of earlier MS-BASIC versions makes using of disk in own programs both ugly mess and very slow. Internally it seems that they did not quite remember to add everything needed when making BASIC, so Disk BASIC uses tricks like adding values to stack pointer and then jumping to seemingly random addresses inside BASIC ROM.

- Lack of read back support in devices like VDP, OPLL and memory mapper. Implementing read back would have made things really much easier.

Login or register to post comments

By ARTRAG

Enlighted (6281)

ARTRAG's picture

01-05-2016, 10:11

Does it count if I mention the vdp flaws?
On msx 2, sprites would have been much more useful if they had color patterns to be recalled by an index instead of a table of 512 bytes to update each time a shape changes or a sprite passes to a different plane

By gdx

Prophet (3088)

gdx's picture

01-05-2016, 10:18

NYYRIKKI, I agree with you and I add these design flaws:

  • No system variable to indicate RAM in slots except a few variables under MSX-DOS.
  • Flags for Keyboard type, time format, MSX version, Basic version and VDP ports in Main-ROM instead of in system variables (to allow MSX2 upgrade, replace the keyboard, etc).
  • Frequency 50/60Hz not ajustable on MSX1.
  • Hardware scrolling missing on MSX2. (This is a home computer!)
  • Z80 frequency always the same on all MSX generations except the Turbo R. (Too late! )
  • Selected Memory Mapper pages number not readable. (only the pages of internal mapper is readable.)
  • Reset button available only as option.
  • The difficulty and the slowness to call a routine into the main ROM or the Sub-ROM under MSX-DOS.

By PingPong

Prophet (3460)

PingPong's picture

01-05-2016, 11:19

For me the worst flaw was the choice of TMS vdp. back in 1977 was an interesting chip but 5 years later was obsolete.
key flaw points were:
- lack of hw assisted smooth scrolling
- lack of a true multicolor mode (screen 3 is useless for games)
- sprite support would be to limited
- stupid "magic" y=208 coordinate. useless and root of problems when enhancing y res or implement R24 in msx2

@ARTRAG. i agree with you about msx2 sprites. but, yet another time, due to TMS roots. Yamaha proved to be able to do things well when there is no constraint on TMS compatibility.

with the deletion of screen 1 and a more enhanced in resolution screen 3 mode + scroll support, msx would have been a great gaming machine. later generations would be great too.

By Bit Addict

Resident (34)

Bit Addict's picture

01-05-2016, 11:20

The z80 bus machine design.

No memory mapped I/O. Performing I/O is no different than putting a value at a memory location. It comes with pros and cons. Introducing video ram on a separate bus introduce a performance penalty in the hardware design (slow IO on the external bus).

By spacemoai1973

Expert (96)

spacemoai1973's picture

01-05-2016, 11:43

Tms9918 was not choice. V9938 was simply not ready on time.
The same happened again with v9990 and turbor

By spacemoai1973

Expert (96)

spacemoai1973's picture

01-05-2016, 11:46

Memory mapped I/O is described in the MSX standard as the preferred method. That almost no manufacturer except for Yamaha listened is not the fault of MSX.

By andrear1979

Expert (96)

andrear1979's picture

01-05-2016, 13:39

Hi guys,

I remember several talks about the risk of blowing up some MSX models if one writes to the PSG
without masking most significant bits of PSG register 7.

For the record, I self-shot several times this way on my machine :evil: (Philips VG8010) but luckily it survived happily...

By gdx

Prophet (3088)

gdx's picture

01-05-2016, 13:49

PingPong wrote:

For me the worst flaw was the choice of TMS vdp. back in 1977 was an interesting chip but 5 years later was obsolete.

Not really because at that time the TMS is released with only 4KB of VRAM because the Ram was very expensive.
TMS had no bitmap mode but it allows to make good games with 16 colors and very fast graphics. At that time, the VDP with bitmap graphics were relatively slow, displayed few colors and a low resolution.

By NYYRIKKI

Enlighted (5399)

NYYRIKKI's picture

01-05-2016, 23:09

I continue a bit...

Known MSX1 bugs:
- MSX1 does not always set correctly VARTAB variable
- MSX1 does not always set correctly MEMSIZ and STKTOP in CLEAR-command.
- Devices that have zero lenght device name are not handled correctly (e.g. ":GAME" as filename.)
- call init,statement and device routines in page 2 or 3 don't set stack correctly

Early disk ROM versions related bugs:
- Fails to read secondary FAT if primary FAT is broken
- FAT buffer cache does not work and it may cause unnessessary rewrites
- Returns 1 byte too big record size for CON-device.
- BDOS 0A (buffered console input) has a bug in handling when buffer is full.

MSX2 bugs:
- When reading data from clock chip MSX2 swaps printermode & cassette speed parameters.

Design flaws:
- MSX2 built in RAM disk is so slow that it seems like a joke!

By Manuel

Ascended (15829)

Manuel's picture

01-05-2016, 23:09

Flaw: on a 64kB MSX1 you can only use at most 28815 bytes for your basic program... that was quite uncompetitive with any competitor at the time.

Page 1/6
| 2 | 3 | 4 | 5 | 6