PC-98: Star Cruiser (Arsys) not booting

[yksoft1]

Apparently it uses GDC K-CG mode to show its copyright screen.

[joncampbell123]

I'm still not clear what K-CG mode does. Ignoring it has worked so far.

[sikthehedgehog]

Apparently it controls access to K-CG, which is the memory that holds the kanji font? Although when I look up about it there are also mentions about K-CG being able to reside in ROM or RAM… I'm clueless, but it definitely has something to do with the kanji font.

Found this: https://www.webtech.co.jp/company/doc/undocumented_mem/memsys.txt

bit 3: K-CG(漢字キャラクタジェネレータ)アクセスモード 1= ドットアクセス 0= コードアクセス(起動時設定)

• PC-9801初代では無効(常にコードアクセス状態)

Translation (part Google Translate, part me cleaning up):

bit 3: K-CG (Kanji Character Generator) access mode 1 = pixel access 0 = code access (startup setting)

• Invalid in first generation PC-9801 (always code access state)

What does "code" mean here? Character/codepoint?

[joncampbell123]

I'm aware that in the CG most of it maps to ROM, except for a subset of the codes that are mapped to RAM (188 of them if I recall).

DOSBox-X emulates the default behavior seen on real hardware where font bitmaps written to these RAM locations are rendered as the font bitmaps they are. Without which custom bitmaps for the text layer would not render (for example: the scoreboard in Touhou Project on the right hand side of the screen).

[joncampbell123]

Could K-CG pixel access be a mode in which these code somehow come out to a bitmap? In the same way that in Simple Graphics mode the vertical line attribute becomes a signal to render the low 8 bits of the character as a low resolution 2x4 bitmap in the character cell?

[joncampbell123]

I don't think the game is hanging because of K-CG mode. At the point it hangs at the logo waiting for flags to set.

I also see DOSBox-X's log reporting unknown access to ports 88h and 8Ah which if I recall are suppose to be the older FM board I/O ports.

[joncampbell123]

The only code to bind to 0x88/0x8A is in board14.c, boardpx.c, and boardx2.c

The 26k and 86 FM boards respond to both 88h/8Ah and 188h-18Eh even, correct?

EDIT: No, that's not the problem. The game is clearly trying to use the OPNA at 188h. The interrupt handler appears to read it right off the bat.

Enabling FM timer tracing code shows that it writes 0x00 to FM timer register 0x27, which clears all interrupts. It doesn't appear to do anything to trigger FM timer interrupts.

[joncampbell123]

Hung condition loop.

EAX=00000C02 ESI=000007B6 DS=1060 ES=0000 FS=0000 GS=0000 SS=2800 Real EBX=00004000 EDI=00004100 CS=0060 EIP=0000348F C0 Z1 S0 O0 A0 P1 D0 I1 T0 ECX=00000100 EBP=0000C03F NOPG IOPL3 CPL0 EDX=00000007 ESP=0000FFFE 16

0060:00003497 823E0F0100 cmp byte [010F],00 ds:[010F]=C500 0060:0000349C 7403 je 000034A1 ($+3) (no jmp) 0060:0000349E E89F00 call 00003540 ($+9f) 0060:000034A1 823E0E0100 cmp byte [010E],00 ds:[010E]=0000 0060:000034A6 7403 je 000034AB ($+3) (no jmp) 0060:000034A8 E82300 call 000034CE ($+23) 0060:000034AB C3 ret

0060:0000348F 823EC60000 cmp byte [00C6],00 ds:[00C6]=0001 0060:00003494 75F6 jne 0000348C ($-a) (no jmp) 0060:00003496 C3 ret

It's not waiting for vsync, because INT 2h vsync is masked.

Master interrupt controller state ICW 0/0 special=0 auto-eoi=0 rotate-eoi=0 single=0 request_issr=1 vectorbase=0x08 active_irq=8 isr=00 isrr=ff isrignore=80 IRQ INT# Req /Mask/Serv 0 0x08 1 0x09 2 0x0A M 3 0x0B M 4 0x0C M 5 0x0D M 6 0x0E M 7 0x0F CASCADE Slave interrupt controller state ICW 0/0 special=0 auto-eoi=0 rotate-eoi=0 single=0 request_issr=1 vectorbase=0x10 active_irq=8 isr=00 isrr=ff isrignore=00 IRQ INT# Req /Mask/Serv 8 0x10 9 0x11 10 0x12 M 11 0x13 M 12 0x14 13 0x15 14 0x16 M 15 0x17 M

Note: IRQ0 = system timer, IRQ1 = keyboard, IRQ2 = vsync, IRQ12 = FM, IRQ 13 = mouse

Game has it's own IRQ0 handler and IRQ12 handler. It does not install any other handlers.

[joncampbell123]

Ok... in a rather elaborate IRQ0 handler, it's looking at port 90h (floppy controller) and testing a bit. It might be waiting for a bit to clear.

[joncampbell123]

If I enable the floppy emulation, the game talks directly to the FDC and issues some seek, check interrupt, and some read commands.

[joncampbell123]

This game, like several other PC-98 games that talk directly to the floppy controller, will probably not work in DOSBox-X until the FDC controller emulation is revised and cleaned up.

[joncampbell123]

I want to clarify that booter games with their own custom FDC support code generally don't work in DOSBox-X yet, especially if they are doing that to read odd sector arrangements or tricks like sectors marked head == 0 on physical head 1.

[joncampbell123]

Here's something.

The IRQ0 handler does not read back response to a command if the busy bit is set.

The READ command is "hanging" with the game because my implementation considers the FDC busy until the read response has been read back (my experience with some FDC controllers on some Pentium motherboards).

Clearing the busy bit immediately after read works, but then our own FDC data read function refuses to return data because it assumes no data to return if not busy.

Fixing that code to return data from buffer, busy or not, gets the game going and it issues a few reads. However it crashes, implying the wrong data is being returned.

[joncampbell123]

Ah, out of range sector numbers.

Fixed.