Bell release v0.2!

Timendus · Post by **Timendus** » Mon 13 Nov, 2006 5:12 pm

Okay, my harddisk is alright, only the boot sector is toast. I've already backed up Bell and a few other small things through a very slow Linux live CD, and I'll continue development once I've got my PC booting again. Which could take a while if I have to reinstall everything from scratch...

Anyway, I'm off to install a proper Linux distro to backup the rest...

It's a bit sad that I need all my Linux systems (laptop, server, live CDs) to save my only Windows system

Edit: Damn, crosspost again

The full version with all the bells and whistles* is a bit under 700 bytes.
*) bytes, data blocks, large data blocks, strings, all swap routines

Post by **kv83** » Mon 13 Nov, 2006 5:21 pm

700 bytes... nice

Timendus · Post by **Timendus** » Thu 16 Nov, 2006 11:57 am

Okay, I wrote the manual (or at least a first version). Now I need to finish Ti-82 support, which is half done. Literally; I can set the lines, but I seem to be reading them wrong

Can someone please confirm that I only need to set bits 2 and 3 for the tip and the ring respectively to write to the port? The only source code that I found that uses it also sets bits 4 and 5, but since my routines were written to set two bits and not four I just picked bits 2 and 3 and it seems to work on PTI. I don't know about the hardware though, and I'm not sure what setting bits 4 and 5 would be good for; maybe it self-destructs if I neglect them?

About reading the port; it seems (again, looking at that source file) that I have to check bits 0 and 1, and zeros mean that the lines are high (not active), ones that a line is low (active). My test program doesn't behave as expected though, so either my information is not correct or my test program sucks

Input anyone?

KermMartian · Post by **KermMartian** » Thu 16 Nov, 2006 3:26 pm

This explains the bit thing better than I could, but if you don't feel like clicking and reading, no, you don't need to mess with bits 4&5:
http://wikiti.denglend.net/index.php?ti ... s:Ports:00

Post by **benryves** » Thu 16 Nov, 2006 3:36 pm

That's the 83+, not the 82.

(Yes, I made the same mistake, posting about the 83/83+).

Timendus · Post by **Timendus** » Thu 16 Nov, 2006 4:33 pm

Timendus wrote:Ti-82 support

kerm_martian wrote:http://wikiti.denglend.net/index.php?ti ... s:Ports:00

Read the question first, try to be the smartass with the answer second, Kerm

Edit: Ah, some answers...

link port

Write:
# Write $C0: white wire positive, red wire positive
# Write $D4: white wire positive, red wire negative
# Write $E8: white wire negative, red wire positive
# Write $FC: white wire negative, red wire negative

Read:
# bit 1 set: White wire is positive, but circuit is open
# bit 1 res: White wire negative, or positive with electrons flowing
# bit 0 set: Red wire is positibe, but circuit is open
# bit 0 res: Red wire negative, or positive with electrons flowing

It would seem that reading is exactely as I expected it to be. Writing is also as I had gathered from that source; each line gets two bits to set.

Code: Select all

$C0 = 11000000
$D4 = 11010100
$E8 = 11101000
$FC = 11111100

But like I said; it works just as well when I use only bits 2 and 3...

Timendus · Post by **Timendus** » Thu 16 Nov, 2006 5:07 pm

Many thanks to Mattias Lindqvist & Dines Justesen

They wrote this in 1999:

Code: Select all

-----------------------------------------------------------------------------
Port 0 : Link port                                                       R/W
-----------------------------------------------------------------------------

This port is used to communicate with other calculators, computers and CBL
equipment. The port is used in the same ways as the link port on the TI85.

The port consist of two parts, the Port Configuration Register (PCR) and the
Port Data Register (PDR). PCR controls whether the PDR is used as input or as
an output (PCRx controls PDRx). PDR is used to send and receive data.

Bit  Function
--------------------------------------------------------------------
 7   PCR3
 6   PCR2
 5   PCR1
 4   PCR0
 3   PDR3
 2   PDR2
 1   PDR1
 0   PDR0

PDR bit 0 and 2 is used to control/read the voltage on the tip, while bit 1
and 3 is used for the middle. The base is always used for ground.

Each of the the data lines have the same circuit attached (shown below).

