138 replies to this topic

[kamakazi]

Mitch, on Mon Feb 15, 2010 5:26 PM, said:

GroovyBee, on Mon Feb 15, 2010 4:33 PM, said:

All the atari7800.net links in post #2 are dead for me.

That's because atari7800.net seems to have died. Most of those links were just copies of stuff from other pages anyway.
Atari7800.org dev page
Atari Museum 7800 tech doc page
Dan Boris' 7800 tech page

Mitch

Thank you 7800 Guy for posting those links.

[EricBall]

kamakazi, on Mon Feb 15, 2010 9:07 AM, said:

As stated earlier, I plan to use a PC for 7800 programming. Here is what I have so far... Crimson Editor + 7800 Emulator + DASM
Is there anything I'm missing?

Nope. With that you just need time and desire to start working. Graphics tools might help once you get beyond the "get something one the screen" phase and into the "make it look pretty" phase. However, you may find it just as easy creating sprites by hand rather than trying to use tools which don't speak 7800.

kamakazi, on Mon Feb 15, 2010 9:07 AM, said:

What I was thinking about attempting was using a ST emulator with all the development software Atari created. This stuff is available online. Would this attempt work?

Maybe. I don't know if anyone else has gone that route. It might be easier or hard than the DASM+emulator route.

kamakazi, on Mon Feb 15, 2010 9:07 AM, said:

Another approach to gaining knowledge of 7800 programming I thought about was learning the 2600 first. Even if it is another console, it might shed some light on developing 6502 assembly language skills.

The advantage of the 2600 over the 7800 is it's easy on the 2600 to get something on the screen. 3 lines of VSYNC+VBLANK and 262 lines of playing with TIA registers. While the 7800 you have to set up your display lists and your DLLs and then hope you didn't forget something or you're staring at a blank screen wondering what you did wrong. The nice thing about the 7800 is once you get that working most of the programming is data movement and AI, while on the 2600 you get into display kernel programming trying to update those TIA registers ahead of the beam.

kamakazi, on Mon Feb 15, 2010 9:07 AM, said:

Oh, I almost forgot...would anyone know how to test PC based 7800 programming efforts on a real 7800? This is mainly to test for any differences between an emulator and real hardware. Thanks again!

Ask. There are people on the forum with the right hardware (i.e. CC2) to help out.

[kamakazi]

Thanks Eric!

I don't mind hand-drawing the sprites. I have played with the 7800 development software on a real ST, and used the program that converts the NEOchrome art to the 7800 "S" file. On the PC side, would someone recommend an art program that might have similar features to NEOchrome and one that will work with Vista?

Edited by kamakazi, Tue Feb 16, 2010 6:56 PM.

[GroovyBee]

kamakazi, on Tue Feb 16, 2010 6:50 PM, said:

On the PC side, would someone recommend an art program that might have similar features to NEOchrome and one that will work with Vista?

I currently have a PC command line tool in beta testing that will convert normal windows *.bmp files into source/header files for 7800 projects. It supports MARIA's 160A, 160B, 320A and 320B. I'm probably going to add 320C support too. You can mix and match all supported modes.

[kamakazi]

Tried viewing Dan's 7800 Sprite Demo, but it locks up when the 7800's "ATARI" logo should disappear. I did follow Dan's instructions on how to compile the program and used the "make.bat" file to do so. I was going to compile it, see what it did, and try to gain Maria knowledge by trying the program with different sprites. However, running it in MESS is locking up the emulation. Any ideas would be greatly appreciated. Keep in mind that I was testing it in Dan's original presentation before playing around with it.

Edited by kamakazi, Thu Feb 18, 2010 8:42 PM.

[kamakazi]

Below is code generated using CharMapper78Beta. This is a small 8x16 sprite. I was just playing around with some of the program's features to see what was generated. As of present, I have no clue how to impliment it yet, but it others wanting to program the 7800 would like to use it, feel free to do so.

