Jump to content
IGNORED

Going from Emulator to 5200 hardware


Recommended Posts

A continuation from my first post in the 5200 forum. Click here to see my site about Koffi if you want to refer to pictures via VSS, which I think were starting to look pretty darn good:

http://cafeman.www9.50megs.com/atari/5200d...offiKopter.html

 

I was in for a bit of a shock when I tried out Koffi: Yellow Kopter on the 5200 tonight. It didn't look nearly as good as it does while running the ROM on either VSS or Atari800win!

 

Now, mostly it is just that the colors have slightly different hues than what I was going for. The cloud pixels, for example, purple on an emulator, are more reddish maroon in hue on the machine. Didn't exactly like that. Also, color #$02 which I use for the clouds interior, it is black on the 5200 just like color #$00 is. I can see no difference between the two.

 

So I will need to adjust the colors, and it will be difficult and I'll need to right and re-write Eproms because I just can't tell from the PC what the end result is going to look like. My solution is to incorporate some color-changing logic in my program and link it to one of the keypad buttons. That way I can play around with the colors on the machine and not have to re-write the eprom so much (which, I haven't gotten my own eprom programmer yet anyway).

 

The other thing that disappoints me is Koffi's appearance. His eyes are a blurry mess -- I can't clearly see his eyes. I mean, you can tell he has eyes and that they blink, but the blue I use for his eyes doesn't mesh well with the yellow i use for his body and it seems to smear into each other a bit. This seems strange because I can see in other games where 1 pixel stands out more clearly; why not on Koffi? For example in Joust, look at the Joust Ostrich -- one color, but its yellow pixels are clear and defined against the black bg. Maybe I'll have to brighten Koffi's yellow (if possible) and just use black for his eyes... once again, it will take experimentation.

 

I think the game runs faster on the actual machine, too. I cycle through 2 or 3 colors for the fire and it flashes to quickly on the actual machine.

 

Okay, the thing that really has me worried is that my DLI background register color changes are not static. They seem to jump between 1 and 2 scanlines. I assume I am using up too much time in my DLI, but even at the bottom, where I do something like this:

 

code:


ldx #$6a ;

stx COLBK ; bg change

sta WSYNC ; next scanline

dex

dex

stx COLBK

sta WSYNC ; next scanline

dex

dex

stx COLBK

sta WSYNC ; next scanline

dex

dex

stx COLBK

sta WSYNC ; next scanline

dex

dex

stx COLBK

sta WSYNC ; next scanline

dex

dex

stx COLBK

 

 

;rwltst

pla ; pop X

tax

pla ; pop accumulator

rti ; Return from interrupt

 


 

Even those lines seem to have movement, although I am only doing 2 dex's between the WSync. I checked out Moon Patrol -- its DLI color bg changes are rock solid. Any advice here?

 

My other minor problem is that I'm still in widescreen mode, so the background color extends left and right of the actual playfield graphics. Somebody pointed out how to correct that & I just didn't do it yet.

 

More observations -- control is FINE. Koffi is easy to control and stops on a dime. I tried using the trak-ball but it wouldn't move koffi at all. I thought the machine reads the trak-ball signal just like the analog sticks but there is obviously more to it than that.

 

So, my first look at Koffi was actually exciting and quite disappointing all at the same time. I'm sure that changine colors around will make the game look more like the pictures I've shown, but the non-solid appearance of my DLI lines in the background worries me.

 

By the way, I didn't write the eprom myself -- I need to get an eprom programmer soon. Any suggestions are welcome, I have no idea what is out there. Cheap but reliable is good.

 

[ 01-07-2002: Message edited by: Cafeman ]

Link to comment
Share on other sites

quote:

Originally posted by Cafeman:

[snip] More observations -- control is FINE. Koffi is easy to control and stops on a dime. I tried using the trak-ball but it wouldn't move koffi at all. I thought the machine reads the trak-ball signal just like the analog sticks but there is obviously more to it than that. [snip]

 

Remember the code I supplied simulates a digital joystick. The Trak-ball is analog like the paddles. There will have to be some code changes for Trak-ball support. I was going to look into the Trak-ball but I thought it would be hard to simulate looking at an emulator. I'll see if I can look into it though.

 

quote:

Originally posted by Cafeman:

Okay, the thing that really has me worried is that my DLI background register color changes are not static. They seem to jump between 1 and 2 scanlines. I assume I am using up too much time in my DLI, but even at the bottom, where I do something like this: [snip]

Any advice here?

Your DLI looks strange. I'm not looking at my docs right now but why not use VCOUNT to find out which scan line you are on?

 

Another way to do this is have 5 DLIs. Then in the first DLI do you color changes and set the next DLI vector to the next DLI routine until you have reached your 5. For example the generic DLI routine could look like:

code:


DLIRoutine

sta WSYNC ; wait for horizontal sync

sta COLBK ; accumulator is the background color

 

stx VDSLST ; x is the low byte of the next DLI

sty VDSLST+1 ; y is the high byte of the next DLI

jmp XITVBL ; Restore the registers and return from interrupt


 

Then the first DLI would look like:

code:


DLI1

pha

txa

pha

tya

pha

 

lda #$6A

sta colorChange

ldx #&ltDLI2

ldy #>DLI2

 

dec colorChange

 

jmp DLIRoutine

 

The second DLI would look like:

code:


DLI2

pha

txa

pha

tya

pha

 

lda colorChange

ldx #&ltDLI3

ldy #>DLI3

 

dec colorChange

 

jmp DLIRoutine

Just a suggestion though.

 

Hopefully later on I'll be able to look at my docs and give better insight.

Link to comment
Share on other sites

That DLI code is just the bottom part of it. I experimented with doing that kind of thing; it seemed to work; I kept it.

 

Basically I have 6 DLI's, or so. Everytime I enter a DLI, I increment a variable. So everytime I enter a DLI from the Display List, the variable counts 1 2 3 4 5 and 6. In effect, I am counting 'scanlines' -- but I don't enter a DLI on every scanline.

 

After that, I do something like this:

 

code:


lda #DliLine

cmp #$01

beq DLI1

cmp #$02

beq DLI2

...

 

DLI1

... color register changes

pla

tax

pla

rti

 

DLI2

... color register changes

pla

tax

pla

rti

 


 

I thought by doing it this way I'd have enough cycles per DLI, even though I have duplicate code. I was afraid that if I made it more modular, and each DLI-n jmp'd to a common end, I may run out of cycles. I hope you understand what I'm trying to say. I could show the entire long DLI here if you want.

 

[ 01-08-2002: Message edited by: Cafeman ]

Link to comment
Share on other sites

You should be able to use VCOUNT for your scanline count. I think the current scanline would be VCOUNT-1.

 

I would suggest starting out going modular (reads better I think) and later if you found you needed the cycles remove the jumps and duplicate code.

Link to comment
Share on other sites

short info:

 

i do my dlis in this way:

 

set it directly in the displaylist... no long dlis...

 

dli1

 

pha

txa

pha

tya

pha

sta wsync

do the stuff

lda #

sta dliv (512 on atari 800)

lda #>dli2

sta dliv+1

pla

tay

pla

tax

pla

rti

 

dli2

 

same as above just pointing to dli3...

 

last dli

does not enter the new vector or even the vector to dli1...

 

my vbl routine sets the correct pointer to dli1...

 

if you need a dli in between a line than

point the dli directly to it with WSYNCs...because in character mode you just can set the dli-bits on 8/16 scanline modes...

 

maybe this helps...

 

btw. you should not have jumping scanlines with "STA WSYNCS"... i would switch each dli off and try each of your 6 dlis... if they are jumping and then switching them on separatly: 1, 2,3,4,5,6, 1+2, 1+2+3, 1+2+3+4, ...

 

maybe you can trace which or when your routines get out of sync...

 

hve

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

Link to comment
Share on other sites

I follow what you guys are saying about the trak-ball code.

 

If I were to change the logic to trak-ball logic, I'd have to look for a range of POT0 and POT1 numbers. Range1 would move left or right 1 pixel, Range2 would move left or right, 2 pixels, etc?

 

Second thing -- An Eprom Emulator. Hmmm, so it would plug into my 5200 cart that I plug the eprom into? And I'd have to have the PC running side-by-side with the 5200 on a tv set? And there is no slowdown of access via RAM, as opposed to right off an Eprom?

 

That sounds fast, but I really need the ability to write Eproms and I doubt and Eprom emulator does that too. I will review it though, thanks for the tip.

 

The other alternative I have is to tie in a color cycling routine with keypad keys. If I press 1, it will increase Pyro's color by 1, 2 will decrease the value. Pressing 3 would change to the next table value which might be Koffi's first color, etc. That doesn't sound all that tough to implement, if I need to.

Link to comment
Share on other sites

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by Cafeman:

<STRONG> I tried using the trak-ball but it wouldn't move koffi at all. I thought the machine reads the trak-ball signal just like the analog sticks but there is obviously more to it than that.

</STRONG><HR></BLOCKQUOTE>

 

The 5200 does read the track ball just like an analog stick. The speed you rotate the ball is equivelant to how far you push the stick in a specific direction. So rolling the ball slowly to the left is like pushing the stick slightly to the left. Rlling the ball quickly to the left is like pushing the stick hard to the left.

 

The reason is probably doesn't work with Koffi is that I assume you are checking for the stick value to go above or below a certain value to read each direction. The track ball may never get over these limits, or it might have to be rolled very fast to reach them.

 

A game like Koffi that simulates a digital stick from the analog stick won't work with the trackball. But a game that actually reads the stick as analog (Centipede for example) will work with the trackball.

 

For anyone who is interested the schematic for the trackball is on my web page.

 

Moderator Edit: Dans Page is located here: http://atarihq.com/danb

Link to comment
Share on other sites

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by Cafeman:

<STRONG>So I will need to adjust the colors, and it will be difficult and I'll need to right and re-write Eproms because I just can't tell from the PC what the end result is going to look like.

</STRONG><HR></BLOCKQUOTE>

 

You might want to invest in an EPROM emulator. This is device that plugs into your PC, and into the socket where you would put the EPROM and simulates the EPROM via RAM. You run a program on your PC to download the code to the emulator and the system sees it just like an EPROM.

 

I have one from a company called Souther Cross, you can see it here:

 

Moderator Edit: Search for it on http://www.wiltronics.com.au

 

I used it quite extensivly when I was reverse engineering the Odyssey 2. It works great and is reasonably priced.

Link to comment
Share on other sites

quote:

Originally posted by Dan Boris:

The 5200 does read the track ball just like an analog stick. The speed you rotate the ball is equivelant to how far you push the stick in a specific direction...

 

The reason is probably doesn't work with Koffi is that I assume you are checking for the stick value to go above or below a certain value to read each direction. The track ball may never get over these limits, or it might have to be rolled very fast to reach them.

 

A game like Koffi that simulates a digital stick from the analog stick won't work with the trackball. But a game that actually reads the stick as analog (Centipede for example) will work with the trackball...

Dan

 

That's what I was thinking. The Trak-ball (and the 5200 joypad when you're not simulating a digital controller) is more of a position controller like the paddles for Stella. You would have to calculate the position based on the value of the POT read instead of looking to see if the stick was pushed and moving a certain number of pixels.

