Jump to content

HiassofT

Members
  • Content Count

    1,192
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by HiassofT

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. @tschak909 could you give this highspeed patch version a try? https://www.horus.com/~hias/tmp/hipatch-200428.zip I've implemented the entry point at $CFED as described above. The patch includes a "Hias 1.32" version identifier so you can check for the presence of the entry point. I included some info in README.txt and also a "diag-entry.src" file that makes use of the entry point (I've used that for testing here). so long, Hias
  14. Yes, the theoretical limit of the OS SIO code would be 65535 bytes. The practical limit is about 47k as the OS SIO code needs to store the data somewhere (eg $0400-$BFFF). I haven't tried doing such large transfers yet so I'm not 100% sure if it really works or if there might be a bug in the OS SIO code. However I'm doing 8k transfers in the The!Cart flasher and that works just fine. so long, Hias
  15. I was thinking about a timer in fujinet, but it seems you already have things working so that's a bit moot now BTW: you may need to be prepared for the proceed/interrupt getting occasionally "lost". Anything that reads from PORTA/PORTB (eg joystick handling in VBI or programs fiddling with PORTB to access extended memory) will clear the interrupt bit in PACTL/PBCTL. Even if a program has IRQs enabled things may get missed. So having a timer in fujinet code that creates periodic notifications may be a good thing, eventually the notification should get through. so long, Hias
  16. Not easily. Extending the code would be no big problem but then it won't fit into the very limited ROM space. However it should be possible to provide an official entry point to the highspeed code in ROM (that bypasses the device check). I already include a unique signature with version and date (eg "Hias 1.31 200411" in my current testing version) in the last 16 bytes ($CFF0-$CFFF) so you can check for presence of my highspeed code in ROM, verify that the version is recent enough (eg 1.31 and below won't have that entry point) and then use it (at your own risk I was thinking about "set A to the desired highspeed variant, eg 3 for pokey divisor 3", then call the entry point like standard SIO. $CFED might be a good location for that entry point but I'll need to think about that a bit and also re-shuffle things a bit ($CFED is currently used, EE and EF seem to be free). so long, Hias
  17. I can't remember if I played with PIA interrupts (interrupt and proceed lines on SIO) before, glancing through the PIA datasheet and Atari OS source code it should be pretty straight forward. If PIA is configured to handle interrupts, i.e. bit 5 of PACTL/PBCTL set to 0 (input), bit 4 to edge polarity and bit 3 to 1 (IRQ enable) then PIA will assert the IRQA/B lines (which are connected to the 6502's IRQ input) whenever the configured edge is detected. The IRQ line will stay asserted until PORTA/B are read. So the PIA acts as a latch, translating edge-triggered interrupts to level triggered ones. The IRQ handler in the OS already takes care of that, it checks bit 7 of PACTL/PBCTL (which signals that the PIA asserted the IRQ), read PORTA/B (which clears that bit and deasserts IRQA/B) and then calls the corresponding interrupt vectors VPRCED ($202) or VINTER ($204) which by default do nothing (PLA/RTI). So you can simply hook into these interrupt vectors and for example set a flag in memory (LDA #1, STA GOT_IRQ, PLA, RTI) which you can then check via a CIO/XIO call from your program. It might be best to let that CIO/XIO call auto-clear the bit, or you could do that when you issue the SIO commands to react on the interrupt condition (eg retrieve the receive buffer). As it might take the program a bit to check for IRQ assertion (it could be busy doing something else, or might only check every frame or so) and also the whole SIO roundtrip takes quite a bit of time it might be best to rate-limit generation generation of the interrupt edges in fujinet. eg when some data is available for the first time generate a 50us or so low pulse on the SIO interrupt or proceed line. I chose 50us because that's about the length of a bit at standard ~19kbit rate and that should be received well on the Atari side even if there's capacitive load on the SIO lines. Then repeatedly check eg every 100ms or so if there's still data in the buffer and if yes generate another pulse. It might be easiest to implement that via a timer (if you have one available), if the timer is running it means interrupt conditions are already sent, if it's not running then create an edge and start the timer. The timer routine can then simply disable itself when eg the whole receive buffer has been retrieved. so long, Hias
  18. Ahem, you seem to suggest hooking up about +/-9-12V (with inverted polarity) from the USB-serial cable directly to the Atari. That would be a really, really bad idea. Only breakout boards or adapters with du-pont style connectors are safe to hook up to the Atari, and even then you need to make sure it's a 5V one, not a 3.3V one. so long, Hias
  19. I don't have a Retrotink but I'm rather sure the cut off margins come from the TV's overscan settings / processing. My TV (LG 55C8) has a "Just Scan" setting to disable overscan, so eg all 1920x1080 pixels are displayed (easy to verify with a RPi/PC/... hooked up), but this doesn't apply to the SD modes (720x480, 720x576) which are always displayed with overscan (so part of the image cropped off). so long, Hias
  20. Thanks, Indus GT is working fine again in test31! I did some more tests and it seems the issues in test28-30 were triggered by MFM disks (I had a 180k DD ATR in the drive), 90k/FM disks worked fine. I tested with stock XL/XE OS rev 2, no other specific options, cold booting only the Atari didn't work either. Log in the debugger showed that the drive stepped fine on powerup but the last line was the FDC switching to FM FDC: Physical track is now 0.0 DISKEMU: Stepper phases now: 0 DISKEMU: Stepper phases now: 8 DISKEMU: Stepper phases now: 1 DISKEMU: Stepper phases now: 8 DISKEMU: Stepper phases now: 1 DISKEMU: Stepper phases now: 0 FDC: Density encoding now set to FM With test31 the drive is now switching correctly to MFM: DISKEMU: Stepper phases now: 1 DISKEMU: Stepper phases now: 0 FDC: Density encoding now set to FM FDC: Density encoding now set to MFM ... so long, Hias
  21. Thanks a lot for testing, good to know it's working fine on real hardware! I haven't done much regression testing either yet, that's tedious work as I also need to verify that all projects where I embed the highspeed code work fine (I need to make sure the receive loop doesn't cross a page boundary as that'd screw up divisor 0 timing). I had a go at testing indus super synchromesh with Altirra and it seems the $58 (upload/execute) command needs blacklisting from highspeed ($22 probably too), otherwise GTSYNC won't properly execute if it was run before (eg boot DOS XL, on initial drive+computer cold start the highspeed code won't detect super synchromesh and use standard SIO, then reboot the Atari after DOSXL executed GTSYNC ON, highspeed code now uses synchromesh but GTSYNC ON doesn't work). Unfortunately I'm out of code space to add the blacklisting - and as half-broken drive support is a lot worse than no support it means I probably won't add the indus mode. so long, Hias
  22. @phaeron it looks like Indus full drive emulation is broken in test28 and newer. test27 is working fine but with test28/29/30 there's no response from the drive on boot. so long, Hias
  23. Can this be done via one of the indus.sys / loader programs or does it require a ROM upgrade? If it's via loader program than it shouldn't be too hard for one of the Z80 programmers to change that to return $06 on the get speed byte $3f command and change the IO code to use the same timing as super synchromesh. so long, Hias
  24. This was a good one 🙂 I don't have an Indus drive and testing without real hardware is tricky (yeah, I could check if Altirra could help here, but that's still not quite the same as real HW where I could hook up a scope). I also think a different approach to the Indus issue might be better: if people don't want to install the ultraspeed firmware ROM then it may be beneficial to alter the code uploaded by indus.sys to make the drive fully XF551 compatible (or - if possible - US or 1050 Turbo compatible). This would result in instant compatibility with all existing highspeed solutions/codes without having to alter each one of them to the almost-but-actually-not-quite-xf551-compatible (super) synchromesh protocol. so long, Hias
  25. In the 1.31 200411 version linked above the location in the ROM is CDCB: CDCA A9 10 LDA #$10 CDCC 8D 04 D2 STA $D204 so long, Hias
×
×
  • Create New...