Dr. Kylstein

Well, I'm stumped. I'll have to bug a professor about that. Edit: oh, it's (probably) because there is no "correct" answer for integer division in those cases. Darned mathematicians... Sorry for wasting your time.

For unsigned 32-bit numbers, I believe the answer is to multiply by 0xCCCCCCCD. (It looks pretty similar to your fixed-point constant...) Modulo arithmetic is the mathematician's way of simulating a fixed number of bits in an integer representation, so in this case I solved for for x*5 = 1 mod 2^32 (uisng Wolfram Alpha). For 8-bit ints it would be mod 2^8, and I think you're probably familar with how large numbers behave in that case. It's a neat bit of mathemagic, if you care to use it.

Are you using those fractional bits at all? If not, I think you could use a modular inverse for that divide by 5. It would only save one operation though.

So if I still knew how to cycle count, it wouldn't be a problem? It's been too long since I've done this stuff.

I want to have multiple rows of enemies that the player must dodge, like the cars from Frogger, except that my player has per-pixel movement. From the look of the horizontal positioning code I've borrowed, it looks like I need (nearly?) a whole line to re-position the second sprite. Is there a trick I'm missing, or do I need to go to two-line? I'm using DPC+.

Thanks for the correction! That statement started to smell wrong as soon as I posted it.

Works for me on a modded 4-switch over composite to a 10-year old 20" Magnavox CRT. I expect digital TVs to be where problems occur, but I don't have one handy.

Ok, here it is with the right bankswitch program file. I should warn you that I haven't managed to get any non-trivial programs working with this. I think there may be a problem accessing the data fetch registers. dpcplus_ca65.zip

Ok, nevermind. I figured out that I had connected sync to pin 3 instead of pin 2. It works great now!

I bought one the assembled video mod boards from LittleJoe and installed it last night. Photos of the Combat atrract screen are in the spoiler. As the colors cycle, the picture comes and goes and switches between the states pictured. The best output is when using the in-game colors: I can see the scores, background, and left tank clearly in correct colors but the picture is shifted down vertically several lines and the rows all oscillate towards the right, shearing the picture. My impression is that the variation is due some of the colors going out of range, and the shearing means something's wrong with the sync, but I can't see any obvious problems with the wiring.

There were some mistakes in the converted macro.inc file. Here's one more update. dpcplus_ca65.zip

Ok, here's one that builds in one step and includes a batch file. I knew about incbin but hadn't thought of using it this way. dpcplus_ca65.zip

I have put together a basic example for building a DPC+ rom with the cc65 tools. It's a mash-up of GroovyBee's demo above and Spiceware's DPC+ demo. It includes conversions of all the headers. The resulting rom draws color bars on the screen (as in GroovyBee's demo) by doing round-robin accross the code banks. I'm quite new to Atari programming, but hopefully this will be useful to someone. Edit: The Makefile is for GNU Make, it uses the Unix command 'cat' to combine the arm and 6502 pieces. Edit2: I think I should mention that this is not a superset of any of the existing examples, it lacks some features. dpcplus_ca65.zip

Wow, it almost feels complete already! I'm excited to see where this goes.

The robots in the demo charge at walls too readily. In Berzerk, they do know how to avoid walls, they just misjudge corners and edges sometimes. Most frags are due to bumping into or shooting each other.