Jump to content
tmp

AVGCART

Recommended Posts

just a quick reply, i'm sure the more knowledgeable ones will give you better answers

 

first of all, SIDE emulation without having U1MB has probably limited use and shift-s mode is basically useless in this situation (same as going into side mode on power-on using button)

 

1. no

2. could be a bug, i need to test it on non-u1mb machine, this functionality was just lightly tested

3. afaik fatfs.sys doesn't support fat32 so you'd need to have at least fat16 partition to be able to see any files from sdx, not sure whether APT is needed

4. this was never tested, if anyone can confirm that CAR should run side loader, i can take a look into it

5. i leave that to fjc to answer, i have no information about that functionality so i'm not sure whether it can be used on avgcart in any way

Share this post


Link to post
Share on other sites
4 hours ago, NuY said:

3. Is having the SIDE driver active in SDX all that is required to see the SD card?

You need to initialise the card using FDISK, and this means also building FAT partitions from the ground up. The Atari only sees partitions defined inside the 'APT', and you create these partitions using FDISK. To get FAT16 partitions to show up via FATFS.SYS, you need to create 'external' APT entries (links to MBR FAT partitions). This process is described in the APT Toolkit manual.

4 hours ago, NuY said:

4. How does one access the SIDE loader from SDX? There only appears to be side.sys related on CAR:, and typing CAR at the prompt locks up the screen

CAR runs the SIDE Loader from the SDX prompt on a real SIDE cartridge. I didn't yet test this on the AVG cart, but I guess it would be desired behaviour.

4 hours ago, NuY said:

5. Similarly, how does one access the OSS carts that are referred to on the download page for AVG SIDE roms?

Have a look at the README file in the ZIP file containing the regular SIDE loader ROMs. I must admit I never gave a thought to whether anyone would want or need to use the patched OSS ROMs with the AVG cart (which can anyway fully emulate OSS language carts), nor whether it would work. If the AVG's SIDE emulation perfectly emulates SIDE2 behaviour, I guess it would work.

 

I've been testing some beta AVG firmware here, but with very limited time to spare. I'll try to test some more unusual usage scenarios tomorrow. :)

Share this post


Link to post
Share on other sites
4 hours ago, tmp said:

just a quick reply, i'm sure the more knowledgeable ones will give you better answers

 

first of all, SIDE emulation without having U1MB has probably limited use and shift-s mode is basically useless in this situation (same as going into side mode on power-on using button)

 

1. no

2. could be a bug, i need to test it on non-u1mb machine, this functionality was just lightly tested

3. afaik fatfs.sys doesn't support fat32 so you'd need to have at least fat16 partition to be able to see any files from sdx, not sure whether APT is needed

4. this was never tested, if anyone can confirm that CAR should run side loader, i can take a look into it

5. i leave that to fjc to answer, i have no information about that functionality so i'm not sure whether it can be used on avgcart in any way

Thanks tmp, I wasn't sure if Shift-S was required or not - given FJC's reply above obviously not :) A use case - possibly as a way to run a Basic program or the PDC (?) audio player without having to reboot?

11 minutes ago, flashjazzcat said:

You need to initialise the card using FDISK, and this means also building FAT partitions from the ground up. The Atari only sees partitions defined inside the 'APT', and you create these partitions using FDISK. To get FAT16 partitions to show up via FATFS.SYS, you need to create 'external' APT entries (links to MBR FAT partitions). This process is described in the APT Toolkit manual.

CAR runs the SIDE Loader from the SDX prompt on a real SIDE cartridge. I didn't yet test this on the AVG cart, but I guess it would be desired behaviour.

Have a look at the README file in the ZIP file containing the regular SIDE loader ROMs. I must admit I never gave a thought to whether anyone would want or need to use the patched OSS ROMs with the AVG cart (which can anyway fully emulate OSS language carts), nor whether it would work. If the AVG's SIDE emulation perfectly emulates SIDE2 behaviour, I guess it would work.

 

