F18A programming, info, and resources

[+Lee Stewart]

Impressive!

 

...lee

[matthew180]

Is there any way to use the PIX instruction on an off screen bitmap buffer?

Sorry, but no. The hardware doing the calculation includes the BML base address in the calculation and uses the calculated address to directly plot the pixel. The PIX instruction is also restricted to the original 16K of VRAM and cannot be used to plot pixels in a buffer in the 2K of GPU-RAM.

 

It would be really useful to be to be able to draw to a buffer that's not currently visible and then change the bitmap layer base address to point to your buffer once the drawing is done.

I can't think of a good way to do that without a firmware change. I really didn't consider double-buffering due to the already limited memory.

 

I suppose the 'A' bit in the instruction could have been better used to specify that a second register be used for the pixel address calculation.

 

Nice work by the way. Very cool!

[TheMole]

In this demo my mushroom logo is taking the F18A for a spin.

 

http://www.youtube.com/watch?v=ly0QLST4nl4

 

Source code and E/A#3 file attached. Only works on the hardware.

 

Tres cool! For some reason I immediately imagine a spinning/scaling batman logo and accompanying jingle...

[Asmusr]

I can't think of a good way to do that without a firmware change. I really didn't consider double-buffering due to the already limited memory.

 

The demo is actually using 3 buffers: the original image and two display buffers. Each one is 4K so there is still room for name table, pattern table, color table and the program. With more optimization, e.g. incremental calculation of the source address, I think you could double the frame rate.

[matthew180]

That just goes to show that you should never assume... Sorry. I really should not change the PIX instruction at this point, or mess with the new register assignments. Maybe next time. Heck, with the 500K FPGA I could include 2D (and maybe 3D) rotation, scale, translation, and sheer instructions. :-)

[RXB]

Number of Pixels and Screen size are the biggest issues with the future.

 

Currently the TI Video is like using a old Digital Watch with 16 colors and very small display.

 

Much like when playing on a PC and it forces you into 640x480 screen when using a 2048x1536 display. Huge waste of space!

 

Also if we had a mouse interface built into the VDP chip that was hardware based Disk Access would be the only real downside to making a modern UI.

[matthew180]

UPDATE: The first post of this thread was updated with a PDF document, contributed by Rasmus, containing many of the F18A technical posts from this forum. Thank you Rasmus for compiling the posts and making them available in a single document!

[Omega-TI]

UPDATE: The first post of this thread was updated with a PDF document, contributed by Rasmus, containing many of the F18A technical posts from this forum. Thank you Rasmus for compiling the posts and making them available in a single document!

 

NICE, good quality work too! Thanks!

 

I hope I did not overstep my bounds. But I thought it was so good it deserved a cover.

F18Cover.zip

Edited December 6, 2013 by Kevan

[RobertLM78]

Nice compilation of information on the "61384" . Thank you Rasmus!

[OX.]

I'd really like to see F18A emulation for the TI added to MESS.

[Asmusr]

A demo of isometric graphics made using tiles in ECM3 (8 color) mode. The graphics were created in Magellan. I found the pretty trees on the net.

 

 

If you run E/A#3 ECM3C from the disk, the screen will be scrolling, this time using the F18A scroll registers.

 

Edit: added Magellan file to the zip.

ECM3Scroll.zip

[matthew180]

This is absolutely fantastic! I would love to see a game made out of this!! A hack-n-slash like Diablo would be awesome.

[Asmusr]

The question is how to move sprites behind the trees, building etc. I know you can specify that a tile has priority over sprites, but I'm not sure that will be enough. I think you will have to change the sprite patterns dynamically based on the position, the tile map, and a depth map. Any good ideas?

[TheMole]

Neat graphics, would love to see this in action but don't have the F18A installed yet...

 

