flashjazzcat

Probably just hooks or tables: the pointer driver, for example, just needs to define the polling routine (which should also update the relative X,Y coordinates, which are added to the absolute coordinates by the stage 2 VBL), the frequency of the polling, and some trigger code. Symbols are nice too (as found in SDX): we can have a global symbol "poll" which just points to an RTS until a driver updates the poll vector. Dunno about "practicing" (practising?): I've had a look at the docs and I'll "adapt" any relevant ideas.

Same here on desktop browser.

Yes indeed, but I really prefer to use MADS for development, and it'll be easier if I don't have to start using a different (and possibly deprecated) assembler.

Small but critical update: http://atari8.co.uk/apt/tools/fdisk4_test4_081113.zip I was messing with FDISK 4 this evening and noticed that sometimes it was impossible to edit partition sizes. There was also a (cosmetic) bug in the partition name editing routine. I don't have time to add the other things on the to-do list at the moment, but I thought the editing bug important enough to fix.

Drivers are the answer. Just get rid of the default mouse driver and replace it with one which supports the fancy hardware.

64-bit? Seems to work in 32-bit.

Sounds sensible, although we're months away even from that stage yet.

RGB vs stock output is like night and day. It's worth it.

Heh - Google is admittedly much faster than MADS and Eclipse. Right here on this thread we rehashed the driver code until a decent sampling rate was possible without consuming too much CPU time. 1KHz is no good if it's tying up all the processing time, "standard" speed or not. On the other hand, if 1000Hz is a standard polling rate (as you've written), how can it also be "arbitrary"? Here's a forum discussion which advocates a 1KHz sampling rate for an Amiga mouse, and here is CPC wiki entry which suggests polling an ST mouse at at least 500Hz. My experiments demonstrated that on real hardware, with a standard ST or Amiga mouse, somewhere towards the 1KHz end provides the best compromise. But I was still getting reports of roll-back (when the mouse direction becomes ambiguous because readings have been missed) until I added in ballistics, and now it's really smooth (because the acceleration tends to prevent the user moving the mouse too fast). I haven't done a precise count of how many cycles the mouse IRQ consumes when the mouse is idle, but if we blew say 40,000 cycles per second polling the mouse, I think that's reasonable in order to ensure smooth movement. A lot of A8 mouse drivers (such as Multi-Mouse) poll the mouse in a closed loop, so the machine can't do anything else except service interrupts until some kind of exit condition is met. I wonder what the sample rate is in a closed loop? 20KHz? 30KHz? No good for our purposes, though. Standard ST and Amiga mice. No idea what the Hz rating is but as I say, the optimal sample rate was arrived at through experimentation on the target hardware. Not that I want to constantly revisit this subject (since there are many more pressing matters which need addressing in order to advance the project), but the only additional optimisation I can think of is to drop the sample rate after a period of mouse inactivity - say 20 IRQ ticks. Then, while sampling at a low frequency, boost the sample rate back up again as soon as a change is detected. Regardless: this won't account for massive increases in rendering speed, and it would only be of any benefit if you didn't move the mouse while the screen was being redrawn. I'm really more concerned with stuff like which relocatable binary format to use, since that will become an issue before too long. I PM'd tebe about a couple of issues with the capabilities of MADS' own proprietary format six weeks ago, but haven't received a reply. While we banter about other stuff, and this kind of thing goes unaddressed, potential obstacles are stored up for a later day...

Correct in every detail.

1KHz is not arbitrary. It took months of experimentation to arrive at that sample rate. Much slower, and you get roll-back when moving the mouse at speed. The mouse pointer is drawn once per frame.

It's less a mathematical thing than a "feel" thing. Responsiveness to me is how long it takes before the is GUI ready to respond to user actions. If the windows take too long to redraw, the user is already trying to click on something else, and so perceives lag. Redraws can't be instantaneous, so the objective is to make them fast enough and unobtrusive enough that the user appreciates that the system is busy without becoming frustrated by lag. The performance impact of running the scheduler at 10Hz would be that the renders would get a little more CPU time (though not an appreciably greater amount, since the scheduler IRQ is brief if there's no context switch). 10Hz is impracticably slow for a scheduler, though: it would negatively impact the system in other ways (tasks would be slow to respond since the context switches weren't happening fast enough). Regarding refresh: there's no "frame rate" as such. It's not an immediate-mode GUI. Stuff takes as long to draw as it takes to draw... you see the updates real-time. Mouse sampling is 1KHz or thereabouts because that's the lowest frequency (coupled with acceleration) which works reliably and accurately. If the mouse isn't moving, the IRQ is cheap (especially with the custom IRQ handler): .local mouse ; pokey timer interrupt-driven mouse sampler lda $d300 cmp old_mouse bne Moved pla rti Moved ...

Yeah - it's always the way with new code: most important thing is to get it working and bug-free... then comes the optimisation. I thought of lots of obvious things since I uploaded the vid, including inlining clipping stuff. Plenty of slack there, and there's already a scheduler interrupt firing 50 times a second in that video, together with the mouse sampler IRQ at 1,000 Hz. It's taking so long just to develop the 6502 version that I can't say a 65816 build is something I'd undertake till... well... somewhat later in life, if at all. The main objective is to see what can be done with a stock CPU and a minimum of 64KB or 128KB. There's application development after that, which should occupy a lot of my hobby time for some years. That said, I have taken care to ensure that the GUI will run on a 65816 accelerator, although even that seems to me to defeat the object somehow.

