I recently won a job lot on ebay and buried in the box was this.

http://imgur.com/a/LdJmP#0

I have been trying to find out more about it as I had no clue as to what it was. So far the most valid explanation is part of a CoCo development kit.
Does anyone know any more about it? I have asked in a couple of places and am fairly sure it is a CoCo dev cart but know nothing more than that…

If this is the wrong section apologies but I don’t really know where it should go….

This post was submitted by warpedflash.

a couple of month ago I was dreaming of a coco 3 rendering texture mapping in realtime. And finally I think I did it: If everything goes well I will post a DSK so you can try it out. Here is a screenshot attached, showing MESS emulation running.
The demo has a predefined path and no user control. It features high precision texture mapping with perspective correct, mip-mapping and distance shading. The floor and ceiling are texture mapped too using perspective correction but I had to trade texture resolution for speed, so basically it is more-or-less a sort of infinite carpet.
It runs at about 5 frames per second, and works on a plain 128KB coco 3. I have tested it with floppy (MESS,VCC) and DrivePak (real coco).

coco3_texture_map.jpg (213 KB)

This post was submitted by remz.

Thanks in Advance
Bill Pierce

This post was submitted by Bill Pierce.

This post was submitted by DanWebb314.

What books should I get? What specific magazines/issues would be helpful? What assembler should I use?

Also more importantly, Can you explain to someone who is a noob what are things I shouldn’t do (ie: I want to use the original coco 1/2 resolutions/colors but I also want it run on a CoCo 3 without problems.)

Need input ASAP as I’d like to have something to show at the next Rainbowfest.

Thanks!

This post was submitted by courtesi.

So as far as I can tell my serial interrupt doesn’t fire. Does anyone know how the serial interrupt is supposed to trigger? I assumed a new irq would be generated for each state change on the rs232 port, meaning for each bit, regardless of whether it is a start/data/stop bit. I understand doing it this way rules out any massively fast baud rates, but I think at double cpu speed it should be possible to capture 38400 on down…

This post was submitted by sc.

MC1=0 MC0=X 16k internal 16k external
MC1=1 MC0=0 32k internal
MC1=1 MC0=1 32k external

Can anyone clarify this? When you want to treat all system memory as standard RAM right up to $7FFFF, what should be the proper setting for these bits? I do understand the use of the int vector areas, and being able to lock in FE00-FEFF, etc… just don’t know what is meant by “internal” vs “external” vs a combination of the two…

This post was submitted by sc.

This post was submitted by sc.

TABLE FCC /01234/

LDX #TABLE
LDA #2
LDA A,X

…will the CPU replace the value in A, after using the current value in A for the addressing mode? So in the above example, it would load the new value (character “2″ in table) from the address 2,x?

This post was submitted by sc.

first, disable all PIO interrupts

0003  CLR $FF01
0004  CLR $FF03
0005  CLR $FF21
0006  CLR $FF23

non-compatible mode, enable gime as source of interrupts

0007  LDD #$7A20
0008  STD $FF90

but make sure no interrupts are going to be happening

0009  LDD #$0000
0010  STD $FF92

set up a timer interval for later

0011  LDD #$08EE
0012  STD $FF94

set up a 40×24 text mode

0013  LDD #$030C
0014  STD $FF98

with video memory starting at physical address $0

0017  LDD #$0000
0018  STD $FF9D

set up all foreground pallete with black

0019  STD $FFB8
0020  STD $FFBA
0021  STD $FFBC
0022  STD $FF9E

and all background pallette with green

0023  LDD #$1212
0024  STD $FFB0
0025  STD $FFB2
0026  STD $FFB4
0027  STD $FFB6

MMU: put physical page $0 at logical page $0 for access to video memory

0028  LDD #$0001
0029  STD $FFA0
0030  STD $FFA8

…thought I’d put this up here and see if anyone thinks I’m way off here, back to my debugging…

Now, this is only a 313 byte file.  So I write the content of the file starting at the first byte of the image, which should be track 0 sector 1.  Next I create the directory entry, specifying name, extension, type 2 for binary, 0 in the ascii flag.  Then we come to the “first granule” of the file, in which I’ve tried both zero and one.  So first question:  Are granules numbered starting with zero or one?

Then in the two bytes that specify the # of bytes used in the last sector, I put in a zero and 57, since the second sector of my file only has 57 bytes used.

Finally, in the first position of the FAT table (which I understand is after 6 bytes of control information), I place an entry that should mark the first granule as used.  I place in here the value 194 (which is 128+64 to set bits 7 and 6 high, and the value 2 in the lower 5 bits specifying that only 2 sectors of this granule are in use.

Based on my reading, that’s all I need.  I get this DSK image going via drivewire, run a “DIR” and I see the filename and ext I chose, but then the DIR fails with FS error.

Any theories?  Thanks!

The Color Computer has a four-pin DIN connector on its back panel for its serial port. There is very little internal hardware dedicated to supporting this, so most of the work of sending and receiving bits is done in software; the CPU goes into a loop either setting the output bit or reading the input bit.

As you might imagine, doing both at the same time can be tricky, since you don’t have any guarantees about when the first bit of a byte will arrive; it might be while you are right in the middle of sending a byte. The result is a limited baud rate; the CPU can only do so many bits per second. Some of my assembly-language programs can receive at 9600 baud, but don’t do any sending at all. Comm programs might get up to 2400 baud, but may not be so reliable at that rate.

Here is a cheesy ASCII drawing of that connector, including a pinout and showing how the pins are numbered. The drawing is of the back-panel connector, looking at it from the back of the machine. So if you are looking at the pins of the connector at the end of a cable, it is backwards.

        ------       Pin#  RS-232 signal            Printer signal
      /  \__/  \     ----  ----------------------   ---------------
     /          \
    / 4      1   \    1    CD - carrier detect      ignored
       o      o
   |              |   2    RS232IN - input data     printer status
   |              |                                 (high == ready)
   |  3      2    |
       o      o       3    GND - ground             ground
    \            /
     \          /     4    RS232OUT - output data   data to printer
      \        /
        ------

Note that pins of connector are not always used the same way! This is possible because most everything is done in software; pins 1 and 2 are required by the hardware to be inputs, but it is up to the program to decide how to use those inputs. While any sort of communications program should use the RS-232 pin-out, the built-in BASIC printer routines use pin 2 as “printer status” and completely ignore pin 1. So the cable you wire up for a printer has to be different from the one you wire up for a modem. Thank MicroShaft for that.

The cassette cable has a 5-pin DIN connector on one end, that plugs into the back of the CoCo; the other end has three earphone-style plugs, that plug into the EAR, AUX (or MIC), and REMOTE jacks. The remote-control plug is smaller than the other two. The other two are differentiated by color: the black one plugs into the EAR jack, while the grey one plugs into AUX.

Here is an ASCII drawing of that connector, including a pinout and showing how the pins are numbered. The drawing is of the connector at the end of the cable, with the pins pointing toward you. So if you are looking at the back of the machine, at the connector there, this pinout is backwards. My apologies for the wacky numbering; this is the same numbering as in the CoCo-1 technical manual.

        -------       Pin#  Name      Connects to
      /  \___/  \     ----  -------   -----------------------------------
     /           \
    /             \    1    CASSMOT   SG stem

   |               |   2    GND       B stem, LG stem
   |  1o       o3  |
   |               |   3    CASSMOT   SG tip
        o     o
    \  4   o   5  /    4    CASSIN    B tip
     \     2     /
      \         /      5    CASSOUT   LG tip
        -------       

                         B=black    SG=small grey    LG=large grey

The names are given from the perspective of the computer, so “OUT” means output from the computer, input to the cassette, and it should go into the AUX (or MIC) jack while the cassette is recording.

The “connects-to” column show which of the three earphone-style plugs the wire leads to, and to which part (stem or tip).

Below is another cheesy ASCII drawing, this time of one of those plugs. The cylindrical prong actually consists of two metal parts, separated by a narrow strip of plastic, drawn as “X”s. The stem section is much longer than the tip section, and the tip section has a groove around it, so that a spring loaded contact can hold it in place a little bit when it is inserted into a jack.

              -------------
              |           |
              |           |------------xx-\  /--\
              |           |            XX  --    |
              |           |  "stem"    XX   "tip"|
              |           |            XX  --    |
              |           |------------xx-/  \--/
              |           |
              -------------

For both of the plugs that carry data (the large ones), the stem is connected to ground, and the tip is the data line.

For the motor-control plug (the small plug), it shouldn’t really matter which of its two wires connects to its tip and which connects to its stem; you could just as easily connect 1 to SG tip and 3 to SG stem, and it should still work fine. These two wires are just connected together by a relay in the computer when it is time to let the motor run. The wiring shown here matches my cassette cable

The theory behind this is using data arrays as a map to determine where the regions are for the digital directions. It took 3 arrays but you can identify direction and jump to a line number to handle that direction in a single line of code. I hope it’s faster than multiple tests.
Modifying the axis maps allow you to change where the joystick is centered of length of throw required to indicate a direction.

Array A is for the X axis, array B for the Y axis, and C is to convert the sum of those two values to a digital direction.
Two arrays are used for A&B so that unique bits can be set for each axis and unique values are provided for each digital equivalent location.
ON GOSUB could be used in place of ON GOTO
Lines 100-900 are not provided but they handle each unique direction (state) of a digital joystick.

10 DIM A(64):DIM B(64):DIM C(37):FOR I=0 TO 63:READ A(I):NEXTI:FOR I=0 TO 63:READ B(I):NEXTI:FOR I=0 TO 36:READ C(I):NEXT I
20 ON (C(A(JOYSTCK(0)) + B(JOYSTCK(1)))) GOTO 100,200,300,400,500,600,700,800,900
30 GOTO 20
999 REM X AXIS DATA
1000 DATA 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
1010 DATA 1,1,1,1,1,1,1,1,1,1,1,1,2,2,2,2
1020 DATA 2,2,2,2,4,4,4,4,4,4,4,4,4,4,4,4
1030 DATA 4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4
1039 REM Y AXIS DATA
1040 DATA 8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8
1050 DATA 8,8,8,8,8,8,8,8,8,8,8,8,16,16,16,16
1060 DATA 16,16,16,16,32,32,32,32,32,32,32,32,32,32,32,32
1070 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32
1079 REM DATA TO CONVERT TO DIGITAL JOYSTICK POSITION
1080 DATA 0,0,0,0,0,0,0,0,0,1,2,0,3,0,0,0,0,4
1090 DATA 5,0,6,0,0,0,0,0,0,0,0,0,0,0,0,7,8,0,9

That being said, I’d like to make it as relatively painless as possible. I’d like to be able to teach him the basics of memory and register manipulation, while also giving him easy/pretty ways to see the output.

He’s never done programming before. and he’s 9.

So, I was wondering if there are any well-known subroutine entrypoints in ROM,  for things like

“print a number/string/whatever to the screen”, etc, etc., if you are writing a program directly in ASM (via EDTASM) rather than trying to insert things into a BASIC subroutine.

I thought there were… but it’s been 20 years so I dont remember clearly

64? Are there some peeks&pokes I’m unaware of that could shift basic into a 64 column mode? Just curious…

This post was submitted by sc.

coco3 512k, standard 6809
HDB-DOS 1.1D DW3 COCO 3 (hdb-dos startup version message)
a standard copy of disk edtasm

Will Robert Gault’s edtasm patch allow me to access my drivewire drive images directly from edtasm?

If so, is it still available? (Couldn’t find a working URL…)

Thanks!

This post was submitted by sc.

Oh, if we just had this back in the 80′s,…..

Users of the popular Rainbow IDE, and the Portal-9 IDE, behold the new Phoenix IDE – a CoCo author’s dream. The best way to describe this IDE is “Rainbow x 2″.

In order to save the Micro Drive Pak, a special $29 preorder price is being offered with the conditions that you will have to wait about 3 weeks for the IDE to be wrapped up. You’ll also get free upgrades, so beat the price by supporting CoCo3.com with a preorder sale.

Check out these screen shots. Easy on the eyes, less mouse movement, and CoCo friendly. The docking panes can become floating windows that you can move to another monitor if you like. Just drag them where you want them, redock them to another location, and configure your layout how you like.

One of the screen shots shows the OS-9 Level II RMA assembler crunching out an object file in a fraction of a second.  The readout window was moved to the right side of the screen and all the other panels have been neatly organized on the left sidebar, all using simple drag and drop.  You decide how you want the IDE to look, and CoCo OS-9 software development will be a snap.

Thanks!

This post was submitted by plainsteve.

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.

Thanks and have a good day!

This post was submitted by remz.

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.

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.

This post was submitted by remz.

I was attempting at doing a smooth driving/racing game to see if the coco 3 could pull it out. I think it would be feasible. This screenshot shows the actual prototype running on MESS:

The demo has no user control yet, but the road moves at a totally arcade quality framerate of 60 frames per second. The road is shown in pseudo-3D perspective, along with a colorful gradient sky. The car dash itself is ‘borrowed’ from Test Drive, Amiga version. You can see the game shows about 32 different colors at the same time, which is pretty cool. A bit like good-old DragonFire did with the CoCo 2
I haven’t tested it yet on the real hardware.
The main problem with this kind of demo is the tricky timing required to use horizontal blank usefully. That is why I haven’t made a lot of progress.
I would have hoped to add curvy roads eventually. The best would be up and down hill too but I haven’t figured out how to do it.

This post was submitted by remz.

coco3_zak.gif (15 KB)

This post was submitted by remz.

1 REM COPYRIGHT (C) T&D SOFTWARE 1984
2 GOTO60000
3 PMODE4:CLEAR1000,15599
4 HT=PEEK(27)*256+PEEK(28)-783
5 CLS:PRINT”THIS TEXT GOES TO GRAPHICS!”:EXEC HT
59999 END:RUN
60000 PCLEAR4:GOTO3

The code makes perfect sense to me until the “EXEC HT” thing. This seems to dump the text screen onto the first page of PMODE 4 … with no ML code to work with. I have no idea why.

Can anyone shed light on this? Thanks.

This post was submitted by RetroRick1974.

Let’s see some support for Roger’s excellent product by making more game disks!

This post was submitted by Robert Gault.

http://www.coco3.com/community/wp-content/uploads/2010/03/6x09_Instruction_Sets.pdf

Enjoy!

This post was submitted by DarrenA.

This post was submitted by hhos.

This post was submitted by remz.

I would like to know if the PIA ‘VSYNC FLAG’ and ‘HSYNC FLAG’ can be read on a CoCo 3 running a GIME video mode, such as 320x200x16 colors.
In order word: can I know the state of the vertical sync and horizontal sync without using interrupt, just by reading the PIA registers, like a pseudo-code while loop like this:
while(PIA.VSYNC == false) wait;
// Great, we are in VBLANK period: do something useful
…
while(PIA.VSYNC == true) wait;
// OK the vertical blank period is over, the screen begins to be traced.
…
I’ve done some test but I failed miserably.

Thanks!

This post was submitted by remz.

The mixing is very high quality, effectively mixing 3 channels at 23.5 KHz.
The music itself is converted automatically by a Perl script I wrote, which take a .SID and convert it into CoCoSID2 data. This new format features endless possibilities such as vibrato, portamento, attack/decay/sustain/release, etc.

One of the biggest challenge was fitting the song into the remaining space (in order to keep the file small enough so that a simple LOADM command loads both program and data simultaneously).
In fact the uncompressed complete song takes exactly 125952 bytes (123 KB).
Using two stages of compression, I managed to compress it down to 29478 bytes (29 KB). The music player uncompress data in realtime without any requiring memory. So making a CoCo 2 version is absolutely possible.

However since the music data takes so much space, I have removed the background image as it didn’t fit anymore.

This is the best sound I have ever heard a CoCo generate, even including the Orchestra-90 pak which sounded so “thin”.
I hope you enjoy it. As the first CoCoSID, I can gladly put the source code online too.
Thanks to everyone who helped creating this project!
Rem

This post was submitted by remz.

But what happened to me was having corrupted data which in turned led to a complete crash with an invalid opcode. Even worse the bug is somewhat random since the stack or corruption is not exactly the same each time I booted it up. Very annoying bug, since even MESS Debugger can’t help because when it ‘crashes’ on an illegal opcode, it simply stops working and doesn’t tell you anything about it. Arggh.

This post was submitted by remz.

The work was stimulated by a discussion of the GrafExpress package. The included program, Art, was of particular interest. This program appears to mix four levels of cyan, blue, red, and green to achieve 256 colors on screen at the same time. The method sets Palettes 0-3 to 0,16,32, and 48 which are black, dark gray, light gray, and white on a composite monitor. When seen on an NTSC monitor, artifact colors are created. How this technique works has been discussed in other threads on this site.

The most impressive results so far have come from hand creating a palette file for use with PC programs such as GIMP and Paint Shop Pro. Graphic files have been converted to BMP images, the palette colors changed to those displayed by the Coco, the images re-sized and aspect ratio adjusted, the BMP header removed, and the images save as .vef files.
This is a large amount of manual labor and the results, which are impressive, are completely dependent on the manually create palette file and how various PC programs reduce the number of colors to fit the new palette.

There ought to be a method for converting BMP palettes to composite artifacts automatically so that hand crafted palettes are not necessary. To make any progress in this direction, the actual colors displayed by the 640×4 mode must be known. It is very unlikely that these colors are cyan, blue, red, and green.
Paint Shop Pro and probably other programs will display both RGB and HSL color data during color adjustment of palette entries. The easiest way to visualize the HSL (ie. composite) color space is as a circle while RGB color space is a cube. If you look at the color “wheel” in Paint Shop Pro, you can see that if red is assumed to be the starting color, at 90deg is a yellow-green, 180deg cyan, 270deg purple, and 360deg returns to red.

As the Coco artifact colors of the 640×4 mode are synchronized with each byte, each byte must represent one color burst cycle. As there are four “primary colors” per byte they must be arraigned around the HSL color wheel in 90deg intervals. Therefore the colors must be those mentioned above for Paint Shop Pro.

The program, Art, can not be mixing more than one “pure” color as the RGB primaries are at 120deg intervals around the color wheel. Since the artifact colors are not true composite colors, we can’t use the Coco definition of CMP color xxIIPPPP to convert RGB to CMP. We also must realize that each time we add artifact “blue” or “green” we are also adding some red. Even more confusing is how to derive the value for cyan from an RGB palette.

At this point we should try to validate the above conclusions. One test would be to see what happens in the program, Art, when you blend the four main colors. Anyone in the audiance know what you get when you use additive colors and blend red with cyan? If you do that in Art, using full red and full cyan, you get light gray. How about blending blue and green? That you can do in Paint Shop Pro and the result not surprisingly is cyan. However with Art, “blue” mixed with “green” give almost the same color gray as obtained with red and cyan. Clearly the 640×4 mode is not producing blue and green for “primary colors”. It looks like the above conclusions are essentially correct about the nature of the four “primary colors” of the 640×4 mode.
That gives us a clue for a method of obtaining a value for the cyan entry from an RGB palette, we can added together the values for blue and green. This could also solve the problem presented by the presence of red in both the Coco “blue” and “green” colors. Cyan “cancels” out red so if we create cyan from the RGB BG values, we also reduce the effect of red from the purple and yellow-green Coco colors.

There is one other problem with the 640×4 artifact mode. The shape of the pixels is rectangular rather than round or square. In fact the pixel width is about twice the pixel height. This problem requires that each line be doubled on the Coco if a correction is not made on a PC when creating .vef files. However, this problem also offers the possiblilty to double the effective number of colors the 640×4 mode can display, while at the same time correcting the aspect ratio. When converting RGB palette colors to 640×4 artifact palette colors, any error can be used to change the color value for the duplicate pixel. The resulting image should look like a half-tone screening process used in commercial printing.

Well theory is one thing and programs are another. I’ve managed to write an assembly program to view true BMP files on a Coco3 using the 640×4 artifact mode. The program will work with either a 128k or 512k Coco3. A 640x225x4 screen is used but each horizontal line is 256 bytes long because HVEN is activated. The height of the image is limited by the amount of memory. The right joystick is used to scroll over the image. The program requires any graphic image on a PC to be reduced in size to a maximum width of 256 bytes,colors reduced to a maximum of 256, and the file saved in BMP format. You will find that the resulting file sizes will typically place a limit of two images per side of a 35 track Coco disk.

The zip file contains a .dsk image with several programs. The main program are HLOAD.BAS and HLOADDW3.BAS. These are Basic loaders for the ml program. They will ask which disk contains the bmp file and what is the file name. Use HLOAD if all disks will be mounted in a real Coco3 system. Use HLOADDW3 if the disks will be mounted on a PC with a Drivewire system. More details are in the DW3 version as remarks.
Also on the disk are several programs that create color charts demonstrating the possible colors. Viewing the charts on an RGB system or an emulator set for Composite display is informative. There are several image disks containing BMP files. Run on an emulator set for Composite will show the images in gray scale. An NTSC monitor or TV must be used to view the images in color.

bmpDemo.zip (304 KB)

This post was submitted by Robert Gault.

A Preprocessor for Disk Extended Color Basic for the CoCo 1, 2, 3 and their Emulators

Urbane is designed to allow any DECB program to be written without line numbers and with unique variables of any length. All DECB commands and functions are supported and version 1.060202 is considered complete and ready for use in writing any DECB program.

Roger Taylor has graciously agreed to host the files. Thanks Roger!

There are three files currently available:

Download These Two Files if you are just curious about what Urbane is:

1)Source Colorized by the ConTEX editor.
Use this file as an example how to write your own programs.

