TheMole

Ah yes, the "Artrag" approach... . But that's not technically "screen 2" anymore, right? Sort of a hybrid half bitmap mode? I really need to dig a bit deeper into that 'cause I really don't know enough about how it uses VRAM.

True, and while it would be possible to add a bit more color ala Screen 2 in a non-game context (I think Rasmus demonstrated this with his omnidirectional scroller demo), I truly cannot afford the extra 6k of VRAM that this would consume. My VRAM layout is pretty full as it is (check out post #19 of this thread, I only have 2k left...), and I don't really see a way of making enough room for it .

Could it be that you uploaded an older disk image? I've wandered about for a bit but did not run into any orchids. I also still see the title screen?

New version attached to post 1. New features: Alex can now punch the yellow star boxes. About half of them will reveal a money bag, half of them will be empty (this is random, also it's different from the original game where you had a 50/50 chance of getting a small or large bag, but I don't have room left for "small bag" graphics). Alex can now pick up money bags, both from star boxes as well as regular ones. Alex can now destroy skull boxes, but beware: doing so is so scary that it will send shivers down Alex's spine, which will make him unable to move for a good second or so... Added a bunch of sound effects. I'll probably need to tweak the "breaking stone" and "killing enemies" sound effects as they don't come across very well on the TI. I seem to remember reading somewhere that the SMS's sound chip had a slightly tweaked noise channel for more percussive sounds, which could be the reason why it sounds a bit off. Added a loading screen, which is silly on emulation but I gather will be helpful on real hardware with actual slow-as-molasses floppy disks. Next up: tweak the Alex graphics a bit so I can get by with less sprite patterns. I have to win back 64 bytes in the table to define the "bird" enemy at the end of the level so I can replace the placeholder. After that I'll start working on refactoring the code to make the gameplay slightly less hard coded so I can load entire level definitions from disk, I am not looking forward to that .

Thanks! I fully intend to polish it up into a real game. I don't think I'll do a one-on-one port of all the master system levels, but I will definitely add some more gameplay elements and levels. Not sure if I should include the janken matches though. Does this open for you: http://s9.postimg.org/p37j885tb/miracle_island_1.png ?

I know there's a difference between the TI chip and the modified version used in the Master System, but is it normal that one loses quite a lot of detail/fidelity in the noise channel when playing these files on the TI? I'm converting (captured) vgm's for Alex Kidd, and they sound much less impressive once converted.

Thanks for testing and the feedback. Turns out I hadn't learned my lesson yet... last file I loaded still encroached on the VDP disk buffers. You were supposed to see Alex's ghost ascend to heaven and hear a game over tune play (which is loaded from disk). I resorted to simply caching the part of the buffers that are overwritten in RAM, just like you suggested a couple of days ago. Working version attached. I think I'm taking too much time updating the screen during VBLANK. I managed to improve it to the point where there's only some minor screen tearing left (at least in MESS), but I'd like to get it perfect. Any idea how much time we have during VBLANK (and how many bytes we should be able to transfer). Yup, known issue. I use bytes for sprite locations, which means there is no room for 'negative' screen positions. It gets worse... try punching when at the left edge of the screen and facing left . I need to limit how far to the left Alex can go, it's on my list of things to do though. *edit* instead of attaching the new version to this post, I decided to always add the latest version to the first post

Having said all the above, I am an idiot... I started figuring there was something else wrong when I tried loading the graphics from another function. It worked, so there was nothing wrong with the file loading functions all along (well, after my first round of moving things about in VRAM). Turns that in my init_gfx function (which loads the patterns from disk, amongst other things) I had this little line: vdpmemset(0, 0, 0x4000); I was filling all of VRAM with zeroes, thus overwriting the "no-go" disk buffer/cache/whatever at the top of VRAM as well. The call was there to clear out memory so to make things easier to debug (just so I wouldn't have to distinguish random junk from true buffer overruns...). Commenting out that line makes everything work just perfectly. Go figure... So, updated version of the disk image attached to this post, for all those that are interested to test and play with it. Feedback appreciated, all caveats about shaky sprite-sprite collision detection and all from my previous post still apply though. alexkidd.dsk

%0 and %1 are the first and second parameter passed from the C environment, as defined in the post-colon sections of the __asm__ call ( "stat", and "op" in this case). The first line means that %0 in the assembly code refers to a write only parameter ( = ) that is cached in a register ( r ), with the name stat, the second indicates that %1 refers to a read-only parameter cached in a register. The third line tells the compiler that the values in r0 and r1 will be clobbered (official gcc term ) during the execution of the assembly code. Well, the VRAM address is not really a pointer, since none of the VRAM memory is directly accessible by the CPU. On top of that, the null pointer is a perfectly valid address to write to as far as gcc is concerned, protection from writing to null pointers is actually a function of the OS/environment you are running in.

Excellent to hear (about the CRPG and girlfriend), I'd love to see how far you can take this (uhm, the CRPG...).

Welcome back. I just wanted to take the opportunity to thank you for the work you've done. I don't think I would've gotten back to programming the very first computer I've ever owned if it weren't for your gcc port. So thanks!

Thanks for the offer. These are the relevant functions from the file handling code I've cobbled together (it is heavily inspired by code from Lucien2's Nyogsothep game, so credit should go to him): #define PAB_NAMELENGTH_ADDR (*(volatile int*)0x8356) #define PAB_VDP_LOCATION 0x2400 #define DEFAULT_BUFFER_LOC 0x2C00 // File operations #define OPEN 0 #define CLOSE 1 #define READ 2 #define WRITE 3 #define LOAD_VDP 5 #define SAVE_VDP 6 int dsr_link(int op) { volatile int stat; __asm__ ( "mov %1,r1 \n\t" "blwp @dsrlnk \n\t" "stst %0" :"=r"(stat) :"r"(op) :"r0","r1" ); return stat; } int file_operation(pab* p, int op) { int EOF = 0, stat, err; p->opcode = op; p->flags = p->flags & 0x1F; vdpmemcpy(PAB_VDP_LOCATION, (unsigned char*)p, sizeof(pab)); PAB_NAMELENGTH_ADDR = PAB_VDP_LOCATION + 0x09; stat = dsr_link(; vdpmemread(PAB_VDP_LOCATION, (unsigned char*)p, sizeof(pab)); err = p->flags >> 5; if (err == 5) { EOF = 1; err = 0; } else { if (err) err++; else if (stat & 0x2000) err = 1; } if (err && p->opcode != 1) close(p); return err; } int load_to_vdp(pab* p, const char* filename, int vdp_buffer_location, int n) { p->record_number = n; p->buffer_address = vdp_buffer_location; strcpy(p->name, filename); p->name_length = strlen(p->name); return file_operation(p, LOAD_VDP); } int load(pab* p, const char* filename, char* buf, int n) { int ret = load_to_vdp(p, filename, DEFAULT_BUFFER_LOC, n); vdpmemread(DEFAULT_BUFFER_LOC, (unsigned char*)buf, n); return ret; } Then, for loading I simply use: pab fd; load(&fd, "DSK1.SONGSFX1", (char*)leveltheme, 2624); which loads the song to CPU RAM and actually works. The following however: pab fd; load_to_vdp(&fd, "DSK1.PATT1_0", 0x0000, 1024); is supposed to load 1 frame of pattern definitions to >0000 in VRAM, but doesn't work... As you can see from the code above, the load function simply uses the load_to_vdp function with some defaults, so I'm stumped as the why one would work and the other wouldn't. Both files are in PROGRAM format, by the way.

Nevermind, just figured out that you mean the VDP address that is part of the PAB structure.

Thanks for the feedback Lee. I use PAB in the same way as you, basically as a structure holding the I/O parameters. It works if I put it at 0x2400, not if I put it at 0x3400. However, I am not sure what you mean by VRAM buffer, unless you're talking about the "top of VRAM" section reserved for disk access, but I don't think you can move that around, right? I'm loading 1k blocks from disk as PROGRAM files, or at least that's what I'm trying to do. I'm going to have to take a close look at the code again to see if I'm not confusing some of my pointers to the different locations in VRAM.

Awesome!

Are there limitations as to where the PAB can be put in VRAM? I've managed to have it load one file (the song) using the TI controller when putting the PAB at 0x2400, but it doesn't work at 0x3400... which seems very odd to me. I'm still struggling with loading stuff directly to the right location in VRAM as well, but that I can probably figure out once I understand the limitations a bit better. It's still going to be a struggle to get things cleanly in memory without using too many RAM buffers. My VRAM layout is pretty specific and fairly packed. 0x0000-0x0400 Frame0 @ 0x0000 0x0400-0x0800 SIT1 @ 0x0400 0x0800-0x0C00 Frame1 @ 0x0800 0x0C00-0x1000 SIT2 @ 0x0C00 0x1000-0x1400 Frame2 @ 0x1000 0x1400-0x1800 SDT_R @ 0x1400 0x1800-0x1C00 Frame3 @ 0x1800 0x1C00-0x2000 SDT_L @ 0x1C00 0x2000-0x2400 Frame4 @ 0x2000 0x2400-0x2800 PAB @ 0x2400 0x2800-0x2C00 Frame5 @ 0x2800 0x2C00-0x3000 0x3000-0x3400 Frame6 @ 0x3000 0x3400-0x3800 0x3800-0x3C00 Frame7 @ 0x3800 0x3C00-0x3FFF SAL @ 0x3F00 CT @ 0x3FC0 FrameN = Pattern definitions for frame n of smooth scrolling defs (1k each) SIT1/2 = Screen Image Table, nametable for front and backbuffers (756 bytes each) SDT_L/R = Sprite pattern definitions for Alex is facing left/right respectively (1k each) SAL = Sprite attribute table (128 bytes) CT = Color table (16 bytes) Note that I need file loading for two things: to load the music file in RAM (I do this first) and to load the scrolling pattern definitions into VRAM (Frame1-8 in the memory map above). This is all done at the start of a level, so once everything is in place I don't have to take the VDP disk buffers into account anymore. But, I do need an efficient way of getting this stuff into VRAM in the first place. Worst case scenario, I could: Load all patterns, one by one into normal RAM via the song buffer and move them to the lower 8k of VRAM. Load the song into RAM Move the pattern definitions to their correct locations in VRAM a couple of bytes at a time But that seems awfully wasteful.

I actually think the tunnel looks rather good, at least as far as visibility of the effect is concerned. You might want to play with the chosen colors a little bit, I figure it might look better if you stick to a specific "base color", if you know what I mean. We have three shades of green, for instance. That combined with black might allow for some interesting Matrix alike effects. I agree with sometimes99er though, the asteroid animation could do with a re-distribution of depth changes. Now it looks like you have then linearly distributed along the Z-axis, while it would probably work better if you afforded more different sizes to the closer-by version of the sprite, letting the further-away version rely on less different sprite definitions. Having said all that, this looks like an awesome project you're working on, and I'm very happy that you're cross-posting this on atariage here! I think we should have more of these discussions with the larger "9918" community, especially now that with things like C compilers and PC tools cross-platform development becomes a real possibility and it should help boost homebrew output for both communities.

Anyone know the exact VDP and scratchpad locations to mind? I found an article in MG's smart programmer that shows anything below 0x37d8 should be fair game (and 0x3be4 if you do the equivalent of a "call files(1)"), but it still borks even if I avoid that area completely.

Thanks for the tip, Tursi. Unfortunately, I can only use Classic99 once in a while to test something since I've moved to Mac (I need to borrow my gf's PC to test on Windows). It's a shame too, 'cause although MESS is very powerful, nothing beats Classic99's debugger in terms of ease of use and features.

