Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

e1will

Members
 View Profile  See their activity

  • Content Count

    364

  • Joined

  • Last visited

Posts posted by e1will

  1. Posted

    Could ASM be used to put three scores on the screen

     

    Yes... but if you want to stick with bBasic you could just show them on alternate frames. Show one for a few seconds, then the other, color-coded to help indicate what's what.

     

    --Will

  3. Posted

    I noticed that if you reset a player multiple times on one scan line it isn't drawn at all. I lost the original program I found this in (I was afraid of asking then) so I modified the How to Draw a Playfield example to show this. Is this a bug in stella, or can you not do this on a real Atari? I thought I read somware that you could do this to make a backround that repetaed the same pattern over and over again but I can't remember where that was. thanks in advance for your answeres.

     

    I haven't gone through the .asm you posted, but here's how I do it in the game I'm working on:

     

    WriteLives
STA WSYNC
NOP3
WriteLives_loop
LDA graphicPtr,Y
DEY
BPL KeepOnWriting
RTS
KeepOnWriting
STA.w GRP0
STA GRP1
REPEAT 8
STA RESP0
STA RESP1
REPEND
STA RESP0
STX GRP1
STX GRP0
JMP WriteLives_loop

     

    It's a little clunky, but it works. Give that a try in Stella... works fine with 2.8.x and 3.0.

     

    Hope this helps.

     

    --Will

  5. Posted · Edited by e1will

    I am worried of a potential con where there is noise on the controller lines, and by accident, we get 1100, and then are stuck in driving controller mode, when we really have a joystick plugged in. How high is the probability of something like this happening?

     

    I don't have any info on the driving controllers (I'd be curious to see some of those answers myself), but regarding "sticking" them in driving controller mode, you could always snap back to joystick mode if you saw a 10nn or 01nn pattern, meaning they'd pushed the joystick left or right. Should be a quick test you can run every few frames as a sanity check... chances are if there was a noise issue where the game thought it was a DC but they had a joystick, the player would probably wiggle it in various directions to get a response.

     

    --Will

  7. Posted · Edited by e1will

    Hello everyone!

     

    Here's the latest version: v0.11.

     

    This has a new feature for AtariVox and SaveKey users (and Stella users too): You can save your game and return to it later. This is handy if you've reached level 14 or so and don't want to lose your place, but need to go do something else. (Like play Juno First for a few hours.) You can load your game exactly where you left off when you return.

     

    To save your game, go to the egg shelf room (screenshot attached) and press the Fire button on the joystick. If the program was able to save the game successfully, it will move you to the score room. If it was unsuccessful, it will move you to the credits room. It will be unsuccessful if you don't have an AtariVox or SaveKey attached (or if you're running in an emulator and don't have the game properties configured to use an AtariVox or SaveKey as the P1 controller.)

     

    To load your game, start a new game, go to the egg shelf room and press Reset on the console. If the program was able to load the game successfully, it will move you to the score room; if not, to the credits room.

     

    Special thanks to stephena and especially cd-w for the help in getting the AtariVox interface working correctly.

     

    There is a known issue where the screen will roll while it's reading from or writing to the save file. That's on the to-fix list.

     

    I've got some more neat stuff on the way for the next version, so stay tuned...

     

    --Will

    post-23222-126032533704_thumb.png

  8. Posted

    Is there additional documentation available for the optimized code? I was just going by the code example from AtariVox.rtf (revision date 2004-NOV-16), perhaps that doc is out of date?

    No, I never do documentation. :)

     

    Unfortunately I am pretty busy over the next weeks, so most likely I won't have time to look at the code again. Maybe someone else can help?

     

    Oh, no problem. I've got it working with the original code, so I'm using that. (Actually, I'm trying my own optimizations at that, which I'll post if they work.)

     

    --Will

  9. Posted

    Thanks! My problem now is that the 107-byte optimized code gave me just enough room to get the save/load features in... I had to temporarily comment some stuff out to get the 169-byte original to fit, so I'm going to be in code-squish mode for a while. 32k seemed so roomy when I started!

    The optimized code was tested to work, so I suppose that it is mainly a documentation flaw. Probably a return value is different from what you expect.

     

    Is there additional documentation available for the optimized code? I was just going by the code example from AtariVox.rtf (revision date 2004-NOV-16), perhaps that doc is out of date?

     

    --Will

  10. Posted

    I'm glad you got it to work - I guess there are still some issues with the optimised i2c code. I'm looking forward to hearing speech in Duck Attack now - it is a really nice original game.

     

    Cheers,

    Chris

     

    Thanks! My problem now is that the 107-byte optimized code gave me just enough room to get the save/load features in... I had to temporarily comment some stuff out to get the 169-byte original to fit, so I'm going to be in code-squish mode for a while. 32k seemed so roomy when I started!

     

    --Will

  11. Posted

    I am using the unoptimised version in Juno First - I think it would be best to start with this code.

     

    Chris

     

    Swapping in the original i2c.inc fixed the issue! I'm able to write to the .dat without problems now. I'm using the same example code, the only change is including i2c.inc instead of i2c_v2_2.inc.

     

    Thanks for the debugging help; I really appreciate it.

     

    --Will

  12. Posted

    I'm not sure - try it without this test and see what happens :)

     

    Chris

     

    Well, if I comment out the BCS (and the ROR I just added) and just let the example code plow on through with its jsr i2c_txbytes, the .dat file is not updated (contents all $FF, Windows modification date unchanged.)

     

    I assume you're not using Thomas's optimized version in Juno First? Would I be better served to just use Alex's original version? Or are there known bugs with it?

     

    --Will

     

     

    buffer = $80

