TheMole

I might be wrong, but aren't you doing parallel projection now (it is the cheaper of the two operations)? It's a bit difficult to see 'cause of the odd shape of the polyhedron you're using, but if in the demo I rotate over one axis I can clearly see the projected line segments remaining the same on-screen size as they rotate into the screen (towards the back). If you were doing a perspective projection the line segment would become smaller the further away from the viewer it goes. Typically, perspective projection is used in 3D games since it gives a better impression of depth, whereas parallel projection is mostly only used in certain CAD applications and views where the length of a line segment needs to be visually comparable to others regardless of z-position. Note, parallel projection is often called orthogonal or orthographic projection, like in the picture below, so my terminology might be causing some confusion. Just to be clear, from the looks of it you are not doing the second type of projection, right?

Although it won't tell you about which addresses to use, I'd say most of the info for those cards can be found in the VDP's datasheets. As to what the functionality provided on the other addresses is concerned, each address should map to what is in the manual called a "port", of which there are four. The functions of each port are the following: "VDP has four ports, port #0 is a read/write data port, port #1 is write register set-up port, port #2 is write palette port, and port #3 is write register data port". Full datasheet/programming manual can be found here: http://rs.gr8bit.ru/Documentation/V9938-programmers-guide.pdf

Now that I'm looking at this again, it seems like you are doing parallel instead of perspective projection. Is that an artistic choice, or are you doing it to save on a division? Any idea if the additional division per vertex would pull down the framerate by much (on the F18A version, that is...)?

Very nice! Well, it really depends on what type of 3D graphics you want to do... But a software z-buffer will almost always not be the right answer. If you're trying to make a 1st or 3rd person view indoor shooter, there are basically two common approaches you can follow: A "portal" rendering engine (ala Unreal): you divide the world into convex rooms (called "sectors") that are connected via "portals" (typically doorways or windows in levels). First you determine the sector you are in, then you determine the visible polygons in that sector via frustrum culling (simply testing whether polys are at least partially within your field of view). For each of the polygons that are flagged as being a portal, you adjust your frustrum and recursively render the sector it links to. Everything else within a sector is rendered using the painters algorithm, which we know will always work since we have a convex space. A BSP rendering engine (ala Quake): instead of storing your polygons in a flat list, you store them in a binary tree. You build the binary tree (offline) by taking a random first polygon and using that to divide your space in two subspaces (hence the binary nature of the tree): a subspace consisting of the polygons that are in front of the plane defined by your first polygon, and a subspace consisting of the polygons that are at the back of that plane. When rendering your BSP tree, you start at the root node and simply test if your viewpoint is in front or in back of the polygon defined in the root node and recursively follow the same procedure for the "side" of the tree from that node onwards you've just determined. Once you hit a lead node, you render the polygon there and move back up through your recursion, rendering the polygon at that node, and so on... For resource constraint devices, the BSP tree is by far the fastest approach (linear, and no sorting required, just a simply back/front test). However, it was never used in 8-bit games since Doom was the first game to actually use the technique (although in pseudo 3d, 'cause Doom used lines instead of polys). For outdoor rendering, or other non-first person setups there's less room for aggressively optimized rendering algorithms. Most efficient would probably be to simply do higher level culling and occlusion tests (e.g. bounding box tests, octrees, ...) combined with the BSP approach for what are typically called "brushes". Having said that, most 8-bit 3D that I've seen is not really 3D, but uses 2D raycasting to create a 3D effect like in my Wolfie3D demo.

Nope, my max bid was 300 USD, and I don't plan on increasing that (and it turns out the seller doesn't ship to Europe anyway...). But yeah, it'll probably sell for close to $1000 again.

FYI: the second question is a yes/no question to which one cannot answer no... I chose "other", but this is my nanoPeb. 1 system has a PEB with two internal drives and one additional external drive (full height). The other system has a nanoPEB. I also have one PEB with just one full height drive. Although all of the above is quite theoretical in my case, since it's all packed away in storage, so yeah...

