Altirra 2.60 released

[Keatah]

I have to note my disagreement on this. I prefer the current method of dealing with "flippies." That is, each side is its own image file. After all, the flip side of a disk in a 1050 is seen by the Atari as a completely distinct disk, just as much as if it were on a different physical disk entirely. The fact that people made flippies in the physical world, is not at all relevant in the virtual world in any way that I can see, other than perhaps the information on the flipside might be related to the front side.

 

Since emulators let you have all the "drives" you want, it would seem to be a convenience advantage to have each disk in its own separate image file.

 

I'm all for the 1 side = 1 image = 1 logical/physical device scheme. We've been doing it this way since the BBS days when WaReZ were always packed 1 side per file. And everything in the archives is typically done this way too.

 

It only begins changing when you start using larger logical devices and putting more, separate, different applications + games all into one image, like a virtual HDD image.

 

Applewin emulator provides 2 simulated drives like so..

..and you can pre-load sides 1 and 2 of a game and simply hit the swap button to change the active image in drive 1.

[fujidude]

That is a fair point fujidude and well made. Honestly I had not even considered that some people didn't use flippys! All my disks were flipped and even the 'backups' that formed the vast majority of my game collection were flippies that sometimes had what were originally I suppose two SS DD diskettes put on to either side of one DS DD copy. Even this question itself would go away if Altirra checked the currently selected image was compliant to the current drive profile.

 

Hey there. Yeah, when I was using the real iron I used "flippies" a lot. I had two 1050 drives. Both were modified. One had a U.S. Doubler, and the other had a Happy enhancement. The mods let them support SD, ED, or DD, but being 1050, they still were only SS.

 

 

Even this question itself would go away if Altirra checked the currently selected image was compliant to the current drive profile.

 

I'm not exactly sure how it would do that. The .ATR specification doesn't seem to have a way to indicate double sided.

 

 

Although another would also arise - say you were using a XF551 profile and through it created what amounted to a flippy image - a DS DD diskette with, say the 'Countryside' and 'Dungeon' disks of 'Wizard's Crown' (I seem to have that game on the brain currently!) on either of its two sides... Now how would you tell the XF551 to read side 2 for the 'Dungeon Disk' when it was required by the game given the XF551 has two heads and doesn't need to flip? For that matter how would you tell it to even write the two sides separately in the first place? I suppose that is not really a question facing Altirra uniquely, but something the real hardware encountered as well. Perhaps the 'flip' option would only become enabled when Altirra detected a DS DD (or DS SD for that matter!) image had been inserted but the profile in use was '1050'?

 

Like you say, I'm not sure how you would write one out that way in the 1st place. Also, I see no reason to do so with an emulator., and truthfully not even with a physical XF551. With physical stuff, just flip the darn disk. With emulation, just load the SS image you want in the drive, or in another drive.

 

 

One other question that occurs to me is; does the '*.ATR' disk format even store discrete details like number of sides and density of sectors/tracks in the first place? Are these data kept in a header that Altirra could read when the image was first inserted and so do its geometry compliance check?

 

As I mentioned, ATR does not track SS vs. DS. I think that SpartaDOS, for its part, might be able to tell that based on information on a SD formatted disk. I'm not for sure on that and would have to look it up somewhere. As to ATr format, do a search here on AA. I researched it and posted a comparison of the author's (Nick Kennedy of SIO2PC fame) spec, and the version of it as changed by Steve Tucker. Unfortunately, Steve's changes are somewhat incompatible with Nicks spec, which is a shame, because Nick left in spares which Steve could have used for his proprietary extensions. Well, enough on that. It is what it is. If one has to choose between them, I suggest Nick's version. I'm not sure about .ATX format.

Edited May 4, 2015 by fujidude

[morelenmir]

Lots of cool information there fujidude! In regards the 'ATR' format, I feared it might not have the header data to key off... I suppose you could always 'simulate' a flippy by loading one 'side' in drive 1 and then a second in drive 2; you could then 'flip' using the new 'rotate up/down' commands. Maybe you could also wrap two sides - represented as two SS 'ATR's - in a *.zip/rar and then swap between them in the fashion that was being discussed above.

 

In regards the actual hardware then, did it not 'think' in terms of sides? Say the XF551 had a DS DD disk inserted; did it just see that as 1440 sectors as opposed to 720 when a SS DD disk and NOT 2 discrete lots of 720 sectors? Specifically it didn't kind of read 'side 1, sector 0 ->side 1, sector 1... side 1 sector 719' and then start again 'side 2, sector 0...' Did it just count 'sector 0->sector 1... sector 720->sector 721...' and so on?

