[Home] [Downloads] [Search] [Help/forum]

Gammon Forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  Electronics
. -> [Folder]  Microprocessors
. . -> [Subject]  Atmega chip stand-alone programmer to upload .hex files
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?

Atmega chip stand-alone programmer to upload .hex files

Postings by administrators only.

[Refresh] Refresh page


Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Fri 11 May 2012 02:48 AM (UTC)

Amended on Tue 31 Mar 2015 11:10 PM (UTC) by Nick Gammon

Message
This page can be quickly reached from the link: http://www.gammon.com.au/uploader


This project is intended to allow you to program your Atmega chips without having to buy a dedicated ICSP programmer. Instead, it uses a Uno (or similar) board to act as a programmer.

The programming sketch is running on the Uno. The hex (binary) file to be uploaded to the target chip has been compiled in the Arduino IDE (Integrated Development Environment) and copied to the SD card.

The (micro) SD card is plugged into a Micro SD breakout board, similar to this:



These boards can be purchased for around $US 15, and let you plug in an ordinary micro-SD card, which you can then swap into your PC / Mac / Linux box to upload or download .hex files.

Arduino Ethernet Shield support


Version 1.27 onwards of the sketch allows you to use the Arduino Ethernet Shield (which has a micro-SD card connector on it) instead of using a SD card adapter.

If you are using the Ethernet Shield then you have to make USE_ETHERNET_SHIELD true, a little way from the top of the sketch, as follows:


#define USE_ETHERNET_SHIELD true


When using the Ethernet shield there is a wiring change (described below) because the Ethernet shield uses D4 as the "slave select" pin for the SD card.

Example session


Upon starting the sketch it reads the SD card and locates all the .hex files in the root directory, like this:


Atmega hex file uploader.
Written by Nick Gammon.
Version 1.0
Reading SD card ...

HEX files in root directory:

BLINK2~1.HEX : 4595 bytes.  Created: 2012-05-11 07:47:40.  Modified: 2012-05-11 10:50:06
OPTI328.HEX : 1467 bytes.  Created: 2011-11-29 10:11:44.  Modified: 2011-11-29 10:11:44
MEGA2560.HEX : 22989 bytes.  Created: 2011-11-29 10:11:44.  Modified: 2011-11-29 10:11:44
ATMEGA8.HEX : 2870 bytes.  Created: 2011-11-29 10:11:44.  Modified: 2011-11-29 10:11:44
LILYPAD.HEX : 5484 bytes.  Created: 2010-09-25 22:52:34.  Modified: 2010-09-25 22:52:34
SKETCH~1.HEX : 170228 bytes.  Created: 2012-05-11 09:40:24.  Modified: 2012-05-11 09:40:24
LARGE_~1.HEX : 170228 bytes.  Created: 2012-05-11 10:54:48.  Modified: 2012-05-11 10:54:48
BLINK3.HEX : 3061 bytes.  Created: 2012-05-11 11:08:00.  Modified: 2012-05-11 11:08:00


The size and date/time modified are shown to help you to choose the appropriate file. Note that the file names are the old "8.3" style, so you may not see the exact name you saved them as.

The sketch then detects the type of chip it is connected to, like this:


Attempting to enter programming mode ...
Entered programming mode OK.
Signature = 0x1E 0x95 0x0F 
Processor = ATmega328P
Flash memory size = 32768 bytes.
LFuse = 0xE2 
HFuse = 0xDB 
EFuse = 0xFD 
Lock byte = 0xFF 


You are then asked to choose which file to upload/process:


Choose a file [  ] ...


I'll choose BLINK3.HEX (type into input box, or copy and paste):


Processing file: BLINK3.HEX
Checking file ...

##
Lowest address  = 0x0
Highest address = 0x439
Bytes to write  = 1082
No bootloader.
Suggest making high fuse = 0xDB 


The file is read to verify that it is the correct format for an Intel hex file, including checking the sumcheck bytes for each line.

It also checks that the file will fit into the memory of the target processor.

If the file is too large you may see a message like this:


