This would totally screw up drivewire server, but I’m using my own drivewire server, and could have it detect plain text transmissions and forward them to a printer…

This post was submitted by sc.

This post was submitted by jayee.

Originally, I wasn’t going to get them, but after I contacted the seller she offered to let me have both drives for $4.99 plus actual shipping, which turned out to be a significantly less than ebay’s calculated shipping.

So far I’ve done a little bit of light cleaning on them and hooked them both up. I can’t get the white one to read or write anything as of yet, and I have to nudge the platter to get the disk to turn, but the silver one actually seems to operate properly.

I guess it’s a good thing that the silver one is the working one, as it looks like I could put any full height drive into the white one, which makes an easy repair. The silver one looks to have an extra-long circuit board, so I’m probably stuck with the drive that’s in there.

By the way, has anyone heard from John of GIMEchip.com in the past week or so? I never got the MB8877a he said he was sending me and I haven’t seen him post anything here or send anything to the mailing list recently – I’m hoping he’s alright, I remember him making that post about his health that one time.

This post was submitted by jmetal88.

tjb

This post was submitted by tjb.

This post was submitted by Kodiak.

This post was submitted by zerocool.

This post was submitted by notagamer94.

This post was submitted by zerocool.

This post was submitted by beretta42.

Thanks,
tjb

This post was submitted by tjb.

This post was submitted by zerocool.

This post was submitted by zerocool.

This post was submitted by sc.

Thanks,
James

This post was submitted by jms71.

I’m glad I found this site.  I have been carrying around two, like-new, CoCo 2′s for years, now I’m retired and I want to spend some time playing with them.  Why?  Because,  in 1984, I wrote the thesis for my Master’s Degree on a CoCo 2, using colorscripsit, the C81 cassette and a small dot matrix printer for the thesis drafts.  When I had the final ready to go I paid a fellow student to type the thesis into proper format, but the year of drafts and edits and redo’s was all done on the CoCo.  The little machine really hung in there for me, so about 7 years ago I bought the two CoCo’s and some peripherals, just to remember and relive. 

This post was submitted by adventure.

http://cgi.ebay.com/Tandy-Color-Computer-3-System-Extras-/110557958839?cmd=ViewItem&pt=LH_DefaultDomain_0&hash=item19bdc492b7

I am selling this system – looking for a good home!

Scott

This post was submitted by ScottC.

http://www.goldmine-elec.com/

What transistor should I use for the speech and sound pak? See below:

G4881A 74LS10 Triple 3-Input Positive-NAND qty2.00 $0.50
—————————————————————————
A10498 2N3906 PNP General Purpose Amplifier qty2.00 $0.26
—————————————————————————
G43155 2N3906 Small Signal General Purpose PNP qty2.00 $0.24
—————————————————————————
A20193 2N3906 Small Signal PNP Transistor qty2.00 $0.26
—————————————————————————
G16844 14 Pin IC Socket qty 2.00 $0.40

This post was submitted by adventure.

If any one can point me to it on the internet with a link or send me a DSK via email. chazbeenhad at hotmail dot com.

Thanks!

This post was submitted by Charlie.

Thanks All – John
512KAnySIMM_PLUS_512K-44256_PLD-Equations(GIMEchip.com)

Name GCC-MEMBRD-0001.0 ;
PartNo GCC-MEMBRD-0001.0 ;
Date 6 1 2010 ;
Revision 01 ;
Designer J&R ;
Company GIMEchip.com ;
Assembly 512K 1M 2M Memory Board for CoCo 3 ;
Location U1 ;
Device g16v8 ;

INPUT PINS
PIN 01 = E; This is the E-Clock Output from the G.I.M.E. A.C.V.C.

PIN 02 = !HSYNC; This is the Horizontal Sync from the GIME A.C.V.C.

PIN 03 = !VSYNC; This is the Vertical Sync from the G.I.M.E. ACVC.

PIN 04 = !RAS; This is the Row Address Strobe from the GIME ACVC.

PIN 05 = !CAS; This is the Column Address Strobe from the GIME ACVC.
The following two signals are not used in the 512K Upgrades.

PIN 06 = DAT6; This is Bit 6 from the DAT Board of the 1M and 2M upgrades. It is either Bit 6 of
the extended Dynamic Address Translation (DAT) memory or Bit 0 of the Video Bank
Register.

PIN 07 = DAT7; This is Bit 7 from the DAT Board of the 2M upgrades. It is either Bit 7 of the
Extended DAT memory or Bit 1 of the Video Bank Register.

OUTPUT PINS
PIN 12 = !CASOUT; This is the !CAS signal to the DRAM. During any Video or CPU cycle, it follows
!CAS from the G.I.M.E. A.C.V.C. During a REFRESH Cycle, !CAS and !RAS (!CASOUT,
!RASOUT) are swapped at the DRAMs, and !CASOUT is truncated so as to terminate
simultaneously with !RASOUT, the effect of which is to cause the DRAMs to perform
a CBR (CasBeforeRas) Refresh cycle using the DRAMs internal counters. This method
allows the use of 512-Cycle Refresh DRAM, whereas the GIME normally only supports
DRAM with a 256-Cycle Refresh. Using this method should allow any 30-pin or
72-Pin SIMM (120nS or faster) to be used with the CoCo 3. In fact, it should
allow the use of almost any DRAM (within reason) that supports CBR Refresh.

PIN 13 = !RASOUT; This is the !RAS signal to the DRAM. It normally follows !RAS from the GIME.
See !CASOUT for more details, above.

PIN 14 = !CPUVID; This signal tells the DAT board whether the current Cycle is a CPU Cycle or a
Video Cycle. 1=CPU, 0=Video. This signal is needed so that the DAT Board knows
when to present either the DAT Bits 6,7 or the Video Bank Bits to DAT6 DAT7.

PIN 15 = Z9; This is the multiplexed address line Z9 to the DRAMs. It will be DAT6 on !RAS or
DAT7 on !CAS. DAT6 and DAT7 will be either the DAT Memory Bits or the Video
Bank Bits, depending on the state of !CPUVID. DAT6 & DAT7 are generated by
circuitry over on the DAT Board.

LOGIC EQUATIONS & VARIABLE DEFINITIONS
SYNC = HSYNC # VSYNC; This signal is active during either HSYNC or VSYNC time.

RFSH = SYNC & !E; This signal indicates that we have time to do a CBR
Refresh of the DRAM.

CPU = E; This signal indicates a CPU cycle is in progress. Not
used – just here for reference. E=1=Always a CPU Cycle.

VID = !HSYNC & !VSYNC & !E; This signal indicates that a Video Cycle is in progress.
Note: Clock Speed=1.78Mhz=E=0=Video Cycle. This is not,
however, the case in .89Mhz mode. In .89Mhz mode,
E=0=Video Cycle except during HSYNC and VSYNC time.

CASOUT = (CAS & !RFSH) # (RAS & RFSH); CASOUT follows !CAS during a non-refresh cycle. During a
refresh cycle, CAS and RAS are swapped at the DRAM.

RASOUT = (RAS & !RFSH) # (RAS & CAS & RFSH); RASOUT follows !RAS during a non-refresh cycle. During a
refresh cycle CAS and RAS are swapped at the DRAM. Note
the presence of both RAS and CAS in the refresh cycle.
of this signal. This was done to truncate CAS making
sure that it terminates simultaneously with RAS as the
DRAM expects.

CPUVID = VID; This signal is high during a CPU cycle and low during a
Video cycle. I originally wrote this as VID & !CPU which
is redundant, but produces the same result. In fact, the
previous equations for CPU and VID can be eliminated and
CPUVID written as: CPUVID = !SYNC & !E.
The DAT Board really only needs to know when a REAL
Video Cycle is in progress so as to present the Video
Bank Bits – at all other times, the DAT6 & DAT7 bits
are presented from the extended DAT memory.

Z9 = (DAT6 & RAS) # (DAT7 & CAS); This is the multiplexed Z9 Address line – not used in
512K upgrades.

I have the XT disk controller used with these drives installed in an older PC, booting from a SCSI drive into Ubuntu Linux. So far I have managed to have it see the device (I had to recompile the kernel first) but it cannot successfully read any of the sectors.

I have successfully transferred multiple SCSI hard disks to disk images.

This post was submitted by wesgale.

I finally finished my review of Roger’s Drive Pak and CoCoNet. It’s all here with videos (GR2K is a yawner due to load time…). If you’re considering getting one of these cool new devices, go take a look. Hopefully the info there will help you make the right decision for your needs.

Brian

I have found some posts online that say I can replace the ROM11 with the ROM file from Robert’s web site. However, that does not work and the machine does not boot (coco3 or coco3h). In the terminal error messages talk about invalid CRC checksums. So there must be a CRC checksum database somewhere.

I’ve also noticed that ROM11 actually has code for 2 locations $C000 (if I remember correctly, this is the start of cartridge ROM) and $E000 (I have no idea what may be stored here). If this is the case these ROMS are not just a dump of program information, but a combination of memory location and program information. Which leads me to the conclusion that the ROM dump must be processes somehow.

Any help getting this to work in XMAME/XMESS would be helpful.

Thanks,

William

This post was submitted by willz88coco3.

Thanks and have a good day!

This post was submitted by remz.

Okay, so I forgot about the holiday (July 4th). Now that the holiday is out of the way, I can get around to posting part 2 of this project. Part 1 is located HERE.

Before getting started, download the zip file containing the EAGLE files and PDF files HERE.

NOTE: This became part 2 of 3 rather than 2 of 2 – part 3 will be the equations for the 22v10 GAL chip. – John

With that in mind, I began working non-stop for just under nine hours. At the end of that nine hours, I had finished that which you see before you now. An 8-Slot Multi-Pak Compatible Interface for our beloved CoCo. Keep in mind – this was all done for you guys (and gals). I wanted to make something that would be of use to each and every one of you.

Now, this article is separated into two parts. This is part 1 of 2. I decided early on to use two PCB’s (Printed Circuit Boards), with the 8-Slot Board attaching to the Buffer Cartridge Board via a short length of 40-wire ribbon cable. I know that using two PCB’s increases the cost somewhat, but I really wanted the flexibility afforded by the use of the ribbon cable. With that in mind, let’s have a look at the Buffer Cartridge Board (download the files at the end of this article and print out the PDF’s to reference as you read along.)

The Buffer Cartridge Board plugs into the cartridge slot of the CoCo or Dragon and buffers all address and control lines before passing them via the ribbon cable to the Slot Board. Note that the Data Bus isn’t buffered at this point by the cartridge board – it is passed on to the Slot Board where it is buffered bi-directionally.

Looking at the schematic, page 1:
CN1 is the cartridge plug that plugs into the CoCo.
CN2 and CN3 are the grounding tabs (one on each side of the cartridge plug).
Resistor R1 and LED1 are a power on indicator – if this LED is lit, then the Computer is powered on.
Resistor R2, R3, transistor Q1 and capacitor C1 are connected so as to act as a SWITCH. When power is applied to the CoCo, the collector of Q1 will be pulled to a low logic level, termed !PS_ON (I suppose it would be more accurate to say that the transistor is wired as a logic inverter). This signal is passed to the Slot Board and is used to power on an ATX Power Supply. Turning on the CoCo, therefore, will automatically power on the 8-Slot MPI via it’s standard ATX Power Supply. This !PS_ON signal is passed to the Slot Board via Pin 9 of the 40 pin header (which is normally 5 volts from the coco, see next…)
Capacitor C6 is used as a filter cap for the 5 volts from the CoCo cartridge slot. Note that this 5 volts is used only on the Buffer Cartridge Board – it is NOT passed on to the slot board – all power is provided to the slot board via the ATX Power Supply. As such, pin 9 of the 40 pin header is freed for another use – the passing of the signal that turns on the MPI’s ATX Power Supply.
RN1A-RN1D are part of a 4.7K Resistor Network – they are used as pull up resistors for some of the sensitive signals.
S1 is a RESET switch – very handy – you can RESET the CoCo (and the MPI [if enabled, see below]) by simply pressing this little TAC Switch.
IC1 and IC2 are the Address Bus Buffers.
C2 and C3 are the decoupling caps for IC1 and IC2.

Schematic, Page 2:
CN4 is the 40-pin IDE-Type Header, which is used to connect to the Slot Board. ALL signals are buffered between the two boards, but the data bus is buffered on the Slot Board for reasons that will become apparent in part 2 of this article.
C7 is a filter cap that I erroneously included in the design and it should be omitted. This pin is not the 5V from the CoCo but is being used to pass the signal to tell the ATX power supply to switch on – so this cap is not needed.
SW1 and SW2 are switches that I will discuss at the end of this (part 1) article.
Capacitors C8,C9 and C10 are on the !CART, E and Q lines and may or may not be needed. I have allowed for them just in case.
RN1E is another 4.7K section of the resistor network used as a pullup.
IC3 and IC4 buffer all of the Control Lines plus the two (E & Q) clocks.
C3 and C4 are the decoupling caps for IC3 and IC4.

Now, the functions of the two 8-Position DIP Switches will be discussed. These 16 Total switches (contained in two 16-pin DIP packages) allow great flexibility in the control of this interface. Let’s look at them in order, starting with SW1, switch 1, on continuing until all 8 have been discussed.
SW1:
S1 = Allow/Disallow !SLENB. If this switch is OFF then !SLENB cannot be controlled by any device in the MPI. If this switch is on, !SLENB functions normally.
S2 – Allow/Disallow SOUND. If this switch is OFF, then no sound can be passed from any device in the MPI back to the SND input of the CoCo. Since the ON position of all of these switches is common sense, I’ll only discuss what the OFF position means.
S3 – OFF = Prevent R/W* from reaching the MPI.
S4 – OFF = Prevent Q Clock from reaching the MPI.
S5 – OFF = Prevent E Clock from reaching the MPI.
S6 – OFF = Prevent CTS* from reaching the MPI.
S7 – OFF = Prevent SCS* from reaching the MPI.
S8 – OFF = Prevent CART* from the MPI from reaching the CoCo. This can be used to disable the Auto-Start of the cartridge in the active MPI slot.
SW2:
S1 – OFF = Prevent RESET* from reaching the MPI. This can be used to allow the CoCo to be reset without resetting the MPI and peripherals therein.
S2 – OFF = Prevent NMI* from reaching the CoCo from the MPI.
S3 – OFF = Prevent HALT* from reaching the CoCo from the MPI.
S4 – OFF = This controls whether or not the ENABLE* signal reaches the MPI. The ENABLE* signal is generated on the cartridge board and will be discussed below. Pin 33 of the 40-pin header is used to pass the ENABLE* signal to the slot board (this pin [33] is normally 1 of 2 GND pins. The other is Pin 34 which still serves as GND.)
S5 – This switch determines whether or not pin 2 of the CoCo cartridge connector is connected to pin 2 of the header connector. Since pin 2 is not used in the CoCo 3 (it has +12V in the CoCo & Dragon), it can be used to pass specific signals such as interrupts, etc between the CoCo & the MPI. I have thus allowed for it to be used in case you need it for a project.
S6 – This switch determines whether or not pin 1 of the CoCo cartridge connector is connected to pin 1 of the header connector. Since pin 1 is not used in the CoCo 3 (it has -12V in the CoCo & +12V in the Dragon), it can be used to pass specific signals such as interrupts, etc between the CoCo & the MPI. I have thus allowed for it to be used in case you need it for a project.
S7 – This determines whether or not the !PS_ON signal reaches the MPI’s ATX power supply. If this switch is off, then the MPI cannot power on. Useful in cases where you do not wish to turn on the MPI.
S8 – This switch generates the ENABLE* signal. If this switch is OFF then the address and control bus buffers are tri-stated. If S4 is ON, then the DATA buffer is also tri-stated. This effectively disconnects the MPI from the CoCo, in case you need to do so without powering everything down. If S4 is off, the address and control buffers will tri-state, but not the data buffers (I don’t know if this mode is useful, but it’s a ”freebie” mode). Now, if S8 is off, the MPI functions normally.

