TheMole

Hehehe, clear and understood! Looking forward to the online version, but in the mean time the pdfs are a great resource.

Yeah, I looked at that, just to be sure . Now, with the current design, each level will need somewhere between 13.5k and 18.5k of uncompressed data for the 9918a version, of which at least 8k can easily be compressed; for the F18A graphics, we need roughly 4k less per level (2k less for the pattern data, and the collision detection data can be reused across both versions). I'll probably do around 12 to 13 levels. Adding all the music, title screen, story text, etc... I think I'll hit 400k of data and roughly 24k of code. The 512k version should be good enough. If I go over that, I would probably look at compressing the data first though, there's plenty of room for improvement with that (I could win 6k per level by not pre-calculating the scrolling patterns for instance, but that would increase the loading times for the levels). I'm also assuming a 512k cart is slightly cheaper to make if I want to do a physical cartridge release .

Excellent news, thanks for the heads-up Michael (and for adding support for the new carts as well, obviously)!

Great Initiative! I don't want to be greedy and ask you to spend even more effort and time on this, but have you considered sharing the spreadsheets via Google Sheets? That way you can share a persistent link the the most up-to-date version of each document, and you can even make it read-only while still allowing people to search/filter/etc... Also, people wouldn't have to download anything or sign up to Google to get access.

If it didn't have such a low resolution screen, and came with an app that did decent JCM800+Tubescreamer modeling I'd be all over it. It's a shame really, it is a great looking device and unlikely the PET phone is actually a bit more than a rebranded cheapish Chinese phone (it being a custom designed, branded, cheapish Chinese phone at a somewhat premium price...).

Yeah, you're right, they just seem to have stepped out of the mobile devices market in favor of embedded devices: http://www.reuters.com/article/2012/09/25/texasinstruments-wireless-idUSL1E8KP5FN20120925?irpc=932 I just knew we weren't able to get support for any of their chips anymore for our devices (routers, modems, tablets and set-top-boxes) and remembered the news about them stepping out of the mobile phone/tablet game and figured they just stopped the entire line. I was wrong .

They exited the smartphone chip market in 2012 and no longer make the OMAP chips. But they still make the calculators using Texas Instruments as a consumer facing brand, so no way they'll license anyone the right to make a TI branded smartphone without being heavily involved.

That is super cool!

Another update, this time in video format: New in this video: the ability to finish a level and to go from one level to the next keeping track of lives (you start with three), if you die you get kicked back to the title screen If you finish the game (so currently only two levels... ) you get kicked back to the title screen Better tree graphics in the second level (although the "deadly roots" had to be made a bit more plain to make it all fit within 128 characters). Next up: Re-introduce enemies Re-introduce level introduction screen Make level introduction screen available as pause screen during game Add gameover screen Add F18A renderer for all of the above After that I'll release an .rpk for everyone to play with and give feedback, while I work on the story and final game's levels.

Excellent news, will try this ASAP tonight when I get home from work! Thank you! You might also be interested in the discussion on creating bankswitched cartridges we had a while ago here. I now have a pretty good system up and running, but if you're still looking for features to add native support for "far" function calls would surely help make this a bit more generic and perhaps even efficient. Moving to gcc 5.2 would be cool.

I ordered a nanopeb from stargames and got a cf7 about one week later. Not a big deal for me though, I hadn't planned on using the pio/rs232 anyway. Keep in mind that I live in Belgium, so I can probably get things a bit quicker from stargames than ppl abroad.

Nope, I didn't, good to know and thanks for that! I still think it might be beneficial to keep a thread here on the forum to tell people when new versions come out?

I only know how it works from a software perspective, but there are 64 banks in the 512k cartridge, and you select banks 0-63 by writing to 0x6000-0x6080 respectively. The banks are non-inverted, and the memory locations to activate them two bytes apart So: - to select bank 0, you write to 0x6000 - to select bank 1, you write to 0x6002 - to select bank 2, you write to 0x6004 ... - to select bank 30, you write to 0x603c ... - to select bank 62, you write to 0x607c - to select bank 63, you write to 0x607e

