Back in the saddle

Wow, finally a breather so I can get back to programming?  Excellent!

Here's a screenshot of the NetReversi game so far.  It doesn't do anything yet (other than move the cursor), but some of the logic is built-in ready to be used:

Here's a little snippet of the code.  I'm currently using the Notepad++ editor:

Today I'm working on what might be the most difficult piece of this game - determining if a move is legal.

In Reversi, you play on a 8x8 board, with game discs that are black on one side, white on the other.  Like checkers, you and your opponent both have a color (white or black).  When you take one of your opponent's pieces, you turn it to your color by flipping it.

The way to take one of your opponent's pieces is by surrounding them on the board, either horizontally, vertically, or diagonally.  If you have one of your pieces on one side of your opponent's piece(s), and you place one of your pieces on an empty square adjacent to and on the other side of those opponent's pieces, you turn all the opponent's pieces in between to your color.  For a better explanation of the rules, you can consult Wikipedia's page on Reversi.

The thing is, since a capture can happen from any angle (horiz, vert, or diag), and since you have to circumscribe your opponent's pieces, it's actually a deceptively difficult algorithm to determine if a move is legal.  The best bet is probably to use a recursive function.

More to come, hopefully later today...

Retrochallenge: Sharpening the Saw

After a week or two off, I'm getting back into the swing of things on my networked Reversi game for the Commodore 64.

The rules of Reversi are deceptively difficult to program.  I've been faced with creating a recursive algorithm to check whether a move is legal, and then flip the corresponding pieces accordingly.

In terms of development, I've decided on these tools at the moment:

