EricBall
-
Content Count
2,362 -
Joined
-
Last visited
Posts posted by EricBall
-
-
I don't know if there are enough new titles to subdivide ports from new designs, and, thinking about it, it would be hard to say, for instance, which one Leprechaun would fall under (when it you finish, Eric!).I'd prefer that you don't consider Leprechaun since it's still a work in progress. Next year, after I've lost the SuperCharger contest to PoP.
-
It all depends on why you are collecting the games. Obviously, if you want to play your colllection (using the cart, versus emulator or RAM cart) you are either going to have to open them or buy a duplicate.
If you are collecting them so you can say you have a complete collection, then you need to weigh the value having it sealed versus being able to play it.
If you are collecting as an "investment" and plan on selling your collection at some point, leave 'em sealed (especially if you can prove it's the original factory wrapping). There are people who will pay extra for that kind of thing.
-
Actually, I did have a look at it (although I had to find it on your website since the link was broken). Unfortunately, it didn't fit the requirements anymore. (You are mentioned in a source comment though.)
-
The player can stop, but only while "on grid", which will always be the first frame of the animation. (The player can, however, reverse direction "off grid".)
-
Suggestions are good. Samples are better.
-
Give it a shot! If I get more than one result, I'll do different ones for the player and the enemies.
-
4 sets of animation - running, swinging (rope 2nd row of pixels from top), climbing and digging/zapping (creates a hole in the ground). Each animation is 4 frames. (Left / Right will be handled via hardware or manual mirroring.)
Single color 8x8 pixel sprites; 5:3 pixel aspect ratio (2:1 is a reasonable approximation). However, the sprite (other than digging) should mostly stick to the middle 4 pixels in each row since that is the size of the background grid. Moving sprites move at a rate of 1 pixel per frame.
The digging sprites may use the entire 8 pixel width, although they will span two columns of the background grid. (So half is the current position, and the other half is over the hole.)
Attached are the C64 Lode Runner sprites for reference. (Although they only used 2 frame animation.)
-
Anyone out there willing to give me some help making up the sprites for Leprechaun? (My Lode Runner style game for the SuperCharger, see my AtariAge blog for the current WIP.)
And I'm going to warn you ahead of time; you won't have many pixels to work with, or any colors either. But anything has to be better than simple squares.
-
I also have a SC and a CC2 (for 7800 development, honest!). I was considering getting rid of my SC, then this contest came around I I decided final testing on the actual device was probably a good idea.
-
Stella debugger critiques & suggestions
I'm trying to use the Stella debugger for Leprechaun. (I'm still undecided whether it or Z26.log helps me find bugs quicker. Right now the Stella memory dump is being very helpful, along with traps & breakpoints.)
annoyances (no particular order):
- the disassembly should reflect the PC, not just set the MSBs, this also seems to affect breakpoints
- breakpoints & traps seem to linger somewhat over a reload
- TIA register names shouldn't be overlaid with the symbol table for anything other than immediate loads
- scanline & frame commands should take decimal inputs, not hex (not frame count seems to be 1 more than Z26.log)
suggestions (no particular order):
- set / clear breakpoints by double clicking on the disassembly
- run, reload, and quit buttons
- ? should be alias for help, maybe break help into two pages
- ability to set inputs (i.e. joystick direction) inside debugger
-
Unlike the 2600 where the number of lines per frame is under software control, the 7800 generates a set number of lines per frame depending on whether it's PAL or NTSC. Although a PAL 7800 will try to execute a NTSC game, it may have problems because it expects to handle 50 additional lines so it will run off the end of the DLL data. This might cause garbage to be displayed at the bottom, or it could cause the game to lock up. (Probably because a DLI was invoked.)
The lack of a digital signature will prevent an unmodified NTSC 7800 from executing a PAL game. (Which has a better chance of working, depending on what those 50 missing lines contain.)
-
All the timing is locked into the frame rate. I have one DL interrupt above the score and one at the bottom of the screen. It changes the background color between gray and black at those. The bottom one starts the single-buffer DLL updates and the top one starts the collision/movement updates for the next screen (60 fps updates!). So if one or both updates finish too soon on a PAL system, it could get out of sync.It's more what's in RAM after your DLL. Since a PAL 7800 expects 50 more lines, it's going to read the next 3 bytes until it thinks it's finished those 50 lines. So if the first of those 3 byte "DLL entries" has the MSB set, then it's going to trigger a DLI and muck up the background color.
Try simply adding four 16 line DLL entries after your main DLL which point to a null display list.
-
IFAIK there are no 7800s other than NTSC and PAL. Nope, no SECAM version with only 16 colors, no 480p version either. Supporting PAL shouldn't be much more than adding some null zones to your DLL to add in the extra 50 lines. (Which is probably what is causing Mayhem's problems.)
Of course, that's the easiest way to support PAL. To really support PAL you'll need to use those extra lines and make any necessary adjustments to the code to compensate for a 50Hz frame rate instead of 60Hz. IIRC the 7800 PAL palette is nearly identical to the NTSC palette, not the 2600 PAL palette.
-
Price needs to include:
- cost of any materials (PCBs, EPROMs, sacrificial donor carts)
- amortized cost of any one time costs (EPROM burner)
- amortized cost of any one time labour (PCB layout)
- manufacturing labour
- author royalties
- profit / risk factor
Lowering the price may generate more sales, but there's a break-even point on the amortized costs. Don't sell enough and you don't cover those costs & lose money. Of course, higher prices could also drop the number of sales even farther.
The real question is how big is the market for a 7800 homebrew and what people are willing to pay for it. $20-$40 isn't a lot in the grand scheme of things, and I'm sure there are completist collectors who would pay a lot more than that.
As for making Combat 7800 available for download, that is a decision I will leave for Harry to make. And since the ROM doesn't seem to be widely available, I will take that as an indication that Harry doesn't wish to make it available for download. And I respect his decision, just like Ebivision has made that decision. And, that may even be the correct decision to increase the number of cartridge sales.
Look, there's two ways to do this. I made the decision to make my creations freely available for download. If AtariAge or PackRat Video Games (or anyone else, for that matter), wants to make cartridges for sales, that's fine with me too (although I do expect royalties). But I'm not taking any risks; I'm not out any cash if they don't sell.
The other way (which makes particular sense for Combat 7800, since it's a new, untested, market), is to not make the ROM available for download and hope that will increase the number of sales. Let's face it. We can talk about try before you buy, etc, but when it comes down to it, often people will not pay for something when there is a free equivalent.
We can also turn this on it's head. If you want 7800 homebrews on a cartridge, like Frogger, Q*Bert & Beef Drop, then you damn well better pay Harry his asking price for Combat 7800. Because the AtariAge store (and atarisales) aren't in business to make you happy. They are in business to make a profit. And the more Combat 7800 cartridges atarisales sells, the more incentive there is for them and others to release other 7800 homebrews.
Hmm, that was rather longer than I expected. I'll get off this soapbox now.
-
Did you find something? I saw that Beautifer supports some asm types.Nope, didn't find anything, and haven't had the time to create something myself. I also found that I had some semi-contradictory desires on how to handle different labels. (Important, because labels are case sensitive in DASM.)
-
Well the AtariAge Titles in Development page lists (and has links to) Beef Drop, Frogger, Q*Bert, Senso DX, SpaceWar and Tubes.
Combat 7800 was an entry to the Atari 7800 Homebrewerpalooza Contest.
Robotfindskitten had some bugs, but is notable because it was programmed using cc65.
supercat was thinking about porting the CGA game Wormy at one time.
I have a feeling I may have forgotten one.
There's also a small number of hacks which have been created.
-
Exactly. The NES had three main technical advantages over the 7800:
1. The GPU doesn't steal cycles from the CPU.
2. Simple fixed function GPU. (Versus the 7800 display lists.) Sure the NES is limitted to 8 sprites per line & 64 sprites total (while the 7800 can do 30 per line and 256+ total), but it requires far less CPU time for the NES to put a sprite onscreen. And backgrounds (with scrolling) are easy to do on the NES, but significantly impact the number of sprites per line on the 7800.
3. A kick-ass sound chip with built in DMA for sampled sound playback.
1 & 2 basically come down to the same thing: more CPU time means better games.
-
Nope, just audio on the cart. The expansion port had both audio & video lines.
-
The TIA is driven by the 3.58MHz colorbust clock, which is then divided down by some cascaded LFSRs. There's a document (TIASOUND) by Ron Fries which gives the details. (Or have a look at the schematics in the AtariAge archive and puzzle it out from there.)
-
The main advantage of POKEY is it has more bits for the frequency divider, which makes it much easier to make music that doesn't sound like an out-of tune electronic piano. However, when it comes to that actual sound (waveforms), POKEY doesn't have that much more than the TIA. So maybe it's better to say that POKEY means better music rather than better sound. (Well, it does have four 8 bit channels while the TIA only has two 5 bit channels.)
-
Hmm, interesting idea. That would reduce the 40 pin POKEY down to 18-20 pins:
3 power, ground, clock
1 audio out
4 address
8 data (write only)
2 chip select (one high, one low, might be able to make do with only one)
(might still need a R/W line to latch the data properly)
But I suspect to do so would have cost Atari $$ in retooling, instead of just dipping into the parts bin. Remember that POKEY was used for a lot of different things, including some arcade titles.
Also remember that GCC's original idea was to include a sound generator into MARIA, just like the TIA (although hopefully more advanced), but the idea was dropped for cost reasons.
-
I just look at it from a hardware perspective. The 7800 cart port has address & data lines only (well, okay, there are some other signals, but no video input like the expansion port).
So if this was going to execute C64 carts it would need to include a modified version all of the C64 guts, including the CPU. (Because there would be address conflicts with the TIA, RIOT, MARIA & 7800 RAM otherwise.) That "C64 in a cart" would then have to render the C64 graphics to some kind of on-cart 7800 compatible framebuffer (probably 320B) which then a stub 7800 game could then get MARIA to display. The stub game would also somehow surface the controller inputs to the "C64 in a cart".
So, maybe, in theory, it could be done. But it would require some custom silicon to provide a "C64 in a 7800 cart". But I can't imagine that it would be financially feasible (based on the size of the 7800 market), and probably not technically feasible at that time.
-
According to http://www.old-computers.com/museum/computer.asp?st=2&c=757 the Umimex is some kind of German console where the CPU was built into the cartridge. (Though I'm not sure if C64 meta-emulation would be possible.)
It certainly ain't no 7800 cartridge, and there's no way you could create a C64 adapter for the 7800 cartridge slot. Maybe the expansion port, but that'd be a simple video pass through, you'd need a full C64 in the "adapter".
-
Does anyone know of a tool (DOS, Windows, or C++ source) which will reformat 6502 ASM for consistency?
For Leprechaun, I've got chunks of code which I've done at different times & I haven't been consistent with my use of upper & lower case. I'd like to be able to run my source through a filter which will reformat everything.
I'm thinking stuff like opcodes as lower case, equate labels as upper case, address labels as lower etc.
Man, that was like 2 years ago. Time sure flies. 
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Atari Excellence Awards 2005 NOMINATIONS
in Events
Posted
Ahh... Well, I've never considered Leprechaun a port of Lode Runner. To me the objective of a port or remake is to duplicate the original game (although since many games have multiple ports, "original" may be open to interpretation) as closely as possible given the limitations of the platform.
Thus PoP and Beef Drop are clearly ports because they attempt to duplicate the graphics & gameplay. Where it may get fuzzier is if the graphics and gameplay are similar, but the actual levels do not match.
In any case, the author probably had a definite intent when they created the game.