I have a couple of questions regarding burning my own carts. - First of all, are there any carts that can be programmed by the TI, or do you always need an EEPROM programmer? - Secondly, I seem to remember reading that the ubergrom cart can ensure that the ROM portion of the cart starts up in the first bank, whereas the ROM-only carts need a header in every bank. Is this true, or am I making stuff up? - Thirdly, what is the most efficient way to set up a cart for development purposes (which cart, ROM or UberGROM, which programmer, ...) Thanks!

Sorry for the misleading title, as this is really a request for a MESS updates thread . I was trying to figure out if MESS evert started supporting non-inverted 512k cart images. I'm still running 0.149b and that one doesn't take the image I've been testing in js99'er. I tried going through the MESS release notes, but with all the changes for all the systems it's kind off hard to find the ti99 specific info. Anyway, Michael, consider this a request from my part to keep a thread dedicated to MESS updates, like we have for classic99 and js99er .

Yeah, I don't necessarily plan on adding F18A-only gameplay features to this specific game, but I do want to support enhanced graphics throughout the game. Having 512kb of cart space means I don't have to worry about the space taken up by duplicating all the assets for the two chips . I'm progressing quite well, although I'm still not where I was with the disk version. Originally, I had hard-coded all the data for a single level, but this time around I wanted to support multiple levels from the start.'m now back to the point where Alex can walk around in the world, but this time he can do so in two distinct levels . I still need to add the enemy handling and block-punching back in (gameplay wise, the block punching is in, but it isn't rendered yet), but it's good to be able to test this in different environments. It has surfaced some bugs with the older code that I wouldn't have discovered otherwise. Also spending a bit more time on the PC tools to generate the levels, since they now need to support creating more data (putting entities in maps) and will eventually also need to support creating the graphics for the F18A. Anyway, here's a couple of screenshots of the two currently available levels as rendered by the good old 9918a: *edit* I really need to redraw the graphics for the treetops though...

Funny how Google Translate turns "Rasmus" into "Robert" when translating from Danish to English or Dutch...

That's the guy from Treasure Island.

Some of the best graphics I've ever seen on the 9918, hiding the chip's limitations really well! Regarding movement: I think for you it will depend on how long the ball is consider to be on the floor, but in Alex Kidd I do the following each frame: (consider that Alex has a position (x,y) and a speed (hvelocity, vvelocity)) When pushing the joystick right, I add a constant acceleration value to the hvelocity, pushing left will subtract that same. When the joystick is in the neutral, we substract or add (when hvelocity is postive and negative respectively) a friction value. The friction value for me is half the acceleration value, but this can be tweaked depending on how 'slippery' the gameplay needs to be (friction is much lower in Mario games, for instance). When Alex is airborne, the value for acceleration is halved, and friction is zero (although, again this can be tweaked and I would recommend to have at least always some friction for your game) At the end of each frame, right before drawing the sprites, I add hvelocity to Alex's x position. Usually full control when in the air will seem off, and as a rule of thumb I typically try to make it that a player is never be able to fully reverse his direction when airborne.

Well, I've decided to take the cartridge route. Porting the game over is going to be a bit of work, but I'm taking the opportunity to clean up the code a bit, and add F18A support. For now, I have the title screen back up and running. It ain't much, but it was heaps of fun getting the build system and the bank switching up and running . The video show the title screen in both 9918a and F18A versions running in the wonderful js99er!:

Thanks Rasmus, that helped! So basically, the 4 pages are always arranged as follows: PAGE1 | PAGE2 BASE | BASE + 1k ----------------------- PAGE3 | PAGE4 BASE + 2k | BASE + 3k Regardless of the configuration of the page sizes, they merely "enable" the pages.

