HiassofT

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

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

This reads exactly like the issue I fixed last year: https://github.com/RespeQt/RespeQt/pull/6 The fix has been merged into the master branch almost a year ago - but it seems RespeQt didn't create a release with it... so long, Hias

It took me a while to figure it out but I think I know now what's going wrong: You need to change the "X" in the first 5 columns/pins to "0". These are inputs, and "X" in JEDEC test vectors means "use default value" for input pins (on outputs it means "don't care"). The default "X" value is set to "0" in the JED file before the test vectors (with the "X" field in the file): X0* V0001 XXXXX111111N1HH1HHHLLLLN* ... BTW: substituting the "N" VCC/GND pin values with "G" and "V" looks OK to me. so long, Hias

You can also build ATasm without zlib support (it's optional and only used for creating compressed Atari800 snapshot files, a feature I've never used). Simply run: make USEZ= ZLIB= so long, Hias

No. The design goal of this upgrade was to provide a simple and easy to build RAM upgrade in addition to the base memory. Replacing the base 64k memory as well would have complicated things a lot. so long, Hias

Yes, 600XL needs to be upgraded to 64k first. Using an ATF22V10C should work, but I haven't tested it myself. so long, Hias

The highspeed code works fine on 400/800 but the ROM patch needs about 1k of ROM space - the only possibility to get that much space was to reuse the international character set. Actually it's possible to patch the 400/800 OS, patchrom for the PC supports that, but it will create a 16k ROM - you can use that in an XL or probably also in an incognito, but not on a stock 400/800. so long, Hias

The easiest way is to check the contents of $CFF0-$CFFF. If the OS is patched the first 4 bytes contain the string "Hias", followed by version number and date. eg 48 69 61 73 20 31 2e 33 32 20 32 30 30 34 32 38 Hias 1.32 200428 so long, Hias

Instead of bus-sniffing in software you should be able to offload that to the programmable I/O (PIO) state machines - a really nice feature! so long, Hias

@mytek if you prefer a native linux solution just use patchrom from my highspeed-sio git ihttps://github.com/HiassofT/highspeed-sio - this includes the latest check/fix checksum changes. so long, Hias

Yes, this should work fine. 9-bit mode seems to have been used in some older industrial applications and this trick was often used to get 9-bit mode working with UARTs. The 16C950 even has support for a native 9-bit mode. When enabled the 9th bit is stored in the LSR parity bit when receiving, like on 16C550, and when transmitting the LSB of the scratch pad register holds bit 9 (this has to be written before the data register). so long, Hias

Thanks a lot, this is very interesting info! Using mark/space parity was also my first idea. POSIX termios only supports even/odd parity, but eg linux has the CMSPAR extension to select mark/space parity as well and it's supported by quite a lot of drivers (8250, pl011, ftdi etc). Sending arbitrary 9-bit data would be a huge PITA, sending with a fixed 9th bit (mark/space parity) is rather easy and receiving 9-bit data with parity-errors signalled in-band is doable with a bit of leg-work (setup with INPCK and PARMRK flags and post-process received data). Not exactly sure how it's in OS/X or windows APIs, but eg using a Raspberry Pi looks feasible to me - pl011 supports flexible baudrate configuration, and RPis come with HDMI and composite outputs which are helpful to get something displayed. Other ARM SBCs should work as well, OFC. so long, Hias

The data - otherwise it wouldn't be fun to interface with standard serial chips and APIs ? See eg the info from the (awesome) Altirra HW reference manual. WARNING: please make sure you have a hard surface or wall nearby, you might feel a strong urge to bang your head against that after reading the details. so long, Hias

