Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Tursi

Members
 View Profile  See their activity

  • Content Count

    7,205

  • Joined

  • Last visited

  • Days Won

    8

Posts posted by Tursi

  1. Posted

    On 11/6/2020 at 8:29 PM, HOME AUTOMATION said:

    Classic99: >0460 >094C

    Win994a:  >04CC >23A0

     

    ...on the diskfile the resultant crc/checksum differs as well. Nothing more. Curious!

    Not on MY Classic99! :)

      

       0070  0300  limi >0002                  (16)
   0002
   0900  0300  limi >0000                  (38)
   0000
   0904  02E0  lwpi >83e0                  (10)
   83E0
> 0908  04CC  clr  R12                   
   090A  23A0  coc  @>0032,R14            
   0032
   090E  1602  jne  >0914                 
   0910  0460  b    @>1404                
   1404

     

    Are you running a replacement ROM?

    • Like 1
    • Thanks 1

  3. Posted

    On 11/5/2020 at 7:19 AM, HOME AUTOMATION said:

    Sure enough, there was a difference at >0908 ...>0460, vs. >04CC.:roll:

    Is it an offset issue, or just that one word?

     

    >04CC is "CLR R12", and >0460 is "B @>" (absolute branch)... pretty big difference.

     

    >0908 is near the start of the interrupt routine, clearing the CRU base. The next instruction is supposed to test for cassette interrupt. Changing it to >0460 sounds like someone replaced the interrupt routine...

     

    • Like 3

  4. Posted

    42 minutes ago, cubanismo said:

    Comparing the source for the 1997 loader with the disassembled 2005 loader, I can see they both put the screen bitmap object at 0x1000, and it's a 1-bit image. The 1997 loader displays 3 lines of text, resulting in a (320 >> 3) x 24 = 0x3c0 byte bitmap, so it ends at 0x13c0. We're safe. The 2005 loader displays 4 lines of text, resulting in a (320 >> 3) x 32 = 0x500 byte bitmap, which ends right at 0x1500 (good guess, right?). The last line is constantly updated, displaying the last uploaded dword. BJL was drawing its text over the first 0x100 bytes of uploaded data, corrupting my BIOS instructions.

    Ah ha... a case of battling bioses ;)

     

    • Like 1

  5. Posted

    2 hours ago, Airshack said:

    What should I do when my program begins in the 24K block of high expansion memory ( AORG >A000 ) and then it's length extends beyond the 24K limit at >FFD7?  [ref: E/A manual, Section19.1 Memory Allocation, p.305]

     

    Specifically, how do I utilize the lower block of 8K memory from >2000 - >3FFF?

    I don't know what other people do, but I create separate assemblies for each memory space. When you're all done you can link the program images manually. ;)

     

    • Thanks 1

  6. Posted

    On 11/1/2020 at 10:08 PM, Swami said:

    One thing someone outside collectorvision might be able to contribute if they wanted was a menu system for the colecovision core where you could add box art and manual pics.

    You could... but you have to remember it's a Z80 reading an SD card - loading the images would slow down the menu a lot. My goal in that menu was performance to get you into the game as quick as possible...

     

    But, if someone wanted to, you have 24k of ROM space to play with, and 512k of RAM during the menu execution... ;)

     

  7. Posted

    I'm not entirely sure I remember. I haven't touched any of those tools since... looks like 2012?

     

    I have definitely run the Skunkboard BIOS from BJL, though... in theory it's not that hard. The Skunkboard copies the BIOS from flash to RAM for normal operation anyway, so it always runs from RAM.

     

    calc_vals does look wrong to me, too, hehe. ;) I'd say your instinct is probably correct.

     

    The code contains absolute jumps, so if you are loading it at a different address and it's working, I assume you're changing the build address. I mean, you should find it's pretty much the same code that is actually loaded into the flash chip when programming the Skunkboard, so I guess you could try comparing against that -- or just extracting the working code and throwing this version away. ;) I can't say what this was used for, might have just been a one-time test.

     

    What was the exception? 0x141c should still be in the initial moves... is one of the labels there mis-defined in your jaguar.inc?

    • Thanks 1

  8. Posted

    15 minutes ago, DuaneAL said:

    Is the scratchpad limited to 256?  I seem to recall that it could be expanded but I don't know if there would be a benefit to doing that.  Although, if you had a larger scratchpad, that might make Playground more interesting.

    The scratchpad responds to memory addresses >8000 to >83FF, so you could in theory drop 1k of RAM there. Any software that relies on the mirroring would fail, but in the unlikely instance that any was found, we could fix it. ;)

     

    • Thanks 1

  9. Posted

    Okay, yeah, that definitely points to the VRAM starting to go. Over at Ninerpedia there's a selection of title page images that show each VDP RAM chip individually corrupted -- if you catch catch the title page corruption matching one of them, that could tell you which chip to replace. (Or, of course, replacing them all). 

     

    https://www.ninerpedia.org/index.php?title=Troubleshooting

     

    There's also the F18A upgrade - the older VGA one is harder to come by at the moment, but Matt will hopefully have the newer version in a few months. That is a plug-in replacement for the VDP that obsoletes the on-board video memory, and so bypasses the issue.

     

  11. Posted

    Version 399.032

     

    - minor tweaks to make it build in 64-bit, but the 64 bit build is not going to be released
    - move the check for "pause when window inactive" to reduce slowdown
    - popcart CRU emulation
    - set VDP interrupt and alpha lock CRU in 9901
    - 60fps in all places (found a place still set to 62hz)
    - set audio buffer to DAC level rather than assume 0
    - more disk DSR sanity checks
     

    http://harmlesslion.com/software/classic99

     

    • Like 12
    • Thanks 1

  12. Posted

    Congratulations! Definitely take a look at your upgraded console when you have a moment, though, it should not be flakey on the title screen at all (especially because the console code doesn't even look at memory expansion, but also from experience - I ran a 32k console with a wait state switch for years). You'll probably find a cold solder joint.

     

    Well, assuming it was solid before the upgrade, of course. Failing VRAM is an increasing problem on our machines, and that would be the second guess... Of course, you can replace that too!

  13. Posted

    The UberGROM and the FinalGROM were designed with different purposes in mind. The UberGROM was never meant to be a reusable flash cartridge that you changed out daily. It was intended for permanent cartridges, to be able to reproduce older GROM carts and to create new ones. It was the first cartridge with permanently reprogrammable GROM in a single chip. So I don't see them as directly comparable. At best you can say that the FinalGROM obsoleted the need for individual cartridges, and that's probably fair. But they /were/ years apart. ;)

     

    A few people use UberGROM for communications, which was one of the goals. It powers the XB27 suite, and that's probably its greatest use. There was also the Break Free game which used the GROM side (since Jim's PCB supports just the ROM, just the GROM, or both ;) ). I can't remember too many other dedicated uses, but, the GROM side at least was created just so it'd be possible to make reproductions of Editor/Assembler and Extended BASIC. And a few people did that, at least! ;)

     

    My own standpoint, though, is that it was never going to be a mass market product. I intended to aim the GROM reproductions at developers who needed them, sell the chips pre-programmed and ready for loading with GROMCFG, and make that my contribution. It all kind of blew up in my face. While I was forced to accept that and release everything to the community, there's no real need to push it. Developers who need it, have it in their toolbox. ;)

     

     

     

    • Like 8
    • Thanks 3

  18. Posted

    Remember that the 32 sprites on a line has a default which is set by the user via hardware jumper. If your software relies on it working, make sure you unlock the F18A and set the limit in VR30 - otherwise it will seem to work on some machines and not on others. :)

     

  21. Posted

    9 hours ago, towmater said:

    I don't know what's inside that rubber mess... but what about just cutting two-feet or so out of the cable and making it a little less cumbersome? Is the length important for some "propagation" reason?

    It's not... people have used all kinds of cables over the years to replace that thing. The cable as built has buffers at each end to drive the signal, but there are no timing issues that I'm aware of. The TI's memory cycle is pretty slow.

     

    Inside the rubber is literally just a shielded ribbon cable. The big blocky "foot" that plugs into the console has buffers for that end of the cable.

    • Thanks 1

  25. Posted

    11 hours ago, dhe said:

    Phase two, I'd like to find a number of people who would like to participate in writing a small game.

    That would serve as a proof of concept, of joint TI collaboration.

     

    The not fully formed plan would be something like this...

    Each person gets assigned a small section of code.

    We jointly check code in and out.

    I don't know if it counts as proof of concept, that's what we did for the megademo. There's already a shipped product that did it! ;)

     

    Wish you luck though! Collabs lead to fun things.

     

     

    • Like 3
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...