Windows Tools for Atari Programming

[+MrFish]

A modified version of Atari800Win emulator that dumps all the fonts pointed by CHBASE at the end of frame. If character set is modified on runtime then it can create a lot of files...

 

Nice! I just tested it on Bosconian...

[+MrFish]

If you want to really have fun, open up Bomb Jack. :D

[funkheld]

hello, this programm not loaded :

 

https://ataritools.fr.gd/ATARITOOLS_800--k1-8_BIT-k2-.htm

 

 

greeting

Edited October 14, 2018 by funkheld

[funkheld]

Hi good afternoon.

I'm looking for a disassembler for xex files for a pc.

Thank you.

greeting

[Wrathchild]

I'd recommend using Altirra's debugger as a first port-of-call.

 

You can also try tools such as DIS6502 (searching the forum could have revealed this)

[AtariNutcase]

I prefer using the Atari Altirra emulator by Avery Lee. Sometimes though it's hard to save a disk program. Like for example recently I've been writing a lot of tutorials in Basic on my new website, but getting errors such as ERROR 162, 139, etc. I have gone through I tried to recreate the disk images, but this one isn't budging.

 

So it would be really beneficial if someone can maybe point out what I am doing wrong. I also have added the disk drive file DOS25.XFD so it can jump into DOS with no issues. I also have the BASIC attached as a cartridge.

 

It seems like I have everything working as it should, but still can't save any new images.

 

My website is https://www.atari65xe.com

 

I appreciate your help everyone! Glad to be here

Edited March 4, 2019 by AtariNutcase

[+Stephen]

I prefer using the Atari Altirra emulator by Avery Lee. Sometimes though it's hard to save a disk program. Like for example recently I've been writing a lot of tutorials in Basic on my new website, but getting errors such as ERROR 162, 139, etc. I have gone through I tried to recreate the disk images, but this one isn't budging.

 

So it would be really beneficial if someone can maybe point out what I am doing wrong. I also have added the disk drive file DOS25.XFD so it can jump into DOS with no issues. I also have the BASIC attached as a cartridge.

 

It seems like I have everything working as it should, but still can't save any new images.

 

My website is https://www.atari65xe.com

 

I appreciate your help everyone! Glad to be here

Error 139 is device NAK (not aknowledged). If you are trying to save to a non-exitsent drive for example. I think error 162 is directory full. All DOS2 derivatives only allow for 64 files.

[Wrathchild]

For dev work I find it handy to simply map a drive area using the "Host Device (H:)" set to also install as "D:"

There is a nice option here too as you can use H6 rather than H1 and when saving via LIST"H6:NAME.BAS" the end-of-lines are saved as a CR/LF rather then the Atari's $9B character.

 

[tebe]

C64 65XE Debugger (2019-02-22)

https://sourceforge.net/projects/c64-debugger/

 

[+Stephen]

Wow!!

[Yaron Nir]

I was wondering if there is a sprite editor tool that produces a byte array for mode E?

 

something like, you choose sprite wide (4,8,12,16,20 ....) you choose sprite height and you start "litting" up pixels

then you can export this into C or ASM byte array code that can be drawn in mode E (bitpairs)

 

any1?

[Irgendwer]

I think your use-case is covered by the "Image->Convert to PMG" function of Graph2Font:

 

 

You just have to filter the exportable data according to your needs.

 

 

[Yaron Nir]

Why PMG?

I am looking for bitpairs for mode E...

[emkay]

Why PMG?

I am looking for bitpairs for mode E...

I guess, you want to draw a "Sprite" , then the tool exports the graphics with 4 shifted Bitpairs , and to use it for preshifting tables to import it to your Assembler?

[Irgendwer]

I am looking for bitpairs for mode E...

 

Ok, I see.

You could produce the images with "Atari Graphics Studio" http://madteam.atari8.info/uzytki/ags.7z

and bribe TeBe that he allows to change the size for the MIC format - which seems currently tied to the static 160x192 pixels...

...or you "filter/cut-out" the MIC data produced by the studio (read some bytes, skip some etc. - even something in TB-XL would work).

 

Or you bribe me to create something more convenient for the command line, like "PNG in -> multiple 2-bit graphics which are surrounded by a frame of whatever size out"...

[Yaron Nir]

 

Ok, I see.

You could produce the images with "Atari Graphics Studio" http://madteam.atari8.info/uzytki/ags.7z

and bribe TeBe that he allows to change the size for the MIC format - which seems currently tied to the static 160x192 pixels...

...or you "filter/cut-out" the MIC data produced by the studio (read some bytes, skip some etc. - even something in TB-XL would work).

 

Or you bribe me to create something more convenient for the command line, like "PNG in -> multiple 2-bit graphics which are surrounded by a frame of whatever size out"...

 

hahaha

what do you want as a bribe i can ofer some nice routines in CC65 but i guess for you it won't mean much

 

so, yes, if you could kindly create a command line utility (win10 compatible) the get as input "file.png" and also get the frame size x,y and also get the spacing size x,y between frames and produces a byte array of the image frames that is C compatible.

 

I have the power to name you a "Night" (same as sir jamey named Brienne of Tarth to be a night in game of thrones )

beleive me it is worth it

[Wrathchild]

Shhhhh... silent 'K'

 

[Yaron Nir]

?

[sanny]

Just watched this movie again last week

[Irgendwer]

I have the power to name you a "Night" (same as sir jamey named Brienne of Tarth to be a night in game of thrones )

beleive me it is worth it

 

Ok, to be called "Sir Irgendwer" sounds quite tempting (hoping you really meant "knight"...)

 

So here I am:

 

img2sprites is a command line tool which

