Rybags

BBC has RAM that can be accessed at 4 MHz, so supposedly all video and refresh accesses are transparent giving the CPU no halt states. Freddie makes no difference, Antic/6502 both run at ~ 1.79 MHz sharing the bus without interleave regardless of machine. Later DRAMs can supposedly tolerate more slack refresh times than the earlier ones, e.g. Commodore Plus4 gets away with only 5 Refresh slots per scanline vs Atari's 9. But it wouldn't have been much point making an Antic version that does less Refresh cycles, you'd suddenly end up with a heap of software (esp demos) that didn't work properly. Similarly, the later RAM chips Atari used could likely run in a 5 MHz system but producing an architecture with interleaved CPU/Antic access would = more broken software.

PMSL. I think there is an ST emu for the Amiga but it only does selected Desktop type apps. You'd probably emulate an ST easily enough with one of the newer PPC Amigas, but forget it with any 68K based system, exept maybe a really quick '060 and even then it'd be a bit of a fudge.

If you're switching in/out of Basic/AsmEd, you need to clear the WARMST flag ( when re-entering either, because each one uses similar z-page locations for their pointers and will corrupt the other one. That's also equivalent to entering "NEW". The problem though is that if WARMST is clear after the CASINI (2) vector is called, the OS will boot the disk again. That can be an advantage but we don't really want it happening here. The trick is to have your routine do the stuff the OS would normally do so that it doesn't get the chance to reboot the disk. So, you've got your routine with the BOOT flag (9) with bit 1 set. You'd need something like: jsr initdos lda #0 sta WARMST ; 8 jsr initcart jmp ($bffa) initdos jmp ($c) initcart jmp ($bffe) You only set WARMST to zero if changing to a different language environment, otherwise leave it alone. Doing this means the stack will have some stuff left on it, but it doesn't matter.

Don't forget, Right Cart will only work properly with a 400/800 based OS

He mentions being "part way through the mod" - just how much of the mod have you done?

I should have mentioned before... to reset-proof your Basic or Asmed, you need to use the cassette init vector (2,3) to point to your own init routine. Set the BOOT (9) flags to it's value OR 2 (1 = disk software booted, 2=cassette, 3=both). Then your init routine will need to: . Set the OS top of RAM pointers to $A0. The decimal locations to change are 106 and 740. . Close and re-open the "E:" device so that the screen is re-established around $9C00. . Restore the ROM-copy contents of $BC00-$BFFF. Good idea is to keep this copy under the OS, maybe try $CC00-$CFFF. . Call the cartridge INIT vector by indirect JSR through ($BFFE) . Test BOOT flag. If bit 0 set indicating DOS present, then do an indirect JSR through ($0C). . Run the cartridge by JMP ($BFFA). You might want to put a keycheck in, e.g. with my 800XL AsmEd I check for SHIFT and if it's held during Reset I switch between Basic and Assembler. For the 1200XL you might use it to bypass Basic and just run DOS instead - for that to happen, just bypass everything above and DOS should run instead. It's handy to have in case you corrupt/crash your cartridge copy. You need to put your init routine somewhere. My AsmEd has it right below the screen ($9B80 ?) but that's not a real good place because it will be wiped as soon as you open any graphics screen that uses > 1K. There are a few places in low RAM where there's bytes free. Another place is somewhere low in the stack - $110-$17F usually never gets touched so you could use that.

filecopy.zip This old Basic program I wrote will copy the non-banked 8/16K cartridges. Been a long time since I used it, IIRC it'll save them as binary file with Init/Run addresses as per the cartridge vectors. But it doesn't do anything like recovering the RAM wiped by the screen when you press Reset, so it won't be much use for Basic or the AsmEd cart. I've got an XEX version of the AsmEd that runs from RAM... although it relies on Basic being enabled (XL-banking style) to work properly. The problem you'll find running any RAM-based cart images on the 1200XL is that when you press Reset, the screen will wipe what's at $BC00-$BFFF. The way around it is to keep a copy of that area somewhere else in RAM and restore it each time, as well as Opening another screen with RAMTOP set lower. Of course that introduces it's own problem, you don't really want to lose a chunk of RAM in low memory, probably the best place to keep the backup 1K copy is in RAM under the OS, but that can conflict with some DOSes.

I don't have one and haven't used one. It was intended as an 80-column display generator for Word Processing, terminal programs and the like. Not sure, but I think it's text only - not intended for doing graphics. Probably no artifacting possible either - half the purpose of the thing is to have a quality readable 80 column display without such annoyances. All that aside, you wouln't get much of a game on it - every command has to trickle over the serial bus, so e.g. filling a 640x240 bitmapped display using SIO at 19.2K would take about 15-20 seconds.

It's a totally seperate display to what your normal monitor or TV shows - the device attaches to your serial port and the computer instructs it what to show, and it drives a second monitor. So, you can in theory have 2 screens with totally seperate stuff on them. But the XEP80 won't show any normal Atari stuff like multicolour graphics, PM graphics etc.

There's plenty of games, and you can effectively count many graphical ones that use Mode 2 AKA Graphics 0 as well. Night Mission Pinball as well as a good number of other pinball games. Stellar Shuttle as well. Some of them rely on artifacting, others just utilize the higher resolution.

