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

754 Excellent

About HiassofT

  • Rank

Contact / Social Media

Profile Information

  • Gender
  • Location
    Salzburg, Austria

Recent Profile Visitors

21,695 profile views
  1. 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
  2. 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
  3. 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
  4. 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
  5. Yes, 600XL needs to be upgraded to 64k first. Using an ATF22V10C should work, but I haven't tested it myself. so long, Hias
  6. 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
  7. 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
  8. 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
  9. @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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  • Create New...