MikeFulton

I've not tried Altirra. I'm working on a disk image management tool.

I am looking for information about the disk layout used by Atari DOS 3. Not interested in how to do DOS calls in BASIC or anything like that. I need to know things like the sector layout, directory format, VTOC info, etc. I have already googled for this, but the results don't seem to include any technical info. Thanks!

Everybody seems to be going out of their way to misunderstand what I'm saying. To be clear, I'm not talking about a single zip of the entire site. We were talking specifically about the Holmes stuff which was mentioned as being 700mb. A 700mb file isn't a huge download these days. I download bigger files all the time. A modern game demo could easily be 10 times bigger than that.

Had tried an older version long ago and just downloaded 2.2. I guess the big question is, what's the deal with the keyboard? I mean, I don't really want to hit Shift-2 on my PC keyboard to get a double-quote, even if that is how you do it on a real Atari 8-bit. Can't we have an option to use a translated keyboard? I didn't see the source or I'd jump in and just do it...

Sigh... Not saying that it should only be a single big archive. I'm saying that in addition to the individual file downloads, there should be a single ZIP with everything. Because a lot of people will want to download it all, and doing 6000 files of a 100kb each via FTP is extremely inefficient compared to doing a single big zip.

Strictly, an "IRQ" (Interrupt Request) is an electrical signal to the CPU from an outside source (like Antic or Pokey) telling the CPU "interrupt what you're doing and process this other thing". There are a wide variety of things which generate IRQs. Most common are timers and hardware events like the vertical blank for video, or things like control lines on an I/O port. On the 6502 and most other processors, an interrupt can be maskable or non-maskable. A maskable interrupt can be turned off or disabled in hardware, while a non-maskable interrupt (NMI) cannot. Typically, an NMI is used for things that are especially time sensitive. There are often certain conditions in the processor which generate a similar condition known as an exception, but this is not strictly the same thing as an IRQ. Also, people often say "IRQ" when they really just mean "interrupt" or "interrupt handler" (referring to the code that is called to process the interrupt) but this is not really correct usage. On the Atari, you get an IRQ from each vblank, and for any scanline where the display list indicates a DLI should occur. These are both NMI. A VBI or DLI routine would be an example of an interrupt handler processing the resulting interrupt. If your display list specifies a DLI to occur on the last scanline, the interrupt handler can take much longer than DLIs from other scanlines. By "disabling the VBI" and using the DLI instead, someone is trying to gain more time in the interrupt handler and still get the same 50/60hz timing that a VBI would provide. By the way, they're not really disabling the VBI interrupt at the hardware level, since it's an NMI that will always fire as long as the video is turned on. They're just disabling the handler that normally runs in response to the interrupt.

I was talking about the specific folder, not the entire archive. Although, a single ZIP for the entire archive wouldn't be a terrible idea either.

It wasn't presented as FTP... until now I didn't even notice that "ftp" was in the URL.

Whoever runs that site seriously needs to make an "everything.zip" file. I mean, it'd only be about 2 mb at most so why not?

First, FlashJazzCat, you were right about me counting from 0 instead of 1. However, it turns out that sector 5 on my disk image was corrupted, which is why it didn't make sense as a sector map. I started looking at the rest of the disk, which is mostly ACTION! source code, and found a few sectors that have garbage intermingled with the expected ATASCII text. This got me wondering, so I dug out an archive CD-R which had all my old 8-bit stuff on it. When I looked at that version of the same file I discovered they didn't match. Somewhere along the way, things got messed up. So now I'm starting over with new image files, freshly formatted. Thanks for your time, everybody!

Not an ATR. It's XFD, no header. I'm writing code that reads existing disks. Don't really have the option of specifying a particular version. I will double check that idea later when I'm not on my iPad. However, the sector preceding the directory info didn't appear to be a sector map, so there's still that.

Can someone post the disk images here?

That's not what I'm seeing with my SpartaDOS Construction Set disks. There is no sector map and the main directory starts at sector 5. Can you put a file or two on there and post an image file?

Thanks for the link. Oddly, the file system is not explained in the programmer's guide, which I already had. Unfortunately, it looks like this manual is the source of the information on the webpage I was working from. The manual includes the same error, and doesn't say anything further about the main directory's sector map.

