[A7800 - the Atari 7800 Emulator]

Thanks for the kind words of encouragement. No good deed goes unpunished, I guess.

[The new Atari 2600+ w/HDMI out and 2600/7800 support]

44 minutes ago, Thomas Jentzsch said:

True, but IIRC someone "optimized" the HMOVE blanks away.  

Also, there were missing undocumented opcodes, which did impact some homebrews.

 

Despite that, i agree that it's a shame the ASIC was lost/abandoned.

[Most recent binaries for the games of mine being pulled. All in one place.]

Just throwing an idea out here... we have 2 kinds of multibutton adapters now, mega7800 and snes2atari, that are in a number of players hands already thanks to 7800GD and Petscii Robots. @batari announced his intent to create a snes2atari+ adapter, which will support proline emulation and native snes2atari. I see these adapters getting even more popular as time goes on, if only to allow couch-complaint pause, reset, new rom selection in flash cart, etc.

 

In 7800basic I put together a "multibutton" build option, and every 64 frames any default-proline controler is probed to see if either of these adapters are present. If one of them is found, its driver runs once per frame and updates SWCHA and INPT1 faux registers, with extra button bits stuffed into the INPT1 faux register. From the game code perspective, the game just checks the faux registers, which is a nice generic interface.

 

I'm not pushing for any asm game author to do all that, but I am using it to illustrate that support for multibutton controls using these adapters are likely to be a thing going forward. It's also worth highlighting that the flashback controls aren't something that are easily obtainable anymore.

[DMA Masking - an alternative to modifying CHARBASE when vertically scrolling]

6 hours ago, bsteux said:

Wrt 1 cycle DMA penalty existence, that would be surprising (but not excluded, a look at schematics would be required or an experimental check): in Maria, the high address on which the logic to continue the state machine for DMA access is based on (test on A11 or A12 bit) is not the last byte of each DL, so there is plenty of time to add the OFFSET and implement the logic to decide to jump to the next DL or continue with DMA access..

I ran the test, and it's actually worse - you lose 3 cycles of DMA for sprites with graaphics that are in the hole. (in addition to the header dma, of course)  Additional info is over in the 7800 Hardware Facts thread.

[7800 hardware facts]

It's been a while since I posted here, but I have another dma wrinkle to spell out... the 7800 Software Gude states "If holey DMA is enabled and graphics reads would reside in a DMA hole, no DMA penalty is incurred", but that doesn't appear to be true.

 

The following test creates:

• two zones, each with 2x 5-byte sprite objects with 10 bytes of graphics per sprite.
• two zones, each with 8x sprites as above, but the graphics data is in a DMA hole.

Then the test draws bars using kernel-style register hits. The X position of the color bar increases in proportion to how much DMA occurred in that zone. (fyi, the bar width is 12 Maria cycles)

 

The expected DMA for the first set sprites is 80 cycles  ((5 byte header * 2 cycles + 10 byte gfx * 3 cycles) * 2 sprites)

If we follow the guide statement, the DMA for the second set of sprites is 80 cycles ((5 byte header * 2 cycles + 0 graphics) * 8 sprites)

 

So if the guide is correct, the bar X should be the same for both portions of the screen. But they differ...

The X for the second bar is offset by 24 Maria cycles. It seems we're paying the dma penalty for the first byte of sprite graphics, at which point the hole is discovered and the object render is aborted. 

 

I think I actually inferred this a while back, as a7800 has the same assumption already coded, but I didn't have solid evidence for it until today.

 

I've updated the DMA section of the7800 Software Guide at the wiki.

 

dmaholecycles.a78

[DMA Masking - an alternative to modifying CHARBASE when vertically scrolling]

8 hours ago, bsteux said:

Hi,

