Jump to content

HiassofT

Members
  • Content Count

    1,255
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by HiassofT

  1. With PHI2 connected to the CLR input (pin 3) the Q output should go low immediately after the falling edge of PHI2 - so Q shouldn't extend past PHI2. With PHI2 connected to B (and CLR pulled high) the pulse with is determined only by R/C and can extend past PHI2 - you can use such a setup to control a latch to latch address lines beyond PHi2. Either ways the pulse length is limited by R/C and it starts after some delay after the rising edge of PHi2. If the R/C time delay is small enough this can OFC be shorter than the PHI2 high duration. The Nexperia (ex-NXP, ex-Philips) 74HCT123 datasheet contains some helpful information, including a chart with pulse with for small C values: https://assets.nexperia.com/documents/data-sheet/74HC_HCT123.pdf so long, Hias
  2. No, Olimex also came to my mind but it wasn't them (and they have rather good reputation eg for their JTAG adapters). I couldn't let go and went through my email archive and finally found the name: it was Bilex. Google turned up a website but it looks quite orphaned so could well be they're out of business by now. so long, Hias
  3. Yes, there was, but I forgot their name. But I remember they shipped terrible quality, nothing but issues with their boards and they weren't too cheap either. Better stick with above mentioned PCB manufacturers. so long, Hias
  4. A 74HCT123 with 33pF capacitor and 5k6 resistor is a good starting point, that's what we've been using in various projects (TurboFreezer, The!Cart). Note that exact timing might vary depending on manufacturer and/or batch of the '123, cap tolerance, parasitic board capacitance etc. You might need to tweak the R value a bit to get a signal which has it's falling edge some 20-50ns before the falling edge of PHI2. See eg the Turbo Freezer 2011 schematics (ignore the R, C values and IC number, I've mentioned the correct ones in the errata) so long, Hias
  5. While 6502 would have address hold time Atari messed this up when halting the 6502 and giving Antic bus access. The LS04 buffer in the PHI2 signal makes this even worse. So expect zero or even negative address hold time relative to the PHI2 signal on PBI. BTW: when calculating delays also keep in mind that rise/fall times can be pretty long (esp rise). You are not the first one to hit this infamous Atari "PHi2 issue". An easy countermeasure is to use an LS/HCT123 to generate a shortened PHI2 signal and use that for writes (register on the falling edge). so long, Hias
  6. I'd say keep it as simple as possible regarding packaging. An atari800-rpi package (with the legacy proprietary driver) that conflicts with atari800 package should do fine, I guess. I'm not really sure if there are much use cases where having both versions installed at the same time would make too much sense - and differences in config files can cause headaches. Pre-built images and switching the same SD card between RPi0/1 and 2/3/4 are the only ones I can think of ATM but I guess these are really rare cases. atari800 then could use the standard debian packaging already present (though not updated to 5.0.0 IIRC) and is nothing you need to worry about - except running dpkg-buildpackage on arm and arm64 🙂 so long, Hias
  7. Just my 2c: IMO it would be best to provide a separate package for RPi0/1 with the legacy proprietary graphics stack (eg atari800-legacy) and a standard package using mesa/gl for RPi2-4. Full KMS with mesa gl drivers are now the default on RPiOS Bullseye, firmware KMS and the proprietary gl drivers are currently still available but no longer maintained (RPi0/1 users might want to use them though as the proprietary gl driver has better performance on the low-end single-core RPis). Coexistence of standard and legacy atari800 packages could easily be managed with Debian's alternative system (update-alternatives --config atari800). so long, Hias
  8. Feel free to reuse/enlarge/shrink/.. the PBI adapter board we used for the Turbo Freezer 2011. Eagle files are here https://www.horus.com/~hias/freezer/turbo-freezer-2011/freezer-eagle-files.zip so long, Hias
  9. Just saw the mail on the atari800 mailinglist, Atari800 v5.0.0 has been released today https://github.com/atari800/atari800/releases/tag/ATARI800_5_0_0 Binaries should follow soon. Thanks a lot to everyone involved! so long, Hias
  10. Getting some meaningful 8.3 names most likely won't work without manual interaction. eg if you have "Donkey Kong", "Donkey Kong Junior" and "Donkey Kong Remix" you'll have to choose yourself how to resolve the shortening so you later know which one was which. The tools can help you to automate some boring task like removing embedded tags like [composer] (year) etc. RegEx and JavaScript might be useful to automate some of that and/or you could export a file list to csv, process that with calc/excel/whatever you're most familiar with, and semi-automatically and/or manually choose short file names there, then use the csv to rename the files. The csv approach with from and to columns might also be helpful if you later want to know what DONKGJR3.SAP actually was, just look it up there 🙂 so long, Hias
  11. MS PowerToys include a PowerRename tool https://docs.microsoft.com/en-us/windows/powertoys/powerrename And there's also third-party windows software like Bulk Rename https://www.bulkrenameutility.co.uk/ I haven't used either of these myself but the descriptions read like they should help with most of the boring leg-work. Personally, as a linux user, I use mmv on the command line to bulk rename files. so long, Hias
  12. 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
  13. Thanks a lot for refreshing my memory, I had completely forgotten about that! so long, Hias
  14. 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
  15. 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
  16. @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
  17. Absolutely - or maybe even more. My comment wasn't meant too seriously 🙂 so long, Hias
  18. 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
  19. @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
  20. Simply speaking: Nir was very lucky it worked without this particular cart. In general it won't work though. so long, Hias
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
×
×
  • Create New...