HBI-V1 programing information needed...

Page 1/6
| 2 | 3 | 4 | 5 | 6

By NYYRIKKI

Enlighted (5385)

NYYRIKKI's picture

07-12-2004, 20:56

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 (???)

Login or register to post comments

By BiFi

Enlighted (4348)

BiFi's picture

07-12-2004, 22:03

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

By NYYRIKKI

Enlighted (5385)

NYYRIKKI's picture

07-12-2004, 23:55

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


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


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.


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

By NYYRIKKI

Enlighted (5385)

NYYRIKKI's picture

08-12-2004, 15:00

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

By HansO

Paladin (672)

HansO's picture

08-12-2004, 17:35

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

D startblock Y
0

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

D
0

E
0,1,2

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

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

By BiFi

Enlighted (4348)

BiFi's picture

08-12-2004, 18:09

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

By BiFi

Enlighted (4348)

BiFi's picture

08-12-2004, 18:50


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

By NYYRIKKI

Enlighted (5385)

NYYRIKKI's picture

08-12-2004, 19:59


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.

By HansO

Paladin (672)

HansO's picture

08-12-2004, 20:13

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

By NYYRIKKI

Enlighted (5385)

NYYRIKKI's picture

08-12-2004, 20:37


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

By NYYRIKKI

Enlighted (5385)

NYYRIKKI's picture

08-12-2004, 20:45

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

Page 1/6
| 2 | 3 | 4 | 5 | 6