16kRAM

One (perhaps) unsatisfactory workaround is to find an alternate version of the games that are exhibiting this behavior. I suggest trying the Homesoft collection, either at http://mushca.com/f/atari/ or at tnfs://atari-apps.irata.online/Atari_8-bit/Games/Homesoft. From the Irata TNFS server, it is possible to copy the Homesoft xex files to your personal TNFS server using the Copy feature found in CONFIG. Regarding Galaxian, here is the code at $5580. This is the entry point of the program - defined in the binary file's RUNAD block ($02E0..$02E1) At $5584-$558A, you can see $5500 being loaded into DOSINI (00 --> DOSINI & 55 --> DOSINI+1). DOSINI doubles as the Cassette's Run Address. Presumably, after the warm start, execution should commence at $5500. With that thought, (if one is feeling a bit hacky), it is possible to modify your copy of the Fandal Galaxian.xex so that the binary file's RUNAD is $5500 instead of $5580 and it will skip this warm start code. Though I'm sure the last thing the world needs is another variant of a game image. I've done no more than boot this XEX so something may break during play. So in a modern hex editor, open the Fandal Galaxian.xex, scroll to the bottom of the file and change the last 2 bytes from 80 55 to 00 55 and save. BEFORE AFTER Looking at $5500, it is indeed as @twh/f2 noted, in the Fandal Galaxian, there is code related to a cassette version.

Using the FujiNet, I'm able to reproduce the error mounting this Galaxian XEX to a device slot and booting. https://a8.fandal.cz/detail.php?files_id=1942 My understanding is that for loading XEX files via CONFIG, the FujiNet concocts a blank MyPicoDos ATR image and injects the XEX file onto it. From Linux, creating a MyPicoDos ATR file using dir2atr for this Galaxian binary results in similar behavior (constantly resetting). dir2atr -b PicoBoot406 galaxian.atr galaxian (where "galaxian" is a directory containing "galaxian.xex") However, grabbing a random joust.xex from my folder, I was able to create an ATR that boots successfully. dir2atr -b PicoBoot406 joust.atr joust (where "joust" is a directory containing "joust.xex") Perhaps some incompatibility exists between this galaxian.xex binary file and the MyPicoDos's binary loader. The binary file blocks for galaxian.xex are straight-forward enough. ataricom 0.30-200502 (c) 2008-2020 Matthias Reichl <hias@horus.com> block 1: 5500-75ff (bytes: 2100, offset: 6) block 2: 02e0-02e1 (bytes: 2, offset: 210a) RUN: 5580 So it will take some tracing to better understand where things go awry. Edit: corrected "using this Galaxian XEX" to "mounting this Galaxian XEX".

Textfiles.com maintains a database of historical North American BBSs. Here it is organized by area code. http://bbslist.textfiles.com/usbbs.html Also, what I assume to be a repository of just the list files themselves. http://www.textfiles.com/bbs/BBSLISTS/ http://www.textfiles.com/support/ Edit: Corrected from "US" to "North American"

If I'm seeing things correctly, this would save 2 bytes as execution continues under the BNE only if TRAMSZ is zero. So save the zero in the X register and reuse it to store into BASICF. CHKBA LDA LDX TRAMSZ ; set to 1 if cartridge is present BNE BASREADY ... STA PORTB LDX #$00 STX BASICF ; Set flag to keep BASIC enabled in PORTB on reset

After upgrading my Linux machines from Debian 11 Bullseye to Debian 12 Bookwork, I was disappointed to find that I was forced to disable the DirectX 9 and 11 options found under the Altirra menu item Tools --> Options --> Display in order to get any video output. Being limited to the non-DirectX video was a little soul-draining after having become accustomed to the heart-warming NTSC / PAL emulation produced using DirectX. But after an evening of testing settings and nuking my wineprefix before trying something else, I found that changing the rendering engine to Vulkan allowed the DirectX 11 video option to work again. Assuming you have the Debian winetricks package already installed, $ winetricks --gui "Select the default wineprefix" --> OK --> "Change settings" --> OK --> "renderer=vulkan" --> OK Then hit "Cancel" until winetricks closes. Performance-wise, on my machines, the Vulkan renderer is not as quick as the previous version (presumably OpenGL). This becomes more obvious in full screen mode. Anyway, this was my experience. Hope it helps others in the same boat (or at least my future self when I forget what I did to make it work). Edit: Corrected Altirra menu item path.

https://www.atariarchives.org/mapping/appendix19.php

Pressing the RESET console switch or issuing the WARM command will revert the color registers to their default values.