Rectangle-based window manager just about debugged and working now: Windows full of text are the slowest to render, so I figured three windows full would be a useful performance test. With reams of new code, there's plenty of room for optimisation, but I'm satisfied that this system will be the most responsive. By optimising the clipping and rendering routines we should be able to squeeze a bit more out of it, and now I can refocus on kernel development and continue with the cart conversion. For interest: the client areas of the window are no longer rendered by the demo application, but by the window manager itself. Each window contains a "text control" which occupies the entire client area. When a window is resized, the demo application gets a WM_SIZE event and goes ahead and changes the size of the text control to match before the system gets hold of it and draws it at the new size. The text control will probably end up with its own scrollbars (integral to the control), so a simple text editor will consist of little more than menu definitions, window records, an event loop, and calls to the file selector, etc. The GUI itself will take care of all the text editing.

Just to note: the mouse capture issue persists. I don't actually think it matters whether the OS pointer is in the display bounds or not when it's captured with F12, if that helps any.

Altirra's debugger is awesome - and more so now I've marshalled most of the debugging windows by turning them into tabs (all the floating windows can get a bit unwieldy). I don't honestly think I'm using the debugger to its full potential, to be honest: I need to take the time to sit down and study the stuff I'm not using. Debugging linked lists would have been harder if everything wasn't interleaved and aligned on hex boundaries: so, I have 64 bytes of "next" pointers, which line up nicely in the memory monitor window. I then had to trace the lists and jot down the node content, translate all the rects from hex to decimal, and draw them out on paper.

I just used the (ample) facilities in Altirra's excellent debugger: breakpoints at judicious points (before and after changes to the rectangle lists), break on memory access (useful when looking for rogue writes by faulty code, overflowing buffers, etc), memory monitor, pen and paper. Yes: downloadable BIN for flash cart in the first instance (min 64KB), and hopefully something designed specially for the job one day. First cart build will take several months to prepare, however.

Simply that. It doesn't need to do anything more.

It was Clayton Walnut's C-Manship which included a program to demonstrate GEM window rects by filling them with different patterns. This is something similar which I coded up to test a particular optimisation: It shows all the separate rects which make up the desktop. Of specific interest (and the reason for the patterns) is the area to the immediate right of the foreground window's title bar. The split algorithm - when superimposing the front window - has split the long rectangle immediately above the back window. It also created the long vertical space to the right of the foreground window. These two splits have resulted in two rectangles of the same width, one above the other, to the right of the front window. This is inefficient when it comes to rendering the rectangles, since we're iterating twice when we could have iterated once with a single, larger rectangle. The optimisation is: when adding new rectangles as the result of splitting others, first scan through the entire list looking for a rectangle of the same horizontal / vertical position and width / height which is immediately adjacent to the new rectangle. If one is found, simply enlarge that rectangle to encompass the new one: The result is that the superfluous rectangle is no longer introduced.

Well, I guess for anyone not using SIDE1 or SIDE2 with U1MB, the PBI ROMs are irrelevant (doubly so if MyIDE is being used). If you have U1MB, obviously the optimal way of attaining proper hard disk functionality is to buy a SIDE and use the PBI ROM, but I suppose there's no law against using the soft-driver with MyIDE. Unfortunately there'll never be an APT PBI ROM for the MyIDE cart since the MyIDE registers are at the wrong address (or perhaps I should say an incompatible address).

Should have another update soon. Hit a mind-boggling bug last night (I suppose it had to happen after days of unrestrained progress) which took about four hours to track down. Basically, when splitting a window's existing rectangles with a new one, any rectangle in the list which doesn't intersect with the new rectangle gets left alone. Any rectangle which does intersect gets split into smaller rectangles, and the original rectangle is then removed from the list. New rectangles are added to the head of the list, so we can iterate through the original list without being troubled by the new additions. This obviously requires manipulation of the head and previous node pointers; the latter being essential for the deletion of the original rectangle. Turned out that if the rectangle didn't intersect, previous node wasn't being updated, so the next insertion was pointing head to the next rectangle in the list, causing the non-intersecting rectangle to be lost. Words can't express how much fun it was tracing through hex memory dumps to find that one.

Me too. I lost the floppy drive when I upgraded the PC a year ago and kind of regret not searching for a motherboard with a floppy connector (although I'm not even sure if any exist now). I got hold of a cheap, ancient laptop with a removable floppy drive, but I haven't tried FloImg with that yet. A USB drive for the PC would be great, but I'm doubtful for the reasons cited in your link.

Slightly OT: but do those USB floppy drives actually work with FloImg?

Yeah - the logic is not optimal but basically it blits if there's a complete copy of the window already on the screen. We could mess about with partial blits but it's simpler to just draw the whole window if it arrived from an off-screen location. Not to lose all sense of perspective, but it does look pretty favourable running next to System 6 on an (admittedly somewhat overburdened) emulated 68K Mac at 8MHz.

Heh... this is a bit more like it: All the redraws are confined to any intersection of the window's old position and the newly computed rectangles which make up the desktop around the window's new position. It would probably help to fill the different desktop rectangles with different patterns to demonstrate what's going on. I think there was a program for the ST (possibly in "C-Manship") which did just that, filling a window's rectangles with different fill patterns. Anyway: I spent much of the evening gleefully ripping masking code out of the graphics library, so I haven't quite gotten around to adding more windows.