ubn_in.htm

2) The produced DECB program also Colorized by ConTEX.

ubn_out.htm

Download This Zip File if you wish to run the Preprocessor.
It includes a “dsk” file for the CoCo ready to run
and includes all files including the above two “htm” files.

urbane.zip

No shifting of shapes is required, eliminating pre-shifted shapes, coarse movement, or slower shifting on the fly operations. All in all, a gain I think.

Bit masking becomes an effect, rather than a draw tool. With multiple pixels in a byte, masking is needed to combine the on screen data with the sprite. Now, that can be used for overlay type graphics, like a map that doesn’t draw solid, but see through.

Probably the coolest thing is just not drawing transparent pixels. Having sprites of arbitrary size is easier, in that there isn’t a multiple of 8 factor to be combined with masking. It’s just pixels, loads and stores.

Sprite color data can be stored in a sequence thus:

Sample Space Ship Sprite

--#--       - = Transparent, not drawn
#@@@#       # = White
-###-       @ = Color

DATA $FF, $FF, $A0, $A0, $A0, $FF, $FF, $FF

Start with upper left pixel, which is transparent, encoding only “on” pixels, working to the right, then down in horizontal sweeps, ending at lower right.

Normally, the shape of a sprite is encoded in a bit pattern, with the color data coming from palette register settings. Color in the NTSC 256 mode is absolute. Write the value, get the color.

The shape of the sprite then is just a matter of STA operations, with a screen position index.

The easiest thing to do then, is to just encode the sprite with upper left “pixel” being start of screen, or 0 in the X and 0 in the Y, screen coordinate fashion.

                            0         0,159 = SCREEN +159($9f)
                            |                                 |
0,0 = SCREEN            0 - +-#-----> (+ x)    . . .       ---+
0,1 = SCREEN +160($A0)      #@@@#                             |
0,2 = SCREEN +320           |###                              |
        .                   |                                 |
        .                   |                                 .
        .                   |                                 .
                            V  (+ y)                             .
                            .                                 .
                            .                                 .
                            |                                 |
                            +---                           ---+
                                 159,199 = SCREEN +30719($77FF)


A Sprite Pixel address is calculated with (Y * 160 + X) + SCREEN

The sprite above is drawn at screen origin 0,0.

To draw it at a new origin of 10,10 do the math to get the address:

(10 * 160 + 10) = 1610 ($64A)

And add to the address of the graphics screen, SCREEN.

Individual sprite pixels are then just screen addresses, applying the same formula.

…or!

STA #SCREEN+2  , X  'Where X is the new origin calculated above
STA #SCREEN+160, X
STA #SCREEN+161, X   +--
STA #SCREEN+162, X   |
STA #SCREEN+163, X   |  Sprite "Shape" is just addresses
STA #SCREEN+164, X   |  Drawn at "X" origin
STA #SCREEN+321, X   |
STA #SCREEN+322, X   +--
STA #SCREEN+323, X


The actual drawing routine requires that the colors be loaded, unless the sprite colors are the same. In that case multiple STA operations can be used, or a STD operation to knock out two pixels more quickly.

This post was submitted by Potatohead.

CoCoDrawReadMe.txt (9 KB)

This post was submitted by Paul.

Enjoy!

Sprite Editor Disk.dsk (437 KB)

This post was submitted by Paul.

After being completely out of touch with the CoCo community for like 25 years, I’m finally getting back into it.

Back in the days, I had a printed copy of the BASIC interpreter in Assembly Language. All three, standard BASIC, Extended BASIC and DISK BASIC with some comments. Does anyone still have such monsters? I’d love to get back into Assembly Language. The most fun I had was tweaking the BASIC interpreter.

This post was submitted by Corey.

10 HSCREEN3:B=0:’ Try values of 0-8 for B
20 A=8:X1=B:Y1=0:GOSUB130
30 HLINE(X1,Y1)-(X2,Y2),PSET,B
40 HLINE(X1,Y1)-(X2,Y2),PSET
50 HLINE(X1,Y2)-(X2,Y1),PSET
60 W=X2-X1+1:H=Y2-Y1+1
70 HBUFF1,W*H
80 HGET(X1,Y1)-(X2,Y2),1:HCLS
90 FOR I=0TO7:X1=I:Y1=I*24:GOSUB130
100 HPUT(X1,Y1)-(X2,Y2),1,OR
110 NEXTI
120 GOTO120
130 X2=X1+32:Y2=Y1+20:RETURN

After trying the above program with several values of B, change line 130 so that X2=X1+31 and run the program with B=0. The corruption is caused because Basic uses different array sizes for HGET and HPUT as I progresses from 0-7.
The same problem exists with the PMODE GET/PUT as shown in the next example.

