7800 XM update

[Bill Loguidice]

 

I'm not saying this to justify, defend or excuse ... but I do find that sometimes homebrewers have to deal with a lot of crap. At the root of what they do is a love for the console they're working on, not because they're getting paid a 150K salary to make Atari projects. They donate unbelievable amounts of time because it's something they love to do.

 

Despite this, I've seen homebewers get raked over the coals - why are you charging this much? Why hasn't there been an updated version of this game? When will this be done? Why is it not done now? Why are you making this? That idea sucks ... you shouldn't make it! Your programming skills suck - I'm better etc.

 

I've also seen it become draining for homebrewers where they simply burn out, drop the system, abandon projects etc. Sometimes its real life taking over. Sometimes its burning out on a project. Sometimes its the crap they take in forums.

 

As I said above, Curt and GroovyBee took a lot of crap for this project, even at its inception before pre-orders. I mean, geez, there were working prototypes of systems at shows and roms of some of the games around and people were calling the hardware and software photoshop and trying to rally philosophically against even making something like an XM.

 

That's got to be draining after a while.

 

Again, I don't know why GroovyBee stopped communicating and have no involvement with a lot of the history. But I do know he made a lot more programs (at varying stages of completion) than he is often given credit for

 

I understand your point and think it reflects the reality a lot of the time, but in the end it's only forum comments, so it's hard to see that as a legitimate excuse for someone to drop out, get discouraged, etc. If you're that fragile you shouldn't be making anything for public consumption or putting yourself out there publicly. There will always be jerks to deal with. Always.

 

With all that said, in this case, considering the time that has passed, whatever criticisms were levied are hard to argue with at this point. I think in general there IS a lot of good will in the homebrew community, but consistent delivery failures despite past successes does turn general sentiment negative eventually, and in those cases, it's hard to argue against (and the main actors prior to the new team in the case of the XM have not only had delivery issues with the XM, but also in other projects, so it has indeed added up).

[Lendorien]

 

I'm not saying this to justify, defend or excuse ... but I do find that sometimes homebrewers have to deal with a lot of crap. At the root of what they do is a love for the console they're working on, not because they're getting paid a 150K salary to make Atari projects. They donate unbelievable amounts of time because it's something they love to do.

 

Despite this, I've seen homebewers get raked over the coals - why are you charging this much? Why hasn't there been an updated version of this game? When will this be done? Why is it not done now? Why are you making this? That idea sucks ... you shouldn't make it! Your programming skills suck - I'm better etc.

 

I've also seen it become draining for homebrewers where they simply burn out, drop the system, abandon projects etc. Sometimes its real life taking over. Sometimes its burning out on a project. Sometimes its the crap they take in forums.

 

As I said above, Curt and GroovyBee took a lot of crap for this project, even at its inception before pre-orders. I mean, geez, there were working prototypes of systems at shows and roms of some of the games around and people were calling the hardware and software photoshop and trying to rally philosophically against even making something like an XM.

 

That's got to be draining after a while.

 

Again, I don't know why GroovyBee stopped communicating and have no involvement with a lot of the history. But I do know he made a lot more programs (at varying stages of completion) than he is often given credit for

 

While I will agree with you on homebrewers taking crap, and how the acts of crappy people can burn people out,this project was on again off again for five years. You had promises to keep people up to date, then long stretches of silence followed by promises to try and get it out by this date and that date. I know Mr. Vendel has health issues, but five years is an awful long time when you shelled out a hundred dollars for it. Yes, it's got to be draining to get criticism. But in this case, some of it was self inflicted. Perhaps that was a sticking point with Groovybee. I don't know. I just hesitate to agree with anyone who is willing to ignore the amazingly long wait we've had.

 

As someone said a few pages back, if many of the people who paid for the XM had known they'd have to wait 5+ years, they probably would't have spent the money.

 

I'm thrilled that others are trying to get things done so it can finally be sent out. I don't know what Groovybee's issue is, but I really do wish he'd be kind to the community and be generous with the work he's already done on the project and share it with them. Seems odd to me that he'd ignore people he's had positive relationships with in the past. Perhaps you're right and he really did get burned out by it all. Still no contact, not even a, "hey, this burned me out and I really just can't be involved in it any more?" That sorta blows.

