Atari 2600 emu ramblings :)

Baggers

Thought I'd start a thread here, so we don't·hijack someone elses thread

Well, We've got a 6502 emu in spin, when I finish work on 10th · I'll make a start on converting it to asm.

Potatohead, Any further ideas on TIA? or do you want to attempt getting the driver sorted?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

potatohead

Good call on the thread. I was feeling guilty about the other one!

Yeah, I looked at the TIA last night. I think speed wise, we are ok with a coupla COGs, but it's not as simple as I thought! Lots of timing precise logic is necessary, even for very basic by the book displays. Those would be the early titles, COMBAT, ADVENTURE, AIR SEA BATTLE, etc... All of those are 2K and 4K of ROM.

There is the TIA emulated to very high precision in Stella. A lot of the work required is done there. Those guys worked from the schematics forward.

The 2600 is 1.1Mhz or so. That yields a few more decode instructions, and that's favorable.

Perhaps we should change the thread title too. If we've got a 6502, there are multiple targets. The VCS is appealing because everything fits into the Prop RAM easily enough. I've a few thoughts on that

-the Stella team renders to a frame buffer. Good news there is the 2600 is 160x180-200 resolution. More good news is most of the graphics are more like 40 or 80 pixels horizontally, with only a few unique colors per scan line. We are behind in the intensity department as the VCS has 8 levels, not a show stopper, but it will take some mapping. Seems like there are some options there, without having to do a full on 160 pixel frame buffer.

The other path, given a running 6502, is something like the Apple ][noparse][[/noparse]. It's only got a frame buffer, no interrupts either. All we would need is some address translation, to get smaller productions up and running!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

potatohead

From the other thread:

If you do, then we are off to the races emulation wise! PASM will nail it. Of that, I'm sure. Only need 1.4Mhz for a VCS.

Hmmm.... Some early 2600 / VCS games are only 2 & 4K of 6502 code. Wonder just how hard the TIA is to emulate... I know that's not a NES, but hey! Start somewhere, right?

From Baggers

Yeah, it's a start [noparse]:)[/noparse]
1.4Mhz = 17.14etc pasm instructions per 1 6502 instruction to decode.
at least with 2 & 4K of 6502 code we can use HUB-RAM for memory [noparse]:)[/noparse]
As for TIA, not sure, but I'm sure we'd have a few cogs left to have a good attempt at it lol

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

potatohead

I think a good first start would be to throw up a character mode display, get the 6502 core running, and do some simple stuff with it. I've got the 8x8 NTSC driver that basically is the same driver computer text displays used. I've an old 400 too. Could write the same code on both, run, benchmark, and verify it's actually doing what it says it's doing.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

Baggers

As for thread name can keep it as is for now til we have 6502 up n running correctly and at full speed.

As for TIA, could we have a cog generting scan lines, and reading 6502's port or ram addy, to build a small 160x8 scan line buffer, which the TV driver then decodes on the fly a scan line or a few behind, adding the sprites etc. and displaying? [noparse]:)[/noparse]

But yeah, for starters, lets get a display up and runnng first, and have the spin code 6502 core running exactly the same, as your 400, so we can test it's correctness first, then once we're happy with it's ability, then pasm it [noparse]:)[/noparse] and run the same tests again [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

potatohead

I'm liking that actually.

Did some digging, and the mess project has a core also, TIA, and 6522 RIOT chip, which could be used to do some sound for KABOOM!

A coupla scanlines behind makes a lot of sense. Basically, the TIA builds it's display a scan at a time. Display entities are sent to it, during the line, or HBLANK time. For the playfield, it can do some very basic stuff, like mirror. That stuff seems to be straightforward.

The trouble lies in the sprites. They are strips like the Atari computers are. That's cool. They don't work out of a RAM buffer, and instead get their data at the time it's needed from the CPU. Finally, to position them, cycle exact writes are often needed to accomplish that.

At least there is a body of existing code.

I'm also intrigued by that little c to spin proggy. Want to have a play with that to see just what it does. Could be very handy. -- No longer hosted there.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

Post Edited (potatohead) : 12/2/2008 7:41:27 PM GMT

Baggers

Yes, sounds good,

