mos6507's Blog - CPLD autoswitching

RSS Bot · September 20, 2007

Delicon successfully implemented CPLD autoswitching in combination with a simple "staller" program I wrote that copies itself into zero-page and runs a simple rainbow kernel for a fixed number of seconds. The CPLD appears to take only about 7 seconds to program, but we're giving it some extra buffer before it jumps out just in case.

So the way it works is there are three CPLD core files. The most common schemes are available in all of them. The ARM autodetects the banking scheme of the game you want to load and sees if the core file in the CPLD can handle it. If it can, it loads it immediately. If it can't, it reprograms the CPLD while the staller program is running and then indirectly jumps to init the cart.

Here is my wonderful code. If someone thinks they can squeeze a fancier kernel into 128 bytes, please give it a shot. Remember, while the kernel runs it can't access any cart addresses at all.

	processor 6502
include vcs.h
include macro.h

;===============================================================================
; Z P - V A R I A B L E S
;===============================================================================

SECONDS_TO_PAUSE = 11


;ScreenTop_ram = $00B0


SEG.U   variables
ORG	 $80

reserved	ds 8
bk		ds 1
bk2		ds 1
bk3		ds 1
bk4		ds 1
jiffies		ds 1
seconds		ds 1

ram_start   .byte


;===============================================================================
; R O M - C O D E
;===============================================================================
SEG	 Bank0
ORG	 $f000

Start
CLEAN_START



LDX #ram_routine_end-ram_routine
copy_ram
LDA ram_routine-1,X
STA ram_start-1,X
DEX
BNE copy_ram

LDA SECONDS_TO_PAUSE; seconds to pause
STA seconds
LDA #60
STA jiffies

;
JMP ram_start



; copy this to RAM
ram_routine


ScreenTop
lda  #2
sta  VSYNC
sta  WSYNC
sta  WSYNC
sta  WSYNC
lda  #43
sta  TIM64T
lda #0
sta  VSYNC

WaitForVblankEnd
lda INTIM
bne WaitForVblankEnd
sta WSYNC
sta VBLANK
sta WSYNC




LDA bk
STA bk2

LDA bk4
STA bk3

LDY #100 

ScanLoop


LDA bk2
STA COLUBK
DEC bk2


STA WSYNC 
DEY
BNE ScanLoop


LDA bk
STA bk2
LDY #100 

ScanLoop2

LDA bk3
STA COLUBK
DEC bk3


STA WSYNC 
DEY
BNE ScanLoop2


LDA #2
STA WSYNC
STA VBLANK
LDA #0
STA COLUBK


OverScan ;***************************** OVERSCAN CALCULATIONS
LDY #21
KillLines
STA WSYNC
DEY
BNE KillLines

INC bk
DEC bk4
 
DEC jiffies
BNE ScreenTop

;LDA bk


LDA #60
STA jiffies

DEC seconds
BNE ScreenTop



;if you want to see it end in an emulator, uncomment this
;Done
;	LDA #$B8
;	STA COLUBK
;	JMP Done


JMP ($FFFC)
ram_routine_end


org $FFFC
.word Start
.word Start

The current technical problem we're having is the cart is drawing too much power to work with the microSD card for the current voltage regulator. We actually have to go a little over spec in the hopes that short bursts will be safe enough for the system. Delicon replaced the regulator on his system and it fixed his brownout problems. I have to do the same on my end once I get the proper part. We do have a power jack on Chimera but we are desperately trying to avoid making a wall-wart a mandatory accessory. It should ideally only be required for power-hungry peripheral boards like the PS2 adapter (which has its own ARM on it).

Right now the CPLD files and the zero-page staller are being loaded from microSD. When we're done they will be embedded into the actual ARM firmware so the only microSD access will be when loading the game files themselves.

Power requirements when loading from the surface-mount flash chip are much lower than microSD. The original intention was to not support removable media as a cost-cutting measure. That way you wouldn't be forced to purchase a separate microSD card to get up and running. It would just be instant plug and play. But with a microSD socket on the standalone Chimera, and microSD cards rapidly coming down in price, it seemed like the extra flash chip might become redundant. The flash chip is also not required for "embedded" Supercharger or Chimera games that can fit in the leftover space of the 512K ARM flash. Right now we don't know how much space there will be but I'm hoping at least 128K. So it's more for use with future Chimera-native games that the cart will auto-boot into. I just don't know whether it has to be there in all cases.

Anyway, the hardware has proven itself capable of being a functional multicart. To be a truly viable one, though, it needs an onscreen menu. That's the next big hurdle. When I get the regulator replaced I'll get a video posted so you'll be able to see it switch between games for real.

http://www.atariage.com/forums/index.php?a...;showentry=3883