You could have a masking sprite per character sprite. The masking sprite would have a higher sprite number than the character sprite and follow the character sprite (although only moving in 8-pixel steps, so always on image pattern boundaries) and you'd have to load the patterns of the underlying background into the masking sprite's definition each time, but it should be doable. You might also need to have different patterns that have a transparent background if your image patterns use all 8 colors. Still easier than dynamically changing the sprite patterns I think.

 

All that said, I find nothing more frustrating if a character is truly hidden from view in a game and my real answer would probably be to let descent map design solve this for you. . If you don't want to hide the sprite but instead give the impression it is behind an object, you could consider one of the following cheap tricks:

• Flicker the character sprite whenever at least a portion of the sprite is supposed to be behind a background, making it appear somewhat translucent.
• Change the sprite definition to something that indicates the sprite is behind the current background image (which I suppose would then technically need to be called the foreground image), such as an outline of the character instead of a full colored-in version.

I tried loading the png into Magellan, but the colors become messed up and the map is truncated to the screen. Is there another way to load images into Magellan and let it turn it into character definitions, palette definitions and a scrollable map? It'd be great if one could load one of these and spit out map data: http://www.smspower.org/Maps/AlexKiddInMiracleWorld-SMS?gallerypage=The+City+of+Radaxian

[matthew180]

I think tile priority could still be used, but any isometric map engine is going to have to include some sort of depth-map component. The tile priority would probably have to be calculated and adjusted dynamically. I have never written an isometric map engine, so I don't have any practical experience or advice to give.

[RobertLM78]

This is absolutely fantastic! I would love to see a game made out of this!! A hack-n-slash like Diablo would be awesome.

Agreed!

[Asmusr]

I tried loading the png into Magellan, but the colors become messed up and the map is truncated to the screen. Is there another way to load images into Magellan and let it turn it into character definitions, palette definitions and a scrollable map? It'd be great if one could load one of these and spit out map data: http://www.smspower.org/Maps/AlexKiddInMiracleWorld-SMS?gallerypage=The+City+of+Radaxian

 

Magellan could really benefit from improved import functions. The existing Import Character Image function expects a 64*256 bitmap with unique characters (no map). I have added the Magellan file to my original post if you want to see how it looks.

 

Regarding the use a masking sprite, the tiles can have as many as 32 different colors within a 16x16 area, so you would need to plan the colors carefully or use several 8x8 masking sprites. I don't know if that's easier than changing the base sprite pattern - perhaps the invisible part could be changed to an outline as you suggest?

 

The problem using the tile priority is that it affects all instances of a tile on the screen, and also that the 'background layer' of each tile would be limited to one (transparent) color through which the sprites are visible. There are many places where tile priorities would be really useful, e.g. drawing the bridge that you walk under in a Commando clone, but I think the model may be too simple for an isometric game.

 

Another option for an isometric game would be to use the bitmap layer and software sprites. Much less colorful but, but it would allow you to draw real isometric tiles in back to front order. The GPU could easily handle this.

 

I'm not sure if I'm going to do any of this. I'm still looking for the really good idea for my next game...

[matthew180]

The problem using the tile priority is that it affects all instances of a tile on the screen, and also that the 'background layer' of each tile would be limited to one (transparent) color through which the sprites are visible.

This is one area I wish I had thought about longer or had some sort of game development experience to draw upon to make the hardware something that would be useful. A priority bit-map based on the tile's screen location would have been much more useful than on a per-tile basis.

 

However, I still think it could be done by having a set of unique tiles that are used to draw the tile map around where the player sprite is located. These would have their patterns updated and priorities set based on the depth information, and the rest of the map could be drawn without priority.

 

