splendidnut
-
Content Count
500 -
Joined
-
Last visited
Posts posted by splendidnut
-
-
45 minutes ago, dlmartins said:My main questions for the Atari development community:
- Is there a danger for enhanced games, by their nature, to not be preserved or playable?
- Is the lack of support in MiSTER and possibly other hardware based approaches for these enhanced games a concern?
- Is the use of enhanced games lazy and a lazy approach (compared to a Mapper)?
- What are the primary reasons for using ARM based enhancements?(1) ALL games are always in danger of not being preserved if no one makes the effort to do so. Playability depends on preservation, which depends on people being willing to preserve them.
(2) As long as there are emulators available that support emulating the hardware, there's really no need to be concerned. Those working on MiSTER have no obligation to support the hardware unless their goal is to be able to run those enhanced games.
(3) Maybe. I would actually argue that one of the goals of programming is to be lazy and not work harder than you need to. In general, any kind of programming is always work regardless of the platform.
(4) In Atari 2600 games, ARM based enhancements allow developers to get more out of the system... mainly, get more out of the TIA (audio/video) chip.
-
3
-
-
Oh man, things are going to get crazy now! Here come the buses to run over the people...
-
2
-
-
-
Hmmm, crap... Just checked, off by 5 pixels. Don't know why I didn't check to make sure it was centered.
Fixed:
Score_Code: sta WSYNC lda #0 sta COLUBK inx cpx #100 bne Score_Code sta WSYNC ldx #1 ; 2 2 stx VDELP0 ; 3 5 turn off vertical delay stx VDELP1 ; 3 8 turn off vertical delay ldx #0 ; 2 10 stx GRP0 ; 3 13 make sure player0 is off stx GRP1 ; 3 16 make sure player1 is off stx ENABL ; 3 19 make sure ball is off stx ENAM0 ; 3 22 make sure Missile1 is off stx ENAM1 ; 3 25 make sure Missile0 is off stx REFP0 ; 3 28 make sure reflect is off stx REFP1 ; 3 31 make sure reflect is off ldx #$E0 ; 2 33 ; +2 for HMP0 stx HMP0 ; 3 36 ; fine positioning for player1 stx RESP0 ; 3 39 ; player0 at X=56 = ((39 * 3) - 68)+5 +2 stx RESP1 ; 3 42 ; player1 at X=64 = ((42 * 3) - 68)+5 +1 ldx #$F0 ; 2 44 ; +1 for HMP1 stx HMP1 ; 3 47 ; fine positioning for player1 ldx #3 ; 2 49 stx NUSIZ0 ; 3 52 ; player0 - 2 copies, close stx NUSIZ1 ; 3 55 ; player1 - 2 copies, close lda ScoreColor ; 3 58 sta COLUP0 ; 3 61 sta COLUP1 ; 3 64 sta WSYNC sta HMOVE ; sets player0 X=56, player1 X=64 -
The code in the link @Karl G provided uses "absolute,y" memory accesses; whereas, you switched them to (indirect),y accesses which take one more cycle each. You need to move the score display kernel code around a bit to compensate for this AND you'll need to adjust your positioning also.
Fixed code:
Score_Code: sta WSYNC lda #0 sta COLUBK inx cpx #100 bne Score_Code sta WSYNC ldx #1 ; 2 2 stx VDELP0 ; 3 5 turn off vertical delay stx VDELP1 ; 3 8 turn off vertical delay ldx #0 ; 2 10 stx GRP0 ; 3 13 make sure player0 is off stx GRP1 ; 3 16 make sure player1 is off stx ENABL ; 3 19 make sure ball is off stx ENAM0 ; 3 22 make sure Missile1 is off stx ENAM1 ; 3 25 make sure Missile0 is off stx REFP0 ; 3 28 make sure reflect is off stx REFP1 ; 3 31 make sure reflect is off ldx #0 ; 2 33 ; +0 for HMP1 stx HMP1 ; 3 36 ; fine positioning for player1 ldx #$FF ; 2 38 ; +1 for HMP0 stx RESP0 ; 3 41 ; player0 at X=60 = ((41 * 3) - 68)+5 stx RESP1 ; 3 44 ; player1 at X=69 = ((44 * 3) - 68)+5 stx HMP0 ; 3 47 ; fine positioning for player1 ldx #3 ; 2 49 ; X now 1 stx NUSIZ0 ; 3 52 ; player0 - 2 copies, close stx NUSIZ1 ; 3 55 ; player1 - 2 copies, close lda ScoreColor ; 3 58 sta COLUP0 ; 3 61 sta COLUP1 ; 3 64 sta WSYNC sta HMOVE ; sets player0 X=62, player1 X=72 ;--------------------------------- ;--- now draw score ldy #7 sty ImageHeight ; 80 - 8 - 8 - 64 ScoreLoop lda (DigitLivesTens),y ; 5 (70) sta WSYNC sta GRP0 ; 3 (3) hello0->[GRP0] lda (DigitLivesOnes),y ; 5 (8) sta GRP1 ; 3 (11) hello1->[GRP1], hello0->GRP0 lda (DigitThousands),y ; 5 (16) sta GRP0 ; 3 (19) hello2->[GRP0], hello1->GRP1 lda (DigitHundreds),y ; 5 (24) tax ; 2 (26) hello3->X lda (DigitTens),y ; 5 (31) sta Temp2 ; 3 (34) lda (DigitOnes),y ; 5 (39) hello5->A ldy Temp2 ; 3 (42) stx GRP1 ; 3 (45) hello3->[GRP1], hello2->GRP0 sty GRP0 ; 3 (48) hello4->[GRP0], hello3->GRP1 sta GRP1 ; 3 (51) hello5->[GRP1], hello4->GRP0 sta GRP0 ; 3 (54) hello5->GRP1 dec ImageHeight ; 5 (59) ldy ImageHeight ; 3 (62) bpl ScoreLoop ; 2/3 (65) sta WSYNC ; extra blank line to keep it 262 scanlines lda #0 sta NUSIZ0 sta NUSIZ1 sta COLUBK rts -
There's been a couple of versions of that done already:
(ignore the link snapshots... clearly we live in the future where the forums are sentient and spend all their time perusing memes)
-
1
-
-
Satan's Hollow
-
2
-
-
Not a dumb question at all. I don't think I've ever thought of utilizing an editor's code-folding feature for assembly code.
Recently, I've gotten into the habit of using macros (MAC name ... ENDM) to encapsulate chunks of code. It's an easy way to make relocatable code.
-
I'm constantly moving DASM-based projects between Windows and Macs... and so far I haven't hit any issues with line ending characters tripping up assembly.
-
Somewhere there's a prototype of Marble Madness using a technique similar to this.
Oh, that was easy to find:
-
1
-
-
I'm currently in the processing of getting things working again after playing around with different bank-switching schemes. E7 -> 3EP -> DPC+
I went down the path of creating a sprite blitter to draw the sprites into RAM buffers for display. BUT, I was having trouble finding a bank-switching scheme to easily support doing that. I found that the RAM layout in the E7 bank-switching scheme was too limited for what I wanted to do. I played around with 3EP to the point where I had everything switched over and working, but discovered that the standard Harmony doesn't have any support for it. So I after some consideration, I started switching things over to DPC+.
That was a while back... I walked away for a bit, leaving it in a bad state. Just this past weekend, I got things kinda working in again. Currently, the level display is working, but the player isn't; he's upside down (easy fix)... and he can't seem to find the ground anymore. (which are all things caused by switching between banking schemes)
At this point, I'll probably throw out the sprite blitter, since it will no longer needed with DPC+. I can just store the sprites in the Display Data RAM/ROM area and use the Data Fetchers. Also, adding back in the "alternating color" magic should be relatively easy now. We shall see...
That's the gist of where this is at. Currently... a slow simmer.
-
3
-
-
Taking a deeper look at the link I posted, it appears the modules are separated out (i.e. the TIA stuff is in a separate folder). Granted, I may be wrong, but I would think that it would still be useful and, if anything, better than starting from scratch.
-
1
-
-
The CollectorVision Phoenix has an Atari 2600 FPGA implementation available on their github account:
-
This is my favorite 7800 emulator. Works great, seems very accurate and it's very easy to use. Wish there was a MacOS version and/or open-source, but that neither of those are deal breakers.
Thanks for putting this out there!
-
Alright. Well I've got Bongo and the monkeys moving around a bit and some coconuts dropping. Granted, the coconuts look a bit like rocks but they're dropping/bouncing and it's fun to watch.
Enjoy.
-
8
-
1
-
-
Well then that confirms that there is an issue with your PlusCart.
-
To me, that looks like RF interference in the same frequency range as the dot/color clock (system clock). That would suggest not enough power is being provided or the power rails are noisy. Which that could be any of the following: a power supply/connection issue, a bad capacitor, a bad/dirty cartridge connection (cart or connector) OR a bad solder joint somewhere.
Have either of these two systems had cap kits installed?
I ask because I've run into issues similar to this with the Harmony Cart... All original games worked fine except for the Harmony cart. The issue on one of my systems was quite extreme: there were major sync/video loss issues. I ended up getting cap kits (which come with a new power connector and regulator) from console5.com for both systems, and now they work great.
This is old tech, might be time for some refurbishing.
-
And now there's a cat and some better flicker management!
Enjoy!
NTSC:
PaintTheCity-WIP-NTSC-20210330.bin
PAL60:
-
6
-
-
The Atari has two sound channels, so you can play two sounds at once. On an un-modded system, these two channels are mixed together and output in mono.
The TIA chip outputs the two sound channels separately, so some people have modded their systems to have stereo sound with one channel outputting on the left, and the other on the right.
-
1
-
1
-
-
I'm not sure. They seem to have gone out of their way to try and differentiate themselves via a repeated mantra. But I've yet to see how they really differentiate from what AtariAge is doing. Although they probably don't seek out nor accept submissions of games developed outside the "company". It's all developed "in-house" so-to-speak.
-
3
-
1
-
-
From what I've seen in this thread, I don't think they're shipping things in any kind of order.
ADDENDUM: "any kind of specific order"... they might be doing random batches.
At the end of the day, it's potentially just David and Garry (2 people) trying to ship ~1000 boxed items. They're a very small company, so it's going to take awhile.
-
4
-
-
Added first attempt at PAL colors to previous post.
ADDENDUM:
Added latest binaries to first post.
-
2
-
-
Oh, wow, it's been way too long.
I've actually been occasionally poking at the enemy logic for Paint The City, and I think I've finally gotten it in a half-decent state. It is buggy, and chaotic, but it kinda works, and the game is now kind of playable. Enemies follow the level, they spawn at different speeds, you can crash into them. Sometimes they behave properly, sometimes they don't. And... Bullets collisions are still not implemented.
BUT, really I just want to show off my title screen. It ended up looking better than I expected.
Oh, and here's a ROM to try out.
Enjoy!
NTSC:
PaintTheCity-WIP-NTSC-20210328.bin
PAL60:
PaintTheCity-WIP-PAL60-20210328.bin
-
11
-
-
If you are patient, it will come. Otherwise it will seem like it's never going to arrive.
I just got my shipping notice today, and I ordered relatively early.
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
ARM based/enhanced Atari development, MISTer FPGA, and preservation
in Atari 2600
Posted
For reference, @Kitrinx was way more nice/civil in this discussion: