Jump to content

Recommended Posts

I finally got around building my first TI-99/4A cartridge, the StrangeCart. My intention was to introduce this only after I have created a demo for it, but since I don't know when I have the time to do that, I will just go ahead and tell about it now. I actually already posted some picture in facebook a few days ago, but at that moment not much was working.

 

This is effectively a modern single chip cartridge for the TI-99/4A. It can eventually act as ROM, GROM, RAM and a ton of other things. I have tested so far only little and I am implementing new functionality as I go. So far I have used it to to provide ROM and GROM and tested it with:

  • Invaders
  • Extended Basic
  • asmusr's raycaster.

It can host all of them at the same time (i.e. there is enough storage for multiple cartridge images even without any storage device).

(story continues after the pictures below)

 

large.IMG_2951.jpg.0b98c9fca713f2183ab897f12e803729.jpg

 

large.IMG_2950.jpg.f57feef1b7810863f9b196053a310dcc.jpg

 

The PCB design did not really go according to plan: the mounting hole is in the wrong place, the pin headers are too far back to fit into the module bay. The silk screen text is all over the place, some fonts are so small that you can just see a blob next to a component. But that doesn't really matter, since the main thing is that it works. I wanted to keep the PCB design very simple, since I am manually building these. Even if I want to build boards with complex FPGA chips, there is still merit in keeping thins super simple.

 

The main action happens on the underside of the board, where a LPC54114 microcontroller implements all the functions. It is the only component on the underside.

 

The microcontroller has two ARM processor cores: one Cortex M0+ core and one Cortex M4F core. I am running them at 96 MHz. In my opinion the really cool thing about this setup and my proof-of-concept software is that the less powerful M0+ core alone is sufficient to serve the bus of the TI-99/4A in real time, leaving the M4F core free for other things. The two cores can communicate via shared memory.

 

Think about running a native code basic interpreter on the StrangeCart, providing something like 1000x performance over extended Basic. Or to say it differently, the raw processing power here is more than 5x of gameboy advance. Plus it has hardware floating point support...

 

The microcontroller chip has 256K of Flash memory and 192K of RAM. Due to these capabilities the board has a bunch of extension headers: if one brings in extra address lines from the expansion connector, the StrangeCart could also implement memory expansion and mass storage expansion. I have provided header pads for the signals which are only present on the expansion connector.

 

The most difficult bit in this has been setting up the software properly so that both cores operate properly and the toolchain works. These chips are very complex, with a huge amount of on-chip peripherals. Still, the "bus server" program running on the M0 core is less than 4K bytes in size. I have setup things so that the M4F is the master processor, it configures everything and then boots the M0. The M0 is running from RAM for maximum performance, with interrupts disabled.

 

My plan is to implement support for the mini memory cartridge, before moving to testing things with parallel processing.

  • Like 15
  • Thanks 1

Share this post


Link to post
Share on other sites
58 minutes ago, jrhodes said:

So, this is basically your take on what the FinalGrom should have been?

Not really. FinalGrom supports larger cartridge images and does well what it is designed to do.

This design is in some sense a simpler single-chip version of my ET-PEB, but adapted for the cartridge port. I was planning to have on the same board also the side connector, but decided to drop that since it would have meant a four layer board and it would have taken more time than I wanted to spend at this time.

  • Like 2

Share this post


Link to post
Share on other sites

Looks pretty interesting! Keep updating! :)

 

  • Like 2

Share this post


Link to post
Share on other sites
8 hours ago, Vorticon said:

Cool! Now what do you envision the main use for that cart will be? 

Thanks! I think it still remains to be seen, once the "standard" features are there (ROM, RAM, GROM support). A clear use case is to emulate old cartridges. 

 

The software running on the StrangeCart is written in C or C++, so development for this platform is fast. One of my original ideas was to create a Basic implementation, which would run fast enough to enable creation of sophisticated software in Basic. That might be attractive to people here. Basic code running on the StrangeCart could use probably at least 128K of RAM, so one would have much more space to work with. If that basic was compatible with extended basic, one could take existing software and just run it on the cartridge faster.

 

Its worth noting that this version of the board is a prototype, I may amend future versions with more low-cost features.

 

The header J4 breaks out an I2S bus, in a pinout compatible with Adafruit I2S Stereo DAC. I have tested these DAC boards with other microcontrollers, but haven't written drivers yet for the StrangeCart. Adding the DAC gives you stereo 16-bit (or even 24-bit) 48kHz audio. My other use case for this board (with or without the TI-99/4A) is implementation of software synthesisers.

  • Like 2

Share this post


Link to post
Share on other sites

I have a pending project that could certainly make use of this hardware - if I can get that far down my todo list. So I'm certainly interested. 

 

What does it cost to build?

 

