flashjazzcat

See here Roy.

Lots of changes and fixes, so yet another test: fdisk4_beta8_171113.zip Changes/Bug Fixes The boot flag is now properly saved to the partition table. In addition, the boot flag (if set) is now cleared if a partition's drive number is removed. This makes sense, because the only the drive number of the boot partition is saved to disk. External (FAT) partition entries now remain correctly positioned following the insertion of regular partition entries. In fact, the whole table is now kept sorted in numerical order by partition start sector. It's no longer possible to insert more than one reference to the same external partition. Split/Divide (now called "Fill/Divide") now correctly adjusts calculated partition sizes to account for partition table records, etc. Therefore when you ask for 128 partitions, you should get 128 and not 127. Re: the above, the maximum number of partitions is now 128 instead of 127. The internal partition records have been completely reorganized, greatly reducing code size and complexity (although the saved space has largely been filled up with new stuff). In any case, the program should now work with the Sparta TD line regardless of whether the cart is present. SDX still requires use of the "X" command if the RC_GR8.SYS display driver is being used. Partition Properties has been augmented to report the state of the "external" flag. Similarly, Disk Properties has been altered to provide more space for the hardware ID string. Partition names do not now auto-clear when you edit them. Editor behaviour has changed again (see below). I've made an attempt to handle Extended Boot Records (EBRs), so although the program won't create logical FAT partitions (only a single primary one, plus the APT), it will register up to sixteen FAT partitions (i.e. three primary plus thirteen extended) if you prepared the disk using a partition editor on the PC. The APT partition entry ($7F) MUST be primary, however, and you should set the media up accordingly if using another utility. Regarding editor behaviour: I considered adding a "cleanup" option to get rid of gaps left between entries in the table, before realising it would be better if gaps were not permitted to exist in the first place. Therefore, with an empty table, you now can't cursor down until you add entries. So, to partition the disk, just press enter, type the partition size, then enter again to close the entry. The cursor will advance to the next line. If you want to insert another entry higher up the list, cursor up and choose "Insert entry". An entry will open up for you and you'll be put straight into edit mode, and the space will just close up again if you change your mind and press Escape. You can still delete standard and external entries alike with "Delete entry". I've been testing this build today on my 1200XL (which has two APT devices attached), using a 4GB CF card with four FATs (one of which is a logical partition) and a single APT. Seems stable so far. I was never able to duplicate issues with drive number selection, and I'm completely confounded by the fact Steve was seeing ASCII zero instead of drive numbers in his selection list. The logic of the program would seem to utterly prohibit such a situation, so I can only assume some code got overwritten. I've moved the drive number look-up table away from buffers just to be safe. Regardless of the fact this is unapologetically partly an exercise in user interface design - and regardless of the fact that a partition editor should generally be a use-once-and-forget-it application - obviously its critical nature means it must be well tested and reliable. When APT was introduced the application was re-written, and then again when we needed external FATs, but by this stage there were a lot of kludges. Removing those and replacing them with predictable, robust code - as well as refining the UI - has hopefully been time well spent. And now - for the bug reports.

If you were in the UK, I could get it sorted for you. Perhaps you could send the machine back to Lotharek? In any case, it's easy to throw one's hands up in despair at times like these (and very understandable), but there's always some way to get things fixed.

You could have the PBI options present even if the device isn't capable of PBI operation. However, if you purchased the device from Lotharek it should be v2 and thus good to go. Perhaps he can verify the provenance of your Ultimate 1MB?

I agree with Phil. Certainly looks to me like the board is not even set up for PBI operation.

FATFS does not support long filenames: it currently converts FAT directory entries into the standard 23 byte records (with 8.3 names) required by SPARTA.SYS. As noted above, SPARTA.SYS is not currently able to handle long filenames, and this precludes any file system driver from doing so for the time being. Note also that FAT LFN encoding (although not decoding) is licensed Microsoft technology.