Maybe open the thing up and run a slightly faster master clock. Problem then is that you might run into SIO transmission problems.

That thread talks about "dumping", which you only do with ROMs. The 2600 and Gemini in default configuration don't have any ROMs built into them, and in any case a game dump or BIOS ROM source code wouln't give much clue towards pinouts. Like I said before, the best bet is to check where the traces go - find the resistor ladder and you should find the luma lines. Find connectivity between the address/data bus lines between the IC and 6507 and that's most of the chip done.

There's only really 2 scenarios where no (or a minimal amount of) screen data needs to be moved in a h-scroller R-Type kind of game: . small sized level where e.g. 8 screens worth of data is predrawn and the window moves over it. . give every line it's own 4K region and take advantage of the Antic "feature" of wraparound when it overruns the 4K boundary. For that second scenario it becomes a bit expensive, but a 128K system could cope - e.g. 20 lines = 80K devoted to the screen. You don't need to move any data, all you need to do is copy the last 40 or so bytes of each 4K area backwards to the start of the 4K area so that the wraparound will look smooth.

I should have said "less than 40 chars per frame on average" or something like that. Also I was talking from a single frame buffer perspective, where new data is introduced and the stuff that scrolls off is lost. And, not large overall buffer, just an LMS per line and less than 64 bytes used per screen line. So, groups of lines start at offset 0 on their "buffers" and move towards a max value e.g. 24 chars offset from that (disregard fine-scroll here for a bit). Instead of all lines hitting the max at the same time, have groups of lines such that the offsets are different, e.g. 8 lines have offset 0 when the next 8 are at 8 and the final 8 lines are at 24. That way, you introduce new tile/char data at "offset + 40" type of thing, and reset your offset back to zero when it hits the end (and perform the block memory moves at that time). But instead of the entire screen at once, you only have to handle moving a third of it at one time when a move is required. Of course you could expand on that - use a different offset for every line if needed, which means you don't have big block moves at once, just little ones more often.

Original release in 1982 by Broderbund, cartridge and disk according to AtariMania. I'm almost sure I had it on tape, but can't be sure, and it was a pirate job anyway which means it wasn't necessarily commercially available that way. Original was largely in 320 mono mode, later Atari cartridge release in 1988 done with more colour.

That's one way to go about it. The advantage the A8 has with scrolling is that since you have 4 characters worth of fine-scroll, you don't need to do bulk memory moves in the one go. It's entirely possible to stage it - in conjunction with LMS changes you could quite easily get away with only moving 40 characters per frame. Of course that can cause some level of confusion with stuff like softsprites or collision mapping - but you're keeping track of each line's offset, so you just need to take them into consideration for those things.

Part of me just says "take Atari Basic and the FastROM Floating-Point routines from Newell". Disadvantage of course is Atari Basic is a bit slow, even with better FP. And it'd also need a good deal of stuff from the OS included too like adapted CIO routines. Doing the keyboard is nothing - Pokey already does most of the work, you can virtually get away with a 64 byte translation table and a bit of code to handle it.

Some of the demos on the STE show just what could have been. For the millionth time - it's the machine that should have been the launch vehicle. It addresses all the main deficiencies vs the Amiga, except for open hardware architecture, multitasking OS, and hardware sprites.

But it shows. The Amiga chipset is the culmination of months/years of effort and was leading edge in many regards. All the original ST had really was Glue and Shifter, and had no real special graphics ability other than greater bitdepth over 8-bit machines and the Macintoshes of the time.

You don't need their BIOS to create a "clone" in the rough sense though. The problem with IBM was that the PC was off-the-shelf parts, so anyone could build one. You could also say that if they'd gone closed architecture and specifically created patented custom ICs, that the end product mightn't have been capable of the stepped evolution that the PC has gone through in ~ 30 years.

There's every chance Warner just registered the (new) name in anticipation of splitting and spinning it off, so that they could retain the name for the arcade division.

The problem both Atari and Commodore had was they didn't really secure a position in the educational or corporate/government sectors. So, dad used IBM at work, which meant home sales for them and the clones (eventually). Apple always had good representation in schools, which led to home sales there, and the Mac's good representation in the print industry gave them inroads into the corporate/government sectors. All Atari had was the flowon effect from the bottom end, ie consoles. They had every opportunity to create and expand the image and market for their computers, but of course we all know how that went. Warners could have sewn the market up in 1979-81, but failed. Tramiels did a great job in the mid 1980s but the closed architecture and too slow evolution of the ST ultimately made it become redundant.

Warner were clueless at selling computers. You may as well say Atari pulled out of the computer business by 1985 if Warner had held on. Even if the Amiga deal had gone the other way, they'd have found a way to make a balls-up of it. Consoles - I'd reckon maybe they'd have kept them going, maybe the 7800 and Lynx would have come along. Whatever bad you can say of the Tramiels, at least they breathed some life into the 8-bits which prolonged them that few extra years. But they repeated problems of past by not progressing with the times and updating the 8 and 16 bit lines in timely fashion. Chances are that Atari as we knew it would have been dead 3 or 4 years earlier if Warner had kept it, so at least the way things did go saw Atari into the 1990s.

Great music, but that colour-cycling is annoying as. Would be better to just keep the pic, then have some EQ bars or something as visual fx.

You shouldn't need anything else. But your problem will be finding a CTIA to begin with.