@GTV reviews the Cosmic Fantasy 1-2 Switch collection by Edia, provides examples of the poor English editing/localization work. It's much worse for CF1. Rated "D" for disappointment, finding that TurboGrafx CF2 is better & while CF1's the real draw, Edia screwed it up...
Main Menu

Hu7 development system interface routines

Started by ccovell, 12/10/2015, 06:59 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ccovell

Hi, folks.  The talk about NEC Avenue games having analogue joystick code in them, etc, got me browsing around a few of their ROMs.  And I found something cool inside the boot bank of OutRun (probably others...): from $F400- onwards, it has a minimal Hu7 command interface!

Search around for the Hu7, Hu7CD on the Web or YouTube if you don't have an idea of it yet.  It contains a large amount of extra RAM, and possibly several MBits of ROM space too.  Well, by examining how the OutRun code does stuff, we can glean a bit of information about the Hu7 interface.

At least bank $FC contains RAM, and it is needed as OutRun's code copies bank $00 to this, then modifies the first $400 bytes, and uses it as a boot bank as well as RAM.

A PC Parallel Port is connected to the Hu7 system, and its ports are $1C00-1C4x or higher.  These ports are always accessed by the PC-Engine in LOW CPU SPEED MODE...

A map of ports:
$1C00: data byte from PC to PCE
$1C01: data byte to PC from PCE
$1C02: handshake from PC to PCE in bit 2 and/or 3
$1C03: handshake to PC from PCE in bits 0,1,3,4, and 7 (dunno what they all do)
$1C20-$1C22:  (??  CD-ROM simulator?)
$1C40: ?  Both written and read.

Dunno about the others for now, but the command interpreter in OutRun waits for the bytes $48,$75,<command byte> then acts on command numbers from $00-$1F.  (Heartwarmingly, $48,$75 is "Hu" in ASCII.)

The commands (as far as I have deciphered them) are:
00: "NO COMMAND"
01: Send byte data "$03,$11" to PC from PCE.
02: Read further address bytes from PARPORT (LL,HH) and send byte at that Add. location back to PC.
03: Read (as above) from PARPORT and write sent byte to specified address into PCE Add.
04: Boot to ROM/RAM, maybe?
05: Send stored registers/MPR to PC from PCE.
06: Send stored registers/MPR from PC to PCE.
07: Send mem range (ADDR, LEN) to PC from PCE.
08: Send mem range (ADDR, LEN) from PC to PCE.
09: Send VRAM version of command 07.
0A: Write VRAM version of command 08.
0B: Fill memory version of 08 (with a single byte value).
0C: Fill VRAM version of 08 (with a word value).
0D: Copy memory (SRCADDR, LEN to ADDR2).
0E: Copy memory (SRCADDR, LEN to VRAMADDR).
0F: Copy VRAMADDR to memory (ADDR, LEN).

10: Copy (move?) VRAM to VRAM
11: Send Physical address (??) to PC from PCE.
12: Read 1 dummy byte from PC to PCE.
13: Send boot MPR regs to PC from PCE.
14: Send boot MPR regs from PC to PCE.
15: Version of command 07 with specified PCE bank.
16: Version of command 08 with specified PCE bank.
17: Send byte data "$24" to PC from PCE then boot to ROM/RAM?
18: Send VCE PAL version of command 07.
19: Write VCE PAL version of command 08.
1A: Send 3 bytes from PC to PCE, written to regs $1C20-$1C22.
1B: Regs $1C20-$1C22 sent to PC from PCE.
1C: Send word data at (ADDR,Bank,LEN) to PC from PCE.
1D: Write word data to (ADDR,Bank,LEN) from PC to PCE.
1E: VRAM version of command 1C.
1F: VRAM version of command 1D.

----

When Hu7 is started up, the code in OutRun does the following:
#$80 -> $1C23
#$00 -> $1C20,$1C21,$1C22
#$01 -> $1C40
#$91 -> $1C03
... wait for $1C02 bits 2,3 to both be high
#$09 -> $1C03
#$0B -> $1C03

... wait for $1C02 bit 3 to be low     ;start of "get byte" routine
read $1C00
#$08 -> $1C03
... wait for $1C02 bit 3 to be high
#$09 -> $1C03                              ;end of "get byte"
-----

here's the "write byte" routine:
byte -> $1C01
#$0A -> $1C03
... wait for $1C02 bit 2 to be low
#$0B -> $1C03
... wait for $1C02 bit 2 to be high

elmer

Nice find!  :D

It sounds like they've left in the stub code for the PC debugger ... that's a bit of a "naughty".

ccovell

Here are the HuCards that I found had a Hu7 header in them:

game                    ver.    address

Atomic Robo Kid         1.10    $F400
Deep Blue               1.00    $F800
Drop Rock Hora Hora     1.10    $F400
Drop Off (U)            1.20    $F200
F-1 Pilot               1.00    $F800
Gai Flame               1.20    $F200
Gaia no Monshou         1.00    $F800
Mahjong Goku Special    1.10    $F400
Niko Niko Pun           1.10    $F400
Out Run                 1.10    $F400
P-47                    1.00    $F800
Titan           (? possibly 1.10) ~$F400


Version 1.20 adds about 8 more functions, so I'll look into them.

MooZ

I'll try to run etripator on some v1.20 games tonight.

ccovell

Do you have a (Win) executable of etripator anywhere for download?

MooZ

#5
Yep :

For Gai Flame, I'm using this configuration file for the moment:
[hu7d]
filename=hu7.asm
type=code
bank=0
org=f243
size=d9

update

ccovell

Thanks!  By the way, if you want to test out any of these Hu7 stubs in an emulator, you can change the reset vecs to the start, and change the 3 or so references to bank $FC at the start to $F8 (regular PCE RAM.)

dangdang


ccovell

Mooz, does your disassembler have a way to add labels to ZP (RAM) locations and absolute addresses used in operands?

MooZ


MooZ

I quickly hacked something.
Labels are now used in opcode arguments.

etripator v0.5 (beta)

ccovell

Well, I finished before your latest version came out, but here's my disassembly of the Hu7 routines:

https://www.chrismcovell.com/texts/chris_hu7_dis.asm
https://www.chrismcovell.com/texts/labels.cfg
https://www.chrismcovell.com/texts/gaiflame.cfg

Version 1.20 has 8 more routines that add BRAM, ADPCM, and Supergrafx support.  A few functions, registers, and RAM locations I couldn't figure out how they worked, so let me know if you figure them out.

MooZ

cmd11_Send_Phys_Addr_Broken? is super/really weird...
Do you know if it appears in the other games?