VBXE 2

[NRV]

Well, this one seems very near to the colors I remember, from when I programmed in real (NTSC) hardware..

 

Larry-NTSC.zip

 

hope it helps..

[candle]

NRV: thanks

 

Peteym5: since when having definable pallete was a problem for PC users? just use it wisely

[flashjazzcat]

Can we have cable building info for LCD TVs?

 

Here is SCART connector pinout :

 

http://en.wikipedia.org/wiki/SCART

 

For proper operation you must connect:

 

- Ground from ATARI to SCART pins 4,5,9,13 and 18

- R component from ATARI to SCART pin 15

- G component from ATARI to SCART pin 11

- B component from ATARI to SCART pin 7

- "RGB Control" signal from ATARI to SCART pin 16 (switches TV to RGB input mode)

- Composite Video (CVBS) from ATARI to SCART pin 20 (as SYNC source in TV RGB mode)

 

Optionally you can connect audio from atari to SCART pins 2 and 6.

 

R, G, B and "RGB control" signals are provided by the VBXE board.

Composite video is standard atari signal.

 

Of course you have to switch TV to one of "external" inputs as signal source.

Great, thanks. Finally: what kind of connector do I need to buy for the VBXE end?

[peteym5]

I am making blitter routines that can be executed from a cartridge based game. So some of us that want to make some money off our projects, cartridges are a good way to go. I am starting off with a subroutine that copies data stored in a bank switching cartridge to the memory banks on the VBXE board. Please keep in mind, this will be part of code that gets copied to RAM first before being called. Since the 128K Atari Max carts only occupy $A000 TO $BFFF, you have to copy your bank switching routines to ram first anyway.

 

CartTypeXEGS = 1

CartTypeMax = 2

CartType = CartTypeMax

_Bank_Sprites = 08

Current_CartBank = $80

Current_VBXEBank = $81

CartBank = $D500

 

Copy_Sprite_Data

IFT CartType = CartTypeXEGS

CartBase = $8000

CartOver = $A0

ELI CartType = CartTypeMax

CartBase = $A000

CartOver = $C0

EIF

copy_sprites_data_to_vbxe:

;Set First Cartridge Bank

IFT CartType = CartTypeXEGS

LDA #_Bank_Sprites

STA CARTBANK

ELI CartType = CartTypeMax

LDA #255

LDX #_Bank_Sprites

STA CARTBANK,X

EIF

STA Current_CartBank

LDX #>CartBase

STX COPY_FROM_ADDR + 1

Set First VBXE Bank

LDA #$9E

STA VBXE_MB_CPU

STA Current_VBXEBank

LDX #>$40

STA COPY_DEST_ADDR

;Set number of Pages

LDY #$40

LDX #0

COPYLOOP

 

COPY_FROM_ADDR = *+1

LDA $A000,x

COPY_DEST_ADDR = *+1

STA $4000,X

INX

BNE COPYLOOP

 

 

LDX COPY_FROM_ADDR+1

INX

CPX #CartOver

BNE Set_From_High

LDX Current_CartBank

INX

IFT CartType = CartTypeXEGS

STX CARTBANK

ELI CartType = CartTypeMax

TXA

LDA #255

STA CARTBANK,X

EIF

STA CurrBank

LDX #>CartBase

Set_From_High

STX COPY_FROM_ADDR + 1

 

LDX COPY_DEST_ADDR + 1

INX

CPX #$80

BNE Set_Dest_High

LDX Current_VBXE_Bank

INX

STX VBXE_MB_CPU

LDX #$40

Set_Dest_High

STX COPY_DEST_ADDR + 1

LDX #0

DEY

BNE COPYLOOP

RTS

 

 

 

Many of us may choose the AtariMax cart because we can flash them ourselves. If you choose to use the 128k XEGS supercarts, you have to know someone who can flash them for you.

Edited September 10, 2009 by peteym5

[candle]

one thing to this code:

try to use VBLDA VBSTA or similiar macros when reading/writing from/to vbxe - you can't assume its at d640 or d740

 

