Can someone help me to fill up the next table with correct information? I just collected this information today, so it can be still very wrong. The device I have is broken, so I can't even test it... The purpose is to help emulator makers to emulate this thing...


#7E00-#7EFF: Read buffer. Will return 256*256 picture. After one byte is read, next one will be returned. (LDIR/OTIR is used to read multiple bytes at a time)


#7FFC R/W: %ABC???XX
A Read: Busy or something like that (Z=Idle, NZ=Busy) Usually you can skip with ESC key.
B Read: ???(Need to change sometimes)
C Read: Video sync (Wait to be Z and wait to be back NZ)
XX Write: No info


#7FFD R/W: %A??DXXYY
A Read: Even/Odd frame
D Read: Video signal detected (NZ = No video signal)
XX Write: No info
YY Write: No info

#7FFE Write: %XXYYYZZZ
XX = ?
YYY = ?
ZZZ = ?

#7FFF Write: 8bit data (???)

Quote:

#7FFE Write: %XXYYYZZZ XX = ? YYY = ? ZZZ = ?

Are you sure this register is split up like that, then this might be something.

I think YYY and ZZZ are filled with the block size numbers for X and Y. Where which number is to written I don't know yet. The table is below.

XX might be filled with the start block value for either X or Y. The table is below.

I'm working the other way around though, from the CALL statements. Problem is I don't know what a few of these values actually do, but this is what I have found out sofar:

