7.16mhz 1200XL

[Rybags]

I believe that's been covered.

 

Any I/O access must occur on a certain time boundary. If you look at chip datasheets you'll find that new data should be present on the bus at certain offsets within each machine cycle.

 

As such, Bob's upgrade skews such memory accesses so that they're delayed until the time they should occur. So, the cost penalty of any ROM or I/O access is at least 4 "fast" cycles" and in some cases could be 7.

 

That is just for the access phase of the instruction, not the entire instruction.

 

I don't see too many problems with games that do stuff in DLIs. Very few games perform changes that are cycle critical, they just store WSync then do their changes during HBlank.

 

Of course, when you get into things like mixing GTIA and standard mode or reusing Players in a line then things become complicated.

[drac030]

...

	   lda var
   clc
   adc #$6502
   sta ext

 

Assuming the same as above, 15 clocks - 32% faster. But to run this coded you need the possibility to switch to the native mode, and for that you have to replace the OS.

 

I don't have a 65816 to play around with. What's the cycle breakdown of the above for 65816-- does the 2nd read cycle for MSB in the LDA Var occur one cycle after the first read for LSB or more? Similarly for STA. There is only 8-bit data bus so much be splitting up into multiple reads/writes. So if I write a 16-bit value to 53270, two color registers would get set but what's the time in cycles between the first write and the second?

 

A 16-bit LDA or STA takes exactly one cycle more than 8-bit one. So, for the above example (R - read, W - write cycle, I - internal op):

 

	LDA VAR - R:OP R:ARGL R:ARGH R:DATAL R:DATAH (5 read cycles)
CLC - R:OP I:- (1 read cycle + 1 internal operation = 2 cycles total)
ADC #$6502 - R:OP R:ARGL R:ARGH (3 read cycles)
STA EXT - R:OP R:ARGL R:ARGW W:DATAL W:DATAH (3 read cycles + 2 write cycles = 5 cycles total)

 

The MSB is written in the next cycle after the LSB.

[peteym5]

I will let you in on alittle secret, I had to multiply screen positions and store the results into tables before starting each level for my game. It does have limits like I couldn't move things into between positions easily. The table took up a few KBs for RAM. Now with a 65816 CPU, it could do the calculations during game play because using 16bit instructions. The routine could do it less CPU cycles, it would do it in less time at 1.79mhz. At 4x the speed, it would probably be little more than an original ADC or SBC command. I am speaking of Integer 8bit x 8bit values, which are commonly used for ML games. You can make something run as fast as a Super Nintendo game, but still would be short in graphics ability. Unless there is a plan to accompany a 65816 upgrade with an extra video chip. I am still curious of peoples game ideals for these upgrade.

[Rybags]

Carrier Command would be a cool one.

Not like the shitty C-64 version, but one with basic textured effects like the 16 bit versions.

Still, it might well have to be done in a lower res graphics mode.

 

Galaga - although I'm of the belief that with some tricks and compromises it could be done reasonably well on a standard machine.

 

3D games - a Doom conversion could be done, but available RAM would be a limiting factor in it's complexity. Something like Wolfenstein should be a walk in the park though.

[Heaven/TQA]

re: Wolf

 

as there is the Apple2 source available...

[Shaun.Bebbington]

How much faster could it be made to go? Which component limits the design to 7 MHz?

 

The SuperCPU is over-clocked at 20Mhz from an internal 65816 at 14Mhz ... I suppose the board could easily run at 14Mhz...

 

Around 14 mhz is the speed limit of these CPUs, probably make them run an 8x the speed of an Atari. Would have to keep in mind of certain limitations when writing to the Atari hardware area that you cannot write faster than an equivalent of one update per 1.79mhz cycle. That is a LDA #, sta $Dxxx which takes 6 cycles will translate to less than one cycle. If you get to this speed, you probably need to start adding in NOPs inside the DLIs or anywhere lots of writes send to the hardware area. The Antic/GTIA atleast has to run at 1.79 mhz. Pokey chips in arcade machines ran at 1mhz, 1.5mhz, and 2mhz without any problems.

 

