-
Posts
7,732 -
Joined
-
Last visited
-
Days Won
12
RevEng's Achievements
Quadrunner (9/9)
9.3k
Reputation
-
I wouldn't use the demo and extrapolate. I was quick to just allocate a bunch of ram while I was banging the code out. The best way to do it is to figure out how many display objects per zone your game needs, and then take a wild guess at the amount of ram you need, and allocate it with dlmemory compile the game and look for the line like "XXXX to YYYY used as zone memory, allowing ZZ display objects per zone." if ZZ is bigger than the number of objects you need, adjust dlmemory for less memory and repeat from step 2 if ZZ is smaller than the number of objects you need, adjust dlmemory for more memory and repeat from step 2 if you're here, you have allocated the perfect amount of memory for your game. I know a process is less efficient than giving you some rule of thumb, but it would have to be several rules of thumb, with "set dlmemory" and double-buffering, with another for "set extradlmemory". I like it! I may adapt it back to the pdf guide at some point, but for now my lack of cycles and your ability to iterate would be better served if I held off.
-
Productivity Comes to the 7800 (note the date of the post)
-
There no reason to be nervous about changing pfheight during runtime. There's nothing that uses it outside of the kernel, and the kernel itself has no memory or dependency of what the value was during the previous frame.
-
The beautiful self destruction of Sweet Baby Inc
RevEng replied to JPF997's topic in Modern Gaming Discussion
My 2 cents is that AtariAge should ban culture war discussions, because the topic fits right in with the existing religion and politics ban. All of these topics quickly devolve into worst-motive assumptions and name calling, with civil discourse being impossible. It would be much better for the community to just leave this shit on Reddit, X, and Youtube.- 24 replies
-
- 14
-
You don't need to worry about that check, since you're looking to run in 2600 mode. The region byte is checked to see if running in 7800 mode should be rejected.
-
Ahhhh, thanks for that explanation. Makes sense. I originally figured it was a dasm parser issue, rather than something intentional.
-
The 7800basic compile process checks if the produced rom from the underlying dasm assembly looks to be the right size. The messages you're quoting are from dasm, but if the produced rom looks right (it happens, but it's rare) then 7800basic isn't aware of the problem. That produced rom is definitely broken in some way. There isn't a general problem with using "$09" in 7800basic source code. Your dasm error indicates that you've used "09" somewhere instead of "$09". If I use "09" in source I can replicate your error. It looks like dasm doesn't accept zeroes in front of decimal values.
-
It's basically a "cart isn't inserted" check. Due to bus capacitance causing a bit of hang-time on the last driven data bus value (when there's nothing driving the bus anymore) a naive check for no cart rom (e.g. look for all FF, look for all 0, check the same location many times, etc) often fails to actually catch a no cart rom condition. That last-driven value is usually the last byte of the opcode's operand. By using a different base address but reaching the same final address with different indexes, gcc forced the last-driven value to be different. I'm not aware of any 2600 bank schemes that respond to FE00-FE7F. Are there any? If there are, it's a bit hard to say. Essentially the question of whether this scheme would pass this check or not can be reduced to "is the value returned from reading the same hotspot location twice consistent?" That's probably going to depend on the bankswitch hardware, rom, and console.
-
I know the PAL bios comments say that, but it's not quite what it's doing. It's comparing FE00-FE7F to itself using two different base addresses, and indexes set to compensate. If the compared values don't match, then it jumps to the internal game.
-
It's a niche application, but I always though it would also be useful to allow characters on a "lower level" to go underneath an overpass... But for sure, HUDs are the main application.
-
Have a look at lockzone and unlockzone. You should be able to lock the zones involved in the hud, and the sprites will appear to disappear as they move into the locked hud zone.Then you can unlock the hud if you need to plot hud elements on top of it. Locking and unlocking is a relatively cheap activity.
-
Is there a way to run a 2600 game in 7800 mode?
RevEng replied to PacManPlus's topic in Atari 7800 Programming
The PAL and Parsec bios use heuristics to detect whether a cart is 2600 or 7800. Rather than looking for encryption, one of the checks is to look for telltale 2600 rom mirrors. If they're present, the console gets locked into 2600 mode. No idea why the game isn't running in 2600 mode, tho. Maybe it's still feeding 7800 code. -
They've already done the 2600, but we have a secret weapon on the 7800 front. Neither man nor machine can endure 7800 Karateka.
-
If you want to send it for the 2600+ code, we can try it out with later stage testing. We'll initially check against some of the purpose-built paddle test utilities... Paddle Test (DLI Sampling) (20050510) (C19CE22C).a78 Rotational Controls Demo (20200829) (59A5457E).a78 ...it's easier to compare behaviour vs real hardware with those, since they provide numerical output.