Rybags

The XL OS deals with PAL/NTSC OK but relies on GTIA to detect what system is in use. The main things that are different are the key repeat and bitrate settings for cassette operations. The cassette stuff shouldn't matter if the main crystal isn't changed, and in theory doesn't matter anyway because the overall differences are slight and Pokey can compensate. The key rate - PAL on NTSC settings will be annoyingly slow. There might be software that doesn't work properly on a system modded to PAL but retaining NTSC Antic but it would probably be fairly rare.

Using TRAMSIZ as a cart flag... not sure that's compatible among all OS revisions? Cutting down on code... LDX #$9F CPX RAMTOP BCC GR0 INX STX RAMTOP saves all of one byte Looks like you have 2 loops doing copies to the screen, maybe a single subroutine could save some space? Possibly use last character with high bit set as end of string indicator rather than a zero byte though the code to handle that would probably not save anything here. BASIC MISSING is shorter than BASIC REQUIRED

The forced entry method isn't that bad. It can be made to look more tidy if you set the background and foreground colours the same. You could have POKE 842,12 : GR. 0 : RUN "D:filename" as the last statement.

One thing I've been wanting to try is to "inject" a Basic program into memory (default or location of your choice) then have the environment setup correctly. In theory it should be fairly easily done by using the Atari Basic Source book as reference. Such a technique would be useful to use with a unified Xex/Basic loader or just have as a segment that can be prepended to a Basic program file. But anyway, existing method that I've used in the past. Create a text file (ATASCII) with "batch" commands, e.g. your RUN "D:filename" or whatever. OPEN the file, use whatever IOCB you want other than 1 or 6. Basic uses 7 for things like ENTER and LPRINT, you could use that easily enough. Change location 180 dec to point to the IOCB you're using. I just tried and it works in immediate mode. The problem with using AUTORUN.SYS is that you're likely returning from your program before Basic itself gets run, so the default input file # as described will probably get reset back to 0. Also, some operations in Basic such as LOAD or RUN will reset it, so you're limited to what you can do. But a RUN <filename command> is sufficient for most needs anyway. You could probably overcome that using a VBlank routine which sets the input file # repeatedly then disables itself after a short period - though problem #2, when Basic is run it probably closes all IOCBs.

Small switch might be write protect override. Drive reset - I don't see the point, the firmware is pretty solid and ejecting/inserting a disk should be sufficient to "reset" the drive.

Wouldn't the easy way be to just print stickers and use existing carts? Some/all of those would be banked carts so might need the specific board to work. Likely an existing one could be repurposed. Supposedly the XE carts can be opened nondestructively by inserting one side into a vice, I think there might be a thread around about it.

ATR is just a disk image, the system configuration shouldn't matter. But needing Basic probably means that it has Basic programs on it. Does it have a Dos on it, or just some sort of menu or other boot loader? Possibly it could be modified to switch the onboard Basic in. Or worst case, actually load a Ram based copy of Basic.

That's pretty cool. Would be good to have others to do comparison. We can do triangle and sawtooth on Pokey but I don't think RMT has any support for it - also the range and frequency steps available makes it a bit hard to do music using them anyway.

Basic has the LOCATE X,Y,C statement that will return what colour/character is at that location. Otherwise you could just PEEK the memory location. The formula for would be SC=PEEK(88)+PEEK(89)*256 CA=SC+X+Y*40 Note that if you're talking text window with a graphics mode that these won't work, you'd need to refer to the locations relevant to that. Also - LOCATE will return ASCII code, PEEK will give screen character code which in most cases will be different.

You could get away with using some stack space. Probably half or more pretty easily. Also the printer buffer though it's not a lot of space. IOCBs - 0 and 6 will generally be in use, 7 gets used for load/save/LPRINT so you could use 1-5 if not otherwise being used, so potentially 80 bytes there.

