tag:blogger.com,1999:blog-24451926562455278122024-03-13T13:02:55.718-07:00Stupid VDG TricksJohn W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.comBlogger33125tag:blogger.com,1999:blog-2445192656245527812.post-27216021026661987582023-01-14T10:18:00.000-08:002023-01-14T10:18:56.588-08:00Software Sprite<p>As often discussed, the <a href="https://en.wikipedia.org/wiki/Motorola_6847">Motorola 6847 VDG</a> offers little in terms of assistance for game programmers or other software authors. While many contemporary video chips offered assistance in scrolling backgrounds or in moving objects in the foreground of a display, the 6847 hardware merely provides access to a static <a href="https://en.wikipedia.org/wiki/Framebuffer">framebuffer</a>. As we have seen prviously, anything beyond a still image requires work from the CPU. Fortunately for CoCo people, the <a href="https://en.wikipedia.org/wiki/Motorola_6809">Motorola 6809 CPU</a> is reasonably capable, and when used properly it can provide at least some of these video effects.</p><p></p><div class="separator" style="clear: both; text-align: center;"><iframe allowfullscreen="" class="BLOG_video_class" height="266" src="https://www.youtube.com/embed/M-jrTuXICVU" width="320" youtube-src-id="M-jrTuXICVU"></iframe></div> <p></p><p><span style="font-size: large;"><b><span style="font-family: arial;">Get Things Moving</span></b></span></p><p><span style="font-size: large;"><span style="font-family: inherit;"><span style="font-size: small;">Of course the only way to start is to draw something in the framebuffer memory by using the CPU's usual load and store instructions to copy data out of program storage and into the framebuffer. To create the illusion of motion this must be done rapidly and repeatedly. If care is not taken between draws to remove the previous image then "movement" will create a trail across the screen, corrupting the background image. Various methods exist for doing that cleanup (e.g. saving and restoring the background as part of the sprite draw operation), but this takes both program development time and execution time. The latter in particular is at a premium when so much data is already being moved for the background.</span></span><b><span style="font-family: arial;"><br /></span></b></span></p><p><span style="font-size: large;"><b><span style="font-family: arial;">Mask Mandate</span></b></span> </p><p>In
the 6847's RG3 (4 color, 2 bit per pixel) graphics mode, each byte of
buffer memory represents 4 <a href="https://en.wikipedia.org/wiki/Pixel">pixels</a>. Since memory writes happen one byte
at a time, any image that uses less than 4 pixels in each byte it
occupies will interfere with those extra pixels unless care is taken. This is typically observable as the movable object appearing a bit like a postage stamp laid on top of the display. Unless the object being displayed is rectangular with a pixel width that is a multiple of 4 pixels, then part of the draw operation must include masking. This involves reading the background, using a bitwise mask of the object to combine the object's pixels with the background pixels then writing the resulting data. This operation performs the trimming necessary to preserve the background. There is some execution time lost for the masking, and storing the mask data doubles the amount of memory necessary for storing the graphics objects. But there really is no way around this part.<br /></p><p><span style="font-size: large;"><b><span style="font-family: arial;">No Background Check</span></b></span></p><p>With the scrolling background demonstration as a base, we can now show a foreground item on top. Since both the foreground item and the background image move in relation to each other, this is not a single draw (or mask and draw) operation. With a normal static framebuffer, displaying a moving foreground itme would require some action to restore any background bits eclipsed by the foreground when the foreground moves. This might require regenerating the background algorithmically or saving the background before drawing the foreground and restoring the background after the foreground is moved. If we draw the foreground item in our source or "render" buffer, then all of the above would be true. But by drawing the foreground item directly in the current "display" buffer, we know that the background will be copied from the render buffer to the next display buffer at the next buffer switch. Since the background is already being redrawn for every frame, we don't need to maintain the background at all, saving all that time that would have been used for maintaining the background image!</p><p>So while redrawing the entire background initially seems expensive, that operation turns out to be cheaper than tracking damage to the background image and redrawing the background over and over again. It took me a while to wrap my head around this feature, but hopefully the explanation above makes things clear for you? I hope so.</p><p>Hopefully I can keep finding time to turn this discussion into an actual CoCo game. If you want to see where this all goes, then be sure to stay tuned!<br /><br /></p>John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com1tag:blogger.com,1999:blog-2445192656245527812.post-75180696513763951932023-01-10T11:10:00.001-08:002023-01-10T11:46:09.515-08:00Scrolling Engine<p>Well, it's been a while! Despite the boredom and isolation that came along with the COVID years, I didn't do much that was very impressive in terms of retro programming during that time. In a cruel twist of fate, the boredom (and an ongoing spat with another CoCo media figure) seems to have robbed me of inspiration during that time. Despite that, I did manage to produce a little technology demo to demonstrate scrolling a full graphical background on a <a href="https://en.wikipedia.org/wiki/TRS-80_Color_Computer">CoCo</a>. Some have asked for more information on how this was done. If that interests you, then please continue reading!</p><p></p><div class="separator" style="clear: both; text-align: center;"><iframe allowfullscreen="" class="BLOG_video_class" height="266" src="https://www.youtube.com/embed/WKShAOlQQps" width="320" youtube-src-id="WKShAOlQQps"></iframe></div><br /><b><span style="font-size: medium;"><span style="font-family: courier;">So Much Work</span></span></b><br /><br />Scrolling a background image with the <a href="https://en.wikipedia.org/wiki/Motorola_6847">6847 VDG</a> is not by itself a huge technical problem. All that is required is to move a lot of data from where it starts to a new location. For a CG3 (128x96) screen that means 3 KB or 3072 bytes of data moved for each frame of video. Many video chips roughly contemporary with the 6847 provided hardware support that allow (usually at the expense of some memory usage) for the illusion of movement by changing the source of the video data between frames. The <a href="https://colorcomputerarchive.com/repo/Documents/Datasheets/MC6883%20Synchronous%20Address%20Multiplexer%20Advance%20Information%20(Motorola).pdf">SAM</a>/VDG combination used in the CoCo offers a rudimentary version of this, but the frame-to-frame jumps would be too coarse and the memory demands too great to be useful by itself for smooth animation.<br /><p></p><p><b><span style="font-size: medium;"><span style="font-family: arial;">So Little Time</span></span></b></p><p>With no useful hardware support available, brute force must be used to copy bytes around in the video buffer. Computers are fast, but not infinitely fast. How much time do we have? And how long does it the <a href="https://en.wikipedia.org/wiki/Motorola_6809">6809</a> take to copy 3072 bytes? The VDG generates just under 60 video frames per second. With the normal 0.89 MHz clock speed of the CoCo, that leaves us less than 15000 clocks to move the data for each frame. Unless the CPU can move one byte in five clock cycles (which it cannot), then there is just not enough time. Even at just 30 frames per second, we still wouldn't be very close.<br /></p><p><b><span style="font-size: medium;"><span style="font-family: arial;">Switch Things Up</span></span></b></p><p>The 6847 generates video output at just under 60 frames per second, and the SAM/VDG combination used in the CoCo does offer a "screen flip" capability. Combining those two details allows us to "<a href="double buffer">double buffer</a>", or to draw in one buffer while the other is used as the display source and then to switch between the buffers. Using two buffers effectively halves our video frame rate but doubles the amount of time available for video data movement and gets us back to a manageable 30 frame updates per second.<br /></p><p><b><span style="font-size: medium;"><span style="font-family: arial;">Blast Away</span></span></b></p><p>One unique feature of the 6809 CPU architecture is the User stack. This provides an efficient means for moving data, particularly when combined with the System stack and used for what is colloquially known as "<a href="https://blog.moertel.com/posts/2013-12-14-great-old-timey-game-programming-hack.html">stack blasting</a>". This feature allows for moving up to 8 bytes at a time in as little as 26 cycles for just two instructions. This would potentially allow us to move a frame's worth of data in roughtly 10000 cycles (depending on the actual code implementation). My implementation depends on some looping and is not quite that efficient. But it does suffice to keep the video update well within the 30 frame per second limit while leaving a generous amount of time available for doing something else (e.g. handling I/O or implementing game logic).</p><p><b><span style="font-size: medium;"><span style="font-family: arial;">Single Source</span></span></b></p><p>The two buffers mentioned above are merely tools for keeping the display looking correct and up-to-date. But both buffers are completely ephemeral. A third buffer is kept for rendering the actual video frame. This buffer is the source for the stack blast copies described above. since both of those buffers will be overdrawn almost immediately, any "permanent" change to the display needs to be done in this "render" buffer. Consequently this is the perfect place to draw any static background items (e.g. anything to be scrolled).</p><p>I think that mostly covers it. I originally implemented this back in the Summer of 2020, so hopefully I am not overlooking any big details. But I believe the main points are covered. This technique gets the job done, and it has a few advantages that I hope to exploit in the near future...stay tuned! <br /></p>John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com0tag:blogger.com,1999:blog-2445192656245527812.post-40316708699683345322020-01-30T12:43:00.000-08:002020-01-30T12:43:08.575-08:00Space Assault Port to 6800Now, on to the bigger project I've been hinting at... :-)<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/u3CxKqi_XiU/0.jpg" src="https://www.youtube.com/embed/u3CxKqi_XiU?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
So...<a href="http://www.lcurtisboyle.com/nitros9/spaceassault.html">Space Assault</a> is a clone of the well known arcade hit <a href="https://en.wikipedia.org/wiki/Space_Invaders">Space Invaders</a>, produced for the <a href="https://en.wikipedia.org/wiki/TRS-80_Color_Computer">Tandy Color Computer</a> by <a href="https://www.mobygames.com/company/image-producers-inc">The Image Producers</a>, (written by Lou Haehn?) and released in 1981. Some time ago, Darren Atkinson took it upon himself to disassemble the Space Assault ROM image for the CoCo and to do a binary translation of the <a href="https://en.wikipedia.org/wiki/Motorola_6809">6809</a> code into a version for the <a href="https://en.wikipedia.org/wiki/Motorola_6800_family">6803</a>-based <a href="https://en.wikipedia.org/wiki/TRS-80_MC-10">Tandy MC-10</a>. The <a href="http://www.colorcomputerarchive.com/coco/MC-10/Cassettes/Games/Space%20Assault%20(Darren%20Atkinson)%20(ML).c10">MC-10 version</a> plays very much like the CoCo version, with modifications from Darren to accommodate use of the MC-10 keyboard in place of the CoCo joystick.<br /><br />It occurred to me that this bit of MC-10 magic might be a good candidate for porting to my <a href="http://vdgtricks.blogspot.com/2014/01/building-micro-chroma-68-kit.html">Micro Chroma 68</a> (uchroma68), so I sent Darren an email requesting access to his MC-10 Space Assault source. Darren was nice enough to oblige, so I immediately checked his source into a <a href="https://en.wikipedia.org/wiki/Git">git</a> repository and set about to making the initial superficial changes necessary to reproduce his MC-10 Space Assault binary using my chosen assembler, the old <a href="http://aminet.net/package/dev/cross/MotFreeware">Motorola Freeware BBS assembler</a>.<br />
<br />
<b><span style="font-family: "Courier New", Courier, monospace;"><span style="font-size: large;">6803 > 6808 </span></span></b><br />
<br />
Working MC-10 code seems like a good place to start for a uchroma68 port, but some more preparation work is still required. The problem is that not all code that runs on the 6803 CPU in the MC-10 will also run on the 6808 CPU in the uchroma68. The 6808 (and the related 6802) execute the same instruction set as the earlier 6800, without any additions. But the 6803 (and the related 6801) use a somewhat improved architecture that supports a number of instructions that are not supported by their 6800/6802/6808 cousins. Not only are these extra instructions quite useful, they also make the 6803 a bit more like the 6809 architecturally. It is no surprise to learn that Darren used a number of these new instructions when porting Space Assault from the 6809 to the MC-10's 6803. Porting the MC-10 version of Space Assault to run on the uchroma68's 6808 will involve replacing these 6801/6803 instructions with 6800/6802/6808-compatible sequences.<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New", Courier, monospace;">Macro-like Translations</span></span></b><br />
<br />
<br />
Several of the new 6801/6803 instructions involve an architectural change that allows the 8-bit A and B accumulators to be grouped together as the 16-bit D accumulator. Instructions like "LDD" and "STD" are easily replaced with "LDAA/LDAB" and "STAA/STAB" combinations, just as "ADDD" is easily replaced with an "ADDB/ADCA" combination. Using a macro processor (either built-in to an assembler or something external like <a href="https://en.wikipedia.org/wiki/M4_(computer_language)">m4</a>) should make these substitutions trivial, requiring no changes to the source code at all. But as I am using the quite primitive assembler from Motorola, I simply made these changes directly in the source code -- the triviality made this more worthwhile than introducing an m4 pass in the Makefile.<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New", Courier, monospace;">Emulation Functions</span></span></b><br />
<br />
Some of the other new 6801/6803 instructions are not so easily replaced. Equivalent instruction sequences are lengthy, and require allocation of memory for temporary storage of registers used in those sequences. Instructions such as "PSHX", "PULX", and "ABX" are in this category, and they are so useful that again it is no surprise that Darren makes hearty use of them in his MC-10 port of Space Assault. In this effort, I found that replacing these instructions with equivalent subroutine calls provided good results while only requiring six bytes for temporary storage of the D, X, and S registers and a few bytes for a temporary stack. (The S register storage and the temporary stack were required to avoid data corruption in a couple of places where an emulated "ABX" was required within a routine that was using S as a pointer for data movement.)<br />
<br />
<blockquote class="tr_bq">
EMUSAVS rmb 2 ; temp storage of S for 6801/6803 emu <br />EMUSAVX rmb 2 ; temp storage of X for 6801/6803 emu <br />EMUSAVD rmb 2 ; temp storage of D for 6801/6803 emu <br />
<br />
EMUSTACK rmb 3 ; temp stack for 6801/6803 emu calls<br />EMUSTKTOP rmb 1<br />
<br />
emu_abx<br />
pshb<br /> psha<br /> stx EMUSAVX<br /> clra<br /> addb EMUSAVX+1<br /> adca EMUSAVX<br /> staa EMUSAVX<br /> stab EMUSAVX+1<br /> ldx EMUSAVX<br /> pula<br /> pulb<br /> rts<br /><br />emu_pshx<br />
stx EMUSAVX ; save X<br /> tsx<br /> staa EMUSAVD ; save A & B<br /> stab EMUSAVD+1<br /> ldaa ,x ; get return address from stack<br /> ldab 1,x<br /> pshb ; push return address onto stack<br /> psha ; - also adjusts stack pointer<br /> ldaa EMUSAVX ; retrieve X value<br /> ldab EMUSAVX+1<br /> staa ,x ; save X value onto stack<br /> stab 1,x<br /> ldaa EMUSAVD ; restore A & B<br /> ldab EMUSAVD+1<br /> ldx EMUSAVX ; restore X value<br /> rts<br />
<br />
emu_pulx</blockquote>
<blockquote>
tsx<br /> staa EMUSAVD ; save A & B<br /> stab EMUSAVD+1<br /> ldab 3,x ; get X from stack<br /> ldaa 2,x<br /> staa EMUSAVX ; save X<br /> stab EMUSAVX+1<br /> pula ; get return address from stack<br /> pulb ; - also adjusts stack pointer<br /> stab 3,x ; save return address onto stack<br /> staa 2,x<br /> ldaa EMUSAVD ; restore A & B<br /> ldab EMUSAVD+1<br /> ldx EMUSAVX ; set new X value<br /> rts</blockquote>
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New", Courier, monospace;">Simple Rewrite</span></span></b><br />
<br />
Perhaps the most complicated new 6801/6803 instruction is "MUL", which of course multiplies the 8-bit accumulators A and B to produce a 16-bit product in the D accumulator. I anticipated coding a lengthy routine to emulate this instruction, but I found that the code was only doing a multiply by a fixed value of 5! Two left shifts and a single add produced equivalent results, so "MUL" was no longer an issue... :-)<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New", Courier, monospace;">More To Come</span></span></b><br />
<br />
I think that covers the remaining "prep" work for the uchroma68 port of Space Assault. At this point, I have code for a machine that does not exist: an MC-10 with a 6800 CPU. The result, of course, will run on a normal MC-10 -- but that would be a pointless objective. I would show a demo video here, but the result is virtually indistinguishable from Darren's original code. Hopefully you can just trust me -- it works. ;-)<br />
<br />
The next step will be accounting for differences between the board-level architectures of the MC-10 and the uchroma68. This involves differing locations for video memory, and for where the code and data are loaded and stored. It also involves accounting for <a href="https://en.wikipedia.org/wiki/Input/output">I/O</a> differences, such as reading inputs from the keyboard and possibly making sounds. It will all be very much "<a href="https://en.wiktionary.org/wiki/in_the_weeds">in the weeds</a>", of course...stay tuned!<br />
<br />
<br />John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com5tag:blogger.com,1999:blog-2445192656245527812.post-343855995703435972020-01-27T13:02:00.000-08:002020-01-27T13:21:36.737-08:00Micro Chroma 68 Tape StorageIn my previous post, I showed video of me loading and running code on an emulated <a href="http://vdgtricks.blogspot.com/2014/01/building-micro-chroma-68-kit.html">Micro Chroma 68</a> (aka uchroma68) machine, and hinted at a bigger project. I intended to be back sooner to describe the code loading process and then move-on to the bigger project. But, I got started on the bigger project and neglected the next blog update -- time to get back on track!<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "courier new" , "courier" , monospace;">Audio-Encoded Data</span></span></b><br />
<br />
Code can be loaded onto the uchroma68 in a variety of ways, including from the keyboard input or over an audio-encoded interface intended for using "<a href="https://en.wikipedia.org/wiki/Cassette_tape">compact cassettes</a>" for mass storage. For real hardware, other options include modifications to use an <a href="https://abra-electronics.com/ics-semiconductors/6800-series/6850-asynchronous-communications-interface-adapter-acia-6850.html">ACIA</a> for serial input or <a href="http://www.willegal.net/appleii/appleii-kb-int.htm">modern interfaces</a> to drive the keyboard interface from a remote computer. But since our objective includes targeting the unmodified MAME-emulated uchroma68, it seems best to pursue only standard options for loading code.<br />
<br />
So, how to convert object coded into appropriate audio?<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "courier new" , "courier" , monospace;"><a href="https://en.wikipedia.org/wiki/Kansas_City_standard">Kansas City Standard</a></span></span></b><br />
<br />
<blockquote class="tr_bq">
<i>The <b>Kansas City standard</b> (<b>KCS</b>), or <b>Byte standard</b>, is a way of storing digital data on standard <a href="https://en.wikipedia.org/wiki/Cassette_tape" title="Cassette tape">Compact Audio Cassettes</a> at data rates of 300 to 2400 bits per second (at 300–2400 <a href="https://en.wikipedia.org/wiki/Baud" title="Baud">baud</a>) that was first defined in 1976. It originated in a symposium sponsored by <a href="https://en.wikipedia.org/wiki/Byte_(magazine)" title="Byte (magazine)">Byte magazine</a> in November 1975 in <a href="https://en.wikipedia.org/wiki/Kansas_City,_Missouri" title="Kansas City, Missouri">Kansas City, Missouri</a> to develop a standard for storage of digital <a href="https://en.wikipedia.org/wiki/Microcomputer" title="Microcomputer">microcomputer</a> data on inexpensive consumer quality cassettes.</i></blockquote>
The uchroma68 uses the Kansas City Standard for audio data encoding. This old standard defined how to transfer bits and bytes as audio, suitable for storage on consumer audio tape. Fortunately for me, open source tools (e.g. <a href="http://www.dabeaz.com/py-kcs/">py-kcs</a>) already exist for encoding and decoding such audio. Unfortunately, some of those tools presume to deal only with ASCII-encoded test files (e.g. BASIC programs). Since I needed to deal with binary data, I did have to write a patch to allow for handling binary input to the KCS encoder:<br />
<blockquote class="tr_bq">
diff --git a/kcs_encode.py b/kcs_encode.py<br />
index 21bbf080917d..1f078dd0b537 100755<br />
--- a/kcs_encode.py<br />
+++ b/kcs_encode.py<br />
@@ -52,7 +52,7 @@ def kcs_encode_byte(byteval):<br />
<br />
# Write a WAV file with encoded data. leader and trailer specify the<br />
# number of seconds of carrier signal to encode before and after the data<br />
-def kcs_write_wav(filename,data,leader,trailer):<br />
+def kcs_write_wav(filename,data,leader,trailer,binary):<br />
w = wave.open(filename,"wb")<br />
w.setnchannels(1)<br />
w.setsampwidth(1)<br />
@@ -64,7 +64,7 @@ def kcs_write_wav(filename,data,leader,trailer):<br />
# Encode the actual data<br />
for byteval in data:<br />
w.writeframes(kcs_encode_byte(byteval))<br />
- if byteval == 0x0d:<br />
+ if not binary and byteval == 0x0d:<br />
# If CR, emit a short pause (10 NULL bytes)<br />
w.writeframes(null_pulse)<br />
<br />
@@ -74,16 +74,29 @@ def kcs_write_wav(filename,data,leader,trailer):<br />
<br />
if __name__ == '__main__':<br />
import sys<br />
- if len(sys.argv) != 3:<br />
- print("Usage : %s infile outfile" % sys.argv[0],file=sys.stderr)<br />
+ import optparse<br />
+<br />
+ p = optparse.OptionParser()<br />
+ p.add_option("-b",action="store_true",dest="binary")<br />
+ p.add_option("--binary",action="store_true",dest="binary")<br />
+ p.set_defaults(binary=False)<br />
+<br />
+ opts, args = p.parse_args()<br />
+ if len(args) != 2:<br />
+ print("Usage : %s [-b] infile outfile" % sys.argv[0],file=sys.stderr)<br />
raise SystemExit(1)<br />
<br />
- in_filename = sys.argv[1]<br />
- out_filename = sys.argv[2]<br />
- data = open(in_filename,"U").read()<br />
- data = data.replace('\n','\r\n') # Fix line endings<br />
- rawdata = bytearray(data.encode('latin-1'))<br />
- kcs_write_wav(out_filename,rawdata,5,5)<br />
+ in_filename = args[0]<br />
+ out_filename = args[1]<br />
+ if opts.binary:<br />
+ data = open(in_filename, 'rb').read()<br />
+ rawdata = bytearray(data)<br />
+ else:<br />
+ data = open(in_filename, 'r', newline=None).read()<br />
+ data = data.replace('\n','\r\n') # Fix line endings<br />
+ rawdata = bytearray(data.encode('latin-1'))<br />
+<br />
+ kcs_write_wav(out_filename,rawdata,5,5,opts.binary)</blockquote>
With that, I could encode audio data for the uchroma68 by using the '-b' option which I added to kcs_encode.py. But what about the logical format of that data?<br />
<b><span style="font-size: large;"><span style="font-family: "courier new" , "courier" , monospace;"> </span></span></b><br />
<b><span style="font-size: large;"><span style="font-family: "courier new" , "courier" , monospace;">JBUG-Compatible Format</span></span></b><br />
<br />
Knowing how to send 0's and 1's is not too helpful until one knows what 0's and 1's to send. Even a program binary still needs to be accompanied by information such as where to write the program in memory and perhaps protocol data used to manage the transfer. The TVBUG firmware on the uchroma68 uses a format for binary data that is compatible with the format used by the JBUG firmware from the <a href="https://en.wikipedia.org/wiki/MEK6800D2">MEK6800D2</a> board which had preceded it, although TVBUG allows for an extension to the format that provides for the program name to be encoded along with the program data. Based on information from the TVBUG and JBUG manuals and some reading of the assembly language listings of those programs, I was able to write a script that converts a binary program file into a <a href="https://en.wikipedia.org/wiki/Hex_dump">hex dump</a> representing the data prepared for audio encoding:<br />
<blockquote class="tr_bq">
#!/bin/sh<br />
<br />
###########################################################<br />
# Convert a binary to hexdump of JBUG logical tape format<br />
# (used by both JBUG and TVBUG)<br />
###########################################################<br />
<br />
usage() {<br />
cat <<USAGE<br />
usage: $(basename $0) [-l <loadaddr>] [-n <progname>] [-p] <filename><br />
<br />
-l <loadaddr> base load address<br />
-n <progname> output program name<br />
-p pad tape output with 0xff characters<br />
<filename> input data file<br />
USAGE<br />
}<br />
<br />
while getopts ":l:n:p" opt<br />
do<br />
case ${opt} in<br />
l)<br />
LOADADDR=$OPTARG<br />
;;<br />
n)<br />
PROGNAME=$OPTARG<br />
;;<br />
p)<br />
PADOUT=1<br />
;;<br />
\?)<br />
echo "Invalid option: $OPTARG" 1>&2<br />
;;<br />
:)<br />
echo "Invalid option: $OPTARG requires an argument" 1>&2<br />
;;<br />
esac<br />
done<br />
shift $((OPTIND-1))<br />
<br />
# Set default load address of zero (if not specified on command-line)<br />
LOADADDR=${LOADADDR:-0}<br />
<br />
if [ $# -ne 1 ]<br />
then<br />
usage<br />
exit 1<br />
fi<br />
<br />
INFILE=$1<br />
INSIZE=$(stat -c %s $INFILE)<br />
<br />
if [ x$PADOUT = x1 ]<br />
then<br />
for i in $(seq 1 1024)<br />
do<br />
echo -n 'ff'<br />
done<br />
echo<br />
fi<br />
<br />
if [ -n "$PROGNAME" ]<br />
then<br />
echo -n $PROGNAME | xxd -p<br />
echo '0d'<br />
fi<br />
<br />
OUTSIZE=0<br />
while [ $OUTSIZE -lt $INSIZE ]<br />
do<br />
BLOCKSIZE=$(($INSIZE - $OUTSIZE))<br />
if [ $BLOCKSIZE -gt 256 ]<br />
then<br />
BLOCKSIZE=256<br />
fi<br />
<br />
echo -n 'ff'<br />
echo -n '42'<br />
printf '%x' $(($BLOCKSIZE - 1))<br />
printf '%04x' $(($LOADADDR + $OUTSIZE))<br />
<br />
xxd -p -g 1 -l $BLOCKSIZE -s $OUTSIZE $INFILE<br />
<br />
OUTSIZE=$(($OUTSIZE + $BLOCKSIZE))<br />
done<br />
<br />
if [ x$PADOUT = x1 ]<br />
then<br />
for i in $(seq 1 144)<br />
do<br />
echo -n 'ff'<br />
done<br />
fi<br />
<br />
echo -n 'ff'<br />
echo '47'</blockquote>
The hex dump output can be fed to the xxd utility (e.g. 'xxd -p -r'), captured, and then encoded to Kansas City Standard format audio.<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "courier new" , "courier" , monospace;">Demo</span></span></b><br />
<br />
In my earlier post, I mentioned "a text-based animation that I originally ported from a <a href="https://en.wikipedia.org/wiki/VTech_Laser_200">VZ-200</a> C program to assembly language for the <a href="https://en.wikipedia.org/wiki/TRS-80_MC-10">MC-10 </a>which I had always suspected would be easy to get on the uchroma68". Well, I was right -- changing two "equ" statements (one for the load address and one for the screen address) was all that was required...<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/W0jjjRF5eCA/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/W0jjjRF5eCA?feature=player_embedded" width="320"></iframe></div>
<br />
But wait -- there's more! The bigger project involves more porting from the MC-10 to the Micro Chroma 68, this time porting some code that originated on the Tandy Color Computer before being ported by Darren Atkinson.<br />
<br />
Intrigued? Then stay tuned...John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com0tag:blogger.com,1999:blog-2445192656245527812.post-61495845709512365012019-12-31T12:40:00.000-08:002019-12-31T12:53:58.962-08:00Micro Chroma 68 RevisitedAbout six years ago, on this blog I <a href="http://vdgtricks.blogspot.com/2014/01/building-micro-chroma-68-kit.html">documented the build</a> of an original <a href="https://en.wikipedia.org/wiki/Motorola">Motorola</a> Micro Chroma 68 (aka "uchroma68") kit. The "kit" was intended as an evaluation platform for the <a href="https://en.wikipedia.org/wiki/Motorola_6847">6847 VDG</a> and consisted of a <a href="https://en.wikipedia.org/wiki/PCB">PCB</a> and the major <a href="https://en.wikipedia.org/wiki/Integrated_circuit">IC</a>s like the <a href="https://en.wikipedia.org/wiki/Motorola_6800">6808 CPU</a>, 6847 VDG, etc. (I had to acquire the various other bits, mosty <a href="https://en.wikipedia.org/wiki/Electronic_component#Passive_components">passive components</a>.) I enjoyed the build process and even hoped to target the machine for some <a href="https://en.wikipedia.org/wiki/Retrogaming">retro games</a> development. Nevertheless, the overall lack of available hardware made this platform seem too niche to be a priority for development. After I wrote a simple program to demonstrate the machine working, I essentially set aside the uhroma68 and largely ignored it.<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "courier new" , "courier" , monospace;">Virtual Reality</span></span></b><br />
<br />
Of course, I never forgot about the uchroma68. Recently in my Internet wanderings, I came across the news that <a href="https://en.wikipedia.org/wiki/MAME">MAME</a> had added <a href="https://github.com/mamedev/mame/commit/cc9b9974375947a1769689e74594f2b5d1aa56b9">uchroma68 support</a>:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/M4Bbxj0rKT8/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/M4Bbxj0rKT8?feature=player_embedded" width="320"></iframe></div>
<br />
This bit of news was exciting enough to inspire me to install the proper <a href="https://en.wikipedia.org/wiki/ROM_image">ROM images</a> and update my MAME installation in order to try out the emulation. Having done so, I decided to pursue how to get my old example program running on the emulator:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/38La3oqXQfQ/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/38La3oqXQfQ?feature=player_embedded" width="320"></iframe></div>
<br />
<b><span style="font-size: large;"><span style="font-family: "courier new" , "courier" , monospace;">Whet Your Appetite</span></span></b><br />
<br />
Getting this far was fun and not without some challenges. I'll save those details for the next post! Plus, I have a text-based animation that I originally ported from a <a href="https://en.wikipedia.org/wiki/VTech_Laser_200">VZ-200</a> C program to assembly language for the <a href="https://en.wikipedia.org/wiki/TRS-80_MC-10">MC-10 </a>which I had always suspected would be easy to get on the uchroma68. That might provide a better taste of the uchroma68 platform and how it is similar to the MC-10.<br />
<br />
Beyond that, I have another porting project in the works that involves a headstart provided by a very clever partner. I think you will enjoy that one, and it might bring us the best game to come to the uchroma68 so far. Intrigued? Well...stay tuned!John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com0tag:blogger.com,1999:blog-2445192656245527812.post-40879827427773857822016-01-30T15:34:00.000-08:002016-01-30T15:34:28.873-08:00RC2016/01 Wrap-UpHere we are at the end of <a href="http://www.retrochallenge.net/">RC2016/01</a>, and what have we got? Well in my case I have a port of <a href="http://www.tuxdriver.com/download/xmasrush/">Xmas Rush</a> for the <a href="https://en.wikipedia.org/wiki/TRS-80_MC-10">TRS-80 MC-10</a> -- very exciting stuff! At the end of my last post on the topic, there was still some timer stuff to handle and some "odds and ends". So, let's see how that went...<br /><br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/HP2jPCGVQqY/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/HP2jPCGVQqY?feature=player_embedded" width="320"></iframe></div>
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Pause To Experiment</span></span></b><br />
<br />
Early on I had thought that precision timing might not really be necessary, that perhaps the video glitches would be spread so thin that it would hardly be noticeable. Later, someone else made a similar suggestion. So I conducted an experiment that changed the game's time base to just a bit more than the time required for a single frame of video. This did have the predicted effect of spreading the video glitches around so as to make them less objectionable, but they were still both noticeable and constantly recurring. While I did not pursue any algorithmic changes to the drawing routines that might have made this even less objectionable, the experiment cemented my belief that stable timing synchronized with the video hardware remained a worthwhile pursuit.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/C1hD_DYAeME/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/C1hD_DYAeME?feature=player_embedded" width="320"></iframe></div>
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Help From Afar!</span></span></b><br />
<br />
I implemented the timing synchronization by enlisting help from the user to position a marker off-screen. This marker represented the time the video hardware was not actively drawing the screen, and moving it off-screen equated to synchronizing the program to do its animation while the hardware was not actively drawing. This solution is quite effective, and I don't think it is objectionable for the user to do this once when starting the game.<br />
<br />
The timing I am seeing here at home is the roughly 60Hz timing of NTSC video. Of course, in much of the world the video standards are timed for 50 Hz vertical refresh rates. By adding a user choice between 50Hz and 60Hz and a corresponding variable used for timer setting, I was able to accommodate that situation. However, I don't have an MC-10 that uses PAL video or one of the French MC-10 clones, the <a href="https://en.wikipedia.org/wiki/Matra_Alice">Matra Alice</a>. Luckily I was able to reach out for testing help on the <a href="https://groups.yahoo.com/neo/groups/trs80mc10club/info">Yahoo MC-10 group</a>. There I found <a href="https://groups.yahoo.com/neo/groups/trs80mc10club/conversations/messages/6168">confirmation</a> that my 50Hz timer synchronization was working too.<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">One Last Bug... </span></span></b><br />
<br />
Along with that testing came a <a href="https://groups.yahoo.com/neo/groups/trs80mc10club/conversations/messages/6181">report</a> that in some cases the snowmen would overlap and disappear! Worse, even in this vanished state they could still capture the player, causing him to lose...what was going on?<br />
<br />
The moving objects in Xmas Rush are drawn using an XOR operation against the existing screen data. The primary reason for this is to highlight the case when a snowman captures the player, but a side effect is that when two snowmen exactly overlap then they cancel each other out on the screen and seemingly disappear. In order to counteract that I have a series of tests in the snowmen movement routines that were intended to prevent an exact overlap. However, those test were clearly not working...<br />
<br />
The original 6809 code for the snowman position tests used a CMPD instruction to do a 16-bit comparison against the D register (i.e. the A register and B register together). The 6803 lacks such an instruction, so in the conversion process I compared 8-bits against A and the other 8-bits against B. This changed the flow just enough that I confused myself, and I ended-up checking each snowman's position against the position of only one other snowman, allowing overlaps to occur with the other two! Once I found that problem it was easy to correct, and now snowmen should generally be unable to eclipse one another.<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">That's A Wrap</span></span></b><br />
<br />
So anyway, that's about it for Xmas Rush on the MC-10. I'll get the MC-10 binaries added to the Xmas Rush web page and then I'll call it a month. I am really happy to have finally taken the time to learn more about the MC-10 and to put it to a decent use, and I hope you have enjoyed monitoring my progress along the way. I will probably have Xmas Rush on display at the <a href="http://www.glensideccc.com/cocofest/">25th annual "Last" Chicago CoCoFEST!</a> this April, if you want to stop and give it a go.<br />
<br />
Until next time, I hope you will find your own excuse to get out your retro computing gear and make it do something fun, useful, or otherwise enjoyable. And as always, I hope you will stay tuned!John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com2tag:blogger.com,1999:blog-2445192656245527812.post-25323594854758985332016-01-23T15:04:00.000-08:002016-01-23T15:04:48.223-08:00Checking My ListAnother week down and roughly one more left to go in the <a href="http://retrochallenge.net/">Retrochallenge</a> RC2016/01 event. I got off to a bit of a slow start this month, but since then things have progressed well. It looks like things are shaping-up nicely for my port of <a href="http://www.tuxdriver.com/download/xmasrush/">Xmas Rush</a> to the <a href="https://en.wikipedia.org/wiki/TRS-80_MC-10">TRS-80 MC-10</a>!<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/8SRT9vQ2kq4/0.jpg" src="https://www.youtube.com/embed/8SRT9vQ2kq4?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Time Is On My Side</span></span></b><br />
<br />
One of my main concerns with this port has been the lack of a <a href="https://en.wikipedia.org/wiki/Screen_tearing">vertical sync</a> signal available to the CPU on the MC-10. A direct port of the drawing algorithms from the <a href="https://en.wikipedia.org/wiki/TRS-80_Color_Computer">CoCo</a> version of Xmas Rush resulted in objects sometimes disappearing completely within certain vertical ranges of the screen. I considered altering the basic drawing algorithms in hopes of minimizing the screen problems, but that really seemed like a <a href="http://www.urbandictionary.com/define.php?term=Band-Aid+Solution">"band aid" solution</a> at best.<br />
<br />
The MC-10's <a href="http://www.alldatasheet.com/datasheet-pdf/pdf/126472/MOTOROLA/MC6803.html">Motorola 6803</a> CPU does have a hardware timer circuit, so precision timing is possible. The problem remains as to where (actually when) to anchor the timer settings. Since we know how long the screen is actively drawing and how long each frame lasts, we can derive the anchor point by interacting with the user. The timer is used to divide the screen into two periods, representing the active and inactive drawing times. A visual indicator is used to indicate the temporal position of the inactive period, and the user is asked to provide input that is used to relocate the inactive period until it's visual indicator is not visible. Once that temporal anchor is established, all that is required is to never miss a frame timer expiration... :-)<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/Gp8oIHY-slo/0.jpg" src="https://www.youtube.com/embed/Gp8oIHY-slo?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Watch Your Step</span></span></b><br />
<br />
Xmas Rush uses a bitwise map to represent the scrubby trees that comprise the playfield terrain. At game time, that map is also used to generate a data structure used to detect potential collisions between that terrain and the player and snowmen. Converting the original <a href="https://en.wikipedia.org/wiki/Motorola_6809">6809</a> code to 6803 code was a bit tricky, since the 6809 code made use of the extra index register available on that CPU. The conversion made a lot more use of the stack, reminding me of a <a href="https://en.wikipedia.org/wiki/Tower_of_Hanoi">Towers of Hanoi</a> game gone terribly wrong... Anyway, I eventually managed to sort that out and objects were suitably constrained from moving across the tree-filled terrain.<br />
<br />
With the player now moving about, it seemed like a good time to introduce the pitter-patter sound used during player motion. The CoCo version used the horizontal sync signal for timing <a href="https://en.wikipedia.org/wiki/Square_wave">square wave</a> generation, but the MC-10 is as equally unhelpful for horizontal sync as it is for vertical sync. I had hoped that I could do some tricky hardware timer manipulations to use the timer both for the vertial sync emulation and for sound timing, but I couldn't seem to master that feat. Instead, the sound timing is based around cycle-counted loops representing horizontal sync periods. This proved to be satisfactory for all of the sound generation in Xmas Rush.<br />
<br />
BTW, the pitter-patter sound is not a normal tone. Each up-down transition of the square wave is governed by the output of a <a href="https://en.wikipedia.org/wiki/Linear_feedback_shift_register">linear feedback shift register</a> (LFSR) used to generate pseudo-random data. In a very real sense, the pitter-patter sound is more of a noise than an actual tone.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/h_upWIFgc8E/0.jpg" src="https://www.youtube.com/embed/h_upWIFgc8E?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Win Or Lose</span></span></b><br />
<br />
It is important to be able to tell when the moving objects collide. This causes the player to lose when he collides with one of the snowmen, and it is a prerequisite for a win that the player must seize the evergreen tree. Xmas Rush does not have any special data structure for detecting sprite collisions. With so few sprites, it was easiest just to check each sprite position to see if it overlaps with the player.<br />
<br />
A set of flags is used within the game code to indicate which snowmen are active and whether or not the evergreen tree has been seized by the player. These flags are used in the drawing routines to control what is drawn in a given frame. The "seized" flag is also used in coordination with the player's position to detect a "win" condition. <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/ghZ-NVgTFlM/0.jpg" src="https://www.youtube.com/embed/ghZ-NVgTFlM?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
The last, big missing piece was the movement of the snowmen. Since the game loop erases and redraws every sprite during every frame, movement is nearly trivial -- just change the draw location and the object moves! Each of the four snowmen has its own movement strategy and a corresponding routine to implement that strategy. I won't divulge them here, but each strategy is fairly simple, and the snowmen can be manipulated into trapping themselves behind parts of the terrain as they pursue their personal strategy.<br />
<br />
Anyway, with moving snowmen the game is largely complete. All that remains is integration of the timer calibration code into the main program, and a few odds and ends. This week should see a successful end to this project...I hope you will stay tuned!John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com0tag:blogger.com,1999:blog-2445192656245527812.post-76579108195199397982016-01-15T14:01:00.000-08:002016-01-15T14:01:52.186-08:00RC2016/01 Half-time UpdateWow, half-way through January already! After a slow start, I now have my <a href="http://www.tuxdriver.com/download/xmasrush/">Xmas Rush</a> port to the <a href="https://en.wikipedia.org/wiki/TRS-80_MC-10">MC-10</a> well underway. I recorded a few more progress reports throughout the past week -- let's review!<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/AOyU05Im71M/0.jpg" src="https://www.youtube.com/embed/AOyU05Im71M?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Graphics Mode </span></span></b><br />
<br />
The Christmas tree on the title screen is drawn in a "<a href="https://en.wikipedia.org/wiki/Semigraphics">semi-graphics</a>" mode in which the low-resolution graphical glyphs are really just special characters, no different from numerals, punctuation, and letters of the alphabet. These are handy for a number of things, but they are generally not as flexible as the "high-resolution" graphics used for the main part of the game. Fortunately, switching to graphics mode is fairly simple to do.<br />
<br />
The <a href="https://en.wikipedia.org/wiki/Motorola_6847">6847 Video Display Generator (VDG)</a> is configured through a collection of logic signals applied to its external pins. These can be wired a number of different ways, and even on the MC-10 some of the configuration pins are actually driven directly by the incoming video data. The rest are connected to a small register on the MC-10 motherboard. That register can be changed by writing to any address between $9000 and $bfff, although $bfff is the conventional address to use. Writing an appropriate bit pattern to this address is all that is required to change the graphics mode.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/GccxD5fc3Yc/0.jpg" src="https://www.youtube.com/embed/GccxD5fc3Yc?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Coordinate Translation </span></span></b><br />
<br />
With graphics mode engaged, we need some way to specify where graphics are displayed on the screen. For simplicity's sake, I designed Xmas Rush to use a simple 32x32 grid for placing objects on the screen. This alignment naturally matches the number of horizontal bytes for each line, avoiding the need for any mask-and-shift operations when writing data to the screen. The X- and Y-coordinate for each object is stored in a two-bye pair that can be easily manipulated using the double-accumulator operations (e.g. LDD, STD, etc) available on the <a href="http://www.textfiles.com/bitsavers/pdf/motorola/MC6801RM_AD2_MC6801_Reference_Manual_May84.pdf">6803</a>.<br />
<br />
There is a bit of math involved in translating a set of coordinates on the 32x32 grid into an address for accessing the <a href="https://en.wikipedia.org/wiki/Framebuffer">framebuffer</a>. Of course, I already had <a href="https://en.wikipedia.org/wiki/Motorola_6809">6809</a> code to do this on the <a href="https://en.wikipedia.org/wiki/TRS-80_Color_Computer">CoCo</a>. Blindly translating that to 6803 code for the MC-10 quickly provided satisfactory results.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/yAx5Fj0rsbU/0.jpg" src="https://www.youtube.com/embed/yAx5Fj0rsbU?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Timing Again </span></span></b><br />
<br />
From there, I quickly conquered the task of drawing the playfield. Xmas Rush uses a bitmap to describe the placement of all the bare trees that make-up the playfield. Translating the relevant 6809 code from the CoCo to 6803 code for the MC-10 again proved an easy task, allowing me to begin work on the fundamentals of constructing the game loop.<br />
<br />
The CoCo version of Xmas Rush uses a graphics animation technique known as "<a href="http://gameprogrammingpatterns.com/double-buffer.html">double buffering</a>". At any give time one buffer is displayed while the other is redrawn for the next frame of animation. Periodically a <a href="https://en.wikipedia.org/wiki/Analog_television#Vertical_synchronization">vertical sync</a> event occurs. At that time the program changes which buffer is actually displayed, and work shifts to clearing and redrawing the previous buffer. This technique prevents ever displaying a partially drawn frame, and it provides a natural source of "<a href="https://en.wikipedia.org/wiki/Real-time_clock">real time</a>" information for pacing the game.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/YeReLq9LiKM/0.jpg" src="https://www.youtube.com/embed/YeReLq9LiKM?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
The MC-10 provides no means for the CPU to observe when a vertical sync event happens, but it does provide an internal timing source that can be used for game pacing. My initial attempt to use this timing source as a substitute for the vertical sync event was disappointing, because I was resetting the timer based upon its current value (a moving target) rather than as an offset from the previous setting. A little fix stabilized the timing so at least the game can be paced correctly.<br />
<br />
The current timing technique is still prone to showing some weird video effects, depending on the exact timing between the game and what the VDG is doing. I think that a manual, user-driven timing synchronization is possible. Alternatively, maybe just some random resets will be acceptable -- this would be similar to the "reset until this is blue" that was so common on CoCo games that used <a href="https://en.wikipedia.org/wiki/Composite_artifact_colors">NTSC "artifact" colors</a>.<br />
<br />
In any case, there is still some work to be done adding player movement, snowman AI, and other missing game bits. This is a good start, but it needs a good finish. Do you want to see how it ends-up? Then you will just have to stay tuned...John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com0tag:blogger.com,1999:blog-2445192656245527812.post-5224350973258293982016-01-10T15:29:00.000-08:002016-01-10T15:29:02.833-08:00MC-10 FamiliarizationProgramming retro computers is not rocket science. After all, it wasn't that long ago that <a href="http://www.frombedroomstobillions.com/">teenagers and grade-schoolers</a> regularly produced commercial-quality programs on these very machines! Nevertheless, a new machine always has some new idiosyncrasies and a few tricks to learn to make them useful. The <a href="https://en.wikipedia.org/wiki/TRS-80_MC-10">MC-10</a> is no exception, and much of my time spent with that machine in the past week has been devoted to learning a few such tips and tricks...<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/tfR3QX21nT8/0.jpg" src="https://www.youtube.com/embed/tfR3QX21nT8?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Time Well Spent</span></span></b><br />
<br />
I like to make use of "real time" sources to control events in my games. Hand-coded loops and cycle counting can be an effective soure of "real time" information, but they are fragile. Small changes in the game code can produce large timing differences than can be difficult to predict and painful to recode again and again. On the <a href="https://en.wikipedia.org/wiki/TRS-80_Color_Computer">CoCo</a>, I often use the <a href="http://www-inst.eecs.berkeley.edu/~cs150/sp99/sp99/project/compvideo.htm">vertical and horizontal sync signals</a> as reliable sources of timing information. Unfortunately, the MC-10 makes no provision for accessing either sync source.<br />
<br />
Fortunately, the <a href="http://datasheets.chipdb.org/Motorola/mc6801_3.pdf">Motorola 6803</a> CPU in the MC-10 has a little "secret" -- an internal timer! The timer functionality is based on counting elapsed CPU clock pulses, which amounts to a source of "real time" information. Using this timer I was able to replace the hand-coded timing loop in my screen flashing example program, unlocking the ability to accurately time game events.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/lXX6K6dU-Bo/0.jpg" src="https://www.youtube.com/embed/lXX6K6dU-Bo?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Key Exercises</span></span></b><br />
<br />
Moving along from timing, it should be obvious that a game needs some form of input to indicate what the player wants to do in the game. A joystick would seem like an obvious choice, but the MC-10 has no joystick ports. It does, however, have a keyboard. The MC-10 keyboard employs a reasonably standard switch matrix that the CPU controls by outputing a value at one location and reading back a value from another location. This is similar to how the keyboard is read on the CoCo and on any number of other systems.<br />
<br />
Conversely, a game needs some form of output. Graphics are obvious, but a little audio can be a big plus. The MC-10 has no sound chip, and it does not even have the CoCo's <a href="https://en.wikipedia.org/wiki/Digital-to-analog_converter">DAC</a>. However, it does have a 1-bit digital output for producing audio, similar to the <a href="https://en.wikipedia.org/wiki/Apple_II">Apple II</a> or the <a href="https://en.wikipedia.org/wiki/ZX_Spectrum">ZX Spectrum</a>. Producing audio on the MC-10 is reasonably simple, particularly with control of the timer. There is even a <a href="https://en.wikipedia.org/wiki/BIOS_interrupt_call">ROM call</a> available for producing simple tones. One might be surprised at how much is possible with <a href="http://shiru.untergrund.net/1bit/">1-bit audio</a>, but simple tones will be more than enough for porting <a href="http://www.tuxdriver.com/download/xmasrush/">Xmas Rush</a>.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/xuyUSOZXfIA/0.jpg" src="https://www.youtube.com/embed/xuyUSOZXfIA?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Practice Porting</span></span></b><br />
<br />
So with a few exercises under my belt, it is time to start porting. Since the MC-10 has the same <a href="https://en.wikipedia.org/wiki/Motorola_6847">Motorola 6847</a> video chip as the CoCo and can support all of the video modes used by Xmas Rush, there is practically no need to generate new graphic data for anything. I started by reproducing the "intro" and "tally" screens using the same data used in the CoCo version. I did change some of the text to reflect the use of the MC-10 keyboard rather than the (non-existent) joystick port. Incidentally, the Christmas tree graphic was produced using Simon Jonassen's web-based <a href="http://cocobotomy.roust-it.dk/sgedit/">sgedit</a> utility -- very handy!<br />
<br />
Well, that is my little recap of this week's progress. I am pleased with my results so far! The biggest challenge has been figuring-out how to port 6809 code to it's poorer cousin, the 6803. Most of the Xmas Rush graphics data should remain intact, and most algorithms will be virtually the same (albeit written for the register-poor 6803). The biggest problem I forsee right now will be dealing with the single, fixed video buffer on the MC-10. I don't think that problem will be too tough, but there could be problems. If you want to see how that goes, then you will just have to stay tuned!John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com0tag:blogger.com,1999:blog-2445192656245527812.post-50093566042526636342016-01-05T18:12:00.001-08:002016-01-05T18:12:49.835-08:00A Little Prodding Helps!More than half-way through the first week of <a href="http://www.retrochallenge.net/">RC2016/01</a>, and not surprisingly I am barely getting started. Slow Retrochallenge starts seem to have become a habit for me! Hopefully this competition will at least end better for me than the last one did...<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxXAJqQa0G_OnDdenousRI_b1f4MT17zm6Z7pFAtX-SYTzYYGsDC4JTvEj5Z4S1LOZCSKQOuAcfGlOkRofoo5PwwRxPK_t-Ta7N3M7ERXtCknSz8aWwQ6xipOhl8CZfERRDrZb0QqvRf4/s1600/20160105_144845.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxXAJqQa0G_OnDdenousRI_b1f4MT17zm6Z7pFAtX-SYTzYYGsDC4JTvEj5Z4S1LOZCSKQOuAcfGlOkRofoo5PwwRxPK_t-Ta7N3M7ERXtCknSz8aWwQ6xipOhl8CZfERRDrZb0QqvRf4/s320/20160105_144845.jpg" width="320" /></a></div>
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Desktop MC-10</span></span></b><br />
<br />
The biggest reason for my sluggish Retrochallenge start is that I was still finishing-up some stuff I started during my extended end-of-the-year break in December. I generally use this yearly ritual to enjoy some retro projects and similar work, and this time was no exception. Along with a few soldering projects and other fun, I used a big portion of my time to straighten-up some of the disaster that is my office/bonus-room/man-cave. This time I even managed to clear-off the top of my desk and to reduce the biggest pile of junk to a somewhat smaller, mostly orderly pile of boxes!<br />
<br />
One of the soldering projects from my December break involved installing a composite video output circuit to my MC-10. (These are <a href="https://sites.google.com/site/thezippsterzone/mc-10-composite">available from Ed Snider</a>, and are highly recommended to other MC-10 owners!) The newly composite-capable MC-10 pairs nicely with an 8 inch Night Owl LCD monitor on my newly cleaned-off desk. In fact, I have it situated in such a way that the "cassette" interface cable easily reaches my development laptop, allowing me to load code on the MC-10 by simply playing a WAV file on my laptop.<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Wake-Up Calls</span></span></b><br />
<br />
We are far enough into the Retrochallenge event that I had started to get "how's it going?" inquiries from a few friends. This includes inquiries from CoCo (and MC-10) "demo coder" Simon Jonassen, fellow Retrochallenge competitor <a href="https://sites.google.com/site/cocoboot2/home/retrochallenge">Brett Gordon</a>, and even my old Linux colleague <a href="https://en.wikipedia.org/wiki/Alan_Cox">Alan Cox</a>. In particular, the latter inquiry proved to be enough to get me moving.<br />
<br />
I had no idea that Alan had been working on a project to enable playing the old <a href="https://github.com/EtchedPixels/ScottAdams6800">Scott Adams adventure games on the MC-10</a>. Anyway, Alan suggested using a slightly <a href="http://www.solorb.com/linux8bit/">modernized version of the old Motorola freeware assembler</a> which is maintained for Unix-like systems. He also pointed me at a tool he had written for making cassette images for loading machine code. I had solutions for these problems, but apparently Alan's code (and his interest in my project) was enough to get me off the couch -- thanks, Alan!<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">In Motion</span></span></b><br />
<br />
Back in March of 2014, there was a <a href="https://groups.yahoo.com/neo/groups/trs80mc10club/conversations/topics/4331">thread on the MC-10 Yahoo group</a> about getting an ASCII-based animation running on the MC-10 and other 6847-based machines. I had participated in this effort, and had some MC-10 assembly code as my result. As part of getting started with this project, I got that code out and running on the MC-10 on my desk. I also ported the code I had from my earlier <a href="http://vdgtricks.blogspot.com/2014/01/building-micro-chroma-68-kit.html">Micro Chroma 68 build</a> I did as a Retrochallenge project. I now feel "in the groove" for writing some new code for the MC-10.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/woEDtWg6r1Q/0.jpg" src="https://www.youtube.com/embed/woEDtWg6r1Q?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
Originally, I had envisioned porting a monitor program for loading code over the
serial port. However, the rebuild/reload/run cycle with my current arrangement seems fairly quick and is convenient enough to make me
question the need for that porting effort. Also, the MC-10 emulator support on Linux is better than I had realized, including both MAME/MESS support and a surprisingly good Javascript-based emulator at <a href="http://mc-10.com/">mc-10.com</a>. The latter even includes the ability to load cassette images from local storage directly into emulator memory -- fast and easy! So, I may just live with what I have and save the serial-port stuff for another day...maybe...<br />
<br />
Anyway, I suppose this post marks that I am officially underway with the RC2016/01 competition. If you want to see where I end-up, then I guess you will just have to stay tuned... John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com0tag:blogger.com,1999:blog-2445192656245527812.post-14773347994187574812015-12-31T14:53:00.001-08:002015-12-31T15:01:01.517-08:00Xmas Rush for the MC-10It's been a while since I've posted on this blog. I guess it is time to change that! A little Retrochallenge action should liven things up for a bit...<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Christmas Spirit</span></span></b><br />
<br />
Late in 2015 (just before the Thanksgiving holiday in the USA), I started thinking about making a Christmas-themed game for the <a href="https://en.wikipedia.org/wiki/TRS-80_Color_Computer">Tandy Color Computer</a> (CoCo). The original idea was to have a collection of 3 or 4 "mini games" with silly holiday references. I got started on that by putting together a simple game engine that used one of the 4-color modes on the CoCo. I tried to save time by taking the easy choice as often as possible, implementing simple blocky animation mechanisms, etc. Nevertheless, the holiday season brought with it some extra demands on my time...<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">What's the Rush?</span></span></b><br />
<br />
By mid-December or so I had only come-up with one mini-game, a scenario where you have to go into the forest, grab the last Christmas tree, and escape from the evil snowmen guarding the tree. It sounds silly, but it turned-out to be rather fun. With the self-imposed Christmas deadline approaching I decided to polish-up what I had and make the best of things by releasing it. The result was <a href="http://www.tuxdriver.com/download/xmasrush/">Xmas Rush</a>!<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/EcqZKGqq7dc/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/EcqZKGqq7dc?feature=player_embedded" width="320"></iframe></div>
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Challenge Accepted</span></span></b><br />
<br />
Now we are at the turn of the year. With the New Year comes the next <a href="http://www.retrochallenge.net/">Retrochallenge</a> event, <a href="http://www.wickensonline.co.uk/retrochallenge-2012sc/rc201601-entrants-list/">RC2016/01</a>! I have been participating in Retrochallenge events for a number of years, although my entry this past summer was a bit lackluster. Nevertheless, Retrochallenge is generally time well spent. The competition aspect makes for great motivation to get things done and the event provides great inspiration as an opportunity to observe what others are doing. I will continue what has become a tradition for me by entering again this year.<br />
<br />
But what is the entry? Well, one regret I had about the Xmas Rush development was that I didn't have time to document any of what I was doing. I suppose I could go back and do that as my entry, but that seems a bit lame. However, it occurred to me that the <a href="https://en.wikipedia.org/wiki/TRS-80_MC-10">MC-10</a> should be able to run Xmas Rush reasonably well. Plus, I have wanted to do an MC-10 project for some time. So for RC2016/01 I will port Xmas Rush to the MC-10, documenting the process along the way. Hopefully everyone will enjoy that!<br />
<br />
The MC-10 is a different processor than the CoCo, and it has a number of architectural limitations that make it more challenging as a development target that its more powerful cousin. Plus, I will have to put some work into building an MC-10 development environment that is friendly to my style of work. Hopefully none of those challenges in insurmountable...be sure to stay tuned!John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com0tag:blogger.com,1999:blog-2445192656245527812.post-59945497035794166482015-01-01T14:42:00.000-08:002015-01-03T11:43:14.405-08:0035 Colors On NTSCSome time ago, I played with a "flicker" technique on the CoCo that alternated screens between a 9-color (8 + black) "Semi-Graphics" mode and a 4-color "Color Graphics" mode on the VDG. I combined that with a technique for teasing 8 on-screen colors out of the 4-color mode, giving a combined effect of 44 on-screen colors! I then used this technique as the basis for showing puzzle pictures in Sluzzle, and there was much rejoicing...<br />
<br />
Not long after that, I conceived of a similar technique that might solve at least a few of the problems with the 44 color technique at the cost of reducing the palette size a bit. I let that sit dormant for a while, until I decided to play with it a bit during my 2014 year-end break. Below I will describe the 35 color technique for those interested in hearing more.<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Problems Abound</span></span></b><br />
<br />
The main problem with the 44 color "flicker" technique is, of course, the flicker. The mode toggles between the two base video modes (SG24 and G6C) at the vertical refresh rate (60 Hz on NTSC machines, 50 Hz on PAL machines). This produces a noticeable flicker effect on the displayed screen, but unfortunately this is inherent to any "flicker" technique -- sorry!<br />
<br />
The bigger problem with the 44 color technique is that it uses the aforementioned technique to get 8 on-screen colors from the 4-color modes of the VDG. This is achieved by switching the colorset select (i.e. CSS) input to the VDG <u>while a line is being drawn on the screen</u>! This changes between the two 4-color palettes as much as 8 times per line, doubling the amount of available colors on the screen. (This 8 color technique is also used in the CoCo version of the Imagic game Dragonfire.) Unfortunately the extra colors come at the cost of eating-up all of the available CPU while the 4- (now 8-)color screen is being drawn.<br />
<br />
The other big problem with the 44 color technique is that only one of the base modes offers the (non-)color black. Since the observed color at a given position is the average of the colors at that position on the two base screens, then no position will ever be observed as fully black. Although the available dark blue is a workable substitute in many case, the lack of a true black is a big handicap for the 44 color technique.<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Another Option</span></span></b><br />
<br />
If we accept that we will only get 4 on-screen colors from the 4-color base screen, then we could free-up more CPU time while that screen is displayed. This would allow more time for implementing a game, playing background music, or whatever else. But what about black pixels?<br />
<br />
It turns out that on NTSC CoCos (and Dragons), there is another option. Due to how an NTSC video signal encodes color (and how the CoCo video circuit is implemented), the black and white 256x192 VDG mode (G6R) is effectively a 128x192 4-color mode offering black, white, "blue" (cyan?), and "red" (orange?) pixels. This mode was very popular for commercial games on the Coco, and it is similar to using 4 of the 6 available colors in the high-res video mode of the Apple II.<br />
<br />
So now we can use a "flicker" technique to alternate between the G6R (i.e. PMODE4) "artifact color" mode and a Semi-Graphics mode. Since the G6R mode also offers black and white, both of those colors are still available when using the "flicker" technique! I will show the available palette below.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioPzHvgY6RoHoXxrQTgHd_18p-2r0rLENN3xpTT8FaHtKAAhO-vl5HO9oWiDI3tWOdz7aUEJcAVSJvQPS45EZ2ln3WH4qJK7z8DEFJmSX9h5wkC5yVXphjKLNOS3JG5ZoGlFts4YL_YhE/s1600/20150101_125449.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioPzHvgY6RoHoXxrQTgHd_18p-2r0rLENN3xpTT8FaHtKAAhO-vl5HO9oWiDI3tWOdz7aUEJcAVSJvQPS45EZ2ln3WH4qJK7z8DEFJmSX9h5wkC5yVXphjKLNOS3JG5ZoGlFts4YL_YhE/s1600/20150101_125449.jpg" height="180" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Semi-Graphics Palette</td></tr>
</tbody></table>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjoDljhGILdmfPNggCg6Swqsa1e8PiXxJzLxxlr4yWeN2F2a6uWkpla2Lyc9J2JdzF4VrkYvntQvpaSy4FJKcO3HE5aOgvfL2KavHxf2DjVRbVwAfQFkNmPbWYzKLUUIyCjSlfuKtw8_I4/s1600/20150101_125808.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjoDljhGILdmfPNggCg6Swqsa1e8PiXxJzLxxlr4yWeN2F2a6uWkpla2Lyc9J2JdzF4VrkYvntQvpaSy4FJKcO3HE5aOgvfL2KavHxf2DjVRbVwAfQFkNmPbWYzKLUUIyCjSlfuKtw8_I4/s1600/20150101_125808.jpg" height="180" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">G6R "artifact color" Palette </td></tr>
</tbody></table>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkvs9N5232RMuRBqXiums66DyWR4nmU86NysM5gO-w36VsO2RMRhrKbxt2PQLPeaahyXmW3mW5SSoCeSR85VIDQxXBva3vfvKLKdsNsn3IPpYNiXs_HFO3yTH2qLweJzbbJn90x8NE97I/s1600/20141227_151920-1.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkvs9N5232RMuRBqXiums66DyWR4nmU86NysM5gO-w36VsO2RMRhrKbxt2PQLPeaahyXmW3mW5SSoCeSR85VIDQxXBva3vfvKLKdsNsn3IPpYNiXs_HFO3yTH2qLweJzbbJn90x8NE97I/s1600/20141227_151920-1.jpg" height="258" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Combined "Flicker" Palette</td></tr>
</tbody></table>
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Issues Remain</span></span></b><br />
<br />
As you can see, this technique yields a nice range of usable colors from the VDG. It does, of course, still have a perceivable "flicker" on the screen. Also, the technique is limited to being used on NTSC displays. Of course, the G6R mode can be used as a 2-color mode on PAL machines -- by ignoring the "artifact" colors, this could also be viewed as a 17 color technique...<br />
<br />
Sticking with the NTSC world, there is one other problem. Anyone familiar with the use of "artifact" colors on the CoCo will know that the patterns corresponding to "blue" and "red" switch at random between resets. That is why so many CoCo games have an introductory screen with a message like "reset until this is blue". Any program using the 35 color technique described above will need to address the same issue.<br />
<br />
Finally, I am seeing some distortion to the colors near the top of the display. I have not yet determined why that is happening, and it might relate to something else I am doing -- YMMV. I'm going to downplay this distortion for now, as I believe it is likely caused by something outside the core of the technique described herein.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7BLEWgHSwPF4AoCcfONE7Ws0WkTd_Rr9MSyJoRg2xBcOPpx0BhbC92y-pmk-MHLaFjxy7I4OQn7jbrl2RI_rerzvr_XdyYFUzlELmBHYI0UtUEM8u8KZP71XYDUY9XwZxfA0EoyjHYTg/s1600/20150101_131932.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7BLEWgHSwPF4AoCcfONE7Ws0WkTd_Rr9MSyJoRg2xBcOPpx0BhbC92y-pmk-MHLaFjxy7I4OQn7jbrl2RI_rerzvr_XdyYFUzlELmBHYI0UtUEM8u8KZP71XYDUY9XwZxfA0EoyjHYTg/s1600/20150101_131932.jpg" height="180" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">44 Color Me</td></tr>
</tbody></table>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEidysJFpNqi6kExjkJ4XaYKCQNz8zFFI7BAWcy8oGTpHfycKO2pKh0COBsv4Jhdtk7w2xYXdpJRsb0Tl7m99gVIGsOZ7iosVlOlWHWMgRy6twUV7XKm1IAD2nFmOwtODR5I1GIK4qF-byI/s1600/20150101_132422.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEidysJFpNqi6kExjkJ4XaYKCQNz8zFFI7BAWcy8oGTpHfycKO2pKh0COBsv4Jhdtk7w2xYXdpJRsb0Tl7m99gVIGsOZ7iosVlOlWHWMgRy6twUV7XKm1IAD2nFmOwtODR5I1GIK4qF-byI/s1600/20150101_132422.jpg" height="180" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">35 Color Me</td></tr>
</tbody></table>
Nevertheless, I am getting decent results in my picture conversions using this 35 color technique. The availability of a true black makes a huge difference, and that largely compensates for the ~20% smaller color palette available versus the 44 color technique. With a lot more CPU time available, this technique could be useful for any number of programs on the CoCo including games.<br />
<br />
I'm not planning to do anything more with this technique right now, but I hope someone else finds it useful. I'm happy to consult with anyone that wants to try to make use of it. In any case, be sure to stay tuned... :-)John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com6tag:blogger.com,1999:blog-2445192656245527812.post-29990983690805721212014-02-02T12:13:00.000-08:002014-02-03T06:52:37.768-08:00Working KeyboardThe end of the Retrochallenge event freed me to work a bit on spiffing-up my <a href="http://www.68bits.com/micro-chroma-68.html">Micro Chroma 68</a> project. Still not happy with the keyboard hack, I looked in earnest at how I might fix things...<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjERkmKlro-NjhiBqBL5-SQson-u7m9FNRXwngQjuOB5Q0XgRo0IdyEzdo85szup7PkuA1lDzHeeeL53OdWi_3_L3kFY-XUWNlloH2JnhP7w-WXedEfZJbiPMxGArHwgX9b699YaYbR-Vo/s1600/20140202_143440.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjERkmKlro-NjhiBqBL5-SQson-u7m9FNRXwngQjuOB5Q0XgRo0IdyEzdo85szup7PkuA1lDzHeeeL53OdWi_3_L3kFY-XUWNlloH2JnhP7w-WXedEfZJbiPMxGArHwgX9b699YaYbR-Vo/s1600/20140202_143440.jpg" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Keyboard Adapter One-Shot Timer Circuit<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;"><br /></span></span></b></td></tr>
</tbody></table>
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">One Shot</span></span></b><br />
<br />
My <a href="http://vdgtricks.blogspot.com/2014/01/two-steps-forward.html">earlier experiences</a> with the <a href="http://www.willegal.net/appleii/appleii-kb-int.htm">PS/2 keyboard adapter</a> and my own hack to make it work with the Micro Chroma 68 suggested that either the adapter was not generating a strobe signal at all or that the <a href="http://www.youtube.com/watch?v=9v5Pn5ftwvM">TVBug</a> software was just missing it. The former seemed unlikely, so I set about to address the latter issue.<br />
<br />
Mike Willegal's documentation for the keyboard adapter tells me that the adapter should be generating an 125 microsecond pulse for every <a href="http://www.thefreedictionary.com/keystroke">keystroke</a>. That translates to a little more than 100 CPU cyles during the strobe signal. But since the strobe signal is not generating an interrupt, those 100 cycles may not be enough for TVBug to see the strobe if it happens to be doing something else.<br />
<br />
To address this, I fed the strobe signal from the adapter to a <a href="http://en.wikipedia.org/wiki/555_timer_IC">555 timer</a> circuit configured as a <a href="http://en.wikipedia.org/wiki/Multivibrator#Monostable_multivibrator_circuit">one-shot timer</a>. This allowed me to send a longer strobe to the Micro Chroma 68 after a keystroke. Experimenting a bit led me to use a 470 kΩ <a href="http://en.wikipedia.org/wiki/Resistor">resistor</a> and 0.1 μF <a href="http://en.wikipedia.org/wiki/Capacitor">capacitor</a>, resulting in a pulse width of 47 milliseconds -- quite a bit longer than what the adapter was generating! These values give me very reliable and pleasant keyboard entry, with no need for a magic "repeat the last key" button... :-)<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Grounded Out</span></span></b><br />
<br />
The Micro Chroma 68 keyboard interface also has provisions for 4 directional keys and a "Home" key. I guess these allow for moving the cursor around on the screen, but I'm not sure I see the usefulness. Anyway, letting them float was resulting in some random cursor movement as can be seen in some of my videos posted previously. While mucking with the keyboard interface, I took the opportunity to ground all of those signals. This also resulted in a much more pleasant TVBug experience. <br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Happy Camper</span></span></b><br />
<br />
So, that is one less nagging problem with my Micro Chroma 68 build! As long as I restrain myself from typing more than 20 characters per second (which would be 240 <a href="http://en.wikipedia.org/wiki/Words_per_minute">words per minute</a>), the keyboard is quite usable. With the new modifications I was able to reenter my flashing "Retrochallenge Rulez!" program much more easily than before.<br />
<br />
Anyway, it looks like the Retrochallenge event was extended until midnight GMT today. I wanted to get this posted so that my entry gets full consideration... :-) But in all seriousness, I do hope and expect to keep poking at this one a bit more for a little while longer. So, as always...stay tuned! John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com0tag:blogger.com,1999:blog-2445192656245527812.post-63184872920574396512014-01-31T14:45:00.001-08:002014-01-31T14:45:52.004-08:00Final LapThe end of the month is here, and with it the end of the <a href="http://www.retrochallenge.net/">Retrochallenge</a> Winter Warmup for 2014. Despite a few setbacks and unresolved issues, this has been a good one for me! But before I declare my contest entry complete, I should at least get some code running on this thing... :-)<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiQJgDDqO0Wvcm_jvGwqtMsfKCAJ7Kcpz88A5m2buLQ7ZNCdnFCh0UGfOXjcWgfzVyfhGVUnUiHymnYWzJ5nyfmKkebc0iOU5ipYMS7wMQfYl2mlKaXZgLM1g_Q4a_7_EEzjDP6L54K8GM/s1600/20140131_153238.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiQJgDDqO0Wvcm_jvGwqtMsfKCAJ7Kcpz88A5m2buLQ7ZNCdnFCh0UGfOXjcWgfzVyfhGVUnUiHymnYWzJ5nyfmKkebc0iOU5ipYMS7wMQfYl2mlKaXZgLM1g_Q4a_7_EEzjDP6L54K8GM/s1600/20140131_153238.jpg" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The Micro Chroma 68 Expressing Enthusiasm</td></tr>
</tbody></table>
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Some Assembly Required</span></span></b><br />
<br />
The TVBug <a href="http://en.wikipedia.org/wiki/Resident_monitor">monitor</a> on the <a href="http://www.68bits.com/micro-chroma-68.html">Micro Chroma 68</a> board only provides for loading machine language programs. So, the first step is to find an <a href="http://en.wikipedia.org/wiki/Assembly_language">assembler</a> for the <a href="http://en.wikipedia.org/wiki/Motorola_6800">Motorola 6800</a> family of processors that runs under my <a href="http://en.wikipedia.org/wiki/Linux">Linux</a> development environment. There are a number of options for this, although it seems that <a href="http://www.rogtronics.net/blog/?p=255">not all assemblers are created equal</a>! <a href="http://www.youtube.com/watch?v=0znNiN0lYAQ">We must be cautious...</a><br />
<br />
In the <a href="http://en.wiktionary.org/wiki/days_of_yore">days of yore</a>, <a href="http://en.wikipedia.org/wiki/Motorola">Motorola</a> operated a "<a href="http://en.wikipedia.org/wiki/Freeware">freeware</a>" <a href="http://en.wikipedia.org/wiki/Bulletin_board_system">BBS</a>. This BBS was originally available by <a href="http://en.wikipedia.org/wiki/Modem">modem</a>, and later over the Internet as an <a href="http://en.wikipedia.org/wiki/File_Transfer_Protocol">FTP</a> site. Some of the files there included <a href="http://en.wikipedia.org/wiki/Source_code">source code</a> for assemblers targeting the full range of Motorola's <a href="http://en.wikipedia.org/wiki/Central_processing_unit">CPU</a>s, including the 6800. Alas, the site is no more and it is now difficult to find even an old archive of it. If anyone knows of such an archive, please leave that info as a comment on this blog -- that site needs to be preserved!<br />
<br />
Fortunately, others found those tools useful as well. While the unadulterated sources are difficult to find, a variety of slightly modified versions are available from a number of places. So for now, I will be using the as0 assembler from the "<a href="http://www.solorb.com/linux8bit/masm.tar.gz">masm</a>" package. It is a simple tool, but it more then fills the need at hand.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjk2L45_WBkmShkt5Xg6VoK7lZH40YadP-y6D5vmnLRnFDgp2AjBIQQSKki-4uycgX-BoGRydSYJD45oAdLs9ddzdPYyQtK41-ERoHQLe0lvUT69MyuDcyy9ptkloDJWZVR7Et5_KmqlmY/s1600/20140131_152634.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjk2L45_WBkmShkt5Xg6VoK7lZH40YadP-y6D5vmnLRnFDgp2AjBIQQSKki-4uycgX-BoGRydSYJD45oAdLs9ddzdPYyQtK41-ERoHQLe0lvUT69MyuDcyy9ptkloDJWZVR7Et5_KmqlmY/s1600/20140131_152634.jpg" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Manual Code Entry In TVBug</td></tr>
</tbody></table>
<div class="separator" style="clear: both; text-align: center;">
</div>
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;"><a href="http://en.wikipedia.org/wiki/Hands-on">Hands-On</a> Programming</span></span></b><br />
<br />
The Micro Chroma 68 is already limited in its accessibility for loading programs, providing only an <a href="http://en.wikipedia.org/wiki/Kansas_City_standard">audio cassette interface</a> and the video/keyboard <a href="http://en.wikipedia.org/wiki/System_console">console</a>. Since I still have not received those magic <a href="http://en.wikipedia.org/wiki/Capacitor">capacitors</a> for the audio interface, I am limited to just the console for loading programs. The keyboard adapter I am using has a provision for input through a <a href="http://en.wikipedia.org/wiki/Serial_port">serial port</a> instead of the <a href="http://en.wikipedia.org/wiki/PS/2_port">PS/2</a> keyboard. But with the continuing <a href="http://vdgtricks.blogspot.com/2014/01/two-steps-forward.html">"repeated characters" problem</a>, manual intervention is still required.<br />
<br />
Undaunted, I wrote a small program to put a message on the screen and assembled it with the assembler mentioned above. The assembler outputs an <a href="http://en.wikipedia.org/wiki/SREC_%28file_format%29">S-record</a> file by default, but I also had it generate a listing file. That file had the <a href="http://en.wikipedia.org/wiki/Hexadecimal">hexadecimal</a> values for all of the <a href="http://en.wikipedia.org/wiki/Opcode">opcodes</a> and data for my program, allowing me to enter them into the TVBug monitor manually. The process was a bit tedious, but it was manageable for the small program in question.<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Flash In The Pan</span></span></b><br />
<br />
The original program merely cleared the display and wrote a new message to the screen. At the end of the program, I simply inserted a busy loop to keep my display on the screen rather than returning to TVBug. This worked fine, but didn't have quite enough sizzle for the end of the project. I checked the schematics and found that the <a href="http://www.batsocks.co.uk/readme/video_timing.htm">video timing</a> signals from the <a href="http://en.wikipedia.org/wiki/Motorola_6847">VDG</a> are available for the CPU to read on the Micro Chroma 68. So, I changed the end of the program to spin in a loop that counted those timing signals and periodically changed the display's color set between the green and orange options -- exciting! ;-)<br />
<br />
While changing the end of the program, I was faced with a problem. I had structured the code such that adding new code at the end would force me to reenter a significant amount of data in memory. My inherent laziness kicked-in and found another option -- I just jumped over the data and added new code at the end. Maybe this sheds some light on why "<a href="http://en.wikipedia.org/wiki/Spaghetti_code">spaghetti code</a>" was so prevalent and accepted back in the early days of computing? Or, maybe I am just a horrible coder...<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.youtube.com/embed/OAtlXvQsAZ8?feature=player_embedded' frameborder='0'></iframe></div>
<br />
Thus ends my entry for the Retrochallenge Winter Warmup 2014 event. I hope that all of you have enjoyed reading about it as much as I have enjoyed doing it! A few problems remain, and ultimately I would like to do something a bit more useful (or at least something more interesting) with the Micro Chroma 68 in the future. I can't help but think that it would look right at home mounted inside of an arcade cabinet...hmmm...<br />
<br />
Well, anyway...if you want to find-out what happens in the future then you'll just have to stay tuned!John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com0tag:blogger.com,1999:blog-2445192656245527812.post-69876814879056755362014-01-26T17:56:00.000-08:002014-01-26T18:06:13.792-08:00Two Steps ForwardMy <a href="http://www.68bits.com/micro-chroma-68.html">Micro Chroma 68</a> project is still in need of a solution for keyboard input. The original (and long-term) plan is to use the <a href="http://vdgtricks.blogspot.com/2014/01/all-keyed-up.html">Radio Shack ASCII-encoded keyboard</a>, but that isn't working at the moment. Until that gets fixed, I'll have to find some other option. Fortunately, others have already faced this sort of problem and at least one of their solutions is available...<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiro0V4R4mcepF5Z-1GEANL_mCrWVGoZ6amR98znmdEKFyqr_WCUpzt5B2gMsZB69-V01wj8YI_Uq3uV0Apa2UqyldP8Xz9VE4nu5eH6mq9os0Nk8Ew4G7-5c4Wf-0wzzfzElNrLPt7s4c/s1600/20140126_133453.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiro0V4R4mcepF5Z-1GEANL_mCrWVGoZ6amR98znmdEKFyqr_WCUpzt5B2gMsZB69-V01wj8YI_Uq3uV0Apa2UqyldP8Xz9VE4nu5eH6mq9os0Nk8Ew4G7-5c4Wf-0wzzfzElNrLPt7s4c/s1600/20140126_133453.jpg" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">PS/2 -> ASCII Keyboard Adapter</td></tr>
</tbody></table>
<span style="font-family: Courier New, Courier, monospace; font-size: large;"><b>Problem Solved?</b></span><br />
<br />
The Micro Chroma 68 was roughly contemporary with the <a href="http://en.wikipedia.org/wiki/Apple_I">Apple I</a>, and both used the same sort of ASCII-encoded keyboard. While original Apple I kits are <a href="http://en.wiktionary.org/wiki/hen's_teeth">as rare as hen's teeth</a>, replica kits are available and many people have built them. These Apple I builders have faced the same sort of keyboard problem that I am facing. So what do they do for keyboards?<br />
<br />
At least one person solved the issue by using a <a href="http://en.wikipedia.org/wiki/Microcontroller">microcontroller</a> to drive a (somewhat) modern <a href="http://en.wikipedia.org/wiki/PS/2_port">PS/2</a>-style keyboard on one side and the ASCII-encoded interface on the other. Even better, <a href="http://www.willegal.net/appleii/appleii-kb-int.htm">such a kit</a> is available for sale! I bought one and quickly built it. Initial testing even suggested that it was working...<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhFPOHMwCL-N5K9LbzHJokS099DIKx7RuuN6CFxrXJ936whjmsGvsBOMbxn2xR6o_6HFa3jxNirLCo7RVxs2UVaCKBFHsbhUNajLohvlB20N3e6_3BlOiDwr_KJh3pxcwzRIwmdRT5ygWc/s1600/20140126_133524.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhFPOHMwCL-N5K9LbzHJokS099DIKx7RuuN6CFxrXJ936whjmsGvsBOMbxn2xR6o_6HFa3jxNirLCo7RVxs2UVaCKBFHsbhUNajLohvlB20N3e6_3BlOiDwr_KJh3pxcwzRIwmdRT5ygWc/s1600/20140126_133524.jpg" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Close-Up Look At The Dead Bug Hack</td></tr>
</tbody></table>
<span style="font-family: Courier New, Courier, monospace; font-size: large;"><b><a href="http://en.wikipedia.org/wiki/Point-to-point_construction#.22Dead_bug.22_construction">Dead Bug</a></b></span><br />
<br />
Despite initial impressions of success, I soon discovered a problem -- when pressing a single key multiple times, only the first <a href="http://www.thefreedictionary.com/keystroke">keystroke</a> was recognized by the Micro Chroma 68! This is at least inconvenient and it could be crippling for entering data into the monitor program. What might be causing this?<br />
<br />
The ASCII-encoded interface was at best a '<a href="http://en.wikipedia.org/wiki/De_facto">de facto</a>' standard and at worst it was no standard at all. Such interfaces typically had 7 data signals and one strobe signal that signified when the data was valid. But, the polarity of those signals and the timing of the strobe could vary between implementations. The fact that any keys were being read by at all suggested that the data line polarity of the keyboard adapter matched the expectations of the Micro Chroma 68. But what about the strobe signal?<br />
<br />
The documentation for the PS/2 -> ASCII adapter indicated that the strobe signal goes high to signify that the keyboard data is valid. Checking the <a href="http://en.wikipedia.org/wiki/Source_code">source code</a> for the Micro Chroma 68's <a href="http://www.68bits.com/micro-chroma-68-manual.pdf">TVBug</a> monitor revealed that it was expecting the strobe signal to go low to indicate valid data. I could not visualize how this might account for the observed loss of repeated keystrokes, but it seemed worthwhile to at least make the interface match the expected behavior.<br />
<br />
I found a <a href="http://en.wikipedia.org/wiki/7400_series">74-series</a> inverter chip in my parts stash and added it to the PS/2 -> ASCII adapter circuit using a 'dead bug' style of construction. The hardware functions just as expected, and I verified that all of the connections were correct. Unfortunately, instead of the Micro Chroma 68 only accepting single keystrokes it then didn't see any keystrokes at all...<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhODW2n82paE6yXpR8p7p1ko5C3dttsq_XYsLh-N7dajLUBOGhyJdze2a5XyEpCCBTTf6eWI80qvQtYrSQIKapvXPPYI7LSka99VjjHziUTNf3igXsMsm4mQZHb9-Q4j96o9qz8kHzVBGE/s1600/20140126_140446.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhODW2n82paE6yXpR8p7p1ko5C3dttsq_XYsLh-N7dajLUBOGhyJdze2a5XyEpCCBTTf6eWI80qvQtYrSQIKapvXPPYI7LSka99VjjHziUTNf3igXsMsm4mQZHb9-Q4j96o9qz8kHzVBGE/s1600/20140126_140446.jpg" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Yet Another Hack...</td></tr>
</tbody></table>
<span style="font-family: Courier New, Courier, monospace; font-size: large;"><b>Make It Work</b></span><br />
<br />
Obviously, that was unacceptable. But, simply putting things back like before was only marginally better. So, what to do?<br />
<br />
When first observing the "no repeated keys" problem, I did some poking around and found that I could get the Micro Chroma 68 to accept a repeated key if I used a <a href="http://en.wikipedia.org/wiki/Test_probe">probe</a> to drive the strobe line myself. As I indicated above, I have verified the connection between the microcontroller on the keyboard adapter and the strobe line on the Micro Chroma 68 parallel keyboard input. So, I'm at a bit of a loss for why driving the signal manually works...<br />
<br />
I can only figure that the Micro Chroma 68 is somehow missing the strobe signal. I may be able to correct that with a <a href="http://en.wikipedia.org/wiki/Multivibrator#Monostable_multivibrator_circuit">one-shot timer</a>, or there may be some other problem that I'm not yet seeing. In the meantime, I have inserted a momentary push-button switch in series with the strobe line. This allows me to manually drive the strobe line when I need to repeat a keystroke, so at least I can get around the problem in the short-run.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.youtube.com/embed/9v5Pn5ftwvM?feature=player_embedded' frameborder='0'></iframe></div>
<br />
Once again I am left with an imperfect solution. In the long-term I hope to have a more polished result, but for now I'm just trying to get each thing working well enough to make the next step possible. I guess that is a bit like life, or parenting, or something... :-)<br />
<br />
Anyhow, now I've got a mostly working Micro Chroma 68 board (sans <a href="http://en.wikipedia.org/wiki/Kansas_City_standard">audio cassette storage interface</a>), I've got a way to view its video output (via a hack on a satellite board), and I've got a way to put information into the machine (with an extra step for repeating keystrokes). I may be limping a bit, but I think I can make it across the finish line!<br />
<br />
Now I suppose I have to brush-up on <a href="http://en.wikipedia.org/wiki/Motorola_6800">6800</a> <a href="http://en.wikipedia.org/wiki/Assembly_language">assembly language</a> and figure-out how to write a little program to run for the end of the contest. I've got some big distractions coming this week, so don't expect too much! But until then, please do stay tuned...John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com0tag:blogger.com,1999:blog-2445192656245527812.post-67200761077008602902014-01-23T11:43:00.000-08:002014-01-23T11:43:22.483-08:00Keep It CleanWhen last we left our daring hero, the <a href="http://www.68bits.com/micro-chroma-68.html">Micro Chroma 68</a> board was just barely showing some signs of life. The video output was stable, but the garbled mess on the screen was a telltale sign that something was still wrong with the circuit...<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglnQHOcgUYYrQkMyLIg0jV4qML2qqCsI7m8V8Wx9vTT9CmWXsAzNzPl6wQ1Chd8crDPhpMt-lEoaFSEezJVDz4IsONfMh6QHahgaGpoNqHEr3AuxyN6iNZOVnQ6qsdA2zo_1VkB0kOWps/s1600/20140122_170119.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglnQHOcgUYYrQkMyLIg0jV4qML2qqCsI7m8V8Wx9vTT9CmWXsAzNzPl6wQ1Chd8crDPhpMt-lEoaFSEezJVDz4IsONfMh6QHahgaGpoNqHEr3AuxyN6iNZOVnQ6qsdA2zo_1VkB0kOWps/s1600/20140122_170119.jpg" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Micro Chroma 68 Display</td></tr>
</tbody></table>
<span style="font-family: Courier New, Courier, monospace; font-size: large;"><b>By The Book</b></span><br />
<br />
The <a href="http://www.68bits.com/micro-chroma-68-manual.pdf">manual</a> for the Micro Chroma 68 board has some simple procedures defined for debugging a non-functioning board. The first step, of course, is simply to check your work: check power and ground connections; ensure that parts are installed correctly; and, check for shorted or open connections on the board itself. I completed those checks, yet the problem persisted. Fortunately, the next round of testing was more fruitful.<br />
<br />
The manual described a few simple and temporary modifications to make to the circuit. These modifications hold the <a href="http://en.wikipedia.org/wiki/Central_processing_unit">CPU</a> in reset while forcing the address decode circuitry to select the <a href="http://en.wikipedia.org/wiki/Read-only_memory">ROM</a> chip. This puts predictable values on the address and data lines, allowing for some simple testing with a <a href="http://en.wikipedia.org/wiki/Voltmeter">voltmeter</a>. These tests showed that the CPU was behaving correctly, but that the <a href="http://en.wikipedia.org/wiki/Bus_%28computing%29">data bus</a> held the wrong value. Further testing showed that while the CPU was driving the address bus correctly, the ROM was seeing the wrong values on its address lines.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGBYLNhSH5w6rak5XJmqaUyeHpnxgBkg1YI7Mqy8OODXKN_jge4CoFO1hOFLiVfRKW7revzA9vYrfZlAIwEsWsYeUrb_9htucpg7hsH2QBD0m-OIwwb7JI_VhykRwEQ8rdPpaWsR0uEbc/s1600/20140123_141351.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGBYLNhSH5w6rak5XJmqaUyeHpnxgBkg1YI7Mqy8OODXKN_jge4CoFO1hOFLiVfRKW7revzA9vYrfZlAIwEsWsYeUrb_9htucpg7hsH2QBD0m-OIwwb7JI_VhykRwEQ8rdPpaWsR0uEbc/s1600/20140123_141351.jpg" height="320" width="240" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Ancient Anti-Static Foam</td></tr>
</tbody></table>
<span style="font-family: Courier New, Courier, monospace; font-size: large;"><b>Baked-On Gunk</b></span><br />
<br />
More checking continued to show the proper connections on the <a href="http://en.wikipedia.org/wiki/Printed_circuit_board">board</a> between the CPU socket and the ROM socket. Digging deeper revealed that the disconnect was between the CPU socket and the pins on the CPU itself! This is a new (or <a href="http://en.wikipedia.org/wiki/New_old_stock">NOS</a>) socket, and it shows no sign of being worn-out. So, what was happening?<br />
<br />
The CPU is one of the chips that were original parts included in the box of the Micro Chroma 68 kit. The chips were inserted into a block of <a href="http://en.wikipedia.org/wiki/Antistatic_bag">anti-static foam</a> which served to contain the chips and to protect their pins from damage, and there they sat for roughly 35 years. When I removed the chips from this foam, I noticed that some bits of the foam stuck to the pins of the chips. I scraped the visible bits of foam away and gave it no more thought until I witnessed the results of the testing described above.<br />
<br />
I acquired some <a href="http://www.radioshack.com/product/index.jsp?productId=2102649">parts cleaner</a> from a local electronics retailer and used it to clean the pins of the chips that were included with the Micro Chroma 68 kit. After this cleaning and closer visual inspection, I was satisfied that the chips were clean and serviceable. I re-installed the chips and repeated the tests described above. Some of the pins now properly reflected the state of the address bus, but to my chagrin some of them were still incorrect.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh91aZnlxmGqOzGdI-IZANZ0y_AuEIgB6sh-l6kRuU2n9b2CBjeTA0rJSlE9JGcsq2RPSczLZcJfsfKwRHnVKIyEcU-A7eFxPf9ZkE9M_s5W0OFgsIL2YK1A3f1Z5tzX0fyl2a9bm_xLQ0/s1600/20140123_141824.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh91aZnlxmGqOzGdI-IZANZ0y_AuEIgB6sh-l6kRuU2n9b2CBjeTA0rJSlE9JGcsq2RPSczLZcJfsfKwRHnVKIyEcU-A7eFxPf9ZkE9M_s5W0OFgsIL2YK1A3f1Z5tzX0fyl2a9bm_xLQ0/s1600/20140123_141824.jpg" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Strangest Electronics Tool Ever</td></tr>
</tbody></table>
<span style="font-family: Courier New, Courier, monospace; font-size: large;"><b>File It Away</b></span><br />
<br />
After some thought, I decided on a more aggressive strategy for cleaning the pins of the chips in question. Using some small hobby files, I filed the pins until they were slightly shiny. I then hit them again with the parts cleaner, just to remove any remaining filings. I re-installed the chips onto the board, and another round of testing showed correct values for the address and data lines at both the ROM and the CPU. Then I removed the test hacks to the reset line and the ROM address decoding, and I powered-up the board. The picture at the top of this entry shows the result -- the TVBug sign-on message and an apparently working Micro Chroma 68 board!<br />
<br />
So, where does that leave things? I still need a keyboard solution to allow for input -- more on that in the next post, most likely. I'm also still missing a couple of <a href="http://en.wikipedia.org/wiki/Capacitor">capacitor</a> values related to the <a href="http://en.wikipedia.org/wiki/Kansas_City_standard">audio cassette interface</a> for storing programs -- hopefully they will arrive soon! Finally, it would be nice to see at least one program running on the board by the end of the month. I'm not sure if I can solve all of these issues between now and then, but I might be able to keep things interesting in the meantime. I hope you will stay tuned!John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com1tag:blogger.com,1999:blog-2445192656245527812.post-85188093730350304162014-01-19T14:50:00.002-08:002014-01-19T15:30:19.439-08:00A Few Things AmissThis weekend brought me a bit more time for working on my <a href="http://www.68bits.com/micro-chroma-68.html">Micro Chroma 68</a> build. A few more parts have arrived, and I found an alternative for an important one that was still missing. The board is showing some signs of life, but perhaps just barely so...<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEikLlaoO0lseJGJyi_wpspkVtbowr20t6x396Hfvk7u1rge0ZpahDF6Xm6UJfE-WOfOWCEccoBBhsDiomx_wgKBAxEL6CJ9qeAM0HRSaehUUKXpmvmX_KYNISk4ZPqX5TrJWQlAos9o1Gg/s1600/20140118_194828.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEikLlaoO0lseJGJyi_wpspkVtbowr20t6x396Hfvk7u1rge0ZpahDF6Xm6UJfE-WOfOWCEccoBBhsDiomx_wgKBAxEL6CJ9qeAM0HRSaehUUKXpmvmX_KYNISk4ZPqX5TrJWQlAos9o1Gg/s1600/20140118_194828.jpg" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Garbled Output on the Micro Chroma 68</td></tr>
</tbody></table>
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Substitution</span></span></b><br />
<br />
I had collected most of the parts required for this build over time, and I ordered the remaining parts during the first week of January. Unfortunately, there are still parts that have not arrived. I received two of the missing <a href="http://en.wikipedia.org/wiki/Capacitor">capacitor</a> values this week, but I am still missing three more. Two of the missing capacitors are only used in the <a href="http://en.wikipedia.org/wiki/Kansas_City_standard">audio cassette storage interface</a>, so they aren't required for <a href="http://blog.asset-intertech.com/test_data_out/2012/03/what-is-board-bring-up.html">board bring-up</a>. Unfortunately, the missing parts also include one of the capacitors in the <a href="http://en.wikipedia.org/wiki/Crystal_oscillator">clock circuit</a>. So, the board has not been testable until recently.<br />
<br />
The missing clock circuit part is a 50 pF capacitor. While poking around in my parts stash, I found a bag of 47 pF capacitors. The Micro Chroma 68 kit instructions specifically mention the use of a 47 pF capacitor as a substitute for that part. Since that capacitor is mated with a variable capacitor on the other end of the crystal, the clock can still be tuned to the proper frequency. I installed the capacitor, tuned the clock using the <a href="http://en.wikipedia.org/wiki/Frequency_counter">frequency counter</a> feature of my <a href="http://en.wikipedia.org/wiki/Oscilloscope">oscilloscope</a>, and moved onto getting a video display!<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0KMSqHLkqjExDijt6NnuHlOH_E_c35TLweCsEELMUgJgQNr6x0GoZbU8VamZAiauqInDj9eZZxEffgrnZf6igZM10M1s2rAStElWMwOrrvEzD7if1hB9YcPDRBuGV0YOJNLttXKVGfB4/s1600/20140119_172649.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0KMSqHLkqjExDijt6NnuHlOH_E_c35TLweCsEELMUgJgQNr6x0GoZbU8VamZAiauqInDj9eZZxEffgrnZf6igZM10M1s2rAStElWMwOrrvEzD7if1hB9YcPDRBuGV0YOJNLttXKVGfB4/s1600/20140119_172649.jpg" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Perfboard MC1372 Circuit</td></tr>
</tbody></table>
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Reinvention</span></span></b><br />
<br />
The Micro Chroma 68 board is designed to provide an <a href="http://en.wikipedia.org/wiki/RF_modulator">RF signal</a> for feeding a TV through its antenna connection. As I mentioned in an earlier post, I attempted to hack the circuit to disable the RF signal generation and to just output a <a href="http://en.wikipedia.org/wiki/Composite_video">composite video</a> signal. Alas, I don't seem to have understood the <a href="http://console5.com/wiki/MC1372">MC1372</a> datasheet as the device was not generating any video output at all.<br />
<br />
I went back to the drawing board and built a new MC1372 circuit based on a schematic in the <a href="http://en.wikipedia.org/wiki/Motorola_6847">MC6847</a> datasheet. The new circuit was similar to the hack I had attempted, but different in a few details. I built it on a piece of <a href="http://en.wikipedia.org/wiki/Perfboard">perfboard</a>, and used some wires to plug it into the MC1372 socket on the Micro Chroma 68 motherboard. Thankfully, this circuit worked to provide the video output in the picture at the top of this entry.<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Deduction</span></span></b><br />
<br />
Of course, it doesn't take a lot of expertise to deduce that the screen output pictured above isn't exactly what the board should be producing. I would have expected to see a sign-on message from the Micro Chroma 68's built-in <a href="http://en.wikipedia.org/wiki/Resident_monitor">monitor software</a>, TVBug. The garbled mess on the screen certainly suggests that something is wrong.<br />
<br />
Letting the board sit there and run sometimes results in some screen characters getting changed, and fiddling with the <a href="http://en.wikipedia.org/wiki/Reset_button">reset button</a> or the break key has some effects that offer tantalizing clues that at least something is working on the board. Removing the <a href="http://en.wikipedia.org/wiki/Video_memory">video memory</a> results in a more uniform pattern on the screen, suggesting that the 6847 is able to read the video memory. So, there are some signs of life on the board even if the current state is far from perfect.<br />
<br />
It isn't clear to me what the problems are with my Micro Chroma 68, but these clues suggest that the fix could be as simple as replacing a bad chip or fixing a short-circuit or a <a href="http://en.wikipedia.org/wiki/Soldering">cold solder joint</a>. Finding the answers will require a combination of <a href="http://en.wikipedia.org/wiki/Deductive_reasoning">deductive reasoning</a> based on observations and methodical inspection and testing of the board itself. There is no telling how long that might take, but please do stay tuned! :-)<br />
<br />John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com7tag:blogger.com,1999:blog-2445192656245527812.post-39189505091254454772014-01-12T08:47:00.001-08:002014-01-12T08:48:27.474-08:00Rapid Advance<div>
The <a href="http://www.68bits.com/micro-chroma-68.html">Micro Chroma 68</a> build is making good progress! My schedule aligned on Saturday such that I had several hours which I could fill with the smell of melted metal. So far the only casualties are a spool of <a href="http://en.wikipedia.org/wiki/Solder">solder</a> and the worn-out tip of my soldering iron... :-)</div>
<div>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEik4lPImHhEfuhU1NnLZAa2brevzF0G9Sise8gvLtbr7ECGxCq3KFAT6Eo04bVc8eH0MKF6hBdFgo7H-JhyphenhyphenbQgJ0-ote7af-StaI2h5hteQifcAfVGOdRZNduUbM7xuEvrLbsJfVPJDWEo/s1600/20140111_223824.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEik4lPImHhEfuhU1NnLZAa2brevzF0G9Sise8gvLtbr7ECGxCq3KFAT6Eo04bVc8eH0MKF6hBdFgo7H-JhyphenhyphenbQgJ0-ote7af-StaI2h5hteQifcAfVGOdRZNduUbM7xuEvrLbsJfVPJDWEo/s1600/20140111_223824.jpg" height="320" width="240" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Progress on Micro Chroma 68 Construction</td></tr>
</tbody></table>
<br /></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: large;"><b>Progress Report</b></span></div>
<div>
<br /></div>
<div>
With most of the required parts in hand, it was easy to make progress on construction. In particular, I had been waiting on the various <a href="http://en.wikipedia.org/wiki/Integrated_circuit">IC</a> sockets to arrive. It is standard practice when assembling a <a href="http://en.wikipedia.org/wiki/Printed_circuit_board">PCB</a> to install the sockets first. Sockets have lots of pins, and it is easiest to get them installed properly when there is nothing else on the board to prevent them from laying flat while being soldered. Other parts that lay flat (like resistors and diodes) are typically next in line, followed by capacitors and special items like crystals, connectors, and switches.</div>
<div>
<br /></div>
<div>
I now have the IC sockets, resistors, diodes, and capacitors installed in the Micro Chroma 68 board, with exceptions for the <a href="http://en.wikipedia.org/wiki/LC_circuit">RF tank circuit</a> (discussed below) and the handful of parts which I still don't have. This includes a handful of oddly valued capacitors, and one socket that I overlooked when ordering the rest. It should be simple to install those parts as they get here. As long as they arrive on time, those parts should pose no barrier to completing construction.</div>
<div>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgiLXf_KXABVl9YEkgcnVDVlDV66kfE9brBT-KgYUmbaeDcyPgeMdTA95msUxJB0KTe7-UuzU6uUAf7jurupvnNCZej6TNeX3cBBklLScJ8kJ4ntn0NXNKyq4OzX35UBtbx1lJUen4gmbI/s1600/20140112_113705.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgiLXf_KXABVl9YEkgcnVDVlDV66kfE9brBT-KgYUmbaeDcyPgeMdTA95msUxJB0KTe7-UuzU6uUAf7jurupvnNCZej6TNeX3cBBklLScJ8kJ4ntn0NXNKyq4OzX35UBtbx1lJUen4gmbI/s1600/20140112_113705.jpg" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Imperfect Fit for C5 and R2</td><td class="tr-caption" style="text-align: center;"><br /></td></tr>
</tbody></table>
<br />
<br /></div>
<div>
<a href="http://en.wikipedia.org/wiki/Square_peg_in_a_round_hole"><span style="font-family: Courier New, Courier, monospace; font-size: large;"><b>Square Pegs</b></span></a></div>
<div>
<br /></div>
<div>
I have been pleased at the availability of some of the less common parts required for the build. Between surplus electronics providers and various auction sellers, I have been able to locate usable options for every required part so far. Unfortunately, it can be difficult to find the exactly correct footprint for every part. In particular, I had to do some creative bending of the leads on both the <a href="http://en.wikipedia.org/wiki/Potentiometer">potentiometers</a> and the adjustable capacitor in order to fit the holes on the PCB. This isn't uncommon or unexpected -- I'm just glad that the pins were long enough to reach! Of course, doing this probably <a href="http://www.urbandictionary.com/define.php?term=the%20vapors">gives the vapors</a> to all of those <a href="http://www.applefritter.com/content/im-going-build-apple-1-replica">"period correct" Apple I replica </a>kit builders... ;-)</div>
<div>
<br /></div>
<div>
<span style="font-family: Courier New, Courier, monospace; font-size: large;"><b>Engineering Opportunity</b></span></div>
<div>
<br /></div>
<div>
One part that I made no attempt to find is the variable <a href="http://en.wikipedia.org/wiki/Inductor">inductor</a> that forms part of the tank circuit for the <a href="http://en.wikipedia.org/wiki/RF_modulator">RF modulator</a>. This part is unnecessary because I don't intend to have RF output for the video. Such a circuit was useful back in the days when the only way to use an unmodified TV as a monitor was by building a tiny TV transmitter into your device. But nowadays simple <a href="http://en.wikipedia.org/wiki/Composite_video">composite video</a> is a widely available option, and it will generally provide a much higher quality display as well.</div>
<div>
<br /></div>
<div>
Fortunately, the <a href="http://en.wikipedia.org/wiki/Motorola">Motorola</a> <a href="http://www.datasheetarchive.com/dlmain/Datasheets-16/DSA-317085.pdf">MC1372</a> part used in the RF modulator circuit can be configured to produce just the composite video without the RF modulation. As detailed in the datasheet for that part, this mostly requires replacement of the RF tank circuit with a single diode. The <a href="http://en.wikipedia.org/wiki/The_Devil_is_in_the_detail">devil is in the details</a>, of course. But I intend to work-out those details and find a way to hack the PCB in order to produce composite video instead of the RF output.</div>
<div>
<br /></div>
<div>
Other than the video output hack, the board is almost ready for some limited testing. Unfortunately, one of the missing capacitors is part of the <a href="http://en.wikipedia.org/wiki/Clock_signal">clock circuit</a>. So while I can do some limited testing for <a href="http://en.wikipedia.org/wiki/Short_circuit">shorts/opens</a> and the like, I can't do much to test the functioning of the <a href="http://en.wikipedia.org/wiki/Motorola_6800">CPU</a> or <a href="http://en.wikipedia.org/wiki/Motorola_6847">VDG</a> or anything else in the system that needs the clock to function. The waiting game continues, so like me you will just have to stay tuned...</div>
John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com0tag:blogger.com,1999:blog-2445192656245527812.post-72924198085735167232014-01-10T13:56:00.000-08:002014-01-10T13:57:56.555-08:00All Keyed UpUnfortunately, my Retrochallenge project continues to progress at a turtle-like pace. I have still been waiting for parts, and tending to some of life's other demands. In the meantime, I have managed to poke around my project at its edges...<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiOIVjeQoyoXDZTAtA94wfzlnJ3_irKPBp8Fw8vNf9DEgVULXMqfIWsitRsGK4fwG4jSKY78hTdNT8y320qHMxj1_fZFdSIitgi5cqujM47YXT06lN4zHLfoq3Q8hni0KU30wsJmjot5kA/s1600/20140110_145915.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiOIVjeQoyoXDZTAtA94wfzlnJ3_irKPBp8Fw8vNf9DEgVULXMqfIWsitRsGK4fwG4jSKY78hTdNT8y320qHMxj1_fZFdSIitgi5cqujM47YXT06lN4zHLfoq3Q8hni0KU30wsJmjot5kA/s1600/20140110_145915.jpg" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Radio Shack ASCII-Encoded Keyboard</td><td class="tr-caption" style="text-align: center;"><br /></td></tr>
</tbody></table>
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Keyboard Crisis</span></span></b><br />
<br />
The <a href="http://www.68bits.com/micro-chroma-68.html">Micro Chroma 68</a> board is designed to take input through a parallel interface to an <a href="http://en.wikipedia.org/wiki/ASCII">ASCII</a>-encoded keyboard. This sort of arrangement appears to have been common in the days of <a href="http://en.wikipedia.org/wiki/TV_Typewriter">TV typewriters</a> and the <a href="http://en.wikipedia.org/wiki/Apple_I">Apple I</a>. Someone even <a href="http://www.ballyalley.com/pics/hardware_pics/ASCII_Keyboard/ASCII_Keyboard.html">interfaced</a> one to the <a href="http://en.wikipedia.org/wiki/Bally_Astrocade">Bally Astrocade</a>! Nevertheless, today it seems to be quite difficult to find such hardware...<br />
<br />
Fortunately, a couple of years back I managed to find the keyboard pictured above for sale on a popular online auction site. FWIW, the keyboard and the <a href="http://en.wikipedia.org/wiki/Printed_circuit_board">PCB</a> were sold separately in the <a href="http://www.radioshackcatalogs.com/html/1977/h094.html">1977</a> and <a href="http://www.radioshackcatalogs.com/html/1978/h099.html">1978</a> editions of the Radio Shack <a href="http://www.radioshackcatalogs.com/">catalog</a>. The <a href="http://bytecollector.com/archive/digital_group/documentation/hardware/dg_systems/rs_keyboard.pdf">manual</a> for the encoder PCB is available online for the curious among us.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgVcbKDxyKhDExBCDJd2NvoXMAtYCUUvZSfnM1ii-k5_KBnyHNJSpwHhcntYDAYCKtOcNgiS5Pmb3PyU3-LS73WGb4VSnDfAH4hyphenhyphenzyomz4IJ7-lNBL1QKUw6PWO_XFjN0wjqyTKjk2F-jw/s1600/20140108_192812.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgVcbKDxyKhDExBCDJd2NvoXMAtYCUUvZSfnM1ii-k5_KBnyHNJSpwHhcntYDAYCKtOcNgiS5Pmb3PyU3-LS73WGb4VSnDfAH4hyphenhyphenzyomz4IJ7-lNBL1QKUw6PWO_XFjN0wjqyTKjk2F-jw/s1600/20140108_192812.jpg" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Heep Test Module</td><td class="tr-caption" style="text-align: center;"><br /></td></tr>
</tbody></table>
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Heep Test Module</span></span></b><br />
<br />
I thought it would be wise to test out the keyboard, given its age and unknown condition. Fortunately, the manual provides a diagram for the oddly named "Heep Test Module". I was able to construct the fixture in an hour or so from a handful of scrounged <a href="http://en.wikipedia.org/wiki/Light-emitting_diode">LED</a>s and resistors, some wire, and a newly acquired <a href="http://en.wikipedia.org/wiki/Edge_connector">edge connector</a>.<br />
<br />
As an aside, I thought the "Heep Test Module" name sounded a bit odd. Coincidentally, I was reading the newly released <a href="http://www.crcpress.com/product/isbn/9781466592476">CoCo book</a> when I noticed mention of a <a href="http://en.wikipedia.org/wiki/Tandy_Corporation">Tandy</a> engineer by the name of <a href="http://www.youtube.com/watch?v=VNF_TCI7vT8">Jerry Heep</a>. I guess that "Heep Test Module" is like a printed electronics manual version of an <a href="http://en.wikipedia.org/wiki/Easter_egg_%28media%29">Easter Egg</a>!<br />
<br />
Anyway, I'm glad I took the time to build this fixture. Applying power to the keyboard lights-up the fixture in strange ways, revealing that the keyboard is not currently functioning as it should -- one more thing to fix... Alternatively, I may have to <a href="http://www.willegal.net/appleii/appleii-kb-int.htm">buy</a> or <a href="http://www.interak.pwp.blueyonder.co.uk/PCtoASCII.htm">build</a> some sort of replacement.<br />
<a href="http://www.youtube.com/watch?v=OTzLVIc-O5E"><br /></a>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzdOJWxSXXLgiMAU5IZ7rKWJb70pXF_tjJN_sVRblmRumJkDWAQwISKogTDr55Hg6q-8xDKfo9nBKcvDBhMMyP8fVMZJ7qp41a2MAKDNb3PM1tya4_KQ9TrO-rZwERigrIW9_k69kvi9I/s1600/20140110_155340.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzdOJWxSXXLgiMAU5IZ7rKWJb70pXF_tjJN_sVRblmRumJkDWAQwISKogTDr55Hg6q-8xDKfo9nBKcvDBhMMyP8fVMZJ7qp41a2MAKDNb3PM1tya4_KQ9TrO-rZwERigrIW9_k69kvi9I/s1600/20140110_155340.jpg" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Bags Of Parts</td></tr>
</tbody></table>
<a href="http://www.youtube.com/watch?v=OTzLVIc-O5E"><br /></a>
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;"><a href="http://www.youtube.com/watch?v=OTzLVIc-O5E">Parts Is Parts</a></span></span></b><br />
<br />
Aside from the keyboard situation, I am running out of excuses on the construction project. While I still don't have all the parts I need to complete the box, delivery trucks have been rolling and I've got the bulk of the missing ingredients. I had been missing some key parts, like <a href="http://en.wikipedia.org/wiki/Integrated_circuit">IC</a> sockets and some particularly valued resistors and capacitors. A few of those are still outstanding, but most of the stuff is here already.<br />
<br />
Hopefully the next post will at least have some parts stuck to the board! Until then, of course, you'll have to stay tuned... :-)John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com0tag:blogger.com,1999:blog-2445192656245527812.post-82820037137801200142014-01-05T18:27:00.001-08:002014-01-05T18:30:30.105-08:00Building the Micro Chroma 68 KitThe <a href="http://www.retrochallenge.net/">Retrochallenge Winter Warmup 2014</a> event started days ago, and I have yet to blog about my entry! I guess I need to get going on that... :-)<br />
<br />
For some time, I've been in possession of a mostly complete <a href="http://www.68bits.com/micro-chroma-68.html">Micro Chroma 68</a> kit that I acquired from someone in the <a href="http://en.wikipedia.org/wiki/TRS-80_Color_Computer">Tandy Color Computer</a> (CoCo) community. Over time I've acquired most of the parts required to build the kit, and I've been on a bit of a roll lately with electronics construction projects. So, I guess this is as good a time as any to work on this build!<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhEjpMwTiNRLr5T3auE3mFmo4P-46G1O1EJMUPPN6kq0FDReSBfGsBgLCsmXqpSIvpeI9j1-p8JJ5AGEZsHc8I7E7ILlD0H2yL2r9Z29GbMWf9Wp3jmDo01JE6W976iYBako20EUN9S8VE/s1600/20140102_163129.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhEjpMwTiNRLr5T3auE3mFmo4P-46G1O1EJMUPPN6kq0FDReSBfGsBgLCsmXqpSIvpeI9j1-p8JJ5AGEZsHc8I7E7ILlD0H2yL2r9Z29GbMWf9Wp3jmDo01JE6W976iYBako20EUN9S8VE/s1600/20140102_163129.jpg" height="240" width="320" /></a></div>
<br />
<span style="font-family: Courier New, Courier, monospace; font-size: large;"><b>What Is It?</b></span><br />
<br />
The Micro Chroma 68 is a <a href="http://en.wikipedia.org/wiki/Single-board_computer">single board computer</a> (SBC) based on a derivative of the <a href="http://en.wikipedia.org/wiki/Motorola_6800">Motorola 6800</a> processor. It was produced as a platform for demonstrating the <a href="http://en.wikipedia.org/wiki/Motorola_6847">Motorola 6847</a> video display generator (VDG). Along with the <u>amazing</u> graphics capabilities of the VDG, the Micro Chroma 68 features an interface for loading and storing information stored on audio cassettes, and a keyboard interface for interacting with the device as a <a href="http://en.wikipedia.org/wiki/Computer_terminal">video terminal</a>. The device also features an EXORcisor bus connector for interfacing to other devices.<br />
<br />
I have seen it suggested that this device provided some inspiration to the designers at Tandy that ultimately produced my beloved CoCo. Whether that is true or not, it seems likely that those designers would at least have been aware of this device. While the Micro Chroma 68 is clearly designed for engineers and experimenters, it does show the first few steps toward producing a standalone computer consumable by normal folk.<br />
<br />
The Micro Chroma 68 also seems comparable to the venerated <a href="http://en.wikipedia.org/wiki/Apple_I">Apple I</a> design. They certainly have similar features and capabilities. Given the high cost of building even a replica Apple I kit, this is probably the closest I'll ever come to that experience!<br />
<br />
<span style="font-family: Courier New, Courier, monospace; font-size: large;"><b>Shop 'Til You Drop</b></span><br />
<br />
The Micro Chroma 68 kit comes with a <a href="http://en.wikipedia.org/wiki/Printed_circuit_board">printed circuit board</a> (PCB), and a handful of key <a href="http://en.wikipedia.org/wiki/Integrated_circuit">integrated circuits</a> (ICs). However, it is far from a complete kit and not all of the other parts are still commonly available. I had made a point of acquiring most of the remaining ICs already, but some of the other parts are equally hard to find. Luckily, some strategic eBay shopping and a check of a trusty electronics surplus provider (<a href="http://www.unicornelectronics.com/">Unicorn Electronics</a>) seems to have located all of the required parts.<br />
<br />
Unfortunately, I didn't do this shopping until New Year's Day. Some of the items are coming from distant suppliers, and I may not have everything in hand until the third week of January or later! Hopefully I can make enough progress with what I already have and anything that comes early so as to still have a chance to complete the build....<br />
<br />
<span style="font-family: Courier New, Courier, monospace; font-size: large;"><b>Other Pursuits</b></span><br />
<br />
I had some time-off around the turn of the new year, and I used it to work on a variety of retro-ish hardware projects. I fixed old game consoles (even a <a href="http://en.wikipedia.org/wiki/Vectrex">Vectrex</a>!), made cables, built circuits, and even made a project enclosure out of an old cigar box! Anyway, I've got a lot of distractions available to keep me busy even if the Micro Chroma 68 parts get delayed. If that happens, then I'll try to at least post a link or two here as well. In any case, be sure to stay tuned... :-)John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com0tag:blogger.com,1999:blog-2445192656245527812.post-89601552646352418682013-03-29T15:43:00.003-07:002013-03-29T15:43:45.686-07:00BASIC-ly Done<br />Only another month until <a href="http://www.glensideccc.com/cocofest/">CoCoFEST!</a> It sounds like this will be an extra good one...see you there? It will be a great chance for you to play Sluzzle... :-)<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Lock 'N Load</span></span></b><br />
<br />
When last we left Sluzzle, we were sorely in need of a loader to coordinate loading both the game binary itself and the pictures that are the object of the game. All of that could be added to the Sluzzle binary itself, but the built-in <a href="http://en.wikipedia.org/wiki/Color_BASIC">Disk Extended Color BASIC</a> was just itching to help out!<br />
<br />
Just like a shell script wrapper around a finicky Unix binary, DECB provides a number of facilities that make it attractive for writing a loader program. While the built-in options for flow control, text processing, and (especially) disk access are not necessarily great performers, they are relatively easy to use. Plus, using them avoids dedicating time to developing such code.<br />
<br />
The DECB loader for Sluzzle performs reasonably well and was easy to implement. The BASIC console and disk I/O routines were much easier to use and adapt than writing the assembly language equivalents would have been to do. Dealing with line numbers still sucks, but some minimal planning and allocation of line number ranges to specific parts of the program makes things manageable. The <a href="http://sourceforge.net/projects/toolshed/">Toolshed</a> utilities also helped by letting me edit the BASIC sources on a modern PC rather than on the CoCo's keyboard.<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Take Control</span></span></b><br />
<br />
I added a new feature to Sluzzle -- a help screen! That might be helpful for people new to Sluzzle that aren't sure what controls to use. The help screen is implemented by switching the video mode and the screen address back to the text screen used by BASIC, which will show whatever was left on the screen just before starting Sluzzle. The loader was extended to write the control guide data before executing the Sluzzle binary. Typing '?' while Sluzzle is active will reveal the help screen -- too bad I didn't include that in the video... :-(<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.youtube.com/embed/PP7Y9nGx358?feature=player_embedded' frameborder='0'></iframe></div>
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">PLAY Along</span></span></b><br />
<br />
One final touch that is barely discernible in the video is the addition of a few music queues. Starting, winning, and losing the game are all punctuated with some appropriate musical notes. These are implemented using the PLAY command, which Color BASIC has in common with <a href="http://en.wikipedia.org/wiki/GW-BASIC">GW-BASIC</a> (also from Microsoft). The PLAY command processes a type of <a href="http://en.wikipedia.org/wiki/Music_macro_language">music macro language </a>that is also similar to the <a href="http://en.wikipedia.org/wiki/Ring_Tone_Transfer_Language">Ring Tone Text Transfer Language</a> once used on Nokia phones. This is another way in which using the built-in BASIC is a lot more efficient with programmer time than writing that feature from scratch would be.<br />
<br />
With Sluzzle complete, I have released a <a href="http://git.infradead.org/users/linville/sluzzle.git">git tree</a> with the Sluzzle source. I have also released some <a href="http://www.tuxdriver.com/download/sluzzle/">downloadable binaries</a> for those that aren't interested in DIY. I hope you enjoy it as much as I do.<br />
<br />
I don't know what will come next here. I may want to branch out to some other machines that use the 6847? Or maybe there will be some new ways to exploit the VDG on the CoCo? It is hard to tell...but as always, stay tuned!John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com4tag:blogger.com,1999:blog-2445192656245527812.post-87004131681519428392013-03-23T19:09:00.000-07:002013-03-23T19:10:20.426-07:00Scramble, Unscramble, and WinI'm still working hard to get Sluzzle ready for the <a href="http://cococoding.com/contest/">CoCo Coding Contest</a> review. I may have to throw-out a few features, but it will still be fun to play. I keep spending a little too much time "testing" to make sure it is still working -- it must be fun! :-)<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Shuffle Like You Mean It</span></span></b><br />
<br />
The whole point of a sliding puzzle game is to move the tiles back into their correct order. That wouldn't be much fun if they weren't scrambled-up in the first place! So with the basic mechanic of moving the tiles already working, the next order of business was to figure-out how to shuffle the tiles for a new game.<br />
<br />
The shuffling routine needed a source of (pseudo-)random numbers. The old <a href="http://en.wikipedia.org/wiki/Linear_feedback_shift_register">LFSR</a> workhorse rode to the rescue on this one. In <a href="http://fahrfall.blogspot.com/">Fahrfall</a> I used a 16-bit LFSR, but this time I am using an 8-bit one. The 255 value wrap range seemed sufficiently larger than the 4 directional choices used for moving puzzle pieces -- no point in shifting 16 bits when 8 bits can do the job.<br />
<br />
I was disappointed with my original shuffling algorithm. It basically just got the next LFSR value, masked off unneeded bits, and then moved in that direction. The problem was that this didn't seem to shuffle the board very much without really large numbers of moves. All those extra moves introduced noticeable startup delay while shuffling the board. I added code to the shuffling routine that refuses to make a move that undoes the previous move. This allowed for satisfactory shuffles in just a few dozen moves!<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Give Me A Hint</span></span></b><br />
<br />
Since some pictures may be less familiar than others (and since people have faulty memories), I thought that it would be nice to provide a way to see the unscrambled picture without having to quit (or solve) a game. I implemented the unscramble as a <a href="http://en.wikipedia.org/wiki/Selection_sort">selection sort</a>, using the blank square as a scratch space for swapping blocks. This resolved the unscramble issue without any major issue.<br />
<br />
The re-scrambling of the blocks seems like it should have been easy as well, since it is essentially just another sort using the block order saved from before the unscramble. For some reason, it took me at least twice as long to implement the rescramble as it took to implement the unscramble. I think that I was confusing myself between the numbered tags I used for tracking the block locations and the numbers I used for identifying the locations themselves. Anyway, it goes to show you that even someone familiar with assembly language and coding in general can get stymied once in a while -- or, maybe I'm just getting old! At least my CoCo is eternally youthful... <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.youtube.com/embed/P9aHvdkevSE?feature=player_embedded' frameborder='0'></iframe></div>
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Is It Over?</span></span></b><br />
<br />
There is little point in playing a game on a computer unless the computer can tell you when the game is over. Implementing this was fairly easy. As I hinted above, I maintain a map of which block is currently in each location. After every move, I walk the map to check if the number of each block matches the number for the position it is in. If they all match, the picture is unscrambled and the game is over -- you win! But really, playing is its own reward...<br />
<br />
So, the basic game mechanics are in place. The next major step I see is to implement a <a href="http://en.wikipedia.org/wiki/Color_BASIC">Color BASIC</a> loader that lets you select which image you want to unscramble and then loads the image and the actual game binary. After that, maybe there will be a little more time for a few more embellishments.<br />
<br />
Wanna see it? Then stay tuned...John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com0tag:blogger.com,1999:blog-2445192656245527812.post-34680505270684635822013-03-18T18:46:00.000-07:002013-03-18T18:46:01.108-07:00Introducing SluzzleBack in early February, I <a href="http://vdgtricks.blogspot.com/2013/02/back-at-it.html">mentioned</a> that I would be using some of the work documented in this blog as the basis for a "sliding puzzle" game. Time marches on, so I had better get moving if I am going to have a game ready in time for the review!<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;"><br /></span></span></b>
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;"><a href="http://cococoding.com/contest/">CoCo Coding Contest</a></span></span></b><br />
<br />
The contest is sponsored by Aaron Wolfe, under the auspices of his <a href="https://sites.google.com/a/aaronwolfe.com/cococoding/home">CoCoCoding</a> web site. It seems like a great way to generate some extra excitement in the CoCo community, and to promote the Chicago-area <a href="http://www.glensideccc.com/cocofest/">CoCoFEST!</a> It looks like there are a number of competing projects, and hopefully Aaron has some people lined-up to help with the judging...? The reviews are supposed to start in just 10 days...yikes!<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;"><a href="http://en.wikipedia.org/wiki/Self-modifying_code">Self-Modifying Code</a></span></span></b><br />
<br />
The 44-color graphics mode described previously in this blog is built upon the 8-color graphics mode described here before that. These modes depend on precisely timed changes to the CSS input to the <a href="http://en.wikipedia.org/wiki/Motorola_6847">VDG</a>. Cycles are so tight that every line on the screen needs its own corresponding set of instructions in the code. There is not even any time for conditional branching!<br />
<br />
The code in the <a href="http://git.infradead.org/users/linville/vdgtricks.git">vdgtricks.git</a> repository handles this by generating custom assembly language programs for each image. The image conversion tool not only converts the image data to an appropriate format for the CoCo, but it also generates the matching code for setting the CSS bit on the VDG at the appropriate times while the image is drawn on the screen. That works great, but it isn't very flexible. Since I wanted to support selectable images for Sluzzle, there needed to be another option.<br />
<br />
The code for each line of an image is comprised of the same basic set of operations, except that STA and STB instructions are used for clearing or setting the CSS bit for each segment of a given line. The first STA or STB instruction in each line is the same distance in memory from the first STA or STB instruction of the next line, and each STA or STB instruction within a line is a fixed distance from the first one for that line. This knowledge allows for writing a program that can rewrite itself as appropriate for a given image.<br />
<br />
I modified the image conversion tool so that instead of generating custom code for each image, a data structure is generated that represents the proper CSS setting for each segment of every line. This data is appended to the image data, and the viewer program interprets it as the program initializes itself. As the data is interpreted, the proper sequence of STA and STB instructions is inserted into the display portion of the code to match the image data.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.youtube.com/embed/-Hs98SuBvMo?feature=player_embedded' frameborder='0'></iframe></div>
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Prototype</span></span></b><br />
<br />
Sluzzle is a "sliding puzzle" or "<a href="http://en.wikipedia.org/wiki/15_puzzle">15 puzzle</a>" style of game. Such a game involves dividing an image into a number of blocks (including one empty block), and moving the blocks around to put them into the correct order. I wrote some code that could blank a block on screen and more code that could copy the contents of one block to another, including both the graphics data and the corresponding code instructions. This code is working now, but the game is far from complete.<br />
<br />
Over the next several days I expect to add code to scramble images for a new game, and to unscramble the images temporarily to provide a hint to players. I also intend to add the ability to choose from a variety of background images. I hope to add a few more embellishments as well, like some sort of timer or other scorekeeper and maybe a few sound effects. If things really go well then maybe I can add some music? Dunno if that is likely or not... I'm pretty sure there won't be any auto-solver -- just too much code and not enough time!<br />
<br />
Anyway, enough for now... I'll try to milk this for another entry or two between now and then! Of course, to see that you will have to stay tuned... :-)John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com5tag:blogger.com,1999:blog-2445192656245527812.post-83811984482431215842013-03-03T14:31:00.001-08:002013-03-03T14:31:53.763-08:00Curiouser and CuriouserI found a <a href="http://en.wikipedia.org/wiki/PAL">PAL</a> <a href="http://en.wikipedia.org/wiki/TRS-80_Color_Computer">CoCo</a> owner, Simon Jonassen, that took an interest in seeing my 44-color picture viewer running live on his machine. Contrary to earlier reports of PAL <a href="http://en.wikipedia.org/wiki/Dragon_32/64">Dragon 64</a> machines happily running the same code as my <a href="http://en.wikipedia.org/wiki/NTSC">NTSC</a> CoCo, his PAL CoCo was not so happy...<br />
<br />
<a href="http://www.youtube.com/watch?v=VdQY7BusJNU"><b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Time After Time</span></span></b></a><br />
<br />
At first, I wasn't sure what to make of Simon's reported problems. Between the confusion created by the working Dragon 64 machines and the difficulties of working from a picture of a TV set, I wasn't sure what was happening. Fortunately, Simon was able to poke at the code and to determine that adding the extra 50 lines per frame was enough to stabilize the image (as I had initially speculated). Unfortunately, that wasn't enough to make things right either...<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">Expect Delays</span></span></b><br />
<br />
It turns-out that the delay time between the horizontal sync interrupt and the beginning of the next visible line is also different on the PAL CoCo machines. I don't know if that is caused by differences in the PAL video signal, if it is caused by the circuitry added around the <a href="http://en.wikipedia.org/wiki/Motorola_6847">VDG</a> to make it PAL-compatible, or if there is some other reason why this happens. In any case, adjusting the cycle-counted code to account for this difference is sufficient to make things work.<br />
<br />
Note that the Dragon 32 is still an open question. At least <a href="http://www.6809.org.uk/dragon/hardware.shtml">one link</a> suggests that it works similarly to the PAL CoCo. Even if so, it is unclear whether or not the same horizontal timing applies. <br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;"><br /></span></span></b>
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">On One Condition</span></span></b><br />
<br />
Accommodating the PAL timing required some slight refactoring of the code, forcing the CSS value for the beginning of the line to be set after the end of the next line but before the SYNC instruction that waits for the horizontal sync signal. Luckily this works fine for the NTSC code as well, with a few timing-related alterations. I was able to simply add a conditional check to the source code, allowing a simple build option to control whether NTSC- or PAL-compatible code is built. I have pushed this code as an update to the <a href="http://git.infradead.org/users/linville/vdgtricks.git">git repository</a> for this project.<br />
<br />
I have also released updated code binaries for download. The new <a href="http://www.tuxdriver.com/download/vdgtricks/">NTSC-compatible code</a> is available at the same location as before, and the new <a href="http://www.tuxdriver.com/download/vdgtricks/PAL/">PAL-compatible code</a> is available in the PAL subdirectory there as well.<br />
<br />
I am now investigating the acquisition of a PAL CoCo and a Dragon 32. Hopefully that will allow me to answer any remaining timing questions, or any new ones that arise. But between now and then, I really need to get to work on the sliding puzzle game for the <a href="http://cococoding.com/contest/">CoCo Coding Contest</a> -- stay tuned!John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com2tag:blogger.com,1999:blog-2445192656245527812.post-1315470306068792962013-02-13T16:48:00.001-08:002013-02-13T16:48:43.284-08:00More ResultsHey...just a guick update with a couple of links...<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">PALpable Interest</span></span></b><br />
<br />
I found some helpful <a href="http://en.wikipedia.org/wiki/Dragon_32/64">Dragon</a> folks that were interested in this project. One of them ran the code on his <a href="http://en.wikipedia.org/wiki/PAL">PAL</a> Dragon and posted the results on <a href="http://archive.worldofdragon.org/phpBB3/viewtopic.php?t=2695#p6783">this thread</a>. Surprisingly enough, the code seems to more-or-less work "as is".<br />
<br />
I know that the PAL CoCo's and Dragons use the same (NTSC-only) <a href="http://en.wikipedia.org/wiki/Motorola_6847">6847 VDG</a> chip as the NTSC machines. They have added circuitry that basically puts the VDG to sleep while extra lines are added to drive the PAL display. I had presumed that those extra horizontal lines would be visible to the software, but apparently that isn't true.<br />
<br />
I guess the lack of visibility for those extra lines is good news for this project. OTOH, I had thought that the horizontal sync signal could be a good timing source for sound/music playback. Now I would guess that those extra "invisible" lines would break any code using the horizontal sync signal for music playback. So, if I ever want to support PAL machines in some future music-enhanced version of <a href="http://fahrfall.blogspot.com/">Fahrfall</a> then I will have to find another way to make it work...<br />
<br />
<b><span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;"><a href="http://en.wikipedia.org/wiki/Just_Like_Heaven_%28song%29">Show Me, Show Me, Show Me!</a></span></span></b><br />
<br />
I posted a few more examples of pics displayed using the 44-color technique on my CoCo. They are available in an album on my Facebook page. <a href="http://www.facebook.com/media/set/?set=a.4326187712188.2182192.1212010700&type=1&l=13314f06c9">Have a look!</a>John W. Linvillehttp://www.blogger.com/profile/06733985097169878581noreply@blogger.com0