TheMole

The question is a bit confusing, but I am guessing you mean your host compiler is gcc 4.6.3? Gcc 4.6.3 should compile gcc 4.4.0 just fine (keep in mind you're compiling the compiler with a compiler... ). As for how to patch, you should be able to use Tursi's instructions for that without any major modifications (I think you're using Linux, if I remember correctly, so some details will be different but the overall process should be similar enough).

Very nice, hope you find that last bug soon.

Small update: Somewhat improved collision detection (all the collision points are there, but the location of them isn't perfect yet) Alex can now turn left and right (I simply swap the sprite pattern table pointer to a mirrored version when he changes direction) Slightly tweaked physics, Alex can now no longer reverse direction in mid-air on a normal jump Added punching animation and the ability to punch the blue blocks in the level. Still some visual glitches here due to rounding errors when calculating the part of the screen to refresh (you can see it in the video at the 30 second mark) Next I plan on cleaning up the codebase a bit, fixing the smaller bugs. Then I'll release a disk image for who's interest in playing with it. After that, I'll have to refactor everything to work with disk files instead of storing all the graphics in one big binary. Currently the game fills nearly the entire 32k, but almost half of that are patterns that can easily be loaded into VRAM and then discarded from memory. I'll also need to optimize a bit here and there as I'm nearly at the limit of what I can do at 60fps and I still need to add enemies. Small video showing the new features:

When a certain market starts providing a service after it has been well established in other markets, I would call that catching up. But I didn't mean to offend, I was simply expressing my surprise about the fact that you're only now getting this. I'd be interested in hearing your findings on the security aspect, but I do want to clarify that I know for a fact these system are at least designed to strictly separate both types of traffic (I work for a company that makes modems and routers, we integrate this stuff in our product lines). Of course, that doesn't mean the design implementation is by definition perfect, but at least all parties involved are aiming for a secure solution.

As far as I know at least Dusseldorf, Frankfurt and Munich airports have free WiFi. The only one that I don't recall having it is Berlin Tegel, but... well it's Tegel... That said, Germany is indeed one of the few countries where you need to provide an email address or other means of identification to get access to it. That said, this is something different. This service requires you to log in with your internet provider credentials, so it's not anonymous at all. In Germany T-Mobile calls it WLAN To Go, Kabel Deutschland calls it Homespot service. It's true that Comcast's twist of giving 10 minutes for free to everyone isn't very common, but the core service is exactly the same.

This is common practice all over the world and I'm surprised the US is just now catching up on this. It's actually a good thing for the majority of customers. Here in Belgium my cable provider (Telenet, a liberty global subsidiary, the largest cableco in the world) does the same thing. The result of this is that I as a subscriber have free WiFi access wherever I'm in another Telenet customer's home. I no longer need to ask friends for access to their WiFi network (meaning they no longer have to share their password with me). There is no adverse effect on internet speeds, since the primary SSID (your home network) has priority over the public SSID. If I'm saturating my connection, the free WiFi users get nothing. In terms of privacy, it's all done on a separate vlan, so it's not like everyone all of the sudden has access to your computers on your LAN.

Thanks Willsy, I compared your code to Tursi's in libti99. They're very close to each other, but libti99 simply doesn't export a way to check for the fire button (in that function at least). I duplicated that function and added the check for 0x01 and it works. Code looks like this: #define JOYST_1 0x0001 #define JOYST_2 0x0002 #define JOYST_LEFT 0x0002 #define JOYST_RIGHT 0x0004 #define JOYST_UP 0x0010 #define JOYST_DOWN 0x0008 #define JOYST_FIRE 0x0001 unsigned char read_joyst(int joystick_id) { unsigned int result; unsigned char retval = 0; __asm__ ( "li r12,>0024 \n\t" "ai %1,5 \n\t" "swpb %1 \n\t" "ldcr %1,3 \n\t" "src r12,7 \n\t" "li r12,>0006 \n\t" "clr %0 \n\t" "stcr %0,8" :"=r"(result) :"r"(joystick_id) :"r12" ); if ((result & 0x0100) == 0) retval |= JOYST_FIRE; if ((result & 0x0200) == 0) retval |= JOYST_LEFT; if ((result & 0x0400) == 0) retval |= JOYST_RIGHT; if ((result & 0x0800) == 0) retval |= JOYST_DOWN; if ((result & 0x1000) == 0) retval |= JOYST_UP; return retval; } The compiler doesn't let me immediately return the result variable (which I think it should, so perhaps a bug...), but other than that I had no issues...

Tursi, you've added a fast joystick scanning function in one of the later updates. Is it possible to scan for the joystick button with that? How would one go about doing so?

Add me to the crowd of Notepad++ lovers. All my TI endeavours are written in it.

Good point, I forgot you must've had to face the same problem with scramble. My goal is to have the block disappear (replace the map data) and do the animation with sprites. The replacement pointer is a good idea though, I'll probably use that.

Hi All, I've found some more time to work on my Alex Kidd port. I manually converted one of the original games' maps to a format that is compatible with my scrolling routines. Naturally, I lost quite a bit of detail, but the end-result isn't too bad. This is what the original looks like: And this is what the same map looks like on the TI: I had to move some blocks around, or remove some blocks to avoid color clash(can't have two different colored blocks directly next to each other), but all-in-all, most of the details are there. I also originally did a very nice conversion of the cave the old man is sitting in at the end, but I ran out of patterns and had to ditch both that and the clouds. I'm thinking of adding it in a static screen that gets tagged onto the end of the map, but those are details for later. Either way, I'm only using some of the original game maps to test playability and will probably design my own at some stage (so it'd be a sequel/prequel instead of a direct port), so I'm not sure how important those issues are. Next up, I started working on real collision detection and fine-tuning the physics to be a bit more in line with the original game. Seems to be working well, although I still need to add a collision check for the top of the sprite (you could jump into one of the blocks now and get stuck if you really try). Next up: finish the collision detection routines, find a way to make Alex face the other direction and implement punching. Also, add the jumping and punching sound effects. After that, I'll need to figure out how to make the blue blocks and the gold boxes destructable in the scrolling data... punching and destroying blocks is kinda the main mechanic of the game . It should be doable, but it will be quite convoluted as I have to decide which patterns to put in place depending on the object on the other side of the block. Finally, here's a video recorded in MESS. Normal caveats apply: youtube makes it a bit more choppy than the real thing, and of course the colors are a bit more washed out here. *edit* The latest work-in-progress version is attached to this post for those that are interested in trying it out. Latest version is from august 24th, 11pm CET. alexkidd.dsk

Excellent, great to see the F18 supported by an emulator! Thanks. I also like your feature prioritization: scrolling and ECM (and to a lesser extent bitmap support) are in my humble opinion the most pertinent for games.

I'm not talking about not working. I think it's beyond discussion that Windows provides much better backwards compatibility than Linux distributions typically do, so of course I'm not going to contest that this compatibility exists. But it's also clear (to me) that running programs from "different generations" will contribute to your computer slowing down over time. I mean, there's no way that offering MFC, Winforms, WPF, ... will not lead to multiple libraries offering same-ish functionality being loaded in memory and thus more memory trashing and swapping. Simply dropping support for older libraries will help force developers of active projects to migrate to the newer versions, which imho is a good thing. Of course, it is also more common on Linux to have the many competing implementations of a certain library installed at the same time, but at least that's a choice (I only use GTK-based applications, for example, so I don't have Qt installed). I /personally/ prefer this early deprecation approach as in my experience and for my workflow the backwards compatibility is not worth the price.

To be honest, neither am I . Like I said, sometimes it's just fun to talk about this stuff, as long as it remains civil and good natured of course .

Loki's original UT99 binary has worked for me for all of this time. Of course, it's a bit easier for a game that only links against SDL1.2, OpenGL and libc, basically. But it is true that Ryan Gordon is a bit of a god when it comes to these things. Well, I have to admit that my experience with Windows has been limited to my work laptop where there's a bunch of company mandated crap probably slowing things down. But I can definitely say that my Ubuntu install on the same device feels a fair bit quicker and while covering my needs in a way that better suits my workflow. But it's mostly preference and having been a Linux enthusiast since before Y2K was a thing it's not unexpected that I lean towards the Linux-y style of working. That's not entirely true though. It's not just the DLL's, it's also the legacy services that need to run in the background and the age-old components that in some cases have not been updated/modernized/optimized because they feel that backwards compatibility is so important. I also disagree that it's just as difficult to patch an open source project than it is to reverse engineer an old binary. Most of the incompatibilities stem from evolved API's, or libraries that have been deprecated in favor of newer ones that offer similar but improved functionality in a non-compatible way. If you have the source, you're mostly concerned in updating/replacing/refactoring the calls to those deprecated API's. With binaries only, you can hope that the changes are small enough that a simple binary patch might be doable or you're stuck reverse engineering the entire functionality. I'll gladly concede that even with source code this is beyond most user's capabilities though

It's stupid to argue about, but it's fun to debate . As long as no-one gets their internet panties in a bunch I'm all for it. That said, I'm not on board with your reasoning here. First of all, there are plenty of age-old programs that run perfectly well on modern Linux distros (I still run UT99 on my Linux machines, granted it's only 15 years old but still). Secondly, you're making it sound as if the choice to drop backwards compatibility with apps that use deprecated libraries is a bad thing. It's exactly the reason why it is (or can be) so much more snappy than Windows and one of the reason why I prefer it. Apple falls somewhere in between with OSX and it shows some the same benefits. Thirdly, due to the nature of the ecosystem, at least with open source programs there is something that can be done about it. Try that with 20 year old software that you just found in an obscure corner of the internet (what is that application that can generate speech synthesizer compatible data again?). But as you said, it's a silly argument. If you want something lean and mean this thing beats it all: entire OS + GUI + web browser on a single floppy disk: http://toastytech.com/guis/qnxdemo.html

Short work-in-progress video of my Alex Kidd game that I work on every now and then when I get some free time. Got the scrolling and most of the physics worked out (jumping, gravity, acceleration and friction), spent a lot of time on that 'cause this type of game completely breaks down with bad controls. I now need to add descent sprite-world collision detection. Oh, and you can't hear it in the video, but it has the exact master system song running in the background thanks to Tursi's gcc music player. Cool stuff!

Looking forward to that (the game as well as the F18A support )!

Nevermind, I figured it out. Turns out I was overflowing my low memory expansion by defining the music as const unsigned char. Dropping the const puts it in high memory and that works perfectly. Cool stuff!

Tursi, I tried using it today but the results aren't quite what I hoped for. It sounds like it's stuck playing the first note. Now, I might have screwed up the conversion of the .spf file to a C constant (I assume I can simply take the binary file and have it encoded as an array of bytes, right?). Other than that, I just converted a vgm with one song using your tool, converted it to a constant and embedded the necessary parts from your example code in my project's main function. Anything obvious I might be missing (I did enable interrupts in the main loop, of course)?

MSX1, so with 9918 and 16k VRAM. I think everything you see there is perfectly doable on the TI. The video you posted shows per-character scrolling, and of course there are those typical 9918 colors. If this were v9938 based, you'd have better colors, smoother scrolling and flickering screen edges .

Very cool. I do think the arpeggios are a bit much in the song itself but being able to put that much information in a single song is very impressive. Can you tell a bit more about the visualisation? As in how does it work, what do the colors and locations of the bubbles mean? Since the compressor is a command line application, any chance this can easily be ported to Linux or OSX?

This is awesome. Makes me anxious to be able to pick up working on my platform game again, if only work wasn't such a time sink right now... Just out of curiosity... How many CPU cycles does every tick take, on average?

Yeah, same for my 2013 lowest-end Mac Mini (using Chrome). Nice job man, really slick.

Runs without errors on my Nexus 5, although fairly slow (15 to 30 fps). Can't test keyboard functionality though, so maybe an onscreen joystick would be good?