On the subject of how fast one of these things can go, they have mentioned on the Western Design Center website that an ASIC version can run up to 200mhz. Those are like programmable logic chips. Doing an ASIC version probably opens up the possibility of running at different speeds and you could do your speed switch with one of those. You can add cache memory to buffer the writes to the hardware. This design is a little more complicated and I know we want to keep this stuff simple.

 

Honestly I think going over 8x is ridiculous, you will run into issues with interfacing the Atari video/audio chipset and other hardware.

The SuperCPU has a 1/20mhz switch, so you can switch to 1Mhz mode whenever you like, even when a program is running.

 

It also works at 2Mhz mode on the 128.

 

Regards,

 

Shaun.

[+bob1200xl]

How about reading TRIG 2 at $D012? It isn't used in an XL (pin 10 of GTIA) so we can ground it if we like - if you read $01, no XL7, where $00 means you have an XL7 installed. This will tell the software if an XL7 is present and it can branch from there.

 

Bob

 

 

@bob: in existing implementations there is no such software switch, so such a register, as you are considering it, would provide something new. In Warp 4 the clocks are switched by address: if the address is $00xxxx, the clock is "slow", otherwise it is fast (unless the turbo is disabled by a hardware switch). In F7 the turbo mode is enabled permanently, you only decide in software, how the fast memory is to be mapped into address space (f.e. you can map Atari memory onto $0000-$FFFF, then it works less or more as Warp 4 - or you can map the card's memory onto $0000-$FFFF, then the entire address space is fast). Again, this can be overridden by a hardware switch.

 

$D5xx is bad idea, this page is already overloaded, so there is a hign possibility for a conflict (with a Maxflash cart, for instance). I think the register should be located outside the first 64K and inside the bank $FFxxxx, as you planned. As I wrote, this area is anyways allocated for I/O by other implementations. This would need a 24-bit address decoder anyways, so making it more precise, i.e. to decode it at $FF8000 (or $FF8000-$FF80FF) should not be a big problem.

 

Other things: even if the largest SRAM is 2 MB, I don't see a problem by using 8 of them to complete a 16 MB (minus 128K). Banking "large chunks" is hm "interesting" idea, but not everyone likes banking so much as to implement it even when it is not necessary (in other words: I don't understand the pleasure of having 8 banks by 2 MB instead of linear 16 MB).

 

@peteym: the Atari OS does not support binary loading at all, and the addresses in the "boot file" header are 16-bit, so it does not. However, the SIO is extended so that it can transfer sectors directly from/to the area above the first 64K, so some support for a DOS, that could implement an extended binary loader is there.

Edited September 20, 2008 by bob1200xl

[Rybags]

Isn't Trig2 used for keyboard detection on the XEGS?

 

Another possibility might be to use something like PADDLE4 - hook in a resistor so a specific value is returned.

[atariksi]

...

	   lda var
   clc
   adc #$6502
   sta ext

 

Assuming the same as above, 15 clocks - 32% faster. But to run this coded you need the possibility to switch to the native mode, and for that you have to replace the OS.

 

I don't have a 65816 to play around with. What's the cycle breakdown of the above for 65816-- does the 2nd read cycle for MSB in the LDA Var occur one cycle after the first read for LSB or more? Similarly for STA. There is only 8-bit data bus so much be splitting up into multiple reads/writes. So if I write a 16-bit value to 53270, two color registers would get set but what's the time in cycles between the first write and the second?

 

A 16-bit LDA or STA takes exactly one cycle more than 8-bit one. So, for the above example (R - read, W - write cycle, I - internal op):

 

	LDA VAR - R:OP R:ARGL R:ARGH R:DATAL R:DATAH (5 read cycles)
