Pab

You're using a hard drive, not a single floppy configuration. My plans are to essentially do away with the concept of "work disk" and let the SysOp specify folders for text/info files, file catalogs, etc. I doubt anyone running a BBS in 2023 is going to rely on a single <360K floppy disk for everything. Just making sure.

Going through the code, looking for things that can be jettisoned and that need to be corrected.... Is there going to be anyone running this thing (virtually or on real hardware) with a single disk drive?

Can you record what your machine is doing from first running LINK20X.bas until the AT loop you describe? Just cellphone footage would help. I can try to figure out exactly where the problem is happening and try to fix or work around it.

As for the drivers you might be onto something. AtariLink relies on numeric response codes because scanning for alphanumeric strings would take too much code. Open a terminal. Type ATZ and hit enter. You should get “OK” back. Then type ATV0 and hit enter. You should get 0 as the response. If you get “OK” then the person who wrote the driver took the cheap way out by not bothering to include numeric response codes. Which for 99% of software won’t matter. It does in this case.

The long lines were created through an old Atari BASIC trick to compress the code as much as possible. The lines were typed with abbreviations that are then expanded after being tokenized. For example… F.X=1 TO 20:IF X/2=ABS(X/2) THEN GOS.200:GOS.500:POS.0,0:?X:G.2000 is 65 characters as far as the editor is concerned, but expands on listing to 84. With a packed line it’s very easy to go over the 120 character limit imposed by the E: device.

Try adding a ?#C2;"+++";:FOR X=I TO 500:NEXT X (Or a similar method of delaying) before the ATE0 This (+++) should grab the modem's attention and enter command mode. Before you run it, power cycle the modem and take out all of the S= statements. I think somehow they got screwed up.

Finding my definition block, here are some of the more commonly used routines, some of which could probably use some fine tuning. Open Modem (OPM): Line 460 Close Modem (CLM): Line 440 Read text file into buffer (RF): 9000 Send text file in buffer (SF): 9500 Get a "Yes" or "No" (YN): 270 "File Convert" - add appropriate extender to filename (FCNV): 8960

One other thing, IOCB 3 was the printer that was supposed to always be connected for the log. If you don't want any logging you can just take out any of the ?#C3; references, or you can change the reference to "P:" in 32007 to anything else. If you do that, though, you ought to add a CLOSE #C3:OPEN #C3,C8+I,0,"(whatever)" to the routine where it connects a caller, just to make sure the file is closed and written to regularly.

I'm also finding stuff I had forgotten about that was under development when my machine gave up the ghost. It looked like the disk I found and started adapting for Altirra BASIC was not my release version, but one where I had stuff in the works that I never finished and forgotten about. For example, on line 780 there is a reference to a file called EXTENDRS that should be loaded and kept handy to be sent after a connection is made. Now I realize what this was. My plan was to let SysOps do multiple file extension definitions instead of the traditional ASCII/ATASCII. For example, you could have added menus in VT-52 or ANSI and made them available to the caller. EXTENDRS was going to list them and ask the caller to pick from the menu which experience they wanted. When I sent this along originally it was causing the machine to look like it was hanging when it made a connection, where in truth it was just waiting for someone to select an extender type from a list that never got sent! It would be easy to add this back in and finish it. Found it. Line 8970 (FCNV+C10) selects the appropriate three character extender from CTRL$ starting at position 17, apparently.

IOCB #2 should be opened to the modem most of the time, unless you are doing a local (SysOp) login in which case it is reopened for E:, if I remember correctly. If it's printing AT to the screen, it might be that it's somehow stuck in local login mode and never opened/reopened the modem. It's been so long since I used the Hayes command set, I'm very rusty. ATE0 tells the modem not to echo characters sent to it (full-duplex mode). The S= commands set different flags. It should be one long command string with the CTRL-M at the very end (after the S37=10) Had to go to Wikipedia for this one: S4=24 S2=255 S7=5 S37=10 This is weird. The S7 should wait 5 seconds for a carrier after connection, which is okay I guess, but the others are gibberish. It's saying the line feed should be CTRL-X (instead of 10), escape character 255 (should be 43 or "+"), and it tries to connect at 14,400bps (S37)! I think you could safely take the rest of the line out, with all the status registers. The important stuff is either set elsewhere or is the default.

Here, for ASM/ED: 10 *=$600 20 PORTB=$D301 30 LDA PORTB 40 AND #$FD 50 STA PORTB 60 RTS I'm at work without access to my 800 or Altirra, so I'll leave it to you to compile and save.

If you plug in any cartridge, it's going to swap out the RAM from $A000-$BFFF (or $8000-$9FFF with 800 right cartridge) so it's defeating the purpose. BASIC would be disabled, but you would still not have RAM there. I assume you're not using SpartaDOS. You could probably write a quick AUTORUN.SYS program to toggle the "BASIC enabled" byte in PORTB.

