Serial interface usage

[lexthehex]

Hi folks,

I've got a Bluetooth serial adaptor (similar to this one: http://www.hobbytronics.co.uk/bluetooth-module) that I'd like to install in my micro, for a bit of wireless remote operation. The adaptor emulates an RFCOMM channel on one side, and can use 3.3V or 5V signal levels. Referring to the 88DSKRAM CD 'Manuals/Altair_RD_4.pdf' document, I'm assuming that I connect the data output to CN3 pin 2 (RXD) and the input to pin 3 (TXD), and GND to GND. Should I connect anything to 'USB_ON'?

Finally, are the voltages 3.3V? I don't want to 'fry' anything..

Thank you.

Lex

[galaga]

i think its avr 5v and pic 3.3v?
but should be fine!!
i would like to know how you got on ..
i saw one on these on eBay 4 not to much

if it was me i would use the 3.3v supply (and maybe put some 100ohm resistors on the tx,rx pin to be safe)

[vbriel]

You can run any voltage between 3.3-5V so you will be fine with that. If you do this, be sure to document your work, I haven't seen any other BT connections posted yet. Last summer we connected a BT with my serial MP3 interface board to an apple II, fun stuff. Cable free is very nice.

So you know, we are working on a new version of the firmware that is able to change the BAUD rate on the Altair. This makes the computer more flexible with other hardware. Also, AUTOBOOT with onboard terminal shut off for external terminals that still need to boot from the SD card for CP/M and other software! Stay tuned, we are testing it now.

[lexthehex]

Vince, Galaga, thanks for your replies - I'll post another message when I've completed the mod. I'll use 3.3V and I'll add resistors too (thanks, Galaga).

[lexthehex]

My apologies for dithering with this one, as I have rather poor eyesight and have to rely on daylight to show me what I'm doing. In addition, I also required extra components and these took a few days to be delivered. List of excuses over..

I have connected a PCB header to CN3 on the RAM drive board and another PCB header to the HobbyTronics Bluetooth adaptor (http://www.hobbytronics.co.uk/wireless/bluetooth/bluetooth-module). Connection was initially established with a 3.3V serial USB adaptor, from a mobile phone. You can buy such adaptors on eBay, and HobbyTronics have a few as well. I used 100 ohm resistors in series with the data lines, to limit current because the TX output of the micro board is about 4V, and is a little high for 3.3V devices. I think there's a certain tolerance built-in to the inputs of most, but it's not much.

With a terminal app running on the PC (9600 bps), data is sent to the micro's onboard terminal - and the data output - on power-up. Because the terminal is enabled, the serial input is disabled and input comes from the keyboard only. Corey986 discusses this in another message (http://www.brielcomputers.com/phpBB3/viewtopic.php?f=31&t=1130) and states that the onboard terminal is disabled if you don't connect the keyboard, or press Ctrl-F7. I did the latter and can verify that after the onboard terminal is disabled, input is read from the serial input.

To test the system, I've been typing simple BASIC programs. An oddity is that in listings of 4K BASIC programs, the top bit of the first letter of each keyword is set. E.g. PRINT "Hello" is translated to [0xD0]RINT "Hello"

I'm taking pictures of everything and will write it up when I've finished.

[garryj]

To test the system, I've been typing simple BASIC programs. An oddity is that in listings of 4K BASIC programs, the top bit of the first letter of each keyword is set. E.g. PRINT "Hello" is translated to [0xD0]RINT "Hello"

That is odd. Is this just with 4K BASIC, or do 8K and 16K BASIC do it also? I'd expect all versions to be sending 7-bit ASCII. Which terminal program are you using? Although it shouldn't be needed, most programs expose an option to force incoming data to 7 bits.

On a more general note, when sending BASIC LISTings from your PC to the 8800micro via your terminal's "send text file" option, make sure it sends CR/LF for end of line, and an inter-character delay of at least 1ms is likely needed because the ATMega in the 8800micro only has a two character rx buffer. A tricky part when sending program listings from a PC is that BASIC needs some time to tokenize and store the line of incoming data, and as free memory gets smaller, the longer the delay becomes, so make sure your terminal settings on send include an end-of-line delay. I've found a good place to start is ~60ms, but it may not be enough when sending large programs.

Hope this helps, and have fun!

[lexthehex]

Hello Garry,

Thanks for your reply.

That is odd. Is this just with 4K BASIC, or do 8K and 16K BASIC do it also? I'd expect all versions to be sending 7-bit ASCII. Which terminal program are you using? Although it shouldn't be needed, most programs expose an option to force incoming data to 7 bits.

Versions of BASIC:

4K BASIC lists programs with the high bit set at the end of keywords, and only accepts uppercase chrs as input.
8K BASIC lists programs with the high bit at the start of keywords, and accepts upper and lower case input.
16K BASIC doesn't do it - it lists programs without the high bit set, and accepts lower-case chrs.

For the following code snippets, I have placed underline characters around output where bit 7 is set. These appear as an inverse-video '?' (in a diamond) on my terminal. I am using GNU Screen 4.00.03 on Ubuntu Linux 8.04.4.

Code: Select all

LIST

100 RE_M_ LEX WAS HERE!
O_K_
list

?S_N_ ERRO_R_
O_K_


Another example:

Code: Select all

PRINT 1/0

?/_0_ ERRO_R_
O_K_
LIST

100 FO_R_ A_=_1 T_O_ 10
110 PRIN_T_ A,A_*_2
120 NEX_T_ A
150 STO_P_


My first thought was that I have a problem with the SD card, but the checksums of all of the programs are okay, so maybe it's a hardware-specific thing with my micro (I put together the main board from a kit, but didn't trust myself with the DSKRAM add-on, so I got this assembled).

