Bruce Tomlin

Got a pic of the bare board? I want to see what kind of chips were used on a real PB proto board. Or a link to a schematic would be good, if discrete chips were used. I just want to see how they did it. Because I haven't been able to find a good way to do it without a 4x4-bit RAM chip, even with PALs.

Because most people don't shop at flea markets or thrift stores. I'd say that most average people either don't know about them or are barely aware of them. Or for whatever reason, the idea of buying something used is unattractive to them. And then there's all the silly people buying up the $5 consoles all the time. Soccer Moms want something that's easy to find on a whim (just take the SUV down to the nearest big box store), and that can be wrapped up in nice paper for Johnny's birthday or for the pile of Christmas presents. If someone asked you to buy a 2600 and bring it back in one hour, you might be able to do it. Most people wouldn't. All that said, I'll just repeat my opinion on this. As long as there are holes on the circuit board to add a cartridge slot, and holes for a switch to disable the on-board ROM, I'll be happy. Because something like this could make a portable 2600 very easy to build.

5200, maybe, Colecovision, no way. The Colecovision used a plug that only the TI 99/4A used, and with completely different voltages. (Do NOT plug a TI 99/4A power supply into a Colecovision! The TI 99/4A uses 18VAC, and the Coleco uses 5 and 12 volts DC!) Unfortunately, due to the way the TI plug is wired, you can't even clip the wire off and use it to hook up a generic power supply to the Coleco. The 5200 needs 9-12 volts, 2 amps. The polarity is reverse that of a Sega Genesis model 1 power supply.

