supercat
-
Content Count
7,259 -
Joined
-
Last visited
Posts posted by supercat
-
-
Well, most of the games for the O2 were pretty feeble, but there were a few real gems out there. I think my personal favorite is Killer Bees, but other great ones include UFO and Pick Axe Pete (I forget exactly how one plays PAP, but if you can find some instructions that would probably greatly enhance your enjoyment of the game.
-
No more than $5 or so cost over a 32K cart would be my guess, but I don't know the market situation.
-
I like the idea, and I would be inclined to use such a cart. If you're serious about this, though, I'd whip out a quick prototype and finalize the actual bankswitching/ram access scheme well before a final product is released and document it so emulator authors have time to implement the schemes into the emulators ahead of time (as was done with other schemes yet to see a cart release, e.g. EF, and should be done soon for 3E with any luck.)It'd be good to have emulators support it, that's for sure. And it'd probably be good also if the makers of the KC/CC could support it. But before I invest $100 or so in a proto (along with hours building it), I'd want to make sure there'd be some usefulness.
Note that my goal here is *NOT* to produce something like the KC/CC, but rather to produce something that would be cheap enough that the AA store could burn in Wormy III (once it's coded) and sell it as a Wormy III cart (assuming the game turns out to be any good).
-
Thanks for the information. The 2600 is clearly superior in terms of its playfield support (40 pixels wide), color output, and audio. The Odyssey has more independently-movable objects, however. The Atari's ability to 'clone' objects means that even without 'tricks' it can support a grid of 36 space invaders while the Odyssey cannot, but the Odyssey can let objects move without restriction, while the Atari is limitted to two freely-movable custom-shaped objects per scan line.
If one views the Atari's abilities only as being those which Atari programmers demonstrated prior to Activision's appearance on the scene, I think the Odyssey fares quite decently in the comparison. The only real places the O2 would fall flat would be in the playfield graphics and in the support for a large grid of enemies (e.g. Space Invaders). If Adventure were coded on the O2, the mazes would be different but there could be up to four shaped objects on screen without flicker (as opposed to two) and not all objects would count against that (the player and the sword could be "character" objects instead of sprites).
The real downfall of the Odyssey is not the hardware, but rather the quality of programming. The best games on the O2 are entirely beyond the abilities of the 2600. Of course, the best games of the 2600 are entirely beyond the abilities of the 2600. The biggest problem with the O2 is that developers have generally failed to push it to its potential.
BTW, do you have any idea how "Killer Bees" is implemented? I'd think the player and enemy swarms are sprites, but what are the beebops and tombstones? Does the program do something tricky to use parts of different built-in character shapes to form them?
-
The O2 is in some ways technically superior to the Atari 2600, but it never had the benefit of third-party support. From what I understand, the O2's display design is based upon the notion that the processor sets up a display during the vertical blank and then lets the display chip draw it. This is distinct from the 2600 where the CPU is responsible for generating the display "on the fly". The O2 display chip allows much more powerful graphics than anything Atari seemed to have in mind when they designed the 2600, but because the latter is designed around (in fact relies upon) on-the-fly display modifications, it can do things the O2 generally can't.
I would be curious to see technical docs for the 2600 if anyone knows of any. I think the video chip was an off-the-shelf Intel part, but even in ancient data books I've never found it.
-
I owned QftR way back when (still have the cart probably but the pieces are long gone) and found the board-game part a real disappointment. Did anyone actually play the board-game part and enjoy it?
-
Well, I hope all goes well. Your game seems pretty good though I wonder why Z26 goes to the high score screen at the end of the game (but then never saves scores). Is the game getting faked out into thinking there's an Atarivox installed?
I'd really like to see this game go forward--it's really cool.
-
Here comes the public beta version of Crazy Balloon!I didn't like the title music at first, but it sorta grew on me. I do wish the Atari allowed things to be better in tune, but wotcher gonna do?
The tunes for level-advance and game-over seem rather wimpy compared to the title music. If you have space, fleshing them out a little more might be nice.
-
Right. Even if someone has an original idea from which they'll want to produce a 2600 game, it will often be far less frustrating to produce the game on some other platform first, get everything working so the game is fun to play, and then port it to the 2600. If a game isn't going to be any fun, it's best to find that out after spending a few hours coding it for an 'easy' system rather than spending two weeks coding it for the 2600. And if a game concept will need reworking, it's best to discover that before coding, especially if the rework would entail a major code overhaul (e.g. when writing kernels, one often has to choose restrictions to enforce on a game to make the kernel workable such as confining objects to certain parts of the screen; if play testing shows that such a restriction makes a game boring, it may be necessary to rewrite the kernel from scratch to eliminate it. Far better to make such discoveries before time is wasted on a no-good kernel.
-
One thing I'd like to see for the 2600 but haven't would be an inexpensive RAM-plus cartridge that could be used to produce saleable games. To be sure, the SuperCharger and Cuttle Cart are excellent devices which supply lots of RAM, but I can't realistically imagine someone taking a Cuttle Cart, slapping a game label on it, and selling it as a 'dedicated' game cartridge (i.e. a cartridge which is designed to simply play a single game).
I've sketched out a design and I think it should be possible to construct an inexpensive three-chip cartridge which would offer the following features:
- 32K of ROM, in eight 4K banks
- 2K of RAM, in eight 256-byte pages
- Self-programming, assuming presence of a flash chip and boot loader
- Three jumper-selectable configurations
The heart of the design would be a 22V10 or similar device.
Twelve inputs:2 timing feedback [wired with RC delays from a timing-control output]
3 A0-A2
5 A8-A12
2 mode-select jumpers
Ten outputs:
1 timing-control output
2 chip-selects
1 write-enable
3 flash A12-A14
3 RAM A8-A10
The timing-control output would go high when any of the following conditions occurred:
-1- Address of the form 0 1xxx xxxx xxxx is present on the bus
-2- Address of the form 1 0001 xxxx xxxx is present on the bus and selected RAM bank is not 111 (uses 3 minterms)
-3- Address of the form 1 0001 xxxx xxxx is present on the bus and mode-select 1 is high
-4- Address of the form 1 xxxx xxxx xxxx is present on the bus, RAM bank is 110, mode select 1 is high, and mode select 2 is high.
The RAM chip-select would go low when an address of the form 1 000x xxxx xxxx is present on the bus and either the RAM bank is not 11x or mode-select 2 is low and mode-select 1 is high, or RAM bank is not xx1 and mode select 2 is low.
The flash chip-select would go low when an address of the form 1 qqqx xxxx xxxx is present on the bus (with qqq not equal 000), or when an address of the form 1 xxxx xxxx xxxx is present, and either RAM bank is 111 and mode select 2 is high, or RAM bank is 11x, mode select 1 is high, and mode select 2 is high.
The write-enable signal would go low when either of the following conditions occurs:
-1- Address of the form 1 0001 xxxx xxxx is present on the bus and first timing-control input is set but not the second.
-2- Address of the form 1 xxxx xxxx xxxx is present on the bus, RAM bank is 110, mode select 1 is high, and mode select 2 is low.
The flash address lines would be latched on the rising edge of the first timing-control input if the address was of the form 0 1001 xxxx xqqq [latch value qqq].
The RAM address lines would be latched on the rising edge of the first timing-control input if the address was of the form 0 1010 xxxx xqqq [latch value qqq].
An asynchronous reset for the flash and RAM addresses should be generated while mode select input 1 and 2 are both low.
The mode-select inputs should be wired with RC delays so that they will both be low for a few miliseconds on initial power-up and will then be pulled up if jumpers are absent. Modes:
-01- (first jumper only): Setting the RAM page address to 7 would deselect the RAM from the address space, making the flash available there.
-10- (second jumper only): RAM page 7 works like any other RAM page; the first 512 bytes of each flash block are inaccessible.
-11- (neither jumper): RAM page 7 deselects the RAM and makes flash available; requesting RAM page 6 deselects RAM and turns all flash accesses into writes.
In addition, there should be a jumper for disconnecting the 22V10's write-enable output from the Flash's write-enable control pin (which should be pulled up).
Anyone think such a thing seems feasible and interesting?
- 32K of ROM, in eight 4K banks
-
In order to program the flash, a microcontroller needs access to the full ACART.If one starts with a flash that contains a boot loader, does one even need a separate microcontroller? I would think the Atari should be able to program itself (a routine to program a 64-byte block of flash would be copied into RIOT RAM and run from there). One wouldn't have niceties like a hardware UART and would thus likely be limitted to 19200-N-8-2 or maybe 38400-N-8-2, but that shouldn't be a problem.
Right now I'm working on sketching out an as-cheap-as-possible design for a RAM+flash cart intended to be a platform for SALEABLE games by homebrew developers. The goal is to use one RAM, one flash, a 22V10, some resistors, and some caps. In the cheapest configuration I could envision, the cart would support 32K flash and 1.75K of RAM and would have two jumpers. With both jumpers installed, the cart could be programmed by a bootloader; with them removed, the cart would be write-protected. There would be one bank-switching method available which does not AFAIK match any other known method (though if someone could direct me to something close that might be useful).
Adding a few more jumpers would allow the use of larger RAM, though with some loss of ability to control RAM and flash addresses separately. I don't know what different programmers would want to do, so leaving such options open might be desirable.
Flash would be divided into eight 4K blocks. Removing a jumper would force A14 high, mirroring the bottom four into the top four and allowing more easily the use of more RAM with 16K or smaller programs.
In minimal configuration, RAM would be divided into eight 256-byte page, accessed at $1000-$11FF in Superchip fashion. Depending upon the status of a jumper, selecting RAM page 0 would disable the RAM and make the flash available there.
For applications requiring more RAM, jumpers would allow upper-order address banking bits from the flash to be directed to the RAM chip, allowing up to a total of 16K RAM, but with restrictions on access.
If the bootloader jumper was installed, selecting a RAM bank 4-7 would cause all accesses in the $1000-$1FFF range to be interpreted as flash writes. The bootloader would have to copy a small routine into ZP RAM, switch RAM banks (turning on write mode), do any necessary writes, switch RAM banks back, and return to running from flash.
Bank switching would be keyed on reads or writes to selected addresses in the range $0400-$0F7F. Note that Stella and/or RIOT would be mirrored here, but the addresses could be chosen that would have no effect. Note that address bits 2-7 would not be decoded but are assumed below to be '0'.
Address %0 010a **** **bc - Select RAM page abc
Address %0 1abc **** **de -- Sets flash block bits XYZ thus:
X=dX+a; Y=dY+b; Z=eY+c.
Note that it's possible to manipulate either the first two or the last bit of the flash block address without affecting the rest. This should allow for easy sharing of the register between RAM and flash addressing.
Anyone know of any bank-switching methods that are remotely similar (that would already be supported in emulators, CC, KC, etc.)?
-
-
'2600 Boulder Dash ® uses a slightly different technique, but along the same lines -- distributing complex calculations into the available calculating time in the 'vertical blank intervals'. In fact, these are the intervals where we are waiting for the timer to reach 0. Your method employs continuous checks. Boulder Dash ® uses a rough approximation (but always high) of the amount of time a particular bit of code will take (in TIM64T units) and pre-checks if there is enough time left on INTIM before proceeding with doing that bit of code.Interesting. I can see that could offer a performance benefit over doing constant checks. If the code is broken up into pieces of about 64 cycles each, that benefit would amount to about 8%. Possibly worthwhile for programming wizards trying to eke out every possible bit of speed in a processor-intensive game, but not so import for mere mortals merely trying to avoid losing vsync while recalculating information for the start of a new level, etc. (users won't care if it takes 5 frames or 10 frames to place all the obstacles in a new level, but losing vsync is ugly).
-
I'm not sure about the VIC-20, but I know that the C64 clock relationships have been documented as based upon the dot clock, since that's what the VIC-II handles, and the VIC-II pretty much drives the rest of the system. Quote from the aforementioned "VIC article", in the "important signals" section:The dot clock is derived using a PLL which operates as a frequency multiplier to boost the colorburst-based frequency to 8181817Hz. IIRC, it multiplies a 1438180Mhz (common crystal, 3579545*4) signal by 4/7.
BTW, I believe Atari 8-bit computers just use a 1438180Mhz clock divided by two for the pixel clock, which gives them somewhat wider pixels than the C64. This results in somewhat slower processing, and also a wider screen display. This is why the Atari defaults to only using the center 38 columns with its BASIC cartridge.
-
Whilst that is possible, it's not entirely straighforward. Working out a signalling scheme for the switching that doesn't interfere with or get masked by the SpeakJet and I2C signals is trickier than it might seem at first. Plus it adds complexity to the hardware (and software) which increases the development time and cost of the unit.If the goal is to simply share I2C and a joystick, I would offer an easy approach using two NFETs and a resistor. Wire the I2C pins to the left and right joystick inputs. In-line with the joystick itself, wire something like this on the left and right joystick signals [the paddle pin and resistor can be shared for both]
Joystick/I2C ----, | | +5 ----------. | | | R | | D Paddle ------+--G S | | `----- From joystick
During most code, the joysticks would work exactly as they normally would since the paddle input would charge to +5 and stay there. When it's necessary to access the I2C, discharge the paddle inputs and the joystick will be momentarily disabled allowing unfettered I2C access.
Note that it would probably be possible to switch the joystick's ground pin instead of switching the left/right inputs, but that could cause problems with I2C communication if the cable wasn't well shielded.
The biggest problem I could see with this approach would be that emulators might think the game used paddles.
-
The layout I'd personally recommend though is starting the Kernel code right after the first ORG F000:ORG $F000 DoKernel Kernel ; Kernel Code here JMP Overscan ... ORG FFFC .word CartridgeEntry
That way, with your kernel code being on top of the ROM space, it does not get shifted around, thus it's safe from all timing issues like crossing pages.
I put my sprite data at $F000, padded out to a multiple of 256 bytes, but arranging for the kernel to be page-aligned is definitely a good idea.
I personally prefer to JSR the kernel, though, at least for the programs I've written where one sometimes has to do calculations that don't really fit between display and VSync. I'm currently reworking one of my programs to try to increase the time available for calculation; I haven't figured out how best to handle the frame counting, but the basic concept is:
Kernel: bit INTIM bpl Kernel1 Kernel1: stx xsave inc fct lda fct kwt2: bit INTIM bmi kwt2 sta WSYNC lsr bcs mainframe lda #$42 sta VSYNC sta WSYNC sta WSYNC lda #[whatever] sta INTIM64 [forget the name] lda fct clc adc #1 and #$7F sta fct sta WSYNC lda #$00 sta VSYNC ldx xsave rts mainframe: ; Main display kernel goes here (nine cycles after the last WSYNC) ... lda #[whatever] sta INTIM64 ldx xsave rts maincode: ; Periodically, in a time-consuming loop: bit INTIM bpl $+5 jsr Kernel1 ; A and Y trashed; X preserved ; BPL target is here
This would allow user code to execute during both vertical blanking intervals. The values loaded into INTIM64 would have to be chosen so that the timer would expire about 150-200 cycles BEFORE the target horizontal blank. The user code would then have to ensure that it checked INTIM every 100 cycles or so [with a 3, 4, 5, or 6 cycle penalty each time it did so depending upon method]. It would be possible to save code space at the expense of time by making the kernel return if INTIM was not yet negative and calling it unconditionally. The extra 12 cycles overhead would seem unduly severe, however.
-
Different vintages of Commodore 64/128 had different numbers of characters per scan line.
My first machine had 262 scan lines of 64 cycles each.
The replacement VIC-II chip had 262 scan lines of 65 cycles each.
My Commodore 128 had 263 scan lines of 65 cycles each.
The processor clock was synchronized with the character clock at precisely 3.579545/3.5 MHz. This is, interestingly, 16% slower than the Atari 2600's 3.579545/3 MHz.
I don't know what the derivation of the VIC-20's clock was, though character clocks might have been 3.579545/7 and thus processor clocks 3.579545/3.5. Anyone know?
-
If you really want to see what the 2600 can do with donkey kong, takea look at my mock ups which inspired lost monkey to make a very rough
proof of concept rom just to show i wasn't smoking wacky weed :-)
You're smoking wacky weed if you think the 2600 can do that. Generally, every scan line must be made up of the following items:
- The playfield (background), which is 40 quad-width pixels wide, consisting of two colors (background and foreground). Use of more than two colors is possible, but will generally limit what else can be done.
- Two player sprites, which are eight pixels wide and one color each. These may be shown at single, double, or quad width; if single-width, up to three copies may be placed at intervals of precisely 16 or 32 pixels [two copies may be placed 64 pixels apart by using wide spacing with the middle one missing]. The three copies may be different shapes OR different colors, but must generally share one or other attribute.
- Two missle sprites, which are 1, 2, 4, or 8 pixel wide [selectable] solid strips. Multiple copies will be drawn if and only if the corresponding sprites are also shown multiply. The missles must be the same colors as their corresponding player sprites.
- The ball, which is a 1, 2, 4, or 8 pixel wide strip the same color as the playfield foreground.
Those are all the things you get. In a few cases, it may be possible to go beyond these restrictions slightly with very tricky coding techniques (e.g. Galaxian shows 7 copies per scan line of one of the player sprites) but they'd be a good starting point for any display-design mockup. Moving a sprite by more than 7 pixels between scan lines generally requires that there be a scan line on which the sprite does not appear. Further, it is generally not possible to move two or more sprites independently on the same scan line (if two sprites are moved in fixed relationship with each other, that can often be done on one line).
-
Bingo. If the balloon itself hits the wall, showing balloon-only for a frame won't cause any visual disruption, since the balloon-pop animation has no string anyway. And if the string hits the wall, showing balloon-only for a frame is a the right thing to do. So either way, show balloon only.
Indeed, as I indicated, if you simply make it so that a collision causes you to switch to balloon only and start animating upward (but with the first frame drawn precisely where the previous frame had been) you shouldn't really have to worry about whether the balloon or string had the first collision since in either case the sequence:
-1- Switch to balloon only
-2- When balloon collides with anything, pop it
-3- Disable user control and make ballon move upward each frame.
should work fine. Note with #3 that if the balloon is being blown sideways, that may as well continue (with the balloon blowing diagonally). If the balloon drifts to the exit, I'd suggest having it drive sideways until it hits something.
-
Although the 7800 supports modes with 1 or 2 bits per small pixel, or 2 or 4 bits per large pixel, the ordering of the bits is different in the different modes. Consequently, the only way to show big sprites is to have data which is sized appropriately. If you're doing a Pac-man intermission, though, this is not a bad thing--a larger "smooth" sprite would be nicer than a blocky magnified one anyway.
-
1
-
-
I once borrowed the cartridge with no instructions (before the days of the net). I thought the graphics were neat, but couldn't really figure out what the "game" was supposed to be. So far as I could tell, one person selected someplace to hide and the other player had to search arbitrarily until he tried the place the first person chose, with no particular clues to go by. Was I missing anything?
-
There were some very good games for the VIC-20 (e.g. Rally X [mangled into Radar Rat Race], Omega Race, and Jelly Monsters [mangled into Cosmic Cruncher?]), but it really wasn't all that great as a gaming platform. The video controller had no sprite capability whatsoever, and the screen thus consisted of a (typically) 22x23 grid of character boxes. Each box would contain either an 8x8 matrix of pixels that were either a foreground color (one of eight, chosen per-character) or a background color (one of sixteen chosen for the whole screen), or else a 4x8 matrix of double-wide pixels chosen from foreground color (1 of 8, per-character), border color (1 of 8, screen-wide), background color (1 of 16, screen-wide), and "auxilliary color" (1 of 16, screen-wide).
Most games performed all action in per-character increments. In Snakman, for example, the pac-creature and ghosts both moved in 8-pixel increments. Although some games worked fine with such constraints (e.g. Rally X) it generally made Vic-20 games "clunky". A few VIC-20 games used tricks to allow smooth motion, but the color restrictions often resulted in color bleeding which was impossible to eliminate [e.g. in Jelly Monsters, dots near the pac-man or ghosts would turn the color of the pac-man or ghosts in question].
The VIC-20 could certainly do many things the Atari 2600 could not; many things that were trivial on the VIC would be impossible on the 2600 (unless one was willing to accept an insane amount of flicker). On the other hand, the Atari could also do many things the VIC could not. Pitfall is not a terribly tricky cartridge from a graphics perspective, but it would be beyond the abilities of the VIC-20 to do a really good port. A few cartridges manage to use interesting tricks to work around the VIC's limitations (e.g. Demon Attack) but the approaches used there are pretty limitted.
-
The READY line on the 6507 freezes the processor in the middle of read cycles (only). For purposes of doing a STA WSYNC, this doesn't really matter since the next bus operation following the write to WSYNC is almost always going to be an instruction fetch (i.e. read). If one were to do something goofy like point the stack pointer at WSYNC and do a BRK, the three write cycles would happen immediately, regardless of the state of the horizontal sync, but unless one is trying to seriously torture-test an emulator I'd not consider that an issue.
For the MARIA chip, however, it's necessary to stop the processor BETWEEN bus cycles, and to delay both read and write cycles. Thus, it's necessary to have a HALT wire on the processor which behaves differently from the READY line.
-
What's the best resource for finding a list of such opcodes, DASM's preferred mnemonics for them, and any side-effects or weirdnesses?
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Crazy Balloon Public Relase
in Atari 2600
Posted
How about loading HMP1 every three scan lines with a value defined by the level data? This should allow you to create a magnet that's shaped like the horseshoe magnets used in grade school science classes.
Also, any possibility of colorizing the string or going with the two-part popping sequence I mentioned earlier?