HBI-V1 programing information needed...

#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.

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

@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.

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.

#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.