Jump to content

supercat

Members
  • Content Count

    7,259
  • Joined

  • Last visited

Blog Entries posted by supercat

  1. supercat
    This version has some significant changes. I rearranged some variables so six bytes' worth of temp variables are now overlayed with kernel temp variables. Hopefully I've eliminated all conflicts there.
     
    It's now necessary to click twice to remove blocks. This allows for a limited preview/undo function. If you click somewhere and don't want to remove the blocks that turned brown, click somewhere else instead.
     
    I added some feeble sound effects as well. Let me know how they are.
     
    Also, if the machine misses the necessary retrace timing, an error screen will appear. Please write down the numbers or symbols that appear and let me know. Then press fire to return to the game.
  2. supercat
    Well, I've got the logic worked out for a "universal" PLD for the AtariAge/CPUWIZ boards using an Atmel ATF750B. The chip is pin-compatible with the 20V8/22V10 which is handy. In a lot of ways I'm not too keen about the design of the chip or the software, though.
     
    The chip is basically positioned as a 22V10 superset. Each output pin (there are ten) has the same set of product terms as on a 22V10, but they're split into two groups. One group feeds a flipflop; the other group feeds, either by itself or "ored" with the first group, into a second flipflop. Either the input or output of the second flipflop may drive the pin; the signal from the pin and the outputs of the two flipflops are fed into the logic array.
     
    Although any of the flipflops may be clocked directly from pin 1 (as on a 22V10), each has a product term that may be used instead (with a slight extra propagation delay). Each also has an independent asynchronous reset chip. There is a global synchronous preset product term, but there's no way to exclude any latches from its effects (which makes it rather useless). Product terms that are not used for these functions are not available for other uses.
     
    Although there are occasions when it's useful to have a pin generate a combinatorial output but have its flipflop fed back into the logic array, it is, to put it mildly, irksome that there's no easy way to have buried asynchronous logic. The separate asynchronous clock and reset functions allow for latched signals to trigger at interesting times, but avoiding race conditions can be a challenge.
     
    Incidentally, while the lack of any buried combinatorial feedback terms is generally a nuisance, having the flipflop on the output of a combinatorial pin can sometimes be useful. Atmel warns that slow-changing clock signals may cause clocks to register multiple times, possibly causing nastiness. My solution in this case it to use the register associated with my "clock output" signal to generate a cleaned-up "clock input" signal.

    cko = (list of "interesting memory accesses"); cko.ckmux = clk; cko.ar = !cko & !clk;
     
    When ana interesting memory access occurs, the CKO pin (pin 22) will go high. This is fed through an RC circuit into CLK on pin 1. When CKO is high, a rising edge of CLK will cause the flipflop behind CKO to go high as well. Even if CLK bounces low and high a few more times, however, the latched signal on CKO will remain high. It will only go low after CKO has gone low and CLK has followed suit.
     
    Unfortunately, the simulator seems to be quite useless at dealing with product-term clocks. Even when I run with maximum verbosity and the simulator shows the clock on a flipflop changing while the data pin is high and asynchronous reset is inactive, nothing happens. So I'll have to do things by hand. Grr...
     
    For my mega-PLD, I've decided to support six banking modes, plus a "boot mode" which on powerup locks the cart into bank 1 until addresses $1FFC and $1FFD are accessed consecutively, whereupon the cart will proceed into F4 mode (starting in bank 1). To switch into another mode, the code must access address $0ACE followed immediately by an address which determines the following mode:

    $0CCC -- Mode 0 (boot mode--not sure why one would do this) $0CCD -- Mode 1 (F4) $0CCE -- Mode 2 (F8) $0CCF -- Mode 3 (F6) $0CDC -- Mode 4 (Parker Brothers) $0CDD -- Mode 5 (no banking allowed--use to put multiple 4K games on a multicart) $0CDE -- Mode 6 (new EE banking)
     
    Note that all of those locations map into RIOT RAM, so a cart can switch modes by copying code to RAM and then executing it. I would consider it extremely unlikely that the mode-switch sequence could occur by mistake even though it's always active.
     
    The new EE mode is a cross between F4 and E0 modes. The top 2K of address space banks into one of eight 2K pages, and the bottom 2K banks into a different set of eight 2K pages. There are six sets of hotspots:

    0068-006F -- Select lower bank 0510-05FF (bit 4 set) -- Select lower bank using A5-A7 0070-0077 -- Select upper bank 0610-06FF (bit 4 set) -- Select upper bank using A5-A7 0078-007F -- Select both banks 0710-07FF (bit 4 set) -- Select both banks using A5-A7
    The $0500-$07FF hotspots are designed so that if code is compiled using "rorg" values of $1000 for the first bank, $3000 for the next, etc. up to $FFFF, the MSB of a code address can be used to select the appropriate bank. For example, if a routine will always be invoked with the stack pointer at $FF, the return code may do something like:

    ldx $FF; MSB of return address nop $700,x; Set both banks for return address rts
    The programmer would have to keep track of whether to set one or both banks, but there's no need for funny bitshifting or conditional logic.
     
    The other set of bankswitch locations is there to save a cycle on bankswitching. I don't really know whether that's apt to be particularly useful, but since it fit I figured I may as well.
     
    Anyone have any comments on the proposal?
  3. supercat
    Imagine that a restaurant were to announce to 100 diners--all strangers--that they would be splitting the tab. If a diner wanted to buy a $50 glass of wine, it would only cost him $0.50; on the other hand, it would also cost the other 99 diners $0.50. If the diner decided instead to have a $2 soda or a $5 glass of wine, he (and everyone else) would pay $0.02 or $0.05, respectively. What would people under such circumstances end up ordering, and what would they pay for it?
     
    Many people would dislike being in that situation, particularly with strangers. While some groups of coworkers will routinely agree to split restaurant checks without niggling over whether everyone's food cost the same, they generally don't want to be seen as unfair by their fellow workers. They will thus either seek to avoid spending substantially more than everyone else, or else offer to pick up a larger share of the total tab. In a group of strangers, however, such pressures will often not apply. If it seems as though many diners are going to have to pay $10 for other people's wine, they'll likely order wines costing around that much themselves, thus pushing the total up higher.
     
    Given a choice, most people would rather dine in a restaurant which allowed them to simply pay for their own meals, than dine in one in which they are required to pay for everyone else's. While there are some all-you-can-eat smorgasbord restaurants, the variety and quality of food is nowhere near what could be found at many pay-for-what-you-eat ones, and for good reason. Customers who are allowed to select expensive food and drink without having to pay for it are apt to do so, even if they wouldn't be willing to pay for the cost of such food and drink themselves.
     
    On the other hand, if some restauranteurs could get the government to require all restaurants to engage in "cost sharing", they'd make out like bandits. They'd be free to put whatever expensive and profitable items on the menu they wanted, secure in the knowledge that some people would buy them and everyone would have to pay for them. At first they might be limited by some restaurants' ability to limit their selections to only cheap ones, but if they could convince the government to require that all restaurants carry expensive foods and beverages, they'd be rolling in gold.
     
    A couple more observations: (1) customers of a cost-sharing business will often find the price to be much greater than what they would want to pay for the goods or services they expect to receive; (2) the quality of goods and services will often be higher than what customers would have wanted to pay for.
     
    Presently, much of what is called "health insurance" is in large measure really cost sharing. A single-payer health system would represent an even more severe form of cost sharing. Fundamentally the only way to get prices under control without restricting people's choices is going to be to increase the extent to which people pay for their own choices. Otherwise prices are guaranteed to increase exponentially until there is no choice but to ration services; rationing services will limit prices, but the variety of affordable choices will be far below what it would have been without cost sharing.
  4. supercat
    Is there any reason why aspiring Presidents should not be willing to prove their eligibility for office as a matter of course?
     
    If Obama was born in Hawaii, why would it not be in everyone's interest for him to authorize the state of Hawaii to officially say so? Note that they have said they have a birth record on file, but they haven't said what it indicates about where he was born (a newspaper article's headline claimed they said the latter, but in the article itself they only said the former).
     
    I would think that if Obama cared at all about the Constitution he should be delighted to demonstrate that he meets the requirements for office. The most charitable explanation I can think of is that, even though he's eligible, he'd rather demonstrate that it's possible for a person to bluster his way into office without proving citizenship, than do anything that would be perceived as acceding to his detractor's demands (no matter how reasonable those demands might be). A frightening prospect since, were he to do so it would pave the way for others who really weren't eligible. That Obama would do such a thing suggests that he's really not a suitable person to be president, but I can't figure any more charitable explanation.
     
    Can anyone else offer one?
  5. supercat
    Really, I do. Because if I'm not 100% wrong about him, one of the world's largest nuclear arsenals will within a few years be in the hands of a third-world nation.
     
    I'll readily admit that McCain was a pretty feeble candidate, but at least he would have let the country tread water until someone better came along in 2012. I believe Obama hates this country and will waste little time running it into the ground.
     
    As I said, I hope I'm wrong.
  6. supercat
    Well, it looks as though the Senate is going to buy a getway car for the worlds' most expensive bank robbery. Unless Congress can stop it, the U.S. may commit economic suicide in the next couple days. STUPID STUPID STUPID STUPID!
     
    The novel-length Christmas-tree piece-of-Sith legislation the Senate just passed will do nothing to resolve the effects of toxic paper in the credit derivatives marketplace, but will cost us about a trillion dollars. As a result of its passage, the crash will be worse than it would have been without it, and we'll have a trillion dollars less of credit to deal with it.
     
    On the other hand, at least people who want to buy a toy bow and arrow for their kid won't have to pay an excise tax for the arrows. I guess maybe that's a good thing.
     
    And McCain--what's up with him? He promises that he'll reject any pork-laden legislation that crosses his desk, and he'll name names. So when a bill with more pork than all the world's sausage factories combined crosses his desk, does he reject it and name names? Nah, he simply approves it. How can he expect to win with leadership like that!? STUPID STUPID STUPID STUPID!
  7. supercat
    Here's a rough kernel test for the 'rings'. This should be quite workable in a real game if everything is flickered at 30Hz (player ship, one shot, enemy fireball, and two chaser mines). Hold player 1 fire to slow down the animation; hold player 2 fire to disable the shift-in data. Color/BW toggles 30Hz flicker. The funny 8x8 block in the middle would be the enemy space ship, which could be drawn at 1lk or 2lk resolution. The plan is probably for rings to have 32 or 48 segments which would be in groups of 3 or so, possibly with some small gaps so that even a full 'ring' would seem to rotate.
     
    The kernel code is horrible and bloated, but should be good as a feasibility test.
  8. supercat
    In case anyone is curious about the exact specs for the music in Stella's Stocking (BTP2 music driver):
     

    4 independent voices; two are output to each sound channel. The voices are otherwise isomorphic.
    Two wave tables, which are used for "loud" and "soft". Normally most voices are shaped to start soft and get loud, or start loud and get soft, or something. In the "Echo Carol" (last tune at fireplace) there's a spot where loud and soft can be heard for a solid stretch.
    Five octave range--61 note chromatic from 65.5Hz to 2096Hz (C3 to C8). Notes in the C diatonic scale are well in tune. Some others not so well, but all pitches are recognizable.
    Subharmonic distortion only exists at pitches one or two octaves down from the target pitch, not at other pitches (e.g. the C8 has some distortion at 1048Hz, but since that's also a C, it's not particularly objectionable).
    All music processing is done by the 6507 processor; it takes 46 cycles every 76 (just over 60%).
    No exotic hardware required for the music, though exotic banking may improve the graphics that I can perform while playing the music.
    If I get Magic Zeepy banking or some similar scheme working, the EBTBTP2 driver will allow for up to 24 or 32 wave tables instead of two, which should allow for much more varied dynamics and instrumentation. That might be considered 'hardware support' for music, but the CPU would still be doing all the real work.

  9. supercat
    I'm curious whether people who support Obama think:
     
    -1- He is not a Marxist, or
     
    -2- Marxism is a good thing;
     
    -3- He does not really support Black Liberation Theology, or
     
    -4- Black Liberation Theology is a good thing.
     
    If you need to better qualify Marxism or BLT, feel free.
  10. supercat
    At first glance, this kernel may look like any other 24-column text kernel. But there are a few differences. It should probably be suitable for use in a text adventure game (with a nice scrolling output, even on an unexpanded 2600!) though I may have to increase the line spacing slightly for that.
     
    For a variety of reasons, this is not "just another 24-column kernel":
     
    -1- Minimal flicker thanks to a variant of David Crane's "flicker blinds" trick and an anti-flicker font.
     
    -2- Minimal space between rows. Three scan lines, which I could probably maintain even fetching text from multiple banks. In a text adventure game, I'd probably increase paragraph spacing by five scan lines (half normal line spacing) and count everything in half lines.
     
    -3- No HMOVE bars; I think this is the first flicker-blinds program to avoid those.
     
    There's another reason this is most emphatically not "just another 24-column kernel". Can anyone spot it?
  11. supercat
    Magic Zeepy banking is a proposed banking method to allow up to 32 zero-page pointers used within certain parts of the code to access up to 24K of ROM directly. It does put some restrictions on the code to be run, but for some applications the ability to access so much memory directly may be more than worth it. The scheme is designed around using a 22V10 as a controller; this entailed some slight compromises, but the scheme should nonetheless be very powerful. The board layout would have to be different from Albert's current cart, but the assembly procedure would be the same. The Zeepy chip would support up to 64Kbytes of ROM.
     
    The 64K of ROM space is divided into two 32K sections of eight 4K banks. One banking control bit is used to select between the two sections; code running within a section may access data only within that section (code in the first section may access 24K of data in that section; code in the second section gets 24K of data in that section).
     
    The eight banks in a section are selected using a 3-bit "primary bank register" and a 3-bit "temporary bank register".
     
    Any access in the range $1C00-$1FFF will copy the primary bank register to the temporary bank register and use it for the access.
     
    Any access in the range $1000-$1BFF will use the temporary bank register for the access (ignoring the primary bank register).
     
    Any access to $0FnF (or more precisely 011xxnnnn1xxx) will select bank 'n' immediately (loading the section-select bit along with both temporary and primary registers).
     
    Any access to $07nF (or more precisely 001xxxnnn1xxx) will load the primary bank select register with 'n'. This will not actually switch banks until the next access in the $1C00-$1FFF range. This will ease jumps between banks when jump target is in the $1C00-$1FFF range.
     
    When bank 0-3 is selected via the primary register, any access in the range $80-$BF will load the temporary bank register with DATA bits 5-7. This would primarily be useful when performing (zp,y) addressing. In that case, the bank number would get latched with the normally-ignored upper address bits stored in the pointer.
     
    If code is running from address $1C00-$1FFF, the only effect of a change to the temporary bank register will be to affect a memory access that occurrs between the change and the next instruction fetch. Most notably, the data fetched by a "lda (zp),y" or similar instruction.
     
    The net effect of all of this would be to allow 4K of code within each 32K section to access 24K of data within that section with minimal overhead.
     
    Thus, simple code like:

    lda (pf1a),y sta PF1 lda (pf2a),y sta PF2 lda (grp0p),y sta GRP0 lda (pf2b),y sta PF2 lda (pf1b),y sta PF1 lda (grp1p),y sta GRP1
    would be able to access up to 24K of playfield and sprite data without any 'manual' bank switching, and the bank for each pointer could be independently selected.
     
    Any thoughts?
  12. supercat
    Here's a sample of what might be possible under Chimera. There's supposed to be another column of data (8 pixels wide) in the left-side red area, but the timing's not quite right so the sprite doesn't show up on a real system (it does under Z26, but Z26 has other problems; besides, what really matters is what a real machine does).
     
    This demo runs under straight F4 banking; the only practical way to animate stuff on the screen would be to use Chimera to patch over a thousand load-immediate instructions in real-time.
  13. supercat
    Here's my start of what Atari's "Space War" should have been. Everything suffers from 30Hz flicker (oh well) but the players can have get 4 shots on screen. Or maybe I'll go with three shots per player and have two floating fuel pods.
     
    In addition to the "combat-style" two-player game, I was planning to also have a single-player game in which a computer-controlled ship lays down red and green dots. The player is required to collect the green dots while avoiding the red dots or the computer-controlled ship.
     
    The kernel is working, as is the basic accelleration of the players. Shot handling needs a lot of work, and I still have to get gravity working. With luck I'll be able to have gravity affect the shots as well as the players. Should make things interesting.
  14. supercat
    I decided to try out some kernel experimentation to see how well Toyshop Trouble could work on the 7800. Things seem like it could work decently, though the lack of cycle-accurate emulation support would probably make it too difficult to get working. Things could be a bit better if the write mode 2 transparency logic used the upper data bits, but even without that ability it should be pretty nicely workable.
     
    The game would run in 320B mode. Four toys per line, each with two independent colors per scan line. The player character would use two fixed colors (tan and blue) plus one color which would be set on each scan line. The usual annoying transparency restrictions would apply (with 'blue' being the annoying color). The conveyor ends would be yellow and blue.
     
    I don't know that there would be enough interest in 7800 games to make the effort worthwhile, but in 320B mode I would think Toyshop Trouble could look quite nice indeed. Testing reveals that things could be done with the required timings to make everything gorgeous, but unlike the 2600 kernel which ignores the player's X position the 7800 kernel would have to adapt to the player's position and avoid doing any MARIA store while the player was being drawn. It's possible to move the required stores around so that in very case they'll avoid splatting anything they shouldn't, but it would be a nuisance. Unlike the 2600, whose processor clock cycles always line up on the same grid, the 7800 processor clock is not synchronous with the scan line. This can make things rather interesting trying to line things up when the code ends up being 1/2 cycle too short. DMA is added in multiples of 3/4 cycle (all DMA time summed together is then rounded to the nearest half-cycle), so adding one byte to a DMA transfer may add 1/2 or 1 cycle to the scan line.
     
    I may drop back to using 320C mode. I don't think the graphic designs could be as nice, but it would allow the player character to be drawn using four colors at low (160-dot) resolution without having to update the player colors each scan line. The toys wouldn't be as pretty as in 320B, but saving 7 cycles per scan line should make it easier to meet all the applicable timing requirements.
  15. supercat
    Well, I just started playing with 7800 programming and it seems somewhat interesting. Haven't really figured out what to do, though. I've been thinking it might be interesting to see if I can manage a missile defense or area-filling game using only the 4K of internal RAM. The location of the zero-page and stack shadows is nuisancesome, but I have a kernel that seems like it should work for 128x96x4 colors with some cycles left over for a few overlay objects. The bitmap is stored linearly at 32 bytes/row, except for an annoying gap at $2000 to allow for the zero-page and stack shadow areas.
     
    I was also thinking that if I can manage to do some CPLD design it might be interesting to try to push the 7800 to its limits like I did for 4A50. Probably should invest more time and effort in 4A50 first, but I would think that with the right hardware the 7800 might be able to do a pretty decent rendition of a color vector graphics game.
     
    The first key, if possible, would be to use the HALT signal to distinguish CPU cycles from MARIA cycles. 16K of the Maria address space would fetch data from one of four 16K banks; another 16K would access a different one of four 16K banks but assert R/W and drive the data bus low. This would provide a fast means of clearing display memory.
     
    For graphics plotting, I'd tweak things a little bit beyond my 4A50 design. If $1000-$17FF is open, I'd set things up to allow pixel plotting via something like:

    cmp $1000,x; X=x coordinate of pixel cmp $16FF,y; Y=y coordinate of pixel
    The $10xx read would latch bits 3-7 of the address and data bits 0-7 (controlling what's plotted). The $16xx read would fetch data from an address formed by munging the bits 3-7 latched above along with some other address registers and the 8 LSBs of the specified address and then latch data bits 0-7 into a second register. The $17xx read would use the same address as the $16xx read, but perform a write there with the masked contents of the first two reads and a "color" register.
     
    Combining these techniques, I think a color vector game in the style of Tempest could probably run at 20fps in NTSC--possibly even 30--even using a 256x192x4 bitmap screen.
  16. supercat
    Although I'm more interested in 2600 development than 7800 development, I've had an idea for a POKEY alternative for 7800 developers. My intention would be to release an open-source framework that other developers could build upon if desired.
     
    The GADGETT (Great Audio Doesn't Get Easier Than This) would be an 8-pin DIP Cypress microcontroller which would be programmed with a small bootloader and would attach to a few pins on the 7800 bus. The part in question costs $2.50 in quantity 100 and could be added to a 7800 cart with no other components required except a one or two resistors.
     
    I've sketched out the CPU/RAM requirements and would expect the following to be workable:

    Six-voice wave-table synthesizer; each voice would mix two 256-byte wave tables in arbitrary proportion, and both mixers would be controlled by independent envelope generators. Maybe vibrato/pitch envelopes as well--not sure about that one.
    Two digitized waveform channels, with arbitrary playback speed, looping, and event queueing. Wave data could be 4- or 8-bit.
    Probably about 12K of flash available for wave and envelope tables, digitized waveforms, high scores, etc.
    To make something like a piano sound, one could load two waveforms--one for a "bright" piano wave and one for a more mellow wave, and two envelopes--one with a quick decay and one with a slower decay. Attach the first wave to the first envelope and the second to the second envelope. When a note was played it would start with a bright sound and fade into a mellower one.
     
    To produce speech, one would have to store digitized phonemes in memory and then queue up a list of events to play them. Since the player would support looping, vowel sounds would not need to take up huge amounts of space. Alternatively, one could simply store spoken messages although 12K of storage wouldn't be a whole lot for that.
     
    I don't want to go so crazy on the specs that I can't get the thing done, but I don't want to make something so wimpy that it's not worth using. If the micro features a write-protected bootloader, code in the 7800 could pump it with whatever sound generation software and wave tables were desired. I could supply a binary code image for a decent sound generator, but if anyone wanted to write their own they could.
     
    In bootloader mode, one would send/receive a byte of data from the GADGETT using something like the following:

    ; Write the byte in the accumulator; read a byte into the accumulator sta temp asl asl asl asl sta $8000 ; GADGETT latches data on D4 and outputs data through a resistor on D0 lsr $3F ; Or some other unused address ror sta $8000 lsr $3F ror sta $8000 lsr $3F ror sta $8000 lsr $3F ror lsr lsr lsr lsr sta temp2 lda temp sta $8000 lsr $3F ; Or some other unused address ror sta $8000 lsr $3F ror sta $8000 lsr $3F ror sta $8000 lsr $3F ror and #$F0 ora temp2
    A little clunky, but not totally outrageous. Once the music player was started, it would switch to using both D0 and D4 as inputs from the 6502 thus allowing two-byte commands to be transmitted quickly:

    sta $8000 lsr sta $8000 lsr sta $8000 lsr sta $8000 txa sta $8000 lsr sta $8000 lsr sta $8000 lsr sta $8000
    Anyone like the concept?
  17. supercat
    Here's a simple demo of my BTP2 music routine. The routine can produce a full chromatic scale over a five octave range, though the top and bottom octaves don't sound too wonderful (I doubt that the DPC would sound great on the really high or really low notes either).
     
    Each of the four voices can independently play loudly or softly (though in this demo the volumes all tie together). This demo doesn't maintain vsync, though doing so probably wouldn't be too hard. The music player requires 46 cycles per scan line, leaving 30. Not enough to do a wonderful kernel, but enough to do something.
  18. supercat
    BTP2 music sounds even better than expected when I put in some real music. I need to put in some real logic for music handling so I can sustain notes (and not use 16 bytes per beat!) but this clip shows the full five octave range of BTP2 with a recognizable tune.
  19. supercat
    My next little project is called BTP2. I've got the data tables designed, but still need to come up with the code to drive them. It's somewhat related to a recent thread. So now you have to speculate what crazy idea I might be thinking of.
     
    Clues:
    Stereo, 15.75KHz
    46 cycles/scan line
     
    Any guesses?
  20. supercat
    Theresa Marie Schindler (Schiavo) was forced to give up the ghost one year ago today, as a result of 13 days' forced dehydration. The media portrayed the issue as a contest between spousal rights and parental rights, and between a person's expressed will to die and other people's will that the person live. The media are liars.
     
    Although a person's spouse should generally be trusted with that person's care, there are exceptions. While Terri was alive, Michael Schiavo sired two children by his mistress, Jodi Centonze, and openly pledged to marry her. That is undisputed fact. To suggest that a married man who only pledges to marry another woman should have any continuing rights as husband of his legal wife is to make a mockery of marriage. (Note that I'm not suggesting that Michael shouldn't have been allowed to get on with life, but rather that if he wanted another woman he should have divorced his wife).
     
    As for Terri's supposed wish not to live, the only "evidence" of that is the recollection of Michael Schiavo and two of his relatives, first recalled seven years after Terri's collapse, that she supposedly told them that. Supposedly, Terri had conversations with each of those Schiavos singly, and the three conversations were quite different. Judge Greer thought the variety of conversations constituted clear and compelling evidence of the seriousness of Terri's intentions. IMHO, a more rational person would think it more likely that the Schiavos simply invented the conversations out of whole cloth, and made them different so as to avoid any need to corroborate each other.
     
    I could go on and on about what's wrong in this case, but that would probably be rather boring. If anyone's interested, I can discuss more in comments. I would like to mention, though, a song I wrote, arranged, and recorded last year. A Bird in a Barren Cage (adapted from a song by Arthur J. Lamb and Harry von Tilzer, circa 1900). The link points to lyrics, sheet music, and a recording (in low and high bandwidth versions). I'd be curious what people think of my musical efforts. This is my first project using Magix Studio 7, but I think it turned out quite nicely.
  21. supercat
    Introducing 0840 EconoBanking
     
    I've just built a cart using a new low-cost 8K banking scheme. Unlike other 8K designs which either require a programmable logic device or multiple logic chips, this design uses one 16-pin DIP, a 2.2K resistor, and a 100pF cap (and an EPROM of course). The one limitation is that code must be written to use the new banking method--it's not F8-compatible. Writing games to be easily-adaptable to both formats, however, should not be difficult. Any address $0800-$0FFF (or $2800-$2FFF, $4800-$4FFF, etc.) will trigger a switch to the bank specified on A6. Use $0800 to switch one way, and $0FFF to switch the other.

    74x153 or 74x253 . +---------+ . Gnd-----|/G1 VDD|-----VCC . VCSA12--|B /G2|-----Gnd . Gnd-----|1C3 A|-----A11 . Gnd-----|1C2 2C3|--. . VCC-----|1C1 2C2|--+ . VCC-----|1C0 2C1|--|--A6 . /CS-----|1Y 2C0|--+----+--EA12 . Gnd-----|VSS 2Y|----R--+--C--Gnd . +---------+
    I justed tested an 8K version of Hack'Em on this cart and it works great. Asteroids, however, is flaky. That game makes some bogus memory accesses around $48xx-$4FFF. Such accesses are harmless in an F8 cart, but trigger bankswitching on this one. Still, if a game is written to avoid stray memory accesses, it should be easy to adapt it to either F8 or 0840 banking.
     
    Additional Notes
     
    Care should be exercised when using "BIT abs" or "NOP abs" to skip over a two-byte instruction, since those instructions will perform a memory read. For example, using a NOP to skip over "LDA #$08" will cause a read of $08A9, triggering a switch to bank zero. These hazards may be mitigated by ensuring that any code that might trigger a bankswitch is already in the bank that would be selected. For example, any code which skips over an LDA instruction should be in bank zero.
     
    If portability to F8 carts isn't a concern, games that need to access a lot of ROM data within the kernel may switch banks at minimal cost. A switch to bank 0 or 1 may be combined with any TIA access. Additionally, an access to memory $0080-$00BF may be combined with a switch to bank 0, and an access to $00C0-$00FF may be combined with a switch to bank 1. For example:

    ; A copy of this routine should be present, at the same address, in both banks. sta $0800+WSYNC; Wait for sync and switch to bank 0 lda PF0data,x ; Fetches from bank 0 sta $0840+PF0 ; Stores it and switches to bank 1 (4 cycles) lda PF1data,x ; Fetches from bank 1 sta PF1 ; Just store to PF1 (three cycles)--still in bank 1
     
    Not sure there's going to be a lot of need for this sort of trick, but 0840 banking does allow it.
  22. supercat
    I've restarted work on my Matchie game after finding a solution for an annoying TIA quirk. Although the 2600 shows 160 pixels across the screen, SCORE mode can corrupt the color of the last HALF-pixel on the left half of the screen. If the last playfield pixel on the left half of the screen is set, the 77th through 80th pixels should appear in P0 color. Unfortunately, the right half of that playfield pixel will show up in an indeterminate color which may be affected by COLUPF even though the playfield should appear entirely in P0 and P1 colors.
     
    For quite awhile i shelved the game because I couldn't get it to look good on a real 2600. Finally, though, I figured out the solution: display Missile 0 at pixel 79 on any scan line where that playfield pixel is set. Problem solved.
     
    I'm curious, though, does anyone know any other race conditions that can cause Atari 2600 to be "split"?
  23. supercat
    Cory Maye, a man who was on death row for having shot an intruder who happened to be a police officer, has bee moved off death row. I've read some of the trial and hearing transcripts of the case, and it sure seems like some prosecutors are more concerned in convictions than in justice.
     
    At trial, Cory Maye testified that he was awakened by the sound of someone bashing at his door, went to the bedroom, got a pistol, and got down on the floor watching the doorway. When door was breached, Cory Maye feared for his life and that of his daughter, and fired three shots, one of them fatal.
     
    The prosecution called a forensic examiner who determined that the bullet track in the decedent's body was downward at roughly a 20 degree angle. When cross-examined as to whether he knew the decedent's posture, he admitted he didn't know; when further cross-examined as to whether one could determine trajectory without knowing posture, he admitted he could not.
     
    Nonetheless, on redirect, the prosecution asked whether--if the decedent were in standard anatomical position (I think he used the term "anatomically correct position"), the shots could have been fired from beneath. The examiner testified that under those circumstances they could not. In rebuttal argument, the prosecutor slammed Maye's credibility by saying he couldn't have been crouched on the floor as he claims and is therefore lying about everything. Never mind the preposterousness of the decedent assuming standard anatomical position (legs, back, neck, and arms straight vertical; palms forward) before being shot.
     
    In reading through the defense's briefs and arguments, I'm amazed at how many points of varying degrees of relevance have to be covered. To be sure, there's a reason for requiring all of a side's arguments to be presented together, but the clutter it can sometimes obscure some of the more basic ones.
     
    The prosecution's argument in the original case was clearly centered around the use of the examiner's testimony to discredit Cory Maye. The prosecution presented no other evidence that Maye could have been aware that the person breaking into his apartment was a police officer, so discrediting him was essential to their case. If it can be shown that the prosecutor himself lied when challenging Maye's credibility, that should be the end of it. The only way the jury could have convicted Maye would be by finding him not credible; by the prosecutor's own arguments, the most important evidence they should consider in making that determination is the testimony of a forensic examiner (such testimony in fact not really saying what the prosecutor claimed).
     
    It may be awhile before the judge in this case can fully digest everything. At least one thing is clear, though: Cory Maye is off death row at least for awhile. The judge found that Cory Maye's attorney completely failed to provide effective counsel for the sentencing phase of his trial. When she announces before starting it that "It's all the same evidence" and that she really has nothing more to add, it's hard to imagine her more effectively sticking a knife in her client. Scary.
     
    More information may be found at www.theagitator.com (no affiliation).
×
×
  • Create New...