Hydlide managed it on a stock 9918A to great affect (although I don't know if this is a true isometric map, it is over-head like Zelda):

 

 

I'm not sure if I'm going to do any of this. I'm still looking for the really good idea for my next game...

How about something like Elite? Personally I would like to see something with a little more replay appeal. Classic coin-ops are great and all, but they were designed to eat your quarters and were generally pretty shallow. Resource management games tend to be very appealing, and procedural generation of the environment makes for a unique game every time.

 

That's why I mentioned a dungeon crawler. It mixes the fun of hacking and slashing monsters with the random nature of mazes and dungeons. They also tend to have the 10-second (kill the mob in front of you), 2-minute (get drops from killing mobs), and 10-minute (chests found on a level) goals of addictive games. Just my two cents.

[RobertLM78]

How about something like Elite?

:thumbsup: Hell yeah! I'd love to see that game on the TI

[Willsy]

How about KnightLore?

 

http://www.youtube.com/watch?v=7n7qtErhF-A

[TheMole]

The ZX Spectrum doesn't have a tile-based VDP, so the techniques applied there are difficult or impossible to use on the TI. Most of what you see on the system is probably pure "software rendering", which means that you easily achieve this by blitting in three phases: first all "background" tiles, then the "sprites" then the "foreground tiles".

 

As for that video of Hydlide 3, that's f*#kin' impressive! The graphics are very well designed, and I would've killed (well, not really...) to have something like that on the TI back in the day. Looking at it, my guess would be that they change patterns of the sprite depending on the foreground. The characters are obviously sprites since they flicker when 3 or more are on the same scanline, but they move in 8-pixel increments which would help reduce the number of patterns required to display the "behind stuff" versions of the sprite (since each foreground object has a different mask for the sprite). There's too many colors for the foreground to be masked with sprites, so it must be done using patterns. They might be doing this in real time by XOR-ing the tile-pattern definition with the sprite-pattern definition. This is only four XOR instructions in bitmap mode, but would be 12 in ECM3 3bpp mode. Then again, it could easily be done on the GPU and maybe that's the best answer to Rasmus' question:

• Keep a "source" copy of all sprite patterns somewhere in VRAM
• Every frame, for every sprite check whether it is in front or behind the current tiles it occupies (using a depth map, for instance).
• For every tile that is potentially in front of the sprite, there is a mask definition (basically a 1bpp tile pattern that distinguishes between foreground and background pixels).
• XOR this mask pattern with the sprite pattern into a new location that will be used by the actual sprite definition. Of course, if you want your sprites to move with pixel resolution you'll need to do some bit twiddling first to align the mask definition with the position of the sprite, but I image the GPU could do this with ease during VBLANK

But man, those are some nice 9918a graphics!

[Asmusr]

I tried loading the png into Magellan, but the colors become messed up and the map is truncated to the screen. Is there another way to load images into Magellan and let it turn it into character definitions, palette definitions and a scrollable map? It'd be great if one could load one of these and spit out map data: http://www.smspower.org/Maps/AlexKiddInMiracleWorld-SMS?gallerypage=The+City+of+Radaxian

 

I just realized how great a resource smspower is for ripping graphics for the TI. I will definitely add a map importing function to the next update of Magellan.

[matthew180]

Thanks to the help of Rasmus and Tursi, I’m happy to announce the in-system software update for the F18A firmware. Currently the update program only runs on a 99/4A and requires a bulk-storage device large enough to contain the update program, bit stream, and data file on the same "disk" (about 226KiB). Currently I recommend using a CF7/NanoPeb device.

 

I have updated the main thread with the download zip file and detailed instructions can found on my website here: http://codehackcreate.com/archives/418

 

If you have any problems or questions, please don't hesitate to ask. I have done everything I can to make sure the update runs smoothly, however keep in mind that as of time of writing it has only been tested in about seven systems. If you are nervous about the update, you might wait until it has been battle-tested by more people.

[+arcadeshopper]

I get a CRC error and it stops.. spacebar makes my TI reset..still works..1.3 rom

 

Funny thing is I get a different CRC error each time, and different in EA and EA II

 

nanopeb 2.0 rs232 model and 4a..

 

Greg

[+arcadeshopper]

I tried another nanopeb (the COM model) and it worked fine 1.5 baby

 

need to find a memory test program I can copy to the peb I guess

 

Greg