Bruce Tomlin
-
Content Count
3,690 -
Joined
-
Last visited
Posts posted by Bruce Tomlin
-
-
I would think the only way a pay-for-play arrangement were to work in this situation would be to take a page from how they pay us to write books. Essentially give an advance against royalties and then once sales exceed the advance get a percentage of the margins.
Except that this model doesn't work very well when you just want a custom hack of an existing game. It's hard to give an advance against royalties of something that isn't going to be sold.
You could maybe offer bounties for specific goals, like a proper disasembly with all the references figured out such that you can randomly insert NOPs into the source code and the game still runs, but you have to come up with very specific goals (so that there isn't disagreement about when money should be paid), and you still have to be able to do something with what you get. If you have a good disassembly and still don't know enough programming to hack the game, you still won't have what you wanted.
-
I agree in principle. However, when you are working with multiple banks of code (overlays), like the Atari 7800, linking and not including does make some things easier.
Nah, bank switching is cake. All you need is multiple ORGs and a few conditionals to check that no page is running over the end. But I suppose it might be nice during development if you have to move stuff from one bank to another. Then all you need to do is mess with the linker control files.
But when you're creating a lot of different assorted combinations of modules (like the legacy 6809 code where I worked) into a system with banked 4x32K ROM and 4x16K RAM, it does become kind of essential.
However, their later 6809 code was all done position-independent, with an RTOS that would assign them RAM and handle the bank switching, so all modules were self-contained and could be put just about anywhere except for the few that required more than 16K of ROM (the second half had to be in page N+1). After I wrote a Turbo Pascal program to put the modules together and a couple of DOS batch files to mimic a primitive make system, things went together real easy.
-
[Reading the paddle is a matter of having the software keep track of how long it takes after the dump for the input signal to become a 1.
And that's "how long" in terms of scan lines. A full screen worth of scan lines is about half the travel of the pot, which is why paddle games only use half of it. This is designed for pong-style games where the paddle can begin showing at the moment the input is sufficiently charged. The kernel has to check the inputs every scan line or every other scan line.
I suppose you wouldn't have to check it as often with fixed resistances, but you still have to keep in mind that those resistances will not be exact, and the charging characteristics will probably not be exact either.
-
I'm always interested in hearing about the original 7800 development tools, too. I hadn't heard of the 2500AD 6502 assembler/linker until you mentioned it, but it looks like it's still available in a Windows version (although it's a bit pricey for me).
In a previous job I used version 5 of their 6809 assembler. Basically it was a cross-assembler from back in the day before cheap fast CPUs, cheap fast hard disks, and the gnu tools, not to mention people like me who wrote their own cross-assemblers. (Once the code was sufficiently factored, it took me a day or two to add 6809 support.) The main feature of 2500AD was that it supported linking together separate object code modules, and it also had a C compiler available. (At least there was a C compiler for 6809, though all I ever got was the manual unless I ended up with the floppy disks in a pile somewhere.) It also let you be lazy, because its parser didn't require a semicolon before comments.
Back in the day, when floppy disks were less than 200K (the source for a 32K game runs 300-400K with hard tabs), hard disks cost half as much as a new car, and CPU speeds were measured in single-digit megahertz, it was a big thing to be able to assemble/compile just one module and link in the rest. Nowadays it takes less time to assemble the code than to start up the emulator, and I think nothing about disassembler listings that take up a megabyte in the early stages, other than it takes half a second to open the file.
I wouldn't mind adding modules and linking support to my own assembler, but your average 2+GHz CPU makes it not worth the effort. If all you want to do is break up the files into smaller chunks, an "include" directive works just as well.
Anyhow, I think it would be cool to see the source code too. It's the comments and label names that are the interesting part, but comments tended to be scarce back in the days of 32 to 64 column screens. Only the real pros (and Apple II users) had the luxury of 80-column screens.
I'll see if I can't disassemble and diff out the changes. Gotta hunt for the various binaries first.
-
Couldn't a paddle line be used as an output sufficient to control a multiplexer?
Maybe. Start by leaving the outputs undumped most of the time. Then read the joystick inputs, dump the paddle outputs, delay a scan line or two, read the joystick inputs again, then undump. You would want a 7414 gate hooked up to one of the outputs for the joystick select since it's an analog signal.
This would even read faster than faking a keypad. Both paddle outputs dump at the same time, so you can't use them separately, but one is enough. It looks like a 7414 and a pair of 74157 chips would do it. If you made it work with both ports, you would only need a third 74157. Total bill of materials: 1x7414, 3x74157, two 9-wire plugs, four D9M jacks. If you're cheap, you can probably replace the 7414 with a 2N2222 transistor. And as long as you don't use CMOS 74xx chips, you don't even need pull-up resistors.
I wouldn't wire up the two joysticks without a 74157 chip to multiplex them, though. If you simply wired the paddle output to the ground of one stick and an inverted paddle output to the other, it would create a shorted path if both players pressed the same buttons.
Also, it just occurred to me that the 4x3 keypad wiring method would not work for two unmodified sticks, because all five buttons are wired to a common line. You would have to run them through a multiplexer, and the result would likely be more than three chips.
However, you could probably configure a joystick pin as a select output to some 74157 chips, then re-wire that input from the joysticks to one of the paddle inputs. You could use the other paddle input for a second fire button, or you could even hijack two joystick pins for select outputs and have EIGHT joysticks with 74153 multiplexers. But input would be slow like with scanning a keypad.
-
Without looking at anything, it seems to me like you could do it. First of all, you would absolutely need diodes on every one of those switches to avoid ghosting, just like Colecovision controllers use. (Unless you went all the way and did something with TTL chips, that is.) Ghosting is okay for keyboards, but not for joystick inputs.
The best way to package it would be to simply create an adapter that has a plug and two jacks, then you wouldn't need to hack up any controllers (other than to get a plug with sufficient wires).
It would be nice if you could do like the Colecovision and use the extra two pins for select signals, but on the Atari those are the paddle inputs, which have to be used as inputs. And in fact, that's why reading keyboard controllers is less than trivial. You have to delay like two full WSYNCs after selecting each of the four rows, then each of the columns is on a different TIA input. For both ports, that's a total of six inputs you have to collect per row.
(Hmm, I wonder what you could do by hooking up the row outputs to a decoder chip. 30 keys per port with a 4-to-10 decoder, and 48 keys with a 4-to-16 decoder. That's not exactly awesome, but it's interesting. Basic Programming would have been less annoying.)
-
Arcade PCBs are exposed to a lot of dust, some of which may be a bit conductive, and that is why cleaning them works for you. But the Colecovision is not a coin-op.
In the case of the Colecovision, the problem is typically video DRAM chips that have gone bad, and bad power, usually due to oxidation inside the power switch. No amount of soaking in water is going to fix a bad DRAM chip.
Often a DRAM chip goes completely bad, and you can tell which one by how the "insert cartridge" screen looks. Actually testing for bad bits sounds like an interesting idea, though. I might see what I can do when I get a couple of my current projects finished.
Also, if there is a dead DRAM chip, it might be good to figure out a way to show it even with the chip dead. Maybe something like "U8 BAD" in big block letters. Or even choose name table entries to work around it. (Hmm, I've seen bits show up bad in the name table, but the patterns are still OK? And I only just now realized this after how many years?)
It would also be nice in addition to the controller test I've already written, to have one specifically for testing if either joystick input chip has gone bad. Something like you turn the stick in all directions, and it marks inputs as being good.
Of course there will always be problems that can't be tested simply by software diagnostics, like the one time I got a "sepia-tone" CV. One of the inputs to the video modulator had a bad solder joint and it was causing all the colors to come out brownish.
-
MESS is well named because it is a total mess. I use a version of MacSDLmess in my build scripts to test my code (because I can call it up from a command line), but that's really it. I know there's a bug with the VDP interrupt handling which can potentially cause a game to lock up when it wouldn't on real hardware. But since I only use it for development, I don't know if any real games are affected. (I blame Coleco anyhow for putting it on NMI, which has some rather annoying side-effects.)
-
Keio Flying Squadron is good if you like shooters.
Popful Mail is a pretty good platformer, but right now I'm bogged down in the middle where they throw like five boss fights in a row at you with very little advancement in between. Fortunately I'm playing on an emulator and can use save states to make those fights less annoying.
-
Count me in as another vote for clamshells. My preference would be clear plastic clamshells that can take cover sheets (like clear DVD cases). And I've been annoyed the past few years about how VHS clamshells tend to have hub nubs in them, making them impossible to re-use for cartridges without modiications. You can get them with no nubs and with cover sheet thingies, but you basically have to mail-order them that way.
Most importantly, clamshells don't collapse like cardboard boxes, especially the ones with gatefolds and a nook for the cartridge. (Intellivision, O^2, etc.)
The only problem I have with clamshells is the baffling ease at which instructions seem to get lost from them. This doesn't seem to be just a problem with rentals.
-
"Fix" is a generous term. You can adjust the white gear to play DVDs, CDs, and dual-layer DVDs, but not all three at once. I've done it before- I had to do it to play Gradius V and Chulip- and it's no fun having to readjust it constantly to play all the games in your collection. I just wound up buying a slimline PS2 as a replacement.
I think it depends on how the drive is messed up. From what I understand, the white gear is the coarse control for the angle of the read head. And it uses a cheap leaf spring to keep in position. As the leaf spring weakens with use, the gear lets you adjust for the change in spring tension.
Of course the best reason to have a fat PS2 is because you can add a hard drive and a memory card running Free McBoot and turn it into a jukebox system which doesn't need to use the crap Sony drive. Rip and patch once on a PC, then put the game back on the shelf.
Back on topic, I found a Camerica NES Freedom Stick the other day, minus the IR receiver module. Add a 9-wire plug, and a DB-9 connector for a keypad, and this should make a good replacement joystick for Colecovision.
-
Even better is if you can include a version number and/or date near the beginning of your code so that it ends up in the binary.
-
Taking the rest and making keychains and other art work out of them would be cool.
Worst comes to worst, if everything is going to be scrapped then you should save the boxes if you ask me and flatten them out nicely.
You should also film that many cartridges melting. Is there any way you can get some cameras mounted in the thing that melts stuff?
Don't forget cartridge wallets. Saving the boxes may not be a bad idea, but with that many of them the most interesting thing to do with them is to cover walls with them. With a good assortment, it might be cool for a theme restaurant.
And I suspect that the recycling process would start with grinding them to something like small gravel, then probably a winnowing process with either air to blow the plastic and paper away, or an electromagnetic process to kick the metallic bits away.
-
I would guess they are final, since they are mask ROMs. Prototypes would be on EPROMs.
These aren't development prototypes, they're production prototypes. But without the matching cases you wouldn't be able to tell. There is still a chance that they could be different from the final release, though it is unlikely.
Anyone got a can of Krylon and a hacksaw lying around in their garage? I can probably dig up a few old labels. (ha ha)
-
Yeah, the reef store dreams.
Also, me being the one to give the Cooper Black carts that name. (I did in fact confirm that a few years ago.) That was the typeface they used for their text, so why not?
The newsgroup auctions: yes kiddies, there actually WAS a time before ebay!
Also, I met SSSSPACEWALK in person a couple of times.
-
So O'Shea wants their salt mine space back now? Still, it serves them right for jacking up the prices on everything simultaneously and then wondering why they stopped selling so well. All they did was sell out of the ones that were actually rare enough to be worth more. Then they had convinced themselves that they were all worth five bucks and didn't lower the price of the rest.
I'm thinking that it depends entirely on which carts are involved here. A bunch of Pac-Man and ET, you could melt down 95% of them and it would be no real loss. Somewhat rarer games (Tower Toppler, Barnyard Blaster, Meltdown, etc.) are still worth at least two bucks, but there aren't likely to be many of those left. Definitely the low-numbered 2600 games get priority over 7800 games.
Yeah, if there are any copies of Ballblazer, they're all worth saving for the Pokey chip. (I'm guessing Commando is long gone.) Sell 'em for four bucks single or less per case (6-pack?) and let people desolder their own damn chips. Jinks is also worth something for the board and RAM chip, it's the most common 7800 RAM game easily converted for homebrew purposes. Maybe 10 bucks per 6-pack. It really depends on how badly people want to desolder chips or how efficiently they can do so.
Making the carts worth about $1.30 a piece in gold right now not including the PCB's which could have gold as well.
Well, for what it's worth, even with the types of carts Albert wants, he wants the molded plastic shells, not the boards. All you gotta do is get someone to remove the screws, pop out the boards, throw the screw and shell into one box and the board into another box. Still, holy crap on the amount of gold in there. (Note that some of it is the little bonded wires inside the chips that connect them to the pins.)
It sure makes me wish I could get anywhere near that kind of money for the gold in all the junk boards in the attic that I've accumulated from taking stuff apart to save space. Mostly it's so I can (theoretically) have a nice supply of parts, but most multi-layer boards have holes too small to desolder the chips easily, and I tend to get the interesting chips off first. And the going rate on "computer scrap" recycling normally considers all the sheet metal and plastic that goes along with whole items. (Scrap steel is priced by the TON.)
-
It's probably not a good idea to trust wire colors, since there's nothing to say they didn't change (even on different manufacture runs).
Find the pinout, stick a straight pin into the appropriate pin of the plug, then use an ohmmeter to find the wire.
-
No way.
Cheese.
Cake.
CHEESECAKE.
-
The CoCo guy is doing the same thing. In his store, he's got ham gear, and there is some cross over to the CoCo as that stuff has good memories for a lot of HAMs, though I wonder. Most HAMs I know (and I was once one) are pretty savvy.
HAMs also have hamfests, which are like the various video game meets we have, only more of them, and less far to drive. (For instance, there is currently NOTHING in Texas for video games, other than a coin/pin thing in Houston. The only one barely in range is in Tulsa.) They already have a good way to sell directly to each other. They don't need flea-bay.
-
I'm guessing that the saw cut is there to mean "not for sale" or somesuch.
It would be a "cut out", just like remaindered LPs (and LDs) would have a saw cut along the side of the sleeve (where there was no disc), CDs would have a notch bitten out of the jewel case spine, and unsold books would have covers removed. (I may have seen a "cut out" DVD, but if I did, I don't remember how it was done.)
-
That's called a "reef store" dream (after someone in rec.games.video.classic had a dream where he found all sorts of wierd cartridges and stuff in a thrift store that was off shore in a reef), and is often considered a good omen for going out thrifting that day.
-
They added scaling and rotation technology to Sega CD. Could they have also boosted the number of colors for better video quality? I don't know to what extent that would have driven up costs, but it was expensive anyway.
You know what they had to do with the 32X? That's what they would have had to do to get better graphics on Sega CD.
The scaling and rotation was just a processing chip. You fed it the graphics data, it chewed on it and spit it out, and then you had to write it to the VDP yourself.
-
Update on my $30 haul of systems. The PS2 powers on and gives you the main menu screen, but insert a game or movie dvd and it doesn't load it.
Is it a "fat" PS2? Google for "ps2 white gear". While this won't help a truly crapped-out drive, and it's a pain in the butt to take the unit apart (especially to avoid pulling out cables that you shouldn't), it may in fact fix it.
-
Interestingly, there's no actual "hardware" inside the devices. I think there's a chip to let it Boot in SMS mode, but all the hardware beyond that is in the genesis itself...unlike all those Atari clones from back in the day, which were an entire 2600 and just used the console as a leach for power and video feed.
Actually, the only hardware needed for an adapter is for the pause button. I'm not sure what the chip in a genuine PBC is used for, but it may be related to the card slot. There have been adapters which are nothing more than a circuit board in a vertical-stack cartridge, if you don't care about the games on card. (aka "Tower of Sega" mode) The adapter is also necessary to ground the "M3" line, which selects SMS bus mode.
(I really don't know what Sega was thinking by putting SMS games on cards as well as carts. I guess maybe they were thinking of making a portable system, but didn't follow through on the card format. All they succeeded in doing was confusing customers. Using the card slot for the 3D adapter was okay, I guess, but it would have been better in port 2.)
The support supposedly exists even in Sega-branded MD/Genesis systems without the physical ability to use Sega's adapter. Note that the Genesis 3 was not produced by Sega, and has the support removed.
The one game on card that I know won't work (F-16 Fighting Falcon, which is as far as I know the only 32K card game), doesn't work because it is one of the few SMS games that use a TMS-9918 video mode.
EDIT: Apparently the card slot was for backwards compatilbility with a card-slot add-on for the SG-1000. Still, it sounds more like a gimmick than anything else.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Top 25 psp games of all time
in Modern Console Discussion
Posted
It doesn't suck as bad as the Sega CD. But now you see why so many people want to run emulators on the PSP. It emulates everything up to the PS1 very well, and apparently the N64 too.