"DMA masking" is I think the idea I was looking wrt vertical scrolling. At the moment, in cc7800, I'm using a black object to overlay the bottom of the screen, which is a similar idea but is not as effective as yours. I've got 2 questions to you Atari 7800 expert (I'm just starting on my side) :

1 - you're stating that on the upper part of the bottom DLL the DMA cost is 44 cycles. Why not 10 * 4  = 40 ? Is there something I misunderstand ? The idea is to overuse DMA on the bottom lines with 4 x 32 bytes. With 4 5-bytes DLs, the actual cost DMA cost would be (10 + 3 * 32) * 4 =  424 cycles, which together with the DMA startup and shutdown times + 7 CPU delay cycles should cover the 454 DMA cycles available. On the Holey DMA covered part, this should consume 40 cycles no ?

2 - What if we draw these 32 bytes outside the screen, at position 160 ? Do you know if Maria eats up DMA cycles in that case or if Maria is clever enough to disengage offscreen writing and spare DMA cycles ? (which would be nice in the general case, but not convenient in our case, since otherwise we would have to really draw something either transparent or background color ON screen).

Best regards !

 

1. It's been suggested in the past that an object's holey dma takes up 1 maria cycle, rather than none, for the calculation/abort. It's one of those things I should have verified a while back, but haven't done yet. I used the +1 cycle per holey graphic in my calculation, to err on the side of caution.

2. That should work - nice variation! Maria still "renders" objects that are outside the 0-159 range, with all the regular dma costs. It just doesn't actually update the scanline buffer with any out-of range pixels.

 

[My experiments with Atari 7800]

[Circus Convoy]

18 minutes ago, JagChris said:

 I'm going to assume you didn't win any badges yet.

[cc7800, a C compiler dedicated to the Atari 7800]

1 hour ago, KrunchyTC said:

I guess a better question is, what is the point of that limitation? what causes that? Why do pixels have to be doubled up like that? or have to share a BG color?

Maria was engineered for a particular cost target, and they already had to drop the on-board sound-chip to keep within the silicon budget. The 320 modes economically use the same underlying circuitry as the 160 modes, including the palettes and transparency. I'm pretty sure the design goal was the 160A, 160B, and 320A modes, which are all normal enough, with the other 320 modes being bonus/hack modes.

 

In other words, nothing is free. Having quirk-free-high color 320 modes would have required a much more complicated design.

[7800basic beta, the release thread]

Heads up there's a new v0.29 7800basic release at github. Changes include...

• feature: added "set 7800GDmenuoff" statement, to flag that 7800GD shouldn't use the menu.
• feature: added "set 7800header" statement, to allow adding ad-hoc 7800header commands.
• feature: plotchars now can plot more than 32 characters, when working with 160A, 320A, or 320D.
• fix: 7800header was sanitising mega7800 controllers on reload.
• fix: dasm updated. Inability to grow pass-buffer now handled gracefully.
• fix: plotmap causing compilation errors due to missing multiplication library.

I would normally wait more than a week between releases, but the plotmap bug is compile-breaking, so a quick release was warranted.

[Bernie & the Tower of Doom [WIP]]

That music is amazing, and there's so many different themes!  Fantastic job  @miker!!!

[PAL Asteroids rom]

8 hours ago, Trebor said:

A "hack" standalone PAL Asteroids ROM is definitely possible for someone with the interest, time, and skill. 

Asteroids_PAL.a78

 

[edit - the posted rom was updated to flag "pal" in the header too]

[A78 header changes]

Oh dear. Seems like off-by-one errors have now crept into my documentation.

 

Fixed now.

[Atari Dev Studio for Homebrew Development [Release]]

1 hour ago, Muddyfunster said:

@mksmith I'm getting an error after the update. 

 

"couldn't grow memory for message buffer"

 

The exact same code compiled under v.028 beta but after the extension updated and set to default, that's the error that I get.

That's a dasm error. It has a "pass buffer" which is used to suppress errors in one pass that actually go away in later passes. If the buffer isn't sufficient to store the next line of output, the buffer gets reallocated to twice the size it was previously. That reallocation is what failed.

 

First thing I'd try is a reboot. If you've been running for a while, even if you have memory, your free memory might be fragmented such that the OS can't hand out a contiguous block.

[7800basic beta, the release thread]

Thanks for the kind words, guys! As SainT said, I'm looking forward to seeing what you guys do with it.

 

I think it's a worthwhile addition to any proline based game, if even just to allow the player to pause the game from the couch.

[7800basic beta, the release thread]

I dropped a new v0.28 7800basic release at github. Changes include...

• feature: new multibutton controller paradigm, which allows simplified support for proline, snes gamepads (via snes2atari), and megadrive gamepads. (via mega7800) Controllers are autodetected and updated on-the-fly by 7800basic.
• feature: megadrive gamepad support. (via mega7800)
• feature: freed up space in 7800basic reserved area for converttobcd and math routines, if they're not used.
• feature: freed up space in 7800basic reserved area by making pokey-based sound effects optional.
• feature: added "-s" to 7800rmtfix, to produce stripped rmt files, suitable for use with incbin or compression.
• fix: throw error when rmt is included without pokey support. (reported by AtariusMaximus)
• fix: increased maximum number of dasm passes to allow complex projects to build. (reported by mksmith)
• fix: incorrect abort due to space overflow. (reported by darryl1970)
• fix: rare overflow in if...then parsing. (reported by AtariusMaximus)

A big thanks to:

•  @SainT for donating a 7800gd and mega7800 to the cause, and providing sample mega7800 code!
• @Muddyfunster and @mksmith for running the new multibutton code through it's paces!
• All of the bug reporters!

 

[Faster Caching]

You could use PHA in place of the indexed writes, and you'll save 1 cycle per write.

 

You could also save 2 cycles on your X adjustment if you're willing to use undocumented opcodes. (LDA #$FF, SBX #5)

[edit: TXA; SBX #5 would be 1 byte less]

 

[A78 header changes]

hram is "halt-banked ram". Presently it's just implemented in banksets.

[My 1st Atari 2600 game (Man Goes Down)]

The void is just an empty level, which would normally force you to fall down and die. You can survive the void by grabbing a helipack or bubble first, and if you do, eventually you run into some golden platforms that push you off the top of the screen. There's no video of it that I'm aware of, but here's a post that has screenshots of the wall/gold-bars at the end. It's been a while since I did the whole run, but IIRC there's a bunch more bars, but they flicker in and out of existence.

 

e1will also put together a hack that pins the player to the top of the screen, which you can use to see the void+wall and beyond.

 

 

[My 1st Atari 2600 game (Man Goes Down)]

4 minutes ago, Thomas Jentzsch said:

Someone could try to disassemble the ROM and then finish the game.

For sure, from a technical perspective. Without Alex's permission, it doesn't feel quite right to me, though I do see an argument that it's been abandoned and fair game.

[My 1st Atari 2600 game (Man Goes Down)]

31 minutes ago, thegoldenband said:

Do I remember correctly that Alex had a stroke at the end of 2005? Only he can say whether that life-changing event triggered his break from the hobby, but it's tempting to think so.

 

Lots of people make huge life changes after a stroke, by choice or necessity. If they have deficits afterward, maybe old pastimes inevitably remind them of what they've lost; if they don't, maybe the brush with mortality makes them change their priorities and take up bicycling or whatever instead.

 

Either way, he made a wonderful game. One wishes it had gotten the green light for formal release.

I think that's the most likely hypothesis, but it's not so much that he chose to quit - lots of people move on the from the hobby - it's the no-contact thing that's odd. He doesn't owe anybody anything, but just a simple "I've moved on, guys" statement without any follow-up would have at least put it all to bed.

 

Even better would have been "I've moved on. Here's the source - if someone wants to finish it for a co-credit, go for it", but that's just me being greedy.

[Death Merchant - Final Version]

1 hour ago, Atarius Maximus said:

Nice! Thanks!  I haven't attempted a z-modem download in nearly 30 years!

[...]

I may make some file download areas dedicated to Atari, you've given me a good start.   I could make my future game releases only available on the BBS! 

Glad to give you something to start with! It was fun getting the z-modem upload to work on my end.  I *think* it probably would have been easier to use syncterm to accomplish it, but I did the z-modem upload in the old Unix man way.

 

I posted an earlier version of that demo at AA before, but the version I uploaded is a TheWall exclusive, which I tuned and tweaked a fair bit, to be smoother and more aesthetically pleasing.

[Death Merchant - Final Version]

8 hours ago, Atarius Maximus said:

Email and messaging works, but there are no file downloads.

There's now one file that can be downloaded.

(provided you have a terminal with z-modem support)

[My 1st Atari 2600 game (Man Goes Down)]

3 minutes ago, llabnip said:

This remains my favorite unfinished game.  I've come to terms that it won't be completed - but it still shines as a great original homebrew on the system. 

I've come to terms that it won't be finished, but Alex's abrupt and complete departure from the hobby has always felt a bit unsettling to me. Short of showing up on his doorstep, everything was done to try and get a hold of him, to see if the game publishing could be moved forward. He either isn't seeing the messages, or he's decided to go no-contact with the entire community.

[My 1st Atari 2600 game (Man Goes Down)]

It's a masterpiece. I think the "giant void/giant wall" ending was probably what he wanted to fix, before calling it done. Even with that ending it's still gold.

 

Alex's domain herbs64.com, where he used to document his various projects, now appears to be a Japanese porn site.