Edited May 4, 2015 by morelenmir

[flashjazzcat]

The XF551 is a double sided drive so the 1440 sectors are contiguous and there's no need for flipping. Only when using a DOS incapable of DS/DD might one be inclined to cut an index hole and write protect notch and flip the disk.

[morelenmir]

I used to use this weird 'nibbler' contraption my father had for metal working to notch my flippies. It was kind of like a tiny hand powered and counter-sprung guillotine that 'nibbled' away a small, perfectly square chunk of whatever you were trying to cut. I suppose it was a bit like a cross between a grip-trainer and a hole punch! If I was really careful I found I could notch new disks perfectly with that thing and never wreck the media inside... Wow... I haven't thought of that for - genuinely - decades... I wonder where it is now!

[phaeron]

Update:

http://www.virtualdub.org/beta/Altirra-2.70-test12.zip

http://www.virtualdub.org/beta/Altirra-2.70-test12-src.zip

• Fixes regression in assembler due to MVN/MVP fix.
• .basic_dumpline can now decode TBXL tokens (-t) and .basic_vars sees TBXL labels.
• Fixed ATOS line draw regression due to page crossing (MADS .pages only produces a warning, not an error... grr).
• Added History tracking support for Veronica and emulation of V1/V2 hardware differences.
• Added DSDD 80-track format to New Disk dialog.

 

Is there any way in Altirra to use the CF drive from an Incognito as R/W? I don't have my 800 set up right now, but would like to download some things onto its CF drive. I have a USB CF adapter in my laptop.

 

Currently, no. I have avoided implementing write support so far due to an irrational fear of accidentally destroying disks. Also, R/W support requires additional program code to unmount the disk first as Windows will not allow write access to a mounted partition. You can, however, go through a VHD image as Altirra mounts VHD images directly without going through Windows, so it would be possible to clone the VHD onto the CF card.

 

Avery, what about the notion of auto mounting based upon the file name, ie a zip containing all the disks for a game and Altirra looking at the name and seeing where Disk 1 or Side 2 etc is and mounting in numerical or alphabetical order..

 

Just asking about how much work it would be?

 

Too much for the payback?

 

Remember I'm not asking as a request, just the feasibility of it as its a lazy / novelty feature.

 

Not hard, although I'd have to go through the details and probably create an option for it. The way .zips currently work with multiple supported images isn't ideal -- I've been tripped up myself a few times by not realizing that there are multiple files in a .zip.

 

One other question that occurs to me is; does the '*.ATR' disk format even store discrete details like number of sides and density of sectors/tracks in the first place? Are these data kept in a header that Altirra could read when the image was first inserted and so do its geometry compliance check? Perhaps the default format for disk images that Altirra produces and saves should be the '*.ATX' format of 1:1 VAPI clones? That format does keep these data I believe.

 

As others have noted, ATR doesn't store any information about disk geometry. It only stores a disk size and a sector size. This means that some disk geometries are actually ambiguous, as there is no way to distinguish a 40-track double sided image from an 80-track single sided image by sector count. The way Altirra deals with this is that it has to guess the geometry by a hardcoded table mapping from sector counts to track/sector/head counts. Fortunately, this doesn't matter most of the time as the main Atari disk interface is only by sector number (LBA, pfft... Atari had that years ago!), and it only surfaces when DOS uses the PERCOM block commands or accurate sector timing is needed. ATX won't help as it only supports SSSD disks, and AFAIK there is no format other than ATR that can handle extended disk geometries beyond SSDD. That means pretty much all that having track/sector/head fields in the New Disk dialog would buy is saving a few keystrokes in a calculator... not very compelling. I've added the DDSD 80-track format as it's at least unambiguous.

 

In my opinion, it would be useful to have an extended disk format that could supplant ATR/ATX, but building enough momentum for a new file format is difficult, especially since there are not a lot of programs that manipulate disk images that are actively updated.

 

You can't read a flippy disk in an XF551, or any unmodified double-sided drive for that matter. The disk is rotating the wrong way and there is an offset between the top and bottom heads. The disk would have to be flipped even in an XF551. Therefore, there's no real point in tying disk flip behavior to the emulation mode.

 

[Shawn Jefferson]

Actually 'Wizard's Crown' was somewhat like that. It didn't actually expressly insist on multiple disks but it certainly helped! It really was a fantastic game and in my opinion head and shoulders above the somewhat self-satisfied 'Ultima' titles - not that I didn't enjoy those also. I felt so... betrayed... when the sequel 'Eternal Dagger', despite what the advert in 'Page 6' promised was only released for the paltry Commodore 64!

 

