HiassofT

@ebiguy I'm pretty sure I tested the fix back then and it worked fine. @foft the problem seems to be that RespeQt's default branch is set to "develop" so a simple git clone gives you that - and that branch doesn't include the fix (it's in master). you can either do a "git checkout origin/master" in the cloned tree or tell git clone to initially give you master instead of develop with "git clone -b master https://github.com/RespeQt/RespeQt.git" so long, Hias

atarixfer uses RTS by default (that's the signal used by standard 1050-2-PC cables). APE prosystem uses DTR. You don't need CTS for atarixfer, but you'd need that when using atariserver with a SIO2PC cable. Don't forget to supply 5V to the 1050-2-PC cable though. so long, Hias

1050-2-PC mode needs a command line (usually driven by RTS or DTR) and 5V/VCC/Ready in addition to RxD, TxD and GND connected to the 1050. The 5V/Ready pin is important, if 5V isn't present there the 1050 will play dead. On most older 1050-2-PC interfaces connecting to PC serial ports you had to provide the 5V externally as it's not available from the serial port and deriving it from the control lines of the serial port is problematic. On the RPi it's easiest to just use 3.3V<->5V level shifters to connect to the 1050 or Atari, the cheap 4-way bidirectional FET level shifters work fine - see README.RPi in atarisio (also note that you need to add the overlays to get RTS and CTS on the RPi GPIO pins). Your serial port addon board/hat sounds like it may contain a RS232 line driver, converting from 3.3V to the +/-12V RS232 levels. If it doesn't provide RTS and CTS signals by default it may be tricky to rewire it to support these. Also going from 3V on the RPi to 12V on RS232 and then back to 5V in the 1050-2-PC interface adds more points where things could go wrong (eg a slow line driver that's then preventing reliable operations) - better avoid that. If you want an off-the-shelve solution I'd recommend buying the SIO2PC/1050-2-PC USB dual adapter from Lotharek. It works just fine with atariserver/atarixfer (see README.lotharek for details on how to switch it to 1050-2-PC mode). Using an old, serial 1050-2-PC cable with a FTDI based USB-serial adapter works, too, if you externally provide 5V. USB-serial adapters with other chips is hit-and-miss (in general more miss than hit), as they often don't support signalling when the transmission has finished (which is essential in 1050-2-PC mode). SIO2PC mode is more forgiving in that aspect. so long, Hias

I haven't got around to update the documentation with the changes I did in the 3.11 (beta) versions. Please have a look at the "ChangeLog.txt" in the latest software ZIP - currently https://www.horus.com/~hias/freezer/software/beta/freezer-software-200413.zip (see also below). The majority of the documentation is still valid, only very few things changed (eg the "M" memory map command) and most of the new additions like the CartEmu presets should be pretty self-expanatory (I hope). One difference of the new Panos Freezer that might not be too obvious is that it uses a different flash chip than the previous versions. This chip has a smaller internal block size (4k instead of 64k), which is a good thing as it allows you to separately reflash each 8k bank and you no longer need to worry about the previous 64k restriction. Here's the list of changes from the 2020-04-13 changelog: BTW: the current 3.11 beta software versions also work on the older 2005 and 2011 Freezer models. so long, Hias

Simple, non-technical explanation: without a proper power supply anything can happen and it's pure luck if something works or not. A bit more technical/detailed: glitches in the power rail may lead to shifts in the thresholds of the input-stage of circuits. Or internal circuitry in ICs, like flip-flops, may loose their state. Glitches on the power rail also usually also affect the output stage of ICs and produce glitchy output. Input stages of other circuits, even if their power source is stable, react differently to those glitches as the exact switching point between low and high isn't specified but dependent on manufacturing processes and variations in silicon etc. So, what possibly could have happened is that a short glitch on the power rail caused a glitch on the PHI2 signal which was "noticed" on one CPLD (your problematic freezer) and lead to double-clocking of the Freezer state machine, but not on the other CPLD. A glitch on the reset input at the wrong time could have caused similar fatal effects. There are a lot of other effects that can happen due to short or longer power glitches and one common thing of these is that they are nasty and can be hard to diagnose from the software/logic side. So, in case of odd issues (no matter if it's on a PC, an old Atari, a router or some other system) it's always a good idea to check all external and internal power rails with a scope. Switch-mode power supplies are the norm nowadays so a standard DMM won't do a job and may show a stable 5V or 3.3V supply. But a scope will reveal if there's ripple/glitches on the rail, eg due to aging capacitors. so long, Hias

Ah, bad/insufficient power makes perfect sense, that's about the number one cause of most odd/unexplainable/intermittent issues. so long, Hias

Very puzzling. I had expected to see issues from the production tool as well - not sure why flash and RAM access seem to be fine but freezing doesn't work on this one XE model. I can't remember ever seeing such an issue combination. A shot in the dark: if you have a scope it might be interesting to probe the PHI2 and the shortened PHI2 signals (the latter is on pin 13 of the HCT123), both on the working freezer and the non-working one when plugged into the problematic XE. The falling edge of the shortened PHI2 should be about 50ns before the falling edge of PHI2. so long, Hias

Can you try flashing the Freezer to (latest version) stock firmware with the production tool? https://www.horus.com/~hias/tmp/prodtool-200726.zip This will wipe the whole flash memory and also perform some basic Freezer RAM tests. Just set the flash write and ramdisk switch to "on", all other switches to "off" position and boot the ATR. If something's not quite right then you should get some error messages on screen - a screenshot of that could help narrowing down if there's some issue with flash or RAM. so long, Hias

-k disables hotkey support - I usually have that enabled. Especially SHIFT+CONTROL+S is quite handy if some program trampled over the stack area or if you later power up/enable another drive. So far no one reported compatibility issues with hotkey support enabled. * hotkeys: The keyboard IRQ routine of the OS is patched and you can control the SIO patch using various keystrokes: SHIFT+CONTROL+S Clear SIO speed table and enable highspeed SIO SHIFT+CONTROL+N Disable highspeed SIO (normal speed) SHIFT+CONTROL+H Enable highspeed SIO SHIFT+CONTROL+DEL Coldstart Atari so long, Hias

I had a quick go at it and added options to only verify and fix 16k XL/XE OS ROM checksums to my patchrom tool. I've attached a win32 console executable. Run "patchrom -c atari.rom" to verify the ROM checksums or "patchrom -C atari.rom fixed.rom" to save the ROM with fixed checksums to "fixed.rom" so long, Hias patchrom-133.zip

Have a look at the "patchrom.cpp" (and "patchrom.h") file of my highspeed SIO patch, esp the update_rom_csum function (and the get_csum1/2 and update_checksum_block functions it calls): https://github.com/HiassofT/highspeed-sio/blob/master/patchrom.cpp#L135 so long, Hias

Thanks for the quick merge! So far only @Tempest seems to have been affected by the issue, we were PM'ing the last couple of days trying to figure out why his cart stopped working. Took us a while to figure out that RespeQt was the culprit. so long, Hias

A very important warning: don't use RespeQt versions from late 2018 up to 5.3 when flashing your The!Cart. These versions have broken 8k-sector-size ATR handling and will soft-brick your cart - you can revive them by reflashing with "FLASH.COM" from "thecart.atr" though (latest version is here https://www.horus.com/~hias/thecart/software/thecart-software-170924.zip) RespeQt version 4 from here https://github.com/ebiguy/RespeQt/releases (and previous versions) are working properly. I've opened a PR with a fix, so future RespeQt versions should be safe to use again https://github.com/RespeQt/RespeQt/pull/6 so long, Hias

/dev/atarisio0 is for using 16550/16C950 UARTs (on-board or on PCI/PCIe) with the AtariSIO kernel driver. If you are using a USB SIO2PC adapter it's not relevant to you. If you use a 16550/16C950 UART that driver will in general work better than the /dev/ttySx support in AspeQt/RespeQt (and result in lower system load). I've created AtariSIO almost 20 years ago, when "real" serial ports were the norm and USB adapters were exotic, and still support it. In the meanwhile it can also deal with USB adapters and other serial ports and you can also use it with eg a Lotharek dual 1050-2-PC/SIO2PC USB adapter or a Raspberry Pi to directly access a 1050 or XF551 in 1050-2-PC mode. You can find more info about AtariSIO and download it here: https://www.horus.com/~hias/atari/#atarisio so long, Hias

Just to be clear: I don't recommend getting an old boat anchor, I only mentioned that as a last resort in case of a really limited budget as the other options in the < 350 USD range aren't too great either. Quality-wise you can't count much on it, these are 25-40 year old things that can break down any time and may be unrepariable. And feature-wise the current hobbyist scopes also have a lot more to offer. Features in used LeCroy, R&S or HP/Agilent (digital) scopes may be better but good luck finding them for 200-300 USD ? so long, Hias

In this case it's best to look out for a used scope in the <= 70 USD range and hope it'll keep working for some time. If it breaks down you won't have lost too much money. To repair an analog scope you'd need another scope (chicken, egg...) and lots of the mid/late 1980ies and later models contain custom parts that are unobtainable (eg the Tek 2465 etc). Digital scopes are basically unrepairable, unless it's some very basic thing like a broken cap in the power supply. OTOH new scopes in the 200-300 USD range aren't too attractive by today's standards and sooner or later you may realize you really miss the features that would have been present in the 350 USD models. As these cheap scopes have almost no value on the second-hand market (everyone knows about their limitations) you'd have to completely write off the money spent on it if you want to move on to a better model or just keep using it. Buy cheap, buy twice. so long, Hias

This is a really bare bone digital scope and I wouldn't recommend it unless your budget is really tight and you can get it for 50 - max 100 USD. The ~350 baseline set by the mentioned Rigol and Siglent hobbyists scopes is where I'd start looking as they offer a lot more value for the money than the older/cheaper scopes (like the Hantek or eg the Rigol DS1052E which seems still to be available for about 250 USD). With these newer/current scopes you'll get higher waveform update rates which are not only helpful to catch occasional glitches but are only used to do intensity graded display. I.e. you get an "analog scope like" display where glitches/rarer occurring waveforms are displayed in darker color. That's enormously helpful to get a quick impression how the signal looks like. You'll miss that with the Hantek and older Rigol, they'd just jump between the waveforms (or might not even catch that every tenth time the signal only reaches 3V instead of 5V). Large sampling memory (several megpoints compared to a few kpoints), especially in combination with segmented memory is really helpful to capture a longer sequence and then zoom in. Or, with segmented memory, record a bunch of traces and then check into the one you are interested in (which might be eg the 5th or 6th occurrence of the trigger, not the first or the last). You get a really nice choice of advanced triggering features that the simpler/older scopes don't offer. Some of them are really helpful as well as you can trigger for setup/hold violations, occasional glitches etc. Ah, and also helpful are the various builtin decoders (RS232, I2C, SPI). While these decoders are a bit bare-bone compared to the one of (PC-based) logic analyzers they are still quite usable and you can quickly check eg which command frame your Atari sent to a disk drive etc. so long, Hias

All Rigol DS1000 and 2000A models ship with all options included. For more bandwidth either buy the higher specced models or search the eevblog forum for riglol so long, Hias

Depends on what you'd like to do with it but for general (including digital / Atari) stuff the Rigol DS1054Z might be a good choice (this is also what phaeron seems to be using, judging from the screenshots). Costs about 330 USD new (just checked tequipment site) and 4 channels are really helpful when doing digital stuff. I'd stay away from old analog scopes (unless you have a really specific requirement, eg 500MHz+ bandwidth at no budget), to diagnose digital stuff you really want something with (segmented) storage. Standalone scopes (i.e. with their own screen and real knobs to turn) are also a lot easier and more intuitive to use than the PC based ones IMO (they may offer other features, but the better ones like the picoscopes aren't too cheap). I'm using a Rigol MSO2072A here (2ch analog plus 16 digital) here and I'm quite satisfied with it. so long, Hias

I was more thinking about the relocatable CIO driver being loadable from fujinet so applications can use that instead of having to deal with SIO calls. so long, Hias

For non-SDX operations (think also about a bootable ATR/disk that just wants to use your device) it might be a good idea to provide a relocated driver code from fujinet via some SIO calls. The programs (or simple COM / AUTORUN.SYS files to install the driver to fixed locations) know best which memory location is available and then just get the driver code from there. The 1050 Speedy did this to provide a highspeed SIO code and I've implemented the same in AtariSIO, providing my highspeed SIO code. That's done with 2 SIO calls: the first one ($68) just returns 2 bytes, the total length of the code. The second one ($69) loads code from the drive, relocated to the address in DAUX. So the caller just needs to set DBUF=DAUX and DLEN to the result from the previous call and then has a $E459 replacement at the specified address. A similar approach for fujinet could look like the caller then doing a "JSR MYLOADADDRESS" to let the code install itself into HATABS (or just provide the handler table at the very beginning). To do the relocation I used another very simple (but a bit tedious) approach. I assemble my code for some fixed location (I used $1000) and provide the length of the relocation table at the very end and right before that a list of absolute locations in the code that need to be relocated. See eg https://github.com/HiassofT/highspeed-sio/blob/master/hisio.src#L115-L152 RELOC .WORD ?ABS01+1, ?ABS02+1, ?ABS03+1, ?ABS04+1, ?ABS05+1 ... RLEN .WORD *-RELOC The tedious part is that I manually need to list every location in my code that contains addresses to be relocated - so I put those ?ABS01... labels before those. eg https://github.com/HiassofT/highspeed-sio/blob/master/hisiodet.src#L31 ?ABS01 STA SPEEDTB,X Note that with this simple approach you have to avoid using 'LDA #<MYADR / LDA #>MYADR' as that would be a PITA to handle. Using 'LDA MYLOC / LDA MYLOC+1' with MYLOC containing a 'WORD MYADR' works fine though (all three locations need to be relocated though). While being a bit tedious and error prone the nice thing about this approach is that it works with every assembler. Back then when I wrote the code there weren't many alternatives and dealing with ca65's object format seemed a lot more troublesome. The relocation code is quite simple, it checks the last 2 bytes of the driver binary to find out the relocation table begins (and where the driver code ends), and then adjusts all the addresses in the table accordingly. To get the offset in the driver binary that have to be relocated it first needs to substract the driver start address ($1000) from the values in the relocation table and then adjust the word at that offset by RELOC_DEST_START-DRIVER_START. There are several other possibilities how you can handle that (for SDX you'd probably better use it's native relocatable format), just wanted to show a simple approach that works without needing sophisticated tools. so long, Hias

A rather simple solution that should cover a lot of cases is using a (configurable) timeout. This is how I implemented the printer backend in AtariSIO some time ago. I used a rather simple approach: if there was no SIO activity for 15 seconds it'd flush out the printer data. Sure, that won't cover every situation but it worked really nicely for the stuff I mainly did (like sending program listings to the printer). so long, Hias

You forgot lpd in your list ? OK, just kidding. More seriously, nowadays IPP should be the way to go. It's an open standard (see RFCs 8010 and 8011), based on http and for a minimal IPP client it should be enough to implement the Print-Job message (which creates a print job and sends the document data in a single call). (De-)serializing the binary IPP messages requires a bit of leg-work but it's not too hard, there's even a pure javascript implementation https://github.com/williamkapke/ipp A lot of network printers nowadays can handle PDF natively, so if you already have a PDF renderer you should be fine. I wouldn't care too much about all the older and/or proprietary protocols or standards, they'd be a huge PITA. For those situations a Raspberry Pi running cups to handle the translation looks like a better option. so long, Hias

I've been using git for quite a long time now, really like it, imported most of my old svn trees with Atari projects into git and also push some of them to github. Main reason for doing that is that I wanted to give people easy access to my git trees and I was too lazy to setup cgit on the server I use as a centralized storage for most of my git trees. The beauty of git is that you can easily add as many remotes as you like and decide what you push to/pull from them. About two months ago I installed gitlab on one of the RPi4s sitting unused on the shelve and setup a CI to automatically build one of my Atari projects in a docker container whenever I pushed changes to it. This was more for fun and about playing with GitLab CI though. I'm using github with a couple of other open source projects (LibreELEC, Raspberry Pi kernel) and while the general project workflow functions (like pull requests, reviews etc) are quite OK the github web UI has some really annoying quirks: One of it is that the commits (eg in a pull request) are displayed ordered by author date, not commit date. This really creates a mess if you picked/merged commits in a very specific order. The online editing functions are also something you should better not use, as it'll create a new commit on each change. Not sure if there's some easy way to squash that via the webui. Most of the time I work with git on the command line as I can easily fetch github PRs into local branches (or just fetch the branch of the user PR'ing the change) to review/test them, for LibreELEC I use a rather simple shell script to automatically do an octopus merge of all my feature branches and other remote branches I use/need for testing into a test branch - and then build and test with that. When I'm fine with my local feature branch(es) I push the to my github repo and PR them for review - and then enter the usual comment/fixup/squash/rebase/... cycle. so long, Hias

Thanks, I remember the discussions about that back then. The main problem with implementing that is that I simply don't have enough code space left in ROM - I'm down to about 16 unused bytes and I don't really want to drop the keyboard patch like you did in the SIO2BT patch. I think the documented entry point is a pretty good compromise. It won't interfere with non-disk devices (throwing get speed byte and get status commands using various highspeed protocols at standard SIO devices like printers only slow things down), only needs 3 extra bytes in code space for the entry point JMP and gives software full control over what's going to transmitted via SIO. This entry point can also be used to deliberately bypass the OS SIO when you want to make sure the command really gets transmitted at the speed/protocol you want without any autodetection happening in the background and without PBI devices possibly redirecting/modifying/... it. so long, Hias