Jump to content

speccery

Members
  • Content Count

    606
  • Joined

  • Last visited

Community Reputation

1,085 Excellent

About speccery

  • Rank
    Dragonstomper

Recent Profile Visitors

4,694 profile views
  1. I was/am part of the collectorvision Dev team, ported the Atari 2600 core for it and worked on that core. My Verilog version of the TI-99/4A, the icy99, is easier to port than my original EP994A I think. I will probably port that over to the Collectorvision - especially if there is interest as it seems. It would be a fun project. I wish I had more time to work on these projects. I have had the parts for MiSTer lying around now for 18 months, I wonder when I end up plugging the few pieces together… icy99 is probably not as compatible as the current mister core, but it would be a start.
  2. Interesting stuff, need to try these out, thanks @PeteE I just yesterday added the I2S DAC driver code to the StrangeCart codebase - it still doesn't do much, just produces a saw wave or sine wave output. But it is 16-bit stereo sound at 48kHz.
  3. They are GPL routines, so >6000 in GROM space. That's what I did so far too.
  4. Thanks, good idea. Changing the device name is very easy. I’m not planning to take the idea far, but I want to play a bit with the idea of the cartridge being a “super mini memory”. I think it’s a nice test bed for software integration. GPL DSRs are not scanned and found by all software, but TI Basic does do it. I’m not sure what is the support for cartridge space machine code DSRs, I guess DSRs in cartridges are rare.
  5. I want to continue the integration of the StrangeCart to the normal TI infrastructure, so I wrote today my very first few instructions in GPL! My intention is to enable saving of TI Basic programs into the Flash memory of the StrangeCart. I took the code base of the Mini Memory as the basis, and added to the code an small extension, which doesn't do much yet. I just created the start of a DSR of a new device "SCMEM". It is now possible to write in TI Basic: SAVE SCMEM.HELLO The GPL code I created writes the string SCMEM.HELLO to the address >7012, its length to >7010 and it also saves the first 128 bytes of the Basic program to >7080. The ARM could take that and write it to the serial flash memory, but it doesn't do that yet. But by dumping the memory of the ARM I saw that the data arrived in the RAM of the ARM as expected. Not a big deal, since emulating the mini memory already supported RAM for the TI. Going from here to supporting saving should be simple, now that this data transfer works. The mini memory source code is in my opinion a great starting point for looking at GPL. I used the StrangeCart (obviously) for developing the GPL. I have to say that it is very convenient to be able to easily upload with XMODEM a new version of the GPL code into the StrangeCart. No need to unplug or power cycle anything, just a simple USB connection is needed.
  6. Yes, thanks for making it! There's definitely nostalgia at play, but I really like that there's new software requiring just the console! Of course TI Basic has huge constraints, so it is always an achievement to have something playable created with it.
  7. Nice to see a TI Basic game, I haven't played one in ages. At first I could not get this to work on the real iron (controls seemed to have no impact) before I remembered that alpha lock must be on as the code is probably looking for upper case characters. Also discovered that my ET-PEB could not handle 9 character file names, but renaming the file made it work. I was looking for a TI Basic program to test certain things with the StrangeCart, and I think I found what I was looking for
  8. Yes, I did another variable. If you look at the C-code in the spoiler, you can find two new variables: phase and scale. In the video only the phase parameter is used to vary the phase of the curves. After taking the video I also added the scale parameter, which allows changing the scale, but if "zooming in" it currently does not look too great as there are some breaks in the curves - the loops should be adjust a little accordingly. I will add you to the list of people who are interested in the boards. I am trying to get to a point where I could start to offer the boards, I have acquired now components and PCBs for about 20 boards, which would be the prototype/first batch. Hand assembling the boards is certainly a chore, but with the present shortage of chips I figured its best to be a bit self sufficient. I just wish the present heatwave we are "enjoying" here in Finland would ease a bit so that I could me productive.
  9. Thanks @9640News! I don't think I've ever seen a BASIC listing for the Geneve, apparently the syntax is similar to TI Extended Basic with twin colons. What was the speed like? I suppose this Basic is not doubly interpreted and the TMS9995 is faster than TMS9900 at least when workspace is in internal RAM.
  10. I had to dig up my notes to see where the original program came from. After digging for a while it was no surprise to notice it came from Stuart's pages. (I couldn't insert his AA handle here since there are quite a few Stuarts in here and right now I forget which was is his - but credits go to him). You can find it here: http://www.stuartconner.me.uk/tms99110_breadboard/tms99110_breadboard.htm There are also some interesting benchmark results there. Need to check how fast this would go in TI BASIC or TI Extended BASIC, running it without plotting should give a good idea. The run time on the StrangeCart without data transfer to TMS9900 is currently 18ms (milliseconds). Almost all of the runtime is spent running C-library sinf() and sqrtf() functions (single precision sin and square root). There are ARM optimised versions of these but I haven't tested them yet, I expect them to be quite a bit faster. I am curious to check them out. Here is the C-code:
  11. We could also run TMS9900 emulator on the ARM, I have considered that too. In that case we still need the same kind of I/O routing between the processors. But I haven't fully figured out the benefit of emulating the TMS9900 - so that we effectively could run the same software, but this time emulated and probably quite a bit faster, but with quite a bit of complexity in routing all I/O operations to the real TMS9900 to handle... But this is certainly a possibility. And yes, I am aware of Mecrisp and support for that could probably be added as well, although my current firmware is designed in a way that it would handle all the interrupts and USB communication etc, so Mecrisp would need to be a passenger, not the driver at least if I were to integrate it.
  12. If there was supposed to picture in there, I can only see an empty rectangle...
  13. The graphics demo presented on the video consists of two parts: TI-99/4A cartridge ROM for the TMS9900 and ARM code. When the demo TI cartridge is loaded, it is associated with ARM code (and this is compiled C using hardware floating point unit, not BASIC so I am cheating in my comparison a bit ). When the TMS9900 writes to magic locations in the cartridge ROM area it causes the ARM processor to run code, and as a result the ARM will write new TMS9900 machine code into the cartridge area, which the TMS9900 will then run. The primary role of the TMS9900 is to update screen with data calculated by the ARM. To answer your question, if you run your current programs they will still run at 3MHz using the TMS9900, whether they're BASIC or assembly. But I am working on two pieces of code which would make the performance of the StrangeCart accessible: Interpreters running on the ARM, and using the TI for input/output. I have some kind of a start of a BASIC interpreter for this, and it also would be nice to add Forth. SDK to make it possible to create "cartridges" which contain TMS9900 machine code and ARM machine code, the ARM code created by compiling C code using GCC.
  14. I am on vacation. That means a bit more time for hobbies, so I finally published a video on YouTube talking about some of the features of the StrangeCart. I have done every now and then work on the board. About a month ago I got it running at 150MHz, up from 96MHz. That gives opportunities for more precise timing. But due to everything else going on I haven't had much time to work on the board, although there are some other things I've done which I'll discuss later. Progress has been pending a bit on my desire to get a video out for people to see and comment this thing so far. Now I decided to just get a video done, by lowering the level of ambition I had in terms of things I wanted to cover. Hopefully this is still interesting.
×
×
  • Create New...