U1MB, Incognito, SIDE2, SIDE3, 1088XEL/XLD Firmware 4.0 Released

[ivop]

This sounds exactly how it should be done to cope with very deep directories. And this:

18 minutes ago, flashjazzcat said:

and I usually push the file pointer to a stack (not the hardware stack) for each directory level.

...is what I meant by using a list (or a separate software stack) which is not populated by recursively calling a function for each deeper level, but it just keeps track of tasks to be done.

 

You were already aware of the problem, but I thought I'd mention it in case you didn't.

[flashjazzcat]

No worries.  I've been at it a while, for better or worse.

 

In any case, one could process tree levels without access to any file pointers if it was possible to open eight or so directory channels all at once, but this is rather inelegant and we only have three channels here anyway. So it's a case of:

• Encounter directory
• Push file pointer on stack, bump tree level
• Close file
• Open subdirectory
• So on...

At the end of a directory, if level > 0, pull the top file pointer off the stack, open the parent directory, and seek to the saved position. We also need a stack for the path spec as well, so we can add and remove subdirectory names at the end of it as we go up and down the tree.

 

Just about at the point of getting something out of my raw directory channel, anyway.  Directories have a file size of 0 in FAT, so I'm setting the file size to $FFFFFFFF (internally, in the FCB) for everything but the FAT16 root directory, whose file size is set to that of the directory (which is of a fixed size and may not expand). Very easy to completely destroy a directory until this is well tested, of course, although in practice one would use write mode on a directory simply for direct manipulation of existing entries rather than the allocation of new ones.

Edited October 7, 2021 by flashjazzcat

[flashjazzcat]

Finally got raw mode working properly as a random access file stream, but was disappointed initially by the fact directory listing was much slower. Of course this is caused by the fact we're reading large amounts of redundant information (VFAT long filenames and deleted entries) 32 bytes at a time through the CIO (the prior version was filtering the filenames, so this data was never transmitted in the first place). Easy fix for this was to read the raw directory full sectors at a time and maintain an internal buffer. This allows the data to burst and it's actually faster than the initial version. This will work fine when walking the tree as well; we need simply seek to the start of the current sector and keep track of the internal buffer offset at each level of the tree.

 

Next to finish append and update modes, then turn attention to the main loader again so I can think about a beta, finally.

Edited October 9, 2021 by flashjazzcat

[flashjazzcat]

DOS is feature complete, with just things like recursive copy, time/date set, etc, to add. I might have to release the beta with a curtailed set of main loader enhancements just to get something out there.

 

I also added a CAR and BASIC commands. This video shows BASIC XE being used with the new DOS and command processor, all launched straight from the SIDE3 loader:

 

 

 

[Level42]

Freaking awesome.

 

I can do some beta-testing if you’d like.

[+Stephen]

Can't wait to check this out!

[Beeblebrox]

@flashjazzcat  Fantastic.... yup... can't wait to try the beta in whatever stage it's at. Well done.

[Level42]

Beeble…..

 

It’s funny to see you write a posting of one line and then 16 lines of signature….???

[Beeblebrox]

31 minutes ago, Level42 said:

Beeble…..

 

It’s funny to see you write a posting of one line and then 16 lines of signature….???

 heh heh @Level42  ... you are so right!    Funnily enough I have a widescreen monitor so only get 8 lines! Gonna slim it down sometime soon.

Edited October 15, 2021 by Beeblebrox

[Atari8guy]

On 10/15/2021 at 2:36 AM, flashjazzcat said:

DOS is feature complete, with just things like recursive copy, time/date set, etc, to add. I might have to release the beta with a curtailed set of main loader enhancements just to get something out there.

 

I also added a CAR and BASIC commands. This video shows BASIC XE being used with the new DOS and command processor, all launched straight from the SIDE3 loader:

 

 

 

So is this a new DOS or an adapted version of SDX or am I asking silly questions?  I don't understand...  Though I think using my PC to load up the card will be cool....no matter the DOS...

[flashjazzcat]

1 minute ago, 8bitguy1 said:

So is this a new DOS or an adapted version of SDX or am I asking silly questions?

This is a new DOS, and it uses FAT, so it's totally file-system compatible with your PC, Mac, etc. No ATRs, containers, drivers, etc.

[Beeblebrox]

2 minutes ago, 8bitguy1 said:

So is this a new DOS or an adapted version of SDX or am I asking silly questions?  I don't understand...  Though I think using my PC to load up the card will be cool....no matter the DOS...

@8bitguy1  I found watching the big video Fjc created a few weeks back helps. I watched it a few times. 

[Atari8guy]

9 minutes ago, flashjazzcat said:

This is a new DOS, and it uses FAT, so it's totally file-system compatible with your PC, Mac, etc. No ATRs, containers, drivers, etc.

So this is the thing that will make me break down and finally add a SIDE3 to the collection...  (Not that I need excuses)

