Jump to content

Shawn Jefferson

Members
  • Posts

    2,047
  • Joined

  • Last visited

  • Days Won

    1

Shawn Jefferson last won the day on January 5 2011

Shawn Jefferson had the most liked content!

1 Follower

About Shawn Jefferson

  • Birthday 12/22/1973

Profile Information

  • Gender
    Male
  • Location
    Victoria, Canada
  • Interests
    Atari, Karate, IT Security, vintage gaming, old british cars (MGB)

Recent Profile Visitors

21,509 profile views

Shawn Jefferson's Achievements

River Patroller

River Patroller (8/9)

296

Reputation

  1. Let me know how it works for you. You can use these commands to save, restore and quit. Don't try to use anything else. save restore quit
  2. Thanks, I did get this part connected and thanks to Bob Wooley I also got the machine functioning for the most part. Except: the 1200XL donor keyboard is suffering from the typical mylar issue, I need to get a replacement the speech synthesis isn't working, I get an error 138 when I try to test this. I haven't really done much troubleshooting on this issue yet, as I'm not sure where to look first. I am running the 800XL OS ROM in this machine, that wouldn't cause this issue would it? I had assumed that the handlers for V: are being done through the PBI interface. (V: handler does appear to be present when I run SI on this machine.)
  3. Maybe if it's all written in assembly, but Frotz is in C, and yea, it compiles to well over the 64k range just out of the box with no OS interaction routines. The other "problems" are: The Z-machine is actually a virtualized hardware machine with it's own opcodes and memory space. As I mentioned this can be 128k, 256k, or 512k depending on version. Some of this memory is "dynamic" so really must be in RAM somewhere, this can be up to 64k if I am reading the standard correctly, although in practice is probably much smaller. The rest is static and code, so can be loaded off disk (making of course, the virtual z-machine memory access more complicated and your main code larger). The z-machine also has it's own stack for routine call addresses and local variables, this is in addition to the z-machine memory and must be somewhere in RAM as well. On the Atari the extra ram banking area is very large, 16k, and that is right in the middle of the memory map ($4000-7FFF), so you have to be very careful with code placement when trying to use banked memory. Your main code cannot be in this space if you plan on accessing that extra memory from that code, or once you bank out, your program crashes. The Ozmoo team solved most of these problems on the C-64, so it's possible for sure. I don't have the expertise, or interest to port that, but hopefully someone else does and will do it. The C-64 has more usable main RAM typically, so any Atari port is likely to need to start very low in RAM ($400 or lower, which means probably no DOS), and use the RAM under the OS as well. I suppose you could juggle around the extra RAM banking area, but it's complicated (16k hole in main memory), where-as the REU on the C65 only uses a 256 byte bank window (I believe).
  4. I did think of writing a VBXE version as well, but that would be a way off... let's just see if the thing will even work at all.
  5. Hi, I've seen it, but it's written in assembly on the Apple, which puts me way outside that venn diagram that Wrathchild posted. Maybe someone with Apple knowledge will port it at some point, but it won't be me unfortunately.
  6. I've been thinking over the years of trying to port Frotz like I did Moria, and did some hacking around tonight. I quickly commented out the picture and sound code just to see how large the executable would end up being, and it's going to be much larger than can fit into the Atari memory, so I think if I continue this I will target a cartridge instead. I think that it's the only way to port Frotz with most of the features (excluding sound and pictures). So the idea is: port the Frotz code to run out of cartridge with banking where necessary allow a DOS boot so disk access is possible load the story file into extended memory (V3 files can be 128k, V5 can be 256k, and V6+ can be 512k) Still need to "cc65-ize" the code fully and write the os_* functions to write to the screen and other hardware to even see if it will run at an acceptable speed and how much optimization is needed. Hopefully someone will port Ozmoo, as it sounds like a more elegant and optimized program for the 8-bit computers.
  7. Posting up a Shadow World score so at least can get on the list! What do you do when one of the pods is able to land? I haven't figured that out yet.
  8. Didn't get a screenshot, and need to practice some more, Twerps: 414. Update, 591.
  9. Gave it another crack and improved my score slightly!
  10. I think I'll get last place sewn up! 36,845 is my highest so far. Playing on real hardware (600XL with video port added, 64k upgrade and Ultimate 1mb), running through a retrotink to the LCD.
  11. Hi, yes, the 1400XL MMU is different from all the others. It's close, but not quite the same. I have looked into using a GAL, and the TL866 programmer, and that looks like a good option, but without knowing if I have an actually good set of equations (or a dump of the Atari part) I don't think it will help me much. I had someone else program the PAL A and PAL C chips for me (actually two different people just to make sure)!
×
×
  • Create New...