Namco IPL Interface: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
m (→‎Data transfer format: "two byte pairs" sounds like 4 bytes)
(Remove CP/M reference and replace the final record example with a more traditional EOF record.)
Line 44: Line 44:
ASCII-encoded bytes are sent by the interface as byte pairs encoding the hexadecimal digits in ASCII (E.g. $5F would be encoded as <code>'5', 'F' -> $35, $46</code>), which are then decoded by the IPL. This means that the true sizes for each ASCII-encoded field in the above table are doubled.  
ASCII-encoded bytes are sent by the interface as byte pairs encoding the hexadecimal digits in ASCII (E.g. $5F would be encoded as <code>'5', 'F' -> $35, $46</code>), which are then decoded by the IPL. This means that the true sizes for each ASCII-encoded field in the above table are doubled.  


An example packet expressed as a list of ASCII strings:  
An example record expressed as a list of ASCII strings:  


<code>":", "02", "6942", "00", "BEEF", "A6"</code>  
<code>":", "02", "6942", "00", "BEEF", "A6"</code>  


If the data length is 0, the IPL reads 10 more raw bytes before exiting. The most straightforward way to format the final packet would be to treat the data field as a single ASCII-encoded byte and pad the remaining ASCII-encoded fields:  
If the data length is 0, the IPL reads 10 more raw bytes before exiting. The most straightforward way to format the final record would be to append an extra ASCII-encoded byte to a traditional EOF record, as the record type is not checked in this scenario:


<code>":", "00", "0000", "00", "00", "00"</code>  
<code>":", "00", "0000", "01", "FF", "00"</code>  


This method of terminating data (compared to using a $01 record type for EOF) is a common practice in most [[wikipedia:CP/M-80|CP/M-80]] assemblers.


The destination address determines whether the data is transferred to PRG-RAM or the PPU. If the destination address is below $6000, the IPL adds $2000 to it and sends the data to the PPU (likely intended for [[PPU_nametables | PPU nametable]] data). Otherwise, the destination address is used as-is and the data is sent to PRG-RAM instead.
The destination address determines whether the data is transferred to PRG-RAM or the PPU. If the destination address is below $6000, the IPL adds $2000 to it and sends the data to the PPU (likely intended for [[PPU_nametables | PPU nametable]] data). Otherwise, the destination address is used as-is and the data is sent to PRG-RAM instead.

Revision as of 02:34, 20 December 2023

The Namco IPL Interface is a proprietary Famicom expansion port device used for an Initial Program Loader (IPL.MAIN) present in Famicom Disk System games developed by Namco. The IPL and its interface allowed developers to upload PRG-RAM and PPU nametable data to the system, with an option to save the data to disk.

As the interface hardware was never released commercially, the information on this page is based on ongoing analysis of disassembled code from the IPL.

Interface

Input ($4016 write)

7  bit  0
---- ----
xxxx xxxS
        |
        +- IPL interface strobe

The strobe is only ever performed once by the IPL on start-up.

Output ($4017 read)

7  bit  0
---- ----
xxxD SDDx
   | ||| 
   | ||+-- Data bit
   | |+--- Data bit
   | +---- Status bit (set to 1 after strobe)
   +------ Data bit

The IPL checks for the interface's presence via the status bit after a single strobe. If this bit is set, the IPL initialises a data transfer. Otherwise, the IPL displays a fake license screen and boots the loaded game instead. It is unknown if the status bit remains set on successive polls (i.e. while the data bits are being polled).

It is unknown if all data bits contain identical data. The IPL simply ANDs the $4017 read with %00010110 and checks if any bits were set in the result. The bit order is %76543210.

Data transfer format

The interface transfers data to the Famicom using a variant of the Intel HEX format described as the following:

offset	size	description
------	----	-----------
0	1	start code, raw $3A byte (":")
1	1	ASCII-encoded data length (0: end data transfer)
2	2	ASCII-encoded destination address (big endian)
4	1	ASCII-encoded record type (must be $00, data type)
5	x	ASCII-encoded data
5+x	1	ASCII-encoded checksum complement
6+x		-

ASCII-encoded bytes are sent by the interface as byte pairs encoding the hexadecimal digits in ASCII (E.g. $5F would be encoded as '5', 'F' -> $35, $46), which are then decoded by the IPL. This means that the true sizes for each ASCII-encoded field in the above table are doubled.

An example record expressed as a list of ASCII strings:

":", "02", "6942", "00", "BEEF", "A6"

If the data length is 0, the IPL reads 10 more raw bytes before exiting. The most straightforward way to format the final record would be to append an extra ASCII-encoded byte to a traditional EOF record, as the record type is not checked in this scenario:

":", "00", "0000", "01", "FF", "00"


The destination address determines whether the data is transferred to PRG-RAM or the PPU. If the destination address is below $6000, the IPL adds $2000 to it and sends the data to the PPU (likely intended for PPU nametable data). Otherwise, the destination address is used as-is and the data is sent to PRG-RAM instead.

The checksum operation is performed on the decoded bytes with the carry always cleared, starting from the data length field. The complement must result in a final checksum of 0.

Hardware

The interface hardware was likely connected using an RS232-style serial port with a baud rate of 38400 (46.60 CPU cycles per bit, the IPL waits 47 cycles). The polling routine in the IPL checks for a start bit (1->0 transition), then waits 62 CPU cycles (~1.5 periods) before polling the data bits.

USB-to-TTL parts such as the PL2303 or FT232 may be able to recreate the interface on modern hardware.

References