Rybags

C'mon Jose... and you're the guy who posts mockups as proof-of-concept and says someone could program the game easily.

A scrolling engine with a player that doesn't even move properly and no enemy or other objects that can be interacted with is anything but almost finished.

Don't press fire - nothing other than left/right seems to work anyway. Looks promising but also looks very "early days".

Nope... been sitting in my cupboard for about the last 4 months.

For $600 you could buy a mint boxed XL or XE and populate it with every popular upgrade around and have an infinitely better machine.

You'd be better off just making up a cable or getting someone to make it for you. That way if it needs to be externally programmed again you can do it yourself. Also, the default setup supposedly doesn't have the fusebit settings right and can inadvertantly stop working if you hotplug it into a powered up machine, and has to be reprogrammed externally in that case... and AFAIK to get the correct fusebit settings you also need to program it externally.

Don't try to put the ATR into the cart menu. The purpose of the ATR is to be run on real machine via APE or other modern SIO device to flash the cart. If you've got a USB flash interface then you don't need that - just flash the raw BIN image.

Just chuck a RIOT and TIA in there. Hey presto, memory requirements met and you can play 2600 games as well.

The VCount compare shouldn't check for a specific value. >=133 for PAL is a better idea. It's documented (by Phaeron) but not well known that VCount actually reads 1 higher than it's normal highest value. It's only for 1 cycle or so, but that's enough for software to occasionally see the higher value.

Got a pic or two of a 405 punched card reader somewhere.

That "user input" one was a joke. But yes, doing such input from disk would be a memory saver. Another one if the RAM isn't being used could be to have a RAMDisk handler that uses RAM under the OS. Give it NOTE/POINT ability and you can do nice random access.

To save even more RAM: Get the user to input the variable values: 10000 INPUT V1,V2,V3,V4,V10 Then have a printed sheet with the values the person has to type in for the program to work properly.

I've got a proto 1015 if anyone's interested.

Stick/strig use the same memory amount as Peek. RND has a dummy argument, so any variable name will do. Putting more statements per line is another way to save RAM. Each new line is something like 3 extra bytes. Character sets are 1024 bytes not 2048. Gr. 1 and 2 chsets are only 512 bytes. In my experience, biggest memory saver in general is long lines and using constants instead of numerics. Another huge saver is eliminating duplicate data. Assembler routines are a big culprit there. e.g. rather than having DATA lines where essentially 4-5 bytes are consumed per byte of code, have routines in strings. Downside is they have to be relocatable. Advantage is there's no memory waste other than the 7 bytes or so overhead that a string must have. Where Asm stuff has to be location-specific, load it from file rather than embedding in the program. Initialising variables can be done more efficiently in a big block by reading from DATA. e.g. with your constants: 10000 RESTORE 10000:READ V1,V2,V3,V4,V5,V6,V10 100010 DATA 1,2,3,4,5,6,10

Requires Basic cart... and I bet it's got nothing on Rear Guard.

Physical space is only one aspect. The main constraint on the 800 is lack of required signalling. The second constraint is the closed architecture of the original OS in comparison to the XL. With PBI devices you have built in hooks so that you can have seamless integration (from a software perspective) of things like HDDs, and dynamically loaded/linked handlers if required - and the SIO protocol was also expanded to cater for such instances. Additionally you have the ability to overlay any location in the memory map with RAM, ROM or I/O space from an external device. The fact that the whole thing might look like Cletus towing a uHaul trailer with his '76 Pinto might be a detracting factor, but that's the price of having a compact form-factor machine.

Wasn't a sheep the first animal to be cloned ? I've not played with backup or import solutions yet... my plan is to create a setup using a HDD image in Altirra then put onto flashable media and see if it goes OK on the real thing.

To an extent the board system (esp RAM) was geared towards expansion. But, like practically everything else marketed as "expandable", Atari never supported it properly in that regard. Repeat the story for XL, XE, 7800 and ST to an extent. The 65816 was presented to Atari but after the 800 was discontinued. Naturally if that CPU was used as an upgrade path, the OS probably would have been updated to suit. So in summary, the slot system as employed was a good idea in principle, albeit limited in capabilty, and by the time the opportunity came along to use it effectively the machine had been superceded. Of course we have the 65C02 in the interim, but in reality the small extra advantage it would give is probably not worth it if you look at incompatability issues vs possible gains.

RIP Raster. That's real sad to hear. One of the most prominent figures of the Atari community. His presence is probably there in more than 75% of every new game or demo release of the last several years.

Jaybird3rd here was selling some a year or so ago - boards/chips, no shells. I picked up about 16 of them. When desoldering, the ground pin will be harder to do because the heat floats away into the trace - the trick there is to leave for last and just lever the chip out while heating the pin.

It's deliberate, to disorient the player. There were lots of little strategies like that in old games - even the terrain colour change in Scramble levels was a subtle way of putting the player off.

I do the lowercase + underscore. Much more readable. Couldn't care less about what MS people are doing, 6502 is unique enough in that you'd only really confuse it with 6809 and not much else. The downside though is that the fixed pitch fonts most editors use have a "one" that looks practically the same as lower-case "L".

Xenon (1) would be a much more achievable project. For Xenon 2, charmode would be the way. Those carnivorous flower enemies (or whatever they are) that grow in/out could be done cheaply by having character definitions that are dynamically changed. 2-4 sets of the characters required allow them to be in a different growth phase so they're not all doing the same thing at once.

I don't see the point. The keyboard is always present, so to get the game you'd need Shift-F5 and F3 at the same time. It'd be just as easy to use the pulldown and lauch the ROM. I'd prefer the addition of more RAM configs, like Rambo/Compy 320K, and maybe smaller sizes like 24 and 32K.

Re my earlier one about the disk access logging - is it gone, or still available via a switching command ? It's handy to have in some circumstances.