NOS version 0.4.2 released

[kenp]

1 hour ago, tschak909 said:

Yes, you can flash the device, while plugged in to the Atari.

 

-Thom

Sorry I got interrupted by a call and didn't catch your reply in time.  I just plugged it in with the USB cable and away everything went.  Very nice, very smooth.

 

But now I have to plug everything back together an see if the tricks I was trying work better.   🙂

[kenp]

Back here because I'm trying a thing with NOS. 

 

So I'm booted from the Irata NOS.  I have two local servers running the TNFS software so I can watch the attempts to copy things across from one to the other.  Both connected, one as N1: and the other as N2:.  Both giving me the correct directories in response to a DIR command. 

 

(This is a little like Zeno's Paradox.  Always a little closer but never quite reaching the end.)

 

But when I try a COPY command   ....   COPY N1:FARKLE N2:/   ....   the screen changes to bright green type on a dark green background, there's no activity and a return to the N1: prompt.  I can use still DIR commands but NCOPY always returns CMD? and after the first attempt COPY just returns to the N1: prompt.  Stays in green screen.

 

(FARKLE is simply a 368K disk image file minus the .ATR extension. )

 

Of course the end point in this game is to download a copy of NOS and SpartaDOS with the N: handler and commands so I can boot them locally but as close as I get the process stops when I issue the COPY commands. 

 

(btw, I get the same results if I try this for copying files from the Irata server but I set up a second server here so I could follow the logs from both sides to see what might be happening.)

 

Any help or suggestions appreciated.

[+DjayBee]

I am not sure if COPY already works.

When I last used NOS at v0.3.0, COPY was still on the to-do list.

[kenp]

NOS is at 0.42, if I remember correctly.  In a video, which I guess now is in the other thread, an example was shown where the fellow connected to the Irata servers, got a directory list then copied a file CYCLOD.XEX on the remote to his system as CYCLOD.COM so COPY should be working.  I've got the traces from the servers and I could take a camera picture of the screens since I'm not using Altirra yet to show what I'm seeing. 

 

It's going to be something stupidly simple and astonishingly obvious once seen like the way I was incorrectly trying to connect to the servers before.  Now I've got the connections, I can get a directory lists so I know I've got the right connections. 

 

I just tried making a directory using an MKDIR command and that works.  It doesn't look like it because it returns a status 138 but the directory does get created.  RMDIR also deletes the directory.  I was also able to delete one of the FARKLE files that was on the local server but it returned a 138 again after the delete was done.  So I'm connecting, creating new data objects on the servers, deleting objects on the servers, getting some weird messages but the actions are happening.

 

 I feel like I'm down to the last 1/64th of the distance to the target.

[16kRAM]

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.

Edited March 23, 2023 by 16kRAM

[+DjayBee]

15 minutes ago, 16kRAM said:

NOS is an attempt to implement these as internal commands. 

You might reconsider this because NOS is quickly approaching some sort of size wall.

 

When I hacked it last for my Syncalc PoC, I already had to disable many functions to keep MEMLO below the required limit.

(Yes I know that it is uncommon to have code starting at $1700 and also hijack some 500 bytes between $700-$1100.)

Edited March 23, 2023 by DjayBee

[16kRAM]

11 minutes ago, DjayBee said:

You might reconsider this because NOS is quickly approaching some sort of size wall.

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

[kenp]

8 hours ago, 16kRAM said:

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.

Alright, then I'm not going mad or quite as dumb as I feared.  SO much happening.

 

Good to know the colour change was planned and not something gone awry.  Very good.  You have to mark the stubs somehow to know what's going on.  I can keep an eye open for that in the future and not panic that I've done something horribly wrong.  Hey, wait, is there a little back door command to put the colours back to normal?

 

Yes, the NCOPY demo was happening, I think, in one of the enabled DOS versions but I haven't gotten it to work there, either, that's why I came back to NOS to try.  I'll go back to the DOSes and keep pounding away on trying to get the NCOPY working.  As I mentioned, what's stopping it is going to be something very simple and stupidly obvious once it gets going.

 

The idea of an NOS is good and I like it but I still have bunches of floppies to migrate stuff from and the possibility of having the Atari connected to the virtually inexhaustible hard drive space on my Linux machines is so tempting.  I've been doing copies to .ATR files but there are tools in the raw Linux environment I'd like to use on the plain Atari files as well; sorting, finding dups, etc.  I can see a day coming when I won't need the floppies any longer.  I might keep a few in a picture frame as a tribute to the old days.  (but then why is an adapter for putting an ISA card in a new computer just so I can get a new floppy disk interface card into a Ryzen machine and have several different floppy drives so tempting at the same time.  I'm so conflicted.  🙂 )

 

Take care.  Thank you for all the effort to bring this old platform into a new day.

Edited March 23, 2023 by kenp

[16kRAM]

13 hours ago, kenp said:

Hey, wait, is there a little back door command to put the colours back to normal?

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

[kenp]

8 minutes ago, 16kRAM said:

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

Of course, and I did think about that a bit after I closed off that comment.  I never got the attention span together to get back and edit it or answer it myself.

And it's a thing I've caught myself doing lately to get back to a known state.  BUT it's not something that we just do with our new computers, is it? 

The old computers like these Ataris are a much simpler system compared to the new Linux based 8/16 core/thread 32GByte DRAM monsters we're used to now.

[desiv]

Not sure if this is expected behavior or not, but I just noticed something interesting (to me).

When loading some XEX games (not most) from a mapped TNFS drive, they won't run.

But when I mount the XEX file directly in the Funinet program, they run fine.

This is on my 400 with 48k RAM.  I was figuring they were just bad XEX files or not compatible with my 400, until I tried attaching the XEX file to the drive in the Fujinet app and hitting OPTION and it just ran.

I had that happen with the XEX files for Pacman and MsPacman.

But most other XEX files with the NOS boot image, I just type "load file.xex" and they run...

 

Not a big deal, but just something I noticed...

[_The Doctor__]

Perhaps the file needs read, write and/or the file is multi part/segmented/stage loaded and the network connection won't stick around for that, where as a local copy of the item is now on an SD card and can have all of those things.

Edited March 26, 2023 by _The Doctor__

[desiv]

9 minutes ago, _The Doctor__ said:

Perhaps the file needs read, write and/or the file is multi part/segmented/stage loaded and the network connection won't stick around for that, where as a local copy of the item is now on an SD card and can have all of those things.

I mean I can attach the same file from the same TNFS server in the Fujinet app and it works fine (and I almost never mount read/write, I think Ultima III is the only time I've done that).  But if I try to "load" it from NOS from the same TNFS server, it fails.

 

I haven't tried it from the SD card.