7800 Programming

[Tempest]

Has anyone taken a serious stab at programming the 7800? What is it like? Is it similar to programming for the 2600 or more like the 400/800 and 5200?

 

Dan, I've taken a look at your Robotron code and I've got to admit I'm lost. There are some new commands in there I'm not familar with and there seems to be alot of tables and such. I'm hoping that the documentation I get with the 7800 Developers Kit will help me understand, but this may be over my head. Maybe my Agent X game will be for the 5200 afterall, but I'd love to tap into the 7800's superior graphics abilities. With the 5200 I had help from various people who were experienced with the 400/800 so it made learning the 5200 much easier (a big thank you to Debro, Nukey Shay, and Cafeman), but I don't think I can be one of the pioneers of 7800 programming (I'll leave that to Dan).

 

Tempest

[DanBoris]

I haven't heard from anyone who is actively working on programming the 7800 so you would be a pioneer if you got into it. I think the system will be fairly easy to program once someone comes up with a good sprite engine for it. Once that is figured out it will definitly be easier then the 2600 to program and may even be easier then the 5200 especially if you want to have a lot of sprites on the screen at one time.

 

Dan

[Tempest]

I definetly want to have lots of sprites on the screen (a Cloak & Dagger type games demands it). Maybe I will look into it after I get Cypher done. It would be nice to work with some actual development software (from the developers kit), rather than just typing in code by hand and hoping it runs in the emulator right.

 

Tempest

[Heaven/TQA]

Hi Dan & tempest,

 

well... I started to code on Atari 7800. The 1st code was like yours... a Scroller... ;=)

 

well. as a demo coder of course the screen was full of scrollers.

 

i have gone through the robotron as well...

 

it is not so complicated as it might look for the 1st time... (you should go through our 2d-fullscreen-bumpmapping-routine for atari 800 instead... or our 3d-rubiks-cube-source... ;=))

 

but you are right. the maria chip is quite powerful BUT yes...we need a

sprite engine. i am working on it.

 

if we have a working sprite engine routine it would be interesting to put sprites on a background! and after that...scroll the

background as well... it was so easy on 8bit atari...

 

if i have understood robotron source...

 

the main structure is:

 

1 calc the positions

2 update the position-tabs

3 render the screen

4 goto 1

 

rendering goese like

 

3.1 get positions

3.2 get from precalculated tables the

adresses of the sprite data and the

sprite data offset. as well as the

region where the sprite should be positioned

(vertically)

3.3 generate the DLLs

3.4 start VBL

 

looks simple and must be. it is like updating the Displaylist of Atari 800 or

5200 every VBL.

 

mainscreen-structure is like

 

region 0

region 1

region 2

...

 

where each region is a 160x8 screen-block

 

and all sprites are stored

0

0

0

0

0

0

0

0

data

data

data

 

so you have 0s as offset into your sprite data...

 

it is not so complicated as i have it described...

 

dan: one question...how is robotron

splitting the sprites when they cross

2 regions?

 

heaven/taquart

http://www.s-direktnet.de/homepages/k_nadj/main.html

[DanBoris]

Robotron actually uses 16 line high regions on the screen not 8. The sprite data is padded out with extra 0's to make each sprite 16 lines high. The beauty of the 7800 is that you never have to touch this data like you do on the 5200/8-bits. You move the sprite up and down in each region by chaning the pointer to the sprite data in each DL entry.

 

I am not sure how Robotron handles crossing region boundries but it shouldn't be to hard to do:

 

1. Determine which region the sprite starts in.

 

2. Write the DL entry into the first region with the memory pointer adjusted to the correct point in the sprite data so the image starts on the correct line.

 

3. Caluclate if the the sprite spans into a second region.

 

4. Write the DL entry into the second region with the memory pointer adjusted into the graphics data so it picks up where the first region left off.

 

This sounds more complicated then it really is. Since the display regions should ideally by 8 or 16 lines high the calulation needed above should be quite easy.

 

This is also where Holey DMA comes in, which I admit that I didn't understand until I started thinking about the sprite engine. When you need to move a sprite down in a region it is necessary to point the memory pointer to an address that actually outside the graphics data. Holey DMA causes these reads outside the graphics data to return a 0 instead of garbage graphics.

 

Next thing I need to turn my mind to is how scrolling is done on the 7800, should be fun

 

 

Dan

[Heaven/TQA]

still one mindblasting question left for me:

 

is it the best to determinate the max.

amount of sprites in 1 scanline?

 

otherwise put every dl on dladr+dl*128?

and each entry takes 4-5 bytes so we

have max. 64 sprites per region?

 

or am i completly wrong?

[DanBoris]