;--------------------------------------------------------
;vblda	- loads accumulator with VBXE register value
;	  use:	vblda	VBXE_REGISTER

vblda	.macro
.ifdef	__VBXE_AUTO__
lda	VBXEBase+1
sta	vblda_adr
lda.w	:1
vblda_adr	equ *-1
.else
lda	:1
.endif
.endm

;--------------------------------------------------------
;vbsta	- stores accumulator in VBXE register
;	  use:	vbsta	VBXE_REGISTER

vbsta	.macro
.ifdef	__VBXE_AUTO__
pha
lda	VBXEBase+1
sta	vbsta_adr
pla
sta.w	:1
vbsta_adr	equ *-1
.else
sta.w	:1
.endif
.endm

 

and here are how VBXE address space is defined:

 

.if .not .def __VBXE_AUTO__ .and .not .def __VBXE_D700__	; default case - vbxe at 0xd640
VBXE_BASE		equ	0xd600
.elseif .not .def __VBXE_AUTO__ .and def __VBXE_D700__		; vbxe is assumed to be under 0xd740
VBXE_BASE		equ	0xd700
.else								; vbxe should be autodetected
VBXE_BASE		equ	0x0000
.endif

VBXE_VIDEO_CONTROL	equ	VBXE_BASE+0x40
VBXE_XDL_ADR0		equ	VBXE_BASE+0x41
VBXE_MINOR		equ	VBXE_BASE+0x41
VBXE_XDL_ADR1		equ	VBXE_BASE+0x42
VBXE_XDL_ADR2		equ	VBXE_BASE+0x43
VBXE_CSEL		equ	VBXE_BASE+0x44
VBXE_PSEL		equ	VBXE_BASE+0x45
VBXE_CR			equ	VBXE_BASE+0x46
VBXE_CG			equ	VBXE_BASE+0x47
VBXE_CB			equ	VBXE_BASE+0x48
VBXE_COLMASK		equ	VBXE_BASE+0x49
VBXE_COLCLR		equ	VBXE_BASE+0x4a
VBXE_MB_CTL		equ	VBXE_BASE+0x5d
VBXE_MA_CTL		equ	VBXE_BASE+0x5e
VBXE_MA_BSEL		equ	VBXE_BASE+0x5f
VBXE_BL_ADR0		equ	VBXE_BASE+0x50
VBXE_BL_ADR1		equ	VBXE_BASE+0x51
VBXE_BL_ADR2		equ	VBXE_BASE+0x52
VBXE_BLITTER_START	equ	VBXE_BASE+0x53
VBXE_BLITTER_BUSY	equ	VBXE_BASE+0x53
VBXE_IRQ_CONTROL	equ	VBXE_BASE+0x54

 

you may also consider using this structure for Blitter calls:

 

BLTBLK	.struct
orgin_ptr	.long
ostep_y		.word
ostep_x		.byte
dest_ptr	.long
dstep_y		.word
dstep_x		.byte
width		.word
height		.byte
and_mask	.byte
xor_mask	.byte
col_mask	.byte
zoom		.byte
pattern		.byte
control		.byte
.ends

 

those macros and addresses are for FX 1.20 core - this is finall version, and won't get changed again unless some major bugs will be found

we are pretty sure that all cliches of previous core version were fixed - for long time there was noone who could write something for this card, but things are getting better

[peteym5]

I was about to ask how to detect if VBXE is present and at what address. Now with Autodetect, does it like capture all the stores going to certain memory locations and puts them into the proper VBXE register locations? Or do we have to set up something that modifies all the register writes in our code? Like I said portions of ML code are copied to ram because we need self-modifying code to speed things up.

[candle]

autodetect:

 

;--------------------------------------------------------
;		Zero page variables for VBXE
;
;--------------------------------------------------------
.zpvar	VBXEBase	.word
.zpvar	Y_Register	.byte

;--------------------------------------------------------
;		Common calls for VBXE
;
;--------------------------------------------------------

