Karl G

JFYI to anyone else who may be interested in discussions of DOS, DOS games, vintage PC hardware, etc. I have made a club for those kinds of topics. https://forums.atariage.com/forum/434-dos-discussion/

JFYI I have made a club for this: https://forums.atariage.com/forum/434-dos-discussion/

This looks amazing! The gameplay is smooth, and the graphics look great! My one suggestion so far would be to have more of an indication of when you are hit. Maybe your ship can flash slightly when you take damage, or perhaps just the shield indicator?

I have two systems that run DOS right now: one is a vintage HP 200LX palmtop, which is a genuine pocket-sized XT-compatible system with CGA running on a grayscale LCD screen. I love this device, but the screen presents challenges for old eyes, especially since it is not backlit. The other is a Book 8088, which is a new system meant to be a recreation of the original IBM PC with CGA graphics in notebook form. I swapped out the slightly faster NEC V20 with a genuine 8088 on mine.

This is an evolving list; I will add to it as I go. Feel free to suggest any I have missed! DOS and Other DOS Communities FreeDOS: An open-source re-implementation of DOS; mostly complete. DOS ain't dead: DOS-related forums. VOGONS: DOS, hardware, and emulation discussion. Dosgames Forum: DOS games discussion and more. DOS Emulation DOSBox: A DOS emulator with a focus on running DOS games. DOSBox-X: A fork of DOSBox with more of a focus on accuracy and completeness. Development DJGPP: DOS 32-bit development toolchain (runs on 368 or later, and produces code for 386 or later) Open Watcom: An open-source version of the classic Watcom compiler; reasonably modern and up to date. Runs on 386 or later, but can produce either 16 or 32-bit code. Vintage Borland C/C++: Various versions of the original DOS Borland C/C++ compilers. Vintage Turbo C/C++: Various versions of the original DOS Turbo C/C++ compilers. Vintage Microsoft C/C++: Various versions of the Microsoft C/C++ compilers. NASM Assembler: Free and open-source assembler for many platforms, including DOS.

The short answer is that it should work up to 64K, but the 128K and 256K versions will not, at least not currently. The longer answer is that there's no technical reason that these sizes could be supported, but support for these bankswitching formats has not been added yet. The bankswitching formats that would need to be added to the 2600+ are: DF (128K) DFSC (128K + SuperChip RAM) BF (256K) BFSC (256K + SuperChip RAM) My game Penult uses DFSC, so that will probably eventually be supported (since it's a released homebrew cart), but I have been asking about it for months with no sign of movement on it so far. Edit: I should probably tag @RevEng to verify the accuracy of my answer since this is his framework.

Pretty cool! It definitely looks like it could be mass chaos! I was wondering how score could be displayed. Perhaps each player could have an associated color, and the score displayed is the player that most recently scored a point with the score in their associated color (so maybe each Pac-Man should be the appropriate color as well).

I'm not sure what's wrong, either, since my copy of bB crashes trying to compile this. One question, though: What is your customized std_kernel.asm? If you didn't intend this, then delete the copy in that directory, and let bB use its standard one. What version of bB are you using? I don't see a version string in your compiler output, which makes me wonder if you are using an older version.

I'm quite curious what you mean by "multi-threading support" in the context of a single 8-bit processor. 🙂

A most impressive feat! You pack a lot into that 4K, and the lack of flicker (so far at least) is a nice bonus. I'm wondering how committed you are to keeping it as close to the arcade version as possible? I have an idea that I think would work well with the kernel you are using, but isn't strictly true to the original. Specifically, I noticed the groups of two turtles have one sprite turtle followed by 3 lines presumably to represent the second turtle. I was wondering if you could instead use the lines to represent a partially submerged turtle instead? That way, you could have the group of two taking turns which one is submerged, and that way the lines would make more sense, and you still wouldn't need more than one sprite in the pair of turtles at a time.

A second this suggestion! I would love to see such a forum on AtariAge. Perhaps it would be called "Vintage PC"?

The latest information I have is that the Penult cart is at least not yet supported on the 2600+, but I have asked to see if there is any updated information on that.

Hi @Albert and @Ben from Plaion - I have another person asking me if the Penult cartridge will work with the 2600+. Did this cart get sent over, and has DFSC bankswitching support been added? Also relevant is whether or not AtatiVox/SaveKey support is working or likely to work in the future, as the game all but requires it. Thanks in advance for any updated info!

Is there a TL;DR description of what changes to the original game are in this hack?

I think what you are trying to make already exists, unless I am misunderstanding something. I don't think any 2600 games have been made to take advantage of it, though: https://stoneagegamer.com/mega7800-controller-adapter-for-atari-7800-retrohq.html

In this case, you were loading from memory address 10 instead of the literal number 10. The fact that it loaded 16 from that address is coincidence rather than a decimal vs hex issue. DASM doesn't really distinguish between constants and variables; both are labels that are assigned a value. The only thing that distiguishes how it is treated is the "#" for a literal number, or its absence for a memory address. Forgetting to put "#" before numbers or constants when loading them is a common pitfall.

JFYI, the "#" is to distinguish loading a literal number value from loading from a memory address. The number supplied after the "#" defaults to decimal. If you want to load a hex number, you would use a "$" after the "#", e.g.: lda #$57

This is the one that I use. I don't know how it compares to any others, but it's cheap and gets the job done: https://www.amazon.com/gp/product/B07L931SB5/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

Ping-pong Wars?

I'm just happy that nobody has beaten my high score yet!

This isn't one I played BITD, but the look and feel is fantastic! Great sprites, animations, sound and explosion effects! I'm afraid that you are going to have to finish this one. Sorry... I don't make the rules.

I'm wondering if the deep discounts are because the product isn't doing well? It's surprising to see it discounted that much so soon after launch.

In that case, you may need another data table to store CTRLPF and/or ballheight values for each pose as well. A little more complicated, but still quite doable.

Assuming that you are talking about bB without a custom kernel, you might not need to vary the width of the ball at all. If the ball object is drawn under the sprite, then the varying lengths could be handled by positioning alone, having some of it obscured under the player sprite to have different lengths extending from your player sprite (which also gives finer-grained control of the length). If you do it this way, you could have two data tables, e.g. ball_offset_x and ball_offset_y, containing values that are added to e.g. the player0x and player0y coordinates to get the values that should go into ballx and bally for each pose. e.g. ballx = player0x + ball_offset_x[PoseNumber]

That's how I do it for assembly projects as well, but batari Basic doesn't have conditional compilation like that. It's possible to do it with inline assembly, though.