Jump to content

HiassofT

Members
  • Content Count

    1,244
  • Joined

  • Last visited

  • Days Won

    1

HiassofT last won the day on November 10 2011

HiassofT had the most liked content!

Community Reputation

766 Excellent

About HiassofT

  • Rank
    Stargunner

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Salzburg, Austria

Recent Profile Visitors

22,151 profile views
  1. Not for mads or ca65 but I did that for atasm a while ago. I've attached my sources, see Makefile for atasm command line flags used to build (the sources can both build 3.10 and 3.00). so long, Hias duplicator-3.00-3.10-atasm.zip
  2. Thanks a lot for refreshing my memory, I had completely forgotten about that! so long, Hias
  3. Not 100% sure where you got 38SF040 from, we used an SST 39SF040. SST39SF040-70-4C-NHE would be the full part number (industrial temperature range,I instead of C, should work fine too but isn't needed) so long, Hias
  4. Just be careful, there's a lot of scammers and counterfeit chips out there these days. read eg https://www.wsj.com/articles/chip-shortage-has-spawned-a-surplus-of-fraudsters-and-fake-parts-11626255002 In general I'd recommend ordering Xilinx CPLDs (and other parts) from the authorized distributors. Mouser, Digikey, Farnell etc all show (dummy) availability dates of in about half a year to a year, but they might get some stock a lot earlier (or maybe not, but you also don't risk paying outrageous prices or getting fakes). No, you have to flash the ROM before (at least the config and one mega speedy slot). If you later trash the config slot or the whole flash you'll also need to remove the flash and program it with an EPROM programmer - that's the reason why we went for a socketed PLCC flash instead of TSOP. so long, Hias
  5. @guus.assmann should have the latest PCB files that were used for production. I have some files here but I'm not 100% sure if they are really the final version. so long, Hias
  6. Absolutely - or maybe even more. My comment wasn't meant too seriously 🙂 so long, Hias
  7. Maybe it's time to go oldschool and switch back to good old TTL chips again 🙂 Or maybe not, even those are low on stock ATM. Damn crisis... so long, Hias
  8. @apc The RPi UART (/dev/ttyAMA0, the miniuart ttyS0 is better avoided) is pretty straight forward to use and works very well. For non-standard speeds I use the termios2 ioctls - linux supports these for ages (but IIRC glibc still doesn't include the definitions so you have to provide them locally - see Termios2.h) and let the kernel drivers choose the right settings (possibly fractional divisors etc) to configure the desired baudrate. The old, often used approach with TIOCSSERIAL / custom_divisor is better to be avoided, too. so long, Hias
  9. Simply speaking: Nir was very lucky it worked without this particular cart. In general it won't work though. so long, Hias
  10. This is expected. You have to make sure you use the same hardware setup (OS, RAM upgrade, cart, right bank in case of bankswitching carts etc) when you restore a snapshot as you used when saving the snapshot. Freezing with a cart present and restoring without may work at very rare occasions, sometimes you have to manually change GINTLK to prevent a hard-lockup on restore, but if some code in the cart tries to trash the memory contents in the cart area you are pretty much out of luck (well, you could patch/crack that but then it's better to use a cracked XEX as you won't have the hassles with that). so long, Hias
  11. You can find that eg in the Turbo Freezer 2005 schematic (it's in the lower right corner) https://www.horus.com/~hias/freezer/turbo-freezer-2005/hardware/schematics-xl.pdf 74HCT123 with 5k6 and 33pF will work, too, but keep in mind that these '123 aren't exactly precision devices (esp in the configuration we use them here, it's also mentioned in the datasheet) so if in doubt better check PHI2 vs shortened PHI2 with a scope (and if it's not short enough use a lower value resistor or pot). Also keep in mind that this only affects writes, but if rogue reads can alter state in a device/chip (eg checking for toggle-bit programming done in a flash chip or reading data from an IDE device) this won't help - in this case you need to latch address signals or shorten reads (the latter isn't recommended, but usually works well enough and the simple "stabilizing PHI2" mod with the wire on LS08 in the Atari will do it just fine). so long, Hias
  12. Of course it will never work to do the programming from the same machine. During programming all I/Os are tri-stated so you'll have no MMU in your system. Using another Atari to program the CPLD (instead of using a PC, impact and xilinx cable) should be doable though. My motivation for looking into that back then when I created the 2005 Turbo Freezer was that it would allow us to supply a very cheap, passive, joystick cable together with the Freezer and people would have an easy possibility to update the logic (and as the Freezer is an external device it would even have been possible from the same machine). Signal edges ruined that (rise/fall times were way above the maximum specced values), other than that it worked fine. I still think it could be doable with some active adapter, maybe similar to the PIC programmer. The XC95144XL is used on quite a bunch of Atari upgrades so having a possibility to update that from an/another Atari with a cheap joystick port solution could be interesting for lots of users so this isn't a too stupid idea at all. so long, Hias
  13. Seems I had a too quick glance at the xapp058 code, the readByte function in ports.c already seems to stream from the input file (using fgetc). So probably only the usual cc65 porting will be needed, i.e. making sure temporary data structures fit into memory and data types are correct. so long, Hias
  14. In fact, they do. Quick search turned up xapp058: https://www.xilinx.com/support/documentation/application_notes/xapp058.pdf https://www.xilinx.com/support/documentation/application_notes/xapp058.zip The zip contains the C source code for embedded XSVF programming, might be a bit of work to get that running on the Atari though. It looks like it wants to have the whole XSVF in RAM, which is about 80k for the XC95144XL (erase+program+verify). Adapting the code to stream the data from the XSVF file might be feasible, this is left as an exercise for the reader though 🙂 so long, Hias
  15. Some 15 years ago I did something similar for Lattice iM4A5 CPLDs (which I used in the 2005 Turbo Freezer). That wasn't too hard, Lattice provided sample C code to perform the JTAG programming, that only needed a few changes to access PIA pins (and probably some adaption for cc65) and the Lattice toolchain also was able to generate a more compact, binary vector format for that purpose (a lot smaller than SVF). Major showstopper though was that the caps and inductors at the joystick port killed the edges and even with schmitt-triggers added I couldn't get it to reliably program the CPLD (with direct connection to PIA it worked, albeit quite slow compared to PC programming). I hadn't pursued that further, so not 100% sure if it was a minor issue to solve or a major one. I don't recall Xilinx provided something similar to the Lattice ispvm-system (IIRC that's what it was called) programming and IIRC Xilinx also recommends against using SVF for their CPLD programming (though it worked quite well here on a PC with a parallel port bit-banged JTAG adapter - several years ago). so long, Has
×
×
  • Create New...