StefanD

I tried today the HyperXF-Rom for the XF551 drive with Altirra 4.10. Wow this really works - Altirra emulates the 8040/50 in the XF551. Very impressive! But I found an issue: The HyperXF menu can't be booted (this comes up when booting without a disk). I tracked this issue down: The 8039 emulation in Altirra executes the command MOVP3 A,@A (opcode $E3) at location $B21 without respect to SEL MB0 at $B03. So page B is accessed, but page 3 would be correct. Edit: Here is the HyperXF-Rom: HYPROMA.rom

Weapon selection works now as expected. Menu is OK also, I didn't notice I can press Esc and then return to the interrupted gameplay with Esc or BACK. Moving on the map works opposite the first doom version in the thread - so I mentioned it. But of course it works. Thanks for this imperessive game.

Tested it on Altirra 2.6 and 4.1, same result. If I press "3" and then the fire button, the shotgun is displayed and works. (Pressing only "3" doesn't display the shotgun.) Edit: Same on real hardware (800 XL with 192 KB RAM extension)

Wow, this is fast and fluent. Amazing work! Some bugs: - Right from the beginning of the game I can choose and use all weapons (e.g. chainsaw and shotgun). When pressing e.g. 3 and then the fire button, the shotgun is displayed and used. - When pressing Esc to abort the game and return to the title screen, the screen is garbled and the title music isn't played. - On the map the joystick directions left/right and up/down are swapped (compared to the first Doom version in this thread).

I played until level 18 so far. For level 8 and 9 I needed lots of trys. Level 12 I could solve instantly: There are 5 colors and 5 moves, so you must erase a color in the 2nd move (and in each following move) and thus connect all pixels of one color in the first move. Thanks for another edition of this great game! 🙂

OK, I looked IN the webpage and found the hint. But I didn't understand it until I googled it - very nice easter egg ?

Wow, thanks @globe for this fantastic game - and it's so incredible fast. I like especially the different type of weapons. It's also good to see decriptions of items, objects and weapons in the intro. And the bit flinging gun is a nice idea - took me a bit to see how it works. It's a bit difficult to see if there is a way to the left/right or not. Thus for the floor discussion, I would prefer a dark shaded floor without dithering as in the XEX in Post #128. P.S.: When searching through the code to replace key "Z" (for playing in Altirra with German keyboard where "Y" and "Z" are swapped) I found some kind of "immortal mode" ...

Every cart can get control before the OS opens the editor sreen via the cart's init address located at $bffe. AtariWriter opens the editor here, then closes it (to create the display list), then inserts its own E handler in HATABS. It also uses some RAM (at least page 6) and modifies the display list. So if CONFIG uses the editor handler E, it uses AtariWriter's E handler which surely works different - so garbage may be displayed.

Thanks, I found this while testing my FSWAP tool (this swaps two drives).

1) Boot a DOS (e.g. XDOS) 2) Mount an ATR (from tnfsd.exe) to drive 7 (or any other drive), if not already mounted 3) FEJECT 7 4) DIR D7: -> this resets the Fujinet cart and unmounts all drives

I'm currently experimenting with the FNC tools and the SIO API. After using FEJECT to eject a drive, a following DIR to this drive resets the Fujinet cart and all drives are unmounted. Is this a bug in FEJECT (or the $E9 command)?

Press Fujinet Reset button, use FMOUNT (now on D1:) and then FMALL (to remount all disks). I'm getting more and more used to the CLI tools - I even don't want to boot into CONFIG on powerup, but right into my XDOS ?

