Fabrizio Caruso

Thanks/Grazie @Nop90! The penpal array was indeed confusing for me as well as Handy 0.95 which hides the Suzy bug. I am happy I got the Atari Lynx glitch sorted thanks to you. Next Atari target I need to improve is the Atari 7800, which is currently lacking real graphics in Cross-Lib. I would like to show make my games playable on the browser through a Javascript emulator as I do for some of my targets (VIC20, C64, Laser500, Laser 200, etc.). Any suggestion?

Thanks everyone here! Without you I was lost. I have managed to build fixed versions of all my 8 home-brews that I have written with my Cross-Lib framework: https://github.com/Fabrizio-Caruso/CROSS-LIB/releases/tag/atari_lynx

I got it to work by trial and error without fully understanding what I am doing... I delete the tile area by using black as foreground and it works: void _tgi_gfx_delete(uint8_t x, uint8_t y) { empty_spr->hpos = (x)*8; empty_spr->vpos = (y)*6; empty_spr->penpal[0] = 1; tgi_sprite(empty_spr); } void _tgi_gfx_draw(uint8_t x, uint8_t y, uint8_t tile, uint8_t color) { _tgi_gfx_delete(x, y); _tgi_tile[tile].hpos = (x)*8; _tgi_tile[tile].vpos = (y)*6; _tgi_tile[tile].penpal[0]=color; tgi_sprite(&(_tgi_tile[tile])); }

@Nop90Thanks a lot! I was setting penpal[0] with wrong values that made the sprite solid and so I was getting the Suzy bug (no final pixel). @Nop90 I can use your example to get my code to display transparent sprites! Now my goal is to get a total result that looks like a solid sprite without the Suzy bug. I need to clear the 8x6 "tile". How can I do it? My background color is black. I thought I could use tgi_bar (no idea what it does behind internally) but it does not produce the desired effect. Then I could just use a transparent black block with no transparent pixels but I don't know how to do it.

@LordKraken I don't understand how to have a transparent color in BPP1. You seem to say it is possible. What do you mean by "first color" ? You mean the color mapped to the "0" bits or the color 0 in the palette? If I do something like: _tgi_tile[i].sprctl0 = (unsigned char) (BPP_1 | TYPE_NORMAL | 0x07); ... _tgi_tile[i].penpal[0] = (unsigned char) 0x14; then the color mapped to 0 bit, is still not transparent.

@42bs, so I am confused. I am using 1BPP and 0 is not transparent. It is solid. If it can be made transparent, I would like to know how. What I need to do is display an 8 pixel wide 6 pixel solid high rectangle with just 1 foreground color (that may change on each 8x6 block) and a common background color. Probably irrelevant here: All such rectangles are aligned on 8 pixel wide 6 pixel. So they are sort of like "tiles". If I could display transparent + 1 color sprites in 1BPP, I could clear the area first and then display what I want so that the end result looks like an 8x6 tile. I need to display all pixels and avoid the hardware bug. Do you mean I can do it in 1BPP? Could you please tell me how?

Thanks @42bs, so BPP_1 has no transparent color... and with BPP1 I cannot display 8 pixels. I can do only 7 pixels or 15 pixels... In reality I don't need transparency. I would just be happy with 8 solid pixels with foreground and background color. I thought of transparency as a way to work around the hardware bug of the Suzy chip. So I have to use BPP_2, then how do I set a color to be transparent? Sorry if I ask basic questions... I have read some doc and I have not understood it. What is then penpal[0] in BPP_2 ? penpal[0] -> 00 penpal[1] -> 01 penpal[2] -> 10 penpal[3] -> 11 ? What do you mean by "don't care" ? you mean transparent ?

