Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


HiassofT last won the day on November 10 2011

HiassofT had the most liked content!

Community Reputation

689 Excellent

About HiassofT

  • Rank

Contact / Social Media

Profile Information

  • Gender
  • Location
    Salzburg, Austria

Recent Profile Visitors

21,320 profile views
  1. 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
  2. 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
  3. /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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. The U1MB PBI code would be a different route (I guess the "All" SIO devices selection should do it), the code I added is for patched XL OS ROMs. Just use the patchrom.exe in the ZIP to create a patched XL OS and install it in one of the U1MB OS slots if you want to give it a try. so long, Hias
  • Create New...