flashjazzcat

Just stumbled across this one: mva #0 Ds1[0].ReturnCode This puts $00 into the proper element of struct Ds1. mva #0 Ds1 [0].ReturnCode However, the second example (note space between struct name and array index) always stores $00 in the first byte of the struct.

Judging by the video you sent, this works as designed. Selecting View->Show Megabytes toggles the display between sectors and megabytes, and View->Show Names toggles the display between standard view and a view where all the partition names are listed in the main window, with the details appearing where the partition names would normally be. When active, both views are marked with a symbol next to them in the menu. I noticed a couple of your posts over at AtariMax. The geometry options provided by MyBIOS certainly seem rather inflexible. However, providing the MBR on the card has an APT (type $7F) entry in it, the APT drivers and tools should happily work with it, ignoring the proprietary MyIDE partitioned area (I have no idea of the design ethos behind that, BTW: I assume that like APT it's some kind of container... it would have been easier if they'd gone with the pre-existing APT design instead of incompatible partition table standard number 1,438... hence the need for the "middle man". ). Similarly, the shared FAT area should be usable with the APT tools. I guess the proof will be in the pudding, so to speak. I'm not personally geared up for testing this combo, but I'll fix anything that's broke within reason. The only way to get an APT onto the card using FDISK is to prepare the media from the ground up using that application: it's not possible to just "drop" an APT into an existing partition structure. However, there's nothing stopping you doing so with a Windows-based partition editor or similar. FDISK should then pick up the APT entry in the existing disk structure and allow you to partition the space. Regarding U1MB: while it provides full PBI HDD support for SIDE 2, it's not possible to do so for MyIDE because its IDE registers clash with U1MB's RAM. However, you can still use MyIDE with MyBIOS - flashed to the U1MB - or with the SDX soft-driver. SIDE2 is definitely the more compatible option when it comes to hard disks, though. ... I've had a look at rounding errors and the "MB View" number representation in FDISK, and have completely rewritten the conversion routines. The off-by-one errors were confounding and frustrating, but have been eliminated. Doing accurate pseudo-floating-point representation (and conversion from ASCII fractional MB back to sector values) of 32-bit numbers without an FP library isn't the easiest thing... Decimal places in MB view have been extended from 2 to 4; 2 being inaccurate when dealing with 65,535 sector partitions, and introducing a lot of unintentional rounding up and down. MB view is now sector-accurate: Thus if you edit a partition in MB view, it will not surprise you by changing size to the nearest 50 sector value... Split/Divide (must be a name for that with less redundancy) also gets a BPS field, as suggested by Steve:

Yep - it's buggy as hell, as I've said. Haven't done anything with it in months. In the absence of another tool for the job, don't use it until I've fixed it.

The SIDE loader doesn't bother the PBI ROM (for which read "SIDE Hardware") when loading XEX files, therefore the SIDE Hardware doesn't need to be enabled when loading XEXs. ATRs are another matter: the SIDE loader asks the PBI ROM to register the ATR as a mounted disk image. If the PBI can't do this for any reason (say - it can't recognize the FAT), it will return an error message - usually causing the SIDE loader to report "Cannot find FAT32 partition". So it seems to me we need to focus on the formatting of your CF cards. The latest PBI ROM versions should handle a variety of disk layouts, with or without MBR partition tables. However - I'll try to do some testing in case something was missed. It appears your cards just have FAT boot sectors and thus a single partition covering the entire media. This should work fine. However, something's clearly not quite right. If you have the time/inclination, try using Gparted or some third-party partitioning application to put a couple of FAT partitions onto one of your cards. This will force an MBR partition table to be written to sector 0. See if this helps any. Alternatively, use FDISK 4 (see the APT Partitioning Tools topic) to put a FAT and an APT on the card. This - again - will force an MBR to be written to the card. You can then format the FAT partition using your PC. However - as said above - you ought to be able to use a plain formatted CF card straight out of the shop, so if there's a problem there we need to get to the bottom of it.

I can't see the base code being any more than 64KB.

That's why pre-emptive multitasking is only a realistic proposition if the software is written with the context switching in mind: i.e. keeping everything inside the banking window to avoid unnecessary copying. As for virtual memory: without a page fault facility, obviously the mechanism can't be transparent. A sensible method would (will) be to substitute hard disk for extended RAM when performing an explicit request for a chunk of extended RAM. If the calling program code is in the banked region, it follows that some kind of indirect method of fetching extended memory will be needed, so that's an ideal time to delegate requests to virtual memory. It's also worth mentioning that in light of the profusion of hard disk devices for the A8 in recent years, Drac030 has written a virtual memory library for SpartaDOS X, and IIRC it's already (optionally) used in some of the SDX toolkit applications. The above notwithstanding, 1MB RAM expansions are just as ubiquitous as hard disks nowadays...

1.327 per cent bigger than it is now.

What does the initialization dialog report the overall disk size as at the top, in MB? This kind of scheme works on a smaller scale, utilising the full space on the disk, as shown below:

Urgh... video was made before there was any software (FDISK) capable of creating these kinds of FAT entries, so I guess I need to make a new video. And write an updated manual... ah, the joys. Do you want to use the FATFS driver as shown in the video? If so, fire up FDISK 4, go to "Initialize disk", create a 31MB FAT16 and an APT of any size you like. Then, in the APT editor which appears next, choose Partition->Make External, and choose the FAT16 partition you created earlier. Give the external partition a drive letter. Now, take the CF card, put it in the PC, and format it FAT16, 4 or 8KB clusters. Now copy some Atari files onto it. Then put it back in the A8, fire up SDX, and install the FATFS driver. You should be able to do a "DIR" on the FAT16 partition.

Do... and watch the video as well.

SDX can't read FAT without a driver. We have FATFS.SYS, which can read a FAT16 partition of up to 32MB. But you need to set that up as I've described umpteen times and made a tutorial video about. Without that FATFS driver and that FAT16 partition of just the right size, set up just the right way, Atari DOS (SDX, or any other) can only see partitions in the APT, and the XEX loader can see your ATRs/XEXs in the FAT area.

People have lives - they do what they can in the time available. Try to enjoy what's there, and appreciate what's been done.

If you're really interested in the details, read this: http://drac030.krap.pl/APT_spec.pdf In short, APT is a partition table design for the A8. MBR (a partition table design often used on the PC) was deemed unsuitable for the A8 for several reasons, so APT was born. It provides for a "protective" MBR so that your PC OS won't obliterate your Atari partitions, and facilitates (recently) "external" links to FAT partitions on the same media. Thus can FAT data be accessed in a controlled way (via drivers and software) on the A8, while also remaining accessible by your PC. APT is also the container for conventional A8 hard disk partitions (generally those formatted in a file system your PC can't access directly).

I think you quite neatly answer your own question there. Be grateful there are folks who are capable of at least starting projects. I'm curious to know, though, when you would consider the Dragoncart project "finished". Is ethernet on the A8 leaving you feeling robbed somehow?

Explain? I don't see what's not working there. You get a check mark next to "Show Megabytes" when MB view is active, and a check mark next to "View Names" when names view is active... Erm... FAT MB size is the size of the FAT in megabytes. Meanwhile, APT MB size is the size of the APT in megabytes. So if you want a 2GB FAT, type 2048 in the FAT MB box and so on.

That's correct. No PBI driver found because it's turned off. Sounds like there's no loader in the U1MB ROM? Never have the SIDE cart's switch in the down position if you're using it with U1MB. U1MB has its own SpartaDOS X, it's own loader, it's own hard disk driver. SIDE switch should be in the upper (loader) position at all times. Put it there and leave it that way. Turn SIDE hardware on, with switch, in the U1MB BIOS and leave it that way. Whether SDX is enabled or not in the U1MB BIOS is up to you. This is the configuration you're trying to get working. If you're pressing "L" in the U1MB BIOS screen and the loader is coming up, that's a start. If it's saying "FAT32 partition not found", then maybe there is a problem with the MBR on the card. If you're just trying to get ATRs mounted, forget about FDISK, APT and SDX partitions for a moment. Just get a nice FAT32 partition on the disk (do that using your PC), put some ATRs on it, and keep going with the known configuration I described above.

Software bug: not telling the user he's forgotten (or did he really "forget"?) to define the size of the APT. Human bug: not putting an APT on the disk. D'Oh! Will fix later.

Don't use the loader on the cart. Use the loader in U1MB. When SIDE hardware is enabled in the U1MB BIOS, SIDE cart is IDE registers and nothing else. Are you sure you have the loader-equipped U1MB ROM?

Steve Carden has been kind enough to offer to give FDISK 4 a good workout this weekend, so this seemed a good time to address a few bugs. Firstly the new build: fdisk4_beta5_091113.zip Changes/Bug Fixes Erasing all partitions or doing a split/divide now properly resets the window view. Previously, the selection bar could be left stranded if it wasn't at the top of the partition list, causing the program to become unresponsive. Some problems with garbage appearing following bounds-corrected partition size entries have been addressed. The program now won't allow you to create a new partition entry if there isn't a minimal amount of free space left. Split/divide has been revised with better input validation and bounds-checking. Dialog boxes now won't repeatedly block on illegal input if you're trying to press Escape to cancel the dialog. In addition, there's now a "Media Properties" sheet accessible from the top-level menu. This is bare-bones at the moment, simply reporting the interface name (although this doesn't appear under IDE Plus, since the BIOS doesn't appear to support the feature yet), media name, PBI ID, total disk capacity, etc. Later I'll add MBR/APT detection so you can get a rough idea of what's actually on a disk before you go ahead and reinitialize it from scratch. Regarding split/divide: just as a reminder, you can specify either/or when it comes to partition sizes and partition counts. You can specify just the number of partitions, and the available space will be divided into n partitions, or you can also specify the size and the program will attempt to create n partitions of the stated size (if the partition table overflows, only as many partitions as will fit will be created). Likewise, specifying partition size with no number of partitions will just cause the available space to be filled with partitions of size n. Note also that the size unit specified in the split/divide dialogue reflects the current setting in the View menu (i.e. MB or Sectors). When initialising a disk from scratch, remember to specify which kind of FAT partition you want at the partition level. There are different MBR partition types for FAT16 and FAT32, although it is possible to "force" Windows to format partitions using FAT sizes discrepant with the MBR partition ID. The U1MB/Incognito PBI drivers (and ensure you have the latest ones) will always attempt to deduce the FAT type from analysis of the file system; likewise FDISK itself attempts to base identification of FAT type from the file system where possible (when creating the list of "external" partitions), although it's possible that "creative" formatting can fool it from time to time. FDISK is only concerned with primary partitions, and (like the PBI drivers) makes no attempt to follow extended MBR partition links. Therefore the maximum number of external FAT partitions is THREE (leaving one primary partition slot for the APT itself). General Usage Notes If you create fifteen partitions and assign them all drive numbers, logically it follows that the PBI HDD partitions will block out all your SIO devices when you boot the hard disk. This is squarely a usage issue, and a prime reason FDISK doesn't automatically assign drive letters when partitions are created using split/divide. Note that SpartaDOS X includes facilities to bypass this issue on a by-drive basis. The safety feature which caused the program to enter super-hibernation mode if a user attempted to create further partitions when there was no space remaining on the disk has been replaced in the latest version with more robust sanity checking of user input. External FAT Partitions When creating FAT16 partitions for use with KMK's FATFS.SYS driver, take care to ensure that the partitions are absolutely no more than 32MB in size. Note that a 32MB partition generally has 65,535 sectors. To be on the safe side, I generally make the FAT16 partitions (using a PC partition editor) 31.xx MB in size. If the FAT is too large, FATFS.SYS will produce an Unknown File System error, because the SpartaDOS X file system driver cannot currently access more than 65,535 sectors in a given partition, be it FAT or SDFS. Providing the recommended setup procedure is followed, FATFS operation using IDE Plus has been found to work without issue. Compatibility With Older FDISK Versions Something which appears to have caught Steve out was that from version 4 of FDISK onwards, you can't leave empty gaps between APT partitions. This change was made primarily to simplify the editor and the editing process. In old FDISK versions, you could delete a partition near the top of the list and all the subsequent partitions would stay put. This is no longer the case. If you delete a partition, everything after it will move up to close the gap. Similarly, if you enlarge a partition, everything after it will be physically moved forward. A side-effect of this is that if you previously partitioned a disk using an older FDISK version and left gaps between APT partitions, when you save the partition table back in FDISK 4, some partitions will move and any data in them will become invalid. The program does warn you of this if it detects empty space in the partition table when loading it, but clearly this is something which users can't be warned about enough. So... you have been warned. To-Do Aside from the aforementioned enhancements to the media property sheet, there are a couple of UI enhancements Steve has suggested which I'll think about including, such as fast entry of repeated partitions of the same size (although I think split/divide pretty much takes care of this requirement anyway). The ancillary programs such as HDDINFO require complete rewrites since they are distantly out of sync with the current incarnation of FDISK, being written long before the advent of external FAT partitions and SDX FAT drivers. The little ATR mounting program whose source I shared a while back probably warrants completion as well. Steve made another good suggestion: add a "BPS" field to the split/divide dialogue so the density of the partitions can be specified. It's easy to forget there's only one DOS capable of handling 512 byte sectors. I'll also re-emphasise the warning the program spits out about moving partitions (created with old FDISK versions) if the tables have gaps in them.

I imagine it will be identical. I dislike ST mice and have a few third-party substitutes I'll have to open up tomorrow. At least the mod supposedly doesn't interfere with Amiga/ST functionality.

Instructions are here. Right button is read in Paddle(0) or Paddle(2). Note the instructions unfortunately refer to the wires by colour, so some intuition will be required if the mouse has different coloured wires. Of course something like Option or Shift+Left-click will work just as well for unmodded mice.

Want one which does? It'll give me a reason to mod one of my mice up tomorrow.

Do you have "SIDE Hardware" enabled in the U1MB menu? Set it to "enabled, with switch".

Or by using lookup tables (7 pages), which are a bit less memory-hungry than pre-shifted fonts (especially since 5-bit fonts need shifting into eight different positions). But 384 pixels horizontal resolution still only gives you 76 columns of 5-bit chars, with an awkward 4 pixels left over. I suppose that's the other reason (as well as speed of rendering) that the less readable 4-bit solutions have prevailed. If RAM's absolutely no object and you don't value your eyesight, there's always the very interesting interleaved 80 column mode Phaeron uses in his Acid test.

And I have no intention of using this in the GUI before anyone asks (again). Apart from anything else, I can only afford 8KB for the frame buffer.