Ah, good to know. I've been using the HFDC controller in MESS, so I'll try switching. Thanks

So... finally found some more time to work on this. A bunch of stuff has been added, and I'd almost call it "a game" now (except for there being no win condition yet). New stuff: I now load most of the graphics and music from files on disk. I had to do this because I was running out of program space, and this took a shitload of time since I had to figure out how to do file loading on the TI for the very first time, and then how to fit all of it in memory where gcc likes it. Added enemies. Unfortunately, I ran out of sprite pattern definition slots and need to use a placeholder for two out of three enemies (the red balls are supposed to be some sort of plant, and the black ball is supposed to be a kind of bird). I'm not sure how I can resolve this except for maybe sacrificing some animation frames or color for Alex himself, but I'd rather not do that as I kinda like how it makes the game look like it's running on a more high-end system with multi-color sprites. Alex can now die, so no more running across lava or through enemies for him! Also, a sad song plays when he dies... Improved Alex-World collision detection, I'm very happy with how this turned out. Although you can still see small glitches (Alex moving into a block for one or two pixels), you never get stuck and it never looks too horrible. Added jumping and punching sounds, still need to look for a "destroyed enemy" sound Sprite flickering routine. Still todo: Make the yellow blocks punchable as well. I would need one more sprite definition for the most straightforward way of implementing this, but as I said before I'm out of space for those. I'll probably have to integrate that in the map definition instead, which is going to be a bit more work but should have the added benefit of not introducing even more sprite flickering then I have to suffer already. Add a win condition F18A support ECM3 and hardware scrolling support Here's a short video showcasing the new features recorded in js99er: Now, I haven't been able to run this on the real deal since my hardware is unfortunately rotting away in my damp basement until I get my house in order (friggin' renovations seem to take forever...), and I have seen some glitches in MESS and some stuttering in Classic99, so I would very much appreciate it if one of you could test it on real hardware and perhaps make a video so I can gauge how smooth it runs on that? For those that want to give it a spin, there's a disk image attached. EA#5, DSK1.ALEXKIDD (needs 32K memory expansion and it the file paths are hardcoded to run from DSK1 for now, sorry about that). *edit* thanks to Rasmus for trying it out and unfortunately reporting that it does not work on real iron. I've removed the download until I've found a fix for this.

