Compiling/modding Z26

[supercat]

What must I do to compile Z26 for Windows? I'd like to add some new bank switching methods (which I'm currently working on hardware for).

 

I haven't figured out the details of my new hardware yet, but one feature will be "hires helper" mode, useful for developing games with a Stell-A-Sketch style hires screen. On the new hardware, plotting a pixel at coordinate X,Y (i.e. in the X and Y registers) will take three instructions:

  LDA $1F00,x
 ORA $1000,y
 STA $1000,y

Erasing a pixel will also take three instructions:

  LDA $1F80,x
 AND $1000,y
 STA $1000,y

The "hires helper" hardware will actually be very simple--essentially, it will cause any access to $1Fxx to copy bits 4-7 of the address into bits 0-2 of the page address, and bit 3 of the address into bit 3 of the page address. Despite its simplicity, however, the "hires helper" should allow the creation of games for the A2600 that would otherwise not be possible.

 

BTW, in case anyone is wondering, the hardware would regard a single access to addresses $1000-$10FF as a read, and the second part of a double access as a write. Because "LDA $1000,y" performs a single read and "STA $1000,y" performs a read and write consecutively, these instructions would be correctly handled by the hardware.

 

FYI, the following instructions would be handled correctly be the hardware:

; Note: I is X or Y; STO is any store instruction; RMW is any read-modify-write instruction
 All addressing modes of reads EXCEPT indexed reads that cross a page boundary WITHIN the RAM area.
 RMW $10xx
 RMW $0Fxx,I [page crossing INTO the RAM area]
 RMW ($xx,X)
 RMW ($xx),Y [page crossing into $10xx]
 STO $10xx,X [page crossings into, within, and out of the RAM area are all acceptable; the latter will not result in a store]
 STO ($xx),Y [all page crossings acceptable, as above]

The following instructions would not be handled correctly by the hardware:

  READ $10xx,I [page crossing WITHIN the RAM area]
 READ ($xx),Y [ditto]
 RMW $10xx
 RMW $10xx,I [except for page crossing from outside the RAM area into it]
 RMW ($xx),Y [ditto]
 STO $10xx
 STO ($xx,X)
***Code execution from RAM***

Note that while the set of usable instructions under this scheme would be somewhat reduced compared with those allowable under a SuperChip-style scheme (using separate read and write addresses), it does not require the use of double address space for writing and reading. The current plan is to have a 256-byte area and a 1.75K area of RAM available with separate write-protect latches; a write-protected area would be usable for code execution.

 

What would be necessary to add such a feature to Z26? I've looked at the SuperCharger library, and I have something of an idea of how I'd implement the banking, but I have no idea how to recompile Z26 to do that.

Edited July 19, 2005 by supercat

[+batari]

What must I do to compile Z26 for Windows?  I'd like to add some new bank switching methods (which I'm currently working on hardware for).

894009[/snapback]

I haven't any idea. But note that source for Stella is available too, and it's written in C++. No x86 assembly to mess with I've hacked and compiled Stella myself and it wasn't too hard, and changing around and/or adding bankswitching shouldn't be too painful.

 

Also, note that the Stella team has managed to get 3E into the latest Alpha 2.0 build, which you can get now.

[Eckhard Stolberg]

What would be necessary to add such a feature to Z26?  I've looked at the SuperCharger library, and I have something of an idea of how I'd implement the banking, but I have no idea how to recompile Z26 to do that.

894009[/snapback]

In order to compile z26 or Stella you need to get a C(++) compiler and the nessessary libraries. For z26 you'd also need an assembler. And of course you need to get the source code of z26 and/or Stella.

 

The C compiler you can find at www.mingw.org. You'd need to get the latest stable version of MinGW. Also get the latest stable version of MSYS, which is a Unix command shell with the nessessary tools to use the C compiler.

 