jsr	i2c_startwrite	; Start signal and $a0 command byte
;   ROR
;	bcs	eeprom_error	; exit if command byte not acknowledged

lda	#$01			; upper byte of address
jsr	i2c_txbyte
lda	#$40			; lower byte of address
jsr	i2c_txbyte

ldx	#$00
write_loop
lda	buffer,x		; get byte from RAM
jsr	i2c_txbyte		; transmit to EEPROM
inx
cpx	#$08			; 8 bytes sent?
bne	write_loop

jsr	i2c_stopwrite	; terminate write and commit to memory
clc

rts

eeprom_error
jsr	i2c_stopwrite	; terminate write and commit to memory
sec

rts

  14. Posted

    OK, I see the problem. If you look at the definition of the i2c_startwrite command, the last line before the rts is "bcc i2c_rxbyteloop". This means that the carry flag will *always* be set at the end of this function. I think that Thomas has optimised out this bit of functionality. In fact, it looks like you should test bit 0 of the accumulator rather than the carry flag. I suspect there must have been a note about this somewhere, but I can't find it now. Anyway, hopefully this should solve the problem!

     

    Chris

     

    Ah! I'll give that a try, then. Thanks!

     

    --Will

  15. Posted · Edited by e1will

    Correct, the first jsr i2c_startwrite is failing (setting the carry flag.) The binary is posted above (post #18), the first jsr i2c_startwrite is at $B9C3. Either stepping through it in the debugger or letting it run at normal speed seems to produce the same results.

    --Will

     

    I'm having a bit of trouble finding the AtariVox calls in your code. Can you let me know when they are called in the game, and which bank/address they are at. Ideally, if you could separate the AVox stuff from your main code and post the source, or post a symbol file for the Stella debugger?

     

    Chris

     

    Sure, symbol file attached.

     

    --Will

     

    EDIT: The jsr i2c_startwrite call is the only call in the game that pushes the stack pointer down to F3, so if you have trouble locating that call you can just add a breakif {sp==F3} and it will catch there. Starting a game, move the robot to the right door and into the light blue room, then pressing the fire button is what triggers the AtariVox call.

    DUCKNTSC.zip

  16. Posted

    If it still doesn't work, then it might be a problem in the programming of the AVox itself. Unfortunately, I can't help in that area.

     

    If I understand correctly, the problem is the very first "jsr i2c_startwrite" command, before any AtariVox or SaveKey programming is performed. I suggest that e1will posts the binary containing the problem so that we can debug it and see why this is happening.

     

    Chris

     

    Correct, the first jsr i2c_startwrite is failing (setting the carry flag.) The binary is posted above (post #18), the first jsr i2c_startwrite is at $B9C3. Either stepping through it in the debugger or letting it run at normal speed seems to produce the same results.

     

    --Will

  17. Posted · Edited by e1will

    Just thought I'd take care of the obvious first; you are restarting Stella, correct? It's not enough to select the AVox as the right controller in the UI. You then have to restart Stella with the same ROM to pick up the change (as indicated by the text at the bottom '(*) Changes to properties require a ROM reload').

     

    Yep, definitely restarting Stella each time. What's interesting is when I recompile the ROM, Stella will "forget" that I've specified AtariVox for the P1 controller (perhaps it uses a checksum or modification date rather than simply the filepath of the ROM?) and reverts it to Joystick, but regardless I do change the controller setting outside of the game (and then confirm it's still set correctly by looking at the config after starting the game.)

     

    --Will

     

    EDIT: Tried it with the commandline argument, still can't access the EEPROM: Stella.exe -fullscreen -1 -rc atarivox DUCKNTSC.BIN

  18. Posted

    There is an option to use a real AtariVox in Stella (Input Settings -> Virtual Devs -> AVox Serial port), but I don't think this will interfere with the SaveKey stuff. Have you tried setting the right port to "SaveKey" instead? Do other games (e.g. Juno First) do their SaveKey saving and loading fine with this version of Stella? Could the stack pointer be overwriting something (e.g. the SaveKey temp variable) when you do the jsr? If it still doesn't work, you could post some more of your code here.

     

    Chris

     

    Setting the P1 controller to SaveKey gives the same results. Juno First is working fine saving and retrieving its high scores, so Stella is able to read and write to the .dat file. The stack pointer is at $F7 when the SaveAndLoad_Main function (which contains the example code) is called, and drops to $F5 when the jsr i2c_startwrite is called; the temp variable is at $DD, so there shouldn't be a conflict there.

     

    Here's how I'm calling it: the main game loop calls a joystick input function (PlayerMove, at $F374 in bank 7), which checks if the fire button is being pressed in the egg shelf room. If it is, it JSRs to the SaveGame function, which JSRs to the SaveAndLoad_Main function ($B9C3 in bank 3) which contains the example code. The first thing that function does is call jsr i2c_startwrite, which on return has the carry flag set. (And viewing the contents of the .dat file confirm nothing has been changed from all $FF's.)

     

    When SaveAndLoad_Main returns, it puts the player in either the score room (if the carry flag is clear, meaning success) or the credits room (if the carry flag is set, meaning failure), and so far it has always done the latter.

     

    --Will

    DUCKNTSC.BIN

  19. Posted

    I just wanted to add that if you'll be using an AtariVox with Stella, you must use this latest optimized i2c code. Thomas released this new code in part because we found a bug when adding AVox support to Stella.

     

    Well, I'm brand new to programming for the AtariVox, and I must be making a rookie mistake, although I don't know what it is.

     

    I'm including Thomas's i2c_v2_2.inc, I'm using the example code from AtariVox.rtf EXACTLY as it's written, and I've got my ROM configured in Stella to look for the AtariVox in the right port (screenshot attached). But when the example code runs, the first jsr i2c_startwrite always returns with the carry flag set, which from the documentation means it was unable to communicate with the port.

     

    buffer = $80

jsr	i2c_startwrite	; Start signal and $a0 command byte
bcs	eeprom_error	; exit if command byte not acknowledged

lda	#$01			; upper byte of address
jsr	i2c_txbyte
lda	#$40			; lower byte of address
jsr	i2c_txbyte

ldx	#$00
write_loop
lda	buffer,x		; get byte from RAM
jsr	i2c_txbyte		; transmit to EEPROM
inx
cpx	#$08			; 8 bytes sent?
bne	write_loop

eeprom_error
jsr	i2c_stopwrite	; terminate write and commit to memory


rts

     

    Is there some initialization that I'm missing? Or a Stella configuration option I've missed?

     

    --Will

    post-23222-125996986377_thumb.png

  20. Posted · Edited by e1will

    Maybe the new locations have something to do with it??

     

    Of course, the specific ROM must actually use the AVox device (ie, it must have the controller type set to AtariVox, either in its properties or manually from the commandline). Otherwise, a EEPROM dat file will never be created.

     

    I've tried specifying different locations for EEPROM path, including these:

    ~\Application Data\Stella\

    C:\Stella\

     

    ...and I get the same results each time. I know it's not a Windows permissions issue, since Stella has no problem with the "Save ROM" feature in the debugger with ROMs in the same directory as what's specified in the EEPROM path.

     

    This behavior is consistent with other games I've tried that have AtariVox functionality (e.g. Juno First says "SAVEKEY CARD NOT FOUND!" when I start it in the emulator.)

     

    Anything else I might try? Am I correct in understanding that Stella should create C:\Stella\atarivox_eeprom.dat if stella.ini shows "eepromdir = C:\Stella\" and I start a game like Juno First?

     

    --Will

     

    EDIT: Nevermind! The problem was the P1 controller type. Apparently it had reverted to Joystick somehow. Changing it back to AtariVox fixed the problem. Thanks for the reminder to check that setting.

  21. Posted

    Is Stella 3.0 handling the AtariVox EEPROM emulation differently than 2.8.x did?

     

    I can't seem to get 3.0 to either read the existing atarivox_eeprom.dat file or create a new one, and running games that worked fine under 2.8.4 (e.g. Man Goes Down) no longer save or load under 3.0.

     

    --Will

  22. Posted · Edited by e1will

    Great game. I will give it some more play tomorrow.

     

    A minor comment:

    IMO, at the credits screen, "Duck" and "Attack!" should have the same with (like at the title screen). Looks better that way. Also the vertical space between the two words is much bigger at the title screen. It should look identical on both screens.

     

    Good suggestion. I've changed the credits logo to match the title screen's.

     

    v0.09 is attached - the major change to this version is a new "Continue" feature. If you reach level 6 or higher before running out of lives, you can continue the next game at the same level (with score reset to zero) by pressing the fire button before the timer runs out.

     

    To compensate I've cut down the number of levels you can select from the title screen to 5 (from 9). To get to level 9 now you'll need to beat levels 5, 6, 7 and 8 first.

     

    I've got a really neat feature planned for version v0.10, so stay tuned!

     

    --Will

    post-23222-12598810977_thumb.png

    post-23222-125988111018_thumb.png

  23. Posted

    I just wanted to add that if you'll be using an AtariVox with Stella, you must use this latest optimized i2c code. Thomas released this new code in part because we found a bug when adding AVox support to Stella.

     

    Thanks for the heads-up. Out of curiosity, what was the nature of the bug?

     

    --Will

  24. Posted

    Thomas also posted an optimised version of the AtariVox i2c code.

    I'm hoping you will be adding AtariVox speech to Duck Attack?

     

    Chris

     

    Thanks for the updated .inc link!

     

    I would love to have some sounds in there (a nice robotic "duck in vicinity!" would be great) but I'm not sure if I have the byte-squeezing skills to pull it off. I'm going to play around and see if I can manage it, although I'm not optimistic since things are pretty darn tight as it is. (And I don't actually have an AtariVox, so testing would be tough.)

     

    I did decide to add a "save game" feature, though, so that if you're wandering around on Level 14 and want to play something else for a while, you can save the game to the EEPROM and resume it later. That (and high score retention) will be in v0.09. Since Stella emulates that, testing should be straightforward (I hope).

     

    --Will

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...