Yes, of course, let's do this in our private PM conversation, so we don't bother the others in this large thread. (And since I now have Fujinet, I'm able to do tests.) But moving the command line options from the D-handler to the command line itself would require a rewrite of many XDOS functions, so I can't complete that shortly. All other things should be possible.

- In the COP example, XDOS interprets the space between Cypher and Bowl.xex as parameter delimiter. So XDOS is executing COP N:Cypher Dx:Bowl.xex, where x ist the default drive - so you'll get Error 170. AUX2=128 is from the cassette support for short IRGs. In my new XDOS 2.5x version (not published yet), I'll do AUX2=128 only, when "C:" is used. You can patch XDOS 2.43 by changing $1A33 from $6a to $ea, e.g. enter "=1A33 EA" in the XDOS command line. This will set AUX2 to 0. (There is no easy patch to deactivate the space delimiter in XDOS, sorry.) - A problem is also, that due to memory limitations (LOMEM should be $1E00), I implemented serveral command line options directly in the D-handler, e.g. the slash options /A, /Q (Yes/No-Queries) and in the COP command multifile copy with wildcards and filename transfer from source to destination. So e.g. COP N:Bowl.xex D2: doesn't work - instead you have to type the destination filename always, when using other devices than D:. And something like COP N:*.COM will copy only the first found file. (An advantage of the command line options in the D-handler is, that you can use them outside the commandline. E.g. type in BASIC LOAD"D:*.BAS/Q" and XDOS will prompt you for all *.BAS files, so you can select one without knowing the exact name of it.) Perhaps I should move the command line options from the D-handler to the command line for correct use of other devices with filenames like Fujinet's N: or Altirra's H:, but this will increase the length of XDOS - I suppose XDOS will get 500 bytes longer and LOMEM thus goes up from $1E00 to $2000. I need to think about this ... - By the way, I can't boot XDOS 2.43 from ATARI-APPS. Reason is, that Fujinet sets the 3rd byte of the Status command to $FE, which is used by XDOS to detect an XF551 drive and thus XDOS uses the XF high speed protocol, which seems not to be supported by Fujinet. If I turn off the XF detection on all drives in XDOS (=711 11 12 13 14 15 16 17 18 does it), it works. So no problem for me.

Fujinet Version: 0.5.e6b3e94e 2021-01-22 01:42:35 (as displayed by the Fujinet webserver) Computer: Unmodified 800XL Fujinet power: By Atari (no external power) Other connected peripherals: none 1. In CONFIG, mount all 8 drives in the drive list (no "Empty" in the drive list), drive 1 should be DOS 2. Press OPTION to boot the DOS in D1: 3. Press the Disk Rotate Button 8 times. Problem: The 8th press and all further presses don't work. The blue LED flashes, but SAM doesn't say anything and all drives respond with Error 138. 1. Configure a working WiFi connection (selection bar in CONFIG green) 2. Press Fujinet Reset Button and reboot Atari with SELECT key hold down 3. The CONFIG WiFi selection screen appears (with red selection bar). Now press 'S' (without configuring a WiFi connection) Problem: Selection bar in the host/drive list is red. Should be green, since the WiFi connection still works.

Thanks for the CONFIG tool, it works as expected. I like the key info at the bottom of the CONFIG screens. Very helpful for beginners! I often want to select a drive to boot. But the Disk Rotate Button seems not to work in CONFIG (nothing happens when pressing it). So I must boot D1: (via OPTION), then press the disk rotate button, then reboot. I see the following possibilities to add this function: - Disk Rotate Button works in CONFIG - Add a key press, which does the same as the Disk Rotate Button. This can be indicated on the screen by e.g. an asterisk between the host and drive number in the drive slots list. - Add a key press to rotate the displayed ATR/XEX filespecs as Altirra (Disk.RotateNext function) and other SIO2xx devices. - Add a key press to swap the selected entry with D1: I would prefer one of the last two options.

Fantastic game - it's very addictive! Most times I get only 2 points or so. But sometimes, if I manage to put enough circles on the playfield, I can make 10 or more points. My highscore is 22 points. Thanks for another unusual interesting game!

I tested YASH with Sparta DOS X 4.48 in Altirra: - I can't reproduce any screen problems with YASH & SpartaDOS (without TD.COM of course). YASH saves the DL vector (560/561) resets it and enables DLIs. When calling the DUP via DOSVEC, it restores the DL vector and disables DLIs (NMIEN=64). Setting the DL vector is safe, since it is done with disabled IRQs (SEI), which cuts the OS VBI routine short. (Hopefully, Sparta DOS doesn't disable this standard mechanism of the OS ...) - With "TD.COM ON" the YASH screen is messed up. Reason is, that an interrupt routine of Sparta DOS always inserts the TD line at the start of any display list with some blank lines, even if a program creates a new non-standard display list. This doesn't work with YASH, since it needs an own display list with DLIs and the insertion of the TD line together with some blank lines makes the display list too long for ANTIC. And since the YASH display is shifted down by the TD line the DLIs use wrong colors, since they are based on VCOUNT values. The Sparta DOS manual states the following on p. 108: "TD ON may be incompatible with some programs. If you are having problems with a program, try TD OFF, or do not install it at all." A solution would be that Sparta DOS checks, if a normal display list (with 24 blank lines at the beginning) is shown and if not, the TD line is not displayed. And/or the TD line is only inserted, when there are enough blank lines at the beginning of the display list AND the display is not shifted down for the TD line, i.e. replace 8 blank lines of the DL with the TD line. Perhaps the Sparta DOS developers can do something about this, since the current behaviour of TD may affect all programs with an own display list? @Marius: The interface firmware doesn't support mounting an XEX file - so YASH can't do this. Please send an E-Mail with your request to Thomas Grasel, the developer of the interface. See here: http://www.abbuc-raf.de/