[Austin]

This thread:

 

[78001987]

This thread:

 

i would much rather watch the dog run in circles, than watch people get ganged up on and shouted down for voicing their opinion. Edited May 4, 2016 by 78001987

[78001987]

Hasn't there been a fairly consistent history of Grooveybee just randomly and suddenly dropping out of projects and going silent? I'm not an INT guy, but I thought I remembered reading a lot of grousing about how he was developing a bunch of INTV homebrews and then *poof* he pulled an Alderaan, and he was gone.

[toiletunes]

[SoulBlazer]

78001987, on 04 May 2016 - 09:09 AM, said:

Hasn't there been a fairly consistent history of Grooveybee just randomly and suddenly dropping out of projects and going silent? I'm not an INT guy, but I thought I remembered reading a lot of grousing about how he was developing a bunch of INTV homebrews and then *poof* he pulled an Alderaan, and he was gone.

 

First time I've heard a Star Wars planet used like that.

[DracIsBack]

 

I understand your point and think it reflects the reality a lot of the time, but in the end it's only forum comments, so it's hard to see that as a legitimate excuse for someone to drop out, get discouraged, etc. If you're that fragile you shouldn't be making anything for public consumption or putting yourself out there publicly. There will always be jerks to deal with. Always.

 

Agree. Was just speculating. At one point, even Bob has had to deal with complete arses that burned him out for a while. That's my only point.

[DracIsBack]

 

While I will agree with you on homebrewers taking crap, and how the acts of crappy people can burn people out,this project was on again off again for five years. You had promises to keep people up to date, then long stretches of silence followed by promises to try and get it out by this date and that date. I know Mr. Vendel has health issues, but five years is an awful long time when you shelled out a hundred dollars for it. Yes, it's got to be draining to get criticism. But in this case, some of it was self inflicted. Perhaps that was a sticking point with Groovybee. I don't know. I just hesitate to agree with anyone who is willing to ignore the amazingly long wait we've had.

 

Agree. Have voiced those concerns myself.

[Lynxpro]

Feature creep has killed more projects...

 

You bring a good point here with eveolution of tech. Much of what the XM brings to the table can be supplied in homebrews with a standard CPUWIZ board with Hokey/Pokey chip, and the upcoming H2.

 

If I had the choice between an XM and the H2 sitting on a table, and was told to pick one, I would grab the H2 because it supports many of the XM features.

 

I also firmly believe someone would have developed and released a homebrew High Score Cart lock on device (think cut off cart shell with port on top, like a Game Genie) by now if it weren't for all this waiting for the XM. The long wait may have effectively stifled potential innovation for simpler devices that would have been obsoleted by the XM.

 

Speaking of Game Genie, has anyone thought about making a similar device for 2600/7800 games so it could modify them on the fly?

[Lynxpro]

 

Speaking of the RAM, I remember asking a few years back why that amount of memory as that seemed unusual given the spirit of the project (to put 8bit style cartridge enhancements in one package). I remember the answer was that it was actually cheaper at that point to buy RAM in 128K increments instead of 16K.

 

That and the XBoard already had 128K RAM.

Edited May 5, 2016 by Lynxpro

[tep392]

Here's an interesting detail on the XM RAM that I only learned after I started working on the project. The 128K of RAM is split into 16 8k banks. Any two of those banks can be mapped into locations $4000 and $6000. The cool part is that they are mapped independently for Maria and the CPU. So Maria can be reading from two banks while the CPU is updating two other banks. This allows page flipping so graphics characters can be updated independently of what is being displayed.

[phoenixdownita]

Here's an interesting detail on the XM RAM that I only learned after I started working on the project. The 128K of RAM is split into 16 8k banks. Any two of those banks can be mapped into locations $4000 and $6000. The cool part is that they are mapped independently for Maria and the CPU. So Maria can be reading from two banks while the CPU is updating two other banks. This allows page flipping so graphics characters can be updated independently of what is being displayed.

Interesting, but how does it do it?

The cart connector has no Maria mem access signal per se, only 6502 driven R/W, Halt, IRQ and Phi2 as far as control signals go.