I agree. Some commands could be offloaded to external executables.

Hi. A COPY command is not implemented in NOS yet. When implementing a new command, the first thing I do is add an entry to the command table and a subroutine to change the COLOR2 register, just to be sure I have that part working. I've had several false starts with COPY but have left have the command table entry and stub routine enabled. I should've commented it out to avoid confusion. You'll see the same for LOCK and UNLOCK but with different colors. Regarding a video of a copy function, I suspect it was a demonstration of one of the N: device-enabled DOSes found under irata's DOS directory. There, you'll find an NCOPY.COM alongside the other N-device commands (NCD.COM, NPWD.COM, ...) all implemented as external executables. NOS is an attempt to implement these as internal commands. For NCOPY/COPY in NOS, we've thought about this being handled by the FujiNet itself and NOS sends an SIO command to FujiNet asking it to handle it. This would avoid clobbering memory on the Atari where maybe you are editing a BASIC program or something. The other option is to use a small buffer in the N-device space and the NCOPY/COPY command performs many, many short reads and writes to accomplish the transfer of bytes. In a traditional floppy-based DOS, this would require a million disk swaps, but with NOS that wouldn't be the case. Regarding the 138 returned by MKDIR/RMDIR. I've seen the error code, too. I'll have to debug to understand why. But for now it can be ignored.

This reminds me that my intent is for the byte $0D to be ignored during batch file parsing so that $0D $0A is treated the same as $0A. I'll take a look at the code to understand why it isn't behaving correctly.

You have the right idea - NOS.BAT should just contain NOS commands such as NCD. It can not parse BASIC commands. My first thought is it has something to do with the end-of-line (EOL) character in the file NOS.BAT. The last byte of the file NOS.BAT needs to be either a $0A (Unix EOL) or $9B (Atari EOL). Windows EOL ($0D $0A) doesn't work well as it results in a garbage character when being read by the Atari. I'm unsure what Apple uses. If there is no EOL character at all, NOS will just continuously beep searching for an end-of-line. For example, here I'm using hexdump from my modern computer to examine the bytes in the file $ hexdump -C NOS.BAT 00000000 4e 43 44 20 4e 3a 54 4e 46 53 3a 2f 2f 31 39 32 |NCD N:TNFS://192| 00000010 2e 31 36 38 2e 30 2e 31 39 35 2f 0a << Unix EOL |.168.0.195/.| $ hexdump -C NOS.BAT 00000000 4e 43 44 20 4e 3a 54 4e 46 53 3a 2f 2f 31 39 32 |NCD N:TNFS://192| 00000010 2e 31 36 38 2e 30 2e 31 39 35 2f 9b << ATARI EOL |.168.0.195/.| If you edit NOS.BAT from a text editor on the Atari, then you will be assured the end-of-line character is $9B. I'm attaching the T:EDIT editor for the Atari below. You can drop it in your TNFS-shared folder and run it on the Atari using the example below: ( Note: T:EDIT apparently uses the same address space as BASIC in ROM, so be sure BASIC is not resident (if 800XL/XE, etc boot while holding the OPTION key) or use the NOS command NOBASIC to release BASIC's address space back to RAM. ) N1: NCD N1:TNFS://192.168.0.195/ N1: LOAD TEDIT.COM Once in T:EDIT, Enter the NOS commands to be executed when NOS is loaded. @SCREEN NCD N1:TNFS://192.168.0.195/ (be sure to hit ENTER here - EOL char appears as left arrow) CTRL+S to Save, Save as N1:NOS.BAT (Note: If you ever encounter an application that complains about the Nn: device, substitute Dn:) CTRL+Q to Quit to DOS CTRL+L will load (if you need to make changes later) INSERT adds spaces The @SCREEN command will print the batch file statements as they are being parsed. This may help troubleshoot if all this turns out to be the wrong answer. TEDIT.COM

I've attached an ATR file which has AtariWriter.xex transferred to an ATARI DOS 2.0s floppy and renamed to AUTORUN.SYS. Following assumes FujiNet hardware version 1.3 or greater. (1.0 may not support SIO daisy chain). 1. Copy the file AtariWrite.atr to the FujiNet SD card 2. Set the Device Select switches on the physical floppy drive to be device #2. such as https://archive.org/details/atari1050multilingualmanual/page/n6/mode/1up?view=theater 3. Boot into the FujiNet Config screen 4. Select the AtariWriter.atr image from the SD host into Drive Slot #1 5. Leave Drive Slot #2 unassigned 6. Boot using the OPTION key (remember to continue holding the OPTION key to disable BASIC if on a non-400/800) 7. At the ATARIWRITER menu, [L]oad a file from D2: (I could not find a way to index on D2:, so you'll need to note the AtariWriter document filenames beforehand). I've tested using the Altirra/FujiNet-PC environment. Hope this works for you. AtariWriter.atr