Well, that’s about it for Part 1. I will post Part 2 (the Slot Board) as soon as I have time to type it all up. As you can tell, I’m not very good at writing articles – also, whenever you see a signal referred to as !ENABLE, it is the same as ENABLE* – that means the signal is active low.
DOWNLOAD THE FILES FOR PART 1 HERE:
Buffer Cartridge Board – Schematic and Layout EAGLE files
Buffer Cartridge Board – Schematic and Layout PDF files

PART 2 COMING SOON.

If you see any potential problems in this design, please let me know.

Thanks – John

The usual commands for RS-DOS work in HDB-DOS -- as far as I have played with it. The manual claims each mounted ‘drive’ has access to 256 disk images -- I did not test this as I have no images set up in this manner. All I have done is insert disks and load and run programs, making vague mental notes about load times, which were quick enough for me. NitrOS-9 load times for DriveWire 4 were very quick, and I’ll discuss that in another article.

The first thing I loaded was a demo called ‘TRIBALLS’. The image loaded and executed without a hitch. And, as you can see by the included images, they displayed quite nicely on a 15″ LCD via Roy’s VGA adapter. The first image is just two reflective balls generated by the demo.

And here’s the video I attached of my CoCo3 playing MIDI files thru the server PC using Aaron’s DriveWire 4 Java applet.

www.youtube.com/watch?v=IP7CeIfkPyA

This redefines cool folks, if you haven’t tried it yet, I highly recommend it. I’ll try to post a vid later this week of me getting on one of the BBS’s I’ve been frequenting.

There are more reviews in the pipeline as well, not the least of which is Roger’s MicroSD Drive Pak and his Serial Pak.

Later,

Brian

Edit -- guess I should have included the link…

This post was submitted by adventure.

2. Take a 20-Pin Socket and snip off all pins EXCEPT: 1,2,4,9,10,19,20.

3. Bend the following pins of the socket straight out: 1,2,4,9.

4. Place the socket atop IC1 (74LS245) and solder pin 10 to pin 10, pin 19 to pin 19 (which is bent out on IC1) and pin 20 to pin 20.

5. Solder a wire from Pin 2 of the socket to either the PCB hole where Pin 19 of IC1 was snipped from or to Pin 52 of IC6.

6. Solder a wire from Pin 1 of the socket to pin 9 of IC4.

7. Solder a wire from Pin 4 of the socket to pin 11 of IC4.

8. Solder a wire from Pin 9 of the socket to pin 3 of IC4.

9. Install the PAL chip into the socket (pin 1 to pin 1 orientation).

10. Put everything back together and the MPI should now be 100% Compatible with the Tandy CoCo 3 Upgraded 26-3124 MPI.

Enjoy! -John

Name 26-3124 M.P.I. Upgrade ;
PartNo GCC-3124.01 ;
Date 6/1/2010 ;
Revision 01 ;
Designer J&R ;
Company GIMEchip.com ;
Assembly 26-3124 M.P.I. Upgrade PAL for CoCo 3 ;
Location U1 ;
Device g16v8 ;
/* ***************************************** INPUT PINS **********************************************/
PIN 01 = !CTS; /* Cartridge Select Signal */
PIN 02 = !DBEN_IN; /* Original !DBEN Signal */
PIN 04 = A7; /* Address Line A7 */
PIN 09 = !SLENB; /* Input To Disable Device Selection. */
/* ***************************************** OUTPUT PINS *********************************************/
PIN 19 = !DBEN_OUT; /* New !DBEN Signal – Active LOW – Enables The Multi-Pak Interface Data Buffer */
/* ***************************** LOGIC EQUATIONS & VARIABLE DEFINITIONS ******************************/
DBEN_OUT = CTS # SLENB # (DBEN_IN & !A7); /* Active LOW on CTS or SLENB or (DBEN_IN and not A7)*/
/* ***************************************************************************************************/
/* 26-3124 MPI Upgrade #2, Using a PAL (GAL 16v8) (c) 01 JUNE 2010 by J&R of GIMEchip.com. Enjoy! */
/* 1. Snip pin 19 of IC1 (74LS245) close to the P.C.B. and bend it up so that it sticks straight out.*/
/* 2. Take a 20-pin Socket and snip off all pins EXCEPT: 1,2,4,9,10,19,20. */
/* 3. Bend the following pins of the socket straight out: 1,2,4,9. */
/* 4. Place the socket atop IC1 (74LS245) and solder pin 10 to pin 10, pin 19 to pin 19 (which is */
/* bent out on IC1) and pin 20 to pin 20. */
/* 5. Solder a wire from pin 2 of the socket to either the P.C.B. hole where pin 19 of IC1 was */
/* snipped from or to pin 52 of IC6. */
/* 6. Solder a wire from pin 1 of the socket to pin 9 of IC4. */
/* 7. Solder a wire from pin 4 of the socket to pin 11 of IC4. */
/* 8. Solder a wire from pin 9 of the socket to pin 3 of IC4. */
/* 9. Install the PAL chip into the socket (pin 1 to pin 1 orientation). */
/*10. Put everything back together and the MPI should now be 100% compatible with the Tandy CoCo 3 */
/* Upgraded 26-3124 MPI, with the address range limited to $FF40-$FF7F, SLENB*, CTS* */
/* ***************************************************************************************************/

This post was submitted by adventure.

The Color Computer is totally self-contained — no bulky separate power transformers — and the only cord, the one to the wall socket, has a standard three-pron g connector. It can work with any color or black-and-white television set and has provisions for joysticks, a 1500 bps (bits per second) cassette interface, and an expansion connector for preprogrammed game cartridges.

Our aim in this article is to expose the insides of the computer and show what makes it run. Using this information, you should be able to expand the Color Computer in a number of ways, with a minimum of expertise. We will also describe the graphics interface so that do-it-yourself graphics routines should be a piece of cake.

System Hardware

Taking the cover off is simply a matter of removing seven screws and lifting the lid. Be warned, however, that Tandy takes a dim view of owners fooling around with their hardware. Opening the case voids the warranty on the machine (one of the screws lies under a paper label that gives this warning).

The first surprise is that the entire computer is built on a single printed-circuit boa rd — including the power supply. Most of the digital circuitry lies inside an RFI (radio-frequency interference) shield — this was probably necessary to get FCC (Federal Communications Commission) Type Approval, but it also helps to give a clean display. To get a look at the parts, simply pry off the top of the shield.

There are only twenty-four DIPs (dual in-line packages) in the system and they are all made by Motorola. (The parts list is shown in table 1. ) The machine comes stuffed with 4 K-byte memory circuits; but there is a simple way to change these to 16 K-byte devices and a tricky way to get 32 K bytes of on-board memory — more on this later.

While we do not yet have a schematic diagram, the block diagram in figure 1 should be sufficiently detailed to allow a thorough understanding of the system. There are four basic sections:

– the microprocessor

– the video-display circuitry

– the me mory

– the other I/O (input/output) devices (keyboard, cassette, serial port, and joysticks)

The microprocessor is Motorola’s advanced 8-bit machine, the MC6809E. It was designed to support today’s high-level languages, including the Extended BASICs now available. It has two 16-bit index registers and two 16-bit stack pointers, as well as two 8-bit accumulators that can be used as a double-precision 16-bit accumulator. It supports both position-independent code (code that can be executed anywhere in memory without reassembly) and reentrant (interruptible) code.

The video display is generated by the Motorola MC6847 VDG (video display generator). This is a 40-pin LSI (large-scale integration) part that reads from 1A K bytes to 6 K bytes of memory, depending on mode, to produce an analog video signal. This signal is fed to the MC1372 color-subcarrier modulator to get composite video, which is then modulated by the ASTEC video modulator to channel 3 or 4.

The Color BASIC inte rpreter is stored in an 8 K by 8 bit ROM (read-only memory). Its companion, Extended BASIC, comes in another ROM of the same type. The basic machine comes with only the first ROM; the extended ROM costs $99 plus installation.

As mentioned, the computer comes with eight MCM4027 4 K-bit dynamic memory circuits. Tandy will upgrade your system to 16 K bytes by replacing these with MCM4116s (16 K-bit devices) for $119. Or you can buy the system with 16 K bytes and the Extended BASIC ROM for $599.

These memory circuits are controlled and refreshed by a special part, the MC6883 SAM (synchronous address multiplexer). It provides all the signals for the memory and the VDG and also provides the timing signals for the microprocessor.

The other I/O functions are all handled by parallel ports in the form of MC6821 PIAs (peripheral interface adapters). The keyboard is connected to these and is scanned and decoded in software. The serial port and cassette port are both derived from a single parallel line an d are selected by software. The optional joysticks are encoded with an A/D (analog-to-digital) converter composed of a resistive-summing network hooked to a 6-bit parallel port and an LM339 comparator.

The MC6809E Microprocessor

The third-generation MC6809E 8-bit microprocessor features several 16-bit operations. This puts it functionally between the 8- and the 16-bit processors. A description of the MC6809E signals appears in figure 2 .

The programming model of the MC6809E is shown in figure 3 . Three registers were added to the register set of the original MC6800:

– a direct page register

– a user stack pointer

– a second index register

There are two 8-bit accumulator registers, the A register and the B register, that are used for data manipulation and serve as holding registers for arithmetic calculations. The MC6809E has many 16-bit arithmetic operations, including addi tions, subtractions, loads, stores, and an 8 bit by 8 bit multiplication. The 16-bit arithmetic operations use both accumulators — with the A register treated as the most significant byte. When the A and B registers are concatenated, they are referred to as the D register.

The DP (direct page) register is one of the new registers. Its contents form the high-order byte of the address bus during instructions utilizing the direct addressing mode. This register may be changed to allow direct addressing anywhere in the 64 K-byte memory map, as compared to the MC6800, which allowed direct addressing only in the first 256 bytes of the memory map. Direct addressing uses the immediate byte of the instruction as a 1-byte pointer into a single 256-byte “page” of memory. This shortens instruction execution time because the high-order byte is furnished by the direct page register. MC6800 source code compatibility is ensured because actuation of the RESET line clears the direct page register.

The MC6809E has f our 16-bit pointer registers available to the user. The U and S registers support stack- oriented instructions such as PSH and PUL. The S register is used as the hardware stack pointer to support interrupts and subroutine calls. The U register gives the designer the capability of maintaining an independent stack.

The other two registers, X and Y, are intended primarily for use as index registers, although special indexing modes allow them to be used to maintain additional stack areas. All four pointer registers can be used as index registers, allowing indexed addressing, indirect-addressing or indexed indirect addressing. These pointer register capabilities permit the MC6809E to function efficiently as a stack processor, allowing the microprocessor to support graphics, high-level languages, and modular programming techniques.

The microprocessor’s program counter, while primarily used by the processor to address the next instruction, may be referenced as an index register, thus allowing addressing m ode. This register may be changed to allow addressing relative to the program counter.

The condition code register defines the state of the microprocessor such that conditional branch instructions may be used. The condition code register also allows masking of some of the interrupts.

The register set is manipulated with the 59 instructions shown in table 2. Over 1460 different op codes are available to the programmer if all modes of the instructions are considered. However, only the 59 mnemonics must be remembered when using an assembler.

Efficient PIC (position-independent code) can be written using the capabilities of the MC6809E. The program counter can be used as a pointer to provide offsets within the program. For example, when a portion of PIC is executed, the stack addresses, peripheral addresses, and other addresses may be specified as offsets from the current program counter address.

Other key factors in effective position-independent code writing are the use of long and short relative-branch instructions and LEA (load effective address) instructions. The relative-branch instructions allow PCR (program counter relative) branching. When an 8-bit offset is used, control may be transferred anywhere within a 256-byte area. A 16-bit offset allows transfer of control anywhere in the entire 64 K-byte address space. The following are examples of the relative-branch instructions:

        DECA        Decrement A Accumulator
        BEQCAT      If A = O then go to CAT
                    (CAT is within +/-128 bytes)
        INCA        Increment A Accumulator
        LBEQ DOG    If A = 0 then go to DOG
                    (DOG is within +/-32,768 bytes)

The LEA instructions work by calculating the effective address of an indexed instruction and storing it in the specified pointer register. This allows the programmer to use all the internal addressing hardware of the microprocessor. Below are some examples of the LEA instructions.

        Instruction
          Operation
        LEAX 1O,X            X + 10 -> X
        LEAY A,Y             Y + A -> Y
        LEAXD,Y	             Y + D -> X
        LEAU -10,U           U - 10 -> U
        LEAX TABLE,PCR	     (see text below)

Note how the registers may be incremented or decremented using the LEA instructions. In addition, registers may be used as offsets, as explained above. The program counter may be used as a pointer register with 8- or 16-bit signed offsets. As in relative addressing, the offset is added to the current contents of the program counter register to create the effective address.

The last example calculates the offset of TABLE and adds it to the current value of the program counter register. This value is then placed in the X register. Tables related to a particular routine will maintain the same relationship after the routine is moved, since addresses are calculated when the code is executed.

Position-independent code is not without disadvantages, the major bei ng that it generally takes 5 to 10 percent more space than nonrelocatable code. In addition, PIC usually takes 5 to 10 percent more time to execute. Typically, PIC would be used for utility programs where the run-time addresses are dynamically determined. This eliminates the need for a linking loader to perform a relocation operation. Common examples of this type of code would be machine-language utilities such as graphic routines and subroutines called by BASIC programs.

The MC6809E has several very interesting hardware features also. Referring to the signal descriptions of figure 2 , note that not only does the microprocessor have 16 address lines, 8 data lines, and an R/!W (read/write) line, but there are several other control lines. The MC6809E is synchronized to the video-display circuit by the two clock inputs, E and Q. These two clocks control internal operation of the microprocessor. Figure 4 shows typical timing diagrams for bus operations.

Three interrup t control lines, !NMI, !FIRQ, and !IRQ, allow peripherals to request (demand!) support. Each interrupt causes the microprocessor to retrieve a vector from a specific address and use it to begin executing instructions.

The Color Computer uses IRQ (interrupt request) and FIRQ (fast interrupt request) to support real-time clock input (driven by the horizontal and vertical sync signal from the VDG) and to auto-start read-only memory cartridges. The NMI (nonmaskable interrupt) input is reserved for use by the expansion port.

These interrupts function in different manners. The NMI cannot be disabled or postponed under software control and is useful in real-time interrupt-servicing disk transfers. The other two interrupts are maskable under software control. One is “faster” than the other in that a response to an FIRQ saves only the condition code register and the program counter on the stack. The other, IRQ, “stacks” all the registers, as does NMI. Separate interrupts were used for the PIAs (parallel in terface adapters) to provide independent vector addresses for the service routines, thereby minimizing the software overhead.

