7800 - what did Atari wrong?

[7800 - what did Atari wrong?]

13 hours ago, splendidnut said:

I believe Rikki & Vikki was developed specifically for the 7800 hardware first... The Steam version of the game is actually running the game in a 7800 emulator developed by the game creators specifically for assisting with developing the game and the new bank-switching hardware it uses.

That's the simplified version, below is the director's cut.

 

When Rikki & Vikki's development began it used Atari's mapper with 16KB of EXRAM. After working with this configuration for around a month or two I designed SOUPER based upon what features I thought the hardware needed to run the game software well - and also what could be added to each cartridge at a reasonable cost to the end user. I did a very dirty hack of SOUPER support without BupChip audio into ProSystem 1.3 and used it throughout 2015.

 

BupSystem's development was kicked off when Rikki & Vikki transitioned from just a demo to full production in 2016, for the following reasons...

1. Unlike the Genesis or NES, the 7800 userbase is too small to move the number of units required to pay for another game - we needed digital sales.
2. ProSystem's emulation of Maria's timing was not very accurate, which was a huge issue for gauging what we could and couldn't pull off.
3. The organization of most 7800 emulators at the time didn't reflect how the hardware actually worked, in particular having two bus controllers and cartridges which are aware of HALTn's state.
4. We needed an emulator core which was easy to interface with Steam and migrate to other platforms.
5. I wanted an architecture which made drafting new mappers very easy in case we continued with the hardware after Rikki & Vikki.
6. I wanted software which works on Windows 95 <-> Windows 10 with minimal fuss.
7. I did not want to deal with any licensing issues in a commercial product.
8. I did not think this would be too problematic to write, and we could reuse many of the required libraries in pure Windows games.
    

 

12 hours ago, 8th lutz said:

Harvey also had issues with Rikki and Vikki before his comment.

I actually don't disagree with what he said. This was brought up in the actual Rikki & Vikki thread, but keep in mind the game was our first time working with the hardware and was built around optimization techniques and visual aesthetics I thought of over a decade ago while skimming its manual. There is far more which can be achieved with this little Atari wedge.

 

We were primarily limited by the monetary budget, not the cycles or bytes. The game had to ship by a certain day and many of our decisions were made around this restriction. If you look at many later NES or Famicom titles such as Super Mario Bros. 3, Kirby's Adventure, Ufouria, or any of Konami's stuff - these reflect several years of working with the same platform and refining techniques.

[Video Game Critic reviews Rikki & Vikki]

Huh. I've been on hiatus from the boards, but this was brought to my attention as a problem. So here I am.

 

I have zero issues with this review, the Video Game Critic paid for their copy of Rikki & Vikki and can have whatever opinion they like about it. If we had given them a free cartridge in exchange for a lengthy article - then this would be a complication. But that wasn't the case.

 

Is longer and more detailed feedback preferred?

Sure, but it's not required.

 

What's written is enough to indicate aspects of the game they enjoyed and didn't. I'm certainly not going to complain about getting high marks either. If a player only trots through the first ten minutes of a game but really enjoys it, that's fine.

 

 

Considering the issues we had getting any coverage for Rikki & Vikki, having a short review is better than nothing - even a bad review is better than nothing. Any sort of visibility is a huge deal. We had a bump in sales after this review went up, so I'm quite happy it exists at all.

[Spire of the Ancients (WIP)]

What happens when you disable the colorburst mid-frame isn't going to be consistent across all sets.

 

I'd put this in the same category as the rapid flickering techniques to get more colors I see around here : not recommend, but if you want to do it - do it and put a warning in the manual that it might not work with certain setups.