See my earlier post in this thread for an explanation of this code fragment: https://atariage.com/forums/topic/108472-xf551-oses/?do=findComment&comment=2059318

ATASM has the precedence also in its docs. Same as MADS regarding unary < > and binary + -. For me, this is also strange, but it has the advantage, that it has same precedence as unary -, e.g. -5+7 is 2 and not -(5+7) = -12. And you can use expressions like x+<y+z, where you probably don't expect x+<[y+z]. So put the expr in brackets [] and it works as it should without warnings, e.g. lda #<[adr-1].

Hi, I'm the author of the original Hugohunt game for the Atari 800 XL, written in 1985. Here are some more infos on the game: The original game has 9 levels. The 2600 version was ported by Angelsoft and has new levels due to the hardware limitations of the 2600: All levels are now mirrored and at most 2 large items per line in the Labyrinth are possible. There is a version with 7 levels (4K) for the intermediate player and a version with a second set of 7 levels (8K) for the skilled player. Each comes in a PAL version and a NTSC version with reduced screen height. I designed levels 1, 2, 5, 6 and 7 of the second level set and Angelsoft all other levels. See here for download: http://www.angel-soft.de/hugohunt-release-fuer-vcs/ Here is the ZeroPage Homebrew stream on YouTube, where they played Hugohunt: Here are the instructions for the game: hugohunt5.pdf

Sorry, the Atari with QMEG-OS didn't crash - I haven't waited long enough after the screen fills with garbage. The exact sequence is: - Turn on Atari with QMEG-OS - The normal empty text screen appears for a very short time - The screen turns black or (quite seldom) garbage appears on the screen - The OS now tries to boot drive #1 - If drive #1 isn't active, the OS goes to the QMEG menu (which is a replacement for the self test). Normal behaviour without AVG cart is, that the empty text screen remains there while the OS tries to boot drive #1 (like the XL-OS does). I assume, that the AVG cart doesn't activate its ROM early enough before the OS checks for a cart. So the OS places the text screen and the display list at $bcxx and when the cart activates its cart area $a000-$bfff, it implicitely changes the display list which could cause garbage or a blank screen. (The same may happen with a 400- or 800-OS, but I didn't test this.) This doesn't really matter, since you can go to AVG cart's menu with Reset (or Esc from the QMEG menu, which jumps to the reset vector $e474). Sorry for the confusion.

I have a similar problem with QMEG-OS: At power on with the AVG-Cart, the cart is often simply ignored (except the screen often gets black) and otherwise the Atari crashes (garbage at the screen is displayed). After I press Reset, the AVG cart works normally (or I hold SELECT to ignore the cart at power on to avoid a crash). But on the 400 this doesn't work after a crash, since Reset is not a CPU reset, but an interrupt. I suppose, the AVG cart needs some time to initialize itself. The cold reset in the 400-OS and QMEG-OS works much faster, since these OSes don't test the whole RAM, as the XL-OS does. So the cart may have not been initialized fully when the OS jumps to the cart ROM area - maybe the cart doesn't present its ROM at $a000 in time. Many thanks for the AVG cart - it's fantastic.

Hi, I've written a simple level viewer in BASIC for Dungeon Hunt 1 & 2. So if you want to have a preview at the dungeon levels in the DH games, can't find a level exit or don't want to blindly explore or draw the mazes while playing, you can look at them with this viewer. For an example see the screenshot of Dungeon Hunt 2, level 1 below. To use the viewer, boot the ATR and follow the prompts. Of course, you'll need one or both Dungeon Hunt games. For Dungeon Hunt 2 see the ABBUC software contest 2019. (This viewer is published with jacobus' agreement.) Have fun! DH12VIEW.atr

@Marius: Standard Ultra speed sector skew in DD is 8 of 19 (for use with Pokey divisor 9), i.e. with 300 RPM = 5 RPS, time for 1 DD sector is 8/19*0.2s, so 1 KB takes 4*8/19*0.2s = 0.337s, which gives 2.967 KB/s. So 3 KB/s is correct for Ultra speed! What did you expect? Normal DD sector skew is 16 of 19, which gives only 3 KB/s *8/16 = 1.5 KB/s and XF high speed (=warp speed) sector skew is 10 of 19, which gives 3 KB/s *8/10 = 2.4 KB/s. Even with Turbo speed sector skew 7 of 19 (Pokey divisor 6), you get not more than 3 KB/s *8/7 = 3.4 KB/s. You can decrease the sector skew by one sector, but then you'll get timing problems, if you use long VBIs or (lots of) DLIs.