The interrupt vectors in the Color Computer are mapped to the top of the BASIC ROM by the SAM chip. These vectors point to locations in programmable memory starting at address hexadecimal 100. On reset, the BASIC program stores jump instructions in these locations which point to the interrupt-service routines. Each jump call consists of 3 bytes: the jump extended op code (hexadecimal 7E) and the address of the routine. If a particular interrupt is not being used, all 3 bytes of its jump call would contain 00. See table 3 for a map of the interrupt-service addresses.

To define a jump call, program the 3 bytes with the required jump instruction. For example, if the SWI (software interrupt) service routine is located at hexadecimal 8000, the SWI jump call should be loaded with 7E 80 00. The following BASIC program would load the SWI jump call with this vect or:

POKE 264,0
POKE 263,128
POKE 262,126

This example program defines the last byte of the jump call first, then the middle byte, then the first byte. This approach is required to prevent interrupt service until the jump call is completely defined. If the jump call was defined by starting with the first byte, an interrupt could be vectored to the wrong address. All interrupt-service routines should end with a hexadecimal 3B (Return from Interrupt op code) to restore the Color Computer to the proper state.

Two other MC6809E input-control signals used by the Color Computer are HALT and RESET. RESET is controlled by the pushbutton switch on the rear right-hand portion of the Color Computer. When the switch is pressed, RESET goes low to initiate a restart routine. The HALT input is connected to the expansion port. When HALT goes low, the MC6809E completes the current instruction, then releases the address, data, and R/!W lines to the high-impedance state. This allows another device, su ch as a DMA (direct-memory access) controller, to control the bus.

Since the microprocessor is not halted until completion of the current instruction, the external bus controller has to wait 20 bus cycles before driving the bus. This delay is required because the longest execution time for an MC6809E instruction is 20 cycles for a CWAI instruction ( see table 2 ).

This delay could have been minimized if the BA and BS lines were brought out to the expansion port. BA and BS (Bus Available and Bus Status) indicate one of four machine states. These four states and the BA and BS signal combinations are shown in table 4.

Of the four states, the Halt/Bus-Grant Acknowledge is the only one pertinent to the design of the Color Computer. The Normal state indicates that the microprocessor is executing code. The Synchronize Acknowledge state, which allows the processor to be synchronized to an external event, is not required in the Color Co mputer. Nor is the Interrupt Acknowledge state, which indicates that vector fetches are occurring.

Four other MC6809E signals were ignored by the Color Computer’s designers: TSC, AVMA, BUSY, and LIC. TSC (Three State Control) is used to put the buses into the high-impedance state for cycle-stealing operations.This type of operation is typically used for DMA or dynamic-memory refresh and is not needed in the Color Computer.

AVMA, BUSY, and LIC are intended primarily for use in multiprocessor systems (which the Color Computer is not). AVMA (Advanced Valid Memory Access) is the signal indication that the processor will use the bus during the next cycle. The BUSY output provides the “indivisible” memory indication required for a “test and set” operation (operations of this type are required for efficient multiprocessor support on a common bus). LIC (Last Instruction Cycle) indicates that the first byte of an op code will be latched at the end of the present bus cycle.

The MC6809E was th e best choice of the microprocessors available for use when the Color Computer was designed. The external clock inputs allow the microprocessor to be synchronized to the video display to allow interleaved memory accesses. In addition, the power of the MC6809E instruction set allows the efficient graphics drivers supported by the Extended BASIC.

The Video Display and the Memory Controller

The “Color” in Color Computer comes from the MC6847 Video Display Generator. This device can display information stored in memory using a variety of alphanumeric, semigraphic, and graphic modes. To understand how it works, refer to the signal description shown in figure 5. Normally the address lines DAO thru DA12 would be connected to a block of programmable memory (usually static devices such as MCM2114s) shared with the microprocessor. Depending on the mode selected, the VDG would read the memory and, taking the information off its data lines (DD0 thru DD7), it would format and s hift out video information to its companion part (the MC1372 Color Television Modulator) to be transmitted to a TV receiver.

This method of using the part is fine, but it has a few drawbacks. First, there needs to be a way to allow the microprocessor to write its output data to memory. This means that there must be three-state buffers between the microprocessor bus and the VDG bus (and logic to control them). A control pin on the VDG, Memory Select (MS), must be used to put the VDG’s address lines in the high-impedance state when the processor accesses the memory.

One side effect of this is that the VDG shift registers will be filled with the data from its data bus as usual, except that the address lines are under the control of the microprocessor, and so the data that gets sent out on the video lines is incorrect. This results in “sparkles” of random color on the TV screen and can be annoying when you are trying to move your TIE fighter out of enemy gunsights!

Second, there is only one bloc k of memory for the VDG to “look” at. In trying to implement computer animation, it would be nice to allow the microprocessor to draw one picture while another is being displayed. Then you would simply swap memory pages and, voila, the horse moves! You can’t do this with the system outlined above unless you resort to fancy hardware.

Of course, both of these problems can be overcome. We have seen it done with an entire board full of TTL (transistor-transistor logic) packages but this is expensive and not for the faint of heart. Fortunately, these problems have a solution in the form of another LSI device from–you guessed it–Motorola. The MC6883 SAM (Synchronous Address Multiplexer) is a 40-pin TTL part that marries the MC6809E and the MC6847 to some dynamic programmable memory.

SAM, the Synchronous Address Multiplexer

The little jewel called the SAM should really interest computer experimenters. In the first place, it provides the clock signals needed by the microprocessor. T he E and Q clocks are derived from the 14.31818 MHz crystal — they are normally 895 kHz — but this can be changed, as we will see. Secondly, the SAM also provides RAS (rowaddress strobe) and CAS (column-address strobe) signals for dynamic-memory refresh. As anyone who has tried to design a dynamic-memory board can tell you, it isn’t easy; and one of the hardest things is deriving RAS and CAS and hiding the refresh cycle from the processor. The SAM does it all and could do it even without a VDG. A complete memory board could be designed around this device even if you didn’t want a video display. A signal description of the MC6883 is given in figure 6.

To conserve the number of pins on a dynamic-memory circuit the address is multiplexed in 6-bit pieces (7 bits for 16 K-bit devices). The SAM takes all the microprocessor address lines, multiplexes them to the memory, and controls RAS, CAS, and WE (Write Enable). A typical read cycle is shown in figure 7.

The micro processor puts out an address to read a location in the dynamic memory. The SAM splits this address into the row address and the column address. First the row address is presented to the memory on the output lines Z0 thru Z5, and the falling edge of RAS causes the memory to latch this part of the address into internal decoders. The SAM then puts out the column address and drops CAS. This causes the memory device to latch the column address and decodes the location in the internal memory array. The memory’s stored data is then put on the data-output lines and through a buffer to the microprocessor.

Now, what about refreshing? Dynamic-memory circuits are made of small capacitor cells and, unless they are refreshed, the charge that represents the stored information will bleed off in a very short time. The memories are constructed such that merely accessing all the row addresses every 2 ms will keep the data alive. Usually this is done with counters that need only count from 0 to 63 (0 to 127 for 16 K-bit d evices). The trick is to hide this from the microprocessor.

In the MC6809E, this is possible because the microprocessor needs to access memory only during the time that the E clock is high, so all that must be done is to refresh the memories when E is low. The SAM also does this little chore.

There are two differences between a system that uses 4 K-bit circuits and one that uses 16 K-bit devices. First, the MCM4116 integrated circuits have an extra address line which must be connected to the Z6 output of the SAM. Second, the refresh counters in the SAM must be programmed to put out 128 refresh addresses for the MCM4116s instead of the 64 needed for the MCM4O27s. The SAM has to be programmed to do this. How this is done will be detailed later.

In the Color Computer, the change is simple. There are only two jumpers that need to be switched to select either 4 K-bit or 16 K-bit memory devices. One of these connects the seventh address line, and one is connected to a PIA input line. Upon reset, t he BASIC interpreter reads this bit and sets up the SAM for the type of memory indicated. That’s all there is to it.

So what does all this have to do with the VDG7 Since the VDG needs to be able to read memory to refresh the video screen, the SAM takes care of this, also. The address lines of the VDG are not connected at all in this system. Rather, the SAM is programmed into the same mode as the VDG and duplicates the timing of the VDG’s address bus, except that it accesses memory to refresh the VDG during the E low time (so that the VDG accesses are transparent to the microprocessor). Since there is no possibility of a bus fight between the processor and the VDG, there is no need to deny the VDG access to the memory and the screen remains glitchless.

The full timing is shown in figure 8 .The SAM usually provides memories with the address needed td access the data for the VDG to output as video. During the active display time (one frame of video) these addresses automatically refr esh the memory devices. During the vertical retrace time, the SAM puts out refresh addresses. The microprocessor can access the memory at any time E is high and is therefore not affected.

Programming the VDG

The VDG has 5 mode-control pins that determine how the address lines behave and how the data that is obtained from the memory is to be interpreted. In this system, these lines are connected to lines PB3 thru PB7 of PIA2. The data-output register for this device is located at address hexadecimal FF22. The microprocessor can write directly to this port to select the VDG mode. In fact, Extended Color BASIC has a statement, PMODE, to do just this.

The VDG has one alphanumeric mode (using its internal character generator or an external one), two semigraphic modes, and eight full-graphic modes. The modes and the way the mode-control pins must be programmed are shown in table 5.

The alphanumeric mode is the one used by BASIC to print on the screen. The V DG sequentially reads 512 bytes from memory f6r each TV frame. The data is interpreted as character codes, with the first byte corresponding to the top left corner (“home” position). There are 16 rows of 32 characters for a total of 512 characters on the screen. The character code is given in table 6.

Lowercase characters are displayed as inverted (light characters on a dark background). This is done by tying bit 6 (DD6) of the VDG to the INVERT pin. Because this bit is set in all lowercase numbers, they are inverted.

To support the SET and RESET commands in Radio Shack’s Level I BASIC, data line DD7 on_the VDG is connected to the alpha/semigraphic pin (A/S). Whenever this bit is set, the VDG will interpret the data in the manner shown in table 5, under the semigraphic-4 mode. Instead of displaying a character, a colored block that is divided into four smaller blocks is displayed. The code in the byte read from memory determines which pattern of blocks is sh own and what color it is. Using the smaller element within the block as a pixel, this gives a grid of 64 by 32 blocks, which are the dimensions of the SET and RESET commands. The other semigraphic mode is similar to this, but each large block is divided into six blocks (instead of four) and has a choice of two sets of four colors, controlled by the CSS (Color Set Select) pin. (Refer to the semigraphic-6 mode in table 5. )

The remaining eight modes are of the bit-mapped graphic type. They require 1, 1.5, 2, 3, or 6 K bytes of memory, depending on the mode. Basically, the data in memory is interpreted as pixels. In the four-color modes (1-C, 2-C, 3-C, and 6-C), each pixel is represented by 2 bits, selecting one of four colors. The set of colors is selectable by the CSS pin. In the two-color modes (1-R, 2-R, 3-R, and 6-R), each bit is mapped one-to-one on the screen. If the bit is set, the pixel is colored, and if it is not set, the pixel is black. The color set can be changed so the pix el can be either buff or green; color sets are controlled by the CSS pin. The resolution of these modes varies from 64 by 64 to 256 by 192 pixels horizontal and vertical respectively.

To use these graphic modes, you simply program the VDG by writing the mode code into the PIA output register, and write to the “screen memory” addresses. The only problem is that the VDG’s address lines are not connected to any memory. As mentioned before, the SAM provides the addresses and the VDG interprets the data from the memory, so the SAM must be programmed to be in the same mode as the VDG in order to get a meaningful display.

Programming the SAM

With a SAM~in the system, the memory map is pretty much fixed. The SAM directly decodes the addresses from the processor to access memory, and provides device selects for the rest of the sytem on the SO thru S2 pins. These pins are decoded by a 3-to-8 decoder (74L5138) to get the active-low select signals for the rest of the system. Refer to the memory map shown in figure 9 .

The reset vector and interrupt vectors at the top of the map are mapped from hexadecimal FFF2 thru FFFF to BFF2 thru BFFF. This allows these vectors to be stored in the 8 K-byte BASIC ROM beginning at address hexadecimal AOOO. The addresses of the two PIAs, the second ROM, and the off-board ROM cartridges are also shown in figure 9.

The block of addresses from hexadecimal FFCO to FFDF are the locations of the SAM registers. The SAM is programmed and its various options selected by writing to these locations. The data is immaterial since the data bus is not connected to the SAM. Each register bit has two unique locations, an even location and an odd one. Writing to the even location will clear the register bit. Writing to the odd location will set the bit. By encoding the bits, and accessing the appropriate locations, the SAM can be programmed.

The memory map in figure 9 shows the modes and the locations assoc iated with each. S stands for set and C for clear in the diagram. The programmable attributes include:

– VDG mode: mode of address lines during VDG refresh time.

– Display offset: the base address of the memory used by the VDG is specified here. This is the address of the pixel in the upper left-hand corner of the screen in graphic mode. Programmable in 1/2 K pages.

– Memory size: 4 K-bit, 16 K-bit or 64 K-bit dynamic memories or a full map of static memory and I/O.

– Microprocessor clock rate: can be set for 0.8, 1.8 MHz or address-dependent rate.

– Page: allows two 32 K-byte memory pages between hexadecimal 0000 and 7FFF.

The VDG mode bits in the SAM must be programmed to match the mode selected for the VDG on its mode pins. Table 7 shows the correspondence between the SAM and the VDG modes. If the two modes do not agree, interesting results can be obtained. Some of the se “mixed” modes include graphics mixed with alphanumerics.

The VDG address offset specifies where the SAM should start the address counters. Figure 10 shows the address sent by the SAM as a function of this offset. This allows the VDG display to be “paged” through memory in 512-byte pages, allowing fast page swapping for animation, etc. On reset, BASIC will set the offset to hexadecimal 400 so all the screen output of the BASIC interpreter is at locations hexadecimal 400 thru 5FF. Try POKEing to these locations to use the alphanumeric and semigraphic modes.

The Extended BASIC supports the higher-resolution graphics and can also allocate more memorY for multiple pages, up to eight. It provides graphic operations, such as LINE, DRAW, and CIRCLE, that are fast enough to allow the programming of real-time games using the joysticks as controllers.

Memory type is self-explanatory. The SAM must be programmed for the type of memory devices used in the system to produce the correc t timing signals. If 16 K-bit circuits (MCM4116 or the equivalent) are used, pin 35 can be used for RAS1. This is needed to select a second bank of devices to provide 32 K bytes of memory. One way to do this on the Color Computer is to piggyback a second set of eight MCM4116s on top of the existing integrated circuits, paralleling all the pins except for the RAS pin. When this is jumpered to pin 35 on the SAM, the system then has 32 K bytes of user-programmable memory.

The microprocessor clock rate is also programmable. There are three modes, as shown in figure 9 . In mode 0, the clock rate is fixed at one-sixteenth the crystal frequency. In this case, that is 895 kHz. Mode 2 gives a fixed rate of one-eighth the crystal frequency, or 1.8 MHz. This can be used with an MC68BO9E, a 2 MHz version of the microprocessor. However, there are no memory or VDG addresses output in this mode, so don’t use it.

Mode 1 is the most interesting. It gives a dual-rate clock of 895 kHz or 1.8 MHz dep ending on the address used in the bus cycle. When the processor accesses addresses from hexadecimal 0000 to 7FFF and FF00 to FF1F, the lower rate is used, allowing for slower memory and peripherals. When all other addresses are accessed, the processor runs at 1.8 MHz. Using fast ROMs will almost double the speed of the system because a majority of the microprocessor’s memory references are to fetch opcodes. If you want to try this, execute the following BASIC statement:

