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 <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 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.) > >