Unless you really need the space I'd say keep the RF modulator in, then you've got an additional option to hook it up to a TV. Last year I bought a new TV, an LG OLED 55C8, and here in Europe (models seem to vary in different parts of the world) it doesn't have any analog composite/s-video/RGB inputs. But it still supports analog RF input, so that's the only possibility to hook up an Atari to that TV without needing any additional devices/converters/... RF video quality surely isn't too great but at least it's a possibility to get a picture without investing $$$ into some analog to HDMI converter. Not sure how long old, analog RF will be supported by TVs (analog terrestrial was killed here long ago and most cable providers transitioned to DVB-C too, so probably will stop analog sooner or later), but that option might buy you a bit of time until analog stuff is finally phased out completely. so long, Hias

Chrome is on a crusade against http download links from https sites ("mixed content download"), see here: https://blog.chromium.org/2020/02/protecting-users-from-insecure.html As AtariAge is served via https (which is a good thing) a lot of the (esp older) http links here on the forum will be blocked without notice. so long, Hias

I recently packaged the Atari800 Kodi Retroplayer addon for LibreELEC and since a few days it's available from our official addon repository: LibreELEC Add-ons -> Game add-ons -> Emulators -> Atari - 5200 (Atari800) (sic!) Under the hood it uses the libretro port of Atari800 which isn't too up-to-date, has a couple of (more or less annoying) quirks, but the issues are quite easy to resolve and it's good enough to play most games After installation you have to copy the OS ROMs (atarixl.rom, atariosa.rom, atariosb.rom, ataribas.rom) into the correct folder: /storage/.kodi/userdata/addon_data/game.libretro.atari800/resources/system (if you do it via ssh/scp) or addon_data\game.libretro.atari800\resources\system in the "Userdata" windows share. Note: you have to manually create the directories, game.libretro.atari800 and anything below won't be there after initial installation. Quite annoyingly the atari800 addon won't re-check for added OS ROMs after you started it once. You can work around that by ssh-ing into LibreELEC and manually deleting "/storage/.atari800.cfg" - editing the .atari800.cfg file may also work. You may want to adjust the addon settings / emulator configuration and change system type and PAL/NTSC video standard. Better don't play around with internal resolution though, that didn't end well here ? Then enter the "Game" menu in Kodi, choose the folder with your Atari stuff and select the ATR etc. It seems the libretro folks forgot to include "car" and "xex" in the list of supported extensions (I'll have a look at getting this fixed), but there's a simple workaround for that, too: ssh in, edit "/storage/.kodi/addons/game.libretro.atari800/addon.xml" and add these extensions to the "<extensions>" definition. It should then eg look like this: Then restart kodi (or use reboot from the kodi menu) so that the changes take effect. so long & happy Atari gaming, Hias

There's no general incombatibility issue between the Turbo Freezer and the MyIDE carts that I'm aware of. The problem is that the Atari timing is messed up (aka "PHI2 issues"), and there are well known mitigations that hardware upgrades can implement to avoid that. The Turbo Freezer 2005 was one of the first devices that included 74HCT123 to fix RAM/flash write timing (in addition to address latches to fix internal register writes in the CPLD) - and of course the 2011 versions also includes that 74HCT123. For IDE/CF interfaces only fixing write timing is not enough, they must also fix read timing. The easiest way to do that is to simply do the "stabilizing mod" in the Atari, solder a wire to the 74LS08. Another possibility is to latch the address lines going to the IDE/CF device. ISTR some IDE/CF interfaces were also plagued by other issues (could have been termination/ringing related and/or grounding issues), but can't remember all details. I can't say for sure what's going wrong exactly in your case but as only the MyIDE interface seems to have issues it's very likely that it's been working "on the edge" for a while now and adding the Freezer just made the core issues more visible - probably other upgrades could have cause that as well. so long, Hias

I'm very sure it's an issue with the MyIDE cart - pretty much all IDE/CF carts have a long history of timing problems, showing symptoms exactly as you described. so long, Hias

Sorry, I don't have a MyIDE II cartridge. I have an old MyIDE+Flash cartridge but gave up on it a long time ago as it was well known for it's stability / timing issues. No idea if this was improved or fixed with the II version. so long, Hias