[tep392]

The Halt signal.

 

Interesting, but how does it do it?

The cart connector has no Maria mem access signal per se, only 6502 driven R/W, Halt, IRQ and Phi2 as far as control signals go.

[philipj]

This thread:

 

[Andromeda Stardust]

 

Speaking of Game Genie, has anyone thought about making a similar device for 2600/7800 games so it could modify them on the fly?

Yes, I have thought of it. Since the 2600 has onky 4k addessable RAM, a simple 5-7 character code format would do, similar to how the NES Genie worked. Three hex characters defines the address in ROM, since 16^3 is 4096. For 5 character codes (to be used with 4k games only), the next two characters are the value to replace it with on cart read.

 

XXX:XX

 

For bankswitched games, seven character codes are used.

 

XXX:XX:XX

 

The first three nibbles define the address, the next two nibbles define the check value, and the last to nibbles the value to replace it with. For seven character codes, the modified value is only sent to the console when the value in ROM matches the check value. That way only values requested from the appropriate bank get modified. This system should work on all standard bankswitch schemes.

 

7800 cheat system could also work like the NES Genie with support for 6/8 character codes, but the cheat cart boot ROM would need to have it's own checksum. A high score cart could be incorporated into the 7800 version of the Genie. Special provisions should be added however, to disable high score saving when cheat codes are active. Perhaps a toggle switch on the cart could enable/disable the genie codes on the fly in game. High score cart will only function if the 7800 genie switch is disabled at boot, bypassing the code entry screen completely and directly loading the piggybacked game cart with HSC hardware.

 

Just like with the H2, the 7800 genie could be made compatible with cheats for 2600 games, but would obviously not work on a 2600 due to the extra pins.

[+Propane13]

 

Speaking of Game Genie, has anyone thought about making a similar device for 2600/7800 games so it could modify them on the fly?

 

There was something back in the 2002 called Cheetah for the Atari 2600 by Bob Colbert:

I think it was a software thing only; don't remember much about it.

 

Here's a post for reference (not much reference, I'm afraid):

http://atariage.com/forums/topic/6778-cheetah-codes/

[Andromeda Stardust]

 

There was something back in the 2002 called Cheetah for the Atari 2600 by Bob Colbert:

I think it was a software thing only; don't remember much about it.

 

Here's a post for reference (not much reference, I'm afraid):

http://atariage.com/forums/topic/6778-cheetah-codes/

That went far with only 4 posts. Also the OP's hosting website got replaced by an ad portal.

 

I still think a Genie device for the 2600 or 7800 would be fun. I have found the old NES Game Genies incredibly fun to tinker with and occasionally corrupt the games. Geme Genie codes used a simple bit-swap encryption so it was not immediately obvious what the byte order was. I was thinking ROM could range from 000 to FFF start to finish, and 00-FF input for the check bytes and modifiers. Make it simple for people to make their own codes or pull values from a Hex Editor.

[CPUWIZ]

You can already use the MCP devcart for cheating, just edit the ROM and re-load. Because the cart boots with the signature, it is not even required to re-calculate the signature for the ROM.

[HammR25]

I understand how page flipping helps me read books but how does it help make games better? Draw screens faster?

[RevEng]

I understand how page flipping helps me read books but how does it help make games better? Draw screens faster?

Page flipping allows the game to display one screen, while working on another. Whenever it's done working on the new page, it flips from the old page to the new page, making all of the updates appear instantly.

 

So either the game can throw a lot of time at character updates during each frame (lots of changing tiles) or it can spread tile updates over lots of frames but still have them update instantly. (leaving the CPU more free for other work during any given frame)

 

Without page flipping, character/tile changes that should visually happen at the same time appear to happen in sequence instead. Check out PET Invaders for an example - the Invaders should all move at the same time, but due to lack of page flipping, they don't.

 

 

It's not usually that pronounced in 7800 games, but it can be if the tile updates are complicated.

 

The same concept can also apply to sprites, allowing you to build up a lot more sprites over a number of frames, so long as you don't need them to move every frame.

[Lynxpro]

You can already use the MCP devcart for cheating, just edit the ROM and re-load. Because the cart boots with the signature, it is not even required to re-calculate the signature for the ROM.

 

