| |
TWW
Registered: Jul 2009
Posts: 541 |
The big VICE & SuperCPU Thread
I open this thread so coders may share information and issues regarding the Vice SuperCPU Emulator.
I found 2 issues;
The TCD command doesen't work. PHA/PLD works fine. Tried the XBA tp make sure there was no funny business with the C register beeing mixed up but same result.
I did a wipe-mem routine which clears memory. Obviously a 16 bit STZ DP is the way to go and just relocating the ZP for each page you wipe. However a dumb 16 bit STZ Abs,x (2 cycles more/instruction) is faster then a loop with roughly 20 cycles overhead. The math doesen't add up as the DP aproach consumes less cycles acc. to ref. material. Can it be the RAM refresh and branching which causes aditional wait times (I read somewhere that a RAM Refresh takes 8 cycles) which causes the deviation? |
|
... 12 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11135 |
Quote:and they will be just as boring on the SuperCPU :)
you can rotate them 20 times faster -> part is over much earlier -> less boredom =) |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
Quote: Texture mapped 3D objects are boring on the PC, boring on the Amiga, and they will be just as boring on the SuperCPU :)
But you have the ability to write to the VIC every cycle so I bet you can do some wicked crazy stuff there. Vicious SID style audio effects are virtually "free" too, you'd only lose 60 out of the 1260 or so cycles you have each line...
mayve an allborder flat shaded inconvex poly at 25 or 50 fps, would please both of us ;) |
| |
Trash
Registered: Jan 2002
Posts: 122 |
Quote: Texture mapped 3D objects are boring on the PC, boring on the Amiga, and they will be just as boring on the SuperCPU :)
But you have the ability to write to the VIC every cycle so I bet you can do some wicked crazy stuff there. Vicious SID style audio effects are virtually "free" too, you'd only lose 60 out of the 1260 or so cycles you have each line...
You could do everysecond line FLI with new D800-colors each fli-line with sprite-underlay and splits on the spritecolors that would give you 4x2 pixels with any color of your choice, right? |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
Quote: You could do everysecond line FLI with new D800-colors each fli-line with sprite-underlay and splits on the spritecolors that would give you 4x2 pixels with any color of your choice, right?
now we're talking :) tho probably there would be no time to split the sprite colors, because the VIC will need the free cycles bcoz of the badline and sprites. |
| |
Trash
Registered: Jan 2002
Posts: 122 |
True, but three colors + backcolor + a fourth fixed spritecolor per 4x2 would be sufficient for most needs...
EDIT:
Now when I think about it, three colors + background per 4x2 would be doable with no more than a REU... |
| |
Count Zero
Registered: Jan 2003
Posts: 1825 |
Indeed there is a lot of trickery possible on a SuperCPU. Double buffering stuff and switching optimization modes, writing to 2 registers at once or having the zeropage at $d000 to speed up register writes. I am really curious as to what demostuff people come up with now and who finds the best use for too many cycles _left_ :)
|
| |
Ninja
Registered: Jan 2002
Posts: 406 |
Wow, I made them more than a dozen of years ago, still you might find my articles about SCPU timings interesting:
http://the-dreams.de/articles/scpu-superram.txt
http://the-dreams.de/articles/scpu-badlines.txt |
| |
chatGPZ
Registered: Dec 2001
Posts: 11135 |
i like how the existance of supercpu demos only depends on the availability of an emulator.... reminds me of what happened when reu was finally emulated correctly =) |
| |
enthusi
Registered: May 2004
Posts: 675 |
I shall write a demo that utilizes warp-mode and RAM-injection of vice. |
| |
AmiDog
Registered: Mar 2003
Posts: 97 |
The SuperCPU64 has 128KB of SRAM and the SuperCPU128 (which also works on the C64) has 256KB. Bank $01 is described as "PseudoROM, RAM" and should basically contain a copy of the C64 ROMs for performance reasons.
I remember trying to use bank $01 for some timing sensitive code back in 2005/2006 or so, but it failed for some reason. Does anyone know if bank $01 is write-protected somehow, or if the SuperCPU does treat bank $01 in some special way making it hard/impossible to use for custom code? Perhaps parts of bank $01 can be used?
Since I wasn't using any ROM routines, I kind of assumed I should be able to use bank $01 for my own code, since the SuperCPU really only needs to remap bank $00 ROM accesses to bank $01 ones and shouldn't need to mess with direct bank $01 accesses at all. |
| Previous - 1 | 2 | 3 - Next |
