flashjazzcat

Not with like-for-like functionality and flexibility, although I believe that with brutal optimisation and various tricks the general look and feel can be approximated. The slowdown on a 68000 Mac when they added stuff like colour support to QuickDraw is palpable. System 7 on an 8 MHz Mac is a really appealing benchmark for the A8. But it's not necessarily the fairest one. Same with MagiC and Jinee on my STE. If the 68000 stuff had all been written in hand optimised assembler with no need for colour support, etc, I'm sure it would be blistering. But I'm no expert in 68000...

Good point regarding the website. I've been well and truly side-tracked by APT stuff recently, but now that stuff's mostly nailed down, it's GUI time again. As for major components: the GUI has taken on a very Symbos-like architecture, in the sense that it comprises (or - more properly - will comprise) a number of major parallel tasks, together with something equivalent to the Mac "Toolbox" - the latter being a big library of ROM-based UI controls. The main tasks are roughly as follows: Window Manager (which SymbOS calls the "desktop manager"): handles windows, dialogs, menus, user interaction with controls, etc. Process manager: handles loading / executing of tasks, etc. File system manager: deals with calls to DOS - basically any file-related tasks. As well as this, you have the scheduler running in the IRQ, and the kernel itself which handles stuff like memory requests and inter-process messaging. There's also the graphics library, which is called by the window/dialog manager when it wants to draw something on the screen. The window manager is the only process which ever calls the graphics library directly: all application requests for redrawing windows, controls, etc, are handled by the window manager. This way, requests for screen updates are queued up and handled by the (non-re-entrant) graphics routines. We'll also have a driver system for file systems, input devices, RTCs, etc. Whether the screen output routines can ever be abstracted enough to become device independent remains to be seen: at the moment they're all hard-coded for a 1bpp display, which is one place we get the speed from. Code which draws a button, for example, does not call pixel plotting code which could be made screen-mode independent: It just blits the bitmap direct to the 1bpp display RAM.

FDISK 4 tutorial part 1: This covers the basics of using the program, although hopefully the software is now intuitive enough that you can skip most of the video. I'll cover the interesting stuff in part 2 (external FAT partitions, use of FATFS.SYS, etc).

Display quality aside, the resolution / colour limitations as well as the stock CPU clock speed are one of the joys of developing for the platform. Not everyone "gets" why that's the case, but it is the case for me. Stick a 16MHz processor in there and throw 256 colours at the screen and it becomes unclear where the achievement lies in getting the machine to perform various feats.

Yeah, I'll get in on that.

Great - I love it when bug-fixing is as easy as that.

Please do! And take plenty of shots of LW in 80 column mode with the default colour scheme. Anyway: to get back to the theme - RGB output is (I'd suggest) something users would have keenly adopted were an adapter made available back in the day. The extra graphics capabilities of VBXE are, of course, a different matter when it comes to what's "Atari" and what isn't.

Must just be me or my monitors then - even modded machines tend to pale in comparison to VBXE RGB output on a 1084S. If I'd never seen RGB, I wouldn't know what I was missing, but I did, and I do. Even when I think I've tuned the Y/C so it looks good, I boot The Last Word and... forget about it. Sure you can make the letters out, but it's indistinct. Switch to an LCD, then, and watch its skewy s-video scaler make one side of the software 80 column characters wider than the other. With RGB, none if this quaint compromise between practicality and purism: it's clear and you can read it. I always had the uncomfortable feeling, therefore, that LW's 80 column mode is largely redundant on a stock machine (and therefore "not Atari"?... where does it all end?). However - as I say, I may just have experienced unlucky marriages of computer and display. The exception is a particular 800XL with a particular mod (Ultravideo) and a particular LCD monitor (LG M227WD, which sadly died), which resulted in somewhat RGB-like quality. But in general, I don't find Y/C output terribly well suited to 80-column output.

Consistency is a rare and laudable human attribute.

The excellent advice you got on the fundamentals of getting the flasher working surely helped. Anyway - just flashed the CPLD update on my Incognito; all good. Thanks Candle. EDIT: BIOS and Loader updated too, straight from the FAT32 partition using the loader. Smooth as silk. Candle: can we sort out a utility to update the PBI ROM in the same way?

It's worth £100 not to have to look at crappy Y/C output.

Doesn't make a blind bit of difference what's in CONFIG.SYS... SDX isn't even required to run FDISK. Just ensure SIDE Hardware is enabled in the Incognito menu.

Right: set up 800 (for first time since Candle repaired and returned my Incognito), booted and ran the latest FDISK beta: Not sure how old the PBI ROM is on mine, but it picks up the card and reads the table. Only thing I noticed is that this PBI ROM build doesn't return a hardware ID string - probably just needs flashed to the latest version.

Sounds like a transmission error... PBI ROM is wholly responsible for operation following Initial mount. Video would help.

Time to set up my 800 and do some testing...

Inabilty of driver author and hardware designer to agree on RTC encoding method, I believe.

Is that a "no" to the previous question?

Did you boot the XEX by typing COLD /N at the SDX prompt?

You'll need to disable SDX to boot anything, if it's enabled.

That's the Atari trying to read an ATR. I thought you were trying to boot an XEX???

I found the best way to use structs in that manner is to define a pointer to the struct array and then use the struct tags as offsets in the Y register, thus: ldy #Enemy.Room lda (Enemy_Pointer),yYou'd advance the pointer like this: adc # [.len Enemy]Or you could use a look-up table or similar for the array element addresses. Anyway - that's the way I use arrays of structs. I don't define them as static: I just allocate a buffer large enough to hold n * [.len Struct] and index it as above. Heh... it can be reworked later (and it does happen) - it just takes longer (in the long-term) than getting it just so in the first place.

Thanks for that Roy. The program is probably missing fundamentals like checks on buffer overruns (so there'll be a limit to the directory size - probably quite severe given the storage requirements for long filenames), which might explain some issues. The details on the problem filenames are appreciated. I was half way through making another (better) video tutorial but stopped when I discovered another couple of bugs in FDISK, although they were purely cosmetic. For some reason I wrote code to display the APT revision number as a BCD (major/minor version) number, when it fact it's a 2-bit value which occupies bits 5-6 of the first byte of the APT. This in turn led me to discover (with a slight start) that the number of mapping entries written out in an empty APT was wrong (undefined, in fact), but fortunately it's always corrected once entries are added. Both fixed now.

When you say "the first two FAT32 directories are scrambled", do you mean their entries in the root directory, or the actual directory content in the folders? Note that the file lists are sorted alphabetically, so we might need to turn this off to get a better idea of where the problem is occuring.

Thanks Roy. I'll look into that. Heh... I didn't think anyone ever used import/export table. View by MB seems practical to me, but who knows how useful view by partition name is. Anyway thanks! PS: Candle was asking if FDISK can be put on the SDX CAR: device. Obviously at 19KB it's too big, but it shouldn't take long to make a build split up into a couple of overlays which will fit (files on CAR: are limited to 8KB). I dropped the SDX-only version (which used DLLs) because the application needs to work regardless of the DOS in use and it was too much of an upheaval maintaining two very different versions of the same utility which nevertheless did exactly the same job.

Were you using the version from the website? Try the attached and let me know if it's any better: matr_0.2_beta.zip