Re: [M100] Packet radio like it's 1987
Usually, you will make your own cable. Look up the pin out for your radio’s connectors. Most mobiles have a TNC connector on the back, a mini DIN that looks a lot like a PS/2 connector. For radios without a TNC connector, you have to be creative. It usually involves an interface box like a RigBlaster to connect to the microphone and speaker jacks. On Thu, Apr 29, 2021 at 2:21 AM Jeff Gonzales wrote: > Alex, > > Can you help me with a similar setup? I think I found a TNC like yours in > the garage. Where do I get a cable for the radio? What radio are you > using? Can I use a cheap Baofeng for this or do I need an HF radio? > > Thanks, > Jeff > > On Wed, Apr 14, 2021 at 11:54 AM Alex ... > wrote: > >> Figure this would be a fun one to share with the [M100] list. :) >> >> I recently bought a big box of random ham radio packet gear which >> included a bunch of old TNC modems and assorted cables. Unfortunately, it >> turns out the quad serial port card in my desktop PC is dead. >> >> Enter the Tandy 102 to the rescue! I was able to test all 4 of the TNCs >> on the air and sent a test email from the T through a local Winlink RMS >> node. >> >> This whole exercise got me wondering if the built-in Bell 103 modem could >> be adapted for HF packet radio use. Has anybody tried that yet? >> >> Pictured in the attached photo is the Tandy 102 hooked to a MFJ 1274 >> modem, monitoring Network 105 traffic on 7104khz. >> >> -Alex >> > -- Tom Wilson wilso...@gmail.com (619)940-6311
Re: [M100] Packet radio like it's 1987
Sure, I'll give it a shot. To connect the TNC to the Model T, you'll need a cable with two DB-25 male connectors, or the right adaptors and dongles to get an equivalent. In my setup I have a DB25 male to DE-9 female cable on the T102, then a DE-9 gender bender, and another DE-9 female to DB-25 male cable plugged in to the TNC. Double check with an ohmmeter or continuity test if you're unsure what kind of cable you have. Try 1200 baud 8-N-1 first (STAT 58N1E in TELCOM) and power on the TNC. It should print some kind of banner with the ROM version it is running and then give you a "cmd:" prompt. If it does, try a couple of commands from the documentation to set it up with your callsign, etc. If you don't get the banner and prompt, or you see a bunch of gibberish, try different baud rates and other settings until something legible comes through. My radio is a Yaesu FT-857D and I wired the cable to connect it to the TNC myself using the manual for both machines as a reference. The Kantronics and MFJ TNCs I have all came with instructions about which pins do what in the documentation. For the Baofeng, you might be able to find an appropriate cable online somewhere, depending on the radio. For something super cheap like a UV5R, it'll probably cost as much as the handheld itself, and I'm cheap, so I'd probably just butcher one of the (frankly awful) earphone/mic cables that come with them and use that to wire it up. It might be necessary to adjust some of the trimpots on the TNC to get the audio levels right before transmitting. Again, check the manual for details. You don't need a HF rig if there's any local packet stations near you on VHF or UHF. If you just want to test RX and see if it will decode packets, try setting some of the MONITOR settings on the TNC to ON and tune to 144.39Mhz. If there is anyone using APRS near you, you might hear packets there. In my county, there's a network of digipeaters that has pretty wide coverage on this frequency so there's always packets every few seconds with weather station reports, locations of people driving around, info about local repeaters, etc. Another place to look is the RMS list for Winlink email. You can find a list of stations running those nodes here: https://www.winlink.org/RMSChannels - Winlink's documentation on the subject sucks, but if you CONNECT to one of these nodes, there's some simple commands like "LM" or "B" that you can use to get around without a proper Winlink client. Try "HELP". At this point you've got the Model T as a dumb terminal for packet radio. Somebody more handy with BASIC than I could probably write up a program to display the APRS weather reports nicely or make a proper WL2K mail client. :) Hope that helps! -Alex On Wed, Apr 28, 2021 at 6:51 PM Jeff Gonzales wrote: > Alex, > > Can you help me with a similar setup? I think I found a TNC like yours in > the garage. Where do I get a cable for the radio? What radio are you > using? Can I use a cheap Baofeng for this or do I need an HF radio? > > Thanks, > Jeff > > On Wed, Apr 14, 2021 at 11:54 AM Alex ... > wrote: > >> Figure this would be a fun one to share with the [M100] list. :) >> >> I recently bought a big box of random ham radio packet gear which >> included a bunch of old TNC modems and assorted cables. Unfortunately, it >> turns out the quad serial port card in my desktop PC is dead. >> >> Enter the Tandy 102 to the rescue! I was able to test all 4 of the TNCs >> on the air and sent a test email from the T through a local Winlink RMS >> node. >> >> This whole exercise got me wondering if the built-in Bell 103 modem could >> be adapted for HF packet radio use. Has anybody tried that yet? >> >> Pictured in the attached photo is the Tandy 102 hooked to a MFJ 1274 >> modem, monitoring Network 105 traffic on 7104khz. >> >> -Alex >> > -- Disclaimer: Any resemblance between the above views and those of my employer, my terminal, or the view out my window are purely coincidental. Any resemblance between the above and my own views is non-deterministic. The question of the existence of views in the absence of anyone to hold them is left as an exercise for the reader. The question of the existence of the reader is left as an exercise for the second god coefficient. (A discussion of non-orthogonal, non-integral polytheism is beyond the scope of this article.) Thanks /usr/games/fortune
Re: [M100] Packet radio like it's 1987
Alex, Can you help me with a similar setup? I think I found a TNC like yours in the garage. Where do I get a cable for the radio? What radio are you using? Can I use a cheap Baofeng for this or do I need an HF radio? Thanks, Jeff On Wed, Apr 14, 2021 at 11:54 AM Alex ... wrote: > Figure this would be a fun one to share with the [M100] list. :) > > I recently bought a big box of random ham radio packet gear which included > a bunch of old TNC modems and assorted cables. Unfortunately, it turns out > the quad serial port card in my desktop PC is dead. > > Enter the Tandy 102 to the rescue! I was able to test all 4 of the TNCs on > the air and sent a test email from the T through a local Winlink RMS node. > > This whole exercise got me wondering if the built-in Bell 103 modem could > be adapted for HF packet radio use. Has anybody tried that yet? > > Pictured in the attached photo is the Tandy 102 hooked to a MFJ 1274 > modem, monitoring Network 105 traffic on 7104khz. > > -Alex >
Re: [M100] Packet radio like it's 1987
Around the same ear I had my mobile packet rig setup - A 73 Toyota Corolla with a Yaesu Memoriser, and TAPR TNC2, and a Model 100. I remember leaning over at the traffic lights one afternoon, typing "Not now Kevin, I'm driving" Those were the days before people had mobile phones and we could touch things in the car without police having a hernia. Kindest regards, Doug Jackson em: d...@doughq.com ph: 0414 986878 Check out my awesome clocks at www.dougswordclocks.com Follow my amateur radio adventures at vk1zdj.net --- Just like an old fashioned letter, this email and any files transmitted with it should probably be treated as confidential and intended solely for your own use. Please note that any interesting spelling is usually my own and may have been caused by fat thumbs on a tiny tiny keyboard. Should any part of this message prove to be useful in the event of the imminent Zombie Apocalypse then the sender bears no personal, legal, or moral responsibility for any outcome resulting from its usage unless the result of said usage is the unlikely defeat of the Zombie Hordes in which case the sender takes full credit without any theoretical or actual legal liability. :-) Be nice to your parents. Go outside and do something awesome - Draw, paint, walk, setup a radio station, go fishing or sailing - just do something that makes you happy. ^G ^G ^G ^G ^G ^G ^G ^G- In more laid back days this line would literally sing ^G ^G ^G ^G ^G ^G ^G ^G On Thu, 22 Apr 2021 at 14:35, Mike Eppler wrote: > I ran a packet station on the Iditarod Race start line in 1987. the > equipment was a Yaesu FT221R transceiver a MFJ 1270 TNC and a Model 100. We > were the backup for the starting timer. Great Fun and a Little cold. The > rig was a red Toyota Land Cruiser, and we parked on Knik Lake. 73's to all > Mike, KL7ILA > On 4/19/2021 10:38, Alex ... wrote: > > Douglas, > You make a very good point. I'd never even considered that the UART might > get in the way. After a look over the datasheets for the chip, there > doesn't seem to be any way to disable the stop bit functionality and turn > it into a dumb shift register. > > Now I'm wondering if the old modem chip could still be utilized in a > hybrid approach: Bypass the UART and read/write bits directly to the modem > via the 8085's SID/SOD lines? It could be less work for the CPU this way, > since the modem can deal with the waveforms and frequencies in hardware. > That's another hardware mod, and still leaves the timer problem. > > Regarding hardware mods to the M102, the way I see it is: When am I going > to use this modem on a telephone line ever? Using the RIT is a good idea > though. > > Jeff, > If you want to use the Tandy as a terminal with an external TNC like I've > been doing the past week, you just hook it to the serial port with the > necessary adapters and use TELCOM to type commands to the TNC. Make sure > you turn on flow control or your TNC will probably outrun the old model T. > So far I've used it to send Winlink email through a local VHF RMS node and > made a couple of contacts on HF. > > On Sat, Apr 17, 2021 at 8:19 PM Douglas Quagliana > wrote: > >> >How much of the 8085's time will be left to do anything useful at all >> with the data with it essentially bit-banging the waveforms like that? >> >> Probably not much CPU time will be left while receiving. But packet >> radio is half-duplex on HF and VHF. If you are connecting to a packet >> radio BBS or having a keyboard to keyboard chat with another human, there >> isn't much that the CPU needs to do except display the received data and >> look for keys being pressed on the keyboard. >> >> > With the modem and UART hardware doing the hard layer 1 work, the CPU >> should have plenty of cycles to spare to deal with the bit stuffing, >> encoding, CRC checks, AX25 packet structure, etc. >> >> Can the Model 100's modem/UART hardware be configured to just demodulate >> bits synchronously? The way the modem/UART would be used over the phone >> lines would be asynchronously (the "A" in "UART"), where every 7 (or 8) >> data bits are placed in between a start bit and a stop bit, and maybe with >> a parity bit at the end of the character being sent. "8N1" is really a >> start bit, eight data bits, no parity bit and one stop bit. These ten bits >> for a character are sent, then there could be a pause for a small fraction >> of a second and then the start bit for the next character is sent. That's >> "asynchronous" serial. >> >> However, AX.25 packet radio doesn't work that way. It's synchronous. >> AX.25 uses an HDLC flag byte (0x7E) as a "start of data frame" indicator >> and then a continuous stream of bits (all the data bits for the whole >> packet one after another) with zero bits stuffed in after five contiguous >> one bits and then another HDLC flag for the end of the packet. In AX.25 >> there are no start bits, no stop bits and no
Re: [M100] Packet radio like it's 1987
I ran a packet station on the Iditarod Race start line in 1987. the equipment was a Yaesu FT221R transceiver a MFJ 1270 TNC and a Model 100. We were the backup for the starting timer. Great Fun and a Little cold. The rig was a red Toyota Land Cruiser, and we parked on Knik Lake. 73's to all Mike, KL7ILA On 4/19/2021 10:38, Alex ... wrote: Douglas, You make a very good point. I'd never even considered that the UART might get in the way. After a look over the datasheets for the chip, there doesn't seem to be any way to disable the stop bit functionality and turn it into a dumb shift register. Now I'm wondering if the old modem chip could still be utilized in a hybrid approach: Bypass the UART and read/write bits directly to the modem via the 8085's SID/SOD lines? It could be less work for the CPU this way, since the modem can deal with the waveforms and frequencies in hardware. That's another hardware mod, and still leaves the timer problem. Regarding hardware mods to the M102, the way I see it is: When am I going to use this modem on a telephone line ever? Using the RIT is a good idea though. Jeff, If you want to use the Tandy as a terminal with an external TNC like I've been doing the past week, you just hook it to the serial port with the necessary adapters and use TELCOM to type commands to the TNC. Make sure you turn on flow control or your TNC will probably outrun the old model T. So far I've used it to send Winlink email through a local VHF RMS node and made a couple of contacts on HF. On Sat, Apr 17, 2021 at 8:19 PM Douglas Quagliana mailto:dquagli...@gmail.com>> wrote: >How much of the 8085's time will be left to do anything useful at all with the data with it essentially bit-banging the waveforms like that? Probably not much CPU time will be left while receiving. But packet radio is half-duplex on HF and VHF. If you are connecting to a packet radio BBS or having a keyboard to keyboard chat with another human, there isn't much that the CPU needs to do except display the received data and look for keys being pressed on the keyboard. > With the modem and UART hardware doing the hard layer 1 work, the CPU should have plenty of cycles to spare to deal with the bit stuffing, encoding, CRC checks, AX25 packet structure, etc. Can the Model 100's modem/UART hardware be configured to just demodulate bits synchronously? The way the modem/UART would be used over the phone lines would be asynchronously (the "A" in "UART"), where every 7 (or 8) data bits are placed in between a start bit and a stop bit, and maybe with a parity bit at the end of the character being sent. "8N1" is really a start bit, eight data bits, no parity bit and one stop bit. These ten bits for a character are sent, then there could be a pause for a small fraction of a second and then the start bit for the next character is sent. That's "asynchronous" serial. However, AX.25 packet radio doesn't work that way. It's synchronous. AX.25 uses an HDLC flag byte (0x7E) as a "start of data frame" indicator and then a continuous stream of bits (all the data bits for the whole packet one after another) with zero bits stuffed in after five contiguous one bits and then another HDLC flag for the end of the packet. In AX.25 there are no start bits, no stop bits and no parity bits. If there is a way to tell the Model 100's modem/UART "Hey just send me straight bits for what you see, synchronously, not asynchronously" then maybe we can receive 300 baud AX.25 packet radio but if the UART is expecting start/stop/parity bits, then the modem/UART won't be able to receive 300 baud AX.25 packet on HF. You could still use the internal modem/UART to send/receive ASCII Bell 103, start/data/stop/parity, but I don't know if anyone still uses that on HF anymore. Probably, I just don't know. W1AW used to send ASCII bulletins, but they replaced ASCII and AMTOR with PSK31 and MFSK16 back in 2009. If you go this route, I would just adjust RIT and XIT on the radio so that the tones are what the modem expects for ORIG and ANSWER so that you don't need to make hardware mods to the M100. On the other hand, the cassette port data is similar to AX.25 packet in that there is a sync/header byte and there (usually) aren't start/stop/parity bits, just straight bits. (Some NECs write two stop bits after the data byte.) The challenge is that the cassette port/RIM instruction only gives you "signal is above zero" or "signal is below zero" so all you can get is above/below and the timing information on the zero crossings of the waveforms. It's not really an analog-to-digital converter except for that one bit. See Figure 3-9 "Demodulation Circuit of Cassette Interface" on page 17 of the Model 100 Technical Reference Manual. But, the
Re: [M100] Packet radio like it's 1987
Douglas, You make a very good point. I'd never even considered that the UART might get in the way. After a look over the datasheets for the chip, there doesn't seem to be any way to disable the stop bit functionality and turn it into a dumb shift register. Now I'm wondering if the old modem chip could still be utilized in a hybrid approach: Bypass the UART and read/write bits directly to the modem via the 8085's SID/SOD lines? It could be less work for the CPU this way, since the modem can deal with the waveforms and frequencies in hardware. That's another hardware mod, and still leaves the timer problem. Regarding hardware mods to the M102, the way I see it is: When am I going to use this modem on a telephone line ever? Using the RIT is a good idea though. Jeff, If you want to use the Tandy as a terminal with an external TNC like I've been doing the past week, you just hook it to the serial port with the necessary adapters and use TELCOM to type commands to the TNC. Make sure you turn on flow control or your TNC will probably outrun the old model T. So far I've used it to send Winlink email through a local VHF RMS node and made a couple of contacts on HF. On Sat, Apr 17, 2021 at 8:19 PM Douglas Quagliana wrote: > >How much of the 8085's time will be left to do anything useful at all > with the data with it essentially bit-banging the waveforms like that? > > Probably not much CPU time will be left while receiving. But packet radio > is half-duplex on HF and VHF. If you are connecting to a packet radio BBS > or having a keyboard to keyboard chat with another human, there isn't much > that the CPU needs to do except display the received data and look for keys > being pressed on the keyboard. > > > With the modem and UART hardware doing the hard layer 1 work, the CPU > should have plenty of cycles to spare to deal with the bit stuffing, > encoding, CRC checks, AX25 packet structure, etc. > > Can the Model 100's modem/UART hardware be configured to just demodulate > bits synchronously? The way the modem/UART would be used over the phone > lines would be asynchronously (the "A" in "UART"), where every 7 (or 8) > data bits are placed in between a start bit and a stop bit, and maybe with > a parity bit at the end of the character being sent. "8N1" is really a > start bit, eight data bits, no parity bit and one stop bit. These ten bits > for a character are sent, then there could be a pause for a small fraction > of a second and then the start bit for the next character is sent. That's > "asynchronous" serial. > > However, AX.25 packet radio doesn't work that way. It's synchronous. > AX.25 uses an HDLC flag byte (0x7E) as a "start of data frame" indicator > and then a continuous stream of bits (all the data bits for the whole > packet one after another) with zero bits stuffed in after five contiguous > one bits and then another HDLC flag for the end of the packet. In AX.25 > there are no start bits, no stop bits and no parity bits. If there is a > way to tell the Model 100's modem/UART "Hey just send me straight bits for > what you see, synchronously, not asynchronously" then maybe we can receive > 300 baud AX.25 packet radio but if the UART is expecting start/stop/parity > bits, then the modem/UART won't be able to receive 300 baud AX.25 packet on > HF. > > You could still use the internal modem/UART to send/receive ASCII Bell > 103, start/data/stop/parity, but I don't know if anyone still uses that on > HF anymore. Probably, I just don't know. W1AW used to send ASCII bulletins, > but they replaced ASCII and AMTOR with PSK31 and MFSK16 back in 2009. If > you go this route, I would just adjust RIT and XIT on the radio so that the > tones are what the modem expects for ORIG and ANSWER so that you don't need > to make hardware mods to the M100. > > On the other hand, the cassette port data is similar to AX.25 packet in > that there is a sync/header byte and there (usually) aren't > start/stop/parity bits, just straight bits. (Some NECs write two stop bits > after the data byte.) The challenge is that the cassette port/RIM > instruction only gives you "signal is above zero" or "signal is below zero" > so all you can get is above/below and the timing information on the zero > crossings of the waveforms. It's not really an analog-to-digital converter > except for that one bit. See Figure 3-9 "Demodulation Circuit of Cassette > Interface" on page 17 of the Model 100 Technical Reference Manual. But, > the nice part about this small circuit is that it doesn't care much what > the baud rate or the frequencies of the signals are. It just takes an > analog input waveform and outputs a square waveform to the CPU pin. All of > the cassette reading and writing is done in software in the ROM routines. > The cassette "format" that the M100 uses of 1500 baud with a mark of 2400Hz > and space of 1200Hz is entirely implemented in software timing routings > independent of any hardware. The challenge for
Re: [M100] Packet radio like it's 1987
All of what you guys are doing is really rad! I bought a bunch of old packet stuff a few years back hoping to connect it up with my m100. Never got around to it. It would be great to get some guidance on that. On Sun, Apr 18, 2021 at 9:35 AM Brad Grier wrote: > Re: 8201a docs etc -- this is a helpful site. Not sure if it has > exactly what you're looking for. > > https://www.web8201.net/default.asp?content=tech.asp > > --Brad > > On Sat, Apr 17, 2021 at 6:19 PM Douglas Quagliana > wrote: > >> >How much of the 8085's time will be left to do anything useful at all >> with the data with it essentially bit-banging the waveforms like that? >> >> Probably not much CPU time will be left while receiving. But packet >> radio is half-duplex on HF and VHF. If you are connecting to a packet >> radio BBS or having a keyboard to keyboard chat with another human, there >> isn't much that the CPU needs to do except display the received data and >> look for keys being pressed on the keyboard. >> >> > With the modem and UART hardware doing the hard layer 1 work, the CPU >> should have plenty of cycles to spare to deal with the bit stuffing, >> encoding, CRC checks, AX25 packet structure, etc. >> >> Can the Model 100's modem/UART hardware be configured to just demodulate >> bits synchronously? The way the modem/UART would be used over the phone >> lines would be asynchronously (the "A" in "UART"), where every 7 (or 8) >> data bits are placed in between a start bit and a stop bit, and maybe with >> a parity bit at the end of the character being sent. "8N1" is really a >> start bit, eight data bits, no parity bit and one stop bit. These ten bits >> for a character are sent, then there could be a pause for a small fraction >> of a second and then the start bit for the next character is sent. That's >> "asynchronous" serial. >> >> However, AX.25 packet radio doesn't work that way. It's synchronous. >> AX.25 uses an HDLC flag byte (0x7E) as a "start of data frame" indicator >> and then a continuous stream of bits (all the data bits for the whole >> packet one after another) with zero bits stuffed in after five contiguous >> one bits and then another HDLC flag for the end of the packet. In AX.25 >> there are no start bits, no stop bits and no parity bits. If there is a >> way to tell the Model 100's modem/UART "Hey just send me straight bits for >> what you see, synchronously, not asynchronously" then maybe we can receive >> 300 baud AX.25 packet radio but if the UART is expecting start/stop/parity >> bits, then the modem/UART won't be able to receive 300 baud AX.25 packet on >> HF. >> >> You could still use the internal modem/UART to send/receive ASCII Bell >> 103, start/data/stop/parity, but I don't know if anyone still uses that on >> HF anymore. Probably, I just don't know. W1AW used to send ASCII bulletins, >> but they replaced ASCII and AMTOR with PSK31 and MFSK16 back in 2009. If >> you go this route, I would just adjust RIT and XIT on the radio so that the >> tones are what the modem expects for ORIG and ANSWER so that you don't need >> to make hardware mods to the M100. >> >> On the other hand, the cassette port data is similar to AX.25 packet in >> that there is a sync/header byte and there (usually) aren't >> start/stop/parity bits, just straight bits. (Some NECs write two stop bits >> after the data byte.) The challenge is that the cassette port/RIM >> instruction only gives you "signal is above zero" or "signal is below zero" >> so all you can get is above/below and the timing information on the zero >> crossings of the waveforms. It's not really an analog-to-digital converter >> except for that one bit. See Figure 3-9 "Demodulation Circuit of Cassette >> Interface" on page 17 of the Model 100 Technical Reference Manual. But, >> the nice part about this small circuit is that it doesn't care much what >> the baud rate or the frequencies of the signals are. It just takes an >> analog input waveform and outputs a square waveform to the CPU pin. All of >> the cassette reading and writing is done in software in the ROM routines. >> The cassette "format" that the M100 uses of 1500 baud with a mark of 2400Hz >> and space of 1200Hz is entirely implemented in software timing routings >> independent of any hardware. The challenge for receiving packet radio is to >> rewrite the cassette ROM routines to change the baud rate to 1200 and the >> mark to 2200Hz. This would have to be done in 8085 assembly as BASIC just >> isn't fast enough. Note that some other laptops similar to the Model100 >> like the NEC PC-8201A/PC-8300 already use a different baud rate for >> cassette I/O. (The NEC laptops use 600 baud if I recall correctly.) "It's >> only software." >> >> Ok...I'll be going back to looking at zero crossing demodulators >> >> Does anybody have a ROM disassembly for the NEC PC-8201A/PC-8300 ? I'd >> like to see how they do the timing for their 600 baud cassette format. >> >> Regards, >> Douglas >>
Re: [M100] Packet radio like it's 1987
Re: 8201a docs etc -- this is a helpful site. Not sure if it has exactly what you're looking for. https://www.web8201.net/default.asp?content=tech.asp --Brad On Sat, Apr 17, 2021 at 6:19 PM Douglas Quagliana wrote: > >How much of the 8085's time will be left to do anything useful at all > with the data with it essentially bit-banging the waveforms like that? > > Probably not much CPU time will be left while receiving. But packet radio > is half-duplex on HF and VHF. If you are connecting to a packet radio BBS > or having a keyboard to keyboard chat with another human, there isn't much > that the CPU needs to do except display the received data and look for keys > being pressed on the keyboard. > > > With the modem and UART hardware doing the hard layer 1 work, the CPU > should have plenty of cycles to spare to deal with the bit stuffing, > encoding, CRC checks, AX25 packet structure, etc. > > Can the Model 100's modem/UART hardware be configured to just demodulate > bits synchronously? The way the modem/UART would be used over the phone > lines would be asynchronously (the "A" in "UART"), where every 7 (or 8) > data bits are placed in between a start bit and a stop bit, and maybe with > a parity bit at the end of the character being sent. "8N1" is really a > start bit, eight data bits, no parity bit and one stop bit. These ten bits > for a character are sent, then there could be a pause for a small fraction > of a second and then the start bit for the next character is sent. That's > "asynchronous" serial. > > However, AX.25 packet radio doesn't work that way. It's synchronous. > AX.25 uses an HDLC flag byte (0x7E) as a "start of data frame" indicator > and then a continuous stream of bits (all the data bits for the whole > packet one after another) with zero bits stuffed in after five contiguous > one bits and then another HDLC flag for the end of the packet. In AX.25 > there are no start bits, no stop bits and no parity bits. If there is a > way to tell the Model 100's modem/UART "Hey just send me straight bits for > what you see, synchronously, not asynchronously" then maybe we can receive > 300 baud AX.25 packet radio but if the UART is expecting start/stop/parity > bits, then the modem/UART won't be able to receive 300 baud AX.25 packet on > HF. > > You could still use the internal modem/UART to send/receive ASCII Bell > 103, start/data/stop/parity, but I don't know if anyone still uses that on > HF anymore. Probably, I just don't know. W1AW used to send ASCII bulletins, > but they replaced ASCII and AMTOR with PSK31 and MFSK16 back in 2009. If > you go this route, I would just adjust RIT and XIT on the radio so that the > tones are what the modem expects for ORIG and ANSWER so that you don't need > to make hardware mods to the M100. > > On the other hand, the cassette port data is similar to AX.25 packet in > that there is a sync/header byte and there (usually) aren't > start/stop/parity bits, just straight bits. (Some NECs write two stop bits > after the data byte.) The challenge is that the cassette port/RIM > instruction only gives you "signal is above zero" or "signal is below zero" > so all you can get is above/below and the timing information on the zero > crossings of the waveforms. It's not really an analog-to-digital converter > except for that one bit. See Figure 3-9 "Demodulation Circuit of Cassette > Interface" on page 17 of the Model 100 Technical Reference Manual. But, > the nice part about this small circuit is that it doesn't care much what > the baud rate or the frequencies of the signals are. It just takes an > analog input waveform and outputs a square waveform to the CPU pin. All of > the cassette reading and writing is done in software in the ROM routines. > The cassette "format" that the M100 uses of 1500 baud with a mark of 2400Hz > and space of 1200Hz is entirely implemented in software timing routings > independent of any hardware. The challenge for receiving packet radio is to > rewrite the cassette ROM routines to change the baud rate to 1200 and the > mark to 2200Hz. This would have to be done in 8085 assembly as BASIC just > isn't fast enough. Note that some other laptops similar to the Model100 > like the NEC PC-8201A/PC-8300 already use a different baud rate for > cassette I/O. (The NEC laptops use 600 baud if I recall correctly.) "It's > only software." > > Ok...I'll be going back to looking at zero crossing demodulators > > Does anybody have a ROM disassembly for the NEC PC-8201A/PC-8300 ? I'd > like to see how they do the timing for their 600 baud cassette format. > > Regards, > Douglas > *"The task of receiving 1200 baud AX.25 as cassette signals would be > easier if there was a timer that ran at 1200 Hz, but the uDP1990 chip can't > generate 1200 Hz. By default its timer runs 256 times per second and while > you CAN hook that in software, 256 Hz won't help when we want a 1200 Hz > timer. But I digress...(More info on the uDP1990 and the
Re: [M100] Packet radio like it's 1987
In the mid 80's the CPU utilisation was the primary reason why everybody used intelligent Packet Radio TNC's. Nowadays, there are groups of people who use AtMega368 chips to do that function. Small, cheap, easy to source. http://www.mobilinkd.com/2014/09/11/arduino-kiss-tnc/ Kindest regards, Doug Jackson em: d...@doughq.com ph: 0414 986878 Check out my awesome clocks at www.dougswordclocks.com Follow my amateur radio adventures at vk1zdj.net --- Just like an old fashioned letter, this email and any files transmitted with it should probably be treated as confidential and intended solely for your own use. Please note that any interesting spelling is usually my own and may have been caused by fat thumbs on a tiny tiny keyboard. Should any part of this message prove to be useful in the event of the imminent Zombie Apocalypse then the sender bears no personal, legal, or moral responsibility for any outcome resulting from its usage unless the result of said usage is the unlikely defeat of the Zombie Hordes in which case the sender takes full credit without any theoretical or actual legal liability. :-) Be nice to your parents. Go outside and do something awesome - Draw, paint, walk, setup a radio station, go fishing or sailing - just do something that makes you happy. ^G ^G ^G ^G ^G ^G ^G ^G- In more laid back days this line would literally sing ^G ^G ^G ^G ^G ^G ^G ^G On Sun, 18 Apr 2021 at 10:19, Douglas Quagliana wrote: > >How much of the 8085's time will be left to do anything useful at all > with the data with it essentially bit-banging the waveforms like that? > > Probably not much CPU time will be left while receiving. But packet radio > is half-duplex on HF and VHF. If you are connecting to a packet radio BBS > or having a keyboard to keyboard chat with another human, there isn't much > that the CPU needs to do except display the received data and look for keys > being pressed on the keyboard. > > > With the modem and UART hardware doing the hard layer 1 work, the CPU > should have plenty of cycles to spare to deal with the bit stuffing, > encoding, CRC checks, AX25 packet structure, etc. > > Can the Model 100's modem/UART hardware be configured to just demodulate > bits synchronously? The way the modem/UART would be used over the phone > lines would be asynchronously (the "A" in "UART"), where every 7 (or 8) > data bits are placed in between a start bit and a stop bit, and maybe with > a parity bit at the end of the character being sent. "8N1" is really a > start bit, eight data bits, no parity bit and one stop bit. These ten bits > for a character are sent, then there could be a pause for a small fraction > of a second and then the start bit for the next character is sent. That's > "asynchronous" serial. > > However, AX.25 packet radio doesn't work that way. It's synchronous. > AX.25 uses an HDLC flag byte (0x7E) as a "start of data frame" indicator > and then a continuous stream of bits (all the data bits for the whole > packet one after another) with zero bits stuffed in after five contiguous > one bits and then another HDLC flag for the end of the packet. In AX.25 > there are no start bits, no stop bits and no parity bits. If there is a > way to tell the Model 100's modem/UART "Hey just send me straight bits for > what you see, synchronously, not asynchronously" then maybe we can receive > 300 baud AX.25 packet radio but if the UART is expecting start/stop/parity > bits, then the modem/UART won't be able to receive 300 baud AX.25 packet on > HF. > > You could still use the internal modem/UART to send/receive ASCII Bell > 103, start/data/stop/parity, but I don't know if anyone still uses that on > HF anymore. Probably, I just don't know. W1AW used to send ASCII bulletins, > but they replaced ASCII and AMTOR with PSK31 and MFSK16 back in 2009. If > you go this route, I would just adjust RIT and XIT on the radio so that the > tones are what the modem expects for ORIG and ANSWER so that you don't need > to make hardware mods to the M100. > > On the other hand, the cassette port data is similar to AX.25 packet in > that there is a sync/header byte and there (usually) aren't > start/stop/parity bits, just straight bits. (Some NECs write two stop bits > after the data byte.) The challenge is that the cassette port/RIM > instruction only gives you "signal is above zero" or "signal is below zero" > so all you can get is above/below and the timing information on the zero > crossings of the waveforms. It's not really an analog-to-digital converter > except for that one bit. See Figure 3-9 "Demodulation Circuit of Cassette > Interface" on page 17 of the Model 100 Technical Reference Manual. But, > the nice part about this small circuit is that it doesn't care much what > the baud rate or the frequencies of the signals are. It just takes an > analog input waveform and outputs a square waveform to the CPU pin. All of > the
Re: [M100] Packet radio like it's 1987
>How much of the 8085's time will be left to do anything useful at all with the data with it essentially bit-banging the waveforms like that? Probably not much CPU time will be left while receiving. But packet radio is half-duplex on HF and VHF. If you are connecting to a packet radio BBS or having a keyboard to keyboard chat with another human, there isn't much that the CPU needs to do except display the received data and look for keys being pressed on the keyboard. > With the modem and UART hardware doing the hard layer 1 work, the CPU should have plenty of cycles to spare to deal with the bit stuffing, encoding, CRC checks, AX25 packet structure, etc. Can the Model 100's modem/UART hardware be configured to just demodulate bits synchronously? The way the modem/UART would be used over the phone lines would be asynchronously (the "A" in "UART"), where every 7 (or 8) data bits are placed in between a start bit and a stop bit, and maybe with a parity bit at the end of the character being sent. "8N1" is really a start bit, eight data bits, no parity bit and one stop bit. These ten bits for a character are sent, then there could be a pause for a small fraction of a second and then the start bit for the next character is sent. That's "asynchronous" serial. However, AX.25 packet radio doesn't work that way. It's synchronous. AX.25 uses an HDLC flag byte (0x7E) as a "start of data frame" indicator and then a continuous stream of bits (all the data bits for the whole packet one after another) with zero bits stuffed in after five contiguous one bits and then another HDLC flag for the end of the packet. In AX.25 there are no start bits, no stop bits and no parity bits. If there is a way to tell the Model 100's modem/UART "Hey just send me straight bits for what you see, synchronously, not asynchronously" then maybe we can receive 300 baud AX.25 packet radio but if the UART is expecting start/stop/parity bits, then the modem/UART won't be able to receive 300 baud AX.25 packet on HF. You could still use the internal modem/UART to send/receive ASCII Bell 103, start/data/stop/parity, but I don't know if anyone still uses that on HF anymore. Probably, I just don't know. W1AW used to send ASCII bulletins, but they replaced ASCII and AMTOR with PSK31 and MFSK16 back in 2009. If you go this route, I would just adjust RIT and XIT on the radio so that the tones are what the modem expects for ORIG and ANSWER so that you don't need to make hardware mods to the M100. On the other hand, the cassette port data is similar to AX.25 packet in that there is a sync/header byte and there (usually) aren't start/stop/parity bits, just straight bits. (Some NECs write two stop bits after the data byte.) The challenge is that the cassette port/RIM instruction only gives you "signal is above zero" or "signal is below zero" so all you can get is above/below and the timing information on the zero crossings of the waveforms. It's not really an analog-to-digital converter except for that one bit. See Figure 3-9 "Demodulation Circuit of Cassette Interface" on page 17 of the Model 100 Technical Reference Manual. But, the nice part about this small circuit is that it doesn't care much what the baud rate or the frequencies of the signals are. It just takes an analog input waveform and outputs a square waveform to the CPU pin. All of the cassette reading and writing is done in software in the ROM routines. The cassette "format" that the M100 uses of 1500 baud with a mark of 2400Hz and space of 1200Hz is entirely implemented in software timing routings independent of any hardware. The challenge for receiving packet radio is to rewrite the cassette ROM routines to change the baud rate to 1200 and the mark to 2200Hz. This would have to be done in 8085 assembly as BASIC just isn't fast enough. Note that some other laptops similar to the Model100 like the NEC PC-8201A/PC-8300 already use a different baud rate for cassette I/O. (The NEC laptops use 600 baud if I recall correctly.) "It's only software." Ok...I'll be going back to looking at zero crossing demodulators Does anybody have a ROM disassembly for the NEC PC-8201A/PC-8300 ? I'd like to see how they do the timing for their 600 baud cassette format. Regards, Douglas *"The task of receiving 1200 baud AX.25 as cassette signals would be easier if there was a timer that ran at 1200 Hz, but the uDP1990 chip can't generate 1200 Hz. By default its timer runs 256 times per second and while you CAN hook that in software, 256 Hz won't help when we want a 1200 Hz timer. But I digress...(More info on the uDP1990 and the 256 Hz interrupt that you can hook see https://ftp.whtech.com/club100/ref/watchdog.doc and note that this file ends in ".DOC" but it is a text file not a Microsoft Word document.)
Re: [M100] Packet radio like it's 1987
How much of the 8085's time will be left to do anything useful at all with the data with it essentially bit-banging the waveforms like that? On HF, packet radio is 300 baud using Bell 103 tones already. I've done some reading over the schematics and it looks like the onboard modem can be put into a test mode (pin 2 high) where it uses the same tone pair for RX and TX. The analog filters can be similarly aligned by lifting one trace from the ANS/ORG switch. The frequencies of the tones themselves aren't a problem since you can just offset the tuning on your SSB transceiver to compensate. With the modem and UART hardware doing the hard layer 1 work, the CPU should have plenty of cycles to spare to deal with the bit stuffing, encoding, CRC checks, AX25 packet structure, etc. That and it would just be cool to have a cable going out the modem jack straight to a transceiver and log on to some BBS on battery power. On Fri, Apr 16, 2021 at 1:06 AM Douglas Quagliana wrote: > All, > >I haven't tried the Bell 103 modem, but the cassette port is (in > theory) fast enough to see 1200 baud AFSK. The cassette port is supposed to > run at 1500 baud. To receive AX.25 packet you would need to count the time > between zero crossing similar to the way the cassette port does it now, and > figure out if the current bit was a mark or space, then shift the bits into > memory as they are received. Upon receiving the trailing HDLC flag you > would need to undo the zero bit stuffing, undo the NRZI encoding, and check > the CRC. The problem is that Bell212 (1200 baud packet radio) shifts AFSK > tones when one bit time has elapsed (1/1200th of a second) and that doesn't > exactly match up with the zero crossings for the 2200Hz tone, so you get a > whole 1200Hz tone starting at whatever phase the waveform was then at, but > more than one 2200Hz tone per bit and the waves are contiguous so the next > one just starts where the previous one ends. It doesn't start the phase > over at zero for the next bit. > >The M100 ROM has code for reading the cassette input pin at 6FDBH and > it will watch the cassette port input pin connected to the 8085 SID on pin > 5 with the RIM instruction, and then return the number of t-states until > the wave will end. This would have to be rewritten to take into account > the different frequencies for packet radio versus what the cassette > frequencies are. For details on the routine at 6FDBH see > https://ftp.whtech.com/club100/ref/rcmap6.100 and go down to 6FDBH. > >I've already written code for AX25 for PCs that will undo the zero bit > stuffing, NRZI and CRC, but didn't get to the bit detection on a M100. I > did get as far as a "read the frequency on the cassette port" but not for > 1200 baud bits. I think it would be neat to receive and perhaps send > packet radio on the cassette port without a TNC. This has been on my bucket > list for a long time to see if it could even be done. If you're interested > or if you know more about the cassette port routines, then please let me > know. > > Douglas > > > On Wed, Apr 14, 2021 at 10:54 AM Alex ... > wrote: > >> Figure this would be a fun one to share with the [M100] list. :) >> >> I recently bought a big box of random ham radio packet gear which >> included a bunch of old TNC modems and assorted cables. Unfortunately, it >> turns out the quad serial port card in my desktop PC is dead. >> >> Enter the Tandy 102 to the rescue! I was able to test all 4 of the TNCs >> on the air and sent a test email from the T through a local Winlink RMS >> node. >> >> This whole exercise got me wondering if the built-in Bell 103 modem could >> be adapted for HF packet radio use. Has anybody tried that yet? >> >> Pictured in the attached photo is the Tandy 102 hooked to a MFJ 1274 >> modem, monitoring Network 105 traffic on 7104khz. >> >> -Alex >> > -- Disclaimer: Any resemblance between the above views and those of my employer, my terminal, or the view out my window are purely coincidental. Any resemblance between the above and my own views is non-deterministic. The question of the existence of views in the absence of anyone to hold them is left as an exercise for the reader. The question of the existence of the reader is left as an exercise for the second god coefficient. (A discussion of non-orthogonal, non-integral polytheism is beyond the scope of this article.) Thanks /usr/games/fortune
Re: [M100] Packet radio like it's 1987
All, I haven't tried the Bell 103 modem, but the cassette port is (in theory) fast enough to see 1200 baud AFSK. The cassette port is supposed to run at 1500 baud. To receive AX.25 packet you would need to count the time between zero crossing similar to the way the cassette port does it now, and figure out if the current bit was a mark or space, then shift the bits into memory as they are received. Upon receiving the trailing HDLC flag you would need to undo the zero bit stuffing, undo the NRZI encoding, and check the CRC. The problem is that Bell212 (1200 baud packet radio) shifts AFSK tones when one bit time has elapsed (1/1200th of a second) and that doesn't exactly match up with the zero crossings for the 2200Hz tone, so you get a whole 1200Hz tone starting at whatever phase the waveform was then at, but more than one 2200Hz tone per bit and the waves are contiguous so the next one just starts where the previous one ends. It doesn't start the phase over at zero for the next bit. The M100 ROM has code for reading the cassette input pin at 6FDBH and it will watch the cassette port input pin connected to the 8085 SID on pin 5 with the RIM instruction, and then return the number of t-states until the wave will end. This would have to be rewritten to take into account the different frequencies for packet radio versus what the cassette frequencies are. For details on the routine at 6FDBH see https://ftp.whtech.com/club100/ref/rcmap6.100 and go down to 6FDBH. I've already written code for AX25 for PCs that will undo the zero bit stuffing, NRZI and CRC, but didn't get to the bit detection on a M100. I did get as far as a "read the frequency on the cassette port" but not for 1200 baud bits. I think it would be neat to receive and perhaps send packet radio on the cassette port without a TNC. This has been on my bucket list for a long time to see if it could even be done. If you're interested or if you know more about the cassette port routines, then please let me know. Douglas On Wed, Apr 14, 2021 at 10:54 AM Alex ... wrote: > Figure this would be a fun one to share with the [M100] list. :) > > I recently bought a big box of random ham radio packet gear which included > a bunch of old TNC modems and assorted cables. Unfortunately, it turns out > the quad serial port card in my desktop PC is dead. > > Enter the Tandy 102 to the rescue! I was able to test all 4 of the TNCs on > the air and sent a test email from the T through a local Winlink RMS node. > > This whole exercise got me wondering if the built-in Bell 103 modem could > be adapted for HF packet radio use. Has anybody tried that yet? > > Pictured in the attached photo is the Tandy 102 hooked to a MFJ 1274 > modem, monitoring Network 105 traffic on 7104khz. > > -Alex >
Re: [M100] Packet radio like it's 1987
On 15/4/21 7:39 pm, Doug Jackson wrote: From memory the SCC could help out with the encoding which was something like HDLC or SDLC.. that's rattling my brain cells though. That's right, the ZSCC handles H/SDLC natively. I'd used it on a prior work project that required that, so was intimate at the time with how to set up the SCC to work, and had some spare AM7910 modem chips as well. In essence, it would be the TNC. It is one of those projects I'd love to revisit if I ever get enough Round Tuits (although my understanding is that packet radio these days, in that format, is dead in these parts). PS, I'm still licensed, I just haven't keyed a transmitter in a lng time. Cheers, --dt
Re: [M100] Packet radio like it's 1987
>From memory the SCC could help out with the encoding which was something like HDLC or SDLC.. that's rattling my brain cells though. I remember that the Tnc2 had a state machine to do that. Doug On Thu, 15 Apr 2021, 8:05 pm Alex ..., wrote: > What would the Zilog SCC have gotten you? A couple extra serial ports for > additional modems? > > On Wed, Apr 14, 2021, 23:41 Daryl Tester < > dt-m...@handcraftedcomputers.com.au> wrote: > >> On 15/4/21 1:23 am, Alex ... wrote: >> >> > Figure this would be a fun one to share with the [M100] list. :) >> >> Sometime last century (if not millenium) I attempted to build an add on >> card >> for my M102 to run a Zilog SCC chip for the purposes of packet radio. I >> only >> remembered this because I came across the board a year or so ago when >> cleaning >> up a little used junk box. Alas, my lack of ability back then stymied me >> (I >> mean, I have a lack of ability now, but I make up for that in >> stubbornness - >> channeling the Dunning-Kruger). >> >> Cheers, >>--dt >> >
Re: [M100] Packet radio like it's 1987
What would the Zilog SCC have gotten you? A couple extra serial ports for additional modems? On Wed, Apr 14, 2021, 23:41 Daryl Tester < dt-m...@handcraftedcomputers.com.au> wrote: > On 15/4/21 1:23 am, Alex ... wrote: > > > Figure this would be a fun one to share with the [M100] list. :) > > Sometime last century (if not millenium) I attempted to build an add on > card > for my M102 to run a Zilog SCC chip for the purposes of packet radio. I > only > remembered this because I came across the board a year or so ago when > cleaning > up a little used junk box. Alas, my lack of ability back then stymied me > (I > mean, I have a lack of ability now, but I make up for that in stubbornness > - > channeling the Dunning-Kruger). > > Cheers, >--dt >
Re: [M100] Packet radio like it's 1987
On 15/4/21 1:23 am, Alex ... wrote: Figure this would be a fun one to share with the [M100] list. :) Sometime last century (if not millenium) I attempted to build an add on card for my M102 to run a Zilog SCC chip for the purposes of packet radio. I only remembered this because I came across the board a year or so ago when cleaning up a little used junk box. Alas, my lack of ability back then stymied me (I mean, I have a lack of ability now, but I make up for that in stubbornness - channeling the Dunning-Kruger). Cheers, --dt
