STGAC

A simple implementation would be to let ANTIC have a 64K 'cache' to itself and the 65816 have a 512K (or 2MB, whatever) RAM for its use. Writes go to both, ANTIC reads from the 64K, 65816 reads from 'big RAM'. The only conflict is when you write RAM during HALT. Then you may lose one 65816 cycle. (not 4 or Or when you access the I/O ($D000-$D5FF), which eats up a whole 6502 cycle. Some accomodation must be made for ANTIC access to ROM. Not sure why I am encouraging this by talking about it... Bob With the prefetch queue, the entire inx, tax, rol, ror, lda #, ldx #, etc. can be executed within the HALT period rather than the cycle that does not require memory fetch. And one cycle of the four @7.16Mhz would be used and instruction would have to aligned in that odd way. If he can implement 14.32Mhz, you have 8 cycles so 4+ byte prefetch queue would allow usage of all 8 cycles optimally. I mean if you are going to go through building the logic of using the HALT period mine as well do it optimally rather than just for one CPU cycle.

Yeah,,, OK - maybe you guys need to cut back on the sugar intake? Next thing, we'll be accessing memory in doublewords, with a memory controller and DMA... Bob If it's only one instruction prefetch and memory refresh/ANTIC DMA follows, you can let the branch execute as is since it'll just set IP=newval and since the prefetch has to be filled anyway on the next instruction fetch, it'll fetch from right address. The CPU will always be fetching instructions from the prefetch area so I don't think we need to determine whether it's instruction, operand, or plan data. We still have to know if it's some instruction that causes slow down of clock (like I/O) and align and refill queue. It's the same data getting to the CPU through the prefetch queue rather than going directly from RAM which saves the bus for doing memory refresh or ANTIC DMA. In fact, you can have 65816 always be executing instructions during HALT mode since you can always send it a NOP ($EA) for when an instruction cannot be executed without accessing bus.

You just connect the resistors between the LUMA and ground and CHROMA and ground. The Atari puts out too much signal for some of the s-video inputs. The resistors draw down the voltage to an acceptable level. They are supposed to terminate the video coax but that is secondary, really. Problem is, if they are missing you may get too much voltage. How did you 'add the missing line'? Bob Hi Bob So far I've only added the missing video line to the monitor jack and then built an SVID cable. How do the terminators work? Sorry if my electronics inexperience is showing. I'm slowly getting back into it after 20 years away. The only other mods on this 800XL are a 32in1 from classics and a 256Mb expansion which was in there when I acquired it. I think it's a Newell. Thanks for the help. Paul

I want to point out that Rambo/XE works the same on the XL7 - you just need faster logic. There are no compatibility issues. Bob

Not a lot of room left in that CPLD... I have considered control registers and the best I can come up with is to use one of the extended memory banks. So, you would read/write to $FFxxxx to set or reset bits, for example. (this assumes that you guys aren't going to want 16mb of linear memory) No existing code should be doing this - a 6502 can't even execute the instruction. Killing the 7.16mhz clock is not a trivial exercise, by the way. Bob

How do we tell? I'll look at mine when I get home tonight... Bob

I have not considered a linear ANTIC memory expansion - not sure how it would work since ANTIC only has 15 address bits. ANTIC certainly isn't going to run any faster, no matter what memory it's accessing. You can have ANTIC accessing expanded memory in the same mode as it does on the 130XE while the CPU accesses linear memory and/or 130XE mode memory. Linear memory (where implemented) works all the time. Anytime the A16-23 register is loaded with a non-zero value, all the decodes for ROM, I/O and such are disabled. (actually, not enabled) This is so you can write to $03D301 or $04D400 and hit only RAM. In practice, you could have $D301 banking memory and still get to $024000 in linear memory. (you have to remember that the physical, linear RAM is the same as the physical, banked RAM) In reality, if you activate linear RAM, some stuff crashes - as I described in another post. I think SIO works OK. I'll try some SpartaDOS. I use DOS 2.0 - it works just fine. Bob Ah, but you can always copy the ROM to RAM and enjoy the faster speed - though you are correct, it may be necessary to re-write SIO code to maintain compatibility. And to Bob the Builder: On the 130xe you can have Antic and CPU accessing different 16K banks; I would guess that implementing that feature when using the linear 65816 memory mode would be a challenge (particularly since the PIA bank switching would do nothing). An additional level of complexity in the circuit for minimal return (other than speeding up the Sea of Disks demo)...

Well, not exactly. The cartridge will have the FRAM and pretty much work with either a stock machine or the XL7. The XL7 will be able to access the FRAM at a much higher speed, however. Even if we continue to run the FRAM itself at 1.79mhz, the XL7 could access it on just about every other cycle, where a stock Atari can only write to the FRAM every six cycles or so... (something like that) Should make screen updates much faster. No code or hardware changes needed in the video cartridge, either. Bob You could do 4x6 pixel characters much faster, but you are still limited to 320 pixels across. Access to the Atari video will be faster, but still can only update the registers at 1.79 mhz. The XEP80 won't gain any speed because it goes through the joystick port. One ideal is add that proposed FRAM thing to this board (Fram is something people were proposing to put on a cartridge). Maybe have a side bus running at 7.16mhz. One issue is combining this thing with Videoboard XE, if this processor board goes over where the VBXE has to plug it, it would be harder to put both in at the same time.

In your example, the cycles would be: 0,0,1,0. Non-RAM access always starts on cycle 0 and ends on cycle 0. Yes, the 'wait state' occurs before ROM access. (cycles 2 and 3 in your example) Repetitive ROM (non-RAM) accesses don't need alignment - you'll just stay on the 1.79mhz clock and start on cycle 0 for each access. It should be evident that you won't see much difference in speed while you're running from ROMs. I considered using fast(er) Flash for ROMs. That may let us run at 3.58mhz. Serial FRAMs, even in the cartridge, will probably run at 7.16mhz. Parallel FRAMs may or may not. There are lots of things to try... so many toys, so little time. Bob

The linear memory requires a latch on the data buss to capture the upper 8 bits of the address. This works fine - most of the time. Under some unknown conditions, one of the other Atari chips gates data onto the buss and throws you out into nowhere-land. Doesn't happen very often, but it kills you. On a stock Atari, who cares if there is spurious data on the buss for the first 100ns or so... I've built it with linear memory and it's really nice. You don't have to be in '816 mode to use it - just execute a long address load or store, even in 8-bit, 6502 emulation. But, the machine is less stable that way. Larry White has the linear memory machine, I think. (no, maybe not... I dunno) For now, you could just RAMBO/320XE the thing if you want more memory. All the inputs are static except A14 and A15, which come from the CPU in plenty of time. Use very fast logic - a CPLD like the ATF750C at 10ns would work, I'm sure. You would have to bring PB0-PB7 up to the XL7 board - everything else is there. Bob I would think the reverse to be true. The 130XE is the only A8 to come with banked memory when new and so far this upgrade isn't even designed for the XE machines. While the XE bank switching scheme is slick, having a linear memory model would make life for the programmer much easier. Bob; the '816 can address more than 64k, without giving away too many details of your project, is there any technical reason that there couldn't be a couple more SRAMs wired to upper address space? It sounds like the goal of this project is to keep the hardware simple and I would think this to be the simplest way to address additional memory. On the other hand, if this complicates things, I think the boost in CPU speed is *much* more valuable than the additional memory (any more a swap file on a fast hard drive or ram drive is a good way around the 64k limit too).

That IS a 512K SRAM in there... why would the 130XE scheme be any more complex on this thing than on any other 1200XL? Just has to be fast, right? Bob

He did a 65816 drop-in but it ran at the same speed as the 6502. It didn't even have extended linear memory. Bob

I'm not a programmer, but the DLI is used to sync the CPU with a certain point on the screen. The FRAM is already in sync with the screen display (we hope!) so we can make changes with the FRAM instead of making the CPU do it. This may free up the CPU to execute DLI code that was not able to 'fit' into the cycles available without the FRAM cart. It doesn't have anything to do with ANTIC, actually. Some programs might need just a little more DLI 'space'. Maybe a game coder could jump in here and explain what they would use this for. Bob I still don't get it. Maybe I'm too fixated on the present design, which connects to the cartridge port, not directly to ANTIC. But it does use DLIs to sync the enhanced video output with the ANTIC/GTIA video.

As long as the cartridge knows where he is on the display, you can use that timing to initiate video alterations to the combined display screen. Not as versitile as the DLI but it would incur no overhead to the system (other than loading the FRAM initially). This gives you back CPU time that would be spent on DLIs. And, it's much 'faster' than a DLI. Bob Sorry, I can't quite unravel it. Please explain.

The first few times I read your post I said "HUH?". But,,, after you unravel all the spagetti... yes! You could extend DLI code into the cartridge. That's actually a great avenue to pursue! Bob