Learning to accept Atari quirks

[+rbairos]

other - put the missing signals out through the cartridge port. That would allow for adding RAM without having to repurpose an address line as the read/write line, and make implementing things like DPC+, CDF, and BUS much easier as you could look for the correct signals instead of trying to recreate them by monitoring changes in the address lines.

 

After experiencing the quirks of atari programming for last two or three weeks, Ive come up with a magical wish list for fun.

Let's see if I get this poll option working properly..

 

 

Edited January 11, 2018 by rbairos

[vidak]

If I'm being totally honest, I don't actually have any wishes for any more hardware improvements to the 2600. Hahaha. The limitation is a really nice challenge, and in many ways the 2600 really does take care of some of the most difficult stuff for you.

 

More sprites would be nice, but you really can cheat your way out of that issue.

 

Ah! I just realised what I'd improve. More RAM, and bigger supported ROM sizes than just 4KB - although bank switching isn't really a big issue...

[+rbairos]

True enough,I wouldn't change it either, as the whole art is to create within the constraints. But it is a fun exercise enumerating all the strange little limitations and short-cuts they took.
I just added a few more.

Edited December 6, 2017 by rbairos

[+SpiceWare]

other - put the missing signals out through the cartridge port. That would allow for adding RAM without having to repurpose an address line as the read/write line, and make implementing things like DPC+, CDF, and BUS much easier as you could look for the correct signals instead of trying to recreate them by monitoring changes in the address lines.

[+rbairos]

other - put the missing signals out through the cartridge port. That would allow for adding RAM without having to repurpose an address line as the read/write line, and make implementing things like DPC+, CDF, and BUS much easier as you could look for the correct signals instead of trying to recreate them by monitoring changes in the address lines.

Yah for sure. I got that one as "C/S and/or R/W lines brought out to the cartridge." That's probably the one that's most chintzy since it wouldnt have cost them much to expand the cartridges by one row (two edge paths).

 

[ZackAttack]

Halt 6507, take over write signal, update TIA COLUBK register every pixel, game over.

[+SpiceWare]

I got that one as "C/S and/or R/W lines brought out to the cartridge."

 

Doh! Don't know how I missed that.

[ZylonBane]

I assume "Automatic HMOVE strobing" is your inside-out way of listing "Horizontal position registers".

[Omegamatrix]

I'm torn between a Z register, a third sprite, and a full playfield. I voted for a full playfield because in a lot of situations you don't have time to update it. This is especially true when you are bashing RESP0 and RESP1 over and over in the kernel to make multiple copies.

 

While we are dreaming, I would also like a register bit to toggle between playfield modes setup as it is now (using PF0, PF1, and PF2) and the proposed full playfield (using five eight bit PFx registers).

 

The Z register would be super cool if it could support fast 2 cycle transfers like:

TXZ

TZX

TYZ

TZY

Transfers between index registers = me happy.

 

And then:

TZA

TAZ

 

TSZ

TZS

 

Also it would be desirable:

ldz (zp),Y

lda (zp),Z

lda zp,Z (as well as INC, DEC, ADC, etc..)

[+rbairos]

I assume "Automatic HMOVE strobing" is your inside-out way of listing "Horizontal position registers".

I've been reading TIA manuals too long.

 

[ZackAttack]

Pixel clock that is 2 CPU cycles wide​ means the clock for the 6507 is the pixel clock divided by 2 instead of being divided by 3 like it is now right? In other words the 6507 is clocked 50% faster.

 

You're also missing a superscalar 6502 with L1 cache. I'm sure some out of order execution would go nicely with timing critical memory mapped I/O.

[+rbairos]

So given the original chipset, is there any configuration that would have resulted in more performance? (besides bus signals to cartridge)

Could it have a faster crystal and the timing loops adjusted accordingly?

[+SpiceWare]

Could it have a faster crystal and the timing loops adjusted accordingly?

Yep, here's a test of clocking (a newer) CPU at the same speed as TIA, resulting in 228 cycles of processing time per scanline.

[JeremiahK]

It's hard, because some of these could be helpful only sometimes. For example, having full 40-bit playfield control would be nice, until you want to do a simple mirrored playfield that only takes one or two writes. And having 2 color clocks per cycle would make kernel timing easier, but it would cut the horizontal resolution from 160 to 106.

[JeremiahK]

How about a built-in random number generator? Now that would be nice!

[bogax]

other - put the missing signals out through the cartridge port. That would allow for adding RAM without having to repurpose an address line as the read/write line, and make implementing things like DPC+, CDF, and BUS much easier as you could look for the correct signals instead of trying to recreate them by monitoring changes in the address lines.

 

I wonder how hard it would be to infer/reconstruct R/W from what you see on the busses (ie with something far short of a full processor)

I mean (disregarding branches and page crossings for a moment) if you know the instruction you know what R/W should be for each cycle.

I don't think it would be too hard to sync to instructions, a read or two from a specific address maybe.

So the question in my mind is can you reasonably accomodate branches (still only two possibilities) with what you can see on the

data and address busses. (I think I could live with out page crossings but if you could accomodate them too it would be nice of course, but I think

being able to deal with branches would be a neccessity)

Even if you could only count on your inferred R/W for a short stretch of code before you had to resync it would be very useful.

[+nanochess]

A 6502 running at 1 cycle for each instruction would allow me to do a lot of the other things suggested at the pool

[DirtyHairy]

 

I wonder how hard it would be to infer/reconstruct R/W from what you see on the busses (ie with something far short of a full processor)

 

 

The real prize wouldn't be reading the R/W line, but writing it. As ZackAttack wrote, you'd just do a WSYNC to get the 6502 off the bus; after that, you could write to the TIA without any restrictions for the rest of the line, updating it every color clock if you like.

Edited December 9, 2017 by DirtyHairy

[+rbairos]

Has anyone ever been tempted to run a couple lines from the cpu (W + RDY) to say a 1/4" stereo jack out the back. Then make a cart with a coily cable you plug into this 'mega turbo booster' for fun?

[+rbairos]

Occured to me a combined 4 cycle Load + Store opcode, as opposed to LDA, STA, etc would be handy and quite used.