BSS Show full post »
BSS
Still waiting on these boards to arrive...

Here's the updated label. As described on the podcast, now totally redone in Inkscape to avoid issues with modifying the older crazy high resolution bitmapped version.
RiverRaidTE.png 
I also forgot to mention above, when you load up the 60Hz version of the game it plays a few explosion sounds to indicate turbo mode.
Quote 1 0
Mar
Looks snazzy.

I know this isn't going to be mass produced so it's not really an issue. But I'm assuming the bit in the top left is to indicate that removing and reinserting the cart activates and deactivates turbo. Just talking for myself (and if I didn't know before hand), I'd be confused and looking for a little button up the top! Maybe there's a clearer way to describe the function?

Again, it's not going to be mass produced so maybe it's not worth exploring other options.
Quote 0 0
BSS
In practice, I've found that my 6 switch doesn't even come close to toggling the switch. The system barely needs any force to open the dust cover. Jr systems don't even have the cover.

So the more than likely scenario is that anyone who wants to switch modes will be doing it by pushing the thingy with their finger, which is located around that indicator.
Quote 0 0
bakersnarkMDW
BSS wrote:
In practice, I've found that my 6 switch doesn't even come close to toggling the switch. The system barely needs any force to open the dust cover. Jr systems don't even have the cover.

So the more than likely scenario is that anyone who wants to switch modes will be doing it by pushing the thingy with their finger, which is located around that indicator.


That’s a good thing because it will stay in the same mode on reinsertion and only get switched to “Turbo” when you make it.
Random item from my Tabletop Games Collection
[image] 
See it & the rest here:
Quote 0 0
BSS
The V3 boards did eventually arrive. Should they work, they would almost certainly be the final edition.
1.jpg 
Here's the first populated one ready to be entombed. Switch wired and in place by the pole. Note: No sockets, and I left the programming jumper open. Possible regret incoming.
2.jpg 
Basically it didn't work. I just got vertical lines or nothing. Seemed a little random too which wasn't too comforting. After checking all of the connections for a while I was confident everything was wired correctly. Closing the jumper didn't help. At the time I'm thinking I either wrecked the EEPROM during soldering, or maybe the wires to the switch are acting like an antenna.

I own a 8 channel logic analyser which I thought might give some insight. So I got to connecting everything up.
3.jpg 
As it turns out, my thingy won't do a raw 8 bit bus without a clock signal. Which means I have to take one of the 8 wires and connect to the clock line, leaving only 7 for data making this probably not a useful endevour. Anyway here's a screenshot of the Atari data bus chooching away. Not a super clean signal but it didn't matter by then.
logic.png    
The next thing to try was to verify everything using the EEPROM programmer. But because I didn't use a socket it means I had to convert it to work with the board. I had intended to do this anyway, just not so soon. Here's the contraption as it looks right now.
5.jpg 
So verifying the ROM like this showed that it was waaay off. There was data, but probably 80% different to what I had programmed. So I wrote the ROM again, and tried it in the Atari again. Still no good.
After giving up for a couple of days I thought I'd try the still assembled and working V2 board in the EEPROM programmer to make sure the new socket was wired good. This didn't verify correctly either, but it was close. And now there was a clear pattern. I found that a couple of bits were flipped.

I fixed the wiring, verify the V2 again and it's still wrong. But now only a few bytes in the whole 4K. This is actually a little concerning, because now I'm pretty sure the programmer is OK. Are EEPROMs not as reliable as I thought?

Anyway I programmed the V3 cart like this, and fired it up. He works. Here's a the sealed cart running the game.
6.jpg 
Winner.