That Geneve is from the same seller and has the same description as this auction: http://www.ebay.com/itm/MYARC-Geneve-9640-TI-99-4A-Texas-Instruments-compatible-RARE-/141511090911?pt=US_Vintage_Computers_Mainframes&hash=item20f2b7e2df The picture is different though (previous one had a case), so it's probably a second Geneve. Last one went for $750, which is waaay too much for my tastes. I put in a bid that makes sense to me, but I'm almost certain I'm not going to win it...

Thank you sir. Cool demo, nice use of the speech synth for the sound effect. I also like the very nice skull logo/graphic.

Never looked into how one makes rpk files. Can you share your layout.xml?

This is a console modification, right? Not a pbox card?

Neat looking effect, cool music. I'm guessing you generated the horizontal scroll data on top of 8 frames of vertically scrolling animation? Is there a reason why you need the characters to be 8x8 blocks?

Cool, thanks for the info. That is indeed how I figured it would work, and it's nice to see that HTTP is done on the TI side. So I'm guessing you use certain escape sequences to get the Lantronix to connect to certain IP addresses then?

True, although it was very common for other systems to work with re-definable 8x8 characters as well, for instance. I reckon you could come up with a base set of tags that would work across different systems, and then allow system/browser specific definitions for the more advanced stuff... Aaargh! It's HTML all over again

Nice, high quality stuff. Thanks!

If you have a working beige console you are looking to get rid of and are willing to ship to Belgium, I wouldn't mind giving it a nice home. I have two silver ones, but love the look of the beige ones (I know, I know... but the heart wants what it can't get/doesn't have, I guess )

Fair enough, although I imagine it would be possible to emulate a Lantronix or similar device within the emulator (not a feature request, just curious !). I guess I also don't quite understand how you use such a device from the serial side of things, and how much of the heavy lifting the device is doing. Is it basically tunneling TCP or UDP over serial (and HTTP being handled by the TI)? With commands to establish connections to certain IP/port combinations, ala netcat on Linux? Or does it handle the HTTP protocol as well?

Would it make sense to standardize the (a) set of generic retro computer tags instead of having TI specific ones? I could see a whole dedicated retro internet subcommunity flourish across a wide range of systems. Sites like atariage, or other retro computer forums and info sources could provide alternative retro-ml pages when detecting retro user agents.

Cool! Any way to get this to work in an emulator?

Don't. There's a bit of a stigma associated with XB, but given the new tools (XB256, XB compiler, PC-side editing tools, structured XB programming, ...) the environment has become so much more powerful that I wish there were more people like yourself creating cool stuff with it. Either way, looking forward to the end result of this!

Cool, glad it was useful info.

