Jump to content

E474

Members
  • Content Count

    387
  • Joined

  • Last visited

Community Reputation

176 Excellent

About E474

  • Rank
    Moonsweeper

Recent Profile Visitors

2,205 profile views
  1. Hi, I think there is a certain amount of chaos in the online markets at the moment. Some goods have gotten really expensive (IPA for example, as you can make hand sanitizer with it), but some things seem to be getting cheaper as I have a feeling people don't want to be left with too much stock when cash/liquidity is King. I got a 4GB Raspberry Pi a couple of weeks ago for £29.99, which is much cheaper than usual. Not sure if the seller was being squeezed, or wanted to cash out. The Pi is on the list to be set up, but it's still in decontamination/holding.
  2. Hi, @kbr pointed out to me via PM that the micro sd card is on the screen. On the other hand there is a micro-USB connector on the Arduino that I currently use for power, not sure if I could use the barrel connector instead, and connect a USB memory stick using an OTG cable in the microUSB connector? I think I would wire up 2 buttons: - reset - cycle ATR If I could set everything else up via the 8-bit menu program, I think that would be all you need. You could probably get away with not having a reset button if you powered down each time, but I think there is a reset button on my Arduino anyway. Just out of curiosity @Waltermixxx, how do you store ATR images if you don't have a screen with a microSD card on it? Also, sorry for (slightly) hijacking the fujinet thread.
  3. I guess an SDrive-Max, with just a button, would be an SDrive-????
  4. Hi, Would it be possible to overload the "Next ATR" button functionality, so that if you have defined disk slots, e.g. D1=AA.ATR, D2=AB.ATR, you cycle those ATRs, if you only have slot D1 defined, you cycle to next ATR file in the current directory. Personally I would put all ATRs from a multi disk product in the same directory (and only those ATR's), and only define one disk slot, which I would boot from. Also, is there any progress on a public design for ESP32 boards that can be sent off and made up (ideally one that doesn't involve the word "eventually"). I agree that the SDrive Max touch screen can be a little fiddly, but I've just asked @kbr if he can replace it with a Next Atr button, and use the SDrive menu program on the Atari for everything else. I think it would be fairly straightforward, but I don't know the electronics to do it, and would need the electronics done before I could hack the SDrive firmware.
  5. Hi, I don't have a crystal ball, but I figure this will be the peak price period for retro kit for a while, due to people holding off on discretionary spending, more items coming on to the market due to people clearing out their own lofts/storage during corona virus lockdown and other peoples lofts/storage space (due to corona virus deaths, assuming kit doesn't go to landfill when people want to get a vacant property on the market quickly). My own weakness is for 1050 drives, but I'm reluctant to pay too much for one, unless it has an exotic mod. I would really like to get an 810 at some point, but they don't come on to the market very often here (UK), but that's about the only thing I would like to buy. I'm thinking of not buying any original 8-bit kit for the next 6 months, if prices crash then I've made the right decision, if they increase it will probably be only by a bit. Having said all that, I should try and sell off one or two 800xl systems, but I've held off till now on the basis that I like to have spares. Even being in lockdown the last week, I've been so busy I have only managed about 45 minutes of Atari time (Bandits!), but I'm hoping things will settle down in a week or so, and I will get some peace and quiet and can start 8-bit hacking again. Hope everyone is being careful about corona virus!
  6. Hi, You could also use the 400/800 OS, replace the SIO handler code with an RTS, and it should boot to the Memo Pad.
  7. Hi, Unfortunately there's not much chance of replacing (or dumping) the US-Doubler as it's part of this setup: So, I would be inclined to note it in the Altirra Hardware Reference (if it was my document, which it isn't). Timewise, I think I got the upgrade in the second half of 1985 or first half of 1986, but I can't be more specific than that (not sure if that rules out any of the ROMs), and I don't know if there is a dated copyright message in the dump of the Lazer code. Having said all that, I think I will code for SIO get status not being 100% reliable, and for that matter get Percom block also not always returning a correct Percom block. Thanks!
  8. Hi, Thanks very much - I had forgotten about this thread, despite commenting on it! It looks like it must be a ROM issue as it is definitely not setting the status bit 7 for ED correctly on my hardware. I guess the best thing to do is check the status register, if it returns bit 7 true, then it is Enhanced Density, and if it returns bit 7 false, check if I can read sectors > 720 just in case. Btw, is there any chance this is a bug on particular releases of US Doubler ROMs, or is it only for copied versions (and if so, I wonder which ones). Perhaps it's worth mentioning in @phaeron's Altirra Hardware Reference Manual that some unofficial US Doublers do not set status bit 7 correctly for ED disks? Thanks for all the help.
  9. Hi, I have replaced the single density disk size test of reading sector 721/1040 with a test on the status byte instead, and it looks like my US-Doubler is not setting the highest bit of the status register when the disk is enhanced density (1040 sectors). My Lazer (Happy clone) does set the bit correctly. Can anyone with a genuine US Doubler verify this (maybe @Nezgar has the drives to do this?) - the attached ATR needs to be booted on Drive 1, test executable (TESTAPP.EXE) in ATR needs to be run against a floppy in drive 2 (sorry for hard-coding the drive number). It should be able to detect SD/ED/DD disks in drive 2 with a Happy or similar drive, but always return SD for SD/ED with a US-Doubler. Changed code goes like: TEST_FOR_ENHANCED_DENSITY_SECTORS JSR GET_DRIVE_STATUS JSR DISPLAY_SIO_STATUS JSR DISPLAY_DRIVE_STATUS_BUFFER LDA DRIVE_STATUS_BUFFER AND #$80 BEQ IS_720 SEC RTS IS_720 CLC RTS ; ; returns: ; ; SEC - could read enhanced density sectors ; CLC - could not read enhanced density sectors ; ; Thanks! ATM_SD.atr
  10. Hi, Thanks very much for the sources, I will sit down and give them a good read. Attached is an ATR with the executable I have been working on - it expects to be booted from drive 1, and assumes drive 2 is the source drive to check - it's quite bloated as it was a test using the ATR Maker sources for some subroutines. Thanks again! ATRMD_SD1.atr
  11. Hi, Thanks very much @Alfred and @phaeron for the replies (and attachment) - I have been testing with my own code and have found that my "clone" US-Doubler does return a Percom block, but will often return a single density (720 sector) Percom block when there is a double density disk in the drive. So @phaeron is quite correct regarding "correct" vs "valid" - thanks! My disk detection routine is basically: get status (SIO DCMND $53) on source drive -- Y/positive result: drive exists -- Y/negative result: drive doesn't exist, stop read sector 1 on source drive -- Y/positive result: disk present in drive -- Y/negative result: disk not present in drive, stop read sector 4 immediate (DSTAT=0) just to set up XF551, ignore return code read sector 4, starting sector size of $80, doubling sector size and retrying until sector reads successfully (upper limit of 2K sized sectors) if sector 4 is 128 byte sector, see if it is single density (720 sectors) or enhanced density (1040 sectors) - I do this by reading from sector 721 and see if SIO return code is positive or negative. I'm not testing on the drive status at the moment, but I am going to add this test, though, IIRC, I have seen some suspect results with my US-Doubler. Also, if reading sector 721 gives an error, I plan on reading additional >721 sectors, just in case the disk is an enhanced density disk with a bad sector 721. if sector 4 size is >128 bytes, I get the Percom block, then compare the Percom block sector size against the actual size, if this matches, then the Percom block is most likely correct, if it doesn't match, then the drive is probably a US-Doubler, SuperArchiver or Indus GT, in which case I assume the disk is a double density single sided disk (720 * 256 byte sectors). I'm going to add a test to see if I can read a DD sector 721, just in case it is a larger capacity disk that doesn't return an accurate Percom block. I think this should cover most, if not all, disk types and drives, I have some additional error states such as drive supports double density but doesn't return a Percom block at all, but I'm not sure if these actually exist. Thanks again for the help, I will test the above attached file (percombl.obx) - is there any chance you can upload the source code for it too?
  12. Hi, In the Altirra Reference Manual, page 189, it says that the US-Doubler, Super Archiver and Indus GT drives, in particular, can't be relied on to return a valid Percom block. Do these drives only support Singled Sided Double Density disks at most, e.g. 720 x 256 byte sectors? Are there any drives that support larger sized disks but also can't be relied on to return a valid Percom block (or any other drives that are also unreliable)? Am asking as I am trying to test when to trust a Percom block. Thanks!
  13. Hi, Have you tried checking values from the defective board against values from a working board? They should be identical until they are not, if you see what I mean.
  14. Hi, I think the different sdrive.com files can be selected if you hold down SHIFT when booting. You can also reboot with the Atari/inverse video key.
  15. Hi, Thanks @Nezgarfor the plug for dump1050 - I think it's much more preferable to dump the ROM via software than taking apart a working board and dumping with an EPROM reader (these boards are getting on a bit). I also think it's handy to have a backup of the ROM in case it goes bad in the future. It's also good for software preservation. There are a couple of locations that can't be read via software ($FFF8 and $FFF9, if I recall correctly), these locations are used for triggering a bank selection. The value that you get isn't necessarily the value in the EPROM, but what happens to be on the data bus given the electronics for your board. Even if there was a consistent value returned, it wouldn't necessarily be the value in the EPROM. If you want to compare different ROM dumps, you should just compare the bytes that can be reliably dumped, these bytes are the only ones that the processor can actually access anyway. If you compare different dumps using a CRC/hash value, then it will look like the files are different, but this isn't a significant difference, it's only significant if the data that can be dumped reliably is different. If you want to make a physical dump of the ROM using an EPROM reader, you should be able to read these hidden bytes, but you'll be reading data that the processor can't, and you also run the risk of accidentally damaging the board. I guess the upshot of all this is that if you are interested enough to find out about the ROM contents of your upgrade, you'll also find out about the bytes that can't be read, and that if you want to compare ROM dumps, you'll only be comparing bytes that the processor can read. There's more info on the thread that @Nezgar kindly linked to, and also on the github page with the sources. Hope this helps!
×
×
  • Create New...