Hi everyone, I am struggling with what I thought was a rather simple problem. I need to display something as simple as an 8 pixel wide, 6 pixel high rectangles with just 1 color to chose for the foreground and 1 common background color. Due to a bug in Suzy chip if I do this I lose the 8th pixel on each line. If I add an extra dummy byte just to display the missing pixel, I end up deleting 8 (or 7) pixels on the right of my sprite. I am using something like this, which gives me a solid background with a missing last pixel and I don't know how to force Suzy to display the missing pixel without deleting 8 pixels to the right of the sprite. _tgi_tile[i].sprctl0 = (unsigned char) (BPP_1 | TYPE_NORMAL); _tgi_tile[i].sprctl1 = (unsigned char) (LITERAL | REHV); _tgi_tile[i].sprcoll = (unsigned char) NO_COLLIDE;

The binary for Stinger is not the correct one. It has corrupted tiles. The good one is here: https://github.com/Fabrizio-Caruso/CROSS-LIB/releases/download/stinger/Xstinger_atari_lynx_gfx.lnx

Sorry guys if this question is a bit out of scope: Is the main branch still compatible with libti99 (https://github.com/tursilion/libti99)? On a different but still related topic, do we have any chance that at least some basic input/output routines if not all libti99 could be distributed with the compiler to make things simpler for the user?

Hi everyone! How can I test the latest changes? I run git pull to pull the latest changes -> OK. Then if I rerun ./install.sh <path> it seems to be doing nothing. If before that I run cleanpatches.sh, then when I run ./install.sh I get the prompt "Reversed (or previously applied) patch detected! Assume -R? [n] y", to which I can answer y or no and in both cases I get failures.

@Tursi I agree with you that the compiler itself should not depend on any ROM, as it should be possible to use it to compile for other targets. On the other hand it would be very helpful if the compiler were distributed with a very thin (optional) library and by library I mean anything. It could just be a bunch of macros and not necessarily a fully fledged pre-compiled library to link. This is what is done on nearly all other 8-bit compilers (CC65 for the 6502, Z88DK for the I8080 and Z80, CMOC for the 6809, LCC1802 for the 1802, CC6303 for the 6800/3, etc.). You get a compiler together with a little (or big in some cases) dev-kit that allows you to handle some input/output on the target machine. So that your project only depends on one devkit, which you can install in one single step. Ideally your library or a sub-set of it could be optionally distributed with the compiler as long as you are not strongly against it.

There maybe multiple places as they may be scattered across different releases in my GitHub page. I can make it simpler for you. Nevertheless I would prefer to complete my current work on real graphics for the 7800 before people start playing the Atari 7800 versions because the current one look quite ugly. In theory the only way to get the most up to date versions of my game for any system is to download Cross-Lib, install the required compiler (cc65 for most MOS 6502 targets) and run: xl <game> <target> where <game> is one of these games: chase, shoot, bomber, snake, horde, verbix, shuriken, stinger and <target> can be atari, atari5200, atari7800, atari_lynx, c64, c16, vic20, zx81, c128, apple2, nes, gb (gameboy), gg (gamegear), sms, spectrum, msx, cpc, zx81, coco, coco3, dragon, mo5, to7, ti99, etc...

Hi @gambler172! All the 8 games written with my Cross-Lib framework (i.e., Chase, Shoot, Bomber, Snake, Horde, Verbix, Shuriken, Stinger) can be built for the Atari 7800 and for any of the 200 systems. Currently I build the games for the Atari 7800 only using 160A tile mode (3 colors + background) and with just the default tiles provided by CC65 (which is a subset of the ASCII set). No sound support yet. So on the Atari 7800 the games will only feature 4 colors and ASCII-like graphics. The game code is the same across 200 systems. So you get the very same game but the look and feel may be different. I am working on adding real tile support (not just ASCII). It is a matter of time. More colors is more complex due to the way the Atari 7800 chip works and that fact that my abstraction layer is only tile-based (no abstract sprites, so no hardware sprites). Using 160B mode with just tiles would impose other restrictions (number of tile shapes would be too low). So I may stick to 3+1 colors. P.S.: Most of the 8 games can be built optionally also in 320A mode (monochromatic but hires). Due to memory restrictions I cannot build some of them in this mode.

@RB5200 I may build a repository with up to date versions. The source of the library and sometimes the source code of the games is always updated and improved. So the ideal solution would be to build the games from source but I understand this is not practical for everyone.

@RB5200, all my 8 Cross-Lib games can be built for the Atari 5200, Atari Lynx, Atari 8-bit and Atari 7800 (better graphics is work in progress). Support for the Atari ST is still work in progress. The very same games can be built for about 200 systems. Not just Atari.

After double-checking what my Makefile is doing. I will try to reinstall gcc for ti, your library and redo all steps from scratch... I suspect I may be linking things that do not "match" in my script because gcc for ti is correctly building your examples. If I compile a single file as I do with your "make example", I get the right result. So it is a problem in my script. I thought someone with Assembly skills and knowledge of the TI99/4A could look at the produced binaries and see what is wrong in the one that does not work.

@Tursi So I know think that maybe I am linking the wrong things on the newly configured system of mine. Or I something my scripts do, depend on something that is very different in one system vs the other. Maybe I am linking a different version of the your library or the crt that I had compiled with a previous compiler. Something stupid like that maybe. I see that the binaries differ quite soon, so maybe the crt.

@Tursi, sorry for the confusion. My so called build-chain can take one single file but what my script does is several things including: compile some tools if necessary, compile the single file, compile the library source files, convert the abstract assets into something that can be included or linked with the other files, link all these things, apply some post-processing to produce disk/tape/crt images. To be precise this is what I am doing: https://github.com/Fabrizio-Caruso/CROSS-LIB/blob/master/src/Makefile_common#L2629 This can be reproduced in Cross-Lib by running the following commands from the src directory: xl clean && xl clean tools && xl rebuild helloworld ti99 Do you want me to provide the single .o files generated during the compilation? I never thought your make was not OK but I thought that maybe the newly modified gcc for ti was not OK. I now think it has no problem. I think I am doing something wrong and/or stupid.

Thanks @Tursi! I am not sure what you mean by compiling your example with my build chain because my build chain, as is, won't compile a single file. My build chain does a bunch of things, one of which is linking whatever you want to compile with my library source files (my so called library is just source files that are recompiled each time). So I cannot compile just your isolated example with Cross-Lib. I could embedded in the Cross-Lib project and compile it with my build-chain. Not sure this is useful. Do you mean to compile your example with your make file (make example) on the PC where I can't get my own Cross-Lib build chain to produce working examples? Your example works fine in any configuration. I have attached EXAMPLE (built under the PC where Cross-Lib is not working) On the other hand I have a helloworld example in Cross-Lib: https://github.com/Fabrizio-Caruso/CROSS-LIB/blob/master/src/examples/helloworld/main.c which I have compiled with my OK config and my KO config. I have attached both here. XHELLOWORLD1_KO EXAMPLE XHELLOWORLD1_OK

@Tursi I am sorry. The problem is most probably in my build-chain. Both the latest compiler and your lib are fine and work together with no issue for me. Your "make example" produced EXAMPLE (not EXAMPLE1). I could run it and it worked fine. So, this means that the problem is in my build-chain. It is not in my code because the very same code of mine works fine on a different PC of mine. Same code compiled on PC with old gcc 4 ti under Cygwin 32-bit: OK Same code compiled on PC with latest gcc 4 ti under Cygwin 64-bit: KO Maybe I am doing something wrong when I link the object files. The produced binaries are different as shown a previous post of mine. My (ugly) build chain is basically a portion of my Makefile: https://github.com/Fabrizio-Caruso/CROSS-LIB/blob/master/src/Makefile_common#L2629

I need to double check if my wrongly configured system is linking the same libti99.

@tursi, the problem could be on my side somehow, then, and only affect my project...

@tursi, sorry I have put good images... I have attached bad image of one of my games (which works on a different installation of gcc for ti). XBOMBER1 XBOMBER2

The different between the good (right) and the bad (left) is just a couple of bytes (in my case here start around $0000E0):