10 WIDTH32:PMODE4,1:PCLS:SCREEN1,1:B=0:’ Try values of 0-8 for B
20 A=8:X1=B:Y1=0:GOSUB130
30 LINE(X1,Y1)-(X2,Y2),PSET,B
40 LINE(X1,Y1)-(X2,Y2),PSET
50 LINE(X1,Y2)-(X2,Y1),PSET
60 W=X2-X1+1:H=Y2-Y1+1
70 DIM M(W,H)
80 GET(X1,Y1)-(X2,Y2),M:PCLS
90 FOR I=0TO7:X1=I:Y1=I*24:GOSUB130
100 PUT(X1,Y1)-(X2,Y2),M
110 NEXTI
120 GOTO120
130 X2=X1+32:Y2=Y1+20:RETURN

Don’t forget to change line 130 from 32 to 31 in the second half of the trials.

If you are now crushed, because the above seems to indicate that you can’t create sprites with GET/PUT or HGET/HPUT and smoothly move them around on the screen, there is hope. The Microsoft Basic used for PMODE screens has a feature that Microware left out of the HSCREEN code. You can use option G with the GET/PUT commands.
Let’s see what happens when option G is used in the next example.

10 WIDTH32:PMODE4,1:PCLS:SCREEN1,1:B=0:’ Try values of 0-8 for B
20 A=8:X1=B:Y1=0:GOSUB130
30 LINE(X1,Y1)-(X2,Y2),PSET,B
40 LINE(X1,Y1)-(X2,Y2),PSET
50 LINE(X1,Y2)-(X2,Y1),PSET
60 W=X2-X1+1:H=Y2-Y1+1
70 DIM M(W,H)
80 GET(X1,Y1)-(X2,Y2),M,G:PCLS
90 FOR I=0TO7:X1=I:Y1=I*24:GOSUB130
100 PUT(X1,Y1)-(X2,Y2),M,PSET
110 NEXTI
120 GOTO120
130 X2=X1+32:Y2=Y1+20:RETURN

Note that now the rectangle smoothly moves across the screen one pixel at a time without being corrupted. This is quite different from the one byte per move or corruption seen without the G option (PMODE) or with HGET/HPUT.

Is there an option equivalent to G that can be used with HSCREENs? Unfortunately not. The only recourse open to HSCREEN users short of writing some machine language code to emulate the PMODE software is to create multiple images for each pixel in a byte. So using HSCREEN3 with eight pixels per byte for example, eight images are needed to obtain smooth movement.

10 HSCREEN3
20 A=8:Y1=0:FOR I=0TO7:X1=I:GOSUB130
30 HLINE(X1,Y1)-(X2,Y2),PSET,B
40 HLINE(X1,Y1)-(X2,Y2),PSET
50 HLINE(X1,Y2)-(X2,Y1),PSET
60 W=X2-X1+1:H=Y2-Y1+1
70 HBUFFI+1,W*H
80 HGET(X1,Y1)-(X2,Y2),I+1:HCLS:NEXT
90 FOR I=0TO7:X1=I:Y1=I*24:GOSUB130
100 HPUT(X1,Y1)-(X2,Y2),I+1,OR
110 NEXTI
120 GOTO120
130 X2=X1+32:Y2=Y1+20:RETURN

Now it does not matter if you change line 130 as was done in the earlier examples.

This post was submitted by Robert Gault.

I included some sample sprites I made for a game I am making. This was the first in a series of BASIC applications to create and setup media for a BASIC video game. I am currently working on a board layout app. I need more memory for a board larger than 320×192.

Hope you enjoy.

BASIC SPRITE EDITOR DISK.dsk (437 KB)

This post was submitted by Paul.

I have just finished a “wolfenstein 3D” style raycasting demo for the CoCo 3. It took countless hours but I am very proud of the result. One of my goal was to try to get it as fast as SockMaster’s Gloom demo. Here are the main features and info:

- Optimized raycasting engine
- Fullscreen (256 x 192) in 16 colors, effective resolution is 128 x 192
- Rock-solid, ultra precise 16-bit math calculations
- Player to wall collision detection, with ‘sliding’ on wall
- Keyboard + Joystick simultaneous control: Analog joystick controls view, and keyboard controls movement
- Use classic shooter “W A S D” keys or regular arrows. Strafe left/right, move forward/backward
- 3D look up and down
- No ‘fish-eye’ effect: precise perspective correction
- Fast delta segment rendering: approx. 15-20 frame per second
- Small executable: almost everything is calculated at runtime
- “Unlimited” view distance: limited only by maze size.
- No clipping
- Works on plain  CoCo 3 with 128KB

Download link for the .DSK here: The file is called “WOLF.BIN”:

http://www.coco3.com/community/wp-content/uploads/2009/12/REMDISK_Wolf_demo.zip

Comments are welcome!
Thank you very much,
Rem

This post was submitted by Paul.

I’ve been playing with a different technique which uses a single image screen but swaps the palette registers through three different sets of colors. This also has a flicker and again the intensity depends on relative screen brightness.
I thought that if the swap of palettes could be made more frequent, say in the horizontal blanking pulse, the flicker would be reduced because of the drastic rate increase.

Now here is the question, why is the flicker unchanged or slightly reduced with the 60Hz swap rather than the 15kHz swap? This is counter intuitive and I don’t know the answer.

You can look for yourselves as the enclosed zip file contains a test program and an image disk. Use a real Coco3 or and emulator. Give the image some time to load as it is large.

BMPSHOW.zip (98 KB)

This post was submitted by Robert Gault.

I have just finished coding a sprite demo engine for the CoCo 3, it has been uploaded here:
http://www.coco3.com/community/wp-content/uploads/2009/11/REMDISK_Sprite_Demo.zip

The demo features:
- Fullscreen resolution of 256×192 in 16 colors
- Fast and smooth scrolling background
- Up to 8 sprites, 16×16 pixels, with transparency support
- Very large background: 5440 pixels wide by 192 pixels = 522240 bytes of graphic compressed using tile maps
- 60 frames per second at all time
- Multiple animated background tiles
- Runs on a stock CoCo 3 with 128KB
- Color palette designed for RGB monitor

To control the demo:
At startup, the demo displays 6 sprites. You can’t control them, they circle around the screen.
Move joystick to the right to scroll (scrolling only works in one direction)
Use joystick buttons to add or remove sprites: Button #0 add 1 sprite (up to 8 on the screen), Button #1 remove 1 sprite.

Known bugs or limitations:
- When removing a sprite, sometimes a little bit of ‘garbage’ may be left on the screen
- Some sprites may flicker slightly when reaching the top of screen while scrolling, with background animated tiles.

The source code is 37,779 bytes long and took me countless hours to optimize. I believe this demo can prove a CoCo 3 is so versatile it could outperform a Commodore 64 at graphics.

Comments and suggestions are welcome!
Thank you,
Rem

This post was submitted by remz.

My question is: is there a way to scroll only 1 pixel, or maybe scroll 1 byte instead of 2?
(I mean without having to copy the whole screen, which would require at 256x192x4bpp = 24576 bytes x 60 fps = 1474560 bytes per second of memory copied: impossible on a 1.79 MHz CoCo 3)
Thanks!

This post was submitted by remz.

This post was submitted by beretta42.

This post was submitted by remz.

At any rate, a few of the simple assembly programs I was writing back in the day were on hold anyway, since I am just lousy ad dividing two numbers.  I don’t need precision, don’t even need a decimal place usually, I just want to take a couple integers and get an integer result, with maybe the first “remainder” stored somewhere just in case I feel like rounding.

Anyone have some simple examples of how do divide on the coco?  I’m assuming (might feel dumb here) that there isn’t a div opcode.  If there is, I’d better go re-read the 6809 manual…

-sc

I just finished my first version of a fast 2D scaling demo for the Coco 3. I have uploaded the .BIN here:
http://www.coco3.com/community/wp-content/uploads/2009/10/scale.zip

I would really like to hear your feedback about it! Use the left joystick to control vertical and horizontal scaling.
And again, thanks to Robert for his support on the joystick input part.

Rem

MESS_scaling_demo.jpg (110 KB)

This post was submitted by remz.

Try this out. It will print on the screen the type of CPU present.

“Dan H. Eicher” wrote:
>
> Does anyone have a short basic program I can type in to find out which CPU I
> have in my coco 3?
>
> Thanks,
> Dan

10 ‘ 6309/6809 CPU ID PROGRAM
20 ‘ FOR THE COCO/COCO III
30 ‘ AND DRAGON 32/64
40 ‘ BY STEPHEN J WOOLHAM
50 ‘
60 START=&HD00
70 FOR I=START TO START+15:READ A$:POKE I,VAL(“&H”+A$):C=C+PEEK(I):NEXT:IF C<>1363 THEN PRINT”ERROR IN DATA LINE”:END
80 EXEC START
90 IF PEEK(157)=3 THEN CPU$=”6309″ELSE IF PEEK(157)=9 THEN CPU$=”6809″
100 PRINT”A “+CPU$+” CPU IS PRESENT…”:END
110 DATA C6,FF,10,4F,5D,27,04,86,9,20,2,86,3,97,9D,39

Stephen Woolham
SJWoolham@Hotmail.com

http://www.fortunecity.com/skyscraper/disk/162/ ]]> http://www.coco3.com/community/2009/10/how-to-check-which-cpu-is-inside-the-coco/feed 2 http://www.coco3.com/community/2009/10/reference-list-of-pokes-peeks-and-execs http://www.coco3.com/community/2009/10/reference-list-of-pokes-peeks-and-execs#comments Mon, 05 Oct 2009 00:24:15 +0000 Roger http://www.coco3.com/community/?p=24974 The following is a list of Coco 1 and 2 (should also work on the 3) pokes which were published in the Saskatoon Color Computer User’s Group newsletter, March 1986. Originally they were taken from The Color 80 Journal newsletter published by the Adirondiack Color Computer Club in New York state. These might work on a Dragon too- please let me know.I should also mention that I have added several pokes which were suggested by people who have viewed this list on the internet.

Important Ones

• POKE 65497,0 on Coco 1 and 2
  

  double speed of RAM and ROM. It will cause your screen to fill with garbage, and sometimes causes memory to disappear. Printer, disk and cassette functions won’t work.

• POKE 65497,0 on Coco 3
  

  double speed of RAM and ROM. Printer, disk and cassette functions won’t work.

• POKE 65496,0
  

  puts machine from double speed ROM and RAM back to normal speed.

• POKE 65495,0
  

  doubles speed of ROMs; Basic programs by 1 and a half. Does not work with all computers, or with disk, cassette or printer operations.

• POKE 65494,0
  

  puts ROMs and Basic back to normal speed. Cassette, printer and disk works normally.

• POKE 65315,54
  

  disables cartridge takeover, allows you to put in a Rompack without it starting up. NOTE: the use of this poke to put in a cartridge with the machine power on can cause damage to your computer. It’s use is not recommended.

• ?PEEK(487)*256+PEEK(488)
  

  start address of last machine language program loaded off of cassette

• ?PEEK(126)*256+PEEK(127)
  

  end address of last machine language program loaded off of cassette

• To put a 64K Coco into all RAM mode, where the ROM can be modified:
  

  RESTORE: FOR I=3584 TO 3584+24:READ A:POKE I,A:NEXT:EXEC 3584: DATA 26,80,142,128,0, 166,132,183,255,223,167,128, 140,224,0,39,5,183,255,222,32, 239,28,175,57

POKE &H95C9, &H57: POKE &HFF22, &H50 Coco 3 Green border
POKE &H95C9, &H17: POKE &HFF22, &150 coco 3 Black border
FOR X = 442368 TO 446225: POKE X,32: NEXT Forces lowercase on 32-column mode on the CoCo 3
POKE 149,4:POKE 150,88 Sets printer baud to 50
POKE 149,2:POKE 150,227 Sets printer baud to 75
POKE 149,1:POKE 150,246 Sets printer baud to 110
POKE 149,1:POKE 150,153 Sets printer baud to 134.5
POKE 149,1:POKE 150,110 Sets printer baud to 150
POKE 149,0:POKE 150,180 Sets printer baud to 300
POKE 149,0:POKE 150,87 Sets printer baud to 600
POKE 149,0:POKE 150,40 Sets printer baud to 1200
POKE 149,0:POKE 150,25 Sets printer baud to 1800
POKE 149,0:POKE 150,23 Sets printer baud to 2000
POKE 149,0:POKE 150,18 Sets printer baud to 2400
POKE 149,0:POKE 150,10 Sets printer baud to 3600
POKE 149,0:POKE 150,7 Sets printer baud to 4800
POKE 149,0:POKE 150,3 Sets printer baud to 7200
POKE 149,0:POKE 150,1 Sets printer baud to 9600
POKE 155,X (16,32,64,132,255) Sets printer width to X
POKE 111,254:DIR sends directory to printer
PEEK(65314) returns an even number if printer is on / odd if off
POKE 41382,188 generates a blinking cursor
POKE 41923,0 disables break key on INPUT/LINEINPUT, must be in all RAM
POKE 41923,3 restores break key operation, must be in all RAM
PEEK(25)*256+PEEK(26) basic program start address
PEEK(106) comma column width
PEEK(116) 127=32k computer, 63=64k computer
PEEK(170) 0 if trace flag on
PEEK(148) current cursor color, 1-11
PEEK(182) current PMODE, ECB only
PEEK(188) 14=disk system, 6=cassette system
PEEK(230) DLOAD baud rate
PEEK(282) 0 if in lowercase mode
PEEK(32768) 69=ECB computer
POKE 359,57 keeps the computer on the last SCREEN command
used, until another SCREEN command is used.
example: it will stay on the high-res screen
SCREEN 1,1 until SCREEN 0,1 is typed in
POKE 25,6:NEW PCLEAR 0 in extended Basic
POKE 25,14:POKE 3584,0:NEW Pclear 0 in Disk Extended Basic
POKE 65314,8 does a SCREEN 0,1 without Extended Basic
POKE 65314,0 does a SCREEN 0,0 without Extended Basic
POKE 178,X when put before graphics commands in Extended
Basic (Except PCLS) it will create different
colours and patterns.
POKE 186,X if X is an even number from 2 to 128, it will
move the pointer to the start of the Hi-res
screen, and allows viewing in 1/2 pages
POKE 45,0:POKE 46,0 disables the CONT function after BREAK
POKE 113,0 cold start when RESET is pressed
POKE 113,85 regular restart after POKE 113,0
POKE 148,0 stops flashing cursor for 3 seconds
POKE 175,79 same as TRON, ECB only
POKE 280,PEEK(275) true random numbers
POKE 282,0 enable lowercase
POKE 282,255 enable uppercase
POKE 283,X slows keyboard response, X=speed, 1 is fastest
POKE 283,4 normal keyboard response
POKE 293,0 disable ECB and CB commands
POKE 293,20 reverses POKE 293,0
POKE 65313,0 motor on
POKE 65313,52 motor off