; 7800 160x2 Sprite Image Data



	.org	$C000

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;							
SPRITEDATA:				; SPRITE GRAPHICS IMAGE DATA!
;							
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
PADDLE:
	.byte	$00,$00	 ; Sprite # 0 


	.org	SPRITEDATA+$100

	.byte	$00,$00	 ; Sprite # 0 


	.org	SPRITEDATA+$200

	.byte	$00,$00	 ; Sprite # 0 


	.org	SPRITEDATA+$300

	.byte	$00,$00	 ; Sprite # 0 


	.org	SPRITEDATA+$400

	.byte	$00,$00	 ; Sprite # 0 


	.org	SPRITEDATA+$500

	.byte	$3F,$FC	 ; Sprite # 0 


	.org	SPRITEDATA+$600

	.byte	$FF,$FF	 ; Sprite # 0 


	.org	SPRITEDATA+$700

	.byte	$C0,$03	 ; Sprite # 0 


	.org	SPRITEDATA+$800

	.byte	$C0,$03	 ; Sprite # 0 


	.org	SPRITEDATA+$900

	.byte	$C0,$03	 ; Sprite # 0 


	.org	SPRITEDATA+$A00

	.byte	$C0,$03	 ; Sprite # 0 


	.org	SPRITEDATA+$B00

	.byte	$00,$00	 ; Sprite # 0 


	.org	SPRITEDATA+$C00

	.byte	$00,$00	 ; Sprite # 0 


	.org	SPRITEDATA+$D00

	.byte	$00,$00	 ; Sprite # 0 


	.org	SPRITEDATA+$E00

	.byte	$00,$00	 ; Sprite # 0 


	.org	SPRITEDATA+$F00

	.byte	$00,$00	 ; Sprite # 0 

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
;
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

I do need more information on setting up Display Lists and Display Lists Lists. Even after all I have read, that portion is still confusing to me. If someone could create examples that would help. Thanks!

[kamakazi]

I have a question...Since the 5200 and 7800 share similar processors...why couldn't one take a 5200 game and port it over the 7800 for learning purposes? I understand that there would be a lot of work to be done like address changes, setting up DL and DLLs, the graphics, but wouldn't the assembly code be similar? Just and idea.

[GroovyBee]

kamakazi, on Mon Feb 22, 2010 1:23 AM, said:

I have a question...Since the 5200 and 7800 share similar processors...why couldn't one take a 5200 game and port it over the 7800 for learning purposes?

If all you want is the logic and AI from a game you could start with any cartridge based 6502 based machine. It'll be a ton of work but you could start by adapting VIC-20 or C64 games. Personally, I'd stick with the cart version of any game first because its anti-piracy protection will be less (or none) when compared to a tape/disk based game.

[kamakazi]

GroovyBee, on Mon Feb 22, 2010 5:32 AM, said:

kamakazi, on Mon Feb 22, 2010 1:23 AM, said:

I have a question...Since the 5200 and 7800 share similar processors...why couldn't one take a 5200 game and port it over the 7800 for learning purposes?

If all you want is the logic and AI from a game you could start with any cartridge based 6502 based machine. It'll be a ton of work but you could start by adapting VIC-20 or C64 games. Personally, I'd stick with the cart version of any game first because its anti-piracy protection will be less (or none) when compared to a tape/disk based game.

What I was suggesting was porting over some 5200 games that the 7800 didn't get. The idea behind it would be the simple fact that 6502 game logic code would work allowing the coder to concentrate on the 7800's MARIA. It seems to me that the 7800s biggest issue is not controlling it, but getting even a single pixel on the screen. I will admit, it has the most awkward display routine I've ever seen.

[GroovyBee]

kamakazi, on Tue Feb 23, 2010 4:00 PM, said:

What I was suggesting was porting over some 5200 games that the 7800 didn't get. The idea behind it would be the simple fact that 6502 game logic code would work allowing the coder to concentrate on the 7800's MARIA.

There are other factors to take into account in a machine to machine conversion. Like the lack of linear video RAM and hardware sprite collision detection (both available on the 5200). Neither of which features are present in the 7800 by default. This might mean extra RAM in the cart is needed or software sprite collision detection (bounding box or ANDing together).

Quote

It seems to me that the 7800s biggest issue is not controlling it, but getting even a single pixel on the screen. I will admit, it has the most awkward display routine I've ever seen.

Actually I find it quite easy to get MARIA to do what I want .

[EricBall]

kamakazi, on Mon Feb 22, 2010 1:23 AM, said:

I have a question...Since the 5200 and 7800 share similar processors...why couldn't one take a 5200 game and port it over the 7800 for learning purposes? I understand that there would be a lot of work to be done like address changes, setting up DL and DLLs, the graphics, but wouldn't the assembly code be similar? Just and idea.

