Rybags

It'd have to be the one near top left with "Coleco" printed on it. On the other side you can plainly see the 2 chips are the 6532 RIOT and the 6507 CPU. Finding if it's pin-compatible with a 'scope... Get the pinout of the TIA, then use outputs from the corresponding pins: . CSync - there should be a ~ 1 ms pulse at a frequency of just under 16 KHz . Colour out - put a game in, preferably one that has a coloured background. You should get a high frequency wave output from this pin. You might want to use CSync as a trigger when monitoring this pin. You could test other pins too such as the Luma ones. In all cases probably a good idea to have a game running as TIA would probably only output on CSync without one. You also should be able to visually check (or just use the continuity test of a multimeter) stuff like the Data and Address buses, the R/W select, and the RDY line. Also, the Luma pins should go through a resistor ladder, so their ultimate paths/destinations will be similar.

Wasn't "wank" an unknown word in the US until Married With Children introduced it?

The thorny one comes later.... "Now that you've got all this extra space... would you like to take in a tenant?"

[ media ] or [ youtube] codes, then have the full URL inside them (remove spaces). End with [ /media] or [ /youtube] tag.

28 MHz crystal is needed due to the scan-doubling. And the revised Core for VGA produces the 31 KHz Sync signals - that has to be the case because the Atari only generates them at half that rate. AFAIK, there is soldering involved to tap this new Sync signal from the VBXE board, then you use that instead of the one from the motherboard.

Why would you need those? Do 30 KHz crystals even exist? They'd probably be 6 inches long if they did. The "modded" VBXE generates the needed signals, the reason the 28 MHz crystal is needed is that the pixel clock speed is twice normal (remember 640x240 mode = ~14 MHz) since it's doubling up each scanline.

Crysal change = you have to desolder the 14 MHz one and solder back in a 28 MHz one. Core upgrade, I would assume is just flashing a new core as per normal. I'd also assume you'd do that, then set the new one as the boot default before doing the crystal. Wiring... fairly sure candle mentioned the need to add a connection or two for Sync - obviously makes sense since the default 15 KHz sync is sourced from GTIA, VBXE in default mode plays no part in driving it. I've had a change of mind for my video convertor... I'm thinking now I'll just put it into a project box. Don't see the sense in powering it all the time from the PC - think I'll just drive it from a wall-wart and put a power switch on the box. Another possibility, if it'll fit is to put it into the XM301 case with my SIO2SD (which is still sitting bare).

The amount of space you have isn't critical. The trick is to create the torrent and have everything nicely in folders, then RAR each individual PDF. Then people can download whatever parts they need, and seed as much or as little as they can cater for.

At the least, it's a new core by candle and you have to change to a 28 MHz crystal (same as an Amiga). Not sure if the core remains fully compatible, to fit new stuff in some cases they have to cut on existing features.

If you did the mod for VBXE @ 30 KHz, then it would work on practically any VGA monitor. But of course, you're still at 60 Hz frame rate which is a bit flickery, PAL is worse off because most monitors are pretty poor at doing 50 FPS. Thinking about it, the older monitors are probably better for 60 Hz because that was actually the standard for a while, and they tend to use larger/longer persistence pixels.

A better idea would be to just create a Torrent once all the Atari doco is available in PDFs. Then, nobody is paying for hosting.

The presumed value of the docs or effort others have put in isn't what they want money for. It all comes down to network bandwidth - chances are they're transmitting multiple terabytes per month so they'd be paying pretty big money for that. Most similar free services are the same... max out your free Photobucket quota, and it cuts that off too.

I don't get it... why would you trade away a 64K 600XL and keep the XEGS? It's a better made machine with under half the footprint, and infinitely better keyboard.

You'd probably find it easier to just identify what parts of the ROM have changed from whatever the original contains. Then find the corresponding version of PacMan on the 5200 (if it exists, there are at least 2 PacMan versions from Atari). Then find the corresponding original data within the 5200 ROM and change it to the hacked version. Of course, that'll probably work for maybe 90% of the sprite/level type data, but for actual code changes it'll need grunt-work.

Yes... the captures are a little grainy (zoom into DOS one), but streets ahead of the monitor output from a non-VBXE machine.

For doing video and stills captures, plus allows me to use it on my LCD monitor instead of the 1084 if needed.

Still a little tidyup work needed, then it can go inside the computer.

Got my RGB to S-Video/Composite adaptor working http://www.amigamaniac.com/RGB_to_PAL_NTSC_adapter.html The chip expects .714 Volts P->P on the RGB inputs, but VBXE does .75. So, I put in a voltage divider on each of the inputs. For now, R1=75 Ohms, R2=1.2K which should bring it down to about .705 V. I'll have to do a luma bar program or something to check that the range is right. The convertor needs a DC source of between 7-35 Volts, so I've mounted it on a PCI bracket and it'll just go inside the PC. I'll be using it through my capture card, so it's no great problem. Here's a few sample capture pics.

Works fine for me.

Is that just a simple PS resize, or something else? That Vader pic... there's such little variance of colour through the whole thing, it could probably be done in 160h multicolour anyhow.

.include generally means the assembler will include a file as if it was just inline with the rest of the program. So, you can't have duplicate labels, and any common memory locations can get assembled to twice. Like I said - just way easier to keep the files seperate and also assemble them seperately.

Generally you don't assemble multiple programs like that. When developing a program though, it's fairly normal to split things up then .include routines in an assembly, but for those examples you're better off keeping them all seperate. Many assemblers allow Local labels, so you could take that route, but IMO with those examples just keep them as seperate files. TXTBUF = * just means that the label will have the value of whatever the location counter is at the time. So e.g. *= $600 lda #1 ; asm to $600,1 jsr print ; asm to $602,3,4, text = * ; this will be $605 the label "text" in this case would have value $605

There's the "Spectrum 512" mode that IIRC uses MOVEM.W instructions to block reload the pallette registers 3 times per scanline allowing 48 colours per scanline. You could also do APAC-like modes by mixing scanlines of dark colour info with ones with luma on a per-scanline basis but that would work with a PAL TV only. Then there's all the software overscan stuff that uses switching tricks among refresh rates/modes that removes one or more border regions, the resolution stays the same just the graphics area gets bigger. I think there's also hardware projects to add a second Shifter to allow more colours in lores. But, on a standard machine I don't think there's any way to have resolutions other than the 3 default ones with their 16/4/2 colour choices. You could do stuff like multi-playfield parallax/overlapped scrolling in lores but you'd lose colours not gain them.

ST had plenty of games but I don't think the modern-day scene for games is anywhere near as active as the 8-bits. Not sure on exact numbers but it'd be well over 1,500+ for 68000 Asm-based commercial games. IIRC one of the cracker groups got to 520 disk releases (DBug?), and most of those had multiple games per floppy.

I'd go PAL - it's quite probable that more games were developed in the old days in PAL countries, although the Amiga can switch between PAL/NTSC modes. Should note though - the PAL/NTSC switch isn't 100% compatible, the machines still have different clock speeds and PAL Amigas can still show more scanlines. Power supply - probably not worth the bother of getting one overseas, just use a local one - they just use 5 and 12 Volts DC, so the Amiga itself will work anywhere if you use the local PSU. You could even use a PC power supply although an unexpanded Amiga 500 only draws about 12 Watts or so and mightn't be sufficient load to use alone on one.