Highest address of 0x3FFD9 exceeds available flash memory top 0x8000


Or if the file appears to be a bootloader, but does not start on one of the bootloader boundaries for this particular chip:


Start address is not a bootloader boundary.


If all is well you will see this:


Type 'V' to verify, or 'G' to program the chip with this file ...


You can type V to verify an earlier upload, or G (Go) to upload the file to the target chip:

If you type G you will see something like:


Processing file: BLINK3.HEX
Erasing chip ...
Writing flash ...

#########
Written.
Processing file: BLINK3.HEX
Verifying flash ...

########
No errors found.
No bootloader.
Setting high fuse = 0xDB 
Done.


The flash memory is erased, the file written, and then the flash verified to confirm it agrees with what should have been uploaded.

Also the appropriate fuse byte is set so that the processor boots into this file. If the file starts at address 0 then the reset vector is set to be the one at address 0. Otherwise, it programmed to boot into the bootloader address.

Speed


The examples above programmed in about a second. A larger file (170228 bytes on disk, 60518 bytes to be written to flash memory) takes:


  • 10 seconds to check the disk file
  • 20 seconds to program the chip
  • 18 seconds to verify the chip contents


By comparison, uploading the same sketch through the bootloader took about 18 seconds. So this method is comparable in speed. Well, it's slower if you include verifying the board afterwards, but I don't think the bootloader does that. You could always remove the verify step from the sketch to save time.


Wiring


SD card

If you are using the Arduino Ethernet Shield you can skip this part, because the shield has an SD card connector on it.

Since the SD card uses SPI we have used "hardware" SPI to access the Flash card. This is wired up like this:




Arduino      SD Card
-------------------------------------

D10 (SS)     CS (chip select) (green)
D11 (MOSI)   DI (data in) (blue)
D12 (MISO)   DO (data out) (orange)
D13 (SCK)    CLK (clock) (yellow)

+5V          5V (red)
Gnd          GND (green)


Then for the target chip we use "bit banged" SPI, so that both devices can be active at once.

Target device




Arduino      Atmega328
-------------------------------------

D4 (SCK)     Pin 19 (black) (or D3, see below)
D5 (SS)      Pin 1 (reset) (green)
D6 (MISO)    Pin 18 (orange)
D7 (MOSI)    Pin 17 (white)

+5V          5V (red)
Gnd          GND (blue)


If you are using the Arduino Ethernet Shield, use D3 for SCK rather than D4, as D4 is used as the Slave Select pin for the SD card interface.

If the target device requires an external clock the sketch provides an 8 MHz clock output on pin D9, so connect pin D9 to the clock input (pin 9 on an Atmega328).

Producing a .hex file


To produce the .hex file you need to Verify your sketch in the IDE.

If you select "verbose" mode in the IDE you will see the file names scroll by in the message box. The last file name will be the .hex file which you need to put onto your chip:


/var/folders/1l/43x8v10s1v36trvjz3v92m900000gn/T/build5801712006257958435.tmp/Blink2.cpp.hex
Binary sketch size: 1082 bytes (of a 30720 byte maximum)


Make sure you have selected the correct target board in the IDE before you verify your sketch, this ensures that the correct code is generated for the chip you upload it to.

Then copy that hex file onto the SD card, unmount (eject) the SD card from your PC, and insert it into the SD reader. Then you are ready to program your chip.

Starting addresses


For chips which support a bootloader, there are 5 possible starting address, depending on the size of the bootloader. For example, with the Atmega328:


  • 0000: no bootloader, boots straight into target sketch
  • 7000: 4096 byte bootloader
  • 7800: 2048 byte bootloader
  • 7C00: 1024 byte bootloader
  • 7E00: 512 byte bootloader


Any other starting address will invalid, because the processor would not start executing the sketch program from that location.

The programming sketch endeavours to work out the valid starting addresses, and rejects any .hex file that does not start on those boundaries, for a particular target chip.

It also sets the fuse byte appropriately to make it boots at the requested address. Other fuse bits are not changed.