GAME CHEATS
===========
Replace X with number in range.

3D Brickaway POKE 13648,X (1-255) # of men
Astro Blast POKE 17351,X (1-255) # of men
Cashman POKE 28302,X (1-255) # of men for player A
Donkey King POKE 12914,X (1-255) # men in Normal game
POKE 12904,X (1-255) # men in Practice game
Dunkey Munkey POKE 15121,X (1-100) # of men
Electron POKE 14019,X (1-255) # of men
Food War POKE 10307,X (1-255) # of men
Fury POKE 13951,X (1-255) # of men
Galagon POKE 10250,X (0-255) speed of first wave
POKE 15621,X (0-255) speed of second wave
Ghost Gobbler POKE 9075,X (1-255) # of men
POKE 10860,0 9000 pt. bonus shape (v1.5 only)
POKE 10870,0 3 ghosts trapped (v1.5 only)
POKE 11678,255 black background
Grabber POKE 16018,10 255 men
Katerpillar Attack POKE 10793,X (1-255) # of men
Kron POKE 16902,4 255 men
LunarRover Patrol POKE 22369,X (1-255) # of men
Mr. Dig POKE 21561,X (1-255) # of men
Mudpies POKE 29679,X (1-100) # of men
Pac-Tac I POKE 9009,X (1-255) # of men
Planet Invasion POKE 7446,X (1-40) # of men
Protectors II POKE 8464,X (1-100) # of men
Space Race POKE 10605,X (1-100) # of men
The Frog POKE 12002,X (1-255) # of men
Trapfall POKE 11452,X (1-255) # of men
Tutankam POKE 17437,X (1-100) # of men
Whirlybird Run POKE 8312,X (1-255) # of men
Zaxxon POKE 25624,X (1-255) # of men
Zaksund POKE 16670,X (1-255) # of men

16 41256 (256K x 1) DRAM chips These should preferably be 150 or 120 ns acess speed, although faster chips (100 ns or faster) will likely work just fine, too.

4 18 pin DIP headers, of a size that will plug into the four 18 pin memory sockets on the CoCo 3. A Machine Pin style 18 pin socket may work fine for this purpose. Machine Pin style 20 pin sockets can, of course, be hack-sawed into 18 pin sockets.

4 .1 to .47 mfd (I recommend .33 or .47 mfd) capacitors, physically very small in size (the size of a match-head is best).

One short piece of wire.

Approach:

What you will do is make four QUADRUPLY STACKED sets of memory chips. That is, you will be making four, four-chip-high piggybacks on top of the four 18 pin headers. Most of the pins will go straight thru and be soldered to the pins of the chip or header below them. However, a few pins will be re- routed.

Bend straight out (horizontally) pins 1,2, and 14 of a 41256 DRAM chip. Bend pin 16 of that DRAM chip “forward” so it reaches just a bit outward in the direction of the length of the 41256 chip.

Line up the chip over the 18 pin header, so that pins 1 and 16 of the DRAM chip lie over pins 2 and 17 of the header. See to it that pin 16 of the 41256 is bent in such a way that it can make contact with pin 18 of the header.

Solder pins 3,4,5,6,7, and 9 of the DRAM chip to pins 4,5,6,7,8, and 9 of the header. These pins will be going STRAIGHT DOWN, unbent.

Solder pins 9,10,11,12,13, and pin 15 of the DRAM chip to pins 10,11,12,13,14, and pin 16 of the 18 pin header. These pins will be going straight down.

Solder pin 16 of the DRAM chip to pin 18 of the header. This requires that pin 16 be bent a bit “forward”, as noted above. You might want to put a “dog leg” type bend in it to keep it from contacting pin 17 of the header.

Prepare three more 41256 chips in a similar fashion, EXCEPT don’t bend forward or out pin 1 or 16. Leave pin 16 alone. Now stack those three chips on top of the chip and header you prepared, one on top of the other. Attach pin 1 of the chips to pin 1 of the lowest chip, and attach pin 16 of the chips to pin 16 of the chip below it. Note that all the pin 16′s are routed to pin 18 of the header, and that all the pin 1′s are routed to the pin 1 of the lowest chip, which in turn is NOT hooked to the header, but instead is bent out.

Now, using wire wrap or other small gauge wire, join on each chip pins 2 and 14. Run wires from the joined pins 2 and 14 of each individual chip to pins 2,3,15, and 17 of the 18 pin header. It does not matter what pair of joined pins goes to what pin of the header… just be sure that each of those four header pins is connected to a pair of joined pins 2 and 14 from one of the four DRAMs in the stack.

Now solder on top of the stack the little capacitor, hooking one side of the capacitor to pin 8 of the DRAM chip and the other side to pin 16 of the DRAM chip at the top of the stack.

Make up a total of four such stacks as above.

Note that you will likely find it easiest to clip off the narrow part of the horizontally bent out pins, leaving just the fat part of them to solder to. This may in fact be necessary to keep the pins from hitting each other when the stacks are installed.

Now plug each of the four stacks into the four 18 pin DRAM sockets in the CoCo 3.

Solder short wire jumpers between the joined pin 1′s of each of the four stacks.

Solder a wire from the joined pin 1′s of all 16 DRAMs to a plate thru solde r pad just in FRONT of pin 11 of CN4 on the CoCo 3 mother board. This is the missing address line used in the 512K upgrade.

The plate thru pad in question is located very near CN4, between CN4 and CN 2 CN 4 is a 12 pin socket used for part of the 512K memory board, and CN 2 is th e socket for the keyboard of the CoCo 3. Be SURE to remove the keyboard of the CoCo 3 before doing this, else you risk destroying the ribbon cable of the keyboard when you try to solder to the CoCo 3 mother board.

Your CoCo will look a bit weird, as if there are four “high rise towers” in the memory chip sockets. However, if you carefully follow these instructions, you SHOULD get out of this a 512K CoCo 3.

Reference Information:

