flashjazzcat

For closure, Peter had indeed fixed the Outline label sorting issue several revisions ago, but I had simply been resistant to updates owing to many plugins becoming broken in some more recent Eclipse builds. However, Peter convinced me to try a completely fresh installation and I'm now completely happy (especially since Eclipse's dark mode now bears looking at).

At first it sounded to me like a knackered cart connector. I once had a machine here with two address line contacts shorting out when no cart was inserted, resulting in no boot, but when a cart was inserted, the short was cleared and everything worked fine.

I reserve a special mistrust of any Atari 8-bit powered by USB, and at least half the time, my misgivings are quickly proven well-founded. I recently asked a client who reported SIDE3 issues I was unable to replicate once his setup was on my desk what kind of power supply he was using, expecting him to say 'USB'. Sure enough, he sent me a photo of a 1.6A USB adapter.

Needless to say, anything preventing proper communication betweem the CPU and memory is laible to cause an aggressive RAM test to fail, so I wouldn't even necessarily describe SysCheck calling bad RAM on a machine that's otherwise broken anyway a false result. The machine described above (which turned out to have a failing power supply) is a perfect example.

What loader are you using on real hardware?

Working fine here on a PAL 600XL with VBXE/U1MB/PokeyMAX/SIDE3.

I didn't know for the longest time, years ago. It's easily missed when one uses SDX, etc.

In the manual (SIDE3 here, but similar notes exist in the U1MB/SIDE manual). The XEX loader (at $700) has to implement the fundaments of a read-only FAT16/32 file system driver in order to read the file, plus the low-level SD card driver (in contrast to co-processor solutions which do all the clever stuff in a microcontroller, leaving the 6502 side of things to just pull bytes out of a data register. I might experiment with a PBI-based XEX loader, not that this will be much use on non-U1MB systems, although it will be highly usable when External U1MB is done.

Micron DRAMs (yet again). They should be socketed and replaced as a matter of routine, and doing so may well fix the machine.

I have no idea whether it will make a difference, but is the R42 resistor present? It's not present on my PAL 600XLs but is populated on NTSC machines. Candle suggested it was some kind of video feedback resistor, and although I removed it when troubleshooting the luma on the machine in the video (eventually discovering the problem was caused by a partially shorted decoupling cap on CD4050), I put it back and didn't notice any effect. But composite was - as usual - quite nasty, and I wonder if W42 makes any difference at all. In any case, it seems: NTSC: W2 = populated, R42 = vacant PAL: W2 = vacant (since we have a discreet clock source for colourburst), R42 = populated PS: the composite output in the photos resembles the composite on the NTSC machine in the video, so I wouldn't obsess over it too much unless you're keeping the machine and propose to tailor the video to your liking. Anyone buying a forty-odd year old 8-bit computer should surely have their eyes open regarding non-standard analogue video output, etc.

MaxTasks = 16 (an arbitrary value, chosen to keep the process table at a reasonable size). The following processes are run at start-up: Clock Desktop Idle File manager Kernel System Two of these (clock and file manager) are classed as applications, and the rest system tasks. So it would be possible to run ten profilers. Memory usage is indeed quite high right off the bat, but the kernel immediately counts 48K ($0000-$3FFF and $8000-$FFFF) as used (by ROM, the 8K display buffer, and internal tables), and the system allocates RAM (by 256-byte page) for quite a few large resources before the desktop comes up. Note also that one page (256 bytes) of each 16K extended memory bank is reserved for memory housekeeping.

Prodatron (the SymbOS author) has been a regular participant in this thread and it was he who convinced me to abandon my mask-based window manager and replace it with a rectangle-based one similar to what he implemented in SymbOS. Indeed, it was he who convinced me to make the thing multi-tasking.

Relocatable code occupies no more memory than non-relocatable code once loaded from storage and fixed up in RAM, so the only real issue presented by the lack of an MMU seems to me to be the lack of memory protection (so random writes outside of the application's allocated RAM can be somewhat disruptive). The minimum RAM requirement is 128K, with (on that base configuration) 80KB available for resources and applications (four extended banks plus the main bank). That's ample for a handful of applications, resident resources, etc. In point of fact the system could probably run in 64K, although the limitations (16K for applications and resources) would severely impede usability. Although, since we now have a proliferation of mass storage devices which are as fast as RAM to RAM CPU block moves, it would be fairly trivial to cache an inactive process to disk if RAM was in contention. That's why the UI is one of the processes which runs entirely in banked ROM, consuming no RAM whatsoever. Applications, meanwhile, can implement a complex UI using minimal code (since they're just calling the OS instead of drawing everything themselves). Probably so, although all but a few of the most ardent coders will probably balk at the complexity of the window and dialogue descriptions and hope that someone also writes a resource editor to make application development less intimidating. Appreciated - thanks! You mean SymbOS? I had a cheeky idea the other week while making a video demoing 'Let's Emu' (Spectrum emulator for the 65C816). If we can emulate the Z80 at reasonable speed with Rapidus, would it not be feasible to emulate the CPC (with VBXE taking care of the emulated display)?

You can do this with SIDE3 as well since it not only reads and writes FAT, but provides a DOS that reads and writes FAT (something else not mentioned in the video). Totally agree regarding the convenience of RespeQt and virtual folders used by SIO2PC and Altirra, though. The ideal situation is to have both (SIO2PC and multi-cart).

That's almost as surprising as the prior response. I have no particular insight into how WUDSN works, but I assumed the code parser would collate a list of identifiers and simply sort and present them however it saw fit (since the assembler need not even be present for the outlining feature to work). I was hoping to avoid the situation of a label like 'buildLBA' effectively appearing in a separate list of lowercase identifiers after the end of the list of identifiers beginning with (or wholly comprising) uppercase letters, since a case-insensitive sorting algorithm would - for example - place 'buildLBA' right after 'BootDisk' and in front of 'CheckSwap' regardless of character case. Perhaps this is just the way Eclipse works, anyway, so I'll have to live with it (the source files being far too huge to start messing around with label names just in order to circumvent this issue). Thanks!