3.58MHz RS-232 baud tables for nanoPEB?

[ckoba]

Hello,

 

I've received my nanoPEB from StarGames, and it appears to work fine. As I've never had a TI with a floppy drive (emulated or otherwise), I'm having fun trying to understand how it works.

 

I've overclocked my TI from 3MHz to 3.58MHz with the crystal swap hack. After performing that modification, I discovered that none of my "cassette tapes" (actually wav files) would load until I adjusted my bin-to-wav script to use 1600/800Hz for logic 0 and 1 respectively.

 

From what I've been able to understand, RS-232 will have similar issues, and I need to modify bytes in the nanoPEB EEPROM to do the needful.

 

To that end, I've read out the 29F010 with an EPROM burner and see what I think is the RS232 DSR at offset 0x4000:

00004000  aa 01 00 00 40 10 00 00  40 16 00 00 40 6c 00 00  |....@...@...@l..|
00004010  00 00 40 f2 00 00 40 20  41 64 05 52 53 32 33 32  |..@...@ Ad.RS232|
00004020  40 2c 41 64 07 52 53 32  33 32 2f 31 40 38 41 6a  |@,Ad.RS232/1@8Aj|
00004030  07 52 53 32 33 32 2f 32  40 40 41 54 03 50 49 4f  |.RS232/2@@AT.PIO|
00004040  40 4a 41 54 05 50 49 4f  2f 31 40 54 41 5a 05 50  |@JAT.PIO/1@TAZ.P|
00004050  49 4f 2f 32 40 60 41 76  07 52 53 32 33 32 2f 33  |IO/2@`Av.RS232/3|
00004060  00 00 41 70 07 52 53 32  33 32 2f 34 00 00 40 d2  |..Ap.RS232/4..@.|
00004070  00 00 08 00 03 03 45 43  45 00 43 52 45 06 4c 46  |......ECE.CRE.LF|
00004080  45 0c 4e 55 45 12 44 41  45 5e 42 41 45 24 50 41  |E.NUE.DAE^BAE$PA|

... so the question is, which bytes do I change and how are they calculated from console speed and desired baud rate?

 

Thanks in advance for any advice,

 

-- Chris

[Stuart]

The nanoPEB RS-232 DSR may well be based on that in the TI card - a disassembly of which is available here: [http://www.unige.ch/medecine/nouspikel/ti99/rs1.txt]. I'd start working through both and you should be able to find the baud rate table and the data to load into the TMS9902 - this starts at label A40A6 in the listing. Once you've found that in the nanoPEB, you can recalculate the 9902 data needed for a different console clock rate using the information on this page: [http://www.unige.ch/medecine/nouspikel/ti99/rs232c.htm#Operating9902].

 

Stuart.

Edited April 22, 2015 by Stuart

[atrax27407]

Ther easiest way to find the baudrate table is to dump the code and do a hex search for >85AA849C8271 (110,300 etc.) to find the start of the baudrate table ( for a >0030 3.0 mHz crystal). If you have an overclocked system, you will also have to replace the hard-coded clock rate in the EVEN console ROM (a TMS2532) with the appropriate value for your crystal (>0038) for 3.58 Mhz).

[atrax27407]

Quick calculation for the baudrate table FOR A 3.58 MhZ crystal(from Thierry Nouspikel some years ago):

 

110 >02AB

300 >04E9

600 >82EA

1200 >8175

2400 >00F9

4800 >805D

9600 >003E

19.2K >001F

38.4K >0010

57.6K >8008

[+mizapf]

Some time ago I collected the rate register values for the 9902 here:

 

http://www.ninerpedia.org/index.php/Technical_details#Determine_rate_register_values_for_TMS9902

[Stuart]

Some time ago I collected the rate register values for the 9902 here:

 

http://www.ninerpedia.org/index.php/Technical_details#Determine_rate_register_values_for_TMS9902

 

I remember seeing that nearer the time Michael, and couldn't actually seem to get the values in the diagram to agree with the values from other sources. For example, for 1200 Baud, the RS-232 DSR gives a value of >015B, as does the TIBUG listing for my TM990 board. But looking at all combinations of clock divider and multiplier in that diagram, none of them seem to have a value reasonably close to that?

Edited April 22, 2015 by Stuart

[Omega-TI]

Interesting, using this TI'ers could setup a network not likely to ever be usable or detectable to users of other systems classic or modern.

[+mizapf]

 

I remember seeing that nearer the time Michael, and couldn't actually seem to get the values in the diagram to agree with the values from other sources. For example, for 1200 Baud, the RS-232 DSR gives a value of >015B, as does the TIBUG listing for my TM990 board. But looking at all combinations of clock divider and multiplier in that diagram, none of them seem to have a value reasonably close to that?

 

I got these values delivered inside the emulation ... but I just found out how they relate to each other . Have a look at http://www.unige.ch/medecine/nouspikel/ti99/rs232c.htm

 

Halfway through the document at that page (search for "Frequency calculation") you can find your values on the left, and the values that I collected on the right. Note that the values in my illustration lack the RDV8 bit.

[Tursi]

Interesting, using this TI'ers could setup a network not likely to ever be usable or detectable to users of other systems classic or modern.

 

Well, the modem needs to understand you, and if it does, it will then convert the data to a standard rate.

 

For the raw serial data, extracting the bitrate from a sample of the data is pretty easy.

[Omega-TI]

Thanks for the explanation Tursi. I figured the average person connecting to a modem they could not sync with would give up and move on, never knowing what was at the other ends. From what you say, it's a piece of cake to figure it out. So much for that method of gate keeping.

[Tursi]

Nah, modems above 600 bps use well-defined and increasingly complicated algorithms to communicate on the phone line - they can't do arbitrary bitrates.

 

600 bps and under are usually just tones on the line, but again, you could easily take a short sample of the data, measure the distance between the bits, and work out the bitrate.

[Tursi]

(For the sake of OT curiousity - a modem handshake)

 

[Stuart]

 

I got these values delivered inside the emulation ... but I just found out how they relate to each other . Have a look at http://www.unige.ch/medecine/nouspikel/ti99/rs232c.htm

 

Halfway through the document at that page (search for "Frequency calculation") you can find your values on the left, and the values that I collected on the right. Note that the values in my illustration lack the RDV8 bit.

Ah, you're absolutely right. I've been looking at the values for the 2.5 MHz processor. <blush>

[ckoba]

The nanoPEB is indeed based on the TI board; the EPROM dump matches Thierry's disassembly, and plugging the table that atrax27407 graciously provided into the 3.0MHz table appears to be straightforward enough. Thanks for all the assistance, folks.

 

One more question: atrax27407 further indicated that I'd need to replace a single byte in the console ROM to reflect the use of a faster crystal. Is that required? I couldn't find any reference to a magic number in the disassembly, and for logistical reasons (internal 16-bit 32k upgrade) it's going to be a PITA to remove the ROMs. I'll do it if I have to (and fabricate a plug-in board for EPROM/RAM expansion while I'm at it), but is it truly necessary?

 

The reason I'm asking -- it seems to me that the console will assume that it's running at 3MHz, even though it's at 3.58, and use the 3MHz clock multiplier with the altered table to calculate the timings for the baud rates. Changing the table will change the baud rates as calculated with a 3MHz multiplier. Changing the 3MHz multiplier to reflect a faster system clock shouldn't require changing the table.

 

Or am I missing something basic here?

 

Thanks again, all ...

Edited April 24, 2015 by ckoba

[atrax27407]

Remember, There are more baudrates that I supplied than there are in the baudrate table. You will have to "sacrifice" some of the slower rates to add the faster ones. I would burn a new EVEN console ROM with the new clock speed. The TI indexes its activitiews off that rate and some of the higher baudrates might not work properly otherwise.

[ckoba]

According to Thierry at http://www.unige.ch/medecine/nouspikel/ti99/eeproms.htm#RS232%20card, it's not necessary to patch the console ROM *if* (and this is a BIG *if*) the RS232 bits of the EEPROM at >4000 are replaced with the contents of rs_2.bin as contained in http://www.unige.ch/medecine/nouspikel/ti99/rs232.zip.

 

Reading the patch comments at http://www.unige.ch/medecine/nouspikel/ti99/rspatch.txt it appears that it uses a counter/interrupt scheme to calculate the console speed, and eliminates the 2.5MHz tables in favor of a fuller baud range. This was exactly what I was looking for; thanks, everyone, for the pointers.

 

I don't have a spare 29F010 on hand at the moment, and I'm reluctant to zap the one in the nanoPEB on general paranoia principles, so I'll need to obtain one the next time I'm in town. I'll report back with results when I have them.

 

Thanks again ...

Edited April 25, 2015 by ckoba