CLC - R:OP I:- (1 read cycle + 1 internal operation = 2 cycles total)
ADC #$6502 - R:OP R:ARGL R:ARGH (3 read cycles)
STA EXT - R:OP R:ARGL R:ARGW W:DATAL W:DATAH (3 read cycles + 2 write cycles = 5 cycles total)

 

The MSB is written in the next cycle after the LSB.

 

So I guess no pre-fetching (or in parallel) for instructions in the 65816. How about the 24-bit address STA/LDA-- how many cycles is that?

[atariksi]

Isn't Trig2 used for keyboard detection on the XEGS?

 

Another possibility might be to use something like PADDLE4 - hook in a resistor so a specific value is returned.

 

If it's just for detecting the speed-up, there's no need to waste a register for that. With interrupts disabled, just turn on the fast pot counters and time a read/write to RAM and see what the speed up is. Should be just a few instructions and it would only need to be done once. And if they use a software to trigger off the speed-up, the same port should be read-able.

 

I have seen some code including mine that uses PADDLE4..7 for getting one-scan line accurate counter.

[peteym5]

Another simple thing to do is execute some specific 65816 instructions. These will be either NOPs or Illegal OPcodes on an 6502. Would have to write something that will not crash either system to allow everything to keep functioning. The Atari 6502 cannot execute PHX, PLX for example.

[+bob1200xl]

I think what we need is a specific indication that an XL7 is installed, above the fact that the clock is faster or a 65816 is installed.

 

Bob

 

 

 

Another simple thing to do is execute some specific 65816 instructions. These will be either NOPs or Illegal OPcodes on an 6502. Would have to write something that will not crash either system to allow everything to keep functioning. The Atari 6502 cannot execute PHX, PLX for example.

[+bob1200xl]

I don't know - is it?

 

I looked at the paddles. They are wired to ground in the XLs - means a little more work to use them. Cut traces and such...

 

Bob

 

 

Isn't Trig2 used for keyboard detection on the XEGS?

 

Another possibility might be to use something like PADDLE4 - hook in a resistor so a specific value is returned.

[Rybags]

I think the keep it simple rule should apply.

 

If a simple timed loop or test execution will allow easy identification of the upgrade, then just go with that.

[potatohead]

Could always just ask too.

[Heaven/TQA]

just my 2cents

 

65c02, 6502, 65816 ??? CPU sells but who`s buying...


How to detect on which CPU the assembler code is running

(This information is from Draco, the author of SYSINFO 2.0)

You can test on plain 6502-Code if there is a 65c816 CPU, the 16-Bit processor avaible in some XLs as a turbo-board, avaible. Draco told me how to do this:

First we make sure, whether we are running on NMOS-CPU (6502) or CMOS (65c02,65c816). I will just show the "official" way which doesn`t uses "illegal opcodes":


test_nmos: lda #$99
	   clc
	   sed
	   adc #$01
	   cld
	   beq cmos
	   ...
; if the program is here we have a 6502-cpu
	   rts
cmos	   ...
; if here, we have a cmos-type (65c02,65c816)
	   jmp test_65816


This test uses the decimal mode and the decimal addition. On NMOS-CPUs the addition does not affect the Z-flag. 

But now we have to make sure if we are running on a 16-bit-CPU. This could be important if we include in our program/demo 16-bit Code or on the other side if we can use "illegal opcodes".

The 16-bit test uses the REP #$xx command which does nothing on 65c02! (but on 65c816 !!!): 

test_65816: rep #$02 ; resets the Z-flag on 65c816 (use MAE-Assembler !!!)
		bne c816
		...	  ; here is stored the 65c02-Code
		rts
c816		...	  ; here could be the additional 16-bit code
		rts


Special thanx to Draco!!! I will use in my next demos/intros 16-Bit code even if its just 16-bit additions which make life easier.;) 





--------------------------------------------------------------------------------


Last changes: 19 Jun 1997



Feel free to contact me for any legal reason!


HeAvEn, Member of TaquarT

[Heaven/TQA]

another old doc

 

