-
Content Count
49 -
Joined
-
Last visited
Posts posted by MikeFulton
-
-
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...
-
Rather wasteful of bandwidth if all the user wants is (as in this case) a single ATR, though, especially when the option exists to bulk download for those accessing via FTP.
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.
-
I see the phrase "IRQ" mentioned and I'm not 100% sure of what it means.
From what I learned at university, an IRQ is an "Interrupt Request".
So can an IRQ be a vbi routine or a dli routine or both or neither?
I sense but am not sure that people are saying that you can use a DLI as an IRQ, just making it run much longer than they normally would. Is this right?
I've even seen it mentioned that the VBI has been completely disabled and instead code is running from a DLI on the final scanline of the screen. Why would somebody want to do this, what are the advantages? Is this an IRQ?
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 don't understand. The link is only DOSes. http://ftp.pigwa.net has Holmes archives 1,2,3 (about 700 megs), CTH archive (650 megs),
Pooldisk and other stuff, at least 1 GB.
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.
-
If you use a good FTP client, I recommend Filezilla, you can easily select the files(or folders) you want to download.
Using zip files requires downloading the entire file, even if you want just a single item, and unless there is a list of the files contents you don't even know if it contains what you want.
It wasn't presented as FTP... until now I didn't even notice that "ftp" was in the URL.
-
I think you'll find them here:
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!
-
3
-
-
Not an ATR. It's XFD, no header.If the OP is using a Hex editor to read an atr He might be confusing the header of the ATR.
I'm writing code that reads existing disks. Don't really have the option of specifying a particular version.Did the very ancient versions of SpartaDOS not put the root directory at a fixed location, prior to the disk format being revised? I may have imagined that (EDIT: Yes, I did imagine it)... but best to use Sparta 3.2 and up anyway. The documentation is definitely 100 per cent correct regarding current incarnations of SDFS.
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.Could there be some doubt over sector numbering clouding the issue here? Logical sectors on the A8 are numbered starting at $01, not $00. Numbering them from $00 onwards would explain the misconception completely.
Good idea, but it seems to me more than coincidental that if you number the sectors from 0, the value in the boot sector points straight at the main directory's first data sector.
-
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?
-
The filesystem is described starting at page 151 in the manual: http://sdx.atari8.info/sdx_files/4.47/sdx_4-47_user_guide.pdf
Sector maps and directories are explained.
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.
-
I'm really quite bad at C but from the STEEM source code I can see that the authors are banging Line-A at some point during boot to trick the system into an extended resolution. Not surprising then that it should be extremely fragile. Perhaps maybe making an auto folder program that re-bangs Line-A after GDOS loads? (yes I know, dirty hack on top of a dirty hack but it might work!)
I'm not sure at the exact purpose of your setup but is it by chance that you just want a dev environment to compile stuff? Then maybe Vincent's cross-m68k-gcc with gemlib/mintlib is a better choice? (I also have a version that doesn't need cygwin to work, just plain windows if anyone's interested)
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...
-
CRY RMW (Read, Modify, Write - ie, additive mode) is slower because of the additional bus access when using overlayed bitmaps.
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.
-
CRY overlays take longer than RGB overlays, as they are additive (easy to prove, as well, by waiting for tearing)
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.

Atari DOS 3 File System
in Atari 5200 / 8-bit Programming
Posted · Edited by MikeFulton
I've not tried Altirra. I'm working on a disk image management tool.