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 <b...@bradgrier.com> 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 <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.) >> >> > > -- > -- > Brad Grier > > >
