HiassofT

Give the "stabilize XL" mod a try, the simple one-wire connection from pin 4 to pin 13 on the LS08 is easy enough to do http://nleaudio.com/css/stabiliz.htm It sounds a bit like you are suffering from timing issues and swapping out the ls08 for a f08 will only help a little bit - the "stabilizing" mod will shift PHI2 timing a lot more. so long, Hias

Buy a block of brass, a saw, sets of files and drills and do it old-school like students in mechanical engineering school have to go through - create your very own gears from scratch 🙂 so long, Hias

Well, I guess you are well aware of what you are doing so no further comments on the chip choice here 🙂 I'm glad you got it working and fingers crossed the 3V3 flash will do it's job until your Farnell shipment arrives! so long, Hias

Out of curiosity: which chip did you use? so long, Hias

It uploads the flasher code to the mega speedy and calls it's init function which then checks if the Speedy ROM version is new enough and if a SST 39SF040 flash chip (manufacturer ID $BF, device ID $B7) is present. If those checks fail it'll report an error. so long, Hias

Well, in PAL land TVs didn't have any tint control settings - those were only needed in Never-The-Same-Color land 🙂 Other than that artifacting woks at best very poorly with PAL - so most of the time we saw some barely colored odd black-and-white dot patterns. so long, Hias

@xxl You could try if you can squeeze out a few more MIPS by using undocumented opcodes in sysinfo - Eclaire should support them just fine 🙂 so long, Hias

29F040 has 64kb block size whereas 39SF040 has 4k. 29F040 won't work with the flasher as it can't reprogram each individual slot separately. so long, Hias

I never used a mouse with my 8bit Ataris - I guess a KVJ switch (with 2 joystick/paddle ports) might be more appropriate 🙂 so long, Hias

I'm not much of a gamer nowadays but I spent endless hours playing Boulder Dash (esp with the construction kit, creating levels with one of my best friends) and Ball Blazer (lots of fun as a 2-player game) back in the 1980ies. so long, Hias

The default desktop on Ubuntu is GNOME and that uses Wayland instead of Xorg for a while now - hence no Xorg log files. so long, Hias

Sure, you can do that with additional hardware, making use of the PBI support in the OS. You are re-creating the U1MB though if you go this route, it uses that method to support highspeed SIO. so long, Hias

Not really. $5000-$57FF clashes with normal RAM, you'd have a hard time loading data via SIO to those RAM locations if ROM is mapped in, it might contain display or even worse DLI code/data that's being used or, very common, a RAM upgrade will decide to not map in ROM to that location as it uses PB7 for bank selection if PB4 is low. You can reuse the selftest area, but not for things that are needed during normal operation. Some patched OSes threw out cassette or PBI support to free up some space, but all of those are more commonly used than the international charset so aren't a good choice if you want to stay compatible with as many programs and setups as possible. so long, Hias

While the international character set added a couple characters from various languages it was far from complete and it missed some important characters - IIRC Ä and ß for German language. So word processors (eg StarTexter) and other programs in the german speaking area often used their own character set anyways. so long, Hias

There's no easy way to support RAM boards. The highspeed SIO code at $CC00-$CFFF is part of the OS and has to be present on powerup - otherwise you won't be able to boot. You could probably fiddle around with a diagnostic cart that puts the code at $CC00 very early after powerup and then disables itself, but you still need to have the patched OS at $E000-FFFF which won't work without the cart. So, in general, the answer is no, you need ROM at $Cxxx so long, Hias

