Rybags

I could possibly help (Canberra) - I've got 2 stock 1050 drives, neither been used in a few years but I don't see why they'd not work fine. I have sufficient modern day emulated devices and interfaces to easily transfer to a PC based ATR and/or individual files. Not sure how much postage would be - I'm guessing probably well under 30 bucks for the trip both ways for that number of floppies. The alternative of course is to obtain another floppy drive - I've not kept an eye on the local market much lately but doubt you'd get one under 40 bucks.

Would be nice if this came out to fill another gap in the arcade conversion list. What would also be nice, probably nicer, would be Exerion. Though the technical demands would be somewhat higher, possibly even more so than Galaga.

Has anyone tried some of the Mac wallpapers? Mac OS IMO is somewhat a pain to use compared to Windows but at least they maintain high quality with the wallpaper.

Remember here that the 1064 replaces all the internal Ram with it's own and it would be the case here also for a 600XL. No doubt the jumper would be to select 1064 or banked mode - if you put the first card in banked mode in a 600XL then you'd likely get 16K base RAM only, with the extra Ram appearing if selected through the banking register for 32K contiguous.

There's various methods of SIO that can be done - unclocked, clocked by internal or external source though most usage cases see the clocking done by Pokey. You can also bit-bang but it's a fairly rare thing - the default cassette handler the only OS based thing that uses it and only for determining timing requirements at the start of each block read. Pokey does the byte level IO automatically for you but it uses 0 start bit, 8 data bits lsb first then a 1 stop bit. You get no choice to change any of that (unless you bit-bang). Many external Atari and 3rd party peripherals just assume a default bitrate or use special commands to set a higher one and don't use the clocking facility. Generally the stop to start bit transition is sufficient to compensate for any slight timing differences. All the signalling is 0/5 Volt levels (though the specs have high/low voltage levels that are assumed for 0 & 1s) Depending on what you want to do you can either have your device behave like an Atari smart peripheral, waiting for the Command line to go low then reading the command frame and responding if the device ID matches your own. Or just act as a dumb peripheral, assuming it's the only device on the bus and deal with the raw serial data. Tutorials and such - not a great deal around I think. I wrote a 1050 emulator on the ST about 30 years ago and referred to the Atari OS and Hardware manuals - they have needed stuff like the framing and command protocols and timing requirements (e.g. if your device responds too fast it can be missed) I no longer have the source for it - I sold the ST I had and it was on floppies for DBasic which in itself is probably a lost product as it uses a custom 1K sector format.

A barrier to progress there is that for whatever stupid reason, just like the 2600 the 5200 has no /W line on the cartridge port, though it does appear on the expansion connector. As for configuration ideas - yeah, a cartridge with decent amount of Ram and flash that could act in different ways would be a cool idea. Like default to having Rom with the startup vectors appearing where they need to be, then allowing bankable config of flash and Ram in various ways in 16K chunks in the $4000 and $8000 areas.

Notable that there's a comment from Cathryn Mataga there also.

Save/restore is up to the programmer. Alternatively if the sprite objects are all that VBXE bitmap is being used for you could just do an erase operation. Of course when doing these they should be done in the same sequence for your active objects to prevent garbage appearing.

The X register is what's important there. It'll be $D6 or $D7 indicating the base page if VBXE is installed or $00 if it isn't. A, Y will hold $40 if VBXE is installed otherwise A = $00.

Cheers. I suppose one downside, lockdowns could mean nowhere to go with registration time dwindling away?

What'd be nice is if they'd provided the /Halt signal which the ECI has. Then possibly we could do DMA read/write access which could mean IO speeds only limited by cycles lost to Antic screen and refresh cycles. Then we could have faster SD card access and may as well throw a blitter in there as well. And may as well throw in a bit of external Ram and have the blitter capable of rendering character and bitmap softsprites.

Another thought - you could employ a "dummy" mode where a call doesn't do register updates, only bumps the pointer. Then you could keep indexes and be able to start the song at predetermined positions if needed. Sure, it might waste a frame or three doing the cue process but generally such events in games are usually if you start a new level or life.

80 column mode productivity is only possible by outside software enhancements, ie drivers and/or specific software that's VBXE aware. AFAIK nobody has produced a Rom based OS that is VBXE aware. SpartaDos - unsure if any of the Rom based ones have VBXE software or drivers included (entirely possible some might). For programming, the manual included is sufficient. The firmware update package will also have example software including source code. Some people have created webpages with demo software and lists of software that utilize VBXE.

If a voice is left alone by the RMT music, will RMT2LZSS also leave it alone? In theory you might then be able to use a modified RMT player to do the sfx portions - which in most cases should be pretty light on the CPU use.

According to the Sophia manual there's a bit setting to allow disabling the Gr. 10 pixel offset. Though you would expect the default to be to have the offset as normal hardware does. Possibly Simius or someone with one installed who's played around with the extra features could help out here?

Most likely usage case - have a hotkey that can do a coldstart without clearing extended Ram, then boot your favourite Dos from the Ramdisk. Initial startup of course would see you needing to populate the Ramdisk with the bootable image which would be slower than a normal boot but in theory you could work all day without need for slow Dos startups. And in theory play normal disk bootable games and still have your Ramdisk images intact.

If you just wanted the 1K + hundred bytes or so around $CC00-$CFFF you could copy the OS to RAM and overwrite the second character set.

PORTB Bit 4 turns the CPU access to extended 130XE memory at $4000-$7FFF on and off. If the screen lives in that area then you could easily corrupt any data you have in extended Ram. If a Basic program is in there, which is very likely if a Dos is loaded then you potentially switch part of it out and crash - and not forgetting stuff like strings and the stack for loops/subs lives above the program. Also remember, default bitsettings for everything except Basic are 1.

Will be very good to see this game come to it's proper conclusion - even better if done so in an unconstrained fashion by the original author.

Yeah, get well soon TMR! I've got Type 2 Diabetes and some CPLD/Asthma as well thanks to 30 years of smoking (stopped over 8 years ago now) so don't look forward to the possibility of getting Covid.

Looks a lot like some of the XL keyboard variants. Are the key rows stepped (hard to tell from the pics but they look almost flat) Also relevant would be the age (serial #) though it has encased Ram boards which probably means it's not a later one.

You also need to store 3 in GRACTL so GTIA knows that the PMG DMA is occurring. Also note, PMBASE doesn't point directly to the graphics data, there will be offsets depending on double/single resolution mode. 384/768 bytes unused followed by missiles then the 4 players, seperated by either 128 or 256 bytes. Plus, PMBASE has to be on a 1K/2K boundary depending on res.

I did a game on the PC around 1987... on a work machine, not sure if it was GWBasic but it did have statements to do rendering and collision detection of softsprites. Never saved a copy or printout for myself so it's gone now... though in theory could be recreated without too much effort.

You'd want to retain the checksum (validation from within the OS doesn't much matter) because there's still that odd bit of software (mainly Electronic Arts?) that does it's own validation (though possibly it just checks against hardcoded values for the 400/800 only)

Flash based multicarts will usually have project files associated so you can just keep them on the PC. The Atarimax flashcart writer interface (USB) I believe allows backing up most carts. Host based backup is equally possible though if it's not a known banking scheme it could be tricky. Note of course copying a cartridge is only part of it - there's no guarantee a backup will work by loading into RAM. And banked cartridges only work unmodified if copied to a cartridge that uses the same banking scheme.