Just to add: Nametable 2 is at position 0, which technically I think is a 4k boundary? Nametable 1 is at 4k, but I'm not scrolling that one. Perhaps I should try swapping them? *edit* Nope, didn't help... still shows garbage in the second page. Different garbage... , but still garbage...

This is my setup code: void load_title_f18a() { // Blank screen so we don't show garbage VDP_SET_REGISTER( 0, 0x00); VDP_SET_REGISTER( 1, 0x00); VDP_SET_REGISTER( 7, 0x00); // Black border VDP_SET_REGISTER( 4, 0x05); // Pattern table at 4 * 0x800 (0x2000 - 0x3800) VDP_SET_REGISTER( 2, 0x04); // Nametable, 0x04 * 0400 (0x1000 - 0x1400) VDP_SET_REGISTER( 3, 0x60); // Attribute table, 0x60 * 0x40 (0x1800 - 0x1c00) VDP_SET_REGISTER(10, 0x00); // Second name table at 0 * 0x400 -> 0x0000 - 0x800 VDP_SET_REGISTER(11, 0x20); // Second attribute table at 32 * 64 = 0x20 * 0x40 -> 0x0800 - 0x1000 VDP_SET_REGISTER(29, 0x10); // Set 2 vertical pages for TL1 VDP_SET_REGISTER(49, 0xb0); // 0xb0 = TL2 enable | ECM3 for tiles VDP_SET_REGISTER(50, 0x02); // Per position attributes vdpmemset(0x0000, 0x00, 0x4000); // Load color, pattern and sprite generator RESources from ROM rom_to_vram(RES_START(title_nt_f18) , RES_END(title_nt_f18) - 768 , 0x0000); rom_to_vram(RES_START(title_attr_f18) , RES_END(title_attr_f18) - 768 , 0x0800); rom_to_vram(RES_START(title_nt_f18) + 768 , RES_END(title_nt_f18) , 0x1000); rom_to_vram(RES_START(title_attr_f18) + 768 , RES_END(title_attr_f18) , 0x1800); rom_to_vram(RES_START(title_patt_f18) , RES_END(title_patt_f18) , 0x2800); rom_to_ram (RES_START(title_pall_f18) , RES_END(title_pall_f18) , (unsigned char*)palettes); // Copy palettes to CRAM VDP_SET_REGISTER(47, 0xC0); // Palette write mode | Auto increment | Start at address 0 for (int i = 0; i < 64; i++) { VDPWD = (palettes[i] & 0xff00) >> 8; VDPWD = (palettes[i] & 0x00ff); } VDP_SET_REGISTER(47, 0x00); // VRAM write mode VDP_SET_REGISTER(26, 0x50); // Scroll 80 pixels up, to hide title card VDP_SET_REGISTER( 1, 0x40 | VDP_MODE1_INT); // GM1 / No blanking | Interupt enabled } The rom_to_vram calls load the data into VRAM from other banks in the cartridge, but I've verified that these work fine. A VRAM dump is attached for reference. I'm trying to "drop" TL2 into view (it contains the game's title, I'm sure you know the effect I'm after...). It title scrolls out of the way nicely, but the lowest 80 pixels (with the settings above) show 'garbage', which I'm sure it's picking up from elsewhere in VRAM but I can't figure out from where. Note that I'm using location based attributes, which may change things from 'normal' tile-based attributes. vram_dump.txt

Thanks, I'll try it when I'm home tonight.

Matthew (or Rasmus or anyone else who's programmed the F18A's scroll registers), I'm trying to figure out how to do scrolling with pages on the F18A. I'm looking at both the documentation and the register sheet, but I'm getting a bit confused on how things are supposed to work in v1.6. In the pdf file, there's mention of a "start page" bit in register 29, which determines the page offset for the scroll value in registers 27 and/or 28. But in the v1.6 version of the register document these bits are gone. How does one select the start page in the new firmware?