Wiring for Mega2560 board




Code


Source on GitHub

The latest version will be available on GitHub:

https://github.com/nickgammon/arduino_sketches

You can see from that what recent changes were.


Also you require the SDFat library:

https://github.com/greiman/SdFat


Tip:
The SdFat library seems to be undergoing changes/improvements as at April 2015. The hex uploader may not compile with the new version of the SdFat library.

An archived version of the SdFat library (which works with the hex uploader sketch) is available from:

http://gammon.com.au/Arduino/SdFat-master.zip (2.2 Mb)

Unzip that file, and from within the folders inside it, copy the SdFat folder into your "libraries" folder (which is under your Arduino sketchbook folder - not inside the Arduino application folder). Then restart the Arduino IDE.


If you try to compile under older versions of the Arduino IDE, which do not support the F macro, you will get errors. You can get a copy of that here:

http://arduiniana.org/libraries/flash/



Disclaimer


This sketch is a work-in-progress. Please be advised that it has not been tested on every possible chip. Various chip signatures and configurations have been allowed for but it is possible that there was a transcription error for some of them. You are advised to verify the settings for your chip. Use at your own risk.

Custom cable


You can save yourself some time and effort by making up a custom ICSP cable, like this:



Now for boards (like the Sanguino, Uno, Mega2560) that have an ICSP header, just plug one end of the cable into it, and the other end into your programming board, like this:




Easy cabling for Micro SD board


You can easily connect to the Micro SD board by getting a 4-wire female-to-female wire, and two extra ones, like this:



(Or just get 6 female-to-female wires).

The 4-wire cable just plugs into the SD card reader starting at the CS pin (chip select) and ending with CLK (clock). Then plug the red wire into the +5V pin and the black wire into the Gnd pin. I put some heat-shrink over it to stop the pins shorting against something:



The red and black (power) wires can pick up 5V and Gnd from the ICSP header (pin 2 is 5V, pin 6 is Gnd) like this:



(Note the middle pin (pin 4) is not used).

The other four wires just plug into pins D10 (CS) through to D13 (CLK) like this:



I used a longer version of the pin header to make a male-to-male gender changer:



Or you could save yourself the trouble and use male-to-female cable.

If you use both this and the custom cable suggested earlier, you can have a compact "chip programmer" like this:





Updated user interface


Since the sessions were captured above, the sketch has been modified to allow you to read from flash and save back to disk, erase flash memory, and modify fuses. Now you enter an action code like this:


--------- Starting ---------

Attempting to enter programming mode ...
Entered programming mode OK.
Signature = 0x1E 0x95 0x0F 
Processor = ATmega328P
Flash memory size = 32768 bytes.
LFuse = 0xFF 
HFuse = 0xDE 
EFuse = 0xFD 
Lock byte = 0xCF 
Actions:
 [E] erase flash
 [F] modify fuses
 [R] read from flash (save to disk)
 [V] verify flash (compare to disk)
 [W] write to flash (read from disk)
Enter action:


Example of reading flash memory:


Enter action:
R

Choose file to save as: 
TEST.HEX
Copying flash memory to SD card (disk) ...

################################################################
################################################################
################################################################
###############################################################
File TEST.HEX saved.


Example of changing the low fuse:


Enter action:
F
LFuse = 0xFF 
HFuse = 0xDE 
EFuse = 0xFD 
Lock byte = 0xCF 
Choose fuse (LOW/HIGH/EXT/LOCK) ...
LOW
Current value of low fuse = 0xFF 
Enter new value for low fuse (2 hex digits) ...
C2
WARNING: Fuse changes may make the processor unresponsive.
Confirm change low fuse from 0xFF to 0xC2 . Type 'YES' to confirm ...
YES
Changing low fuse ...
Fuse written.
LFuse = 0xC2 
HFuse = 0xDE 
EFuse = 0xFD 
Lock byte = 0xCF 

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #1 on Fri 11 May 2012 04:11 AM (UTC)

Amended on Fri 11 May 2012 04:46 AM (UTC) by Nick Gammon

