Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


flashjazzcat last won the day on August 14 2019

flashjazzcat had the most liked content!

Community Reputation

11,586 Excellent

About flashjazzcat

  • Rank
    Never ever bloody anything ever!
  • Birthday 12/19/1972

Contact / Social Media

Profile Information

  • Gender
  • Location
    United Kingdom
  • Interests
    Playing jazz guitar, music, reading, writing, PCs and anything to do with computers, movies

Recent Profile Visitors

70,064 profile views
  1. Or a thin piece of aluminium, some photo paper and a laser printer. Print mirrored design, iron onto metal face down, then wash away paper.
  2. They sure do, but you can thin them down and they look very nice (see recent video). Left as an exercise for the reader.
  3. https://www.ebay.co.uk/itm/Atari-600-XL-Label-Logo-Sticker-Badge-brushed-aluminum-48-x-9-mm-287/182185824896
  4. You can perform the U1MB update right from the SIDE3 loader. I have PM'd you pre-release U1MB firmware for SIDE3 (please do not share it), and instructions on how to install it.
  5. You have the SIDE PBI BIOS installed, which is designed for the SIDE/SIDE2 cartridge. You need to install the pre-release U1MB firmware, found in the download section of the SIDE3 firmware page of my website: https://atari8.co.uk/firmware/side3/ The proper release will be forthcoming shortly (updates to plugin architecture and such took a lot longer than expected).
  6. Correct, and without any risk of being left with a black screen if the resolution is out of range.
  7. Yes: just updated my 1088XEL from Sophia 1 to Sophia 2 the other day in order to test the U1MB Sophia 2 plugin and everything works very nicely indeed. I could think of no other target machine which would allow a 2 minute install.
  8. Just the new v.4.00 plugins. The thing has been redesigned a bit since this photo was taken, collapsing all the Sophia functionality down to six settings.
  9. That's page three, although if Page 6 had done so, they may have lasted a bit longer.
  10. I am not in the least bit angry, and I don't know why you would conflate my attempts to explain the logic behind the SDX kernel device names as evidence of anger. It is you who has written that you are 'upset'. I would say consistency. If you're going to make a clean break of it (for reasons Konrad can explain more eloquently than I), there is no point in leaving vestigial elements of the old convention in place for arbitrary reasons. If you understand that, from where does the confusion arise? Not really unexpected when if you have spent twenty minutes familiarising yourself with SDX or looking through the manual. A hex numbering scheme could certainly have worked, but is not really user-friendly if said user doesn't understand hexadecimal, and we seem to be discussing concepts which are purportedly hard to grasp for the average user. 1-F isn't very expandable, however; if SDX one day supported 26 drives, your hex unit numbering scheme would fall flat on its face. OK - chill. No offense intended. I was just responding to this: I didn't realise you specifically meant the limitations of HATABS. My bad! I'm not sure you know what you're saying: in the same breath, you tell us you are not claiming the device naming scheme is arbitrary and confusing, and then say that it's 'unnecessary' and a source of pointless confusion. 'Arbitrary' means 'based on random choice or personal whim, rather than any reason or system.' So: pointless, which is what you call it in as many words. I am arguing that long device IDs are essential to the flexibility of the SDX driver model, and that the DSK device should follow the same conventions for the sake of internal consistency in the SDX kernel. Anyway: no aggravation intended. I speak as someone who has been using SDX since 1989, and I guess I have become used to it.
  11. What about my PCLink volume on PCL2: (or "DPCL2:" via the CIO)? "D:" denotes the current directory on the default drive, which may be anything from D1:-DO:. If you add a unit number, it still refers to the current directory on the specified drive, unlike the bonkers MYDOS implementation where adding a unit number forces a reference to the root of the specified drive. Nothing inexplicable about it at all. "J" is the tenth letter of the alphabet. If you prefer, use "DA:" through "DO:". It's HATABS which only supports a single character device name; the handler can do as it pleases, as evidenced by the SDX "D:" handler itself, which allows "DDSK1:", "DCON:", etc. I have to wonder how many times one wants to refer to the cassette device from the DOS prompt anyway. The reasons behind device kernel names have already been laboriously explained here and are explained in the manual as well. There is logical reasoning behind the design; you may not like or agree with it, but to portray it as arbitrary or a labrynth of confusion seems disingenous. As for MS-DOS: this may have informed the design of SDX, but this would hardly be surprising in the late 1980s when MS-DOS was probably the predominant disk operating system. Those of us old enough have been using '"A:" through "Z:" to address our disk drives and hard disk partitions on PCs for some thirty-odd years, and the conventions remain the same to this day. Perhaps one would prefer a linux /dev approach, but this would still involve a completely redesigned device naming scheme which is not directly compatible with the one implemented by Atari DOS 2.x. And the reasons for not simply sticking with that standard have already been covered.
  12. Yes, but the reasoning behind kernel device names and drive letters has more to do with flexibility. Imagine only being able to use a single device ID and unit number for something like the 'CAR:' (cartridge volume) or 'PCL:' (PCLink) devices. 'C:' and 'P:'? Nope... already taken. In any case, from the CIO, the exact notation you suggested can be used anyway, and this does not involve any 'conflicts' with existing devices, even if you have an HDD partition on 'C:' (since it's D3:, DC:, DDSK3: or DDSKC: via CIO). But in the CLI, where there are pipes, batch files, and multiple installable devices, getting away from the limitations of the single-character device names made a lot of sense. The screen editor and keyboard, etc, are referred to by different device names at the SDX command line, so no contention is possible with 'E:', 'K:', etc.
  13. EDDY runs in 64 columns by default using a built-in display driver, but will run in 80 columns and use additional colours where S_VBXE.SYS is present.
  14. Did you run RWCRC on a fresh partition?
  • Create New...