My guess for the weird input configuration on the Atari is due to it being an Apple II port. On the Apple II, the original game controllers were a pair of analog paddles (to support Woz's Breakout). So, two paddles with one button each. Later the two potentiometers and two buttons from the paddles were merged into a single joystick with two buttons. On the Apple II, a player could comfortably hold a paddle in each hand and press the fire button on each - or - employ the two buttons on a single joystick. When the game was ported from the Apple II to the Atari, they must've decided to adhere to the Apple's two button input. I suppose if someone were to use paddles on the Atari version, then the input might seem less awkward.

I should've included a bandwidth-friendly path to these scans. https://archive.org/details/AdAstraV2n3 https://archive.org/details/AdAstraV2n4

While attending the recent "Atari 8-bit Computer Old School User Meeting" graciously hosted by the National Videogame Museum, in a box of mostly unremarkable floppy disks, I found two more issues of Ad Astra... These have been scanned and uploaded to the Internet Archive (links below). https://archive.org/download/AdAstraV2n3/adastra_v2n3.pdf https://archive.org/download/AdAstraV2n4/adastra_v2n4.pdf I typed in the BASIC and assembly programs found in Volume 2 Number 3. (Hopefully no typos) adastra_v2n3.atr The MORSEGEN program is interesting. It installs a timer driven interrupt routine that converts typed text into Morse code beeps. A portion of the stack is used as a keyboard buffer so you can type as fast as you wish and the Morse code beeps will play at a steady rate, eventually catching up to your input. The code header explains how to use the program. Several years ago, I had found Volume 2, Issues 1 & 2 in a local video game store. It turns out the same collector who sold those issues to the store also donated the box of disks to the meetup. So it was just good fortune that I happened to have been to both at just the right time.

If you follow the ANTIC podcast, you may recall an interview with Bruce May regarding a strategy game he created in 1982/83 called "Magic Castle". Mr. May submitted the game to several publishers for review but none agreed to take on the title. What remains of the game is available in scans of the BASIC listing, a print-out of a memory dump, design and programming notes, and a user manual. A link to the interview is found here: Scans of the artifacts are here: https://archive.org/details/magiccastle_atari/Magic Castle Compiled Code I've re-digitized the game assets as well as performed some light reverse-engineering of the binary data. I did have to inject some of my own code to transition from binary load of AUTORUN.SYS into launching the BASIC program. What I did was a kludge but it works. https://github.com/michaelsternberg/magic-castle My goal for the project was to re-implement the game exactly as found in the BASIC listing and binary data. With this in mind, the only thing I would consider a bug would be a transcription error between the scan and the implementation. I am aware of some minor issues but I've confirmed these are what's in the original data. I suspect the code listing and binary data might be from a version prior to the one submitted to the publishers. I say this because the user manual describes 3 levels of what is called the "Void". However the game data and programming has only 1 defined. Below is an ATR image of the game disk. Requires ATARI BASIC If playing on an emulator, you may need to press the CTRL key while using the arrow keys. (On a real ATARI, CTRL is not needed). Read the user manual as this is a strategy game. The rules and victory condition are not obvious. I hope this at least quells some of the curiosity listeners of the interview might have had. For sure, Bruce May created a charming game design and performed a heroic programming effort to turn it into something real. It's a shame that Mr. May was unable to find a publisher and it's a shame we've had to wait so many decades to see it. Magic Castle (1983)(May, Bruce)(US)[BASIC].atr

Forgot to include a link: http://retrotinker.blogspot.com/2017/11/building-coco-games-with-inform.html

This thread demonstrates it's possible to extract Infocom's Z3 interpreter from one of Infocom's Atari disk images and append your own Z3 story. Links at the bottom of my post in that thread may help point you in the right direction. After a pretty intensive month or so of development, I was able to do it with Grue Z3. (Though I had the advantage of starting with someone else's story). https://github.com/michaelsternberg/grue_z3 https://16kram.com/2017/07/20/an-apple-ii-build-chain-for-inform/(Apple II example - but the build instructions for Inform 6.15 and "hello world" example would apply to any 8-bit platform) John Linville's series of posts in Inform and the Coco show a little more sane method of injecting a story file into a disk image. I clumsily concatenated the interpreter, story file, and padded out the remainder of with 0s. Hope it helps.

