MSX2 bugs:
- PUTSPRITE instruction when the colors logical operator is used.
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.
In fact, the problem is the secondary slot selection mentioned by NYYRIKKI. If we allocate more memory for the Basic then the excution will become much slower because it would switch the slots RAM/ROM to each instructions. Also without Disk-Rom there is no variable to know the slot for RAM. In short, the Basic interpreter can't select or know quickly the Main-RAM/Main-ROM position.
How did they handle this for other home computers?
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.
I don't agree with the "uncompetitive with any competitor" ... We had only 28815 bytes, but that was a trade off due to the fact that we had one of the best BASIC on the market at the time. If we had had a poorer or simpler BASIC, say with a 16Kb ROM only, then we would have had more RAM.
I remember making technical and comparison in 1984, using magazines and tests. The MSX had a very complete BASIC. You have to remember that the real competitors were : Commodore 64 (who had almost no BASIC at all), ZX Spectrum (good BASIC but less RAM).
The problem was the timing of the arrival on the market in Europe. The MSX was a good machine versus the Commodore 64 or the ZX Spectrum, but both machines were already on the market in 1983. The MSX was launched in mid 1983 in Japan, but arrived only in Europe in mid 1984.
By then, it was already too late for this kind of machine. The next generation (ST and Amiga) would be introduced one year later, and wipe everything.
Contrary to their competition at the time, the japanese did not aim for a new, revolutionary machine, but rather tried to standardize a proven concept, and to mass produce it. That approach IS the flaw to the MSX design.
Great thread, NYYRIKKI!
I will point some issues that bother me; some of them was already pointed by some of you:
- Slot selecting should be uniform, either two bytes at memory or two bytes at some port address. (preferably the latter to avoid all those subslot issues we all know)
- BASIC syntax shouldn't vary based on localization (like the absurd PRINT USING statement issue)
- BASIC Support for Memory Mapper (a computer with 128k of RAM reporting only a few more than 23k bytes free? come on!)
- Actually, a Memory Mapper for all MSX models would be terrific!
- MSX2+ specs should be released in 1984 as MSX2; Both ASCII and Yamaha had terrible timming with release dates.
- VDP Hardware Sprites should have same specifications of the screen mode and its shape choosed from any position of Pattern Generator Table (like we have on V9990) or VRAM pointer. (Because this is a home computer with strong gaming orientation)
- VDP should had Hardware assisted scrolling capabilities on both directions from day 0 or at least from MSX2 specs. (Because this is a home computer with strong gaming orientation)
- VDP hardware sprite flipping, rotating and priority attributes - even if we hadn't multiple layers, we could choose if that particular sprite was in front or behind the image plane (Because this is a home computer with strong gaming orientation)
- VDP line/column interrupts for split screen - or hardware assisted split screen support (Because this is a home computer with strong gaming orientation)
- I would loved two or three image planes, but I know this is daydreaming on 1983 technology for a 8-bit home computer (again, because this is a home computer with strong gaming orientation)
- MSX BUS should (at some point on history) allow DMA transfers to avoid PIO transfers (Disk Drive interfaces for instance) and help on RAM/VRAM transfers
- Better Interrupt handling for other than VDP events (if you get another interrupt during ISR you're doomed!)
- Memory Mapped I/O should be enforced on external devices (to avoid port collision, solve port shortage issues and allow multiple equal devices)
- YM3527 should be offered as Y8950 alternative to a cheaper MSX-AUDIO (and/or)
- YM3812 should be offered as YM2413 enhancement to MSX-MUSIC
About @Metalion argument: MSX indeed came almost too late for a 8-bit system, but if it had at least MSX2+ specifications in at least 1984, it could have done better on a market that just discovered AMIGAs, ATARI STs, and 16-bit PCs.
Can't think on anything more for now. Ofcourse there are some things that I would want, but they could stay as optional features like they already are (Digitizing and superimposition features, Serial/MODEM communication ports...)
Everything else on the standard is something to be praised: standardization, componentization, strong and integrated BASIC language, CP/M compatibility, software houses support... even the hacking possibilities! Most competitor systems have very limited possibilities here.
Then, just some comments on what I don't agree:
- Lack of readback for devices: This is inherent to each device (VDP, OPLL, etc.) so, why they should spend with more chips and circuitry complexiness just to be able to read back what you just wrote? On every other system you would simply deal with it, but we MSX'ers keep whining about readback...
- "No memory mapped I/O": I/O's are both Memory and port mapped on MSX. There's no plausible reason memory based I/O should be prohibited... On the contrary: With external devices being exclusively memory mapped we could prevent port conflicts and thus making possible to run multiple unmodified hardware in a useful way (we could have multiple MSX-AUDIO or MSX-MUSIC carts out of the box) due to the slot selection subsystem. Plug-and-play specs before it was ever invented!
Nothing specially, I suposse that some decisions were took taking costs in consideration. MSX1 is a good machine considering that the main idea was to make a standar, and its aproach is good with a BIOS layer. However in MSX2 there are some big issues:
- Why Z80@3,5Mhz?
- Why not flipped hardware sprites?
- Why not multicolor sprites?
I think these are the main lacks.
I stick with the VDP complaints adding:
* Interrupt on command completion.
* Much much much much faster command engine
* more sprites
Don't know about interrupt on command completion, but the other things are found on V9990
Don't know about interrupt on command completion, but the other things are found on V9990
Interrupt on command completion is in the V9990 too, but nevertheless it would’ve been trivial to add to the V9938 (just CE OR /EN3 AND /IRQ), so it’s a shame it isn’t there.
@Grauw didn't understand what you meant with "(just CE OR /EN3 AND /IRQ)"
What I meant is that the logic required is just two or three simple logic operations. CE is the command execute bit, already there, they would just have had to tie it up with the IRQ (interrupt request) line and a new enable bit (“EN3”). So it would’ve been a very simple and cheap feature to add, almost a no-brainer.