POKE 65495,0

This will set bit R0 of the microprocessor rate register at location hexadecimal FFD7 and put the SAM into the dual-rate mode. If your microprocessor can run at the higher speed (a pretty good bet), you will see the changing-color cursor flashing about twice as fast as normal. Your BASIC programs will now run about twice as fast, too. There is one problem, though — don’t try to use the SOUND, CLOAD, or CSAVE statements in this mode. The PIA used by these statements is at location hexadecimal FF20 and it will p robably not run at the higher speed.

The other two registers do not apply to the Color Computer. The Map Type bit chooses a mixed programmable/read-only type of system such as the Color Computer or a fully programmable system such as a disk-based one. The Page bit allows two 32 K-byte pages of memory to be accessed between locations hexadecimal 0000 and 7FFF. This can’t be done on this system.

Keyboard Scanning

The keyboard is configured as an 8 by 7 matrix of keys. The Color Computer uses a software routine to encode the keyboard in a manner similar to that of the TRS-80 Model I. This is done by shifting a 0 through the B port of PIA IC8. The B port drives the 8 rows of the keyboard; the 7 columns are connected to the A port of ICS. The A port has internal pull-up resistors that provide a logic 1 level unless a key is depressed. When the shifted 0 occurs on the row of the closed key contact, the low level is passed to port A. By repeating the scanning procedure several times, debounced inputs are recognized.

If you need to monitor the keyboard during a program, a function (INKEY$) is provided. The BASIC statement

                        A$ = INKEY$

will return a character if a key is closed when the function is called. An example use of this function would be to monitor the keyboard during a “Tank” game for directionkeys and a “Fire” key. This would allow you to play a “Tank” game without having a set of joysticks.

Digital-to-Analog Converter

The D/A (digital-to-analog) converter allows the Color Computer to send analog waveforms. These signals are used for the cassette output, sound to the video modulator, and as a reference signal for A/D (analog-to-digital) conversion.

Six of the eight port A lines are configured as outputs and buffered to drive a resistive adder network for analog signal generation, as shown in figure 11 . The resultant analog signal ranges from 0 V to +5 V in 78 mV steps. This type of converter is accurate to +/-1/2 the least significant bit, or in this case +/-39 mV.

Cassette Port

The Color Computer has a cassette port which connects to a low-cost recorder. Motor-control capability is included that allows the cassette recorder to be started or stopped as required. The motor can be turned on and off with the statements MOTOR ON and MOTOR OFF. This allows the user to fast-forward or rewind tapes without having to unplug connections to the Color Computer.

Data is output to the recorder from the D/A converter. If an oscilloscope is connected to the data-output line, pin 5 of the cassette jack, an 800 mV 1500 bps signal will be seen.

When data is loaded from the cassette recorder, the playback signal can be routed to the modulator sound input in a manner that allows you to monitor the cassette signal via the speaker of a television set. This is done with the AUDIO ON and AUDIO OFF statements.

The cassette data-output can be used for an analog out put level because the D/A converter can be controlled by a user program. The motor-control relay can be used to control loads up to 6 V DC at 500 mA.

Joystick Interface

Two joystick ports are provided which allow full x,y directional control. Each joystick has a pushbutton for use with games (eg: paddle control for the Pinball game). Each joystick consists of two potentiometers, each connected across +5 V and ground. The wiper of each potentiometer is connected to the input of an analog multiplexer controlled by PIA 1C8. The voltage level from each of the four potentiometers is routed to the A/D converter to get a digital value for the position. This value will range between 0 and decimal 63. The JOYSTK(j) function returns the digital value of the joystick position.

Analog voltage levels from the joysticks are digitized using a successive-approximation technique. This is one of the more popular methods of A/D conversion. The 6-bit D/A converter is used in a feedback loop to ge nerate a known analog signal to which the unknown analog joystick input is compared. This technique is not as fast as a flash converter, nor is it as slow as a binary counter.

Figure 12 shows the block diagram for the successive approximation converter circuit. Figure 13 shows a flowchart for this approach. The D/A converter inputs are controlled by the microprocessor to form a successive-approximation register. The analog output is compared to the analog joystick input by the MLM339 comparator whose output is monitored by the MC6809E.

At the start of a conversion the MSB (most significant bit) of the D/A converter is turned on by the microprocessor, producing an output equal to half the full-scale value. This output is compared to the analog input and if it is greater than the joystick voltage, the microprocessor turns the MSB off. However, if the D/A output is less than the joystick voltage, the MSB remainson.

Following the trial of the MSB, the next m ost significant bit is turned on and again the comparison is madebetween the converter’s output and the joystick voltage. The same criteria apply and this bit is either kept on or turned off. This procedure of testing each bit continues four more times until the 6 bits of the D/A converter have been set to the proper level.

Once the conversion is complete the microprocessor reads the joystick output by reading port A of PIA 1C4. The internal structure of port A allows a read of the port to sample the output logic levels. Now the Color Computer has the digital value for the joystick voltage. The time necessary to do this conversion is constant and does not vary with the analog voltage level.

Note that the Color Computer has an on-board A/D converter that accepts a signal between +5 V and ground and can digitize it with less than a 40 mV error. This means you can use the appropriate joystick inputs to monitor various analog voltages. The switch inputs are connected to the PIA (the left switch to 1C8 pin 3, PAl; and the right switch to 1C8 pin 2, PAO). You can write a progam to monitor these bits for use with external devices. Figure 14 shows the connectors for the joysticks (which are not shown in the TRS-80 Color Computer Operation Manual).

RS-232 Interface

An RS-232 interface is also provided. This allows you to connect all manner of devices to the Color Computer. The standard RS-232 Transmit Data, Receive Data, and Carrier Detect signals are provided. This is the fundamental signal subset used by most devices. Tandy sells an off-the-shelf line of printers and a modem that are readily usable.

Expansion Port

The expansion port provides the capability to interface almost anything to the Color Computer. Table 8 lists the pins and their functions. Note that the entire address bus is brought out. There is also a decode-defeat pin which disables the 74L5138 that decodes ROMs and peripherals. This allows the expansio n port to redefine the memory map. For instance, a flip-flop could be toggled to remove the BASIC and Extended BASIC ROMs from the memory map and replace them with programmable memory. A disk-controller board could also contain 48 K bytes of memory to fill the system from address hexadecimal 0000 to FF60.

The Vector Graphic company makes a wire-wrap prototype board (part number 4609) that fits the expansion connector of the Color Computer. This allows you to build your own peripheral boards. We are working on an interface to the General Instrument “Cricket” sound generator. The output from this circuit can be routed to the video modulator through a pin on the expansion connector. If you want, you can also build your own game cartridges. If you want them to auto-start like the Tandy cartridges, connect pins 7 and 8 together. This runs the Q clock into the CB1 input of PIA 1C4, causing an FIRQ interrupt. The FIRQ interrupt-service routine jumps to hexadecimal COOO and starts execution. There is also a dev ice select on pin 32 that is decoded from hexadecimal C000 to FEFF.

Summary

We have tried to completely describe the architecture of the Color Computer and deduce the reasoning behind the design trade-offs. Tandy certainly is to be complimented on the amount of “bang for the buck” — every part is fully used and several innovative design ideas are evident. We believe that the Color Computer has the capability to surpass the Model I in sales.

In a later article we will take a detailed look at the Extended BASIC and discuss its capabilities. We are currently implementing several popular video games in BASIC. Once the algorithms are proven, we plan to convert them to machine language to increase the speed, although with the power of the Extended BASIC we may not have to.

Table 1

List of integrated circuits used in the TRS-80 Color
Computer. Large-scale integration reduces the number of devices
necessary to build in sophisticated capabili
ties, and improves
reliability. All circuits used are manufactured by Motorola.

Number              Device
Part        of Pins  Quantity   Number          Description
  

MC6809E       40        1         1          Microprocessor
MC6821        40        2         2,3        Parallel Interface Adapter
MC6883        40        1         4          Synchronous Address Multiplexer
MC6847        40        1         5          Video Display Generator
MCM68A364     24        2         6,7        8 K-byte Read-Only Memory
MCM4027       16        8         8 thru 15  4 K-bit Programmable Memory
MC74LS138     16        1         16         3-bit Decoder
MC74L802      14        1         17         Quad 2-Input NOR Gate
MC74L8244     20        1         18         Octal Buffer/Line Driver
MC74L8273     20        1         19         8-bit Latch
MC14050B      14        1         20         Hex Noninverting CMOS Buffer
MC14529B      16        1         21
         Dual 4-Channel Analog
MC1372        14        1         22         Color-Subcarrier Modulator
MLM339        14        1         23         Quad Voltage Comparator
MC723C        14        1         24         Voltage Regulator
MC78M12        3        1         25         Voltage Regulator
MC79M12        3        1         26         Voltage Regulator
MC79M05        3        1         27         Voltage Regulator
UM1285-8      NA        1         28         ASTEC Video Modulator

Table 2

The 6809 instruction set.

8-BIT OPERATIONS


MNEMONIC       DESCRIPTION


ABX                    Add B register to X register unsigned.
ADCA, ADCB             Add memory to accumulator with carry.
ADDA, ADDB             Add memory to accumulator.
ANDA, ANDB             AND memory with accumulator.
ANDCC                  AND immediate with condition code register.
ASLA, ASLB, ASL        Arithmetic shift left
 accumulator or memory.
ASRA, ASRB, ARS        Arithmetic shift right accumulator or memory.
BITA, BITB             Bit test memory with accumulator.
CLRA, CLRB, CLR        Clear accumulator or memory.
CMPA, CMPB             Compare memory with accumulator.
COMA, COMB, COM        Complement accumulator or memory.
DAA                    Decimal Adjust A accumulator.
DECA, DECB, DEC        Decrement accumulator or memory.
EORA, EORB             Exclusive OR memory with accumulator.
EXG Ri, R2             Exchange R1 and R2.
INCA, INCB, INC        Increment accumulator or memory.
LDA, LDB               Load accumulator from memory.
LSLA, LSLB, LSL        Logical shift left accumulator or memory.
LSRA, LSRB, LSR        Logical shift right accumulator or memory.
MUL                    Unsigned multiply (8 bit by 8 bit = 16 bit).
NEGA, NEGS, NEG        Negate accumulator or memory.
ORA, ORB               OR memory with accumulator.
ORCC                   OR immediate with condition code register.
P
SHS (register list)   Push register(s) on hardware stack.
PSHU (register list)   Push register(s) on user stack.
PULS (register list)   Pull register(s) from hardware stack.
PULU (register list)   Pull register(s) from user stack.
ROLA, ROLB, ROL        Rotate accumulator or memory left.
RORA, RORB, ROR        Rotate accumulator or memory right.
SBCA, SBCB             Subtract memory from accumulator with borrow.
STA, STB               Store accumulator to memory.
SUBA, SUBB             Subtract memory from accumulator.
TSTA, TSTB, TST        Test accumulator or memory.
TFR Ri, R2             Transfer register R1 to register R2.

16-BIT OPERATIONS


MNEMONIC         DESCRIPTION


ADDD                     Add to D accumulator.
SUBD                     Subtract from D accumulator.
LDD                      Load D accumulator.
STD                      Store D accumulator.
CMPD                     Compare D accumulator.
LDX, LDY, LDX, LDU       Lo
ad pointer register.
STX, STY, STS, STU       Store printer register.
CMPX, CMPY, CMPU, CMPS   Compare pointer register.
LEAX, LEAY, LEAS,  LEAU  Load effective address into pointer register
SEX                      Sign extend
TFR register, register   Transfer register to register.
EXG register, register   Exchange register to register.
PSHS (register list)     Push register(s) onto hardware stack.
PSHU (register list)     Push register(s) onto user stack.
PULS (register list)     Pull register(s) from hardware stack.
PULU (register list)     Pull register(s) from user stack.

INDEXED ADDRESSING MODES


MNEMONIC        DESCRIPTION


0, R           Indexed with zero offset.
[0, R]         Indexed with zero offset indirect.
,R+            Autoincrement by 1.
,R + +         Autoincrement by 2.
[,R + +]       Autoincrement by 2 indirect.
,- R           Autodecrement by 1.
,- - R         Autodecrement by 2.
[,- - R]       Autodecrement by 2 ind
irect.
n, P           Indexed with signed n as offset (n = 5, 8, or 16 bits).
[n, P]         Indexed with signed n as offset indirect.
A, R           Indexed with accumulator A as offset.
[A, R]         Indexed with accumulator A as offset indirect.
B, R           Indexed with accumulator B as offset.
[B, R]         Indexed with accumulator B as offset indirect.
D, R           Indexed with accumulator D as offset.
[D, R]         Indexed with accumulator D as offset indirect.

NOTE:

R = X, Y, U, or S; P = PC, X, Y, U, or S.
  Brackets indicate indirection. D means use AB accumulator pair.


6809 RELATIVE SHORT AND LONG BRANCHES


MNEMONIC        DESCRIPTION


BCC, LBCC        Branch if carry clear.
BCS, LBCS        Branch if carry set.
BEG, LBEO        Branch if equal.
BGE, LBGE        Branch if greater than or equal (signed).
BGT, LBGT        Branch if greater (signed).
BHI, LBHI        Branch if higher (unsigned).

BHS, LBHS        Branch if higher or same (unsigned).
BLE, LBLE        Branch if less than or equal (signed).
BLO, LBLO        Branch if lower (unsigned).
BLS, LBLS        Branch if lower or same (unsigned).
BLT, LBLT        Branch if less than (signed).
BMI, LBMI        Branch if minus.
BNE, LBNE        Branch if not equal.
BPL, LBPL        Branch if plus.
BRA, LBRA        Branch always.
BRN, LBRN        Branch never.
BSR, LBSR        Branch to subroutine.
BVC, LBVC        Branch if overflow clear.
BVS, LBVS        Branch if overflow set.

6809 MISCELLANEOUS INSTRUCTIONS


MNEMONIC        DESCRIPTION


CWAI              Clear condition code register bits and wait for interrupt.
NOP               No operation.
JMP               Jump.
JSR               Jump to subroutine.
RTI               Return from interrupt.
RTS               Return from subroutine.
SEX               Sign extend B register into A register.
SWI, 5W12, 5W13   Software inter
rupts.
SYNC              Synchronize with interrupt line.

Table 3

Interrupt vectors for Color Computer BASIC. At the reception
of an interrupt, control is transferred to a service routine
via a call to an address stored near the top of the 4 K address
space (occupied by the BASIC ROM). The address points to a
3-byte jump instruction (loaded into programmable memory when
BASIC is initialized); that, in turn, points to an interrupt-
handling routine.

Contents of
             Address of       Indirect      Indirect
             Interrupt        Routine       Routine
Interrupt      Vector       Call Address      Call
 Source     (hexadecimal)   (hexadecimal) (hexadecimal)


Reset           FFFE            A027          none      direct call to restart
NMI             FFFC            0109        undefined   not used
SWi             FFFA            0106        undefined   not used
IRQ             FFF8
            010C          A9B3      Extended BASIC uses
                                                        894C to update real-
                                                        time clock.
FIRQ            FFF6            010F          A0F6
SWI2            FFF4            0103        undefined   not used
SWI3            FFF2            0100        undefined   not used

Table 4

The four possible machine states. The Bus Available and Bus
Status signals can be decoded to detect when the bus is not
being used by the processor.