• CC65 C compiler for 6502-based systems (notably the C64)
• Notepad++ for my code editor (probably will replace this part)
• CC65 makefile for building/testing
• VICE emulator for local testing (can't test network functions with this)
• Real Commodore 128 and Flyer drive/network device for testing (have to move code to the device for testing)

My Retrochallenge goal is to have a working prototype of this game - a 0.1 version, if you will - by the end of July.  I'd better get coding!

PX-8 virtual drive mock-up - the gory details

I am quite pleased to report that I managed to create a prototype of a virtual disk drive for the PX-8, using a Propeller "Professional Development Board", and a cable (more on this later) to connect to the PX-8. Here is a brief background of the project, and what I wanted to accomplish for the Retrochallenge:

The Goal

Create a prototype of a PX-8 virtual disk drive using the Propeller microcontroller.

Measurement of Success

The virtual drive should respond to a DIR command from the PX-8, and load a single file.

Main Obstacle

Garbled communications between the Propeller and the PX-8 "serial" (peripheral) port.

What we have here is a failure...

The PX-8 communicates with its peripherals over something called the "serial" port. This is different than the RS-232 port (it's got one of those, too); however, it is actually RS-232 under the hood. Specifically, 38400 baud, no parity, 8 bits, 1 stop bit.

The Propeller development board has built in a MAX3232 level converter and a female DB-9 connector wired as "DCE" (like a modem). Part of the stock software that comes with the Propeller IDE (called the "Propeller Tool") is a module for doing serial communications.

I had a model of software to work from - the "vfloppy" program. This software runs under Linux, and is a virtual disk drive for the PX-8. It is open-source, and works great.

But in order to make any progress at all, I first needed to find a solution to garbled communications between the Propeller and the PX-8. When looking at the bytes going to and fro, it was clear something was haywire.

That something was me.

When I constructed the cable for use with vfloppy, I neglected that a serial cable has two types of ground. One is similar to chassis ground, and the other is signal ground. The reference I was reading at the time for the PX-8 serial port connector did not differentiate, so I hooked the PX-8 signal ground to the PC side chassis ground. This made it kind of work, but not reliably, as there was obviously impedance between the two types of ground. Once I figured this out, just a few days ago, the garbled communications went away. Just in time, I hoped, for a Retrochallenge entry.

Now to make the Prototype

I knew I wouldn't have time to actually duplicate the EPSP protocol in time, so I thought, why not capture a session with a working package (vfloppy), then make a Propeller program to play back that session. It's a very dumb program, with hard-coded bytes in and bytes out. However, although a one-trick pony, it would demonstrate that not only could the PX-8 and Propeller now communicate, but actually have a working conversation.

vfloppy has a great debug mode that can output everything that's going on in a session. I captured that output for a session that included:

• Go to the E: drive
• Do a directory
• Load a program called "BATTERY.COM"

The session was REALLY long, with lots of bytes. I knew I couldn't write a Propeller program that duplicated that session by hand. So, I dusted off my Perl brain cells, and wrote a Perl program that took the session output from vfloppy debug mode, and converted it to Propeller "Spin" code (Spin is the native language of the Propeller). Here's the ugly Perl code:



By the way, I know the pictures are not good. The lighting was bad, and I'm out of time. I'll get some better pictures later...

And here is a portion of the Spin program that it helped me to write (this is the Propeller Tool, the IDE for Propeller programming):



Here's a picture of the Propeller development board, wired up with VGA output and RS232 output, functioning as the PX-8 virtual drive:



And here's a picture of the PX-8 before power-up:



In the next picture, I power up the virtual drive and PX-8, then navigate to the E: drive. When this happens, the in/out byte sequence plays between the PX-8 and the Propeller exactly as recorded when I did the real session with vfloppy.

(For the next pictures, you'll have to click the image to get a bigger version to make it readable. Again, sorry for the bad lighting, and the notoriously bad contrast on the PX-8 display...)

Notice the PX-8 happily shows the E> prompt, perfectly fooled that it's talking to a real drive:



This thing is functioning like a player piano - so I have to type everything just like I typed it in the real session. Any deviation will make the house of cards fall down. So next, I type DIR (return), just like I did for real with vfloppy:



Now, the big moment - I actually run a program! From the PX-8's point of view, it still thinks it's talking to a real floppy drive. From the Propeller's point of view, it's just waiting for the right bytes to come in, then spewing what was recorded earlier:



Smoke and Mirrors


Before you say it, I know - this approach is smoke and mirrors, because there's really near zero intelligence on the Propeller side. However, it met my goal in proving that the PX-8 and Propeller could successfully communicate, and that the Propeller, when properly programmed, can be a virtual drive for the PX-8.

Next Steps!


Now that the facade has proven the viability of the project, my next step is to begin to crank out the code that makes this thing a virtual drive for real.

An SD card will serve as the mass storage for this device. I've used an SD card with the Propeller before, so that assumption should be a safe one.

The vfloppy code is a very useful reference implementation, but I want to make sure I understand everything that it does, and not just copy the logic from it. As I work through the reverse engineering and compare with the published Epson protocols, I'm sure it will be fun and enlightening.

I will keep my progress updated on this blog, and as the project matures, I may actually start a dedicated blog and progress site.

Yay! Time for some sleep! See you all in the Winter Warmup...

SUCCESS!

Full blog post coming next - but I'm packing a happy hooray and sigh of relief, as my Retrochallenge finishes successfully with hours to spare!

Details within a few minutes...

Tomorrow starts the 2011 Retrochallenge

The Retrochallenge 2011 officially kicks off tomorrow (well, really, tonight at midnight). This year, again, I am trying to jump-start my project for a Epson PX-8 virtual disk drive.

Yes, this is the 3rd attempt. And since the third time is the charm, as Bullwinkle would say, "This time for sure!"

More info tomorrow with pictures, specifications, links, and other fun.

Retrochallenge Success!

To recap - my goals for the Retrochallenge 2011 Winter Warmup were:

• Build a cable to connect the Commodore SFD-1001 drive to the PET 2001-8N.
• Test the cable and the drive by successfully formatting a disk, saving a program, then re-loading that program into memory.
• Get some software from the Internet, load it into the PET, then save it to the SFD-1001.

Having done the first two steps, I set out this evening to finish step 3 - getting some bits from the Internet to the PET. And - success!

(With one caveat - I actually created the program that I moved from my PC to the PET/SFD-1001, using VICE. But it could have been a PRG program from anywhere.)

Here are the steps I used to get the program from my PC to the PET, then to the SFD-1001:

Create program in VICE

I typed a small (very!) program into the VICE Commodore PET emulator program, then saved it to a virtual tape file ("TAP" file). It's pretty easy to create and use a virtual tape image in VICE. I'll leave the "how" as an exercise to the reader, but you'll figure it out in less than a minute.



Create a WAV file with an analog C2N-compatible audio image of the program

Next, I used a program called "Audiotap" that converts a virtual TAP file into an audio "WAV" file.



This program prompts you for the *.TAP file, then for the output *.WAV file. It then creates an audio WAV file that reflects the same signal you'd hear as created/used by a real Commodore C2N cassette drive.

Record the WAV file to tape

Now, creating this file and recording it to a cassette deck was pretty easy. Getting it to read on the PET was hard. The audio levels had to be adjusted properly, and I actually had to switch computers once. I was trying to use my laptop for this, but its sound output is too noisy. I eventually switched to my desktop, which has a SoundBlaster Audigy 2 ZS, and this was squeaky clean. Here's the mono cassette deck I used:



Load the program from C2N tape into the PET

Once the WAV file was recorded on the tape, then I moved it to the C2N cassette deck, and attempted to load the program from tape.



As I mentioned, getting the analog levels correct was tricky - but once done, things were looking up!



Save the program to the SFD-1001

With the program successfully in memory, I wasted no time in saving it to the SFD-1001:



Test that it all worked

With the program safely moved from the PC to the PET to the SFD-1001, I then did a cold-start (just to make sure there's nothing up my sleeves), and loaded the program back from disk:



Voila! Bits moved successfully from the PC realm to the PET via good ol' cassette tape, then tucked safely away on disk.

The future

As I've been reading up on moving programs between the PC and the PET, I've found that there are several options, all of which are better and more sophisticated than the cassette tape proxy method that I just performed. I'll be looking into these, perhaps building some more hardware, and then will blog with future results.

But for now, I will bask in the bright light of Retrochallenge success!

RC 2011 Winter Warmup photos

As promised, here are some photos of my Retrochallenge 2011 Winter Warmup project. You click on the pictures to get a bigger version.

First, let's start with a photo of the PET 2001-8N, SFD-1001 disk drive, and handy 5.25" disk holder (containing a DS/DD disk!):



Here's a close-up of the PET:



Here is the SFD-1001 IEEE-488 drive. Notice the DIP switch on the lower right-hand side - this is the "hacked" device select that I talked about earlier:



Here is the drive side of the cable I made. Note that it's a 24-pin Amphenol connector - smaller than Centronics-style printer plug, but similar in appearance:



Here are a couple of pics of the PET side of the cable (this is the side I soldered). A bit ugly, but functional - and I got good solder joints. I think I'm doing better with my soldering these days. Note that it's the same type of connector as the PET (and later) user port:





This is the SFD-1001 formatting the disk:



And here is the result - notice the 4133 BLOCKS FREE - that's slightly over 1 MB. Read it and weep.



OK, here's where I chain two programs together, while not losing the variables in-between. There are two programs on the disk, creatively named PROGRAM1 and PROGRAM2. I've got screen shots; however, the first screen shot is pretty fuzzy, so here's the code...

PROGRAM1:

5 PRINT "NOW RUNNING PROGRAM1"
10 A=1001
20 A$="SFD1001":A$=A$+""
30 PRINT A
40 PRINT A$
50 PRINT "CHAINING TO PROGRAM2"
60 PRINT
70 LOAD "PROGRAM2",8

Hey, on line 20, what am I doing with the A$=A$+""? Why add a null string to another string? Here's a summary - When Commodore BASIC sees a new string defined like A$="HELLO", it leaves the string storage right in the BASIC program. Why move it and take up more space? Pretty efficient - except when you chain to another program, that line number is gone, and so is your string. So you need to do something to Commodore BASIC to make the string "dynamic" - stored in variable memory, rather than right in the BASIC program. Adding a null string is one way to convince the string to be "dynamic".

For a better and more lengthy explanation, see Jim Butterfield's 5 part series on this topic, as provided to me by Nathan (thanks Nathan!). (Links at the end of this blog post.)

PROGRAM2:

10 PRINT "NOW RUNNING PROGRAM2"
20 PRINT A
30 PRINT A$

Pretty simple, right? Line 70 of PROGRAM1 loads PROGRAM2 from disk, and it starts running, printing the variables to prove they made it! Here are the screen shots, including the program running:

PROGRAM1:



PROGRAM2:



Running PROGRAM1, which chains to PROGRAM2 - Drum roll please!



It's ALIVEEEEEE!!!

OK, here are the links to the Jim Butterfield articles if you'd like to read up.

Loading And Linking Commodore Programs by Jim Butterfield (Part 1,) Part 2, Part 3, Part 4, Part 5.

My next posting, perhaps later this weekend, will be a first shot at getting bits from the Intarwebs into the PET, and onto the SFD-1001! Stay tuned!

As a side note, my cat Stormie decided to upstage my retro hobby today. When she wants attention, she's pretty persistent. From one PET to another...

Episode #139 - covers my Retrochallenge 2011 Winter Warmup entry

Be sure to check out Episode #139 of the Retrobits Podcast, which I devote to the SFD-1001 drive, IEEE-488, and my Retrochallenge 2011 Winter Warmup entry!

Highlights:

• The SFD-1001 drive and cable are functional and working well.
• I've been able to "chain" two BASIC programs together to make a more "complex" program; however, string variables may not be preserved when loading one program from another. More research required.
• My proposed first-pass method to move a program from the Internet to the SFD-1001 involves using an emulator to create a TAP (virtual cassette tape) file of the desired program, using another utility to turn that TAP file into a WAV file, recording the WAV to a cassette tape, then loading that program from that tape onto the PET 2001 using the C2N cassette deck. Finally, the program will be stored from the PET to the SFD-1001. Whew! Morse code goes faster!

Another week and a half to finish! Hoping for a success!

Voltage problem?

I'm still working on my Retrochallenge entry. There are only a few more days in the month, and I feel like I'm pretty close to the goal. However, it could be that a good ol' hardware issue has me stuck.

I've reverse-engineered some of the code from the "vfloppy" program, and figured out how the PC serial port is used to talk to the PX-8. It's very straightforward, as I thought, based on the specs - 8 bits, no parity, 38400 baud, no flow control, just raw I/O. No magic at all. And that's exactly the way the serial code for the Propeller works, too, by default. So, why do I not have reliable communication?

Based on the trouble I had making the vfloppy program work with one computer and not another, it occurred to me that serial port voltage/current might be an issue. I checked the Epson PX-8 tech specs, and it looks like the serial and RS232 ports on the PX-8 want +/- 8V. Standard RS232 voltage is +/- 12V, and that's what the MAX3232 chip (used on the Propeller development board for serial communications) puts out. So, I'm wondering if there's a sufficient voltage mismatch as to be causing communication issues? Seems unlikely, but I'm kind of at a loss to understand why this is being so difficult to get going.

Anyhow, I'll keep working - perhaps I can put some resistors in line, and see if that improves the situation.

The first speed bump

When trying to accomplish something with technology, it seems like there are always these strange "gotchas". I've encountered the first on my road to a PX-8 virtual drive prototype...

As I set out to produce the PX-8 virtual floppy drive, one resource that I'm hoping to use for reference is the open source, Linux-based "vfloppy" program (see previous post). Turns out, vfloppy works great on my old Dell laptop, but not on my newer one (Dell D630). Both are running Ubuntu 10.04 LTS, both have the same serial UART, and they are configured identically. However, with the D630, I get serial communication errors, and with the older Dell Inspiron, I don't. Ugh.

Since I've got the source code, I went poking around to see how the serial port is initialized and opened in the vfloppy program (epspdv3.c). It's pretty straightforward stuff using the standard libraries. Should be about as hardware non-specific as you can get.

Thinking it might be my specific D630, I tested another that I had handy. Same issue. So the problem is not with faulty hardware, but with some specific hardware/software issue.

I know problems come up when trying to accomplish something - it's part of the challenge of a project. But this is my least favorite kind of problem, because it is, at best, only a tangent to the real problem I'm trying to solve.

I might just be stuck using my older laptop for the project, unless some magic happens...

PX-8 virtual drive: Next stop - Linux and vfloppy!

The vfloppy disk simulator is software that acts like a disk drive for the Epson HX-20 and PX-8 systems. It is written in C, for Linux. It's regularly updated, and now supports the D88 virtual disk file format used by the PX-4/PX-8 emulators produced by Toshiya Takeda.

All the software in play here is GPL/open-source, which is awesome. Having an open, working, updated implementation of the disk drive simulation will be very helpful in my efforts to produce a Propeller-based virtual drive.

This is the most current and best solution I'm aware of for emulating the Epson PF-10 floppy drive on a modern system, so I'm off to install Linux on a spare machine. Rather than use a virtual machine and have the potential hazards of uneven serial port support, I'm putting this on real hardware. I'm going with Ubuntu 10.04 on a Dell Inspiron laptop. Will be nice to take the new Ubuntu for a test drive anyhow!

Retrochallenge 2010 begins!

The Epson PX-8s are charging their NiCads - warming up for their role in my entry for this year's Retrochallenge event. May the games begin!

PX-8 Virtual Drive, take 2

The Epson PX-8 is a circa 1984 laptop computer, running the CP/M operating system (ROM based). Last I checked, you can still purchase new PX-8 systems from Star Technology. However, the PF-10 3.5" portable disk drive for the PX-8 is a very rare beast - the ones I've seen on eBay I've never been able to afford.

Communications between the PX-8 and PF-10 are over an RS-232 compatible connection at 38400 baud. The protocol is documented, and there are a couple of software packages - one for Linux, and one for DOS - that emulate the drive. I would like to extend the work that's already been done in this field, and create a portable, battery-operated virtual disk drive for the PX-8.

I'm hoping to be able to use a Propeller microcontroller chip as the "brains" of the virtual drive. The Propeller is cool - 8 parallel cores or "cogs" typically running at 80 MHz nominal clock speed. There are hardware/software solutions for interfacing with external storage, including SD cards.

Like last year, I've entered the Retrochallenge contest with the goal of producing a first pass at a virtual drive prototype. Unlike last year, this year I hope to achieve the goal!

More postings as I go. Look for details on this blog, with the tag label "retrochallenge".

Retrochallenge 2010 starts in two weeks!

Hi all,

The Retrochallenge 2010 contest begins in about two weeks! If you've got a fun idea for a retrocomputing activity or project, head on over now!