as for the cycle timing though, I've been thinking 6.3125 instructions at 80Mhz ( 7.575 at 96Mhz ) per pixel at 160 spanning the 50.5 us scanline, assuming 12 are the sync ( NTSC ) . that could be an issue, as it's 4 instructions per hub op. 2 for the hubop and 2 for the wait.

Yeah that C to spin might be handy, depends on if it's basic C to spin or complex C.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

potatohead

I'm gonna go collect some 6502 stuff. We need data sheets, and another core or two to look at. That one seems kind of goofy on a first pass. Also, the C to spin goodie doesn't seem to exist there anymore. Maybe it didn't work? LOL!!

You went right where I was thinking too. Not enough time in the scan to get stuff done. Gonna have to be rendered a few lines behind for sure, meaning at least two COG's for TIA. I think we are forced to render at 8 bits per color too. On the VCS, it can literally be any color, any time. Was thinking 4 colors per scan line, but then remembered lots of tricks... There is one for the background, one for the playfield, one for both sprites. That's 4, but other stuff can happen. That means the shorter, more intense wativid loop...

The 6502 will be doing stuff, right in the middle of the scan line, and when it does stuff, impacts where and what appears on that scan, and sometimes the next one. So no packing it in to the blanking time for the TIA.

I think it's easy enough to just make some target code that assumes a 40 byte text screen, number font starting right at 0, so the value $00 = "0". That's a coupla loops, jump, add, etc... Only a small part of the CPU, nothing complex. I'll start on that too.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

Post Edited (potatohead) : 12/2/2008 9:18:03 PM GMT

Baggers