Pin out of 41256 chip compared to pin out of 4464 chip socket in CoCo 3:

               41256   4464               ------------                        1  *OE  (not used by CoCo 3   tied high  Ignore     extra adr  A8  1   2  I/Oa  bi directional I/O line      Data In   Din 2   3  I/Ob  bi directional I/O line                *WE 3---4  *WE   write enable               *RAS 4---5  *RAS  Row Address Strobe                adr 5---6  adr   address line                adr 6---7  adr   address line                adr 7---8  adr   address line                Vcc 8---9  Vcc   +5 volts

               adr  9--10  adr               adr 10--11  adr               adr 11--12  adr               adr 12--13  adr               adr 13--14  adr    data in    Din 14  15  I/Oc  bidirectional I/O line              *CAS 15--16  *CAS  Column Adress Strobe      ground   gnd 16  17  I/Od  bidirectional I/O line                     \-18  gnd   ground

What is going on here is that the Din and Dout of each 41256 is connected t o each other, and those two joined pins are then connected to one of the bidirectional I/O lines of the header. The one extra address line (pin 1 of a ll 16 chips) is hooked to the mother board so that it can connect to that address line of the GIME chip’s memory management section. Finally, pin 1 of the 4464 chips is not actually used, for it is an enable line that is grounded all the time. Therefore, we can ignore the fact that the 41256 lacks such a line. It is a great pity we could NOT use four 44256 chips to upgrade the CoCo 3 to 512K memory. This would have eliminated the hassel of staking chips four high . However, the refresh cycle for 44256 chips is 512 cycles, and the durn GIME ch ip in the CoCo supports only 256 cycle refresh. One would need special extra circuitry (like that on the Disto 2 meg upgrade) to use such chips.

I have successfully upgraded one CoCo 3 to 512K in this fashion. It’s AWFULLY tedious.

—marty MARTYGOODMAN on Delphi
MARTYGOODMAN@DELPHI.COM on Internet
Please share this article freely with all.

P.S. minor typo: pin 14 of the 41256 is a Dout, not a “Din” line. All Din lines of a given 41256 chip are shorted to the Dout line of that chip in the CoCo 3 memory circuit.

I’ve set up the “DK” header and made a rom image from $C000-$FFFF (I’ve left the last 16 bytes blank).

When I try it in MESS, it works in the CoCo 1/2 modes, but…

1. With “old” Color BASIC, it does not autostart. I have to type EXEC 49154, is this normal?
2. It does not work in any CoCo 3 mode. It starts with a little bit of corruption on screen (some interrupt?), then crashes into a CoCo 3 text mode. Are there any special considerations on a CoCo 3?

Thanks.

This post was submitted by Jmk.

POKE 62861,189:POKE 62862,244 fixes the HDRAW bug

POKE &HE649,&H10 fixes the RGB and BMP commands

POKE 55180,18:POKE 55181,18:POKE 55182,18 turns of disk drive moter faster

POKE 38543,33:POKE 38563,33 fixes PCLEAR 0 error. Now you can
PCLEAR 0 and get 28941 bytes of free
MEM!!

POKE &HF670,18:POKE &HF671,18 prevents a WIDTH command from clearing
the screen

POKE &HA1C1,&H39:FOR F=&HA1CA to &HA1C1
STEP -1:READA:POKE F,A:NEXT F:DATA 121,39,
72,67,0,255,182,2,255,127 put as the first line of your program
it will speed up your computer by about
15%!! It patches the keyboard scan routine

FOR I=&H8000 to &H8013:READ B$:POKE I,VAL
(“&H”+B$):NEXT I:POKE &H85CB,&HBD:POKE
&H85CC,&H80:POKE &H85CD,0:DATA 86,21,BD,
A2,82,A6,84,BD,A2,82,86,21,BD,A2,82,BD,85,
D1,5A,39 patches the D command during EDIT to
show the character being deleted!

FOR I=&H8014 TO &H8022:READ B$:POKE I,VAL
(“&H”+B$):NEXT I:POKE &HAB85,&H80:POKE
&HAB86,&H14:DATA 10,27,2D,CC,BD,AF,67,BD,
AD,01,9E,47,7E,AD,E6 patches the RESTORE command so you can
restore to any line number. For example,
RESTORE 40 restores any DATA from line 40
on, but no DATA prior to line 40. A plain
old RESTORE still restores every DATA
statement

—————————————————————————————
COCO 3 POKES, PEEKS, and EXECS

MEMORY MAPPING AND THE 8K BLOCKS
DECIMAL VALUES
MMU Address Mapped to Usually is Hi-Res-Mode
&HFFA0 &H0000 – &H1FFF 56 56
&HFFA1 &H2000 – &H3FFF 57 48
&HFFA2 &H4000 – &H5FFF 58 49
&HFFA3 &H6000 – &H7FFF 59 50
&HFFA4 &H8000 – &H9FFF 60 51
&HFFA5 &HA000 – &HBFFF 61 61
&HFFA6 &HC000 – &HDFFF 62 53
&HFFA7 &HE000 – &HFFFF 63 63

Blocks 48 to 63 (&H30 to &H3F) are available on both 128k and 512k CoCos.
They can also be numbered 112 to 127 (&H70 to &H7F). Blocks 0 to 47
(&H00 to &H2F) are available ONLY on the 512k CoCo. They can also be
numbered 64 to 111 (&H40 to &H6F) The numbers can be used interchangeably
because the blocks are “shadowed”. Block &H3F is the same block as &H7F.
On a ONE MEG CoCo, though, the blocks are NOT shadowed, and the numbers
represent different blocks. See diagram further down.

WHAT ARE THE BLOCKS USED FOR?

Decimal Hex Function
112 &H70 first quarter of HSCREEN
113 &H71 second quarter
114 &H72 third quarter
115 &H73 fourth quarter
116 &H74 HGET/HPUT buffer (default)
117 &H75 The Stack
118 &H76 Hi-Res Text Screen (40 and 80 column)
119 &H77 unused
120 &H78 Program storage
121 &H79 Program storage
122 &H7A Program storage
123 &H7B Program storage
124 &H7C Extended Color BASIC (in RAM)
125 &H7D Color BASIC (in RAM)
126 &H7E Cartridge Address
127 &H7F CoCo 3 Super Extended BASIC, and I/O

Memory Block Map

&H00 to &H3F 64 8k blocks in 1 MEG CoCos (I think)
&H40 to &H6F 48 8k blocks in a 512k CoCo (48x8k=384k)
&H70 to &H7F 16 8k blocks in all CoCo 3s (16x8k=128k)
&H80 to &HFF 128 8k blocks in 2 MEG CoCos (I think)

In summary, ALL CoCo 3s have blocks &H70 to &H7F available. In a 512k CoCo 3,
you have &H40 to &H7F available. In a 1 MEG CoCo 3, you have &H00 to &H7F,
and in a 2 MEG CoCo 3, you have &H00 to &HFF available.

&HFFB0 to &HFFBF contain the palette registers. PEEK and POKE to these to
set the 16 palettes. Values range from 0 to 63.

POKE 63372,x controls the cursor blink rate in the 40/80 screen. The
default is 11. 0=fast, 255=slow

POKE 63381,0 stops the cursor blinking in 40/80 screens
POKE 63381,1 starts it blinking again

POKE &HF7A3,x x is from 0 to 255, it sets the shape of the cursor in 40/80 screens

PEEK(487)*256+PEEK(488) the start address of an ML program
PEEK(126)*256+PEEK(127) the end address of an ML program
PEEK(157)*256+PEEK(158) the EXEC address of the program

POKE &HFF21,&H3C immediately turns on the cassette relay (MOTOR ON)
POKE &HFF21,&H34 immediately turns off the relay (MOTOR OFF, but no delay)

&HE654 to &HE663 storage of the default CMP palette values
&HE664 to &HE673 storage of the default RGB palette values
&HE674 to &HE687 storage of current palette values

POKE 150,x set printer baud rate. 87=600, 41=1200, 18=2400, 7=4800, 1=9600
if running in high speed (1.8mhz) baud is doubled also!

POKE &HFFBC,x POKE here to set the width 32 foreground color
POKE &HFFBD,x POKE here to set the width 32 background color

EXEC 44539 pauses and waits for any key press (except BREAK/SHIFT/ESC)

POKE 65497,0 1.8mhz speed POKE for the CoCo 3 (no effect with emulator)
POKE 65496,0 normal speed POKE (.89mhz) for CoCo 3

POKE &HE6C6,33 VERY USEFUL – This disables the automatic clearing of the
HSCREEN. Usually, when you do an HSCREEN command, the CoCo
automatically clears the HSCREEN. This POKE prevents that.

POKE 282,255 set keyboard to uppercase
POKE 282,0 set keyboard to lowercase

&HF09D to &HF39C location of data for the HPRINT character set (8 bytes per
character, 96 characters). You can modify the HPRINT font
by changing these values. If you’re not using HPRINT, this
is available space for ML programs. (768 bytes, 3/4K)

POKE 186,msb
POKE 187,lsb set the start address for the PMODE 3/4 screen

POKE 113,0:EXEC &H8C1B
POKE 113,0:DLOAD |– three different ways to cold-start a CoCo 3
POKE 113,0 /

POKE 111,254:DIR forces a disk directory to be printed on the printer

if you PEEK(&H00E7) you can tell what the WIDTH is (0=32, 1=40, 2=80)

&HE0D4,&HE3A3, &HE50B poke these with an 8k block number for HGET/HPUT
the default is &H74

PEEK(41)*256+PEEK(42) the line number to continue after a STOP command

PEEK(49)*256+PEEK(50) the line number of the next DATA statement to be read

PEEK(135) the ASCII code of the most recently pressed key
can be used with EXEC 44539 instead of INKEY$

POKE 175,0 turn tracer on (TRON)
POKE 175,1 turn tracer off (TROFF)

decimal 338 to 345 the keyboard rollover tables – values change based on what keys
are being held down

if PEEK(341)=191, then the ALT key is being pressed
if PEEK(342)=191, then the CTRL key is being pressed
if PEEK(343)=191, then F1 is being pressed (F11 on the emulator)
if peek(344)=191, then F2 is being pressed (F12 on the emulator)

PEEKs 474 to 481 contain ASCII values of most recently used FILENAME (8 characters)
PEEK(482) contains file type (0=BASIC, 1=DATA, 2=BINARY)

POKE &HD7C0,x:POKE &HD816,y disk drive step rate (not for ADOS)
x=3 y=23 for 30ms (default)
x=2 y=22 for 20ms
x=1 y=21 for 12ms
x=0 y=20 for 6ms (most drives can do this, it’s faster and quieter)

44014 to 44018 ASCII values used for the prompt “OK”. You can change the OK prompt
POKE 44014,0 no prompt at all, just a cursor

EXEC 43345 makes a click sound

POKE 41598,19:POKE 41591,95 the BREAK key now pauses (same as SHIFT-@) and
SHIFT-BREAK will act as the BREAK key

POKE &HE414,0:POKE &HE42A,0 disables the CoCo 3 BREAK key

A=RND(-TIMER) use this to get “more-random” numbers from the RND statement
similar to RANDOMIZE on other computers

POKE &HE79B,196:POKE &HE79C,x where x is from 0 to 255. This changes the HPAINT
command to paint a variety of patterns
POKE &HE79B,212:POKE &HE79C,181 the defaults for the HPAINT command

After POKE &HF6BC,255, you can CLS x where x is from 0 to 255 to clear the 40/80
screens with a variety of attributes

&H01DA to &H02D8 the old cassette buffer, which can be used for short ML programs
it’s 255 bytes long

POKE 41893,0 disables the CLEAR key
POKE 41893,129 enables the CLEAR key

POKE 41909,0 prevents SHIFT-BACK-ARROW from erasing the entire line
POKE 41909,21 enables the SHIFT-BACK-ARROW

POKE &HADEB,&H39 prevents SHIFT-@ from pausing programs, speeds up the program!

POKE &HFE04,x where x is the column spacing you want (20,40,80,etc.)

POKE &HFF94,x where x is from 0 to 255, controls the “blink” attribute blink rate
POKE &HFF94,126 the default “blink” attribute blink rate

POKE &HD762,x where x is 1 to 255. This controls how many times the disk drive
tries to read a “problem” with the disk. The default is 5, but if
you set it to 1 or 2, the computer will try fewer times. If you have
ever accidentally typed, for example, DIR 1, but had no disk in the
drive, the computer tries 5 times to read it. By changing this value,
it will return to the OK prompt sooner, or try longer, if you want.

POKE &Hf697,x where x is from 0 to 255. Default is 32. When you CLS on a 40/80
screen, this is the ASCII of the character used to clear the screen.

16-bit Xmodem-CRC calculation
6809 opcode by Roger Taylor

Enter with reg.A being the current byte received or transmitted within your packet

04110 ADC010    EORA    CRC
04120     LDB    CRC+1
04130     ASLB
04140     ROLA
04150     BCC    ADC020
04160     EORA    #16
04170     EORB    #33
04180 ADC020    ASLB
04190     ROLA
04200     BCC    ADC030
04210     EORA    #16
04220     EORB    #33
04230 ADC030    ASLB
04240     ROLA
04250     BCC    ADC040
04260     EORA    #16
04270     EORB    #33
04280 ADC040    ASLB
04290     ROLA
04300     BCC    ADC050
04310     EORA    #16
04320     EORB    #33
04330 ADC050    ASLB
04340     ROLA
04350     BCC    ADC060
04360     EORA    #16
04370     EORB    #33
04380 ADC060    ASLB
04390     ROLA
04400     BCC    ADC070
04410     EORA    #16
04420     EORB    #33
04430 ADC070    ASLB
04440     ROLA
04450     BCC    ADC080
04460     EORA    #16
04470     EORB    #33
04480 ADC080    ASLB
04490     ROLA
04500     BCC    ADC090
04510     EORA    #16
04520     EORB    #33
04530 ADC090    STD    CRC
04540     RTS

The following extensions often show up in the CoCo World. Here’s what they are:

AR compressed file, using the AR utility by Carl Kreider, (uses LZ compression)

ARC file compressed with TC.BIN and later versions of “The Compressor” series

ASM the assembly language source code from EDTASM

BIN a binary file, usually a machine language program that needs to be LOADMed

BAS a general BASIC file (could be tokenized, or in straight ASCII format)

CAS virtual cassette file for use with Jeff V.’s CoCo Emulator

CM3 CoCo Max 3 compressed graphic file. CM3 is a highly efficient horizontal and vertical
compressor (or so the literature tells us)

EC# Projector-3 command file, the # can be 0-9 or A-Z where the character pressed along with [ALT]
from within Projector-3 will perform the function coded in the file. MIRROR.ECM is a command
that takes the current picture and flips it horizontally

DAT generic extension for data of some sort

DOC generic extension for files that contain information documents about how to use a program

DSK although not found on a CoCo disk, the DSK files are common with Jeff Vavasour’s CoCo
emulator. The DSK file is a Windows/DOS file that contains the data from a real CoCo disk.
The DSK file can either be changed back into a real 5.25 CoCo disk, or used as-is with the
emulator.
DSK ** There is also a CoCo utility called DSHRINK that will create DSK files from a standard
CoCo 35 track disk (under RS-DOS). This DSK file contains the entire contents of the disk.
The two DSK files ARE NOT interchangeable. **

FMT format driver file for the Projector 2 series multiviewer, can be added or removed from the
system disk to customize the program to handle whatever picture formats you want or have

GIF Graphic Interchange Format, generally the standard graphic format for ALL computers,
although being replaced by TIFF (Tagged Image File Format) GIF was developed by CompuServe.
GIF 87a is the basic standard, but it was extended to 89a to include embedded text- that is,
a message/note of text that could be viewed during/after seeing the picture. The note might
be the title, the creator, a BBS or Internet address, etc. GIF89a also added transparency,
animation, and timed looping.

HLP generic extension for help files

LZH identical to the MS-DOS LZH compression, ported to CoCo

MAX CoCoMax 1 and 2 picture format, is close or identical to the old CoCo 2 .BIN PMODE format

MGE Color Max 3 “compressed” graphic file. MGE used some sort of alternating compressed/
uncompressed runs of data. Rumor has it that sometimes the compressed file was even
larger than if the file hadn’t been compressed, so it was advised to keep the compression
switched off (a menu option) Standard 320×192 pictures are 14 granules long (about 30k)

NIB a graphic file format developed by Rick Cooper for CFDM. FYI, NIB used a rather complex,
but efficient method of using two data buffers, filling one with information about changes
in the current pixel, and the second with what the change was. The data was then combined
and compressed again (I think using some sort of RLE) and saved to disk. NIB was “extended”
by (me) Stuart Wyss to be fully backwards compatible, but to also support embedded text
(like GIF89a), 640×192, forced color sets, and color-cycling (to support CoCo Max animation)

PAK (not to be confused with Emulator PAK files) was a compression developed by G.B. Jansen

PAK (not to be confused with G.B. Jansen’s PAK) is an MS-DOS extension of files from Jeff V.s
CoCo emulator. A PAK file could either be a “snapshot” of the system, or a program pack.

PIX yep, a graphic file, belonging, I think, to Apple Macintosh

PM4 standard 6k/12k PMODE dump, same as the .BIN format but some older versions of the Projector
series graphics viewers may require this extension instead

RAT The RAT Graphics Design Package picture format, viewable by the Projector series viewers

RLE a graphic file compressed using Run Length Encoding

SQS a graphic file format developed by (me) Stuart Wyss (SQS is short for Squash) FYI, SQS was
a sort of “windowing” compression format that compared subsequent lines. It worked pretty
well.

SQZ another graphic file format developed by Rick Cooper for CFDM (SQZ is short for Squeeze)

TC3 a file/group of files compressed using the TC3 compressor

TNY graphic file format for the TINY program (possibly AMIGA format)

TXT generic extension for text files

VEF OS-9 graphic format, may be compressed or uncompressed. Compressed VEFs are sometimes
called “Squashed VEF”.

ZIP The standard for file compression in the MS-DOS/Windows world, available for CoCo.

NOTE: This is a guide only. Programmers often make up their own extensions, or use one or two
regardless of what the file actually contains. For example, BIN is a very common extension. It
can be a program that needs to be run, a low-res picture file, data for a program, music, etc.

A file consists of:

1. a leader
2. a filename block
3. a 1/2 second gap
4. another leader
5. some number of data blocks
6. an end-of-file block

A leader is just 128 bytes of $55 (binary 01010101). There should be no gap at all between the end of the leader and the beginning of the block that follows it. In fact, If the “gap” flag in the filename block is $01, I think there should be no gap at all between any two blocks, with only two exceptions: the gap that precedes the file, and the gap following the filename block. There must be a leader after each of those gaps to re-establish timing. If that gap flag is $FF, then there seems to be a 1/2 second gap and another leader before every data block and before the end-of-file block.

A block contains:

1. two “magic” bytes (55 and 3C)
2. one byte – block type (00=filename, 01=data, FF=EOF)
3. one byte – data length (00 to FF)
4. 0 to 255 bytes – data
5. one byte – checksum (sum of data, type, and length bytes)
6. another magic byte (55)

The three different types of blocks contain different amounts of data. A filename block contains fifteen bytes of data; an EOF (end-of-file) block contains no data bytes at all; and a data block may contain anywhere from 0 to 255 bytes, as indicated by the length byte.

The data in a filename block:

1. eight bytes – the filename
2. one byte – file type (00=BASIC, 01=data, 02=machine code)
3. one byte – ASCII flag (00=binary, FF=ASCII)
4. one byte – gap flag (00=no gaps, FF=gaps)
   (The tech manual shows 01 as the code for “no gaps”, but binaries saved by Extended Color BASIC actually have 00.)
5. two bytes – machine code starting address
6. two bytes – machine code loading address

I have now verified that bytes are stored least-significant bit first. (Thanks to Simon South for first pointing this out to me).

Each bit is recorded as a single cycle of a sine-wave. The frequency of the wave distinguishes a “0″ from a “1″ bit. A “1″ is a single cycle at 2400 Hz, while a “0″ is a single cycle at 1200 Hz. So the average bit rate is about 1500. But this “baud rate” depends on the data; a file containing all 00 bytes would take about twice as long as a file containing all bytes of FF’s. (It is not exactly twice as long, because the overhead in each block will contain bytes with both 0′s and 1′s.)

The CoCo recognizes bits by detecting zero crossings – those places where the sine wave crosses from positive to negative or visa-versa. This means that it is independent of the volume (or loudness) of the signal, except that smaller signals are easier to mess up with noise. It is also independent of inversions – the tape can play the signal back upside-down and the computer won’t even notice the difference.

      +---+--+---+
  C1+ |1  +--+ 16| VCC
   V+ |2       15| GND
  C1- |3       14| T1out
  C2+ |4  MAX  13| R1in
  C2- |5  232  12| R1out
   V- |6       11| T1in
T2out |7       10| T2in
 R2in |8        9| R2out
      +----------+

MAX242 5V RS232 transceiver with shutdown.

      +---+--+---+
  /EN |1  +--+ 18| /SHDN
  C1+ |2       17| VCC
   V+ |3       16| GND
  C1- |4       15| T1out
  C2+ |5  MAX  14| R1in
  C2- |6  242  13| R1out
   V- |7       12| T1in
T2out |8       11| T2in
 R2in |9       10| R2out
      +----------+

LTC485 Quad RS485 line driver.

     +---+--+---+            +---+---*---+---+
 1A1 |1  +--+ 16| VCC        | A | EN| Y |/Y |
 1Y1 |2       15| 2A2        +===+===*===+===+
/1Y1 |3       14| 2Y2        | 0 | 1 | 0 | 1 |
 1EN |4       13| /2Y2       | 1 | 1 | 1 | 0 |
/1Y2 |5 75174 12| 2EN        | X | 0 | Z | Z |
 1Y2 |6       11| /2Y1       +---+---*---+---+
 1A2 |7       10| 2Y1
 GND |8        9| 2A1
     +----------+

LTC485 RS485 line transceiver.

    +---+--+---+             Receiver:           Transmitter:
  Y |1  +--+  8| VCC         +-------+---*---+   +---+---*---+---+
/OE |2        7| B           |  A-B  |/OE| Y |   | D |DEN| A | B |
DEN |3  75176 6| A           +=======+===*===+   +===+===*===+===+
  D |4        5| GND         |>+200mV| 0 | 1 |   | 0 | 1 | 0 | 1 |
    +----------+             |<-200mV| 0 | 0 |   | 1 | 1 | 1 | 0 |
                             |   X   | 1 | Z |   | X | 0 | Z | Z |
                             +-------+---*---+   +---+---*---+---+

LTC488 Quad RS485 line receiver.
Note the unusual ORed output enables.

    +---+--+---+             +-------+---+---*---+
 B1 |1  +--+ 16| VCC         |  A-B  | OE|/OE| Y |
 A1 |2       15| B4          +=======+===+===*===+
 Y1 |3       14| A4          |>+200mV| 1 | X | 1 |
 OE |4       13| Y4          |>+200mV| X | 0 | 1 |
 Y2 |5 75173 12| /OE         |<-200mV| 1 | X | 0 |
 A2 |6       11| Y3          |<-200mV| X | 0 | 0 |
 B2 |7       10| A3          |   X   | 0 | 1 | Z |
GND |8        9| B3          +-------+---+---*---+
    +----------+

LTC489 Quad RS485 line receiver.

    +---+--+---+             +-------+---*---+
1B1 |1  +--+ 16| VCC         |  A-B  | OE| Y |
1A1 |2       15| 2B2         +=======+===*===+
1Y1 |3       14| 2A2         |>+200mV| 1 | 1 |
1OE |4       13| 2Y2         |<-200mV| 1 | 0 |
1Y2 |5 75175 12| 2OE         |   X   | 0 | Z |
1A2 |6       11| 2Y1         +-------+---*---+
1B2 |7       10| 2A1
GND |8        9| 2B1
    +----------+

MC1413 7-bit 50V 500mA TTL-input NPN darlington driver.
The drivers need no power supply; the VDD pin is the common cathode of the seven integrated protection diodes.

    +---+--+---+             +---*---+
 A0 |1  +--+ 16| /Y0         | A |/Y |
 A1 |2       15| /Y1         +===*===+
 A2 |3       14| /Y2         | 0 | Z |
 A3 |4  ULN  13| /Y3         | 1 | 0 |
 A4 |5  2003 12| /Y4         +---*---+
 A5 |6       11| /Y5
 A6 |7       10| /Y6
GND |8        9| VDD
    +----------+

1488 TTL to RS232 level shifter.
The outputs are at RS-232 levels, and sometimes are connected to ground through a small capacitor (up to 470 pF) to reduce slew-rate. Note that 1B is missing (and can be taken to be 1 at all times). Usually VDD=+12 and VEE=-12.

    +---+--+---+          +---+---*-----+
VEE |1  +--+ 14| VDD      | A | B |  Y  |
 1A |2       13| 4A       +===+===*=====+
 1Y |3       12| 4B       | 0 | 0 | VDD |
 2A |4  1488 11| 4Y       | 0 | 1 | VDD |
 2B |5       10| 3A       | 1 | 0 | VDD |
 2Y |6        9| 3B       | 1 | 1 | VEE |
GND |7        8| 3Y       +---+---*-----+
    +----------+

1489 RS232 to TTL level shifter.
A inputs are RS232-level inputs, C inputs are response control, a TTL signal which could be used to adjust threshhold and hysteresis but is generally unnecessary and unused. It is often tied through a 300 – 470 pF capacitor to ground.

    +---+--+---+
 1A |1  +--+ 14| VCC
 1C |2       13| 4A
 1Y |3       12| 4C
 2A |4  1489 11| 4Y
 2C |5       10| 3A
 2Y |6        9| 3C
GND |7        8| 3Y
    +----------+

ULN2003 7-bit 50V 500mA TTL-input NPN darlington driver.
The drivers need no power supply; the VDD pin is the common cathode of the seven integrated protection diodes.

    +---+--+---+             +---*---+
 A0 |1  +--+ 16| /Y0         | A |/Y |
 A1 |2       15| /Y1         +===*===+
 A2 |3       14| /Y2         | 0 | Z |
 A3 |4  ULN  13| /Y3         | 1 | 0 |
 A4 |5  2003 12| /Y4         +---*---+
 A5 |6       11| /Y5
 A6 |7       10| /Y6
GND |8        9| VDD
    +----------+

UDN2585 7-bit 50V 500mA TTL-input PNP (high-side) darlington driver.
The drivers need no power supply; the GND pin is the common anode of the seven integrated protection diodes.

    +---+--+---+             +---*---+
 A0 |1  +--+ 16| /Y0         | A |/Y |
 A1 |2       15| /Y1         +===*===+
 A2 |3       14| /Y2         | 0 | Z |
 A3 |4  UDN  13| /Y3         | 1 | 0 |
 A4 |5  2585 12| /Y4         +---*---+
 A5 |6       11| /Y5
 A6 |7       10| /Y6
VCC |8        9| GND
    +----------+

26LS31 4-bit 3-state RS422 line driver.

    +---+--+---+
 1A |1  +--+ 16| VCC
 1Y |2       15| 4A
/1Y |3       14| 4Y
 CE |4  26LS 13| /4Y
/2Y |5   31  12| /CE
 2Y |6       11| /3Y
 2A |7       10| 3Y
GND |8        9| 3A
    +----------+

26LS32 Quad RS422 line receiver.
Note the unusual ORed output enables.

    +---+--+---+             +-------+---+---*---+
 B1 |1  +--+ 16| VCC         |  A-B  | OE|/OE| Y |
 A1 |2       15| B4          +=======+===+===*===+
 Y1 |3       14| A4          |>+200mV| 1 | X | 1 |
 OE |4  26LS 13| Y4          |>+200mV| X | 0 | 1 |
 Y2 |5   32  12| /OE         |<-200mV| 1 | X | 0 |
 A2 |6       11| Y3          |<-200mV| X | 0 | 0 |
 B2 |7       10| A3          |   X   | 0 | 1 | Z |
GND |8        9| B3          +-------+---+---*---+
    +----------+

ULN2803 8-bit 50V 500mA TTL-input NPN darlington driver.
The drivers need no power supply; the VDD pin is the common cathode of the eight integrated protection diodes.

    +---+--+---+             +---*---+
 A0 |1  +--+ 18| /Y0         | A |/Y |
 A1 |2       17| /Y1         +===*===+
 A2 |3       16| /Y2         | 0 | Z |
 A3 |4  ULN  15| /Y3         | 1 | 0 |
 A4 |5  2803 14| /Y4         +---*---+
 A5 |6       13| /Y5
 A6 |7       12| /Y6
 A7 |8       11| /Y7
GND |9       10| VDD
    +----------+

UCN5800 4-bit 50V 500mA TTL-input NPN darlington driver with input latches and output enable.
The VDD pin is the common cathode of the four integrated protection diodes.

    +---+--+---+
RST |1  +--+ 14| /OE
 LE |2       13| VCC
 D1 |3       12| /Q1
 D2 |4  UCN  11| /Q2
 D3 |5  5800 10| /Q3
 D4 |6        9| /Q4
GND |7        8| VDD
    +----------+

UCN5801 8-bit 50V 500mA TTL-input NPN darlington driver with input latches and output enable.
The VDD pin is the common cathode of the eight integrated protection diodes.

    +---+--+---+
RST |1  +--+ 22| /OE
 LE |2       21| VCC
 D0 |3       20| /Q0
 D1 |4       19| /Q1
 D2 |5       18| /Q2
 D3 |6  UCN  17| /Q3
 D4 |7  5801 16| /Q4
 D5 |8       15| /Q5
 D6 |9       14| /Q6
 D7 |10      13| /Q7
GND |11      12| VDD
    +----------+

UCN5810 10-bit serial-in 60V 40mA TTL-input PNP (high-side) darlington driver with output latches and output enable.
The VDD pin is the output supply voltage.

    +---+--+---+
 Q7 |1  +--+ 18| Q8
 Q6 |2       17| Q9
 Q5 |3       16| SOUT
CLK |4       15| VDD
GND |5  UCN  14| SIN
VCC |6  5810 13| /OE
 LE |7       12| Q0
 Q4 |8       11| Q1
 Q3 |9       10| Q2
    +----------+

UCN5815 8-bit 60V 40mA TTL-input PNP (high-side) darlington driver with input latches and output enable.
The VDD pin is the output supply voltage.

    +---+--+---+
RST |1  +--+ 22| /OE
 LE |2       21| VCC
 D0 |3       20| Q0
 D1 |4       19| Q1
 D2 |5       18| Q2
 D3 |6  UCN  17| Q3
 D4 |7  5815 16| Q4
 D5 |8       15| Q5
 D6 |9       14| Q6
 D7 |10      13| Q7
GND |11      12| VDD
    +----------+

UCN5821, UCN5822 8-bit serial-in 50/80V 500mA TTL-input NPN darlington driver with output latches and output enable.
Maximum open collector voltage is 50V for UCN5821 and 80V for UCN5822.

     +---+--+---+
 CLK |1  +--+ 16| /Q0
 SIN |2       15| /Q1
 GND |3       14| /Q2
 VCC |4  UCN  13| /Q3
SOUT |5  5821 12| /Q4
  LE |6  5822 11| /Q5
 /OE |7       10| /Q6
 GND |8        9| /Q7
     +----------+

UCN5890, UCN5891, UCN5895 8-bit serial-in 50/80V 250/500mA TTL-input PNP (high-side) darlington driver with output latches and output enable.
Maximum open collector voltage is 50V for UCN5891 and UCN5895 and 80V for UCN5890. Output current is 250mA for UCN5895, 500mA for UCN5890 and UCN5891. The VDD pin is the output supply voltage.

    +---+--+---+
GND |1  +--+ 16| SOUT
CLK |2       15| VCC
SIN |3       14| /OE
 LE |4  UCN  13| VDD
 Q0 |5  589x 12| Q7
 Q1 |6       11| Q6
 Q2 |7       10| Q5
 Q3 |8        9| Q4
    +----------+

DS8863, DS8963 8-bit 10V/18V 500mA TTL-input NPN darlington driver.
Maximum open collector voltage is 10V for DS8863 and 18V for DS8963.

    +---+--+---+             +---*---+
/Y0 |1  +--+ 18| VCC         | A |/Y |
 A0 |2       17| A7          +===*===+
 A1 |3       16| /Y7         | 0 | Z |
/Y1 |4  DS   15| A6          | 1 | 0 |
/Y2 |5  8863 14| /Y6         +---*---+
 A2 |6  8963 13| A5
/Y3 |7       12| /Y5
 A3 |8       11| A4
GND |9       10| /Y4
    +----------+

75173 Quad RS485 line receiver.
Note the unusual ORed output enables.

    +---+--+---+             +-------+---+---*---+
 B1 |1  +--+ 16| VCC         |  A-B  | OE|/OE| Y |
 A1 |2       15| B4          +=======+===+===*===+
 Y1 |3       14| A4          |>+200mV| 1 | X | 1 |
 OE |4       13| Y4          |>+200mV| X | 0 | 1 |
 Y2 |5 75173 12| /OE         |<-200mV| 1 | X | 0 |
 A2 |6       11| Y3          |<-200mV| X | 0 | 0 |
 B2 |7       10| A3          |   X   | 0 | 1 | Z |
GND |8        9| B3          +-------+---+---*---+
    +----------+

75174 Quad RS485 line driver.

     +---+--+---+            +---+---*---+---+
 1A1 |1  +--+ 16| VCC        | A | EN| Y |/Y |
 1Y1 |2       15| 2A2        +===+===*===+===+
/1Y1 |3       14| 2Y2        | 0 | 1 | 0 | 1 |
 1EN |4       13| /2Y2       | 1 | 1 | 1 | 0 |
/1Y2 |5 75174 12| 2EN        | X | 0 | Z | Z |
 1Y2 |6       11| /2Y1       +---+---*---+---+
 1A2 |7       10| 2Y1
 GND |8        9| 2A1
     +----------+

75175 Quad RS485 line receiver.

    +---+--+---+             +-------+---*---+
1B1 |1  +--+ 16| VCC         |  A-B  | OE| Y |
1A1 |2       15| 2B2         +=======+===*===+
1Y1 |3       14| 2A2         |>+200mV| 1 | 1 |
1OE |4       13| 2Y2         |<-200mV| 1 | 0 |
1Y2 |5 75175 12| 2OE         |   X   | 0 | Z |
1A2 |6       11| 2Y1         +-------+---*---+
1B2 |7       10| 2A1
GND |8        9| 2B1
    +----------+

75176 RS485 line transceiver.

    +---+--+---+             Receiver:           Transmitter:
  Y |1  +--+  8| VCC         +-------+---*---+   +---+---*---+---+
/OE |2        7| B           |  A-B  |/OE| Y |   | D |DEN| A | B |
DEN |3  75176 6| A           +=======+===*===+   +===+===*===+===+
  D |4        5| GND         |>+200mV| 0 | 1 |   | 0 | 1 | 0 | 1 |
    +----------+             |<-200mV| 0 | 0 |   | 1 | 1 | 1 | 0 |
                             |   X   | 1 | Z |   | X | 0 | Z | Z |
                             +-------+---*---+   +---+---*---+---+

75188 TTL to RS232 level shifter.
The outputs are at RS-232 levels, and sometimes are connected to ground through a small capacitor (up to 470 pF) to reduce slew-rate. Note that 1B is missing (and can be taken to be 1 at all times). Usually VDD=+12 and VEE=-12.

    +---+--+---+          +---+---*-----+
VEE |1  +--+ 14| VDD      | A | B |  Y  |
 1A |2       13| 4A       +===+===*=====+
 1Y |3       12| 4B       | 0 | 0 | VDD |
 2A |4  1488 11| 4Y       | 0 | 1 | VDD |
 2B |5       10| 3A       | 1 | 0 | VDD |
 2Y |6        9| 3B       | 1 | 1 | VEE |
GND |7        8| 3Y       +---+---*-----+
    +----------+

75189 RS232 to TTL level shifter.
A inputs are RS232-level inputs, C inputs are response control, a TTL signal which could be used to adjust threshhold and hysteresis but is generally unnecessary and unused. It is often tied through a 300 – 470 pF capacitor to ground.

    +---+--+---+
 1A |1  +--+ 14| VCC
 1C |2       13| 4A
 1Y |3       12| 4C
 2A |4  1489 11| 4Y
 2C |5       10| 3A
 2Y |6        9| 3C
GND |7        8| 3Y
    +----------+

75452 Dual NAND line driver.

    +---+--+---+
 1A |1  +--+  8| VCC
 1B |2        7| 2B
 1Y |3 75452  6| 2A
GND |4        5| 2Y
    +----------+

default is 11. 0=fast, 255=slow POKE 63372,x Stop the cursor blinking in 40/80 screens POKE 63381,0 Start the cursor blinking again POKE 63381,1 x is from 0 to 255, it sets the shape of the cursor in 40/80 screens POKE &HF7A3,x Storage of the default CMP palette values &HE654
to &HE663 Storage of the default RGB palette values &HE664
to &HE673 Storage of current palette values &HE674
to &HE687 Set the width 32 foreground color POKE &HFFBC,x Set the width 32 background color POKE &HFFBD,x 1.8mhz speed POKE for the CoCo 3 (no effect with emulator) POKE 65497,0 Normal speed POKE (.89mhz) for CoCo 3 POKE 65496,0 Disable the automatic clearing of the HSCREEN. POKE &HE6C6,33 location of data for the HPRINT character set (8 bytes per character, 96 characters). &HF09D
to &HF39C 8k block number for HGET/HPUT the default is &H74 &HE0D4,&HE3A3,
&HE50B Change the HPAINT command to paint a variety of patterns. x is from 0 to 255. POKE &HE79B,196:POKE
&HE79C,x Defaults for the HPAINT command POKE &HE79B,212:POKE
&HE79C,181 x is the column spacing you want (20,40,80,etc.) POKE &HFE04,x x is from 0 to 255, controls the “blink” attribute blink rate POKE &HFF94,x Default “blink” attribute blink rate POKE &HFF94,126 x is from 0 to 255. Default is 32. When you CLS on a 40/80 screen, this is the ASCII of the character used to clear the screen. POKE &Hf697,x End address of an ML
program PEEK(126)*256+PEEK(127) EXEC address of the
program PEEK(157)*256+PEEK(158) Start address of an
ML program PEEK(487)*256+PEEK(488) x is from 0 to 255.
Default is 32. When you CLS on a 40/80

screen, this is the ASCII of the character used to clear the
screen. POKE &Hf697,x See what the WIDTH is
(0=32, 1=40, 2=80) PEEK(&H00E7) ]]> http://www.coco3.com/community/2009/09/coco-3-peeks-and-pokes/feed 0 http://www.coco3.com/community/2009/09/coco-peeks-and-pokes http://www.coco3.com/community/2009/09/coco-peeks-and-pokes#comments Sun, 06 Sep 2009 21:06:32 +0000 Roger http://www.coco3.com/community/?p=121 POKE 55180,18:POKE 55181,18:POKE 55182,18 turns of disk drive moter faster