Witazije polish coders! Try using extended memory in this way...(special message to Coders of VENT and JOURNEY)
Let me give Tamas Bene of HARD the keyboard...

"...It depends on what we call "standard". My expansion is 130XE-compatible (without Antic-switching), so all programs which is written for XE should run as well on my Atari. Actually it is a 192K expansion, so the whole memory is 256K. 
The problem is that demo-coders (and others) use $d301 in a non-standard way. I mean they change bits in $d301 which work differently on different expansions, or even they store values in $d301 other than $fc-$ff, instead of masking only those bits which are intended to be changed. (Fortunately the Atari OS was written much more carefully, they even use bit masking for setting values like $ff. Otherwise even the OS might not work with extended machines. :^) 
For example, I found the following instructions in the Journey demo at several places: 
lda #$b3 sta $d301 
This has some meaning on a particular expansion, but I have no idea what it should do. For me, it just switches OS in and BASIC out. 
BTW, my 192K expansion works as follows: 
bits 0,1 and 7 work as for normal Atari (switching OS/Basic/Selftest). bit 4 switches the expansion on/off, just like for 130XE. here is a table for bits 2,3,5,6: 


bit6 bit5 bit3 bit2	action
------------------------------
0	0	0	0	   maps base memory $0000-$3fff to $4000-$7fff
0	0	0	1	   maps base memory $4000-$7fff to $4000-$7fff
0	0	1	0	   maps base memory $8000-$bfff to $4000-$7fff
0	0	1	1	   maps base memory $c000-$ffff to $4000-$7fff
0	1	0	0	   extended bank #01 at $4000-$7fff
0	1	0	1	   extended bank #02 at $4000-$7fff
0	1	1	0	   extended bank #03 at $4000-$7fff
0	1	1	1	   extended bank #04 at $4000-$7fff
1	0	0	0	   extended bank #05 at $4000-$7fff
1	0	0	1	   extended bank #06 at $4000-$7fff
1	0	1	0	   extended bank #07 at $4000-$7fff
1	0	1	1	   extended bank #08 at $4000-$7fff
1	1	0	0	   extended bank #09 at $4000-$7fff
1	1	0	1	   extended bank #10 at $4000-$7fff
1	1	1	0	   extended bank #11 at $4000-$7fff
1	1	1	1	   extended bank #12 at $4000-$7fff



This expansion is quite a standard, it was published in the german Atari Magazin a couple of years ago. Also, it needs the simplest hardware among all the extensions I know of, so it's the cheapest one too. I'm sure a lot of people built it for this reason. 

Most programs using extended memory do some sort of memory check (at least the self-respecting ones;-) But they usually fail on my expansion because they detect expanded banks in the first 4 cases (bit5=bit6=0) even though in these cases the base memory is mapped to the bankswitched $4000-$7fff area. I wonder why they don't do a check for this case. It would be simple - just treat the 4 16K "banks" of the base memory in the same way as expanded banks, and check if writing to any bank causes any changes in any other bank. The check could look like this: 


1. Set all possible values in bits 2,3,5,6, and store a different number for each of them at $4000. (numbers 1-16) 
2. Store numbers 17-20 at addresses $0000, $4000, $8000, and $c000 in the base memory. 
3. Set all possible values in bits 2,3,5,6 again, and check if the value stored at $4000 in each bank is still there, or it is overwritten. If overwritten with a different value, then it is not a real, separate bank, so remove from the list of available banks. 
It's so simple. 
An even simpler way would be to let the user configure the number of memory banks and the actual $d301 values he want to use. For example, the ramdisk in DOSes like TurboDOS and MyDOS work in that way. Other example is the excellent game The Brundles by KE-Soft. 
/Tamas" 
______________________________________
/__  __   __  _\
/  / /_|_ |   |__\  Software, Hungary
______________________________________

Here is another Description by Dracon...



XL/XE RAM expansions

