Update README.md

This commit is contained in:
Charles Mangin 2016-07-20 16:25:01 -05:00 committed by GitHub
parent 8807187ed1
commit c40dcbd5e1
1 changed files with 26 additions and 33 deletions

View File

@ -46,8 +46,6 @@ Luckily, there are already examples of reading in data on those pins.
I dug into [Michael Mahon's NadaNet](http://michaeljmahon.com/NadaNetPaper.html) implementation for inspiration, and found proof of speedy and reliable communication on the game port. This was encouraging.
But, rather than require developers to implement NadaNet network packet reads just to get a few bytes into and out of an AVR, we can continue to take inspiration from the cassette routines. Using those as a starting point, I look for a transition from LOW to HIGH in pushbutton 1, then count the loops until the transition from HIGH to LOW. If it's a short time, the bit is zero, if it's longer, a one.
===
@ -151,52 +149,37 @@ uses $EF for storing outgoing byte
On the GP2IO side, the AVR has two interrupts set on ANN0 and ANN1: as the RTS pin goes HIGH (rising), and on changes to the data pin. If the data pin changes state in less than 70 microseconds (.07 milliseconds) the bit is read as zero. Longer than 70 microseconds, a one.
~~~
attachInterrupt(0, APPLERTS, RISING); // ANNUNCIATOR 0, Apple sending byte
attachInterrupt(1, RECEIVINGBITS, CHANGE); // ANNUNCIATOR 1, Apple sending bits
void APPLERTS() {
// signal to start receiving bits from Apple II
bitCount = 0;
changeCount = 0;
returnByte = B00000000;
}
void RECEIVINGBITS()
{
// ignore short "reset" transitions
currentMicros = micros();
if (changeCount % 2 == 1) {
if ((currentMicros - lastMicros) > 70) {
receivedBit = 1;
} else {
receivedBit = 0;
}
byteArray[7 - bitCount] = receivedBit;
bitCount++;
}
changeCount++;
if (bitCount == 8) { // got a BYTE
receivedByte = arrayToByte(byteArray, 8);
PROCESSBYTE( byte(receivedByte) );
TIMEOUTCLOCK = millis();
}
lastMicros = currentMicros;
}
~~~
===
@ -223,13 +206,21 @@ Processing Bytes on the GP2IO
The AVR starts in a null "standby" state, waiting for a "control" byte from the Apple II to set its function. Subsequent bytes after the function is set are the "message". The value of the first byte from the Apple determines the function according to this table:
$01 Sets the RGB LED on the GP2IO to the color value of the next three bytes, in order Red, Green and Blue. Requires 3 byte message
$02 Sets the RGB LED to white, intensity based on the 1 byte message that follows (0-255).
$04 Write the following message to an internal buffer, for retrieval later. First byte is message length (0-255 bytes follow)
$08 Write the following message to UART serial (buffered). First byte is message length (0-255 bytes follow)
$10 Write the following 8 bytes to I2C bus. For the demo, this is connected to either an 8x8 LED matrix or a 4 character 7-segment display. Requires 8 byte message.
$20 SPI (not yet implemented)
$40 Query the buffer. Triggers the AVR to respond with one byte, containing the length of the current buffer.
$80 Send the buffer. Triggers the AVR to respond with the first N bytes of the buffer, where N is the byte following the $80 trigger.
$00 Debug mode. At the moment, simply echoes the bytes received from the Apple side into the serial buffer, and prints them to USB serial out. Also sends one byte from the GP2IO buffer to the Apple whenever the APPLECTS signal (Annunciator 2) goes high.
@ -259,6 +250,7 @@ EXAMPLE: RGB LED Pulse white
SLIGHTLY MORE COMPLEX EXAMPLE: RGB LED pulsing
SETRGB:
one-shot, sets the LED with red value in $06, green at $07, blue at $08
@ -272,6 +264,7 @@ SETRGB:
0811- 20 03 03 JSR $0303 ; SENDBYTE
0814- 60 RTS ; return.
CYCLERGB
0816- A9 00 LDA #$00 ; set accumulator to 0