POKE 38543,33:POKE 38563,33 fixes PCLEAR 0 error. Now you can
PCLEAR 0 and get 28941 bytes of free
MEM!!

POKE &HA1C1,&H39:FOR F=&HA1CA to &HA1C1
STEP -1:READA:POKE F,A:NEXT F:DATA 121,39,
72,67,0,255,182,2,255,127 put as the first line of your program
it will speed up your computer by about
15%!! It patches the keyboard scan routine

FOR I=&H8000 to &H8013:READ B$:POKE I,VAL
(“&H”+B$):NEXT I:POKE &H85CB,&HBD:POKE
&H85CC,&H80:POKE &H85CD,0:DATA 86,21,BD,
A2,82,A6,84,BD,A2,82,86,21,BD,A2,82,BD,85,
D1,5A,39 patches the D command during EDIT to
show the character being deleted!

FOR I=&H8014 TO &H8022:READ B$:POKE I,VAL
(“&H”+B$):NEXT I:POKE &HAB85,&H80:POKE
&HAB86,&H14:DATA 10,27,2D,CC,BD,AF,67,BD,
AD,01,9E,47,7E,AD,E6 patches the RESTORE command so you can
restore to any line number. For example,
RESTORE 40 restores any DATA from line 40
on, but no DATA prior to line 40. A plain
old RESTORE still restores every DATA
statement