I'm sure Eternal Dagger was released for the Atari 8-bit. Yep, here:

http://www.atarimania.com/game-atari-400-800-xl-xe-eternal-dagger-_1882.html

[morelenmir]

Many thanks for adding the extra hard-coded format type Phaeron! I hear what you are saying about the putative extended dialogue only saving calculator strokes... But that is still a worthy ease-of-use feature and - to me at least - I suggest it would remove SOME of the ambiguity, even if some of the permutations you could create would be equivalent.

 

I was also myself starting to think about a new format! Something that would hold all the data necessary wouldn't really be very hard to imagine; an extended - and perhaps user-extensible - header system would do it. Ideally it would be nice if it were user editable as well or at least something you could load in to a hex-editor and read very clearly. I once invented a similar thing for use as the framework to hold a one-time pad based file archive that could be spread over multiple disks/volume and each volume was, aside from the individual spanned file - if any - independently de-encipherable. That was a lot of fun and not a million miles away from what is needed here, other than the need to span files obviously.

 

The problem of course is getting other people to use it! That said you control what is the premier A8 emulator currently available and so carry a LOT of weight. I think anything of that nature you implemented would start to appear in the other emulators...

[morelenmir]

 

I'm sure Eternal Dagger was released for the Atari 8-bit. Yep, here:

http://www.atarimania.com/game-atari-400-800-xl-xe-eternal-dagger-_1882.html

WOW - that is the first time I have seen that!!!

 

Back in 1997 when I first gained access to the internet I scoured all the Atari sites I could find for 'Eternal Dagger' and NEVER turned it up! MANY, many thanks Shawn!!!

 

There was even a PC version of WC, but again no EtD... Go on, point me in the direction of that port too...!!!

[Shawn Jefferson]

Sure, right after you tell me of the long lost Ultima V port that I missed.

[Kyle22]

...Currently, no. I have avoided implementing write support so far due to an irrational fear of accidentally destroying disks. Also, R/W support requires additional program code to unmount the disk first as Windows will not allow write access to a mounted partition. You can, however, go through a VHD image as Altirra mounts VHD images directly without going through Windows, so it would be possible to clone the VHD onto the CF card.

 

 

Thanks for the info. So, would a dd type tool work for this such as SelfImage for Windows? Also, what about R/W support on the APT partition that Windows doesn't mount? That would be perfect. I don't really care about the FAT32 partition in this case, because I want to read the files directly from SDX.

[morelenmir]

Sure, right after you tell me of the long lost Ultima V port that I missed.

Now that I do have!

[morelenmir]

Is there any reason you haven't emulated the 'TurboFreezer' Avery or is it just a case of 'same old, same old' with much the same functionality available in currently existing simulated devices?

[Keatah]

I used to use this weird 'nibbler' contraption my father had for metal working to notch my flippies. It was kind of like a tiny hand powered and counter-sprung guillotine that 'nibbled' away a small, perfectly square chunk of whatever you were trying to cut. I suppose it was a bit like a cross between a grip-trainer and a hole punch! If I was really careful I found I could notch new disks perfectly with that thing and never wreck the media inside... Wow... I haven't thought of that for - genuinely - decades... I wonder where it is now!

I couldn't afford anything so exotic as that. I had to settle for a hole punch they threw out at school. My first experience with trashing!

[Mclaneinc]

Every one I knew had a nibbler, I just used a pair of fine sharp electronic snips, 3 quick cuts and you had the same thing

 

I actually knew one person who created a jig for cutting the notch out so it was exactly in the same place as the other side of the disk..Mad..

[fujidude]

For quite a while I used scissors to get the job done. Then I bought an inexpensive tool made specifically for the job. I think it cost around 5 to 7 dollars if I remember right. It was like a jig in that it always lined up correctly. It had a plunger with the cutting suface. Worked great. I think they were called disk notchers.

 

In fact, I think I wad this very brand...

 

[fujidude]

Speaking of Altirra and disk images.... is it possible to use the BlackBox emulation to simulate industry standard (360K - 2.88MB) floppy drives? If so is anyone here doing it? I know that was done on the real BB via the floppy board. Is that part of the BB emulation in Altirra?

 

Anyway, it would pretty cool to be able to interface emulated industry standard floppy drives to the emulated Atari within Altirra one way or another. Either through BB emulation or possibly even better just through Altirra itself more directly.

 

I do know I have been able to create some custom disk images of those larger sizes and get them to work in SDX 4.4x under Altirra. Maybe that's good enough. One can always hope though.

[flashjazzcat]