There's one on here: SDOSUTIL.atr DESEG.COM. Might need to run with the cartridge off to maximize buffer space (it reads the entire file into RAM), but it does work with the Sparta command line.

I wrote one in the mid-nineties which does what you want. I'll dig it out tomorrow - it may be of some use.

Blub. Fortunately it only cost me a few pence of mobile contract and electricity to digest that bit of rationalisation. And yet - oddly - I suddenly heed the urge to be compensated... never thought of charging for electricity used.

Thanks Frankie. I'll try to duplicate the issue.

So - which is it? Note that for my part, I don't adhere to any GPL licence (the content on my website is described as "donationware") - I just rely on people to be fair. While at no point have said "please remove my stuff", I did seek to take issue with the unapologetic retorts when you were pulled up about not seeking permission to distribute software which might still be under active development. All you had to say was "OK - sorry for not checking first - is it OK to leave the stuff in, or do you want it removed?". That would have been the end of it. However, because (as we're frequently reminded) the collection was "a lot of work", my voiced concerns are apparently judged as unreasonable. And by post twelve, you're the wounded party, saying you didn't expect "this kind of behaviour", "grief", etc, etc. You also - after three years - seemed ignorant of the provenance of the software in question. I might be an idealist, but I cannot imagine sticking (for example) Aspeqt, Candle's XEX loader, or a copy of SpartaDOS X on a disk and giving it away - let alone charging for it - without at least making some attempt at contacting the authors first. I even ask Drac030 - for instance - before including one of his utilities on a free-to-download toolkit disk, lest the author takes umbrage at his work showing up unannounced on some other website. Maybe he wouldn't mind, but I don't want to assume that that is the case. Clearly such good manners have fallen out of fashion. Better to act first, then say "But hey - it took me ages to copy this stuff" when challenged. Some people get mildly pissed off in such circumstances. I'm not sure what's so difficult to understand about that. Now that it's out in the open: do what you like as far as I'm concerned. A simple email or PM would have been easier.

Crashing issue was the result of a new "optimisation". Editor window closes and re-opens when the view changes from detail to names. However, the underlying background is no longer cached (to save memory), but I forgot to remove the code which reinstates the background (in this case, from a empty cache) when the view is changed. Fixed now. Boot flag problem confirmed. Steve Carden was having trouble with drive numbers but I couldn't reproduce any issues. He was getting a load of hearts in the drive list, but I've never had a problem. Can you elucidate at all? Just doing general tidying up now and I'll try and nail the remaining issues over the weekend.

Yikes... thanks guys. Will check it out.

Yeah - I read all about the double-indirection a couple of years back and even considered using the idea for a while. I eventually decided it was more trouble than it was worth, however, and that a page allocator with a bitmap would be more efficient. The indirect handles were a source of application errors on the Mac because developers would tend to forget the pointers were indirect. I could imagine them being a bugger to debug... Still, it did seem a nifty solution at the time.

Last one: fdisk4_beta7_141113.zip Anything broken in this gets fixed and then I'll put it on the website, finalised. Bug Fixes / Changes Redesigned property sheets Shortcut keys on top-level menu (you now have to press Escape to get into the top-level menu, but you can open the device selector with one key by pressing Enter). Infinite loop fixed which could occur when entered partition size exceeded available space Bug in Undo fixed Memory footprint reduced Issues with TDLINE in RealDOS fixed FAT16 partitions of less than 32MB are now written out as MBR type $04 "External" FAT partitions: Improved recognition of FAT file system type Still waiting on some info from Steve on a couple of further issues under RealDOS. Thanks to him for testing these builds with his hardware, and thanks also to Ray for his bug reports.

