Jump to content

EricBall

Members
  • Content Count

    2,362
  • Joined

  • Last visited

Blog Comments posted by EricBall


  1. Actually, I think you can only get 5 columns of sprites onscreen with even spacing. 3 copies with medium spacing followed by 2 copies medium spacing. 12~8-24-8-24-8~24~8-24-8~12 = 160

     

    This also means some very tight timing requirements. 6 cycles to do the updates (out of 8 for the 24 pixel gap) leaving 4.67 cycles to do the loads. It might just be possible to use immediate for COLU and and indexed for the GRP. I'd have to do a timing spreadsheet.


  2. I always wonder how fun could be have with a computer without a monitor and without a keyboard. Can I play some games with an Altair 8800?

    Well, I once had a book of programs for the KIM-1, which was a 6502 based computer with a only hex keypad and a LED display. The book gave a bunch of games, including classics like "hunt the wumpus". I suspect you could even adapt some of them to be playable with only lights and switches. You just have to know what each input & output means then use your imagination.


  3. Regarding the 6502, things sure are clear in hindsight. But even such, it's hard to see how anyone saw real utility for (ZP,X) addressing. I'd like to see the logic diagram for the 6502, so I could see how much logic was wasted on this.
    Actually, the Commodore 64 KERNAL keeps a table of indirect vectors in ZP RAM for various service routines, including (IIRC) keyscan, print a character, and so forth. So, at least in their case, there's a good case for having a jump table in RAM indexed to find a service routine.

    JMP (ZP) is a different addressing mode than (ZP,X). (ZP,X) is ---000-- while JMP (both absolute and indirect) are ---011--


  4. It depends on whether you are planning on mid-screen repositioning and what else you plan on doing each line. You can easily do 9 pixels wide using a the player & missle for each sprite. (Assuming you have the cycles and storage to handle the missle updates). You can also use HMOVE or NUSIZ updates to fiddle with the effective width.


  5. When I reinstalled XP for someone, the USB keyboard wasn't enabled in the BIOS, so it didn't work unless Windoze was running. But without a keyboard, I couldn't update the BIOS, nor could I type anything to get Windows reinstalled. So I had to run home and grab a PS/2 keyboard just to get the OS installed. I'd bring one along just in case. And a laptop with a modem, for sure, just in case you need to get online.

    Good point about the keyboard.

    I also had to call Microsoft to get an approval code or something like that. I can't remember what they asked me, but I was rather annoyed that I had to do all this. For this reason, I will never, ever, ever install XP or any future M$ product on any of my computers unless they stop this practice. When Win2k becomes annoyingly obsolete, I'm going 100% Linux and/or Mac.
    That's the Windows Produce Activation. There's a couple of files which need to be backed up and restored.
    Make sure that you install SP2 before conneting to the web.

    One advantage of high speed internet over dialup is you can use a NAT router/firewall. I'm bringing one with me for just that reason.


  6. I coded up most of the routine then did some cycle counting. Unfortunately, it's worse than the "find the display list" routine I used in BallDemo. It's a simpler routine and the not-in-list checking is fairly quick. However, when you multiply the 26 cycles each sprite takes by the number of display lists you end up with a larger number of cycles. Sigh


  7. Both paddles and driving controllers need to be read as part of the kernel, and I don't know how much flexibility BB gives you in that area. But I do agree that there are certain classes of games where a paddle or spinner is superior to a joystick because you aren't limitted to a single speed.

     

    Sure X is nice, but it often doesn't play nice with the native windowing system. It's also heavy on the network; so much so that I will VNC into a local system instead of running the X-Server on my PC. (And that's the exception, 99% of the time I stick to SSH shells.) Window Managers, fonts, focus handling, and window controls can also cause headaches.

     

    Multi-user is good, but tough to get right from a security perspective unless you're really hard-nosed and dilligent. You also have to prevent users and rogue processes from gobbling up the CPU, RAM, and disk space impacting the other users & processes.


  8. For me I find there's high points and low points.

     

    Chunks of code which seem to write themselves, mind-twisting problems which can either be a pain or pleasure to solve, glue logic (the stuff which gets from one chunk of code to the next) which is annoying because it's fiddly and it has to be done before you can actually see things in action, frustrating code rewrites, and the often tedious debugging sessions.

     

    And it can be very, very time consuming. I have to almost schedule in time when I'm slogging through the low points, and schedule time for other stuff when I'm racing through the high points.


  9. Nope. Don't even bother trying to sort the sprite list. Just scan through the list for each display list looking for ones with Y values in the appropriate range.

     

    Actually, the sprites are sorted - back to front (although the front ones may flicker if there are too many sprites on the line).

     

    I'm betting that the Y value comparison is a simple enough operation that it can be done very quickly. So the fact that you have to scan through the sprite list N times isn't a big deal.


  10. I agree, I'm just hoping that these are the same as my THX Widescreen Collector's Edition VHS tapes. For that version they went back and cleaned up the picture and made some subtle improvements on some of the optical effects. (Although I don't think they fixed the wormy Emperor.)

     

    But most importantly, they did nothing else. No re-voice overs. No micro-edits so you don't see guards getting lasered. Just making the video (and audio) as good as possible.

     

    I'm going to wait to see if whether these are the real deal before I buy them.

     

    And I too had been making DVDs from those VHS tapes. Capture from S-Video input with lossless compression, gently filter and IVTC with AVI Synth, compress at a high quality/bit rate with TMPGEnc.


  11. You can always voice your idea on the forums. And, who know, it might even be appealing enough for someone to decide that it would make a good enough game that they want to put the effort into creating it. But don't count on getting anything other than an acknowledgement unless you provide a lot more to the project than just the idea.

     

    Funding, hmmm... What's a couple of hundred hours at minimum wage? A couple of thousand dollars? At contract programmer wages? Tens of thousands? Consider that Glenn Saunders put up US$1000 of his own money for the SuperCharger Contest and there have only been a couple of entries I'm aware of. (And there's less than 2 months to go.)

     

    The fact of the matter is no-one can be as passionate about your idea as you. If you really want to see your idea become reality then you need to put in the time and effort and do the work. The one good thing is there are lots of people who are willing to help you along the way.


  12. You can always go 32k. There 16k and 32k carts cost exactly the same to produce.

     

    True - though it seems silly to go from 16K to 32K just to add an easter egg.

     

    Just give yourself the option and reserve the bankswitch addresses now. If you don't use them, fine. But later you might come up with an idea which would use that extra 16K.


  13. Uhh... no, thanks. I'd only touch MARIA if someone was pointing a gun at my head :)

    I regard MARIA as a great sounding idea which turned out to be not so great when put into practice. The reality just didn't match up to the fantasy.

     

    Could MARIA and the 7800 been better? Yes, but I think if you tried to address each of the problems with the 7800 you'd end up closer & closer to the NES. e.g. DMA stealing too many CPU cycles? Put it on a separate bus (like the NES). Tiled scrolling backgrounds painful to do and take too many GPU cycles? Use a dedicated background look-up table with hardware scrolling (like the NES). Display lists still getting you down? Use hardware sprites (like the NES). 160 resolution too blocky & 320 resolution too many color issues? Use 240 resolution (like the NES). You see where I'm going here?

     

    The one place I think the NES could have been improved was to use zero page addresses for hardware registers (like the 2600/7800). This is particularly true for the NES which uses them frequently. (Much, much more frequently than the 7800. Though not quite to the same extreme as a 2600 kernel.)

     

    I feel the same way, though the main problems for me with the 7800 is that it doesn't have anything like the same following as the 2600, and the emulator support is not there yet.

    There's probably a chicken & egg thing going on here. The first stage of emulation is ensuring existing games run correctly. The second stage is actually emulating the hardware with all of it's limitations and quirks. This is true of many emulators. For example, MAME developers have a habit of preferring to trying to emulate the hardware (and portability) at the expense of playability.


  14. I have to say that they look impressive. You've definitely captured the look & feel of the original. (Which version are you grabbing the frames from btw?)

     

    Now the challenge is going to be squeezing all of these sprites into the 6K ROM space along with all the level data!


  15. Funny that these are called "don't care" states. Obviously we care...

    No, not "don't care" - undefined. Well, I guess they are "don't care"; the ex-6800 engineering team who created the instruction set and schematics (which were then were layed out by hand; and even more amazingly, successfully the first time) didn't care what those opcodes did. They simply tried to use the smallest number of gates to achieve the list of features Chuck Peddle specified.

     

    it's hard to see how anyone saw real utility for (ZP,X) addressing.

    Yes, (ZP,X) isn't frequently used on the 2600. But imagine that you have an array of pointers to lists, i.e. *strptr[X]. Must more useful when you have more RAM and ROM space. Think of the Apple ][ and manipulating an array of strings or multiple pseudo stack pointers.


  16. IHMO the following corrects the decoding quirks:

     

    INX E8 -> EA (part of the INX row, same as DEX wrt DEC)

    NOP EA -> B8 (which is the lost SEV instruction)

    TYA B8 -> 88 (part of the STY row, same as TXA wrt STX)

    DEY 88 -> C8 (one bit off DEX)

    INY C8 -> E8 (one bit off the new position of INX)

     

    This also introduces a new opcode for EB, which would probably be (A AND X) SBC # -> A -> X

     

    I'd also add the missing addressing modes to STX, STY, CPX, CPY and BIT. I have no idea why they were excluded. (Well, maybe some additional logic would be needed to allow CPX to use the LDX addressing modes.)


  17. But if you start playing around with the instructions, you'll see that there aren't quite enough bits to give every instruction the same number of addressing modes
    By my count that's 38, including some nice "bonus" instructions. So there would be 26 opcodes left over--room for still more goodies. What am I missing?

    You're correct. I was remembering a think exercise where I fantasized* about adding additional addressing modes across the board (mostly making X & Y orthoganal) and using those addressing modes for more opcodes (plus adding opcodes like ADD & SUB). In that case I ran out of bits.

     

    If you look at this opcode map, you will notice that certain opcodes only appear in certain rows and certain addressing modes always appear in certain columns (with exceptions of course). I suppose this was done to save costs and maybe increasing decoding speed, even though it "wastes" quite a few opcodes.

    Actually, if you make a table with 00, 04, 08, 0C, 10, 14, 18, 1C across the top (addressing modes) and then group the remaining bits by the two LSBs (00, 01, 02, 03), i.e. 01,21,41,61,81,A1,C1,E1 are the ALU opcodes; you will see the logic. Really the main offenders in the whole scheme are NOP,INX,DEX,INY,DEY, and TYA. They don't seem to fall into place. In fact, all of the X & Y opcodes seem slightly misplaced.

     

    But you're right; other than those exceptions, the opcode bytecodes were designed to simplify decoding and reduce the number of gates required to implement the 6502. The whole reason why the whole 03 block of 64 opcodes wasn't defined (leading to instructions like LAX) was it simplified decoding each block to a NAND gate and two wires instead of a full 1 in 4 demux.

     

     

    * What? You don't fanasize about creating the ultimate 8-bit ISA?


  18. I wonder why the 6502's designers didn't simply use the same addressing logic for all of those instructions (basically say that if the two LSBs of an opcode are not both zero, the next three bits set the addressing mode). That would seem much easier than having all sorts of special-case logic to handle instructions like BIT, CPY, and CPX.

    Actually, there is a certain logic to the addressing modes for the different opcodes. The main ALU ops (LDA, STA, ADC, CMP, SBC,AND,OR,EOR) all have eight addressing modes. Then there's another (larger) group of opcodes which also share (a smaller number of) similar addressing modes. Then there are the other opcodes which didn't fit. But if you start playing around with the instructions, you'll see that there aren't quite enough bits to give every instruction the same number of addressing modes

     

    That's not to say there aren't some quirks and places where the symetry is broken for no apparent reason. (Or things which seem like they might have been done more efficiently.)


  19. (btw, am I the only guy who wishes the 650x had a carry-enable flag similar in concept to the "D" flag?)

    I've always wished for ADD and SUB instructions (without carry) so I don't have to put in CLC/SEC for an extra byte & two! cycles. A disable carry would only be useful if you had to do carry affecting instructions between a carry affecting instruction and a carry effected instruction. Not something I've run into that often.


  20. I guess I don't quite see the problem with the normal straightforward method. If someone is climbing a ladder or falling or otherwise has a 'pegged' X position, the LSB should be 128 rather than zero; if that is done, I would think everything should be fine.

    That would be another way of handling it except that then means I need an extra CMP to determine if the sprite is on grid instead of LDA XFPOS / BNE off_grid.

     

    On the other hand, if you will require motion on no more than 127 frames every 256, there might be some slight advantages to using the 'signed-LSB' method if you take advantage of the overflow flag. This code gains a little on efficiency because there's no need to test whether velocity is positive or negative. If there's no overflow, it doesn't matter; if there is an overflow, the sign of pos_lsb will be the opposite of the sign of direction.

    That's a nice bit of code. I think I'll revamp SpaceWar! 7800 (which uses a lot of signed fractional addition) to use it rather than how I'm doing sign extension now (after I'm finished Leprechaun of course). For Leprechaun the sprites have an action rather than a velocity so I use SBC/ADC. Thus I can INC/DEC based on the overflow flag alone. (Of course, I'm doing a complete rewrite of that code, so who knows what it will look like.)

     

    Oh, that's one problem with having a signed fractional byte rather than an unsigned fractional byte (which is the usual when treating a 16 bit (signed or unsigned) value as an 8.8 fixed point value - you can't use the carry register to easily add two 16 bit values. You'd need code to set/clear carry based on the overflow flag before adding the second byte. Not as elegant. Ummm... thinking about that more, I'm not sure that would work right. Let's just say it's not as simple when doing x.x + y.y with signed fractional bytes versus x.x + 0.y and leave it at that.


  21. I'll agree that UMD movies were very predictably DOA, especially at the price point they were charging. They might have been more popular if they were at a lower price point (maybe even pack-ins with tie-in games) and could be an impulse buy. But otherwise it was just a way to show off the screen until better games showed up.

     

    The funny thing is many PSP owners do watch movies on their PSP - ripped from a DVD to a memory stick.

×
×
  • Create New...