Jump to content

EricBall

Members
  • Posts

    2,427
  • Joined

  • Last visited

Blog Entries posted by EricBall

  1. EricBall
    This weekend while my wife was in Miami and my son was at school or asleep I played far too much Half Life 2. I got the game as part of the Orange Box for the PS3, which I bought to play Portal. But HL2 is an FPS and thus is verbotten in my wife's opinion. But what she doesn't know. . . Based on the walkthrough, I've played through over half of the game (maybe even two thirds). And although I had fun, it wasn't quite as satisfying as the original. I will say that I thought many of the environments were extremely well done. City 17 felt real. You could feel the oppression, depression and collapse. The sheer hopelessness is amazing. Ravenholm was convincing as a zombie town. And the train bridge captured the feeling of climbing hundreds of feet over the river.But there were many other things which I didn't like. The biggest is how linear the game is. You can't get lost, although you may have to search a little to find the next exit. But when I was trying to escape City 17 I quickly realized I simply had to follow the most obvious path and I would be on the right track, which kinda defeated some of the fear & tension.Also high on my list of dislikes is how long the loads take. Maybe it's just the PS3 port, but I found it very annoying when the action stops as it loaded the next section. Since the game is linear, couldn't the next level be loaded in the background half-way through the level? It's also kinda sad when I can predict when a set scene is going to occur.I also found the story worse than HL1 - in spite of it being more complex. Why the G-Man brings you back and where the new Combine aliens came from is never really explained. And maybe Dr. Breen isn't the "bad guy", he's just trying to make the best of a near hopeless situation.Finally, the NPC and enemy AI doesn't seem to act as intelligent as HL1 - i.e. charging mindlessly into overwhelming fire. (Although it's kinda nice when I had the big gun on the car. I'd park the car, spring the trap, then run back to the car.) And although it's initially distressing when "friendly" NPCs get killed, I quickly realized there was no impact. (And if they are dumb enough to attack a gunship with an SMG standing out in the open, then the predictable will happen.)
  2. EricBall
    Although I don't program games for a living, I visit gamasutra.com daily. A common topic in many articles is "free-to-play", from philosophical treatises to in-depth tutorials on how to best convince players to pay-up. Personally I think "free to play" is killing the industry (Nintendo being the current whipping boy) because it disrupts the most direct feedback loop between the creators and the players.
     
    You see, IMHO players should be paying for content, because this is what the programmers (and other artists) are creating. Subscription based games are the best example of this as part of the monthly fee can be used to fund content creation - which makes the players want to continue paying the subscription. Sequels are a more drawn out form of the same thing. If enough people bought the first game, then a sequel gets made for people to spend more money on.
     
    But FTP doesn't work like that. It uses "free" to entice as many people as possible to play the game. But then it turns around and tries to find ways to get players to pay as much money as possible. But the players don't want to pay - they are in the "why pay when you can have it for free" mindset.
     
    Furthermore, because the players often aren't paying for content, the creator's effort goes into finding ways to improve & optimize squeezing money out of players. And in some cases all players (whether they are paying or not) are costing the creators money in server rentals & bandwidth.
     
    Meanwhile, traditional payment games and companies (e.g. Nintendo) are suffering because buyers have access to large amounts of free content.
     
     
  3. EricBall

    rants
    "Turn asteroids into space habitats!  Just use self-replicating robots." Says the blurb - and I immediately stop reading.  Because, unlike the author, I've actually given the concept of self-replicating robots some thought and have concluded they are distinctly non-trivial and not something humanity is likely to create in my lifetime.
     
    In my case I was considering von-Neuman probes - inter-steller spacecraft which use the resources of the destination solar system to create replicas which are then sent out to other nearby solar systems.
     
    The problem with self-replicating spacecraft (or robots) is they have to be capable of a huge number of industrial processes as everything which makes up the spacecraft, including the machinery etc used for the processes, must be manufactured by the spacecraft from the raw materials it can obtainThis means the spacecraft not only needs to be able to fabricate integrated circuits, but it needs to be able to manufacture the machinery used to fabricate the integrated circuits, and able to manufacture the machinery used to refine raw ores, etc. etc.
     
    Once you start to think about what would be required, the idea of a self-replicating robot becomes laughable.  An inter-planetary spacecraft, certainly because size isn't as much of a factor.  One question is whether it would be possible to obtain or synthesize all of the necessary materials by mining asteroids and the inter-planetary medium to avoid the need to enter and exit planetary gravity wells & atmosphere.
  4. EricBall
    I finally took the plunge and bought Minecraft for the PC (after playing many hours on the PS3). An article about 2B2T, an "anarchy" server with a world which is now five years old, intrigued me. The world is littered with stuff players have built up and others have torn down. The central spawn point is a wasteland of blocks floating far over bedrock. Simply not dying of falling or starvation when you start is difficult.

    And yet, in spite of it's reputation as a lawless environment, it's surprisingly peaceful once you escape the spawn zone. Even in the spawn zone there are oasis where wood and food can be found, left behind by good Samaritans. And none of the other players I've run across has attacked me, in spite of the NSFW chat. (Even the hostile mobs seem placid.)

    OTOH, any of the chests I have found are empty or only contain the most trivial items. Food is still scarce, although I've been lucky finding a few melon farms which haven't been razed. And in spite of walking close to 9km of game distance, I am still finding frequent evidence of previous players.

    A couple of notable items I've come across on my journey. First was I stepped through a Nether Portal with the intent of gathering some netherack. But when I stepped back through the portal I found myself in a completely different location, far underground. While some use the nether to more quickly move through the world, I think I will avoid it until I am better prepared.

    Second was the pair of Mooshroom cows in a normal forest biome. I don't know whether another player lured them there from their Mooshroom island home, or whether they spawned there due to some bug, but I appreciated them and milked them for their mushroom stew. I briefly considered trying to set up camp and farm them, but it was too close to the spawn zone to avoid the griefers who delight in destroying whatever they can find.

    A shout out to doctrzombie for his YouTube videos which have inspired my 2b2t journey.
  5. EricBall
    My second base was semi successful. While the mine bottomed out into lava, it still yielded a few diamonds and other ores; but no emeralds (not that I've seen a village, where emeralds are used for trading). I also found an abandoned mine shaft, complete with a cave spider spawner. Unfortunately, it's difficult to create a automated grinder for cave spiders.

    I constructed a Nether portal, but discovered it linked to an existing portal so I didn't return to my base. I now better understand how portals are linked. Given the number of existing portals it may be difficult to use them in the way I do on the PS3.

    Once my spiral mine could no longer be extended without running into lava or obsidian, I packed all of my most valuable items and prepared to leave.

    The first thing I did was to build another emergency respawn point. I tweaked my layout to both reduce the amount of dirt required and avoid potentially not respawning adjacent to my bed.

    I decided to journey back to one of the primary axis and follow it back towards the spawn area. I was hoping I'd see more of the legendary ruins and constructs which I'd heard about if I was on the "beaten path".

    And I did see some, but not as many as I'd hoped. One unexpected item was the canal along the axis which blazed a path straight through hills and mountains. Building it obviously required a lot of time and effort, but some of its characteristics puzzled me like: why so deep, why line it with cobblestone rather than just leaving the existing blocks, and why bother storing the waste ores in chests and leave behind crafting tables? But it was there, so I used it to speed my journey.

    I did find a couple of interesting bases, including a tower made entirely of obsidian surrounded by fields of catus. Being obsidian made it difficult to walk up and down the enclosed open staircase in the evening twilight. Beneath the tower was an obsidian lake, so the creator may have mined it, but that would have required a large number of diamond picks. Maybe the creator cast it using lava, or used some kind of hack or cheat.

    I also passed a platform high in the sky with both a waterfall and several pillars reaching up to it. I didn't bother trying to get up to it, seldom have I found anything worth the trouble. (I did find one base with an Ender Chest, which I broke before I realized I wouldn't get the Eye of Ender necessary to recreate it.) But still I explored the occasional tower or structure along my journey. However, I avoided the various Nether Portals. Although they might have speeded my journey, they could just as easily send me far off course or kill me.

    But it wasn't Nether portal or other player which killed me (I did see one other player, who was busy clearing ice from the canal). Instead it was a tower and me moving around taking screen captures. The next thing I knew I was falling far enough to kill me.

    The good news is my respawn idea worked. I returned to the platform in the sky where wood and food waited for me. The bad news is lost all of the items I had collected and crafted. So I gathered the wood, broke the floor under the pond and floated down the waterfall to the ground below. I'd built the platform close to my second base, so I returned there to gather some of what I had left behind and think about my next plan.

  6. EricBall
    I am going to start a YouTube channel https://www.youtube.com/channel/UCxuqdYak8Q81EUkUeSDoUVg of my 2b2t experience. My plan is to kill myself so I start back at spawn, then work out from there. Hopefully passing along a few bits of wisdom for new players and a few laughs.

    I'm bringing home a headset from work tonight to see how that works out. QuickTime does a great job of recording the actual gameplay at 4K then converting it down to 720p for YouTube.

  7. EricBall
    My first plan on my journey away from my book making base was to set up a fresh spawn point. So I column jumped up to cloud level and created a 7x7 small platform on which I put small pond, melons, wood blocks and my bed (which I slept in to reset my spawn point). The idea was if I died I would at least have enough food and wood to make a fresh start, and I could get down from the clouds by turning the pond into a waterfall.

    One item of interest I found on my journey was an Ocean Monument, complete with an Elder Guardian - a tough semi-boss who I had no interest in even attempting to defeat.

    I eventually found what I was looking for - an Extreme Hills biome; under which I should be able to find emeralds. So I carved out my second base, starting with a hidden entrance, a room for an enchanting table and bookcases, and a mine shaft.

  8. EricBall
    Current status - static starfield complete (NTSC version)
     
    The next big step is turning the Star X,Y into DLL & DL entries and going to a dynamically built DLLs (one for on grid i.e. StarY&7=0) instead of the static DLL & DLs. Once that's done, I'll need to integrate the 4K SpaceWar! 7800 sprite to DL routine.
     
    Sorry if this is a little dense and cryptic. It's mostly for me to remind me of the design decisions which I've made (or remade).
     
    Reviewed old blog entries, found ROM memory map: 2K even star tiles, 22K (236x88) starfield tilemap, 2K odd star tiles, 2K code, 2K sprite graphics, 2K code/data/signature.
     
    Regenerated starfield tilemap & tile graphics from Yale Bright Star Catalog - all stars < 6 magnitude (visible to naked eye) mapped to 236x108 cylindar (avg of NTSC/PAL aspect ratio), trimmed to 88 rows. 236 tiles per row with first 20 tiles duplicated at end for easy wrap-around. 0,0 = bottom left (note: top left used for sprite positions) so StarY&7 is used for CHARBASE & SPRITE LSB offset on last row & sprite Ypos adjustment. Tile map stored with 0,0 at $8800. Quincunx (diagonal) sampling with bit 0 lower left and bit 1 lower middle right (next row middle at bottom middle left, right). 4836 stars in starfield.
     
    StarX is 2 bytes: 0-235 (row offset, two 4-byte DL entries per DL, width=21/20, handle wrap around by SBC & test) and -8 - -1 (Xpos + odd/even)
    StarY is 4 bytes (2+2 fractional). MSW is 9 bits (8 * (88-25 = 63 row) + 0-7 raster) stored as signed value for SINE routine, so the MSB is just a sign extend (very useful for the SINE routine). The initial values of StarY[n] and StarY[n-1] will need to be adjusted for PAL to keep the starmap onscreen.
     
    RAM will be primarily consumed by display lists (32 required for PAL). The two DLLs take up 213 bytes so can be stuck in $2100, which will extend into the stack page. That leaves 3.5 K for the display lists. Two possibilities exist. First, three 85 byte DLs per page. That nets 18 sprites per row. Second, allow the DLs to cross page boundaries giving 108-116 bytes per DL (depending on ZP overlap) with 24-26 sprites per row. Each player ship can use up to 4 sprite entries per row + shots. One option is to allow larger DLs for the rows which will contain the score etc.
     
    One important item for display lists, vertical scrolling and vertical wrap around. The current SW display list builder uses a additional DL pointer list entry for bottom to top wrap around. With vertical scrolling, the display list builder works in the same way. However, the bottom display list is basically just a duplicate of the top display list with the StarY & 7 offset! I will have to do some thinking to make sure the vertical shift can't push a sprite off the bottom of the screen.
  9. EricBall
    https://entertainment.slashdot.org/story/17/01/19/2218238/3d-tv-is-dead

    I don't dispute that 3D TV never took off, what I find interesting is the TV manufacturers decided to drop a feature - no matter how unused.

    What's interesting is 3D is still popular enough to make 3D films. (Although my preference is for 2D editions I saw Rogue One in 3D because there wasn't a non-3D showing on a big screen.)

    Personally my 55" LG TV is passive 3D capable - so the glasses don't require batteries. I've used it to watch 3D Blu-Rays (e.g. TRON Legacy), but in most cases it doesn't add anything to the movie. But at least I have the capability.

  10. EricBall
    The other day I was browsing a warehouse sale which had a few 4K TVs (but no 3D, which I found interesting), and it got me to thinking about them. Not because I want one, but strictly on a why? basis.

    The local cable company is hyping their 4K TV offering, starting with local baseball and hockey games. But when I'm watching my 55" HDTV, I'm not thinking "boy, I'd pay big bucks to have more picture detail".

    Maybe if my TV filled the entire wall so HDTV looked like 320x200 VGA on a 21" monitor. But then I wonder whether compression wouldn't make the extra resolution moot.
  11. EricBall
    Since I can't find my Leprechaun round tuit, I've told myself I have to work on SpaceWar! 7800 some more. One of the features I really want to add to SW78 is the starfield background (Expensive Planetarium). But the tile map is much larger than the screen, thus it needs to move in some way to show the whole thing. My original idea was to make the movement based on the spaceships wrapping around; they'd kinda drag the starfield with them. The disadvantage with this idea is there are two ships (though "fighting" to controll the starfield might be amusing) and the starfield wraps side to side but not top to bottom.
     
    Then I had a thought - why not make the starfield drift model what it does in real life? Have the center of the screen follow a sine wave around the tile map. Even have the period of the sine wave be different than the width of the tile map so it wouldn't be a simple repeat. Nifty! Okay, but how to implement? The cheap & easy way out would be a lookup table. The main disadvantages is it would be limitted to 256 values (compared to the 1888 pixel width of the tile map) unless I went to a 16 bit pointer and used more ROM. Hopefully it could be done programatically in less space.
     
    Of course there's this little problem - it has to run on a 6502. No FPU with built-in transecendental functions. No floating point registers. Heck, no hardware multiply or divide even. Just an 8 bit ALU with add and subtract with carry. Furthermore, I don't want to be burning up huge amounts of cycles in some fixed-point multiply function. I must be dreaming to even consider the possibility that such a thing could exits. (To be fair, I'll set my accuracy requirements low.)
     
    To my surprise - it is that easy. The Second Order Oscillator from http://www.ied.com/~petr/Oscillators.html meets my requirements exactly.
    The series y[n] = sin(n * a) can be calculated using y[n+1] = 2 * cos(a) * y[n] - y[n-1]
     
    Wow! Perfect! 2 * cos(a) is a constant, and thus I can make it something (trivially) easy to calculate using simple adds and multi-byte fixed point arithmetic. What's more, if you scale y[n] and y[n-1] that scaling flows through to y[n+1] and all other values. So I don't even need to multiply by the height of the tile map; just set the initial values correctly.
     
    I've done some testing using a spreadsheet and figured out that I need to use 8+16 bit fixed point with 2*cos(a) = 2 - 1/64K, so no shifts will be required, just subtract the integer portion (with sign extend) from the least significant byte. This gives a period of around 1609 pixels. I need to do some more thinking & testing to make sure the values don't overflow or decay. But it's definitely workable!
  12. EricBall
    Several years ago I rescued a number of old 4:3 LCD monitors my employer was discarding, including several particularly nice 20" 1600x1200 Dell 2007 FP.  My plan was to use them to create vertical monitor MAME cabinets.  But having learned from past projects, I resisted doing anything on the hardware side until I'd figured out the software side.  And then, like many of my projects, that's where it waited.  I'd occasionally give the idea some thought, but never really do anything serious.
     
    But more recently I've started giving trying to work out a plan.  The basic idea is to use a Raspberry Pi Zero as the CPU, powered off the monitor USB ports.  The monitor also has a 12V power port which could be used to power speakers - but that's hardware so something for later.
     
    From a software side it appears there are a few different front ends which could serve.  Basic idea is to select game via a very simple grid which plays attract mode videos.  This appears to be doable.
     
    But that brings up the question - what games?  The current plan is for a minimalist control panel - joystick plus two or three buttons (depending upon what the games require).
     
    I already have Lakka on an SD card for my Pi0w which has MAME 0.78 (aka mame2003).  So I downloaded the Windows version, generated the XML file and filtered it by vertical monitor and original games.  The plan is to then work through that list and try to figure out what works and what doesn't.
     
    There are 700 games....  this might take a while...
     
  13. EricBall
    I've done some cycle counting of the display list builder for SpaceWar! 7800 and the results aren't pretty:
     
    103 cycles per display list (25 NTSC, 30 PAL)
    403 cycles per player sprite, +191 for horizontal wrap around
    248 cycles per non-player sprite, +82 for horizontal wrap around
    50 cycles per sprite header vertical wrap around
    200+ cycles of overhead
     
    At 114 cycles per raster, just the display list builder is going to chew through all 62 lines of VBLANK.
     
    So, what to do?
    1. Optimize where possible, but otherwise ignore it and risk having the display stutter.
    2. Alternate frames building display lists and game processing. I'd need to recalculate (or fudge) all of the gravity & velocity tables since it would be effectively 30fps instead of 60fps.
     
    #2 sounds feasible, just need to add the DLI wait routine after the display list builder.
     
    Note: SpaceWar! 7800 doesn't do itself any favors when it comes to the display list builder:
    1. 4 way scrolling tiled background
    2. 4 way wrap around
    3. player sprites are double height versus the zones
  14. EricBall
    One of the classic complaints against the 7800 is it uses the 2600's TIA for sound. Maybe that could be used as an advantage.
     
    Imagine a TIA music editor which uses the 7800's graphical capabilities to display notes on a scale and to scroll in realtime during playback.
     
    My only question is how to get compositions out of the 7800 and back to a PC so the creations could be added to 2600/7800 homebrews. Maybe via a SaveKey <-> serial interface?
  15. EricBall
    One of the frustrating aspects of 7800 coding is constructing the display lists. On paper it sounds like a great plan - a list of pointers to sprites with width and horizontal positioning info. Very powerful and flexible, but damn difficult to use in practice.
     
    My balldemo code has, what I thought, to be as efficient way of doing this as possible. The pseudo code goes something like this:
    For each sprite determine which display list based on the vertical position. Add sprite pointer etc to the end of the display list and the next display list. (Each display list controls 1-16 rasters, thus sprites which move vertically need to be in more than one list.) Once all the sprites have been added, add a termination flag to the end of every list.
     
    The main problem with this method is the 6502 is an 8 bit processor, so the code has to use indexed indirect ( aka (ZP),Y ) addressing. So there's a lot of data movement steps, copying data from lookup tables, loading the current end of list offset etc. Ugh. The vertical position fiddling is also not pleasant (although probably unavoidable).
     
    Anyway, it occurred to me this morning that a more efficient way might be to flip the order. So:
    For each display list, scan the list of sprites to determine whether they need to be added based on vertical position. Add sprite pointer etc to the end of the display list. Once all the sprites have been added, add a termination flag to the end of the current list.
     
    Now, I haven't tried to code this yet (I want to but I'm trying to work on Leprechaun) but this should be somewhat more efficient because a lot of the mucking around with pointers isn't required. You set up the pointer only once for each display list. Now, it does require scanning through the list of sprites multiple times, but that should be simple comparisons. (Although there may still be some vertical position fiddling required.)
     
    The other advantage is it should be possible in this case to compact the display lists so each one follows the other. This would be particularly useful if the game double-buffered the display list updates since it would save RAM. (With the sprite -> display list routine each display list has a fixed length and starts at a fixed position.)
     
    Just thought I'd put it here so I wouldn't forget.
  16. EricBall
    After the fire we bought an Acer Aspire One (D270) netbook to use while our laptops were being cleaned. It's biggest problem isn't the 10" 1024x600 screen or the correspondingly small keyboard but the 1GB of RAM. The Intel Atom N2600 isn't a speed demon either, but it's surprisingly adequate for basic web surfing. But once that RAM fills up the system slows to a crawl. So I'm looking at upgrading the RAM and replacing the hard drive with an SSD.
     
    Although officially the system will only support 2GB of RAM, it appears that at least 3GB of a 4GB stick will be recognized even by the preloaded Windows 7 Starter Edition. So now I need to do some price shopping, while trying to avoid the line between "cheap" and "cheap 'cause it's junk".
     
    I have the same problem shopping for an SSD, as there are a lot of reports of people's SSDs suddenly becoming non-functional within the first year. Therefore I'm trying to research people's experiences with warranty replacement, particularly in Canada, on the assumption the drive will fail and I will need to replace it.
  17. EricBall
    One thing I find amazing about the 2600 homebrew scene is the strong interest in creating new bankswitching hardware, often with advanced capabilities. I think, very soon, the only remaining VCS limitations will be the capabilities of the TIA and that there are only 76 CPU cycles per line to update the TIA (hmm... shades of the GTIA/ANTIC).
     
    Anyway, one idea which occurred to me is whether it would be possible for the cartridge to automatically bankswitch the 64K (32K usable) address space. Basically, the cartridge would snoop the address & data buses and pull the missing 3 address bits out of the data stream.
     
    I've done some looking at the 6502 addressing modes and some intelligence & heuristics would be required. The cartridge would have to shadow the PC register so it can determine which data bytes are opcodes (for the correct addressing mode) and which are address MSBs. The tricky bit would be handling the extra fetch when indexed addressing goes over page boundaries and handling branches.
  18. EricBall
    Earlier this year I managed to complain enough to my cableco about their move from analog to digital for SD stations (and the impact on my dual tuner TiVo) to get a free rental HD PVR. Last week I realized there's a whole whack of movies which get shown on the HD channels (i.e. my wife taped Inglorious Bastards, and I watched one of the Transformers movies), but there's no consolidated listing which would make it easy to find the ones which I might want to watch.
     
    But then I got to thinking - I have a subscription to Schedules Direct (for OTA listings used by my HD MythTV), so I can get listings for my cableco too. So my challenge is to put that data (which is an XML file retrieved via SOAP) into some kind of database which I could then query.
     
    Fortunately, there were code examples on the SD forums - including one which put the data into a SQLite database. But the samples were in Python - I guess I get to learn a new programming language.
     
    The code came together remarkably quickly. I used the ElementTree library to convert the XML to Python dictionaries, then a cool bit of Python from the sample code to convert the dictionaries to SQL insert statements for SQLite.
     
    Stuff I liked about Python:
    1. Dictionaries - these are really cool key+value lists and made a great intermediate step between the XML and the SQL insert with the key being the field name.
    2. For loops for lists & dictionaries. It's kinda like the batch "for %a in (*.txt)" - no indexes or linked list pointers required. (Although this makes traditional numeric for loops more .... interesting.)
     
    Stuff I disliked about Python:
    1. Having to put colons at the end of def, for & if statements. Although I can respect using indentation for blocks (I still think if/endif is a less error-prone construct), the number of times I had to re-edit my code just to add colons...
    2. While slicing strings with [start:end] is cool (especially being able to use negative values for RIGHT$), I don't know why [3:4] doesn't return two characters. It's like I'm having to include a character for the zero terminator.
    3. I'm not sure I agree with the copy by reference default. Outside of some recursive tree routines (where the child needed to modify the child pointer in the parent), I've seldom had reason to copy by reference in my programs. I'm much more likely to want spam=eggs to have spam be a copy of eggs. It just seems to me I'm much more likely to accidentally forget the .copy() and have problems when modifying spam or eggs affecting the other.
    4. I hit some runtime code errors which would have been nice to detect at compile time, like trying to use a new variable as an lvar or a type mismatch. I appreciate that Python doesn't require the programmer to declare a datatype for each variable, but that doesn't mean the compiler can't track variable initialization and types and flag obvious problems.
  19. EricBall
    One of the knocks against the Propeller is it has no code protection, unlike PICs and other microcontrollers with onboard EEPROMs. And although the protection may be less than perfect, I can understand many companies are not willing to have their IP in an easily accessible state.
     
    IMHO the way to remedy the situation is to include a small amount of onboard OTP storage for an encryption key and integrate a decryption routine into the bootloader. But for that to work someone (i.e. me) needs to code up the crypto routines. So I've been learning all about AES and working out how to code the routines in Propeller Assembly.
     
    I've coded up a first attempt at the encryption routine and it's surprisingly compact - less than 1K. I've done some cycle counting and it's over 14K cycles per 128 bit block! At 80MHz that works out to 88K per second, so that's not too bad as far as load time is concerned, adding less than a half a second for 32K. The biggest time sync is the combined ShiftRows + SubBytes routine which has to do a table lookup for each byte and reorder the bytes in the four 32 bit columns at just under 1K cycles for each round, and there are 10 rounds per block.
     
    And although crypto sounds big and scary, it's actually not that complex. The toughest part is keeping the byte order straight when reading the spec! (Like the 4 bytes which make up the 32 bit column are shown as [a0 a1 a2 a3], where a0 is the LSB!) AES breaks down into four or so main subroutines (SubByte which does a table lookup, ShiftRows which mixes bytes between words, MixColumns which does a matrix multiply on each column, and a routine to do a polynomial multiply by 2). The parts which operate on the 32 bit columns are easy on the Propeller, but the byte operations are painful!
     
    My next step is to wrap the code in something I can use to view the results then start going through the sample data and make sure everything works.
  20. EricBall
    So the rumors were true. Although I'm not convinced this marriage was a good idea for anyone.
     
    According to the press releases, AMD is going to use ATI to improve it's chipsets, especially wrt integrated graphics, with the idea to integrate the graphics core and onto the CPU in the future.
     
    First problem - AMD has significant financial issues. They are deep in debt, their stock ain't doing hot, their current mass-market CPUs aren't doing so well against Intel's, and Intel can price-cut much lower than AMD and still make a buck.
     
    Second problem - AMD had the ability to partner with Via, nVidia, and ATI for chipsets (and make non-GPU versions in-house). That will probably dry up fairly quickly.
     
    Third problem - ATI will get locked out of the Intel chipsets, leaving nVidia with the high-end integrated and Intel with the low-end integrated. Whether ATI will be able to go after the console market is anyone's guess.
     
    Fourth problem - the growth market is in low-power integrated chipsets, not in high-performance GPUs. Not to say that ATI can't make low-end chipsets, but so could Via.
     
    Fifth problem - integrating a high-performance GPU and CPU on the same die is going to significanly cut into yeilds. And AMD is currently having problems getting their process shrink & yeilds up to speed. Although this is more a future concern than something immediate.
     
    I'm also just not seeing the full benefit to ATI. AMD doesn't have the finances to be a major sugar-daddy to ATI. It's cutting ATI off from a lot of flexibility which they had when they were on their own.
  21. EricBall
    "The Death of PC Gaming"
     
    Attention all PC gamers, start saving your pennies now.
     
    Based on the above article, it sounds like Microsoft might manage to kill PC gaming. In brief:
     
    1. DX10 will require a DX10 capable graphics card and Vista
    2. Indications are DX10 graphics cards will have substantial power & cooling requirements, potentially requiring a bigger power supply
    3. Vista will definitely require more RAM than XP, and will probably require more CPU
    4. Indications also are DX10 graphics cards will be primarily PCIe, it may be tough to find AGP versions
     
    So to play the latest & greatest PC games with all the DX10 graphical bells & whistles you will need:
    1. a new OS
    2. a new graphics card
    3. and, depending on what you have now, a whole new PC
     
    Hmm... all of a sudden the PS3 is looking mighty cost effective
  22. EricBall
    There's a free Angry Birds beta available via the Chrome App Store. I've played through the first 21 screens and I can't understand why it's so popular.
     
    This isn't to say that I don't enjoy it. I certainly had fun with this physics/puzzle game. But I also found the gameplay somewhat frustrating, and my tolerance and patience for failure is reasonably high. Thus, I imagine that most people would find the game very frustrating (confirmed by my wife), thus I am puzzled by why it's popular.
     
    The problem, IMHO, is the game asks the player to do two tasks:

    Determine the "right" place for the bird to hit to kill the pigs.
    Pull the slingshot back correctly to hit the desired target. (With the additional timing requirements for some of the birds.)

     
    Unlike some other parabolic arc firing games I've played, Angry Birds doesn't give the player any help in determining #2 for the first shot. Yes, you can refine your later shots base on the previous one, but that doesn't help with that first, often critical shot. And that's a problem. Because unlike a game like Worms where a mis-aimed shot typically has no negative impact, with Angry Birds that first shot can often cause the structure to collapse in such a way that it's significantly more difficult, if not impossible, to kill the pigs using the remaining shots.
     
    So, in order to be successful you have to accomplish both #1 and #2 on the first shot with no aids to assist with either. Difficult? Yes. Frustrating? You betcha.
     
    I also can't imagine trying to play the game on an iTouch/iPhone with the level of accuracy required with the slingshot (unless it's really zoomed in compared to the WebGL version).
  23. EricBall
    One of the weird characteristics of the SuperCharger is the bankswitching. On one hand it does have some flexibility in mapping the three 2K RAM banks to either the low ($1000-$17FF) or high ($1800-$1FFF) banks, with or without the ROM BIOS (always $1800-$1FFF). But on the other hand, there are a limitted number of possibilities:

    D4-D2 bank config 000 3 ROM 001 1 ROM 010 3 1 011 1 3 100 3 ROM 101 2 ROM 110 3 2 111 2 3
    The big limitation (IMHO), is there are no options for bank 1 & bank 2 together.
     
    And I just realized I'm going to have to redo the bank layout for Leprechaun . . . Again! I'd just gotten everything worked out using bank 3 low for the kernel with plans for bank 2 high for the 6 digit display. But now I've realized that it makes more sense to put the level timer at the top of the screen, which means bank 2 can be low, which will make it easier to leverage the 6 digit routine for the "load next level" screen. But that means I need to make bank 3 high, since there is no 2+1 layout. This means I need to move the kernel to bank 1 since $1000-$10FF is only accessible in read-only mode, and make sure $1700-$17FF (last page in bank 1) is part of the level data since the SC BIOS will clobber it during multi-load.
     
    So 2+ROM for end of level, load screen and probably title screen, 2+3 for level timer (top of main screen), 1+3 for main kernel and game logic. Hopefully I've gotten it right this time.
     
    Now, one cool thing about the SC is the file doesn't have to be stored in order. Which means the file can be in memory order rather than bank order.
  24. EricBall
    For those interested in Apple ][ copy protection (and cracking of it) I have found two troves of information.

    First is the 4am Apple ][ Library at https://archive.org/details/apple_ii_library_4am Attached to each archive is a text file where 4am describes his cracking process. In most cases he simply follows the boot process, analyzes the often obfuscated code to figure out how to capture the next step in the process, then determines the minimum change required to allow the disk to be easily copied. (e.g. https://archive.org/details/Gumball4amCrack )

    Second is PoC||GTFO 0x10 (pocorgtfo10.pdf, available from https://www.alchemistowl.org/pocorgtfo/and other mirrors) which contains an article on various methods of disk were made uncopyable, or at least impossible to copy without being detected.

    Finally, http://fabiensanglard.net/prince_of_persia/pop_boot.phphas information on the RWTS18 format used by Prince of Persia. There's also source code at https://github.com/jmechner/Prince-of-Persia-Apple-II

    See the comments from http://atariage.com/forums/blog/7/entry-2436-more-apple-musings/and http://atariage.com/forums/blog/7/entry-2514-more-disk-musings/ for previous discussion on this topic.



  25. EricBall
    One of Woz's design decisions for the Disk ][ was to force the MSB of each byte read to be 1. Although this restricted the number of values each byte could take, this was already restricted by the number of sequential zero bits i.e the time between changes in magnetic field; initally 1 (DOS 3.2), later 2 (DOS 3.3). But the restriction on the MSB had several positive side effects:
    1. The MSB could be used as an easy "data ready" flag by the CPU.
    2. The read sequencer could hold the completed byte even after the MSB of the next byte was received. This gave the CPU extra time to read the completed byte.
    3. Extra zero bits between bytes could be ignored, which allowed the read sequencer to automatically synch to a series of FF bytes separated by 1 or 2 zeros.
     
    One alternative would have been to store each set of 8 bits in a FIFO which the CPU could read. But then the CPU would need to perform the synchronization - determining the start & end of each byte.
     
    The following is a decode of the state machine for the DOS 3.3 Read Sequencer. For each state (n the left there)are four possible commands+next states depending on whether the MSB of the shift register is 1 or zero and whether a read pulse (change in magnetic field=1 bit) was received from the disk. Note: The command takes effect as part of the state change.

    MSB=0,RP=0 MSB=0,RP=1 MSB=1,RP=0 MSB=1,RP=1 0 NOP 1 NOP 1 NOP 1 NOP 1 1 SL1 2 SL1 2 NOP 3 NOP 3 2 NOP 3 NOP D NOP 2* NOP 0 3 NOP 4 NOP D NOP 4 NOP 4 4 NOP 5 NOP D NOP 5 NOP D 5 NOP 6 NOP D NOP 6 NOP D 6 NOP 7 NOP D NOP 7 NOP D 7 NOP 8 NOP D NOP 8 NOP D 8 NOP 9 NOP D NOP 9 NOP D 9 SL0 2 NOP D NOP A NOP D A SL1 B SL1 C NOP B NOP D B SL0 5 SL0 D NOP C NOP D C SL0 D SL0 D CLR A NOP D D NOP 0 NOP D NOP E NOP E E SL1 F SL1 F NOP F NOP F F SL1 4 SL1 D CLR E CLR E
    One important note is the "code" won't read the first byte correctly when entering read mode from "sense write protect" mode, which leaves the system in state 0 with the MSB in an unknown state. Maybe it was felt programs would typically leave the Disk ][ in read mode and there was no need to try to read the first byte after a mode switch correctly. Thus, the logical point to start figuring out the behaviour of the sequencer is to start with the "Hold" state which occurs when a byte has been completely read - state 2 with the MSB set, marked with a *.
     
    What this simple command+state does is ignores any zero bits between bytes. Once a read pulse is received it starts with state 0 (MSB=1) and continues down, ignoring any read pulses for the next 4 cycles, then waiting for the next read pulse or another 8 cycles. (It acutally waits up to 13 cycles total for a read pulse before deciding the bit is a zero.) If a read pulse is received then it jumps to state D (MSB=1), waits for another few cycles, then clears the shift register and shifts in the first bits. (The CLR naturally forces the MSB=0 for the next state.)
     
    This is all about holding onto the completed byte as long as possible as the CPU needs the data to be at least 7 CPU=14 state machine cycles (for RLOOP LDA $C08A,X + BPL RLOOP), even though there is only 4 CPU=8 state machine cycles between bits.
     
    On the MSB=0 the logic is fairly simple - wait for a read pulse. When RP=1 jump to state D, wait for RP=0, then jump back to state 0, wait one cycle, then shift in a 1. If no read pulse is recieved after 11 cycles then shift in a zero (it only waits 8 cycles for the second zero). The only trick is after the shift it jumps to state 2, which kicks over to the "Hold" state when the MSB=1 after the shift.
     
    One interesting item is how the "code" tries to mask unstable read pulses. In some cases the state transitions after a read pulse is received ignore futher read pulses for several, but in other cases (such as state D MSB=0) the code loops indefinitely waiting for the read pulses to stop. This is done because the the magnetic transition might "ring" (in either the magnetic or electrical domain) causing extra pulses (hopefully an even number); so it makes sense to somehow ignore them.
     
    Waiting for the read pulses is more efficient, but this affects zero bit detection. In theory bits would occur every 8 state machine cycles, since that is the timing of the write sequencer. However, that assumes the disk is rotating at exactly the same speed as it was written (and there is no jitter in the clock supplied to the state machine, which I believe there is). Thus the read sequencer needs to allow for some variation - both fast & slow. Where problems can arrise is with two quick zero bits, or where there is 3 * ( 8 - ? ) - 1 cyles between one bits. The read pulse masking could reduce that number of cycles futher, which could cause the second zero bit to be lost since the state machine has to wait 2 * ( 8 + ? ) cycles to decode the zero bits.
     
    Coming up with alternate state machines is an interesting exercise. The real limitation is there are only 16 MSB=0 states which have to handle stuffing the first two bits into the byte and then detecting the other six bits.
×
×
  • Create New...