Sure. Can you tell me which Linux distribution you're using? I'll take the assumption that you're using a debian-based distro (like Ubuntu), since that's what I know best, but most of this stuff will be generic enough to work in other environments as well. Only when you need to install dependencies you might need to do something specific for your distro. The good thing about ti99sim is that binaries for Linux are provided, so all you need to do is make sure you have the right dependencies installed (more on that later). So in most circumstances it's simply a matter of downloading one of these packages: http://www.mrousseau.org/programs/ti99sim/archives/ti99sim-0.0.12.i386.tar.gz http://www.mrousseau.org/programs/ti99sim/archives/ti99sim-0.0.12.amd64.tar.gz http://www.mrousseau.org/programs/ti99sim/archives/ti99sim-0.0.12.armhf.tar.gz Which one to choose depends on your machine. The first one will work on almost any PC-class device, the second one only on 64bit machines with a 64bit OS installed. The last one is specifically for ARM devices such as the Raspberry Pi. Once downloaded, all you need to do is unpack the archive and check your dependencies. Unpacking is easy enough as most Linux distro's come with a nice UI program for that (just double click the archive), but you can also do it in a terminal. The benefit of the terminal is that it works exactly the same in every distro, while the UI program can differ ("Linux" is not a single OS, just the kernel. The different distro's ship with different user-space programs to round out the full OS functionality). So in a terminal, go to the directory where you've downloaded the tarball and unpack it: # cd ~/Downloads/ # tar -xvzf ti99sim-0.0.12.i386.tar.gz # cd ti99sim-0.0.12 At this point, you need to prepare the roms for the emulator (like MESS, ti99sim doesn't have a license from TI to redistribute the roms, so you have to do this manually). Unfortunately, I remember this process being quite convoluted and I don't have a Linux PC at hand to do this step by step, so I might be making some mistakes here... Anyway, the author of ti99sim suggests taking the 994a.bin file from a working v9t9 install, but you can just as well take the ti99_4a.zip file from a MESS install, unzip it and convert them to ti99sim format using the supplied convert-ctg program. I haven't tried this, but I believe this should do the trick (assuming the ti99_4a.zip file is in the ti99sim folder): # unzip ti99_4a.zip # ./convert-ctg 994a.bin # mkdir -p ~/.ti99sim/roms # mv 994a.ctg ~/.ti99sim/roms/TI-994A.ctg This should get you a base system up and running, with 32k, but without disk or speech support (those need separate roms). By the way, you'll notice that I'm using 994a.bin in the command there. This is because of the way the convert-ctg program works: if you have a set of roms that exists of multiple components (in this case, a ROM and a GROM set), you only supply the part of the file name (plus the extension) that is the same across the different files in the set. convert-ctg will then find the right files to create the .ctg file. So let's see if we're missing dependencies. The simplest way to do this, is to just try to run the damn thing: # ./ti99sim-sdl If this runs, your system has all the required libraries installed, if you get an error along the following lines: ./ti99sim-sdl: error while loading shared libraries: libsdl-1.2.so: cannot open shared object file: No such file or directory that means that you don't have SDL installed (SDL is like DirectX on windows, an input+graphics library for games and other multi media programs). This is where the install procedure of your specific distro comes into play. On a debian-based distro, you would then simply issue the following command: # sudo apt-get install libsdl-1.2 libcrypto It'll ask you for your password and will install the two packages listed (libsdl-1.2 and libcrypto), which next to the basic stuff that every distro has by default should be all that is needed. While normally those should be enough, it might throw more errors in case there are more dependencies. Then, you just need to go over each missing library it reports and install them using the same mechanism one-by-one. Usually the name of the package (in the "apt-get install" line) is the reported missing filename up to the .so part. So, for libsdl-1.2.so this becomes libsdl-1.2. There might be small deviations on this, in which case you will need to search your package manager for the right package by hand, or do a Google search. Now try running it again (./ti99sim-sdl) If this works, and you want disk support, do the exact same thing as with the console roms: locate the zip file with the rom in your MESS install, unzip it and run disk.bin through the convert-ctg program, taking note to add the -cru=1100 flag to the command line (this is needed for DSR's). Then copy to the ~/.ti99sim/roms directory and rename it ti-disk.ctg. like so: # unzip ti99_fdc.zip # ./convert-ctg -cru=1100 disk.bin # mv disk.ctg ~/.ti99sim/roms/ti-disk.ctg The emulator also does not support rpk's like MESS or js99er, so you will need to convert these manually as well. The process is much the same, and it uses the same convert-ctg program. The biggest difference is that cartridge files need to go into the ~/.ti99sim/cartridges directory instead of roms. Other than that the process is the same as for the roms we did (without the -cru flag, obviously). ti99sim will report which roms it has found on start-up and if there are any problems with them, so if anything fails that's the first thing to investigate. I know it's very convoluted, but it is all due to the fact that we need to create the roms. Unfortunately I don't have my Linux box set up, otherwise I could've simply attached the roms to this post and told you where to copy them. I would recommend that the first person who goes through this process does just that .

I just tried the compiler and wanted to report on a small change I needed to do (to my code) to make it compile with the new patch. I'm using the extern keyword to define cross-file global variables in my code. With the previous version the following worked: In file snd_engine.h: extern unsigned char[BUFFER_SIZE] sfxbuffer; In file snd_engine.c: unsigned char sfxbuffer[BUFFER_SIZE]; In file main.c: #include "snd_engine.h" load_song(sfxbuffer, "DSK1.MAIN_M", SONG_SIZE); play_song(sfxbuffer, SONG_NUMBER); With the new patch, this setup fails at the linking step with an undefined symbol error on the variable sfxbuffer. Changing the definition of sfxbuffer in snd_engine.c to: unsigned char sfxbuffer[BUFFER_SIZE] = { 0 }; solves the problem and the program compiles, links and runs fine. I just wanted to report it to ensure this is intentional/known behavior, and is not a symptom of some other bug. According to the C standard, the first version should work (without the initializer). Also of note, when compiling the version with the initializer with the old patch, the sfxbuffer ends up in the .data segment, whereas without it ends up in the .bss segment (which I believe is the correct behavior). With the new version it ends up in the .bss segment, so that looks good.

True, I could opt not to compress destructible blocks. The only problem that's left when using an RLE method then is how to quickly determine the starting column of a block of data that needs to be copied to the VDP. Hard to explain, so I'll take your cue and show a 1D example. Basically, for every 8 frames, I need to make sure that the full screen table (32 columns x 24 rows) has been update in VDP memory. Every 8 frames, the starting column of the map section I need to copy needs to be increased by 1. So, the first time I need to copy columns 0 - 31. After the screen has scrolled 8 pixels, I need to copy columns 1 - 32, after 16 pixels 2 - 33, and so forth. With the non-compressed map, this is trivial: I just copy 32 bytes (per row) from the array that represents the map to the VDP starting at the item that corresponds to the column that needs to be displayed on the left-most side of the screen (map[row][0], map[row][1], map[row][2], ...). All I need to do is increase a counter and use that as an index for the array. With RLE compression, I can't predict where in the map array to start looking, so I'd need to make sure I have a buffer of at least 32 bytes decompressed in advance. That can still work, and it's worth investigating actually. I'll run some tests to see how much the maps compress with RLE when not compressing destructible parts of the map. As an example: all blue (*edit*: cyan actually, not the blue background obviously ) and yellow blocks in this map are destructible:

I'm using a separate pattern table for sprites, since I change the screen pattern table every frame (or, more precisely every pixel scrolled). Using the screen pattern tables for sprites would lead to a lot of duplication that way. That also means that I only have two half sprite pattern tables at my disposal (one for the left facing main character + enemies and one for the right facing character + enemies), so adding the clouds as sprites is also a nogo, unfortunately. For reference, this is my VRAM layout: Graphics (scrolling levels) Bitmap (Title screen, etc...) ------------------------------------- ------------------------------------- Frame0 @ 0x0000, size 1024b Patterns @ 0x0000, size 6614b SIT1 @ 0x0400, size 756b Frame1 @ 0x0800, size 1024b SIT2 @ 0x0C00, size 756b Frame2 @ 0x1000, size 1024b SDT_R @ 0x1400, size 1024b Frame3 @ 0x1800, size 1024b SIT @ 0x1800, size 756b SDT_L @ 0x1C00, size 1024b SAL @ 0x1F80, size 128b Frame4 @ 0x2000, size 1024b Colors @ 0x2000, size 6614b PAB @ 0x2400, size +/- 64b CT @ 0x2440, size 16b Frame5 @ 0x2800, size 1024b FILEBUFF @ 0x2C00, size ? Frame6 @ 0x3000, size 1024b SAL @ 0x3400, size 128b Frame7 @ 0x3800, size 1024b SDT @ 0x3800, size 512b

Yup, that did the trick, thanks! I hadn't noticed it was a problem in libgcc (the gcc source tree is a mystical and mythical beast that hasn't shown me all it's secrets yet... lot's of learning still to do on that front ). I should point out that this was the first time I tried compiling with your script, and I actually never tried compiling libgcc in the past, so this might or might not be a new problem. I don't use any of the library's functions, so I'm set for now. Thank you very much for helping me out! For those that are interested in an OS X build, I can post it here. But it might be good to hold off on that until I can compile libgcc for a full package...