Chimera update
Earlier in the week we were able to verify that Supercharger games are working again. I haven't tried any multiloads other than Survival Island, but odds are, we're good to go on that front.
Next, we've been able to get bidirectional serial communications working. We wrote a test program that lets you type characters in Hyperterminal and have them echo back after reaching the VCS.
Next, we were able to get queues working again (I don't think I'll call queues Ouroboros anymore, it's too hard to type). Right now queues appear to work when running out of ARM RAM. We're limited to only 16 of these (4K total). Tomorrow we're scheduled to test queues out of cart SRAM, where timing is much tighter. The current hotspot memory map we're using supports 100 SRAM queues, hence 25.6K bytes, but we have 64K to work with. So ultimately we may adjust how the hotspots operate. We want to limit the hotspots to the last page of cart RAM so as not to steal away too much space from code.
Also, we were having some problems with RF interference with the serial cable connected. Through some serendipity we were able to solve this problem by enabling a resistor pack component that is on the cart between the VCS and the CPLD. We hope that this part should both help protect the cartridge from getting fried by bad VCS code and also enable alternate ways of writing RAM.
The most recent demo written has 4 queues running at once providing playfield bitmaps. Two represent the first iteration of PF1, for graphics and color. The third represents the background color underneath the second iteration of PF1. The last is the second iteration of PF1 graphics. In addition to mirroring text back out to Hyperterminal, I poke the data into that last queue. The VCS has no trouble keeping up with incoming keypresses during VBLANK. We're currently running at 38.4K baud. I expect us to eventually be able to bump this up to 56K. We also have to implement hardware flow control.
For those whom seeing is believing:
This is an early demo so it isn't really showing anything that couldn't be done through other means (although processing incoming serial through a controller port would be nasty). But a big part of this is making it easier.
Here is what the kernel code looks like for this demo. Pretty simple, huh?
StartKernel ; Set PF Pattern sta WSYNC ;lda #%10101010 ;sta PF1 ;sta PF2 ; Count Kernel Lines ldy #KERNH KernelLoop lda CH_QUEUE_FAST sta PF1 lda CH_QUEUE_FAST+1 sta COLUPF SLEEP 21 lda #00 sta COLUPF lda CH_QUEUE_FAST+2 sta PF1 lda CH_QUEUE_FAST+3 sta COLUBK SLEEP 8 lda #00 sta COLUBK sta WSYNC dey bne KernelLoop ; Clear PF Pattern sty PF0 sty PF1 sty PF2 EndKernel
I hope to eventually show some demos that probably could not be done through other means. The text mode we have to work on for the menuing system will be the one to look for. We should be able to share a few boards with interested parties if they want to work on fancier demos than I can create. Let me know.
2 Comments
Recommended Comments