It's a limitation of Pokey. The base frequencies and voice combinations have limitations. If doing 4 voices x 8 bit AUDF then you can usually only have: All voices 64 KHz based (usual default) or all voices 15 KHz based. Then you have the option of using 1.79 MHz base on voices 1 and 3 - in this case it will override the 15 or 64 KHz setting for those voices. Then you have the option of joining voices 1+2 and/or 3+4 - in which case the base frequency of voices 1&3 is used and the combined 16 bit AUDF becomes the frequency value (generally you'd do this in 1.79 MHz mode but doing it in 15 or 64 is also valid though less useful) Assuming you're using just single Pokey and you want those lower frequency sounds then your options would be: Use 15 KHz on 2 voices then join the other 2 in 16 bit mode. Use 64 KHz on 2 voices then join the other 2 in 16 bit mode. (I'm assuming here that RMT should support these options, I'm not an expert on that program) For most needs you'd probably do better using the second option there - the 15 KHz mode has it's merits but for general music the note precision isn't very good.

I'd like to see it running the dot matrix minigames from Cue Ball Wizard.

Nice, but a question. Couldn't the overall board size have been significantly reduced and still been retained by the default screw positions given the amount of component reduction? Though that said, would there be a cost saving to make it worth the effort?

It's pretty well accepted that cartridges need to be removed before running most games or application software. In any case, it's only really language carts that allow a disk boot.

Atari has a variety of blues, greens and yellow/brown variants. Where it suffers though is the reds, especially PAL where we only really have one.

$2000 lower limit is a general figure for when a DOS is present. Without Dos you can assume $600 though up to $680 can potentially be overwritten by the input buffer in some cases. If no language processor is present and certain other conditions you can potentially use memory from $400.

It covers everything AFAIK. Not sure if the bugs are replicated (from memory VBXE doesn't do one of the GTIA modes quite properly) Fairly sure the blit is only scanline accurate in cycle usage. That would only matter in a situation where it's being heavily used and there's timing critical processes. In any case, the blit is the lowest priority for memory access, overridden by general graphics and CPU requests.

I noticed this and the Ridiculous Reality threads bumped earlier today. Both those games I played to death around release time until I finally finished them. Might have to pick them up again. Add RGB (and probably a few others) to that list also.

Generally you want to alter DLists during VBlank or at least after the relevant part has been displayed. Hscrol register - easiest done in VBlank but if you have multiple scroll areas then you'd adjust it just before each area starts. The thing with LMS + Hscrol - each works the opposite way. If you increment the LMS address, the display moves to the left, increment HScrol it moves to the right. A trick you could use is to have a "world coordinate" origin type of system which operates in 160h pixel values. To get the LMS value, shift it right twice then add it to the normal screen origin. To get the HSCROL value, AND it with #3 then EOR with #3. So then you'd have a running set of values like: World X Actual LMS Actual HSCROL 0 0 3 1 0 2 2 0 1 3 0 0 4 1 3 5 1 2 6 1 1 7 1 0 8 2 3

Regardless of Ram type it's probably a good idea to give it a bit more than 3 seconds for a power cycle. Better still is not to power off at all if possible. If you're in Basic just type B. If you have a Dos menu run at E477 (holding Option if needed)

RIP. Sorry to hear that also. Too many around here leaving at a young age, that's only a year older than me.

Pretty much, as well as 4 controllers on 400 (such games usually work on XL anyway)

OK, I played the C64 version and probably did worse. My perception of the difficulty is probably out because I played both with the keyboard and not a stick or gamepad. This game probably isn't suited to keyboard since you're controlling the cat also a good deal of the time and it's just not as easy that way. Have to say though having not played the C64 one for multiple years - top effort on getting this looking and playing very similarly to the original.

First goes just then. It's been a long time, I'd forgotten you have to select the powerup by button/wiggle. Pretty good, I've not gotten far. Maybe a bit harder than C64 Wizball. The delay when you change level or die then re-emerge is a bit too long IMO. Mention of port comparisons - from memory the Amiga version was a big disappointment compared to the original, so far I would rank this one above it at the least.

Suggestions - maybe try an 8 channel stereo version as well ? Request - how about AC/DC "Shoot to Thrill" ?