Working with FastAssembler lately, I've been writing my source code on a PC using EditPad 8 as my text editor. (It supports ATASCII and I have syntax color schemes for both 6502 source and Action! for it, so it's pretty handy to work with.) I then run a batch file in SDX in Altirra to copy my code through ECP, run FA, and run OBJ2ACT. The other day, a thought occurred to me: what would be involved in creating an IDE for FA on an 8-bit machine? How could something along these lines be pulled off on an actual Atari? My first thought would be a stub program, including routines for accessing and utilizing banked RAM, which would load and jump through the INITAD vector to move MEMLO to protect itself. The next module would be our main IDE program and text editor, which would be loaded into one bank and utilize a second bank for its editor text. Then the RUNAD vector would jump to code in the stub to switch to the proper bank and run our editor. When the time comes to compile, we JSR back into the stub, which restores the main bank, loads an appropriate command line, and uses SDX calls to run FA. When it's done, the stub retakes control, goes back to the bank holding our IDE/editor, and returns control. When we're done and exit the program, it would return to the stub which would close anything open, restore the old MEMLO, and exit through DOSVEC. Fancier stuff like using redirection to pipe the output from FA so we can display it in a window in the IDE might be a bit harder to do, and probably beyond the capabilities of the machine, but the basic functionality of an IDE might not be too hard to pull off. Just a thought experiment here. The feasibiliy of writing a program to "wrap around" and call an existing program. Not the most practical application but there could be other uses for such an approach.

And...you lost me. Oh, well.

CompyShop 576K works but RAMBO 320K doesn't. I will admit I haven't looked too hard at the source code. Is there a way to build an "OSS" cart from the 3.7 sources instead of the original 3.6?

I will. Thanks to JAC and everyone who contributed to 3.7 by the way. Not having to expand my symbol table allocation alone is worth some screen scramble when writing.

Solved it. Stupid me. The configuration I had for SDX was to USE BANKED. Thus, any time disk buffers would be needed, SpartaDOS would swap out the RAM from $4000-$7FFF, then restore it when it was done. With the "plain" 16K cartridge, all memory from $8000-$BFFF becomes ROM, so when running the CAR command SDX first relocates the display list from $9C20 and screen RAM from $9C40 to $7C20 and $7C40... right in the middle of the banked RAM window. So not a bug in ACTION! 3.7p, and not so much a bug in SDX, but an unintended consequence of using the "plain" linear 16K cartridge. Any program I ran that switched banks would end up causing the same problem. Also not really something that's easily fixable, especially for a niche situation (after all, how many non-game 16K linear cartridges are out there?). So I guess I'm going to have to either use 3.6, a disk version, or just put up with screen scramble when accessing banked RAM.

Yes. The 3.6 works fine. The “3.7 OSS” (really still 3.6) cart also works. Only the “plain” 16k cart image glitches.

Forgive me if this has been addressed upthread; I didn't see anything when I searched. Using the plain 16K cart image of 3.7 (March 2023 build and all before) in Altirra (latest build) emulating the U1MB and SDX 4.49. During disk access (compiling from disk, saving, or even writing the CAR.SAV file exiting to DOS) the display list and display get scrambled. All returns to normal when the access is done. Does not happen under other DOS's, turning off HSIO in U1MB does not affect it, nor does turning off PBI or disabling the SIDE3 SD support. Does not happen in disk versions. Have not dumped the image to cart so can't try it in my actual 800. Sample screenshots included. Doesn't affect the function of the cart, just darned annoying.

Oh, I agree. The super maps were a kludge and the new code is a much more elegant solution.

Finally have time to follow up on this.t It appears that when the new routines for random-access "point" operations were written sometime after SDX 4.2, the existence of "super" maps was ignored. Thus, if a "super" map is created for a file it is ignored by the system, and its sector(s) not deallocated when the file is deleted. (They were also not deallocated under 4.2, as they were never fully implemented or properly documented. However, the new routines seem to have solved the problem of "point"ing to a location deep within a large file requiring the chain of sector maps to be scanned from the beginning (which is what the super maps were meant to fix) so they aren't needed any longer. So, mystery solved.

I shipped it to Larry, who couldn't even get it to spin up. Not surprised considering how old it was. Just as well. Thanks to all who offered advice.

Yeah. Here are some pictures of the beast. I remember using an old XF551 case for power and housing with the ribbon cable hanging out a notch I carved out in the back. Now that I think about it, I don’t remember using it with my MIO. I think it was only after I had the Black Box and floppy board that I got the hard drive. I don’t have a PC with a PCI slot right now but could probably hash one together and drop CentOS on it. Then I could always use dd to image the drive to a 10Mb file. Then I’d just have to decode it to figure out where all the partitions are and how to make ATR’s out of them to eventually move onto the Incognito CF card. Manufacture date is (get ready) 23 September 1987, so I don’t plan to apply power or do anything else with this drive until it can be properly connected and ready to dump. If anything is recoverable I will have one shot at it.

I have an old 10mb scsi hard drive I used to use with an MIO and then with a Black Box. I’d like to try and access the data on the drive (if it hasn’t completely deteriorated). I currently have an 800 with Incognito and an Altirra install on a PC with Windows 11. No XL/XE and no adapter. What are the best options for trying to access the drive?

Looking at mine, I definitely have the flat pin connectors (and a few of them have bent annoyingly in my efforts to reseat it; I'd forgotten what a pain pins could be). I think I'm going to build my own ribbon cable at this rate. Standard 8x2. If it still gets flaky, then I'll try replacing the socket. Trying to minimize the amount of soldering I have to do.