Bus Available          Bus Status        Machine State
  Signal                 Signal


   low                     low           Normal (running)
   low                     high          Synchronize Acknowledge
   high                    low           Interrupt Acknowledge
   high                    high          Halt/Bus-Grant Acknowledge

Table 7

Mode correspondence between the SAM and the VDG.

Synchronous Address
       Mode             Video Display Generator Signals    Multiplexer Signals
                                     GMO
                        G/A    GM2     GM1   EXT/I CSS     V2     V1    V0


Internal alphanumeric    0      X       X      0    x      0       0    0
External alphanumeric    0      X       X      1    X      0       0    0
Semigraphic-4            0      X       X      0    X      0       0    0
Semigraphic-6            0      X       X      1    X      0       0    0
Full graphic 1-C         1      0       0      0    X      0       0    1
Full graphic 1-R         1      0       0      1    X      0       0    1
Full graphic 2-C         1      0       1      0    X      0       1    0
Full graphic 2-R         1      0       1      1    X      0       1    1
Full graphic 3-C         1      1       0      0    X      1
       0    0
Full graphic 3-R         1      1       0      1    X      1       0    1
Full graphic 6-C         1      1       1      0    X      1       1    0
Full graphic 6-R         1      1       1      1    X      1       1    0
Direct memory access     X      X       X      X    X      1       1    1

Table 8

Signals available at the expansion port.

Expansion Port Pin Description

pin   function            pin    function

 1    -12V                 2      +12V
 3    HALT                 4      Nonmaskable Interrupt
 5    RESET                6      E
 7    Q                    8      CB1 of 1C4
 9    +5V                 10      DO
11    D1                  12      D2
13    D3                  14      D4
15    D5                  16      D6
17    D7                  18      RIW
19    AO                  20      Al
21    A2                  22      A3
23    A4                  24      A5

25    A6                  26      A7
27    A8                  28      A9
29    A1O                 30      All
31    A12                 32      C000 thru FEFF
33    Ground              34      Ground
35    Analog In           36      FF40 thru FF5F CS
37    A13                 38      A14
39    A15                 40      Decode Defeat

Table 5

illustration_link (198 Kbytes)

Video Display Generator Modes

Table 6

illustration_link (135 Kbytes)

Codes for the characters stored in the VDG’s internal character generator. THe loewr section contains inverse-video characters, dark characters on a light background.

Figure 1

illustration_link (195 Kbytes)

Block diagram of the Radio Shack Color Computer. Although a detailed schematic diagram is not available, the connection of the main components can be readily determined. Note that the use of large-scale integrated circuits (the microprocessor, SAM dynamic-memory handler, video-display gen erator, and parallel port interfaces) means that a minimum number of components is necessary to build this flexible computer.

Figure 2

illustration_link (108 Kbytes)

Pin description of Motorola’s MC6809E microprocessor. The device has several 16-bit instructions that, coupled with ease of programming and speed, make for a very powerful 8-bit processor.

Figure 3

illustration_link (146 Kbytes)

Registers available in the 6809. Similar in architecture to the 6800, the 809 has three extra registers to facilitate memory accesses: a direct page register, a user stack register, and a second index register. The instruction set is also more robust, with the addition of 16-bit add, subtract, and multiply operations.

Figure 4

illustration_link (177 Kbytes)

Timing diagrams for 6809 bus operations. As with the 6800, both memory and peripherals area accessed in the same way and share the same address space. The complete instruction cycle for reads (figure 4a) and writes (figure 4b ) is the same: approximately 1.1 microseconds.

Figure 5

illustration_link (72 Kbytes)

Pin description of Motorola’s MC6847 Video Display Generator. In concert with the Synchronous Address Multiplexer (see figure 6), this device interprets the contents of a block of memory to create a color display (using either an internal character generator or an external one). The output signal is converted to composite video by an MC1372, whyile a device built of discrete components modulates the signal to radio frequencies for reception on a standard television.

Figure 6

illustration_link (60 Kbytes)

Pin description of Motorola’s MC6883 Synchronous Address Multiplexer. This device provides the complex timing signals required by the microprocessor and for refresh of dynamic memories, as well as multiplexing addresses going into the memories. The various programmable modes of the video-display generator are provided for so that the SAM can help to refresh the video display. (This occurs during the portions of instruction cycles that the processor does not access memory.)

Figure 7

illustration_link (84 Kbytes)

Typical read cycle of 4116-type dynamic memory circuits. To reduce the number of pins required, the memory device interprets the address being accessed as two sets of 7 bits that come at different times over the same set of pins. The memory cells of each device are arranged in an array, and the two sets of bits define a row address and a column address. When a set of address bits is valid, either the CAS (column-address strobe) or the RAS (row-address strobe) signal is sent to latch in the respective portion of the address.

Figure 8

illustration_link (41 Kbytes)

Diagram of a typical dynamic-memory refresh cycle. The SAM provides every dynamic memory with a signal on each row address, as required, to refresh the data contained within.

Figure 9

illustration_link (135 Kbytes)

Memory map of the Color Computer address space. The general division of addresses is provided at the left, while the SAM programming registers and the processor-interrupt vectors are expanded at the right.

Figure 10

illustration_link (14 Kbytes)

Mapping of the video-display refresh address. The SAM uses a 7-bit offset to determine the start of video-display memory. This allows the use of 512-byte “pages” for display refreshing, making it possible to page through memory to create fast animation effects, etc.

Figure 11

illustration_link (95 Kbytes)

Schematic diagram of the Color Computer’s digital-to-analog converter. In a rather simple scheme, the output lines of a parallel port drive a resistive ad ding network to provide coversion. The resulting analog signals are used for recording on a cassette, providing the video modulator with sound, and also as part of the analog-to-digital converter.

Figure 12

illustration_link (107 Kbytes)

Diagram for the analog-to-digital converter circuit. Also used as the joystick interface, this circuit applies the successive-approximation method (see figure 14) to change analog signals to digital form.

Figure 13

illustration_link (118 Kbytes)

Flowchart of the successive-approximation algorithm used by the Color Computer.

Figure 14

illustration_link (42 Kbytes)

Pin designationas of the Color Computer joystick connectors. The connectors will mate with a standard 5-pin DIN plug, and any signal within the A/D converter’s range may be monitored under program control.

This post was submitted by adventure.

What is CoCoPAK? CoCoPAK is a software companion to Roger Taylor’s MicroSD Drive PAK. It will allow you to manipulate the SD card data off line, in a Micro$oft PC environment using a standard SD card reader connected to a USB port.

CoCoPAK Features:

- Import/Export of complete card images
- Import/Export of .DSK files to a RSDOS partition
- Creation/Deletion of Partitions
- Formatting new SD cards to work with the Drive PAK
- Formatting single partitions (effectively erasing only a partition)
- Displaying and saving complete RSDOS directories of a partition
- Displaying and saving card partition information
- Completely erasing SD cards so they can be formatting using other OS formats.
- A Card Snooper which gives you a window into the cards data

The Link:

http://pilot352.home.comcast.net/~pilot352/CoCoPAK/CoCoPAK_1.0.52.zip

This is the first release of the software. During the next few weeks, there may be one or two releases to fix bugs that people may find. After that, in a few months, Phase two will be released. This release will have several new features that I wanted to put in but didn’t have the time to do it now.

If you find a bug or think of a feature you would like to see added, you can post it here or send me an e-mail at support @ franklinlabs.com (Remove the two spaces).

If you want to complain about the software, you can also contact me through e-mail. Please use this address for complaints: itsfreeso@Idontcare.com.

Note to VISTA and above users:
Sorry, but this software will no work correctly under Vista or above. Micro$oft put a block on direct sector access to all dives. This prevents this software from working. It should work if you run it under the XP emulation under Vista or you may try it if you have full administrative rights. But, these methods are not guaranteed to work. Later releases may have this dilemma solved.

I would also like to thank Roger for his support in the development of this software and the creation of the MicroSD Drive PAK.

Pilot352

P.S. All comments welcome (as long as they are full of praise and gratitude!! ) )

CoCoPAK_1.0.52.zip (613 KB)

This post was submitted by pilot352.

I am specifically wondering how to mount partitions from within NitrOS9, so are there docs for OS9/NitrOS9 that deal with this?

This post was submitted by hhos.

Thanks,

Wal.

This post was submitted by CocoWal.

Thanks
Level 1

This post was submitted by Level 1.

Thanks Level 1

This post was submitted by Level 1.

Download the ZIP file here.

This post was submitted by memluk.

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=350363238088

Originally, I would have called it a bit better than average deal. That is, until it arrived.

I pulled it out of the shipping box and hear something rattling around inside. I looked, and the cartridge port cover was missing.

Guess what was sticking out of the cart port.

A 512K RAM board! I can’t freaking believe it! I don’t know if it’s all good, but I plugged it back into its socket, and the CoCo booted to BASIC.

So, I got basically got a 512K CoCo 3 for $26/$42 shipped.

I’m excited.

This post was submitted by jmetal88.

I am interested in buying a Tano Dragon 64 CoCo compatible computer because I heard that you can still buy one of these things new. My question is, can I use my CoCo disk controller and game cartridges on the Dragon computer? Are my CoCo stuffs compatible with this computer? This could be a deal breaker for me if it is not. I would appreciate it if there are Dragon 64 owners out there that would share their knowledge and experience regarding the Tano Dragon 64 computer. Thanks.

This post was submitted by cocopuff.

Thanks,

Wal.

This post was submitted by CocoWal.

This post was submitted by mikedubya.

Thanks.

This post was submitted by adventure.

Unfortunately, the two disk-based games I tried didn’t work.

The first was Gantelet, which loaded the first half and failed to load the second half. After I manually loaded the second half, I was able to run the game and get past the intro screens, where my wizard character was able to walk around. Problem is, the map never showed up. I was able to randomly hit items and walls and such, but the graphics on screen were pretty scrambled and I couldn’t see where I was going. Somehow I managed to bump into the exit to level two at one point, and the game froze between levels

The other game I tried was Wizard’s Den, which, again, loads up past the intro screen. On this one, though, the main game never started.

What I’m wondering is, since I had to load HDB-DOS via cassette cable, are these problems being caused by the disk games overwriting HDB-DOS in memory or something? Would I be able to get these games working if I had an EPROM board with the DriveWire version of HDB-DOS burned to it?

I only ask because I don’t think I’ll be able to afford a CoCo floppy controller or drive at any point in the near future. If I could, I would definitely prefer to play these games on real floppies.

This post was submitted by jmetal88.

0066 0019 TXTTAB RMB 2 *PV BEGINNING OF BASIC PROGRAM
0067 001B VARTAB RMB 2 *PV START OF VARIABLES
0068 001D ARYTAB RMB 2 *PV START OF ARRAYS
0069 001F ARYEND RMB 2 *PV END OF ARRAYS (+1)
0070 0021 FRETOP RMB 2 *PV START OF STRING STORAGE (TOP OF FREE RAM)
0071 0023 STRTAB RMB 2 *PV START OF STRING VARIABLES

My thought is this: If you poked these pointers to intentionally set all variable/string space to reside in a single address block that corresponds to a logical block that could be swapped out as needed by changing it’s MMU register, then could you not then have a basic program in memory that could use all “lower” memory in the machine below $60000?

For example, setting the pointer values above to define var/string space as extending from $6000-$7FFF would give you 8K total of variable storage. The associated MMU register for this memory space must by default contain 59, defining it as $76000-$77FFF. So if you change that MMU register to 0, 1, 2, or whatever, you are in essence swapping a new 8K block into the $6000-$7FFF space.

So, set it to block 0, load a bunch of variables, set it to 1, load a bunch more, oh I need something from before, switch it back to 0 and retrieve it, etc.

Only tricky bit would be to preserve the pointers above when you switch blocks. And maybe that’s too tricky to make any of this worth while. Still, it seems like a real simple assembly program might be able to keep a table of preserved pointers associated with each possible MMU block value, and save/restore them each time you request a new block of memory.

Ok, just rambling now, still thought it was kinda interesting though.

This post was submitted by sc.

Here is what is displayed when I run make/make all:

make[1]: Entering directory `/usr/src/toolshed/build/win32/libnative’
cc -I../../../include -c -o libnativegs.o ../../../libnative/libnativegs.c
../../../libnative/libnativegs.c: In function `_native_gs_fd’:
../../../libnative/libnativegs.c:89: error: structure has no member named `_fileno’
../../../libnative/libnativegs.c: In function `_native_gs_size’:
../../../libnative/libnativegs.c:140: error: structure has no member named `_fileno’
make[1]: *** [libnativegs.o] Error 1
make[1]: Leaving directory `/usr/src/toolshed/build/win32/libnative’

I am also having no luck building nitros9 from CVS. Something appears to be missing. Mamou is choking while compiling UUCPBB. symbol undefined on pass 2 errors for what should be defined os9 calls like F$Fork, F$Wait, and F$Exit.

I think that I am missing something. A component for Cygwin maybe.

Any help would be appreciated.

This post was submitted by willz88coco3.

I would like to know more about the “Skip Factor” on CoCo disks. First, here’s what I know, please correct me if I’m wrong on anything. Basic’s DSKINI has an optional parameter allowing the user to format the disk using a specified skip factor.
The Skip factor tells the floppy controller where to find a sector on a given track. This was designed to allow an optimized access to sequential read. By default, Basic uses “4″ as Skip Factor.
A “track” is physically a ‘circle’ on the disk. This circle is divided into sectors.
To demonstrate this, let’s illustrate the physical sector on a track:
Physical sector (01 to 18, then it wraps around back to 01, etc..)
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 (loop) 01 02 ..
When Basic finishes loading sector 01, by the time it has finished processing and gets ready to start reading sector 02, the disk has kept revolving so it is already on the middle of sector 03 or 04.
In order to read sector 02, the disk would have to complete almost a full spin and thus slowing down the read.
To this effect, the “logical sector” are interleaved, as I said for Basic the default skip is 4, so the layout might look like this:
Logical sector:
01 10 06 15 02 11 07 16 03 12 08 17 04 13 09 18 05 14

This means that after reading sector 01, the disk will be somewhere over sector 06 or 15. Waiting for sector 02 is very short since it is almost the next one.

I read somewhere that OS-9 uses a skip factor of 2, since it performs faster than basic.

Now my questions:
- Is using a skip factor of ’2′ the fastest possible disk access, since using a skip factor of ’1′ would leave no time between sector reads?
- How does the disk controller *knows* what is the skip factor on a given disk?
- Since ‘DSKCON’ routines doesn’t know or care about skip factor, it means that Basic’s ‘DSKINI’ has some special low level access directly to the controller hardware?
- Will any ‘skip factor’ work? i.e.: it would only be less than optimal, but it should no cause problem for Basic?
- How can I experiment with custom Skip Factor using Rainbow IDE, which creates a CoCo DSK using “DECB DSKINI” internally during build?
- Can a program detect what is the Skip Factor on a disk?
- About disk read speed: since a track is physically a circle on the disk, it means that outer tracks are longer than inner tracks. And since track capacity remains constant, it must mean the data on the shortest track will read faster?
- ..and if it reads faster, then sector skip time will be much shorter, thus the skip factor must be set according to the fastest sectors?

I did some quick test but I didn’t notice any speed difference between tracks, I am wrong?

This post was submitted by remz.

I’m looking to get a Deluxe Joystick for my CoCo 2 and the CoCo 3 I bought on eBay recently. I’d like the 26-3012B model with the two fire buttons and 6-pin connector.