@reifsnyderb if all you need is a 16k ROM file then you are fully set. Using 16k ROM files as input (OS A/B or XL/XE OS) is supported in patchrom versions since ages (eg the latest 1.30 release on my website) - only 10k input file support is a new feature. I only added the option to disable patching the keyboard handler as a safety measure, in the extremely rare case a program uses the same keystrokes and the patched handler would interfere with it, but I'm not aware of any issues or anyone even using that option and running a patched OS without patched keyboard handler. With a stock 1050 connected everything should work as before, the only difference is you get a short delay on powerup (more precisely each first access to a disk drive) when the patched SIO driver is probing for highspeed support in the drive (this is done with SIO sounds muted so it'll appear just as a short delay, though actually the SIO bus is busy). If you have a SIO2PC/SIO2SD/SDrive attached you should get highspeed right away on boot (and as Ultraspeed SIO is the very first protocol being probed, and that's what SIO emulators usually support, this will happen with almost no noticeable delay). so long, Hias

I just noticed I haven't done an official release yet with the 10k OS A/B functionality and while it's in the source code repo since almost 3 years https://github.com/HiassofT/highspeed-sio and I posted some development versions of patchrom it might not be easy to find the latest version of patchrom.exe - so I'm attaching it here. so long, Hias hipatch-220314.zip

Forgot to add: input has to be a 10k file (mathpack plus OS). so long, Hias

@reifsnyderb no need to modify anything, this is already supported. eg just use patchrom on a PC to create a patched OS A or B version and cut the 16k ROM file into C000-CFFF and E000-FFFF OS parts (first 4k and last 8k of it). so long, Hias

Sure, For example a very popular DOS here in Europe was Turbo DOS XL/XE. Despite it's name it works very well with an Atari 800 as well. It supports ultraspeed drives (Happy/Speedy), XF551 and the 1050 Turbo. To save memory you could choose which high speed drivers should be included in the initializer software which wrote the DOS to the disk. https://atariwiki.org/wiki/Wiki.jsp?page=Turbo-DOS It's command-line based, supports batch files etc and uses DOS 2.x SD/ED/DD format - it's still my favourite DOS for Atari computers. so long, Hias

Don't worry too much about about optimizing for storage space or speed at this point, you can care about it later, at this point it's more important that you get your transformation pipeline right and it's also very helpful to have the intermediate transforms available as files so you can easily perform manual checks by just analyzing the files (you also may need that option later to verify if your transformation was correct or not). As a general rule of thumb keep in mind that every transformation is usually lossy and may lead to false positives - eg when chosing to use a hash instead of an actual data compare you have the problem of potential hash collisions. Checking against file size plus a known good cryptographic hash (eg SHA-256 or SHA-512) is usually fine (rsync uses file size plus MD5 IIRC in checksum mode). In order to determine which transformations are helpful to get better matches it's good practice to start with quick prototyping - use whatever tools you have available, use your favourite (scripting) language and implement a quick prototype to verify your theory - it doesn't matter much if you store the check results in a hash table, a dictionary, a sqlite database or whatever or if you create 10 times the original data size of temporary files on your SSD - the important thing is you can verify if the approach was good or not (you can apply that just to a subset of the whole collection to speed things up). Eg store all intermediate transformations in a parallel directory structure, where you create a directory for every source file in your collection. 6GB of input isn't much these days (modern webbrowsers need about that amount of RAM with a dozen or two tabs open), storage space on media is even less of a problem unless you need 100-1000 times the amount of it, so don't be afraid to use it if you have space available and it helps you. For ATR files you may use a simple transformation like stripping off the header - then you have the pure data sectors and might then get a match against XFD files (which are basically that, pure sector data without the ATR header). To match individual files inside an ATR against COM/EXE/XEX you may extract those files from the ATR (eg into an extract subdir in the parallel directory structure). As you can imagine this transform is very lossy - you not only loose the info from the ATR header, and the boot sectors (which are typically part of DOS.SYS on normal DOS disks) and all unused sectors - but that may not even matter, because you may find matches of the individual files against other files in your collection (or other ATRs). It'll be an incremental process, you can think of other transformations (eg zeroing out sectors in ATRs that are marked as unused in the VTOC or zeroing out entries at the end of the directory that have the deleted flag set to undo "user saved and later deleted some file" stuff), adding more heuristics (eg compare the file names/sizes/hashes on one ATR with another and flag up if only additional files are present on one ATR) etc. Once you've found out which transformations and checks are helpful to find duplicates you can then start optimizing ig (eg remove temporary disk storage after processing or read data directly from the files etc). BTW: If you store results in your database it's also very important to store information about the transformations you applied so you can verify how you got to the match (which is very important in case of false-positive matches - a wrong tranformation chain of PACMAN.ROM might lead to a match against DONKEYKONG.ROM and that's probably not what you want 🙂 so long, Hias

I've been using atr2unix to extract DOS2.x/MyDOS ATRs for ages, modified it a little bit to make it more robust (it ignores the inverse bit of filenames, invalid files starting at sector 0 and simply skip files that couldn't be written) and it's been doing a good job so far. I recently posted my patched version here: Comparing COM/EXE/XEX files will become a huge PITA though as various collectors decided to process the file with compressors of all sorts (and sometimes they even messed up, eg when dropping all zero-blocks from a file but not adding a clear-memory routine in an init block before - so when loading from DOS which may have remnants of DUP.SYS and other stuff in memory the programs will break). I just checked the homesoft disk 001 that I downloaded about 5 years ago and it contains different files than the one currently available. eg old ZYBEX.COM: # ataricom ZYBEX.COM ataricom 0.30-221009 (c) 2008-2022 Matthias Reichl <hias@horus.com> block 1: d301-d301 (bytes: 1, offset: 6) block 2: 03f8-03f8 (bytes: 1, offset: 11) block 3: 0244-0244 (bytes: 1, offset: 16) block 4: 1d49-9bff (bytes: 32439, offset: 21) block 5: a000-bbff (bytes: 7168, offset: 32464) block 6: 022f-022f (bytes: 1, offset: 39636) block 7: d400-d400 (bytes: 1, offset: 39641) block 8: 9c00-9fff (bytes: 1024, offset: 39646) block 9: bc00-bfff (bytes: 1024, offset: 40674) block 10: 02e2-02e3 (bytes: 2, offset: 41702) INIT: 1d49 vs new ZYBEX.COM: # ataricom ZYBEX.COM ataricom 0.30-221009 (c) 2008-2022 Matthias Reichl <hias@horus.com> block 1: 2020-203a (bytes: 27, offset: 6) block 2: 0244-0244 (bytes: 1, offset: 37) block 3: 730d-77ff (bytes: 1267, offset: 42) block 4: 02e2-02e3 (bytes: 2, offset: 1313) INIT: 776d block 5: 227e-7722 (bytes: 21669, offset: 1319) block 6: 85c1-9b2a (bytes: 5482, offset: 22992) block 7: a62d-bbff (bytes: 5587, offset: 28478) block 8: 02e2-02e3 (bytes: 2, offset: 34069) INIT: 7723 And that's just from a single source, atari.online.pl archive has another dozen Zybex XEXs files... so long, Hias

This sounds a lot like the old brownout fuse issue - if it's not programmed correctly the firmware in the eeprom could be trashed on power up/down and you only get the single "black bar" line when that happened. Solution: reprogram the ATMEL with latest firmware and set the fuse bits correctly (there should be plenty of old topics about that issue with info about what to do here on the forum). so long, Hias

Open a shell, change to the directory where the RespeQt binary is located and run "ldd RespeQt" - this will show you which libraries it needs. If any of them show up as "not found" then install them via the package manager - otherwise RespeQt won't start. It would have been better if respeqt had been distributed as a proper deb package then all required libraries would have been installed automatically (Qt really is a beast in that aspect). so long, Hias

I'm using good old atr2unix to extract ATRs, it works fine for my purposes so I saw no need to reinvent the wheel with my own software. https://www.crowcastle.net/preston/atari/atr2unix-1.2.c I've adapted it a little bit so it ignores the inverse bit in filenames and skips files with starting sector 0. You'll find that in some disk images where creators thought a fancy directory listing with additional info would be nice - but original atr2unix tripped badly over that. I've attached a ZIP with the patched source code and a compiled win32 exe of it. so long, Hias atr2unix.zip