I've been testing some beta AVG firmware here, but with very limited time to spare. I'll try to test some more unusual usage scenarios tomorrow. :)

Thanks FJC, if I'm honest I've always wondered what the benefits of mass storage access would be on an A8 given that SIO2X devices are all capable of reading huge ATR files, but the examples given with the audio player do intrigue me and am keen to try them out! I'll try and dig up an unused SD card  and prep from scratch, appreciate the advice on that score. For me, I think the benefits to having a dual formatted card would be the ability to use a single card for regular A8 usage (ie. my beloved type in programs/TLW etc.) and of course the features of AVG, primarily hosting cart files.

 

With the above in mind then, it's possible I may have misunderstood the OSS cart functionality of a real SIDE. My desired use case would be akin to having a real SDX cart with an OSS cart piggybacked on it, so one can save directly to the SDX drives (whichever format) from say MAC65. As my intSDX refuses to play nice with AVG, currently I have to boot from a disk/ATR with ye olde Spartados on it (X32G.SYS iirc) with my real MAC65 cart attached. Given this, am I correct in assuming that a real SIDE cart can only be SDX OR SIDE OR OSS cart? And not a combo of SDX AND OSSS cart?

 

I did run the SIDE config utility after running the SIDE CAR file from AVG UI, but after choosing 6 (I think) for MAC65 and then selecting reboot, the Atari just reset and booted from D1: as usual (or to BASIC prompt with no disk in D1). Running the SIDE CAR  from AVG UI after further reset just brought up the regular SIDE loader menu.

 

Sorry for the bombardment of text, hopefully it all makes sense, and thanks again to tmp and yourself for these tools.

Share this post


Link to post
Share on other sites

Just re-read my last post and it could be clearer, so here goes:

 

Current workflow

Plug in MAC65 cart (OR AVG cart and select regular MAC65 car file)

Boot from Spartados floppy with X32G.SYS

 

Desired workflow

Plug in AVG cart and select "SDX with SIDE support and OSS" car file (assuming M65 is set active)

Get to SDX prompt

Type CAR to get to MAC65

Assemble to my SD card

Type DOS to get back to SDX prompt

 

Hopefully that makes better sense.

 

/ramble

Share this post


Link to post
Share on other sites
4 minutes ago, NuY said:

Thanks FJC, if I'm honest I've always wondered what the benefits of mass storage access would be on an A8 given that SIO2X devices are all capable of reading huge ATR files

The IDE mass storage devices are still around four to five times faster than the fastest possible SIO devices, and none of the serial devices I'm aware of allow for the creation of a partitioned hard disk. I've kind of got used to partitions and 60KB/s read speeds now.

 

As for sharing a card between AVG's 'native' mode and SIDE mode: that should be no problem at all. I've observed that AVG's loader ignores everything but the first FAT partition on the card, so even if there were any contention between sharing the FAT between both loaders (not that there should be), you could just create one or more extra FATs for the SIDE loader, FATFS.SYS, etc. AVG's menu also won't interfere with the APT container on the disk.

8 minutes ago, NuY said:

My desired use case would be akin to having a real SDX cart with an OSS cart piggybacked on it, so one can save directly to the SDX drives (whichever format) from say MAC65.

This is exactly how the OSS ROMs work on a real SIDE cart. All four carts are present; you simply select one, it appears as an external cart, and it stays that way until you change the selection or revert to the SIDE loader (which occupies the first 32K 'external' cart slot). No need to go through any boot menus or anything at all when powering on the machine.

10 minutes ago, NuY said:

Given this, am I correct in assuming that a real SIDE cart can only be SDX OR SIDE OR OSS cart? And not a combo of SDX AND OSSS cart?

