Jump to content

x=usr(1536)

Members
  • Content Count

    3,140
  • Joined

  • Last visited

  • Days Won

    3

x=usr(1536) last won the day on April 2

x=usr(1536) had the most liked content!

Community Reputation

6,410 Excellent

2 Followers

About x=usr(1536)

  • Rank
    River Patroller

Profile Information

  • Gender
    Male
  • Location
    913 S. Broadway, Los Angeles, CA 90015

Recent Profile Visitors

13,493 profile views
  1. We're on the same page about that Understood. I'm just not seeing the advantage to having a separate upgrade specific to the 600XL when a single box could do it all. We're in agreement on the idea, just not the approach 😁
  2. I'm not 100% certain that this is correct - my understanding is that RAM on the PBI bus will disable internal RAM, which means that all 64K on-board the 1064 will be used. Please tell me if the following makes sense or not; I'll freely admit that I'm not always the sharpest marble when it comes to the deeper workings of hardware. The 600XL - by default - can address 64K of RAM, but only use 16K of it. This is why it is necessary to modify (with jumper wires) the 74LS158 and 74LS51 that handle memory multiplexing on a machine receiving an internal 64K upgrade: yanking the 16K RAM ICs and replacing them with 64K RAM ICs will work, but you'll still only be able to use 16K of RAM. WRT the 1064's internals, I'm using this picture for reference: The two columns of ICs on the left appear to be for address multiplexing, while the two columns on the right are the RAM. If the 600XL was internally-capable of using all 64K without modification, the entire addressing section on the 1064 would be unnecessary, as would two of the 4864s in the RAM section. However, that would also make the 1064 a redundant peripheral, since the upgrade it provides would be able to be done internally from the start just by replacing the 16K RAM ICs with 64K RAM ICs. The 1064 appears to be (effectively) replacing the 600XL's on-board RAM and multiplexing logic with its own. In a way, it's as though it was grafting the equivalent of that section of an 800XL onto the 600XL, which is kinda nifty. If I'm wrong on any of this, I'll happily accept corrections. Like I said, I'm not the world's smartest hardware inner-workings guy.
  3. I understand what you mean by this, but with a 1064 you still lose 16K 😜 Being serious, though, any memory attached to the PBI will effectively disable the on-board memory, at least from my understanding of how the PBI works. If this is correct, then there's no way around it - you have to replace the base memory regardless. You're not really losing anything by going the PBI route since it wouldn't have been available in that case anyway. I'm not sure that I understand how this doesn't create two memory expansions: one to bring the 600XL up to 64K, and another to work with both the 600XL and 800XL 🤷‍♂️
  4. Every time we get a rehash of events, another 7800 dies. 👼
  5. Folks, I just want to clarify something: I'm not proposing a starting score other than zero. The bonus for starting at a higher level would only be awarded when the level is completed. No freebies; the player has to work for it 😁 As for the weapons and artifacts, @-^CrossBow^-'s idea of picking up the more powerful versions as you play through the level is a good one, though I'm not sure how many levels of difficulty it would take to reach the tipping point between 'this is hard but getting better' and 'yup, I'm dead'. As for the artifacts, I have no really good idea on this one either.
  6. More like the latter, but not exactly. Let's say you start on level 3. Your score still starts at zero, but on completion of the level you receive a bonus of, say, 50,000 points or similar. The bonus could even be linked to the starting difficulty, so completing level 3 at Hard would yield a higher bonus than at Easy or Normal.
  7. Nice! Looking forward to seeing how that shakes out. Which leads me on to my next point, which will probably be incredibly obnoxious in light of the above 😜 What about tweaking this a little bit so that if you complete the level, you receive a bonus for jumping ahead? Same idea as Star Wars, Tempest, etc. used, essentially. (And I get it - space is tight. If something is doable, great; if not, no biggie 😁 )
  8. I understand the points that you're raising here. However, there's something I'm not totally clear on: If I'm following correctly, what you would like is a PBI-attached 64K memory expansion with PBI passthrough - like a 1064, but in a smaller form factor. From there, subsequent memory upgrades could be attached to the PBI port of that device to expand beyond the stock 64K. Is this correct? Tell me if this sounds correct: what you are essentially describing is a 64K 'shim' upgrade that would sit between the 600XL and a Universal memory upgrade offering considerably more memory that would work on an 800XL (or, presumably, an XE with ECI port). That shim upgrade wouldn't be required for any machine other than the 600XL. Am I headed in the right direction? If I am correct, there are two issues that I can see with doing this: Having stacked PBI devices - even small ones with passthrough - will extend the depth of the 600XL past where an 800XL would end, negating any space savings. While the Universal memory upgrade would have a potential market of every PBI- / ECI-equipped machine, the 64K one would only be useful for 600XLs. They're a much smaller slice of the market, so the 64K shim device would likely be disproportionately expensive when compared to the Universal upgrade offering way more RAM. What I'm wondering is if it might be possible to have something similar to @tf_hh's 576K upgrade, but connected to the PBI slot. In all use cases, it would disable internal RAM regardless of size and provide 64K of base memory with 512K of extended RAM that could be paged in and out as necessary. This way, there's only a single device needed for external RAM upgrades. Should help with pricing as well as compatibility.
  9. Well... I think you may be right 😉 Not sure how it happened, but despite keeping the images in separate directories, it appears as though I still managed to load the wrong ones. Double-checked with the correct ones, and, yep, can't get past the disk swap. Not now 😁 Apologies for the confusion.
  10. Right, understood 😁 What I'm not grasping is why the changes that are visible in the DD version (slower animations, for example) aren't visible in the SD version.
  11. My fault; somehow I managed to miss both of those. Doing a quick comparison (shasum -a 256) of the SD disk images from this version and the previous one I was using: 4f4c63380ae728eeb27853e60a37e665d2745e25c3764ef37e6d7f7ac67b85d5 PoP_SD_A_20210610.atr 45346d1bafcc44b2050c985558273fbd66051801a2988330d03ab2c87c3349d0 pop_SD_A_DLiTest.atr 29088021d27904e1678b87d2b2bf51dbc4bfe2fc0535b3e30fdb696aa9163312 PoP_SD_B_20210610.atr b0ac5949509eb31582100fb5bc7f06824d9e1470661a829ac9a1d8fb32bca2eb pop_SD_B_DLiTest.atr It's clear that the disk images aren't the same, but given the differences in behaviours between the SD and DD DLI test versions, were all of the changes incoporated into the DD version also applied to the SD version?
  12. Here's what I've seen so far: Double-Density: Booted successfully once from FujiNet, BSOD on next boot (though dancing girl was still dancing for a time after the BSOD before freezing), third boot was successful. Power-cycled computer between all attempts. Dancing girl and mouse loading animations are slower than in previous releases (not sure if intentional or not) No response to fire button / console keys / keyboard during demo mode, so can't start game Single-Density: Booted fine from FujiNet 3 times in a row Dancing girl and mouse animations are at same speed as previous release (i.e., faster than the DD version) Fire button is read correctly, so disk swap and game start proceed as normal
  13. Now that I look around a bit, there does seem to be a larger than usual case of The Ass going around the forums at present.

    1. Cebus Capucinis

      Cebus Capucinis

      I'm doing my part as best I can!

  14. AAfter leaving the attract mode running for about 20 minutes or so, the game has crashed on a loading screen. This time it's the mouse, and the animation is with the mouse looking left (viewer right).
×
×
  • Create New...