Except this experience raises new issues that I don't understand yet. All of the possibilities I can think of are rather slim chances.
- Soldering the EEPROM corrupted it?
- Having the programming jumper open was unstable even though it should just connect to the second ground pin as expected.
- Why the V2 cart has flipped a few bits I don't know. Maybe buffering the write-enable signal through the hex inverter is not a good idea.
Quote 2 0
Mar
Hmm, that's very confounding. How can it change from what was programmed in it? To be fair though, I'm not entirely able to follow the various bits and pieces you are doing externally from the ROM (my brain isn't good with this kind of stuff). But that being said, surely it has to be related to what is happening outside of the ROM. Unless you've somehow got two seperate ROMs that are dying, and won the ROM reverse lottery!
Quote 0 0
BSS
Searching for more sacrifices on ebay. Surely no self respecting collector, or otherwise, would want this. I'm sure better quality carts came out of the New Mexico landfill.
sm.png 
Quote 1 0
bakersnarkMDW
Would you want to wrap that around your board? The screws look good! 😏

What are they asking? 💵
Random item from my Tabletop Games Collection
[image] 
See it & the rest here:
Quote 0 0
BSS
Trash to treasure! It's $10 including shipping. It's on the way.

I found a critical bug in the game on Friday while playing the cart on the 128-in-1. I just spent all Friday night and Saturday working on this. Might be a bit of a dense post, but it gives in idea of how this thing rides on a knife edge sometimes.

On game 3, I found that if you hit the final bridge while it isn't completely drawn on screen, the game lets you play one more stage. I'm surprised I never came across this before, because to optimise your time you want to destroy the bridge as soon as it appears on screen and I would have been trying to do this.

Originally I had programmed the game to end when a bridge explodes, and you are on level 6.

The reason this is a problem is because the game treats your current stage as the one at the top of the screen, rather than where your plane is located. The bridge is a divider, but ultimately is considered part of the previous stage than the next. So it's possible to hit the target bridge while the game still has you on level 5.
bug.png 
So fixing this means I had to add something to check if the bridge is in the top block, and add 1 to the comparison. This would take 9 bytes, and what you do know, I have 9 bytes of ROM space right there.

As it turns out, those 9 bytes aren't contiguous. You can see four $EAs in the screenshot. The rest are right around where this subroutine is called. So I had to skimp on clearing a carry flag for the addition, meaning it actually adds 2. Due to two fortunate coincidences, this doesn't seem to matter.

- The "bridge is exploding" byte is actually a counter that is set to 16 then counts down to 0. So if you trigger this case, the game runs for one extra frame than it should. Ends when it's 15 instead of 16. Close enough.
- Bridge 4 is impossible to destroy when it's in this state due to the playfield geometry. There's an island in the way and you have to do a tight turn before you can hit it.

Anyway it seems to work fine now, but want to test more. If I need to add the clear carry, it might involve swapping games 3 and 4 so I can squeeze another couple of bytes out of this routine. Possibly not an easy task.
Quote 2 0
BSS
The solution came to me while lying in bed. If I tell it to add 0, it will always add 1 and never skip the last frame. Make perfect sense.
fixed.png 
Another example of the many crazy ways you can optimise assembly. Crisis averted. 
Quote 2 0
Mar
Sounds completely logical to me! *cough*
Quote 0 0
bakersnarkMDW
BSS wrote:
The solution came to me while lying in bed. If I tell it to add 0, it will always add 1 and never skip the last frame. Make perfect sense.
fixed.png 
Another example of the many crazy ways you can optimise assembly. Crisis averted. 


Does this mean you saved most of those 9 bytes for additional upgrades and enhancements? I’ll start making a list!  😉
Random item from my Tabletop Games Collection
[image] 
See it & the rest here:
Quote 1 0
BSS
Took a look at the Starmaster cart today. There's a bunch of problems:

- As Marc predicted on the podcast, the screws might need to be drilled out.
- There's no Activision logo on the bottom.
- The dust cover poles aren't spring loaded.
- It doesn't actually smell like it came from a landfill.
sm1.png  sm2.png 
Was tossing up whether or not to bother with it. If I don't use this for River Raid, at least I'd have a Starmaster cart, right? It's a pretty good game. Problem:

- The game doesn't work. At least in the 128-in-1.

It's definitely clean on the inside. Though I notice the PCB is white, which I've never seen before. This cart has a HES label. Maybe it's fake? I don't know.
sm3.png 
Quote 0 0
bakersnarkMDW
FAKE!?
Who’d be taking genuine 2600 cartridge cases and putting their own dodgy boards inside? 😲
Random item from my Tabletop Games Collection
[image] 
See it & the rest here:
Quote 1 0
Mar
I heard on the grapevine ... that there's been some progress!?!?
Quote 0 0