TailChao

The "eventually whenever" feature of supporting all SOUPER variants (SOUPER, SUBPAR, and SUBLET) found its "whenever" last Saturday. Both SOUPER and SUBPAR are pretty close to what was already implemented in 0.9.6.1, but SUBLET's flash programming features are all there - and it has an SST39SF040 attached! Which means... ...this is the first time I've seen the FoxBIOS (manufacturing test program) update an R12 build of Rikki & Vikki to R14 on Windows. Any cartridge which has a Flash ROM attached won't push written changes to the ROM upon removal of the cartridge or closure of the program, this is intended to protect the original data. However, the changes will be pushed in save states. When I add support for EEPROM or NVRAM devices in the next whenever, these will have their contents pushed to disk.

If you mean effects found by experimentation, no. Nearly everything was "paper computer'd" and then implemented as-is, the assets had to all follow a schedule. The only sequence which had any effects or animation tests done for it was Eternal Misery (last boss of the co-op campaign), since I needed to figure out how many drawings I could actually fit in memory and how fast new texture sets could be moved in between phases.

It was overall fine, and I mean that quite as-is. Most of the nice features in the architecture come with an asterisk, but that's fairly common for when it was made. There were no hideous issues in developing the software or our custom hardware for the cartridges - the biggest limit was the budget we had to work with rather than the console we were targeting. More cycles for Sally would have been nice, but what we got isn't horrible. Having worked with all three of the NES, SMS, and 7800 trifecta - Atari's wedge didn't feel out of place or out of its league. So the base unit's design is okay. However, I don't think the available designs for the 7800's cartridges were very good. They made the numbers go up, just not in a way which gives a helpful boost to game software. Maria's architecture was fun to work with, but she is also minimalist to a fault. Her lack of rendering features (no flipping, no mixing, no priorities, no no no) severely impact what you can achieve - she's only good at one thing (drawing wide, arbitrarily positioned objects) but can do this extremely fast. This also makes her benefit far more from increased texture memory than the NES or SMS since you get way higher performance by not tiling your visuals. Our SOUPER mapper was designed to plus this and the upcoming PMC1 further nudge it. The hardware's minimalism was a repeated encounter, not in a bad way either. Moreso I was always surprised it was able to do so much with so little. This made writing the emulator much easier - it took around nine days to get Rikki & Vikki to run, starting from zero. But I don't remember much of those nine days. Mode 320B fit well with my preference for resolution over color count, Rikki & Vikki's visuals were all stylized around this, favoring animation and good movement in the characters rather than detailed backgrounds. As I've written before, I still believe much better can be achieved on the hardware. The only things I found unsatisfactory relative to its contemporaries were the build quality of the units and design of the controllers. Hmm... that's about it.

That'd still be 170 unique Display List Lists - so you could at least use it for a portion of the display. Using individual Display Lists for most of the game screen would get around many of the Holey DMA restrictions too, you'd have better clipping granularity. But at that point our "Maria Assistant" would have to be something like a Super FX or SA-1. Of course, that's still within reach - even if it's a bit high The 512 byte size is listed in the old Atari manuals for both Display Lists and Display List Lists. I haven't verified whether it actually exists for either.

Yes, and this is exactly the approach I've gone with for the upcoming PMC1 mapper. It's not as elegant as having a full scroll assist as described above - but you can at least unroll a new background while nudging the current one, and the DLX / DLY viewports make that very easy. Here's the thing about that restriction, it's considerably difficult to reach. Each entry is (at least) four bytes and takes eight cycles to parse, you're going to run out of render time on the current line before you hit 512 bytes of Display Lists. Both this and the similar restriction on DLLs have been on my testing list for awhile because of this. They're just so far out there in normal use.

No problem, and since I wasn't just late to the party - but completely missed it, let's rewind for a bit... You can't make Maria render any faster, but you can prepare her consumables to reduce overhead and a mapper can help with this. Splitting Display Lists into separate regions which can be manipulated individually (i.e. a background and foreground) is a plus, much faster than doing it all in software. The biggest assist would be a mapper which could follow Maria's parsing and either replace the lower bits of or perform a full add with each Display List's X-Position entry. This way you could more easily unroll an entire screen of Display Lists in normal (non-character) mode and nudge it horizontally with zero overhead. Yes, I believe it's feasible to have 8-way scrolling in 320B and still knock out a reasonable framerate. But it's not trivial. Yes.

This requirement appears to have originated purely from Maria's access timing and what memory grades were affordable. Maria reads Display List data pretty quickly for 1984 - and the internal SRAMs are both 100ns to accommodate this. The Mask ROMs on the cartridges were likely far slower. Considering most SRAM and NOR Flashes you can purchase nowadays are usually 70ns or less - it's no longer a requirement. There's been more than a few releases which put Display Lists in both RAM or ROM on a cartridge.

