Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

569 Excellent

1 Follower

About elmer

  • Rank

Profile Information

  • Gender

Recent Profile Visitors

5,197 profile views
  1. Thanks, but it was a 48K 400 that nearly broke the ends of my fingers as I programmed on it, because it was all the I could afford BITD! The 800 was always my dream, and I really regret selling the one that I finally bought, back in the early 90s when it seemed as though I'd never want to program on it again. These days I have a 1200XL that I dearly love, and I don't really *need* an 800, but I got an Incognito a few years back ... so there's something inside me that really wants to go back to the 800 experience. 🙂
  2. I'm *SO* jealous that I missed this! Thank you Paul for keeping the prices good for those people that care (and aren't just going to flip), and best wishes to @Tindron ... the Atari 800 was the 2nd computer that I owned (as an upgrade from a 400, that was all that I could afford at the time).
  3. So, you applied a move-to-front transform on the input stream, and it improved the compression (just like it was designed to do) ... congratulations! https://en.wikipedia.org/wiki/Move-to-front_transform Unfortunately, the decompression is now slower than before, and it needs to keep a bunch of extra information around, thus using more memory. Whether the time-vs-space tradeoff is worth it to you, is something that only you can decide ... but I'm glad that you're having fun experimenting.
  4. So, you're talking about "lazy" coding the matches instead of the traditional "greedy" coding. Yes, that definitely helps the compression! This is not new, and I'm afraid that you're a couple of decades behind the state-of-the-art. The next step beyond what you're proposing is obvious, and that is to look 2 bytes ahead. The cool programmers these days are using "optimal" coding of the compressed stream, but that takes some pretty-sophisticated techniques that just make my head hurt!
  5. Whoops ... there was a small bug in my ZX0 decompressor when handling matches that were a multiple of 256 bytes long ... which are so rare that it didn't get caught earlier. Luckily, the fix actually saves a few bytes and makes the decompressor a liitle faster! Since nobody is complaining about the decompressor size, I've kept it at the same 196 bytes long, and added another 2 branch-unlikely optimizations to make it a tiny bit faster. Here is the fixed decompressor ... zx0_6502.mad
  6. Some quick testing shows that, yes, the new compressor turns ZX0 into something that is (IMHO) usable for development! File Size Compressor Time ========================================== PoPCore.bin 40,164 PoPCore.lz2 23,922 lzsa.exe -f2 1.0s PoPCore.zx0 23,310 zx0.exe -quick 2.5s PoPCore.zx0 22,655 salvador.exe 1.0s PoPCore.zx0 22,646 zx0.exe 35.5s
  7. I have tried to improve my ZX0 (not DX0 as I was incorrectly saying earlier) a few times over the previous months, but while I can make some small improvements to the speed ... the cost in terms of the size increase is never worth it (IMHO). The same happens with the changes in ZX0 for the "new" improvements (targeted at the Z80 CPU) ... the 6502 decompressor is both slower and longer if that "new" format is used, so I recommend folks to just use the option to write out the "old" or "classic" ZX0 format, and to use the assemly-language code that I posted earlier to decompress it. The REALLY BIG news is that Emmanuel Marty released his own much, much, much faster ZX0 compressor a few days ago, and this should now (hopefully) make ZX0 a good replacement for general-purpose development, and it will probably relegate LZSA2 to the trash-bin, along with so many other "great-in-their-time" ideas. You can find Emmanuel Marty's new compressor here ... https://github.com/emmanuel-marty/salvador
  8. Thanks! It certainly looked like the 99105 was deliberately designed to allow the use of the old 3MHz CRU chips, but it's wonderful to have that confirmed.
  9. Yes, the patches are source code patches to the original binutils and gcc source code. They aren't incremental, you just apply the latest patches to the original GNU source archives. The instructions that you're following are from 2012 ... it looks like "gcc-installer.tgz" script was written some time after that. "gcc-installer.tgz" expands into the "install.sh" shell script, which does all of the downloading/patching/build for you. I suggest that you try building the compiler using that script. If your really want to do your own extract/patch/configure/build process, then I suggest that you follow jedimatt42's build instructions (which look as though they also do some patching to get things to build with the gcc10 compiler).
  10. I've never tried to build tms9900-gcc before. Which additional patches are you referring to?
  11. I have another question for you ... It looks to me like just dividing the TMS99105's 6MHz clock by two to generate a 3MHz clock for the TMS9901 and TMS9902 *might* be enough to interface both chips to the TMS99105 without any extra logic, and without needing to buy the faster TMS9901NL-40. Is that what you found with your board, or did you have to add an extra wait-state to each TMS9901 and TMS9902 access (beyond the 1 automatic wait-state that is part of the TMS99105's LDCR and STCR instructions)?
  12. It's been years since I used cygwin, because the whole cygwin project has been rather eclipsed by the developers of the mingw32/msys2 project, but if I remember, cygwin doesn't always put the directory of its DLLs into the current path. Have you searched you cygwin directories for the missing cyggmp-3.dll? If you can find it, then copy it into the same directory as your tms9900-gcc.exe file. Like you, I still use Win7, and I just tried building tms9900-gcc with msys2, but it failed with some errors. This is because every new version of the GCC compiler finds more and more warnings/errors in the older binutils and gcc sources, and the old build scripts fail unless the old source is fixed, or the build scripts are modified. I am having exactly the same problems compiling older versions of GCC with the new GCC 10 compiler on both Windows (msys2) and Linux. 😞
  13. Your experience is similar to mine, in that I have no past history with the TI99/4A or Geneve, and have no paticular interest in keeping compatibility with them. I remember seeing the Cortex issues of ETI in W.H.Smiths, avidly reading the details, and then lusting after the machine, even though I couldn't afford it. Somehow I got hold of a TMS9995 Data Manual, and I was absolutely fascinated by the architecture. Then I became even more fascinated when I read the TMS99105/TMS99110 Data Manual. But alas, I had neither the spare cash, nor the electronic skills at the time, and the fascination never led to any action. Now that SMT Prototyping services are becoming affordable, it is fun to think of how a Cortex successor might be designed, especially since Matthew Hagerty's amazing work on the F18A-MK2 would seem to provide an excellent solution to the otherwise difficult video portion of such a machine.
  14. If you're following Start's example of driving the EPROM and SRAM chips' /OE lines with the CPU's /RD signal, then that might be where your problem is. Taking a look at the TC551001BPL-70's datasheet, it says that the /OE Access Time is 35ns, the same as the 55ns SRAM that I can get. Add another (generous) 7ns for the signals to propagate throught the 74ALS645, and you've got 42ns before the CPU can see the valid data. According to the TMS99105 data sheet, the time between /RD and when the CPU expects the data to be valid, is Tded = ((1/2 Tc2) - 63) = (83 - 63) = 20ns. If you look carefully again at Stuart's website, it says that he used a W24257AK-20, with a /OE Access time of 10ns ... which does meet the TMS99105's timing requirements. <EDIT> This timing condition is probably why some of the examples in The 99000 Microprocessor book seem to suggest only using the /RD signal to activate the 74ALS573 / 74ASL645 data buffers, and not the memory chips' /OE signals.
  15. I completely agree with the joy of using old parts at the heart of the system (especially the CPU), and keeping the modern stuff as convenient replacements for logic and memory chips. Another thing that I think of as fair, is replacing old-and-cantankerous serial port hardware with something modern like an FT245RL, which gives you essentially the same functionality, but is much easier to use. From what I can see, the first challenge with trying to design a simple system using the TMS99105, is going to be running a no wait-state memory cycle, with only 85ns from ALATCH-hi to needing to having the data available at the CPU's pins. That isn't too bad if you're willing to buy/solder a 25ns-or-less SOP/TSOP package chip onto your circuit board, but it seems a bit more challenging if you're looking at the modern SMT PCB prototyping companies, who seem to be more likely to only offer 55ns 5V SRAM parts. Then again, *if* you can design for the 55ns memory speed, you can take advantage of the wide availability of dirt-cheap 55ns SST39SF040 flash ROM parts. If I am understanding the datasheets correctly, then the 74LS612 is going to need some really fast SRAM to reliably run the TMS99105 with no wait-states. Its tAVQV1 time of 39-79ns would seem to push the limits of your timing, especially with 74ALS573 buffers between it and the CPU, with 3-18ns delays on both the address and data. If you then add in any more decoding logic between the 74LS612 and the ROM/RAM, or any card-to-card buffering, then things would seem to get pretty dicey.
  • Create New...