This is an interesting issue. I see two approaches to doing this. The way you describe is how Robotron does it. With 128 bytes for each DL you can get either 128/4 = 32 or 128/5 = 25 sprites on each line. For most games this isn't a big limitation since each a game like robotron doesn't have more then 50 or so sprites total, you just have to be careful that a situation doesn't come up in the game where you overrun one of the DLs. The advantage to this method is that it is easy to implement in your sprite engine. The disadvantages are that it wastes a lot or RAM since it any one time most of the DL memory area is empty, and the limited number of sprite per line.

 

The second method would be to build the DLs one by one, placing each right after the other in memory. You would go through your sprite list, find each one that appears in the first region and build that DL. You would then repeat the process for the second DL, etc. The advantage to this method is that it takes less memory and you don't have the limitation of how many sprite go on each line. The disadvantage is that the sprite engine would have to be more complex and would take much longer to execute.

 

Also remeber that there is a physical limitation to how many sprites can be on a line. The MARIA chip has a limited amount of time to generate each line.

 

Dan

[DanBoris]

None that I have seen. A graphics tool would be very useful because of the unusual way graphics data has to be orginized on the 7800.

 

Dan

[Eckhard Stolberg]

There are some ST based tools that came with Atari's development system. I once saw the disk images on the net, but I forgot where it was. But you probably wouldn't want to work on the ST anyway.

 

The tools it had were an assembler, a graphics converter, that extracted sprite data for the 160 pixels with 4 colours mode from Neopaint files, and a sound effects editor for the TIA, that did it's output through the dev cart.

 

I wrote a similar sound tool for DOS, that works with a 7800 with a new BIOS chip installed or a VCS with a Supercharger or something similar. The modification to the 7800 is pretty simple for PAL machines and would also allow you to test your code on a real machine, if you would also modify a 7800 game cartridge into a RAM cart.

 

You probably wouldn't want to do music with the TIA though. Some 7800 games, like Ballblazer, came with a POKEY chip in the cartridge, which might be much better suited. If you have some good sound editing tools and music playback routines for the POKEY, maybe you could share them with us. I'm sure the people on this board who are currently try to programm the 5200 would also appreciate those.

 

The PC cross-assembler that most people use for programming the 2600 and the 5200 is DASM 2.12.04 by Matt Dillon and Olaf Seibert. It might be a good idea to use this for 7800 programming as well.

 

And for Dan:

Scrolling is pretty easy on the 7800 too. You have to set up a DLL for 243 lines, but only 192 or so get actually displayed (for NTSC 7800s). And you can set up more than 243 lines without a problem. The MARIA would just ignore the one that are too much. So for vertical scrolling you can just set up a 16 lines region in the invisible part in the top of the screen. If you reduce the number of lines for this region, the screen would scroll upwards. When you have reached zero lines for this region, just reset it to 16, remove the topmost 16 line region of the actual display from the DLL and add a new region DL to the invisible part at the end of the screen.

 

Horizontal scrolling is also very easy. For each object you can specify a horizontal starting position in the DL. There are 256 possible positions, but only 160 of them are on the screen (this is also true for the 320 pixel modes). If you position an 8 pixel object at position 255, then the last 7 pixels would be wrapped to position 0 in the same line. So if you'd increase the position for all your objects by one, your screen would slowly scroll to the left in an endless loop. With the character mode, you can easiely build up a tile based background, that you can scroll left and right. Whenever a tile has disappeared on one of the sides, you can rewrite the tile list, that your DL points to, and that way create an even larger background than the 256 pixels.

 

 

Ciao, Eckhard Stolberg

[Atari-Jess]

but is it easier to work on the 7800 than the 5200 or what?

[Jetboot Jack]

7800 Development systems supplied by Atari in the late 80's were ST based and used MADMAC as the assembler.

 

Neopaint with a convertor for the art, and a 2 voice sequencer for the risible audio hardware....

 

No POKEY tool was supplied - I used a custom written 8Bit program to do POKEY tunes - but never moved them over to 7800...

 

I have to say I found the XL/XE hardware far more flexible than the 7800 to work with.

 

The 7800's sprite facilities were cool, but the awful scrolling (it was tedious compared with ANTIC) and image management compared with the PAM hardware was readily apparent. The audio was atrocious and I'd grown used to character set indirection and developed a pretty nice sprite multiplexer on the ANTIC/GTIA hardware......

 

I'd have to say that homebrew 5200 would be far easier, simply because its just a RAM challenged XL/XE and that hardware is easy to use and well documented.....

 

sTeVE

[Heaven/TQA]

but 5200 is no challenge because the 5200 is actually an xl...

 

for any atari 8bit devtool:

 

try our taquart 6502 ms dos atari assembler

