flashjazzcat

The driver is so efficient now, I don't even see the lack of (say) an interrupt-driven or absolute coordinate mouse as a problem (the simple expedient of bailing straight out of the NMI when you notice that the port reads the same as the last time you looked at it saves a lot of time, for example). This reminds me that MouSTer has (I think, although I didn't update the firmware for a long time) an absolute coordinate-based mouse mode. Handy, but not something that needs to be relied upon in any way at all.

It's reading the mouse thirty or forty times per frame in a loop and apparently doing little else but that until it gets a button down.

General, GUI: doesn't make any difference. Fifty or sixty 'gray code' samples a second isn't going to result in a usable mouse pointer. Aside from the drivers examined at the beginning of this project, I recall a driver called 'Multi Mouse' published in Page 6 Magazine which was intended to interface with BASIC, etc, and that just put the machine into a blocking loop reading the mouse until the button was pressed. This of course worked perfectly well (since movement on both axes was being constantly monitored) as long as you don't need the computer to be doing anything at all while the user is moving the mouse around the desk. A great deal of discussion and development was invested in sampling the mouse at the highest possible rate using the least possible machine cycles, and experimentation showed that once the sampling dropped below 500Hz or so, it was crap.

For a joystick, yes, but if we're talking about reading a mouse, a VBI is totally insufficient. The mouse is sampled at 1KHz (twenty times per frame using evenly spaced interrupts down the height of the screen) in order to ensure smooth motion.

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.