ZackAttack

Your best bet for getting this on a cart is to program it yourself. I'm sure if you start a new topic in the bB sub forum with some screen shots and source code attached you will find all the help you need. The key here is that you need to demonstrate a reasonable level of effort on your part rather than "it didn't work, can you do it for me". That effort includes posting detailed information about what you want to accomplish, how you've tried to accomplish it and what happened when you tried.

The only difference I have observed is that the movement is one pixel less than on the normal consoles (clamped to 0).

Considering how little ram there is you may be better off using a indexed store to accomplish the same thing. ; Calculate which register to update wherever works best for you lda #HMM0 sta $80 ; Load X with the register in the kernel ldx $80 lda #$e0 sta 0,x ; Which register is written to is now dynamic If all you want to do is toggle between two registers you could use xor. I.E. COLUP0 ^ $01 = COLUP1 and COLUP1 ^ $01 = COLUP0

You will get better responses if you post basic questions to the batari basic sub forum. RT's webpage has everything you need to get started including links to the latest tools http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#gettingstarted

Try sta.w resm1. $0013 = $13 so it probably still assembles as ZP without explicitly saying otherwise with .w

Thanks, if I'm reading it correctly the jr is -7 -8 -9 -10 -11 -12 -13 -14 0 0 -1 -2 -3 -4 -5 -6 instead of -8 -9 -10 -11 -12 -13 -14 -15 0 -1 -2 -3 -4 -5 -6 -7 for both 73 and 74 hmoves Correct, ends on 73. The issue only appears on my jr. On my ntsc 7800 and in stella the position matches the doc. That rom only works on my 7800. It completely crashes on the jr. Probably the harmony firmware though, both the harmony and uno cart hate this system. If I understand this correctly the 73/74 hmove should be fine for the 12 sprite kernel because all 3 copies of P0 and P1 will remain in the middle of the screen and should never overlap with the hmove clock pulses. So based on everything covered above, the detection only needs to differentiate between those two possibilities. And using a normal hmove after wsync will be correct regardless of which system it is.

Well the FW is open source so anyone is welcome to add the additional robustness. There's certainly a chance that something like you described will be necessary, but we'll have to get further along with the updater development before we know if it's truly necessary or not. The ace file format makes it possible to bundle all sorts of new drivers and schemes with a game. That should greatly reduce the need to update FW.

Yeah, that routine takes a varying number of lines depending on object position. Either modify the routine to always consume 2 lines or use the timer again to make the number of lines for positioning all those objects constant. You could also position some of the objects in vblank if they're not used by the score.

Are you using the PositionObject subroutine on the ball after the score is drawn? That routine will take 1 or 2 scanlines depending on the position of the object, which isn't a problem during vblank if you're using the timer, but will cause problems if you're using it to position something in between display kernels.

While working on a 12 sprite kernel I noticed that my 2600jr doesn't behave as described in the HMOVE document on the minidig. Specifically the cycle 73 HMOVE seems to be off by one. Was there a test program used to generate this chart and if so does anyone know where to obtain it? If not I'd like to write one that displays the move values for 0-15 for cycle 73, 74 and 3 HMOVEs. Any ideas on how to extract the actual HMOVE values from the TIA? I. E. setting HMP0 to 0 and strobing HMOVE on cycle 73 moves P0 n pixels. Programmatically find n.

The program that erases the flash memory and writes the new firmware is not part of the firmware. It will be a separate bin file with the new firmware embedded in it. So to support future updates via SD card the current firmware only needs to be capable of running bin files with custom ARM code. That is exactly what MacRorie is testing in cases 1 and 2 above. The updater program is still in development, but it is far enough along that I have tested it exactly as you proposed. There is some risk with updating the firmware. During the update process the cart will be in a state where the flash is erased. If anything goes wrong at that time it would require programming via the ST-LINK to get the cart functional again. So the updater will need to be thoroughly tested and also beta tested by uno cart owners that are comfortable with programming via ST-LINK before being released to everyone. The biggest difference between this latest firmware version and the prior versions is that it supports the file format necessary to launch the updater program.

Does the trick involve a donor cart, epoxy, and a dvd player?

An input of 0 produces an output of 0. A is set to 0 and that 0 is ANDed with X to produce the result. So the value of X is irrelevant since anything ANDed with 0 will always be 0. I'm having trouble understanding your comment about it being the same as the other powers of 2. The powers of 2 all have a single bit site, which is not more than one, and as a result the output is 0 for those as well.

decrementing $00 will wrap around to $ff since it's an 8 bit register. You can verify this easily with visual 6502. http://www.visual6502.org/JSSim/expert.html?a=0000&d=a0008480a780ca8780 (change the 00 after a0 in the url to test other values) Don't give me too much credit. I was trying to figure out how to determine if a single bit was set and only when I went to post my original solution did I realize I solved the wrong problem. I think that actually made it easier to solve. Also, it doesn't update any status flags, so there may be a better solution if you want to branch instead of storing the value to ZP. It would be cool if we had a new 6502 riddle to solve every week.