Okay, good to confirm it. This is one of the reasons I'd like to get configurable RAM reset patterns in there eventually. As of writing it's fixed to a very rude pattern which may be familiar to 3DO programmers - but allowing for all zero, all high, or something which approximates the hardware would be nice. In other news, I've implemented everything in the most recent PMC1 feature set aside from the actual SPI devices which can be connected to it. The BupChip commands have also been added and are slightly changed from SOUPER's to allow for 128 music tracks instead of 32. Depending upon how thoroughly this gets vetted prior to release it may be a "secret feature" but it's at least included.

Bruce Tomlin's 7800sign agrees with you, so another mystery solved.

Nope, that's NTSC. I investigated a little more this morning and found the game would run properly if all RAM (both in the cartridge and console) was initialized to zero. However, it wouldn't run at all if the NTSC (Atari Rainbow) BIOS was executed first. Using the PAL (Asteroids) BIOS would result in the game starting, but still with garbage. I'm not sure why the NTSC BIOS execution handoff isn't working, but there's definitely an initialization problem here.

Fantastic, another Atari wedge back in tip-top shape. Reminder for anyone planning on ordering - make sure the address you enter in PayPal's checkout system is written clearly and correctly. I mentioned this earlier in the thread, but we've gotten two orders with mangled destinations in the past few weeks. If we catch it then you'll get a confirmation email asking for clarification, if not your package could get lost - especially if it's going overseas. Check your spam folder for messages from a PenguiNet address, yadda yadda. This way we can ensure your copy of the game arrives and arrives soon.

Meanwhile, in other hardware configurations not used by the commercial library - EXRAM is now supported for 32KB cartridges in both A78 and CDF format. In previous implementations only EXRAM/A8 (used by 'Rescue on Fractalus') was allowed for this cartridge type. As with BupSystem's SUPER implementation - declaring your software in a CDF allows specifying the EXRAM size from 2KB - 16KB while A78's are always assumed to have the full 16KB. This at least allows @PacManPlus's old Defender demo to load albeit with a bunch of garbage in overscan. Addendum : Does any other software use this configuration, or is Defender the only one?

...and again! No register or feature changes, but I got the SPI Controller to operate at exactly PHI2 (1.79 or 1.19 MHz) instead of (PHI2 / 2). So one byte every eight clocks, which is faster than most arbitrary unrolled copies like... LDA SPI_DATA ; 4 STA SPI_DATA ; 4 STA (GLO_PointerA),Y ; 6 INY ; 2, 16 ... ...but if you're banging SPI_DATA (for example, seeking within flash memory), you'll still need a nop or two.

It could be any number of things, which calls for the obligatory - if you continue to have trouble contact us and activate the warranty card's secret powers. We've yet to meet a console that can't be coerced into running the game properly.

Huh, looks like the horizontal sync is spazzing out. RF is composite with more junk in the signal, so the differences you're seeing are likely from the leveling in the composite mods or in the television itself. A Dutly Discount, if you will. F5 = Flame Cavern, Floor 5 Don't forget - there's over 100 screens of Misery Land in each cartridge.

Unfortunately due to an increase in the cost of international postage, we can no longer offer the same shipping rates to customers in Canada and Mexico. The new shipping costs are as follows. Domestic : $5.99 International (Canada) : $19.99 International (Mexico) : $21.99 International (Everywhere Else) : $24.99 I've updated the first post's FAQ to reflect this new pricing - thanks for understanding. Don't forget, we also offer a digital version which is currently on sale for only $1.99 until April 8th - no shipping required!

...and after a week, I've nudged some things around. In particular, Maria's paging has been repartitioned as follows. ; | $xx00 | $xx40 | $xx80 | $xxC0 ;--------------------------------------------------------------------------- ; $00xx - $3Fxx |........................................................... ;---------------|----------------------------------------------------------- ; $40xx - $4Fxx | EXRAM (4KB, EXRAM_V_SEL) or DLM (4KB, DSX/DSY + BGL/FGL) ;---------------|----------------------------------------------------------- ; $50xx - $5Fxx | BGX_C | BGX_D | BGX_E | BGX_F ;---------------|----------------------------------------------------------- ; $60xx - $6Fxx | BGX_A | BGX_B ;---------------|----------------------------------------------------------- ; $70xx - $7Fxx | BGX_W ;---------------|----------------------------------------------------------- ; $80xx - $8Fxx | BGR_W ;---------------|----------------------------------------------------------- ; $A0xx - $AFxx | CHX_C | CHX_D | CHX_E | CHX_F ;---------------|----------------------------------------------------------- ; $C0xx - $CFxx | CHX_A | CHX_B ;---------------|----------------------------------------------------------- ; $E0xx - $EFxx | CHR_A | CHR_B ;--------------------------------------------------------------------------- That should work a little better. CHR_A, CHR_B, and the new BGR_W are still restricted to the first 512KB of the 2MB ROM, but I've moved their registers around to leave space for an upper byte to make this future-extendable - right now they're constrained due to gate count. Rest I'm still okay with. EQU_PMC1.asm