OK, this question is going out to anybody who knows anything about details of the SpartaDOS file system. I'm using the information posted at: http://atari.kensclassics.org/dos.htm#sparta. I've determined that there seems to be a mistake in the information posted, and I'm trying to fill in the gap. Specifically, the info on that page says that bytes 9 & 10 of the boot sector contain the "First sector of sector map for main directory" but I have determined that they actually point to the first sector of the directory itself, not the sector map. Now I need to figure out how to determine the sector map for the main directory. Or, maybe the main directory is a fixed size and doesn't use a sector map. I dunno... anybody who has a clue about this, please let me know. If you're asking yourself what a "sector map" is in this context, you're probably not the one with the answer to my question, but I'll try to explain. With Atari DOS, and most of the other variants that are compatible, the directory entry for each file specifies the first sector used by the file. The last 3 bytes of each sector specify either that this is the last sector of the file, or the number of the next sector in the file. SpartaDOS does it a bit differently. For each file or directory, there is a sector map which indicates which sectors are used. A sector map is one or more sectors which contain a list of sector numbers that belong to the file.

Yawn... Ok, it looks like two things need to be done. First, the hack needs to check the device ID and abort if it's not a screen device being opened. Next, it needs to run at every screen device open workstation call, not just the first time. That may also require a frame buffer check so it doesn't allocate a new buffer each time.

Well I'm half asleep and reading it on my iPad, but looking at the STEEM source, it looks OK. But it's probably not hooked in correctly. It looks like they grab the trap and stub in the code in such a way that it only runs on the first open workstation call. I need to look at it awake.

Banging the VDI screen driver variables ("line-a" isn't really accurate in that context) is all that's really needed, but they're apparently doing it at the wrong place. If it was properly hooked in, GDOS wouldn't matter. Well, maybe I'll look at the sources. I suspect I'll have the same issue with Hatari...

That didn't explain things as much as you may have hoped. Do you mean multiple objects with the object processor where blending is required instead of simple prioritization? Or are you talking about just doing some sort of blending during a normal rendering operation?

I think it's very simple... the 2600 is what most people think of when they think of that "old Atari game system". And there's no getting around the fact that when you compare the 2600 and its games with systems made just a couple of years later, the 2600 graphics are fairly primitive and most of the games are simple and repetitive. This is not intended as an insult, just an acknowledgment of the reality. I've loved my 2600 back when I was a kid, but let's not kid ourselves about it. By comparison, something like the original NES or the Sega Master System is a lot more sophisticated than the 2600. Now, with that whole idea in mind... follow closely and hold on tight because here's a sharp left turn. Consider that when most people go camping, they don't get naked and hike 20 miles into the mountains without a knife or a canteen or a tent. They drive into the campgrounds with their car, set up their tent and maybe blow up an air mattress, then they use matches to start a fire using the firewood they bought at the grocery store, or maybe turn on the propane heater to keep things warm, and if they don't catch any fish for dinner, they open the ice chest and have some sandwiches or fried chicken. In other words, they want to get out into the outdoors and "rough it" a bit, but there's a limit to how far they wanna take the idea. Likewise with many "retro gamers". They wanna play some of those old games, but most of the old Atari stuff is taking the whole idea just a step too far for them. That's not a bad thing, necessarily. It means the rest of the old Atari fans have less competition on those eBay auctions.

The emulator is a means to an end. I have no great desire to fart around with it, beyond what's necessary. I am basically trying to get a development environment together with MultiTOS, Lattice C, and various other dev tools. Today I played around with Hatari for awhile and seem to have gotten it pretty close to working as needed. I've got MultiTOS up and going and LC as well. Some random crashing, and some not-so-random, are the main remaining issues. One point of confusion, however... I've configured Hatari to use 1280x960 but I'm getting noticeably less space in the window. I'm guessing that Hatari is applying the idea of "1280x960" to the overall screen including borders (which I've got turned off) and not the actual useable space. But I've not looked too far into that whole issue since everything else is more or less working OK.

What do you mean by "overlay" ?

Christos, I've heard the exact thing about Aramym a few times, and I've also heard the 100% exact opposite about it. Personally, I've not been able to figure out how to get Aranym to work. It comes up with a config window, but I don't seem to be able to get from there into an actual emulator. And the config dialogs... OMG whomever designed them doesn't wanna meet me in a dark alley, let me tell you. I really haven't had a lot of problems with STEEM. There have been a few very specific things, but overall it seems to work OK. I've tried Hatari for game playing but haven't tried anything more serious. I suppose I'll give it a go.

If I recall correctly, doing 3D rendering with gouroud shading was noticeably faster with CRY mode because only the Y channel needed to be manipulated for the shading. I spent way too many hours on artwork conversion tools for CRY...

It should be noted that Tiny-C is barely recognizable as being related to C. The syntax is drastically altered. It's an interesting thing to play around with (or at least it was back then... today maybe not so much), but that's about as far as it goes.