[Openmsx-bugs] [ openmsx-Bugs-961064 ] Halnote: internal software of Sony HB-F1XDJ does not start

[SourceForge.net]

Bugs item #961064, was opened at 2004-05-26 21:35
Message generated for change (Comment added) made by manuelbi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=421861&aid=961064&group_id=38274

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General/misc
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Manuel Bilderbeek (manuelbi)
Assigned to: Wouter Vermaelen (m9710797)
>Summary: Halnote: internal software of Sony HB-F1XDJ does not start

Initial Comment:
It's in GOODMSX2... It seems to need the system disk,
but the MSX hangs at boot.

----------------------------------------------------------------------

>Comment By: Manuel Bilderbeek (manuelbi)
Date: 2007-09-29 12:00

Message:
Logged In: YES
user_id=78178
Originator: YES

Wouter implemented Halnote mapper, and Halnote seems to work now.

Question remains: how do we test the internal software of the Sony
HB-F1XDJ?

----------------------------------------------------------------------

Comment By: Manuel Bilderbeek (manuelbi)
Date: 2007-05-07 20:44

Message:
Logged In: YES
user_id=78178
Originator: YES

Here is some information I got from Rudolf Lechleitner about the Halnote
mapper:

First, the initial information, supplied in the RuMSX manual, it seems to
originate from Atarulum:


HALNOTE
Cartridge (6 Mega but total copy is 8 Mega). Switch adress is &HAFFF,
save-adress is &HA000, block-size is &H2000, first block is 00, last block
is 7F.

HALNOTE uses 16KB battery buffered RAM in page 0 as well as a small amount
of RAM in page 3. ROM-mapper size is 2KB, writing values with bit 7 set
enables write to the mapper-page, specified in the lower 7 bits (values
0-127).

Lex Lechz: This information is not verified. Because information is not
precise enough (how much ROM is writeable? how much RAM is present in page
3?) RuMSX does not emulate it completely!

SOFT TITLE : HALNOTE (6M)

BOARD : HAL ENGINE III (HAL LABORATORY)

MEGAROM CONTROLLER : M17H003 (OKI JAPAN:64pin) -- Konami 8KB Method(?)

ROM : HALOS-14 (40PIN:2M for HALNOTE OS??), LH5321L7 (SHARP:32PIN),
LH532122 (SHARP:32PIN) for KANJI & MSX-JE

SRAM(?) : AKM624ALSP-12 (ASAHI KASEI:28PIN) * 2EA

BATTERY : BR2330 (+3V)  MATSUSHITA ELECTRIC JAPAN)

ANOTHER CHIP : M74HC244P (MITSUBISHI : 20PIN) * 2EA, M74HC245P (MITSUBISHI
:20PIN), HBN-1K (9K4 12) (RICHO : 20PIN)

SWITCH ADDRESS : AFFF

SAVE ADDRESS : A000

BLOCK SIZE : 2000

FIRST BLOCK (FIRST BANK): 00

LAST BLOCK (LAST BANK) : 7F

TOTAL SIZE : 8Mega Bit (REAL SIZE : 6Mega Bit)


 * BLOCK 00 ~ 1F (2Mega Bit) : HALNOTE's Operating System Area.
 * BLOCK 2F ~ 3F (2Mega Bit) : Non Using Area. (Maybe RAM??)
 * BLOCK 40 ~ 7F (4Mega Bit) : JIS 1st/2nd Kanji & MSX-JE


===============

Next, additional information by Rudolf:

About status in RuMSX:
hmm, I guess the Halnote mapper in RuMSX is less working.
Of course I like to share the existing code. It hopefully helps to create
a fully working code.
The HALNOTE.ROM and HALNOTE1.DSK are starting properly, but after painting
the screen the code appears to hang. I assume this is due to the incomplete
implementation, but I have still no time to examine the current situation
in more detail. Therefore...

(Manuel: he supplied a couple of files form the RuMSX sources, available
on request.)

Current state & source:

