Entry tags:
Gameboy Printer Simulator part 2: the software
Before I completely forget about it, here's the rest of that Gameboy Printer emulator post. This time, it's about the software.
( Part 2: the software )
( Part 2: the software )
Entry tags:
Gameboy Printer simulator part 1: the hardware
Making some sort of Gameboy Printer simulator has been on the projects list for quite some time now - ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
pewterfish may remember me poking at it once or twice while in the Brighton house. The idea simmered on the back burner for many years until I saw a couple of things recently and a lot of stuff just clicked together.
Three random updates in one!
Tuesday's discovery was that erasing part of the flash chip your code is executing from is a Bad Idea. Not because I'm erasing the code that's being executed (I'm actually erasing a completely different part of the chip), but because while the chip is carrying out a sector erase it doesn't respond to reads for different sectors.
For added fun, when the processor presumably threw a bus error exception, it failed to run the exception handler because that's also located in the same flash chip. So it just reset and left me staring at the startup output wondering how my upload function had morphed into a crash-on-demand function. Fortuantly it didn't also become a brick-on-demand function.
Wednesday's annoyances were mainly made up of finding piddly little bugs in my code, with each bug fixed unearthing a new one somewhere else (most of these are due to other chunks of code being incredibly picky about parameters). And due to how the hardware is structured each time I recompile the code it takes about 15 minutes to re-flash everything. This isn't helped by the system deciding to sulk every fourth upgrade or so.
On the plus side, I managed to deal with all the flash-related issues from Tuesday. This means that about half of the stuff I'm working on now all behaves itself. As long as you don't look at it funny.
And today's achivement was wandering down to production to see if I could prise a particular component out of them, and somehow managing to end up with two fully populated system boards to play with. Result!
For added fun, when the processor presumably threw a bus error exception, it failed to run the exception handler because that's also located in the same flash chip. So it just reset and left me staring at the startup output wondering how my upload function had morphed into a crash-on-demand function. Fortuantly it didn't also become a brick-on-demand function.
Wednesday's annoyances were mainly made up of finding piddly little bugs in my code, with each bug fixed unearthing a new one somewhere else (most of these are due to other chunks of code being incredibly picky about parameters). And due to how the hardware is structured each time I recompile the code it takes about 15 minutes to re-flash everything. This isn't helped by the system deciding to sulk every fourth upgrade or so.
On the plus side, I managed to deal with all the flash-related issues from Tuesday. This means that about half of the stuff I'm working on now all behaves itself. As long as you don't look at it funny.
And today's achivement was wandering down to production to see if I could prise a particular component out of them, and somehow managing to end up with two fully populated system boards to play with. Result!
On mice and men...
Logitech spins 'revolutionary' free-wheeling mouse
Mouse maker Logitech today introduced its first input device with a freely-rotating scroll wheel, aiming the system at gamers looking for fast weapon changes and Microsoft Office users who need to be able to whizz through long documents...
But flip a switch on each laser-guided gadget's base, and the wheel runs freely. The alloy-made wheel is weighted to spin for six seconds, Logitech said...
Oddly enough, my aging Intellimouse Explorer has a similar design on the wheel. It requires very little pressure to spin and doesn't so much click as gently bump. And you can set it spinning for about half a second.
It's a lot better designed than the current version, which has a heavily damped wheel that doesn't click at all. Which, while it may be nice, is hopeless for trying to change weapons in Unreal Tournament.
Plus it fits my hand nicely, and has drivers that actually work.
Say what you like about Microsoft, they know how to make mice.
New house, new people, new DVD, dead computers
Right, well yesterday I moved in to my student accomodation, and upon unpacking Achilles (the Win2k beast) I discovered that the case fan had not survived the car journey and was now making all sorts of loud grinding noises. Ah well, it's not like that fan was making the difference between happy computer and melted computer.
Shortly after,pewterfish and I powered down the firewall to run some Cat5 to my room, and upon powering the firewall back up it started making the same nasty grinding noises, this time from the power supply. Is making loud grindy noises an infectious disease among fans or something?
So, after a trip to Maplin and a suitable period of menancing electrics with a soldering iron, both fans were replaced with nice new quiet ones. And the firewall was powered back up, only to discover another fan was making that grinding noise as well. One bit of ferreting around later, and the firewall is now happily running without one of its many fans. Whereupon we discover that it's not booting, and the reason for it's refusal to boot appears to have something to do with /var/log disliking the power cycle. I hope this isn't a sign of things to come.
Anyway, the rest of the kit is behaving itself, and I've been hacking a GameBoy Printer emulator of mine hooked up to the parallel port on Odysseus (Slackware 10.1). The trouble with trying to do something like this on anything bar DOS is the operating system will quite happily not give your program cycles when the data comes in, and so you end up missing anything from bits up to whole bytes. This isn't a problem if you can drive the clock, however when printing the GameBoy like to use it's internal clock to send the data. Which means you run into the timing problems.
What else... Nick and Dan have succeded in getting me hooked on Firefly. I must admit, they appear to have one of the more accurate renditions of space physics. The Alliance cruisers are decidedly non-aerodynamic, the drives are completely silent (except of course if you're inside the ship or in atmosphere), and the insides of the ships have an absence of pointless flashing lights. It is a shame that the drives are always running, and that the ships appear to be as manouverable as the plot requires, but apart from that it's very good. I like the mix of new and old technologly as well - one of the things that you don't expect in a sci-fi series are people still riding horses.
Anyway, I'm off to go and make something to eat tonight, and then probably to watch more Firefly. Laptops make very nice DVD players.
Shortly after,
pewterfish and I powered down the firewall to run some Cat5 to my room, and upon powering the firewall back up it started making the same nasty grinding noises, this time from the power supply. Is making loud grindy noises an infectious disease among fans or something?So, after a trip to Maplin and a suitable period of menancing electrics with a soldering iron, both fans were replaced with nice new quiet ones. And the firewall was powered back up, only to discover another fan was making that grinding noise as well. One bit of ferreting around later, and the firewall is now happily running without one of its many fans. Whereupon we discover that it's not booting, and the reason for it's refusal to boot appears to have something to do with /var/log disliking the power cycle. I hope this isn't a sign of things to come.
Anyway, the rest of the kit is behaving itself, and I've been hacking a GameBoy Printer emulator of mine hooked up to the parallel port on Odysseus (Slackware 10.1). The trouble with trying to do something like this on anything bar DOS is the operating system will quite happily not give your program cycles when the data comes in, and so you end up missing anything from bits up to whole bytes. This isn't a problem if you can drive the clock, however when printing the GameBoy like to use it's internal clock to send the data. Which means you run into the timing problems.
What else... Nick and Dan have succeded in getting me hooked on Firefly. I must admit, they appear to have one of the more accurate renditions of space physics. The Alliance cruisers are decidedly non-aerodynamic, the drives are completely silent (except of course if you're inside the ship or in atmosphere), and the insides of the ships have an absence of pointless flashing lights. It is a shame that the drives are always running, and that the ships appear to be as manouverable as the plot requires, but apart from that it's very good. I like the mix of new and old technologly as well - one of the things that you don't expect in a sci-fi series are people still riding horses.
Anyway, I'm off to go and make something to eat tonight, and then probably to watch more Firefly. Laptops make very nice DVD players.
(no subject)
There are some quite marked differences between hardware and software buffers. I've just swapped the onboard AC'97 sound for a SoundBlaster PCI128, which has failed to solve my stuttering sound problem (well, stuttering system). It has, however, changed the symptons. Previously the sound would stutter.
Now it loops.
Now it loops.