I know there are a couple reasonably priced on eBay right now, but they’re in auction format, and I much prefer a straight sale as opposed to bidding and waiting.

I don’t have much spare cash right now, so I’m looking to spend in the $10 range (this might be a little negotiable), including shipping. For reference, the two I’m watching on eBay right now are at $7 including shipping and $13 including shipping. I’m hoping someone on here might be willing to part with one at around that price range. Obviously, this will depend on how close you are to me, and how light you can make the package.

My zip code is 74006, so you can make the necessary calculations in order to determine if you can offer me such a deal.

Thanks!
You can reply via comment or send an e-mail to jmetal88@sbcglobal.net.

This post was submitted by jmetal88.

This post was submitted by sc.

Updated to include DE-1 Expansion Connectors and 1Mx16 SRAM

This is an update to the GIMEchip.com E.A.G.L.E. library which includes the DE-1 Expansion Connectors and some additional Static RAM chips including a 1Mx16 10nS part for my DE-1 Expansion Board Project. -John
The “.zip” file is here.

- TRS-80 Color Computer model 26-3003 (32 KB of RAM and new keyboard)
- joystick catalog #26-3008
- cassette recorder CTR-80A
- disk drive FD 500
- printer DMP 100
- various cassettes, discs, and program paks with documentation
- magazines (Rainbow from the 1980s)
- books on BASIC programming

email me: doug94114@yahoo.com

This post was submitted by rdrsfo.

Thank you

This post was submitted by mrnukem.

I wanted to design this with common components that are likely to found in your “junk box a.k.a. Parts Bin”, so I didn’t use any PLD’s and such. I also used two 16C550′s in the design as it is more likely that you would have them lying around as opposed to the dual 16C552. This design could be improved significantly by using a single DUART chip and replacing the four MAX232′s with a single chip that houses the equivalent of four MAX232′s. However, as I said, I wanted to design with common components that can likely be had cheaply in bulk from eBay if you don’t have them already. That being said, I’ll describe the design.

Each of the two UARTS requires 8 consecutive memory locations, bringing the total to 16 for both UARTS. Where in the CoCo’s memory map are you likely to find 16 available consecutive memory locations? The answer is the SCS* signal, normally used by the Disk Controller to access the drive select register and the FDC chip. This signal is mapped to $FF40-$FF5F, but the Disk Controller only needs the $FF4x range (and it doesn’t even use the entire 16 bytes in the $FF4x range.) So what I have done is split the SCS* signal in half. The $FF4x range is passed through to the Cartridge header contained on this board. The $FF5x range is used by the two UARTS. You can plug the Disk Controller into this card and this card into the CoCo. This is useful if you don’t have an M.P.I.

Since the INTERRUPT outputs of the 16C550′s are active high and NOT open-collector, I have used a 7406 O.C. inverter to invert the interrupts and to allow them to be “wire-or’ed” before going to the IRQ* pin of the CoCo. All 8 signals on the DB-9 Serial Connectors are supported, though it is unlikely that you’ll need some of them such as RI and DCD.

UART0=$FF50-$FF57
UART1=$FF58-$FF5F

For info on programming the UARTS, please see the datasheet here.

The board layout as a “.pdf” is here.
The schematic as a “.pdf” is here.
The E.A.G.L.E. “.sch” and “.brd” files are in the “.zip” file here.

This schematic and board layout was completed in under six hours (not counting breaks, about four hours) and so needs to be scrutinized and examined for errors. If you spot any potential problems, let me know and I’ll correct them. If you want to prototype and debug this card feel free to do so. If you get it working and want to produce it – go ahead. If you improve the card by using a Duart and a “quad” max232 type level translator, please post your work for all to enjoy.

Now, I’ll start work on the general purpose I/O, A/D, Control card request.

Thanks – John

Also, I remember finding source code for what looked like all of the modules in NitrOS9 but, at present, I am unable to find them again. Does anyone know where I can find these?

This post was submitted by hhos.

Thanks to everyone that has kept up with the technology!

Level 1

This post was submitted by Level 1.

All known Disk Images of Dragon Data’s Basic09 are corrupt (at least all that I’ve come across). Basically, the file system is seeing some of the files, such as RUNB, as if they were DIRectories. With the help of a binary disk editor, I modified the attributes of the affected files directly. I then used DSAVE to copy the files off to a freshly formatted 180k diskette. The result is that which you see here – a 100% error free diskette image of Tano/Dragon Data’s Basic09 diskette, and yes, it works fine with any model of the CoCo under OS-9 Level I or II. The original image that I worked from was the .VDK image from the Dragon Data Archive – as far as I know, that image is still corrupt. You may use this corrected .os9 image to generate a new .VDK image if required.
Disk Image Here:Dragon-Basic09.zip

Please take a moment to visit the above link and read the post before reading this one. Thanks – John

Okay, are you back from reading the previous post? Good – now let’s continue:

If you’ve been reading my posts, you may remember reading about my health and how it has affected my memory. I bring this up because, if you’ve read my previous Stereo Pak Article (the link above), then you will note that I mentioned that I needed to update the Stereo Pak design to include a couple of amplifying buffers to boost the output up to near 1v p-p. I also mentioned that I needed to include a mixing circuit to mix the left and right channels and feed those back to the CoCo’s SND input. Well, when I went to start on these improvements, I found that I had already designed version 2.0 of the Stereo Pak which not only included those enhancements, but also included a MONO output in addition to the two Stereo Outputs. For the life of me, I can’t remember when I developed this Version 2.0 schematic, but there it was, in my projects folder. All in all, I suppose it’s a good thing, because I can now upload version 2.0.

Now, all that is included in this upload is a “.pdf” file of the version 2.0 schematic. I haven’t did the board layout yet. Given my current memory woes, I do need to verify the component values and circuitry to be certain that they will generate the proper signal levels. After that, I will do the PCB layout and upload the complete project as a “.zip” file. For now though, you may download the pdf for your perusal.

Please let me know if you spot any obvious errors so that I may correct them. Thanks – John

Download the “.pdf” here.

This is the beginning of an EAGLE Library for the CoCo & Dragon Computers.

This is a library for the EAGLE Schematic and Printed Circuit Board software. It is intended to contain parts useful in the creation of hardware for the TRS-80 Color Computer. Some parts were borrowed from other libraries (such as the CoCo and Dragon Libraries on MaltedMedia’s ftp) and other components were created by me. I have even included a GIME in the library. I know you can’t buy a GIME, but if you happen to have one and want to use it in a project – the part is in the library. This library will be ever evolving and if you have a specific part that you need that’s not in the library – let me know – If I can get the specs from a datasheet – I can create the part. The reason that I am working on this library is in the hopes that it will entice others to create new CoCo hardware. Thanks – John
YOU CAN DOWNLOAD THE LIBRARY HERE: GIMEchip CoCo EAGLE Library (GIMEchip.com Work In Progress – Not Even Beta Yet)

Thanks

This post was submitted by Level 1.

Stereo Sound And The TRS-80 Color Computers

Designing The Ultimate Stereo Sound Pak For The Tandy Radio Shack TRS-80 Color Computer 1, 2 and 3 (CoCo 1, 2 and 3).
By: J&R of GIMEchip.com

Phone HOME.

DISCLAIMER #1:
I am not a genius. As such, all of my writings are susceptible to errors and mistakes, due to the whole “being human” syndrome. I present this information to the Vintage Computing Community as a whole, and the Tandy Radio Shack TRS-80 Color Computer Community in particular. Please note that I am not responsible for any damages of any kind that you may incur from the use of this information. If you do not agree with this statement, please stop reading… now. Otherwise, I invite you to continue…
DISCLAIMER #2:
The following article is provided for informational purposes only. Any attempt to modify your computer without the proper skills to do so may void your computer. Any attempt to modify your computer without unplugging it first may void you. This Information is provided “as-is” with no guarantee of fitness for any purpose, either explicit or implied. We disclaim any and all responsibility for losses incurred through the use of this information. By using this information, you are deemed to have accepted these conditions of use, and you agree NOT to sue us.

CLARIFICATION:
The preceding disclaimers state as plainly as possible that if you decide to make use of any of the information contained within this document that you do so at your own risk. Designing hardware for the CoCo (ColorComputer) is a hobby of mine and is not motivated by any desire of profits. As this is a not for profit venture, obviously I can’t afford not to disclaim the use of this information.

This Article is Copyright ©23 February 2010, Gimechip.com, All Rights Reserved. (but, like all my other designs, you guys know you can use it if you want to .)

THE FOLLOWING TEXT WAS WRITTEN 23 FEBRUARY 2010:

Two days ago, during a rough thunderstorm, my internet connection was interrupted. In this day and age, what is there to do, if not browse the internet? Obviously, this resulted in almost immediate boredom. In an attempt to alleviate said boredom, I decided to design a CoCo hardware product. Way back in 1994, my Father designed a CoCo Stereo Sound Card that was compatible with the Tandy “Orchestra 90/CC” and the Speech Systems “Stereo Composer”. It had the added advantage of intercepting sound output to port $FF20 (the CoCo’s 6-bit DAC) and outputting this to both Stereo Channels Simultaneously. My Father basically used the Orchestra 90/CC Schematic, adding the required additional circuitry to decode the two Stereo Composer Channels and the Mono ($FF20) Channel. It was a bulky device, but functioned as intended. However, one caveat – If it was plugged into a Multi-Pak, the $FF20 channel would not work because the Multi-Pak’s data buffer is only enabled on $FF40-$FF7F. Dad had mentioned plans to alleviate this caveat, as well as adding support for the Single-Bit Sound Output (bit 1 of $FF22). I decided that I would do a complete re-design of Dad’s idea, without using the Orchestra 90/CC Schematic – after all, I would be using a GAL chip to reduce the circuitry required (I wanted to fit this on a 16 Sq. In. PCB). After working all night (my internet didn’t return until about 5:30 A.M.), I completed a design and board layout which I believe will function. Please note though, that none of this has been tested. I leave it up to my readers to point out any errors in this design, such that I may correct them.

To start the design, I first had to identify the audio output I/O addresses. This wasn’t too difficult, as my Dad provided me with the Orchestra 90/CC and Stereo Composer I/O addresses, and I knew the CoCo’s 6-bit DAC is mapped to address $FF20 and the single-bit sound output is bit 1 of $FF22. So, basically, the I/O map looks like this:

$FF20 – The CoCo’s standard audio output, via a 6-bit DAC, bits 2-7, with bit 2 being the LSB. Bit 1 is the RS-232 data output, and bit 0 is the Cassette Data Input. The Stereo Pak will activate both it’s LEFT and RIGHT Channels whenever a write to $FF20 occurs. This will allow the Stereo Pak to generate sound from ANY piece of CoCo software. Note that even though the CoCo’s internal sound routines, and most other software, only generate a 6-bit digital byte for the sound, most of the Music Composition Programs (commercial and otherwise) generate a full 8-bits (even though 2 bits are ignored by the CoCo’s 6-bit DAC.) These programs can now be heard through the Stereo Pak in their full 8-bit glory! It is important to note that bit 1 is the output for the RS-232 port – the stereo pak will therefore output noise while printing to the RS-232 port or communicating with equipment such as a modem. A jumper will be included to allow the $FF20 sound to be enabled or disabled in order to alleviate this “noise”.

$FF22 – The CoCo also has a single-bit sound output at bit 1 of $FF22. I could have designed the Stereo Pak to simply activate both Stereo Channels on any write to $FF22, but this wouldn’t be of much use since bit 1 wouldn’t make much of a difference in the amplitude of the output of the DAC’s. A better solution would be to apply bit 1 to all 8-bits of the DAC’s whenever a write to $FF22 is detected. This allows the toggling of bit 1 to toggle the output of the DAC’s between near zero volume and maximum volume. Of course this approach means two data bus buffers have to be added to the design – one only active on writes to $FF22, the other only active on writes to $FF20, $FF70, $FF72, $FF7A and $FF7B (these latter addresses are those for the Stereo Composer and Orchestra 90.) There will also be a jumper allowing the $FF22 sound to be enabled or disabled (as with $FF20, there are other uses of $FF22 which can generate noise.)

$FF70 and $FF72 – These are the LEFT and RIGHT outputs of the Speech Systems Stereo Composer. Again, jumpers allow either or both of these addresses to be enabled or disabled.

$FF7A and $FF7B – These are the LEFT and RIGHT outputs of the Tandy/Software Affair Orchestra 90/CC. Again, jumpers allow either or both of these addresses to be enabled or disabled.

With that I jumped right into the design, working all night until I ended up with the following schematics:

This part of the schematic is basically the cartridge “plug”, address decoding and the enable/disable jumpers for each of the memory addresses. Notice that a GAL 22V10 is employed to reduce the number of chips considerably.

This part of the schematic represents the two sets of data bus buffers. Note that if the $FF22 output were removed from the design, then this entire section of the schematic could be eliminated. The second set of buffers are responsible for feeding bit 1 of $FF22 to all 8-bits of the DAC’s.

This is the feedthrough header (CN1) which is used to allow the Disk Controller or the Multi-Pak to plug into the sound card. If the sound card were to be plugged into the M.P.I., then the $FF20 and $FF22 outputs would not function. Therefore, I have allowed for the M.P.I. to plug into the sound card. Also shown is a reset button that allows the CoCo to be reset by pressing the switch. There is a power L.E.D. and an EPROM – the EPROM can contain operating software for the Stereo Pak (such as the Orchestra 90/CC ROM). The Auto-Start Jumper will allow the EPROM software to auto-execute if the jumper is installed. The ROM enable jumper allows the ROM to be enabled or disabled completely (in case a Floppy Disk Controller is installed.)

These are the two (LEFT and RIGHT) DAC’s. Rather than use R2R’s as in the Orchestra 90/CC, I decided to use 7524 Multiplying DAC’s. This saves a lot of circuitry and should sound really awesome.

This is the initial P.C. Board Layout. It is completely routed by the auto-router and so many of the tracks are less than optimal.

THE “.ZIP” FILE CONTAINING THE WHOLE PROJECT MAY BE DOWNLOADED HERE:
Stereo DAC Sound Card (GIMEchip.com) Complete “.zip” file includes E.A.G.L.E. files

Thanks,

Wal.

This post was submitted by CocoWal.

About three years ago, I began working (playing around with, actually) my Dad’s vintage computing equipment. The CoCo is my Dad’s favorite machine and that which I grew up using. As such, it has also become my favorite.

I immediately began developing hardware for the machine. All sorts of stuff really. Even managed to get an FD-500 to do Hi-Density by double clocking the WD1773 during sector read/writes.

In order to fund the projects, I started selling stuff on the evil that is eBay, and I have to say, without all of the support that I’ve received from you wonderful Ladies and Gentlemen, I might not have ever developed a single item. The CoCo Community is truly the GREATEST Vintage Computing Community in the world.

Now, my Dad taught me that you can have money and you can have friends, but when money is spent and gone, friends are still there. His motto: “I’d rather have friends over money any day.” I suppose that’s a good one

So, I am now in the process of getting all of my designs together and uploaded to CoCo3.com. You can all use this stuff however you see fit. If you want to debug and build any of it to sell – go ahead. You’ve my blessings

On a personal note, the last three years have been rocky. I have been diagnosed with a heart condition at a young age. It is manageable, though it took them long enough to figure out what was wrong. It still scares me sometimes when it starts acting up and I can’t breathe, but it passes. I suppose that’s another reason I want to get everything uploaded here – to make sure it’s always available to you folks, no matter what happens.