[flashjazzcat]

14 minutes ago, 8bitguy1 said:

So this is the thing that will make me break down and finally add a SIDE3 to the collection

There are much loftier and philanthropic, far-reaching motives behind what I'm doing besides driving sales, but hopefully it will, yes.

 

Edited October 18, 2021 by flashjazzcat

[Faicuai]

21 minutes ago, flashjazzcat said:

There are much loftier and philanthropic, far-reaching motives behind what I'm doing

Do I see a mouse-pointer, perhaps, behind that lofty inspiration?

 

If so, sales are already in the bag, though.... ??

[xxl]

A guy doesn't run DOS to load a game... A real man would never admit that he needs a foreplay to get a game to run.

 

over 10 years ago Pajero wrote a DOS that works with the FAT filesystem on the Sio2SD... he was ahead of his time... who remembers that today?

[flashjazzcat]

2 minutes ago, Faicuai said:

Do I see a mouse-pointer, perhaps, behind that lofty inspiration?

Having the file system and shell basically written for the GOS is a nice side-effect, yes, but there is no telling where the DOS itself will end up going. I'm currently adding a MEM.SAV facility and tested it today with TBXL (which usefully exposed a small bug in the short formatted directory's free sector line). I'm also trying to appeal to game developers who 'like the space' (disk space, that is).

 

[flashjazzcat]

1 minute ago, xxl said:

over 10 years ago Pajero wrote a DOS that works with the FAT filesystem on the Sio2SD

What - it ran on the 6502 and handled all the clusters? Or did it use a message passing system and let the AVR do all the heavy lifting?

[xxl]

there are two philosophies - just like with FujiNet vs DragonCart ?
take a moment to consider why the road you think is better runs straight into the wall. Why all such solutions for any platform in the initial design phase just rejected it. How many are there that have succeeded 100%? Zero.

 

The devices that you will be able to operate anyway have functions that you duplicate. One thing you can't avoid - you need additional hardware, so don't be afraid of it, the world is moving forward, don't get attached to one solution  which is also losing momentum...

 

Free advice*:
write a FAT to SDFS translation driver, you already have DOS. an additional advantage - two days after releasing such a driver, nobody will ever install SDFS on physical media again

 

 

This is of course to positively motivate you to work even harder on it and push the gas to the floor.

 

 

* - Just kidding, the 5 units of currency you have there is due.

Edited October 18, 2021 by xxl

[flashjazzcat]

I was poised with a link to the SIO2SD source code (written in C) in case anyone wished to try compiling it for the 6502, but I see now there is no need.

 

Remember I wrote the menu for the Ultimate Cart, so I know how easy it is to make the client/server approach work, and I know it's not for me. Both approaches have pros and cons, and looking at 40 year old computers through a lens of stark practicality is completely baffling to me. Old computers are not about taking the path of least resistance.

Edited October 18, 2021 by flashjazzcat

[_The Doctor__]

so what we have is a stand alone DOS, but SIDEB provides some speed, but could run one whatever device provided said device has the interface for it?

Or a client/appliance where it both?

Or are we a PBI DOS serviced through the keyhole and PBI space/window?

Or cart based like X and we are leveraging the rom slots like u1m/incognito/side?

 

PBI DOS isn't unlike the systems and methods used for MIO/BlackBOX...   so that would be interesting indeed. Many don't realize it's faster than internal ramdisks and their banking methods

Edited October 18, 2021 by _The Doctor__

[flashjazzcat]

There's already a read-only FAT driver in the U1MB/Incognito PBI BIOS, and I always thought it would be very interesting to implement a complete DOS across the PBI.

 

I already compiled a stand-alone, bootable version of this DOS, complete with a boot loader which will bootstrap it, but some severe kludging is necessary to get the Atari OS to cope not only with the 512 byte boot sector, but the fact the space normally occupied by the boot record is full of FAT filesystem data. All foreseeable situations will provide ROM-based booting anyway, though, so it's hardly a big problem.

 

Edited October 18, 2021 by flashjazzcat

[Level42]

Tiny little simple dumb-end-user question:

- will it be possible to delete files from the SD-card through SIDE3 loader menu ?

Edited October 18, 2021 by Level42

[flashjazzcat]

8 minutes ago, Level42 said:

Tiny little simple dumb-end-user question:

- will it be possible to delete files from the SD-card through SIDE3 loader menu ?

Yes. This already works in the pre-release loader, and of course you can do so from the CLI as well (although you're limited to short aliases in that context).

[flashjazzcat]

'MEM.SAV' (though an unsophisticated implementation), works nicely. Everything between MEMLO and MEMTOP is dumped and read back from disk in about 1 second, so you can copy files, etc, without losing your work.

 

 

I'll do a bit of tidying up on the loader next, the sole focus being releasing something fairly soon.