Message
Example of use with ATtiny85




Example session:


Atmega hex file uploader.
Written by Nick Gammon.
Version 1.0
Reading SD card ...

HEX files in root directory:

BLINK2~1.HEX : 2210 bytes.  Created: 2012-05-11 07:47:40.  Modified: 2012-05-11 13:52:56
OPTI328.HEX : 1467 bytes.  Created: 2011-11-29 10:11:44.  Modified: 2011-11-29 10:11:44
MEGA2560.HEX : 22989 bytes.  Created: 2011-11-29 10:11:44.  Modified: 2011-11-29 10:11:44
ATMEGA8.HEX : 2870 bytes.  Created: 2011-11-29 10:11:44.  Modified: 2011-11-29 10:11:44
LILYPAD.HEX : 5484 bytes.  Created: 2010-09-25 22:52:34.  Modified: 2010-09-25 22:52:34
SKETCH~1.HEX : 170228 bytes.  Created: 2012-05-11 09:40:24.  Modified: 2012-05-11 09:40:24
LARGE_~1.HEX : 170228 bytes.  Created: 2012-05-11 10:54:48.  Modified: 2012-05-11 10:54:48
BLINK3.HEX : 3061 bytes.  Created: 2012-05-11 11:08:00.  Modified: 2012-05-11 11:08:00
---------
Attempting to enter programming mode ...
Entered programming mode OK.
Signature = 0x1E 0x93 0x0B 
Processor = ATtiny85
Flash memory size = 8192 bytes.
LFuse = 0xE2 
HFuse = 0xDF 
EFuse = 0xFF 
Lock byte = 0xFF 
---------
Choose a file [  ] ...
Processing file: BLINK2~1.HEX
Checking file ...

##
Lowest address  = 0x0
Highest address = 0x30B
Bytes to write  = 780
No bootloader fuse.
Type 'V' to verify, or 'G' to program the chip with this file ...
Processing file: BLINK2~1.HEX
Erasing chip ...
Writing flash ...

#############
Written.
Processing file: BLINK2~1.HEX
Verifying flash ...

############
No errors found.
No bootloader fuse.
---------
Attempting to enter programming mode ...
Entered programming mode OK.
Signature = 0x1E 0x93 0x0B 
Processor = ATtiny85
Flash memory size = 8192 bytes.
LFuse = 0xE2 
HFuse = 0xDF 
EFuse = 0xFF 
Lock byte = 0xFF 




Example of use with Atmega644P (Sanguino)




Example session:


Atmega hex file uploader.
Written by Nick Gammon.
Version 1.0
Reading SD card ...

HEX files in root directory:

BLINK2~1.HEX : 2210 bytes.  Created: 2012-05-11 07:47:40.  Modified: 2012-05-11 13:52:56
OPTI328.HEX : 1467 bytes.  Created: 2011-11-29 10:11:44.  Modified: 2011-11-29 10:11:44
MEGA2560.HEX : 22989 bytes.  Created: 2011-11-29 10:11:44.  Modified: 2011-11-29 10:11:44
ATMEGA8.HEX : 2870 bytes.  Created: 2011-11-29 10:11:44.  Modified: 2011-11-29 10:11:44
LILYPAD.HEX : 5484 bytes.  Created: 2010-09-25 22:52:34.  Modified: 2010-09-25 22:52:34
SKETCH~1.HEX : 170228 bytes.  Created: 2012-05-11 09:40:24.  Modified: 2012-05-11 09:40:24
LARGE_~1.HEX : 170228 bytes.  Created: 2012-05-11 10:54:48.  Modified: 2012-05-11 10:54:48
BLINK3.HEX : 3061 bytes.  Created: 2012-05-11 11:08:00.  Modified: 2012-05-11 11:08:00
SANGBLNK.HEX : 2955 bytes.  Created: 2012-05-11 14:27:22.  Modified: 2012-05-11 14:27:22
---------
Attempting to enter programming mode ...
Entered programming mode OK.
Signature = 0x1E 0x96 0x0A 
Processor = ATmega644P
Flash memory size = 65536 bytes.
LFuse = 0xFF 
HFuse = 0xDC 
EFuse = 0xFD 
Lock byte = 0xCF 
---------
Choose a file [  ] ...
Processing file: SANGBLNK.HEX
Checking file ...