What I was thinking was have another cog counting the Horizontal scan, and just getting input from the 6502, for mods to TIA at every scan pos, storing that into a buffer that the TIA renderer accesses [noparse]:)[/noparse] should be able to do something looking cycle perfect then [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

potatohead

Got it. ...I think. So, the CPU core outputs it's R/W state in the HUB, along with what's on it's BUS, for the TIA to read as it would from a regular old hardware BUS? There is a clock tick counter shared by all as well.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

Baggers

exactly [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

potatohead

Cool. On a non-multi processor system, this then would be essentially one big loop. Suppose it could be a coupla processes or threads also. Either it's fast enough, or it isn't. For us on the Prop, our constraint then is # instructions per clock, or the thing falls outta sync, as each thing runs on it's own.

On the 2600, we've got the 6507 variant, with a 12 bit address bus, the RIOT chip, and the TIA. The RIOT is where the RAM lives, and it's only got 128 bytes. That's it for system RAM. 4K addressable ROM. The RIOT chip does I/O for the controllers, and I think sound comes from the TIA.

Here are some document links:

http://www.qotile.net/minidig/docs/2600_riot_map.txt (there are no interrupts hooked up, and the interrupt bit on the 6507 is hardwired to be 0 no matter what)

http://www.zimmers.net/anonftp/pub/cbm/documents/chipdata/r650x/index.html

http://www.atarihq.com/danb/tia.shtml (TIA Info)

http://www.atarihq.com/danb/files/TIA_HW_Notes.txt (has great description of polynomial counters! Never knew why these were used. Now I do. They take the same number of cycles, every iteration.)

Found this also:

MOS 6507 1.19MHz

Television Interface Adapter (TIA or "Stella") 3.58MHz. This chip produces the video display and sounds for the 2600. It also has 6 registers which are used as A/D converters and for the trigger buttons on the joysticks. For those familiar with the Atari 800, this chip is about 1/2 of a TIA/Pokey in all respects. But, there is no ANTIC chip to drive it; the CPU must do all the work that the ANTIC does in the 800.

The TIA runs at colorburst speed. This makes perfect sense to me, given how Ataris generally display things. The CPU then is 1/3 of that. My gut says this is to give the TIA time to deal with what it sees on the BUS in real time.

I've collected the relevant goodies into the attached ZIP file, along with a few handy items from 6502.org.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

Post Edited (potatohead) : 12/3/2008 4:09:41 PM GMT

trodoss

@potatohead

Most likely you have most/all of this info by now, but just in case·here another site with 2600 specs/opcodes/etc:

http://nocash.emubase.de/2k6specs.htm

potatohead

That's an awesome link. I'm gonna mirror that, just in case.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

potatohead

My next step is to clean up my older speed test, and find it actually. That can be a drop in testing ground for the 6502. Text mode screen, with 8x8 font, nothing else. Makes for nice and easy debug. We can have the CPU write to the text screen, to see stuff. And have the actual state of the CPU display there as well. I'll attach that soon.

Got work to do today, so that's it for now. Just collecting some info.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

Baggers

nice work so far [noparse]:)[/noparse]
sorry I can't help much at the mo, mad busy with work [noparse]:([/noparse] xmas demo n all that lol

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

JT Cook

I did a C64 emulator a while back on the PC (never released) and one thing·that I found is every document on the 6502 has some difference on how an op code and flag is handled here and there. One thing I would recommend is checking out the source to VICE for the 6502 handling because I think it handles all the op codes (documented and undocumented) correctly. Also MAME's 6502 core is pretty good and I think that is what I mostly used when I had opcode problems to reference.

Speaking of undocument op codes, I don't know how much the 2600 games used them, but I know pretty much every C64 game did. I think the only thing that didn't the undocumented op codes was the kernal and basic roms.

potatohead

Jt_Cook, I do know many 2600 games use the undocumented ones as well. Lots of homebrew titles do anyway. Gotta work all the tricks on that machine.

Baggars, no worries man. I'm teeing things up for the work to come. Figured we could get a test environment up, driver, framework, etc... That's all stuff I know I can handle and I've got little bits of time to split between this and KABOOM! This is work I know I can do, so I'm gonna because there is work coming I can't do without some help!

From my understanding of the thread so far, having a worthy 6502 at speed is project #1. That's where the framework comes into play. A text display gives us a nice debug, speed test and such, with few hassles. Perhaps it's foolish, but I think working through a core to find if a COG can do it fast enough probably comes before tuning it to handle all the bizarre hacks that people code to that chip. Am I wrong on that?

Got a link to the MAME 6502 core files? Or... is it just go grab the whole thing and pick it out of the source tree? I built it once for SGI. It's HUGE!

Frankly, I'm kind of excited to plug away on something like this. I think it's gonna be fun.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

Baggers

Yeah, thanks, and yes, I know it's gonna be very intricate with timings etc once we start on TIA.
and project#1 is get the 6502 emu up to speed, well project #1 is get a test framework piece of 6502 that we'll be testing etc. then get the 6502 emu running that code [noparse]:)[/noparse]

I was gonna say the fact the background is 40 fat pixels is quite cool can use that to our advantage, but some games look higher res than that, they have title images, like garfield etc.
so maybe I'm missing some other mode lol need more reading, but that needs more time. oh well, soon be xmas lol

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

Dennis Ferron

Hey guys; I recently finished a project which connects a Propeller with a real 6502. It was my Propeller design contest entry, the PROP6502 Laptop. I'll be posting the code to the object exchange when I feel better (I'm home sick at the moment). It includes a Spin/asm object that spoon-feeds a 6502 at the bus cycle level. I'm thinking if I can make that object code-compatible with your emulator object, then we could test 2600 games on both the emulated 6507, and my real 6502 chip. It might help debugging.

I've separately been working on a rolling buffer TV driver. What that is, is it's an NTSC driver that takes its pixel color bytes from a line buffer which can be one line, or ten, or the whole screen. What you can do with that is declare a buffer size, say 10 lines, and fill up to line N+9 while the TV is on line N. That way there is some latency between the display line you are rendering, and the display line that is on the TV, so if you fall behind, the TV driver just consumes lines already rendered and you have some opportunity to catch up by doing the next lines more quickly. You could also double up certain lines, that is if you fall behind you could insert a record that indicates "don't move on yet; just display the previous line again" and then you could skip a line and render the next one.

That could be useful for your 2600 emulation because you could use the buffer to give you some breathing room; if some of the time your emulation takes a little longer to render the whole NTSC line than you actually have time for, you could still make up the difference in the next line. Or, say you can only achieve 4/5ths the speed you need, you could render 4 lines and double up the 5th.

AndreL

That's cool -- I made one too last year or so, basically a propeller GPU that you could talk to over a SPI/parallel bus, so one of my developers could experiment with the 6502, and different processors and have a nice GPU to talk to. Anyway, sounds good!

