Roydea6 Posted June 16, 2010 Share Posted June 16, 2010 I'm fairly sure that Altirra is handling bit 1 of PORTB incorrectly and switching in BASIC when that bit is used for extended RAM banks. Aha, got it! Don't know how I missed that the first time. Please verify the fix: http://www.virtualdu...-1.7-test21.zip http://www.virtualdu...-test21-src.zip This seems to have fixed the Memory setup, but now I can't get ALT+8 to open the printer output--- the menu drop down still opens printer output. Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 17, 2010 Share Posted June 17, 2010 I'm fairly sure that Altirra is handling bit 1 of PORTB incorrectly and switching in BASIC when that bit is used for extended RAM banks. Aha, got it! Don't know how I missed that the first time. Please verify the fix: http://www.virtualdu...-1.7-test21.zip http://www.virtualdu...-test21-src.zip This seems to have fixed the Memory setup, but now I can't get ALT+8 to open the printer output--- the menu drop down still opens printer output. Oops. http://www.virtualdub.org/beta/Altirra-1.7-test22.zip http://www.virtualdub.org/beta/Altirra-1.7-test22-src.zip I reworked the ins/del keys, too. Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted June 17, 2010 Share Posted June 17, 2010 Nice fix... 1.7---test22 Quote Link to comment Share on other sites More sharing options...
Shawn Jefferson Posted June 18, 2010 Share Posted June 18, 2010 It does support the 1Mb and 8Mb Atarimax cart mappers (41 and 42), but it does not support flash operations. I don't have any information on how those work. Atari++ has this support I believe (source code is available for this, so that could be a good source of info on how it works). Also, Steve Tucker of AtariMax (classics on AtariAge) could probably give you the information. Wrathchild wrote a patch for Atari800Win that implements it as well, another source of info potentially. I have Steve's 6502 flashing code, but I have to admit I don't truly understand what it's doing to put the hardware into "flash" mode. Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 19, 2010 Share Posted June 19, 2010 It does support the 1Mb and 8Mb Atarimax cart mappers (41 and 42), but it does not support flash operations. I don't have any information on how those work. Atari++ has this support I believe (source code is available for this, so that could be a good source of info on how it works). Also, Steve Tucker of AtariMax (classics on AtariAge) could probably give you the information. Wrathchild wrote a patch for Atari800Win that implements it as well, another source of info potentially. I have Steve's 6502 flashing code, but I have to admit I don't truly understand what it's doing to put the hardware into "flash" mode. I think I worked it out. Try this version: http://www.virtualdub.org/beta/Altirra-1.7-test24.zip http://www.virtualdub.org/beta/Altirra-1.7-test24-src.zip It probably isn't entirely correct, but it seems to work with the Atarimax flashing disk images that I have. There are now also options for creating new flash cartridges out of thin air and saving the modified images to disk. Programming a flash chip was a bit of interesting learning. You have to write a series of values with the right data and addresses in order to kick the chip into command mode, and then you can either read out ID information or do write/erase operations. Different flash chips vary in the exact address bits monitored, commands supported, etc. I emulated an Am29F010 flash chip for the 1Mbit cartridge and an Am29F040B flash chip for the 8Mbit one. (Those who actually do hardware will probably spot a problem with the second one. The device ID didn't work out otherwise.) All writes are instantaneous; I wonder what the write speed on a real cart is, as potentially you could write a "flashdisk" driver for it, assuming it's fast enough and the flash has enough endurance. Writing to the flash cartridge doesn't require much code. Quote Link to comment Share on other sites More sharing options...
carmel_andrews Posted June 19, 2010 Share Posted June 19, 2010 what happened to version 1.7 on it's own (i.e not the test versions) Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted June 19, 2010 Author Share Posted June 19, 2010 what happened to version 1.7 on it's own (i.e not the test versions) It's not released yet hence these are 1.7 beta's Quote Link to comment Share on other sites More sharing options...
Shawn Jefferson Posted June 30, 2010 Share Posted June 30, 2010 Thought I should say that I tested 1.7's support of the Atarimax cartridge and it worked nicely! I tested images for the 1mb and the 8mb cartridge that I modified to write data back to the flash cart (Ultima II and Temple of Apshai Trilogy.) Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted June 30, 2010 Author Share Posted June 30, 2010 Latest beta has MyIDE emulation, keys for Ctrl+Esc and Ctrl+Shift+Esc, command-line switches for artifacting, save screenshot command, H: compatibility fixes. http://www.virtualdub.org/beta/Altirra-1.7-test26.zip Quote Link to comment Share on other sites More sharing options...
+therealbountybob Posted June 30, 2010 Share Posted June 30, 2010 Just tested the MYDOS/H: again: can now see files when do a directory of *.xex etc but still cannot copy multiple files (error 165) using C(opy) "H:*.xex," If it's any help when copying a single file it works using "H:filename.xex,d1:filename.xex" but "h:filename.ext," gives the error 165 also. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 30, 2010 Share Posted June 30, 2010 Perhaps there's only one open channel allowed on H:? Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted June 30, 2010 Share Posted June 30, 2010 Just tested the MYDOS/H: again: can now see files when do a directory of *.xex etc but still cannot copy multiple files (error 165) using C(opy) "H:*.xex," If it's any help when copying a single file it works using "H:filename.xex,d1:filename.xex" but "h:filename.ext," gives the error 165 also. MyDOS even has this problem with the APE interface using the 'MIRROR' drive. I noticed this problem years ago when trying to set up MyIDE partitions. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 30, 2010 Share Posted June 30, 2010 All I can suggest is that a multi-file copy may require two open channels on the "H:" device: one for the disk directory, and another for the file streams themselves. The "H:" handler may only allow one channel. We have the same situation with the SDX "CAR:" device. To copy files from CAR:, it was (still is?) necessary to TYPE the file with output redirected to the destination file. It may be that MyDOS closes the directory before opening the source file during a single file copy, but not when copying mutliple files. Of course, my understanding of MyDOS and/or the implementation of the "H:" handler may be completely wrong! Quote Link to comment Share on other sites More sharing options...
+Stephen Posted June 30, 2010 Share Posted June 30, 2010 All I can suggest is that a multi-file copy may require two open channels on the "H:" device: one for the disk directory, and another for the file streams themselves. The "H:" handler may only allow one channel. We have the same situation with the SDX "CAR:" device. To copy files from CAR:, it was (still is?) necessary to TYPE the file with output redirected to the destination file. It may be that MyDOS closes the directory before opening the source file during a single file copy, but not when copying mutliple files. Of course, my understanding of MyDOS and/or the implementation of the "H:" handler may be completely wrong! I think you are correct. SDX still required the output redirection to copy from the CAR device. Also, the H: issue is not a fault of the emulator, but it occurs on real hardware as well (the MyDOS + APE issue). Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 30, 2010 Share Posted June 30, 2010 I think you are correct. SDX still required the output redirection to copy from the CAR device. Also, the H: issue is not a fault of the emulator, but it occurs on real hardware as well (the MyDOS + APE issue). The problem may not be confined to the emulator, but it could be that the emulator slavishly apes (no pun intended) hardware behaviour. The only way I've ever been able to batch copy files from H: to Dn: and back again is using the file manager in The Last Word (that's not intended as a plug: the file manager allows you to work with any device ID and does not require an always-open channel for the directory, thus overcoming the apparent single-IOCB limitation of H:). Quote Link to comment Share on other sites More sharing options...
Shawn Jefferson Posted July 1, 2010 Share Posted July 1, 2010 Latest beta has MyIDE emulation, keys for Ctrl+Esc and Ctrl+Shift+Esc, command-line switches for artifacting, save screenshot command, H: compatibility fixes. http://www.virtualdub.org/beta/Altirra-1.7-test26.zip Hmm, I'd like to know how the MyIDE emulation works. Do you need to create you own IDE "image", and I guess you will need to run one of Mr.Atari's modified OS ROMs. Quote Link to comment Share on other sites More sharing options...
phaeron Posted July 1, 2010 Share Posted July 1, 2010 I think you are correct. SDX still required the output redirection to copy from the CAR device. Also, the H: issue is not a fault of the emulator, but it occurs on real hardware as well (the MyDOS + APE issue). The problem may not be confined to the emulator, but it could be that the emulator slavishly apes (no pun intended) hardware behaviour. The only way I've ever been able to batch copy files from H: to Dn: and back again is using the file manager in The Last Word (that's not intended as a plug: the file manager allows you to work with any device ID and does not require an always-open channel for the directory, thus overcoming the apparent single-IOCB limitation of H:). Altirra's H: device can do I/O on all eight IOCB channels. There's no hardware emulation involved in the H: device, so this is purely a software question of whether the caller is using CIO, if the IOCB request is compliant, and if the caller is interpreting the responses correctly. I did find some bugs on my end, but this looks like another bug in MyDOS. I'm seeing a CIO open request ($03) for the wildcard source path, but with the wrong mode. The Atari OS Manual states that if an OPEN DIRECTORY ($03) command is issued with AUX1 = $06, but MyDOS is passing AUX1 = $04 and expecting to get back a directory listing, and that specifies a regular read-only OPEN FILE command. The problem with trying to work around this is that this operation is already defined in the OS Manual as opening the first matching file. The wildcard copy operation fails in Altirra, and presumably with APE, because MyDOS is trying to interpret the contents of a file as a directory listing. Since there is no way to tell from the IOCB itself whether the caller intends official or MyDOS behavior, working around this would require a MyDOS compatibility option. Quote Link to comment Share on other sites More sharing options...
Rybags Posted July 1, 2010 Share Posted July 1, 2010 That's weird... then how can MyDos differentiate between a normal Open File or Open Directory request, seeing that the data passed can be exactly the same? Or does it only use the AUX1=04 form internally? Quote Link to comment Share on other sites More sharing options...
phaeron Posted July 1, 2010 Share Posted July 1, 2010 That's weird... then how can MyDos differentiate between a normal Open File or Open Directory request, seeing that the data passed can be exactly the same? Or does it only use the AUX1=04 form internally? This only happens with non-disk devices and with the copy command. If you use the list command or if it is working with a Dn: device, it issues AUX1=$06 as expected. It's only for a non-disk device and for the copy command that it uses the wrong mode. Since it was rare to have non-disk CIO devices that supported directories, this might never have been tested properly. I wonder if it might be patchable. Quote Link to comment Share on other sites More sharing options...
snicklin Posted July 1, 2010 Share Posted July 1, 2010 Thank you for the .ini file reading solution. More choice = More flexibility. Quote Link to comment Share on other sites More sharing options...
phaeron Posted July 1, 2010 Share Posted July 1, 2010 Latest beta has MyIDE emulation, keys for Ctrl+Esc and Ctrl+Shift+Esc, command-line switches for artifacting, save screenshot command, H: compatibility fixes. http://www.virtualdub.org/beta/Altirra-1.7-test26.zip Hmm, I'd like to know how the MyIDE emulation works. Do you need to create you own IDE "image", and I guess you will need to run one of Mr.Atari's modified OS ROMs. Altirra will create the IDE image for you and emulate the hardware, but it's up to you to initialize it and supply the driver. Since it is hardware emulation, any of the methods will work, including the MyIDE internal OS, the flash+IDE cartridge, or a soft-booted image. I used 4.4F/I to test. Details: The IDE drive itself is 32 sectors/track, 16 heads, and supports I/O up to 32 sectors at a time. It will do both 8-bit and 16-bit bus transfers. It doesn't yet support the full ATA-1 standard, only read/write sector, identify drive, and set feature commands. This is enough to run FDISK and the MyIDE boot driver. The IDE image is 512 bytes per sector in linear order. Because the MyIDE drivers default to using 16-bit transfer mode with an 8-bit bus, normally only the even bytes will be used. It is possible to use all 512 bytes/sector in 8-bit transfer mode, as at least one MyIDE demo does. To use the MyIDE internal ROM, rename the ROM image to otheros.rom and switch the firmware mode to Other. You will need to invert the BASIC setting and turn off Fast Boot, as there is some incompatibility with the patched ROM and the fast boot feature. To use the flash+IDE image, mount the .bin image as a cartridge and set the mapper mode to flash+IDE. If you only have the flasher ATR, you can use that in Altirra, but it's a pain: you will need to mount an empty 1Mbit flash cartridge (NOT flash+IDE), boot and run the flasher, and then save it as a cartridge image without headers. You can't flash it as flash+IDE because the flasher detects a 4Mbit flash cartridge. I don't know why; something with the flash unlock access pattern. Didn't know there even was a 4Mbit cartridge. The IDE interface occupies either $D100-D11F or $D500-D51F depending on which I/O range you select in System > Hard Disk. $00-$07 simply address the IDE command registers, and after that it's just the ATA spec. Reading and writing sectors is shockingly easy, and the drive will go as fast as your code possibly can -- the 6502 can't even break PIO 0 speeds. Setting up MyIDE itself is a bit of a pain. I'm not sure how it works on the real hardware -- I might have something subtly wrong with the hardware interface -- but here's how I had to do it with the flash+IDE cartridge image in Altirra: Cold reset the Atari and hold Start+Select+Option to enter the menu. Select the cartridge (option 3). Select FDISK 2. Select Init/Auto so FDISK sees the correct drive geometry. Select Make, drive 2, single density, 720 sectors. Select Option, boot drive 1, use images, enable IDE, on-screen activity enabled. Mount a DOS disk in D1:. Select Exit and Save to boot into DOS. This part is a bit fidgety. D2: should be active as the disk image on the hard drive, but sometimes it doesn't work until you use a couple of the Ctrl+Shift commands to enable and unprotect it. Copy D1: to virtual D2: in DOS. Soft-cold-reset (Ctrl+Shift+\) and hold S+S+O to go all the way back into FDISK again. Select Swap, change image partition 1 to D1:, save, exit. At this point, if all goes well, the emulated Atari should reset, the border should turn green, and it should boot off the emulated IDE drive. Emulated success! I have to admit, this is a weird (and somewhat roundabout way) of "try before you buy." After going through this, I can't say I'd really recommend the flash+IDE cartridge, for two reasons: the IDE part relies on a soft-kicked ROM, which won't work with software that uses the upper 16K of memory or twiddles the kernel PORTB bit, and the flash part is incompatible with the normal Maxflash 1Mbit cartridge due to a modified banking mechanism. The internal version looks more appealing, though, because with the driver in kernel ROM and with the IDE using $D1xx instead of $D5xx, you don't have a conflict with cartridge banking registers. Quote Link to comment Share on other sites More sharing options...
Shawn Jefferson Posted July 1, 2010 Share Posted July 1, 2010 (edited) I was caught by the fact that the MyIDE system only uses 256 bytes of each sector, so the size you specify in the hard disk is halfed. I'm testing with some of the software I wrote for MyIDE and it's working nicely, thanks! Edited July 1, 2010 by Shawn Jefferson Quote Link to comment Share on other sites More sharing options...
+Stephen Posted July 2, 2010 Share Posted July 2, 2010 With an internal ROM it doesn't need the RAM OS. The 32 in 1 OS is good for this. Quote Link to comment Share on other sites More sharing options...
Keatah Posted July 3, 2010 Share Posted July 3, 2010 Now only if we could get the correct colors in Star Raiders. As far as I know, the only emulator to correctly render them is Atari 800 Emulator V2.1.0 Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted July 3, 2010 Share Posted July 3, 2010 (edited) I'm testing with some of the software I wrote for MyIDE and it's working nicely, thanks! Would be nice to know if the resulting image file can be easily transfered to a drive or CF card? But cudos for development of the myIde support, I'll be trying it out this week! Edited July 3, 2010 by Wrathchild Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.