speccery
-
Posts
922 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by speccery
-
-
I have continued to work on the StrangeCart BASIC over the past several weeks. I haven't recently had the time work on the hobby for extended amounts of time in one go, with these constraints working on software seems to be somewhat easier than hardware (I have several things to do there such as new picocart PCB layout).
Anyway I realised that what I was missing was the thing BASIC is known for - immediacy i.e. command mode. Up til now what you could have been doing with the StrangeCart is to load an existing TI BASIC program and save it to the memory of the StrangeCart, and use its CALL RUN to have run the BASIC program very fast. In other words, BASIC program editing would be done with regular TI BASIC; access to StrangeCart has been a bit indirect, as save to the flash memory of the board has the side effect of making the program available for the StrangeCart BASIC interpreter.
Earlier, the firmware has thus treated the BASIC program as a ROM: even though my interpreter can run the BASIC program, it could not modify it. I am now in the process of adding a tokeniser and building blocks for editing the loaded program. The revised BASIC has already now a command interpreter, which can be entered and it runs entirely on the StrangeCart. Within the interpreter there are bunch of standard BASIC features already working:
- RUN command enables running the program (nothing new)
- LIST command enables listing the program (supports now ranges of lines)
- OLD enables loading a BASIC program from the SCD1 drive
- BYE exits the command interpreter
Those commands were already there in various forms, but now:
- Entering NEW clears the BASIC program and variables (yes, progress comes in small steps)
- Entering a line number alone deletes the line from memory
- Entering a line number and code after it tokenises the code and inserts the code line into the right place of the program.
These sound trivial additions, but the size of the BASIC and other parts of the firmware expanded by almost 1000 lines of C++ to support these features.
Tokenising TI BASIC lines takes a bunch of code, and the memory management of altering BASIC programs in memory is also a bit tedious: I am maintaining in the StrangeCart's memory the BASIC program in normal TI BASIC save format: there is a 8 byte header, followed by the line number table (backwards as in the VDP memory) followed by the program code (also backwards, highest numbered line of code in the lowest memory address). The only change I implemented is that while in VDP memory the BASIC program size is restricted to 16K (in practice less) and is loaded near the top of the 16K space, now after loading a I modify the 16-bit line pointers so that they are zero based relative to the memory address where the BASIC program is stored. This is reversible - it simply means subtracting a fixed memory offset from every line number table address entry. That can be added back, and if subsequently saved the program can be loaded back to normal TI BASIC (I haven't tested it yet but I am sure I can make it work since the format is the same). But the plus side is that the tokenised program size can extend up to 64K. The compatibility at the moment with the use of 16-bit line offsets means that 64K is the limit for tokenised code - data areas are on top of that.
When fully completed and the onboard command mode is finalised, these changes mean that I can support different video modes with ease. My intention is to do this so that when one enters the StrangeCart BASIC command interpreter, the 16k VDP memory contents are copied to the StrangeCart's memory for backup, and then I will be free to mess around with VDP memory to support any video mode - including F18A 80 column mode - for TI BASIC programs. When returning from the StrangeCart BASIC back to TI BASIC I intend to restore the state of the VDP.
Even with these limited features I have had a lot of fun playing with the command interpreter while working on the code. The command mode makes it self contained. In fact I am testing the interpreter without even plugging the board into the TI, since the command interpreter also supports operation over serial line.
-
8
-
1
-
I bought from eBay another TI-74 to have another unit in case I make a mistake and break something. The device arrived today.
I got it for a reasonable price, and I also got another thing I was looking forward to - a cartridge for the device. This is important for me as now I have in this cartridge the edge connector for this thing.
Interestingly there appears to be an EPROM chip in the cartridge. And as an added bonus, I now have what appears to be a pension calculation software
in German and working in Deutsche marks - the currency has aged less well than this TI-74... Anyway the computer seems to work well and is a good working order. If I have the energy at some point I intend to make a PCB and use the connector in this cartridge for it.
I am also thinking about implementing the hexbus protocol in the strangecart, which would enable me to attach the TI-74 to the TI-99/4A. That is clearly highly useful
in this day and age...
-
4
-
-
On 5/13/2023 at 2:10 PM, Vorticon said:
Any advantage to using that board versus an arduino?
It's a lot smaller, at least compared to regular Arduino size. I also will check if it could be powered directly from the TI-74, making the whole arrangement more portable. I'm starting to have a bit too many projects
but I was planning to make a specific PCB for this one, potentially including LIPO battery interface.
-
2
-
-
On 5/9/2023 at 2:21 PM, JasonACT said:
In your opinion, would you add 3 pull-up resistors on the ~enable pins of 3 of the '245 chips for when the Pico is still resetting?
Yes good point, in fact one of the mods I already have done for the board is this. Especially important for the '245 driving the TI's data bus.
-
@arcadeshopper Hi Greg, a follow up question: I will need to do another spin of the PCB to fix the bodge wires. I have already done pretty much the work, but I am planning to swap out the external serial flash ROM chip and put in a SD card slot instead. While I am at it, I could also put in a pseudo static RAM chip. I have already those, if I remember they're 8 megabytes in size. It's a nibble wide serial chip, so might be a bit tricky but should be able to use that for cartridge ROM storage. What amount of memory you'd like to see?
-
1
-
-
2 hours ago, dhe said:
That's one way to add an SD Card slot! 😃
Yes! I don’t know about you, but I have many of these micro SD to full size SD adapters. Might as well put them into good use
and I’ve been wondering if they actually can be soldered like this. They can, but one has to be quick in order not to melt the plastic…
-
4
-
-
I've been working on a port of @brain's great HEXTIr project for the Black Pill board. It now works in terms of being able to save and load programs to a SD card. Still need to test more and debug as the port is in its infancy. It's been a fun project so far. The code is here at GitHub. I wrote some comments in the readme file there. Below some pictures, I like the form factor here although still need to provide a proper power supply, perhaps with a LiPo batter or something.
-
6
-
-
On 4/30/2023 at 6:50 AM, arcadeshopper said:
@speccery what are the memory specs on this board? how much rom and grom can it simulate?
Sorry for the late reply, I haven't clearly been paying attention here. The microcontroller RP2040 chip itself has about 264k of RAM, so I think that carts at least around around 200k bytes can be served from RAM, be it ROM and GROM. In addition, the Raspberry Pico board itself has an external 2 megabytes of flash ROM, which I think is fast enough to serve GROM and but perhaps also regular ROM. It's been a while I worked on the code, need to check where it keeps the ROM contents. In addition to those memories, there is also a 16 megabyte external SPI flash chip. In practice this means that as far as GROM is concerned, there is no limit in practice. For ROM, it might be limited to the internal RAM size.
-
2
-
-
Since I'm in the process of going into yet another rabbit hole by having ordered a CC-40 from @arcadeshopper, I played a little in the last few days with my TI-74 to get started with CC40 thoughts
I found an Arduino UNO from the bottom of a drawer and a SD card adapter shield, and built a HEXTIr. The SD card shield I have is from Seeedstudio. The PCB version of the shield is 4.2 and date is Nov 2013, and I think that sounds about right when I bought it. Soon that thing is retro in its own right... Anyway I had to edit the HEXTIr code a little to get it working with this setup, mainly in order to not try to detect the SD card presence (edited config.h). I also added a jumper to tie D10 and D4 together, in a lazy effort to get the chip select of the SD card to the right pin. The HEXTIr code uses by default pin D10 (i.e. PB2) for SD card select, while this shield uses D4 (PD4).
In my build there's no pull up resistor on the D2 (PD2) pin (hex bus BAV signal), but it still worked. I compiled the HEXTIr firmware with the Arduino IDE. I kind of hate that IDE, but it is easy to get started. For good measure I enabled debugging by editing config.h:
#define CONFIG_UART_DEBUGThis was very useful, since otherwise it would have been hard to know if something is working. My main obstacle turned out to be a 2GB SD card, once I switched to a 32GB card it worked.
I used to have a pocket computer back in the day, for the life of me I can't remember the model but I believe it was a Sharp. The TI-74 brought back memories of that device and also made me wonder what happened to it, perhaps I gave it to my brother or something.
I also wanted to get a feel of what TMS7000 assembly looks like. I discovered that MAME supports the CC-40, so I compiled MAME, found the CC-40 ROMs and tested that. It took surprisingly little effort to compile and running MAME with
mame -window -debuggave me a view of the assembly code on the CC-40.
I have no idea how to get the CC-40 cartridges loaded in MAME, I guess it wants some specific file names or something?
Another question: I was able to find and load the PC interface extension modules to the TI-74 (i.e. call poke, call peek etc.). I learned that these are loaded with LOAD.PGM, and it made me wonder how the LOAD.PGM itself works, as it somehow is able to load these machine code routines and make them visible to Basic. Also, is there a way to load all of the extensions in one go instead of manually loading them one by one? It feels that must be possible.
And finally, I assume someone has made an tokenizer and detokenizer for the TI-74/CC-40? I think I saw somewhere a mention of such a program, at least for Windows. Having it would make it possible to edit BASIC programs on a modern computer (and to take a look at what LOAD.PGM does). I am a Mac user, but I do have a windows box too.
Thanks for comments and advice already in advance!
-
3
-
-
I released new firmware for the StrangeCart, please see description at the Github wiki page.
The new firmware is available here.
The updates are relatively minor on the outside, but internally more significant. The big one is a more comprehensive INPUT handler with a line editor with command history memory. One thing I forgot to mention in the Wiki is that the line editor currently works a little differently from the one we're used to with the TI: FCTN+1 works like backspace (delete to the left) rather than delete. Insert mode is on all the time.
-
1 hour ago, TheBF said:
Did you ever find a use for Mecrisp or was that a side project?
I did test it a little. I tested it on the grommy2 board but I didn’t try to get the actual GROM functionality running it. I think it is interesting and very useful for brining boards up, but I am so much more productive with C++ that at least for now I am keeping it on the side. I am still considering making it available on the StrangeCart, but if I do it it would rely on the existing code for communication with the TI, so I would need to integrate it.
-
2
-
-
I've been very busy in the last month or so with work, no progress with any of my TI related projects. But now I have a long weekend, with some time to work on the strangecart and I also plan to work on the grommy2 firmware.
I've refactored the strangecart firmware somewhat, this has been a background project, I started it already a couple of months ago. It's been slow going progress due to lack of time. I've reached a point where the code is somewhat easier to work with.
Anyway, I've now been able to get some progress done with the Basic interpreter. These are not only visible internally to the code but also providing additional functionality. One of the open points in the strangecart Basic was the lack of proper handling of INPUT statements. That's now in much better shape, supporting proper handling of input prompts and input to multiple variables. I still need to improve the line editing functionality, it's now super simple and does not support any editing
but I will change that. The strangecart firmware already has a line editor which is used when communicating with it using the serial port (over USB). That line editor also supports command history features. As part of the refactoring I ported that code from my previous C-language version to C++. I will need to see if I use that as the basis for the input line editor, or if I create another version.
Having a line editor will also be necessary to add in the future tokeniser (i.e. conversion of input text to Basic lines). I want to do that since I want the strangecart be able to also offer interactive Basic mode. Once I have that, I want to add support for 40 column text mode and also support 80 column mode with F18A. My intention still is to resist going wild with extensions - tempting as those are, but rather make the Basic programming and debugging experience friendlier.
The bottom line is that there is progress, and hopefully quite soon a new version of the firmware. There aren't many strangecarts out yet, but if you have feature requests please let me know!
-
6
-
-
I've been building a couple of StrangeCarts and I also have interest from the community for some more, so I wanted to make the build process slightly faster by automating testing. I have sketched a test sequence I take every board through before sending them over, but I realised I can still improve the coverage and make the testing job easier for me.
The most common problems I have encountered are that the microcontroller is not properly soldered. I do it by hand, and I try to do it very carefully, but mistakes still sometimes happens. There are two main categories; shorting two pins next to each other (the distance between pins is 0.25mm, even a tiny bit of solder can bridge them) or that there is too little solder somewhere, and a pin I thought is connected actually is not. The latter is actually the main issue, I'm pretty good at spotting solder bridges and double and triple check for this before applying power for the first time.
To help with this, I now added a test mode to the firmware ("pintest"). It's a simple algorithm, which configures almost all of I/O pins into GPIO mode and sets the as inputs, with internal pull up resistors enabled. As a result, all I/O pins should read as ones. Then I run a sequence, where I set one pin at as an output, and drive it briefly low. When done, I check that it actually went low, and also that no other pins went low (indicating a short).
This simple pintest is very effective, I use it as follows:
- I first check for shorts. With the board unplugged (only USB connected) I run the pintest once, and if all is well nothing is shorted and any input doesn't go suddenly low when another pin is configured as output driven low. This tells me that there are no shorts, but it doesn't tell me if pins are properly soldered.
- Once the above test succeeds, I plug in the board to the TI and run Parsec from the StrangeCart. That tests all address and data lines and most control lines.
- I then unplug the board from the cartridge slot to test the remaining lines, meanly used for optional extensions. To test these I apply manually a wire between two pins, just holding it with my hands while running the test. What should happen when I run the pin test is that I get two errors, for both of the pins connected with the extra wire there should be another pin which follows it, due to the wire. If I don't get an error, one of the pins is not soldered properly. If I get two errors, it's good, and I move the wire between two other pins and run the test again. This way I can very quickly cover all the pins not used when running Parsec. There are 11 extension pins like this.
-
7
-
I finally did a video of the GROMmy boards. You can find it here. I hope you find it interesting and/or entertaining
-
7
-
2
-
-
This is cool indeed. Reminds me of article I read a long time ago about creating the smallest elf executable "possible", where the whole executable code was in the elf header and as I recall the header was also shortened
-
1
-
-
11 hours ago, PeteE said:
Thanks @PeteE for the help here. I will add that link to the first message of the thread.
-
1
-
-
Didn't realise its been this long since an update here... Sorry, I'll try pick up speed with this thread as well. Even if I've been busy with RL it shouldn't be hard to improve from a 3 month interval...
Anyway I started to do minimal order fulfilment by assembling two new StrangeCarts. This is the newest PCB iteration - a design I did 6 months ago but only now am assembling. It's the same as the previous one, except the edge connector is about 1mm deeper.
For assembly I'm testing the approach I've been using with good success with the GROMmy boards: hot plate with low temperature solder paste. I don't have a stencil and as you can see the hot plate is so small that it's only baking half a board at a time. But the nice thing is that it follows the temperature profile. Also, even without the stencil and manually placing components, the build process is faster than with individual soldering. During working week I anyway don't have enough time in one evening (with other unrelated activities) to assemble a board fully, so one half at a time should work well. I will reflow the chips with a soldering iron afterwards, without a stencil the TQFP package is not going to solder properly...
-
6
-
-
5 hours ago, Artoj said:
Hi All,
I am still waiting for many parts, in the meantime I added the Stuart Conner's TMS9995 SBC design including 48 I/O lines so it fits into the Mini Expansion unit. Now I can use the box without the TI99/4A connected via the side port. You can use Cortex Basic of the TMS9995 SBC from a terminal as it has a RS232 port, So now the box can fit a whole lot of cards that are built just for the SBC as well. I am still working on adding lots of CRU decoding as well, on a separate card that could possibly decode 128 and more lines. This should complete most of my projects for the TI99, one more card is still in the works. Regards Arto
That's very cool, thanks @Artoj! How many cards are you having now in total?
Now that I finally have a PEB (clone) myself, I've been thinking about a TMS9995 board for the PEB in the spirit of the Geneve, but that's another story. Is your board designed as a bus master, or can it co-exist when this is connected to the TI? Also, wondering if having a VDP card would be interesting too now that you have the CPU, for example my FPGA VDP design could easily be added in here...
-
2
-
-
While recovering from the flu, I realised that a board I've been working on happens to have 15+ I/O pins on one edge. I've been using the keyboard connection solution depicted in the first message of this thread since July and it's been working great, but it's clumsy and untidy. So I ported the code to this other board I created and got it working today. Much tidier, when I have more energy I will try to see if I can fit this and the keyboard at the same time. The white extra wire is the ground wire, the TI keyboard connector doesn't have a ground connection. I'm hoping the TI keyboard cable will get a good connection on top of this extra board. Even if it doesn't, this is still so much more convenient.
-
6
-
-
1 hour ago, Archimedes5000 said:
Hi, sorry for beeing late. Yes I am interesset, if it is not too late. How can I get them ?
Greetings Axel
Hi Axel, just send me a PM and we can go from there.
-
5 hours ago, TheBF said:
You use Mecrisp for eveything of course.
(just kidding)
It might be useful to have Mecrisp for testing the boards. Lot's of Forth shops use it that way with a few scripts that can be shot into the board and confirm things are working properly.
Much handier than the old " debug monitor" programs that embedded stuff used to use.
It indeed would be possible to run everything in Forth. My productivity using C or C++ is probably 100x compared to what I would do in Forth
For testing and bring up of hardware projects Forth indeed is great, as for other hardware tinkering. The nice thing about mecrisp is that it supports storing programs into flash very easily, you basically just turn on programming mode, and it will compile and store directly to flash.
Of course it would be simple to implement in GROM space something akin to a serial port, which would make it possible to interact with mecrisp from the TI, i.e. use the TI as a terminal for it.
-
5
-
-
I wanted to measure how much of the CPU capacity of the grommy2 goes into emulating a GROM chip. It appears to be approximately 4%.
This is the update I alluded to in the previous message. I've been wondering for a while if the StrangeCart could run the GROM service routine as an interrupt instead of polling. On the StrangeCart cart it is not as important as it is faster and anyway needs to poll the bus to support ROM / RAM accesses, but on the grommy2 it could be interesting to see if interrupt based approach would work.
And it did, I configured the STM32 EXTI interrupt system so that whenever the /GROMCS goes low, the grommy2 gets an interrupt and handles the GROM services in the service routine (ISR). The reason I wanted to go to this direction was to be able to measure how much of the CPU capacity of the grommy2 goes into emulating a GROM chip, and also to reduce power consumption by halting the CPU if nothing is happening (the power consumption is anyway tiny). I configured one of the many timers on the STM32 chip as a timer counting 500ns intervals, and my ISR resets the timer in the beginning of processing and reads the count at the end. I then store the current, minimum and maximum values of the ISR processing time. The main loop is mostly just sleeping and waiting for interrupts. Every 5 seconds it prints out using the statistics using the serial port, the statistics contains the number of GROM reads, GROM writes, CPU usage.
The code is not by any means optimized, but further optimisation is not really necessary since the 4% level is so small. The 4% applies to handling GROM services when running TI Basic, of course this is application dependent. Parsec seems to use around 10% during its peak time at the start of the game when it's probably transferring data from GROM to VDP RAM. Once the game runs, it's consuming only around 0.5% of the grommy2's CPU since it's doing very few GROM accesses at run time.
Now this approach also means that the grommy2 could run some other software most of the time. I'm still thinking about "porting" Mecrisp Forth over... Not entirely sure what would be the use case for that, other than it would be cool to have it in there.
-
2
-
-
14 hours ago, Artoj said:
I am waiting for my T48/TL866 programmer with adaptor boards to arrive, is this usable for your boards?
I don't know. I have a TL866 I think, haven't used it much. A simple FTDI USB-to-serial dongle is all that's needed to program the GROMmy2. The StrangeCart appears as a USB drive in programming mode, so with it even the dongle is not needed. Actually I have been thinking that the StrangeCart could become the dongle for GROMmy2. The real solution is to make it programmable from the TI's side, I have been doing design and preparations for that. I've been having a flu for the past week or so, which has caused a slowdown with everything. I did do one interesting improvement last week, need to write about it later.
-
2
-
-
On 1/25/2023 at 9:40 AM, Archimedes5000 said:
I am interested in testing. Can you build it yourself or order it?
Greetings Axel
I have a few available, happy to sell & ship if you want. I have a couple other shipments to do as well, so need to get to it...
-
1
-
in German and working in Deutsche marks - the currency has aged less well than this TI-74... Anyway the computer seems to work well and is a good working order. If I have the energy at some point I intend to make a PCB and use the connector in this cartridge for it.
in this day and age...
and I’ve been wondering if they actually can be soldered like this. They can, but one has to be quick in order not to melt the plastic…
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
StrangeCart
in TI-99/4A Development
Posted
Thanks @Ksarul I remember this being mentioned by someone (you?) in some call or at least in the forums. Is there an example cartridge somewhere I could take a look at? I would be interested in taking a look. Would be a great match for this project - and a nice way to compare performance as the StrangeCart can both emulate GROMs allowing in cartridge mode and- if I can extract the BASIC program - I could run it using it's BASIC interpreter.