Normally PCR is set to C0 by the ROM, which sets          Vdd
PDR0/1 as inputs and PDR2/3 as outputs. Doing this        ---
means that the voltage at the tip and the middel           |
can be read as PDR1/0. PDR2/3 is then used to control      < 10 KOhms
the output (a one gives an output of app. 0V).             >
                                                           |
When two calculators are connected together the            V Diode
output will be high if neither of them has their           |
transistor on, otherwise it will be low (wired or)    out--O---------- PDR0/1
                                                           |
                                                           < 470 Ohms
                                                           >
                                                           |
                                                      NPN  \__/\/\____ PDR2/3
                                                           /  33 KOhms
                                                           |
                                                         __|___
                                                          Gnd


Write:
------

When writing to the link port the upper nibble sets the PCR, while the lower
sets the PDR. The state of the tip and the middle can be set using the
following values.

Value  Function
----------------------------------------------------
C0     White wire is positive. Red wire is positive.
D4     White wire is positive. Red wire is grounded.
E8     White wire is grounded. Red wire is positive.
FC     Whits wire is grounded. Red wire is grounded.

The above values are the values used by the ROM, except for FC which is not used
since the system never sets both wires to ground. Other values can be used, but
these gives the best results.

Read:
-----

When the a byte is read from the link port, the upper nibble contains the last
value written to the PCR. Assuming that these are set to 1100b (e.g. one of the
above mentioned values where written to PCR), the contence of the PDR can be
interpeted as follows.

Bit  State Function
------------------------------------------------------------------------
2+3        Last value written
1    1     White wire is positive.
     0     White wire is grounded.
0    1     Red wire is positive. 
     0     Red wire is grounded.

Emphasis on:

Normally PCR is set to C0 by the ROM, which sets PDR0/1 as inputs and PDR2/3 as outputs.

So, taking into account that it complicates reading from the port to use values in the first nibble other than $C (%1100), I'll use $C0 as the base value for Bell, write to bits 2 and 3 and read from bits 0 and 1. Which is exactely what I was doing

Guess I hadn't set the first nibble right in my test program...

Edit: Got it... Stupid little mistake in my test. It was supposed to pull the other line low when you pull one line low and return when you pull both lines low. I hadn't realized that when you pull one line low, and the Ti-82 pulls the other low, that would also be detected as both lines being low, and the Ti-82 would return. So when it returned on pulling one line low, I figured I wasn't reading the port right. In other words; I had it right from the start

New version coming up!

Timendus · Post by **Timendus** » Thu 16 Nov, 2006 7:02 pm

Version 0.2 has been released, as has the manual. Enjoy the read, and please do let me know what you think!

New features:

Send or receive zero terminated strings
Swap datablocks and strings
Compile for Ti-82

On the new Ti-82 support: It compiles, it's controlling the link port, my moving sprites demo runs on it, but my demo gives a "Connection lost" at random moments. It probably has something to do with my lack of knowledge or experience with programming for Ti-82, and the fact that the Ti-82 is much slower in comparison.

It seems I have also fixed the Ti-83+ crash bug (which also appeared on Ti-82). I wasn't controlling the key port correctly in the api routine kbd.waitKey(). Another something that could have been the cause is that I was calling Ti-OS routines with interrupts disabled. I'm not entirely sure. Either way, it wasn't Bell, so it isn't important.

Edit: It was the disabled interrupt thingy.

Edit 2: At Vincent:

It seems to have shrunk in size

Code: Select all

Brass Z80 Assembler 1.0.4.7 - Ben Ryves 2005-2006
-------------------------------------------------
Assembling...
Pass 1 complete. (718ms).
BELL: Selected hardware: Ti-82
BELL: Library included, size is 601 bytes
Pass 2 complete. (125ms).
Writing output file...
Errors: 0, Warnings: 0.
Done!

601 bytes on all calculator models, with all the bells and whistles turned on.

Timendus · Post by **Timendus** » Sun 19 Nov, 2006 11:42 am

So, we've all lost interest, haven't we?

Well, it doesn't matter, I'll upload the next version to Ticalc.org, and be done with it. After that I'll probably only fix a few bugs, and perhaps write one or two extra features when I'm really bored. This is supposed to be a quick stable branch of CLAP, not something I want to develop any further.

