Rybags

VBXE is more oriented towards bitmap where NES is generally towards tiles and sprites. Though of course you can mix in Antic graphics and VBXE can use blits and has enhancements such as attribute maps and the extra colour bit. The programming effort is likely a bit more on VBXE but the capabilities exceed that of a midrange Amiga. But the CPU in stock form becomes a limiting factor.

With big C64 games though, VBXE conversion or otherwise, you can usually create an easy memory hole by using the sprite area for something else. VBXE also has that advantage with versatility of banking. Used to play this game a fair bit to the point of finishing all the levels. Like most of Braybrook's games, a pretty polished effort.

Runs for a while but then hangs in 130XE mode. I guess there's no game start yet? How do you plan to do the game sprites? This game IMO would probably be a good VBXE candidate. The biggest hurdles though - often these C64 games take up almost all the 64K Ram, 128 vs 256 characters is a pain though VBXE can just use blits to convert character to bitmap. Also, Uridium relies on the 320 pixel Hscrolling, sadly we only get the 160 res scrolling.

PIA should have no bearing on SHIFT, it's handled by Pokey. Yep, 2 keys but no way to differentiate between them.

Without taking away from the pics and utility... got to say that's some good music there on the Atari.

The reason isn't really known. Likely a printing batch error and knowing Atari they probably had 10,000 or more done in a run and decided to use them anyway. Fairly sure it's been discussed before, some years back. I've got one of these carts, so assuming it was sold retail here to begin with, was probably made 1981 or later.

Reminds me of a tree from Necromancer.

Something that would be cool would be the ability to have D1: mapping by a hotkey to allow disk swaps. Maybe a large file container that held multiple ATR images. But then it'd need to be guaranteed contiguous. And the firmware would need to be asssured all the mapping possibilities fall within the bounds of the file. Gets complicated fairly quickly. Or maybe just have a particular partition type that is just assumed to contain lots of small disk images in groups of 4 or something?

I don't think so (I've not used mine in a fair while and am probably multiple firmware releases behind). You can change which one to boot from though. And thanks to the OS versatililty that substitutes the IDE IO method almost transparently with SIO, you can have in effect a floppy image as a drive, it's not really the preferred way to do things.

What's the audio doing? Buzzing or other noise can be sign of overvolting PS.

I think a PBI or ECI VBXE might be possible with pickoffs on the motherboard for extra needed signals. Maybe a simpler passthru for Antic with ribbon carrying the ANx signals. In theory the CSync should be able to be generated independantly rather than taking it off the motherboard.

In the modern day I imagine it'd be fairly easy with a RaspPi or similar board. Or even a VBXE equipped Atari could operate as a slave. Unsure if it could self-host with redirected SIO... possibly a custom OS Rom needed to do that?

Yeah, I think the term just means Instruction Register Graphics which can refer to any Antic mode but was taken on board to refer to these textual graphics modes that were not easily available at the time. No sure if De-Re had the reference but fairly sure some of the early 80s magazines like Compute!, Byte, Analog and Antic were probably using it. By the time the XL included it in the OS it was already in widespread use and the terms IRG and Antic 4 or 5 had already stuck. For compatibility reasons it made sense to do your programming using a modified DList rather than a Graphics 12 call anyway, and it was only a few lines extra code and the graphics handling was fairly easy. Graphics 15 - a different matter since Gr 8 was the only one with the same memory footprint and Gr 7 the only one with the same pixel handling. The technique there was to change the OS screen origin so you could plot to both halves of the screen.

Stepped = like a traditional typewriter. Then there's the straight ones where the keys are level.

There's multiple keyboard types (4 or 5?) for the XL. Generally the non stepped ones have a bit of mushy feel and probably need more travel than the stepped ones. I've had 2 of the steppd ones, the one on my current 600XL IMO isn't as good as the first one I had. I guess also over the years oxidization, dust and wear can mean that they don't work as well as when newer.

Or how about "Hard bell-end"

On the 6502 and non 16 bit derivatives the only 16-bit register is the PC. Zero-page can be sort of like a bunch of psuedo 16-bit registers since the indirect addressing modes use them as such. To copy more than 256 bytes there's generally 3 usual options: . Use extra indexed instructions e.g. lda charset.space+$100,x / sta chr+$100,x . Use a pair of z-page pointers. The usual case there is when the size to be copied is variable or unknown. More coding needed and you usually keep a counter for the # of pages or do a compare when incrementing the high byte of source or destination. . Self-modifying code. It can be done in a compact fashion and can often be the fastest method but hard to debug if things go wrong.

Not sure. I remember having both (bload copies) and playing them reasonably regularly. Probably around late 1984/early 1985.

Interesting - I don't think I've seen Atari's SECAM output before. It looks like it has better saturation than other standards. Do you have a PAL machine you can try with a similar setup?

SET is a directive in some assemblers. Though some similar code worked fine for me testing just now.

Fairly sure there's projects around for PS1 and possibly N64 controllers. Generally the modern controllers use serial comms and the usual interface method is a microcontroller in the middle doing the reading and translation to what our system can understand.

Did they cover Atari much at all though? We had the same named magazine (under licence but different content) here and their Atari coverage was pretty poor.

Conan is Mode E so really not many reasons not to use better colours. But a potential problem that can arise when items use certain pixel values and setting the colours to be true for one thing can make it look bad on another. With just 4 colours or however many available it was always a compromise, and with computers having lesser palettes it was a compromise again there. No doubt if the game had originated on the Atari some extra effort might have gone in. Just a few things that come to mind for Conan: - use some PMGs. - proper colours. - DLIs to allow more colours. - better game engine with less speed variation. One of the annoyances of Conan on the Atari, as if it wasn't hard enough already, was that the speed could be highly variable depending on how much was onscreen. No doubt just the use of PMGs alone there would have made it a lot more consistent.

The animated intro version is much better (different music) Some of the poly noise sound is fairly unique. Plenty around. Koronis Rift, Spelunker (elevator and other), Whirlinerd. The music from some Synapse games. The shared sound effects from the Datasoft platform adventures.

Supposedly 250ns is the upper limit as I'd read in a Ram expansion article for the 400 in the day - 200ns should be fine (250ns equates to a bit under half a 1.79 MHz cycle)