There are some types of RAM expansions designed for XL and XE 
computers. The most popular in Europe are based on the general 
concept used by the Atari Corp. in the 130XE computer: a port, 
formerly responsible for controlling joysticks #2 and #3, is now used 
as a memory controller port. This port is mapped at $D301 and 
traditionally labelled as PORTB.

The general purpose of the PORTB is to control all on-board memory 
resources, i.e. the system RAM as well as the OS and BASIC ROMs.

I. ROM controller

Bits #0, #1 and #7 control the system ROM. This function is common 
for all XL and XE computers:

Bit	Meaning (if set)
---	----------------
#0	OS ROM enable
#1	Atari BASIC ROM disable
..
#7	SELF TEST ROM disable

Bit #0 changes affect the XL OS area at $C000-$CFFF and $D800-$FFFF, 
if the bit is set, there is the XL OS ROM there, otherwise the shadow 
RAM is enabled. NOTE: the PDVREG $D1FF has higher priority than PORTB!

Bit #1 affects the area $A000-$BFFF. If this bit is cleared, there's 
Atari BASIC ROM there, RAM otherwise.

Bit #7 affects the area $5000-$57FF. If it is cleared, the SELF TEST 
ROM, located normally at $D000-$D7FF and masked out by hardware I/O 
registers, is switched to $5000-$57FF; otherwise, there's normal RAM 
there.

II. RAM controller

1) Atari 130XE

Stock 800XL and 65XE computers lack additional RAM, so the remaining 
PORTB bits do nothing. 130XE however and expanded XL/XE use them to 
control RAM extensions.

Generally, considering the 16-bit address bus, it is impossible to 
enlarge the physical address space past the existing 64k. In the 
130XE, the total amount of system RAM is split into two large parts: 
64k base RAM and 64k bank select RAM. That last is accessible as four 
16k portions to be exchanged with a 16k block belonging to the base 
RAM area.

This area is located from $4000 up to $7FFF. Both 6502 and Antic are 
granted an *independent* access to this memory. PORTB bits meaning is 
as follows:

bits #2, #3 - bank select
bits #4, #5 - access control
bit #6 - unused

The first pair (bits 2 & 3) selects one of four additional 16k banks 
you want to access to. The other pair decides, which processor will 
use the bank selected by the first two bits:

#4 - CPU access:   0 - additional RAM
			   1 - base RAM
#5 - Antic access: 0 - additional RAM
			   1 - base RAM

This gives four possible combinations:

76543210
--------
xx00xxxx - both processors use the additional bank
xx01xxxx - only Antic uses the additional RAM
xx10xxxx - only CPU uses the additional bank
xx11xxxx - both processors use the base RAM

That's all for 130XE.

2) 192k RAM expansion

The computer's behaviour is exactly the same as in 130XE besides of 
that bit #6 is used together with the bits #2 and #3 to select an 
additional banks. This gives eight combinations, i.e. eight banks may 
be accessed, 16k each.

3) 320k Compy Shop expansion

Also known as "German 320k". This type of RAM extension is quite 
popular in Europe, so that several American programs get confused 
considering this to be 192k.

Since all free bits have been used for bank selection, the Compy Shop 
expansion uses bit #7 for bank selection. This gives 16 possible 
combinations, hence the additional RAM area can be enlarged to 256k 
(256 + 64 = 320).

To get rid of possible conflicts with the SELF TEST ROM (normally 
controlled by the bit #7), this bit is used to control SELF TEST only 
when bits #4 & #5 are both set to 1. Otherwise it controls the bank 
select RAM.

4) 256k Newell Industries expansion

This expansion is NOT fully 130XE compatible. It is similar to the 
192k with except that the bit #5 is used for bank selection, not for 
Antic access control. It means, that you have four bits for bank 
selection, but both CPU and Antic must use the same memory at a time. 
Furthermore, only 12 of 16 possible combinations are used so that you 
have 192k additional RAM instead of 256k. This is the most stupid 
expansion I have ever seen (my computer has it installed).

4) 320k Newell Industries expansion