I recently chanced upon two issues of Ad Astra... - The Journal of the Atari Microcomputer Net Amateur Radio Operator Users' Group (volume 2 nos. 1 & 2) at a local used video game store. Before that, I was completely unaware of this publication but now I'm intrigued by the technical level of its articles. I've scanned my 2 copies and uploaded them to archive.org. Mr. Savetz has already archived volume 1 nos. 3 & 4 in 2017. For my scans, I created two versions of each: one that is strictly monochrome and one that is gray-scaled. Other versions were generated by archive.org including some with OCR. Inspect the archive.org Files section depending on your level of interest. Here are links to the 4 issues so far: v1n3: https://archive.org/details/AdAstraV1n3/ https://archive.org/download/AdAstraV1n3/Ad%20Astra%20v1n3.pdf v1n4: https://archive.org/details/AdAstraV1n4/ https://archive.org/download/AdAstraV1n4/Ad%20Astra%20v1n4.pdf v2n1: https://archive.org/details/AdAstraV2n1/ (mono): https://archive.org/download/AdAstraV2n1/Ad%20Astra%20v2n1%20mono.pdf (gray): https://archive.org/download/AdAstraV2n1/Ad%20Astra%20v2n1.pdf v2n2: https://archive.org/details/AdAstraV2n2/ (mono): https://archive.org/download/AdAstraV2n2/Ad%20Astra%20v2n2%20mono.pdf (gray): https://archive.org/download/AdAstraV2n2/Ad%20Astra%20v2n2.pdf Does anyone else own any other copies? It'd be cool to complete the run. - Michael S.

As far as eking out another scan line per character to create a more readable font, the math may not support it. The PLATO terminal's character mode is 64x32 characters. With the 192 scan lines on the Atari, that leaves exactly 6 scan lines per character row - which is where it is now. ; .##..... ; #..#.... ; ####.... ; #..#.... ; #..#.... ; ........ I'm not a graphics expert so maybe there's some overscan tricks, but it'd need 32 additional scan lines to add one to each character row.

Update: My attempt to quote tschak909 didn't work correctly. Posted by tschak909 on Mon Feb 19, 2018 8:17 PM Somebody took TLP and made an xex out of it, and it has a very odd bug, where just before it finishes drawing the password prompt, the cart somehow falls out into the weeds and jumps to warm start.... Not a bug. There is some copy-protection being employed here. At B863 exist 12 curious bytes. This is a bit of obfuscated code that is decrypted and copied from ROM to RAM in the subroutine at B84B. lda #<(LB863-1) ; Address of obfuscated code (well, minus 1) ldy #>(LB863-1) ldx #$0C ; Initialize counter to 12 jmp sub_b84b sub_b84b: sta off_EC ; Create pointer to obfuscated code sty off_EC+1 ; ldy #$00 ; Point to the first byte lda #$55 ; Decryption key 01010101 sec @LOOP: iny ; Increment pointer index rol a ; Rotate the key 01010101 -> 10101010 pha eor (off_EC),y ; Decrypt the byte using exclusive OR sta L3E33-1,y ; Save the byte to RAM pla dex ; Decrement counter bne :@LOOP ; Continue looping while counter not equal to 0 jmp L3E33 ; B860 4C 33 3E LB863: .byte $65,$AA,$12,$F7,$49,$D5,$25,$A9 .byte $19,$DC,$B2,$CD Here is the decrypted code. (Note: BFFC is in the ROM's address space and contains a 0). L3E33: DEC $BFFC ; Try to alter a ROM address from 0 to -1. LDA $BFFC ; Load "altered" value into CPU. BEQ $3E3E ; Still equal to 0? Yes, you're cool. RTS JMP COLDSV ; No? Stinking Pirates! Reboot RTS ; One de-protection solution is to change the 4C (JMP) at B860 to 60 (RTS) in the ROM file and re-convert it to an XEX. - Michael

Hi Thom, I'm interested. While stepping through the disassembly, I often leave my connection open for a long time. I'd feel better doing that in a sandbox. Also I like the idea of worry-free filling up the pbnotes with Atari-specific threads. - Michael S.

Thanks for the help. For sure, I am still finding this part confusing.

https://archive.org/search.php?query=creator%3A%22Dorsett+Educational+Systems%22 Update: Sorry. I realize now you're asking about the Fractions package specifically.

Here's a link to the code found in The Learning Phone. https://github.com/michaelsternberg/tlp/blob/50aada8a8fe7c7673f9b7feeb48bbd47c2647d04/tlp.asm#L3587