POKE &HFF21,&H3C immediately turns on the cassette relay (MOTOR ON)
POKE &HFF21,&H34 immediately turns off the relay (MOTOR OFF, but no delay)

POKE 150,x set printer baud rate. 87=600, 41=1200, 18=2400, 7=4800, 1=9600
if running in high speed (1.8mhz) baud is doubled also!

EXEC 44539 pauses and waits for any key press (except BREAK/SHIFT/ESC)

POKE 282,255 set keyboard to uppercase
POKE 282,0 set keyboard to lowercase

POKE 186,msb
POKE 187,lsb set the start address for the PMODE 3/4 screen

POKE 113,0:EXEC &H8C1B
POKE 113,0:DLOAD |– three different ways to cold-start a CoCo 3
POKE 113,0 /

POKE 111,254:DIR forces a disk directory to be printed on the printer

PEEK(41)*256+PEEK(42) the line number to continue after a STOP command

PEEK(49)*256+PEEK(50) the line number of the next DATA statement to be read

PEEK(135) the ASCII code of the most recently pressed key
can be used with EXEC 44539 instead of INKEY$

POKE 175,0 turn tracer on (TRON)
POKE 175,1 turn tracer off (TROFF)

decimal 338 to 345 the keyboard rollover tables – values change based on what keys
are being held down

if PEEK(341)=191, then the ALT key is being pressed
if PEEK(342)=191, then the CTRL key is being pressed
if PEEK(343)=191, then F1 is being pressed (F11 on the emulator)
if peek(344)=191, then F2 is being pressed (F12 on the emulator)

PEEKs 474 to 481 contain ASCII values of most recently used FILENAME (8 characters)
PEEK(482) contains file type (0=BASIC, 1=DATA, 2=BINARY)

POKE &HD7C0,x:POKE &HD816,y disk drive step rate (not for ADOS)
x=3 y=23 for 30ms (default)
x=2 y=22 for 20ms
x=1 y=21 for 12ms
x=0 y=20 for 6ms (most drives can do this, it’s faster and quieter)

44014 to 44018 ASCII values used for the prompt “OK”. You can change the OK prompt
POKE 44014,0 no prompt at all, just a cursor

EXEC 43345 makes a click sound

POKE 41598,19:POKE 41591,95 the BREAK key now pauses (same as SHIFT-@) and
SHIFT-BREAK will act as the BREAK key

POKE &HE414,0:POKE &HE42A,0 disables the CoCo 3 BREAK key

A=RND(-TIMER) use this to get “more-random” numbers from the RND statement
similar to RANDOMIZE on other computers

After POKE &HF6BC,255, you can CLS x where x is from 0 to 255 to clear the 40/80
screens with a variety of attributes

&H01DA to &H02D8 the old cassette buffer, which can be used for short ML programs
it’s 255 bytes long

POKE 41893,0 disables the CLEAR key
POKE 41893,129 enables the CLEAR key

POKE 41909,0 prevents SHIFT-BACK-ARROW from erasing the entire line
POKE 41909,21 enables the SHIFT-BACK-ARROW

POKE &HADEB,&H39 prevents SHIFT-@ from pausing programs, speeds up the program!

POKE &HD762,x where x is 1 to 255. This controls how many times the disk drive
tries to read a “problem” with the disk. The default is 5, but if
you set it to 1 or 2, the computer will try fewer times. If you have
ever accidentally typed, for example, DIR 1, but had no disk in the
drive, the computer tries 5 times to read it. By changing this value,
it will return to the OK prompt sooner, or try longer, if you want.

#FILE: $RCSfile: cocotokn.txt $
#DESC: List of the Coco Extended Color Basic tokens
#REV: $Revision: 1.1 $
#DATE: 16/03/94
#AUTHOR: Graham E.Kinns
#DISCLAIMER: All information provided as is etc.
#ARCHIVE: This file is part of the DRGNINFO collection of Dragon info files
#CONTACT: Comments, bugs, revisions, suggestions to Dragon@grempc.demon.co.uk
#HISTORY: 1.0 16/03/94 - Initial version
#RCSID: $Id: cocotokn.txt 1.1 1994/05/10 16:30:57 G.E.Kinns Exp $
#XREF: basicfmt.txt - tokenised Basic format
#      bastoken.txt - Dragon Basic tokens
#Operator tokens
#Token  Keyword

