flashjazzcat

I was wondering if this works yet: I asked @tebe about the ability to generate multiple RELOC blocks in the same source file more than ten years ago, so I figured it might not be too soon to bring it up again. Although the instructions appear to cleam it's (now) possible to have multiple RELOC blocks, I'm unable to get this to work since it keeps throwing out compiler errors ('ORG in reloc block', etc). To be clear, what I was hoping to accomplish is exactly what's already supported by the SDX relocatable format (multiple reloc blocks of different types with inter-block references included in the fix-up table) but without the annoying limitations of said SDX relocatable format (eight character label names, no lo/hi fixups, etc). For clarity, perhaps an example will help: blk absolute $3000 ; loads at arbitary address, and is jettisoned after use Init jsr something rts blk reloc main ; loader relocates this block down to MEMLO in base memory DriverStart ; do stuff blk reloc ext ; loader relocates this block into extended memory (if available) ExtCode ; do more stuff blk update address ; produce fixup table I realise the relocatable format was ostensibly designed for use with the MADS linker, but I wrote the relocating, linking loader more than a decade ago and the MADS proprietary format is otherwise perfectly usable, aside from the inability to produce a compound file which can be efficiently relocated into main and extended memory as required.

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).