Link to comment
Share on other sites

well... i never seen in arcade games that the player can change every (!) color of the game... think about it...

 

normally i would not use the shadow registers of atari instead of direct access of them (do not know if possible on 5200...)

 

and now you would probably have to change your whole code from

 

color_init

lda #color1

sta colpm0

lda #color2

sta colpm1

...

 

into

 

lda color1

sta colpm0

lda color2

sta colpm1

 

and maybe you run out of zeropage adresses...

 

a solution could be just let the user increase the brightness like in quake...or what is common now in every 3d ego shooter...

 

i had the same experience when i coded maybe 8 years ago a demo and when i saw it few weeks after release later on another machine not my 130xe devkit (a REAL one...with 1 MB!) the background color was a complete another one...

 

so my fire routine with "reflections on whater below it" turned into "green" water...

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

 

and download "carpe diem" demo...

 

final words: do not care too much about it... the players do not know how the colors look right... so they will not recognize it... we in software business say "don't die in buty" "nicht in schoenheit sterben"... ;=)

 

heaven

Link to comment
Share on other sites

and here is a quote found in the source code i wrote 1997 (see the site i gave u...)

 

"...as you study the code you can maybe recognize

some patches... they were done because

of the damned deadline for the party... and

what are coders do if they do not find the bug???

 

