Dragon's Lair Status

It's amazing to look back and see that I ordered the PCBs all the way back on Feb 7th. They (of course) came later than expected, and I've been battling them for the last week and a bit.

I wrote the software without emulation support (for all but the CF card that I already did) only to find it not working on hardware. At least, not reliably. I could always get the CFI data, but attempts to write or erase the flash were random - sometimes working, sometimes not.

This issue consumed me all of last weekend and by Monday I had implemented full flash emulation in Classic99 and fixed a number of minor isses, but it still didn't work on hardware. I decided I would have to give up, ship the last few boards I could build by hand, and call it done. But I went ahead and created a list of possible things I could verify on the new boards. Then, because I can't let things go, I started hitting the easy ones. ;)

One of those was to desolder the flash chip, program it externally, and try it in my test cart. When this worked, I put it back on the board and tried again, where it didn't work. I quickly realized that now that the OE and WE lines were under CPLD control, I would need to set them to valid states (it turns out both were defaulting to pull up, +5. This disabled the flash output). I ended up setting the default to pull down and giving WE a powerup state of high -- this worked.

I decided, just for kicks, to try that on an unmodified board, and found that my programming load for the CPLD had all the new pins set to CMOS drive. Without a pullup on the board itself, this would leave the lines floating when they were supposed to be high (if I follow right). Changing those to LVTTL suddenly made all my tests work.

Since then I've been correcting minor issues and improving the flow of the software. I thought I had a success earlier in the week, and that led to needing to make another critical change to the game software itself.

The board has a flaw on it that write protects the first 128k of the flash chip by hardware, and disabling this write protect is risky because the trace is under the board (instead of out where it would be easy. When I changed the board I made a specific pass to look for traces like this, but because I didn't label my pins correctly, I thought it was just a power supply ground and left it alone.)

This means I needed to change the software to skip over the first 128k. The game is raw assembly and although I did use offsets and equates for a lot of it - there was some hard coded page wrangling to deal with. Lesson learned - I'm still making sure I got all of it right tonight (even though I've already programmed five boards).

Anyway, the first pass of the programming software needed over 4 hours, so today while it was running I decided to speed that up. I first attempted a mod over at nouspikel.com/ti99 to remove a couple of wait states from the console. My thinking was to hot-rod my main console, add the hacks needed for programming, and have two machines ready to run in parallel. Unfortunately, I failed and it doesn't boot. I don't have time to see why right now, so I put it aside to double check later.

I then moved over to the code itself, and moved the three inner loops to the scratchpad. Scratchpad RAM (the TI has a whole 256 bytes of it!) is zero-wait-state RAM, running fully 3 times faster than all other RAM in the system. (After the slow execution time of the instructions themselves, programs usually see a bit under twice the performance). The main loops are reading from the CF card, writing to the flash chip, and verifying the flash chip data... these three loops only needed about 100 bytes. I was also really happy (once again) to see how easy it was for GCC to link into them.

I also found a bug in a little gimmick I had put in last time. It's /always/ the little gimmicks. I put a little progress bar and running man to show it was working at the top of the screen. I figured that it wouldn't hurt anything. But, sure enough, a bug meant the running man updated every single packet, eating cycles. ;)

Testing in emulation suggested that time would be down to about 2.5 hrs, but my local build Classic99 is a bit broken speed-wise. Loading it up on hardware had a cartridge programmed in 90 minutes. Definitely happier with that!

However, the output carts don't work yet. They don't pass checksum and they had a bug in practice mode. I've fixed the practice mode bug and it's writing again to see if I have sorted checksum (which works in emulation, so it's bothersome). They DO run and play so at least I can verify the game, even if the diagnostics were broken by the move ;)

But anyway, long way of saying that I had to learn so much to get this going, and it never stops. I'm grateful for the knowledge but will be glad when the next project doesn't require so much download into my head. ;) Going alllllll the way back, this project brings together:

- image conversion to TI bitmap mode (a process that took many years to get nice)
- video conversion to frames
- audio conversion to TI audio (took some fiddling)
- VHDL for the CPLD
- programming CPLD hardware
- laying out a PCB for manufacture (rather than the simple tools I used before)
- hand soldering fine pitch components
- troubleshooting this particular hardware
- getting a PCB manufactured (done before, but never fully on my own)
- programming these specific flash chips (I've done others before)
- reverse engineering the CF7 interface (this frankly was pretty simple)
- reading and writing Compact Flash cards in 8-bit mode
- understanding how the CF7 stores disk information on the CF card (this took longer)
- learning how to use DD from Windows to build the CF data I need to program the carts

I don't know, something like that, it took a while. I need to go bed. ;)

Counterfeit Flashes?

It's always hard to be sure... but I'm getting a lot of failures on the last tray of flash chips - I'm up to 29 so far (and I only had 110 in the first place!) What bugs me is that the first trays I ran through, the smaller ones, were perfect, as were the first ten or so from the big tray.

I can't find any markings that tell me for sure what's wrong with the chips that fail - they have varying date codes and I don't (yet) have any for-certain authentic chips to compare them against. But the chips that fail all fail the same way - the EPROM programmer reports that the ID command comes back as "0x09090909" (and 0x09 seems to be the ID command), and if I ignore it, both the chip erase and the write attempts fail immediately.

This means if I'm going to reach 100 carts for Dragon's Lair, I'm now dependent on the manufactured run working. I haven't started that software yet, hopefully this weekend. (I started to update Classic99 for the flash emulation and that turned into a re-architecture. So hey, good news, I finally started version 4! ;) But I need to put that aside and do something quicker and hackier for testing the software.)

The good news is that although Fry's didn't have any CF cards, I did grab a bunch off Amazon. Only a couple of them worked on the CF7 (there's really something wrong with that thing's timing), but I only need ONE to work, so I can proceed with that for now. They've billed me for them, so fingers crossed.