Also, not long ago, my Mom was diagnosed with cancer. They removed the tumor. She is undergoing Chemo now and it’s been so rough for her. It’s been rough for me too, but I don’t let her see me distraught – I try to keep her spirits up. They say the Chemo is just a precaution, and I think she said that she will have to have radiation after the Chemo, but I’m not sure. Still, I just have to believe it’s going to be okay.

I often give away free stuff too. Lately, I’ve been under a lot of stress, so if I’ve promised any of you wonderful people anything and you haven’t received it – please REMIND me. I forget a lot of things these days – so much on my mind. However, if I’ve promised you something and it never arrived – let me know so I can get it to you. I love to make people happy – that’s what I do

Finally, are there any CoCo BBS’es left in the world? I am setting up a test BBS. I don’t know if the MagicJACK can sustain a modem connection, but I want to try calling a BBS from my MagicJack line. If it turns out that it can sustain a modem connection between 300-9600 baud, I may set up a ten-line CoCo BBS just so folks can relive the days before the internet was common. I think it’ll be fun. Does anyone know where I can find the OS-9 Level 2 BBS software package to run the thing with? Should I run it from a PC using a PC BBS software? Or should I run it from a CoCo? Suggestions……????

Thanks – John

P.S. – I forgot – If any of you have any project ideas, toss them my way and I’ll see if I can get them done and posted for you – this is how I have fun and try to take away the stress and keep my mind off of Life, The Universe, and Everything = 42.

During the development of various CoCo 3 Memory Upgrades, I decided that the best RAM to use would be Static RAM – no refresh hassles and the possibility of battery backup makes it a great choice. However, the Address Bus is multiplexed and must be demultiplexed for use with Static RAM. It isn’t really that difficult to demux the “Z” bus as it is called in CoCoLand. Latch half the address on !RAS and present that with the Z-bus (which provides the second half of the address on !CAS) to the SRAM at !CAS time. !WE then causes either a Read or Write to be performed depending upon it’s logic level. The notes below describe the circuit. I’ll answer any questions as best I can.

Jumper JP1 allows selection of !CAS or a “delayed” !CAS.

!OE of the 128Kx8 SRAM tied to GND allows !WE to act as R/!W.

!RAS strobes the first half of the address into the latch.

!CAS strobes both halves of the address into the SRAM.

A16 is tied high since only half of the 128Kx8 SRAM is used.

!WE then allows: a read of the SRAM if high, otherwise data is written into the SRAM.

Note that !CAS strobes the !CS1 line which enables the SRAM for the duration of !CAS only.

CS2 is tied high and must remain high in order that the SRAM may be enabled.

A16, shown tied high, can be high or low – it doesn’t matter which half of the SRAM we use.

A16 could also be attached to an S-R flip-flop to provide a bank switching circuit, thus providing two 64K Banks of RAM.

Note that the SRAM is the LP (Low Power) version, which also allows for a battery backup circuit to be used.

THIS CIRCUIT HAS PROVEN SUCCESSFUL AT REPLACING A BANK OF EIGHT 4164 DRAMS.

NOTE, HOWEVER, THAT THIS CIRCUIT ASSUMES THAT THE DO & DI OF THE DRAMS ARE USED SEPERATELY BY THE TARGET CIRCUIT. THIS MAY NOT ALWAYS BE THE CASE, AS SOME DESIGNS SIMPLY TIE THE DO & DI PINS TOGETHER. IT DOESN’T MATTER TO THIS CIRCUIT WHETHER THE DO & DI PINS ARE TIED TOGETHER OR NOT. IT WILL WORK REGARDLESS. HOWEVER, IF THE TARGET CIRCUIT HAS THE DO & DI PINS TIED TOGETHER, THEN THIS CIRCUIT CAN BE SIMPLIFIED BY LEAVING OUT THE DO & DI BUFFERS. THE SIMPLIFIED CIRCUIT FOR SUCH AN INSTANCE IS PROVIDED IN THE FIRST PART OF THIS SERIES:
SEE: 4164 DRAM – SRAM Replacement #1 for the circuit to use when DO & DI are tied together.

The files for this project (part 2) are here:
“.PDF”
“.txt”
“.ZIP” including E.A.G.L.E. files.

Next, I will post some of the development work on the 512K SRAM CoCo 3 Upgrade, the 2-Meg SRAM CoCo 3 Upgrade and the specifications for the 512Meg Pageable (by extending the MMU registers to 16-bits) RAM Upgrade for the CoCo 3.

I am also working on a 2-Meg Upgrade for the CoCo 1 and 2. My intention is to create a 2-Meg RAM upgrade for the CoCo 2 that functions like the CoCo 3 2-Meg upgrade. By incorporating the MMU registers, it should be possible to modify a CoCo 2 to run OS-9 Level 2. However, only the VDG (Term_VDG) and lo-res 256×192 graphics will be useable, since this will be a memory upgrade only. I will keep you all posted on the progress of this device – the VDG Video may also be useable at 1.78 Mhz on the CoCo 2 since this upgrade will be static and will not need the refresh, but this depends upon whether !CAS and !RAS are actually generated during the 1.78Mhz mode on the CoCo 2 – I’ll have to examine the VDG and SAM datasheets to see – if not, then OS-9 L2 would have to be patched to run at .89Mhz with this upgrade — we’ll see how it goes – John

During the development of various CoCo 3 Memory Upgrades, I decided that the best RAM to use would be Static RAM – no refresh hassles and the possibility of battery backup makes it a great choice. However, the Address Bus is multiplexed and must be demultiplexed for use with Static RAM. It isn’t really that difficult to demux the “Z” bus as it is called in CoCoLand. Latch half the address on !RAS and present that with the Z-bus (which provides the second half of the address on !CAS) to the SRAM at !CAS time. !WE then causes either a Read or Write to be performed depending upon it’s logic level. The notes below describe the circuit. I’ll answer any questions as best I can.

Jumper JP1 allows selection of !CAS or a “delayed” !CAS.

!OE of the 128Kx8 SRAM tied to GND allows !WE to act as R/!W.

!RAS strobes the first half of the address into the latch.

!CAS strobes both halves of the address into the SRAM.

A16 is tied high since only half of the 128Kx8 SRAM is used.

!WE then allows: a read of the SRAM if high, otherwise data is written into the SRAM.

Note that !CAS strobes the !CS1 line which enables the SRAM for the duration of !CAS only.

CS2 is tied high and must remain high in order that the SRAM may be enabled.

A16, shown tied high, can be high or low – it doesn’t matter which half of the SRAM we use.

A16 could also be attached to an S-R flip-flop to provide a bank switching circuit, thus providing two 64K Banks of RAM.

Note that the SRAM is the LP (Low Power) version, which also allows for a battery backup circuit to be used.

THIS CIRCUIT HAS PROVEN SUCCESSFUL AT REPLACING A BANK OF EIGHT 4164 DRAMS.

NOTE, HOWEVER, THAT THIS CIRCUIT ASSUMES THAT THE DO & DI OF THE DRAMS ARE TIED TOGETHER. THIS IS NOT ALWAYS THE CASE – THE CoCo 2, FOR EXAMPLE DOES NOT HAVE THE DO & DI PINS OF THE DRAM TIED TOGETHER. IN SUCH A CASE A SET OF TRI-STATE BUFFERS MUST BE INCORPORATED ON THE SRAM DATA BUS PINS. SEE: 4164 DRAM – SRAM Replacement #2 for the circuit to use in such an instance.

The “.pdf” Schematic here: 4164 DRAM – SRAM Replacement #1 (GIMEchip.com).pdf

The text file here: 4164 DRAM – SRAM Replacement #1 (GIMEchip.com).txt

and the EAGLE schematic as a “.zip” here: 4164 DRAM – SRAM Replacement #1 (GIMEchip.com).zip

He mentioned his card had NTSC TV output and I had a light bulb moment.

I have plenty of experience with multiple monitors on Windows, and an older 3D card I used had a TV-out but I’d only ever had a PAL TV to connected to it. Unfortunately, that card is dead and my new one doesn’t have TV-out, anyway…

So here’s the question: If an NTSC TV is hooked up to the PC via a 3D graphics card that has a TV-out, and MESS or Vcc were displaying a 256-artifact color image (black and white on an RGB monitor), would the artifacts be displayed on the NTSC TV, and if so, displayed as intended? My hunch is they would, provided MESS or Vcc were displaying the image in full-screen mode, and the aspect ratio displayed on the TV from the emulators is correct.

Does anyone have a 3D card with a NTSC TV out, MESS or Vcc installed and the cable needed to connect the TV to the graphics card? The TV-out may be an S-Video socket, but most cards with this come with an S-Video to RCA cable. Update: I’ve now learned some Intel cards use a VGA to RCA cable for TV-out

I’d be happy to work with anyone who is willing to give it a go.

I can be emailled at jmlaw@iprimus.com.au

Fingers crossed, this could give access to the artifact colors for those without a NTSC CoCo 3. Or for those who only have 128k, access to the artifact colors AND 512k, and for those of us with only 512k, access to 2MB or even 8MB from MESS or Vcc.

Though the specifics of programming under DECB for more than 512K are not something I’m familiar with just yet. Robert Gault mentioned in a post a while back the extra memory is accessed using the two high-order bits not used normally with 512k of, if I remember correctly, the value you put into the task register when switching memory blocks. I’ll look into that now…

The potential could be 8MB RAM, quality sound effects & music (possible now but more RAM means more space for quality audio data) AND 256 artifact colors. I’ve started writing a game, and have the ‘nuts & bolts’ of using the artifacts and supporting16 color RGB with the same game code sorted. So if it works, I’d be super keen to write my next game using 2MB or 8 MB. While these memory upgrades aren’t available now that I’m aware of, perhaps if there was a use for them, someone could make them and sell them. I think someone (maybe gimechip) had developed plans for or was working on a 2MB upgrade.

I’m also working on a 256 artifacts video demo (yeah I know it’s been done by John Linville already, cool hey ), but more RAM would mean a longer video demo,  but ultimately, games with enough RAM  for video cut-scenes between levels. Ever imagine a game on the CoCo 3 doing that?!?!

Also, being able to use 80 track virtual disks in Vcc, or virtual hard drive images (working now I believe) with the disk drives over-clocked (needs high-speed poke set and CPU over-clocked) will load a lot of data very quickly so the load times of all the extra data wouldn’t be an issue in Vcc. A standalone .bin file (not on disk) loads very quickly too. Just a thought…

While I’m almost 100% certain (haven’t tried it) a game can be written to access huge storage quite easily on the MicroSD, SuperIDE, or via DriveWire etc,  I’m also trying to keep my game ideas emulator-compatible, just for now.

The idea may not work, but considering the potential, I think it has to be worth investigating. I have far more ideas than I have time to test or implement, so if you get and idea from something I’ve written here, go for it.

Reminds me of a good quote: “If you have an apple and I have an apple, and we exchange apples, we both still have 1 apple. But if you have an idea and I have an idea, and we exchange ideas, we both now have 2 ideas”

This post was submitted by JasonL.

This post was submitted by navydave.

A CoCo MIDI Sequencer PAK With MIDI IN OUT & THRU

This is a CoCo MIDI Sequencer Program PAK that I was working on. It’s been a long time since I’ve looked at the circuit and don’t exactly remember why I did some things the way they are done. This was intended to be compatible with Lyra, CoCo MIDI Pro, UltiMuseIII, etc. This hasn’t been tested. I am uploading it for informational purposes. If you want to work with it and debug it, feel free to do so. I will answer any questions as best I can. I plan to re-do this and create a much better schematic & layout at some point in the future. All files are in E.A.G.L.E. format -John
Files downloadable here: CC-FlexiMIDI-Version-1.0 (GIMEchip.com)

I loaded it on to my CoCo 2, and ran it, and got a simple title screen that says “Success Manion – Press Any Key to Continue”.

Unfortunately, after I pressed the key, I got “The Adventure Begins…” followed immediately by “?OM Error In 3020″, which I gather means Out of Memory.

Has anyone played or heard of this game before? I tried a Google search on it, but didn’t really come up with anything, aside from a .DSK image that somehow referenced the name of the game (in an index, I guess) without actually containing the game.

I can try to load it on to my computer via my sound card if anyone wants to take a look at it. I suppose I could even extract the ASCII if I mess around with it in an emulator (it does look to be in BASIC). I don’t know if it’s actually too big, or if some programming error is causing it to try loading data into an address that doesn’t exist (I have 64k of RAM, by the way).

This post was submitted by jmetal88.

DOWNLOAD THE E.A.G.L.E. FILES FOR THE SLOT EXTENDER HERE: Slot Extender (GIMEchip.com)

At this point, you may be wondering: “How is it possible to install an alternative Disk BASIC ROM without opening up the Disk Controller?” There are often several methods to solve any given problem. The method that I have devised is actually quite simple. The CTS* select signal is responsible for selecting (enabling) the Disk BASIC ROM within the Disk Controller. The “*” indicates that this select signal is active low. If this line were to be held high (logic level 1), then the Disk BASIC ROM would remain in the high-impedance (disconnected) state. It would be as if the ROM did not exist. The CC-MDP-0001.0 accomplishes this by feeding all of the signals from the cartridge port straight through to the Disk Controller, with the exception of the CTS* signal. The CTS* signal from the cartridge port is connected to the CC-MDP-0001.0’s internal ROM, whilst the CTS* signal that is output from the CC-MDP-0001.0 to the Disk Controller is held perpetually high. This has the effect of substituting the ROM onboard the CC-MDP-0001.0 in place of the Disk Controller’s internal ROM. This device can also be used to substitute or disable the internal ROM’s of other Pak’s as well (the Deluxe RS-232 Pak for example).

Although the above “Theory of Operation” was to be the extent of the original design criteria, it became readily apparent that a few additional useful and interesting features could be included in the design without increasing the complexity too much. Those features are as follows:

ONE MEGABYTE OF ROM MEMORY – The CC-MDP-0001.0 CC-Multi-DOS-Pak, Version 1.0 includes 1-Megabyte of onboard EPROM arranged as 32 software selectable banks of 32Kx8. The entire 1-Megabyte of ROM is accessible to the CoCo 3. The CoCo 1 and 2 can only access 512K of the 1-Meg of EPROM memory. This is NOT a design flaw in the CC-MDP-0001.0, rather it is a hardware limitation of the CoCo 1 and 2. In order to access these additional ROM banks, the CoCo MUST be in the ROM Mode (POKE 65502,0 or POKE &HFFDE,0). This generally is not an issue with the CoCo 1 and 2 as these machines normally run in the ROM mode. Some software programs (such as those that patch BASIC) will place these machines in the “ALL RAM” mode. In such a case, the above POKE will return the machine to the ROM mode. The CoCo 3 is a different story altogether – it normally runs in the RAM mode. In order to access the added ROM banks, the CoCo 3 must be placed into the ROM mode.

THIRTY TWO PROGRAM PAKS ONLINE AT ONCE – As evidenced by the above statement, it is possible to have the equivalent of 32 – 32K Program Paks online at once. Any bank may be selected by a simple POKE statement. The active bank is selected by writing a value of 0-31 (&H00-&H1F) into address 65345 (&HFF41), whilst the contents of the active bank are accessed solely by the CTS* select signal of the Color Computer. The Color Computer 1 and 2 can only access the first 16K of any 32K bank. The Color Computer 3 can access the entire 32K of any bank. As previously mentioned, this is a hardware limitation of the Color Computer 1 & 2, and NOT a design flaw in the CC-MDP-0001.0.

