• Please review our updated Terms and Rules here

Doesn't anyone else want to BBS with their PET?

VERAULT said:
Ral-clan my pet has white phosphor!! Not green!

Secondly your absolutely right. I want to BBS with my PET. That's why I bought a wifi modem (for use with all my other retro hardware to) but if all you want is a CBM machine to have access buy this : https://www.cbmstuff.com/proddetail.php?prod=WiModemOLED

I bought his standard serial version and am making a user port to serial rs232 adapter cable

Edit:
I am making this cable in an attempt to try connecting my PET: http://biosrhythm.com/?p=1136
Click to expand...

so I built the adapter. Works great on the C64 shame it wont work on the PET. Still havent found any information to get my " The NET Works" serial device configured for the PET.
 
How far have people got with MCTERM?

I have just been having a look at the requirements for the cable - and it can't be that difficult...

The MCTERM documentation states that the general pins used on the RS232 connector are 2, 3, 7 and 8. 2 is Transmit Data, 3 is Receive Data, 7 is Ground and 8 is Carrier Detect.

Pins 1, 12, A and N on the USER PORT connector are GND - so should be connected to pin 7 of the RS232 connector.

You DEFINITELY need an RS232 level converter. You can get these as packaged units - but they do require a separate power supply. This is why the 'proper' RS232 level version of the MCTERM cable required a power supply connection to the PET.

Previous work seems to have identified pin H as transmit. This should be connected to the RS232 connector pin 2 (via the RS232 level converter).

The RS232 level converters resolves the issue regarding the signal inversion that was seen...

The only problem is to now identify Receive Data and Carrier Detect on the user port.

Previous work may have identified PINS B and F as being related to receive. I would like to bet that pin B is Receive Data and pin F is Carrier Detect.

I suspect that the problem the previous work had with the receive side is the presence of the Carrier Detect signal. This is generally inactive when the modem is not connected to the line - but becomes active when the carrier frequency is picked up by the modem (indicating the presence of data). If the MCTERM software is configured to look for the presence of Carrier Detect BEFORE permitting received data to be detected - this may account for the problems. It may also account for why sometimes it may have 'falsely' detected some data if the signal had been connected to receive data.

I usually 'strap' Carrier Detect to permanently enable it.

The MCTERM manual also tantalisingly indicates that other RS232 handshake signals may also be present on the user interface connector (e.g. pins 4, 5, 6, 9 and 20 on the RS232 connector).

I would usually strap 4-5 and 6-8-20 (4 being Request To Send. 5 being Clear To Send. 6 being Data Set Ready. 8 being Data Carrier Detect. 20 being Data Terminal Ready).

Why 9 is mentioned in the MCTERM manual I don't know? Pin 9 can be a source of positive voltage.

Pin 1 is classed as Ground in the MCTERM manual. It shouldn't be - it is for the cable shield.

Does anyone want me to look further into this?

Dave
 
Last edited:
daver2 said:
How far have people got with MCTERM?

I have just been having a look at the requirements for the cable - and it can't be that difficult...

The MCTERM documentation states that the general pins used on the RS232 connector are 2, 3, 7 and 8. 2 is Transmit Data, 3 is Receive Data, 7 is Ground and 8 is Carrier Detect.

Pins 1, 12, A and N on the USER PORT connector are GND - so should be connected to pin 7 of the RS232 connector.

You DEFINITELY need an RS232 level converter. You can get these as packaged units - but they do require a separate power supply. This is why the 'proper' RS232 level version of the MCTERM cable required a power supply connection to the PET.

Previous work seems to have identified pin H as transmit. This should be connected to the RS232 connector pin 2 (via the RS232 level converter).

The RS232 level converters resolves the issue regarding the signal inversion that was seen...

The only problem is to now identify Receive Data and Carrier Detect on the user port.

Previous work may have identified PINS B and F as being related to receive. I would like to bet that pin B is Receive Data and pin F is Carrier Detect.

I suspect that the problem the previous work had with the receive side is the presence of the Carrier Detect signal. This is generally inactive when the modem is not connected to the line - but becomes active when the carrier frequency is picked up by the modem (indicating the presence of data). If the MCTERM software is configured to look for the presence of Carrier Detect BEFORE permitting received data to be detected - this may account for the problems. It may also account for why sometimes it may have 'falsely' detected some data if the signal had been connected to receive data.

I usually 'strap' Carrier Detect to permanently enable it.