Also known as "American 320k". This expansion is NOT fully compatible 
with the 130XE standard, but it was apparently quite popular in the 
USA since some software (f.e. ICD's SpartaDOS X 4.x) seems to base on 
it. Nevertheless, some software, like "Envision" for example, may 
fail on such computers.

Only bit #4 is used to control the memory access here, which implies 
that there's no separated access for the CPU and Antic. In fact, both 
processors must use the same type of RAM at the same time; if bit #4 
is set, CPU and Antic use the base RAM, otherwise both use additional 
bank.

Bits #2, #3, #5 and #6 are used for bank selection.

5) 576k expansion.

This is similar to the American 320k with except that bit #7 is used 
the same way as in Compy Shop 320k expansion. So bits #2, #3, #5, #6 
and #7 are used for bank selection if the bit #4 is set to zero 
(CPU & Antic additional RAM access). This expansion is not fully 
compatible with the 130XE.

6) 1 MB (1088k) expansion.

The same as 576k with except that the bit #1 (normally controlling 
Atari BASIC ROM) is used for bank selection if bit #4 is set to zero. 
This gives six bits (64 banks, 16k each) for bank selection, so that 
the additional bank area may be enlarged to 1024k. This type of 
expansion isn't fully 130XE compatible either.

III. RAM detection routine

Since it is quite difficult to determine what expansion a particular 
computer has and what amount of memory is currently available, the 
most simple solution is to use the following routine. It is a 
non-destructive test, any data previously stored in the additional 
RAM will remain intact.

The routine returns the number of found additional RAM in the 
accumulator. You must multiply it by 16 then add 64 to get the total 
amount of the system RAM in kilobytes as a result.

; Bank select RAM detection
; Stolen from the SysInfo
;
; Must NOT be located within the $4000-$7FFF !!!
;
portb	=	$d301
extra	=	$4000
;
lda portb
pha
lda #$00
sta counter
ldx #$7f;Save the ramdisk contents before the test
loop1	txa
asl
ora #$01
sta portb
lda extra
sta buffer,x
dex
bpl loop1
ldx #$7f;Clear tested RAM.
loop2	txa
asl
ora #$01
sta portb
lda #$00
sta extra
dex
bpl loop2
lda #$ff;Reset PORTB
sta portb
lda #'K	;Mark base RAM as tested.
sta extra
ldx #$7f;Count banks.
loop3	txa
asl
ora #$01
sta portb
lda extra
bne skip
inc counter
lda #'K
sta extra
skip	dex
bpl loop3
ldx #$7f;Restore the ramdisk contents
loop4	txa
asl
ora #$01
sta portb
lda buffer,x
sta extra
dex
bpl loop4
pla
sta portb
lda counter
rts
;
counter	.dc	0;number of banks
buffer	.ds	64;64-byte buffer


Konrad M.Kokoszkiewicz mail:draco@mi.com.pl http://www.orient.uw.edu.pl/~conradus/ IRC:[Draco] *** Ea natura multitudinis est, *** aut servit humiliter, aut superbe dominatur. ************************************************* *** U pospolstwa normalne jest, ze albo sluzy ono *** unizenie, albo bezczelnie sie panoszy. (Liv. XXIV, 25) 





--------------------------------------------------------------------------------


Last changes: 19 Jun 1997



Feel free to contact me for any legal reason!


HeAvEn, Member of TaquarT

[peteym5]

I think what Bob meant was detecting his XL7 upgrade. I know now its pretty easy to determine CPU type and possibly determine speed, but different upgrades may have different memory configurations and attached features.

[atariksi]

I think what we need is a specific indication that an XL7 is installed, above the fact that the clock is faster or a 65816 is installed.

 

Bob

 

 

 

Another simple thing to do is execute some specific 65816 instructions. These will be either NOPs or Illegal OPcodes on an 6502. Would have to write something that will not crash either system to allow everything to keep functioning. The Atari 6502 cannot execute PHX, PLX for example.

 

