Here is all I know about it. Keep in mind that I have never managed to write a working routine to send a byte of data from one calc to another. THe closest I got was sending a byte, but the receiving calc didn't exit the loop. Anyways:

You can write 00b to 11b to port 0 (that is 0 to 3). When you write these values to the port, the read values are inverted. For example, if you do this:

Code:


When the other calc reads port 0, they will get the lower two bits as 01. This can actually be quite useful, to. Whenever you read from port 0, you should always mask out the upper 6 bits. When you write to the port and then read from it, bits 4 and 5 reflect what your write value was.

So to be clear, if one calculator writes %01 to the port, the other calculator will read %10. Also, when your routine is done, write the value 0 to port 0 to reset it to its proper values. Otherwise, the OS thinks data transmission is being attempted and the calculator will seem to freeze up (it doesn't freeze, it just takes a while for it to detect other inputs such as key presses).

I am not sure what the hardware specs are, but I am pretty sure their role is important, too.

And just to clarify Xeda's point about the flipping, it's not that the link lines get exchanged as they would in an RX/TX <-> TX/RX scenario. It's that reading bits is logically inverted from writing bits. Also, from a hardware perspective, a logical high ("1") is 0V, or the line shorted to ground. A logical low ("0") is 5V, or the line left floating at VCC. If either calculator pulls a line to electrical low or logical 1, then BOTH calculators read it that way until BOTH calculators release it.

Thanks for the help on that. I was asking because I want to include these topics in my Z80 tutorial, which I resumed while Zelda is on summer hiatus.

Let me be a bit more specific about my questions...

1. Would writing to the link port follow the same conventions as writing to the LCD or keyboard port? How about reading?

2. Can you read/write a full byte at a time, or will it only read 2 bits at a time (cuz of the high/low thing)?

Err, I would recommend that someone more experienced with the link port and with interrupts write at least those two topics, personally. Yes, writing and reading to the link port uses the in and out commands, but I think you're imagining it happening at a much higher level than it does. Those two bits aren't two actual transmitted bits, they're the current voltage/logic levels of the two lines. You manipulate those with a higher-level protocol to synchronize and send/receive bits and bytes.

Ah, I see. Would you happen to know who I can consult on that?

PS: My tutorial is going to, at the end, glorify DCS's assembly libraries, AP feature, and CALCnet

I am probably not the one to talk to on those points as I am not too experienced. What I typically attempt is this kind of style:

Use one of the bits as a clock and the other as a data bit. With this method, you only send one bit at a time. When one calc sends a bit, say it sets the clock bit to 0. Now when it reads from the port, the clock bit is 1. When the other calc is reading, the clock bit is 1, too, so it takes the data bit, and writes the clock bit as 1. Now the clock is at zero, so the sending calc knows the system is ready to receive the next bit.

That is a bit messy, but it should provide some results.

Xeda, do you mean that in your scheme, the sending calc releases clock, and the receiving calc asserts clock? Either way, that unfortunately won't work, because remember that when either calc asserts a line (digital 0->1, electrical 5v->0v), it has to release that line before the other calculator can do anything with it. Most schemes I know have the sending calc toggling the clock line up and down, with either rising or falling edges signalling the receiver to read a data bit. Many will also do a bit-level parity or packet/frame-level confirmation of successful transmissions via a checksum. ACagliano, I'd be happy to help out with consultation or content to the best of my abilities, but of course I have a few time constraints. And I certainly appreciate that the tutorial will raise awareness of DCS's tools for ASM coders!

Thanks Kerm. I was thinking of publishing this as an ebook and selling it for a nominal price, for the main intent of funding ClrHome's .org domain and possibly allowing us to buy our own server. Any suggestions for a good price? I will, of course, be posting it here and on omni as well, for free, cuz u guys are awesome. lol.

*you guys. I must say that I've found selling/asking for donations to be fairly unpopular in the community, but you certainly have every right to try for it. And of course, how much it will be worth will be dependent on its length and quality. Speaking from experience as a student and a teacher, the most beneficial thing you can possibly do is have a lot of good, well-annotated code examples. Even if you do everything else poorly, just make your code examples plentiful and good.

Hmmm. Well, I figured I'd put it free in places cuz I don't want to force people to pay for it. I was actually thinking like $.99, maybe less, however good it is. oh well. I'll ask what the community thinks when its done.

That seems reasonable to me as an initial plan. Do you have any kind of schedule in mind as far as completing the project? Will you be releasing the chapters as you go for comments, or all at once at the end? Do you have an outline/table of contents yet?

I do, but its kind of out of whack atm. Let me whip one up:


Table of Contents

UNIT 1

CHAPTER 1 – YOUR CALCULATOR UNLEASHED
SECTION 1 – A MATHEMATICAL TOOL
SECTION 2 – A GAMING CONSOLE
SECTION 3 – A MINI COMPUTER
CHAPTER 2 – MERITS OF PROGRAMMABILITY
SECTION 1 – USAGES
SECTION 2 – “HISTORY” RECOLLECTION
SECTION 3 – USER-DEFINED “FUNCTIONS”
CHAPTER 3 – TOOLS AND RESOURCES
SECTION 1 – WHAT IS A PROGRAM?
SECTION 2 – WHERE CAN I FIND THEM?
SECTION 3 – QUALITY AND COMPATIBILITY
SECTION 4 – HOW DO I USE THEM?

UNIT 2

CHAPTER 4 – PROGRAMMING MATH LEVEL 1
SECTION 1 – BITS, NIBBLES, BYTES, AND WORDS
SECTION 2 – OPERATION FLAGS
SECTION 3 – HEXADECIMAL, BINARY, AND DECIMAL
SECTION 4 – ADDITION AND SUBTRACTION
SECTION 5 – MULTIPLICATION AND DIVISION
CHAPTER 5 – PROGRAMMING MATH LEVEL 2 14
SECTION 1 – WHAT IS A BOOLEAN?
SECTION 2 – BIT-LEVEL OPERATIONS
SECTION 3 – BIT-LEVEL ARITHMETIC
CHAPTER 6 – FUNDAMENTAL CONCEPTS
SECTION 1 – TYPES OF MEMORY
SECTION 2 – THE CPU
SECTION 3 – ADDRESSING AND POINTERS
SECTION 4 – VARIABLES AND EQUATES
SECTION 5 – DATA TYPES

UNIT 3

CHAPTER 7 – BASIC SKILLS
SECTION 1 – MOVING AND COPYING DATA
SECTION 2 – READING AND WRITING TO MEMORY
SECTION 3 – SUBROUTINES AND SYSTEM ROUTINES
SECTION 4 – CONDITIONALS AND PROGRAM FLOW
CHAPTER 8 – TEXT DISPLAY
SECTION 1 – HOME SCREEN
SECTION 2 – GRAPH SCREEN
CHAPTER 9 – USING EXTERNAL VARIABLES
SECTION 1 – NAME STRINGS
SECTION 2 – “PROGRAM” TYPES
SECTION 3 – “APPLICATION” AND “APPLICATION VARIABLE” TYPES
SECTION 4 – “STRING” AND “EQUATION VARIABLE” TYPES
SECTION 5 – “LIST” AND “MATRIX” TYPES
SECTION 6 – “OP” VARIABLES

UNIT 4

CHAPTER 10 – CREATING AN INTERFACE – INPUT
SECTION 1 – GETKEY AND GETCSC
SECTION 2 – PROMPTING FOR DATA
CHAPTER 11 – CREATING AN INTERFACE – OUTPUT
SECTION 1 – DISPLAYING IMAGES
SECTION 2 – BUFFERS AND GRAYSCALE
SECTION 3 – EVENTS AND EVENT SCRIPTS
SECTION 4 – MODIFYING DATA
CHAPTER 12 – MOST ADVANCED TOPICS
SECTION 1 – THE KEYBOARD PORT ($01)
SECTION 2 – THE LCD DRIVER ($10 AND $11)
SECTION 3 – THE LINK PORT
SECTION 4 – INTERRUPTS
SECTION 5 – HOOKS
SECTION 6 – APPLICATION PROGRAMMING
CHAPTER 13 – SIMPLIFYING THE COMPLEX
SECTION 1 – THE ASSEMBLY LIBRARIES
SECTION 2 – THE DCS GUI AND ASSOCIATED PROGRAM FEATURE
SECTION 3 – CALCNET 2.2 AND GLOBAL CALCNET

APPENDIXES

APPENDIX A - STANDARD PROGRAM/APP HEADER
APPENDIX B – COMPLETE Z80 INSTRUCTION SET, PROCESSING TIMES, AND BATTERY USAGE
APPENDIX C – FULL TI-Z80 REGISTERS LIST
APPENDIX D – FULL TI-Z80 VARIABLE TYPE LIST
APPENDIX E – SAMPLE PROGRAM – THE GUESSING GAME
APPENDIX F - FULL TI-Z80 HOOKS LIST
APPENDIX G - FULL TI-Z80 GETKEY/GETCSC CODES

Ow, my ears. You really like capital letters, don't you? That's certainly a very ambitious outline, but I'm sure not too ambitious for your ability to complete it. How about my questions about timing and release schedule?

I am filling in the sections out of order, so I'm not sure about either. I will definately let you know. As for the caps, I cut and pasted from Word's TOC, which is all caps.

Timendus would be the person to talk to about that, they recently stopped by MC (MaxCoderz) and i believe put their CLAP site (http://clap.timendus.com/) and BELL library (http://bell.timendus.com/) back online. They did a lot of investigation into the link port and even today are probably one of the more knowledgeable people on the subject.

Ok, thanks...

On the topic of interrupts. I understand the majority of it, but I'm a bit boggled by something. How does the calc determine where to get the interrupt.

The low byte of the address of the interrupt is in the "i" register.
The high byte is randomly selected from some address between $9900 and $9A00.

Is that right?

Chickendude: I remember being awed by Timendus' CLAP around the time when I was first attempting to put CALCnet together. Luckily, since then I've learned a lot and can look back in slightly-uncomfortable nostalgia on my newbishness. Have you seen the current iterations of CALCnet (Cn2.2) and globalCALCnet (gCn)?

ACagliano: Sort of. The *high* byte of the address is the 'i' register. The *low* byte is a random number between $00 and $FF. If you assume that i is, for example, $9A, then the address read could be anywhere from $9A00 to $9AFF. From that address, the calculator will read a two-byte value. If you fill $9A00 through $9B00 (257 bytes) with a single one-byte value, such as $99,$99,$99,..., then the calculator will reliably jump to $9999 when it reaches your interrupt. Because you don't know if it will hit the interrupt vector table at an odd or even byte, the interrupt itself must be at an address with a doubled number, such as $9999 or $B4B4 or $8080.

Ah. Now I see. Thanks.

You're welcome. The z80 is designed to get the low byte from the bus, set by the interrupting device, but for some reason TI didn't implement this in their ASIC. Therefore, the bus value is always just a random number.

CAn you use this bus for random generation?