Regarding line delays, GNU Screen has a 'slowpaste' option to delay text during buffer upload. The delays can be made very long indeed, so this is not a problem. The CRLF line endings are a little awkward since Linux - and UNIX - uses LF as an end-of-line character. This just means running uploaded files through 'unix2dos'.

Lex

[chassum]

FWIW, I had something similar occur when I was using minicom connected to my Micro-Kim running fig-forth. IIRC, it cleared up when I changed from 8-1-N to 7-1-E. You might try something along those lines.

[garryj]

I'll be darned -- your serial I/O is working fine. I just dumped a listing from 4K and 8K BASIC and the high bit of keyword characters are set as you described -- 8K BASIC sets it on the first keyword character and 4K the last. I haven't ever combed an early MS BASIC disassembly, but I'd hazard a guess that they may have used the high bit to delimit keywords because memory constraints of the day were so tight and just about all terminal equipment was 7 bit.

I never noticed this because I used 4K and 8K BASIC very little, and the fonts we use for the internal Propeller terminal are 7 bit, so all character I/O was forced to 7 bit before being sent to the display, or the SD card when capturing text.I skimmed through the MITS 8K BASIC manual but didn't see any mention of it. The few times I've had my 8800micro connected to a PC via a serial<->USB dongle I was using either 16K BASIC or CP/M.

Something to learn every day...

[lexthehex]

Hello garryj, chassum and others,

From garryj:

I'll be darned -- your serial I/O is working fine. I just dumped a listing from 4K and 8K BASIC and the high bit of keyword characters are set as you described -- 8K BASIC sets it on the first keyword character and 4K the last. I haven't ever combed an early MS BASIC disassembly, but I'd hazard a guess that they may have used the high bit to delimit keywords because memory constraints of the day were so tight and just about all terminal equipment was 7 bit.

That's a relief, but it's a bit strange, as well. The high bit flag is common for many old BASICs - I remember looking through the Sinclair ZX81 ROM and seeing the high bit set at the end of all keywords. Why would they pass it through to the terminal, though? Very odd.

I've tested it on SIMH and it does the same thing.

To chassum:

My terminal program - being GNU Screen - doesn't mention parity settings in its manual, and doesn't appear to have any way to set them. I'll try Minicom instead. Screen's good points are its terminal emulation and multiplexing capabilities, but it isn't quite as good with serial lines. Minicom is specifically intended for dial-up links, and it has parity options.

Fixed! Setting parity to 7M1 or 7S1 fixes it. It's been a long time since I've done this basic serial stuff, but I'm guessing that it sets comms to 7-bit, with an additional parity bit set to mark or space.

I'm pleased to report that I have got the Bluetooth serial adaptor working, and I'm now wirelessly testing this stuff, over Bluetooth. I had some trouble powering the device, so I tapped into the VBAT line. This will mean a bit of extra drain on the batteries, but means that the adaptor continues to work after the Altair is switched off. I think that I did this because I couldn't find a 3.3V line, and VBAT is close. It's not an ideal solution and I should probably use VDD on the main board - anyone (Vince?), is there any way to get at this easily?

Cheers,

Lex.

[garryj]

It's not an ideal solution and I should probably use VDD on the main board - anyone (Vince?), is there any way to get at this easily?

Pin 12 of the Propeller chip on the main board is VDD and C11 is its decoupling cap.

[lexthehex]

Garryj wrote:

Pin 12 of the Propeller chip on the main board is VDD and C11 is its decoupling cap.

Garryj, thanks for that - got it. I'll leave this until tomorrow, because there isn't much light in here now - and I am getting tired. My soldering's bad enough when it's light, but when it's dark, it's frightening.

Lex

[lexthehex]

I am writing the documentation, which currently amounts to a very simple Google Docs document. It can be found here:

https://docs.google.com/document/d/1c1TBfCwY4sS6dAQfkF-kgntKxOcZEtHUsKt6GNLX46o/edit?usp=sharing

I will be adding photos, and there will probably be many corrections to be made. Comments are welcome at the above page.

Lex