Shawn Jefferson

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

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.)

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).

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.

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.

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.

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.

Twerps, 1251

Didn't get a screenshot, and need to practice some more, Twerps: 414. Update, 591.

This game is rough.

Last try, 42615

Gave it another crack and improved my score slightly!

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.

Best I could do so far, 38300..

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)!

The system seems quite stable when playing Star Raiders or Star Raiders 2, and I can let the memory test run for a long time with no change. There is another ROM chip, but all those devices in the 1400/1450XL are all PBI devices, so I don't think this ROM comes into it (and least not yet). The more I think about it, the more I am thinking its something to do with the PAL A (MMU) chip that I attempted to program from the equations. It's similar to that in the 1200XL and the 800XL, but not exactly the same. Although it seemed like so much of the machine is working properly, with banking ROMs in and out that it's a bit confusing. Maybe Bob Wooley would dump the PAL A chip like he had done for the PAL C, I'll have to PM him, as he seemed like the only person with the board and the capability to dump it.

Thanks, I found the Atari PDF on Freddie and see it's controlling CAS/RAS generation from address lines. I guess it may still be the issue for me, perhaps. The MMU in the 1400XL is the 61919 (PAL A), that certainly could be the issue since I was not able to source that chip, or get a dump of the official chip, and tried to rebuild it from the original equations (see the thread below). I'm not sure how that could be the issue with the things that are working though? The most likely scenario is that I've screwed up the equations of that PAL A chip somehow, but very strange with the way things are working if that is the case.

I'm using CO61598B, which is the single chip OSROM, and I've swapped it out, it doesn't seem to be a problem with the actual OS ROM, and to get the system to even boot into self-test and diagnostic carts it would have to be working somewhat. I also was able to get SALT2.05 on my Atarimax flashcart and verified that C000 and C0001 have the correct checksum values. I don't see how it could be the OSROM, or the socket, since data bus lines and address bus lines would have to be working just to get this far? I haven't swapped the MMU (freddie) out, since I don't have a spare, and likely any chip in my 130XE or 65XEs would be soldered in, and I'm not sure I want to try desoldering it. I could get another one from Best maybe. Do you think the symptoms I'm seeing here would indicate a problem with MMU? I'm not sure what the Freddie MMU does exactly? PIA I've swapped out and that appears to be working in another machine. I can't test that much in this machine with it only going to self test though. But it does look like portB is working, since I can enable/disable BASIC it appears (self test showing different number of RAM blocks).

The ROM is the standard XL OS production ROM chip, I haven't made any alterations to it (tried two different ROMs).

I found today that Star Raiders II also has the diagnostic bit set, so I can run that as well. Everything there seems to work properly as well, although I haven't played a game yet to see if it's all working. I also checked continuity between the CPU address lines and two LS244 chips (buffering the address lines?), and to the OS ROM, and all were fine.

Hi, I'm troubleshooting my 1450XL build, see thread here: And I'm having an issue where the machine goes straight to self test, and the first ROM square is red. All other ROM and RAM tests are green. As I'm troubleshooting and trying to track down the issue, I need some help in where to look. Here's what I know and am assuming: Holding option will allow the self test to show 48 RAM squares, so banking out BASIC seems to work Star Raiders cartridge works and plays, I can fly around and press keys, etc.. No sound though, might be related or not. I have swapped many chips: OS, BASIC, CPU, GTIA, PIA, no change. Continuity checks here and there, no issues that I can tell (but maybe didn't check everywhere) Looking at the OS disassembly and what it's doing during the self test, it looks like it's doing a checksum over C002-D000 and also 5000-5800. Somehow that is failing, but since self test works, that's being banked in properly anyway (maybe not banked out, as the OS tries to do before the checksum routines, but would that actually cause the OS checksum to fail?), because the OS is partially working, and Star Raiders is working, I think all the data bus lines to the OS ROM are working fine, and probably (?) all the address bus lines. Any ideas where to look next? The PAL chips that help with banking may be wrong, but it appears that everything is being banked appropriately from what I can tell. I don't have a SALT cartridge, which would probably help a little narrow things down... might be my next project to build one. I have a logic probe on the way, but no logic analyzer, might be another purchase soon, lol.

I got impatient and soldered in Y2 where I thought it should go, and I now have signs of life! Unfortunately I still have some problems somewhere. I'm getting a picture, which is good, but it's going straight into memory test and showing the first ROM bar as red. All memory tests pass, and holding down Option shows 48 RAM squares as expected. Star Raiders cartridge works and I can play (although I don't have sound, but one problem at a time!). I've swapped the OS ROM, reseated the BASIC rom, swapped BASIC rom, checked continuity around the OS ROM a little, tried reflowing the pins on the OS ROM.

Going through everything on this board, and I had a question, where does Y2 go? I haven't soldered this on but I have the part X115-ND. Looking at the pictures of completed boards, and it looks like it's "next" to the two large holes besides the Y1 marking, and it fits here, but I'm not sure, all those holes just look like vias. Also, another (probably dumb) question, should I fill all the vias with solder, or just leave them open? Continuity seems ok from all the testing I've done.

Thanks! I can add that to my chip tester now.

Very cool. I had John Lemmon in the local Atari user group install mine, and I think it was a clone... I still have that Happy drive, used to work great last time I fired it up.