Karl G

It says that a password is required to access the page, and I don't have one. This happens regardless of whether or not I'm logged onto my itch.io account.

I think you will probably get more feedback when you get far enough to post a demo version. Right now there is just a couple of seconds of video footage, so it's hard to get a sense of how the game will play. I hope you are having fun with Atari development, and I look forward to seeing what you come up with. 🙂

Thanks for posting these! The Game Boy link seems to be broken, though. I found a Game Boy port, but by a different developer than the one you listed: https://oscarbraindead.itch.io/paku-paku-gb-gameboy

Here's what I got via email:

I really love the mechanics of this one.

Mine, and I think most of them, came with a NEC v20, which is 8088 compatible, and runs at the same clock speed, but is somewhat faster due to some optimizations. You can see it on benchmarks that compare to a standard PC/XT. For that reason, I swapped it out for a genuine 8088 so that software that assumed PC/XT speeds would run at the correct speed. I did get an 8088-2 so I could still use the turbo feature if I needed it, though.

I managed to compile a7800 for my Raspberry Pi 400, and it works, but the pokey audio output sounds bad. I suspect this is a speed issue, though. Mame is pretty beefy, and maybe my poor Pi can't keep up. So, my questions are: Is anyone else running a7800 on a Pi? If so, any tips for performance or audio? Is there a way to disable pokey sound support when running something via a7800?

An update was emailed out yesterday.

I know what is causing this, and how to fix it. The section of the manual on pfheights says there's a known issue if the first row in pfheights isn't set to 8. When I set it to 8 myself, I got a stable picture when I set it to 8 in your code. However, the other issue is that the numbers already added up to 92 instead of 88, and up to 92 after making that change. It still works like this, but it expands the size of your visible screen, so takes processing time away from your game. This is less of an issue if you don't use the score or a minikernel, however. Anyway, I suggest that you set the first pfheights entry to 8, then subtract 1 from 8 of the other lines to make the total equal 88.

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.