Jump to content

solidcorp

Members
  • Content Count

    459
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by solidcorp


  1. Did you end up selling it? How much and was the guy a member of AA per chance? Inquiring minds want to know :)

     

    Nope, no one has even inquired about the price.

    What is the price?

     

    What's it worth?

     

    From a cost basis it took somewhere between 500 and 800 hours to write the software, plus PCB & PLD development, plus machining a custom clear cartridge - on a CNC machine I designed and built as well.

     

    Plus all the subjective stuff - it's connected to a big piece of video game history - and only one was every made.

     

    ...and it's an awesome game. :)

    • Like 1

  2. I'm showing the latest Star Castle 2600 at Video Game Summit 2011 right now.

     

    It starts easier, has level progression, better controlls, and more. It's a one of a kind stand alone cart, I just finished the clear cartridge that lights up with the game action.

     

    And best of all, as of today it's for sale.

     

    D. Scott Williamson

    • Like 7

  3.  

    I really haven't looked at this in great detail - I thought it might be worth looking into for ScumSoft since he's doing a dpc+bitmap kernel. I would have to sit down with pen and paper to look at the possibilities - I presume you're hitting respx once for each player? I just thought something might be possible with the cycle savings from dpc+, I was hoping you where using a loop though for a few more cycles saved to be honest though :P

     

    The players are set to tripple close mode. I hit RESP0 and RESP1 four times each per line, but each time you hit them within a scan line it seems to restart the scanning at the start of the first space, so you get two copies of the player that look like[space][player][space][player]. The arrangement of player 0 and player 1 is critical since you have to load graphics and strobe the resets at very particular times that in most configurations will either overlap meaning that you need to write a RESPx and a GRPx register in the same cycle, or they are so close together that you can't fetch data fast enough. It takes 18 pixels to load and store one byte from zero page:

    lda zp ; 3 cycles, 9 pixels

    sta zp ; 3 cycles, 9 pixels

     

    I presume your using zero page loads for the data, so that would be one cycle saved per load for 8 cycles. He could also lose txs,tsx since you can just load immediate, for 4 more cycles.

     

    Immediate can only work for constant data, not characters that change every line.

     

    Doing the ball is a no brainer lda #,sta enabl could be done at any point to use 5 cycles. Hopefully we could keep that data in the accumulator and ror, sta enamx at the appropriate point for 4 more cycles. We'd have to use the 1st or 4th copy of the missile only and disable or have disabled the missile before the 2nd or 1st copy appears.

     

    The vertical delay and all the registers including the stack pointer must be used to attain the timing needed for venetian blinds. Data is loaded into the delay registers of P0, P1, and the display of P0, data is also loaded into SP,A,X, and Y, then the first store to RESP0, then it's a race to load and store all the register to position and write the pixels of the 8 bytes of sprites on that single height scan line.

     

    I hadn't been thinking about using all the registers since i didn't realise this was needed when the copies were 8 pixels apart, I guess that's an artifact of having to hit respx at the right point? So I was hoping Y say could be kept with the d1 bit set to 0. So just sty enamx at any point. That would just squeeze into the cycles saved but I thought there might have been a few more available.

     

    Remember that the players are set to triple single width mode and the missiles will be too. You can have different settings for both, otherwise, there are plenty of cycles for setting ball/missile and even playfield graphics.

     

    I guess it's possible to shave off quite few cycles by not using venetian blinds?

     

    Yes, venetian blinds take more cycles and are harder because you need to reset the graphics registers more frequently and have to use a single scan line kernel.

     

    I may try and knock something up - any hints to the respx timing I've always been a bit confused by where the extra copies appear, I presume you have to hit at some point between the first and second copies, instinct would be to hit it at exactly the start of the second copy, but I'm not sure that's right?

     

    Yes, like I said, when in triple player mode and you write RESPx more than once a scan line, it appears that the player graphics will appear 8 pixels to the current pixel location at the end of the sta instruction, and it will only show two copies. Set up a test case and play with it in Stella, use the debugger to tweak values or set up many scan line experiments at one time to view results.

     

    Edit: Didn't remember respx trick right, I have to hit it three times between changing grpx right?


  4. On CRT-based screens, flicker-blinds are better than column-based flicker. On some LCD screens, flicker-blinds come out really ugly and column-based flicker is decidedly better.

     

    Call me a purist, but I like using the 2600 unmodified with same technology that was available in its heyday (the 70's and 80's).

     

    That means a CRT TV, I never had my 2600 connected to an LCD TV as a kid and I'm not going to start now! ;)

     

    Scott


  5. Many of the RESPx strobe techniques suffer because sooner or later you end up needing to write to a RESPx on the same cycle that you need to write to a GRPx register.

     

    Also, like supercat said, since the CPU runs one cycle for every 3 color clocks and the quickest you can write to RESP values is in 3 cycles or 9 pixels (without using BRK or JSR tricks which require the stack pointer get reset) single pixel gaps or overlaps are all but unavoidable. Such is life.

     

    There is still a lot of time in the lines of my kernel to do more interesting things like set colors or adjust the playfield but remember that the missiles inherit their NUSIZ from their player and are trippled just like the players if that is enabled. It also takes more code to enable and disable the missiles and the ball. Due to timing and the trippling I abandoned trying to fill the center with one more column of missile/ball text.

     

    I don't use DPC in this kernel, though I have nothing opposed to "illegal opcodes". I use macros to display the venetian blinds of 5 lines without loops (2 different synchronized routines used on alternate frames). For timing I also absolutely had to use vertical delay and I used the stack pointer as a byte register (TXS,TSX) to recover a byte in 2 cycles instead of reading from zero page which would have taken 3 cycles at a critical moment later in the scan line.

     

    Can any of you post links to your screnshots or relative posts?

     

    Scott


  6. Has anyone ever made a 32 character text display on the 2600?

     

    Yes; my 32-character routine works as two groups of sixteen (or, more specifically, two groups of 64 pixels wide, with a 16-pixel gap, at 50% flicker. BTW, I also have a routine to do flickerless three groups of three sprites, and a specialized routine to show "ATARIAGE" at 50% Venetian blinds with 15-pixel-wide characters.

     

    Cool, I knew someone must have been down this road and I'd find them here.

     

    I really don't like the flickering as opposed to venetian blinds, I think Stella is very generous with the phosphor setting as compared to what you see on a TV (my TVs anyway).

     

    How are you doing flickerless three groups of three sprites?

    (If you hit RESPx more than once on a scan line in triple player mode, it resets the hardware after the first sprite displays so you just see a space, sprite, space, sprite.)


  7. I also like most of Random Terrain's suggestions about the character set, the only exception being for "Q." I'm thinking of this instead:

     

    post-7456-0-10780600-1303251287_thumb.png

     

    It doesn't look as good with the 3x5 character size, but is still readily recognizable as "Q." It looks better if you have another line or two for lowercase descenders, so the tail of the "Q" can be in the first (highest) descenders' row.

     

    Michael

     

    I really like it, that's a trouble character, I may use yours thanks.

     

    Scott


  8. How about using a second font shifted over a pixel? It looks like selectively using a shifted font would allow you to smooth out some of the spacing issues.

    I was thinking the same thing, but you might not need a second font, just shift/rotate the data before storing it in RAM. There might still be two or three spots where the spacing will be off, but it should look a little better.

     

    I also like most of Random Terrain's suggestions about the character set, the only exception being for "Q." I'm thinking of this instead:

     

    post-7456-0-10780600-1303251287_thumb.png

     

    It doesn't look as good with the 3x5 character size, but is still readily recognizable as "Q." It looks better if you have another line or two for lowercase descenders, so the tail of the "Q" can be in the first (highest) descenders' row.

     

    Michael

     

    As it is it takes about 11 scan lines (I think) to convert the 32 characters of text into 80 bytes of graphics data. Adding shifts would time unnecessarily and may reduce the number of scan lines displayable. In this case, if it worked, I'd gladly trade the 512 bytes of character data for the cycles saved.

     

    Scott


  9. How about using a second font shifted over a pixel? It looks like selectively using a shifted font would allow you to smooth out some of the spacing issues.

     

    That was the plan, I did that, it didn't work. :(

     

    The timing is so exquisitely delicate that the graphics registers are being changed while they are being displayed. By adding shifted characters and using them to fill selected columns fixed the columns but bled into earlier usages of the player graphics. There are no free cycles to pull the open gaps together either.

     

    I reiterate though, it is possible to make two perfectly spaced columns of 16 characters separated by 6 or 7 pixels. Maybe there is a use for that.

     

    Also, there are tens of cycles free in a couple places every 2 scan lines (one venetian blind) to do free color cycling or set playfield graphics as long as you are able to change those values at the time slots you are given in the scan line.

     

     

    Scott


  10. Note the character spacing, I wish I could get it perfect but I believe that's impossible. There is one other working configuration where there are two groups of 16 characters that line up perfectly, but they are separated by 6 or 7 pixels in the center of the screen, so unless I want to make it look like newspaper columns, I thought this configuration worked better.

    . . .

     

    Questions? Comments?

    Too bad you can't get it to always have one space between characters and a larger space between words. Kind of hard to read the way it is.

     

    If I was making the characters, most would look like what you have, but there would be some differences. The image below shows what I might have done (my possible character replacements are darker).

     

    post-13-0-75190100-1303248125_thumb.png

     

    Thanks, I may take you up on most if not all of your suggestions.

     

    Scott


  11. Screenshot.

     

    I got venetian blinds in last night, and man does that make a difference on a real TV. This screenshot is from Stella with the command line phosphor flag turned on and it's pretty representative of what you see on the TV.

     

    The lines of text could be a few scanlines closer together - I burn extra scan lines for the edges of the green color bars and for the anti-aliased holes in the sides of the paper.

     

    My video frame timing is really sloppy in this demo, VSync, and overscan times are perfect but I couldn't even tell you how many lines this is trying to display right now. It's close enough to 192 that it doesn't roll on my TV though - I'll sort that out later when I get vertical scrolling working. It could preload one line of text graphics into RAM in VBlank, but I don't think that would buy enough time to display another line of text - maybe if I stripped out all the decorative code - idk.

     

    Note the character spacing, I wish I could get it perfect but I believe that's impossible. There is one other working configuration where there are two groups of 16 characters that line up perfectly, but they are separated by 6 or 7 pixels in the center of the screen, so unless I want to make it look like newspaper columns, I thought this configuration worked better.

     

    Its a hare over 2.5k. There are no fancy tables for combined characters or anything, just 51 five pixel tall characters(256 bytes)of the font in the left 4 bits and the same in the right 4 bits.

     

    Nukey Shays comment and looking at the Harmony menu has me thinking about spending another 260 bytes on a lower case font too (only 26 glyphs need to be case sensitive).

     

    Questions? Comments?

    post-18143-0-28383500-1303235418_thumb.png


  12. It sounds like you're strobing RESP0 and RESP1 to get extra copies of the sprites. Good job! I'm looking forward to seeing the result.

     

    Michael

     

    Exactly right Michael. The trick is configuring the hardware (it's behavior is unexpected) and getting the writes to GRP0, GRP1, RESP0, and RESP1 in exactly the right order at exactly the right time. There are [at least] 6 configurations that I proved can not possibly work. This configuration works with some character spacing concessions. Venetian blinds introduces more headaches because there is a limit to how quickly you can retrieve the character data into the four 8 bit 6507 registers to stuff into the hardware regs AND you have to fill all 80 bytes of character data between lines. I think the image quality is totally worth it over PacMan ghost flickering though.

     

    There are no illegal opcodes used [yet] either - but I wished for a bunch!

     

    Well, I better get back to it...

     

    Scott


  13. I haven't heard about the "Star Castle 64K" project yet. Are there any more details about it?

     

    StarCastle will always run in 8k to be historically relevant (I know, I know, Yars Revenge was a 4k cart, but there were 8K carts at the time and I just set out to prove it was technically possible to make the game at that time and that it wouldn't suck). There are some improvements in the StarCastles game since last year.

     

    To make StarCastle, I decided to make my own cartridge from scratch, PCB, EEPROM, PLD, LEDs and all. The maximum capacity is 64K, 16x4k banks which is working with two software controllable LEDs. I used Stella and the Harmony cart for 99% of the development though using F8 bank switching.

     

    The StarCastle MegaCart is a 64K cartridge that is intended to "exhibition" my work on StarCastles. I'm not much for saying what I plan to do, but I guarantee I'll tell you all when I have something to show. ;)

     

    Scott Williamson


  14. The solution for N is to use a tall "n" instead. So there's only M and W to worry about in a 3x5 font.

     

    I thought about that, the font graphics are still a little low on the list at the moment. :)

     

    I really like the mixed case used in the Harmony cart, but am single case now. I have the bits and space to do mixed case... maybe later.

     

    Thanks!

     

    Scott


  15. So each letter is 4 pixels wide leaving 1 pixel space between letters? Sounds a bit scrunched to me.

     

    It's scrunched, the same 3x5 font I used in S.T.U.N. Runner on the LYNX - it gets a little dicey with "M", "N", and "W", they are distinguishable but context starts to become important. :)

     

    Two characters per player, just like all the other text routines (except those that use players and the ball). Each letter is 3 pixels wide leaving 1 pixel space between letters - most of the time - as I said there are spacing artifacts that, so far are unavoidable due to the intricate timing required and the use of the four 6507 byte registers. I find the text display acceptable. It is not as nice as the evenly spaced 24 and 28 character text displays, but it was a feat to get all that text to just to display on a single interleaved scanline - 8 players worth for 16 characters with venetian blinds effect coming.

     

    Scott


  16. The Harmony cart displays 24-characters. Supercat managed to display 26 characters, but I don't think anyone has managed to top this yet. I'm interested to know how you managed it - can you post up a screen-shot?

     

    Chris

     

    I will, I promise, but please let me clean it up first - I'll try to post a pic in a few days.

     

    Also, there are no HMOVE bars and missiles & ball are unused for text.

     

    Scott


  17. Has anyone ever made a 32 character text display on the 2600?

     

    I've seen the 24 character display

     

    And I think Thomas Jentzsch did a 28 character display (used in the Harmony cart?).

     

    I've been working on one for several weeks and just got it working last night. It's not perfect, it's off center and has a minor character spacing artifact that I'm pretty sure is insurmountable but it's acceptable. I verified it works in both Stella and on the Harmony cartridge (hats off to the Stella team, this kernel uses the hardware in a weird way but the emulation is 100% true to the real platform). It truly can display 32 character strings of any text within the 51 character font. The interleaved text it 10 lines tall and it takes a little more than that to reload the 80 byte buffer. I found an art style/theme that really works within the quirky constraints, I'm not ready to show it though. I haven't finished the Venetian blinds or have it scrolling yet either, but those are details, technically the hard part is done.

     

    This will be part of the 64k StarCastle mega cart. By the way, the 64K cartridge hardware with 2 software programmable LEDs is working too.

     

    Scott Williamson

    • Like 3

  18. What else known about this unit? How rare it is? and how much would it cost to have one??

     

    Also Where is it widely available?

     

    Saw one of those in a little Atari store in St. Charles IL. I can't think of the name of the place for the life of me.

     

    Was it the General Computer Store? Run by a guy named Ralph?

     

    Or perhaps it was the Compu-Cellar? Run by Don Bahr (my uncle)?

×
×
  • Create New...