they approximate the whole fx to the bug so the

bug IS the FX...

 

well... to be TRUE... if you run really unreal you

can see that the center-pixel is not correct f.e.

i dont know why but my twirl-generator could not calculate

the center-pixel correct... (circle with radius 1)

so i had to do a patch..."

 

really unreal intro comment, 1997

Link to comment
Share on other sites

quote:

Originally posted by Cafeman:

I follow what you guys are saying about the trak-ball code.

 

If I were to change the logic to trak-ball logic, I'd have to look for a range of POT0 and POT1 numbers. Range1 would move left or right 1 pixel, Range2 would move left or right, 2 pixels, etc? [snip]

 

I have some code I experimented with last night and it works fine in Atari800WinPlus. I had to use the mouse to simulate the joystick. It's not too bad and less code the the digital joystick routine.

 

I'd like to send it to O.G. for a test but until then...

 

code:


CheckHorizontalMove

 

lda PADDL0

lsr

 

clc

adc #LEFT_EXTREME

 

cmp #RIGHT_EXTREME

bcc StorePlayerHorizontalPosition

 

lda #RIGHT_EXTREME

StorePlayerHorizontalPosition

sta PLAYERH

rts

 

This is just for the horizontal movement. The vertical movement is pretty much the same. If you are using zero lines above and below your player to erase "dirty" bits (as I am with my demo) you will have to change your routine to do a true clear of the data and a redraw in the new position.

 

Again, please note that this has note been tested on the 5200 yet.

 

Enjoy

Link to comment
Share on other sites

