Bell release v0.2!

[Timendus]

Thank you for your answer

The rom call witch were causing the problem is _getkey

Quote from WikiTi

Haha, exactly, I wrote that quote

Good to hear that you seem to have fixed your bug! I hope so!
Weird though to have such a bug on the hardware and not in the emulator if the ROMs are identical. That's really quite unusual.

[M@thieu41]

I didn't know that

Someone told me than the emulator is sometimes more successful than the hardware...

But i have some bugs with the connexion, i don't know why, but sometimes the game leave for no reason. Else, it work perfectly

Thanks you again for your help ^^

[M@thieu41]

Finally, it doesn't work very good: the connexion is often lost (it quit the game without write the score) and sometimes, i have some "ram cleared".
I don't understand why, have you any idea?

EDIT: Once, i've had a message while i were testing my game:
"ERR: TYPE DONNEE
1:Quitter"

[Timendus]

That's a very hard question to answer from such a distance

Once, i've had a message while i were testing my game:
"ERR: TYPE DONNEE
1:Quitter"

That's not an assembly error, but a TI-OS / Basic error.

ram cleared

That's an assembly error of the type "you're writing data where you're not supposed to be writing" (in most cases).

It seems to me like you have messed up a pointer somewhere (maybe the stack?) and are either writing to or jumping to a bad location. I'd say that this is unrelated to Bell. Time to do some good old bug hunting in your game logic? But this seems like a topic for a programming help forum, not for this thread. If you make a new thread, link to it for me so I can follow it a bit, will you?

[M@thieu41]

But this seems like a topic for a programming help forum, not for this thread. If you make a new thread, link to it for me so I can follow it a bit, will you?

Sorry for this.

But finally, I've maybe found the problem: it is on the bell_swapByte routine:

Code: Select all

bell_swapByte: 
	; Store data to be sent 
	push af 
	; Should we send first or receive first? 
	ld a,(bell_calcId) 
	or a 
	jp z,_bell_sendFirst 
 
_bell_recvFirst: 
	; Receive data 
	call bell_recvByte 
	; Exit on receive error 
	ret nz                            ;<- 1.You don't do pop before ret, if there's an error... 
	; Store the received byte 
	ld b,a 
	; Get the byte to send 
	pop af 
	; Store the received byte even safer 
	push bc 
	; Send data 
	call bell_sendByte 
	; Retrieve the stored data 
	pop af 
	ret                                ;<- 2.It can be z, or nz, but not necessary the same at the out of bell_sendByte 
 
_bell_sendFirst: 
	; Get the byte to send 
	pop af 
	; Send data 
	call bell_sendByte 
	; Exit on send error 
	ret nz         
	; Receive data 
	call bell_recvByte 
	ret  
 
_bell_sendFirst: 
	; Get the byte to send 
	pop af 
	; Send data 
	call bell_sendByte 
	; Exit on send error 
	ret nz                           
	; Receive data 
	call bell_recvByte 
	ret                                

I've replace it by:

Code: Select all

bell_swapByte:
	; Store data to be sent
	push af
	; Should we send first or receive first?
	ld a,(bell_calcId)
	or a
	jp z,_bell_sendFirst

_bell_recvFirst:
	; Receive data
	call bell_recvByte
	; Exit on receive error
	jr nz,_bell_recvFirst_skip
	; Store the received byte
	ld b,a
	; Get the byte to send
	pop af
	; Store the received byte even safer
        push bc
	; Send data
	call bell_sendByte

_bell_recvFirst_skip:
	; Retrieve the stored data
        pop bc
        ld a,b
        ret

_bell_sendFirst:
	; Get the byte to send
        pop af
	; Send data
	call bell_sendByte
	; Exit on send error
	ret nz
	; Receive data
	jp bell_recvByte

and it works(but on the emulator, i've not test on the hardware)

[M@thieu41]

Do you know if any other routine from TI-OS (other than _getkey) messes the ports?

[Timendus]

Wow, you found an error in Bell, that's awesome!
Did your fix solve the problems on hardware?

It's not necessarily getkey that messes with the link port, but -- if I remember correctly -- the Ti-OS silent link transfer code. This is the code that enables you to push programs to the calculator from your PC when you're in the Home screen (not in receive mode). The code is triggered by an interrupt controller and by getkey. Once it gets triggered it starts communicating with the other calculator instead of letting Bell do that.

[bastiaanc]

Hi everybody,

I'm a sixteen-year-old Dutch boy. My English is not very good, so don't be suprised if I make a very stupid mistake

I heard of this topic by Timendus. I've mailed him a serveral times a few months ago, but I found out it was more difficult as I expected, so I decided trying it first by myself. I've tried to learn the z80-assembly-language (how is that called?) and in my opinion I can work good enough with the language.

Btw, I'm with a friend working on a communication system between two Texas Instruments calculators. (I know, we could copy Timendus' CLAP or Bell, but it's for an essay (in Dutch a PWS, I guess Timendus knows what I mean) so I want to figure out the biggest part by myself.)

At the moment I want to test the linkport, but I don't know a good emulator that also works with the linkport. Timendus recommended me a few months ago to use PindurTI, but i could only find a version for TI-82 or 83, but I need TI-84. Does anybody know a good emulator that can handle the linkport? Now I'm using Wabbitemu. (WOW, this smiley is exactly the logo of Wabbitemu... can't be coincidence)

Buttttt I read you are/were using Brass, but I don't really understands how it works. My experience in programming is by the way not quite good. Actually my knowledge of generally computerprograms isn't very good too. I hope that's not a problem.

I hope you can help me. Thanks in advance (can you say that in English?)

[M@thieu41]

Wabbitemu works for this, but some rom call mess the linkport in harware and not in the emulator...

PS I m not english too,sory for my mistakes

@timendus: it doesn t work in the harware, i think it s the fault of one of the rom call i use in my game:
_vputs
_ipoint
_dispop1a
_setxxop1
Do you know something about that?

[bastiaanc]

Aah thanks for your respond I've found the function of the linkport in wabbitemu. (wasn't expecting it did excist, because none of you said they used it.)
Thanks

[M@thieu41]

Do you have any idea for my problem?

[bastiaanc]

Uhm, sorry, I don't exactly understand your problem. I'm not a very experienced assembler. Maybe the problem is a result of bcall-instructions, wich resets the linkport, but I guess you allready knew that.

[Timendus]

@timendus: it doesn t work in the harware, i think it s the fault of one of the rom call i use in my game:
_vputs
_ipoint
_dispop1a
_setxxop1
Do you know something about that?

Could you be more specific on what isn't working right now?
Maybe you can disable all the calls first, see if it's working then, and enable them one by one?