A game is made up of main two types of code - code which is responsible for getting stuff displayed, and code which is more display independent. (There's also code which does other I/O like user input and sound, but that's typically a much smaller piece.) You'd think it should be possible to somehow swap out the display dependent code, but unless the game was written with that in mind, you will probably find even the "display independent" code is structured to make the "display dependent" code as easy as possible. This might be something as simple as whether the GPU can reflect a sprite or whether Y=0 is the top or the bottom of the screen, but can be as challenging as bitmap versus tilemap backgrounds.

Additionally, trying to reuse code for porting without the original commented source code will be much more difficult. Not only will you have to create a reasonable disassembly, but you will need to reverse-engineer the context of each piece of code.

[GroovyBee]

kamakazi, on Mon Feb 22, 2010 1:23 AM, said:

I have a question...Since the 5200 and 7800 share similar processors...why couldn't one take a 5200 game and port it over the 7800 for learning purposes? I understand that there would be a lot of work to be done like address changes, setting up DL and DLLs, the graphics, but wouldn't the assembly code be similar? Just and idea.

The first BBC Micro home computer game port/adaptation to the 7800 has been successful (just a few glitches left for me to fix).

[etschuetz]

Not certain if this was mentioned yet, Crimson Editor is a dead app that hasn't been updated in years. I recommend Notepad++. Google it, and enjoy it. It does everything that Crimson Editor did, and a LOT more.

I admit, I was a crimson editor lover for a long time, as I used it when I was in college. It is just a shame it died.

--Edit--

Crap, just saw that it was edited may 2008, which was more than i expected. Either way Notepad++ and Crimson Editor are both good apps. Notepadd++ see's regular updates though.

Edited by etschuetz, Sun Aug 1, 2010 3:56 PM.

[gdement]

I can't think of much need for frequent updates on a text editor. If it's usable, has syntax highlighting, supports UNIX CR's, and doesn't have the bugs of MS notepad then it's good for me. notepad++'s politics turned me off, but looks like Crimson Editor is still updated as well.
http://sourceforge.n...ldeditor/files/
The homepage still says 2008 but sourceforge says 4/2010. They say it's now maintained by the "Emerald Editor community" so that might be why the Crimson site is out of date. The latest version I downloaded is something they call "SVN286", I can't find a real version number so I have no idea what that means. To me that just makes it sound like it was written for a 286.
I can't believe it took me this long to find out about it, it's really a nice editor. I've been using gVim but that has all the vim weirdness I could live without.

[kamakazi]

Ok...stupid question. How do you create the DL and DLL for the 7800...in English please?

[GroovyBee]

kamakazi, on Sun Sep 12, 2010 1:21 AM, said:

Ok...stupid question. How do you create the DL and DLL for the 7800...in English please?

There are several examples of how to do this in the programmers forum, plus the Atari and GCC MARIA documentation. You'll have to be more specific about what part(s) you are having problems with. Attaching your code will help too.

[kamakazi]

I guess I'm just wanting to understand what each does specifically how I go about building the lists. I mean, what determines how they are built? I know there are the documentations that talk about it, but I was hoping that some here would share their experiences with them.

I also don't quite understand the difference between the Display List and the Display List List. I have read the documents that GroovyBee has mentioned over and over...which ends in me scratching my head going, "huh?"

In all respect to the 7800, I'm surprised someone hasn't created a BASIC like program for developing 7800 programs in a similar fashion that batari BASIC has done for the 2600.

I know I've asked before but what PC programs are out there where I can attempt to create some sprites and background graphics?

Edited by kamakazi, Sun Sep 12, 2010 1:30 PM.

[GroovyBee]

kamakazi, on Sun Sep 12, 2010 1:08 PM, said:

I mean, what determines how they are built?

