MSXPi Users and Developers Guide
MSXPi Users and Developers Guide
• Raspberry Pi Zero W
This is the recommended Raspberry Pi model, because the form factor is ideal to plug into
the interface, and the low power consumption allows it to be powered by the MSX without
the need for another external power supply.
The fact that it also has wireless networking makes it the ideal Raspberry Pi for MSXPi.
• Raspberry Pi Zero
The second best Raspberry Pi model to plug into MSXPi. This model comes without the wifi
module, but has all other capabilities of the model above. To use networking features of
MSXPi, a wifi dongle need to be connected in the USB port.
These models can also be used with MSXPi, although the connection will be awkward with
the use of wires and external power supply. Not recommended for daily use, although can
be use for development, experimentation and tests. One advantage of this model is that it is
faster, and has audio output that can be used along with pplay command.
MSXPi cannot be used with any Raspberry Pico models, as they are in fact microcontrollers and
do not run Linux as their base operating system, which is required for the MSXPi server program.
MSXPi software is composed of different components running on MSX and on the Raspberry Pi.
The Raspberry Pi run the server component which listen for GPIO events, decode serial bits using
a four pins and transform them into commands and data. In the MSX side, there are different
software components depending on how the user wants to use MSXPi:
• MSX-DOS ROM is stored in the MSXPi EEPROM. This is the MSX-DOS 1 customized with
the MSXPi low level drivers to allow the MSX to boot from disk images stored in Raspberry
Pi SD card. The ROM also contain the MSXPi BIOS with a set of CALL commands that can
be used from BASIC.
• MSX-DOS commands - these are the “P” commands that implement a series of
functionalities in MSX-DOS allowing greater experience with MSXPi, such as setting
system clock and access to internet resources form MSX-DOS 2 or Nextor.
• MSXPIEXT.BIN is the MSXPi BIOS implementaton that can be loaded from BASIC and
behave similar to a MSXPi with an installed ROM. The BIOS is installed in the RAM in the
the 4000h cartridge area, becoming available for BASIC programs.
• Raspberry Pi Zero W
This is the essential component in the interface. It boots into Linux, and starts up the msxpi-
server.py application that implements all MSXPi commands on the server side.
• Micro SD Card
This SD Card is used by the Raspberry Pi to boot into Linux. There is a pre-configured
image in the MSXPi repository containing a recent Raspbian OS and all the required MSXPi
programs and libraries.
• EEPROM AT28C256
This EEPROM contains the MSXPi BIOS and MSX-DOS drivers required to boot into
MSX-DOS 1.03 from a disk image stored in the Pi SD Card. This EEPROM can also be
used for other purposes, such as storing ROM games. This EEPROM should be written from
MSX-DOS using the supplied AT28C256.COM programmer.
• ROM Jumpers
Used to disable the ROM and also select one of the two 16KB ROM banks available.
• CPLD
Contains the firmware to decode I/O ports used by MSXPi, and do all data transfers between
MSX and Raspberry Pi.
• JTAG Connector
USB-Blaster compatible connector used to program the CPLD with new firmware versions
or other custom firmware. CPLD programming cannot be done via MSX, and requires the
Altera software installed in a Windows computer. To program the CPLD, the interface must
be inserted into the MSX and the MSX turned on.
• Activity LED
Flashes whenever the interface is communicating with the Raspberry Pi
There are a few steps to setup MSXPi, and you can choose between using a MSXPi pre-installed
SD Card image (ready to boot MSXPi), or build your own image using a fresh Raspbian Image
downloaded from Raspberry Pi web site - both methods are described below.
• Setup MSX with the client side software (MSX SD Card / disk drive)
After this basic setup, you should be able to use the MSXPi "P" commands from your MSX. To
unleash full MSXPi power, configure the Raspberry Pi Zero W Wi-Fi:
pset WIFISSID Your Wifi Name
pwifi set
preboot
Note: The first reboot may take longer than 3 minutes, because Raspbian will expand the filesystem
in the SD and initialize the Linux system - following reboots will be faster.
In case you need very detailed instructions, please read "Tutorial - Setup Raspberry Pi for MSXPi
the Easy Way - Using the MSXPi Pre-Installed Image.pdf", in
https://github.com/costarc/MSXPi/tree/master/documents (Portuguese version also available).
This is the official Raspberry Pi SD Card image writer - download and install in your desktop PC.
Download the MSXPi setup script - it will download and install everything needed to have MSXPi
up and running:
mkdir /home/pi/msxpi
cd /home/pi/msxpi
wget https://tinyurl.com/MSXPi-Setup
sudo ./MSXPi-Setup
If you need very detailed instructions, please read "Tutorial - Setup Raspberry Pi for MSXPi the
Hard Way - Installing Raspbian from Scratch.pdf", in
https://github.com/costarc/MSXPi/tree/master/documents (Portuguese version also available).
Do not delete files in drive A:, because they are needed for the MSXPi to boot and operate correctly
in this mode.
3 Users Guide
MSXPi can be used as a stand-alone floppy disk drive, booting from a MSX-DOS 1.03 in a disk
image (.dsk) stored in the Raspberry Pi. This works to an extent, although there are several
limitations and bugs. It’s not the recommended way to use the MSXPi, although it is a reasonable
option if there is not another storage device available to boot the MSX with Nextor or MSX-DOS 2.
The best method to use MSXPi is to use it along with the SD Card interface running Nextor or
MSX-DOS2 (such as a Megaflashrom SCC+ SD). In this configuration, the user has the best option
for boot and storage in paralell with all networking features provided by MSXPi.
Either way, the "P" commands are available and can be used in the MSX-DOS 1, 2 and Nextor. The
MSXPi BIOS (CALL commands) can also be used irrespective of how the system was booted, with
options to have the BIOS in an EEPROM (AT28C156) or load it from BASIC by loading the
“msxpiext.bin” extension.
Note that booting from the integrated MSX-DOS 1 require the Raspberry Pi to complete its boot
sequence and start the msxpi-server.py - for this reason, a MSX cold boot (power on) may take a
few minnutes to sucessfully boot into the MSX-DOS.
To bypass the MSX-DOS 1.03 boot and go directly to BASIC, keep ESC pressed during the boot
sequence.
To boot from another interface (for example, with Nextor), insert that interface in a lower slot, and
the MSXPi in the higher slot, and power on the MSX. To skip the MSXPi waiting time during the
boot, keep ESC pressed during the boot sequence.
To update the MSXPi client side ("P" commands in the MSX Disk or SD CARD), simply run the
command:
MSXPIUPD.BAT
The progress is displayed in the screen, and errors will be easily spotted.
Before running the command, make sure that networking is configured and working properly.
To update the MSXPi server components, the following commands can be used from the MSX-
DOS:
pcd /home/pi/msxpi
prun wget https://tinyurl.com/MSXPi-Setup
prun chmod 755 MSXPi-Setup
prun ./MSXPi-Setup
These commands should only be executed after verifying that the network is working properly,
because once MSXPi-Setup is executed there will be no output to the screen.
This update takes up to five minutes, and the MSX prompt will be locked until the Raspberry Pi is
rebooted - at this point, the MSX returns the command prompt to the user.
Verify the MSXPi status and version with the PVER command.
When the BIOS is available, some commands can be used to verify if the MSXPi server if
operation:
CALL MSXPI("pver")
If the command stop responding or return "Connection Error", use ESC if necessary to interrupt the
command, wait 5 seconds and try again. After retrying and it still does not work, the Raspberry Pi
might need to be inspected, which requires loging in and repairing potentials issues. The next
section discuss some potential work arounds and advice to deal with some issues - if none of these
work, or if the user is not technically able to perform them, the next best option is to re-write the sd
card for the MSXPi.
Remember that the Raspberry Pi Zero is powered by the MSX. When the MSX is powered off, so is
the Raspberry Pi. Ideally, the user should always run "pshut" from DOS, or call msxpi("pshut")
from BASIC before powering off the MSX, to reduce the chances of having the SD Card corrupted.
3.4.1 AT28C256
Write a ROM file to the EEPROM. The ROM may be 8KB, 16KB or 32KB.
It's possible to write two ROM files (8KB or 16KB each) and switch between them by
switching the jumper A14/A15 - the ROMs must be previously merged, each ROM stored in
the beggining of 16KB area.
Examples:
at28c256 /i (Display headers of all identified ROMs)
at28c256 /s 2 MSXPIDOS.ROM (write MSXPi ROM to MSXPi connected imsxpiupdn slot
2)
3.4.2 MSXPIUPD
Perform a full upgrade of the MSXPi client and server software - the ROM is downloaded
but not written to the EEPROM, which needs to be done manually using at28c256.com
programmer.
This command download all P commands from github to the MSX drive - existing versions
re overwritten. The server components are also updated, including the two disk images used
by the MSX-DOS 1.03.
In the MSX-DOS 2, the output is nicely formatted as show in next picture. In the MSX-DOS
1, there will be some error messages everytime the “ECHO” command is used in the batch
file, but the files will be updated successfully.
3.4.3 PDATE
Sets the MSX-data and time by readingn these informaton from Raspberry Pi. This
command does not accept any parameter.
3.4.4 PCD
Sets the path for the MSXPi commands pdir and pcopy. Is called without parameters, will
display the current path.
The path may be a Raspberry Pi filesystem path, a http/ftp/smb url, or one of the three
virtual devices below. Any of thesse three devices can be changed via pset command.
◦ m A user local network resources. The default path for m: is ftp://192.168.1.100
◦ r1 A internet location. Default path is the msxarchive.nl roms for MSX1
◦ r2 A internet location.Default path is the msxarchive.nl roms for MSX2
Examples:
pcd
pcd /home/pi
pcd m:
pcd r1:
pcd http://www.msxarchive.nl/pub/msx/
3.4.5 PDIR
Show contents of current path in the MSXPi when no path is passed as parameter.
Show contents of given path when passed as parameter.
Note that the path can be local to the Raspberry Pi and also a remote / network resource.
Examples:
pdir /home/pi
pdir http://www.msxarchive.nl/pub/msx
3.4.6 PCOPY
Copy a file from a Rapsberry Pi path (filesystem or network) to the MSX drive.
The file can be in the Raspberry Pi s card (any folder), in the network (ftp/http/smb) on in
one fo the three virtual devices (m, r1 and r2).
pcopy accepts the parameter "/z" to desompress a file, lookup its original name inside the
compressed archive, and use it to save in the MSX drive.
Examples:
pcopy /home/pi/msxpi/msxpi.ini msxpi.ini
pcopy ftp://192.168.1.100/pver.com
pcopy m:pver.com
pcopy /z r1:frogger.zip (download frogger.zip from msxarchive, unzip, save as frogger.rom)
3.4.7 PPLAY
Play music and audio from RPi SD card (soon also to play multimedia over the network).
PPLAY can play a music file, pause, resume and stop it. The audio can also played in a loop.
Once the music is started, a unique ID is returned to the MSX, which can be used with the
pause/resume/stop commands.
• Options implemented so far:
◦ play (start playing a multimedia file or stream)
◦ loop (play the same audio until a stop is sent to RPi)
◦ pause (pauase the audio)
◦ resume (restart the audio previously pause)
◦ stopn (stop the audio)
◦ getids (list the unique ID of the audio playing)
◦ getlids (list the unique ID of the looping audio)
Examples:
pplay play Aleste.mp3
1465
pplay pause 1465
pplay resume 1465
pplay stop 1465
Note: 1465 aboce is the unique ID of the audio playing. It will be different each time a new audio is
played.
3.4.8 PRUN
Run a command in the Raspberry Pi. Note that commands that require inputs are not
supported.
Pipe is suported, but must be replaced by "::" in the MSXPi.
Examples:
prun ls -l /etc
prun cat /home/pi/msxpi/msxpi.ini
prun ps -ef :: grep msx
prun wget http://www.msxarchive.nl/pub/msx/games/roms/msx1/frogger.zip
3.4.9 PSET
This command is used to manage the MSXPi variables, such as the wifi ssid, wifi password,
virtual drives, MSXPi current path, disk images and other user variables.
The variables are saved in a file: /home/pi/msxpi/msxpi.ini and loaded when MSXPi starts.
When used to set the disk images for MSXPi, this command will enforce the loading of the
new disk image, making it available immediately.
Note: It's recommended to not change variable DriveA, because it defines the disk with
MSX-DOS and the P commands for the MSX-DOS 1.03 boot. Changing this variable may
lock the user oout of the DOS, requiring manual changes to the msxpi.ini file to recover the
boot.
Examples:
pset
pset WIFISSID My Wifi Name
pset WIFIPWD MyWifiPass
pset DRIVE1 /home/pi/msxpi/disks/diskb.dsk
3.4.10 PWIFI
Display the current network interface information, and set the wifi using the Wifi variables
Examples:
pwifi
pwifi set
Note: "pwifi set" will use "WIFISSIDW" and "WIFIPWD" MSXPi variables to configure
the Wifi interface. After "pwifi set" command, a reboot is required for the Raspberry Pi to
enable and acquire the new network configuration.
3.4.11 PRESTART
Restart the MSXPi Server (msxpi.server.py) in the Raspberry Pi.
3.4.12 PREBOOT
Reboot the Raspberry Pi.
3.4.13 PSHUT
Shtudown the Raspberry Pi. This command should be used before powring off the computer.
4 Developers Guide
This section is directed to developers that want to create new MSXPi programs, in either BASIC or
Assembly in the MSX side. Note that all code on the server side is always Python.
The interface is enabled when the MSX write or read the IO ports 0x56, 0x57 and 0x5A. These
ports are decoded by the CPLD in the interface, serialize the data in the data bus and transfer to the
Raspberry Pi, which convert the data back bytes and process it as defined in the MSXPi protocol
(see next section).
The command name (8 bytes string) corresponds to a function in the msxpi-server.py running in the
Raspberry Pi. These comamnds (such as “pcd”) will be executed in the Raspberry Pi, and return the
output as a 256 bytes data block – in some cases, the returned data is larger than 256 bytes, in which
case the P command must be prepared to detect and process correctly the additional blocks – failing
to do this will cause the MSXPi to enter an “out of sync” state and fail.
There are many variations of the high level protocol, but as previously mentioned, they all must
start with a command being set to Raspberry Pi. Below it’s shown the main possible variations of
the structure and sequence of actions in MSXPi commands.
Send a command, followed by the parameters. Expect to to receive at least one block of data back
as response. This is the most common structure, because the response will contain useful data to be
presented to the user in either successful or failure situations:
• Output of the command executed in the Raspberry Pi
• Error message when the command failed
MSXPi Protocol 1
This structure is used in most of the P commands, and is also implemented in the CALL MSXPI for
BASIC development. The user can easily implement additional functinality for MSXPi using this
structure by cloning the TEMPLATE code (in the Clients/src folder) and the “template()” function
in the msxpi-server.py.
MSXPi Protocol 2
MSXPi Protocol 3
Send a command, send additional parameters, and receive many blocks of data. Optionally, send
also additional data during the execution of this command.
This is a more complex implementation, and there are different ways this structure can be
implemented, by either locking on not locking the msxpi-server. Study the command PCOPY
(locking the server to a single command) and the BASIC program IRC.BAS (not locking the
server).
“Locking the server” means that the command takes over the MSXPi until its completelly finished.
“Not locking the server” means the operatons are assynchronous, and one program span across
several calls to MSXPi, allowing other commands to be used in between calls.
MSXPi Protocol 4
Programs can be developed in BASIC to use MSXPi resources by using three BIOS commands:
• CALL MSXPI – Send a command and parameters to Raspberry Pi, and receive back a reply
• CALL MSXPISEND – Send a block of data to Raspberry Pi
• CALL MSXPIRECV – Receive a block of data from Raspberry Pi
All commands need a buffer address, which can be provided by the developer. If a buffer area is not
provided, the MSXPI BIOS command will automatically reserve one with 259 bytes at the top of
the RAM. Note that leaving the BIOS to reserve the buffer might be dangerous, because if the
commands return data larger than the buffer, it will start to overwrite system ram (and the STACK)
at the top of the RAM, causing a crash.
The recommended way to allocate a buffer is to do it explicitly in the command, with enough
capacity for the data that is expected to be received. For example, if the developer leaves the buffer
allocation responsibility for the MSXPi BIOS while using executing CALL MSXPI(“prun ls -lR /”),
the computer will crash because the amount of data returned by the command is immensely larger
than the buffer, consequently causing a crash.
Syntax:
CALL MSXPI(“<stdout>,<buffer address>,<command>”)
Examples:
call msxpi(“pdir”)
call msxpi(“0,pdir”)
call msxpi(“1,pdir /home/pi/msxpi”)
call msxpi(“2,D000,pdir /etc”)
Executes a command (function) defined in the “msxpi-server.py”, receives the reply data and
process it according to the option specified in the “stdout” parameter.
Possible values for stdout parameters
stdout Description
1 Print tall received data o screen. If the data is 1 block only, full data is also available in
the buffer. If it is larger than one block, only last block is available in the buffer
2 Store all received data in the memory starting in the address provided in the command
(the buffer). May corrupt the top RAM and stack if data is larger than the available space
in the buffer.
Buffer Address: This is a string composed of four hexadecimal digits for a memory area to receive
data from Raspberry Pi – for example, “C000”. It must have at least 259 bytes (BLKSIZE) available
from this address.
Command: Any command defined in the “msxpi-server.py” program. Each command is created as a
function in the server, as for example “pdir”, “pcd”, “prun” or any other command created by the
developer. Parameters are also accepted.
CALL MSXPi uses a buffer of size BLKSIZE (259 bytes) to receive data from Raspberry Pi. Each
block received will contain a header, as shown in this table:
A transfer occurs BLKSIZE bytes at a time, and it may have one or more blocks. If the total data to
transfer is larger than the BLKSIZE, then more than one block transfer will be required - the CALL
MSXPi command takes care of these, making sure all data is available for the user. However, if you
implement your own commands in the server to be called by CALL MSXPi, then you must assure
that the server contains the correct logic to send the blocks sequentially as described. Refer to one
of the MSXPi server commands to understand how it can be done.
lsb and msb bytes contain the data size for the data in this block. This is required because even
tough the transfers occur in blocks of fixed size (BLKSIZE), the actual user data might be less that
a block – all remaining data in the block is always padded with zeros. It’s also needed in cases
where the data is larger than one block – the header in each block contain the size of the useful data
in that block. The client program must control how much data and blocks is read from Raspberry Pi
based on this header.
The size for the useful data in the block can be calculated in BASIC as follows (assuming it was
passed “D000” in the CALL MSXPi command):
SIZE=PEEK(&HD001)+256*PEEK(&HD002)
Note that this buffer structure is hard-coded in the MSXPi BIOS commands, and need to be
respected by the MSXPi Server commands running in the Raspberry Pi.
The return codes in each block can be one of:
RC_TXERROR Connection error or checksum error after all retries. This code is generated
by the MSX client software because the transfer failed. There is not valid
data in the buffer.
RC_SUCCESS Operation successful. This code is returned by the Raspberry Pi. There is no
blocks to be transferred. Buffer contain valid data.
RC_FAILED Operation failed. This code is returned by Raspberry Pi. There is no more
blocks to be transferred. Buffer may contain a valid error message.
RC_READY Operation successful. This code is returned by the Raspberry Pi. There are
more blocks to be transferred. Buffer contain valid data.
Other return codes are available for use in development – consult the include.asm file reference.
When the command is called, the following scenarios may develop:
1. Connection error: Raspberry Pi did not receive the command or it failed the checksum. The
return code will be RC_TXERROR (set by the MAX due to lack of communication with Raspberry
Pi)
2. Raspberry Pi received the command, processed it but it failed: The return code will be set by
Raspberry Pi to RC_FAILED and there will be an error message in the buffer - some server-side
programs might set to a different error code, it’s up to the developer to define which error code they
want to use.
3. Raspberry Pi received the command, processed and it succeed. The return code is
RC_SUCCESS, and there will be data available in the buffer.
4. Raspberry Pi received the command, processed and it succeed. The return code is RC_READY,
meanign there is another blocks of data ready to be transferred. When receivig this return code, the
client software must read anotehr block, otherwise the service will be stuck waiting to send the data,
causing an “out of sync” situation.
This section describes the high level routines that can be used to support the development of new
applications for the Raspberry Pi to run under MSX-DOS or BASIC.
It’s described only the recommended routines, although may others are available and can be used by
the developer.
The template below show the minimum structure a MSXPi program should have, and the API
libraries it must import.
ORG $100
; User code – start here
;…
: ...
; User code – ends here
4.4.1.1 SENDCOMMAND
Sends a command with a maximum of eight bytes to the server. The command should be defined
somewhere, terniantd in zero and be valid ascii characters. Register DE must contain the address of
the command before calling SENDCOMMAND.
ld de,command
call SENDCOMMAND
...
...
ret
command: db "pdir",0
4.4.1.2 SENDPARMS
This command is only valid for MSX-DOS programs, as it reads the buffer area used to store
parameters passed when running .com commands (address $80). If the program does not need
parameters, this routine may not be used.
The routine uses the BUF area, which shouold be cleared before calling SENDPARMS.
ld de,command
call SENDCOMMAND
; Clear the buffer area, which has 256 Byes (BLKSIZE)
ld de,buf
ld bc,BLKSIZE
call CLEARBUF
; Check if there are parameters in the command and send to Raspberry Pi
call SENDPARMS
; User program here
...
...
ret
command: db "pdir",0
4.4.1.3 SENDDATA
Sends a block of data to the server - its the counterpart of RECVDATA. The size of the block to
transfer is passed in BC and the RAM address to read the data from in DE register. Any error in the
transfer will return flac C set, otherwise NC will be set.
After finishing the transfer, DE returns updated pointing to the next available address in the RAM
buffer.
ld de,buf
ld bc,BLKSIZE
call SENDDATA
jr c,error
ret
4.4.1.4 RECVDATA
Receives a block of data from the server - its the counterpart of SENDDATA. The size of the block
to transfer is passed in BC, and the RAM address to store in DE register. Any error in the transfer
will return flac C set, otherwise NC will be set.
After finishing the transfer, DE returns updated pointing to the next available address in the RAM
buffer.
ld de,$4000
ld bc,BLKSIZE
call RECVDATA
jr c,error
ret
buf: equ $
4.4.1.5 PRINTPISTDOUT
Prints a string to screen.
String address is passed in DE, and size in BC.
Will terminate and return if finds zero even if BC is not zero.
4.4.1.6 PRINTNLINE
Prints a ASCII 13 followed by a ASCII 10 to the screen, forcing the cursor to start of new line.
4.4.1.7 PRINT
Prints a text terminated in zero to screen.
String is passed in HL.
4.4.1.8 CLEARBUF
Write zeroes to a buffer area.
Address is passed in DE and size in BC.