;--------------------------------------------------------
;VBXE_Detect - detects VBXE FX core version 1.07 and above,
; and stores VBXE Base address in VBXEBase
VBXE_Detect
lda	#0
ldx	#0xd6
sta	0xd640			; make sure it isn't coincidence
lda	0xd640
cmp	#0x10			; do we have major version here?
beq	VBXE_Detected		; if so, then VBXE is detected
lda	#0
inx
sta	0xd740			; no such luck, try other location
lda	0xd740
cmp	#0x10
beq	VBXE_Detected
ldx 	#0  			; not here, so not present or FX core version too low
stx	VBXEBase+1
stx	VBXEBase
sec
rts
VBXE_Detected:
stx	VBXEBase+1
lda	#0
sta	VBXEBase
vblda	VBXE_MINOR		; get core minor version
clc	 			; x - page of vbxe
rts

 

MADS can generate reference table for use with self modyfying code that would contain all addresses for places to fix (like relocation table), but TeBe should explain this

[peteym5]

That is very useful and since I intend to copy routines from the cartridge ROM to RAM anyway during its initialization, I can have it watch for STA, STX, STY to VBXE registers and set the high byte to $D6 or $D7. That does solve a problem that a few of us have been wondering about.

 

All the games I am working on use player/missile multiplexers that are self-modifying code and must be stored in ram. It references all the sprite definitions by number ( 1 is a spaceship, 2 is a UFO, 3 is an Atari user flipping a Commodore user the bird.) The rest of the program writes information to a table containing definition#, x, y, etc. When the multiplexer is called it looks up this table, like put spaceship at 124,124 and decides what player to use, and updates the player/missile area + DLI table that finally updates the registers. My ideal if VBXE is present, it read the same table and blit a 256 color version of that spaceship to 124, 124. I am aware if using 320 mode, the x position has to be multiplied by 2.

Edited September 11, 2009 by peteym5

[candle]

seems like a good idea

you can get 160 resolution using LowRes overlay mode

but its enteirly up to You

[Heaven/TQA]

Candle, how is the assembling of the board going on?

[candle]

30 boards assembled, today i'm going to finnish the firmware, and start shipping those boards

 

developers first, so yours should be send within a week (need to put it into Your 65XE)

[Heaven/TQA]

cool...

[peteym5]

I am looking at various bitmap loaders and do notice they chop the first 1078 bytes off. Is that the whole header on a 8-bit bitmap. It is easy to come up with something that can remove it and save in a new file. If anyone intends to use these bitmaps for their games, it will start making it a pretty large game to be distributed on cartridge or disk.

[Rybags]

Sounds about right.

 

At least with an 8-bit colour index, pictures should compress reasonably well with RLE... other methods should go OK too.

 

Maybe we need some new pic compression format - JPG is just too slow, and I doubt that the legacy ones with compression were designed with 8-bit pixels in mind.

[candle]

remember that windows bitmap is strangly complicated format of storing raw data... rows are upside down, and data are always dword aligned (if size of the picture is not dividable by 4, then its stuffed with zeros at the end of the line to make it dividable)

[GroovyBee]

I am looking at various bitmap loaders and do notice they chop the first 1078 bytes off. Is that the whole header on a 8-bit bitmap.

Yep! The first 54 bytes contain a header block of information about the image. The next 1024 bytes are the palette data stored as 256 lots of G,B,R,0 (stored as bytes). The other important information you need to know is that pixel data for each row is stored starting on a 4 byte boundary (after the first row). If the width of the bitmap isn't a multiple of 4 pixels, extra zeros are added to the end of each row. The image data is also stored upside down.

[Rybags]

Not always upside-down... there's actually a bitflag somewhere that tells the loader which way up.

 

I tend to use Photoshop to do my stuff... it's got the option to store the pic either way.

 

A "proper" pic loader should really examine the bitflags and image parameters in the BMP file... I tend to just read the raw data, trusting that I've saved it in the proper way.

