TheMole

With Lucien's permission, and if Retroclouds agrees, I think it might be worth adding this to the gcc section of the development resources thread.

Yeah, I do think optimization of the meta-tile approach is the only way forward. I want to be sure that I'm not missing some super fast, super intelligent approach that I haven't thought of. As for storing the meta-tile dictionary as words instead of bytes... I could, but I'm afraid that doubling the size of it will come back to bite me in the ass later on when I get new ideas/maps/artwork/music/whatever... that require the memory . I'll probably try to get it fast enough with bytes first.

That sounds like a simplified RLE compression algorithm you're proposing. For static stuff, I agree that this would work very well and is speedy enough for real-time decompression. However, the problem is that it's hard (impossible?) to change the compressed data in-memory without going through a full compression cycle, and since the player can destroy parts of the map/level, I need it to be dynamically modifiable.

If you're only interested in getting a TI emulated on the Raspberry Pi and MESS turns out to be too heavy, I can recommend ti99sim. It's not nearly as faithful an emulation as MESS is, but for most everyday scenarios (running games, etc...) it should be good enough. It was semi-recently updated with explicit Rpi support: http://www.mrousseau.org/programs/ti99sim/

Lucien: very cool that you've made a Windows build available for everyone. I know some people were looking for this (at least arcadeshopper and Rasmus, if I remember correctly), and I'll probably use it in a pinch on a Windows machine as well. Much appreciated! I haven't been able to further look at my clang build problem, so I haven't been able to use the new version yet. Perhaps I should try compiling with GCC for mac.

I've been thinking about how to add efficient, fast compression of level data to Alex Kidd. Currently, the widest level possible (unpacked) due to memory constraints is 1280px wide (or, 160 characters, or 5 screens). The level in the current Alex Kidd demo fully exploits that space, and it is the smallest I have in my current designs. This takes slightly less than 4k of RAM (3840 bytes, to be exact). So, I need to come up with a form of compression of the levels that has a number of characteristics: Compress the data enough so that total memory consumption for a map of 3072px wide (the largest map I currently have designed) is less than the 3840 bytes currently available (and actually, I probably need to shoot for something around 3kb 'cause I need some memory back for other things, such as longer music tracks). Is extremely fast to unpack to VDP: I need to copy three to six rows (96 - 192 bytes) of unpacked data to the VDP every frame, depending on how fast Alex is running (he runs fast enough to need two-pixel scroll increments at times). Add to that the 128 bytes for the sprite table that need to be uploaded every frame, as well as the game logic even with the uncompressed map I'm close to the edge of the the machine can do with the current C code. Allow for dynamic modifications to the map. This is probably the most annoying requirement, but since Alex can destroy parts of the world (rocks get replace by nothing, boxes replaced by money bags or special items, specials items and money bags by nothing) I need to be able to take those out for as long as that part is potentially on screen. Because of that, simple RLE is out of the question. So I ruled out RLE. Besides that, the obvious one is to look at the way the levels are built up: every item on screen can be represented by a 16x16 meta-tile. Using the meta-tile approach, the map data itself of course compresses to 25% of it's original size, and the meta-tile dictionary will take up around 800 - 1024 bytes, depending on the complexity of the map. This puts the largest map at around 2k, so the compression result is excellent. However, uploading this to the VDP turns out to be slower than expected. In iterating over the metatiles, I need to see whether I'm uploading odd or even rows, and starting from odd or even columns and that code slows things down enough to push me over the limit of what I still have available in the time for one frame (well, when Alex is running at least, when he moves slowly, I only need to do this for three rows and that still seems to work fine). I can do a couple of things to remedy this (optimize the lookup code, unroll some loops, hand code it in assembly, ...), but I wanted to see of someone else can think of a super-duper way of compressing the data that is nearly free when it comes to turning it into something that I can upload to the VDP.

That's a neat use of the characteristics of the algorithm. Instead of calculating the occurring transitions in a pre-defined map, you just pre-scrolled every character into an empty 8x8 pattern, allowing you to scroll any text without having to do the pre-calculation. I like it, and might steal the idea for the story progression in Alex Kidd.

Yeah, thanks for taking up the challenge on that one. I'm glad we ended up with your front-view volcano instead my top-down version. I only made minor modifications to your effort, so again: much appreciated!