It works just fine. It makes a beautiful picture on both my big Sony TV and on a Commodore monitor. (I got an S-video male to dual RCA male cable for five bucks at Fry's.) The only problem I have is with a portable multi-game clamp display from Mad Catz (I think), where the colors are easily overmodulated on it (the main CC2 screen shows as all rainbow colored), but I've hooked it up to other game systems and it shows the same problem. Maybe there's a trimpot inside the display that I can adjust, or maybe I can make some kind of attenuator cable. I did make one mistake, which was that I forgot to trim down the ribbon cable on the "left" side (the right side goes to a farther row of resistors) by a half an inch before soldering to the resistors. But it was already in and working, and I didn't want to mess with it any more. And just to clarify things here, I am ***NOT*** making more of these things! This is just the regular S-video mod you can find with a Google search! It was someone else who hinted at making an easily installed mod! I just took the time to make mine look nice and fit on a tiny board that I happened to have lying around.

It's about time I posted a picture of the mod I did... this is about as small as you can get that particular mod without using surface mount parts. And I just happened to have a chunk of board this size handy.

But Hat Trick still has the redeeming value of having the most useful circuit board of all the carts out there (except for I think it's Winter Games which has a RAM chip too). If I was ever to try putting a big game on the 7800 (or making repros of same), I'd order a couple cases of Hat Trick from O'Shea's, and hope I could get a better price for ordering a bunch at once. But since what I'm working on now goes just fine onto a PP2 board with a 7404 chip added, Hat Trick carts won't do me a lot of good.

It's nifty, but I don't need one thanks to the CC2. I can either drop hacked images on the card, or load them through the serial port. So far, my only hack has been an infinite lives hack for Montezuma's Revenge. Ditto for the Colecovision, since I have an ICE with 64K of overlay RAM (16x4K blocks), which even lets me override its BIOS ROM.

Or if they do get successful, they end up being bought out by a chain. In San Antonio, Game World got up to three locations, then they sold out to Gamestop. Then there was Gamefellas in Austin, which had three stores in Austin and one in San Antonio, but they've since shrunk back to only one store in Austin, and I don't know the status of their San Antonio store. But GF was only in malls, so they probably had a bit more overhead.

As I recall, when you travel a lot, the chance of someone going with you and not coming back is rather high. Another thing that's kind of annoying is that no matter how well you treat everybody, even if you don't travel someone is going to move out every two weeks anyhow.

You didn't know that the people who made Ms. Pac-Man are the same people who designed the 7800?

The 2600 just doesn't have what it takes to do a decent menu system. The lack of a phase 2 clock line doesn't help either (it's why Robot Tank has problems on a 7800, but no problems in a CC2) That's why the CC2 was made for the 7800. If you wanted the features of the CC2 badly enough to pay $200 for it, getting a 7800 to use it in is a minor issue. There's only a few games that don't work right on a 7800 with the CC2, and those are basically due to the B&W / PAUSE switch change.

But you still have to have a PC handy to use it. What makes the CC2 so great is that it's completely standalone.

Ditto here. Although I did one other thing. Back then I found on the internet how to get (and hack around for) codes for various random objects. I guess they didn't put much checksumming on the codes. Toward the end when I was really getting tired of it, I would not play for two weeks, then set the clock back to the day after I last played it. Then I'd do a day of stuff, move the clock forward, do another day of stuff, move the clock forward, etc.

Hmm. I'm headed up to Dallas for an anime convention on Labor Day weekend... maybe I could bring one up with me? I'm pretty sure I can find one in my piles of crap. I never really considered a bare Aquarius console to be worth more than three bucks anyhow. And extras are more of a pain than they're worth to keep around, so I'll even give it to you for free.

Well, this will certainly be a first in the history of classic games... EPROM microsurgery to recover a lost game!

Seeing as how the picture in the auction was bad enough "accidentally on purpose" to blur out the word "reproduction", I think the only thing label-wise that could have made a difference would have been to put an AA logo on the label.

Yep. Don't need one. I've got a Z-80 ICE with 64K of overlay RAM. Mmm, single-step...

I saw one back in the day, not knowing what it was. I figured out that it was MS-BASIC with 2K of RAM. My Level II 16K TRS-80 from years before was more capable than that. I'm pretty sure I have a boxed LOGO somewhere in my box of Aquarius stuff. Not sure where I got it, though. As for the price markings, it's LOGO, so of course those are turtle graphics.

Colecovision would be too easy (no carts used bank switching) and would have little need for an FPGA, but I think Intellivision could use something. NES/Famicom would be nice due to all the bank switching variations used, but it would be a tight fit for an MMC card. I have 200 megs of over 900 ROMs that I got from a DC emulator disc, and the biggest MMC cards are 256 megs (for around $100, IIRC). Then there would be the little issue of the copy protection chip. But they'd be easy enough to desolder from SMB/DH carts and stick into a socket on the board.

I don't understand what you mean. All my macro parameters are literals, so you can use a label that's not defined yet, because it just drops in the parameter as a string, editing each macro line as it is being used. I still need some way to "glue" the parameters without whitespace so you could (for instance) append "_END" to a parameter. I'm using the macros together with segments as a way to assemble 7800 graphics and make them actually readable. ************ C000 GRAPHICS DATA ************ ; initialize segment addresses SEG C000 ORG $C000 SEG C100 ORG $C100 SEG C200 ORG $C200 SEG C300 ORG $C300 SEG C400 ORG $C400 SEG C500 ORG $C500 SEG C600 ORG $C600 SEG C700 ORG $C700 SEG C800 ORG $C800 SEG C900 ORG $C900 SEG CA00 ORG $CA00 SEG CB00 ORG $CB00 SEG CC00 ORG $CC00 SEG CD00 ORG $CD00 SEG CE00 ORG $CE00 SEG CF00 ORG $CF00 SEG ; macros for graphics data GFX_C0 MACRO L3,L2,L1,L0 SEG C000 HEX L0 IF (. >= $C100) ERROR Graphics overflow in $CXXX block! ENDIF SEG C100 HEX L1 SEG C200 HEX L2 SEG C300 HEX L3 ENDM GFX_C4 MACRO L3,L2,L1,L0 SEG C400 HEX L0 SEG C500 HEX L1 SEG C600 HEX L2 SEG C700 HEX L3 ENDM GFX_C8 MACRO L3,L2,L1,L0 SEG C800 HEX L0 SEG C900 HEX L1 SEG CA00 HEX L2 SEG CB00 HEX L3 ENDM GFX_CC MACRO L3,L2,L1,L0 SEG CC00 HEX L0 SEG CD00 HEX L1 SEG CE00 HEX L2 SEG CF00 HEX L3 ENDM SEG C000 G_BLANK_SQ: GFX_CC 0F0F0F0F, 78F0F0E1, 78F0F0E1, 78F0F0E1 GFX_C8 78F0F0E1, 78F0F0E1, 78F0F0E1, 78F0F0E1 GFX_C4 78F0F0E1, 78F0F0E1, 78F0F0E1, 78F0F0E1 GFX_C0 78F0F0E1, 78F0F0E1, 78F0F0E1, 0F0F0F0F SEG C000 G_UL_CORNER: GFX_CC 0F0F, 78E1, 78E1, 78E1 GFX_C8 78E1, 78FF, 7900, 7900 GFX_C4 7900, 7900, 78FF, 78E1 GFX_C0 78E1, 78E1, 78E1, 78E1 I can also do 7800 display lists (this is derived from Harry Dodgson's stuff): DLI MACRO DLI, H16, H8, LINES, ADDR DB (!!(DLI) * 128) | (!!(H16) * 64) | (!!(H8) * 32) | ((LINES-1) & 15) DB >(ADDR) DB <(ADDR) ENDM DL MACRO ADDR, PALETTE, WIDTH, HPOS DB <(ADDR) DB (((PALETTE) & 7) << 5) | (-WIDTH & 31) DB >(ADDR) DB HPOS ENDM XDL MACRO ADDR, PALETTE, WIDTH, HPOS, WM, IND DB <(ADDR) DB (!!(WM) * 128) | 64 | (!!(IND) * 32) DB >(ADDR) DB (((PALETTE) & 7) << 5) | (-WIDTH & 31) DB HPOS ENDM ROMDLL DLI 0, 0, 0, 15, DL00-ROMDLL+RAMDLL; skip 25 scan lines, and set WM DLI 0, 0, 0, 10, DL0-ROMDLL+RAMDLL ; main display is 12 zones of 16 lines each, with holey-DMA 16 DLI 0, 1, 0, 16, DL1-ROMDLL+RAMDLL DLI 0, 1, 0, 16, DL2-ROMDLL+RAMDLL DLI 0, 1, 0, 16, DL3-ROMDLL+RAMDLL DLI 0, 1, 0, 16, DL4-ROMDLL+RAMDLL DLI 0, 1, 0, 16, DL5-ROMDLL+RAMDLL DLI 0, 1, 0, 16, DL6-ROMDLL+RAMDLL DLI 0, 1, 0, 16, DL7-ROMDLL+RAMDLL DLI 0, 1, 0, 16, DL8-ROMDLL+RAMDLL DLI 0, 1, 0, 16, DL9-ROMDLL+RAMDLL DLI 0, 1, 0, 16, DL10-ROMDLL+RAMDLL DLI 0, 1, 0, 16, DL11-ROMDLL+RAMDLL DLI 0, 1, 0, 16, DL12-ROMDLL+RAMDLL DLI 0, 0, 0, 16, DL0-ROMDLL+RAMDLL; skip 26 scan lines DLI 0, 0, 0, 10, DL0-ROMDLL+RAMDLL DL00 XDL G_BLANK, 0, 1, 0, 1, 0; address=>blank, palette=0, width=1, hpos=0, wm=1, ind=0 DL0 DW 0 DL1 DW 0 DL2 DW 0 DL3 DW 0 DL4 DW 0 DL5 DL G_UL_CORNER, 4, 2, 40-4 Because I haven't needed it, and it would be a lot of work when I had other stuff to do that was more important. It requires parser tricks on the order of making macros work.

Definitely not, but is your assembler compatible with DASM code? Probably about 95+% now. Besides, nobody except me has cared enough to try to make it compatible. I'm certainly not going out of my way to add DASM-isms that I don't think people aren't using. There's some wierdnesses in DASM due to the way it was designed that I don't handle, and many of them are unique to DASM and not any other assembler. DASM is kind off in its own little world with the way it does things. And I made this assembler to work the way I wanted, not to please people with years of DASM code. In particular, I have no delusions of having you in particular switch to this. You're the last person I'd expect to want to switch, because you've written so much DASM code already. A few of the differences are: 1) because of the multi-pass, you can ORG to a label that isn't defined yet. I'm not yet convinced that this is a truly useful thing, but I've seen it relied upon (in such a way that moving an EQU statement to the beginning of the source would have fixed the problem). 2) it always outputs data with a DS statement and uses segments to stop that. This is because it outputs .BIN files, which can't have "holes" like .hex and S9 can. So I have SEG.U work the same as SEG. This causes the same result in normal DASM use of DS and SEG.U. 3) I think one form of equate statement in DASM acts like a #define, but it's not obvious which one. All my equate statements evaluate a number and only save that. You want a macro, define a macro. 4) There will be subtle differences in the expression evaluator, but those are cases where you probably should have used parens anyhow. Oh, and I take both ( ) as well as [ ] for parens. The guy who wrote DASM apparently couldn't figure out how to parse 6502 code while using regular parens for expressions. 5) dot-labels are defined relative to the last regular label, not a SUBROUTINE statment. I could consider changing this someday. 6) no REPEAT / REPEND. I do add some useful things, though. I've added stuff so that a lot of vintage 7800 source code will work without changes, in particular the H() and L() functions, which are used everywhere in old 7800 source. It's also compatible with whatever Harry Dodgson used for his 7800 Monitor Cart. It'll take his code after you space the opcodes out of column 1. Someday I may make a 2.0 where it adds a linker so that you can use multiple source files without recompiling the whole thing. That's pro-level stuff that REAL cross-assemblers do. 2600 projects aren't big enough for this, but it is possible that a 7800 or NES or Colecovision cartridge could get big enough. And DASM won't do 6809, Z-80, etc. I've done Colecovision code and want to do Vectrex code someday. I have hardware ICE emulators for 6809 and Z-80, and that's why I want output in .hex/S9 files... because that's what they take. So, did you even try reading the documentation to see what my assembler can do?

Actually, if you look at the picture in the auction, you'll notice it's very badly focused. It's not hard to take another picture if you get a bad one. In fact, I'd probably have to work to get a picture that bad. And I could certainly make a JPG that looked much better.

I've finally updated it again, to version 1.7. I also added 6809, 68HC11, and 8085 assemblers. A lot of bugs were fixed, conditional assembly was added, undocumented 6502 opcodes are supported, output was cleaned up, segments are now supported, and it was made even more compatible with various old assembly code pseudo-ops. (I like not having to global-replace on old code to make it work.) There's also a new version of makerom with minor fixes, and a new version of sign7800, also with minor fixes. C'mon, I can't be the only programmer around here who isn't totally in love with DASM!

And the .zip file format is completely open. And it's not going to change either, like RAR did a while back. As a Mac user, it was no fun trying to decode RARs when the l33tists insisted on using the latest beta of RAR with default settings. It is still no fun to try decoding ACE v2 archives.

But unfortunately there is none. You could add one to the Atari though. Which doesn't do any good. Because the cartridge bank switching won't get reset. I had even wired up one to my 7800 before I realized this wouldn't work with the CC2.