Audio is kind of a strange case, since the cart port has no audio input. I've wanted many times to make a cartridge with enhanced audio. :)

 

  • Like 2

Share this post


Link to post
Share on other sites
On 5/17/2020 at 10:49 AM, Tursi said:

I have a pending project that could certainly make use of this hardware - if I can get that far down my todo list. So I'm certainly interested. 

 

What does it cost to build?

 

Audio is kind of a strange case, since the cart port has no audio input. I've wanted many times to make a cartridge with enhanced audio. :)

 

I am glad you are interested.

To your question on cost, I haven't calculated the cost of BOM but it is probably below USD 20 even in small quantities. When I bought the components for prototypes I bought also other materials simultaneously, and instead of buying for example only something like 5 resistors actually needed (of a given resistance) I usually buy a hundred. I can build a prototype board for you and send it over, if you cover the shipping costs and materials, something like that.

 

For the audio part, my thought process was something like this: it would be cool to provide enhanced audio capabilities, and since this cartridge would also contain the content (i.e. game), the original audio could be just replaced with audio generated by the board. Thus one could modify the binary of the content, to for instance perform writes somewhere in the address space of the cartridge, and then have the processors on the cartridge pick up that information and generate the appropriate audio response. I already did something like this with my ET-PEB, where it captured writes to >8400 and mapped that information to MIDI notes passed to an external synthesizer.

  • Like 1

Share this post


Link to post
Share on other sites

It will be some time till I get to another hardware project, so don't worry about sending me anything right now. :)

 

I just kept leaning on Matt to add an audio register to the F18A MK2 GPU. Then we can just code whatever audio we want in that. ;)

 

  • Like 2

Share this post


Link to post
Share on other sites

A quick update: got Mini Memory support working. Thus now StrangeCart provides ROM, GROM and RAM. 

Not much testing, but I was able to save and load BASIC code to the mini memory. I powered off the 99/4A while providing power to StrangeCart over USB, and after powering on the 99/4A I was able to load the Basic program back. I dumped the saved basic program bytes to a serial console, and spent a while in trying to understand what they are. Using Thierry's 99/4A tech pages it appears that when doing "save MINIMEM.test" and looking at the bytes which got written to >7000, I have:

>7000..>7007: the mini memory file header

>7008..>700F: 8 mysterious bytes, part of the Basic program. It appears there are 4 words, here, one being a count of something, followed by three pointers in VDP memory, perhaps location of line number table before saving.

>7010.. Line number table of basic code, stored in memory in reverse order, highest numbered line first. The first word is the line number, then another word which is a pointer to the Basic code for that line. Thus 4 bytes per line, first line last in the line number table. My test program had 4 lines, so the line number table had 16 bytes. This leads us to:

>7020.. Finally the Basic program in reverse order, last line stored in the lowest memory address, in tokenised format.

 

I suppose I could add support for flashing the contents of the 4K RAM section of mini memory to the MCU's flash memory, to make the RAM persistent.

  • Like 2

Share this post


Link to post
Share on other sites

That is most interesting. Would you mind posting a picture of the underside of the Strangecart? 

Curious to see how much space the microcontroller uses.

Share this post


Link to post
Share on other sites
Posted (edited)
7 hours ago, retroclouds said:

That is most interesting. Would you mind posting a picture of the underside of the Strangecart? 

Curious to see how much space the microcontroller uses.

Not much - there is a lot of space for all kinds of add ons. I will definitely be using the extra space at some point, I have many ideas for that. By the way, since this is essentially a single chip thing, it could also be attached to the side expansion bus, with a very small PCB. Of course the same applies for the cartridge. Without all the expansion headers and other extra stuff the PCB could be a lot smaller.

The package is a 64-pin LQFP. Makes for a nice and simple build.

large.IMG_0779.jpg.ffd8aad817a8e2bde76480883d0b778b.jpg

Edited by speccery
  • Like 3

Share this post


Link to post
Share on other sites
Posted (edited)
3 hours ago, GDMike said:

Can you make it do better vdp graphics as an optional video processer?

So you want a "plug and play" f18a alternative?

Edited by jrhodes
  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, GDMike said:

Could it happen

It would not work natively as none of the signals necessary to supplant the 9918A are present at the GROM (cartridge) port.

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

What about at the  side port? I'll have a Tipi in the peb, so make sure I can still use that too. I'd appreciate that. 

We need a good video setup don't we?

Edited by GDMike

Share this post


Link to post
Share on other sites
12 hours ago, GDMike said:

Can you make it do better vdp graphics as an optional video processer?

 

Something plugged into the cartridge port cannot replace the functionality of the built-in VDP. As mentioned by @OLD CS1 above the signals are not there. 

I am not sure what you're looking for. For better video functionality, the options are F18A, F18A Mk2, or just replacing the entire computer with a FPGA chip. My Icy99 design supports digital video output on some of the FPGA boards I use for development (this project is not complete yet). The MiSTer port of my EP994A core is also one option.

 

