Rybags

There is the chance that the 1020 draws some power from the computer, depriving the interface of sufficient Amperage. As ridiculous as it seems, the 410 and 1010 tape drives at least also do the same, even if powered off and not being used - I didn't know that at all until the recent "discovery" of the ability to generate a 6th "voice" by using that feature to create sound by toggling the drive control on/off. As for what pins are used - as a minimum a semi-intelligent SIO device, ie anything other than a tape drive, uses Data In, Data Out, GND, Command. But daisy-chainable "middle" devices will pass through every pin whether it uses the signal or not.

It was obviously just a means to minimise their losses, avoid tax, etc etc. If they'd looked at where the market was going, they could easily have gotten on the multimedia bandwagon at just the right time. They could quite easily had outflanked the likes of ATI, 3dFX and nVidia if they'd hired the expertise and just concentrated on the niche that they had already tried (and largely failed) to dominate with the ST/TT/Falcon.

If he's using an RF -> SVideo convertor then it should do audio seperately as well. Unless he's already got the convertor, it's a kinda roundabout way to convert an ordinary signal over crap medium to a crap signal over reasonably good medium. Way better off just doing one of the video mods to the console and get S-Video direct.

How about something other than the 1020 as the middle device? Could be that the 1020 is barely letting the signal through and it's below the interface's threshold, or maybe the interface just needs a certain amount of current in it's signals to work properly. Is the interface powered by the SIO plug or does it use an adaptor? Another factor might be that it's relying on the +5 V supplied by the computer. Some devices such as certain tape drives use that current to drive part of their circuitry.

How about - go back to previous with the faces, and give them some different colours in the collars.

The majority of the grunt and cost of modern consoles is the CPU and GPU power required just to render a hires screen. A remote "dumb client" type of setup would probably end up being something almost as highly spec'd as a full-blown console, not to mention costing almost as much. The big 3 are getting kinda old insofar as the graphics tech compared to what PCs have available - sure they could have made the consoles with dual port graphics output to run 2 TVs, but in doing so you're effectively halving the rendering capability when 2 monitors are in use. Not to mention the fact that if they did make a system as you've suggested, they'd probably be slashing their profit margin even further... AFAIK the XBox at least is sold at or under cost and requires the sale of a few games before it turns a profit for M$.

That doesn't sound right, it's as if the +5 is getting through but the Command or Data line isn't. How about try a disk drive or something else at the end of the chain. I suspect you might encounter the same thing. Device ID shouldn't matter - when SIO devices are powered off they obviously don't take part other than passthru mode, and even powered up a SIO compliant device that's working properly doesn't have the means or reason to be able to inhibit communication to devices further down the chain, regardless of what their type/ID is. You might also want to test the 1020's SIO jacks with a multimeter. Power it off, disconnect everything. Each pin should have continuity to the corresponding pin on the other jack.

A full 64K swap would be nice for user-initiated task switching, but yeah, you'd either need OS code, or to have a preloaded fall-through piece of code that sat somewhere in RAM and hopefully didn't get wiped. Another possibility might be to have a full swap with the ability to have a small window that can overlay temporarily, then use a bit of the stack to handle the final swapover and jump. I've been meaning to write up a task-switcher to use under VBXE. It can map up to 32K wherever you want, so you could have it do task-switching among half a dozen or so virtual machines, just need to move the remaining 30K the old fashioned way.

http://www.atarimax.com/jindroush.atari.org/acarts.html There's a reasonably complete list there. I don't think it has second Pokey listed, AFAIK it's never gone beyond a homebrew DIY thing. In theory you could easily map 16 extra Pokeys to the $D5xx page via cartridge, but of course you'd end up with something almost as big as the computer's motherboard.

It depends on the location and what's included. I'd have grabbed a Portfolio by now, but I don't think a single one here has gone for under $120.

First off - are you talking about the RF signal that the 7800 generates by default, or do you have an addon board that ouputs better video? If you have an addon board, you should be able to drag seperate chroma and luma out of it anyway and use a more direct approach. You can get joiners that take an S-Video signal and combine it into composite RCA for about 3-4 bucks. Other way around isn't really a valid way to do things. S-Video has chroma and luma distinctly seperated, and you can't really seperate those signals with a simple passive plugin device. TVs and monitors will actually seperate chroma and luma from a composite input as part of converting it to native RGB to drive the tube/panel. You might get lucky, some devices are smart enough to recognise that the S-Video input has a combined signal coming in, I think one of my PC capture cards used to do that. But as I said, a passive device won't do any conversion to the "better" standard so it'll be anyone's guess as to whether the monitor will like it. An active converter in theory could produce the two seperate signals for you but what you'll end up with won't be as good as a native S-Video signal.

STacy would be worth a fair bit - even Portfolios fetch upward of $175 here, so I'd imagine $250 as a bare minimum. STBook http://www.atarimuseum.com/computers/16bits/stbook.html I'd imagine that to be very rare, as the article states it never sold and only around 1,000 units were shipped for evaluation.

