Display List Help

[toad]

p.s. let me attempt to answer my own question, and then everyone can tell me, how wrong it is....ha. Or maybe I get lucky.

 

Lets say you have some sixteen bit number stored, and in decimal the current score is 4412. Now you want to display four characters in some location on the screen, in a text mode. So, 4,4,1,2. Im thinking you go to some site like 6502.org, grab some optimized 16 bit math routine, and you divide 4412 by 1000. You get the result 4 plus some unimportant remainder. 4 is your first digit for display, you have some reordered character set, or some lookup table, so 4 becomes whatever value you actually need to place in the screen memory at whatever is the proper location. then you take 4 * 1000 =4000. and subtract that from 4412 and now you have 412....divide that by 100....and so on and so forth, and eventually you have the score placed on the display.

 

I know I must sound retarded, but is this essentially the process, or is there a much simpler way? I am just assuming I need to read through source code.... is their a particularly good repository of source code? well I mentioned 6502.org because that did come up in a google search, and had some math routines that looked good. But I am not sure I am on the right track or not....anyway, thanks

[MaPa]

Even this is possible solution, and updating score is as simple as ADC or SBC instruction, the displaying it on the screen is really bad. The 16bit math routines for dividing by 1000, 100 etc. is surely "slow" for this purpose. I don't know what is "ideal" solution for managing score, but something simple like storing individual digits in separate memory comes to my mind. So if you have your score 4412, you will store it in 4 bytes - 2, 1, 4, 4. Then the displaying is simple as LDA digit1, ADC #$10, STA screen, LDA digit2, ADC #$10, STA screen-1 etc. (if you are using default charset). On the other side you have do more work when updating score, not just simple ADC/SBC but you have to take digit by digit, adjust it, check for "carry" etc. but it is simple work with some instructions which will be much more faster than 16bit dividing.

 

Or you can use decimal mode of 6502 CPU as I did in my two games. I had 6 digit score, so 3 bytes used so your score 4412 I would store in sequence 12,44,00. Below is actual code for changing score from my game. The subroutine is called with points in A,X (if I want add or sub 1250 points I would put 50 into A and 12 into X). And displaying this score is something like LDA score+2, 4x LSR, and do whatever you need with topmost digit.... LDA score+2, AND #$f and do something with the second digit... etc.

 

 

;----------------------------------------------------------------------------------------------------
; CHANGING SCORE
;----------------------------------------------------------------------------------------------------
change_score_plus
 sed
 clc
 adc score
 sta score
 txa
 adc score+1
 sta score+1
 lda #0
 adc score+2
 sta score+2
 cld
 rts

change_score_minus
 sta tmp_a
 stx tmp_x
 sed
 sec
 lda score
 sbc tmp_a
 sta score
 lda score+1
 sbc tmp_x
 sta score+1
 lda score+2
 sbc #0
 sta score+2
 bcs ret
 lda #0
:3  sta score+#
ret  cld
 rts

tmp_a dta 0

tmp_x dta 0

[TMR]

i just keep one byte for each digit of the score and have them all counting 0 to 9...

[toad]

Thanks both! This is cool, now I need to write some assembly tonight...

[+playsoft]

Best case with Pokey Timers is to have the OS switched out and use the hardware vector direct.

Additional to that, make the Timer the only possible source of an IRQ which means there becomes no need to do bit testing, you only then need to disable/enable the Timer again to allow the next required IRQ.

 

Jitter is generally unavoidable with any interrupt due to the fact that 6502 will always finish an executing instruction before servicing an interrupt. On C64 on technique is to use 2 IRQs and have the first IRQ sit executing short instructions so the second one has a guaranteed "short" jitter.

 

We have the WSync register which allows a guaranteed known cycle position on the scanline but of course it can be defeating the purpose of using Timers rather than DLI in the first place if we want to conserve every possible machine cycle.

 

The other thing with Timers is that in emulation the accuracy is generally not very accurate. Altirra generally gets them cycle perfect but most others will only be scanline accurate which is next to useless for many purposes.

 

Thank you for the explanation of the jitter, what I saw initially makes sense now. I already have the timer as the only IRQ, but I'd not swapped out the OS - I will try and see if that gives a more consistent zone on the XL/XE. I tried on another emulator and that was completely out, so this is not practical at all really.

[Synthpopalooza]

As far as keeping score tallies: Convert each digit to ASCII (by adding 48 to the value) then store each character on the screen ... by reading each char location on the screen and incrementing it, you can keep a tally of the score. The screen in this case acts double duty: Displaying the score, and providing a memory location where each digit of the score is stored.

[phaeron]

Regarding IRQ jitter -- another issue is that the XL/XE OS dispatches immediate IRQs two cycles later than OS-B due to an additional CLD instruction. It turns out that Altirra's built-in OS was also missing this instruction, which I'm going to fix, but I'd recommend either taking this into account or taking over the IRQ vector directly if you are only targeting XL/XE machines.

[Rybags]

OS in or out is more an overhead issue than jitter. The instruction path should be constant.

 

The other thing to note is that it can be a misconception about needing to reload the AUDF value - it's not required if the same delay is used. The Timers operate in continuous mode, not one shot mode. That's a saving of several cycles.

[+playsoft]