The needs of the game determine how the DL in each zone is constructed. Apart from adhering to TV standards, regarding the number of scan lines produced, there are no hard and fast rules (as long as you don't need to change the MARIA read mode on the fly).

Quote

I know there are the documentations that talk about it, but I was hoping that some here would share their experiences with them.

Personally I don't have any problem setting up DLLs and DLs for my games. However, without you specifying what you want to achieve its going to be hard to guide you in the right direction.

[kamakazi]

Ok...It's an idea that I've been working on for a while now. I figured that I would start with the 2600 first to learn assembly, but I ended up using the batari BASIC combined with VisualbB to start creating this idea. However, I ran into issues when trying to put a row of blocks on the screen on the 2600 using those tools. So, now I'm back on the 7800 trying to do the same game. I guess I could show the screenshot of the 2600 version to give an idea of what I'm trying to accomplish on the 7800.



Even if this is a 2600 screenshot, it will have to serve as a basis for showing my idea. The idea is to create a match game similar to PopCap's Bejeweled but present in the flavor of Atari's Breakout. I haven't made it that far yet, but at the start of each level, the game is to place a few rows of random colored blocks on the playfield. The object of the game is to have the player "shoot" blocks, also random in color, into the playfield in an attempt to try and match 3 or more blocks of the same color. The level ends when all blocks are removed.

There is a catch. As play progresses in any one level, the blocks will start to move toward the bottom of the screen, similar to Breakout's Progressive mode. If any one block reaches the Paddle area, then the game is over. I am also toying around with the idea of incorporating a ball graphic that will appear at random which will immediately remove any blocks it hits in a single pass. I may also allow the paddle to be destroyed by it if they collide with one another. I'm not sure on that one yet.

For starters, I would simply like to have the paddle on the 7800 screen, and have it movable. I may play around with Dan's sprite demo and see what I can come up with. I may need help getting a background on the display later. But, this should give a rough idea of what I'm trying to accomplish.

Edited by kamakazi, Sun Sep 12, 2010 1:58 PM.

[GroovyBee]

How about starting a new thread in the programmers section or homebrew section and we'll take it from there?

[gdement]

kamakazi, on Sun Sep 12, 2010 1:08 PM, said:

I also don't quite understand the difference between the Display List and the Display List List.

The Maria works one scanline at a time. For each scanline, it will read the corresponding Display List. This list tells Maria what graphic objects (sprites) to render on that line. For each listed object, Maria locates the actual graphic data, and reads one line of graphics for that object and renders it. It keeps doing this until everything in the display list has been rendered, and thus the scanline is complete.

The same display list can be reused on multiple lines. Typically you use the same display list for 8 or 16 consecutive lines. This means Maria will attempt to render all of the same objects on each of those 16 lines. The graphics data will require a different vertical offset as you proceed to each new line. Maria handles this offset automatically. It will also allow objects to "disappear" on lines where they should not be visible.


The DLL tells Maria which Display List to use for each scanline.
Typically, after 8 or 16 lines, you will switch to a completely new Display List with a different list of objects in it. The DLL defines the range of scanlines where each Display List will be used.

[EricBall]

Easy stuff first (i.e. answers exist in the forum)

kamakazi, on Sun Sep 12, 2010 1:08 PM, said:

I also don't quite understand the difference between the Display List and the Display List List. I have read the documents that GroovyBee has mentioned over and over...which ends in me scratching my head going, "huh?"

Display List List Help

kamakazi, on Sun Sep 12, 2010 1:08 PM, said:

I guess I'm just wanting to understand what each does specifically how I go about building the lists. I mean, what determines how they are built? I know there are the documentations that talk about it, but I was hoping that some here would share their experiences with them.

Sample 7800 source code
Sample 7800 source code using (ZP,X)

kamakazi, on Sun Sep 12, 2010 1:08 PM, said:

In all respect to the 7800, I'm surprised someone hasn't created a BASIC like program for developing 7800 programs in a similar fashion that batari BASIC has done for the 2600.

It's a time & effort issue. Maybe if you want a tool like batari BASIC you can assist GroovyBee with his toolset.

[kamakazi]

Well, I played around with Dan's Sprite Demo for the 7800 and changed the sprite. I now have a rather skinny space ship looking thing LOL.



Now, if I could only figure out how to do a full screen playfield

[EricBall]

kamakazi, on Mon Sep 13, 2010 11:41 AM, said:

Now, if I could only figure out how to do a full screen playfield

Except the 7800 doesn't have a playfield. It does, however, have indirect or character mode where the display list entry points to a string of characters (tile indexes).

[kamakazi]

Let's see if I understand correctly how the Display List and Display List List work. I won't be displaying any code but putting in English basically what I am understanding these do.

First, graphics are put in a Display List, so to speak. Without using the OFFSET, it is to my understanding that each raster (or sprite) would need its own DL. When Maria goes to "fetch" the graphics data, it uses a Display List List that will point to the DLs. Is this right?