Jump to content

Shawn Jefferson

Members
  • Posts

    2,047
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Shawn Jefferson

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

     

  3. 8 hours ago, bfollowell said:

     

    For the screen-write code are you going to check for VBXE and use 64/80 characters if VBXE is installed, rather than just the standard Atari 40?

     

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

    • Like 1
  4. 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.

    • Like 3
    • Thanks 1
  5. 10 hours ago, archeocomp said:

    I programmed and successfully tested GAL16V8 from China on TL866 programmer as replacement for MMU in a 600XL. The original MMU was very running very hot albeit working correctly. GAL in place runs much cooler. I could send you my files.

     

    10 hours ago, Rybags said:

    I've not done such programming.  Though the logic involved in the Atari memory selection at that level is usually fairly simple.

     

    But I don't know if there's specific stuff for the 1450 - entirely possible since there's sufficient differences among the likes of 800XL, 1200XL, XEGS.

     

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

     

  6. 13 minutes ago, Rybags said:

    Roms don't use Ras/Cas.  But Freddie should make a system a bunch more reliable as the timing is precise based on 14 MHz clock increments and the delay line relies on electrical characteristics to get it's fractional values.

     

    But 1450... doesn't that have the voice chip and extra Rom to drive it?  Could it be that some Rom overlay is going on which gives a different checksum?

     

    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.

     

     

  7. 31 minutes ago, Mathy said:

    Hello Shawn

     

     

    Freddie is not the MMU!  The MMU is about the size of a memory chip, Freddie is about a big as the Atari specific chips.  Freddie replaces stuff like the delay line and the LS158 chips the XL series has.

     

     

     

    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.

  8. 4 hours ago, Nezgar said:

    There are a number standard XL OS production ROM's... which one are you using? The 1200XL had 2, the 600 and 800XL's had a rev 1 and 2, XE's used XL rev 2 and 3, XEGXS had a rev 4. The 1400's probably had their own too.

     

    I was going to say I could just mail you a drop-in replacement EPROM but that's odd if you tried a 2 already. Do your ROM's work in another XL or XE?

     

    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?

     

    4 hours ago, Rybags said:

    2 failed OS Rom chips with the same symptoms seems unlikely... more likely is there's some issue with the MMU or something in the memory selection circuit like 74LS chip or PIA.

     

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

     

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

     

     

     

     

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

    • Like 1
    • Thanks 1
  11. 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.

     

  12. 5 hours ago, tf_hh said:

     

    Here it is:

    
    CHIP   MMU1200   GAL16V8   COMPLEX_MODE
    
    A11  A12  A13  A14  A15  MAP  RD4  RD5  REN  GND
    REF  S5   OSL  MPD  OSH  CI   IO   NC   S4   VCC
    
    /S4  = /A13 & /A14 & A15 & RD4 & REF;                  /* "Right cartridge" */
    /S5  =  A13 & /A14 & A15 & RD5 & REF;                  /* "Left cartridge" */
    
    /IO  = /A11 & A12 & /A13 & A14 & A15 & REF;           /* I/O Area $D000-$D7FF */
    
    /OSL = /A12 & /A13 &  A14 & A15 &  REN &  REF                /* O.S. Range $C000-$CFFF */
         +  A11 &  A12 & /A13 & A14 &  A15 &  MPD & REN & REF    /* Floating Point routines $D800-$DFFF */
         + /A11 &  A12 & /A13 & A14 & /A15 & /MAP & REN & REF;   /* Atari-Logo $5000-$57FF */
    
    /OSH =  A13 &  A14 &  A15 & REN & REF;       /* O.S. Range $E000-$FFFF */
    
    /CI  = /A13 & /A14 &  A15 & RD4 & REF        /* Set CAS Inhibit, disable DRAM when ROM */
         +  A13 & /A14 &  A15 & RD5 & REF        /* or I/O area is accessed */
         + /A11 &  A12 & /A13 & A14 & A15 & REF
         + /OSL
         + /OSH
         + /REF;

    The MPD signal is connected to 5 volts via resistor, because there´s no PBI at the 1200XL. But the genuine PAL uses this signal ?

     

    MMU_1200.jed 1.07 kB · 2 downloads

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

×
×
  • Create New...