0x80	FOR
0x81	GO
0x82	REM
0x83	'
0x84	ELSE
0x85	IF
0x86	DATA
0x87	PRINT
0x88	ON
0x89	INPUT
0x8a	END
0x8b	NEXT
0x8c	DIM
0x8d	READ
0x8e	RUN
0x8f	RESTORE
0x90	RETURN
0x91	STOP
0x92	POKE
0x93	CONT
0x94	LIST
0x95	CLEAR
0x96	NEW
0x97	CLOAD
0x98	CSAVE
0x99	OPEN
0x9a	CLOSE
0x9b	LLIST
0x9c	SET
0x9d	RESET
0x9e	CLS
0x9f	MOTOR
0xa0	SOUND
0xa1	AUDIO
0xa2	EXEC
0xa3	SKIPF
0xa4	TAB(
0xa5	TO
0xa6	SUB
0xa7	THEN
0xa8	NOT
0xa9	STEP
0xaa	OFF
0xab	+
0xac	-
0xad	*
0xae	/
0xaf	^
0xb0	AND
0xb1	OR
0xb2	>
0xb3	=
0xb4	<
0xb5	DEL
0xb6	EDIT
0xb7	TRON
0xb8	TROFF
0xb9	DEF
0xba	LET
0xbb	LINE
0xbc	PCLS
0xbd	PSET
0xbe	PRESET
0xbf	SCREEN
0xc0	PCLEAR
0xc1	COLOR
0xc2	CIRCLE
0xc3	PAINT
0xc4	GET
0xc5	PUT
0xc6	DRAW
0xc7	PCOPY
0xc8	PMODE
0xc9	PLAY
0xca	DLOAD
0xcb	RENUM
0xcc	FN
0xcd	USING
# RSDOS adds these .. (from Dragon User 12/84)
0xce	DIR
0xcf	DRIVE
0xd0	FIELD
0xd1	FILES
0xd2	KILL
0xd3	LOAD
0xd4	LSET
0xd5	MERGE
0xd6	RENAME
0xd7	RSET
0xd8	SAVE
0xd9	WRITE
0xda	VERIFY
0xdb	UNLOAD
0xdc	DSKINI
0xdd	BACKUP
0xde	COPY
0xdf	DSKI$
0xe0	DSKO$
#Function tokens - all proceeded by 0xff to differentiate from operators
#Token  Keyword
0x80	SGN
0x81	INT
0x82	ABS
0x83	USR
0x84	RND
0x85	SIN
0x86	PEEK
0x87	LEN
0x88	STR$
0x89	VAL
0x8a	ASC
0x8b	CHR$
0x8c	EOF
0x8d	JOYSTK
0x8e	LEFT$
0x8f	RIGHT$
0x90	MID$
0x91	POINT
0x92	INKEY$
0x93	MEM
0x94	ATN
0x95	COS
0x96	TAN
0x97	EXP
0x98	FIX
0x99	LOG
0x9a	POS
0x9b	SQR
0x9c	HEX$
0x9d	VARPTR
0x9e	INSTR
0x9f	TIMER
0xa0	PPOINT
0xa1	STRING$
# RSDOS adds these .. (from Dragon User 12/84)
0xa2	CVN
0xa3	FREE
0xa4	LOC
0xa5	LOF
0xa6	MKN$

-sc

-sc

As you start typing code, a list popes up with relevant syntax, variables, functions, you name it as well as templates such as with for loops where I all I have to do is type for then hit the tab button twice and it creates a for loop with all its parameters and in the case of C# it also gives you the curly braces.

I think this would help coco developers.

Is there an example somewhere I could study to learn from? Google hasn’t given me much help, at least not that I could make sense of. I tried to implement a suggestion that I found to multiply and then add a value using the D register over and over, but I wasn’t sure how to implement multiplication on a 16 bit value. I tried loading D and then multiply on A and B, then the addd, and got a sequence that repeats every 5 bytes so I did something wrong there.

Sorry if this is a silly question, I could use any advice.

[url]http://www.6809.org.uk/dragon/xroar-flash.shtml[/url]

Load both files and type in RUN. Keyboard=left and right buttons and joystick is whatever simulates a joystick on what your running it on.

What do you gusy think? Does it have potential?

Do you think you could take a look at Window Master? Under MESS the mouse doesn’t seem to work properly. It just seems to like the corner of the screen under any of the different adapters that are available in MESS’ menu.

If you need any more information (to help debug,) or for a copy of the DMK image, you can contact either myself or Briza.

Thanks!
-M.

What’s the next great project? I’m not an engineer, and I don’t have the money to start developing stuff myself. I’m only making a suggestion for those who are in that position. But I know far less powerfull computers are using ethernet now, and I think this would be a *very* useful and popular product for the CoCo.

Why not? Please think about it.

I’m a programmer by hobby and by profession, and I’d like to do some hobby programs for the CoCo3 I have. However, I can’t figure out how to save to disk.

I ran a graphics program (can’t think of the name at the moment) and successfully saved a picture to my second floppy drive (D1, I have two stacked floppy drives that connect via the cartridge input, although I have them in slot 4 of my multi-pak interface). So, I know the hardware is working. However, when I boot into Extended Basic (I noticed its “extended” when the floppy drives are present, and not Extended when they are not) I can’ figure out how to save. When I run the EDTASM+ ROMPak, I can’t save there either. Supposedly the WD command is supposed to work, but I can’t figure it out.

I read somewhere that you have to have the disk version of EDTASM (not the ROMPak like I have) to save to disk. (Mine can apparently save to cartridge (?) or cassette). Is this true?

As far as the Extended basic goes, I can’t even figure out how to get a directory listing. I usually end up going into OS9 L2 for that. (If anybody want to explain that to me, or link me to websites I haven’t read yet [and I've read a lot already] please feel free).

I love to learn new computer “stuff” and I love to program. Any information, guides, reading, manuals, or anything that you can toss my way would be wonderful.

If you need any more information, just ask.

Thanks in advance, and I look forward to any helpful replies!

I then went to GCC (another freebie) but after reading that it’s basically supported by one guy and I had difficulty implementing it, I gave up.

BTW, how come everything for Linux has to be so freaking convoluted. Just to find a simple patch, I have to wonder through thousands of links that say “go here” just to be taken to another thousand links… jeeeze!!

Anyway, I finally settled on Dunfield’s 6809 C compiler. It cost me $100.00, but so far it works quite well. It doesn’t support typedefs or enums though. But I’ve been working around that.

I was just wondering what C Compilers do others use and what are your opinions of them???

If I want to make an audio file, or just generate the audio, where can I find bits to waves documentation?

I am currently writing a very simple game for the CoCo3 — (Sorry – with a twist) and I would like some advice.

It seems programming sprites these days is a lost art, and I am having some trouble pinning down some information. I want to use 16 sprites to control the moving of all the pawns in the game…. and this is where I start to have some trouble.

I understand the basic concepts — save the background, draw the sprite, restore the background and move. I also understand why using and/or will quickly draw a sprite and why vsync is needed.

Following the advice I have read here in the forums, I figured each of the 16 pawns would be defined as this:

Start Address of Pawn Graphic (16-Bit)
X/Y Position of the Pawn (16-Bit)
Pawn Status (8 Bit)

So far so good… and now I get stuck… the definition of the sprite itself.
I can easily store the pawn definition in 8 bytes like this:
00011000 = $18
00111100 = $3C
00011000 = $18
00011000 … etc…
00011000
00111100
01111110
11111111

I already wrote an ML routine that decodes each bit of the 8 bytes and can draw the pawn on the screen… but how do I associate color with the pawn? Would it just be best to define the 64 bytes and include all the information…. or am I missing something here in the sprite definition?

I apologize if this is a basic question — I have never really worked with sprites before — and the information train is quickly drying up on the net.

Thank you!!

CoCo
GIME
Other

So far I am certain of only this:
The CPU and associated ROM, the PIA’s, RAM and probably the 74LS138 in the upper left corner of the -008 picture are CoCo.
The FDC is in “other”.

I hope you will all take an interest and contribute. I would like to discuss a coordinate system for referencing components’ locations. I think letters across the short edge and numbers along the long side. This will save time searching for the component/trace/wire under discussion by avoiding the tedious task of scanning the whole board for “U92″.

Thanks,
HH

ALR

I have worked through understanding all the new ( I say new because my days were spent pushing a CoCo2 back in the day) registers and most of their functions (Thank you RG!)

One thing I would like to know is if anyone knows of a utility I can use to create sprite images. My guess is this would need to be a CoCo3 util so I can get the colors right.

I need to take an image and break it down into binary for inclusion in my programs. I already read some good advice from 6809er — and now I would like to put it to work!

Thank you!!

There is absolutely no reason why I can’t use notepad on my PC, except I need a certain amount of green radiation every week…

I am aware of FFA0-FFA7 … and FFA8-FFAF

Getting right to the point, let’s assume I am writing an ML program… and I start in page 1 with an ORG of $2000. Let’s say I need to access additional pages of memory, but I want to control that feature.

So with my small program operating out of page 1, I want to control page 2 and point it to different segments of memory.

If I try to point FFA2 to say, 30 — I freeze up — and I do think the machine spews profanity at me!

Ok, so I load FFAA with 30 — all is well so far. Then I set FF91 — and I can smell the smoke coming from my machine.

Seems to me I am missing something very simple here — and I am hoping someone will hit me with a tack hammer and set me straight on how to manually control blocking of virtual memory segments.

Does this seem like a good idea? Has anybody ever tried it? Is the 6809 fast enough to do it 16 Bombs Per Second like the Atari 2600 Version?

I am asking, Because although I am on a project I have to start on again, I am thinking for my next complete game

Alr

My original plan was to remake the .DSK imaging utility into a more user-friendly application, with the ability to export a .XML data file as a catalog. With this approach, I could do whatever I wanted with the data – such as a simple database or HTML utility. After some additional thought, I came up with the idea of creating a basic database within the application itself. My end goal is to be able to create an entire catalog of all my disk images and incorporate meta-data for their content. There will also be a search utility in the application which will allow you to look for files or content on the disk images themselves. I’ve also included a hex editor to modify the contents of the disk images – may be useful to someone.

Let me know If anyone has ideas on anything I should be including for functionality.

[b:914eae0c22]Latest build located[/b:914eae0c22] [url=http://www.fiscap.com/trs-80_fdce.zip]here[/url].

Here are a couple of screenshots of my progress so far:

[url=http://www.fiscap.com/images/trs80_catalog.jpg][img:914eae0c22]http://www.fiscap.com/images/trs80_catalog_tn.jpg[/img:914eae0c22]
[/url]
[url=http://www.fiscap.com/images/trs80_explorer.jpg][img:914eae0c22]http://www.fiscap.com/images/trs80_explorer_tn.jpg[/img:914eae0c22]
[/url]

http://aaronrls01.webs.com/Cocogames/GameKBD.txt

Anyone see any mistakes or errors? I don’t wan assemble the game and find out something was wrong and start ALL over again…

This is my first post here but not my first time with the CoCo. I’ve owned a CoCo from day 1 ( old gray 4K version 1.0 ). I was bored lately and wrote a small utility to access .DSK files. I am offering this utility free here. All I ask is that you try it and let me know how it works for you. I am also interested in opinions on features to add.

You can download the utility here…
>>>> DOWNLOAD THE LATEST VERSION BELOW < <<<

If you find a problem, please post it here so I can address it. I’m just doing this for fun and with the hope that everyone will find the utility useful.

For those who are really interested, just email me or post here and I can send you the source code for the utility.

Here’s a screen shot (reduced in size)…
[img:d084a05686]http://home.comcast.net/~pilot352/CoCoDsk.jpg[/img:d084a05686]

Again, this is just for fun and your comments are welcome.

Thanks for your time.

Also, I will be making revisions from time to time and will post them here as I release them.

Enjoy!!

Also, A screenie would be fine, too.

result = result * 256 + ( (unsigned long)*bytes++ & 0x00FF);

Trying to find the correct syntax, and or if it can do it.

Thanks,

Tim

Actually there are ten HSCREEN modes available as listed in the service manual. Resulting from another thread on Programming, I have found a convenient method for accessing the other mode while retaining all of the drawing commands in Super Extended Basic.
One strange finding comparing the PMODE4 screen with the HSCREEN 256×192 x2 which have identical size is that artifact coloration does not behave the same way. If you have a composite monitor, you should try the two programs below and carefully compare the results.

There is a table in RAM that gives the horizontal bytes per line for each of the HSCREEN modes. If you change the values in this table and then POKE a value into $FF99, you can access the extra modes.

HSCREEN 256x192x4 colors with artifacts
[code:1:e3980c2174]
10 ON BRK goto 110
20 POKE&HFFB0,0:POKE&HFFB2,&H3F
30 POKE&HE6CB,64
40 HSCREEN1
50 POKE&HFF99,17
60 HCLS0:HCOLOR2
70 HLINE(0,0)-(255,191),PSET
100 GOTO100
110 RGB

analogous PMODE screen
10 WIDTH32
20 PMODE3:PCLS1:SCREEN1,1
30 COLOR2,0
40 LINE(0,0)-(255,191),PSET
50 PMODE4,1:SCREEN1,1
60 GOTO60
[/code:1:e3980c2174]

Both of the above programs draw a diagonal line on a 256x192 screen. Both will show artifact colors on a composite monitor. However, the PMODE program line will have a single color either red or blue while the HSCREEN program will have three colors white, red, and blue. Both lines look identical on an RGB monitor.

Any of the other HSCREEN modes can be used if you enter the correct width in the table at $E6CB. You must match the color resolution of the new mode with the mode value being replaced.
So if you want 256x192x16 you must replace the line width for mode2 which also has 16 colors. Above 256x192x4 was used so the mode1 line width was replaced as it also has 4 color resolution.

===========================
correction to line 30 first program. POKE value should be 64

http://en.wikipedia.org/wiki/Talk:TRS-80_Color_Computer

I added it as discussion as I no longer have a color computer III. I figure you guys can re-do this, and post up your experiences, best color sets and other technical info.

Have fun!!

I haven’t done basic since I started assembly some time ago XD

I am now paying the price XD