Another very quick post, just to say that we are now able to flash the MEGA65 bitstream into the flash on the FPGA boards. This means that from turning the power on, to seeing Kickstart takes only about 3.5 seconds -- and some of that delay is actually waiting for the monitor to turn on. If the monitor is already on, it can be quite close to 3 seconds, and possibly even a little less.
Power off to seeing C65 READY prompt, allowing time for the monitor to wake up from deep sleep took no more than 4.6 seconds.
This is very pleasing progress, and there is some scope for improvement. We are currently only driving the flash at 22MHz, which at 4 bits wide, and with a ~4MB bitstream. This means that loading the configuration currently takes (8*4x10^6) / 22x10^6*4 = 32x10^6 / 88x10^6 seconds = ~0.37 seconds, plus some overhead for the signaling between the FPGA and flash. I don't currently know the ratio of the overhead. In any case, it might be possible to shave another 0.1 second or so off the 0.37 second figure. Given that the total programming time on the FPGA at present is 1.7 seconds, this suggests that it might actually reduce the start time by more like 0.3 - 0.5 seconds. We will see.
The other thing we can do to improve boot time is to load the C65 ROM from flash instead of the SD card, or otherwise to reduce the SD card setup time.
I tried to find out exactly how long a real C64 takes to power on. My recollection is 1 - 2 seconds. It would be nice to match this, but I am already happy with < 5 seconds, compared to the about 15 seconds that it took loading the bitstream from the SD card. At some point I will post a video showing a MEGA65 booting from flash.
Making a C64/C65 compatible computer
Friday, 25 September 2015
Thursday, 24 September 2015
Making speed control easier
Just a quick post today about a couple of enhancements to make it easier to select CPU speed on the MEGA65:
1. The CPU now defaults to be locked to 48MHz, so that it is as fast as possible by default.
2. To enable slower speeds (under C128/C65 speed control register direction): POKE0,64
3. To force the CPU back to full speed: POKE0,65
4. The ASC/DIN key on a real C65 keyboard will have a similar effect to the above.
The POKE 0 system uses a special over load of the CPU DDR port at $00 - if $40 or $41 are written, then the DDR is not changed, but instead the CPU speed control function is followed instead.
1. The CPU now defaults to be locked to 48MHz, so that it is as fast as possible by default.
2. To enable slower speeds (under C128/C65 speed control register direction): POKE0,64
3. To force the CPU back to full speed: POKE0,65
4. The ASC/DIN key on a real C65 keyboard will have a similar effect to the above.
The POKE 0 system uses a special over load of the CPU DDR port at $00 - if $40 or $41 are written, then the DDR is not changed, but instead the CPU speed control function is followed instead.
Monday, 21 September 2015
MEGA65 being controlled by a real C65 keyboard
Going further from the last post, together with Sy2002, we can now control a MEGA65 using a real C65 keyboard. This works by having the special input PCB (the MEGA65 PIC board) that we designed accept the C65 keyboard ribbon cable, and talk to the FPGA board via one of the PMOD connectors. While we knew we were at least somewhat close to achieving this, with some round-the-clock effort between Australia and Germany, it all came together this morning, as you can see in the following video:
We still have yet to test the behaviour of the C65-specific keys, which use a separate column signal compared with the C64 ones, but there is no reason why it shouldn't work, and any bugs should be fairly straight-forward to find and fix as the logic surrounding it is very simple.
I also tried to laser-cut some more test pieces for the MEGA65 laptop prototype, but the laser cutter wouldn't play nicely, and just kept engraving my MDF sheets instead of cutting them, and Corel Draw kept refusing to export all the paths to the print file. Very frustrating. I might have a go again later in the week if I get the chance.
We still have yet to test the behaviour of the C65-specific keys, which use a separate column signal compared with the C64 ones, but there is no reason why it shouldn't work, and any bugs should be fairly straight-forward to find and fix as the logic surrounding it is very simple.
I also tried to laser-cut some more test pieces for the MEGA65 laptop prototype, but the laser cutter wouldn't play nicely, and just kept engraving my MDF sheets instead of cutting them, and Corel Draw kept refusing to export all the paths to the print file. Very frustrating. I might have a go again later in the week if I get the chance.
It moves!
... the cursor that is, by the new keyboard interface.
While I have been fairly busy with other things, I managed to implement and test the VHDL for allowing keyboard input via a simple protocol on one of the PMOD connectors on the FPGA board. This means that the PCB that we have designed for connecting a real C64 or C65 keyboard to the FPGA board will hopefully soon work. This will be very nice.
Basically there are 8 data lines on a PMOD connector, and there are five PMOD connectors on the Nexys4 board. We are using just one at the moment to talk to the keyboard/joystick/cartridge port board for now -- this will change later, but we just want to get keyboard and joystick input working nicely first.
On that PMOD, we have one line as clock, another to indicate start of sequence, and then four bits of data from the PCB to the FPGA board. The last two bits allow for a half-bandwidth back-channel to the PCB, for example to set keyboard/diskdrive LED status, and to set pins on the cartridge port.
The microcontroller on the PCB still needs to be programmed to support this, but I did manage to poke at the PMOD pins with my multi-meter set to current on the clock and data pins and make the MEGA65 think that the right cursor-key was being pressed. This was very nice to see :)
Unrelated in terms of functionality, I also took the opportunity to improve the timing closure in a few places (hopefully I haven't broken sprites in the process :), and change all mention of C65GS and G65 file extensions to MEGA65 and M65, reflecting the new name of thing.
So while this is a rather boring post visually, it does mark a significant step towards having the MEGA65 living in a real case with a real keyboard -- whether that be the desktop or laptop versions.
While I have been fairly busy with other things, I managed to implement and test the VHDL for allowing keyboard input via a simple protocol on one of the PMOD connectors on the FPGA board. This means that the PCB that we have designed for connecting a real C64 or C65 keyboard to the FPGA board will hopefully soon work. This will be very nice.
Basically there are 8 data lines on a PMOD connector, and there are five PMOD connectors on the Nexys4 board. We are using just one at the moment to talk to the keyboard/joystick/cartridge port board for now -- this will change later, but we just want to get keyboard and joystick input working nicely first.
On that PMOD, we have one line as clock, another to indicate start of sequence, and then four bits of data from the PCB to the FPGA board. The last two bits allow for a half-bandwidth back-channel to the PCB, for example to set keyboard/diskdrive LED status, and to set pins on the cartridge port.
The microcontroller on the PCB still needs to be programmed to support this, but I did manage to poke at the PMOD pins with my multi-meter set to current on the clock and data pins and make the MEGA65 think that the right cursor-key was being pressed. This was very nice to see :)
Unrelated in terms of functionality, I also took the opportunity to improve the timing closure in a few places (hopefully I haven't broken sprites in the process :), and change all mention of C65GS and G65 file extensions to MEGA65 and M65, reflecting the new name of thing.
So while this is a rather boring post visually, it does mark a significant step towards having the MEGA65 living in a real case with a real keyboard -- whether that be the desktop or laptop versions.
Saturday, 12 September 2015
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.
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.
Thursday, 10 September 2015
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.
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.
Subscribe to:
Posts (Atom)