Click Here to visit our Sponsor
The Latest News ! The History of Computing The Magazine Have Fun there ! Buy books and goodies
  Click here to loginLogin Click here to print the pagePrinter ViewClick here to send a link to this page to a friendTell a FriendTell us what you think about this pageRate this PageMistake ? You have mr info ? Click here !Add Info     Search     Click here use the advanced search engine
Browse console museumBrowse pong museum


Ready prompt T-shirts!

see details
C64 maze generator T-shirts!

see details
Spiral program T-shirts!

see details
Pixel Deer T-shirts!

see details
BASIC code T-shirts!

see details
Breakout T-shirts!

see details
Vector ship T-shirts!

see details
Pixel adventure T-shirts!

see details
Pak Pak Monster T-shirts!

see details
Shooting gallery T-shirts!

see details



Untitled Document

Ray Gannon has written an excellent description of the Microtan 65 :

The Microtan 65 (M65 for the purposes of this description) was a 6502 based single board microcomputer which could be expanded into what later became the ORIC, ATMOS and later computers. The basis of all these highly integrated machines can be seen in the Microtan 65, and although the detail of the I/O addressing varies between the M65 and the ORIC etc, the fundamental method of keyboard addressing, tape I/O were all there in the M65. In addition, the M65 was very much a hands-on machine - it had a powerful single step function that could be used for debugging at the hardware level.


The M65 was quite simple by today's standards - an NMOS 6502 running at 750 KHz clock rate, cassette interface for storing and retrieving programmes (300 and 2400 baud even then!), and the option to use either a software scanned hex keypad or (if you could afford it) an ASCII keyboard. The M65 had a massive 1K byte of RAM, and the original monitor program (not even called an operating system) held in EPROM was also 1K. This was later changed to a 2KByte monitor program. In keeping with all the early monitors it was called a bug - presumably a bad joke, in this case TANBUG. The software facilities were rudimentary; Modify memory, Display a block of memory, Run a program, Display Registers, Single Step, Set Breakpoints, Copy a block of memory.....

The major advance that the M65 had over a lot of the competition at that time was that the VDU was flicker free - that is expected now, but at the time a lot of micros would either access the screen memory asynchronously to the video timing (causing flicker and splats on the screen) or would only write to the screen memory during a non- display period (which was slow). The M65 got over this problem by making use of a major feature of the 6502. The 6502 (unlike most current CPUs) has a regular period in its processing when all CPU activity is inside the chip, leaving the external memory available for access by other circuitry - in this case the screen memory. This technique is also used on the ORIC.


The screen memory occupies the space between $200 and $3FF ($ here means hexadecimal). In addition to the standard 8 bits of screen RAM, there was an additional single bit RAM shadowing the $200 to $300 space. This was configured as a 9th bit write-only plane, and was used by the M65 for rudimentary graphics. Setting the 9th bit to a bit displayed a Minitel type block graphic.

$300 is the top left hand displayed character and the display is 32 characters across by 16 lines down - The character representation is standard ASCII. Several pieces of M65 software write to the bottom line by writing to memory starting at $3E0 - the left hand character on the bottom line, rather than vectroing through TANBUG. The 32 x 16 characters was the reason that the 6502 was clocked at 750 KHz. To get the circuitry to work at a (nearly) standard video rate meant that the pixel clock had to be 6MHz. When the M65 was designed only a 1MHz 6502 was available, and so 750KHz was used (6MHz divided by 8). A lot of 6502's could be persuaded to work at a higher clock rate, and I managed to get an M65 working at 1.5 MHz (although this required some software mods in my system - the tape interface timing)

I/O in the M65 is decoded into a 16K space to simplify the hardware. In fact the 1K of RAM is echoed through the bottom 32K, the I/O through the next 16K, and the EPROM through the top 16K. If you added an expansion board (TANEX) the decoding was modified and the wasted space reclaimed.

The M65 memory map is shown below :

Low memory 0000 Zero Page
  0100 Stack
  0200 Screen RAM
  0400 end of M65 memory (!)
  8000 I/O
  F800 TANBUG V2
High Memory FFFF  

In common with other 6502 designs, I/O is mapped into memory space, there is no dedicated I/O space as on the Z80, 8086 etc.
The I/O ports are (when fully decoded) :

Write to $BFF0 Clear Keyboard Flag (Keyboard would generate an IRQ)
Read from $BFF0 Turn Graphics On (enables "9th bit" graphics writes)

Write to $BFF1 Used by the hardware single step

Write to $BFF2 To write a scan pattern to the hex keypad (if fitted)

Write to $BFF3 Turn off Graphics (disable "9th bit" graphics writes)
Read From $BFF3 Read Keyboard Port (either keypad or ASCII keyboard)



Adding a TANEX board gave you a number of features - an add-on to TANBUG called EXBUG, extra RAM, ROM sockets, a couple of 6522 PIA's, and a 6551 UART. At Reset, TANBUG looks at the connected I/O, and enables various features (Printer, UART comms, Cassette etc) depending on what you have installed - very elegant. And not only the hardware, incorporating EXBUG into the system was automatic as well, and was really quite clever (if not unique!).

Without a TANEX board, the address $F7F7 would appear to the 6502 to have the same data as $FFF7. In TANBUG, this is a jump to an internal monitor routine. With TANEX installed, $F7F7 is decoded properly, and that address is an entry point into EXBUG. EXBUG provided features such as cassette tape loading and saving, a simple assembler / disassembler, hex calculator.

The ROM sockets on TANEX could be used to run a 12K BASIC, or a two pass assembler, or even (and more likely given the hardware bias of the M65) code written for a specific hardware control application.

Written by Ray Gannon 17 April 97

Click here to go to the top of the page   
Contact us | members | about | donate old-systems | FAQ
OLD-COMPUTERS.COM is hosted by - NYI (New York Internet) -