The MCTERM manual also tantalisingly indicates that other RS232 handshake signals may also be present on the user interface connector (e.g. pins 4, 5, 6, 9 and 20 on the RS232 connector).

I would usually strap 4-5 and 6-8-20 (4 being Request To Send. 5 being Clear To Send. 6 being Data Set Ready. 8 being Data Carrier Detect. 20 being Data Terminal Ready).

Why 9 is mentioned in the MCTERM manual I don't know? Pin 9 can be a source of positive voltage.

Pin 1 is classed as Ground in the MCTERM manual. It shouldn't be - it is for the cable shield.

Does anyone want me to look further into this?

Dave
Click to expand...

Dave, I absolutely would like you to look further into this as I am at a standstill with my PET as far as serial communication.
 
I'll have a look tomorrow a bit more.

Have you got the MCTERM software and ROM on your PET?

Unfortunately, my 8032 is in 'dry dock' at the moment awaiting repair...

Dave
 
daver2 said:
I'll have a look tomorrow a bit more.

Have you got the MCTERM software and ROM on your PET?

Unfortunately, my 8032 is in 'dry dock' at the moment awaiting repair...

Dave
Click to expand...

Dave, is MCterm just a disk image because I dont have it. I have a pet 2001-8 with the cpu/rom upgrade from Tynemouth software. What other ROM would I need?
 
No.

MCTERM is a ROM (that fits into UD12 at address $9000) in an 8000 series machine AND a disk/cassette program. The ROM image and disk program can be found at https://cbm8bit.com/8bit/commodore/disk-image/0835a42444509eb9e585f6d400397c0f (ROM image = MCTERM [ROM]; disk program = MCTERM).

The manual can be found at http://mikenaberezny.com/wp-content/uploads/2015/07/mcterm-manual.pdf (thanks Mike)...

A bespoke cable is required to connect the USER PORT of the PET to the RS232 serial device. That is the subject of the current work.

An alternative is a cable/software presented in TRANSACTOR Volume 3 issue 06. This is not as comprehensive as MCTERM and will only run at 300 BAUD. This software is more limiting than MCTERM.

The current state of the interfaces (as far as I can tell) is detailed at http://biosrhythm.com/?p=1359.

The question is - what are you trying to achieve?

Dave
 
OK.

I haven't been able to find any documentation (yet) for this device - but only been looking for 10 minutes...

First off - the two UARTS (TR1602-B) are made by Western Digital and the data sheet can be found here http://ae6pm.com/Semidata_sheets/TR1602B.pdf.

From the data sheet I can see pin 35 is the Parity Inhibit; pin 36 selects the number of stop bits; pins 37 and 38 select the number of data bits; pin 39 enables even parity and pins 17 and 40 are the RX and TX clocks respectively.

By inspection (or the use of a multimeter set to Ohms) it should be now possible to work out the serial port configuration links by tracing the wiring from pins 35-39 of each UART to the configuration blocks.

I see there is a crystal on the board. The crystal will be connected to an oscillator circuit and this (in turn) will be connected to 1 or 2 BAUD RATE GENERATOR ICs. These will be connected to the jumper blocks for the BAUD rate selection for each UART (and hence to pins 17 and 40 of the UARTS). Again, by identifying the data sheets and tracing out the circuitry it should be possible to identify what BAUD RATE is associated with each link.

The IEEE 488 address we should be able to work out by trial and error...

You will need a Commodore PET to IEEE 488 cable and a terminator.

Can you get some further close-up pictures of each device on the board for me? I should then be able to identify the BAUD RATE GENERATOR(s) and RS232 buffers for you. Tracing the transmit and receive data to/from the UART devices will be the best way of identifying the RS232 buffers.

It's getting late in the UK so I will pick this up again tomorrow.

Regards,

Dave
 
as I come in from a sad day of sawing wood... that joke fell pretty flat Chuck.. Im gonna go shower and hope I didnt get poison IVY in my nethers........
 
daver2 said:
OK.

I haven't been able to find any documentation (yet) for this device - but only been looking for 10 minutes...

First off - the two UARTS (TR1602-B) are made by Western Digital and the data sheet can be found here http://ae6pm.com/Semidata_sheets/TR1602B.pdf.

From the data sheet I can see pin 35 is the Parity Inhibit; pin 36 selects the number of stop bits; pins 37 and 38 select the number of data bits; pin 39 enables even parity and pins 17 and 40 are the RX and TX clocks respectively.