RESET – The CC-MDP-0001.0 includes a reset button – no need to reach behind the computer to press the reset button.

POWER INDICATOR – The CC-MDP-0001.0 includes an LED power-on indicator.

POWER-ON RESET – The CC-MDP-0001.0 is designed to perform a power-on reset to bank 0. Pressing the reset button will NOT reset the EPROM to bank 0. This is necessary in order to access software in the other banks from a reset. If you will only be using bank 0, a jumper is included to force the reset button to reset the EPROM to bank 0. In most cases, this jumper should never be installed.

CARTRIDGE PASS-THRU AND HEADER – The CC-MDP-0001.0 includes both a 40-pin edge card cartridge slot and a 40-pin male header. These are meant for a Disk Controller as the CTS* signal at these connectors is held permanently high. This results in the ROM of any device being plugged into these being rendered invisible. The Disk Controller may be plugged directly into the edge card connector, or if you wish to distance the Disk Controller from the computer, a 40-pin cable (female header on one end, edge card on the other) may be connected between the header and the Disk Controller. Although these connectors were intended for the Disk Controller, it is possible to connect other devices to them. For example, the Speech/Sound Cartridge does not use the CTS* select signal and so the Speech/Sound Cartridge could be connected to the header, with the Disk Controller connected to the edge card. This could be handy if you do not have a Multi-Pak Interface. The Orchestra 90/CC could be connected to the header as well, with the Orchestra 90 software being housed in one of the EPROM banks of the CC-MDP-0001.0. This device opens up many new and interesting possibilities for your CoCo.

Programmable Logic – A small PLD is employed to reduce the component count significantly.

The schematics and board layout are provided in E.A.G.L.E. format for your experimentation. The following discussions are of the schematic pages:

CN3 is the cartridge plug that plugs into the CoCo Cartridge Slot. Notice that all of these signals are labeled as designated in the TRS-80 Color Computer Technical Reference Manual. CN1 is the 40-pin male “feed-thru” header. Notice that all signals are wired straight across with the exception of CTS* and SCS*. The CTS* signal has already been discussed. The reason that the SCS* signal is not wired straight across is that it is a R/W* select signal for memory addresses 65344-65375 (&HFF40-&HFF5F.) This select signal is used by the Disk Controller. The Disk Controller only needs 65344 (&HFF40) and 65352-65359 (&HFF4C-&HFF4F.) The remaining addresses in this range are wasted, and normally unavailable for use. The PLD (GAL) chip in the CC-MDP-0001.0 takes in the SCS* select signal, the R/W* signal, and the lower half of the address bus. Using these inputs, the GAL separates 65345 (&HFF41), as a write only select, from the SCS* signal. This write only select is used to latch the upper 5 “bank” Address bits for the EPROM. An altered SCS* (SCSOUT*) is generated and sent to the header and edge card. The SCSOUT* signal is active on all addresses in the 65344-65375 (&HFF40-&HFF5F) EXCEPT for the bank latch address 65345 (&HFF41.)

CN2 is the edge-card connector which is wired pin for pin to the feed-thru header, CN1. S1 is the RESET button, which should be self-explanatory. LED1 is the POWER ON Indicator, ditto S1.

IC2 is the PLD (A GAL16V8 from Atmel or Lattice.) The sole purpose of the 16V8 is to separate address 65345 (&HFF41) from the CoCo’s SCS* signal, while passing the remaining addresses 65344 (&HFF40) and 65346-65375(&HFF42-&HFF5F), as SCSOUT*, to the feed thru header and edge card. IC1 is the bank select latch. This latch is obviously mapped to 65345 (&HFF41), and is write only in this circuit. Only bits D0-D5 are latched – bits D6 and D7 are ignored (much in the same way as the CoCo 3’s 6-bit G.I.M.E. Registers.) Resistor R1 and Capacitor C3 provide the power on reset feature. The nature of a capacitor is to act as a direct short when power is applied, until it charges, at which point it acts as an open (in DC circuits.) When power is first applied, the capacitor is basically a short to ground for the clear (CLR) input of the latch which resets the EPROM bank bits to 0. As the capacitor begins to charge, it will eventually pass the voltage level considered by the latch as a logic high and the clear input will then be at a logic 1 level. It will remain at that level as long as power is applied to the circuit. It only takes about 1mS for the capacitor to fully charge, at which point it will appear as an open circuit. Basic electronics theory dictates that an open drops maximum voltage, so at this point, the clear pin is near Vcc. Data can now be written to the latch. JP1 is the jumper which allows a RESET of the computer to reset the latch to bank 0. Under normal conditions, this jumper should NOT be installed. If you only intend to use bank 0 of the EPROM, then this jumper may safely be installed. However, if you plan to use any of the other banks, the jumper MUST be OFF in order that the selected bank remains selected after a reset.

The CUPL code for the g16v8 GAL is included in the “.zip” file. This code has been compiled with Atmel’s WinCUPL 5. The code should be easily portable to other compilers.

IC3 is of course the One-Megabyte (1Mx8) EPROM chip. Others could probably be used as long as they are pin compatible. All of this portion of the schematic should be readily apparent and self-explanatory, except perhaps the group of wire pads. I used the wire pads for the grounding tabs. Also shown are the standoffs used to mount the finished P.C.B. in a case. This completes the schematics of the CC-MDP-0001.0 product. I hope that you have found this document informative and useful. If you spot any errors or omissions, please do not hesitate to contact me – this will allow me to make the proper corrections and debug the design, should bugs be found to exist.

PCB Layout created using EAGLE 5.xx
This board has been completely routed using the E.A.G.L.E. Autorouter. This being the case, it is extremely likely that many of the tracks are less than optimal. However, I am a Hobbyist – not a Pro, therefore, this is the best that I could do. Please note that, as of 02 March 2010, this layout has not been tested. Please report any errors to: sales@gimechip.com. The EAGLE Project Files are available for download from: coco3.com CC-Multi-DOS-Pak (GIMEchip.com)

When considering an address for the bank select latch, I had to make sure that the chosen address did not violate the real-estate of existing peripherals that might be encountered in the CoCo Community. To this end, I did a few hours research and found that the original DISTO Super Controller I included four 28-pin, software selectable ROM sockets. This seemed perfect – by using the same address as used by the original DISTO controller, I wouldn’t violate any memory addresses reserved for other peripherals. The CC-MDP-0001.0 would simply replace the similar function of the DISTO SC-I. The address used for this purpose by Tony was 65345 (&HFF41.) Once that was taken into consideration, the remainder of the design simply fell into place.

The 27C080 1-Mx8 EPROM should have a maximum access time of 300nS in order to work with a CoCo 3 in the High-Speed (1.78Mhz) Mode.
Bank 0 of the EPROM should contain your primary DOS (Disk BASIC) as this is the bank that is automatically selected upon power up. The other 31 banks may contain any combination of ROM images (Games, DOS BASICs, Applications, etc.)
To switch EPROM banks from BASIC, use the statement: POKE 65345,n where n is the bank number (0-31). Hexadecimal: POKE &HFF41,n (n=&H00-&H1F). At this point any number of things may happen, depending upon whether you are using a CoCo 1,2 or a CoCo 3. With a CoCo 1 or CoCo 2, it is likely that a crash will occur. Pressing reset should reboot the computer into the selected bank and likely return you to Extended BASIC (unless the selected BANK contains a Disk BASIC, in which case the selected Disk BASIC should properly initialize.) If the selected bank contains software other than a Disk BASIC, then you will need to enter EXEC 49152 (or EXEC &HC000). This will transfer control of the computer to the software residing in the currently selected EPROM bank. This procedure will not work on the CoCo 3, since the CoCo 3 normally runs in the ALL RAM mode. While in this mode, the CoCo 3 cannot access the ROM, and switching banks will have no effect because the CoCo 3 will continue executing the software from RAM. In order to properly utilize the CC-MDP-0001.0 with a CoCo 3, after entering the above POKE to select the bank, you must enter: POKE 113,0 and then press reset. If the selected bank contains a Disk BASIC, it should properly initialize. Alternatively, you could enter: POKE 113,0:DLOAD to reinitialize the CoCo 3 without having to press reset. If the selected bank contains software other than a Disk BASIC, you will need to enter: EXEC 57360 (or EXEC &HE010). This is a special routine in the CoCo 3 which switches the machine into the ROM mode and then executes the code at 49152 (&HC000). It is equivalent to: POKE 65502,0:EXEC 49152 (or POKE &HFFDE,0:EXEC &HC000).

To switch EPROM banks from assembly language, simply write the bank number via a STA or similar instruction to $FF41. It is recommended that the interrupts be disabled prior to switching banks, and then re-enabled afterward.
Even though each bank is 32K in size, any size ROM image up to 32K may be programmed into each bank. There should be no problems as long as the code is written to the beginning of the bank. I prefer, however, to duplicate the code throughout the bank. For example, if I have an 8K ROM image, I would program it into the bank four times, writing the image sequentially. If I have a 16K ROM image, such as Extended ADOS-3, then I would program the code into the bank twice (the upper and lower 16K sections of the 32K bank would contain identical data.) This isn’t strictly necessary, it’s rather a matter of personal “taste” than anything else.

The CC-MDP-0001.0 is capable of housing any ROM image from almost any CoCo Program Pak Verbatim – with the exception of the “Super” Program Paks – they are likely to require patching to work with this device (unless by some strange twist of fate they use the same bank switching scheme as the CC-MDP-0001.0, but this is doubtful – I think those Pak’s bank switch via a latch at &HFF40, but don’t quote me on that.)

The ROM in the CC-MDP-0001.0 is selected by the CTS* signal, just like any other Program Pak. The CoCo 1 and CoCo 2 are only capable of accessing 16K via the CTS* select. This means that only the first half of each 32K bank can be accessed by the CoCo 1 and 2. The CoCo 3 contains a specific GIME register that can be set to access 16K internal/16K external (CoCo 1 and 2 CTS*) or 32K external (for accessing the full 32K Program Paks). You need not know how this register works to make use of these 32K Program Pak images, as they will set up the register properly such that their software can access the entire 32K address space. This should be totally transparent. For those of you who are interested in how this register works, here is a useful table:
FF90 INITIALIZATION REGISTER 0
Bit 7 – CoCo Bit 1= Color Computer 1/2 Compatible
Bit 6 – M/P 1= MMU enabled
Bit 5 – IEN 1= GIME IRQ output enabled to CPU
Bit 4 – FEN 1= GIME FIRQ ” ”
Bit 3 – MC3 1= Vector page RAM at FEXX enabled
Bit 2 – MC2 1= Standard SCS
Bit 1 – MC1 ROM mapping 0 X – 16K internal, 16K external
Bit 0 – MC0 ” ” 1 0 – 32K internal
1 1 – 32K external
CoCo bit set = MMU disabled, Video address from SAM, RGB/Comp Palettes => CC2.
This Table Was Obviously Borrowed From The Information Gathered By: Kevin K. Darling.
CC-Multi-DOS-Pak (GIMEchip.com)

Thanks, Level 1

This post was submitted by Level 1.

This post was submitted by remz.

This post was submitted by basilf.

512K.gif (33 KB)

This post was submitted by dana.

This post was submitted by PunkMaister.

Thanks

This post was submitted by Level 1.

Also, I need to get a “Y” cable to use a MIDI Pac & disk pac together (I use to have one-lost it over the years). My Multipac Interface died and I have no way to get my old MIDI files.

Thanks

This post was submitted by keyboardman.

I have several manuals and software packages looking for a good home. First come, first serve. Let me know which things you want, I will let you know how much it will cost for me to mail it, and you can PayPal me the postage.

Note that these were kept in an attic, so I don’t have high hopes for the software disks or tapes working properly.

Please email me at dave_nedde (at) yahoo.com.

Thanks

Here is what I have:
26-1172 TRS-80 modem manual
26-3290 The Sands of Egypt Animated Adventure manual and disks
26-3311 raaka-tu Adventure game manual and tape
26-3076 Mega-Bug game cartridge
26-3085 Microbes game cartridge
62-2006 TRS-80 Assembly Language Programming
0-8359-7864-8 TRS-80 Color Computer Graphics by Don Inman
8749284-800 Getting started with Color basic
26-3001/3002 TRS-80 Color Computer Operation Manual
26-3250 EDTASM+ Color computer editor assembler with zbug (manual only)
62-2076 Color Computer Graphics by William Barden Jr.
62-2077 TRS-80 Color Computer Assembly Language Programming by William Barden Jr.
8749267-800 Going Ahead with Extended color basic
8749299-881-TM Color Computer Disk System Owners manual & Programming Guide
Hot CoCo 5/85, 6/85, 7/85, 8/85, 10/85, 11/85

What looks like a computer (round 5 pin) <-> cassette tape (3 mono plugs) cable

This post was submitted by PunkMaister.

What is the process for upgrading the CoCoNet ROMS in a Drivepak? I see you have released several newer versions since the one I received in my Drivepak.

Thanks

This post was submitted by Ed Orbea.

< <<< Go Here >>>>

-Pilot

This post was submitted by pilot352.

Darryl

This post was submitted by dneyman.

http://rapidshare.com/files/388442991/ColorComputerNewsBestOf1981.pdf.html

MD5: 5FB17235E2EAFFD5A4AD3435AF005EE7

If you aren’t going to upload it to a permanent spot, please don’t download it.
I’m sure someone will post a permanent link to the file.

This post was submitted by jdiffend.

http://nitros9.lcurtisboyle.com/fembotsrevenge.html

After much searching, I found a Dragon software archive with a VDK (virtual disk) file that appears to contain one of the “Cimeeon Moon” games here:

http://archive.worldofdragon.org/archive/index.php?dir=Disks/SnarkHunter/&sort=filename&sort_mode=d

http://archive.worldofdragon.org/archive/index.php?dir=Disks/SnarkHunter/&file=ADVEN04A.vdk

I’ve spent hours trying to open that file in MESS and XROAR, hoping to finally play the game and see if it approaches the greatness of Daggorath. No luck. So I am appealing to all of you for help. Can anyone extract “Cimeeon Moon” from that VDK file and convert it to a pak or cas file that I can play? You would make this old school CoCo gamer very happy.

Also, does anyone know if the ColorQuest 3-D games were inspired by Dungeons of Daggorath, or perhaps even release before it?

Thanks for your help, and for this great site!

This post was submitted by daggorath.

I am new to this forum, but the CoCo2 16K was my first childhood computer. I just recently got bitten by the CoCo bug again and I am now trying to get back into the CoCo seen. Anyhow, I have a question that I hope you CoCo buffs can help me with as I cannot find this information on the web. I recently purchased a white case CoCo 1 with 64K ram on Ebay, but the interesting part is that this computer comes with a regular size key grey keyboard! Did Tandy ever make a white case CoCo 1 with a grey keyboard? I though that these white case CoCo 1′s only come with the “melted” keyboard according to wikipedia? I can’t find any info on the web about these grey keyboard CoCo’s ever exist so I assume that this computer had an aftermarket keyboard upgrade? The previous owner also added a green power on light to the top of the case, see attached picture of the computer below. I think it looks pretty cool! Can anyone confirm that this computer’s grey keyboard is original or have any info on this unique CoCo? Thank you.

coco2_64k.jpg (48 KB)

This post was submitted by cocopuff.