I think I've found a strange discrepancy between the behaviour of the Ultimate 1MB main BIOS mappings on real hardware and in the emulator. This occurs immediately after power-up/reset when the config lock is off and the BIOS ROM is mapped at $C000-$FFFF (with hardware and BIOS RAM present at $D000-$D7FF). In the emulator, I'm seeing unexpected and disruptive addressing behaviour in some regions above $E000 (areas normally unused by the stock BIOS). Assuming this to be some strange mapping quirk, I tried the same experiments using real hardware and the problems do not occur. Not sure if some OS patch setting is to blame or what, but it's definitely not reflecting real hardware behaviour.

 

EDIT: Actually something in the $D800-$DFFF region seems to be behaving oddly. Dumps of the mapped in ROM in Altirra compared with the original ROM reveal no differences, but something's definitely getting clobbered somewhere.

Edited May 5, 2015 by flashjazzcat

[morelenmir]

Every one I knew had a nibbler, I just used a pair of fine sharp electronic snips, 3 quick cuts and you had the same thing

 

I actually knew one person who created a jig for cutting the notch out so it was exactly in the same place as the other side of the disk..Mad..

That's not mad Paul! That sounds perfectly sensible to me!!! It used to drive my dad crzay when I knicked his nibbler for the flippy cause. He said cutting the plasticized cardboard stuff on the disks blunted the blade and they cost him a fortune. Bearing in mind he came from Barnsley, so the Yorkshire-Parsimony-Exchange-Rate worked that out to be about £2.99 from Wickes...!!!

 

One thing I have noticed while playing with the 'BlackBox' and 'MIO' is; using their built-in hard-drive dialog is very pleasant as the loader automatically detects the geometry of the simulated hard drive from its physical storage file. However the all-but-same dialogue for hard drives from "System->Hard Disk->..." does not. Would it be possible to fix this and use the same underlying routines in both places? Again, like an expanded wizard for floppies it is not essential but is certainly a very comfortable ease-of-use feature. As it stands I incorporate all the geometry data into the file name for the simulated hard drive storage file. That can quickly start brushing up against MAX_PATH depending how far the folder which contains it is buried.

Edited May 6, 2015 by morelenmir

[gozar]

I just used a regular hole punch that we already had.

[phaeron]

Is there any reason you haven't emulated the 'TurboFreezer' Avery or is it just a case of 'same old, same old' with much the same functionality available in currently existing simulated devices?

 

Not a lot of demand, a bit invasive to the core hardware emulation, and the debugger does substantially what you'd want to do with the Freezer.

 

Speaking of Altirra and disk images.... is it possible to use the BlackBox emulation to simulate industry standard (360K - 2.88MB) floppy drives? If so is anyone here doing it? I know that was done on the real BB via the floppy board. Is that part of the BB emulation in Altirra?

 

Anyway, it would pretty cool to be able to interface emulated industry standard floppy drives to the emulated Atari within Altirra one way or another. Either through BB emulation or possibly even better just through Altirra itself more directly.

 

I do know I have been able to create some custom disk images of those larger sizes and get them to work in SDX 4.4x under Altirra. Maybe that's good enough. One can always hope though.

 

No, the Floppy Board isn't emulated. I'm not even sure I have any technical information on it, although IIRC it had its own CPU and RAM. ANTIC DMA makes it hard for the main CPU to keep up with an FDC, so usually either a secondary CPU or a DMA controller is needed.

[Heaven/TQA]

Disk swapping killing my first 1050 (the metal clip):

 

- alternate reality

- ultima 4

- wizard's crown

- eternal dagger

Edited May 6, 2015 by Heaven/TQA

[Heaven/TQA]

Btw as tinkering with 5200 dev. Following questions:

 

- pal? Is the 5200 only NTSC? Can not switch the emulation to PAL

- break points with wudsn/mads? In XL emulation everything works as designed but 5200 no break points support? I mean source level triggered BPs

Edited May 6, 2015 by Heaven/TQA

[xzerix]

If memory serves, the first version of the 5200 had four ports and was NTSC only, and the second version had two ports and was PAL or NTSC. Which Bios are you using - the four- or two-port one?

[phaeron]

I disabled PAL/SECAM for 5200 mode because, as far as I know, a PAL version of the 5200 was never released. There were a couple of games ported, and the revised motherboard may have had provisions for it, but it didn't ship. Let me know if you have a reference otherwise.

 

Source debugging should work identically in 5200 mode. Check if you can do Go To Source from disassembly view -- if you can't, the source line information isn't coming through. The list modules (lm) command will show what symbol files are loaded. You need the listing (.lst) file for source line association to work.