Powering the laptop

I am hoping to have the laptop ready for the Adelaide Mini Maker Faire on the 1st of November.  This means I need to make some rapid progress.

As shown in the previous post, I have started to get the hang of the laser cutter, and am starting to work out the cutouts in the various panels, starting with the keyboard.

I have already ordered a nice battery management board that will charge the batteries, and also provide output power from the batteries.  To this I will add a cheap 12V adapter that I bought from Jaycar Electronics. So, I can make use of power once I can get it into the laptop.

Next is to work out how I am going to get power into it to charge the batteries.  I use 2009-2012 model macbook laptops at work and home already, so my preference is to make it compatible with Apple's magsafe connector.  To this end I have obtained a dead macbook and given it a magsafeectomy, and started trying to understand how the magsafe connector works. I have discovered a few things:

1. The magsafe DC-in board really is just a way to get to the 5 pins on the connector, there is essentially no smarts in the DC-in board.  This is good.

2. Magsafe power supplies don't turn on their full voltage until they see a ~37K resistance between the Vcc and GND pins.  After seeing that for 1 second, they switch on the full voltage.  What I don't yet know is if the resistor can stay there. From a power perspective, 37K Ohm at 20V will dissipate only about 0.5mW, so it could indeed remain there.  What I don't know is if the Apple power-supply expects it to disappear after a while. I will also have to work out if I have to isolate the battery manager etc until the full voltage is available. It would be nice if all I have to do is put the resister in place, and then just use it.

3. The LED on the magsafe connector is controlled using the 1-wire protocol on the centre pin. This allows setting the LED either orange, green, or both, which makes yellow.  It would be nice to implement this for the MEGA65P prototype, but it probably won't happen for the first revision. Someone has managed to control the LED via an Arduino, so there is no real technical barriers to doing this -- provided I can get an indication from the battery management board about the charge state of the battery, i.e., full or charging.

4. The connector on the end of the 5 pins is a bit too small to be convenient, so I will probably replace it with a 0.1" 5-pin header.

So all up, it looks like I should be able to use magsafe on the prototype.

Some laptopification preparations

I have crimped a few minutes among everything that is going on to do a couple of things towards the MEGA65P prototype - the laptop form factor one.

Readers of this blog will know that I already have a suitable panel, batteries and a number of other components for this. What I have been working on lately is seeing how I can lay out the components, and just how big this laptop will end up being.  It turns out quite big, but not exceedingly outrageously so.

The batteries take up about 1/3 of the space, which is quite a lot, although the 3.5" floppy drive doesn't really help much either.  Or the full-sized genuine C65 keyboard with full-travel keys.

I like the safe and robust LiFePO4 batteries, because they are safe and robust. No one wants an exploding C65 on their lap. Also, there is nothing worse than having batteries fail, so that you need to be plugged into the mains all the time.  So I have opted for four quite large LiFePO4 cells. Actually, it is probably fairer to say that I have opted for four VERY large cells. Each is 3.2V / 12Ah, or 38.4Wh each -- as much as the entire battery in some other laptops.  This means that all up the MEGA65P will have 153.6Wh.  That's more than double what my macbook has.

This specification was based in part on the stated current draw of the LCD panel driver that I bought, which claimed up to 3A power consumption.  This would mean that the batteries might only last about 4 hours, although I hoped somewhat more.  I had, however, been ignoring this question until I decided to order a 12V regulator for the prototype.  1A regulators are smaller, cheaper and don't really need a heat sink. However, a 3A regulator at only 80% efficiency might generate more than 7 Watts of heat, and would probably require a heat sink.

So today while we were rearranging some things in the lab, I decided to test the actual power consumption of the LCD panel driver, and also the MEGA65 running on the FPGA board, so that I would know which regulator I need, and also get a good idea of the battery life I could expect.  I was in for a pleasant surprise: The LCD panel never consumes more than 0.61A @ 12V at full brightness, and the FPGA board about 0.59A @ 5V.  This means about 7.5W for the LCD panel and 3W for the FPGA board, or 10.5W all up.  This means that the four LiFePO4 cells should be able to run the MEGA65P prototype for between 14 and 15 hours.  The reality will probably be a bit less, once I add missing peripherals and parts, but it looks like it should comfortably run for 10 hours of continuous use.  This will be a nice result.

I also took a few minutes in the Digital Fabrication Lab here to start modeling laser-cut panels for the MEGA65P.  So far I have just been working on the top panel for the bottom half, trying to get the keyboard cut out right.  This has taken some trial and error, to get all the spaces around the keys even and not excessive, while not being so close as to jam keys (which was actually a problem with my real C65 -- it was a prototype, after all).