Andre'

potatohead

Here's the very basics.

Text mode screen, SPIN string compatible font, elementary clear screen and print at x,y routine, and some pointers.

I'm going to write a bit of simple 6502 code now.

My assembly hello world is almost always the number counter bit. It's easy, and it works nice with just a text screen.

On the test frame code, the upper left corner of a 40x24 text screen is @ $7bff, 6502 program @ $6000

"0" = $30 -- "9" = $39

That's enough to code something that will actually do something.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

Post Edited (potatohead) : 12/7/2008 8:05:37 AM GMT

potatohead

Dennis, that sounds really cool actually. Can't wait to see more about it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

potatohead

DAT

test_program

{ Program Origin $6000

                zero = $30
                nine = $39

              screen = $7bff

              numbers = $7cc7

        lda #zero               'get zero digit loaded
        ldx #8                  'we are gonna do nine digits
digits  sta numbers, x          'put them on screen, right to left
        dex                     'next digit?
        cpx #0                  'done ?
        bne digits              'no, continue writing digits to screen!

                                'yes, move on to counting on them....


'hand assembly until I get the 400 sorted, or DASM or something...
'this code is relocatable and simple, so it can be put right into the test proggy with no worries
'which is where it is right now!

}


byte byte  $a9, $30          '         lda #zero
byte byte  $a2, $08          '         ldx #8
byte byte  $9d, $c7, $7c     'digits   sta numbers, x    (check endian on this one)
byte byte  $ca               '         dex
byte byte  $e0, $00          '         cpx #0
byte byte  $d0, $f8          '         bne digits        (check branch offset)

Anyone care to double check me on the branch and endian order for the absolute, x instruction?

And if this is good, just copy paste into the main program DAT section, and we've got some baby test code to execute with an emulated 6502.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

potatohead

Here's the project with a baby, spud 6502. Just enough to execute the simple text proggy. It works! I was reading about CPU emulation last night, and just had to try a simple case this morning.

I think I'm gonna add enough CPU emulation to get digits counting for a speed metric sanity check in SPIN.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

Post Edited (potatohead) : 12/7/2008 7:45:45 PM GMT

potatohead

Here's one with a loop.

There are branch and addressing troubles. The thing never leaves the first digit. This is the one I'm hacking on right now, to understand how it all works. I'm going through the code and emulator to see where it breaks down. Clearly, fancy stuff, like clock step and CPU state on the screen come up FAST!

More of the CPU is emulated now. Enough to count up the digits displayed earlier.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

Baggers

cool nice start to it [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

potatohead

I missed emulating a whole instruction!! Worked fine after I popped that in. Spin is faster than I thought, but way slow still.

Here's the working test code case, and partial 6502.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

Post Edited (potatohead) : 12/8/2008 3:09:19 AM GMT

Baggers

attach the file [noparse]:)[/noparse] lol

strange, it's attached now lol

edit: cool, looks good so far [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite



Post Edited (Baggers) : 12/7/2008 9:53:54 PM GMT

potatohead

Yeah, I post first, then go back and deal with attachments. LOL It's habit, and I really should just hit the button for that.

@96 MHZ it takes close to 50 seconds to execute 500K instructions.

...so, we were talking, what 17 instructions to decode?

I'm looking at the SPIN, thinking through PASM. Gonna be close!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

Baggers

Yeah, I know it's gonna be close [noparse]:([/noparse]
considering you can only read a byte every 4 instructions.
96Mhz = 24 Mips
Now, our only saving grace, which I forgot, which should give us LOTS of time, is the fact that it's not 1 cycle per instructon [noparse]:)[/noparse]
Which makes things a LOT nicer, for 2cycle instructions, we get 34 instructions, and for 3 cycle instructions we get 51 instructions [noparse]:D[/noparse] happy days as they say...
although it'll be in LMM, we're gonna have to try and get MOST of the inner workings in local PASM.
So, for now, we get the SPIN version finished and working, then optimise the spin into a more PASM friendly way, then convert it to PASM.
Well, that's my thinking on it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite



Post Edited (Baggers) : 12/7/2008 10:03:20 PM GMT