The OSS ROMs work stand-alone (i.e. with the SIDE cart in 'Loader' mode, so SDX doesn't boot, and some other DOS in use), with SDX enabled (so SDX boots from the SIDE cart and typing 'CAR' starts the chosen OSS ROM), or in conjunction with Ultimate 1MB's PBI BIOS; again - with or without SDX enabled. Apart from any side-effects of the patched banking mechanism, the OSS ROMs behave 100 per cent as a real cartridge, either plugged directly into the Atari or in the pass-thru cart port of SDX.

 

So: let's say you have SIDE and no Ultimate 1MB in the machine. You run the loader, run the configuration tool, and choose an OSS cart. From that point on, if you boot SIDE in 'SDX' mode, you type 'CAR' to start the OSS cart. If you boot the cart in 'Loader' mode (switch 'up'), the machine immediately boots the chosen OSS cart (after first booting any disk-based DOS, if present).

 

I don't know how the innards of the AVG firmware operate, but if the external cartridge space comprises thirty-two 8K banks selected via $00-$1F written to $D5E4, and boots with this register set to $00, then the OSS ROMs should work. Some study of the original SIDE cart's behaviour may be required to get things 100 per cent correct; for example, management of the SDX banks (accessed via $D5E1) when the external cart is accessed via 'CAR', and likewise the other way on when SDX is recalled by jumping through DOSVEC ($0A). As I say: I'll be more help to tmp when I've had time to hit AVG with some esoteric test scenarios. :)

Share this post


Link to post
Share on other sites
Just now, NuY said:

Plug in AVG cart and select "SDX with SIDE support and OSS" car file (assuming M65 is set active)

Get to SDX prompt

Type CAR to get to MAC65

Assemble to my SD card

Type DOS to get back to SDX prompt

Yes... I didn't mention the HDD side of things in my previous answer. :) That should all work perfectly well, too.

Share this post


Link to post
Share on other sites

Of course, I forgot one salient point in all this. The real SIDE cart stores the OSS base bank in its battery-backed NVRAM, which the AVG does not have. The SIDE loader obtains the base bank from NVRAM on every OS boot, so on reflection I think the OSS ROMs are a non-starter with the AVG cart. Sorry!

 

EDIT: I've removed any mention of the patched OSS ROMs from the AVG download page to avoid any further confusion. ;)

Edited by flashjazzcat

Share this post


Link to post
Share on other sites
1 minute ago, flashjazzcat said:

Of course, I forgot one salient point in all this. The real SIDE cart stores the OSS base bank in its battery-backed NVRAM, which the AVG does not have. The SIDE loader obtains the base bank from NVRAM on every OS boot, so on reflection I think the OSS ROMs are a non-starter with the AVG cart. Sorry!

Heh, I was just in the middle of typing a reply to the effect of "How does AVG remember which OSS cart selected when booting from two different CAR files"!

 

Your reply makes perfect sense in the context of a real SIDE cart of course. I had wondered if somehow a writeback to the CAR file was occurring behind the scenes when running the SIDE config utility.

 

In that case then, as AVG (afaik) has no concept of passthrough carts (currently ;)) would the following idea work? Take your existing "SDX with SIDE support" car file and bake in one OSS language? Or indeed, any language cart (MS Basic, TBXL...?), such that the end result would be the ability to boot from say "SDX with SIDE support and M65 built in" and get to M65 by typing CAR.

 

I'm not averse to having several SDX car files, each with a different language on - maybe there could be an ability to "roll-your-own" SDX SIDE language car file?

 

Just thinking off the top of my head here.

 

On a completely unrelated note, is there possibility of including the SDX MAN pages on the car files for future releases? I appreciate having the online help files when I'm fiddling with commands I have no clue how to use :)

 

Thanks again, and I hope I'm providing you with more esoteric ideas ;) Absolutely no rush on my side, appreciate the support you've always given.

  • Like 1

Share this post


Link to post
Share on other sites
5 minutes ago, NuY said:

Take your existing "SDX with SIDE support" car file and bake in one OSS language? Or indeed, any language cart (MS Basic, TBXL...?), such that the end result would be the ability to boot from say "SDX with SIDE support and M65 built in" and get to M65 by typing CAR.

 

Yep: this was how it was originally going to work anyway until I hit upon a way of hosting multiple ROMs on the external cart space and having the loader silently bank them in. You could simply take the OSS-equipped ROM and replace the loader ($40000-$47FFF) with one of the subsequent 32K blocks of data (i.e. one of the OSS ROMs).

 

EDIT: regarding MAN pages: yes - but you can add them yourself using the SDX Imaging Tool if you want in the meantime. I figured that since SIDE is primarily focused on running a hard disk, you could just make a folder on the HDD and put the MAN files there.

Edited by flashjazzcat
  • Like 1

Share this post


Link to post
Share on other sites
5 minutes ago, flashjazzcat said:

Yep: this was how it was originally going to work anyway until I hit upon a way of hosting multiple ROMs on the external cart space and having the loader silently bank them in. You could simply take the OSS-equipped ROM and replace the loader ($40000-$47FFF) with one of the subsequent 32K blocks of data (i.e. one of the OSS ROMs).

Aha, brilliant! I suppose this takes us back to my original question 4 then, around getting to the SIDE loader from SDX prompt (by typing CAR). I'll await the results of tmp's testing on that one.

 

I've never done anything with regard to manipulating cartridge images - do you have any recommendations on software to use to move the blocks of data around in the image file? (Windows or A8)

Share this post


Link to post
Share on other sites
10 minutes ago, NuY said:

I've never done anything with regard to manipulating cartridge images - do you have any recommendations on software to use to move the blocks of data around in the image file? (Windows or A8)

HxD does everything I need. Also handles file comparison, low-level disk access, disk images... the lot.

  • Like 2

Share this post


Link to post
Share on other sites

can anyone give me altirra debugger command that logs $d5xx accesses? i don't feel like reading help tonight ;-)

Share this post


Link to post
Share on other sites
4 hours ago, flashjazzcat said:

Yep: this was how it was originally going to work anyway until I hit upon a way of hosting multiple ROMs on the external cart space and having the loader silently bank them in. You could simply take the OSS-equipped ROM and replace the loader ($40000-$47FFF) with one of the subsequent 32K blocks of data (i.e. one of the OSS ROMs).

that's actually a good idea because it doesn't require me to do anything (except for fixing CAR command), i always like those ;-)

 

https://youtu.be/JgBbXj4Ei78

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

So just some quick updates on my latest shenanigans (hopefully tmp and FJC will like some of these tinkerings):

 

1. I bought a 64gb SDXC card because it was cheap, and am pleased to report it works fine in AVGCart (with caveats, noted below)

2. You probably already knew this FJC, but FDISK that is on the SDXSIDE car image recognises said card and its capacity correctly (something like 60992MB)

3. After updating the AVGCart with a test firmware from tmp, running CAR from SDXSIDE car image works correctly, and launches SIDE loader

 

Re the 64gb card, it's a Sandisk UHS-I Class 10 SDXC card (full size, not micro). Had some interesting behaviour from AVG on first using it. I didn't bother with any initialisation on the card before it went in AVG, so on booting, I got the usual grey AVG screen with "reading directory" message, which hung the machine, and pressing Reset just brought up the same thing again. I then powered off the Atari and slotted in my existing working SD card, powered up, and just got a black screen. Power cycle and same result. 64gb card in AVG, same result. I was quite concerned I'd blown something up, so disconnected AVG and booted up Atari fine. AVGCart back in and power up with old SD card in, and black screen again; but on pressing Reset the SD directory comes up. Power cycled again, and behaviour repeated - Boot to black screen, press Reset and directory appears. I can't explain that one :)

 

Moving on, after (eventually) finding a utility to format FAT32 under Windows > 32gb, I copied the contents of my old SD card to the new 64gb one, slotted it in AVG and Atari booted first time into the cart menu. A few test car files and fiddling with SDX seem to work okay.

 