An add on device could provide an auxiliary display, but then we would need software support. In fact StrangeCart supports a very limited version of this, there is a pin header for a small 128x64 OLED display. I have used these displays in the past as status indicators, and was planning to do the same here. The connection is via I2C bus, which is a slow bus for video content.

  • Like 1

Share this post


Link to post
Share on other sites
On 5/25/2020 at 1:58 AM, dhe said:

Are you planning on supporting console grom over ride?

Sorry I missed your message. I am not familiar with override, do you mean

1 - replacing the console GROM content (by pulling them out and using the board to provide alternative GROM content) or

2 - I seem to have read from somewhere that GROMs have weak output drivers and another chip could drive the data bus simultaneously, effectively overriding GROM content.

 

If it is option 2 you have in mind, I have not tested this and don't know if the drivers on the microcontroller are strong enough on the pins I am using for data bus. The chip is operating at 3.3V, which may further limit the drive capability if it needs to "fight" against other chips.

For option 1, the current version of the board does not handle the GREADY signal, although that could easily be wired to one of the spare headers. With that setup the StrangeCart could replace all GROMs.

 

I am curious what content you have in mind for replacement GROMs? Has somebody worked on a new version? Or just to use old GROM code with the version 2.2 systems to support ROM only cartridges?

  • Like 1

Share this post


Link to post
Share on other sites

Back when Millers Graphics release the GramKracker, there where many nice mods made to grom0 and grom1 to customize things.

And yes, your understand (option 2) is perfect, it was more by accidental discover, that it was found grom override worked as well as it did (100%) - because the ttl line drivers essentially just over rode the p-mos signals of the grom chips. I didn't even think about the micro controller, being 3.3V natively.

The other benefit of the gram kracker, being an 8K gram, instead of a 6k grom and that area now becoming larger, and r/w instead of ro.

 

Since you have total software control, do you think the strangecart could emulate the psystem?

  • Like 2

Share this post


Link to post
Share on other sites
17 hours ago, dhe said:

Back when Millers Graphics release the GramKracker, there where many nice mods made to grom0 and grom1 to customize things.

And yes, your understand (option 2) is perfect, it was more by accidental discover, that it was found grom override worked as well as it did (100%) - because the ttl line drivers essentially just over rode the p-mos signals of the grom chips. I didn't even think about the micro controller, being 3.3V natively.

The other benefit of the gram kracker, being an 8K gram, instead of a 6k grom and that area now becoming larger, and r/w instead of ro.

 

Since you have total software control, do you think the strangecart could emulate the psystem?

Thanks, makes sense. My current code assumes 6K GROMs (to conserve flash space) but switching to 8K GROMs is a no brainer and will actually speed up the code slightly.'

 

Yes, it could run the P-system. I was not familiar with p-code, but after a very quick read about the P-code architecture that should not be a problem. Of course it would require writing a P-code interpreter in C. I am sure those must already exist, so it would be a porting job.

 

Share this post


Link to post
Share on other sites

Switching gears to another topic, I read through some of the source code for the Mini Memory module. One thing I learned is that apparently it is possible to implement DSRs in cartridges. I guess it should have been obvious, but I was somehow thinking that they're linked to the expansion bus and enabled with CRU bits in an address space not available in the cartridge slot. As most people reading this probably already know, the cartridge slot only presents 13 address lines and a chip select signal for the address range >6000..>7FFF. Thus it is not possible to have a DSR in this address space, if it would have to appear in the range >4000..>5FFF, where the CRU bits are used to page in the ROMS for different devices.

Anyway, Mini Memory does implement DSRs, and it even does that in GPL code. I have never written any GPL, but reading parts of the mini memory source was pretty straightforward - actually a good starting point for GPL. What I learned (and should have realised before) is that the mini memory save/load mechanism uses the standard DSR interface and you indeed can do it with a cartridge. So that means that the StrangeCart could easily have filesystem support as well.

 

So with that out of the way, I am thinking about something like this: you write a Basic program, and save it on the strangecart. Then you could ask the StrangeCart to run it, on behalf of the ordinary Basic interpreter. And you would go very fast.

Share this post


Link to post
Share on other sites
4 minutes ago, dhe said:

I believe the pcode card itself is just groms - not sure where / how they map, but there are people here with bigger brains. So all you would need to do is space to hold the grom code. I believe mess emulates the pcode, so I'm sure Michael knows the ins and outs.

 

http://www.mainbyte.com/ti99/hardware/peb/pcode_card.html

 

Well GROM support is already there, in fact my current prototype software houses GROM code for 3 separate cartridges. Among the directions StrangeCart could take is interpreting GPL by the CPU on the cartridge. 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...