You can see here my 3rd iteration, which is almost right. You can see the annotations I have made of what needs to be adjusted.  It already looks kind of cool with the keyboard in. Sorry about the poor image quality -- the camera on my phone is getting rather clapped out. The natural colour of the MDF isn't too far off "commodore beige" ;)  For the actual prototype I will most likely use off-white acrylic or acetel plastic.

Aren't new computers better than 8-bit computers?

And now for a few minutes fun diversion while I have a headache: I ran across this video quite by accident, which looks at some of the ways in which old computers were better than the newer generation.  

Of course it is all a bit tongue-in-cheek, but there is some truth in the simple reliability and maintainability of old computers.  Anyway, I hope you enjoyed a few minutes diversion.

Hi-res bitplane mode sprites now working!

Okay, so the last main part of my burst of sprite-enhancements is now working: bitplane mode for hires sprites.  What can be seen below is two sprites on screen, fully coloured in (all one bits for the image), overlapping each other and a character-mode checkerboard in the background.  The presence of each sprite causes one bit in the output colour to be flipped, and as this occurs in each combination, it yields a distinct colour.

For a lame piece of basic, it looks kind of interesting.  Of course it would look better with some interesting animation.  I might have some fun later finding some games where turning on bitplane mode on the sprites yields pretty results, but that will have to wait until I have more time. For now I am happy that I have implemented the main outstanding sprite functions -- although the collision detection still has some wrinkles to be worked out.

Bitplane-mode/"attached" sprites working in multi-colour mode

... but not in mono-mode.

In the last couple of posts I have written about my plan for having a bitplane mode for sprites. What this means is that a sprite can be set to modify the colour of the pixels it touches instead of just painting with its own colour(s).

This can be used to do a few different things.  First, you can set the bitplane mode on one or more sprites, and have them modify the colours of a "normal mode" sprite, so that only the appearance of the first sprite will change (assuming you make the bitplane-mode sprite(s) only have bits set inside the first sprite).  But you can also have sprites that all have the bitplane mode enabled, in which case they will modify the colour of the character/bitmap/background pixels behind them instead.  This is what I do here, but lets do things in order.

First, I enabled a couple of 64x100 pixel sprites, using $0400-$07ff as the data source. I spaced them slightly.  Because bitplane sprite mode currently only works in multi-colour mode, I have put the sprites in multi-colour mode, and so we can see the three colours in each sprite (white, red, black and pink), of which two are in common (black and pink):

Next I turn on bitplane mode for one of the sprites: Now we can see that it is modifying the colours behind it, whether those colours are from a sprite or from the rest of the display.

The extra colours are all the result of fiddling with a couple of the bits in the colour.
Now if we enable bitplane mode on both those sprites, we can see the same thing happening, but with more of the bits being fiddled, so we can see more colours where the two sprites overlap:

Okay, so using random junk for the sprites isn't really the best demonstration, so I filled the sprites with solid data, and did much the same thing:

Remember that the above display is all on a blue background, with only yellow text.  All other colours are the result of having the two bitplane mode sprites over the top modifying the colours.  One is modifying bits 0 and 1, and the other is modifying bits 2 and 3.  If I had more time I could have animated them to show the effect better. Another day.

Each sprite in bitplane mode will modify a specific bit or bits in the pixel colour. In mono mode (hires sprites), the bit is the number of the sprite. In multi-colour mode, it is a pair of bits, with sprite 0 modifying bits 0 and 1, sprite 1 bits 2 and 3, sprite 4 bits 0 and 1 again and so on.

Next step is to get it working for mono/hires sprites. I think I have found the bug, and am resynthesising it now. I was reading the wrong bit from the sprite colour data vector, which was always zero.  This came about because I use the same 128-bit vector for mono and multi-colour sprites, and just pad the upper bit of each two-bit colour select in mono/hires mode.  Hopefully in a few days I will have an updated post showing hires bitplane mode sprites, and perhaps after that I will write some simple little demo that has an animated set of bitplane mode sprites that causes an area of the screen to be dimmed or something like that.

Screen shots of debugging enhanced sprites

I have managed to fix a few more bugs with the extended size sprites, as the following shots show. Apologies for the horrible quality of the images, my usual phone is not in reach, and the one I had on hand has a terrible camera.

First, here is a sprite with extended width (64 pixels wide) mode on, and extended height mode on, with a sprite height of 100 pixels.  That's a big sprite!  Sprite data addresses are still in multiples of 64 bytes, but can span upto 1KB for big sprites -- that's enough for 128 rows of unique data.

Here is another similar shot where I have changed the contents of screen memory (which is where I have the sprite pointed to for convenience) to show that it is noticing all 1KB of it:

In the previous post I spoke about adding "xray-mode" to mark foreground, background, sprite and border elements, so that I can debug the sprites more easily. This is what it looks like for this display. Looks like everything is getting correctly classified.  A little after I took these screen shots, I realised that the sprite background/foreground priority bug seems to be fixed -- either that, or I have the sense of the flag backwards. In any case, the sprites are appearing behind the text, which proves that I can do the priority sorting.  I just checked in VICE, and confirmed that I did indeed have the sprite priority flag working backwards -- so I'll add that to the next resynthesis run.  This is a good discovery, because it means that a whole bunch of extra games should work now as well.

Here is the same sprite with horizontal tiling turned on, making it repeat across the screen every 64 pixels -- great for parallax background.

What didn't work was the bitplane modification mode, which I have poked around with a bit since, and hopefully will have working soon.

More work on sprites

Finally got a chance to look at the sprite fixes that I have been working on now that I am next to my FPGA board again.

It is nice to see the sprite colour bug fixed, and see some of the games that are known to work without problem on the MEGA65.

This also means that I have finally been able to take a look at my work on 64-pixel wide, and variable height sprites, as well as a few other fun sprite improvements, some of which are inspired by the Amiga and abuse of sprites on that platform.

First up, I fixed a bug with normal-width sprites that was introduced when I started adding support for 64-pixel wide sprites.  The sprite data fetch logic was fetching one more byte than it needed to. With 24 bit = 3 byte wide sprites, this wasn't a problem, as the 4th byte didn't map anywhere since the byte address was using two bits, and thus has four possibilities. However, the move to 64 pixel = 8 byte sprite fetch meant that the extra byte, now being the ninth byte (byte 8), mapped back onto the first byte (byte 0) in the 3-bit sprite data address register.  This meant that the first byte of each row of a sprite was showing the byte that should be shown in the third position two rows down.  This was fairly easy to find and fix once I thought about it, and indeed fixed the problem.

However, after this I was seeing glitching on the right edge of sprites, which turned out to be an analogous problem, where a 25th (or 65th) column of pixels was being drawn.  Again, easy to find and fix once I thought about what was going on, and could look at a sprite on the screen and fiddle with its data.

There was also a bug where the variable height mode was not working properly, because I had mis-plumbed some registers, rendering it impossible to set the height of sprites to anything other than the normal 21 pixels. I have rolled that fix in to the next build as well.

Just these changes, allowing much bigger sprites, should increase the usefulness of sprites quite a bit.  A tall or wide character now only needs a single sprite, hopefully leaving more sprites free for other things.  Once the rest of the MEGA65 is implemented, I might look at adding more sprites, but for now I am concentrating on making the ones we have more useful and interesting.

Sprite/foreground collision is still not working, so I have also added an "xray mode" to the VIC-IV, where instead of showing the normal display, it shows foreground, background, border and sprites all as a single distinct colour.  This is enabled with a physical switch on the FPGA, to make it easy to debug.  This change is in the build I am currently synthesising now.

I also took the opportunity to add some new extended sprite features, based on my reading about how Amiga sprites work, and also how they were used to create a tiled 16-colour background in some games on the Amiga.  However, I have not copied the Amiga functionality directly, and instead created something that achieves the same results, plus some extra opportunities for abuse.

First up, I added a flag that causes a sprite to be tiled horizontally, instead of being drawn only once.  This is a simple kind of hardware-assisted sprite multiplexing. Combined with 64-pixel wide sprites, it will hopefully be useful.  For example, having a full-width parallax background can now be easily done using a single sprite.  Again, this should leave more sprites free for other things.

Second, I have added a flag that causes a sprite to modify one or two bits in the colour otherwise to be displayed.  That is, each sprite can now be selected to modify one bitplane (or two in multi-colour sprite mode) of the output.  This works for other sprites, providing something effectively the same as sprite-bonding on the Amiga, but allowing the combination of arbitrary numbers of sprites to yield arbitrary colour depths.  It isn't quite the same, because the "master" sprite that is being combined with the bitplane-modifying sprite(s) has its colour selected in the normal way, so a transparent pixel in that sprite will always translate to a transparent pixel when displayed.  So this part of the functionality, while implemented differently to the Amiga, is generally similar.

What I have also done, because it is trivial from a hardware perspective, is to allow sprites in bitplane mode to modify the colour of the non-sprite elements of the screen.  This is something rather different, and offers all sorts of opportunities for abuse.  You could use it to easily draw shadows or highlights on a display, just by carefully setting up the palette and using a sprite in the shape of a shadow.  But you could also use it to provide extra bits of depth to a regular bitmap display, without incurring the memory cost of making the whole display deeper.  For example you could make something that is similar to FLI or one of the other VIC-II bad-line tweaked modes, but with a completely static display.  There is ample opportunity for demo effects here as well, especially since the bitplane modification is an XOR, so you can get a bit creative with the end effect.

All these changes are in the model that I am currently synthesising now. Hopefully they will all work, and I will have a few minutes free some time soon to try them out and post some screen shots of strange looking sprites.