_DFONT (X,Y,Z$) - write text onto screen
[B = toggle 'bold'
[P = some YJK manipulation or something, haven't figured it out yet
[R = toggle 'reverse'
something with I and T

_TOBAS - reboot system

_DCLS - clear internal VRAM
ERR=19 - no video signal

_DG - start internal digitizer software

_AD (A,B,C,D,E,F,G) - automatic digitize & copy to VRAM
A = block size X
B = block size Y
C = start block X
D = start block Y
E = wait?
F = ?
G = interlace

_MD (A,B,C,D,G) - manual digitize
A = block size X
B = block size Y
C = start block X
D = start block Y
G = interlace?

_FMD - ?

_DCOPY (X,Y)-(X,Y)TO(X,Y) - copy area from internal VRAM to VRAM)

_YJK (Y,J,K) - YJK color adjust

---

block size X/Y:
0 = 1/1 = full screen
1 = 1/2 = full screen, resized to fit 2 times
2 = 1/3 = full screen, resized to fit 3 times
3 = 1/4 = full screen, resized to fit 4 times
4 = 3/4 = 1/3 screen, resized to fit 4 times
5 = 2/2 = half screen, twice displayed
6 = 2/3 = half screen, resized to fit 3 times
7 = 2/4 = half screen, resized to fit 4 times

start block X/Y:
0 = update 0-X parts
1 = update 1-X parts
2 = update 2-X parts
3 = update 3-X parts

wait?
X = wait X interrupts before digitizing?

Unknown:
0 = ?
1 = ?

interlace:
0 = digitize all lines
1 = digitize even lines
2 = digitize odd lines

Maybe this will help a bit. Meanwhile I'll try to do some more testing using your addresses, since I have a HBI-V1 as well. Any results I will post here.

Quote:

Quote: #7FFE Write: %XXYYYZZZ XX = ? YYY = ? ZZZ = ? Are you sure this register is split up like that, then this might be something.

I'm pretty sure, but I'll take a deeper look, when I have more time. The problem is, that this code is quite a "spaghetti", variables are stored in relative address calculated from stack etc.

Quote:

I'm working the other way around though, from the CALL statements. Problem is I don't know what a few of these values actually do, but this is what I have found out sofar:

You propably already figured this out, but just in case...

Type:

POKE &HFBB0,1
_DG

When you are in digitize software, press CTRL+SHIFT+GRPH+KANA/CODE

Type:

POKE &HFBB1,0
LIST

... and you can see the original software...

Quote:

wait? X = wait X interrupts before digitizing?

This sounds reasonable, if I understood the routines correctly, this is passed to digitize routine in register E when you use routines from ML jump table.

Quote:

Maybe this will help a bit. Meanwhile I'll try to do some more testing using your addresses, since I have a HBI-V1 as well. Any results I will post here.

Yes, this helps as I have already forgotten quite a well, how this thing worked (when it worked). It is also good to know, that there is technical person out there with working version of this cartridge.

Here is my guess, how internal jump table works. Could you test these routines as well, BIFI?

#4010 "SONY HBI-V1 V10",0

#4020 Digitize

	Input:
	C	=0 Copy to VDP
	B	=0 ???
	E	Nuber of frames to wait
	HL	Pointer to 6 bytes parameter table

	Table pointed by HL:

	n	0-255
	n+1	0-3	Interlace ???
	n+2	0-7 	Block size X ???
	n+3	0-7	Block size Y ???
	n+4	0-3	Start block x ???
	n+5	0-3	Start block y ???
	n+6	0-3

#4023 DCOPY or something like that

	Input:
	HL	Pointer to parameter table 

	Table pointed by HL:
	Lucky guess: x,y,x,y,x,y

#4026 Convert Screen
	Input:

	None

#4029 Digitize frame
	Input:

	None

	Explanation:
	Calls digitize routine (#4020) with following values:

	BC=1
	E=0
	Table pointed by HL: 0,3,0,0,0,0,0,1

#402C Start digitize software
	Input:

	None

	Explanation:
	Same as CALL DG in BASIC. Loads the BASIC program from ROM.

#402F Send command to hardware
	Input:
	HL	Pointer to 6 bytes parameter table

	Table pointed by HL:
	Same as in Digitize routine.

#4032 Copy Digitizer RAM to VRAM.
	Input:

	None

From the japanese manual I have (long ago) interpreted and tested the calls for the HBI-V1 as follows:

HBI-V1 CALLs

Screen divided in 4x4 blocks?
Calls work in screen 8,10,11,12, function depends on screen setting

AD(A,B,C,D,E,F,G) autodigitize

A block size X
0: 1/1 3: 1/4 6: 2/3
1: 1/2 4: 3/4 7: 2/4
2: 1/3 5: 2/2

B blocksize Y
0: 1/1 3: 1/4 6:2/3
1: 1/2 4: 3/4 7: 2/4
2: 1/3 5: 2/2

c startblock X
0<C<3

D startblock Y
0<D<3

E wait parameter (in frames, 60 per second, in Europe 50)
0 ~ 255 0 = nowait

F loop
0,1 (1 = loop)

G manual
0,1,2


DCLS DigitizerClearScreen

DCOPY (A.B) - (C,D) TO (E,F) call digitizer copy

0 <= A <=255
0 <= B <=211

A <= C <= 255

B <= D <= 211

0 <= E <=255
0 <= F <=211

DG Call digitizer menu

MD (A,B,C,D,E) call manualdigitize, see autodigitize

A
0: 1/1 3: 1/4 6:2/3
1: 1/2 4: 3/4 7: 2/4
2: 1/3 5: 2/2

B
0: 1/1 3: 1/4 6:2/3
1: 1/2 4: 3/4 7: 2/4
2: 1/3 5: 2/2

c
0<C<3

D
0<D<3

E
0,1,2

YJK (Y,J,K) RGB value to YJK?

-7 < Y < 7
-7 < J < 7
-7 < K < 7

@NYYRIKKI: I will test those routines as well.
@HansO: Thank you for this quite complete information. This will fill in those missing pieces in the list. It will also be a great help in 'disecting' the rest of the module on how to control it.

Quote:

#4029 Digitize frame Input: None Explanation: Calls digitize routine (#4020) with following values: BC=1 E=0 Table pointed by HL: 0,3,0,0,0,0,0,1

A few weeks ago I have been doing some disassembling on the ROM image to figure out some stuff and my guess is this routine is _DCLS. I haven't done all of it yet and I know it's not very legal to disassemble the ROM, but when you want to be able to emulate it (or control it using assembly), it's quite useful to find out what routine is doing what, just due to lack of documentation.

Quote:

YJK (Y,J,K) RGB value to YJK? -7 < Y < 7 -7 < J < 7 -7 < K < 7

First mystery solved. This will adjust YJK picture with RGB values. Like this:

_YJK (B,R,G)

Where each value represents amount of that (RGB) color to be increased or decreased. Example:

10 SCREEN 12
20 BLOAD"XYZ.SCC",S
30 _YJK(-7,0,0) ' Remove blue colors from picture.
40 A$=INPUT$(1)

This is propably the same routine, that can be found from #4026. HL points to table, where colors are.

The manual contains even more information, should I scan and publish it?

Quote:

Quote: #4029 Digitize frame Input: None Explanation: Calls digitize routine (#4020) with following values: BC=1 E=0 Table pointed by HL: 0,3,0,0,0,0,0,1 A few weeks ago I have been doing some disassembling on the ROM image to figure out some stuff and my guess is this routine is _DCLS. I haven't done all of it yet and I know it's not very legal to disassemble the ROM, but when you want to be able to emulate it (or control it using assembly), it's quite useful to find out what routine is doing what, just due to lack of documentation.

Ah, you must be right... Next "guess":

Table +1 contains SCREEN mode:
0 = SCREEN 12
1 = SCREEN 10/11
2 = SCREEN 8
3 = Other / Clear memory

This same value is transferred to #7FFE bit 6&7

Here is, how the table is put to #7FFC-#7FFF:

Table: A,B,C,D,E,F,G
#7FFC: %XXX***GG
#7FFD: %X**XEEFF
#7FFE: %BBCCCDDD
#7FFF: %AAAAAAAA

*=Not used bit
X=Bit used to read status from device.

As the filling of the table is started from #7FFF and there is 1 as a last byte in DCLS, I would guess, that bits 0/1 are used to execute command.

@Bifi: At least in this part of Europe, reverce engineering is fully legal.
@HansO: Can you see, does the manual contain any information about using the cartridge with ML? Also information about CALL FMD could be usefull...

No information at all in the manual about ML interface

FMD is not in the documentation, MD is (Manual Digitize).

The manual is a typical userguide: about connecting, about how to use the programs on the delivered floppy, the builtin DG program and the Basic statements. Nothing more technical, no circuit diagram, no description of the inner part of the ROM alas.
A pity, because this device is the best piece of MSX hardware I have seen to let a MSX2+ be usefull! The resulting pictures were for long the only way for me to digitize video pictures in high quality. A pity that the device is NTSC limited. The PAL mod did make it show colors on European video images, but the bottom part falls off (in NTSC 480 lines, in PAL 625). The knowledge how this PAL mod is done is lost I think. As is access to a service manual.

The worst thing in this device is, that you can't control the picture contrast or brightness. (well, you have the switch, but...)

I'm starting to think, that the bottom part problem is more limited by the software than hardware. This digitizer has 64KB of memory, but only 53K (212 lines) is copied to VRAM. Rest of the data (44 lines) is usually not read or copied over the ROM. If you can capture also this part of the picture, you still miss 56 lines, but that is only double of the amount you normally miss with NTSC picture. (I talk here about non interlaced picture)

I hope that someone could try, is the rest of the picture also available to use...

Quote:

Table: A,B,C,D,E,F,G #7FFC: %XXX***GG #7FFD: %X**XEEFF #7FFE: %BBCCCDDD #7FFF: %AAAAAAAA

Last version of my guess of writeable data:
A = ??? (Picture offset, I hope )
B = Screen mode (See earlyer post)
C = Y-Block size (Note: swapped with X)
D = X-Block size
E = Y-Start block
F = X-Start block
G = Command (01 = Execute 00 = Terminate?)

I noticed a switch on the side of the digitizer and a line from it goes to the upper input but not the lower. I wonder what the manual says about the two seperate inputs. Is there a difference between them? I found out the switch is some brightness setting on the input. My guess is the switch is supposed to be for the upper input only, but by trial and error it also works on the lower input.

@HansO: Maybe scanning it and putting it online can help us get a better view on some things when somebody can translate it.
@NYYRIKKI: I'll continue the disassembly to find out what all commands do. And I'll do some testing with the cartridge itself.