Got some current logistical challenges on prepping the SD card for use with SDXSIDE as AVG doesn't (yet) have two SD card sockets... :)

Share this post


Link to post
Share on other sites

that 64gb card could've been formatted with exfat which is not supported

 

as for the black screen, could be a bad contact, maybe a psu issue (less likely)

Share this post


Link to post
Share on other sites
15 hours ago, NuY said:

You probably already knew this FJC, but FDISK that is on the SDXSIDE car image recognises said card and its capacity correctly (something like 60992MB)

Yes: fixed-point math in FDISK is only 32-bits wide, and errors are introduced when the higher-order bytes are used to describe the capacity of bigger cards. I have a complete re-write in the pipeline but am struggling to find the time to work on it.

 

As for two slots: there should be no problem sharing the same card between both modes of operation once everything is set up correctly.

Share this post


Link to post
Share on other sites
6 hours ago, flashjazzcat said:

Yes: fixed-point math in FDISK is only 32-bits wide, and errors are introduced when the higher-order bytes are used to describe the capacity of bigger cards. I have a complete re-write in the pipeline but am struggling to find the time to work on it.

 

As for two slots: there should be no problem sharing the same card between both modes of operation once everything is set up correctly.

Aye, using diskpart on Windows reports it as being 59gb, but that's rounding off of course, not to mention that these days 1gb is 1000mb rather than 1024mb (don't get me started :))

 

The set up is what I'm having some issues with. I'm running Windows 7 so I've been through a painful day or so trying to find ways of using more than one partition useable by Windows, and failed. Until such time I upgrade to W10 I decided on having the card set up with a 4gb (4095mb) FAT16 partition and the same for APT for OCD reasons (!). The current issues I'm having revolve around AVG not refreshing the card slot after boot, meaning I have to manipulate the card in Windows to have a FAT partition on to which I can slap the SDX car file on, so that I can boot to SDX and repartition on the Atari. This necessitates creating a FAT partition through FDISK of course.

 

The current issue is that when using FDISK from the SDX car file, there's some strange behaviour when entering digits in the size fields. Even with auto-fill deselected the behaviour persists. Steps to replicate:

 

- Open FDISK, select initialise from menu, confirm warnings about MBR being destroyed, this brings us to the partition screen

- Tab to auto fill box and deselect with space

- Tab to FAT size field, type in any number above 3560, press tab again

- FAT size field reverts back to the full size of the card (in this case 60904)

- Type any number above 3560 in APT field and press tab, APT field reverts back to full size of card

 

