[Gopher2600 - v0.26.1]

10 hours ago, JetSetIlly said:

I've added a new windowed interface to Gopher2600. This will form the basis of a new debugger. I've pushed the changes to the Github repository but not packaged a new release so anyone interested will have to compile it themselves. Go has a very good build system so there shouldn't be any problems if anyone chooses to do this.

 

The new interface is specified with a command line flag:

 

    gopher2600 -imgui <path to rom>

 

Screenshot below for people who do not have a Go dev environment or want to install one.

 

I've also added an audio silence detector, which helps with audio buffer exhaustion on slow machines (like mine ? )

 

Dear ImGUI... excellent !

 

[Sprite default horizontal position]

7 hours ago, stephena said:

If the glitch you mention is in the coloured bars in the Activision logo, then that's also happening on real hardware.  So Stella is correct here.

 

EDIT:  Looks like the Ball object is being rendered too late on those scanlines.

Thank you so much for the feedback. I'll forward your reply to the author of that ROM.

[Sprite default horizontal position]

2 hours ago, DirtyHairy said:

To add, no sprite is ever off screen. Each sprite is represented by a counter, and once it reaches a trip point, the sprite will draw. For real hardware, the state of the counters is undefined on startup. Writing to RESx will reset the sprite counter to a well-defined value, but even before that, the sprite will start rendering at the same color clock every line, although the precise value is undefined.

 

As SvOlli says: if you develop an emulator, it is best compare to the real system. Javatari is pretty accurate in most cases, but it definitely has some bugs, and even Stella has some known (and certainly some unknown) corner cases where emulation is off.

Thanks. I am testing against both Javatari and Stella. One of my test ROMs has graphical glitches on Stella which are not present on Javatari (https://javatari.org/?ROM=http://www.mousefingers.com/atari2600/2020.bin), so I wasn't sure which one was most accurate. I will continue testing on both though and investigate getting some hardware.

[Sprite default horizontal position]

4 hours ago, SvOlli said:

The position is undefined and varies from power-on cycle to power-on cycle, since the states of the TIA chip are not initialized. You can test this by turning the VCS on with no cartridge. There quite some variation on what the TIA displays.

 

But your approach on creating an emulator reminds me of what one of the developers of the Commodore 8-Bit emulator VICE told me once. He created a test case that worked on original hardware, but didn't in the emulation. The author of that part of emulation stated: "but every other emulator is doing it the same". The reply was obvious: "so every one else is doing it wrong".

Please when developing an emulator, try to emulate the original system. Emulating another emulator is not what you want, or is it? And if you need to take a shortcut for some reason, take at least the emulator that's by consensus the most accurate emulator available: Stella.

Thanks for the info. I only mentioned Javatari as that is the one on the 8bitworkshop site. I am also checking my work against Stella. I do not currently own any 2600 hardware, but if I were to buy one how what would be the best way to run my own code ? Some sort of eprom cartridge ?

Thanks.

[Sprite default horizontal position]

Hi. I'm writing my own 2600 emulator and I'm using the tutorials on 8BitWorkshop.com as test cases so I can see if my emulation is matching Javatari. I have an issue with the tutorial in chapter 8, color sprites. In this code the horizontal position of P0 is never set, yet in the emulator it appears half way across the screen. In my emulator, since the horizontal P0 position is never set, P0 is currently off-screen.

So my question is... what is the default horizontal position of the hardware sprites if you don't actually set them ? Is this documented anywhere ?

Thanks.

[2600 palettes in rgb format]

Nice. Thank you !

[2600 palettes in rgb format]

Hi. I'm writing a 2600 emulator and I'm looking for rgb values for the palettes the machine used. I know I should probably work them out with luminance and value etc. but I just want some quick rgb values to throw in for now so that I can see if my TIA emulation is working sensibly.

 

Thanks.

[Instructions affected by BCD]

Thank you

[Instructions affected by BCD]

I'm writing my own 6502 emulator and was wondering which instructions are affected by Binary Coded Decimal. Is it just ADC & SBC, or do INC, INX, INY, DEC, DEX and DEY obey BCD rules when the flag is set ?

Thanks.

[Reset vector with 2K ROM]

Wow. Some good tips there. I learnt to program the 6502 on the C64/128 when I was a kid. Used to do demo's and rip games apart etc. The only other asm I've done is a couple of years coding 68K on the MegaDrive. The 2600 is quite a challenge after 20-odd years of making games with higher level languages and tools. Absolutely loving getting back down to the metal again. Makes me feel like a big kid .

[Reset vector with 2K ROM]

Ah, that explains it. Thank you

[Reset vector with 2K ROM]

Hi, as I understand it when the 2600 is powered on the PC is set by the reset vector, which is held in ROM memory locations $fffc & $fffd. But when a 2K ROM is inserted the ROM only reaches up to $f7ff. When I look at the hex dump of Combat I can see the reset vector ($f000) in locations $f7fc & $f7fd.

 

So does the reset vector location depend on the ROM size or am I missing something ?

 

Thanks