flashjazzcat

I bet it's more responsive than my Galaxy Ace 2 running Samsung's crappy I8160 Jellybean kernel.

EDIT: D'Oh! URL is in the title... . Checking it out now... I like!

Does the counter still work on pictures attached to (and embedded in) posts? All mine report "Downloaded 0 times". Of course, maybe they've all been downloaded 0 times, but I wonder...

Always cut too small and file to size. I learned this the hard way.

I mean when designing the partition table, leave D1 and D2 (for example) clear. You can have D3 as the boot drive and read AUTOEXEC.BAT from that.

Sometimes the XL trim is just screwed on but you're unlucky in that respect and I wouldn't fancy trying to break the glue. Best way to get the bages off is to soften the adhesive by heating with a hair dryer, but I never once managed to remove one without bending it.

No - unmounting will still work. You're probably better off avoiding a couple of drive numbers when partitioning anyway, and using them for serial drives.

Done a lot of rewrites, so a final test version in case I broke something: fdisk4_beta9_011213.zip Changes/Bug Fixes New partition type $03 defined for "external" (FAT) partition entries. Metadata sector number is now stored in the partition entry for type $03, meaning it can be stored elsewhere than immediately before the partition data (which isn't convenient with FAT partitions, or indeed any data outside of the APT). Metadata sectors for external partitions are stored at the beginning or end of the APT, depending on the location of the external partition. For the reason above, external partitions can now be named Global metadata default flag is now stored in the APT. This means you can specify whether you want metadata (i.e. partition name stores) at disk initialisation time, although you can change this preference at any time and also toggle metadata on individual partitions Partition properties now allows you to toggle access flags, etc, in the dialog APT properties allows you to toggle the global metadata flag Checks for (and warnings about) potential data loss on populated partitions owing to partition table edits have been somewhat improved Writing the partition table to disk now no longer issues a media change command (which activates the revised table). Reboot or refresh partition table, or use "Write/activate", described below. New "Write/activate" option added to disk menu. This writes the table to disk and issues a media change so it immediately becomes active. Fill/Divide now allows you to specify a start drive number, as well as partition density and metadata. Thus can a partition table complete with drive numbers be created in a few keystrokes. External partition entries are now integrity-checked against the MBR, and are declared invalid and removed if the MBR partition they refer to no longer exists or has moved "Names" view can now be toggled with Ctrl+N. Device "ID" now has the PBI handler number in the second position. So, "1.0.1" means PBI device, device 0, master disk (slave is 2). The number of APT records as well as the APT revision is now displayed in APT properties The editor will no longer edit an APT with a higher revision number than that for which the editor is specced Instead of crashing, when the RC_GR8.SYS display driver is installed, FDISK will revert to the stock display if there's not enough RAM for the 80 column display (i.e. the user didn't run the editor with the "X" command). Other minor stuff as well which I can't recall. As I say, there have been so many changes that I won't rule out a breakage somewhere, so test out on non-critical media. If you've made external partitions with previous versions of FDISK, this version should update the external entries to the new format the next time you open the APT for editing. However, you may wish to start from scratch for maximum flexibility. Also in the ZIP is a little program called TRACEAPT.COM which I wrote to verify the location of the external metadata sectors. I include it here because it's become quite useful and offers an insight into the geometry of APT. It's very simple, but will probably be turned into a proper integrity test / fix-up type tool at some stage. MOUNT.COM (command line dynamic mounting tool for command line DOSes) is also being rewritten, MATR debugged, and some minor improvements have been made to the PBI drivers, so they'll be getting updates as well soon. In fact, this version of FDISK breaks dynamic APT partition mounting in the current Incognito and U1MB BIOSes, since that functionality in the drivers relied on a small error in the partition records. ATR mounting and such is unaffected. I don't honestly think people are using partition mounting that much anyway...

Kyle: How many 255 byte FAT directory entries do you think you can fit into 48K? Or am I missing something here?

Thanks. I'll check it out.

OT, but I can't seem to get answers through the usual channels: Is there any reliable source code around which I can adapt to make stand-alone PBI ROM flashers for Incognito and U1MB? I realize that depending on the PLCC sector size it may be necessary to read (say) the BIOS menu code and re-flash that as well as the PBI ROM, but nevertheless I think this would be a useful way to perform PBI ROM updates (of which there will be some soon) without having to erase and flash the entire 512KB. I've got (rather rough) code which handles one of the U1MB PLCCs, but with so much bricking going on I'd prefer to use something tried, tested, and safe.

The ROM on the ATR was entirely zeroes. I don't think the choice of flasher was the issue in this particular instance. I completely agree that the flashers need sorting out, however.

I seem to remember compiling this years ago when I was trying to design a RAMdisk handler for DOS 2.5 / MyDOS which wouldn't wipe out reserved memory banks. Not sure if I still have the modded source anyway... if I find it, I'll see if it's of any use.

Missed betting opportunity there.

Yep - just tried loading some other stuff with the X command and screen garbage occasionally appears. Hopefully the garbage won't "stay", however, providing DLT are informed of the issue.

OK - that's good to hear. In that case, a delay loop before any disk activity would be an excellent idea, just to give the stage 2 VBL a chance to tick over a couple of times before DOS sets CRITIC.

EDIT: Larry did some RWTESTs a while ago and posted a result of 45197 for the MIO RAMdisk (reading, using MyDOS), and this is twice as fast as the SDX RAMdisk driver... and this is because the MIO does unbuffered transfers (RAM is mapped at $D600). And this appears to be marginally faster than any DOS can read a 256bps hard disk.

Well, before loading ICET - with TD Line enabled under SDX - $230 (SDLSTL) points to $142C, which is the top of the TD Line Display List (this will vary depending on where in RAM the driver loaded). This display list ends with a JMP to $9C23, which is where the remainder of the OS display list resides. When the problem occurs, after typing "X ICET.XEX", the "X" command first disables the library and moves the screen and display list up in RAM by 8KB. When the garbage is displayed, the SDLSTL points at $BC20 (so the TD line has been disabled), but the end of the DL does a jump/wait to $BC2C, which is the wrong address. So the target of the jump/wait was not properly reset when the TD line was disabled (presumably by changing the DL vector, rather than calling the driver, which would have reset the DL properly). While investigating this, I noticed that Altirra's .dumpdlist command always reports the target address of the Antic jump/wait command rather than the content of SDLSTL if the two differ (which they shouldn't in any case). So - if you're going to shut off the TD Line by directly writing to the display list vector, you also need to trace through the DL (following the Antic JMP instruction, $01) and also amend the target address of the jmp/wait at the end of the OS display list. The fact this issue only happens about half of the time would suggest to me that the stage 2 VBL is resetting the jmp/wait vector when the application is half way through changing SDLSTL. The solution might simply be to do an SEI prior to amending the vectors.

Ice-T. AFAIK, it disables the TD Line under SDX and doesn't re-enable it on exit. There's also a whole lot of screen garbage when loading the program with the TD line on under SDX if the TD line hasn't been turned off before CRITIC gets set during the loading process. This only happens some of the time.

And I suppose some explanatory gloss in the dialog, lest someone tries to set it read/write, can't, and then assumes the drop list is broken.

That's because they're read-only.

I once experienced issues using SDX format, but I use DOS 2 format in this exact way every day without issue.

Still getting an "access denied" error, even with the permissions on the device modified. Starting to think this is Mint being obstinate...

No problem Steve - and thanks for the update! Hmmm... and I think you're still waiting for updated versions of said drivers. That might be the easiest way to proceed. If they were APT drivers, they should work with the new FDISK. Not much about what is actually produced by the partition editor has really changed since the very first version which supported APT - just bug fixes, really, and the addition of external partition support.

Good stuff. I'm currently trying to work out a way of packaging partition names for "external" (i.e. FAT, CP/M) partitions, but I'm uncertain this will warrant another beta. I do want to get the system right before doing a proper release of FDISK. Of course there's already a lot of partitioned media out there, so everything needs to be backwards compatible. Hopefully it won't take long. If you're not using those external FATs, go ahead and use the latest FDISK beta to partition the cards. The worst that will happen is that - if you want to add external partitions later on (for KMK's FAT and CP/M drivers) - a later version of FDISK may create an extra, special partition inside the APT to store partition names. I'll make sure it doesn't break existing APTs. MATR still isn't finished. At the moment, I'm also rewriting the MOUNT utility so it's self-contained and works with any command-line DOS.