Monday 31 August 2009 at 9:05 pm
Alright, a quick update on where the StackBook is at.
The Screen:
Have cut up the tracks on a small piece of protoboard that I still need to cut down to the right size. This will adapt the screen to two 10-pin headers (power/control lines, data lines). Need to also add the two more headers to the main board.
The main board:
Add (a socket for a) crystal oscillator already!
The Ethernet module:
I have the 3.3v regulator and I've taken another look at the pinout. I need some pin headers here to socket this thing in - I don't want to solder it down. Jaycar doesn't have them, apparently Aztronics do, but I have to get out there some time.
The Keyboard:
Spent 15 minutes searching the web, then found that my usual supplier of stuff from Hong Kong has
this, so I ordered it. Should be OK once I remove the case - by the dimensions looks fullsize, but I can of course make the laptop shorter. Don't want to make it too small though - and i should leave enough room to fit some interesting stuff in. Just wish I could make it a little smaller as the screen is not huge. Oh well, guess I'll have to figure something.
The case
Probably perspex. Need to find some laptop screen hinges somewhere.
Power:
Hmmm. At the moment, it's using USB power through a 10-pin ISP socket. Should add a DC jack with a LM7805LD (I've got one somewhere here...), and feed 6v into it. Need to at some point get a 5v boost converter and make this thing run off 18650s... and work out charging etc. One of the A-D pins (spare from the LCD) can be connected to the raw battery input to get the voltage (which since it is lower than Vin is fine) for battery metering.
Sockets:
Probably 10-pin ISP headers (for both chips), power, a serial port, ethernet, and maybe a "misc port" with some wires / I2C bus on it. First person to suggest IEC bus gets something thrown at them :)
Other stuff
Needs a stupidly loud buzzer. Or rather, doesn't. Though it will be getting more LEDs - and I probably should move the blue power one when I have a keyboard.
Also, soft poweron... I wonder how low power I can make the AVR...
Thursday 27 August 2009 at 10:40 pm
... or how to get a C64 onto a 22" monitor.
I bought
this video to VGA converter from DealExtreme for usage with the C64. In short, it works quite well - there's not much visible flickering, everything looks alright. No rolling picture or other horrible problems caused by the C64's video output rate. Only issue is there is some interlacing on the image - but I haven't found this to be a problem in gameplay, it's only slightly evident in text mode.
There is a bit of colour fringing though - quite bad in the blue area - but I'm not incredibly sure to what extent it is just the C64's video output hardware making a messy signal - as there is some similar fringing on a TV. As I said before - many corners were cut in the C64's video hardware.
Compare that to the iREZ ReelEyes video capture card image, which seems to have a little less, but still some fringing...
I'd say that this thing's worth the money though.
Edit: Probably should clarify about the colour fringing: it only happens when dark colours and bright colours are right next to each other. In the blue texture there's alternating blue and black lines for dithering and that sets it off badly - this is a worst case scenario. Normally you don't see it (look at the light tile area) - but this sets it off badly. I'll take more pictures later.
Tuesday 25 August 2009 at 10:55 pm
Rule #2 of electronics according to gm:
Just because it works (or appears to) doesn't mean it's right.
I was experiencing problems with the third segment of the display - namely anything drawn on it going onto the other two and general pixel corruption caused by the third panel not being activated in the correct sequence. Remember last time, when CS1 and CS2 had to be swapped to make the graphics appear the right way round? It wasn't because they were wired up wrong. This is the chip select sequence:
__inline__
void ks0108::SelectChip(uint8_t chip) {
//static uint8_t prevchip;
if(chipSelect[chip] & 1)
fastWriteHigh(CSEL1);
else
fastWriteLow(CSEL1);
if(chipSelect[chip] & 2)
fastWriteHigh(CSEL2);
else
fastWriteLow(CSEL2);
}
Can you see what this assumes about the LCD, and why it would work with CS1 and CS2 swapped if this assumption was wrong?
This display has active-low CS lines - in other words the chip is selected when the enable line is grounded. In the previous case where we were only driving the left 128 pixels, when chip 1 was supposed to have been selected, chip 2 was, and vice versa. However, attempting to use 3 chips with this results in something different - chip 1 is off when selected, chips 2 and 3 are on - very very bad. Hence why the stuff for chip 3 was being drawn over the other two. So after fixing the fastWriteHigh/Low problem and adding an if statement to turn chip 3 on and off, it worked.
I'll release the modified ks0108 code when I've got it cleaned up a bit - it's a little hackish at the moment - and I've probably broken stuff in the code for other setups. But anyway, I can now draw to the whole 192x64 LCD.
Tuesday 25 August 2009 at 11:49 am
It was quite clear from the start that the character LCD would not be anywhere near enough screen space for anything serious.
So something had to be done. Anyway, you probably know about
what happened to the previous gLCD I had.
Anyway, I have a nice new 192x64 LCD that is not only bigger than the old one, it came with a testing board, and has it's magic smoke intact. So let's wire it up:
(Remember what I said about improvising?)
The testing board is pretty good - power is taken from the USB port - and there's space for a pin header on the left which you can solder a programming header on and reprogram the chip. Unfortunately the chip is a 16F57 - rather low end, but it serves the purpose.
So let's get it onto the breadboard.
There's an Arduino library for the KS0108 controller (again, nearly all of these GLCDs use the same chip or a clone of it - but you have to be careful as there's two different pinouts, and the 192x64s are different to the 128x64s.
Hey, it works.
Except when it doesn't.
After much annoyance, the problem was eventually traced to a) Chip Select 3 was floating, and b) there were no capacitors on the crystal.
If you don't know what Chip Select lines do on one of these LCDs: it's simple. The 4 ICs on the back of the display are a KS0107 and 3 KS0108s. The KS0107 controls the 64 row inputs and the general LCD. The KS0108s control each lot of 64 columns: 192x64 LCDs have 3 of them, 128x64 LCDs have 2 of them. Since we can only write to one at a time, we have enable lines for them. But the Arduino library that I'm using only seems to be set up for 128x64 screens. After I put a wire in to pull CS3 high, the LCD panel started behaving somewhat more. When I switched it to the internal oscillator, the garbage drawing problems were fixed. I need to put two caps on the crystal. Side effect of the internal oscillator is that the chip is now running at 8MHZ - but it's not the slowdown that makes it more reliable as I already turned up the delay and that didn't fix things.
Seems, though, that I had CS1 and CS2 swapped. They seem to be right now (you can tell because the 64x64 blocks are in the wrong order).
We're going to need a better font than Arial 14 point though (Helvetica > Arial anyway...). For this I used
GLCDFontCreator, a handy java applet that not only can create new fonts, but can convert existing ones.
To do this, go to File->New Font
Rename the font, select the font you want to convert, and for a pixelfont, pick the right size. Hit OK, then use Export -> Export Font to save it as a .h file.
You may notice that I named the font f04b03 - this is because identifiers in C cannot start with a number. The font being converted is from
this page.
Tuesday 25 August 2009 at 10:46 am
I had the problem of the power brick for the pictureframe not working. I'm not entirely sure why, but I think it was a loose connection inside (the only power brick for the G3 I had left had a huge crack through it - I sold the last good one with the 3400...).
But I also had a PowerBook G4 power brick that had a short right up near the plug. Since they're both the same voltage, I cut the cables and spliced them in. And it worked - so now I have a nice smaller power brick for the G3 Pictureframe that works properly.
Monday 24 August 2009 at 7:24 pm
Alright, so on the weekend, a friend and I went through most of his C64 stuff, and I am now in possession of a C64C, 1541v2, datasette drive, two joysticks (with non-working fire buttons) and an XM1541 cable (I don't have a parallel port on anything though).
Also, I (finally) built the C64 video out cable... but I still don't have the S-Video plug on it yet. This is what it looks like so far:
And here's some photos of the whole setup - using my digital pictureframe (PowerBook G3 with a PCMCIA video capture card) for a monitor as I don't have anything else with composite / S-video in. The video capture card has a few issues syncing with the C64's video signal - but it gets there after a few tries (loading up the video settings window and closing it so the digitizer is reset). This stems from the fact that the C64 actually outputs 50.12Hz (985248/63/312) instead of 50Hz that PAL wants. Had a look at the specs of the video to VGA converter, it supports 800x600 at 60 and 75Hz and 1024x768 at 60Hz. Interesting - especially seeing as it has PAL input.
Also, I've *got* to find a way to get an external keyboard into the C64... it takes up too much room on my desk...
Game being played is
BOFH: Servers Under Siege.
Todo:
Wire S-Video plug onto cable.
Build an
XU-1541 cable (USB to IEC serial).
Get the fire button working on the joysticks.
Saturday 22 August 2009 at 02:06 am
Ok, so I guess the LCDs didn't quite get into the post fast enough to make it here on Friday. I expect they'll be here Monday/Tuesday.
Anyway, I installed the full 76GB X-Plane on my desktop... and you thought Crysis had a large install! My GTX275 has been running perfectly (there's some texture bugging issues, but I think that's an issue with the beta version of X-Plane instead - I didn't get it before I updated to the beta). I have a Logitech WingMan Formula GP steering wheel (why is a wheel named WingMan?) set up to provide it's pedals as rudder pedals (for some reason on Windows, you only get the axis that is a combination of the two pedals, but on Mac, you get the left pedal, the right pedal and the combination axis... odd), as well as my Saitek Cyborg 3D joystick.
Also, I found out something interesting today - some models of AVR are capable of addressing external SRAM. So the final StackBook will almost certainly not have an ATMega32 in it - as it is not one of those models. I'm going to need more than 2K of RAM.
I think that's about it.
Thursday 20 August 2009 at 11:29 pm
Some of you may have been following the annoying time I've been having with my Gigabyte GTX275. BIOS version F3_C came out today - and it appears to have fixed the "no video on boot" issue completely. I've rebooted many times since then and the problem's fixed. So I guess it's time to possibly play with a bit of overclocking, possibly install more OSes etc now that I actually see the BIOS screens. So, no nasty legal letters to MSY reminding them of their obligations under the Trade Practices Act to actually do something about defective gear.
In other news, the LCDs have been shipped, and the DX package containing the video converter has shipped.
Unfortunately I have been told that some video converters will not work properly with the C64 because it doesn't actually output proper PAL but a signal at 50.12Hz instead of 50 - but some are perfectly fine. So I just hope mine works - or I guess it's going back to where it came from.
So yeah, the StackBook project is stalled, waiting for a LCD, my graphics card works again, and I still haven't wired up the C64 video cable. Or given you all a schematic for it.
I'll get round to it...
Monday 17 August 2009 at 10:18 pm
On the electronics front:
Stackbook: Haven't had the time to do particularly much. Got a 3.3v regulator, and a few 10Kohm potentiometers.
C64 video cable: Also, on the other front, I have some stupidly thick coaxial cable for wiring in the C64 cable - Jaycar guys didn't have the reasonably sized stuff. Seriously this stuff is way too thick - 5mm in diameter.
Drew up the circuit diagram today, I think I'll leave the audio in pin alone. I have the 8-pin DIN plugs, but unfortunately they are DIN 41526 8 pin ones (purchased from Electus - same ones Jaycar have), not 41524s. The difference lies in the positioning of pins 7 and 8 (but only those pins I believe) - which fortunately are +5v and N/C - so I can just pull them out and pretend they don't exist. 5-pin DIN plugs are what is more commonly used - but I need that centre pin. Pinout is
for the C64's video cable. The S-Video to VGA converter is reportedly "Ready" at DX, so I should see it in about a week and a half. This should be fun :)
On a related note, looked up the part number for the large chip on the board marked "Fastloader". It's an 8K EPROM. (UV-erasable - one E not two). It's probably a replacement for the 1541's code that speeds up... loading.
Other projects:
I am now in posession of a Logitech Wingman Extreme Digital, which has a game port connector. It's going to be converted to USB. Opened it up and the whole thing looks like it'd be easy to just replace the circuit board in there with an ATMega8 and some already written code (mJoy or something like that). I didn't take a proper look though - I suspect it may have USB in there because it's sure got a lot of circuits for a joystick - but it is doing digital down the gameport.
I might get time to solder the RCA plugs onto the C64 cable tonight... if not, tomorrow night then.
Oh, and the
thread in the Geocache Navigator Forums seems to have gained a few replies, the first a form pasting by someone, and the second a message of "we can no longer afford to provide the service in the current economic climate". I'm not sure that the server industry has been terribly affected by the recession... but it seems to be a popular excuse of late. What do you think?
Saturday 15 August 2009 at 11:25 pm
Alright, I've had enough here, I'm just going to order another LCD and fix this one when i have the new one and know what to expect...
Generally stuff doesn't ever work again once it has emitted smoke, so I'll just put this one down to experience.
I had another look at
the datasheet. Look at the block diagram, note how the arrow on Vee is pointed into the chip... hope others don't make the same mistake.
Oh well, guess I did this so you don't have to :)
Saturday 15 August 2009 at 9:51 pm
A little more poking round reveals that said capacitor is an output filter cap, not the one that it actually uses in the voltage inversion chip.
So I carefully desoldered it. (carefully meaning soldering iron + long nose pliers, one side at a time :) ).
I'm not actually sure why it blew up when I connected the output voltage to ground... since that was just directly shorting it.
Anyway, that boosted the output voltage of the chip up to about -2.17v from -1.5v, so we're seeing something on the LCD now.
But now I can't get the AVR the were plugged into to program. I think (hope) this is unrelated and I've just pulled a wire somewhere accidentally.
Edit: Yes it was - there was a loose wire. Gotta love breadboards for that reason :|
Saturday 15 August 2009 at 11:13 am
I took a look at the board today and found, on the right edge, a nicely bulging SMD capacitor. It's C62, and it's marked C475.
Later edit: 6.3v, 0.475 microfarad - if i'm reading it right according to
here - however C caps (the 6.3v part) are "rare" according to the document I read. There's a cap below it marked the same - I guess i could try to get my hands on a capacitance meter and measure that one - I do need a new/better multimeter...)
This page says otherwise - 16v, and 47*10^5 picofarads (47 microfarads) - that sounds better at least - because it's electrolytic as the board has a + sign next to it. I'd say this one is the one I'd trust.
It's right next to U6, which is a
HTC TJ7660 C_835 which is a simple chip to invert voltages.
But the cap isn't the cap used by the converter - it's connected between the output and ground - probably to clean up the output waveform. I need a scope to really see what's going on here I guess, but my multimeter reports 1.5v where there should be 5. Time to do some SMD soldering I guess (after getting the components).
It still smells bad in here :|
I connected the negative voltage out pin straight to the contrast in pin and I see something there - it looks like a few horizontal lines, some sign of life.
I may just buy another LCD - a 192x64 one.
In my annoyance, I forgot to mention - it's a second screen - a graphical one with 128x64 pixels.
Saturday 15 August 2009 at 01:36 am
More dodgy datasheets.
Turns out that "supply voltage for LCD drive" is not actually a voltage you have to input, but a -5v output that is connected to the other pin via a voltage divider.
Yes, there was smoke. From a $16 part that I spent about half an hour soldering wires to.
Hmmm...
Friday 14 August 2009 at 11:07 pm
It has recently come to my attention that the quite awesome
Geocache Navigator has become payware on the Nokia devices (it was previously free for those who don't know). While sometimes, software developers have to pay the bills, the Nokia version is 30 euros... WTF!?
30 euros, for those who don't know offhand, is about $50 Australian dollars. To compare things - I recently purchased version 9 of X-Plane. That cost me a total of $62.58 Australian... including shipping - and that was when it was $39 US - it's now $29. Please could the developers of Geocache Navigator explain how their product was either a) harder to write or b) is worth more than the world's most advanced flight simulator. It's also not like there's a small market for geocachers either - in fact, I wonder how it compares to the flight sim community?
Of course, they're being nice to us by letting us "upgrade" for 15 euros - still $25, and IMO, about $15 more than the app really warrants. I'm not averse to paying for software - I do legitimately purchase stuff if it's worth the price being charged. So if it was $5 or $10, I'd buy it, because I'm not going to deny that it's a useful app. But $50? That's excessive - I could probably find a Garmin eTrex for that if I looked hard enough...
A quick look on the iTunes App Store reveals equivalent apps - Groundspeak's Geocache app going for US$10 (~$12 AUD as I write this). Geosphere is $8. Geocaches Near Me is $0.99. Geopher Lite is $1.99.
In conclusion: you have angered a few software developers who might just be planning on writing something right now.
Friday 14 August 2009 at 10:35 pm
If you haven't been following:
Part 2 and
Part 1
Alright, so it's getting to be about time to start moving this thing off a breadboard.
I've begun the task of soldering up a motherboard. First a 10-pin programming header was added. This is for programming, but more importantly power. A power LED was then added, but a high value resistor was used to cut back the power draw.
After putting an ATMega32 in the socket, the programming was tested and it actually works (always good). However, it had no I/O pins (yet), so it's back to the breadboard because I didn't have any to solder in. $30 of them just came from Electus and I've had to start a second box of electronics junk - I've got a _ton_ of IC sockets, pin headers, plugs, IDC connectors etc etc (and a solder sucker - the "undo" button for soldering).
Of course, we're going to need some way of outputting the data. For this we will require a screen. This came from an online electronics store in Hong Kong (like most of my box of junk, and half of the random gadgets here) - Sure Electronics' creatively-named
2002 LCD Module black character no backlight.
Reading the datasheet tells you it has a "KS0076B" controller chip. This may look obscure from the Google results - but it's also much more commonly known as the hd44780 - and that chip is in almost every character LCD out there. The Arduino library for it is called LiquidCrystal.
I didn't have pin headers at the time, so I soldered LEDs across the header, then trimmed all the legs. Works reasonably well. The key to success in electronics is always improvisation.
After making a 16-pin cable to replicate this over to the breadboard, I messed around quite a bit but still couldn't get the display to output anything. I tried inputting power to the connector on the left, bridging the solder division to enable it, but still nothing. Hmmmm. Then I re-read the datasheet and figured out that in Section 4, the parameter "VDD - V0" having a range of 4.4 to 5.1v actually means that this voltage is negative relative to VDD. In other words, that pin is to be provided with -0.1 to 0.6v for a 5v input. Since 0 is within that range, I just tied the pin to ground (I should use a 10k potentiometer to set contrast, I'll rewire it when i have one). And suddenly the screen came on. After a bit more fiddling, it even displayed something!
I wired up the 16-pin ribbon cable before I'd read the specs for the LCD though. You actually don't need all 16 pins. Read
the datasheet for further details: but in short, pins 1-6 and 11-14 are all you really need. So I split the cable into 6 and 4 pins, then crimped a 16-pin connector with them in the right place. After some messing around, it works!
The point of this was so that I could put a smaller 10-pin header on the motherboard instead but still have the LCD work. Which I did - and put it in the top left, which by necessity, is closest to port A. Unfortunately this is the analog input port... but oh well. It's closest, and there are still two analogue input lines available. I also wired the pins into them in the order for which it is physically easiest - it just took a bit of multimeter poking to figure out what was what so I could tell the software what went where. One more pin was saved from the AVR by simply grounding the R/W line - we don't plan to read from the LCD display. I am told by a friend of mine, though, that reading back from it is useful because you can check the busy flag and slow down the data transfer if it's not ready, but this display seems to cope fine. YMMV.
Anyway, it works (which is always good):
And a close-up view:
I think I need to get a
less anger-
inspiring test sentence...
Thursday 13 August 2009 at 6:16 pm
Firstly we need to get the chips communicating. This is done by I2C (aka TWI).
Tips: It's always on the same pins (SDA and SCL). Remember the pull-up resistors.
Test Program:
On the CPU:
#include <Wire.h>
void setup()
{
Wire.begin();
pinMode(1, INPUT);
}
void loop()
{
Wire.beginTransmission(4);
Wire.send(digitalRead(1));
Wire.endTransmission();
delay(100);
}
On the auxillary controller:
#include <Wire.h>
int ledPin = 1;
void setup()
{
pinMode(ledPin, OUTPUT);
Wire.begin(0x04);
Wire.onReceive(receiveEvent);
digitalWrite(ledPin, HIGH);
delay(100);
digitalWrite(ledPin, LOW);
delay(100);
}
void loop()
{
delay(100);
}
void receiveEvent(int howMany) {
char c = Wire.receive();
if (c == HIGH) {
digitalWrite(ledPin, HIGH);
} else {
digitalWrite(ledPin, LOW);
}
}
And here's two pictures of two ICs doing the job of none.
Thursday 13 August 2009 at 5:46 pm
It's sure been a while since my last entry, hasn't it?
Quick progress update:
- zTower has been re-written in C++ and is now looking much nicer.
- Stack Underflow has gotten slightly further - but is still not quite ready.
- GPSTool still is how it was :)
Anyway, time to announce a project. The name I have for it at the moment is the "StackBook" - it's not great, but you think of something better.
So what is this thing?
In short, it's an ATMega32-based ultra-low-power mobile computing platform. I'm not claiming that it'd be practical - but it'd sure be fun to build your own computer from the ground up, right?
The general layout of the architecture is that there will be an ATMega32 running the main guts of the thing, with an ATMega8 handling other tasks. The two will communicate with each other, and other devices onboard with I2C (or as the trademark lawyers want us to say : TWI). The ATMega32 is likely to, however, be replaced with something bigger because it only has 2K of SRAM which i can see getting to be a problem.
Anyway, the arduino environment and header files have been hacked up to handle the extra chips - I will upload changed files soon.