This sounds like the typical Atari bus load / PHI2 issue. If you use an Atari XE just plug the MyIDE cart into the cart slot on the XE Freezer adapter board, without SysCheck attached. Also note that SysCheck and the Freezer don't work well together as they both use the same method to map memory in and thus will clash (eg if you try to use a ROM from SysCheck and then try to activate the Freezer). so long, Hias

The!Cart is equipped with 128MB of flash and 512k of RAM. In 8k mode ($A000-$BFFF) you can select the 8k bank and source (RAM/ROM) of that window (and ofc also disable the 8k to access the Atari RAM). The!Cart also offers a "flexi mode" where you have separate bank, source and enable registers for $8000-$9FFF and $A000-$BFFF. This makes working with both RAM and ROM at the same time a lot easier as you can eg keep the A000 area at a single ROM bank while switching in various other RAM or ROM banks at $8000. Or have 2 different RAM banks mapped etc. The predecessor to this flexi mode was the "8k-RAM" mode that I implemented on the TurboFreezer 2011. There you have 8k ROM (or RAM, if you want) mapped at $A000 and can optionally switch in RAM at $8000 (again via separate bank and enable registers). I'm using this mode in the CartEmu menu of the Turbo Freezer to have a separate area to store presets. As the RAM on the Turbo Freezer 2011 has battery backup this is a really convenient way to have persistent storage (not limited by flash page size or having to fear wearing out the flash chip by excessive re-writes). so long, Hias

I've uploaded DiskCart V1.30 to my homepage https://www.horus.com/~hias/atari/#diskcart DiskCart allows you to transfer up to 8 disk images of arbitrary size to flash carts, write images back to disk drives, boot images from the cart or use the integrated MyPicoDos version to start files from the images. DiskCart runs enntirely on Atari 8-bit computers, only requirements are a minimum of 48k RAM (64k RAM for image boot) and a flash cart. Currently Atarimax 8MBit, 512k and 4MB Flash MegaCarts and Turbo Freezer 2005 and 2011 CartEmus are supported. I originally wrote DiskCart about 10 years ago for the 512k Flash MegaCart, then extended it to support the Turbo Freezers, Atarimax 8MBit and 4MB Flash MegaCart, and obviously forgot to upload it to my homepage back in 2013 - versions 1.0 and 1.21 were included in Bernd's Flash MegaCart software releases though. I recently dug into my old code again after Ralf from ABBUC noticed that the 1.21 version didn't work with the new Panos Freezer, fixed that, update MyPicoDos and flasher code to latest versions and added some fixes that I started to work on in 2013 and added some improvements (like a 512k Freezer 2011 mode which leaves part of the CartEmu space free for other use). so long, Hias

I've mainly tested with "Attach special cartridge->Empty 512k MegaCart flash cartridge", and also tried with a plain 512k ROM file selecting the MegaCart 512K (3) type. The 512k flash MegaCart doesn't have a cart type number assigned in Atari800's CART.txt, so probably packing that into a CAR file will be a bit tricky (well, banking is identical to normal 512k MegaCart but one would need to flag to the emulator that it has a flash chip). so long, Hias

I think I found a bug: The 512k MegaCart flash cartridge seems to be emulated with 4096k MegaCart flash banking (255 16k pages, $FF disables cart) instead of standard 512k MegaCart banking (bits 0-4 select one of 32 16k banks, bit 7 disables cart). Info about that cart can be found here: http://www.abbuc.de/~bernd/neue-module---new-cartridge/index.html I noticed that when testing my old diskcart/diskwriter software (see here http://www.abbuc.de/~bernd/downloads/diskcart.zip) which uses $80 to disable the cart and crashes in Altirra immediately at the start when it tries to run code at $BB00 (which should be RAM). .bank indicates that the internal cart address follows 4MB MegaCart banking, only $FF disables it and the address increases up to 4MB (minus 16k). The flash chip (29F040) seems to be emulated correctly though. This bug has probably been present from the beginning, I went back to 3.00 and got the same crash (didn't go back further in time). so long, Hias