Sprite default horizontal position

[FizzyChicken]

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.

[JetSetIlly]

2 hours ago, FizzyChicken said:

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.

 

It is set implicitly as part of the CLEAN_START macro.

[+SvOlli]

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.

[DirtyHairy]

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.

Edited January 23, 2020 by DirtyHairy

[FizzyChicken]

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.

[FizzyChicken]

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.

[+stephena]

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.

[DirtyHairy]

1 hour ago, FizzyChicken said:

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.

As Stephen says: Stella is correct here. If you want to use something web based, try Stellerator (see my signature), it has the same TIA core as Stella and offers comparable accuracy.

[DirtyHairy]

1 hour ago, FizzyChicken said:

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 ?

You can get a Harmony cartridge or UnoCart for running your code; both are cartridge emulators that run ROMs off a SD card.

[tokumaru]

2 hours ago, DirtyHairy said:

You can get a Harmony cartridge or UnoCart for running your code; both are cartridge emulators that run ROMs off a SD card.

Cartridges that boot into their own software (e.g. when accessing external storage, configuring FPGAs, displaying menus, etc.) before running your code are useless for testing the boot up state of the machine, though. For those cases you do need an old fashion socketed EPROM/EEPROM/FlashROM cartridge and an EPROM programmer. EPROM emulators are also a thing, but those are harder to find.

[FizzyChicken]

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.

[+SpiceWare]

13 hours ago, tokumaru said:

Cartridges that boot into their own software (e.g. when accessing external storage, configuring FPGAs, displaying menus, etc.) before running your code are useless for testing the boot up state of the machine, though.

 

You can flash a ROM image directly onto a Harmony cart using the Development tab:

 

 

 

Doing so removes the Harmony Menu, allowing you to test the 2600's startup state. Once done you'd use the BIOS Update tab to restore the menu:

 

[tokumaru]

Awesome! The Harmony cartridge is more versatile than I thought! Thanks for letting me know!

[+SvOlli]

The "direct flashing" is together with Harmony specific "ARM" cartridges the most noticeable difference between Harmony and Uno.