xasm (you can find it on my website)

it is quite strange in a 1st look but has

really cool features which makes coding

easy, f.e. build in sin-generator and

new "adressing modes" & commands like

"add" (no clc, adc anymore...)

 

but it is mainly done for dev code on

8bit atari but maybe suitable for 5200

as well...

 

other tools can be found on the net and

where compiled on taquart-ftp server.

the url you find as well on my website. just scroll down to the links.

 

when i code on atari i use following tools

 

-xasm for coding on pc

-hip-converter for hires 160x200x30 pictures

-taquart fastpacker which is really fast pack-routine

-pokey-replay routine for 4/8 channel pokey music with 2 digi channels

-music was composed by our own musician with...damned i forgot the composing tool...

-several font editors

-own texture-editors for mode9-gfx (80x60x16)

...

-Atari 800win 2.6 emulator

 

i dont know if you know that 8bit is possible to do "HIP"-pictures which are

nearly 160x200x30 pictures because of an "bug" in the atari GTIA. antic mode 9+10 combined brings you fab grafics... read

my faq on hip on my website, too:

www.s-direktnet.de/homepages/k_nadj/main.html

 

Heaven/TQA

[Heaven/TQA]

and check out

http://www.uni-karlsruhe.de/~Marek.Tomczyk

 

steve, i am interesting in your sprite

multiplexer? any more detailed informations?

[Heaven/TQA]

check the demo links out

 

or

http://ajax.umcs.lublin.pl/~mfranczak/atari/index.html

 

for gfx, music tools (theta music composers, f.e.)

 

but i recommend to check the "demo-links" from atari 8bit resort on uni-karlsruhe...

 

and if you want to have some nice demos/games check this archive out

http://www-user.tu-chemnitz.de/~sgl/atari/

[Heaven/TQA]

oops. of course 128 div 4 is not 64...

[Heaven/TQA]

so...

 

we from taquart have many dev tools for coding on 8bit atari (gfx, msx, others...)

 

but are there any for atari 7800?

 

f.e. font-editors, sprite editors, gfx editors, gfx converters, assemblers

 

music replay-routines... and so on...

[Jetboot Jack]

Heaven/TQA

 

It's been a while (like over 8 years) now since I touched any XE programming - I have promised several people that I will exhume my (and my collegues) old work and pop it onto a web page.

 

The sprite multiplexer was used in Shadow of the Beast and a demo of Last Ninja II for getting 4 multicolour or 8 mono sprites (64 pixels) worth per scan line w/o flicker (well mostly) - hideous horizontal timing routines though!!!

 

We abandoned it for other games as it was very timing intensive, we had to use narrow playfield to get enuff DMA time, and then used software sprites in dynamically redefined characeter sets which were nearly just as good...

 

As soon as I have unpacked my belongings (I moved to the US from the UK recently) I hope to start uploading files...

 

sTeVE

[Jetboot Jack]

BTW - I have found my copy of ENVISION PC - a great tool that lets you build and animate with characters on the PC and output the data for XE.

 

Its DOS based, but works in win 95/98/2000 just fine.

 

sTeVE

[Heaven/TQA]

steve!

 

post me your routines!!! they must be

great...

 

never heard of shadows of the beast or ninja 2 port...(do i missed the last ninja?)

 

a good job was also system 3's international karate development which looks great better than the c64 original and does not worked with player/missle but with fonts! (the karata champs...)

 

archer mclean rocks! (i love dropzone...)

and the music was done by rob hubbard...and it was a hybrid floppy disk (b-side was the c64 code...)

 

heaven

[Jetboot Jack]

Back in the day I and a few friends did some work for ATARI UK. We produced 3 cheap assed games for them - all unreleased (Contagion, Z-force and an ST title).

 

I then set up a company with some industry vetrans to eek some sales out of the 8bit as ATARI dumped their hardware - HARLEQUIN - and we signed Psygnosis, System 3 and Grandslam - we released PLASTRON...

 

We had MENACE, Barbarian, Shadow of the Beast, Last Ninja II, Paperboy and more in developemnt, plus some originals too (Zero War (urgh!) and Project Xanthien).

 

The XE market was awful - Plastron sold very few units and we found our games spread everywhere, too much piracy!

 

We pulled the plug on the company and went our seperate ways - I joined Microprose as a games designer - the rest is history...

[DEBRO]

quote:

---

Originally posted by Eckhard Stolberg:

There are some ST based tools that came with Atari's development system. I once saw the disk images on the net, but I forgot where it was. But you probably wouldn't want to work on the ST anyway.

---

 

Here is a site with some ST disk images. I'm not sure if this is the one you're thinking of.

 

http://www.pipeline.com/~jhardie/