The XEGS keyboard does have a pin labelled trigger #2.

 

If you do use a trigger pin, I think it's also possible to trigger off the turbo mode using a WRITE to the READ-ONLY light pen h/v ($D40C or $D40D or any other read-only register) and thus make it seem like the trigger pin is READ/WRITE. Of course, you don't need to know what's written if you just want to enable turbo mode once else you can detect zero/nonzero on the data bus and set trigger pin accordingly (boolean).

Edited September 22, 2008 by atariksi

[atariksi]

Could always just ask too.

 

What mods do you need to put in an unaccelerated 65816 into current Atari 6502 socket? I see some pin differences in the link you gave previously. I guess the chips are not pin-compatible just software compatibility is supported.

[+bob1200xl]

You need to relocate a few pins and generate some timings/clocks for the motherboard. No wiring has to be changed - it's a drop-in. No, they're not pin compatible. (the 6502 vs. the 65816) I've seen the schematic on the Web somewhere.

 

Bob

 

 

Could always just ask too.

 

What mods do you need to put in an unaccelerated 65816 into current Atari 6502 socket? I see some pin differences in the link you gave previously. I guess the chips are not pin-compatible just software compatibility is supported.

[Sikor]

What mods do you need to put in an unaccelerated 65816 into current Atari 6502 socket? I see some pin differences in the link you gave previously. I guess the chips are not pin-compatible just software compatibility is supported.

Here: http://hardware.atari8.info/65816.php - you can read about changes, in Polish language only (use google translator for english text).

[peteym5]

Well one major difference is that HALT line, most of the other pins are the same. This is something needed so the Antic chip can halt the CPU and access the BUS for its own purposes. Why would you not want something that can easily run faster?

 

I am interested in seeing what we can make one of these faster computers can do for us. We already determine it can do more with a DLI that comes in handy for changing colors, and player/missile positions and widths. You also not as much limited with a VBI, it can do many more changes to the play field and player/missile graphics. Imagine having 100 moving multicolored objects on the screen at once? That is without adding anything to the Video hardware.

[Rybags]

Also imagine:

 

Fullscreen action in APAC or TIP (or anything else needing constant DLIs or a Kernal for that matter).

 

e.g. if you have 200 scanlines in PAL for a Kernal, leaves 112 free.

 

112x114= ~ 12,700 cycles free on a normal machine, not exactly a lot of time to do a lot of stuff.

 

On an accelerated machine, a theoretical ~ 51,000 cycles free if it's all RAM-based accesses.

 

 

Thinking about this some more - maybe it needs an "NMI Delay" function. It will be so fast that you'll now have a ton of free cycles when your DLI is entered. Might be handy to be able to latch the DLI and delay it by about a quarter of a scanline.

[atariksi]

You need to relocate a few pins and generate some timings/clocks for the motherboard. No wiring has to be changed - it's a drop-in. No, they're not pin compatible. (the 6502 vs. the 65816) I've seen the schematic on the Web somewhere.

 

Bob

 

 

Could always just ask too.

 

What mods do you need to put in an unaccelerated 65816 into current Atari 6502 socket? I see some pin differences in the link you gave previously. I guess the chips are not pin-compatible just software compatibility is supported.

 

What if I just drop it in and perhaps take out some pins from socket-- can I boot it up without requiring any soldering? I mean I can have interrupts disabled even-- as long is it boots up for trying things out with it.

 

By the way I tried the trigger on the Atari XEGS and 800XL:

 

the XEGS does read a "0" on trigger #2 if no keyboard is detected and "1" if keyboard is present; reads a "0" on trigger #3 (may be grounded).

 

the 800XL reads a "1" on trigger #2 and trigger #3.

 

Also noticed that STRIG(2) and STRIG(3) are not shadowed by OS ROM but just repeats of STRIG(0) and STRIG(1) (unlike Atari 400/800) so you need to do "? PEEK(53266)" and "? PEEK(53267)" to read the trigger #2 and #3 on XL/XEGS.