Planned for version 1.0:
- Improved error feedback (with optional error handler and report routine for the lazy people)
- Optional checksum bit per byte (will probably make transfers about 20% slower, but who knows it might be useful to someone)
- Check to see if it's still TASM compatible

- See if I can polish bell_connect up and perhaps take a look at the connection loss problem with Ti-82
- If I have time left: write a (few) nice demo(s)

Saibot84 · Post by **Saibot84** » Mon 20 Nov, 2006 4:26 pm

pretty cool Timendus!

Post by **benryves** » Mon 20 Nov, 2006 4:34 pm

Heh, not lost interest - it's a cool project.

However, I don't really intend to write any multiplayer games just yet, so it's of limited use to me just yet, so I can't really comment on it too much.

Post by **kv83** » Mon 20 Nov, 2006 4:59 pm

I didn't lose intrest, just wasn't around for a couple of days. Great to hear that you shave of some bytes

As I said, I'll use this with my new project... when I have time to work on it.

Timendus · Post by **Timendus** » Mon 20 Nov, 2006 9:57 pm

Don't worry, I'm not blaming anyone

It's too specific to have a broad audience

It would be nice to be able to point to your game and say "look, that's what Bell can do!"

But I guess I'll have to write a few demos myself. I had a nice idea about that (which I've had since pretty much the beginning of this project) but I'm not sure if it's possible at all...

Oh, and I didn't shave anything off, I just didn't remember it correctly. I've added quite a few bytes to it today though with the error report routine (lots of strings), so it's nearing 1000 bytes with all features turned on. You'll probably not use all features in a more realistic situation though

Timendus · Post by **Timendus** » Mon 08 Jan, 2007 11:52 pm

I've managed to find a moment to work on this project again this evening! Almost forgot that it's so much fun and such a pain in the ass at the same time

Anyway:

I fixed
- TASM compatibility (several small problems)
- SPASM compatibility (thanks Spencer

)
That is, they are now both able to assemble the library without throwing any errors. There's still a chance that there are other problems though, but I don't expect any.

Working on
- Improved error feedback (with optional error handler and report routine for the lazy people)
The error handler and report routine is pretty much done now, but not all routines set the right flags yet when they encounter errors. Also, the error reporting has revealed a bug in my connect routine (see below), so that's slowing me down a bit.

Still to be done
- Optional checksum bit per byte (will probably make transfers about 20% slower, but who knows it might be useful to someone)
- See if I can polish bell_connect up and perhaps take a look at the connection loss problem with Ti-82
- If I have time left: write a (few) nice demo(s)

New found bug
- When two programs with different program IDs try to connect one calculator will return the right "incompatible program type" error and the other just times out while they should both give the same error

Looking at the transfer in PTI's debugger reveals that the calculator that sends it's ID second tries to send a one bit after the ID swap for God knows which reason...

I'm not yet releasing the current version, even though I'd have loved to fix the assembler compatibility, because it's too much of a mess in it's current state. I'm going to try to fix the connect bug first, then finish the error reporting, and after that I can release a new version. If anyone would like a version that works with TASM or SPASM in the mean while, just contact me and I'll help you out.

Edit: All routines should now set the error flags properly. Most of it's been tested to work too

. And it has grown quite a bit; it's now 1028 bytes with all the fun stuff enabled

Now I just have to get the connect bug and the "connection lost is sometimes crash" bug which has re-appeared out of my code and it should be alright for a release! But for now I'm going to bed. G'night!

Timendus · Post by **Timendus** » Tue 09 Jan, 2007 2:21 pm

Timendus wrote:New found bug
- When two programs with different program IDs try to connect one calculator will return the right "incompatible program type" error and the other just times out while they should both give the same error Looking at the transfer in PTI's debugger reveals that the calculator that sends it's ID second tries to send a one bit after the ID swap for God knows which reason...

Fixed. Turned out my error flag got overwritten on sending a byte, so the calculator that received first, sent second wouldn't see the error, try to send data, and time out.

Now on to the "connection loss is sometimes crash" bug

My guess is that it could have something to do with my fiddling with the stack pointer with interrupts enabled... It really sucks trying to debug an error that only occurs once every thirty or so tries...