1) RomtypeHalNote.htm - the mapper description, which is part of the help
files. Some parts are very technical, some parts unknown and assumptions
(explicitly stated). Anyway it is a good start to rebuild all facts and the
current state of my emulation. This file is part of my public source.
(Manuel: see above.)

2) Msxmedia.c - manages the media: maps the halnote.rom into pages 0-3
(64kb) and performs the auto-detection of this rom. This file is part of my
public source.

3) Msxmem.c - contains the memory-manager. The current implementation adds
16KB (S)RAM at the beginning of the image and fills them with 0xFF. This in
turn moves the ROM start to page 1 (beginning at 0x4000). This file is part
of my public source.
Notes:
3b) the SRAM size is described as 16KB, but I cannot verify it right now
3a) 0xFF seems to be the initial value of the cartridge SRAM, where
working with the ROM can change the SRAM contents - which will be used on
subsequent reboots. It would be a nice feature to support a reset to the
initial values (or is it provided somewhere within the ROM?). Anyway:
during experimental beta RuMSX does not save the contents, so they are
currently managed as normal RAM memory.

4) Msx.c - is for now internal only. Of course you can use all Halnote
relevant parts of this file. This is basically the function MapROM(), which
contains a section for the type ROMTYPE_EX_HALNOTE. The current
implementation behaves as following:
4a) Halnote and it's SRAM is mapped into pages 0-3 (64KB)
4b) Page 0 contains the (S)RAM
4c) Halnote uses 8KB memory banks
4d) Banks can only be changed by writing into page 1 or 2 (0x4000-0xBFFF).
Writing into an address switches the bank that is mapped to this address.
4e) The (S)RAM does not use bank-numbers. It appears to be fixed to page 0
and cannot be switched or moved.
4f) Valid bank-numbers are 0x00 to 0x7F (7 bits only, bit7=0). This
switches the banks in read-only mode
4g) Using bank-numbers 0x80 to 0xFF (bit7=1) ignores bit7, so that also
values 0x00-0x7F are used. But in this case the banks are writeable. This
is - for sure - not fully correct, but there are some indicators that some
pages do also contain RAM that can be toggled into readonly mode. This
implementation is intended to figure out more details about that.


===================

About testing it:

The HALNOTE consists of the ROM-cartridge and 2 disks. The ROM as
stand-alone cartridge appears to be worthless. Even in combination with the
2 disks reveals what's in it!
Insert the ROM-cartridge and boot  from Disk1. AUTOEXEC.BAT will run
HN.COM and should start the user-interface. In RuMSX the graphical
user-interface appears before the program freezes. Still something wrong
with the ROM-mapper...

=============

About usage of this mapper type in the Sony HB-F1XDJ MSX2+:

The HBF1XDJ.ROM indeed seems to use a mapper very similar to halnote.

a) The halnote-type (S)RAM in page 0 seems not to be present, so the ROM
appears to start at &H4000 only. Anyway: for experimental reasons the same
mapper can be used because the resulting configuration (except from the
additional RAM) would be the same.

b) Found mapping adresses are &H4000, &H6000 and &H8000.

c) The ROM-boot routine registeres an EXTBIO hook responding to calls with
D=&H10, E=&H00. This means that this bios extension provides a
kanji-driver. And really performing a CALL KANJI in MSX Basic accesses
several pages of this ROM.

d) Unbelievable that this additional driver (to MSXKANJI.ROM/32kb and
KANJI.ROM/256kb) should support Kanji only. Even the size of
HBF1XDJ.ROM/1024kb assumes that there is something else hidden in it. So it
may be worth more examination, but this would be an even harder task.
Hints: the small code starting at &H4000 contains the initialisation and
EXTBIO entrypoint only. The code starting at &H6000 seems to provide some
sort of BIOS routines (jump-table) for any unknown reason. Maybe it is
really a Kanji-driver only, but - who knows...?

That's it for now...

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=421861&aid=961064&group_id=38274

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Openmsx-bugs mailing list
Openmsx-bugs@...
https://lists.sourceforge.net/lists/listinfo/openmsx-bugs