Well, you're wrong on the last assertion because the first thing I did was check through the list before I made my first post. I found half a dozen copies of The Last Word, MrFish's LW font collection, several GUI demos, and various copies of my APT partition editor, FDISK. And I wouldn't claim ownership of any of that original software - I'm asserting it. However, I won't deny that some of this stuff could have originated from sources other than my website. The three year thing is immaterial for the simple reason that it's an invalid counter-argument when offered to someone who is the original author of the content (which is the manner in which the three year factor was originally used). I could put a mandatory surcharge on downloads of original software on my website and then probably sit back and watch as no-one downloaded it. But that's my prerogative because it's my original content - my IP - and I can try and charge for it if I feel that way inclined, which I don't - despite the fact I spend most of my free time creating it and I pay annual hosting fees, maintain dev equipment, etc. That's what the "Donate" button's for. Stephen J Carden emailed me at the weekend asking if he could include FDISK (when it's finished) on his RealDOS toolkit disk. I don't really have a problem with the idea (although I tend to prefer cross-linking to the originating download page because I fret about keeping every site administrator updated on current software revisions - but that's just me). Steve isn't going to make any money out of his toolkit disk, but he thought it courteous to ask anyway. I really appreciated that. I can only echo snicklin's points above. I have nothing against the basic premise of making software widely available to everyone in a convenient way. If there was already a large group of people lobbying for software collections on Blu-Ray disks, and you stepped up and offered the service... well, that's helping the community, I guess. On the other hand, if you spent three years downloading and cataloguing stuff and then suddenly decided to burn everything onto disks and then flog them... well, there's a perceptible difference in intent there. Anyway: it's how you go about things at the end of the day. I wouldn't write off understandable human reactions as "negativity". That said, not everyone asks first before hosting stuff. Such is life.

Correct. And the fact it took three years to "collect" the software is immaterial to the matter at hand. Some of the software took five years to write... so shall I start charging for downloads?

OK: Thanks for that. FDISK wrote out type $06 (FAT16 partition with 65536 or more sectors) and Windows apparently changed it (quite reasonably) to type $04 (FAT16 with less than 65536 sectors). I'll add detection code for type $04 and ensure FDISK writes type $04 if the partition is FAT16 and less than 32MB. First 447 bytes are zero in Sector 0 - Part 1 . The MBR partition table starts at byte 446 ($1BE); the space before this is for PC boot sector code and not applicable here. Anyway: recognizing type $04 is the most important thing to fix, but we might as well write out the correct ID in the first place too.

Nor any of my software...

Original MIO... Hmmmmmm.

Post sector 0 of the card, please, so I can have a look. I need to know the MBR partition ID, and a look at the FAT partition's boot sector would be helpful. Also whether the FAT partition was created by FDISK or with a PC-based utility.

You have VBXE enabled? Turn on interlace.

Another (and hopefully the last) beta: fdisk4_beta6_131113.zip Bug fixes It's no longer possible to proceed to the APT partition editor without specifying the size of the APT segment Number conversion has been completely rewritten and MB view should now be free of rounding errors MB values are now accurate to four decimal places Changes The Split/divide dialogue now has a BPS field so you can specify the density of a group of partitions It's now possible to use fractional MB values in the disk initialisation dialogue Media Properties now has a few additional fields showing the basic disk geometry The Device Selector shows the name of the interface as well as the controller. When using multiple devices, this should help to identify which is which. Validation has been generally strengthened when something destructive is about to happen IDE Plus 2.0 is now correctly identified by name and ROM version number Using multiple devices As previously mentioned, the Device Selector will pick up all APT-compliant devices on the system, regardless of whether they are PBI or soft-driver devices. This means you can individually partition IDE Plus and the SIDE soft-driver, for example, with both present and active. The APT PBI drivers for U1MB, Incognito, and IDEa and the soft-drivers for SIDE and MyIDE all report back a hardware ID string. IDE Plus 2.0 doesn't (yet); detection of that interface is therefore based on magic bytes. I'll assume the view bug Roy reported doesn't exist since my enquiries in that department reached an abrupt dead-end.

Wow... superb work. Just watched the video but will run it on real hardware tomorrow. Some really stunning effects!