quote:

Originally posted by Cafeman:

Second thing -- An Eprom Emulator. Hmmm, so it would plug into my 5200 cart that I plug the eprom into? And I'd have to have the PC running side-by-side with the 5200 on a tv set? And there is no slowdown of access via RAM, as opposed to right off an Eprom?


 

Not quite, you plug the EPROM emulator into the 5200 cart and into the PC. No actual EPROM is needed. The emulator hooks to your PC parallel port so you can put an extension cable on it so your PC doesn't have to be right next to your 5200. There is no slow down, the 5200 see it as if it was an EPROM. The beauty of this is that you don't have to burn a real EPROM until your game is complete. If it works with the emualtor it will work exactly the same when you finally burn it to an EPROM.

 

Dan

Link to comment
Share on other sites

How much time does it take to burn a 32K ROM for the 5200? Is it two 16K ROMS? (I'm talking about using Eproms of course).

 

And Eproms are re-writable, correct?

 

If it only takes a moment to re-burn your eprom, and you can use the same one over & over again, I'm not sure I'd NEED an emulator.

 

Forgive my dumb questions, I really am an amateur & newbie at the chip side of this.

Link to comment
Share on other sites

To kind of expand on the thread from the 5200 forum...the Atari computer would make a great platform to test on. This would of course depend on you having one. If you're only going to produce for the 5200 then this could be a cheap way out. Using an APE cable and going to the 8-bit. I would like to do this too but I don't have an APE yet

 

As for the image size you could start your code at $8000. I'm sure you're probably no where near 32K in image size. Starting your code at $8000 instead of $4000 should give you a size of 16K.

 

This port should be really easy if you are using the equates header that Alan supplied.

Link to comment
Share on other sites

I do have a 1200XL, its not in the best condition though (my cousins dropped it a few times, me thinks).

 

I like the idea of getting a n eprom emulator. SOunds superior to burning eproms all the time. After all, I only want to burn an eprom once its all done -- and I can get others to do that for me.

 

Could I use one of these eprom emulators with ANY cart-based system? If not, which ones? Could I use it for GBA development?

Link to comment
Share on other sites

Yes, in theory they should work with any system that has a ROM. I have used it with the 7800 and the Odyssey 2, work great on both. The only trick can be building a socketed cartridge to plug the emulator into. For example the eprom emulator I use has a 28 pin connector on it, but O2 carts only take 24 pin EPROMS, so I had to so a little re-wiring to get it to work.

 

Dan

Link to comment
Share on other sites

I'm using the Pocket Programmer and their EPROM emulator - Pocket Programmer Link

Generally speaking it is a good product. The biggest disadvantage of it is the old DOS program that operates it...

 

BTW: Another approach that works just fine for the Vectrex guys is to create a non-voletile SRAM based cartridge (aka VECRAM). On one side it hooks up to the PC via the parallel port, on the other side it has the pinout of a cartridge. Once a BIN file has been downloaded into the SRAM it will stay there till a new file overwrites it. The VECRAM costs no more than $100... Although it can be directly used, it could be a nice idea to implement for any other cartridge based console...

 

O.G.

 

[ 01-10-2002: Message edited by: OldGuru ]

Link to comment
Share on other sites

I was looking at John Dondzilla's Vectrex page, he shows a picture of the Eprom Emulator he uses ... funny, this thread was the first time I recall hearing about one (or paying attention to it).

 

I assume he used his E.E. for both his Vectrex and CV development.

 

I am so incredibly un-knowledgable about wiring anything. I can program in several languages, but to do any wiring or elecronics work totally intimidates me. All of you homebrewers and coders seem to be equally apt at both sides of the game -- programming and the cart-building. It seems inevitable I must fork out the $$$ for an eprom emulator and learn how to build carts myself.

Link to comment
Share on other sites

quote:

Originally posted by DEBRO:

code:

CheckHorizontalMove

 

lda PADDL0

lsr

 

clc

adc #LEFT_EXTREME

 

cmp #RIGHT_EXTREME

bcc StorePlayerHorizontalPosition

 

lda #RIGHT_EXTREME

StorePlayerHorizontalPosition

sta PLAYERH

rts

 

This is just for the horizontal movement. The vertical movement is pretty much the same. If you are using zero lines above and below your player to erase "dirty" bits (as I am with my demo) you will have to change your routine to do a true clear of the data and a redraw in the new position.

 

Again, please note that this has note been tested on the 5200 yet.

 

Enjoy

 

GOOD NEWS...

 

I heard back from O.G. this weekend and the code will work on the 5200

 

Thanks again O.G.

 

He tested it with his joypad because he doesn't have a trak-ball but if all the information on the trak-ball is correct then this code should give your game Trak-ball support.

 

Roll on Koffi...

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...