I agree. Never understood the use of the widget anyway, completely messes up the look of the system, the carts are in the way and you still need to reset to select a new cart.

It would probably require a bit of work, but you could consider moving to the gcc assembler (it works stand-alone without the C compiler as well).

Do you buy toothpicks one at a time as well?

I was too late to take the screenshot at the end of the race, so I don't have one. I did manage to complete the full 8 laps though, and had a score of around 101000. I'll try again later when I feel like it a bit more... 'cause man, this is not a fun game... . All the while playing this I couldn't shake stop thinking that the TI should be capable of sooo much better when it comes to pseudo-3d racing games. If have very fond memories of playing Pit Stop II on the C64, and that game is buttery smooth on the system: (kick ass narration on this video, by the way ).It's also an immensely fun game to play, I've wasted hours and hours on this, up to the point where the monotonous engine sounds kept on droning in my skull for hours after I'd stopped playing. The mechanics of having to mind your tire wear and fuel consumption adds a lot of depth to the gameplay. The biggest problem with TI Pole Position is obviously the choppiness of the road rendering, given that it renders at a whopping 1 fps... I'm wondering how easy it would be to implement a pseudo-3d road renderer that gets at least 15fps, and I think it should be possible if you make the road take up less screen real estate (less screen to update). Pole Position's roads are a whopping 96 pixels high, or half the screen, while in Pit Stop II it's only 72 pixels. Hell, in Grand Prix Circuit on the c64 the road is only 38 pixels high! Suppose we take a road that is 64 pixels high (1/3 of the screen), that would mean we'd need to render 64*15 horizontal lines per second to get 15fps, or 960 horizontal lines per second (a pseudo 3d racing game is basically a pre-rendered set of horizontal lines that depict a straight road. Then, when doing turns, the lines are simply drawn with an offset distance from the side of the screen that gets smaller the closer you get to the bottom of the screen). I know Tursi measured a max speed of 92 lines per second for arbitrary bresenham lines, but maybe we can get a 10-fold speed increase if we just need horizontal lines. Of course, if you make the road as small as 38 lines, it's only a four-fold speed increase and I'm sure that is possible.