No problems. The people involved should have it ready sometime inbetween lunch and afternoon tea.

The 5200 Choplifter is obviously reworked to be able to run in just 16K of RAM. Isn't the computer colour version a later XE type? Plenty of those cartridges are a bit unconventional in that they only use the ROM as a kind of big virtual disk drive. The game itself is actually copied into the machine's RAM and run from there. Nothing really wrong with that, makes no difference to the gameplay but it does mean it won't work on older unexpanded systems. In theory it would be entirely possible to hack the 5200 Choplifter to be able to run on a 16K computer on homebrew cart but the effort vs how many would actually benefit means it's not worth bothering.

Space Invaders (2600) IMO was quite possibly the best licenced conversion to any platform. Super Breakout is also better on the 2600. They did a great job with the sound effects given the platform. Galaxian on the A8 is kinda crap. Haven't played the 2600 one properly but the A8 version has totally rubbish sound and the gameplay is nowhere near the arcade. The graphics are fairly good but good graphics don't mean good game. Centipede, haven't really played the 2600 version but I reckon the computer version is pretty good. But then Millipede came along - much faster gameplay and a better overall package. Donkey Kong on the 2600 is a bit of a joke. But given the machine's capabilities you couldn't expect much more. They probably could have done the sound a bit better. The A8 computer version is in some ways better than the arcade,. Asteroids is a bit of a disappointment on both systems - at least with the 2600 version they bothered to give them different colours, the computer version would have been better if done in hires line-art. But I'm fairly sure Asteroids was one of those early carts that were compromised because it was made to run on an 8K RAM system. No doubt it also could have been made better if they used a 16K ROM. Pacman, there's no comparison. No need to repeat almost 30 years worth of disappointment about the 2600 version but it's clear from later Pac variations as well as hacks and homebrews of the genre that what was released is just a botched rush job compared to what could have been.

Main machine 800XL: VBXE, plus external RGB->SVideo converter pending installation 32in1 OS RAM 320XL, Total available RAM 830K (62K int + 256 in RAM320 + 512 VBXE) External SIO2SD

Err... I don't think so. The MMU or whatever equivalent logic the machine happens to use depends on the S4 and S5 inputs to "know" whether a cartridge is inserted. In such cases, access to RAM at the relevant area $8000-$9FFF and/or $A000-$BFFF is then inhibited and the RD4/RD5 Chip Selects are activated instead. Of course the exception comes in the form of certain carts like the OSS and AtariMax ones that have the ability to disable/enable the cart via software on the fly. But, I believe the /CCTL should always work ($D500-$D5FF access). That allows carts which only have hardware registers mapped to that page, e.g. homebrew Covox, second Pokey @ $D5xx, RT8 cart.

1010 tape drive, put SIO2SD in there too. Or maybe it's a bit small. Is there link/pic for IDEa? I'm thinking I might have to get working on an IDE interface myself soon.

If you've got some Sally 6502s, I might be interested. They're CO14806. Pokeys are still in mega abundance, jaybird was selling a bunch last year and I grabbed 16 of them.

I'd say yes. Probably use PMGs in OR (PRIOR=00) mode. Probably fiddly in places, you'd need all manner of positional, size changes etc. Also probable that some black areas would be saturated with the player colours. Get Jose onto it.

Maxflash studio can export ATRs which will program the cart from the Atari side. You can perform erase/flash-write operations with your own program on the Atari but it's not a straightforward process, plus there's a minimum block size that has to be programmed (64K for the 8 mbit and 16K [?] for the 1 mbit)

Looking at the 1064 schematics, it appears to just run /RAS through LS04 invertors 4 times in order to get a delay.

There's a toerag over here doing similar - selling all manner of homebrew, emulators and dumps of old games as downloadable items. I reported him, but as always I suspect eBay will do absolutely nothing about it.

Using software, I got tape to about 800-850 bps reliably. The OS in fact can handle a range of speeds from something like 500-900. The baud rate for writing is hard-coded but I just got around it by using a VBI that forced values into the AUDF registers to increase it. You can't directly quantify baud rate to load time, it's a bit more complex. The leader has to be at least 5 seconds or so. The IRGs are about 0.25 seconds, so by default you've got ~ 2 seconds of wasted time per KB loaded. Also, tape records are 132 bytes of which only 128 are data, so that's around 3% overhead there. When I only had a 1010 I wrote a custom hi-speed loader for the AsmEd cart image. It had a standard boot sequence of about 2 or 3 blocks, then did a SIO call that loaded the entire 8K image as one huge block without gaps. The entire thing was saved at high speed and I used a shorter leader (just don't press REC until a few seconds has passed). It loaded in little over half the time that a normally saved version would have. The added bonus of such custom loaders is that they can be made practically impossible to copy using the computer, it's kinda surprising that hardly any software used them.

It's true stero - the second Pokey maps to it's own address area and has a seperate audio preamp and jack.