It always saddens me when internet communications between intelligent adults are framed in what appears to be the most negative way possible. We're an international bunch with different cultural backgrounds, and we all communicate in our own specific ways. So yeah, a pointed remark from a Dane (some of the most verbally direct people in the world) might come across a bit harsh to a Canadian (if I remember correctly Omega?) - a people that are known to be almost notoriously friendly. But really... if you step back I'm sure everyone will see it's not meant to be rude, it's meant to convey an opinion. Nothing more, nothing less. Definitely not something I would hope a bunch of guys that are at least my age (and often 10 or more years older than me) get irked about. For what it's worth, Belgians are known for trying to avoid confrontation, seeking middle ground and enabling compromises. So yeah, I just had to... .

I'm having a problem building this on OS X 10.10 (using LLVM). Usually I have to fiddle with some things a little bit to get things working, but here I'm stumped as to what might be going wrong. This is as far as I get (and the modifications I did to get this far): Patches apply fine Binutils compiles fine GCC starts to compile: first I had to amend the ./configure line to point to where libgmp and friends can be found. Then I had to modify a GCC version check to fix a compile error (and later link error) in toplev.c (simple #ifdef gcc-ism I had to strip out, nothing that should impact the code in the end) Then I run into the error I can't seem to solve below: /Users/danny/Documents/dev/build/gcc-4.4.0/build/./gcc/xgcc -B/Users/danny/Documents/dev/build/gcc-4.4.0/build/./gcc/ -B/Users/danny/Documents/dev/build/tms9900/bin/ -B/Users/danny/Documents/dev/build/tms9900/lib/ -isystem /Users/danny/Documents/dev/build/tms9900/include -isystem /Users/danny/Documents/dev/build/tms9900/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include -DHAVE_CC_TLS -o _absvhi2.o -MT _absvhi2.o -MD -MP -MF _absvhi2.dep -DL_absvsi2 -c ../../../libgcc/../gcc/libgcc2.c \ -DLIBGCC2_UNITS_PER_WORD=2 In file included from ../.././gcc/tm.h:5, from ../../../libgcc/../gcc/libgcc2.c:31: ../../../libgcc/../gcc/config/tms9900/tms9900.h:1132: error: expected ‘)’ before ‘*’ token make[1]: *** [_absvhi2.o] Error 1 make: *** [all-target-libgcc] Error 2 === Failed to build GCC === I looked at tms9900.h, tm.h and libgcc2.c and can't see any obvious mistakes (definitions seem to be complete and match up and all that...). Any ideas? *edit* I want to add that I did get it to compile in the past with the LLVM that comes with XCode 5, but since upgrading to Yosemite and XCode 6 I hadn't tried recompiling the code base. The LLVM version is reported as follows: Dannys-Mac-mini:dev danny$ gcc -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.0.0 Thread model: posix

Excellent, very cool updates. I'm going to build this as soon as I get home 'cause I think I may have been bitten by the segment bug you talked about on your blog. I just never attributed it to the compiler, but it from your description it could be it (hope so!).

Ah, but if there's still active IP on the design, making repros might be a bit of a problem? I guess Richard would have to chime in on that.

Well, this is a tricky one... I did not find the bug, but for some reason I managed to get rid of it anyway... adding a completely unrelated call somewhere in the middle seems to have solved my issue. This is what it looks like in action (recorded in MESS): http://youtu.be/mIr4lCLaw1A Big thank you to all the people who helped out with the overworld graphics, I think I kept at least parts of everyone's input and I do believe it's a nice improvement over my original proposal. Gotta love this community!

Just a small update: I'm still working on this and have a version with start screen, overworld screen and one level almost ready to go. However, I've ran into a strange bug. When starting the game, I do the equivalent of a call files(1) to free up enough room in VRAM for the scrolling screens and bitmap+sprite screens. I use the code provided in Tursi's libti99 for this, and it has work just fine up until now. Since a week or so, the game hangs when starting up, and it hangs in the DSR code itself (at least, I can see it looping in the 4000 address range). I only see this on MESS, not js99er or Classic99, but that's to be expected given how only MESS actually uses the real DSR. Anyway, hopefully I can get this fixed soon so I can move to more fun tasks, such as adding compression to the level data .

If you can share them, I wouldn't mind taking a look at the schematics. As I said before, I'm not a hardware guy but I'm interested in learning. This seems like a simple enough project to get started with, especially if I can learn from the TI schematics.

Thanks for the document, very usefull stuff. Shame it doesn't allow paging in cart RAM, but still... Would you happen to have a schematic for the 128k cart?

Thanks for the info Michael, looks like shadowing system ROM is a no-go then. I still think there's merit in doing a memory expansion unit that shadows DSR and cart ROM spaces. Of course, the shadowed RAM should be disabled by default, and only enabled by software that is aware of it. For the DSR part, it would be useful for programs that don't use DSRLNK at all (you'd be writing software specifically for this type of memory expansion anyway in that case, so that's not a stretch). Same goes for shadowing the cart RAM, classic carts that bring their own ROM in that area wouldn't be able to use this of course, but they would still function since the shadow RAM would be disabled until software specifically written for it turns it on.

Cool, I did not know the 128k allowed paging in that way. I always just figured it allowed paging of memory in the 'normal' 32k expansion space. A sidecar version of this would be really cool though. Do you have docs on the card's operation? A workalike with modern components seems like a good approach for a sidecar version of it.

Well, no, I would see it as follows (in 8k chunks): 0000-1FFF = System ROM / Shadow RAM 2000-3FFF = Lower RAM expansion 4000-5FFF = DSR ROM / Shadow RAM 6000-7FFF = Cartridge ROM / Shadow RAM 8000-9FFF = Memory mapped devices, GROM, PAD RAM, ... A000-FFFF = High RAM expansion (24k) With system ROM, DSR ROM and Cartridge ROM paged out for an environment that doesn't use anything from the system ROMs and GROMs (think along the lines of a Geos alike environment, or maybe an MDOS port for the TI). I'm not sure how you would bootstrap the system this way (in software), but I'm sure there's be a way. With just the DSR ROM paged out, you could create apps that don't interact with hardware once loaded (e.g. arcade games). And with the cartridge ROM paged out, everyone with a simple EA cart could use it somewhat like a supercart, or you could simply create disk-based EA programs that can access 48k of RAM total. Sounds very powerful to me, and I don't think such a 56k sidecar design would be overly hard to design... I'm going to read up on that doc you referenced in your other reply to see how feasible it would be.

So, given that the DSR ROM range is addressable over the peripheral bus, it must be fully decodable there. Would one be able to overlay 8k of RAM in the 0x4000-0x5fff area by simply reserving one CRU address for it, latching a select/enable bit high on CRUOUT and pulling it low on CRUIN on that address? I doubt it can be that simple, as I would assume someone would've come up with a 40k RAM expansion with a contiguous 16k area, and a contiguous 24k area by now already. Or even better, a 56k expansion that also masks the 8k cartridge ROM area and the system ROM area with RAM? We'd almost be in C64 territory with that... As far as I know, only the 8k between 0x8000 and 0x9FFF are off-limits due to the memory mapped VDP, sound, GROM, etc... right?

I've always wondered about how DSR memory actually works on the TI. Can one simply add new DSR's by making them available on the bus at 0x4000? If so, would a 64k SRAM chip that decodes in that space when selected (how? via CRU?) allow for adding new (software-only) DSRs to the system? I could imagine simple devices (like an RTC or a ramdisk) being emulated by a DSR in this way...

Rasmus, I have a small feature request: would it be possible to display the meaning of the contents of the VDP registers somewhere on the debugger screen? That way I don't have to flip between docs and js99er to figure out if I've set my registers to point to the correct locations in VRAM, etc... .

WiFi isn't necessary for me personally, but some form of PEB-over-UTP would be super. That would make the Rpi-as-a-PEB idea immediately feasible, and at the same time would provide a software extensible replacement for the nanoPEB. If someone is willing to build the hardware for this, I will commit to help out with the Linux software side of things.

Omega, de keep in mind that the low-end Windows tablets typically run Windows RT on top of ARM CPU's, and are not capable of running normal Windows programs that haven't been explicitly ported to the platform. So Fred's HDX software will not run on those things!

Is there a written explanation of how it works somewhere?