[Dragon's Cache - Vs. Puzzle Drop Game - Now Available for Purchase!!!]

5 hours ago, Revontuli said:

@TailChao I appreciate your recent help and info in these threads (and awesome work in general)! - let me know if there's anything you might want me to test on my end.

Thanks, and no problem.

 

I think your current recommendation of having testers ensure the high score screen works on their consoles is best for now. Even if it's a happy accident - that's still the behavior which emulators should replicate. But the high score screen getting stuck thinking it's been spuriously paused is a little suspect of an incorrect read, write, or mask which happens to work.

[7800basic, under the hood]

I'm not a 7800basic user, but some general stuff for unrolled Display List techniques like this...

 

Quote

I've also used this extensively with Millie and Molly to render the entire screen as tiles ie, blocks, ladders, dirt, monster animations (excluding the players which are overlaid). Essentially the screen is laid out like a map and then you can update co-ordinates (tiles) with the new image pointer.  On top of this you can overlay sprites each draw but you will still eventually run out of draw time if you draw too many. 

Using only 4-Byte Display Lists and grouping your tiles together into larger draws when they're both sequential in memory and share a palette makes the fillrate go way, way, way up. Then you'll have more time to draw foreground items or have Sally actually run the game.

 

 

Quote

I also think this would potentially be a great engine for a flick-screen map game - including animated tiles (16x16 probably recommended).

You can also use it for scrolling by having your unrolled background drawn slightly larger than the visible screen. Nudge your tiles each frame the camera moves while unrolling the Display Lists for the next coarse "step" left or right.

[Dragon's Havoc - Shmup-In-Progress [UPDATE: Demo available!]]

While the hardware test already went through...

 

On 5/19/2020 at 7:54 AM, Revontuli said:

The video capture seems to have not captured the full framerate - I'm using flicker for the projectiles, rendering half of them every other frame, so there are roughly twice as many projectiles during actual gameplay, at least in emulation - I'm curious to see how this looks on physical hardware.  MAME A7800 seems to stutter every few seconds, while BupSystem and RetroPie have a nice, steady framerate that makes the projectiles look OK.

...I have a possible explanation for this. Hardware tests have shown Maria's NTSC timing is 263 scanlines long, which causes her rendering to be slightly slower than the 59.94 or 60Hz used by most other consoles or computer displays. BupSystem keeps the 263 scanline length but artificially cranks the speed up to a fixed 60Hz so there's less chance of tearing or skipping.

 

So A7800's speed is likely correct, but your computer's display is off sync from its updates which causes the stuttering.

[Dragon's Cache - Vs. Puzzle Drop Game - Now Available for Purchase!!!]

On 5/29/2020 at 3:17 AM, Revontuli said:

Emulators seem to have an issue with the high score screen - notably this is one of the few places where I modified existing assembly code, and didn't stick with 7800Basic.  MAME A7800 seems to still work, though, and for the moment that's the emulator I'm ultimately using to test compatibility with hardware. BupSystem is much easier to install, but it (and ProSystem) have odd glitches with the high score.  I'm not sure of the exact sub-emulator Retroarch uses, but it seems to run the game pretty well.  

 

All that said, I'd ask anyone playing on a 7800 right now to let the "attract mode" of the title screen and high score board cycle, and try to get back to the title by pressing a button in the high score screen.  It seems to work on MAME, but that's likely the most vulnerable place, code-wise.

So, @RevEng contacted me regarding this issue when it first popped up. At first I thought it could be an issue in either my RIOT implementation or how the controllers themselves are interfaced with it and the TIA.

 

BupSystem drives all the controller inputs high or low depending upon if a button is pressed (which is how my adapters and some other controllers work). The joystick on an actual ProLine leaves the inputs open or shorts them to ground depending upon its position. Some software uses really bogus AtariVox / SaveKey detection which doesn't account for an input stuck high or low, which can happen with either style of input but is more easily triggered with the former.

 

I watched what Dragon's Cache was doing in terms of setting up SWCH(A/B) and SW(A/B)CNT to see if there was anything off there - it looked okay. But I didn't investigate what it was doing with any of the reads. Leaving the High Score screen by pressing [PAUSE] bothers me since this could be caused by either a fault in the emulation or a happy accident in the game which still works on the hardware and A7800.

 

As of writing I don't know which it is

 

 

12 hours ago, AW127 said:

Thanks for explanations. Because of the highscore problem, it could maybe also not be a bad idea, to get in contact with "TailChao", the BupSystem programmer, and tell him, what "Dragon's Cache" technically does in that problematic moment (you, as the programmer, are the best person for that, cause you exactly know it) and that "BupSystem" has a problem with that and then hangs.

BupSystem's development is on hiatus, but I'm still keeping a tracker. Any issues should go in its thread.

 

[Rikki & Vikki]

On 5/18/2020 at 6:53 PM, Giles N said:

A bit hard though, and I’m used to GnG-arcade or on the NES... 😎😋

Rikki & Vikki is difficult and while I'm severely biased as its lead - Ghosts 'n Goblins is entirely its own echelon of cruel. Ghouls 'n Ghosts is much closer to the tuning here.

 

4 hours ago, Mayhem said:

Still need to get around to this, but bills bills bills... hopefully won't sell out. Any chance of a stock update?

There's 83 copies left, moving at a fantastically medium speed. But once these are gone the digital version won't be .

[BupSystem]

Oh hey, it's BupSystem v0.9.6.3

 

"But wait, I thought you said this wasn't going to be released until 6/5?!" you shriek, or fervently type.

"Software can only be late, what is this nonsense?!"

 

Ah, well for one I ran out of small things I wanted to patch. The second reason is that today marks four years since BupSystem's first (albeit secret at the time) release - so let's celebrate by pushing this build now. Anyway...

 

What's new in this version?

• Added
  • Separate menu item icons for Aero themes.
  • Support for using the menu in Full Screen Mode.
  • Optional confirmation when erasing the cartridge history.
  • Multiple file support for Drag 'n Drop.
• Cleanup
  • All menu item icons redrawn in monochrome.
  • Custom images are a little more considerate of system metrics.
  • Disabled menu items could still be triggered in Full Screen Mode using their accelerator keys.
  • Adjustments in the Color Dialog are now shown whether or not a cartridge is loaded.
  • Disabled mouse cursor autohiding while the Color Dialog is visible.
  • Corrected longstanding GDI Resource leaks in the Input and Joystick Disconnected Dialogs.
     

While there's still a long way to go in terms of accuracy and other improvements, I feel what's here is enough to justify a long hiatus from the platform.

[DMA Masking - an alternative to modifying CHARBASE when vertically scrolling]

10 hours ago, RevEng said:

A variation on your interrupt method, that occurred to me today... instead of hitting a the palette registers when you're at the desired scanline, you could write a zero-terminator over the first object in that bottom zone DL. (and then restore it later) That would work better with higher color modes.

Untested (I'm sticking with dma masking) but I don't see why it wouldn't work.

It should be fine - as long as the write makes it in. Maria walks the Display List each active line.

 

Three options, now

[JS7800: Atari 7800 JavaScript Emulator]

Always nice to have more options for emulation - and hey, this one's cross platform out of the box.

Great work!

[BupSystem]

16 hours ago, AW127 said:

Ah, okay. But it sounds like there is a chance that this will probably come one day. Would definitely be great .

That's going to be the case with most improvements or new features. I'd like for most requests to go in - as long as they don't conflict with what's already there and (in this case) be configurable. It's really a question of when.

 

 

16 hours ago, AW127 said:

What you think about it? It would be better for users without a G-Sync compatible monitor, than always switching the Hz-value in Windows, before starting "BupSystem", even when my two mentioned NirCMD-links in the taskbar makes theHz-switching much easier than going all the time into the monitor-settings of Windows and change the Hz-value there. But when "BupSystem" could do it by his own, it would be even better. 

I'll look into it, since having this as part of my render library would be nice. But it's a low priority. I did get the autohiding menu in Full Screen Mode working as part of 0.9.6.3, which would be a prerequisite for this feature.

[BupSystem]

7 hours ago, AW127 said:

(1) would it be technically feasible, that "BupSystem" identifies a game-rom in the moment it loads, if it's PAL or NTSC and then switches automatically in the correct console-type (NTSC/PAL) without that the user must do anything?

This is feasible, but is in the same category as overscan where I'm only going to add the behavior when it's fully user configurable. So I can't nudge this into 0.9.6.3 but it will be added to the first post's grocery list.

 

Whenever the advanced options dialog shows up it'll be in there - with the asterisk that only *.a78 format cartridges will support automatic region selection.

 

 

7 hours ago, AW127 said:

(2) and would it be, additionally to point (1), also feasible, that "BupSystem" then also switches in two different fullscreen-videomodes, depending if its a PAL or a NTSC rom? And these fullscreen-resolutions, the user had chosen before in the emulator-menue.

 

I ask because of that - some users have a monitor which can handle 50Hz modes (for example my "BenQ BL912" flatscreen monitor can) and such a 50Hz mode is ideal for PAL games, cause the run with 50FPS and then the scrolling looks very smooth in games which scrolls. And for NTSC games a standard 60Hz fullscreen-mode is ideal, cause they run with 60FPS.

Ah, you mean different Full Screen Exclusive modes.

 

The requirement for these has (mostly) been eliminated through things like NVIDIA's G-Sync, which now supports Borderless Windowed programs like BupSystem. I'll confirm it actually syncs for PAL / 50Hz when I have access to a friend's (better) PC next weekend - we tested it in NTSC / 60Hz and it works great.

[BupSystem]

...and what would new features be without new mistakes.

 

Just found out I was drawing the menu item icons out of spec, which worked for classic Windows but resulted in broken alpha on anything which supports Aero and has it enabled (Vista+). So I'm gonna toss together two sets of icons for both scenarios (you can even be extremely rude and change it while BupSystem is running).

 

 

If you do heavy customization of your Windows themes or use a really crazy DPI setting the icons may be disabled to prevent distortion of the images. Also added some more warning prompts before erasing the cartridge history, etc.

 

Thought I was gonna get to take like a year off from wedge development, but I'll try and put together a new build for 6/5/2020. As usual, any other reports (especially for the interface) would be appreciated.

[Third party controllers for 7800]

1 minute ago, SmittyB said:

Don't bother spending anything more than pocket money for one unless you're looking for something official over something good. Being from PAL-Land my 7800 came with the pad and I'd rank it about equal to the Master System controller which, if you've never used one, is also not great.

I'd honestly rank ProPads below the Master System controllers because of their wiiide button spacing.

 

Additional DIY options are the ProNES and ProSMS adapters I designed awhile back - I used the former through most of Rikki & Vikki's development (then gave them all away) and the latter since.

[Rikki & Vikki]

8 hours ago, davidcalgary29 said:

That's awesome. I know this hasn't turned out the way that you'd hoped, but I hope you sell out of the rest quickly. I bought another copy a few months ago and sent it off to a friend across the country who just bought a 7800. What a showpiece for the system!

I hope so too - gotta use all these shelves to catalog my toilet paper hoard.

 

Again, despite the poor digital sales it has been really cool to see the game recommended as part of a 7800 starter pack - or sell the console outright to players who would not have considered it before.

[DMA Masking - an alternative to modifying CHARBASE when vertically scrolling]

There's even bigger gains for this approach if you're not using character mode and want to keep your background drawing generic.

 

Another method which favors low color modes (320A / 320B) is the following...

1. Don't modify the height of the last visible DLL region in your playfield - as with the DMA Masking technique.
2. Trigger a DLI on the entry before this, then WSYNC into your fine scroll offset.
3. Zero all the palette registers.

 

You'll lose cycles in the opposite direction here, and there is some risk of jitter since Sally is responsible for making the change. But since there's only a few registers to change the noise isn't much worse than the status bar divide in Super Mario Bros 3 or Kirby's Adventure. This is one of the reasons I dropped a raster comparator into a mapper, which drops the requirement for the WSYNC step.

[BupSystem]

Oh hey, it's BupSystem v0.9.6.2

 

What's new in this version?

• Added
  • Upgraded to Visual C++ 6.0 SP5 + Processor Pack.
  • Optimization now favors Pentium Pro.
  • EXRAM support for 32K cartridges.
  • SUBPAR and SUBLET variants of SOUPER cartridges.
  • SST39SF040 (512KB NOR Flash) for SUBLET cartridges.
  • Cartridge type guessing when loading Binary Files (*.bin).
  • Sorted history of recently played cartridges and persistent file filters.
  • Execution pause, resume, and frame step.
  • Menu item icons.
• Cleanup
  • Sally's clock multiplier was accidentally grouped with save state data.
  • Rendering is now skipped when a cartridge isn't running.
  • Moved console region selection into its own menu.
  • Changed default cartridge format to Atari 7800 File (*.a78).

 

Most improvements were in the interface or under the hood, getting Flash ROM (!) support in there is a big deal and there were several other alterations pertaining to long term maintenance and simplifying new mapper development. The Visual C++ 6.0 SP5 + Processor Pack upgrade was quite nice, despite the executable growing by several tens of kilobytes (oh my!) it actually runs faster - did exactly what it said on the tin.

 

Draft PMC1 support is included (basically everything from the previous posts), but as of writing isn't documented - I'd like to wait until the hardware has been verified and released before "formally" adding it. But you're welcome to give it a try!

 

 

What's next?

I'd like to finish PMC1 support by the end of this year, then go back to analyzing Maria's timing and try and get this downpat and thoroughly documented. The two actually go together well since the PMC1 is designed to be more observant of Maria's bus activity than SOUPER was. As of writing, most of my reverse engineering efforts are going towards other hardware.

 

Everything else, sometime whenever later... no idea...  bla bla.

[7800 Qix]

Never tried the A8 version, but invested a good amount of time in the NES and 5200 versions.

 

12 hours ago, bizarrostormy said:

The NES version is 159x159 and fills fast with the same 6502. (I don’t think the PPU can help with this stuff but am not certain.) So it’s not just the resolution.

The PPU has no fill or copy features, additionally VRAM can only be accessed outside of active scan. So their update routine is pretty quick - you can actually see it filling in the carpet patterns tilewise instead of linewise as in the 5200 version. Everything here is very well thought out.

 

Rendering both the playfield and QIX in cartridge memory kinda trivializes it, especially as the QIX itself only moves by drawing new lines and erasing old ones. So Atari's standard mapper would actually work fine - all the assets are aligned to DL regions. You could then overlay the marker and sparx with usual Holey DMA draws.

 

Of course, if you want to cram everything in a ROM-only cartridge then it becomes a challenge

[BupSystem]

Cross posting from twitter-twatter, but draft PMC1 support is all set for v0.9.6.2 - including some SPI Devices. As noted previously, this may remain a secret feature if I don't verify everything in hardware prior to release. But this is also the last new feature I wanted to include.

 

You'll be able to instantiate a PMC1 cartridge by writing a CDF, here's an example with two SPI Devices attached...

ProSystem		; Platform
PMC1			; Mapper
THE 100 MEGA SHOCK	; Title
Primary.bin		; Binary

SPI DEVICE (S25FL128P)	; SPI Device A
Resources.bin		; Secondary Flash ROM

SPI DEVICE (M95512)	; SPI Device B
Save.eep		; EEPROM Save Data

CORETONE		; Uses BupChip
Samples.smp		; Sample Package
Macros.ins		; Instrument Set
Track_0.mus		; Music Tracks
Track_1.mus		; |
...			; V

 

The Primary ROM on all PMC1 cartridges is assumed to be an AS29CF160T, you can unlock and write to this but the changes won't be pushed to the original file.

 

SPI Device support is limited to the S25FL128P (16MB Flash) and M95512 (64KB EEPROM), you can attach them however you like in the two device slots as shown above. Devices are always attached in incrementing slots (A, B, ...). Using the SPI DEVICE (EMPTY) keyword will leave a slot open - and both can be left unoccupied by leaving out the SPI DEVICE definitions. Same for CORETONE, it can be excluded if unused - as in SOUPER cartridges.

 

Going to take a break for awhile before packing this version up, but it's nice to have all the additions checked off.

[Handy Music instruments on WhiteLynx.fi]

4 hours ago, Turbo Laser Lynx said:

Ah, too bad. But since you say "not easily" I guess it's still possibly possible I'd need to experiment at some point, perhaps it's possible by just creating fast arpeggios. But I have a feeling there's some other parameter(s) that change while the sound is playing too to create that distinct sound, and not only changing notes.

You can change just the frequency, or both the frequency and and amplitude. Doing both can help avoid a grating telephone ring sound.

 

The example Karri gave above would work, but both frequency offsets wouldn't be consistent along the entire scale. You can get away with this depending upon how wide of a frequency range the instrument is being used with (some NES games do) - but this is a shortcoming in all the drivers I wrote. You'd usually want a table with your scale and detuning by a few cents.

 

 

4 hours ago, Turbo Laser Lynx said:

Unfortunately I don't properly understand how sounds are created (or the parameters that create sounds) on the Lynx, or how those "fake chords" / fast arpeggiating sounds are "properly" created on any system. I'd need to look into that and/or ask around if a chip musician could explain it a bit.

Yeah, I like chipper because it's quite fast creating small songs with the the tracker/UI, but HandyMusic seems nice since it uses less space and the instrument creation seems fairly straight forward in comparison. Perhaps creating sounds / instruments in chipper is easy too if you know what you're doing. I wonder if there's some documentation or tutorial(s) somewhere on how to create chip sounds. I know it involves changing different parameters of the sounds "on the fly".

Another option is to use a visualizer and observe what other games did, techniques used on the NES, SMS, MSX, etc - are all applicable here.

 

HandyMusic and its SASS language were derived from my experience working with Atari / Epyx's sound tools, which are not very well known. Using something closer to MML might have been a better choice. I'm hesitant to say the tools should be used as any sort of reference since I last used them over half a decade ago and remember more than a few poor decisions in the driver structure.

[Rikki & Vikki]

AAAaaaaaahhhh!

[Rikki & Vikki]

Me neither.

 

Anyway, we're down to the last 100 copies of the Atari 7800 version. If you've been holding off on ordering it might be time to reconsider.

[Handy Music instruments on WhiteLynx.fi]

7 hours ago, Turbo Laser Lynx said:

Would it be possible to translate for example this nice sound from Chipper to Handy music?

Not easily, the HandyMusic driver was never designed for arpeggios like this. So I recommend sticking with Chipper's native driver.

[Handy Music instruments on WhiteLynx.fi]

Hah, I thought some of the instrument names looked familiar.

 

The layout of these pages is really cool - having a script above a little play button was where I eventually wanted to go with the tools. Thanks so much for putting this together!