bigmessowires

Thanks all. I'm actually not looking to build an Atari cartridge, but just to understand how the RAM's write enable signal is generated for Atari cartridges with on-board RAM. From having looked at this a while back, I remembered that it was possible, but not the details of exactly how it's done. The ASCII schematic of E0 bankswitching has the answer, if you stare at it long enough. Basically you need to create a monostable multivibrator that's normally high but outputs a short low pulse whenever there's a rising edge on one of the address bits (or on a combination of address bits AND-ed and OR-ed as you desire). You can adjust the capacitor and resistor values to get a specific pulse length, then use this pulse as your /WE signal. This guarantees the /WE won't be asserted until a short time after the address bits have settled, and that it will be de-asserted before the address and data change again, assuming you've tuned the pulse width correctly. For anyone who's curious, my actual goal is to support in-system programming of a flash ROM SIMM in a 68K Macintosh, where there is no /WE signal present at the SIMM socket. I hope to use the same technique as these Atari cartridges do to repurpose one of the address bits as /WE for the flash.

Great, yes this is more like what I'm thinking of. I'll look at this in more detail. Thank you!

Right, that's true from a programmer's model. But from a hardware designer's perspective I'm pretty sure that more is needed. In that diagram if you used A4 directly as /WE, then you would have the address bits changing simultaneously with the /WE signal that latches them, leading to data corruption. It would not meet the RAM chip's hold time requirement on the address bits relative to /WE. For an example of what I'm talking about, look at this bank-switching cartridge design. This isn't external RAM, but it's somewhat similar. The resistor and capacitor that are connected to 74LS04N in the center of the schematic are essential for making it work. They add some amount of delay to the CLK signal for the 74LS174N, so the rising edge of the clock won't happen until a short time after the address bits change, instead of simultaneous with the address bits change. Without that RC delay circuit, this design probably wouldn't work. But an external RAM has a level-sensitive /WE signal, not an edge-sensitive clock input like this bank-switch circuit. I believe it needs some kind of circuit element that drives /WE low a short time after the address bits change, then after a delay, drives /WE high before the address and data change again. Basically it needs to guarantee that address and data are stable for the whole time that /WE is low. If there's an old cartridge design with RAM that's been reverse-engineered, or a new cartridge design with RAM that's open source but doesn't involve a microcontroller, I could look at the schematic to see how exactly it generates the /WE signal for the RAM chip.

Thanks, I do understand about splitting the address space, but I'm wondering specifically how the write enable signal for the RAM chip is generated. Is there a schematic I could look at? Maybe I'm wrong, but I don't think it could be as simple as OR-ing and AND-ing some address bits together to make a write-enable signal. The required timing for /WE relative to the address and data wouldn't be met. I'm thinking there must be some kind of delay built-in to the circuit that generates /WE for the RAM chip.

Because the CPU's R/W signal isn't exposed on the cartridge connector, cartridges with RAM need to fake it and synthesize their own /WE for the RAM. How exactly is this done? Are there schematics of working solutions? I don't think it would work to use an address bit directly as /WE since I don't think the timing of when address bits change relative to the data bits would be correct for RAM writes. I'm thinking it would need a delay circuit of some type, maybe an RC circuit controlled by an address bit. I swear I once saw a schematic of such a thing, but now my searches are coming up empty. Thank you!

This should probably go without saying, but just in case: Did you actually develop Atari games in the 1970s and 80s? Did you work on Kaboom, Basketbrawl, and Miner 2049er? How much of the text in your first post is correct and how much is fiction?

Ah, I found it.

There was a post 1-2 months ago here at Atari Age, with a ChatGPT-generated alternate history of Atari emulation and homebrew game development. It sounded very convincing, and mentioned a few prolific posters by name, even though the facts it described were quite wrong. I can't seem to find that post now. Does anyone remember what I'm talking about? Thank you!

Are you familiar with fixed point numbers? This method is using a two-byte fixed point counter (Vpos_hi and Vpos_lo) to step through the lines of the logo. As you've found, you can't use an integer step size, or else the final logo height will always be some multiple of the number of lines in your logo, and you can't get smooth scaling. You could extend this technique to a three-byte fixed point counter with one integer byte and two fractional bytes, and a two-byte lookup table to match, and it should be 100 percent smooth. If you have enough CPU time, you could also replace the lookup table with a software division subroutine.