[GroovyBee]

I'll have to disagree. The standard 54 byte header does not allow for a flip image flag. The data is stored upside down as is the standard for DIB format.

[peteym5]

I'll have to disagree. The standard 54 byte header does not allow for a flip image flag. The data is stored upside down as is the standard for DIB format.

 

So that is why the one example I am looking at has a flip image. I am looking at an ideal of simple compression involving looking for repeated data since we have the black background as color 0. What a routine can do is simple have 0 followed by how many black pixels. This would not be too difficult to do on a 6502 and be a very small routine. I am not looking for something that takes up more than a few hundred bytes on a cartridge. Doing JPEG style is ludicrous and has artifacting issues

Edited September 14, 2009 by peteym5

[GroovyBee]

Have a look at the algorithms for PCX and GIF89a. Both are lossless compression and used in 256 colour palette bitmaps.

[candle]

consider using RLE and DELTA compression used in FLI/FLC files

it might get handy soon

 

since i've annouced i'm starting shipping the boards in last friday, and i'm still writing the firmware i feel i need to apologise

 

this is how the final board presents in 65XE without ECI port:

 

 

and thats what firmware looks:

 

(this is S-Video, not VBXE output)

 

why is taking so long?

I don't want to make lame excuses, but it just take me and electrons most of our spare times - i'm responsible for firmware at board side, and electron upgrades fc.com utility on atari side to make use of all features that are possible with vbxe2

 

vbxe v1.x has up to 4 banks for core storage, where vbxe 2 has 12 banks + bank for firmware upgrade (not implemented yet) and test core for repair/debug purposes that checks VideoDAC and SRAM chip

Firmware upgrade (meaning the ATMEGA48 firmware) is not implementer on Atari, nor Atmel side

additional bank support is not implemented at Atari side

 

Most of the command set that controller has is implemented, today i'm finnishing with last two

 

it was long day with debugger and all kinds of stack problems you can get writing under assembler and not making a "pop" before you would "ret"

 

if someone (speaking about the developers here) is anxious to get his board with the current version of firmware - just drop me a line, there is standard ISP header on VBXE2 so anyone having AVR programmer will be able to upgrade it

in other case - please be patient - i'm working on this 17-18hrs a day having all other things left behind

[candle]

uhm, can't edit, so need to post an update

 

all commands except those for flashing the atmel chip are implemented

we even haven't decided what opcodes should those have

 

nite!

[Heaven/TQA]

hehehe.... is it my 65xe?

[peteym5]

Looks like PCX design is not too far from what I had in mind. If its just containing the sprite definations, chances are it will not be a huge image. I was intending on making the total width of the image at like 128. Which is something I can work with. Its hard to predict how many sprites a game will use. I have to see what the Zoom options can do. Is it simple 2x, 4x, etc?

[DamageX]

Here's a suggestion for compressing 8bpp images. It may be desirable to break large images into blocks or lines first, but anyway, after processing imagine that the output (compressed) data looks like this:

 

1 byte - number of colors used in the image (minus 1)

? bytes - list of the colors, in the order that they first appear

? bytes - compressed bitstream

 

Here is how the decoder would interpret the data for decompressing.

 

- first pixel will always be the first color in the list

- for the second pixel there are two possibilities. Either it is the same color as previous, or it is the next color in the list. So read one bit to determine the answer

- if the bit is clear then for the third pixel there will again be only two possibilities, otherwise the number of possibilties for the third pixel increases to three and we may have to read two bits to determine the answer

 

take this data for example:

 

image (16 bytes total)

0,0,15,30,0,15,30,60,15,30,60,40,30,60,40,255

 

compressed data (11 bytes total)

(bytes)

5

0,15,30,60,40,255

(bits)

0

1

1

00

01

10

11

01

10

11

100

10

11

100

101

(note that I wrote bit strings MSB first while they would be stored/read LSB first)

 

Doesn't take a lot of code to implement and it should be effective in the case that only a fraction of the available 256 colors are actually used in the image.