Swapping out the OS brings the change in earlier but also gives consistent positioning on the NTSC 800XL and PAL 130XE which I don't think I had before - according to my notes I had a slight (1 char) difference there.

[kamakazi]

Thanks guys for the information you have shared. I'm going to start working on some Assembly routines to see if I have actually learned anything (LOL). I am planning on using the setup on my PeeCee to see what all I can do. If that fails I can always switch to the real Atari and use BASIC combined with Assembly Subs to see what happens. One way or another I will have something.

 

As for the comment made earlier about me converting BASIC to ASSEMBLY; I am well aware that an Atari can't do this but I have played around with a feature in my Atari DOS that converts BASIC programs into BIN files. I was thinking that once the BIN file is created I might could find a way to bring it to the PC where I can disassemble it and explore it. It was just a theory.

 

Thanks again guys and keep the ideas coming.

[Rybags]

Basic programs can be compiled, that is the feature you'd want to look at. Turbo Basic being one of the most prominent.

 

Saving the Basic workspace in Dos as a .Bin won't do anything useful. The program in memory is just a bunch of tokens, packed decimal numbers, strings and the like. Although there are PC-side utilities that can convert back into a Basic listing.

[kamakazi]

After discovering a link from another post on these forums, I played around a bit with Easy 6502's website and some simple assembly code. I did OK and picked up quick on the Load, Store, Increase, Decrease, and BNE commands but still need to learn a few more things for BEQ, SBC, and others. Transfer opcodes were not that difficult to use either. The only downfall to this is that it is strictly for the 6502 processor (which I assume has some graphics abilities of its own or the Javascript sampler window has a simple graphics routine in its code) and the Atari has four other processors to worry about.

 

Here was the code I used (part was already there, modified by me, and the last part was added by me from memory...scary huh?)

 

LDA #$04
STA $05ff
LDA #$05
STA $0200
LDA #$08
STA $0402
LDA #$07
STA $04FF

 

All this did was place pixels on the screen with set colors. The "screen resolution" for the sampler starts at $0200 for the top-left and ends at $05ff on the bottom right. So I am learning something it's just taking me a long time to comprehend for some reason...I'm blaming all the years of BASIC programming for it LOL. It's too bad that there are not tutorial books on creating just the display lists for Atari home computers and consoles which are broken down into baby steps. It is a time consuming lesson but I'm enjoying every minute of it!

 

I think I've shared the image before but since it has been so long ago I'll post it again so that others will see what kind of project idea I have in mind.

 

 

This is a game I made during college that went on paper in 2005, had mock ups made during a college course in 2011 which ultimately ended up being fully developed using Photoshop for graphics and DarkBASIC Professional for code work within 3 weeks time. It is a game that I would like to port over to the Atari's and published. I'm not in it for the money, don't get me wrong, but one of my lifetime goals has been to work for Atari making games and seeing other people enjoy the work. This image is of the real game, not a mock up, and what I was close to wanting to achieve on an Atari. This game was for one player since being on a laptop, and considering the amount of time it took to make the game so I could get actual screenshots for a college document, I simply didn't have the time to develop it further for two-players. But since the Atari has four controller ports I have often considered trying to make the game where it can support four players simultaneously but I'm not sure if the screen size would be able to handle all elements on the screen and still have enough space to make it enjoyable.

 

For those that are curious, this is not a Breakout style game even if the game is based on that style. It's a simple match three game. There are no extra lives and the blocks in the playfield work their way toward the bottom of the screen in a timely fashion. Once any block reaches the paddle it's game over and a final score is given. I wanted to keep an arcade-style game play with this project and I feel I have achieved that in the Windows version I created. Now I just want to port it over to Atari so Atari fans can try the game and I can see their reactions. The game's current name is Blast 'Em.

 

When the project was finished I shared it on DarkBASIC's forums (The Game Creator's). To my surprise I went back to the website the next day and a member had been putting the game through it's paces try to get as high of a score as possible. After that I thought it would be cool to see the game reach a point where a high score is sitting in a database somewhere with a person's name and their record score. That is the drive behind making it for Atari. I believe the highest score that member made was over 40,000 points. And, no, it does not have any special moves or ways to earn bonus points other than when a round is completed.

 

Now that everyone reading this knows of what I am trying to do, and I'm showing that I am serious about learning assembly so that game can be the best it can be, I've got more Assembly to learn. I'll check back in a few days. Wish me luck and any other secrets or tricks that advanced assembly programmers would like to share I'd love to hear them.

[kamakazi]

OK...dumb question...and I thought there was one Atari game that did something similar and I've played the game a thousand times or more. Super Breakout on the 5200 has a ball counter on the left side of the playfield. Did Atari use a single screen mode and just draw the font in a graphics format to the screen or did they use dual screen modes to accomplish the ball counter/playfield combination? If that first part is the case, then using a single screen mode I will, drawing the HUD display I must. I don't mind having to draw the text on the screen if I have to I was just trying to make sure I would be under 32k.

[kenjennings]

Looking at a few videos on youtube... it's kind of hard to tell how wide the playfield is.. but it looks like 5200 Superbreakout uses a Player to display the vertical line of text. I've done the same thing in some games to display scores and status. Of course, the graphics are not overly complicated, so if the game screen is based on a text mode it could also be done with a redefined character set.