Monday, May 14, 2018

First run of Dragon's Lair Prototype Boards

In order to advance on the hardware side of this, I learned KiCAD and laid out two PCBs. One is the intended final board, and one is a prototyping board that accepts the same ZIF socket for the flash chips as my EPROM programmer does.

I got the PCBs back from OSH Park, and there are a few screwups...



I haven't checked them electrically yet, but there are two main issues - one is OSH's and one is mine.

The OSH one is those connector tabs you see all around the board. I wouldn't generally care, but they put one on the end of the cartridge connector. This has two side effects. First, I need to file it off to make it fit into the port (okay, whatever).

Secondly, and more importantly, whatever method they use to break apart the boards physically damaged the connector:



It's a little hard to see in this photo, but the board is coming apart at the top layer and has actually torn a millimeter or so between the traces. You can most easily see it in the distortion on the one trace.

There's no similar damage on the bottom, so I assume that's the direction they flexed the board to break it apart from the next one.

I'll have to drop them an email to ask how to avoid that on production. It's likely I can use at least one of these boards for prototyping and testing.

The other problem is I apparently didn't measure out the adapter board correctly, because it's completely wrong. It has two parts - the large DIP footprint and the smaller 10-pin header. I managed to make the holes too small for the DIP part and use the wrong pitch and misaligned the 10-pin header. GO ME!

I have three of the adapters, just in case, so I think I can fake it by bending the very long pins on the 10-pin header, and I'll just have to force it or grind the pins to fit the DIP (or use my I-do-this-every-time trick of soldering smaller leads onto the pins... sigh. Someday I'll remember that sockets use thicker pins...)

Anyway, in the middle of moving, but I need to try and test this out as quick as possible, because the next challenge I'm facing is that the 1gigabit chips are obsolete and getting hard to find. OH BOY.

Edit: As Captain C used to tell me: 'Never underestimate the power of force!' I literally used a hammer. ;)


Wednesday, March 7, 2018

It's not Lego!

While pondering why it is that the state of software development has reached the point that it's at (which very patient long term readers will remember is my usual gripe. Blogger says there are 3 of you! ;) )... where was I?

Right, so anyway, projects seem to be planned very strangely. There are cycles and cycles of proposals, and pre-pre-design documents (though rarely an ACTUAL design document). We have processes designed to break tasks down into a bullet point's worth of work, and we consider that planning. We have code management systems that make actually looking at the code the hardest thing to actually do (I'm looking at YOU, Gitlab...)

And while going through all this in my head and trying to reconcile with the task I'm trying to complete myself, I grumbled to myself "code is hard". And that was the revelation.

Oh, I've always known that it's hard to write good code. Anyone who tells you otherwise is either a liar or a genius, and the odds are heavily stacked in one direction. But I've never had that thought in this context. And that's when it all fell together for me.

Coding is increasingly treated as one of the least important parts of the software development process, maybe second only to testing (which will be a rant one day). And yet coding (and testing) are the only parts of the process that actually matter. They are the only parts that actually produce product at the end of the day.

And so as I was thinking that coding is just brushed off as the least important part of the planning process. It seemed like the assumption was that it was going to be easy to get it right, and testing would be covered by the process. So don't stress that part. And then I realized, there IS a style of development for which this is so, and it's increasingly proposed as the right way to do things.

And that style is: don't do it.

Think about it. You've been on the project that said "can't we just buy a package that does that?" How about "is there a library we can use?"

And so I'm of two minds here. The first one is that, well, yes, re-use is a good thing. Yes, many many many tasks have already been developed in one form or another. And no, I don't desperately want to write a USB stack from scratch. So we can just go out, and take all these pre-written libraries, and write a few lines of glue code, and not only is it likely to work, but it's been mostly pre-tested.(Or, so we blindly assume...) Hell, at this point we're not even the performance bottleneck, so let's just write it in script!

The other mind is the reality that I live in anyway where the exact things we want to do don't exist, and so we're building them. But we still use that building-block mentality. We don't consider that maybe nobody actually knows how to do that, and so it's going to take time to get it right. There is still a world where the hard code isn't written yet.

We've reached a point where many people assume that if something doesn't exist, it's because it's too hard to be possible. Don't you believe it. It only means that someone hasn't done it yet, and nothing more. Get out there. Write the hard code. Get it wrong! Then figure out WHY it was wrong and get it right. Odds are, by that point you'll have created something better than anyone before you did.

Oh, and if you're a project planner, realize that hard tasks take time. ;)

Tuesday, November 7, 2017

Investigation continues...