True. It wouldn't be as on-the-fly as a Game Genie though. Being able to edit the game while it's paused would be more Game Genie/Shark'ish. Unless there was a way to run the data through the joystick port, it would end up having to be a pass-through type cartridge device. It would be great to have a simplified device like that and as a plus also join the ranks of the other HSC options already available. I'm thinking something like that would be a hit at the next Atari Party or Portland RGC.

 

I'm getting misty-eyed for such a device. Now I'm thinking about heading over to Fair Game and buying one for the Sega [should've been Atari!] Genesis used for $4.

Edited May 7, 2016 by Lynxpro

[CPUWIZ]

Yeah, I don't know about that, you would have to read the entire cart into a RAM cart. Then you could use the HALT line to stop the processor and modify memory on the fly. This will also AGAIN run into the problem of obtaining cart connectors, which is why I didn't bother running PCB's for a pass-through POKEY board.

 

Could be a cool upgrade to the XM, depending on how it is constructed, you could potentially even use a XEGS keyboard to input the code.

 

But, IMHO, like all these funky things, it isn't worth making for 5-10 people. Far too much work and money to invest.

[Lynxpro]

Yeah, I don't know about that, you would have to read the entire cart into a RAM cart. Then you could use the HALT line to stop the processor and modify memory on the fly. This will also AGAIN run into the problem of obtaining cart connectors, which is why I didn't bother running PCB's for a pass-through POKEY board.

 

Could be a cool upgrade to the XM, depending on how it is constructed, you could potentially even use a XEGS keyboard to input the code.

 

But, IMHO, like all these funky things, it isn't worth making for 5-10 people. Far too much work and money to invest.

 

Agreed…unless it was part of a Kickstarter project.

 

Let's say when the XM comes out and the majority of its owners buy PIA chips and install them and had XEGS keyboards, with such a device as this, one could write a hack for Dark Chambers which would allow it to get closer to John Palevich's original goal with Dandy…that being to have another gamer serve as dungeon master on a separate machine loading various maps and challenges for the rest of the players on the main machine.

 

Of course, unlike the 400/800 [since I mentioned Dandy], the 7800 doesn't support 4-players, and from the sounds of it, even with a PIA and a POKEY in the XM, I have serious doubts it could be hacked to support the MultiJoy hacks that have come out over the past few years on the A8 side of things. It's a shame.

 

The XM - or any other hardware possibly designed to support "XM features" - equipped with a PIA would finally allow the 7800 to support MIDI Maze style networking. I'm still trying to wrap my head around how Atari Corp had planned to release MIDI Maze for the 7800 without it having a PIA and an SIO standard. I guess we'll probably never know the answer to that question unless Curt finds source code on that Vax he has.

[Andromeda Stardust]

Yeah, I don't know about that, you would have to read the entire cart into a RAM cart. Then you could use the HALT line to stop the processor and modify memory on the fly. This will also AGAIN run into the problem of obtaining cart connectors, which is why I didn't bother running PCB's for a pass-through POKEY board.

 

Could be a cool upgrade to the XM, depending on how it is constructed, you could potentially even use a XEGS keyboard to input the code.

 

But, IMHO, like all these funky things, it isn't worth making for 5-10 people. Far too much work and money to invest.

Why would a RAM cart be necessary? The original Game Genie surely did not dump the entire cart contents into RAM. If it did, it would have only worked with NROM titles. I think a simple microcontroller could handle scanning the bus I/O for ROM address and passing a different value to the console in the way that the Game Genie did.

 

And yes, I understand 7800 connectors would be a problem due to the extra pins, as it doesn't rely on industry standard interface like 2600 does. But that didn't stop clone makers from producing similar SNES cartridge ports to support carts with side pins.

 

A lazy way to do a 2600 version Game Genie style lock on cart port however would be to have the vintage style 24 pin floppy connector mounted on the edge of the PCB and have the "fingers" that pry open the dust flap built in as extension of the PCB itself. Then you simply use sawed off Atari shell as the case, or route out the end label area for a nicer finish. Care would be needed inserting carts, but otherwise it would work great.