The example code I posted works, but the final height of the logo is inversely proportional to Vpos_scale. So if you change Vpos_scale linearly like in my example, the logo height changes non-linearly, and it looks a little strange. Here's some code that corrects for this by changing the logo height linearly, and using a look-up table to determine the right Vpos_scale value needed to get the desired height. The logo doesn't scale quite as smoothly at large logo heights though. I think you'd need to go to 8.16 fixed point format to get totally smooth scaling using this technique. vscale.dasm

What kind of effect are you trying to create? I looked through the code, but couldn't really understand what's intended. Are you hoping to smoothly scale the text in the vertical dimension to any arbitrary height? I might suggest keeping a vertical coordinate in 8.8 fixed point. On every scan line, use the integer part to index into your logo data, then add a fractional delta value. That should enable you to get smooth scaling without jumpiness. Here's some untested code: lda #42 ; change this value for different scaling sta Vpos_scale lda #0 sta Vpos_lo sta Vpos_hi ldy #192 Count ldx Vpos_hi lda Logo,x sta PF1 sta PF2 lda Vpos_lo clc adc Vpos_scale sta Vpos_lo lda Vpos_hi adc #0 sta Vpos_hi dey sta WSYNC bne Count

These are all great ideas! Was a 1.79 MHz clock possible at the time? I would have assumed Atari went with the fastest CPU they could get, but I don't know what the incremental cost would have been for going faster. If they increased the speed they would have needed a faster spec'd PIA as well as faster 6507, not sure about the TIA. Including the R/W signal at the cartridge connector seems like it should have been a no-brainer if Atari could have anticipated future technology trends, and would have cost them virtually nothing in manufacturing costs. As I understand it, the cartridge connector already has every address signal the 6507 offers (A0 through A12), so it wouldn't be possible to add more unless you also replaced the 6507 with a 6502. The 4K limitation comes from the 2600's memory map, which defines anything with A12=1 as ROM and anything with A12=0 as either TIA or PIA. To free up more address space for ROM, the Atari would need more complex internal address decoding logic for both the TIA and PIA. And the designers were probably trying to shave costs on that. But the extra logic could have been something as simple as an extra OR gate. How about this idea: The PIA has two 8-bit bidirectional I/O ports. In normal use PORTB (SWCHB) is configured as eight inputs, but only five are actually used for the console switch inputs, so there are three PORTB pins unused. These could be configured by software as outputs, and routed to the cartridge connector to be used as additional optional address signals. For only the cost of routing three extra traces on the PCB, Atari could have provided built-in 8-way bank switching by writing to SWCHB with mask X X B2 B1 X B0 X X. I checked the data sheet to confirm that writing to PIA input registers has no effect, so this would be perfectly safe. You wouldn't even need pull-up resistors for B2,B1,B0 to handle the start-up condition before they were configured as outputs, because PIA inputs already have a weak pull-up. It's perfect!

I'd never say no to more RAM! But so far, I've been surprised that RAM isn't the major limitation that I imagined it would be. The main challenge is not enough time during a scan line to do all the things I'd like to do, and especially not enough time during HBLANK to update TIA registers without creating visible glitches. Imagine if all the color and graphics register updates could be optionally delayed until the next HBLANK period... that would be sweet.

After experimenting with 2600 programming for a while, I have some hardware wish-list items for an "Atari 2600++". These are extra hardware features in the TIA or 6507 that I think could have been do-able with only a modest increase in hardware cost and complexity. Think of these as ideas for what Atari and MOS might have done if they'd had a slightly bigger budget. What else would you add to this list? TIA CDELP0/CDELP1 - Like VDEL, but for player color changes. PF3 and PF4 registers - With five 8-bit playfield registers, you could have an asymmetric playfield all the time! COLUM0/M1/BL - Independent colors for the missiles and ball. Or at least one extra color, applied to all three. LINENO - A hardware line counter, resets during VSYNC, increments after every line. XP0,XP1,XM0,XM1,XBL - A direct way to set the X position. I understand TIA implements these as LFSRs and not standard binary registers, but even if we had to use a table lookup to get the necessary LFSR value, it would be so much nicer to stuff in an X value than to suffer through RESxx and HMxx and HMOVE. 6507 ADD/SUB - Add or subtract without carry (add) or with carry (sub). Avoids needing to CLC/SEC everywhere. mem.A address mode - Variant of INC/DEC/ASL/LSR/ROL/ROR that operates on memory but also leaves the new value in the accumulator. The existing instructions already have to load the value from memory anyway, and modify it, so why not stick the value in A while also writing it back to memory? STZ, INC/DEC accumulator - these were all added in the 65C02

The title screen music is amazing! It makes me want to keep playing just to hear it again.