flashjazzcat

Another bonus with the final versions is that they now make better use of screen real-estate when S_VBXE.SYS or RC_GR8.SYS are present:

Maybe I got some funky downloads.

It's possible to make a convincing replacement, should you get stuck.

Well, I recommend against using any beta once version 4 is released. Beta 8 has the odd bug... hopefully none in beta 9. Not to mention the fact external FAT partitions now have their own partition type, recognized and checked by the forthcoming U1MB/Incognito PBI updates, so I won't entertain complaints about mangled partition tables from people using beta 8 with new PBI ROMs.

Tried stock 64KB configuration with some success but this rather defeats the object of Basic XE. I couldn't get the extensions to boot properly with SDX enabled until I disabled all the extended RAM in U1MB (this is in Altirra). Even then, the BXE cart doesn't let SDX boot properly, and typing DOS at the BXE prompt bizarrely takes me to the DOS 2.5 menu. Can't emulate Incognito yet and testing on real hardware again won't reveal much. Something very cooky going on with Basic XE anyway, apart from possible PORTB oddness (I have vague recollections of an old thread describing some short-sightedness in OSS's use of PORTB bits). If I eject the extensions disk and boot with SDX enabled, everything looks good until I type CAR, then DOS. SDX is clattered on re-entering the command processor, and locks up shortly afterwards. My workaround would involve clicking the 5-in-1 cart button until MAC/65's number comes up on the LCD.

Better yet, try http://atariage.com/forums/topic/210754-apt-hard-disk-preparation-and-utilities/page-6?do=findComment&comment=2877529.

You're using the SDX soft-driver Kyle, so it doesn't make any difference whether the machine is an XEGS or has PBI support... and consequently whether the jumper is in place or not. The OP was having issues with the PBI ROM.

So what happens when they don't work? Symptoms?

Well - we were getting warm. Solution here.

Thanks Sebastian. I almost reached this conclusion in the other thread. It suddenly dawned on me that for some reason the OS mustn't have been observing the PBI device at all.

No you don't need an APT for this to work. MyBIOS ballsing things up doesn't surprise me much and obviously isn't my problem, and I don't know if I'm reading Lotharek right there but I can see no circumstance where it's wise to run SDX off the SIDE cart when it's right there on the U1MB. U1MB: SDX on, SIDE: SDX off. Now: here's s pertinent question. Does your OS of choice even contain any PBI code? It must initislise the PBI device at boot, otherwise HDD and ATRs will never work.

Do APT partitions work at all?... you may have said already but I forget. By this I mean does any aspect of SIDE Hardware work at all? Both the PBI hard disk and ATR mounting are managed by the same code. It'll either work or (for some unknown hardware related reason) it won't. And how did you prepare the CF card? Does it have an MBR (master boot record) on it? Surely it's a confounding issue, but there must be a determinable cause.

Another good one: Mikomi 15LCD250, which someone gave me in return for fixing up their PC: s-video RGB Should be found in second-hand shops and boot-sales across the UK, and quite a nice match for the XE.

Well, you were never going to find eight totally redundant header pins on a board this size, to be fair. Parallel JTAG cables are easy to make and all you need is and old PC or a PCI parallel card for a few quid. Personally I'd have sent the item back for repair if all this is too much, just as you would with any other defective item. Costly postage, etc, is just one of those unavoidable circumstantial factors.

Got some odd results using SDX folder imaging while developing today which are presumably caused by cached sectors not being invalidated when a file changes. Target file is closed when changed, but only by rebooting SDX could I be sure I was loading the freshly compiled build of the application. I'll do some more tests tomorrow.

I'll take the relative silence following sixteen downloads as a good sign. New version of MOUNT is nearly done: This will require a BIOS update for U1MB/Incognito in order to work properly with the partition tables created with the latest editor. I found a couple of cosmetic bugs in the PBI ROMs while developing this (most notably their DEVINFO commands didn't return $01 for the Bus ID, and also numbered the Controller IDs 1-8 instead of 0-7: both fixed in the new ROMs), as well as the aforementioned mounting issue (mounting only worked because the partition IDs were stored in un-mounted partition entries, and they shouldn't be and no longer are). "MOUNT /L" is a little slow with IDE Plus 2.0 since that interface doesn't yet implement drive mapping (which is simply a way of getting a map of all the drive numbers attached to the PBI device), so all fifteen drives numbers are polled for the partition IDs regardless of whether they're hard disk partitions or not, complete with the associated timeout delays. IDE Plus also doesn't return the hardware description via the DEVINFO command. Having said that, the IDE Plus doesn't implement dynamic mounting at all yet, so this utility may be of limited use with it anyway. Just need to add support for providing the device ID (i.e. MOUNT /L 1.3.2 to get a list of partitions on the slave drive of PBI device #3), tidy up MATR, finish the BIOS updates, then that's that. EDIT: Also discovered that partition tables created with the new FDISK don't work with IDE Plus 2.0 if you have the global metadata flag set, since it's not recognized by the IDE Plus BIOS; indeed this reserved bit, when set, causes the partition table to be deemed invalid. Temporary solution (pending BIOS update) is to go into APT properties in FDISK and turn off the global metadata flag. You can still have named partitions (i.e. metadata can be manually set on partitions), but the global flag is currently not compatible with IDE Plus 2.0.

Oh good lord... I just got things set up the way I like them using the current scheme.

@Bugbiter: the viewer is coming along great, but please move the display list outside of the $4000-$7FFF region if possible. You get a lot of screen garbage under SDX otherwise, if DOS is running code and buffers in banked memory. EDIT: Same goes with interrupt code: keep it all outside of any area which might get banked out by DOS when the interrupts are still running. This includes $4000-$7FFF and potentially also the RAM under BASIC, depending on which DOS operation is being invoked. Alternatively, shut the DLIs down when calling the CIO. The viewer just crashed under SDX when DOS banked itself in, causing the NMI's RTI instruction to return to the middle of DOS code.

Probably a daft question but after you mount the ATR in the SIDE loader (so it has a "D1" next to it), what's the exact next step you perform?

Exactly. I usually just "paint carefully" so the peroxide doesn't slather all over the brown plastic. It's no big deal anyway. I've never yet experienced peroxide draining the colouring out of the brown plastic, although I certainly wouldn't risk intentionally giving it the full treatment.

Yeah the only extra step with the XEX is that you'll need some kind of tool to pack the ROM image into executable segments which then load themselves into extended memory. There are a couple of ways to go about it. The real shame is the usual PLCC on the U1MB has 64KB sectors, so every time you flash the PBI, you also have to erase and reflash the BIOS, thus injecting a small but perceptible element of risk.

Well, this much vaunted XEX flasher should be an interesting prospect, since as I see it, it would have to be a multi-stage binary file which successively loads chunks of itself into extended RAM banks. That would mean 32 init segments to bump PORTB, so you couldn't just paste the U1MB ROM image onto the end of an executable. This is why the SDX flasher - for example - uses an ATR: so that the ROM can be included verbatim as a separate file on the disk image, and loaded in stages by the flasher. I'm sure a self-contained XEX flasher is a logical proposition if you possess no serial peripherals and ATR mounting is the only way of accessing ATRs, but there are probably a number of good reasons why it doesn't exist yet. Of course, an XEX which runs right from the FAT partition and actually pulls the ROM file from the FAT is another possibility, but again quite an undertaking and the circumstances under which such a thing would be required seem to me quite exceptional. I've just put together an ATR-based flasher for 64KB sector PLCCs which reads the entire ROM into extended RAM and then flashes from there. The main advantage of this is that it's fast if you're able to mount the ATR using U1MB / SIDE, but beyond that something SIO-based is just as good. Some kind of inexpensive SIO2PC connection which can be used with Aspeqt is a really sound investment if you need some alternative means to access the content of ATRs in emergency situations.

Looking at the other thread, I thought you'd already done a complete reflash with the v2 ROM? You complain of no ATR support, but I'm not sure what's to be achieved by flashing the exact same content to the ROM, but via a different method (i.e. via an XEX instead of a burner). Just leave the chip where it is... some procedural factor has to be at fault here, and no amount of levering the PLCC in and out of the board is going to solve that.

Just looked: that's the exact code my current U1MB PBI/BIOS flasher is based on.

Thinking on - I'm sure the one I saw with evidence of glue had been repaired. Makes sense.