flashjazzcat

Just scan the short names when building the file list, and access and display the long name some place when the selection bar lands on the filename in question. Kind of like a tool-tip.

He has no such information.

Incognito's HDD is almost certainly faster than the MIO RAMdisk.

No luck. Still get "access denied", although this is a generic error which can be duplicated by typing any old crap into the image filename box, so perhaps it's not the correct device spec.

Brilliant - thanks so much for that run through. I did make notes when we spoke about it before, but obviously not quite detailed enough. I'll give it a try. The other thing I was wondering is whether Linux will let you mount partitions from an image file just as if it were a physical disk. This would be safer than using a real card, but would permit formatting of FATs, etc. Anyway - I'll try out your suggestions. Back in Win 7 at the moment, since Mint totally locked up on me and I lost patience with it somewhat. I wonder if Avery will ever offer writes to a physical disk under Windows. I appreciate his reasoning for not doing so, though.

/dev/sde in my case, but I keep getting a permission error. How to run Altirra with elevated permissions? Tried (wrongly, apparently) running wine as root, but Altirra kept locking up.

MyDOS can't handle loading from H:. When the device name isn't a disk ID, it gets confused and puts in the wrong AUX values. Use Altirra's drive redirection to put the host device on Dn:. As I said, $2000 is the typical safe load address. Watch out for buffer overruns. After the first press of "1" in your program, code in the $7xxx region gets overwritten, resulting in a JSR into junk. Use CIO call tracing in Altirra too. And don't forget MyDOS directory entries are one character longer.

$2000 is perfectly fine. In what way does it not work with MyDOS?

This is specially for people who hate putting the drive numbers in.

Well - the APT spec has been around for two years or more, so every opportunity was open to avoid incompatibility on that side of things when new interfaces were developed. Unfortunately, Van Gogh chose not to hop on board, preferring instead to lop his ear off.

The original VBXE slideshow wouldn't work with MyDOS and I fixed that for Sebastian. I could take a look... not sure what the issue was now. DOS 2.5 is just totally unsuited to this kind of application... we have plenty of viable alternatives.

Yep - good links - read 'em all last year. Folklore's a good site. Thanks for sharing these for the benefit of others, though. Ironically, now we use window rects, we no longer use regions.

I once went through two motherboards trying to build a stable modded 800XL for someone until I realized there was a dry solder joint on that very stereo Pokey board, causing all kinds of random temperature-related lock-ups and instability. Fixing that resulted in perfect operation. Not saying that's the case here, but it just goes to show there a hundred different places to look for the source of an issue.

I know about overlays (although it would be a damned waste of CPU cycles to leave Antic DMA enabled with a VBXE display), but I'm unsure how things would pan out calling a blitter operation via a DLI on an overlay screen. I'd rather turn off DMA and use the traditional flickering pointer method in that case, all the elegance of the stock Atari DLI solution being lost. To be honest, I think a VBXE version would be interesting and it's probably one of those things which needs to happen one day just for the hell of it. 256 or 16 colour resources are no small ask, though, and I wouldn't dream of burdening MrFish with such a request any time soon. So - far from ruling out a VBXE version, I just think it's far too soon to be spending time planning the details. I did NOT know the Antic display had to be enabled for VBXE 480i mode, however. That kind of sucks a bit, since 640x400 would be the minimum requirement to keep the AR right. 320x200x256 would be lots of fun, though. I was never sure exactly how to set up interlacing using a standard display, let alone using VBXE. Hadn't seen the first of those sites before... some nice stuff.

Well, I'm no VBXE coding wizard but I don't see any XDL interrupt (the equivalent of a display list interrupt) which would trigger an NMI on a particular scan line of the VBXE display. The way the DLI pointer works is that the CPU draws and erases the pointer at the exact instant and duration that it's going to be visible on the screen. The pointer is therefore invisible to the underlying display (effectively a high resolution PMG). I haven't yet worked out how to do the same thing using the XDL. Hopefully there'll be something new soon. The Window Rect re-write was pretty intense (Prodatron described it as "f**king brave") and I have to say a break doing other stuff was needed after that. However, I want to get back into the kernel next week and demonstrate some concurrent processes (in a very basic form to start with, but nevertheless it will show pre-emptive multi-tasking).

Never experienced transmission errors with a SIDE2 (although I did with SIDE1). It shouldn't require any stability mods... but what you describe definitely sounds like a transmission error. What brands of CF card are you using? Are there any other mods on the machine apart from the Ultimate 1MB?

Now I'm confused as well. When you enable "SIDE hardware" in U1MB, you can't simultaneously use SDX on the cart, since the switch should be in the up (loader) position. Two modes of HDD operation are: Side 2 switch up with SIDE Hardware enabled in U1MB, SDX enabled / disabled in U1MB (depending on which DOS you fancy). This gives you a PBI HDD. Side 2 switch down with SIDE Hardware and SDX disabled in U1MB (SDX is then run from the cart). You'll need the SDX soft-driver to use the HDD in DOS in this configuration. The third (stand-alone) mode of SIDE operation is with the switch in the up (loader) position and SDX/SIDE Hardware both disabled in U1MB. The FAT32 XEX loader will then boot from the cart. Of course U1MB owners can get at the XEX loader by pressing "L" in the BIOS menu screen.

Watch the beginning of the video in this post. What works better when you set SIDE to disabled? The hard disk? The computer? SDX? Anyway: SIDE Hardware is a PBI driver for your SIDE cart. If you switch on "SIDE Hardware" in the U1MB BIOS, you don't need any soft-drivers or whatnot to enjoy the hard disk. Select "SIDE Hardware, w/button", put the SIDE cart's switch into the LOADER (NOT SDX) position, and off you go. If you want to know how to set the card up - it's in the video.

Well, if DLT aren't worried about it (assuming they know), then it's the unwary buyer who's being ripped off - and as you said before, any collectors owe it to themselves to stay informed.

I'd never considered that, but it makes total sense. Actually I don't mind the click (I kind of missed it on the school Beebs in the 80s after being used to the A8)... I suppose ten years of coding with the TV speaker up desensitised my ears.

If things stay as they are now, just (!) the entire screen output library would need replacing. The logic side is clearly removed from the rendering end of things. Candle encouraged me to make the data structures at least forward-compatible with some colour support (for possible VBXE use), and the coordinate system is already ample (-32,768 to 32767 in on both axes). I STILL have not figured out how the DLI mouse pointer might be implemented under VBXE, however - short of using some kludgy overlay which would fire a DLI at the appropriate point (requiring Antic DMA to be enabled), which in turn would do some blitter stuff. No idea yet. MrFish and I dallied with tracker files a year or more back, but it never went further. I'm using two Pokey timers, which might have an impact on sound generation. Phaeron made some interesting remarks on sound generation in light of this, IIRC, further back in the thread.

Surely a believable depiction of breasts is the best litmus-test for any new graphics mode. And that's from someone who has access to real ones.

Well, the 160px pointer resolution in itself isn't a major problem as long as you're just clicking on buttons. No good for a hi-res pixel editor though. Maybe that's why Diamond's drawing app used four colour mode (Diamond used a PMG pointer).

No, because PMGs lack the necessary horizontal positioning resolution. Not sure if there'll be any provision for 160 column / 2bpp support for stuff like colour drawing programs and the like: this kind of relates to the mode-independency stuff I talked about earlier. Not in the least bit worried about that at the moment. The system is ostensibly monochrome hi-res and that's what I want to get working first.

The mouse pointer? It's a PMG.