Interestingly, if I enter 8192 in both fields or numbers above this (I haven't tried all numbers ;)) the fields both stay as they should be. Naturally to work around this I can use numbers below 2000 or so (certain other combinations of numbers in the two fields seem to behave similarly to the above description). The preference would be to have the FAT16 partition as large as possible however, as I tend to use the old card as a scratch disk for non-Atari related stuff.

 

Edit: FDISK version is 4.67

Edited by NuY

Share this post


Link to post
Share on other sites
8 minutes ago, NuY said:

Steps to replicate

Yes: I've replicated this previously and it's most irritating. It's a direct result (I think) of the aforementioned problem with large capacity cards. I did an amazing '640K is enough' move when designing the fixed point arithmetic and this causes the issue you're observing.

 

Share this post


Link to post
Share on other sites

Channeling your inner Bill G eh!

 

It's interesting that it only happens for a certain total range. I fiddled with the numbers in both fields again, and in short, entering numbers above 8192 in both works fine.

 

As a potential workaround, if I create both partitions at 8192mb and then resize the FAT partition using Windows to 4095mb, would the APT partition still be visible, in theory? I recall reading in one of your posts or possibly in the userguide that messing with partitions after the APT one could destroy data, but I don't know if FAT and APT have to be contiguous.

 

While I have the user guide open, could you clarify something on the FAT access side of things? On page 16 referring to ATRMOUNT, the guide states that this command is designed for U1MB, and goes on to say that IDEPlus users should use their proprietary tools to mount ATRs. My question is if ATRMOUNT would work under SDXSIDE (good name eh) if an ATR was copied to an SDFS partition?

 

Lastly and unrelated, going back several posts ago when we were discussing the OSS carts embeded in the SDX image, you mentioned the inability to save config for SIDEloader due to their being no NVRAM to save it to. As a suggestion/feature request, would it be possible for SIDELoader/SIDEcfg to save its configuration to a file directly on the SD card? The theory being that the program would try to read NVRAM first (succeeding on a real SIDE cart, failing on an AVG cart), and as a fallback, look for a file on the FAT partition of the card, say in the root?

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, NuY said:

It's interesting that it only happens for a certain total range. I fiddled with the numbers in both fields again, and in short, entering numbers above 8192 in both works fine.

Yes: it seemed to me that avoiding certain whole multiples avoided the issue. Something like: 8193 worked while 8192 did not. I'm exactly sure what the problem is but I'm unhappy with the whole way of expressing volume sizes as fractional MB values. I'm thinking of doing away with the fixed point representation entirely and just using the lowest unit which accurately expresses the volume size, and simply rounding things up when precision doesn't matter (much as the SIDE loader does when you elect to display file sizes).

1 hour ago, NuY said:

As a potential workaround, if I create both partitions at 8192mb and then resize the FAT partition using Windows to 4095mb, would the APT partition still be visible, in theory? I recall reading in one of your posts or possibly in the userguide that messing with partitions after the APT one could destroy data, but I don't know if FAT and APT have to be contiguous.

As long as Windows doesn't blindly delete any unrecognised MBR partition table entries, it should be OK. I've resized multiple FAT partitions using the Windows 10 Disk Management Console without disturbing the APT, IIRC.

1 hour ago, NuY said:

My question is if ATRMOUNT would work under SDXSIDE (good name eh) if an ATR was copied to an SDFS partition?

Good name, but I'm not sure what it represents. Do you mean the SIDE.SYS driver which handles HDD access under SpartaDOS X when no Ultimate 1MB is present? In which case: it's SIDE.SYS. That driver is completely incapable of handling ATR disk images, despite the fact I developed the ATR mounting code using a huge version of that driver back in 2011 or so.

1 hour ago, NuY said:

As a suggestion/feature request, would it be possible for SIDELoader/SIDEcfg to save its configuration to a file directly on the SD card? The theory being that the program would try to read NVRAM first (succeeding on a real SIDE cart, failing on an AVG cart), and as a fallback, look for a file on the FAT partition of the card, say in the root?

This would be great if a) there was room left in the 16K SIDE ROM for additional code, and b) if the loader was capable of writing to FAT volumes (which would require more code... see point 'a'). Of course the SIDE cartridge and the AVG SIDE ROM have virtually unlimited code space (256KB, or 32K if dividing the ROM into segments to handle the OSS carts), but this would require a separate branch of the stand-alone SIDE loader (for SIDE and AVG), since such code expansion is not really possible in the U1MB and Incognito versions of the loader. While AVG's SIDE emulation mode is most welcome (indeed, I suggested it in the first place, although primarily with U1MB integration in mind), I don't really want to plough resources into developing a special branch of the SIDE loader for AVG, when AVG's built-in loader can (or should) be able to do everything the user needs when the device is used stand-alone for launching XEXs and ROMs.

 

That is not to say that being able write to the FAT wouldn't be a useful feature in loader builds targeting 'native' platforms (one could create new, blank ATRs, etc), but if I could perform such feats when running on the AVG cart, I'd want to perform them on the U1MB and Incognito as well. I may well find a way of utilising 'padding' space in the ROMs of those two devices in the future, and thus open up an extra 4KB of code for the loader for features which could be implemented across all targets (U1MB, Incognito, SIDE, SIDE2, 1088XEL/XLD, and AVG) without having to maintain different branches of the loader. Right now, all targets are compiled from the same source code with very little variation between them (although conditional assembly is complex enough and has already accounted for a couple of recent bugs). If things become much more complex than that, I fear they will get completely out of hand. :)

 