I went through and verified the pinout of the cart, and burned a new AVR and dropped it on the board to test, but it's still working just as flakey. A couple of things were interesting.. one is that when it partially works, it seems to get most of the bytes right (because the program selection is mostly correct). That seems to suggest either I am lucky or the address code is working. (I suspect the latter - if I was lucky I wouldn't be having an issue).

Putting the logic analyzer on it was all over the place, to the point where I couldn't make sense of what I was seeing. But I also determined that my console's power switch is wearing out... so I need to make a repair there to continue anyway.

One thing that has crossed my mind is that with the new compiler, the code may be running too fast. I check the MDIR and MODE pins immediately after detecting GSEL -- maybe that's too fast? When I get the logic analyzer properly on the bus I will recheck that theory.

This shouldn't even be an issue, but I am leaning back towards the ROM-based cart.... I just want this part to work. ;) But in the meantime, I relaid-out the cart to use the ATTINY861 instead - it's a 20 pin part instead of 14. So it doesn't look as much like a GROM, but it has enough pins to bring out the ISP header. I also positioned it so, in theory, the ZIF socket will fit on the board when in the console. I haven't ordered this board or the new parts yet though...

I probably should test programming one of the 128MB flash chips as well -- if my new programmer can pull that off, maybe I should stop wasting my time with the GROM emulation. (But darn it, this part was supposed to "just work". ;) )


Saturday, November 4, 2017

Didn't Work First Try

Never should expect that it will, but I'm a bit disappointed and frustrated at this point.

I had two things to do today - the first was to port my GROM simulation code to the ATTINY84 that I selected for GROM boot. I thought it would be nice to have that to startup, and I could use the EEPROM for high score saving.

That port went reasonably well, and for the most part it did what I expected. Then I shut off the reset pin and discovered that I don't seem to be able to get high voltage serial programming, needed to reprogram it without a reset pin, to work. I spent several hours on this, including research and rewiring it repeatedly. I seem to recall having this issue before and eventually deciding keeping a reset pin was a good idea, but I need every I/O an ATTINY84 has. I think I may nudge up to the next physical size.

Then I went to build the cartridge prototype, and pretty much everything on that PCB was problematic.

First I detected that I didn't actually buy all the ICs I needed to assemble it. I was able to raid the parts bin but it was frustrating. Then, of course, the ATTINY footprint was too close to the IDE port to allow a ZIF socket (I always forget how big they are), and I forgot that the pins need to be larger.

I soldered leads to the ZIF socket to get it on the board, and forgot you need to do that when it's OPEN, not closed, because otherwise the sockets don't always open up for you. ;)

Finally, I got it all together and plugged it into the TI. It didn't come up reliably, it's very flakey, but at this point I think I'm done for the day. When it did come up, the data was correct. I got as far as seeing the menu entries and even getting Easy Bug to start booting, so the basics are working. Either there's some timing issue or I configured one of the I/Os wrong, or (worst case) the IDE circuitry is interfering.

Because I was too dumb to test it before I put the IDE circuitry on.

So I think the next step is to take Jim up on his layout offer while choosing a new chip for this approach, and we'll see which layout works first. ;)


Also did a few surveys to see what people thought about dither patterns. My first favorite was shot down pretty hard, but in the second pass there are two contenders neck in neck, one of which IS my favorite. Sadly there are only about a dozen votes, which speaks lovely for the potential market of this thing. Oh well. ;)

So it looks like we'll be using an ordered dither, but in order to get around the terribly washed-out effect I was getting, I introduced back in a tiny bit of error distribution. It makes a difference in the color yet preserves the more regular patterns of the ordered dither, and I'm pleased that people like it. It's really down to whether I'll use the 2x2 or the 4x4 pattern at this point. (When I re-encoded, I'll probably just do the top four so I can change it out again at the last minute without fearing that the frame numbers might change...)

You can see the current challenge video here (if you can get past Youtube's scaling...): https://www.youtube.com/watch?v=NdO-lokD7DM

Thursday, October 5, 2017

I think it'll work...

I have laid out an IDE interface with an UberGROM powered by an ATTINY84 - that'll give me 8k of GROM on the cart, which is plenty to bootstrap and maybe even run the game.

I'm expecting to need 32k to run, but I guess we'll see.

Anyway, I've still got a long way to go.. hopefully using this will let me work out the kinks and prove the hardware and software both. My first pass, I'm just going to load EasyBug on the GROM so that I can poke at the CF card manually.

I was silly and laid out the PCB before getting the TI cart outline, so I made it way too tall. Still, I think there's a good chance it'll fit. One more night should be enough to get me there... then I can order some and we'll see.