In early days, almost all home computers ROMS have bugs in their code.
I've heard about of speccy ROM bugged (basic)
The QL was a true gem (there is a list of a great number of bugs in QL's ROM ) about it with some spectacular bugs.
(like a print -2-2 basic command that gives 0 as result!)

I've never heard about msx BIOS or BASIC ROM BUGS, but i'm sure there should be more than one.
Considering that the BASIC is from M$ ....

Someone knows any info about this?
Having a list of ROM bugs is (for me) cool!

I don't remember the thread; but IIRC someone found a bug related to the play command...

@jltursan: small things, i guess, i'm looking for something more exotic.

If I recall correctly MSX2 mouse routines on BIOS doesnt work very well... but appears to be fixed on MSX2+ or tR's BIOS - at least I had to do an ugly hack (provided by Adriano, thanks!) to have mouse working on Carmen Sandiego.

IIRC, JLtursan reported some weird behaviour regarding PRINT USING in Turbo-R BASIC v.4.0. But maybe it is just a matter of international configurations.

Regarding hardware bugs, I love the one that infested the Gameboy development: given certain circumstances (out of retrace IIRC), any 16-bit register operation would corrupt the sprite RAM. Imagine it: you just try one innocent INC HL and then all the sprite data is threatened. Try to debug that

For me, it is a hardware level bug the fact that the background coord system does not match the sprites coord system. Weird.

Not really bugs, but strange anyway:

1) you can place commas in the call commands; the interpreter doesn't complain. I.e.:

poke &hf346,1
call s,y,ste,m

2) line nr. 0 acts a bit weird in BASIC

0 rem Every time you press enter on this line, a space will be prepended

list
0  rem Every time you press enter on this line, a space will be prepended

list
0   rem Every time you press enter on this line, a space will be prepended

(etc.)

Bugs that I know:

1) In MSX tR H.BGFD and H.ENFD hooks are not called in DOS2 mode.

2) the Multicolour Mode version of the TDOWNC standard
routine on MSX1 has a bug

The routine is identical to the Graphics Mode version except
that the bottom boundary address is 0500H instead of 1700H.
There is a bug in this routine which will cause it to behave
unpredictably if MLTCGP, the Character Pattern Table base
address, is changed from its normal value of zero. There should
be an EX DE,HL instruction inserted at address 17CEH.

If the Character Pattern Table base is increased the routine
will think it has reached the bottom of the screen when it
actually has not. This routine is used by the "PAINT" statement
so the following demonstrates the fault:

        10 BASE(17)=&H1000
        20 SCREEN 3
        30 PSET(200,0)
        40 DRAW"D180L100U180R100"
        50 PAINT(150,90)
        60 GOTO 60

3) Multicolour Mode version of the TUPC standard
routine has same kind of bug. This time there should be an EX
DE,HL instruction at address 17EBH.


4) (7507H) and PRSCNT is incremented to show the number of strings
completed. If control returns abnormally then anything left on
the Z80 stack is copied into the current voice buffer (6253H).
Because of the recursive nature of the macro language parser
where the "X" command is involved there may be a number of four
byte string descriptors, marking the point where the original
string was suspended, left on the Z80 stack at termination.
Saving the stack contents in the voice buffer means they can be
restored when the loop gets around to that voice again. Note
that as there are only sixteen bytes available in each voice
buffer an "Illegal function call" error is generated (475AH) if
too much data remains on the stack. This will occur when a
queue fills up and multiple, nested "X" commands exist, for
example:

        10 A$="XB$;"
        20 B$="XC$;"
        30 C$="XD$;"
        40 D$=STRING$(150,"A")
        50 PLAY A$

There seems to be a slight bug in this section as only fifteen
bytes of stack data are allowed, instead of sixteen, before an
error is generated.

When control returns from the macro language parser register
A is incremented to select the next voice for processing. When
all three voices have been processed INTFLG is checked and, if
CTRL-STOP has been detected by the interrupt handler, control
transfers to the GICINI standard routine to halt all music and
terminate. Assuming bit 7 of PRSCNT shows this to be the first
pass through the mainloop, that is no voice has been
temporarily suspended because of a full queue, PLYCNT is
incremented and interrupt dequeueing started via the STRTMS
standard routine. PRSCNT is then checked to determine the
number of strings completed by the macro language parser. If
all three operand strings have been completed the handler
terminates, otherwise control transfers back to the start of
the play mainloop to try each voice again.

5) Address... 7B99H (MSX1)

This routine is used by the "BASE" statement handler to
update the VDP base addresses. The current screen mode, in
register A, is examined and control transfers to the SETTXT,
SETT32, SETGRP or SETMLT standard routine as appropriate. Note
that this is not a full VDP initialization and that the four
current table addresses (NAMBAS, CGPBAS, PATBAS and ATRBAS)
which are the ones actually used by the screen routines, are
not updated. This can be demonstrated with the following, where
the Interpreter carries on outputting to the old VRAM Name
Table:


10 SCREEN 0
20 BASE(0)=&H400
30 PRINT"something"
40 FOR N=1 TO 2000:NEXT
50 BASE(0)=0


Note also that this routine contains a bug. While SETTXT is
correctly used for 40x24 Text Mode, SETGRP is used for 32x24
Text Mode and SETMLT for Graphics Mode and Multicolour Mode.
Any "BASE" statement should therefore be immediately followed
by a "SCREEN" statement to perform a full initialization.

... just remembered one more... IIRC there is a bug with custom devices when large amount of data is transferred (>16KB?)

I mean something like...

BLOAD "USB:large_over_16KB_file.bin",R

... might cause a problem.

great list i see....

I also remembered a string garbage collection bug, that cause a lot of waste time in garbage collection when there is a little string space available....