Main priority at the moment (aside from getting the latest U1MB/Incognito maintenance update released) is to fix up these FDISK flaws. That's going to require a week or so of leisurely coding and testing time... LOL. :)

 

Edited by flashjazzcat
  • Like 1

Share this post


Link to post
Share on other sites
19 minutes ago, flashjazzcat said:

<snip> (I can't get multiquote to work :P)

Fractional MB: Yes, I agree certainly for the initialisation screen - the rarity of removeable storage with capacity under 1GB must be vanishingly rare these days; integer MB displays would certainly sufficient for me. Until such time SDFS can handle > 32MB, fractional display is probably better in that context.

 

Resizing partitions: Thanks, I'll give that a try then :)

 

Name: I was bored of typing out "SDX cartridge image with SIDE support" to refer to the image :D

 

The fact SIDELoader has no capability of writing to disk completely escaped me to be honest :) I agree all functionality should be available across all platforms that are supported by SIDELoader notwithstanding U1MB or lack thereof. From my perspective, the IDE emulation is more important than the loader, but the loader is an extension of AVG, if you like. There will be times when XEXs don't work in AVG and vice versa, so having the best of both worlds is a definite advantage. There's the audio streamer as well, of course (which name escapes for the minute..) From a wider perspective, I guess it also means tmp doesn't have to reinvent the wheel for support for a certain feature, if it is already present in SIDE or its loader.

 

FDISK: Ultimately I guess you will want to squash the bug we discussed, but as a temporary measure, how about disabling the sanity checking during parsing of the size fields, and checking the total of both fields doesn't exceed the device capacity at the point of pressing Return? Not sure if the maths for this would still be the same as you're using currently ;) In addition, a minor suggestion: If one selects FAT16 as the type, there shouldn't be any need to have this larger than 4095MB in the sizing options, as FAT16 can't be any higher than 4GB anyway.

 

If you need any FDISK testing, let me know - I'll probably be fiddling with this SD card for a couple of weeks yet anyway :)

Share this post


Link to post
Share on other sites
20 hours ago, flashjazzcat said:

a) there was room left in the 16K SIDE ROM for additional code, and b) if the loader was capable of writing to FAT volumes (which would require more code... see point 'a').

Perhaps you could have the user supply an empty file on the FAT file system. After that, if you restrain your configuration size to at most one cluster (or perhaps even one sector), you know where it is located on the disk and it'll be sequential, i.e. no need to modify the FAT if you stay withing the boundaries. That'll severely reduce the size of your write FAT FS code, because it can only write to that particular file that is already there. It cannot create files and write larger files (and manipulate the FAT an directory sectors) but that's not needed.

 

Just my €0.02

 

Edited by ivop
typo

Share this post


Link to post
Share on other sites
10 minutes ago, ivop said:

Perhaps you could have the user supply an empty file on the FAT file system. After that, if you restrain your configuration size to at most one cluster (or perhaps even one sector), you know where it is located on the disk and it'll be sequential, i.e. no need to modify the FAT if you stay withing the boundaries. That'll severely reduce the size of your write FAT FS code, because it can only write to that particular file that is already there. It cannot create files and write larger files (and manipulate the FAT an directory sectors) but that's not needed.

Yes: somewhere along the line I had considered that. It's a good idea. Unfortunately even three extra 6502 instructions will overflow the available space on the 1088XEL/XLD builds of the loader, so if I'm going to go for any extra features at all, I might as well grab at least 4K of unused space and enable new file creation as well (which would make the built-in CIO FMS so much more useful too).

  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...