supercat
-
Content Count
7,259 -
Joined
-
Last visited
Posts posted by supercat
-
-
My current wish item for Z26 would be a feature to mark certain addresses that, when accessed, should
-1- Display a half-pixel dot on the screen, [at current scan location]
-2- Start logging
-3- Stop logging
-4- Arm a watchdog [settable value]
-5- Feed the watchdog
-6- Disarm the watchdog
The watchdog should trap when a program goes too long without feeding it. The intended use would be for programs which do processing in vblank/overscan but poll the RIOT to see if they need to redraw the display. If a program is written to have 4 scan lines 'slop' on RIOT polling but a particular application sometimes takes 5 between polling cycles, the display will be fine unless the slow operation occurs at an inopportune time. Having a watchdog would allow such lurking problems to be detected.
Any idea if Stella will include anything like the above features?
-
Each 5 byte header has a pointer to the appropriate byte in the character grid and width=20 bytes. Maria then reads the byte at the pointer position and uses that as the LSB to the bottom of the sprite data, which is stored in ROM. The MSB comes from the Maria CHARBASE register.So if I wanted to use 2K-byte character sets, eight of them would take 16K but I'd only have one register to update per frame; if I wanted to use smaller character sets, I'd have to update 40 display lists? Tough call, since using 2K character sets would not have to be wasteful if other data were interspersed with them. I could imagine Wormy working quite nicely as a 32K cartridge with 16K of that consisting of interleaved screens and characters.
Hrmm, one problem. Each header also contains the palette info, so you'll be limitted to 4 colors for the entire screen. Very CGA. You'll also need to watch out for artifacting. Unless you figure out how to use 320C, then you will have more colors, but less flexibility in using them.Well, Wormy II was a CGA game. If you like I could enclose a copy; it sorta plays on modern machines though it runs too fast [cued off frame rate]. And with artifacting, I think you'd sorta get 16 colors on sorta 320x200 resolution [since different combinations of colors in pixel pairs would yield differnet colors on screen]. Remind me how 320C works?
Anyway, where was I. Oh right, the graphics data in ROM. Okay, since we're using 2 byte characters (8 pixels wide, 4 colors = 2 bits per pixel) you have 128 characters to play with. However, you could change CHARBASE every frame and have multiple character sets. Each character set would be 2K, so with 8 character sets you'll need 16K of graphics data. (Actually, you'll only be using around 48 of the 128 characters, so you could put more than one worm character set into a single 2K block.)But using multiple character sets within a 2K block would entail updating 40 display lists? Not that that'd be impossible, but it would seem more work.
Cool.
-
What? Under Z26Win it sounds like the BoulderDash theme being beaten to death with a sack of accordions. Granted, it's a very old version of Z26Win. Do newer versions handle this mode of sound generation better?Excellent work!There is a switch to synchronize the emulator with the sound generation. I have found that this improves things slightly, but the timing still isn't perfect and the sound is thus still a little off.
One thing you need to realize about emulators is that they don't operate cycle-for-cycle in real time (Windows won't allow that) but they operate fast enough that most things happen within 1/60 second of when they should. This is mostly fine for display updates (though sometimes things flicker when they shouldn't, or don't flicker when they should), and is even okay for 'conventional' audio (if a note is played a little early or late it's usually no big deal) but the timing jitter causes severe problems with sampled audio. That's just the nature of the beast.
-
I wonder if AtariAge could make any money by selling off the bare boards from recycled cartridges. I know many people have all the commons, but some people are missing a few. For $0.50-$1.00 each I might fill in my collection.
-
... that modern 6502s exist and that the instruction set has been filled out with BRA (branch always), BBR0 through BBR7 (branch on bit reset) BBS0 through BBS7 (branch on bit set), RMB0 through RMB7 (reset memory bit) and SMB0 through SMB7 (set memory bit).....Some nice features added, but ADC #immed sometimes takes 3 cycles now instead of two. BTW, I never did understand why there wasn't a 'BIT #immed' instruction. Would have seemed logical.
-
-
Question - are there more than 128 distinct shapes? 'Cause if there aren't then you can simply store the 40x25 character map in RAM.There are 32 characters that are used for animating the worm, of which at most 15 can be on screen at once (12 may be on screen in arbitrary combination, then one head front, one head-body join, and one tail back). There are about 16 other non-animated characters shapes (walls, mines, gold bags, power-ups, etc.). Each of the worm characters has eight variations. The non-animated characters have only one each.
If the MARIA can read graphics from ROM, it would be a simple matter to have eight character sets and simply change the 20 display lists for the rows containing worm segments to change character sets from one frame to the next. Duplicating the non-animated characters would be somewhat wasteful, but not too bad. The other approach would be to copy the animated part of the character set between frames. If I only copy the 240 bytes that are actually needed, this might be workable.
Well, there's one worm [which actually looks more like a centipede] and it's animated along its entire length. I would think 38 8x8 sprites on a scan line in 320B mode would be even more of a bandwidth drain than 40 8x8 tiles.
-
Cool. Means if I ever got by Dodgson cart working again I might be able to do Wormy for the 7800 in 320B mode. BTW, it needs exactly 40 columns, not 41. The game was written for a CGA, and uses simulated 8x8 character drawing (320x200x4 colors) to draw things quickly. Most of the motion in the game is done by manipulating the character set, so if memory allowed it should be possible to make Wormy run nice and zippy. The primary requirement would be recopying the shape data for thirty-two characters each frame. Since the character shapes would be 16 bytes each, that would be 512 bytes. If the code uses a tight loop:
LOOP: LDA CSROM0,X STA CSRAM,X LDA CSROM0+128,X STA CSRAM+128,X LDA CSROM0+256,X STA CSRAM+256,X LDA CSROM0+384,X STA CSRAM+384,X DEX BPL LOOP
That's 41 cycles/loop, times 128 loops. That's 5248 cycles, or 69 scan lines. A little over where I'd like to be, though maybe the top part of the screen could be in lower-color mode. Would the CPU get any time during the displayed part of the frame?
I suppose things could probably be improved slightly if one took advantage of the fact that only 15 of the 32 characters will ever be on screen at once Would be a little more complicated than always copying all 32 characters, but the cycle saviings could be worth it.
Either that, or else can the MARIA get data out of external ROM without copying it to RAM first? If so, that'd be the way to go. There are about 48 character shapes, of which 32 are animated. There are eight character sets, so they'd take up 6144 bytes total. Too much to fit in RAM, but well within the capacity of a ROM.
-
How about a game with a breakout-style paddle at the bottom of the screen, where the goal is to keep the ball airborne? I would think that when running the Boing! demo there are actually a lot of spare CPU cycles per scan line but they're in different places depending upon the ball's X position. Having two or more different versions of the kernel which could be selected based upon whether the spare cycles are nearer the start or end of the scan line might be helpful.
For the most basic breakout-style paddleball game, you wouldn't need to do much during the scan lines since your missles (use both of them, staggered 8 pixels, to make a super paddle) could be prepositioned at the start of a frame. On the other hand, if you wanted any targets for the ball to hit, those would have to be drawn sometime.
-
Well, I have a couple of questions (of course). Firstly, the game Asteroids turns a bit redish before I start a new game and after I die. The same thing happens with Home Run, only it's red throughout the entire game. Is this normal, or is there a problem with my carts? If there's a problem, then, is there some way to fix it?In the interest of preventing screen-burn-in, Atari's games cycle the screen colors when they are not being played. Generally, the color cycling begins immediately (and funky colors are something of a game-over indication). Not sure about why Home Run would be red all the time unless that's just the game's color scheme.
-
If your game crashes before it executes even a single instruction, I would suspect a loading problem. What are you using to transfer your binary to the SC? I think I have experienced a similar problem, if the footer tone after the binary transfer wasn't long enough.I'm using WPLAYBIN. Though I'm thinking I may have to reexamine some of the header to make sure I didn't bump anything. How does the header in the BIN file compare with the headers of the tape blocks?
The SC doesn't count cycles. It counts address changes. The write will go to the fifth different address after the access to $F0xx, but only if this address is in the ROM area and if writing is enabled. Writes to the control byte at $FFF8 will alway happen immediately. There is no address counting or RAM enable for this.Counting address changes. Interesting. Does it look at the entire address (well A0-A12) when making the determination, so the sequence:
Foo: LDA $F0xx,x NOP LDA MyAddress
is guaranteed to work for any value of MyAddress other than Foo+6 or Foo+7 [either of which would cause a write to address Foo+8]?
If they're counting address changes, I wonder why they need the write pulse delay to be programmable? I would have guessed that they needed that to get suitable timing accuracy over a several-cycle period, but accuray within a single cycle shouldn't have been a problem.
I wonder why that other document says the SC writes are based on cycles?
-
This is the document that I used to plan my overall deisgn for timing. Its not perfect, but I am told that its pretty close to the VCS. I cant comfirm any of the values, as the only testing equipment I have had access to in a long while is my multimeter with a really bad frequency counter.Well, someone just pointed me to something that makes this a little trickier than I'd thought. It's absolutely imperative that the cartridge be able to support two back-to-back "write" cycles to the same address, or else the three most popular addressing modes won't work. So the self-oscillating behavior I'd thought was a 'bug' is really a feature, though it does have to be tuned precisely. This is probably why Starpath used the funny write method they did--it eliminates these problems.
-
I need to find 4 620 Ohm 1/4 W resistors for Bookpile who is doing a mod for me.What precision? Could you use a 560+47 [total 607 nominal] or 560+75 [635 nominal], 470+150 [620 nominal], 330+300 [630 nominal], 390+220 [610 nominal], or some other such combination?
-
I'm working on a 1K minigame for the Supercharger and am having a couple problems. Perhaps someone else who's dealt with the thing can offer some advice.
-1- The program starts fine in emulation. On a real unit, however, it dies about 2/3 of the time on startup. My code turns on an audio beep before it does anything else, and the times that it dies (black screen) it does not beep, suggesting that it's dying before it starts executing my code. Is there a potential issue with the header information and such (which I don't really understand but just copied out of Stella-Sketch)?
-2- My understanding of the Supercharger was that the first memory access over address $F000 that occurred at least four but no more than six cycles following an access to $F000-$F0FF would trigger a memory write. This would suggest that the sequence:
lda $F0E7 lda $F123
would store $E7 into address $F123. This doesn't seem to work in Z26, though. It does work if I use:
lda $F0E7 nop lda $F123
but that doesn't really seem right, since the address fetch for the last instruction will take place on the fifth cycle following the trigger access; it would seem that this should trigger a write on the address fetch, rather than on the following data fetch.
My code currently uses (ZP),Y for all the accesses and that seems to work, but it's a real pain in the tusch. What is supposed to work there?
-
The Atari 2600 and 7800 both use 228 chroma clocks/line, IIRC. The Nintendo uses 227.5. A consequence of this is that on the former systems chroma artifacts stay in the same place every line and every frame, while on the latter system the chroma artifacts alternate lines and frames. This improves the graphic output considerably except when the screen is scrolling at a rate of exactly one pixel per frame, and even then it's still probably better in most ways than the 7800.
I would expect that a game which took advantage of artifacting might manage to produce better graphics than one which didn't, but I don't know of any 7800 games that do. Does anyone else know?
Also, it's been ages since I read the 7800 specs. Can the Maria clock out enough data to put up a full screen of 4-color 8-pixel wide tiles in 320 mode if there are no other sprites that need to be drawn?
-
It sucks that the Bobby proto seems to have bitrotted. If it is indeed bitrot, and not a problem somewhere else on the EPROM or board (like the problems Tempest is having with his Meltdown), then the contents of that particular cart are more than likely lost forever (although depending on the damage, it may or may not be possible to reconstruct what's there, but if it's not a final release binary, then it'll be much harder to do).If it's a marginal case of bitrot, reading the device out with different VDD levels may be able to help.
-
"LDA WSYNC" will take three cycles, regardless of when in the scan line it occurs. The MSB of the accumulator will indicate whether a collision occurred between player 0 and the playfield; bit 6 will indicate whether a collision occurred between player 0 and the ball. Bits 0-5 will most likely be "00 0010".
-
I can't think of anything better than a classic 12ga shotgun with a 3.5" magnum turkey load and a full choke. And a 12ga is a pretty common skeet gun (even though most units used for skeet shooting have 2.75" or 3" chambers).
-
Remove the cartridge and the bonus 20.06 from the box.What's a 20.06? Is it just a smidge smaller than a 20ga?
I certainly would not advise firing a 30-06 at any airborne target unless you are in the middle of open ocean. A 30-06 bullet can travel for miles (it's not accurate out that far, but it could still hit someone).
-
Graphics are fairly simplistic, as with most Odyssey2 games. As for sprites, I'm not sure on the technical part of it, but it can display far more than 4 object on the screen with no flicker at all (that's one thing I've always like about the O2). Chess displays the whole board, with somewhat unique graphics for the pieces.The O2 hardware is designed to display four sprites that can be any shape, twelve objects whose shapes are predefined (letters, numbers, the walking man, etc.), and four groups of four horizontally-arranged objects each whose object shapes are likewise predefined.
My guess from your description would be that the O2 is using some tricks to form the chessmen out of 'pieces' of the predefined shapes. Sorta clever if that's what they're doing. Any possibility of a screenshot?
-
It requires a lot of searching for an application to find its data,Not a lot. Simple loop. The memory is quite small, searching is fast - it happens in the blink of an eye.
How many pages per frame can you read headers from while showing a display? Obviously if you screen-blank you can read stuff much faster, but screen blanking is ugly.
ID bytes are a bad move since they are not human readable. A list of IDs needs to be maintained and it's more finite than what we already have. To make them human readable, any application which shows the directory would need to know the meaning of all IDs. What happens when new IDs are added? Does everyone have to send their memory manager cart or games back to be updated?That's why I'd suggested that the first part of the flashcart memory contain the name of each game. This would allow a lookup based on application ID.
Linked lists are bad because they are corruptable and can break the file system.How are files over 117 bytes handled?
BTW, What are the RAM requirements of your proposed system? This is something that is critical to those who are already working on projects which use the file system.Not much. Whatever scratchpad is needed by the I2C routines, plus a 2-3 bytes, and maybe 4-6 bytes of stack (all but 2 of which could safely be used by the display kernel).
How does the memory get formatted for use in the first place? The existing system does not require any formatting. A blank EEPROM (full of 1s) will just show all blocks empty.Fair advantage.
This shouldn't happen. Any program that uses the file system should be able to save data to any block, whether previously used or not. Simple.Well, then you need a way to let users decide what they want to delete.
Any of those concepts seem interesting?To be frank, no, sorry. I fail to see how it cures any problems, but it creates new ones.
You may be right. I sometimes have good ideas and sometimes bad ones. Only way to know is to put 'em out and see what happens.
Search the Stella archives for "AtariVox EEPROM File Format" to see some of the talk about this.I'll look into that. Thanks.
-
I think I figured out a good single-comparator-based solution if it's acceptable to have /WE go low 355ns after address stabilization and high 684ns after address stabilization. It assumes that the PLD will switch cleanly to VDD, and that 4.0 volts (0.8VDD) will be a valid high for the /WE signal, but I think those are pretty save assumptions. Adding another resistor would allow /WE to be pulled higher, but would require refiguring all the other resitors.
The PLD generates a signal which is low except when an address looks interesting and the /WE output from the compator is high; when both of those conditions apply, it should be driven high. This signal goes through a 223 ohm resistor to a 1nF cap on the non-inverting input of the comparator.
The other input of the comparator connects via 1K resistor to ground, 249 resistor to VDD, and a 57.6 resistor to the output. The output of the comparator connects to /WE on the RAM chip and to a feedback input on the PLD.
Normally, the cap will sit at ground. When an address is interesting, PLD will output a high and the cap will take 355ns to charge to 4.003 volts. At that time, the output of the comparator will switch to ground. The PLD will then start outputting a low, causing the cap to discharge until it reaches 0.897 volts. At this time, the comparator will again float its output (allowing it to be quickly pulled back up to 4.003 volts). The PLD's output will also go high again at this point, but since the cap would take another 311ns to charge to 4 volts and the memory cycle will end before that, this will not pose a problem.
-
You're absolutely right about the "blippiness" - that's unfortunately a necessary evil to overcome some very badly sounding interference that would otherwise arise between the two channels. Believe me, you don't want to hear it!Can you throw on an amplitude envelope to make it sound 'dingy' or 'hooty' instead?
Adding an amplitude envelope or modulation can help mask some of the objectionable out-of-tune-ness. To be sure, the masking only stretches so far and some of the 2600's notes are truly horrible clinkers. But amplitude shaping and percussion can help a lot.
-
I meant $5 over the cost of a non-SRAM bankswitched cart. I don't think $5 total would be plausible in any reasonable quantity.That would eliminate the cost of the PCB then, which would help a lot. I would say you could get really close.
My thinking is that if RAM-plus carts cost $30 in the Atari store, people may still buy them. If they cost over $40, many fewer people will. Since the Atari Store can sell their current carts for $20, I would figure the extra cost for the RAM-plus cart shouldn't be much over $5 if the Atari Store is going to sell them for $30 and make a profit.
This is true; I also tied my chip enable low. The problem isnt whether the SRAM will function correctly, its mis-triggering a bankswitch. With todays really really fast logic (compared to yesteryear), a switch could be trigger during address stabilization. I know that, until I put in a small delay after recognizing a bankswitch, every now and then the game froze up. To be honest I dont know what the real problem was, I do know it went away when I added about a 136ns (2 ticks) delay after a bankswitch address was seen (14.7456MHz clock gives me about a 68ns per tick). The timing on this wasnt super critical, any delay worked.If one is trying to do a bank-switch on a read cycle that's supposed to return valid data (as in $F8 bankswitching), timing is apt to be tricky because one needs to do the bank switch soon enough that the EPROM can respond to it and output the new data in time. For the bank-switch methods I'm using, the timing is not so critical, and so I'm using the /WE timing logic for the bank-switching. Since /WE has no effect if the RAM is deselected, and since the rising edge of /WE occurs (must occur) when address and data are both stable, this should provide a good timing point for doing the bank switch.
The only timing constraints I'm aware of are (1) address must be stable before the falling edge of (WE | CE) and must remain stable until after the rising edge; (2) data need not be stable before the falling edge but must be stable before the rising edge.The problem is that the address stabilizes happens way before the data. Like I mentioned above, 2 ticks (136ns) for bankswitch delay, but I had 7 ticks (about 476ns) for my falling edge of WE and 1 tick (68ns) for WE return. SRAM timing was tight.
Is it really that tight? If data is stable 556ns after addresses become stable, I would think you should have about a 250ns window for /WE to go high (assuming 30ns for address stabilization). If the target time is set to 675ns, that would allow for +/- 18% on the timing.
The problem with RC timing, as I am sure your aware, is not obtaining an accurate clock, its obtaining a repeatable consistently accurate clock. RC timing relies heavily on environmental factors. I am sure you could get it to work, I have no doubt. The problem I see is in production. You may need to add a pot to help with timing qualifications and will it hold enough after reaching a new unknown environment?Good point. I'm thinking that I should probably add an 8-pin analog comparator to the timing circuit so as to yield something less touchy. I've come up with a 1-comparator, 5-resistor, 1-cap solution which should work if there are never two 'interesting' accesses back to back (and I can't think of any reason there would be). Oddly, all of the two-comparator solutions I can come up with use more resistors.
What board house do you recommend? Also, I wonder if it's best to try to come up with a good mechanical fit on the first proto, or space things out more and simply try to get the circuit working? Since the proto houses I know of charge more $$$ for non-rectangular boards, I was thinking of making a board that's 1.2" by over-long. Would look a little goofy, but it'd avoid having to get the thing cut to fit the cartridge slot.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Atari 2600 BASIC compiler is here!
in batari Basic
Posted
How about having an 8K mode which puts the video kernel and graphics in one bank and everything else in the other? That wouldn't necessarily be the optimal division, but it should be pretty simple to do seamlessly.