z26 and Stella both need the SDL library. You can get it at www.libsdl.org. You need to get the latest (1.2. development version for MinGW. I think Stella also needs libPNG and zlib, but I don't know where to download the nessessary files.

 

For z26 you also need NASM for compiling the assembler parts. You can get the Windows version at nasm.sourceforge.net.

 

If you have installed everything properly, you can recompile the emulator by using "make" in the Unix command line shell while being in the source code directory of either z26 or Stella.

 

 

Ciao, Eckhard Stolberg

[supercat]

I haven't any idea.  But note that source for Stella is available too, and it's written in C++.  No x86 assembly to mess with I've hacked and compiled Stella myself and it wasn't too hard, and changing around and/or adding bankswitching shouldn't be too painful.

894169[/snapback]

 

What's wrong with x86 assembly, if I can get semething that will compile it with everything else?

 

BTW, what do you think of my idea for the hi-res optimized banking scheme? Sound like it should allow for some interesting games? I don't really see how one could do a whole lot better unless one reserved two pages for hires graphics and, with Y>0, did

 stx $3D  ; [or wherever--some special address to set the X coordinate]
 lda $10FF,y  ; Do automatic read/modify/internal-write

This would reduce the pixel-plotting time from 16 cycles down to eight, but would require much more complicated hardware that I don't really think would be worth it.

[+batari]

What's wrong with x86 assembly, if I can get semething that will compile it with everything else?

Personally, I've looked at both Stella and z26 source. While z26 is much faster and does more, I found the assembly source somewhat sparse on comments and thus somewhat difficult to follow.

 

But if you don't have a problem with it, knock yourself out.

BTW, what do you think of my idea for the hi-res optimized banking scheme?  Sound like it should allow for some interesting games?  I don't really see how one could do a whole lot better unless one reserved two pages for hires graphics and, with Y>0, did

 stx $3D ; [or wherever--some special address to set the X coordinate]
 lda $10FF,y ; Do automatic read/modify/internal-write

This would reduce the pixel-plotting time from 16 cycles down to eight, but would require much more complicated hardware that I don't really think would be worth it.

894589[/snapback]

I haven't yet figured out how this scheme would work. I'll look into it a little more.

[supercat]

This would reduce the pixel-plotting time from 16 cycles down to eight, but would require much more complicated hardware that I don't really think would be worth it.

894589[/snapback]

I haven't yet figured out how this scheme would work. I'll look into it a little more.

894669[/snapback]

 

The scheme I'm planning to actually use (the first one mentioned) would take thirteen cycles (I miscounted sixteen). The memory from $1F00-$1F5F would be preloaded with the eight-byte pattern $01,$02,$04,$08,$10,$20,$40,$80; the memory from $1F80 to $1FDF would be preloaded (by the programmer) with $FE,$FD,$FB,$F7,$EF,$DF,$BF,$7F. Any access in the range $1F00-$1F5F or $1F80-$1FDF would set the bank-switching hardware so that the appropriate column of display data would be accessed at $1000-$10FF.

 

Figure in those assumptions and the sequences to set and erase pixels should be pretty clear.

 

As for the latter scheme, it would require that the cartridge itself contain read-modify-write hardware. If I were willing to use a 95C72 instead of a 95C36 (i.e. a more powerful programmable logic chip) it would be possible to make it so that the CPLD would turn certain read accesses into read-modify-write operations internally. In fact, I slightly-overcomplicated the proposal and it's not necessary to use fully page crossings since memory and logic devices are fast enough to do the whole read-modify-write operation in a single 6507 cycle. Although it would be rather cute to be able to do that, though, I suspect the performance gains would in practice be pretty marginal and not worth the extra hardware required.

 

The approach given at the top of this post, however, would require relatively little hardware to implement (and what it requires should fit in the 95C36). It would be equally usable with both index registers (as indicated) or with one, in case the other was needed for loops (e.g. to draw a series of points)

  ldx #numpts-1
lp:
 ldy xcoord,X
 lda $1F00,Y
 ldy ycoord,X
 ora $1000,Y
 sta $1000,Y
 dex
 bpl lp

If an object needed to be movable in the X dimension (without recomputing all its coordinates) but not in the Y direction, the loop would still work nicely:

  ldx #numpts-1
 clc
lp:
 lda xcoord,x
 adc xposition ; Should never set carry
 tay
 lda $1F00,y
 ldx ycoord,x
 ora $1000,y
 sta $1000,y
 dex
 bpl lp

 

Dealing with the case where the Y coordinate is mobile is harder, since there's no nice way to do the arithmetic without trashing the value in the accumulator (there's a funny opcode to subtract from X, but only if the accumulator is $FF). Even that's not too bad, though:

 

  ldx #numpts-1
 clc
lp:
 lda xcoord,x
 adc xposition ; Should never set carry
 tay
 lda $1F00,y
 pha
 lda ycoord,x
 adc yposition
 tay
 pla
 ora $1000,y
 sta $1000,y
 dex
 bpl lp

 

Sound interesting?

[+batari]

This would reduce the pixel-plotting time from 16 cycles down to eight, but would require much more complicated hardware that I don't really think would be worth it.

894589[/snapback]

I haven't yet figured out how this scheme would work. I'll look into it a little more.

894669[/snapback]

 

The scheme I'm planning to actually use (the first one mentioned) would take thirteen cycles (I miscounted sixteen). The memory from $1F00-$1F5F would be preloaded with the eight-byte pattern $01,$02,$04,$08,$10,$20,$40,$80; the memory from $1F80 to $1FDF would be preloaded (by the programmer) with $FE,$FD,$FB,$F7,$EF,$DF,$BF,$7F. Any access in the range $1F00-$1F5F or $1F80-$1FDF would set the bank-switching hardware so that the appropriate column of display data would be accessed at $1000-$10FF.

 

Figure in those assumptions and the sequences to set and erase pixels should be pretty clear.

OK, I think I get it now, so it's kind of a bitmapped screen on the 2600 (though it's not bitmapped in the strictest sense.) So what kind of resolution would this yield?

 

(there's a funny opcode to subtract from X, but only if the accumulator is $FF)

SBX also works if A=X.

 

Still trying to wrap my brain around the scheme that does processing on the cart.