• is quite untested (please do so)
• needs badly a more verbose documentation than my facts here (any volunteer?)
• is a .NET console application developed under Linux with Mono but (should) work flawlessly under Windows too
• is executed with a filename as argument
• this filename is the input image, .NET (should) support BMP, GIF, JPEG (not really suitable), PNG & TIFF
• the top most line in the image has to contain the translation palette from left to right, the leftmost pixel is the background color the

  order of the other colors decide which index the color has in the target raw data

  so if the image "starts" with "white", "yellow", "pink" then "white" is the background (0), "pink" is 1 and "yellow" is 2

• the program detects the number of colors in the first line. In the explained case you have three colors, so 2 bit per pixels are needed in the target data

  (you could add a fourth color which still would fit into 2 bits per pixels)

• the palette is only for the pixel value assignment. The color values itself are not part of the output or translated into a "best-fit" of the Atari palettte!
• depending on the palette size the converter automatically produces 1,2,3 or 4 bit(s) per pixel target raw data. 3 bits/8 colors don't make much sense as the target bytes have two spare bits then. The 4 bit per color case is more interesting for the GTIA modes (untested)!
• output data in the source image is detected by frames which are not the background color - any other color will do (no need to be part of the palette). The user data is inside of a frame, having a one pixel margin to it.
• colors in the user data which are not part of the palette are ignored (-> background)
• You can have as many frames in a single image as you want and position the frames freely in the source image. The detection of frames is from top to bottom, left to right.
• Raw data of the frames is created in files consisting of the source filename and an enumeration. (test.png -> test001.spr test002.spr ...)
• Every line is padded to a full byte
• the option "-v" before the filename will output info about the conversion process (try it out!)
• the option "-h" before the filename puts the width in bytes, width in pixels and height in pixels in front of the produced raw data (a byte each)
• dimension of frames greater than 8 bit (255) are unsupported!
• the dimension of the source file is not restricted. You can produce the images in any size and with any tool you like (f.e. "GrafX2" if you like to have the 2:1 aspect ratio of pixels during edit) even the bitmap output of G2F makes sense!
• raw data to source code conversion is not a task of this tool! Please use xxd or other tools for this step! (But of course the the raw data is suitable for an ".incbin" in assembly code!)

The archive contains this small 2 bit per pixel sample image:

 

Don't hesitate to report bugs.

img2sprites.exe.zip

Edited May 11, 2019 by Irgendwer

[Yaron Nir]

First and foremost, I sir. Yaron, name thy irgendwer (or do you prefer Christian ? ) name thy to be a great knight!

may all the presents here be my witnesses.

hear hear for the new Knight sir. irgendwer!!!!

 

As for you provided tool:

1. To start with - excellent work in such short time.

2. it works on win10 as well

3. love the idea that it recognized the frames automatically and the colors. that will be good technique for the png provider to be using.

4. love the verbos option and the output of it. will use it all the time for proof references

5. i converted your png and got 4 spr files. as you stated, the files were binary files.

so i run xxd on them to produce C files and it worked.

this is what i got for the first spr file:

unsigned char __4ColorDemo001_spr[] = {
  0x14, 0x14, 0x00, 0xff, 0xff, 0xff, 0x28, 0x28, 0xaa
};
unsigned int __4ColorDemo001_spr_len = 9;

5. this is a great start. what is missing from this is:

- The definitions of the colors used in the png

(for example, before the array sprite definition, have a color array definition to hold the 3 colors that were being used)

- Can this be combined into 1 file containing all frames rather than 1 file per frame? i will have many many frames and i will get lost with all these many files

- can your tool contain the convertion to C, or should i write a batch file script that do that. preference - have it all in 1 tool.

 

Besides that - many many thanks christian. excellent work. and much appreciated.

[Wrathchild]

For 5, it was explained "the palette is only for the pixel value assignment. The color values itself are not part of the output or translated into a "best-fit" of the Atari palettte!"

The ordering of the colours determined the index used, e.g. the first value in your C output is 0x14 so these are pixels "00 01 01 00", a mix of background and COLOR0.

Having a tool map the, presumably RGB, colour to an A8 index depends on many things, e.g. PAL/NTSC differences.

It would usually need the supplying of a palette file and a method to find the closest match, as can be seen in RasterConverter.

So it is best left up to you to code the colours in your application by setting COLOR0 to COLOR4 appropriately using, say, the palette viewer in Altirra as a guide.

If you need a quick command line tool, sources can be found here.

[Yaron Nir]

Hey mark,

I understand. Yes basically if I have the bit-pairs I can code the colors later myself to my needs , should be very easy.

Thank you!

[Irgendwer]

Besides that - many many thanks christian. excellent work. and much appreciated.

 

Thanks! I will see if I find the time to go for a single file output. Normally this would require to produce the information for offsets to the frames too. (Ideally hi- and low-byte separated tables...)

Don't expect too much in the nearer future while a simple shell script should also be able to join the files...

 

Direct C-source output is out-of-scope for me, as this would open an additional construction side - and xxd does a solid job. You may get the notion that I favor small, somewhat connectable tools instead of producing a jack of all trades device.

 

Thanks Mark, for explaining the reason for (non-)handling of palettes.

 

And thanks to all who liked my content and just "elected" me this way into the exclusive lodge of users with more likes than posts!

[popmilo]

Ok. Guess I need to do this to get that knight title

 

It's a python script bundled as exe... Don't ask me why it's 28Mb

 

Run exe with "--help" to get description.

 

Parameters are filename of image to convert, bunch of integer values as number of sprites in x,y dir on spritesheet, sizes etc.
Also included bitpair convert feature. Input bitpair order as string "2031" and it will convert shades of gray from 0123 to 2031 as atari bitpairs.

 

In archive you'll find png image of Double dragon frames and convert.bat script for testing.

 

Guess I'll leave Yaron to write a nicer description

 

convert_sprites.zip