##
Lowest address  = 0x0
Highest address = 0x411
Bytes to write  = 1042
No bootloader.
Suggest making high fuse = 0xDD 
Type 'V' to verify, or 'G' to program the chip with this file ...
Processing file: SANGBLNK.HEX
Erasing chip ...
Writing flash ...

#####
Written.
Processing file: SANGBLNK.HEX
Verifying flash ...

####
No errors found.
No bootloader.
Setting high fuse = 0xDD 
Done.
---------
Attempting to enter programming mode ...
Entered programming mode OK.
Signature = 0x1E 0x96 0x0A 
Processor = ATmega644P
Flash memory size = 65536 bytes.
LFuse = 0xFF 
HFuse = 0xDD 
EFuse = 0xFD 
Lock byte = 0xFF 
---------
Choose a file [ SANGBLNK.HEX ] ...

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #2 on Sat 06 Oct 2012 11:50 PM (UTC)
Message
Improvement allows target to run


The latest version (in the .zip file, and also GitHub) has a boolean (defaulting to true) as follows:


const bool allowTargetToRun = true;  // if true, programming lines are freed when not programming


If true, while the sketch is awaiting your command (eg. W for Write, V for Verify etc.) the four pins connecting to the target board are set to high-impedance (input). This lets the board leave its reset state and run the (newly uploaded) sketch on it.

This makes it easy to upload a sketch, test it, and re-upload fixes, without having to keep inserting and removing the four wires for programming. The wires in question are D4 to D7.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #3 on Fri 09 Nov 2012 10:47 PM (UTC)
Message
Improvement allows sketch to run with no SD card


The latest version (in the .zip file, and also GitHub) now allows the sketch to proceed with no SD card detected. This means you can use the sketch to check signatures, change fuses, and erase the target flash, even if you haven't got an SD card (or the adapter board).

(Commit)

https://github.com/nickgammon/arduino_sketches/commit/1469ebff9afcb7f

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #4 on Fri 18 Oct 2013 09:28 PM (UTC)
Message
Improvements disallows unsafe actions


Certain fuse changes, made inadvertently, can "brick" your processor. In particular changing the High fuse to disable SPI programming, or disabling the Reset pin.

The sketch has been altered to check the three high-order bits of the High fuse to ensure that they are 110xxxxx

The high order bit (1xxxxxxx) should be a 1 (that is, "unprogrammed") which for most chips means the Reset pin can be used.

The next bit (x1xxxxxx) should also be a 1 (that is, "unprogrammed") which for most chips means that DebugWIRE, JTag, or OCD (on chip debug) is disabled.

The third bit (xx0xxxxx) should be a 0 (that is, "programmed") which for most or all chips enables SPI programming.

SPI programming is what is actually used to do the programming of the chip, thus turning it off would make the chip unprogrammable.

These checks are enabled by a define near the start of the sketch:


#define SAFETY_CHECKS true        // check for disabling SPIEN, or enabling RSTDISBL 


You can make that "false" if you really want to change those three fuse bits.

These changes should make it difficult to inadvertently make the target chip unusable.

(Commit)

https://github.com/nickgammon/arduino_sketches/commit/4782e9d0

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #5 on Fri 13 Feb 2015 01:55 AM (UTC)

Amended on Fri 13 Feb 2015 06:31 AM (UTC) by Nick Gammon

Message
Variant which uploads a single file


Following a request on the Arduino forum a modified version is now available:

https://github.com/nickgammon/arduino_sketches/blob/master/Atmega_Hex_Uploader_Fixed_Filename

This removes all serial interaction, and is now a standalone "update firmware" sketch.

The intention is to allow multiple chips to be programmed, if necessary "in the field", without needing to have a laptop or PC with a serial interface.