I like the concept. Would be really cool if the 2 player mode is co-op and gives a slight advantage. My suggestions are: Ditch the horizontal positions of the cannons and instead map Left, LU, Up, UR, and Right to 5 positions facing above. Then mirror that cannon with a second cannon facing down. Single player controls both cannons by moving the top cannon. Double player moves cannons independently making the game a little easier if you team up. P0 for the enemy ships and the Cannons. P1 for enemy missile/bombs. Sync the fire timing of all three enemy rows to keep consistent spacing between the missile/bombs. Shooting the last enemy in row will sometimes drop a powerup which is picked up by shooting it before it expires. BL for cannon fire. Can be different colors depending on current activated powerup. Rapid fire cannon always. Should make kernel design much easier if bullets always have constant vertical spacing and vertical velocity. Button reserved for special powerups such as slow motion, nuke, wide bullets, etc Core is drawn via mirrored PF so only a single PF register needs to be updated. Try to make 1LK work before resorting to 2LK. HMOVE and ENABL can be set at the end of the previous line. GRP0 and COLUP0 should be simple LDA (ind),y STA ZP pairs only taking 16 cycles total. With the lack of PF where all the action is there might just be enough room to pull it off.

8 cycles

Assuming we're both seeing the same issue it's probably a small subset of systems which have more sporadic bus timings. I've run into similar problems when working on harmony encore drivers and it was only a few systems besides mine that had the problem. It should be pretty safe. Compared to the firmware that DirtyHairy provided the only thing that changed are the 3e, 3f, DPC, and ACE schemes. I don't have a 512MB cart to test with, so you should at least test those schemes on a 512MB cart to be sure. I've include a couple ace roms for you to test with since its a new scheme. ace-colorbars.bin ace-movinglines.bin FYI, ArmCustomExecutable(ACE) is a scheme I invented specifically for the UnoCart-2600 to allow developers to offload some of the processing tasks to the ARM processor in the cart. Soon I'll be releasing an example framework to reference for those who are interested in making games for the UnoCart.

I tried this on my 2600 JR and got similar results. The game would run for a few seconds before it completely crashed. After some investigating I found that speeding up the random number generator resolved the issue on my console. If you have the means to update the firmware you can try this version and see if it fixes it for you as well. Please let us know if it does or not. This version also supports 512KB 3e and 3f ROMs (has DirtyHairy's changes) and also supports the new ACE file format which enables firmware updates via SD card from this version on. AtariCart-ACEandDPC-2018-06-30.zip

No, M0 must be the same color as P0 and M1 must be the same color as P1 on each horizontal line. If the players always remained below the tree trunk you could use the missiles for that.

I recently added support for running custom arm programs to my fork of the firmware. Eventually either myself or someone else will create an firmware updater. So if anyone is planning on shipping their cart back for programming they may want to hold off until that's implemented. In theory if you order a cart with firmware that supports the ACE file format it will be able to self update via SD card whenever it gets implemented, but that's very much a beta version of the firmware at this point.

I was playing around with ray casting the other day. The algorithm I used was based on this article. The equation with sqrt is simplified so that sqrt is not actually required. For sin() I just created a lookup table with 128 elements. This is easier than using radians or degrees because a simple bitwise and with $7F will always convert an angle to the proper range. cos() can be accomplished with the same table. You just have to offset by 1/4 rotation before anding with $7F. vec2 rotate(int direction, vec2 vec) { f32 s = SineLookup[direction & 0x7f]; f32 c = SineLookup[((direction + 32) & 0x7f)]; vec2 v = { F32Add(F32Mul(c, vec.x), F32Mul(s, vec.y)), F32Add(F32Mul(F32Mul(F32(-1), s), vec.x), F32Mul(c, vec.y)) }; return v; }

Thanks to the work DirtyHairy had already done for the flash programming I was able to get this working fairly quickly. Firmware: uno-firmware-2018-06-20.zip Test ROM: ace-colorbars.bin GitHub: https://github.com/ZacharyScolaro/UnoCart-2600/tree/ace

There was a bug that could cause some vertical bar glitches to appear on some systems. It's fixed as of the 2018-6-15 build.

To toggle an execution breakpoint breakpoint <label> To break when a variable is written to trapwrite <label> To break when a variable is read from trapread <label> Of course there is much more you can do, but that's the minimum any bB developer should know. Regarding that batch file. Once it's been thoroughly verified it would be nice to push out a new bB update so everyone has proper symbols in stella.

I installed vbb and played around with this some. I believe this will do the right thing for both bb and vbb. To test this do the following: Open %bb% in file explorer. (win + r) Copy 2600bas.bat so you can revert the change if needed. Edit 2600bas.bat with notepad. Replace the file with the following and save it. @echo off if X"%bB%" == X goto nobb preprocess <"%~f1" | 2600basic.exe -i "%bB%" > bB.asm if errorlevel 1 goto bBerror if X%2 == X-O goto optimize postprocess -i "%bB%" > "%~f1.asm" goto nooptimize :optimize postprocess -i "%bB%" | optimize >"%~f1.asm" :nooptimize IF /I "%SESSIONNAME%"=="console" ( echo Detected bB dasm "%~f1.asm" -I"%bB%"/includes -f3 -l"%~f1.lst" -s"%~f1.sym" -o"%~f1.bin" | bbfilter ) ELSE ( echo Detected vbB mkdir "%~p1\bin" dasm "%~f1.asm" -I"%bB%"/includes -f3 -l"%~p1\bin\%~n1%~x1.lst" -s"%~p1\bin\%~n1%~x1.sym" -o"%~f1.bin" | bbfilter ) goto end :nobb echo bB environment variable not set. :bBerror echo Compilation failed. :end