Yep, the useful range for unaligned graphics is effectively $A000 - $AFFF, $C000 - $CFFF, and $E000 - $EFFF. That's still 12KB of space, though.

Option a) is a little easier, for each bank you can do something like this... SEG OBJ_STAGE_F ORG ADDR_OC_STGF,EMPTY_FILL RORG BANK_SWAP ;------------------------------------------------------------------------------- BANK_THIS SET BANK_OC_STGF INCDIR "./SUB/OBJ_Over" INCLUDE "ANI_OverMis.asm" INCLUDE "OBJ_OverMis.asm" INCDIR "./SUB/RBX" INCLUDE "ANI_Fiddler.asm" INCLUDE "OBJ_Fiddler.asm" INCDIR "./SUB/RMX" INCLUDE "ANI_Launcher.asm" INCLUDE "OBJ_Launcher.asm" INCLUDE "ANI_Pipe.asm" INCLUDE "OBJ_Pipe.asm" INCLUDE "ANI_Laser.asm" INCLUDE "OBJ_Laser.asm" INCLUDE "ANI_Sentry.asm" INCLUDE "OBJ_Sentry.asm" INCLUDE "ANI_FoxBot.asm" INCLUDE "OBJ_FoxBot.asm" INCDIR "./SUB/OBJ_Glue" INCLUDE "ANI_GoodEnd.asm" INCLUDE "OBJ_GoodEnd.asm" BANK_USED SET (* - BANK_SWAP) ROM_USED SET (ROM_USED + BANK_USED) ECHO "[OC] OBJ_STAGE_F :",BANK_USED,(BANK_SIZE - BANK_USED) REND Where BANK_SWAP = $8000 (start of bank from Sally's view), ADDR_[NAME] is the start of the bank in ROM, and BANK_[NAME] is the bank number. The value of BANK_THIS is changed at the start of each bank definition so that any object code will use this instead of a fixed bank number. This makes it easier to "defragment" objects later on.

...and now it's in for 0.9.6.2, triggered by Shift + Pause. That wasn't too bad!

After providing support for the mapper for around a year - I've gone back and rewritten the equate file to cover all three variants and contain tips based upon common questions. It's also been reformatted to allow easier comparisons with the upcoming PMC1. The mapper documentation in BupSystem's HTML Help will be updated accordingly in the next release (0.9.6.2) and I've also attached the equate to this post. I may add support for all three variants in either this upcoming release or a future one since it'd be nice to have the flash programming mode in SUBLET fully replicated. Phew! EQU_SOUPER.asm

Nice work so far! It does - the players are two overlapped 32x32 draws and the enemies are usually distributed in order to reduce the bandwidth requirements. While there's only 2 - 3 of them onscreen, they're also very wide and the game allows the player to mess with the stage geometry. Do you have the resources available to unroll the maze and ditch character mode? Most of it is static. I'm not super familiar with the XM, but going by what's here... you could pre-render the whole maze as a huge texture in the XM's RAM and just split it on the color transitions between the dots and outline. Then whenever the player eats the dots just clear them out.

Pausing was added in the last few weeks, so I'll stick frame advance on the todo list. Maybe Shift + Pause to trigger it? The only catch is that the audio might drift out of sync if you use this feature for a long period of time (i.e. step through hundreds of frames). But unpausing will snap it back into alignment.

Agreed. While I do like the crispness of S-Video, abusing NTSC smearing is a blast. I thought everyone had gotten the CRT photos out of the way 20 pages ago, but hey - whatever. Here's some more Linytron.

I've mostly settled on a feature set for PMC1, so it's attached here. While SOUPER was intended to be minimalist and allow easy migration of software using Atari's mapping scheme, PMC1 is designed specifically to address what I feel are shortcomings in the hardware and falls roughly between MMC3 and MMC5 class. It also contains a few "looking forward" features with an intention to be expandable, but remain compatible (i.e. it'd be feasible to do a PMC2 which adds new knobs and dials but remains compatible, or cut off things you don't need to make a PMC1-micro). If the partitioning seems a little confusing, it may be helpful to think of Maria's graphic fetches as $VVUU (or $YYXX) from a giant texture which is all of memory. This is why some elements are subdivided on A7 or A7 + A6 borders. The SPI Controller has been added since it's significantly cheaper to use 3.3v SPI Flashes + SPI Level Shifter and pull data into EXRAM rather than expanding the size of the NOR Flash. You can drop a 16MB SPI Flash on there easy and store all your graphic data or stage maps on there, it can also be a little simpler than converting everything to 3.3v - it's nice and isolated. Please note this is a draft specification. I've written the Verilog and will add this to BupSystem for 0.9.6.2 - but are in no rush to finalize it. As stated before, "eh, maybe by the end of the year" is my timeline. If there's anything you feel would plus this feature set, let me know and I'll see if it's feasible. EQU_PMC1.asm