The file name is hardcoded as "firmware.hex".

You need to add additional wiring to what is described above, namely:


  • A "start programming" switch on D2, normally open, which is connected to Ground when closed.
  • A red "error" LED connected (via a 220 ohm resistor) to A0.
  • A green "ready" LED connected (via a 220 ohm resistor) to A1.
  • A yellow "working" LED connected (via a 220 ohm resistor) to A2.


How to use


When powered up, the green "ready" LED should glow steadily, indicating it is ready to be used. Connect up your target chip via ICSP and close the switch on D2 (briefly).

The green LED will go out. The yellow "working" LED should flash rapidly as the firmware is flashed. Then the green LED will go on steadily, and the yellow LED will flash as the chip is verified. Finally the green LED should flash quickly 3 times, wait a second, and repeat that sequence 10 times (10 lots of 3 flashes) to indicate it finished OK. After that the green LED will light steadily to indicate it is ready to program another chip.

Programming time


As a guide, I flashed the ASCIItable sketch in about 7 seconds. A larger sketch (the bootloader uploader, which is about 28kB of program memory) took around 46 seconds.

Error statuses


Since there is no serial interface, various flash combinations indicate different error conditions. These are done by flashing up to 9 times either the red or yellow LED, or both together, repeated in groups of five. (eg. 5 lots of 4 flashes).

Flash rates

A "status" consists of one or more flashes, 200 mS apart (in other words, quickly blinking). The status groups are repeated with a one-second gap. So if you see 5 slow flashes (a second between each one) then that is "Cannot open SD card" (shown 5 times), not "Cannot reach chip signature" shown once. For example "Cannot enter programming mode" would be:


blink-blink-blink --- pause --- blink-blink-blink --- pause --- blink-blink-blink ... and so on, five times



These statuses are:

Problems with SD card or programming target chip


  • Red x 1 = Cannot open SD card
  • Red x 2 = Cannot read file 'firmware.hex'
  • Red x 3 = Cannot enter programming mode in target chip
  • Red x 4 = This chip does not have a bootloader fuse
  • Red x 5 = Cannot read chip signature
  • Red x 6 = Unrecognised signature
  • Red x 7 = Bad start address in hex file for code
  • Red x 8 = Verification error


Problems with firmware.hex file


  • Red+yellow x 1 = Line in file is too long
  • Red+yellow x 2 = Line in file is too short
  • Red+yellow x 3 = Line does not start with a colon (:)
  • Red+yellow x 4 = Invalid hex digits (should be 0-9, A-F)
  • Red+yellow x 5 = Bad sumcheck at end of line
  • Red+yellow x 6 = Line not expected length
  • Red+yellow x 7 = Unknown record type
  • Red+yellow x 8 = No 'end of file' record in file
  • Red+yellow x 9 = File will not fit into flash of target


If you have a problem with the firmware.hex file (ie. the red+yellow statuses) try loading the file into the Atmega_Hex_Uploader sketch (shown earlier in this page) which would show you the exact line number causing the problem in the serial monitor.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #6 on Sun 03 May 2015 03:53 AM (UTC)

Amended on Sun 03 May 2015 03:57 AM (UTC) by Nick Gammon

Message
Stand-alone programmer pre-assembled


Robert Patterson from CrossRoads Fencing (and a moderator on the Arduino forum) has made a pre-assembled stand-alone programmer board.

It looks like this:



It does not need a PC interface. You just power it up and the current file number is displayed in the two-digit display. You dial-up which file you want programmed (00 to 99, or optionally 00 to FF) and then press the Start button. The LEDs and the 7-segment display show the progress of the programming.

You can obtain one from here:

http://www.crossroadsfencing.com/BobuinoRev17/Programmer.html

This would be useful for technicians "in the field" to reprogram the firmware in devices, or for places like schools where you want to quickly install code, or bootloaders, onto multiple boards.

The code mentioned above (in reply #5) has been updated to support this board.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


54,957 views.

Postings by administrators only.

[Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at FutureQuest]