By inspection (or the use of a multimeter set to Ohms) it should be now possible to work out the serial port configuration links by tracing the wiring from pins 35-39 of each UART to the configuration blocks.

I see there is a crystal on the board. The crystal will be connected to an oscillator circuit and this (in turn) will be connected to 1 or 2 BAUD RATE GENERATOR ICs. These will be connected to the jumper blocks for the BAUD rate selection for each UART (and hence to pins 17 and 40 of the UARTS). Again, by identifying the data sheets and tracing out the circuitry it should be possible to identify what BAUD RATE is associated with each link.

The IEEE 488 address we should be able to work out by trial and error...

You will need a Commodore PET to IEEE 488 cable and a terminator.

Can you get some further close-up pictures of each device on the board for me? I should then be able to identify the BAUD RATE GENERATOR(s) and RS232 buffers for you. Tracing the transmit and receive data to/from the UART devices will be the best way of identifying the RS232 buffers.

It's getting late in the UK so I will pick this up again tomorrow.

Regards,

Dave
Click to expand...

Dave I will get you some photos soon, but I am tired as well from working outside today.
One thing you mentioned. I have the ieee 488 cables, but I dont have a terminator. I never heard of that with IEEE 4888. My pet communicated with my SFD-1001 without a terminator, can you explain how its used?
 
I don't recall the schematics, but likely your PET and SFD did not work without termination. They likely have it built in.

HPIB might be able to get by without bus termination, in a pinch.
 
So its like Scsi? IS there an actual physical terminator I need to get or is this configured per device? Im curious.,
 
Yes, but it's not just SCSI. Any data bus technically requires termination. Sometimes you can get by without it, especially at low speeds.

Thinking about how the connectors work for HPIB, there probably isn't any termination. So the speed must just be low enough that we all get by without it. But again I'd have to see schematics or maybe a specification for the bus to know for certain.
 
Ignore the bit about termination - I was working too late last night obviously!

The IEE 488 bus does not require a terminator (it is operating at relatively slow speeds).

Unable to find any documentation myself today on your TNW488/232 - so we will have to reverse engineer the functionality.

No problem regarding the photographs - when you are ready. I have plenty to do at home myself...

Dave
 
daver2 said:
Ignore the bit about termination - I was working too late last night obviously!

The IEE 488 bus does not require a terminator (it is operating at relatively slow speeds).

Unable to find any documentation myself today on your TNW488/232 - so we will have to reverse engineer the functionality.

No problem regarding the photographs - when you are ready. I have plenty to do at home myself...

Dave
Click to expand...

Dave I added some close up photos of the board and zoned them as to help (and hopefully not confuse) http://s613.photobucket.com/user/Verault/library/TNW488 232/Close up rs-232 device
if any images are blurry or you need a better photo just let me know.
 
I'm responding to this thread because I was recently BBSing with my VIC-20 on Cottonwood BBS, when I read a post from a new user there who said he was online with his PET 3032! I was suprised, because as you can see by this thread, no one had figured out how to get online with a PET. The only clue he left was that he was using a "simulant wifi modem" which I presume is this one: https://www.simulant.uk/blog/wifi-for-old-computers-with-a-serial-port/

But that seems to be a serial modem (as in standard 9pin DIN serial port). I already have a similar moden (A Jim Drew Wifi232). The problem is how did he hook it up and what software does he have that will recognise it?

I do have one of those Commodore 64 user-port to RS232 converters that let you use a standard Hayes modem on a C64 back in the 1980s, but I've heard the PET's user port is just different enough that it might not be compatible (no power on certain pins, lines different) and I terrified of trying something untested and breaking my PET.

I left him a PM on the BBS, but often new users don't return, so I'm wondering if anyone here knows the solution? I would LOVE to get online with my PET!

Maybe he's using one of these adapters, but unless I find something that has been specifically tested on the PET, I'm reluctant to try it.
https://www.tindie.com/products/8bit_bruno/simple-wifi-rs232-modem-commodore-serial-bundle/
 
Last edited:
My post #46 probably holds the secret?

MCTERM ROM and disk plus an interface cable between the USER port ‘bit banging’ the serial lines to the modem.

That’s my guess anyhow.

I haven’t even fixed my 8032 yet!

Dave
 
You must log in or register to reply here.
Back
Top